Open Stack

Please see the below reply from Rob. He's having issues posting to
-operators.


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:
>
>  http://www.netapp.com/us/media/tr-3958.pdf
>
>  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 :
>
>  https://communities.netapp.com/docs/DOC-31749
>
>  Cheers,
>
>  Robert Esker
> Sr. Product Manager - OpenStack
> NetApp, Inc.
> +14089307782
>
>  @openstacknetapp
>
>   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?
>>
>> Chris
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140403/a20fbad7/attachment.html>