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.
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.
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.
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 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.
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.
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.
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.
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 |