Managed vs unmanaged VPS: wat is de juiste keuze?

Managed versus unmanaged VPS: het korte antwoord

De keuze tussen een managed en een unmanaged VPS is een vraagstuk over arbeidsinzet, niet over het product zelf. Unmanaged betekent dat u zelf verantwoordelijk bent voor patching, de firewall, back-ups, monitoring en de herstart om 02:00 uur 's nachts. Managed betekent dat de provider een deel van deze taken voor u uitvoert, waarbij de omvang van dit deel enorm verschilt per host. De enige zinvolle vergelijking is de lijst met taken die elk abonnement u uit handen neemt, afgezet tegen uw eigen uurtarief.

Er bestaat geen standaarddefinitie voor de term managed. Bij de ene host betekent het dat het besturingssysteem wordt gepatcht en dat een medewerker uw supporttickets beantwoordt. Bij de andere betekent het dat er een configuratiescherm is geïnstalleerd en dat alles daarboven uw eigen verantwoordelijkheid is. Een derde partij biedt een schriftelijk servicecontract met een gegarandeerde responstijd. Twee abonnementen met dezelfde benaming kunnen op elk essentieel punt verschillen; lees daarom het document met de scope voordat u naar de prijs kijkt. Als u nog moet bepalen waarvoor de machine precies dient, is wat u daadwerkelijk met een VPS kunt doen de betere vraag om eerst te beantwoorden.

De taken waarvoor iemand verantwoordelijk moet zijn

Elke draaiende server brengt dezelfde lijst met werkzaamheden met zich mee. Bij een onbeheerd abonnement is die lijst voor u. Bij een beheerd abonnement betaalt u om taken van die lijst te schrappen. Loop de lijst na en schrijf bij elk punt een naam.

• Het patchen van het besturingssysteem en de reboots die kernel-updates vereisen.
• Firewallregels, die correct moeten blijven naarmate u services toevoegt of verwijdert. De basis van de ufw-firewall voor een VPS behandelt de beginconfiguratie.
• SSH-toegang: beheer van sleutels, het uitschakelen van wachtwoordauthenticatie, het intrekken van een sleutel wanneer iemand vertrekt en een manier om weer toegang te krijgen als u uzelf buitensluit.
• Back-ups, een offsite kopie en een herstelprocedure die u daadwerkelijk heeft uitgevoerd.
• Monitoring, wat betekent dat u weet of de server bereikbaar is, of er schijfruimte beschikbaar is, of de service nog draait en of het certificaat niet is verlopen.
• Logboekcontrole en de actie die volgt wanneer er iets verdachts in die logs staat.
• Serviceconfiguratie voor de webserver, de database, de reverse proxy en de wachtrij, indien u deze gebruikt.
• Certificaatvernieuwing en het herstel wanneer automatische vernieuwing niet meer werkt.
• Capaciteitsbeheer, wat betekent dat u merkt dat het geheugen vol raakt voordat de out of memory (OOM) killer dat voor u doet.
• Incidentrespons, wat betekent dat u wakker en bereikbaar bent op een tijdstip dat u niet zelf kiest.

De meeste van deze taken zijn routinematig en kunnen door een script worden uitgevoerd. Incidentrespons is de enige taak die dat niet kan, omdat hiervoor een persoon nodig is die beslissingen kan nemen. Dat is het werkelijke product dat een beheerd abonnement verkoopt; daarom besteedt de onderstaande checklist het grootste deel van de vragen aan de ondersteuningsomvang in plaats van aan het patchen.

Wat managed beheer doorgaans niet omvat

Dit is waar kopers vaak de mist in gaan, dus wees hierover nauwkeurig. Een managed contract dekt normaal gesproken het besturingssysteem en de software die de provider heeft geïnstalleerd. Het stopt bij de grens van uw applicatie.

Uw eigen code is uw verantwoordelijkheid. Een 500-foutmelding vanuit uw applicatie is geen serverfout. De provider bevestigt dat het webserverproces draait en geeft het ticket vervolgens terug. Dat is een redelijke grens. Het is tevens het grootste verschil tussen wat kopers verwachten en wat zij hebben aangeschaft.

Problemen op applicatieniveau vallen meestal buiten de scope. Een trage databasequery, een plugin die na een update niet meer werkt, een verkeerd geconfigureerde cache of een mailwachtrij die niet meer wordt verwerkt: deze zaken bevinden zich boven de grens, zelfs als de provider de onderliggende software heeft geïnstalleerd.

