Tip:
Highlight text to annotate it
X
Matt: Ladies and gentlemen, thank you for standing by. Welcome to the Building OpenStack
Block Storage into your Cloud Infrastructure Strategy webinar. During the presentation,
all participants will be in a listen-only mode. If you'd like to ask a question during
a presentation, please use the chat feature located at the lower left corner of your screen.
If you need to reach an operator at any time, please press star zero. As a reminder, this
conference is being recorded Tuesday, November 19, 2013. I would now like to turn the conference
over to Seth Fox. Please go ahead. Seth: Thank you, Matt. Hi, everyone. My name
is Seth Fox, and I am the VP of Operations of Solinea. As Matt has indicated, I'll be
the moderator today. I want to thank everyone for joining us this morning, this afternoon,
or this evening depending on where you are. Before we get started, I just want to give
you a quick overview of your host today. First up is SolidFire. SolidFire provides an all-SDD
based storage system that is focused on large scale IT infrastructure. Their block storage
architecture delivery is best in class QoS experience with higher performance and lower
cost per gigabyte, relative traditional fans, and I think the main reason everyone is here
today is their OpenStack Cinder API and 100% REST-based API for management. Also, sponsoring
today is Solinea. Solinea is a software and services company designed to deliver cloud
strategy architecture integration to enterprises, and service providers, and test providers
worldwide. Additionally with our speakers, I'll give
you a quick overview of them. We've got Ken Pepple who is the CTO of Solinea, and in addition
to working with our customer base, he's also lead some of the largest OpenStack deployments
worldwide. Prior to Solinea, Ken was the director of cloud development at Internap Network Services.
We're going to love their public cloud efforts that were based on OpenStack. Also, joining
us today will be John Griffith from SolidFire. He's the Lead OpenStack Engineer with SolidFire.
John is also the Project Technical [00:02:00] Lead of PTL for the OpenStack Cinder project.
What I'd like to do real quick is put up a quick survey just to get a sense of our participants
today. If folks wouldn't mind just letting us know where you are. That will help our
presenters get a better understanding of where everyone is in their process today, and guide
the conversations that way. I'll leave it up for about five more seconds, and we can
now get rolling. In fact, we got most of the responses in. I will close that out. Now,
with that, I will hand it off to Ken Pepple who will start to talk today.
Ken: Excellent. Thanks, Seth. The first thing that we'd like to talk about is a little bit
of a background to get everyone up to the same speed of what we're going to be talking
about here, and then I'll hand it over to John who will dive much deeper into the specifics
around block storage. Just to level set for everyone here and give
you background, OpenStack is an Apache2 open source project. It started back in 2010 by
Rackspace and NASA as they got together to provide and create a project around being
able to create a massively scalable infrastructure of the service cloud software. Over the past
three years, this has grown from simple two projects into now almost nine different projects
to cover different areas of what you would need for an infrastructure of the services.
These services projects have been divided into about nine different projects, as I've
said; as well as two categories. There is a number of tenant services or services that
users would actually subscribe to, to be able to use in their computing infrastructure,
and then there is a number of shared support services which are in the backgrounds [00:04:00]
to help them carry out and actually support these tenant-exposed services.
The main services that you would interact with are things like compute, network, and
storage. In particular here, we're going to talk about object storage, as well as locked
storage. However, there are a number of supporting services of shared services like we talked
about earlier. Specifically things like identity, metering, orchestration that allows you to
use these tenants-exposed services a little bit better.
OpenStack was really designed to drive industry standards and accelerate cloud adoption for
everyone; not just people that wanted to do the public clouding but also people who wanted
to have a private cloud or some kind of specialty cloud that was out there, and especially to
avoid the end of cloud lock-in. What we see with OpenStack today is OpenStack has grown
into an extremely flexible architecture for both deployment, as well as writing new services.
It supports a variety of different, what we call resources. These resources are things
like hypervisors, or storage providers, or different SPN, or networking providers.
It's wholly addressable like APIs to allow each one of the services to stand alone. What
we've seen is a large number of vendors have actually backed this to create multiple backend
off of either their hardware or their software for these services. The initially used cases
for OpenStack were -- as you can imagine since it came out of an infrastructure cloud server
provider -- was to provide infrastructures of service by service providers but also things
like creating and hosting web scaled out applications, performing big data, or even using it in Ceph
providers. Overtime, [00:06:00] we've seen many more used cases being built out on OpenStack.
With that background, we move to our next slide. As I said, OpenStack actually has multiple
ways to do storage and it has multiple services there. Today, there tends to be two major
services that people will use to be able to use some kind of storage within their cloud.
One of them in object storage and the other one is block storage.
Object storage tends to be and was one of the first services for OpenStack. It came
out of actually Rackspace's cloud files. Basically, object storage is something that people are
looking to be able to actually store and then retrieve files. It's fully distributed but
eventually consistent object store. However, it's not something you can actually mount
or have POSIX type of access to within your cloud instances. It's really well suited for
backup and archiving, as well as things like CD integration. Where you see it is, it's
very similar to Amazon S3 model. Opposed to object storage which is really
for ... Tends to be for backup and archival, we also have block storage. Block storage
is the more traditional storage that most people will think about and use within their
computing infrastructure. It allows you to have a volume or a block store unit that you
can attach or detach from your virtual instance in the cloud. It plays to have persistence
that you can still actually have hopefully some kind of POSIX or actual mountable access
to your files. It's similar in some ways to Amazon's EBS, Elastic Block Service, and it
tends to be for the more traditional ways that most people will tend to use cloud infrastructure
and cloud storage within their enterprise. The other part of [00:08:00] it is there is
a widely different workload for people who would be looking to use on this. Object storage
is really for more static content and it tends to have larger files that have a sequential
read or write to it, and you tend to get in general lower performance out of it especially
when you look at latency. On the hand, block storage tends to be a highly dynamic and it's
for your smaller random read-write or things that have highly burstable IO. It also tends
to be especially depending on what backend you use, optimize more for latency to be able
to use in your traditional database, messaging, and production applications.
While these two services are the most common services deployed and they would be certainly
the most mature, there are other services being developed within OpenStack. In the future,
you're going to see services like folders or files as a service. Instead of getting
the obstruction of a block storage volume or simply a place to put objects, Manila will
be a project that will be coming that actually gives you a file system as a service. There
will be other things coming. However, these are what we see today.
Cinder has a relatively small number of features but widely applicable features to be able
to use across almost everyone's environment. The two primary ones are the creation and
deletion of volumes, and then the attach and detach. Basically VN API call to sender, you
can create or delete any volumes that you'd like out there, and create them in sizes or
types of services that you would like. After you've created them, you can attach them or
detach them basically to [00:10:00] any server that you have in your cloud.
Now, today, you can't actually attach them to multiples, multiple instances that you
have, but you can attach them, and then detach it, and then attach it to a different instance
within your environment. There is also a number of features to preserve availability or persistence.
Today, those tend to be snapshots where I can take an exact copy of a Cinder volume,
and snapshot it or free it at any point in time or I can back it up.
Backup is a slightly different definition whereas with snapshot, I am taking the exact
copy of it. If I have a ten gig volume, I get a ten gig snapshot. Backup the content
within the volume and back it up to some object store. I can preserve content either way there.
I can also use volumes or block storage to be able to boot from. Boot from volume is
volumes can be made into images than I can then boot my actual instance off of, and likewise,
I can actually snapshot that back to be able to save that back into the object store.
You see these three classes of traditional or features within Cinder. However, there
is the ability within Cinder to create extensions for vendors. If the vendor has specific features
within Cinder or within their backend for Cinder, they can actually provide that and
expose that through extensions to Cinder that are specific to them. If they have special
features, they can create an extension to the API and you can use that specific extension
of the API to access proprietary or special features which are not in the main line Cinder.
As [00:12:00] I said before, OpenStack has a large flexibility or a great flexibility,
and being able to provide different architectures and designs, and then specifically true around
Cinder is the deployment options. Today, there are over a dozen and I think it's actually
over two dozen now, different backend that Cinder that can be deployed with.
When I talk about backend, Cinder provides an API and an orchestration service, and it
actually orchestrates some deployment backend. The backend may be things like our traditional
limit iSCSI or it could be something like, say, the SolidFire. We have different pluggable
backends that we can use. As of, I believe, the wholesome release, you're actually configured
to use multiple backends, for example, if you'd like to provide different levels of
service. For example, you can have a chip and dip option where you're just using Linux-sized
SCSI on traditional Linux server, and then you can possibly have a much higher performance
one like SolidFire. It provides different levels of service via the different backends
that you can provide. Within the Cinder service, you actually have
a number of different daemons as well as some supporting software there. If you get into
the actual configuration deployment of it, it's a very traditional distributed application
which looks actually very much like OpenStack Nova or the compute service where you have
a number of API daemons that you can run for availability. You have a scheduler to be able
to adjudicate request and route them to the correct backend. Then, you have a few service
daemons that actually orchestrate those backends for you. That's all supported by a database
and a [00:14:00] message queue. There are a number of high availability configurations.
High availability will mostly be determined by how you're going to support your database
and your message queues. These patterns that people are using today tend to be very similar
to the ones that we use for the other OpenStack services. Being able to create either master-slave
or some kind of failover service for the database, and then some kind of messaging queues is
cool but those same options actually apply here to Cinder.
Now, as I talk about some of the other things here, I am actually going to turn this over
to John. John can give us a little bit more detail here on some of the ways that we can
change backup and snapshot destination, as well as transport protocols. Then, he'll go
much deeper into different areas here on Cinder where he can actually talk in more depth about
full Cinder and how SolidFire enables a better Cinder deployment. John?
John: Cool. Thanks, Ken. Ken gave a great intro on Cinder and the block storage project,
and what it's all about. Some things I wanted to touch on that a lot of people I talk to
when introducing this get a little bit confused on this is how to actually view it from a
higher level. I am going to go over what Ken just talked about and give another take on
it. One of the ways that I describe Cinder to
a lot of new folks is as storage as a service or software to find storage. It's somewhat
of a controversial term but this is the context that tends to work a lot for people. The whole
concept is, what we're doing is we're allowing you to have multiple types of storage backends
or storage devices, block storage devices and what we're doing basically is we're obstructing
all the differences and things like that into a common API and giving you basically just
[00:16:00] a pool of block storage resources that you can utilize.
The reality is in terms of the basic functionality and the basic characteristics of those storage
devices, they all basically do the same things as Ken pointed out. Some are better at some
things than others and that's where the differences really come in, and you can really start to
expose those things through things like extensions, as Ken pointed out.
Ken pointed out also the ability to do multi backends. The concept there for people that
aren't familiar, the way it used to work in OpenStack was if you wanted to have, say,
for example, a default Linux iSCSI OVM based storage backend, and you wanted to add a SolidFire
backend, what you had to do in the past was you actually had to deploy another Cinder
note and have a whole new volume service running on the note. The reality is when you get into
using these backends like SolidFire, or NetApp, or Ceph, or whoever it might be, when you
get into that state, what's happening is that volume noted, actually that service is doing
nothing more except acting as a proxy for that vendor's API in which case having an
entire server dedicated for that is a little bit of an overkill.
What we did is we added the ability to do multiple backends on a single server. That
works great. The only word of caution there is if you're actually using the LVM service,
the default LVM service, you might not want to do that because all that storage is actually
being served from that note. He touched on the high availability pretty well. There is
really not too much else to tell there. Right now, configuring high availability in OpenStack
and in Cinder in particular is a very manual process for the sys admin that is done outside
of OpenStack. It's a matter of configuring the components like the database [00:18:00],
and the rabbit, and the message queue, and everything else all doing that outside of
OpenStack on your own. Going forward, those are things that we would
like to definitely focus on and make easier, have more integrated, and things like that
so that it's not quite as difficult to do, but for right now, that's where things are
at. The backup and snapshot destinations, the main thing there that I'd like to talk
about is on the backup side. In backups, we basically do a dump of the block storage volume
from Cinder into an object store. As of Havana, we now have the ability to configure
different backends. It used to be the only backend that you could backup to with Swift
but we now have the ability to do that to Ceph object store, as well as for the traditional
[tape 00:18:55] folks out there, typically storage manager also has a driver plug in.
What you can do is in your config file, you can specify what type of backend you want
to use for backups. Just like you can specify what backend to use for the actual block storage,
you can also do the same thing for your backup service. That's a nice feature.
The primary transport protocols that work extremely well in OpenStack iSCSI and there
is some fiber channel worth going on as well. iSCSI really is, in my opinion, one of the
most flexible ways and the most scalable methods to use.
Next ... Just a second. There you go. I had a little lag. I am very sorry.
Next, I wanted to talk about an example of reference architecture [00:20:00] that we
have. There is a built-in reference architecture for OpenStack which is in Cinder uses basically
logical volume manager to deploy volumes and things like that. That's a little bit different.
What I wanted to talk about was an actual reference architecture using SolidFire.
In that particular architecture, we have a single node running all of the cinder services
because as I mentioned again, it's mostly just a proxy or a gateway into our API. That's
not really ... It's not a heavy load for that server. We take the SolidFire 6010 and you
can few configured that as our backend storage. What we do is we use a dedicated ten gig iSCSI
network for our data traffic so that when you get plenty of performance and there is
no concerns or issues there. The key things that get really interesting
is how you actually utilize that storage and how you utilize Cinder. One of the used cases
that I find most interesting is to actually do bootable volumes and do what we call copy
an image to a volume. The things that that gives you in OpenStack when you create an
instance and when you spin up an instance, the way it actually in the default mode, the
way it works is it goes out to what's called glance which is an image repository, and it
does an HTTP pool of all the bits and the data for that image down on to the compute
note, and builds in a femoral instance that spins up and runs. You don't have any persistent
date storage on there. Everything is a femoral and this is where Cinder comes in.
Now, you can attach persistent storage via iSCSI but what's cool is you can take that
a step further, and you can actually create a Cinder volume now, and actually load the
image on to that Cinder volume. Now, you have a [00:22:00] bootable Cinder volume with a
persistent instance on it, a persistent image. What gets really interesting with that, when
you're using something like SolidFire, we have things like in-line dedup, and compression,
and things like that, and very fast cloning and snapshots.
What you can do then is you can cut glance out of the picture for your customers. We
have a number of customer deployments where what they do is they have a single, say, 500
gig development image that they have uploaded in the glance. What they'll do is go ahead
and just download that on to a Cinder volume one time, and have that as a template or a
golden volume. Then, from that point, any developer in their
team can just do a clone or duplicate of that volume and spin up their instance in a matter
of 20 to 30 seconds and be done. They don't have to go in and incur that overhead of downloading
it from glance every time, and they've got something that's persistent so they can modify
it, and tweak it, and do whatever they need to do, shut it down and come back to it later
if they want. The beauty of that is because we do the deduplication, most of those bits
end up being deduped and of course, that's a huge savings in terms of the space usage.
The next thing, I want to talk a little bit about what's new in Havana. Havana was the release
we just came out with for OpenStack here last month. There's a few new features inside of
Cinder that I wanted to talk about. One of those is the ability to do volume migration.
We had talked about the ability to have multiple backends and things like that, and how HA
works, [00:24:00] and so on, and so forth, but one of the things that you have to consider
is if you have all of your volumes deployed on a certain backend, what happens when you
actually want to take that backend out of service and introduce a new one or what happens
if, for example, you have to do a far more update and people can't use that backend anymore
or something like that. What we did is we put in an API mechanism
to allow you to actually migrate the data off of one backend and transfer it over to
another. It is a live migration. Depending on the backend you use, it will determine
how long that migration takes and how robust it is but the whole goal is to basically have
live migrations that eventually will be completely seamless to an end user. An admin, for example,
would go into the API, request that the migration is performed. The end user still continues
to go about his business and use the volume in whatever ways he's using it. Then, when
everything is ready, the admin can just pull the plug on the old volume backend service
and things just pick up on the new one. That's a really big advantage that we started
to work on. It's in the first iteration for Havana. There is a lot of improvement that
are planned and coming down the pipe in the next release. In the next six months, we'll
see a lot of improvements there. Another big feature that we added was the
ability to extend an existing volume. The idea here is, for example, if you created
volume and there was 50 gig, for example, and somewhere you decided, hey wait, I actually
need 100 gig, so on and so forth. Instead of actually having to deploy another Cinder
volume, and attach it, and use it, and go through all that trouble, now, you actually
have the ability to just go ahead and extend the size of that volume. That's a really nice
feature and it's handy to have. Then, one of my favorites is the ability to
actually transfer [00:26:00] ownership of a volume among tenants. Inside of OpenStack,
you have tenants, all of the resources are isolated between the tenants. With transfer
volume, what you can do now is, for example, if you're in Department A and you have a volume
with a certain data on it, or certain information, or something like that, or maybe one of these
images that you created, you now have the ability to go ahead and give that to Department
B. What happens is you go into the API and you create a transfer. It gives you back a
key. You give that key to whoever you want to give it to in Department B. Then, they
can go ahead, and claim it, and take ownership of that volume, and utilize it.
The other thing we talked quite a bit about backups and we keep mentioning that. One of
the things in the backup code for previous releases up until Havana was that it only
works for certain backends. Mostly, it only worked for backends that had their own internal
implementations or things like that. As of this release, we have a generalized backup,
so no matter what backend you use, you can do those backups to the Ceph object store,
or the Swift object store, or the TSM that I mentioned. There is a generalized mechanism.
It may not be as efficient for some as others but it is there and it makes it so that everybody
can play. There are some things to think about when
you're deploying Cinder, a couple of considerations and best practices to keep in mind. The first
is anytime you're talking about cloud and you're talking about OpenStack in particular,
you're usually talking about massive deployments and you're also talking about deployments
that are going to change overtime and be dynamic. One of the top things to always think about
is plan to scale. Depending on your use case, and [00:28:00] what kind of shop you are,
this might be something as simple as just continuing to add Cinder notes. The thing
about OpenStack is it is horizontally scalable. To gain more, all you have to do is you don't
throw more disc drives into the system. What you do is you just add more notes to the system.
The scaling thing is something definitely to keep in mind. Keep in mind that it is horizontal
scaling that you're going to want to be thinking about. Is your backend device horizontally
scalable, as well as Cinder which is horizontally scalable?
The other thing to think about is in a cloud environment, you're going to have varying
workloads. There is going to be significantly different workloads throughout your environment.
If you have, for example, 200 tenants, they all might be doing different things. Some
may be running databases. Some may be running websters. Some may be doing some sort of test
dev environment. Because of that, it makes the cloud a little bit challenging because
especially with block storage because you have to try and figure out how do I actually
plan and deliver for all those varying workloads? That's something definitely to keep in mind.
The other thing I touched on was multi-tenancy. In this cloud environment, especially if you're
going to do things like public clouds, you're going to have all kinds of different tenants
and different people accessing these systems. OpenStack does a really good job of segregating
those tenants and keeping them isolated and dealing with security and things like that,
but you also want to think about your backend storage devices as well. Does it have the
concept of multi-tenancy? Does it have any sort of security enhancements or anything
like that to take care of that? Another problem that you need to think about
is what's called the noisy neighbor issue. The noisy neighbor issue, for example, [00:30:00]
is if you're all sharing one particular storage device. Tenant A, for example, is running
a database and Tenant B is running his database or test dev environment or whatever. The things
that you're going to run into on some systems, some backend storage systems is if, for example,
Tenant A is doing some heavy read access of the database, he may be stealing all of the
IOPS off of that backend device. The result is Tenant B then is starved, and gets no performance,
and can't get his work done. That's a huge problem. You definitely need to take a look
at things like that, and consider that, and keep that mind when you're choosing your backend
storage implementation. Then, of course, one of the most important
things especially when we talk about the scales that we're talking about and all of the automation
and everything else, fault tolerance, as well as failure recovery. Things happen, things
break, they always do. It is just a fact. No matter how hard you try, you can't develop
your way out of failure. These things can be on the Cinder side or they could be on
the backend storage side. You need to take into consideration how you're going to deal
with that, how you're going to deploy your configurations to actually meet failure scenarios
and recovery from it quickly and efficiently. You need to figure out things like depending
on the backend that you use if you lost your Cinder service or your Cinder node, for example,
do you still have a way to get into the backend storage device that you're using and remap
all the tenant volumes and everything, and get everything back online, or are you stuck?
Those are things that you need to think about. Then, of course, also on the backend itself,
you need to figure out what exactly the failure risk for that device is. Is it a fault [00:32:00]
tolerance backend? Is it a clustered storage device? Things like that. Those are all considerations
that you definitely need to take into consideration when you're deploying.
I touched on some of these already but the other things that in terms of the actual backend,
these are basically the key bullets. These are the takeaways that you should get from
that previous slide. First, you need to look at performance. In performance isn't just,
it's a super, super fast storage device. Performance is things like is it performing across the
board? Is it consistent? Can I control that performance?
The other really big on here is scale. I mentioned before, when you talk about OpenStack and
everything, you definitely talk about things at very, very large scale. Do you have storage
device? You need to have a storage device that you can scale, that you can scale horizontally,
and you can continue to grow as your needs dictate in the future.
Then, of course, high availability is huge. We talked about the failure scenarios and
things like that. You definitely want to have something that if you have a 1000 volume sitting
on this device or if you have 100 and some tenants, you can't really afford to have that
backend storage device just go away and be unrecoverable, or have it take days or even
weeks for you to recover all that data. You need to be able to recover quickly and seamlessly.
Data reduction is a huge thing to think about in cloud deployments. The reason why is because
the reality is many of these customers, many of these tenants, they're going to be deploying
Linux servers or Windows servers even. There is a huge potential [00:34:00] for data reduction
there that will allow you to save a lot of money and extra cost.
Finally, the Cinder integration. Ken had mentioned, there's well over a dozen products, closer
to two dozen different backends. They're integrated in backend storage devices that are integrated
inside of Cinder. The thing to keep in mind is fairly easy to write a functional driver
that works, and deploy, and get it submitted into the OpenStack code base. It's completely
another thing to actually understand how all the components up above inside of OpenStack
are utilizing that and keeping everything up to date and keeping things sync so that
they work. OpenStack is a very fast moving project. It's
constantly under development, always new features coming along, and so everything inside of
that ecosystem needs to grow together, so that is a really important thing.
I touched on the reference architecture and some of the things that we see there, and
I wanted to just real quick just talk about some of the real world used cases that I was
thinking of and keeping in mind with those. We have a public cloud provider named iWeb.
They do a lot of exactly what I described. Along their customers and their tenants to
do things like do bootable volumes and boot from volume for their instances, and so on,
and so forth to get all the efficiencies and benefits and speed out of that.
In addition, what iWeb does is they utilize the SolidFire cluster which gives them the
ability to actually sell different IOPS provisioning to their clients so their clients can actually
pay based on what they're desiring for performance, they can select the IOPS levels. On the SolidFire
cluster, the QoS allows you to set minimum IOPS, maximum IOPS, and burst IOPS [00:36:00].
What this translates to from iWeb's perspective and their customers is they can actually purchase
tiers of storage in performance for that storage. We also talk about in more of a private cloud
type of environment, we have quite a number of customers that are doing things in the
same manner. They are just doing it locally for their dev teams. We have specific web
2.0 companies. They are doing things like spinning up hundreds or even thousands of
instances on SolidFire volumes, for example, and using that in their test and development
environment. Through OpenStack and through the SolidFire cluster, they're able to do
that extremely efficiently and extremely quickly, and they are able to do things that they weren't
able to do before. That's a little bit about where we are and
where we've been with Cinder and the block storage project. A little bit about what's
coming up in the future. It's really early in what we call this next release as Ice House.
We're still working on defining a lot of the features and functions that we want to attack
and we what we want to prioritize. Some of the big things that we really want
to look at are furthering the integration with what's called Trove which is database
as a service. This is one of the supporting services that Ken had mentioned that sits
on top of the tenant services. We really want to develop that further and get some more
efficiencies and enhancements there. Basically, what that's doing is allowing you to literally
deploy a database setup through the OpenStack APIs. Once you have all the other components
down below in place, then you can go ahead and do this. It's got a lot of potential.
It's really a promising project. There is [00:38:00] also things like big data
as a service. We're looking at doing Hadoop and things like that. There's some really
interesting things coming for Ice House. Definitely, keep your eyes peeled. We'll be blogging and
posting things between our website, and Twitter, and everything else talking about this new
features as they're coming out, as we develop them. There are a lot of good things coming
there. With that, I am going to take a look here
at the questions. Seth: John, I can read up and and we can go
from there. John: Sure.
Seth: Sure. John: Okay.
Seth: First question we've got is, earlier John, it looks like you were talking about
how images that transfer the volumes. You'd also mentioned the possibility to eliminate
glance in the SolidFire technology. The question is they want to confirm that they heard that
correctly and if so, can you elaborate on that a little bit more?
John: Yeah, sure. It's not so much eliminating glance. I should clarify. The idea is, I mentioned
before, the way the default OpenStack, the way it works is every time you boot an instance,
it actually goes out to the glance server, and the glance repository, and does an HTTP
transfer of all the bits for that image. That's every single time. The way that I would describe
or qualify our technology in Cinder, eliminating that is it doesn't actually eliminate glance
but what it does is instead of doing that every time, it only does it once. You go out
and you do that once you do a copy image to volume one time, and then you just clone that
volume. It's [00:40:00] much more efficient and it's much faster.
Then, also for some people, some people don't like having a femoral instances. They don't
like having to rewrite their apps to figure out how to do things like recover from that
failure mode, spin it up another instance, so on, and so forth. Having a persistent instance
is actually a huge advantage for a lot of people as well.
Then, of course, keep in mind, you can still do the same. You can do the reverse as well.
You can have volume that you deploy an image on and modify it and everything, and you can
upload that to glance as well. Then, people can use that in the future.
The key that I was trying to get on there was basically there are definitely more efficient
ways to boot an instance in OpenStack other than the traditional download instance from
glance every time. Hopefully, that helps. Seth: Great. Excellent. The next question
we've got is about any plans in OpenStack to implement provision to IOPS similar to
EDS today? John: Actually, that's a great question, and
there already are. That's already available. By using something, specifically if you're
using SolidFire, the admin has the ability to create what we call volume types. Those
volume types can map to certain IOPS settings. This is the use case I was talking about.
iWeb for example, they sold this to their customers, and so on, and so forth, and that
is exactly what that does. The whole idea is yes, you can provision.
You can set these specific IOPS and do that. In addition, as of Havana, we did also start
work on things like rate limiting at the hyper values, running things like that. That's another
option as well. Seth: We got another one in the queue. This
is talking about [00:42:00] scaling. How do you really scale the Cinder API in a high
traffic environment? John: That's a really good question. That's
one of those deployment considerations that you need to figure out and you need to look
at. If you are doing ... If you go the single node route, depending on how much traffic
you think you're going to see from the API and things like that, this is something you
need to consider. Do you actually need multiple API servers? You can easily do things with
Cinder, with all of the OpenStack projects. You can have multiple API endpoints and just
put a proxy in front of them, and just let it do a rules-based scheduling, or load balancing,
or whatever. There's lots of options there. One of the things that you can do in particular
is you can start with a single Cinder node deployment, and then depending on how things
go, you can decide whether you need to scale that out or not. You can grow that and grow
into multiple nodes. The API question is interesting because depending
on the environment and depending on what's happening, that is going to dictate how heavily
that API is used. Typically, for block storage, what you see from a lot of people is it's
not nearly as free point as things might be in some other APIs but it just depends. It
totally depends on the deployment and the customers that you end up with.
Seth: Thanks, John. Ken. Ken: Just to elaborate than that, within block
storage, the API node actually aren't in the data path. It's only being used as a control
path there. It's probably going to have a lot lower traffic than you're probably used
to in an object store where actually the API sits actually within the data path. Obviously,
it's a complex system [00:44:00] sometimes, so there's different things depending on which
different things you actually want to scale there.
John: Yeah, excellent. Thank you, Ken. Good point.
Seth: Good. This next question, I think maybe for Ken. You talked about these different
systems to launch different APIs from the Openstack side to send to APIs, what type
of automation tools can we use against these types of systems?
Ken: It depends on what you're looking to automate there. We have people that are looking
to automate within the instance and they tend to be using things like Chef and Puppet to
be able to install packages and things like that. You can certainly do something like
that but usually you could be able to bring block storage in and things. You're really
looking for something that does what we call orchestration, something that can actually
create instances for you and hopefully, multiples of them, attach block storage to each one
of them, configure your networking, and a number of networks that you need.
Today, you have a number of options to be able to do that. There are commercial options
out there from vendors like Dell which has Stratis and Service Mash which was recently
bought by CSC, but there is also OpenStack projects. OpenStack key which is a new project
in Havana actually allows you to do that orchestration to be able to create stacks which is a number
of applications, as well as network and block storage that you can add to those things.
It really depends on what you're looking to do, whether you're really looking to do configuration
management, or it is more orchestration, or that you want to use open source, or you've
got a proprietary vendor that you'd like to use for those. However, all of those, you've
got open APIs for this so you should be able to use theoretically anything that supports
those open APIs. Seth: Great. It looks like I've got one more.
Does [00:46:00] Cinder work with Ceilometer in any way to handle publishing and storage
of performance mix? Ken: I am going to let John answer that but
if not, I can. John: I'll let you go into the details, Ken,
but the short answer to that is yes. Ceilometer does go ahead and do periodic test employing
into Cinder and extract information. There is a good bit of work that needs to be done
to add some more functionality there and some more features. Ken, I'll let you touch on
any details that might be more interesting there.
Ken: Sure. I think today, mostly it is gathering events and some summary statistics out of
there. If you know at a time how much block storage somebody has or which volumes they've
created, I think you can find things like that out of Ceilometer today. However, if
you're looking for how many IOPS they view or how much traffic they're pushing across
there, I don't think some of those things have actually made it to production yet within
Ceilometer and they're probably things you'll see in Ice House or whatever we end up calling
J later in 2014. Seth: I've got more question about economics.
Is there anything that you can be pointed to understand that the TCO of the OpenStack
SolidFire deployment model versus other storage solutions blended with OpenStack?
John: That is a really good question. The thing is in terms of the TCO and the things
you have to look at as I mentioned before, things like the dedup, the scalability, and
things like that. Also the performance. The thing to keep in mind [00:48:00] is with our
solution in particular is you get to do things like set those minimum IOPS and maximum IOPS,
and actually divide up the performance of the system, and actually pull it out as resources.
The problem with other systems when you're trying to do things like fight the noisy neighbor
problem and stuff like that, the only way to really guarantee any sort of performance
or do anything with that is to actually just provision more storage. Just completely underutilize
the backend device. In exchange, what you get is you get better performance for all
of your tenants and all of your customers but that's not really a good option. That
drives your TCO way up because now, you're buying way more storage than you actually
need. From our perspective, the performance aspect is one huge TCO benefit.
Then, the other thing is like I mentioned you, things like deduplication and compression,
those are huge benefits as well. The other thing to keep in mind when you're talking
about TCO is things like fault tolerance and fault recovery. The fact, with our device,
it's a clustered storage device. It's not a RAID. It doesn't have a single point of
failure, control, or anything like that. The thing is we can do things like lose drives
or even lose an entire note in a cluster depending on your configuration. In most cases, it's
completely seamless to the end users. They don't even know. It's also self-healing. All
the rebuild is automatic. When you talk about things like TCO, those
are all the different things that you need to think of. In addition, you need to think
about things like what you're getting for your money. With SolidFire and OpenStack,
for example, you're getting a platform and a company that is dedicated to OpenStack actually
invested in working in OpenStack fulltime and not just on their component but on the
entire [00:50:00] project. They understand how things work or we understand how things
work and how things go together. Then, we also have a first class topnotch
testing. Testing support, that's another huge thing to consider in TCO.
Ken: Yeah, I'd agree there, John. I also think for customers that are looking and very interested
in what their TCO, and either cost or TCO, or any of those things. Solinea and SolidFire
have a lot of materials to help you along with this. Solinea has helped a lot of customers
in understanding their TCO and their budgetary view of the instant cloud and what it's going
to cost and what are the benefits going to be.
In addition, SolidFire provides a lot of this especially within the service provider market.
If you're looking, if you go to this market, SolidFire and Solinea can help you both on
that upfront piece but also about how you might market this and go to market with it.
Seth: I think that looks like all the questions. Take a look at SolidFire.com. [Inaudible 00:51:13]
blog some additional details and give everyone a ... To thank John and Ken today. I think
this is a great session, and if anyone has questions, please follow up directly. With
that, I will hand it back [inaudible 00:51:33] to close this out.
Matt: Ladies and gentlemen, that does conclude the webinar for today. We thank you for your
participation and ask that you please disconnect your line.