Here in this post i will discuss how we can deploy WSO2 API Manager across multiple data centers.
Problems with normal clustered deployment across multiple data centers.
Large number of database calls and web service calls may cause extreme slowness and in future that may cause to lot of other issues.
In this this kind of situations ideal solution would be having one master data center and few read only data centers.
Still we will not be able to overcome issues happen due to missing cluster communicate across nodes. But we will be able to perform basic tasks across all data centers.
Master data center.
API store, publisher, gateway, key manager will be deployed here and all are connected to read/write databases.
All API creation subscription creation, token generation should happen here.
Once new API published it will be pushed to some servers like dropbox or file server(artifact server). Then read only nodes have to pick API config from there(we may not be able to use deployment synchronizer here).
That way only we can avoid API publishing call between data centers.
Read only data centers.
In this data canters we will have gateway and key management nodes and those will only serve API requests.
In this data center we will have database servers which are synch up with master data center databases. We can have replicated database cluster and replicate data.
Also we may not be able to enable clustering across data centers. Due to that data centers may keep their own throttle counters etc(which we cannot avoid).
Here is a sample deployment diagram for suggested solution.
Problems with normal clustered deployment across multiple data centers.
- The databases are accessed (by the gateway node on Secondary data center) over two regions. (This will slow down the server startup as there are multiple DB calls get invoked)
- Publishing API to gateway is done through web-service calls across data centers.
- Since the Gateway at Secondary site uses the KayManager node at Master site (Please correct us, if we have mistaken this), API access token validation is done through web-service calls across data centers.
- As we observed gateways in both deployments will not be synced-up properly.
- Throttle counts will be maintain per data center.
Large number of database calls and web service calls may cause extreme slowness and in future that may cause to lot of other issues.
In this this kind of situations ideal solution would be having one master data center and few read only data centers.
Still we will not be able to overcome issues happen due to missing cluster communicate across nodes. But we will be able to perform basic tasks across all data centers.
Master data center.
API store, publisher, gateway, key manager will be deployed here and all are connected to read/write databases.
All API creation subscription creation, token generation should happen here.
Once new API published it will be pushed to some servers like dropbox or file server(artifact server). Then read only nodes have to pick API config from there(we may not be able to use deployment synchronizer here).
That way only we can avoid API publishing call between data centers.
Read only data centers.
In this data canters we will have gateway and key management nodes and those will only serve API requests.
In this data center we will have database servers which are synch up with master data center databases. We can have replicated database cluster and replicate data.
Also we may not be able to enable clustering across data centers. Due to that data centers may keep their own throttle counters etc(which we cannot avoid).
Here is a sample deployment diagram for suggested solution.
Nicely articulated the problems and the possible feasible solutions, good job Sanjeewa!
ReplyDelete