Layer7 API Management

I am using the software version of API Gateway v8.4 and API Portal V35. (Form Factor is Software)

Environment as below:-

------------------------
Server1: API Gateway v8.4
Server2: API Portal v35
------------------------

I am supposed to build the similar environment without changing hostnames, certificates on new servers. The only difference is IP address of new servers will differ.
In /etc/hosts, server names, URL names, hostnames everything will be similar.

------------------------
Server3: API Gateway v8.3
Server4: API Portal v35
------------------------

From Portal perspective, I am doing the backup on Server2 and restoring on Server4. All looks good here.

From Gateway perspective, I am doing the backup on Server1 (image backup with -ia flag) and restoring on new Server3 with ssgrestore.sh.
As per Server3 Gateway, just installed SSG RPM and installed the MySQL DB. Then using ssgrestore.sh to import the server1 gateway configs in Server3.

------------------------
Server1 Backup Command: #./ssgbackup.sh -image backup.zip -ia -v –halt
Server3 Restore Command: #./ssgrestore.sh -image /opt/SecureSpan/Gateway/config/backup/images/20170923050756_backup.zip -dbu username -dbp ****** –v –halt
------------------------

I was able to successfully restore the gateway on Server3 and able to test all the functional use cases are working as expected.

Even though everything is working as expected, one thing is not clear for is about "cluster_info" table details.

This table during the restore process got all details from Server1.

In that columns named "address", "esm_address", I have manually updated the new Server3 IP Address. But, was not sure about "multicast_address" value.

------------------------
Can I ignore this "multicast_address" field and leave as is?
Will that create impact to my old cluster (Server1) or new cluster (Server3) gateways by any chance?
------------------------

BTW, I didn't use ssgmigrate.sh for this by referring the documentation "Migration Tip" in
------------------------
https://docops.ca.com/ca-api-gateway/8-4/en/administer-the-gateway/migrate-using-ssgmigrate-sh-utility

"Note: If your goal is to initialize a new cluster using a backup image, use the Restore Utility (ssgrestore.sh) instead. For more information, see Restore Gateways."
------------------------

Other than "multicast_address" in "cluster_info" table as a clarification, on our new cluster, everything is working as expected.
BTW for an additional information, I am building this new parallel equivalent environment and then upgrade that gateway to V9.2 CR05 release.

Hello,

We have seen this in the past before. Specifically around multicast_address' being the same on both nodes in the cluster_info table. There are a few things that could cause this:

1) The servers have come up at the same time
2) The servers can't communicate at time of boot

The following procedure should fix the issue:

1) Stop both database nodes in the cluster. It is very important that nothing is writing to the database.

2) Delete the contents of the cluster_config table. This table is written to dynamically by the nodes so the content will be auto regenerated.

# mysql ssg -e "delete from cluster_info"

3) Start ONLY the Primary node and wait a few minutes. This will regenerate the cluster_info contents which include the multicast details.

4) Start the Secondary node.

I'm not sure there is much you can do, other than if you're rebooting them manually give them a staggered start.

I hope this helps!

-Alec Daniello

APIM Support

Thanks, Alec !!

Multicast address got updated with the new one with your suggested steps. Can you please let me know, whether the approach taken by me is appropriate, or do I need to include something else in order to accomplish a parallel which replica of an existing environment.

Regards,

Ankush

Dear Ankush,

Just to remind you that the backup/restore utility is designed for backup/restore on the same server. It's not a good tool for clone, or migration.

Regards,

Mark

Hi, Mark

Thanks for the input !!

Appreciate it  

Thanks,

Ankush

Hello,

Just to correct my last update, we have seen this in the past when the multicast_address is NOT the same. I apologize for the confusion. Again the steps below will help you ensure the cluster_info table is configured correctly:

https://support.ca.com/us/knowledge-base-articles.TEC0000001371.html

-Alec Daniello

APIM Support