Alta disponibilidade se refere a uma metodologia de design que se destina a manter um sistema disponível para uso enquanto for prático. A intenção é minimizar as causas de tempo de espera, como falhas e manutenção do sistema, e minimizar o tempo que demorará para detectar e recuperar de eventos de tempo de espera ocorridos. Na prática, os meios automatizados de detecção e recuperação de eventos de tempo de espera tornam-se rapidamente necessários à medida que níveis mais altos de disponibilidade devem ser obtidos.
O Sentinel é um aplicativo multicamadas complexo que depende de (e fornece) uma ampla variedade de serviços. Adicionalmente, ele se integra com vários sistemas de terceiros externos para coleção de dados, compartilhamento de dados e remediação de incidente. A maioria das soluções de alta disponibilidade permite que os implementadores declarem as dependências entre os serviços que devem estar altamente disponíveis e os serviços dependentes, mas isso se aplica apenas a serviços em execução no próprio cluster. Sistemas externos ao Sentinel, por exemplo, fontes de evento, devem ser configurados separadamente para estarem tão disponíveis quanto a organização necessita, e também devem ser configurados adequadamente para manipular situações quando o Sentinel estiver indisponível por algum período de tempo, como um evento de failover. Se os direitos de acesso estiverem firmemente restritos, por exemplo, se sessões autenticadas forem usadas para enviar/receber dados entre o sistema de terceiro e o Sentinel, então, o sistema de terceiro deverá ser configurado para aceitar sessões de origem ou iniciar sessões para qualquer nó de cluster (o Sentinel deve ser configurado com um IP virtual para esse fim). O NetIQ não pode garantir nenhum nível específico de alta disponibilidade entre o nosso produto e os sistemas de terceiros fora de nosso controle.
Todos os clusters de alta disponibilidade requerem algum formulário de armazenamento compartilhado de modo que os dados de aplicativo possam ser rapidamente movidos de um nó do cluster para outro, no caso de uma falha do nó de origem. O próprio armazenamento deve estar altamente disponível; isso é normalmente obtido usando a tecnologia SAN (Storage Area Network) conectada aos nós do cluster que usam uma rede Fibre Channel. Outros sistemas usam NAS (Network Attached Storage), iSCSI ou outras tecnologias que levam em conta a montagem remota do armazenamento compartilhado. O requisito fundamental do armazenamento compartilhado é que o cluster possa mover de forma limpa o armazenamento de um nó do cluster com falha para um novo nó do cluster.
NOTA:Para iSCSI, você precisa usar a maior Unidade de transferência de mensagem (MTU) suportada pelo hardware. MTUs maiores oferecem benefícios ao desempenho do armazenamento. O Sentinel pode apresentar problemas se a latência e/ou largura de banda para o armazenamento for mais lenta do que o recomendado.
Há duas abordagens básicas que o Sentinel pode usar para o armazenamento compartilhado. O primeiro localiza todos os componentes - binários de aplicativo, configuração e dados de evento - no armazenamento compartilhado. No failover, o armazenamento é desmontado do nó primário e movido para o nó de backup, que carrega o aplicativo inteiro e a configuração do armazenamento compartilhado. A segunda abordagem armazena os dados do evento no armazenamento compartilhado, mas os binários de aplicativo e a configuração residem em cada nó do cluster. No failover, apenas os dados de evento são movidos para o nó de backup.
Cada abordagem tem benefícios e desvantagens, mas a segunda abordagem permite que a instalação do Sentinel use caminhos de instalação compatíveis com o FHS padrão, leve em consideração a verificação do pacote RPM, além do patch a quente e reconfiguração para minimizar o tempo de espera.
Essa solução o conduzirá por um exemplo de processo de instalação para um cluster que usa o armazenamento compartilhado iSCSI e localiza os binários de aplicativo/configuração em cada nó do cluster.
Um componente principal de qualquer ambiente altamente disponível é um modo confiável e consistente de monitorar os recursos que devem ser altamente disponíveis, junto com quaisquer recursos dos quais sejam dependentes. O SLE HAE usa um componente chamado Agente de Recurso para executar esse monitoramento - o trabalho do Agente de Recurso deve fornecer o status de cada recurso, além de (quando perguntado) iniciar ou parar o recurso.
Os Agentes de Recurso devem fornecer um status confiável para recursos monitorados para prevenir tempo de espera desnecessário. Falsos positivos (quando um recurso é considerado como tendo falhado, mas pode, na verdade, recuperar-se por conta própria) podem causar a migração do serviço (e tempo de espera relacionado), quando não são, de fato, necessários; e falsos negativos (quando o Agente de Recurso reporta que um recurso está funcionando mas, na verdade, ele não está funcionando corretamente) podem impedir o uso adequado do serviço. Por outro lado, o monitoramento externo de um serviço pode ser um tanto difícil - uma porta de serviço da web pode responder a um simples ping, por exemplo, mas pode não fornecer dados corretos quando uma consulta real é emitida. Em muitos casos, a funcionalidade de autoteste deve estar integrada no próprio serviço para fornecer uma mediação verdadeiramente precisa.
Essa solução fornece um Agente de Recurso OCF para Sentinel que pode monitorar uma falha principal do hardware, sistema operacional ou sistema do Sentinel. A essa altura, os recursos de monitoramento externos do Sentinel estão baseados nas investigações de porta IP, e há algum potencial para leituras de falso positivo e falso negativo. Planejamos melhorar o Sentinel e o Agente de Recurso com o decorrer do tempo para aprimorar a precisão desse componente.
Dentro de um cluster de alta disponibilidade, os serviços críticos são constantemente monitorados e reiniciados automaticamente em outros nós, no caso de falha. Essa automação pode introduzir problemas, no entanto, se ocorrer algum problema de comunicação com o nó primário, embora o serviço em execução nesse nó pareça estar inativo, na verdade, ele continua a executar e gravar dados no armazenamento compartilhado. Nesse caso, iniciar um novo conjunto de serviços em um nó de backup pode facilmente causar corrupção de dados.
Os clusters usam uma variedade de técnicas, coletivamente chamadas de fencing, para prevenir que isso aconteça, incluindo SBD (Detecção de split brain) e STONITH (Atirar na cabeça do outro nó). O primeiro objetivo é prevenir a corrupção de dados no armazenamento compartilhado.