Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз Proxmox VE 8.3, дистрибутива для организации работы виртуальных серверов"	+/–
Сообщение от opennews (??), 22-Ноя-24, 00:17
Опубликован релиз Proxmox Virtual Environment 8.3, специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таких продуктов, как VMware vSphere, Microsoft Hyper-V и Citrix Hypervisor. Размер установочного iso-образа 1.4 ГБ... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62273
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 22-Ноя-24, 00:17	–10 +/–
не интересно, не умеет запускать OCI (докер) контейнеры
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #14

5. Сообщение от Аноним (5), 22-Ноя-24, 02:56	+13 +/–
Отрадно видеть как любимый проект развивается. 7 лет в продакшене и всем рекомендую
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #10

7. Сообщение от Аноним (7), 22-Ноя-24, 06:50	+10 +/–
Он умел запускать контейнеры до того как всякие докеры появились. В те времена это был OpenVZ. Сейчас из контейнеров он умеет LXC, что ничуть не хуже докеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #8

8. Сообщение от Аноним (8), 22-Ноя-24, 07:18	+5 +/–
гораздо лучше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #32

9. Сообщение от Аноним (8), 22-Ноя-24, 07:18	+1 +/–
7 лет не обновлялись?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

10. Сообщение от Минона (ok), 22-Ноя-24, 07:48	+/–
Сколько кластеров и нод?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #45, #54

11. Сообщение от Аноним (11), 22-Ноя-24, 08:22	+/–
Обновился штатно без замечаний.
Ответить | Правка | Наверх | Cообщить модератору

