Задача

Требуется обеспечить работоспособность определённого IP-адреса (шлюза, важного сервера и т.д.) при пропадании связи с устройством, которому этот адрес первоначально принадлежит, с помощью резервных устройств.

В статье для этой цели будут использованы Debian Linux, протокол CARP и утилита ucarp.

В своей предыдущей статье я вкратце коснулся темы создания High Availability решения на основе демона heartbeat. Однако, как выяснилось, что-то сложнее чем 2-х узловой кластер на нем делать не так уж удобно. Изучение проблемы вывело меня на след проекта Pacemaker. Его-то мы сейчас в кратце и рассмотрим.

В этой статье будет описано архитектурное решение низкого уровня облачной платформы Hivext, а именно уровня дата центров и взаимодействия между собой серверов разного типа.
Напомним, что проект Hivext — предназначен для более эффективного использования ресурсов (временных и финансовых) при разработке “богатых” интернет приложений (Rich Internet Application) и предоставляет широкий набор готовых взаимосвязанных сервисов.
Благодаря компании IT-GRAD мы получили возможность бесплатного разворачивания дополнительной копии платформы в Питерском дата центре (ДЦ). Нам выделили виртуальный хостинг на базе VMware vSphere 4. Работать с таким хостингом можно и через веб интерфейс и через десктоп клиент, все довольно удобно.

На данный момент Hivext развернута в 3-х территориально разнесенных ДЦ: Киев (Украина), Житомир (Украина) и Санкт-Петербург (Россия). Конфигурация платформы внутри каждого ДЦ построена по определенной структуре.

Предлагаю, так сказать, заглянуть под капот нашей платформы.

Все уже наверняка обратили внимание, что в PostgreSQL 8.4 появился новый режим работы базы данных: Warm standby. При нём во время работы базы данных Write-Ahead логи (WAL) транслируются на подчинённую базу данных, на которой в реальном времени применяются, как если бы это происходило на основной системе. Поэтому, если основная база данных по какой-то причине (молния/торнадо/третья мировая война/другие стихийные бедствия) выйдет из строя, можно будет мгновенно переключиться на подчинённую базу данных (данные в которой будут достаточно актуальны по сравнению с основной базой) и использовать её дальше.
Но, к сожалению, «тёплый стэндбай» подразумевает, что на подчинённой системе непрерывно происходит процесс восстановления базы данных; из чего следует, что пока основная база жива, подчинённой базой пользоваться нельзя.
Если вы читаете хотя бы блог depesz (не говоря уже про коммит-логи), то вы уже знаете, к чему я веду; если же нет, то… 19-го декабря прошлого года в разрабатываемую версию PostgreSQL 8.5 была добавлена функциональность Hot standby. Теперь, при настройке репликации WAL, подчинённая база данных тоже может использоваться для запросов SELECT (и только SELECT, по понятным причинам). Если раньше второй сервер со второй базой данных простаивал в ожидании форс-мажора, и админу приходилось краснеть перед менеджерами при вопросах об эффективности использования оборудования — то теперь этот сервер, при правильном построении логики приложений, поможет разгрузить основную базу данных.
Подробности о функционировании Hot standby можно прочитать в соответствующей статье из документации разрабатываемой версии PostgreSQL.

В одном из наших проектов (социальная генеалогическая сеть), о котором я писал в данном топике, мы используем очередь отложенных событий, реализованную на мемкеше. Ее архитектура такова: приложение записывает в эту очередь различные события и данные, относящиеся к ним (тип события, входящие параметры, и функция обработчик этого события). После чего менеджер(-ы) очереди разбирают эту очередь и выполняют отложенные события. В частности такая очередь используется для сбора статистики, но также и для других более критичных к выполнению задач.
Поэтому очень важно обеспечить high availability для менеджера(-ов) очереди.

Но т.к. ф-ия обработчик очереди к нам приходит из вне, то за качество этого обработчика события мы не отвечаем, т.е. если обработчик вдруг выбросит ошибку, то нам ее нужно обработать и продолжить работу менеджера очереди. Но иногда случается, что обработчики выбрасывают фатальные ошибки (Fatal Error), и это может стать проблемой…