Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące instalacji systemu plików NFS w systemie Linux dla usługi Azure NetApp Files

  • Artykuł

Ten artykuł ułatwia zapoznanie się z opcjami instalacji i najlepszymi rozwiązaniami dotyczącymi korzystania z nich w usłudze Azure NetApp Files.

Nconnect

nconnect Użycie opcji instalacji umożliwia określenie liczby połączeń (przepływów sieciowych), które należy ustanowić między klientem systemu plików NFS i punktem końcowym NFS do limitu 16. Tradycyjnie klient systemu plików NFS używa jednego połączenia między samym sobą a punktem końcowym. Zwiększenie liczby przepływów sieci znacznie zwiększa górne limity operacji we/wy i przepływności. Testy okazały się nconnect=8 najbardziej wydajne.

Podczas przygotowywania środowiska SAS GRID z wieloma węzłami do środowiska produkcyjnego można zauważyć powtarzalny 30% redukcji czasu wykonywania z 8 godzin do 5,5 godziny:

Opcja instalacji Czasy uruchamiania zadania
Nr nconnect 8 godzin
nconnect=8 5,5 godziny

Oba zestawy testów używały tej samej maszyny wirtualnej E32-8_v4 i RHEL8.3 z wyprzedzeniem odczytu ustawionym na 15 MiB.

W przypadku korzystania z programu nconnectnależy pamiętać o następujących regułach:

  • nconnect program jest obsługiwany przez usługę Azure NetApp Files we wszystkich głównych dystrybucjach systemu Linux, ale tylko w nowszych wersjach:

    Wersja systemu Linux NFSv3 (wersja minimalna) NFSv4.1 (minimalna wersja)
    Redhat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 lub SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Uwaga

    SLES15SP2 to minimalna wersja SUSE obsługiwana nconnect przez usługę Azure NetApp Files dla systemu plików NFSv4.1. Wszystkie inne wersje zgodnie z określoną określoną wersją to pierwsze wersje, które wprowadziły nconnect tę funkcję.

  • Wszystkie instalacji z jednego punktu końcowego dziedziczą nconnect ustawienie pierwszego zainstalowanego eksportu, jak pokazano w następujących scenariuszach:

    Scenariusz 1: nconnect jest używany przez pierwszą instalację. W związku z tym wszystkie instalacji względem tego samego punktu końcowego używają polecenia 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

    Scenariusz 2: nconnect nie jest używany przez pierwszą instalację. W związku z tym nie ma instalacji względem tego samego użycia nconnect punktu końcowego, mimo że nconnect można je określić w tym samym miejscu.

    • 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

    Scenariusz 3: nconnect ustawienia nie są propagowane między oddzielnymi punktami końcowymi magazynu. nconnect jest używany przez instalację pochodzącą z 10.10.10.10 instalacji, ale nie przez instalację pochodzącą z programu 10.12.12.12.

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

  • nconnect może służyć do zwiększenia współbieżności magazynu z dowolnego klienta.

Aby uzyskać szczegółowe informacje, zobacz Linux concurrency best practices for Azure NetApp Files (Najlepsze rozwiązania dotyczące współbieżności systemu Linux dla usługi Azure NetApp Files).

Nconnect Zagadnienia dotyczące

Nie zaleca się używania nconnect i sec=krb5* instalowania opcji razem. Spadek wydajności zaobserwowano w przypadku używania dwóch opcji w połączeniu.

Interfejs GSS-API (Generic Security Standard Application Programming Interface) umożliwia aplikacjom ochronę danych wysyłanych do aplikacji równorzędnych. Te dane mogą być wysyłane z klienta na jednej maszynie do serwera na innej maszynie. 

Gdy nconnect jest używany w systemie Linux, kontekst zabezpieczeń GSS jest współużytkowany między wszystkimi nconnect połączeniami z określonym serwerem. TCP to niezawodny transport, który obsługuje dostarczanie pakietów poza zamówieniem w celu obsługi pakietów poza zamówieniem w strumieniu GSS przy użyciu przesuwanego okna numerów sekwencji. Gdy pakiety nie są odbierane w oknie sekwencji, kontekst zabezpieczeń zostanie odrzucony i zostanie wynegocjowany nowy kontekst zabezpieczeń. Wszystkie komunikaty wysyłane w kontekście teraz odrzuconym nie są już prawidłowe, co wymaga ponownego wysłania komunikatów. Większa liczba pakietów w nconnect konfiguracji powoduje częste pakiety poza oknem, wyzwalając opisane zachowanie. Nie można określić określonych wartości procentowych degradacji przy użyciu tego zachowania.

Rsize i Wsize

Przykłady w tej sekcji zawierają informacje na temat podejścia do dostrajania wydajności. Może być konieczne wprowadzenie zmian w celu dopasowania do określonych potrzeb aplikacji.

