| Hi,
Please keep the list on CC as I guess others might be interested as well, if you don’t mind.
For VMs one can use rbd backed block devices and for bare-metal nodes where there is no abstraction one can use krbd - notice the k there, it stands for “kernel”. krdb is the in-kernel driver as there is no other abstraction layer there to provide unlike in the VM case where qemu can use librbd to implement the functionality.
If it’s a VM environment anyway then just attach the volumes from the underlying ceph and you are good to go. Make sure to attach multiple volumes on the same node for better performance - if you want 10TB per node for example, I’d mount 10x1TB.
I’d keep the replication in HDFS as that gives it “fake” data locality so better processing in MR/Spark workloads; just make sure you do map the nodes to different physical zones in your ceph cluster; way I’d do it is split the nodes across the racks, so let’s say 10 VM on rack 1, 10 VM on rack 2, 10VM on rack3, and set up the crush rules to keep the data on that particular volume within the rack.
This maps your underlying failure domains from ceph to hdfs basically.
Hi Zoltan! Thanks for the tips :)
I suppose the krbd is for bare metal nodes? I ask because you says "for vm's" for both of them ;)
A couple of questions if you don't mind. This cloud is base in apache cloudstack, so I understand I should go to the VM way, right? And why is better not to use krbd if they are VM's?
I understand i should disable replacation in one of them. Would be your recommendation to do it in ceph or in hadoop? Ceph seems to be more reliable, but i have doubts if any hadoop feature would work bad if replication is disabled "from the hadoop side".
THanks!
De: Zoltan Arnold Nagy <zoltan@xxxxxxxxxxxxxxxxxx>
Enviado: viernes, 05 de febrero de 2016 02:21 p.m.
Para: Jose M
Asunto: Re: Ceph and hadoop (fstab insted of CephFS) Hi,
Are these bare metal nodes or VMs?
For VMs I suggest you just attach rbd data disks then let hdfs do it’s magic. Just make sure you’re not replicating 9x (3x on ceph + 3x on hadoop). If it’s VMs, you can just do the same with krbd, just make sure to run a recent enough kernel :-)
Basically putting HDFS on RBDs.
Hi Zoltan, thanks for the answer.
Because replacing hdfs:// with ceph:// and use CephFs doesn't work for all haddop componentes out of the box (unless in my tests), for example I had issues with Hbase, then with Yarn, Hue, etc (I'm using the cloudera distribution but I also tried with separate components). And besides the need to add jars and bindings to each node to get them work, there are a lot of places (xmls, configuration) where the "hdfs for ceph" replacement need to be made.
Giving this issues, I thought that mounting ceph as a local directory and then use this "virtual dirs" as the haddop dfs dirs, would be easier and will work better (less configuration problems, and only changing the dfs dirs will make all components work without any more changes).
Of course I can be totally wrong, and it's a core change to do this, that's why I think I should ask here first :)
Thanks!
PS: If you are asking why I'm trying to use ceph here, well it's because we were given an infrastructure with the possibility yo use a big ceph storage that's working really really well (but as an object store and wasn't use until now with hadoop).
Might be totally wrong here, but it’s not layering them but replacing hdfs:// URLs with ceph:// URLs so all the mapreduce/spark/hbase/whatever is on top can use CephFS directly which is not a bad thing to do (if it works) :-)
On Tue, Feb 2, 2016 at 3:42 PM, Jose M <soloninguno@xxxxxxxxxxx> wrote:Hi,
One simple question, in the ceph docs says that to use Ceph as an HDFS
replacement, I can use the CephFs Hadoop plugin
(http://docs.ceph.com/docs/master/cephfs/hadoop/).
What I would like to know if instead of using the plugin, I can mount ceph
in fstab and then point hdfs dirs (namenode, datanode, etc) to this mounted
"ceph" dirs, instead of native local dirs.
I understand that maybe will involve more configuration steps (configuring
fstab in each node), but will this work? Is there any problem with this type
of configuration?
Without being a big HDFS expert, it seems like you would beessentially putting one distributed filesystem on top of anotherdistributed filesystem. I don't know if you're going to find anythingthat breaks as such, but it's probably not a good idea.John
Thanks in advance,
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________ceph-users mailing listceph-users@xxxxxxxxxxxxxxhttp://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
|
