Risolvere i problemi di configurazione nas e destinazione di archiviazione NFS

  • Articolo

Questo articolo offre soluzioni per alcuni errori di configurazione comuni e altri problemi che potrebbero impedire ad Azure Cache HPC di aggiungere un sistema di archiviazione NFS come destinazione di archiviazione.

Questo articolo include informazioni dettagliate su come controllare le porte e su come abilitare l'accesso necessario a un sistema NAS. Include anche informazioni dettagliate sui problemi meno comuni che potrebbero causare l'esito negativo della creazione della destinazione di archiviazione NFS.

Suggerimento

Prima di usare questa guida, leggere i prerequisiti per le destinazioni di archiviazione NFS.

Se la soluzione al problema non è inclusa qui, aprire un ticket di supporto in modo che il servizio Microsoft e il supporto tecnico possano collaborare per analizzare e risolvere il problema.

Fornire thread di connessione sufficienti

I sistemi di Cache HPC di grandi dimensioni effettuano più richieste di connessione a una destinazione di archiviazione. Ad esempio, se la destinazione di archiviazione usa il modulo Ubuntu Linux nfs-kernel-server , il numero predefinito di thread daemon NFS può essere inferiore a otto. Aumentare il numero di thread a 128 o 256, che sono numeri più ragionevoli per supportare un Cache HPC medio o grande.

È possibile controllare o impostare il numero di thread in Ubuntu usando il valore RPCNFSDCOUNT in /etc/init.d/nfs-kernel-server.

Controllare le impostazioni delle porte

Azure Cache HPC richiede l'accesso in lettura/scrittura a diverse porte UDP/TCP nel sistema di archiviazione NAS back-end. Assicurarsi che queste porte siano accessibili nel sistema NAS e che il traffico sia consentito a queste porte attraverso qualsiasi firewall tra il sistema di archiviazione e la subnet della cache. Per verificare questa configurazione, potrebbe essere necessario collaborare con firewall e amministratori di rete per il data center.

Le porte sono diverse per i sistemi di archiviazione di diversi fornitori, quindi controllare i requisiti del sistema durante la configurazione di una destinazione di archiviazione.

In generale, la cache deve accedere a queste porte:

Protocollo Port Servizioo
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 montaggio
TCP/UDP 4047 stato

Per informazioni sulle porte specifiche necessarie per il sistema, usare il comando seguente rpcinfo . Questo comando seguente elenca le porte e formatta i risultati pertinenti in una tabella. (Usare l'indirizzo IP del sistema al posto di <> storage_IP termine.

È possibile eseguire questo comando da qualsiasi client Linux in cui è installata l'infrastruttura NFS. Se si usa un client all'interno della subnet del cluster, può anche essere utile per verificare la connettività tra la subnet e il sistema di archiviazione.

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

Assicurarsi che tutte le porte restituite dalla rpcinfo query consentano il traffico senza restrizioni dalla subnet di Azure Cache HPC.

Controllare queste impostazioni sia sul NAS stesso che su qualsiasi firewall tra il sistema di archiviazione e la subnet della cache.

Controllare le impostazioni di squash radice

Le impostazioni di squash radice possono interrompere l'accesso ai file se sono configurate in modo non corretto. È consigliabile verificare che le impostazioni di ogni esportazione di archiviazione e nei criteri di accesso client corrispondenti Cache HPC siano appropriate.

Lo squash radice impedisce che le richieste inviate da una radice superutente locale sul client vengano inviate a un sistema di archiviazione back-end come radice. Riassegna le richieste dalla radice a un ID utente (UID) senza privilegi, ad esempio 'nessuno'.

Suggerimento

Le versioni precedenti di Azure Cache HPC sistemi di archiviazione NAS necessari per consentire l'accesso radice dalla Cache HPC. Non è ora necessario consentire l'accesso alla radice in un'esportazione di destinazione di archiviazione, a meno che non si desideri che i client Cache HPC abbiano accesso radice all'esportazione.

Lo squash radice può essere configurato in un sistema di Cache HPC in queste posizioni:

  • In Azure Cache HPC : usare i criteri di accesso client per configurare lo squash radice per i client che corrispondono a regole di filtro specifiche. Un criterio di accesso client fa parte di ogni percorso dello spazio dei nomi di destinazione di archiviazione NFS.

    Il criterio di accesso client predefinito non esegue lo squash root.

  • All'esportazione di archiviazione: è possibile configurare il sistema di archiviazione per riassegnare le richieste in ingresso dalla radice a un ID utente (UID) senza privilegi.

Se l'esportazione del sistema di archiviazione esegue lo squash radice, è necessario aggiornare la regola di accesso client Cache HPC per tale destinazione di archiviazione anche alla radice di squash. In caso contrario, è possibile avere problemi di accesso quando si tenta di leggere o scrivere nel sistema di archiviazione back-end tramite il Cache HPC.

Questa tabella illustra il comportamento per diversi scenari di squash radice quando una richiesta client viene inviata come UID 0 (radice). Lo scenario contrassegnato con * non è consigliato perché può causare problemi di accesso.

Impostazione UID inviato dal client UID inviato da Cache HPC UID efficace nell'archiviazione back-end
nessuna squash radice 0 (radice) 0 (radice) 0 (radice)
root squash solo a Cache HPC 0 (radice) 65534 (nessuno) 65534 (nessuno)
*root squash solo nell'archiviazione NAS 0 (radice) 0 (radice) 65534 (nessuno)
root squash in Cache HPC e NAS 0 (radice) 65534 (nessuno) 65534 (nessuno)

UiD 65534 è un esempio. Quando si attiva lo squash radice in un criterio di accesso client, è possibile personalizzare l'UID.

Controllare l'accesso nei percorsi della directory

Per i sistemi NAS che esportano directory gerarchie, verificare che Azure Cache HPC abbia accesso appropriato a ogni livello di esportazione nel percorso dei file in uso.

Ad esempio, un sistema potrebbe mostrare tre esportazioni simili alle seguenti:

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

L'esportazione /ifs/accounting/payroll è un elemento figlio di /ifs/accountinge /ifs/accounting si tratta di un elemento figlio di /ifs.

Se si aggiunge l'esportazione payroll come destinazione di archiviazione Cache HPC, la cache viene effettivamente montata e accede alla directory delle retribuzioni /ifs/ da questa posizione. Azure Cache HPC quindi necessita di un accesso sufficiente a /ifs per accedere all'esportazione/ifs/accounting/payroll.

Questo requisito è correlato al modo in cui la cache indicizza i file ed evita conflitti di file, usando handle di file forniti dal sistema di archiviazione.

Un sistema NAS con esportazioni gerarchica può fornire handle di file diversi per lo stesso file se il file viene recuperato da esportazioni diverse. Ad esempio, un client può montare /ifs/accounting e accedere al file payroll/2011.txt. Un altro client monta /ifs/accounting/payroll e accede al file 2011.txt. A seconda del modo in cui il sistema di archiviazione assegna gli handle di file, questi due client potrebbero ricevere lo stesso file con handle di file diversi (uno per <mount2>/payroll/2011.txt e uno per <mount3>/2011.txt).

Il sistema di archiviazione back-end mantiene gli alias interni per gli handle di file, ma Azure Cache HPC non può indicare quali handle di file nel relativo indice fanno riferimento allo stesso elemento. È quindi possibile che la cache possa avere scritture diverse memorizzate nella cache per lo stesso file e applicare le modifiche in modo errato perché non sa che sono lo stesso file.

Per evitare questo possibile conflitto di file per i file in più esportazioni, Azure Cache HPC monta automaticamente l'esportazione disponibile più superficiale nel percorso (/ifs nell'esempio) e usa l'handle di file specificato da tale esportazione. Se più esportazioni usano lo stesso percorso di base, Azure Cache HPC deve accedere a tale percorso.

