Aracılığıyla paylaş

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.

Şunlar için geçerlidir:

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) Hayır Hayır
Microsoft.Storage Sağlanan versiyon 2 HDD (standart) Bölge (ZRS) Hayır Hayır
Microsoft.Storage Sağlanan versiyon 2 HDD (standart) Coğrafi (GRS) Hayır Hayır
Microsoft.Storage Sağlanan versiyon 2 HDD (standart) GeoZone (GZRS) Hayır Hayır
Microsoft.Storage Tahsis edilen v1 SSD (üst düzey) Yerel (LRS) Hayır Evet
Microsoft.Storage Tahsis edilen v1 SSD (üst düzey) Bölge (ZRS) Hayır Evet
Microsoft.Storage Kullandıkça ödeme yap HDD (standart) Yerel (LRS) Hayır Hayır
Microsoft.Storage Kullandıkça ödeme yap HDD (standart) Bölge (ZRS) Hayır Hayır
Microsoft.Storage Kullandıkça ödeme yap HDD (standart) Coğrafi (GRS) Hayır Hayır
Microsoft.Storage Kullandıkça ödeme yap HDD (standart) GeoZone (GZRS) Hayır Hayı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 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

NFS nconnect

NFS nconnect, istemci ile NFS dosya paylaşımınız arasında birden çok TCP bağlantısı kullanmanıza olanak tanıyan bir NFS dosya paylaşımları için istemci tarafı bağlama seçeneğidir.

Fayda -ları

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 boyutu tarafından sunulan bant genişliği ölçek sınırlarını (10 GiB / sn) elde etmek için yaklaşık 20 istemci makineye ihtiyacınız olacaktır. 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

Ö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

Linux istemcilerinde uygun ölçekte NFS Azure dosya paylaşımlarıyla nconnect bağlama seçeneğini kullanırken 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ı.

NFS Azure dosya paylaşımlarıyla nconnect kullanılırken IOPS'deki ortalama iyileştirmeyi gösteren ekran görüntüsü.

NFS Azure dosya paylaşımları ile nconnect kullanılırken aktarım hızındaki ortalama iyileştirmeyi gösteren ekran görüntüsü.

Öneriler

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

Ayarla nconnect=4

Azure Dosyalar nconnect'in en fazla 16 ayarına kadar ayarlanmasını desteklese de, bağlama seçeneklerini en uygun nconnect=4 ayarıyla yapılandırmanızı öneririz. Ş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ı bağlamayı gerektiriyorsa, genel uç nokta üzerinden bağlanırken bu ayarların kalıcı olacağını garanti edemeyiz. 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: 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 çözümlense bile, genel uç noktalar statik adresler olmadığından adresin kalıcı olmasını garanti edemiyoruz.

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 ö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)
  • İŞLETİM SİSTEMİ: Linux (Ubuntu 20.40)
  • 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

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 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 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.

Nconnect'in ne zaman önerilip önerilmez olduğunu belirtmek için ilgili gecikme süresine sahip çeşitli okuma ve yazma GÇ senaryolarını gösteren ekran görüntüsü.

Ayrıca bakınız

  • Last updated on