Rozwiązywanie problemów z konfiguracją serwera NAS i obiektem docelowym magazynu NFS

  • Artykuł

Ten artykuł zawiera rozwiązania niektórych typowych błędów konfiguracji i innych problemów, które mogą uniemożliwić usłudze Azure HPC Cache dodawanie systemu magazynu NFS jako miejsca docelowego magazynu.

Ten artykuł zawiera szczegółowe informacje na temat sprawdzania portów i sposobu włączania wymaganego dostępu do systemu NAS. Zawiera również szczegółowe informacje o mniej typowych problemach, które mogą powodować niepowodzenie tworzenia miejsca docelowego magazynu NFS.

Napiwek

Przed rozpoczęciem korzystania z tego przewodnika zapoznaj się z wymaganiami wstępnymi dotyczącymi miejsc docelowych magazynu NFS.

Jeśli rozwiązanie problemu nie zostało uwzględnione w tym miejscu, otwórz bilet pomocy technicznej, aby usługa i pomoc techniczna firmy Microsoft mogły współpracować z Tobą w celu zbadania i rozwiązania problemu.

Podaj wystarczające wątki połączenia

Duże systemy pamięci podręcznej HPC cache wysyłają wiele żądań połączeń do miejsca docelowego magazynu. Jeśli na przykład docelowy magazyn używa modułu Ubuntu Linux nfs-kernel-server , domyślna liczba wątków demona NFS może być nawet 8. Zwiększ liczbę wątków do 128 lub 256, które są bardziej rozsądne, aby obsługiwać średnią lub dużą pamięć podręczną HPC Cache.

Liczbę wątków w systemie Ubuntu można sprawdzić lub ustawić przy użyciu wartości RPCNFSDCOUNT w systemie /etc/init.d/nfs-kernel-server.

Sprawdzanie ustawień portów

Usługa Azure HPC Cache wymaga dostępu do odczytu/zapisu do kilku portów UDP/TCP w systemie magazynu NAS zaplecza. Upewnij się, że te porty są dostępne w systemie NAS, a także że ruch do tych portów jest dozwolony przez wszystkie zapory między systemem magazynu i podsiecią pamięci podręcznej. W celu zweryfikowania tej konfiguracji może być konieczna praca z administratorami zapory i sieci dla centrum danych.

Porty różnią się w przypadku systemów magazynowania od różnych dostawców, dlatego podczas konfigurowania miejsca docelowego magazynu sprawdź wymagania systemu.

Ogólnie rzecz biorąc, pamięć podręczna wymaga dostępu do następujących portów:

Protokół Port Service
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 zamontowany
TCP/UDP 4047 stan

Aby poznać określone porty wymagane dla systemu, użyj następującego rpcinfo polecenia. Poniższe polecenie wyświetla listę portów i formatuje odpowiednie wyniki w tabeli. (Użyj adresu IP systemu zamiast adresu < IP systemu> storage_IP termin.)

To polecenie można wydać z dowolnego klienta systemu Linux z zainstalowaną infrastrukturą NFS. Jeśli używasz klienta wewnątrz podsieci klastra, może również pomóc zweryfikować łączność między podsiecią a systemem magazynu.

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

Upewnij się, że wszystkie porty zwrócone przez rpcinfo zapytanie zezwalają na nieograniczony ruch z podsieci usługi Azure HPC Cache.

Sprawdź te ustawienia zarówno na serwerze NAS, jak i na wszystkich zaporach między systemem magazynu i podsiecią pamięci podręcznej.

Sprawdzanie ustawień głównego squasha

Ustawienia głównego squasha mogą zakłócać dostęp do plików, jeśli są one nieprawidłowo skonfigurowane. Należy sprawdzić, czy ustawienia każdego eksportu magazynu i zgodne zasady dostępu klienta usługi HPC Cache są odpowiednie.

Root squash uniemożliwia wysyłanie żądań przez lokalny katalog główny superużytkownika na kliencie do systemu magazynu zaplecza jako katalog główny. Ponownie przypisuje żądania z katalogu głównego do nieuprzywilejowanego identyfikatora użytkownika (UID), takiego jak "nikt".

Napiwek

Poprzednie wersje usługi Azure HPC Cache wymagały od systemów magazynowania NAS, aby umożliwić dostęp główny z pamięci podręcznej HPC Cache. Teraz nie musisz zezwalać na dostęp główny do eksportu docelowego magazynu, chyba że klienci usługi HPC Cache mają mieć dostęp główny do eksportu.

