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

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

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

По крайней мере, для меня это полные джунгли различных доступных решений. Собственные Apache mod_proxy и HAproxy - это два, которые мы нашли по быстрому поиску в Google, но, имея нулевой опыт балансировки нагрузки, я понятия не имею, что подойдет для нашей ситуации или на что мы будем обращать внимание при выборе решения для решения нашей проблемы. проблемы доступности.

Какой для нас лучший вариант? Что мы должны сделать, чтобы обеспечить высокую доступность, оставаясь в рамках наших бюджетов?

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

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

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

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

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

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

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

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

Несколько вещей для размышления также:

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

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

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

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

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

Мой голос за Linux Virtual Server в качестве балансировщика нагрузки. Это делает директора LVS единственной точкой отказа, а также узким местом, но

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

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

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

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

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

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

Вы можете рассмотреть возможность использования надлежащего программного обеспечения для кластеризации. RedHat's (или CentOS) Cluster Suite или 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 с cloudfoundry или, возможно, Elastic beanstalk или просто старый AWS, автоматически масштабирующий мысль. Я использую это, и оно довольно хорошо масштабируется, а эластичность может увеличиваться / уменьшаться без какого-либо вмешательства человека.

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

Это может быть лучшее использование вашего времени.