You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Star Guo <st...@ceph.me> on 2014/12/08 15:56:21 UTC

答复: 答复: Cloudstack and Disaster Recovery

I think if all the cloudstack network is behind a firewall ( a device setting DNAT+SNAT ) it may be easy to achieve the goal of DR.

Make all CS management (mysql) as a KVM instance which start with virsh, and backend btrfs, and make primary storage and secondary storage backend of other subvolume in btrfs.

And the DR site , you should prepare a physical host with brtfs, and the standby physical which install kvm agent (and the network) and set the configure file as same as the machine of 
production site (maybe fix the uuid in the cloud db of mysql) .

The last is backup firewall ( a device setting DNAT+SNAT ) configuration , while recovery the configuration to the same module device of the DR site ( RouterOS? ).

Then, the public IP of ISP, change the DANT IP and SNAT outbond IP ? Fix DNS?

Best Regards,
Star Guo

-----邮件原件-----
发件人: Nux! [mailto:nux@li.nux.ro] 
发送时间: 2014年12月8日 21:14
收件人: dev@cloudstack.apache.org
主题: Re: 答复: Cloudstack and Disaster Recovery

Thanks, but that is not my main problem. My difficulties are more like:

- how do I dump metadata for cloudstack KVM guests that are not running? virsh dumpxml will not work as the guests that are not running are not defined at all in libvirt (ie this will not list them: virsh list --all)

- how do I make sure the proper IPs and networks will be in place in the DR site? I'd need to recreate all the virtual networks and make sure there is a Virtual Router somehow working and still aware of IP assignments etc.

I know that ideally DR should be done at application levels, but it's not what the customers are asking. :-)

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Star Guo" <st...@ceph.me>
> To: dev@cloudstack.apache.org
> Sent: Monday, 8 December, 2014 12:51:13
> Subject: 答复: Cloudstack and Disaster Recovery

> Hi,
> 
> I think if you make nfs as primary storage backend on brtfs or zfs 
> (freenas?) you could take a snapshot and send all to DR site. Also, a 
> plan of increment snapshot.
> This may be good method.
> 
> Best Regards,
> Star Guo
> 
> 
> -----邮件原件-----
> 发件人: Nux! [mailto:nux@li.nux.ro]
> 发送时间: 2014年12月8日 20:34
> 收件人: dev@cloudstack.apache.org
> 主题: Cloudstack and Disaster Recovery
> 
> Hi,
> 
> I'm getting more and more requests from customers to have "mini clouds"
> installed, but also DR capability.
> This would be a great occasion to introduce them to Cloudstack, except 
> for the DR bit for which I have found no straightforward way of 
> performing. I'd have to replicate a whole lot of stuff to make it work.
> 
> Right now I'm stuck with setups of 3+ hypervisors running plain 
> libvirt/KVM because of this; DR is a no-brainer, I'm just dumping xml 
> metadata for VMs and rsync qcow2 files over SSH, making sure all the 
> storage and networks pools are in place.
> 
> Pointers?
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro


Re: 答复: 答复: Cloudstack and Disaster Recovery

Posted by Nux! <nu...@li.nux.ro>.
Yeah, that's what I meant by "not straighforward". :-)

I'll stick with my libvirt/KVM setups for now.

Cheers

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Star Guo" <st...@ceph.me>
> To: dev@cloudstack.apache.org
> Sent: Monday, 8 December, 2014 14:56:21
> Subject: 答复: 答复: Cloudstack and Disaster Recovery

> I think if all the cloudstack network is behind a firewall ( a device setting
> DNAT+SNAT ) it may be easy to achieve the goal of DR.
> 
> Make all CS management (mysql) as a KVM instance which start with virsh, and
> backend btrfs, and make primary storage and secondary storage backend of other
> subvolume in btrfs.
> 
> And the DR site , you should prepare a physical host with brtfs, and the standby
> physical which install kvm agent (and the network) and set the configure file
> as same as the machine of
> production site (maybe fix the uuid in the cloud db of mysql) .
> 
> The last is backup firewall ( a device setting DNAT+SNAT ) configuration , while
> recovery the configuration to the same module device of the DR site ( RouterOS?
> ).
> 
> Then, the public IP of ISP, change the DANT IP and SNAT outbond IP ? Fix DNS?
> 
> Best Regards,
> Star Guo
> 
> -----邮件原件-----
> 发件人: Nux! [mailto:nux@li.nux.ro]
> 发送时间: 2014年12月8日 21:14
> 收件人: dev@cloudstack.apache.org
> 主题: Re: 答复: Cloudstack and Disaster Recovery
> 
> Thanks, but that is not my main problem. My difficulties are more like:
> 
> - how do I dump metadata for cloudstack KVM guests that are not running? virsh
> dumpxml will not work as the guests that are not running are not defined at all
> in libvirt (ie this will not list them: virsh list --all)
> 
> - how do I make sure the proper IPs and networks will be in place in the DR
> site? I'd need to recreate all the virtual networks and make sure there is a
> Virtual Router somehow working and still aware of IP assignments etc.
> 
> I know that ideally DR should be done at application levels, but it's not what
> the customers are asking. :-)
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> ----- Original Message -----
>> From: "Star Guo" <st...@ceph.me>
>> To: dev@cloudstack.apache.org
>> Sent: Monday, 8 December, 2014 12:51:13
>> Subject: 答复: Cloudstack and Disaster Recovery
> 
>> Hi,
>> 
>> I think if you make nfs as primary storage backend on brtfs or zfs
>> (freenas?) you could take a snapshot and send all to DR site. Also, a
>> plan of increment snapshot.
>> This may be good method.
>> 
>> Best Regards,
>> Star Guo
>> 
>> 
>> -----邮件原件-----
>> 发件人: Nux! [mailto:nux@li.nux.ro]
>> 发送时间: 2014年12月8日 20:34
>> 收件人: dev@cloudstack.apache.org
>> 主题: Cloudstack and Disaster Recovery
>> 
>> Hi,
>> 
>> I'm getting more and more requests from customers to have "mini clouds"
>> installed, but also DR capability.
>> This would be a great occasion to introduce them to Cloudstack, except
>> for the DR bit for which I have found no straightforward way of
>> performing. I'd have to replicate a whole lot of stuff to make it work.
>> 
>> Right now I'm stuck with setups of 3+ hypervisors running plain
>> libvirt/KVM because of this; DR is a no-brainer, I'm just dumping xml
>> metadata for VMs and rsync qcow2 files over SSH, making sure all the
>> storage and networks pools are in place.
>> 
>> Pointers?
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
> > www.nux.ro