Acordo de Nível de Serviço (SLA) para disponibilidade do Event Streams

Plano padrão

O plano Standard do Event Streams fornece uma arquitetura altamente disponível por meio da implementação da região multizona. Em um local multizona, o serviço Event Streams é distribuído entre três zonas de disponibilidade, o que significa que o cluster é resiliente à falha de uma única zona ou de qualquer componente dentro dessa zona.

O serviço Event Streams é fornecido com disponibilidade de 99.99 % no Plano Padrão. Para obter mais informações sobre o SLA para serviços de alta disponibilidade no IBM Cloud®, consulte Acordos de nível de serviço para IBM Cloud(Nuvem pública).

Plano Enterprise

O plano Enterprise do Event Streams fornece uma arquitetura altamente disponível por meio da implementação da região multizona. Em um local multizona, o serviço Event Streams é distribuído entre três zonas de disponibilidade, o que significa que o cluster é resistente à falha de uma única zona ou de qualquer componente dentro dessa zona.

Em uma implementação de região com várias zonas, o serviço Event Streams é fornecido com disponibilidade de 99.99 % no plano Enterprise. Para obter mais informações sobre o ANS para serviços de alta disponibilidade no IBM Cloud, consulte Acordos de Nível de Serviço para IBM Cloud(Nuvem Pública).

Quando o serviço Event Streams é executado em uma configuração não altamente disponível, como em locais de zona única, a disponibilidade é de 99.9 %. Para obter mais informações sobre o SLA para serviços não altamente disponíveis no IBM Cloud, consulte Acordos de nível de serviço para IBM Cloud(Nuvem pública).

Como medi-lo?

As instâncias de serviço são monitoradas continuamente para desempenho, taxas de erro e sua resposta a operações sintéticas. As indisponibilidades são registradas. Para obter mais informações, consulte Status do serviço para Event Streams.

Disponibilidade refere-se à capacidade de aplicativos produzirem e consumirem mensagens de tópicos do Kafka.

O que deve ser considerado para obter essa disponibilidade?

Para obter altos níveis de disponibilidade da perspectiva do aplicativo, é necessário considerar a conectividade, o rendimento e a consistência e a durabilidade das mensagens. Os usuários são responsáveis por projetar seus aplicativos para otimizar esses três elementos para seus negócios.

Conectividade

Devido à natureza dinâmica da nuvem, os aplicativos devem esperar quebras de conexão. Uma quebra de conexão não é considerada uma falha de serviço.

Novas tentativas

Os clientes Kafka fornecem a lógica de reconexão, mas deve-se ativar explicitamente reconexões para produtores. Para obter mais informações, consulte a propriedade retries. As conexões são refeitas dentro de 60 segundos.

Duplicatas

A ativação de novas tentativas pode resultar em mensagens duplicadas. Dependendo de quando uma conexão é perdida, o produtor pode não conseguir determinar se uma mensagem foi processada com sucesso pelo servidor e, portanto, deve enviar a mensagem novamente quando reconectada. Aplicativos de design para esperar mensagens duplicadas.

Se duplicatas não puderem ser toleradas, será possível usar o recurso de produtor do idempotent (do Kafka 1.1) para evitar duplicatas durante as novas tentativas. Para obter mais informações, consulte a propriedade enable.idempotence.

Rendimento

O rendimento é expresso como o número de bytes por segundo que podem ser enviados e recebidos em um cluster.

Orientação específica para o plano Standard

Para obter informações sobre a orientação de rendimento, consulte Limites e cotas - Standard.

Orientação específica para o plano Enterprise

Para obter informações de orientação de rendimento, consulte Limites e cotas - Corporativo.

Medição

Os aplicativos de instrumentos para estar cientes de como eles estão se apresentando. Por exemplo, o número de mensagens enviadas e recebidas, os tamanhos das mensagens e os códigos de retorno. Entender o uso de um aplicativo ajuda a configurar seus recursos apropriadamente, como o tempo de retenção para mensagens nos tópicos.

Saturação

À medida que o limite do tráfego que pode ser produzido no cluster se aproxima, os produtores começam a ser regulados, a latência aumenta e, em última instância, ocorrem erros, como erros de tempo limite. Dependendo da configuração, a consistência e a durabilidade da mensagem também podem ser impactadas. Para obter mais informações, consulte Consistência e durabilidade das mensagens.

Consistência e durabilidade das mensagens

O Kafka atinge sua disponibilidade e durabilidade ao replicar as mensagens que recebe através de outros nós do cluster, que podem, então, ser usados em caso de falha. O Event Streams usa três réplicas (default.replication.factor = 3), o que significa que cada mensagem recebida por um nó é replicada para dois outros nós em zonas de disponibilidade diferentes. Dessa maneira, a perda de um nó ou da zona de disponibilidade pode ser tolerada sem perda de dados ou função.

