Gestion et automatisation de réseau : Cisco Network Registrar

Comment gérer le basculement DHCP CNS Cisco Network Registrar

30 juillet 2013 - Traduction automatique
Autres versions: PDFpdf | Anglais (31 janvier 2006) | Commentaires


Contenu


Introduction

Ce document explique comment installer et gérer des paires de serveur de Basculement du protocole DHCP de Network Registrar de Cisco CNS (DHCP) pour la release (5,5 ou plus tard). Les paires de Basculement sont les serveurs DHCP principaux et de sauvegarde qu'interactif dans une configuration de Basculement, et le serveur de sauvegarde succède pour louer des adresses aux clients si le serveur principal est en panne.

Le reste de ce document explique ce qu'est le Basculement DHCP, comment il fonctionne, et comment installer, vérifier, et dépanner le Basculement simple.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations de ce document sont basées sur les versions de logiciel et matériel suivantes :

  • Versions 5.5 et 6.0.x de Cisco Network Registrar

  • Serveur du Sun Solaris E220R avec Solaris 8 installé

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Quel est Basculement DHCP ?

Le Basculement du protocole DHCP (DHCP) est un protocole conçu pour permettre à de plusieurs serveurs pour traiter un réseau simple. Le Cisco Network Registrar permet à un serveur DHCP de sauvegarde pour succéder pour un serveur DHCP principal de Network Registrar si le serveur principal échoue. Pour que ceci fonctionne sûrement, les serveurs primaires et secondaires doivent mettre à jour une base de données cohérente des informations de bail. Les serveurs doivent coordonner toute l'activité de bail de sorte que ces informations soient synchronisées en cas de Basculement.

Il y a trois types de configurations de Basculement DHCP de Network Registrar :

Le Basculement simple est le Basculement le plus facile à gérer. Ce document se concentre sur la façon implémenter, vérifier, et dépanner le Basculement simple. Il n'y a aucun avantage de représentation avec le backoffice et les configurations symétriques.

Basculement simple

Le Basculement simple inclut un serveur principal simple et son serveur de sauvegarde suivant les indications de cette illustration :

/image/gif/paws/46807/17867.gif

Ce sont les avantages du Basculement simple :

  • La configuration est simple — le Basculement est activé au niveau du serveur.

  • Le serveur de sauvegarde est identique au serveur principal.

  • Il est facile mettre à jour Basculement simple car le réseau change.

Basculement de Backoffice

Le Basculement de Backoffice inclut beaucoup de serveurs principaux qui utilisent un serveur de sauvegarde simple suivant les indications de cette illustration :

17868.gif

Un avantage de Basculement de backoffice est qu'il réduit le nombre total de serveurs que vous devez gérer.

Ce sont les inconvénients du Basculement de backoffice :

  • Vous devez classer le serveur de sauvegarde pour manipuler la somme des configurations.

  • Vous devez reproduire les modifications au serveur principal sur le serveur de sauvegarde.

Basculement symétrique

Avec le Basculement symétrique, le réseau est divisé entre deux serveurs et ils se sauvegardent.

/image/gif/paws/46807/17869.gif

attention Attention : Bien que dans le mode normal, les deux serveurs dans le Basculement symétrique partagent la charge du réseau, mais le gain dans la capacité de traitement est minimal. Un serveur de sauvegarde actionne à environ 40% de la capacité de serveurs principaux de maintenir la base de données de bail synchronisée. Si les serveurs se sauvegardent, ils doivent dédier une partie de leur capacité de traitement à la synchronisation, qui laisse moins de capacité disponible pour entretenir des clients. Le Basculement symétrique est sujet aux erreurs puisque vous devez configurer chaque portée individuellement. Utilisez le Basculement simple, parce qu'il a les la plupart des avantages avec les moins inconvénients.

Comment le Basculement fonctionne

