Аппаратные средства RAID1 предлагают значительные преимущества для RAID S/W в вычислительном кластере, это очень избыточно?
Я собираюсь настроить кластер Linux 5 узлов физического сервера (больше узлов, которые будут добавлены позже, вероятно).
- кластером будет управлять Proxmox (и да, он работает в программном обеспечении RAID),
- совместно используемая память будет реализована с Gluster в избыточной установке с каждым физическим сервером, содержащим кирпич (так, данные будут избыточно доступны от всех машин),
- Кластер Percona XtraDB будет использоваться в качестве основной, мультиосновной базы данных - снова с данными, совместно использованными всеми реальными машинами
- каждая машина будет иметь два жестких диска приблизительно 2-3 ТБ в размере каждый в установке RAID1
- все машины будут размещены в крупном информационном центре с предоставлением резервного питания и т.д.
- спецификации сервера видны здесь
- объем целого кластера состоит в том, чтобы распределить рабочую нагрузку +, позволяют высокую доступность. Машина может понизиться в любое время, не будучи проблемой для целой системы.
Одно из решений, оставленных для взятия, - использовать ли программное обеспечение RAID1 или аппаратные средства RAID1 + BBU.
Программное обеспечение RAID является решением, я очень знаком с (я управляю многими серверами с 15 лет, и я знаю, как инструменты работают). У меня никогда не было серьезной проблемы с ним (главным образом только сбой жесткого диска). Это причины, почему я предпочитаю программное обеспечение RAID.
Что я не люблю об аппаратных средствах, RAID является несовместимостью между поставщиками контроллера и отсутствием опыта, который я имею с ними: различные параметры конфигурации, другой метод мониторинга, различные утилиты - не хорошее чувство для создания кластерной системы.
Я знаю, что при использовании BBU аппаратные средства RAID может и быть быстрым и надежным (запись через кэш). Однако, так как все данные будут храниться очень избыточным способом в кластере, моя идея состоит в том, чтобы использовать программное обеспечение RAID1 и отключить барьеры в файловой системе для увеличения производительности записи. Я ожидаю, что это приведет к подобной производительности как аппаратные средства RAID1. Конечно, я рискую потерей данных из-за энергозависимого кэша записи, однако по моему скромному мнению, который должен быть обработан кластеризирующимися механизмами так или иначе (целая машина должна смочь восстановить данные из других узлов после отказа).
У меня нет опасений по поводу ресурсов ЦП, необходимых Реализации 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.