Get best of the week

etcd 3.4.3: investigaci贸n de seguridad y confiabilidad de almacenamiento

Nota perev. : El contenido de este art铆culo no es del todo t铆pico de nuestro blog. Sin embargo, como mucha gente sabe, etcd se encuentra en el coraz贸n de Kubernetes, por lo que este estudio, realizado por un consultor independiente en el campo de la confiabilidad, result贸 ser interesante entre los ingenieros que operan este sistema. Adem谩s, es interesante en el contexto de c贸mo los proyectos de c贸digo abierto que ya han demostrado su eficacia en la producci贸n se est谩n mejorando incluso a un nivel tan "bajo".



La b贸veda de valor-clave (KV), etc. es una base de datos distribuida basada en el algoritmo de consenso Raft. En un an谩lisis realizado en 2014 , encontramos que etcd 0.4.1 se vio afectado por las llamadas lecturas obsoletas por defecto(lea las operaciones que devuelven un valor antiguo e irrelevante debido a un retraso en la sincronizaci贸n - aprox. transl.) . Decidimos volver a etcd (esta vez, a la versi贸n 3.4.3) para evaluar nuevamente en detalle su potencial en el campo de la confiabilidad y la seguridad.

Hemos encontrado que la operaci贸n con pares de "clave-valor" estrictamente serializable y que los procesos del observador (relojes) entregados a cada cambio en la clave de orden. Sin embargo, los bloqueos en etcd son fundamentalmente inseguros, y los riesgos asociados con ellos se ven exacerbados por un error, como resultado de lo cual no se verifica la relevancia del arrendamiento despu茅s de esperar el bloqueo. Puede leer el comentario de los desarrolladores de etcd en nuestro informe en el blog del proyecto .

El estudio fue patrocinado por la Cloud Native Computing Foundation (CNCF), parte de The Linux Foundation. Se llev贸 a cabo en pleno cumplimiento de las pol铆ticas 茅ticas de Jepsen .

1. Antecedentes


El repositorio de Etc KV es un sistema distribuido dise帽ado para ser utilizado como base para la coordinaci贸n. Al igual que Zookeeper y Consul , etcd almacena peque帽as cantidades de estados raramente actualizados ( por defecto, hasta 8 GB ) en forma de un mapa de valores clave y proporciona lecturas, escrituras y microtransacciones estrictamente serializables en todo el almac茅n de datos, as铆 como primitivas de coordinaci贸n como bloqueos , seguimiento (relojes) y selecci贸n de l铆deres. Muchos sistemas distribuidos, como Kubernetes y OpenStack , usan etcd para almacenar metadatos de cl煤ster, coordinar vistas coordinadas de datos, elegir un l铆der, etc.

En 2014, ya realizamos una evaluaci贸n de etcd 0.4.1 . Luego descubrimos que, por defecto, es propenso a lecturas obsoletas debido a la optimizaci贸n. Si bien el trabajo sobre los principios de Raft discute la necesidad de dividir las operaciones de lectura en subprocesos y pasarlos a trav茅s de un sistema de consenso para garantizar la viabilidad, etcd lee en cualquier l铆der local sin verificar un estado m谩s actual en el l铆der m谩s nuevo. El equipo de desarrollo de etcd implement贸 el indicador de qu贸rum opcional , y en la API de la versi贸n 3.0 de etcd , la linealizaci贸n para todas las operaciones, excepto las operaciones de seguimiento, apareci贸 de forma predeterminada . La API etcd 3.0 se concentra en un mapa plano KV donde las claves y los valores son opacos

( opacos ) conjuntos de bytes. Usando consultas de rango, puede simular claves jer谩rquicas. Los usuarios pueden leer, escribir y eliminar claves, as铆 como monitorear el flujo de actualizaciones para una sola clave o rango de claves. El kit de herramientas etcd se complementa con arrendamientos (objetos variables con una vida 煤til limitada, que se mantienen en estado activo mediante solicitudes de latidos del cliente), bloqueos (objetos con nombre dedicados vinculados a arrendamientos) y la elecci贸n de l铆deres.

