Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Cluster over WAN for ICM version 8

Hi All;

Now I built side A (RGR, HDS, CVP PG and CUCM PG) and I got a new servers to build side B. I am going to install the ICM on side B. Regarding to the databases (HDS, AW, logger), just I have to create them on side B, and connect side B and it will synch with side A? Or there is something else I have to do?

Side A and side B linked by WAN, but it is a reliable fiber link of 1 Gbps bandwidth and very stable.

Thanks for the help in advance.

Regards

Bilal

3 ACCEPTED SOLUTIONS

Accepted Solutions
Green

Cluster over WAN for ICM version 8

Logger B will synch with logger A.

The HDS on side B will try to catch up, but given the retention time of a logger (typically 14 days) it may never be the same as the HDS on side A.

The AW is built and destroyed on demand - it's always accurate.

Regards,

Geoff

Green

Cluster over WAN for ICM version 8

The old data that before the 14 days, this already migrated from logger to HDS.

The really old data has migrated from Logger A to its HDS. But it's gone from Logger B so it can't be on its HDS.

Why did you take so long to bring up the second HDS?

It will synchronize either way - you should have tested this by now.

Test 1: LoggerA, RouterA, RouterB, LoggerB

Test 2: LoggerB, RouterB, RouterA, LoggerA

Regards,

Geoff

Green

Cluster over WAN for ICM version 8

This can be fixed. I am reluctant to give advice on the forum.

This came up once before

https://supportforums.cisco.com/thread/271063

My advice there was to open a TAC case. They will help you and this must be done correctly.

Regards,

Geoff

21 REPLIES
Green

Cluster over WAN for ICM version 8

Logger B will synch with logger A.

The HDS on side B will try to catch up, but given the retention time of a logger (typically 14 days) it may never be the same as the HDS on side A.

The AW is built and destroyed on demand - it's always accurate.

Regards,

Geoff

New Member

Cluster over WAN for ICM version 8

Dear Geoff;

The old data that before the 14 days, this already migrated from logger to HDS. So, how HDS of side B will get this old one?

About B synch A, is it always B synch A, or it is because A already live so B will synch A? In other words, if B was live and A joined, so A will synch B?

Regards

Bilal

Green

Cluster over WAN for ICM version 8

The old data that before the 14 days, this already migrated from logger to HDS.

The really old data has migrated from Logger A to its HDS. But it's gone from Logger B so it can't be on its HDS.

Why did you take so long to bring up the second HDS?

It will synchronize either way - you should have tested this by now.

Test 1: LoggerA, RouterA, RouterB, LoggerB

Test 2: LoggerB, RouterB, RouterA, LoggerA

Regards,

Geoff

New Member

Cluster over WAN for ICM version 8

Dear Geoff;

What happened actually that we are building a disaster recovery to be over WAN. So we started our work in the site that will be a disaster recovery for the production site and we built one leg of the IPCC in this Disaster Recovery site.

In the Disaster Recovery site (DR), we built first leg (site A, CVP Call Server, CVP VXML, CUCM Publisher, CUCM Subscriber) and it is running well.

Coming back now to the main site, I got a fresh new 3 servers, so I decided to use them for RGRB, CMPGB, VRUPGB and will synch them with what I did in the DR (which has site A), again until now I am not touching the production servers.

All what I need now is to be check that the cluster over WAN will work fine, so I installed and configured RGRB, CMPRGB and VRUPGB.

My questions here:

1) For the Logical, Physical and Peripheral IDs in side B (CMPGB and VRUPGB), I have to use the same one in side A, correct?

2) CG and CTIOS Server, same ports that I used in side A I am going to use it for side B?

3) About HDS: I can backup/restore from HDS at side A to HDS at side B?

Any special advise for this scenario?

Fully thanks for kindly support.

Regards

Bilal

New Member

Cluster over WAN for ICM version 8

Dear Geoff;

What happened actually that we are building a disaster recovery to be over WAN. So we started our work in the site that will be a disaster recovery for the production site and we built one leg of the IPCC in this Disaster Recovery site.

In the Disaster Recovery site (DR), we built first leg (site A, CVP Call Server, CVP VXML, CUCM Publisher, CUCM Subscriber) and it is running well.

