Dans l'architecture de la passerelle d'aujourd'hui, les passerelles s'inscrivent auprès d'un contrôleur d'appels principal; cependant, l'interface IP par laquelle la passerelle s'inscrit est une interface procr dans le cas où le contrôleur d'appels est une série de serveurs dupliqués ou des serveurs pris en charge (par l'interface Ethernet du processeur). Pour les serveurs pris en charge, voir Description et référence du matériel Avaya Aura® Communication Manager.

La fonction Survivable Core Server offre une résilience aux passerelles et aux serveurs multimédias. À l'aide de la fonctionnalité Survivable Core Server, les serveurs de sauvegarde peuvent être placés à divers emplacements dans le réseau du client. Les serveurs de sauvegarde fournissent un service aux réseaux de ports dans le cas où le serveur pris en charge ou la paire de serveurs de série dupliquée tombe en panne, ou si la connectivité au serveur principal Communication Manager est perdue. Les serveurs de base surviables peuvent être des serveurs pris en charge ou des serveurs de série dupliqués et offrir une fonctionnalité Communication Manager complète lorsqu'ils sont en mode surviable, à condition qu'il existe une connectivité suffisante à d'autres composants Avaya (par exemple, les terminaux, les passerelles et les serveurs de messagerie).

Lorsque vous concevez un réseau pour prendre en charge les serveurs de cœur résilients, tenez compte des éléments suivants :

• Les serveurs de base surviables s'inscrivent au(x) serveur(s) principal(aux) par le biais d'un protocole. Chaque serveur de base survivable doit être en mesure de communiquer avec un procr pour télécharger les traductions.

La passerelle ne peut pas faire la distinction entre l'inscription par le biais d'une PROCR ou l'inscription directe à un serveur. Avant Communication Manager 3.0, sans serveurs de cœur survivables, si une passerelle s'enregistrait avec succès avec une adresse IP de contrôleur d'appel principal, la passerelle était correctement enregistrée avec le contrôleur d'appel principal. Cependant, dans Communication Manager 3.0 et les versions ultérieures, lorsqu'une passerelle termine un enregistrement réussi par une adresse IP définie comme adresse de contrôleur d'appel principal, si cette adresse est une procr, la passerelle peut ne pas être enregistrée auprès du véritable contrôleur d'appel principal. Le réseau d'accès qui héberge la procr peut être sous le contrôle d'un Serveur Principal Surviable, mais la passerelle ne saura pas qu'elle est enregistrée auprès d'un Serveur Principal Surviable.

Lorsque le réseau d’accès traditionnel revient au contrôleur d’appel principal, la passerelle perd sa liaison H.248 et l’algorithme de récupération de perte de liaison s’active, ce qui devrait suffire. La fonction de retour automatique au serveur principal ne s'active que si la passerelle abandonne la connexion et s'inscrit auprès d'un serveur distant survivable. La migration des serveurs de base survivables ne doit avoir lieu que si le réseau de ports est raisonnablement certain de retourner au contrôleur d'appels principal, de sorte que la passerelle retournerait simplement à la même interface procr. Désormais, lorsque la passerelle retourne à la même interface procr, la fonction de récupération de perte de liaison effectue un audit contextuel avec le contrôleur principal et apprend que le contrôleur d'appel principal n'est pas au courant de la passerelle. Dans ce cas, le contrôleur émet une demande de redémarrage à chaud à la passerelle, ou un comportement potentiellement différent si la préservation de la connexion est active en même temps. La fonction de retour automatique n'est pas affectée par les serveurs de base résilients.

Pour obtenir de plus amples renseignements sur les serveurs centraux survivables, reportez-vous à la section intitulée Options survivables Avaya Aura® Communication Manager.