Hiperwizor czy kontenery jako podstawa nowego serwera domowego?

Wybierz kontenery na początek, jeśli plan na pierwszy rok obejmuje jeden zaufany stos aplikacji linuksowych; wybierz hiperwizor na początek, jeśli plan zakłada już osobne systemy operacyjne, często zmieniające się środowiska testowe lub granice zaufania wymagające całych maszyn wirtualnych.

To wybór płaszczyzny sterowania serwera, a nie decyzja o tym, czy kontenery i maszyny wirtualne mogą współistnieć. Host oparty na hiperwizorze może uruchamiać Dockera wewnątrz maszyny wirtualnej, a host z Linuksem oparty na kontenerach może później dodać KVM. Najlepszym rozwiązaniem domyślnym jest ta warstwa, której jednostka kopii zapasowej i awarii odpowiada obciążeniom, które możesz dziś wskazać.

Przed wyborem płaszczyzny sterowania zinwentaryzuj obciążenia

Zapisz każdą planowaną usługę, jej wymagania dotyczące systemu operacyjnego, lokalizację danych, dostęp do sprzętu, ekspozycję oraz dopuszczalny zakres ponownego uruchomienia. Zaznacz wszystkie maszyny wirtualne z systemem Windows lub BSD, eksperymentalne jądra, niezaufany kod lub usługi publiczne, których naruszenie bezpieczeństwa nie powinno obejmować hosta aplikacji.

Jeśli lista obejmuje niemal wyłącznie utrzymywane obrazy Dockera na jednym jądrze Linuksa, kontenery już zapewniają pakowanie aplikacji, sieci, zasady ponownego uruchamiania i kontrolę zasobów. Jeśli obejmuje kilka systemów operacyjnych lub często zmieniające się środowiska testowe, hiperwizor zapewnia bardziej naturalną granicę cyklu życia.

Nie traktuj samych pomysłów jak obciążeń. Zanim poniesiesz koszt pamięci, przestrzeni dyskowej i utrzymania płaszczyzny sterowania maszynami wirtualnymi, wymagaj co najmniej jednego obecnego zadania, którego kontenery nie mogą poprawnie obsłużyć.

Porównaj izolację z jednostką, którą faktycznie obsługujesz

Kontenery współdzielą jądro hosta i zawierają aplikacje wraz z zależnościami. Maszyny wirtualne mają własne jądro systemu gościa i emulują sprzęt lub przypisują go bezpośrednio. Porównanie techniczne granic kontenerów i maszyn wirtualnych wyjaśnia, dlaczego mniejsze obciążenie kontenerów i silniejsza izolacja systemów gościa wynikają z odmiennych architektur, a nie z uniwersalnego rankingu jakości.

Podejście zorientowane na kontenery jest wydajne, gdy usługi mogą współdzielić jeden zaktualizowany host z Linuksem i można je odtworzyć z plików Compose lub innej deklaratywnej definicji. Podejście zorientowane na hiperwizor zapewnia większą przejrzystość, gdy jedną maszynę wirtualną można odbudować, odizolować zaporą lub przywrócić do wcześniejszego stanu, nie traktując każdej usługi jako części tej samej instancji systemu operacyjnego.

Decyzja przemawia za odejściem od kontenerów, gdy usługa wymaga innego jądra lub model zaufania wyklucza współdzielenie jądra hosta. Przemawia za odejściem od hiperwizora, gdy każda maszyna wirtualna miałaby zawierać identyczną instalację Linuksa, której jedynym zadaniem byłoby uruchamianie tych samych zaufanych kontenerów.

Wybierz jednostkę kopii zapasowej i odbudowy

Odbudowa zorientowana na kontenery jest szybka tylko wtedy, gdy definicje, sekrety, wersje i woluminy trwałe są oddzielone i objęte kopiami zapasowymi. Odtwarzanie zorientowane na hiperwizor jest szybkie tylko wtedy, gdy kopie zapasowe maszyn wirtualnych są niezależne od uszkodzonego hosta, a konfiguracja sieci hosta i mapowania urządzeń są udokumentowane.

Przetestuj jedno destrukcyjne odzyskiwanie na zapasowej maszynie wirtualnej lub nośniku zastępczym. Wybierz rozwiązanie, którego dane wejściowe potrafisz wyliczyć i odtworzyć; panele i przyciski migawek nie zastąpią kopii przechowywanych poza hostem.

Featured

Osobista chmura i domowy NAS ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Niech powiązania ze sprzętem i siecią ujawnią ukrytą pracę

Dostęp do GPU, USB, HBA i specjalnych kart sieciowych może być bezpośredni na hoście opartym na kontenerach, ale kontenery z podwyższonymi uprawnieniami i szerokie mapowania urządzeń osłabiają granice izolacji aplikacji. Hipernadzorca może przypisywać urządzenia do systemów gościa, jednak grupy IOMMU, zachowanie podczas resetowania i własność sterowników hosta mogą sprawić, że ta ścieżka będzie zawodna.

W przypadku sieci obowiązuje ta sama zasada. Mosty kontenerów są prostym rozwiązaniem dla jednej zaufanej strefy aplikacji; mosty i zapory wielu systemów gościa mogą ułatwić rozdzielenie stref laboratoryjnych, publicznych i infrastrukturalnych, ale zwiększają też liczbę interfejsów i ustawień routingu, które muszą przetrwać odzyskiwanie.

Ożywiona dyskusja operatorów o wyborze Debiana z Dockerem zamiast Proxmoxa pokazuje praktyczną granicę: hipernadzorca jest przydatny, gdy maszyny wirtualne są rzeczywistym wymogiem, ale może wydawać się zbędnym elementem, gdy serwer uruchamia tylko kontenery.

Zacznij prosto, ale określ warunek migracji

Wybierz podejście oparte na kontenerach, gdy wszystkie planowane usługi działają w ramach jednego zaufanego jądra Linuksa, pamięć jest ograniczona, a dane aplikacji wraz z plikami wdrożeniowymi tworzą przetestowany zestaw do odzyskiwania. Utrzymuj minimalną konfigurację hosta, aby późniejsze dodanie wirtualizacji lub migracja do niej były nadal możliwe.

Wybierz podejście z hipernadzorcą jako podstawą, gdy plan na pierwszy rok obejmuje co najmniej dwa systemy gościa z różnymi jądrami, strefami zaufania, harmonogramami przywracania lub przypisaniami sprzętu. Poradnik wyboru systemu operacyjnego serwera domowego pomoże ustalić, jakich możliwości hosta faktycznie wymagają planowane usługi.

Wróć do wyboru, gdy pojawi się niezgodny system operacyjny, ryzykowne publiczne obciążenie, powtarzalne środowisko laboratoryjne lub potrzeba odzyskiwania całej maszyny wirtualnej. Nie migruj tylko dlatego, że jedna z opcji jest modna; migruj, gdy zmieni się jasno określona granica.