principio de arquitectura etcd

Tabla de contenido

La terminología central de etcd

• Raft : el algoritmo utilizado por etcd para garantizar una sólida coherencia de los datos del sistema distribuido.
• Nodo : una instancia de la máquina de estado Raft.
• Miembro : una instancia de etcd, que administra un nodo y puede proporcionar servicios para las solicitudes de los clientes.
• Clúster : un clúster etcd que puede trabajar en conjunto está formado por varios miembros.
• Peer : el nombre de otro miembro en el mismo clúster etcd.
• Cliente : el cliente que envía solicitudes HTTP al clúster etcd.
• WAL : registro de escritura anticipada, el formato de registro utilizado por etcd para el almacenamiento persistente.
• Instantánea : instantánea configurada por etcd para evitar demasiados archivos WAL y almacenar el estado de los datos de etcd.
• Entrada : una entrada en el registro en el algoritmo Raft.
• Proxy : un modo de etcd que proporciona servicios de proxy inverso para clústeres de etcd.
• Líder : El nodo que procesa todos los envíos de datos generados por elección en el algoritmo Raft.
• Seguidor : el nodo que falla en la elección en el algoritmo Raft se utiliza como nodo subordinado para proporcionar una sólida garantía de coherencia para el algoritmo.
• Candidato : Cuando el seguidor no recibe el latido del líder por más de un cierto período de tiempo (se considera que el líder ha funcionado mal), cambiará a candidato y comenzará la elección.
• Término : El momento en que un nodo se convierte en el líder de la próxima elección se denomina término.
• Voto : Un voto en la elección.
• Índice : número de elemento de datos. En Balsa, utilice Término e Índice para localizar datos.
• Confirmación : una confirmación, los datos persistentes se escriben en el registro.
• Proponer : Una propuesta a la petición de que la mayoría de los nodos de acuerdo a datos de escritura.

arquitectura de software etcd

• Servidor HTTP : acepta solicitudes de API de clientes y solicitudes de sincronización e información de latidos de otros nodos etcd.

• Tienda : se utiliza para procesar varias funciones soportadas por etcd, incluyendo indexación de datos, cambios de estado de nodo, monitoreo y retroalimentación, procesamiento y ejecución de eventos, etc. Es la implementación específica de la mayoría de las funciones API proporcionadas por los usuarios por etcd.

• Raft : La implementación específica del algoritmo de coherencia fuerte es el algoritmo central de etcd.

• WAL (Write Ahead Log) : Es el método de almacenamiento de datos de etcd. Etcd almacenará el estado de todos los datos y el índice del nodo en la memoria. Además, etcd también realizará el almacenamiento persistente a través de WAL. En WAL, todos los datos se registrarán por adelantado antes del envío.

  • Instantánea es una instantánea de estado para evitar un exceso de datos;
  • La entrada representa el contenido de registro específico almacenado.

Por lo general, se envía la solicitud de un usuario y se reenvía a la tienda a través del servidor HTTP para el procesamiento de transacciones específicas. Si implica la modificación de datos del nodo, se entregará al módulo Raft para cambios de estado y registros de registro, y luego se sincronizará con otros El nodo etcd confirma el envío de datos y finalmente envía los datos y se sincroniza nuevamente.

Balsa

Para la nueva versión de etcd, el paquete Raft es la implementación específica del algoritmo de consenso Raft.

¿Qué significa un término en balsa?

En el algoritmo Raft, en términos de tiempo, un término (término) es desde el comienzo de una elección hasta el comienzo de la siguiente. Desde un punto de vista funcional, si el seguidor no recibe la información del latido del líder, terminará el período actual, se convertirá en candidato y luego iniciará una campaña, y luego ayudará a la recuperación del clúster cuando el líder falle. Cuando se inicia la votación para las elecciones, los nodos con un valor de término pequeño no tendrán éxito. Si el Clúster no falla, el Término continuará indefinidamente. Además, los conflictos en la votación también pueden entrar directamente en las próximas elecciones.

¿Cómo cambia la máquina de estado Raft?

