Hoge beschikbaarheid van IM en Presence Server configureren

Inleiding

Dit document beschrijft hoe de Hoge beschikbaarheid (ook bekend als Redundantie) van Instant Message and Presence (IM&P) in een ondernemings-IM- en Presence-omgeving werkt en hoe u problemen kunt oplossen.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Cisco Unified IM&P
• Cisco Jabber-clients

Gebruikte componenten

• Cisco Unified IM&P 10.0 en hoger.
• Cisco Jabber-clients 9.6 en hoger.

De informatie in dit document is gemaakt van de onderdelen in een specifieke labomgeving. Alle onderdelen die in dit document werden gebruikt, werden gewist met een gewalste (standaard) configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

IM and Presence hoge beschikbaarheid (HA)

De IM and Presence Service Server biedt een hoge beschikbaarheid of redundantie in de vorm van logische servergroepen in de CUCM-configuratie. Deze configuratie wordt doorgegeven aan IM and Presence en vervolgens gebruikt om redundantie toe te staan in geval van een IM and Presence Service of serverstoring.  Wanneer een HA-event plaatsvindt, worden de sessies van de eindgebruiker verplaatst van de mislukte server naar de back-up.  Wanneer de server weer normaal wordt, worden de gebruikerssessies automatisch of handmatig door de beheerder teruggezet.  

Configuratie van redundantie

De redundantie groep is het logische serverpaar dat de toewijzing van een server aan het IM en Presence subcluster evenals de configuratie voor HA mogelijk maakt.  U hebt toegang tot dit gedeelte van de configuratie als volgt op de webpagina van de CUCM-server.

Systeem > Presence-redundantie

Wanneer de beheerder de IM&P Publisher aan het Systeem > de configuratie van de Server op CUCM toevoegt en de IM&P server wordt opgeslagen, wordt de groep DefaultCUPSubCluster redundantie gecreëerd met de daaraan toegewezen uitgever.  

Indien gemaakt, ziet de Redundantie Group er als volgt uit:

Deze Redundantion Group vertaalt zich in het IM and Presence subcluster. In de huidige staat van de configuratie van de Redundancy Group in CUCM zou deze er zo uitzien als in de webpagina IM and Presence Cluster Topology:

We zien dat de IM&P uitgever wordt toegewezen aan de DefaultCUPSubcluster en dat is de Subscriber server niet.  Dit komt doordat de IM&P Subscriber server niet is toegewezen aan de Redundantie Group in de CUCM-configuratie.

Toewijzen de Subscriber aan de Redundantiegroep:

Als u de Subscriber Server aan de Redundantion Group wilt toewijzen, selecteert u simpelweg de abonneeserver uit de vervolgkeuzelijst en vervolgens slaat u de configuratie-wijziging op.

Nadat de IM&P-abonnee is toegevoegd aan de groep Redundantie:

U ziet na de toevoeging van het secundaire knooppunt (de abonnee) dat de optie Hoge beschikbaarheid kan worden geselecteerd. Om hoge beschikbaarheid te activeren moeten we simpelweg het selectieteken Hoge beschikbaarheid inschakelen en de configuratie wijzigen.

Als hoge beschikbaarheid is ingeschakeld:

De pagina verfrist vervolgens de status en de reden van de server.  Wanneer de server in een initialisatietoestand verkeert, betekent dit dat de twee servers kunnen communiceren.  De servers zouden dan de servicestatus controleren voordat de staat overgaat op een normale toestand.  Als de twee servers met elkaar kunnen verbinden en alle gecontroleerde diensten aan beide staan, zouden we dan een normale toestand krijgen. Dit betekent dat alle gecontroleerde diensten actief zijn op de IM&P servers.

Status normale redundantie:

Normal-Normal High Availability State in de IM&P Topologie pagina:

Gecontroleerde IM en Presence Services

