NAS of server? Een server koopt je vooral flexibiliteit

Een server vervangen door een NAS lijkt op papier vaak een eenvoudige besparing.

Minder hardware. Minder stroomverbruik. Een compact toestel voor opslag, backups en eventueel enkele extra toepassingen.

Tot een bedrijf meer van die NAS begint te verwachten.

Dan verandert de vraag.

Heb je werkelijk een server vervangen door een NAS, of heb je alleen de opslag vervangen en de rest van de infrastructuur over het hoofd gezien?

Voor mij is dat de kern van de beslissing.

De juiste vraag is daarom niet: “NAS of server?”

De juiste vraag is:

“Welke workloads moet deze infrastructuur ondersteunen?”

Een NAS is vandaag veel meer dan opslag

NAS staat voor Network Attached Storage. In de basis is het een opslagplatform dat bestanden via het netwerk beschikbaar maakt aan gebruikers en systemen.

Moderne NAS-systemen kunnen echter veel meer.

Sommige modellen ondersteunen virtualisatie. QNAP biedt bijvoorbeeld Virtualization Station, een KVM-gebaseerde hypervisor waarmee virtuele machines op bepaalde x86-NAS-systemen kunnen draaien.

Een NAS kan ook integreren met Microsoft Active Directory. Een QNAP NAS kan bijvoorbeeld lid worden van een Active Directory-domein en domeingebruikers en groepen gebruiken voor toegangsbeheer.

Daardoor is de klassieke vergelijking tussen een NAS en een server te beperkt.

Een NAS kan vandaag een belangrijk infrastructuurplatform zijn.

De vraag is hoeveel verantwoordelijkheden je dat platform wilt geven.

Het probleem ontstaat wanneer “alleen bestanden” niet echt alleen bestanden betekent

Ik zie vooral een risico wanneer een bedrijf een server vervangt door een goedkope NAS omdat de server volgens de offerte of de gebruiker “alleen maar bestanden deelt”.

Die conclusie vraagt eerst een grondige inventarisatie.

Een server kan ondertussen ook functioneren als:

• applicatieserver
• databaseserver
• domain controller
• printserver
• monitoringplatform
• virtualisatieplatform
• back-upserver
• platform voor een specifieke bedrijfsapplicatie
• Linux-service of containeromgeving

Microsoft Windows Server ondersteunt bijvoorbeeld Active Directory, SMB, opslagfuncties, Hyper-V, containers, clustering en verschillende netwerkdiensten.

Wanneer je tijdens een migratie alleen naar de bestanden kijkt, kunnen de andere workloads gemakkelijk verdwijnen uit de analyse.

De NAS wordt vervolgens het nieuwe centrale platform.

Daar ontstaat een architectuurvraag.

Een NAS kan veel. Dat betekent niet dat je alles erop moet draaien.

Een modern x86-NAS kan virtuele machines ondersteunen. QNAP documenteert bijvoorbeeld ondersteuning voor Windows Server en verschillende Linux-distributies binnen Virtualization Station.

Dat maakt een NAS technisch interessanter dan het klassieke beeld van een eenvoudige vier-bay opslagbox.

Maar technische mogelijkheid en geschikte architectuur zijn twee verschillende vragen.

CPU-capaciteit, RAM, storage I/O, netwerkinterfaces, uitbreidbaarheid en softwaremogelijkheden bepalen samen welke workloads je verantwoord kunt uitvoeren.

Een NAS met voldoende resources kan een uitstekende infrastructuurcomponent zijn.

Een goedkoop NAS-model waarop vervolgens een database, meerdere virtuele machines, containers en bedrijfsapplicaties worden geplaatst omdat “het allemaal kan”, vraagt een andere beoordeling.

Het aantal workloads neemt toe. De afhankelijkheid van één platform neemt toe. De impact van een storing verandert mee.

Active Directory verdwijnt niet omdat je een NAS gebruikt

Een NAS kan vandaag integreren met Active Directory.

Dat betekent bijvoorbeeld dat gebruikers en groepen uit het domein kunnen worden gebruikt om toegang tot bestanden en shares te regelen.

Maar een NAS die lid is van een Active Directory-domein, vervangt daarmee nog geen Active Directory Domain Services.

AD DS beheert onder meer gebruikers, computers en andere netwerkobjecten. Microsoft beschrijft AD DS bovendien als een gedistribueerde directorydienst met replicatie tussen domain controllers.

