Replicación

Puede ser necesaria la ayuda del fabricante.

Acerca de la capa de replicación

DINAMO master La replicación (RL) en es una implementación de un sistemasíncrono multitipo, en el que todos los dispositivos de un pool aceptan solicitudes de modificación de datos (como crear/eliminar claves, cambiar contraseñas de usuario, etc.). Cualquier dato modificado en un HSM se transmite desde el nodo en el que se ha realizado la operación a todos los demás participantes, antes de que se confirme finalmente una transacción distribuida.

La transmisión se realiza mediante el conocido confirmación en dos fases (2PC), ampliamente utilizado en el sector de las bases de datos. El 2PC tiene algunas desventajas, pero a pesar de ello es popular en la práctica: es sencillo, eficiente y proporciona una solución correcta al problema del consenso entre nodos. Por desgracia, es un protocolo que permite bloquear las operaciones distribuidas.

La coherencia es una característica intrínseca de HSM. No se requiere lógica de cliente ni infraestructura para manejar resultados operativos no deterministas. De hecho, si RL devuelve uno de los códigos de retorno documentados, se pueden seguir algunos pasos para la resolución de problemas. La mayoría de las veces, estos pasos son suficientes para revelar los problemas subyacentes; en cualquier caso, si la intervención del fabricante es realmente necesaria, los datos de depuración permitirán una prestación de asistencia más ágil.

En su empeño por funcionar de forma coherente, RL se diseñó para detectar y evitar escenarios de cerebro dividido. En este caso, Sync-Point (SP) se concibió como una forma de codificar todo el estado de un HSM en un único número. DINAMO Con una sola validación a nivel de protocolo, es capaz de saber si sus pares comparten el mismo estado.

Comprobaciones iniciales

1. Como se ha indicado anteriormente, todos los HSM de un pool deben comunicarse para un correcto funcionamiento distribuido; comprueba que todos los dispositivos tienen las direcciones TCP/IP de los otros HSM en sus cachés de nodo; por ejemplo, un pool formado por 2 HSM, A y B: A debe tener registrada la IP de B, y del mismo modo B debe tener registrada la IP de A (no importa si las direcciones se obtienen mediante autodescubrimiento, o si se registran manualmente). La comprobación puede realizarse a través de las consolas local o remota.

2. Compruebe que los HSM pueden comunicarse a través de las direcciones identificadas en [1.]. La prueba de comunicación puede realizarse a través de las consolas local o remota;

3. Compruebe que todos los equipos de la misma piscina comparten el mismo punto de sincronización (SP); el SP es un número hexadecimal (por ejemplo CA110F4B3A0662A2un pequeño número de control correspondiente como 5058 también estará disponible, lo que facilitará la realización de este paso).La comprobación del SP puede realizarse a través de las consolas ubicación o remoto;

   Si no se cumple [3.], deberá garantizarse la sincronización de los equipos divergentes, utilizando utilizando una imagen oficial para lalive-sync puede ejecutarse con este fin, sin interrumpir los servicios; copias de seguridad/restauraciones también se pueden realizar copias de seguridad / restauraciones, con la desventaja de que son procesos offline que requieren ajustes en la configuración de red; la función live-sync es el método recomendado (tras la sincronización a través de él, los nodos preexistentes tienen sus cachés con direcciones IP sensibilizadas como parte del procedimiento, y empiezan a funcionar con los nuevos HSM automáticamente);

4. Compruebe si uno o más HSM del pool tienen un registro de transacciones pendientes (PTL); como se destacó en el debate de 2PC, las operaciones de escritura distribuidas (por ejemplo: creación de claves) pueden bloquearse si una transacción anterior aún está en curso; normalmente -basándose en la naturaleza operativa muy asíncrona de RL- las transacciones pendientes son resueltas automáticamente por el replication-manager en cuestión de minutos.Las transacciones pendientes (por ejemplo, la creación de claves) pueden bloquearse si una transacción anterior aún está en curso; normalmente, debido a la naturaleza operativa asíncrona de RL, las transacciones pendientes son resueltas automáticamente por el gestor de replicación en cuestión de minutos; cada PTL lleva toda la información necesaria para las confirmaciones; si no se puede acceder a uno de los nodos que participan en la operación distribuida (fallo de hardware, red, etc.), el pool permanece bloqueado; los mensajes administrativos de nodo caído pueden utilizarse para informar al pool de que uno o más dispositivos dejarán de estar operativos, lo que permitirá confirmar las PTL que dependen de los HSM no disponibles (y desbloquear finalmente el pool). La operación node-down sólo puede realizarse a través de la consola remota.