У себя в компании я часто сталкиваюсь, что нужно поднять какой-то сервис, чтобы "общупать" его досконально. Хотя PCшники у нас довольно мощные, но большую часть ресурсов съедают PyCharm и Chrome, а на виртуалки с экспериментами очень часто остаётся совсем мало. Поэтому мы завели у себя небольшую стойку с парой-тройкой серверов для экспериментов и локального Gitlab'а. Но что-то пошло не так и очень захотелось поиграться с чем-то новым. Я далеко не журналист, поэтому прошу заранее простить меня за возможные ошибки в тексте. Хотя я и пробежался по тексту, но всё равно мог что-то упустить. Всегда открыт к исправлениям в личном сообщении. Помимо всего прочего "о вкусах не спорят" и я ничего не рекламирую, а просто хочу поделиться тем, как мы решили нашу задачу. Ну и конечно же всё это можно было сделать иначе, но мне захотелось именно так. В своё время, так как у наших заказчиков часто стоит OpenStack, мы его так же успешно развернули, чтобы совместить боль и слёзы тестирование одних продуктов с другими.
Но проблема в том, что офис != ДЦ и нам повезло снимать офис в месте, где стабильно каждые 2-3 месяца вырубают свет, притом делают это ночью, пока никто не видит. А вы пробовали поднимать кластер OpenStack после сбоя по питанию? Да и в целом продукт явно заточен не на наши нужды (хоть и очень удобно поднимать по 5-10 нод или разворачивать ansible'м целую инфраструктуру). Ещё очень огорчало поедание ресурсов просто работающего кластера (фактически 2-3 сервера по 4CPU/16GbRAM чисто под работу пустого кластера) и необходимость держать контроллер отдельно от compute-ноды, чтобы не мешать работе (AIO отъедает в простое 35Гб ОЗУ — это как-то многовато для сервера в офисе). Конечно можно было бы всё вынести в AWS/DO/Azure/GCE, но если есть 3-4 сервера, то почему бы их не использовать, ведь так или иначе уже имеющееся оборудование выйдет дешевле "облака". Собственно об железе: Помимо всего прочего, есть: Последние 2 сервера были успешно оккупированы после того, как очередной внезапный ночной сбой по питанию привёл Ceph в OpenStack'е в негодность и было принято вынести их на независимые ноды. Впрочем, ничего не мешает их потом перенести в VM. HITACHI вообще 2 шт, но мы всё вгрузили в одну машину и позже я поясню почему.
Я так подробно расписываю, просто, чтобы было понятно принятое решение. Основная проблема с OpenStack была в том, что AIO был слишком прожорливым и конкурировал с виртуалками, а размазывание по хостам… Короче говоря, ванильный OpenStack как бы нам ни нравился, но не подходил под наши нужды и возможности. Логично было бы предположить, что может стоит перейти на VMWare ESXi (как многие товарищи и предлагали). Но не лежала душа у меня к этому продукту... Нужно было то, что можно будет хорошо закастомизировать под наши нужды (где-то в пересечении дёшево, производительно и гибко), а так же, чтобы этим было удобно пользоваться простым разработчикам, которые не хотят ничего настраивать, а только делать "фыр-фыр-фыр" кодить и ставить эксперименты. Выбор пал на Proxmox VE, потому что: Публикация далее описывает то, как я настраивал инфраструктуру только сервера с Proxmox практически в живом режиме. Перенос серверов Gitlab'а никак не описывается, потому что к этой теме никак не относится. Есть некоторое legacy после OpenStack по нарезке сети, в частности публичная сеть и настройки OSPF на Mikrotik'ах. Хотелось следующего: Буду описывать как это сделать "с нуля": Нельзя сказать, что это прям очень правильное правило, но если кто из знатоков подскажет как правильно его написать, то буду премного благодарен. Вообще нам изоляция нужна только на L2, но на L3 привожу больше для ознакомления. Сервер будет настроен так, чтобы получить максимальную производительность от текущих дисков. Однако мы не забываем, что всё может случиться и ночью свет может резко на час-другой пропасть пока все спят. Так как мы ничего не хотим покупать, то следует отключить всё, что связано с подпиской: На этом пока закончим основную настройку. Вообще настройка Proxmox Bridge для работы достаточно простая. Но я не я, если не удалю гланды ректально сделаю что-нибудь экстравагантное. Мне очень хотелось, чтобы работал OVSBridge и на OVSBond. Но проблема в том, что мне так же не хотелось бы, чтобы пользователи каждый раз назначали VLAN при создании VM/LXC. Поэтому порядок настройки следующий для всех 6ти интерфейсов: Прежде всего удаляем старый pve/data, чтобы не запутаться с meta-разделом и т.д. Добавляем второй раздел к нашему volume group: Создаём новый раздел как нас учит документация Proxmox + небольшой хак для оптимизации snapshot'ов: Теперь нам нужно подключить lvmcache, но в целях оптимизации ресурса SSD, я специально выделил раздел на нём размером 241Гб. Этого объёма вполне хватит для кеша, а оставшаяся часть диска будет ресурсом для убитых блоков. Правда это в теории, потому что лично мне до конца не понятно работает ли это. В любом случае, кеш в 465Гб потом будет вдвое дольше и сложнее удалять (например, чтобы заменить диск или расширить массив). UPD: есть один глюк с dm_cache, из-за которого нужно проделать ещё одну магию: Поначалу всё работало, но потом почему-то перестало. Видимо с обновлением удалили эти модули. Обычно я перед перезагрузкой делаю, чтобы быть уверенным, что всё обновлено и ядро самое свежее: К слову, в 6ой версии ядро 5.0, а на подходе (на момент публикации) вроде как 5.3.7.
Всё, теперь отправляем систему в ребут. Если мы всё правильно сделали, то после перезагрузки наш сервер будет доступен извне по обоим адресам. Так же можно будет загрузить свежие шаблоны контейнеров и радоваться жизни. Ну мы же не просто админы, а DevOps'ы (что это вообще значит?), поэтому нам нужно знать, когда какая-то из виртуалок взбесится и будет творить непотребства. Вообще все эти действия проще всего сделать в GUI, но на меня внезапно напала агрессивная форма лени, чтобы делать скриншоты, поэтому опишу командами. Смотрим доступные нам шаблоны: Думаю для начала можно загрузить ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz: Создадим контейнер для InfluxDB и Grafana: Подключаемся к терминалу нашей виртуалки по ssh root@172.16.1.101 или через pct console 999. Устанавливаем пакеты InfluxDB и Grafana: Настраиваем InfluxDB для работы. Нам для этого нужно будет сперва создать базу: Далее, нам необходимо настроить UDP-порт, на который Proxmox будет слать запросы: … и теперь перезапустим influx: systemctl restart influxdb Тут всё предельно просто. На сервере с proxmox'ом нужно создать файл следующего содержания: Файла там по умолчанию нет. По какой-то мне неведомой причине метрики пошли не сразу, поэтому пришлось вызвать systemctl restart pvestatd на сервере проксмокса. Теперь нам нужно всё это визуализировать. Заходим в нашу grafana по адресу http://172.16.1.101:3000/ (admin:admin), меняем пароль.
Нашёл в дебрях сайта графаны, что можно прикрутить красивый дашборд для визуализации Proxmox, но его пришлось немного подпилить напильником исправить, чтобы учесть все наши реалии.  Теперь нам нужно импортировать Dashboard: В общем-то всё. Для удобства, я дополнительно туда же подключил Dashboard'ы из Gitlab. Описывать этот процесс нет смысла, надо только иметь в виду, что Prometheus должен быть доступен с этого контейнера, его необходимо подключить как Datastore в Grafana и при экспорте дашбордов указывать, что они external, чтобы выбрать нужный datastore. Со скриншотами из свежей Grafana косяк вышел, поэтому простите за качество.


 Специалист