NFS Azure dosya paylaşımları için performansı geliştirme

Şunlar için geçerlidir: ✔️ NFS dosya paylaşımları

Bu makale, ağ dosya sistemi (NFS) Azure dosya paylaşımlarının performansını iyileştirmenin çeşitli yollarını sunmaktadır. Konular arasında daha iyi ardışık okuma verimliliği için Linux read_ahead_kb çekirdeği parametresini yapılandırmak, daha az istemci makineyle aktarım kapasitesini ölçeklendirmek için mount nconnect seçeneğinin kullanılması ve gecikmeyi azaltmak için depolama hesabınızı müşterilerinizle aynı erişilebilirlik alanına yerleştirmek yer alır.

Okuma aktarım hızını geliştirmek için önceden okuma boyutunu artırın

Linux'taki read_ahead_kb çekirdek parametresi, sıralı okuma işlemi sırasında "önceden okunması" veya önceden eklenmesi gereken veri miktarını temsil eder. 5.4'den önceki Linux çekirdek sürümleri, önceden okuma ayarını, istemci tarafı bağlama seçeneğini temsil eden okuma arabellek boyutunun bağlı dosya sisteminin rsize15 katı olarak ayarlar. Bu, çoğu durumda istemci sıralı okuma aktarım hızını geliştirmek için önceden okuma değerini yeterince yüksek bir değere ayarlar.

Ancak Linux çekirdek sürümü 5.4'le başlayarak Linux NFS istemcisi 128 KiB varsayılan read_ahead_kb değerini kullanır. Bu daha küçük değer, büyük dosyalar için okuma verimliliğini azaltabilir. Daha yüksek önden okuma değerine sahip Linux sürümlerinden, 128 KiB varsayılan sürümlere yükselten kullanıcılar, ardışık okuma performansında bir düşüş yaşayabilir.

Linux çekirdeklerinin 5.4 ve sonraki sürümlerinde, daha iyi performans için read_ahead_kb değerini kalıcı olarak 15 MiB olarak ayarlayın.

Bu değeri değiştirmek için Linux çekirdek cihaz yöneticisi udev'de bir kural ekleyerek okuma boyutunu ayarlayın. Şu adımları izleyin:

1. Bir metin düzenleyicisinde, aşağıdaki metni girip kaydederek /etc/udev/rules.d/99-nfs.rules dosyasını oluşturun:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. Konsolda udevadm komutunu süper kullanıcı olarak çalıştırıp kural dosyalarını ve diğer veritabanlarını yeniden yükleyerek udev kuralını uygulayın. Udev'in yeni dosyadan haberdar olması için bu komutu sadece bir kez çalıştırmanız yeterlidir.

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect, istemci ile NFS dosya paylaşımınız arasında birden fazla TCP bağlantısı oluşturmak için kullandığınız bir istemci tarafı bağlama seçeneğidir. Özellikle tek bir TCP bağlantısının darboğaz haline geldiği büyük ölçekli iş yüklerinde faydalıdır.

nconnect Faydaları

Nconnect ile toplam sahip olma maliyetini (TCO) azaltmak için daha az istemci makinesi kullanarak performansı büyük ölçekte artırabilirsiniz. nconnect özelliği, tek veya birden çok istemci kullanarak bir veya daha fazla NIC üzerinde birden çok TCP kanalı kullanarak performansı artırır. nconnect olmadan, en büyük SSD dosya paylaşımı sağlama boyutunun sunduğu bant genişliği ölçeği sınırlarını (10 GiB / s) ulaşmak için yaklaşık 20 istemci makineye ihtiyacınız var. nconnect ile yalnızca 6-7 istemci kullanarak bu sınırları elde edebilir ve işlem maliyetlerini yaklaşık 70% azaltırken, saniyede G/Ç işlemlerinde (IOPS) ve büyük ölçekte aktarım hızında önemli geliştirmeler sağlayabilirsiniz. Aşağıdaki tabloya bakın.

