Problemen met NAS-configuratie en NFS-opslagdoel oplossen

  • Artikel

Dit artikel bevat oplossingen voor enkele veelvoorkomende configuratiefouten en andere problemen die kunnen voorkomen dat Azure HPC Cache een NFS-opslagsysteem als opslagdoel toevoegt.

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

Fooi

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

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

Voldoende verbindingsthreads bieden

Grote HPC Cache-systemen maken meerdere verbindingsaanvragen naar een opslagdoel. Als uw opslagdoel bijvoorbeeld gebruikmaakt van de Ubuntu Linux-module nfs-kernel-server , kan het standaardaantal NFS-daemon-threads zo laag zijn als acht. Verhoog het aantal threads tot 128 of 256, wat redelijker is om een middelgrote of grote HPC-cache te ondersteunen.

U kunt het aantal threads in Ubuntu controleren of instellen met behulp van de RPCNFSDCOUNT-waarde in /etc/init.d/nfs-kernel-server.

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 ook dat verkeer is toegestaan voor deze poorten 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 heeft de cache toegang nodig tot deze poorten:

Protocol Port Onderhoud
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 koppeld
TCP/UDP 4047 status

Gebruik de volgende rpcinfo opdracht voor meer informatie over de specifieke poorten die nodig zijn voor uw systeem. Met deze opdracht hieronder worden de poorten vermeld 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 waarop de NFS-infrastructuur is geïnstalleerd. Als u een client in het clustersubnet gebruikt, kan dit ook helpen bij het controleren van de connectiviteit tussen het subnet en het opslagsysteem.

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 rpcinfo query worden geretourneerd onbeperkt verkeer van het subnet van de Azure HPC Cache toestaan.

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

Root squashinstellingen controleren

Root squash-instellingen kunnen de toegang tot bestanden verstoren als ze onjuist zijn geconfigureerd. Controleer of de instellingen voor elke opslagexport en het overeenkomende HPC Cache-toegangsbeleid voor clients geschikt zijn.

Root squash voorkomt dat aanvragen die worden verzonden door een lokale superuser root op de client worden verzonden naar een back-endopslagsysteem als hoofdmap. Aanvragen van de hoofdmap worden opnieuw toegewezen aan een niet-bevoegde gebruikers-id (UID) zoals 'niemand'.

Fooi

In eerdere versies van Azure HPC Cache zijn NAS-opslagsystemen vereist om roottoegang vanuit de HPC Cache toe te staan. Nu hoeft u geen hoofdtoegang toe te staan voor een opslagdoelexport, tenzij u wilt dat HPC Cache-clients hoofdtoegang hebben tot de export.

Root squash kan op deze plaatsen worden geconfigureerd in een HPC Cache-systeem:

  • Op de Azure HPC Cache : gebruik clienttoegangsbeleid om root-squash te configureren voor clients die voldoen aan specifieke filterregels. Een clienttoegangsbeleid maakt deel uit van elk NFS-doelnaamruimtepad.

    Het standaardbeleid voor clienttoegang verplettert de hoofdmap niet.

  • Bij de opslagexport: u kunt uw opslagsysteem zo configureren dat binnenkomende aanvragen opnieuw worden toegewezen vanuit de hoofdmap naar een niet-bevoegde gebruikers-id (UID).

Als uw opslagsysteem de hoofdmap exporteert, moet u de HPC Cache-clienttoegangsregel voor dat opslagdoel bijwerken om ook de root te onderdrukken. Als dat niet het probleem is, kunt u problemen ondervinden bij het lezen of schrijven naar het back-endopslagsysteem via de HPC-cache.

In deze tabel ziet u het gedrag voor verschillende root-squashscenario's wanneer een clientaanvraag wordt verzonden als UID 0 (root). Het scenario dat is gemarkeerd met * wordt niet aanbevolen omdat dit toegangsproblemen kan veroorzaken.

Instelling UID verzonden vanaf client UID verzonden vanuit HPC Cache Effectieve UID voor back-endopslag
geen wortel squash 0 (hoofdmap) 0 (hoofdmap) 0 (hoofdmap)
root squash alleen bij HPC Cache 0 (hoofdmap) 65534 (niemand) 65534 (niemand)
*root squash bij NAS-opslag alleen 0 (hoofdmap) 0 (hoofdmap) 65534 (niemand)
root squash bij HPC Cache en NAS 0 (hoofdmap) 65534 (niemand) 65534 (niemand)

