Planejando para Dispatcher

Esta capítulo descreve o que o planejador de rede deve considerar antes de instalar e configurar o componente Dispatcher.

Este capítulo inclui as seguintes seções:

Nota:
Para as versões anteriores, quando o produto era conhecido como Network Dispatcher, o nome do comando de controle do Dispatcher era ndcontrol. O nome do comando de controle do Dispatcher é agora dscontrol.

Considerações de Planejamento

O Dispatcher consiste nas seguintes funções:

As três funções da chave do Dispatcher (executor, gerenciador e orientadores) interagem para equilibrar e despachar os pedidos recebidos entre servidores. Juntamente com pedidos de balanceamento de carga, o executor monitora o número de novas conexões, conexões ativas e conexões em um estado concluído. O executor também faz a coleta de lixo de conexões de reconfiguração ou concluídas e fornece essas informações ao gerenciador.

O gerenciador coleta informações do executor, dos orientadores e de um programa de monitoramento de sistema, como o Metric Server. Com base nas informações que o gerenciador recebe, ele ajusta o modo com que as máquinas servidores são ponderadas em cada porta e fornece ao executor o novo peso para uso em seu balanceamento de novas conexões.

Os orientadores monitoram cada servidor na porta designada para determinar o tempo de resposta e a disponibilidade do servidor e, em seguida, fornece essas informações ao gerenciador. Os orientadores também monitoram se um servidor está ativo ou inativo. Sem o gerenciador e os orientadores, o executor faz o planejamento round-robin com base nos pesos do servidor atual.

Métodos de Encaminhamento

Com o Dispatcher, é possível selecionar um dos três métodos de encaminhamento especificados no nível da porta: encaminhamento MAC, encaminhamento NAT/NAPT ou encaminhamento CBR (Content-based Routing).

Roteamento em Nível MAC do Dispatcher (Método de Encaminhamento MAC)

Usando o método de encaminhamento de MAC do Dispatcher (o método de encaminhamento padrão), o Dispatcher faz o balanceamento de carga de pedidos recebidos para o servidor selecionado e o servidor retorna a resposta diretamente ao cliente sem nenhum envolvimento do Dispatcher. Com o método de encaminhamento, o Dispatcher apenas examina os fluxos de entrada cliente para servidor. Ele não precisa ver os fluxos de saída de servidor para cliente. Isto reduz significativamente seu impacto no aplicativo, e pode resultar no desempenho de rede melhorado.

O método de encaminhamento pode ser selecionado durante a inclusão de uma porta usando o comando dscontrol port add cluster:port method value. O valor do método de encaminhamento é mac. É possível especificar o parâmetro do método apenas quando a porta estiver incluída. Ao incluir a porta, você não pode alterar a configuração do método de encaminhamento. Consulte dscontrol port — configurar portas para obter informações adicionais.

Limitação do Linux: os sistemas Linux implementam um modelo baseado no host de endereços de hardware de propaganda para os endereços IP que usam ARP. Esse modelo é incompatível com os requisitos do servidor de back-end ou o servidor de disposição de alta disponibilidade para o método de encaminhamento Mac do Balanceador de Carga. Consulte Alternativas de Criação de Alias de Loopback do Linux ao Usar Encaminhamento mac do Load Balancer, que descreve inúmeras soluções para se alterar o comportamento do sistema Linux para torná-lo compatível com o encaminhamento mac do Load Balancer.

Limitação do Linux ao usar servidores zSeries ou S/390: existem limitações ao usar servidores zSeries ou S/390 que possuem placas Open System Adapter (OSA). Consulte Problema: No Linux, Limitações de Configuração do Dispatcher ao Usar Servidores zSeries ou S/390 que Têm Placas Open System Adapter (OSA), para obter soluções alternativas possíveis.

NAT/NAPT do Dispatcher (Método de Encaminhamento NAT)

O uso do recurso Network Address Translation (NAT) ou Network Address Port Translation (NAPT) do Dispatcher remove a limitação para servidores com carga balanceada se localizarem em uma rede conectada localmente. Quando você quiser ter servidores em locais remotos, é possível usar a técnica do método de encaminhamento NAT em vez de usar uma técnica de encapsulação GRE/WAN. Também é possível usar o recurso NAPT para acessar diversos daemons de servidor que residem em cada máquina servidor com carga balanceada, em que cada daemon atende em uma porta exclusiva.

É possível configurar um servidor com diversos daemons de duas maneiras diferentes:

Esse aplicativo trabalha bem com protocolos de aplicativo de nível superior, como HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, entre outros.

Limitações:

Você precisará de três endereços IP para a máquina do Dispatcher – nfa, cluster e endereço de retorno. Para implementar NAT/NAPT, faça o seguinte (consulte também Etapas de Amostra para Configurar os Métodos de Encaminhamento NAT ou CBR do Dispatcher):

