You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Jim Jones <cl...@gmail.com> on 2014/03/24 20:11:10 UTC
CloudStack DR Approach (not HA)
Hello,
I am interested to know what everyone is using to provide disaster recovery
for VMs running in CloudStack?
Note, I am talking about true DR to another data center, not HA. I have
seen the previous thread where someone asked about DR, but the answer
provided only talked about HA of VMs within the same Cluster or Zone. This
is not my question.
I am looking for a method to maintain an up-to-date copy of a running VM,
including its data, in another Zone or Region, such that if the first Zone
is destroyed, the VM can be brought up in the other Zone and continue
production.
Before cloud, DR for virtualized environments was typically handled using
SAN replication. The VMs would be quiesced and snapshotted at regular
intervals (e.g. hourly), and the SAN LUNs would be continuously replicated
asynchronously. Following this approach, if the primary site was
destroyed, the SAN LUNs would be enabled for read-write at the secondary
location, and the VMs could then be started there, using the last
successful snapshot (the last consistency point).
I have looked at what Amazon and Rackspace provide for their Clouds, and
the approach seems to be user-initiated quiesced cloud snapshots, combined
with Secondary Storage that is automatically replicated and available
throughout their Clouds. Therefore, if the site where the VM is running
gets destroyed, the latest VM snapshot can be deployed from Secondary
Storage to any other Zone.
I would like to know if anybody has experience/insights using this approach
on CloudStack, particularly using XenServer hosts.
Is there a mechanism available for end-users to create quiesced CloudStack
snapshots of running production VMs, such that applications and filesystems
are put into a consistent state prior to the snapshot being created?
Also, can anybody offer insight into how to automatically or continuously
replicate Secondary Storage across Zones or Regions, using NFS-based
Secondary Storage (not object storage), such that CloudStack users will see
any be able to deploy their Snapshots in any other Zone or Region?
If what I am describing is not yet possible with CloudStack, I would be
like to be pointed towards the part of the CloudStack roadmap that
discusses the planned architecture.
Thanks,
JJ
Re: CloudStack DR Approach (not HA)
Posted by ilya musayev <il...@gmail.com>.
http://cloudstackcollabconference2014.sched.org/event/f2162b8cb2fcaf4c0290a862ad5524ca?iframe=no&w=100&sidebar=yes&bg=no#.UzEAQdzrX7I
> What about using iRODS (http://www.irods.org); with a custom
> Micro-Service. Conceptually; what does everyone think?
>
>
> Is there a mechanism available for end-users to create quiesced CloudStack
> snapshots of running production VMs, such that applications and filesystems
> are put into a consistent state prior to the snapshot being created?
>
> Also, can anybody offer insight into how to automatically or continuously
> replicate Secondary Storage across Zones or Regions, using NFS-based
> Secondary Storage (not object storage), such that CloudStack users will see
> any be able to deploy their Snapshots in any other Zone or Region?
>
> If what I am describing is not yet possible with CloudStack, I would be
> like to be pointed towards the part of the CloudStack roadmap that
> discusses the planned architecture.
>
>
>
>
> On Mon, Mar 24, 2014 at 3:11 PM, Jim Jones <cl...@gmail.com>wrote:
>
>> Hello,
>>
>> I am interested to know what everyone is using to provide disaster recovery
>> for VMs running in CloudStack?
>>
>> Note, I am talking about true DR to another data center, not HA. I have
>> seen the previous thread where someone asked about DR, but the answer
>> provided only talked about HA of VMs within the same Cluster or Zone. This
>> is not my question.
>>
>> I am looking for a method to maintain an up-to-date copy of a running VM,
>> including its data, in another Zone or Region, such that if the first Zone
>> is destroyed, the VM can be brought up in the other Zone and continue
>> production.
>>
>> Before cloud, DR for virtualized environments was typically handled using
>> SAN replication. The VMs would be quiesced and snapshotted at regular
>> intervals (e.g. hourly), and the SAN LUNs would be continuously replicated
>> asynchronously. Following this approach, if the primary site was
>> destroyed, the SAN LUNs would be enabled for read-write at the secondary
>> location, and the VMs could then be started there, using the last
>> successful snapshot (the last consistency point).
>>
>> I have looked at what Amazon and Rackspace provide for their Clouds, and
>> the approach seems to be user-initiated quiesced cloud snapshots, combined
>> with Secondary Storage that is automatically replicated and available
>> throughout their Clouds. Therefore, if the site where the VM is running
>> gets destroyed, the latest VM snapshot can be deployed from Secondary
>> Storage to any other Zone.
>>
>> I would like to know if anybody has experience/insights using this approach
>> on CloudStack, particularly using XenServer hosts.
>>
>> Is there a mechanism available for end-users to create quiesced CloudStack
>> snapshots of running production VMs, such that applications and filesystems
>> are put into a consistent state prior to the snapshot being created?
>>
>> Also, can anybody offer insight into how to automatically or continuously
>> replicate Secondary Storage across Zones or Regions, using NFS-based
>> Secondary Storage (not object storage), such that CloudStack users will see
>> any be able to deploy their Snapshots in any other Zone or Region?
>>
>> If what I am describing is not yet possible with CloudStack, I would be
>> like to be pointed towards the part of the CloudStack roadmap that
>> discusses the planned architecture.
>>
>> Thanks,
>> JJ
>>
Re: CloudStack DR Approach (not HA)
Posted by Matthew Kaufman <mk...@gmail.com>.
What about using iRODS (http://www.irods.org); with a custom
Micro-Service. Conceptually; what does everyone think?
Is there a mechanism available for end-users to create quiesced CloudStack
snapshots of running production VMs, such that applications and filesystems
are put into a consistent state prior to the snapshot being created?
Also, can anybody offer insight into how to automatically or continuously
replicate Secondary Storage across Zones or Regions, using NFS-based
Secondary Storage (not object storage), such that CloudStack users will see
any be able to deploy their Snapshots in any other Zone or Region?
If what I am describing is not yet possible with CloudStack, I would be
like to be pointed towards the part of the CloudStack roadmap that
discusses the planned architecture.
On Mon, Mar 24, 2014 at 3:11 PM, Jim Jones <cl...@gmail.com>wrote:
> Hello,
>
> I am interested to know what everyone is using to provide disaster recovery
> for VMs running in CloudStack?
>
> Note, I am talking about true DR to another data center, not HA. I have
> seen the previous thread where someone asked about DR, but the answer
> provided only talked about HA of VMs within the same Cluster or Zone. This
> is not my question.
>
> I am looking for a method to maintain an up-to-date copy of a running VM,
> including its data, in another Zone or Region, such that if the first Zone
> is destroyed, the VM can be brought up in the other Zone and continue
> production.
>
> Before cloud, DR for virtualized environments was typically handled using
> SAN replication. The VMs would be quiesced and snapshotted at regular
> intervals (e.g. hourly), and the SAN LUNs would be continuously replicated
> asynchronously. Following this approach, if the primary site was
> destroyed, the SAN LUNs would be enabled for read-write at the secondary
> location, and the VMs could then be started there, using the last
> successful snapshot (the last consistency point).
>
> I have looked at what Amazon and Rackspace provide for their Clouds, and
> the approach seems to be user-initiated quiesced cloud snapshots, combined
> with Secondary Storage that is automatically replicated and available
> throughout their Clouds. Therefore, if the site where the VM is running
> gets destroyed, the latest VM snapshot can be deployed from Secondary
> Storage to any other Zone.
>
> I would like to know if anybody has experience/insights using this approach
> on CloudStack, particularly using XenServer hosts.
>
> Is there a mechanism available for end-users to create quiesced CloudStack
> snapshots of running production VMs, such that applications and filesystems
> are put into a consistent state prior to the snapshot being created?
>
> Also, can anybody offer insight into how to automatically or continuously
> replicate Secondary Storage across Zones or Regions, using NFS-based
> Secondary Storage (not object storage), such that CloudStack users will see
> any be able to deploy their Snapshots in any other Zone or Region?
>
> If what I am describing is not yet possible with CloudStack, I would be
> like to be pointed towards the part of the CloudStack roadmap that
> discusses the planned architecture.
>
> Thanks,
> JJ
>
Re: CloudStack DR Approach (not HA)
Posted by Nux! <nu...@li.nux.ro>.
On 24.03.2014 19:11, Jim Jones wrote:
> Hello,
>
> I am interested to know what everyone is using to provide disaster
> recovery
> for VMs running in CloudStack?
Hello Jim,
I'm also interested in this subject.
Right now for some DR VMs I (am trying to) use Xenserver + HAlizard,
but this is just a 2 hypervisor setup.
If I had to do it now, my least cumbersome approach would probably be
to recommend setting up VMs in the DR zone and replicate stuff at
application level and do some load balancing.
I'm very curious what others do.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: CloudStack DR Approach (not HA)
Posted by Andrei Mikhailovsky <an...@arhont.com>.
Hi Jim,
I would suggest looking at Ceph for the multisite data replication, including primary and secondary storage. I doubt nfs would be of much use here unless you are a masochist )) Alternatively, you may look at using zfs with zfs send/receive feature to remote copy across filesystem snapshots. You may ran nfs over zfs if nfs is preferred.
As to the cloudstack, and I've not done any tests and just hypothesizing, you can have a vm in multiple regions/zones, which are pointing to the volume which you've synced across to a remote dc. If your primary zone/dc dies, you simply start the vm from another zone/region using the last snapshot state.
I would also suggest looking at scalr, which should automate things for you when it comes to switching between failed and live dcs. It's a fantastic looking product from the looks of it.
Andrei
----- Original Message -----
From: "Jim Jones" <cl...@gmail.com>
To: users@cloudstack.apache.org
Sent: Monday, 24 March, 2014 7:11:10 PM
Subject: CloudStack DR Approach (not HA)
Hello,
I am interested to know what everyone is using to provide disaster recovery
for VMs running in CloudStack?
Note, I am talking about true DR to another data center, not HA. I have
seen the previous thread where someone asked about DR, but the answer
provided only talked about HA of VMs within the same Cluster or Zone. This
is not my question.
I am looking for a method to maintain an up-to-date copy of a running VM,
including its data, in another Zone or Region, such that if the first Zone
is destroyed, the VM can be brought up in the other Zone and continue
production.
Before cloud, DR for virtualized environments was typically handled using
SAN replication. The VMs would be quiesced and snapshotted at regular
intervals (e.g. hourly), and the SAN LUNs would be continuously replicated
asynchronously. Following this approach, if the primary site was
destroyed, the SAN LUNs would be enabled for read-write at the secondary
location, and the VMs could then be started there, using the last
successful snapshot (the last consistency point).
I have looked at what Amazon and Rackspace provide for their Clouds, and
the approach seems to be user-initiated quiesced cloud snapshots, combined
with Secondary Storage that is automatically replicated and available
throughout their Clouds. Therefore, if the site where the VM is running
gets destroyed, the latest VM snapshot can be deployed from Secondary
Storage to any other Zone.
I would like to know if anybody has experience/insights using this approach
on CloudStack, particularly using XenServer hosts.
Is there a mechanism available for end-users to create quiesced CloudStack
snapshots of running production VMs, such that applications and filesystems
are put into a consistent state prior to the snapshot being created?
Also, can anybody offer insight into how to automatically or continuously
replicate Secondary Storage across Zones or Regions, using NFS-based
Secondary Storage (not object storage), such that CloudStack users will see
any be able to deploy their Snapshots in any other Zone or Region?
If what I am describing is not yet possible with CloudStack, I would be
like to be pointed towards the part of the CloudStack roadmap that
discusses the planned architecture.
Thanks,
JJ