Tech Talk: Docker with Dell SC Storage With Sean McGinnis and Ryan Wallner
Tech Talk: Docker with Dell SC Storage With Sean McGinnis and Ryan Wallner
Watch a video, read the transcript, and view the slides of a presentation from DockerCon that taught those in attendance how to optimize Docker volume management.
Join the DZone community and get the full member experience.Join For Free
The State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.
In case you missed DockerCon, or could not choose among all of the amazing sessions, we wanted to share a couple session videos and transcripts with the community. In the talk featured below, Ryan Wallner of ClusterHQ joins Sean McGinnis from Dell on stage to discuss a partner solution that enables optimal management of Docker volumes.
We hope you enjoy the presentation!
Docker With Dell SC Storage
Sean: Welcome, everyone. We're going to talk about Flocker and Dell Storage Center integration. I'm Sean McGinnis from the Dell Storage group. Software Architect there. Been around since what maybe more people might recognize it as, as the Compellent Array, but I have with me Ryan from ClusterHQ. I'll just turn it right over to you.
Ryan: Hi, everybody. I'm from ClusterHQ. I'm a Solutions Engineer there, Evangelist, write some code, so a few different hats. Today, I'm actually going to introduce what is Flocker, how we integrate with different storage platforms such as Dell, and talk a little bit about some of the features we provide and where we're going with Flocker.
Capabilities and Features
Flocker has been around for a little over a year and a half now, so we've been in the Docker ecosystem for a long time. We've had a number of different customers using Flocker, and so we've really had the ability to create a project that works really well to manage Docker volumes. At its core, Flocker is a data volume manager, so if you're familiar with Docker volumes in general, this allows you to manage external volumes with a number of different storage arrays. What I mean by that is that we sit in the middle of the stack, so we plug northbound into all the Docker toolkit, such as Swarm and UCP, and we plug southbound into different storage providers, including Dell. We're agnostic, and we center ourselves around being that unified API for different storage platforms. This allows you to use different clusters with different storage configurations, different backend storage for different types of applications. You can use us in AWS, in Rackspace, in GCE, but also use us on-prem with something like Dell, and so forth.
Use Cases and Integrations
[2:09] A little bit about how you can use Flocker. One use case is Database-as-a-Service, or just running a database in a container. Contrary to a lot of people will tell you, you do not be scared of running a database in a container. Like I mentioned, Swisscom is one of our customers, and they've been doing it for a year and a half now, things like MongoDB, Postgres, Elasticsearch. These are all things that work really well in containers. You don't have to treat it as this external service. This can be used in AWS instead of something like RDS. You can create a Swarm cluster and run databases and containers on there, and we'll automate the provisioning of EBS volumes and move those around for you, and things like that. We also provide a Volume Hub, which is this bottom right picture here. This gives you visibility into your cluster, gives you this operational flexibility to where your volumes are in your cluster, how big they are, what metadata are associated with that, and it allows you to manage your clusters that way. A number of different users have been using this. It's open source so feel free to pull it down from GitHub and start running it with Docker, Swarm, and UCP.
I mentioned Flocker has been around for awhile now, and we've been doing stateful services and containers for a couple years now, and we've been working on a lot of cool things so I'm going to talk a little bit about our roadmap and where our vision is leading us. We have a vision of not only managing data for production applications like databases, but we want to manage data in your whole entire data lifecycle so throughout the devops lifecycle including working on your laptop, pushing things to QA and test, pushing things into production, bringing them out of production into QA, those cycles. Volume Hub will sit in the middle, and not only just be a UI into your cluster, but it'll allow you to do things like work on your laptop using a Docker volume and treat it as if you would treat a Git repository. You could take and push that volume to Volume Hub, pull it out, so be able to pull a volume to another machine. Say a co-worker wants to work on that same data fixture, or pull it into QA, let Jenkins use a number of snapshots to run some tests.
[4:52] This is this last piece over here, and the right piece is how we're doing this. Flocker has been around for some time now, and the data layer is this new piece. The data layer will still work with all of our storage partners. We'll leverage everything they'd done that's really been around for a lot of time and stand on their shoulders. Storage features like compression, de-dupe, and snapshots, we're trying to take advantage of that. On top of that, we're going to build this data layer API to make the ability to push and pull these volumes around to different clouds, different coworkers, and different environments, so that we can manage the whole lifecycle. That's all I had. I'm going to turn it back to Sean, and he'll take you through the rest.
Sean: Thanks Ryan. Now, with the background of Flocker, tell a little bit about the story of how Dell Storage decided to work with ClusterHQ and Flocker. Back when I started looking at this, it became obvious that you need persistence in containers. There's a lot of workloads that you'd want to run that need some persistent storage that can be accessible across cluster nodes, and not quite follow that paradigm of completely stateless, kill here, bring up there. You need that data accessible, so started looking around at what some of the options were. At the time, there was the volume plugin for Docker, which still was relatively new. It wasn't quite clear if that was fully stable yet or not, and started hearing a lot about Flocker. Once I started looking at it, looked really good. They were not just looking at how to expose persistence within containers. They had some other things like dvol in the works. Started talking to them. The team there was great to work with, really open about their roadmap and what kinds of things they were trying to achieve.
[7:00] We decided to go that route. Then, once we set down a path, we had to decide. There's a couple options with Flocker. One of the options available at the time was to use their Cinder integration. If you have OpenStack Cinder deployed, you can configure Flocker to point at that Cinder instance and use that for provisioning storage. Dell Storage has a Cinder driver, so that was certainly an option. We tested it out. If anyone's interested in doing that, that's a great option. The one thing that I was a little concerned about was, that's great if you're running OpenStack, but if a customer's not running OpenStack, it's a little work to get everything up and running, and that's just one more piece in the environment that you need to manage and learn about and maintain. The other option that they provide is a native driver that can be implemented and used within Flocker. This actually worked out really well, because since we had that Cinder driver … The Cinder code is written in Python. Flocker is in Python, so it really didn't take too much.
We were able to take our Cinder driver that has all of these operations for creating volumes and attaching, and things like that, and leverage a lot of that code to be able to implement a native Flocker driver. That really didn't take too long. We were able to test in the 1.7 release, and we've been staying up to date on all the releases since then, and things work great. They provide a lot of tools within Flocker. I'm from Dell Storage, but if you're a competitor, if you're looking at integrating, they've got all the tools there. Take a look. It's certainly something that we'd love people to try, and get some feedback on. Our driver is out there on GitHub. GitHub.com/DellStorage, and can be deployed along with Flocker. We've tested various scenarios, either from individual Docker engine hosts, up to full Swarm clusters.
Then, once we had that functionality, or actually while we were working on that functionality … If anyone's been involved in this, there's Docker Global Hack Day. Just wanted to bring this up, because it was a really great collaboration, I think. It was between EMC, ClusterHQ, and Dell. The three of us got together. I think Ryan did quite a bit of the work. Madhuri did quite a bit of the work. I was still getting up to speed, so I tried to contribute, but those guys really did the most here. Within this hack day, we were able to add this capability of storage profiles into Flocker volumes, so that we were able to … It's one thing to just be able to provide that persistence.
[10:30] Once you have that, once you start to look at your environment and the different use cases for having this persistence in containers, you have production deployments where you want to have really good performance in your storage, or you might have just developers working on something, and performance isn't that big of a concern. The great thing about this storage profile is you're able to give that information in when you create the container, and be able to specify gold, silver, bronze, and there's some different options in there as well, so that you have a way of passing that through to the storage to have awareness of how … Whatever that means for that storage backend. In the case of Dell Storage Center, we have different storage tiers, and these affect things like the type of disks that are used, whether it's SSD at the high end, or slow SATA disks at the backend. This exposed a way to be able to pass that information in and shave that volume created on whichever storage type that you would need for your given deployment. We've gotten number three in that for the infrastructure category, but that's out there now. It's available for everyone.
Just a little bit of the technical detail of how this all ties in together. There were some diagrams before, but to really isolate that to how this interacts with the storage, the Flocker controller talks to the Flocker agent on each of the nodes. In each of those nodes, there's our Dell SE driver that gets installed, configured with the information of where it needs to communicate to to interact with our storage. Everything's through our Dell Storage Manager, formerly known as Enterprise Manager, and that configures the storage on the array.
To get back out to the bigger picture, this is similar to the one before, a little different. On the bottom there, we have the Dell Storage Array, and you can see on the left, on host one, we had two containers, C1 and C2, each with a volume. Using Flocker, you can easily kill that container on host one, bring it up on host two, and the array just follows that, and you have your volume. As this scales out, multiple host nodes, you can still keep that volume with you, still have all your data there. You don't need to repopulate that database or come up with some way of syncing files across all of your nodes.
To get more information about this, there's a lot of great Flocker documentation on ClusterHQ's site. The blog has a lot of good information talking about some of the other things besides Flocker that ClusterHQ is working on. There's a link to the Dell SC driver, if you want to pull that down. Again, I'd love to have any feedback from anybody that's running this, even if you just want to let us know how you're using it or what kind of problems it solved for you. Love to talk to you. There's more information available on the Dell Knowledge Center. This is where we keep all of our user guides, best practices and things like that. With that, I'll open it up to questions, and we'll try to answer them.
Audience: I haven't used Flocker before, but I'm curious. Storage is a huge concern with any Docker container, especially when you're running databases. Are you able to use that as a cluster so it can manage multiple hosts connecting to a single volume? Is that a possibility with Flocker?
Ryan: Right now, we treat the container to volume mapping as a one-to-one. Typically, when we see distributed databases like a Mongo sharded database, or multi-master, multi-slave kind of configurations, each one of those shards has its own Flocker volume. Actually, one of the diagrams I showed was a use case where, say a MongoDB slave fails, and you bring that slave back up. Typically, you'd rebalance all that data over the network. With Flocker, because you can manage that storage separately, we'll rebalance and move the data actually where that new slave comes back up, and you're actually only rebalancing a smaller delta. It turns out with pretty large datasets, your recovery time for those kind of systems will only be degraded for a little bit of time instead of a lot of time while you're rebalancing to the new network. Single volume to multi-container, the answer's no, just because we restrict that in terms of the block storage backends we use, but there are use cases where you can do similar setups.
Sean: There's actually some concerns with that, because unless the file system on the hosts are aware of it being accessed, you can end up with data corruption if you're not aware of what those concerns are. Yes?
Audience: What type of higher level functionality can you get? I'm thinking of a use case where I've got, say, a half terabyte database, and I want to take a snapshot of it and provide it to a dev environment to use it. It seems like this would be a good spot to manage that.
Ryan: In terms of how Flocker treats that kind of use case, today Flocker's functionality doesn't do a lot of that snapshotting and movement, but the roadmap items I did talk about, and stuff we're working on right now, will allow you to put that volume under management so that we can continually snapshot that volume, and then when you're ready to move that volume, essentially you'd be able to push and let someone pull that over. Even if it's fairly large, but be mindful that you'd have to set up that volume so that you're continually moving data, otherwise pulling six terabytes of data is going to be really slow.
Audience: Would there be a way … Because any reasonably good storage array already has really robust snapshots, and so, what if I decided I'm going to go to my storage, I'm going to take my snapshot myself. Can I introduce that to Flocker and say, "Call it Sally and present it to this-"
Ryan: Exactly. We don't want to limit how you use different storage platforms. By all means, we're going to enable users and customers to say, "I want this storage platform. It already has a really robust snapshotting platform," and just pass through and use it. We're going to enable that, but we do have options to let you use our own snapshotting mechanism as well. We realize partners like Dell have put many years into those type of operations.
Sean: On the Dell side we're looking forward to this. In other environments, that is a very common and great use case, is that we're able to instantly expose a snapshot up. Other than rescans, you can get access to that production data in a safe way in a development environment, and not have to mock out all kinds of fake information. We'll be working with ClusterHQ in being able to expose that capability whenever it's available.
I think that's time. Thank you.
Published at DZone with permission of Carissa Karcher , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.