Najpierw hiperwizor czy kontenery na nowym serwerze domowym

Wybierz podejście oparte na kontenerach, gdy plan na pierwszy rok obejmuje jeden zaufany stos aplikacji linuksowych; wybierz podejście oparte na hipernadzorcy, gdy plan już obejmuje odrębne systemy operacyjne, często zmieniające się środowiska laboratoryjne lub granice zaufania wymagające całych maszyn gościnnych.

To wybór dotyczący warstwy sterowania serwerem, a nie tego, czy kontenery i maszyny wirtualne mogą współistnieć. Host oparty na hipernadzorcy może uruchamiać Dockera wewnątrz maszyny wirtualnej, a host linuksowy oparty na kontenerach może później dodać KVM. Właściwym wyborem domyślnym jest warstwa, której jednostka kopii zapasowej i awarii odpowiada obciążeniom, które potrafisz dziś określić.

Zrób inwentaryzację obciążeń przed wyborem warstwy sterowania

Zapisz każdą planowaną usługę, jej wymagania dotyczące systemu operacyjnego, lokalizację danych, dostęp do sprzętu, ekspozycję oraz akceptowalny zakres ponownego uruchomienia. Oznacz gościa z systemem Windows lub BSD, eksperymentalne jądro, niezaufany kod albo usługę publiczną, której przejęcie nie powinno obejmować hosta aplikacji.

Jeśli lista składa się niemal wyłącznie z utrzymywanych obrazów Dockera działających na jednym jądrze Linuksa, kontenery już zapewniają pakowanie, sieci, zasady ponownego uruchamiania i kontrolę zasobów. Jeśli obejmuje kilka systemów operacyjnych lub często zmieniające się środowiska laboratoryjne, hipernadzorca zapewnia bardziej naturalną granicę cyklu życia.

Nie traktuj pomysłów jako obciążeń. Zanim poniesiesz koszt pamięci, przestrzeni dyskowej i utrzymania warstwy sterowania maszynami wirtualnymi, wymagaj co najmniej jednego bieżącego 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 pakują aplikacje wraz z ich zależnościami. Maszyny wirtualne zawierają jądro gościa oraz emulują sprzęt lub przypisują go bezpośrednio. porównanie techniczne granic kontenerów i maszyn wirtualnych wyjaśnia, dlaczego mniejszy narzut kontenerów i silniejsza separacja gości wynikają z różnych architektur, a nie z uniwersalnego rankingu jakości.

Podejście oparte na kontenerach jest wydajne, gdy usługi mogą współdzielić jedno załatane środowisko linuksowe i być odtwarzane z plików Compose lub innej deklaratywnej definicji. Podejście oparte na hipernadzorcy jest przejrzystsze, gdy jednego gościa można odbudować, odizolować zaporą lub przywrócić bez traktowania każdej usługi jako części tej samej instancji systemu operacyjnego.

Wybór odchodzi od kontenerów, gdy usługa wymaga innego jądra albo model zaufania odrzuca współdzielenie jądra hosta. Wybór odchodzi od hipernadzorcy, gdy każdy gość zawierałby jedynie identyczną instalację Linuksa, której jedynym zadaniem byłoby uruchamianie tych samych zaufanych kontenerów.

Wybierz jednostkę kopii zapasowej i odbudowy

Odbudowa oparta na kontenerach jest szybka tylko wtedy, gdy definicje, sekrety, wersje i woluminy trwałe są rozdzielone i objęte kopią zapasową. Przywracanie oparte na hipernadzorcy jest szybkie tylko wtedy, gdy kopie gości są niezależne od uszkodzonego hosta, a sieć hosta oraz mapowania urządzeń są udokumentowane.

Przetestuj jedną destrukcyjną procedurę odzyskiwania na zapasowej maszynie wirtualnej lub na nośniku zastępczym. Wybierz rozwiązanie, którego dane wejściowe potrafisz wyliczyć i odtworzyć; pulpity i przyciski migawek nie zrekompensują braku kopii przechowywanych poza hostem.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Pozwól, aby zależności sprzętowe i sieciowe ujawniły 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 uprzywilejowane i szerokie mapowania urządzeń osłabiają wąską granicę aplikacji. Hipernadzorca może przypisywać urządzenia gościom, jednak grupy IOMMU, zachowanie podczas resetowania i własność sterowników hosta mogą sprawić, że ta ścieżka będzie niestabilna.

Sieć działa według tego samego schematu. Mosty kontenerowe są kompaktowe dla jednej zaufanej strefy aplikacji; wiele mostów gości i zapór może wyraźniej rozdzielać strefy laboratoryjne, publiczne i infrastrukturalne, ale dodaje też interfejsy oraz stan routingu, które muszą przetrwać odzyskiwanie.

Popularna dyskusja operatorów na temat wyboru Debiana z Dockerem zamiast Proxmoksa pokazuje praktyczną granicę: hipernadzorca jest wartościowy, gdy maszyny wirtualne są rzeczywistym wymaganiem, ale może wydawać się dodatkową komplikacją, gdy serwer uruchamia wyłącznie kontenery.

Zacznij prosto, ale określ warunek migracji

Wybierz podejście oparte na kontenerach, gdy wszystkie planowane usługi mieszczą się w jednym zaufanym jądrze Linuksa, pamięć jest ograniczona, a dane aplikacji wraz z plikami wdrożeniowymi tworzą przetestowaną jednostkę odzyskiwania. Utrzymuj host bazowy w minimalnej postaci, aby późniejsze dodanie wirtualizacji lub migracja do niej pozostały możliwe.

Wybierz podejście oparte na hipernadzorcy, gdy plan na pierwszy rok obejmuje co najmniej dwóch gości z różnymi jądrami, strefami zaufania, harmonogramami wycofywania zmian lub przypisaniami sprzętu. Przewodnik wyboru systemu operacyjnego serwera domowego pomoże potwierdzić, jakich możliwości hosta faktycznie wymaga lista usług.

Wróć do tej decyzji, gdy pojawi się niekompatybilny system operacyjny, ryzykowne obciążenie publiczne, powtarzalne środowisko laboratoryjne lub wymaganie odzyskiwania całego gościa. Nie migruj tylko dlatego, że jedno rozwiązanie jest modne; migruj, gdy zmienia się konkretna, nazwana granica.