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

У нас есть существующее веб-приложение, которое использует Postgresql 9.0 и PGPool-ii. Я думаю о миграции нашей инфраструктуры в Amazon EC2 и был вдохновлен следующей ссылкой: http://aws.typepad.com/aws/2008/12/running-everything-on-aws-soocialcom.html, которая использует подобную архитектуру.

Поскольку Amazon RDS не поддерживает PGSQL, мы будем придерживаться PGPool-ii, чтобы балансировать запросы на разных серверах БД и поддерживать их синхронизацию между собой.

Итак, мы планируем развернуть 3 внешних веб-сервера, которые будут содержать следующее: - Веб-сервер + PHP-код - PGPool-ii

Тогда у нас было бы 2 сервера баз данных на отдельных экземплярах Amazon только с PGSQL. Эти 2 PG-сервера будут использоваться PGPools, расположенными на 3 внешних серверах.

Мой вопрос в том, что я не знаю, достаточно ли это решение, так как несколько PGPool получат доступ к нескольким серверам PGSQL. Большинство примеров PGPool демонстрируют один PGPool, который использует N базовых PGSQL-серверов. Является ли хорошей практикой развертывание экземпляра PGPool на каждом веб-сервере?

Если нет, есть ли другая/лучшая архитектура, чтобы избежать использования SPOF с помощью Amazon?

Большое спасибо за ваши ответы.

Ответ 1

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

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

Тем не менее, есть один большой улов для использования ElasticIPs для перехода на другой ресурс. Повторное назначение 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 не поддерживают изменение типов экземпляров на лету.

Ответ 2

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

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

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

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

Оба Amazon и Rackspace предлагают (99%) надежное решение для хостинга, а остальные 1% мы должны учитывать при правильном резервировании и распространении в разных регионах и т.д.,