Hitaalle Azure Files -käytölle VPN:n yli ehdotetaan kahta muutosta, ja ne lyhentävät eri asioita. Palvelinpuolen metatietovälimuisti tekee kelvollisista toiminnoista halvempia palvelimelle. Paikallinen haaravälimuisti siirtää tavut ja toiminnot lähemmäs käyttäjää. Näiden välillä hinnaston tai lehdistötiedotteen perusteella valitseminen on se tapa, jolla jako tulee testissä nopeammaksi ja pysyy yhdeksältä aamulla muuttumattomana.

Kaksi välimuistia, kaksi eri latenssia

Molemmat vaihtoehdot esiintyvät välimuisti-sanan alla, ja siitä hämmennys alkaa. Ne sijaitsevat verkon vastakkaisilla puolilla.

ChangeWhere it actsWhat it does not imply
Azure Files service metadata cachingThe service's handling of supported metadata operations on eligible sharesNo removal of the client's network round trips
A supported local server or cache designSome content and operations placed nearer the usersNo universal offline access or instant cross-site consistency
Application batching or limited copy concurrencyThe number and overlap of remote operationsNo automatic speedup for every workload

Microsoftin SMB:n suorituskykyohje kuvaa metatietovälimuistin kelvollisille SSD-jaoille sekä siihen liittyvän rekisteröintivaiheen. Kelpoisuus ja ominaisuuden tila kuuluvat todelliselle tallennustilille, joten lue nykyinen sivu äläkä kahden vuoden takaista esikatselutiedotetta.

Jaa odotus kolmeen osaan

Jokaisella hitaalla hakemistolistauksella on kolme kustannusosaa, ja ne reagoivat eri korjauksiin. On pyyntökohtainen palvelinkäsittelyaika, VPN:n yli tehtävien riippuvaisten edestakaisten matkojen määrä ja siirrettävä hyötykuorma. Palvelinpuolen välimuisti hyökkää ensimmäiseen. Mikään palvelimen puolella ei hyökkää toiseen.

Siksi jako voi näyttää parempia palvelumittareita, vaikka käyttäjän tiedostovalitsin jumittuu edelleen kahdeksaksi sekunniksi.

Missä kukin vaihtoehto ansaitsee paikkansa

Jos työkuorma on metatietoraskas, kun kelvolliseen SSD-jakoon kohdistuu paljon avauksia, stat-kutsuja ja hakemistoluetteloita, palvelinpuolen välimuisti on halpa kokeilu. Se ei vaadi uutta infrastruktuuria eikä muuta sitä, miten käyttäjät pääsevät jakoon.

Jos työkuorma on interaktiivinen ja latenssirajoitteinen, rehellinen vaihtoehto on tuettu paikallisen palvelimen suunnittelu, jossa on dokumentoitu synkronointimalli. Se on eri arkkitehtuuri omine käyttökustannuksineen, ei kytkin.

Mitä kumpikaan vaihtoehto ei muuta

SMB-allekirjoitus ja -salaus ovat edelleen voimassa, ja ne maksavat edelleen sen, mitä ne maksavat. Käyttöoikeuksien valvonta ratkaistaan edelleen käyttäjäkohtaisesti, joten välimuistiin tallennettu kopio ei yksinkertaista valtuutusta. Sivustojen välinen yhdenmukaisuus vaatii edelleen määritellyn mallin, koska haaran paikallisten lukujen ja pilvipuolen kirjoitusten on sovittava jostakin. Ja offline-käyttö pysyy asiakasasetuksena, ei palvelinominaisuuden sivuvaikutuksena.

Kun joku lupaa, että palveluominaisuus poistaa WAN-edestakaiset matkat, se on väite, joka on testattava ensin.

Mittaa sitä toimintoa vasten, josta käyttäjät valittavat

Ajoita tarkka toiminto synteettisen kopion sijaan. Measure-Command { Get-ChildItem \\files\projects -Recurse } haaratoimiston asiakkaalla antaa luvun, jota voit verrata ennen ja jälkeen, ja Get-SmbMultichannelConnection näyttää, käyttääkö asiakas useampaa kuin yhtä polkua. Laita se saman ikkunan palvelinpuolen latenssimittareiden viereen.

Pidä jako, asiakkaan sijainti, VPN-polku ja tietoturvakäytäntö vakiona, tai mittaat muutosikkunaasi etkä ominaisuutta. Kirjaa myös tiedostomäärä ja kokojakauma, koska pienten tiedostojen työkuormat ja massakopiot reagoivat täysin eri vipuihin.

Tulos, joka kannattaa saada, on muutos, joka vastaa rajaa, joka todella oli hidas, ja jonka käyttö- ja yhdenmukaisuuskustannukset on kirjoitettu. Suurempi tallennuksen IOPS-luku dialla ei ole se tulos.

Aiheeseen liittyvät artikkelit