[email protected]+31 20 369 1191SupportNL EN

Author: Murat Bayhan

Datacentercolocatie: volg de faaldomeinen, niet de featurelijst

Lees hoe u datacentercolocatie beoordeelt op faaldomeinen, vermogensdichtheid, netwerkdiversiteit, operationele controle, Remote Hands en multi-site veerkracht.

Datacenterinfrastructuur die colocatie, connectiviteit en een veerkrachtig multi-site ontwerp weergeeft

Het kiezen van een colocatiedatacenter lijkt een facilitaire beslissing totdat de eerste serieuze afhankelijkheid zichtbaar wordt. Een rack kan redundante stroomvoorziening, meerdere carriers, 24/7 ondersteuning en een respectabele SLA hebben, maar de applicatie kan nog steeds uitvallen omdat beide netwerkpaden dezelfde conduit delen, replicatie afhankelijk is van één metropoolregio of vervangende hardware de locatie niet snel genoeg kan bereiken.

De echte beslissing bij het selecteren van een colocatiedatacenter draait om faaldomeinen, operationele controle en de punten waar infrastructuurafhankelijkheden samenkomen.

Daardoor verschuift de colocatiebeslissing van faciliteitsselectie naar infrastructuurontwerp. Rackprijs en gecommuniceerde beschikbaarheid zijn belangrijk, maar vormen slechts een deel van het ontwerp. Infrastructuurarchitecten moeten begrijpen welke workloads er zullen draaien, hoe die workloads communiceren, welke componenten onafhankelijk moeten kunnen blijven functioneren, wie geacht wordt in te grijpen wanneer er iets defect raakt en hoe moeilijk het later zal zijn om de omgeving uit te breiden.

Een faciliteit die goed werkt voor een rack van 4 kW met conventionele servers kan een slechte keuze zijn voor dichte GPU-systemen. Een locatie die ideaal is voor latencygevoelige workloads kan weinig geografische scheiding bieden voor disaster recovery. Een gebouw met veel carriers kan nog steeds concentratierisico creëren als elk circuit via dezelfde fysieke route het gebouw verlaat.

Datacenterselectie begint daarom bij architectuur, niet bij vastgoed.

Definieer workload-, dichtheids- en groeivereisten voor colocatie

Voordat faciliteiten worden vergeleken, moet worden vastgesteld wat de omgeving precies moet ondersteunen. Een enterprise-SaaS-platform, een hostingprovider, een storagecluster en een AI-trainingsomgeving kunnen allemaal standaard 19-inch racks gebruiken, maar hun infrastructuurvereisten verschillen sterk.

Applicatieprestaties bepalen de acceptabele latency. Storagearchitectuur bepaalt de replicatiebandbreedte. Hardwaredichtheid beïnvloedt stroom en koeling. Regelgevingsvereisten beïnvloeden fysieke beveiliging en auditbaarheid. Operationeel eigenaarschap bepaalt of Remote Hands een gemak is of een kernonderdeel van het operationele model.

Ook groeiaannames zijn belangrijk. Veel implementaties worden gedimensioneerd op basis van het huidige aantal racks, terwijl beperkingen die twee jaar later pijnlijk worden buiten beschouwing blijven: extra vermogen per rack, beschikbare cross-connectcapaciteit, grotere netwerkpoorten, aangrenzende rackruimte, opslag voor reserveapparatuur of toegang tot een tweede faciliteit.

Sommige van die beslissingen zijn duur om terug te draaien. De overstap van 10G naar 100G-netwerken is beheersbaar als de onderliggende fiberinfrastructuur en optica dit ondersteunen. Een volledige productieomgeving verplaatsen omdat de faciliteit onvoldoende rackdichtheid kan leveren, is een ander verhaal.

Beoordeel vermogensdichtheid, koeling en rackcapaciteit bij colocatie

De totale vermogenscapaciteit van een faciliteit zegt verrassend weinig over wat uw racks daadwerkelijk kunnen verbruiken.

