Udostępnij za pośrednictwem

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

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

Użycie opcji montowania nconnect umożliwia określenie liczby połączeń (przepływów sieciowych), które należy ustanowić między klientem systemu plików NFS a punktem końcowym NFS aż do limitu 16 połączeń. 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 sieciowych znacznie zwiększa górne limity operacji we/wy i przepływności. Testy wykazały, że nconnect=8 jest najbardziej wydajnym.

Podczas przygotowywania środowiska SAS GRID z wieloma węzłami pod kątem produkcji można zauważyć powtarzalną 30-procentową redukcję czasu wykonania z 8 godzin do 5,5 godziny:

Opcja instalacji Czasy uruchamiania zadania
Nie nconnect 8 godzin
nconnect=8 5.5 godz.

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:

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

    Uwaga

    SLES15SP2 to minimalne wydanie SUSE, w którym nconnect jest obsługiwane przez usługę Azure NetApp Files dla systemu plików NFSv4.1. Wszystkie pozostałe wersje, jak określono, to pierwsze wersje, które wprowadziły funkcję nconnect.

  • 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 montaże na tym samym punkcie końcowym używają 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 zachodzi montowanie na ten sam punkt końcowy z użyciem nconnect, mimo że można określić nconnect na nim.

    • 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 montaż pochodzący z 10.10.10.10, ale nie przez montaż pochodzący z 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 być używany do zwiększenia współbieżności przechowywania dla 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 Uwagi

Nie zaleca się używania opcji montowania nconnect i sec=krb5* jednocześnie. Użycie tych opcji razem może spowodować obniżenie wydajności.

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 są odbierane poza oknem sekwencji, kontekst zabezpieczeń jest odrzucany, a nowy kontekst zabezpieczeń jest negocjowany. 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 konfiguracji nconnect powoduje częste występowanie pakietów spoza okna, 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. Jeśli rsize ani wsize nie są określone podczas montowania, klient i serwer negocjują największy rozmiar obsługiwany przez oba. 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, aby zarówno rsize, jak i wsize nie były ustawione na wartości większe niż 262 144 bajtów (256 K). Możesz zauważyć, że zarówno zwiększone opóźnienie, jak i zmniejszona przepustowość w przypadku używania rsize i wsize większych niż 256 KiB.

Na przykład wdrożenie systemu SAP HANA typu scale-out z węzłem zapasowym na maszynach wirtualnych Azure przy użyciu usługi Azure NetApp Files na serwerze SUSE Linux Enterprise Server pokazuje maksymalny rozmiar 256 KiB rsize i wsize 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 rozmiary odczytu i zapisu wynoszące 256 KiB, a SAS GRID ogranicza r/wsize do 64 KiB, jednocześnie zwiększając wydajność odczytu dzięki większemu wyprzedzeniu odczytu dla instalacji NFS. Aby uzyskać szczegółowe informacje, zobacz Najlepsze praktyki dotyczące odczytu wstępnego NFS dla 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ż opcje montowania rsize i wsize. W związku z tym nie są one ograniczeniami.
  • W przypadku korzystania z pamięci podręcznej systemu plików, sekwencyjne operacje wejścia/wyjścia będą występować przy rozmiarze określonym przez opcje montowania rsize i wsize, chyba że rozmiar pliku jest mniejszy niż rsize lub wsize.
  • Operacje pomijające pamięć podręczną systemu plików, mimo że nadal są ograniczone przez opcje montowania rsize i wsize, nie są tak duże, jak maksymalna określona przez rsize lub wsize. Ta kwestia jest ważna w przypadku korzystania z generatorów obciążeń, które mają opcję directio.

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.

Spójność otwarcia po zamknięciu i czasomierze atrybutów pamięci podręcznej