Aangezien u verschillende implementatiemodellen kunt hebben: IM Only, IM met SIP/XMPP Federatie, IM met Naleving, IM met Blijvende Chatfunctie, Controle van de afstandsbediening, etc., van welke van deze processen om te controleren is dynamisch. Standaard worden deze items altijd gemonitord als HA is ingeschakeld:

IDS-database

Presence Engine (indien geactiveerd)

XCP router

De Server recovery Manager controleert om te bepalen of de conformiteit (Message Archiver), persisterende chatting (Text Conference Manager), SIP-federatie (SIP Federation Connection Manager), XMPP-federatie (XMPP Federation Connection Manager) is ingesteld (en geactiveerd).  

Als ze zowel zijn ingesteld als geactiveerd, controleert de Server Restore Manager (SRM) ook deze services.

Voorzichtig: Voordat u verdergaat met het opnieuw opstarten van een of meer van de gemonitorde services, dient u de hoge beschikbaarheid uit te schakelen van de Presence Redundancy Group op de CUCM-server. Dit geldt ook wanneer een herstart van een of meer van de IM&P-knooppunten wordt uitgevoerd.

Gebruiker failover-proces

Wanneer een failover plaatsvindt (automatisch of handmatig) is het belangrijkste te onthouden punt dat de gebruikersaccount niet van de ene server naar de andere wordt verplaatst, maar alleen de gebruikerssessie in Presence Engine wordt verplaatst.  In pre-10 versies van IM and Presence, werd de gebruikershandleiding van de ene server naar de andere verplaatst.  Deze gebruikersstap was erg duur voor serverbronnen en werd toegevoegd aan de lading op de server.  In 10.X en later blijft de gebruiker gehuisvest op de server waaraan ze zijn toegewezen, en wordt de eindgebruikerssessie in de Presence Engine verplaatst van het mislukte knooppunt naar het functionele knooppunt.  De gebruiker hoeft Jabber niet te verlaten en opnieuw in te loggen wanneer de verandering met Server Restore Manager (SRM) gebeurt.

Jabber-client opnieuw opgeven Timer

Om de gebruikerssessie volledig actief te laten worden op het secundaire IM&P-knooppunt na een failover-gebeurtenis, moet de gebruiker proberen in te loggen op die server via SOAP (Client Profile Agent).  Dit gebeurt automatisch met het eenmalige wachtwoord dat uit de IMDB-database wordt doorgegeven. Aangezien logins extreem duur zijn voor resources op de IM and Presence server, moet er een manier zijn om log ins te gooien wanneer er een failover-gebeurtenis optreedt.  Met dit filter of de buffer kunnen alle gebruikers inloggen op het secundaire knooppunt zonder dat de service wordt onderbroken voor gebruikers op het secundaire knooppunt.  De mechanismen die worden gebruikt om het inloggen van gebruikers te beperken, zijn de serviceparameters voor SRM-server (Client Re-Login Low Limit-Server herstelt).  

Clientherkenning lagere limiet - de parameter die de minimale hoeveelheid tijd (in seconden) definieert die de Jabber-client wacht voordat de client inlogt op de secundaire server in het geval van een HA-gebeurtenis.

Client Re-Login Upper Limit - de parameter die de maximale hoeveelheid tijd (in seconden) definieert die de Jabber client wacht voordat de client inlogt op de secondaire server in het geval van een HA-gebeurtenis.

De Jabber client ontvangt deze parameters bij inloggen naar de server en slaat de waarden voor toekomstig gebruik op.  Wanneer we een HA-event ontvangen van de IM&P server kiest de client een willekeurig aantal seconden tussen de bovenste en onderste limieten en wacht dan die hoeveelheid tijd voordat de Jabber-client inlogt naar het secundaire evenement.  Zodra de timer verlopen is, probeert de client het loggen van de SOAP naar het secundaire knooppunt.

IM- en Presence-backtypes

