LINUX.ORG.RU

Собираю Proxmox сервер для дома

 , ,


0

1

Здарова народ!

Хочу отделить storage и compute как говориться, пусть данные живут в NAS и всякие эксперименты пусть будут в Proxmox.

Так как квартира не резиновая, здоровенный корпус не хочется ставить. Хочется mATX. Ну и цена на озу печальная. Дешевле выходит DDR4.

А еще хотелка 50/100gbe NIC использовать чтобы играться с утилизацией железа под нагрузкой.

Собственно вопрос, какое железо выбрать, вариантов два:

Intel i5 на 1700 сокете, есть энергоэффективные ядра, поддерживает транскодинг - Jellyfin сможет спокойно работать.

AMD Ryzen 5 AM4 - есть относительно дешевые 8 ядерники, Jellyfin не запустить без дискретке или G проца, в остальном вроде бы те же яйца только вид с боку.

Денег за связку мать + проц много отдавать не хочется, хочется остаться не менее чем на 8 ядрах. Ну и железо чтобы не было старым зионом.

Что посоветуете?

p.s. Список того, что хочу крутить на Proxmox:

  • Elastic Search или Open Search
  • Elastic APM или Open Telemetry
  • Meilisearch
  • PostgreSQL
  • ClickHouse
  • MongoDB
  • MariaDB
  • Redis
  • Cassandra
  • CockroachDB
  • Kafka
  • MiniIO
  • Vaeltwerden
  • KeyCloack
  • Gitea + k3s + runners
  • Authentic
  • ARR-стек
  • qBitTorrent

Ну и так всякое по мелочи

UPD: Бюджетный вариант

AM4 + 5700G - связка выходит около 20к рублей, туда же идет более дешевая DDR4 (25к за 64гб) видимо на этом и остановлюсь

★★★★

Последнее исправление: AntonyRF (всего исправлений: 1)

Привет, условно рекомендуемым является правило с сайта openstack: на 1 ядро один 1 Гб ОЗУ; плюс смотри минимальные системные требования, например Debian.

Итого в остатке, у тебя теоретически максимально 8 «полноценных» виртуалок, на которых (речь про Debian) ~25% ресурсов ОЗУ потреблять будет ОС самого гостя.

Даже если ОЗУ сделаешь до условных 64 Гб, то упрешься в 8 ядер.

В любом случае, твой проект определяет цена и изначально это эксперимент: если сомневаешься, то посмотри на профильных форумах и потом покупай.

В целом, рекомендую озаботится не очевидным вопросом: по факту, если продуктивности твоей конфигурации хватит на все ОЗУ И ЦПУ, то не стоит забывать про пропускную способность дисковой подсистемы. Например, встроенный SATA, не смотря на 4-6-8 физических портов обычно работает на 1x pci-e; что так же справедливо и к встроенной сетевой карте.

anonymous
()
Ответ на: комментарий от hippi90

zram, zswap сколько-то спасёт… По идее такие вещи начинают потреблять из-за «закешировать все». Есть в конфигах не сможет исправить, то cgroups поизучает)

anonymous
()
Ответ на: комментарий от NyXzOr

Вот поэтому и акцентировал, что это эксперимент: он явно написал, что хочет и «стек ПО» и «нагрузки на hardware». По сути, у него вопрос больше звучит таким образом: у меня нет возможности взять максимальную комплектацию, что бы понять насколько это продуктивно. Пожалуйста, подскажите номиналы от которых я смогу оттолкнуться в решении и по ситуации принимать решение о продолжении исследований в конкретном направлении.

anonymous
()
Ответ на: комментарий от hippi90

Он там Clickhouse собрался крутить, эта хрень оперативку жрет как не в себя, ей и 64 будет мало.

Дома? У меня под кроватью ClickHouse живет — жрет сотни мегабайт. Храню что-то близкое к timeseries, 116M записей, 5Gb на диске.

urxvt ★★★★★
()
Ответ на: комментарий от Byers

https://github.com/OpenNebula/docs/blob/master/source/management_and_operations/guest_os/windows_best_practice.rst#numa

Могу специально поискать, таких глупостей. Я ж не из головы это все беру: все предельно просто, как пишет рекомендацию разработчик, так и дублирую.

anonymous
()
Ответ на: комментарий от manntes-live

Домашний комп на 7950х, возможно по текущему конфигу второй сервер соберу, буду из всех своих железок делать оркестрацию какую-то. В общем это больше для экспериментов и тестов. А не постоянная нагрузка

AntonyRF ★★★★
() автор топика
Ответ на: комментарий от anonymous

Там написано про распределение ядер проца и про hugepages, где действительно страницы от 1Гб или больше дают некоторый буст виртуалкам. Ни слова про «на 1 ядро один 1 Гб ОЗУ» :)

Byers
()

