Назад | Перейти на главную страницу

Консолидация SQL Server

У нас есть несколько стандартных серверов SQL Server 2008 R2, каждый для одного приложения, которое мы хотим объединить в один физический сервер. Запустив perfmon на этих серверах, они не используют большой объем ЦП, операций ввода-вывода или сетевого трафика, поэтому они являются хорошими кандидатами для консолидации. Пара вопросов:

Что лучше: создать один экземпляр с несколькими базами данных или несколько экземпляров (например, экземпляр для каждого приложения?)

Я не ожидаю больших споров, но есть ли способ каким-то образом управлять вводом-выводом, чтобы ни одна база данных / экземпляр не могла занять все ресурсы ввода-вывода? Я знаю, что могу справиться с CPU с помощью регулятора ресурсов.

В конфигурации RAID у нас будет 22 диска (и 2 «горячего» резерва). Запись тяжелее чтения, поэтому мы сделаем RAID-10. Лучше установить один большой массив для всех баз данных, а затем два меньших массива для файлов журналов и tempdbs, или настроить выделенный массив для каждой базы данных / экземпляра.

Спасибо.

Вот о чем следует подумать:

  • Возможно, вы захотите использовать отдельные экземпляры с точки зрения безопасности. Если у вас есть единая группа администрирования для всех существующих серверов, это не проблема, и один экземпляр с несколькими базами данных может быть подходящим вариантом. Если вы нарушите свою администрацию или если у вас есть особые проблемы с безопасностью, то отдельный экземпляр может оказаться неприемлемым.
  • SQL Server Enterprise - единственная производственная версия, в которой доступен регулятор ресурсов. Если вы переходите на стандарт SQL, это не вариант для вас.
  • Работа с dba для одного экземпляра может быть проще, чем для нескольких экземпляров (с точки зрения общих операций).
  • При отсутствии регулятора ресурсов будет проще ограничить память, используемую каждым приложением, используя отдельные экземпляры и установив параметр максимальной памяти для каждого экземпляра. Однако это также добавит дополнительных административных расходов. Тем не менее, SQL Server ОЧЕНЬ ХОРОШО управляет физическими ресурсами. Информации о вашем окружении недостаточно, чтобы понять, стоит ли это начинать, но мое чутье говорит нет.
  • Как правило, у вас есть больше переменных, работающих с одним приложением в общей (то есть с одним экземпляром) среде. Например, если плохой план запроса застревает в кэше планов, и вы используете один экземпляр, это может отрицательно повлиять на все другие базы данных, пока вы не очистите этот плохой план. Но, опять же, это не похоже на большой риск для вас.

Если в настоящее время базы данных не выполняют интенсивный ввод-вывод, тогда у вас должно быть все в порядке, просто имея том для данных, а затем отдельный том для журналов.