Here's my general concern about multiple volume snapshots at once. Giving such a feature leads the user to believe that snapshotting multiple volumes at once will give them consistency across the volumes in the snapshot. This is not true, and difficult to do with many hypervisors, and typically requires an agent in the VM. A single snapshot, as exists today, is really crash consistent, meaning that there is may exist unsync'd data. To do a true multi volume snapshot requires a "quiesce" functionality in the VM. So you do pause I/O queues, fsync, fsync, snapshot, snapshot, unpause I/O.
I'm might be fine with the option of allowing multiple volumeId's to be specified in the snapshot API, but it needs to be clear that those snapshots may be taken sequentially and they are all independently crash consistent. But, if you make that clear, then why even have the API. Essentially it is the same as doing multiple snapshot API commands. So really I would lean towards having the multiple snapshotting supported in the driver or storage subsystem, but not exposed to the user. You can easy accomplish it by having a timed window on snapshotting. So every 10 seconds you do snapshots, if 5 requests have queued in the last 10 seconds, you do them all at once. This could be implemented as a framework thing. If your provider implements "SnapshotBatching" interface and that has a getBatchWindowTime(), then the framework can detect that it should try to queue up some snapshot requests and send them to the driver in a batch. Or that could be implemented in the driver itself. I would lean toward doing it in the driver and if that goes well, we look at pulling the functionality into core ACS. Darren On Wed, Sep 18, 2013 at 5:22 AM, SuichII, Christopher < [email protected]> wrote: > I would like to raise for discussion the idea of adding a couple methods > to the Storage Subsystem API interface. Currently, takeSnapshot() and > revertSnapshot() only support single VM volumes. We have a use case for > snapshotting multiple VM volumes at the same time. For us, it is more > efficient to snapshot them all at once rather than snapshot VM Volumes > individually and this seems like a more elegant solution than queueing the > requests within our plugin. > > Base on my investigation, this should require: > -Two additional API to be invoked from the UI > -Two additional methods added to the Storage Subsystem API interface > -Changes in between the API level and invoking the Storage Subsystem API > implementations (I know this is broad and vague), mainly around the > SnapshotManger/Impl > > There are a couple topics we would like discussion on: > -Would this be beneficial/detrimental/neutral to other storage providers? > -How should we handle the addition of new methods to the Storage Subsystem > API interface? Default them to throw an UnsupportedOperationException? > Default to calling the single VM volume version multiple times? > -Does anyone see any issues with allowing multiple snapshots to be taken > at the same time or letting storage providers have a list of all the > requested volumes to backup? > > Please let me know if I've missed any major topics for discussion or if > anything needs clarification. > > Thanks, > Chris > -- > Chris Suich > [email protected] > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > >
