Teljesítmény optimalizálása Lsv3, Lasv3 és Lsv2 sorozatú Linux rendszerű virtuális gépeken

  • Cikk

Figyelemfelhívás

Ez a cikk a CentOS-ra, egy olyan Linux-disztribúcióra hivatkozik, amely közel áll az élettartam (EOL) állapotához. Fontolja meg a használatát, és ennek megfelelően tervezze meg. További információ: CentOS End Of Life útmutató.

A következőkre vonatkozik: ✔️ Linux rendszerű virtuális gépek egységes méretezési ✔️ csoportjai

Az Lsv3, a Lasv3 és az Lsv2 sorozatú Azure-beli virtuális gépek (Azure-beli virtuális gépek) számos olyan számítási feladatot támogatnak, amelyeknek nagy I/O-ra és átviteli sebességre van szükségük a helyi tárterületen az alkalmazások és iparágak széles körében. Az L sorozat ideális big data- és SQL-, NoSQL-adatbázisokhoz, adattárházakhoz és nagy tranzakciós adatbázisokhoz, például Cassandra, MongoDB, Cloudera és Redis adatbázisokhoz.

Több build is elérhető az Azure Marketplace-en a linuxos partnerekkel való együttműködés miatt. Ezek a buildek az Lsv3, a Lasv3 és az Lsv2 sorozat teljesítményére vannak optimalizálva. Az elérhető buildek a következő és újabb verziókat tartalmazzák:

  • Ubuntu 16.04
  • RHEL 8.0 és klónok, például CentOS, Rocky Linux és Alma Linux
  • Debian 9
  • SU Standard kiadás Linux 15
  • Oracle Linux 8.0

Ez a cikk tippeket és javaslatokat tartalmaz annak biztosítására, hogy a számítási feladatok és alkalmazások a virtuális gépekre tervezett maximális teljesítményt érjék el.

AMD EPYC™ lapkakészlet architektúrája

A Lasv3 és az Lsv2 sorozatú virtuális gépek a Zen mikroarchitektúrán alapuló AMD EPYC-kiszolgálóprocesszorokat™ használnak. Az AMD az EPYC-hez™ kifejlesztett Infinity Fabricet (IF) skálázható összekötőként a NUMA-modellhez, amely felhasználható a helyszíni, a csomagon belüli és a többcsomagos kommunikációhoz. Az Intel modern monolitikus die processzorokon használt QPI -val (Quick-Path Interconnect) és UPI-vel (Ultra-Path Interconnect) összehasonlítva az AMD több NUMA kis die architektúrája teljesítménybeli előnyöket és kihívásokat is jelenthet. A memória sávszélességének és késési korlátainak tényleges hatásai a futó számítási feladatok típusától függően változhatnak.

Tippek a teljesítmény maximalizálása érdekében

  • Ha egyéni Linux GuestOS-t tölt fel a számítási feladathoz, a gyorsított hálózatkezelés alapértelmezés szerint ki van kapcsolva. Ha engedélyezni szeretné a gyorsított hálózatkezelést, engedélyezze azt a virtuális gép létrehozásakor a legjobb teljesítmény érdekében.
  • A maximális teljesítmény eléréséhez eszközenként több feladatot futtathat mély üzenetsor-mélységgel.
  • Ne keverje az NVMe felügyeleti parancsait (például NVMe SMART-információs lekérdezést stb.) az NVMe I/O-parancsokkal az aktív számítási feladatok során. Az Lsv3, a Lasv3 és az Lsv2 NVMe-eszközöket a Hyper-V NVMe Direct technológia biztosítja, amely "lassú üzemmódra" vált, amikor bármilyen NVMe-rendszergazdai parancs függőben van. Az Lsv3, a Lasv3 és az Lsv2 felhasználók drámai teljesítménycsökkenést tapasztalhatnak az NVMe I/O teljesítményében, ha ez történik.
  • Az Lsv2-felhasználók számára nem ajánlott az eszköz NUMA-információira (mind a 0) támaszkodniuk a virtuális gépről az adatmeghajtók számára, hogy eldöntsék az alkalmazásuk NUMA-affinitását. A jobb teljesítmény érdekében ajánlott a számítási feladatokat a processzorok között elosztani, ha lehetséges.
  • Az Lsv3, a Lasv3 és az Lsv2 VM NVMe-eszköz I/O-üzenetsorpáronkénti maximális támogatott üzenetsor-mélysége 1024. Az Lsv3, a Lasv3 és az Lsv2 felhasználók számára javasoljuk, hogy a (szintetikus) teljesítménymérési számítási feladataikat az 1024-ben vagy annál alacsonyabb várólistamélységben korlátozzák, hogy ne aktiválják a várólista teljes feltételeit, ami csökkentheti a teljesítményt.
  • A legjobb teljesítmény akkor érhető el, ha az I/O közvetlenül az összes nyers NVMe-eszközre történik particionálás nélkül, fájlrendszerek nélkül, RAID konfiguráció nélkül stb. A tesztelési munkamenet megkezdése előtt győződjön meg arról, hogy a konfiguráció ismert friss/tiszta állapotban van az egyes NVMe-eszközökön való futtatással blkdiscard . A teljesítménytesztelés során a legkonzisztensebb teljesítmény elérése érdekében javasoljuk, hogy az NVMe-eszközöket a tesztelés előtt előkonfigurálja úgy, hogy véletlenszerű írásokat ad ki az összes eszköz LBA-jának kétszer, az SNIA Solid State Storage vállalati teljesítményteszt-specifikációjában meghatározottak szerint.

