На данный момент существует множество вариантов создания кластера Linux.
Для менеджера кластера: вы можете использовать Red Hat Cluster manager, Pacemaker или Veritas Cluster Server. Первый имеет наибольшую динамику, второй по умолчанию идет с подписками на RH, а последний очень дорогой и имеет очень хорошую репутацию ;-)
Для хранилища: - Вы можете реплицировать LUN с помощью программного устройства raid / md - Вы можете использовать сеть, используя репликацию DRBD, которая предлагает немного большую гибкость - Вы можете использовать технологию Veritas Storage Foundation, чтобы общаться с вашей технологией репликации SAN.
У кого-нибудь есть рекомендации или опыт работы с этими технологиями?
Я бы пошел с GlusterFS. Последняя версия 3.x поддерживает георепликацию (тип длинного скрытого канала), а также репликацию по локальной сети. Есть много документов о том, как реплицировать и распространять данные по кластеру.
Мне не нравится DRDB, потому что есть ограничение на количество узлов, которые вы можете использовать. Я думаю, что GlusterFS на приличном оборудовании с приличной настройкой сети может быть именно тем, что вам нужно. Определенно стоит тестовая сессия.
Как всем известно, DRBD очень медленный. Вы не можете использовать это для корпоративных целей с высокой нагрузкой. Он использует функции хеширования 128 КиБ, которые ограничивают количество запросов ввода-вывода максимумом. 128 КБ вместо 512 КБ, которые может предоставить обычный жесткий диск. Кроме того, есть тупое определение размера запроса ввода-вывода. Эта вещь работает только при подключении к другому хосту. Если вы потеряете соединение, он будет сброшен до 4 КБ на локальных жестких дисках. 8.4.1 и 8.3.11 имеют те же проблемы.
Вот еще некоторые подробности: http://www.gossamer-threads.com/lists/drbd/users/24104
Вот почему на реальных предприятиях используются такие вещи как 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?) Имеет гораздо больше смысла, чем реплицированное хранилище.
Мы используем DRBD в работе. Он работает довольно хорошо, но мы используем его только в конфигурации с двумя узлами. Я бы не стал рассматривать это как что-то более сложное.
Wrt. программный raid / md, в то время как DRBD на первый взгляд представляет собой просто RAID 1 по сети, на самом деле DRBD значительно сложнее, чтобы иметь дело, например, с временными разделами сети без необходимости повторной синхронизации с нуля и т. д.
Также учтите, что программный RAID-1 обычно пытается сбалансировать нагрузку на диски, равномерно распределяя чтение по ним. Излишне говорить, что это не очень хорошая идея, если один диск является локальным, а другой находится где-то за сетевым каналом с потенциально низкой пропускной способностью / высокой задержкой.
IOW, программный RAID - не лучшее решение для репликации.
Кластер Metro / stretch можно использовать только в режиме асинхронной или полусинхронной репликации, что исключает md.
Я работал с 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).