Storage Integrations for Container Orchestrators
Download as PPTX, PDF2 likes3,839 views
This presentation will dive into all the storage options available with the most popular container orchestrators such as Kubernetes, Docker, and Mesos.
Ad
More Related Content
What's hot (20)
Similar to Storage Integrations for Container Orchestrators (20)
Ad
Recently uploaded (20)
Ad
Storage Integrations for Container Orchestrators
- 1. Storage Integrations for Container Orchestrators Highly Available Applications on Docker, Kubernetes and Mesos
- 2. Open Source at Dell EMC – Contributing to and maintaining open source projects – Community engagement – Technical solution leadership {code} by Dell EMC is a group of passionate open source engineers and advocates building community around software-based infrastructure. Platinum Sponsor
- 3. THERE IS NO SUCH THING AS A ”STATELESS” ARCHITECTURE IT’S JUST SOMEONE ELSE’S PROBLEM - Jonas Boner, CEO of Lightbend
- 4. If You’re Running… • Databases – Postgres, MongoDB, MySQL, MariaDB, Redis, Cassandra • Search, Analytics, Messaging – ElasticSearch, RabbitMQ • Content Management – Wordpress, Joomla, Drupal, SugarCRM • Service Discovery – Consul, Zookeeper, etcd • Continuous Integration and Delivery – Jenkins, GitLab, SonarQube, Selenium, Nexus • Custom Applications – That Java app your company built Stateful and persistent applications
- 5. Applications need data Lots of different types of persistent services to consider Files Blocks Documents Logstreams Time Series Media and Streaming Modern or Traditional Applications Storage Services Objects Your use case here…
- 6. hub.docker.com 10 of the top 30 require persistence 4/4/17
- 7. Use services from any cloud True portability of applications requires interoperability My Cloud Public Cloud Universal Network and Storage Interfaces Container Orchestrators ..and interoperating with cloud services ..with your preferred CO Running Container Images ..with or without virtualization No teleportation here.
- 8. Storage is easy when abstracted by a hypervisor Everything is software defined with virtualized infrastructure Physical Servers Hypervisor/IaaS You get software defined storage from any storage platformCompute Network Storage Shared storage (FC/iSCSINFS) Provided through hyper-converged storage Data-plane abstraction makes it easy to connect storage to VMs. OR/AND VM Abstracted by a hypervisor for VMs With many heterogeneous servers and storage Maybe this is the right answer for you. DATA FLOW
- 9. Cloud Native Thinking Applied.. Be portable, focus on software and interoperability instead of data-plane abstraction Container Orchestrators Container OSs Storage resources are interoperable Cloud Storage Service Integration with Storage Orchestrators Cloud Native Storage Compute Network Storage DATA FLOW
- 10. Deploying Applications with Storage • Orchestrator ensures application and container are running at all times. • A new container will be created with the existing data if necessary. • The application process and container maintain ephemeral. • Storage is orchestrated to the host and made available to container. Storage is attached and detached from host instances where containers are targeted to run. deploy: container: redis volume: name: redisData /redisData /etc /var /bin /opt /data
- 11. Interfacing for Storage Services Container orchestrators and runtimes are able to make specific requests for storage services. Container Orchestrator Cloud and Storage Platform Container Hosts Interface achieves these things.. • Create/Remove volumes • Inspect/List volumes • Attach/Detach volumes • Mount/Unmount volumes
- 12. Interoperability for Storage Services • Orchestrators communicate with external storage platforms to perform storage lifecycle and orchestration features. • These integrations take place internal and external to container runtimes and orchestrators and their code base. Container Orchestrator Cloud and Storage Platform Container Hosts Cloud and Storage Platform Storage Plugins In-Tree Out-of-Tree Managed Plugins or Host Process
- 13. Storage Plugins Interoperability Today Docker Volume Driver Interface DVDI DVDCLI Flex Interface DVDI JSON over RPC JSON over Proc JSON/RPC over HTTP Storage Platform JSON/RPC over HTTP In-Tree
- 14. How do we tie all this together?
- 15. Introducing REX-Ray REX-Ray The leading container storage orchestration engine enabling persistence for cloud native workloads rexray.codedellemc.com • Out of Tree Plugin • Trusted Cloud Native Interoperability • Open Source • Enterprise Ready – High Availability – CLI Intuitiveness – Effortless Deployment – Architectural Choices – Natively Secure • Multi-Platform Storage Management – Storage agnostic (block/file/object)
- 16. Docker Integration • Use the stand alone Docker Engine to run a stateful application or combine it with Docker Swarm Mode to turn your application into a robust service. • Available in the Docker Store as a certified and trusted plugin • REX-Ray development started when the Docker Volume Driver interface was introduced in 1.7 Experimental • One of 6 available drivers during DockerCon 2014 debut of the Docker Volume Driver • {code} team has submitted 6 patches and over 100 lines of code to the Docker Engine for Storage • Provides full volume lifecycle capability
- 17. Docker Integration • Deploy as a host based service or as a Docker Plugin Available in the Docker Store
- 18. $ docker service create --name redis --replicas 1 --mount type=volume,src=redisData, dst=/data,volume-driver=rexray redis redisData /etc /var /bin /opt /data Storage Platform Persistent Volume Docker Swarm Integration
- 19. End-to-End Container Persistence Leadership for Mesos What does it do Enables external storage to be created / mounted / unmounted with each agent task Abstracts Docker Volume Drivers for Mesos Storage orchestration engine Cool factor • First Mesos Agent external storage module • Merged into Mesos 1.0 (2016) • Allows the use of any Docker volume driver with Mesos! • Vendor agnostic • DC/OS 1.7+ framework (2016) mesos-module-dvdi Docker Volume Driver Client CLI DVDCLI REX-Ray
- 20. Mesos Container Framework Integration • Marathon from Mesosphere • Apache Aurora (originally used by Twitter) • ElasticSeach
- 21. Kubernetes Integration • Kubernetes offers two approaches for storage integration. • An “in-tree” volume plugin for a platform. The storage interface code is directly embedded into Kubernetes. The downside is that plugin velocity (the speed at which a plugin can be added, enhanced, or patched) is gated by the Kubernetes release cycle. • The second approach is to leverage the FlexVolume volume plugin. This plugin uses externally installed and managed software to handle basic Attach/Detach/Mount/Unmount storage operations.
- 22. Kubernetes Integration • REX-Ray provides an adapter script called FlexREX which integrates with the FlexVolume plug-in to interact with the backing storage system • Allowspodsto consumedatastoredonvolumes thatare orchestratedby REX-Ray.Using Kubernetes' FlexVolumeplug-in,REX-Raycan provideuniform accessto storage operationssuchasattach, mount, detach,and unmountforanyconfiguredstorageprovider. • Runstatefulapplicationsinpodsand statefulsetsthroughFlexREX, andbenefitfrom CLImanagement capabilities. • UseanyREX-Raysupportedstorageplatform • Dynamic Provisioningandstorageclassesarenotavailableas a limitationof FlexVolume andrequires volume create/deleteto be managedoutsideof Kubernetes $ rexray flexrex install
- 23. Kubernetes Integration • ScaleIO is part of the core Kubernetes code and a first class native storage provider • ScaleIO can take full advantage of the Kubernetes volume lifecycle features including dynamic provisioning and storage classes • ScaleIO driver is embedded in the standard distribution of Kubernetes • Contributed code from the {code} by Dell EMC team passes “Google” standard of quality • Opens a new opportunity for those running Kubernetes in on-premise data centers. It allows utilization of your commodity x86 server hardware for very high performance and highly available storage for running stateful apps in containers.
- 24. OpenShift Integration • Kubernetes is used under the covers of OpenShift • Get all the benefits of FlexREX and native use of ScaleIO without any additional configuration • Support persistence requirements for applications
- 25. Storage Plugins Interoperability Today Docker Volume Driver Interface DVDI DVDCLI Flex Interface DVDI JSON over RPC JSON over Proc JSON/RPC over HTTP Storage Platform JSON/RPC over HTTP In-Tree
- 26. Solving the problem • REX-Ray or Kubernetes is installed and configured on all hosts in the cluster as a stateless service • Container engines redirect volume operations to the storage driver – Create/Mount/Unmount/Delete $ docker run --volume-driver=rexray -v redisData:/data redis /redisData /etc /var /bin /opt /data
- 27. Solving the problem • Lose the container or lose the server – Data persists and remains in tact on the remote storage platform /etc /var /bin /opt /redisData
- 28. Solving the problem • Attach the volume to a new container on a different host – Equivalent of a hard reset. Application starts and resumes from the last write to disk – Container scheduler is responsible for creating a new container • Scalability – Application data can scale to the maximum supported by the storage platform /etc /var /bin /opt /data /redisData
- 29. #CodeOpen Demo
- 30. Take our projects for a spin at the {code} Labs http://github.com/codedellemc/labs
- 31. codedellemc.com community.codedellemc.com @codeDellEMC blog.codedellemc.com {code} by Dell EMC is a group of passionate open source engineers and advocates working to build a community around software-based infrastructure. rexray.codedellemc.com github.com/codedellemc/labs vLab (For Partners) Use REX-Ray & ScaleIO w/ Docker, Mesos and Kubernetes
Editor's Notes
- #3: Add talking points to each point OSS projects: Docker, Mesos, Kubernetes, Cloud Foundry
- #8: The key word here is interoperability. This allows me to satisfy requirements of making my application portable when there are unversal hooks into the necessary parts of my application. Which computing is pretty universal, but the networking and storage aspect must be as well. Today we have things like the Container Network Interface while the Container Storage Interface is currently under development. These universal concepts allow my applications to interoperate with any cloud service without relying on the need for virtualization.
- #9: But lets take virtualzation as an example. The abstraction of every facet of compting/network/storage makes it very easy to consume. All of the heavy lifting is done by the hypervisor because the types and amounts of servers, storage and networking aren’t visible to the container orchestrator, engine or runtime . And maybe this is the right answer for you, and to be honest, the immediate future of containers will be using a hypervisor. This creates a pseudo-software defined storage platform behind the container orchestrator’s back. But we need to think a bit differnenly as this progresses because the data-plane abstraction is relying on a virtulized mount to provide the data persistence.
- #10: If we take this to a cloud native concept, the data flow should be horizontal. The compute, networking, and storage is decoupled and only fits through a series of universal interfaces. These interfaces are responsible for the orchestration of networking and storage on different types of clouds and on-premise products. This lateral data flow allows an application to be truly portable across any type of environment and even spread across environments.
- #11: So how does this work? In this example we are looking at a redis deployment. The orchestrator is responsible for to make sure this application adheres to the specifics or remediation policy. A new container is created and storage is orchestrated to the host and made available to the container. If data currently exists on the volume, then it’s mounted and state resumes. If not, a clean volume is mounted and any init or kickstart scripts can begin. At this point, the application and container remain ephemeral. Meaning that I can destroy the container and I’m expecting the CO to restart a new container. However, no data will be lost since it rests on a external storage platform and the use of the storage orchestration will take care of volume lifecycle.
- #12: The volume lifecycle achieves a few different things. It can… this is all possible through various and specific API requests to the storage platforms
- #13: The API requests for storage orchestration to external platforms can come from two possibilities. First is an in-tree driver which is native code built-in to the CO. the second is out-of-tree drivers using a plugin. Each one of these has its own pros and cons list. The in-tree driver is subject to the release cycle of the CO. The storage plugins for out-of-tree might not be given all the benefits of an in-tree if the interfaces the are exposed can’t utilize the feature sets of the storage platform.
- #19: In this example, our application is storing data in “/mydata”
- #20: Docker Volume Driver Isolator Module No remote storage capability using Mesos before September 2015 {code} was first to bring an abstracted persistent storage model Freedom to use the Mesos Containerizer with ANY docker volume driver (that means you don’t need Docker) Merged upstream into Mesos 1.0 to provide storage platform support for any vendor who has written a docker volume driver, including REX-Ray Every company that boasts storage integration with Mesos uses the {code} contributed module. DVDCLI Sss Sss DC/OS 1.7 Release ships with REX-Ray embedded DC/OS 1.8 Release ships with DVDI embedded for Mesos 1.0 Featured in the documentation - https://dcos.io/docs/1.8/usage/storage/external-storage/
- #32: First, a few things about the team that has made this possible. The Dell EMC {code} team is a team made up of open source software engineers and developer advocates, focused on making EMC a well-known name within the open source community. We will focus on one of their projects, REX-Ray, in this presentation.