Aracılığıyla paylaş

Azure dosya paylaşımı performansını anlama ve iyileştirme

Azure Dosyalar çoğu uygulama ve kullanım örneği için performans gereksinimlerini karşılayabilir. Bu makalede, dosya paylaşımı performansını etkileyebilecek farklı faktörler ve iş yükünüz için Azure dosya paylaşımlarının performansını iyileştirme adımları açıklanmaktadır.

Şunlara uygulanır

Yönetim modeli Faturalama modeli Medya katmanı Yedeklilik Küçük ve Orta Büyüklükteki İşletme (SMB) Ağ Dosya Sistemi (NFS)
Microsoft.Storage Sağlanan versiyon 2 SSD (üst düzey) Yerel (LRS) Hayır Evet
Microsoft.Storage Sağlanan versiyon 2 SSD (üst düzey) Bölge (ZRS) Hayır Evet
Microsoft.Storage Sağlanan versiyon 2 HDD (standart) Yerel (LRS) Evet Hayır
Microsoft.Storage Sağlanan versiyon 2 HDD (standart) Bölge (ZRS) Evet Hayır
Microsoft.Storage Sağlanan versiyon 2 HDD (standart) Coğrafi (GRS) Evet Hayır
Microsoft.Storage Sağlanan versiyon 2 HDD (standart) GeoZone (GZRS) Evet Hayır
Microsoft.Storage Tahsis edilen v1 SSD (üst düzey) Yerel (LRS) Evet Evet
Microsoft.Storage Tahsis edilen v1 SSD (üst düzey) Bölge (ZRS) Evet Evet
Microsoft.Storage Kullandıkça ödeme yap HDD (standart) Yerel (LRS) Evet Hayır
Microsoft.Storage Kullandıkça ödeme yap HDD (standart) Bölge (ZRS) Evet Hayır
Microsoft.Storage Kullandıkça ödeme yap HDD (standart) Coğrafi (GRS) Evet Hayır
Microsoft.Storage Kullandıkça ödeme yap HDD (standart) GeoZone (GZRS) Evet Hayır

Sözlük

Bu makaleyi okumadan önce depolama performansıyla ilgili bazı önemli terimleri anlamak yararlı olacaktır:

  • Saniye başına GÇ işlemleri (IOPS)

    IOPS veya saniye başına giriş/çıkış işlemleri, saniye başına dosya sistemi işlemlerinin sayısını ölçer. "Girdi/Çıktı" terimi, Azure Dosyalar belgelerinde "işlem" ve "hareket" terimleriyle karşılıklı olarak kullanılabilir.

  • G/Ç boyutu

    Bazen blok boyutu olarak da adlandırılan G/Ç boyutu, bir uygulamanın depolamada tek bir giriş/çıkış (G/Ç) işlemi gerçekleştirmek için kullandığı isteğin boyutudur. Uygulamaya bağlı olarak G/Ç boyutu 4 KiB gibi küçük boyutlardan daha büyük boyutlara kadar değişebilir. G/Ç boyutu, ulaşılabilir aktarım hızı açısından önemli bir rol oynar.

  • İşlem hızı

    Aktarım hızı, saniyede depolama alanından okunan veya yazılan bit sayısını ölçer ve saniye başına mebibayt (MiB/sn) cinsinden ölçülür. Aktarım hızını hesaplamak için IOPS'yi G/Ç boyutuyla çarpın. Örneğin, 10.000 IOPS _ 1 MiB G/Ç boyutu = 10 GiB/sn, 10.000 IOPS _ 4 KiB G/Ç boyutu = 38 MiB/sn.

  • Gecikme süresi

    Gecikme, gecikme için eş anlamlıdır ve milisaniye (ms) cinsinden ölçülür. İki tür gecikme süresi vardır: uçtan uca gecikme süresi ve hizmet gecikme süresi. Daha fazla bilgi için bkz . Gecikme süresi.

  • Kuyruk derinliği

    Kuyruk derinliği, depolama kaynağının herhangi bir anda işleyebileceği bekleyen G/Ç isteklerinin sayısıdır. Daha fazla bilgi için bkz . Kuyruk derinliği.

