Отказ узла кластера Nutanix. Что увидит пользователь?

После небольшого перерыва, блог возвращается к регулярным публикациям.
В настоящий момент мы готовим перевод основополагающего популярного труда по общедоступной архитектуре Nutanix, так называемую Nutanix Bible, которую постепенно пишет блоггер Steve Poitras. Вскоре мы переведем и выложим ее целиком, а пока — отдельные фрагменты.

Надежность и устойчивость — ключевые понятия, если не вовсе самое важное для Nutanix Distributed File System (NDFS). Будучи распределенной файловой системой NDFS создана обрабатывать ситуации с ошибками компонентов, сервисов и контроллеров (CVM) системы.
Кластер Nutanix автоматически выбирает оптимальный путь между хостом гипервизора и данными гостевой VM. Это называется «automatic path direction», или Autopath.

Когда данные расположены локально, то оптимальный путь всегда лежит через локальный CVM к локальным устройствам хранения. Однако, в некоторых ситуациях, данные VM не лежат на локальном для нее хранилище, например такое получается, если VM недавно мигрировала с хоста на хост. В этих случаях локальный CVM перенаправляет запросы на чтение через сеть на хранилище другого хоста.

Nutanix Autopath также непрерывно мониторит статус всех CVM в кластере. Если какой-то из процессов не ответил два и более раза за 30-секундный интервал, то другая CVM перенаправляет путь к данным на хранилище соответствующего хоста на другой CVM. Для предотвращения непрерывного переключения между CVM, путь к данным не меняется на прежний, до тех пор, пока исходная CVM не продемонстрирует стабильную работу в течение по меньшей мере 30 секунд.
«Отказ» CVM может включать в себя ручное выключение CVM пользователем, обновление ПО, или любое другое событие, в ходе которого CVM перестает работать и отвечать нормально. В любых этих случаях autopathing прозрачно переключает трафик к дискам на другой CVM в кластере.
Гипервизор и CVM взаимодействуют по внуренней частной сети, через выделенный виртуальный коммутатор. Это означает, что весь трафик данных к дискам идет через внутренние IP-адреса CVM. Внешний IP-адрес CVM используется для удаленой репликации и для коммуникации между CVM.
 
null
 
В случае отказа локального CVM, локальные адреса, ранее используемые локальным CVM, становятся недоступными. В этом случае, NDFS автоматически определяет отказ и перенаправляет трафик хранилища на другой CVM в кластере по его сети. Этот ре-роутинг пути происходит прозрачно для гипервизора и для VM, выполняющихся на хосте.

Это означает, что даже если CVM выключен, VM хоста по прежнему будут иметь возможность проводить операции ввода-вывода. NDFS также предпринимает попытки самостоятельно исправить ситуацию, так, обнаружив выключенный CVM, она попытается перезагрузить или включить выключенный локальный CVM. Как только локальный CVM вернется в строй и снова будет доступен, трафик прозрачно будет переброшен назад, и начнет обслуживаться этим локальным CVM.
NDFS использует так называемый replication factor (RF) и контрольные суммы для того, чтобы быть уверенным в целостности и доступности данных при отказе или повреждении узла кластера или дисков. В случае отказа узла или его дисков, данные повторно реплицируются по всем узлам кластера, сохраняя заданную величину RF; это носит название re-protection. Re-protection может случиться после того, как CVM перестанет работать.
Ниже на рисунке показано, как это выглядит для отказавшей CVM:
 

 
Что при этом заметит пользователь?
В ходе процесса переключения, хост с отказавшим CVM может сообщить о недоступности датастора. Гостевые VM на этом хосте могут выглядеть «подвисшими» до тех пор, пока путь к хранилищу не будет восстановлен. Обычно эта пауза составляет около 15 секунд, и заметна по резкому пику задержек в операциях. Хотя основная копия данных гостевой VM будет недоступна, так как она подключена к отказавшему CVM, данные останутся доступными, так как остаются доступными их реплики. Как только перенаправление пути будет завершено, VM продолжит операции чтения и записи.
Производителность может несколько снизиться, так как ввод-вывод пойдет через сеть, вместо прямого доступа через внутренний виртуальный коммутатор. Однако, так как весь трафик идет через сеть 10GbE, для большинства нагрузок это не будет заметным для пользователей.
Описанное поведение характеризует архитектуру Nutanix как устойчивую к внутренним отказам, позволяя гостевым VM продолжать работать даже в условиях отказа локального хранилища. В иных системах, при отказе хранилища, ошибке работы или kernel panic, гостевая VM и приложения принуждены будут рестартовать на другом хосте, вызывая серьзные перебои с доступом к приложениям.

[Важное добавление] Начиная с NOS 3.5.3.1 пауза в работе VM практически неуловима для приложений.

Что случится, если откажет другой CVM?
Отказ второго CVM будет иметь то же влияние на VM на другом хосте, чтио означает, что уже два хоста начнут посылать запросы операций ввода-вывода по сети. Более важно, однако, что это дополнительный риск для данных гостевых VM. С двумя отказавшими CVM, недоступными становятся уже два набора локальных физических дисков. В кластере с replication factor, равным двум, появляется риск того, что некоторые экстенты данных VM станут недоступными, по крайней мере до тех пор, пока один из CVM не возобновит работу.

Однако, если поседовательный отказ произойдет уже после того, как завершится процесс новой репликации данных или re-protection, то это будет означать риск тот же, что и при отказе одного узла. Вы можете продолжать терять узлы кластера Nutanix, если после одного из отказов успевает отработать re-protection, и до тех пор, пока на узлах есть запас места на дисках под данные, которые перемещает re-protection.

Отказ загрузочного диска
Каждый CVM загружается с SATA-SSD. При работе кластера этот диск также держит логи компонентов и прочие сопутствующие файлы. Отказ этого загрузочного диска вызовет также и отказ CVM. Так как хост не имеет доступа к загрузочному диску напрямую, то гостевые VM при этом продолжают работать. В этом случае NDFS Autopath будет также перенаправлять путь трафика к дискам через другой CVM. Одновременно с этим, NDFS продолжает непрервывно мониторить состояние SSD для предсказания возможных отказов (в будущем мы остановимся на этой операции более подробно).

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *