Jedną z rzeczy, które moim zdaniem czynią hiperwizor naprawdę dobrym, jest to, że od razu po instalacji ma rozsądne i sensowne ustawienia domyślne, które pozwalają od razu zacząć pracę. Ostatnią rzeczą, na którą warto zwrócić uwagę, jest konieczność wprowadzania zmian przez pół dnia, aby platforma była użyteczna. To jedna z rzeczy, które naprawdę lubię w Proxmox, ponieważ od razu oferuje bardzo użyteczny zestaw ustawień domyślnych. Można go zainstalować, zalogować się, zacząć tworzyć maszyny wirtualne i serwery LXC oraz uruchamiać wszystko w środowisku produkcyjnym lub w domowym laboratorium. Okazuje się jednak, że istnieje kilka domyślnych ustawień Proxmox, które można zmienić. Przyjrzyjmy się domyślnym ustawieniom, które pozostawiam bez zmian, i tym, które zmieniam, aby lepiej je zrozumieć.

Ustawienia domyślne Proxmox pozostawiam celowo

Może pojawić się pokusa, aby od razu zacząć modyfikować domyślne ustawienia Proxmoxa — bo przecież „da się”. Przestrzegam jednak przed takim podejściem. Proxmox oferuje ogromne możliwości konfiguracji, ale nieprzemyślane zmiany mogą łatwo pogorszyć wydajność, nie przynosząc żadnych realnych korzyści, a wręcz generując nowe problemy. Są to ustawienia domyślne, którym zaufałem od samego początku, zaraz po instalacji.

Układ interfejsu użytkownika i model uprawnień Proxmox Web

Ogólny układ interfejsu użytkownika Proxmoxa pozostawiam dokładnie taki, jaki jest po instalacji. Widok centrum danych, struktura węzłów oraz organizacja maszyn wirtualnych są logiczne i czytelne — wystarczy poświęcić im chwilę. Teraz, gdy tryb ciemny jest dostępny i ustawiony domyślnie, nie mam potrzeby wprowadzać żadnych zmian w wyglądzie ani w sposobie działania interfejsu, nawet w obrębie ustawień domyślnych.

Przejdźmy do uprawnień. Wielokrotnie widziałem — i sam na początku również to robiłem — jak użytkownicy na zbyt wczesnym etapie próbują nadmiernie dostosowywać role i uprawnienia w Proxmoxie. Niemal zawsze prowadzi to później do niepotrzebnego chaosu. W środowisku domowego laboratorium domyślne logowanie root@pam, uzupełnione o rozsądnie skonfigurowane tokeny API do automatyzacji, jest w zupełności wystarczające. Z dodawaniem LDAP-a czy zewnętrznych mechanizmów uwierzytelniania nie spieszę się, o ile nie ma ku temu konkretnej, uzasadnionej potrzeby.

W praktyce większość dużych graczy, takich jak VMware i inni dostawcy, zmieniła swoje podejście do integracji z Active Directory. Z perspektywy bezpieczeństwa bardzo często oznacza to otwarcie puszki Pandory — naruszenie uprawnień w Active Directory może wówczas przełożyć się na domyślny dostęp do całego środowiska wirtualizacji.

W tym kontekście domyślne ustawienia Proxmoxa są rozsądne, bezpieczne i dobrze udokumentowane.

Domyślne abstrakcje pamięci masowej

Uważam, że sposób, w jaki Proxmox obsługuje i abstrakcyjnie integruje pamięć masową, jest jedną z jego największych zalet. Do dyspozycji mamy lokalny LVM, storage katalogowy, NFS, iSCSI oraz Ceph — a wszystko to jest zarządzane w sposób spójny i dobrze przemyślany.

Jeśli korzystam z lokalnej pamięci masowej, pozostawiam domyślną konfigurację storage’u katalogowego. W przypadku NFS lub SMB pozwalam Proxmoxowi zarządzać tymi zasobami, zamiast ręcznie montować je w systemie operacyjnym. Interfejs użytkownika oferuje bardzo dobre, przemyślane przepływy pracy, które znacząco ułatwiają konfigurację pamięci masowej, a także późniejsze tworzenie kopii zapasowych, migracje oraz zarządzanie uprawnieniami.

Domyślne modele sprzętu maszyn wirtualnych

Kolejnym obszarem są domyślne modele sprzętowe maszyn wirtualnych. W większości przypadków pozostawiam je bez zmian. Korzystam z domyślnego VirtIO dla dysków i sieci, typu maszyny i440fx oraz standardowych ustawień BIOS-u. Taka konfiguracja zapewnia najlepszą kompatybilność na różnych platformach.

Jeśli jednak chcesz wprowadzić zmiany, możesz przełączyć typ maszyny na q35 — nowocześniejszy układ PCI, który lepiej współpracuje ze współczesnymi systemami operacyjnymi gościa.

Sterowniki VirtIO działają bardzo dobrze, a ich największą zaletą jest szerokie wsparcie. Dodatkowo są one ściśle zintegrowane z domyślnymi narzędziami Proxmoxa. Jedyną sytuacją, w której warto rozważyć zmianę tych ustawień, jest praca z bardzo przestarzałym lub silnie wyspecjalizowanym oprogramowaniem.

Domyślny harmonogram tworzenia kopii zapasowych

Podczas konfigurowania kopii zapasowych w Proxmoxie, nawet jeśli zmieniam harmonogram ich wykonywania, pozostawiam sam mechanizm backupów bez modyfikacji. Integracja z Proxmox Backup Server jest — moim zdaniem — bardzo dobrze zaprojektowana już na starcie i nie wymaga wielu zmian, aby skutecznie zabezpieczyć dane.

Poza tym nie tworzę kopii zapasowych ręcznie za pomocą skryptów ani nie korzystam z zadań cron poza Proxmoxem. Domyślne ustawienia backupów w Proxmoxie zapewniają przejrzystość i dobre raportowanie błędów. Cenię spójność i niezawodność wbudowanej funkcji tworzenia kopii zapasowych, a ręczna replikacja jest trudna — i szczerze mówiąc, po co ją komplikować?

Domyślne ustawienia zawsze zmieniam od razu

A teraz podzielę się z Wami najciekawszą częścią — są to domyślne ustawienia, które zwykle modyfikuję w większości instalacji Proxmoxa. Pamiętajcie, że te zmiany nie są radykalne ani rewolucyjne, ale z czasem znacząco poprawiają komfort i efektywność pracy na platformie wirtualizacyjnej.

Konfiguracja repozytorium subskrypcji

To oczywiste, zwłaszcza w przypadku laboratoriów domowych. W takich środowiskach wyłączam repozytoria korporacyjne i włączam repozytoria bez subskrypcji dla aktualizacji. Dzięki temu unikam problemów związanych z tym, że Proxmox VE domyślnie wskazuje na repozytoria korporacyjne i wymaga subskrypcji. Przy domyślnej konfiguracji repozytoriów logi mogą się szybko zapełniać błędami 401, gdy sprawdzanie aktualizacji zakończy się niepowodzeniem.

Proxmox oferuje jednak proste rozwiązanie, jeśli chcesz korzystać wyłącznie z aktualizacji niesprawdzonych i mniej rygorystycznie testowanych pod kątem środowisk produkcyjnych. Wystarczy wskazać repozytoria bez subskrypcji, co pozwala na sprawdzanie i pobieranie aktualizacji całkowicie bezpłatnie i bez generowania błędów.

Układ pamięci masowej podczas instalacji Proxmox

Podczas instalacji Proxmoxa łatwo jest po prostu zaakceptować ustawienia domyślne — i w większości przypadków działają one dobrze. Jednak jeśli korzystam z ZFS, robię krok wstecz i dokładnie rozważam układ dysków oraz dodatkowe kwestie, takie jak kompresja. Zastanawiam się też, czy dany węzeł będzie uczestniczył w replikacji lub tworzeniu kopii zapasowych.

W przypadku LVM lubię przyjrzeć się konkretnemu sprzętowi, na którym instalowany jest Proxmox, i sprawdzić, czy rozmiar partycji wymiany oraz przydzielona przestrzeń woluminu głównego są odpowiednie dla danego hosta.

Pamiętaj, że nie trzeba już dopasowywać rozmiaru partycji wymiany jeden do jednego do pamięci RAM — ta zasada jest nieaktualna dla nowoczesnych środowisk wirtualizacji. Poniżej znajduje się jednak dobra praktyka, którą warto wziąć pod uwagę:

• Host 32 GB RAM: swap 8–16 GB
• Host 64 GB RAM: swap 16 GB
• Host 128 GB RAM: swap 16–32 GB
• Host 256 GB RAM: swap 32 GB

Pamiętaj również, że partycja główna nie zawiera tylko systemu operacyjnego, ale także:

• Aktualizacje pakietów i pliki w pamięci podręcznej,
• Logi,
• Obrazy jądra,
• Metadane zadania kopii zapasowej,
• Obrazy ISO (jeśli są przechowywane lokalnie),
• Zrzuty awaryjne,
• Obrazy kontenerów, jeśli intensywnie korzystasz z LXC