De rollen zijn dus verschillend.

Een NAS kan gebruikmaken van Active Directory.

Een NAS die aan Active Directory gekoppeld is, is daarmee nog geen domain controller.

Dat verschil moet tijdens een infrastructuurontwerp expliciet worden gemaakt.

De migratie is meer dan bestanden kopiëren

Een server naar een NAS migreren lijkt eenvoudig wanneer je alleen naar de data kijkt.

In werkelijkheid kunnen ook rechten, bestandsstructuren, applicaties en gebruikersverwachtingen onderdeel zijn van de migratie.

Ik heb zelf ervaren dat een datamigratie veel meer kan zijn dan bestanden van A naar B kopiëren.

Bij een migratie naar Microsoft SharePoint kunnen bijvoorbeeld bestandsnamen en mappenstructuren problemen veroorzaken. Verboden tekens, foutieve naamgeving en wijzigingen tijdens de migratie kunnen ervoor zorgen dat een eenvoudige kopie niet volstaat.

In een eerdere migratie heb ik daarom eerst bestandsnamen moeten voorbereiden en vervolgens meerdere synchronisatiefasen gebruikt.

Hetzelfde principe geldt bij een server naar NAS-migratie.

Je migreert geen schijven.

Je migreert data, rechten, afhankelijkheden, gebruikersverwachtingen en soms applicaties.

Een folderstructuur met honderden mappen en duizenden bestanden kan technisch perfect gekopieerd zijn en toch functionele problemen veroorzaken.

De prijs van een NAS staat niet op de doos

Een NAS van bijvoorbeeld €1.000 vergelijken met een server van €3.000 zegt weinig over de totale kost van de oplossing.

Ik kijk liever naar de volledige infrastructuur.

Welke workloads moet het systeem ondersteunen?

Hoeveel capaciteit is nodig?

Welke CPU- en RAM-resources zijn nodig?

Welke storage I/O is vereist?

Welke netwerkcapaciteit heb je nodig?

Hoe wordt de omgeving geback-upt?

Welke redundantie is nodig?

Hoe wordt het systeem gemonitord?

Welke licenties zijn nodig?

Wie levert support?

Hoe kan het systeem later worden uitgebreid?

En vooral:

Wat gebeurt er wanneer dit systeem uitvalt?

Een NAS die uitsluitend een secundaire kopie van data bevat, heeft een ander risicoprofiel dan een NAS waarop het volledige bedrijf afhankelijk is van één platform.

Dat verschil staat meestal niet op de offerte.

Denk ook na over vendor lock-in

Een NAS bestaat uit meer dan een aantal harde schijven.

Je krijgt te maken met een combinatie van hardware, firmware, storageconfiguratie en beheersoftware. De mogelijkheden om schijven later in een ander platform te gebruiken, verschillen per fabrikant en configuratie.

Daarom stel ik vóór een aankoop graag twee vragen:

Hoe krijg ik mijn data terug als deze fabrikant morgen verdwijnt?

En:

Kan ik deze data herstellen zonder exact hetzelfde toestel?

Dat zijn voor mij relevantere vragen dan alleen:

“Hoeveel terabytes krijg ik voor mijn geld?”

Er bestaan ook NAS-systemen waarbij je veel meer controle over het platform krijgt.

x86-hardware kan bijvoorbeeld met een ander besturingssysteem worden uitgerust. In mijn eigen ervaring is dat interessant wanneer ik maximale controle wil over hardware, Linux, storage en netwerkfunctionaliteit.

Op dat moment wordt een NAS technisch gezien steeds meer een compact serverplatform waarbij storage een belangrijke functie is.

Dat kan interessant zijn.

Maar dan komen beheer, kennis, support en continuïteit opnieuw in beeld.

Een oplossing die alleen goed functioneert zolang één specifieke engineer weet hoe alles is opgebouwd, creëert een andere bedrijfsafhankelijkheid.

Soms is een NAS precies de juiste keuze

Ik zou een NAS daarom zeker niet afschrijven.

Voor een organisatie die voornamelijk centrale bestandsopslag en backups nodig heeft, kan een NAS een zeer geschikte oplossing zijn.

Ook als storageplatform binnen een bredere infrastructuur kan een NAS logisch zijn.

Mijn voorkeur gaat vaak uit naar het scheiden van functies wanneer de bedrijfsvereisten dat rechtvaardigen.

Storage waar storage thuishoort.