Het merendeel van dataherstel valt buiten de scope. Back-ups van de provider beschermen de image van de gehele server en zijn bedoeld voor situaties waarin de host-hardware faalt. Ze zijn zelden ontworpen voor situaties waarin u zes weken geleden een rij hebt verwijderd, een foutieve migratie hebt uitgevoerd of een bestand hebt beschadigd en dit pas vandaag opmerkt. Vraag naar de bewaartermijn, of een enkel bestand kan worden teruggehaald en wie het herstel uitvoert.

Software die u zelf hebt geïnstalleerd, is uw verantwoordelijkheid. Installeert u Docker, dan is de provider doorgaans verantwoordelijk voor de host, terwijl u verantwoordelijk bent voor alles binnen de containers.

Handmatige wijzigingen kunnen de ondersteuning ongeldig maken. Sommige contracten sluiten een component uit van de ondersteuning zodra een klant de configuratie ervan direct heeft aangepast. Vraag hiernaar als u van plan bent om zelf instellingen te optimaliseren.

Weeg uw eigen tijd af tegen het maandelijkse verschil

Neem de twee offertes die voor u liggen en noteer het maandelijkse prijsverschil. Dat bedrag is wat de provider in rekening brengt om de taken uit de bovenstaande lijst uit handen te nemen. Bepaal nu wat dit voor u waard is.

• Wat is een uur van uw tijd waard en hoeveel uur per maand kost die lijst zodra deze is geautomatiseerd?
• Wat kost één uur downtime voor de applicatie die op deze server draait?

Een stabiele Ubuntu-server met automatische updates en externe monitoring vereist zeer weinig routineonderhoud. De meeste maanden is er helemaal geen onderhoud nodig. Routinewerk is goedkoop zodra een script het uitvoert. Onderbrekingen zijn het kostbare onderdeel, en onderbrekingen zijn precies wat een managed plan verkoopt. Als de server een hobbyproject draait, kost een storing niets en is een onmanaged server de logische keuze. Als de server bestellingen verwerkt, onderzoek dan kritisch of een supportcontract een storing daadwerkelijk verkort, aangezien een managed provider nog steeds uw ticket moet lezen, de fout moet reproduceren en actie moet ondernemen.

Het verschil schaalt ook mee met het aantal servers. Managed-kosten worden meestal per server berekend, terwijl automatisering eenmalig wordt geschreven en gekopieerd. De tweede server halveert de effectieve kosten van het script dat u voor de eerste schreef. Lees daarom hoe u meerdere Linux-servers beheert voordat u zich vastlegt aan een vergoeding per server. Voor de basisbedragen aan beide kanten van de vergelijking bepaalt wat een VPS daadwerkelijk per maand kost de ondergrens, en de afweging tussen VPS en dedicated server is van belang zodra de werklast groot genoeg is dat de meerprijs voor managed services verwaarloosbaar wordt.

Vragen voor een host voordat u betaalt voor de managed premium-dienst

Stel deze vragen voordat u betaalt en vraag om de antwoorden op schrift. Een verkooppagina is geen document met de projectomvang.

1. Wat valt er precies onder de dienstverlening, taak voor taak? Vraag om de lijst, niet om de brochure.
2. Omvat de ondersteuning software die ik zelf installeer, of alleen software die door u is geïnstalleerd?
3. Past u automatisch patches toe en herstart u de server voor kernel-updates zonder mij vooraf te vragen?
4. Wie is er verantwoordelijk als een door u toegepaste patch mijn applicatie onklaar maakt?
5. Maakt u back-ups? Waar worden deze opgeslagen, hoe lang worden ze bewaard en wie voert een herstel uit?
6. Heeft u onlangs een klantserver hersteld en hoe lang duurde dat?
7. Wat is de responstijd voor tickets en is deze anders op zondag om 03:00 uur?
8. Behoud ik root-toegang en vermindert het gebruik daarvan de ondersteuning die u biedt?
9. Worden de kosten per server of per account in rekening gebracht?
10. Wat neem ik mee als ik vertrek? Een configuratie die afhankelijk is van een eigen controlepaneel kan lastig te exporteren zijn.

Vraag 5 is bepalend voor de meeste andere vragen. Een host die hier nauwkeurig op antwoordt, geeft aan dat dit proces al eerder is uitgevoerd. Een vaag antwoord betekent dat het herstel nooit is getest, en een niet-geteste back-up is slechts een kopie. Vraag 5 heeft ook een locatiecomponent: waar de kopieën zich fysiek bevinden is zowel een juridische als een technische kwestie, en wat er werkelijk toe doet bij het kiezen van een hostingland gaat hier dieper op in.

De middenweg: unmanaged met automatisering