Dobre zasady:

• Aktywny węzeł laboratorium domowego: od 96 do 128 GB
• Węzeł klastra z obrazami ISO, kopiami zapasowymi i logami: 128 GB
• Minimalny węzeł Proxmox: 64 GB

Wszystko mniejsze niż 64 GB prawie zawsze wiąże się z późniejszym czyszczeniem. Poświęcenie dodatkowych 5 minut może się opłacić, ponieważ przez cały okres użytkowania węzła nie będziesz musiał zmagać się z brakiem miejsca ani innymi problemami z instalacją systemu.

Typ procesora maszyny wirtualnej

Domyślnie, podczas tworzenia maszyny wirtualnej lub LXC w Proxmox, używany jest ogólny typ procesora. Dzieje się tak z uzasadnionych powodów, ponieważ pomaga to zmaksymalizować kompatybilność procesora i kompatybilność migracji. Jeśli jednak korzystasz z tej samej generacji procesora w różnych węzłach lub w laboratorium z jednym węzłem, prawie zawsze zmieniam to na hosta.

Pozwala to udostępnić gościowi więcej funkcji procesora i skorzystać z takich rozwiązań jak zagnieżdżona wirtualizacja. W przypadku laboratoriów domowych jest to duże ułatwienie, ponieważ pozwala wypróbować inne rzeczy wymagające udostępnienia możliwości wirtualizacji procesorowi.

Konfiguracja memory ballooning

Inną domyślną funkcją, którą warto rozważyć, jest „Memory Balling”, mechanizm dynamicznego zarządzania RAM-em między maszynami wirtualnymi. Jest ono domyślnie włączone. Warto o tym pomyśleć w obliczu dzisiejszych wzrostów cen pamięci i wielu systemów z małą ilością pamięci. Jeśli jednak zależy Ci na najlepszej i najbardziej przewidywalnej wydajności, możesz wyłączyć tę opcję, ponieważ pozwala ono maszynom wirtualnym gości i maszynom LXC zachować przydzieloną im pamięć.

Szczególnie w przypadku aplikacji intensywnie wykorzystujących pamięć, takich jak bazy danych, stosy monitorowania lub inne aplikacje wrażliwe na wydajność, zazwyczaj działają one lepiej ze stałą pamięcią. W przypadku maszyn wirtualnych o niskiej wydajności lub lekkich maszynach użytkowych pozostawienie skonfigurowanego „Memory Balling” jest całkowicie w porządku.

Pamiętaj, że być może nie akceptujesz już domyślnego ustawienia, ale świadomie bierzesz pod uwagę swoje obciążenia, decydując, jak skonfigurować zachowanie pamięci.

Nazewnictwo i segmentacja mostów sieciowych

Podczas instalacji i uruchomienia Proxmox w domowym laboratorium lub środowisku produkcyjnym, domyślnie tworzony jest most vmbr0. Jest to całkowicie w porządku, podobnie jak vSwitch0 w VMware. Jednak prawie zawsze zmieniam nazwy lub dodaję kolejne mosty, gdy laboratorium się rozrasta.

Nadawanie nazw mostom w oparciu o ich przeznaczenie lub sieć VLAN ułatwia rozwiązywanie problemów. Na przykład można tworzyć mosty zarządzające, pamięci masowej i różne sieci laboratoryjne. Tak właśnie robiliśmy i robiliśmy również w środowiskach VMware przez lata. Myślę, że ta metodologia dobrze sprawdza się również w przypadku Proxmox.

Można pozostawić wszystko na jednym domyślnym moście i po prostu przypisać maszyny do różnych sieci VLAN, ale z punktu widzenia zarządzania i widoczności uważam, że spowoduje to późniejszy bałagan w zarządzaniu, gdy laboratorium się rozrośnie.

Przechowywanie migawek i kopii zapasowych

Wspomniałem wcześniej, że nie zmieniam struktury tworzenia kopii zapasowych. Korzystam z wbudowanych przepływów pracy kopii zapasowych, które są już wbudowane w Proxmox. Dostosowuję jednak zasady retencji w oparciu o istotność obciążenia i dostępną przestrzeń dyskową.

Maszyny wirtualne, które są krytyczne w moim środowisku, mają dłuższy czas retencji. Testowe maszyny wirtualne mają krótszy czas retencji, a nawet zerowy, jeśli są tymczasowe lub ulotne. Wyraźne określenie tego zapobiega nadmiernemu zajmowaniu miejsca przez kopie zapasowe w czasie i zapewnia odpowiednią ochronę ważnych danych.

Domyślne ustawienia zapory sieciowej

Domyślne ustawienia i możliwości Proxmox obejmują naprawdę wydajne rozwiązanie zapory sieciowej wbudowane w hypervisor. Jest ono domyślnie wyłączone na poziomie centrum danych. Prawie zawsze je włączam, nawet jeśli nie używam od razu skomplikowanych reguł.

Zadawano mi już to pytanie: skoro mam zaporę sieciową, taką jak pfSense lub OPNsense, która chroni moją sieć, po co mi zapora Proxmox? Cóż, to świetne pytanie. Korzystanie z zapory Proxmox pozwala chronić hypervisor lub maszyny wirtualne przed zasobami w tej samej sieci VLAN/podsieci. Dzięki temu można skutecznie oddzielić host Proxmox od reszty sieci i ruchu wschód/zachód. To coś, czego główna zapora sieciowa nie może zrobić z ruchem w tej samej sieci VLAN.

Nawet proste zasady, takie jak blokowanie zbędnego ruchu przychodzącego lub izolowanie sieci VLAN w laboratorium, mogą mieć realną wartość dla Twojego laboratorium i nauki.

Rejestrowanie i monitorowanie

Domyślne ustawienia logowania Proxmox są wystarczające, ale zazwyczaj integruję monitoring zewnętrzny wcześnie. Lubię skonfigurować cel syslog dla moich logów Proxmox i rozpocząć monitorowanie za pomocą Prometheusa i Grafany lub dodać alerty. Możesz również wcześnie dodać serwer Proxmox VE do czegoś takiego jak Pulse, aby uzyskać doskonałą widoczność monitorowania.

Domyślne ustawienia Proxmoxa czasami zmieniam

Nie wszystko jest sztywną regułą. Przyjmuję poniższe wartości domyślne i oceniam je indywidualnie, w zależności od środowiska i sposobu użycia.

Strojenie ZFS

Jeśli korzystam z systemu ZFS, czasami może być konieczne dostosowanie rozmiaru pliku ARC, ustawień kompresji lub rozmiaru rekordu. Jednak to również zależy od przypadku i należy zrozumieć obciążenie. Domyślne ustawienia sprawdzają się w przypadku obciążeń o mieszanym przeznaczeniu. Zbytnie dostrojenie systemu ZFS lub dostrojenie go do niewłaściwego typu obciążenia może prowadzić do problemów.

Ustawienia HA i klastra

Domyślne ustawienia wysokiej dostępności są rozsądne, ale nie włączam HA na wszystkich węzłach tylko dlatego, że mam wiele węzłów.

Niektóre obciążenia nie korzystają z HA i dodają niepotrzebnej złożoności. Włączam HA wybiórczo tam, gdzie przynosi to realne korzyści, a ustawienia domyślne pozostawiam w innych miejscach.

Przejście PCI i ustawienia IOMMU

Są to ustawienia specjalnego przeznaczenia, które włączam tylko wtedy, gdy jest to potrzebne. Przepustowość GPU, przepustowość karty sieciowej i przepustowość dysku to przypadki użycia tych ustawień, ale wymagają one dokładnego przemyślenia ich wdrożenia.

Nie należy włączać tych ustawień wszędzie na każdym hoście, ponieważ może to powodować problemy. Przepustowość PCI to narzędzie, które włącza się w razie potrzeby, ale pozostawia wyłączone przez większość czasu, gdy nie jest potrzebne.

Podsumowanie

Mamy nadzieję, że ta dyskusja na temat domyślnych ustawień Proxmoxa, które są dostępne od razu po instalacji, oraz tego, czy pozostawić je bez zmian, czy je zmienić, pomoże tym, którzy rozważają konfigurację. Jak każdy dobry hypervisor, Proxmox nie wymaga od użytkownika wprowadzania zmian w większości zadań, zwłaszcza w domowym laboratorium. Jednak wiedza o tym, które ustawienia domyślne pozostawić, a które ewentualnie zmodyfikować, to świetny sposób na jeszcze większe zwiększenie wydajności i użyteczności. Jeśli przebudowujesz laboratorium lub po prostu audytujesz istniejący klaster, to ćwiczenie będzie doskonałym ćwiczeniem. Możesz być zaskoczony, jak wiele drobnych usprawnień czeka na wprowadzenie.

---

Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.

Link do formularza tutaj: https://beitadmin.pl/pomysly

Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).