[Эта статья была первоначально написана Shay Naeh.]
В моем предыдущем посте я обсуждал необходимость виртуализации сетевых функций в облаке. В этом посте я собираюсь погрузиться в реальный сценарий, который МОЖЕТ попробовать дома. (Действительно, мы также поддерживаем локальное облако, помните?)
Напомним, что основные проблемы виртуализации сетевых компонентов в облаке обычно связаны с автоматизацией, будь то на этапе развертывания или после развертывания:
- Автоматическое развертывание
- оркестровка
- Мониторинг
- Самовосстановление
- Автоматическое масштабирование
Ниже показано, как я добился этого на OpenStack с помощью Cloudify.
Решение
Для автоматического развертывания и зависимостей между уровнями я использовал
Cloudify . Cloudify предоставляет простой способ написания рецептов и зависимостей между компонентами. В ходе эксперимента я снял с полки программное обеспечение, которое создает видеопотоки, и запустил его в веб-контейнере Tomcat. Я использовал Tomcat и виртуальный программный балансировщик нагрузки для обеспечения эластичности. Tomcat, в свою очередь, регистрируется с помощью виртуального балансировщика нагрузки, который я создал с использованием Apache. Здесь вы можете прочитать больше о Apache
mod_proxy_balancer . Apache LB — это функция виртуальной сети, которая направляет трафик на несколько видеопотоков на основе предварительно определенной политики. Я использовал простую политику циклического перебора для равномерного распределения запросов между серверами Tomcat.
Я также использовал соединитель Tomcat, поэтому всякий раз, когда запускается новый Tomcat, он подключается к балансировщику нагрузки, объявляя о наличии дополнительного видеопотока, и вы можете направлять мне трафик, я доступен.
Для потокового видео я использовал Subsonic , что требовало минимальной настройки. Затем я загрузил различные файлы MP3 и MP4 (аудио и видео) и смог воспроизвести их в настольном браузере и на мобильных устройствах Android и iPhone, используя клиентское приложение, загруженное из Google Play и Apple App Store соответственно.
Обратите внимание, что видеопотоки Tomcat не могут запускаться до тех пор, пока не будет запущен LB, поэтому существует зависимость между Tomcat и LB. Эта зависимость отмечена в рецепте ниже, создание сервисов и зависимости между ними:
application {
name="subsonic"
service {
name = "apacheLB"
}
service {
name = "tomcat"
dependsOn =["apacheLB"]
}
}
Orchestration — Cloudify управляет оркестровкой сетевой инфраструктуры, которая обеспечивает возможность развертывания компонентов NFV. Cloudify определяет сети, подсети, группы безопасности, плавающие IP-адреса, сеть управления и сеть приложений в OpenStack. Подсети в Openstack зависят от сетей, созданных первыми. Вот фрагмент кода из драйвера Cloudify, который определяет сеть управления и условия для сети приложений:
cloudNetwork {
management {
networkConfiguration {
name "Cloudify-Management-Network"
subnets ([
subnet {
name "Cloudify-Management-Subnet"
range "177.86.0.0/24"
options ([ "gateway" : "177.86.0.111" ])
}
])
custom ([ "associateFloatingIpOnBootstrap" : "true" ])
}
}
templates ([
"APPLICATION_NET" : networkConfiguration {
name "Cloudify-Application-Network"
subnets {
subnet {
name "Cloudify-Application-Subnet"
range "160.0.0.0/24"
options { gateway "null" }
}
}
custom ([ "associateFloatingIpOnBootstrap" : "true" ])
}
])
}
Cloudify также управляет службами приложений и зависимостями, как определено выше.
Мониторинг является частью оркестровки и определяет метрики, которые будут собираться и действовать в соответствии с ними. Метриками могут быть, например, количество запросов, пропускная способность, которая фактически является количеством запросов в заданную единицу времени, специфичные для домена метрики, такие как Tomcat, занятые потоки и т. Д. Метрики используются для отображения текущего состояния системы, приложения и внутренних ресурсов. , Он также используется для дополнительных активных задач, таких как самоисцеление и автоматическое масштабирование, подробнее об этом в следующих разделах. Мониторы можно применять к любому источнику данных, используя различные методы сбора, такие как SNMP, CLI, JMX и т. Д. Ниже приведен пример мониторов, которые я использовал для сбора метрик с серверов Tomcat через JMX.
monitors {
def metricNamesToMBeansNames = [
"Current Http Threads Busy": ["Catalina:type=ThreadPool,name=\"http-bio-${currHttpPort}\"", "currentThreadsBusy"],
"Current Http Thread Count": ["Catalina:type=ThreadPool,name=\"http-bio-${currHttpPort}\"", "currentThreadCount"],
"Backlog": ["Catalina:type=ProtocolHandler,port=${currHttpPort}", "backlog"],
"Total Requests Count": ["Catalina:type=GlobalRequestProcessor,name=\"http-bio-${currHttpPort}\"", "requestCount"],
"Active Sessions": ["Catalina:type=Manager,context=/${ctxPath},host=localhost", "activeSessions"],
]
return getJmxMetrics("127.0.0.1",currJmxPort,metricNamesToMBeansNames)
}
Самовосстановление — когда умирает сервер Tomcat или умирает балансировщик нагрузки, Cloudify запускает новый. Cloudify знает это по постоянному мониторингу сервисов, которыми управляет. В случае сбоя службы он будет запущен автоматически, как указано в рецепте.
Автоматическое масштабирование. Что вы делаете, когда в вашей системе запускается больше нагрузки, больше пользователей и дополнительных транзакций, как вы увеличиваете ее емкость при высокой загрузке и уменьшаете ее в обычное время? Вы должны иметь гибкое автоматическое решение, решение для автоматического масштабирования.
Ниже приведена диаграмма архитектуры, на которой вы можете увидеть поток трафика от vLB к стримерам vVideo, а также генерацию нагрузки для имитации запросов, поступающих от реальных клиентов. Нагрузка генерируется для проверки правил автоматического масштабирования. В рецепте Tomcat я добавил следующие правила:
service {
extend "../../../services/tomcat"
elastic true
numInstances 2
minAllowedInstances 1
maxAllowedInstances 4
scalingRules ([
scalingRule {
serviceStatistics {
metric "Current Http Threads Busy"
statistics Statistics.maximumOfMaximums
movingTimeRangeInSeconds 1
}
highThreshold {
value 4
instancesIncrease 2
}
lowThreshold {
value 1
instancesDecrease 1
}
}
])
}
Это говорит Cloudify, которая управляет историей автоматизации, начинать с двух экземпляров Tomcat и на основе отслеживаемой метрики, называемой «Текущие HTTP-потоки заняты», увеличить количество серверов на два, если порог пересекает четыре (вы можете использовать более высокие числа, его настраивается). Я использовал четыре, чтобы сразу увидеть результаты. Cloudify получает количество занятых потоков от Tomcat, используя JMX, а затем сравнивает его с заданным порогом.
Вот экран Subsonic, как он выглядит в браузере на рабочем столе (это представление взято из Subsonic)
Используя мобильные телефоны некоторых друзей, мы смогли подключить множество мобильных телефонов, каждый из которых слушал свою музыку или просматривал собственное видео.
Как только LB работал, и после настройки файлов cookie для продолжения направления сеанса пользователя на тот же видеопоток, с которым пользователь начал работать, все работало гладко. Пользователи были направлены на видеопотоки, работающие на Tomcat, и когда видеопоток или, более точно, потоки Tomcat пересекали определенный порог, были добавлены дополнительные серверы Tomcats, автоматически зарегистрированные в LB и готовые принять дополнительных пользователей и запросы.
Еще одно слово об автоматическом масштабировании : когда система простаивала и ее использовали меньше клиентов, она освобождала серверы и уменьшала количество доступных стримеров vVideo. Другими словами, 100% эластичная система, растущая и уменьшающаяся по требованию.
Теперь я могу использовать виртуальный компонент LB в качестве виртуального компонента NFV для дополнительных целей, это уже существующий компонент NVF в моем каталоге.