Alta Disponibilidade

Com alta disponibilidade, o WebSphere eXtreme Scale fornece redundância de dados confiáveis e detecção de falhas.

O WebSphere eXtreme Scale organiza automaticamente as grades de dados do Java Virtual Machines em uma árvore vagamente federada. O serviço de catálogo na raiz e os grupos principais que mantêm os contêineres estão nas folhas da árvore. Consulte Arquitetura de Armazenamento em Cache: Mapas, Contêineres, Clientes e Catálogos para obter mais informações.

Cada grupo principal é automaticamente criado pelo serviço de catálogo em grupos de cerca de 20 servidores. Os membros do grupo principal fornecem monitoramento de funcionamento para outros membros do grupo. Também, cada grupo principal elege um membro para ser o líder para comunicar as informações do grupo para o serviço de catálogo. Limitar o tamanho do grupo principal permite o bom monitoramento de funcionamento e um ambiente altamente escalável.
Nota: Em um ambiente do WebSphere Application Server, no qual o tamanho do grupo principal pode ser alterado, oeXtreme Scale não suporta mais de 50 membros por grupo principal.

Pulsação

  1. Os soquetes são mantidos abertos entre o Java Virtual Machines e se um soquete for fechado inesperadamente, esse fechamento inesperado será detectado como uma falha do peer Java Virtual Machine. Essa detecção captura casos de falha, como a Java Virtual Machine saindo rapidamente. Tal detecção permite a recuperação desses tipos de falhas normalmente em menos de um segundo.
  2. Outros tipos de falhas incluem: um pânico no sistema operacional, uma falha física do servidor ou falha de rede. Essas falhas são descobertas por meio de pulsação.
Pulsações são enviadas periodicamente entre pares de processos: Quando um número fixo de pulsações está ausente, é assumida uma falha. Essa abordagem detecta falhas em N*M segundos, em que N é o número de pulsações ausentes e M é o intervalo de pulsações. Especificar diretamente M e N não é suportado. Um mecanismo de régua de controle é usado para permitir que um intervalo de combinações de M e N testadas seja usado.

Falhas

Um processo pode falhar de várias maneiras. o processo poderia falhar porque algum limite de recurso foi atingido, tal como o tamanho máximo do heap ou alguma lógica de controle de processo terminou um processo. O sistema operacional poderia falhar, fazendo com que todos os processos em execução no mesmo sistema fossem perdidos. O hardware poderia falhar, embora com menos frequência, como a NIC (placa da interface de rede), fazendo com que o sistema operacional fosse desconectado da rede. Muitos outros pontos de falha podem ocorrer, fazendo com que o processo se torne indisponível. Neste contexto, todas estas falhas podem ser categorizadas em um dos dois tipos: falha de processo e perda de conectividade.

Falha de Processo

O WebSphere eXtreme Scale reage às falhas de processo rapidamente. Quando um processo falha, o sistema operacional é responsável pela limpeza de qualquer recurso pendente que o processo estava utilizando. Essa limpeza inclui a alocação e conectividade da porta. Quando um processo falha, um sinal é enviado para as conexões que estavam sendo utilizadas por esse processo para fechar cada conexão. Com estes sinais, uma falha de processo pode ser detectada instantaneamente por qualquer outro processo que está conectado ao processo falho.

Perda de Conectividade

A perda de conectividade ocorre quando o sistema operacional se desconecta. Como resultado, o sistema operacional não pode enviar sinais a outros processos. Há diversos motivos pelos quais pode ocorrer uma perda de conectividade, mas eles podem ser divididos em duas categorias: falha de host e insulamento.

Falha de Host

Se a máquina for desconectada da tomada de energia, ela desligará instantaneamente.

Insulamento

Este cenário apresenta a condição de falha mais complicada para o software tratar corretamente porque o processo é presumido como indisponível, embora não esteja. Essencialmente, um servidor ou outro processo aparece para o sistema com falho enquanto, de fato, está executando adequadamente.

Falhas do Contêiner