Applicaties waar applicaties thuishoren.

Virtualisatie op een platform dat daarvoor ontworpen en gedimensioneerd is.

Identity als aparte infrastructuurfunctie wanneer die nodig is.

Dat kan op meerdere fysieke systemen.

Het kan ook op één fysiek platform wanneer de architectuur, redundantie, prestaties en continuïteitsvereisten dat toelaten.

De technologie volgt de architectuur.

Een server koopt je vooral flexibiliteit

Dat is voor mij uiteindelijk het belangrijkste verschil.

Een server geeft je doorgaans meer vrijheid om verschillende workloads te combineren, te virtualiseren, resources toe te wijzen en later andere toepassingen te ondersteunen.

Die flexibiliteit heeft een prijs.

Een NAS kan goedkoper, eenvoudiger en energiezuiniger zijn wanneer de workload beperkt blijft tot wat het platform daarvoor moet doen.

Een server kan interessanter worden wanneer je meerdere workloads, toekomstige uitbreidingen of specifieke softwarevereisten moet ondersteunen.

Daarom zou ik de keuze niet beginnen met een product.

Ik zou beginnen met de workloads.

Welke infrastructuur heeft je bedrijf de komende drie tot vijf jaar nodig?

Dat is de vraag die ik zou stellen voordat een server wordt vervangen.

Daarna kun je bepalen welke technologie daarbij past.

Dat kan een klassieke server zijn.

Dat kan een NAS zijn.

Dat kan een server plus NAS zijn.

Het kan ook een NAS met virtualisatie zijn.

Voor bepaalde bedrijven kan een groot deel van de workloads beter naar een cloudplatform of datacenter verhuizen.

De vormfactor is uiteindelijk een gevolg van de architectuur.

Dat sluit aan bij hoe ik naar infrastructuur kijk: technologie moet de bedrijfsstrategie ondersteunen.

Consolidatie kan zinvol zijn wanneer je het aantal systemen kunt verminderen zonder continuïteit, beveiliging of prestaties te verslechteren.

Mijn checklist vóór je een server door een NAS vervangt

Voor ik zo’n beslissing neem, wil ik minstens deze vragen beantwoorden.

1. Welke workloads draaien vandaag op de server?

Kijk niet alleen naar bestanden.

Inventariseer alles wat op het systeem draait en waarvan gebruikers of applicaties afhankelijk zijn.

2. Welke workloads moeten over drie jaar nog bestaan?

Een migratie is een goed moment om oude applicaties en diensten kritisch te bekijken.

Misschien moet een bepaalde workload helemaal niet naar de NAS.

Misschien moet ze helemaal verdwijnen.

3. Welke prestaties zijn werkelijk nodig?

CPU, RAM, storage I/O en netwerkcapaciteit moeten gebaseerd zijn op de workload.

Niet op het aantal bays.

Niet op het aantal terabytes.

4. Wat gebeurt er bij hardwarefalen?

Bepaal RTO en RPO voordat je de hardware kiest.

Hoe lang mag een dienst onbeschikbaar zijn?

Hoeveel data mag je maximaal verliezen?

Die antwoorden bepalen mee welke architectuur nodig is.

5. Hoe herstel je de data zonder het originele NAS-platform?

Test het herstel.

Een backup die nooit getest werd, is geen bewezen herstelstrategie.

6. Wie beheert het systeem?

Een eenvoudig toestel kan nog altijd een bedrijfskritische afhankelijkheid worden.

Documentatie, kennis en beheerbaarheid horen daarom bij de architectuurkeuze.

7. Wat kost de oplossing over vijf jaar?

Kijk naar hardware, storage, licenties, elektriciteit, support, beheer en vervanging.

Een lagere aankoopprijs betekent niet automatisch een lagere totale kost.

Dus: NAS of server?

Misschien was de NAS nooit het probleem.

De vraag waarmee de beslissing werd genomen, kan het echte probleem zijn.

“Hoeveel opslag hebben we nodig?” is een storagevraag.

“Welke infrastructuur heeft ons bedrijf nodig?” is een architectuurvraag.

Dat verschil kan duizenden euro’s en veel operationele problemen bepalen.

Heb jij ooit een server vervangen door een NAS en daar later spijt van gekregen?

Of heeft een NAS bij jouw bedrijf juist jarenlang perfect gewerkt?

Ik ben vooral benieuwd naar de workload achter die beslissing.