13. Сообщение от Аноним (13), 22-Ноя-24, 09:16	+5 +/–
> более плотная интеграция стека для создания программно определяемых сетей (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. Это будет работать, но это не достаточно гибко. Управление гиперкластером, опять же... тоже дырка в голову. В общем, телеком и сервис-провайдеры его обычно не ставят.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #25

14. Сообщение от dalco (ok), 22-Ноя-24, 09:17	+2 +/–
Кто же эту пакость на хост-машине запускает? Так-то в инструкции к Proxmox VE прямым текстом сказано: "Cтрадаете докером - поднимите виртуалку, а в ней уже пускайте всякое разное".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #17

15. Сообщение от WE (?), 22-Ноя-24, 09:28	+1 +/–
Всё так. PVE называют виртуализацией для домохозяек, это не облачное решение провайдера услуг, это именно оркестрация виртуальных машин (ну и LXD). Хорошо подходит для развёртывание VMок, без дополнительных требований, чего многим достаточно. Если исходить из требований провайдера облачных услуг, начинать надо с установки хотябы OpenNebula, но всё одно путь будет к OpenStack.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #41

16. Сообщение от manchelsi (ok), 22-Ноя-24, 10:39	+/–
Если бы incus/lxd не попробовал, с удовольствием сидел бы на проксмоксе
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

17. Сообщение от нах. (?), 22-Ноя-24, 13:56	+2 +/–
только вот после примерно третьей виртуалки тебе надоест, наверное, закатывать солнце вручную. А OKD/впопенштифт требует... ой, vmware.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #20

18. Сообщение от Аноним (-), 22-Ноя-24, 15:30	+/–
Как обновиться на боевом серваке с версии 8.2 на 8.3? Я только недавно поставил 8.2 и апгрейд ещё не делал ни разу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #33, #34, #38

19. Сообщение от Аноним (-), 22-Ноя-24, 15:33	+1 +/–
И чем incus/lxd примечателен? Чем оно лучше proxmox/lxc?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #53

20. Сообщение от dalco (ok), 22-Ноя-24, 17:04	+2 +/–
Если честно, я вообще стараюсь докер не использовать. Сплошной головняк и никакого профита.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #22

21. Сообщение от анон (?), 22-Ноя-24, 17:26	+/–
Тут кто-нибудь может мне прояснить, весь функционал OMV позволяет отказаться от Proxmox?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

22. Сообщение от нах. (?), 22-Ноя-24, 17:32	+/–
Но зачем тебе на локалхосте - proxmox?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #27

23. Сообщение от нах. (?), 22-Ноя-24, 17:32	+1 +/–
нонахрена?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26

24. Сообщение от нах. (?), 22-Ноя-24, 17:33	+/–
на твоем локалхосте - почти наверняка, да. proxmox претендует немножко не на васянские подкроватные сервера. (претендует - !=, увы, подходит для. "но они хотя бы попытались")
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #30

25. Сообщение от нах. (?), 22-Ноя-24, 17:37	–2 +/–
> SDN в Proxmox - это страшный долгострой и один из главных блокеров для больших внедрений у > Proxmox. А с SDS конечно все замечательно, ога! Вон аж ТРИ разношерстных версии одного и того же (а говорили - ничему не учатся! Тот опыт "автоапгрейда" у чуваков с редита явно имел большой успех у клиентов.) Другого SDS нахаляву, то ись, даром - у меня для вас нет. Ой, простите. У rhbm для вас нет. А поляки не потянули.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #50

26. Сообщение от Аноним (-), 22-Ноя-24, 17:42	+1 +/–
Чтобы быть на острие атаки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #28

27. Сообщение от dalco (ok), 22-Ноя-24, 17:55	+/–
На локалхосте он повторяет структуру рабочих кластеров на том же Proxmox'е :) Уж лучше я дома поэкспериментирую, нежели рабочий кластер из бэкапов подымать. Так-то, нифига сложного, просто долго и скучно. Кстати, даже дома оно удобней, когда виртуалки (пара десятков) в Proxmox'е живут. Тупо удобней бэкапить и управлять всем этим хозяйством. Ну, а сам Proxmox (3 ноды и бэкап-сервер) в virt-manager'е живёт. Благо, дома от этих виртуалок суперскоростей не требуется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #29, #55

28. Сообщение от нах. (?), 22-Ноя-24, 17:57	–1 +/–
> Чтобы быть на острие атаки. да просто забери чужие 15 тыщ забытые у банкомата - и вот тебе шторм-зю в 77 лет! "штош вы так убиваетесь?! Вы  ж так никогда не убьетесь!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

29. Сообщение от нах. (?), 22-Ноя-24, 18:04	–2 +/–
> Proxmox (3 ноды и бэкап-сервер) в virt-manager'е живёт. Благо, дома от > этих виртуалок суперскоростей не требуется. месье понимает толк в извращениях, я смотрю...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

30. Сообщение от Аноним (40), 22-Ноя-24, 18:04	–1 +/–
Ой да ладно тебе, если нужно без лишних приседаний дать разрабам песочницу с вмками и селф-сервисом то вполне себе подходит. У меня джун к сабжу написал простую морду с четырьмя кнопками, весь отдел разработки кипятком писяет так удобно. Нужна виртуалка (или десять) навыброс — клац! и через пять минут явки-пароли в почте. А в ночь с пятницы на воскресенье костыль на баше сносит всё что старше двух недель. А в проде такое конечно не поставишь, ну так кроме прода есть масса других мест, где лишние деньги тратить нерационально, а за $0.0 проксмокс вполне сойдёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #31

31. Сообщение от нах. (?), 22-Ноя-24, 18:09	+/–
> Ой да ладно тебе, если нужно без лишних приседаний дать разрабам песочницу с вмками и > селф-сервисом то вполне себе подходит. во-первых - э... а им - нахрена вот?! 8-O Они что с теми вмками делать-то умеют кроме rm -rf (и то неточно)? во-вторых - а железо для всего этого, чё, бесплатное, вообще? Так-то я бы мог им подобное выдать в рамках текущей инфры (делов-то на пару дней, в вмвари такое запилить пусть даже наколенным способом, без покупки правильных решений), но нет деньгов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #35, #42

32. Сообщение от ilya (??), 22-Ноя-24, 20:26	+/–
чкм лучше докеров то ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #40, #43

33. Сообщение от ilya (??), 22-Ноя-24, 20:30	–1 +/–
apt update && apt upgrade -y  &&  reboot
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #36

34. Сообщение от ilya (??), 22-Ноя-24, 20:31	–1 +/–
apt update && apt upgrade -y  &&  reboot
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #37

35. Сообщение от анонимус (??), 22-Ноя-24, 20:47	+/–
Своё железо в масштабах контура разработки - дешевле и гибче. Для разработки как правило нужно много разных сервисов и небольших виртуалок, и их масштабирование. Вполне себе задача, которую админу нужно решать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #39

36. Сообщение от 1 (??), 22-Ноя-24, 21:46	+/–
> apt update && apt upgrade -y  &&  reboot apt dist-upgrade Или apt full-upgrade
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

37. Сообщение от 1 (??), 22-Ноя-24, 21:47	+/–
> apt update && apt upgrade -y  &&  reboot 1 раза не достаточно для обновления? =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

38. Сообщение от 1 (??), 22-Ноя-24, 21:49	+/–
> Как обновиться на боевом серваке с версии 8.2 на 8.3? Я только > недавно поставил 8.2 и апгрейд ещё не делал ни разу. Там есть кнопочка в соответствующем разделе вебморды управления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

39. Сообщение от нах. (?), 22-Ноя-24, 23:40	+1 +/–
> Своё железо в масштабах контура разработки - дешевле и гибче. с чего оно дешевле и с чего гибче чем выделение ресурсов из общего пула? Тем более что разработчики обычно не собираются это все администрировать. И тем более - не умеют. > Для разработки как правило нужно много разных сервисов и небольших виртуалок, и кто обещал что они всегда будут небольшие? Завтра тебе принесут требование срочно-срочно-вчера запилить хрень на половину мощности выделенного сервера. С перспективой сожрать еще столько же послезавтра. И горе тебе если ты не ограничил эту возможность автоматикой. > Вполне себе задача, которую админу нужно решать. обычная задача которую решает неудачник-админ поставленный сторожить такие вот поделки разработчиков с полным доступом ко всему включая управление самой виртуализацией - "вы нам все сломали и мы теперь не можем попасть на свою (хорошо еще не "все свои") виртуалочку, немедленно починить!" Не знаю где ты взял каких-то других разработчиков. Собственно, я такое наблюдаю примерно пару раз в месяц, но поскольку у нас разработчики лишены возможности чем-то сложным поуправлять, то за пределы их контейнера оно обычно не выбирается. (и когда показываешь такому "все сломали" его же собственный .bash_history - чорта с два он извинится. Обычно просто пропадает со связи. До следующего всесломали.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

40. Сообщение от Аноним (40), 22-Ноя-24, 23:59	+/–
Нестандартнон решение, можно так всё настроить, что побоятся уволить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

41. Сообщение от Аноним (41), 23-Ноя-24, 00:01	+/–
А для домохозяек есть incus/lxd со своим WebUI Ставится на обычную Ubuntu, без необходимости ставить специальный дистр и прекрасно дает виртуалки и контейнеры(lxc), пашет хоть на amd64, хоть на arm64, жрать не просит(а Proxmox просит, буквально просит, в смысле, что либо ты альфа-тестер, либо платишь им подписку) По сути вот уже лет 10-12 Proxmox это альтернатива XCP, такая себе нишевая вещь для маленьких инсталяций, для контор с парой-тройкой-десятком серверов, где нет нужды разворачивать OpenStack
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

42. Сообщение от Аноним (40), 23-Ноя-24, 00:56	+/–
Да вообще знают зачем виртуалка нужна, но четвёртая кнопка как раз чтобы сразу кубернетес кубернетил. Железо понятно не бесплатное, досталось вместе с продуктом купленной конторы. Продукт интегрировали в нашу платформу, а железо отдали под R&D до списания, там три стойки всего с торами, два свича и роутер, в датацентре где-то в Аризоне, далеко от основной инфры. Денег на лицензии туда  точно никто не даст, так что самое то проксмокс ставить, lxd разворачивать, с опенстаком играться. Чем бы джуны ни тешились, лишь бы прод не трогали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #47

43. Сообщение от Анониссимус (?), 23-Ноя-24, 01:43	–1 +/–
Не нужно страдать пробрасыванием всего и вся. Работаешь с контейнером как с обычной ОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

44. Сообщение от Аноним (44), 23-Ноя-24, 05:45	+/–
Что-то они там "перепатчили" в своем проксобубунто ядре. У меня вылез странный баг с ведром 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.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46, #48, #56

45. Сообщение от nume (ok), 23-Ноя-24, 10:15	+4 +/–
Вы бы ещё возраст у девушки спросили
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #49

46. Сообщение от adm (??), 23-Ноя-24, 17:42	+/–
на 7-ми нодах все ок, а на одной тупо рандомный кернел паник с высером на сетевуху интел, тоже пришлось откатить ядро
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от нах. (?), 24-Ноя-24, 14:05	+/–
А , ну вот в таком виде - на те, боже, что нам не гоже - сойдеть, да. Тем более что халявный esxi (который вроде бы как раз можно в такой позе) запретили, да и управлять им неудобно без нехалявного контроллера. (но что они не попросят однажды все вот такое вот вместе с виртуализацией завернуть и 1:1 на прод перенести "патамушта только так оно работаит" - это можно делать ставки)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

48. Сообщение от нах. (?), 24-Ноя-24, 14:07	+/–
> Что-то они там "перепатчили" в своем проксобубунто ядре. У меня вылез странный ну как бы 6.8.12 и 6.8.8 намекает нам, что не они. Вероятней интел что-то поулучшал в драйвере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

49. Сообщение от Минона (ok), 24-Ноя-24, 21:41	+/–
> Вы бы ещё возраст у девушки спросили Спрашиваю - отвечают. А это секрет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #52

50. Сообщение от Аноним (13), 25-Ноя-24, 09:39	+1 +/–
Всё правильно, вас зря минусуют. Скорее всего, вы в курсе про всё это, но всё равно напишу... Я тоже не видел сколько-нибудь быстрого открытого 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 можно считать бессмысленным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #51, #58

51. Сообщение от нах. (?), 25-Ноя-24, 17:14	+/–
Ага, ага. Я разок попробовал, в рамках лабораторной работы. Не хватило... деньгов. Што? Да, для реализации шва6одкина решения даже в тестовой среде - не хватило денег. Потому что то железо и те лицензии которые были - такого не потянут. За roce, внезапно, надо платить. А у вмвари (пока!) почему-то работает. Наверное, особая магия. Нам, обитателям нижнего мира, недоступная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

52. Сообщение от нах. (?), 25-Ноя-24, 17:15	+/–
ты б бороду седую что-ли куда-нибудь под шарф спрятал...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

53. Сообщение от нах. (?), 25-Ноя-24, 17:16	+/–
для локалхоста - в разы проще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

54. Сообщение от SubGun (ok), 26-Ноя-24, 10:46	+1 +/–
4 кластера, от 6 до 15 нод в каждом. Полет нормальный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

55. Сообщение от t (??), 26-Ноя-24, 12:38	+/–
> Proxmox (3 ноды и бэкап-сервер) в virt-manager'е живёт. как ?? т.е. proxmox и backup server - это виртуальные машины на локалхосте ??
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #59

56. Сообщение от Аноним (13), 26-Ноя-24, 14:04	+/–
> Сетевухи 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+. И это никто не будет исправлять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #57

57. Сообщение от пох. (?), 26-Ноя-24, 16:31	+/–
> такая же проблема и на Windows Server 2019+ и на ESXi 7+ заметьте - в 16й и в 6.5 (и наверное даже в 6.7) ничем не воняет. На тех же самых 500х Что не исправят - это, конечно, верю. И да, похоже про sr-iov можно начать забывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

58. Сообщение от Аноним (58), 26-Ноя-24, 17:03	+/–
> Хрустальный дворец под названием Linstor слишком хрустальный и не живет вне L2-домена, то есть годится как сторадж на один кластер. Проблема кроется в DRBD как протоколе репликации, который сложно пропихнуть через L3-сеть, соблюдая все необходимые QoS-ы в конвергентной сети (compute + storage). А что можете сказать по поводу vates и их xostor? Говорят они с linstor работали для своего хранилища.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #60

59. Сообщение от dalco (ok), 26-Ноя-24, 17:29	+/–
>> Proxmox (3 ноды и бэкап-сервер) в virt-manager'е живёт. > как ?? > т.е. proxmox и backup server - это виртуальные машины на локалхосте ?? А чего бы и нет? Во-первых, настройки легко отрабатываются и проверяются на виртуальном кластере без угрозы для настоящего рабочего кластера. Во-вторых, сам виртуальный кластер тоже снапшотится периодически. Восстановить - пара кликов мышкой. Хоть весь оптом, хоть конкретную ноду или бэкап-сервер. В-третьих, когда виртуалок домашних много, то в virt-manager'е уже весьма хреново с ними работать. А проксмокс - это проксмокс :) Да nested virtualisation, но ведь работает, причём весьма шустро. И кушает относительно немного - процентов 40-50 от 128 гигов оперативки и проца процентов 10, всё остальное мне для просмотра ютубов :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

60. Сообщение от Аноним (13), 27-Ноя-24, 10:26	+/–
Это 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, но с минимальной защитой от дурака.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #61

61. Сообщение от Аноним (58), 28-Ноя-24, 08:05	+/–
> Просто считай, что XOSTOR - это тоже такой Linstor, но с минимальной защитой от дурака. Тогда это неинтересно. То есть кроме vsan и возможно s2d вариантов то и нет?? Какое-то ты всё печальное рассказываешь. И как-то вариантов в будущем не видно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема