Архив за месяц: Апрель 2014

Как быстро кластер Nutanix восстанавливает целостность после отказа диска на узле?

В продолжение темы о том, что происходит при отказе диска или ноды кластера Nutanix, давайте посмотрим подробнее «сколько стоит» нам такая авария. В первую очередь нас будет интересовать время восстановления и объемы обработанного трафика.
Но прежде всего, давайте посмотрим как и что происходит при отказе диска в ноде или ноды целиком.
Если узел обнаруживает отказ диска, то корректирующие действия начинаются немедленно.
Если кластер обнаруживает потерю одного из узлов, он берет таймаут на 60 секунд, и если за это время не восстановилась работа узла (читай, не ответил CVM), то начинаются действия по исправлению ситуации.

В ходе этих корректирующих процедур, Nutanix Cluster для трафика внутренней репликации выделяется 25% общей ширины канала межнодовой сети кластера, чтобы эта процедура минимально влияла на нормальную работу и производительность системы. Таким образом, на процесс репликации внутри системы выделяется четверть доступной полосы (обычно это 10G Ethernet).

Когда кластер принимает решение о начале восстановления после отказа диска в ноде или ноды целиком, то первым делом начинается сканирование и проверка метаданных с тем, чтобы определить, какая часть информации затронута. Эта работа распределяется путем механизма map-reduce между всеми узлами кластера.

Задача репликации данных добавляется в очередь кластерных фоновых процессов, и начинает выполняться узлами, как только появляется возможность, в рамках выделенного лимита ресурсов для фоновых задач. Так как задача при этом распределена между всеми узлами кластера, то чем больше узлов в кластере, тем быстрее происходит ребилд. По умолчанию, можно занять 10 задач в секунду из 25 возможных для процесса внутренней репликации. Задача внутренней репликации имеет приоритет выше, чем auto-tiering.
Таким образом, в 4-нодовом кластере мы имеем 40 параллельных задач репликации. Данные в кластере перемещаются блоками, которые называются extent groups, размером 4MB. Следовательно, в кластере мы можем достичь объема копирования в данный момент времени репликации, равный 40х4MB=160MB, в идеальном случае.
Так как данные равномерно распределены по узлам кластера, и полоса, доступная на диск для репликации состяавляет 75MB/s (сюда входит и чтение и запись), то максимальная полоса составляет 75MB/s * число дисков, что значительно выше, чем 160MB/s. Таким образом, мы можем ожидать, что максимальная полоса репликации будет составлять 160MB/s.
Фактически, так происходит в кластере то, что в RAID называется RAID-rebuild, и для больших групп RAID-5 или RAID-6 может занимать дни.

Ну и, для иллюстрации, видео о том, как происходит процесс восстановления состояния кластера в результате потери 1TB SATA диска с 24GB данных на нем.
Рекомендую, для понятности, включить HD (YouTube теперь включает low-resolution по умолчанию для проигрывания видео), в этом ускоренном вдвое видео видно, что происходит с сетевым трафиком и загрузкой процессора в ходе такой процедуры.
Отказ диска был имитирован из консоли менеджмента.

Как вы видите, через 3 минуты рабочее состояние кластера было восстановлено и репликация данных полностью завершилось, при этом штатная работа по обслуживанию VM на кластере в этот период продолжалась.

Отказ узла кластера 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 для предсказания возможных отказов (в будущем мы остановимся на этой операции более подробно).