Velocità di archiviazione adatta per etcd? Chiediamo fio

Una breve storia su fio e etcd

Prestazioni del gruppo etcd dipende in gran parte dalle prestazioni della sua memoria. etcd esporta alcune metriche in Prometeoper fornire le informazioni sulle prestazioni di archiviazione desiderate. Ad esempio, la metrica wal_fsync_duration_seconds. La documentazione per etcd dice: affinché l'archiviazione sia considerata sufficientemente veloce, il 99° percentile di questa metrica deve essere inferiore a 10 ms. Se hai intenzione di eseguire un cluster etcd su macchine Linux e vuoi valutare se il tuo spazio di archiviazione è abbastanza veloce (ad es. SSD), puoi utilizzare filo è uno strumento popolare per testare le operazioni di I/O. Eseguire il comando seguente, dove test-data è la directory sotto il punto di montaggio dell'archiviazione:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Devi solo guardare i risultati e verificare che il 99esimo percentile della durata fdatasync meno di 10 ms. In tal caso, hai uno spazio di archiviazione ragionevolmente veloce. Ecco un esempio dei risultati:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Note

• Abbiamo personalizzato le opzioni --size e --bs per il nostro particolare scenario. Per ottenere un risultato utile da fio, fornisci i tuoi valori. Dove trovarli? Leggere come abbiamo imparato a configurare fio.
• Durante i test, tutto il carico di I/O proviene da fio. In uno scenario reale, ci saranno probabilmente altre richieste di scrittura in arrivo nello storage oltre a quelle relative a wal_fsync_duration_seconds. Il carico aggiuntivo aumenterà il valore di wal_fsync_duration_seconds. Quindi, se il 99° percentile è vicino a 10 ms, il tuo spazio di archiviazione sta esaurendo la velocità.
• Prendi la versione filo non inferiore a 3.5 (i precedenti non mostrano percentili di durata fdatasync).
• Sopra è solo un frammento dei risultati di fio.

Lunga storia su fio e etcd

Cos'è WAL in etcd

Di solito i database usano log write-ahead; lo usa anche etcd. Non discuteremo in dettaglio il log write-ahead (WAL) qui. È sufficiente per noi sapere che ogni membro del cluster etcd lo mantiene in una memoria persistente. etcd scrive ogni operazione chiave-valore (come un aggiornamento) in WAL prima di applicarla allo store. Se uno dei membri di archiviazione si arresta in modo anomalo e si riavvia tra gli snapshot, può ripristinare localmente le transazioni dall'ultimo snapshot in base al contenuto WAL.

