Overview of apache stratos (incubation) 4.0 architecture
2 likes5,801 views
This document summarizes the 4.0 architecture of Apache Stratos, an open source PaaS incubation project. The architecture allows users to deploy composite applications across multiple clouds by defining cartridges, autoscaling policies, and deployment policies. It uses a Stratos Manager, Cloud Controller, Message Broker, Auto Scaler, Load Balancer, and Cartridge Agents that communicate through topics. This enables capabilities like dynamic scaling, load balancing, smart policies, and multi-cloud deployment.
Overview of apache stratos (incubation) 4.0 architecture
- 1. Overview of Apache Stratos (Incubation) 4.0 Architecture by Lakmal Warusawithana Committer, PPMC Member Apache Stratos (Incubating) Software Architect , WSO2 Inc 14th November 2013
- 2. Architecture, Design and Code Reviews Date Description Owner 14th november Discuss overall Stratos 4 architecture Lakmal 18th november Load Balancer Imesh 21st november Autoscaler Architecture Lahiru 25th november Cloud Controller Reka 28th november CEP Integration Nirmal 3rd december Cartridge Agent Sajith
- 3. Architecture of Apache Stratos (Incubating) 4.0
- 4. USER -----create application-----> Stratos Manager ● select Cartridges and auto scaling policy and deployment policy for the application ● provide repository for the Application ● SM (Stratos Manager) will generate a “subscription key” for the subscription and store against the repository information SM -----subscription details-----> Cloud Controller ● Pass subscription details (Cartridges+Policies+Subscription key) to CC (Cloud Controller) via a service call
- 5. CC ---publish to topology topic---> Message Broker ● create payload for the subscription. It will include ○ subscription cluster id ○ subscription key ● publish “cluster created” event to topology topic which include associated policy names MB -----getting topology update-----> Auto Scaler ● AS (Auto Scaler) already subscribed to topology topic. ● Received “cluster created” message, then update the current in memory topology inside the AS ● AS will evaluate the rules and send the decision to CC via service call
- 6. CC -----update topology-----> MB ● received the decision that send the auto scaler. ● CC update the payload with followings ○ member_id ○ MB and CEP service endpoints ● create instance via jclouds and pass the payload to instance ● update topology topic with “instance spawned”
- 7. Cartridge Agent -----instance_status topic-----> MB ● subscribe to depSync topic ● Publish “member started” event to instance_status, and wait MB -----get instance_status-----> SM ● SM already subscribed to instance_status topic ● received the “member started” message ● send the depSync message, with encrypted repository information using previously generated “subscription key”
- 8. Cartridge Agent -----instance_status topic-----> MB ● receiving depSync message and decrypted repository information with “subscription key” and store in memory ● check and wait for all necessary applications to be started ● publish “member ready” event to instance_status topic with member information ● start cartridge heath publisher. publish periodic health stats to CEP via thrift
- 9. CC -----update topology-----> MB ● CC already subscribed to instance_status topic ● received “member ready” message ● publish “member activated” event to topology MB -----update end-point members-----> LB ● LB already subscribe to topology topic ● received “member activated” message, then update in memory topology for relevant cluster ● update relevant cluster member list of the load balancing end point
- 11. Support for External Load Balancers
- 12. Scalable Dynamic Load Balancing ● LB could be defined as a Cartridge ● Service Cluster or a group could defined its own LB ● Subscription can request a dedicate LB ● LB can auto scale
- 13. Scalable Dynamic Load Balancing
- 14. Smart Policies ● Ability to define Smart Policies ○ High availability in multi-cloud ○ Economy policy ○ Failover policy ○ High performance ○ Dedicated resources ● Meet SLAs ● Policy could be define by DevOps
- 15. Cloud Bursting and Multi-cloud PaaS
- 16. Build in LXC Support
- 18. Thank you