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

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

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

Om lösningen på ditt problem inte ingår här öppnar du en supportbiljett så att Microsofts tjänst och support kan hjälpa dig att undersöka och lösa problemet.

Kontrollera portinställningar

Azure HPC Cache behöver läs-/skrivåtkomst till flera UDP-/TCP-portar i NAS-lagringssystemet på backend-enheten. Kontrollera att dessa portar är tillgängliga i NAS-systemet och att trafik tillåts till dessa portar via eventuella 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 för lagringssystem från olika leverantörer, så kontrollera systemets krav när du ställer in ett lagringsmål.

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

Om du vill veta mer om de 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 valfri Linux-klient som har NFS-infrastruktur installerad. Om du använder en klient i klustrets undernät kan det också 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 frågan tillåter obegränsad rpcinfo trafik från Azure HPC Cache undernätet.

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

Kontrollera rotåtkomst

Azure HPC Cache behöver åtkomst till lagringssystemets exporter för att skapa lagringsmålet. Mer specifikt monterar den exporterna som användar-ID 0.

Olika lagringssystem använder olika metoder för att aktivera den här åtkomsten:

• Linux-servrar lägger vanligtvis no_root_squash till den exporterade sökvägen i /etc/exports .
• NetApp- och EMC-system styr vanligtvis åtkomst med exportregler som är knutna till specifika IP-adresser eller nätverk.

Kom ihåg att cacheminnet kan använda flera olika IP-adresser från cacheundernätet om du använder exportregler. Tillåt åtkomst från alla möjliga IP-adresser för undernätet.

Arbeta med din NAS-lagringsleverantör för att aktivera rätt åtkomstnivå för cachen.

Tillåt rotåtkomst på katalogsökvägar

För NAS-system som exporterar hierarkiska kataloger Azure HPC Cache rotåtkomst till varje exportnivå.

Ett system kan till exempel visa tre exporter som dessa:

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

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

Om du lägger payroll till exporten som HPC Cache lagringsmål monterar cacheminnet faktiskt och kommer åt /ifs/ lönekatalogen därifrån. Därför Azure HPC Cache rotåtkomst till /ifs för att få åtkomst till /ifs/accounting/payroll exporten.

Detta krav är relaterat till hur cachelagring indexerar filer och undviker filkollisioner med hjälp av filreferenser som lagringssystemet tillhandahåller.

Ett NAS-system med hierarkiska exporter kan ge olika filreferenser 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 /ifs/accounting/payroll monterar och kommer åt filen 2011.txt . Beroende på hur lagringssystemet tilldelar filreferenser kan dessa två klienter ta emot samma fil med olika filreferenser (en för <mount2>/payroll/2011.txt och en för <mount3>/2011.txt ).

Backend-lagringssystemet behåller interna alias för filreferenser, Azure HPC Cache kan inte se vilka filreferenser i indexreferensen som är samma objekt. Det är möjligt att cacheminnet kan ha olika skrivningar cachelagrade för samma fil och tillämpa ändringarna felaktigt eftersom den 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 minsta tillgängliga exporten i sökvägen ( i exemplet) och använder filhandtaget från /ifs exporten. Om flera exporter använder samma bassökväg Azure HPC Cache rotåtkomst till den sökvägen.

Justera storleksbegränsningar för VPN-paket

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

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

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

• Om DITT VPN tillåter pingkommandon kan du testa att skicka ett paket i full storlek.

  Kör ett ping-kommando via VPN till NAS med dessa alternativ. (Använd lagringssystemets IP-adress i stället för <storage_IP> värdet.)

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

  Det här är alternativen i kommandot:

  • -M do – Fragmentera inte
  • -c 1 – Skicka endast ett paket
  • -s 1472 – Ange storleken på nyttolasten till 1472 byte. Det här är den maximala nyttolasten för ett paket på 1 500 byte efter att ethernet-overhead har redovisas.

  Ett lyckat svar 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 pinget misslyckas med 1472 byte finns det förmodligen ett paketstorleksproblem.

För att åtgärda problemet kan du behöva konfigurera MSS-ihopslagning på VPN så att fjärrsystemet korrekt identifierar den maximala ramstorleken. Läs dokumentationen VPN Gateway IPsec/IKE-parametrar om du vill veta mer.

I vissa fall kan det hjälpa att ändra MTU-inställningen för Azure HPC Cache till 1400. Men om du begränsar MTU på cacheminnet måste du även begränsa MTU-inställningarna för klienter och backend-lagringssystem som interagerar med cachen. Läs Konfigurera ytterligare Azure HPC Cache inställningar för mer information.

Sök efter ACL-säkerhetsstil

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

Om systemet rapporterar sitt säkerhetsformat som UNIX eller POSIX utan att inkludera förkortningen "ACL", påverkar det här problemet inte dig.

För system som använder ACL Azure HPC Cache måste du spåra ytterligare användarspecifika värden för att kontrollera filåtkomsten. Det gör du 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 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 kan du kontakta supporten för att få experthjälp.