La velocità di archiviazione è adatta per etcd? Domandiamo a fio

Breve storia di fio ed etcd

Le prestazioni del cluster sono stati resi dipendono in gran parte dalle prestazioni del suo storage. etcd esporta alcune metriche in Prometheus, per fornire le informazioni necessarie sulle prestazioni dello storage. Ad esempio, la metrica wal_fsync_duration_seconds. Nella documentazione di etcd si afferma: affinché lo storage sia considerato sufficientemente veloce, il 99° percentile di questa metrica deve essere inferiore a 10 ms. Se prevedi di avviare un cluster etcd su macchine Linux e vuoi valutare se il tuo storage è sufficientemente veloce (ad esempio, SSD), puoi utilizzare fio — uno strumento popolare per testare le operazioni di input/output. Esegui il seguente comando, dove test-data è la directory sotto il punto di montaggio dello storage:

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

Basta guardare i risultati e controllare che il 99° percentile della durata fdatasync 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 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 un risultato utile da fio, indica i tuoi valori. Da dove prenderli? Leggi come abbiamo imparato a configurare fio.
• Durante il testing, tutto il carico di input/output proviene da fio. In uno scenario reale, probabilmente ci saranno anche altre richieste di scrittura nello storage, 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 a 10 ms, il tuo storage non avrà sufficiente velocità.
• Prendi la versione fio non inferiore a 3.5 (le versioni precedenti non mostrano i percentili della durata di fdatasync).
• Sopra è mostrato solo un frammento dei risultati di fio.

Lunga storia di fio ed etcd

Che cos'è WAL in etcd

Di solito, i database utilizzano il log delle scritture anticipate; etcd lo utilizza anch'esso. Qui non discuteremo in dettaglio il log delle scritture anticipate (write-ahead log, WAL). È sufficiente sapere che ogni membro del cluster etcd lo registra in uno storage permanente. etcd registra ogni operazione con coppie chiave-valore (ad esempio, un aggiornamento) nel WAL, prima di applicarle allo storage. Se uno dei membri dello storage va in crash e si riavvia tra gli snapshot, può ripristinare localmente le transazioni dall'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 file normale nello storage permanente. Prima di continuare l'elaborazione, etcd DEVE essere completamente certo che la registrazione nel WAL sia realmente avvenuta. In Linux, una sola chiamata di sistema non è sufficiente. write, poiché la scrittura nello storage fisico potrebbe essere ritardata. Ad esempio, Linux può tenere in cache in memoria del kernel (ad esempio, nella cache delle pagine) la registrazione WAL per un certo tempo. E per garantire che i dati siano effettivamente scritti nello storage permanente, è necessaria una chiamata di sistema fdatasync dopo la scrittura, e etcd la utilizza (come può essere visto nell'output strace, 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)            = 0

Sfortunatamente, la scrittura nello storage permanente non avviene istantaneamente. Se la chiamata fdatasync funziona lentamente, le prestazioni del sistema etcd diminuiscono. Nella documentazione di etcd si afferma, che lo storage è considerato sufficientemente veloce se nel 99° percentile delle chiamate fdatasync durante la scrittura nel file WAL impiegano meno di 10 ms. Ci sono altre metriche utili per lo storage, ma in questo post parliamo solo di questa metrica.

Valutazione dello storage usando fio

Se è necessario valutare se il vostro storage è adatto per etcd, utilizzate fio, uno strumento di testing delle prestazioni di I/O molto popolare. È importante ricordare che le operazioni su disco possono essere delle più varie: sincrone e asincrone, molteplici classi di chiamate di sistema, ecc. Di conseguenza, fio è piuttosto complesso da utilizzare. Ha molti parametri, e diverse combinazioni dei loro valori producono carichi di lavoro I/O completamente diversi. Per ottenere numeri adeguati per etcd, è necessario assicurarsi che il carico di lavoro di scrittura di fio sia il più vicino possibile al carico reale di etcd durante la scrittura dei file WAL.

Pertanto, fio deve, almeno, generare un carico sotto forma di una serie di operazioni di scrittura sequenziali su un file, ogni scrittura consisterà in una chiamata di sistema write, seguita da una chiamata di sistema fdatasync. Per le operazioni di scrittura sequenziali, fio ha bisogno del parametro —rw=write. Per far sì che fio utilizzi la chiamata di sistema write durante la scrittura, è necessario specificare il parametro —ioengine=sync. Infine, per chiamare fdatasync dopo ogni scrittura, bisogna aggiungere il parametro —fdatasync=1. Gli altri due parametri in questo esempio (—size e —bs) dipendono dallo specifico scenario. Nella sezione successiva spiegheremo come configurarli. pwritePerché proprio fio e come abbiamo imparato a configurarlo

In questo post descriviamo un caso reale. Avevamo un cluster

