Homelab #14: pierwszy downsize

Od ostatnich zmian w homelabie minęło ponad pół roku. Do tego momentu głównie budowałem homelab i niezbyt zwracałem uwagę na takie rzeczy jak zużycie prądu w skali miesięcy ani na to, że mogę mieć te same funkcje przy mniejszej ilości sprzętu i/lub większej stabilności. W tym artykule chciałbym podzielić się zmianami, jakie wprowadziłem w tym czasie, oraz tym, czego się przy tym wszystkim nauczyłem.

Główną motywacją do zmian było to, że zacząłem monitorować zużycie prądu przez homelab. W pewnym momencie zauważyłem, że pobiera on powyżej 200 W, a pracuje 24/7, co przekłada się na dość spory koszt energii. Postanowiłem więc zejść chociażby do poziomu 150 W. W podsumowaniu pokażę, do jakiego zużycia udało mi się ostatecznie dojść, jednocześnie zwiększając stabilność całej infrastruktury.

Pożegnanie z k3s

Nie chcę tutaj dyskutować o tym, po co hostuję serwisy lokalnie. Postaram się przygotować osobny artykuł, w którym opiszę, po co, co i jak dokładnie hostuję w „chmurowej" części homelabu.

Na początek wybrałem k3s jako platformę do hostowania części chmurowej w domu. Wybór padł na niego głównie dlatego, że: znam Kubernetes, miałem trzy wolne komputery i musiałem bardzo szybko przygotować infrastrukturę, która pozwoliłaby mi nie myśleć o niej przez kilka miesięcy. Z perspektywy czasu mogę powiedzieć, że był to dobry wybór.

Ogólnie nie miałem z k3s żadnych dużych problemów, ale zauważyłem kilka drobnych, które sprawiły, że zacząłem się zastanawiać nad zmianami. Pierwszym z nich była migracja podów pomiędzy nodami. Czasami musiałem jeden po drugim wyłączać nody klastra i w tym procesie k3s bardzo długo migrował serwisy z niedziałającego noda na zdrowy, co powodowało różne problemy z aplikacjami. Kolejną rzeczą była sama organizacja klastra — przez sześć miesięcy ani razu nie zdarzyła się sytuacja, w której przydałyby mi się trzy jednostki. Dodatkowym benefitem rezygnacji z jednej z nich byłoby pozbycie się ~10 W z homelabu.

Plan był więc taki: rozdzielam k3s na dwa serwery:

• aplikacje
• bazy danych

Po pierwsze, pozwoliłoby mi to zmniejszyć chmurę z trzech do dwóch komponentów. Po drugie — pozbyć się overheadu Kubernetesa. Tak, Kubernetes daje możliwość skalowania zarówno kontenerów, jak i nodów. Ale z jednej strony nie skorzystałem z tego jeszcze ani razu i nie przewiduję, żebym w najbliższym czasie miał skorzystać. Z drugiej — częściowe skalowanie horyzontalne mogę i tak zrobić, dodając np. LXC w Proxmoxie, który byłby częścią chmury. Choć wątpię, że kiedykolwiek do tego dojdzie. Chyba najważniejszą motywacją było dla mnie zmniejszenie zużycia energii oraz zwolnienie jednego z komputerów.

Tak też zrobiłem. Wszystkie aplikacje są uruchamiane za pomocą Docker Compose, a dostęp do nich odbywa się przez Cloudflare Tunnel. Bazy danych nie mają dostępu z zewnątrz, backupy są robione przez crontab, a na dane wykorzystałem możliwość zainstalowania dodatkowego dysku SATA w Dell OptiPlex Micro.

W ten sposób przeprowadziłem zmiany w homelabie, które pozwoliły mi zmniejszyć zużycie energii, a jednocześnie pozbyć się overheadu Kubernetesa. I jak do tej pory nie zauważyłem żadnych minusów.

UniFi Cloud Gateway Fiber

UniFi Dream Machine Special Edition — była to pierwsza duża jednostka w moim homelabie (UniFi Express pomijam, bo choć było to moje pierwsze urządzenie sieciowe, to na pewno nie tak ważne jak UDM). Zakupiona jeszcze w 2024 roku i tak naprawdę to od niej zaczęła się moja przygoda z homelabem. Był to długo planowany zakup i do dziś jestem z niego bardzo zadowolony. Gdyby nie on, nie wiem, czy mój homelab wyglądałby tak, jak wygląda teraz. Dodatkowo było to moje pierwsze urządzenie w formacie rack — co dało mi pęd do pójścia w stronę szafy rack.

Niestety musiałem się z tym urządzeniem pożegnać, a głównym powodem było to, że w międzyczasie pojawiły się tańsze, mocniejsze i jednocześnie bardziej energooszczędne jednostki od tego samego UniFi. Pewnego wieczoru zacząłem się zastanawiać, jakie są alternatywy dla UDM. Okazało się, że w ciągu ostatniego roku UniFi zaprezentowało nową linię urządzeń — Cloud Gateway. Od razu w oko wpadł mi UniFi Cloud Gateway Fiber.