roteamento baseado em conteúdo do Dispatcher (Método de Encaminhamento CBR)

O componente Dispatcher permite executar roteamento baseado em conteúdo para HTTP (usando a regra de tipo de "conteúdo") e HTTPS (usando afinidade de ID de sessão SSL) sem ter que usar Caching Proxy. Para tráfego HTTP e HTTPS, o método de encaminhamento cbr do componente Dispatcher pode fornecer um roteamento baseado em conteúdo mais rápido que o componente CBR, que requer Caching Proxy.

Para HTTP: A seleção de servidor para roteamento baseado em conteúdo do Dispatcher é baseada no conteúdo de uma URL ou de um cabeçalho HTTP. Isso é configurado usando a regra de tipo de "conteúdo". Quando configurar a regra de conteúdo, especifique o "padrão" de sequência de procura e um conjunto de servidores para a regra. Ao processar uma nova solicitação recebida, a regra compara a sequência especificada com a URL do cliente ou com o cabeçalho HTTP especificado na solicitação do cliente.

Se o Dispatcher localizar a sequência na solicitação do cliente, ele encaminhará a solicitação para um dos servidores na regra. O Dispatcher então retransmite os dados de resposta do servidor para o cliente (método de encaminhamento "cbr").

Se o Dispatcher não localizar a sequência na solicitação do cliente, ele não seleciona um servidor do conjunto de servidores na regra.

Nota:
A regra de conteúdo é configurada no componente Dispatcher da mesma maneira que é configurada no componente CBR. O Dispatcher pode usar a regra de conteúdo para tráfego HTTP. No entanto, o componente CBR pode usar a regra de conteúdo para ambos os tráfegos HTTP e HTTPS (SSL).

Para HTTPS (SSL): O roteamento baseado em conteúdo do Dispatcher faz o balanceamento de carga com base no campo ID de Sessão SSL da solicitação do cliente. Com SSL, uma solicitação do cliente contém o ID de sessão SSL de uma sessão anterior e os servidores mantêm um cache de suas conexões SSL anteriores. A afinidade de sessão de ID SSL do Dispatcher permite que cliente e servidor estabeleçam uma nova conexão usando os parâmetros de segurança da conexão anterior com o servidor. Ao eliminar a renegociação dos parâmetros de segurança SSL, como chaves compartilhadas e algoritmos de criptografia, os servidores economizam loops de CPU e o cliente recebe uma resposta mais rápida.Para ativar a afinidade de ID de sessão SSL: o tipo de protocolo especificado para a porta deve ser SSL e o tempo de permanência da porta deve ser configurado para um valor diferente de zero. Quando o tempo de permanência for excedido, o cliente poderá ser enviado para um servidor diferente do anterior.

Você precisará de três endereços IP para a máquina do Dispatcher – nfa, cluster e endereço de retorno. Para implementar roteamento baseado em conteúdo do Dispatcher (consulte também Etapas de Amostra para Configurar os Métodos de Encaminhamento NAT ou CBR do Dispatcher):

Nota:
O recurso de replicação de registro de conexão de alta disponibilidade (que garante que uma conexão do cliente não é descartada quando uma máquina do Dispatcher de backup assume o controle da máquina principal) não é suportado com roteamento baseado em conteúdo do Dispatcher.

Etapas de Amostra para Configurar os Métodos de Encaminhamento NAT ou CBR do Dispatcher

Figura 12. Exemplo de Uso dos Métodos de Encaminhamento NAT ou CBR do Dispatcher
Configuração para Uso de Encaminhamento NAT ou CBR do Dispatcher

Você precisará de pelo menos três endereços IP para a máquina do Dispatcher. Para Figura 12, as ações a seguir são as etapas necessárias para você configurar minimamente os métodos de encaminhamento nat ou cbr do Dispatcher:

1.Inicie o executor
  dscontrol executor start

2.Defina o gateway do cliente
  dscontrol executor set clientgateway 1.2.3.5
  NOTA: Se sua sub-rede não tiver um roteador local, você deverá
        configurar uma máquina para fazer o encaminhamento de IP e usá-la como
        clientgateway. Consulte a documentação do sistema operacional 
        para determinar como ativar o encaminhamento de IP.

3.Defina o endereço do cluster
  dscontrol cluster add 1.2.3.44

4.Configure o endereço do cluster
  dscontrol executor configure 1.2.3.44

5.Defina a porta com um método nat ou cbr
  dscontrol port add 1.2.3.44:80 method nat
  ou
  dscontrol port add 1.2.3.44:80 method cbr protocol http