Kullanım desenlerini temel alan bir medya katmanı seçme

Azure Dosyalar, performansı ve fiyatı dengelemenize olanak sağlayan iki depolama medya katmanı sağlar: SSD ve HDD. Dosya paylaşımının medya katmanını depolama hesabı düzeyinde seçersiniz ve belirli bir medya katmanında depolama hesabı oluşturduktan sonra , yeni bir dosya paylaşımına el ile geçiş yapmadan diğerine taşınamazsınız.

SSD ve HDD dosya paylaşımları arasında seçim yaparken, Azure Dosyalar'da çalıştırmayı planladığınız beklenen kullanım düzeninin gereksinimlerini anlamak önemlidir. Büyük miktarlarda IOPS, yüksek veri aktarım hızı veya düşük gecikme süresine ihtiyacınız varsa SSD dosya paylaşımlarını seçmeniz gerekir.

Aşağıdaki tabloda SSD ve HDD dosya paylaşımları arasında beklenen performans hedefleri özetlenmektedir. Ayrıntılar için bkz Azure Dosyalar ölçeklenebilirlik ve performans hedefleri.

Kullanım düzeni gereksinimleri SSD HDD
Yazma gecikme süresi (tek basamaklı milisaniye) Evet Evet
Okuma gecikme süresi (tek basamaklı milisaniye) Evet Hayır

SSD dosya paylaşımları, paylaşım boyutuna göre aşağıdaki performans profilini garanti eden bir sağlama modeli sunar. Daha fazla bilgi için sağlanan v1 modeline bakın.

Performans denetim listesi

İster yeni ister mevcut bir iş yükü için performans gereksinimlerini değerlendirin, kullanım desenlerinizi anlamak öngörülebilir performans elde etmenize yardımcı olur.

  • Gecikme süresi duyarlılığı: Okuma gecikmesine duyarlı olan ve son kullanıcılar için yüksek görünürlüğe sahip iş yükleri, HEM okuma hem de yazma işlemleri< için tek milisaniyelik gecikme süresi (küçük G/Ç boyutu için 2 ms) sağlayabilen SSD dosya paylaşımları için daha uygundur.

  • IOPS ve aktarım hızı gereksinimleri: SSD dosya paylaşımları, HDD dosya paylaşımlarından daha büyük IOPS ve aktarım hızı sınırlarını destekler. Daha fazla bilgi için bkz . dosya paylaşımı ölçek hedefleri .

  • İş yükü süresi ve sıklığı: Kısa (dakika) ve seyrek (saatlik) iş yüklerinin HDD dosya paylaşımlarının yüksek performans sınırlarına ulaşma olasılığı, uzun süre çalışan ve sık gerçekleşen iş yükleriyle karşılaştırıldığında daha azdır. SSD dosya paylaşımlarında, sağlanan depolama, IOPS ve aktarım hızına göre kullanılacak doğru performans profilini belirlerken iş yükü süresi yararlı olur. Yaygın bir hata, performans testlerini yalnızca birkaç dakika çalıştırmaktır ve bu genellikle yanıltıcıdır. Performansın gerçekçi bir görünümünü elde etmek için yeterince yüksek sıklıkta ve sürelerde test etmeye dikkat edin.

  • İş yükü paralelleştirme: Aynı istemcideki birden çok iş parçacığı, işlem veya uygulama örneği gibi işlemleri paralel olarak gerçekleştiren iş yükleri için, SSD dosya paylaşımları HDD dosya paylaşımlarına göre net bir avantaj sağlar: Çok Kanallı SMB. Daha fazla bilgi için bkz . SMB Azure dosya paylaşımı performansını geliştirme.

  • API işlemi dağıtımı: Çok sayıda dosyaya karşı okuma işlemleri gerçekleştiren iş yükleri gibi meta veri ağır iş yükleri, SSD dosya paylaşımları için daha uygundur. Bakınız Metadata veya ad alanı yoğun iş yükü.

Gecikme süresi

Gecikmeyi düşünürken, önce Azure Dosyalar ile gecikme süresinin nasıl belirlendiğini anlamak önemlidir. En yaygın ölçümler, uçtan uca gecikme süresi ve hizmet gecikmesi ölçümleriyle ilişkili gecikme süresidir. Bu işlem ölçümlerini kullanmak, uygulama trafiğinizin istemciye ve istemciden aktarım sırasında ne kadar zaman harcadığını belirleyerek istemci tarafı gecikme süresi ve/veya ağ sorunlarını belirlemeye yardımcı olabilir.

  • Uçtan uca gecikme süresi (SuccessE2ELatency), bir işlemin istemciden, ağ genelinden Azure Dosyalar hizmetine ve istemciye geri dönmesi için geçen toplam gidiş dönüş süresidir.

  • Hizmet Gecikme Süresi (SuccessServerLatency), bir işlemin yalnızca Azure Dosyalar içinde gidiş dönüşe geçmesi için geçen süredir. Bu, herhangi bir istemci veya ağ gecikme süresi içermez.

    Azure Dosyalar için istemci gecikme süresini ve hizmet gecikme süresini karşılaştıran diyagram.

SuccessE2ELatency ile SuccessServerLatency değerleri arasındaki fark, ağ ve/veya istemcinin neden olduğu gecikme süresidir.

İstemci gecikme süresini hizmet gecikme süresiyle (bu durumda Azure Dosyalar performans) karıştırmak yaygın bir durumdır. Örneğin, hizmet gecikme süresi düşük gecikme süresi bildiriyorsa ve uçtan uca istekler için çok yüksek gecikme süresi bildiriyorsa, bu, tüm zamanın Azure Dosyalar hizmetinde değil istemciye ve istemciden aktarımda harcandığını gösterir.

Ayrıca, diyagramda gösterildiği gibi hizmetten ne kadar uzaktaysanız gecikme süresi o kadar yavaştır ve herhangi bir bulut hizmetiyle performans ölçek sınırlarına ulaşmak o kadar zordur. Bu durum özellikle şirket içinden Azure Dosyalar erişilirken geçerlidir. ExpressRoute gibi seçenekler şirket içi için ideal olsa da, yine de yalnızca aynı Azure bölgesinde çalışan bir uygulamanın (işlem + depolama) performansıyla eşleşmez.

Tavsiye

Şirket içi ile Azure arasındaki performansı test etmek için Azure'da VM kullanmak, Azure bağlantısının ağ özelliklerini temellendirmenin etkili ve pratik bir yoludur. Az veya yanlış yönlendirilmiş ExpressRoute bağlantı hatları veya VPN ağ geçitleri, Azure Dosyalar üzerinde çalışan iş yüklerini önemli ölçüde yavaşlatabilir.

Kuyruk derinliği

Kuyruk derinliği, bir depolama kaynağının hizmet olarak kullanabileceği bekleyen G/Ç isteklerinin sayısıdır. Depolama sistemleri tarafından kullanılan diskler HDD iş millerinden (IDE, SATA, SAS) katı hal cihazlarına (SSD, NVMe) dönüştükçe, daha yüksek kuyruk derinliğini destekleyecek şekilde de gelişmiştir. Büyük bir veri kümesindeki tek bir dosyayla seri olarak etkileşim kuran tek bir istemciden oluşan iş yükü, düşük kuyruk derinliğine örnektir. Buna karşılık, birden çok iş parçacığı ve birden çok dosya ile paralelliği destekleyen bir iş yükü kolayca yüksek kuyruk derinliğine ulaşabilir. Azure Dosyalar binlerce Azure küme düğümüne yayılan ve iş yüklerini büyük ölçekte çalıştıracak şekilde tasarlanmış dağıtılmış bir dosya hizmeti olduğundan, yüksek kuyruk derinliğine sahip iş yükleri oluşturmanızı ve test etmenizi öneririz.

