Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Ez a cikk segít megérteni az Azure NetApp Files SMB-teljesítményét és ajánlott eljárásait.
SMB többcsatornás
A többcsatornás SMB alapértelmezés szerint engedélyezve van az SMB-megosztásokban. A meglévő SMB-kötetek összes SMB-megosztásához engedélyezve van a funkció; az összes újonnan létrehozott köteten engedélyezve van a funkció a létrehozáskor.
A funkció engedélyezése előtt létrehozott SMB-kapcsolatokat alaphelyzetbe kell állítani az SMB Többcsatornás funkció előnyeinek kihasználásához. Az alaphelyzetbe állításhoz leválaszthatja és újra csatlakoztathatja az SMB-megosztást.
A Windows támogatja a Többcsatornás SMB-t a Windows 2012 óta a legjobb teljesítmény érdekében. Részletekért tekintse meg az SMB Multichannel üzembe helyezését és az SMB Multichannel alapjait.
Az SMB többcsatornás előnyei
Az SMB Többcsatornás funkció lehetővé teszi az SMB3-ügyfél számára, hogy egy hálózati adapteren vagy több hálózati adapteren keresztül létesítsen kapcsolatkészletet, és egyetlen SMB-munkamenetre vonatkozó kérések küldéséhez használja őket. Ezzel szemben az SMB1 és az SMB2 esetében az ügyfélnek egy kapcsolatot kell létrehoznia, és egy adott munkamenet összes SMB-forgalmát ezen a kapcsolaton keresztül kell elküldenie. Ez az egyetlen kapcsolat korlátozza az egyetlen ügyfél által elérhető teljes protokollteljesítményt.
Az SMB többcsatornás teljesítménye
Az alábbi tesztek és grafikonok bemutatják az SMB Multichannel teljesítményét az egypéldányos számítási feladatokon.
Véletlen I/O műveletek
Mivel az SMB Multichannel le van tiltva a kliensen, tiszta, négy KiB méretű olvasási és írási teszteket hajtottak végre az FIO és egy 40 GiB méretű munkakészlet használatával. Az SMB-megosztás minden teszt között le lett választva, miközben az SMB-ügyfélkapcsolatok számának növekményeit a fogadó oldali skálázás hálózati adapter beállítása szerint hajtották végre: , 1, 4, 8, 16, és set-SmbClientConfiguration -ConnectionCountPerRSSNetworkInterface <count>. A tesztek azt mutatják, hogy az alapértelmezett beállítás 4 elegendő az I/O-igényes számítási feladatokhoz; a 8 és 16 értékekre való növelés elhanyagolható hatással volt.
A netstat -na | findstr 445 parancs bebizonyította, hogy további kapcsolatok lettek létrehozva az 1 -től 4 -ig, 4 -tól 8 -ig, és 8 -től 16 -ig növekményekkel. Minden teszt során négy processzormagot használtak fel teljes mértékben az SMB-hez, amit a perfmon Per Processor Network Activity Cycles statisztikája is megerősített (ez a cikk nem tartalmazza).)
Az Azure-beli virtuális gép (VM) nem befolyásolja az SMB (és az NFS) tárolási I/O-korlátait. Az alábbi diagramon látható módon a D32ds-példány típusa korlátozottan 308 000-es sebességgel rendelkezik a gyorsítótárazott tároló I/OPS-hez, 51 200 pedig a nem gyorsítótárazott tároló I/OPS-hez. A fenti grafikon azonban jelentősen több I/O-t mutat az SMB-n keresztül.
Szekvenciális I/O
A korábban ismertetett véletlenszerű I/O-tesztekhez hasonló teszteket 64 KiB szekvenciális I/O-val hajtottak végre. Bár az RSS-hálózati adapterenkénti ügyfélkapcsolatok számának négynél nagyobb növekedése nem volt észrevehető hatással a véletlenszerű I/O-ra, ugyanez nem vonatkozik a szekvenciális I/O-ra. Ahogy az alábbi grafikon is mutatja, minden egyes növekedés az olvasási sebesség megfelelő növekedésével van társítva. Az írási átviteli sebesség nem változott az Azure által az egyes példánytípusokra és -méretekre vonatkozó hálózati sávszélesség-korlátozások miatt.
Az Azure hálózati sebességkorlátokat helyez el az egyes virtuális gépek típusán és méretén. A sebességkorlát csak a kimenő forgalomra vonatkozik. A virtuális gépen található hálózati adapterek száma nem befolyásolja a gép számára elérhető teljes sávszélességet. A D32ds-példány típusa például másodpercenként 16 000 MB(2000 MiB/s) hálózati korlátot ír elő. Ahogy a fenti szekvenciális grafikon is mutatja, a korlát a kimenő forgalmat (írásokat) érinti, a többcsatornás olvasásokat azonban nem.
SMB-aláírás
Az SMB protokoll biztosítja a fájl- és nyomtatómegosztás, valamint más hálózati műveletek, például a Távoli Windows-felügyelet alapjait. Az SMB-csomagok átvitele során az SMB-csomagokat módosító, középen belüli támadások megakadályozása érdekében az SMB protokoll támogatja az SMB-csomagok digitális aláírását.
Az SMB-aláírás az Azure NetApp Files által támogatott összes SMB protokollverzió esetében támogatott.
Az SMB-aláírás teljesítményre gyakorolt hatása
Az SMB-aláírás káros hatással van az SMB teljesítményére. A teljesítménycsökkenés egyéb lehetséges okai között az egyes csomagok digitális aláírása további ügyféloldali CPU-t használ fel, ahogy az alábbi perfmon kimenet is mutatja. Ebben az esetben a Core 0 felelős az SMB-ért, beleértve az SMB-aláírást is. Az előző szakaszban szereplő nem többcsatornás szekvenciális olvasási átviteli sebesség számával való összehasonlítás azt mutatja, hogy az SMB-aláírás a teljes átviteli sebességet 875MiB/s-ről körülbelül 250MiB/s-ra csökkenti.
1 TB-os adatkészlettel rendelkező egyetlen példány teljesítménye
Az alábbi két diagram egy 50 TB-os, nagy teljesítményű felhőszolgáltatási szintű tároló teljesítményét mutatja be, 1 TB-os adatkészlettel és 4-es SMB többcsatornás konfigurációval, hogy részletesebb betekintést nyújtson az olvasási/írási keverékekkel dolgozó számítási feladatokba. A 16-os optimális IODepth értéket használták; Rugalmas I/O (FIO) paraméterekkel biztosították a hálózati sávszélesség (numjobs=16) teljes kihasználását.
Az alábbi diagram a 4 KiB véletlenszerű I/O-ra vonatkozó eredményeket mutatja be egyetlen virtuálisgép-példánysal és 10%-os időközökkel rendelkező olvasási/írási keverékkel:
Az alábbi diagram a szekvenciális I/O-hoz tartozó eredményeket mutatja:
Teljesítmény 5 virtuális gép 1 TB-os adatkészlettel történő horizontális felskálázása esetén
Ezek az 5 virtuális géppel végzett tesztek ugyanazt a tesztelési környezetet használják, mint az egyetlen virtuális gép, és mindegyik folyamat a saját fájljára ír.
Az alábbi diagramon a véletlenszerű I/O-k eredményei láthatók:
Az alábbi diagram a szekvenciális I/O-hoz tartozó eredményeket mutatja:
Hyper-V ethernet-adapterek monitorozása
A FIO-val végzett tesztelés egyik stratégiája az, hogy beállítjuk numjobs=16. Ezzel a művelettel minden egyes feladatot 16 konkrét példányra bont, a Microsoft Hyper-V hálózati adapter maximális kihasználása érdekében.
A Windows Teljesítményfigyelőben az egyes adaptereken végzett tevékenység ellenőrzéséhez válassza a Teljesítményfigyelő > Számlálók hozzáadása > Hálózati interfész > Microsoft Hyper-V hálózati adapter lehetőséget.
Miután adatforgalom fut a köteteken, figyelheti az adaptereket a Windows Teljesítményfigyelőben. Ha nem használja a 16 virtuális adaptert, előfordulhat, hogy nem maximalizálja a hálózati sávszélesség kapacitását.
SMB-titkosítás
Ez a szakasz segít megérteni az SMB-titkosítást (SMB 3.0 és SMB 3.1.1)
Az SMB-titkosítás az SMB-adatok végpontok közötti titkosítását biztosítja, és védi az adatokat a nem megbízható hálózatokon előforduló lehallgatásoktól. Az SMB-titkosítás az SMB 3.0-s és újabb verzióin támogatott.
Amikor kérést küld a tárolónak, az ügyfél titkosítja a kérést, amelyet a tár visszafejt. A válaszokat a kiszolgáló hasonlóan titkosítja, és az ügyfél visszafejti.
A Windows 10, a Windows 2012 és az újabb verziók támogatják az SMB-titkosítást.
Az SMB-titkosítás és az Azure NetApp Files
Az Advanced Encryption Standard (AES) használatával történő SMB-titkosítás az Azure NetApp Files megosztási szintjén engedélyezve van. Az SMB 3.0 az AES-CCM algoritmust, míg az SMB 3.1.1 az AES-GCM algoritmust használja.
Nincs szükség SMB-titkosításra. Ezért csak akkor engedélyezett egy adott megosztáshoz, ha a felhasználó azt kéri, hogy az Azure NetApp Files engedélyezze azt. Az Azure NetApp Files-megosztások soha nem érhetők el az interneten. Csak egy adott virtuális hálózatról, VPN-en vagy expressz útvonalon érhetők el, így az Azure NetApp Files-megosztások természetüknél fogva biztonságosak. Az SMB-titkosítás engedélyezésének lehetősége teljes mértékben a felhasználón múlik. A funkció engedélyezése előtt vegye figyelembe a várható teljesítménybírságot.
Az SMB-titkosítás hatása az ügyfelek számítási feladataira
Bár az SMB-titkosítás hatással van mind az ügyfélre (az üzenetek titkosításával és visszafejtésével járó cpu-terhelésre), mind a tárolásra (az átviteli sebesség csökkentése), az alábbi táblázat csak a tárolásra gyakorolt hatást emeli ki. A számítási feladatok éles környezetben való üzembe helyezése előtt tesztelnie kell a titkosítási teljesítmény hatását a saját alkalmazásaira.
| I/O-profil | Hatás |
|---|---|
| Olvasási és írási munkaterhelések | 10%-ról 15%-ra |
| Metaadat-intenzív | 5% |
Gyorsított hálózatkezelés
A maximális teljesítmény érdekében ajánlott a gyorsított hálózatkezelést konfigurálni a virtuális gépeken, ahol csak lehetséges. Tartsa szem előtt a következő szempontokat:
- Az Azure Portal alapértelmezés szerint gyorsított hálózatkezelést tesz lehetővé a funkciót támogató virtuális gépek számára. Más üzembehelyezési módszerek, például az Ansible és hasonló konfigurációs eszközök azonban nem. A gyorsított hálózatkezelés engedélyezésének elmulasztása felboríthatja a gép teljesítményét.
- Ha a gyorsított hálózatkezelés nem engedélyezett a virtuális gép hálózati adapterén a példánytípus vagy -méret támogatásának hiánya miatt, akkor a nagyobb példánytípusok letiltva maradnak. Ezekben az esetekben manuális beavatkozásra van szükség.
- Nincsen szükség arra, hogy az Azure NetApp Files dedikált alhálózatában a hálózati adapterek gyorsított hálózatát beállítsuk. A gyorsított hálózatkezelés olyan képesség, amely csak az Azure-beli virtuális gépekre vonatkozik. Az Azure NetApp Files hálózati adapterek tervezés szerint vannak optimalizálva.
Oldalméretezés fogadása
Az Azure NetApp Files támogatja a fogadási oldal skálázását (RSS).
Ha engedélyezve van az SMB Multichannel, az SMB3-ügyfél több TCP-kapcsolatot létesít az Azure NetApp Files SMB-kiszolgálóval egy olyan hálózati adapteren keresztül, amely egyetlen RSS-kompatibilis.
Annak ellenőrzéséhez, hogy az Azure-beli virtuális gépek hálózati adapterei támogatják-e az RSS-t, futtassa a parancsot Get-SmbClientNetworkInterface az alábbiak szerint, és ellenőrizze a mezőt RSS Capable:
Több hálózati interfész kártya SMB-ügyfeleken
Ne konfiguráljon több hálózati adaptert az ügyfélen az SMB-hez. Az SMB-ügyfél nem egyezik meg az SMB-kiszolgáló által visszaadott hálózati adapterek számával. Minden tárolókötet egy és csak egy tárolási végpontról érhető el, ami azt jelenti, hogy egy adott SMB-kapcsolathoz csak egy hálózati adapter használható.
Ahogy az alábbi kimenet Get-SmbClientNetworkInterface is mutatja, a virtuális gép két hálózati adaptert használ: 15 és 12. Ahogyan az alábbi parancsban Get-SmbMultichannelConnectionis látható , annak ellenére, hogy két RSS-kompatibilis hálózati adapter van, az SMB-megosztáshoz csak a 12-es interfész használható; a 15-ös interfész nincs használatban.
