1. Antecedentes
Los centros de datos y las aplicaciones de hoy en día operan en entornos altamente dinámicos y, en respuesta a entornos altamente dinámicos, escalan con servidores adicionales y crecen y se reducen según sea necesario. Al mismo tiempo, las fallas del servidor y de la red también son comunes.
Por lo tanto, el sistema debe gestionar la puesta fuera de línea y fuera de línea del servidor durante el funcionamiento normal. Deben reaccionar a los cambios y adaptarse automáticamente en segundos; una interrupción notable a menudo es inaceptable para los clientes.
Afortunadamente, el consenso distribuido puede ayudar con estos desafíos.
1.1 Generales bizantinos
Antes de presentar el algoritmo de consenso, se presenta un ejemplo simplificado de generales bizantinos para ayudar a comprender el algoritmo de consenso.
Asumiendo que no hay rebeldes entre los generales bizantinos, y que la información del mensajero es confiable pero puede ser asesinado, ¿cómo pueden los generales llegar a una decisión de consenso sobre si atacar?
La solución puede entenderse aproximadamente como: primero seleccione un general entre todos los generales para tomar todas las decisiones.
Un ejemplo es el siguiente: si hay 3 generales A, B y C, cada general tiene una cuenta regresiva aleatoria. Una vez que finaliza la cuenta regresiva, el general se considerará candidato general y luego enviará un mensajero para entregar la elección. voto mensaje a los generales B y C, si los generales B y C no se han identificado como candidatos (la cuenta atrás para ellos mismos no ha terminado) y no han emitido sus votos electorales a nadie más, votarán por los generales A, el mensajero Cuando volviendo al General A, el General A sabe que ha recibido suficientes votos para convertirse en Gran General. Después de tener un general, depende del General A decidir si atacar y luego enviar un mensajero para informar a los otros dos generales que se ha convertido en general. Si no ha tenido noticias de los generales B y C durante un tiempo (el mensajero puede ser asesinado), envíe otro mensajero hasta que reciba una respuesta.
1.2 Algoritmos de
consenso El consenso es un problema fundamental en los sistemas tolerantes a fallas: los servidores pueden acordar un estado compartido incluso ante una falla.
El algoritmo de consenso permite que un grupo de nodos funcionen juntos como un todo y continúen funcionando incluso si algunos de los nodos fallan. Su corrección se debe principalmente a la naturaleza de la máquina de estado replicada: la máquina de estado de un grupo de servidores calcula copias del mismo estado, incluso si una parte del servidor falla, aún pueden continuar ejecutándose.
rsm-arquitectura.png
Figura 1 Arquitectura de máquina de estado de replicación
Las máquinas de estado replicadas normalmente se implementan mediante el uso de registros replicados. Cada servidor almacena un archivo de registro que contiene la secuencia de comandos que la máquina de estado ejecuta en secuencia. Debido a que cada registro contiene los mismos comandos y está en el mismo orden, cada máquina de estado procesa la misma secuencia de comandos. Dado que la máquina de estado es determinista, se procesa el mismo estado y se obtiene la misma salida.
Entonces, el trabajo del algoritmo de consenso es mantener consistente el registro replicado. El módulo de consenso en el servidor recibe comandos de los clientes y los agrega al registro. Se comunica con módulos de consenso en otros servidores para garantizar que incluso si algunos servidores fallan. Cada registro termina conteniendo solicitudes en el mismo orden. Una vez que los comandos se han copiado correctamente, se dice que están confirmados. La máquina de estado de cada servidor procesa los comandos enviados en orden de registro y devuelve la salida al cliente, por lo que estos servidores forman una única máquina de estado altamente confiable.
Los algoritmos de consenso adecuados para sistemas prácticos suelen tener las siguientes propiedades:
La seguridad. Garantiza la seguridad en condiciones no bizantinas (es decir, las bizantinas simplificadas mencionadas anteriormente), incluidas la latencia de la red, las particiones, la pérdida de paquetes, la replicación y el reordenamiento.
Alta disponibilidad. La mayoría de los servidores se consideran completamente funcionales siempre que estén operativos y puedan comunicarse entre sí y con los clientes. Por lo tanto, un clúster típico de cinco servidores puede tolerar dos fallas del lado del servidor. Supongamos que los servidores fallan al ser detenidos; luego pueden recuperarse de su estado en almacenamiento estable y volver a unirse al clúster.
La consistencia no depende del tiempo. Los relojes incorrectos y los retrasos extremos en los mensajes, en el peor de los casos, solo crean problemas de disponibilidad, no problemas de consistencia.
Los comandos se pueden completar cuando la mayoría de los servidores del clúster respondan sin que unos pocos servidores lentos afecten el rendimiento general del sistema.
2 conceptos básicos
2.1 Tipos de nodos
Un clúster de Raft incluye varios servidores, tomando como ejemplo un clúster típico de 5 servidores. En cualquier momento, cada servidor debe estar en uno de estos tres estados:
Líder: responsable de iniciar latidos, responder a los clientes, crear registros y sincronizar registros.
Candidato: El rol temporal del líder en el proceso de elección, se transforma de seguidor e inicia una votación para participar en la elección.
Seguidor: acepte el latido del corazón del líder y registre los datos de sincronización, y vote por Candidato.
En circunstancias normales, solo un servidor es el líder y los servidores restantes son seguidores. Los seguidores son pasivos, no envían solicitudes, solo responden a las solicitudes del líder y el candidato.
Figura-2: Estado del servidor
2.2 Duración del mandato
Figura-3: Tenencia
Como se muestra en la Figura 3, el algoritmo raft divide el tiempo en términos de longitud arbitraria y el término se representa mediante un número continuo, que se considera el número del término actual. El comienzo de cada mandato es una elección en la que uno o más candidatos intentan convertirse en Líderes. Si un Candidato gana la elección, se desempeña como Líder por ese período. Si no se elige ningún líder, comenzará otro período y la próxima elección comenzará de inmediato. El algoritmo balsa garantiza que hay al menos un líder en un término dado.
Cada nodo almacena el número de término actual, que se intercambia cuando los servidores se comunican; si un servidor encuentra que su propio número de término es más pequeño que otros, se actualizará a un valor de término mayor. Si un Candidato o Líder descubre que su mandato ha expirado, volverá inmediatamente a ser un Seguidor. Si un servidor recibe una solicitud con un número de plazo vencido, rechaza la solicitud.
2.3
Entrada de registro: cada evento se convierte en una entrada y solo el líder puede crear una entrada. El contenido de la entrada es <term,index,cmd> donde cmd es la operación que se puede aplicar a la máquina de estado.
log: una matriz compuesta de entradas, cada entrada tiene un índice que indica su propio registro. Solo el líder puede cambiar los registros de otros nodos. El líder siempre agrega la entrada a su propia matriz de registro primero y luego inicia una solicitud de consenso, que luego el líder envía a la máquina de estado después de que se aprueba. El seguidor solo puede obtener el nuevo registro y el índice de compromiso actual del líder y luego aplicar la entrada correspondiente a su propia máquina de estado.
3 elección de líder
balsa utiliza un mecanismo de latido del corazón para desencadenar la elección del líder.
Si un servidor puede recibir información válida del Líder o Candidato, permanecerá en el estado Seguidor, actualizará su elección Transcurrida y volverá a programar.
El líder enviará periódicamente latidos a todos los seguidores para garantizar su estado de líder. Si un seguidor no recibe información de latidos dentro de un período, se llama tiempo de espera de elección, luego considerará que no hay un líder disponible en este momento y comenzará una elección para elegir un nuevo líder.
Para comenzar una nueva elección, el seguidor incrementa su propio término y pasa a Candidato. Luego iniciará una solicitud RequestVoteRPC a todos los nodos, y el estado de Candidato continuará hasta que suceda lo siguiente:
Ganar la elección
Otros nodos ganan la
elección Termina una ronda de elección, nadie gana
La condición para ganar la elección es: un Candidato puede convertirse en Líder si recibe una mayoría de votos (N/2+1) del grupo dentro de un término.
Mientras el Candidato está esperando votos, puede recibir latidos de otros nodos que declaran que es el Líder. En este momento, hay dos situaciones:
Si el número de mandato del líder es mayor o igual que su propio número de mandato, significa que la otra parte se ha convertido en líder y volverá a ser seguidor.
Si el número de término del líder es menor que su propio número de término, rechazará la solicitud y permitirá que el nodo actualice el término.
Dado que pueden presentarse varios Candidatos al mismo tiempo, ningún Candidato obtendrá la mayoría de los votos, y si no hay otra forma de redistribuir los votos, puede repetirse indefinidamente.
balsa utiliza un tiempo de espera de elección aleatoria para evitar esto. Después de que cada Candidato inicia una elección, se aleatoriza un nuevo tiempo de espera de enumeración. Este mecanismo permite que los servidores se distribuyan y, en la mayoría de los casos, solo un servidor tomará la delantera y ganará antes de que los demás servidores agoten el tiempo de elección.
replicación de 4 registros
Una vez que se selecciona el líder, comienza a aceptar solicitudes de clientes. Cada solicitud de cliente contiene un comando que debe ser ejecutado por la máquina de estado replicada.
Después de que el líder reciba la solicitud del cliente, generará una entrada, que incluye <índice, término, cmd>, y luego agregará la entrada al final de su registro, transmitirá la entrada a todos los nodos y pedirá a otros servidores que copien la entrada. .
Si el seguidor acepta la entrada, la agregará a su propio registro y se la devolverá al líder para su aprobación.
Si el líder recibe la mayoría de las respuestas exitosas, el líder aplicará la entrada a su propia máquina de estado, y luego la entrada puede confirmarse y devolver el resultado de la ejecución al cliente.
raft garantiza las dos propiedades siguientes:
En los dos registros, hay dos entradas con el mismo índice y término, luego deben tener el mismo cmd
En los dos registros, hay dos entradas con el mismo índice y término, luego la entrada anterior también debe
pasar el mismo "Solo el líder puede sobrevivir a la entrada" para garantizar la primera propiedad, y la segunda propiedad requiere una verificación de consistencia para garantizarla.
En general, los registros del líder y el seguidor son consistentes y, luego, el bloqueo del líder hará que los registros sean diferentes, por lo que la verificación de coherencia fallará. Los líderes manejan las inconsistencias de los registros obligando a los seguidores a replicar sus propios registros. Esto significa que el registro de conflictos del seguidor se sobrescribirá con el registro del líder.
Para que el registro del seguidor sea consistente con su propio registro, el líder necesita encontrar el lugar donde el seguidor es consistente con su registro, luego eliminar el registro del seguidor después de esa posición y luego enviar el siguiente registro al seguidor.
El líder mantiene un nextIndex para cada seguidor, que representa el índice de la siguiente entrada de registro que el líder enviará al seguidor. Cuando un líder llega al poder, inicializa nextIndex a su último índice de entrada de registro + 1. Si el registro de un seguidor es incoherente con el del líder, la comprobación de coherencia de AppendEntries fallará en el siguiente RPC de AppendEntries. Después de una falla, el líder disminuirá el índice siguiente y volverá a intentar el RPC de AppendEntries. Eventualmente, nextIndex llegará a un lugar donde los registros de líder y seguidor sean consistentes. En este punto, AppendEntries devolverá el resultado correcto, se eliminarán las entradas de registro en conflicto en el seguidor y se agregarán las entradas de registro faltantes en el líder. Una vez que AppendEntries regresa con éxito, los registros de Follower y Leader son consistentes, y este estado permanecerá hasta el final del plazo.
5 Seguridad
5.1 Restricciones electorales Los
líderes deben asegurarse de almacenar todas las entradas de registro enviadas. Esto permite que las entradas de registro fluyan en una sola dirección: del líder al seguidor, y el líder nunca sobrescribe las entradas de registro existentes.
Cuando cada Candidato envíe RequestVoteRPC, traerá la información de la última entrada. Cuando todos los nodos reciban información de votación, compararán la entrada y, si encuentran sus propias actualizaciones, se negarán a votar por el Candidato.
La forma de juzgar si el registro es antiguo o nuevo: si los términos de los dos registros son diferentes, se actualiza el término mayor; si los términos son iguales, se actualiza el índice más largo.
5.2 Bloqueo del nodo
Si el líder falla, los nodos del clúster no reciben la información del latido del líder dentro del tiempo de espera de la elección, lo que activará una nueva ronda de elección del líder. Durante la elección del líder, todo el clúster no está disponible para el mundo exterior.
Si el seguidor y el candidato fallan, es mucho más fácil lidiar con ellos. RequestVoteRPCs y AppendEntriesRPCs enviados más tarde fallan. Dado que todas las solicitudes de balsa son idempotentes, se volverán a intentar indefinidamente si fallan. Si el bloqueo se recupera, puede recibir una nueva solicitud y luego optar por agregar o rechazar la entrada.
5.3 Tiempo y disponibilidad
Uno de los requisitos de raft es que la seguridad no dependa del tiempo: el sistema no puede fallar simplemente porque algún evento sucedió más rápido o más lento de lo esperado. Para garantizar los requisitos anteriores, es mejor cumplir con las siguientes condiciones de tiempo:
tiempo de emisión << tiempo de espera de las elecciones << MTBF
broadcastTime: el tiempo de respuesta promedio para el envío simultáneo de mensajes a otros nodos;
choiceTimeout: tiempo de espera de elección;
MTBF (tiempo medio entre fallas): el tiempo promedio de salud de una sola máquina;
broadcastTime debe ser un orden de magnitud menor que choiceTimeout, de modo que el El líder puede continuar enviando un latido para evitar que los seguidores comiencen las elecciones;
choiceTimeout también es varios órdenes de magnitud más pequeño que MTBF, para que el sistema funcione de manera estable. Cuando el líder falla, no estará disponible durante todo el tiempo de espera de las elecciones; esperamos que sea solo una pequeña fracción del tiempo total.
Dado que broadcastTime y MTBF son atributos determinados por el sistema, es necesario determinar el momento de choiceTimeout.
En términos generales, el tiempo de transmisión es generalmente de 0,5 a 20 ms, el tiempo de espera de elección se puede establecer en 10 a 500 ms y el MTBF generalmente es de uno o dos meses.