Felsöka problem med NAS-konfiguration och NFS-lagringsmål

  • Artikel

Den här artikeln innehåller lösningar på några vanliga konfigurationsfel och andra problem som kan hindra Azure HPC Cache från att lägga till ett NFS-lagringssystem som lagringsmål.

Den här artikeln innehåller information om hur du kontrollerar portar och hur du aktiverar nödvändig åtkomst till ett NAS-system. Den innehåller också detaljerad information om mindre vanliga problem som kan orsaka att NFS-lagringsmål skapas.

Dricks

Läs kraven för NFS-lagringsmål innan du använder den här guiden.

Om lösningen på problemet inte ingår här öppnar du ett supportärende så att Microsoft Service och Support kan samarbeta med dig för att undersöka och lösa problemet.

Tillhandahålla tillräckligt med anslutningstrådar

Stora HPC Cache-system gör flera anslutningsbegäranden till ett lagringsmål. Om ditt lagringsmål till exempel använder Ubuntu Linux-modulen nfs-kernel-server kan standardantalet NFS-daemontrådar vara så lågt som åtta. Öka antalet trådar till 128 eller 256, vilket är mer rimliga siffror för att stödja en medelstor eller stor HPC Cache.

Du kan kontrollera eller ange antalet trådar i Ubuntu med hjälp av RPCNFSDCOUNT-värdet i /etc/init.d/nfs-kernel-server.

Kontrollera portinställningar

Azure HPC Cache behöver läs-/skrivåtkomst till flera UDP/TCP-portar i serverdelens NAS-lagringssystem. Kontrollera att dessa portar är tillgängliga i NAS-systemet och att trafik tillåts till dessa portar via brandväggar mellan lagringssystemet och cacheundernätet. Du kan behöva arbeta med brandväggs- och nätverksadministratörer för ditt datacenter för att verifiera den här konfigurationen.

Portarna skiljer sig åt för lagringssystem från olika leverantörer, så kontrollera systemets krav när du konfigurerar ett lagringsmål.

I allmänhet behöver cachen åtkomst till dessa portar:

Protokoll Port Tjänst
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 monterad
TCP/UDP 4047 status

Om du vill veta vilka specifika portar som behövs för systemet använder du följande rpcinfo kommando. Det här kommandot nedan visar portarna och formaterar relevanta resultat i en tabell. (Använd systemets IP-adress i stället för <> storage_IP term.)

Du kan utfärda det här kommandot från alla Linux-klienter som har NFS-infrastruktur installerad. Om du använder en klient i klustrets undernät kan det även hjälpa dig att verifiera anslutningen mellan undernätet och lagringssystemet.

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

Kontrollera att alla portar som returneras av rpcinfo frågan tillåter obegränsad trafik från Azure HPC Caches undernät.

Kontrollera de här inställningarna både på SJÄLVA NAS:en och även på eventuella brandväggar mellan lagringssystemet och cacheundernätet.

Kontrollera inställningarna för rot squash

Root squash-inställningar kan störa filåtkomsten om de är felaktigt konfigurerade. Du bör kontrollera att inställningarna för varje lagringsexport och på de matchande HPC Cache-klientåtkomstprinciperna är lämpliga.

Rot squash förhindrar att begäranden som skickas av en lokal superanvändarrot på klienten skickas till ett serverdelslagringssystem som rot. Begäranden tilldelas om från roten till ett icke-privilegierat användar-ID (UID) som "ingen".

Dricks

Tidigare versioner av Azure HPC Cache krävde NAS-lagringssystem för att tillåta rotåtkomst från HPC Cache. Nu behöver du inte tillåta rotåtkomst på en lagringsmålexport om du inte vill att HPC Cache-klienter ska ha rotåtkomst till exporten.

Rot squash kan konfigureras i ett HPC Cache-system på följande platser:

  • I Azure HPC Cache – Använd klientåtkomstprinciper för att konfigurera root squash för klienter som matchar specifika filterregler. En klientåtkomstprincip är en del av varje namnområdessökväg för NFS-lagringsmål.

    Standardprincipen för klientåtkomst krossar inte roten.

  • Vid lagringsexporten – Du kan konfigurera lagringssystemet för att tilldela om inkommande begäranden från roten till ett icke-privilegierat användar-ID (UID).

Om lagringssystemet exporterar roten bör du uppdatera HPC Cache-klientåtkomstregeln för lagringsmålet till att även krossa roten. Annars kan du få åtkomstproblem när du försöker läsa eller skriva till serverdelslagringssystemet via HPC Cache.

Den här tabellen illustrerar beteendet för olika root squash-scenarier när en klientbegäran skickas som UID 0 (rot). Scenariot som är markerat med * rekommenderas inte eftersom det kan orsaka åtkomstproblem.

Inställning UID som skickas från klienten UID som skickas från HPC Cache Effektivt UID på serverdelslagring
ingen rot squash 0 (rot) 0 (rot) 0 (rot)
root squash på endast HPC Cache 0 (rot) 65534 (ingen) 65534 (ingen)
*endast rot squash på NAS-lagring 0 (rot) 0 (rot) 65534 (ingen)
root squash på HPC Cache and NAS 0 (rot) 65534 (ingen) 65534 (ingen)

