Serviços de rede de aplicativos : Cisco LocalDirector 400 Series

Métodos da configuração difícil em LocalDirector

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


A Cisco anunciou o fim das vendas para o Cisco LocalDirector. Para mais informação, refira o fim da vida útil do 400 Series de LocalDirector e as observações e os boletins de produto da Fim--venda.


Índice


Introdução

O Sticky ou a Persistência de sessão são um método de uso geral que se assegure de que uma sessão cliente permaneça conectada ou colada ao mesmo server para a duração de sua sessão. Isto é necessário para o anúncio publicitário ou os aplicativos seguros que exigem a preservação da informação de sessão, ou exige um login de usuário e uma authentication e autorização. Normalmente em uma encenação do Balanceamento de carga, cada requisição sucessiva do cliente outra vez é avaliada e pode ser enviada a um server diferente na rotação do Balanceamento de carga. Quando todos os server têm o mesmo índice e se o usuário olha somente a informação, este é o método preferido para o Balanceamento de carga. Quando a Persistência de sessão é exigida, um de três métodos para o Sticky pode ser usado no LocalDirector (LD) — Sticky genérico, Sticky do Secure Socket Layer (SSL), e Cookie.

Pré-requisitos

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você está em uma rede viva, assegure-se de que você compreenda o impacto potencial do comando any antes que você o use.

Métodos de configuração

Sticky genérico

O Sticky genérico é baseado no endereço IP de origem da conexão recebida. Os pedidos do mesmo endereço IP de Um ou Mais Servidores Cisco ICM NT são enviados sempre ao mesmo server que esse que foi selecionado em sua conexão inicial. O LD mantém uma tabela interna que siga esta informação. Para configurar o Sticky genérico, emita o comando sticky virtual_id minutes generic.

O ID Virtual (VID) é definido no comando bind da configuração LD, e nos minutos onde o parâmetro é quanto tempo depois que as disconexões de um cliente a esperar até que sua informação da associação difícil (que o server eles era na última vez) esteja removida. O usuário pode ser colado a um server diferente a próxima vez que conectam. O padrão é minutos zero (deficiente pegajoso).

Caveat

Este método trabalha bem a menos que os clientes de entrada trabalharem através de um proxy, do Firewall, ou de um roteador que execute a tradução de endereços. Nesta situação, o LD vê todos os pedidos de usuário que vêm do mesmo endereço IP de Um ou Mais Servidores Cisco ICM NT, e envia todos os pedidos ao mesmo server.

Sticky SSL

O Sticky SSL é baseado na sessão de SSL ID (SID) do cliente à conexão de servidor. SID obtém negociado quando o cliente conecta. SID é enviado no cabeçalho HTTP, e não cifrado. SID seja lido pelo LD. A sintaxe de comando é SSL pegajoso dos minutos do virtual_id.

O VID é definido no comando bind da configuração LD, e o parâmetro dos minutos é quanto tempo depois que as disconexões de um cliente a esperar até que sua informação da associação difícil (que o server eles era na última vez) esteja removida. O usuário pode ser colado a um server diferente a próxima vez que conectam. O padrão é minutos zero (deficiente pegajoso).

Caveat

O internet explorer 5.x e acima renegocia agora o ID de SSL cada dois minutos. Para obter mais informações sobre disto, refira o internet explorer renegocia a conexão do secure sockets layer cada dois minutosleavingcisco.com .

Um cenário difícil baseado em um valor que mude constantemente não trabalha bem. Como uma ação alternativa, configurar o LD de modo que o cliente venha dentro no HTTP, e seja carga equilibrada entre um grupo de reorientam URL um pouco do que servidores de Web. Cada um destas URL aponta de volta a um endereço direto IP (MERGULHO) no LD esse mapas a um único servidor real. Agora que o cliente se comunica a um servidor único, não pode haver uma carga equilibrada a um outro real e pode evitar esta edição. Para obter mais informações sobre desta configuração, refira configurar o redirecionamento HTTP a https no Cisco LocalDirector.