En la versi贸n 3.0, etcd ofrece una API transaccional limitadapara operaciones at贸micas con muchas claves. En este modelo, una transacci贸n es una expresi贸n condicional con un predicado, una rama verdadera y una rama falsa. Un predicado puede ser una conjunci贸n de varias comparaciones clave: igualdad o diversas desigualdades, de acuerdo con las versiones de una clave, revisi贸n global, etc., o el valor clave actual. Las ramas verdaderas y falsas pueden incluir m煤ltiples operaciones de lectura y escritura; todos ellos se aplican at贸micamente dependiendo del resultado de la estimaci贸n de predicados.

1.1 Garant铆as de consistencia en la documentaci贸n


A partir de octubre de 2019, la documentaci贸n de etcd para la API establece que "todas las llamadas a la API demuestran coherencia constante, la forma m谩s s贸lida de garant铆a de coherencia disponible en los sistemas distribuidos". Esto no es as铆: la consistencia constante es estrictamente m谩s d茅bil que la linealizaci贸n, y la linealizaci贸n es definitivamente alcanzable en sistemas distribuidos. Adem谩s, la documentaci贸n establece que "durante la operaci贸n de lectura, etcd no garantiza la transferencia del valor [m谩s reciente (medido por el reloj externo despu茅s de la finalizaci贸n de la consulta)] disponible en cualquier representante del cl煤ster" Esta tambi茅n es una afirmaci贸n demasiado conservadora: si etcd proporciona linealizaci贸n, las operaciones de lectura siempre est谩n asociadas con el estado comprometido m谩s reciente en orden de linealizaci贸n.

La documentaci贸n tambi茅n afirma que etcd garantiza el aislamiento serializable: todas las operaciones (incluso las que afectan a varias teclas) se realizan en un orden general. Los autores describen el aislamiento serializable como "el nivel de aislamiento m谩s fuerte disponible en sistemas distribuidos". Esto (dependiendo de lo que quiere decir con el "nivel de aislamiento") tampoco es cierto; la serializaci贸n estricta es m谩s fuerte que la simple serializaci贸n, mientras que la primera tambi茅n se puede lograr en sistemas distribuidos.

La documentaci贸n dice que todas las operaciones (excepto el seguimiento) en etcd son linealizables por defecto. En este caso, la linealizaci贸n se define como la consistencia con relojes globales d茅bilmente sincronizados. Cabe se帽alar que dicha definici贸n no solo es incompatible con la definici贸n de linealizaci贸nHerlihy & Wing, pero tambi茅n implica una violaci贸n de la causalidad: los nodos con horas de atenci贸n intentar谩n leer los resultados de las operaciones que ni siquiera han comenzado. Suponemos que etcd todav铆a no es una m谩quina del tiempo, y dado que se basa en el algoritmo Raft, se debe aplicar la definici贸n generalmente aceptada de linealizaci贸n.

Dado que las operaciones de KV en etcd son serializables y linealizables, creemos que, de hecho, etcd proporciona una serializaci贸n estricta por defecto . Esto tiene sentido, ya que todas las teclas, etcd est谩n en una sola m谩quina de estado, y Raft proporciona un pedido completo de todas las operaciones en esta m谩quina de estado. De hecho, todo el conjunto de datos etcd es un 煤nico objeto linealizable.

Bandera opcional serializable bajaEl nivel de operaciones de lectura de consistencia serializable estricta a regular, que permite la lectura de un estado comprometido desactualizado. Tenga en cuenta que la bandera serializableno afecta la serializaci贸n de la historia; Las operaciones de KV, etc. son serializables en todos los casos.

2. Prueba de desarrollo


