cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Mikhailovsky <and...@arhont.com>
Subject Re: CloudStack DR Approach (not HA)
Date Mon, 24 Mar 2014 20:58:52 GMT
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" <cloudfanatic007@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 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message