Esta configuração exige usando endereços IP públicos extra, um para cada servidor real, registro de todos os servidores reais no DNS, e que o novato do cliente a conexão em HTTP (porta 80) um pouco do que HTTPS (porta 443).

Cookies

Há dois tipos de Cookie que o LD pode trabalhar com, cookie passivo (os Cookie que são introduzidos pelos servidores de Web do servidor de retaguarda), e o Cookie introduz (os Cookie introduzidos pelo LD próprio).

Modo passivo de cookie pegajoso

A sintaxe de comando é nome pegajoso do modo passivo de cookie dos minutos do virtual_id.

Este comando permite a conexão difícil baseada em um Cookie criado pelo servidor real pegajoso. O LD aprende o Cookie e armazena-o na memória. Quando duas cookies idêntico (dois Cookie com o mesmos NOME e VALOR) existem em dois server diferentes, o modo do modo passivo de cookie na versão 3.3.x LD não pode trabalhar corretamente. O LD faz decisões no relacionamento difícil baseado no Cookie recebido do servidor de Web. A segunda cookie idêntico quebra o primeiro relacionamento difícil no LD.

O LD (que atua como um servidor proxy) recebe conexões de cliente novas e faz a varredura do pedido HTTP GET para um Cookie esse combina um na memória. Se há um fósforo e o tempo não expirou, LD pacotes para a frente ao servidor real pegajoso previamente selecionado. O LD faz a varredura então de pacotes do servidor real pegajoso até que a primeira resposta HTTP esteja detectada. Se há um fósforo, mas o tempo expirou, o LD atribui a conexão a um servidor real novo. Se não há nenhum token set-cookie na resposta HTTP, o LD para de atuar como servidor proxy e para a frente todos os pacotes diretamente ao servidor real pegajoso. Se há um set-cookie na resposta HTTP, o LD armazena o Cookie novo na memória e para-o de atuar como o servidor proxy para a conexão. Se o servidor real pegajoso não responde nem retorna a um TCP RST, o LD atribui a conexão a um servidor real novo.

Se o servidor real retorna Cookie múltiplos no cabeçalho HTTP, o LD faz a varredura para o primeiro diretivo set-cookie e ajusta então o relacionamento difícil (persistência) para conexões subsequente no primeiro Cookie encontrado no cabeçalho HTTP.

Inserção de cookies pegajosa

A sintaxe de comando para a inserção do Cookie é domínio pegajoso do nome da inserção de cookies dos minutos do virtual_id.

Este é um comando opcional. Este comando permite a conexão difícil baseada em um Cookie criado pelo LD. O LD (que atua como um servidor proxy) recebe conexões de cliente novas e faz a varredura do cabeçalho HTTP do pedido GET para um Cookie. Se um não é detectado, o LD atribui a conexão a um servidor real e cria o Cookie. Se um Cookie é detectado, o LD extrai-o para determinar o servidor real pegajoso ID e o tempo de expiração. Se o tempo não expirou, LD para a frente a conexão ao servidor real pegajoso. Se o tempo expirou, o LD atribui a conexão a um servidor real pegajoso novo e cria um Cookie novo.

Uma vez que uma associação difícil é estabelecida, o LD para de atuar como servidor proxy, e para a frente todos os pacotes diretamente ao servidor real pegajoso. A opção da inserção de cookies é baseada no tempo. É incomum para que os pulsos de disparo do cliente e servidor sejam sincronizados exatamente. É recomenda que você especifica um grande bastante valor no argumento dos minutos para cobrir possíveis diferenças de clock entre clientes e servidor. O nome é muito importante, porque é a corda que o LD procura e decide que server os pacotes devem ser enviados. O tempo no LD é igualmente muito importante, e deve ser ajustado ao tempo meridiano de Greenwich (GMT) nas forças armadas ou no formato do tempo universal coordenado (UTC).


Informações Relacionadas


Document ID: 25746