De relevante vraag is hoeveel geconditioneerd vermogen aan een specifiek rack kan worden geleverd, met het redundantiemodel dat uw workload vereist.

Een faciliteit kan aanzienlijke nutscapaciteit hebben en tegelijkertijd veel lagere limieten hanteren op rij- of rackniveau. UPS-topologie, distributiearchitectuur, dimensionering van stroomonderbrekers, generatorcapaciteit, onderhoudsprocedures en koelcapaciteit beïnvloeden allemaal de bruikbare dichtheid.

Dit wordt belangrijker bij AI, HPC, dichte virtualisatie en high-performance storage. Hardware-inkoop kan niet los worden gezien van colocatieplanning. Een serverplatform dat aantrekkelijk lijkt op basis van prijs-prestatieverhouding kan een volledig ander infrastructuurprobleem creëren zodra stroomverbruik, airflow, optica, switchcapaciteit en rackindeling worden meegenomen.

3W Infra past dezelfde denkwijze toe op hardwareplanning en kijkt naast de directe workloadvereisten ook naar toekomstige groei, stroomverbruik, connectiviteit en efficiëntie. Met ervaring in het beheer van meer dan 100 racks ziet 3W Infra dit effect op schaal: kleine verschillen in stroomverbruik per apparaat kunnen binnen één rack of een grotere omgeving oplopen tot meerdere kilowatts.

Dat is het juiste detailniveau. Vermogensplanning hoort thuis in architectuurgesprekken voordat hardware wordt besteld.

Beoordeel redundantie en gedeelde faaldomeinen bij colocatie

Twee exemplaren van iets leveren niet automatisch veerkracht op.

Twee netvoedingen kunnen nog steeds eindigen in dezelfde bovenliggende infrastructuur. Twee netwerkcarriers kunnen via dezelfde meet-me room het gebouw binnenkomen. Twee fibercircuits kunnen voor het grootste deel van hun route dezelfde ducting delen. Twee datacenters kunnen afhankelijk zijn van hetzelfde stedelijke elektriciteitsnet, dezelfde overstromingszone, transportcorridor of cloud-on-ramp.

De nuttige vraag is niet "Is dit redundant?" maar "Wat kan één keer uitvallen en beide paden tegelijk wegnemen?"

Netwerkontwerp verdient extra aandacht omdat logische en fysieke diversiteit gemakkelijk door elkaar worden gehaald. BGP-sessies met meerdere upstreamcarriers verbeteren de routeringsdiversiteit, maar garanderen geen fysieke paddiversiteit. Twee L3-diensten kunnen nog steeds over dezelfde fiber lopen. Ook hebben dubbele cross-connects binnen een faciliteit beperkte waarde als ze samenkomen op één extern pad.

Voor multi-site systemen moeten architecten faaldomeinen vanaf het rack naar buiten in kaart brengen: stroomdistributie, switches, meet-me rooms, fiberroutes, carriers, metropoolregio's, cloudverbindingen en applicatieafhankelijkheden.

De Amsterdamse colocatieopstelling van 3W Infra illustreert dit onderscheid in de praktijk. Onze eigen DWDM-ring verbindt maincubes, Equinix AM11 en Iron Mountain via redundante, onderhoudsbeschermde dark fiber, met zowel Layer 2- als Layer 3-connectiviteit tussen de locaties. Layer 2-links zijn beschikbaar op 10G, 25G, 40G en 100G, terwijl Layer 3-transit wordt geleverd via het eigen autonome systeem (AS) van 3W Infra.

Het gaat er niet alleen om dat meerdere datacenters met elkaar verbonden zijn, maar vooral om hoe die interconnectie is opgebouwd. Fysieke paddiversiteit, fiberrouting, switchingarchitectuur en gedeelde afhankelijkheden bepalen of een multi-site ontwerp het risico daadwerkelijk verlaagt of hetzelfde faaldomein slechts over meerdere locaties verspreidt.