Para crear un conjunto de pruebas, utilizamos la biblioteca Jepsen adecuada. Se analiz贸 la versi贸n, etcd 3.4.3 (la 煤ltima a partir de octubre de 19), trabajando en cl煤steres de Debian Stretch que constan de 5 nodos. Hemos implementado una serie de fallas en estos grupos, incluyendo particiones de red, aislando nodos individuales, dividiendo el grupo en una mayor铆a y una minor铆a, as铆 como particiones no transitivas con una mayor铆a superpuesta. Ellos "cayeron" y suspendieron subconjuntos aleatorios de nodos, y tambi茅n desactivaron deliberadamente a los l铆deres. Se introdujeron distorsiones temporales de hasta varios cientos de segundos, tanto a intervalos de varios segundos como a milisegundos ("parpadeo" r谩pido). Dado que etcd admite el cambio din谩mico de la cantidad de componentes, agregamos y eliminamos nodos al azar durante las pruebas.

Las cargas de prueba incluyeron registros, conjuntos y pruebas transaccionales para verificar operaciones en KV, as铆 como cargas especializadas para cerraduras y relojes.

2.1 Registros


Para evaluar la confiabilidad de etcd durante las operaciones KV, se desarroll贸 una prueba de registro durante la cual se realizaron operaciones aleatorias de lectura, escritura, comparaci贸n y configuraci贸n en las teclas de la unidad. Los resultados se evaluaron utilizando la herramienta de linealizaci贸n de Knossos utilizando el modelo de registro de comparaci贸n / instalaci贸n y la informaci贸n de versi贸n.

2.2 Conjuntos


Para cuantificar las lecturas obsoletas, se desarroll贸 una prueba que utilizaba una transacci贸n de comparar y establecer para leer un conjunto de enteros de una sola clave y luego agregar un valor a este conjunto. Durante la prueba, tambi茅n realizamos una lectura paralela de todo el conjunto. Despu茅s de completar la prueba, los resultados se analizaron para detectar casos en los que el elemento, que se sab铆a que estaba presente en el conjunto, estaba ausente en los resultados de lectura. Estos casos se usaron para cuantificar las lecturas obsoletas y las actualizaciones perdidas.

2.3 Anexar prueba


Para verificar la serializaci贸n estricta, se desarroll贸 una prueba de adici贸n durante la cual las transacciones se le铆an en paralelo y se agregaban valores a las listas que constaban de conjuntos 煤nicos de enteros. Cada lista se almacen贸 en una clave etcd, y se hicieron adiciones dentro de cada transacci贸n, leyendo cada clave que necesitaba ser cambiada en una transacci贸n, y luego estas claves se escribieron y las lecturas se realizaron en la segunda transacci贸n, que estaba protegidapara asegurarse de que no haya cambiado ninguna clave grabada desde la primera lectura. Al final de la prueba, trazamos la relaci贸n entre las transacciones en funci贸n de la prioridad en tiempo real y la relaci贸n de las operaciones de lectura y adici贸n. La verificaci贸n de este gr谩fico en busca de bucles permiti贸 determinar si las operaciones eran estrictamente serializables.

Si bien etcd evita que las transacciones escriban la misma clave varias veces, puede crear transacciones con hasta un registro por clave. Tambi茅n nos aseguramos de que las operaciones de lectura dentro de la misma transacci贸n reflejaran operaciones de escritura anteriores de la misma transacci贸n.

2.4 cerraduras


Como servicio de coordinaci贸n, etcd promete soporte integrado para bloqueo distribuido . Investigamos estas cerraduras de dos maneras. Al principio, se generaron solicitudes aleatorias de bloqueo y desbloqueo , recibiendo un contrato de arrendamiento para cada bloqueo y dej谩ndolo abierto utilizando el cliente incorporado, etc. en el cliente Java keepalivehasta su lanzamiento . Probamos los resultados con Knossos para ver si forman una implementaci贸n linealizada del servicio de bloqueo.

Para una prueba m谩s pr谩ctica (y para cuantificar la frecuencia de fallas de bloqueo), utilizamos bloqueos y etcd para organizar la exclusi贸n mutua al realizar actualizaciones en el conjunto en memoriay busqu茅 actualizaciones perdidas en este conjunto. Esta prueba nos permiti贸 confirmar directamente si los sistemas que usan etcd como mutex pueden actualizar de manera segura el estado interno.