Helyi NVMe-tároló használata

Az 1,92 TB-os NVMe lemez helyi tárolója az összes Lsv3, Lasv3 és Lsv2 virtuális gépen rövid élettartamú. A virtuális gép sikeres szabványos újraindítása során a helyi NVMe-lemez adatai megmaradnak. Az adatok nem maradnak meg az NVMe-en, ha a virtuális gépet újra üzembe helyezték, felszabadították vagy törölték. Az adatok nem maradnak fenn, ha egy másik probléma miatt a virtuális gép vagy a rajta futó hardver állapota nem megfelelő. Forgatókönyv esetén a régi gazdagépen lévő adatok biztonságosan törlődnek.

Vannak olyan esetek is, amikor a virtuális gépet át kell helyezni egy másik gazdagépre, például egy tervezett karbantartási művelet során. Ütemezett események esetén a tervezett karbantartási műveletek és bizonyos hardverhibák várhatók. Ütemezett események használatával naprakész maradhat az előrejelzett karbantartási és helyreállítási műveleteken.

Abban az esetben, ha egy tervezett karbantartási eseményhez a virtuális gépet újra létre kell hozni egy üres helyi lemezekkel rendelkező új gazdagépen, az adatokat újraszinkronizálni kell (ismét a régi gazdagépen lévő összes adatot biztonságosan törölni kell). Ez a forgatókönyv azért fordul elő, mert az Lsv3, a Lasv3 és az Lsv2 sorozatú virtuális gépek jelenleg nem támogatják az élő áttelepítést a helyi NVMe-lemezen.

A tervezett karbantartásnak két módja van.

Standard virtuális gép ügyfél által vezérelt karbantartása

  • A virtuális gép egy 30 napos időszak alatt egy frissített gazdagépre kerül.
  • Az Lsv3, a Lasv3 és az Lsv2 helyi tárolási adatok elveszhetnek, ezért az esemény előtti biztonsági mentés javasolt.

Automatikus karbantartás

  • Akkor fordul elő, ha az ügyfél nem hajtja végre az ügyfél által ellenőrzött karbantartást, vagy vészhelyzeti eljárások, például egy nulla napos biztonsági esemény miatt.
  • Az ügyféladatok megőrzésére szolgál, de a virtuális gépek lefagyásának vagy újraindításának kicsi a kockázata.
  • Az Lsv3, a Lasv3 és az Lsv2 helyi tárolási adatok elveszhetnek, ezért az esemény előtti biztonsági mentés javasolt.

A közelgő szervizesemények esetén az ellenőrzött karbantartási folyamattal válassza ki a legmegfelelőbb időpontot a frissítéshez. Az esemény előtt biztonsági másolatot készít az adatokról a prémium szintű tárterületen. A karbantartási esemény befejeződése után visszaadhatja az adatokat a frissített Lsv3, Lasv3 és Lsv2 virtuális gépek helyi NVMe-tárolójához.

A helyi NVMe-lemezeken adatokat karbantartó forgatókönyvek a következők:

  • A virtuális gép fut és kifogástalan állapotban van.
  • A virtuális gép újraindul a helyén (Ön vagy az Azure).
  • A virtuális gép szüneteltetve van (felszabadítás nélkül leáll).
  • A legtöbb tervezett karbantartási karbantartási művelet.

Az ügyfelek védelme érdekében az adatok biztonságos törlésére szolgáló forgatókönyvek a következők:

  • A virtuális gép üzembe helyezése, leállítása (felszabadítása) vagy törlése (Ön által).
  • A virtuális gép nem megfelelő állapotúvá válik, és hardverhiba miatt egy másik csomóponton kell szervizelnie.
  • Néhány tervezett karbantartási karbantartási művelet, amelyek megkövetelik, hogy a virtuális gépet egy másik gazdagépre helyezze át karbantartás céljából.

Gyakori kérdések

Az alábbi kérdések gyakran merülnek fel ezekkel a sorozatokkal kapcsolatban.

Hogyan megkezdi az L sorozatú virtuális gépek üzembe helyezését?

A többi virtuális géphez hasonlóan a Portál, az Azure CLI vagy a PowerShell használatával is létrehozhat virtuális gépet.

Egyetlen NVMe-lemezhiba miatt a gazdagép összes virtuális gépe meghibásodik?

Ha lemezhiba észlelhető a hardvercsomóponton, a hardver meghibásodott állapotban van. Ha ez a probléma jelentkezik, a rendszer automatikusan felszabadítja a csomópont összes virtuális gépét, és áthelyezi egy kifogástalan állapotú csomópontra. Az Lsv3, a Lasv3 és az Lsv2 sorozatú virtuális gépek esetében ez a probléma azt jelenti, hogy az ügyfél adatai a hibás csomóponton is biztonságosan törlődnek. Az ügyfélnek újra létre kell hoznia az adatokat az új csomóponton.

Módosítani kell a blk_mq beállításait?

Az RHEL/CentOS 7.x automatikusan blk-mq-t használ az NVMe-eszközökhöz. Nincs szükség konfigurációs módosításokra vagy beállításokra.

Következő lépések

Az Azure-beli tárolási teljesítményre optimalizált összes virtuális gép specifikációinak megtekintése