OpenStack предназначен для успешной работы в различных вариантахмонтажных установок, начиная с очень маленьких частных облаков до огромных общедоступных облаков. Чтобы добиться этого, разработчики добавили параметры настройки в свой код, что позволяет изменять поведение различных компонентов в зависимости от ваших потребностей. К сожалению, не возможно охватить все вероятные установки с помощью параметров конфигурации по умолчанию.
К моменту написания данной книги, OpenStack имеет более чем 1500 вариантов настроек. Вы можете увидеть их задокументированными в справочном руководстве по настройке OpenStack. Данная глава не может надеяться на документирование всех вариантов. Однако мы постараемся описать важные понятия, чтобы вы знали, куда идти копать для получения дополнительной информации.
Многие проекты OpenStack реализованы уровне драйвера, и каждый из этих драйверов будет применять свои собственные параметры конфигурации. Например, в вычислительной среде OpenStack (nova), существуют различные реализации драйвера гипервизора- libvirt, хenserver, hyper-V и vmware. Не все из этих драйверов гипервизора имеют схожие свойства, причем каждый из них имеет различные требования по настройке.
![[Замечание]](../common/images/admon/note.png) | Замечание |
|---|---|
|
Реализованые к настоящему времени гипервизоры приведены на веб-сайте документации OpenStack. Вы можете увидеть матрицу различных свойств в драйверах гипервизора вычислительной среды OpenStack (nova) на вики OpenStack, на странице матрицы поддерживаемых гипервизоров. |
Смысл, который мы пытаемся получить здесь заключается в том, что данный вариант соответствует вашему выбору драйвера не только потому что он существует. Обычно документация отмечает, какие драйверы применяется для настройки.
Еще одной распространенной концепцией в различных проектах OpenStack заключается в периодических задачах. Периодические задачи очень похожи на задания cron в обычных Unix системах, однако они выполняются внутри процесса OpenStack. Например, когда вычислительной среде OpenStack (nova) требуется определить какие образы она может удалить из своего локального кэша, она выполняет периодическую задачу.
Периодические задачи важны для осмысления из-за ограничений в модели потоков, которую использует OpenStack. OpenStack использует совместные потоки в Python, что означает, что если что-то долго и сложно работает, то оно будет блокировать другие задачи внутри этого процесса на выполнение, пока это что-то добровольно не отдаст выполнение другому совместному потоку.
Наглядным примером этого является процесс nova-compute.
Для того, чтобы управлять кэшем образов при помощи libvirt,
nova-compute имеет периодический процесс, который сканирует
содержимое кэша образа. Частью этой проверки является вычисление контрольной суммы
для каждого из образов и получение подтверждения, что контрольная сумма соответствует тому, что ожидает
nova-compute. Однако, образы могут быть очень
большими, и вычисление таких контрольных сумм может занять много времени.
В одном из обращений, прежде чем о нем было сообщено как об ошибке и ее исправлении,
nova-compute блокировал эту задачу и переставал
отвечать на запросы RPC. Это было видно для пользователей в виде отказов таких операций, как
порождение или удаление экземпляров.
Выход из этой ситуации заключается в том, что если вы видите процесс OpenStack, который, как представляется, "остановился" на некоторое время, а затем продолжает процесс нормально, вы должны проверить, что периодические задачи не испытывают проблем. Один из способов сделать это- отключить периодические задачи, установив интервал их в ноль. Кроме того, вы можете настроить как часто эти периодические задачи выполняются в некоторых случаях. Возможно, имеет смысл запускать их с другой частотой со значения по умолчанию.
Частота определяется отдельно для каждой периодической задачи. Поэтому, чтобы отключить каждую периодическую задачу в вычислительной среде OpenStack (Nova), вам нужно будет установить ряд опций конфигурации в ноль. Текущий список опций настройки, которые вы должны установить в ноль это:
-
bandwidth_poll_interval -
sync_power_state_interval -
heal_instance_info_cache_interval -
host_state_interval -
image_cache_manager_interval -
reclaim_instance_interval -
volume_usage_poll_interval -
shelved_poll_interval -
shelved_offload_time -
instance_delete_interval
Для установки параметров конфигурации в ноль, включите строку, подобную
To set a configuration option to zero, include a line such as
image_cache_manager_interval=0 в вашем файле
nova.conf.
Этот список будет меняться между редакциями, поэтому, пожалуйста, обратитесь к вашему руководству по настройке для текущих данных.
В этом разделе рассматриваются конкретные примеры вариантов настройки, которые вы могли бы рассмотреть для тюнинга. Это ни в коем случае не исчерпывающий список.
Руководство OpenStack по безопасности предоставляет глубокое погружение в вопросы безопасности облака OpenStack, в том числе SSL/TLS, управление ключами, PKI и управления сертификатами, обмена данными и неприкосновенности частной жизни, а также согласованности
Руководство по высокой доступности OpenStack предлагает советы для устранения единой точки отказа, которая может привести к простоям системы. Хотя этот документ не предоставляет исчерпывающих инструкций, он предлагает методы и техники, позволяющие избежать простоев и потери данных.
Редакция Havana с сетевой средой OpenStack (neutron) не обеспечивают полную поддержку IPv6. Улучшенная поддержка планируется в редакции Icehouse. Вы можете следовать развитию, наблюдая за neutron IPv6 Subteam at work.
Изменяя настройку конфигурации, вы можете настроить IPv6 при
использовании nova-network для сетевой среды, и проверить
установки, описанные для FlatDHCP и конфигурации с многими хостами.
Основой является побудить nova-network
полагать, что команда radvd
выполнилась успешно. Полная настройка детально обсуждается в
блог- посте Cybera,
“Установка IPv6 облака”.
До выхода редакции Grizzly, частота периодических задач указывалась в секундах между исполнениями. Это означало, что если периодическая задача для выполнения требовала 30 минут, а частота была установлена на час, то периодическая задача фактически выполнялась каждые 90 минут, потому что задача будет ждать час после окончания выполнения перед новым запуском. Ситуация изменилась в Grizzly, и теперь мы измеряем частоту периодических задач с момента старта задачи. Таким образом, наша периодическая задача на 30 минут будет запускаться каждый час, с 30-минутным ожиданием между окончанием первого запуска и началом следующего.
Расширенная поддержка глобальной кластеризации серверов хранения объектов должна быть добавлена начиная с редакции Grizzly (1.8.0), когда были введены регионы. Вы могли бы реализовывать такие глобальные кластеры для обеспечения репликации данных по географическим областям, на случай природного стихийного бедствия, а также для того, чтобы пользователи могли записывать или получить доступ к чвоим объектам быстрее на основе ближайшего центра обработки данных. Вы настраиваете регион по умолчанию с одной зоной для каждого кластера, однако, будьте уверены, что ваша глобальная сеть (WAN) сможет справиться с дополнительной нагрузкой запросов и ответов между зонами после того, как вы добавите несколько зон и построить кольцо, которое обрабатывает бОльшее число областей. Для получения дополнительной информации обратитесь к документации по Географически распределенным кластерам.