Operando e Gerenciando o Balanceador de Carga

Nota:
Durante a leitura deste capítulo, nas seções gerais que não são específicas para um componente, se você não estiver usando o componente Dispatcher, substitua "dscontrol" e "dsserver" pelo seguinte:

Este capítulo explica como operar e gerenciar o Balanceador de Carga e inclui as seguintes seções:

Administração Remota de Balanceador de Carga

O Balanceador de Carga fornece duas maneiras diferentes de executar seus programas de configuração em uma máquina separada daquela onde ele reside. A comunicação entre os programas de configuração (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) e o servidor (dsserver, cbrserver, entre outros) pode ser feita com o uso de um dos seguintes métodos:

A vantagem da administração remota usando RMI é que o desempenho fica mais rápido do que o da administração baseada na Web.

As vantagens de usar administração baseada na Web é que ela fornece administração remota autenticada segura e pode se comunicar com a máquina do Balanceador de Carga mesmo quando um firewall está presente. Além disso, esse método de administração não requer instalação e uso de chaves de autenticação (lbkeys) no computador cliente remoto que está se comunicando com a máquina do Balanceador de Carga.

Remote Method Invocation (RMI)

Para RMI, o comando para se conectar a uma máquina do Balanceador de Carga para administração remota é dscontrol host:remote_host.

Se a chamada RMI vier de uma máquina que não seja a máquina local, uma chave pública/chave privada a sequência de autenticação deve ocorrer antes da aceitação do comando de configuração.

A comunicação entre os programas de controle em execução na mesma máquina dos servidores do componente não é autenticada.

Use o seguinte comando para gerar chaves públicas e privadas para serem usadas para autenticação remota:

lbkeys [create|delete]

Esse comando só é executado na mesma máquina que o Balanceador de Carga.

Usar a opção create cria uma chave privada no diretório de chave dos servidores:

O script também cria chaves públicas no diretório das chaves de administração para cada um dos componentes do Balanceador de Carga:

O nome do arquivo para a chave pública é: component-ServerAddress-RMIport. Essas chaves públicas devem então ser transportadas para os clientes remotos e colocadas no diretório de chaves de administração.

Para uma máquina do Balanceador de Carga com endereços de nome do host 10.0.0.25 usando a porta RMI padrão para cada componente, o comando lbkeys create gera os seguintes arquivos:

O conjunto de arquivos de administração foi instalado em outra máquina. Os arquivos de chave pública devem ser colocados no seguinte diretório no computador cliente remoto:

O cliente remoto agora está autorizado a configurar o Balanceador de Carga em 10.0.0.25.

Essas mesmas chaves devem ser usadas em todos os clientes remotos que você quer autorizar para configurar o Balanceador de Carga em 10.0.0.25.

Se você fosse executar o comando lbkeys create novamente, um novo conjunto de chaves públicas/privadas seria gerado. Isso significaria que nenhum dos clientes remotos que tentou se conectar usando as chaves anteriores seria autorizado. A nova chave teria que ser colocada no diretório correto naqueles clientes que você quer autorizar novamente.

O comando lbkeys delete exclui as chaves públicas e privadas na máquina servidor. Se essas chaves forem excluídas, nenhum cliente remoto será autorizado a se conectar aos servidores.

Para lbkeys create e lbkeys delete, há uma opção forçar. A opção forçar suprime os prompts de comandos que perguntam se você quer sobrescrever ou excluir chaves existentes.

Após você estabelecer a conexão de RMI, é possível a comunicação entre os programas de configuração usando os comandos dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol, dswizard, cbrwizard e sswizard de um prompt de comandos. Também é possível configurar o Load Balancer usando a GUI digitando lbadmin a partir de um prompt de comandos.

Nota:
Devido a mudanças nos pacotes de segurança na versão Java, as chaves do Load Balancer geradas para releases anteriores à v5.1.1 podem não ser compatíveis com as chaves para o release atual, portanto, você deve gerar novamente suas chaves ao instalar o novo release.

Administração Baseada na Web

Requisitos

Para usar administração baseada na Web, os itens a seguir são obrigatórios no computador cliente que executa administração remota:

Os itens a seguir são obrigatórios na máquina host que você está acessando para executar administração baseada na Web:

Configurando o Caching Proxy

Executando e Acessando Administração Baseada na Web

Para executar administração baseada na Web, ela deve ser iniciada na máquina host do Load Balancer: Emita lbwebaccess a partir do prompt de comandos da máquina host.

O ID do usuário e a senha para a máquina host que você está acessando remotamente também são obrigatórios. O ID do usuário e a senha são os mesmos que o ID do usuário e a senha de administração do Caching Proxy.

