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

Bu makalede, ağ dosya sistemi (NFS) Azure dosya paylaşımları için performansı nasıl geliştirebileceğiniz açıklanmaktadır.

Şunlara uygulanır

Dosya paylaşımı türü	SMB	NFS
Standart dosya paylaşımları (GPv2), LRS/ZRS
Standart dosya paylaşımları (GPv2), GRS/GZRS
Premium dosya paylaşımları (filestorage), LRS/ZRS

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, okuma arabellek boyutu için istemci tarafı bağlama seçeneğini temsil eden, önceden okuma değerini bağlı dosya sisteminin rsize15 katı eşdeğerine 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 küçük değer, büyük dosyalar için okuma aktarım hızı miktarını azaltabilir. Linux sürümlerinden 128 KiB varsayılanı olan sürümlere daha büyük bir okuma değeriyle yükselten müşteriler sıralı okuma performansında düşüş yaşayabilir.

Linux çekirdekleri 5.4 veya üzeri için, gelişmiş performans için kalıcı olarak 15 MiB olarak ayarlamanızı read_ahead_kb öneririz.

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'nin yeni dosyadan haberdar olmasını sağlamak için bu komutu yalnızca bir kez çalıştırmanız gerekir.

   sudo udevadm control --reload
   

Nconnect

Nconnect , istemci ile NFSv4.1 için Azure Premium Dosyalar hizmeti arasında daha fazla İletim Denetimi Protokolü (TCP) bağlantısı kullanmanıza olanak tanıyarak performansı büyük ölçekte artıran bir istemci tarafı Linux bağlama seçeneğidir.

Avantajları nconnect

ile nconnecttoplam sahip olma maliyetini (TCO) azaltmak için daha az istemci makinesi kullanarak performansı büyük ölçekte artırabilirsiniz. Nconnect tek veya birden çok istemci kullanarak bir veya daha fazla NIC üzerinde birden çok TCP kanalı kullanarak performansı artırır. olmadan nconnect, en büyük premium Azure dosya paylaşımı sağlama boyutu tarafından sunulan bant genişliği ölçek sınırlarına (10 GiB/sn) ulaşmak için yaklaşık 20 istemci makineye ihtiyacınız vardır. ile nconnectyalnı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ı konusunda önemli geliştirmeler sağlayabilirsiniz. Aşağıdaki tabloya bakın.

Önkoşullar

• En son Linux dağıtımları tam olarak destekler nconnect. 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 nconnect

Linux istemcilerinde uygun ölçekte NFS Azure dosya paylaşımlarıyla bağlama seçeneğini kullanırken nconnect aşağıdaki performans sonuçlarını elde ettik. Bu sonuçları nasıl elde ettiğimiz hakkında daha fazla bilgi için bkz . Performans testi yapılandırması.

Için öneriler nconnect

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

Ayarlamak nconnect=4

Azure Dosyalar en fazla 16 ayarı ayarlamayı desteklese nconnect de, bağlama seçeneklerini en uygun ayarıyla nconnect=4yapılandırmanızı öneririz. Şu anda, Azure Dosyalar uygulaması nconnectiç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. genel amaçlı VM'leri Azure Dosyalar ile 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 verebilir 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.

Nconnect bağlama başına yapılandırma

bir iş yükü, tek bir istemciden farklı nconnect ayarlara sahip bir veya daha fazla depolama hesabına birden çok paylaşım bağlamayı gerektiriyorsa, genel uç nokta üzerinden bağlanırken bu ayarların kalıcı olacağını garanti edebiliriz. Bağlama başına yapılandırma yalnızca Senaryo 1'de açıklandığı gibi özel uç nokta üzerinden depolama hesabı başına tek bir Azure dosya paylaşımı kullanıldığında desteklenir.

Senaryo 1: nconnect Birden çok depolama hesabı olan özel uç nokta üzerinden bağlama başına yapılandırma (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: nconnect Genel uç nokta üzerinden bağlama başına yapılandırma (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

Senaryo 3: nconnect Tek depolama hesabında birden çok paylaşıma sahip özel uç nokta üzerinden bağlama başına yapılandırma (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 özetlenen sonuçları elde etmek ve ölçmek için aşağıdaki kaynakları ve karşılaştırma araçlarını kullandık.

• Tek istemci: Tek NIC ile Azure VM (DSv4 Serisi)
• İşletim sistemi: Linux (Ubuntu 20.40)
• NFS depolama: Azure Dosyalar premium dosya paylaşımı (sağlanan 30 TiB, ayarla nconnect=4)

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

Hem karşılaştırma hem de stres/donanım doğrulaması için kullanılan ücretsiz, açık kaynaklı bir disk G/Ç aracı olan Esnek G/Ç Test Aracı'nı (FIO) kullandık. FIO'yu yüklemek için, seçtiğiniz platform için yüklemek üzere FIO README dosyasındaki İkili Paketler bölümü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 derinliği

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

64k 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

1024k 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

4k G/Ç 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

8k 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

64k 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

1024k 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

Bağlama seçeneğini kullanırken nconnect , 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 için yüksek ölçekli IOPS veya tüm performans gerekmez. Daha küçük ölçekli iş yükleri nconnect için anlamlı 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.

Ayrıca bkz.

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