v1.13, che monitoravamo utilizzando Prometheus. etcd v3.2.24 era ospitato su SSD. Le metriche di etcd mostrano latenze troppo elevate per fdatasync, anche quando il cluster non stava facendo nulla. Le metriche erano strane e non sapevamo bene cosa significassero. Il cluster era composto da macchine virtuali e dovevamo capire qual era il problema: nel SSD fisico o nel layer di virtualizzazione. Inoltre, apportavamo frequentemente modifiche alla configurazione dell'hardware e del software e avevamo bisogno di un modo per valutarne gli effetti. Potevamo eseguire etcd in ogni configurazione e osservare le metriche di Prometheus, ma era troppo laborioso. Stavamo cercando un modo abbastanza semplice per valutare una configurazione specifica. Volevamo verificare se capivamo correttamente le metriche di Prometheus di etcd. Kubernetes v1.13, che monitoravamo con Prometheus. etcd v3.2.24 era ospitato su SSD. Le metriche di etcd mostravano latenze troppo elevate per fdatasync, anche quando il cluster non stava facendo nulla. Le metriche erano strane e non sapevamo bene cosa significassero. Il cluster era composto da macchine virtuali e dovevamo capire dove fosse il problema: negli SSD fisici o nel layer di virtualizzazione. Inoltre, apportavamo spesso modifiche alla configurazione hardware e software e avevamo bisogno di un modo per valutare i loro risultati. Potevamo eseguire etcd in ogni configurazione e osservare le metriche di Prometheus, ma era troppo laborioso. Cercavamo un modo sufficientemente semplice per valutare una configurazione specifica. Volevamo verificare se interpretavamo correttamente le metriche di Prometheus di etcd.

Ma per questo era necessario risolvere due problemi. In primo luogo, com'è il carico di input-output che etcd genera quando scrive nel WAL? Quali chiamate di sistema vengono utilizzate? Qual è la dimensione delle registrazioni? In secondo luogo, se rispondiamo a queste domande, come possiamo riprodurre un carico di lavoro simile con fio? Non dimenticate che fio è uno strumento molto flessibile con molti parametri. Abbiamo risolto entrambi i problemi con un unico approccio: utilizzando comandi lsof e strace. lsof mostra tutti i descrittori di file utilizzati dal processo e i file correlati. Con strace possiamo analizzare un processo già in esecuzione o avviarne uno e studiarlo. strace visualizza tutte le chiamate di sistema effettuate dal processo in esame (e dai suoi processi figli). Quest'ultima è molto importante, poiché etcd applica proprio questo approccio.

Per prima cosa, abbiamo utilizzato strace per esaminare il server etcd per Kubernetes quando non vi era alcun carico sul cluster. Abbiamo notato che quasi tutte le registrazioni WAL avevano all'incirca la stessa dimensione: 2200–2400 byte. Perciò nel comando all'inizio del post abbiamo specificato il parametro —bs=2300 (bs indica la dimensione in byte per ciascuna registrazione fio). Si prega di notare che la dimensione della registrazione etcd dipende dalla versione di etcd, dalla distribuzione, dai valori dei parametri, ecc., e influisce sulla durata di fdatasync. Se hai uno scenario simile, analizza i tuoi processi etcd con strace per scoprire i numeri esatti.

Successivamente, per avere una buona rappresentazione delle operazioni nel file system etcd, l'abbiamo avviato con strace e con i parametri -ffttT. Così abbiamo cercato di esaminare i processi figli e registrare l'output di ciascuno in un file separato, oltre a ottenere rapporti dettagliati sull'inizio e sulla 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 quali scopi. Così siamo riusciti a ottenere i risultati mostrati sopra. Le statistiche sui tempi di sincronizzazione hanno confermato che il valore wal_fsync_duration_seconds di etcd corrisponde alle chiamate di fdatasync con i descrittori di file WAL.

Abbiamo esaminato la documentazione di fio e scelto i parametri per il nostro scenario, in modo che fio generasse un carico simile a quello di etcd. Abbiamo anche controllato le chiamate di sistema e la loro durata avviando fio da strace, in analogia con etcd.

Abbiamo selezionato accuratamente il valore del parametro —size, che rappresenta il carico totale di input/output da fio. Nel nostro caso, si tratta del numero totale di byte scritti nello storage. Questo si è rivelato direttamente proporzionale al numero di chiamate di sistema write (e fdatasync). Per un determinato valore di bs, il numero di chiamate a fdatasync = size/bs. Poiché eravamo interessati al percentile, dovevamo avere un numero sufficiente di campioni per l'affidabilità, e abbiamo calcolato che 10^4 (corrisponde a 22 mebibyte) sarebbe stato sufficiente. Se —size è inferiore, potrebbero verificarsi effetti anomali (ad esempio, alcune chiamate a fdatasync richiedono più tempo del normale e influenzano il 99° percentile).

Prova tu stesso

Abbiamo mostrato come utilizzare fio e scoprire se lo storage ha la velocità necessaria per alte prestazioni di etcd. Ora puoi provare a farlo da solo, utilizzando ad esempio macchine virtuali con storage SSD in IBM Cloud.

Fonte: habr.com