Flagi rsize i wsize ustawiają maksymalny rozmiar transferu operacji NFS. wsize Jeśli rsize instalacja lub nie zostanie określona, klient i serwer negocjują największy rozmiar obsługiwany przez te dwa. Obecnie zarówno usługa Azure NetApp Files, jak i nowoczesne dystrybucje systemu Linux obsługują rozmiary odczytu i zapisu nawet 1 048 576 bajtów (1 MiB). Jednak w celu uzyskania najlepszej ogólnej przepływności i opóźnień usługa Azure NetApp Files zaleca ustawienie zarówno i rsizewsize nie większe niż 262 144 bajtów (256 K). Możesz zauważyć, że zarówno zwiększone opóźnienie, jak i zmniejszona przepływność w przypadku używania rsize i wsize większej niż 256 KiB.

Na przykład wdrożenie systemu SAP HANA skalowalnego w poziomie z węzłem rezerwowym na maszynach wirtualnych platformy Azure przy użyciu usługi Azure NetApp Files na serwerze SUSE Linux Enterprise Server pokazuje 256-KiB rsize i wsize maksymalnie w następujący sposób:

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

Na przykład sas Viya zaleca 256-KiB rozmiary odczytu i zapisu, a SAS GRID ogranicza r/wsize do 64 KiB podczas rozszerzania wydajności odczytu z większym wyprzedzeniem dla instalacji NFS. Aby uzyskać szczegółowe informacje, zobacz Artykuł NFS read-ahead best practices for Azure NetApp Files (Najlepsze rozwiązania dotyczące odczytu systemu plików NFS dla usługi Azure NetApp Files ).

Następujące zagadnienia mają zastosowanie do użycia elementów rsize i wsize:

  • Losowe rozmiary operacji we/wy są często mniejsze niż rsize opcje instalacji i wsize . W związku z tym w efekcie nie zostaną one ograniczone.
  • W przypadku korzystania z pamięci podręcznej systemu plików sekwencyjne operacje we/wy będą występować przy rozmiarze wstępnie określonym przez rsize opcje instalacji i , chyba że rozmiar pliku jest mniejszy niż rsize i wsizewsize.
  • Operacje pomijania pamięci podręcznej systemu plików, mimo że nadal ograniczone przez rsize opcje i wsize instalacji, niekoniecznie będą wystawiane tak duże, jak maksymalna wartość określona przez rsize lub wsize. Ta kwestia jest ważna w przypadku korzystania z generatorów obciążeń, które mają directio tę opcję.

Najlepszym rozwiązaniem w przypadku usługi Azure NetApp Files w celu uzyskania najlepszej ogólnej przepływności i opóźnienia jest ustawienie rsize i wsize nie większe niż 262 144 bajtów.

Czasomierze atrybutów zbliżenia do otwierania i pamięci podręcznej

NFS używa luźnego modelu spójności. Spójność jest luźna, ponieważ aplikacja nie musi przechodzić do udostępnionego magazynu i pobierać dane za każdym razem, aby z nich korzystać, scenariusz, który miałby ogromny wpływ na wydajność aplikacji. Istnieją dwa mechanizmy, które zarządzają tym procesem: czasomierze atrybutów pamięci podręcznej i spójność zbliżona do otwartej.

Jeśli klient ma pełną własność danych, oznacza to, że nie jest on współużytkowany między wieloma węzłami lub systemami, gwarantuje to spójność. W takim przypadku można zmniejszyć getattr operacje dostępu do magazynu i przyspieszyć działanie aplikacji, wyłączając spójność zbliżenia do otwierania () (noctoctojako opcję instalacji) i włączając limity czasu zarządzania pamięcią podręczną atrybutów (actimeo=600jako opcja instalacji zmienia czasomierz na 10 m w porównaniu z wartościami domyślnymiacregmin=3,acregmax=30,acdirmin=30,acdirmax=60). W niektórych testach nocto zmniejsza około 65–70% getattr wywołań dostępu, a dostosowanie actimeo zmniejsza liczbę wywołań o kolejne 20–25%.

Jak działają czasomierze pamięci podręcznej atrybutów

Atrybuty acregmin, acregmax, acdirmini acdirmax kontrolują współistnienie pamięci podręcznej. Poprzednie dwa atrybuty kontrolują, jak długo atrybuty plików są zaufane. Dwa ostatnie atrybuty kontrolują, jak długo atrybuty samego pliku katalogu są zaufane (rozmiar katalogu, własność katalogu, uprawnienia katalogu). Atrybuty min i max definiują minimalny i maksymalny czas trwania, przez który atrybuty katalogu, atrybuty pliku i zawartość pamięci podręcznej pliku są uznawane za wiarygodne. Między min i maxalgorytm służy do definiowania czasu, przez jaki wpis w pamięci podręcznej jest zaufany.

Rozważmy na przykład odpowiednio wartości domyślne acregmin i acregmax 3 i 30 sekund. Na przykład atrybuty są wielokrotnie oceniane dla plików w katalogu. Po 3 sekundach usługa NFS jest odpytywane pod kątem aktualności. Jeśli atrybuty są uznawane za prawidłowe, klient podwaja zaufany czas do 6 sekund, 12 sekund, 24 sekund, a wartość maksymalna jest ustawiona na 30, 30 sekund. Od tego momentu, dopóki atrybuty w pamięci podręcznej nie zostaną uznane za nieaktualne (w którym momencie rozpoczyna się cykl), wiarygodność jest definiowana jako 30 sekund jako wartość określona przez acregmax.