Le protocole de Basculement est conçu pour se protéger contre plusieurs genres de pannes :

  • Panne du serveur principal — Le serveur de sauvegarde succède les services qui ont été fournis par le serveur principal jusqu'à ce que le serveur principal soit opérationnel de nouveau. Malgré le fait que le serveur principal met à jour le serveur de sauvegarde après qu'il réponde au DHCP Client (une mise à jour paresseuse), il n'y a aucune possibilité d'allocation d'adresse IP en double même si le serveur principal échoue avant qu'elle mette à jour le serveur de sauvegarde.

  • Panne de l'artère de communications entre les serveurs principaux et de sauvegarde — le serveur de sauvegarde ne peut pas distinguer une panne du serveur principal et la panne de l'artère de communications au serveur principal. Le protocole de Basculement est conçu pour fonctionner correctement dans l'un ou l'autre d'événement. Il n'y a aucune possibilité d'allocation d'adresse IP en double même si les deux serveurs restent opérationnels et chacun communique avec seulement un sous-ensemble de clients DHCP.

Vous pouvez employer de nombreux paramètres pour définir votre configuration de Basculement. Les paramètres sont décrits dans les paramètres de Basculement et leur section de descriptions.

Après que vous mettiez en marche les serveurs, chaque serveur entre en contact avec l'autre. Après le contact est établi, le serveur principal fournit au serveur de sauvegarde un pool privé des adresses IP pour l'utiliser en cas d'une panne. Le serveur principal met à jour le serveur de sauvegarde toutes les fois qu'il exécute une exécution pour un DHCP Client.

Le serveur principal continue à mettre à jour le serveur de sauvegarde et le serveur de sauvegarde permet le serveur principal aux demandes de client de service dhcp.

Si une panne se produit sur le serveur principal, le serveur de sauvegarde assure et renouvelle les adresses des clients en cours et des adresses d'offres à de nouveaux clients. Quand le serveur principal est opérationnel de nouveau, il réintègre automatiquement avec le serveur de sauvegarde sans intervention d'administrateur.

Cette illustration est un exemple de trafic téléphonique dans une configuration de Basculement :

/image/gif/paws/46807/101400.gif

Vous pouvez changer quelques paramètres systèmes par défaut, tels que le pourcentage des baux que le serveur principal envoie au serveur de sauvegarde, ou du délai d'exécution maximum de client (MCLT) suivant les indications de l'illustration. Si vous activiez le Basculement sur votre serveur DHCP, ne changez pas les attributs de Basculement-maximum-client-pôle-temps ou de bail-période-facteur. Si vous avez besoin de plus d'informations au sujet de la façon changer le par défaut MCLT et/ou louer des configurations de facteur de période, se rapporter au délai d'exécution maximum de client et louer la section de facteur de période dans ce document.

Choisir un pourcentage de sauvegarde

Placez le pourcentage de sauvegarde assez grand pour permettre au serveur de sauvegarde pour continuer à servir de nouveaux clients au cas où le serveur principal échouerait. Calculez le pourcentage de sauvegarde basé sur le nombre d'adresses disponibles. Le pourcentage de sauvegarde par défaut est 10%. Placez le pourcentage à une plus grande valeur si vous vous attendez à des pannes étendues, parce que les serveurs principaux reprend des adresses une fois par heure si le pool d'adresses du serveur principal chute au-dessous de son pourcentage de prédéfinis. Par exemple, avec le pourcentage 10% de sauvegarde par défaut, le serveur principal reprend des adresses si son pool d'adresses tombe en-dessous de 90%.

Facteur maximum de délai d'exécution de client et de période de bail

