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

Как подключить к сети этот отказоустойчивый кластер Windows и набор реплик MongoDB? (схема внутри)

Как видите, два моих узла отказоустойчивого кластера Windows Server (WSFC) имеют по три сетевых интерфейса, которые соединяют их с тремя разными сетями:

  1. Публичная сеть
  2. Частная сеть, состоящая из узлов WSFC
  3. Частная сеть, состоящая из узлов WSFC и машины с файловым ресурсом кворума-свидетеля WSFC.

Имеет ли смысл запланированная мною конфигурация сети? Есть ли у меня «правильное» количество сетевых адаптеров и сетей? Я думаю, что второй сетевой адаптер / сеть может быть ненужным.

Мои два узла набора реплик MongoDB также имеют по три сетевых интерфейса каждый - очень похоже на предыдущую ситуацию:

  1. Публичная сеть
  2. Частная сеть, состоящая из основного и дополнительного узлов набора реплик MongoDB.
  3. Частная сеть, состоящая из первичного, вторичного и арбитражного узлов набора реплик MongoDB.

Имеет ли смысл такая сетевая конфигурация? Есть ли у меня «правильное» количество сетевых адаптеров и сетей? Я думаю, что второй сетевой адаптер / сеть может быть ненужным.

Вот самая простая версия, которую я рассматриваю:

ОБНОВИТЬ:

Здесь есть два вопроса: один по кластеризации MS, а другой по Mongo.

Кластеризация MS

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

Поместите контрольный сигнал в тот же интерфейс / подсеть, что и общедоступный интерфейс

Согласно этой теории, если вы потеряете публичный интерфейс, вы хотеть сердцебиение не работает, потому что этот узел фактически недоступен для пользователей.

Поместите сердцебиение в собственный частный интерфейс / подсеть

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

Поместите WFS в сеть Heartbeat

Если два узла находятся в одной и той же общей сети (один и тот же набор коммутаторов поддерживает закрытые сети для обоих узлов), то размещение WFS в сети Heartbeat не представляет никаких новых уязвимостей.

Если два узла находятся в разных доменах сбоя сети (например, в разных центрах обработки данных), это плохая идея. Сеть периодических сообщений предоставляет параметр кворума «большинство узлов», а WFS предоставляет параметр кворума «Большинство общих файловых ресурсов». Вы действительно хотите, чтобы оба варианта находились в разных доменах сбоя.


Ваша пересмотренная диаграмма имеет смысл, если оба узла находятся в одном дата-центре, хотя я бы сам хотел, но сердцебиение на публичной стороне.

MongoDB

MongoDB немного проще. При четном количестве узлов вам абсолютно необходимо, чтобы третий узел выполнял функцию разрешения конфликтов. Они довольно ясно понимают это. Однако на вашей диаграмме указано:

До 12 копий участников (7 могут голосовать).

7 - нечетное число. Вам не нужен арбитр.

В отличие от кластеров Microsoft, кластерное голосование Mongo не заботится о нескольких способах выхода из тупиковой ситуации в сети. Из-за этого отдельные арбитражные и внутренние сети кластера не обеспечивают значимого повышения устойчивости. Единственная причина, по которой вам нужна отдельная арбитражная сеть, - это если ожидалось, что трафик репликации будет настолько тяжелым, что пакеты выборов (на самом деле, тактовые импульсы) будут проталкиваться так далеко вниз по стеку, что он пропустит 10-секундный тайм-аут.