
Tijdens een digitale toets in Schoolyear AVD (Azure Virtual Desktop) draait voor elke student een eigen virtuele werkplek in Azure. Die werkplekken worden kort voor de toets aangemaakt en na afloop weer afgebroken. Wat er in die paar uur met die machines gebeurt, bepaalt of de toets soepel verloopt. Schoolyear levert standaard monitoring via het Schoolyear Dashboard, waarop algemene meldingen staan. De dienst van ParaSoll gaat een aantal stappen verder: geavanceerde monitoring en alerting op de AVD-omgeving die voor een toets wordt gestart. In deze blog lees je wat dit inhoudt, hoe een melding eruitziet en wat je er voor, tijdens en na een toetsmoment aan hebt.
Stel, om 9.00 uur begint een toets voor 140 studenten. Ruim voor die tijd begint Schoolyear AVD in Azure met het uitrollen van de toetsomgeving. Daarbij wordt een groot aantal technische componenten geautomatiseerd gebouwd, zoals 140 virtuele werkplekken, een paar proxyservers en een host pool waar die werkplekken zich bij aanmelden. Pas wanneer een hele serie aan scripts en acties is doorlopen, kan een student inloggen.
In die keten kan op verschillende plekken iets misgaan. Een deployment in Azure kan mislukken. Een werkplek kan prima draaien, maar zich niet aanmelden bij de host pool, waardoor niemand erop kan. En soms loopt alles door, maar is een machine zo zwaar belast dat de toetssoftware traag reageert. In de toetsruimte merk je daar pas iets van als een student zijn hand opsteekt. Precies dat moment wil je voor zijn.
Schoolyear levert een basisdashboard waarmee je de toets zelf volgt, met de monitoring die daarbij hoort. Dat is de plek voor de toetsorganisatie. Wat je daar niet ziet, is wat er onder de motorkap binnen de Azure-omgeving van de onderwijsinstelling gebeurt: of elke werkplek succesvol is uitgerold, of elke machine bereikbaar is voor een student en hoe de machines het houden terwijl de toets loopt.
Die laag beheren wij voor onderwijsinstellingen die Schoolyear AVD gebruiken, en daarom hebben we er zelf monitoring voor ontwikkeld. Het is dus geen functie van Schoolyear en geen uitbreiding van het Schoolyear Dashboard, maar een aanvullende ParaSoll-dienst die naast de basismonitoring van Schoolyear draait. De ParaSoll-monitoring kijkt standaard om de paar minuten in de Azure-omgeving van de onderwijsinstelling, en tijdens een toets vaker. Zodra er een nieuwe toetsomgeving verschijnt, volgt de monitoring alle acties van de deployment: hoeveel werkplekken zijn uitgerold, hoeveel zijn nog in uitrol, hoeveel zijn geslaagd of mislukt, hoeveel studenten zijn aangemeld en hoeveel sessies zijn actief of verbroken. Per werkplek controleren we of een student kan verbinden. Blijft een werkplek na een ingestelde tijd onbeschikbaar, dan markeert de monitoring die als mislukt, met de reden erbij. Bijvoorbeeld dat de machine zich na het opstarten niet heeft aangemeld bij de host pool.
Daarnaast halen we per werkplek de belasting van belangrijke componenten op, zoals processor, geheugen en SSD (Solid State Disk). Komt een werkplek even boven een drempelwaarde, dan kleurt deze eerst oranje. Wordt de drempelwaarde langer overschreden, dan wordt deze rood.
Om in één oogopslag alle mogelijke verstoringen in de verschillende schakels van de keten te zien, verzamelt de monitoring ook storingsinformatie van Schoolyear en Microsoft. Een incident daar staat in hetzelfde overzicht als de meldingen uit de eigen omgeving, zodat we bij een storing meteen weten aan welke kant het probleem zit.

Hoe bruikbaar een melding is, hangt af van het detailniveau: hoe specifieker de melding, hoe sneller een probleem is opgelost. Een kritieke melding uit onze monitoring noemt daarom de toetsomgeving, de host pool en de werkplekken waar het om gaat, met de oorzaak en een directe link naar de machine in Azure. Een beheerder hoeft dus niet eerst te zoeken waar het zit, maar kan meteen handelen: een werkplek opnieuw aanmelden bij de host pool, een machine opnieuw uitrollen of extra werkplekken bijzetten voordat de toets begint.
Meldingen hebben drie niveaus. Informatief, zoals een toets die start of een batch extra werkplekken die wordt uitgerold. Waarschuwing, bijvoorbeeld als een meting tijdelijk mislukt. En kritiek, als werkplekken niet beschikbaar komen. Onze servicedesk is getraind op deze meldingen en weet bij elk type welke actie erbij hoort. Gebeurt er iets, dan worden direct de beheerders ingelicht die verantwoordelijk zijn voor die school, en zij kunnen meteen aan de slag. Daar hoeft niemand eerst voor te bellen. Elke melding blijft bewaard, zodat we achteraf precies kunnen terugzien wat er wanneer gebeurde en hoe het is opgelost.

Een toets is voorbij als de laatste student uitlogt, maar de monitoringdata blijft beschikbaar. Per toets is er een rapportage over de belangrijkste metrics van de omgeving, zoals de belasting van de werkplekken, verdeeld over de fases van de toets: het uitrollen en opstarten, het wachten op de studenten, het inloggen, de toets zelf en de afbouw. Je ziet per fase de hoogste en de gemiddelde belasting, de zwaarste werkplekken en verschillende andere metrics, overzichtelijk in grafieken en met conclusies in gewone taal. Was de gekozen VM-grootte (het formaat van de virtuele machine) passend, of moet die voor een volgende toets met deze software omhoog of omlaag? Zijn er werkplekken uitgerold die niemand heeft gebruikt?
Dat laatste raakt direct de kosten. Elke uitgerolde werkplek kost geld, ook als deze bij een toets niet is gebruikt. Per maand telt de monitoring per school het aantal toetsen, het aantal uitgerolde werkplekken, hoeveel daarvan geslaagd of mislukt zijn, hoeveel proxies er draaiden, hoeveel verkeer er in- en uitging en alles wat verder in Azure geld kost. Zo kun je de Azure-kosten van digitaal toetsen verklaren en bijsturen, bijvoorbeeld door minder werkplekken uit te rollen waar dat kan of een andere VM-grootte te kiezen waar dat nodig is. Dit is wat we bedoelen met cost control en reporting, en het komt uit dezelfde bron als de monitoring tijdens de toets.


Neem contact met ons op!
