De inzet van nieuwe technologieën en produkten in een datacentrum is veelal bedoeld om bestaande problemen op te lossen op het gebied van koeling, energieverbruik, ‘floorspace’, en bezettingsgraad van rekencapaciteit. De oplossingen zijn vaak gebaseerd op concepten van virtualisatie, functionaliteitsintegratie of een combinatie van die twee. Echter deze twee concepten introduceren onbedoeld een nieuw probleem: complexiteit.
Bekende voorbeelden zijn die van een blade-server chassis, een VM-Ware ESX installatie, een netwerk chassis met switchblades, firewall- en loadbalancer-modules, en diverse in software gevirtualiseerde functionaliteiten zoals routing, firewalling en virtuele servers.
De nieuwe produkten zijn enerzijds geoptimaliseerd in het fysieke: kleiner, compacter, modulair en het samenvoegen van functionaliteiten in één apparaat. Anderzijds zijn ze dankzij virtualisatie in staat om de systeembronnen dynamisch toe te wijzen en af te stemmen op de behoeften waardoor de totale capaciteit van opslag, rekenkracht en werkgeheugen veel efficiënter kan worden gebruikt.
Dit kan echter allemaal niet worden gerealiseerd zonder extra intelligentie en dus complexiteit.
Voor de productspecialisten en systeemarchitecten is dit geen probleem. Deze mensen hebben kennis en ervaring en vooral ook (project)tijd om de complexe producten te installeren, configureren en werkend op te leveren. Echter voor de beheerorganisatie vormt de extra complexiteit een nieuw obstakel om de infrastructuur operationeel te houden.
Om dit te kunnen illustreren is het nodig om het begrip complexiteit nader te ontleden in een aantal deelaspecten:
Abstractie:
Door integratie van functionaliteiten en de inbedding van diverse virtuele entiteiten in de software van een apparaat, wordt de infrastructuur abstracter. Op de computervloer, in het rack, is een functionaliteit niet meer herkenbaar in een onderscheidbaar apparaat. 'Zou je naar de zaal kunnen gaan en webserver01 even kunnen rebooten' is er niet meer bij. Dit brengt ons gelijk bij het nauw gerelateerde aspect van de toegang tot een (virtueel) apparaat. De stappen en autorisaties die nodig zijn om lokaal of van-afstand toegang te krijgen tot een apparaat of service zijn omvangrijker en complexer. De beheerder moet eerst aanloggen in een tussenlaag en vervolgens een nieuwe sessie maken naar de uiteindelijke virtuele service. Zelfs de verbindingen tussen diensten, apparaten of componenten zijn niet meer zichtbaar en herkenbaar: de kabels zijn vervangen door een ontoegankelijke 'backplane' in een chassis.
Ook de tekening en de topologie van de infrastructuur 'mappen' bestaan niet meer op de fysieke verschijningsvorm in het datacentrum. Dit betekent een groter risico op fouten en het vergt ook meer tijd en aandacht om de tekening up-to-date te blijven houden. Al met al heeft de beheerder meer kennis en tools nodig om het machinepark te kunnen begrijpen en te beheren.
Verwevenheid en afhankelijkheid:
De integratie en virtualisatie zorgt ervoor dat fysieke apparaten, besturingssystemen en applicaties onderling veel meer verweven zijn en sterk afhankelijk zijn van elkaar. Een fysiek defect aan een apparaat heeft meteen verstrekkende gevolgen voor een groot aantal diensten. Het is veel moeilijker om een gevolg van zo'n defect te isoleren tot een beperkt aantal diensten. Natuurlijk zijn de producten en oplossing hierop ontworpen en is er een vorm van redundantie ingebouwd. Echter dit levert op zijn beurt weer extra complexiteit op.
Een ander punt is dat in het geval van een noodzakelijke wijziging zoals een upgrade of de uitfasering van een component er met veel meer partijen/klanten moet worden afgestemd over wanneer de wijziging, met vaak een zekere down-tijd, mag plaatsvinden. Dit kost aanzienlijk meer (doorloop)tijd vanwege de extra communicatie en overleg dat nodig is.
Onduidelijke grenzen van beheerdomeinen:
De nieuwe technologieën corresponderen totaal niet meer met de traditionele organisatiestructuur van de beheerorganisatie zoals bijvoorbeeld de indeling: netwerkbeheer, systeembeheer en applicatiebeheer. De demarcatie van beheerdomeinen kan opeens komen te liggen in een apparaat zelf. Een voorbeeld hiervan is een blade-chassis of een ander product met een ingebouwde fysieke of virtuele ethernet switch. Waar eindigt de verantwoordelijkheid van netwerkbeheer en waar begint die van systeembeheer?
Om toegang te krijgen tot de switch in het chassis heeft netwerkbeheer toegang nodig tot de beheeromgeving van het chassis; is dit wenselijk? Andersom kan een (virtuele) switch die door systeembeheer wordt beheerd onbedoeld verkeerd worden geconfigureerd waardoor dit ongewenste effecten in het netwerk veroorzaakt (het zenden van BPDU's, vtp settings, et cetera).
Helemaal lastig wordt het in het geval van een storing; waar ligt de oorzaak en wie gaat er wat aan doen? Om nog maar te zwijgen over een situatie waarbij bijvoorbeeld één van de twee beheerdomeinen is uitbesteed aan een externe partij.
Functionele integratie en virtualisatie zijn mooie technologieën die ons in staat stellen een enorme efficiëntieslag te maken in het datacentrum. Echter de introductie van deze nieuwe producten kan niet plaatsvinden zonder structurele aanpassingen in de beheerorganisatie op het gebied van kennisniveau, beheerdomeinen, en service-afspraken.
Technologie kan niet los worden gezien van organisatie en mensenwerk !
Beste Bart,
Goed en zeer herkenbaar stuk. En ik deel je mening. Ook al is de techniek nog zo ver, snel en mooi. Zonder een gedegen IT organisatie en afdoende kennis ( intern of extern ) is er nog steeds weinig van te maken.
Dag Bart, mooi artikel, maar ik begrijp iets niet en wellicht kun je dit voor mij verduidelijken.
Als het virtualiseren zo complex is, waarom ziet het er bij Amazon EC2 zo simpel uit? Ik snap best dat opzet, beheer en opsporen van fouten moeilijker is dan 1 server met daarop een OS, maar dit zijn toch zaken die je automatiseert? Je kiest een opzet en een beleid een standaard manier van opzetten waardoor je problemen en uitbereidingen door kunt voeren zonder hier nog dieper over na te hoeven denken.
Virtualisatie is nu juist zo aantrekkelijk omdat je hier een elasticiteit en schaalbaarheid mee kan realiseren. Zo als jij het beschrijft lijkt het allemaal heel moeilijk en heel duur en dat kan niet de bedoeling zijn.
Een scenario wat ik me voor kan stellen waarom het moeilijk en complex is, is als je iets heel specifieks nodig hebt zoals zeer krachtige IO of een database met extreem veel transacties die razendsnel uitgevoerd moeten worden.
AOL heeft onlangs een onbemand datacenter opgezet volledig op basis van virtualisatie. Een productie server optuigen kan in minder dan 60 seconden en ze voldoen aan alle veiligheidseisen.
Als virtualisatie en integratie erg complex geworden zijn klinkt het teveel als maatwerk en maatwerk in een virtualisatie omgeving is in mijn ogen onwenselijk. Het is vaak een aanknopingspunt om nog iets dieper en langer na te denken en een betere standaard oplossing te vinden die op de korte termijn wellicht meer kost, maar op de lange termijn een enorme besparing oplevert.
Maar goed, een half jaar geleden riep ik iets over mainframes – iets waarover ik behoorlijk onwetend bleek te zijn- en nu ben ik mainframes met andere ogen gaan bekijken.
@Henri,
de voorbeelden die je noemt gaan over het gebruik van de dienst die Amazon EC2 levert. Das dus simpel geworden.
Het artikel gaat over het cloudbeheer en waarom dat complex is.
Mijn tante googlet ook regelmatig, maar zelf een wereldwijde zoekmachine bouwen vindt ze vast een uitdaging.
Het gaat juist niet over cloudbeheer, maar Bart benoemd dat het beheer ladtiger is geworden aangezien het niet meer alleen netwerk, windows, unix of storage is maar een combinatie. Je zal dus infrabeheerders aan moeten gaan stelken en de oude expertse groepen los moeten laten.
@Henri
Het probleem is meestal dat de organisatie en de mensen niet worden aangepast aan de nieuwe technologische standaarden en ontwikkelingen. Als je ‘van scratch’ kan beginnen met een nieuwe datacenter zonder legacy en met mensen die vanaf het begin het zaakje opbouwen en uiteindelijk gaan beheren is er niets aan de hand en dan lopen mens & technologie samen op. Maar hoe vaak komt voor ?
Beste Bart,
Met belangstelling heb ik je artikel gelezen. Ik had soms het gevoel dat ik het me je eens was en vaak het gevoel dat het niet zo was.
Ik ben het met je eens dat de complexiteit van ICT groter is geworden. Maar dat geldt toch voor alles en niet alleen ICT!! Dit is de uitkomst van “(door)ontwikkeling” van producten. Voorbeeld: je heb als automonteur vandaag de dag met andere complexiteit(hoger) binnen deze industrie te maken dan 5 jaar geleden.
Deze complexiteit vereist andere werkwijze, kennis en aanpak. Het is wel waar dat dit voor meer verwevenheden en afhankelijkheden zorgt, maar als je je bouwstenen goed op elkaar gezet heb met de juiste kennis en aanpak dan zou je hier geen last van krijgen.
Het verhaal onder “abstractie”, “onduidelijke grenzen” of “Verwevenheid”gaf me het gevoel dat dit door een iemand geschreven is die al sinds 1999 op vakantie op een onbewoond eiland was en nu dat hij terug is wordt hij opeens met veel vernieuwing binnen ICT geconfronteerd! Beste Bart, wat wil je hiermee duidelijk maken? ICT is nu anders dan voorheen, dit is toch al duidelijk!Bovendien ik ben het met een antal punten in die stukken niet eens, waar ik verder niet op in ga.
En tot slot ik vind het merkwaardig als men iets in de organisatie veranderd door het invoeren van bijvoorbeeld de nieuwe technologische standaarden en ontwikkelingen terwijl verder niet gekeken wordt naar andere componenten in de keten om dit mee te veranderen.
@Reza,
De auteur wil duidelijk maken dat virtualizatie en daarmee samengaande integratie, voor complexiteit zorgt. De titel zegmaar 🙂
De techneuten met enig abstractievermogen hebben daar geen moeite mee. Bedrijven of beheerorganisaties vaak wel.
Die zijn net gewend aan aparte beheerdomeinen : Security, Server, netwerk, met elk eigen beheerders. Nu gaat de ESXi beheerder ineens zelf extra virtual NATted of Bridged NICs aan virtualmichines koppelen of hele virtual switches definieeren.
Eindelijk eens een artikel in Computable waarin per bewering tal van argumenten worden gegeven inclusief duielijke voorbeelden. Dat helpt blijkbaar weinig, gezien de reacties.
mauwerd,
Ik probeerde aan te geven dat deze grote complexiteit bij de ICT wereld van deze tijd hoort. Dat geldt niet alleen voor virtualisatie maar ook andere zaken. Neem bijvoorbeeld Exchange 2010. Deze dienst is zeer complexer geworden dan de oude versies zoals 2003! Een beheerder van Exchange 2010 meer moet weten en kunnen dan die van de oude versie. Dit betekent dat de beheerorganisatie mee moet groeien met deze veranderingen. Als ICT manager dien je er voor te zorgen dat je beheerteam enige abstractievermogen en voldoende kennis heeft anders moet je beter je ICT afdeling uitbesteden!
Gebaseerd hierop als je je beheerders tijdig opleidt en tijdens de uitvoering van het project mee laat draaien met het projectteam VMware (in de bouwfase) dan zou je niet zo opkijken tegen zaken zoals het maken van een extra virtual NATted of Bridged NICs die aan virtualmichines koppelen of hele virtual switches definiëren (als je cursus gaat volgen dan zal je dit op de dag 3 van VMware training leren)
Computable is een site met een hoge kwaliteit. Dit is NIET het eerste artikel op deze site dat met tal van argumenten gepubliceerd wordt. Ik raad je aan om deze site beter te verkennen.
Bovendien wanneer een argument voor jou geldig is hoeft niet voor iemand anders ook geldig te zijn. Gelukkig hebben we allemaal niet even veel kennis en ervaring anders was het heel saai op deze site!
Mijn punt is dat als het moeilijker en complexer wordt de eventuele winst snel verdampt en het een indicator is dat je geen standaarden hanteert.
In een ander computable artikel ging het over de frustratie om de SAN uit te bereiden. Daar was virtual storage dus ingewikkeld gemaakt door processen en een verkeerde inzet van de SAN.
Ik snap ook wel dat de techniek complex is, maar door een standaard te gebruiken en daarmee dus ook dingen te automatiseren (zoals agents die vertellen wat het probleem is en wat er gedaan moet worden) kun je het wel effectief managen en kostenbesparingen realiseren.
Als je te maken hebt met legacy en daardoor je virtualisatie omgeving complexer wordt zit je op een verkeerd spoor. Dat spoor loopt namelijk dood.
Rationaliseren is pure noodzaak om de IT in de organisatie economischer te maken. Dit vergt visie en leiderschap. Bij gebrek hieraan (en vaak door belang bij een leverancier) wordt het probleem wel opgelost met meer techniek, maar ook met meer complexiteit en daarbij behorende kosten.
Als je iets unieks nodig hebt voor bijvoorbeeld innovatie is een (tijdelijk) toegevoegde complexiteit acceptabel. Maar heel veel bedrijven/processen/behoeftes zijn helemaal niet uniek en moeten daarom juist gestandaardiseerd worden. Dat complexe oplossingen nodig zijn door eerder gemaakte keuzes zou in mijn ogen geen excuus mogen zijn.
Niettemin sta ik open voor inzicht. Als iemand mij kan uitleggen waarom bepaalde complexiteit noodzakelijk is sta ik daar open voor. Ook sta ik open voor de argumentatie waarom er afweken is van een generieke standaard die bijvoorbeeld self-service mogelijk maakt (aka de cloud).
Nog een kleine aanvulling: Bij het verplaatsen van grote MS SQL Server databases bleek dat virtualisatie in het begin inderdaad een extra laag aan complexiteit met zich mee bracht. Het tunen van de performance leidde tot meer factoren die invloed hadden (I/O, gedeeld geheugen, et cetera). Maar ook hier bleken standaard door MS uitgewerkte scenario’s uitkomt te bieden.
Daarnaast denk ik dat bijvoorbeeld Microsoft Azure een indicatie is waar het naar toe gaat. Die richten zich meer op een platform, hoe de servers die daar onder liggen functioneren zie je eigenlijk niet en dat is volledig geautomatiseerd (en bedienbaar via een zelfbediening portaal)