Actions
-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
Updated by Jessica Mack almost 9 years ago · 1 revisions