Usando o espelhamento
O espelhamento permite que mensagens em uma instância de serviço Event Streams sejam copiadas continuamente para uma segunda instância. A resiliência do aplicativo pode ser melhorada usando espelhamento como se a primeira instância de serviço se tornasse indisponível, os aplicativos podem se reconectar à segunda instância e continuar sua operação normal.
Esse recurso faz parte do serviço totalmente gerenciado e pode ser usado somente entre instâncias de serviço que usam o plano Enterprise do Event Streams.
Recursos de espelhamento:
- Tópicos de espelho, dados de mensagem e deslocamentos de grupo de consumidores entre duas instâncias de serviço do Event Streams, que podem ser provisionadas em diferentes contas do IBM Cloud.
- ANS de 99.99% de disponibilidade, consistente com o serviço Event Streams.
- Pode ser monitorado usando o IBM Cloud® Monitoring.
Limitações de espelhamento:
- Unidirecional: os dados podem ser espelhados apenas em uma direção por vez entre um par de instâncias de serviço.. Isso significa que o espelhamento oferece um estilo "ativo-passivo" de alta disponibilidade, e não "ativo-ativo"
- Assíncrono: as mensagens devem ser produzidas com êxito para a instância de origem antes que possam ser espelhados para a instância de destino... Isso significa que, quando ocorre uma falha, o cluster de destino pode não ter todas as mensagens até o ponto exato da falha devido ao atraso na replicação e alguns dados de mensagens podem ser perdidos.
- Consumo de mensagem pelo menos uma vez: quando um consumidor se move entre as instâncias, pode ser necessário reprocessar mensagens que ele já processou.
Antes de iniciar o espelhamento, considere os seguintes pontos:
- Os aplicativos podem precisar ser modificados para aproveitar melhor o espelhamento..
- Assegure-se de que haja capacidade suficiente disponível para o tráfego de rede usado para espelhar dados entre instâncias.
Para ativar o espelhamento, consulte Guia de configuração de espelhamento.
Visão geral de espelhamento
O espelhamento de tópicos selecionados acontece entre dois clusters e é unidirecional, o que significa que os dados são espelhados em uma direção de um cluster de origem única para um cluster de destino único. Cada cluster possui um alias de
espelhamento Neste documento, A é usado para o alias do cluster de origem e B para o alias do cluster de origem. Os alias são configuráveis quando o espelhamento é ativado, portanto, por exemplo, eles podem ser "us-south"
e "us-east".
Um tópico chamado mytopic do cluster de origem (A) aparece no cluster de destino (B) como mytopic.A, indicando que é originário de A. Esse tipo de tópico é chamado de tópico remoto porque se origina
do cluster remoto (fonte). Por outro lado, todos os tópicos criados diretamente no cluster de destino pelos usuários são chamados de tópicos locais.
Para selecionar quais tópicos são espelhados, um padrão de expressão regular pode ser configurado usando os controles de usuário de espelhamento.
O espelhamento converte automaticamente compensações do consumidor entre as instâncias de origem e de destino. Em versões anteriores do Event Streams, os consumidores tinham que usar um tópico especial chamado A.checkpoints.internal (em que A é o alias do cluster de origem).. Isso não é mais necessário, no entanto, o tópico de ponto de verificação continua sendo criado e atualizado pelo processo de espelhamento para compatibilidade com versões anteriores
com aplicativos existentes. Os aplicativos que desejam usar o tópico de pontos de verificação podem usar o Kafka MirrorClient para simplificar o acesso aos dados mantidos neste tópico
Finalmente, por causa da nomenclatura de tópicos remotos:
- Evite usar aliases de cluster como parte dos nomes de recursos do Kafka
- Assegure-se de que o nome do tópico remoto (por exemplo, tópico de origem e alias do cluster de origem) não exceda o limite de comprimento para tópicos Kafka (249 caracteres). Se um nome de tópico remoto exceder esse limite, as mensagens não serão espelhadas para o tópico..
Planejamento de capacidade
O uso da rede e a localização geográfica das instâncias de serviço de origem e destino devem ser considerados ao planejar a capacidade.
Largura de banda da rede
A largura de banda da rede necessária para espelhar os tópicos selecionados deve ser considerada na permissão de largura de banda das instâncias de serviço de origem e de destino. Por exemplo, se 10 MB/s de tráfego de mensagens forem produzidos por aplicativos na instância de serviço de origem para os tópicos espelhados, serão necessários mais 10 MB/s de largura de banda de saída para espelhar essas mensagens na instância de destino. Isso deve ser permitido juntamente com qualquer largura de banda de saída existente que já esteja sendo usada por aplicativos de consumo. Os painéis de monitoramento podem ser usados para determinar o uso de rede em uma instância de serviço. Para obter mais informações, consulte Monitorando métricas do Event Streams.
Localização geográfica
Como ocorre com qualquer rede, o rendimento máximo alcançável é um fator da distância por meio da qual os dados são transmitidos (devido ao aumento de latência e à perda de pacote). Isso afeta a taxa de transferência máxima que pode ser obtida entre as instâncias de origem e de destino. Coloque as instâncias de serviço de destino em um local geograficamente o mais próximo possível da origem.
A tabela a seguir fornece orientações sobre a taxa de transferência alcançável ao espelhar a partir de uma instância de origem com capacidade de 150 MB/s.
| Regiões | Rendimento máximo por partição | Rendimento total máximo |
|---|---|---|
| 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 |
| dentro da mesma região eu-gb <-> eu-gb | 2,5 MB/s | 35 MB/s |
Os números indicam:
- Rendimento total máximo: o máximo total de MB/s que podem ser espelhados em todos os tópicos selecionados.
- Rendimento máximo por partição: o máximo de MB/s que pode ser espelhado dentro de uma única partição. Selecione o número de partições que estão configuradas para os tópicos de origem para garantir que a carga de partição permaneça dentro deste limite.
Exceder os limites resulta em um atraso crescente entre os dados nas instâncias de origem e de destino. Ter um grande atraso de dados pode resultar em uma quantia maior de dados da mensagem que serão perdidos se a instância de origem falhar Mesmo se o atraso entre as instâncias for zero, como o espelhamento é assíncrono, você deve antecipar que alguns dados podem ser perdidos se a instância de origem falhar. Os painéis de monitoramento podem ser usados para determinar a latência para cada tópico. Para obter mais informações, consulte Monitorando o espelhamento.
A orientação sobre o rendimento alcançável foi gerada usando mensagens de 100K produzidas em 50 partições de tópico Se a sua carga de trabalho usar tamanhos de mensagens menores (por exemplo, em 1K) ou menos partições, o espelhamento poderá não atingir esses níveis de rendimento.
Excluindo tópicos de destino redundantes
Para evitar a exclusão acidental de dados da instância de destino, os tópicos não são excluídos automaticamente dela quando são excluídos da origem. É de responsabilidade do usuário excluir os tópicos na instância de destino. Se tópicos espelhados são frequentemente excluídos e criados, mais disco de disco e partição pode ser consumido no cluster de destino. O uso pode ser monitorado com o painel de monitoramento no cluster de destino, consulte Monitorando Event Streams métricas. É possível excluir tópicos que não são mais necessários usando a CLI, a IU ou as interfaces de administrador
Políticas de acesso do IAM para espelhamento
Como os aplicativos precisam acessar os clusters de origem e destino, as políticas de acesso do IAM devem ser configuradas em ambos os clusters e usar a chave de API do ID de serviço ao qual as políticas estão anexadas. Podemos usar os recursos curingas do IAM Designando acesso usando políticas curingas para simplificar as políticas de acesso que controlam o acesso aos recursos espelhados.
Se você for novo em políticas de acesso do IAM, consulte Como o IBM Cloud IAM funciona e Gerenciando a autenticação para suas instâncias do Event Streams para obter mais detalhes..
Defina as seguintes políticas de acesso IAM em ambos os clusters, em que
A.checkpoints.internal.
| Tipo de recurso | ID do recurso | Função |
|---|---|---|
| cluster | Leitor | |
| Grupo | <RESOURCE_NAME>.* | Conforme necessário para o aplicativo |
| tópico | <RESOURCE_NAME>.* | Conforme necessário para o aplicativo |
| txnid | <RESOURCE_NAME>.* | Conforme necessário para o aplicativo |
| tópico (específico para o tópico do ponto de verificação) |
|
Leitor |
Conceder políticas de acesso fino-graude a aplicativos individuais. Por exemplo, para aplicativos simplesmente consumir concessão apenas acesso Leitor.
Para espelhar controles de usuário, é necessário ter as seguintes permissões no cluster de destino.
| Tipo de recurso | ID do recurso | Função |
|---|---|---|
| cluster | Gerente |
Restrições baseadas em contexto e controles de segurança de rede com Mirroring
O espelhamento segue um modelo baseado em pull, em que o cluster de destino inicia a conexão para extrair dados do cluster de origem. Esse modelo baseado em pull no espelhamento impõe controles de rede no cluster de origem, garantindo que somente o cluster de destino autorizado possa acessar os dados do cluster de origem.
Quando os controles de segurança de rede, como a restrição baseada em contexto (CBR) ou a lista de permissões de CSE, estão ativados, um caminho seguro no nível da rede e da identidade de segurança é definido pela adição de uma lista de permissões de ponto de extremidade de serviço ao cluster de origem, que inclui o IP do pod de espelhamento do cluster de destino. Essa configuração impõe um controle de acesso refinado no nível da infraestrutura, permitindo que apenas o ponto de extremidade de espelhamento autorizado (o cluster de destino) extraia dados do cluster de origem.
As credenciais compartilhadas entre o cluster de origem e o de destino são estritamente para o processo de espelhamento e não concedem acesso a nenhum outro recurso entre as implantações do Event Streams. Isso significa que o processo de espelhamento é isolado e seguro, impedindo o acesso não autorizado a outros recursos.
Esses controles de segurança de rede devem ser ativados antes da configuração do espelhamento. Se forem aplicadas restrições baseadas em contexto após a configuração do espelhamento, o espelhamento não será iniciado até que o cluster seja atualizado.
Se o CBR for ativado após o espelhamento:
- Abra um tíquete de suporte.
- Aguarde até o próximo ciclo de atualização do cluster (pelo menos 24 horas) para que as alterações tenham efeito.
- Inclua os endereços do nó espelho em suas regras de CBR.
- Desativar e reativar o espelhamento no cluster de destino.
Considerações quando você compartilha clusters entre várias entidades
Quando várias entidades, como diferentes unidades de negócios, estiverem compartilhando uma instância e precisarem ser isoladas umas das outras, siga as diretrizes de nomenclatura para simplificar o gerenciamento e a operação de clusters espelhados.
Nome Kafka recursos usando o modelo a seguir: < ENTITY_PREFIX> < SEPARATOR> < NAME>
Em que:
- < ENTITY_PREFIX> é o prefixo para a entidade que usa este tópico.
-
é um caractere opcional usado para separar facilmente os nomes das entidades e dos recursos. -
é o nome do recurso Kafka.
Por exemplo, se a unidade de negócios de contabilidade precisar de um tópico chamado faturas, você poderá chamá-lo de accounting.invoices.
As políticas de acesso necessárias devem ser ajustadas. Por exemplo, para a unidade de negócios de contabilidade, são necessárias as políticas a seguir no cluster B:
| Tipo de recurso | ID do recurso | Função |
|---|---|---|
| cluster | Leitor | |
| Grupo | contabilidade.* | Conforme necessário para o aplicativo |
| tópico | contabilidade.* | Conforme necessário para o aplicativo |
| txnid | contabilidade.* | Conforme necessário para o aplicativo |
| tópico (observe que isso é específico para o tópico do ponto de verificação) | A.checkpoints.internal | Leitor |
O cluster A deve ter as mesmas políticas de acesso, exceto a última, que deve estar em B.checkpoints.internal.
Controles do usuário de espelhamento
Você pode configurar o espelhamento usando o CLI ou API REST de Administração. Todos os controles do usuário de espelhamento são executados no cluster de destino.
Configurando a seleção de tópico
A seleção de espelhamento é feita com base nos nomes dos tópicos no cluster de origem usando padrões de expressão regular (regex). Escolha os nomes dos tópicos em seu cluster de origem cuidadosamente, ao considerar o conselho a partir das Considerações quando você compartilha clusters entre várias entidades seção.
Com nomes de tópicos bem estruturados, como inclusão de um prefixo em tópicos que fazem parte do mesmo grupo ou aplicativo, é fácil controlar o espelhamento. Com essa convenção de nomenclatura em vigor, todos os tópicos futuros que corresponderem ao padrão serão automaticamente espelhados sem a necessidade de mais alterações.
A seleção de tópicos é fornecida na forma de uma lista de um ou mais padrões regex. Um tópico será selecionado se ele corresponder a qualquer um dos padrões na lista
Alguns exemplos de padrões para selecionar tópicos para espelhamento:
| Padrões de exemplo | Explicação |
|---|---|
^topic1$ |
Nomes de tópicos completos. Isso corresponde apenas ao único tópico denominado topic1 |
^topic1$,^topic2$ |
Lista de padrões correspondentes a nomes de tópicos completos. Isso corresponde aos dois tópicos denominados topic1 e topic2 |
^aaa.* |
Corresponder no prefixo Isso corresponde a qualquer nome de tópico que inicia com aaa |
^aaa.*,^bbb.* |
Lista de padrões correspondentes no prefixo. Isso corresponde a qualquer nome de tópico que inicia com aaa ou bbb |
^branch_[0-9]{3}_[a-z]*$ |
Padrão de expressão regular mais complexo para corresponder nomes de tópicos. Isso corresponde a qualquer nome de tópico que começa com branch_, seguido por exatamente 3 dígitos, seguido por _ e qualquer
número de letras minúsculas |
.* |
Espelhar todos os tópicos de origem. |
Ao usar a CLI, os padrões são fornecidos como uma lista separada por vírgula. Por exemplo, o comando a seguir selecionará todos os tópicos cujo nome tenha o prefixo accounting ou hr..
ibmcloud es mirroring-topic-selection-set --select '^accounting.*,^hr.*'
O comando a seguir mostra como fazer a mesma seleção usando a API de REST de Administração Os padrões estão na forma de uma 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.*"]}'
A atualização de uma seleção de tópicos substitui o conjunto atual de padrões.
Para remover a seleção para que nenhum tópico seja espelhado, use a opção --none com a CLI ou um padrão vazio com a API REST de Administração, conforme a seguir.
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 desativar seletivamente o espelhamento, reaplique a seleção de tópicos, deixando de fora os padrões que você deseja desativar. Por exemplo, quando topic1, topic2, topic3 estão sendo espelhados no momento, os comandos a seguir desativam o espelhamento para topic2, mas deixam os outros dois ativados.
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$"]}'
Recuperando a seleção de tópico
Você pode recuperar a seleção de espelhamento usando as seguintes interfaces:
CLI:
ibmcloud es mirroring-topic-selection
API de REST:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection
Recuperando os tópicos ativos
Você pode recuperar os tópicos que estão sendo ativamente espelhados usando as seguintes interfaces:
CLI:
ibmcloud es mirroring-active-topics
API de REST:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/active-topics
Construindo aplicativos cientes do espelhamento
Produtores
Recomendamos que os produtores produzam apenas para os tópicos locais. Comutar um produtor entre instâncias geralmente exigirá uma mudança na configuração, para que o produtor use os terminais e as credenciais corretos para se conectar.
Consumidores
Os consumidores devem assinar e consumir tanto dos tópicos locais quanto remotos. Isso pode ser feito com uma assinatura curinga. Por exemplo, para consumir de ambos accounting.invoice e accounting.invoice.<ALIAS>,
use a assinatura para accounting.invoice.*.
Ao consumir ambos os tópicos locais e remotos, verifique se o aplicativo requer ordenação rígida. Nesse caso, os tópicos remotos devem ser totalmente consumidos primeiro, antes de você começar a consumir os tópicos locais. Dessa forma, as mensagens são processadas na ordem em que foram produzidas.
Deslocamentos de consumidores
Quando os dados da mensagem são espelhados entre duas instâncias, há várias razões pelas quais os deslocamentos designados à mensagem na instância de origem podem não corresponder ao deslocamento usado na instância de destino. Por exemplo:
- Excluindo e recriando um tópico com o mesmo nome na instância de origem.
- Espelhando tópicos com uma política de limpeza compacta.
- Produzindo mensagens usando transações
Parte das faixas do processo de espelhamento de mensagens que deslocam na instância de origem são equivalentes a quais deslocamentos na instância de destino. Para eficiência, apenas um pequeno número de deslocamentos equivalentes é rastreado, com locais próximos do cabeçalho do tópico sendo favorecidos Quando as compensações são confirmadas para grupos de consumidores na instância de origem, elas são convertidas para o deslocamento equivalente mais próximo na instância de destino e um deslocamento correspondente é confirmado para o grupo na instância de destino. Essa conversão é destinada a assegurar que um consumidor que alterna para o cluster de destino não ignore nenhuma mensagem que foi espelhada. No entanto, como nem todo deslocamento equivalente é rastreado pelo processo de espelhamento, quando um consumidor alterna para a instância de destino provavelmente reprocessará dados que ele já consumiu na instância de origem.
Ao gravar aplicativos que rastreiam o progresso do consumidor confirmando compensações, considere o seguinte:
- Os deslocamentos do consumidor serão espelhados apenas se o grupo de consumidores correspondente não estiver sendo usado ativamente na instância de destino
- Espere reprocessar alguns dados da mensagem quando o consumidor for movido para a instância de destino.
- Quanto mais atrás da cabeça do tópico um consumidor estiver quando se mover para a instância de destino, mais dados ele potencialmente precisará reconsumir.
- Se você desejar minimizar a quantia de dados reconsumidos e puder gerenciar cuidadosamente aplicativos de comutação entre instâncias, o conjunto recomendado de etapas para alcançar isso será:
- Pare de produzir mensagens na instância de origem.
- Espere até que o consumidor atinja o início do tópico.
- Confirme um deslocamento neste local
- Alterne o consumidor para a instância de origem.
Monitorando o espelhamento
Você pode monitorar o espelhamento usando IBM Cloud Monitoring. Para ativar o monitoramento, consulte Monitorando métricas do Event Streams. O painel Monitoramento está disponível no cluster de destino.
O painel Espelhamento do Event Streams expõe as métricas a seguir:
- Rendimento de espelhamento: os bytes por segundo de rendimento de espelhamento da instância do Event Streams de origem. Isso é útil para ver se o espelhamento está ativo e para o planejamento da capacidade.
- Latência de espelhamento: a latência de espelhamento por tópico em segundo da instância do Event Streams de origem. Isso é útil para determinar o quão atrás um tópico está no cluster de destino.
Os dados que são produzidos dentro da janela de latência podem ainda não estar presentes no cluster de destino e ainda podem ser perdidos se ocorrer um desastre no cluster de origem. No entanto, se o espelhamento estiver atualizado, o failover enquanto ambos os clusters permanecem funcionais poderá ser realizado sem qualquer perda de dados.
Entendendo os objetivos de recuperação com espelhamento
Em um plano de proteção de dados como o espelhamento, o objetivo do ponto de recuperação (RPO) e o objetivo do tempo de recuperação (RTO) são parâmetros de chave. Você deve entender as decisões associadas a esses objetivos.
Você pode monitorar o objetivo do ponto de recuperação usando a métrica de latência de espelhamento que é fornecida no painel Espelhamento. Esta métrica mostra o lag entre ambos os clusters, assim você pode estimar a quantidade de perda de dados caso ocorra um desastre. Você é responsável por monitorar esse valor e garantir que ele se encaixe no seu RPO.
O objetivo do tempo de recuperação é totalmente controlado pelos usuários e é composto das janelas de sincronização a seguir:
- O tempo que o usuário leva para decidir fazer o failover.
- O tempo que o usuário leva para fazer o fail over de seus aplicativos.
Teste
Teste falhando sobre e de volta quando você fez seus aplicativos espelharem-se cientes. Complete as etapas que estão delineadas no Cenário de exemplo de recuperação de desastres e use os painéis Monitoramento para garantir que todas as etapas sejam concluídas como esperado.
Exclusão e recriação de tópicos com o mesmo nome no cluster de origem
Quando os tópicos são excluídos no cluster de origem, o tópico correspondente no cluster de destino não é excluído automaticamente. Se você subsequentemente recriar o tópico no cluster de origem, os dados do novo tópico no cluster de origem serão anexados ao final do tópico existente no cluster de destino.
Considerações sobre o Kafka Streams e o Kafka Connect
O Kafka Streams e o Kafka Connect contam com tópicos internos com nomes específicos para armazenar o estado e a configuração. Quando esses tópicos são espelhados, eles são renomeados no cluster de destino. Por esse motivo, os aplicativos Kafka Streams e Kafka Connect não podem fazer failover e fail-back entre clusters. Considere isso quando planejar a recuperação de desastres de tais aplicações.