Layer 2 versus Layer 3 voor multi-datacentercolocatie

Het uitbreiden van Layer 2 tussen datacenters kan bepaalde migraties en clusteringontwerpen vereenvoudigen. Het kan faaldomeinen echter ook verder uitbreiden dan verwacht.

Met een stretched VLAN kunnen systemen in verschillende faciliteiten binnen hetzelfde broadcastdomein blijven en hun IP-adressering behouden. Dat kan nuttig zijn wanneer applicaties moeilijk opnieuw te adresseren zijn, wanneer migratie met minimale applicatiewijzigingen moet plaatsvinden of wanneer specifieke clusteringtechnologieën afhankelijk zijn van L2-adjacentie.

De keerzijde is operationele koppeling.

Broadcastproblemen, spanning-treegedrag, problemen met MAC-learning (Media Access Control), onbedoelde loops of fouten in het control plane kunnen dan meer dan één locatie beïnvloeden. Troubleshooting wordt ook moeilijker omdat de fysieke locatie van een workload niet langer eenduidig overeenkomt met de netwerkgrens.

Layer 3-scheiding creëert doorgaans duidelijkere faaldomeinen. Elke locatie beheert zijn eigen subnets, routeringsbeleid bepaalt de bereikbaarheid en BGP (Border Gateway Protocol) of een IGP (Interior Gateway Protocol) kan padselectie en failover regelen. De keerzijde is dat de applicatiearchitectuur routed boundaries moet kunnen verwerken.

Geen van beide benaderingen is per definitie beter. Een hostingplatform dat live migraties uitvoert kan een L2-extensie rechtvaardigen. Een geografisch verspreide SaaS-architectuur kan beter bediend zijn met onafhankelijke L3-domeinen en failover op applicatieniveau.

Het belangrijkste is om deze keuze bewust te maken in plaats van Layer 2 uit te rekken omdat dat tijdens de initiële implementatie eenvoudiger lijkt.

Beoordeel carrierdiversiteit, fiberroutes en datacenterconnectiviteit

Carrierneutraliteit is nuttig, maar het aantal logo's in een meet-me room mag niet worden verward met netwerkarchitectuur.

Ondernemingen moeten beoordelen welke carriers op locatie beschikbaar zijn, hoe cross-connects worden geleverd, of gewenste cloudconnectiviteit bereikbaar is, welke poortsnelheden worden ondersteund en of circuits via fysiek gescheiden routes kunnen worden afgenomen.

Hier wordt multi-datacenterarchitectuur ook commercieel relevant.

De ene locatie kan een uitstekende carrierdichtheid hebben maar dure rackruimte. Een andere kan gunstigere economics voor compute bieden. Een derde kan dichter bij een cloud-on-ramp of Internet Exchange liggen. Als locaties voorspelbaar met elkaar kunnen worden verbonden, kan infrastructuur worden geplaatst op basis van de workload in plaats van ieder component in één faciliteit te moeten onderbrengen.

De Amsterdamse opstelling van 3W Infra is een praktisch voorbeeld van dit model. De drie onderling verbonden colocatielocaties maken het mogelijk om connectiviteit tussen racks en carriers in de metropoolregio door te trekken, zodat een carrier die in de ene faciliteit beschikbaar is ook kan worden geleverd aan apparatuur die in een andere faciliteit staat.

Die flexibiliteit heeft een architecturale keerzijde. Zodra verkeer afhankelijk wordt van de transportlaag tussen datacenters, wordt dat metronetwerk onderdeel van de productieomgeving. Fiberroutes, paddiversiteit, switching- en optische infrastructuur, capaciteitsmarge, monitoring, onderhoudsprocedures en failovergedrag moeten met dezelfde zorg worden beoordeeld als het datacenter zelf.

Remote Hands en operationele ondersteuning in colocatieontwerp

Een datacenter kan aan iedere technische specificatie voldoen en toch moeilijk te beheren zijn.