6.Configure um endereço de retorno do alias no Balanceador de Carga (usando a placa de Ethernet 0)
  NOTA: Em sistemas Linux, não é necessário criar um alias para o endereço de retorno se você estiver usando
  encaminhamento nat na máquina instalada.

  dscontrol executor configure 10.10.10.99

  ou use o comando ifconfig (apenas para Linux ou UNIX):
  AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0
  HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up
  Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up
  Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up

7.Defina servidores backend
  dscontrol server add 1.2.3.4:80:192.10.10.10
    router 10.10.10.6 returnaddress 10.10.10.99 

O gateway do cliente (1.2.3.5) é o endereço do roteador 1 entre Balanceador de Carga e o cliente. O roteador (10.10.10.6) é o endereço do roteador 2 entre Balanceador de Carga e o servidor backend. Se você não estiver certo quanto ao clientgateway ou ao endereço do roteador 2, é possível usar um programa de rastreio de rotas com o endereço do cliente (ou servidor) para determinar o endereço do roteador. A sintaxe exata desse programa será diferente com base no sistema operacional que você está usando. Você deve consultar a documentação do sistema operacional para obter mais informações sobre esse problema.

Se o servidor estiver na mesma sub-rede que o Balanceador de Carga (ou seja, se nenhum roteador for retornado usando rastreio de rotas) insira o endereço do servidor como o endereço do roteador. No entanto, se o servidor estiver localizado na mesma máquina que o Load Balancer, o endereço do roteador deverá ser inserido no campo do roteador em vez de no endereço do servidor. O endereço do roteador é aquele usado no comando "server add" na máquina do Balanceador de Carga na etapa 7.

Particionamento do Servidor: Servidores Lógicos Configurados como um Servidor Físico (endereço IP)

Com o particionamento do servidor, é possível distinguir ainda mais entre URLs determinadas e seus aplicativos específicos. Por exemplo, um servidor da Web pode servir páginas JSP, páginas HTML, arquivos GIF, pedidos de banco de dados e assim por diante. O Balanceador de Carga fornece agora a habilidade de fazer a partição de um servidor específico ao cluster e à porta em vários servidores lógicos. Isso permite que você seja avisado sobre um serviço específico na máquina, para detectar se um mecanismo do servlet ou um pedido do banco de dados está sendo executado mais rápido ou não está sendo executado de nenhum modo.

O particionamento do servidor permite que o Balanceador de Carga detecte, por exemplo, que o serviço de HTML está servindo as páginas rapidamente, mas a conexão com o banco de dados foi desfeita. Isso permite que você distribua a carga com base na carga de trabalho específica ao serviço mais granular, em vez do peso em todo o servidor sozinho.

Particionamento do Servidor Usando Orientadores HTTP ou HTTPS

O particionamento do servidor pode ser útil quando usado em conjunto com os orientadores HTTP e HTTPS. Por exemplo, quando você tiver um servidor HTML que manipula páginas HTML, GIF e JSP, se você definir (incluindo) o servidor uma vez na porta 80, receberá apenas um valor da carga para todo o servidor HTTP. Isso poderá ser falso, porque é possível que o serviço GIF talvez não funcione no servidor. O Dispatcher ainda encaminha páginas GIF para o servidor, mas o cliente vê um tempo limite ou uma falha.

Se você definir o servidor três vezes (por exemplo, ServerHTML, ServerGIF, ServerJSP) na porta e definir o parâmetro advisorrequest do servidor com uma cadeia diferente para cada servidor lógico, em seguida, poderá consultar o funcionamento do serviço específico no servidor. ServerHTML, ServerGIF e ServerJSP representam três servidores lógicos que foram particionados de um servidor físico. Para ServerJSP, é possível definir a cadeia advisorrequest para consultar o serviço na máquina que manipula páginas JSP. Para ServerGIF, é possível definir a cadeia advisorrequest para consultar o serviço GIF. E para ServerHTML, você define o advisorrequest para consultar o serviço HTML. Portanto, se o cliente não obtiver resposta do advisorrequest para consultar o serviço GIF, o Dispatcher marcará esse servidor lógico (ServerGIF) como inativo, enquanto os dois outros servidores lógicos poderão estar em funcionamento. O Dispatcher não encaminha mais GIFs para o servidor físico, mas ele ainda pode enviar pedidos de JSP e HTML para o servidor.

Para obter informações adicionais sobre o parâmetro advisorrequest, consulte Configurando o Orientador HTTP ou HTTPS Usando a Opção de Pedido e Resposta (URL).

Exemplo de Configuração de um Servidor Físico em Servidores Lógicos

Na configuração do Dispatcher, é possível representar um servidor físico ou um servidor lógico usando a hierarquia cluster:port:server. O servidor pode ser um endereço IP exclusivo da máquina (servidor físico) em um nome simbólico ou no formato de endereço IP. Ou, se você definir o servidor para representar um servidor particionado, deverá fornecer um endereço do servidor que pode ser resolvido para o servidor físico no parâmetro address do comando dscontrol server add. Consulte dscontrol server — configurar servidores para obter informações adicionais.

