Project

General

Profile

-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