Azure Files metaadat-gyorsítótár kontra helyi fióktelepi gyorsítótár
A szolgáltatásoldali metaadat-gyorsítótár csökkenti a kiszolgáló munkáját. Nem viszi ki az oda-vissza utakat a WAN-hálózatából. Hasonlítsa össze a kettőt aszerint, mit rövidítenek valójában.
A lassú Azure Files-eléréshez VPN-en keresztül két változtatást javasolnak, és ezek különböző dolgokat rövidítenek. A szolgáltatásoldali metaadat-gyorsítótár olcsóbbá teszi a jogosult műveleteket a kiszolgáló számára. A helyi fióktelepi gyorsítótár közelebb viszi a bájtokat és a műveleteket a felhasználóhoz. A kettő közötti választás árlista vagy sajtóközlemény alapján az az út, amelyen egy megosztás gyorsabb lesz egy mérésben, és reggel kilenckor változatlan marad.
Két gyorsítótár, két különböző késleltetés
Mindkét lehetőség a gyorsítótár szó alatt jelenik meg, és itt kezdődik a zavar. A hálózat ellentétes oldalain helyezkednek el.
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
A Microsoft SMB teljesítményre vonatkozó útmutatója metaadat-gyorsítótárazást ír le a jogosult SSD-megosztásokhoz, valamint a hozzá tartozó regisztrációs lépést. A jogosultság és a funkció állapota a tényleges tárfiktához tartozik, ezért az aktuális oldalt olvassa, ne egy két évvel ezelőtti előzetes bejelentést.
Ossza három részre a várakozást
Minden lassú könyvtárlistázásnak három költségösszetevője van, és ezek különböző javításokra reagálnak. Van a kérésenkénti szolgáltatásfeldolgozási idő, a VPN-en átmenő függő oda-vissza utak száma és a mozgatandó hasznos teher. A szolgáltatásoldali gyorsítótár az elsőt támadja. A kiszolgáló oldalán semmi sem támadja a másodikat.
Ezért mutathat egy megosztás jobb szolgáltatásmetrikákat, miközben a felhasználó fájlválasztója még mindig nyolc másodpercig akad.
Hol érdemli ki helyét az egyes lehetőség
Ha a munkaterhelés metaadat-igényes, sok megnyitással, stat-hívással és könyvtárfelsorolással egy jogosult SSD-megosztáson, a szolgáltatásoldali gyorsítótárazás az olcsó kísérlet. Nem igényel új infrastruktúrát, és nem változtat azon, hogyan érik el a felhasználók a megosztást.
Ha a munkaterhelés interaktív és késleltetéskorlátos, a tisztességes lehetőség egy támogatott helyi kiszolgálóterv dokumentált szinkronizációs modellel. Ez más architektúra, saját üzemeltetési költségekkel, nem kapcsoló.
Mit nem változtat meg egyik lehetőség sem
Az SMB-aláírás és -titkosítás továbbra is érvényes, és továbbra is annyiba kerül, amennyibe kerül. A hozzáférés-vezérlés továbbra is felhasználónként oldódik meg, így a gyorsítótárazott másolat nem egyszerűsíti az engedélyezést. A helyek közötti konzisztenciához továbbra is meghatározott modell kell, mert a fióktelepi helyi olvasásoknak és a felhőoldali írásoknak meg kell egyezniük valamiben. Az offline hozzáférés pedig ügyfélbeállítás marad, nem egy kiszolgálófunkció mellékhatása.
Amikor valaki azt ígéri, hogy egy szolgáltatásfunkció megszünteti a WAN oda-vissza utakat, az az állítás, amelyet először kell tesztelni.
Ahhoz a művelethez mérjen, amelyről a felhasználók panaszkodnak
A pontos műveletet időzítse, ne egy szintetikus másolatot. Measure-Command { Get-ChildItem \\files\projects -Recurse } egy fióktelepi ügyfélen olyan számot ad, amelyet előtte és utána össze tud hasonlítani, és Get-SmbMultichannelConnection megmutatja, hogy az ügyfél egynél több útvonalat használ-e. Tegye ezt ugyanazon időablak szolgáltatásoldali késleltetési mérőszámai mellé.
Tartsa állandóan a megosztást, az ügyfél helyét, a VPN-útvonalat és a biztonsági szabályzatot, különben a változtatási ablakát méri, nem a funkciót. Jegyezze fel a fájlszámot és a méreteloszlást is, mert a kis fájlokból álló munkaterhelések és a tömeges másolások teljesen különböző karokra reagálnak.
A megérő eredmény egy olyan változtatás, amely illeszkedik ahhoz a határhoz, amely valóban lassú volt, és amelynek üzemeltetési és konzisztenciaköltségei le vannak írva. Egy nagyobb tárhely-IOPS-szám a dián nem ez az eredmény.