UniFi Cloud Gateway Fiber — urządzenie, które posiada wszystkie niezbędne mi porty, wspiera wszystkie aplikacje UniFi, jest wydajniejsze niż UDM SE, a na dodatek zużywa mniej prądu. Dodatkowym plusem jest cena — 1250 zł.

Długo się więc nie zastanawiałem i kupiłem UCG Fiber. Migracja całej sieci sprowadzała się do wyeksportowania backupu z UDM i odtworzenia go przy inicjalizacji nowego urządzenia. Dosłownie w 15 minut UDM SE został wyjęty z racka i zastąpiony przez UCG Fiber. Tak, niestety UCG Fiber nie jest rack ready, ale nie stanowiło to problemu — i tak miałem kilka urządzeń poziomu sieciowego (ONT oraz DNS), które idealnie zmieściły się na półce obok niego.

Sama ta wymiana zmniejszyła zużycie energii o około 25–30 W.

Podział głównego serwera

W jednym z artykułów opisałem mój główny serwer Proxmox, który został umieszczony w szafie rack. Jego specyfikacja wygląda następująco:

• Intel i5-14400
• Gigabyte B760M D3HP DDR4
• 2×8 GB DDR4
• 1 TB NVMe

Główną motywacją do utrzymywania tego serwera było to, że planowałem mocno korzystać z lokalnego AI, a do tego potrzebowałbym karty graficznej. Przez jakiś czas używałem Intel Arc A40 6 GB oraz MSI GeForce RTX 3050 LP E OC 6 GB. Ale po testach kart z 6 GB VRAM i po stwierdzeniu, że w ciągu tygodnia korzystam z karty przez może 5–10 minut, uświadomiłem sobie, że trzymanie jej włączonej 24/7 tylko po to, żeby użyć jej przez kilka minut, jest bezsensowne.

Doszedłem więc do wniosku, że nie potrzebuję karty graficznej lokalnie (przynajmniej na ten moment). Zacząłem się zastanawiać, czy nie warto przenieść Proxmoxa na jakiś mini PC. Głównym problemem znowu było zużycie prądu — jakkolwiek bym nie kombinował z ustawieniami płyty głównej oraz trybami oszczędzania energii w Proxmoxie, nie udawało mi się zejść poniżej ~40 W. A to moim zdaniem trochę za dużo jak na serwer, na którym jedyne, co się dzieje, to działający Home Assistant, a raz na jakiś czas korzystam ze stacku *arr, Gitei lub baz danych.

Zacząłem się więc zastanawiać, w którą stronę mógłbym z tym pójść. Miałem jeden zapasowy Dell OptiPlex 3050 Micro i nawet raz spróbowałem zmigrować na niego cały Proxmox, ale niestety okazało się, że obciążenie jest jednak za duże jak na i3-8100T.

Z czasem powstał trochę inny plan: rozdzielić główny serwer na dwa mniejsze. Jeden byłby serwerem Proxmox ze wszystkim oprócz Home Assistanta. Drugi służyłby wyłącznie do hostowania Home Assistanta. Pozwoliłoby mi to bawić się Proxmoxem bez konieczności zatrzymywania całej automatyzacji domowej (jako że wszystkie włączniki w mieszkaniu są smart, to w momencie, gdy Home Assistant nie działa — nie działa nic). Plan więc jakiś miałem — problemem był tylko hardware.

I pewnego dnia udało mi się znaleźć Dell OptiPlex 5090 Micro (i5-10500T + 16 GB DDR4 + 250 GB NVMe) w bardzo atrakcyjnej cenie. Kupiłem go więc od razu, z zamiarem użycia jako głównego serwera z Proxmoxem. Home Assistanta zainstalowałem na Dell OptiPlex 3050 Micro.

W ten oto sposób podzieliłem główny serwer na dwa mniejsze:

• 5090 (i5-10500T) z Proxmoxem (zużycie CPU ~25%)
• 3050 (i3-8100T) z Home Assistantem (zużycie CPU ~10%)

Sumarycznie te dwa komputery zużywają ~25 W, czyli około 60% zużycia oryginalnego serwera. A na dodatek dało mi to możliwość zabawy z Proxmoxem bez zakłócania pracy Home Assistanta.

Na ten moment jeszcze nie wiem, co zrobić z głównym serwerem — na razie po prostu go wyłączyłem, ponieważ nie jestem pewien, czy nie będę kiedyś potrzebował serwera ze slotem PCIe.

Podsumowanie

Postarałem się opisać wszystkie zmiany, które wprowadziłem w homelabie w ciągu ostatnich sześciu miesięcy. Finalnie udało mi się zejść ze zużyciem energii z ponad 200 W do okolic 125 W. Przy tym, moim zdaniem, zwiększyłem codzienną stabilność całości oraz przygotowałem infrastrukturę pod punktową rozbudowę dzięki większej granulacji. Przed zmianami miałem jeden serwer oraz trzywęzłowy klaster — teraz mam cztery osobne maszyny (dwa serwery chmurowe z Dockerem, Proxmox na OptiPlexie 5090 oraz Home Assistant na OptiPlexie 3050), z których rozbudowywać mogę tylko te, które tego faktycznie potrzebują.