Fysieke interventie blijft onvermijdelijk. Drives gaan defect. Optica moeten worden vervangen. Fiber moet opnieuw worden gepatcht. Voedingen vallen uit. Nieuwe servers arriveren. Apparatuur moet worden geïnstalleerd, gelabeld, getest, verplaatst en uiteindelijk uitgefaseerd.

Voor infrastructuur die honderden of duizenden kilometers van het engineeringteam staat, wordt Remote Hands onderdeel van het herstelpad.

De relevante vraag is niet alleen of de dienst bestaat. Ondernemingen moeten vaststellen welke werkzaamheden technici zonder gedetailleerde instructies kunnen uitvoeren, of gekwalificeerde engineers buiten kantooruren beschikbaar zijn, hoe escalatie werkt, welke reserveonderdelen lokaal kunnen worden opgeslagen en hoe fysieke werkzaamheden worden gedocumenteerd.

In Amsterdam kan 3W Infra werkzaamheden uitvoeren zoals het ontvangen en uitpakken van hardware, rack-and-stack, bekabeling, optica, vervanging van componenten, provisioning van cross-connects en andere on-site infrastructuuractiviteiten. Projectmatige fysieke ondersteuning is ook beschikbaar in verschillende andere landen.

Voor een op afstand beheerde omgeving beïnvloedt die mogelijkheid de mean time to repair net zo direct als monitoringsoftware. Het operationele model moet daarom samen met de netwerk-, stroom- en hardwarearchitectuur worden beoordeeld en niet als een afzonderlijke ondersteuningsfunctie worden behandeld.

DCIM, infrastructuurzichtbaarheid en operationele controle

Ondernemingen moeten ook vragen welke infrastructuurinformatie na de implementatie zichtbaar blijft.

Netwerkmonitoring ligt voor de hand. Stroomverbruik, omgevingscondities, hardware-inventaris, circuitinformatie, racklocatie, serienummers, bekabelingsregistraties, incidenthistorie en configuratiestatus zijn op schaal even belangrijk.

Hier beginnen DCIM, asset management, network observability en configuration management elkaar te overlappen.

Een DCIM-platform kan laten zien in welke rackunit een apparaat staat, maar operations moeten ook weten welke switchpoort het gebruikt, welk circuit het rack voedt, welke applicatie ervan afhankelijk is, wanneer de garantie verloopt, waar het reserveonderdeel ligt en wie bevoegd is het te vervangen.

Zonder die context raken redundantiediagrammen snel verouderd.

Operationeel eigenaarschap moet daarom vroeg worden vastgelegd. Bepaal welk team netwerkconfiguratie beheert, wie cross-connectwijzigingen goedkeurt, wie de hardware-inventaris bijhoudt, wie het werk van Remote Hands valideert en waar de verantwoordelijkheden van de provider bij de rackgrens ophouden.

Onduidelijkheid blijft meestal bestaan totdat een incident deze zichtbaar maakt.

Ontwerp multi-site colocatie voor veerkracht en disaster recovery

Multi-site architectuur wordt vaak gepresenteerd als het antwoord op veerkracht, maar een tweede datacenter helpt alleen als de applicatie er daadwerkelijk gebruik van kan maken.

Active-passive ontwerpen zijn in sommige omgevingen operationeel eenvoudiger, maar herstel hangt af van de kwaliteit van replicatie, failoverprocedures, DNS- of routeringswijzigingen en regelmatig geteste runbooks.

Active-active ontwerpen kunnen de hersteltijd verkorten en workloads verdelen, maar introduceren andere problemen: statussynchronisatie, dataconsistentie, traffic steering, asymmetrische paden, split-brain-condities en applicatiegedrag tijdens gedeeltelijke netwerkuitval.

Latency kan de beperkende factor worden lang voordat ruwe bandbreedte dat is. Synchrone storagereplicatie kan bijvoorbeeld geografische beperkingen opleggen waardoor twee ver uit elkaar gelegen locaties technisch veerkrachtig maar operationeel onpraktisch worden voor de workload.

