cloud / systemen
Een Amazon EFS-probleem kan al bestaan lang voordat het zichtbaar wordt. Een klein bestandssysteem kan een workload weken of maanden goed bedienen terwijl het een eindige voorraad burstcredits verbruikt. De applicatie oogt gezond, dashboards blijven groen en de architectuur wint vertrouwen. Dan bereikt de reserve nul en stuit dezelfde workload op een veel lagere duurzame doorvoerlimiet.
Door deze vertraging voelt de storing plotseling. Operationeel is ze dat allerminst.
De verborgen mismatch
Bij Bursting Throughput groeit de basisdoorvoer mee met de hoeveelheid gegevens in de opslagklasse EFS Standard. AWS documenteert een basisniveau van 50 KiB/s per GiB, waarbij elk bestandssysteem minimaal 1 MiB/s gemeten doorvoer krijgt. Werk onder het basisniveau levert credits op; werk erboven verbruikt ze.
Het gevaarlijke patroon is een belasting waarvan het langetermijngemiddelde iets boven die basisdoorvoer ligt. Dat veroorzaakt mogelijk niet meteen een incident, omdat eerder opgebouwde credits het verschil opvangen. Het saldo daalt echter elke dag.
Waarom de symptomen in de verkeerde richting wijzen
Wanneer opslagaanroepen langer duren, wachten applicatieworkers. In Linux tellen processen die geblokkeerd zijn in niet-onderbreekbare I/O-wachttijd mee voor de load average. Daardoor kan een opslagknelpunt op een tekort aan rekencapaciteit lijken. Requests komen in de wachtrij, workerpools lopen vol en time-outs verspreiden zich door de dienst, ook wanneer CPU-gebruik niet de oorzaak is.
Meer instances toevoegen kan de situatie verergeren als elke nieuwe worker meer aanvragen doet op hetzelfde beperkte gedeelde bestandssysteem. Het knelpunt wordt gedeeld, terwijl de extra gelijktijdigheid de druk erop verhoogt.
Waarom zes gezonde maanden weinig bewijzen
Een lange periode zonder storing bevestigt alleen de combinatie van vraag, basisdoorvoer en resterende credits in die periode. Het bewijst niet dat de belasting houdbaar is wanneer de credits op zijn. Een dalende BurstCreditBalance is daarom niet alleen een capaciteitsdetail, maar een vroeg betrouwbaarheidssignaal.
Belastingtests moeten de stabiele toestand omvatten, niet alleen een korte piek. Een test van tien minuten kan aantonen dat de burstlimiet hoog genoeg is. Hij zegt weinig over een tekort dat zich over duizenden uren opbouwt.
Een betere onderzoeksvolgorde
- Vergelijk CPU-gebruik met load average en I/O-wachttijd.
- Onderzoek EFS
BurstCreditBalanceover weken of maanden. - Vergelijk
MeteredIOBytesmetPermittedThroughput. - Leg het verband tussen opslagbeperkingen, applicatielatentie en verzadiging van workers.
- Controleer hoeveel gegevens daadwerkelijk in de Standard-opslagklasse staan, want die hoeveelheid bepaalt de Bursting-basisdoorvoer.
- Bepaal of de werklast thuishoort bij Bursting, Elastic of Provisioned Throughput.
De technische les
Burstcapaciteit is een buffer, geen capaciteitsplan. Elke dienst op basis van credits moet worden beoordeeld op de richting en snelheid van het saldo, niet alleen op de vraag of de huidige waarde boven nul ligt. Het eerdere artikel in deze reeks beschrijft het werkelijke incidentpatroon in detail; het volgende vertaalt die les naar een concreet CloudWatch-monitoringontwerp.