Резервирование центральных компонентов решения
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 |
Пример размещения компонентов решения в географически разнесенных ЦОД представлен на рисунке ниже. На всех последующих рисунках используются одинаковые условные обозначения:
- оркестратор – 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 недоступна.