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

LocalDirector FAQ

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


LocalDirector é agora Fim--venda. Refira os boletins do Cisco LocalDirector série 400 para mais informação.


Perguntas


Introdução

O diretor local é um requisito de alta disponibilidade, solução Internet-escalável que carrega inteligentemente o tráfego dos equilíbrios TCP/IP através dos servidores múltiplos. Server pode automaticamente e transparentemente ir dentro ou fora de serviço. O diretor local vem com um mecanismo de failover em hot standby, eliminando todos os pontos da falha para a fazenda do server.

Este documento dá respostas às perguntas mais frequentes (FAQ) sobre o diretor local.

Q. Quantas relações do diretor local são precisadas?

A. Um mínimo de duas relações é precisado; estes devem ser separados pelos LAN virtuais diferentes (VLAN) em um interruptor, ou por dois concentradores separados

Q. Como eu atribuo um endereço secundário a um diretor local?

A. Emita o comando alias ip address, que apareceu primeiramente na versão de software 3.1.3 do diretor local. Se você reage do modo de failover, você igualmente precisa de emitir o comando failover alias ip address.

Q. Como o diretor local causa uma falha de servidor real?

A. À revelia, o diretor local segue o medidor dois (a sem resposta atribui novamente e o TCP Reset atribui novamente) ao determinar a disponibilidade do servidor. Você pode usar os valores de limiar e os valores da atribuição renovada para ajustar o mecanismo de falha do servidor.

Q. Por que o diretor local 3.1.3 não atribui novamente conexões difíciis falhadas SSL?

A. Esta edição apareceu primeiramente no diretor local 3.1.3, quando o Sticky do secure sockets layer (SSL) foi introduzido primeiramente. Esta edição é endereçada pela identificação de bug Cisco CSCdp03095 (clientes registrados somente).

Q. Por que o diretor local 3.1.3 não decresce conexões corretamente ao usar menos predictor de conexão?

A. Esta edição é endereçada pela identificação de bug Cisco CSCdp09265 (clientes registrados somente).

Q. O diretor local 3.1.3 não replicate sua configuração à unidade em standby corretamente. Por quê?

A. Esta edição apareceu primeiramente na versão de localdirector 3.1.3. Refira a identificação de bug Cisco CSCdm47752 (clientes registrados somente).

Q. Que é a ação alternativa para o problema com Sticky SSL e internet explorer 5.0?

A. Este problema afeta os clientes que usam IE 5.0 como seu navegador e iniciam uma sessão de SSL através de todo o diretor local que usar o código 3.1.x do diretor local e mais altamente. Quando o diretor local é configurado para usar o Sticky SSL para manter a Persistência de sessão, um ID de SSL está criado. O diretor local traça a sessão de SSL ID (SID) a um servidor real específico. O IE 5.0 restaura o SSL SID entre de 30 segundos a dois minutos. Isto faz os usos do informação usado pelo LocalDirector manter a Persistência de sessão inútil.

Veja o Redireção do HTTP ou o Sticky genérico para manter a Persistência de sessão com aplicativos de SSL.

Q. Quando eu executo o código do diretor local 3.1.3, o Sticky SSL não está trabalhando. Por quê?

A. Pouco pode ser feito sobre esta edição; contudo, considere tentar o seguinte:

  1. Make certifica-se de que os servidores de Web estão configurados para apoiar somente a versão de SSL 3
  2. Configurar uma rota padrão no diretor local, porque proxy a conexão inicial. Recomenda-se fortemente que você promove à liberação a mais atrasada disponível neste momento (verifique os Release Note para ver se há detalhes).
  3. Como um último recurso, você poderia executar um farejador de rastreamento para confirmar exatamente as edições apropriadas.
  4. Verificação - As verificações final ocorrem no lado servidor e cliente para assegurar-se de que transferências não estejam interferidas com por uma terceira parte. Quando o lado servidor e cliente confirma a validez de transferências, o aperto de mão está completo. Se a confirmação não ocorre, o aperto de mão começa sobre na tentativa de corrigir uma intercepção ou um problema que possam ter ocorrido no handshake original.

