Weinig zaken binnen IT zijn zo spannend als de inrichting van een nieuwe infrastructuur om deze als productieomgeving te laten draaien. Hoewel we tegenwoordig meer klikken dan dat we met fysieke serverracks in de weer zijn, blijft het nog steeds enerverend om te zien dat je inspanningen een solide en betrouwbare systemen opleveren. In een perfect wereld sluit alles perfect op elkaar, verloopt de planning op schema en is het eindresultaat direct klaar om in productie te gaan. De werkelijkheid is helaas anders.
Ik neem hier het voorbeeld van een nieuw virtualisatiecluster, maar dit voorbeeld kan voor vrijwel alles in IT gelden, van de netwerk- tot de applicatielaag. De schroeven en moeren waarmee je de constructie opbouwt, worden volgens een patroon aangebracht. Je kiest een server, switches, storage en draait alles in elkaar. Het ontwerp volgt een vast pad en in die weg hoop je geen onverwachte zaken tegen te komen, zoals driverincompatibiliteit of een buggy softwarestack. Zelfs als alles volgens plan verloopt en het lijkt alsof alles productieklaar is, ben je er nog lang niet. Je bent pas net begonnen.
De testfase
Nu moet je alles als een bezetene gaan testen om er zeker van te zijn dat het 100 procent werkt. En daar kun je nooit 100 procent zeker van zijn.
Het is heel normaal om je richting het licht aan het eind van de tunnel te haasten en de laatste stappen van je klus af te raffelen. Waar we eerst methodologisch en behoedzaam te werk gaan, ontstaat altijd de neiging om tegen het eind minder op details te letten. En juist daar kunnen de addertjes zich in het gras verschuilen.
Terug naar ons nieuwe virtualisatiecluster: We vervangen een ouder cluster met een snellere, grotere en betere versie. We stappen over van 1G naar 10G, van relatief trage storage naar snelle opslag en misschien zelfs van Clovertown naar Sandy Bridge architectuur. De nieuwe apparatuur maakt alles makkelijker en sneller. Menig beheerder en IT-manager wordt enthousiast van zo'n implementatie. Poorten worden aan elkaar gelust, switches geconfigureerd, storage ingesteld, gedeelde resources en LUN's aangemaakt; het hele moeras van een moderne virtualisatieomgeving wordt in relatief rap tempo opgetrokken. Uiteindelijk is het een goed ontwerp waarin je als een warm mes door de boter snijdt.
Er worden een aantal test VM's ingesteld die snel en responsief functioneren en daarmee hun voorgangers tot trage slakken degraderen. Ze lijken perfect te werken en de snelle testen voorspellen geen vuiltje aan de lucht. Dit is waar de neiging om te grote stappen te nemen ontstaat en de slimme beheerders zichzelf moeten verplichten om dagen of weken uit te trekken voor veelomvattende tests op ieder element voordat productieworkloads naar de omgeving verhuizen.
Eerst dient de storage op iedere host in het cluster onder de loep genomen worden. Met virtualisatie is dit kinderspel geworden. Een snelle Linux VM en scripts op basis van Bonnie++ of zelfs dd laat je in een loop draaien en het hele bouwwerk klonen zo vaak als nodig is om een significante load voor iedere fysieke host in het cluster te creëren en hiermee iedere ingeregelde LUN of gedeelde map te testen. Met willekeurige slaapmomenten creëer je op deze manier een random workload met lees- en schrijfbewerkingen. Maar als je echt een storage subsysteem op de pijnbank wilt leggen, zijn er nog een aantal betere manieren.
Stapje voor stapje naar een zwaardere belasting
Als je zo'n systeem een paar dagen hebt laten draaien en niets wat betreft het netwerk of de storage blijkt foutmeldingen te genereren, dan kun je de load verhogen. Gebruik Netperf of een soortgelijke tool om deze VM's te testen en schrijf een snel script om willekeurig TCP-verkeer te genereren dat je op verschillende momenten tussen de VM's laat lopen in een loop. Voeg dit toe aan de bestaande storageworkload. Wil je zeker van je zaak zijn, voeg dan nog een aantal VM's met flink wat CPU's en RAM toe en laat hier ook de nodige stresstests op los. Als je dit goed doet, wordt je cluster op ieder vlak zwaar op de proef gesteld, van CPU tot storage en van RAM tot het netwerk. Als er iets kapot zou kunnen gaan, is dit het moment waarop het zou moeten gebeuren, althans in theorie.
Dit is voor mij het punt waarop ik expres dingen kapot ga maken. Ik haal de stroom van een host om te zien of de noodscenario's in werking treden. Hetzelfde geldt voor het netwerk, waar ik een kabel verwijder of een poort op de switch uitschakel om te zien of de automatische overzetting op de juiste manier gebeurt. Doe dit niet alleen in idle situaties, maar ook met de volledige workload geactiveerd - dit is wanneer het telt.
Het zorgt voor enige geruststelling
Voor sommigen is dit het leukste werk: manieren vinden om het maximale uit verse apparatuur te halen en te kijken waar de zwakke punten en gaten zitten. De voordelen zijn voor iedereen duidelijk. Daarnaast breng het een bepaalde rust als er daadwerkelijk productie gedraaid gaat worden. Het maakt het veel gemakkelijker een probleem op te lossen en de oorzaak te achterhalen.
Dus blijf vooral testen. Probeer er lol in te krijgen om ieder subsysteem en iedere component maximaal te belasten voordat je de productieomgeving activeert. Het is prettig om te merken dat het licht dan gewoon blijft branden.
-
-
Er zijn nog geen reacties.Reageer
Preview