ГЛАВА 4

Вычислительные узлы

Вычислительные узлы образуют ядро ресурсов облака OpenStack Compute, предоставляя для запуска экземпляров процессоры, память, сетевые ресурсы и ресурсы систем хранения.

Выбор процессора

Выбор типа процессора в вашем вычислительном узле является очень важным. Для начала убедитесь, что процессор поддерживает виртуализацию посредством VT-x чипов Intel, или AMD-v для чипов AMD.

На ваше решение также влияет число ядер в процессоре. Для современных процессоров обычным является наличие до 12 ядер. Кроме того, если процессор поддерживает технологию Hyper-threading, эти 12 ядер удваиваются до 24 ядер (прим. перев.: корректнее, аппаратных потоков). Если вы приобретаете сервер, поддерживающий несколько процессоров, количество ядер еще умножается.

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

Выбор гипервизора

OpenStack Compute поддерживает множество гипервизоров для различных уровней, в том числе KVM, LXC, QEMU, UML, VMWare ESX/ESXi, Xen, PowerVM, Hyper-V.

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

Например, KVM является наиболее часто используемым гипервизором в сообществе OpenStack. Помимо KVM, многие существующие реализации чаще чем с остальными перечисленными работают с Xen, LXC, VMWare и Hyper-V — однако, каждому из них не хватает некоторых функций поддержки или устарела документация об их использовании с OpenStack.

Наилучшая информация для поддержки вашего выбора может быть найдена в матрице поддержки гипервизоров ( https://wiki.openstack.org/wiki/HypervisorSupportMatrix), а также в справочнике конфигурации ( http://docs.openstack.org/trunk/config-reference/content/section_compute-hypervisors.html).

Кроме того возможен запуск нескольких гипервизоров в одной реализации с использованием Объединения хостов (Host Aggregates) или Ячеек (Cells). Тем не менее, на отдельном вычислительном узле в одно и тоже время может работать только один гипервизор.

Решения хранилищ экземпляра

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

Это подходы

• Система хранения вне вычислительного узла – совместно используемая файловая система
• Система хранения на вычислительном узле – совместно используемая файловая система
• Система хранения на вычислительном узле – не разделяемая файловая система

В общем случае, вопросы на которые вы должны ответить при выборе СХД будут следующими:

• Какое количество дисковых пластин вы хотите получить?
• Можно ли получить лучшую производительность ввода/вывода добавляя шпиндели при неизменной сетевой структуре?
• К какому результату с лучшим соотношением стоимость-производительность вы стремитесь?
• Как вы оперативно управляете системой хранения?

Система хранения вне вычислительного узла – совместно используемая файловая система

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

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

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

В этом случае диски для хранения работающих экземпляров размещаются на серверах за пределами вычислительных узлов. Существует ряд преимуществ такого подхода:

• При выходе из строя вычислительных узлов экземпляры обычно легко восстанавливаются
• Работа выделенной системы хранения может быть проще в эксплуатации
• возможность масштабирования на любое количество шпинделей
• Становится возможным совместно использовать внешние накопители для других целей

Основные недостатки такого подхода:

• В зависимости от конструкции, интенсивное использование ввода/вывода может приводить к несвязности экземпляров.
• Использование сети может приводить к снижению производительности

Система хранения на вычислительном узле – совместно используемая файловая система

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

Однако, данная система имеет ряд негативных моментов:

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

Система хранения на вычислительном узле – не разделяемая файловая система

В данном случае каждый nova-compute узел снабжается достаточным количеством дисков для хранения экземпляров своих хостов. Существует две основные причины, почему это является хорошей идеей:

• Использование интенсивной нагрузки ввода/вывода на одном вычислительном узле не влияет на экземпляры на других вычислительных узлах.
• Ввод/вывод с пямым доступом может повысить производительность.

Он также имеет недостатки:

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

Проблемы миграции в реальном масштабе времени

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

Миграция в реальном масштабе времени может быть выполнена и при использовании не разделяемых хранилищ с использованием функции, известной как миграция динамических блоков KVM (KVM live block migration). Хотя ранее реализация блочной миграции KVM и QEMU считалась ненадежной, существуют более новые, более надежные реализации блочной миграции в реальном режиме времени, такие как QEMU 1.4 и libvirt 1.0.2, которые, к тому же, совместимы с OpenStack. Тем не менее, ни один из авторов данного руководства не имеет опыта первых рук использования блочной миграции в реальном времени.

Выбор файловой системы

Если вы хотите поддерживать миграцию в реальном времени на совместно используемой системе хранения, вам необходимо настроить распределенную файловую систему.

Возможные варианты включают:

• NFS (система по умолчанию для Linux)
• ClusterFS
• MooseFS
• Lustre
• Прим. перев.: GPFS,
  см. http://www.mdl.ru/Solutions/Put.htm?Nme=GPFS, например, подробности во врезке "Сосредоточение внимания на OpenStack" в книге "Определяемые программным обеспечением системы хранения `для чайников`".

Нам знакомо применение всех этих систем и мы рекомендуем вам выбрать ту, с которой у вас есть наибольший практический опыт.

Перегруженное выделение

OpenStack позволяет перерасход (overcommit) процессоров и памяти на вычислительных узлах. Это позволяет вам увеличить количество экземпляров, которое вы можете иметь работающими в вашем облаке за счет снижения производительности этих экземпляров. OpenStack Compute использует следующие коэффициенты по умолчанию:

• Отношение выделения процессоров: 16
• Отношение выделения памяти: 1.5

Коэффициент выделения процессоров по умолчанию 16 означает, что планировщик распределяет до 16 виртуальных ядер на узле для физического ядра. Например, если физический узел имеет 12 ядер, планировщик выделяет до 192 виртуальных ядер для экземпляров (например, если каждый экземпляр имеет 4 виртуальных ядра, будет запущено 48 экземпляров).

Точно так же, значение по умолчанию, равное 1.5, для коэффициента выделения памяти означает, что планировщик распределяет экземпляры в физическом узле, пока общее количество оперативной памяти, связанной с экземплярами меньше чем 3/2 объема оперативной памяти, доступной на физическом узле.

Например, если физический узел имеет 48ГБ оперативной памяти, планировщик распределяет экземпляры на этом узле, пока сумма ОЗУ, связанного с этими экземплярами не достигнет 72ГБ (например, девять, когда каждый экземпляр имеет 8ГБ ОЗУ).

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

Ведение журнала

Журналирование более подробно описано в главе под названием "Ведение журнала". Однако важно принять во внимание анализ проекта до начала эксплуатации вашего облака.

OpenStack порождает много полезной регистрационной информации, однако, для того, чтобы она стала полезной для целей эксплуатации вы должны рассмотреть возможность наличия центрального сервера журналирования, чтобы отправлять туда журналы, а также систему разбора/анализа журналов (например, logstash).

Сетевое обеспечение

Сеть в OpenStack является сложной, многогранной проблемой. См. Главу 6.

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