Azure NetApp Files için Linux NFS bağlama seçenekleri en iyi yöntemleri

  • Makale

Bu makale, bağlama seçeneklerini ve bunları Azure NetApp Files ile kullanmaya yönelik en iyi yöntemleri anlamanıza yardımcı olur.

Nconnect

nconnect Bağlama seçeneğinin kullanılması, NFS istemcisi ile NFS uç noktası arasında 16 sınırına kadar kurulması gereken bağlantı sayısını (ağ akışları) belirtmenize olanak tanır. Geleneksel olarak, bir NFS istemcisi kendisiyle uç nokta arasında tek bir bağlantı kullanır. Ağ akışlarının sayısının artırılması, G/Ç ve aktarım hızının üst sınırlarını önemli ölçüde artırır. Test, en yüksek performansa sahip olduğunu tespit nconnect=8 etti.

Üretim için çok düğümlü SAS GRID ortamı hazırlarken, çalışma süresinde 8 saatten 5,5 saate kadar tekrarlanabilir %30 azalma olduğunu fark edebilirsiniz:

Bağlama seçeneği İş çalışma süreleri
Hayır nconnect 8 saat
nconnect=8 5,5 saat

Her iki test kümesi de aynı E32-8_v4 sanal makinesini ve RHEL8.3'i kullandı ve okuma 15 MiB olarak ayarlandı.

kullanırken nconnectaşağıdaki kuralları göz önünde bulundurun:

  • nconnect Azure NetApp Files tarafından tüm büyük Linux dağıtımlarında desteklenir, ancak yalnızca daha yeni sürümlerde desteklenir:

    Linux sürümü NFSv3 (en düşük sürüm) NFSv4.1 (en düşük sürüm)
    Redhat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 veya SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Not

    SLES15SP2, NFSv4.1 için Azure NetApp Files tarafından desteklenen en düşük SUSE sürümüdür nconnect . Belirtilen diğer tüm sürümler, özelliği tanıtan nconnect ilk sürümlerdir.

  • Tek bir uç noktadan tüm bağlamalar, aşağıdaki senaryolarda gösterildiği gibi bağlı ilk dışarı aktarma ayarını devralır nconnect :

    Senaryo 1: nconnect ilk bağlama tarafından kullanılır. Bu nedenle, aynı uç noktaya yönelik tüm bağlamalar kullanır nconnect=8.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    Senaryo 2: nconnect ilk bağlama tarafından kullanılmaz. Bu nedenle, orada belirtilse nconnect bile aynı uç nokta kullanımına nconnect karşı bağlama yoktur.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    Senaryo 3: nconnect ayarlar ayrı depolama uç noktalarına yayılmaz. nconnect , gelen 10.10.10.10 bağlama tarafından kullanılır, ancak gelen 10.12.12.12bağlama tarafından kullanılmaz.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • nconnect belirli bir istemciden gelen depolama eşzamanlılığını artırmak için kullanılabilir.

Ayrıntılar için bkz . Azure NetApp Files için Linux eşzamanlılığı en iyi yöntemleri.

Nconnect Husus -lar

Seçenekleri birlikte kullanmak nconnect ve sec=krb5* bağlamak önerilmez. İki seçenek birlikte kullanıldığında performans düşüşü gözlemlenmiştir.

Genel Güvenlik Standart Uygulama Programlama Arabirimi (GSS-API), uygulamaların eş uygulamalara gönderilen verileri koruması için bir yol sağlar. Bu veriler bir makinedeki istemciden başka bir makinedeki bir sunucuya gönderilebilir. 

nconnect Linux'ta kullanıldığında, GSS güvenlik bağlamı belirli bir sunucuya yapılan nconnect tüm bağlantılar arasında paylaşılır. TCP, sıralı sayılardan oluşan kayan bir pencere kullanarak bir GSS akışındaki sıra dışı paketlerle başa çıkmak için sıra dışı paket teslimini destekleyen güvenilir bir aktarımdır. Sıra penceresinde olmayan paketler alındığında, güvenlik bağlamı atılır ve yeni bir güvenlik bağlamı anlaşması yapılır. Şimdi atılan bağlamda ile gönderilen tüm iletiler artık geçerli olmadığından iletilerin yeniden gönderilmesi gerekir. Bir nconnect kurulumdaki daha fazla paket sayısı, açıklanan davranışı tetikleyerek sık sık pencere dışı paketlere neden olur. Bu davranışla belirli bir düşüş yüzdesi belirtemez.

Rsize ve Wsize

Bu bölümdeki örnekler, performans ayarlama yaklaşımı hakkında bilgi sağlar. Belirli uygulama gereksinimlerinize uygun ayarlamalar yapmanız gerekebilir.

