Когда я впервые настроил кластер Hyper-V 2012 из 2 узлов, отказоустойчивость была практически мгновенной. У меня была виртуальная машина Sql Server 2012 (на Win2012) с выделенным ей объемом оперативной памяти 8 ГБ. Я мог переключить узел, на котором он находился, и он перешел бы на другой узел, не разрывая моего соединения Sql.
Затем я добавил вторую виртуальную машину в кластер (клон первой виртуальной машины), также с 8 ГБ. Теперь переключение занимает пару секунд, и мое соединение SQL сбрасывается. Является ли это фактором объема оперативной памяти, которую нужно переместить? Влияет ли на это сеть? Является ли это скоростью кворумного диска?
В моем случае оба узла подключены к одному DAS, а файлы VM находятся на CSV. Я бы ожидал, что диски не являются фактором, поскольку ничего не нужно перемещать. Все должно быть в RAM, верно? Так что с увеличением RAM производительность отказоустойчивости снижается?
решение1
Оглядываясь назад, я думаю, что я должен был знать. Ответ состоит из двух частей, потому что, по моему мнению, есть запланированный отказ и «реальный»/незапланированный отказ — и запланированный отказ не считается.
Плановый отказ
Плановый отказ на самом деле заключается в том, что система кластеризации просто опустошает узел, а затем перезагружает его для вас. Поэтому, когда вы напрямую перезагружаете узел через RDP или «Остановить службу кластера» в графическом интерфейсе приложения кластеризации, первое, что происходит, — это отключение виртуальной машины в режиме Live Migrated. Поскольку вы на самом деле просто выполняете живую миграцию виртуальных машин, время, которое это займет, зависит от того, что нужно перенести, и от сетевого подключения. Если у вас сетевой адаптер 1 Гбит, это займет некоторое время (~118 МБ/с). Чем больше оперативной памяти у ваших виртуальных машин, темВам больше подойдут более быстрые сетевые карты.
Реальное аварийное переключение
Незапланированный/"реальный" отказ происходит, когда вы отключаете машину. В этом случае кластерная система автоматически запускает ВМ на другом узле. Поведение для внешнего мира такое же, как если бы вы перезагрузили ВМ. Для ВМ это то же самое, как если бы вы "выключили" ее, а затем снова запустили. Поэтому "реальный" отказ всегда будет зависеть от того, сколько времени потребуется вашим ВМ для загрузки.
Тангенс
Это меня разочаровывает, концептуально, потому что мне кажется, что все разговоры о кластеризации в сети предполагают, что ("жесткий") отказ узла скрыт системой кластеризации --- предполагается, что сервисы никогда не выходили из строя. Вероятно, это распространяется тем фактом, что все веб-страницы, которые я помню, читали, тестировали отказ кластера в программном обеспечении (запланированный отказ). Так что все, что они на самом деле делают, это доказывают, что Live Migration работает так, как рекламируется (никакого простоя с точки зрения клиента).
Моя главная ошибка заключалась в непонимании самого отказа. Помимо концепции горячего/теплого/холодного резервного сервера, где автоматический отказ происходит на горячем сервере, есть еще и горячий/теплый/холодный отказ. Как уже упоминалосьздесь, горячее аварийное переключение происходит мгновенно, теплое аварийное переключение измеряется в секундах, а холодное аварийное переключение измеряется в минутах. Я был наивен, предполагая, что все автоматические отказы являются «горячими». Думаю, я ожидал какой-то магии с ОЗУ, когда кластер будет обновлять копию ОЗУ виртуальной машины на другом узле — что-то вроде доставки журнала транзакций с SQL Server. Но для этого потребовался бы канал связи между машинами, который был бы по крайней мере таким же быстрым, как ОЗУ, чтобы гарантировать его работу.