🥇Com comprovar els discs amb fio per obtenir un rendiment suficient per etcd

Nota. transl.: Aquest article és el resultat d'una mini-investigació realitzada pels enginyers d'IBM Cloud a la recerca d'una solució a un problema real relacionat amb el funcionament de la base de dades etcd. Una tasca semblant era rellevant per a nosaltres, però, el curs de reflexions i accions dels autors pot ser interessant en un context més ampli.

Breu resum de tot l'article: fio i etcd

El rendiment d'un clúster etcd depèn molt de la velocitat de l'emmagatzematge subjacent. etcd exporta diverses mètriques de Prometheus per supervisar el rendiment. Un d'ells és wal_fsync_duration_seconds. A la documentació per etcd diuaquest emmagatzematge es pot considerar prou ràpid si el percentil 99 d'aquesta mètrica no supera els 10 ms...

Si esteu pensant en configurar un clúster etcd en màquines Linux i voleu provar si les unitats (com ara els SSD) són prou ràpides, us recomanem que utilitzeu el popular provador d'E/S anomenat fil. N'hi ha prou amb executar la següent comanda (directori test-data s'ha d'ubicar a la partició muntada de la unitat provada):

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

Només queda mirar la sortida i comprovar si el percentil 99 s'adapta fdatasync en 10 ms. Si és així, la vostra unitat funciona prou ràpid. Aquí teniu un exemple de sortida:

fsync/fdatasync/sync_file_range:
  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]

Unes quantes notes:

A l'exemple anterior, hem ajustat els paràmetres --size и --bs per a un cas concret. Per obtenir un resultat significatiu fio, especifiqueu els valors adequats per al vostre cas d'ús. Com triar-los s'explicarà a continuació.
Només durant les proves fio carrega el subsistema de disc. A la vida real, és probable que altres processos escriguin al disc (a més dels relacionats amb wal_fsync_duration_seconds). Aquesta càrrega addicional pot augmentar wal_fsync_duration_seconds. En altres paraules, si el percentil 99 de la prova amb fio, només una mica menys de 10 ms, hi ha una bona probabilitat que el rendiment d'emmagatzematge no sigui suficient.
Per a la prova necessitareu la versió fio no menys de 3.5, perquè les versions anteriors no agreguen resultats fdatasync en forma de percentils.
La conclusió anterior és només un petit fragment de la conclusió general fio.

Més informació sobre fio i etcd

Unes paraules sobre WAL, etcd

En general, s'utilitzen bases de dades registre proactiu (Registre d'escriptura anticipada, WAL). etcd també es veu afectat. Una discussió sobre WAL està fora de l'abast d'aquest article, però per als nostres propòsits, el que necessiteu saber és que cada membre del clúster etcd emmagatzema WAL en un emmagatzematge persistent. etcd escriu algunes operacions d'emmagatzematge de valor-clau (com ara actualitzacions) a WAL abans d'executar-les. Si un node es bloqueja i es reinicia entre instantànies, etcd pot recuperar transaccions des de la instantània anterior en funció del contingut del WAL.

Així, cada vegada que un client afegeix una clau a la botiga KV o actualitza el valor d'una clau existent, etcd afegeix la descripció de l'operació al WAL, que és un fitxer normal a la botiga persistent. etcd HA d'estar 100% segur que l'entrada WAL s'ha desat realment abans de continuar. Per aconseguir-ho a Linux, no n'hi ha prou amb utilitzar la trucada al sistema write, ja que la pròpia operació d'escriptura al suport físic pot ser retardada. Per exemple, Linux pot mantenir una entrada WAL en una memòria cau del nucli a la memòria (per exemple, a la memòria cau de la pàgina) durant algun temps. Per garantir que les dades s'escriuen al suport, s'ha d'invocar una trucada al sistema després de l'escriptura fdatasync - això és exactament el que fa etcd (com podeu veure a la sortida següent strace; Aquí 8 - Descriptor de fitxer WAL):

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

Malauradament, escriure a l'emmagatzematge persistent triga un temps. L'execució prolongada de les trucades fdatasync pot afectar el rendiment de etcd. A la documentació del repositori indicat, que per a un rendiment suficient és necessari que el percentil 99 de la durada de totes les convocatòries fdatasync en escriure en un fitxer WAL era inferior a 10 ms. Hi ha altres mètriques relacionades amb l'emmagatzematge, però aquest article se centrarà en aquest.

Valorant l'emmagatzematge amb fio

Podeu avaluar si un determinat emmagatzematge és adequat per utilitzar-lo amb etcd mitjançant la utilitat fil - un provador d'E/S popular. Tingueu en compte que les E/S de disc es poden produir de moltes maneres diferents: sincronització/async, moltes classes de syscall diferents, etc. L'altra cara de la moneda és aquesta fio extremadament difícil d'utilitzar. La utilitat té molts paràmetres i diferents combinacions dels seus valors donen lloc a resultats completament diferents. Per obtenir una estimació raonable d'etcd, heu d'assegurar-vos que la càrrega d'escriptura generada per fio sigui el més propera possible a la càrrega d'escriptura del fitxer WAL d'etcd:

