On 11/08/2012 06:41 PM, Clayton Weise wrote:
Imho snapshots should be handled by a plugin. So on a Snapshots aware
SAN we should try to use the build in snapshots capabilities of that SAN
instead of doing it ourself.
This can considerably change the way storage is handled with XenServer and
iSCSI/FC since right now one SR is equivalent to a single LUN on your storage
array but that SR can contain many different volumes for VMs. In order to take
advantage of snapshots on the array you would need to create a separate SR for
each volume (somebody feel free to correct me if I'm wrong here) since the
array wouldn't know about the individual volumes/LVMs inside of the SR. With
NFS it's easier because it's all just files, but block storage is different and
can vary greatly in behavior from one HV to another.
Yes, I got the same feedback from David Nalley as well, we shouldn't try
to do that after thinking about it again :)
Wido
-----Original Message-----
From: Wido den Hollander [mailto:[email protected]]
Sent: Thursday, November 8, 2012 3:50 AM
To: [email protected]
Subject: Re: snapshot vs backup
On 07-11-12 18:13, Marcus Sorensen wrote:
I believe I saw this discussed once somewhere, but at the moment snapshots
are basically backups, correct? You'll have to forgive my ignorance if I
don't understand how it works on all platforms/storage types.
Edison brought this up with a storage refactor.
So moving forward are we renaming everything that's snapshot to backup
(since it works great for that as-is) and implementing a new snapshot, or
splitting the existing snapshot functionality into taking the actual
snapshot vs copying it to secondary storage (backup), or leaving snapshot
as-is and implementing some flag or something else that allows for both the
existing backup functionality as well as an instant cow style backup?
Imho snapshots should be handled by a plugin. So on a Snapshots aware
SAN we should try to use the build in snapshots capabilities of that SAN
instead of doing it ourself.
Same goes for RBD, QCOW2, etc, etc.
Backups should be different indeed, still handled differently for
different storage backends just to prevent we are working against the
storage backend while it could have awesome features for this.
In the end a backup should end up at the Secondary Storage.
Still, this is something that needs to go into the Storage Layer
refactor and we need to have this written down.
This thread covers a lot of it: "Requirements of Storage Orchestration"
from over a week ago.
Wido