Root squash można skonfigurować w systemie HPC Cache w następujących miejscach:

  • W usłudze Azure HPC Cache — użyj zasad dostępu klienta, aby skonfigurować root squash dla klientów, którzy są zgodni z określonymi regułami filtrowania. Zasady dostępu klienta są częścią każdej docelowej ścieżki przestrzeni nazw magazynu NFS.

    Domyślne zasady dostępu klienta nie są głównym elementem głównym.

  • Podczas eksportowania magazynu — możesz skonfigurować system magazynu, aby ponownie przypisał żądania przychodzące z katalogu głównego do identyfikatora użytkownika bez uprawnień (UID).

Jeśli katalog główny eksportu systemu magazynu powoduje usunięcie zabezpieczeń katalogu głównego, należy zaktualizować regułę dostępu klienta usługi HPC Cache dla tego miejsca docelowego magazynu, aby również usunąć katalog główny. Jeśli nie, podczas próby odczytu lub zapisu w systemie magazynu zaplecza za pośrednictwem pamięci podręcznej HPC Cache mogą wystąpić problemy z dostępem.

W tej tabeli przedstawiono zachowanie dla różnych scenariuszy z użyciem głównego squasha, gdy żądanie klienta jest wysyłane jako identyfikator UID 0 (root). Scenariusz oznaczony jako * nie jest zalecany , ponieważ może powodować problemy z dostępem.

Ustawienie Identyfikator UID wysłany z klienta Identyfikator UID wysłany z pamięci podręcznej HPC Cache Skuteczny identyfikator UID w magazynie zaplecza
brak squasha głównego 0 (główny) 0 (główny) 0 (główny)
root squash tylko w pamięci podręcznej HPC Cache 0 (główny) 65534 (nikt) 65534 (nikt)
*Root squash tylko w magazynie NAS 0 (główny) 0 (główny) 65534 (nikt)
root squash w pamięci podręcznej HPC Cache i NAS 0 (główny) 65534 (nikt) 65534 (nikt)

(Identyfikator UID 65534 jest przykładem; po włączeniu root squash w zasadach dostępu klienta można dostosować identyfikator UID).

Sprawdzanie dostępu w ścieżkach katalogu

W przypadku systemów NAS, które eksportują katalogi hierarchiczne, sprawdź, czy usługa Azure HPC Cache ma odpowiedni dostęp do każdego poziomu eksportu w ścieżce do używanych plików.

Na przykład system może wyświetlać trzy eksporty w następujący sposób:

  • /ifs
  • /ifs/accounting
  • /ifs/accounting/payroll

Eksport /ifs/accounting/payroll jest elementem podrzędnym /ifs/accountingelementu i /ifs/accounting sam jest elementem podrzędnym /ifs.

W przypadku dodania payroll eksportu jako miejsca docelowego magazynu usługi HPC Cache pamięć podręczna faktycznie instaluje /ifs/ katalog listy płac i uzyskuje do niej dostęp. Dlatego usługa Azure HPC Cache potrzebuje wystarczającego /ifs/accounting/payroll dostępu, aby /ifs uzyskać dostęp do eksportu.

To wymaganie jest związane ze sposobem, w jaki pliki pamięci podręcznej indeksuje i unika kolizji plików przy użyciu dojść do plików zapewnianych przez system magazynowania.

System NAS z eksportami hierarchicznymi może dać różne dojścia plików dla tego samego pliku, jeśli plik jest pobierany z różnych eksportów. Na przykład klient może zainstalować /ifs/accounting i uzyskać dostęp do pliku payroll/2011.txt. Inny klient instaluje /ifs/accounting/payroll i uzyskuje dostęp do pliku 2011.txt. W zależności od tego, jak system magazynu przypisuje dojścia plików, ci dwaj klienci mogą odbierać ten sam plik z różnymi uchwytami plików (jeden dla <mount2>/payroll/2011.txt i jeden dla <mount3>/2011.txt).

System magazynu zaplecza przechowuje wewnętrzne aliasy do obsługi plików, ale usługa Azure HPC Cache nie może określić, które uchwyty plików w odwołaniu do indeksu odwołują się do tego samego elementu. Istnieje więc możliwość, że pamięć podręczna może mieć różne zapisy buforowane dla tego samego pliku i zastosować zmiany niepoprawnie, ponieważ nie wie, że są one tym samym plikiem.

