ГЛАВА 3

Масштабирование

Пользуйтесь переводом существенно переработанной и дополенной 2й редакции (12-дек-2014),
находящейся теперь и в режиме постоянно обновляемой документации
(последняя пока доступна только на англ.яз.).

Если ваше облако является успешным, в конце концов, вы будете должны добавить ресурсы для удовлетворения растущего спроса. OpenStack разработан для горизонтального масштабирования. Вместо перехода на более крупные серверы, вы закупаете больше серверов. В идеале вы масштабируете и баланс нагрузки между функционально- идентичными службами.

Отправной пункт

Определение масштабируемости вашего облака и того, как ее улучшать является упражнением для балансировки со многими переменными. Ни одно из решений не отвечает всем целям масштабирования. Тем не менее, было бы полезным отслеживать ряд метрик.

Обычно отправной точкой является количество ядер вашего облака. Путем применения некоторых соотношений вы можете получить информацию о количестве виртуальных машин (VM), которые вы ожидаете выполнять ((доля перерасхода × ядра) / виртуальных ядер в экземпляре), сколько требуется дискового пространства (предпочитаемый размер диска × число экземпляров). Вы можете использовать эти соотношения для определения того, какой объем дополнительной инфраструктуры требуется вам для поддержания вашего облака.

Предпочтения по умолчанию OpenStack:

Название	Виртуальные ядра	ОЗУ	Диски	Непродолжительно
m1.tiny	1	512 MB	1 GB	0 GB
m1.small	1	2 GB	10 GB	20 GB
m1.medium	2	4 GB	10 GB	40 GB
m1.large	4	8 GB	10 GB	80 GB
m1.xlarge	8	16 GB	10 GB	160 GB

Предположим, что следующие установки поддерживают (200 / 2) × 16 = 1600 экземпляров VM и требуют 80 TB хранилища для /var/lib/nova/instances:

200 физических ядер
Большинство экземпляров имеют размер m1.medium (2 виртуальных ядра, 50 GB хранилища)
Соотношение перегруженного выделения (overcommit) CPU по умолчанию (cpu_allocation_ratio в nova.conf ) в 16:1

Тем не менее, вам потребуется не только оценка числа ядер для оценки загрузки, с которой, вероятно, столкнутся службы API, серверы баз данных и серверы очередей. Также вы должны рассмотреть модели использования вашего облака.

В качестве конкретного примера сравните облако, поддерживающее платформу управляемого веб- хостинга с облаком, выполняющим тест интеграции для проекта развития, который создает одну виртуальную машину на каждый код транзакции. В первом случае тяжелая работа создания ВМ происходит только каждые несколько месяцев, в то время, как второй размещает постоянную тяжелую нагрузку на контроллере облака. Вы должны учитывать среднее время жизни ваших ВМ, поскольку большие значения означают меньшую нагрузку на контроллер облака.

Помимо создания и останова виртуальных машин вы должны учитывать влияние пользователей, подключающихся к услуге — в частности, к nova-api и связанной с ним базой данных. Просмотр списка экземпляров накапливает большое количество информации и, принимая во внимание частоту, с которой пользователи выполняют эту операцию, облако с большим количеством пользователей может значительно увеличить нагрузку. Это может произойти даже без их ведома — оставленная открытой в браузере закладка экземпляра инструментальной панели (Dashboard) OpenStack обновляет список виртуальных машин каждые 30 секунд.

После того, как вы учтете эти факторы, вы можете определить то, как много ядер потребуется контроллеру облака. Учитывая вышеперечисленные рассуждения, для стойки вычислительных узлов достаточно обычного сервера с 8ю ядрами и 8 ГБ ОЗУ.

Также вы должны проанализировать ключевые характеристики производительности для пользовательских виртуальных машин. Вы должны принимать во внимание как бюджет, так и ограничения бюджета. Примеры параметров включают в себя: производительность систем хранения (шпиндели/ядра), доступность памяти (ОЗУ/ядра), пропускная способность сети (Гбит в секунду/ядра) и общая производительность процессора (CPU/ядра).

Для знакомства с метриками, определяющими масштабирование вашего облака, отсылаем вас к Главе 13.

Добавление узлов контроллера

Вы можете облегчить горизонтальное расширение вашего облака добавляя узлы. Добавление вычислительных узлов выполняется легко — они легко подхватывают существующие установки. Однако, при создании кластера высокой доступности необходимо учитывать некоторые важные моменты.

Напомним, что узел контроллера облака выполняет несколько различных служб. Для целей расширения на новом сервере вы можете установить службы, которые будут взаимодействовать внутри исключительно с использованием очередей сообщений — nova-scheduler и nova-console. Тем не менее, другие составные части требуют большего внимания.

