Risolvere i problemi di configurazione NAS e target di archiviazione NFS

Questo articolo offre soluzioni per alcuni errori di configurazione comuni e altri problemi che potrebbero impedire a Cache HPC di Azure 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.

Tip

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 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 una cache HPC di medie o grandi dimensioni.

È 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

Cache HPC di Azure 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	Porto	Servizio
TCP/UDP	111	rpcbind
TCP/UDP	2049	NFS (Network File System)
TCP/UDP	4045	nlockmgr
TCP/UDP	4046	montaggio
TCP/UDP	4047	status

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>.

È 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 della cache HPC di Azure.

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 root squash

Le impostazioni di Root squash possono interrompere l'accesso ai file se sono configurate erroneamente. È necessario verificare che le impostazioni su ogni esportazione di archiviazione e sui criteri di accesso dei client della cache HPC corrispondenti siano appropriati.

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

Tip

Le versioni precedenti di Azure HPC Cache richiedevano che i sistemi di archiviazione NAS consentissero l'accesso root dalla cache HPC. Ora, non è necessario consentire l'accesso root a un'esportazione di destinazione dello storage, a meno che non si desideri che i client HPC Cache abbiano accesso root all'esportazione.

Lo root squash può essere configurato in un sistema di cache HPC nei seguenti punti:

• Nel Cache HPC di Azure, usare i criteri di accesso client per configurare il root squash per i client che corrispondono a regole di filtro particolari. Un criterio di accesso del client fa parte di ogni percorso nello spazio dei nomi del target di archiviazione NFS.

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

• Durante l'esportazione del sistema di archiviazione: è possibile configurare il sistema di archiviazione per riassegnare le richieste in ingresso da root a un ID utente non privilegiato.

Se il sistema di archiviazione impedisce privilegi di root, dovresti aggiornare la regola di accesso client della cache HPC per quel target di archiviazione per impedire anche i privilegi di root. In caso contrario, è possibile avere problemi di accesso quando si tenta di leggere o scrivere nel sistema di archiviazione back-end tramite la cache HPC.

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

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

UID 65534 è un esempio. Quando si attiva il root squash in una politica di accesso dei client, è possibile personalizzare l'UID.

Controllare l'accesso nei percorsi della directory

Per i sistemi NAS che esportano directory gerarchiche, verificare che Cache HPC di Azure 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 monta effettivamente /ifs/ e accede alla directory delle retribuzioni da lì. Cache HPC di Azure 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 Cache HPC di Azure non è in grado di 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 un possibile conflitto per i file nelle esportazioni multiple, Azure HPC Cache monta automaticamente l'esportazione più superficiale disponibile nel percorso (/ifs nell'esempio) e utilizza l'handle di file fornito da tale esportazione. Se più esportazioni usano lo stesso percorso di base, Cache HPC di Azure 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 Cache HPC di Azure 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 tua VPN consente comandi ping, puoi 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>.

  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 del gateway VPN .

In alcuni casi, la modifica dell'impostazione MTU per cache HPC di Azure 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 Cache HPC di Azure .

Controllare le impostazioni 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, Cache HPC di Azure 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.