Cuando Raft comenzó a ejecutarse, Node ingresaba al estado de seguidor de forma predeterminada, esperando que el líder enviara información de latido. Si se agota el tiempo de espera, el estado cambiará de Seguidor a Candidato y entrará en la siguiente ronda de Término para iniciar la elección. Cuando se reciba el voto del "nodo mayoritario" del Clúster, el Nodo se cambiará a Líder. El líder puede tener fallas en la red, lo que hace que otros nodos voten para convertirse en el líder del nuevo término. En este momento, el antiguo líder original se cambiará a Seguidor. El candidato cambiará a Seguidor si descubre que un líder ha sido elegido con éxito mientras espera que otros nodos voten.

¿Cómo asegurar que el líder sea elegido en el menor tiempo posible y prevenir conflictos en las elecciones?

En la imagen de la máquina de estado de la balsa, puede ver que en el estado Candidato, hay un tiempo de espera, donde el tiempo de espera es un valor aleatorio, es decir, después de que cada Nodo se convierte en un Candidato, el tiempo de espera es el momento de iniciar una nueva ronda de elecciones. Cada uno es diferente, habrá una diferencia horaria. Dentro de la diferencia de tiempo, si la información del candidato recibida por Candidate1 es mayor que el valor de término de la información iniciada por el candidato (es decir, la otra parte es una nueva ronda de Término), y el candidato 2 que quiere convertirse en el líder en la nueva ronda contiene todos los datos enviados, entonces Candidate1 Votará por Candidate2. Esto asegura que haya una pequeña probabilidad de que haya conflictos electorales.

¿Cómo evitar que otros Candidatos inicien una votación para convertirse en líder cuando faltan algunos datos?

En el mecanismo de elección de Raft, se usa un valor aleatorio para determinar los tiempos de espera. El primer nodo que expira aumentará el número de Término para iniciar una nueva ronda de votación. Generalmente, otros nodos votarán cuando reciban el aviso de elección. Sin embargo, si los datos enviados guardados por el Nodo que inició la elección están incompletos en el Término anterior, Node se negará a votar por ellos. A través de este mecanismo, es posible evitar que el nodo que perdió los datos se convierta en el líder.

¿Qué pasa si un nodo de Raft se cae?

Normalmente, si el seguidor se cae, si el número de nodos disponibles restantes supera la mitad, el clúster puede funcionar normalmente sin ningún impacto. Si el líder está caído, Seguidor no recibirá el latido del corazón ni las horas extra, iniciará una campaña para obtener votos, se convertirá en una nueva ronda de Líder de mandato y continuará brindando servicios para el Clúster.

Cabe señalar que actualmente, etcd no tiene ningún mecanismo para cambiar automáticamente las Instancias (número total de nodos) de todo el Cluster, es decir: si no hay una llamada artificial a la API, el Nodo después del tiempo de inactividad de etcd aún se cuenta como el número total de nodos, cualquier solicitud El número de votos necesarios para confirmar es más de la mitad de este total.

¿Por qué el algoritmo Raft no necesita considerar el problema de los generales bizantinos al determinar el número de nodos disponibles?

En el problema bizantino, una arquitectura distribuida que permite que n nodos estén inactivos y aún proporciona servicios normales requiere un número total de nodos de 3n + 1. Raft solo necesita 2n + 1. La razón principal es que existe fraude de datos en el problema de los generales bizantinos, mientras que etcd asume que todos los nodos son honestos. Antes de la elección, etcd debe indicar a los otros nodos su propio número de período y el valor del índice al final de la ronda anterior del período. Estos datos son precisos y otros nodos pueden decidir si votar en función de estos valores. Además, etcd restringe estrictamente el flujo de datos de líder a seguidor para garantizar que los datos sean consistentes y estén libres de errores.

¿De qué nodo del clúster lee y escribe datos el cliente?

Para garantizar una sólida coherencia de los datos, el flujo de datos en etcd Cluster es de líder a seguidor, es decir, todos los datos de los seguidores deben ser coherentes con el líder; si son inconsistentes, se sobrescribirán.

Es decir, todas las solicitudes de los usuarios para actualizar los datos son obtenidas primero por Leader, y luego se notifica a otros nodos para que también se actualicen, y cuando la "mayoría de los nodos" retroalimenta, los datos se enviarán a la vez. Un elemento de datos enviado es el elemento de datos que Raft realmente ha almacenado de manera estable y ya no se modificará. Finalmente, los datos enviados se sincronizarán con otros Seguidores. Debido a que cada nodo tiene una copia de seguridad precisa de los datos enviados por Raft (el peor de los casos es que los datos enviados no se han sincronizado por completo), cualquier nodo puede procesar la solicitud de lectura.

