Services de mise en réseau d'applications : Cisco LocalDirector de la gamme 400

LocalDirector - FAQ

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


LocalDirector est maintenant fin de commercialisation. Référez-vous au pour en savoir plus de bulletins de Cisco LocalDirector de la gamme 400.


Questions


Introduction

Le Local Director est une solution facilement disponible et Internet-extensible qui équilibrent la charge intelligemment le trafic TCP/IP à travers de plusieurs serveurs. Serveurs peut automatiquement et d'une manière transparente aller dedans ou hors service. Le Local Director est livré avec un mécanisme de secours immédiat de Basculement, éliminant tous les points de panne pour la batterie de serveur.

Ce document apporte des réponses aux forums aux questions (Foire aux questions) au sujet du Local Director.

Q. Combien d'interfaces de Local Director sont nécessaires ?

A. Un minimum de deux interfaces sont nécessaires ; ceux-ci devraient être séparés par les différents réseaux locaux virtuels (VLAN) dans un commutateur, ou par deux Concentrateurs distincts

Q. Comment est-ce que j'assigne une adresse secondaire à un Local Director ?

A. Émettez la commande d'IP address de pseudonyme, qui est apparue la première fois dans la version de logiciel 3.1.3 de Local Director. Si vous êtes en mode de Basculement, vous devez également émettre la commande d'IP address de Basculement alias.

Q. Comment le Local Director entraîne-t-il une vraie panne de serveur ?

A. Par défaut, le Local Director dépiste deux mesures (le pas de réponse réaffectent et la Réinitialisation TCP réaffectent) en déterminant la disponibilité du serveur. Vous pouvez employer les valeurs seuil et les valeurs de réaffecter pour ajuster le mécanisme de panne de serveur.

Q. Pourquoi le Local Director 3.1.3 ne réaffecte-il pas les connexions adhérentes défectueuses SSL ?

A. Ce numéro est apparu la première fois dans le Local Director 3.1.3, quand Secure Sockets Layer (SSL) Rémanent a été introduit la première fois. Cette question est abordée par l'ID de bogue Cisco CSCdp03095 (clients enregistrés seulement).

Q. Pourquoi le Local Director 3.1.3 ne décrémente-il pas des connexions correctement à l'aide du moins predictor de connexion ?

A. Cette question est abordée par l'ID de bogue Cisco CSCdp09265 (clients enregistrés seulement).

Q. Le Local Director 3.1.3 ne réplique pas sa configuration vers l'équipement de réserve correctement. Pourquoi ?

A. Ce numéro est apparu la première fois dans la version 3.1.3 de LocalDirector. Référez-vous à l'ID de bogue Cisco CSCdm47752 (clients enregistrés seulement).

Q. Queest-ce que le contournement pour le problème avec le SSL est Rémanent et l'Internet Explorer 5.0 ?

A. Ce problème affecte les clients qui utilisent IE 5.0 en tant que leur navigateur et initient une session SSL par n'importe quel Local Director qui utilise le code 3.1.x de Local Director et plus élevé. Quand le Local Director est configuré pour employer le SSL Rémanent pour mettre à jour la Persistance de session, un ID SSL est créé. Le Local Director trace l'ID de session SSL (SID) à un vrai serveur spécifique. IE 5.0 remet à l'état initial le SSL SID entre de 30 secondes à deux minutes. Ceci fait les utilisations de LocalDirector de l'information de mettre à jour la Persistance de session inutile.

Voyez la redirection HTTP ou Rémanent générique pour mettre à jour la Persistance de session avec des applications SSL.

Q. Quand I exécutent le code du Local Director 3.1.3, le SSL Rémanent ne fonctionne pas. Pourquoi ?

A. Peu peut être fait au sujet de cette question ; cependant, envisagez d'essayer ce qui suit :

  1. Make s'assurent que les web server sont configurés pour prendre en charge la version 3 SSL seulement
  2. Configurez un default route sur le Local Director, parce qu'il proxy la connexion initiale. On le recommande fortement que vous amélioriez à la dernière release disponible en ce moment (vérifiez les notes de mise à jour pour des détails).
  3. En dernier recours, vous pourriez exécuter un tracé de renifleur pour confirmer exactement les questions appropriées.
  4. Vérification - Les contrôles finaux ont lieu sur le serveur et le côté client pour assurer des transferts n'ont pas été gênés par un tiers. Quand le serveur et le côté client confirment la validité des transferts, la prise de contact est complète. Si la confirmation ne se produit pas, la prise de contact recommence afin d'essayer de corriger une interception ou un problème qui ont pu s'être produits dans la prise de contact d'origine.