Q. Que o Sticky SSL é usado para?

A. O Sticky SSL no diretor local mantém a Persistência de sessão quando os aplicativos de SSL são usados. Porque o SSL é um meio de transporte cifrado, o diretor local é limitado a que variáveis pode usar para identificar o tráfego de um cliente para se certificar que vai ao mesmo servidor real. O diretor local usa um SSL SID, que seja criado entre o cliente e servidor durante o protocolo de handshake SSL. O protocolo de handshake SSL simplificado é como segue:

  1. Hellos do cliente - Informa o server que algoritmos criptográficos o cliente pode apoiar e pede-o a verificação da identidade do server. O SSL SID é gerado.
  2. Servidores hello - Envia ao cliente seu ID digital e determina que criptograficamente e algoritmos de compactação a se usar para a sessão. A sessão de SSL ID é confirmada e usada na resposta.
  3. Aprovação de cliente - Valida a autenticidade de um server. Uma vez que o server é verificado, o cliente gerencie uma chave secreta e cifra-a com a chave pública do server que é fornecida nos servidores hello. O cliente envia então a chave secreta cifrada de volta ao server.
  4. Verificação - As verificações final ocorrem no lado servidor e cliente para assegurar-se de que transferências não estejam interferidas com por uma terceira parte. Quando o lado servidor e cliente confirma a validez de transferências, o aperto de mão está completo. Se a confirmação não ocorre, o aperto de mão começa sobre na tentativa de corrigir uma intercepção ou um problema que possam ter ocorrido no handshake original.

Q. Podem meus servidores reais estar em uma sub-rede diferente do que a sub-rede virtual do diretor local?

A. Sim. Há pelo menos duas instalações de rede possíveis para fazer isto acontecer.

/image/gif/paws/15062/locdirfaq-1.gif

Se:

  • O endereço IP de Um ou Mais Servidores Cisco ICM NT do diretor local é 192.1.1.10 255.255.255.0.

  • A relação do roteador para o diretor local é 192.1.1.1 255.255.255.0.

  • O server real é 204.1.1.20.

Então:

  • Adicionar um endereço secundário na relação do roteador; por exemplo, 204.1.1.1 255.255.255.0. Este endereço tem que estar na mesma sub-rede como os servidores reais.

  • Mude o gateway padrão do servidor real a 204.1.1.1.

  • Certifique-se que o gateway padrão do diretor local é 192.1.1.1.

  • Se você está executando o código 3.x no diretor local, adicionar o endereço IP 204.1.1.10 do pseudônimo também.

/image/gif/paws/15062/locdirfaq-2.gif

Se:

  • O endereço IP de Um ou Mais Servidores Cisco ICM NT do diretor local é 192.1.1.10 255.255.255.0.

  • A relação do roteador 1's para o diretor local é 192.1.1.1 255.255.255.0.

  • A relação do roteador 2's para o diretor local é 192.1.1.2 255.255.255.0.

  • O server real é 204.1.1.20.

Então:

  • Adicionar a rota 204.1.1.0 255.255.255.0 192.1.1.2 no diretor local para permiti-la de dirigir todo o tráfego para servidores reais ao segundo roteador.

Q. Que você faz quando você detecta que os pacotes dos servidores reais passam através do diretor local e estão deixados cair pelo Firewall?

A. É possível que há alguns pacotes da retransmissão de FIN (ou o ACK) dos server após o diretor local removeu a conexão da tabela. Você pode configurar o diretor local para obstruir este tipo do pedido adicionando o comando secure a sua configuração. Isto obstruiria todos os pacotes que não pertencem às conexões equilibradas carga. Uma outra solução é adicionar o comando delay sua configuração. Este comando remove a conexão certos minutos mais tarde. Veja a referência de comandos para a versão 4.2 do software do diretor local para a informação do comando more.


Informações Relacionadas


Document ID: 15062