La tercera versi贸n de la prueba de bloqueo involucr贸 guardias en la clave de arrendamiento para modificar el conjunto almacenado en etcd.

2.5 Seguimiento


Para verificar que los relojes proporcionan informaci贸n sobre cada actualizaci贸n de clave, se cre贸 una clave como parte de la prueba y se asignaron ciegamente valores enteros 煤nicos. Mientras tanto, los clientes compartieron esta clave durante varios segundos a la vez. Cada vez despu茅s del inicio del reloj, el cliente comenz贸 con la revisi贸n en la que se hab铆a detenido la 煤ltima vez.

Al final de este proceso, nos aseguramos de que cada cliente observara la misma secuencia de cambios clave.

3. Resultados


3.1 Seguimiento desde la 0陋 revisi贸n


Al rastrear una clave, los clientes pueden especificar una revisi贸n inicial , que es "una revisi贸n opcional con la que se inicia el rastreo (inclusive)". Si el usuario desea ver cada operaci贸n con una determinada clave, puede especificar la primera revisi贸n de etcd. 驴Qu茅 es esta auditor铆a? El modelo de datos y el glosario no proporcionan una respuesta a esta pregunta; las revisiones se describen como contadores de 64 bits que aumentan monot贸nicamente, pero no est谩 claro si etcd comienza desde 0 o 1. Es razonable suponer que la cuenta regresiva es desde cero (por si acaso).

Por desgracia, esto est谩 mal. Al solicitar la revisi贸n n煤mero 0, etcd comienza a transmitir actualizaciones, comenzando con la revisi贸n actual en el servidor m谩s una, pero no con el primero. La solicitud de la primera revisi贸n da todos los cambios. Este comportamiento no est谩 documentado en ninguna parte .

Creemos que, en la pr谩ctica, es poco probable que esta sutileza provoque problemas en la producci贸n, ya que la mayor铆a de los cl煤steres no persisten en la primera revisi贸n. Adem谩s, etcd comprime la historia de todos modos con el tiempo, por lo que en aplicaciones del mundo real, lo m谩s probable, en cualquier caso, no requiere leer todas las versiones, comenzando con la primera revisi贸n. Tal comportamiento est谩 justificado, pero no da帽ar铆a la descripci贸n correspondiente en la documentaci贸n.

3.2 Cerraduras m铆ticas


La documentaci贸n de la API para los bloqueos establece que una clave bloqueada "se puede usar junto con las transacciones para garantizar que las actualizaciones en etc. se produzcan solo cuando el bloqueo sea de su propiedad". Es extra帽o, pero no proporciona ninguna garant铆a para las cerraduras en s铆 mismas y su prop贸sito no se explica.

Sin embargo, en otros materiales, los mantenedores, etc., a煤n comparten informaci贸n sobre el uso de cerraduras. Por ejemplo, el anuncio de lanzamiento de etcd 3.2 describe una aplicaci贸n etcdctlpara bloquear cambios en el intercambio de archivos en un disco. Adem谩s, en un problema en GitHub con una pregunta sobre el prop贸sito espec铆fico de los bloqueos, uno de los desarrolladores de etcd respondi贸 lo siguiente:

etcd , ( ) , ( etcd), - :

  1. etcd;
  2. - ( , etcd);
  3. .

Solo se da un ejemplo de este tipo etcdctl: se us贸 una cerradura para proteger al equipo put, pero no vincul贸 la clave de la cerradura a la actualizaci贸n.

Por desgracia, esto no es seguro porque permite que varios clientes mantengan simult谩neamente el mismo bloqueo. El problema se ve agravado por la suspensi贸n de procesos, bloqueos de red o particiones, sin embargo, tambi茅n puede ocurrir en grupos completamente sanos sin fallas externas. Por ejemplo, en esta ejecuci贸n de prueba, el proceso n煤mero 3 establece con 茅xito el bloqueo, y el proceso 1 obtiene el mismo bloqueo en paralelo incluso antes de que el proceso 3 tenga la oportunidad de eliminarlo:



La violaci贸n de mutex fue m谩s notable en los contratos de arrendamiento con TTL cortos: los TTL de 1, 2 y 3 segundos no pudieron proporcionar una exclusi贸n mutua despu茅s de solo unos minutos de prueba (incluso en grupos sanos). Las suspensiones de proceso y las particiones de red provocaron problemas a煤n m谩s r谩pido.

En una de nuestras variantes de prueba de bloqueo, se utilizaron mutexes etcd para proteger las actualizaciones conjuntas de un conjunto de enteros (como sugiere la documentaci贸n, etcd). Cada actualizaci贸n lee el valor de muestra actual en memoria y, despu茅s de aproximadamente un segundo, vuelve a escribir esta colecci贸n con la adici贸n de un elemento 煤nico. Con arrendamientos con un TTL de dos segundos, cinco procesos paralelos y una pausa de proceso cada cinco segundos, pudimos causar una p茅rdida constante de aproximadamente el 18% de las actualizaciones confirmadas.

Este problema fue exacerbado por el mecanismo de bloqueo interno en etcd. Si el cliente esper贸 a que el otro cliente lo desbloqueara, perdi贸 su contrato de arrendamiento y, despu茅s de eso, se liber贸 el bloqueo, el servidor no verific贸 dos veces el contrato de arrendamiento para asegurarse de que todav铆a es v谩lido antes de informarle al cliente que el bloqueo ahora est谩 detr谩s de 茅l.

La inclusi贸n de una verificaci贸n de arrendamiento adicional, as铆 como la selecci贸n de TTL m谩s largos y el establecimiento cuidadoso de los tiempos de espera de las elecciones , reducir谩n la frecuencia de este problema. Sin embargo, las violaciones de mutex no se pueden eliminar por completo, ya que los bloqueos distribuidos son fundamentalmente inseguros en los sistemas asincr贸nicos. El Dr. Martin Kleppmann describe convincentemente esto en su art铆culo.Sobre cerraduras distribuidas. Seg煤n 茅l, los servicios de bloqueo deben sacrificar la correcci贸n para mantener la viabilidad en los sistemas as铆ncronos: si el proceso falla mientras se controla el bloqueo, el servicio de bloqueo necesita alguna forma de forzar el desbloqueo. Sin embargo, si el proceso en realidad no cay贸, sino que simplemente se ejecuta lentamente o no est谩 disponible temporalmente, desbloquearlo puede llevar a que se mantenga en varios lugares al mismo tiempo.

Pero incluso si el servicio de bloqueo distribuido usa, por ejemplo, alg煤n tipo de detector de falla m谩gica y puede garantizar la exclusi贸n mutua, en el caso de alg煤n recurso no local, su uso seguir谩 siendo inseguro. Suponga que el proceso A env铆a un mensaje a la base de datos D mientras mantiene un bloqueo. Despu茅s de eso, el proceso A se bloquea y el proceso B recibe un bloqueo y tambi茅n env铆a un mensaje a la base D. El problema es que un mensaje del proceso A (debido a la asincron铆a) puede aparecer despu茅s de un mensaje del proceso B, violando la excepci贸n mutua que se supon铆a que deb铆a proporcionar el bloqueo. .

Para evitar este problema, es necesario confiar en el hecho de que el propio sistema de almacenamiento admitir谩 la correcci贸n de las transacciones o, si el servicio de bloqueo proporciona dicho mecanismo, utiliceToken de " cercado" que se incluir谩 en todas las operaciones realizadas por el titular de la cerradura. Asegurar谩 que no se produzcan operaciones repentinas del titular de la cerradura anterior entre las operaciones del propietario de la cerradura actual. Por ejemplo, en el servicio de bloqueo Chubby de Google , estos tokens se llaman secuenciadores . En etcd, puede usar la revisi贸n de la clave de bloqueo como un token de bloqueo ordenado globalmente.

