Планирование аппаратного обеспечения для вашего кластера OpenStack: ответы на ваши вопросы

в 10:11, , рубрики: cinder, fuel, nagios, Neutron, Open Compute, open source, openstack, swift, VLAN, zabbix, аппаратное обеспечение, Блог компании Mirantis/OpenStack, виртуальная машина, гипервизор, кластер, коммутатор, мирантис, сервер, трафик, метки: , , , , , , , , , , , , , , , , ,

Автор: Грег Елкинбард

Моя коллега Анна Френд (Anne Friend) и я недавно представляли вебинар на тему “Как справиться с планированием аппаратного обеспечения для вашего облака OpenStack“ . Во время вебинара мы обещали дать вам ответы на вопросы, которые не успели озвучить в прямом эфире. Эта статья и будет посвящена ответам на данные вопросы.

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

Типичный центральный коммутатор не обладает одинаковой пропускной способностью канала восходящей связи по сравнению с пропускной способностью канала нисходящей связи. Например, обычно коммутатор trident+ будет иметь 48 10-гиговых портов для нисходящей связи с общей пропускной способностью 960 Гб/c, но только 4×40-гиговых портов или 320 гигов в качестве пропускной способности в восходящем направлении, таким образом, лимит превышен примерно в соотношении 3/1.

Это означает, что вам следует ограничить трафик, проходящий вверх по каналам связи. Это можно сделать двумя способами. Один – это запускать пользовательские ВМки в домене (L2-сегменте) пограничного коммутатора, чтобы снизить трафик между исходящими связями.

Второй основной источник трафика – это трафик Cinder между узлом Cinder и узлом Compute. Концентрация этого трафика в одном коммутаторе также разгрузит восходящий канал. Например, если вы используете Cinder ISCSI хранилища, то вы можете предоставить один или два коммутатора на стойку и убедиться, что планировщик Cinder создает тома из хранилища, расположенного в той же стойке, что и ресурсы Compute. Оба эти фильтра пользовательские, их необходимо создать для планировщиков Nova и Cinder. Это не совсем “готовое решение”, но это простое изменение.

Я пытаюсь понять, как мы можем применить некоторые компромиссные варианты, которые вы описали в более частных терминах. Можете ли вы привести численный пример компромисса при выделении vCPU/VRAM для двух разных случаев?

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

Требования к ЦП
-100 виртуальных машин
-В среднем 2 вычислительных узла EC2
-Максимум 16 вычислительных узлов EC2
-Отсутствие превышения лимита

Это соответствует:
-200 ГГц емкости ЦП (100 пользователей x 2 ГГц/пользователя)
-Максимальное число ядер — 5 (16 ГГц / 2.4 ГГц на ядро)

На основе расчетов:
-Коэффициент на Hyperthreading 1.3
-10-11 ядер E5 2640 (200 ГГц / 2.4 ГГц на ЦП / 6 ядер)
-5-6 двухядерных серверов (11 ядер / 2 ядра на сервер)
-17 ВМ на сервер (100 ВМ / 6 серверов)

Требования к памяти
-100 виртуальных машин
-4 Гб на виртуальную машину
-Минимум 512 Мб, максимум 32 Гб

Это соответствует:
-400 Гб итого (100 ВМ * 4 Гб на одну ВМ)

На основе следующих расчетов:
-Необходимость в четырех машинах по 128ГБ (400 Гб / 128 Гб)
-Балансировка с ЦП, вам потребуется 6 машин для общей емкости ЦП
-Сократить память сервера и работать с 6 машинами по 64 или 96 ГБ (6x64 ГБ равно 384 ГБ, 6×96 равно 596ГБ)

Если вам необходимо иметь чуть больше памяти, вам нужны машины емкостью 96 Гб.

Когда вы говорите, что VLAN подходит для небольшой сети, насколько небольшую сеть имеете в виду?

Небольшая сеть имеет менее 4 тысяч виртуальных сетей. Тем не менее, так как Neutron позволяет каждому пользователю иметь несколько сетей, вы не можете полагать, что вы можете разместить 4 тысячи пользователей. Также не забывайте, что у вас есть некоторые нужды статичной инфраструктуры; не забудьте сохранить теги для этих сетей.

Как Fuel помогает выполнить автоматизированную настройку сети?

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

Как вы полагаете, лучше ли использовать аппаратное обеспечение известных производителей, таких как Dell, HP и т.п., или мы сможем достичь той же производительности с помощью созданного нами программного обеспечения? Рекомендуется ли использовать Open Compute Platform?

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

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