rsize ve wsize bayrakları bir NFS işleminin en büyük aktarım boyutunu ayarlar. Bağlamada belirtilirse veya wsize belirtilmezsersize, istemci ve sunucu ikisi tarafından desteklenen en büyük boyut üzerinde anlaşma sağlar. Şu anda hem Azure NetApp Files hem de modern Linux dağıtımları 1.048.576 Bayt (1 MiB) kadar büyük okuma ve yazma boyutlarını desteklemektedir. Ancak Azure NetApp Files, en iyi genel aktarım hızı ve gecikme süresi için hem hem de rsize wsize 262.144 Bayttan (256 K) büyük olmayan bir ayar önerir. Kullanırken rsize hem gecikme süresinin arttığını hem de aktarım hızının azaldığını ve wsize 256 KiB'den büyük olduğunu gözlemleyebilirsiniz.

Örneğin, SUSE Linux Enterprise Server üzerinde Azure NetApp Files kullanarak Azure VM'lerinde bekleme düğümüne sahip bir SAP HANA ölçek genişletme sistemi dağıtma işlemi 256 KiB rsize ve wsize üst sınırı aşağıdaki gibi gösterir:

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

Örneğin, SAS Viya 256 KiB okuma ve yazma boyutları önerir ve SAS GRID değerini 64 KiB ile sınırlarken r/wsize , NFS bağlamaları için okuma performansını artırarak okuma performansını artırır. Ayrıntılar için bkz . Azure NetApp Files için NFS ileri okuma en iyi yöntemleri.

ve kullanımı rsize wsizeiçin aşağıdaki önemli noktalar geçerlidir:

  • Rastgele G/Ç işlem boyutları genellikle ve wsize bağlama seçeneklerinden rsize daha küçüktür. Bu nedenle, bunlar kısıtlama değildir.
  • Dosya sistemi önbelleği kullanılırken, dosya boyutu ve wsizedeğerinden küçük rsize olmadığı sürece ve wsize bağlama seçenekleri tarafından rsize belirtilen boyutta sıralı G/Ç gerçekleşir.
  • ve bağlama seçenekleriyle kısıtlanmış olsa da dosya sistemi önbelleğini rsize wsize atlayan işlemler veya wsizetarafından rsize belirtilen en büyük değer kadar büyük değildir. Seçeneği olan iş yükü oluşturucuları directio kullandığınızda bu önemli noktadır.

Azure NetApp Files ile ilgili en iyi uygulama olarak, en iyi genel aktarım hızı ve gecikme süresi için 262.144 Bayt'tan büyük olmayan bir değer ayarlayın rsize wsize .

Açık tutarlılık ve önbellek özniteliği zamanlayıcıları

NFS gevşek bir tutarlılık modeli kullanır. Uygulamanın paylaşılan depolamaya gitmesi ve bunu kullanmak için her seferinde veri getirmesi gerekmediğinden tutarlılık gevşektir. Bu senaryo, uygulama performansı üzerinde çok büyük bir etki yaratabilecek bir senaryodur. Bu işlemi yöneten iki mekanizma vardır: önbellek özniteliği zamanlayıcıları ve açık tutarlılık.

İstemci verilerin tam sahipliğini aldıysa, yani birden çok düğüm veya sistem arasında paylaşılmazsa, garantili tutarlılık vardır. Bu durumda, açık (bağlama seçeneği olarak) yakıncto tutarlılığı kapatarak ve öznitelik önbellek yönetimi için zaman aşımlarını açarak (actimeo=600noctobağlama seçeneği zamanlayıcıyı varsayılanlara acregmin=3,acregmax=30,acdirmin=30,acdirmax=60göre 10 m olarak değiştirir) depolamaya erişim işlemlerini azaltabilir getattr ve uygulamayı hızlandırabilirsiniz. Bazı testlerde erişim nocto çağrılarının yaklaşık %65-70'ini getattr azaltır ve ayarlamalar actimeo bu çağrıları %20-25 oranında azaltır.

Öznitelik önbelleği zamanlayıcıları nasıl çalışır?

, , acregmaxacdirminve acdirmax öznitelikleri acregminönbelleğin tutarlılığını denetler. Eski iki öznitelik, dosyaların özniteliklerinin ne kadar süreyle güvenilir olduğunu denetler. İkinci iki öznitelik, dizin dosyasının özniteliklerinin ne kadar süreyle güvenilir olduğunu denetler (dizin boyutu, dizin sahipliği, dizin izinleri). min ve max öznitelikleri, bir dizinin özniteliklerinin, bir dosyanın özniteliklerinin ve bir dosyanın önbellek içeriğinin sırasıyla güvenilir olduğu en düşük ve en uzun süreyi tanımlar. ile maxarasındamin, önbelleğe alınmış bir girdinin güvenildiği süreyi tanımlamak için bir algoritma kullanılır.

Örneğin, varsayılan acregmin ve acregmax değerleri (sırasıyla 3 ve 30 saniye) göz önünde bulundurun. Örneğin, öznitelikler bir dizindeki dosyalar için tekrar tekrar değerlendirilir. 3 saniye sonra NFS hizmeti tazelik için sorgulanır. Öznitelikler geçerli kabul edilirse, istemci güvenilen süreyi 6 saniye, 12 saniye, 24 saniye olarak ikiye katlar ve ardından maksimum değer 30, 30 saniye olarak ayarlanır. Bu noktadan sonra, önbelleğe alınan öznitelikler eski olarak kabul edilene kadar (bu noktada döngü baştan başlar), güvenilirlik tarafından acregmaxbelirtilen değer olarak 30 saniye olarak tanımlanır.

