 You guys hear me? Okay Good The good thing is I can't see anybody in the audience right now because I'm being blinded by these lights So if you've got any questions or anything, and I don't recognize you just Yell out and also we've got these microphones in the aisles here if you've got any questions during our Q&A Session at the end. Just feel free to come up and blur them out or interrupt or however You'd like to interject that. Welcome to our session. My name is Rob Young. I'm with Red Hat I'm here with Chris Merz from NetApp and with Amrith Kumar from Tessora We are here to talk about expanding Deboss workloads with Openstock Trove and the cool thing about this is we are also working together on a spec In a blueprint on how we can extend the storage options for Trove to include Manila So if you're a system administrator You're very familiar with legacy applications mode one applications if you were in today's keynote You'll find this very interesting because you can now plug in or you will be able to plug in Trove database as a service Applications into the traditional file system implementations that you're very you should be very comfortable in working with So let's go ahead and get started We're going to save our questions for the end we're going to have an open discussion Q&A session at the end So bear with me our agenda for today is I'm going to kick it off again. I'm Rob Young with Red Hat I work with our Openstock team. I'm a technical product manager. So I work very closely with engineering On our Red Hat Openstock platform I'm going to handball to Amrith when we get to the database as a service discussion to talk about Trove The architecture the benefits to using Trove In a public and hybrid cloud environment over, you know, some of the other options Chris is going to take over to talk about the Manila specific storage option that we have the architecture there the file system We'll have some key takeaways and then we'll have some open discussion So just real quickly if you guys were in the keynote this morning, you know, there was a really good discussion From the Gartner folks about mode one and mode two applications You know, this should be near and dear to a lot of people's in this room's heart because you know mode one is the traditional enterprise application That we have out there around accounting around just making sure our business is doing what it should but mode two is probably while most of us are here right now because of Openstock and innovation and how those two need to be married and The problem that that we're seeing right now is just overall applications are more dynamic now the lady who gave the talk or This morning from Gartner was spot-on when she said, you know, more than 41% of revenue will come from digital-based Applications and these are applications that you know can't be delivered via waterfall technology. They have to be, you know From concept to deployment days versus weeks or months So this is a big problem time to market a lot of pressure on guys like me on people in this Room to deliver on that. The other thing is developers need a quick way to deploy Databases that they're going to be testing with and doing QA on and you know writing documentation against If you've come from a development environment like I have 20 years ago 10 15 years ago I had to go to a DBA to Request such databases things like my SQL Maria DB those things didn't exist You know I was working with Oracle and SQL server and other things and I needed to be a DBA to set up my test environments Not only for you know my development cases, but for rolling over into production and you know nowadays That just can't happen. The DBA can't be a bottleneck in this case So the other thing is the TCO that you know comes along with Databases of service or just deploying databases in general is a lot higher in the public realm If you've got a private option to do these things you can dramatically cut your costs from an AWS or you know Some of the other public providers that are out there. So We just want to talk about you know some of these problems and how we are working together to solve them as a trio So if you look at open stock right now There is Pain that comes with success So if you look at the overall core components and I've I've got the four here because I think keystone is a big part of this as well security But when you talk about networking compute and storage as these things have matured and people have you know Seen them stabilized within their environment. They know how to administer them. They know how to deploy them they're looking for additional ways to Save money or to innovate within their own environment. So the survey that was mentioned this morning in the keynote 97 97% of the people say they want a standardization of API is 92% want to avoid vendor lock-in blah, blah, blah But 62 66% want to save money and when you look at things like, you know, the ancillary Services like as a service for trove for Sahara for file systems things like that These are things that can easily be brought in to any of these Reasons why people move to open stock as a justification And if you look at the number one thing the number one as a service component that people are adding after Their core components have matured and have stabilized its trove and databases of service And we get we didn't make this up We actually you know pulled this directly from the the user survey and talking to customers This is pretty much the trajectory that that we see as well as a company at Red Hat so in our database as a service and You know that the reason why I think people are looking at this as a very attractive option for them trove specifically is because it allows a higher granular level of control for developers for People that that that need databases quickly and can stand them up and burn them down very quickly It also lowers the TCO building versus, you know renting something from AWS for a platform and the cool thing about Dbos nowadays is it's not only limited to open source databases as Traditionally has been found to Sora Amroth. We'll talk about this in just a minute They provide proprietary options as well. So if you want to spin up your own databases of service in-house on a Private or a hybrid cloud you can do that on the platforms that you typically wouldn't have been able to just a few years ago So open-stack Dbos Specifically the trove project, you know, this is a mature. It's a maturing I should say a big tent project and Chris will talk about this a little bit in just a couple of minutes But it's going to provide the flexible storage options for data database creation Stand up and burn down for backups for, you know The different needs that you're going to traditionally have found a DBA needing to service But you're also going to find storage options on the back end that are somewhat limited right now But growing all the time. This is where innovation comes in and the traditional use cases that I mentioned before Around the mode one applications Enterprise-wise these are going to be much more of a topic when Dbos and Manila are Integrated so with that I'm going to turn it over to Amroth from to Sora He's going to walk you through trove specifically the architecture and the advantages of Dbos Thanks, Rob You guys able to hear me? Okay It's Rob said I can't see you so so let's talk briefly about database to the service My name is Amroth. I am with to Sora or the trove company. I'm also the PTL of the trove project for the Newton cycle So as Rob said the benefits of databases of service are That it's much more than just provisioning if you wanted to do just provisioning you could do it a million ways You could use Ansible or puppet or chef or whatever But unlike other parts of your application the database is one thing which once you create it is going to stick around for a long time So provisioning is just the beginning Once you provision a database you got to make sure that it's continuously maintained It's secure. It's up-to-date with whatever patches you need and from time to time you need to do things like take backups But databases are also Complex beasts in another way. Nobody runs a single instance database in production So in order to achieve high availability Performance you use things like replication and clustering and for anybody who set up a database Setting up a database as a single instance is Hard it's boring after a while, but setting up clustering or replication is painful and No, no industry at this point is Using a single database in their data in their enterprise. You have multiple databases each of which does these things in a different way So the motivation of databases of service very simply is to reduce your cost But more importantly to reduce your risk and to make it easier for you to consume databases in your enterprise So the benefits of databases service are drive down your cost Make it safer and easier to use your databases and we'll talk more about how some of this stuff works So since we're going to be delving a little bit into the details of how trove works and I'm gonna give you a brief overview of you know trove architecture Trove is a maturing big tent project. It's been around for a while and it consumes the services from the core open stack Components, but you're on the right-hand side. I don't know if you're able to see the little dot But there's no one top cinder swift glands neutron and keystone the core open stack services, which you need If you were to provision a database instance Through trove which is the service on the left you talk to the trove API and there's other service components within trove Which do the actual things that trove has to do Your actual compute instance is coming to you from something which nova is going to give you The storage you get is going to be something your persistent storage for your database at this point in time is Necessarily going to be a cinder volume either that or you're provisioning something like redis And you don't need persistent storage and you're using an ephemeral volume, but The whole gist of this talk is in order to get Mature applications to use databases you need more flexibility in that storage area and we're talking about how we're going to improve that When you want to do things like replication or clustering or backups We use swift for some intermediate storage. That is something which we want to extend as well There's some work underway to make seph a possibility for that But just swift or seph is not the answer. We need to have more flexibility in that area as well If you have a question unless it's really quick, can we hold it to the end? Okay, great question. The question is when I say replication of database. Do I need to raise your coding? Okay? answers no Trove provides you with an abstraction for a database. So let me tell you what replication I talk about Give me a single instance of my sequel which basically means what you're gonna get is a Nova compute instance with my sequel running on it It's a single database Give me a replicated pair of my sequels says give me one master and multiple slaves Where the data is maintained by the database? With postgres replication is by the database Trove does not physically implement replication trove Uses whatever capability your database has for replication or clustering So the clustering which trove provides is the database's native clustering So we say cluster of mongo instances. It's mongo clustering. We talk about okay So trove is gonna be a consumer of the services of the other open stack projects And we support about a dozen databases at this point some relational some non-relational databases But the most important thing to remember is we automate a lot of workflows We do not physically implement the mechanism by which the database must do replication We use whatever the database does for replication and we give that to you as a managed service. That's what trove does We do not physically implement backup Whatever mechanism the database has for backup and we'll talk about backup as a specific example in a second We give you that capability. We simplify configuration management as well. So let's take an example specifically of backup One of the very important things about trove is we do not want to reinvent the wheel so Let me give you an example of how something like backup works every database Technology has a notion of backup. So let me talk about say postgres You can do backups with trove in postgres in one of three different ways. You can do a database dump You can use Bercona backup Bercona extra backup or you can do incremental backup. So trove implements a notion of a strategy to do the backup The user requests a backup of trove trove uses the database native backup utility as a strategy And then sends the data at this point to a place which is Swift The goal is that in the future that storage should be abstracted in such a way that you can use not just Swift but Cinder or Manila People who've used Oracle have for a long time realized that running a database on an NFS share is a great way to do things In the cloud one of the restrictions you have and this is you know whether it's the Amazon cloud or Traditionally the open stack cloud if you have a Cinder volume an EBS volume you can attach it to one and exactly one VM at a time Which means if you want to run something like a database with shared storage, this is not possible However running databases with shared storage is a very very common and important use case. So how do we do that? so let's talk about Maybe some of the use cases which are going to need that like Rob talked about originally there's three primary things which people do with the database There's the developer who just wants to quickly spin up a database and try something out For that person a single instance a single VM is perfectly satisfactory However, there's a person who wants to QA a system when you QA a system you want to test some things which are slightly more robust What happens to the system if some infrastructure fails? How do we recover for that you need something like clustering or replication? And at the far end of the spectrum you may want to have a production database One of the important things of Trove's model is by not reinventing the wheel and Just using the primitives for compute in this case that Nova provides us On the far end of the spectrum with bare metal we can use Nova with the ironic driver and get bare metal Everybody knows about VMs in the middle That's the bread and butter of Nova on the far left. You can use either small VMs with small flavors or You could use the Nova Docker driver Nova compute LXD or something like that Use a flavor and use the flavor to drive the hypervisor you want all three are provided today Bare metal and VMs work just fine If you want to use containers you have to do a little bit more and there's sessions to talk about that at the summit but at the end of the day what I want to highlight is Trove's architecture builds on the other projects and By not reinventing the wheel we can support a very broad variety of use cases So one specific use case from a database perspective, which we want to address Which is particularly important to people running applications with significant amounts of data So take the example on the left-hand side I have a developer who or I have a QA organization which has a database. Let's say it has 200 gigabytes of data and They want to quickly provision an instance so that a QA person a test person can run some tests The notion is they have sample data and they want to quickly provision a bunch of Instances with that same data set and when they're done with it. They're going to destroy the instances very common use case fine there's an entirely different use case for a production database and Let's assume that that vertical sequence down there is a time series At say 10 in the morning, it's fine three in the afternoon. It's fine at six in the evening It's fine at nine in the night. It's fine and then something goes horribly wrong a Production use case for this is to say at the point where you find that it's not okay Just revert to the previous use case Okay, now if you think about this from a storage perspective These two models are two very classic use cases for snapshots The sample data is a snapshot Every point in time is a snapshot the example on the left is snapshots with cloning The example on the right is a snapshots without cloning Currently the mechanism which mechanisms which trove has to do backups Do not leverage these smart capabilities which storage So if any of you has used storage from for example net app and Chris is going to talk about this in more detail These are things which are available today with the storage subsystems and trove is not using So what we are planning to do is to improve the integration so that When you have a 200 gig data set and you want to launch a new database The answer is not make the new database and load 200 gigabytes of data The answer should be clone the snapshot and you're up and running much faster and The example on the right is not take a backup every time of your two petabyte database and then be offline for You know unknown numbers of days when you restore it The answer is revert your snapshot which with some storage subsystems the matter of seconds Both of these are real production use cases which people want on their databases which are operated by trove Which is what we plan to do so With that, let me hand it over to Chris who's going to talk more about How some of these things are done with Manila, which we're going to be talking more about later. Thanks Emerson. I Really can't see anybody That's better So my name is Chris Mers and I work for solid fire now part of net app and I'm going to talk today And continue talking about the the Manila project and integration into trove databases service so Basically just to give you an idea of of what Manila is a brief overview It's it's it provides shared file system as a service With an open stack addressing a critical gap in the Open-Sex storage services coverage and it basically enables a new category of on-demand file storage based on infrastructure as a service To put that simply Manila does for shared file systems what Cinder does for block storage basically you can provision file shares via self-service API and So a tenant could say, you know, I'd like a one terabyte File share and make it available to this particular network range of hosts and then Manila will manage the share security and handle the plumbing of the underlying network and storage artifacts the the project began back in 2013 and there it was a basically a fork of the Cinder project since the shared file services was not something that was within the the eventual Charter of Cinder and At that point, you know, the architecture is fairly similar except in areas where divergence was necessary To cover the complexities of shared file systems It's production proven There's nearly two dozen drivers for back-end storage and active feature development. There's one of the one of the most interesting things is The the file share types, which is send, you know, very very similar to Cinder volume types Which allows you to expose the underlying characteristics of the storage architecture that you're actually using and In many ways, this is One of the keys to the integrations that that Amrith was talking about the ability to To utilize storage capabilities within the context of Trove and databases service is something that is very very interesting to a lot of people and is where you can truly accelerate the benefits of the entire architecture together the idea that you can use Snapshots as was mentioned or clones to Speed up operational activities such as making copies of data sets back up and restore You know, this is not just an incremental improvement. This is a radical change of mindset in some cases, you know Increasing speeds of data transfer to orders of magnitude because you're actually pivoting the database architecture Around the place where the data exists on the storage itself And this is one of the goals of further integration of of the various Storage projects in in to Trove We see and our customers have have told us specifically that This type of integration as we're talking about with Manila into into Trove is a critical bridge for enterprise adoption There have been There are basically three ways in which you're going to be using storage. There's going to be object Block and file. That's that's that's the triumvirate of storage and with the Manila project That that gap is complete that you we've got it all covered now It doesn't matter if you're using fiber channel. It doesn't matter if you're using I SCSI and it doesn't matter if you're using NFS You you can adopt OpenStack and Trove in the way the best suits your infrastructure investment both in terms of the hardware and the skill set So the idea here is that you know, there are there are many many traditional core mode one mode two apps that are designed for shared file system and this has been the case for many many years decades and by lowering the migration barriers for enterprises and We're we're encouraging people to to step into OpenStack in a way that is Familiar and comfortable to them. Let's talk a little bit about the Manila architecture If you if you know anything about the sender architecture, this is going to look fairly familiar to you You know commands come in via the rest API or the horizon dashboard the auth manager acts as a gateway from there the the scheduler the API interact with the stateful data and the sequel database and The messaging queues interact with the drivers and you can have many different types of shares with many different, you know many different back-end drivers so in that case is you know, like I said, it's it's a fairly similar architecture to sender but the You know the the capabilities of the underlying storage systems are going to be surfaced through the driver and that's going to let the Basically the the system know what type of storage you can provision as a share type and what its capabilities are going to be or There has snapshot capability some idea of what the performance is going to be and that type of thing and By surfacing this further into Trove The idea is to allow When you go into provision databases in in Trove to to choose your storage type as an option There's not just a default when you set up the system, but actually have You know create database classes and say well, this is test dev of a particular type, so we're going to need a You know a large volume low performance shared file system for this and or this is going to be a production database We're going to need a high performance Cinder volume for this or you know depending on what type of database you're deploying and some databases Are really well suited for using using shared file systems, you know oracles is one of them And as you have enterprises who are exploring OpenStack orchestration exploring Trove Databases service orchestration they're going to ask the questions Okay. Well, how can I take my existing existing system and migrate it into OpenStack? Well, I use NFS and Oracle. How am I going to do that? And we're attempting to answer those questions providing an easy path of migration and adoption So, you know to understand the the true impact that You know the manila has in the database world. You have to understand The network file system and and go back a ways so NFS has been around forever It was invented by Sunmicro in 84 It's still today the most common shared file system protocol in the storage world It provides a flexibility ease of deployment that is unmatched by by other storage systems So, you know, I was looking through the Oracle rack installation. I had a few weeks back and and the You know has the various various storage types are using and the the NFS Section just had one line in it Make a share install it and move on to section six and and the it's still the de facto Enterprise database standard for for many many many global companies and it's trusted and proven and You know when I first started getting into this, you know, I was coming from a different aspect I came from a block storage background and and so well why NFS and Veteran looked at me and said why not NFS it works It isn't broken. Why are we trying to fix this exactly? Why should I change the way I've been doing business for two decades in order to to come into open stack? And I said well, that's a really good point so, you know, there's got lots lots of lots of Advantages, you know inline snapshots the ability to access snapshots from the file system and the host itself rather than having to have a storage administrator action Data-sharing between hosts, you know, there's there's just a ton of of good reasons why people continue to use NFS and and frankly prefer it over Fiber channel or iskazi is as protocols so You know just to talk about the key takeaways for today Basically as Rob said earlier co-op the core open stack maturity and stability translates to expanded use cases and you know as we Get into those expanded use cases. We want to lower the barriers to entry For enterprise adoption that is that is a goal for for many of us within open stack is we want more people using this great system and The these kind of key enterprise integrations make the open stack tent even bigger You know, it's already a big tent But we're trying to make we're trying to expand the walls the tent make it even bigger and and invite people in In services like trove and manila can dramatically simplify the use of databases in in the open stack cloud and You know, once the critical core applications of an enterprise are in open stack Full migration can be achieved and that and that is the ultimate goal so with that To hand it back over to I'm with for a minute. So let me Put on my trove PTL hat for a second and say there's a whole bunch of things Which we're doing to make trove better If these are topics which are interesting to you or if this particular topic is interesting to you, there's a session 520 in the evening on Wednesday, please do attend it If you're working on one of the other open stack projects Be great to hear from you But if you're somebody who is using these kinds of capabilities in your enterprise We're really interested in your feedback on the things which we can do to make trove better that Reviews 520 on Wednesday the spec itself which I put up for review a while ago is the line above There is also another spec for integration for snapshot backups Which is a I believe cinder focus spec and There's a there's a full list of all the things which we're doing in trove List of all the reviews if you want to comment and contribute so they'll be absolutely welcome as well I'm gonna pass it back to Rob and then we can probably get on to Q&A and I believe if you're interested all three of our companies have boots in the marketplace, so please come over and see us Thank you. Thanks, Amar. So if you got any questions or for the open discussion We tried to reserve about ten minutes if you'd like to come up to the mics Or you can even huddle up here when we're done if you like but just real quick if you're already running open stack in Production and you need help all three of our companies are very well suited To to help you with that. So if you're even just getting started you want to do a POC or whatever you've got questions about these things Here's the the product and services information the for red hat. It's the open stack Platform so if you're interested doing a Google search on that or whatever to Sora provides a database as a service Platform so if you're interested in the open source Sequel no sequel or if you've got advanced needs around Oracle, you know other proprietary databases They can help you with that as well and the net app has got just a plethora of storage options Not only for for open stock, but other applications as well So if you've got any questions about any of those things Amrith has mentioned the commercial interests are out there in the marketplace Just just stop by you you'll probably learn more than you really want to know Actually, so with that here Is the best way to get in touch with any of the three of us? We're all active on our C if you'd like to follow us on Twitter email whatever smoke signal however You know we'd love to talk to you about trove Databases of service Manila or any other aspect of open stock for that matter So just to seek us out. We'd be happy to help you out and with that That's the end of our session. Thanks for attending and if there are any questions open discussion. We'd love to entertain them now So, uh, okay. Well, um, well, thank you for attending. We'll be up here for a couple more minutes Enjoy the rest of the show