Coming back now to the main site, I got a fresh new 3 servers, so I decided to use them for RGRB, CMPGB, VRUPGB and will synch them with what I did in the DR (which has site A), again until now I am not touching the production servers.

All what I need now is to be check that the cluster over WAN will work fine, so I installed and configured RGRB, CMPRGB and VRUPGB.

My questions here:

1) For the Logical, Physical and Peripheral IDs in side B (CMPGB and VRUPGB), I have to use the same one in side A, correct?

2) CG and CTIOS Server, same ports that I used in side A I am going to use it for side B?

3) About HDS: I can backup/restore from HDS at side A to HDS at side B?

Any special advise for this scenario?

Fully thanks for kindly support.

Regards

Bilal

Green

Cluster over WAN for ICM version 8

1. Yes, of course.

2. Normally, CG1A listens on 42027 and GC1B listens on 43027. CTIOS listens to the same port on each side for the clients - and the cross-connection between each.

3. Not normally, but there is a document in the Wiki about doing  that.

https://supportforums.cisco.com/docs/DOC-15290

9. From the HDS2 server, import HDS1 database over to HDS2 (use the database copy from LoggerB's local machine).

10.  Run the following query against HDS2 database.

truncate table Recovery   

11.  Start HDS2 services.  Allow enough time for data to get replicated (Logger -> HDS).

12.  At the end of this exercise, verify BOTH max recovery keys and max DateTime match between LoggerA, HDS1, LoggerB, HDS2.

        SQL Command:  max(DateTime), and max (RecoveryKey).

Regards,

Geoff

New Member

Cluster over WAN for ICM version 8

Dear Geoff;

I am afraid that I am facing the problem because I created the sideB database fresh, so it is not able to synch and that causing a problem related to the LastUpdateKey as I will explain below, but how I can overcome this?

Now I configured RGRB, CMPGB and CVPPGB and all is connected and I started services.

Let us talk about RGRB and RGRA:

Actually when I installed RGRB, I created a database using ICMdba, so  sideB database is empty.

At the Router A mdsproc, I saw the message that:

Communication with peer Synchonizer established.

Synchonizer switching to active duplex operation.

Logger A config logger is giving that that (and this is maybe because I created a fresh database in side B):

Synchronization failed because the LastUpdateKey on sideB is not present in the sideA Config Message Log.

As shown in the below picture:

Also at RGRB, I am noticing that LoggerB configlogger is keep restarting and its snap shot as following:

Also, at RGRB mdproc I see the below message:

Regards

Bilal

Green

Cluster over WAN for ICM version 8

This can be fixed. I am reluctant to give advice on the forum.

This came up once before

https://supportforums.cisco.com/thread/271063

My advice there was to open a TAC case. They will help you and this must be done correctly.

Regards,

Geoff

New Member

Cluster over WAN for ICM version 8

Dear Geoff;

I followed the link and it is fixed at RGRB.

Now I am facing a problem with CUCM PG and CVP PG, actually it is not becoming UP and giving that network name is no longer available.

Could be because I have until now one CVP Call Server and One Publisher and One Subscriber so both side (A and B) are connecting to the same CVP Call Server and same Subscriber and using same Peripheral ID and same Physical ID and same Logical ID, and same PIM number?

Regards

Bilal

New Member

Cluster over WAN for ICM version 8

Dear Geoff;

This is to confirm that it is working, but it worked when I stop services at side A.

Actually VRU PG at side B which is configured to connect with the same CVP Call Server that side A is connecting, when side A is up and I am trying to start VRU PG at side B, then a failure happen and I see Windows OS message that it is going to restart after spcific amount of minutes and seconds.

Could this because they are both (VRU PG A and B) are connected to the same CVP Call Server? But when side A down, and I start side B, then no problem and things are going fine.

I do not face the restart problem at CUCM PG of side B if side A is UP also, but services are not becoming UP and it is giving that specific network name is no longer available as shown in the above picture in the previous post. Is it normal thing? Or because connected to the same CUCM?

Regards

Bilal

Green

Cluster over WAN for ICM version 8

Could this because they are both (VRU PG A and B) are connected to the same CVP Call Server?

That's exactly how it's supposed to be.

Both A and B connect to the CVP Call Server which is listening on port 5000. Of course, they don't try to connect at the same time - the PIM is overseen by the PG process, and through the MDS they talk to each other, and they know which side should really bind to the CVP Call Server (the active side).

JTAPI is different in a production environment - where the JTAPI gateway on PIM A talks to the CTI Manager on 1 subscriber; and the JTAPI gateway on PIM B talks to the CTI Manager on a different subscriber; the PG controls the active side from above.

Regards,

Geoff

New Member

Cluster over WAN for ICM version 8

Is it possible to start VRU PG at side A and side B at the sametime and trying to connect to the same CVP Call Server?

Because if side A is active and if started VRU PG at side B, then the server give Windows message that it will restart after a specific minutes and seconds and ofcourse the service VRU PIM at side B will be stopped. That is why I am asking if I can have VRU PIM at side A and VRU PIM at side B to be both connected to the same CVP Call Server at port 5000, or that is not possible? If it is possible, so why this is happening with me (the restart)?

Currently if I need to start VRU PIM at side B, I have to stop the VRU PIM at side A, otherwise the restart message will appear and the server will be restarted automatically after the specific time. This restart message remind me in the viruses that we show it sometime and it is restarting the machine

Thanks for the help in advance.

Regards

Bilal

Green

Cluster over WAN for ICM version 8

You must have the PIM for the VRU PG on side A connect to the Call Server on port 5000 and the PIM on side B connect to the same Call Server on the same port, but only one will connect. That will be controlled by whichever PG is designated as the active side. If you have them both running, and bounce the connected PIM, the other one will bind to the port.

If you get the message that it is going to stop the server and restart it, type "stopshut" at a command prompt or in the "Run" box and it will stop the shutdown/restart process.

The fact that you are getting this means that something is not set up properly in the configuration of the PGs. Go over how you have set these up - look at the public and private connections, because you have something amiss.

Regards,

Geoff

New Member

Cluster over WAN for ICM version 8

Dear Geoff;

Regarding to the CUCM PGs, if one side is active then I see the other side processes to be IDLE and the mdsproc to be OO. Is that normal or I have to see standby? But at the same time, I tried to stop the services for CUCM PG side A then I found that CUCM PG side B become active, also I tried to stop CUCM PG side B and I found that CUCM PG side A become active. But standby word I do not see it in the processes but I see Active and Idle while the mdsproc at the Idle side is OO (out of service) and at the Active side is InSvr. Is that fine?

About the VRU PG, I checked the configuration and the IP addresses for the Visible and Private for the low and high IPs and every thing is fine, also if VRU PG side A service is stopped then VRU PG side B can start and work fine and if VRU PG at side B is stopped then VRU PG side A can start and work fine. The only problem that when both VRU PGs of both sides (A and B) will be started at the sametime (and they are configured to connect to the same CVP Call Server), then the problem happens and the restart message appear. One thing I tried to change it in the configuration is the Peripheral ID (not the logical and not the physical), so I tried to use same Peripheral ID for VRU PG side B and A, also I tried to use another Peripheral ID for side B than this for side A (already there are 4 Peripheral IDs under the same VRU PG configured in the configuration manager, because in the production there are 4 CVP Call Servers). But the same problem is happening.

I investigated the problem of the VRU PG and I discovered the following scenario is happening:

If I started VRU side B (for example) and services become Active, then when I am starting VRU side A, the vrupim process is getting an error (very fast, I was not able to take snap shot) and it is stopping and the service disappear, and then an error at the mdsproc is appearing and it is saying that there was an error in the vru process and it is stopped, and then the services are stopping and the restart message appears. So, the first failing process is the vrupim (and this process should not be related to the other side configuration, am correct?).

Thanks for the help.

Regards

Bilal

Green

Cluster over WAN for ICM version 8

By the way, looking at the screen shot above, it's indicating that the PG is not in the same timezone as the central controller. All your nodes should be in the same timezone.

One thing I tried to change it in the configuration is the Peripheral ID (not the logical and not the physical), so I tried to use same Peripheral ID for VRU PG side B and A, also I tried to use another Peripheral ID for side B than this for side A (already there are 4 Peripheral IDs under the same VRU PG configured in the configuration manager, because in the production there are 4 CVP Call Servers).

The IDs must be the same on A and B. In fact the exported registry of PGA and PGB will be near identical. I would compare with a registry diff tool to see if there is a mistake.

What about if you do this? Shutdown the Call Server so neither PIM can bind. Now start them up - shutdown each in turn, bring them back up, change order and so on. Is the MDS OK?

Now start the Call Server. If this causes a problem, get the trace using dumplog and show us.

From what you are saying it appears that there is a problem with MDS - and this means the config is not right.

Is the binding order on each PG correct - public before private?

Regards,

Geoff

New Member

Cluster over WAN for ICM version 8

Dear Geoff;

The Time Zone fixed as I found a difference time zone at CUCM PG at side A. Thanks.

I did serverals attempts for VRU PG A and B while CVP Call Server is down but the same result (the VRU PG that start firstly is going fine while the second one is causing the error and the restart message).

At the RGR, I see the below picture:

About the installation at the PGs, I reviewed the values that I gave for VRU PGA and VRU PGB and they are the same and the public IPs, private IPs, high value and low value IPs are all correct. Also the Peripheral IDs and Logical and Physical are both same and correct. At side A, I determined it is side A and at side B I determined it is side B and I selected to be duplex (in both sides).

About ur sentence:

Is the binding order on each PG correct - public before private?

* I did not get what do u mean exactly by it. But if you mean when I did the installation for the PGs, when it ask for the IPs for the private and public, actually the menu it self is asking for private before public as shown below:

One thing, is the configuration at the Configuration Manager (at the AW), what could be the configuration that causing this problem and it is effecting? I am attaching also below a snap shot.

At the RGR, I enabled at the registry the PG03 and PG02 and PG01 (where PG01 for CUCM, PG02 for VRU and PG03 for MR), and the only thing that I have a problem with the VRU PG

One question please: the side that will not be active, should I see in the services IDLE or Standby?

Regards

Bilal

Green

Re: Cluster over WAN for ICM version 8

I did serverals attempts for VRU PG A and B while CVP Call Server is down but the same result (the VRU PG that start firstly is going fine while the second one is causing the error and the restart message).

OK then. We know it has nothing to do with the Call Server. You need to solve this problem.

By the "binding order" I mean the two NICs on the server itself. Examine the network binding order in Windows and make sure, on both PG A and PG B that the public NIC is first in the binding order.

The MDS process is going to provide the best info about what is wrong. Increase the trace to 0xffff and run the test again and gather the trace. Examine the trace and you will see the problem - for sure. Once you fix it, remember to put the trace back.

The Router is trying to tell you what's wrong. It can't see that PGB at the address 172.30.9.8 specified.

Regards,

Geoff

New Member

Re: Cluster over WAN for ICM version 8

Dear Geoff;

Still the problem the same, kindly find below the result of ipconfig /all and how it look like (same thing on both VRU PGs):

Also this is the MDS log at both VRU PGs:

By the way, I need to post rar files contains the snap shot of the configuration for the VRUPGA and VRUPGB, but not able to know how to insert this rar files.

Regards

Bilal

New Member

Re: Cluster over WAN for ICM version 8

I am also adding a snap shots of the configurations that I did for VRUPGA and VRUPGB to see if there is anything wrong:

VRUPG - Side A:

VRUPG - Side B:

Configuration at the configuration manager:

Registry at the RGR and RGRB:

PG01, PG02 and PG03 are enabled, and only the PG3Enabled is enabled.

I hope that those can help to discover the problem reason.

Regards

Bilal

New Member

Re: Cluster over WAN for ICM version 8

Any help?

I need to say that the gatekeeper license is terminated. But I am assuming that this is not the reason for the problem because one VRU PG side is able to work fine but both sides togethor is causing the problem. Also, as we said that if the CVP is stopped, the problem should not be related.

So, what could be the reason?

Regards

Bilal

New Member

Re: Cluster over WAN for ICM version 8

Dear Geoff;

The problem resolved. One side was patched and ther side was not patched. Sorry for this.

But I would like to know, is it really important that visible IP to be before private IP when doing ipconfig /all? Why?

Regards

Bilal

1543
Views
0
Helpful
21
Replies
CreatePlease to create content