Azure Files meta veri önbelleği ile yerel şube önbelleği
Hizmet tarafındaki meta veri önbelleği sunucu işini azaltır. Ancak WAN'ınızdaki gidiş dönüşleri kaldırmaz. İkisini gerçekte neyi kısalttıklarına göre karşılaştırın.
VPN üzerinden yavaş Azure Files erişimi için iki değişiklik öneriliyor ve bunlar farklı şeyleri kısaltıyor. Hizmet tarafındaki meta veri önbelleği uygun işlemleri sunucu için daha ucuz hale getirir. Yerel şube önbelleği baytları ve işlemleri kullanıcıya yaklaştırır. Aralarında bir fiyat listesine veya basın bültenine göre seçim yapmak, bir paylaşımın kıyaslamada daha hızlı görünüp sabah dokuzda değişmeden kalmasının yoludur.
İki önbellek, iki farklı gecikme
Her iki seçenek de önbellek sözcüğü altında görünür ve karışıklık tam orada başlar. Ağın karşıt taraflarında dururlar.
| 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'un SMB performans kılavuzu uygun SSD paylaşımları için meta veri önbelleğini ve ona eşlik eden kayıt adımını açıklar. Uygunluk ve özellik durumu gerçek depolama hesabına aittir, bu nedenle iki yıl önceki bir önizleme duyurusunu değil güncel sayfayı okuyun.
Beklemeyi üç parçaya ayırın
Her yavaş dizin listesinin üç maliyet bileşeni vardır ve bunlar farklı düzeltmelere yanıt verir. İstek başına hizmet işleme süresi, VPN üzerinden bağımlı gidiş dönüşlerin sayısı ve taşınması gereken yük vardır. Hizmet tarafındaki önbellek ilkine saldırır. Sunucu tarafında hiçbir şey ikincisine saldırmaz.
Bu yüzden bir paylaşım daha iyi hizmet ölçümleri gösterebilirken kullanıcının dosya seçicisi hâlâ sekiz saniye donabilir.
Her seçenek yerini nerede kazanır
İş yükü meta veri açısından ağırsa, uygun bir SSD paylaşımına karşı çok sayıda açma, stat çağrısı ve dizin sayımı varsa, hizmet tarafındaki önbellekleme ucuz deneydir. Yeni altyapı ve kullanıcıların paylaşıma ulaşma biçiminde değişiklik gerektirmez.
İş yükü etkileşimli ve gecikmeye bağlıysa, belgelenmiş bir eşitleme modeline sahip desteklenen yerel sunucu tasarımı dürüst seçenektir. Bu, kendi işletme maliyetleri olan başka bir mimaridir, bir anahtar değil.
İki seçeneğin de değiştirmediği şey
SMB imzalama ve şifreleme hâlâ geçerlidir ve hâlâ maliyeti neyse odur. Erişim denetimi hâlâ her kullanıcı için çözülür, bu yüzden önbelleğe alınmış bir kopya yetkilendirmeyi basitleştirmez. Siteler arası tutarlılık hâlâ tanımlı bir model gerektirir, çünkü şube yerel okumaları ile bulut tarafındaki yazmalar bir konuda anlaşmak zorundadır. Ve çevrimdışı erişim bir istemci ayarı olarak kalır, bir sunucu özelliğinin yan etkisi değil.
Biri bir hizmet özelliğinin WAN gidiş dönüşlerini kaldırdığını vaat ettiğinde, ilk sınanması gereken iddia budur.
Kullanıcıların şikayet ettiği işleme göre ölçün
Sentetik bir kopya yerine tam işlemi ölçün. Measure-Command { Get-ChildItem \\files\projects -Recurse } bir şube istemcisinde öncesi ve sonrası karşılaştırabileceğiniz bir sayı verir ve Get-SmbMultichannelConnection istemcinin birden fazla yol kullanıp kullanmadığını gösterir. Bunu aynı pencere için hizmet tarafı gecikme ölçümlerinin yanına koyun.
Paylaşımı, istemci konumunu, VPN yolunu ve güvenlik ilkesini sabit tutun, yoksa özelliği değil kendi değişiklik pencerenizi ölçersiniz. Dosya sayısını ve boyut dağılımını da kaydedin, çünkü küçük dosya iş yükleri ile toplu kopyalar tamamen farklı kaldıraçlara yanıt verir.
Elde tutmaya değer sonuç, gerçekten yavaş olan sınıra uygun bir değişiklik ve onun işletme ile tutarlılık maliyetlerinin yazılı olmasıdır. Bir slayttaki daha büyük depolama IOPS sayısı o sonuç değildir.