Això vol dir que el generat fio la càrrega hauria de ser almenys una sèrie d'escriptures consecutives al fitxer, on cada escriptura consisteix en una crida al sistema writeSeguit per fdatasync.
Per habilitar l'escriptura seqüencial, heu d'especificar el senyalador --rw=write.
Que fio escriure mitjançant trucades write (en lloc d'altres trucades al sistema, per exemple, pwrite), utilitzeu la bandera --ioengine=sync.
Finalment, la bandera --fdatasync=1 assegura que cada write ha de ser fdatasync.
Els altres dos paràmetres del nostre exemple són: --size и --bs - pot variar segons el cas d'ús específic. La següent secció descriurà la seva configuració.

Per què vam triar fio i com vam aprendre a configurar-lo

Aquesta nota prové d'un cas real que hem trobat. Teníem un clúster a Kubernetes v1.13 amb monitorització a Prometheus. Els SSD es van utilitzar com a emmagatzematge per a etcd v3.2.24. Les mètriques Etcd van mostrar latències massa altes fdatasync, fins i tot quan el clúster estava inactiu. A nosaltres, aquestes mètriques ens semblaven molt dubtoses i no estàvem segurs de què representaven exactament. A més, el clúster estava format per màquines virtuals, per la qual cosa no es podia dir si el retard es devia a la virtualització o la culpa de l'SSD.

A més, vam tenir en compte diversos canvis en la configuració de maquinari i programari, per la qual cosa necessitàvem una manera d'avaluar-los. Per descomptat, seria possible executar etcd en cada configuració i mirar les mètriques de Prometheus corresponents, però això requeriria un esforç important. El que necessitàvem era una manera senzilla d'avaluar una configuració específica. Volíem provar la nostra comprensió de les mètriques de Prometheus provinents d'etcd.

Això va requerir resoldre dos problemes:

En primer lloc, com es veu la càrrega d'E/S generada per etcd quan s'escriu als fitxers WAL? Quines trucades de sistema s'utilitzen? Quina és la mida dels blocs de registre?
En segon lloc, diguem que tenim respostes a les preguntes anteriors. Com reproduir la càrrega corresponent amb fio? Després de tot fio — Utilitat extremadament flexible amb una gran quantitat de paràmetres (això és fàcil de verificar, per exemple, aquí -aprox. trad.).

Hem resolt tots dos problemes amb el mateix enfocament basat en comandes lsof и strace:

Amb lsof podeu veure tots els descriptors de fitxers utilitzats pel procés, així com els fitxers als quals es refereixen.
Amb strace podeu analitzar un procés que ja s'està executant o executar un procés i mirar-lo. L'ordre mostra totes les trucades al sistema fetes per aquest procés i, si cal, els seus descendents. Aquest últim és important per als processos que es bifurquen, i etcd és un d'aquests processos.

El primer que vam fer va ser utilitzar strace per examinar el servidor etcd del clúster de Kubernetes mentre estava inactiu.

Així que es va trobar que els blocs de registre WAL estan agrupats molt densament, la mida de la majoria estava en el rang de 2200-2400 bytes. És per això que l'ordre al començament d'aquest article utilitza la bandera --bs=2300 (bs és la mida en bytes de cada bloc d'escriptura fio).

Tingueu en compte que la mida dels blocs d'escriptura d'etcd pot variar segons la versió, el desplegament, els valors dels paràmetres, etc. - afecta la durada fdatasync. Si teniu un cas d'ús similar, analitzeu-lo amb strace els vostres processos etcd per obtenir valors actualitzats.

Aleshores, per tenir una idea clara i completa de com funciona etcd amb el sistema de fitxers, el vam començar des de sota strace amb banderes -ffttT. Això va permetre capturar processos fills i escriure la sortida de cadascun en un fitxer separat. A més, es va obtenir informació detallada sobre l'hora d'inici i la durada de cada trucada al sistema.

També hem utilitzat l'ordre lsofper confirmar la vostra comprensió de la sortida strace pel que fa a quin descriptor de fitxer s'ha utilitzat per a quin propòsit. He arribat a la conclusió strace, semblant a l'anterior. Les manipulacions estadístiques amb els temps de sincronització van confirmar que la mètrica wal_fsync_duration_seconds de les trucades de coincidències d'etcd fdatasync amb descriptors de fitxers WAL.

Per generar amb fio una càrrega de treball semblant a la d'etcd, es va estudiar la documentació de la utilitat i es van seleccionar els paràmetres adequats a la nostra tasca. Hem verificat que les trucades al sistema correctes estan en curs i hem confirmat la seva durada executant-nos fio d' strace (com es va fer en cas d'etcd).

Es va prestar especial atenció a la determinació del valor del paràmetre --size. Representa la càrrega total d'E/S generada per la utilitat fio. En el nostre cas, aquest és el nombre total de bytes escrits al suport. És directament proporcional al nombre de trucades write (i fdatasync). Per a un concret bs nombre de trucades fdatasync és igual size / bs.

Com que ens interessava el percentil, volíem que el nombre de mostres fos prou gran per ser estadísticament significatiu. I això ho va decidir 10^4 (que correspon a una mida de 22 MB) n'hi haurà prou. Valors de paràmetres més petits --size va donar un soroll més pronunciat (per exemple, trucades fdatasync, que triguen molt més de l'habitual i afecten el percentil 99).

Depèn de tu

L'article mostra com utilitzar-lo fio es pot jutjar si el mitjà destinat a utilitzar-se amb etcd és prou ràpid. Ara et toca a tu! Podeu explorar màquines virtuals amb emmagatzematge basat en SSD al servei IBM Cloud.

PS del traductor

Amb casos d'ús ja fets fio Per a altres tasques, vegeu documentació o directament a repositoris de projectes (n'hi ha molts més dels que s'esmenten a la documentació).

PPS del traductor

Llegeix també al nostre blog:

Font: www.habr.com

Com comprovar els discs amb fio per obtenir un rendiment suficient per etcd