De meeste technische lezers willen geen van beide extremen. Ze willen een unmanaged plan waarbij het routinewerk door de machine wordt gedaan, terwijl hun eigen aandacht uitgaat naar zaken die een machine niet kan beoordelen. Richt dit op de eerste dag in. De eerste tien minuten op een nieuwe VPS is het praktische startpunt voor iedereen die voor unmanaged kiest, en SSH-toegang beveiligen hoort bij diezelfde eerste sessie.

Automatische beveiligingsupdates

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Dat bestand zou nu APT::Periodic::Update-Package-Lists "1"; en APT::Periodic::Unattended-Upgrade "1"; moeten bevatten. Een ontbrekend bestand, of een 0 op een van beide regels, betekent dat er niets wordt uitgevoerd en dat u geen melding ontvangt.

Test het zonder het systeem te wijzigen. Let op dat het pakket unattended-upgrades is, terwijl het commando enkelvoudig is:

sudo unattended-upgrade --dry-run --debug

De uitvoer toont elk pakket dat is overwogen en eindigt met een regel zoals No packages found that can be upgraded unattended wanneer er niets in de wachtrij staat. Echte runs worden naar /var/log/unattended-upgrades/unattended-upgrades.log geschreven, dus controleer daar in plaats van te gissen.

Een kernel-update wijzigt niets totdat de machine opnieuw opstart, omdat de actieve kernel de kernel is die bij het opstarten is geladen. Het bestand /var/run/reboot-required verschijnt wanneer een herstart in de wachtrij staat. Houd dit bestand in de gaten, of laat de machine het afhandelen in /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" houdt de herstart tegen zolang er iemand is ingelogd; dit is veiliger op een machine die u interactief gebruikt en nutteloos op een machine waar niemand op inlogt. De volledige unattended upgrades-configuratie op Ubuntu behandelt de blocklist-syntaxis en de e-mailopties.

Monitoring die ergens anders draait

Een monitor die op de server zelf draait, kan u niet vertellen dat de server offline is, omdat de monitor dan ook offline is. Plaats de controle op een tweede host of op een externe dienst. Uptime Kuma voor statusmonitoring is het gebruikelijke zelfgehoste antwoord, en dit hoort op een andere machine te staan dan de machine die het controleert.

Controleer minimaal vier zaken: bereikbaarheid, schijfgebruik, of de applicatie antwoordt op de juiste poort en het verlopen van certificaten. Schijfruimte is het punt waar mensen vaak de mist in gaan. Een logbestand of database die elke dag een beetje groeit, legt de machine plat op een moment dat niemand het verwacht, en het eerste symptoom is vaak een service die niet kan schrijven en afsluit.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Voeg ook een heartbeat toe. Een timer op de server roept een URL aan na elke succesvolle back-up of gezondheidscontrole, en de monitor waarschuwt wanneer die aanroep stopt. Een stille server genereert dan zelf een waarschuwing, wat een pull-only controle niet kan doen wanneer het netwerkpad zelf het probleem is.

Back-ups die u ten minste één keer hebt hersteld

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init print created restic repository <id> at sftp:... één keer. Het uitvoeren hiervan tegen een repository die al bestaat, mislukt in plaats van deze te overschrijven; dat is het gewenste gedrag. Bewaar een kopie van die passphrase ergens buiten de server: de repository is onleesbaar zonder deze sleutel en er is geen herstelpad.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots zou de run moeten tonen die u zojuist hebt gemaakt met de datum van vandaag. restic check verifieert de repository-structuur en print no errors were found. Doe nu het onderdeel dat de meeste mensen overslaan:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

Het bestand dat u verwachtte staat er wel of niet, en het nu uitzoeken kost tien minuten. Zet de run vervolgens op een timer zodat deze niet van u afhankelijk is. Schrijf /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

En /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers toont de volgende run en de resterende tijd. Een leeg resultaat betekent dat u de service hebt ingeschakeld in plaats van de timer; dit is de meest gemaakte fout hier. Persistent=true voert een gemiste taak uit na de volgende boot, zodat een machine die 's nachts uitstond alsnog zijn back-up krijgt. Restic-back-ups op een VPS gaat dieper in op de repository-indeling en retentie, en systemd-services en timers legt de unit-bestanden regel voor regel uit.

Wat automatisering u niet oplevert

Het levert u geen beoordelingsvermogen op. Een automatische herstart om 02:00 uur vindt plaats, ongeacht of uw applicatie correct opstart. Controleer daarom of elke service zelfstandig start en voer daarna bewust een herstart uit terwijl u wakker bent:

systemctl is-enabled nginx docker
sudo reboot

