Vandaag zullen we de statistieken van het schijfsubsysteem in vSphere analyseren. Een opslagprobleem is de meest voorkomende reden voor een trage virtuele machine. Als, in het geval van CPU en RAM, het oplossen van problemen eindigt op hypervisorniveau, dan heeft u bij problemen met de schijf mogelijk te maken met het datanetwerk en het opslagsysteem.
Ik zal het onderwerp bespreken aan de hand van het voorbeeld van bloktoegang tot opslagsystemen, hoewel de tellers voor bestandstoegang ongeveer hetzelfde zijn.
Een beetje theorie
Wanneer we het hebben over de prestaties van het schijfsubsysteem van virtuele machines, letten mensen meestal op drie onderling verbonden parameters:
- aantal invoer-/uitvoerbewerkingen (invoer-/uitvoerbewerkingen per seconde, IOPS);
- doorvoer;
- vertraging van invoer-/uitvoerbewerkingen (latentie).
Aantal IOPS meestal belangrijk voor willekeurige werkbelastingen: toegang tot schijfblokken die zich op verschillende plaatsen bevinden. Een voorbeeld van een dergelijke belasting kunnen databases, bedrijfsapplicaties (ERP, CRM), enz. zijn.
Doorvoer belangrijk voor opeenvolgende belastingen: toegang tot blokken die zich achter elkaar bevinden. Bestandsservers (maar niet altijd) en videobewakingssystemen kunnen bijvoorbeeld een dergelijke belasting genereren.
De doorvoer is als volgt gerelateerd aan het aantal I/O-bewerkingen:
Doorvoer = IOPS * Blokgrootte, waarbij Blokgrootte de blokgrootte is.
Blokgrootte is een vrij belangrijk kenmerk. Moderne versies van ESXi maken blokken tot 32 KB groot. Als het blok nog groter is, is het in meerdere verdeeld. Niet alle opslagsystemen kunnen efficiënt met zulke grote blokken werken, daarom is er een DiskMaxIOSize-parameter in de geavanceerde instellingen van ESXi. Hiermee kunt u de maximale blokgrootte verkleinen die door de hypervisor wordt overgeslagen (meer details ). Voordat u deze parameter wijzigt, raad ik u aan om de fabrikant van het opslagsysteem te raadplegen of de wijzigingen op zijn minst op een laboratoriumbank te testen.
Een grote blokgrootte kan een nadelig effect hebben op de opslagprestaties. Zelfs als het aantal IOPS en de doorvoer relatief klein zijn, kunnen hoge latenties worden waargenomen bij een grote blokgrootte. Let daarom op deze parameter.
Wachttijd – de meest interessante prestatieparameter. De I/O-latentie voor een virtuele machine bestaat uit:
- vertragingen binnen de hypervisor (KAVG, Average Kernel MilliSec/Read);
- vertraging geleverd door het datanetwerk en opslagsysteem (DAVG, Average Driver MilliSec/Command).
De totale latentie die zichtbaar is in het gastbesturingssysteem (GAVG, Average Guest MilliSec/Command) is de som van KAVG en DAVG.
GAVG en DAVG worden gemeten en KAVG wordt berekend: GAVG–DAVG.
Laten we het eens nader bekijken KAVG. Tijdens normaal bedrijf zou KAVG naar nul moeten neigen of op zijn minst veel minder moeten zijn dan DAVG. Het enige geval dat ik ken waarin KAVG naar verwachting hoog is, is de IOPS-limiet op de VM-schijf. In dit geval zal de KAVG toenemen als u de limiet probeert te overschrijden.
Het belangrijkste onderdeel van KAVG is QAVG: de wachtrijtijd voor verwerking binnen de hypervisor. De overige componenten van KAVG zijn verwaarloosbaar.
De wachtrij in het schijfadapterstuurprogramma en de wachtrij naar de manen heeft een vaste grootte. Voor sterk belaste omgevingen kan het nuttig zijn om deze omvang te vergroten. beschrijft hoe u de wachtrijen in het adapterstuurprogramma kunt vergroten (tegelijkertijd zal de wachtrij naar de manen toenemen). Deze instelling werkt wanneer slechts één VM met de maan werkt, wat zeldzaam is. Als er meerdere VM’s op de maan zijn, moet je ook de parameter verhogen Disk.SchedNumReqUitstekend (instructies ). Door de wachtrij te vergroten, verlaagt u respectievelijk QAVG en KAVG.
Maar nogmaals, lees eerst de documentatie van de HBA-leverancier en test de wijzigingen op een laboratoriumbank.
De omvang van de wachtrij naar de maan kan worden beïnvloed door de toevoeging van het SIOC-mechanisme (Storage I/O Control). Het biedt uniforme toegang tot de maan vanaf alle servers in het cluster door de wachtrij op de servers dynamisch te veranderen naar de maan. Dat wil zeggen, als een van de hosts een VM draait die onevenredig veel prestaties vereist (luidruchtige buur-VM), reduceert SIOC de wachtrijlengte tot de maan op deze host (DQLEN). Meer details .
We hebben KAVG uitgezocht, nu een beetje over DAVG. Alles is hier eenvoudig: DAVG is de vertraging die wordt geïntroduceerd door de externe omgeving (datanetwerk en opslagsysteem). Elk modern en minder modern opslagsysteem heeft zijn eigen prestatietellers. Om problemen met DAVG te analyseren, is het zinvol ernaar te kijken. Als alles in orde is aan de ESXi- en opslagkant, controleer dan het datanetwerk.
Om prestatieproblemen te voorkomen, kiest u het juiste Path Selection Policy (PSP) voor uw opslagsysteem. Bijna alle moderne opslagsystemen ondersteunen PSP Round-Robin (met of zonder ALUA, Assymetrische Logical Unit Access). Met dit beleid kunt u alle beschikbare paden naar het opslagsysteem gebruiken. In het geval van ALUA worden alleen de paden naar de controller die eigenaar is van de maan gebruikt. Niet alle opslagsystemen op ESXi hebben standaardregels die het Round-Robin-beleid instellen. Als er geen regel voor uw opslagsysteem bestaat, gebruikt u een plug-in van de fabrikant van het opslagsysteem, die een overeenkomstige regel maakt op alle hosts in het cluster, of maakt u zelf een regel. Details .
Sommige fabrikanten van opslagsystemen adviseren bovendien om het aantal IOPS per pad te wijzigen van de standaardwaarde van 1000 naar 1. In onze praktijk maakte dit het mogelijk om meer prestaties uit het opslagsysteem te “persen” en de tijd die nodig is voor failover aanzienlijk te verkorten in het geval van een controllerstoring of update. Controleer de aanbevelingen van de leverancier en als er geen contra-indicaties zijn, probeer dan deze parameter te wijzigen. Details .
Basis prestatiemeteritems voor schijfsubsystemen van virtuele machines
Prestatiemeteritems voor schijfsubsystemen in vCenter worden verzameld in de secties Datastore, Schijf en Virtuele schijf:
In paragraaf DataStore er zijn metrische gegevens voor vSphere-schijfopslagplaatsen (datastores) waarop de VM-schijven zich bevinden. Hier vindt u standaard tellers voor:
- IOPS (gemiddelde lees-/schrijfverzoeken per seconde),
- doorvoer (lees-/schrijfsnelheid),
- vertragingen (lezen/schrijven/hoogste latentie).
In principe blijkt alles duidelijk uit de namen van de tellers. Laat me nogmaals uw aandacht vestigen op het feit dat de statistieken hier niet voor een specifieke VM (of VM-schijf) gelden, maar algemene statistieken voor de gehele datastore. Naar mijn mening is het handiger om deze statistieken in ESXTOP te bekijken, althans op basis van het feit dat de minimale meetperiode daar 2 seconden is.
In paragraaf Schijf er zijn metrische gegevens op blokapparaten die door de VM worden gebruikt. Er zijn tellers voor IOPS van het sommatietype (het aantal invoer-/uitvoerbewerkingen tijdens de meetperiode) en verschillende tellers die verband houden met bloktoegang (opdrachten afgebroken, busresets). Naar mijn mening is het ook handiger om deze informatie in ESXTOP te bekijken.
Sectie Virtuele schijf – het nuttigst vanuit het oogpunt van het vinden van prestatieproblemen van het VM-schijfsubsysteem. Hier kunt u de prestaties voor elke virtuele schijf bekijken. Het is deze informatie die nodig is om te begrijpen of een bepaalde virtuele machine een probleem heeft. Naast de standaardtellers voor het aantal I/O-bewerkingen, lees-/schrijfvolume en vertragingen, bevat deze sectie nuttige tellers die de blokgrootte weergeven: Lees-/schrijfverzoekgrootte.
In de onderstaande afbeelding ziet u een grafiek van de prestaties van de VM-schijf, waarin u het aantal IOPS, de latentie en de blokgrootte kunt zien.
U kunt ook prestatiestatistieken voor de gehele datastore bekijken als SIOC is ingeschakeld. Hier vindt u basisinformatie over de gemiddelde latentie en IOPS. Standaard kan deze informatie alleen in realtime worden bekeken.
ESXTOP
ESXTOP heeft verschillende schermen die informatie bieden over het hostschijfsubsysteem als geheel, individuele virtuele machines en hun schijven.
Laten we beginnen met informatie over virtuele machines. Met de toets “v” wordt het scherm “Disk VM” opgeroepen:
NVDISK is het aantal VM-schijven. Om informatie voor elke schijf te bekijken, drukt u op “e” en voert u de GID van de betreffende VM in.
De betekenis van de overige parameters op dit scherm blijkt duidelijk uit hun namen.
Een ander handig scherm bij het oplossen van problemen is Schijfadapter. Opgeroepen door de “d”-toets (velden A,B,C,D,E,G zijn geselecteerd in de onderstaande afbeelding):
NPTH – het aantal paden naar de manen die zichtbaar zijn vanaf deze adapter. Om informatie te krijgen voor elk pad op de adapter, drukt u op “e” en voert u de naam van de adapter in:
AQLEN – maximale wachtrijgrootte op de adapter.
Ook op dit scherm staan de vertragingstellers waar ik het hierboven over had: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.
Het scherm Schijfapparaat, dat wordt opgeroepen door op de “u”-toets te drukken, geeft informatie over individuele blokapparaten - manen (velden A, B, F, G, I zijn geselecteerd in de onderstaande afbeelding). Hier kunt u de status van de wachtrij voor de manen zien.
DQLEN – wachtrijgrootte voor een blokapparaat.
ACTV – aantal I/O-opdrachten in de ESXi-kernel.
VRAAG – aantal I/O-opdrachten in de wachtrij.
%AMERIKAANSE DOLLAR – ACTV / DQLEN × 100%.
LOAD – (ACTV + QUED) / DQLEN.
Als %USD hoog is, kunt u overwegen de wachtrij te vergroten. Hoe meer opdrachten in de wachtrij, hoe hoger de QAVG en dienovereenkomstig de KAVG.
U kunt ook op het scherm Schijfapparaat zien of VAAI (vStorage API for Array Integration) op het opslagsysteem draait. Selecteer hiervoor de velden A en O.
Met het VAAI-mechanisme kunt u een deel van het werk van de hypervisor rechtstreeks naar het opslagsysteem overbrengen, bijvoorbeeld op nul zetten, blokken kopiëren of blokkeren.
Zoals je op de foto hierboven kunt zien, werkt VAAI aan dit opslagsysteem: er wordt actief gebruik gemaakt van Zero- en ATS-primitieven.
Tips voor het optimaliseren van het werk met het schijfsubsysteem op ESXi
- Let op de blokgrootte.
- Stel de optimale wachtrijgrootte in op de HBA.
- Vergeet niet SIOC in te schakelen voor datastores.
- Kies een PSP in overeenstemming met de aanbevelingen van de fabrikant van het opslagsysteem.
- Zorg ervoor dat VAAI werkt.
Handige artikelen over het onderwerp:
Bron: www.habr.com