Я исследую настройку серверного решения с балансировкой нагрузки, состоящего из трех модулей CentOS 5.4. Два из этих ящиков будут находиться в одном учреждении, а третий - в другом учреждении.
В настоящее время я работаю над настройкой Heartbeat, ldirectord, ipvsadm для балансировки нагрузки машин, но я не уверен, что он будет работать с
Я не очень хорошо знаком с деталями того, как все это работает, но будет ли балансировка нагрузки работать правильно, когда все эти серверы не находятся в одной локальной сети? Я не уверен, использует ли Heartbeat SNMP для отправки сигналов или нет, который будет работать только по локальной сети. Кто-нибудь пробовал это или нашел другое решение?
Это большая тема, которая быстро усложняется. В CAP теорема является хорошей отправной точкой, так как определяет выбор более высокого уровня, который необходимо сделать.
Когда вы имеете дело с веб-приложением, требующим больших объемов записи, становится труднее распределить нагрузку по Интернету при сохранении целостности данных. Приложения, ориентированные на чтение (поиск!), Легче распространять, поскольку вам не нужно беспокоиться о логистике записи данных.
ipvs позволяет Linux по существу стать коммутатором уровня 4. Я наиболее успешно использовал его на уровне 2 (ARP / ethernet - канальный уровень), и это был бы мой первый выбор, но, возможно, было бы целесообразно использовать что-то вроде LVS-Tun для географически разделенных серверов, которые не имеют соединения на уровне широковещания. Обратите внимание, ipvsadm - это инструмент пользовательского уровня для ipvs, а ldirectord - это демон для управления ресурсами ipvs.
сердцебиение эффективно сменилось кардиостимулятор. Чтобы контролировать другой сервер, необходимо иметь несколько ссылок. Риск отсутствия последовательного или избыточного физического соединения между серверами существенно выше. Даже несколько физически различных подключений к Интернету, которые отслеживает сердцебиение между двумя сайтами, обязательно отключатся. Здесь в игру вступает риск данных, поскольку автоматическое переключение при отказе может привести к повреждению данных разделенным мозгом. Не существует идеального метода снижения этого риска.
Вы можете добавить больше логики в процесс аварийного переключения. Например:
Если path1 не работает, path2 не работает, этот процесс не запущен, и я не могу этого сделать - тогда переключение.
Это снижает риск, но даже в этом случае не обязательно до такой степени, что можно физически подключать серверы на небольшом расстоянии.
Со статическим контентом легко использовать Сеть распространения контента.
Простая балансировка нагрузки и аварийное переключение могут быть выполнены с помощью Циклический DNS, что более подвержено ошибкам.
Протокол пограничного шлюза это сетевой протокол, обеспечивающий высокую доступность на сетевом уровне.
В конечном итоге, имея достаточно денег (времени / ресурсов), можно разработать соответствующее SLA, чтобы обеспечить высокую степень доступности. Ваш бюджет будет вашим главным ограничением. Определите свои требования, а затем посмотрите, чего вы можете достичь в рамках своего бюджета, поскольку будут компромиссы.
Я часто обнаруживал, что имеет смысл, по крайней мере, в случае написания тяжелых приложений, обеспечить высокую доступность и автоматическое переключение при отказе в одном и том же физическом помещении. Как часть плана аварийного восстановления и SLA, чтобы иметь возможность ручного переключения на физически отдельную площадку, что позволяет поддерживать целостность данных, но при этом поддерживает уровень качества обслуживания.
Наличие разных серверов в разных местах не должно быть проблемой, пока они не смогут связаться друг с другом.
Проблема будет в пропускной способности между ними и в том, что вы делаете на ней.
Heartbeat не использует snmp и может быть многоадресным, одноадресным или широковещательным. Это особый протокол (в любом случае snmp работает между lans sicne, это протокол udp).
Какие службы пытаются балансировать нагрузки?
Другая идея - это реализация DRBD с высокой доступностью. Проверьте этот сайт http://www.drbd.org/home/what-is-drbd/