Este capítulo explica como operar e gerenciar o Balanceador de Carga e inclui as seguintes seções:
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.
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.
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:
Para sistemas Windows —
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\PROGRA~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\PROGRA~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\PROGRA~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\PROGRA~1\IBM\edge\lb\admin\* Pass /documentation/lang/* C:\PROGRA~1\IBM\edge\lb\documentation\lang\*em que lang é o subdiretório de idiomas (por exemplo, en_US)
Para sistemas operacionais AIX, HP-UX, Linux e Solaris —
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/lang/* /opt/ibm/edge/lb/documentation/lang/*
ln -s /opt/perl/bin/perl /usr/bin/perl
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:
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
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.
É 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.
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).
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.
É 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.
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
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).
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.
Este seção explica como operar e gerenciar o componente Dispatcher.
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.
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.
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):
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.
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.
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.
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.
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:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
Para sistemas Linux:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_passwordAlém disso, você deve comentar todas as linhas no arquivo snmpd.conf que começam com as seguintes palavras: com2sec, group, view ou access.
Para instalar suporte SNMP para o HP-UX:
Para usar SNMP do Load Balancer com sistemas SuSE Linux, você deve fazer o seguinte:
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:
Para instalar suporte SNMP para o Solaris:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
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.
Para instalar o suporte SNMP para o Windows:
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:
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:
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.
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.
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.
Esta seção explica como operar e gerenciar o componente CBR do Balanceador de Carga.
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.
Após iniciar o CBR, é possível controlá-lo usando um dos seguintes métodos:
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.
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.
Após você iniciar o Site Selector, é possível controlá-lo usando um dos seguintes métodos:
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.
Após você iniciar o Controlador Cisco CSS, é possível controlá-lo usando um dos seguintes métodos:
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.
Após você iniciar o Controlador Nortel Alteon, é possível controlá-lo usando um dos seguintes métodos:
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.
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.
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.