Cello saas scalability architecture
0 likes534 views
CelloSaaS supports scalability through scaling out its various layers. The cache layer can be scaled out by adding more cache nodes. The database layer supports vertical partitioning by modules and database sharding by tenants, allowing data from different modules and tenants to be distributed across multiple database servers. The web and application layers are designed to be stateless through principles like out-of-process sessions and per-call services, enabling both layers to be scaled out infinitely across multiple servers.
Cello saas scalability architecture
- 2. 2 CelloSaaS : Scalability Architecture Scalability in CelloSaaS CelloSaaS can be scaled out either by scaling up or scaling out. Scale up is straightforward. Let us see how the different layers of the celloSaaS application can be individually scaled out. Production Deployment Architecture User Load Balancer User User Load Balancer Active – Active Cluster Primary Secondary Caching Caching Cache Server Farm Web Server Farm Application Server Farm Batch Processing Server cluster- VM Single Database Server OR Partitioned Databases by modules and Clients Single Hardware Single Hardware Cache Layer: CelloSaaS supports Distributed cache such as AppFabric, Amazon elastic EC2. This ensures that the cache layer can be scaled out by adding more nodes if there is a higher memory requirement for cache. This also ensures that the cache is centralized and hence supports the web servers on scaled out scenario. Database Layer: CelloSaaS supports vertical partitioning by modules as well as database Sharding by Tenants.
- 3. 3 CelloSaaS : Scalability Architecture Module Based Vertical Partitioning Different modules can be modeled to reside on different servers based on the load. Data belonging to modules is grouped to data groups. For examples in a HR system, the Core HR module and Leave Management Modules can be grouped under “HR” Data group and Performance Management Data can be grouped under “PMS” Data group. Each data group can reside in its own server. Example, “HR” Data group can reside on Server 1 and “PMS” Data group can reside on server 2. During development the application models the data as per data groups and passes the data group name while dealing with database operations via cello DB APIs. Cello maps the data group to the location of the servers and connects respectively to the right servers and fulfills the request. Tenant Based Sharding Even though an application data is vertically partitioned there might be a need to further scale out the data within a single data group to multiple servers based on load. Cello supports this by providing the ability to have data in multiple servers based on the tenant. In the above example let us assume the load on the PMS data group is high and we want to further scale out the data of PMS to multiple servers. Cello supports this by allowing each data group data to be sharded further by tenant identifier. As per cello each data group and a tenant combination can reside in a server. While using Cello DB APIs cello automatically routes the tenant’s requests to the respective server. For example Tenant 1-n Tenant n+1 – 2n PMS Server1 Server2 HR Server1 Web Layer - This is responsible for rendering the user interface. CelloSaaS advocates the following principle to scale out this layer. Session Usage - CelloSaaS does not use session for storing any data. If the application needs to store session celloSaaS mandated out-of proc session storage. This ensure that the application is stateless and hence can be easily scaled out Cache Usage- CelloSaaS uses AppFabric distributed cache as the caching layer. This ensures that the memory state of cache is centralized and hence the application becomes stateless which is necessary to be scaled out. Application Layer- This is responsible for the web service driven business layer. CelloSaaS advocates the following principle to scale out this layer Per Call Services- All services are per call instances and hence can be scaled infinitely Cache Usage- Application Layer also uses centralized caching mechanism of AppFabric which ensures that the application layer is stateless and hence can be scaled out. For more information: [email protected], www.techcello.com