Modificare le restrizioni relative alle dimensioni dei pacchetti VPN

Se si dispone di una VPN tra la cache e il dispositivo NAS, la VPN potrebbe bloccare pacchetti Ethernet di dimensioni intere di 1500 byte. Questo problema potrebbe verificarsi se gli scambi di grandi dimensioni tra il NAS e l'istanza di Azure Cache HPC non vengono completati, ma gli aggiornamenti più piccoli funzionano come previsto.

Non esiste un modo semplice per indicare se il sistema presenta o meno questo problema, a meno che non si conoscano i dettagli della configurazione VPN. Ecco alcuni metodi che consentono di verificare la presenza di questo problema.

  • Usare gli sniffer di pacchetti su entrambi i lati della VPN per rilevare quali pacchetti trasferiscono correttamente.

  • Se la VPN consente comandi ping, è possibile testare l'invio di un pacchetto di dimensioni complete.

    Eseguire un comando ping sulla VPN sul NAS con queste opzioni. (Usare l'indirizzo IP del sistema di archiviazione al posto di <> storage_IP valore.

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

    Queste sono le opzioni nel comando:

    • -M do - Non frammento
    • -c 1 - Inviare un solo pacchetto
    • -s 1472 - Impostare le dimensioni del payload su 1472 byte. Si tratta del payload di dimensioni massime per un pacchetto da 1500 byte dopo aver contabiliato il sovraccarico Ethernet.

    Una risposta positiva è simile a questa:

    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

    Se il ping ha esito negativo con 1472 byte, è probabile che si verifichi un problema di dimensioni del pacchetto.

Per risolvere il problema, potrebbe essere necessario configurare il blocco MSS sulla VPN per fare in modo che il sistema remoto rilevi correttamente le dimensioni massime del frame. Per altre informazioni, vedere la documentazione relativa ai parametri IPsec/IKE Gateway VPN.

In alcuni casi, la modifica dell'impostazione MTU per Azure Cache HPC su 1400 può essere utile. Tuttavia, se si limita la MTU nella cache, è necessario limitare anche le impostazioni MTU per i client e i sistemi di archiviazione back-end che interagiscono con la cache. Per informazioni dettagliate, vedere Configurare altre impostazioni di Azure Cache HPC.

Controllare lo stile di sicurezza ACL

Alcuni sistemi NAS usano uno stile di sicurezza ibrido che combina elenchi di controllo di accesso (ACL) con la sicurezza TRADIZIONALE POSIX o UNIX.

Se il sistema segnala lo stile di sicurezza come UNIX o POSIX senza includere l'acronimo "ACL", questo problema non influisce sull'utente.

Per i sistemi che usano elenchi di controllo di accesso, Azure Cache HPC deve tenere traccia di valori specifici dell'utente aggiuntivi per controllare l'accesso ai file. Questa operazione viene eseguita abilitando una cache di accesso. Non esiste un controllo rivolto all'utente per attivare la cache di accesso, ma è possibile aprire un ticket di supporto per richiedere che sia abilitato per le destinazioni di archiviazione interessate nel sistema di cache.

Passaggi successivi

Se si verifica un problema che non è stato risolto in questo articolo, contattare il supporto tecnico per ottenere assistenza di esperti.