Масштабирование — это все восторженные.
Когда вы разговариваете об оркестровке облаков (все крутые ребята делают это в наши дни), вы просто не сможете пройти десять минут, если кто-то не будет на вечеринке и не будет ввязываться со старым голодом: «Да, но вы можете автоматически масштабировать мое заявление?.»
На самом деле, я один из тех, кто устраивает вечеринки. Вы не можете винить нас; с тех пор как появились облачные вычисления, масштабирование больших топологий приложений стало гораздо более осуществимым, потому что теперь вы можете предоставлять любые ресурсы через API за считанные минуты.
Тем не менее, горизонтальное масштабирование является и будет оставаться очень нетривиальной проблемой для решения. Прежде всего, приложение, которое вы пытаетесь масштабировать, должно знать, что оно может масштабироваться, и не полагаться на какое-либо состояние, которое может измениться в масштабе.
OpenStack Orchestration стало проще с Cloudify. Получи это сейчас. Идти
Возьмите, например, экземпляр веб-сервера, чтобы иметь возможность масштабирования, и он не может хранить сведения о сеансе, которые имеют отношение к последующим запросам, поскольку эти запросы могут обрабатываться другими экземплярами. Только когда это требование выполнено, мы можем начать говорить о других, более «общих» проблемах:
- Как и какие показатели измерять.
- Как запустить процесс масштабирования.
- Как построить сам процесс.
В этой статье я буду говорить об этих аспектах, и мы увидим, как можно подойти к этой проблеме в облачной среде OpenStack .
Масштабирование на OpenStack с помощью Heat
OpenStack Heat — это механизм оркестровки приложений, разработанный для OpenStack Cloud. Он интегрирован в дистрибутив OpenStack и может использоваться через CLI или через графический интерфейс Horizon. Для определения топологий приложений в Heat используется собственный шаблонный язык под названием HOT (шаблон оркестровки Heat).
Этот раздел предполагает базовые знания о жаре. Если вам не хватает этих знаний, вы можете взглянуть на следующие ссылки, чтобы помочь вам понять, что это такое:
- HOT Guide — Простое руководство по написанию шаблонов HOT
- ГОРЯЧАЯ Ссылка — Глоссарий
Автоматическое масштабирование в тепле осуществляется с помощью трех основных типов:
OS :: Heat :: AutoScalingGroup
AutoScalingGroup — это тип ресурса, который используется для инкапсуляции ресурса, который мы хотим масштабировать, и некоторых свойств, связанных с процессом масштабирования.
ScalingPolicy — это тип ресурса, который используется для определения влияния процесса масштабирования на масштабированный ресурс.
Тревога — это тип ресурса, который используется для определения условий запуска ScalingPolicy.
Все это станет намного понятнее, когда мы рассмотрим пример, поэтому давайте продолжим и сделаем это.
В нашем случае мы будем автоматически масштабировать сервер WordPress, который подключается к статическому и общему экземпляру MariaDB.
Ниже приведены выдержки из примера полного автоматического масштабирования .
Это определение сервера MariaDB:
db:
type: OS::Nova::Server
properties:
user_data:
str_replace:
template: |
#!/bin/bash -v
yum -y install mariadb mariadb-server
systemctl enable mariadb.service
systemctl start mariadb.service
…<more installation stuff…>
Мы видим, что это просто ресурс типа OS :: Nova :: Server со свойством user_data для установки MariaDB через yum.
Теперь давайте посмотрим, как часть автомасштабирования вступает в игру.
Любая реализация процесса автоматического масштабирования всегда должна отвечать на три основных вопроса:
- Какой ресурс масштабировать?
- Что делает процесс масштабирования?
- Когда должен быть запущен процесс масштабирования?
Q1: который
asg:
type: OS::Heat::AutoScalingGroup
properties:
min_size: 1
max_size: 3
resource:
type: OS::Nova::Server
properties:
user_data:
str_replace:
template: |
#!/bin/bash -v
yum -y install httpd wordpress
systemctl enable httpd.service
systemctl start httpd.service
setsebool -P httpd_can_network_connect_db=1
…<more installation stuff…>
Это ресурс типа OS :: Heat :: AutoScalingGroup, и он определяет, что мы хотим масштабировать ресурс типа OS :: Nova :: Server, который устанавливает httpd и развертывает на нем приложение WordPress . Обратите внимание, что масштабированный ресурс может быть определен вне масштабирующей группы, а затем на него можно ссылаться с помощью встроенной функции get_resource.
Q2: что
web_server_scaleup_policy:
type: OS::Heat::ScalingPolicy
properties:
auto_scaling_group_id: {get_resource: asg}
adjustment_type: change_in_capacity
scaling_adjustment: 1
Это ресурс типа OS :: Heat :: ScalingPolicy. Давайте ближе посмотрим на его свойства
- auto_scaling_group_id:
- Вот как мы связываем эту политику с определенной группой масштабирования, которая, в свою очередь, определяет ресурс для масштабирования.
- adjustment_type:
- Это указывает, что мы собираемся создать изменение относительно текущей емкости. Другими параметрами здесь могут быть «точная_капитализация» или «процент_обмен_ин_капитальность».
- scaling_adjustment:
- В этом все дело, каждый раз, когда эта политика срабатывает, мы хотим добавить еще один экземпляр WordPress.
Q3: Когда
cpu_alarm_high:
type: OS::Ceilometer::Alarm
properties:
description: Scale-up if the average CPU > 50% for 1 minute
meter_name: cpu_util
statistic: avg
period: 60
threshold: 50
alarm_actions:
- {get_attr: [web_server_scaleup_policy, alarm_url]}
matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}}
Мы видим, что этот сигнал тревоги является ресурсом типа OS :: Ceilometer :: Alarm, который определяет свойства, которые в основном сообщают тепловому двигателю:
вызвать web_server_scaleup_policy, если средний процессор на сервере WordPress превышает 50% в течение как минимум 1 минуты
Хорошо, это заняло у нас некоторое время, но мы сделали это путем определения шаблона HOT с возможностью автоматического масштабирования. Теперь давайте рассмотрим аспекты масштабирования, которые мы упоминали в начале поста, в отношении примера, который мы только что видели:
метрика
Мы видим, что метрические измерения выполняются с помощью Ceilometer , который является встроенной системой мониторинга и измерения, интегрированной в OpenStack. Он предоставляет различные метрики для всех видов ресурсов OpenStack. В текущем примере мы использовали метрику cpu_util для проверки загрузки ЦП сервера WordPress. Существует множество различных метрик на выбор, от экземпляров Compute до LBaaS .
Однако чего-то не хватает. Во многих случаях нас действительно интересуют метрики, специфичные для приложений / промежуточного программного обеспечения. То есть я хочу, чтобы мой сервер WordPress масштабировался, когда слишком много запросов попадают в текущую конечную точку. Этот тип информации никоим образом не раскрывается через Ceilometer, что, конечно, имеет смысл, поскольку он не имеет никаких сведений о том, что именно размещается на серверах, которые он отслеживает. Хорошая новость заключается в том, что, технически говоря, вы можете отправлять пользовательские метрики в Ceilometer через API пользовательских данных, На практике это нетривиальные инженерные усилия, которые должны быть выполнены пользователем. В идеале было бы неплохо, если бы вы могли настраивать, какие пользовательские метрики будут передаваться в Ceilometer через шаблон, и иметь встроенный компонент на сервере, который фактически выполняет эту работу.
Инициирование
Процесс масштабирования запускается автоматически, как только порог тревоги будет превышен. Heat также предоставляет веб-крючок для явного запуска политик масштабирования с помощью атрибута alarm_url, прикрепленного к самой политике.
Процесс
До сих пор мы на самом деле не обсуждали, что на самом деле делает процесс масштабирования, т. Е. Просто создает новый экземпляр ресурса и все? На что это похоже? Где это определено?
Это не случайно, просто потому, что вся эта информация скрыта от пользователей, и, следовательно, по определению, тот же процесс будет применяться к любому виду ресурсов. Например, если бы я вместо этого хотел масштабировать экземпляр MariaDB, я бы просто ссылался на этот ресурс внутри AutoScalingGroup, а не на встроенный ресурс.
Однако что, если масштабирование экземпляра БД имеет другие административные последствия для моей системы, чем масштабирование экземпляра веб-сервера? Иногда вам может потребоваться возможность выполнения определенных операций перед запуском нового экземпляра. Возможно, существуют некоторые проблемы SLA, которые необходимо выполнить, используя сторонние конечные точки. На самом деле, этот аспект специально не связан с автоматическим масштабированием; те же аргументы могут быть применены к созданию стека, удалению, обновлению … и, ну, вы понимаете, моя точка зрения.
Ладно, я думаю, что это было довольно громко и давало много работы для автоматического масштабирования в среде OpenStack, но это только половина. В моем следующем посте я хотел бы сравнить этот процесс с процессом на основе TOSCA, который имеет отношение к любой другой облачной или даже гибридной облачной среде с OpenStack. Еще не все.