Problemen met NAS-configuratie en NFS-opslagdoel oplossen

Dit artikel bevat oplossingen voor een aantal veelvoorkomende configuratiefouten en andere problemen waardoor Azure HPC Cache NFS-opslagsysteem niet kan toevoegen als opslagdoel.

Dit artikel bevat informatie over het controleren van poorten en het inschakelen van hoofdtoegang tot een NAS-systeem. Het bevat ook gedetailleerde informatie over minder veelvoorkomende problemen die ertoe kunnen leiden dat het maken van een NFS-opslagdoel mislukt.

Tip

Lees voordat u deze handleiding gebruikt de vereisten voor NFS-opslagdoelen.

Als de oplossing voor uw probleem hier niet is opgenomen, opent u een ondersteuningsticket zodat De service en ondersteuning van Microsoft met u kunnen samenwerken om het probleem te onderzoeken en op te lossen.

Poortinstellingen controleren

Azure HPC Cache heeft lees-/schrijftoegang nodig tot verschillende UDP-/TCP-poorten op het back-end NAS-opslagsysteem. Zorg ervoor dat deze poorten toegankelijk zijn op het NAS-systeem en dat verkeer naar deze poorten is toegestaan via firewalls tussen het opslagsysteem en het cachesubnet. Mogelijk moet u samenwerken met firewall- en netwerkbeheerders voor uw datacenter om deze configuratie te verifiëren.

De poorten verschillen voor opslagsystemen van verschillende leveranciers, dus controleer de vereisten van uw systeem bij het instellen van een opslagdoel.

Over het algemeen moet de cache toegang hebben tot deze poorten:

Protocol Poort Service
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 is bevestigd
TCP/UDP 4047 status

Gebruik de volgende opdracht voor meer informatie over de specifieke poorten die nodig zijn voor uw rpcinfo systeem. Met deze onderstaande opdracht worden de poorten weergegeven en worden de relevante resultaten in een tabel opgemaakt. (Gebruik het IP-adres van uw systeem in plaats van de <storage_IP> term.)

U kunt deze opdracht uitvoeren vanaf elke Linux-client met een NFS-infrastructuur geïnstalleerd. Als u een client in het clustersubnet gebruikt, kan dit ook helpen om de connectiviteit tussen het subnet en het opslagsysteem te controleren.

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

Zorg ervoor dat alle poorten die door de query worden geretourneerd onbeperkt verkeer van het rpcinfo Azure HPC Cache subnet van de query toestaan.

Controleer deze instellingen zowel op de NAS zelf als op eventuele firewalls tussen het opslagsysteem en het cachesubnet.

Toegang tot hoofdmap controleren

Azure HPC Cache moet toegang hebben tot de exports van uw opslagsysteem om het opslagdoel te maken. In het bijzonder worden de exports als gebruikers-id 0 aan de exporten bevestigd.

Verschillende opslagsystemen gebruiken verschillende methoden om deze toegang mogelijk te maken:

  • Linux-servers voegen no_root_squash over het algemeen toe aan het geëxporteerde pad in /etc/exports .
  • NetApp- en EMC-systemen bepalen doorgaans de toegang met exportregels die zijn gekoppeld aan specifieke IP-adressen of netwerken.

Als u exportregels gebruikt, moet u onthouden dat de cache meerdere verschillende IP-adressen uit het cachesubnet kan gebruiken. Sta toegang toe vanaf het volledige bereik van mogelijke IP-adressen van het subnet.

Notitie

Hoewel de cache hoofdtoegang tot het back-endopslagsysteem nodig heeft, kunt u de toegang beperken voor clients die verbinding maken via de cache. Lees Clienttoegang controleren voor meer informatie.

Werk samen met de leverancier van uw NAS-opslag om het juiste toegangsniveau voor de cache in te stellen.

Roottoegang op mappaden toestaan

Voor NAS-systemen die hiërarchische Azure HPC Cache, moeten ze toegang hebben tot elk exportniveau.

Een systeem kan bijvoorbeeld drie exports als deze tonen:

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

De export /ifs/accounting/payroll is een onderliggende /ifs/accounting van en is zelf een /ifs/accounting onderliggende van /ifs .

Als u de export toevoegt als HPC Cache opslagdoel, wordt de cache van hieruit daadwerkelijk aan de payroll /ifs/ salarislijst bevestigd en gebruikt. Daarom Azure HPC Cache toegang tot de /ifs hoofdmap nodig om toegang te krijgen tot de /ifs/accounting/payroll export.

Deze vereiste heeft betrekking op de manier waarop de cache bestanden indexeert en bestandsindrijvingen voorkomt met behulp van bestandsing handles die het opslagsysteem biedt.

