Procedure consigliate per la concorrenza Linux per Azure NetApp Files - Slot di sessione e voci di tabella slot

Questo articolo illustra le procedure consigliate per la concorrenza per gli slot di sessione e le voci della tabella slot del protocollo NFS di Azure NetApp Files.

NFSv3

NFSv3 non dispone di un meccanismo per negoziare la concorrenza tra il client e il server. Il client e il server definiscono il relativo limite senza consultare l'altro. Per ottenere prestazioni ottimali, è consigliabile allineare il numero massimo di voci della tabella slot lato sunrpc client con quella supportata senza eseguire il pushback nel server. Quando un client sovraccarica la capacità dello stack di rete del server di elaborare un carico di lavoro, il server risponde riducendo le dimensioni della finestra per la connessione, che non è uno scenario di prestazioni ideale.

Per impostazione predefinita, i kernel Linux moderni definiscono le dimensioni sunrpc.tcp_max_slot_table_entries della voce della tabella slot per connessione sunrpc come supporto di 65.536 operazioni in sospeso, come illustrato nella tabella seguente.

Queste voci della tabella degli slot definiscono i limiti di concorrenza. I valori elevati non sono necessari. Ad esempio, usando una teoria di accodamento nota come Littles Law, si scoprirà che la velocità di I/O è determinata dalla concorrenza (ovvero i/O in sospeso) e dalla latenza. Di conseguenza, l'algoritmo dimostra che 65.536 slot sono ordini di grandezza superiori a quelli necessari per guidare anche carichi di lavoro estremamente impegnativi.

Littles Law: (concurrency = operation rate × latency in seconds)

Un livello di concorrenza inferiore a 155 è sufficiente per ottenere 155.000 operazioni NFS Oracle DB al secondo usando Oracle Direct NFS, che è una tecnologia simile al concetto dell'opzione nconnect di montaggio:

• Considerando una latenza di 0,5 ms, è necessaria una concorrenza di 55 per ottenere 110.000 operazioni di I/O al secondo.
• Considerando una latenza di 1 ms, è necessaria una concorrenza di 155 per ottenere 155.000 operazioni di I/O al secondo.

Per informazioni dettagliate, vedere Prestazioni del database Oracle in volumi singoli di Azure NetApp Files.

L'oggetto sunrpc.tcp_max_slot_table_entries ottimizzabile è un parametro di ottimizzazione a livello di connessione. Come procedura consigliata, impostare questo valore su 128 o meno per connessione, senza superare 10.000 slot a livello di ambiente.

Esempi di conteggio degli slot in base alla raccomandazione di concorrenza

Gli esempi in questa sezione illustrano il numero di slot in base alla raccomandazione di concorrenza.

Esempio 1: un client NFS, 65.536 sunrpc.tcp_max_slot_table_entriese nessuna nconnect per una concorrenza massima di 128 in base al limite lato server di 128

L'esempio 1 si basa su un singolo carico di lavoro client con il valore predefinito sunrpc.tcp_max_slot_table_entry 65.536 e una singola connessione di rete, ovvero senza nconnect. In questo caso, è possibile ottenere una concorrenza pari a 128.

• NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
  • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
    • Il client in teoria non può inviare più di 65.536 richieste in anteprima al server per ogni connessione.
    • Il server accetterà non più di 128 richieste in anteprima da questa singola connessione.

Esempio 2: un client NFS, 128 sunrpc.tcp_max_slot_table_entriese nessuna nconnect per una concorrenza massima di 128

L'esempio 2 si basa su un singolo carico di lavoro client con un sunrpc.tcp_max_slot_table_entry valore pari a 128, ma senza l'opzione nconnect di montaggio. Con questa impostazione, una concorrenza di 128 è ottenibile da una singola connessione di rete.

• NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
  • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
    • Il client non emetterà più di 128 richieste in anteprima al server per ogni connessione.
    • Il server accetterà non più di 128 richieste in anteprima da questa singola connessione.