Ondernemingen moeten daarom eerst het gewenste faalmodel kiezen en pas daarna het tweede gebouw.

Een technisch indrukwekkende faciliteit compenseert niet voor een applicatie die niet kan failoveren, een netwerk waarvan de "diverse" paden dezelfde fiber delen of een operationeel model waarvoor eerst een engineer moet invliegen voordat een server kan worden vervangen.

De moeilijkste datacenterbeslissing is niet welk gebouw de langste featurelijst heeft. Het gaat erom te bepalen waar u de grenzen van uitval, controle en operationele verantwoordelijkheid wilt leggen - en vervolgens te controleren of de faciliteit, het netwerk, het hardwareplatform en het ondersteuningsmodel die grenzen versterken of stilzwijgend ondermijnen.

FAQ met strategische inzichten

Wat moeten executives als eerste beoordelen bij het kiezen van een colocatiefaciliteit?

Begin met workloadrisico, groei, vermogensdichtheid, netwerkafhankelijkheden en herstelvereisten, omdat deze factoren bepalen of een faciliteit het bedrijf ook na de eerste implementatie blijft ondersteunen.

Waarom zijn gedeelde faaldomeinen belangrijker dan algemene claims over redundantie?

Redundante componenten kunnen nog steeds tegelijkertijd uitvallen wanneer ze bovenliggende stroomvoorziening, fiber, carriers of controlesystemen delen. Het in kaart brengen van afhankelijkheden is daarom essentieel voor geloofwaardige veerkrachtplanning.

Wanneer levert een multi-site colocatiestrategie echte commerciële waarde op?

Dat gebeurt wanneer afzonderlijke locaties de continuïteit, leveranciersflexibiliteit, capaciteitsopties en herstelmogelijkheden verbeteren zonder netwerkcomplexiteit te introduceren die zwaarder weegt dan het voordeel van de extra veerkracht.

Hoe moeten ondernemingen kiezen tussen Layer 2 en Layer 3 tussen datacenters?

Kies op basis van applicatiegedrag en faalgrenzen: Layer 2 bevordert continuïteit en migratieflexibiliteit, terwijl Layer 3 doorgaans duidelijkere isolatie en routeringscontrole biedt.

Waarom moet carrierdiversiteit verder worden beoordeeld dan alleen het aantal beschikbare providers?

Commerciële keuze heeft alleen waarde wanneer circuits fysiek en operationeel onafhankelijk zijn. Meerdere carriers die fiberroutes of faciliteiten delen kunnen namelijk dezelfde onderliggende blootstelling aan storingen behouden.

Hoe helpt 3W Infra het risico bij multi-datacentercolocatie te verminderen?

3W Infra combineert onderling verbonden Amsterdamse datacentercolocatie, carrierneutrale toegang, Layer 2- en Layer 3-netwerken en hands-on operationele ondersteuning om veerkrachtigere en flexibelere multi-site omgevingen te creëren.

Hoe moet operationele ondersteuning de uiteindelijke colocatiebeslissing beïnvloeden?

Interventie op afstand beïnvloedt de hersteltijd rechtstreeks. Ondernemingen moeten daarom de beschikbaarheid van engineers, escalatieprocedures, afhandeling van reserveonderdelen, documentatie en verantwoordelijkheid van de provider beoordelen naast de technische specificaties.

Bespreek uw datacentercolocatiestrategie met 3W Infra

Wilt u bespreken hoe colocatie, netwerkdiversiteit, faaldomeinen en operationele ondersteuning binnen uw infrastructuur moeten samenwerken? Neem contact op met de infrastructuurexperts van 3W Infra via [email protected].

ISO 27001 Gecertificeerd
PCI DSS Compliant Datacenters
24/7 ondersteuning op locatie
Snelle levering op maat
Geen langlopende contracten
Diverse lease-opties en aankoop
Schaalbaarheid
Kostenefficiëntie