Para acessar a administração baseada na Web do Load Balancer, acesse a seguinte URL no navegador da Web a partir do local remoto:

http://host_name/lb-admin/lbadmin.html

Em que host_name é o nome da máquina que você está acessando para se comunicar com o Load Balancer.

Quando a página da Web for carregada, a GUI do Load Balancer aparecerá na janela do navegador para você executar a administração remota baseada na Web.

A partir da GUI do Load Balancer, também é possível emitir comandos de controle da configuração. Para emitir um comando a partir da GUI:

  1. destaque o nó Host a partir da árvore da GUI
  2. selecione Enviar comando... no menu pop-up Host
  3. no campo de entrada de comando, digite o comando que deseja executar. Por exemplo: executor report. Os resultados e o histórico dos comandos executados na sessão atual são exibidos na janela fornecida.

Atualizando a configuração remotamente

Com a administração remota baseada na Web, se houver diversos administradores atualizando a configuração do Load Balancer a partir de outros locais, você vai precisar atualizar a configuração para visualizar (por exemplo) o cluster, porta ou servidor que foi incluído (ou excluído) por outro administrador. A GUI da administração remota baseada na Web fornece uma função Atualizar Configuração e Atualizar todas as Configurações.

Na GUI baseada na Web, para atualizar a configuração

Usando Logs do Balanceador de Carga

Para Dispatcher, CBR e Site Selector

O Balanceador de Carga posta entradas para um log do servidor, um log do gerenciador, um log do monitor de métrica (comunicações de criação de log com agentes do Metric Server) e um log para cada orientador usado.

Nota:
Além disso, apenas para o componente Dispatcher, entradas podem ser feitas em um log do subagente (SNMP).
Nota:
O componente Content Based Routing (CBR) não está disponível em plataformas que executam um JVM de 64 bits, exceto para HP-UX ia64. No HP-UX ia64, o componente CBR executa como um aplicativo de 32 bits. É possível usar o método de encaminhamento CBR do componente Dispatcher do Balanceador de Carga para fornecer roteamento baseado em conteúdo sem o uso do Caching Proxy. Consulte roteamento baseado em conteúdo do Dispatcher (Método de Encaminhamento CBR) para obter informações adicionais.

É possível configurar o nível de criação de log para definir a expansividade das mensagens gravadas no log. No nível 0, os erros são registrados e o Balanceador de Carga também registra cabeçalhos e registros de eventos que ocorrem apenas uma vez (por exemplo, uma mensagem sobre um orientador, que começa a ser gravada no log do gerenciador). O nível 1 inclui informações em andamento e assim por diante, com o nível 5 incluindo cada mensagem produzida para auxiliar na depuração de um problema, se necessário. O padrão para os logs do gerenciador, orientador, servidor ou subagente é 1.

É possível configurar também o tamanho máximo de um log. Ao configurar um tamanho máximo do arquivo de log, o arquivo será quebrado. Quando o arquivo atingir o tamanho especificado, as entradas subsequentes serão gravadas na parte superior do arquivo, sobrescrevendo as entradas de log anteriores. Não é possível configurar o tamanho do log como um valor que seja menor do que o atual. As entradas de log são registradas pela data e hora, portanto, é possível informar a ordem na qual elas foram gravadas.

Quanto mais alto você configurar o nível de log, mais cuidadosamente deverá escolher o tamanho do log. No nível 0, provavelmente seja seguro deixar o tamanho do log como o padrão de 1 MB. No entanto, ao criar log no nível 3 e superior, você deverá limitar o tamanho sem torná-lo muito pequeno para que seja útil.

Alterando os Caminhos do Arquivo de Log

Por padrão, os logs gerados pelo Balanceador de Carga são armazenados no diretório de logs da instalação do Balanceador de Carga. Para alterar esse caminho, configure a variável lb_logdir no script dsserver.

Sistemas AIX, HP-UX, Linux e Solaris: O script dsserver está localizado no diretório /usr/bin. Nesse script, a variável lb_logdir é configurada como o diretório padrão. É possível modificar essa variável para especificar o diretório de log. Por exemplo:

LB_LOGDIR=/path/to/my/logs/

Sistemas operacionais Windows: O arquivo dsserver está localizado no diretório bin <install_root>ibm\edge\lb\. No arquivo dsserver, a variável lb_logdir é configurada como o diretório padrão. É possível modificar essa variável para especificar o diretório de log. Por exemplo:

set LB_LOGDIR=c:\path\to\my\logs\