İstemciler tarafından tam sahiplik olmadığında bile, örneğin istemciler verileri salt okunur olarak kullanıyorsa ve veri güncelleştirmesi başka bir yol üzerinden yönetiliyorsa, benzer bağlama seçeneklerinden yararlanabilecek başka durumlar da vardır. EDA, web barındırma ve film işleme gibi istemcilerin kılavuzlarını kullanan ve nispeten statik veri kümelerine (EDA araçları veya kitaplıkları, web içeriği, doku verileri) sahip uygulamalar için, tipik davranış veri kümesinin istemcilerde büyük ölçüde önbelleğe alınmış olmasıdır. Çok az okuma var ve yazma yok. Depolama alanına geri dönen birçok getattr/access çağrısı vardır. Bu veri kümeleri genellikle dosya sistemlerini bağlamak ve düzenli aralıklarla içerik güncelleştirmeleri göndermek için başka bir istemci aracılığıyla güncelleştirilir.

Bu gibi durumlarda, yeni içerik almada bilinen bir gecikme vardır ve uygulama güncel olma olasılığı olan verilerle çalışmaya devam etmektedir. Bu durumlarda nocto ve actimeo veri dışı tarihin yönetilebileceği dönemi denetlemek için kullanılabilir. Örneğin, EDA araçları ve kitaplıklarında actimeo=600 bu veriler genellikle seyrek güncelleştirildiğinden düzgün çalışır. İstemcilerin sitelerini actimeo=10 düzenlerken veri güncelleştirmelerini zamanında görmesi gereken küçük web barındırma için kabul edilebilir olabilir. Birden çok dosya sistemlerine actimeo=60 gönderilen içeriğin bulunduğu büyük ölçekli web siteleri için kabul edilebilir olabilir.

Bu bağlama seçeneklerinin kullanılması, bu gibi durumlarda iş yükünü depolamaya önemli ölçüde azaltır. (Örneğin, yeni bir EDA deneyimi IOP'leri araç hacmine 150 K'dan >~6 K'ya indirdi.) Uygulamalar bellekteki verilere güvenebildiğinden önemli ölçüde daha hızlı çalışabilir. (Bellek erişim süresi, hızlı bir ağda /access için getattrnanosaniye ve yüzlerce mikrosaniyedir.)

Açık tutarlılığı kapatma

Açık duruma yakın tutarlılık ( cto bağlama seçeneği), önbelleğin durumu ne olursa olsun, açık durumda bir dosyanın en son verilerinin her zaman uygulamaya sunulmasını sağlar.

  • Bir dizinde gezinildiğinde (lsörneğin, ls -l belirli bir RPC kümesi (uzak yordam çağrıları) verilir. NFS sunucusu, dosya sistemi görünümünü paylaşır. Belirli bir NFS dışarı aktarma işlemine erişen tüm NFS istemcileri tarafından kullanıldığı sürece cto , tüm istemciler burada aynı dosya ve dizin listesini görür. Dizindeki dosyaların özniteliklerinin güncelliği, öznitelik önbelleği zamanlayıcıları tarafından denetlenir. Başka bir deyişle, cto dosya oluşturulduğu ve dosya depolama alanına indiği anda dosyalar uzak istemcilere görünür.
  • Bir dosya açıldığında, dosyanın içeriği NFS sunucusu açısından yeni bir şekilde garanti edilir. Makine 2'de bir dosya açıldığında içeriğin Makine 1'den boşaltılması tamamlanmamış bir yarış durumu varsa, Makine 2 yalnızca açık olduğunda sunucuda bulunan verileri alır. Bu durumda Makine 2, zamanlayıcıya ulaşılana kadar acreg dosyadan daha fazla veri almaz ve Makine 2 önbellek tutarlılığını sunucudan yeniden denetler. Bu senaryo, dosya Makine 1'den yazılmaya devam ederken Makine 2'den bir kuyruk -f kullanılarak gözlemlenebilir.

Açık tutarlılık yok

Açık duruma yakın tutarlılık (nocto) kullanılmadığında istemci, önbellek özniteliği zamanlayıcıları ihlal edilene kadar dosya ve dizinin geçerli görünümünün güncelliğine güvenir.

  • Bir dizinde gezinildiğinde (lsörneğin, ls -l belirli bir RPC kümesi (uzak yordam çağrıları) verilir. İstemci yalnızca önbellek zamanlayıcı değeri ihlal edildiğinde geçerli bir dosya listesi için sunucuya acdir çağrı gönderir. Bu durumda, yakın zamanda oluşturulan dosyalar ve dizinler görünmez. Son kaldırılan dosyalar ve dizinler görüntülenir.

  • Dosya hala önbellekte olduğu sürece bir dosya açıldığında, önbelleğe alınmış içeriği (varsa) NFS sunucusuyla tutarlılık doğrulanmadan döndürülür.

Sonraki adımlar