shared hotspare для mdadm

    (сомневался сюда писать или в системное администрирование)

    Я обнаружил, что в интернете очень мало (и не очень внятно) объяснено, как mdadm работает с общими (глобальными) дисками горячей подмены. В заметке я опишу, что это такое, и объясню, почему shared hotspare не отмечены в /proc/mdstat как общие, а вместо этого выглядят как вполне себе локальные.

    Что такое hot-spare?


    (Я пишу не для новичков, так что галопом по европам)
    Если массив обладает избыточностью и один из его дисков вышел из строя, то существует возможность восстановить избыточную информацию на резервный диск. Если диск добавляется в массив руками (админу пришло письмо о сбое, он прочитал письмо, проснулся/оделся, приехал на работу, вынул сбойный диск, вставил запасной, добавил его в массив, дал команду на восстановление избыточности), то такой диск называется cold-spare. Просто «запасной диск».

    Если же в сервере есть простаивающий диск, на который осуществляется восстановление избыточности сразу после сбоя любого из дисков массива, то такой диск называется hot-spare. Главное достоинство — оно отребилдится (восстановит избыточность) даже если админ письмо прозевал или не успел вовремя приехать.

    Локальные hot-spare

    Обычно запасной диск добавляется для массива, то есть если в массиве сбой, то его резервный диск и используется. Если сбой происходит в соседнем массиве, то hot-spare из «чужого» массива не используется.

    Это на самом деле логично — если у нас стоит выбор — использовать hot-spare для восстановления избыточности системного раздела или раздела с данными, то надо восстанавливать избыточность раздела с данными. А если системный раздел уже «занял» hot-spare, то будет бяка. Более того, некоторые производители предлагают 1EE hotspare, в которой резервный диск используется и для хранения данных (пустое место «размазано» между дисками массива, обеспечивая возможность быстрого ребилда и увеличивая производительность в нормальном режиме).

    Глобальные (общие) hot-spare

    Однако, бывает так, что массивов с данными много. И им всем нужны hot-spare диски. Но дисков жалко. И тогда возникает желание иметь «общий» диск, который может быть использован для любого из массивов (а ещё лучше 2-3 таких диска).

    Это было вступление. Теперь переходим к сути вопроса.

    linux md

    mdadm (ядерный модуль в DM-стеке) не поддерживает shared hot-spare. Диск может быть добавлен как hot-spare только в конкретный массив.

    Но mdadm поддерживает!

    Именно так. mdadm поддерживает, ядерный модуль — нет. Mdadm реализует общий hot-spare методом «перекинуть hotspare с одного массива на другой, повреждённый».

    Другими словами, для того, чтобы это сработало, должен быть запущен mdadm в режиме -F (follow). Он же обычно присылает сообщения на почту о проблемах рейда. Большинство современных дистрибутивов его запускают (если есть массивы), но, важно понимать, что он обслуживает только те массивы, которые были собраны из mdadm.conf, а не собранные ручками. (Да-да, тут нас ждёт подстава).

    spare-group

    Для возможности распределять диски между разными массивами есть понятие spare-group, то есть группа, в пределах которой возможно перекидывание дисков. Таких групп может быть много — и hot-spare переносятся только между ними.

    Как легко понять из вышенаписанного про mdadm/linux md, в /proc/mdstat нет и не может быть ничего про spare-group. Потому что это личные мысли и соображения mdadm'а, а ядро про это ни сном, ни духом (файлы-то в /proc создаются модулями ядра...).

    Таким образом, обеспечивать shared hot-spare можно только с с помощью mdadm. Тут два варианта: если группа указана для массива, собирающегося при загрузке (/etc/mdadm/mdadm.conf), то там можно указать hot-spare, примерно так:

    ARRAY /dev/md1 level=raid1 num-devices=2 metadata=1.2 spares=1 spare-group=myhostparegroupname name=server:1 UUID=18219495:03fda335:3f1ad1ee:a5f5cd44
    devices=/dev/sda,/dev/sdb,/dev/sdc
    ARRAY /dev/md2 level=raid1 num-devices=2 metadata=1.2 spare-group=myhostparegroupname name=server:2 UUID=18219495:03fda335:3f1ad1ee:a5f5cd45
    devices=/dev/sdd,/dev/sde

    (сразу отвечаю на вопрос, где столько умных слов взять — mdadm --detail --scan --verbose)

    Дописано по сравнению с выводом mdadm тут только spare-group. Обратите внимание — во втором массиве НЕТ hot-spare, однако, т.к. группа указана, то в случае сбоя будет использоваться диск из другого массива с той же самой группой. В нашем случае это будет /dev/md1.

    Разумеется, всё это произойдёт, только если у нас есть запущенный в режиме -F mdadm. В debian он в выводе ps выглядит так:
    /sbin/mdadm --monitor --pid-file /var/run/mdadm/monitor.pid --daemonise --scan --syslog
    


    Самих групп при этом на одной системе может быть несколько.

    Кстати, тут есть мелкая гадость: при вызове mdadm с --detail упоминания о spare-groups не будет, их нужно будет дописывать самим.

    Local && global hotspare


    А вот тут, увы, йок. Насколько я знаю, mdadm не поддерживает одновременно и локальные (которые будут принадлежать только одному массиву) и общие hotspare. Если есть два массива с одним spare-group, то все hot-spare из одного массива могут быть использованы на благо другого.

    Сценарий не такой редкий, как кажется. Вот простенькая топология:

    SYS_ARRAY
    DATA_ARRAY
    2 hot-spare

    Логично было бы один hot-spare сделать принадлежащим только DATA_ARRAY, а второй сделать общим, чтобы использовался и как резерв для SYS_ARRAY, и как «второй уровень резерва» для DATA_ARRAY.

    Увы, увы, увы, этого нет (если меня разубедят в комментариях, я буду очень рад).
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 28

      0
      Не в давался раньше в тонкости настройки mdadm, т.к. обычно использовал железный рейд и узнать что mdadm тоже может shared hot-spare очень полезно. Спасибо!
      Это третья статья из серии «я бы продонейтил».
        0
        Мы тоже до определённого момента использовали железные рейды. Больше — спасибо, не надо.
          0
          Я могу конечно придумать, почему лучше пользоваться софтовым рейдом и почему плох железный.
          Но хотелось бы услышать ваш реальный опыт до «определённого момента» и после.
            0
            Сдох контроллер, а их уже не выпускают, а резервные мы не купили.
              +3
              Во-1х, воскрешать программный проще — ты знаешь как он функционирует, и можно спокойно снять образа дисков и восстановить данные, не полагаясь на метод втыка или какие-то левые проприетарные софтины которые хз дадут ли результат

              Во-2х, ядро ушло в панику, перед этим сбросив кеш. На программном рейде я получил рассинхронизованное зеркало, которое после перезагрузки сребилдилось и всё.
              На аппаратном зеркале я получил кашу на диске, откуда долго и нудно выковыривал нужные данные.

              В-3их, вот коммент выше — аппаратные имеют привычку пропадать с горизонта, в случае помирания — влип в жир ногами по полной программе.

              В-4ых, многие «аппаратные» это выносной калькулятор, без драйверов бесполезная вещь.
                +2
                Одно из хранилищ облака — два сбоя рейда до запуска в продакт (адаптек пятой серии), один сбой в продакте. Второй рейд (собирали второе хранилище) — просто феерическое количество глюков.

                Софтовые рейды — опыта сбоев не было (используется на остальных хранилищах облака).

                Мне даже трудно скзать про «реальный опыт» — какой может быть реальный опыт, если проблем не возникает? :)
                  0
                  Спасибо. Всем. За развёрнутые мнения.

                  Сам пользуюсь и софтовыми и аппаратными решениями. Не являюсь сторонником какого-то одного лагеря =)

                  Всё-таки про плюсы аппаратного решения:

                  — В жёстких требованиях по производительности выигрывает всё-таки честный аппаратный RAID на быстрых винтах. Покрайней мере наш отдел билинга так считает.

                  — Vmware ESXi умеет ставится только на аппаратный RAID. Софтварный RAID в инсталяторе не предусмотрен.
                    0
                    А нафига VMWare вообще рейд? Не знаю, как у ESXi, а XCP позволяет умигрировать виртуальные машины с узла, на котором умер жёсткий диск, так что мы вполне себе живём без рейдов на хостах виртуализации. За это время сдохло два диска — ни одна виртуальная машина не пострадала.
                      0
                      сам хост esxi вообще ставится на флешку, и отказоустойчивость там вообще не нужна.
                      ну из локальных сторов он умеет и отдельные диски, и аппаратные рейды. но это только в качестве полумеры, все равно штатно оно расчитано на работу с внешним стором.
              0
              Получается что этот способ не работает если массив был собран модулем при загрузке ядра (поиск/автоопредление)?
              А для того чтобы получить hot-spare для root раздела нужно массив собирать руками в initramfs?
                0
                Или достаточно запустить массив модулем, но описать его в mdadm.conf чтобы демон потом за ним следил?
                  0
                  Нужно чтобы массив был запущен на момент чтения mdadm'ом конфига. Хотя, наверное, --scan опция включит слежение и за выключенными массивами.

                  Я говорил про ситуацию «собрали ручками после загрузки» — в таких случаях монитор нужно перезапустить (или запустить свой).
                0
                Одно плохо в софт-рейде.
                Варианты:
                1. Сдох контроллер диска и завесил в момент прерывания ядро
                2. Побилась пластина, но не выдает ошибок, а просто дико тормозит и плюет местами левыми данными
                В них он не спасает.

                Доходит до того что не получается исключить сбойнувший винт из массива, т.к. у mdadm срывает крышу, потому как глючит пол системы из-за сбоя.
                Лечится только загрузкой rescuecd и ребилдом без монтирования.
                  +1
                  1. Решается адекватными контроллерами (например, SAS контроллер и SAS корзина с SATA дисками)
                  2. Для кого SCT придумали, а? Или вы про проблемы desktop'ных винтов? Так не используйте их в рейде. Для рейдов есть нормальные винты, у которых с STC всё хорошо.

                  Куда веселее, когда срывает крышу у фирмвари железного рейда и он херит содержимое write cache'а.
                    +1
                    1. Решается нормальными RAID-контроллерами
                    2. Seagate Constellation, WD RE 4

                    Для SAS использовать софтовый рейд — кощунство.
                      0
                      А теперь давайте без религиозно-мистических интонаций, какие бонусы даёт использование аппаратного рейда по сравнению с софтовым в случае SAS? Я знаю только один — bus saturation для PCI-E, но мой опыт говорит, что его в продакте не достигнуть (т.к. там идут рандомные операции).

                      Когда вы говорите «нормальные рейд-контроллеры», то мне даже становится странно. Я знаю, что из вендоров остались Arcea, Adaptek и LSI. Кто из них по-вашему мнению «нормальный»?

                      Я ни разу не встречал указанной проблемы (с дисками, которые бы блокировали работу mdadm). Точнее, встречал. На одном из тупых адаптековских HBA, вставление в хотплажную корзину винта на две минуты фризило систему — забраковали.
                        0
                        Сам недавно столкнулся с такой проблемой на Intel SR1600UR и SATA дисками WD RE4.
                        Решилось только rescuecd, в горячем режиме mdadm не работал.

                        Если вы не видите преимуществ хард-контроллеров, то о чем можно еще говорить?
                        BBU, read/write cache, оптимизация очередей…
                        Действительно какие преимущества…

                        То что у ваш опыт еще не включает таких случаев не значит что их не бывает.
                          +1
                          SATA напрямую были воткнуты? Вот тут, я думаю, и причина. В случае SAS инфраструктуры отказ конкретного диска совершенно ни на что не влияет. В крайнем случае, его можно отключить средствами backplane'а.

                          Оптимизацию очередей линукс делает куда лучше аппаратных рейдов (BIO coalesing — в linux magazine про это довольно много писали), read cache у нас в системах хранения такой, что хардварные рейды уписаются от зависти (слабо аппаратный рейд с сотней гигов кеша найти?), с write cache'ем — у нас kyuubei пока не задеплоен, хотя планируется — и там с этой «проблемой» более чем хорошо.

                          BBU прекрасно заменяется микроупсами для сервера.

                          Итак, помимо этих «преимуществ», что ещё нам хорошего могут предложить аппаратные рейды? Ах, да, лимит на количество иопсов (тот же адаптек официально признаёт, что больше 10к IOPS они не выдержат).
                            0
                            Есть платформа с HS, та же картина.
                              0
                              М… я такого не видел. Причём не только у себя в облаке (допустим, несколько сотен жёстких дисков не репрезентативная выборка), но и по дата-центрам (тут уж выборка точно репрезентативная). В указанном списке я не работал с Intel'ом, ок, спасибо, учту на будущее (viva supermicro?)
                                0
                                Supermicro в принципе viva.
                                Intel еще те платформы, через 5 штук танцы с бубном.
                                HP еще люблю.
                              0
                              опять же не могу отгуглить kyuubei
                                0
                                kyuubei?
                              0
                              А HP SmartArray чем «ненормальные» контроллеры? Да и делловские PERC'и вроде тоже ничего. «кашицу» на диске я получал как раз на LSI.
                            0
                            Куда веселее когда он херит содержимое write cache, и записывает полученную кашицу на все диски зеркала.
                              0
                              что такое STC?
                                0
                                SCT:http://www.csc.liv.ac.uk/~greg/projects/erc/
                                  0
                                  ok, спасибо

                          Only users with full accounts can post comments. Log in, please.