Istnieją inne przypadki, które mogą korzystać z podobnego zestawu opcji instalacji, nawet jeśli klienci nie mają pełnej własności, na przykład jeśli klienci używają danych jako tylko do odczytu, a aktualizacja danych jest zarządzana za pomocą innej ścieżki. W przypadku aplikacji korzystających z siatek klientów, takich jak EDA, hosting internetowy i renderowanie filmów oraz mają stosunkowo statyczne zestawy danych (narzędzia lub biblioteki EDA, zawartość internetowa, dane tekstury), typowe zachowanie polega na tym, że zestaw danych jest w dużej mierze buforowany na klientach. Istnieje kilka operacji odczytu i brak zapisów. Będzie wiele getattrwywołań /access wracających do magazynu. Te zestawy danych są zwykle aktualizowane za pośrednictwem innego klienta instalowania systemów plików i okresowo wypychania aktualizacji zawartości.

W takich przypadkach występuje znane opóźnienie podczas wybierania nowej zawartości, a aplikacja nadal działa z potencjalnie nieaktualnymi danymi. W takich przypadkach nocto i actimeo może służyć do kontrolowania okresu, w którym można zarządzać nieaktualną datą danych. Na przykład w narzędziach i bibliotekach EDA dobrze się sprawdza, actimeo=600 ponieważ te dane są zwykle często aktualizowane. W przypadku małego hostingu internetowego, w którym klienci muszą widzieć aktualizacje danych w odpowiednim czasie podczas edytowania witryn, actimeo=10 mogą być akceptowalne. W przypadku witryn internetowych na dużą skalę, w których zawartość jest wypychana do wielu systemów plików, actimeo=60 może być akceptowalna.

Użycie tych opcji instalacji znacznie zmniejsza obciążenie do magazynu w takich przypadkach. (Na przykład ostatnie środowisko EDA zmniejszyło liczbę operacji we/wy na wolumin narzędzia z >150 K do ~6 K). Aplikacje mogą działać znacznie szybciej, ponieważ mogą ufać danym w pamięci. (Czas dostępu do pamięci to nanosekundy a setki mikrosekund dla getattr/access w szybkiej sieci).

Spójność zbliżenia do otwierania

Spójność zbliżenia do otwierania ( cto opcja instalacji) gwarantuje, że niezależnie od stanu pamięci podręcznej, podczas otwierania najnowszych danych dla pliku zawsze są prezentowane aplikacji.

  • Po przeszukaniu katalogu (lsls -lna przykład) zostanie wystawiony określony zestaw wywołań procedury zdalnej (procedury zdalnej).
    Serwer NFS udostępnia swój widok systemu plików. Tak długo, jak cto jest używany przez wszystkich klientów NFS, którzy uzyskują dostęp do danego eksportu NFS, wszyscy klienci zobaczą tę samą listę plików i katalogów w tym miejscu. Świeżość atrybutów plików w katalogu jest kontrolowana przez czasomierze pamięci podręcznej atrybutów. Innymi słowy, o ile cto jest używany, pliki są wyświetlane klientom zdalnym zaraz po utworzeniu pliku, a plik znajduje się w magazynie.
  • Po otwarciu pliku zawartość pliku jest gwarantowana świeżo z perspektywy serwera NFS.
    Jeśli istnieje warunek wyścigu, w którym zawartość nie została zakończona opróżnianie z maszyny 1 po otwarciu pliku na maszynie 2, maszyna 2 otrzyma tylko dane obecne na serwerze w momencie otwarcia. W takim przypadku maszyna 2 nie będzie pobierać większej ilości danych z pliku, dopóki acreg czasomierz nie zostanie osiągnięty, a maszyna 2 ponownie sprawdzi jego współistnienie pamięci podręcznej z serwera. Ten scenariusz można zaobserwować przy użyciu ogona -f z maszyny 2, gdy plik jest nadal zapisywany z maszyny 1.

Brak spójności zbliżonej do otwartej

Jeśli nie jest używana spójność bliska otwierania (nocto), klient będzie ufać aktualności bieżącego widoku pliku i katalogu do momentu naruszenia limitu czasu atrybutów pamięci podręcznej.

  • Po przeszukaniu katalogu (lsls -lna przykład) zostanie wystawiony określony zestaw wywołań procedury zdalnej (procedury zdalnej).
    Klient wyda wywołanie serwera tylko dla bieżącej listy plików, gdy acdir wartość czasomierza pamięci podręcznej została naruszona. W takim przypadku ostatnio utworzone pliki i katalogi nie będą wyświetlane, a ostatnio usunięte pliki i katalogi będą nadal wyświetlane.

  • Po otwarciu pliku, o ile plik jest nadal w pamięci podręcznej, jego buforowana zawartość (jeśli istnieje) jest zwracana bez sprawdzania spójności z serwerem NFS.

Następne kroki