Вы должны осуществлять баланс нагрузки служб пользователя, таких как инструментальная панель (Dashboard), nova-api или прокси хранения объектов. Используйте любой стандартный метод балансировки нагрузки HTTP (круговой [round robin] DNS, аппаратная балансировка нагрузки, программное обеспечение, подобное Pound или HAProxy). Одно предостережение в отношении инструментально панели (Dashboard) касается прокси VNC, который использует протокол WebSocket — нечто, с чем может бороться балансировщик нагрузки L7. Ознакомьтесь также с Horizon session storage ( http://docs.openstack.org/developer/horizon/topics/deployment.html#session-storage).

Вы можете настроить некоторые службы, такие как nova-api и glance-api для использования нескольких процессов, изменив флаг в их конфигурационном файле — позволив тем самым им совместно работать с несколькими ядрами на одном компьютере.

Существует множество вариантов балансировки нагрузки для MySQL и RabbitMQ имеет встроенную поддержку кластеризации. Информацию о том, как настроить эту и многие другие службы можно найти в разделе эксплуатации (Operations Section).

Разделение ваших облаков

Используйте один из следующих методов OpenStack для разделения ваших облаков: ячейки (cell), области (region), зоны (zone) и объединения хостов (host aggregate). Каждый метод обеспечивает свою функциональность, описанную в приводимой ниже таблице:

	Ячейки (Cells)	Области (Regions)	Зоны доступности (Availability Zones)	Объединения хостов (Host Aggregates)
Используйте, когда вам нужно	Единый API конечной точки для вычислений или вам потребуется второй уровень планирования.	Дискретные области с отдельными конечными точками API и отсутствием согласования меду областями.	Логическое разделение в пределах вашего развертывания nova для физической изоляции или отказоустойчивости.	Для управления группой хостов с общими характеристиками.
Пример	Облако с множеством сайтов, в котором вы можете планировать ВМ "где угодно" или на определенном сайте.	Облако с множеством сайтов, в котором вы управляете ВМ определенного сайта и вам требуется общая инфраструктура.	Отдельное облако сайта с оборудованием, запитываемым от отдельных источников.	Планирование для хостов с высоконадежной поддержкой аппаратных средств.
Накладные расходы	• Новая служба, `nova-cells` • Каждая ячейка имеет полную установку nova, за исключением `nova-api`	• Различные конечные точки API для каждой области. • Каждая область имеет полную установку nova.	• Изменения настроек для nova.conf	• Изменения настроек для nova.conf
Совместно используемые службы	Keystone `nova-api`	Keystone	Keystone Все службы nova	Keystone Все службы nova

Этот массив вариантов может быть разделен на два — те, кто приводят к выполнению раздельных реализаций nova (ячейки и области) и те, которые совместно используют (зоны доступности и объединения хостов).

Ячейки и области

Ячейки OpenStack Compute разработаны для возможности работы облака в распределенном режиме без необходимости использования более сложных технологий, или для принуждения использования существующих установок nova. Хосты в облаке разбиваются на группы, называемые клетками (cells). Клетки настраиваются в дерево. Клетки верхнего уровня ("API cell") имеют хост, на котором выполняется служба nova-api, однако отсутствуют службы nova-compute. Каждая клетка потомка выполняет все другие типичные службы nova-*, найденные в обычной установке, за исключением службы nova-api. Каждая клетка имеет свою очередь сообщений и службу базы данных, а также выполняет nova-cells — который управляет взаимодействием между API клетки и клетками- потомками.

Это позволяет использовать один сервер API для управления множеством установок облаков. Предоставление второго уровня управления (в выборе клеток), в дополнение к обычному nova-scheduler выбору хостов обеспечивает большую гибкость управлению выбора места запуска виртуальной машины.

Сравните это с областями. Области имеют отдельную конечную точку API на одну установку, что допускает более дискретное разделение. Пользователи, желающие выполнять экземпляры на сайтах, должны выбирать область в явном виде. Однако при этом не требуется дополнительное усложнение запуска новой службы.

Инструментальная панель OpenStack (Horizon) в настоящее время использует только одну область, так что в каждой области должна работать одна служба инструментальной панели. Области являются надежным способом разделения определенной инфраструктуры между установками OpenStack Compute, гарантируя при этом высокую степень отказоустойчивости.

Зоны доступности и объединения хостов

Вы можете использовать зоны доступности, объединения хостов или и то, и другое одновременно для разделения установки nova.

Зоны доступности реализуются и настраиваются аналогично объединениям хостов.

Однако, вы используете зону доступности и объединение хостов по разным причинам:

Зона доступности. Позволяет вам организовывать хосты OpenStack Compute в логические группы и представляет собой форму физической изоляции и избыточности по отношению к другим зонам доступности, которые используют другой источник питания или другое сетевое оборудование.
Вы определяете зону доступности, в которой расположен локально на каждом сервере указанный хост вычислений. Зона доступности обычно используется для определения набора серверов, имеющих общее свойство. Например, если некоторые стойки в вашем центре данных имеют отдельный источник питания, вы можете поместить сервера этих стоек в их собственную зону доступности. Зона доступности могут также помочь отделять различные классы оборудования.
Когда пользователи запрашивают оборудование, они могут указать из каких зон они хотят строить свой экземпляр. Это позволяет снабдить пользователей облака возможностью распределения их ресурсов приложений по разным компьютерам для достижения высокой доступности при сбоях оборудования.
Объединение хостов. Делает возможным для вас разделять развертывание OpenStack Compute в логические группы для балансировки нагрузки и распределения экземпляра. Вы можете использовать объединение хостов для дальнейшего разделения на зоны доступности. Например, вы можете использовать объединение хостов для разделения зон доступности на группы хостов, которые либо имеют общие ресурсы, такие как СХД и сетевое оборудование, или имеют особую функциональность, например, высоконадежное компьютерное оборудование.

Широко применяемым использованием объединений хостов является предоставление информации для планировщика nova. Например, вы можете использовать объединение хостов для объединения нескольких в группу, которая совместно использует определенные особенности (flavors) или образы.

Tip Ранее все службы имели зону доступности. В настоящее время свою собственную зону доступности имеют только службы nova-compute. Службы, подобные nova-scheduler, nova-network, nova-conductor всегда распространяются на все зоны доступности.
Когда вы выполняете любую из следующих операций, соответствующие службы появляются в их собственных внутренних зонах доступности (CONF.internal_service_availability_zone):

список хостов nova (os-hosts)
детали euca-describe-availability-zones
список служб nova-manage

Внутренняя зона доступности скрыта в euca-describe-availability_zones (non-verbose).
CONF.node_availability_zone была переименована в CONF.default_availability_zone и используется только в службах nova-api и nova-scheduler.
CONF.node_availability_zone все еще работает, но признана устаревшей.

Масштабируемое оборудование

Закупка оборудования

"Облако" было описано как неустойчивая среда, в которой серверы могут создаваться и удаляться по желанию. Хотя это может быть правдой, это совсем не означает, что ваши серверы должны быть нестабильными. Обеспечение вашего облака надежным и правильно настроенным оборудованием означает, что ваше облако остается запущенным и работающим. Обычно усилия направлены на создание надежной среды аппаратных средств, следовательно вы можете предоставлять облако, которое пользователи могут рассматривать как нестабильное или изменчивое.

OpenStack может быть развернут на любом оборудовании, поддерживаемом OpenStack-совместимым дистрибутивом Linux, например, используемым в эталонной архитектуре данной книги Ubuntu 12.04.

Оборудование не обязано быть неизменным, однако, по крайней мере, должно иметь один и тот же тип процессора для поддержки миграции экземпляра.

Рекомендуемым обычно оборудованием для использования в OpenStack является стандартное предложение, стоящее уплаченных за него денег, которое предлагает большинство производителей аппаратных средств. Необходимо просто разделить ваши закупки на строительные блоки, такие как "вычислители", "хранилища объектов" и "контроллеры облака" и закупать их столько, сколько необходимо. Возможно вам не потребуется тратить дополнительные средства, если вы уже имеете серверы, если они отвечают вашим требованиям производительности и технологии виртуализации, что весьма вероятно, для поддержки OpenStack.

Планирование емкости

OpenStack разработан для увеличения в размерах прямым образом. Принимая во внимание соображения главы Масштабируемость — в особенности в отношении размеров контроллера облака — по мере необходимости, возможно, потребуется приобретение дополнительных узлов для вычислений или хранения объектов. Новые узлы не обязаны иметь ту же спецификацию, или даже того же производителя, что и существующие узлы.

Для вычислительных узлов, планировщик nova будет заботиться о различиях в размерах для соблюдения требований к числу ядер и объему памяти, однако вы должны проанализировать изменения квалификации пользователей при различных скоростях процессоров. При добавлении узлов хранения объектов, должен быть указан вес, который отражает емкость узла.

Мониторинг использования ресурса и роста числа пользователей позволит вам определить время новой закупки. Глава Мониторинг описывает некоторые полезные метрики.

Нагрузочные испытания

Вероятность отказа сервера велика в начале и конце его жизни. Как результат, можно избежать больших затрат в работе с оборудованием при его эксплуатации путем проведения надлежащих отбраковочных испытаний на ранней стадии, чтобы попытаться вызвать отказы. Общий принцип заключается в нагрузке оборудования до его пределов. Примеры нагрузочных испытаний включают в себя работу тестов процессоров и дисков на протяжении нескольких дней.

Глава 2	Оглавление	Глава 4

Перевод: Copyright © 2014 . All rights reserved. Ссылки обязательны (Refs and links obligatory).		http://www.mdl.ru