Optimera prestanda på virtuella Datorer i Lsv3, Lasv3 och Lsv2-serien för Linux

  • Artikel

Varning

Den här artikeln refererar till CentOS, en Linux-distribution som närmar sig EOL-status (End Of Life). Överväg att använda och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledningen.

Gäller för: ✔️ Enhetliga skalningsuppsättningar för virtuella Linux-datorer ✔️

Lsv3, Lasv3 och Lsv2-serien Azure Virtual Machines (virtuella Azure-datorer) stöder olika arbetsbelastningar som behöver hög I/O och dataflöde på lokal lagring i en mängd olika program och branscher. L-serien är perfekt för Stordata, SQL, NoSQL-databaser, datalager och stora transaktionsdatabaser, inklusive Cassandra, MongoDB, Cloudera och Redis.

Flera versioner är tillgängliga på Azure Marketplace på grund av samarbete med partner i Linux. Dessa versioner är optimerade för Lsv3-, Lasv3- och Lsv2-seriens prestanda. Tillgängliga versioner omfattar följande och senare versioner av:

  • Ubuntu 16.04
  • RHEL 8.0 och kloner, inklusive CentOS, Rocky Linux och Alma Linux
  • Debian 9
  • SUSE Linux 15
  • Oracle Linux 8.0

Den här artikeln innehåller tips och förslag för att säkerställa att dina arbetsbelastningar och program uppnår maximal prestanda som utformats för de virtuella datorerna.

ARKITEKTUR för AMD EPYC-kretsuppsättning™

Virtuella datorer i Lasv3- och Lsv2-serien använder AMD EPYC-serverprocessorer™ baserat på Zen-mikroarkitekturen. AMD utvecklade Infinity Fabric (IF) för EPYC™ som skalbar sammankoppling för sin NUMA-modell som kan användas för kommunikation på tärning, paket och flera paket. Jämfört med QPI (Quick-Path Interconnect) och UPI (Ultra-Path Interconnect) som används på intels moderna monolitiska die-processorer kan AMD:s arkitektur med många NUMA-små tärningar ge både prestandafördelar och utmaningar. De faktiska effekterna av begränsningar för minnesbandbredd och svarstid kan variera beroende på vilken typ av arbetsbelastningar som körs.

Tips för att maximera prestanda

  • Om du laddar upp en anpassad Linux GuestOS för din arbetsbelastning är accelererat nätverk inaktiverat som standard. Om du tänker aktivera accelererat nätverk aktiverar du det när den virtuella datorn skapas för bästa prestanda.
  • För att få maximal prestanda kör du flera jobb med djup ködjup per enhet.
  • Undvik att blanda NVMe-administratörskommandon (till exempel NVMe SMART-informationsfråga osv.) med NVMe I/O-kommandon under aktiva arbetsbelastningar. Lsv3-, Lasv3- och Lsv2 NVMe-enheter backas upp av Hyper-V NVMe Direct-teknik, som växlar till "långsamt läge" när eventuella NVMe-administratörskommandon väntar. Lsv3-, Lasv3- och Lsv2-användare kan se en dramatisk prestandaminskning i NVMe I/O-prestanda om det händer.
  • Lsv2-användare rekommenderas inte att förlita sig på enhetens NUMA-information (alla 0) som rapporteras inifrån den virtuella datorn för att dataenheter ska kunna bestämma NUMA-tillhörigheten för sina appar. Det rekommenderade sättet för bättre prestanda är att sprida arbetsbelastningar mellan processorer om möjligt.
  • Det maximala ködjupet per I/O-köpar för Lsv3-, Lasv3- och Lsv2 VM NVMe-enhet är 1024. Lsv3-, Lasv3- och Lsv2-användare rekommenderas att begränsa sina (syntetiska) benchmarkingarbetsbelastningar till ködjup 1024 eller lägre för att undvika att utlösa fullständiga köförhållanden, vilket kan minska prestandan.
  • Bästa prestanda erhålls när I/O görs direkt till var och en av de råa NVMe-enheterna utan partitionering, inga filsystem, ingen RAID-konfiguration osv. Innan du startar en testsession kontrollerar du att konfigurationen är i ett känt nytt/rent tillstånd genom att köra blkdiscard på var och en av NVMe-enheterna. För att få den mest konsekventa prestandan under benchmarking rekommenderar vi att du förhandsvillkorar NVMe-enheterna innan du testar genom att utfärda slumpmässiga skrivningar till alla enheternas lbas två gånger enligt definitionen i prestandatestspecifikationen för SNIA Solid State Storage Enterprise.

