В этой главе мы обсудим некоторые варианты, которые вам необходимо рассмотреть при построении ваших вычислительных узлов. Вычислительные узлы образуют ядро ресурсов облака OpenStack Compute, предоставляя для запуска экземпляров процессоры, память, сетевые ресурсы и ресурсы систем хранения.
Выбор типа процессора в вашем вычислительном узле является очень важным. Для начала убедитесь, что процессор поддерживает виртуализацию посредством VT-x для микросхем Intel, или AMD-v для микросхем AMD.
![[Tip]](../common/images/admon/tip.png) |
Совет |
|---|---|
|
Обратитесь к документации производителя для проверки того, поддерживается ли виртуализация. Для Intel, ознакомьтесь с “Поддерживает ли мой процессор технологию виртуализации Intel®?”. Для AMD, озакомьтесь с Виртуализация AMD. Заметим, что ваш процессор может поддерживать виртуализацию, однако она может быть выключена. Ознакомьтесь с документацией на BIOS для того чтобыпонять как разрешать свойства процессора. |
На ваше решение также влияет число ядер в процессоре. Для современных процессоров обычным является наличие до 12 ядер. Кроме того, если процессор поддерживает технологию Hyper-threading (многопоточности), эти 12 ядер удваиваются до 24 ядер (прим. перев.: корректнее, аппаратных потоков). Если вы приобретаете сервер, поддерживающий несколько процессоров, количество ядер еще умножается.
Гипервизор предоставляет программное обеспечение для управления доступом виртуальных машин к аппаратным средствам нижнего уровня. Гипервизор создает, управляет и контролирует виртуальные машины. OpenStack Compute поддерживает множество гипервизоров для различных уровней, в том числе:
Вероятно, наиболее важным фактором при вашем выборе гипервизора будет текущая практика использования или опыта. Кроме того, существуют практические соображения обойтись свойствами соответствия, документированности, а также уровня компетентности сообщества.
Например, KVM является наиболее часто используемым гипервизором в сообществе OpenStack. Помимо KVM, многие существующие реализации чаще чем с остальными перечисленными работают с Xen, LXC, VMWare и Hyper-V — однако, каждому из них не хватает некоторых функций поддержки или устарела документация об их использовании с OpenStack.
Наилучшая информация для поддержки вашего выбора может быть найдена в матрице поддержки гипервизоров а также в справочнике конфигурации.
![[Note]](../common/images/admon/note.png)
- Система хранения вне вычислительного узла – совместно используемая файловая система
- Система хранения на вычислительном узле – совместно используемая файловая система
- Система хранения на вычислительном узле – не разделяемая файловая система
- Проблемы миграции в реальном масштабе времени
- Выбор файловой системы
В рамках закупки для вычислительного кластера вам необходимо задать технические требования для дисковой системы хранения с которой работает установленный экземпляр. Существует три основных подхода предоставления такого хранилища временного типа и очень важно понимать последствия вашего выбора.
Это подходы:
-
Система хранения вне вычислительного узла – совместно используемая файловая система
-
Система хранения на вычислительном узле – совместно используемая файловая система
-
Система хранения на вычислительном узле – не разделяемая файловая система
В общем случае, вопросы на которые вы должны ответить при выборе системы хранения будут следующими:
-
Какое количество дисковых пластин вы хотите получить?
-
Можно ли получить лучшую производительность ввода/вывода добавляя шпиндели при неизменной сетевой структуре?
-
К какому результату с лучшим соотношением стоимость-производительность вы стремитесь?
-
Как вы оперативно управляете системой хранения?
Многие операторы используют раздельные хосты для вычислений и для хранения. Вычислительные службы и услуги хранения имеют различные требования, например, вычислительные хосты обычно требуют больше процессоров и памяти, чем хосты хранения. Таким образом при фиксированном бюджете есть смысл иметь различные конфигурации для ваших вычислительных узлов и ваших узлов хранения, при основных вложениях в процессоры и память на вычислительных узлах и главных затратах на блочные устройства на узлах хранения.
Однако, если вы более ограничены в количестве имеющихся у вас в наличии физических хостов для создания вашего облака и вы хотите дать возможность выделять работающим экземплярам все имеющиеся в вашем распоряжении хосты, имеет смысл запускать вычислительные хосты и хосты хранения на одинаковых компьютерах.
Мы рассмотрим все три главных подхода к экземплярам хранилищ в следующих нескольких разделах.
В данном разделе диски хранилища обслуживаются экземплярами, расположенными на серверах вне вычислительных узлов.
Когда вы используете раздельные хосты для вычислений и хранения данных, вы можете рассматривать ваши вычислительные узлы как "не запоминающие состояние". Если на вычислительном хосте у вас нет работающего в настоящий момент экземпляра, вы можете использовать его в автономном режиме или полностью очистить, что не окажет никакого влияния на оставшуюся часть вашего облака. Это упрощает обслуживание вычислительных хостов.
Существует ряд преимуществ такого подхода:
-
При выходе из строя вычислительных узлов экземпляры обычно легко восстанавливаются.
-
Работа выделенной системы хранения может быть проще в эксплуатации.
-
У вас есть возможность масштабирования на любое количество шпинделей.
-
Становится возможным совместно использовать внешние накопители для других целей .
Основные недостатки такого подхода:
-
В зависимости от конструкции, интенсивное использование ввода/вывода может приводить к несвязности экземпляров.
-
Использование сети может приводить к снижению производительности.
При данном выборе, каждый вычислительный узел имеет достаточное количество дисков, однако распределенная файловая система связывает диски всех вычислительных узлов в единую реализацию.
Основным преимуществом данного подхода заключается в том, что он масштабируется на внешние системы хранения по мере запросов на дополнительное пространство хранения.
Однако, данная система имеет ряд негативных моментов:
-
Запуск распределенной файловой системы может заставить вас утратить локальность данных по сравнению с не разделяемым хранилищем.
-
Восстановление экземпляров усложняется из- за зависимости от множества хостов.
-
Физические размеры шасси вычислительного узла могут ограничивать количество шпинделей, доступное в вычислительном узле.
-
Использование сети может привести к снижению производительности.
В данном случае каждый вычислительный узел снабжается достаточным количеством дисков для хранения экземпляров своих хостов.
Существует две основные причины, почему это является хорошей идеей:
-
Использование интенсивной нагрузки ввода/вывода на одном вычислительном узле не влияет на экземпляры на других вычислительных узлах.
-
Ввод/вывод с пямым доступом может повысить производительность.
Он также имеет недостатки:
-
В случае отказа данного узла, работающие на нем экземпляры утрачиваются.
-
Физические размеры шасси вычислительного узла могут ограничивать количество шпинделей, доступное в вычислительном узле.
-
Миграция экземпляров с одного узла на другой является более сложной и может быть основана на функциях, которые могут не получить поддержки в дальнейших разработках.
-
В случае потребности в дополнительном пространстве хранения, данное решение не является масштабируемым.
Работа совместно используемой файловой системы всистеме хранения отдельном от вычислительных узлов идеально подходит для облаков, в которых надежность и масштабируемость являются наиболее важными факторами. Работа совместно используемой файловой системы на самих вычислительных узлах может быть лучшим сценарием при котором вы должны развертывать предустановленные серверы для которых вы практически не имеете возможности управления их спецификациями. Запуск не разделяемой файловой системы на самих вычислительных узлах может быть хорошей идеей для облака с высокими требованиями к вводу/выводу и низкими требованиями к надежности.
Мы рассматриваем миграцию в реальном масштабе времени неотъемлемой частью деятельности облака. Эта функция обеспечивает возможность экземплярам беспрепятственно передвигаться с одного хоста на другой, необходимость выполнения для требующих перезагрузки на хосте обновлений, однако хорошо работает только с совместно используемой системой хранения.
Миграция в реальном масштабе времени может быть выполнена и при использовании не разделяемых хранилищ с использованием функции, известной как миграция динамических блоков KVM (KVM live block migration). Хотя ранее реализация блочной миграции KVM и QEMU считалась ненадежной, существуют более новые, более надежные реализации блочной миграции в реальном режиме времени, такие как QEMU 1.4 и libvirt 1.0.2, которые, к тому же, совместимы с OpenStack. Тем не менее, ни один из авторов данного руководства не имеет опыта первых рук использования блочной миграции в реальном времени.
Если вы хотите поддерживать миграцию в реальном времени на совместно используемой системе хранения, вам необходимо настроить распределенную файловую систему.
Возможные варианты включают:
-
NFS (система по умолчанию для Linux)
-
GlusterFS
-
MooseFS
-
Lustre
-
Прим. перев.: GPFS, см. http://www.mdl.ru/Solutions/Put.htm?Nme=GPFS, например, подробности во врезке "Сосредоточение внимания на OpenStack" в книге "Определяемые программным обеспечением системы хранения `для чайников`"
Нам знакомо применение всех этих систем и мы рекомендуем вам выбрать ту, с которой у вас есть наибольший практический опыт.Если вы не знакомы ни с одной из них, выберите NFS, поскольку она наиболее проста в установке и существует обширное сообщество со знаниями о ней.
OpenStack позволяет перерасход (overcommit) процессоров и памяти на вычислительных узлах. Это позволяет вам увеличить количество экземпляров, которое вы можете иметь работающими в вашем облаке за счет снижения производительности этих экземпляров. OpenStack Compute использует следующие коэффициенты по умолчанию:
-
Отношение выделения процессоров: 16:1
-
Отношение выделения памяти: 1.5:1
Коэффициент выделения процессоров по умолчанию 16:1 означает, что планировщик распределяет до 16 виртуальных ядер на узле для физического ядра. Например, если физический узел имеет 12 ядер, планировщик выделяет до 192 виртуальных ядер для экземпляров. При типичном определении предпочтения каждый экземпляр имеет 4 виртуальных ядра, при этом соотношении на физическом узле будет запущено 48 экземпляров.
Формула для числа виртуальных экземпляров на вычислительном узле такая: (OR*PC)/VC, где:
- OR
-
Соотношение перегрузки процессора (число виртуальных ядер на физическое ядро)
- PC
Число физических ядер
- VC
-
Число виртуальных ядер на экземпляр
Точно так же, значение по умолчанию, равное 1.5:1, для коэффициента выделения оперативной памяти означает, что планировщик распределяет экземпляры в физическом узле, пока общее количество оперативной памяти, связанной с экземплярами меньше чем 3/2 объема оперативной памяти, доступной на физическом узле.
Например, если физический узел имеет 48ГБ оперативной памяти, планировщик распределяет экземпляры на этом узле, пока сумма ОЗУ, связанного с этими экземплярами не достигнет 72ГБ (например, девять, когда каждый экземпляр имеет 8ГБ ОЗУ).
Вы должны выбрать надлежащее значения коэффициента выделения процессоров и памяти для вашего конкретного случая.
Ведение журнала более подробно описано Главе 13, Ведение журнала и мониторинг. Однако важно принять во внимание анализ проекта до начала эксплуатации вашего облака.
OpenStack порождает много полезной регистрационной информации, однако, для того, чтобы она стала полезной для целей эксплуатации вы должны рассмотреть возможность наличия центрального сервера ведения журнала, чтобы отправлять туда журналы, а также систему разбора/анализа журналов (например, logstash).
Сеть в OpenStack является сложной, многогранной проблемой. См. Главу 7, Проектирование сети.