Вскоре мы приступим к установке нашей установки Dynamics AX. Наша цель - обеспечить высокую доступность, и мы тесно сотрудничаем с нашими разработчиками.
Мы задали им вопрос о SQL и кластеризации Hyper-V. Они рекомендовали, чтобы при работе на полностью виртуализированной платформе не было реальной причины для виртуализации на уровне приложения (SQL) и что просто настраивала кластеризацию Hyper V в Windows Server и создавала SQL и все другие связанные виртуальные машины приложений на LUN для внутренней обработки. хранилище (в нашем случае HP P2000) и просто запуск файлов VHD в режиме высокой доступности с использованием CSV.
Это правда? Или мы должны кластеризовать SQL отдельно на уровне VHD?
Большое спасибо!
Они рекомендовали, чтобы при работе на полностью виртуализированной платформе не было реальной причины для виртуализации на уровне приложений.
Это потенциально опасный совет. Кластеризация Hyper-V обеспечивает высокую доступность в случае отказа оборудования - вот и все.
Гостевая кластеризация обеспечивает высокую доступность на уровне ОС в случае BSOD, сбоя обновления Windows, сбоя приложения или любого другого режима сбоя, не связанного с оборудованием. Это также позволяет исправлять эти системы и приложения без простоя приложения, что может быть важно для чего-то вроде установки Dynamics.
Существует множество конфигураций, в которых нет смысла добавлять гостевую кластеризацию при использовании кластеризации на уровне гипервизора, потому что вы можете восстанавливать из резервной копии в случае сбоя ОС, но сказать, что это так. никогда Это необходимо, поскольку кластеризация выполняется на гипервизоре, в лучшем случае это отрывочный совет. Они наиболее эффективны при использовании в тандеме.
Они рекомендовали, чтобы при работе на полностью виртуализированной платформе не было реальной причины для виртуализации на уровне приложений.
Некомпетентность. Так просто.
Это полностью зависит от ваших требований. И как ты это делаешь.
Стандартная кластеризация на уровне SQL Server является активной / пассивной, и при сбое другого экземпляр SQL Server будет перезапущен, что по-прежнему должно быть быстрее, чем перезапуск виртуальной машины.
Альтернативой SQL Server являются группы высокой доступности, которые имеют преимущество в виде двух хранилищ, поэтому, если исходный сервер удаляет файлы базы данных, другой компьютер может взять на себя управление. Общее хранилище не требуется.
Это действительно зависит от того, что вам нужно.
Это также зависит от исправления;) Когда вы исправляете виртуальную машину, содержащую SQL Server, это может быть простоем. Ты можешь это сделать? (плановые простои, период обслуживания).
Обычно «нет настоящей причины», как вы сказали, - это либо некомпетентность, либо плохое общение. Причин несколько. Вопрос в том, актуальны ли они для вас. Мы не можем этого решить. Но есть веские причины не использовать CSV и использовать реплицированное локальное хранилище для группы высокой доступности в SQL Server.