Este capítulo explica como configurar os parâmetros de balanceamento de carga e como configurar as funções do gerenciador, dos orientadores e do Metric Server do Balanceador de Carga.
Tarefa | Descrição | Informações relacionadas |
---|---|---|
Opcionalmente, altere as configurações de balanceamento de carga |
É possível alterar as seguintes configurações de balanceamento de carga:
|
Otimizando o Balanceamento de Carga Fornecido pelo Balanceador de Carga |
Usar scripts para gerar um alerta ou registrar a falha do servidor, quando o gerenciador marcar o(s) servidor(es) como inativo(s) ou ativo(s) | O Balanceador de Carga fornece saídas de usuário que acionam scripts que poderão ser customizados quando o gerenciador marcar o(s) servidor(es) como inativo(s) ou ativo(s) | Usando Scripts para Gerar um Alerta ou Registrar Falha do Servidor |
Usar orientadores | Descreve e lista os orientadores, que são relatados em status específicos dos servidores | Orientadores |
Usar a opção de pedido e resposta (URL) do orientador HTTP ou HTTPS | Definir uma cadeia de URL HTTP do cliente exclusivo, específica para um serviço que você deseja consultar na máquina | Configurando o Orientador HTTP ou HTTPS Usando a Opção de Pedido e Resposta (URL) |
Usar orientador próprio | Fornece status de carregamento do servidor backend em uma configuração WAN de duas camadas do Balanceador de Carga | Usando o Auto-Orientador em uma Configuração de WAN de Duas Camadas |
Criar orientadores customizados | Descreve como gravar seus próprios orientadores customizados | Criando Orientadores Customizados (Customizável) |
Usar o agente Metric Server | O Metric Server fornece informações de carregamento do sistema para o Balanceador de Carga | Metric Server |
Usar o orientador Workload Manager (WLM) | O orientador WLM fornece informações de carregamento do sistema para o Balanceador de Carga | Orientador Workload Manager |
A função do gerenciador do Balanceador de Carga executa o balanceamento de carga baseado nas seguintes configurações:
É possível alterar essas configurações para otimizar o balanceamento de carga de sua rede.
O gerenciador pode usar alguns ou todos os seguintes fatores externos em suas decisões para estipular peso:
Ou —
CPU: A porcentagem de CPU em uso em cada máquina servidor com carga balanceada (entrada do agente Metric Server). Apenas para Site Selector, essa proporção aparece no lugar da coluna de proporção de conexão ativa.
Ou —
Memória: A porcentagem de memória em uso (entrada do agente Metric Server) em cada servidor com carga balanceada. Apenas para Site Selector, essa proporção aparece no lugar da coluna de proporção de nova conexão.
Junto com o peso atual de cada servidor e de algumas outras informações necessárias para seus cálculos, o gerenciador obtém seus primeiros dois valores (conexões ativa e nova) a partir do executor. Esses valores baseiam-se em informações que são geradas e armazenadas internamente no executor.
É possível alterar a proporção de importância relativa dos quatro valores por cluster (ou nome de site). Pense nas proporções como porcentagens; a soma das proporções relativas deve ser igual a 100%. A proporção padrão é 50/50/0/0, que ignora as informações do orientador e do sistema. Em seu ambiente, é possível precisar tentar diferentes proporções para localizar a combinação que oferece o melhor desempenho.
Ao incluir o orientador WLM, se a proporção da métrica do sistema for zero, o gerenciador aumentará esse valor para 1. Como a soma das proporções relativas devem totalizar 100, o valor mais alto é diminuído por 1.
O número de conexões ativas depende do número de clientes e também do tempo necessário para usar os serviços que estão sendo fornecidos pelas máquinas servidores de carga balanceada. Se as conexões do cliente forem rápidas (como pequenas páginas da Web atendidas usando GET HTTP), então o número de conexões ativas será baixo. Se as conexões do cliente forem lentas (como uma consulta de banco de dados), então o número de conexões ativas será maior.
Você deve evitar de configurar as proporções de conexões ativa e nova para valores muito baixos. Você desativará o balanceamento de carga e a suavidade a menos que você possua os primeiros dois valores configurados para pelo menos 20 cada.
Para configurar a proporção de valores de importância, use o comando dscontrol cluster set cluster proportions. Consulte cluster udscontrol — configurar clusters para obter informações adicionais.
Os pesos são configurados pela função do gerenciador baseada em contadores internos no executor, feedback dos orientadores e feedback de um programa de monitoramento de sistema, como Metric Server. Se desejar configurar os pesos manualmente enquanto executa o gerenciador, especifique a opção fixedweight no comando dscontrol server. Para obter uma descrição da opção fixedweight, consulte Pesos Fixados pelo Gerenciador.
Os pesos são aplicados a todos os servidores em uma porta. Para qualquer porta particular, os pedidos são distribuídos entre os servidores com base nos pesos relativos entre si. Por exemplo, se um servidor for configurado para um peso 10 e outro servidor para o peso 5, o servidor configurado para 10 deverá ter o dobro de pedidos que o servidor configurado para 5.
Para especificar o limite máximo de peso que qualquer servidor pode ter, use o comando dscontrol port set port weightbound weight. Esse comando afeta na quantidade de diferenças que poderá haver entre o número de pedidos que cada servidor obterá. Se você configurar o limite de peso máximo como 1, todos os servidores poderão ter um peso de 1, 0 se em quiesce ou -1 se marcado como inativo. Conforme você aumenta esse número, a diferença no modo com que os servidores podem ser ponderados aumenta. Em um limite de peso máximo de 2, um servidor pode obter duas vezes a quantidade de pedidos de outro. Em um limite de peso máximo de 10, um servidor pode obter 10 vezes a quantidade de pedidos do outro. O limite de peso máximo padrão é 20.
Se um orientador achar que um servidor ficou inativo, ele informará o gerenciador, que configurará o peso do servidor como zero. Como resultado, o executor não enviará nenhuma conexão adicional para esse servidor enquanto esse peso permanecer zero. Se houve quaisquer conexões ativas com esse servidor antes que o peso fosse alterado, elas serão deixadas para serem concluídas normalmente.
Se todos os servidores estiverem inativos, o gerenciador configurará os pesos pela metade do limite de peso.
Sem o gerenciador, os orientadores não podem ser executados e não podem detectar se um servidor está inativo. Se você escolher executar os orientadores, mas não desejar que o gerenciador atualize o peso configurado para um servidor específico, use a opção peso fixo no comando dscontrol server. Por exemplo:
dscontrol server set cluster:port:server fixedweight yes
Depois que o peso fixado for configurado como yes, use o comando dscontrol server set weight para configurar o peso como o valor desejado. O valor do peso do servidor permanece fixado enquanto o gerenciador estiver em execução, até que você emita outro comando dscontrol server com o peso fixado configurado como no. Para obter informações adicionais, consulte dscontrol server — configurar servidores.
Se a reconfiguração TCP estiver ativada, o Dispatcher enviará uma reconfiguração TCP para um cliente quando o cliente tiver uma conexão com um servidor, cujo peso seja 0. O peso de um servidor poderá ser 0, se ele estiver configurado como 0 ou se um orientador marcá-lo como inativo. Uma reconfiguração TCP fará com que a conexão seja encerrada imediatamente. Esse recurso é útil para conexões de longa duração em que a habilidade do cliente é apressada para renegociar uma conexão com falha. Para ativar a reconfiguração TCP, use o comando dscontrol port add|set port reset yes. O valor-padrão para a reconfiguração é no.
Um recurso útil a ser configurado, em conjunto com a reconfiguração TCP, é nova tentativa do orientador. Com esse recurso, um orientador tem a habilidade de tentar novamente uma conexão antes de marcar um servidor inativo. Isso ajudará a impedir que o orientador marque o servidor inativo prematuramente, o que pode resultar em problemas de reconfiguração de conexão. Isto é, apenas porque o orientador falhou na primeira tentativa, não significa necessariamente que as conexões existentes também estejam falhando. Consulte Nova Tentativa do Orientador para obter informações adicionais.
Para otimizar o desempenho geral, o gerenciador é restrito em relação à frequência com ele pode interagir com o executor. É possível fazer mudanças nesse intervalo inserindo os comandos dscontrol manager interval e dscontrol manager refresh.
O intervalo do gerenciador especifica com que frequência o gerenciador atualizará os pesos do servidor que o executor usa nas conexões de roteamento. Se o intervalo do gerenciador for muito baixo, isso poderá significar baixo desempenho como resultado de o gerenciador interromper constantemente o executor. Se o intervalo do gerenciador for muito alto, poderá significar que o roteamento de pedido do executor não será baseado em informações exatas e atualizadas.
Por exemplo, para configurar o intervalo do gerenciador como 1 segundo, insira o seguinte comando:
dscontrol manager interval 1
O ciclo de atualização do gerenciador especifica com que frequência o gerenciador solicitará ao executor as informações de status. O ciclo de atualização baseia-se no intervalo de tempo.
Por exemplo, para configurar o ciclo de atualização do gerenciador como 3, insira o seguinte comando:
dscontrol manager refresh 3
Isso fará com que o gerenciador aguarde 3 intervalos antes de solicitar um status ao executor.
Outros métodos estão disponíveis para que você otimize o balanceamento de carga para seus servidores. Para trabalhar com alta velocidade, as atualizações dos pesos para os servidores são feitas apenas se os pesos forem alterados significativamente. Atualizando os pesos constantemente quando houver pequena ou nenhuma mudança no status do servidor, será criada uma sobrecarga desnecessária. Quando a mudança de peso da porcentagem para o peso total de todos os servidores em uma porta for maior do que o limite de sensibilidade, o gerenciador atualizará os pesos usados pelo executor para distribuir as conexões. Considere, por exemplo, que o peso total das alterações é alterado de 100 para 105. A mudança é 5%. Com o limite de sensibilidade padrão de 5, o gerenciador não atualizará os pesos usados pelo executor, porque a mudança de porcentagem não está acima do limite. No entanto, se o peso total for alterado de 100 para 106, o gerenciador atualizará os pesos. Para configurar o limite de sensibilidade do gerenciador como um valor diferente do padrão (por exemplo, 6), insira o seguinte comando:
dscontrol manager sensitivity 6
Na maioria dos casos, você não precisará alterar esse valor.
O gerenciador calcula os pesos de servidor dinamicamente. Como resultado, um peso atualizado pode ser muito diferente do peso anterior. Na maioria das circunstâncias, isso não será um problema. Ocasionalmente, isso pode causar um efeito de oscilação na maneira com que a carga dos pedidos forem balanceadas. Por exemplo, um servidor pode acabar recebendo a maioria dos pedidos devido a um alto peso. O gerenciador verá que o servidor possui um número grande de conexões ativas e que o servidor está respondendo fortemente. Em seguida, ele deslocará o peso sobre os servidores livres e o mesmo efeito ocorrerá lá também, criando um uso ineficiente de recursos.
Para atenuar esse problema, o gerenciador usa um índice de suavização. O índice de suavização limita a quantidade que um peso do servidor pode alterar, suavizando efetivamente a mudança na distribuição de pedidos. Um índice de suavização alto faz com que os pesos do servidor sejam alterados menos drasticamente. Um índice de suavização baixo faz com que os pesos do servidor sejam alterados mais drasticamente. O valor padrão para o índice de suavização é 1.5. Em 1,5 os pesos do servidor podem ser muito dinâmicos. Um índice de 4 ou 5 fará com que os pesos sejam mais estáveis. Por exemplo, para configurar o índice de suavização como 4, insira o seguinte comando:
dscontrol manager smoothing 4
Na maioria dos casos, você não precisará alterar esse valor.
O Balanceador de Carga fornece saídas de usuários que acionam scripts que podem ser customizados. É possível criar os scripts para executar ações automatizadas, como alertar um Administrador quando servidores forem marcados como inativos pelo gerenciador ou apenas registrar o evento da falha. Scripts de amostra, que você pode customizar, estão no seguinte diretório:
Para executar os arquivos, você deve movê-los para o seguinte diretório e remover a extensão de arquivo "sample":
Os seguintes scripts de amostra são fornecidos:
Se todos os servidores em um cluster forem marcados como inativos (seja pelo usuário ou pelos orientadores), o managerAlert (se configurado) é iniciado e o Load Balancer tentará rotear o tráfego para os servidores usando uma técnica round-robin. O script serverDown não é iniciado quando o último servidor no cluster é detectado como off-line.
Por padrão, o Load Balancer tenta continuar roteando o tráfego no caso de um servidor entrar on-line novamente e responder ao pedido. Se o Load Balancer em vez de eliminar todo o tráfego, o cliente não receberia nenhuma resposta.
Quando o Balanceador de Carga detectar que o primeiro servidor de um cluster está on-line novamente, o script managerClear (se configurado) será iniciado, mas o script serverUp (se configurado) não será executado até que um servidor adicional fique on-line novamente.
Considerações ao usar os scripts serverUp e serverDown:
Orientadores são agentes dentro do Balanceador de Carga. Seu objetivo é avaliar o funcionamento e o carregamento das máquinas servidores. Eles fazem isso por meio de uma troca do tipo cliente proativa com os servidores. Os orientadores podem ser considerados como clientes leves dos servidores de aplicativos.
O produto fornece vários orientadores específicos do protocolo para os protocolos mais populares. No entanto, não faz sentido usar todos os orientadores fornecidos com cada componente do Balanceador de Carga. (Por exemplo, você não usa o orientador Telnet com o componente CBR.) O Balanceador de Carga também suporta o conceito de um "orientador customizado" que permite que usuários gravem seus próprios orientadores.
Aplicativos do servidor específicos à Limitação no uso de ligação: Para usar orientadores em servidores específicos de ligação, inicie duas instâncias do servidor: Uma instância para ligação em cluster:port e outra instância para ligação em server:port. Para determinar se o servidor é específico de ligação, emita o comando netstat -an e procure server:port. Se o servidor não for específico à ligação, o resultado desse comendo será 0.0.0.0:80. Se o servidor for específico à ligação, você verá um endereço, como 192.168.15.103:80.
Para sistemas HP-UX e Solaris, a limitação sobre o uso de aplicativos do servidor específico à ligação: Se você estiver usando publicação arp no lugar do comando ifconfig alias, o Balanceador de Carga suportará o uso de orientadores enquanto fizer o balanceamento de carga de servidores com os aplicativos de servidor específicos de ligação (incluindo outros componentes do Balanceador de Carga, como CBR ou Site Selector) quando estiverem fazendo ligação com o endereço IP do cluster. No entanto, ao usar orientadores com relação ao aplicativo do servidor específico à ligação, não coloque o Balanceador de Carga na mesma máquina com o aplicativo do servidor.
-DLB_ADV_SRC_ADDR=IP_address
Os orientadores abrem periodicamente uma conexão TCP com cada servidor e enviam uma mensagem de pedido para o servidor. O conteúdo da mensagem é específico para o protocolo que é executado no servidor. Por exemplo, o orientador HTTP envia um pedido de HTTP "HEAD" ao servidor.
Os orientadores então atendem a uma resposta a partir do servidor. Depois de obter a resposta, o orientador faz uma avaliação do servidor. Para calcular esse valor de "carregamento", a maioria dos orientadores medem o tempo para o servidor responder e, em seguida, usam esse valor (em milissegundos) como o carregamento.
Em seguida, os orientadores relatam o valor do carregamento para a função do gerenciador, onde ele é exibido no relatório do gerenciador na coluna "Porta". Em seguida, o orientador calcula os valores de peso agregados a partir de todas as suas origens, pelas suas proporções, e configura esses valores de peso na função do executor. O Executor então usará esses pesos para balancear a carga de novas conexões de entrada do cliente.
Se o orientador determinar que um servidor está ativo e bem, ele relatará um número de carregamento positivo, que não é zero ao Gerenciador. Se o orientador determinar que um servidor não está ativo, ele relatará um valor de carregamento especial negativo (-1). O Gerenciador e o Executor não encaminharão nenhuma conexão adicional para esse servidor até que esse servidor fique ativo novamente.
É possível iniciar um orientador para uma determinada porta por meio de todos os clusters (orientador de grupo). Ou, é possível escolher executar orientadores diferentes na mesma porta, mas em clusters diferentes (orientador específico ao cluster/site). Por exemplo, se você tiver o Balanceador de Carga definido com três clusters (clusterA, clusterB, clusterC), cada um tendo a porta 80, poderá fazer o seguinte:
dscontrol advisor start http clusterA:80Esse comando iniciará o orientador HTTP na porta 80 para o clusterA. O orientador HTTP será avisado em todos os servidores anexados à porta 80 para o clusterA.
dscontrol advisor start ADV_custom 80Esse comando iniciará o orientador ADV_custom na porta 80 para o clusterB e o clusterC. O orientador customizado será avisado em todos os servidores anexados à porta 80 para o clusterB e o clusterC. (Para obter informações adicionais sobre orientadores customizados, consulte Criando Orientadores Customizados (Customizável)).
Usando o exemplo de configuração anterior para o orientador do grupo, é possível escolher parar o orientador customizado ADV_custom para a porta 80 em apenas um dos clusters ou para ambos os clusters (clusterB e clusterC).
dscontrol advisor stop ADV_custom clusterB:80
dscontrol advisor stop ADV_custom 80
O intervalo do orientador configura a frequência com que o orientador solicita o status a partir dos servidores na porta em que está monitorando e então relata os resultados para o gerenciador. Se o intervalo do orientador for muito baixo, isso poderá significar baixo desempenho como resultado de o orientador interromper constantemente os servidores. Se o intervalo do orientador for muito alto, poderá significar que as decisões do gerenciador sobre peso não sejam baseadas em informações exatas e atualizadas.
Por exemplo, para configurar o intervalo como 3 segundos para o orientador HTTP para a porta 80, insira o seguinte comando:
dscontrol advisor interval http 80 3
Não é necessário especificar um intervalo do orientador menor que o intervalo do gerenciador. O intervalo do orientador padrão é sete segundos.
Para certificar-se de que informações desatualizadas não sejam usadas pelo gerenciador nas decisões de balanceamento de carga, o gerenciador não usará as informações a partir do orientador cujo registro de data e hora seja mais antigo que a hora configurada no tempo limite de relatório do orientador. O tempo limite de relatório do orientador deve ser maior que o intervalo de sondagem do orientador. Se o tempo limite for menor, o gerenciador ignorará os relatórios que devem ser usados logicamente. Por padrão, os relatórios do orientador não definem o tempo limite — o valor padrão é ilimitado.
Por exemplo, para configurar o tempo limite de relatório do orientador para 30 segundos para o orientador HTTP para a porta 80, insira o seguinte comando:
dscontrol advisor timeout http 80 30
Para obter informações adicionais sobre como configurar o tempo limite do relatório do orientador, consulte dscontrol advisor — controle do orientador.
Para o Balanceador de Carga, é possível configurar os valores de tempo limite do orientador no qual ele detecta que uma porta específica no servidor (um serviço) falhou. Os valores de tempo limite de servidor com falha (connecttimeout e receivetimeout) determinam quanto tempo um orientador aguarda antes de relatar que uma conexão ou um recebimento falhou.
Para obter o servidor com falha mais rápido detecção, configure os tempos limites de conexão e recebimento do orientador como o menor valor (um segundo) e configure o tempo de intervalo do orientador e do gerenciador como o menor valor (um segundo).
Por exemplo, para configurar o connecttimeout e o receivetimeout para 9 segundos para o orientador HTTP na porta 80, digite o seguinte comando:
dscontrol advisor connecttimeout http 80 9 dscontrol advisor receivetimeout http 80 9
O padrão para o tempo limite de conexão e de recebimento é 3 vezes o valor especificado para o tempo de intervalo do orientador.
Os orientadores têm a habilidade de tentar novamente uma conexão antes de marcar um servidor como inativo. O orientador não marcará um servidor como inativo até que a consulta do servidor tenha falhado no número de novas tentativas mais 1. O valor tentar novamente não deverá ser maior do que 3. O seguinte comando configura um valor da nova tentativa como 2 para o orientador LDAP na porta 389:
dscontrol advisor retry ldap 389 2
Use o orientador TLS se achar que o orientador SSL está marcando os servidores como inativos sabendo que eles ainda estão ativos e se vir uma mensagem dizendo "Nenhum código localizado".
A opção URL para o orientador HTTP ou HTTPS está disponível para os componentes Dispatcher e CBR.
Após ter iniciado um orientador HTTP ou HTTPS, é possível definir uma cadeia URL de HTTP de cliente exclusivo, específica para o serviço que você deseja consultar no servidor. Isto permite que o orientador avalie o funcionamento dos serviços individuais dentro de um servidor. Você pode fazer isso definindo servidores lógicos com nomes do servidores exclusivos que tenham o mesmo endereço IP físico. Consulte Particionamento do Servidor: Servidores Lógicos Configurados como um Servidor Físico (endereço IP) para obter informações adicionais.
Para cada servidor lógico definido na porta HTTP, é possível especificar uma cadeia de URL HTTP cliente exclusiva, específica para o serviço que deseja consultar no servidor. O orientador HTTP ou HTTPS usa a cadeia advisorrequest para consultar o funcionamento dos servidores. O valor-padrão é HEAD / HTTP/1.0. A cadeia advisorresponse é a resposta que o orientador varre na resposta HTTP. O orientador usa a cadeia advisorresponse a ser comparada com a resposta real recebida do servidor. O valor padrão é nulo.
Importante: Se um branco estiver contido dentro da cadeia URL de HTTP:
server set cluster:port:server advisorrequest "head / http/1.0" server set cluster:port:server advisorresponse "HTTP 200 OK"
dscontrol server set cluster:port:server advisorrequest "\"head / http/1.0\"" dscontrol server set cluster:port:server advisorresponse "\"HTTP 200 OK\""
Ao criar a solicitação que o orientador HTTP ou HTTPS envia para servidores de back-end para ver se eles estão funcionando, você digita o início da solicitação HTTP e o Balanceador de Carga conclui o final da solicitação com o seguinte:
\r\nAccept: */*\r\nUser-Agent:IBM_Load_Balanacer_HTTP_Advisor\r\n\r\n
Se você desejar incluir outros campos de cabeçalho de HTTP antes do Balanceador de Carga anexar essa cadeia no término do pedido, poderá fazer isso incluindo sua própria \r\n cadeia no pedido. A seguir há um exemplo do que é possível digitar para incluir o campo de cabeçalho do host HTTP ao seu pedido:
GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHost: www.w3.org
Consulte dscontrol server — configurar servidores para obter informações adicionais.
O auto-orientador está disponível no componente Dispatcher.
Para Balanceador de Carga em uma configuração WAN (rede de longa distância) de duas camadas, o Dispatcher fornece um auto-orientador que coleta informações de status de carregamento em servidores backend.
Neste exemplo o auto-orientador, juntamente com o Metric Server residem nas duas máquinas do Dispatcher que está tendo a carga balanceada pelo Balanceador de Carga de camada superior. O auto-orientador mede especificamente a taxa de conexões por segundo em servidores backend do Dispatcher no nível do executor.
O auto-orientador grava os resultados no arquivo dsloadstat. O Balanceador de Carga também fornece uma métrica externa denominada dsload. O agente Metric Server em cada máquina do Dispatcher executa sua configuração que chama a métrica externa dsload. O script dsload extrai uma cadeia do arquivo dsloadstat e retorna-o ao agente Metric Server. Subsequentemente, cada um dos agentes Metric Server (de cada um dos Dispatchers) retorna o valor do status de carregamento para o Balanceador de Carga de camada superior para uso na determinação de qual Dispatcher encaminhar pedidos do cliente.
O executável dsload reside no seguinte diretório:
Consulte Configurando Suporte ao Dispatcher de Longa Distância para obter mais informações sobre o uso do Dispatcher em configurações WAN. Consulte Metric Server para obter informações adicionais sobre o Metric Server.
O orientador customizado (customizável) é uma pequena parte de código Java fornecida como um arquivo de classe chamada pelo código base. O código base fornece todos os serviços administrativos, como iniciar e parar uma instância do orientador customizado, fornecer status e relatórios e gravar informações de histórico em um arquivo de log. Ele também relata resultados para o componente de gerenciador. Periodicamente, o código base executa um loop do orientador, no qual ele avalia individualmente todos os servidores em sua configuração. Ele começa abrindo uma conexão com uma máquina servidor. Se o soquete abrir, o código base chamará o método (função) "getLoad" no orientador customizado. O orientador customizado executará quaisquer etapas necessárias para avaliar o funcionamento do servidor. Normalmente ele envia uma mensagem definida pelo usuário para o servidor e espera uma resposta. (O acesso ao soquete aberto é fornecido ao orientador customizado.) O código base então fecha o soquete com o servidor e relata as informações de carregamento ao Gerenciador.
O código base e o orientador customizado podem operar no modo normal ou de substituição. A escolha do modo de operação é especificada no arquivo do orientador customizado como um parâmetro no método do construtor.
No modo normal, o orientador customizado troca dados com o servidor e o código do orientador base determina o tempo da troca e calcula o valor de carregamento. O código base então relata esse valor de carregamento para o gerenciador. O orientador customizado só precisa retornar um zero (êxito) ou um 1 negativo (erro). Para especificar o modo normal, o sinalizador de substituição no construtor é configurado como false.
No modo de substituição, o código base não executa nenhuma medida de tempo. O código do orientador customizado executa quaisquer operações desejadas para seus requisitos exclusivos e retorna um número de carregamento real. O código base aceitará o número e o relatará ao gerenciador. Para obter os melhores resultados, normalize seu número de carregamentos entre 10 e 1000, sendo que 10 representa um servidor rápido e 1000 representa um servidor lento. Para especificar o modo de substituição, o sinalizador de substituição no construtor é configurado como true.
Com esse recurso, é possível gravar seus próprios orientadores que fornecerão informações precisas sobre os servidores necessários. Um orientador customizado de amostra, ADV_sample.java, é fornecido com o produto Balanceador de Carga.
Após instalar o Balanceador de Carga, você pode localizar o código de amostra em:
Se o orientador customizado fizer referência a classes Java adicionais, o caminho de classe no arquivo de script inicial do Load Balancer (dsserver, cbrserver, ssserver) deverá ser atualizado para incluir o local.
Os arquivos do orientador customizado de amostra, especificamente para o orientador WebSphere Application Server (WAS) são fornecidos no diretório de instalação do Balanceador de Carga.
Os arquivos de amostra do orientador WebSphere Application Server residem no mesmo diretório de amostras como arquivo ADV_sample.java.
O nome do arquivo do orientador customizado deve estar no formato "ADV_myadvisor.java." Ele deve começar com o prefixo " ADV_" em maiúscula. Todos os caracteres subsequentes devem estar em letras minúsculas.
Assim como por convenções Java, o nome da classe definida no arquivo deve corresponder ao nome do arquivo. Se você copiar o código de amostra, certifique-se de alterar todas as instâncias de "ADV_sample" no arquivo para seu novo nome de classe.
Orientadores customizados são gravados em linguagem Java. Use o compilador Java instalado com o Balanceador de Carga. Esses arquivos são usados como referência durante a compilação:
Seu caminho de classe deve apontar para o arquivo do orientador customizado e arquivo de classe base durante a compilação.
Para sistemas Windows, um comando de compilação de amostra é:
install_dir/java/bin/javac -classpath install_dir\lb\servers\lib\ibmlb.jar ADV_fred.java
onde:
A saída para a compilação é um arquivo de classe, por exemplo
ADV_fred.class
Antes de iniciar o orientador, copie o arquivo de classe para o seguinte diretório:
Para sistemas AIX, HP-UX, Linux e Solaris, a sintaxe é semelhante.
Para executar o orientador customizado, primeiro você deve copiar o arquivo de classe no diretório de instalação adequado:
Configure o componente, inicie sua função de gerenciador e emita o comando para iniciar seu orientador customizado:
dscontrol advisor start fred 123
onde:
Se o orientador customizado fizer referência a classes Java adicionais, o caminho de classe no arquivo de script inicial do Load Balancer (dsserver, cbrserver, ssserver) deverá ser atualizado para incluir o local.
Como todos os orientadores, um orientador customizado estende a função da base do orientador, chamada ADV_Base. É a base do orientador que executa de fato a maioria das funções do orientador, como relatar carregamentos de volta para o gerenciador para ele usar em seu algoritmo de peso. O orientador base também executa operações de conexão e de fechamento de soquete e fornece métodos de envio e de recebimento para uso pelo orientador. O orientador em si é usado apenas para enviar e receber dados para e da porta no servidor sendo avisado. Os métodos TCP na base do orientador são sincronizados para calcular o carregamento. Um sinalizador no construtor em ADV_base sobrescreve o carregamento existente com um novo carregamento retornado do orientador, se desejado.
Estes são os métodos de classe base:
Balanceador de Carga examina primeiro a lista de orientadores nativos fornecida. Se ele não localizar um determinado orientador, o Balanceador de Carga então examina a lista do cliente de orientadores customizados.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
<install_root>ibm\edge\lb\servers\lib\CustomAdvisors
A listagem de programas para um orientador de amostra está incluída em Orientador de Amostra. Após a instalação, esse orientador de amostra pode ser localizado no seguinte diretório:
Este recurso está disponível para todos os componentes do Balanceador de Carga.
O Metric Server fornece informações de carregamento do servidor para o Balanceador de Carga no formulário de métricas específicas ao sistema, relatando no funcionamento dos servidores. O gerenciador do Balanceador de Carga consulta o agente Metric Server que reside em cada um dos servidores, designando pesos para o processo de balanceamento de carga usando as métricas reunidas dos agentes. Os resultados também são colocados no relatório do gerenciador.
Para obter informações sobre como operar o Metric Server (iniciar e parar) e o uso de logs do Metric Server, consulte Usando o Componente Metric Server.
Para obter um exemplo de configuração, consulte Figura 5.
Como o orientador WLM, o Metric Server é relatado nos sistemas do servidor como um todo, em vez de nos daemons do servidor, específicos ao protocolo individual. O WLM e o Metric Server colocam seus resultados na coluna do sistema do relatório do gerenciador. Como consequência, a execução do orientador WLM e do Metric Server ao mesmo tempo não é suportada.
O agente Metric Server deve ser instalado e em execução em todos os servidores que estão tendo a carga balanceada.
A seguir estão as etapas para configurar o Metric Server para Dispatcher. Etapas semelhantes podem ser usadas para configurar o Metric Server para os outros componentes do Balanceador de Carga.
port é a porta RMI escolhida para todos os agentes do Metric Server no qual executar. A porta RMI padrão que é configurada no arquivo metricserver.cmd é 10004.
systemMetric é o nome do script (residindo no servidor backend) que deve ser executado em cada um dos servidores na configuração sob o cluster especificado (ou nome do site). Dois scripts são fornecidos para o cliente - cpuload e memload. Ou, é possível criar scripts de métrica do sistema customizado. O script contém um comando que deve retornar um valor numérico no intervalo de 0 a 100 ou um valor de -1, se o servidor estiver inativo. Esse valor numérico deve representar uma medida de carregamento, não um valor de disponibilidade.
Limitação: Para a plataforma Windows, se o nome do script System Metric tiver uma extensão diferente de ".exe", é necessário especificar o nome completo do arquivo (por exemplo, "mysystemscript.bat"). Isto é devido a uma limitação Java.
Opcionalmente, os clientes podem gravar seus próprios arquivos de script de métrica customizada, que definem o comando que o Metric Server emitirá nas máquinas do servidor. Certifique-se de que qualquer script customizado seja executável e esteja localizado no seguinte diretório:
Os scripts customizados devem retornar um valor de carregamento numérico no intervalo de 0 a 100.
Para que o Metric Server seja executado em um endereço diferente do host local, é necessário editar o arquivo metricserver na máquina servidor com a carga balanceada. Após a ocorrência de "java" no arquivo metricserver, insira o seguinte:
-Djava.rmi.server.hostname=OTHER_ADDRESS
Além disso, antes das instruções "if" no arquivo metricserver, inclua a seguinte linha: hostname OTHER_ADDRESS.
Para a plataforma Windows: você também precisará criar o alias do OTHER_ADDRESS na pilha do Microsoft da máquina do Metric Server. Por exemplo:
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
Ao reunir métricas em diferentes domínios, você deve configurar explicitamente java.rmi.server.hostname no script de servidor (dsserver, cbrserver, etc) para o nome completo do domínio (FQDN) da máquina que está solicitando as métricas. Isso é necessário porque, dependendo da configuração e do sistema operacional, InetAddress.getLocalHost.getHostName() pode não retornar o FQDN.
WLM é o código executado nos mainframes MVS. Ele pode ser consultado para perguntar sobre o carregamento na máquina MVS.
Quando o MVS Workload Management tiver sido configurado no sistema OS/390, o Dispatcher poderá aceitar as informações de capacidade do WLM e usá-las no processo de balanceamento de carga. Usando o orientador WLM, o Dispatcher abrirá periodicamente conexões por meio da porta do WLM em cada servidor na tabela de host do Dispatcher e aceitará os números inteiros de capacidade retornados. Como esses números inteiros representam a quantia de capacidade que ainda está disponível e o Dispatcher espera valores que representam os carregamentos em cada máquina, os números inteiros da capacidade são invertidos pelo orientador e normalizados em valores de carregamento (ou seja, um número inteiro de capacidade maior mas com um valor de carregamento pequeno, ambos representando um servidor mais funcional). Os carregamentos resultantes são colocados na coluna do Sistema do relatório do gerenciador.
Há várias diferenças importantes entre o orientador WLM e outros orientadores do Dispatcher:
Como o agente Metric Server, o agente WLM é relatado nos sistemas do servidor como um todo, em vez de nos daemons do servidor, específicos ao protocolo individual. O Metric Server e o WLM colocam seus resultados na coluna do sistema do relatório do gerenciador. Como consequência, a execução do orientador WLM e do Metric Server ao mesmo tempo não é suportada.