My Company wants to setup wso2 identity server cluster on 3 machines such that if one machine fails, the cluster still works.
All the wso2 documentation shows clustering with shared user store and database but does not mention how to avoid single point of failure.
As per my understanding, the only way to do the same is to form an external ldap cluster as user store and an external database cluster. But that would be much complex and hard to manage.
Can we configure the wso2's embedded ldap to replicate and sync with other node's embedded ldap?
Is there any other way to avoid single point of failure in wso2?
No, you can't use embedded LDAP.
You should avoid using embedded LDAP in production at all costs. It will sure get corrupted with concurrent requests and growth the of data. And you will not be able to recover at all. It's just there for testing purposes.
If you want to avoid any single point of failures due to DB or LDAPs, you should be using DB and LDAP clustered as instructed by the respective provider. And point the common LB URL to the WSO2 server.
Related
We have HTTP sessions in on-premise application. We want to migrate application to Cloud. We got the direction to use REDIS cache implementation in Cloud to replace HTTP sessions.
Do we save user specific(HTTP Session) data in REDIS? Is there any other elegant way to handle this scenario?
Thanks in advance.
Assuming you're talking about a legacy app, you can set Redis (Azure Redis Cache) as your State Provider.
Here's a link about it:
https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-aspnet-session-state-provider
Yes it is possible and Redis is one of the pinpoint solutions for this kind of requirements. It is super fast in-memory key/value store just like sessions(get/set). Most of the modern frameworks come along with built-in session support for Redis. Even it is a legacy app, you may integrate easily(there could some libraries that do that). You may just use commands such as SET, GET, EXPIRE, EXISTS, DEL for a session store.
If it is going to be just string/string you may go with string, if you have some json values you may use hash. Both solutions provide EXPIRE option for you to not store forever and manage your memory.
I am not familiar with Azure side but AWS has ElastiCache service that supports Redis. Another option could be installing one in a EC2 instance for on-prem.
I have been trying to setup an active active setup for WSO2 API Manager. This has been elaborated here:
https://docs.wso2.com/display/AM210/Configuring+an+Active-Active+Deployment#Linux-Mac
Few observations:
The setup looks to be on two different nodes, with all components deployed on each node.
The setup indicates that Publisher should be pointed to one of the two nodes for both the nodes. If that is the case, lets say that node-1 (publisher) node goes down, how will second active instance help?
It recommends using NFS for content synchronization. NFS becomes a single point of failure in that case. Why is content synchronization needed though? Is it only for advanced siddhi query based throttling policies?
Finally, if I do two independent, all-components-in-one setup of API Managers with shared database and content synchronization using rsync/unison; but no throttling data publishing, what are the downsides?
Is this kind of setup fit for Active - Passive?
Thanks
If you use rsync or any deployment synchronization mechanism which is one way, this becomes a single point of failure. Most of the use cases, API publishing happens at the development time and this is actually a limitation.
That's why we can use NFS or file share mechanism. You can point the localhost and write the Synapse file to the file system. Then it shares among the two nodes. When you publish an API, Synapse artifact is created and deployed in the gateway node. In your case, one of the nodes.You can find a sample file in APIM_HOME/repository/deployment/server/synapse/default/api location.
If you disable throttling data publishing, i.e advanced throttling, your APIs can be accessed without any limitation. Simply there is no limit. But burst control and backend throttling will apply.
Yes, this fits for A-P. You can control A-A or A-P from the load balancer.
Is there another way to cluster WSO2 Identity Servers aside from connecting to another node's embedded-LDAP user store? I turn off embedded-LDAP anyway per other instructions. Would it be better to connect to another user's JDBC store instead?
https://docs.wso2.com/display/CLUSTER44x/Clustering+Identity+Server+5.1.0%2C+5.2.0+and+5.3.0
Sharing the user stores is mandatory for the functionality of the cluster as both nodes of the cluster should be exposed to the same user base but the user store doesn't have to be the embedded LDAP. The embedded LDAP is usually used for development purposes. It is not recommended to use them in the production environment. So if your still in PoC stage, it is fine to point both nodes one embedded LDAP otherwise I recommend you to have an external user store such as LDAP, AD or a JDBC one.
You can either use an existing LDAP/AD or point to an outside JDBC user store. But both nodes should point to the same user store. You can refer [1] for more information on configuring different types of user stores.
We are working on setting up the wso2 production environment and the question came up about the importance of having high availability databases on the identity server side. We have concerns regarding access tokens. Does the IDS manage all that information or is it shared among the other DBs? Also, if the DB happens to go down on the IDS side, will it case all of wso2 to crash? Will APIs no longer be available for use? I can't seem to find much documentation on the matter.
Thanks you.
Database high availability is needed for WSO2 products.Tokens will be saved in the database. If database goes down, Identity server will not function properly.
Why would anyone use WSO2 Application Server instead of other application servers?
I rather encountered only problems with it, mainly due to class loading issues, so I would appreciate if someone could point out what are the advantages or the use cases when using WSO2-AS really makes a difference.
I can see the benefits of other standalone WSO2 products, but as far as the AS is concerned, I would rather rely on more lightweight servers and just package the libraries I need.
There are number of advantages on WSO2 Application Server.
1.) It provides in-built support for multi-tenancy, in case if you have isolated departments like organization there is no real need to have number of server instances you could simply create a new tenant.
2.) Automatic lazy loading support for tenants, web applications and web services. In a production system a particular tenant/web application/web service can be ideal for sometime it's a waste to allocate hardware resources continuously to such ideal applications specially if you use IaaS. WSO2 application server can detect such ideal tenant/web application/web service and release their resources and tenant/web application/web service will load again when a new request dispatch to the particular tenant/web application/web service.
3.) Wide range of deployment options, support to deploy on-premise, public or private IaaS , public or private PassS such as Apache Stratos. An an example one can deploy his application into WSO2 App Cloud (http://wso2.com/cloud/app-cloud/) instantly without downloading anything, later he can get same experience one of above platforms.
4.) Deployment synchronization feature, a clustered environment you may have very large number of nodes and upgrading application version and configuration changes across the cluster can be headache. Using Deployment synchronization feature you can modify only one node labeled as manger node and Deployment synchronization will take care about synchronize changes across the cluster automatically and consistently.
5.) When developing applications on WSO2 Application Server you can leverage carbon platform level features such as identity, registry, logging, distributed caching, multi-tenancy etc. As an example one can use identity features provided by the platform to mange users, roles permissions also for authentication and authorization without write something own.
6.) Inbuilt support for security standards such SSO among other WSO2 products.
7.) In-build monitoring capability for web services and web application through WSO2 BAM.
8.) Enhanced and rich dashboard for applications and services which facilitate to basic statistics, application management, security wizards, code generations, Try -It tools, run time logging configurations etc.
9.) Enhanced classloading mechanism (starting from AS 5.1.0), within one Application server instance you can have number of virtual server environments per application level. As an example one can specify an application run on minimal Tomcat mode or can assign to run Carbon mode which is ( Tomcat + Carbon platform).
When it come to your specific issue if you can specify your Application Server version and elaborate more on your classloading issue I can provide you more specific answer.
Having said above I want to mention that I'm from WSO2.