Резервирование центральных компонентов решения

Kaspersky SD-WAN поддерживает две схемы развертывания компонентов: N+1 и 2N+1.

Схема развертывания N+1 подразумевает, что вместе с активным компонентом развертывается один резервный компонент. Если активный компонент выходит из строя, резервный компонент мгновенно занимает его место, обеспечивая непрерывность работы.

Схема развертывания 2N+1 является расширенной версией N+1 и отличается тем, что имеет дополнительный уровень резервирования. В рамках этой схемы активный компонент состоит из двух наборов. Они синхронизированы между собой, и один может занять место другого, если возникает неполадка. При этом также развертывается один дополнительный резервный компонент. Такая схема резервирования позволяет компонентам сохранять работоспособность, даже когда происходит несколько аварий подряд.

В таблице ниже представлены схемы резервирования и протоколы, которые используются для разных компонентов решения.

Схемы резервирования компонентов решения

Компонент

Схема резервирования

Используемый протокол

Оркестратор

N+1

REST

Веб-интерфейс оркестратора

N+1

REST

База данных оркестратора

2N+1

MONGODB

Контроллер SD-WAN и его база данных

2N+1

OPENFLOW (TLS)

Шлюз SD-WAN

N+1

GENEVE

Пример размещения компонентов решения в географически разнесенных ЦОД представлен на рисунке ниже. На всех последующих рисунках используются одинаковые условные обозначения:

Для компонентов решения, которые резервируются по схеме N+1, развертываются два узла в разных ЦОД. Каждый из узлов находится в активном состоянии. Вы можете выбрать узел, к которому направляются запросы, с помощью виртуального IP-адреса или службы DNS.

На схеме изображены три связанные между собой площадки с компонентами решения.

Размещение компонентов решения в географически разнесенных ЦОД

Компоненты, которые резервируются по схеме 2N+1, образуют кластер. Этот кластер содержит один основной узел и два резервных. Вы можете назначить один из узлов арбитром для экономии ресурсов и снижения требований к туннелям.

Если узел кластера назначен арбитром, он не содержит базу данных, и вы не можете сделать его основным. Узел-арбитр участвует в голосовании при выборе основного узла и обменивается с другими узлами периодическими служебными пакетами (англ. heartbeats).

На рисунке ниже представлен пример аварии на одной из площадок и ответная реакция решения. В этом примере показана авария, в ходе которой выходят из строя узлы кластера компонентов решения на площадке 1.

На схеме изображены три свзяанные между собой площадки. На площадке 1 происходит авария.

Авария на площадке 1

Если узлы кластера компонентов решения на площадке 1 выходят из строя, происходят следующие события:

  1. Узел orc-dbs 2 и узел-арбитр orc-dbs 3 теряют связь с узлом orc-dbs 1, после чего выбирают новый основной узел.
  2. Узел-арбитр orc-dbs 3 не может быть основным узлом, поэтому им становится узел orc-dbs 2 и сообщает оркестратору о своей роли.
  3. Узел ctl 2 и узел-арбитр ctl 3 теряют связь с узлом ctl 1, после чего выбирают новый основной узел.
  4. Узел-арбитр ctl 3 не может быть основным узлом, поэтому им становится узел ctl 2 и сообщает оркестратору о своей роли.

На рисунке ниже представлен пример аварии, в ходе которой выходят из строя узлы кластера компонентов решения на площадке 2.

На схеме изображены три связанные между собой площадки. На площадке 2 происходит авария.

Авария на площадке 2

Если узлы кластера компонентов решения на площадке 2 выходят из строя, происходят следующие события:

  1. Узел orc-dbs 1 и узел-арбитр orc-dbs 3 теряют связь с узлом orc-dbs-2, после чего узел orc-dbs 1 остается основным узлом.
  2. Узел ctl 1 и узел-арбитр ctl 3 теряют связь с узлом ctl 2, после чего узел ctl 1 остается основным узлом.

На рисунке ниже представлен пример аварии, в ходе которой прерывается соединение между площадками 1 и 2.

На схеме изображены три свзяанные между собой площадки. На соединении между площадками 1 и 2 происходит авария.

Авария на соединении между площадками 1 и 2

Если узлы кластера компонентов решения на площадках 1 и 2 не могут установить соединение друг с другом, происходят следующие события:

  1. Узел orc-dbs 1 теряет связь с узлом orc-dbs 2.
  2. Узел orc-dbs 1 остается основным узлом, потому что узел-арбитр orc-dbs 3 видит, что обе площадки работают в штатном режиме.
  3. Узел ctl 1 теряет связь с узлом ctl 2.
  4. Узел ctl 1 остается основным узлом, потому что узел-арбитр ctl 3 видит, что обе площадки работают в штатном режиме.

На рисунке ниже представлен пример аварии, в ходе которой прерывается соединение между площадкой 1 и остальными площадками.

На схеме изображены три свзяанные между собой площадки. На площадке соединениях между площадкой 1 и 2, а также 1 и 3 происходит авария.

Авария на соединениях между площадкой 1 и остальными площадками

Если узлы кластера компонентов решения на площадке 1 не могут установить соединение с остальными площадками, происходит следующие события:

  1. Узел orc-dbs 1 теряет связь с узлом orc-dbs 2.
  2. Узел orc-dbs 2 становится основным узлом и сообщает оркестратору о своей роли, потому что узел-арбитр orc-dbs 3 видит, что площадка 1 недоступна.
  3. Узел ctl 1 теряет связь с узлом ctl 2.
  4. Узел ctl 2 становится основным узлом и сообщает оркестратору о своей роли, потому что узел-арбитр ctl 3 видит, что площадка 1 недоступна.
В начало