Насколько дорого (с точки зрения ЦП или памяти) иметь несколько экземпляров SQL Server 2005 вместо одного экземпляра с базами данных с префиксом?
У компании есть три поставщика приложений. Каждый из них установит одно приложение, и для каждого из них потребуется две или три базы данных. Должны ли они использовать один и тот же экземпляр или каждый провайдер должен использовать собственный именованный экземпляр?
Есть ли веская причина для той или иной установки?
Единственная веская причина для установки отдельных экземпляров на одном оборудовании - это очень строгие требования к изоляции. В противном случае всегда лучше иметь только один экземпляр. Один единственный экземпляр может лучше оптимизировать все аппаратные ресурсы для нагрузки, с которой вы сталкиваетесь. Несколько экземпляров не взаимодействуют друг с другом и перекрывают нагрузку на память, ввод-вывод и процессор, что приводит к снижению производительности.
Кроме того, проще администрировать, отслеживать и устранять неполадки одним экземпляром, чем отдельными экземплярами.
Если вы разделите свои SQL-серверы на отдельные экземпляры (или, возможно, отдельные виртуальные машины), преимущества будут следующими:
Лучшее ограничение ресурсов. Регулятор ресурсов SQL 2008 - хорошее начало, но все же не столь детализированное, особенно когда дело доходит до ограничения ввода-вывода. С помощью виртуальных серверов вы можете регулировать ЦП, память и ввод-вывод на уровне виртуальной машины, тем самым давая вам возможность ограничивать ресурсы даже в более старых версиях SQL Server.
Упрощение повышения и понижения производительности. Если необходимо масштабировать одну виртуальную машину, например, если ее приложение внезапно станет более популярным, вы можете перенести ее на более мощную машину без простоя. С другой стороны, если вы используете несколько экземпляров, вам потребуется трудоемкая и трудоемкая установка.
Более гибкие окна простоя - если у вас есть все ваши базы данных в одной ОС (несколько экземпляров SQL), вам придется много координировать, чтобы сделать исправления для Windows. Если они разбиты на разных виртуальных гостей, вы можете вносить исправления в любое удобное время для каждого отдельного гостя (и соответствующих баз данных).
Лучшие пределы безопасности. Если на одном из серверов SQL Server возникнут проблемы, и стороннему лицу необходимо принять участие в устранении неполадок, вы можете предоставить им разрешения на уровне операционной системы, не беспокоясь о том, что они будут делать с другими серверами SQL, установленными на приставке.
Меньше проблем с совместимостью приложений. Некоторые приложения просто несовместимы с именованными экземплярами SQL Server.
Однако это не все единороги и радуги. Некоторые недостатки подхода с несколькими экземплярами и / или виртуальными серверами включают:
Я сделал веб-конференция о консолидации и виртуализации с экспертами по SQL Server Кевином Клайном и Роном Талмейджем. Однако для этого требуется регистрация.
Если вы хотите пойти по этому пути, я бы рекомендовал разделить экземпляры на разное оборудование, а не запускать отдельные экземпляры на одной машине. Если каждый из этих экземпляров намерен получить удар, я бы предпочел, чтобы все они забили один экземпляр, чем три экземпляра на одном ящике с дополнительными накладными расходами, связанными с поддержанием этих экземпляров.
Храните приложения в отдельных экземплярах. Таким образом, провайдеры не видят работу друг друга. Они, вероятно, предпочтут это, поскольку будут рассматривать свои приложения как конфиденциальную информацию. Кроме того, им могут потребоваться другие настройки в базе данных (например, сопоставление).
Обратной стороной этого является то, что экземплярам потребуется немного больше памяти.
Если какое-либо из приложений имеет большую нагрузку, его можно разместить на собственном сервере или, по крайней мере, на отдельном физически отдельном томе диска. Как правило, отдельные экземпляры предпочтительнее отдельных виртуальных машин для сервера базы данных.