Utilización de la duplicación
La duplicación permite que los mensajes de una instancia de servicio de Event Streams se copien continuamente en una segunda instancia. La resiliencia de aplicaciones se puede mejorar utilizando la duplicación como si la primera instancia de servicio dejara de estar disponible, las aplicaciones pueden volver a conectarse a la segunda instancia y continuar su funcionamiento normal.
Esta característica forma parte del servicio totalmente gestionado y solo se puede utilizar entre instancias de servicio que utilizan el plan Event Streams Enterprise.
Características de la duplicación:
- Temas de duplicación, datos de mensajes y desplazamientos de grupo de consumidores entre dos instancias de servicio de Event Streams, que se pueden suministrar en distintas cuentas de IBM Cloud.
- SLA de 99.99% de disponibilidad, coherente con el servicio Event Streams.
- Se puede supervisar utilizando IBM Cloud® Monitoring.
Limitaciones de la duplicación:
- Unidireccional: los datos sólo se pueden duplicar en una dirección a la vez entre un par de instancias de servicio. Esto significa que la duplicación ofrece un estilo "activo-pasivo" de alta disponibilidad, no "activo-activo".
- Asíncrono: los mensajes se deben generar correctamente en la instancia de origen antes de que se puedan duplicar en la instancia de destino. Esto significa que, cuando se produce un fallo, es posible que el clúster de destino no tenga todos los mensajes hasta el punto exacto del fallo debido al retraso de la replicación y que se pierdan algunos datos de los mensajes.
- Consumo de mensajes al menos una vez: cuando un consumidor se mueve entre instancias, es posible que tenga que volver a procesar los mensajes que ya ha procesado.
Antes de iniciar la duplicación, tenga en cuenta los puntos siguientes:
- Es posible que sea necesario modificar las aplicaciones para aprovechar mejor la duplicación.
- Asegúrese de que hay suficiente capacidad disponible para el tráfico de red utilizado para duplicar datos entre instancias.
Para habilitar la duplicación, consulte la Guía de configuración de la duplicación.
Visión general de la duplicación
La duplicación de los temas seleccionados se produce entre dos clústeres y es unidireccional, lo que significa que los datos se duplican en una dirección desde un solo clúster de origen a un solo clúster de destino. Cada clúster tiene un alias
de duplicación. En este documento, A se utiliza para el alias de clúster de origen y B para el alias de clúster de destino. Los alias se pueden configurar cuando la duplicación está habilitada, por ejemplo, podrían
ser "us-south" y "us-east".
Un tema llamado mytopic del clúster de origen (A) aparece en el clúster de destino (B) como mytopic.A indicando que se origina en A. Este tipo de tema se denomina tema remoto porque se origina
en el clúster remoto (origen). En cambio, los temas creados directamente en el clúster de destino por los usuarios se denominan temas locales.
Para seleccionar qué temas se reflejan, puede configurarse un patrón de expresión regular mediante los controles de usuario de reflejo.
La duplicación convierte automáticamente los desplazamientos de consumidor entre las instancias de origen y de destino. En las versiones anteriores de Event Streams, los consumidores tenían que utilizar un tema especial denominado A.checkpoints.internal (donde A es el alias del clúster de origen). Esto ya no es necesario, sin embargo, el proceso de duplicación sigue creando y actualizando el tema de punto de comprobación para la compatibilidad con las aplicaciones existentes.
Las aplicaciones que deseen utilizar el tema de puntos de comprobación pueden utilizar Kafka MirrorClient para simplificar el acceso a los datos contenidos en este tema.
Por último, debido a la denominación de temas remotos:
- Evite utilizar alias de clúster como parte de los nombres de recurso Kafka.
- Asegúrese de que el nombre de tema remoto (por ejemplo, el tema de origen y el alias de clúster de origen) no supera el límite de longitud para los temas Kafka (249 caracteres). Si un nombre de tema remoto supera este límite, los mensajes no se duplicarán para el tema.
Planificación de la capacidad
Tanto el uso de la red como la ubicación geográfica de las instancias de servicio de origen y destino deben tenerse en cuenta a la hora de planificar la capacidad.
Ancho de banda de red
El ancho de banda de red necesario para reflejar los temas seleccionados debe tenerse en cuenta en la asignación de ancho de banda de las instancias de servicio de origen y destino. Por ejemplo, si las aplicaciones de la instancia de servicio de origen producen 10 MB/s de tráfico de mensajes a los temas reflejados, se necesitan 10 MB/s adicionales de ancho de banda saliente para reflejar estos mensajes en la instancia de destino. Esto debe tenerse en cuenta junto con cualquier ancho de banda saliente existente que ya esté siendo utilizado por las aplicaciones consumidoras. Los paneles de control de supervisión se pueden utilizar para determinar el uso de la red en una instancia de servicio. Para obtener más información, consulte Duplicación de las métricas de Event Streams.
Ubicación geográfica
Al igual que sucede con cualquier red, el rendimiento máximo posible es un factor de la distancia sobre la que se transmiten los datos (debido al aumento de la latencia y la pérdida de paquetes). Esto afecta al rendimiento máximo que puede alcanzarse entre las instancias de origen y destino. Coloque las instancias de servicio de destino en un lugar geográficamente lo más cercano posible a la fuente.
La siguiente tabla proporciona una guía para el rendimiento alcanzable al duplicar desde una instancia de origen con una capacidad de 150 MB/s.
| Regiones | Rendimiento máximo por partición | Rendimiento máximo total |
|---|---|---|
| us-south <-> us-east | 1,5 MB/s | 35 MB/s |
| eu-gb <-> eu-de | 2,5 MB/s | 35 MB/s |
| au-syd <-> jp-tok | 0,4 MB/s | 12 MB/s |
| en la misma región eu-gb <-> eu-gb | 2,5 MB/s | 35 MB/s |
Los números indican:
- Máximo rendimiento total: el número máximo de MB/s total que se puede duplicar en todos los temas seleccionados.
- Rendimiento máximo por partición: los MB/s máximos que se pueden duplicar dentro de una única partición. Seleccione el número de particiones configuradas para los temas de origen para asegurarse de que la carga por partición permanece dentro de este límite.
Si se superan los límites, aumenta el desfase entre los datos de las instancias de origen y destino. Tener un retardo de datos grande puede hacer que se pierda una mayor cantidad de datos de mensaje si la instancia de origen falla. Incluso si el retardo entre instancias es cero, ya que la duplicación es asíncrona, debe anticipar que algunos datos se pueden perder si la instancia de origen falla. Los paneles de control de supervisión se pueden utilizar para determinar la latencia para cada tema. Para obtener más información, consulte Supervisión de la duplicación.
La orientación sobre el rendimiento alcanzable se ha generado utilizando mensajes 100K producidos en 50 particiones de tema. Si la carga de trabajo utiliza tamaños de mensaje más pequeños (por ejemplo, en 1K), o menos particiones, es posible que la duplicación no alcance estos niveles de rendimiento.
Supresión de temas de destino redundantes
Para evitar la supresión accidental de datos en la instancia de destino, los temas no se suprimen automáticamente de la instancia de destino cuando se suprimen del origen. Es responsabilidad del usuario suprimir los temas en la instancia de destino. Si los temas duplicados se suprimen y crean con frecuencia, se puede consumir más bonificación de disco y partición en el clúster de destino. El uso se puede supervisar con el panel de control de supervisión en el clúster de destino, consulte Supervisión de métricas de Event Streams. Puede suprimir temas que ya no son necesarios utilizando la CLI, la interfaz de usuario o las interfaces de administración.
Políticas de acceso de IAM para la duplicación
Dado que las aplicaciones necesitan acceder a los clústeres de origen y destino, las políticas de acceso de IAM deben configurarse en ambos clústeres y utilizar la clave de API del ID de servicio al que se adjuntan las políticas. Podemos utilizar las características de comodín de IAM Asignación de acceso mediante políticas comodín para simplificar las políticas de acceso que controlan el acceso a los recursos duplicados.
Si es nuevo en las políticas de acceso de IAM, consulte Cómo funciona IBM Cloud IAM y Gestión de la autenticación en las instancias de Event Streams para obtener más detalles.
Defina las siguientes políticas de acceso de IAM en ambos clústeres, donde
A.checkpoints.internal.
| Tipo de recurso | ID de recurso | Rol |
|---|---|---|
| clúster | Lector | |
| grupo | <RESOURCE_NAME>.* | Según lo requerido por la aplicación |
| tema | <RESOURCE_NAME>.* | Según lo requerido por la aplicación |
| txnid | <RESOURCE_NAME>.* | Según lo requerido por la aplicación |
| tema (específico del tema de punto de comprobación) |
|
Lector |
Otorgue políticas de acceso detalladas a aplicaciones individuales. Por ejemplo, para las aplicaciones que simplemente consumen, otorgue sólo acceso de lector.
Para duplicar los controles de usuario, debe disponer de los siguientes permisos en el clúster de destino.
| Tipo de recurso | ID de recurso | Rol |
|---|---|---|
| clúster | Gestor |
Restricciones basadas en el contexto y controles de seguridad de la red con Mirroring
La duplicación sigue un modelo basado en la extracción, en el que el clúster de destino inicia la conexión para extraer datos del clúster de origen. Este modelo de duplicación basado en la extracción impone controles de red en el clúster de origen, garantizando que sólo el clúster de destino autorizado pueda acceder a los datos del clúster de origen.
Cuando se activan los controles de seguridad de red, como la restricción basada en el contexto (CBR) o la lista de permisos CSE, se define una ruta segura a nivel de red y de identidad de seguridad añadiendo una lista de permisos de punto final de servicio al clúster de origen, que incluye la IP del pod de réplica del clúster de destino. Esta configuración impone un control de acceso detallado a nivel de infraestructura, permitiendo que sólo el punto final de réplica autorizado (el clúster de destino) extraiga datos del clúster de origen.
Las credenciales compartidas entre el clúster de origen y el de destino son estrictamente para el proceso de duplicación y no conceden acceso a ningún otro recurso entre ninguna implementación de Event Streams. Esto significa que el proceso de duplicación está aislado y es seguro, lo que impide el acceso no autorizado a otros recursos.
Estos controles de seguridad de red deben estar activados antes de configurar la duplicación. Si se aplican restricciones basadas en el contexto tras la configuración de la réplica, ésta no se iniciará hasta que se actualice el clúster.
Si se activa CBR después de la duplicación:
- Envíe una solicitud de asistencia.
- Espere hasta el siguiente ciclo de actualización del clúster (al menos 24 horas) para que los cambios surtan efecto.
- Incluya las direcciones de sus nodos espejo en sus reglas CBR.
- Desactivar y volver a activar la réplica en el clúster de destino.
Consideraciones a tener en cuenta cuando se comparten clusters entre varias entidades
Cuando varias entidades, como diferentes unidades de negocio, comparten una instancia y necesitan aislarse unas de otras, siga las directrices de nomenclatura para simplificar la gestión y el funcionamiento de los clústeres duplicados.
Asigne el nombre Kafka a los recursos utilizando la plantilla siguiente: <ENTITY_PREFIX>
Donde:
- < ENTITY_PREFIX > es el prefijo de la entidad que utiliza este tema.
-
es un carácter opcional que se utiliza para separar fácilmente los nombres de entidades y recursos. -
es el nombre del recurso Kafka.
Por ejemplo, si la unidad de negocio de contabilidad necesita un tema que se llame facturas, puede llamarlo accounting.invoices.
Se deben ajustar las políticas de acceso necesarias. Por ejemplo, para la unidad de negocio contable, se necesitan las siguientes políticas en el clúster B:
| Tipo de recurso | ID de recurso | Rol |
|---|---|---|
| clúster | Lector | |
| grupo | accounting.* | Según lo requerido por la aplicación |
| tema | accounting.* | Según lo requerido por la aplicación |
| txnid | accounting.* | Según lo requerido por la aplicación |
| topic (nota, esto es específico del tema del punto de comprobación) | A.checkpoints.internal | Lector |
El cluster A debe tener las mismas políticas de acceso excepto la última que debe estar en B.checkpoints.internal.
Duplicación de controles de usuario
Puede configurar la duplicación utilizando la CLI o la API REST de administración. Toda la duplicación de los controles de usuario se realiza en el clúster de destino.
Configuración de la selección de temas
La selección de la réplica se realiza en función de los nombres de los temas en el clúster de origen mediante el uso de patrones de expresión regular (regex). Elija cuidadosamente los nombres de los temas en el clúster de origen, teniendo en cuenta el consejo de la sección Consideraciones al compartir clústeres entre varias entidades.
Con nombres de tema bien estructurados, como añadir un prefijo a temas que forman parte del mismo grupo o aplicación, es fácil controlar la duplicación. Con una convención de nomenclatura de este tipo, cualquier tema futuro que coincida con el patrón se reflejará automáticamente sin necesidad de más cambios.
La selección de temas se da en forma de lista de uno o varios patrones regex. Se selecciona un tema si coincide con alguno de los patrones de la lista.
Algunos ejemplos de patrones para seleccionar temas para la duplicación:
| Patrones de ejemplo | Explicación |
|---|---|
^topic1$ |
Nombres de tema completos. Esto sólo coincide con el único tema denominado topic1. |
^topic1$,^topic2$ |
Lista de patrones que coinciden con nombres completos de tema. Esto coincide con los dos temas denominados topic1 y topic2. |
^aaa.* |
Coincide con el prefijo. Esto coincide con cualquier nombre de tema que empiece por aaa. |
^aaa.*,^bbb.* |
Lista de patrones coincidentes en el prefijo. Esto coincide con cualquier nombre de tema que empiece por aaa o bbb. |
^branch_[0-9]{3}_[a-z]*$ |
Patrón de regex más complejo para que coincida con los nombres de tema. Esto coincide con cualquier nombre de tema que empiece por branch_, seguido de exactamente 3 dígitos, seguido de _ y cualquier número
de letras minúsculas. |
.* |
Duplicar todos los temas de origen. |
Cuando se utiliza la CLI, los patrones se proporcionan como una lista separada por comas. Por ejemplo, el mandato siguiente seleccionará todos los temas cuyo nombre tenga el prefijo accounting o hr.
ibmcloud es mirroring-topic-selection-set --select '^accounting.*,^hr.*'
El mandato siguiente muestra cómo realizar la misma selección utilizando la API REST de administración. Los patrones tienen el formato de una matriz JSON denominada "includes".
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^accounting.*", "^hr.*"]}'
La actualización de una selección de temas sustituye al conjunto actual de patrones.
Para eliminar la selección para que no se duplique ningún tema, utilice la opción --none con la CLI, o un patrón vacío con la API REST de administración, como se indica a continuación.
ibmcloud es mirroring-topic-selection-set --none
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":[""]}'
Para desactivar selectivamente la duplicación, vuelva a aplicar la selección de temas omitiendo los patrones que desee desactivar. Por ejemplo, cuando topic1, topic2, topic3 están siendo reflejados, los siguientes comandos deshabilitan el reflejo para topic2 pero deja los otros dos habilitados.
ibmcloud es mirroring-topic-selection-set --select '^topic1$,^topic3$'
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^topic1$","^topic3$"]}'
Recuperación de la selección de temas
Puede recuperar la selección de reflejo utilizando las siguientes interfaces:
CLI:
ibmcloud es mirroring-topic-selection
API REST:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection
Recuperación de temas activos
Puede recuperar los temas que se están reflejando activamente utilizando las siguientes interfaces:
CLI:
ibmcloud es mirroring-active-topics
API REST:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/active-topics
Creación de aplicaciones que tienen en cuenta la duplicación
Productores
Recomendamos que los productores sólo produzcan a temas locales. La conmutación de un productor entre instancias normalmente requerirá un cambio de configuración, de modo que el productor utilice los puntos finales y credenciales correctos para conectarse.
Consumidores
Los consumidores deben suscribirse y consumir de temas locales y remotos. Esto se puede realizar con una suscripción con tarjeta comodín. Por ejemplo, para consumir de ambos, accounting.invoice y accounting.invoice.<ALIAS>,
utilice la suscripción a accounting.invoice.*.
Cuando consuma temas locales y remotos, compruebe si la aplicación requiere un orden estricto. En tal caso, los temas remotos deben consumirse por completo antes de empezar a consumir desde los temas locales. De este modo, los mensajes se procesan en el orden en el que se han producido.
Desplazamientos del consumidor
Cuando los datos de mensaje se duplican entre dos instancias, existen varias razones por las que los desplazamientos asignados al mensaje en la instancia de origen pueden no coincidir con el desplazamiento utilizado en la instancia de destino. Por ejemplo:
- Suprimir y volver a crear un tema con el mismo nombre en la instancia de origen.
- Temas de duplicación con una política de limpieza compacta.
- Generación de mensajes utilizando transacciones.
Parte del proceso de duplicación de mensajes realiza un seguimiento de qué desplazamientos en la instancia de origen son equivalentes a qué desplazamientos en la instancia de destino. Por razones de eficiencia, solo se realiza un seguimiento de un pequeño número de desplazamientos equivalentes, con ubicaciones cercanas a la cabecera del tema que se ven favorecidas. Cuando se confirman desplazamientos para grupos de consumidores en la instancia de origen, se convierten al desplazamiento equivalente más cercano en la instancia de destino y se confirma un desplazamiento correspondiente para el grupo en la instancia de destino. Esta conversión está pensada para asegurarse de que un consumidor que conmuta al clúster de destino no omita los mensajes que se han duplicado. Sin embargo, como el proceso de duplicación no realiza un seguimiento de cada desplazamiento equivalente, cuando un consumidor cambia a la instancia de destino es probable que vuelva a procesar los datos que ya ha consumido en la instancia de origen.
Al escribir aplicaciones que realizan un seguimiento del progreso del consumidor confirmando desplazamientos, tenga en cuenta lo siguiente:
- Los desplazamientos de consumidor sólo se duplican si el grupo de consumidores correspondiente no se utiliza activamente en la instancia de destino.
- Se espera volver a procesar algunos datos de mensaje cuando el consumidor se mueva a la instancia de destino.
- Cuanto más detrás de la cabecera del tema que un consumidor se mueve a la instancia de destino, más datos necesitará potencialmente volver a consumir.
- Si desea minimizar la cantidad de datos reconsumidos y puede gestionar cuidadosamente la conmutación de aplicaciones entre instancias, el conjunto de pasos recomendado para conseguirlo es:
- Deje de producir mensajes en la instancia de origen.
- Espere hasta que el consumidor alcance la cabeza del tema.
- Confirmar un desplazamiento en esta ubicación.
- Conmute el consumidor a la instancia de destino.
Supervisión de la duplicación
Puede supervisar la duplicación utilizando IBM Cloud Monitoring. Para habilitar la supervisión, consulte Supervisión de métricas de Event Streams. El panel de control Supervisión está disponible en el clúster de destino.
El panel de control Duplicación de Event Streams expone las siguientes métricas:
- Rendimiento de duplicación: los bytes por segundo del rendimiento de duplicación desde la instancia de Event Streams de origen. Esto es útil para ver si la duplicación está activa y para la planificación de la capacidad.
- Latencia de duplicación: la latencia de duplicación por tema en segundos desde la instancia de Event Streams de origen. Esto resulta útil para determinar el retraso de un tema sobre el clúster de destino.
Los datos que se producen dentro de la ventana de latencia podrían no estar presentes en el clúster de destino todavía y aún así podrían perderse si se produce un desastre en el clúster de origen. Sin embargo, si la duplicación está actualizada, la migración tras error mientras que los dos clústeres permanezcan en buen estado se puede realizar sin pérdida de datos.
Comprender los objetivos de recuperación con la duplicación
En un plan de protección de datos como la duplicación, el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) son parámetros clave. Debe comprender las decisiones asociadas a estos objetivos.
Puede supervisar el objetivo del punto de recuperación utilizando la métrica de latencia de réplica que se proporciona en el panel de control de réplica. Esta métrica muestra el retardo entre ambos clústeres, por lo que puede estimar la cantidad de pérdida de datos si se produce un desastre. Usted es responsable de supervisar ese valor y asegurarse de que encaja en su OPR.
El objetivo de tiempo de recuperación está completamente controlado por los usuarios y se compone de las siguientes ventanas de temporización:
- El tiempo que tarda el usuario en decidir conmutar por error.
- El tiempo que tarda el usuario en fallar sobre sus aplicaciones.
Pruebas
Realice una prueba de migración tras error una y otra vez cuando haya hecho que las aplicaciones tengan en cuenta la duplicación. Complete los pasos que se describen en el Caso de ejemplo de recuperación tras desastre y utilice los paneles de control de Supervisión para asegurarse de que todos los pasos se completan según lo esperado.
Eliminar y volver a crear temas con el mismo nombre en el clúster de origen
Cuando los temas se suprimen en el clúster de origen, el tema correspondiente del clúster de destino no se suprime automáticamente. Si posteriormente vuelve a crear el tema en el clúster de origen, los datos del nuevo tema en el clúster de origen se añadirán al final del tema existente en el clúster de destino.
Consideraciones para Kafka Streams y Kafka Connect
Kafka Streams y Kafka Connect confían en los temas internos con nombres específicos para almacenar el estado y la configuración. Cuando se duplican estos temas, se renombran en el clúster de destino. Por esta razón, las aplicaciones Kafka Streams y Kafka Connect no pueden conmutar por error y conmutar por defecto entre clústeres. Tenga esto en cuenta cuando planifique la recuperación tras desastre de dichas aplicaciones.