Een NAS-systeem met hiërarchische exports kan verschillende bestandsing handles voor hetzelfde bestand geven als het bestand wordt opgehaald uit verschillende exports. Een client kan bijvoorbeeld het bestand /ifs/accounting aan het bestand toevoegen en payroll/2011.txt openen. Een andere client wordt aan het bestand toegevoegd /ifs/accounting/payroll en heeft toegang tot het bestand 2011.txt . Afhankelijk van hoe het opslagsysteem bestandsgrepen toewijst, ontvangen deze twee clients mogelijk hetzelfde bestand met verschillende bestandsing handles (één voor <mount2>/payroll/2011.txt en één voor <mount3>/2011.txt ).

Het back-endopslagsysteem bewaart interne aliassen voor bestandsing handles, maar Azure HPC Cache kan niet zien welke bestandsing handles in de index verwijzen naar hetzelfde item. Het is dus mogelijk dat de cache voor hetzelfde bestand verschillende schrijfingen in de cache kan hebben en de wijzigingen onjuist kan toepassen omdat het niet weet dat ze hetzelfde bestand zijn.

Om deze mogelijke bestandsbotsing voor bestanden in meerdere exports te voorkomen, wordt door Azure HPC Cache automatisch de kleinste beschikbare export in het pad (in het voorbeeld) bevestigd en wordt de bestandsing greep gebruikt die uit die export is /ifs opgegeven. Als meerdere exports hetzelfde basispad gebruiken, moet Azure HPC Cache hoofdtoegang tot dat pad hebben.

Beperkingen voor VPN-pakketgrootte aanpassen

Als u een VPN tussen de cache en uw NAS-apparaat hebt, kan het VPN ethernetpakketten van volledige grootte van 1500 byte blokkeren. Dit probleem kan zich voor doen als grote uitwisselingen tussen de NAS en het Azure HPC Cache niet zijn voltooid, maar kleinere updates werken zoals verwacht.

Er is geen eenvoudige manier om te bepalen of uw systeem dit probleem heeft, tenzij u de details van uw VPN-configuratie kent. Hier zijn enkele methoden die u kunnen helpen bij het controleren op dit probleem.

  • Gebruik pakket-sniffers aan beide zijden van de VPN om te detecteren welke pakketten met succes worden overdragen.

  • Als uw VPN ping-opdrachten toestaat, kunt u het verzenden van een pakket op volledige grootte testen.

    Voer met deze opties een ping-opdracht uit via de VPN naar de NAS. (Gebruik het IP-adres van uw opslagsysteem in plaats van de <storage_IP> waarde.)

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

    Dit zijn de opties in de opdracht :

    • -M do - Geen fragment
    • -c 1 - Slechts één pakket verzenden
    • -s 1472 - Stel de grootte van de nettolading in op 1472 bytes. Dit is de maximale grootte nettolading voor een pakket van 1500 byte na de verwerking van de Ethernet-overhead.

    Een geslaagd antwoord ziet er zo uit:

    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
    

    Als de ping mislukt met 1472 bytes, is er waarschijnlijk een probleem met de pakketgrootte.

U kunt het probleem oplossen door MSS vast te maken op de VPN om ervoor te zorgen dat het externe systeem de maximale framegrootte correct detecteert. Lees de VPN Gateway IPsec-/IKE-parameters voor meer informatie.

In sommige gevallen kan het wijzigen van de MTU-instelling Azure HPC Cache 1400 helpen. Als u echter de MTU op de cache beperkt, moet u ook de MTU-instellingen beperken voor clients en back-endopslagsystemen die met de cache communiceren. Lees Aanvullende instellingen Azure HPC Cache configureren voor meer informatie.

Controleren op ACL-beveiligingsstijl

Sommige NAS-systemen gebruiken een hybride beveiligingsstijl waarin toegangsbeheerlijsten (ACL's) worden gecombineerd met traditionele POSIX- of UNIX beveiliging.

Als uw systeem de beveiligingsstijl rapporteert als UNIX of POSIX zonder het acroniem 'ACL' op te geven, heeft dit probleem geen invloed op u.

Voor systemen die ACL's gebruiken, Azure HPC Cache aanvullende gebruikersspecifieke waarden bijhouden om de toegang tot bestanden te kunnen controleren. Dit wordt gedaan door een toegangscache in te stellen. Er is geen gebruikersbesturingselement om de toegangscache in te stellen, maar u kunt wel een ondersteuningsticket openen om aan te vragen dat het is ingeschakeld voor de betreffende opslagdoelen op uw cachesysteem.

Volgende stappen

Als u een probleem hebt dat niet in dit artikel is opgelost, neem dan contact op met de ondersteuning voor hulp van experts.