Q. Pour quoi est-il Rémanent SSL utilisé ?

A. Le SSL Rémanent dans le Local Director met à jour la Persistance de session quand des applications SSL sont utilisées. Puisque le SSL est un moyen de transport chiffré, le Local Director est limité à quelles variables il peut employer pour identifier le trafic d'un client pour s'assurer qu'il va au même vrai serveur. Le Local Director utilise un SSL SID, qui est créé entre le client et serveur pendant le protocole handshake SSL. Le protocole handshake simplifié SSL est comme suit :

  1. Client bonjour - Informe le serveur quels algorithmes de chiffrement le client peut prendre en charge et demande la vérification de l'identité du serveur. Le SSL SID est généré.
  2. Serveur bonjour - Envoie au client son ID numérique et détermine quels cryptographique et algorithmes de compression à l'utiliser pour la session. L'ID de session SSL est confirmé et utilisé en réponse.
  3. Approbation de client - Valide l'authenticité d'un serveur. Une fois que le serveur est vérifié, le client génère une clé secrète et la chiffre avec la clé publique du serveur qui est fournie dans le serveur bonjour. Le client envoie alors la clé secrète chiffrée de nouveau au serveur.
  4. Vérification - Les contrôles finaux ont lieu sur le serveur et le côté client pour assurer des transferts n'ont pas été gênés par un tiers. Quand le serveur et le côté client confirment la validité des transferts, la prise de contact est complète. Si la confirmation ne se produit pas, la prise de contact recommence afin d'essayer de corriger une interception ou un problème qui ont pu s'être produits dans la prise de contact d'origine.

Q. Mes vrais serveurs peuvent-ils être sur un différent sous-réseau que le sous-réseau virtuel du Local Director ?

A. Oui. Il y a au moins deux configurations réseau possibles pour faire ceci se produire.

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

Si :

  • L'adresse IP du Local Director est 192.1.1.10 255.255.255.0.

  • L'interface du routeur vers le Local Director est 192.1.1.1 255.255.255.0.

  • Le vrai serveur est 204.1.1.20.

Puis :

  • Ajoutez une adresse secondaire sur l'interface du routeur ; par exemple, 204.1.1.1 255.255.255.0. Cette adresse doit être sur le même sous-réseau que les vrais serveurs.

  • Changez la passerelle par défaut du vrai serveur à 204.1.1.1.

  • Assurez-vous que la passerelle par défaut du Local Director est 192.1.1.1.

  • Si vous exécutez le code 3.x sur le Local Director, ajoutez l'adresse IP 204.1.1.10 de pseudonyme aussi bien.

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

Si :

  • L'adresse IP du Local Director est 192.1.1.10 255.255.255.0.

  • L'interface du routeur 1's vers le Local Director est 192.1.1.1 255.255.255.0.

  • L'interface du routeur 2's vers le Local Director est 192.1.1.2 255.255.255.0.

  • Le vrai serveur est 204.1.1.20.

Puis :

  • Ajoutez l'artère 204.1.1.0 255.255.255.0 192.1.1.2 dans le Local Director pour lui permettre de diriger n'importe quel trafic pour de vrais serveurs vers le deuxième routeur.

Q. Que faites-vous quand vous détectez que les paquets de vrais serveurs traversent le Local Director et sont lâchés par le Pare-feu ?

A. Il est possible qu'il y ait une certaine retransmission des paquets de FIN (ou un ACK) des serveurs après le Local Director a enlevé la connexion de la table. Vous pouvez configurer le Local Director pour bloquer ce genre de demande en ajoutant la commande sécurisée à votre configuration. Ceci bloquerait tous les paquets n'appartenant pas aux connexions équilibrées par chargement. Une autre solution est d'ajouter la commande de retard votre configuration. Cette commande enlève la connexion quelques minutes plus tard. Voyez la référence de commandes pour la version 4.2 du logiciel de Local Director pour plus d'informations de commande.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 15062