Als er een failover is, moet er een back-up van de gebruiker zijn wanneer de service op de problematische server wordt hersteld.  Er zijn twee typen serverback:

Handmatige back-up

Handmatige back-up (standaardconfiguratie voor Server Restore Manager) vindt plaats wanneer de service is hersteld en de redundantie-groep de knop Fallback toestaat. Wanneer deze knop is geselecteerd, worden de gebruikerssessies die naar het secundaire knooppunt zijn verplaatst, naar het gestartde knooppunt teruggebracht. De Jabber-client gebruikt dan het opnieuw inloggen op de boven- en onderste limiet voor de back-up.

automatische back-up

Automatische back-up vindt plaats wanneer de server de services controleert en de service voor serverherstel (SRM) automatisch gebruikers terugkoppelen naar hun gestartde knooppunten. De sleutel in deze configuratie is dat de service Server Restore Manager (SRM) 30 minuten wacht op een mislukte service-/server om actief te blijven voordat een automatische back-up wordt gestart.  Zodra deze uptime van 30 minuten is ingesteld worden de gebruikerssessies verplaatst naar hun gestartde knooppunten. De Jabber-client gebruikt vervolgens het opnieuw loggen van de bovenste en onderste limieten voor de back-up. 

Automatische back-up is niet de standaardconfiguratie, maar kan worden ingeschakeld.  Om automatische back-up mogelijk te maken, wijzigt u de automatische back-upparameter in de Service parameters voor serverherstel in waarde True.

Problemen oplossen

Deze sectie verschaft de informatie die u kunt gebruiken om problemen met uw configuratie op te lossen.

Wanneer u hoge beschikbaarheid voor de oplossing van problemen op de IM&P Service Server wilt oplossen, zijn er twee belangrijke timers die u in overweging moet houden.

• De uitwisseling van servers 4 houdt elke 60 seconden bij, als er na de 60 seconden geen respons is, is de Cisco Service Restore Manager (SRM) van mening dat het niet-reagerende knooppunt off-line is gegaan en leidt tot een Fail over opdracht. Zoals het volgende fragment laat zien, kwam de laatste hartslag 62 seconden geleden voor.

2021-05-13 02:48:48,244 INFO[HS]rsrm.RsrmHeartBeatHandler - RsrmHeartBeatHandler: peer down, time since last heartbeat[s]= 62
2021-05-13 02:48:48,244 INFO [HS] rsrm.RsrmAutomaticFallback - RsrmAutomaticFallback: peer states vector changed to [Normal,Running in Backup Mode]

Tip: Voor dit scenario, als u wat vertraging in uw netwerk hebt gevonden, wordt het aanbevolen om de timer voor de hartslag te verhogen van 60 tot 90 seconden.
Navigeren in naar CUCM Management-webpagina > Systeem > Configuratiescherm voor services > Selecteren van de IM&P Server > Selecteer Cisco Restore Manager Instellingen >

• De IM&P Subscriber server wacht 90 seconden, als ze detecteert dat een of meer van de gemonitorde services omlaag zijn, neemt de Subscriber server over.

Vastlegging voor probleemoplossing

• Server Recover Manager (SRM) loggen van voor en na de overnameverkomst (debug level indien mogelijk)
• De output van de opdracht via IM&P opdrachtregel interface run sql selecteert * van bedrijf esubcluster
  • De Enterprise ubcluster-tabel in IM&P-instellingen voor de configuratie van de Redundantiegroep
• De uitvoer van de opdracht via IM&P opdrachtregel-interface Sql selecteren * uit een ondernemer
  • In de tabel enterprisenode worden de knoopinformatie en subclustertoewijzing van het knooppunt weergegeven
• Als de mislukte overwinning is geproduceerd door een dienst die wordt gestopt, verzamel:
  • Logboeken van het kijksysteem
  • Toepassingslogboeken voor de evenementenviewer
  • Logt van de service die wordt gestopt.