(UID 65534 är ett exempel. När du aktiverar rot squash i en klientåtkomstprincip kan du anpassa UID.)

Kontrollera åtkomsten för katalogsökvägar

För NAS-system som exporterar hierarkiska kataloger kontrollerar du att Azure HPC Cache har lämplig åtkomst till varje exportnivå i sökvägen till de filer som du använder.

Ett system kan till exempel visa tre exporter som dessa:

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

Exporten /ifs/accounting/payroll är underordnad /ifs/accountingoch /ifs/accounting är i sig underordnad /ifs.

Om du lägger till payroll exporten som ett HPC Cache-lagringsmål monteras /ifs/ cachen och kommer åt lönekatalogen därifrån. Azure HPC Cache behöver därför tillräcklig åtkomst för /ifs att få åtkomst /ifs/accounting/payroll till exporten.

Det här kravet gäller hur cachen indexerar filer och undviker filkollisioner med hjälp av filhandtag som lagringssystemet tillhandahåller.

Ett NAS-system med hierarkisk export kan ge olika filhandtag för samma fil om filen hämtas från olika exporter. En klient kan till exempel montera /ifs/accounting och komma åt filen payroll/2011.txt. En annan klient monterar /ifs/accounting/payroll och kommer åt filen 2011.txt. Beroende på hur lagringssystemet tilldelar filhandtag kan dessa två klienter få samma fil med olika filhandtag (en för <mount2>/payroll/2011.txt och en för <mount3>/2011.txt).

Serverdelslagringssystemet behåller interna alias för filhandtag, men Azure HPC Cache kan inte avgöra vilka filreferenser i indexreferensen som är samma objekt. Det är därför möjligt att cacheminnet kan ha olika skrivningar cachelagrade för samma fil och tillämpa ändringarna felaktigt eftersom det inte vet att de är samma fil.

För att undvika den här möjliga filkollisionen för filer i flera exporter monterar Azure HPC Cache automatiskt den ytligaste tillgängliga exporten i sökvägen (/ifs i exemplet) och använder filhandtaget som anges från exporten. Om flera exporter använder samma bassökväg behöver Azure HPC Cache åtkomst till den sökvägen.

Justera storleksbegränsningar för VPN-paket

Om du har ett VPN mellan cachen och NAS-enheten kan VPN blockera fullstora Ethernet-paket med 1 500 byte. Du kan ha det här problemet om stora utbyten mellan NAS och Azure HPC Cache-instansen inte slutförs, men mindre uppdateringar fungerar som förväntat.

Det finns inget enkelt sätt att avgöra om systemet har det här problemet eller inte om du inte känner till informationen om VPN-konfigurationen. Här följer några metoder som kan hjälpa dig att söka efter det här problemet.

  • Använd paketsniffare på båda sidor av VPN för att identifiera vilka paket som överförs.

  • Om VPN tillåter ping-kommandon kan du testa att skicka ett fullstort paket.

    Kör ett ping-kommando över VPN till NAS med de här alternativen. (Använd lagringssystemets IP-adress i stället för <> storage_IP värde.)

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

    Det här är alternativen i kommandot:

    • -M do – Fragmenta inte
    • -c 1 - Skicka endast ett paket
    • -s 1472 – Ange nyttolastens storlek till 1 472 byte. Det här är den maximala nyttolasten för ett paket på 1 500 byte efter att du har redovisat Ethernet-omkostnaderna.

    Ett framgångsrikt svar ser ut så här:

    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

    Om pingen misslyckas med 1 472 byte finns det förmodligen ett problem med paketstorleken.

För att åtgärda problemet kan du behöva konfigurera MSS-klämning på VPN för att fjärrsystemet ska kunna identifiera den maximala bildrutestorleken korrekt. Läs dokumentationen om IPsec/IKE-parametrar för VPN Gateway om du vill veta mer.

I vissa fall kan det vara till hjälp att ändra MTU-inställningen för Azure HPC Cache till 1400. Men om du begränsar MTU i cacheminnet måste du också begränsa MTU-inställningarna för klienter och serverdelslagringssystem som interagerar med cachen. Mer information finns i Konfigurera ytterligare Azure HPC Cache-inställningar .

Sök efter ACL-säkerhetsformat

Vissa NAS-system använder en hybridsäkerhetsstil som kombinerar åtkomstkontrollistor (ACL: er) med traditionell POSIX- eller UNIX-säkerhet.

Om systemet rapporterar sin säkerhetsstil som UNIX eller POSIX utan att ta med förkortningen "ACL" påverkar inte det här problemet dig.

För system som använder ACL:er måste Azure HPC Cache spåra ytterligare användarspecifika värden för att kunna styra filåtkomsten. Detta görs genom att aktivera en åtkomstcache. Det finns ingen användarriktad kontroll för att aktivera åtkomstcachen, men du kan öppna en supportbegäran för att begära att den ska aktiveras för de berörda lagringsmålen i cachesystemet.

Nästa steg

Om du har ett problem som inte har åtgärdats i den här artikeln kontaktar du supporten för att få experthjälp.