So, today we're going to finish up our discussion of sort of more general and generic file system design features. We're going to finish talking about caching, and in particular some cache design choices that affect the file system's consistency. And then, once we've created this problem of a relationship between caching and consistency, we'll look at one general purpose way to solve it, which is a technique called journaling. So we have regular office hours this week, everybody is back on duty. We will tell you when the midterms are available, I'm just waiting to hear from the print shop. So as soon as we get them back from the scanner, we will have them, and you guys can pick them up during office hours. I would also encourage you, so if you are upset about the grade you received on a particular question, here's what to do to maximize your chances of success. So the first thing is, come up with a coherent argument about why your answer was not graded correctly. That involves looking at the solution, looking at some of the greater feedback. Without that, you're really not going to make much progress. The second thing is, please come, so the online solutions were updated earlier today. So there are now overall statistics about the exam as well as per question statistics and some feedback provided for some of the questions by the TAs that graded those questions. So you should be able to use that to figure out which TA graded a particular question. So if you have a doubt about it or you feel like you have an argument that the question was not graded correctly, please come and meet with that TA. That should be possible. All the TAs do a number of office hours a week. So approach the right TA, make an argument. We will be flexible if there are mistakes that get made during grading. Of course those mistakes, I would argue, tend to cancel out when applied over the entire class and probably also when applied over your entire exam. But we will certainly address questions with grading on them. But please keep in mind that TAs are also working on helping you with assignment three and other things. Please most importantly, come up with an argument for you come in to ask for points. If you come in and say, I want more points on this question, you're not going to get very far. And yeah, so you guys are making some progress on assignment three up to a 40, making at least headed in the right direction. This is four or five points more than maybe 10 points more than last week. Just let me talk about what we're going to do sort of for the rest of the semester. So from this point forward, what I did last year is I sort of got to the end of my slides and then we talked about some research papers that were related to the topics in the course. What I'm going to try this year is interleaving those papers earlier at points that are sort of topically appropriate. So on Friday, we're going to do our on Wednesday this week, we're going to talk about two different file system designs that are quite different in terms of while their different file system designs are clearly different, but they're quite distinct from each other. They make very different design choices. And so they'll be fun to talk about together. And then on Friday, we're going to talk about RAID. How many people have heard of RAID? All right. So yeah, the RAID is the thing. RAID is the thing that you guys might have used or configured or you guys probably without knowing it use machines that themselves use RAID without you knowing it. So we'll talk about RAID. The RAID paper is posted on the website and you guys might also want to look at other sort of online resources about there.  There's all sorts of information online about it, but please do try to look at the papers. We've heard of the paper in class and since this is our first time, we'll talk a little bit about how to approach something like this. The RAID paper is actually great for this because it's 26 pages long, although it's not that long. It's formatted in a strange way, so it goes fast. But it's also in a way sort of fairly didactic and can be difficult to penetrate if you're new to this. So we'll talk about ways to approach research papers on Friday, but please take a stab at reading the RAID paper before you come to class. And then going forward, we have a mix of topics to finish the class. We're going to talk about virtualization. We'll talk a little bit about OS design. And what I'll be doing is as we go, I'll be dropping in papers maybe one a week for us to look at. So you guys get a chance to see some modern, really modern sort of cutting edge sort of operating system designs and features. This stuff, of course, this RAID paper is from I think the 60s or 70s, so it's not modern and cutting edge, but it's a good paper to practice on, learn how to read these. Any questions about the rest of this semester? But this will be fun. You guys will be surprised that at this point, I think with the knowledge that you picked up in this class and with your previous experiences, you can actually sit down and get the gist of what these papers are about. Take a little bit of practice, but you can, and it's kind of fun because there's still some really very interesting ideas out there in the research community about how to build better systems. OK. So let's talk a little bit about how we organized data blocks. So our final data structure was based on what observation about files. We talked about a couple of different ways to structure our data block index. Multi-level indexes were based on the fact what sort of distribution of file sizes. Most files are small, small configuration files, little Plex files that are used by various programs. Lock files sometimes are zero size. Their existence is what they're there for. But some files can get really big. And so that drove this idea where on the multi-level index, so the inode stores some pointers to blocks, which we call direct blocks. And that stores the first n blocks of the file. This is how I find the first n blocks of the file. What about the next blocks in the file? How do I access the next blocks in the file? So for small files, all the data blocks might be linked from the inode itself. Actually, on Wednesday we'll talk about FFS, which had a sneaky trick of actually for really small files just jamming the contents right into the inode itself. So there were no data blocks at all. But for ASD4, there's always at least one data block. That data block might be linked directly from the inode. But once the file gets big enough, what do I start to do? I can. I can only link so many direct blocks off of the inode itself. So that would prevent the file from getting big. So I start allocating blocks that are not used for data. Instead, they contain pointers to other data blocks. So I introduced one level of indirection. So now my inode has some pointers that point directly to blocks, and some pointers that point to blocks that are used internally that themselves contain pointers to blocks. So this allows the file to grow up to another, maybe to a certain size. And then what do I do after that? This would still limit the maximum size of the file to something, and potentially I want it to be bigger. So what's the natural extension of this idea? Nobody wants to try to say it?  And the next thing I do is allocate doubly or triply or quadruply indirect blocks that just add additional levels of indirection. So now I have a pointer to a block which contains pointers to blocks which contain pointers to data blocks. OK. So we talked about caching. And this is a nice segue into what we'll do today. Operating systems use memory both for pages, to support address spaces, but also as a cache for the file system. And these two uses of memory are constantly at war with each other. They're constantly conflicting. And the operating system is making a decision at runtime about how much memory to allocate to the buffer cache and how much to allocate to process pages. What happens in the case? What can happen if I overallocate memory to the buffer cache? This can, in certain cases, this can cause great performance. What is an example of when this would produce really good performance? Yeah. OK. So that's when it's bad. So that's when things go wrong. If this creates too much memory pressure, then the system can start to thrash. Remember, because essentially what I've done is I lowered the amount of available memory on the system artificially by overallocated memory to the buffer cache. But when does this work well? Give me an example of a situation, and this would be the right decision. A hypothetical scenario. Yeah. So imagine I have a web server that's serving static pages, doesn't have a lot, and maybe the website's large. And so those pages, they're really stored all over the disk. And essentially what that web server is doing, it doesn't have a lot of internal storage. It's really moving data from the file system out over the network. And over time, if that's the only thing running on the machine, that might cause the buffer cache to get quite big. There's not a lot of internal data used by a web server, and it requires a lot of file access. Another application that's like this? Very common to have running on machines. You guys probably used them in the past. Yeah. Backup? OK. So that's a great point. If I'm backing things up, I'm doing a lot of file access, and I'm moving those files into doing a diff against a previous backup or something. What's another standalone application that would potentially create an enormous amount of file access? It's a database. A database has sometimes played tricks where they actually use memmap to map files into their virtual address space. But if they didn't do that, they would be using potentially an enormous amount of disk activity over a large enough area that a large buffer cache would be appropriate. And so this is sort of the other scenario. If I have a lot of paging use, if I have a lot of address space use, but little file system activity, or if the file system activities can find only a few files, then it makes more sense to not allocate as much space to the buffer cache as I would. What places sort of a runtime limit on the size of the buffer cache? Can the buffer cache grow without bound for any particular workload? So if I had a particular program and I start allocating space to the buffer cache, at some point its performance is not going to improve anymore. Why is that? What's the maximum useful size of the buffer cache? What's that? No. Well, at that point, I'm in deep trouble because I don't have any memory for anything else, certainly. But there's a smaller, you can do a tighter bound, the maximum useful size of the file system buffer cache. Yeah. Well, remember, the file system buffer cache is storing data blocks that are potentially in use. So if the total number of files, the total size of all the files that are open or have been accessed recently places a reasonable bound on the size of the buffer cache. If all of my I.O. is going to one small file, adding buffer cache doesn't help because there's nothing else to cache. Everything's already in the cache. Everything that can't hit in the cache is hitting in the cache. I have a 100% cache hit rate. And once I get to 100%, adding more memory to the cache doesn't help. So we talked about where the buffer cache is located on the system. So we discussed putting it above the file system, where would cache whole files, and below the file system. And where did we decide was the right design choice here? This must have had a fantastic weekend. Wish my weekend would have been that. Anything that happened on Friday, it's like, years ago, where should I put the buffer cache? Below, 50% chance of being right. There we go. Below, why? And so we'll come back to why. But what does the buffer cache store if I put it below the file system? This is a short-term memory question because I think I just said it just two minutes ago. It's below the file system. What is stored in the buffer cache? What do file system operations eventually manipulate? Disk blocks. Blocks on disk. And the nice thing about having it below the file system, or one of the nice things, is that I can store data structures, I can cache data structures that aren't part of the file. Inodes, superblocks, other on disk data structures that I would never see if the cache was above the file system. And as you might imagine, these type of file system data structures can be very, very hot in that they're accessed frequently. So remember to translate a path name. Where do I start? What's the first step of translating a path name? I started the root iNode. So what do I have to read? I have to read the root iNode in order to translate every path on the system. So where do you think the root iNode is pretty much from the moment I start the system? In the cache. Root iNode also changes very infrequently. You very rarely add or remove directories from the root of your system. And so the root iNode is just a great, the cache is dream. It doesn't change very often, and it's used constantly. And potentially, I would argue that probably a lot of the top level directories end up in the cache, because they're used so often during path name translation. Once I get down into the leaves of the tree, I don't have necessarily a high enough use rate to justify pinning them in the cache, but the top level stuff is going to be in the cache most. All right, so any questions about caching, path translation? OK. So now we've talked about how to translate names to iNodes. We've talked about how to link data blocks off of iNodes. We've talked about how to improve performance. And so now we're at the point where we're going to discuss some consistency issues. Because at the end of the day, the file system isn't really that useful if it doesn't reliably store data. You might have a file system that was extremely fast, and also it's really cool features. But if your files kept getting lost, if changes that, you know, if you were working on assignment three late one night, and you finally got it to work, you know, and it passed all the tests, and then you went to bed and you woke up and it wasn't the same anymore, and you were getting to 40 out of 100, you would be sad. And you would not use that file system anymore. And this has happened recently. There was a, I should be careful about impugning anybody on video, but there was a very popular file system called RiserFS that used some fancy data structures. But throughout its history, it was played with some consistency issues. And it made certain people, like the incredibly conservative people that maintain some of the big computer systems that you guys use, very reluctant to use it for production systems. Because that is one of the system, you know, when system administrators wake up in the middle of the night in a cold sweat, that's one of the things that, you know, it may be back in the 90s, this is more of a problem, but that's one of the things that they wake up terrified. They're going to come in one day and somehow the whole file server will have died permanently. And that data will be gone. That would be catastrophic for really any institution. Even our department would probably take a long time to survive the complete and utter destruction of the main file server that serves Timberlake and other things. If that went away, we'd have problems, a lot of problems. So consistency is an issue. Now, on the other hand, we just talked about these tricks that I'm going to use to make the file system faster. And what I want to point out here is that there's attention between these two goals. So how does caching exacerbate consistency problems? Short ID of the cache, I'm using memory to store file system contents. What can go wrong? Yeah. Yeah, the cache is in volatile memory. The disk is permanent. The disk will be there if the power goes out or if you unplug it or something bad happens. The memory is not. The system suddenly reboots or there's a power outage. The memory loses state pretty much immediately. And so now that I've introduced a volatile component to my file system, I need to think really carefully about how to make sure that the file system can stay consistent. And in certain cases that we're going to talk about here, it's possible that there will be some data loss. That's sometimes an OK price to pay for the overall file system metadata and structures being accurate. It would be better to, for example, lose a little bit of data than to lose the super block and a lot of my inodes and have no idea where anything was on disk anymore. At that point, you have to take it to some forensic disk specialist who charges you lots and lots of money and spends months trying to piece things together. That's what you would do if you were desperate. Most of us would probably just throw it out and start over. And remember the other challenge here, going back to when we talked about file system challenges originally, operations, the file system, and now that we've talked a little bit about the internals, you guys can see why this is the case, always require modifying or accessing multiple parts of the file system and changing multiple data blocks on disk. So here's an example of creating. So what do I need to do to create a new file in an existing directory? This is pretty similar to an example we did a week ago. What are the things I need to do? In any order, I want to create a file in an existing directory. What's one of the things I need to do? Find space for what? There's a couple of things I need. In order to have a file, I need what? Yeah, I need an inode. Remember for every file, there is an inode. So I'm going to need an inode. Assuming this file is not empty, what else am I going to need? Data blocks. Assuming I want to be able to find this file, what else am I going to need to do? I'm going to need to modify the data blocks in the directory. So I'm going to actually have to find the directory and modify it as well. So I've got to allocate an inode. When I do that, I'm going to mark that the inode's in use, otherwise somebody else might be using it at the same time. I need to allocate the data blocks. Same thing. I need to mark that those data blocks are in use so that I can reserve them for this file. I need to modify the inode and create any data structures I might need to associate the data blocks with the inode that could include direct blocks or doubly indirect blocks or whatever I need to do. And then I need to modify the directory file to associate this inode with a particular relative path name. And then I actually need to write the data blocks out. So I have these data blocks allocated, but I need to actually alter their contents so they reflect the information that the person is trying to write to the file. So the problem here, of course, is that if I get stuck in the middle of this process, or if I'm powered down or if the system fails when only a mixture of these things are done, if I'm not careful, I can create consistency problems in the file system itself. So the question is, why? So this could always happen. Even if I had no cache, even if every time you accessed a file, I had to do all these things, it could still happen that I could leave the file system in an inconsistent state. But why does caching make it worse? Even without a cache, even if I don't use memo, why does caching make this problem worse? Spring or what? You guys are quiet. So the problem caching creates is, depending on when I bring, so for reading, not a problem, right? Reading and caching typically are very friendly, because an item that's read and is in the cache has not changed from whatever the cache is caching. Writing is the problem. So when I write an object, ideally in order to take advantage of the cache, I'd like the right to not have to go to disk every time. And so what can happen is it's possible that there will be an object in the cache, like an inode, or data blocks for a directory, that has been updated by an operation, but has not yet made its way to disk. So the cache and disk have inconsistent contents. And now if I unplug the machine, those changes are not on disk, and so they're gone. And what caching does is, again, this can always happen, because I always have to do a bunch of these operations at the same time, quote unquote, in order to update the file system safely. But now when writes start to lodge in the cache, I have these longer windows of time when there's an inconsistency between what's on disk and what's in the cache. And now I have this bigger target for my power outage. Before, all I had to be was really lucky. I had to be really lucky to catch the file system right in the middle of doing a couple of disk operations. Now I've got these long windows of time during which I can unplug the machine and I can cause some sort of problem. So let's go back to the example and let's think about what kinds of inconsistency can result if the system was interrupted during this operation, or if one of these things didn't get done. So what happens if I allocate the inode, but I don't complete the rest of these operations? Let's say I get through one and then the machine crashes. So what inconsistency would there be if all I finished was allocating the inode? Yeah, so I have an inode that's incorrectly marked as in use. Now, is there a way to detect this? People are shaking their heads. So it turns out there is, right? How can I enumerate every inode that's in use on the system, on a particular file system? What do I have to do to do that? It's a good exam question. I give you a file system. I want you to enumerate every inode that is in use. And then I'm going to compare that with my on-disk data structures. So what do you have to do to enumerate every inode on the system? Yeah, I have to walk through the entire directory tree and record every inode for a directory or a file. But that'll work. So how many, I don't know. So file systems got so much better, it's possible that none of you guys have had to experience it before.  Yeah, so back when I was a youth, back in those days when people hadn't improved these things, there was a possibility that, so it's bad enough when your machine suddenly fails.  You want to turn it on and have it come right back up. No, that's not what would happen on those old systems. They would say, oh, it's time to run a file system consistency check. Why don't you go on vacation for a couple of days and come back later? Because the disk is really slow. And imagine I have to now walk through every directory. I might have to look at every data block on the disk and check these sorts of things. So it's usually possible to fix these things. But we also want to be able to fix them fast. And when we come back to talk later in the lecture about journaling, we'll see why that helps. So same thing with data blocks, similar problem. If I don't mark them in use and they don't associate them with a file, then I might leak them. So in both of these cases, what would happen if I didn't fix the problem is that there would just be a dangling inode, something in the system, one fewer inode than I thought I should have. Same thing with data blocks. And just like with inodes with data blocks, if I want to, I can enumerate every data block that is actually in use on the system. And that's even worse than the inode check. It takes even longer. I have to touch even more things on the system. So what happens? So same thing with, oh, OK. I like this one. Yeah, so sorry. This should actually go for number four, right? So if I don't get the inode associated with the directory, what I have now is a dangling file. I might have a complete file with an inode in data blocks, but it's not a part of any directory. And it's marked as being present. So if I delete a file, it's possible that I could just remove it from the directory and be done. I have a file that can clean up later. But it's also possible I have a file with contents in it that I want that's not linked in any directory. Does anybody know how some modern systems handle this problem? Many of you guys, you may have seen this directory on your own OS 161 virtual box. It's a special directory with a very appropriate name where the file system puts these. It's called Lost and Found. So you might wonder, what is the Lost and Found directory for? Lost and Found Directory is for cases where the file system has discovered a file that's not linked in any directory. And so where to put it? No idea. And so in those cases, it throws it into that directory. And it's now your problem to figure out where that file actually belongs. So just in case you were wondering what that directory was for, now you know. And of course, if I don't actually write the data blocks out before the file system crashes, I can have data loss. And that's bad too. OK. So now let's think about the policy in the cache. So remember, reads are always safe. So the policy with how I cache data really only applies to writes. So if I want to keep things as consistent as possible. And again, this is not sufficient to prevent every kind of failure. But if I want to minimize the chance of failure, what policy should I apply in the cache when data blocks are modified? What should I do? I'm not going to repeat it. What am I going to do with that data block? Yeah, so if I don't buffer writes, if I always push the writes immediately to disk, now I should fix this. It's not that I don't buffer the writes. I can still change the block in the cache. Why would I, if I'm going to write it to disk anyway, why would I also modify the block in the cache? It all seems like extra work. Can you read it that way? Yeah, so it's up to date in the cache when I do a read. So that's why I modify the cache even during writes, even if I'm going to write it right to disk immediately. So the term that we use for a cache that has this property where things are immediately pushed to disk is a write through cache.  They update the cache contents, and then they are immediately queued to the disk. So this ensures that modifications to the file system reach the actual disk as soon as possible. Now, let's say you want your file system to fail. What policy in the cache should you apply in that case? He already knows the name. So this is what's called a write-back cache. And in this case, what we do is you essentially buffer the writes in the cache without updating the file on disk as long as possible. And so until one of several things happens, it's possible that the block is evicted from the cache. It's removed to make space for something else. At that point, you have to write it to disk. It's possible that the file system is unmounted, or the machine powers off safely. In that case, you also have to write things to disk. But the write-back approach essentially produces, remember we talked about before, there's a period of time when I do any caching for writes where the contents and memory differ from the contents on disk. And for a write-through cache, that period of time is as short as possible. For a write-back cache, it's as long as possible. And so this creates the largest chance for some sort of failure. OK. And this is probably pretty obvious. So for performance, the write-back cache is great. It minimizes the number of actual modifications to the file system, to the disk I have to do. So imagine I have 50 different writes. For a write-through cache, all those 50 writes generate disk activity. For a write-back cache, there's only one update to the file that occurs, maybe even at some point later. So the write-back cache allows me to amortize as much activity in the cache as possible for writes. Whereas the write-through cache does not amortize any writes in the cache. OK. So of course we can do something that's a little bit of a mixture of these approaches. And there's a variety of different ways to find a middle ground. One is to immediately write out important file system data structures, things like inodes, directories, the superblock that's got all that really high level information, those things I might not want to buffer in the cache at all, those to pass immediately through. Data, on the other hand, I might be willing to keep in the cache for a little while. Because it turns out when we started talking about file systems, we thought, well, the most important thing for file systems is to reliably store data. It turns out that's not exactly true. The most important thing for file systems is to keep their own internal data structures up to date.  So if you reboot and you get an old version of the file that doesn't have a couple of changes you made, that's probably OK.  So imagine I move a subtree from one directory to another. It's possible that that whole subtree is now unlinked from the file system, and there's a failure. That would be bad. So you could potentially have a lot of files that suddenly go missing. And there's also, to some degree, an API that's provided by the operating system that allows processes to request that the file system be synced, which flushes all dirty buffers out to disk, or to request that a particular file itself be flushed to disk. OK. Any questions up till this point about consistency and right caching piles? OK, so let's finish up today by talking about a different approach to this problem that's used in systems that are available today in most modern file systems. So part of the problem here is that there's something that's not atomic. So remember when we talked about a right, there were all these different operations to perform. And fundamentally, from the perspective of the file system, what's the underlying primitive here that's not atomic? Yeah. Well, modifying disk blocks. So if I have to think about old spinning disks, with that right, I have to change a bunch of different disk blocks. Those disk blocks are located all over the place. So even if I push them down to the disk all at the same time, it's possible that some of them get done and some of them don't. And so that's not what I want. On the other hand, what is more atomic from the perspective of the file system? If writing multiple disk blocks is going to require multiple operations, what's the primitive that I can use to get some degree of atomicity out of the disk? Yeah, writing one, a single disk block. So somehow, if I could take these complicated operations that are traditional file systems required modifying a bunch of different things, and I could compress them into a single operation, somehow, and use that information, it's possible that I can do a better job of providing consistency guarantees, even in the face of cash. So this leads to approach which is generally known as journaling. Journaling takes a lot of different forms, but I'm going to give you sort of a high-level overview of how this works. So what journaling file systems do is they have another on-disk data structure that's called the journal. The journal records pending changes to the file system. So anytime I need to perform a number of actions atomically, or if you're taking database systems or distributed systems in a transaction, I first write those operations to the journal. Following a failure, I can use the journal to quickly figure out what parts of those operations were complete and what parts have not yet been done. And I can use the journal to roll the system forward quickly to a known good state. So keep in mind our little discussion from before. There are usually ways for a file system to determine by exhaustive search over the entire disk that its data structures are consistent. But that's not what I want to do. Because following a crash, I want to be able to come up quickly and keep rolling. I don't want to have the system down for hours while this really slow checking process takes place. And so you can think of journaling as an optimization that allows the file system to recover more quickly. OK, so here's an example. I'm in the process of creating a file. And here's my journal entry for this particular operation. What the journal entry does is it tells the system the different things that need to be done for this operation that take place. So in this case, I need to allocate an inode. I need to grab some data blocks. And I need to add the inode to a particular directory. And I would probably need to write down what the relative path name is. So that's it. Once this is in the, now, writing it to the journal, so the journal is a separate data structure, does not mean that I've completed all of these operations. It's possible that some of them are still being cached in various places. And so now let's talk about what we do when we, so OK, sorry, I was confused by the title of the slide. So as I bring the disk, so eventually what will happen is all of these operations will actually be propagated to the disk. So the file system is keeping track of what parts of the journal entry have been completed. Once the entire journal entry is on disk, then I move on. And what I do is I create a check point. So the check point is the point in the journal up to which everything is consistent. Past the check point, I don't know. So the check point, all the entries sort of above the check point can really sort of be deleted. They're finished. They're on disk. Anything below the check point, I don't know. I'm not sure. Some of it might be done, some of it might not be done. So once all this is done, then what I can do is I can put a check point below this entry. Now, in real systems, of course, there's a bunch of different entries in the journal, and I'm completing different parts of them at different times. But the thing to keep in mind is I can only put a check point below an entry if all of the steps have been completed for all the entries above the check point. Does this make sense? What the check point indicates is where I need to start looking when I'm trying to figure out whether or not the system is in a consistent state. So what I do during recovery, I start at the last check point and I go through all the completed journal entries, and I use them to figure out which on-disk data structure I need to check and what I need to do to them potentially to bring them up to date. So let's say that this was the entry below my last check point. So here's my check point, and then I was, now what this indicates is that I had allocated, I wanted to allocate a new file. It tells me some information about where the file should be, what it should be called, it would have to say what directory it was in, again, there's relative path missing, what data block should be a part of it. Now, remember, at this point, the system isn't sure what parts of this have been completed and what haven't, so what do I do? I know from here, back through the roof, those are done, but I don't know about this entry. So what do I need to do to process this journal entry and bring the system back up to date? The first thing I need to do, I just don't know, I can do them in multiple orders. Yeah, I use them. That's it. I don't necessarily have to redo them, I just have to make sure that they're done. So for example, I need to go to my inode allocation structure and make sure that inode 5.67 is allocated, because it should have been allocated. And then I need to go to the data block data structure and make sure that those data blocks are marked as in use and that they're associated with that file, that the files own data structures point to those data blocks. Then I need to go and I need to read inode 33 and make sure that inode 33 maps a relative path name to inode 5.67, which is this new file that I was creating. And it's possible, like I said, that some of these operations had completed, some of them have been flushed to disk, and others had not. So OK, in this case, I had already done the first step. Oops, hadn't actually updated the inodes data structure to the data block, so it's good I wrote that down. Now I can do that. Didn't do this either. The directory with 33 didn't have this entry in it. And now at this point I'm all caught up. And so the benefit of journaling from the perspective of recovery is it's way, you know, think about there's some entries in the journal, there's hundreds of entries in the journal. It's still way faster than looking through the entire file system and doing these huge, holistic consistency checks. Essentially the journal allows me to focus on the parts of the file system that might have problems. It identifies exactly what parts of the file system could be inconsistent, and so I can focus my efforts there. And when you recover a journal file system, frequently you don't even notice. A lot of times journal file systems, every time they boot up, they check the journal and replay. It's not even a special operation. And if there was some sort of crash, the recovery happens extremely quickly. OK. So what about, well, I'll just finish this since we're low on time. So if, for whatever reason, now the nice thing about the journal entries is they fit inside a data block. And so I can write the journal entries atomically. If for some reason maybe I have a journal entry that span two data blocks and I have an incomplete journal entry, I have to ignore those. Because I don't have enough information to know what the whole operation was. So the nice thing about the journal is that for small operations like updates to metadata, I can represent these in a way so that I can write them inside a single data block. And normally I can get a whole journal entry into maybe one or two data blocks that I can write out really quickly. And now I have a nice pseudo-atomic record of what I was trying to do. And I can use that as part of the recovery process. On the other hand, the data blocks are interesting. So the data blocks by definition are going to be potentially too big to write out all atomically. And so there's two solutions to this. One is that we actually do write them into the journal. And that allows us potentially to update things. But this would require writing every data block twice, which is not fun. The other alternative is we just don't ever write data blocks to the journal. And what this means, again, is that after recovery, it's possible that your file system data structures are up to date, but the contents of the files may not have been perfectly preserved. So sorry. OK, so I'm going to skip the little aside. Well, I have time for it. OK, never mind. So the final thing I'll just point out here that makes this even more interesting is, of course, the fact that the hard disk itself has a cache, as if you thought that we didn't have enough caches. So not only am I caching file system contents in memory, but the hard drive itself is caching blocks. And this can be a problem for any of these consistency approaches. So you buy a hard disk, it advertises it at a certain size cache, and you're like, oh, that's awesome. But how can that create another problem for consistency from the operating system's point of view? Let's say the disk is super clever and has a big fat chunk of memory there, and it's using that memory to, essentially what it can do, it allows it to accept data from the OS and say, oh, I'm finished with that right. But I actually haven't finished the right. It's just in the cache. I'm still working on getting the heads over to where they need to go, but the right's complete. So what's the problem here? Well, it's not even atomicity. It's just that the operating system now doesn't really know when stuff is actually on disk. Just giving it to the disk isn't good enough, because the disk may have it in the cache, the power may go out. And the operating system may say, I'm pretty sure I wrote that block, and the disk is like, I don't know anything about that block. There are these really clever ways to solve this problem. This is my favorite one. So you might wonder, why is the 1 terabyte hard drive that I buy from my laptop computer cost $100, and the one that I buy from my server costs $5,000? And the answer is, I really don't know if there's a good reason for that. But the server drive has a few more features. And one of the features it might have is a battery backup system allowing it to make sure that even if you remove power from it, it will still finish, it'll still make sure that its cache is on disk. So it has enough battery backup to if the power goes out and there's some writes that are still being cached internally, make sure those get to disk before it shuts down. There were also, I think, some drives that actually hardest the rotational energy of the disk platters themselves. So I've taken all this effort to spin the drive up. And you imagine that as that drive spins down, there's a fair amount of rotational energy there. I can use that to finish those last couple of operations, even if I don't have them. OK, so next time we will talk about the Berkeley FAST file system, which is a very old design, but a really canonical and important one that gave birth to a lot of features that you guys are familiar with. And then, for fun, we'll talk about a totally different radical file system design that's called Log Structured File System. So I'll see you guys on Wednesday.