Quando un client aggiunge una chiave all'archivio valore-chiave o aggiorna il valore di una chiave esistente, etcd registra l'operazione in WAL, che è un normale file nella memoria persistente. etcd DEVE essere completamente sicuro che la voce WAL si sia effettivamente verificata prima di continuare con l'elaborazione. Su Linux, una chiamata di sistema non è sufficiente per questo. scrivere, poiché la scrittura effettiva nell'archiviazione fisica potrebbe essere ritardata. Ad esempio, Linux può archiviare una voce WAL in una cache nella memoria del kernel (come una cache di pagina) per un po' di tempo. E affinché i dati vengano scritti accuratamente nell'archiviazione persistente, è necessaria la chiamata di sistema fdatasync dopo la scrittura e etcd la usa (come puoi vedere nel risultato del lavoro straccio, dove 8 è il descrittore del file WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Sfortunatamente, la scrittura nell'archiviazione persistente non avviene istantaneamente. Se la chiamata fdatasync è lenta, le prestazioni del sistema etcd ne risentiranno. La documentazione per etcd diceche l'archiviazione è considerata abbastanza veloce se, nel 99° percentile, le chiamate fdatasync impiegano meno di 10 ms per scrivere nel file WAL. Esistono altre metriche utili per l'archiviazione, ma in questo post stiamo parlando solo di questa metrica.

Stima dello stoccaggio con fio

Se devi valutare se il tuo storage è adatto per etcd, usa fio, uno strumento di test del carico I/O molto popolare. Va ricordato che le operazioni su disco possono essere molto diverse: sincrone e asincrone, molte classi di chiamate di sistema, ecc. Di conseguenza, fio è piuttosto difficile da usare. Ha molti parametri e diverse combinazioni dei loro valori producono carichi di lavoro I/O molto diversi. Per ottenere cifre adeguate per etcd, dovresti assicurarti che il carico di scrittura di prova da fio sia il più vicino possibile al carico effettivo da etcd durante la scrittura dei file WAL.

Pertanto, fio dovrebbe, come minimo, creare un caricamento di una serie di scritture sequenziali sul file, ciascuna scrittura consisterà in una chiamata di sistema scrivereseguito dalla chiamata di sistema fdatasync. Le scritture sequenziali su fio richiedono l'opzione --rw=write. Per fio usare la chiamata di sistema write durante la scrittura, piuttosto che scrivere, devi specificare il parametro --ioengine=sync. Infine, per chiamare fdatasync dopo ogni scrittura, è necessario aggiungere il parametro --fdatasync=1. Le altre due opzioni in questo esempio (--size e -bs) sono specifiche dello script. Nella sezione successiva, ti mostreremo come configurarli.

Perché fio e come abbiamo imparato a configurarlo

In questo post, descriviamo un caso reale. Abbiamo un cluster kubernetes v1.13 che abbiamo monitorato con Prometheus. etcd v3.2.24 era ospitato su un SSD. Le metriche Etcd hanno mostrato latenze fdatasync troppo elevate, anche quando il cluster non stava facendo nulla. Le metriche erano strane e non sapevamo davvero cosa significassero. Il cluster era costituito da macchine virtuali, era necessario capire quale fosse il problema: negli SSD fisici o nel layer di virtualizzazione. Inoltre, abbiamo spesso apportato modifiche alla configurazione hardware e software e avevamo bisogno di un modo per valutarne i risultati. Potremmo eseguire etcd in ogni configurazione e guardare le metriche di Prometheus, ma è una seccatura eccessiva. Stavamo cercando un modo abbastanza semplice per valutare una configurazione specifica. Volevamo verificare se comprendiamo correttamente le metriche di Prometheus da etcd.

Ma per questo, due problemi dovevano essere risolti. Innanzitutto, che aspetto ha il carico di I/O creato da etcd durante la scrittura su WAL? Quali chiamate di sistema vengono utilizzate? Qual è la dimensione dei record? In secondo luogo, se rispondiamo a queste domande, come riproduciamo un carico di lavoro simile con fio? Non dimenticare che fio è uno strumento molto flessibile con molte opzioni. Abbiamo risolto entrambi i problemi con un approccio: utilizzando i comandi lsof и straccio. lsof elenca tutti i descrittori di file utilizzati dal processo e i file associati. E con strace, puoi esaminare un processo già in esecuzione o avviare un processo ed esaminarlo. strace stampa tutte le chiamate di sistema dal processo esaminato (e dai suoi processi figli). Quest'ultimo è molto importante, poiché etcd sta solo adottando un approccio simile.

Per prima cosa abbiamo utilizzato strace per esplorare il server etcd per Kubernetes quando non c'era carico sul cluster. Abbiamo visto che quasi tutti i record WAL avevano all'incirca le stesse dimensioni: 2200–2400 byte. Pertanto, nel comando all'inizio del post, abbiamo specificato il parametro -bs=2300 (bs indica la dimensione in byte per ogni voce fio). Si noti che la dimensione della voce etcd dipende dalla versione etcd, dalla distribuzione, dai valori dei parametri, ecc., e influisce sulla durata di fdatasync. Se hai uno scenario simile, esamina i tuoi processi etcd con strace per scoprire i numeri esatti.

Quindi, per avere una buona idea di cosa sta facendo il file system etcd, lo abbiamo avviato con strace e le opzioni -ffttT. Quindi abbiamo cercato di esaminare i processi figli e registrare l'output di ciascuno di essi in un file separato, e ottenere anche rapporti dettagliati sull'inizio e la durata di ciascuna chiamata di sistema. Abbiamo utilizzato lsof per confermare la nostra analisi dell'output di strace e vedere quale descrittore di file veniva utilizzato per quale scopo. Quindi, con l'aiuto di strace, sono stati ottenuti i risultati mostrati sopra. Le statistiche sul tempo di sincronizzazione hanno confermato che wal_fsync_duration_seconds da etcd è coerente con le chiamate fdatasync con descrittori di file WAL.

Abbiamo esaminato la documentazione per fio e scelto le opzioni per il nostro script in modo che fio generasse un carico simile a etcd. Abbiamo anche controllato le chiamate di sistema e la loro durata eseguendo fio da strace, simile a etcd.

Abbiamo scelto con cura il valore del parametro --size per rappresentare l'intero carico di I/O da fio. Nel nostro caso, questo è il numero totale di byte scritti nell'archivio. Si è rivelato essere direttamente proporzionale al numero di chiamate di sistema write (e fdatasync). Per un certo valore di bs, il numero di chiamate fdatasync = size/bs. Dato che eravamo interessati al percentile, dovevamo avere campioni sufficienti per essere sicuri e abbiamo calcolato che 10^4 sarebbe stato sufficiente per noi (ovvero 22 mebibyte). Se --size è più piccolo, possono verificarsi valori anomali (ad esempio, diverse chiamate fdatasync impiegano più tempo del solito e influiscono sul 99° percentile).

Provate voi stessi

Ti abbiamo mostrato come usare fio e vedere se l'archiviazione è abbastanza veloce da consentire a etcd di funzionare bene. Ora puoi provarlo tu stesso utilizzando, ad esempio, macchine virtuali con storage SSD IBM Cloud.

Fonte: habr.com