Я собираюсь создать кластер Linux из 5 физических серверных узлов (возможно, позже будут добавлены дополнительные узлы).
Одно из решений, которое осталось принять, - использовать ли программный RAID1 или аппаратный RAID1 + BBU.
Программный RAID - это решение, с которым я хорошо знаком (я управляю несколькими серверами уже 15 лет и знаю, как работают инструменты). У меня никогда не было серьезных проблем с этим (в основном выходил из строя только жесткий диск). Это причины, по которым Я предпочитаю программный RAID.
Что мне не нравится в аппаратном RAID, так это несовместимость между поставщиками контроллеров и отсутствие у меня опыта работы с ними: разные варианты конфигурации, разные методы мониторинга, разные служебные программы - плохое чувство для создания кластерной системы.
Я знаю, что при использовании BBU аппаратный RAID может быть быстро и надежный (запись через кеш). Однако, поскольку все данные будут храниться в кластере с высокой степенью избыточности, моя идея состоит в том, чтобы использовать программный RAID1 и отключить барьеры в файловой системе для увеличения производительности записи. Я ожидаю, что это приведет к аналогичная производительность как у аппаратного RAID1. Конечно, я рискую потерять данные из-за изменчивого кеша записи, однако, IMHO, это в любом случае должно обрабатываться механизмами кластеризации (вся машина должна иметь возможность восстанавливать данные с других узлов после сбоя).
Меня не беспокоят ресурсы ЦП, необходимые для реализации программного RAID.
Верно ли мое предположение или я упускаю важную деталь, которая поможет мне сделать правильный выбор?
Я предпочитаю программный RAID аппаратному RAID на отдельных серверах, потому что аппаратный RAID заставляет администратора принимать меры против аппаратного сбоя RAID-контроллера. Обычно это требует наличия запасных RAID-контроллеров и их регулярного тестирования.
Однако в вашей настройке я предполагаю, что избыточность находится на уровне узла, а не на уровне диска. Если узел выходит из строя по какой-либо причине (ЦП, источник питания, контроллер рейда и т. Д.), Этот узел выйдет из кластера и будет заменен как можно скорее новым или отремонтированным узлом, а затем данные будут восстановлены из кластера, а не из рейд. Сказав это, вопрос в том, нужен ли вам RAID вообще!
Вы могли бы сказать: «Моя база данных в основном читается, RAID 1 примерно удвоит пропускную способность, так как чтение может быть распределено между обоими дисками». Но имейте в виду, что сбой диска с последующей заменой этого диска и перестройкой RAID снижает скорость чтения на этом узле временно до уровня одного диска. Если ваша база данных не может разумно распределить трафик между неравными узлами, передавая меньше трафика медленным узлам, то вся нагрузка, которую база данных может обработать, упадет до половины от нормального значения! Это может вынудить вас в любом случае полностью исключить узел с отказавшим диском из базы данных, пока он занят восстановлением внутреннего RAID. Но это делает RAID практически бесполезным.
Альтернативный вариант - не использовать какой-либо RAID, но позволить любому узлу присоединиться к базе данных дважды, по одному разу для каждого диска. Это увеличивает нагрузку на процессор, но если диск является вашим ограничивающим фактором, то кого волнует время процессора? И если диск выходит из строя, этот конкретный полуузел переходит в автономный режим и снова подключается после замены диска. Таким образом, нагрузка будет распределена между всеми дисками.
Если у вас высокая нагрузка записи, решение с отдельным диском даст вам вдвое большую пропускную способность записи, чем RAID 1.
Таким образом, единственная причина по-прежнему думать о BBU заключается в том, что ваши требования к задержке настолько узкие, что вы не можете дождаться, пока данные физически отправятся на диск. В случае сбоя питания BBU обеспечат запись данных. Но есть альтернативы, а именно модули кеш-памяти SSD, такие как dm-cache или bcache. В режиме обратной записи они сначала записывают данные на SSD, что намного быстрее, чем запись на диск, а затем уже фиксируют запись. Даже после сбоя питания они правильно прочитают блоки с SSD. dm-cache и bcache поставляются со всеми последними ядрами Linux, а небольшой (например, 64 или 128 ГБ) SSD серверного уровня (!!) по-прежнему дешевле, чем RAID-контроллер BBU.