Опубликован релиз Proxmox Virtual Environment 8.3, специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таких продуктов, как VMware vSphere, Microsoft Hyper-V и Citrix Hypervisor. Размер установочного iso-образа 1.4 ГБ...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62273
> более плотная интеграция стека для создания программно определяемых сетей (SDN, Software-Defined Networking) с межсетевым экраномSDN в Proxmox - это страшный долгострой и один из главных блокеров для больших внедрений у Proxmox. Всем админам локалхоста и одной стойки сразу поясняю. Это не для вас, я знаю, что вам это не нужно, а тем, кому нужно, тому не нужен проксмокс и никакой заменой он не выступает. Вопрос сетевой изоляции на маленьких развертываниях не возникает.
Они молодцы, что пошли по пути интеграции с EVPN в восьмой ветке. Это значит, что в перспективе на Proxmox когда-нибудь можно будет построить Telco Cloud
- https://www.vmware.com/topics/telco-cloud
- https://www.redhat.com/en/topics/cloud-computing/what-is-tel...
На данный момент в Proxmox это эффективно не реализовать.Сейчас наконец-то можно растянуть зону (сетевой теннант или VRF) между несколькими кластерами Proxmox, если вышестоящее оборудование работает по EVPN-VXLAN и имеет отдельно стоящий контроллер SDN, который сам способен реализовать поддержку федерации SDN в рамках Data Center Interconnect.
Для сравнения, OpenStack Neutron (OVN) и VMware NSX4+ умеют все целиком, то есть могут на себе держать контроллеры сети.В Proxmox, в отличии от того же Hyper-V и XCP-NG есть хотя бы "зайчатки", они движутся в правильном направлении, но только мало...
Для развития SDN и сетевой изоляции нужны как минимум:
- балансировщики нагрузки, интегрированные с FRRouting, которые способны публиковать сервисы из оверлейных сетей на VIP-ы из префиксов внешних сетей (Load Balancer as a Service)
- поддержка IPsec VPN на роутерах, которая стыкует тунель с тенантом в оверлейной сети в режиме Site-to-Site (VPN as a Service)
- автоматизации вокруг кастомного L3-роутинга в сетевой тенант, чтобы люди могли настроить свою маршрутизацию в тенанте (BGP as a Service)Опять же, Q-in-Q и PVLAN должны всегда оставаться опцией, потому что подача физических серверов в тот же сетевой тенант далеко не всегда сводится к тому, чтобы приземлить VTEP-на физическом ToR-свитче над этим сервером. То есть это будет работать... в корпоративной среде. В облачной и провайдерской - не достаточно безопасности и нет изоляции. В случае аренды сервера/колокейшена требуется Port Security, ARP Inspection, DHCP Snooping на L2-сети перед сданным в аренду сервером, а эти технологии (сюрприз!) не совместимы с EVPN-VXLAN по смыслу. То есть в облаке нужно стараться иметь Access-свитчи для дедикейтед серверов с параметрами безопасности и сетевой изоляцией на L2, которую вышестоящие Leaf-свитчи должны яростно тунелировать в VXLAN и отправлять в облачный тенант.
То есть Proxmox движется по смыслу в правильном направлении, но пока еще недозрел до крупняка.
Сторадж, опять же... В Proxmox нет надёжного способа сделать конвергентную сеть (compute+storage) и нет надёжных протоколов подачи кластерного стораджа, кроме Fiber Channel в сторону проприетарных серверов хранения. Остальные опции или недоделанные, или медленные, или ненадёжные. Ну то есть натурально. Проприетарные сервера хранения вроде всяких двухголовых Storage Bridge Bay по штуке на кластер в стойку. И сверху объектыный медленный сторадж на Ceph. Это будет работать, но это не достаточно гибко.
Управление гиперкластером, опять же... тоже дырка в голову. В общем, телеком и сервис-провайдеры его обычно не ставят.
Всё так.
PVE называют виртуализацией для домохозяек, это не облачное решение провайдера услуг, это именно оркестрация виртуальных машин (ну и LXD). Хорошо подходит для развёртывание VMок, без дополнительных требований, чего многим достаточно.Если исходить из требований провайдера облачных услуг, начинать надо с установки хотябы OpenNebula, но всё одно путь будет к OpenStack.
А для домохозяек есть incus/lxd со своим WebUI
Ставится на обычную Ubuntu, без необходимости ставить специальный дистр и прекрасно дает виртуалки и контейнеры(lxc), пашет хоть на amd64, хоть на arm64, жрать не просит(а Proxmox просит, буквально просит, в смысле, что либо ты альфа-тестер, либо платишь им подписку)По сути вот уже лет 10-12 Proxmox это альтернатива XCP, такая себе нишевая вещь для маленьких инсталяций, для контор с парой-тройкой-десятком серверов, где нет нужды разворачивать OpenStack
> SDN в Proxmox - это страшный долгострой и один из главных блокеров для больших внедрений у
> Proxmox.А с SDS конечно все замечательно, ога!
Вон аж ТРИ разношерстных версии одного и того же (а говорили - ничему не учатся! Тот опыт "автоапгрейда" у чуваков с редита явно имел большой успех у клиентов.)
Другого SDS нахаляву, то ись, даром - у меня для вас нет. Ой, простите. У rhbm для вас нет.
А поляки не потянули.
Всё правильно, вас зря минусуют. Скорее всего, вы в курсе про всё это, но всё равно напишу...
Я тоже не видел сколько-нибудь быстрого открытого SDS-решения, даже если all-nvme в однопроцессорные серваки поставить. VMware VSAN и Microsoft S2D справляются. Nutanix я в большом проде не крутил.А что там вообще есть открытое? Linstor и Ceph.
Хрустальный дворец под названием Linstor слишком хрустальный и не живет вне L2-домена, то есть годится как сторадж на один кластер. Проблема кроется в DRBD как протоколе репликации, который сложно пропихнуть через L3-сеть, соблюдая все необходимые QoS-ы в конвергентной сети (compute + storage). Из коробки это просто не реально. L2-вполне реально, а вот L3... Я не знаю, насколько сейчас платное и доступное решение DRBD over RoCEv2 с поддержкой DPDK-интерфейсов. Если это доступная опция в бесплатном Linstor, то можно положиться на OFED-драйверы сетевок NVIDIA/Mellanox и завернуть трафик на L3 по IP-фабрике хотя бы в рамках PoD-а датацентра. Опять же, это потребует свитчей Cisco Nexus 9300+ с доп. лицензиями на RDMA, Juniper QFX5120+ или NVIDIA Mellanox SN3000+. На этих свитчах придётся построить Lossless Ethernet с PFC-приоритетом для DRBD. Как показала практика, для большинства сетевых администраторов с которыми я работал за последние 10 лет такие вещи как конвертация пометки PCP<->DSCP и вдумчивое строительство Diffserv-домена в датацентре поверх IP-фабрики с MP-BGP в качестве внутренней маршрутизации - это капец проблема компетенции. Я допускаю, что это мне с сетевиками не везёт, но рынок труда тоже не блещет знаниями знаниями сложных датацентровых QoS.
Если у вас башковитые сетевые архитекторы, у которых руки откуда нужно растут и они вам способны заплести вам косы такой пышности, что учтется соотношение резервирование буферов на портах свитчей, сетевок в соотношении к длинам кабелей и у вас будут WRED/DDWR профили на очередях, которые до последнего маркируют ECN и перед посылкой PFC-фреймов, то тогда вам все равно вообще, какой SDS. У вас сеть работает и вам не нужно полагаться на TCP с его тормозами на сторадже. У вас от этого освободятся ресурсы на реальную работу этого сторадж-кластера и при правильном включении и всенепременно на однопроцессорных платформах вы получите хорошую производительность по IOPSам и низкие задержки. Ну и естественно, максимум на что вы можете рассчитывать - 15 нод в кластере в одном PoD. Миграция данных между такими кластерами в общем случае должна быть холодная.
Причем, Linbit утверждает, дескать, можно делать HCI, если вы любите приключения. Вот только по-факту, кластерные службы вашего Linstor не понимают рядом стоящие кластерные службы вашей виртуализации, дерутся за ресурсы и не понимают границы буфером блочного и страничного кэширования, то есть RAM там вылетает в трубу.
Ceph - это сепх, все и так знают, что он медленный ломкий кластер. Он не даст вам I/O. И про RDMA забудьте. То что там по RDMA было, работало только через FUSE и так и не вышло до прода.
Ввиду технических ограничений кластерных планировщиков ресурсов (они криво связаны с ОС) рекомендуется ставить оба решения на однопроцессорные серверы и рассчитывать, что вся память и утилизация пойдет только для кластеризации стораджа. В противном случае вы горя хапнете в проде!
Причем редхат на полном серьёзе предоставляет HCI-решение с Ceph и бесстыдно пишет в документации такое:
https://docs.redhat.com/en/documentation/red_hat_openstack_p...
Ну то есть гвоздями прибивайте ресурсы между кластерами сверху. А если 2 проца в сервере, то собирайте сервер соответствующим способом, вешая диски только на один проц и разносите compute и storage на разные процессоры. Мрак. И да, RDMA в Ceph можно считать бессмысленным.
Ага, ага. Я разок попробовал, в рамках лабораторной работы. Не хватило... деньгов. Што? Да, для реализации шва6одкина решения даже в тестовой среде - не хватило денег. Потому что то железо и те лицензии которые были - такого не потянут. За roce, внезапно, надо платить.А у вмвари (пока!) почему-то работает. Наверное, особая магия. Нам, обитателям нижнего мира, недоступная.
> Хрустальный дворец под названием Linstor слишком хрустальный и не живет вне L2-домена, то есть годится как сторадж на один кластер. Проблема кроется в DRBD как протоколе репликации, который сложно пропихнуть через L3-сеть, соблюдая все необходимые QoS-ы в конвергентной сети (compute + storage).А что можете сказать по поводу vates и их xostor? Говорят они с linstor работали для своего хранилища.
Это Linstor с DRBD, интегрированный в XCP-NG и управляемый через Xen Orchestra.XOSTOR - это адаптация, которую Vates делал для себя совместно с Linbit с конкретными целями:
- Интегрировать с управляющим контуром
- Зафиксировать параметры кластера только на официально поддерживаемые. То есть вам помогут автоматикой правильно развернуть. Vates будет поддерживать ваше развертывание в рамках своих support-плановВажно понимать, что XOSTOR - это решение, которое умышленно ограничивает гибкость Linstor сводя его к так называемому "dHCI". Disagregated Hyperconverged Infrastructure - это подход в формировании инфраструктуры виртуализации, когда SDS подключается отдельно. То есть Compute-ноды с виртуальными машинами не имеют ни локальных дисков ни HBA. Storage-ноды подключаются по конвергентной сети тоже по DRBD к Compute. XOSTOR не поддерживает чистый HCI, когда кластерное хранилище утилизирует локальные диски на узлах виртуализации.
Это именно про то, что я писал выше. HCI с открытыми решениями не работает. Кластерные службы хранилища и кластерные службы виртуализации дерутся за ресурсы и не знают о существовании друг-друга. Чтобы избежать проблем с дракой за ресурсы и чтобы не тратить ресурсы своей техподдержки на изначально нерабочий, но теоретически возможный способ развертывания, Vates затребовал ставить Linstor всегда на отдельный кластер (как Ceph обычно ставится) интегрировал это с управляшками как на стороне Compute так и на стороне Storage и назвал это XOSTOR.
Просто считай, что XOSTOR - это тоже такой Linstor, но с минимальной защитой от дурака.
> Просто считай, что XOSTOR - это тоже такой Linstor, но с минимальной защитой от дурака.Тогда это неинтересно. То есть кроме vsan и возможно s2d вариантов то и нет??
Какое-то ты всё печальное рассказываешь. И как-то вариантов в будущем не видно.
не интересно, не умеет запускать OCI (докер) контейнеры
Он умел запускать контейнеры до того как всякие докеры появились. В те времена это был OpenVZ. Сейчас из контейнеров он умеет LXC, что ничуть не хуже докеров.
гораздо лучше
чкм лучше докеров то ?
Нестандартнон решение, можно так всё настроить, что побоятся уволить.
Не нужно страдать пробрасыванием всего и вся. Работаешь с контейнером как с обычной ОС.
Кто же эту пакость на хост-машине запускает?Так-то в инструкции к Proxmox VE прямым текстом сказано: "Cтрадаете докером - поднимите виртуалку, а в ней уже пускайте всякое разное".
только вот после примерно третьей виртуалки тебе надоест, наверное, закатывать солнце вручную.
А OKD/впопенштифт требует... ой, vmware.
Если честно, я вообще стараюсь докер не использовать. Сплошной головняк и никакого профита.
Но зачем тебе на локалхосте - proxmox?
На локалхосте он повторяет структуру рабочих кластеров на том же Proxmox'е :)Уж лучше я дома поэкспериментирую, нежели рабочий кластер из бэкапов подымать. Так-то, нифига сложного, просто долго и скучно.
Кстати, даже дома оно удобней, когда виртуалки (пара десятков) в Proxmox'е живут. Тупо удобней бэкапить и управлять всем этим хозяйством. Ну, а сам Proxmox (3 ноды и бэкап-сервер) в virt-manager'е живёт. Благо, дома от этих виртуалок суперскоростей не требуется.
> Proxmox (3 ноды и бэкап-сервер) в virt-manager'е живёт. Благо, дома от
> этих виртуалок суперскоростей не требуется.месье понимает толк в извращениях, я смотрю...
> Proxmox (3 ноды и бэкап-сервер) в virt-manager'е живёт.как ??
т.е. proxmox и backup server - это виртуальные машины на локалхосте ??
>> Proxmox (3 ноды и бэкап-сервер) в virt-manager'е живёт.
> как ??
> т.е. proxmox и backup server - это виртуальные машины на локалхосте ??А чего бы и нет?
Во-первых, настройки легко отрабатываются и проверяются на виртуальном кластере без угрозы для настоящего рабочего кластера.
Во-вторых, сам виртуальный кластер тоже снапшотится периодически. Восстановить - пара кликов мышкой. Хоть весь оптом, хоть конкретную ноду или бэкап-сервер.
В-третьих, когда виртуалок домашних много, то в virt-manager'е уже весьма хреново с ними работать. А проксмокс - это проксмокс :)Да nested virtualisation, но ведь работает, причём весьма шустро.
И кушает относительно немного - процентов 40-50 от 128 гигов оперативки и проца процентов 10, всё остальное мне для просмотра ютубов :)
Отрадно видеть как любимый проект развивается. 7 лет в продакшене и всем рекомендую
7 лет не обновлялись?
Сколько кластеров и нод?
Вы бы ещё возраст у девушки спросили
> Вы бы ещё возраст у девушки спросилиСпрашиваю - отвечают. А это секрет?
ты б бороду седую что-ли куда-нибудь под шарф спрятал...
4 кластера, от 6 до 15 нод в каждом. Полет нормальный.
Обновился штатно без замечаний.
Если бы incus/lxd не попробовал, с удовольствием сидел бы на проксмоксе
И чем incus/lxd примечателен? Чем оно лучше proxmox/lxc?
для локалхоста - в разы проще.
Как обновиться на боевом серваке с версии 8.2 на 8.3? Я только недавно поставил 8.2 и апгрейд ещё не делал ни разу.
нонахрена?!
Чтобы быть на острие атаки.
> Чтобы быть на острие атаки.да просто забери чужие 15 тыщ забытые у банкомата - и вот тебе шторм-зю в 77 лет!
"штош вы так убиваетесь?! Вы ж так никогда не убьетесь!"
apt update && apt upgrade -y && reboot
> apt update && apt upgrade -y && rebootapt dist-upgrade
Или
apt full-upgrade
apt update && apt upgrade -y && reboot
> apt update && apt upgrade -y && reboot1 раза не достаточно для обновления? =)
> Как обновиться на боевом серваке с версии 8.2 на 8.3? Я только
> недавно поставил 8.2 и апгрейд ещё не делал ни разу.Там есть кнопочка в соответствующем разделе вебморды управления.
Тут кто-нибудь может мне прояснить, весь функционал OMV позволяет отказаться от Proxmox?
на твоем локалхосте - почти наверняка, да.proxmox претендует немножко не на васянские подкроватные сервера. (претендует - !=, увы, подходит для. "но они хотя бы попытались")
Ой да ладно тебе, если нужно без лишних приседаний дать разрабам песочницу с вмками и селф-сервисом то вполне себе подходит. У меня джун к сабжу написал простую морду с четырьмя кнопками, весь отдел разработки кипятком писяет так удобно. Нужна виртуалка (или десять) навыброс — клац! и через пять минут явки-пароли в почте. А в ночь с пятницы на воскресенье костыль на баше сносит всё что старше двух недель. А в проде такое конечно не поставишь, ну так кроме прода есть масса других мест, где лишние деньги тратить нерационально, а за $0.0 проксмокс вполне сойдёт.
> Ой да ладно тебе, если нужно без лишних приседаний дать разрабам песочницу с вмками и
> селф-сервисом то вполне себе подходит.во-первых - э... а им - нахрена вот?! 8-O Они что с теми вмками делать-то умеют кроме rm -rf (и то неточно)?
во-вторых - а железо для всего этого, чё, бесплатное, вообще?
Так-то я бы мог им подобное выдать в рамках текущей инфры (делов-то на пару дней, в вмвари такое запилить пусть даже наколенным способом, без покупки правильных решений), но нет деньгов.
Своё железо в масштабах контура разработки - дешевле и гибче.
Для разработки как правило нужно много разных сервисов и небольших виртуалок, и их масштабирование. Вполне себе задача, которую админу нужно решать.
> Своё железо в масштабах контура разработки - дешевле и гибче.с чего оно дешевле и с чего гибче чем выделение ресурсов из общего пула? Тем более что разработчики обычно не собираются это все администрировать. И тем более - не умеют.
> Для разработки как правило нужно много разных сервисов и небольших виртуалок,
и кто обещал что они всегда будут небольшие? Завтра тебе принесут требование срочно-срочно-вчера запилить хрень на половину мощности выделенного сервера. С перспективой сожрать еще столько же послезавтра. И горе тебе если ты не ограничил эту возможность автоматикой.
> Вполне себе задача, которую админу нужно решать.
обычная задача которую решает неудачник-админ поставленный сторожить такие вот поделки разработчиков с полным доступом ко всему включая управление самой виртуализацией - "вы нам все сломали и мы теперь не можем попасть на свою (хорошо еще не "все свои") виртуалочку, немедленно починить!" Не знаю где ты взял каких-то других разработчиков.
Собственно, я такое наблюдаю примерно пару раз в месяц, но поскольку у нас разработчики лишены возможности чем-то сложным поуправлять, то за пределы их контейнера оно обычно не выбирается.
(и когда показываешь такому "все сломали" его же собственный .bash_history - чорта с два он извинится. Обычно просто пропадает со связи. До следующего всесломали.)
Да вообще знают зачем виртуалка нужна, но четвёртая кнопка как раз чтобы сразу кубернетес кубернетил. Железо понятно не бесплатное, досталось вместе с продуктом купленной конторы. Продукт интегрировали в нашу платформу, а железо отдали под R&D до списания, там три стойки всего с торами, два свича и роутер, в датацентре где-то в Аризоне, далеко от основной инфры. Денег на лицензии туда точно никто не даст, так что самое то проксмокс ставить, lxd разворачивать, с опенстаком играться. Чем бы джуны ни тешились, лишь бы прод не трогали.
А , ну вот в таком виде - на те, боже, что нам не гоже - сойдеть, да.Тем более что халявный esxi (который вроде бы как раз можно в такой позе) запретили, да и управлять им неудобно без нехалявного контроллера.
(но что они не попросят однажды все вот такое вот вместе с виртуализацией завернуть и 1:1 на прод перенести "патамушта только так оно работаит" - это можно делать ставки)
Что-то они там "перепатчили" в своем проксобубунто ядре. У меня вылез странный баг с ведром 6.8.12-4-pve. С некоторых внешних ресурсов сам прокс почему-то качает со скоростью 200-300 KB/s. Банальный "wget https://cdimage.debian.org/cdimage/release/12.8.0/amd64/iso-....Перезагружаешься обратно с ядром 6.8.8-4-pve и эта же команда тащит файл на полной скорости тарифа.
Несколько раз загружался, то с ядром 6.8.12, то с 6.8.8. На 6.8.12 загрузка стабильно тупит. Сетевухи Intel x520-da2.
В выходные лень копать, что это за подземный стук. Пока остаюсь на ядре 6.8.8-4-pve.
на 7-ми нодах все ок, а на одной тупо рандомный кернел паник с высером на сетевуху интел, тоже пришлось откатить ядро
> Что-то они там "перепатчили" в своем проксобубунто ядре. У меня вылез странныйну как бы 6.8.12 и 6.8.8 намекает нам, что не они.
Вероятней интел что-то поулучшал в драйвере.
> Сетевухи Intel x520-da2У вас проблема не в Linux/Proxmox, а в этом оборудовании. Его нужно заменить.
Я не знаю, откуда у людей в рускоговорящем сегменте интернета берется это поверие, будто сетевые карты у Intel хорошие. Просто знайте, что это не так! Я бы сказал, что это второй по забагованности вендор.
Есть несколько сетевых адаптеров, которые вы НИКОГДА не хотите поставить в продакшен на сервер виртуализации. При этом не имеет значение, какая у вас виртуализация!!!
1. Broadcom - это пример того как не надо делать сетевые карты. Broadcom свои драйверы никогда не обновлял нормально нигде. Не адаптировал под новые версии ядра и сетевого стека ни в одной ОС. Они просто сетевки новые клепали. Примечательно, что даже новейшие сетевые адаптеры имеют проблемы как в RHEL, Debian так и на Windows с разными типами разгрузок (offload). Старые могут просто не работать, вызывать панику, терять пакеты. Эти сетевки нельзя использовать нигде в сервере.
2. Intel - причем особенно это касается 200, 500 и 700. Выкиньте их. Их драйверы застряли в 2010-ом году. Они сейчас запрещены для Compute-нагрузок и в Windows и в VMware в Linux начали ломаться только сейчас. Каждый раз когда у Intel начинаются проблемы с любой подсистемой, они выпиливают фичу из драйвера. Новые сетевки такие же убогие.
3. QLogic - сняты с производства, драйверы устарели, большая часть фич не работает в современных ОС.
4. Cavium - это то во что превратился QLogic, сняты с производства, драйверы устарели, большая часть фич пока работает.
5. Emulex - у этих сетевых адаптеров не достаточное количество аппаратных очередей для работы инфраструктуры виртуализации. Они годятся толко чтобы iSCSI на сервер подать. Нельзя их подключать ни к какой реализации виртуального коммутатора. Это в вотчине Broadcom, опять.
6. LSI - то же самое, что Emulex, только драйверы протухли. И опять Broadcom.
Сейчас вы можете без проблем использовать двух вендоров для любых задач:
- NVIDIA/Mellanox - прекрасные открытые драйверы, очень надёжные адаптеры. Там RoCE (это плюс) и прекрасно работает DCB. Также есть поддержка полной разгрузки виртуального коммутатора на ASIC.
- Chelsio - прекрасные открытые драйверы, очень надёжные адаптеры. Там iWarp (это минус), но зато есть поддержка разгрузки TLS (снять из kTLS на ASIC некоторые шифры) и есть поддержка ODX для разгрузки iSCSI. Также есть поддержка полной разгрузки виртуального коммутатора на ASIC.
Оба вендора хороши и очень надёжны на все ОС.Есть еще современные сетевки Marvel, это то, во что превратился QLogic и затем Cavium, но их я вообще в руках не держал. Не могу сказать, хорошие они или плохие.
TL;DR Купите Mellanox или Chelsio. Intel нельзя исправить, только выбросить. И дело не в Linux/Proxmox такая же проблема и на Windows Server 2019+ и на ESXi 7+. И это никто не будет исправлять.
> такая же проблема и на Windows Server 2019+ и на ESXi 7+заметьте - в 16й и в 6.5 (и наверное даже в 6.7) ничем не воняет. На тех же самых 500х
Что не исправят - это, конечно, верю.И да, похоже про sr-iov можно начать забывать.