De hecho, los usuarios pueden leer y escribir en cualquier nodo de etcd Cluster:

• Leer : puede leer desde cualquier nodo porque los datos guardados por cada nodo son muy consistentes.
• Escribir : etcd Cluster elegirá primero al líder. Si la solicitud de escritura proviene del líder, se puede escribir directamente y luego el líder distribuirá la escritura a todos los seguidores; si la solicitud de escritura proviene de otros nodos seguidores, la solicitud de escritura se reenviará a El nodo Leader lo escribe el nodo Leader y luego se distribuye a todos los demás nodos del clúster.

¿Cómo garantizar la coherencia de los datos?

etcd utiliza el protocolo Raft para mantener la coherencia del estado de cada nodo en el clúster. En pocas palabras, etcd Cluster es un sistema distribuido. Múltiples nodos se comunican entre sí para formar un servicio externo general. Cada Nodo almacena datos completos y el protocolo Raft asegura que los datos mantenidos por cada Nodo sean consistentes.

Cada nodo en etcd Cluster mantiene una máquina de estado y, en cualquier momento, hay como máximo un nodo maestro efectivo en el clúster, a saber: Nodo líder. El Líder maneja todas las operaciones de escritura desde el cliente y el protocolo Raft asegura que los cambios en la máquina de estado por la operación de escritura se sincronizarán de manera confiable con otros Nodos Seguidores.

¿Cómo elegir el nodo líder?

Suponga que hay 3 nodos en etcd Cluster, y no hay ningún líder elegido cuando se inicia el Cluster. En este momento, el algoritmo Raft utiliza un temporizador aleatorio para inicializar el proceso de elección de líder. Por ejemplo, los 3 nodos anteriores están ejecutando el temporizador (la duración de cada temporizador es aleatoria), y el nodo 1 es el primero en completar el temporizador, y luego enviará una solicitud para convertirse en líder a los otros dos nodos, y los otros nodos recibirán la solicitud. Posteriormente, responderá con una votación y el primer nodo será elegido como líder.

Después de convertirse en líder, el nodo enviará notificaciones a otros nodos a intervalos regulares para asegurarse de que sigue siendo el líder. En algunos casos, cuando los seguidores no reciben la notificación del líder, por ejemplo, el nodo líder está inactivo o pierde la conexión, otros nodos repetirán el proceso de elección anterior y reelegirán a un nuevo líder.

¿Cómo juzgar si la escritura es exitosa?

etcd cree que después de que la solicitud de escritura es procesada por el líder y distribuida a otros "nodos mayoritarios", es una escritura exitosa. La fórmula para calcular el número de "nodos mayoritarios" es Quórum = N / 2 + 1, donde N es el número de puntos de resumen. En otras palabras, etcd escribe datos simultáneamente en todos los nodos como una sola escritura, pero escribe en los "nodos mayoritarios".

¿Cómo determinar la cantidad de nodos en etcd Cluster?

El lado izquierdo de la figura anterior muestra la relación del quórum (número de quórums) correspondiente a las instancias (número total de nodos) en el clúster. Instances-Quorom obtiene el número de nodos tolerantes a fallas (nodos que pueden tolerar fallas) en el clúster.

Por lo tanto, la cantidad mínima recomendada de nodos en etcd Cluster es 3, porque la cantidad de nodos tolerantes a fallas para 1 y 2 Instancias es 0. Una vez que un nodo deja de funcionar, todo el clúster no funcionará correctamente.

Además, cuando necesitamos determinar el número de instancias en etcd Cluster, recomendamos encarecidamente un número impar de nodos, como 3, 5, 7, ..., porque la tolerancia a fallos de un clúster de 6 nodos no es mejor que la de 5 nodos. , Su número de nodos tolerantes a fallas es el mismo. Una vez que el número de nodos tolerantes a fallas excede 2, debido a que el número de nodos de quórum es menor que 4, todo el clúster deja de estar disponible.

¿Cuál es el rendimiento del algoritmo Raft implementado por etcd?

Un único nodo de instancia admite 2000 escrituras de datos por segundo. Cuanto mayor sea el número de nodos, más lenta y lenta será la sincronización de datos que implica retrasos en la red de acuerdo con la situación real, y mayor será el rendimiento de lectura, porque cada nodo puede manejar las solicitudes de los usuarios.