NFS używa luźnego modelu spójności. Spójność jest luźna, ponieważ aplikacja nie musi za każdym razem przechodzić do magazynu współdzielonego, aby pobierać i wykorzystywać dane, co miałoby 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 dane nie są współużytkowane między wieloma węzłami lub systemami, co zapewnia gwarantowaną spójność. W takim przypadku można zmniejszyć getattr operacje dostępu do magazynu i przyspieszyć działanie aplikacji, wyłączając spójność close-to-open (ctonocto jako opcję instalacji) i zwiększając limity czasu zarządzania pamięcią podręczną atrybutów (actimeo=600 jako opcja instalacji zmienia czasomierz na 10 min w porównaniu z wartościami domyślnymi acregmin=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ą liczniki 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ą uznawane za wiarygodne. Dwa ostatnie atrybuty kontrolują, jak długo parametry atrybutów samego pliku katalogu są uznawane za wiarygodne (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 max algorytm służy do definiowania czasu, przez jaki wpis w pamięci podręcznej jest uznawany za 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 odpytywana w celu sprawdzenia 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, aż do momentu, gdy atrybuty w pamięci podręcznej zostaną uznane za nieaktualne (w którym to momencie cykl rozpoczyna się od nowa), wiarygodność jest określana jako wartość 30 sekund zgodnie z acregmax.

Istnieją inne przypadki, które mogą wykorzystać podobny zestaw opcji montowania, nawet jeśli klienci nie mają pełnej własności, na przykład, gdy klienci używają danych w trybie tylko do odczytu, a aktualizacja danych jest zarządzana przez inną ścieżkę. 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. Istnieje wiele wywołań getattr/access wracających do pamięci masowej. Te zestawy danych są zwykle aktualizowane za pośrednictwem innego klienta, który montuje systemy plików i okresowo przesyła aktualizacje 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 rzadko 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 montowania znacznie zmniejsza obciążenie 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 w porównaniu do setek mikrosekund na getattr/access w szybkiej sieci).

Spójność od zamknięcia do otwarcia

Spójność zamykania i otwierania (opcja montowania cto) gwarantuje, że niezależnie od stanu pamięci podręcznej, przy otwieraniu aplikacji zawsze są przedstawiane najnowsze dane dla pliku.

  • Po przeszukaniu katalogu (ls, ls -l na przykład) zostanie przeprowadzony określony zestaw wywołań 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 uzyskujących dostęp do danego eksportu NFS, wszyscy klienci widzą tę samą listę plików i katalogów. Świeżość atrybutów plików w katalogu jest kontrolowana przez czasomierze pamięci podręcznej atrybutów. Innymi słowy, dopóki cto jest używany, pliki są wyświetlane klientom zdalnym zaraz po utworzeniu pliku, a plik znajduje się na magazynie.
  • Z perspektywy serwera NFS zawartość pliku po jego otwarciu jest gwarantowana jako świeża. Jeśli pojawia się sytuacja wyścigu, w której zawartość nie została do końca opróżniona na maszynie 1 w momencie otwarcia pliku na maszynie 2, maszyna 2 odbiera tylko te dane, które są obecne na serwerze w chwili otwarcia. W takim przypadku Maszyna 2 nie pobiera więcej danych z pliku, dopóki nie zostanie osiągnięty acreg czasomierz, po czym Maszyna 2 ponownie sprawdza spójność swojej pamięci podręcznej z serwerem. Można zaobserwować ten scenariusz, używając komendy tail -f na maszynie 2, kiedy plik jest nadal zapisywany przez maszynę 1.

Brak spójności zbliżonej do otwartej

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

  • Po przeszukaniu katalogu (ls, ls -l na przykład) zostanie przeprowadzony określony zestaw wywołań procedury zdalnej. Klient wysyła żądanie do serwera tylko po bieżącą listę plików, gdy acdir wartość czasomierza pamięci podręcznej została przekroczona. W takim przypadku ostatnio utworzone pliki i katalogi nie są wyświetlane. Ostatnio usunięte pliki i katalogi są 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