Adem谩s, las teclas de bloqueo en etcd se pueden usar para proteger las actualizaciones transaccionales en el propio etcd. Verificaci贸n de la versi贸n de la clave de bloqueo como parte de la transacci贸n, los usuarios pueden evitar una transacci贸n si el bloqueo ya no se mantiene (es decir, la versi贸n de la clave de bloqueo es mayor que cero). En nuestras pruebas, este enfoque nos permiti贸 aislar con 茅xito las operaciones de lectura-modificaci贸n-escritura en las que la escritura era la 煤nica transacci贸n protegida por bloqueo. Este enfoque proporciona un aislamiento similar a los tokens de barrera, pero (como los tokens de barrera) no garantiza la atomicidad: un proceso puede bloquearse o perder un mutex durante una actualizaci贸n que consta de muchas operaciones, dejando a etcd en un estado l贸gicamente inconsistente.

Los resultados del trabajo en los temas del proyecto:

4. Discusi贸n


En nuestras pruebas, etc. 3.4.3 estuvo a la altura de las expectativas con respecto a las operaciones de KV: observamos una consistencia estrictamente serializable de lectura, escritura e incluso transacciones de m煤ltiples claves, a pesar de la suspensi贸n de procesos, bloqueos, manipulaci贸n del reloj y la red, as铆 como un cambio en el n煤mero de miembros del cl煤ster . El comportamiento estrictamente serializable se implement贸 por defecto en las operaciones KV; El rendimiento de las lecturas con el serializableconjunto de indicadores condujo a la aparici贸n de lecturas obsoletas (como se describe en la documentaci贸n).

El monitor (relojes) funciona correctamente, al menos en las teclas individuales. Hasta que la compresi贸n del historial destruy贸 los datos antiguos, el reloj emiti贸 con 茅xito cada actualizaci贸n clave.

Sin embargo, result贸 que los bloqueos en etcd (como todos los bloqueos distribuidos) no proporcionan exclusi贸n mutua. Diferentes procesos pueden mantener la cerradura al mismo tiempo, incluso en cl煤steres saludables con relojes perfectamente sincronizados. La documentaci贸n con la API de bloqueo no dec铆a nada al respecto, y los ejemplos de bloqueos presentados no eran seguros. Sin embargo, algunos de los problemas con los bloqueos tuvieron que desaparecer despu茅s del lanzamiento de este parche .

Como resultado de nuestra colaboraci贸n, el equipo de etcd realiz贸 varias modificaciones a la documentaci贸n (ya han aparecido en GitHub y se publicar谩n en futuras versiones del sitio web del proyecto). La p谩gina API de garant铆as de GitHub ahora establece que, por defecto, etcd es estrictamente serializabley se ha eliminado la afirmaci贸n de que serial y serializable son los niveles m谩s fuertes de consistencia disponibles en los sistemas distribuidos. Con respecto a las revisiones, ahora se indica que el inicio debe ser desde la unidad (1) , aunque la documentaci贸n de la API todav铆a no dice que un intento de comenzar desde la 0陋 revisi贸n dar谩 como resultado "eventos de salida que ocurrieron despu茅s de la revisi贸n actual m谩s 1" en lugar del esperado "despacho de todos los eventos". La documentaci贸n de los problemas de seguridad de la cerradura est谩 en desarrollo .

Algunos cambios en la documentaci贸n, como describir el comportamiento especial de etcd al intentar leer, comenzando con una revisi贸n cero, a煤n requieren atenci贸n.

Como de costumbre, enfatizamos que Jepsen prefiere un enfoque experimental para la verificaci贸n de seguridad: podemos confirmar la presencia de errores, pero no su ausencia. Se est谩n haciendo esfuerzos considerables para encontrar problemas, pero no podemos probar la correcci贸n general de etcd.

