-1D - RGW Geo-Replication and Disaster Recovery¶
*** 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