Архитектура дистрибутива облачной платформы KeyStack ==================================================== Описание дистрибутива --------------------- KeyStack — дистрибутив облачной платформы от компании ITKey, основанный на OpenStack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Дистрибутив базируется на нескольких элементах: - CI-конвейер; - OpenStack IaaS; - OpenStack baremetal; - ELK (EFK) stack; - Prometheus. CI-конвейер состоит из следующего набора компонентов: **GitLab** GitLab — это инструмент для хранения и управления репозиториями Git. Помимо хранения кода, он позволяет организовать процесс CI/CD. Подробнее ознакомиться с документацией по GitLab можно тут: https://docs.gitlab.com/. **Hashicorp Vault** | Программное решение, которое помогает организациям снизить риск взлома и раскрытия данных с помощью автоматизации безопасности на основе идентификации и шифрования как услуги. В решении используется функционал хранения чувствительной информации — паролей, токенов, SSL-сертификатов и другой чувствительной информации. | Подробнее ознакомиться с документацией по vault можно тут: https://developer.hashicorp.com/vault/docs. **Sonatype Nexus** Это программный продукт, реализующий функционал управления репозиториями. Используется для хранения докер-образов, pip,rpm, deb и прочих артефактов. Подробнее ознакомиться с решением можно тут: https://www.sonatype.com/products/sonatype-nexus-repository. **Netbox** Это веб-приложение с отрытым исходным кодом, предназначенное для моделирования и документирования современных сетей. Сочетая традиционные практики управления IP-адресами (IPAM) и управления инфраструктурой центра обработки данных (DCIM) с мощными API и расширениями, NetBox представляет собой идеальный "источник достоверной информации" для автоматизации сети. Подробнее ознакомиться с документацией можно тут: https://docs.netbox.dev/en/stable/. **Openstack** Openstack — это набор технологий с открытым исходным кодом. Платформа OpenStack управляет ресурсами виртуальной инфраструктуры, включая виртуальные серверы, устройства хранения, сети и сетевые службы, такие как балансировщики нагрузки, а также предоставляет функции управления пользователям-арендаторам. Подробнее ознакомиться с документацией можно тут: https://docs.openstack.org/. ---- Гостевые/Хост ОС и гипервизоры ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ В качестве хост ОС KeyStack использует дистрибутив на базе Ubuntu linux актуальной LTS версии. При необходимости в качестве хост ОС возможно использование дистрибутива Астра Линукс. В качестве гостевых ОС поддерживаются распространённые ОС Linux и MS Windows. Со списком поддерживаемых гостевых ОС можно ознакомиться по ссылке: https://www.linux-kvm.org/page/Guest_Support_Status. В качестве базового гипервизора используется KVM как самый зрелый и проверенный гипервизор. При необходимости возможно использование гипервизора VMware ESXi (в рамках существующей инсталляции VMware vSphere). Работа с Baremetal серверами ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ KeyStack Baremetal поддерживает следующие действия с поддерживаемыми физическими серверами: - Установка ОС на сервера; - Подключение в сеть; - Базовые действия администрирования (start/restart/stop/delete); - Подключение СХД к серверам. Сервис объектного хранилища (в дорожной карте) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ В дистрибутиве предусмотрен сервис объектного хранилища. Его особенности: - Построен на базе CEPH, в Single-site и Multi-site конфигурациях; - Хранение образов OpenStack Glance, из которых развёртываются ВМ; - Предоставления S3-совместимого хранилища потребителям платформы. Работа с учетными записями ~~~~~~~~~~~~~~~~~~~~~~~~~~ В качестве основы для управления учетными записями используется Keycloak. Keykloak позволяет решить следующие задачи: - Централизованное управление учётными записями; - Обеспечение политик безопасности — срок действия учётной записи, срок действия пароля и др.; - Возможность интеграции со службой каталогов Заказчика (LDAP, AD, SAML, OpenID). Мониторинг ~~~~~~~~~~ В референс-архитектуре KeyStack в качестве системы мониторинга используется Prometheus. OpenStack имеет хорошую совместимость с Prometheus, возможна интеграция на уровне: - Агентов мониторинга на хост-ОС; - Экспортеров OpenStack для мониторинга состояния виртуальной инфраструктуры; - Возможно произвести интеграцию с существующей платформой мониторинга клиента. ---- Преимущества и сценарии использования KeyStack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | **CI/CD-конвейер** | KeyStack основан на CI-конвейере (применяется для деплоя инсталляции). Это позволяет использовать KeyStack в цепочке существующего CI/CD-конвейере клиента. | **Multi-site облако** | Возможно использование KeyStack в качестве отказоустойчивой облачной платформы, размещённой в нескольких ЦОД с общей сетевой связностью. | **Публичное облако** | KeyStack полностью подходит в качестве платформы для создания и предоставления услуг публичного облака (однако не является платформой для биллинга; при необходимости потребуется интеграция со сторонней биллинговой системой). | **Частное облако** | KeyStack архитектурно и функционально отлично подходит для создания частного облака. | **Предоставление хранилища S3** | В дорожной карте KeyStack запланирована реализация CEPH с возможностью организовать S3 с неограниченной масштабируемостью. ---- Архитектура KeyStack -------------------- KeyStack основан на технологии OpenStack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. figure:: Media/Pic_01.png :alt: OpenStackScheme Основные модули KeyStack ~~~~~~~~~~~~~~~~~~~~~~~~ .. list-table:: :header-rows: 1 * - Наименование - Краткое описание * - OpenStack Nova - Контроллер вычислительных ресурсов, отвечает за создание ВМ * - OpenStack Keystone - Сервис идентификации, отвечает за аутентификацию и авторизацию всех субъектов в KeyStack * - OpenStack Neutron - Контроллер программно-определяемых сетей в KeyStack, отвечает за управление виртуальными сетями тенантов (проектов) * - OpenStack Glance - Библиотека образов виртуальных машин, отвечает за хранение образов ОС для последующего развёртывания ВМ * - OpenStack Cinder - Сервис работы с блочными устройствами хранения данных, отвечает за предоставления ВМ дискового пространства и операции с дисковым пространством * - OpenStack Horizon - Графический интерфейс администрирования * - OpenStack Heat - Инфраструктурный оркестратор * - OpenStack Barbican - Сервис безопасного хранения секретов (пароли, ключи, X509 сертификаты) * - OpenStack Octavia - Контроллер сетевых балансировщиков как сервис * - OpenStack Ironic - Сервис управления и провижининга физическими серверами (Bare Metal Provisioning) * - OpenStack Designate - Контроллер DNS как сервис * - HA модуль ITKey - Контроллер HA для виртуальных машин * - DRS модуль ITKey - Контроллер DRS для виртуальных машин Одним из важнейших модулей KeyStack является сервисный оркестратор (построен на базе CI/CD-пайплайнов), предназначенный для централизованного управления инфраструктурой. Возможности встроенного сервисного оркестратора KeyStack: - Управление multi-site инфраструктурой — при деплое большой инсталляции (>1500 хостов) применяется схема разделения инсталляции на regions и cells, и сервисный оркестратор позволяет управлять разными регионами как единым облаком; - Сервисный каталог — портал с XaaS услугами в режиме самообслуживания; - Day-2 автоматизация — автоматизация жизненного цикла сервисов после создания; - Управление kubernetes-инфраструктурой. :bolditalic:`Разработка UI к Сервисному оркестратору запланирована в дорожной карте продукта.` Подробнее об основных модулях можно прочитать в этом разделе. В работе OpenStack задействованы как основные, так и вспомогательные сервисы. Основные сервисы: - Compute service; - Networking service; - Loadbalancing service; - Image service; - Volume service; - Identity service; - Dashboard. Вспомогательные сервисы: - DNS service; - Network loadbalancing service; - Orchestartion service; - Key manager service. Compute service (Nova) ^^^^^^^^^^^^^^^^^^^^^^ | Nova — сервис, который управляет гипервизорами, виртуальными машинами, жизненным циклом виртуальных машин и предоставляет API-интерфейс. | Nova состоит из следующих компонентов: | **Nova-api** | Сервис, который принимает и отвечает на API-вызовы конечных пользователей. Обеспечивает соблюдение некоторых политик и инициирует большинство действий по оркестрации, таких как запуск экземпляров виртуальных машин. | **Nova-scheduler** | Сервис, который вычитывает сообщения из очереди и определяет, на каком гипервизоре запустится виртуальная машина. | **Nova-conductor** | Осуществляет взаимодействие между сервисом ``nova-compute`` и базой данных. Это исключает прямой доступ к облачной базе данных, осуществляемый ``nova-compute``. | **Nova-compute** | Демон, который создает и завершает экземпляры виртуальных машин через API гипервизора. Например: - libvirt для KVM или QEMU - VMwareAPI для VMware Обработка достаточно сложна. По сути, демон принимает действия из очереди сообщений и выполняет ряд системных команд, таких как запуск экземпляра KVM и обновление его состояния в базе данных. | **Nova-ssh** | Это SSH-сервер, обеспечивающий транспорт для rsync xml-описаний виртуальных машин для миграций между гипервизорами. | **Nova-libvirt** | Libvirt — наиболее часто используемый драйвер виртуализации в OpenStack. Он использует libvirt при поддержке QEMU и, если доступно, KVM. Libvirt выполняется в контейнере ``nova_libvirt`` или как демон, работающий на хосте. | **Nova-novncproxy** | Серверный демон. Обслуживает службу Nova noVNC Websocket Proxy, которая предоставляет websocket-proxy, совместимый с консолями OpenStack Nova noVNC. | **Nova-serialproxy** | Серверный демон. Обслуживает службу Nova Serial Websocket Proxy, которая предоставляет websocket-proxy, совместимый с последовательными портами OpenStack Nova. Подробнее о возможностях Nova, его настройке и возможностях можно узнать тут: https://docs.openstack.org/nova/latest/. Полезные опции: Для вычислительных узлов важно, чтобы они не испытывали недостатка в памяти, дисковой емкости и ядрах процессора. Для этого можно использовать следующие параметры: - ``reserved_host_cpus`` - ``reserved_host_memory_mb`` - ``reserved_host_disk_mb`` Также можно настроить коэффициенты переподписки по памяти, дискам и процессорам: - ``cpu_allocation_ratio`` - ``disk_allocation_ratio`` - ``ram_allocation_ratio`` Существуют параметры, которые позволяют задать начальные значения коэффициентов и использовать API-вызовы для их изменения их значений без перезапуска служб Nova-compute: - ``initial_cpu_allocation_ratio`` - ``initial_ram_allocation_ratio`` - ``initial_disk_allocation_ratio`` Задавать значения данных параметров можно как для конкретных гипервизоров, так и для всех сразу. Для всех гипервизоров сразу — в секцию [DEFAULT] в файле конфигурации ``config/nova/nova-compute.conf``. Для конкретного гипервизора — ``config/nova//nova.conf``. Volume service (Cinder) ^^^^^^^^^^^^^^^^^^^^^^^ Служба хранилища блоков OpenStack (Cinder) добавляет виртуальным машинам постоянное хранилище. Оно предоставляет инфраструктуру для управления дисками и взаимодействует с вычислительными ресурсами OpenStack, чтобы предоставить экземплярам диски. Служба также позволяет управлять снимками томов и типами томов. Служба хранилища блоков состоит из следующих компонентов: | **Cinder-api** | Принимает запросы API и перенаправляет их в ``cinder-volume`` для выполнения действий. | **Cinder-volume** | Взаимодействует напрямую со службой хранилища блоков и с такими процессами, как ``cinder-scheduler``. Кроме того, взаимодействует с этими процессами при помощи очереди сообщений. Служба ``cinder-volume`` отвечает на отправленные службе хранилища блоков запросы чтений и записи, чтобы поддерживать состояние. Может взаимодействовать с разными производителями хранилищ с помощью драйверов. | **Cinder-scheduler** | Выбирает оптимальный узел производителя хранилища, на котором будет создан том. Похож на компонент ``nova-scheduler``. | **Cinder-backup** | Служба ``cinder-backup`` обеспечивает резервное копирование томов любого типа в хранилище резервного копирования. Аналогично службе ``cinder-volume``, может взаимодействовать с различными производителями хранилищ с помощью драйверов. В Openstack в качестве системы очередей используется rabbitmq. Взаимодействие между службами Cinder происходит именно через этот сервис. Подробнее о службе Cinder и его возможностях и сценариях использования можно почитать в официальной документации: https://docs.openstack.org/cinder/latest/. Orchestartion service (Heat) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Heat — основной проект в программе OpenStack Orchestration. Он реализует механизм оркестрации для запуска нескольких составных облачных приложений на основе шаблонов в виде текстовых файлов, которые можно рассматривать как код. Собственный формат шаблонов Heat развивается, но Heat также стремится обеспечить совместимость с форматом шаблонов `AWS CloudFormation `__, чтобы многие существующие шаблоны CloudFormation можно было запускать в OpenStack. Heat предоставляет как `собственный REST API OpenStack `__, так и API-запросы, совместимые с CloudFormation. Служба оркестрации состоит из следующих компонентов: | **Heat-api** | Компонент Heat-api предоставляет `собственный REST API OpenStack `__, который обрабатывает запросы API и перенаправляет их в ``heat-engine`` для выполнения действий. | **Heat-api-cfn** | Компонент Heat-api-cfn предоставляет API-запросы в стиле AWS, совместимый с AWS CloudFormation, и обрабатывает API-запросы и перенаправляет их в ``heat-engine`` для выполнения действий. | **Heat-engine** | Компонент Heat-engine выполняет основную работу по организации запуска шаблонов и передаче событий обратно потребителю API. В Openstack в качестве системы очередей используется rabbitmq. Взаимодействие между службами Heat происходит именно через этот сервис. Подробнее о службе Heat, ее возможностях и сценариях использования можно почитать в официальной документации: https://docs.openstack.org/heat/latest/. Image service (Glance) ^^^^^^^^^^^^^^^^^^^^^^ Служба Glance позволяет пользователям обнаруживать, регистрировать и получать образы виртуальных машин. Она предлагает `REST API `__, который позволяет запрашивать метаданные образа виртуальной машины и получать реальный образ. Вы можете хранить образы виртуальных машин в различных местах: от простых файловых систем до систем объектного хранения, таких как OpenStack Object Storage. | **Glance-api** | Служба Glance-api принимает API вызовы и позволяет обнаруживать, сохранять и получать информацию об образах. Как правило, используется для загрузки образов виртуальных машин. Подробнее о службе Glance, ее возможностях и сценариях использования можно почитать в официальной документации: https://docs.openstack.org/glance/latest/. Identity service (Keystone) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Служба keystone oбеспечивает аутентификацию и авторизацию клиентов через API-интерфейсы, а также распределенную многопользовательскую авторизацию. Поставщик токенов Keystone настраивается через ``keystone_token_provider``. Значением по умолчанию для этого является ``fernet``. | **Токены Fernet** | Токены Fernet требуют использование ключей, которые необходимо синхронизировать между серверами Keystone. Для этого Kolla Ansible развертывает два контейнера — ``keystone_fernet``, который запускает задания cron для ротации ключей через rsync, когда это необходимо, и\ ``keystone_ssh``— SSH-сервер, обеспечивающий транспорт для rsync. Подробнее о службе Keystone, возможностях и сценариях использования можно почитать в официальной документации: https://docs.openstack.org/keystone/latest/. Loadbalancing service (Octavia) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Octavia предоставляет интерфейс управления, позволяющий создавать балансировщики нагрузки и управлять ими. Поддерживает функционал создания отказоустойчивых конфигураций балансировщиков, создания правил и условий балансировки на основании широкого спектра параметров. Octavia состоит из следующих компонентов: | **Octaiva-api** | Сервис, который принимает и отвечает на API-вызовы конечных пользователей, а также помещает в очередь сообщений для вычитывания сервисом ``octavia-worker``. | **Octavia-worker** | Сервис, который вычитывает сообщения из очереди и отвечает за оркестрацию амфор. Он взаимодействует с вычислительным драйвером (в некоторых сценариях развертывания), сетевым драйвером и драйвером Amphora для активации экземпляров Amphora, балансировщиков нагрузки и прослушивателей. | **Octavia-health-manager** | Осуществляет проверку на отсутствующие или нездоровые амфоры в базе данных. Монитор работоспособности проверяет временные метки через настраиваемый интервал, чтобы увидеть, не предоставила ли Amphora контрольный сигнал в течение необходимого периода времени. Если Amphora не сможет сообщить о тактовом сигнале в течение настроенного интервала, диспетчер работоспособности инициирует отработку отказа Amphora и обновит статус прослушивателя в базе данных. Диспетчеру работоспособности необходимо будет знать о балансировщике нагрузки, связанном с отказавшим прослушивателем, чтобы решить, нужно ли ему выполнять отработку отказа дополнительных прослушивателей для миграции отказавшего прослушивателя на новую Amphora. | **Octavia-housekeeping** | Управляет запасным пулом амфор и демонтажем амфор, которые больше не нужны. Через настраиваемый интервал времени сервис будет проверять базу данных Octavia, чтобы определить необходимые действия по очистке и обслуживанию. В спецификации управления жизненным циклом амфоры подробно описаны последовательности создания, резервирования и удаления амфор. Key manager service (Barbican) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Barbican — сервис, который обеспечивает безопасное хранение, предоставление и управление данными для доступа. Barbican обеспечивает управление секретами, ключами и сертификатами, поддерживает генерацию симметричных и асимметричных ключей с использованием различных алгоритмов. Служба Barbican состоит из следующих компонентов: | **Barbican-api** | Предоставляет RESTful API, который поддерживает предоставление секретов Barbican и управление ими. | **Barbican-worker** | Предоставляет интерфейс Openstack RPC, который взаимодействует с ``barbican-api`` очередью сообщений Barbican, читает ее и принимает задания на выполнение. | **Barbican-keystone-listener** | Прослушивает сообщения службы уведомлений Keystone. Используется для управления представлением проектов Keystone в базе данных Barbican при удалении проектов. Подробнее узнать о возможностях Barbican, его настройке и возможностях можно тут: https://docs.openstack.org/barbican/latest/ Dashboard (Horizon) ^^^^^^^^^^^^^^^^^^^ Предоставляет графический веб-интерфейс, предназначенный для управления виртуальной инфраструктурой пользователями в рамках предоставленных прав доступа. Подробнее: https://docs.openstack.org/horizon/latest/. | **Реализация отказоустойчивости** | Отказоустойчивость инсталляций реализуется следующими механизмами защиты (с 100%̆ совместимостью с upstream-кодом): - **Control plane:** - Выделяется 3 или более контроллеров для создания кворума; - Все API-сервисы OpenStack — stateless, и они запускаются на каждом контроллере с балансировкой haproxy; - Кластеризуемые сервисы разворачиваются в режиме "Active-Active" ; - Защита СУБД осуществляется с помощью MariaDB Galera. - **Data plane:** - Мощности Data plane рассчитываются с запасом, чтобы HA-модуль ITKey смог отработать. ---- Характерные проблемы инсталляций upstream OpenStack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Одним из важных отличий KeyStack является качественная проработка архитектуры решения, которая обеспечивает отсутствие проблем, присущих большим инсталляциям OpenStack: - В OpenStack все коммуникации происходят через очередь сообщений RabbitMQ и общую СУБД, которые имеют проблемы масштабирования/кластеризации и восстановлении работоспособности после сбоя. При увеличении количества узлов количество сообщений в очереди растёт в геометрической прогрессии; - Neutron ML2 OVS — нагрузка растёт в геометрической прогрессии ввиду принципа управления сетевой инфраструктурой через агенты, которые также используют очередь сообщений. Решение ~~~~~~~ - Multi-site облако разделяется на Regions (создаются домены отказа со своими собственными изолированными control plane); - При необходимости возможно выделение нескольких Nova Cell внутри Region; - Cell, в отличие от Region, имеет общий сервис Nova, что позволяет как потребителям, использующим API, так и пользователям в графическом портале прозрачно управлять созданием виртуальных машин в разных Cell через единую точку входа; - Функционал Nova Cell позволяет масштабировать Nova. С ним Nova нормально управляет несколькими тысячами хостов, тогда как без него предел — 2-3 сотни; - В OpenStack "Из коробки" невозможна миграция ВМ между Region. Также доступна только холодная миграция между Cell. В KeyStack этот функционал (холодная миграция между Region) запланирован в дорожной карте, или его можно использовать партнерским решением Hystax DR; - Availability Zones (AZ) в KeyStack — логическая группировка гипервизоров, сетевых и baremetal-функций. По сути, AZ — это параметры настройки планировщика для правильного размещения объектов внутри KeyStack в момент их создания. В нашей облачной платформе мы рекомендуем создавать AZ в рамках Cell и не растягивать AZ на несколько Cells, чтобы соблюдать идеологию доменов отказоустойчивости; - Мы рекомендуем использовать OVS-плагин для Neutron как более стабильное и задокументированное решение. - Мы рекомендуем рассмотреть OVN-плагин для Neutron при необходимости масштабирования более чем 200 узлов. Сегментация нагрузок в KeyStack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. list-table:: :header-rows: 1 * -   - Cells - Regions - Availability Zones - Host Aggregates * - Когда использовать? - Единый API-endpoint для compute или необходимость в дополнительном уровне планировщика Nova - Отдельный регион с собственными API-endpoints без координации между регионами - Для создания группы хостов с общими признаками (не ограничивается Nova) - Логическое разделение Nova на группы хостов (гипервизоров) * - Пример - Облако, распределённое на множество площадок, где вы можете создать ВМ "где угодно" или на конкретной площадке - Облако, распределённое на множество площадок, где вы можете создать ВМ на конкретной площадке - Облако на одной площадке с серверами, запитанными от разных источников - Распределение нагрузки по группам серверов с разными характеристикам и или PCI-устройствами * - Избыточность - Самая молодая сегрегация. Каждый cell — отдельная БД и менеджер очередей с общими сервисами Nova - Различные API-endpoints для каждого региона. Каждый регион имеет свой control-plane - Правка конфигурации в nova.conf и OpenStack БД - Правка конфигурации в nova.conf и OpenStack БД * - Общие сервисы - Все сервисы - Можно Keystone - Все сервисы - Все сервисы Выбор multi-site архитектуры ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ В зависимости от требований Заказчика, KeyStack можно развернуть в трех основых конфигурациях multi-site ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **Вариант 1** .. figure:: Media/Pic_02.png :alt: Multi-site 1 - Возможность миграции ВМ внутри Cell (ИС), растянутой между ЦОДами; - Один домен отказа; - Можно нивелировать детальной проработкой архитектуры домена. **Вариант 2** .. figure:: Media/Pic_03.png :alt: Multi-site 2 - Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа; - N доменов отказа; - В роадмапе есть возможность холодной миграции между Region; - Возможно проработать использование механизмов репликации на базе СХД. **Вариант 3** .. figure:: Media/Pic_04.png :alt: Multi-site 3 - Возможность миграции ВМ внутри Cell (ИС) внутри одного ЦОДа; - N доменов отказа; - Возможность горячей или холодной миграции средствами партнерского ПО Hystax. -------------- Сетевая архитектура KeyStack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **В референсной архитектуре KeyStack предлагается использовать OVS для управления сетевой инфраструктурой в OpenStack-облаке.** +-----------------------+----------------------------+---------------------------------------------------------------------+ | SDN | Плюсы | Минусы | +=======================+============================+=====================================================================+ | OVS | Проверенное годами решение | Схема с агентами и RabbitMQ налагает ограничения на масштабирование | +-----------------------+----------------------------+---------------------------------------------------------------------+ Маршрутизация трафика виртуальной инфраструктуры во внешние сети ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Для примера на схеме отображены 2 варианта маршрутизации: 1. Трафик VM1, VM6 маршрутизируется через Gateway-узлы при помощи SNAT. 2. На виртуальные машины VM3, VM4, VM5 назначен Floating IP (назначаемый внешний адрес), и их трафик проходит напрямую во внешнюю сеть без Gateway-узлов. |Routing| ---- Прочие функции KeyStack ~~~~~~~~~~~~~~~~~~~~~~~ | **В KeyStack реализован функционал фильтрации трафика на портах ВМ.** | Таким образом, сетевые потоки могут быть отфильтрованы согласно требованиям ИБ Заказчика: .. figure:: Media/Pic_07.png :alt: Filyering | **В KeyStack реализован сервис LBaaS.** | Сервис LBaaS построен на основе OpenStack Octavia и предоставляет сетевые балансировщики как сервис. .. figure:: Media/Pic_08.png :alt: LBaaS Octavia позволяет создавать балансировщики в виртуальных машинах, контейнерах или на baremetal, а также поддерживает следующие типы балансировки: - HTTP-балансировка; - HTTP-балансировка с health-монитором; - Session-persistent HTTP-балансировка; - TCP-балансировка; - UDP-балансировка; - QoS ruled-балансировка; - Балансировка с ACL по IP; - Non-terminated HTTPS-балансировка; - TLS-terminated HTTPS-балансировка; - TLS-terminated HTTPS-балансировка с SNI; - TLS-terminated HTTPS-балансировка c аутентификацией; - HTTP/2-балансировка с ALPN TLS расширением; - Другие режимы балансировки. .. |Routing| image:: Media/Pic_05.png