Cloudstack Orchestration Appliance
•Download as PPTX, PDF•
1 like•848 views
Do you want a way to deploy CloudStack management services, including databases and supporting services, into a new environment with ease? Do you need resilience for your environment's management plane? We've created a appliance that can host all of the components required to manage a CloudStack-based cloud infrastructure, and can be deployed on various types of hardware, with minimal requirements. The project led to the use of a few interesting technologies and methods, including a tested and customized implementation of MariaDB/Galera to backend CloudStack. During this session, we will go over this appliance design, and hopefully have a dialogue about similar deployment designs that others have used.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Cloudstack Orchestration Appliance
Similar to Cloudstack Orchestration Appliance (20)
Recently uploaded
Recently uploaded (20)
Cloudstack Orchestration Appliance
- 1. This is the Title Page Sure is! www.sungardas.com
- 2. Cloudstack Orchestration Appliance Adam Grochowski, Sungard Availability Services www.sungardas.com
- 3. Introduction Sungard‘s adoption and implementation of Cloudstack Make it even more HA/Secure Some extensions necessary © 2013 SunGard Availability Services LP – All Rights Reserved 3
- 4. About SunGard SunGard is one of the world‘s leading software and technology services companies • More than 17,000 employees serving 25,000 customers • Annual revenue of over $4 billion SunGard Availability Services is one of SunGard‘s four core lines of business • Provides responsive and integrated disaster recovery, managed IT services, IT consulting and business continuity management software solutions • Portfolio of availability services contains a set of solutions that leverage shared, high-intensity IT resources • 5 million square feet of datacenter and operations space • Manages 90 hardened IT facilities connected by a redundant, global dedicated network backbone © 2013 SunGard Availability Services LP – All Rights Reserved 4
- 5. History SunGard Cloud Engineering – estab. 2009 Enterprise Cloud Services—we operate a shared, multi-tenant infrastructure Our customers get cloud economics and agility without needing to re-architect their applications We provide a fully managed "Virtual Data Center" environment for our customers We currently use traditional network isolation and security techniques © 2013 SunGard Availability Services LP – All Rights Reserved We have developed our own orchestration platform for fully automated service provisioning 5
- 6. Current Sungard Enterprise Cloud Orchestration Provisions entire network end to end Runs on complicated hardware Difficult to perform upgrades, generally lifecycle © 2013 SunGard Availability Services LP – All Rights Reserved 6
- 7. Choosing Cloudstack We are growing, so scaling is always a concern Our customers want us to be more flexible and provide more customization We want to improve the reliability of provisioning automation We need to provide more features to our customers in a more agile fashion Public as well as Enterprise Offerings © 2013 SunGard Availability Services LP – All Rights Reserved 7
- 8. Hardware - Current Enterprise Orchestration - From this • • • • • Dedicated Storage Dedicated SAN Dedicated UCS + ToRs Complex Expensive © 2013 SunGard Availability Services LP – All Rights Reserved 8
- 9. To this • • • • • • Simplicity No shared resources (exc. network) Easily Expandable Local storage per host Fully redundant (hypervisor agnostic) Way Cheaper © 2013 SunGard Availability Services LP – All Rights Reserved 9
- 10. Orchestration Design Philosophy/Background Simple and quick to deploy Appliance like for operational ease Highly available and Secure © 2013 SunGard Availability Services LP – All Rights Reserved 10
- 11. Cloudstack HA Orchestration Components, in pairs Cloudstack Management Servers MariaDB + Galera Virtual Firewall Virtual Load Balancer © 2013 SunGard Availability Services LP – All Rights Reserved 11
- 12. Pictures! © 2013 SunGard Availability Services LP – All Rights Reserved 12
- 13. But Galera requires 3 nodes for proper clustering! • Only if you’re concerned about split brain • When one hypervisor loses connectivity, all hope is lost for it • This can make recovery of ‘secondary’ db server a manual task © 2013 SunGard Availability Services LP – All Rights Reserved 13
- 14. Failure/HA Scenarios © 2013 SunGard Availability Services LP – All Rights Reserved 14
- 15. Failure/HA Scenarios Network © 2013 SunGard Availability Services LP – All Rights Reserved 15
- 16. Current Features Network/Firewall/Load Balancer HA design Auto start MariaDB – check for peer before starting Auto start CS – check for SQL before starting © 2013 SunGard Availability Services LP – All Rights Reserved 16
- 17. Next Steps Puppet-ize everything, from install on out Startup ‗Questionnaire‘ to create site build from scratch. Potential – FW Participation with routing core, SG managed on premises clouds © 2013 SunGard Availability Services LP – All Rights Reserved 17
- 18. Conclusion Cloud cloud. Cloud, cloud, cloud cloud cloud. Cloud cloud, cloud cloud; cloud. Cloud cloud cloud cloud cloud. Cloud, cloud, cloud cloud cloud. Cloud = Cloud – Cloud * Cloud Cloud cloud-cloud cloud. • Cloud, cloud, cloud cloud cloud. • Cloud! © 2013 SunGard Availability Services LP – All Rights Reserved Questions? 18
- 19. Contacts Adam Grochowski Partly Cloudy with a chance of showers SunGard Availability Services 680 E. Swedesford Road Wayne, PA 19087 215 446 2679 Office adam.grochowski@sungard.com © 2013 SunGard Availability Services LP – All Rights Reserved 19
- 20. Confidentiality Statement Copyright ©2012 by SunGard Availability Services (or its subsidiaries, ―SunGard‖). All rights reserved. No parts of this document may be reproduced, transmitted or stored electronically without SunGard‘s prior written permission. This document contains SunGard's confidential or proprietary information. By accepting this document, you agree that: (A)(1) if a pre-existing contract containing disclosure and use restrictions exists between your company and SunGard, you and your company will use this information subject to the terms of the pre-existing contract; or (2) if no such pre-existing contract exists, you and your Company agree to protect this information and not reproduce or disclose the information in any way; and (B) SunGard makes no warranties, express or implied, in this document, and SunGard shall not be liable for damages of any kind arising out of use of this document Trademark Information: SunGard and the SunGard logo are trademarks or registered trademarks of SunGard Data Systems Inc. or its subsidiaries in the U.S. and other countries. All other trade names are trademarks or registered trademarks of their respective holders. © 2013 SunGard Availability Services LP – All Rights Reserved 20
Editor's Notes
- We've created a appliance that can host all of the components required to manage a CloudStack-based cloud infrastructure, and can be deployed on various types of hardware, with minimal requirements. The project led to the use of a few interesting technologies and methods, including a tested and customized implementation of MariaDB/Galera to backend CloudStack. During this session, we will go over this appliance design, and hopefully have a dialogue about similar deployment designs that others have used.
- Sungard is a global business with fingers in Various areas. I work for availabilty services which provides DR, Managed Services, and IT consulting. This is a lot of stuff that you’re probably not super interested in.
- Around 2009, Product Development was tasked with creating a cloud solution, and for all intents and purposes became Cloud Engineering. We developed an Enterprise grade clouds, for customers to move their workloads into a virtualized solution without changing their processes much. It’s totally managed, which means our operation team will maintain your OS, some of your Apps etc.
- Over time we’ve developed a fully automated service provisioning system that creates every aspect of a customer’s Virtual Datacenter, from Routing, to Firewall, to switching, all the way to VMs and services for them, such as business continuity.
- However, Over time this software has also gotten a bit unwieldy, difficult to troubleshoot, lifecycle, and maintain for Engineering and operations. So starting around 2011, the decision was made to start looking at cloudstack, at least for a ‘Public, Dev/QA’ offerings WE launched our first ‘Cloudstack powered’ offering in our Dublin center in November of last year. Currently I’m working on a Public Cloud offering which will launch in the early part of 2014, and will launch soon after in 4 other locations around the world. – Cloudstack for automation, and a custom created Portal for the User experience. The hope is that Cloudstack will allow us meet our customers changing demands in a more agile fashion.
- This is what our orchestration systems look look like currently. They are super expensive, and pretty complex to lifecycle, troubleshoot. And cable. And purchase. And deal with in general.
- Cloudstack and our current design has allowed us to simplify this. We didn’t want to deal with a SAN or NAS (in case this gets deployed as an on premises solution) so any kind of shared storage was right out – the only shared resource between these servers is network, and that will be shared with some NAS traffic, as well as Outbound bandwidth. We wanted to have some headroom to add services (rabbitmq for notifications is on our todo list, etc), so our current environment has rather beefy servers (2x8 core Procs, way too much ram)These servers are using Xen as a hypervisor, but since we’re not using any hypervisor specific features, we don’t particularly care what we use
- That’s guided what we’ve done with this current setup, especially with regards to our orchestration designKeep the orchestration with as few moving parts as possible, allowing for ease of setup, maintenance and troubleshooting. OUR customer won’t tolerate downtime, so platform is designed to be resillient and secure. Our Portal will consume the cloudstack API, as will (some) customers.
- So let’s talk about what’s running on those hypervisors that we don’t care about.Cloudstack management Servers,MariaDB with Galera for DB HAA virtual Firewall
- Both mariadb servers are active and therefore we have a multi master environment , and sowe have each CS platform speaking to only one DB
- We’re not very concerned about split brain in our design, because the hypervisors are connected via an LACP interface, on which all necessary tagged networks ride. In the unlikely event that we lose the pair of interfaces on the same host, no traffic will flow to or from that Cloudstack instance, effectively fencing it off from the world. \In the case of a prolonged outage, upon recovery, operations may have to make sure that the dbs are in sync before bringing the second system back online
- Animate me
- Animate me
- Here are the features we've currently worked outAs we've discussed, the firewall and network layout has been specifically tailored to this purposeMariaDB setup - For those not familiar with we've got mariadb auto starting, but checking for a peer to set proper mastership. If you're unfamiliar with MariaDB and Galera, to sum up, you must start up a server in standalone mode, and then start the secondary with knowledge of its masterIf you don't wait, they will either each start up as standalone, or not start because they can't find their peer.We have created a script to mitigate this, and to allow you to not worry about startup order across machinesWe also have some scripts written to check to see if the DB is up before starting up Cloudstack.These modifications allow us to boot up our orchestration hpervisors, and not worry about boot order for vms. They will all naturally shake into place as they boot.
- Here are some future stepsWe are finishing the puppetizaton the entire set of orchestration VMs, so that it's easier to install and maintain We are creating a questionnaire script to feed into puppet - in this way we can create a base install, answer some questions, and have an up and running base cloudstack build, ready to manage an environment. This will allow us to spin up more sites more quickly. In the future, the firewall might participate in the routing core, so that we can remotely manage entire sites through a vpn tunnel to the remote set of cloudstack servers
- So it's a work in progress, we'll continue to refine things as we go along. I'd love to hear any comments, questions, or suggestions, especially if they're written on a 20 dollar bill.