Балансировка нагрузки Apache при ограниченном бюджете?

HAproxy - хорошее решение. Конфигурация довольно проста.

Вам понадобится еще один экземпляр VPS, чтобы он располагался перед как минимум двумя другими VPS. Таким образом, для балансировки нагрузки / аварийного переключения вам потребуется минимум 3 VPS.

Также следует подумать о следующих вещах:

1. Прекращение действия SSL. Если вы используете HTTPS: //, это соединение должно завершаться на балансировщике нагрузки, за балансировщиком нагрузки он должен пропускать весь трафик через незашифрованное соединение.

2. Файловое хранилище. Если пользователь загружает изображение, куда оно отправляется? Он просто сидит на одной машине? Вам нужен какой-то способ мгновенно обмениваться файлами между машинами - вы можете использовать сервис Amazon S3 для хранения всех ваших статических файлов, или у вас может быть другой VPS, который будет действовать как файловый сервер, но я бы рекомендовал S3, потому что он избыточен и безумно дешев.

3. информация о сеансе. каждая машина в вашей конфигурации балансировщика нагрузки должна иметь доступ к информации о сеансе пользователя, потому что вы никогда не знаете, на какую машину они попадут.

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

Итак, я был на вашем месте, вот в чем проблема с веб-сайтом, который делает несколько сотен посещений в день при реальной работе. Это быстро усложняется. Надеюсь, это дало вам пищу для размышлений :)

Я использую следующее решение, которое можно легко реализовать с помощью VPS:

• DNS является циклическим (sp?) До 6 различных действительных IP-адресов.
• У меня есть 3 балансировщика нагрузки с идентичной конфигурацией и использую corosync / кардиостимулятор для равномерного распределения 6 IP-адресов (чтобы каждая машина получила 2 адреса).
• Каждый из балансировщиков нагрузки имеет nginx + лак конфигурация. Nginx занимается получением соединений, перезаписью и некоторым статическим обслуживанием и передачей их обратно Varnish, который выполняет балансировку нагрузки и кэширование.

У этой арки, на мой необъективный взгляд, есть следующие преимущества:

1. corosync / pacemaker будет перераспределять IP-адреса в случае отказа одного из LB.
2. nginx может использоваться для обслуживания SSL, определенных типов файлов непосредственно из файловой системы или NFS без использования кеша (большие видео, аудио или большие файлы).
3. Varnish - очень хороший балансировщик нагрузки, поддерживающий вес, проверку работоспособности серверной части и отлично справляющийся с ролью обратного прокси.
4. В случае, если для обработки трафика требуется больше LB, просто добавьте больше машин в кластер, и IP-адреса будут перебалансированы между всеми машинами. Вы даже можете делать это автоматически (добавляя и удаляя балансировщики нагрузки). Вот почему я использую 6 дюймов в секунду для 3 машин, чтобы оставить место для роста.

В вашем случае наличие физически разделенных VPS - хорошая идея, но затрудняет совместное использование IP-адресов. Цель состоит в том, чтобы иметь отказоустойчивую, избыточную систему и некоторые конфигурации для балансировки нагрузки / HA, которые мешают ей, добавляя единую точку отказа (например, один балансировщик нагрузки для приема всего трафика).

Я также знаю, что вы спрашивали об apache, но в те дни у нас есть специальные инструменты, которые лучше подходят для работы (например, nginx и varnish). Оставьте apache для запуска приложений на бэкэнде и обслуживания его с помощью других инструментов (не то, чтобы apache не мог хорошо балансировать нагрузку или обратное проксирование, это просто вопрос разгрузки различных частей задания на большее количество служб, чтобы каждая часть могла работать хорошо это доля).

Мой голос за Виртуальный сервер Linux как балансировщик нагрузки. Это делает LVS-директор единственной точкой отказа и узким местом, но

1. По моему опыту, узкое место не является проблемой; этап перенаправления LVS является третьим и чрезвычайно дешевым в вычислительном отношении.
2. Единственная точка отказа должна быть устранена с помощью второго директора, два из которых будут контролироваться Linux HA.

Стоимость может быть снижена, если первый директор находится на той же машине, что и первый узел LVS, а второй директор - на той же машине, что и второй узел LVS. Третий и последующие узлы являются чистыми узлами, без последствий для LVS или HA.

Это также дает вам возможность запускать любое программное обеспечение веб-сервера, которое вам нравится, поскольку перенаправление происходит ниже уровня приложения.

Как насчет этой цепочки?

round robin dns> haproxy на обеих машинах> nginx для разделения статических файлов> apache

Возможно также использовать ucarp или heartbeat, чтобы haproxy всегда отвечал. Stunnel будет сидеть перед haproxy, если вам тоже нужен SSL

Вы можете рассмотреть возможность использования подходящего программного обеспечения для кластеризации. RedHat's (или CentOS) Кластерный люкс, или Oracle ClusterWare. Их можно использовать для настройки активно-пассивных кластеров, а также для перезапуска служб и сбоев между узлами при возникновении серьезных проблем. По сути, это то, что вы ищете.

Все эти кластерные решения включены в соответствующие лицензии на ОС, так что вы, вероятно, не боитесь стоимости. Им действительно требуется какое-то общее хранилище - либо монтирование NFS, либо физический диск, к которому имеют доступ оба узла с кластерной файловой системой. Примером последнего могут быть диски SAN с разрешенным доступом к нескольким хостам, отформатированные с OCFS2 или GFS. Я считаю, что вы можете использовать VMWare общие диски для этого.

