Conversion du serveur central surviable existant en serveur principal

Dernière mise à jour : Mar 21, 2025 |
Informations sur le prologue
Métadonnées
Mots-clés :
Suivez cette procédure pour convertir un serveur central survivable existant en un serveur principal. Par exemple, lorsque deux systèmes ou plus sont combinés en un seul système, un serveur Avaya existant peut être converti en serveur principal tandis que d'autres serveurs peuvent être convertis en serveurs de base survivables.
Avertissement :
Cette procédure a un impact sur le service. À mesure que le nouveau serveur principal sera mis en ligne, les passerelles média contrôlées par d'autres serveurs finiront par passer au nouveau serveur principal. La passerelle multimédia doit donc être réinitialisée. Si un serveur de base résilient existe, il peut être avantageux de basculer toutes les passerelles multimédias vers le serveur de base résilient avant la conversion.
  1. Sauvegardez les traductions sur le serveur pour être converties. Si le serveur principal existant est toujours en opération, effectuez une sauvegarde complète. Si le serveur principal existant n'est pas en service, déterminez l'emplacement de la dernière sauvegarde valide.
  2. Vérifiez que le serveur à convertir est déconnecté du LAN/WAN.
    INFORMATIONS SUPPLÉMENTAIRES :
    Avertissement :
    Deux serveurs principaux ne peuvent pas être connectés au réseau local/WAN simultanément.
  3. Connectez l'ordinateur portable au port de services sur le serveur que vous convertissez.
  4. Confirmez que le serveur à convertir exécute la dernière version de Communication Manager.
    1. Sur l'interface de gestion du système, cliquez sur Administration Serveur (Maintenance).
      STEP RESULT:
      L'interface d'administration du serveur est affichée.
    2. Cliquez sur Software Version sous Serveur.
      INFORMATIONS SUPPLÉMENTAIRES :
      Si le serveur ne fonctionne pas avec la dernière version de Communication Manager, mettez le serveur à jour.
  5. Si le serveur est une paire duplex, mettez le serveur de secours hors service.
  6. Exécutez cette étape pour les serveurs actifs S8300E. Dans l'interface de gestion du système, sous Configuration du serveur, cliquez sur l'option Configuration du réseau.
    1. Entrez un ID de serveur (SVID) unique dans le champ Serveur ID. Un seul SVID est requis pour un serveur unique et deux SVID uniques sont requis pour une paire de serveurs dupliqués. Cet ID doit être entre 1 et 256. Habituellement, les serveurs principaux sont réglés à SVID 1 et 2. Les intervalles de numérotation sont autorisés (10, 20, 30, . . .), mais les serveurs peuvent également être numérotés consécutivement.
      INFORMATIONS SUPPLÉMENTAIRES :
      • Cliquez sur Continuer et vérifiez les adresses IP.
    2. Sous la Configuration du serveur, cliquez sur l'option Rôle du serveur dans la marge gauche.
      INFORMATIONS SUPPLÉMENTAIRES :
      • Sélectionnez le serveur principal.
  7. Pour les serveurs dupliqués, effectuez les mêmes activités de configuration que l'étape 6 pour le serveur de secours.
  8. Installez un nouveau fichier de licence avec les réglages appropriés pour le serveur principal.
    INFORMATIONS SUPPLÉMENTAIRES :
    Le nouveau fichier de licence doit avoir les attributs suivants :
    • Enterprise Survivable Server réglé à n
    • ESS Administration réglée à y
    • Un ID de module (MID) de 1 : le MID est appelé ID de cluster (CLID) par la fonction de serveur de cœur surviable. Cette valeur est définie par le fichier de licence et ne peut pas être administrée dans Communication Manager. Chaque serveur d'une paire duplex (OEMR XL R640) a le même CLID. Un serveur principal a toujours le MID de 1.
      Le MID apparaît dans le nom de fichier de licence après la lettre m. Dans un exemple où le nom du fichier de licence du serveur principal est s66579v5m1-060214-20295.lic, le MID serait 1.
    • Un ID système (SID) : Le SID est unique à la configuration du système. Le serveur principal et tous les serveurs centraux survivables auront le même SID.
  9. La configuration du serveur entraîne l'exécution d'une réinitialisation. Il ne suffit pas d'aviser tous les processus non Communication Manager de la nouvelle configuration du serveur, y compris l'ID de cluster.
  10. À partir de l'interface de ligne de commande du serveur actif, exécutez les commandes suivantes pour notifier tous les processus des nouveaux paramètres :
    INFORMATIONS SUPPLÉMENTAIRES :
    • stop -caf
    • start -ca
  11. Pour les serveurs dupliqués, libérez l'occupation du serveur en attente à l'aide de la commande Release Server sur l'interface de gestion du système.
  12. Attendez que le fichier de licence soit synchronisé du serveur actif vers le serveur de secours. Cette vérification peut être effectuée à l'aide de la commande Linux statuslicense-v plusieurs fois jusqu'à ce que l'ID de module soit mis à jour.
  13. Une fois l'ID de module mis à jour, exécutez les commandes suivantes à partir de la ligne de commande pour informer tous les processus de la nouvelle configuration du serveur et de l'ID de module :
    INFORMATIONS SUPPLÉMENTAIRES :
    • stop -caf
    • start -ca
  14. Assurez-vous que les traductions du serveur principal correspondent aux traductions du nouveau serveur principal converti. Utilisez la commande display survivable-processor pour vérifier les traductions principales. Si les traductions ne correspondent pas, ajustez-les au besoin à l'aide de la commande Network Configuration de l'interface de gestion du système (voir l'étape 6).
  15. Supprimez les anciennes traductions ESS du serveur principal nouvellement converti à l'aide de la commande remove survivable-processor nodename, où nodename est l'ancien nom de nœud ESS.
    INFORMATIONS SUPPLÉMENTAIRES :
    Si cela n'est pas fait, le nouveau serveur principal émettra une alarme lorsque l'ancien serveur de cœur surviable ne s'enregistrera pas. Pour obtenir de plus amples renseignements sur l'administration de l'ESS, reportez-vous à la section Administration du serveur principal surviable.
  16. Une fois que les anciennes traductions ESS ont été supprimées, il est nécessaire d’aviser tous les processus Communication Manager que l’ancien identifiant de cluster n’existe plus. Utilisez les commandes suivantes pour notifier les processus Communication Manager :
    INFORMATIONS SUPPLÉMENTAIRES :
    • save trans all
    • reset sys 4
  17. Utilisez la commande list survivable-processor, display survivable-processor nodename, pour vérifier que les traductions correctes sont présentes pour tous les serveurs centraux survivables.
  18. Déconnectez l'ancien serveur principal du LAN/WAN, s'il est connecté.
  19. Connectez le nouveau serveur principal au réseau local/WAN.
  20. Sur tout serveur principal survivable existant, vérifiez que le nouveau serveur principal ou la nouvelle paire de serveurs est connectée au réseau local/WAN.
  21. À l'aide de l'interface de gestion du système, sur chaque ESS et LSP, spécifiez :
    1. Adresse(s) IP du nouveau serveur principal.
      INFORMATIONS SUPPLÉMENTAIRES :
      La modification de l'adresse du serveur principal sur le serveur central surviable ne nécessite pas de reset system 4, et elle ne le fait pas automatiquement.
      Pour obtenir de plus amples renseignements sur la configuration du serveur, reportez-vous à la section Feuilles de travail de configuration du serveur.
  22. Vérifiez que chacun des serveurs centraux résilients et des serveurs distants résilients s'enregistre auprès du serveur principal et que les traductions sont mises à jour.
    INFORMATIONS SUPPLÉMENTAIRES :
    À l'aide de la commande status ess clusters, vérifiez que le serveur principal (ce serveur) est affiché et que tous les serveurs centraux survivables s'enregistrent et que leurs traductions sont mises à jour. Répétez périodiquement la commande status ess clusters ou list survivable-processor jusqu'à ce que tous les serveurs centraux survivables s'enregistrent et soient mis à jour.
    Remarque :
    Un serveur principal actif connaît son propre état et celui de tous les serveurs centraux survivables qui se sont inscrits auprès de lui. Pendant un certain temps (en minutes), une fois que tous les serveurs sont installés et configurés, il peut y avoir une divergence entre l'état affiché par le serveur principal et les serveurs centraux survivables.
  23. Si aucune commande save trans all n'a été effectuée à l'étape 16, faites-le maintenant. Sur le serveur principal, exécutez la commande save translation all pour synchroniser les traductions entre le nouveau serveur principal, les serveurs distants résilients et les serveurs centraux résilients.
  24. Si aucune commande reset system 4 n'a été effectuée dans 16, faites-le maintenant. À partir du serveur principal, exécutez la commande reset system 4.
Liens connexes
Fichiers de licence
Administration du serveur central résilientPréalables pour l'administration d'un serveur central surviable sur le serveur principalÉcran du processeur surviableAdministration de la page 1 de l'écran du Processeur SurvivableAdministration de la page deux de l’écran du processeur surviableAdministration de la page 3 de l'écran Survivable ProcessorAdministration de la page quatre de l’écran du processeur surviableAffectation d’une communauté au réseau portuaireVérification de l'administration sur le serveur principal
Feuilles de configuration du serveurParamètres réseauParamètres de configuration du réseauParamètres de duplicationAjouter une connexion