зачем указывать второй локейшн если у нас только один вип айпи?
Второй location указан для того, чтобы в случае отказа ноды first.local он мигрировал на second.local. Т.к. не задав значение score для second.local при условии не-симметричного кластера (symmetric-cluster=«false») он на ней просто никогда не запустится. Если кластер симметричный (по умолчанию так и есть), то указывать не нужно. Однако я бы не советовал делать так — мы теряем предсказуемость оценки размещения.
так этим же занимается corosync/heartbeat
corosync/heartbeat — занимаются тем, что мониторят состояние жизни нод, если говорить грубо. И для этого им выделяется, как правило, отдельный прямой (крос) линк.
В статье описывается размещения ресурсов привязанных к отличным от этих интерфейсов. К примеру на кластере может быть много сетевых интерфейсов — внутрення сеть, внешняя, DMZ. И мнрожество ресурсов привязанных только к одной из них. В таком случае падения какого-то линка не должна приводить к мигарции всех ресурсов класстера, а переносить только один. Тем самым уменьшая врямя простоя.
Вы и вправду думаете, что в ближайшее год-два они перейдут на systemd? Во первых — это же rhel, а во вторых стабильность тут превыше всего.
Хотя спорить тут бесмысленно systemd круче чем upstart.
>SYN пакеты с произвольных адресов внутренней сетки на произвольные интернет адреса
то есть переполянется таблица ната и сетевая подсистема, а не количество сокетов на менеджмент интрефейсе.
Это не поможет. Как мы можем ограничить свою внутренню подсетку по опции куда отсылать пакеты?
По хорошему нужно тюнить tcp-стек на таймауты спуфинг и тд.
Второй location указан для того, чтобы в случае отказа ноды first.local он мигрировал на second.local. Т.к. не задав значение score для second.local при условии не-симметричного кластера (symmetric-cluster=«false») он на ней просто никогда не запустится. Если кластер симметричный (по умолчанию так и есть), то указывать не нужно. Однако я бы не советовал делать так — мы теряем предсказуемость оценки размещения.
corosync/heartbeat — занимаются тем, что мониторят состояние жизни нод, если говорить грубо. И для этого им выделяется, как правило, отдельный прямой (крос) линк.
В статье описывается размещения ресурсов привязанных к отличным от этих интерфейсов. К примеру на кластере может быть много сетевых интерфейсов — внутрення сеть, внешняя, DMZ. И мнрожество ресурсов привязанных только к одной из них. В таком случае падения какого-то линка не должна приводить к мигарции всех ресурсов класстера, а переносить только один. Тем самым уменьшая врямя простоя.
Хотя спорить тут бесмысленно systemd круче чем upstart.
то есть переполянется таблица ната и сетевая подсистема, а не количество сокетов на менеджмент интрефейсе.
По хорошему нужно тюнить tcp-стек на таймауты спуфинг и тд.
Profit
И как по мне это хорошая популяризация Linux.