Резервирование компонентов решения

Развернуть всё | Свернуть всё

О схемах резервирования компонентов решения

Kaspersky SD-WAN поддерживает две схемы развертывания компонентов решения:

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

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

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

Когда вы настраиваете параметры развертывания узлов базы данных MongoDB или контроллера в соответствии со схемой развертывания 2N+1, последний указанный вами узел становится узлом-арбитром. Узел-арбитр связан с другими узлами и используется для выбора основного узла. Узел, который потерял связь с узлом-арбитром, переходит в режим ожидания. Один из узлов, которые сохранили связь с узлом-арбитром, остается или становится основным узлом. Узел-арбитр не может стать основным узлом и не хранит данные.

Сценарии выхода из строя узлов компонентов решения

На рисунке ниже изображена схема Kaspersky SD-WAN, развернутого на трех виртуальных машинах в центре обработки данных. В схеме используются следующие условные обозначения:

• www – frontend-часть решения;
• orc – оркестратор;
• mongo – база данных MongoDB;
• redis-m – сервер Redis replica;
• redis-s – система Redis Sentinel;
• vnfm-proxy – прокси-менеджер виртуальных сетевых функций;
• vnfm – менеджер виртуальных сетевых функций;
• ctl – контроллер и его база данных;
• zabbix-www – frontend-часть системы мониторинга Zabbix;
• zabbix-proxy – сервер Zabbix-прокси;
• zabbix-srv – сервер Zabbix;
• zabbix-db – база данных системы мониторинга Zabbix;
• syslog – Syslog-сервер.

Пользователи и устройства CPE получают доступ к веб-интерфейсу оркестратора и веб-интерфейсу системы мониторинга Zabbix с помощью виртуального IP-адреса. Виртуальный IP-адрес назначен виртуальной машине 1.

Решение, развернутое на трех виртуальных машинах

В рамках представленной схемы развертывания возможны следующие сценарии аварийных ситуаций:

• Выход из строя виртуальной машины 1 или ее соединения.

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

  • Виртуальный IP-адрес назначается виртуальной машине 2.
  • Узел frontend-части решения www-1 недоступен, www-2 доступен. Веб-интерфейс оркестратора отображается в браузере.
  • Узел оркестратора orc-1 недоступен, orc-2 доступен. Backend-часть решения работает, пользователи могут войти в веб-интерфейс оркестратора и использовать его.
  • Узел базы данных MongoDB mongo-1 недоступен, mongo-2 и mongo-3 доступны, mongo-2 становится основным узлом, так как mongo-3 является узлом-арбитром и не может стать основным узлом. Оркестратор продолжает использовать базу данных MongoDB.
  • Состояние базы данных Redis:
    • Узел сервера Redis replica redis1-m недоступен, redis2-m и redis3-m доступны.
    • Узел системы Redis Sentinel redis1-s недоступен, redis2-s и redis3-s доступны, redis2-s становится основным узлом и случайным образом назначает узел сервера Redis replica redis2-m или redis3-m основным узлом.

    Оркестратор продолжает использовать базу данных Redis.

  • Состояния менеджера виртуальных сетевых функций:
    • Узел прокси-менеджера виртуальных сетевых функций vnfm-proxy-1 недоступен, vnfm-proxy-2 доступен.
    • Узел менеджера виртуальных сетевых функций vnfm-1 недоступен, vnfm-2 доступен.

    SSH-консоли компонентов решения работают.

  • Узел контроллера ctl-1 недоступен, ctl-2 и ctl-3 доступны, ctl-2 становится основным узлом, так как ctl-3 является узлом-арбитром и не может стать основным узлом. Сохраняется сетевая связность между устройствами CPE.
  • Состояние системы мониторинга Zabbix:
    • Узел frontend-части решения zabbix-www-1 недоступен, zabbix-www-2 доступен.
    • Узел сервера Zabbix-прокси zabbix-proxy-1 недоступен, zabbix-proxy-2 доступен.
    • Узел сервера Zabbix zabbix-srv-1 недоступен, zabbix-srv-2 доступен.
    • Узел базы данных системы мониторинга Zabbix zabbix-db-1 недоступен, zabbix-db-2 доступен.

    Система мониторинга Zabbix работает.

• Выход из строя виртуальной машины 2 или 3, или ее соединения.

  При выходе из строя виртуальной машины 2 или 3, или ее соединения узлы компонентов решения, развернутые на виртуальной машине 1, остаются основными и решение сохраняет работоспособность.

• Одновременный выход из строя виртуальных машин 1 и 3 или 2 и 3, или их соединений.

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

  • Веб-интерфейс оркестратора не отображается в браузере. Пользователи не могут войти в веб-интерфейс оркестратора и использовать его.
  • Система мониторинга Zabbix прекращает работу.
  • Сохраняется сетевая связность между устройствами CPE и подключенными к ним сетевыми устройствами, трафик продолжает передаваться.
  • Сохраняется сетевая связность в рамках P2P-сервисов и TAP-сервисов.
  • Сохраняется сетевая связность в рамках P2M-сервисов и M2M-сервисов для установленных сессий. Для новых сессий сетевая связность сохраняется, если при создании P2P-сервиса или M2M-сервиса в раскрывающемся списке Режим изучения MAC вы выбрали значение Learn and flood.
  • Устройства CPE используют механизм компенсации реордеринга (англ. reordering) для снижения количества дублированных пакетов на сетевых устройствах, подключенных к этим устройствам CPE.
  • Нагрузка на устройства CPE и сеть SD-WAN возрастает соразмерно количеству устройств CPE и соединений.

  Если соединения восстанавливаются, решение также восстанавливается и продолжает работать в нормальном режиме.

  При одновременном выходе из строя виртуальных машин 1 и 3 или 2 и 3 происходит потеря конфигурации компонентов решения. Для восстановления конфигурации компонентов решения вы можете обратиться в Kaspersky Professional Services.

• Одновременный выход из строя виртуальных машин 1 и 2.

  При одновременном выходе из строя виртуальных машин 1 и 2 происходит потеря конфигурации компонентов решения без возможности восстановления, так как на виртуальной машине 3 развернуты узлы-арбитры, которые не хранят данные. Для предотвращения такой ситуации мы рекомендуем развертывать базы данных и контроллеры на отдельных виртуальных машинах или физических серверах и делать регулярные резервные копии.