Растягивающийся кластер Linux: репликация MD, DRBD или Veritas?

Я бы пошел с GlusterFS. Последняя версия 3.x поддерживает гео-репликацию (тип вещей с длинным латентным каналом), а также репликацию по локальной сети. Существует множество документов о том, как реплицировать и распределять данные по кластеру.

Мне не нравится DRDB, потому что есть ограничение на количество узлов, которые вы можете использовать. Я думаю, что GlusterFS на приличном оборудовании с приличной настройкой сети может быть именно тем, что вам нужно. Определенно стоит тестовая сессия.

DRBD очень медленный, как все знают. Вы не можете использовать это для корпоративных целей с высокой нагрузкой. Он использует функции хеширования 128 КиБ, которые ограничивают запросы ввода-вывода до макс. 128 КиБ вместо 512 КиБ, что может обеспечить обычный жесткий диск. Кроме того, существует глупое определение размера запроса ввода-вывода. Эта вещь работает только при подключении к другому хосту. Если вы потеряете соединение, оно будет сброшено до 4 КиБ на локальных жестких дисках. 8.4.1 и 8.3.11 имеют те же проблемы.

Вот еще некоторые подробности: Ice

Вот почему реальные предприятия используют такие вещи, как Veritas.

MD RAID 1 намного лучше, если вам нужна производительность по низкой цене. Он также обеспечивает режим "большей части записи", чтобы вы могли избежать чтения с медленного устройства.

В настоящее время я тестирую "растягивающийся кластер" с использованием Red Hat Cluster Suite и DRBD. Я набираю это в отеле возле Red Hat Summit в Бостоне, который только что закончился. Я разговаривал с разработчиками Red Hat CLuster Suite, и они сказали, что в настоящее время растягивающиеся кластеры не поддерживаются.

Это не помешает мне работать над этим ради развлечения. Моя установка - четыре лезвия HP в одном кластере. Два лезвия находятся в одном центре обработки данных, примерно в 15 милях от другого центра обработки данных, в котором находятся два других лезвия. Чтобы объединить кластер, мне понадобилась сетевая команда, чтобы настроить маршрутизаторы между сайтами для передачи многоадресного трафика. Кроме того, поскольку Red Hat жестко кодирует TTL "1" для пакетов многоадресного пульса, мне пришлось использовать iptables для преобразования этого адреса многоадресной рассылки в более высокий TTL.

После того, как это было сделано, я смог получить кластер из четырех узлов со своими блейдами. Для хранения у меня есть 3Par LUN на каждом сайте между каждым из двух локальных узлов. Это блочные устройства, которые я использую для своих устройств DRBD. Я должен добавить, что у меня есть выделенный канал 1G WAN только для моего трафика DRBD. Мне удалось довольно легко запустить DRBD между сайтами и использовать это устройство DRBD в качестве PV в кластеризованном LV с запущенной GFS2. У меня иногда возникают проблемы с разделением мозга на моей установке DRBD, которые я должен восстановить вручную, и я пытаюсь изолировать эту проблему.

Следующий шаг был самым сложным. Я хочу иметь возможность сбой моего монтирования GFS2 на другой узел в случае сбоя основного. Мой сервис GFS2 состоит из плавающего IP -> DRBD -> LVM -> GFS2. Скрипт drbd.sh, входящий в исходный код для кластеризации, вообще не работает, поэтому я тестировал обычный скрипт запуска DRBD в /etc/init.d. Кажется, работает "иногда", поэтому мне нужно настроить, что кажется.

Я с ужасом обнаружил, что ничего из этого не поддерживается в Red Hat Cluster Suite, поэтому любая моя мечта о переносе этого в производство рухнула. И где еще вам понадобится такая установка? Практически только очень важные производственные вещи.

Я говорил с Symantec здесь, и они сказали мне, что они полностью поддерживают активно-активные эластичные кластеры с общим хранилищем. Я верю, что когда я действительно это увижу.

Если у вас есть бэкэнд SAN, тогда файловая система общего хранилища (GFS?) Имеет гораздо больше смысла, чем реплицированное хранилище.

Wrt. программный raid/md, хотя внешне DRBD - это всего лишь RAID 1 по сети, в действительности DRBD значительно сложнее, например, для работы с временными сетевыми разделами без повторной синхронизации с нуля и т. д.

Кроме того, учтите, что программный RAID-1 обычно пытается сбалансировать нагрузку на диски, распределяя чтения по ним несколько равномерно. Излишне говорить, что это не очень хорошая идея, если один диск является локальным, а другой находится где-то позади потенциально сетевого канала с низкой пропускной способностью / высокой задержкой.

Итак, программный RAID не является хорошим решением для репликации.

Я работал с Veritas Volume Manager, Cluster и Global cluster в компании $$$ - мне это очень понравилось.

Я работал с хост-зеркалированием SAN-устройств.

У меня есть пара XEN-кластеров, на которых работает DRBD с локальными дисками для репликации между двумя дата-центрами (не слишком далеко друг от друга). Я только что столкнулся с некоторыми проблемами в прошлую пятницу после короткого отключения сети там...

Что мне действительно понравилось в решении Veritas, так это то, что он может точно настроить каждый аспект. Таким образом, для db-приложения с интенсивным чтением мы настроили тома так, чтобы чтение осуществлялось из основного центра обработки данных, расположенного вместе с клиентами, что дало огромный прирост производительности.

Так что для хранения-репликации: если вы можете себе это позволить - перейдите на Veritas.

Теперь о кластерном программном обеспечении: я знаю Veritas, Sun, AIX/HACMP/HAGEO, HP-Serviceguard и Linux-Heartbeat.

Мне больше всего понравился Veritas, и особенно мне нравится, как он предотвращает сплит-мозги (режим опасности)...

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

Я могу привести здесь слова Алана Робертсона: "Кластер - это не кластер, если вы не проверили его".

И я видел больше простоев из-за сложной кластерной установки, чем из-за экономии при такой установке. Так что будьте проще (Heartbat v1 вместо v2).

Мы используем DRBD на работе. Он работает довольно хорошо, но мы используем его только в конфигурации с двумя узлами. Я бы не стал рассматривать это для чего-то более сложного.

Метро / растягивающийся кластер можно использовать только в режиме асинхронной или полусинхронной репликации, что исключает md,