Tienda

Store, como su nombre indica, es la lógica subyacente implementada por etcd y proporciona el correspondiente soporte de API. Para comprender Store, solo necesita comenzar con la API de etcd. Las llamadas a la API CURD más comunes se enumeran a continuación.

• Asignar valores a las claves almacenadas por etcd:

curl http://127.0.0.1:2379/v2/keys/message -X PUT -d value="Hello world"

{
    "action":"set",                     # 执行的操作
    "node":{
        "createdIndex":2,           # etcd Node 每次有变化时都会自增的一个值
        "key":"/message",          # 请求路径
        "modifiedIndex":2,          # 类似 node.createdIndex，能引起 modifiedIndex 变化的操作包括 set, delete, update, create, compareAndSwap and compareAndDelete
        "value":"Hello world"      # 存储的内容
    }
}

• Consultar el valor almacenado por una clave en etcd:

curl http://127.0.0.1:2379/v2/keys/message -X GET

• Modificar el valor de la clave:

curl http://127.0.0.1:2379/v2/keys/message -XPUT -d value="Hello etcd"

• Eliminar valor clave:

curl http://127.0.0.1:2379/v2/keys/message -XDELETE

WAL

El almacenamiento de datos de etcd se divide en dos partes:

• Almacenamiento en memoria : además de los registros secuenciales de todos los cambios de los usuarios en los datos del nodo, el almacenamiento en la memoria también realizará operaciones como indexación y apilamiento de datos del usuario para facilitar la consulta.
• Almacenamiento persistente (disco duro) : la persistencia utiliza WAL (Write Ahead Log, registro de escritura anticipada) para el almacenamiento de registros.

El registro WAL es binario y la estructura de datos anterior LogEntry se analiza. entre ellos:

El primer tipo de campo, solo hay dos tipos:

1. 0 significa Normal
2. 1 significa ConfChange y ConfChange significa sincronización de los cambios de configuración de etcd, como la unión de nuevos nodos.

El segundo campo es el término, cada término representa el término de un líder y cambiará cada vez que el líder cambie el término.

El tercer campo es el índice Este número de serie aumenta estricta y secuencialmente, lo que representa el número de serie del cambio.

El cuarto campo son datos binarios, que guardan toda la estructura pb del objeto Raft Request.

Existe una herramienta de secuencia de comandos tools / etcd-dump-logs en el código fuente etcd, que puede volcar los registros de WAL en texto para verlos y puede ayudar a analizar el protocolo Raft.

El protocolo de Raft en sí no se preocupa por los datos de la aplicación, es decir, la parte de los datos. La consistencia se logra sincronizando el registro WAL. Cada Nodo aplica los datos recibidos del Líder al almacenamiento local. Raft solo se preocupa por el estado de sincronización del registro. Hay errores en la implementación del almacenamiento local, como no aplicar correctamente los datos localmente, lo que también puede causar inconsistencias en los datos.

En el sistema WAL, todos los datos se registrarán antes del envío. En el directorio de almacenamiento persistente de etcd, hay dos subdirectorios:

1. Uno es WAL: almacena los registros de cambios de todas las transacciones;
2. El otro es Instantánea: almacena los datos de todos los directorios en etcd en un momento determinado.

A través de la combinación de WAL e Snapshot, etcd puede realizar operaciones de manera efectiva como el almacenamiento de datos y la recuperación de fallas de nodo.

¿Por qué necesito Instantánea?

Porque con el aumento en el uso, los datos almacenados por WAL aumentarán drásticamente. Para evitar que el disco se llene rápidamente, etcd toma una instantánea cada 10,000 registros por defecto, y los archivos WAL después de la instantánea se pueden eliminar. Por lo tanto, los registros del historial de operaciones predeterminados que se pueden consultar a través de la API son 1000.