4.1 Recomendaciones


Si usa bloqueos en etcd, piense si los necesita por seguridad o simplemente para aumentar el rendimiento limitando probabil铆sticamente la concurrencia. Los bloqueos Etcd se pueden usar para aumentar el rendimiento, pero usarlos por motivos de seguridad puede ser arriesgado.

En particular, si usa el bloqueo etcd para proteger un recurso compartido como un archivo, base de datos o servicio, este recurso deber铆a garantizar la seguridad sin bloqueo. Una forma de lograr esto es usar una ficha de bombardeo mon贸tono . Puede ser, por ejemplo, una revisi贸n de etcd asociada con la clave de bloqueo retenida actual. El recurso compartido debe garantizar que una vez que el cliente haya utilizado el tokenypara realizar alguna operaci贸n, cualquier operaci贸n con un token x < yser谩 rechazada. Este enfoque no garantiza la atomicidad, pero s铆 garantiza que las operaciones dentro del marco de bloqueo se realicen en orden y no de forma intermitente.

Sospechamos que es poco probable que los usuarios comunes encuentren este problema. Pero si todav铆a conf铆a en leer todos los cambios de etcd, comenzando con la primera revisi贸n, recuerde que necesita pasar 1, no 0. como par谩metro. Nuestros experimentos muestran que una revisi贸n cero en este caso significa "revisi贸n actual", no "Lo m谩s temprano".

Finalmente, los bloqueos y etcd (como todos los bloqueos distribuidos) enga帽an a los usuarios: pueden querer usarlos como bloqueos normales, pero se sorprender谩n mucho cuando se den cuenta de que estos bloqueos no proporcionan exclusi贸n mutua. La documentaci贸n de la API, las publicaciones de blog, los problemas en GitHub no dicen nada sobre este riesgo. Recomendamos que incluya informaci贸n en la documentaci贸n de etcd que los bloqueos no proporcionan exclusi贸n mutua y proporcione ejemplos de uso de tokens de barrera para actualizar el estado de los recursos compartidos en lugar de ejemplos que podr铆an conducir a la p茅rdida de actualizaciones.

4.2 Planes adicionales


El proyecto etcd se ha considerado estable durante varios a帽os: el algoritmo Raft basado en 茅l ha funcionado bien, la API para operaciones KV es simple y directa. Aunque algunas caracter铆sticas adicionales han recibido recientemente una nueva API, su sem谩ntica es relativamente simple. Creemos que ya hemos estudiado suficientes comandos b谩sicos como gety put, transacciones, bloqueo y seguimiento. Sin embargo, hay otras pruebas que deben realizarse.

Por el momento, no hemos realizado una evaluaci贸n suficientemente detallada de las eliminaciones.: Puede haber casos l铆mite asociados con versiones y revisiones, cuando los objetos se crean y eliminan constantemente. En futuras pruebas, pretendemos someter las operaciones de eliminaci贸n a un estudio m谩s cuidadoso. Tampoco probamos las consultas de rango ni las operaciones de seguimiento con varias claves, aunque sospechamos que su sem谩ntica es similar a las operaciones con claves 煤nicas.

En las pruebas, utilizamos la suspensi贸n de procesos, bloqueos, manipulaciones con el reloj, la red se dividi贸 y la composici贸n del cl煤ster cambi贸; Entre bastidores hab铆a problemas como da帽os en el disco y otras fallas bizantinas a nivel de un nodo. Estas oportunidades pueden explorarse en futuras investigaciones.

El trabajo fue apoyado por la Cloud Native Computing Foundation., parte de The Linux Foundation , y cumple con las pol铆ticas 茅ticas de Jepsen . Queremos agradecer al equipo de etcd por su ayuda, y a los siguientes representantes en particular: Chris Aniszczyk, Gyuho Lee, Xiang Li, Hitoshi Mitake, Jingyi Hu y Brandon Philips.

PD del traductor


Lea tambi茅n en nuestro blog:

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles