Onderwerp: Hosting op grote schaal visualiseren

Kijk ook goed naar de complexiteit die je toe gaat voegen door spofs te verminderen. Soms voeg je daardoor zoveel complexiteit toe dat je door de bomen het bos niet meer ziet en er daardoor juist fouten op gaan treden.

Om ook rekening mee te houden: hoe (technisch) complexer de architectuur is, des te duurder het personeel dat het kan onderhouden. Wordt vaak vergeten. Soms is het beter om middels eenvoud te schakelen en zowel problemen als omvang klein te houden. Ik geef een voorbeeld, waarbij het niet om de getallen gaat, maar om de gedachte erachter.

Je kan bij een storage-systeeem telkens bijschalen en meer centraliseren en samenvoegen. Daardoor kun je ongetwijfeld meer performance of zekerheid toevoegen. Maar bedenk je goed welk probleem je oplost. Als we ervan uitgaan dat er op 10 TB een slordige 200 servers staan en je wilt uitbreiden (over tijd een factor 5). Dan kom je dus op 50 TB uit en 1000 servers. Dat kan je doen in gelijksoortige clusters (5x 10 TB) of één groot cluster (of varianten hierop). Als we aannemen dat er eens per <tijdseenheid> een storing is per cluster dan heb je dus bij 5 clusters in theorie 5x zovaak een storing. Maar wel een van 20% van de grootte van die andere.

Nu weet ik natuurlijk niet hoeveel personeel je hebt om servers te herstarten, uit de schijfcheck te halen, defecte databases te fixen en bovenal te communiceren, maar dat gaat sowieso bij 200 klanten aanzienlijk sneller dan bij 1000.

Beredeneer ik dat vanuit een klant (zouden we vaker moeten doen) dan heb ik nog steeds 1 keer per jaar een storing, alleen doordat het hele team dan met 200 klanten bezig is i.p.v. met 1000, duurt die storing aanzienlijk minder lang.

Andere tip: kijk ook naar foutdomeinen. Combineer geen foutdomeinen die van elkaar afhankelijk zijn. Voorbeeld: verbinding komt in DC1 binnen en je trekt 'm door naar DC2. Waardoor je niet alleen een probleem (kan) hebben bij storing in DC2, maar ook bij DC1. Dat zelfde geldt ook voor databases, storage clusters, fysieke nodes, etc.

Denk dat Dennis de spijker op zijn kop slaat. Maak "eilandjes" danwel risico zones en maak de boel niet té complex.

Hardware falen komt steeds minder vaak voor, maar eigenlijk alles gaat fout in software. Maak je het nodeloos complex dan kan er ineens van alles fout gaan ipv die ene storing in 2 jaar.

Alles heeft met het beschikbare budget en daarbij het personeel te maken.

Vaak zal je bijvoorbeeld zien dat de VM/machine prima online is, maar MySQL gewoon aan zijn max connections of iets in die richting zit.

Ik sluit me bij bovenstaande aan, gaat het gewoon niet te complex maken.
Of denk je dat je gewoon een "blik" mensen kunt opentrekken als het een keer spannend wordt? Ik heb nieuws voor je Die mensen zijn er niet, en al helemaal niet afroep beschikbaar.