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

Kaspersky SD-WAN поддерживает несколько схем резервирования отдельных компонентов (см. таблицу ниже).

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

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

• оркестратор – orc;
• веб-интерфейс оркестратора – www;
• база данных оркестратора – orc-dbs;
• контроллер SD-WAN и его база данных – ctl;
• шлюз SD-WAN – GW.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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