Почему ваш кластер SQL Server не должен быть виртуализирован
Один из часто задаваемых вопросов относительно кластеров SQL Server: «Могу ли я создавать кластеры SQL Server в VMware и Hyper-V?»
В теории да. В статье базы знаний Microsoft о поддержке виртуализации SQL Server говорится, что они будут поддерживать вас, если вы используете конфигурации, перечисленные в Программе проверки виртуализации серверов (SVVP).
Но настоящий вопрос не в том, поддерживает ли Microsoft виртуальные кластеры SQL Server.
Вопрос в том, сможете ли вы это поддержать.
Кластеры, как правило, внедряется, потому что бизнес хочет большей доступности. Более высокая доступность означает более быстрое устранение неполадок, когда система не работает. Нам нужно как можно быстрее восстановить работоспособность системы. Добраться туда обычно означает уменьшить количество сложностей; сложные системы занимают больше времени для устранения неполадок.
Добавление виртуализации (что также означает общее хранилище) значительно усложняет поиск и устранение неисправностей. Если бизнесу нужен высокодоступный SQL Server, задайте себе следующие вопросы перед виртуализацией кластера SQL Server:
- У вас хорошие отношения между SQL Server, хранилищем и сетевыми командами?
- Все ли команды имеют доступ только для чтения к инструментам друг друга, чтобы ускорить устранение неполадок?
- Все ли команды имеют доступ к списку вызовов для всех остальных команд и чувствуют ли они себя комфортно, звоня им?
- Есть ли у вас успешно практикуемый, хорошо документированный контрольный список для устранения неполадок в работе SQL Server?
- Есть ли в вашей компании хорошо отлаженный процесс контроля изменений во избежание неожиданностей?
- Есть ли у вас идентичная среда для тестирования изменений конфигурации и исправлений перед запуском?
- Если ответ на любой из этих вопросов - нет, подумайте над тем, как отточить свои процессы, прежде чем добавлять сложность.
Но предприниматели заставляют меня это делать!
Они заставляют вас делать это, потому что вы четко не изложили свои опасения по поводу предпринимательского риска. Покажите бизнес-менеджерам этот же список вопросов. Поговорите с ними о том, что каждый ответ означает для бизнеса. Был ли недавний перерыв в работе между командами? Поднимите это и напомните бизнесу о том, насколько болезненным был этот сеанс устранения неполадок. Проблемы будут только ухудшаться при виртуализации.
Чтобы по-настоящему разобраться в этом вопросе, я предпочитаю интерактивное обсуждение процесса устранения неполадок для физического кластера по сравнению с виртуальным кластером. Покажите все части инфраструктуры и укажите, какие группы владеют какими частями. Каждая дополнительная команда означает больше времени для устранения неполадок.
Как только бизнес соглашается с этим повышенным риском, тогда все в одной команде. Им комфортно с дополнительным риском, на который вы идете, и вам удобно, что вы не виноваты, когда что-то идет не так. И когда у них что-то идет не так, они проведут встречу по итогам, объясняя сбой и время, потраченное на устранение неполадок. Если будет происходить перекладывание вины между командой приложения, администраторами баз данных SQL Server, сетевыми администраторами, администраторами виртуализации и системными администраторами, документируйте это и делитесь (по-дружески) с руководством. Оно может передумать, когда придет время развернуть следующий кластер SQL Server.