Рекомендуете ли вы отдельное ПО для узлов, на которых запущены отдельные сервисы nova? Например, должен ли узел, на котором запущен nova-api, иметь больше памяти, чем узел, на котором запущен glance-api?

Мы в компании Mirantis рекомендуем консолидировать все сервисы инфраструктуры OpenStack в выделенные узлы под названием контроллеры. Этот вид архитектуры облегчает обеспечение высокой доступности.

Что насчет микросерверов, основанных на ARM (или Atom)?

Если у вас облако общего назначения, вам будет трудно создать значительную нагрузку на ЦП на микросерверах на основе ARM или Atom. Попробуйте запустить сервер MsSQL или Oracle на ARM; вы не много добьетесь. Если у вас облако специального назначения, которое укладывается в ограничения этих ЦП, тогда используйте их в любом случае. Облако не полагается полностью на ЦП, а архитектура многих процессоров на основе ARM/Atom не предполагает достаточной пропускной способности или пространства на диске для того, чтобы стать хорошей платформой.

Что насчет «лезвийных серверов»?

Оставьте лезвия для бритья. Используйте для облака обычные серверы. Если нужна более высокая плотность, используйте сервера форм-фактора sleds (Dell C-class, HP SL-class) вместо блейд-серверов. Центральный модуль сервера-лезвия обычно не имеет достаточно пропускной способности, чтобы хорошо работать с облаком, и недостаточно локального пространства для хранения, что помещает двойную нагрузку на ваши требования к пропускной способности шасси. Кроме того, вы оплачиваете премию за такие сервера. Одна или две схемы блейд-устройств начали устранять как минимум узкое место в сети, но остаются и другие сомнения.

Можем ли мы обеспечить миграцию в реальном времени без совместного хранилища?

Вы можете выполнить миграцию в реальном времени без совместного хранилища. Она просто займёт больше времени.

Для небольшого частного облака рекомендуете ли вы оптоволоконный канал для совместного хранения на вычислительных узлах или коллективно-используемую файловую систему на 1 Гигабит?

Ни то, ни другое. Используйте 10 гигов и Ceph или другое блоковое хранилище. Вам не нужно совместно используемое FS или затраты на оптоволокно.

Можете ли вы чуть больше рассказать о требовании к swift 6.5x?

Это отдельный вопрос с более детальным ответом в записанном вебинаре, но вот простое вычисление:

Примите фактор репликации равный 3.

Добавьте два ручных устройства (необходимы для дополнительного пространства для сбоев)

Кроме того, если вы превышаете 75% емкости диска XFS, у вас возникнут проблемы, и получится вот такой расчёт:

(3+2)/.75 = 6.7

После развертывания какие инструменты вы используете или использовали, чтобы проверить загрузку ЦП и аппаратного обеспечения?

В Mirantis мы использовали (и успешно) Nagios и Zabbix.

Можно ли развернуть OpenStack на платформе OCP (Open Compute Platform)?

Да. Mirantis Fuel в целом не зависит от архитектуры аппаратного обеспечения.

Как бездисковые гипервизоры встраиваются в уравнение хранения ‘местнo vs совместное использование vs объект’? Возможно ли управлять вычислительными узлами как клиентами iSCSI без диска, не нарушая возможности Cinder подключаться к целям iSCSI, или для оборудования нужно другое решение SAN?

Давайте чуть изменим вопрос и спросим, зачем вам такие сложности. С Mirantis Fuel для вас уже развернута операционная система. Наличие нескольких небольших дисков для ОС сделает настройку проще. Мы пробовали это раньше, но возникают проблемы в массивах, когда несколько инициаторов для ОС и Cinder с одного узла хотят обратиться к одной и той же цели. Это того не стоит.

Поддерживает ли Fuel объединение интерфейсов?

Да, но вам необходимо использовать интерфейс командной строки, а не веб-интерфейс.

Работали ли вы с гипервизорами на основе Illumos или с чем-либо, использующем Illumos, или работа велась только в Linux?

ZFS не настолько всеобъемлюща, чтобы стоило обращать внимание на побочные операционные системы вроде Solaris. Да, вы можете запускать XEN и KVM с предупреждениями и ограничениями. Если вы достаточно богаты для того, чтобы поддерживать свою собственную команду разработки операционной системы, вы можете это сделать, но вы всегда будете отставать по функциональности. Я создал с нуля несколько команд разработки ОС для различных компаний, и я могу вам сказать, что если это ваша профессиональная сфера — то вперёд. В ином случае лучше идти по проторенной дорожке: вам будет удобнее, чем пробираться сквозь джунгли.

Оригинал статьи на английском языке

Автор: Mirantis_OpenStack

Источник

Поделиться

* - обязательные к заполнению поля