Considerações sobre Escalonamento do Grupo Principal
A quantidade de recursos do sistema, como CPU e memória, consumidos pelo gerenciador de alta disponibilidade não aumenta linearmente com o aumento do tamanho de um grupo principal. Por exemplo, o Protocolo de Sincronia de Visualização utilizado pelo gerenciador de alta disponibilidade requer uma grande quantidade desses recursos para manter um acoplamento rígido sobre os membros do grupo principal. Portanto, a quantidade de recursos consumidos por um grande grupo principal pode tornar-se significativa.
- Pelo número de aplicativos em execução.
- Pelo tipo de aplicativos em execução.
- Pelos serviços do gerenciador de alta disponibilidade utilizados.
Ao configurar a escalabilidade do grupo principal, é necessário assegurar-se de que:
- Todos os processos da célula sejam distribuídos adequadamente nos grupos principais de tamanhos apropriados. A distribuição adequada desses processos limita a quantidade de recursos consumida pelo Protocolo de Sincronia de Visualização.
- Todos os processos de um determinado grupo principal sejam configurados adequadamente para suportar os serviços de alta disponibilidade utilizados no grupo principal.
Considere a implementação de uma ou mais das técnicas de escalabilidade a seguir para escalar o gerenciador de alta disponibilidade em células grandes, mesmo que seu sistema esteja operando adequadamente. As duas técnicas mais básicas são:
- Desativar o gerenciador de alta disponibilidade se ele não for requerido.
- Distribuir os processos entre vários grupos principais e utilizar uma ponte do grupo principal para conectar-se a grupos principais, conforme necessário.
Ajustando o Tamanho de um Grupo Principal
- O primeiro e mais significativo aspecto é o estabelecimento do Protocolo de Sincronia de Visualização sobre um conjunto de membros ativos do grupo principal. Essa atividade é referida geralmente como alteração na visualização.
- O segundo aspecto são as tarefas de descoberta e de detecção de falha planejadas regularmente, executadas pelo gerenciador de alta disponibilidade no segundo plano.
- O terceiro aspecto é o uso de recursos que resulta quando outros componentes do produto utilizam serviços fornecidos pelo gerenciador de alta disponibilidade.
- Alterações na Visualização
O Protocolo de Sincronia de Visualização cria uma nova visualização sempre que detecta alterações em membros ativos do grupo principal. Uma alteração na visualização ocorre, normalmente, sempre que um membro do grupo principal é iniciado ou parado. Quando um membro do grupo principal é iniciado, ele abre uma conexão com todos os outros membros do grupo principal em execução. Quando um membro do grupo principal é parado, outros membros do grupo detectam que suas conexões abertas com o membro parado são fechadas. Seja qual for o caso, o Protocolo de Sincronia de Visualização precisa contabilizar essa alteração. No caso de um membro recém-iniciado, o Protocolo de Sincronia de Visualização deve estabelecer uma visualização que inclua o novo membro. No caso de um membro parado, o Protocolo de Sincronia de Visualização deve estabelecer uma nova visualização para os membros sobreviventes do grupo principal que exclua o membro parado.
Estabelecer uma nova visualização é uma atividade importante, mas utiliza muitos recursos do sistema, especialmente para grupos principais grandes.- Cada membro do grupo principal em execução deve comunicar seu estado atual para outros membros do grupo principal, incluindo informações sobre as mensagens enviadas ou recebidas na visualização atual.
- Todas as mensagens enviadas em uma determinada visualização devem ser recebidas e confirmadas por todos os destinatários para que uma nova visualização seja instalada. Sob condições normais de operação, o recebimento dessas mensagens é confirmado lentamente. Concluir mensagens em um limite de alteração de visualização adequado, requer reconhecimento e retransmissão dinâmicos.
- Todos os membros do grupo principal devem transmitir dados relativos a seus estados atuais, como o conjunto de outros membros do grupo principal com os quais eles podem comunicar-se ativamente.
Conforme o número de membros ativos cresce, a instalação de uma nova visualização requer um aumento não-linear temporário maior no uso da CPU do gerenciador de alta disponibilidade. É significativamente mais caro incluir ou remover um único membro quando existem outros 50 membros do grupo principal, do que é incluir ou remover um membro quando existem 20 outros membros.
A instalação de uma nova visualização também aciona alterações de estado nos componentes do produto que utilizam o gerenciador de alta disponibilidade. Por exemplo, o roteamento de tabelas precisa ser atualizado para refletir o membro iniciado ou parado ou um serviço singleton pode precisar ser reiniciado em um novo membro.
O resultado final é que a instalação de uma nova visualização causa picos transientes significativos no uso da CPU. Se um grupo principal aumentar muito, ocorrerão condições de sincronização de rede degenerativas no limite de alteração da visualização. Essas condições resultam geralmente em falha durante tentativas de instalação de uma nova visualização. A recuperação dessa falha também consome muito a CPU. Quando há CPU insuficiente disponível ou ocorre paginação, as falhas podem multiplicar-se rapidamente.
- Tarefas em segundo plano
O gerenciador de alta disponibilidade executa, periodicamente, várias tarefas em segundo plano, como a verificação do funcionamento de singletons altamente disponíveis que estão sendo gerenciados. A maioria dessas tarefas em segundo plano consome quantidades insignificantes de CPU. As exceções são os Protocolos de Descoberta e de Detecção de Falha planejados regularmente.
O Protocolo de Descoberta tenta estabelecer comunicações entre os membros do grupo principal não conectados atualmente, incluindo processos que não estão em execução. Para um determinado grupo principal que contém membros do grupo principal N, dos quais M estão atualmente em execução, cada período de descoberta resultará em mensagens de descobertas aproximadamente M x (N – M). Portanto, a criação de um grande número de processos que nunca são iniciados afeta desfavoravelmente o uso da CPU do Protocolo de Descoberta.
De forma semelhante, quando o Protocolo de Detecção de Falha é executado, cada membro do grupo principal envia pulsações para todas suas conexões estabelecidas com outros membros do grupo principal. Para os membros ativos M, são enviadas mensagens de pulsação M x (M-1). Se for necessária uma detecção de falha mais dinâmica, o tamanho do grupo principal poderá afetar desfavoravelmente a quantidade de uso da CPU consumida pela pulsação entre os membros do grupo principal.
Grupos principais menores afetam positivamente a quantidade de uso da CPU consumida por esses dois protocolos. Por exemplo, se um grupo principal contiver 100 membros ativos, serão enviadas 9.900 mensagens de pulsação durante cada período de detecção de falha. Dividir o grupo principal com 100 membros em cinco grupos principais menores com 20 membros reduzirá esse número de mensagens para 1.900, que é uma redução significativa.
- Uso externo
- Outros componentes do produto, como gerenciamento de carga de trabalho (WLM) e configuração on demand, utilizam serviços fornecidos pelo gerenciador de alta disponibilidade, como mudança de estado do servidor ativo, para manter as informações de rotina. A quantidade de uso da CPU consumida por esses componentes está vinculada ao tamanho do grupo principal. Por exemplo, o uso da troca de estado do servidor ativo para construir informações de roteamento altamente disponíveis está vinculado ao tamanho do grupo principal.
Distribuindo Processos entre Vários Grupos Principais
- Você pode desativar o gerenciador de alta disponibilidade em processos nos quais os serviços fornecidos por ele não são utilizados.
- Você pode manter os grupos principais pequenos.
A chave para limitar o uso da CPU do gerenciador de alta disponibilidade é limitar o tamanho do grupo principal. Vários grupos principais pequenos é muito melhor que um grupo principal grande. Se você tiver células grandes, crie vários grupos principais.
O hardware no qual você está executando o produto também é um fator na determinação do tamanho do grupo principal apropriado ao seu ambiente.
Divida os grupos principais grandes em vários grupos principais menores. Se os grupos principais resultantes precisarem compartilhar informações de roteamento, utilize pontes do grupo principal para unir os grupos.
Tamanhos do Grupo Principal
- Ao ativar a propriedade customizada IBM_CS_WIRE_FORMAT_VERSION do grupo principal da configuração com um valor de 6.1.0, é possível obter melhorias no protocolo interno do grupo principal. Essas melhorias só estão disponíveis na Versão 6.1 e nas versões posteriores.
- Ao ativar a propriedade customizada IBM_CS_HAM_PROTOCOL_VERSION do grupo principal da configuração com um valor de 6.0.2.31, é possível obter melhorias significativas na utilização da memória e nas características de failover das pontes de grupos principais.
- É possível ajustar as configurações da memória do transporte. Existem duas configurações de memória ou de tamanho do buffer associadas ao transporte do grupo principal.
Os valores padrão dessas configurações são suficientes para grupos principais pequenos de 50 membros ou menos. Para grupos principais com mais de 50 membros, o valor dessas configurações devem ser maiores que os valores padrão. Nota: O aumento do valor dessas configurações da memória do transporte não se traduz diretamente em uma memória alocada de forma mais estatística ou no uso da memória a longo prazo pelo High Availability Manager.
- Grupos principais de até 100 membros devem trabalhar sem problemas.
- Grupos principais contendo mais de 100 membros devem trabalhar sem problemas em muitas topologias. Não é recomendável que um grupo principal exceda 200 membros.
Ajustando Grupos Principais Individuais com Base na Mistura de Aplicativos e Serviços Utilizados
Talvez seja necessário ajustar ainda mais os grupos principais individuais com base na mistura de aplicativos e nos serviços de alta disponibilidade utilizados pelos membros do grupo principal.
- Ajuste a frequência com que o Protocolo de Descoberta padrão e o Protocolo de Detecção de Falha padrão são executados, se as configurações padrão não forem apropriadas.
- Configure o coordenador de grupo principal a ser executado em um processo específico ou um conjunto de processos.
- Particione o coordenador entre várias instâncias se o consumo de recursos pelo processo coordenador for significativo.
- Configure a quantidade de memória disponível para os serviços de distribuição e consistência (DCS) e para os componentes de reliable multicast messaging (RMM) para o envio de mensagens de rede quando for detectado um congestionamento. O congestionamento pode ocorrer sob determinadas condições, embora a replicação memória a memória não seja utilizada.
Ajustando Intervalos de Portas Transitórias
O número de soquetes utilizado por um grupo principal geralmente não é um problema importante. Cada membro do grupo principal deve estabelecer uma conexão com cada um dos outros membros desse grupo principal. Portanto, o número de conexões cresce exponencialmente (n ao quadrado) porque cada conexão requer dois soquetes, um em cada extremidade da conexão. Como normalmente várias máquinas são envolvidas, é provável que você não tenha problemas com o número de soquetes utilizado por um grupo principal. No entanto, se houver um número excessivamente grande de membros do grupo principal em execução em uma única máquina, talvez seja necessário ajustar os parâmetros do sistema operacional que estiverem relacionados com os intervalos de portas transitórias. A maioria dos sistemas operacionais possui comportamento padrão diferente para intervalos de portas transitórias.
