Azure Files metadatu kešatmiņa pret vietējo filiāles kešatmiņu
Pakalpojuma puses metadatu kešatmiņa samazina servera darbu. Tā neizņem turp un atpakaļ braucienus no jūsu WAN. Salīdziniet abas pēc tā, ko tās patiešām saīsina.
Lēnai Azure Files piekļuvei caur VPN tiek piedāvātas divas izmaiņas, un tās saīsina dažādas lietas. Metadatu kešatmiņa pakalpojuma pusē padara atbilstošās operācijas serverim lētākas. Vietējā filiāles kešatmiņa pārvieto baitus un operācijas tuvāk lietotājam. Izvēlēties starp tām pēc cenrāža vai preses paziņojuma ir ceļš, kā koplietojums kļūst ātrāks testā un paliek nemainīgs deviņos no rīta.
Divas kešatmiņas, divas atšķirīgas aiztures
Abas iespējas parādās zem vārda kešatmiņa, un tieši tur sākas apjukums. Tās atrodas pretējās tīkla pusēs.
| 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 |
Microsoft SMB veiktspējas vadlīnijas apraksta metadatu kešatmiņu atbilstošiem SSD koplietojumiem kopā ar reģistrācijas soli, kas tam pievienojas. Atbilstība un funkcijas stāvoklis pieder faktiskajam krātuves kontam, tāpēc lasiet pašreizējo lapu, nevis pirms diviem gadiem publicēto priekšskatījuma paziņojumu.
Sadaliet gaidīšanu trīs daļās
Katram lēnam direktorijas sarakstam ir trīs izmaksu komponenti, un tie reaģē uz dažādiem labojumiem. Ir pieprasījuma apstrādes laiks pakalpojuma pusē, atkarīgo turp un atpakaļ braucienu skaits caur VPN un kravnesība, kas jāpārvieto. Kešatmiņa pakalpojuma pusē uzbrūk pirmajam. Nekas servera pusē neuzbrūk otrajam.
Tāpēc koplietojums var uzrādīt labākus pakalpojuma rādītājus, kamēr lietotāja failu izvēlētājs joprojām karājas astoņas sekundes.
Kur katra iespēja nopelna savu vietu
Ja darba slodze ir metadatu smaga, ar daudzām atvēršanām, stat izsaukumiem un direktoriju uzskaitījumiem atbilstošam SSD koplietojumam, kešatmiņa pakalpojuma pusē ir lētais eksperiments. Tai nav vajadzīga jauna infrastruktūra un tā nemaina to, kā lietotāji sasniedz koplietojumu.
Ja darba slodze ir interaktīva un ierobežota ar aizturi, godīgā iespēja ir atbalstīts vietējā servera dizains ar dokumentētu sinhronizācijas modeli. Tā ir cita arhitektūra ar savām ekspluatācijas izmaksām, nevis slēdzis.
Ko nemaina neviena no iespējām
SMB parakstīšana un šifrēšana joprojām ir spēkā, un tās joprojām maksā to, ko tās maksā. Piekļuves kontrole joprojām tiek risināta katram lietotājam, tāpēc kešotā kopija nevienkāršo autorizāciju. Konsekvence starp vietnēm joprojām prasa definētu modeli, jo vietējie lasījumi filiālē un rakstīšana mākoņa pusē ir jāsaskaņo par kaut ko. Un bezsaistes piekļuve paliek klienta iestatījums, nevis servera funkcijas blakusefekts.
Kad kāds sola, ka pakalpojuma funkcija noņem WAN turp un atpakaļ braucienus, tas ir apgalvojums, kas jāpārbauda vispirms.
Mēriet pret operāciju, par kuru lietotāji sūdzas
Izmēriet precīzo operāciju, nevis sintētisku kopiju. Measure-Command { Get-ChildItem \\files\projects -Recurse } filiāles klientā dod skaitli, ko varat salīdzināt pirms un pēc, un Get-SmbMultichannelConnection parāda, vai klients izmanto vairāk nekā vienu ceļu. Novietojiet to blakus pakalpojuma puses aiztures rādītājiem tajā pašā logā.
Turiet koplietojumu, klienta atrašanās vietu, VPN ceļu un drošības politiku nemainīgus, citādi jūs mērāt savu izmaiņu logu, nevis funkciju. Pierakstiet arī failu skaitu un izmēru sadalījumu, jo mazu failu darba slodzes un masveida kopēšana reaģē uz pilnīgi atšķirīgām svirām.
Rezultāts, ko ir vērts iegūt, ir izmaiņas, kas atbilst robežai, kura patiešām bija lēna, ar pierakstītām ekspluatācijas un konsekvences izmaksām. Lielāks krātuves IOPS skaitlis slaidā nav šis rezultāts.