about NetApp

Некоторое время назад пришлось разбираться с некоей не совсем хорошо описанной и недостаточно хорошо известной функцией внутреннего устройства систем хранения NetApp под названием Mailbox Disk. Это, если в двух словах, некая специальная структура на жестких дисках, с помощью которых две ноды, входящих в HA-пару “классических”, 7-mode кластера сообщают друг другу о своем состоянии, и состоянии кластера в целом, независимо от работы основного метода взаимодействия – кабеля кластерного интерконнекта, и дополнительно к нему.

Упоминание mailbox disks вы можете встретить в выводе команд, показывающих системный статус кластера, и, как правило, в качестве mailbox disks называются диски, на которых располагается root volume системы.

У меня сложилось также впечатление, что mailbox disk это также “рудимент” времен давних, когда кластер у NetApp в целом работал через такие “псевдо-кворумные диски”, без кластерного интерконнекта вовсе, и остался в системе с тех давних пор, но, увы, это пока лишь гипотеза.

Тем не менее, в случае неисправности mailbox disks (их в кластере, если он не использует SyncMirror – по два у каждой ноды), перестает работать cluster takeover, даже при нормальной работе cluster interconnect cable, а это уже серьезно. К сожалению никаких подробных руководств как работать с mailbox disks, что делать в случае проблем с ними, у NetApp в документации нет (отсюда моя гипотеза о “рудиментарности”, то есть “остатках хвоста”, в существовании mailbox disk вообще). ??з maintenance mode его можно удалить, и тогда при перезагрузке контроллера он создастся заново. Но, в общем, это все.

Несмотря на то, что он называется mailbox disk, надо понимать, что это не “диск” как таковой, физически, а просто некая структура в служебных областях диска, не занимающая заметного места, служащая для сношения посредством дупла (с) для двух нод одного HA-кластера.

Вот вам перевод найденного в недрах NetApp KB документа NetApp Mailbox disks FAQ.

Что такое mailbox disk?

Структура, которая называется в Data ONTAP mailbox disks используется для хранения данных состояния кластера, которые должны сохраняться даже при его перезагрузке. Более конкретно это информация о состоянии кластера, состоянии зеркал и владельцах (ownership), которая читается контроллерами кластера во время процесса загрузки. Если контроллер обнаруживает локирование (SCSI Reservation) этих дисков, то вместо выполнения штатной загрузки он останавливается в состоянии "Waiting for giveback". Контроллер не переходит в обычное состояние операций, и подразумевает, что контроллер-партнер перехватил управление на себя (выполнил так называемый "кластерный тэйковер"). Он будет ожидать отдачи на партнере команды cf giveback для того, чтоб перейти в состояние нормальной загрузки. Если диски не локированы, то контроллер загружается обычным образом. Причина, по которой контроллеру нужно писать информацию в mailbox заключается в необходимости показать партнеру, что он жив и подключен к дискам. Также таким образом записывается информация о различных состояниях, например о состоянии зеркальных копий дисков, которые используются для того, чтобы определить какой из плексов зеркала содержит наиболее свежие данные. ??спользование mailbox это вторичный путь (первичный это кабель кластерного интерконнекта) для обеспечения работы heartbeat и предупреждения ситуации split-brain. Он также предупреждает ситуацию ненужного takeover, вызываемую какой-либо неисправностью кабеля кластерного интерконнекта.

Как система хранения выбирает диски под использование как mailbox disk?

В нормальной ситуации система хранения всегда выбирает диск parity и первый диск данных тома root vol для использования в качестве двух mailbox disk. Но если в какой-то момент времени, один из этих дисков откажет, то под mailbox будет использован второй диск parity (dparity disk в RAID-DP) тома root vol. [Пожалуйста, обратите на это предложение особое внимание. Если вы построили систему вопреки best practices с root vol на RAID-4 и на маленьком томе (так называемая "асимметричная схема") в можете столкнуться с ситуацией, когда один из дисков, который был для данного контроллера mailbox, вышел из строя, а dparity для данного тома нет. Это может привести к серьезным проблемам (невозможности кластерного takeover штатным образом, например). Это не шутка. Я как раз сейчас ковыряюсь с такой системой у клиента, "потерявшей" в результате такой ситуации (отказа диска в root vol на RAID-4) свои mailbox, и никак не желающей их видеть вновь, и которая при этом потеряла возможность штатного кластерного тэйковера, несмотря на исправный кабель интерконнекта. прим. Romx]

Диск mailbox может быть автоматически изменен силами DataONTAP, например, если parity disk тома root vol отказал. Data ONTAP назначает роль mailbox диску dparity тома root vol, как новому mailbox. Затем, когда новый диск заменяет сбойный и завершает ребилд, роль изменяется назад на диск parity и первый диск данных тома root vol.

Как контроллер работает с mailbox disks?

Контроллер системы хранения пишет на собственные mailbox disks. Он может читать информацию, записанную партнером на диски mailbox партнера, но никогда не пишет на mailbox-диски партнера. Таким образом, если даже операция локирования (SCSI3 Reservation) происходит на партнерских mailbox disk, то контроллер может по-прежнему читать с них. С помощью таки действий контроллер понимает, что контроллер-партнер жив и работает. Контроллер пытается получить доступ к дискам mailbox каждые 3-5 секунд. Если все "свои", "локальные" mailbox disks одновременно исчезают для системы, система сообщает о "permanent error of accessing mailbox disk" и уходит в panic.

Как Data ONTAP использует mailbox disks для оценки ситуации, в которой необходимо заблокировать работу кластерного файловера?

??спользуется "правило большинства" или "кворума". Допустим, половина членов кластера обеспечивает его стабильную работу. Если доступны менее половины членов кластера, иными словами, если больше половины отказало, то кластерные функции будут отключены (disabled). Таким образом, если одновременно один из двух mailboxes неисправен/недоступен/не отвечает, появится сообщение "mailbox uncertain" или "mailbox error detected", и работа кластерной функциональности будет отключена до тех пор, пока ситуация не будет разрешена. После того, как вышедшие из строя диски mailbox будут успешно заменены на исправные и RAID-группа будет восстановлена, работа кластера будет вновь включена (enabled).

Для системы, использующей SyncMirror, на каждой стороне будет 4 mailbox disks, 2 для локальной, и 2 для партнерской системы, если aggregate или том, содержащий mailbox disks зеркалирован с помощью syncmirror. Если один из них откажет, сообщение не будет показано, так как кворум не затронут. Если откажет два и более, то будет показано вышеописанное сообщение.