Хотелки на полстраницы, а в требованиях как можно дешевле. Ну куда ты лезешь, если тебе все дорого? Купи малинку себе и не парь людям мозги.

anonymous
()
Ответ на: комментарий от Byers

https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement#Dedicated_resource

Естественно, что документацию переписывают со временем. Но давай включим ллллогику: однозначно пол ядра использовать никто не будет. Ок

1 Ядро у нас всегда.

Давай включим ллллогику дальше, если пойти от противного и не читать документацию, то libvirt отчего вдруг для неизвестной ос такие значения даёт?

<domain type="kvm">
  <name>vm1</name>
  <uuid>-------</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>1</vcpu>
  <os firmware="efi">
    <type arch="x86_64" machine="pc-i440fx-10.2">hvm</type>
    <boot dev="hd"/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state="off"/>
  </features>
  <cpu mode="host-passthrough"/>
  <clock offset="utc">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
  </clock>
  <pm>
    <suspend-to-mem enabled="no"/>
    <suspend-to-disk enabled="no"/>
  </pm>

Повторюсь, что когда читал, то четко запомнил расчёт что на 1 ядро брать 1 Гб ОЗУ. Это к тому, что есть условно рекоммендательная методика расчёта. Сейчас многое что могло измениться. Правильный вопрос это половина ответа: на предъявы, в следующий раз, отвечать не собираюсь.

anonymous
()
Ответ на: комментарий от AntonyRF

Угу, еще вилку удлинителя включи в сам удлинитель и получишь Perpetuum mobile.

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

anonymous
()
Ответ на: комментарий от AntonyRF

А если оставить только корпус и не включать в электросеть: вообще Profit!

Могу предложить даже туда хомячка с динамомашинкой посадить для генерации электроэнергии «обратно»: вообще нобелевку дадут!

anonymous
()
Ответ на: комментарий от anonymous

Повторюсь, что когда читал, то четко запомнил расчёт что на 1 ядро брать 1 Гб ОЗУ

Ну когда читаешь про размер страницы памяти, а запоминаешь про объём ОЗУ на ядро, то есть два хороших совета: 1. Подтянуть английский 2. Понять технологии выделения памяти в линуксе.

И тогда не придётся писать постыдные глупости от анонимуса. Загадка почему модераторы не фильтруют эти бредни.

Byers
()
Ответ на: комментарий от Byers

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

anonymous
()
Ответ на: комментарий от AntonyRF

не подскажу, фильтровал по сокету, году и сериям. «по диагонали». почему посчитал не плохим, т.к. теплопакет приемлемый. В любом случае, решение принимать Вам. Про сетевушку/дисковую подсистему не забывайте, что могут стать бутылочным горлышком.

anonymous
()

На всякий пожарный:

https://libvirt.org/kbase/kvm-realtime.html

Учитывая что libvirt, очень вероятно, что openstack/opennebula там раздел про выделение и резервирование ресурсов будет +- с таким же контекстом.

** тот процессор 8 железных по 2 потока.

anonymous
()
Ответ на: комментарий от anonymous

Опять же, если хорошо покопаться в доках на дистрибутивы, то +- выкладки одни и те же дают.

https://documentation.suse.com/sles/15-SP7/html/SLES-all/article-virtualization-best-practices.html#sec-vt-best-hostlevel

уверен, что Вы на proxmox искали, поэтому смотрел везде кроме proxmox

anonymous
()
Ответ на: комментарий от anonymous

открывать глаза по шире и читать не отдельными абзацами

Вот и открой глаза и покажи где в твоей портянке написано «1Гб ОЗУ на 1 ядро»

понимания контекста

Раскрой контекст :)

Byers
()
Ответ на: комментарий от Byers

https://libvirt.org/kbase/kvm-realtime.html#memory-configuration

Не моргая глазками, возвращайся к началу страницы документации и вдумчиво читай до конца. Видимо у Вас непереносимость меня, а разжевывать ответы на явные передергивания желания нет. Т.к. ничего кроме прилагательных в мой адрес на ответы с конкретными выкладками не прочитал. Так что свои капризки устраивайте другим.

anonymous
()
Ответ на: комментарий от anonymous

Не моргая глазками, возвращайся к началу страницы документации и вдумчиво читай до конца.

Скриншот абзаца где написано про «1Гб на 1 ядро» будьте любезны предоставить. То что ты не понимаешь что такое hugepages было очевидно выше по треду, но продолжаешь феерично позорится :)

Видимо у Вас непереносимость меня

Непереносимость безграмотности помноженный на упоротость.

Byers
()
Ответ на: комментарий от Byers

Раз что то лично мне так хочите доказать, в эту игру можно играть в двоем: для данного ТЗ у ТС, какую методику будете применять и исходя из чего?

anonymous
()
Ответ на: комментарий от anonymous