The only thing that comes against you is defeated.  Hallelujah. And if your ways please me, I'll give you your heart and desire. Hallelujah. I like victory. I've never liked to be on a defeated team. I thank God we're on the winning team.  Hallelujah. You do so much. Gotta give God some praise. Been wounded, been hurt, been tried, but I still got a praise. I still think of the goodness of God. And all you've done for me, my soul, cries that we thank God for y'all let me come to get on your nerves today. But we thank God for me being on your nerves. I love y'all and I love Bishop. Thank y'all for giving me an opportunity to come and preach. I don't preach hard like I used to because I'm in my 60 now. My step is getting old. Sometime it's better not to, ain't no use to me, preach it up for storming. All at once, Deacon Sack have a heart attack on the poor person. He preached hard, but he gone. So good words on good ground. Thank God. I am just astonished to see a man of God look that good at 80. Come on, somebody. I see why Sister Alexandria got here when he was, I got a picture when he was him and her and Pastor Marty and Henry, a little picture. They were looking so cute. Since the battle of found in love with him when he was young, he was a war horse. He's still a good horse, though. He's a nice looking handsome young man. And now I'm going to go back and tell Pastor Marty, you need glasses. That is the best look in Alexandria. I'm going to tell him when I get home, I'll say, he always shaking his head, you're right. But they love each other. Back in the hand of your honorable, beautiful pastor. Thank you, Bishop, for letting me grace your present in your church this morning. God bless you. God bless you. Now, I didn't pay him to say all that, but you know, I'll tip him a little bit. I'll give him a little tip. But now, what I want to do at this particular time is we need to take a speaker's offer. Amen. And evangelist, as I said, doesn't pastor a church. And he doesn't have people paying tithes and giving offerings to support his ministry. And so we want to be kind to the evangelist. I talk about old things because I'm old. My wife looks at me and see what Elder Carter sees. She said, you're not old? No, she's really saying, you're old. You talk about old things. Well, I'm an old person. I talk about old things. And I drive old cars and trucks and whatever. My pastor that came to our church to be our new pastor when I was six years old had been an evangelist, nationally evangelist. He went around preaching in the South. And he preached for a whole week. And he got $6. Now, I was back in the olden days, but $6 didn't go very far at all, even in that day, especially in that day. And the Lord has put it in my heart not to ever short the evangelists. And somebody might say, well, there are other churches with bigger congregations than ours. That's not legitimate. We're charged to do what we're charged to do. And I don't want to be asking, when did I find you hungry and didn't feed you? Hello, y'all got that? When did I find you without clothing and I didn't clothe you? So we're charged with being kind to the evangelists. Let's say amen together. Amen. Amen. So do the best that you can. That's right. Don't put your card away. Sister Sykes, Dr. Sykes, she's putting her credit card. She's putting it back in our wallet. But I ask you to do your very best in giving this offering for the evangelists. The Lord will be pleased with it. The Lord will bless you. Give, and it shall be given unto you. The Lord loves a cheerful giver. Said the Lord loves a cheerful giver. But, well, I can't say that. I would say he probably loves it even if you don't give it cheerfully, but I don't believe that. So give it with the right spirit. And I'm saying to you what the promises of God are that it'll come back to you not many days hence. Cast your bread upon the water. All y'all got bread. Cast your bread upon the water. And it should return not many days hence. It won't be long before your bread comes riding back on the water. We're not going to rush right now. I'm, like, minister Sorton. He wants you to put them zeroes in the right place and put a whole bunch of them. Didn't the man preach? Come on, somebody. You know he preached. He preached. And I can speak back in history. Elder Carter used to preach off of a ladder. He had a tall, tall ladder. And he preached his way up to the top of the ladder. But he said, I once was young. Amen. Amen. Is this for your battery?  Oh, all right, thank you. All right. Let us stand. All right, if you'll hold your offering up to the Lord as your sacrifice. Dear Jesus, our Savior, we thank you for who you are. Thank you for your strength, for your power, and for your might. Thank you for your love and your concern for us, your people. We thank you, O God, for that that you've provided for us, O God, even in this service, Lord. Thank you for the word that we've heard, O God. We ask you to help us, O God, to be determined to fulfill every obligation we have towards you. And we thank you, O God, for the opportunity to give into the building of the kingdom of the evangelists. I ask you, O God, to bless it, O God, that it may fulfill a great need in his life, O God. And we thank you for him. Thank you for the word that you've given us today. And we give you praise and glory and honor in Jesus' name. Amen. You may come with your offering. Praise the Lord, saints. We have an announcement. Elder Ross is not here today, but I just wanted to remind everyone as Elder Carter was speaking about the bishop's birthday coming up. Remember that on the 21st, that's not next Sunday, but the following Sunday, we'll be celebrating the bishop. And Elder Ross asked that we all bring $80 for the bishop to celebrate his birthday. Amen. So I just want to remind everyone, please make sure that you prepare to give unto the bishop to honor him for his 80th birthday. Amen. At this time, Minister Marilyn Alexander. In Jesus' name.


