Мне нужна причина, почему мы не должны устанавливать SQL-сервер на контроллере домена

Я системный администратор для небольшой фирмы. Сейчас мы рассмотрим выпуск Windows Server 2008 R2 для фирмы. Мы планируем реализовать Active Directory. Мы также хотели бы обновить RDMS с SQL Server 2000 до SQL Server 2014.

Мы можем позволить себе купить только один сервер из-за размера нашей организации, поэтому мы планируем реализовать AD и SQL Server 2014 на одной машине. Тем не менее Microsoft рекомендует не устанавливать SQL Server 2014 на контроллере домена.

Я проверил причины, но я не понимаю, в чем проблема, поэтому, если кто-то ответит на мои вопросы ниже, это действительно полезно.

1. Нельзя запускать службы SQL Server на контроллере домена под локальной учетной записью службы. → Что произойдет, если мы запустим SQL Server на контроллере домена под учетной записью пользователя домена?
2. После установки SQL Server на компьютер вы не можете изменить компьютер с члена домена на контроллер домена. Вы должны удалить SQL Server, прежде чем сменить хост-компьютер на контроллер домена. → Мы планируем продвинуть наш сервер на контроллер домена до установки SQL Server 2014 и не планируем отменять продвижение на рядовой сервер, потому что это наш единственный сервер. Наш план неверен?
3. После установки SQL Server на компьютер вы не можете изменить компьютер с контроллера домена на члена домена. Вы должны удалить SQL Server, прежде чем сменить хост-компьютер на члена домена. → Мы не планируем отменять рекламу на рядовом сервере, потому что это наш единственный сервер. Наш план неверен?
4. Экземпляры отказоустойчивого кластера SQL Server не поддерживаются, если узлы кластера являются контроллерами домена. → Мы не планируем устанавливать отказоустойчивый кластер, поэтому считаем, что это не проблема. Мы не правы?
5. Программа установки SQL Server не может создавать группы безопасности или предоставлять учетные записи служб SQL Server на контроллере домена только для чтения. В этом случае установка не удастся. → Поскольку у нас всего один сервер, поэтому он никогда не будет контроллером домена только для чтения, поэтому мы считаем, что это не проблема. Мы не правы?

На самом деле, я думаю, что если мы очистим (1), мы сможем установить SQL Server 2014 на нашем контроллере домена.

Спасибо за чтение всех предложений. Я надеюсь, что кто-то даст нам ответы.

Точки, которые вы перечислили, показаны здесь в BOL , и даже если они цитируются:

Программа установки SQL Server не будет блокировать установку на компьютере, который является контроллером домена

В этой статье базы знаний говорится, что установка не удастся, хотя применяется только к списку до версии 2012.

Одна из главных причин, по которой вы будете против этого, - поддержка Microsoft. Как указано в документации, вы не должны устанавливать его, они вряд ли будут оказывать поддержку. Особенно, если у вас есть проблемы с безопасностью или производительностью. Если вы не раскошелитесь на большие деньги, они, вероятно, мало что сделают для вас.

Я никогда не видел, чтобы компания ставила эти две роли вместе без выбора. Мне неприятно это говорить, но если им нужно запустить приложение на SQL Server, и оно станет критически важным приложением, у них нет причин не вкладывать средства в запуск этого приложения. В наши дни аппаратное обеспечение дешевое, и AD не требует много времени, если ваша организация настолько мала. Вы могли бы даже пойти и получить 2 или 3 года оборудования в этом отношении.

С учетом вышесказанного сервер Window Small Business раньше был универсальным средством для ситуации, которую вы описываете. Это AD, Exchange и веб-сервер все в одном; и, если я помню, также был установлен SQL Server, но я не могу вспомнить. Я установил один из этих серверов для отдела один раз.

Однако в Windows Server 2012 они изменили это на Window Server Essential Edition , и я не уверен, какие роли вы получите в этом выпуске. Я бы посоветовал вам просто потратить деньги, чтобы получить Standard Edition. Функция, которую вы получаете со Standard, - это лицензирование для запуска двух виртуальных машин гостевой ОС через Hyper-V. При правильном подборе оборудования это позволит вам запустить экземпляр SQL Server на одной виртуальной машине, а затем приложение на второй. Несмотря на то, что ваша производительность находится на одном сервере, она обеспечивает разделение границ и будет полностью поддерживаемой настройкой Microsoft. Просто мои два цента.

Причины, которые вы привели, - это основные причины, по которым следует избегать сочетания SQL Server и контроллера домена. Я добавлю еще два:

• Это может быть угроза безопасности, если ваш SQL Server доступен с компьютера, подключенного к Интернету (например, веб-сервер)
• SQL Server потенциально может лишить Windows ресурсов, что приведет к эффективному отключению контроллера домена и, в свою очередь, вашей сети.

Тем не менее, совсем нередко видеть SQL Server, установленный на контроллере домена в малом бизнесе - у вас есть только так много ресурсов, и вам иногда приходится обходиться тем, что у вас есть.

Итог: избегайте объединения ролей сервера, если можете. Если вам необходимо объединить AD и SQL Server, помните о рисках и делайте все возможное, чтобы уменьшить их.

[Отказ от ответственности: я бы никогда не подумал объединить AD и SQL Server ни с чем, кроме очень малого бизнеса. Существует слишком много рисков, и нагрузки на серверы обычно намного тяжелее.]

Настоящая проблема здесь заключается в том, что AD DC уже использует SQL Server в качестве своего собственного механизма внутренней базы данных с некоторыми специальными настройками для обеспечения хорошей производительности (так называемая внутренняя база данных Windows). Если вы установите SQL Server на DC, он вступит в конфликт с этой реализацией, поэтому вы столкнетесь не только с проблемами продвижения или отмены продвижения DC, но и с самой базой данных.

Существует также проблема производительности диска для служб и приложений, отличных от AD-DS на контроллере домена, однако это можно исправить, установив SQL Server и поместив базы данных и файлы журналов на диск, отличающийся от диска, на котором находится NTDS.DIT ​​AD. база данных.