У меня есть небольшая виртуализированная среда, в которой размещен небольшой внутренний веб-сайт с серверной частью базы данных. В настоящее время я разделил свои веб-серверы и серверы баз данных на отдельные виртуальные машины, работающие на одном оборудовании.
Однако мне интересно, может ли лучшая стратегия состоять в том, чтобы консолидировать серверы баз данных dev / prod на одной и той же виртуальной машине, но с использованием отдельных экземпляров? Я использую зеркальное отображение SQL для избыточности, поэтому теоретически я бы перешел с 4 виртуальных машин SQL до двух. Преимущества заключались бы в меньшем количестве виртуальных машин для управления, менее сложном распределении ресурсов и гарантии того, что разработчик и продукт находятся в одном патче / службе. уровень упаковки.
Каковы недостатки этого подхода? Если я установлю экземпляр MSSQL по умолчанию на сервере Windows, могу ли я снова запустить установщик, чтобы создать второй (именованный) экземпляр и использовать его для другой среды? Наконец, можно ли было бы разместить разные экземпляры за отдельными IP-адресами, если бы я выделил их одной и той же виртуальной машине?
Вы, безусловно, можете настроить несколько экземпляров MSSQL и привязать их к отдельным IP-адресам. Однако я бы не рекомендовал это делать, если это делается с целью разделения производственной среды и среды разработки.
Я предпочитаю хранить разработку и производство на совершенно разных физических серверах / виртуальных машинах, чтобы никакие ресурсы разработки не потребляли производственные ресурсы. Нередко на машине разработчика есть неконтролируемые процессы / код, которые потребляют все и ставят коробку на колени. Это явно не подходит для производства. Время простоя среды разработки не должно влиять на производство.
Очевидно, что у вас все еще есть общий знаменатель на вашем хост-компьютере, поэтому все, что не так, все равно может уничтожить все, что у вас есть общие ресурсы на уровне виртуальной машины, но у вас, по крайней мере, не будет конкуренции внутри виртуальной машины.
Также существует [довольно типичный] случай, когда безопасность производственной ОС полностью отличается от безопасности разработки, и они являются взаимоисключающими. В этом случае вы вернетесь к другим серверам.
Редактировать:
Я понимаю, что воздействие невелико, это то, что вам придется взвесить для себя. Однако имейте в виду, что неэффективный запрос также может лишить сервер жизни. Если это не проблема для вашей производственной среды, тогда вам подойдет несколько экземпляров. Вероятно, вы захотите установить максимальные ограничения памяти для ваших экземпляров SQL, это поможет облегчить это.
Наличие меньшего количества виртуальных машин для управления - отличный стимул для уменьшения разрастания серверов! Использовать экземпляры MSSQL для отделения разработки от производственной среды довольно просто. Обычно это так же просто, как вы это описали - снова запустите программу установки, чтобы создать второй (названный) экземпляр.
Затем вы можете использовать SQL Server Configuration Manager для привязки именованного экземпляра к любому желаемому IP-адресу на сервере. Это под SQL Server Network Configuration >> Protocols for <INSTANCE NAME>.
К недостаткам этого подхода относятся стандартные проблемы с производительностью, хотя при низком трафике вы почти наверняка не столкнетесь с какими-либо проблемами.
Еще проще было бы использовать две базы данных в одном экземпляре SQL Server; это то, что я сделал бы, если бы у меня не было веских причин нуждаться в двух разных экземплярах.
В любом случае, да, вы можете легко иметь два экземпляра на одном (физическом / виртуальном) сервере; вам просто нужно снова запустить установку и указать, что вы хотите установить именованный экземпляр.