(UID 65534 is een voorbeeld; wanneer u root squash inschakelt in een clienttoegangsbeleid, kunt u de UID aanpassen.)

Toegang controleren op adreslijstpaden

Voor NAS-systemen die hiërarchische mappen exporteren, controleert u of Azure HPC Cache de juiste toegang heeft tot elk exportniveau in het pad naar de bestanden die u gebruikt.

Een systeem kan bijvoorbeeld drie exports als volgt weergeven:

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

De export /ifs/accounting/payroll is een onderliggend element van /ifs/accounting, en /ifs/accounting is zelf een onderliggend element van /ifs.

Als u de payroll export toevoegt als een HPC Cache-opslagdoel, koppelt /ifs/ de cache daadwerkelijk de salarislijst van daaruit. Azure HPC Cache heeft dus voldoende toegang /ifs nodig om toegang te krijgen tot de /ifs/accounting/payroll export.

Deze vereiste is gerelateerd aan de manier waarop de cache bestanden indexeert en bestandsconflicten voorkomt, met behulp van bestandsafhandelingen die het opslagsysteem biedt.

Een NAS-systeem met hiërarchische exports kan verschillende bestandsingangen voor hetzelfde bestand geven als het bestand wordt opgehaald uit verschillende exports. Een client kan bijvoorbeeld het bestand payroll/2011.txtkoppelen /ifs/accounting en openen. Een andere client koppelt /ifs/accounting/payroll en opent het bestand 2011.txt. Afhankelijk van hoe het opslagsysteem bestandsingangen toewijst, ontvangen deze twee clients mogelijk hetzelfde bestand met verschillende bestandsingangen (één voor <mount2>/payroll/2011.txt en één voor <mount3>/2011.txt).

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

Om deze mogelijke bestandsconflicten voor bestanden in meerdere exports te voorkomen, koppelt Azure HPC Cache automatisch de ondiepste beschikbare export in het pad (/ifs in het voorbeeld) en gebruikt de bestandsgreep die is opgegeven uit die export. Als meerdere exports hetzelfde basispad gebruiken, heeft Azure HPC Cache toegang tot dat pad nodig.

Beperkingen voor VPN-pakketgrootte aanpassen

Als u een VPN hebt tussen de cache en uw NAS-apparaat, kan het VPN 1500-byte Ethernet-pakketten blokkeren. Mogelijk hebt u dit probleem als grote uitwisselingen tussen de NAS en het Azure HPC Cache-exemplaar niet worden voltooid, maar kleinere updates werken zoals verwacht.

Er is geen eenvoudige manier om te zien of uw systeem dit probleem ondervindt, tenzij u de details van uw VPN-configuratie kent. Hier volgen enkele methoden waarmee u kunt controleren op dit probleem.

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

  • Als uw VPN pingopdrachten toestaat, kunt u testen of u een pakket met volledige grootte verzendt.

    Voer een ping-opdracht uit via de VPN naar de NAS met deze opties. (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 - Fragment niet fragment
    • -c 1 - Slechts één pakket verzenden
    • -s 1472 - Stel de grootte van de nettolading in op 1472 bytes. Dit is de maximale nettolading voor een pakket van 1500 byte na het maken van de Ethernet-overhead.

    Een geslaagde respons ziet er als volgt 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.

Om het probleem op te lossen, moet u mogelijk MSS-klem op de VPN configureren om het externe systeem de maximale framegrootte te laten detecteren. Lees de documentatie voor IPsec-/IKE-parameters voor VPN Gateway voor meer informatie.

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

Controleren op ACL-beveiligingsstijl

Sommige NAS-systemen gebruiken een hybride beveiligingsstijl die toegangsbeheerlijsten (ACL's) combineert 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, moet Azure HPC Cache aanvullende gebruikersspecifieke waarden bijhouden om de toegang tot bestanden te beheren. Dit wordt gedaan door een toegangscache in te schakelen. Er is geen gebruikersgericht besturingselement om de toegangscache in te schakelen, maar u kunt een ondersteuningsticket openen om aan te vragen dat het is ingeschakeld voor de betrokken opslagdoelen op uw cachesysteem.

Volgende stappen

Als u een probleem hebt dat niet is opgelost in dit artikel, neemt u contact op met de ondersteuning om deskundige hulp te krijgen.