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