Falhas contêiner geralmente são descobertas por contêineres peer através do mecanismo de grupo principal. Quando um contêiner ou conjunto de contêineres falha, o serviço de catálogo migra os fragmentos que foram hospedados nesse contêiner ou contêineres. O serviço de catálogo procura uma réplica síncrona primeiro, antes de migrar para uma réplica assíncrona. Depois da migração dos fragmentos primários para os novos contêineres de host, o serviço de catálogo procura novos contêineres de host para as réplicas que agora estão faltando.

Nota: Ilhamento de contêiner - O serviço de catálogo migrará os shards a partir dos contêineres quando o contêiner for detectado como indisponível. Se esses contêineres se tornarem disponíveis, o serviço de catálogo considerará os contêineres elegíveis para disposição como no fluxo de inicialização normal.

Latência de detecção de falha do contêiner

As falhas podem ser categorizadas em falhas brandas e falhas graves. Falhas brandas normalmente são causadas quando um processo falha. Tais falhas são detectadas rapidamente pelo sistema operacional, que pode recuperar recursos usados, como soquetes de rede. A detecção de falha típica para falhas brandas é de menos de um segundo. A falhas graves podem demorar até 200 segundos para serem detectadas com o ajuste de pulsação padrão. Tais falhas incluem: travamentos da máquina física, desconexões de cabo de rede ou falhas do sistema operacional. O tempo de execução depende da pulsação para detectar falhas graves que podem ser configuradas.

Falha de Serviço de Catálogo

Porque a grade de serviço do catálogo é uma grade do eXtreme Scale, ela também usa o mecanismo de agrupamento principal da mesma forma que o processo de falha de contêiner. A principal diferença é que o domínio do serviço de catálogo usa um processo de eleição de peer para definir o shard principal em vez do algoritmo do serviço de catálogo usado para os contêineres.

O serviço de posicionamento e o serviço de agrupamento principal são Um dos serviços N. Um serviço Um de N é executado em um membro do grupo de alta disponibilidade. O serviço de local e a administração são executados em todos os membros do grupo de alta disponibilidade. O serviço de disposição e o serviço de agrupamento principal são singletons porque são responsáveis pela configuração do sistema. O serviço de local e a administração são serviços somente leitura e existe em qualquer lugar para fornecer escalabilidade.

O serviço de catálogo usa a replicação para tornar-se tolerante a falhas. Se um processo de serviço de catálogo falhar, o serviço será reiniciado para restaurar o sistema para o nível desejado de disponibilidade. Se todos os processos que estiverem hospedando o serviço de catálogo falharem, a grade de dados perderá dados críticos. Essa falha resulta em um reinício necessário de todos os servidores de contêiner. Como o serviço de catálogo pode ser executado em muitos processos, essa falha é um evento improvável. Entretanto, se você estiver executando todos os processos em uma única caixa, dentro de um único chassi de blade, ou de um único comutador de rede, será mais provável que uma falha ocorra. Tente remover os modos de falha comuns das caixas que estão hospedando o serviço de catálogo para reduzir a possibilidade de falha.

Várias Falhas de Contêiner

Uma réplica nunca é colocada no mesmo processo que seu primário porque, se o processo for perdido, isso resultará na perda do primário e da réplica. Em um ambiente de implantação em uma única máquina, talvez você queira ter dois contêineres e replicar entre eles. É possível definir o atributo de modo de desenvolvimento na política de desenvolvimento para configurar uma réplica a ser colocada na mesma máquina que o primário. Entretanto, na produção, o uso de uma única máquina não é suficiente porque a perda de tal host resulta na perda de ambos os servidores de contêiner. Para alterar entre o modo de desenvolvimento em uma máquina única e um modo de produção com várias máquinas, desative o modo de desenvolvimento no arquivo de configuração da política de implementação.

Tabela 1. Resumo de Descoberta de Falha e Recuperação
Tipo de perda Mecanismo de descoberta (detecção) Método de recuperação
Perda de processo E/S Reiniciar
Perda de servidor Pulsação Reiniciar
Interrupção da rede Pulsação Reestabelecer rede e conexão
Interrupção do lado do servidor Pulsação Parar e reiniciar servidor
Servidor ocupado Pulsação Aguardar até servidor estar disponível