Velocitat d'emmagatzematge adequada per a etcd? Preguntem a fio

Una història curta sobre fio i etcd

Rendiment del clúster etc. depèn en gran mesura del rendiment del seu emmagatzematge. etcd exporta algunes mètriques a Prometeuper proporcionar la informació de rendiment d'emmagatzematge desitjada. Per exemple, la mètrica wal_fsync_duration_seconds. La documentació per etcd diu: perquè l'emmagatzematge es consideri prou ràpid, el percentil 99 d'aquesta mètrica ha de ser inferior a 10 ms. Si teniu previst executar un clúster etcd en màquines Linux i voleu avaluar si el vostre emmagatzematge és prou ràpid (per exemple, SSD), podeu utilitzar fil és una eina popular per provar les operacions d'E/S. Executeu l'ordre següent, on test-data és el directori sota el punt de muntatge d'emmagatzematge:

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

Només cal mirar els resultats i comprovar que el percentil 99 de la durada fdatasync menys de 10 ms. Si és així, teniu un emmagatzematge raonablement ràpid. Aquí teniu un exemple dels resultats:

  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]

Notes

• Hem personalitzat les opcions --size i --bs per al nostre escenari particular. Per obtenir un resultat útil de fio, proporcioneu els vostres propis valors. On aconseguir-los? Llegeix com hem après a configurar fio.
• Durant la prova, tota la càrrega d'E/S prové de fio. En un escenari de la vida real, és probable que hi hagi altres sol·licituds d'escriptura que arribin a l'emmagatzematge a més de les relacionades amb wal_fsync_duration_seconds. La càrrega addicional augmentarà el valor de wal_fsync_duration_seconds. Per tant, si el percentil 99 és a prop dels 10 ms, el vostre emmagatzematge s'està quedant sense velocitat.
• Pren la versió fil no menys de 3.5 (els anteriors no mostren percentils de durada de fdatasync).
• A dalt només hi ha un fragment dels resultats de fio.

Llarga història sobre fio i etcd

Què és WAL a etcd

Normalment s'utilitzen bases de dades registre d'escriptura anticipada; etcd també ho fa servir. No parlarem del registre d'escriptura anticipada (WAL) en detall aquí. Ens n'hi ha prou de saber que cada membre del clúster etcd el manté en un emmagatzematge persistent. etcd escriu cada operació de valor-clau (com ara una actualització) a WAL abans d'aplicar-la a la botiga. Si un dels membres d'emmagatzematge es bloqueja i es reinicia entre instantànies, pot restaurar localment les transaccions des de l'última instantània del contingut WAL.

Quan un client afegeix una clau al magatzem de valor-clau o actualitza el valor d'una clau existent, etcd registra l'operació a WAL, que és un fitxer normal en emmagatzematge persistent. etcd HA d'estar completament segur que l'entrada WAL es va produir realment abans de continuar amb el processament. A Linux, una trucada al sistema no és suficient per a això. escriure, ja que l'escriptura real a l'emmagatzematge físic es pot retardar. Per exemple, Linux pot emmagatzemar una entrada WAL en una memòria cau de la memòria del nucli (com ara una memòria cau de la pàgina) durant algun temps. I perquè les dades s'escriguin amb precisió a l'emmagatzematge persistent, es necessita la crida al sistema fdatasync després de l'escriptura, i etcd només l'utilitza (com podeu veure al resultat del treball). strace, on 8 és el descriptor del fitxer 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>

Malauradament, l'escriptura a l'emmagatzematge persistent no es produeix a l'instant. Si la trucada fdatasync és lenta, el rendiment del sistema etcd patirà. La documentació per etcd diuque l'emmagatzematge es considera prou ràpid si, en el percentil 99, les trucades de fdatasync triguen menys de 10 ms a escriure al fitxer WAL. Hi ha altres mètriques útils per a l'emmagatzematge, però en aquesta entrada només parlem d'aquesta mètrica.

Estimació d'emmagatzematge amb fio

Si necessiteu avaluar si el vostre emmagatzematge és adequat per a etcd, utilitzeu fio, una eina de prova de càrrega d'E/S molt popular. Cal recordar que les operacions del disc poden ser molt diferents: síncrones i asíncrones, moltes classes de trucades al sistema, etc. Com a resultat, fio és bastant difícil d'utilitzar. Té molts paràmetres i diferents combinacions dels seus valors produeixen càrregues de treball d'E/S molt diferents. Per obtenir xifres adequades per a etcd, hauríeu d'assegurar-vos que la càrrega d'escriptura de prova de fio sigui el més propera possible a la càrrega real d'etcd quan escriviu fitxers WAL.

Per tant, fio hauria de, com a mínim, crear una càrrega d'una sèrie d'escriptures seqüencials al fitxer, cada escriptura consistirà en una trucada al sistema. escriureseguit de la crida al sistema fdatasync. Les escriptures seqüencials a fio requereixen l'opció --rw=write. Perquè fio utilitzi la crida del sistema d'escriptura quan escrigui, en lloc de escriure, hauríeu d'especificar el paràmetre --ioengine=sync. Finalment, per cridar a fdatasync després de cada escriptura, heu d'afegir el paràmetre --fdatasync=1. Les altres dues opcions d'aquest exemple (--size i -bs) són específiques de l'script. A la següent secció, us mostrarem com configurar-los.

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

En aquest post, descrivim un cas real. Tenim un clúster Kubernetes v1.13 que vam supervisar amb Prometheus. etcd v3.2.24 es va allotjar en un SSD. Les mètriques Etcd van mostrar latències de fdatasync massa altes, fins i tot quan el clúster no feia res. Les mètriques eren estranyes i no sabíem realment què volien dir. El clúster estava format per màquines virtuals, calia entendre quin era el problema: en SSD físics o en la capa de virtualització. A més, sovint vam fer canvis a la configuració del maquinari i del programari, i necessitàvem una manera d'avaluar-ne els resultats. Podríem executar etcd en totes les configuracions i mirar les mètriques de Prometheus, però això és massa complicat. Estàvem buscant una manera bastant senzilla d'avaluar una configuració específica. Volíem comprovar si entenem correctament les mètriques de Prometheus d'etcd.

Però per això s'havien de resoldre dos problemes. Primer, com es veu la càrrega d'E/S que crea etcd quan escriu a WAL? Quines trucades de sistema s'utilitzen? Quina és la mida dels registres? En segon lloc, si responem aquestes preguntes, com reproduïm una càrrega de treball similar amb fio? No oblideu que fio és una eina molt flexible amb moltes opcions. Hem resolt els dos problemes amb un enfocament: utilitzant les ordres lsof и strace. lsof enumera tots els descriptors de fitxers utilitzats pel procés i els seus fitxers associats. I amb strace, podeu examinar un procés que ja s'està executant o iniciar un procés i examinar-lo. strace imprimeix totes les trucades del sistema del procés que s'està examinant (i dels seus processos fills). Això últim és molt important, ja que etcd només està adoptant un enfocament similar.

Primer vam utilitzar Strace per explorar el servidor etcd per a Kubernetes quan no hi havia càrrega al clúster. Vam veure que gairebé tots els registres WAL tenien aproximadament la mateixa mida: 2200–2400 bytes. Per tant, a l'ordre de l'inici de la publicació, vam especificar el paràmetre -bs=2300 (bs significa la mida en bytes per a cada entrada fio). Tingueu en compte que la mida de l'entrada etcd depèn de la versió d'etcd, la distribució, els valors dels paràmetres, etc., i afecta la durada de fdatasync. Si teniu un escenari similar, examineu els vostres processos etcd amb strace per esbrinar els números exactes.

Aleshores, per tenir una bona idea de què està fent el sistema de fitxers etcd, el vam començar amb strace i les opcions -ffttT. Així que vam intentar examinar els processos secundaris i registrar la sortida de cadascun d'ells en un fitxer separat, i també obtenir informes detallats sobre l'inici i la durada de cada trucada al sistema. Hem utilitzat lsof per confirmar la nostra anàlisi de la sortida de l'estrace i veure quin descriptor de fitxer s'utilitzava per a quin propòsit. Així, amb l'ajuda de Strace, es van obtenir els resultats mostrats anteriorment. Les estadístiques de temps de sincronització van confirmar que wal_fsync_duration_seconds d'etcd és coherent amb les trucades de fdatasync amb descriptors de fitxers WAL.

Vam revisar la documentació de fio i vam triar opcions per al nostre script perquè fio generis una càrrega similar a etcd. També vam comprovar les trucades al sistema i la seva durada executant fio des de Strace, de manera similar a etcd.

Hem escollit acuradament el valor del paràmetre --size per representar tota la càrrega d'E/S de fio. En el nostre cas, aquest és el nombre total de bytes escrits a l'emmagatzematge. Va resultar ser directament proporcional al nombre de trucades al sistema d'escriptura (i fdatasync). Per a un valor determinat de bs, el nombre de trucades fdatasync = mida/bs. Com que ens interessava el percentil, havíem de tenir prou mostres per estar segurs, i vam calcular que 10^4 ens serien suficients (és a dir, 22 mebibytes). Si --size és més petit, es poden produir valors atípics (per exemple, diverses trucades a fdatasync triguen més de l'habitual i afecten el percentil 99).

Prova-ho tu mateix

Us vam mostrar com utilitzar fio i veure si l'emmagatzematge és prou ràpid perquè etcd funcioni bé. Ara podeu provar-ho vosaltres mateixos utilitzant, per exemple, màquines virtuals amb emmagatzematge SSD IBM Cloud.

Font: www.habr.com