A seguir está um exemplo de particionamento de servidores físicos em servidores lógicos para manipular diferentes tipos de pedidos.

Cluster: 1.1.1.1
        Port:  80
             Server: A (IP address 1.1.1.2)
                       HTML server
             Server: B (IP address 1.1.1.2)
                       GIF server
             Server: C (IP address 1.1.1.3)
                       HTML server
             Server: D (IP address 1.1.1.3)
                       JSP server
             Server: E (IP address 1.1.1.4)
                       GIF server
             Server: F (IP address 1.1.1.4)
                       JSP server
        Rule1: /*.htm
             Server: A
             Server: C
        Rule2: /*.jsp
             Server: D
             Server: F
        Rule3: /*.gif
             Server: B
             Server: E                

Neste exemplo, o servidor 1.1.1.2 é particionado em 2 servidores lógicos: "A" (manipulando pedidos de HTML) e "B" (manipulando pedidos de GIF). O servidor 1.1.1.3 é particionado em 2 servidores lógicos: "C" (manipulando pedidos de HTML) e "D" (manipulando pedidos de JSP). O servidor 1.1.1.4 é particionado em 2 servidores lógicos: "E" (manipulando pedidos de GIF) e "F" (manipulando pedidos de JSP).

Alta Disponibilidade

Alta Disponibilidade Simples

Figura 13. Exemplo de um Dispatcher que usa alta disponibilidade simples
Dispatcher que usa configuração de alta disponibilidade simples

O recurso de alta disponibilidade envolve o uso de uma segunda máquina do Dispatcher. A primeira máquina do Dispatcher executa o balanceamento de carga para todo o tráfego do cliente, como ela faz em uma configuração única do Dispatcher. A segunda máquina do Dispatcher monitora o “funcionamento" da primeira, e tomará o controle sobre a tarefa de balanceamento de carga, se detectar que a primeira máquina do Dispatcher falhou.

Para cada uma das duas máquinas, principal ou de backup, é designada uma função específica. A máquina principal envia dados de conexão para a máquina de backup continuamente. Enquanto a principal estiver ativa (balanceamento de carga), a de backup estará em um estado de espera, continuamente atualizada e pronta para tomar o controle, se necessário.

As sessões de comunicação entre as duas máquinas são referidas como pulsações. As pulsações permitem que cada máquina monitore o funcionamento da outra.

Se a máquina de backup detectar que a máquina ativa falhou, ela será retomada e iniciará o balanceamento de carga. Nesse momento, os status das duas máquinas são revertidos: a máquina de backup se torna ativa e a principal se torna em espera.

Na configuração de alta disponibilidade, as máquinas principal e de backup devem estar na mesma sub-rede com configuração idêntica.

Para obter informações sobre como configurar a alta disponibilidade, consulte Alta Disponibilidade.

Alta disponibilidade mútua

Figura 14. Exemplo de um Dispatcher Usando Alta Disponibilidade Mútua
Dispatcher Usando Configuração de Alta Disponibilidade Mútua

O recurso de alta disponibilidade mútua envolve o uso de duas máquinas do Dispatcher. Ambas as máquinas executam ativamente o balanceamento de carga do tráfego do cliente, e ambas fornecem backup uma para a outra. Em uma configuração de alta disponibilidade simples, apenas uma máquina executa o balanceamento de carga. Em uma configuração de alta disponibilidade mútua, ambas as máquinas fazem o balanceamento de carga de uma parte do tráfego do cliente.

Para alta disponibilidade mútua, o tráfego do cliente é designado a cada máquina do Dispatcher em um endereço de cluster. Cada cluster pode ser configurado com o NFA (nonforwarding address) de seu Dispatcher principal. A máquina principal do Dispatcher normalmente executa o balanceamento de carga para esse cluster. Em caso de falha, a outra máquina executa o balanceamento de carga para seu próprio cluster e para o cluster do Dispatcher que falhou.

Para obter uma ilustração de uma configuração de alta disponibilidade mútua com “conjunto de clusters A" compartilhado e “conjunto de clusters B" compartilhado, consulte Figura 14. Cada Dispatcher pode rotear ativamente os pacotes para seu cluster principal. Se o Dispatcher falhasse e não pudesse mais rotear ativamente os pacotes para seu cluster principal, o outro Dispatcher poderia assumir o controle roteando pacotes para seu cluster de backup.

Nota:
Ambas as máquinas devem configurar seus conjuntos de clusters compartilhados da mesma forma. Ou seja, as portas usadas e os servidores em cada porta devem ser idênticos nas duas configurações.

Para obter informações sobre a configuração de alta disponibilidade e alta disponibilidade mútua, consulte Alta Disponibilidade.