Metrik (işlem)	G/Ç boyutu	Performans iyileştirmesi
IOPS (yazma)	64 KiB, 1.024 KiB	3x
IOPS (okuma)	Tüm G/Ç boyutları	2-4x
Aktarım hızı (yazma)	64 KiB, 1.024 KiB	3x
Aktarım hızı (okuma)	Tüm G/Ç boyutları	2-4x

nconnect önkoşulları

• En son Linux dağıtımları nconnect'i tam olarak destekler. Eski Linux dağıtımları için Linux çekirdek sürümünün 5.3 veya üzeri olduğundan emin olun.
• Bağlama başına yapılandırma yalnızca özel uç nokta üzerinden depolama hesabı başına tek bir dosya paylaşımı kullanıldığında desteklenir.

Performans etkisi

Aşağıdaki performans sonuçları, Linux istemcilerinde Azure NFS dosya paylaşımları üzerinde nconnect bağlama seçeneği kullanılarak büyük ölçekte ölçülmüştür. Bu sonuçların nasıl sağlandığına dair daha fazla bilgi için performans testi yapılandırmasına bakınız.

nconnect önerileri

'den nconnecten iyi sonuçları almak için bu önerileri izleyin.

Ayarla nconnect=4

Azure Dosyalar, nconnect'i maksimum 16 ayarına kadar ayarlamayı desteklerken, mount seçeneklerini optimal ayar olan nconnect=4 ile yapılandırın. Şu anda, nconnect'in Azure Dosyalar uygulaması için dört kanalın ötesinde bir kazanç yoktur. Aslında, tek bir istemciden tek bir Azure dosya paylaşımına dört kanalın aşılması TCP ağ doygunluğu nedeniyle performansı olumsuz etkileyebilir.

Sanal makineleri dikkatle boyutlandırma

İş yükü gereksinimlerinize bağlı olarak, istemci sanal makinelerinin (VM) beklenen ağ bant genişliğiyle kısıtlanmaması için doğru şekilde boyutlandırılması önemlidir. Beklenen ağ aktarım hızını elde etmek için birden çok ağ arabirimi denetleyicisine (NIC) ihtiyacınız yoktur. Azure Dosyalar ile genel amaçlı VM'leri kullanmak yaygın olsa da, iş yükü gereksinimlerinize ve bölge kullanılabilirliğine bağlı olarak çeşitli VM türleri kullanılabilir. Daha fazla bilgi için bkz. Azure VM Seçicisi.

Kuyruk derinliğini 64'ten küçük veya buna eşit tutun

Kuyruk derinliği, bir depolama kaynağının hizmet verebileceği bekleyen G/Ç isteklerinin sayısıdır. Daha fazla performans kazancı göremeyeceğiniz için en uygun kuyruk derinliği olan 64'ün aşılması önerilmez. Daha fazla bilgi için bkz . Kuyruk derinliği.

Her bir bağlama yapılandırması için

Bir iş yükü, tek bir istemciden farklı nconnect ayarlarına sahip bir veya daha fazla depolama hesabıyla birden fazla paylaşım kurmayı gerektiriyorsa, bu ayarların genel uç noktaya monte edildiğinde kalıcı olacağı garanti edilmez. Montaj başına yapılandırma, Senaryo 1'de tanımlandığı gibi özel uç nokta üzerinde depolama hesabı başına yalnızca tek bir Azure dosya paylaşımını destekler.

Senaryo 1: Birden çok depolama hesabına sahip özel uç nokta üzerinden bağlama yapılandırması başına (desteklenir)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Senaryo 2: Genel uç nokta üzerinden bağlama yapılandırması başına (desteklenmez)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Uyarı

Depolama hesabı farklı bir IP adresine karar verse bile, adresin kalıcı olacağı garanti edilmez çünkü halka açık uç noktalar statik adres değildir.

Senaryo 3: Tek depolama hesabında birden çok paylaşıma sahip özel uç nokta üzerinden bağlama yapılandırması başına (desteklenmez)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Performans testi yapılandırması

Bu makalede belirtilen sonuçları elde etmek ve ölçmek için aşağıdaki kaynakları ve kıyaslama araçlarını kullanın.

