Ceph

h1. -1D - RGW Geo-Replication and Disaster Recovery

<pre>

*** rturk is now known as rturk-away	09:32

*** davidzlap has joined #ceph-summit1	09:32

*** davidzlap has left #ceph-summit1	09:32

*** rturk-away is now known as rturk	09:33

scuttlemonkey	florian, want in to speak on this one?	09:33

gregaf	fghaas: ^	09:33

loicd	ccourtaut: is having troubles with his video connection	09:33

loicd	video / audio	09:34

fghaas	I'm here, yes :)	09:34

fghaas	it's ok for me to lurk though :)	09:34

scuttlemonkey	k	09:34

ccourtaut	i'm currently having problem between my isp/google services :/	09:34

*** wwformat has quit IRC	09:35

*** henrycc has quit IRC	09:35

loicd	http://wiki.ceph.com/01Planning/02Blueprints/Dumpling/RGW_Geo-Replication_and_Disaster_Recovery	09:36

loicd	http://pad.ceph.com/p/RADOS_Gateway_refactor	09:36

*** liwang has quit IRC	09:36

gregaf	loicd: hey, I finally have video of you and it's a beautiful hallway :P	09:38

*** yehuda_hm has quit IRC	09:39

lmb	Are the replicas consistent? (As in, they represent a valid, consistent state of the object at any given time, even if outdated)	09:39

*** yehuda_hm has joined #ceph-summit1	09:40

sagewk	lmb: yes	09:40

sagewk	the (replicated) updates are atomic	09:40

sagewk	but not necessarily ordered (across objects)	09:40

loicd	gregaf: there you see me for real ;-)	09:41

lmb	sagewk: aye	09:41

rturk	hi, loic!	09:41

loicd	:-D	09:41

loicd	it would be useful to have links to the http://tracker.ceph.com/projects/ceph issues related to http://wiki.ceph.com/01Planning/02Blueprints/Dumpling/RGW_Geo-Replication_and_Disaster_Recovery in the pad	09:45

dmick	loicd: add them!  :)	09:45

rturk	loicd: I'm working on a dekiwiki -> redmine plugin	09:45

rturk	so you'll be able to embed them the way you embed etherpads	09:45

rturk	as part of the post-summit work, I planned to share it so ppl can cross-link their work items	09:46

paravoid	they're not new	09:46

paravoid	but it doesn't really work	09:46

paravoid	I opened several bugs about it (incl. performance ones) and they said that they weren't really well designed	09:47

paravoid	they're implementing geo-replication themselves and they're not reusing this code for this	09:47

paravoid	that was on swift 1.7.x, I don't know how it has evolved since	09:48

joao	loicd, wave for us	09:48

scuttlemonkey	paravoid: so was the feeling you got that they were abandoning that code?	09:48

scuttlemonkey	or just not repurposing it for geo-replication	09:48

loicd	:-)	09:48

paravoid	I don't think they're abandoning it since it's there, but it's really for a different purpose from the get go	09:49

michael_dreamhost	the swift-sync seems like a higher level user controrable interface, rather than a cluster policy	09:49

*** liwang has joined #ceph-summit1	09:50

scuttlemonkey	makes sense	09:50

paravoid	the problem with not doing it in the rados layer is that we'll end up with having 6 copies for each object	09:50

joshd	fghaas: glance has their own plans for doing data transfer between regions	09:51

gregaf	paravoid: not necessarily, you could do 2+1 for instance	09:51

paravoid	well, not really	09:51

loicd	http://tracker.ceph.com/projects/rgw/search?utf8=%E2%9C%93&issues=1&q=multisite does that cover it ?	09:51

paravoid	because if I have two lost drives at the same time on one of the clusters	09:51

paravoid	(probable enough)	09:51

paravoid	the pg would be lost	09:52

paravoid	and radosgw replication won't recover it	09:52

hskinner	Please consider geo-dispersion of erasure-encoded objects as you design this	09:53

fghaas	gregaf: feel free to correct me if my summary of your reply is incorrect in the pad	09:53

gregaf	good enough for me, but I'm blunter than they are ;)	09:53

scuttlemonkey	hskinner: that would be a good thing to add to the etherpad as an "other" or something	09:54

scuttlemonkey	perhaps under coding tasks and yehuda can move it around where he wants	09:54

*** chee has quit IRC	09:54

fghaas	gregaf: better?	09:55

gregaf	lol, I did *not* say that	09:55

*** chee has joined #ceph-summit1	09:57

pioto	so, this geo replication being discussed is up at the rgw layer, and not, say, rados?	09:57

scuttlemonkey	pioto: yes	09:57

pioto	meaning, it won't be able to support cephfs or rbd, then? hm	09:58

scuttlemonkey	pioto: the hope is to eventually move it down the stack	09:58

pioto	ok	09:58

fghaas	pioto: I'm sure gregaf has a "blunt" comment for you ;)	09:58

scuttlemonkey	pioto: I think it's more about _using_ rgw to sync all data	09:58

lmb	scuttlemonkey: the "ain't gonna happen" comment on the pad? ;-)	09:58

scuttlemonkey	not limit it to rgw	09:58

nwl	pioto: the driver is disaster recovery. you can use incremental snapshots of rbd with export/import between clusters to do RBD DR	09:58

scuttlemonkey	but someone else can clarify	09:58

fghaas	lmb: I just attributed that one :)	09:58

pioto	nwl: yeah. i thin kthere's also whole-cluster snapshots i saw somewhere	09:59

loicd	what task would you advise a new coder willing to help to try to help with the implementation of geo replication ?	09:59

pioto	but i dunno if there was a good way to replicatte that directly to another cluster.. .think it wanted a whole giant local directory to export to first?	09:59

lmb	scuttlemonkey: access must go through rgw though, otherwise it can't log/journal, right? so you can't use rgw-replication on top of an arbitrary block object	09:59

fghaas	lmb: that is the plan, as it stands	10:00

paravoid	will it scale?	10:00

paravoid	:)	10:00

paravoid	for both large amount of containers and objects	10:01

lmb	fghaas: too bad, misses our use case, but clearly its a great first step	10:01

fghaas	lmb, I know -- surely there's plenty of folks that would love to see this in rbd	10:01

fghaas	which is what I guess you're relating to	10:02

paravoid	sagewk: ^	10:02

rturk	paravoid: I think there's a min or so delay w/the feed FYI	10:02

lmb	fghaas: yeah. similarly though, perhaps it could be implemented in the client-side libraries	10:02

fghaas	librbd I/O multiplex? joshd?	10:02

*** nwat has quit IRC	10:03

*** nwat has joined #ceph-summit1	10:04

*** nwat has quit IRC	10:04

</pre>