Het lijkt wel of we steeds proberen uit de lengte te halen wat er in de breedte gewoon niet altijd in zit. Zo proberen we applicaties die nimmer ontworpen waren voor virtualisatie en gedeeld resource gebruik toch in het keurslijf van standaardisatie te drukken met bijvoorbeeld Remote Desktop Services. En hiermee maken we van de eerdere correctieve ‘ctrl-alt-del’ gewoonte een preventieve door elke nacht servers te herstarten.
Nu is regelmatig herstarten van een server natuurlijk niet slecht, twintig jaar geleden moest ik dit ook al wekelijks doen voor de mainframe om zodoende de aangebrachte wijzigingen actief te maken. En nu veranderen dingen natuurlijk sneller dan ze vastgelegd worden maar mijn tablet herstart ik desondanks met een veel lagere frequentie, meestal als ik vergeten ben deze op te laden. Het is dus best een rare ‘Best Practice’ om servers te herstarten omdat er onopgeloste problemen met applicaties zijn.
Log-a-ritme
Zolang alleen naar functionele oplevering gekeken wordt en geen rekening gehouden wordt met overdraagbaarheid, efficiëntie en onderhoudbaarheid blijven we dus achter de feiten aanhollen.
Universele oplossingen blijven hierdoor knellen met het maatwerk dat er nodig is, waardoor relatief kleine veranderingen grote impact hebben op de gevoelswaarde van ict. Zo wordt met Agile software ontwikkeling nog onvoldoende gekeken naar aspecten die de mogelijkheden voor Root Cause Analysis in de keten verbeteren. Dat laten Coding Cowboys nog steeds over aan het implementatieniveau waardoor preventief herstarten een begrijpelijke ‘Best Practice’ wordt. En zoeken naar de bottleneck is er ook niet eenvoudiger op geworden met de dynamiek van virtualisatie en load balancing. Het heeft veel gelijkenis met het spel ‘Whack-a-mole’ omdat de nodige informatie in logfiles simpelweg ontbreekt.
Door ontbreken van gegevens over bezetting en belasting worden de verschillende lagen van de infrastructuur zoals netwerk, opslag en servers op basis van vuistregels gedimensioneerd. Maar met de zwaarte die aan de factoren gegeven wordt is hier geen sprake van een lineaire schaal waarmee gewogen wordt. Eerder een logaritmische omdat goedkoper, flexibeler en betrouwbaarder moeilijk tegen elkaar afgezet kunnen worden.
Lengte x breedte
Lagen van de architectuur zoals applicaties, servers, netwerk en opslag vormen samen dan wel een keten maar het beheer hiervan is dikwijls opgedeeld naar techniek. En dus kunnen we wel precies zien welke resources en hoe zwaar deze belast worden binnen de verschillende lagen maar niet door wie. En horizontaal schalen, door de server farm te vergroten zal een bottleneck in andere lagen natuurlijk niet oplossen. Zo wordt de end-to-end response, welke gewoon een optelsom van de prestaties van alle lagen in de infrastructuur is, nog steeds gemeten aan de bovenkant. Reactief dus via gebruikers die klagen over trage applicaties en hangende terminal servers bijvoorbeeld. En hoewel er geen gebrek is aan beheertools is het hierbij net als met de examens waar tachtig procent altijd gaat over dat ene boek dat je niet hebt gelezen. Gelukkig zijn deze steeds vaker multiple choice en wie gokt komt dus al een heel eind.
Virtualisatie gecombineerd met load balancing geeft dus ook meerkeuze oplossingen waarbij we onmogelijkheden direct kunnen doen maar wonderen altijd wat langer blijven duren. Zo kunnen we problemen in applicaties isoleren met Virtuele Desktops (VDI) zodat geheugen lekken niet leiden tot verstoringen. Maar dit lost niet problemen in de andere lagen op en dus krijgen we weer nieuwe uitdagingen zoals ´boot storms´ als er herstart moet worden.
Oud-er(n)-dom
Hoewel hier geschetste problemen natuurlijk niet exclusief zijn voor gecentraliseerde desktop omgevingen zijn deze hier het sterkst herkenbaar. In aangeboden applicatie set zitten namelijk nog weleens erfenissen uit de tijd van Windows 95, oplossingen die ooit gemaakt zijn op basis van dezelfde principes als Agile software ontwikkeling. Gebruikers maakten met Pascal, Visual Basic en andere programmeertalen applicaties voor de eigen afdeling. En natuurlijk werd er niet gedacht aan overdraagbaarheid, rekening gehouden met multiprocessors, 64-bits adressering, gedeeld resource gebruik of alle andere technologische vernieuwingen. Dat deze generatiekloof voor problemen in de race om resources kan zorgen is ook niet nieuw. Het is eerder een telkens terugkerend probleem omdat techniek gewoon sneller veranderd dan de applicaties.
Met desktop virtualisatie kunnen we de levensduur van applicaties verlengen maar dus niet het geheugenbereik verbreden, de interne werking efficiënt verbeteren en keten beter afstemmen. Met het stapelen van oplossingen blijven we proberen uit de lengte halen wat er in de breedte gewoon niet in zit.
Een leuk, en heel herkenbaar artikel … althans, voor de wat oudere rotten (no offense!) in het vak.
De oudere jongeren in ons vakgebied komen nog uit een tijd dat je het moest doen met een beperkte hoeveelheid geheugen, waar je afgerekend werd op het aantal klokcycli dat je programma verstookte op het mainframe, en waar opslagruimte nog een klein kapitaal kostte.
Vandaag de dag is het (relatief) makkelijk om er wat meer cpu power, disk- of memory bij te plaatsen. Men wordt nagenoeg niet meer beperkt in mogelijkheden.
Keerzijde hiervan is, mijns inziens, dat een stukje vakmanschap uit het verleden aan het verdwijnen is.
Binnen de embedded sector kom je dit stukje vakmanschap nog wel tegen, vooral gedreven door limitaties in hardware enerzijds, en het vereiste real-time gedrag anderzijds.
Overigens reikt het verder dan alleen efficiënt programmeren. Ook aan systeemkennis schort het nog wel eens. Een mooi voorbeeld (volgens mij heb ik het al eens genoemd) is de applicatieprogrammeur die het overzicht van een helpdeskapplicatie gemaakt had. Dit overzicht werd weergegeven in een matrix-vorm van 10 kolommen x 20 rijen (200 cellen dus)
Voor iedere cel werd eerst de data overgestuurd, en vervolgens werd aan het systeem gevraag of de data goed aangekomen was. Per cel werd dus 3 keer de afstand server-client afgelegd (sturen data, vragen bevestiging, bevestiging).
Tijdens het testen werkte dit goed. Met een responsetijd van 1ms duurde het opbouwen ongeveer 3x200x1ms, dus lekker snel.
@PaVaKe
Dat het herkenbaar is voor jouw vermoedde ik al, ervaring verkrijg je namelijk niet uit boeken hoewel sommige het herlezen ondanks alle ‘vernieuwingen’die we hebben waard zijn. Bijvoorbeeld over processor architecturen, protocollen, geheugenbeheer en schijven om er een paar te noemen. En zoals ik al aangaf is het inderdaad makkelijk om resources bij te plaatsen via horizontale schaling maar dat hiermee vaak ook weer nieuwe uitdagingen geïntroduceerd worden. Welke we uiteindelijk weer oplossen met nog meer techniek omdat de applicaties ‘untouchable’ zijn en we dus niet alleen de architectuur maar ook het beheer stapelen. En alle hulpmiddelen hebben natuurlijk ook weer resources nodig waardoor soms wel 20% van de beschikbare capaciteit hiervoor gebruikt wordt.
En je voorbeeld met testen is weer herkenbaar voor mij en was de reden om dit stuk te schrijven. Want omgevingen worden vaak theoretisch gedimensioneerd terwijl dit dus beter empirisch gedaan kan worden. Maar helaas wordt dit dus nog vaak achteraf gedaan als blijkt dat de lengte geen rek meer biedt.
op één of andere manier is er een stuk tekst weggevallen:
(binnen de seconde)
Echter, toen de applicatie in gebruik werd genomen klaagden de gebruikers in Engeland steen en been over de performance. De programmeur wees direct naar het netwerk, daar waar wij als netwerkbeheer niets vreemds zagen in de performance. Waar meneer de programmeur echter geen rekening mee had gehouden is dat de afstand Nederland-Engeland een wat grotere roundtrip delay heeft dan de afstend client-server in een lokale testopstelling.
Met een roundtrip delay van 20ms kom je al snel op responstijden van boven de 12 seconden.
Toen we hem dat uitgelegd hadden, vroeg hij of we dat niet op konden lossen. Met enig cynisme hebben we hem toen gevraagd hoe hij gedacht dat te doen, door de fysieke afstand Engeland – Nederland te verkleinen?
Je kunt het proberen in de lengte of in de breedte op te lossen, maar de toegevoegde waarde van een goede IT-er zit in de derde dimensie: de diepte, ofwel ervaring.
Wat opvalt in dit artikel is dat beschreven wordt hoe belangrijk een systembeheerder is. Die zelfde beheerder die door “cloudfans” als overbodig beschreven wordt.
Om te kunnen overzien wat tot ongewenste resultaten bij de eindgebruiker leidt is mijns inziens nog steeds een beheerder nodig die een integraal beeld heeft van de gebruikte harware/software/netwerk en daardoor bottlenecks tijdig kan waarnemen.
Maar ja ook ik ben ook al wat langer in de IT . . . .
Aardig en herkenbaar verhaal, en de reacties van PaVaKe en JanVanLeeuwen kan ik dan ook onderschrijven.
Sprak vandaag uitvoering met een student technische automatisering die geheel volgens verwachting had vastgesteld dat zijn opleiding eigenlijk voornamelijk apentruukjes leert maar dat de basis niet echt doorkomt. Tja waar herken ik dat dan weer van he…
Een bijkomend probleem met de door Ewout genoemde voorbeelden is dat je de applicatie vaak aan een bepaalde versie van de ontwikkelomgeving vast hangt.
@Jan,
Wel eens een verhaal gehoord van een database waar steeds weer een snelle SUN nodig was totdat het echt helemaal uit de klauwen liep.
Bleek dat de programeur een select * from table had gedaan en zelf maar eens op selectiekriterium ging filteren en bijhorende tabellen er vervolgens op de zelfde manier aan knoopte.
Als ik computers moest verkopen zou ik zo’n vent meteen inhuren.
@Jan van Leeuwen
Helemaal met je eens maar er is ook een organisatorisch uitdaging want met gemaakte opdelingen in beheer blijft het eigenaarschap van problemen vaak diffuus. Dus worden deze niet altijd opgelost maar gewoon doorgeschoven naar het volgende loket, zoals met applicaties die soms met de beste wil niet te beheren zijn. En de eigenaar van die applicaties is toch nog vaak de business die conservatiever is dan de techniek hoewel daar soms ook een reden voor is door specifieke functionaliteiten.
Want betreffende het zicht op de keten weten we wel dat resources belast worden maar niet door wie (of waarom) waardoor misschien wel de bottleneck bekend is maar dus nog niet de dader, voorbeelden van Pascal en PaVaKe zijn daarin sprekend. En ik kan zelf ook nog wel een lijstje van dit soort voorbeelden toevoegen maar wil me in dit geval beperken tot de SBC omgevingen. De reden daarvoor is dat deze ‘intelligentie’ soms in applicaties is gebouwd om de intellectuele eigendom te beschermen, de specifieke functionaliteit die vaak voorkomt dat er een alternatief gekozen kan worden.
Kortom – alles draait om meten!
Want meten is weten en gissen is missen.
Dit soort ketenvraagstukken is vandaag de dag eenvoudig op te lossen.
Dan heb ik het over het applicatie-inzicht van een keten: wie gebruikt wat, wanneer en met welke prestaties.
Een praktisch voorbeeld – in de afgelopen week waren er per uur de volgende gemiddelden:
(1) 23 Exchange-gebruikers
(2) gelijktijdigheid van 5 gebruikers
(3) transactietijd van 3 seconden
(4) per transactie 3 MB aan netwerkverkeer
Gemiddelden alleen zijn natuurlijk niet voldoende. Daar horen percentielen bij om erachter te komen waar de uitschieters zitten – positief of negatief. En in welke mate die voorkomen.
Sommige van dit soort monitoringtools zijn ook in staat om dat te combineren met resourcebelasting (CPU, disk IO en wat dies meer zij). En dat zowel virtueel als fysiek (ESX of Hyper-V). Alhoewel ik mijn twijfels heb over het praktisch nut van resource monitoring binnen een virtuele server.
Nogmaals – er zijn vandaag de dag voldoende betaalbare instrumenten/tools beschikbaar. Het is daarbij wel zaak dat ook de ‘consumenten’ van die keteninformatie betrokken worden bij de selectie en invoering.
En niet alleen de technische mensen zoals netwerk en systeem beheerders. Want die worden gemeten op device beschikbaarheid (‘bij mij is alles groen’). En niet op de bijdrage aan een (applicatie) keten – laat staan de gebruikersbeleving. Waarbij gebruikersbeleving gedefinieerd is als ‘de wachttijd tussen een klik en het bijbehorende antwoord op het scherm’.
@Will
Je hebt gelijk maar helaas ten dele want het meten is niet voor alle applicaties zo eenvoudig zoals de voorbeelden van PaVaKe en Pascal ook al duidelijk maken. Zoals de wachttijd tussen een klik en het antwoord welke dus niet alleen helemaal door de keten moet, die door alle stapelingen eerder een web is maar dus ook nog verwerkt moeten worden.
Want in een specifieke oplossing als SBC waar meerdere applicaties met verschillende karakteristieken op draaien worden hierdoor vertragingen nog weleens versterkt. En natuurlijk kunnen we aan de achterkant wel bepalen dat verzoeken snel beantwoord worden maar dat zegt nog niets over het eindresultaat. Tenslotte geef jezelf ook al aan dat als de dashboard lampjes die op groen staan, zoals een belasting aan de achterkant nog niet zoveel zegt over de prestatie aan de voorkant.
Deze is namelijk vooral afhankelijk van allerlei koppelingen waar nog weleens erfenissen in zitten uit het verleden, bijvoorbeeld met Domino of andere groupware om maar wat te noemen. Betreffende keuze van instrumenten is er ook niet altijd zoveel vrijheid omdat de business uiteindelijk de applicaties kiest welke IT dan weer mag integreren in de architectuur. En hier wordt niet altijd naar aspecten gekeken zoals onderhoudbaarheid waardoor er dus nogal wat puntoplossingen in het beheer van de platformen, middleware en databases zijn om maar wat te noemen.
Misschien dat je betoog over de eenvoud van ketenbeheer op gaat voor een architectuur welke gebouwd is op de oplossing van één leverancier maar ik ben bang dat praktijk weerbarstiger is. En hierdoor lijkt het ketenbeheer in SBC omgevingen soms net op het spelletje ’touwtje-trek’ van de kermis waar je nooit weet wat er omhoog komt als je een wijziging aanbrengt.
Ooit eens aan een project gewerkt waarbij in de aanbesteding een forse boete clausule was opgenomen binnen hoeveel tijd de gebruiker een respons kreeg. Dit werd natuurlijk gecontroleerd met een stopwatch.
Maar dit valt natuurlijk allemaal onder technisch vakmanschap van de betrokkenen en de juiste aansturing en gebruik van dit vakmanschap. En aangezien de jongere generaties die helaas niet meer of te weinig tijdens hun opleiding meekrijgt zullen ze het dan maar van de oude rotten moeten leren. (Of zelf het wiel opnieuw moeten uitvinden.)
@Ewout:
De kritische noot kan ik me goed voorstellen. Toch meen ik te moeten concluderen dat je teveel gehinderd bent door ter zake doende kennis.
🙂
Even kijkend naar mijn eigen ervaring:
Ik heb in het verleden gewerkt aan het in kaart brengen en oplossen van problemen in applicatie ketens met (gebruikers)transacties die 8-11 servers raakten – afhankelijk van een lees of schrijf actie!
Daar zaten technieken in als web & Citrix voor de front-end, .Net (IIS) & Java (Tomcat) voor de business logic, Websphere als integratie laag, AIX/Oracle & mainframe/DB2 als database server.
De front-ends waren Windows systemen. En de integratielaag was gebaseerd op RedHat.
En dat alles ook nog eens in meerdere of mindere mate gevirtualiseerd.
In dergelijke situaties heb ik nooit meer dan 2 monitoring tools nodig gehad om te begrijpen hoe de keten in elkaar zit. En om me het inzicht te geven rondom het gebruik – wie gebruikt wat en wanneer.
Anders gezegd: laat me weten als je weer eens tegen zo een touwtje-trek situatie aanloopt! Het moet al raar lopen wil ik geen oplossing hebben.