Developer portal 3.X with multiple custers

[naiam02]

Hi Team,

 

What is best approach to support 6 API gateways at 9.x versions with a single developer portal.

 

We have a customer at present who is running 2 Older SOA gateway nodes with one Dev portal 3.x. Customer wants to add 4 more instances with existing SOA gateway nodes making it 6. Customer is not keen on migrating to Dev portal 4.x versions .

 

What is the best approach without impacting performance

 

1. Adding all instances to one cluster and spread the nodes of  the cluster across 3 different data centers
2. Configure replication across all 3 clusters and let portal be pointing to the same cluster as it is now.

[Seiji Moriyama]

Hello,

 

I'm afraid that it isn't a simple decision to make a six node cluster or three two node clusters (or two three node clusters).
If the current two node cluster has to process more traffic in future and it has no room to accept more traffic, you may need to add another node to the cluster.
If you're planning to publish new services, it may be an option to setup a new cluster.

 

I think the number of the API Developer Portal 3.x can be decided from the number of the API Gateway clusters, because the Portal 3.x doesn't support multiple Gateway tenants like 4.x.

 

Cheers,
Seiji

[DustinDauncey]

Hello,

 

I turned this in to a discussion type rather than a question as it was before because there is no actual "right" answer to this as what's being asked for is not actually supported by CA. Ultimately CA Support would not have an answer that's been tested and proven that would achieve this use-case, it would just be theoretical. There are actually multiple points in this scenario which are not supported, which I want to point out with added notes just for everyone's awareness:

 

• Portal 3.5 does not officially support talking to more than one Gateway node, but this is overcome commonly by pointing the Portal to talk to a VIP on a load balancer which then forwards communication across a Gateway cluster behind-the-scenes. This isn't officially supported either but we can speak to this one as it's commonly used by users of Portal 3.5 and we know it works.
• Gateway nodes replicating across geographically separate data centres is also not supported. While this _should_ work under most circumstances, we find that it often creates issues whenever network isn't quite up to speed (high latency, for example), as the underlying MySQL database is very picky with regards to replication timing and even the slightest hiccup can throw it off which then requires manual intervention to reinitialize replication. This is made even worse when they are all "active" clusters receiving live production traffic. This can potentially be less of a problem though when just one cluster (where all nodes are in the same data centre) is active and the others are passive/standby clusters. This is more of an issue because we utilize MySQL Standard or Community Edition, rather than the dedicated MySQL Cluster application. If you used MySQL Cluster, you'd likely be able to achieve this easier and with less fault points, but this is also not an application which we support or have tested running against.
• MySQL replication configuration is only officially supported when it is between 2 database nodes in the same Gateway cluster. Replicating to separate clusters or especially to multiple other clusters, is a setup/configuration which we do not test for and cannot vouch for. This would be done at the MySQL level, so we can only really provide MySQL documentation references (which are all public resources), and that setup would be considered "at your own risk", and issues arising from it would not be supported, unfortunately.

 

So while the use-case is possible to achieve, it's not officially supported nor documented for such a setup. The quick of it though is this:

 

• The additional nodes can be added as usual, per the documentation here: Configuring Subsequent Processing Nodes - CA API Gateway - 9.3 - CA Technologies Documentation  (this part is officially supported)
• The replication for MySQL in a three-way cluster environment can potentially be done with using MySQL Cluster instead of the regular MySQL Community Edition. This may work, but this has not been tested and is "at your own risk": MySQL :: MySQL 5.5 Reference Manual :: 18.6 NDB Cluster Replication 

 

From a Support standpoint, I would strongly discourage the use of a database that we don't test against, and also discourage the architecture used with multiple nodes in multiple clusters across multiple data centres. Quick question: Can I ask why the customer needs so many Gateway nodes and in that particular setup? It's rare that so many Gateway nodes are actually needed to run with the Portal, so I'm curious why this is even necessary. Is it out of resources, for example? Or in other words, what is the ultimate problem they are trying to solve by adding more nodes to all their clusters?

[naiam02]

Hi Moriyama and Dauncey ,

 

Thanks for your valuable suggestions regarding this setup.

 

Now we are planning for migration of their existing setup

 

Older SOA gateway Nodes ---> 9.3 version of gateway

 

Developer portal 3.X---> 4.X version

 

The customer will add two more data centers with each cluster in each data center with existing data center. Portal 4.X will still support multiple clusters and they have limited use of portal . They are not using analytics, or monetization for today.  I believe wrt your 2  point putting all nodes into a single cluster and spread them across data centers is not a good idea if the latency arises. So having 3 separate clusters for different data centers as we have done it for other customers.