My requirement is to have full disaster recovery, buisness continuity, and failover of automatet services on second Datacenter, and not on same ceph cluster. Datacenters have 10GE dedicated link, for communication, and there is option to expand cluster into two DataCenters, but it is not what i mean. There are advantages of this option like fast snapshots, and fast switch of services, but there are some problems. When we talk about disaster recovery i mean that whole storage cluster have problems, not only services at top of storage. I am thinking about bug, or mistake of admin, that makes cluster not accessible in any copy, or a upgrade that makes data corruption, or upgrade that is disruptive for services - auto failover services into another DC, before upgrade cluster. If cluster have a solution to replicate data in rbd images to next cluster, than, only data are migrated, and when disaster comes, than there is no need to work on last imported snapshot (there can be constantly imported snapshot with minutes, or hour, before last production), but work on data from now. And when we have automated solution to recover DB (one of app service on top of rbd) clusters in new datacenter infrastructure, than we have a real disaster recovery solution. That's why we made, a s3 api layer synchronization to another DC, and Amazon, and only RBD is left. Dnia 19 lut 2013 o godz. 10:23 "Sébastien Han" <han.sebastien@xxxxxxxxx> napisał(a): > Hi, > > For of all, I have some questions about your setup: > > * What are your requirements? > * Are the DCs far from each others? > > If they are reasonably close to each others, you can setup a single > cluster, with replicas across both DCs and manage the RBD devices with > pacemaker. > > Cheers. > > -- > Regards, > Sébastien Han. > > > On Mon, Feb 18, 2013 at 3:20 PM, Sławomir Skowron <szibis@xxxxxxxxx> wrote: >> Hi, Sorry for very late response, but i was sick. >> >> Our case is to make a failover rbd instance in another cluster. We are >> storing block device images, for some services like Database. We need >> to have a two clusters, synchronized, for a quick failover, if first >> cluster goes down, or for upgrade with restart, or many other cases. >> >> Volumes are in many sizes: 1-500GB >> external block device for kvm vm, like EBS. >> >> On Mon, Feb 18, 2013 at 3:07 PM, Sławomir Skowron <szibis@xxxxxxxxx> wrote: >>> Hi, Sorry for very late response, but i was sick. >>> >>> Our case is to make a failover rbd instance in another cluster. We are >>> storing block device images, for some services like Database. We need to >>> have a two clusters, synchronized, for a quick failover, if first cluster >>> goes down, or for upgrade with restart, or many other cases. >>> >>> Volumes are in many sizes: 1-500GB >>> external block device for kvm vm, like EBS. >>> >>> >>> On Fri, Feb 1, 2013 at 12:27 AM, Neil Levine <neil.levine@xxxxxxxxxxx> >>> wrote: >>>> >>>> Skowron, >>>> >>>> Can you go into a bit more detail on your specific use-case? What type >>>> of data are you storing in rbd (type, volume)? >>>> >>>> Neil >>>> >>>> On Wed, Jan 30, 2013 at 10:42 PM, Skowron Sławomir >>>> <slawomir.skowron@xxxxxxxxxxxx> wrote: >>>>> I make new thread, because i think it's a diffrent case. >>>>> >>>>> We have managed async geo-replication of s3 service, beetwen two ceph >>>>> clusters in two DC's, and to amazon s3 as third. All this via s3 API. I love >>>>> to see native RGW geo-replication with described features in another thread. >>>>> >>>>> There is another case. What about RBD replication ?? It's much more >>>>> complicated, and for disaster recovery much more important, just like in >>>>> enterprise storage arrays. >>>>> One cluster in two DC's, not solving problem, because we need security >>>>> in data consistency, and isolation. >>>>> Do you thinking about this case ?? >>>>> >>>>> Regards >>>>> Slawomir Skowron-- >>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >>> >>> >>> -- >>> ----- >>> Pozdrawiam >>> >>> Sławek "sZiBis" Skowron >> >> >> >> -- >> ----- >> Pozdrawiam >> >> Sławek "sZiBis" Skowron >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