Esempio 3: un client NFS, 100 sunrpc.tcp_max_slot_table_entriese nconnect=8 per una concorrenza massima di 800

L'esempio 3 si basa su un singolo carico di lavoro client, ma con un valore inferiore sunrpc.tcp_max_slot_table_entry di 100. Questa volta, l'opzione nconnect=8 di montaggio usata per distribuire il carico di lavoro tra 8 connessioni. Con questa impostazione, una concorrenza di 800 è ottenibile tra le 8 connessioni. Questa quantità è la concorrenza necessaria per ottenere 400.000 operazioni di I/O al secondo.

• NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
  • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP), Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)… Connection 8 (10.10.10.10:2049, 10.10.10.11:7321,TCP)
  • Connessione ion 1
    • Il client non emetterà più di 100 richieste in anteprima al server da questa connessione.
    • Il server deve accettare non più di 128 richieste in anteprima dal client per questa connessione.
  • Connessione ion 2
    • Il client non emetterà più di 100 richieste in anteprima al server da questa connessione.
    • Il server deve accettare non più di 128 richieste in anteprima dal client per questa connessione.
  • …
  • …
  • Connessione ion 8
    • Il client non emetterà più di 100 richieste in anteprima al server da questa connessione.
    • Il server deve accettare non più di 128 richieste in anteprima dal client per questa connessione.

Esempio 4 - 250 client NFS, 8 sunrpc.tcp_max_slot_table_entriese no nconnect per una concorrenza massima di 2000

Nell'esempio 4 viene usato il valore ridotto per client sunrpc.tcp_max_slot_table_entry pari a 8 per un ambiente EDA con conteggio di 250 computer. In questo scenario viene raggiunta una concorrenza di 2000 a livello di ambiente, un valore più che sufficiente per guidare 4.000 MiB/s di un carico di lavoro EDA back-end.

• NFS_Server=10.10.10.10, NFS_Client1=10.10.10.11
  • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
    • Il client non emetterà più di 8 richieste in anteprima al server per ogni connessione.
    • Il server accetterà non più di 128 richieste in anteprima da questa singola connessione.
• NFS_Server=10.10.10.10, NFS_Client2=10.10.10.12
  • Connection (10.10.10.10:2049, 10.10.10.12:7820,TCP)
    • Il client non emetterà più di 8 richieste in anteprima al server per ogni connessione.
    • Il server accetterà non più di 128 richieste in anteprima da questa singola connessione.
• …
• …
• NFS_Server=10.10.10.10, NFS_Client250=10.10.11.13
  • Connection (10.10.10.10:2049, 10.10.11.13:4320,TCP)
    • Il client non emetterà più di 8 richieste in anteprima al server per ogni connessione.
    • Il server accetterà non più di 128 richieste in anteprima da questa singola connessione.

Quando si usa NFSv3, è consigliabile mantenere collettivamente il numero di slot degli endpoint di archiviazione su 10.000 o meno. È consigliabile impostare il valore per ogni connessione per sunrpc.tcp_max_slot_table_entries su meno di 128 quando un'applicazione viene ridimensionata in più connessioni di rete (nconnect e HPC in generale e EDA in particolare).

Come calcolare il meglio sunrpc.tcp_max_slot_table_entries

Usando Littles Law, è possibile calcolare il numero totale di voci della tabella slot necessarie. In generale, considerare i fattori seguenti:

• I carichi di lavoro con scalabilità orizzontale sono spesso di natura sequenziale dominante.
• I carichi di lavoro del database, in particolare OLTP, sono spesso di natura casuale.

La tabella seguente illustra uno studio di esempio della concorrenza con latenze arbitrarie fornite:

Come calcolare le impostazioni di concorrenza in base al numero di connessioni

Ad esempio, se il carico di lavoro è una farm EDA e 1.250 client tutte unità del carico di lavoro nello stesso endpoint di archiviazione (un endpoint di archiviazione è un indirizzo IP di archiviazione), si calcola la velocità di I/O necessaria e si divide la concorrenza nella farm.