Modo de produtor do `acks`

Embora todas as mensagens sejam replicadas, os aplicativos podem controlar a robustez com que as mensagens que produzem são transferidas para o serviço usando a propriedade acks mode do produtor. Essa propriedade fornece uma opção entre a velocidade e o risco de perda da mensagem. Com o Kafka 3.0, a configuração do cliente padrão é acks=all (antes desta versão era acks=1). A configuração acks=all significa que o produtor retorna sucesso, assim que o broker ao qual ele está conectado e pelo menos um broker adicional no cluster, tiver recebido a mensagem. A vantagem de usar o acks=all é que ele oferece o nível mais alto de durabilidade e, portanto, proteção contra a perda de dados da mensagem

Réplicas em sincronização

Na configuração que o Event Streams usa, o Kafka escolhe um broker para ser o líder para cada réplica de partição e dois outros brokers para serem seguidores. Os dados da mensagem dos clientes são enviados para o líder da partição e são replicados para os seguidores. Se os seguidores estão acompanhando o líder, eles são considerados réplicas "in-sync". O líder, por definição, é sempre considerado sincronizado.

Se o líder para uma partição se tornar indisponível, talvez devido à manutenção estar sendo aplicada ao broker, o Kafka elegerá automaticamente uma das outras réplicas em sincronização para se tornar o novo líder. Esse processo ocorre rapidamente e é manipulado automaticamente por clientes do Kafka

Eleições de líderes impuros

Event Streams desativa as eleições líderes não limpas. Essa configuração não pode ser alterada.

O termo eleição de líder não limpo descreve como o Kafka responde em uma situação em que toda a réplica em sincronização para uma partição se torna indisponível. Quando as eleições de líder não limpas são ativadas, o Kafka é recuperado tornando a primeira réplica disponível para o líder para a partição, independentemente de ela estar em sincronização. Isso pode fazer com que os dados da mensagem sejam perdidos se a réplica selecionada para ser líder não tiver replicado todos os dados da mensagem do líder anterior Quando as eleições de líder não limpas são desativadas (como é o caso para Event Streams), o Kafka aguarda que uma réplica em sincronização se torne disponível e o elege como o novo líder para a partição. Isso evita o potencial de perda de dados da mensagem que pode ocorrer quando as eleições de líder não limpas são ativadas A compensação é que a recuperação pode demorar mais porque o Kafka pode ter que esperar que um broker específico seja colocado on-line novamente antes que uma partição esteja disponível para os clientes produzirem e consumirem dados da mensagem.

Implementações de localização de zona única

Para a mais alta disponibilidade, recomendamos nossos ambientes públicos de alta disponibilidade que são construídos em nossas localizações de multizona. Em uma localização de multizona, os clusters Kafka são distribuídos em três zonas de disponibilidade, o que significa que o cluster é resiliente à falha de uma zona única ou de qualquer componente dentro dessa zona. Alguns clientes exigem localidade geográfica e, portanto, desejam provisionar um cluster Event Streams em um local geograficamente local, mas de zona única. O site Event Streams oferece suporte a esse modelo de implementação, mas esteja ciente das seguintes compensações de disponibilidade:

Em uma localização de zona única, há categorias de falhas únicas que podem deixar o cluster off-line por um período de tempo. Por exemplo, a falha de um data center inteiro ou a atualização ou falha de um componente compartilhado, como o hypervisor subjacente, a SAN ou a rede. Essas falhas são refletidas no SLA reduzido para localizações de zona única.
Uma vantagem de distribuir o Kafka em várias zonas é minimizar a chance de uma falha que possa derrubar um cluster inteiro. Por outro lado, existe a pequena possibilidade de que uma única falha possa derrubar todo o cluster em uma zona. Em casos extremos, há também o potencial de perda de dados. Por exemplo, mesmo que o acks=all seja usado pelos produtores, se todos os nós Kafka descerem simultaneamente, poderá haver algumas mensagens para as quais os brokers reconheceram o recebimento, mas o sistema de arquivos subjacente não concluiu a liberação para o disco. Potencialmente, essas mensagens não liberadas podem ser perdidas.

Para obter mais informações, consulte Confirmações de mensagem. Em muitos casos de uso, não há necessariamente um problema. No entanto, se a perda de mensagem for inaceitável sob qualquer circunstância, considere outras estratégias, como o uso de um cluster de zona de múltiplas disponibilidades, replicação de região cruzada ou ponto de verificação de mensagem do lado do produtor.

Para obter mais informações, consulte Clusters de zona única e Clusters multizona.