Good afternoon everybody. Oh, sorry. I've interrupted obviously, so please no carry on Thank you for coming. This is our fourth and final session of the day we've Covered multi-cloud networking. We've covered our CVM product and now we're gonna get into building n of the applications With open stack and Cisco ACI. We've got Domenico de Stolli and Ifty Rathore down here two of our engineers and away we go we are we are gonna build time in for Q&A at the end and For those of you who are always very very busy trying to take pictures of the screen Video of the session will be up on the open stack foundation YouTube channel later tonight, so Save the space on your camera for pretty pictures of Berlin and away we go. Thank you very much Thank you, Gary and Welcome everybody to this session. So as Gary said is about open stack and ACI So how we are gonna build your NFV solution based on open stack and ACI. My name is Domenico de Stolli I'm a technical marketing engineer from NCME business unit, which in Cisco is the business unit responsible for ACI So I'm going to present the first part of this session today And then my colleague Ifty will also take care of the of the rest of the presentation So thanks a lot for being here by the way. I heard that someone is playing against us. There are beers Maybe I shouldn't tell you but I I really Appreciate the fact that you are here instead of drinking beers in the other section So let's get it started the agenda today is indeed going to be split on different Things so obviously since we're talking about Cisco ACI and open stack I guess if you're here, you know about what open stack is you may not know what ACI is So we're gonna have a brief introduction about Cisco ACI what it is We're gonna Understand why eventually you may want to run the Cisco ACI solution together with open stack So what are the benefits there and then we're gonna go more towards the NFV kind of challenges That typically our customers have or share with us And how eventually with the Cisco ACI you can solve better those kind of challenges So Cisco ACI and open stack better together if you will So let's get it started What is a Cisco ACI Cisco ACI is indeed a Cisco software defined networking solution This is basically based on three main components, right? So we've got the Underlay or the switching layer if you like which is based on nexus 9000 switching family so those guys here and this is based on a Bipartit graph as we call it or be or rather it in a topology of a leaf and spine Kind of switches. So the second part of ACI is actually made of the AP controller Or rather the AP controller cluster, which is the brain of the solution So we see we'll see later that the Cisco AP controller is basically the single point of management of configuration of troubleshooting and visibility for the entire infrastructure of ACI So the third component is obviously the software that runs on the nexus 9000 and the ACI AP controller, which is indeed called ACI application-centric infrastructure Now the reason why we call it application-centric infrastructure is because ACI is indeed introducing a sort of network network policy framework, which is indeed shared amongst different kind of compute Architectures so you can basically build your application framework, which can be then Allowing connectivity from both burn metal server as well as virtual machine different kind of virtual machine managers And eventually also containers. So all this kind of architecture Or computes can be eventually be part of the same kind of network security policy framework Which is offered by the ACI solution So the beauty of this is that you can eventually move from one kind of architecture to another or having multiple cable architecture Communicating with each other so being switched routed and eventually being also having some service insertion to have communication allowed between all of them How does it work underneath? Open well the ACI solution sorry ACI Works with a protocol, which is called all flex so all flex is an open source declarative model Which allows the communication between the AP controller so our ACI controller and the rest of the node of the fabric So what it means is that? ACI AP controller Instructs all the nodes of what are the policy that should be defined and configured in the nodes in terms of What is basically the intent of the user? So if I can give you an example? The declarative model is the way how I'm telling an instruction Rather without telling each and every step to get to the final configuration I would like to have so if I'm thirsty for example In a declarative model I'm just telling my colleague if the if the I'm thirsty and it will figure it out How are the steps in order eventually to pour some water in a glass and bring to me the the glass right? In an imperative model, which is the kind of old or legacy fashion Model of configuring things. I should tell instead if the exactly how to pour water in my glass walk towards me Going through the stairs and eventually bringing to me that the glass right so with the old flex protocol We really want to abstract the way how the controller doesn't have to know exactly The configuration that must be configured in each and every device, but rather only the intent of the user so obviously Those nodes or devices to which we are pushing the configuration must be smart devices if you like So that's why those devices Will be running some sort of opflex agent so some sort of agents which is capable of this understanding this declarative model So the the interesting thing is that? This opflex agent is not only running in the ACI fabric, but is also running in the hypervisor So can be running in the computer nodes that you have for example It can be running obviously in the computer nodes from an open-stack perspective and we'll see it later You know how exactly the paradigm works But also this can be extended to other agents running on VMware if you're having some VMware Computing your data center or it can be also running on Microsoft CVMM as well as on some type of routers or switches that you have in your data center So this is a final slide before we jump into the open-stack Way of integrating with the ACI and these try to summarize very briefly how ACI works with several kind of domains I think it's It's very well sharing the kind of ACI anywhere vision that we have because ACI is an SDN solution that wants to Be a solution not only for your on-premises data center and when we talk about on-premises We talk also about the possibility to extend your data center across multiple pods or multiple site around the world so having VX LAN end-to-end kind of policy enforcement, which is Completely shared across multiple locations, right? But also we work on a remote location or branch offices Where you can extend again your VX LAN extension as well as well your network policy Enforcement so the remote location here that we are working with is the possibility basically to have Small sites where you can deploy just a pair of these switches So the Nexus 9000 switches or even having ACI extended through what we call the virtual pods So virtual eyes lift and spine components that can run in a very many minimal footprint in your extended branch offices At the same time we also work on the public cloud on the other side. So who's not talking about public clouds? I think some of you may have Attended the previous session from our colleagues in CISC about the multicloud solution So indeed ACI is capable to extend towards different clouds So we are working now with AWS but also Google cloud platform and Microsoft Azure are in the pipeline And the idea there is that obviously you can extend through VPN or think like direct connect your data center network policy To the cloud or to multiple clouds and you can decide obviously based on cost or based on different kinds of business analysis How you extend and where and what you extend exactly from your data center So again, that's a 1,000 Foods view of ACI, but indeed it's it's a very brief introduction just For us to be on the same page that when we are talking about what is ACI Now obviously why we are here. We are here because When talking with customers we talk with several customers every week. We understand that OpenStack has a number of challenges, especially from a network instant point, right? So especially we see that many customers are seeing the fact that the distributed layer 3 services are typically a challenge with OpenStack distribution That's not always true obviously because we have got some distributed virtual routing function but in general if you move to more advanced kind of feature like NAT or floating IP or You know other service insertion then having net distributed network services in OpenStack is not really Something trivial at the same time performance, especially you are here probably because you're interested in NFV So performance in the NFV world. That's very very key, right? So performance is Also sometimes in OpenStack a challenge together with visibility and complexity of troubleshooting Why? Because you typically focus on the overlay so the architecture of OpenStack how you create, spawn, virtual machine, Networks, etc. But you have very minimal visibility or at least you don't have a visibility of a kind of merge infrastructure with your underlay so with your switching layer So with ACI we are trying to solve this kind of problems and we have Possibly or hopefully a Response for each and every of those so first of all we replace completely the data pass from a neutron perspective And we distribute basically the routing function starting from NATs, but also floating IP As well as obviously DHCP and then metadata Optimization which is completely distributed in each and every Compute node that you have we'll see more in details actually in a few slides from now The second thing is that we also support obviously hardware acceleration So with the ACI plug-in we do have the possibility for you to run SRUV or OVS DPTK And in the future also VPP you may have heard about VPP also in our other previous presentation Right at the same time sometimes we talk with customers and many are interested to to run other VLAN or VX LAN But VX LAN comes as a challenge sometimes depending on what kind of Nick interfaces you have in your servers, right? So ACI provides you VX LAN in the back end So basically between leaf and spine We always run VX LAN and you can decide if between the compute node and the top of the rack switch You run VLAN or VX LAN But it doesn't really matter from a scalability standpoint because ACI is capable of doing purple VLAN significance So you can indeed run the same VLAN in many leaf pores, but that VLAN may be Significant Significating something different from an ACI standpoint Again from an integrated overlay and underlay perspective we'll see later, but ACI basically completely automates the configuration that is Pushed from a neutron perspective and therefore you're going to have a one-to-one mapping between the neutron component and the ACI Component and that means that you have a much better visibility of both your overlay and underlay You'll have information like in which hypervisor your VM runs But also what kind of encapsulation that one is using and to which leaf or to which top of the racks which That specific compute node is connected to right so really end-to-end kind of understanding Also of how the packet is flowing within the ACI architecture from one end point to another one and Finally the trouble shooting Is significantly improved also from the L score and the telemetry system Which is part of the ACI architecture with some kind of L score which in percentage will tell you You know how else is your system and eventually if there are any problem will warn you with some others and falls so The ACI solution works with multiple different open stack distribution specifically Obviously with our Cisco V solution, but with red hat OSP director or Canonical Juju charms and what I mean by that is basically the all Installation part of Cisco V more OSP director or Juju charms Take care for you of installing already the ACI plug-in and we'll see in a slide What are this ACI plug-in components that we're going to install but basically there's minimal efforts From your standpoint or is completely transparent? I would say the fact that you are running the ACI plug-in or you are not from an effort perspective, right? So you'll see mostly the benefits and rather No, no pain in terms of installation of the whole architecture So what are the main components of the ACI plug-in? There are mainly three there is obviously the ML to plug-in provided by Cisco ACI So you may know better than me what ML to plug-in is is a framework provided by the open stack distribution in order to Configure your underlay switching layer if you want so Cisco obviously provides one plug-in for ACI The second component which is a key of the environment is the ACI integration module the AIM This guy is actually Representing the one who is doing RESTful API call in order to create ACI objects in your ACI Architecture and finally we're going to have the OpFlex agent that one that I was presenting before and this OpFlex agent is Actually deployed in niche and every compute nodes that you have in your open stack architecture So this is eventually the overall Architecture picture where you which you see how that the entire flow works and talking about the flow Indeed we can see here You know a sort of how you are operating your network from an open stack administrator perspective And you will see actually that it doesn't change much from your normal utilization of open stack So the open stack tenant will still interact with neutron rather than Nova you know all the open stack projects from an open stack controller perspective and when creating Obviously all the network architecture architecture rather The the neutron router the neutron network subnets etc. These will in turn Push the ACI integration module to have some RESTful API call to ACI to the AP controller specifically and creates ACI Objects, so we're gonna have a one-to-one mapping of the neutron network created into ACI what we call endpoint groups, right? So when you will attach virtual machine through Nova to your neutron network Eventually the AP controller will take care of configuring the old fabric Infrastructure so that you're gonna have you know your pervasive gateway a configure all the network policy configure in your Nexus 9000 switches environment So this is the the one-to-one mapping that we have I'll go very quickly through it But the idea is that for each and every neutron objects that you have you're gonna have the corresponding ACI object right, so you have a full visibility of the things there and Well, this is a screenshot of the ACI GUI But I just wanted to highlight you the fact that when you create each and every object for example here an open stack project We're gonna have in turn one ACI tenant when we create an ACI an open stack Neutral network you're gonna see objects created automatically in ACI like ACI endpoint group and bridge domain with a corresponding Subnet attached to that which is representing your default gateway Distributed in each and every node and finally you're gonna have VCB on the Nova virtual machines that you create and attach to the Neutral networks, so you're gonna have information right like your VM name The network the encapsulation that VM is attached to The compute node where that virtual machine is running on right? So you will have really a full whole visibility what I was talking to you just a few minutes back Now I want to switch to NFV Kind of challenges and sure Shortly, I will also pass the word to my colleague ifty But in general when talking with customers about challenges on the NFV kind of architecture What we see is that in the NFV world we see that you you may want to create Very rapidly and eventually create and destroy VNF in your whole environment So the challenge there is that you may have VNF Distributed everywhere in in your data center attached to different top of the rack switches even possibly across multiple data center Right, and the challenge is that the scale of sorry the scale of your architecture in terms of VNF That you're gonna have will be much wider, so you're gonna have obviously a need of Representing or doing equal cost multi-pass towards all the VNF that you are creating At the same time also optical optimal performance on the VNF is also a challenge there, right? so the idea of ACI is also to try to work in the in the sense and in the Kind of the field of NFV and reporting and supporting customers around the different Kind of capabilities that are lacking there So if they were gonna talk shortly about a couple of features here I'm gonna brief introduce you here that ACI supports neutron trunks port obviously Also, we do support neutron SVI so the creation and again if they will talk about it shortly the creation dynamically of BGP SVI enabled Networks on the top of the racks which is towards the VNF components Or as well the service function chaining of neutron, right? So you can create eventually service function chaining in your in your environment and be fully supported by Cisco ACI and As well we support the OBS DP DK and SROV and as I said before VPP is also Some roadmap item that we have with the Cisco ACI In the in the short future So I mean say that I will pass now that the word to ifty which is going to talk more about the neutron SVI and the SFC kind of architecture For yours Hello, hello, it's working right anybody can hear me. So thanks Dominico for doing the hard part So it was great. I'm gonna start with this the SVI slides basically what what do we have for actually the Neutron SVI features and which one do we write so? So First thing is in the as actually my colleague has told you that the SVI is used for a couple of different Yeah, so for the for a couple of different reason one is of course you have VNF's that are adding services Dynamically in your data center or in the in the data path of your Traffic that is maybe going from your branch office to the internet So as you add more services, you want to make sure or you add no net networks You should be able to peer with the external world and advertise the routes using BGP or SPF or whatever protocol you like And the second thing is actually giving you the ECMP you have Services that you're deploying that actually are exposing endpoints So those endpoints could actually be the same IP Addresses and if you actually advertise the same IP address from multiple points in in the ACI infrastructure the ACI actually uses the The automatically will load balance the traffic to all of those endpoints depending on the location so it goes to the It first get loads balanced to the 9k switch and the 9k switch will load balance to the the closest and The least used VNF. So that's one of the main thing and and so we need to be able to peer with the rest of the world to actually Basically advertise our routes and the second thing is actually we can use it for a 64 way ECMP which is actually spanning across multiple sites multi-pod so that's one of the main benefit for the SBI So so you could actually support six different pair of switches and And as I mentioned you can actually distribute your load Further so it's it's more like L3 load balancing coming all the way to your Load balancer VNF and then the load balancer VNF is actually doing extra load balancing Layer four to seven down to your application. So it actually gives you far far more scalability and efficiency So this basically is showing that you can I cannot move because of this mic, but let me see if I could use that so so we are Advertising the same web and and and Basically letting ACI decide which which one will actually getting the load So so it actually goes from the external world to the leaf switch automatically because the ACI policy allows it to and then for that leaf switch will actually Load balance it to if there are multiple VNFs Deployed on the end of the same leaf switch. It will actually load balance to the to those And so yeah, the leaf will automatically extend it to that one So and this is basically we have this demo actually running in our Booth if you want to actually come and see we actually have the fall where we have Basically deployed three different networks. One network is actually representing the external world and the second is the our load balancer, which actually has multiple instances, but is is Advertising the same web through BGP which allows us to actually have the external world come in and and Load balance and then this we have this load balancer which actually load balances to a to a real server form So it's basically L3 load balancing here to here L4 7 4 to 7 from here to here So and actually I should I should have practiced the animation. So that it's actually now a say telling one so we are actually it's we're advertising 10 10 10 10 and the and actually when the first flow so it's flow based right the first flow comes in it's going to Just go come to the ACI and ACI will actually round robin it One by one to the to the load balance. So the second flow actually gets goes to the second one and so and from this you we can actually the Load balance the traffic using, you know any any load balancer There are a lot of actually distributed load balancers available that will give you this scale So this application is for those if you can build yourself with their commercial distributed load balancers available from Actually the companies that are they are here and today So it's basically is going to load balance to the load balancer L4 to 7 is going to load balance to the server from that's outside the ACI's ACI will provide switching and writing for that But what the main component is actually the the Tom is too big So the main component is actually the the ECMP that we're providing for for external L2 load balancing So that was the part for the scalability of your application now The SFC is The new Tron standard new Tron Service function chaining API, right? So what it allows you to do is create port pairs Deploy your VNF on that port there using ingress and egress port and then Define some kind of a classifier that will allow you to actually start Sending the traffic to your VNF or whatever you're deploying and then the return path so It is done using What we call is a multi-node PBR PBR in ACI is what it's called policy based redirect a policy based redirect is done with with With a construct that we call a service graph that gets applied to a Traffic or a router for example and anything that is flying through it. We can say from using this classifier redirect this traffic To this port pair and then bring it back So in multi-node means you could actually have multiple bumps in the wire Which means you could actually take a service to VNF one from VNF one to VNF two We have to do VNF three and then back so you can define all of those things without actually having any domain knowledge of ACI That's what actually it allows you to do So you do not need to know anything about ACI you best basically use the neutron calls Which is create port pairs Port groups create flow classifier Then you can create a service chain when you as soon as you create the service chain the traffic will automatically get redirected because of the ACI service graph functionality and then you and Dynamically you can add and remove nodes to that particular service chain by using update service chain And it's it works out of the box without having to do anything on the ACI side so this is the basic so we have basically four chain API and that actually managed by by The new trunk and then the driver manager Passes that and then is what happens is a I am will actually which is My colleague mentioned it's the the main module that pushes all the all the neutron constructs to the ACI I will actually push it to the to the ACI fabric and But for the neutron site it actually the same way we're creating the port chain. We could take the port Port pair we're taking multiple port pairs making them port pair group if you take multiple port pairs and Create a port pair group. You're deploying those VNFs vertically and ACI will take the responsibility of load balancing to those so that that's also Provided automatically the load balancing to vertical VNFs and if you have multiple Port the port pairs in the service chain Port pair groups and they're deployed Horizontally, which means if you have three port pair groups and you're applying into a service chain It's going to take your traffic to the first four Port pair group first VNF then second VNF and the third VNF if you add another port pair group update that that that service will automatically be inserted into your path so What We support is actually the API and the functionality the CLI For actually creating the the neutron port port pair create command the neutron port Pair group create more classifier create all those commands are part of the neutron CLI so that CLI extension has to be provided by the By the vendor, but we we fully support the API and it works out of the box. Of course, you can always get the Get the neutron SFC a CLI is just a Python to SFC and that actually will allow you to create this But of course the vendor that is giving you the open stack is the one who has to support that part We support it past the so so open stack creates everything so basically When you're creating the SVI as the open stack will create the SVI It's an extension to neutron. So you'll say I want to create a net neutron net create type SVI it will It will actually automatically push the configuration. So neutron Side will create the SVI. It'll manage the life cycle of the VNF and it will manage the the port Port chain, right? So all those three things are are declaratively done from the neutron side and what the it's actually pushed to the to the ACI and ACI actually Does the data path orchestration which means that the traffic automatically will start Going or if you're actually peering it will make sure that the that you can actually have peering capabilities with the external world And so once we created it actually is implemented as a server world as a saying it was a multi-node Service graph so you basically have the client and then you have a server you have two networks and Within that you're inserting this graph. So To create this what we do is we have to create networks Which means you have you created two networks and you created ports ingress and egress port after that what you do is you Insert that into a service chain. So and that VNF will actually start receiving the traffic and And then inside is ACI we have a different semantic, right? So we have the the consumer and the provider instead of the ingress and egress But it actually means the same thing. This knowledge is not required at all to to use it All you need is a sniffer to see that. Yes I'm actually seeing my traffic come to this VNF and it's going out or if you have any monitoring that automatically gets Done, sorry, we don't have too much. So This is just a simple example of Creating it so that we create two networks We create a float a flow classifier Then then we basically create the ports we create the ingress port we create the egress port We basically use the nova to To start the VNF using the ingress and egress port We also create the so we take those two ports and we Put them in a port pair using just the neutron port pair command Then we take that port pair and we create a port pair group. It's just a single Instance if you have multiple port pairs and you create the port pair group from them then it actually will be deployed vertically and Then from the port pair group and the classifier that we created in the last page. We actually Create the neutron port there using the neutron port pair creates. So it's basically completely neutron workflow there is absolutely nothing non-standard about it and and and the magically you'll start seeing that the traffic that you're classifying is automatically reaching the ingress port of the VN and that traffic that you send out from that VNF actually goes back so that's that's the That's the VNF part you can as I said you can actually add and dynamically remove VNFs by just using the the update The port chain update command. So here are basically creating two more networks You see that I Think it's running out of battery or something So yeah, we're creating the source and add destination at another port pair and then we basically add that With the same plus if I sorry, I went too much back Yeah, more pumps in the wire. So we create another another network. We create two more ports. We add a Basically create another another port pair group and then we use those two port pair groups So if we're using initially when we created the Chain we only had one port pair group then we actually update and we add the two Two port pair groups like cluster one and cluster two And it automatically will add the second port pair which means the second VNF will also start receiving the traffic that is leaving the first VNF so and So yeah, and that that is what is a multi-node PVR, which means you see now multiple VNFs on the ACI. This is basically the ACI side But as I said like ACI and knowledge is not really required But just to see you can actually get full visibility on the ACI side in actually what is being inserted in your traffic So this is a very very typical Use for all these things together What we have is basically we have these VMs which are basically brass VMs We have an external net VM and this basically is customers data center. They're all actually running on open stack So from here we create an SVR We can actually say the route to to Google or 888 is through here So all the traffic will start coming here here We can actually Advertise here outside and say the route actually to the data center is here That's the peering part if you want a react also serving A different type of applications here. You can also use To scale your thing and now that actually and then this SVI Will start having all the customer traffic flow through this transit network and go outside Now what we can do is we can use those Neutron port commands we can create these networks and actually start inserting dynamically Applications into the path of that traffic and another thing is we could actually have multiple copies and we can use segmentation using the Neutron port to separate different branches or different Customers or different tenants traffic and we can treat them very differently depending on that segmentation Sign that so this is going to be a trunk port here and a trunk port here and then this actually is Going to have multiple VLANs pass through it and then you can actually define depending on the networks in the VLAN that you're creating dynamically you can treat different Customers traffic different types of traffic differently by actually using different VNFs Depending on what actually you need for for that. So this is a very simple Use case that you can put together There's a lot of a lot of resources to to run all of these things But you're really really welcome to come to our The demos that we have so that was basically it and if you have any questions Back to So I'll sum up very quickly. We're running out of time. I guess we highlighted a Number of benefits to run ACI and open stock. So ACI and open stock better together I think that should be hopefully clear by the end of the session, but We've got some want to know more some links where you can find more information Also, we're gonna be at the booth Just the other side of the of the building so you can find us there and Yeah That would be all from our side So if you've got questions will be around will be at the booth so you can find us anywhere you want Thank you all for coming


