Linux-сервер с балансировкой нагрузки в Интернете?

Linux-сервер с балансировкой нагрузки в Интернете?

Я изучаю настройку решения сервера с балансировкой нагрузки, состоящего из трех коробок CentOS 5.4. Две из этих коробок будут находиться в одном помещении, а третья — в другом.

В настоящее время я работаю над настройкой heartbeat, ldirectord, ipvsadm для балансировки нагрузки машин, но я не уверен, что это будет работать с

Я не слишком хорошо знаком с деталями того, как все это работает, но будет ли балансировка нагрузки работать правильно, когда эти серверы не находятся в одной локальной сети? Я не уверен, использует ли heartbeat SNMP для отправки сигналов или нет, который будет работать только в локальной сети. Кто-нибудь пробовал это или нашел другое решение?

решение1

Это большая тема, которая быстро усложняется.Теорема CAPявляется хорошей отправной точкой, поскольку она определяет выбор более высокого уровня, который необходимо сделать.

Когда вы имеете дело с веб-приложением, интенсивно пишущим данные, становится сложнее распределить нагрузку по Интернету, сохраняя при этом целостность данных. Приложения, ориентированные на чтение (поиск!), легче распределять, поскольку вам не нужно беспокоиться о логистике записи данных.

ipvsпозволяет Linux по сути стать коммутатором уровня 4. Я имел наибольший успех при использовании его на уровне 2 (ARP/ethernet — канальный уровень), и это был бы мой первый выбор, но может быть целесообразно использовать что-то вродеLVS-Тундля географически разделенных серверов, которые не имеют соединения на уровне вещания. Обратите внимание, что ipvsadm — это инструмент пользовательского пространства для ipvs, а ldirectord — это демон для управления ресурсами ipvs.

Heartbeat был фактически замененкардиостимулятор. Для мониторинга другого сервера необходимо иметь несколько ссылок. Риск отсутствия последовательного или избыточного физического соединения между серверами существенно выше. Даже несколько физически отдельных интернет-соединений, которые heartbeat отслеживает между двумя сайтами, обязательно выйдут из строя. Вот где в игру вступает риск данных, поскольку автоматическое переключение на резервный сервер сопряжено с риском повреждения данных из-за разделения мозга. Идеального метода снижения этого риска не существует.

Вы можете добавить больше логики в процесс переключения на другой ресурс. Например:

Если путь 1 не работает, путь 2 не работает, этот процесс не запущен, и я не могу этого сделать — тогда переход на другой ресурс.

Это снижает риск, но даже в этом случае не всегда возможно физическое соединение серверов на небольшом расстоянии.

При использовании статического контента легко использоватьСеть распространения контента.

Простую балансировку нагрузки и отказоустойчивость можно реализовать с помощьюКруговой DNS, что более подвержено ошибкам.

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

В конечном счете, при наличии достаточного количества денег (времени/ресурсов) можно разработать соответствующее SLA, которое обеспечит высокую степень доступности. Ваш бюджет будет вашим конечным ограничением. Определите свои требования, а затем посмотрите, чего вы можете достичь в рамках своего бюджета, поскольку будут компромиссы.

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

решение2

Наличие разных серверов в разных местах не должно быть проблемой, пока они не смогут связаться друг с другом.
Проблема будет в пропускной способности между ними и в том, что вы заставляете течь по ней.
Heartbeat не использует SNMP и может быть многоадресным, одноадресным или широковещательным. Это особый протокол (в любом случае SNMP работает между локальными сетями, поскольку это протокол UDP).
Какие службы пытаются балансировать нагрузку?

решение3

Другая идея — это реализация DRBD с высокой доступностью. Проверьте этот сайтhttp://www.drbd.org/home/what-is-drbd/

Связанный контент