Använda lokal NVMe-lagring

Lokal lagring på 1,92 TB NVMe-disken på alla virtuella Lsv3-, Lasv3- och Lsv2-datorer är tillfälliga. Under en lyckad standardomstart av den virtuella datorn sparas data på den lokala NVMe-disken. Data sparas inte på NVMe om den virtuella datorn omdistribueras, frigörs eller tas bort. Data bevaras inte om ett annat problem gör att den virtuella datorn, eller maskinvaran som den körs på, inte är felfri. När scenariot inträffar raderas alla data på den gamla värden på ett säkert sätt.

Det finns också fall då den virtuella datorn måste flyttas till en annan värddator, till exempel under en planerad underhållsåtgärd. Planerade underhållsåtgärder och vissa maskinvarufel kan förväntas med schemalagda händelser. Använd Schemalagda händelser för att hålla dig uppdaterad om eventuella förväntade underhålls- och återställningsåtgärder.

Om en planerad underhållshändelse kräver att den virtuella datorn återskapas på en ny värd med tomma lokala diskar måste data omsynkroniseras (återigen med alla data på den gamla värden som raderas på ett säkert sätt). Det här scenariot beror på att virtuella datorer i Lsv3, Lasv3 och Lsv2-serien för närvarande inte stöder direktmigrering på den lokala NVMe-disken.

Det finns två lägen för planerat underhåll.

Kundkontrollerat underhåll för virtuell standarddator

  • Den virtuella datorn flyttas till en uppdaterad värd under ett 30-dagarsfönster.
  • Lokala Lsv3-, Lasv3- och Lsv2-lagringsdata kan gå förlorade, så säkerhetskopiering av data före händelsen rekommenderas.

Automatiskt underhåll

  • Inträffar om kunden inte utför kundkontrollerat underhåll eller på grund av nödprocedurer, till exempel en säkerhetshändelse utan dag.
  • Avsett att bevara kunddata, men det finns en liten risk för att en virtuell dator fryser eller startas om.
  • Lokala Lsv3-, Lasv3- och Lsv2-lagringsdata kan gå förlorade, så säkerhetskopiering av data före händelsen rekommenderas.

För kommande tjänsthändelser använder du den kontrollerade underhållsprocessen för att välja en tid som passar dig bäst för uppdateringen. Säkerhetskopiera dina data i Premium Storage före händelsen. När underhållshändelsen är klar kan du returnera dina data till den uppdaterade lokala NVMe-lagringen för Lsv3, Lasv3 och Lsv2.

Scenarier som underhåller data på lokala NVMe-diskar är:

  • Den virtuella datorn körs och är felfri.
  • Den virtuella datorn startas om på plats (av dig eller Azure).
  • Den virtuella datorn har pausats (stoppas utan frigöring).
  • De flesta planerade underhållsunderhållsåtgärder.

Scenarier som på ett säkert sätt raderar data för att skydda kunden är:

  • Den virtuella datorn distribueras om, stoppas (frigörs) eller tas bort (av dig).
  • Den virtuella datorn blir inte felfri och måste repareras till en annan nod på grund av ett maskinvaruproblem.
  • Några av de planerade underhållsunderhållsåtgärder som kräver att den virtuella datorn omallokeras till en annan värd för service.

Vanliga frågor och svar

Följande är vanliga frågor och svar om dessa serier.

Hur gör jag för att börja distribuera virtuella datorer i L-serien?

Precis som andra virtuella datorer använder du portalen, Azure CLI eller PowerShell för att skapa en virtuell dator.

Gör ett enskilt NVMe-diskfel att alla virtuella datorer på värden misslyckas?

Om ett diskfel identifieras på maskinvarunoden är maskinvaran i ett feltillstånd. När det här problemet uppstår frigörs automatiskt alla virtuella datorer på noden och flyttas till en felfri nod. För virtuella datorer i Lsv3-, Lasv3- och Lsv2-serien innebär det här problemet att kundens data på noden som misslyckas också raderas på ett säkert sätt. Kunden måste återskapa data på den nya noden.

Behöver jag ändra inställningarna för blk_mq?

RHEL/CentOS 7.x använder automatiskt blk-mq för NVMe-enheterna. Inga konfigurationsändringar eller inställningar krävs.

Nästa steg

Se specifikationer för alla virtuella datorer som är optimerade för lagringsprestanda i Azure