Уважаемый, спешу приоткрыть тайну завесы, что в <cpu> существует не только параметр mode, но и топология, которая опирается на значения <vcpu>. Вот Вам вырезка примера одной из моих конфигураций

------------------------
<vcpu placement='static'>4</vcpu>
  ----------------------
  <cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' clusters='1' cores='2' threads='2'/>
  </cpu>
------------------------
Dodik
()
Последнее исправление: Dodik (всего исправлений: 1)
Ответ на: комментарий от Dodik

С хоста типовой кусок конфига сдернул.

Речь о том, что NUMA в н.в. считается 1 сокет ядра, причём на 1 ядро предпологается hugetable в 1Гб: отсюда и идёт на generic 2 ядра 2 Гб ОЗУ, а на other OS 1 ядро ОЗУ 1 Гб.

В целом вся история как упряждение на overcommit по ресурсам.

Для люфта ballon memory и shared memory.

Есть еще pinning vcpu за железными ядрами.

Есть рекоммендации какой тип проца выбирать, кроме наиболее близкого к хосту. x86-64; x86-64v2; x86-64v3; x86-64v4. к слову https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html . ЕМНИП, в Debian/RH на v3 планомерно переползают.

Нюансов куча, категорически согласен.

anonymous
()
Ответ на: комментарий от anonymous

** Numa 1 socket / 2 vcpu / 2 Gb RAM, где на одно из ядер предпологается hugetable в условный 1 Гб (в документации RH это расписано)

Снежинка, которая с меня требовала скрин троллила, потому что в Собираю Proxmox сервер для дома (комментарий) чётко написал про этот момент. А уже ссылки, даже с картинками на numa упорно игнорировались.

Ссылку подкину, по vcpu https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html#default-x86-cpu-models

anonymous
()
Ответ на: комментарий от NyXzOr

Никто не запрещает, это рекомендация. Ноги растут из шаблонов, повторюсь virt-manager, когда iso-шку пихаешь она по умолчанию пытается подобрать шаблон.

Если бы на паравиртуализацию не было накладных расходов, тогда как вчера писали можно было бы в лоб «минимальные системные требования». И опять же повторюсь, с той же виндой как гостевой из-за таких моментов нужно будет смотреть драйвера. Нет, ну конечно, если у вас самая топовая конфигурация и столько слотов для passtrought, то конечно.

Если честно, я вообще не понимаю претензий: шаблоны и рекомендации не носят ультимативный характер. Это средство облегчения в процессе развертывания. Так же отмечу, что в исключительных случаях «в рукопашную» и без libvirt, virt-manager, ovirt, cockpit, etc… Если по другому это все равно что сравнивать подходы у ORM и коннектора к БД.

anonymous
()
Ответ на: комментарий от anonymous

Какой-то дурацкий вопрос у тебя. Мы же говорим о том, что можно выделить больше ресурсов в Proxmox, чем на самом деле у тебя есть и оно разрулит их распределение. А что ты можешь полезного с этим делать решать сугубо тебе самому.

AntonyRF ★★★★
() автор топика

Я примерно год назад собрал себе домашний сервак на базе китайской мамки и зиона, удалось засунуть 256 гигов памяти и nvme на 1Тб, но весь бюджет был около 50к.

Jellyfin работает и без видеокарты, декодинг фуллхд вообще вопросов не вызывает.

Ставь Proxmox и не парься, я до этого жил на i5-8600k, упёрся только в 32 гига памяти на itx мамке.

Ну про https://community-scripts.github.io/ProxmoxVE/scripts наверное знаешь

overmind88 ★★★★★
()
Ответ на: комментарий от AntonyRF

Overcommit (memory overcommit) — концепция в управлении памятью операционной системы, которая позволяет выделить процессам больше памяти, чем физически доступно на физической машине. Это возможно, потому что процессы не всегда используют весь выделенный им объём памяти.

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

И к слову в одном из постов и написал что в сущности тут две задачи: нагрузить тестами до упора и с другой стабильный продакшн. Что опять же равносильно утверждению: решать Вам.

И ровно так же не удивляться ответам на форуме игнору на «Я придумал; захотел. А лыжи не едут»

Было ТЗ, по этому ТЗ как заложено разработчиками выкладку в меру своей компетенции дал: конечно, практика покажет.

anonymous
()
Ответ на: комментарий от AntonyRF

AM5 безусловно перспективнее, и в сегодняшнюю мать, скорее всего, можно будет воткнуть новый проц с 12 ядерными CCD(и двумя, если захочется/заможется). Но на текущий момент количество компа на рубль наверное за чем-то вроде 13400/14400 да с DDR4 =(
Следующая ступень, видимо, 265K из-за кучи ядер.

GAMer ★★★★★
()
Последнее исправление: GAMer (всего исправлений: 1)