Si supponga che il carico di lavoro sia 4.000 MiB/s usando una dimensione media dell'operazione di 256 KiB e una latenza media di 10 ms. Per calcolare la concorrenza, usare la formula seguente:

(concurrency = operation rate × latency in seconds)

Il calcolo si traduce in una concorrenza di 160:

(160 = 16,000 × 0.010)

Data la necessità di 1.250 client, è possibile impostare sunrpc.tcp_max_slot_table_entries su 2 per client per raggiungere i 4.000 MiB/s. Tuttavia, si potrebbe decidere di costruire in più headroom impostando il numero per client su 4 o anche 8, mantenendo ben sotto il limite di 10.000 slot consigliato.

Come impostare sunrpc.tcp_max_slot_table_entries sul client

1. Aggiungere sunrpc.tcp_max_slot_table_entries=<n> al /etc/sysctl.conf file di configurazione.
   Durante l'ottimizzazione, se viene trovato un valore inferiore a 128, sostituire 128 con il numero appropriato.
2. Esegui questo comando:
   $ sysctl -p
3. Montaggio (o rimontaggio) di tutti i file system NFS, in quanto il file system NFS si applica solo ai montaggi effettuati dopo che è stato impostato il tonno.

NFSv4.1

In NFSv4.1 le sessioni definiscono la relazione tra il client e il server. Se i file system NFS montati si trovano in cima a una connessione o molti (come nel caso con nconnect), si applicano le regole per la sessione. Durante l'installazione della sessione, il client e il server negoziano le richieste massime per la sessione, stabilendo la parte inferiore dei due valori supportati. Azure NetApp Files supporta 180 richieste in sospeso e i client Linux per impostazione predefinita sono 64. La tabella seguente illustra i limiti della sessione:

Anche se i client Linux per impostazione predefinita sono 64 richieste massime per sessione, il valore di max_session_slots è ottimizzabile. Per rendere effettive le modifiche è necessario un riavvio. Usare il systool -v -m nfs comando per visualizzare il valore massimo corrente in uso dal client. Affinché il comando funzioni, è necessario che sia presente almeno un montaggio NFSv4.1:

$ systool -v -m nfs
{
Module = "nfs"
...
  Parameters:
...
    max_session_slots   = "64"
...
}

Per ottimizzare max_session_slots, creare un file di configurazione in /etc/modprobe.d come tale. Assicurarsi che non siano presenti "virgolette" per la riga nel file. In caso contrario, l'opzione non avrà effetto.

$ sudo echo “options nfs max_session_slots=180” > /etc/modprobe.d/nfsclient.conf $ sudo reboot

Azure NetApp Files limita ogni sessione a 180 comandi massimi. Di conseguenza, considerare 180 il valore massimo attualmente configurabile. Il client non sarà in grado di ottenere una concorrenza maggiore di 128, a meno che la sessione non sia divisa in più di una connessione perché Azure NetApp Files limita ogni connessione a 128 comandi NFS massimi. Per ottenere più connessioni, è consigliabile usare l'opzione nconnect di montaggio e un valore di due o superiore è obbligatorio.

Esempi di valori massimi di concorrenza previsti

Gli esempi in questa sezione illustrano i massimi di concorrenza previsti.

Esempio 1 - 64 max_session_slots e no nconnect

L'esempio 1 si basa sull'impostazione predefinita 64 max_session_slots e nessuna nconnect. Con questa impostazione, è possibile ottenere una concorrenza pari a 64, da una singola connessione di rete.

• NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
  • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
    • Il client non emetterà più di 64 richieste in anteprima al server per la sessione.
    • Il server accetterà non più di 64 richieste in anteprima dal client per la sessione. (64 è il valore negoziato.

Esempio 2 - 64 max_session_slots e nconnect=2

L'esempio 2 è basato su 64 max session_slots , ma con l'opzione di montaggio aggiunta di nconnect=2. Una concorrenza di 64 è ottenibile, ma divisa tra due connessioni. Anche se più connessioni non comportano una concorrenza maggiore in questo scenario, la riduzione della profondità della coda per ogni connessione ha un impatto positivo sulla latenza.

Con il max_session_slots valore ancora a 64 ma nconnect=2, si noti che il numero massimo di richieste viene diviso tra le connessioni.

• NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
  • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
  • Connessione ion 1
    • Il client non emetterà più di 32 richieste in anteprima al server da questa connessione.
    • Il server deve accettare non più di 32 richieste in anteprima dal client per questa connessione.
  • Connessione ion 2
    • Il client non emetterà più di 32 richieste in anteprima al server da questa connessione.
    • Il server deve accettare non più di 32 richieste in anteprima dal client per questa connessione.

Esempio 3 - 180 max_session_slots e no nconnect

L'esempio 3 elimina l'opzione nconnect di montaggio e imposta il max_session_slots valore su 180, corrispondente alla concorrenza massima della sessione NFSv4.1 del server. In questo scenario, con una sola connessione e data l'operazione massima in sospeso di Azure NetApp Files 128 per ogni connessione NFS, la sessione è limitata a 128 operazioni in anteprima.

Sebbene max_session_slots sia stato impostato su 180, la singola connessione di rete è limitata a 128 richieste massime, ad esempio:

• NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
  • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
    • Il client non emetterà più di 180 richieste in anteprima al server per la sessione.
    • Il server accetterà non più di 180 richieste in anteprima dal client per la sessione.
    • Il server accetterà non più di 128 richieste in anteprima per la singola connessione.

Esempio 4 - 180 max_session_slots e nconnect=2

Nell'esempio 4 viene aggiunta l'opzione nconnect=2 di montaggio e viene riutilizzato il valore 180 max_session_slots . Poiché il carico di lavoro complessivo è diviso tra due connessioni, è possibile ottenere 180 operazioni in sospeso.

Con due connessioni in corso, la sessione supporta l'allocazione completa di 180 richieste in sospeso.

• NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
  • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
  • Connessione ion 1
    • Il client deve gestire non più di 90 richieste in anteprima al server dalla connessione 1.
    • Il server deve gestire non più di 90 richieste in anteprima dal client per questa connessione all'interno della sessione.
  • Connessione ion 2
    • Il client deve gestire non più di 90 richieste in anteprima al server dalla connessione 1.
    • Il server deve gestire non più di 90 richieste in anteprima dal client per questa connessione all'interno della sessione.

Come verificare la presenza delle richieste massime in sospeso per la sessione

Per visualizzare le session_slot dimensioni supportate dal client e dal server, acquisire il comando mount in una traccia di pacchetti. Cercare la CREATE_SESSION chiamata e CREATE_SESSION la risposta come illustrato nell'esempio seguente. La chiamata ha avuto origine dal client e la risposta ha avuto origine dal server.

Usare il comando seguente tcpdump per acquisire il comando mount:

$ tcpdump -i eth0 -s 900 -w /tmp/write.trc port 2049

Usando Wireshark, i pacchetti di interesse sono i seguenti:

All'interno di questi due pacchetti, esaminare il max_reqs campo all'interno della sezione centrale del file di traccia.

• File system di rete
  • Operazioni
    • Opcode
      • csa_fore_channel_attrs
      • max reqs

Il pacchetto 12 (richieste massime client) indica che il client ha un max_session_slots valore pari a 64. Nella sezione successiva si noti che il server supporta una concorrenza di 180 per la sessione. La sessione finisce per negoziare la parte inferiore dei due valori forniti.

L'esempio seguente mostra Packet 14 (numero massimo di richieste del server):

Passaggi successivi

• Procedure consigliate per le operazioni di I/O dirette linux per Azure NetApp Files
• Procedure consigliate per la cache del file system Linux per Azure NetApp Files
• Procedure consigliate per le opzioni di montaggio NFS di Linux per Azure NetApp Files
• Procedure consigliate per Linux NFS read-ahead
• Procedure consigliate per gli SKU delle macchine virtuali di Azure
• Benchmark delle prestazioni per Linux