Planejando o Content Based Routing

Este capítulo descreve o que o planejador de rede deve levar em consideração antes de instalar e configurar o componente CBR com o Caching Proxy.

Este capítulo inclui a seguinte seção:

Considerações de Planejamento

O componente CBR permite fazer o balanceamento de carga do tráfego HTTP e SSL usando Caching Proxy para colocar a solicitação em proxy. Com o CBR, é possível fazer o balanceamento de carga de servidores que são configurados a partir do arquivo de configuração do CBR usando comandos cbrcontrol.

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

O CBR é bastante semelhante ao Dispatcher em sua estrutura de componente. O CBR consiste nas seguintes funções:

As três funções chave do CBR (executor, gerenciador e orientadores) interagem para balancear e despachar as solicitações recebidas entre os servidores. Junto com as solicitações de balanceamento de carga, o executor monitora o número de novas conexões e de conexões ativas, além de fornecer essas informações ao gerenciador.

Fazendo o Balanceamento de Carga de Solicitações para Diferentes Tipos de Conteúdo

O componente CBR fornece a capacidade de especificar um conjunto de servidores que tratará de uma solicitação com base em uma expressão regular correspondente ao conteúdo da solicitação do cliente. O CBR permite particionar seu site para que diferentes serviços de aplicativo e conteúdo possam ser entregues por diferentes conjuntos de servidores. Esse particionamento é transparente para os clientes acessando seu site.

Dividindo o Conteúdo do Site para Melhorar o Tempo de Resposta

Uma maneira de dividir o site seria designar alguns servidores para tratar apenas de solicitações cgi e outro conjunto de servidores para tratar de todas as outras solicitações. Isso impediria que scripts cgi cheios de cálculos deixassem os servidores lentos para um tráfego HTML normal, permitindo que os clientes tenham um tempo de resposta geral melhor. Usando esse esquema, você poderia designar estações de trabalho mais potentes para solicitações normais. Isso daria aos clientes um tempo de resposta melhor sem gastos de upgrade para todos os servidores. Você poderia designar estações de trabalho mais potentes para solicitações cgi.

Outra possibilidade para o particionamento de seu site poderia ser direcionar os clientes que estão acessando páginas que requerem registro para um conjunto de servidores e todas as outras solicitações para um segundo conjunto de servidores. Isso impediria que os navegadores casuais do seu site experimentassem os recursos que poderiam ser usados por clientes confirmados por um registro. Isso também permitiria que você usasse estações de trabalho mais potentes para atender aqueles clientes que se registraram.

Você poderia, é claro, combinar os métodos acima para aumentar a flexibilidade e melhorar os serviços.

Fornecendo Backup do Conteúdo do Servidor da Web

Como o CBR permite especificar diversos servidores para cada tipo de solicitação, as solicitações podem ter a carga balanceada para uma resposta de cliente otimizada. Ao permitir que diversos servidores sejam designados a cada tipo de conteúdo, você estará protegido se uma estação de trabalho ou servidor falhar. O CBR reconhecerá a falha e continuará fazendo o balanceamento de carga de solicitações de clientes para os outros servidores no conjunto.

Usando diversos Processos do Caching Proxy para Melhorar a Utilização de CPU

Caching Proxy comunica-se com um processo do CBR por meio de sua interface de plug-in. O CBR deve estar em execução na máquina local para isso funcionar. Como são dois processos separados, diversas instâncias do Caching Proxy podem estar em execução e trabalhando com uma única instância do CBR. Essa configuração pode ser feita para segregar endereços ou funcionalidade entre os Caching Proxies ou para melhorar a utilização de recursos da máquina com diversos Caching Proxies tratando do tráfego do cliente. As instâncias de proxy podem estar atendendo em diferentes portas ou estar se conectando a endereços IP exclusivos na mesma porta, dependendo do que for mais adequado para os requisitos de tráfego.

Usando Balanceamento de Carga Baseado em Regra com CBR

