Hypervisor eerst versus containers eerst voor een nieuwe homeserver

Begin met containers als uitgangspunt als het plan voor het eerste jaar één vertrouwde Linux-applicatiestack omvat; begin met een hypervisor als uitgangspunt als het plan al afzonderlijke besturingssystemen, labs die vaak veranderen of vertrouwensgrenzen omvat waarvoor volledige gastmachines nodig zijn.

Dit is een keuze over de beheerlaag van de server, niet over de vraag of containers en virtuele machines naast elkaar kunnen bestaan. Een host met een hypervisor als uitgangspunt kan Docker in een VM uitvoeren, terwijl een Linux-host met containers als uitgangspunt later KVM kan toevoegen. De juiste standaardkeuze is de laag waarvan de back-up- en storingsgrenzen aansluiten op de workloads die je vandaag kunt benoemen.

Breng de workloads in kaart voordat je een beheerlaag kiest

Noteer per geplande dienst de vereisten voor het besturingssysteem, de gegevenslocatie, hardwaretoegang, blootstelling en de aanvaardbare omvang van een herstart. Markeer alle Windows- of BSD-gastmachines, experimentele kernels, niet-vertrouwde code of openbare diensten waarvan een inbreuk niet ook de applicatiehost in gevaar mag brengen.

Bestaat de lijst vrijwel geheel uit onderhouden Docker-images voor één Linux-kernel, dan bieden containers al verpakkingen, netwerken, herstartbeleid en resourcebeheer. Bevat de lijst meerdere besturingssystemen of labs die vaak veranderen, dan biedt een hypervisor een natuurlijkere grens voor de levenscyclus.

Tel ideeën niet mee als workloads. Eis minstens één actuele taak waaraan containers niet goed kunnen voldoen voordat je betaalt voor het geheugen, de opslag en het onderhoud van een VM-beheerlaag.

Vergelijk de isolatie met de eenheid die je daadwerkelijk beheert

Containers delen de hostkernel en bundelen applicaties met hun afhankelijkheden. Virtuele machines bevatten een gastkernel en emuleren hardware of wijzen hardware toe. Een technische vergelijking van de grenzen tussen containers en VM's legt uit waarom de lagere overhead van containers en de sterkere scheiding van gastmachines voortkomen uit verschillende architecturen en geen universele kwaliteitsrangschikking vormen.

Containers als uitgangspunt zijn efficiënt wanneer diensten één gepatchte Linux-host kunnen delen en opnieuw kunnen worden aangemaakt op basis van Compose-bestanden of een andere declaratieve definitie. Een hypervisor als uitgangspunt is overzichtelijker wanneer één gastmachine opnieuw kan worden opgebouwd, met een firewall kan worden afgeschermd of kan worden teruggezet zonder elke dienst als onderdeel van dezelfde instantie van het besturingssysteem te behandelen.

De keuze slaat om tegen containers wanneer een dienst een andere kernel nodig heeft of het vertrouwensmodel het delen van de hostkernel afwijst. De keuze slaat om tegen een hypervisor wanneer elke gastmachine slechts een identieke Linux-installatie zou bevatten die alleen dezelfde vertrouwde containers hoeft te starten.

Kies de eenheid voor back-up en herbouw

Een herbouw met containers als uitgangspunt is alleen snel als definities, geheimen, versies en persistente volumes gescheiden zijn en er back-ups van worden gemaakt. Een herstel met de hypervisor als uitgangspunt is alleen snel als back-ups van gastmachines onafhankelijk zijn van de defecte host en de netwerkconfiguratie van de host of apparaatkoppelingen zijn gedocumenteerd.

Test één destructief herstel in een reserve-VM of vanaf vervangende media. Kies de aanpak waarvan je de benodigde onderdelen kunt opsommen en herstellen; dashboards en snapshotknoppen maken ontbrekende externe kopieën niet goed.

Featured

ZimaCube 2 persoonlijke cloud-home-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Laat zien wat er nog meer nodig is door hardware- en netwerkafhankelijkheden bloot te leggen

GPU's, USB, HBA's en speciale netwerkkaarten kunnen rechtstreeks worden gebruikt op een host die eerst op containers is gericht, maar bevoorrechte containers en ruime apparaattoewijzingen verzwakken de strikte afbakening van toepassingen. Een hypervisor kan apparaten aan gasten toewijzen, maar IOMMU-groepen, resetgedrag en het eigenaarschap van hostdrivers kunnen die aanpak kwetsbaar maken.

Voor netwerken geldt hetzelfde patroon. Containerbridges zijn compact voor één vertrouwde toepassingszone; meerdere gastbridges en firewalls kunnen lab-, openbare en infrastructuurzones duidelijk afbakenen, maar voegen ook interfaces en routeringsinstellingen toe die na herstel behouden moeten blijven.

Een discussie met veel deelnemers over kiezen voor Debian met Docker in plaats van Proxmox illustreert het praktische onderscheid: de hypervisor is waardevol wanneer VM's echt nodig zijn, maar kan als extra ballast voelen wanneer de server alleen containers uitvoert.

Begin eenvoudig, maar bepaal wanneer je migreert

Kies eerst voor containers als alle geplande diensten op één vertrouwde Linux-kernel passen, het geheugen beperkt is en toepassingsgegevens plus implementatiebestanden samen een geteste hersteleenheid vormen. Houd de basishost minimaal, zodat virtualisatie later nog kan worden toegevoegd of gemigreerd.

Kies eerst voor een hypervisor als het plan voor het eerste jaar twee of meer gasten met verschillende kernels, vertrouwenszones, terugdraaischema's of hardwaretoewijzingen omvat. De keuzehandleiding voor besturingssystemen voor thuisservers kan helpen bevestigen welke hostmogelijkheden de dienstenlijst daadwerkelijk vereist.

Keer opnieuw naar de keuze wanneer er een incompatibel besturingssysteem, een risicovolle openbare workload, een reproduceerbare labomgeving of een vereiste voor herstel van een volledige gast verschijnt. Migreer niet alleen omdat een bepaalde aanpak populair is; migreer wanneer een concreet afbakeningscriterium verandert.