Para todos os sistemas operacionais, certifique-se de que não haja nenhum espaço em um dos lados do sinal de igual e de que o caminho termine em uma barra ("/" ou "\" conforme apropriado).

Criação de log binário

Nota:
A criação de log binário não se aplica ao componente Site Selector.

O recurso de criação de log binário do Balanceador de Carga usa o mesmo diretório de log que o dos outros arquivos de log. Consulte Usando Criação de Log Binário para Analisar Estatísticas do Servidor.

Para Controlador Cisco CSS e Controlador Nortel Alteon

É possível configurar o nível de criação de log para definir a expansividade das mensagens gravadas no log. No nível 0, os erros são registrados e o Balanceador de Carga também registra cabeçalhos e registros de eventos que acontecem apenas uma vez (por exemplo, uma mensagem sobre um orientador que começa a ser gravada no log do consultor). O nível 1 inclui informações em andamento e assim por diante, com o nível 5 incluindo cada mensagem produzida para auxiliar na depuração de um problema, se necessário. O padrão para os logs é 1.

É possível configurar também o tamanho máximo de um log. Quando você configurar um tamanho máximo para o arquivo de log, o arquivo será quebrado; quando o arquivo atingir o tamanho especificado, as entradas subsequentes serão gravadas na parte superior do arquivo, sobrescrevendo as entradas de log anteriores. Não é possível configurar o tamanho do log como um valor que seja menor do que o atual. As entradas de log são registradas pela data e hora, portanto, é possível informar a ordem na qual elas foram gravadas.

Quanto mais alto você configurar o nível de log, mais cuidadosamente deverá escolher o tamanho do log. No nível 0, provavelmente seja seguro deixar o tamanho do log como o padrão de 1 MB. No entanto, ao criar log no nível 3 e superior, você deverá limitar o tamanho sem torná-lo muito pequeno para que seja útil.

Logs do Controlador

Controlador Cisco CSS e Controlador Nortel Alteon têm os seguintes logs:

A seguir está um exemplo de como configurar o nível de criação de log e o tamanho máximo do log para o log do monitor de métrica que registra a comunicação com os agentes Metric Server:

xxxcontrol metriccollector set consultantID:serviceID:metricName
   loglevel x logsize y

Alterando os Caminhos do Arquivo de Log

Por padrão, os logs gerados pelos controladores são armazenados no diretório de logs da instalação do controlador. Para alterar esse caminho, configure a variável xxx_logdir no script xxxserver.

Sistemas AIX, HP-UX, Linux e Solaris: O script xxxserver está localizado no diretório /usr/bin. Nesse script, a variável xxx_logdir está configurada para o diretório padrão. É possível modificar essa variável para especificar o diretório de log. Por exemplo:

xxx_LOGDIR=/path/to/my/logs/

Sistemas Windows: O arquivo xxxserver está localizado no diretório bin <install_root>ibm\edge\lb\. No arquivo xxxserver, a variável xxx_logdir está configurada para o diretório padrão. É possível modificar essa variável para especificar o diretório de log. Por exemplo:

set xxx_LOGDIR=c:\path\to\my\logs\

Para todos os sistemas operacionais, certifique-se de que não haja nenhum espaço em um dos lados do sinal de igual e de que o caminho termine em uma barra ("/" ou "\" conforme apropriado).

Criação de log binário

O recurso de criação de log binário do Balanceador de Carga usa o mesmo diretório de log que o dos outros arquivos de log. Consulte Usando Criação de Log Binário para Analisar Estatísticas do Servidor.

Usando o Componente Dispatcher

Este seção explica como operar e gerenciar o componente Dispatcher.

Iniciando e Parando o Dispatcher

Usando o Valor de Tempo Limite Obsoleto

Para o Balanceador de Carga, as conexões são consideradas obsoletas quando não houve nenhuma atividade nessa conexão para o número de segundos especificados no tempo limite obsoleto. Quando o número de segundos tiver sido excedido sem nenhuma atividade, o Balanceador de Carga removerá esse registro de conexão de suas tabelas, e o tráfego subsequente para essa conexão será descartado.

No nível da porta, por exemplo, é possível especificar o valor de tempo limite obsoleto no comando dscontrol port set staletimeout.

O tempo limite obsoleto pode ser configurado nos níveis do executor, do cluster e da porta. Nos níveis do executor e do cluster, o padrão é 300 segundos e ele é filtrado para a porta. No nível da porta, o padrão depende da porta. Algumas portas bem definidas têm valores de tempo limite obsoleto padrão diferentes. Por exemplo, a porta 23 Telnet tem um padrão de 259.200 segundos.

Alguns serviços podem ter também valores de tempo limite obsoleto por conta própria. Por exemplo, LDAP (Lightweight Directory Access Protocol) tem um parâmetro de configuração denominado idletimeout. Quando os segundos de idletimeout tiverem sido excedidos, uma conexão do cliente inativa será encerrada forçadamente. Idletimeout também pode ser configurado como 0, o que significa que a conexão nunca será encerrada forçadamente.

Poderão ocorrer problemas de conectividade quando o valor de tempo limite obsoleto do Balanceador de Carga for menor do que o valor de tempo limite do serviço. No caso do LDAP, o valor de staletimeout do Balanceador de Carga é padronizado para 300 segundos. Se não houver nenhuma atividade na conexão por 300 segundos, o Balanceador de Carga removerá o registro de conexão de suas tabelas. Se o valor de idletimeout for maior do que 300 segundos (ou configurado como 0), o cliente poderá ainda acreditar que tem uma conexão com o servidor. Quando o cliente enviar pacotes, eles serão descartados pelo Balanceador de Carga. Isso faz com que o LDAP seja interrompido quando um pedido for feito para o servidor. Para evitar esse problema, configure o idletimeout de LDAP como um valor que não seja zero, que seja igual ou menor do que o valor de staletimeout do Balanceador de Carga.

Usando fintimeout e staletimeout para Controlar a Limpeza dos Registros de Conexão

Um cliente envia um pacote FIN depois de ter enviado todos os pacotes para que o servidor saiba que a transação foi concluída. Quando o Dispatcher recebe um pacote FIN, ele muda a transação do estado ativo para o estado FIN. Quando a transação for marcada como FIN, a memória reservada para a conexão poderá ser limpa.

Para aprimorar o desempenho da alocação e reutilização do registro de conexão, use o comando executor set fintimeout para controlar o período durante o qual o Dispatcher deve manter conexões no estado de FIN, ativas nas tabelas do Dispatcher e aceitar o tráfego. Quando uma conexão no estado de FIN exceder fintimeout, ela será removida das tabelas do Dispatcher e estarão prontas para reutilização. É possível alterar o tempo limite de FIN usando o comando dscontrol executor set fincount.

Use o comando dscontrol executor set staletimeout para controlar o período durante o qual o Dispatcher deve manter as conexões no estado Estabelecido, quando nenhum tráfego tiver sido visto como ativo nas tabelas do Dispatcher e aceitar o tráfego. Consulte Usando o Valor de Tempo Limite Obsoleto para obter informações adicionais.

Relatando a GUI — A Opção de Menu do Monitor

Vários gráficos podem ser exibidos com base nas informações do executor e retransmitidos para o gerenciador. (A opção de menu do Monitor da GUI requer que a função do gerenciador esteja em execução):

Usando Protocolo Simples de Gerenciamento de Rede com o Componente Dispatcher

Um sistema de gerenciamento de redes é um programa que é executado continuamente e é usado para monitorar, refletir o status de e controlar uma rede. Protocolo Simples de Gerenciamento de Rede (SNMP), um protocolo popular para comunicação com dispositivos em uma rede, é o atual padrão de de gerenciamento de redes. Os dispositivos de rede normalmente têm um agente do SNMP e um ou mais subagentes. O agente do SNMP se comunica com a estação de gerenciamento de redes ou responde a solicitações de SNMP da linha de comandos. O subagente do SNMP recupera e atualiza dados e os fornece ao agente do SNMP para comunicá-los de volta ao solicitante.

Dispatcher fornece uma Management Information Base do SNMP (ibmNetDispatcherMIB) e um subagente do SNMP. Isso permite usar qualquer sistema de gerenciamento de redes, como -- Tivoli NetView, Tivoli Distributed Monitoring ou HP OpenView -- para monitorar o funcionamento, o rendimento e a atividade do Dispatcher. Os dados de MIB descrevem o Dispatcher sendo gerenciado e refletem o atual status do Dispatcher. A MIB é instalada no subdiretório ..lb/admin/MIB.

Nota:
A MIB, ibmNetDispatcherMIB.02, não será carregada usando o programa xnmloadmib2 Tivoli NetView. Para corrigir esse problema, comente a linha da seção NOTIFICATION-GROUP da MIB. Ou seja, insira "- -" na frente da linha "indMibNotifications Group NOTIFICATION-GROUP" e as 6 linhas seguintes.

O sistema de gerenciamento de redes usa comandos GET do SNMP para consultar valores da MIB em outras máquinas. Depois ele pode notificá-lo se valores de limite especificados forem excedidos. É possível afetar o desempenho do Dispatcher, modificando dados de configuração para o Dispatcher, para corrigir ou sintonizar proativamente problemas do Dispatcher antes de que eles se tornem indisponibilidades do Dispatcher ou do servidor da Web.

Protocolo e Comandos SNMP

O sistema geralmente fornece um agente do SNMP para cada estação de gerenciamento de redes. O usuário envia um comando GET para o agente do SNMP. Por sua vez, esse agente do SNMP envia um comando GET para recuperar os valores de variável da MIB especificados de um subagente responsável para essas variáveis da MIB.

Dispatcher fornece um subagente que atualiza e recupera dados da MIB. O subagente responde com os dados de MIB apropriados quando o agente do SNMP envia um comando GET. O agente do SNMP comunica os dados à estação de gerenciamento de redes. A estação de gerenciamento de redes pode notificá-lo se valores de limite especificados forem excedidos.

O suporte SNMP do Dispatcher inclui um subagente SNMP que usa o recurso Distributed Program Interface (DPI). DPI é uma interface entre um agente do SNMP e seus subagentes. O sistema operacional Windows usa o agente de extensão Windows como uma interface entre o agente do SNMP e seus subagentes.

Ativando SNMP em Sistemas AIX, HP-UX, Linux e Solaris

Figura 37. Comandos SNMP para sistemas operacionais AIX, HP-UX, Linux e Solaris
Sistema do Servidor e Comandos SNMP para AIX, HP-UX, Linux e Solaris

Os sistemas AIX fornecem um agente do SNMP que usa protocolo SNMP Multiplexer (SMUX) e fornece DPID2, que é um executável adicional funcionando como conversor entre DPI e SMUX.

Para sistemas HP-UX, você deve obter um agente do SNMP ativado por SMUX, pois HP-UX não fornece nenhum. O Balanceador de Carga fornece DPID2 para sistemas HP-UX.

Sistemas Linux fornecem um agente do SNMP que usa SMUX. A maioria das versões Linux (por exemplo, Red Hat) é fornecida com um pacote UCD SNMP. UCD SNMP versão 4.1 ou posterior tem agentes SMUX ativados. O Balanceador de Carga fornece DPID2 para sistemas Linux.

Nota:
Para sistemas SuSE Linux, você deve obter um agente do SNMP que é ativado por SMUX, pois o SuSE não fornece nenhum.

Para sistemas Solaris, você deve obter um agente do SNMP ativado por SMUX, pois o Solaris não fornece nenhum. O Balanceador de Carga fornece DPID2 para sistemas Solaris no diretório the /opt/ibm/edge/lb/servers/samples/SNMP.

O agente DPI deve ser executado como usuário raiz. Antes de executar o daemon DPID2, atualize o arquivo /etc/snmpd.peers e o arquivo /etc/snmpd.conf da seguinte forma:

Para sistemas AIX e Solaris:

Para sistemas Linux:

Ativando SNMP em Sistemas HP-UX

Para instalar suporte SNMP para o HP-UX:

  1. Se você não tiver uma versão de GNU SED instalada, obtenha-a no Web site HP, http://www.hp.com.
  2. Obtenha ucd-snmp-4.2.4.tar.gz da seguinte página da Web, http://sourceforge.net/project/showfiles.php?group_id=12694.
  3. Certifique-se de ter "gcc" e "gmake or make" instalado em sua máquina. Se não, você deverá instalá-los.
  4. Descompacte o arquivo zip ucd-snmp-4.2.4.tar.gz e descompacte todos os arquivos tar no diretório.
  5. Acesse o diretório no qual os arquivos de origem são mantidos e faça o seguinte:
    1. run ./configure --with-mib-modules=smux
    2. make
    3. Execute os dois comandos seguintes como raiz:
      1. umask 022
      2. make install
    4. export SNMPCONFPATH=/etc/snmp
    5. start /usr/local/sbin/snmpd -s (Isso inicia o agente do SNMP)
    6. start dpid2 (Isso inicia o conversor de DPI)
    7. dscontrol subagent start (Isso inicia o subagente do Dispatcher)

Ativando SNMP em Sistemas SuSE Linux

Para usar SNMP do Load Balancer com sistemas SuSE Linux, você deve fazer o seguinte:

  1. Remova o ucd-snmp rpm instalado de sua máquina SuSE.
  2. Obtenha o ucd-snmp-4.2.4.tar.gz do http://sourceforge.net/project/showfiles.php?group_id=12694.
  3. Certifique-se de ter "gcc" e "gmake or make" instalados em sua máquina SuSE (você deve instalá-los se eles ainda não estiverem lá).
  4. Descompacte o arquivo zip ucd-snmp-4.2.4.tar.gz e descompacte todos os arquivos tar no diretório.
  5. Acesse o diretório no qual os arquivos de origem são mantidos e faça o seguinte:
    1. run ./configure ––with–mib–modules=smux
    2. make
    3. Execute os dois comandos seguintes como raiz:
      1. umask 022 #
      2. make install
    4. export SNMPCONFPATH=/etc/snmp
    5. start /usr/local/sbin/snmpd –s
    6. start dpid2

Atualize snmpd (se ele já estiver em execução) para que ele releia o arquivo snmpd.conf:

refresh -s snmpd

Inicie o peer DPID SMUX:

dpid2

Os daemons devem ser iniciados na seguinte ordem:

  1. Agente do SNMP
  2. Conversor do DPI
  3. Subagente do Dispatcher

Ativando SNMP em Sistemas Solaris

Para instalar suporte SNMP para o Solaris:

  1. Execute kill no daemon SNMP do Solaris em execução (snmpdx e snmpXdmid).
  2. Renomeie arquivos da seguinte forma:
  3. Faça o download dos seguintes pacotes em http://www.sunfreeware.com/:
  4. Instale os pacotes transferidos por download usando pkgadd.
  5. Faça o download de ucd-snmp-4.2.3-solaris8.tar.gz em http://sourceforge.net/project/showfiles.php?group_id=12694
  6. Descompacte os arquivos gzip e tar ucd-snmp-4.2.3-solaris8.tar.gz no diretório-raiz (/)
  7. Emita os seguintes comandos:
  8. Ele ainda não existe; crie /etc/snmpd.peers. Insira o seguinte em snmpd.peers:
    "dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2     "dpid_password"
  9. Se ele ainda não existir, crie /etc/snmp/snmpd.conf. Insira o seguinte em snmpd.conf:
    smuxpeer        1.3.6.1.4.1.2.3.1.2.2.1.1.2     dpid_password
  10. Inicie /usr/local/sbin/snmpd.
  11. Inicie /usr/local/sbin/dpid2.
Notas:
  1. Os pacotes a seguir estão em formato de pacote.

    No Web site http://sunfreeware.com/, os nomes têm uma extensão de .gz, portanto, não tente descompactá-los com gzip/tar. Em vez disso, use pkgadd packageName.

  2. Quando estiver incluindo a entrada smuxpeer em /etc/snmp/snmpd.conf, certifique-se de que nenhum espaço seja incluído na sequência dpid_password.
  3. O recurso SNMP do Balanceador de Carga é testado com versão 4.2.3 ucd-snmp ativada por smux. Liberações futuras do ucd-snmp com smux deverão trabalhar com uma configuração semelhante.

Ativando SNMP no Sistema Operacional Windows

Para instalar o suporte SNMP para o Windows:

  1. Clique em Iniciar > Painel de Controle > Incluir/Remover Programas
  2. Clique em Adicionar/Remover Componentes do Windows.
  3. No Assistente do Componente Windows, clique em Ferramentas de Gerenciamento e Monitoramento (mas não selecione e nem desmarque essa caixa de seleção) e clique em Detalhes
  4. Selecione a caixa de seleção Protocolo Simples de Gerenciamento de Rede e clique em OK.
  5. Clique em Avançar.

Fornecendo um Nome de Comunidade para SNMP

Com o executor em execução, use o comando dscontrol subagent start [communityname] para definir o nome da comunidade usado entre o agente de extensão do sistema operacional Windows e o agente do SNMP.

IMPORTANTE: No Windows 2003, por padrão, o SNMP não responde a nenhum nome de comunidade apresentado. Nesse caso, o subagente do SNMP não responderá a nenhuma solicitação do SNMP. Para garantir que o subagente do SNMP responderá ao nome da comunidade, você deve configurar Propriedades de Serviço do SNMP com o nome da comunidade e o(s) host(s) de destino apropriados. Configure as propriedades de segurança do SNMP como a seguir:

  1. Abra Gerenciamento do Computador
  2. Na árvore do console, clique em Serviços
  3. Na área de janela de detalhes, clique em Serviço do SNMP
  4. No menu de ação, clique em Propriedades
  5. Na guia Segurança, em Nomes de Comunidade Aceitos, clique em Incluir
  6. Em Direitos da Comunidade, selecione um nível de permissão para esse host para processar solicitações do SNMP a partir da comunidade selecionada (pelo menos a permissão Somente Leitura)
  7. Em Nome da Comunidade, digite um nome de comunidade com distinção entre maiúsculas e minúsculas, o mesmo fornecido para o subagente do Load Balancer (nome da comunidade padrão: public) e clique em Incluir
  8. Especifique se você vai ou não aceitar os pacotes do SNMP de um host. Selecione uma das opções a seguir:
  9. Reinicie o Serviço do SNMP para que a mudança entre em vigor

Traps

O SNMP se comunica enviando e recebendo traps, mensagens enviadas por dispositivos gerenciados para relatar condições de exceção ou a ocorrência de eventos significantes, como um limite sendo atingido.

O subagente usa os seguintes traps:

O trap indHighAvailStatus anuncia que o valor da variável de estado do status de alta disponibilidade (hasState) mudou. Os possíveis valores de hasState são:

-idle
Esta máquina está fazendo o balanceamento de carga e não está tentando estabelecer o contato com seu parceiro Dispatcher.
-listen
A alta disponibilidade foi iniciada e o Dispatcher está atendendo para seu parceiro.
-active
Esta máquina está fazendo balanceamento de carga.
-standby
Esta máquina está monitorando a máquina ativa.
-preempt
Esta máquina está em um estado transitório durante a alternância de principal para backup.
-elect
O Dispatcher está negociando com seu parceiro sobre quem será o principal ou o backup.
-no_exec
O executor não está em execução

O trap indSrvrGoneDown anuncia que o peso para o servidor especificado pela parte csID (cluster ID), psNum (port number) e ssID (server ID) do Identificador de Objeto chegou a zero. O último número conhecido de conexões ativas para o servidor é enviado no trap. Esse trap indica que, até onde o Dispatcher pode determinar, o servidor especificado ficou inativo.

O trap indDOSAttack indica que numhalfopen, o número de conexões abertas pela metade que consistem apenas em pacotes SYN, excedeu o limite maxhhalfopen para a porta especificada pela parte csID (cluster ID) e psNum (port number) do Identificador de Objeto. O número de servidores configurados na porta é enviado no trap. Esse trap indica que o Balanceador de Carga pode estar enfrentando um Ataque de Negação de Serviço.

O trap indDOSAttackDone indica que numhalfopen, número de conexões abertas pela metade que consistem apenas em pacotes SYN, ficou abaixo do limite maxhalfopen para a porta especificada pela parte csID e psNum do Identificador de Objeto. O número de servidores configurados na porta é enviado no trap. Quando o Balanceador de Carga determina que o possível ataque de Negação de Serviço acabou, esse trap é enviado após o envio de um trap indDOSAttack.

Para sistemas operacionais AIX, HP-UX, Linux e Solaris, devido à limitação na API SMUX, o identificador corporativo relatado nos traps a partir do subagente ibmNetDispatcher pode ser o identificador corporativo de dpid2, em vez do identificador corporativo de ibmNetDispatcher, 1.3.6.1.4.1.2.6.144. No entanto, utilitários de gerenciamento do SNMP podem determinar a origem do trap porque os dados vão conter um identificador de objeto de dentro da MIB do ibmNetDispatcher.

Ativando e Desativando o Suporte do SNMP a partir do Comando dscontrol

O comando dscontrol subagent start ativa o suporte SNMP. O comando dscontrol subagent stop desativa o suporte SNMP.

Para obter mais informações sobre o comando dscontrol, consulte dscontrol subagent — configurar subagente SNMP.

Usando ipchains ou iptables para Rejeitar todo o Tráfego para Fortalecer a Máquina do Balanceador de Carga (Sistemas Linux)

Construído no Linux, o kernel é uma instalação de firewall denominado ipchains. Quando o Balanceador de Carga e o ipchains são executados simultaneamente, o Balanceador de Carga vê os pacotes primeiro, seguidos por ipchains. Isso permite o uso de ipchains para fortalecer uma máquina Balanceador de Carga do Linux, que pode ser, por exemplo, uma máquina do Balanceador de Carga, usada para balancear a carga de firewalls.

Quando ipchains ou iptables são configurados como completamente restritos (nenhum tráfego de entrada ou de saída permitido), a parte de encaminhamento de pacote do Balanceador de Carga continua a funcionar normalmente.

Observe que ipchains e iptables não podem ser usados para filtrar o tráfego recebido antes de terem a carga balanceada.

Algum tráfego adicional deve ser permitido para todo o Balanceador de Carga para que funcione corretamente. Alguns exemplos desta comunicação são:

Em geral, uma estratégia ipchains apropriada para as máquinas Balanceador de Carga é desaprovar todo o tráfego, exceto aquele que vai e vem dos servidores de back-end, o Balanceador de Carga de alta disponibilidade parceiro, quaisquer destinos de alcance, ou quaisquer hosts de configuração.

Não é recomendável ativar os iptables ao executar o Balanceador de Carga no kernel do Linux versão 2.4.10.x. A ativação nesta versão do kernel do Linux pode resultar na degradação do desempenho ao longo do tempo.

Para desativar os iptables, liste os módulos (lsmod) para ver quais módulos estão usando ip_tables e ip_conntrack, em seguida, remova-os emitindo rmmod ip_tables e rmmod ip_conntrack. Ao reinicializar a máquina, esses módulos serão incluídos novamente, portanto, é necessário repetir essas etapas cada vez que você fizer a reinicialização.

Para obter informações adicionais, consulte Problema: Os Iptables do Linux Podem Interferir no Roteamento de Pacotes.

Usando o Componente Content Based Routing

Esta seção explica como operar e gerenciar o componente CBR do Balanceador de Carga.

Nota:
O componente Content Based Routing (CBR) não está disponível em plataformas que executam um JVM de 64 bits, exceto para HP-UX ia64. No HP-UX ia64, o componente CBR executa como um aplicativo de 32 bits. É possível usar o método de encaminhamento CBR do componente Dispatcher do Balanceador de Carga para fornecer roteamento baseado em conteúdo sem o uso do Caching Proxy. Consulte roteamento baseado em conteúdo do Dispatcher (Método de Encaminhamento CBR) para obter informações adicionais.

Iniciando e Parando o CBR

O CBR e o Caching Proxy colaboram usando a API do plug-in do Caching Proxy para tratar de solicitações de HTTP e HTTPS (SSL). O Caching Proxy deve estar em execução na mesma máquina para que o CBR comece a fazer o balanceamento de carga dos servidores. Configure o CBR e o Caching Proxy conforme descrito em Exemplo de Configuração do CBR.

Controlando o CBR

Após iniciar o CBR, é possível controlá-lo usando um dos seguintes métodos:

Usando Logs do CBR

Os logs usados pelo CBR são semelhantes aqueles usados no Dispatcher. Para obter informações adicionais, consulte o Usando Logs do Balanceador de Carga.

Nota:

Nos releases anteriores, para o CBR, era possível alterar o caminho do diretório de log no arquivo de configuração do Caching Proxy. Agora é possível alterar o caminho do diretório no qual o log é armazenado no arquivo cbrserver. Consulte o Alterando os Caminhos do Arquivo de Log.

Usando o Componente Site Selector

Iniciando e parandoSite Selector

Controlando o Site Selector

Após você iniciar o Site Selector, é possível controlá-lo usando um dos seguintes métodos:

Usando Logs do Site Selector

Os logs usados pelo Site Selector são semelhantes aqueles usados no Dispatcher. Para obter mais descrições, consulte Usando Logs do Balanceador de Carga.

Usando o Componente Controlador Cisco CSS

Iniciando e parandoControlador Cisco CSS

  1. Digite ccoserver em uma linha de comandos para iniciar o Controlador Cisco CSS.
  2. Digite ccoserver stop em uma linha de comandos para parar o Controlador Cisco CSS.

Controlando o Controlador Cisco CSS

Após você iniciar o Controlador Cisco CSS, é possível controlá-lo usando um dos seguintes métodos:

Usando Logs do Controlador Cisco CSS

Os logs usados pelo Controlador Cisco CSS são semelhantes aqueles usados no Dispatcher. Para obter mais descrições, consulte Usando Logs do Balanceador de Carga.

Usando o Componente Controlador Nortel Alteon

Iniciando e parandoControlador Nortel Alteon

  1. Digite nalserver em uma linha de comandos para iniciar o Controlador Nortel Alteon.
  2. Digite nalserver stop em uma linha de comandos para parar o Controlador Nortel Alteon.

Controlando o Controlador Nortel Alteon

Após você iniciar o Controlador Nortel Alteon, é possível controlá-lo usando um dos seguintes métodos:

Usando Logs do Controlador Nortel Alteon

Os logs usados pelo Controlador Nortel Alteon são semelhantes aqueles usados no Dispatcher. Para obter mais descrições, consulte Usando Logs do Balanceador de Carga.

Usando o Componente Metric Server

Iniciando e Parando o Metric Server

O Metric Server fornece informações de carregamento do servidor para o Balanceador de Carga. O Metric Server reside em cada um dos servidores que estão tendo carga balanceada.

Sistemas Linux e UNIX:

Sistemas Windows:

Clique em Iniciar > Painel de Controle > Ferramentas Administrativas > Serviços. Clique com o botão direito do mouse em IBM Metric Server e selecione Iniciar. Para parar o serviço, siga as mesmas etapas e selecione Parar.

Usando Logs do Metric Server

Altere o nível de log no script de inicialização do Metric Server. É possível especificar um intervalo de nível de log de 0 a 5, semelhante ao intervalo de nível de log nos logs do Balanceador de Carga. Isto gerará um log do agente no diretório ...ms/logs.