Een unattended upgrade kan ook een pakket installeren dat uw applicatie breekt, en niets in de pipeline weet dat dit is gebeurd. Uw monitor is wat dit opvangt, en daarom is de monitor niet optioneel zodra updates automatisch verlopen. De machine dekt het routinewerk af. Het incident blijft uw verantwoordelijkheid.

Wanneer managed de investering waard is

Wees eerlijk over de managed-kant. Vier situaties maken dit de juiste aankoop.

• Niemand in het team beheert Linux en het aannemen van iemand is niet de bedoeling.
• Een compliance-vereiste wijst een partij aan die verantwoordelijk is voor patching, en die partij kunt u niet zijn.
• De stack is er een waarin de host gespecialiseerd is, waardoor hun support uw fout al eerder heeft gezien.
• De persoon die het werk anders zou doen, is uw duurste werknemer, en één uur van hun tijd kost meer dan een maand van de premium-prijs.

Managed is niet automatisch veiliger. Managed-abonnementen patchen sneller dan een onoplettende eigenaar, en dat is een reële winst. Ze installeren ook vaak een configuratiescherm, wat een grote, naar het netwerk gerichte applicatie is met een inlogpagina en een eigen kwetsbaarhedengeschiedenis. Dat kan een redelijke afweging zijn, maar het blijft een afweging.

De beslissing komt elke keer op hetzelfde lijstje neer. Schrijf de tien taken op, markeer wie voor elke taak verantwoordelijk is onder elke offerte, en vergelijk het verschil met wat een uur van uw aandacht waard is. De meeste technische lezers die dit doen, eindigen bij unmanaged met de routine overgedragen aan een timer, en dat is een verdedigbaar antwoord in plaats van een goedkoop antwoord.

FAQ

Wat is het verschil tussen een managed en een unmanaged VPS?

Een unmanaged VPS levert u enkel de machine; u bent zelf verantwoordelijk voor patching, de firewall, back-ups, monitoring en het herstarten na een kernel-update. Bij een managed VPS neemt de provider een deel van dit werk over, meestal op het niveau van het besturingssysteem en de door hen geïnstalleerde software. De exacte grens wordt door elke provider anders bepaald; vraag daarom vóór het vergelijken van prijzen schriftelijk naar de specifieke taken die onder het beheer vallen.

Betekent een managed VPS dat ik geen eigen back-ups nodig heb?

Nee. Back-ups van de provider beschermen doorgaans de image van de gehele server en zijn bedoeld voor situaties waarin de host faalt. Ze bieden zelden uitkomst als u zelf een bestand heeft verwijderd, een foutieve migratie heeft uitgevoerd of weken geleden data heeft beschadigd die u vandaag pas opmerkt. Vraag hoe lang snapshots worden bewaard, of een enkel bestand kan worden hersteld en wie het herstel uitvoert. Zorg daarnaast voor een eigen offsite kopie met een tool zoals restic en test deze met restic restore latest --target /tmp/restore-check zodat u zeker weet dat het werkt.

Is een managed VPS veiliger dan een unmanaged VPS?

Niet per definitie. Een managed plan wordt sneller gepatcht dan een server van een eigenaar die nooit inlogt, wat het risico daadwerkelijk verkleint. Veel managed plannen installeren echter ook een control panel; dit is een grote applicatie die naar het internet is gericht, met een eigen inlogpagina en een eigen geschiedenis van kwetsbaarheden. Een unmanaged server met automatische beveiligingsupdates, een gesloten firewall, SSH enkel via keys en zonder extra actieve services is een kleiner doelwit dan een managed server die een control panel draait.

Kan ik beginnen met unmanaged en later overstappen naar managed?

Meestal wel, al is dit zelden een kwestie van één druk op de knop. Providers voeren vaak een audit uit of bouwen een server opnieuw op voordat ze de verantwoordelijkheid overnemen, omdat ze geen ondersteuning kunnen bieden voor een configuratie die zij niet kennen. Vraag wat de onboarding inhoudt, of een herinstallatie nodig is en of zaken die u zelf heeft geconfigureerd daarna buiten de ondersteuning vallen.

Behoud ik root-toegang op een managed VPS?

Bij de meeste managed VPS-plannen wel, maar root-toegang en de reikwijdte van de ondersteuning beïnvloeden elkaar. Sommige providers beperken of laten de ondersteuning vervallen voor componenten die u handmatig heeft aangepast, en sommige zullen de server terugzetten naar hun eigen template als een supportticket te complex wordt. Leg deze regels schriftelijk vast voordat u wijzigingen doorvoert en beheer uw configuratiebestanden in versiebeheer, zodat een herinstallatie u slechts een uur kost in plaats van een heel weekend.