O CBR, junto com o Caching Proxy, examina solicitações de HTTP usando tipos de regra especificados. Durante a execução, o Caching Proxy aceita solicitações de clientes e consulta o componente CBR em busca do melhor servidor. Mediante essa consulta, o CBR faz a correspondência da solicitação com um conjunto de regras priorizadas. Quando uma regra é correspondida, um servidor é escolhido de um conjunto de servidores pré-configurado. Por fim, o CBR informa o Caching Proxy qual servidor foi escolhido e a solicitação é colocada em um proxy lá.

Após definir um cluster para ter a carga balanceada, você deve se certificar de que todas as solicitações para esse cluster tenham uma regra que escolherá um servidor. Se não for localizada nenhuma regra correspondente a uma determinada solicitação, o cliente receberá uma página de erro do Caching Proxy. A maneira mais fácil de se garantir que todas as solicitações corresponderão a alguma regra é criando uma regra "sempre true" com um número de prioridade bastante alto. Certifique-se de que os servidores usados por essa regra possam tratar de todas as solicitações que não são tratadas explicitamente pelas regras com uma prioridade mais baixa. (Nota: As regras de prioridade com número mais baixo são avaliadas primeiro.)

Para obter informações adicionais, consulte Configurando Balanceamento de Carga Baseado em Regras.

Fazendo o Balanceamento de Carga em Conexões Totalmente Seguras (SSL)

O CBR com Caching Proxy pode receber transmissão de SSL do cliente para o proxy (lado cliente-para-proxy), bem como transmissão de suporte do proxy para um servidor SSL (lado proxy-para-servidor). Ao definir uma porta SSL em um servidor na configuração do CBR para receber a solicitação de SSL do cliente, você tem a capacidade de manter um site totalmente seguro usando CBR para fazer o balanceamento de carga em servidores seguros (SSL).

Além de outras mudanças do arquivo ibmproxy.conf para CBR, outra instrução de configuração precisa ser incluída no ibmproxy.conf para Proxy de Armazenamento para ativar a criptografia SSL no lado do proxy-para-servidor. O formato deve ser:

proxy uri_pattern url_pattern address

em que uri_pattern é um padrão para correspondência (por exemplo: /secure/*), url_pattern é uma URL de substituição (por exemplo: https://clusterA/secure/*) e address é o endereço do cluster (por exemplo: clusterA).

Fazendo o Balanceamento de Carga de Cliente-para-proxy em SSL e Proxy-para-servidor em HTTP

O CBR com Caching Proxy também pode receber transmissão de SSL do cliente e decriptografar a solicitação de SSL antes de colocá-la em proxy para um servidor HTTP. Para o CBR suportar cliente-para-proxy em SSL e proxy-para-servidor em HTTP, há uma palavra-chave opcional, mapport no comando do servidor cbrcontrol. Use essa palavra-chave quando precisar indicar que a porta no servidor é diferente da porta recebida do cliente. A seguir está um exemplo de como incluir uma porta usando a palavra-chave mapport, em que a porta do cliente é 443 (SSL) e a porta do servidor é 80 (HTTP):

cbrcontrol server add cluster:443 mapport 80

O número da porta para mapport pode ser qualquer valor de número inteiro positivo. O padrão é o valor do número da porta recebida do cliente.

Como o CBR deve estar apto a avisar sobre uma solicitação de HTTP para um servidor configurado na porta 443 (SSL), um orientador especial ssl2http é fornecido. Esse orientador começa na porta 443 (a porta recebida do cliente) e avisa o(s) servidor(es) configurado(s) para essa porta. Se houver dois clusters configurados, e cada cluster tiver a porta 443 além dos servidores configurados com um mapport diferente, uma única instância do orientador poderá abrir a porta adequada de acordo. A seguir está um exemplo dessa configuração:

Executor
    Cluster1
       Port:443
           Server1 mapport 80
           Server2 mapport 8080
    Cluster2
       Port:443
           Server3 mapport 80
           Server4 mapport 8080
    Manager
      Advisor ssl2http 443