Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 nconnect
należ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życiemnconnect
, 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 z10.10.10.10
, ale nie przez montaż pochodzący z10.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
iwsize
. 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
iwsize
, chyba że rozmiar pliku jest mniejszy niżrsize
lubwsize
. - Operacje pomijające pamięć podręczną systemu plików, mimo że nadal są ograniczone przez opcje montowania
rsize
iwsize
, nie są tak duże, jak maksymalna określona przezrsize
lubwsize
. 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 (cto
nocto
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
, acdirmin
i 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, jakcto
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ókicto
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, gdyacdir
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
- Najlepsze rozwiązania dotyczące bezpośredniego we/wy systemu Linux dla usługi Azure NetApp Files
- Najlepsze praktyki dotyczące pamięci podręcznej systemu plików Linux dla usługi Azure NetApp Files
- Najlepsze rozwiązania dotyczące współbieżności systemu Linux dla usługi Azure NetApp Files
- Najlepsze praktyki dotyczące odczytu NFS w systemie Linux
- Najlepsze rozwiązania dotyczące jednostek SKU maszyn wirtualnych platformy Azure
- Testy porównawcze wydajności w systemie Linux