Программное обеспечение кластера используется для определения «служб», которые работают на узлах все время или только тогда, когда этот узел «активен». Узлы общаются посредством тактовых импульсов, а также контролируют эти службы. Они могут перезапустить их, если заметят сбои, и перезагрузить, если они не могут быть исправлены.

По сути, вы должны настроить один «общий» IP-адрес, на который будет направляться трафик. Затем можно определить apache и любые другие необходимые службы, которые будут запускаться только на активном сервере. Общий диск будет использоваться для всего вашего веб-контента, любых загруженных файлов и каталогов конфигурации apache. (с httpd.conf и т. д.)

По моему опыту, это работает очень хорошо.

• Нет необходимости в циклическом переборе DNS или любом другом балансировщике нагрузки с единственной точкой отказа - все попадает в один IP / FQDN.
• Файлы, загруженные пользователем, попадают в это общее хранилище, и поэтому их не волнует, выйдет ли из строя ваша машина.
• Разработчики загружают контент на этот единственный IP / FQDN без дополнительного обучения, и он всегда актуален в случае сбоя.
• Администратор может отключить машину, исправить ее, перезагрузить и т. Д. Затем вывести активный узел из строя. Обновление требует минимального времени простоя.
• Этот теперь устаревший узел можно некоторое время оставлять без исправлений, что делает восстановление после сбоя таким же простым процессом. (Быстрее, чем снимки VMWare)
• Изменения в конфигурации Apache являются общими, поэтому во время аварийного переключения не происходит ничего странного, потому что администратор забыл внести изменения в автономном поле.

- Кристофер Карел

Оптимальная балансировка нагрузки может быть очень дорогой и сложной. Базовая балансировка нагрузки должна просто гарантировать, что каждый сервер обслуживает примерно одинаковое количество попаданий в любое время.

Самый простой метод балансировки нагрузки - предоставить несколько A-записей в DNS. По умолчанию IP-адрес будет настроен по циклическому методу. Это приведет к относительно равномерному распределению пользователей по серверам. Это хорошо работает для сайтов без сохранения состояния. Если у вас есть сайт с отслеживанием состояния, требуется более сложный метод.

Для обработки требований с отслеживанием состояния вы можете использовать перенаправления. Дайте каждому веб-серверу альтернативный адрес, например www1, www2, www3 и т. Д. Перенаправьте начальное соединение www на альтернативный адрес хоста. В результате у вас могут возникнуть проблемы с закладками, но они должны быть равномерно распределены по серверам.

В качестве альтернативы, использование другого пути для указания того, какой сервер обрабатывает сеанс с отслеживанием состояния, позволит проксировать сеансы, которые переключили хост на исходный сервер. Это может быть проблемой, когда сеанс для отказавшего сервера прибывает на сервер, перешедший на смену отказавшему серверу. Однако при запрете программного обеспечения для кластеризации состояние все равно будет отсутствовать. Из-за кеширования браузера у вас может не наблюдаться много сеансов смены серверов.

Отказоустойчивость может быть обработана путем настройки сервера на получение IP-адреса отказавшего сервера. Это минимизирует время простоя в случае отказа сервера. Без программного обеспечения для кластеризации сеансы с отслеживанием состояния будут потеряны в случае отказа сервера.

Без переключения при отказе пользователи будут испытывать задержку, пока их браузер не переключится на следующий IP-адрес.

Использование сервисов Restful вместо сессий с отслеживанием состояния должно устранить проблемы кластеризации во внешнем интерфейсе. Проблемы кластеризации на стороне хранилища по-прежнему будут применяться.

Даже с балансировщиками нагрузки перед серверами вы, скорее всего, будете иметь перед ними циклический DNS. Это обеспечит использование всех ваших балансировщиков нагрузки. Они добавят к вашему дизайну еще один уровень с дополнительной сложностью и еще одной точкой отказа. Однако они могут обеспечивать некоторые функции безопасности.

Лучшее решение будет зависеть от соответствующих требований.

Внедрение серверов изображений для обслуживания такого контента, как изображения, файлы CSS и другой статический контент, может снизить нагрузку на серверы приложений.

Обычно я использую пару одинаковых машин OpenBSD:

• Используйте RelayD для балансировки нагрузки, мониторинга веб-сервера и обработки отказавшего веб-сервера
• Используйте CARP для обеспечения высокой доступности самих балансировщиков нагрузки.

OpenBSD легок, стабилен и достаточно безопасен - идеально подходит для сетевых служб.

• http://www.openbsd.org - Главный сайт
• http://www.openbsd.org/faq/pf/carp.html - Документация по карпу
• https://calomel.org/relayd.html - Достойный набор инструкций по RelayD

Для начала я рекомендую настройку Layer3. Это позволяет избежать сложностей при настройке брандмауэра (PF). Вот пример файла /etc/relayd.conf, который показывает настройку простого балансировщика нагрузки реле с мониторингом внутренних веб-серверов:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

Вы дали ec2 с облачный завод или, может быть Эластичный бобовый стебель или просто старый Автомасштабирование AWS мысль. Я использовал это, и он довольно хорошо масштабируется, и, будучи эластичным, можно масштабировать / уменьшать без какого-либо вмешательства человека.

Учитывая, что вы говорите, что у вас нулевой опыт работы с балансировкой нагрузки, я бы предложил эти варианты, поскольку они требуют минимальной "поджаривания" мозга, чтобы приступить к работе.

Возможно, так будет лучше использовать ваше время.