Развертывание высокой доступности Postresql 9.0 на Amazon EC2 с помощью PGPool-ii

Пара мыслей. Во-первых, мы избегаем SPOF для таких вещей, как PGPool, используя Heartbeat, Pacemaker и ElasticIP. Запустите два (или более) экземпляра, посвященных PGPool. Назначьте ElasticIP одному из них. Настройте Heartbeat и Pacemaker для мониторинга PGPool. При отработке отказа пусть Pacemaker запустит сценарий, который назначает ElasticIP новому мастеру (DC в терминах Pacemaker). Если вы используете только два узла, обязательно отключите функцию кворума в Pacemaker, потому что у вас не может быть кворума, если один узел выходит из строя из двух.

Чтобы воспользоваться преимуществами ElasticIP, выполните обратный поиск DNS на своем ElasticIP за пределами Amazon. Это даст вам DNS-имя, которое сопоставляется с ElasticIP, которое должно заканчиваться на amazonaws.com. DNS-запросы из экземпляра EC2 для доменного имени, оканчивающегося на amazonaws.com, фактически разрешатся в внутренний IP-адрес экземпляра, которому назначен ElasticIP. Вы можете указать свои серверы приложений непосредственно на DNS для ElasticIP или, предполагая, что вы используете свой собственный DNS, вы можете создать CNAME, который ссылается на DNS ElasticIP.

Тем не менее, есть одна большая проблема с использованием ElasticIP для аварийного переключения. Повторное назначение ElasticIP вступает в силу в течение 120 секунд. Большая часть времени уходит на ожидание распространения изменений через DNS-серверы Amazon.

Кроме того, хотя я не пробовал запускать PGPool-ii на каждом сервере приложений, я не уверен, что это сработает. Если основная база данных выйдет из строя, я думаю, что каждый из экземпляров PGPool будет конкурировать за обработку отказа. Может быть, я просто недостаточно знаком с PGPool-ii, чтобы понять, как с этим справиться.

Что касается человека, который упомянул plproxy, я думаю, что он перепутал его с PGBouncer, что рекомендуется для использования с plproxy. plproxy — это система разделения, а не балансировщик нагрузки. Тем не менее, PGBouncer также не является балансировщиком нагрузки — это система пула соединений. PGBouncer не обеспечивает балансировку нагрузки. Фактически, FAQ для PGBouncer явно рекомендует использовать балансировщик нагрузки TCP, такой как HAProxy.

Кроме того, утверждения о том, что у Amazon есть проблемы с вертикальной масштабируемостью, которые решает Rackspace, неверны. С инстансами Amazon EC2 вы всегда можете остановить инстанс и обновить его до более крупного типа. Ни Amazon, ни Rackspace не поддерживают изменение типов инстансов на лету.

Хотя у меня нет четкого представления о pgPool. Я провел много исследований в области масштабируемости и проигнорировал pgPool по какой-то причине, которую сейчас не помню.

Я бы посоветовал взглянуть на plproxy. Это предлагает подход с балансировкой нагрузки.

Кроме того, я бы не стал активным покупателем на Amazon из-за проблем с вертикальной масштабируемостью Amazon. Вы не получаете готовое обновление, если хотите увеличить конфигурацию сервера. Таким образом, вы в конечном итоге снова реализуете все настройки своего сервера, если перейдете на более высокий экземпляр.

Таким образом, Rackspace убедительно показал, что вы можете просто попросить их обновить оперативную память с 1 ГБ до 2 ГБ или более, и это будет сделано с помощью простого перезапуска вашего экземпляра.

И Amazon, и Rackspace предлагают (99%) надежное решение для хостинга, а оставшийся 1% мы должны принять к сведению с надлежащим резервным копированием и распространением в разных регионах и т. Д.,