Що таке mailbox disk, 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?

Як Data ONTAP використовує mailbox disks для оцінки ситуації, в якій необхідно заблокувати роботу кластерного файловера?

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

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