Aby uniknąć tej możliwej kolizji plików w wielu eksportach, usługa Azure HPC Cache automatycznie instaluje płytki dostępny eksport w ścieżce (/ifs w przykładzie) i używa uchwytu pliku podanego z tego eksportu. Jeśli wiele eksportów używa tej samej ścieżki podstawowej, usługa Azure HPC Cache potrzebuje dostępu do tej ścieżki.

Dostosowywanie ograniczeń rozmiaru pakietów sieci VPN

Jeśli masz sieć VPN między pamięcią podręczną a urządzeniem NAS, sieć VPN może blokować pakiety Ethernet o pełnym rozmiarze 1500 bajtów. Ten problem może wystąpić, jeśli duże wymiany między serwerem NAS i wystąpieniem usługi Azure HPC Cache nie zakończą się, ale mniejsze aktualizacje działają zgodnie z oczekiwaniami.

Nie ma prostego sposobu na określenie, czy system ma ten problem, chyba że znasz szczegóły konfiguracji sieci VPN. Oto kilka metod, które mogą pomóc w sprawdzeniu tego problemu.

  • Użyj snifferów pakietów po obu stronach sieci VPN, aby wykryć, które pakiety zostały pomyślnie przeniesione.

  • Jeśli sieć VPN zezwala na polecenia ping, możesz przetestować wysyłanie pakietu o pełnym rozmiarze.

    Uruchom polecenie ping za pośrednictwem sieci VPN do serwera NAS przy użyciu tych opcji. (Użyj adresu IP systemu magazynu zamiast adresu < IP> storage_IP wartość).

    ping -M do -s 1472 -c 1 <storage_IP>

    Są to opcje w poleceniu:

    • -M do - Nie fragmentu
    • -c 1 — Wysyłanie tylko jednego pakietu
    • -s 1472 - Ustaw rozmiar ładunku na 1472 bajty. Jest to maksymalny ładunek rozmiaru pakietu 1500 bajtów po uwzględnieniu obciążenia sieci Ethernet.

    Prawidłowa odpowiedź wygląda następująco:

    PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms

    Jeśli polecenie ping zakończy się niepowodzeniem z 1472 bajtami, prawdopodobnie występuje problem z rozmiarem pakietu.

Aby rozwiązać ten problem, może być konieczne skonfigurowanie zaciskania usługi MSS w sieci VPN, aby system zdalny prawidłowo wykrył maksymalny rozmiar ramki. Przeczytaj dokumentację parametrów protokołu IPsec/IKE usługi VPN Gateway, aby dowiedzieć się więcej.

W niektórych przypadkach zmiana ustawienia jednostki MTU dla usługi Azure HPC Cache na 1400 może pomóc. Jednak w przypadku ograniczenia jednostki MTU w pamięci podręcznej należy również ograniczyć ustawienia jednostki MTU dla klientów i systemów magazynu zaplecza, które współdziałają z pamięcią podręczną. Aby uzyskać szczegółowe informacje, zobacz Konfigurowanie dodatkowych ustawień usługi Azure HPC Cache.

Sprawdzanie stylu zabezpieczeń listy ACL

Niektóre systemy NAS używają hybrydowego stylu zabezpieczeń, który łączy listy kontroli dostępu (ACL) z tradycyjnymi zabezpieczeniami POSIX lub system UNIX.

Jeśli system zgłasza swój styl zabezpieczeń jako system UNIX lub POSIX bez uwzględniania akronimu "ACL", ten problem nie ma wpływu na Ciebie.

W przypadku systemów korzystających z list ACL usługa Azure HPC Cache musi śledzić dodatkowe wartości specyficzne dla użytkownika w celu kontrolowania dostępu do plików. Odbywa się to przez włączenie pamięci podręcznej dostępu. Nie ma kontroli dostępnej dla użytkownika, aby włączyć pamięć podręczną dostępu, ale możesz otworzyć bilet pomocy technicznej, aby poprosić o włączenie jej dla obiektów docelowych magazynu, których dotyczy problem, w systemie pamięci podręcznej.

Następne kroki

Jeśli masz problem, który nie został rozwiązany w tym artykule, skontaktuj się z pomocą techniczną, aby uzyskać pomoc ekspertów.