Prestaties optimaliseren op Linux-VM's uit de Linux-serie Lsv3, Lasv3 en Lsv2

  • Artikel

Let op

In dit artikel wordt verwezen naar CentOS, een Linux-distributie die de status End Of Life (EOL) nadert. Houd rekening met uw gebruik en plan dienovereenkomstig. Zie de Richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

Van toepassing op: ✔️ Uniforme schaalsets voor Linux-VM's ✔️

Lsv3, Lasv3 en Lsv2-serie Azure Virtual Machines (Azure-VM's) ondersteunen verschillende workloads die een hoge I/O-doorvoer nodig hebben voor lokale opslag in een breed scala aan toepassingen en branches. De L-serie is ideaal voor Big Data, SQL, NoSQL-databases, datawarehousing en grote transactionele databases, waaronder Cassandra, MongoDB, Cloudera en Redis.

Er zijn verschillende builds beschikbaar in Azure Marketplace vanwege samenwerking met partners in Linux. Deze builds zijn geoptimaliseerd voor prestaties van de Lsv3-, Lasv3- en Lsv2-serie. Beschikbare builds bevatten de volgende en latere versies van:

  • Ubuntu 16.04
  • RHEL 8.0 en klonen, waaronder CentOS, Rocky Linux en Alma Linux
  • Debian 9
  • SUSE Linux 15
  • Oracle Linux 8.0

Dit artikel bevat tips en suggesties om ervoor te zorgen dat uw workloads en toepassingen de maximale prestaties bereiken die zijn ontworpen voor de VM's.

AMD EPYC-chipsetarchitectuur™

Vm's uit de Lasv3- en Lsv2-serie maken gebruik van AMD EPYC-serverprocessors™ op basis van de Zen-microarchitectuur. AMD ontwikkelde Infinity Fabric (IF) voor EPYC™ als schaalbare interconnect voor het NUMA-model dat kan worden gebruikt voor on-die,on-package en communicatie met meerdere pakketten. Vergeleken met QPI (Quick-Path Interconnect) en UPI (Ultra-Path Interconnect) die worden gebruikt op moderne monolithische processors van Intel, kan de veel-NUMA small-die-architectuur van AMD zowel prestatievoordelen als uitdagingen opleveren. De werkelijke effecten van geheugenbandbreedte en latentiebeperkingen kunnen variëren, afhankelijk van het type werkbelastingen dat wordt uitgevoerd.

Tips om de prestaties te maximaliseren

  • Als u een aangepaste Linux GuestOS voor uw workload uploadt, is Versneld netwerken standaard uitgeschakeld. Als u versneld netwerken wilt inschakelen, schakelt u deze in op het moment dat de VM wordt gemaakt voor de beste prestaties.
  • Voor maximale prestaties voert u meerdere taken uit met diepte van de wachtrij per apparaat.
  • Vermijd het combineren van NVMe-beheeropdrachten (bijvoorbeeld NVMe SMART info-query, enzovoort) met NVMe I/O-opdrachten tijdens actieve werkbelastingen. Lsv3-, Lasv3- en Lsv2 NVMe-apparaten worden ondersteund door Hyper-V NVMe Direct-technologie, die wordt overgeschakeld naar de 'trage modus' wanneer eventuele NVMe-beheeropdrachten in behandeling zijn. Lsv3-, Lasv3- en Lsv2-gebruikers zien mogelijk een aanzienlijke daling van de prestaties van NVMe I/O als dat gebeurt.
  • Lsv2-gebruikers worden niet aangeraden om te vertrouwen op NUMA-gegevens van apparaten (alle 0) die zijn gerapporteerd vanuit de VM voor gegevensstations om de NUMA-affiniteit voor hun apps te bepalen. De aanbevolen manier voor betere prestaties is om workloads over CPU's te verdelen, indien mogelijk.
  • De maximale ondersteunde wachtrijdiepte per I/O-wachtrijpaar voor Lsv3-, Lasv3- en Lsv2 VM NVMe-apparaat is 1024. Lsv3-, Lasv3- en Lsv2-gebruikers worden aanbevolen om hun (synthetische) benchmarkingworkloads te beperken tot wachtrijdiepte 1024 of lager om te voorkomen dat volledige wachtrijvoorwaarden worden geactiveerd, waardoor de prestaties kunnen worden verminderd.
  • De beste prestaties worden verkregen wanneer I/O rechtstreeks wordt uitgevoerd op elk van de onbewerkte NVMe-apparaten zonder partitionering, geen bestandssystemen, geen RAID-configuratie, enzovoort. Voordat u een testsessie start, moet u ervoor zorgen dat de configuratie een bekende nieuwe/schone status heeft door op elk van de NVMe-apparaten te worden uitgevoerd blkdiscard . Voor het verkrijgen van de meest consistente prestaties tijdens benchmarking, is het raadzaam om de NVMe-apparaten vooraf te stellen voordat ze worden getest door willekeurige schrijfbewerkingen uit te voeren naar alle LBA's van de apparaten twee keer zoals gedefinieerd in de SNIA Solid State Storage Enterprise Performance Test Specification.

Lokale NVMe-opslag gebruiken

Lokale opslag op de NVMe-schijf van 1,92 TB op alle Lsv3-, Lasv3- en Lsv2-VM's is kortstondig. Tijdens een geslaagde standaardstart van de virtuele machine blijven de gegevens op de lokale NVMe-schijf behouden. De gegevens blijven niet behouden op de NVMe als de VIRTUELE machine opnieuw wordt geïmplementeerd, de toewijzing ervan ongedaan wordt gemaakt of verwijderd. Gegevens blijven niet behouden als een ander probleem ervoor zorgt dat de VIRTUELE machine, of de hardware waarop deze wordt uitgevoerd, beschadigd raakt. Wanneer het scenario zich voordoet, worden alle gegevens op de oude host veilig gewist.

Er zijn ook gevallen waarin de VM moet worden verplaatst naar een andere hostmachine, bijvoorbeeld tijdens een geplande onderhoudsbewerking. Geplande onderhoudsbewerkingen en sommige hardwarefouten kunnen worden verwacht met geplande gebeurtenissen. Gebruik Geplande gebeurtenissen om op de hoogte te blijven van voorspeld onderhoud en herstelbewerkingen.

In het geval dat een geplande onderhoudsgebeurtenis vereist dat de VIRTUELE machine opnieuw wordt gemaakt op een nieuwe host met lege lokale schijven, moeten de gegevens opnieuw worden gesynchroniseerd (opnieuw, waarbij gegevens op de oude host veilig worden gewist). Dit scenario treedt op omdat VM's uit de Lsv3-, Lasv3- en Lsv2-serie momenteel geen ondersteuning bieden voor livemigratie op de lokale NVMe-schijf.

Er zijn twee modi voor gepland onderhoud.

Door de klant beheerde standaard-VM-onderhoud

  • De VIRTUELE machine wordt tijdens een periode van 30 dagen verplaatst naar een bijgewerkte host.
  • Lsv3-, Lasv3- en Lsv2-lokale opslaggegevens kunnen verloren gaan, dus het maken van back-ups van gegevens voorafgaand aan de gebeurtenis wordt aanbevolen.

Automatisch onderhoud

  • Treedt op als de klant geen door de klant beheerd onderhoud uitvoert of vanwege noodprocedures, zoals een zero-day-beveiligingsgebeurtenis.
  • Bedoeld om klantgegevens te behouden, maar er is een klein risico dat een VIRTUELE machine wordt geblokkeerd of opnieuw wordt opgestart.
  • Lsv3-, Lasv3- en Lsv2-lokale opslaggegevens kunnen verloren gaan, dus het maken van back-ups van gegevens voorafgaand aan de gebeurtenis wordt aanbevolen.

Voor toekomstige servicegebeurtenissen gebruikt u het beheerde onderhoudsproces om een tijd te selecteren die het handigst is voor de update. Maak vóór de gebeurtenis een back-up van uw gegevens in Premium Storage. Nadat de onderhoudsgebeurtenis is voltooid, kunt u uw gegevens retourneren naar de vernieuwde Lsv3-, Lasv3- en Lsv2-VM's lokale NVMe-opslag.

Scenario's voor het onderhouden van gegevens op lokale NVMe-schijven zijn:

  • De VM wordt uitgevoerd en is in orde.
  • De VIRTUELE machine wordt opnieuw opgestart (door u of Azure).
  • De VIRTUELE machine is onderbroken (gestopt zonder deallocatie).
  • De meeste geplande onderhoudswerkzaamheden.

Scenario's waarbij gegevens veilig worden gewist om de klant te beveiligen, zijn onder andere:

  • De VIRTUELE machine is opnieuw geïmplementeerd, gestopt (toewijzing ongedaan gemaakt) of verwijderd (door u).
  • De VM wordt beschadigd en moet worden hersteld naar een ander knooppunt vanwege een hardwareprobleem.
  • Een paar van de geplande onderhoudsbewerkingen waarvoor de VIRTUELE machine opnieuw moet worden toegewezen aan een andere host voor onderhoud.

Veelgestelde vragen

Hieronder vindt u veelgestelde vragen over deze reeks.

Hoe kan ik beginnen met het implementeren van VM's uit de L-serie?

Net als bij andere VM's gebruikt u de portal, Azure CLI of PowerShell om een virtuele machine te maken.

Mislukt er één NVMe-schijffout waardoor alle VM's op de host mislukken?

Als er een schijffout wordt gedetecteerd op het hardwareknooppunt, heeft de hardware de status Mislukt. Wanneer dit probleem optreedt, worden alle VM's op het knooppunt automatisch de toewijzing ongedaan gemaakt en verplaatst naar een goed functionerend knooppunt. Voor VM's uit de Lsv3-, Lasv3- en Lsv2-serie betekent dit probleem dat de gegevens van de klant op het mislukte knooppunt ook veilig worden gewist. De klant moet de gegevens opnieuw maken op het nieuwe knooppunt.

Moet ik de blk_mq-instellingen wijzigen?

RHEL/CentOS 7.x gebruikt automatisch blk-mq voor de NVMe-apparaten. Er zijn geen configuratiewijzigingen of -instellingen nodig.

Volgende stappen

Bekijk specificaties voor alle VM's die zijn geoptimaliseerd voor opslagprestaties in Azure