 Good afternoon, thanks everyone for joining. I know it's getting late in the day and Eyes may be getting a little droopy, but we're going to try and make this an interest interesting presentation for you My name is Bill Owen. I work in the spectrum scale development area at IBM And I'm responsible for the integration of open stack with spectrum scale We have Brian Nelson and Simon Lawrence up here on stage with me also to help with the presentation and then send deep Patel and Goron Top I say have been helping with the presentation as well. So I wanted to give them credit But what we wanted what we wanted to talk about today? Thank you What we wanted to talk about today is how you can take some of the Open stack components and combine them to solve some interesting types of problems So we're gonna start with a problem description and from there talk about a potential solution then demonstrate that solution for you So one problem is let's say we've got a media production house or potentially a professional sports team With the media production house You've got a number of subsidiaries in each subsidiary is working on projects concurrently where they're filming Different projects and they need to store that film and process that film Or with the sports team in the NFL for instance every game is filmed every player is Filmed individually on every play So at the end of the game you've got all this different video from different cameras that needs to be compiled edited and Condensed into something that's given to each player. That's kind of a grade So a lot of work to do that and furthermore it's typically done by most teams for every practice also so you've got a huge amount of work editing and Grading out the players on each of these activities So a lot of work is involved in getting that information into the system and doing the editing and then distributing it So the way the process would work in either case is that employees collect videos And they need to upload those to a central storage location and in this case we think object storage is the correct Correct storage target Next once they've uploaded their video the employees want to edit that and They're using sophisticated editing software and typically that wants to access the data from a file interface When they upload the data, they're putting it into a container and they're using their credentials to access that container We want them also to be able to use the same credentials when they access that from the file side So you don't have two different users or two different passwords you have to deal with it's all one person Finally or the next I'm sorry is Multitenancy because you may have different competing projects going on you want to be able to segregate the data so that My subsidiary can't access Brian subsidiary for example And finally because of schedules and priorities changing all the time You want to be able to easily ramp up the number of compute resources or ramp them back down if they're not needed So you have the most efficient use of your resources and you can handle the peaks and load But the basic pattern is you're ingesting data from the object interface and analyzing it or processing it from the file interface Okay, so let's look at what a solution to this might look like And Again, what we're going to talk about next is a solution architecture That works for this and similar use cases We'll do a demo of a sample environment a sample deployment and then talk about some of the challenges that still remain or Have been solved to put this into a production environment Okay, so the overall solution looks like this and we've got a number of open stack components I'll talk about some of them in more detail next but at a high level We've got open stack swift and it's the repository for object data Swift on file is a plug-in or a disk file module for swift and it's what enables accessing the data from the file interface Open stack manila is the service for managing shared file data So it allows you to create file shares and publish those to multiple vms or to physical resources also Behind it all is a shared file system and that's kind of the the the glue that links everything together And then for authentication and authorization keystone plays plays the role there and keystone can Integrate with different kinds of back ends like ad or LDAP back ends And by doing that that allows you to have a unified authentication mechanism for both file and for the the open stack primarily Especially the the object interface. So you've got the same user credentials being used for both interfaces And finally, there's the rest of open stack. That's nova, cinder, glance, neutron All of those play a role in completing this solution Okay, so in more detail open stack swift is highly scalable enterprise class object storage It has a rich and growing set of features And a couple things that are really important one. It's extensible. There's two Primary extension points one is through custom middleware And the second is through pluggable back ends where I can replace an existing swift module with my own version of that module at these plug-in points And finally, um swift supports both the swift api as well as the s3 api And for a lot of clients today, that's really important to be able to use s3 because that's what their existing software is based on Okay, so that that tells us how we're going to get the data into object storage and and how it's going to be held But how did the file file applications access that data? Well, that's where swift on file fits in So a background swift on file was a red hat contribution to open stack in 2014 It allows you to write data as an object read it as a file or vice versa write it as a file and read it as an object It's implemented as a disk file module And again, what this this means is there's a the object server has a plug-in point And you can have different disk files depending on what type of Of underlying storage there is And the disk file can is responsible for abstracting away the the the details Of that underlying storage and providing a common interface across different storage types Also, there's swift storage policies. They allow you to have swift on file fit Nicely into this environment coexisting with the traditional The traditional swift layout But the key point is that clients can access data directly from the file interface They don't need to go through a gateway. There's no copying of data. They're accessing it directly from the file interface for the highest performance So storage policies again this What they do is allow you to specify for a set of containers What kind of storage layout what kind of replication level is required? So in this example, um, the top storage policy is the traditional swift storage policy And it's got its own ring associated with it again that that dictates how the objects are laid out on the systems And in this case, they're traditional servers with, um locally attached disk the second object Object ring and second storage policy at the bottom is a clustered or shared file system And in this case the ring says in this clustered file system. How is my object data laid out? So with that ring definition You've got a url that tells you how to access an object and it looks like this And the key parts are the last three tokens the account name the container name and the object name With community swift This will be located on one of the systems at this path and it's pretty uh pretty ugly path And you can see that the account container and object name don't show up anywhere in there What swift on file does is organize the data in a way that's consumable by humans and by applications So the path is the account name the container name and the object name And when you go to access it from your file application, that's that's where you go to So now we know how to access data from the file side, but how do we make this access? um Remotely available, how do we easily can configure remote vms to access the same file data? And that's where manila comes in the picture So manila is the shared file system service for open stack It provides a uniform interface for underlying file operations again abstracting the details of the underlying storage system And there's quite a few different vendor drivers today. I think something like 15 different manila drivers The kinds of operations its supports are listed here, but things like creating and deleting shares um creating snapshots And allowing you to create a share from a snapshot Managing share access rules specifying which vms or which um servers can access the the data that you've exported One of the important ones for this use case is the ability to manage and and unmanage existing data sets So within the object storage environment, we've got a collection of data in somebody's container We want to take that existing data set and publish it or export it using manila So that feature comes in plays an important part in this use case And finally lots of other features consistency groups replication, etc Also manila has varying degrees of multi tenancy support depending on the requirements So with certain customer requirements, you can implement it in a very simple way Or you can use neutron and the the virtual lands that it supports to do a higher level of multi tenancy Okay, so this sounds pretty good. I've got all the main components I need But how do I share data between Swift on file and manila? That's that's where the shared file system comes into the picture and you can see in the diagram here You've got a shared file system. It provides a common data plane for open stack storage Each of the the vendors that are Providing shared file systems have a different set of features, but the core features include things like Snapshots and backups automatic tiering of data between different types of storage So you can have some data in high performance storage and other data in cheaper slower storage depending on how that data is going to be used And automatically move it between those pools based on activity Also different kinds of replication local site across multi site replication. Those are some of the features that are provided by the the shared file system Also a shared file system enables some unique features within open stack One example is nova live migration If you have nova backed by a shared file system, you can move a vm from one compute node to another compute node Basically, transparently also The ability to share data between glance sender and nova using a copy on write mechanism is a pretty powerful feature so that you can Efficiently use your data and also quickly provision new systems And the features of course are going to vary between different vendors, but the idea is the same The benefits of of that common data plane Okay, so all that seems simple enough at this point I'll hand it to simon for the demo Yeah With the following demonstration, you would like to show you how swift and manila could be combined To for unified data access or sharing across instances So let's have a short look at our demo environment We're using a swift proxy node with a swift on file configuration Connected to a scale out file system. We additionally run a controller node with manila and nova installed Also attached to the same scale out file system We will launch a couple of vms, which will mount our nfs shares To demonstrate how two organizations can securely share the same environment We will create two projects or accounts with one container each and with the help of manila, we will create two shares Passing to the containers The containers will be assigned to a swift on file policy Additionally, we have some demo footage that we will upload Into our container one The object will be made available through the nfs share to our vms Additionally, we will run cation live images to edit this footage We will render it and save it back into our nfs share We will objectize the file and will publish it via swift to see the results Obviously, this is a pretty small setup for real world cases use cases So actually on the left side that could be any video surveillance application or any live setups that are ingesting data into our object store It could be hundreds of accounts that are uploading data into the object store On the right side that could be any file based applications such as live video production systems or professional video editing systems With the help of swift on file and the nfs shares The file based applications are able to work with the objects But as files directly without any data movement or any need for a gateway So now let's have a closer look and start configuring our demonstration system First we will create Two projects So the first one will be named 10 and one and we create another one 10 and two And we create users Which we want to use So it'll be user one We will set the primary project to 10 and one We do the same again for a user two, but now assigning to 10 and two So now we have this setup the next step would be to create the containers So we will create the first one with the user one and the tenant one And as I said earlier the containers will be assigned to swift on file storage policy And we created this in advance. We can show it here to you with swift capabilities command So here you can see it's named sof. That's our storage policy So now let's create the container It will be container one and we assign the sof Storage policy to it And now here you can see our base pass to our storage policy It will also hold our account Directory and account directory will hold the container directory as explained before my bill So that means any object uploaded into this container one Will be ending up under this pass Now we do the same again for our user two and tenant two And we name it container two assigned to the same storage policy And we have our container two directory So now let's create an instance and the shares for it. So we log in as user one And we create an instance We will name it VM one We create a source We select the source and also a flavor And we launch the instance So once it's launched you will see it will connect to the dot 10 IP address. It's important for later So next step the second step would be creating the share You will do this here Actually this the manila plug in so we name it share one The host of the share we can get with the help of the manila pool list command You can copy it Next thing we need is the export location and we said we want to have our container one as The export pass so we look it up and we copy it Into The GUI it will be an nfs share And as share type we select gpsf as a spectrum scale As it's named now And we create the share now as a third important step we need to give access to our VM So we create a share rule and We add the dot 10 IP address to give Um access to it So now we repeat the whole thing same procedure for our user two We will create an instance which is named VM two And also a share two We fast forward this a bit now Here you can see now it will be the dot 11 IP address Stop here you can see we will Point it to the container two pass Again an nfs share And we ask manila to manage it We create a rule for it and now we do that for the dot 11 IP address So basically now our system is set up Let's have some demo footage that we upload into our object store Actually, this is a catamaran journey that I did where I nearly Flipped the cat here's where we brought it into the water So this footage is now uploaded into our object store actually into our container one So let's have a look how this was done on the cli. We use the user one the tenant one And uploaded video one dot mp4 into our container one That's actually just an example on how to do it that could be done with any swift client or s3 I could have even done it on the boat with a mobile connection So now actually we want to access the footage Through our nfs share that means we have to go to our VM one and mount the share So that will be the next step we do So we lock into our dot 10 instance and We have a look at our mounts that are available So it actually shows two now here. That's caused by the fact that we used flat networking If you use neutron you will have the possibility to assign vlans to tenants If you do that, then this has the effect that only would have one The first one would have shown here The others not So let's mount it we do that here done and let's have a look at the content of our share and there is the video one dot mp4 So now let's prove that we are not allowed to mount the second share from our first instance So we try that here We need the directory to do that we try and As expected we get an access denied error that's caused by the share rule that we created earlier Also as a side note the manual steps we see here for the mounting they will Not be needed in the future as of manila auto mounting work that's ongoing So now let's edit the footage we Opened kdn live and we want to open the footage into the application Therefore we select our nfs share. So we go to the mount directory Here's our file we open it And we can start editing it We fast forwarded this also you will see the result later on So once the editing is done, we want to render it and save it Actually, we want to save it back into our nfs share So we select the mount directory again And save it with a new name video one cut Dot mp4. So now we'll start rendering and finish saving it. We fast forwarded this also So let's have a look at the object side and Run a swift list on our container one to see if it's there And yeah, there it is video one cut dot mp4 So you might think wait a minute. There's a step missing We rendered the file we saved it in our nfs share as a file How it is it? How is it introduced back as an object now into our object store? The solution to this is that we run a service that checks the content of our nfs share And as soon as it finds a new content, it will check if it's already in our object store If not, it will objectize it That's the service that you will see here That's doing this so that actually happened exactly to our Rendered file and that's the reason why we now can access it as an object So now let's have a look at it what the result is we log in as our user one And we select the container one to see the content And there it is again We fast forward the download a bit and have a look at the result directly That's there's nearly flipping actually my journey coming to the summit Nice windy So let's have a short summary of what we just showed We uploaded demo footage into our object store As of using Swift on file and the nfs share we had direct access To our file based application and we were able to edit the footage That was done without any data movement and without the need of any gateway So we rendered it we saved it back Into our nfs share as we had the direct access to it And we objectized the result and were able to publish it from the object site to look at it So that was a complete Turnaround to show you so unified data sharing across instances by using Swift and Manila Actually, there's more functionality and enhancements needed and brian will take care about that Thanks, Simon. He got to show all the fun stuff just putting up files editing playing with him But Regardless of how the file gets on the system. It's still a file And so from the object side, it's your swift services who are saving this And if you did nothing the file side would likely not be able to Write to the you know write the file might not even be able to read the file depending on how the permissions are set up So as we go through this with the Swift on file One of the challenges was how to manage the credentials so that the Swift interface and your legacy file applications Can both read and write the files as necessary And so through the use of the the Swift middleware We When an object is being uploaded this middleware will ensure that the file the file permissions are changed so that such that They match the credentials for that account and And that way these legacy file applications to them. They are They have no knowledge of any sort of Swift Or cloud or anything to them. It's just a normal file and they're able to interact with that in In that manner In the future We would like to have more integration with the ACLs So that you know in Swift you can set up these these ACLs and we could perhaps map them into the file and And like also with quotas as these you have quotas in your object side We'd also want to be able to mirror that on the file side And depending on either side how it how it gets defined the other side also Is updated as appropriate Um And um, you know another important challenge, um, and it's not so easy to solve solve this is just that the Knowledge and the expectation of using an object and the knowledge and expectation of using file Are very different and these legacy applications You know, they're not going to change, you know, so Uh, it's in some cases it depends on the User and application workflow in your environment to manage these this situation in terms of You know when objects are being uploaded and when they're being edited It may take some perhaps just user knowledge of these steps so that you know, they don't have the File expectation that I can lock the file And prevent any object uploads because it's kind of two different systems trying to live together um the In the future, we would like to sort of tighten that up so that we can have You know a little bit better coordination Between the two and so that you could have this sort of simultaneous access And uh, and they would sort of fit together in a in a much more seamless way But yeah, so those are just some of the the challenges that we've had So now hand it off to bill for some of the conclusions All right, thanks brand All right, I'm going to go back Two slides just to highlight one thing that in blue there at the bottom We have another presentation on thursday where we're going to go through in more detail Some of these extensions we've made to Swift on file Including in more detail about how we do the user id mapping Okay, so in conclusion Um open stack provides a really nice set of building blocks for constructing systems That allow us to solve a wide variety of customer use cases the second point An enterprise shared file system can be the glue that helps these applications work more efficiently together And what we showed today was a pretty simple hypothetical use case based on these components But our our hypothesis is that the infrastructure that we presented Can be used to solve many more complex real life use cases that our customers are facing today So with that thank you for joining and let me know if you have any questions And a couple of announcements too commercials so um we just released um our team just released a Red paper that talks more about the integration of open stack with spectrum scale So it goes through more sender a little bit of manila and talks about the the integration points Also, ibm has a couple um has several other sessions today That are presenting different aspects of ibm's cloud strategy Okay questions Sure. Thank you a very nice presentation Uh, you mentioned that there is a service that updates metadata in the object if the file is created through nfs Uh, does it uh based on some kind of notification mechanism or it just scans periodically the data and finds new files So what we've implemented today uses a scanning mechanism to look for new files and when it detects there's new files in the system It will do the update But we've got work in progress where we're looking at other more sophisticated mechanisms including event notification And that's something that we're investigating for the future And at the the presentation thursday, we will talk about that aspect more also Okay, and another question. So in your demo you show that you open one file and you create another file. Can you modify a file? Sure, we could save back on to the same file From the file interface and that would be exposed from the object side. Yes Okay, but it will take some time until the scan mechanism figures out Correct. Okay. Thank you Okay. Hey, uh, just wondering if you guys are planning on writing a native manila driver for your swift on file thing You know, uh, I know you're you're you're planning on having this script to update stuff And create objects on the fly after you've you know made modifications in your file store and stuff So would it be helpful to have a driver do that for you? Instead of a separate service So We do have an existing gpfs spectrum scale manila driver for doing the manila share management Having another driver to do that objectation objectization process I don't I don't know that that would make sense to do as a driver. I think it really is More of a demon background Consistency type of process like the swift updater or the swift audit object auditor. Sorry Okay, makes sense. Thanks So I probably have dozens of questions that wait till thursday Your implementation details, but I had one use case question Do you see any need for there to be simultaneous access? to the object as a file And the object is an object We haven't had customers asking for that. So That's that's the best answer that we don't have that as a customer requirement today Having said that Again, our long-term goal is that it would support that and that the two interfaces would become Really tightly integrated the way that smb and nfs are today. I see I see and also in any interest in smb And from your customer for your use cases, is it just you use the nfs example, but is there smb interest? There is some yes Our manila driver today is just nfs, but one of the things we want to Have on the roadmap for the next year year and a half is smb support also excellent. Thank you You're welcome Any other questions? Okay, thank you very much for joining us today