Содержание
Резервирование и отказоустойчивость
Отказоустойчивость обеспечивает последовательную и непрерывную передачу трафика по сети SD-WAN, а также работу сетевых сервисов. Ее уровень повышается за счет применения механизмов резервирования и аварийного переключения на разных уровнях инфраструктуры сети, например, когда вы создаете резервные сервисные интерфейсы.
Если сеть является отказоустойчивой, она может сохранить свою работоспособность как при возникновении небольших проблем, так и серьезных аварий, связанных с функционированием центральных компонентов, таких как маршрутизаторы, туннели и центры обработки данных. Когда один из компонентов перестанет выполнять назначенные ему функции, его место занимает резервный компонент такого же типа. Например, вы можете построить резервный туннель, на который трафик будет передан, если основной туннель будет недоступен.
Отказоустойчивость упрощает балансировку нагрузки между несколькими туннелями, позволяя оптимизировать использование полосы пропускания трафика и избежать перегрузок. В этом случае ни один из существующих туннелей не может стать узким местом (англ. bottleneck) в топологии сети.
Kaspersky SD-WAN обеспечивает непрерывную работу в случае возникновения следующих видов сбоев:
- отказ одного из центральных компонентов, например , шлюза или ;
- отказ или перегрузка каналов передачи данных между центральными компонентами при их георезервировании, когда компоненты сети размещаются на географически разнесенных площадках, чтобы сделать хранение данных более надежным;
- отказ или перегрузка каналов передачи данных между и шлюзами SD-WAN.
Резервирование центральных компонентов решения
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 недоступна.
Резервирование каналов передачи данных между устройствами CPE
Kaspersky SD-WAN обеспечивает защиту от перерывов связи между устройствами CPE, одновременно используя все доступные каналы передачи данных, например интернет-каналы или LTE-каналы.
Режим Active/Active
В этом режиме все WAN-интерфейсы устройств CPE находятся в активном состоянии и передают трафик пользователей.
Контроллер SD-WAN обеспечивает балансировку трафика с использованием от 2 до 16 транспортных путей (англ. multipathing). Балансировка равномерно распределяет трафик по туннелям, что позволяет предотвратить перегрузку отдельных туннелей и возникновение проблем с производительностью у пользователей. Поддерживается три режима балансировки:
- По потокам (англ. per flow) с учетом информации на уровнях L2–L4. В этом режиме доступно два типа балансировки:
- Эквивалентная балансировка – потоки распределяются равномерно по транспортным путям.
- Неэквивалентная балансировка – потоки распределяются по транспортным путям пропорционально стоимости туннелей.
- По пакетам (англ. per packet) – пакеты распределяются пропорционально стоимости туннелей при передаче.
- Широковещательный (англ. broadcast) – пакеты передаются одновременно во все туннели для исключения потерь.
В режиме Active/Active устройство CPE остается доступным, пока сохраняется работоспособность хотя бы одного канала передачи данных.
Режим Active/Standby
В этом режиме вам нужно выбрать основной и резервный транспортный путь для передачи трафика. Балансировка при этом не используется. На устройство CPE заранее загружаются правила использования резервного WAN-интерфейса в ситуации, когда путь через основной WAN-интерфейс становится недоступным. В этом случае при нарушении работы основного транспортного пути не производится переписывание правил коммутации пакетов, и устройство отправляет их через резервный интерфейс.
Вы можете настроить резервирование на уровне транспортных сервисов. При создании транспортного сервиса указываются резервные сервисные интерфейсы (англ. reserve SI) на выбранном устройстве CPE или на другом устройстве. Мы рекомендуем создавать основной и резервный сервисные интерфейсы на разных устройствах. Трафик переключается на резервный сервисный интерфейс, если основной сервисный интерфейс недоступен.
Решение поддерживает создание резервных сервисных интерфейсов для всех типов транспортных сервисов уровня L2.
На рисунках ниже представлены основные примеры перерывов связи между устройствами CPE:
- Выход из строя одного из устройств CPE.
- Выход из строя WAN-интерфейса одного из устройств CPE.
- Выход из строя связности между двумя устройствами CPE.
- Выход из строя LAN-интерфейса одного из устройств CPE.