Назад | Перейти на главную страницу

IP-адрес кластера в среде высокой доступности CentOS (5.x)

Я нахожусь в процессе установки настройки высокой доступности CentOS (5.x) с возможностью аварийного переключения, у меня есть 2 идентичных XEN VPS в двух разных местах, каждый VPS имеет частный IP и общедоступный IP, я использую частный IP на каждом узле для дисковой реплики DRBD, и оба узла подключены с помощью туннеля IPSec на частном уровне, прямо сейчас я думаю об использовании STONITH в качестве механизма ограждения вдоль Pacemaker и Corosync для кластеризации, но меня смущает вся идея IP-адреса кластера (Плавающий адрес) и что я должен точно указать в качестве NS-серверов домена на уровне домена, моя установка имеет 2 узла только с 2 выделенными DNS-серверами, и я знаю, что плавающий IP-адрес не должен принадлежать ни одному из узлов в кластере ( насколько мне известно), так как же этот одинокий IP-адрес может знать об этих двух узлах? любые логические подсказки будут отличными!

С двумя машинами в разных датацентры? Вы не можете. В этом сценарии предполагается, что обе машины в кластере находятся в одной подсети; VIP также находится в этой подсети.

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

Не то, что ты имел в виду, а? Географическая избыточность - дело непростое и дешевое.

Минимум, который я бы сделал здесь, поскольку я предполагаю, что у вас ограниченный бюджет, не более трех или четырех цифр, - это забыть VIP и написать настраиваемый забор, который добавляет и удаляет записи A из DNS, когда машины выходят. онлайн или офлайн, и разместите свой DNS там, где все эти проблемы уже решены (например, Amazon Route 53). Вам также придется использовать STONITH (и написать для этого собственный код), но удаление записи DNS гарантирует, что посетители не будут направлены на мертвый узел.

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