Вскоре мы переходим к кластеру Hyper-V с лицензированием центра обработки данных и при необходимости сможем развернуть несколько виртуальных серверов. У нас около восьми приложений, использующих базы данных SQL. Есть ли какие-либо преимущества / недостатки в настройке отдельного SQL-сервера для каждого приложения по сравнению с тем, чтобы все работало на одном большом SQL-сервере?
Тот факт, что это на HyperV, в большинстве случаев является отвлекающим маневром. Подходите к нему с теми же критериями, которые вы использовали бы для размещения разных баз данных SQL на одном или разных экземплярах на реальном оборудовании.
Пределы производительности системы - память, ввод-вывод, ЦП, потоки / процессы и т. Д. Если объединение баз данных приведет к снижению производительности, масштабируйтесь на большее количество экземпляров на другом оборудовании (или с виртуальной машиной, если возможно, увеличьте масштаб вашего подготовленного оборудования).
Другие критерии, такие как окна резервного копирования, запланированные задания, кластеризация, которая обычно является продолжением вышеперечисленного. Безопасность обычно не вызывает беспокойства, если у вас нет разных баз данных, которым требуется аутентификация из разных недоверенных доменов.
На ваш комментарий: если вы сейчас делаете это со всеми на одном экземпляре и не имея проблемпродолжайте делать это на виртуальной машине правильного размера. Добавление дополнительных виртуальных машин просто потребует больше ресурсов для дополнительных экземпляров ОС. Какого рода обслуживание одной базы данных влияет на другие базы данных? Если вы не делаете что-то вроде повторной индексации в одной базе данных, которая влияет на производительность в других системах, и у них нет перекрывающихся окон обслуживания или периодов допустимого снижения производительности. Это то, что я имел в виду, говоря, что единственная реальная причина для этого - соображения производительности. В противном случае попробуйте закрепиться.