☰

Архитектура виртуального развертывания OpenStack (Juju/MAAS) с 1 физическим узлом

tag-icon • tag-icon juju maas openstack ceph
Архитектура виртуального развертывания OpenStack (Juju/MAAS) с 1 физическим узлом

Я хотел бы продемонстрировать некоторые функции OpenStacks HA/FT (самые важные — это живая миграция и репликация хранилища). Для этой цели у меня есть машина с 32 ГБ ОЗУ и Xeon e3v2 с 4 ядрами (8 потоков). Пока что мне удалось запустить MAAS и Juju, но я не уверен в количестве виртуальных узлов, которые я могу безопасно развернуть (и соотношении перерасхода ЦП/ОЗУ, хотя я где-то читал, что физический ЦП может довольно хорошо справляться с перерасходом на машинах с 1 vcpu).

В настоящее время виртуальная машина, на которой работает MAAS, использует 1 vCPU и 8 ГБ ОЗУ, Juju работает на хосте. Это оставляет мне 7 vCPU и 24 ГБ ОЗУ без перерасхода ресурсов. Я пришел к следующему:

  • 1 узел контроллера: 2vCPU, 4 ГБ ОЗУ - RabbitMQ, mysql, keystone, dashboard, cinder, nova-cloud-controller и Glance в контейнерах lxc
  • 2 узла Ceph: 1 vCPU, 4 ГБ ОЗУ каждый - ceph
  • 2 вычислительных узла: 2 vCPU, 8 ГБ ОЗУ каждый - nova-compute
  • 1 сетевой узел: 1 vCPU, 2 ГБ ОЗУ - квантовый шлюз
  • Плюс хост MAAS: 1 vCPU, 8 ГБ ОЗУ

В итоге это составит 38 ГБ ОЗУ и 10 виртуальных ЦП, так что я немного переоцениваю свои возможности.

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

решение1

У меня похожая конфигурация, и позвольте мне предложить вам:

  • Уменьшите объем оперативной памяти, выделенной для MAAS, около 2 ГБ будет достаточно.
  • Добавьте еще один узел ceph, это поможет вам продемонстрировать устойчивость при использовании ceph и выходе из строя одного узла.
  • Перегрузка ЦП не так уж и плоха, но не стоит перегружать память, поскольку система начнет выполнять подкачку, и производительность станет невыносимой.
  • Вы не упомянули о дисках, которые у вас есть. Для меня это огромное узкое место. У меня есть 2 диска по 7200 об/мин с BTRFS (raid0), но этого недостаточно, пока развертывается Juju.
  • Также вы можете использовать juju-deployer и настроить командную строку, используемую для развертывания, в частности модификаторы тайм-аута и «-s», задающие задержку между каждым вызовом «juju deploy».

Надеюсь, это поможет.

Фелипе,

решение2

Я предлагаю вам сбросить его, если он все еще работает, и использовать LXD. У вас не должно возникнуть проблемразвертывание этогобез MaaS и просто запуск Juju с локальным управлением вашего локального LXDкак описано здесь. Ваша машина должна быть в состоянии запустить его, не слишком потея. Если вам требуется MaaS для демонстрации (это действительно довольно круто. Вы должны попробовать проверить Openstack Roadshows, которые Canonical проводит, если они есть поблизости...), то это становится немного сложнее.

Эта ссылка демонстрируетнастройка на 3 машинах, но вы можете проявить хитрость и развернуть Juju и MaaS на той же другой машине, если вам это действительно нужно. Если на вашей второй машине запущены MaaS и JuJu под LXD с мостом, подключенным к вашей лабораторной локальной сети, и ваш трафик PXE может пройти, вы должны иметь возможность запустить все это в контейнерах на двух машинах. Я пытаюсь сделать что-то подобное с виртуальными машинами VMWare Fusion на моем ноутбуке, где я подключил внутреннюю сеть к сетевому адаптеру Thunderbolt, чтобы позволить машинам MaaS и Juju оркестровать устройства Raspberry Pi и NUC.

решение3

У меня нет опыта использования juju для оркестровки OpenStack, но по опыту работы с ceph и OpenStack, в демонстрационных целях можно без проблем запустить ceph на машинах с 2 ГБ памяти, и я думаю, что хост maas также можно настроить на 6 ГБ вместо 8.

Я не знаю, позволяет ли juju объединять разные роли в одной виртуальной машине, в наших (не juju) развертываниях мы объединяем роли контроллера и сети в одной виртуальной машине (не используя контейнеры).

решение4

При использовании физических узлов в небольшом кластере, особенно в тестовой лаборатории, типичным сокращением является объединение ceph-узлов с вашими вычислительными узлами. Посмотрите на этот набор ceph-0.48-eraинструкции для дебиан, или это более современныйлабораторная конфигурация для proxmox VE.

Используя предоставленные вами числа и предложения по уменьшению оперативной памяти и тройному цеф в других ответах, возможно, получится что-то вроде этого:

  1. 3vCpu + 8gb == RabbitMQ/keystone/glance/и т.д. + cephMon1/Osd1
  2. 2vCpu + 10gb == novaComp2/Net2/Vol2 + cephMon2/Osd2/Httpd2/Rgw2
  3. 2vCpu + 10gb == novaComp3/Net3 + cephMon3/Osd3
  4. 1vCpu + 2gb == novaQuantum4
  5. 1vCpu + 3gb == MAAS_host5

Я сейчас работаю над одноузловой конфигурацией такого рода, но у меня меньше доступной оперативной памяти и только четыре диска для выделения (cephOsd лучше с несколькими дисками). Я не могу подтвердить, что приведенные выше цифры будут работать для вас с адекватной производительностью, поскольку сам не пробовал эту схему, но основная идея слияния несколько ортогональных узлов для экономии vCpu&ram может дать вам достаточно тяги, чтобы достичь желаемого.

ps См. также полуофициальную справочную документацию для OpenStack в одном физическом узле содинVM, а также более актуальное руководство по OpenStack на специальном сервере на devstack.org

Связанный контент