On Wed, Nov 23, 2016 at 5:41 AM, Oscar Segarra <oscar.segarra@gmail.com> wrote:
Hi, 

As on oVirt is it possible to attach local storage I supose it can be used to run virtual machines:

I have drawn a couple of diagrams in order to know if is it possible to set up this configuration:

1.- In on-going scenario:
Every host runs 100 vdi virtual machines whose disks are placed on local storage. There is a common gluster volume shared between all nodes.

Imágenes integradas 1

With local storage you end up losing many of the benefits of shared storage - including migration and HA.
If you do have SSD on your physical hosts, have you considered building gluster volume using these? This could give you improved performance. Regarding performance, I think it is best that you run a test comparing gluster storage performance with local storage and see if this is acceptable to you. Please share the results in case you do.

In the above diagram each host is in its own cluster - as all hosts in a cluster should have access to the storage domain?

Is the gluster volume for backup served from a separate set of server?
 

2.- If one node fails:

Imágenes integradas 2

oVirt has to be able to inventory the copy of machines (in our example vdi201 ... vdi300) and start them on remaining nodes.

¿Is it possible to reach this configuration with oVirt? ¿or something similar?

This is the use case for gluster volume shared storage - where volume is a replica 3. If any host goes down, the data is available on the remaining 2 nodes, and the VMs can be migrated to other nodes.

I don't think what you ask for is possible automatically. If you want local storage to gluster volume backup, you would need 1-1 mapping. i.e each local storage domain has its own gluster volume backup.You could then import the storage domain that's backed up on the gluster volume and start the VMs on the remaining hosts.
 

Making backup with the import-export procedure based on snapshot can take lot of time and resources. Incremental rsync is cheaper in terms of resources.

Geo-replication based backup internally uses rsync, it also takes into account that VM images are consistent on disk before being synced. It however works as a backup option between two gluster volumes.
 

Thanks lot.


2016-11-22 10:49 GMT+01:00 Yaniv Dary <ydary@redhat.com>:
I suggest you setup that environment and test for the performance and report if you have issues. 
Please note that currently there is no data locality guarantee, so a VM might be running on a host that doesn't have its disks.

We have APIs to do backup\restore and that is the only supported option for backup:
You can look at the Gluster DR option that was posted a while back, you can look that up.
It used geo replication and import storage domain to do the DR.
     

Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
        8272306
Email: ydary@redhat.com
IRC : ydary

On Mon, Nov 21, 2016 at 5:17 PM, Oscar Segarra <oscar.segarra@gmail.com> wrote:
Hi, 

I'm planning to deploy a scalable VDI infraestructure where each phisical host can run over 100 VDIs and I'd like to deploy 10 physical hosts (1000 VDIs).

In order to avoid performance problems (replicating 1000VDIs changes over gluster network I think can provoque performance problems) I have thought to use local storage for VDI assuming that VDIs cannot be migrated between phisical hosts.

¿Is my worry founded in terms of performance?
¿Is it possible to utilize local SSD storage for VDIs?

I'd like to configure a gluster volume for backup on rotational disks (tiered+replica 2+ stripe=2) just to provide HA if a physical host fails.

¿Is it possible to use rsync for backing up VDIs?
If not ¿How can I sync/backup  the VDIs running on local storage on the gluster shared storage?
If a physical host fails ¿How can I start the latest backup of the VDI on the shared gluster?

Thanks a lot

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users