En el primer inicio, etcd almacenará la información de configuración de inicio en la ruta del directorio especificada por el elemento de configuración del directorio de datos. La información de configuración incluye ID de nodo local, ID de clúster e información de clúster inicial. Los usuarios deben evitar el reinicio de etcd desde un directorio de datos caducado, porque un nodo iniciado con un directorio de datos caducado será inconsistente con otros nodos en el clúster. Por ejemplo, se ha registrado y acordado que el nodo líder almacenará cierta información antes de reiniciar. Solicite esta información al nodo líder de nuevo. Por lo tanto, para maximizar la seguridad del clúster, una vez que exista alguna posibilidad de corrupción o pérdida de datos, debe eliminar este nodo del clúster y luego agregar un nuevo nodo sin un directorio de datos.

La función más importante de WAL (Write Ahead Log) es registrar el historial completo de todo el cambio de datos. En etcd, todos los cambios de datos deben escribirse en WAL antes de enviarlos. El uso de WAL para el almacenamiento de datos permite que etcd tenga dos funciones importantes:

1. Recuperación rápida de fallas : cuando sus datos están dañados, puede recuperarse rápidamente de los datos originales al estado anterior al daño de los datos realizando todas las operaciones de modificación registradas en el WAL.
2. Revertir (deshacer) o rehacer (rehacer) de datos : debido a que todas las operaciones de modificación se registran en el WAL, se requiere revertir o rehacer. Solo necesita realizar las operaciones en el registro en la dirección o en la dirección de avance.

¿Cuáles son las reglas de nomenclatura para WAL y Snapshot?

, Archivos WAL en el $seq-$index.walformato de almacenamiento de datos de directorio etcd . El archivo WAL inicial es 0000000000000000-0000000000000000.wal, lo que significa que este es el 0 entre todos los archivos WAL, y el número de estado inicial de Raft es 0. Después de ejecutar durante un período de tiempo, puede ser necesario realizar una segmentación de registros y colocar nuevas entradas en un nuevo archivo WAL.

Supongamos que, cuando el clúster se ejecuta en el estado Raft de 20, cuando el archivo WAL necesita segmentarse, el siguiente archivo WAL se convertirá en 0000000000000001-0000000000000021.wal. Si se realiza otra segmentación de registros después de 10 operaciones, el nombre del archivo WAL de la próxima vez será 0000000000000002-0000000000000031.wal. Se puede ver que el número delante del símbolo "-" se incrementa en 1 después de cada segmentación, y el número después del símbolo "-" se determina de acuerdo con el estado inicial real almacenado de la balsa.

Almacenamiento de instantáneas y con nombre más fácil de entender, para $term-$index.walformatear el almacenamiento con nombre. El término y el índice representan el estado del nodo Raft donde se almacenan los datos cuando se almacena la instantánea, el número de término actual y la ubicación del elemento de datos.

modelo de datos etcd

etcd está diseñado para almacenar datos actualizados con poca frecuencia y proporcionar un complemento de vigilancia confiable, que expone la versión histórica de pares clave-valor para admitir instantáneas de bajo costo y monitorear eventos históricos. Estos objetivos de diseño requieren que utilice un modelo de datos persistente, de múltiples versiones y concurrente.

Cuando se guarda la nueva versión del par clave-valor etcd, la versión anterior aún existe. En efecto, los pares clave-valor son inmutables y etcd no realizará operaciones de actualización in situ en ellos, pero siempre generará una nueva estructura de datos. Para evitar un aumento ilimitado de versiones históricas, el almacenamiento de etcd admite la compresión (Compacto) y elimina las versiones antiguas.

Vista lógica

Desde un punto de vista lógico, el almacenamiento de etcd es un espacio de clave binaria plana, y el espacio de clave tiene un índice lexicográfico para la clave (cadena de bytes), por lo que el costo de la consulta de rango es menor.

El espacio de claves mantiene múltiples revisiones (Revisiones), y cada operación de cambio atómico (una transacción puede estar compuesta de múltiples suboperaciones) generará una nueva revisión. A lo largo del ciclo de vida del clúster, las revisiones aumentan de manera monótona. Las revisiones también admiten la indexación, por lo que los escaneos de rango basados ​​en revisiones también son eficientes. La operación de compresión necesita especificar un número de revisión, y las revisiones menores que este se eliminarán.

El ciclo de vida de una clave (desde la creación hasta la eliminación) se denomina "Generación" y cada clave puede tener varias generaciones. Cuando se crea una clave, la versión de la clave (Versión) aumenta. Si la clave no existe en la revisión actual, la versión se establece en 1. Eliminar una clave creará una lápida, establecerá la versión en 0 y finalizará la generación actual. Cada vez que se modifica el valor de la clave, su número de versión aumentará, es decir, el número de versión aumenta monótonamente en la misma generación.

