Una breve storia su fio ed etcd
Prestazioni del cluster dipende in gran parte dalle prestazioni del suo storage. etcd esporta alcune metriche in , per fornire le informazioni necessarie sulle prestazioni dello storage. Ad esempio, la metrica wal_fsync_duration_seconds. : affinché lo storage sia considerato sufficientemente veloce, il 99° percentile di questa metrica deve essere inferiore a 10 ms. Se intendi avviare un cluster etcd su macchine Linux e vuoi valutare se il tuo storage è sufficientemente veloce (ad esempio, SSD), puoi utilizzare — uno strumento popolare per il testing delle operazioni di input/output. Esegui il seguente comando, dove test-data è la directory sotto il punto di mount dello storage:
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestDevi solo controllare i risultati e verificare che il 99° percentile della durata sia inferiore a 10 ms. Se sì, hai uno storage sufficientemente veloce. Ecco un esempio di risultati:
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
percentili di sync (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 configurato i valori dei parametri —size e —bs per il nostro specifico scenario. Per ottenere risultati utili da fio, inserisci i tuoi valori. Dove trovarli? Leggi, .
- Durante il testing, tutto il carico di input/output proviene da fio. In uno scenario reale, ci saranno probabilmente altre richieste di scrittura oltre a quelle relative a wal_fsync_duration_seconds. Un carico aggiuntivo aumenterà il valore di wal_fsync_duration_seconds. Quindi, se il 99° percentile si avvicina ai 10 ms, il tuo storage non è sufficientemente veloce.
- Prendi la versione non inferiore alla 3.5 (le versioni precedenti non mostrano i percentili di durata di fdatasync).
- Sopra è mostrato solo un frammento dei risultati da fio.
Una lunga storia su fio ed etcd
Che cos'è WAL in etcd
Di solito, i database usano ; anche etcd lo usa. Qui non discuteremo in dettaglio il journaling write-ahead (WAL). Ciò che ci basta sapere è che ogni membro del cluster etcd lo registra nello storage persistente. etcd registra ogni operazione con coppie chiave-valore (ad esempio, un aggiornamento) nel WAL, prima di applicarle allo storage. Se tra i snapshot uno dei membri dello storage si arresta in modo anomalo e si riavvia, può ripristinare localmente le transazioni dal momento dell'ultimo snapshot utilizzando il contenuto del WAL.
Quando un client aggiunge una chiave allo storage delle coppie chiave-valore o aggiorna il valore di una chiave esistente, etcd registra questa operazione nel WAL, che è un semplice file nello storage persistente. Prima di continuare l'elaborazione, etcd DEVE essere completamente sicuro che la scrittura nel WAL sia avvenuta. In Linux, ciò non è sufficiente con una sola chiamata di sistema , poiché la scrittura nello storage fisico può effettivamente essere posticipata. Ad esempio, Linux può tenere la scrittura WAL in cache nella memoria del kernel (ad esempio, nella cache delle pagine) per un certo periodo di tempo. E per garantire che i dati siano scritti esattamente nello storage persistente, è necessaria una chiamata di sistema fdatasync dopo la scrittura, e etcd la utilizza (come si può vedere dal risultato di , dove 8 è il descrittore del file WAL):
21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808
21:23:09.894911 write(8, ". 20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296
21:23:09.895041 fdatasync(8) = 0Sfortunatamente, la scrittura nello storage persistente non avviene istantaneamente. Se la chiamata fdatasync funziona lentamente, le prestazioni del sistema etcd diminuiscono. , che lo storage è considerato sufficientemente veloce se nel 99° percentile delle chiamate fdatasync durante la scrittura del file WAL ci vogliono meno di 10 ms. Ci sono altre metriche utili per lo storage, ma in questo post parliamo solo di questa metrica.
Valutazione dello storage con fio
Se vuoi valutare se il tuo storage è adatto per etcd, utilizza fio — uno strumento molto popolare per il test del carico di input/output. Si deve tenere presente che le operazioni su disco possono variare notevolmente: sincrone e asincrone, con molte classi di chiamate di sistema, ecc. Di conseguenza, fio è abbastanza complicato da usare. Ha un sacco di parametri e diverse combinazioni di essi producono carichi di lavoro di input/output molto diversi. Per ottenere cifre adeguate per etcd, è necessario garantire che il carico di scrittura di test da fio sia il più simile possibile al carico reale di etcd durante la scrittura dei file WAL.
Pertanto, fio deve, almeno, generare un carico costituito da una serie di operazioni di scrittura sequenziale in un file, ogni scrittura consisterà in una chiamata di sistema , seguito da una chiamata di sistema fdatasync. Per le operazioni di scrittura sequenziale, fio richiede il parametro —rw=write. Per fare in modo che fio utilizzi la chiamata di sistema write durante la scrittura, bisogna specificare , è consigliabile impostare il parametro —ioengine=sync. Infine, per far sì che fdatasync venga chiamato dopo ogni scrittura, è necessario aggiungere il parametro —fdatasync=1. Gli altri due parametri in questo esempio (—size e —bs) dipendono dallo scenario specifico. Nella sezione successiva spiegheremo come configurarli.
Perché scegliere fio e come abbiamo imparato a configurarlo
In questo post descriviamo un caso reale. Avevamo un cluster v1.13, che monitoravamo con Prometheus. etcd v3.2.24 era ospitato su SSD. Le metriche di etcd mostrano latenze troppo elevate per fdatasync, anche quando il cluster non svolgeva operazioni. Le metriche sembravano strane, e non sapevamo esattamente cosa significassero. Il cluster era composto da macchine virtuali, e dovevamo capire se il problema risiedesse negli SSD fisici o nel livello di virtualizzazione. Inoltre, frequentemente modificavamo la configurazione hardware e software, e avevamo bisogno di un modo per valutare i risultati. Potevamo eseguire etcd con ogni configurazione e osservare le metriche di Prometheus, ma ciò era troppo laborioso. Cercavamo un modo sufficientemente semplice per valutare una configurazione specifica. Volevamo verificare se comprendevamo correttamente le metriche di Prometheus di etcd.
Ma per questo era necessario risolvere due problemi. In primo luogo, qual è il carico di input/output che etcd genera durante la scrittura nel WAL? Quali chiamate di sistema vengono utilizzate? Qual è la dimensione delle scritture? In secondo luogo, se rispondiamo a queste domande, come riprodurre un carico di lavoro simile con fio? Ricordate che fio è uno strumento molto flessibile con molti parametri. Abbiamo affrontato entrambi i problemi con un unico approccio — tramite i comandi e . lsof mostra tutti i descrittori di file utilizzati dal processo e i file associati. Con strace, possiamo studiare un processo già avviato o avviarne uno nuovo e analizzarlo. strace restituisce tutte le chiamate di sistema del processo monitorato (e dei suoi processi figli). Quest'ultimo aspetto è molto importante, poiché etcd applica proprio questo approccio.
Per prima cosa, abbiamo utilizzato strace per studiare il server etcd per Kubernetes quando non c'era carico sul cluster. Abbiamo osservato che quasi tutte le scritture nel WAL erano di dimensioni simili: 2200–2400 byte. Pertanto, nel comando all'inizio del post abbiamo impostato il parametro —bs=2300 (bs significa dimensione in byte per ogni scrittura di fio). Si prega di notare che la dimensione delle scritture in etcd dipende dalla versione di etcd, dalla distribuzione, dai valori dei parametri, ecc., e influisce sulla durata di fdatasync. Se avete uno scenario simile, esaminate i vostri processi etcd con strace per ottenere i numeri esatti.
Successivamente, per avere una chiara rappresentazione delle operazioni nel file system di etcd, l'abbiamo avviato con strace e con i parametri -ffttT. Così abbiamo cercato di analizzare i processi figli e registrare l'output di ciascuno di essi in un file separato, e ottenere anche report 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 fosse utilizzato per quali scopi. Così con strace abbiamo ottenuto i risultati mostrati sopra. Le statistiche sul tempo di sincronizzazione hanno confermato che il parametro wal_fsync_duration_seconds di etcd corrisponde alle chiamate fdatasync con i descrittori di file WAL.
Abbiamo esaminato la documentazione di fio e selezionato i parametri per il nostro scenario in modo che fio generasse un carico simile a quello di etcd. Abbiamo anche verificato le chiamate di sistema e la loro durata eseguendo fio tramite strace, analogamente a etcd.
Abbiamo accuratamente scelto il valore del parametro —size, che rappresenta l'intero carico di input/output di fio. Nel nostro caso, si tratta del numero totale di byte scritti nel repository. Questo è risultato direttamente proporzionale al numero di chiamate di sistema write (e fdatasync). Per un certo valore di bs, il numero di chiamate a fdatasync = size/bs. Poiché ci interessava il percentile, dovevamo avere un numero sufficiente di campioni per la validità, e abbiamo stimato che 10^4 campioni sarebbero stati sufficienti (il che equivale a 22 mebibyte). Se —size è inferiore, potrebbero verificarsi outlier (ad esempio, alcune chiamate fdatasync impiegano più tempo del normale e influenzano il 99° percentile).
Provalo da solo
Abbiamo mostrato come utilizzare fio e verificare se il nostro storage ha la velocità necessaria per le alte prestazioni di etcd. Ora puoi provare a farlo concretamente, utilizzando ad esempio macchine virtuali con storage SSD in .
Fonte: habr.com
