On Wed, 20 Feb 2013, S?awomir Skowron wrote: > 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. Have you read the thread from Jens last week, 'snapshot, clone and mount a VM-Image'? Would this type of capability capture you're requirements? sage > > 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 > > -- 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