Al comprimir, se eliminará cualquier generación que finalizó antes de la revisión comprimida. Se eliminará el registro de modificación con el valor anterior a la revisión (solo el último).

Vista fisica

etcd almacena datos en un árbol persistente B +. Por razones de eficiencia, cada revisión solo almacena los cambios de estado de los datos (Delta) en relación con la revisión anterior. Una sola revisión puede contener varias claves en el árbol B +.

La clave del par clave-valor es triple (principal, secundaria, tipo):

• Mayor: almacena la revisión del valor de la clave.
• Sub: se utiliza para distinguir diferentes claves en la misma revisión.
• Tipo: sufijo opcional utilizado para valores especiales, por ejemplo, t significa que el valor contiene una lápida

El valor del par clave-valor, incluida la delta de la revisión anterior. Árbol B +, es decir, el orden léxico de bytes de las claves, la velocidad de escaneo basada en el rango de la revisión es rápida y es conveniente encontrar el cambio de valor de una revisión a otra.

etcd también mantiene un índice de árbol B en la memoria para acelerar los escaneos de rango en busca de claves. La clave del índice es el mapeo orientado al usuario de la clave de almacenamiento físico, y el valor del índice es un puntero al punto del árbol B +.

Modo proxy de etcd

El modo proxy, a saber: etcd actúa como un proxy inverso para reenviar las solicitudes del cliente al clúster etcd disponible. De esta manera, puede implementar un modo proxy etcd como un servicio local en cada máquina. Si estos proxy etcd pueden ejecutarse normalmente, entonces su descubrimiento de servicios debe ser estable y confiable.

Por lo tanto, el modo Proxy no se agrega directamente al clúster etcd conforme a una coherencia sólida. De manera similar, Proxy no aumenta la confiabilidad del clúster y ciertamente no reduce el rendimiento de escritura del clúster.

¿Por qué el modo Proxy reemplaza al modo de espera?

De hecho, cada vez que etcd agrega un nodo central (Peer), aumentará la carga del líder, incluida la red, la CPU y el disco hasta cierto punto, porque cada cambio de información requiere una copia de seguridad sincrónica. El aumento de los nodos centrales de etcd puede hacer que todo el clúster sea más confiable, pero cuando el número alcanza cierto nivel, los beneficios de aumentar la confiabilidad se vuelven menos obvios, pero reduce el rendimiento de la sincronización de escritura del clúster. Por lo tanto, agregar un nodo etcd ligero en modo Proxy es un reemplazo efectivo para agregar directamente nodos centrales etcd.

El modo proxy en realidad reemplaza al modo de espera original. Además de la función del agente de reenvío, el modo de espera cambiará del modo de espera al modo de nodo normal cuando el número de nodos centrales sea insuficiente debido a una falla. Cuando el nodo fallido se recupera, se encuentra que el número de nodos centrales en etcd ha alcanzado el valor preestablecido y cambiará al modo de espera.

Sin embargo, en la nueva versión de etcd, solo cuando se encuentra que el número de nodos centrales cumple con los requisitos cuando el clúster etcd se inicia inicialmente, el modo Proxy se habilita automáticamente, y viceversa. Las principales razones son las siguientes:

• etcd es un componente que se utiliza para garantizar una alta disponibilidad, por lo que los recursos del sistema que necesita, incluida la memoria, el disco duro y la CPU, deben estar totalmente garantizados para garantizar una alta disponibilidad. Deje que la transformación automática del clúster cambie el nodo central a voluntad, y la máquina no puede garantizar el rendimiento. Por lo tanto, etcd anima oficialmente a todos a preparar grupos de máquinas dedicados para ejecutar etcd en grupos grandes.
• Debido a que el clúster etcd admite alta disponibilidad, algunas fallas de la máquina no causarán fallas funcionales. Por lo tanto, cuando la máquina falla, el administrador tiene tiempo suficiente para inspeccionar y reparar la máquina.
• La conversión automática hace que los clústeres de etcd sean complicados, especialmente ahora que etcd admite la supervisión y la interacción en múltiples entornos de red. El cambio entre diferentes redes es más propenso a errores, lo que genera clústeres inestables.