Yüksek kuyruk derinliği, istemciler, dosyalar ve iş parçalarıyla birlikte birkaç farklı yolla elde edilebilir. İş yükünüzün kuyruk derinliğini belirlemek için, istemci sayısını dosya sayısıyla iş parçacığı sayısıyla (istemciler _ dosyalar _ iş parçacıkları = kuyruk derinliği) çarpın.

Aşağıdaki tabloda, daha yüksek kuyruk derinliği elde etmek için kullanabileceğiniz çeşitli bileşimler gösterilmektedir. En uygun kuyruk derinliği olan 64'ü aşabilirsiniz ancak bunu önermeyiz. Bunu yaparsanız daha fazla performans kazancı görmezsiniz ve TCP doygunluğu nedeniyle gecikme süresini artırma riskiyle karşılaşırsınız.

Müşteriler Dosyalar Thread'ler Kuyruk derinliği
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
2 4 4 32
1 8 8 64
4 4 2 64

Tavsiye

Üst performans sınırlarına ulaşmak için iş yükünüzün veya karşılaştırma testinizin, birden çok dosya ile çok iş parçacıklı şekilde çalıştığından emin olun.

Tek iş parçacıklı ve çok iş parçacıklı uygulamalar

Azure Dosyalar, çok iş parçacıklı uygulamalar için uygundur. Çoklu iş parçacığı kullanımının bir iş yükü üzerindeki performans etkisini anlamanın en kolay yolu, senaryoyu G/Ç işlemine göre incelemektir. Aşağıdaki örnekte, 10.000 küçük dosyayı bir Azure dosya paylaşımına veya bir Azure dosya paylaşımından mümkün olan en kısa sürede kopyalaması gereken bir iş yüküne sahibiz.

Bu tablo, 4 KiB blok boyutunda yazılan tek iş parçacıklı bir uygulamayı temel alarak Azure dosya paylaşımında tek bir 16 KiB dosyası oluşturmak için gereken süreyi (milisaniye olarak) ayırır.

G/Ç işlemi Oluştur 4 KiB yazma 4 KiB yazma 4 KiB yazma 4 KiB yazma Kapat Toplam
İş Parçası 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Bu örnekte, altı işlemden tek bir 16 KiB dosyası oluşturmak yaklaşık 14 ms sürebilir. Tek iş parçacıklı bir uygulama 10.000 dosyayı bir Azure dosya paylaşımına taşımak isterse, bu 140.000 ms (14 ms * 10.000) veya 140 saniyeye dönüşür çünkü her dosya sırayla tek tek taşınır. Önceki bölümde açıklandığı gibi, her isteğin hizmet verme süresinin öncelikle işlem ve depolama alanının birbirine ne kadar yakın olduğuna göre belirlendiğini unutmayın.

Yukarıdaki iş yükü, bir yerine sekiz iş parçacığı kullanılarak 140.000 ms'den (140 saniye) 17.500 ms'ye (17,5 saniye) düşürülebilir. Aşağıdaki tabloda gösterildiği gibi, aynı anda bir dosya yerine sekiz dosyayı paralel olarak taşırken aynı miktarda veriyi %87,5 daha kısa sürede taşıyabilirsiniz.

G/Ç işlemi Oluştur 4 KiB yazma 4 KiB yazma 4 KiB yazma 4 KiB yazma Kapat Toplam
İş Parçası 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Başlık 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
İş Parçacığı 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
İş Parçacığı 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
İş Parçacığı 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
İş Parçacığı 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
İş Parçacığı 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
İş Parçacığı 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Ayrıca bkz.

  • Last updated on