Last active
July 22, 2016 21:01
-
-
Save chianingwang/701db4309877c90a0b1c7b95c774802e to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Swift Deployment Automation in Cisco Intercloud
Speakers: Cisco & SwiftStack
Abstract (1000 chars)
The Cisco Intercloud Storage team has worked with SwiftStack to build Swift deployment automation using SwiftStack and a variety of open source tools. The automation includes hardware provisioning, deployment of Swift, integration with various systems like Keystone, monitoring, etc, as well as unit-tests at the end. The automated workflow leverages Ansible to wrap Kickstart and Python (SwiftStack python modules) scripts for deployment and configuration, creating a repeatable, auditable and consistent process. The deployment takes into consideration different hardware profiles and cluster designs and will dynamically adjust parameters for various environments. It can be run repeatedly and the same process is leveraged for upgrades. At the end, after a Swift cluster build or upgrade, unit-tests are run against the cluster to verify that the system is working. The entire process of deploying/upgrading can be monitored and reviewed through the build pipeline GUI and/or through system logs.
What is the problem or use case you’re addressing in this session? (1000 chars)
Deploying Swift at scale and doing so consistently in a timely manner is critical for the Cisco Intercloud, as teams need to roll out every production site in two weeks. The entire process has to be easy, stable and transparent enough for seasoned and more junior staff members alike that the results are predictable every time. Yet, for different hardware configurations and Swift cluster requirements, provisioning, deployment and unit-testing must remain somewhat flexible. The unit tests are not only verifying CRUD operations against the cluster, but also runs smoke tests, including networking to make sure the cluster is up and healthy.
What should attendees expect to learn? (1000 chars)
Building, managing, maintaining and supporting Swift clusters at scale across multiple geographies and time zones is a challenging task. While it's relatively simple to build a small Swift cluster on bare metal, taking into consideration lifecycle management of a Swift cluster, including upgrades, health, SLAs, monitoring and billing, is quite a different story. Attendees of this session will get a thorough view into what it took to successfully deploy Swift in many data centers across the globe for the Cisco Intercloud organization. Although the tools used for the Cisco Intercloud deployments aren't the only tools that can be used, the design concepts and the processes used to provision, configure, deploy and run Swift at scale will provide great insight to anyone considering a similar project.
Cisco Intercloud migration from Ceph to Swift while in production
Speakers: Cisco & SwiftStack
Abstract (1000 chars)
This is the story about how Cisco Intercloud migrated from Ceph Rados Gateway (RGW) to Swift while in production and without service interruption. To prepare for the migration we collected vital data in the Cisco labs on storage requirements, throughput, latency, etc. A migration plan including all dependencies, such as RGW, Swift, networking, load balancing, SSL termination, Keystone endpoint switch-over and data migration was created. If any of these things weren’t planned in detail, a seamless cut-over could not be guaranteed. The SwiftStack data migrator and cluster shunt middleware were key components to the migration. The migrator maintains thresholds to make sure the data movement won't hurt throughput in the Ceph cluster. The SwiftStack shunt middleware allows RGW and Swift to co-exist and ensures service during the cut-over period. Throughout the migration, monitoring is watching the status of both Ceph and Swift, providing status reports of the migration progress.
What is the problem or use case you’re addressing in this session? (1000 chars)
The ultimate goal was to replace RGW on Ceph with Swift without any downtime. By using Swift instead of RGW with Ceph, Cisco and its customers will gain full Swift API compatibility, as well as additional functionality that only Swift itself can provide. Moving significant amounts of data from one storage system to another without a service disruption is challenging project. Additionally, minimizing the impact on the original production system (Ceph) is critical in order to not degrade service levels. And last, but most important, ensuring that no data is lost during migration, requires a solid plan, tooling and several delta syncs between the old and the new clusters.
What should attendees expect to learn? (1000 chars)
It is still relatively early days in the OpenStack ecosystem. Ceph and Swift are both cornerstones of many OpenStack deployments. They both have their strengths and weaknesses, as well as overlapping functionality and use-cases. When picking one solution over another, you always make some kind of compromise. To get the best of both worlds, you will likely end up with both Ceph and Swift. If you end up needing to migrate from RGW to Swift, the plan and process co-developed by Cisco and SwiftStack can make the difference between a long, complicated migration and a successful one. In this session, we will share the issues we were confronted with and how we solved them.