[Эта статья была написана Эли Полонским]
Это вторая часть нашего сравнения инструментов оркестровки. Вы можете найти часть I здесь .
Этот раздел предполагает базовые знания Cloudify и TOSCA . Если у вас нет этих знаний, вы можете взглянуть на следующие ссылки, чтобы помочь вам понять, о чем они:
TOSCA — это развивающийся открытый стандарт для языка шаблонов для организации приложений в облаке. Он не привязан к какому-либо конкретному облачному провайдеру и сам по себе является не чем иным, как языком шаблонов, у которого нет механизма для его поддержки. Это по своей сути отличается от Heat , который обеспечивает как язык шаблонов, так и движок оркестровки.
OpenStack Orchestration стало проще с Cloudify. Получи это сейчас. ИДТИ
Так что для контекста и для тех, кто мало знает о Cloudify, это движок оркестровки, который понимает шаблоны TOSCA и может взаимодействовать с несколькими поставщиками облачных услуг, и это мы продемонстрируем в этом разделе.
Самая важная концепция для понимания шаблонов TOSCA состоит в том, что каждая отдельная сущность в топологии вашего приложения является anode_template, которая имеет определенный тип_узла и имеет интерфейс жизненного цикла, который точно отображает, как манипулировать, создавать и удалять сущность.
Узел_узла можно рассматривать как эквивалент ресурса, а тип_узла эквивалентен различным типам ресурсов тепла . Интерфейс жизненного цикла, однако, не имеет соответствующей концепции. Этот факт окажется очень важным для нас позже.
Итак, еще раз, давайте углубимся в пример. Мы попытаемся адаптировать тот же вариант использования, что и раньше, автоматически масштабируя сервер WordPress, который подключается к статическому и общему экземпляру MariaDB, для записи в TOSCA и использования Cloudify.
db_host:
type: cloudify.nodes.openstack.Server
properties:
image: <ubuntu-image-id>
flavor: <medium-flavor-id>Это определение node_template хоста, на который мы хотим установить экземпляр MariaDB. В TOSCA каждый логический объект в приложении должен моделироваться отдельно, причем отношения связывают эти объекты друг с другом. Чтобы установить экземпляр MariaDB на этом хосте, мы определяем новый node_template:
db:
type: cloudify.nodes.Database
properties:
db_rootpassword: <db-pass>
db_user: <db-user>
db_name: <db-name>
interfaces:
cloudify.interfaces.lifecycle:
create: scripts/download-maria.sh
configure: scripts/enable-maria.sh
start: scripts/start-maria.sh
relationships:
- type: cloudify.relationships.contained_in
target: db_hostС Cloudify вам не нужно использовать user_data для установки программного обеспечения; вместо этого вы разбиваете процесс установки и хуки интерфейса жизненного цикла на разные части установки, а вся логика находится внутри сценариев. Обратите внимание на раздел отношений, в котором говорится, что db должен быть установлен именно на db_host. Давайте перейдем к части, связанной с масштабированием.
Поэтому, как и в предыдущем посте, напомню, любая реализация процесса автоматического масштабирования всегда должна отвечать на три основных вопроса:
- Какой ресурс масштабировать?
- Что делает процесс масштабирования?
- Когда должен быть запущен процесс масштабирования?
Q1: который
wordpress_host:
type: cloudify.nodes.openstack.Server
properties:
image: <ubuntu-image-id>
flavor: <medium-flavor-id>
interfaces:
cloudify.interfaces.monitoring_agent:
install: diamond.diamond_agent.tasks.install
start: diamond.diamond_agent.tasks.start
cloudify.interfaces.monitoring:
start:
implementation: diamond.diamond_agent.tasks.install
inputs:
collectors_config:
CPUCollector: {}
MemoryCollector: {}
LoadAverageCollector: {}
NetworkCollector: {} Здесь мы определили довольно крутой node_template. Он имеет тип cloudify.nodes.openstack.Server и имеет несколько дополнительных интерфейсов для предоставления ему возможностей мониторинга. Мы видим, что cloudify.interfaces.monitoring_agent заботится об установке агента мониторинга под названием Diamond , а cloudify.interfaces.monitoring настраивает агент с различными сборщиками, которые собирают данные с хоста. Помните, что с OpenStack Heat вся эта конфигурация скрыта от пользователя, но она также существует. Теперь давайте определим реальное приложение WordPress.
wordpress:
type: cloudify.nodes.WebServer
properties:
db_password: <db-pass>
db_user: <db-user>
db_name: <db-name>
db_host: <db-name>
interfaces:
cloudify.interfaces.lifecycle:
create: scripts/download-httpd.sh
configure: scripts/configure-wordpress.sh
start: scripts/start-httpd.sh
cloudify.interfaces.monitoring:
start:
implementation: diamond.diamond_agent.tasks.install
inputs:
collectors_config:
MongoDBCollector: {}
relationships:
- type: cloudify.relationships.contained_in
target: wordpress_hostОбратите внимание, что мы также определяем cloudify.interfaces.monitoring для этого node_template, который указывает агенту мониторинга на хосте добавить HttpdCollector , который является частью многих встроенных сборщиков в Diamond . Это потрясающе, потому что позже мы можем использовать эти метрики для некоторого интеллектуального масштабирования приложения.
Q2: что
Теперь мы хотим точно понять, что будет делать процесс масштабирования. В Cloudify каждый процесс рассматривается как рабочий процесс (чтобы узнать больше об этом, вы можете прочитать этот пост « Что такое рабочий процесс? »), Который по сути является алгоритмом процесса автоматизации. Каждый рабочий процесс состоит из вызовов для операций интерфейса, связанных с определенным типом узла.
Само определение рабочего процесса является частью шаблона:
workflows:
scale:
mapping: default_workflows.cloudify.plugins.scale
parameters:
node_id:
description: Which node_template to scale
delta:
description: delta in number of instance of (negative or positive values)А код рабочего процесса — это метод python, написанный с помощью Cloudify Workflow API .
Давайте посмотрим небольшой фрагмент:
instance.execute_operation('cloudify.interfaces.lifecycle.create'),
instance.set_state('created'),
forkjoin(*_relationship_operations(instance,
'cloudify.interfaces.relationship_lifecycle.preconfigure'
)),
forkjoin(
instance.set_state('configuring'),
instance.send_event('Configuring node')
),
instance.execute_operation('cloudify.interfaces.lifecycle.configure')Помните, что каждый node_template реализует операции жизненного цикла по-разному, и именно в этом заключается разница между масштабированием экземпляра MariaDB или экземпляра WordPress. Но процесс остается прежним. Кроме того, поскольку все это является частью самого шаблона, а не частью механизма рабочего процесса , пользователь может настроить этот процесс так, как считает нужным.
Q3: Когда
Эта часть — то, что TOSCA определяет как Группы и Политики. Однако, на момент написания этого поста, политики еще не были полностью разработаны. Cloudify имеет свою собственную версию этого, которая может в конечном итоге найти свою официальную спецификацию, но сейчас это выглядит так:
groups:
autoscaling_group:
members: [‘wordpress’]
policies:
scaleup_one_instance:
type: cloudify.policies.types.threshold
properties:
service: ReqPerSec
threshold: 1000
upper_bound: true
stability_time: 60
triggers:
autoscale_trigger:
type: cloudify.policies.triggers.execute_workflow
parameters:
workflow: scale
workflow_parameters:
node_id: wordpress_host
delta: 1Давайте разберемся с элементами, чтобы понять, что происходит.
По большей части мы видим, что используемые здесь термины относительно нам знакомы. У нас есть группа с именем autoscaling_group, которая определяет в своих членах, какие узлы будут рассматриваться для проверки. Обратите внимание, что мы указываем wordpressnode_type, а не wordpress_host, поскольку нас интересуют показатели, специфичные для приложения, а не для хоста.
Мы также определяем политику scaleup_one_instance, которая инструктирует движку Cloudify запускать некоторые действия, когда значение ReqPerSecmetric превышает пороговое значение 1000 для периода измерения не менее 60 секунд. Наглядно показано, какие действия предпримет двигатель. Это инкапсулировано в разделе триггеров политики scaleup_one_instance, который объявляет, что рабочий процесс масштаба должен выполняться с заданными параметрами, и в нашем случае эти параметры говорят движку добавить дополнительный wordpress_hostinstance.
На внутренней стороне Cloudify все метрики хранятся в базе данных метрик временных рядов, называемой InfluxDB , к которой можно легко обращаться. Cloudify также предоставляет очень элегантный клиент Python для отдыха . С этим клиентом вы можете легко запустить любой рабочий процесс, который вам нравится
execution = cloudify.executions.start(
deployment_id=’wordpress_deployment’, workflow_id=’scale’,
workflow_paramters={‘node_id’:’wordpress_host’, ‘delta’: 1})
execution_status = cloudify.executions.get(deployment_id=’wordpress_deployment’,
execution_id=execution.id).statusЭто, конечно, также доступно через REST API . Это означает, что если требуется вычисление завесы, для которого необходимо выполнить масштабирование, и они не отражены в политиках, то это будет довольно легко реализовать отдельно.
Резюме
Итак, что мы узнали из всего этого? Целью данной серии статей было понять, как можно выполнить автоматическое масштабирование в OpenStack, а также понять текущие пробелы в реализациях и посмотреть, что можно улучшить.
Мы видели два разных метода, и я думаю, что было бы справедливо сказать, что вы не найдете там хороших инструментов, которые бы делали это совершенно по-другому. Так что можно с уверенностью сказать, что то, что мы только что увидели, охватывает почти все, что есть в настоящее время.
Первый метод был реализован с использованием встроенного инструмента оркестрации OpenStack , также известного как Heat. Я думаю, что Heat очень хорошо справляется с тем, для чего изначально был построен Heat, который координирует ресурсы инфраструктуры OpenStack. Такое ощущение, что они на самом деле не живут и не дышат оркестровкой приложений, что затрудняет управление и масштабирование приложений, а не только инфраструктуры. Тот факт, что процесс масштабирования жестко запрограммирован в двигателе, может оказаться серьезным ограничением для сложных случаев использования, но на самом деле является преимуществом для наиболее распространенных.
Второй путь заключался в использовании движка с открытым исходным кодом под названием Cloudify, который придерживается открытого стандарта TOSCA. Использование этого инструмента дает вам более естественную интеграцию с приложениями различного рода, но меньше интеграции с ресурсами OpenStack. Вы можете обнаружить, что некоторые типы ресурсов еще не поддерживаются, но в целом он имеет очень хороший охват API OpenStack . Используя Cloudify, вы получаете полный контроль над процессом масштабирования. Вы можете расширить и изменить встроенный рабочий процесс в соответствии с вашими конкретными потребностями, что является отличной возможностью.
Конечно, на данный момент это потребует некоторого кодирования на python, но планируются сделать эту композицию рабочего процесса полностью декларативной. Еще одна вещь, о которой стоит упомянуть, это тот факт, что Cloudify полностью независима от облаков, она не зависит от встроенного определения типа или возможностей мониторинга конкретного облачного провайдера. Это является прямым результатом использования такого стандарта, как TOSCA, который делает все это возможным благодаря концепции интерфейса жизненного цикла. Это означает, что вы можете взять облачную установку и шаблоны, а также перенести или расширить свою рабочую нагрузку на другого облачного провайдера без изменений в аспектах шаблона, связанных с масштабированием.
Я надеюсь, что это дает вам достаточно широкий охват вариантов там. В конце концов, вам придется тщательно продумать свой вариант использования и выбрать подход, который наилучшим образом соответствует тому, чего вы хотите достичь. Тем не менее, независимо от того, что это такое, вы, скорее всего, найдете решение, и это очень хорошая новость.