Si les paramètres par défaut n'adaptent pas votre environnement, il y a deux paramètres réglables qui sont essentiels à la fonctionnalité du Basculement : le délai d'exécution maximum de client (MCLT) et le facteur de période de bail. Si vous changez ces paramètres, vous devez les changer sur les deux serveurs.

  • MCLT — Le MCLT contrôle le temps maximum offert à un client au delà de l'expiration d'un bail dont le serveur de partenaire se rend compte. Le par défaut MCLT est d'une heure, qui est optimisée pour la plupart des configurations. Le protocole de Basculement déclare que la période de bail indiquée un client peut ne jamais être plus que le MCLT ajouté au temps d'expiration récemment reçu du partenaire de Basculement, ou le temps en cours, celui qui est plus tard. C'est pourquoi vous voyez parfois la période initiale de bail comme seulement heure, ou un plus long d'heure que prévu pour des renouvellements. Cette heure est le MCLT, une forme d'assurance de bail. La durée de bail réelle est recalculée quand le serveur principal revient.

    Le MCLT est nécessaire en raison de l'utilisation des mises à jour paresseuses par Basculement. Si vous utilisez les mises à jour paresseuses, le serveur peut fournir ou renouveler des baux aux clients avant qu'il mette à jour son partenaire, qu'il peut alors faire dans les séries de mises à jour. Si le serveur descend et ne peut pas communiquer les informations de bail à son partenaire, le partenaire peut ne pas essayer la re-offre que le bail à un autre client a basée sur sa dernière connaissance du bail. Le MCLT garantit qu'il y a une occasion fournie ajoutée pour que le client renouvelle. Une offre de bail et travaux de renouvellement avec le MCLT de cette manière :

    1. Le client envoie un DHCPDISCOVER au serveur, et demande une période désirée de bail, comme, trois jours.

    2. Le serveur répond avec un DHCPOFFER avec une première période de bail du MCLT seulement, une heure par défaut.

    3. Le client demande alors la période d'une heure de bail MCLT et le serveur reconnaît.

    4. Le serveur envoie à son partenaire une mise à jour de grippage qui contient l'expiration de bail pour le client comme temps en cours plus le MCLT, une heure. La mise à jour inclut également le temps d'expiration potentiel comme temps en cours plus la période désirée du client plus le MCLT, trois jours et une heure.

    5. Le partenaire reconnaît l'expiration potentielle, et garantit la transaction.

    6. Quand le client envoie une demande de renouvellement à mi-chemin par son bail, dans une demi- heure, le serveur reconnaît avec la période désirée de bail, trois jours, du client.

    7. Le serveur met à jour alors son partenaire avec l'expiration de bail comme le temps en cours plus la période désirée de bail, trois jours, et l'expiration potentielle comme temps en cours plus une période désirée et une moitié différente de cette période, 3 + 1,5 = 4,5 jours.

    8. Le partenaire reconnaît cette expiration potentielle de 4,5 jours. De cette façon, les essais de serveur principal pour faire mener à son partenaire toujours le client comprendre la période de bail pour le client de sorte qu'il puisse toujours l'offrir au client.

    Il n'y a aucune valeur correcte pour le MCLT. Le par défaut d'une heure fonctionne bien dans la plupart des environnements, mais il y a un compromis entre les facteurs si vous sélectionnez une valeur courte et longue MCLT :

    • Valeur courte MCLT — Une valeur courte MCLT signifie qu'après que vous entriez dans l'état PARTNER-DOWN, un serveur seulement doit attendre une courte durée avant qu'il commence à allouer les adresses IP du partenaire aux clients DHCP. Il seulement doit attendre une courte durée après que l'expiration d'un bail sur une adresse IP avant qu'il réapproprie cette adresse IP à un autre DHCP Client.

      Le du côté incliné d'une valeur courte MCLT est que l'intervalle initial de bail offert à chaque nouveau DHCP Client est court. Une valeur courte MCLT entraîne l'augmentation du trafic parce que ces le besoin des clients d'introduire leur première renouvellent dans la moitié de la quantité de peu de temps MCLT.

      En outre, les extensions de bail qu'un serveur dans l'état COMMUNICATIONS-INTERRUPTED peut donner sont seulement les MCLT après que le serveur soit dans COMMUNICATIONS-INTERRUPTED pour la période désirée de bail de client. Si un serveur reste dans COMMUNICATIONS-INTERRUPTED pour cela long, alors les baux qu'il distribue sont courts, et ce augmente le chargement sur ce serveur.

    • Longue valeur MCLT — Une longue valeur MCLT signifie que la période initiale de bail est plus longue et le temps qu'un serveur dans l'état COMMUNICATIONS-INTERRUPTED étend des baux, après qu'il ait été dans l'état COMMUNICATIONS-INTERRUPTED pour la période désirée de bail de client, est plus long.

      Cependant, un serveur qui entre dans l'état PARTNER-DOWN doit attendre le MCLT plus long avant qu'il alloue les adresses IP pour le partenaire à de nouveaux clients DHCP. Ceci signifie que des adresses IP supplémentaires sont exigées pour couvrir ce délai prévu. En outre, le serveur dans PARTNER-DOWN doit attendre le MCLT plus long de chaque expiration de bail avant qu'elle réapproprie une adresse IP à un différent DHCP Client.

  • Facteur de période de bail — Le facteur de période de bail contrôle combien en avant du client l'expiration de bail peut être selon le partenaire. Le facteur de période de bail est un multiple de la période désirée de bail qui est utilisée pour mettre à jour le partenaire quand le serveur principal l'informe d'un renouvellement de bail. Les valeurs possibles de l'ordre des valeurs sont :

    • 1,5 — Le par défaut et le facteur optimisé de période de bail est 1,5. C'est la période de bail plus la moitié du bail. Cette valeur est meilleur utilisé si la période de renouvellement est 50% du bail.

    • 1,0 — Même que la période de bail le serveur principal donne le client.

    • 2,0 — Deux fois la période de bail le serveur principal donne le client.

    Le facteur de période de bail interagit avec la période de renouvellement de bail. Si la période de renouvellement est plus de 50% du bail, vous devez également augmenter le facteur. Le calcul est :

    1 + renew-percentage = factor
    

    La période habituelle de renouvellement de 50% pourrait prendre (1 + 0,5 =) le facteur par défaut de période de 1,5 baux. Une période de renouvellement de 80% prendrait à a (1 + 0,8 =) le facteur de période de 1,8 baux.

    Vous devez définir le facteur de période de bail seulement pour le serveur DHCP principal. Le serveur principal ignore des facteurs de période de bail définis pour un partenaire, pour te permettre de reproduire les configurations par des scripts.

    La durée de la période sûre est :

    • Installation-particularité

    • Personne à charge sur le nombre d'adresses non allouées dans le groupe

    • Personne à charge sur le débit d'arrivée prévu de clients précédemment inconnus qui ont besoin des adresses

    La période sûre est en général 24 heures, bien que beaucoup d'environnements prennent en charge des périodes de plusieurs jours. Le nombre d'adresses supplémentaires exigées pour la période sûre doit être identique que le total prévu de nouveaux clients un serveur rencontre. Ceci dépend du débit d'arrivée de nouveaux clients, pas les baux attendus par total. Si vous pouvez seulement se permettre une période sûre courte, en raison de beaucoup d'adresses ou d'un débit d'arrivée élevé de nouveaux clients, vous pouvez bénéficier sensiblement quand vous permettez au DHCP pour monter par les problèmes mineurs qui sont fixables dans une heure. Il y a peu de possibilité d'allocation d'adresse en double et, après la panne résolue, la réintégration est automatique et n'exige aucune intervention d'un opérateur.

