 Actually, we'll pass them out right after the first exercise we'll do. So you should all have now, or soon at least, have a small little thing that gives you an IP address, a username, and a password. That, for doing this first exercise, we're going to kind of go really quickly through it. If you want to follow along, do so. You can log in using SSH in your terminal, or if you happen to have a Windows machine, you can do it using Putty. We're going to go really quickly through the first exercise. Hugo here is going to be typing along. And you can do it. It's going to be a lot of typing. If you get it wrong, don't worry about it. It's not a big deal. We basically just want to sort of show how you deploy a regular Swift node using the command line. And so you're going to want to prepare your laptops and be ready with a terminal for that exercise. The SSID should be, what is it, OpenStack Hong Kong? It says on the back of your tag. And I know the password is Havana 13. Yeah, OpenStack Summit HK. And the password will be Havana with a capital H. And then lowercase A, V, A, and A, 1, 3. Yeah, Havana 13. So obviously, if you want to follow along, you're going to need the internet access. Once we're done with the first exercise, what we will do is we will go ahead and do a second one, deploying Swift using Swift Stack. But before we do any of that, we will go ahead and do a little bit of a Swift overview and how it works. So how many here actually knows about Swift? A few people? Great. How many people have actually deployed Swift here before? Awesome. OK, so what is OpenStack Swift? It's a reliable, highly scalable, and hardware-proof object storage platform. Background on it, if you've been here today and followed the tracks, Rackspace was the sort of inventor of Swift. And they committed it to OpenStack as part of the first release. Now, what is Swift Stack? We're a company dedicated to OpenStack Swift. We provide OpenStack Swift software being able to do a controller and managing your entire Swift infrastructure with our controller. It's really simple to deploy this using the Swift Stack controller. And underneath on all the nodes that we deploy, it's just OpenStack Swift vanilla version, just like you would get it from the open source repositories. So back to this, today's agenda will be kind of packed. So we're going to go through pretty fast. And if you have questions, please keep the questions to afterwards, because we're probably not going to be able to answer questions as we go along too much. We'll be here after the fact, and we can stand outside and we can take your questions as you want. If you happen to get stuck during the exercise, just raise your hand, and one of my colleagues will come over and try to help you. If you can't finish it up by the time we're done, we can do it afterwards as well. So sorry about that. Then so we're going to go through the Swift Basics here. We're going to deploy Swift at very high speed on a node from scratch. And we are then going to go ahead and do it with the Swift Stack controller, as I mentioned before. All right, Swift Basics. So as you may know, this is an all HTTP access. They use an HTTP API to access all the objects in the object store. Swift relies upon something called the ring. There's a ring for the accounts, the containers, and the objects. There's also a concept of something called partitions. The partitions are not the kind of partitions that you're maybe used to on a disk, on a regular Linux system. It's more kind of like a directories on disk that uses a hashed value to map data across the cluster. The way you make that happen is to use something called a ring builder. The ring builder is an application in Swift that builds the ring, and we use that to push out the configuration to the cluster. And then every time you make a change, like you're adding a node or dropping a node or adding additional disks, you regenerate the ring and you push it out to the cluster to redistribute the data across the cluster. And the data is also sitting, is also always, always on three different disks throughout the clusters. There's three replicas for durability. The OpenStack Swift HTTP API works, as you can see at the standard URL up there. It basically is a regular URL like you would see in any browser using a web application. And you can access files that way. It maps it into account, container, and object. So if this was Jane had an account, she would have Jane Doe, and she would have a container called Documents, maybe. And in that container, she would have a file.txt with something in it. What's really important about this notion is that this is not a block storage device or block storage system. It's not a file system, it's an object system. It only speaks HTTP natively. So what you get is basically an HTTP call into the cluster. And then everything that gets mapped inside the cluster is still speaking HTTP. So the ring creates the account, container, and object. And it shoots off these three, once it hits the proxy server, it shoots off three different copies to storage devices inside there. And the partitions are then mapped on the disks. And data gets spread in the cluster over these different partitions. So basically, because you have a lot of different partitions on disk, those partitions is actually what's getting moved around. It's not the file itself but a partition. Because if you did it per file, if we're talking about billions and billions of objects, it will take too much overhead to track all that. So what gets moved is actually the partition itself. And that partition gets hashed. So it's checked via an MD5 sum. And if the MD5 sum matches from disk to disk and between the partitions, nothing happens. But if there's a change, it will actually be replicated and moved and make sure that the three copies of everything resides in the cluster. The one cool thing about Swift is that you can actually use different size disks if you want. Let's say you start out with two terabyte disks. Now a year later, you actually have three terabyte disks and you can deploy using those. That's obviously going to be cheaper. So the next time you add another node, what you can do is you add the disks and you add a weight. That weight, we typically recommend using a two for two terabytes or three for three terabytes. And the partitions then get evenly distributed across these different disks, depending on how many partitions and the weight of the disk. So how does this all really happen and it gets put together? The builder database, it's kind of like a lookup table. It tracks all the different devices, being the disks over time. And it contains all the data so that deterministically it can place the object in the cluster based on the partitions. So when the ring gets built, it gets pushed out to every single node and lives on every single node and it gets checked so that that ring is the same on every single node out there. And like I mentioned earlier, there is a ring for the account, the container, and the object. In the first exercise we'll do, you will notice that the ring is deployed on the node. And if you had many, many nodes like that, you would have to do the exact same thing. Make sure that that ring gets distributed across the cluster. Because if you don't have the same ring on all the different nodes, you're going to end up having problems. With the SwiftStack solution, we manage that through our controller so that that ring gets pushed out. Once it's out on all the nodes, it gets flipped over and the new ring gets deployed. All right, so the number of replicas. The ring builder settings takes three different parameters. It's the number of replicas, which typically we recommend to use three in a regular cluster. That's a value that can be changed depending on your needs. But three is typically a good value to use. The number of partitions. The rule of thumb here is about 100 partitions per or times the number of drives that you think you will ever have in your cluster. That's kind of a hard question. Like how do you actually know how many disks you're going to have? Maybe you know because you're only going to be running a backup case. Or maybe there's some finite number of files or objects that you will be storing and you can figure that out. But generally speaking, it's probably better to go a little bit above what you ever think. If we're talking petabytes, obviously, it's going to be pretty big. So you take the 100 partitions times the number of drives that you think you will have, and then you round that up to the nearest power of two. Then during the life of a Swift cluster, your partitions, because you always want to make sure that you have availability and durability of your data, you don't want to move the partitions around too much because you will suffer availability problems. So therefore, there's something called min part hours, which describes how fast or how often partitions can move in the cluster. Basically, what we want is to have two partitions to always be the same and be static. So there's only one allowed to be moved based on some number. That number is typically a 24-hour default. So what that does, it helps ensure that there's at most one replica of data being moved in the cluster. That means that if there's a call coming in to get an object, in the worst case scenario, that call will always find two of your identical replicas. The third may have moved, but all the other ones will still be there. So that way, the availability is ensured in the cluster. So the redistributing partitions. In this example here, we have three disks. We have four partitions on each disk. Now, if we grow the cluster, so we add another disk, we have to rebalance it, like I described before. Rebalance it will basically move the partitions. So you add another disk. And from the first row there, you'll see the four partitions. Now you will have three partitions across four disks instead. OK, the three replicas. So when a client requests or puts in an object, what will happen is it will hit the black box here, which represents a proxy server. And the proxy server will then put three different replicas into the three different disks. What happens here is, before the writes are going to be considered successfully written, the object servers will have to respond with two OKs. Basically, it's called a quorum, and it's really a majority of the number of replicas that you have. So in this case, with three replicas, we would have to have a quorum of two. That ensures that there are at least two different objects written to different disks in the system. And even if the third wasn't successfully written, over time, replicators and auditors will go through the system and place that third copy where it's supposed to be. So what happens if a driver dies? Luckily, they figured out this thing. And there will be handoff locations that are deterministically put into the system. So if that disk dies, where it's supposed to go, what happens is there are at least two or three different handoff locations where that object will be placed until the disk or the ring has changed, and the data will then be replicated back to the third. So then you have your three different objects in three different places. So here's another example of partitions. And in the first row here, we have six different partitions. One disk dies. The replication will move a partition to handoff locations. And those partitions will then end up on the different nodes. So it's kind of the opposite of what we saw when we were adding disks before. All right. So does everyone have one of those little tags now? So Hugo here is going to log in. Can you see this OK? Someone can't see it. So-so. Does it help if you make it a little bit bigger, Hugo? Yeah, can you? Contrast is not good enough. Buzzy, maybe? Yeah, maybe the focus is a little off. Can you make the text white, maybe, Hugo? Foreground there. Let's drag it up to the white. All the way to white ups. Better? All right. Cool. OK. First thing you want to do is you want SSH into your node. So that should just be demo at some IP address. The password should just be password. This virtual machine that we have in here is the latest Swift, the Havana release, 1.10. This is a VM. It has five disks that are virtual disks in this case. We have already installed Swift on this. So the Swift package is already installed. However, we haven't done anything except for preparing the Swift config file. So the first thing we're going to do here is we're going to go and take a look at what the file system looks like. Now, this is going to be a lot of typing. And Hugo has done this a lot of times. If you, when you're done and you can show the last step of this, ready? Raise two hands. First person that can show that they have it running will get a Swift X t-shirt. All right, this is going to take about 15 minutes, hopefully. Ready? Go. Or did that. OK, so take a look at the file system. You can take, just go into do a df minus h. You can do a block id dash o list. And you'll see the different drives in the system. Once you're happy with that, go in and make yourself root. It's password is sudo on this one, so it's fine. Now, after that, what are you going to have to do is you're going to have to format the drives, make XFS file system, set the size to 512. You want to label the disk d1 through d5. And you will see that the way that the disks are laid out is dev slash mapper slash vxv dd and so on. Be careful here. If you mess it up when you type, you're going to have to redo everything and figure out where you went wrong. Afterwards, if you want to make sure that you're all good, you can run the block id minus o list again. So who goes moving along here? Once you go through these motions and type in the different things, you will see the same output that who goes having here. So all this is doing is formatting the drives, putting a label on the disk. And for convenience sake, we're mapping it to d1 for disk one so we can keep track of all this stuff in Swift. And later on, you will see that what this does is it maps into the ring and everything, so. All right, who goes done? I'm moving on. Now, what you're going to want to do is you're going to do make a few directories here and you can do that using the makdir minus p. And what we're going to do, we're going to mount those drives at locations that map to the different disks. So we're going to do that at slash SRV slash node slash disk one and so on. We will share this with you, this presentation. So you can go through it again if you want. Once we have created all the directories here, step two, that's cheating, because now we're going back. What's that? We have a better solution for that. All right, so once the directories are done, you're going to have to mount those drives that we created before and put them onto those mount points. We'll see, where's Hugo here? Oh, yeah, he's almost done. So last thing here, at the bottom, you're going to have to make sure that Swift has the proper permissions. So what you will do is you will change the ownership to Swift for all the different mount points. And Hugo was helpful here enough to do an LSLA on the SRV node directory, and you can see he's got those directories mapped in there. All right, now we're going to create the builder files. So hopefully you got this sorted out. What? One more, okay. Someone's getting ahead of you here, 10 seconds. What you want to do next is you want to go to change directory into Etsy Swift. Once you're there, you're going to want to run the ring builder command. There's something called an account builder, a container builder, an object builder. Remember we were talking about having three different rings. And you're going to run those commands and you're going to create them. So 14 is going to be the partition power here that we're using. Three is going to be the number of replicas and the min part hours that we discussed earlier, that's going to be the one in this case, in this example. So once you have that done, you're still in the Etsy Swift directory. Now, we can run a lot of tons of typing here to actually get this done, but to do this we're going to do a quick little for loop here to make that happen. So basically you will take all the object container and account and you will map that to the different disks into those and then you'll run the ring builder which will then map that into the node that we're running it on which is just the local host. So one, two, seven, zero, zero, one. And the standard ports of Swift which is running 6,000 to 6,000 five. And then it's going to run that until it's done. Intense staring at the screens, I like that. Just type it exactly like it says. Where are we here? Hugo is almost done. Warnings, you shouldn't have warnings in there. Oh, yeah, yeah, okay, yeah, yeah, yeah. That's fine, yeah, so while we're waiting for this to happen, I'll give you a few seconds. I'll discuss something that we didn't really touch upon earlier which is there are zones and there are regions. Regions are essentially super zones. They're physically separated. Zones are generally false domains and a false domain you can think of as being a rack. You may have a top of rack switch. There'll be a single point of failure and you'll maybe have 10 nodes in that rack. If you do that, you probably want to consider that rack of one zone. If you happen to have Swift over multiple data centers, they would reside in different regions and that's what we call global clusters and that would basically make multiple regions with different hardware act as one large cluster. All right, here we go. Okay, last thing we want to do is we actually want to run this with Ring Builder to get this all created. And you will see that this will output some more data across your screen and it will run the balancer. There we go. Okay, last thing here, we want to make sure that we rebalance the rings. And you notice that we have to do this for every single ring that we create, the account, the container and the object. And as you do this rebalancing, the balance should go to very close to zero. Now, once you've done that, run an LS for star.ring.gzip and then you should see rings having been created, account, container and object. Okay, last thing we'll do here now is to start Swift and you do that with a Swift init command. And here we're using restart, we could have used start but restart safe. And if you're interested in looking at what that looks like when Swift starts, you can do, you can tail the Swift all log and you can see a bunch of stuff happening. All right, hopefully you all have your Swift node up and running at this point and it's actually started. With Swift comes a command line client called Python-SwiftClient, it's installed here. And if you want to take a look at, or upload data into your cluster, we've conveniently placed an image in your home directory. So if you CD home slash demo, you can take and upload an image that we put in there using the Swift command line client. What you will do here is you will take, you'll type Swift U for user. We've created an admin user here already for you. So you can use admin colon admin. There's a password which is the minus capital K which is this admin. We have minus A which is the auth URL for the cluster and here you're just gonna auth against your local host. So HTTP127001 slash auth slash v1 and upload catscloudcat.jpg. What that does is it will upload into a container called cats, the image cloudcat.jpg. Now we haven't really created the cats container yet. It will actually be auto created when you run this command. And once you've done that, if you wanna list it, you can go ahead and do the same, rerun the same command, but at the end you run list cats and that should output cloudcat.jpg on your, well if you're ready. So last thing here is you can download the cloud cats again. You can go to another container or another directory or something and download it. Once you've done that, you've done you ago, yep. Now you can make the container world readable and you do that by basically posting to the container, the cats container and what you do there is you're setting the ACL on it to be readable by everything, by everyone. Now once you've done that, you should be able to open a web browser and then take the lower part there and input your VMIP, the public IP that you SSHed into. And hopefully you will see an image there. Uh-oh, can someone take a look, help her? A tool over here, second row, did anyone get it? We have, did you get it? Did you get it beforehand? Who's the winner here? So obviously we did this really fast and as you, if you actually have, if it doesn't work for you now, it's probably because you've done some, you've had some errors in typing stuff in. It gets kind of complicated to do this and if you think about all this in scale, at scale, it's kind of a, it's not that easy to do and especially not when you're on a time pressure to get it done like we've done here. You got it Hugo? Okay, so does most of you have it working? So in the interest of time here, we're actually right on schedule, but in the interest of time, because we're gonna go through the Swift stack way of doing this now, next. We can help you troubleshoot afterwards and we'll have a few people around to do that. So if we can have, start handing out the other handouts here. So this new, this handout is for the Swift stack way of doing this. It's another VM that you can log into and you can deploy Swift from ground up using our controller. While they're handing those out, any quick questions before we start on the next one? Yes, how does this talk to Nova? Well, so object storage is really not a good fit for running a VM on it. It's eventually consistent. So if you have, in this case, we have three replicas, right? If you were to run a VM off of one of those replicas, you don't really know which one of the replicas the VM would talk to, which is problematic because that's a constant stream of data going back and forth. Therefore it's not a really good fit for running VMs on top of an object store. What you wanna run VMs off of is a block storage kind of system. What object storage is exceedingly good at though, is to store lots and lots of unstructured data and meaning images, documents, medical records, sure. Yeah, that's. Log data. Yeah, log data. It could be anything, any file of any sort. Anything like that, yes. And it does so, and it stores it very adorably, meaning that loosing data is virtually unheard of in an object store, unless you make some very serious mistakes. But, and it does very well with high concurrency, meaning thousands and thousands of users at the same time, inputting and getting data out of the system. So, in terms of the use case for Swift, I noticed we have one of the Mercado Libre guys here sitting in the front row, they have taken Swift and they're using it for their application, putting images at 1.5, 1.5 billion images that they're serving. Yeah, so, and they have massive concurrency and tons and tons of users hitting their site all the time requesting data from it. So, that's where Swift really, really shines, right? So, and yeah, so the comment was that what it's also really good at is actually serving up images, VM images to Nova that they can be used and put onto block storage to run it off of there. So you can make templates of VMs and store them and then you call them up when you need them. That's a very, very common use case for Swift. So, everyone have the handout now? Have you been able to log into the next VM? Okay, cool. First thing we will wanna do is actually, I need one of the handouts. What you wanna do is you wanna start going to workshop.swiftstock.com and you wanna log in with the credentials. This is the Swiss stack credentials. It's username WS1 something or zero something. And the password is just password again. Once you do that, you should see a screen similar to what I have. You can call this new cluster we're gonna create just workshop because we're only gonna be using one VM here. We don't really need a partition power of 18 that's completely overkill for this. So, I'm gonna set mine to 10 across both of these both for the object and the account container. I suggest you do the same and I'm gonna hit create cluster. Let's take me, oh, okay, I already have one. Great. Now I'm gonna log into the other one here. So, the password is also password. So, if you've gotten your workshop running here, what you will do is do a curl command, HTTPS workshop.swiftstock.com slash install underscore Ubuntu. You can do a little bit bigger and you will pipe that to bash. What that will do is it will run a command on the node which will install Swift from ground up all the open source bits that we know and love as well as some Swift stack monitoring agents and deployment tools. So, if you run that, whoops. Helps if I spell that right, workshop. There you go. You should see a bunch of packages install. It will take about a minute. Once you get those packages installed on your VM, you will get a claim URL. It will show up at the end of this install. All right, there's my claim URL at the bottom. Does everyone get that? Cool, now take your claim URL, paste it in up there in your address bar and the controller is now linking up to that node. You'll see here that you can claim this node as normal as not being a replacement of a node. If this was a node that we had previously used, it would actually recognize the node and know it and it will import all the settings from it. But we go ahead here and just claim node. It will contact, establish a VPN connection to the node that we installed it on. This typically takes 30 seconds or so. At the end of this, you should be getting a green bar like that and you can go ahead and claim the node. Now, the node still isn't in a cluster, so we wanna add this into the workshop cluster that we created and you can go ahead and add the node and you will see the node as unprovisioned down here and then you can click on ingest now. Here's the zone that we talked about earlier. We're gonna only have one zone here. I'm gonna accept that as the default and at this time, we're almost there. We have already almost gotten this node added into the cluster. The last part we wanna do is we wanna actually go and take a look and configure these drives and the networking of it. Because we're only using one network here, I would set these to just use the public IP address. So I'm just gonna pick my zero address and reassign the interfaces and then I'm gonna click on the manage drives. So here you will see the five different drives that are attached to this node, as well as the OS drive, which is gonna probably be at the bottom of here. What you then wanna do is make sure that you ignore that drive because we don't wanna reformat the drive that the OS sits on. So check the ignore button and click change. If you do this on a regular hardware node, it will actually detect the OS drive for you and ignore it automatically. Now, the next thing we wanna do is we wanna make sure that we format all those drives, similar to what we did for the original Swift node that we deployed earlier. Wanna click change. And so what this does is it basically goes through and it lays down the XFS file system on those drives and amounts them just like we did going through every single step earlier and then we can see that the label is now here, D zero to D four, as opposed to early we had D one through D five. Now, what we're gonna do here is we're gonna add these in to the account container and object tiers for the ring operations, which will basically map the drives in to the ring properly. So you can go ahead and click the plus now button and then hit change and that will take the weight of the drives that we discussed earlier. It will take all that the weight and add them immediately so that all the disks will be the full weight of the drive will be added into the cluster. If this had been a new node, we added to a big cluster, we may have chosen to add it gradually because what happens when you add a new node is the replication starts happening in the cluster and if you have adding a lot of capacity to let's say one petabyte cluster, you add another petabyte to the entire, so you now have two. What's gonna happen is that you have an almost full petabyte and then you have a new blank petabyte that you're adding in, that's gonna smooth out so that you end up having about roughly 50% of the one first petabyte moving over to the other one. That would require a lot of network traffic. So if you were to do that, you probably want to add gradually and what that will do is it will actually take and add a little bit of weight to each drive every hour until you get to the full capacity increase. In this case, because we only have one, add immediately is a safe thing to do. All right, you should notice here that this will change to end use and we're almost done. So if you click on the deploy here, we'll get to enable the node. So all the steps that we did in the first run through of the Swift node, this is actually being done intelligently by our software here, the controller. Now, you'll notice here that there's deploy changes. One thing that we haven't done yet is adding a user. We can't create a cluster until we have a user. So the first thing we want to do here before we continue is to create a user. I'm just gonna call my user demo and I'm gonna type password into password and suggest you do the same for simplicity's sake. Now what you can do when you're ready is to hit deploy changes here and that will actually, here's an API IP address. Be good if I had that one in there too. Actually, when you're in the configure cluster section here because I had already configured this cluster to begin with, this was not set up, but what you want to do here is you want to use the IP address that you logged into. So in my case, that would be 166.78.181.204. Your IP should be different. The cluster API host name is not necessary here. We don't have DNS set up, so there's no need for that. We don't have a valid SSL, so we don't need to use that either. So we can just scroll to the bottom and hit submit changes. All right, now we're good. So what you'll see on the pending configuration changes here is that the things that will happen when we push out the rings. So the rings have now been prepared. We haven't actually created them yet. So when we hit the deploy config to cluster here, what's gonna happen is the rings will be created just like we did on the command line earlier and it will add in the different disks that we just added on the node. And then this will be pushed out, the configuration settings will be pushed out to the node from the controller. So since we're a lot of people here at the same time, this will take a little while, but go ahead and click the deploy config to cluster. And you should see a screen similar to this. And this job will probably take a few minutes and while we do that, you can see here that the auth URL is displayed right there. And we also have a web console, which is just a web console you can upload, download images, documents, things that you have. And it will also display the Swift version that this cluster will be running. If we had multiple nodes, we'll just repeat these steps and we'll add them in one by one or we can add 10 at a time if we wanted to. So this will be obviously be a lot easier to do than actually deploying everything by hand the first, like we did the first time. And well, that was pretty fast for me. Everyone else finish already? No problems? Okay. We can go ahead here and open the console. It'll take a little bit, the first time you load it, it'll take a little while to load the JavaScript. And then you can log in with a username and password and we can create container if you want. Call it photos and you can drag and drop files in here. And again, you can use the, on the command line here, you can actually go ahead and use and do the same things as you did before with the other node where you can upload and download files directly from the command line as well. Anyone have any questions at this point? I have a photo here. Here's my cloud cat. You can take these images, drag them to here and they should be showing up there. Now if you want to actually take a look on the command line you can copy your auth URL, you can use the Swift client and you can take a look at what's actually in this cluster. Add one container, actually not listing my objects yet but I can also run a list. Show me the photos. I can list the photos that are in here. Does that work for everyone? All right, any more questions at this point? Say again, the formatting on your disks or is it pushing out the ring to the node? Probably ignored the wrong one. Yeah, you probably formatted the wrong one. You should have another one in here. That's the one you want to ignore. How do I know that this is from disk? It's this one. How do I know? It's because it says it here. It's different than all the other ones. So you want to go ahead and change that. It would be better if we label that. Yeah, yeah, something like that. You can format amount that one now. Now it should be good. All right, there you go. And then you can add these in here, like that. So these arrays are being added to the object ring, right? Yes, they were just added to the object ring now that we corrected that mistake. So now they're in use here. So formatted and it became an XFS fight system. Exactly. So the problem we had here was that he had actually ignored the wrong disk and it couldn't format it properly because of that. So now we got that sorted. It should be possible for you to push that out again. So in the audience there, how many people are sort of deploying open stack clusters and how many people are developers? Who's using open stack in general like for deploying internal systems? How many people of you are actually planning on using Swift? Fair bit. And how are you gonna be using Swift? Are you using it for an application or are you using it as part of an image store for Nova or anyone? Application, what kind of application? Okay. Any other? Object store for what kind of application just for cloud service providers? Okay, so similar to Rackspace, Amazon maybe? The pages of what? Ebooks? Okay. Okay, interesting. Any other use cases? Okay, so you're kind of doing an online reading experience. Interesting. You're using Swift for a lot of things. Okay, that's cool. So one cluster at McCarty Libre is actually running images and the other one's more of a general purpose cluster. Okay, so actually that brings up a good point here. If you take a look in your cluster here, you can actually go into the managed cluster and you can take a look at, for example, managed middleware. There's a bunch of different middleware here. You can set account quotas on the accounts so you can limit how much data is being uploaded to a particular account. You have bulk operations, which is kind of cool. You can take a huge zip file, for example. You can upload it and auto-unsip that as it gets into the cluster and then you can take an entire, let's say you had a website. You want to deploy like it's a static website. You could actually take the static website. You can auto-deploy that onto the cluster and you can use the static web one to display all the data that's in the container where you uploaded it to and then have a static website that's really, really fast at responding because it can do a lot of gets from thousands and thousands of people at the same time. Yeah, so if I understand your question correctly is could you create a statically mapped object that then would be embedded in your website that would then link directly to your Swift cluster? Really, really small images, yeah? I'm not sure that I have fully understand it but I think that what you're asking is if could you get the image to render automatically in a different web app? And I think that the answer there is that's more or less exactly what Mercado Libre is doing. Actually, our images are probably, are you saying probably container so anyone can see it but I don't know if you want to pass credentials to it you can use it, you can actually code inside your application, you can code a simple client that manage authentication and I don't know. So, yeah, so to that point what we have here in the middleware too for people who are using Keystone, for example, you can go ahead and enable Keystone authentication. You'd have to set this up with your Keystone server, obviously, but there's Keystone integration that comes in here that's easily configurable as well as LDAP-based. If you have an already existing auth system using LDAP, you can use that and that could be used in your application to authenticate against various different end points that you need to. Right, so your application would use the store for accessing the data that it needs, for example. Right, you got a question? No, you don't, so the question was if I work with SwissStack, do you have to have a public IP to talk to the controller? Right, so the controller can be hosted, we have a hosted product that we use, it's called platform.swithstack.com. This is basically exactly what you're seeing here, but this is just for workshops, but you can also have this on-premise so they can sit in your data center and you can have multiple clusters and you can manage multiple clusters with the same controller. Yes, so you can use our hosted controller or you can have it on-premise and what happens is the nodes, your Swift nodes, they will be talking to the controller, they will connect out to the controller. The controller never talks to the node or doesn't initiate that connection. The node initiates the connection to the controller and once it does that then it allows it to talk to the node and being able to deploy new nodes, manage the nodes, make changes to your cluster as you need to and deploy, for example, middleware, authentication and so on. Yes, so the question is, do I need to have a public IP to connect to this? If you have the controller installed in your data center, you don't, but if you use our hosted, no, you don't have to have a public IP on any of the nodes. Actually, we would suggest that you don't. Actually, strongly suggest that you don't because it's a security issue. What happens if you're using a hosted controller is that you initiate a VPN connection going out and so in one of the first steps that we did here when it said connecting to node, what actually happens is there's a VPN connection on the node that gets generated, it's a unique ID, it connects up to the controller and says, hey, I am node so-and-so, let me connect to you. Yeah, it's not a site-to-site, it's actually node-to-controller, so every node has its own unique VPN connection to the controller. Yeah, and underneath that's using open VPN and in case you're, question out there? So does it do any deduplication is the question? Okay, no, it does not do any deduplication. However, if you wanna use some kind of client-side deduplication, you can use that. Going forward, there are some really exciting new features that are rolling into Swift. The first one is gonna be storage policy, which basically gonna allow you to run multiple kinds of policies across, you could for example say I don't need three replicas for certain types of data, I only need two, or I need super fast storage, then you can actually deploy it onto SSDs, which then would almost act as kind of like a mini CDN, right? And then after that, there'll be erasure codes coming in, which will allow you to, actually the presentation that was here right before us, we're talking about the erasure codes schema that's being implemented. It's being written generally now by Swiftstack, Intel and Box, if you're familiar with those guys. So before your next question, you had another question. Are we offering a SaaS product? We are offering the controller as a SaaS product, but we are not, you have to operate your own hardware, or I mean you can have another entity do it for you, but you would buy your own hardware and that's the point of like most people that need a private cloud, it's hard to build a Swift cluster and maintain it and keep it up and monitor it and maintain all that stuff. So that's something that you would put in your data center or your data centers, where you can run multiple regions if you want to and you manage that, but we help you do that through our controller. So the question is what if something fails? Disks that fail, Swift works around that based on the handoff locations, like that we were talking about earlier, right? I was showing on the slides. So what happens is if a drive dies, you will see that in the interface here that a drive is not working properly. You will actually get an alert kind of like this. You can get alerts and if you have a problem with it, you will know here by looking at it. If what, if a demon's not working? Yeah, so what you can do is you can restart the demons on the Swift node and we have tools to allow you to do that. We do not manage your cluster. You manage your own cluster, but we give you all the tools to be able to do so. So back to you, you had a question. Yes, it can support byte ranges. Other questions, anyone here? This side is heavy weighted with the questions. This side is not. How does it compare to Gluster FS? Gluster FS is more of a sort of a file system, right? Which has sort of object storage kind of bolted on to it. It's a slightly different use case. You should always choose Swift, of course. I think that that's, depends on if you need a file system, your needs are probably different and there are certainly use cases where Gluster FS may be a good match for your application. I think in the particular use case that you brought up before, I don't really know a whole lot about it, but it sounds like that would be a pretty good use case for Swift. So. Media content and everything. Oh, look at that. Media files are there, then maybe I don't know, but I'm thinking Gluster FS may be because it gives native interface into the shell and everything. But if your documents, objects are very light in weight, but more documents, your application needs to scale. Well, so Swift scales really well, right? And we've had many, today specifically, we had many, many use cases that were brought up during the day and in the keynote the other day, one of our customers concur, they were showing how they were using Swift for their application. And what they do is they have also millions and billions growing of images of basically receipts that people scan. Yes, receipts. And like, expensive file and all that stuff. Yes, same idea, right? And so it really comes down to your use case. If you have lots of images, lots of small files, lots of high concurrency, that's a very good use case for Swift. And because Swift scales out, linearly out, you can add, I mean, so far, no one has really found a limit to how big it scales. Rackspace, Chuck over at Rackspace was just talking about they have 85 petabytes of raw cluster in there. So they obviously have a lot of... I'm part of Rackspace deployments. Yeah, but Mark Hadalibra talked today about their 1.5 billion images. We have customers that we can't talk about, but they have several, many, many petabytes of data. And they're running it globally across different data centers, but are accessing it as one big cluster which is, if you're running a web app, that is tremendously powerful because you can actually send requests based on the location of where the user is. So if you have three data centers, one in San Francisco, one in London and one in Hong Kong, you can, based on the user's location, you can send them to that data center and get the data back, which will then reduce the latency of the request. Two things which are coming to my mind. One is Swift Explorer. If something like that Finder and all that stuff is there on Mac or Windows Explorer. So if you can write a simple app that Swift Explorer, users will feel that it is a file system. Yeah, so actually I think I have maybe here somewhere or the shell script, something like, instead of LS, we can say SLS, Swift LS. Yeah, so there are a lot of different kind of integrations you can do. Obviously the first one that usually comes to mind is authentication. But there's always load balancing that is required for a big web application. Swift Stack actually has a load balancers as we deployed it now. There's a load balancer that's, lightweight load balancer that's included that you can use out of the box. If you run a very large data center and you need bigger kind of, have bigger load balancing needs, you can put that on top of it. There's CDN integration that you can use. There are CFSIFs and NFS gateways out there that you can deploy in front and get sort of legacy access that basically translates NFS directly into object. And then you do have file managers and file system adapters that can be used. Because every time you want to run a curl command, people don't really want to do that. If you want to see the entire layout of your file system, is a virtual field that they get, oh, I can see the data? Yes, but that's probably if you kind of need a file system. If you in object storage, you probably don't. Actually, one of my colleagues back here has a comment, I think. So I think there's two aspects to that question. The first one is that certainly there are plenty of utilities that make it easier for you to just list files that are in containers and to manipulate them with command line. The Swift command line client is one of them but there are others that have their own strengths and weaknesses and so having easy to use clients at the shell level is definitely something that already exists, it's a solved problem for Swift. But the other aspect of it is it depends on what exactly you're looking for. I mean, if you, you know, Swift is a highly scalable distributed object store and with that, you have to accept certain ideas and one of those ideas is that it's, you know, going to scale to billions of objects, you know, and millions of containers and accounts. And so there are things that you just can't get and that you don't want and things like, oh, I wanna list all of the accounts. Well, the whole way that you can scale to that level is it denies you the ability to do something like that because, you know, that's how Swift is able to provide you with those services. So at some level you have to accept some compromises which are, you know, that I can't treat it like a file system at some level because otherwise, you know, you would just use a file system that were possible. So that's kind of the trade off. Now that being said, sometimes there are things you can do to, like maybe you know that you aren't gonna have a billion accounts or 500 million accounts or whatever. In that case, you know, maybe there are some ways that you can get account listings. We do utilization information, for instance, for Swift and that is a place where we do, to some degree, aggregate account listings and you can get that through that information but that isn't something that is gonna be provided for you like through a Swift API. So yeah, you just kind of have to think about the compromises involved in a distributed object store. I mean it's a bunch of batch scripts only. Like if the container has more than a thousand entries or something like that, you know, there are more entries I'm stripping off only, I'm displaying only up to a thousand. If you want to see more than a thousand then you have to pass an extra parameter or something like that. Paging is something that certainly Swift does already and that's fine for like object listings but once again, when you're talking about things like accounts then that's a different story that won't be an API that you'll get out of Swift anytime just because that, well there's several technical reasons why you won't get that for account listings. Okay, great, cool. Yeah, so just to highlight what Ryan was talking about there too a little bit is that one thing that's very commonly asked for among our customers is billing and utilization data. Sometimes that's because you're an ISP or something and you charge your customer based, you want to be able to charge your customer based on their utilization, whether that is the amount of data they store or how much they upload, bandwidth and so on. But it's also commonly used for internal charge backs. So that is something that our controllers also providing you an API into doing so that you can query it for accounts and container data and use your internal billing system to charge your customer or charge it internally as well. But really at the end of the day, the number of applications and ideas that people have for using Swift are just endless and we see so many different kinds of use cases. We've highlighted a lot of images here today but there's like someone pointed out earlier there are people just dumping all their log data from massive systems into Swift to be able to mine that data and look at it and store it and for long periods of time. So really it's kind of just up to imagination what you want to do with Swift and how you use it. Anyone else have questions? We'll be around for the next few minutes here at least if you have any problems or anything. Yeah, oh yeah, books, good point. Have you guys gotten one of these already? If you want a book, if you don't have it, just come up here and grab it. This will walk you through, this is our CEO, Joe Arnold wrote this book. It will walk you through a lot of the concepts of Swift. It will talk about things in painful detail. You can go through it, you can build a Swift cluster from scratch. If you find that to be painful, you can always call us. This is the latest version as of now, yes. There will probably be another version. Global clusters was still on the idea stage when this book came out. Global clusters was officially released like late summer or something like that. Sorry? I don't know, but I do know that they have their own homegrown object storage system as well. But yeah, there are lots of companies that are using Swift, very large companies, probably companies that you use every day. One of our guys who's the project team lead for the open source Swift team, he usually says that his goal is for everyone to be using Swift every day whether they know it or not. So I think that's a pretty good goal to have. So if you wanna try the Swift stack, you can get in touch with us, you can send an email to contact at swiftstock.com and you also have Mario here somewhere in the room. I think we're outside the room and you can check in with him, he's our VP of marketing and we can arrange for you to have a trial on our controller and we'll be happy to answer any questions you have. So what is Swift's business model? We basically provide the controller service for as a product and we charge by the petabytes used or the storage used, the gigabytes used that you have. So if you, how do we know? If you're using our controller, you have, there's usage data there. If you wanna have an on-prem controller, we have basically an honor system but you're supposed to report to us how much you're using. We have a minimum tier. So you subscribe to a tier and then you pay for that tier that you're in. But usually people find that that is cheaper than hiring five to 10 guys who are really good at Swift. So thank you.