В данной статье я расскажу о своей реализации отказоустойчивого кластера, а также покажу его основную схему, из-за чего появилась необходимость в создании кластера серверов. Данная реализация является недорогой, и способна также осуществлять балансировку нагрузи и работу сложного проекта. Синхронизация данных осуществляется с помощью cwRsync на уровне файлов проекта, и MySQL M-M репликации на уровне базы данных.
Собственно одержимость идеей организации отказоустойчивый кластер возникла, как и у многих моих предшественников, из-за неприятного происшествия с железом. На выделенном Windows сервере в тот момент крутился очередной веб проект, идея которого состоит в высокой готовности. В один прекрасный момент сервер начал падать. Вот так поработает часок, другой и в ребут… Немного покопав логии, и не увидев никаких ошибок подозрение упало на железо и вскоре, после различных тестов, стало понятно – отказывает оперативка. Мы сообщили хостеру о проблеме, и злополучная планка памяти была заменена. Но, приблизительно 2-а часа ресурс был недоступен, не говоря о пропажах в течении дня.
Очередной раз увидев свою беззащитность перед случаем решили копать в сторону организации кластера.
В тот момент мне подсказали, что недорогое решение проблемы в окнах можно получить, используя компонент «Балансировки нагрузки сети» (Network Load Balancing, далее просто NLB). Развернув на VMware Workstation два абсолютно одинаковых сервера под управлением Windows Server 2003 Web edition, я начал свое ознакомление с этой технологией. Немного разобравшись, начал подгонять это все под существующий проект. Забегу немного вперед и скажу – одно дело это все собрать на виртуальных машинах, другое – на реальных серверах. Дома NLB кластер может собрать каждый в течении 5 минут. Когда дело касается реальности, возникает масса проблем с железом и программной частью.
Вот схема компонентов кластера, и их взаимодействия, к которой я в результате пришел:
Идея здесь следующая:
• NLB кластер обеспечивает балансировку нагрузки серверов, распределяя равномерно клиентский трафик между узлами.
• Master–Master репликация синхронизирует базы данных обоих серверов, таким образом обеспечивая отказоустойчивость на уровне базы данных.
• cwRsync синхронизирует файлы и папки.
В случае отказа одного из узлов, служба NLB переносит его нагрузку на оставшийся узел и проект работает дальше. При этом база данных и файлы являются абсолютно одинаковыми. Половина пользователей вообще не заметит этого. Та половина пользователей, которую обслуживал отказавший узел, может потерять сессию, и только. Также при переносе нагрузки кластер не будет доступен в течении пол минуты.
Кластер имеет два виртуальных IP адреса (не привязанные к MAC адресам узлов), трафик с которых распределяется между узлами. Каждый узел, имеет свой уникальный IP, который используется для обслуживания узла (удаленный доступ, копирование данных, организация взаимодействия для репликации и синхронизации). Все узлы должны находится в одной подсети.
В проекте производится не только чтение, а также запись в базу данных. Распределяя нагрузку по кластерам необходима именно Master – Master репликация MySQL сервера.
Это стало возможно благодаря использованию auto_increment_offset.
Для синхронизации каталогов проекта я использовал cwRsync – это знакомая всем утилита Rsync, используемая для этих же целей в Linux, но запущенная на Windows с помощью Cygwin. cwRsync легко работает с Rsync, что позволяет производить синхронизацию\бекапирование серверов под управлением Linux с одной стороны и под управлением Windows с другой.
В следующих статьях я опишу настройку каждого компонента в отдельности. Также опишу ситуации и различные неочевидные вещи, найденные в процессе создания и воплощения в жизнь. Постараюсь следить и дополнять статьи, в случае изменения данной схемы.
Несомненно, кластеризацию можно было осуществить и с помощью других компонентов. Если есть какие-то, более удачные идеи, пишите в комментариях. Если идея будет стоящая, я её с удовольствием реализую.