États de Basculement

Dans le Network Registrar, les états de Basculement définissent ce qu'est la situation en cours de transmission entre les paires principales et de sauvegarde de Basculement.

Régime Serveur principal Serveur de sauvegarde
Normal Sensible à tout le DHCP Client demande et alloue des adresses IP à de nouveaux clients de son groupe d'adresses IP disponibles. Il alloue au serveur de sauvegarde quelques adresses IP aux utiliser si des transmissions sont interrompues. Insensible aux demandes de DHCP Client excepté des renouvellements ou reliez de nouveau les demandes. Le serveur de sauvegarde invite et reçoit un ensemble d'adresses IP pour l'utiliser pour l'allocation à de nouveaux clients DHCP si la transmission avec le serveur principal est interrompue.
Transmissions interrompues Sensible à toutes les demandes de DHCP Client. Il ne peut pas indiquer si le serveur de sauvegarde est descendu ou si le serveur de sauvegarde ne peut pas simplement communiquer. Il fonctionne normalement, bien qu'il ne puisse pas réapproprier une adresse IP d'un DHCP Client à l'autre alors que dans ce régime. Ne peut pas dire si le serveur principal ne communique pas vers le bas ou simplement. Dans l'un ou l'autre de cas, le serveur de sauvegarde est sensible à toutes les demandes de DHCP Client et peut allouer des adresses IP de son groupe de disponible l'adresse reçoit du serveur principal.
De serveurs la transition habituellement entre la normale et les transmissions interrompues en tant qu'un ou autre serveur va en haut et en bas.
Partenaire vers le bas Le serveur courant est garanti que l'autre serveur est en panne. Le serveur courant a le contrôle de toutes les adresses IP, peut offrir n'importe quelle durée de bail ou période configurée d'extension de bail, et à tout moment peut réapproprier une adresse IP d'un client à l'autre. Transitions d'un serveur seulement au partenaire vers le bas s'il est au courant que l'autre partenaire soit vers le bas. La notification peut être ou par le protocole (utilisé quand le partenaire sait qu'il va vers le bas) ou parce que le serveur ne peut pas communiquer avec son partenaire, il a automatiquement écrit le régime interrompu par transmission, et l'administrateur a utilisé la commande de setPartnerDown. La commande de setPartnerDown indique au serveur que son partenaire est vers le bas. Vous pouvez configurer le Basculement pour affecter une transition automatique des transmissions interrompues au partenaire vers le bas après les passages de période sûre, mais vous courez le risque d'allocations d'adresse IP en double si le partenaire n'est pas réellement vers le bas.

Pour vérifier des états de Basculement, utilisez la commande CLI de getrelatedservers :

nrcmd> dhcp getrelatedservers
100 Ok 
Type   Name                    Address            Requests Communications localhost State Partner State 
MAIN   main.test.cisco.com     192.168.1.1        0 OK     NORMAL          NORMAL 
BACKUP backup.test.cisco.com   192.168.1.2        0 OK     NORMAL          NORMAL

Comment installer le Basculement simple

Instructions pas à pas pour des releases avant 6,0

Terminez-vous ces étapes pour installer un Basculement simple pour des versions avant la version 6.0.

  1. Employez l'utilitaire EXPORT de mcdadmin pour obtenir une reproduction précise du serveur principal :

    mcdadmin -x -e exportfile.mcd
    
    
    

    Il n'y a aucune sortie quand vous créez ce fichier. Pour vérifier que le fichier existe, exécutez la commande UNIX LS.

  2. Installez la même version du Network Registrar sur le serveur de sauvegarde.

  3. Copiez l'exportfile.mcd sur le serveur de sauvegarde.

    Retirez les entrées de DN et TFTP qui sont en conflit à partir du fichier. Trouvez les groupes pour des serveurs/nom/dn et des serveurs/nom/tftp et employez un éditeur de texte, tel que vi, pour les retirer.

  4. Utilisez l'utilitaire IMPORT de mcdadmin sur le serveur de sauvegarde.

    mcdadmin -c -o -i exportfile.mcd
    
    

    Vous êtes incité pour un nom d'utilisateur et mot de passe. Le nom d'utilisateur par défaut est admin et le mot de passe par défaut est changeme.

  5. Activez le Basculement, et placez les configurations principales et de sauvegarde identiquement sur les deux serveurs, par exemple :

    nrcmd> dhcp enable failover
    nrcmd> dhcp set failover-main-server=192.168.0.1
    nrcmd> dhcp set failover-backup-server=192.168.0.110
    
    
  6. Redémarrez les deux serveurs.

    nrcmd> dhcp reload
    
    

Instructions pas à pas pour la version 6.0

Remarque: Dans la version 6.0, l'utilitaire de mcdadmin est remplacé par le cnr_exim. Vous pouvez utiliser les étapes décrites pour les releases précédentes, mais vous devriez utiliser l'outil de configuration de Basculement du Web UI de Network Registrar comme décrit dans cette section.

Le Network Registrar crée des relations de paires de Basculement quand vous configurez les serveurs pour utiliser le Basculement.

Pour configurer le Basculement pour le serveur, terminez-vous ces étapes tandis que connecté au serveur DHCP principal.

Remarque: Dans cette procédure, vous devez spécifier une adresse IP du serveur principale et de sauvegarde.

  1. Sur la barre de navigation primaire, DHCP de clic.

  2. Sur la barre de navigation secondaire, le serveur DHCP de clic et les affichages de page de serveur DHCP d'éditer.

  3. À la page de serveur DHCP d'éditer, placez ces attributs :

    • Configurations de Basculement — Cliquez sur en fonction.

    • Serveur principal — Écrivez l'adresse IP du serveur DHCP principal dans les paires de Basculement.

    • Serveur de sauvegarde — Écrivez l'adresse IP du serveur DHCP de sauvegarde dans les paires de Basculement.

  4. Recevez les autres configurations de Basculement, à moins que vous ayez la raison de les changer.

  5. Le clic modifient le serveur pour sauvegarder la configuration.

  6. Sur la barre de navigation secondaire, le Basculement de clic et les affichages de page de paires de Basculement DHCP de liste.

  7. Cliquez sur le nom de paires de Basculement pour ouvrir la page de paires de Basculement DHCP d'éditer.

  8. Placez les identifiants utilisateurs pour accéder au serveur de sauvegarde, puis cliquez sur modifient le Basculement.

  9. Sur le Basculement DHCP de liste les paires paginent, cliquent sur Run, ou l'icône d'état pour voir une liste de modifications à faire avant qu'elles soient appliquées.

  10. Sur le passage/état synchronisez la page de Basculement, sélectionnez le mode précis de synchronisation, puis cliquez sur Run, ou signalez, et si vous êtes satisfait avec les résultats de l'état, cliquez sur Run.

  11. Sur le Basculement DHCP de liste les paires paginent, cliquent sur l'icône de serveurs de gestionnaire et les affichages de page de serveurs de Basculement DHCP de gérer.

  12. Cliquez sur l'icône de recharge pour recharger le serveur principal, puis rechargez le serveur de sauvegarde.

Référez-vous au guide du Web UI de Cisco Network Registrar, 6,0 pour en savoir plus.

Cas d'utilisation : Basculement simple DHCP utilisant le CLI

Travaux de ce cas d'utilisation pour la version 5.5. Il répertorie les étapes pour configurer et activer le Basculement simple DHCP sur une paire de serveurs DHCP de Network Registrar qui utilisent l'interface de ligne de commande (nrcmd) :

Remarque: Cet exemple suppose que vos portées sont déjà définies.

  1. Sur le serveur principal, définissez l'adresse IP du serveur principal, l'adresse IP du serveur de sauvegarde, et le Basculement d'enable. Vous devriez définir l'adresse IP des serveurs plutôt que le FQDN de sorte que la résolution de noms ne soit pas exigée pour que les paires de Basculement communiquent. Assumez ces le scénario :

    Main CNR server: 192.168.0.1
    Backup CNR server: 192.168.0.110 
    
    

    Placez les options comme suit :

    nrcmd> dhcp set failover-main-server=192.168.0.1
    100 Ok
    failover-main-server=192.168.0.1
    
    nrcmd> dhcp set failover-backup-server=192.168.0.110
    100 Ok
    failover-backup-server=192.168.0.110
    
    nrcmd> dhcp enable failover
    100 Ok
    failover=on
    
    
  2. Après que vous sélectionniez les trois commandes, exécutez une recharge DHCP. Vous avez déjà activé le Basculement, pour bientôt comme importations de fichier de configuration au serveur de sauvegarde et les recharges DHCP sur la sauvegarde, les serveurs principaux commencent à communiquer.

    1. Vérifiez que le Basculement configure sur le serveur principal avec la commande de getrelatedservers. Ceci vérifie l'état du serveur principal :

      nrcmd> dhcp getrelatedservers
      100 Ok
      Type Name      Address     Requests Communications localhost State Partner State 
      MAIN gateways 192.168.0.1        0 INTERRUPTED    RECOVER         --
      
      
    2. Pour exporter la configuration du serveur principal, à partir du répertoire de /opt/nwreg2/usrbin dans Solaris exécutez-vous :

      mcdadmin -x -e failoverexport.mcd 
      

      Une fois incité pour le nom d'utilisateur et mot de passe, utilisez le compte d'admin. Le nom d'utilisateur et mot de passe par défaut prédéfini dans le Network Registrar est admin/changeme.

    3. Ouvrez le fichier que vous avez exporté pour vérifier qu'il n'est pas corrompu. La première ligne des textes dans le fichier ressemble à ceci :

      # version: 1.0 
    4. Déplacez le fichier au serveur de sauvegarde et importez-le à la base de données de Network Registrar.

      # ./mcdadmin -c -o -i failoverexport.mcd
      
    5. Mettez en marche le serveur de sauvegarde.

  3. Après qu'une période diverse, qui dépend de la taille de votre déploiement de Network Registrar, le serveur synchronise. Exécutez les getrelatedservers et les sembler de sortie semblables à :

    nrcmd> dhcp getrelatedservers
    100 Ok
    Type Name      Address     Requests Communications localhost State Partner State
    MAIN gateways 192.168.0.1        0 OK             NORMAL          NORMAL 
    
    
  4. Regardez dans le fichier journal pour une déclaration semblable à ceci après que la recharge DHCP :

     06/19/2003  9:41:19 name/dhcp/1 Info Configuration 0 04092 Failover is enabled server-wide. Main server name: '192.168.0.1', backup server name: '192.168.0.110', mclt = 3600, backup-percentage = 10, dynamic-bootp-backup-percentage = 0, lease-period-factor = 150, use-safe-period: disabled, safe-period = 0.
    
  5. Tentative d'obtenir un bail. Vérifiez que la transmission entre les serveurs principaux et de sauvegarde sont dans un état normal quand vous visualisez le fichier journal, /var/nwreg2/logs/name_dhcp_1_log, sur le serveur de sauvegarde. Sur le serveur de sauvegarde, vous voyez le ce des messages dans le fichier journal name_dhcp_1_log :

    07/15/2003 10:26:29 name/dhcp/1 Info Failover 0 04666 Received DHCPDISCOVER packet but failover state of normal did not allow network '127.0.0.1' to respond to clients.  Dropping packet.
    

    Ce message déclare que l'état de Basculement entre les deux serveurs est normal et que le serveur de sauvegarde ne répond pas aux clients quand l'état de Basculement est NORMAL.

Paramètres de Basculement et leurs descriptions

Les valeurs par défaut, sont dans la colonne de paramètre. Les paramètres de Basculement sont répertoriés ici par ordr'importance.

Paramètre Description
le Basculement = a désactivé Contrôles si toutes les portées qui utilisent la configuration de Basculement pour le serveur peuvent s'engager dans le Basculement.
Basculement-principal-serveur = Le Basculement étant activé, le nom DNS du serveur principal associé avec toutes les portées où le Basculement-principal-serveur réglé de nom de portée n'est pas placé. Si ce nom DNS le résout à l'adresse IP du serveur en cours, ce serveur fonctionne en tant que serveur principal pour toutes ces portées. C'est une erreur si les noms du serveur principaux et de sauvegarde les résolvent aux adresses sur le même serveur. Spécifiez l'adresse IP plutôt que le FQDN. Facultatif, aucun par défaut.
Basculement-sauvegarde-serveur = Le Basculement étant activé, le nom DNS du serveur de sauvegarde associé avec toutes les portées si vous n'utilisiez pas l'ordre réglé de Basculement-sauvegarde-serveur de nom de portée. Si ce nom DNS le résout à l'adresse IP du serveur en cours, ce serveur fonctionne en tant que serveur de sauvegarde pour toutes ces portées. C'est une erreur si les noms du serveur principaux et de sauvegarde les résolvent aux adresses sur le même serveur. Spécifiez l'adresse IP plutôt que le FQDN. Facultatif, aucun par défaut.
Basculement-sauvegarde-pourcentage = 10 Le Basculement étant activé, le pourcentage des adresses (unleased) actuellement disponibles que le serveur principal envoie au serveur de sauvegarde pour allouer à de nouveaux clients DHCP quand le serveur principal est en panne. La valeur est seulement signicative pour le serveur principal. Facultatif, transférez 10 pour cent.
Basculement-maximum-client-pôle-temps = 60m Le Basculement étant activé, le délai d'exécution maximum de client, en quelques secondes. Le MCLT est le temps maximum qu'un serveur peut étendre le bail d'un client au delà de ce que pour être son partenaire le connaît. Vous devez définir le MCLT sur le serveur principal, qui le communique à son partenaire. Il est ignoré sur un serveur de sauvegarde.
Basculement-dynamique-BOOTP-sauvegarde-pourcentage = Quand le Basculement est activé, le pourcentage des adresses (franches) actuellement indisponibles que le serveur principal devrait envoyer au serveur de sauvegarde pour des portées réglées avec le BOOTP d'enable de nom de portée.
la Basculement-utilisation-coffre--période = a désactivé Avec le Basculement activé et le positionnement d'attribut de Basculement-utilisation-coffre--période, vous devez permettre à l'attribut de Basculement-utilisation-coffre--période de faire entrer le Network Registrar dans l'état PARTNER-DOWN automatiquement. Si vous désactivez cet attribut (le par défaut), le Network Registrar n'entre automatiquement jamais dans l'état PARTNER-DOWN. Vous devez alors utiliser la commande de setPartnerDown DHCP.
failover-safe-period=24h Avec le Basculement activé et le positionnement d'attribut de Basculement-utilisation-coffre--période, la période sûre, en quelques secondes. Vous devez le définir dans le serveur principal. La période sûre peut différer sur les serveurs principaux et de sauvegarde. Référez-vous au guide de l'utilisateur de Network Registrar, 6,0 pour en savoir plus. Facultatif, transférez 86400 secondes (24 heures).
Basculement-entassement en vrac = activé Le Basculement étant activé, contrôles si une mise à jour de grippage de Basculement (BNDUPD) contient de plusieurs mises à jour d'état de bail. Affects seulement les mises à jour d'état de bail que l'activité de DHCP Client génère. Facultatif, activé par défaut.
Basculement-bail-période-facteur = 1,50 Le Basculement étant activé, le multiple de la période désirée de bail utilisée pour mettre à jour le serveur de sauvegarde quand le serveur principal l'informe d'une nouvelle période de bail de DHCP Client.
Basculement-balayage-intervalle = 15s Le Basculement étant activé, l'intervalle de sondage des Partenaires de Basculement (en quelques secondes) confirmer la connexion réseau. Facultatif, transférez 15 secondes.
Basculement-balayage-délai d'attente = 60s Le Basculement étant activé, l'intervalle, en quelques secondes, après quoi les Partenaires de Basculement qui ne peuvent pas communiquer savent qu'ils ont perdu la connexion réseau. Facultatif, transférez 60 secondes. Généralement, vous ne devriez pas changer le Basculement-balayage-délai d'attente.
Basculement-récupérez = le « mercredi 31 décembre 17:00 1969" Le Basculement étant activé, le temps dans auquel le serveur exécute l'initialisation et entre RÉCUPÉREZ l'état. Si le serveur A s'exécute, le serveur B émet cette commande de demander l'état de serveur A. Enter le temps comme mois, (nom ou ses trois premières lettres), jour, année d'heure (24 heures) (entièrement spécifiée année ou deux derniers chiffres), tout incluse dans des guillemets ; par exemple, « 30 juin 20:00:00 2002." facultatif, par défaut zéro (0).

Vérifiez

Terminez-vous ces étapes pour s'assurer que le Basculement est activé. Les messages de log supposent que se connecter par défaut est activé.

  1. Cinglez d'un serveur à l'autre pour vérifier la Connectivité TCP/IP. Assurez-vous que les Routeurs sont configurés pour expédier des clients aux deux serveurs.

  2. Vérifiez les journaux de démarrage pour s'assurer que vous finissez par dans le mode normal.

  3. Après startup, ayez une tentative de client d'obtenir un bail.

  4. Vérifiez que le fichier journal du log name_dhcp_1_log DHCP, localisé dans /var/nwreg2/logs près de l'installation par défaut, contient des messages DHCPBNDACK ou DHCPBNDUPD de chaque serveur.

  5. Vérifiez que le fichier journal du log name_dhcp_1_log DHCP, sur le serveur de sauvegarde, situé dans /var/nwreg2/logs près de l'installation par défaut, contient les messages que le serveur de sauvegarde relâche des demandes parce que le Basculement est dans un état NORMAL.

  6. Exécutez les getrelatedservers commandent de vérifier que les états de Basculement sont NORMAUX.

    nrcmd> dhcp getrelatedservers
    100 Ok Type   Name                  Address           Requests     Communications localhost State Partner State 
    MAIN   main.test.cisco.com        192.168.1.1        0 OK             NORMAL            NORMAL 
    BACKUP backup.test.cisco.com      192.168.1.2        0 OK             NORMAL            NORMAL 
    

Dépannez

Il y a plusieurs choses que vous pouvez faire pour dépanner le Basculement simple :

  • Assurez-vous que vous avez la Connectivité bidirectionnelle entre vos serveurs principaux et de sauvegarde.

  • Vérifiez que ces paramètres sont définis globalement :

    • failover=on

    • IP address de failover-main-server= de serveur principal

    • IP address de failover-backup-server= de serveur de sauvegarde

    • failover-recover=0

  • Vérifiez que les deux serveurs ont la configuration identique.

  • Vérifiez le fichier journal name_dhcp_1_log pour toutes les erreurs.

    06/19/2003 10:54:44 name/dhcp/1 Info Failover 0 04011 Failover: as main for 192.168.0.110, the backup server NAKed a DHCPBNDUPD message about Lease: 192.168.1.140. The reason was: 'IP address not configured'.  The associated message was:  The server could not process a lease update message for IP address.

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: 46807