• Tek istemci: Tek NIC ile Azure VM (DSv4 Serisi)
• OS: Linux (Ubuntu 20.04)
• NFS depolama alanı: SSD dosya paylaşımı (sağlanan 30 TiB, ayarla nconnect=4)

Boyut	vCPU	Bellek	Geçici depolama (SSD)	Maksimum veri diskleri	Maksimum NIC	Beklenen ağ bant genişliği
Standard_D16_v4	16	64 GiB	Yalnızca uzak depolama alanı	32	8	12.500 Mbps

Karşılaştırma araçları ve testleri

Bu testler, hem kıyaslama hem de stres veya donanım doğrulaması için kullanılan ücretsiz ve açık kaynaklı disk I/O aracı Flexible I/O Tester'ı (FIO) kullanır. FIO'yu kurmak için, FIO README dosyasındaki İkili Paketler bölümüne bakın ve seçtiğiniz platformun talimatlarını izleyin.

Bu testler rastgele G/Ç erişim desenlerine odaklanırken, sıralı G/Ç kullanırken de benzer sonuçlar elde edersiniz.

Yüksek IOPS: 100% okuma

4k G/Ç boyutu - rastgele okuma - 64 kuyruk derinliği

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

8k G/Ç boyutu - rastgele okuma - 64 kuyruk uzunluğu

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Yüksek aktarım hızı: 100% okuma

64 KiB G/Ç boyutu - rastgele okuma - 64 kuyruk derinliği

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

1.024 KiB G/Ç boyutu - 100% rastgele okuma - 64 kuyruk derinliği

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Yüksek IOPS: 100% yazma

4 KiB I/O boyutu - 100% rastgele yazma - 64 kuyruk derinliği

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

8 KiB G/Ç boyutu - 100% rastgele yazma - 64 kuyruk derinliği

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Yüksek aktarım hızı: 100% yazma

64 KiB G/Ç boyutu - 100% rastgele yazma - 64 kuyruk derinliği

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

1024 KiB G/Ç boyutu - 100% rastgele yazma - 64 kuyruk derinliği

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Performansla ilgili dikkat edilmesi gerekenler nconnect

Bir bağlama seçeneği olarak nconnect'ü kullanırken, aşağıdaki özelliklere sahip iş yüklerini yakından değerlendirmeniz gerekir:

• Tek iş parçacıklı ve/veya düşük kuyruk derinliği (16'dan az) kullanan gecikmeye duyarlı yazma iş yükleri
• Tek iş parçacıklı ve/veya daha küçük G/Ç boyutlarıyla birlikte düşük kuyruk derinliği kullanan gecikmeye duyarlı okuma iş yükleri

Tüm iş yükleri yüksek ölçekli IOPS veya aktarım kapasitesi gerektirmez. Daha küçük ölçekli nconnect iş yükleri için faydalı olmayabilir. İş yükünüz için avantajlı olup olmadığına nconnect karar vermek için aşağıdaki tabloyu kullanın. Yeşil renkle vurgulanan senaryolar önerilirken, kırmızıyla vurgulanan senaryolar önerilmez. Sarı renkle vurgulanan senaryolar nötr.

Bölgesel yerleştirmeyi kullanma

Microsoft.Storage kaynak sağlayıcısıyla oluşturulan klasik dosya paylaşımları için, depolama hesabınızın bulunduğu kullanılabilirlik alanını seçmek için bölgesel yerleştirme kullanmanızı öneririz. Bu, VM'lerinizi depolama alanınızla aynı kullanılabilirlik alanına yerleştirmenize olanak tanır ve bu da gecikme süresini yüzde 30'a kadar azaltabilir. Bu özellik şu anda yalnızca desteklenen bölgelerde yerel olarak yedekli depolama (LRS) kullanan SSD depolama hesapları için kullanılabilir.

Ayrıca bakınız

• NFS dosya paylaşımını Linux'a bağlama
• Bağlama seçenekleri listesi
• Azure Dosyaları performansını anlama