Este capítulo explica como configurar os parâmetros de balanceamento de carga e como configurar o Balanceador de Carga para funções avançadas.
Tarefa | Descrição | Informações relacionadas |
---|---|---|
Instalar o Balanceador de Carga em uma máquina que esteja com balanceamento de carga | Configure uma máquina do Balanceador de Carga instalado. | Usando Servidores Instalados |
Configurar a alta disponibilidade ou a alta disponibilidade mútua | Configure uma segunda máquina Dispatcher para fornecer um backup. | Alta Disponibilidade |
Configurar balanceamento de carga baseado em regras | Defina condições sob as quais um subconjunto de servidores será usado. | Configurando Balanceamento de Carga Baseado em Regras |
Usar substituição de afinidade de porta para fornecer um mecanismo para um servidor substituir o recurso permanente de porta | Permite que um servidor substitua a configuração de tempo de permanência em sua porta. | substituição de afinidade de porta |
Usar recurso permanente (afinidade) para configurar uma porta do cluster para que seja permanente | Permite que os pedidos do cliente sejam direcionados para o mesmo servidor. | Como o Recurso de Afinidade para o Balanceador de Carga Funciona |
Usar afinidade de crossport para expandir o recurso permanente (afinidade) nas portas | Permite que solicitações do cliente recebidas de diferentes portas sejam direcionadas para o mesmo servidor. | Afinidade de Porta Cruzada |
Usar máscara de endereço de afinidade para designar um endereço de sub-rede IP comum | Permite que solicitações do cliente recebidas da mesma sub-rede sejam direcionadas para o mesmo servidor. | Máscara de Endereço de Afinidade (stickymask) |
Usar afinidade de cookies ativos para servidores de balanceamento de carga para CBR | Uma opção de regra que permite que uma sessão mantenha afinidade para um determinado servidor. | Afinidade do Cookie Ativo |
Usar afinidade de cookie passivo para servidores de balanceamento de carga para roteamento baseado em conteúdo do Dispatcher e componente CBR | Uma opção de regra que permite que uma sessão mantenha afinidade para um determinado servidor com base no nome do cookie/valor do cookie. | Afinidade do Cookie Passivo |
Usar afinidade de URI para balanceamento de carga em servidores Caching Proxy com conteúdo exclusivo a ser armazenado em cache em cada servidor individual | Uma opção de regra que permite que uma sessão mantenha afinidade para um determinado servidor com base no URI. | afinidade de URI |
Configurar suporte ao Dispatcher de longa distância | Configure um Dispatcher remoto para balanceamento de carga em uma rede de longa distância. Ou faça um balanceamento de carga em uma rede de longa distância (sem um Dispatcher remoto) usando uma plataforma de servidor que suporte GRE. | Configurando Suporte ao Dispatcher de Longa Distância |
Usar ligações explícitas | Evite ignorar o Dispatcher em seus links. | Usando Link Explícito |
Usar uma rede privada | Configure o Dispatcher como servidores de balanceamento de carga em uma rede privada. | Usando uma Configuração de Rede Privada |
Usar cluster curinga para combinar configurações de servidor comum | Os endereços que não estão configurados explicitamente, usarão o cluster curinga como um modo de tráfego de balanceamento de carga. | Usar Cluster Curinga para Combinar Configurações do Servidor |
Usar cluster curinga para firewalls de balanceamento de carga | Todo o tráfego será com balanceamento de carga para firewalls. | Usar Cluster Curinga para Balanceamento de Carga de Firewalls |
Usar cluster curinga com Caching Proxy para proxy transparente | Permite que um Dispatcher seja usado para ativar um proxy transparente. | Usando Cluster Curinga com Caching Proxy para Proxy Transparente |
Usar porta curinga para direcionar tráfego de porta não configurada | Manipula o tráfego que não é configurado para qualquer porta específica. | Usar Porta Curinga para Direcionar Tráfego de Porta Não Configurada |
Usar detecção de "Denial of Service Attack" para notificar administradores (por meio de um alerta) de ataques potenciais | O dispatcher analisa pedidos recebidos para um quantidade exagerada de conexões TCP abertas pela metade em servidores. | Negação de Detecção de Ataque de Serviço |
Usar criação de log binário para analisar estatísticas do servidor | Permite que as informações do servidor sejam armazenadas em arquivos binários e recuperadas a partir desses arquivos. | Usando Criação de Log Binário para Analisar Estatísticas do Servidor |
Usar uma configuração do cliente instalado | Permitir que o Balanceador de Carga resida na mesma máquina de um cliente | Usando um Cliente Instalado |
O Balanceador de Carga pode residir na mesma máquina de um servidor para a qual ele está fazendo balanceamento de carga de pedidos. Isto é comumente referido como instalando um servidor. A instalação se aplica aos componentes Dispatcher e Site Selector. A instalação também é suportada para CBR, mas apenas quando se usa servidores da Web específicos de ligação e Caching Proxy específico de ligação.
Linux: Para configurar ambos, a disposição e alta disponibilidade ao mesmo tempo, ao executar o componente Dispatcher usando o método de encaminhamento Mac, consulte Alternativas de Criação de Alias de Loopback do Linux ao Usar Encaminhamento mac do Load Balancer.
Solaris: Existe uma limitação de que você não pode configurar orientadores WAN quando o Dispatcher do ponto de entrada estiver colocado. Consulte o Usando Orientadores Remotos com Suporte à Longa Distância do Dispatcher.
Windows: A disposição não está mais disponível.
Em liberações anteriores, era necessário especificar o endereço do servidor instalado para ser o mesmo que o nonforwarding address (NFA) na configuração. Essa restrição foi elevada.
Para configurar um servidor a ser instalado, o comando dscontrol server fornece uma opção denominada instalado que pode ser configurado como yes ou no. O padrão é no. O endereço do servidor deve ser um endereço IP válido de uma placa da interface de rede na máquina. O parâmetro collocated não deve ser configurado para servidores que são instalados usando o método de encaminhamento nat ou cbr do Dispatcher.
É possível configurar um servidor instalado de uma das seguintes maneiras:
Para encaminhamento nat ou cbr do Dispatcher, você deve configurar (alias) um endereço de adaptador não usado no NFA. O servidor deve ser configurado para atender nesse endereço. Configure o servidor usando a seguinte sintaxe de comando:
dscontrol server add cluster:port:new_alias address new_alias router router_ip returnaddress return_address
Uma falha nessa configuração pode levar a erros no sistema, em falta de resposta do servidor ou ambos.
Durante a configuração de um servidor instalado usando o método de encaminhamento nat do Dispatcher, o roteador especificado no comando dscontrol server add deve ser um endereço de roteador real, e não o endereço IP do servidor.
O suporte para a disposição ao configurar o método de encaminhamento nat do Dispatcher agora pode ser feito nos seguintes sistemas operacionais se as seguintes etapas forem executadas na máquina do Dispatcher:
arp -s hostname ether_addr pubusando o endereço MAC local para ether_addr. Isso permite que o aplicativo local envie tráfego para o endereço de retorno no kernel.
O CBR suporta a disposição em plataformas AIX, HP-UX, Linux, e Solaris sem configurações adicionais necessárias. No entanto, os servidores da Web e o Caching Proxy que você usa devem ser específicos de ligação.
O Seletor de Site suporta a disposição em plataformas AIX, HP-UX, Linux, e Solaris sem configurações adicionais necessárias.
A função de alta disponibilidade (configurável usando o comando dscontrol highavailability) está disponível para o componente Dispatcher (mas não para os componentes CBR ou Site Selector).
Para melhorar a disponibilidade do Dispatcher, a função de alta disponibilidade do Dispatcher usa os seguintes mecanismos:
Se possível, pelo menos um dos pares de pulsações deve estar em uma sub-rede separada do que no tráfego de cluster regular. Manter o tráfego de pulsação distinto ajudará a evitar falsos controles durante carregamentos muito pesados da rede e também a melhorar o tempo de recuperação completa depois de um failover.
A sintaxe completa para dscontrol highavailability está em alta disponibilidade de dscontrol — controle de alta disponibilidade.
Para obter uma discussão mais completa de muitas das tarefas a seguir, consulte Configurando a Máquina do Dispatcher.
dscontrol highavailability heartbeat add sourceaddress destinationaddress
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3Pelo menos um par de pulsações deve ter os NFAs do par como o endereço de origem e de destino.
Se possível, pelo menos um dos pares de pulsações deve estar em uma sub-rede separada do que no tráfego de cluster regular. Manter o tráfego de pulsação distinto ajudará a evitar falsos controles durante carregamentos muito pesados da rede e também a melhorar o tempo de recuperação completa depois de um failover.
Configure o número de segundos que o executor usa para definir o tempo limite de pulsações de alta disponibilidade. Por exemplo:
dscontrol executor set hatimeout 3
O padrão é 2 segundos.
dscontrol highavailability reach add 9.67.125.18Os destinos de alcance são recomendados, mas não são necessários. Consulte Capacidade de Detecção de Falha Usando Pulsação e Destino de Alcance para obter informações adicionais.
dscontrol highavailability backup add primary [auto | manual] port
dscontrol highavailability backup add backup [auto | manual] port
dscontrol highavailability backup add both [auto | manual] port
dscontrol highavailability statusCada máquina deve ter a função (backup, principal ou ambas), estados e subestados corretos. A principal deve estar ativa e sincronizada; a de backup deve estar no modo de espera e deve ser sincronizada dentro de um tempo curto. As estratégias devem ser as mesmas.
dscontrol cluster set clusterA primaryhost NFAdispatcher1 dscontrol cluster set clusterB primaryhost NFAdispatcher2
dscontrol cluster set clusterB primaryhost NFAdispatcher2 dscontrol cluster set clusterA primaryhost NFAdispatcher1
Além dos critérios básicos de detecção de falha (a perda de conectividade entre Dispatchers ativos e em espera, detectados por meio das mensagens de pulsação), há outro mecanismo de detecção de falha nomeado Critérios de Alcance. Ao configurar o Dispatcher, é possível fornecer uma lista hosts que cada um dos Dispatchers deve poder alcançar, para funcionar corretamente. Os dois parceiros de alta disponibilidade se comunicam continuamente entre si por meio de pulsações, e ele são atualizados entre si sobre quantos destinos de alcance um deles pode executar ping. Se os destinos de alcance em espera executar mais pings do que o ativo, ocorrerá um failover.
As pulsações são enviadas pelo Dispatcher ativo e se espera que sejam recebidas pelo Dispatcher em espera a cada meio segundo. Se o Dispatcher em espera falhar ao receber uma pulsação dentro de dois segundos, um failover será iniciado. Todas as pulsações devem ser quebradas para que um controle do Dispatcher em espera ocorra. Em outras palavras, quando dois pares de pulsações forem configurados, as duas pulsações deverão ser quebradas. Para estabilizar um ambiente de alta disponibilidade e evitar failover, inclua mais de um par de pulsação.
Para destinos de alcance, você deve escolher pelo menos um host para cada sub-rede usada pela sua máquina do Dispatcher. Os hosts podem ser roteadores, servidores IP ou outros tipos de hosts. O alcance do host é obtido pelo orientador de alcance, que executa ping no host. O failover ocorrerá, se as mensagens de pulsação não puderem ser transmitidas, ou se os critérios de alcance forem melhor atendidos pelo Dispatcher em espera do que pelo Dispatcher principal. Para tomar a decisão baseada em todas as informações disponíveis, o Dispatcher ativo envia regularmente ao Dispatcher em espera seus recursos de alcance. Em seguida, o Dispatcher em espera compara esses recursos com os seus próprios e decide se devem ser alternados.
Duas máquinas do Dispatcher são configuradas: a máquina principal e uma segunda máquina denominada backup. Na inicialização, a máquina principal envia todos os dados de conexão à máquina de backup até que ela seja sincronizada. A máquina principal se torna ativa, isto é, inicia o balanceamento de carga. Enquanto isso, a máquina de backup monitora o status da máquina principal e diz-se estar no estado de espera.
Se a qualquer momento a máquina de backup detectar que a máquina principal falhou, ela executará um controle das funções de balanceamento de carga da máquina principal e se tornará a máquina ativa. Depois que a máquina principal se tornar operacional novamente, as máquinas responderão de acordo com o modo com que a estratégia de recuperação foi configurada pelo usuário. Existem dois tipos de estratégia:
O parâmetro de estratégia deve ser configurado igual para ambas a máquinas.
A estratégia de recuperação manual permite forçar o roteamento de pacotes para uma máquina específica, usando o comando de controle. A recuperação manual será útil quando a manutenção estiver sendo executada na outra máquina. A estratégia de recuperação automática é designada para operação autônoma normal.
Para uma configuração de alta disponibilidade mútua, não há nenhuma falha por cluster. Se ocorrer qualquer problema com uma máquina, mesmo que ele afete apenas um cluster, a outra máquina será controlada para os dois clusters.
Para que o Dispatcher roteie pacotes, cada endereço do cluster deve estar com alias para um dispositivo da interface de rede.
Para obter informações sobre como criar um alias na placa da interface de rede, consulte Etapa 5. Criar o Alias da Placa da Interface de Rede.
Como as máquinas do Dispatcher alterarão os estados quando uma falha for detectada, os comandos acima deverão ser emitidos automaticamente. O Dispatcher executará scripts criados pelo usuário para fazer isso. Os scripts de amostra podem ser localizados no seguinte diretório:
Esses scripts devem ser movidos para o seguinte diretório para executar:
Os scripts apenas serão executados automaticamente, se dsserver estiver em execução.
Os seguintes scripts de amostra podem ser usados:
Em sistemas Windows: Em sua, instalação de configuração, se você tiver o Site Selector fazendo o balanceamento de carga de duas máquinas do Dispatcher que estão em operação em um ambiente de alta disponibilidade, será necessário incluir um alias na pilha da Microsoft para os servidores de métrica. Esse alias deve ser incluído no script goActive. Por exemplo:
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
Em goStandby e goInOp, o alias precisará ser removido. Por exemplo:
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
Se houver diversos NIC na máquina, primeiro verifique qual interface você deve usar emitindo o seguinte comando no prompt de comandos: netsh interface ip show address. Esse comando retornará uma lista de interfaces atualmente configuradas e numerará "Local Area Connection" (por example, "Local Area Connection 2") para que seja possível determinar qual deve ser usada.
No Linux para S/390: O Dispatcher emite um ARP gratuito para mover endereços IP de um Dispatcher para outro. Esse mecanismo é portanto unido o tipo de rede subjacente. Ao executar o Linux para S/390, o Dispatcher poderá fazer com que a alta disponibilidade seja controlada nativamente (concluída com mudanças do endereço IP), apenas naquelas interfaces que podem emitir um ARP gratuito e configurar o endereço na interface local. Esse mecanismo não funcionará corretamente em interfaces ponto a ponto, como IUCV e CTC e não funcionarão em determinadas configurações de qeth/QDIO.
Para aquelas interfaces e configurações em que a função de controle de IP nativo do Dispatcher não funcionará corretamente, o cliente poderá colocar comandos apropriados nos scripts go para mudar manualmente os endereços. Isso garantirá que aquelas topologias de rede possam se beneficiar também da alta disponibilidade.
É possível usar balanceamento de carga baseado em regras para ajustar quando e porque pacotes são enviados para servidores. O Balanceador de Carga revisa quaisquer regras incluídas da primeira prioridade à última, parando na primeira regra considerada verdadeira e fazendo o balanceamento de carga do conteúdo entre quaisquer servidores associados à regra. O balanceamento já é feito na carga com base no destino e na porta, mas o uso de regras expande sua capacidade de distribuir conexões.
Na maioria dos casos durante a configuração de regras, você deve configurar uma regra padrão sempre true para capturar qualquer solicitação transmitida por outras regras de prioridade mais alta. Esse padrão pode ser uma resposta "O site está atualmente inativo, tente novamente mais tarde" quando todos os servidores falharem para o pedido do cliente.
Você deve usar balanceamento de carga baseado em regras com Dispatcher e Site Selector quando quiser usar um subconjunto de seus servidores por alguma razão. Você deve sempre usar regras para o componente CBR.
É possível escolher entre os seguintes tipos de regras:
Faça um plano da lógica que as regras devem seguir antes de iniciar a inclusão de regras em sua configuração.
Todas as regras têm um nome, tipo, prioridade e podem ter um intervalo inicial e um intervalo final, junto com um conjunto de servidores. Além disso, a regra de tipo de conteúdo para o componente CBR tem um padrão de expressão regular correspondente associado a ela. (Para obter exemplos e cenários de como usar a regra de conteúdo e uma sintaxe padrão válida para a regra de conteúdo, consulte Apêndice B. Sintaxe de Regra de Conteúdo (Padrão).)
As regras são avaliadas na ordem de prioridade. Em outras palavras, uma regra cuja prioridade é 1 (número menor) é avaliada antes de uma regra com prioridade 2 (número maior). A primeira regra que é atendida será usada. Quando uma regra for atendida, nenhuma outra regra será avaliada.
Para que uma regra seja atendida, ela deve atender a duas condições:
Se uma regra não tiver servidores associados a ela, ela só precisará atender à condição um para ser satisfeita. Nesse caso, o Dispatcher descartará a solicitação de conexão, o Site Selector retornará a solicitação de servidor de nomes com um erro e o CBR fará o Caching Proxy retornar uma página de erro.
Se nenhuma regra for satisfeita, o Dispatcher selecionará um servidor do conjunto completo de servidores disponíveis na porta, o Site Selector selecionará um servidor do conjunto completo de servidores disponíveis no nome do site e o CBR fará o Caching Proxy retornar uma página de erro.
Esse tipo de regra está disponível nos componentes Dispatcher, CBR ou Site Selector.
Você pode querer usar regras com base no endereço IP do cliente se quiser analisar cuidadosamente os clientes e alocar recursos com base em sua origem.
Por exemplo, você observa que sua rede está repleta de tráfego não pago e, portanto, indesejado de clientes vindos de um conjunto específico de endereços IP. Você cria uma regra usando o comando dscontrol rule, por exemplo:
dscontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
Essa regra "ni" analisa cuidadosamente qualquer conexão de clientes indesejados. Você então incluiria na regra os servidores que quer acessíveis, ou, se não incluir nenhum servidor na regra, solicitações vindas de endereços 9.x.x.x não serão atendidas por nenhum de seus servidores.
Esse tipo de regra só está disponível no componente Dispatcher.
Você pode querer usar regras baseadas na porta do cliente se seus clientes estiverem usando algum tipo de software que solicite uma porta específica de TCP/IP ao fazer solicitações.
Por exemplo, você poderia criar uma regra que diz que qualquer solicitação com uma porta de cliente 10002 usará um conjunto de servidores rápidos especiais, pois você sabe que qualquer solicitação do cliente com essa porta é proveniente de um grupo de elite de clientes.
Esse tipo de regra está disponível nos componentes Dispatcher, CBR ou Site Selector.
Você pode querer usar regras com base no horário do dia por razões de planejamento da capacidade. Por exemplo, se houver muitas ocorrências do seu Web site durante o mesmo grupo de horas todos os dias, é possível querer dedicar cinco servidores adicionais durante o período do horário de pico.
Outra razão pela qual é possível usar uma regra baseada no horário do dia é quando você quer deixar alguns servidores inativos para manutenção todas as noites à meia noite; assim, é possível configurar uma regra que exclua esses servidores durante o período de manutenção necessário.
Esse tipo de regra só está disponível no componente Dispatcher.
Você pode querer usar regras com base no conteúdo do campo “tipo de serviço” (TOS) no cabeçalho IP. Por exemplo, se chegar uma solicitação de cliente com um valor de TOS que indique um serviço normal, ela poderá ser roteada para um conjunto de servidores. Se chegar uma solicitação de cliente diferente com um valor de TOS diferente que indique uma prioridade de serviço mais alta, ela poderá ser roteada para um conjunto de servidores diferente.
A regra de TOS permite configurar completamente cada bit no byte do TOS usando o comando dscontrol rule . Para bits significativos que você quer que sejam correspondentes no byte do TOS, use 0 ou 1. Caso contrário, o valor x será usado. A seguir está um exemplo de inclusão de uma regra do TOS:
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
Esse tipo de regra está disponível nos componentes Dispatcher e CBR.
Você pode querer usar regras baseadas em conexões por segundo se precisar compartilhar alguns de seus servidores com outros aplicativos. Por exemplo, é possível configurar duas regras:
Ou é possível estar usando Telnet e querer reservar dois de seus cinco servidores para Telnet, exceto quando as conexões por segundo ficarem acima de um determinado nível. Dessa maneira, o Dispatcher faria o balanceamento de carga nos cinco servidores nos horários de pico.
Configuração da opção de avaliação de regra "upserversonrule" junto com a regra do tipo "conexão": Ao usar a regra do tipo conexões e configurar a opção upserversonrule, se algum dos servidores no conjunto de servidores estiver inativo, será possível garantir que os servidores restantes não sejam sobrecarregados. Consulte Opção de Avaliação de Servidor para Regras para obter informações adicionais.
Esse tipo de regra está disponível no componente Dispatcher ou CBR.
Você pode desejar usar as regras com base no total de conexões ativas em uma porta se seus servidores forem sobrecarregados e iniciar a emissão de pacotes. Determinados servidores da Web continuarão aceitando conexões mesmo se eles não possuírem encadeamentos suficientes para responder ao pedido. Como resultado, os pedidos do cliente expiram e o cliente que acessa seu Web site não é atendido. É possível usar essas regras com base nas conexões ativas para balancear a capacidade dentro de um conjunto de servidores.
Por exemplo, você conhece por experiência que seus servidores pararão de atender depois que 250 conexões forem aceitas. É possível criar uma regra usando o comando dscontrol rule ou o comando cbrcontrol rule; por exemplo:
dscontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 ou cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
Em seguida, inclua na regra seus servidores atuais mais alguns servidores adicionais, que serão usados de outra forma para outro processamento.
As regras de largura da banda reservada e largura da banda compartilhada só estão disponíveis no componente Dispatcher.
Para regras de largura da banda, o Dispatcher calcula a largura da banda como a taxa em que os dados são entregues para os clientes por um conjunto específico de servidores. O Dispatcher controla a capacidade nos níveis do servidor, regra, porta, cluster e executor. Para cada um desses níveis, há um campo contador de bytes: kilobytes transferidos por segundo. O Dispatcher calcula essas taxas acima de um intervalo de 60 segundos. É possível visualizar esses valores de taxa a partir da GUI ou da saída de um relatório de linha de comandos.
A regra de largura da banda reservada permite controlar o número de kilobytes por segundo sendo entregue por um conjunto de servidores. Com a configuração de um limite (alocando um intervalo de largura da banda especificado) para cada conjunto de servidores na configuração, é possível controlar e garantir a quantidade de largura da banda sendo usada por cada combinação de cluster-porta.
A seguir está um exemplo de inclusão de uma regra reservedbandwidth:
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
O intervalo inicial e o intervalo final são especificados em kilobytes por segundo.
Antes de configurar a regra de largura da banda compartilhada, você deve especificar a quantidade máxima de largura da banda (kilobytes por segundo) que pode ser compartilhada no nível do executor ou cluster usando o comando dscontrol executor ou dscontrol cluster com a opção sharedbandwidth. O valor sharebandwidth não deve exceder a largura da banda total (capacidade de rede total) disponível. O uso do comando dscontrol para configurar a largura da banda compartilhada só fornece um limite superior para a regra.
A seguir estão exemplos da sintaxe de comando:
dscontrol executor set sharedbandwidth size dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth size
O valor size para sharedbandwidth é um valor de número inteiro (kilobytes por segundo). O padrão é zero. Se o valor for zero, a largura da banda não poderá ser compartilhada.
O compartilhamento de largura da banda no nível do cluster permite que uma largura de banda máxima compartilhada seja usada pelo cluster. Contanto que a largura da banda usada pelo cluster esteja abaixo da quantidade especificada, essa regra será avaliada como true. Se a largura da banda total usada for maior que a quantidade especificada, essa regra será avaliada como false.
O compartilhamento de largura da banda no nível do executor permite que a configuração do Dispatcher inteira compartilhe uma quantidade máxima de largura de banda. Contanto que a largura da banda usada no nível do executor esteja abaixo da quantidade especificada, essa regra será avaliada como true. Se a largura da banda total usada for maior que a definida, essa regra será avaliada como false.
A seguir estão exemplos de inclusão e configuração de uma regra sharedbandwidth:
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel value dscontrol rule set 9.20.34.11:80:shrule sharelevel value
O value para sharelevel é executor ou cluster. Sharelevel é um parâmetro obrigatório na regra sharebandwidth.
O Dispatcher permite alocar uma largura da banda especificada para conjuntos de servidores dentro de sua configuração usando a regra largura da banda reservada. Ao especificar intervalos inicial e final, é possível controlar o intervalo de kilobytes entregues por um conjunto de servidores para os clientes. Quando a regra não é mais avaliada como true (o intervalo final é excedido), a próxima regra de prioridade inferior é avaliada. Se a próxima regra de prioridade inferior for uma regra "sempre true", um servidor poderia ser selecionado para responder ao cliente com uma resposta "site ocupado".
Por exemplo: Considere um grupo de três servidores na porta 2222. Se a largura da banda reservada for configurada como 300, o máximo de kbytes por segundo será 300, acima de um período de 60 segundos. Quando essa taxa é excedida, a regra não é mais avaliada como true. Se essa fosse a única regra, um dos três servidores seria selecionado pelo Dispatcher para tratar da solicitação. Se houvesse uma regra de prioridade inferior "sempre true", a solicitação poderia ser redirecionada para outro servidor e respondida com "site ocupado".
A regra de largura da banda compartilhada pode fornecer acesso adicional ao servidor para os clientes. Especificamente, quando usado como uma regra de prioridade inferior após uma regra de largura da banda reservada, um cliente ainda pode acessar um servidor mesmo que a largura da banda reservada tenha sido excedida.
Por exemplo: Ao usar uma regra de largura da banda compartilhada após uma regra de largura da banda reservada, é possível permitir que clientes tenham acesso aos três servidores de uma maneira controlada. Contato que haja largura da banda compartilhada disponível para ser usada, a regra será avaliada como true e o acesso será concedido. Se não houver largura da banda compartilhada disponível, a regra não será true e a próxima regra será avaliada. Se uma regra "sempre true" seguir, a solicitação poderá ser redirecionada conforme necessário.
Ao usar largura da banda reservada e compartilhada, conforme descrito no exemplo anterior, uma flexibilidade e um controle maiores poderão ser praticados na concessão (ou negação) de acesso aos servidores. Os servidores em uma porta específica poderão ser limitados no uso da largura da banda, enquanto outros poderão usar largura da banda adicional contanto que ela esteja disponível.
Esse tipo de regra só está disponível no componente Site Selector.
Para a regra métrica todos, você escolha uma métrica do sistema (cpuload, memload ou seu próprio script de métrica do sistema customizado) e o Site Selector compara o valor da métrica do sistema (retornado pelo agente Metric Server que reside em cada servidor de carga balanceada) com os intervalos inicial e final especificados na regra. O valor da métrica do sistema atual para todos os servidores no conjunto de servidores deve estar dentro do intervalo para a regra ser executada.
A seguir está um exemplo de inclusão de uma regra métrica todos em sua configuração:
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
Esse tipo de regra só está disponível no componente Site Selector.
Para a regra métrica média, você escolha uma métrica do sistema (cpuload, memload ou seu próprio script de métrica do sistema customizado) e o Site Selector compara o valor da métrica do sistema (retornado pelo agente Metric Server que reside em cada servidor de carga balanceada) com os intervalos inicial e final especificados na regra. A média dos valores de métrica do sistema atual para todos os servidores no conjunto de servidores deve estar dentro do intervalo para a regra ser executada.
A seguir está um exemplo de inclusão de uma regra métrica média em sua configuração:
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
Esse tipo de regra está disponível nos componentes Dispatcher, CBR ou Site Selector.
Uma regra pode ser criada como “sempre true”. Essa regra será sempre selecionada, a menos que todos os servidores associados a ela estejam inativos. Por essa razão, geralmente ela deve ter uma prioridade inferior a de outras regras.
É possível ter diversas regras “sempre true”, cada uma com um conjunto de servidores associado a ela. A primeira regra true com um servidor disponível é escolhida. Por exemplo, suponha que você possua seis servidores. Você deseja que dois deles manipulem seu tráfego sob todas as circunstâncias, a menos que os dois estejam inativos. Se os primeiros dois servidores estiverem inativos, você desejará que um segundo conjunto de servidores manipule o tráfego. Se todos esses quatro servidores estiverem inativos, você usará os dois servidores finais para manipular o tráfego. Você poderia configurar três regras “sempre true”. O primeiro conjunto de servidores será sempre escolhido, contanto que pelo menos um esteja ativo. Se ambos estiverem inativos, um do segundo conjunto será escolhido, e assim por diante.
Como outro exemplo, talvez você queira uma regra “sempre true” para garantir que se os clientes recebidos não corresponderem a nenhuma das regras configuradas, eles não serão atendidos. Você criaria uma regra usando o comando dscontrol rule como:
dscontrol rule add 130.40.52.153:80:jamais type true priority 100
Em seguida, você não incluiria nenhum servidor à regra, fazendo com que os pacotes dos clientes sejam descartados sem nenhuma reposta.
É possível definir mais de uma regra “sempre true” e, depois, ajustar quais serão executadas alterando seus níveis de prioridade.
Esse tipo de regra está disponível no componente CBR ou no componente Dispatcher (durante o uso do método de encaminhamento cbr do Dispatcher).
Você vai querer usar regras de tipo de conteúdo para enviar solicitações para conjuntos de servidores configurados especificamente para lidarem com alguns subconjuntos de tráfego do site. Por exemplo, é possível querer usar um conjunto de servidores para lidar com todas as solicitações cgi-bin, outro conjunto para lidar com todas as solicitações de fluxo de áudio e um terceiro conjunto para lidar com todas as outras solicitações. Você incluiria uma regra com um padrão que corresponde ao caminho para seu diretório cgi-bin, outra que corresponde ao tipo de arquivo de seus arquivos de fluxo de áudio e uma terceira regra sempre true para lidar com o restante do tráfego. Você incluiria os servidores apropriados em cada uma das regras.
Importante: Para obter exemplos e cenários de como usar a regra de conteúdo e uma sintaxe padrão válida para a regra de conteúdo, consulte Apêndice B. Sintaxe de Regra de Conteúdo (Padrão).
Com a substituição de afinidade de porta, é possível substituir a permanência de uma porta para um servidor específico. Por exemplo, você está usando uma regra para limitar a quantidade de conexões para cada servidor de aplicativos e tem um servidor de estouro com uma regra sempre true que diz “tente novamente mais tarde" para esse aplicativo. A porta tem um valor de permanência de 25 minutos, portanto, você não quer que o cliente seja permanente para esse servidor. Com a substituição de afinidade de porta, é possível alterar o servidor de estouro para substituir a afinidade normalmente associada a essa porta. Na próxima vez que o cliente solicitar o cluster, ele terá sua carga balanceada para o melhor servidor de aplicativos disponível, e não para o servidor de estouro.
Consulte dscontrol server — configurar servidores para obter informações detalhadas sobre a sintaxe de comando para a substituição de afinidade de porta usando o servidor permanente .
É possível incluir regras usando o comando dscontrol rule add, editando o arquivo de configuração de amostra ou com a interface gráfica com o usuário (GUI). É possível incluir uma ou mais regras em cada porta definida.
Esse é um processo de duas etapas: incluir a regra e depois definir quais servidores atender se a regra for true. Por exemplo, nosso administrador do sistema queria controlar o uso de cada divisão por parte dos servidores proxy no site. Endereços IP são fornecidos para cada divisão. Crie o primeiro conjunto de regras com base no endereço IP do cliente para separar a carga de cada divisão:
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
Em seguida, inclua um servidor diferente em cada regra e meça a carga em cada um dos servidores para cobrar a divisão corretamente pelos serviços que eles estão usando. Por exemplo:
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
A opção de avaliação de servidor só está disponível no componente Dispatcher.
No comando dscontrol rule, há uma opção de avaliação de servidor para regras. Use a opção evaluate para escolher se quer avaliar a condição da regra em todos os servidores na porta ou avaliar a condição da regra apenas nos servidores dentro da regra. (Em versões anteriores do Balanceador de Carga, você só poderia medir a condição de cada regra em todos os servidores na porta.)
A seguir estão exemplos de inclusão ou configuração da opção de avaliação em uma regra de largura da banda reservada:
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate level dscontrol rule set 9.22.21.3:80:rbweval evaluate level
O level da avaliação pode ser configurado como porta, regra ou upserversonrule. O padrão é porta.
A opção para medir a condição da regra nos servidores dentro da regra permite configurar duas regras com as seguintes características:
O resultado é que quando o tráfego excede o limite dos servidores dentro da primeira regra, o tráfego é enviado para o servidor “site ocupado" dentro da segunda regra. Quando o tráfego falha abaixo do limite dos servidores dentro da primeira regra, o novo tráfego continua novamente para os servidores na primeira regra.
Usando as duas regras descritas no exemplo anterior, se você configurar a opção de avaliação como port para a primeira regra (avaliar a condição da regra em todos os servidores na porta), quando o tráfego exceder o limite dessa regra, ele será enviado para o servidor “site ocupado" para a segunda regra.
A primeira regra mede todo o tráfego do servidor (incluindo o servidor “site ocupado") na porta para determinar se o tráfego excede o limite. Conforme o congestionamento diminui para os servidores associados à primeira regra, pode ocorrer um resultado não intencional no qual o tráfego continua para o servidor “site ocupado", pois o tráfego na porta ainda excede o limite da primeira regra.
Para os componentes Dispatcher e CBR: Você ativa o recurso de afinidade quando configura a porta de um cluster como permanente. A configuração de uma porta do cluster para que seja permanente, permite que os pedidos de clientes subsequentes sejam direcionados ao mesmo servidor. Isto é feito configurando o tempo de permanência no nível do executor, do cluster ou da porta em alguns segundos. O recurso é desativado configurando o tempo de permanência como zero.
Se você estiver ativando afinidade de crossport, os valores de tempo de permanência das portas compartilhadas deverão ter o mesmo valor igual a zero (não zero). Consulte Afinidade de Porta Cruzada para obter informações adicionais.
Para o componente Site Selector: Você ativa o recurso de afinidade ao configurar um nome de site como permanente. A configuração de um nome de site como permanente permite que o cliente use o mesmo servidor para diversas solicitações de serviço de nomes. Isso é feito configurando-se o tempo de permanência em sitename para alguns segundos. O recurso é desativado configurando o tempo de permanência como zero.
Um valor de tempo de permanência para um servidor é o intervalo entre o fechamento de uma conexão e a abertura de uma nova conexão durante o tempo em que um cliente é enviado de volta para o mesmo servidor usado durante a primeira conexão. Após a expiração do tempo de permanência, o cliente pode ser enviado para um servidor diferente do primeiro. O valor do tempo de permanência para um servidor é configurando usando os comandos dscontrol, executor, port ou cluster.
Com o recurso de afinidade desativado, sempre que uma nova conexão TCP é recebida de um cliente, o Balanceador de Carga seleciona o servidor correto naquele ponto no tempo e encaminha os pacotes para ele. Se uma conexão subsequente for recebida do mesmo cliente, o Balanceador de Carga a tratará como uma nova conexão não relacionada e selecionará novamente o servidor correto naquele ponto no tempo.
Com o recurso de afinidade ativado, se um pedido subsequente for recebido do mesmo cliente, o pedido será direcionado para o mesmo servidor.
Ao longo do tempo, o cliente concluirá o envio de transações, e o registro de afinidade desaparecerá. Portanto, o significado "tempo" de permanência. Cada registro de afinidade fica ativo pelo "tempo de permanência" em segundos. Quando as conexões subsequentes forem recebidas dentro do tempo de permanência, o registro de afinidade ainda estará válido e o pedido irá para o mesmo servidor. Se uma conexão subsequente não for recebida dentro do tempo de permanência, o registro será limpo. A conexão recebida após esse tempo terá um novo servidor selecionado para ela.
O comando server down (dscontrol server down) é usado para tornar o servidor off-line. O servidor não será desativado até que o valor do tempo de permanência expire.
A afinidade de crossport aplica-se apenas aos métodos de encaminhamento MAC e NAT/NATP do componente Dispatcher.
A afinidade de crossport é o recurso permanente que foi expandido para cobrir diversas portas. Por exemplo, se uma solicitação do cliente for recebida primeiro em uma porta e a próxima solicitação for recebida em outra porta, a afinidade de crossport permitirá que o dispatcher envie a solicitação do cliente para o mesmo servidor. Para usar esse recurso, as portas deverão:
Mais de uma porta pode ser vinculada à mesma crossport. Quando conexões subsequentes vierem do mesmo cliente na mesma porta ou em uma porta compartilhada, o mesmo servidor será acessado. A seguir está um exemplo de uma configuração de diversas portas com uma afinidade de crossport como porta 10:
dscontrol port set cluster:20 crossport 10 dscontrol port set cluster:30 crossport 10 dscontrol port set cluster:40 crossport 10
Depois que a afinidade de crossport for estabelecida, você terá a flexibilidade de modificar o valor de tempo de permanência para a porta. No entanto, é recomendado trocar os valores de tempo de permanência para todas as portas compartilhadas para o mesmo valor, caso contrário, podem ocorrer resultados inesperados.
Para remover a afinidade de crossport, configure o valor de crossport novamente para seu próprio número de porta. Consulte dscontrol port — configurar portas para obter informações detalhadas sobre a sintaxe de comando para a opção crossport.
A máscara de endereço de afinidade aplica-se apenas ao componente Dispatcher.
A máscara de endereço de afinidade é um aprimoramento de recurso permanente para agrupar clientes baseados em endereços de sub-rede comuns. A especificação de stickymask no comando dscontrol port permite mascarar high-order bits comuns do endereço IP de 32 bits. Se esse recurso estiver configurado, quando uma solicitação do cliente estabelecer uma conexão com a porta pela primeira vez, todas as solicitações subsequentes dos clientes com o mesmo endereço de sub-rede (representadas pela parte do endereço sendo mascarada) serão direcionadas para o mesmo servidor.
Por exemplo, se você quiser que todas as solicitações de cliente recebidas com o mesmo endereço de rede Classe A sejam direcionadas para o mesmo servidor, configure o valor stickymask como 8 (bits) para a porta. Para agrupar solicitações do cliente com o mesmo endereço de rede Classe B, configure o valor stickymask como 16 (bits). Para agrupar solicitações do cliente com o mesmo endereço de rede Classe C, configure o valor stickymask como 24 (bits).
Para obter melhores resultados, configure o valor stickymask ao iniciar o Balanceador de Carga pela primeira vez. Se você alterar o valor stickymask dinamicamente, os resultados serão imprevisíveis.
Interação com afinidade de crossport: Se estiver ativando afinidade de crossport, os valores stickymask das portas compartilhadas deverão ser os mesmos. Consulte Afinidade de Porta Cruzada para obter informações adicionais.
Para ativar a máscara de endereço de afinidade, emita um comando dscontrol port semelhante ao seguinte:
dscontrol port set cluster:port stickytime 10 stickymask 8
Os possíveis valores stickymask são 8, 16, 24 e 32. Um valor igual a 8 especifica que os 8 primeiros high-order bits do endereço IP (endereço de rede Classe A) serão mascarados. Um valor igual a 16 especifica que os 16 primeiros high-order bits do endereço IP (endereço de rede Classe B) serão mascarados. Um valor igual a 24 especifica que os 24 primeiros high-order bits do endereço IP (endereço de rede Classe C) serão mascarados. Se você especificar um valor igual a 32, você estará mascarando o endereço IP todo, o que desativa efetivamente o recurso de máscara de endereço de afinidade. O valor padrão de stickymask é 32.
Consulte dscontrol port — configurar portas para obter informações detalhadas sobre a sintaxe de comando para stickymask (recurso de máscara de endereço de afinidade).
A manipulação de quiesce aplica-se aos componentes Dispatcher e CBR.
Para remover um servidor da configuração do Balanceador de Carga por qualquer motivo (atualizações, upgrades, serviço, etc), é possível usar o comando dscontrol manager quiesce. O subcomando quiesce permite que conexões existentes sejam concluídas (sem ser danificadas) e encaminhará apenas novas conexões subsequentes do cliente para o servidor em quiesce, se a conexão estiver designada como permanente e o tempo de permanência não tiver sido expirado. O subcomando quiesce desaprova quaisquer outras novas conexões com o servidor.
Use a opção Suspender “Agora", se tiver configurado o tempo de permanência e desejar que novas conexões sejam enviadas para outro servidor (em vez do servidor em estado de quiesce) antes do tempo de permanência expirar. O exemplo a seguir é sobre como usar a opção Agora para suspender o servidor 9.40.25.67:
dscontrol manager quiesce 9.40.25.67 now
A opção Agora determina como as conexões permanentes serão manipuladas da seguinte maneira:
Esta é a maneira mais normal e menos abrupta de suspender servidores. Por exemplo, é possível suspender normalmente um servidor e, em seguida, aguardar o tempo em que houver a menor quantidade de tráfego (talvez pela manhã) para remover completamente o servidor da configuração.
É possível especificar os seguintes tipos de afinidade no comando dscontrol rule:
A afinidade de cookie ativo aplica-se apenas ao componente CBR.
O cookie passivo aplica-se ao método de encaminhamento cbr do componente CBR e do componente Dispatcher.
A afinidade de URI aplica-se ao método de encaminhamento cbr do componente CBR e do componente Dispatcher.
O padrão para a opção de afinidade é "nenhum". A opção tempo de permanência no comando port deve ser igual a zero (não ativado) para configurar a opção afinidade no comando rule para o cookie ativo, cookie passivo ou URI. Quando a afinidade é configurada na regra, não é possível ativar o tempo de permanência na porta.
O recurso de afinidade do cookie ativo aplica-se apenas ao componente CBR.
Ele fornece uma maneira de tornar os clientes “permanentes” para um determinado servidor. Essa função é ativada pela configuração do tempo de permanência de uma regra para um número positivo e pela configuração da afinidade como “activecookie.” Isso pode ser feito quando a regra é incluída ou com o uso do comando rule set. Consulte dscontrol rule — configure rules para obter informações detalhadas sobre a sintaxe de comando.
Quando uma regra é ativada para afinidade de cookie ativo, novas solicitações do cliente têm a carga balanceada usando algoritmos CBR padrão, enquanto que as solicitações sucessoras do mesmo cliente são enviadas para o servidor escolhido inicialmente. O servidor escolhido é armazenado como um cookie na resposta para o cliente. Contanto que as futuras solicitações do cliente contenham o cookie, e que cada solicitação chegue dentro do intervalo de tempo de permanência, o cliente manterá a afinidade com o servidor inicial.
A afinidade do cookie ativo é usada para garantir que um cliente continue tenho sua carga balanceada para o mesmo servidor por um certo período de tempo. Isso é feito por meio do envio de um cookie para ser armazenado pelo navegador dos clientes. O cookie contém cluster:port:rule que foi usado para tomar uma decisão, o servidor para o qual a carga foi balanceada e um registro de data e hora de tempo de espera para quando a afinidade não for mais válida. O cookie está no seguinte formato: IBMCBR=cluster:port:rule+server-time! As informações cluster:port:rule e de servidor são codificadas para que a configuração de CBR não seja revelada.
Quando é disparada uma regra que tem a afinidade de cookie ativo ativada, o cookie enviado pelo cliente é examinado.
Esse novo cookie é então inserido nos cabeçalhos que retornam ao cliente, e se o navegador do cliente for configurado para aceitar cookies, ele será enviado de volta para solicitações subsequentes.
Cada instância de afinidade no cookie tem 65 bytes de comprimento e termina no ponto de exclamação. Como resultado, um cookie de 4096 bytes pode conter aproximadamente 60 regras de cookie ativas individuais por domínio. Se o cookie for completamente preenchido, todas as instâncias de afinidade expiradas serão limpas. Se todas as instâncias ainda forem válidas, a mais antiga será eliminada e novas instâncias para a regra atual serão incluídas.
A opção de afinidade de cookie ativo, para o comando rule, só pode ser configurada como activecookie se o tempo de permanência da porta for zero (não ativado). Quando a afinidade do cookie ativo estiver ativa em uma regra, não será possível ativar o tempo de permanência na porta.
Para ativar a afinidade do cookie ativo para uma determinada regra, use o comando rule set:
rule set cluster:port:rule stickytime 60 rule set cluster:port:rule affinity activecookie
Transformar uma regra em permanente é uma configuração que normalmente seria usada para CGI ou servlets que armazenam o estado do cliente no servidor. O estado é identificado por um ID de cookie (eles são cookies de servidor). O estado do cliente só está no servidor selecionado, portanto, o cliente precisa do cookie desse servidor para manter esse estado entre as solicitações.
A afinidade do cookie ativo tem como expiração padrão o atual tempo do servidor, mais o intervalo de tempo de permanência, mais vinte e quatro horas. Se seus clientes (aqueles enviando solicitações para sua máquina CBR) tiverem horários imprecisos em seu sistema (por exemplo, se estiverem mais de um dia adiantados com relação ao horário do servidor), os sistemas desses clientes irão ignorar os cookies do CBR porque o sistema assumirá que os cookies já expiraram. Para configurar um prazo de expiração mais longo, modifique o script cbrserver. No arquivo de script, edite a linha javaw incluindo o seguinte parâmetro após LB_SERVER_KEYS: -DCOOKIEEXPIREINTERVAL=X, em que X é o número de dias para incluir no prazo de expiração.
Em sistemasAIX, Solaris e Linux, o arquivo cbrserver está localizado no diretório /usr/bin.
Em sistemas Windows, o arquivo cbrserver está localizado no diretório \winnt\system32.
A afinidade do cookie passivo se aplica ao método de encaminhamento content-based routing (cbr) do componente Dispatcher e componente CBR. Consulte roteamento baseado em conteúdo do Dispatcher (Método de Encaminhamento CBR) para obter informações sobre como configurar o método de encaminhamento cbr do Dispatcher.
A afinidade do cookie passivo fornece uma maneira de tornar os clientes permanentes para um determinado servidor. Quando você ativa a afinidade de uma regra como "passivecookie", a afinidade do cookie passivo permite fazer o balanceamento de carga para o tráfego da Web com afinidade para o mesmo servidor baseado nos cookies de autoidentificação gerados pelos servidores. Configure a afinidade do cookie passivo no nível da regra.
Quando a regra for disparada, se a afinidade do cookie passivo estiver ativada, o Balanceador de Carga escolherá o servidor com base no nome do cookie no cabeçalho HTTP da solicitação do cliente. O Balanceador de Carga começa a comparar o nome do cookie do cabeçalho HTTP do cliente com o valor do cookie configurado para cada servidor.
Na primeira vez que o Balanceador de Carga localiza um servidor cujo valor do cookie contém o nome do cookie do cliente, o Balanceador de Carga escolhe esse servidor para a solicitação.
Se o nome do cookie na solicitação do cliente não for localizado ou não corresponder a nenhum conteúdo nos valores de cookie do servidor, o servidor será escolhido usando a seleção de servidor existente ou a técnica round-robin ponderada.
Para configurar afinidade do cookie passivo:
A opção de afinidade do cookie passivo, para o comando rule, só pode ser configurada como passivecookie se o tempo de permanência da porta for zero (não ativado). Quando a afinidade do cookie passivo estiver ativa em uma regra, não será possível ativar o tempo de permanência na porta.
A afinidade do URI se aplica ao método de encaminhamento cbr do Dispatcher e o componente CBR. Consulte roteamento baseado em conteúdo do Dispatcher (Método de Encaminhamento CBR) para obter informações sobre como configurar o método de encaminhamento cbr.
A afinidade do URI permite fazer o balanceamento de carga do tráfego da Web para servidores Caching Proxy, que permitem que conteúdo exclusivo seja armazenado em cache em cada servidor individual. Como resultado, você irá aumentar efetivamente a capacidade do cache do site eliminando o armazenamento em cache redundante de conteúdo em diversas máquinas. Configure a afinidade de URI no nível da regra. Após a regra ser disparada, se a afinidade do URI estiver ativada e o mesmo conjunto de servidores estiver ativo e respondendo, o Balanceador de Carga encaminhará novas solicitações de cliente recebidas com o mesmo URI para o mesmo servidor.
Tipicamente, o Balanceador de Carga pode distribuir solicitações para diversos servidores que entregam conteúdo idêntico. Ao usar o Balanceador de Carga com um grupo de servidores de armazenamento em cache, o conteúdo acessado com frequência é eventualmente armazenado em cache em todos os servidores. Isso suporta um carregamento de cliente bastante alto, replicando conteúdo idêntico armazenado em cache em diversas máquinas. Isso é útil principalmente para Web sites de alto volume.
No entanto, se seu Web site suportar um volume moderado de tráfego de cliente para conteúdo bastante diferente, e você preferir ter um cache maior espalhado por diversos clientes, seu site teria um desempenho melhor se cada servidor de armazenamento em cache tivesse conteúdo exclusivo e o Balanceador de Carga distribuísse a solicitação apenas para o servidor de armazenamento em cache com esse conteúdo.
Com afinidade de URI, o Balanceador de Carga permite distribuir o conteúdo em cache para servidores individuais, eliminando o armazenamento em cache redundante de conteúdo em diversas máquinas. O desempenho para sites de servidor com conteúdo diferente usando servidores Caching Proxy foi melhorado com esse aprimoramento. Ele enviará solicitações idênticas para o mesmo servidor, armazenando assim o conteúdo em cache apenas em servidores únicos. E o tamanho efetivo do cache ficará maior com cada nova máquina servidor incluída no conjunto.
Para configurar afinidade de URI:
A opção de afinidade de URI, para o comando rule, só pode ser configurada como URI se o tempo de permanência da porta for zero (não ativado). Quando a afinidade de URI está ativa em uma regra, não é possível ativar o tempo de permanência na porta.
Esse recurso está disponível apenas para o componente Dispatcher.
Se você não estiver usando o suporte à longa distância do Dispatcher e não estiver usando o método de encaminhamento nat do Dispatcher, uma configuração do Dispatcher exigirá que a máquina do Dispatcher e seus servidores estejam todos conectados ao mesmo segmento de LAN (consulte Figura 32). A solicitação de um cliente chega à máquina do Dispatcher e é enviada para o servidor. Do servidor, a resposta é enviada diretamente de volta para o cliente.
O recurso do Dispatcher de longa distância inclui suporte para servidores externos, conhecidos como servidores remotos (consulte Figura 33). Se GRE não for suportado no site remoto e o método de encaminhamento nat do Dispatcher não estiver sendo usado, o site remoto deverá consistir em uma máquina remota do Dispatcher (Dispatcher 2) e estar localmente conectada aos servidores (ServerG, ServerH e ServerI). O pacote de um cliente irá da Internet à máquina inicial do Dispatcher. Da máquina inicial do Dispatcher, o pacote irá a uma máquina do Dispatcher geograficamente remota e a um de seus servidores localmente conectados.
Todas as máquinas do Dispatcher (locais e remotas) devem ter o mesmo tipo de sistema operacional e plataforma para executar configurações de longa distância.
Isso permite que um endereço de cluster suporte todas as solicitações de cliente mundialmente enquanto distribui a carga para servidores em todo o mundo.
A máquina do Dispatcher recebendo o pacote inicialmente ainda pode ter servidores locais conectados a ela, e pode distribuir a carga entre seus servidores locais e servidores remotos.
Para configurar o suporte à longa distância:
dscontrol server add cluster:port:server router address
Para obter mais informações sobre a palavra-chave roteador, consulte dscontrol server — configurar servidores.
Em Dispatchers de ponto de entrada:
Um dispatcher de ponto de entrada tratará o Dispatcher de segundo nível como um servidor, e ele irá monitorar o funcionamento dele com um servidor e unirá os resultados ao IP real do dispatcher.
Em Dispatchers remotos: Execute as seguintes etapas de configuração para cada endereço de cluster remoto. Para uma configuração de alta disponibilidade no local do Dispatcher remoto, você deve executar essas etapas em ambas as máquinas.
Sistemas AIX
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
Sistemas HP-UX, Linux, Solaris e sistemas Windows
Este exemplo se aplica à configuração ilustrada em Figura 34.
Veja aqui como configurar as máquinas do Dispatcher para suportar o endereço do cluster xebec na porta 80. LB1 é definido como o Load Balancer de "ponto de entrada". Uma conexão de Ethernet é assumida. Observe que o LB1 tem cinco servidores definidos: três locais (ServerA, ServerB, ServerC) e dois remotos (LB2 e LB3). Cada LB2 e LB3 remoto tem três servidores locais definidos.
No console do primeiro Dispatcher (LB1), faça o seguinte:
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
No console do segundo Dispatcher (LB2):
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
No console do terceiro Dispatcher (LB3):
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
Generic Routing Encapsulation (GRE) é um protocolo da Internet especificado em RFC 1701 e RFC 1702. Usando GRE, o Balanceador de Carga pode encapsular pacotes IP do cliente em pacotes IP/GRE e encaminhá-los para plataformas do servidor como OS/390 que suportem GRE. O suporte a GRE permite que o componente Dispatcher faça o balanceamento de carga dos pacotes para diversos endereços do servidor associados a um endereço MAC.
Balanceador de Carga implementa GRE como parte de seu recurso WAN. Isso permite que o Balanceador de Carga forneça balanceamento de carga de longa distância diretamente para quaisquer sistemas de servidor que possam descompactar pacotes GRE. O Balanceador de Carga não precisa estar instalado no site remoto se os servidores remotos suportarem os pacotes GRE encapsulados. O Balanceador de Carga encapsula pacotes WAN com o campo-chave GRE configurado para o valor decimal 3735928559.
Para esse exemplo (Figura 35), para incluir o ServerD remoto, que suporta GRE, defina-o na configuração do Balanceador de Carga como se você estivesse definindo um servidor WAN na hierarquia cluster:porta:servidor:
dscontrol server add cluster:port:ServerD router Router1
Sistemas Linux têm a capacidade nativa de encapsular GRE, que permite que o Balanceador de Carga faça o balanceamento de carga para imagens do servidor Linux para S/390, onde várias imagens do servidor compartilham um endereço MAC. Isso permite que o Balanceador de Carga de ponto de entrada faça o balanceamento de carga diretamente para os servidores WAN do Linux sem passar por um Balanceador de Carga no site remoto. Isso também permite que orientadores do Balanceador de Carga de ponto de entrada operem diretamente com cada servidor remoto.
No Balanceador de Carga de ponto de entrada, configure conforme descrito para WAN.
Para configurar cada servidor de backendLinux, emita os seguintes comando como raiz. (Esses comandos podem ser incluídos no recurso de inicialização do sistema para que as mudanças sejam preservadas nas reinicializações.)
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add cluster address dev gre-nd
Em geral, as funções de balanceamento de carga do Dispatcher funcionam independentemente do conteúdo dos sites nos quais o produto é usado. No entanto, há uma área na qual o conteúdo do site pode ser importante, e na qual as decisões tomadas em relação ao conteúdo podem ter um impacto significativo na eficiência do Dispatcher. Isto está na área de endereçamento de link.
Se as páginas especificarem links que apontam para servidores individuais para o seu site, você estará forçando efetivamente que um cliente acesse uma máquina específica, ignorando assim qualquer função de balanceamento de carga que, de outra forma, poderá estar em vigor. Por esta razão, use sempre o endereço do Dispatcher nos links contidos em suas páginas. Observe que o tipo de endereçamento usado poderá não estar sempre aparente, se o seu site usar programação automática que cria HTML dinamicamente. Para maximizar sua balanceamento de carga, você deverá estar ciente de qualquer endereçamento explícito e evitá-lo onde possível.
É possível configurar as máquinas servidores Dispatcher e TCP usando uma rede privada. Esta configuração pode reduzir a contenção na rede pública ou externa que pode afetar o desempenho.
Para sistemas AIX, essa configuração também pode se aproveitar das velocidades rápidas do SP High Performance Switch, se você estiver executando as máquinas do Dispatcher e do servidor TCP nos nós em um SP Frame.
Para criar uma rede privada, cada máquina deve ter pelo menos duas placas de LAN, com uma das placas conectadas à rede privada. Você deve configurar também a segunda placa de LAN em uma sub-rede diferente. Em seguida, a máquina do Dispatcher enviará os pedidos do cliente para as máquinas do servidor TCP por meio da rede privada.
Sistemas Windows: Configure o nonforwarding address usando o comando executor configure.
Os servidores incluídos que usam o comando dscontrol server add devem ser incluídos usando os endereços da rede privada; por exemplo, relativo ao exemplo do servidor Maçã em Figura 36, o comando deverá ser codificado como:
dscontrol server add cluster_address:80:10.0.0.1
not
dscontrol server add cluster_address:80:9.67.131.18
Se estiver usando Site Selector para fornecer informações de carregamento para o Dispatcher, você deverá configurar o Site Selector para relatar os carregamentos nos endereços privados.
O uso de uma configuração de rede privada se aplica apenas ao componente Dispatcher.
O uso de cluster curinga para combinar configurações do servidor se aplica apenas ao componente Dispatcher.
O “curinga” se refere à habilidade do cluster de corresponder vários endereços IP (isto é, age como um curinga). O endereço do cluster 0.0.0.0 é usado para especificar um cluster curinga.
Se você tiver muitos endereços de cluster para balanceamento de carga, e as configurações da porta/servidor forem idênticas para todos os clusters, você poderá combinar todos os clusters em uma configuração de cluster curinga.
É necessário ainda configurar explicitamente cada endereço de cluster em um dos adaptadores de rede da estação de trabalho do Dispatcher. Você não deverá incluir nenhum dos endereços de cluster na configuração do Dispatcher que usa no entanto, o comando dscontrol cluster add.
Inclua apenas o cluster curinga (endereço 0.0.0.0), e configure as portas e servidores, conforme necessário para o balanceamento de carga. Qualquer tráfego para qualquer um dos endereços configurados pelo adaptador tem a carga balanceada usando a configuração do cluster curinga.
Uma vantagem dessa abordagem é que o tráfego para todos os endereços de cluster é levado em conta ao determinar o melhor servidor a ser acessado. Se um cluster estiver obtendo bastante tráfego, e tiver criado muitas conexões ativas em um dos servidores, o tráfego para outros endereços de cluster terá a carga balanceada usando estas informações.
Você poderá combinar o cluster curinga com os clusters reais, se tiver alguns endereços de cluster com configurações exclusivas da porta/servidor, e alguns com configurações comuns. Cada uma das configurações exclusivas deve ser designada para um endereço de cluster real. Todas as configurações comuns podem ser designadas para o cluster curinga.
O uso de cluster curinga para balanceamento de carga de firewalls se aplica apenas ao componente Dispatcher. O endereço do cluster 0.0.0.0 é usado para especificar um cluster curinga.
O cluster curinga pode ser usado para balanceamento de carga do tráfego para endereços que não estão configurados explicitamente em nenhum adaptador de rede da estação de trabalho do Dispatcher. Para que isso funcione, o Dispatcher deve pelo menos poder ver todo o tráfego destinado ao balanceamento de carga. A estação de trabalho do dispatcher não verá o tráfego para endereços que não foram configurados explicitamente em um de seus adaptadores de rede, a não ser que ele esteja configurado como a rota padrão para algum conjunto de tráfegos.
Após o Dispatcher ter sido configurado como uma rota padrão, qualquer tráfego TCP ou UDP por meio da máquina do Dispatcher terá sua carga balanceada com o uso da configuração de cluster curinga.
Um aplicativo disto é para o balanceamento de carga de firewalls. Como os firewalls podem processar pacotes para qualquer endereço e porta de destino, será necessário estar apto para balancear a carga do tráfego, independente do endereço e da porta de destino.
Firewalls são usados para tratar do tráfego de clientes não seguros para servidores seguros, respostas de servidores seguros, bem como tráfego dos clientes no lado seguro para os servidores no lado não seguro e as respostas.
Você deve configurar duas máquinas do Dispatcher, uma para o balanceamento de carga de tráfego não seguro para endereços de firewall não seguros e uma para o balanceamento de carga de tráfego seguro para endereços de firewall seguros. Como esses dois Dispatchers devem usar o cluster curinga e a porta curinga com diferentes conjuntos de endereços de servidor, os dois Dispatchers deve estar em duas estações de trabalho separadas.
O uso de cluster curinga com Caching Proxy para proxy transparente aplica-se apenas ao componente Dispatcher. O endereço do cluster 0.0.0.0 é usado para especificar um cluster curinga.
A função do cluster curinga também permite que o Dispatcher seja usado para ativar uma função de proxy transparente para um servidor Caching Proxy residindo na mesma máquina que o Dispatcher. Isso é apenas um recurso do AIX, já que deve javer comunicação do componente Dispatcher com o componente TCP do sistema operacional.
Para ativar esse recurso, você deve iniciar o Caching Proxy atendendo às solicitações do cliente na porta 80. Em seguida, configure um cluster curinga (0.0.0.0). No cluster curinga, configure a porta 80. Na porta 80, configure o NFA da máquina do Dispatcher como o único servidor. Agora qualquer tráfego do cliente para qualquer endereço na porta 80 será entregue para o servidor Caching Proxy em execução na estação de trabalho do Dispatcher. A solicitação do cliente vai estar em proxy como de costume e a resposta será enviada de volta do Caching Proxy para o cliente. Nesse modo, o componente Dispatcher não está executando nenhum balanceamento de carga.
A porta curinga pode ser usada para manipular o tráfego que não se destina a nenhuma porta configurada explicitamente. Um uso disto destina-se ao balanceamento de carga de firewalls. Um segundo uso é garantir que o tráfego para uma porta não configurada seja manipulado apropriadamente. Definindo uma porta curinga sem nenhum servidor, você garantirá que qualquer pedido para uma porta que não tenha sido configurada seja descartado, em vez de entregue de volta ao sistema operacional. A porta número 0 (zero) é usada para especificar uma porta curinga, por exemplo:
dscontrol port add cluster:0
Ao configurar um cluster para manipular FTP passivo e a porta curinga, por padrão, o FTP passivo utilizará o intervalo inteiro da porta TCP não privilegiada para conexões de dados. Isso significa que um cliente, com uma conexão existente por meio de um cluster com balanceamento de carga com uma porta de controle de FTP, terá conexões de controle subsequente e conexões de porta superior (porta >1023) com o mesmo cluster roteado automaticamente pelo Balanceador de Carga e com o mesmo servidor que o da conexão de controle de FTP.
Se a porta curinga e a porta FTP no mesmo cluster não tiverem o mesmo servidor configurado, os aplicativos de porta superior (porta >1023) poderão falhar quando um cliente tiver uma conexão de controle de FTP existente. Portanto, a configuração de conjuntos de servidores diferentes para portas FTP e curinga no mesmo cluster não é recomendada. Se este cenário for desejado, o intervalo da porta passiva do daemon de FTP deverá ser configurado na configuração do Balanceador de Carga.
Esse recurso está disponível apenas para o componente Dispatcher.
O Dispatcher fornece a habilidade de detectar ataques potenciais de "negação de serviço" e notificar os administradores por um alerta. O Dispatcher faz isso analisando pedidos recebidos para uma quantidade exagerada de conexões TCP abertas pela metade em servidores, uma qualidade em comum de negação simples de ataques de serviço. Em uma negação de ataque de serviço, um site recebe uma grande quantidade de pacotes SYN fabricados de um grande número de endereços IP de origem e números de portas de origem, mas o site não recebe nenhum pacote subsequente para aquelas conexões TCP. Isso resulta em um grande número de conexões TCP abertas pela metade nos servidores e, ao longo do tempo, os servidores podem se tornar muito lentos, não aceitando nenhuma conexão nova recebida.
O Balanceador de Carga fornece saídas de usuário que acionam scripts que podem ser customizados e que alertam o Administrador para uma possível negação de ataque de serviço. O Dispatcher fornece arquivos de script de amostra no seguinte diretório:
Os seguintes scripts estão disponíveis:
Para executar os arquivos, você deve movê-los para o seguinte diretório e remover a extensão de arquivo ".sample":
Para implementar a detecção de ataque de DoS, configure o parâmetro maxhalfopen no comando dscontrol port da seguinte maneira:
dscontrol port set 127.40.56.1:80 maxhalfopen 1000
No exemplo anterior, o Dispatcher comparará o número total atual de conexões abertas pela metade (para todos os servidores que residem no cluster 127.40.56.1 na porta 80) com o valor do limite de 1000 (especificado pelo parâmetro maxhalfopen). Se as conexões atuais abertas pela metade excederem o limite, em seguida, será feita uma chamada para um script de alerta (halfOpenAlert). Quando o número de conexões abertas pela metade cair abaixo do limite, será feita uma chamada para outro script de alerta (halfOpenAlertDone) para indicar que o ataque está terminado.
Para determinar como configurar o valor maxhalfopen:Execute periodicamente (talvez a cada 10 minutos) um relatório de conexão meio aberto (dscontrol port halfopenaddressreport cluster:port) quando seu site estiver enfrentando um tráfego de normal a pesado. O relatório da conexão aberta pela metade retornará as "conexões totais recebidas abertas pela metade" atuais. Você deve configurar maxhalfopen como um valor que esteja entre 50 a 200% superior ao maior número de conexões abertas pela metade, que o seu site experimenta.
Além dos dados estatísticos relatados, o halfopenaddressreport também gerará entradas no log (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) para todos os endereços de clientes (até aproximadamente 8000 pares de endereço) que acessaram servidores que resultaram em conexões abertas pela metade.
Para fornecer proteção adicional contra ataques de negação de serviço para servidores backend, é possível configurar portas e clusters curinga. Especificamente, em cada cluster configurado, inclua uma porta curinga sem nenhum servidor. Inclua também um cluster curinga com uma porta curinga e nenhum servidor. Isto terá o efeito de descarte de todos os pacotes que não estão endereçados para um cluster e porta não curinga. Para obter informações sobre clusters e portas curinga, consulte Usar Cluster Curinga para Combinar Configurações do Servidor e Usar Porta Curinga para Direcionar Tráfego de Porta Não Configurada.
O recurso de criação de log binário permite que as informações do servidor sejam armazenadas em arquivos binários. Esses arquivos podem ser processados para analisar as informações do servidor que foram reunidas ao longo do tempo.
As seguintes informações são armazenadas no log binário para cada servidor definido na configuração.
Algumas dessas informações são recuperadas do executor como parte do ciclo do gerenciador. Portanto, o gerenciador deve estar em execução para que as informações sejam registradas nos logs binários.
Use o conjunto de comandos dscontrol binlog para configurar a criação de log binário.
A opção Iniciar inicia as informações do servidor de criação de log para logs binários no diretório de logs. Um log é criado no início de cada hora com a data e hora conforme o nome do arquivo.
A opção Parar para as informações do servidor de criação de log para os logs binários. Por padrão, o serviço de log é interrompido.
A opção Configurar Intervalo controla a frequência com que as informações são gravadas nos logs. O gerenciador enviará informações do servidor para o servidor de log a cada intervalo do gerenciador. As informações são gravadas nos logs apenas se os segundos do intervalo de log especificado tiverem decorridos desde quando o último registro foi gravado no log. Por padrão, o intervalo de log é configurado como 60 segundos. Há alguma interação entre as configurações do intervalo do gerenciador e do intervalo de log. Visto que o servidor de log é fornecido com informações não mais rápidas do que os segundos do intervalo do gerenciador, configurar o intervalo do log como menor do que o intervalo do gerenciador, configura-o como o mesmo intervalo do gerenciador. Essa técnica de criação de log permite capturar informações do servidor em qualquer granularidade. É possível capturar todas as mudanças nas informações do servidor que são vistas pelo gerenciador para cálculo dos pesos de servidores. No entanto, essa quantidade de informações, provavelmente não é necessária para analisar o uso e tendências do servidor. Criar o log de informações do servidor a cada 60 segundos fornece capturas instantâneas de informações do servidor ao longo do tempo. Configurar o intervalo de log muito baixo pode gerar altas quantias de dados.
A opção Configurar Retenção controla quanto tempo os arquivos de log são mantidos. Os arquivos de log, mais antigos do que as horas de retenção especificadas, são excluídos pelo servidor de log. Isso apenas ocorrerá, se o servidor de log estiver sendo chamado pelo gerenciador, portanto, parar o gerenciador fará com que os arquivos de log antigos não sejam excluídos.
A opção Status retorna as configurações atuais do serviço de log. Essas configurações ocorrerão se o serviço for iniciado, qual será o intervalo e quais serão as horas de retenção.
Um programa Java de amostra e um arquivo de comando foram fornecidos no seguinte diretório:
Essa amostra mostra como recuperar todas as informações a partir dos arquivos de log e imprimí-las na tela. Ela pode ser customizada para efetuar qualquer tipo de análise que desejar com os dados. Um exemplo de como usar o script e o programa fornecidos para o dispatcher será:
dslogreport 2001/05/01 8:00 2001/05/01 17:00
obter um relatório das informações do servidor do componente Dispatcher de 8h a 17h em 1º de maio de 2001. (Para CBR, use cbrlogreport.)
Apenas os sistemas Linux suportam configurações nas quais o cliente está localizado na mesma máquina que o Balanceador de Carga.
As configurações do cliente instalado poderão não funcionar corretamente em outras plataformas, porque o Balanceador de Carga usa técnicas diferentes para examinar os pacotes recebidos nos vários sistemas operacionais que ele suporta. Na maioria dos casos, nos sistemas diferentes do Linux, o Balanceador de Carga não recebe pacotes da máquina local. Ele recebe pacotes provenientes apenas da rede. Por causa disso, os pedidos feitos no endereço do cluster da máquina local não são recebidos pelo Balanceador de Carga e não podem ser atendidos.