Hi everyone, I'm Joe for Jaspy's CaseBreaks.com with a brand new release 2020 Panini Impeccable Football 3 box picker team 3 Big thanks to all of these folks right here for getting into the action Nick S back in the action getting last spot mojo Falcons here on a Wednesday 3 box picker team 3 Thanks everyone for getting in Only just a few just just a few number block teams here. So that was the number block group There are the results Obviously only only applies to pick your team three. That's in a separate video All right, and let's Let's pop this baby open. Let's see what we got brand a new release drop today Got more in the store too. Jaspy's case breaks calm. What do we got here? We got kind of a What we got we got a chocolate and vanilla French vanilla chocolate and vanilla color here Yeah, we're just brown and yellow if you want to simplify it. All right, so There's the pack right there. Oh Hook us up with filler cards and these these impeccables Good luck Traditionally, there should be a base card on the bottom, but there's not okay We'll use one of these blank cards to slow play the hits a little bit Right out of the gate. We got nine out of ten Aaron Rogers Josh with the Packers Yeah, it kind of looks like a candy box, right? We got Russell Wilson 49 out of 50 Ryan Ryan Hunter with Seattle Got a Julio Jones 73 out of 75 for the Falcons Nick And we've got Russ Grimm 21 out of 75 Hall of Famer Indelible ink autograph going to Mark Mazzur and the Washington football team You know, what's he all about the Redskins made three championship runs behind Grimm at left guard. There you go The three-time first team all-pro was in his second year when Washington went for no in the playoffs after the 82 season route to winning Super Bowl Xvii Yeah, he was a beast Chris Maxwell saying hogs All right, he's just Teddy. What if they just changed the name of the team to the hogs Washington? That'd be awesome We've got rookie autographs Jordan Brooks 25 out of 25 for Seattle Love the impeccable look sort of a canvas finish on the card a burst of watercolor in the background we've got Chad Johnson nice four out of 25 Ocho Cinco Now the Bengals are a number of block team so Cincinnati for Sean Maddock was Cincinnati for it's a nice patch there, too This is player warm, but nice there you go Sean a couple more here out of the first box We got Cam Chancellor on card autograph 19 out of 50 canvas creation autograph for Ryan Hunter in Seattle and the last one here is oh Justin Herbert got a nice patch Maybe a piece of the helmet and An on-card autograph 34 out of 75 Justin Herbert Chargers picked up straight up by Matt Arnold as be the the piece of the helmet looks like with that Still cool though.  Oh And the packaging is a little rough on this one right out of the box Doesn't seem like any cards or damage. That's that's the good news All right, it's been a while says Matt Arnold finally a hit and a nice one, too. All right Bill Happy Thanksgiving to you, too We got Tom Brady 65 out of 75 Rough game for him the other night People getting on him for not taking Jared Goff's hand. Oh, that's a number block team So that goes to five Tampa Bucks five Be for Gary. I got Aaron Jones 31 out of 75 Packers Josh Bruce Break schedules in the chat Dustin Hidden in the chat and I think nightbot just dropped recently as well Quentin Nelson 30 out of 75 Colts That'll be for Kurt and the blue horseshoes although a white horseshoe here, but Blue on their helmet and we've got oh a blockchain card. It's Henry rugs Rookie patch autos gold for my Raiders that Raider redemption going to EA picked up my Raiders believe it or not there there is some Some value to these on the secondary market. Some people are into the blockchain stuff I haven't quite wrapped my head around it yet And there you go EA We've got Darius Layton two-color patch an on-card autograph 46 out of 75 48 out of 75 New York football Giants. I don't know. Do you get a card on your phone? I think that you're able to trade those those digital cards something like that The Giants are a number block team. So that's 40. That's Giants eight and that'll be for Chris Maxwell. There you go, Chris The Darius Layton and got rookie autograph Jeff Gladney 16 out of 49 for the Minnesota Vikings It's gonna be for Jarrett Kay, but yeah, I think it's I think Panini and Toth and all those companies have Tempted to crack the holy grail of Of a digital card, but we'll see how it goes All right, we got another Viking for Jarrett 12 out of 90 not 12 out of 25 You like that? You like that Kirk Cousins, I guess you like that now I think is He actually copied your trademark It's got a nice autograph that good penmanship All right next one is Josh Allen on card autograph six out of 17 six out of his jersey number That looks pretty sharp Buffalo Bills Are a number block team who's got Buffalo six? I Don't be for John John L with Buffalo six. You know they're coming off a buy this week And back here is Antonio Gandhi Golden five out of 15 Looks like a couple pieces of his glove there. Maybe a helmet sticker on top That's pretty awesome Mark, Missouri with the Washington football team To pick for a 190 top loader we'll slide that in there There you go mark and we'll add some of these filler cars there. So it doesn't rattle around during shipping. All right Final box, there's the pack right here this one's More intact and there's the case hit down here The metal piece could be a piece usually a piece of silver, but could be some gold. I want the gold Give me the gold. I Want to know where the gold at redemption on the bottom? We got Dan Marino 19 out of 50 Dolphins Travis the old the righty Todd Gurley to 75 for Nick and the Falcons. I think my Raiders are playing the Falcons this weekend Raiders got Damien Williams 17 out of 75 Super Bowl autograph That'll go to Chris McKee and the Kansas City Chiefs we got Jason Huntley Detroit Lions rookie autograph 81 out of 99 for Eric Jay and the Lions We got Austin Eckler Four-color passion autograph 26 out of 75 for the Bolts. I spray for Matt Arnold and the Chargers Yeah, looks looks like there's a little bit of turf right there. No Definitely game use a couple more here and then the case it we got a Mari Cooper 19 out of 25 canvas creations autograph For Dallas that'll be for Josh proofs Bread big rig just checked the price of gold for us. It's 1,889 dollars 57 cents per ounce the redemption is T Higgins Cincinnati Cincinnati's a number block team. So Cincinnati zero is Brian With the redemption spot Elegance rookie helmet and patch auto We're on to Cincinnati not gold Silver Hall of Fame Oilers warren moon Nice seven out of 20 that of course goes to the Texan that's Aaron Amon zone With that fine fine silver It's a Troy ounce. There you go and there you have it ladies and gentlemen That was a great break. Do I have to any randomizers? No, I don't that was three box pick your team three of the brand new 2020 Panini impeccable football. There's more in the store on jazby's case breaks.com. I'm Joe I'll see you next time for the next break. Bye. Bye