 My name is Vinky Shankar and I work on the cluster first into that and I am the team leader of the replication team and with me I have few of my cluster folks here ready for answering your questions. Okay, so let's begin. So before we start how many of people have used cluster? Please raise your hands. Okay, a few. Okay, Hadoop. Quite many. Okay, so let's see. So let me start by talking a bit about cluster Fs itself and then we'll move with the Hadoop big data interface part. So obviously cluster Fs is, we are obviously storage. We can scale to petabytes. We have distributed scale out mass. And essentially what we do is we are posix compliant and also we are metadata less. So if you have used any other distributed storage, there's a concept called as metadata server. That is a single point of failure. If that goes down, essentially you can't access any files in your distributed system. That's because the metadata server has all the engines. So what cluster Fs has, a big advantage is we are metadata less and because of that we are in a very good shape. Okay, let me focus a bit about scale out and distribute feature here. So with scale out, so any of you who have used cluster Fs, we have different topologies in which you can set up your cluster. One is a distribute, distribute replicate, and distribute replicate and strike. So with distribute, actually what you do is you have a bunch of servers. You configure your cluster in a distribute mode and your files are actually hatched to different nodes. So if you want to access files in parallel, you are actually spreading out your load on different servers. And where replicate comes into picture is when you want a fault or a lint system in which you distribute files on a bunch of nodes and then replicate it to our feedback depending on what your use cases. Okay, so at the very top level, that's what I talked about, cluster Fs coming a level down. cluster Fs is also Hadoop ready. What do you mean by that? So Hadoop is actually a map-reduced framework plus HDFS. HDFS is Hadoop Distributed File System, which is basically has a centralized metadata server also called as name node and a bunch of storage nodes also called as data nodes. So where do we come into picture? So as you saw in the earlier slide, we are metadata less. So if you are using cluster Fs as a backend store for Hadoop, you are actually eliminating the name node, which means you are left with the client machine in which the macro is your branch and the storage nodes. So for Hadoop to use the cluster Fs plugin, Hadoop to actually talk to cluster Fs, we have something called as a cluster Fs plugin, which we will come in the next slide. So the good thing about that is, if you plan to use Hadoop with cluster Fs, one first point is you save data ingestion time. So how does that come into picture? Suppose you are running a patch of a server and you have lots of access logs, your site is getting hit pretty badly and you have lots and lots of access logs and you now want to analyze data. So what do you do? You pick up the access logs and dump it to HDFS. So as you see, you are actually copying data from one file system to another. Where cluster Fs can help you in that is just because we are a process compliant file system and the interface to cluster Fs is via what we call as a native protocol or the fuse client, you can actually mount a cluster volume as a normal UNIX mount product. So if you see what you can do in your Apache web server, just point your log directory to the mount point and there you are done. Every request that is logged by Apache web server is actually going into cluster Fs. And now when you want to analyze data, you use the cluster Fs Hadoop plugin and do your analytics. So where we save time is in the share. Also another great feature is you can access data via multiple protocols. That is, as I just told about it, fuse client is something which is one of the widely used way of accessing data on cluster Fs. Other bits include NFS, HTTP interface, which is OpenStack Swift. We also have a plugin for that. So you can use the rest APIs to put, delete and get files from cluster Fs mount point and obviously Hadoop itself. Now you have your data on cluster Fs. Now what do you do with it? You run MapReduce jobs on it. And how do you do that is what we cover in the next slide. So what does it take to run MapReduce jobs on cluster Fs? Two things. One, a cluster Fs Hadoop plugin, that is a jar file and a configuration file. That's it. So a plugin. What does a plugin mean? It has to be pluggable. Your application need not do any rewrite of jobs. It need not be rewritten. You just take the Hadoop, cluster Fs Hadoop RPM or build it from source, govish and just install it on a machine. Do one configuration file, which I'll be showing you as a demo. And then that's it. No rewrite of application. Let me cover this a bit about the plugin itself. As of now, it's tech preview. That means you could have bugs in place. So if you find it, please report it. So how does it work internally? So Hadoop actually provides an interface called as file system interface. So what we do is just extend that interface. So that interface covers basic operations like open, close, which is very, very basically to access a file anywhere. And some advanced API like get me, given a file, get me all the blocks. Where is it in distributed in a setup? And what is the chunk size? So there are very, very low level APIs and very, very difficult APIs in which you need to put that API in a way in which you understand the underlying file system. So the cluster Fs plugin does all that for you. And the communication to the plugin communicates to cluster Fs via, as I told the fuse mode or the network. The other thing that is very close to Hadoop is given a file, where are the blocks? With HDFS, you actually have a centralized metadata server. So the MapReduce framework actually contacts the name note of the centralized metadata server and gets the list of blocks. With cluster FS, since we don't have the name note, what we do is there is something called as an extended attribute in a file. It's a file system concept where you can store key value pair associated with a particular file. So actually the plugin itself talks to cluster FS, queries the extended attribute, gets the required amount of intelligence to give it back to Hadoop. And that's it. Then Hadoop takes care of scheduling jobs. So what we have tested it so far? We have tested it with MapReduce, existing MapReduce applications. That is these include applications that ship with Apache Hadoop, the example applications. And there's something called as Apache PIC in which you do a scripting kind of thing. It's not a shell script. It's a normal scripting language. You give it to a PIC binary and it converts it into a MapReduce application. So we have tested it with Apache PIC as well as HBase. HBase is a MapReduce database in which you fire a self query kind of thing and internally it's actually a MapReduce application. Now that's it for the talk. I'll just demo. So yeah, one more thing I want to mention the plugin itself only works with Hadoop, this version of Hadoop, 0.20.2. It's tied to this version. We are working on extending the plugin to support other versions. Also the current 1.0, but that's in progress. That's in the timeline. Now I'll show you what configurations you need to do. Once you have untied Hadoop and done all those relevant changes to Hadoop and PNV, there's something called as... This is the Java. You can actually build it from source or have an RPM in stock. Anyway, it should be present in this specific location. Untied Hadoop and there's a lib directory. Put it in there. This is the Java file and we ship a sample configuration file which you need to edit. That is core site. Please don't touch this one. This tells Hadoop to load the cluster FSjar. The rest of all is what you need to touch. Currently I'm running a one node cluster on my laptop only. FS.default.name should be in this format. Cluster FS. This file will present in all the nodes in the cluster. This should be the name of that particular machine. This is the volume name. Anybody who has used cluster you can create a volume. As I said, it can be distributed, replicated, striped. You create a volume that is through cluster CLI. I created a distributed replicate volume with four bricks. These are my export directories. This is my volume name. I use the same volume name here. This tells Hadoop to actually mount this volume via the native protocol. You can run map reduce jobs on the data present inside this volume. Next is the mount point. Because we use to do a fuse mount, you need to give a mount point. This directory should be existing. That is put it here. The final thing is this. Because it needs to do a mount, you need to give the host name or the IP address or any storage node. This is a performance tunable. I will explain this. Currently, just leave it to off. This gives a good performance boost. That is because of the way in which the plugin works. We have seen some bugs in that. For now, just leave it for off. You drop the jar, you do the configurations and then you do the normal. Before that, there is a map red site. This you need to do for your HDFS thing. This has to be pre-done with any system. Once you have done these, what you do is you do start map red.sh. I have already done that beforehand. What you will see is some demands running. These are two demands. One is a job tracker, one is a fast tracker. Because there is a single node cluster, you see it in the same host. Once that is done, now you need to copy some files. Here is the mount point. What I will do is add some files in this directory. In data. I have copied some files. As an example, you are a patchy web server. Your log file directory would be actually pointing to this. Whenever there is a hit on your site, it will be locked here. What you can do next is run some jobs. Before I run a job, there is this thing called for loop shell. It provides some basic. From this shell, you can run a map red job. You can run a normal file system operation. Let me run a normal ls. If you see, because now I have configured it in core site, in the configuration file, it is initializing the cluster of s. Then it dumps all those. As you see it here, in this, you see the same thing there. This is Hadoop's way of reading. This is the way to test out whether your configuration is fine or not. You do well as you do cat or something. This works. Now, coming to the actual MapReduce, I have this. This is the example file that ships with Hadoop. It is called Hadoop.examples.char. There are a bunch of applications. These are all MapReduce apps. Pre-written for your thing to test it out. What I will run is, I will run a grab job, a distributed grab job, and maybe a distributed wordcom. Let's see. How do you run grab? Just to grab, it will show you how to run it. You do in, underscore, there. You don't get the actual mount point, mnt, Hadoop. Don't do that. That's internally there. The plug-in conversion file. Just get in there, and out there for grab, and then get the keyword you want to grab for, out there. Now it's running MapReduce. It's 0% map, 0% reduce. It's using the surface behind. Slowly, ready for catchment. Once this is done, currently you can see that if you do a normal list, you'll see the directory is getting created. This is what I talk about multi-protocol access. You can run it from Hadoop, see the output from a different mount point, from HTTP, whatever. Once this is done, let's do a cat of how data of grab. The preference is eight times of the list. Another job is called word.com. Once this is done, it's done. There you go. Word.com, the original file. So I'm done with that demo and the talk. Any questions? Yep. And you're saying you specify the name node in the course name configuration? Yes. Which node do you specify here? Any storage node. So to mount, you need to give the IP or host name of the storage node. Just give it that. And you keep it uniform, so that you can copy the same file. You need not do an edit. Keep it same so that you don't have to change the configuration. What is the performance with respect to HDFS? What's the performance with respect to HDFS and MAPA? So with MAPA, we are unable to test it with HDFS for read-only workloads. We are on par and for some of the jobs, even better for read-only workloads. But for write workloads or a mix of read and write, in which say it's 70% write and 30% read, we are a bit slow. But we are working on having buffering at the plugin level to improve that. But if your job is purely read-only, like there's grep and work on, in which mostly it reads, reads, reads. So we are on par and even better. If you choose distribute, distributed, replicated, striped volume, you are actually scaling out pretty well. Typically, people who use data processing can do that sometimes. But there's data mostly inside and outside. So there is a way to get the data in. So that's what it is. So why do you kind of protocol activity protocol or something like that? We have a STTP access to files on the surface. That's for OpenStack Swift. We have modified it to talk to the surface. You can do that in place. And then directly via STTP rest calls, you can do put, get, and even delete files. Or you can do the classic Unix way of mounting it. I don't think a native mount or a NFS mount. Or anyway, you can use the Stadoop schedule. So I told you to a FS. I can show you. FS, like this hyphen ls. There's a hyphen port I think. And a hyphen get, hyphen cats. We can use even this. But what we recommend is either you use the Unix, classic Unix way of mounting it or through a STTP. It uses fuse mount. It doesn't do JNI and load. We have a live cluster FS client coming up, but it doesn't use that. It doesn't use JNI to load that and use that. So if you see here, right, a lower mount, it actually does a fuse mount, native mount, and uses that. So what you are seeing here, it was, the plugin will see in its namespace like this. You mount it and then configure FS to store lockfiles in that.