Структура организации контроля и управления вычислительными системами постоянно развивалась — на смену среде с единственным выполняющимся процессом пришла более крупная, сложная и динамическая ее разновидность. Благодаря ей появилась возможность выполнения множественных процессов на различных географически рассредоточенных компьютерах, зона действия которых может охватывать несколько континентов.
Что такое автономные вычисления?
Термин “автономные вычисления”, используемый IBM, обозначает перенос бремени управления IT-системами с IT-специалистов на сами системы. Автономные вычисления — это способность компьютера автоматически управлять своей работой с помощью адаптивных технологий, расширяющих вычислительные возможности и сокращающих время, необходимое компьютерным специалистам для решения системных проблем и других вопросов обслуживания, таких как обновление ПО.
4 актуальных аспекта самоуправления, свойственных автономным вычислениям:
1. Самонастройка
Существующие вычисления. Корпоративные дата-центры включают многочисленный штат разработчиков и платформы. Установка, настройка и интеграция систем требуют временных затрат и чреваты ошибками.
Автономные вычисления. Автоматическая настройка компонентов и систем осуществляется согласно принципам высокоуровневой политики. Остальная часть системы регулируется автоматически и незаметно для пользователя.
2. Самооптимизация
Существующие вычисления. Системы включают сотни устанавливаемых вручную нелинейных параметров настройки, число которых увеличивается с каждым релизом.
Автономные вычисления. Компоненты и системы находятся в постоянном поиске возможностей с целью повышения своей производительности и эффективности.
3. Самовосстановление
Существующие вычисления. Решение проблем в крупных сложных системах требует длительных усилий команды разработчиков.
Автономные вычисления. Система автоматически обнаруживает, диагностирует и устраняет локализованные проблемы программного и аппаратного обеспечения.
4. Самозащита
Существующие вычисления. Обнаружение атак и каскадных сбоев с последующей ликвидацией их последствий происходит вручную.
Автономные вычисления. Система автоматически защищается от вредоносных атак или каскадных сбоев. Она использует средства предварительного предупреждения для предотвращения масштабных перебоев в работе.
Что такое Apache Brooklyn?
И вот тут как нельзя кстати появляется Apache Brooklyn. Это фреймворк с открытым исходным кодом, способный управлять процессами настройки и развёртывания приложений, контролировать их состояния и метрики, понимать взаимосвязи между компонентами (например, знать, что добавление нового веб-сервера потребует изменения конфигурации балансировщика нагрузки), а также применять сложные алгоритмы, регламентирующие работу приложения. Большое влияние на разработку концепции Brooklyn оказали идеи автономных вычислений и теория перспектив.
Важные элементы Brooklyn
Схемы. Для описания приложения и его компонентов Brooklyn использует YAML-схемы, как правило, содержащиеся в файле blueprint.yaml. Эти схемы, объединяющие алгоритмы управления приложением, можно рассматривать как модульные компоненты, допускающие совмещение и повторное использование разными способами.
Локации. Их можно определять для уточнения места выполнения процессов приложения. Brooklyn поддерживает различных облачных провайдеров и предварительно подготовленные машины, включая localhost.
Сущности. В Brooklyn сущности воплощают собой ключевую концепцию развёртывания. Они являются управляемым ресурсом (отдельные компьютеры или программные процессы) или их логическими коллекциями. С ними могут быть связаны события, операции и логика обработки, и именно через этот механизм осуществляется активное управление.
Приложения. Это высокоуровневые сущности, из которых происходят все остальные.
Сенсоры. Этот механизм помогает одним сущностям демонстрировать информацию другим. Сенсоры одной сущности могут отслеживать изменения активности, происходящие в другой. Их, как правило, довольно частое обновление осуществляется либо самой сущностью, либо сопутствующими задачами.
Эффекторы. Это средство управления сущностями в приложении. Обратите внимание, что 3 эффектора жизненного цикла, а именно запуск, остановка и возобновление работы, присущи всем приложениям и сущностям программного процесса в Brooklyn.
Политики. В Brooklyn политикам предоставляется право осуществлять активное управление. К сущностям могут крепиться экземпляры этих политик, способные подключаться к сенсорам других сущностей или при необходимости выполняться. В процессе выполнения они могут проводить вычисления, искать другие значения, вызывать эффекторы или отправлять значения сенсоров сущности, к которой они подключены. Политики координируют управление сущностями в среде выполнения, производя действия, инициированные специальными триггерами. Они часто используются для поддержания исправного состояния системы, например, для устранения сбоев и автоматического масштабирования.
Алгоритмы Brooklyn
- Автоматическое масштабирование (auto-scaler) динамически регулирует свой размер в ответ на запрос поддержания метрики в заданном диапазоне.
- Заменитель службы (service replacer) заменяет вышедший из строя компонент.
- Перезапуск службы (service restarter) перезапускает службу при сбое.
- Детектор сбоев подключения (connection-failure detector) отправляет событие при потере/восстановлении соединения в целях контроля порта хоста.
- Назначение основного (elect-primary policy) хранит одного из потомков/компонентов в качестве основного.
- Периодическое выполнение эффектора (periodic-effector execution) происходит через определённый интервал.
- Выполнение эффектора по графику (scheduled-effector execution) происходит в заданное время или с определённой задержкой.
- Детектор сбоев SSH-подключений (SSH-connectivity failure detector) отправляет событие при потере/восстановлении соединения в целях контроля виртуальной машины SSH.
Развертывание с помощью Apache Brooklyn
Apache Brooklyn использует Apache jclouds для поддержки ряда облачных локаций. Идентификаторами наиболее часто используемых локаций такого рода являются:
jclouds:aws-ec2:<region>: Amazon EC2, в котором:<region>может бытьus-east-1илиeu-west-1(или не указан).jclouds:softlayer:<region>: IBM Softlayer, в котором:<region>может бытьdal05илиams01(или не указан).jclouds:google-compute-engine: Google Compute Engine.jclouds:openstack-nova:<endpoint>: OpenStack, в котором:<endpoint>является URL-доступом (обязателен).jclouds:cloudstack:<endpoint>: Apache CloudStack, в котором:<endpoint>является URL-доступом (обязателен).
name: Tomcat Cluster
location:
'jclouds:aws-ec2':
identity: ******************
credential: *****************************
hardwareId: t2.micro
region: us-west-2
services:
- type: org.apache.brooklyn.entity.group.DynamicCluster
name: Cluster
id: cluster
brooklyn.config:
cluster.initial.size: 1
dynamiccluster.memberspec:
'$brooklyn:entitySpec':
type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
name: Tomcat Server
brooklyn.config:
wars.root: >-
https://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-webapp/0.12.0/brooklyn-example-hello-world-webapp-0.12.0.war
brooklyn.policies:
- type: org.apache.brooklyn.policy.ha.ServiceRestarter
brooklyn.config:
failOnRecurringFailuresInThisDuration: 5m
brooklyn.enrichers:
- type: org.apache.brooklyn.policy.ha.ServiceFailureDetector
brooklyn.config:
entityFailed.stabilizationDelay: 30s
brooklyn.policies:
- type: org.apache.brooklyn.policy.ha.ServiceReplacer
- type: org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
brooklyn.config:
metric: webapp.reqs.perSec.perNode
metricUpperBound: 3
metricLowerBound: 1
resizeUpStabilizationDelay: 2s
resizeDownStabilizationDelay: 1m
maxPoolSize: 3
brooklyn.enrichers:
- type: org.apache.brooklyn.enricher.stock.Aggregator
brooklyn.config:
enricher.sourceSensor: '$brooklyn:sensor("webapp.reqs.perSec.windowed")'
enricher.targetSensor: '$brooklyn:sensor("webapp.reqs.perSec.perNode")'
enricher.aggregating.fromMembers: true
transformation: average
- type: org.apache.brooklyn.entity.proxy.nginx.NginxController
name: Load Balancer (nginx)
brooklyn.config:
loadbalancer.serverpool: '$brooklyn:entity("cluster")'
nginx.sticky: falseВышеприведённый YAML предоставляет архитектуру приложения, состоящего из кластера серверов и балансировщика нагрузки nginx. К кластеру применяются 2 алгоритма: автоматическое масштабирование и заменитель службы.
Добавление этого кода в YAML-редактор позволяет получить графическое представление архитектуры, а Brooklyn с помощью UI обеспечивает гибкий подход к редактированию как архитектуры, так и алгоритмов для каждой сущности.
Brooklyn передаёт детали, касающиеся его событий и действий, для устранения аномалий, обнаруженных в поведении приложения. Графическая визуализация оставляет желать лучшего, поскольку для наглядного представления событий Brooklyn предлагает не самую удобную диаграмму.
Преимущества и недостатки
Преимущества
- Brooklyn — это инструмент с открытым исходным кодом, что является его особым преимуществом. Кроме того, установка фреймворка не представляет особых сложностей.
- Brooklyn использует Apache jclouds для поддержки ряда облачных платформ.
- События и действия отображаются на странице активности.
- Предоставляет информацию о том, какие сенсоры доступны в зависимости от сущности.
- Локацию развёртывания можно сохранить, чтобы использовать в дальнейшем при выгрузке других служб, избегая повторений.
- Политики и сущности могут быть тонко настроены под требования каждого пользователя.
- Пользовательские сенсоры можно создавать посредством обогатителей, объединяя датчики с помощью таких математических операторов, как агрегаторы, редукторы, объединители, дельты, среднее значение и др.
- Может развёртывать приложения, используя командную строку или UI-панель настроек (возможна развёртка через конфигурационный файл
blueprint.YAML).
Недостатки
- Развёртывание осуществляется непосредственно через сам Brooklyn, чтобы обеспечить ему контроль за приложениями, поскольку уже развёрнутые приложения он не отслеживает.
- Не предоставляет canary-развёртывание (развёртывание версий).
- Не предусматривает графическую визуализацию метрик приложения.
- Не контролирует внутренние события и исключения в приложении, но отслеживает состояние всей сущности.
- Не обеспечивает распределённую трассировку вызовов приложения.
- Brooklyn не совместим с Docker Swarm и кластером Kubernetes.
Несмотря на недостатки, Apache Brooklyn — превосходный инструмент. Проблему несовместимости с Docker и Kubernetes можно решить за счёт расширения для Brooklyn — плагина Clocker, разработанного Cloudsoft. Испытайте Brooklyn в деле в своих будущих проектах.
Читайте также:
- Нововведения в Apache Airflow 2.0: смогут ли они удовлетворить текущие потребности инженерии данных
- Непрерывная интеграция и развёртывание ПО: лучшие практики
- Среда разработки Entity Framework в Docker
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Vinesh: Apache Brooklyn- A Step Towards Autonomic Computing
