[Openstack-operators] [openstack][nova] Several questions/experiences about _base directory on a big production environment
joe at topjian.net
Thu Apr 3 17:10:13 UTC 2014
Please see the below reply from Rob. He's having issues posting to
On Thu, Apr 3, 2014 at 11:03 AM, Esker, Robert <Rob.Esker at netapp.com> wrote:
> Both deduplication and various cloning approaches on NetApp systems rely
> on similar (pointer based) block sharing techniques. In fact, you can in
> some ways think of cloning as immediate on demand block sharing and
> deduplication as asynchronous ex post facto block sharing. Compression is
> somewhat different but can be layered in w/ deduplication on the same pool
> of data. If you'd like to know more, this covers it in depth:
> Either way the fundamental underlying block is checksummed and parity
> protected. Perhaps SPoF in the sense that, yes, in the name of efficiency
> we're trying to remove all undesirable redundancy while employing a number
> of different measures to protect against individual component failure, but
> the SPoF ends up being the whole of the system when only one (albeit well
> protected) copy is stored. That's a physics problem. Ultimately to
> protect against site failure / network partition you'd want another
> physical copy elsewhere which is where our replication tech (SnapMirror)
> comes in... subsequent to baseline a thin, diffs only mechanism.
> BTW, all of these attributes can be explicitly selectable in the sense
> that we advertise their configuration state via Cinder Volume Type Extra
> Specs. They can be composed into a Cinder Volume Type that perhaps is
> comprised of 1) compression 2) deduplication 3) an associated SnapMirror
> replication policy.
> Also, on the topic of booting instances efficiently, we debuted a change
> in Havana that when booting from volume 1) clones from glance rather than
> copies where possible (and thus is nearly instantaneous and storage
> capacity efficient 2) provides a default persistent instance (that still
> can be treated as ephemeral if "delete upon terminate" is selected and 3)
> provides for live migration (since it's booted from shared storage) 4) if
> you choose allows you to boot your compute nodes stateless.
> More info in the NetApp OpenStack Deployment & Operations Guide here
> (see the :
> Robert Esker
> Sr. Product Manager - OpenStack
> NetApp, Inc.
> From: Joe Topjian <joe at topjian.net>
> Date: Thursday, April 3, 2014 at 9:27 AM
> To: Chris Friesen <chris.friesen at windriver.com>
> Cc: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [openstack][nova] Several
> questions/experiences about _base directory on a big production environment
> That's a great comment and I fully admit that my knowledge of NetApp
> internals becomes more foggy as time goes on, so I can't confidently
> answer. Anyone else?
> On Wed, Apr 2, 2014 at 10:24 PM, Chris Friesen <
> chris.friesen at windriver.com> wrote:
>> On 04/02/2014 09:28 PM, Joe Topjian wrote:
>> Diego has a great point about not using qemu backing files: if your
>>> backend storage implements deduplication and/or compression, you should
>>> see the same savings as what _base is trying to achieve.
>> Doesn't that still leave you vulnerable to a single point of failure if
>> your single deduped copy gets corrupted?
>> Or can the backend be configured to store multiple copies of each deduped
>> chunk for reliability?
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators