Technical Report NetApp Mirantis Unlocked Reference ... Report NetApp Mirantis Unlocked Reference...

Technical Report

NetApp Mirantis Unlocked Reference Architecture Akshai Parthasarathy, NetApp, Christian Huebner, Dmitry Ukov & Oleksandr Vorobiov, Mirantis

December 2015 | TR-4478

Abstract

This reference architecture was prepared jointly by Mirantis Unlocked and NetApp. The report

details architectural considerations, best practices, and deployment methodologies to create a

highly available Mirantis OpenStack 7.0 (Kilo-based) cloud using NetApp® storage. The

architectural design described has been verified by Mirantis and NetApp and can be deployed

using the Mirantis 7.0 Fuel plug-in.

2 NetApp Mirantis Unlocked Reference Architecture ® 2015 NetApp, Inc. All Rights Reserved.

TABLE OF CONTENTS

1 Introduction ........................................................................................................................................... 4

1.1 OpenStack, Mirantis, and NetApp ...................................................................................................................4

1.2 About This Reference Architecture .................................................................................................................5

1.3 Target Audience ..............................................................................................................................................5

2 OpenStack Services ............................................................................................................................. 5

2.1 Compute Service (Nova) .................................................................................................................................5

2.2 Block Storage Service (Cinder) .......................................................................................................................6

2.3 Object Storage Service (Swift) ........................................................................................................................6

2.4 File Share Service (Manila) .............................................................................................................................6

2.5 Image Service (Glance) ..................................................................................................................................6

2.6 Network Service (Neutron) ..............................................................................................................................7

2.7 Other OpenStack Services..............................................................................................................................7

3 Storage in OpenStack .......................................................................................................................... 7

3.1 Storage Types in OpenStack ..........................................................................................................................7

3.2 NetApp Storage ..............................................................................................................................................8

4 Reference Architectures .................................................................................................................... 10

4.1 Clustered Data ONTAP (NetApp FAS Storage) ............................................................................................ 10

4.2 SANtricity (NetApp E-Series Storage) ........................................................................................................... 14

5 Best Practices ..................................................................................................................................... 16

5.1 Mirantis OpenStack Best Practices ............................................................................................................... 16

5.2 Networking Best Practices ............................................................................................................................ 16

5.3 Storage and Database Best Practices .......................................................................................................... 17

6 Implementation ................................................................................................................................... 19

6.1 Mirantis OpenStack Plug-In .......................................................................................................................... 19

6.2 Predeployment Considerations ..................................................................................................................... 19

6.3 Deployment Workflow ................................................................................................................................... 19

7 Verification and Testing ..................................................................................................................... 29

7.1 Functional Testing ......................................................................................................................................... 29

7.2 System Testing ............................................................................................................................................. 30

7.3 Performing Functional Testing ...................................................................................................................... 30

8 Support ................................................................................................................................................ 31

9 Conclusion .......................................................................................................................................... 31


Appendix: Software and Documentation ............................................................................................... 31

LIST OF FIGURES

Figure 1) OpenStack architecture. ..................................................................................................................................5

Figure 2) OpenStack and NetApp FAS network architecture. ...................................................................................... 11

Figure 3) Control flow (black) and data flow (red) between participants. ...................................................................... 12

Figure 4) OpenStack and NetApp E-Series architecture. ............................................................................................. 14

Figure 5) Control flow (black) and data flow (red) between participants. ...................................................................... 15

Figure 6) Fuel boot. ...................................................................................................................................................... 20

Figure 7) Fuel configuration screen. ............................................................................................................................. 21

Figure 8) Fuel web UI log-in page. ............................................................................................................................... 22

Figure 9) Fuel plug-in installation. ................................................................................................................................ 23

Figure 10) OpenStack environment creation. ............................................................................................................... 23

Figure 11) Fuel UI summary. ........................................................................................................................................ 24

Figure 12) Assign roles in Fuel UI. ............................................................................................................................... 25

Figure 13) General network configuration. ................................................................................................................... 26

Figure 14) Nodes network configuration. ...................................................................................................................... 27

Figure 15) Enable and configure NetApp plug-in. ......................................................................................................... 28

Figure 16) Deploy changes. ......................................................................................................................................... 29


1 Introduction

Cloud computing has transformed the IT landscape and ushered in an era of infrastructure as a service

(IaaS). Applications running within a cloud infrastructure can take advantage of its flexibility, cost

effectiveness, disaster-recovery options, and security. OpenStack is the leading free and open-source

cloud computing IaaS platform and offers a rich set of features beyond traditional compute, storage, and

networking.

This reference architecture was prepared jointly by Mirantis Unlocked and NetApp. The report details

architectural considerations, best practices, and deployment methodologies to create a highly available

Mirantis OpenStack 7.0 (Kilo-based) cloud using NetApp storage. The architectural design described in

this technical report has been verified by Mirantis and NetApp and can be deployed using the Mirantis 7.0

Fuel plug-in.

1.1 OpenStack, Mirantis, and NetApp

About OpenStack

OpenStack is an open-source project that is released under the Apache 2.0 license and implements

services that establish IaaS with additional platform-as-a-service components. The project is managed by

the OpenStack Foundation, a nonprofit corporate entity established in 2012 to promote, protect, and

empower OpenStack software and its associated community. OpenStack technology consists of a series

of modular projects that control large pools of processing, storage, and networking resources throughout

a data center. All of these resources are managed through a single dashboard that gives administrators

control and empowers users with self-service resource provisioning.

Why OpenStack?

OpenStack provides tools that enable IT organizations and service providers to apply flexible, cost-

effective, enterprise-ready IaaS. Contributions made by NetApp, Mirantis, and others can be deployed

with existing hardware in your data center or proof-of-concept labs. In most cases, drivers for specific

infrastructure solutions are provided open source and free of cost. OpenStack use cases include public

cloud providers, private cloud deployments, and hybrid clouds. For more information on OpenStack

benefits and enterprise use cases, go to http://www.openstack.org/enterprise.

About Mirantis

Mirantis is the pure-play OpenStack company. Mirantis delivers all the software, services, training, and

support needed for running OpenStack. More customers rely on Mirantis than any other company to get

to production deployment of OpenStack at scale. Mirantis is among the top three companies worldwide in

contributing open source software to OpenStack, and has helped build and deploy some of the largest

OpenStack clouds in the world at companies such as Cisco, Comcast, Ericsson, NASA, Samsung, and

Symantec. Mirantis is venture-backed by August Capital, Ericsson, Intel Capital, Insight Venture Partners,

Sapphire Ventures and WestSummit Capital, with headquarters in Mountain View, California. Follow us

on Twitter at @mirantisit.

About NetApp

Deployment-proven NetApp storage solutions include data management features to accommodate fully

supportable workloads. NetApp first contributed code to OpenStack in 2011 and joined the OpenStack

Foundation as a charter member in August 2012. As a Gold Member, NetApp is pleased to take an active

leadership role in the OpenStack community. Find more information about OpenStack@NetApp at

http://netapp.github.io.

http://www.openstack.org/enterprise

https://twitter.com/MirantisIT?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor

http://netapp.github.io/


1.2 About This Reference Architecture

Enterprises are looking for a single solution that can meet the requirements of all their workloads, rather

than piecing together separate solutions. OpenStack has steadily gained features and deployment tools

that enable high availability at the control plane, hypervisor, and storage tiers.

This reference architecture focuses on the architectural considerations and deployment methodologies for

a highly available Mirantis OpenStack 7.0 (MOS 7.0) cloud with NetApp storage. The architecture also

covers the use of MOS 7.0 Fuel plug-ins. The reference architecture described in this document is based

on the NetApp technical report “Highly Available OpenStack Deployments Built on NetApp Storage

Systems | TR-4323,” the Mirantis OpenStack Operations Guide, and the Mirantis OpenStack User Guide.

1.3 Target Audience

The target audience for this document includes the following groups:

Technical decision makers. This document describes the value of using NetApp storage solutions with OpenStack cloud services to create a cloud environment that enterprises and service providers can use to meet their respective needs.

Enterprise and service-provider cloud architects. NetApp storage provides an enterprise-class underpinning for OpenStack-based clouds. This document describes architecture, best practices, and key design considerations for deploying OpenStack in a highly available manner.

OpenStack community members and NetApp partners and implementers. It is important for the OpenStack community and NetApp partners to understand the solution architecture of MOS 7.0 on NetApp storage to meet and exceed customer requirements and expectations for their cloud solutions.

2 OpenStack Services

OpenStack is a cloud operating system that controls pools of compute, storage, and networking.

OpenStack consists of a number of different services, some of which are shown in Figure 1.

Figure 1) OpenStack architecture.

2.1 Compute Service (Nova)

The Nova compute service manages the instance lifecycle from creation to scheduling to management

and eventually to deletion. Nova manages compute resources and provides a common REST API that

developers can use to automate cloud operations and provide external orchestration. Administrators also

use the API to control and manage compute resources and instances. Nova is designed to scale

horizontally on standard hardware.

http://www.netapp.com/us/media/tr-4323-design.pdf


https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#operations-guide

https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#user-guide


2.2 Block Storage Service (Cinder)

Cinder block-storage service provides persistent block devices mapped to OpenStack compute instances

(which use ephemeral storage by default). Cinder manages the creation, attachment, and detachment of

the block devices to instances. Persistent block devices provided by Cinder also support instance booting

and provide mechanisms for creating Cinder snapshots.

Cinder is built as a pluggable architecture, which allows using a wide range of storage back ends ranging

from a simplistic Linux LVM setup to enterprise-class block and file storage, such as that from NetApp.

Regardless of the back end, Cinder provides a standard subset of functionality to Nova and the

hypervisors. Some back ends, including those from NetApp, provide additional functionality for a variety

of purposes. Although fully integrated with Nova and Horizon, Cinder can also be used independently

from OpenStack to provide a standardized abstraction for block storage provisioning.

2.3 Object Storage Service (Swift)

Swift object storage service provides a fully distributed, scale-out, API-accessible storage platform that

provides HTTP-based object storage to applications and OpenStack services. The service can also be

used for backups, archiving, and data retention. Object storage does not present a traditional file system,

but rather a distributed storage system for static data such as VM images, photo storage, e-mail storage,

backups, and archives. NetApp storage, especially E-Series storage systems, can provide tremendous

value for Swift.

The Swift API, in a manner similar to that of the Cloud Data Management Interface (CDMI), proposes an

open standard for cloud storage. The API can also function as an alternative endpoint for Amazon Web

Services (AWS) Simple Storage Service and as a CDMI server through the use of add-on components.

2.4 File Share Service (Manila)

Manila file share service provides management of shared or distributed file systems such as Network File

System (NFS) and Common Internet File System (CIFS). Manila provisions and coordinates access to

persistent file-based storage for use by Nova instances or other external requestors. NetApp storage can

be configured as a back end for Manila and provides enterprise-class features.

Like many other OpenStack services, Manila has a pluggable provider architecture that facilitates the

creation and management of shared file systems. Manila also has a pluggable network integration model

that supports all of the major OpenStack networking services. Manila became a formally incubated

OpenStack project during the Juno release cycle and is generally regarded as available for production

use in the Kilo release.

2.5 Image Service (Glance)

Glance image service provides registration and delivery services for disk and server images. The

capability to copy a server image and immediately store it away is a powerful feature of OpenStack.

When multiple servers are being provisioned, a stored image can be used as a template to get new

servers up and running more quickly and consistently than by installing a server OS and individually

configuring additional services. You can also use Glance to store and catalog an arbitrary number of

backups. Using NetApp storage as a back end for Glance image repositories, customers can lower their

data center footprint and take advantage of advanced storage efficiency options.

Glance can store disk and server images in a variety of back ends, including NFS and Object Storage.

The Glance API provides a standard Representational State Transfer (REST) interface for querying

information about disk images and enables clients to download the images to serve as the basis for new

instances. The Glance multiformat image registry enables uploading private and public images in a

variety of popular formats.


2.6 Network Service (Neutron)

Neutron network service is a pluggable, scalable, and API-driven system for managing networks and IP

addresses. As with other aspects of the cloud OS, administrators and users can use this service to

increase the value of existing data center assets. Neutron prevents the network from becoming a

bottleneck or limiting factor in a cloud deployment and provides users with self-service capability for their

network configurations.

2.7 Other OpenStack Services

Dashboard (Horizon)

The Horizon dashboard offers administrators and users a graphical interface to access, provision, and

automate cloud-based resources.

Identity Service (Keystone)

The Keystone identity service provides a central directory of users mapped to the OpenStack services

they can access. This service acts as a common authentication system across the cloud operating

system. The service can integrate with existing back-end directory services such as Microsoft Active

Directory and Lightweight Directory Access Protocol.

Telemetry Service (Ceilometer)

The Ceilometer telemetry service provides a common infrastructure for collecting usage and performance

measurements in an OpenStack cloud. This service’s primary initial targets are monitoring and metering.

Orchestration Service (Heat)

Heat implements an orchestration service to orchestrate multiple composite cloud applications. Heat does

this by using the AWS CloudFormation template format through an OpenStack-native and

CloudFormation-compatible API.

3 Storage in OpenStack

OpenStack instances can be configured to use various forms of back-end storage, ranging from a simple

LVM on compute–node approach to an enterprise-class storage infrastructure. This reference

architecture focuses on NetApp FAS and E-Series enterprise-class storage.

3.1 Storage Types in OpenStack

Ephemeral Storage

Controlled by Nova, ephemeral storage can be used to boot instances on a compute node. Because

ephemeral storage is not persistent beyond the instance’s lifecycle, it cannot be used to store any kind of

persistent data. It is also not shared between compute nodes, so a migration of an instance to another

node cannot be performed on it.

Block Storage

Cinder provides persistent, shared block storage to an instance. It survives when the instance is

destroyed and can be attached to a new instance. Because the storage resource is shared, the

replacement instance can be on an arbitrary compute node.


Object Storage

Object storage provides read and write access to objects using HTTP. Objects are static and not stored in

a traditional file system.

File Storage

The Manila project has taken on the task of managing file system–based storage (NFS, CIFS, HDFS) in

an OpenStack context. Manila graduated as a core service in the OpenStack Kilo release (May 2015).

Image Storage

The Glance component of OpenStack provides an image-storage subsystem to the cloud. Independent of

Cinder, Glance facilitates both instances, booting images over the network and snapshot creation and

consumption. Like Cinder, Glance works with multiple back ends, among them NetApp FAS and E-Series

storage systems.

3.2 NetApp Storage

The demands of a data-driven business require a fundamentally new approach to storage with an

integrated combination of high-performance hardware and adaptive, scalable storage software. The

storage solution needs to support existing workloads as well as adapt and scale quickly to address new

applications and evolving IT models.

NetApp Storage Value for OpenStack

With the advantage of the NetApp® clustered Data ONTAP

® operating system, an OpenStack deployment

can scale on demand without losing flexibility, security, performance, or manageability. VMs can be

deployed in a highly accelerated manner from the storage array. Applications can operate within secure

tenants that span the entire hardware, network, and storage stack. Major components of the storage

infrastructure can be replaced or upgraded nondisruptively. NetApp clustered Data ONTAP OpenStack

integrations expose unique and differentiated capabilities:

Cinder with NetApp FlexClone® technology. You can leverage NetApp FlexClone technology to

create fast and efficient Cinder volume snapshots, as well as use it when Cinder snapshots serve as the source content for new Cinder volumes.

Glance and deduplication. You can leverage the deduplication technology of clustered Data ONTAP for NetApp FlexVol

® volumes that provide storage for Glance because this creates a storage-

efficient Glance image store.

Nova and enhanced instance creation. NetApp FlexClone technology enables the instant provisioning of new Cinder volumes that serve as the persistent root disk for VMs This capability is used rather than the default behavior of redownloading images from Glance for each new VM provisioned.

Protocol options. Through the unified architecture of Data ONTAP, any version of NFS (NFSv3, v4.0, v4.1, or pNFS), iSCSI, or Fibre Channel protocols can be leveraged in OpenStack deployments. This capability removes the need to deploy multiple storage products in order to address different protocol requirements.

Scalability. NetApp clustered Data ONTAP enables cloud administrators to move NetApp FlexVol volumes between nodes of a cluster to balance, distribute, and improve cloud infrastructure performance without interrupting service.

Data protection. The nondisruptive operational capabilities of clustered Data ONTAP help storage operations succeed without loss of service in the event of lost disks.


The E-Series Dynamic Disk Pools (DDPs) feature helps reduce the storage footprint and enhance

protection and scalability. This benefit helps to reduce network traffic for replicas of Swift objects because

of E-Series storage efficiencies.

DDPs provide an alternative to standard RAID groups. DDPs simplify protection by removing the

complexity of configuring RAID groups and allocating hot spares. Utilization is improved by dynamically

spreading data, parity, and spare capacity across all drives in a pool, reducing performance bottlenecks

caused by hot spots. In addition, if a drive failure occurs, DDPs enable return to an optimal state

significantly faster than RAID 6 while reducing the performance impact during the reconstruction of a

failed drive. DDPs also offer protection from multiple drive failures by prioritizing the reconstruction of the

most critical segments.

NetApp Clustered Data ONTAP

Clustered Data ONTAP is an enterprise-capable, unified, scale-out storage operating system. It is the

basis for virtualized shared storage infrastructures. Clustered Data ONTAP is architected for

nondisruptive operations, storage and operational efficiency, and scalability over the lifetime of the

system. A Data ONTAP cluster typically consists of fabric-attached storage (FAS) controllers: computers

optimized to run the clustered Data ONTAP operating system. Clustered Data ONTAP uses the NetApp

WAFL® (Write Anywhere File Layout) system, which delivers storage and operational efficiency

technologies. These technologies include fast, storage-efficient NetApp Snapshot® copies; thin

provisioning; volume, LUN, and file cloning; deduplication; and compression. The same efficiency

features are available regardless of the underlying media type.

Only a Data Fabric enabled by NetApp and clustered Data ONTAP can provide the flexibility and

scalability needed while managing cost. The powerful data management capabilities of clustered Data

ONTAP enable you to monetize value, speed time to revenue, and easily create custom OpenStack

solutions. And by leveraging an open-cloud model, you can easily expand customer acquisition

opportunities and meet a broader range of customer needs.

NetApp FAS Storage

NetApp FAS2500 hybrid storage arrays are built to deliver robust capabilities so that you don’t need to

buy additional equipment as IT needs change. Every FAS2500 includes unified support for NAS and SAN

workloads and can be configured as a hybrid or all-flash system to meet specific price and performance

goals.

FAS8000 enterprise storage systems are engineered specifically to address performance and scalability.

Powered by NetApp Data ONTAP and optimized for scale-out, the FAS8000 series unifies your SAN and

NAS storage infrastructure. With proven data management capabilities, the FAS8000 has the flexibility to

keep up with changing business needs while delivering on core IT requirements.

All FAS storage systems run the NetApp clustered Data ONTAP operating system.

NetApp SANtricity The NetApp SANtricity

® operating system delivers superior performance, reliability, and data protection

for your application-driven workloads and is deployed on E-Series storage arrays. SANtricity is purpose-built for SAN and performance-optimized to deliver data to enterprise SAN applications of all kinds, including OpenStack. Administrators can optimize performance on the fly, using its adaptive caching algorithms to achieve high IOPS and throughput. Installed on close to a million systems worldwide, the SANtricity OS has proven its robust operation and its ability to deliver the highest data integrity.

NetApp E-Series Storage

Today, the challenge for small and medium-sized businesses and remote and branch offices is to

manage growing data requirements with minimal cost and maintenance. The NetApp E2700 storage

system was designed as an entry-level storage system. It meets business requirements by providing


reliable storage. Pay-as-you-grow flexibility makes the E2700 the ideal solution for companies of all sizes

facing rapid, unpredictable growth.

For larger businesses, operations depend on mission-critical SAN applications that must have greater

than 99.999% availability. The E5600 series delivers consistent application performance and continuous

availability to achieve business goals. E5600 storage meets performance and capacity demands without

sacrificing simplicity and efficiency. The E5600 was designed with the SANtricity OS adaptive caching

algorithms, which address a large range of application workloads. Those workloads range from database,

high IOPS, and bandwidth-intensive streaming applications to a mixture of workloads in a high-

performance storage consolidation point.

All E-Series storage systems run the NetApp SANtricity operating system.

4 Reference Architectures

As you read this section, keep the following points in mind:

The clustered Data ONTAP architecture in section 4.1 uses NFS for storage infrastructure access with the NetApp unified driver.

Note: Clustered Data ONTAP can also use iSCSI and Fibre Channel, but NFS is prioritized in this revision. NFS and iSCSI installation are supported using Fuel.

The E-Series and SANtricity reference architecture in section 4.2 uses iSCSI for storage infrastructure access with the NetApp unified driver.

Note: E-Series can use iSCSI and Fibre Channel. iSCSI installation is supported using Fuel.

4.1 Clustered Data ONTAP (NetApp FAS Storage)

Overview

For the initial version of the Mirantis OpenStack with NetApp reference architecture, automatic

deployment of the following configuration has been selected.

Mirantis OpenStack 7.0

Clustered Data ONTAP FAS or E-Series storage

Cinder NFS driver for clustered Data ONTAP and Cinder iSCSI driver for E-Series


Figure 2) OpenStack and NetApp FAS network architecture.

The OpenStack cloud is deployed with Mirantis OpenStack according to the Mirantis OpenStack 7.0

Reference Architecture. As shown above, NetApp clustered Data ONTAP devices are attached to the

management and storage networks to provide access by Cinder on the controllers and the compute

nodes. NetApp devices should be connected according to NetApp best practices from Highly Available

OpenStack Deployments Built on NetApp Storage Systems.

Service Connectivity

The NetApp reference architecture supports Cinder in active-active HA mode. A diagram of the

communication among Nova, Cinder, the instance, the hypervisor, and the storage controller(s) is

displayed in Figure 3.

https://docs.mirantis.com/openstack/fuel/fuel-6.1/reference-architecture.html





Figure 3) Control flow (black) and data flow (red) between participants.

FlexVol Volumes and Cinder Volumes

FlexVol volumes on NetApp clustered Data ONTAP storage systems are general storage containers (also

known as a Cinder back ends). FlexVol volumes can contain multiple Cinder volumes. With a NetApp

NFS Cinder back end, Cinder volumes are represented as files in a NFS-exported FlexVol volume.

/<mountpoint>/flexvol1/cindervol1-file

/cindervol2-file

/cindervol3-file

/<mountpoint>/flexvol2/cindervol4-file

/cindervol5-file

...

In the representation above, FlexVol volumes and Cinder volumes are represented by their UUIDs.

Therefore, a typical path for a Cinder volume is similar to this:

/var/lib/cinder/mnt/952680affd03e543248ceb228080f9f2/volume-0ab17a00-3ec5-

43e3-baf0-2bd648feac21

Where:

/var/lib/cinder/mnt/952680affd03e543248ceb228080f9f2/ is the mount point for a

NetApp FlexVol volume, and

volume-0ab17a00-3ec5-43e3-baf0-2bd648feac21 is the Cinder volume file

Both NetApp FlexVol volumes and Cinder volumes can be extended as your storage requirements

increase. FlexVol volumes can also be shrunk, thereby allowing storage to be reallocated in other FlexVol

volumes.

Image Storage

Clustered Data ONTAP can be used as a file-store back end to Glance. An NFS export is created from a

FlexVol volume and presented to the Glance services as a mounted NFS.

Note: NetApp recommends enabling deduplication and compression for the FlexVol volume containing the Glance images because there is a high probability of having duplicate blocks in the repository. Doing so can save 80% or more in storage capacity.

Storage Considerations

The following considerations and guidelines were taken from the NetApp technical report Highly Available

OpenStack Deployments Built on NetApp Storage Systems | TR-4323.




The maximum number of files in a single FlexVol volume exported through NFS depends on the size of the FlexVol volume; a 1TB FlexVol volume can have 33,554,432 files (assuming 32,000 inodes). The theoretical maximum number of files is roughly 2 billion.

NFS drivers require support from the hypervisor to virtualize files and present them as block devices to an instance.

Since the Icehouse release of OpenStack, the use of parallel NFS (pNFS) is supported with the NetApp unified driver, providing enhanced performance and scalability characteristics.

There is no difference in the maximum size of a Cinder volume, regardless of the storage protocol chosen (either a file on NFS or an iSCSI LUN is 16TB).

Performance differences between iSCSI and NFS are normally negligible in virtualized environments. For a detailed investigation, see NetApp technical report VMware vSphere and ESX 3.5 Multiprotocol Performance Comparison Using FC, iSCSI, and NFS | TR-3808.

Snapshots

Cinder snapshots are created through FlexClone technology using a copy-on-write approach to snapshot

creation. Only blocks that were changed since snapshot creation are rewritten and referenced in the new

snapshot. The high performance of the NetApp Snapshot copy makes it highly scalable. A NetApp

Snapshot copy takes only a few seconds to create, typically less than one second regardless of the size

of the volume or the level of activity on the NetApp storage system.

In OpenStack, you can create a Cinder snapshot by issuing the following command:

$ cinder snapshot-create volume-0ab17a00-3ec5-43e3-baf0-2bd648feac21

Where:

volume-0ab17a00-3ec5-43e3-baf0-2bd648feac21 is a Cinder volume

You can then use the snapshot to create a new Cinder volume using the cinder create command:

$ cinder create --snapshot-id 37475d45-251e-478e-91ed-69baca037a77 3

Where:

37475d45-251e-478e-91ed-69baca037a77 is the UUID of the snapshot and

3 is the size of the Cinder volume to be created from the snapshot

Storage Service Catalog

The Storage Service Catalog (SSC) concept describes a set of capabilities. These capabilities enable

efficient, repeated, and consistent use and management of storage resources by defining policy-based

services and mapping those services to the back-end storage technology. Prominent features that are

used in the NetApp SSC include mirroring (NetApp SnapMirror® technology), deduplication, compression,

and thin provisioning.

To make use of the SSC, the appropriate extra spec(s) must first be mapped to a volume type. Cinder

volumes can then be created with the volume-type attribute specified. For example, assuming that the

gold volume type is mapped to the extra spec of netapp_mirrored, then

$ cinder create --volume-type gold 1 creates a 1GB Cinder volume that is mirrored on the

clustered Data ONTAP back end using SnapMirror technology. For further details on Cinder extra specs

and the SSC, refer to the OpenStack Deployment and Operations Guide from NetApp.

http://www.netapp.com/us/media/tr-3808.pdf


http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/index.html


4.2 SANtricity (NetApp E-Series Storage)

Overview

The NetApp E-Series driver for Cinder was introduced in the Icehouse release of OpenStack as a new

storage family supported within the NetApp unified driver framework. The E-Series driver provides

OpenStack with access to NetApp E-Series controllers for provisioning and maintaining OpenStack block

storage volumes that use the iSCSI protocol.

Architecture

NetApp E-Series storage systems provide internal HA redundancy and therefore can be used as

standalone solutions in environments in which clustered Data ONTAP enterprise-class storage is

prohibitively expensive or operationally inconvenient. Multiple E-Series storage systems can be used to

provide storage resources to Cinder. Figure 4 shows the OpenStack with E-Series and SANtricity

architecture.

Figure 4) OpenStack and NetApp E-Series architecture.

Service Connectivity

The NetApp reference architecture supports Cinder in active-active HA mode. A diagram of the

communication among Nova, Cinder, the instance, the hypervisor, and the SANtricity storage controller is

displayed in Figure 5.


Figure 5) Control flow (black) and data flow (red) between participants.

Note: NetApp E-Series storage systems are deployed individually, whereas FAS storage systems are usually deployed in cluster form. To provide high availability, E-Series storage systems must be deployed in HA pairs.

The NetApp SANtricity Web Services Proxy provides a REST API that allows Cinder to create assets on the E-Series or EF-Series device. The proxy translates the HTTP REST API to the SANtricity SYMbol API.

SANtricity requires a Web Services Proxy in intermediate mode.

The Web Services Proxy can be installed on either Linux or Windows.

Image Storage

Glance can store its image repository on E-Series and EF-Series storage systems. The image-store back

end is located on a volume on the E-Series storage device and mapped to the Glance host. The back end

must be formatted with the desired file system and mounted on the Glance host.

Note: Because one iSCSI LUN can be mounted on one storage node, redundancy and SLAs can be affected. For failover of the Glance subsystem, a resource manager is required that manages unmounting and mounting of the Glance file system. Mirantis OpenStack uses the Pacemaker resource manager. In addition, the use of NetApp RAID DP

® technology on E-Series storage

systems provides redundancy for your Glance image repository disks.

Storage Considerations

The following considerations and guidelines were taken from the NetApp technical report Highly Available

OpenStack Deployments Built on NetApp Storage Systems | TR-4323:

The SANtricity Web Services Proxy in intermediate mode is required.

The proxy can be deployed in active-passive topology.

Manual replication of arraydata.xml between instances of the proxy is necessary if the failover is

to be undetected by Cinder. If arraydata.xml is out of sync, the cinder-volume process must be

restarted to allow Cinder to resume servicing volume requests.




5 Best Practices

5.1 Mirantis OpenStack Best Practices

Implement the following Mirantis OpenStack best practices:

Planning is important for successful deployment. The Mirantis OpenStack and Fuel Planning Guide is a recommended resource for the planning phase.

Provide the following set of hardware:

One MOS server is required for all MOS deployments.

Three controllers are required for HA.

Supply an adequate number of compute nodes for the projected workload.

Mirantis recommends redundant power and networking.

If possible, nodes should be equipped with:

Four 10GbE interfaces for LACP and separation of storage and general networking

One GbE interface for the admin/PXE network

A larger number of cloud nodes is preferable to cutting-edge CPUs and large amounts of memory in a small number of nodes. Providing a larger number of nodes improves both performance and resilience to node failure while usually reducing cost. (Scale-out architecture is preferred to scale-up architecture.)

Although Mirantis OpenStack provides network verification, Mirantis highly recommends double-checking IP ranges for a smooth deployment. IP ranges cannot be changed later without redeployment.

Mirantis recommends adhering closely to the Mirantis OpenStack Reference Architecture for general MOS configuration and deployment. Deviations from the reference architecture are feasible and in some cases required, but they add complexity and require additional testing and operational procedures to support them.

Changes after Fuel deployment should be kept to a minimum. If a major change is necessary, consider development of a Fuel plug-in to provide repeatability of the deployment and reduce the risk of human error.

For further details on these and other best practices, refer to the Mirantis OpenStack 7.0 documentation

site.

5.2 Networking Best Practices

Implement the following networking best practices:

For proper network redundancy in an OpenStack deployment, it is extremely important to have at least two physical Ethernet switches. It is also important to have two or more converged network adapters or NICs per host and two or more NICs per storage controller. The network layout for the environment should be carefully planned, and detailed visual diagrams that display the connections for each port should be developed.

NetApp strongly recommends that anyone deploying OpenStack thoroughly review the OpenStack Security Guide to understand and implement the community-authored security best practices.

The NetApp FAS and E-Series storage systems all support 10GbE. An advantage of 10GbE is its ability to reduce the number of network ports in the infrastructure, especially but not limited to blade servers. In addition, 10GbE can handle several VLANs simultaneously. NetApp and Mirantis recommend using 10GbE throughout any production OpenStack cloud.

Mirantis and NetApp recommend separating storage network traffic from other networks, ideally with a physically separated network. If a physical separation is not possible, a separate network can be provided by using separate switches or by creating a VLAN on shared switches.

https://docs.mirantis.com/openstack/fuel/fuel-7.0/planning-guide.html#planning-guide

https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#ref-arch

https://docs.mirantis.com/openstack/fuel/fuel-7.0/#guides

http://docs.openstack.org/sec/



If switches are shared with storage and other traffic, it is imperative to confirm that the switches have adequate bandwidth to support the combined traffic load. Although the storage VLAN should not be routable, other VLANs (such as those for management or VM traffic on the same switches) might be routable.

Whenever possible, storage networks should be configured as single, isolated networks that are not routable. NetApp recommends minimizing the number of network hops between the storage subsystem and the host node to enable low latency.

Mirantis and NetApp recommend using link aggregation to increase the performance and stability of cloud storage. Best practices include:

Use switches that support LACP link aggregation.

Enable LACP for switch ports connected to Data ONTAP nodes.

Enable LACP for switch ports connected to OpenStack compute nodes.

All of the nodes in an OpenStack deployment must be configured to use NTP to avoid issues that arise from time skew. It is extremely important that the NTP service be highly available, although best practices for arranging that high availability are outside the scope of this document.

NetApp clustered Data ONTAP networking must be set up with these best practices in mind:

Make all Ethernet data ports, interface groups, and VLANs members of an appropriate failover group.

Associate all NFS, CIFS, and management LIFs with the appropriate failover group.

To keep network connectivity as simple as possible, use the same port on each node for the same purpose (assuming similar nodes with similar ports).

For iSCSI storage, NetApp recommends using dedicated iSCSI VLANs that are available to all participating hosts. This method isolates the unprotected storage traffic and should also provide a contiguous network subnet for connectivity.

NetApp E-Series storage controllers do not currently support link aggregation. Therefore, a highly available storage deployment depends on correctly configuring failover drivers to avoid multiple paths in the logical network topology between hosts and storage controllers. For information about how to configure the DMMP driver, see the NetApp E-Series Storage Systems Failover Drivers Guide.

All of the REST APIs used by OpenStack services should be offered through a tier of redundant load balancers configured to distribute incoming connections across all healthy API endpoints.

Note: Mirantis OpenStack takes care of load-balancer configuration during Fuel deployment.

It is a NetApp best practice to use jumbo frames for Ethernet storage traffic, especially NFS. Standard frames require NFS datagrams to be broken up and reassembled at the destination. Doing so causes a performance hit on both ends of the wire. In contrast, a jumbo frame enables NFS datagrams to be sent whole, removing the need to break them up and reassemble them. Jumbo frames should be configured for storage networks and isolated, nonrouted VLANs that carry NFS, CIFS, and iSCSI data streams.

Mirantis advises taking special care that MTU changes are configured end to end to avoid costly disassembly and reassembly of packets en route.

For further details on these and other best practices, see the NetApp technical report Highly Available

OpenStack Deployments Built on NetApp Storage Systems | TR-4323-DESIGN and the Mirantis

OpenStack 7.0 documentation site.

5.3 Storage and Database Best Practices

Implement the following storage and database best practices:

When Cinder is deployed with clustered Data ONTAP, NetApp recommends that each Cinder back end refer to a single storage virtual machine (SVM) in a cluster. Although the driver can operate

https://library.netapp.com/ecm/ecm_download_file/ECMP1394845






without the explicit declaration of a mapping between a back end and an SVM, a variety of advanced functionality (for example, volume-type extra specs) will be disabled.

When Cinder is deployed with Data ONTAP, Cinder snapshots are created by applying the FlexClone feature of Data ONTAP. Therefore, a license option for FlexClone must be enabled.

NetApp OnCommand® Workflow Automation (WFA) is a flexible framework that provides automation

for storage-related tasks, customization, scripting capabilities, and integration with higher-order IT systems such as orchestration software through web services. Unless you have a significant existing investment in WFA that you want to leverage in an OpenStack deployment, NetApp recommends starting with the direct mode of operation when deploying Cinder with a NetApp Data ONTAP cluster.

Currently, using Cinder with a NetApp E-Series system requires using the SANtricity Web Services Proxy in the intermediated mode.

NetApp recommends the following resiliency best practices when deploying storage networks:

Use RAID DP, the NetApp high-performance implementation of RAID 6, for better data protection with Data ONTAP.

Use Dynamic Disk Pools to achieve a faster and more efficient parity protection scheme with E-Series and EF-Series storage solutions.

Use multipath HA with active-active storage configurations to improve overall system availability and promote higher performance consistency.

Allow Data ONTAP to select disks automatically when creating aggregates or volumes.

Use the latest Data ONTAP or SANtricity general deployment release available on the NetApp Support site.

Use the latest storage controller, shelf, and disk firmware available on the NetApp Support site.

Use clustered storage controllers to eliminate single points of failure.

NetApp recommends the following database best practices:

Use the InnoDB storage engine of MySQL.

Restrict database network traffic to the OpenStack management network.

Configure the database to require SSL for database clients to protect data “on the wire.”

If you use clustered Data ONTAP, NetApp recommends breaking the MySQL database components into individual FlexVol volumes. Doings so enables the appropriate MySQL binary log files to be applied for any necessary recovery after a restore of the data.

For appropriate MySQL and NetApp settings, refer to the NetApp technical report Best Practices Guidelines for MySQL | TR-3657.

NetApp recommends the following best practices for backup and recovery:

Create application-consistent backups with NetApp Snapshot copies by flushing the MySQL cache to disk.

Use NetApp tools, such as the NetApp Snap Creator®

framework, as a mechanism to execute efficient backups and restores of the MySQL database.

Manage the clustering and replication carefully when executing a restore. The storage-based NetApp Snapshot copy is not application aware.

For more information about this configuration, refer to the NetApp technical report Online MySQL Backup Using NetApp Snapshot Technology | TR-3601.

NetApp recommends the following best practices for disaster recovery using an active-passive configuration:

Use the NFS protocol for the back-end storage of the MySQL database.

Use semisynchronous or asynchronous replication, depending on your SLA.

Follow guidelines provided for your MySQL storage design to leverage NetApp Snapshot technology to execute efficient backup and restore functionality.

http://mysupport.netapp.com/








When using the Distributed Replication Block Device, use the iSCSI protocol with LUNs for the back-end storage of the MySQL database.

NetApp recommends the following best practices for disaster recovery using an active-active configuration:

Use the NFS protocol for the back-end storage of the MySQL database to take advantage of the flexibility of NetApp storage technology.

Follow the Galera configuration recommendations defined in the MySQL Galera cluster documentation.

Follow guidelines provided for your MySQL storage design to leverage NetApp Snapshot technology copies to execute efficient backup and restore functionality.

Deploy a minimum of three nodes for the MySQL Galera cluster because Galera is a quorum-based system that requires at least three nodes to achieve quorum.

NetApp strongly recommends that database clients access MySQL Galera instances through a load balancer.

If live migration of VMs is a functional requirement of an OpenStack deployment, NetApp strongly recommends using an NFS export from a FlexVol volume as the storage for ephemeral disks for instances. Deduplication of this FlexVol volume can also provide storage efficiency benefits.

For further details on these and other best practices, see the NetApp technical report Highly Available

OpenStack Deployments Built on NetApp Storage Systems | TR-4323.

6 Implementation

6.1 Mirantis OpenStack Plug-In

The reference architecture can be deployed using a Mirantis OpenStack plug-in, which will configure the

appropriate Cinder back end and verify connectivity to the storage system. The plug-in allows deployment

of NetApp integration alongside deployment of the cloud, thus eliminating the need for manual or scripted

postdeployment configuration.

6.2 Predeployment Considerations

The following list summarizes predeployment considerations:

Hardware and networking infrastructure for MOS deployment must be configured according to this reference architecture.

Download the Mirantis OpenStack 7.0 ISO from the Mirantis download site: https://www.mirantis.com/products/mirantis-openstack-software/

Download the NetApp Fuel plug-in from the official Mirantis plug-in repository at: https://www.mirantis.com/products/openstack-drivers-and-plugins/fuel-plugins/

6.3 Deployment Workflow

This section describes the deployment workflow of a NetApp based storage infrastructure with Mirantis

OpenStack.

Boot MOS Master Node

Mirantis OpenStack deploys OpenStack to target hardware from a dedicated machine (or, preferably, in

most cases, a dedicated VM) referred to as a master node. To install the master node, adjust BIOS

settings on this VM to boot from the optical drive and provide the MOS .ISO, either as the image of a

virtual drive or burned to a DVD.



https://www.mirantis.com/products/mirantis-openstack-software/

https://www.mirantis.com/products/openstack-drivers-and-plugins/fuel-plugins/


Press the tab key to configure network and DNS settings, as shown in Figure 6.

Figure 6) Fuel boot.

Perform Initial Configuration

After the base OS is installed, the bootstrap process asks for PXE and other settings. Figure 7 shows the

Fuel configuration screen.


Figure 7) Fuel configuration screen.

Refer to the Fuel User Guide for more details.

Access Fuel Web UI

After MOS components are installed, the FUEL web UI can be accessed through https://<ip

address>:8443. Log in to this IP address from a web browser and use the following default credentials:

User name: admin

Password: admin

The web UI log-in page is shown in Figure 8.

https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#changing-pxe-network-parameters-during-installation

https://x.x.x.x:8443/


Figure 8) Fuel web UI log-in page.

Upload and Install NetApp Fuel Plug-In

Once Fuel is installed, upload the Fuel plug-in for NetApp Cinder drivers. Complete the following steps to

do this:

1. Upload the plug-in rpm package to the root home directory on the MOS master node.

# scp ./fuel-plugin-cinder-netapp.rpm root@<fuel.addr>:~/

2. Access the MOS master node using ssh and install the plug-in.

# fuel plugins --install fuel-plugin-cinder-netapp.rpm

Figure 9 shows the Fuel plug-in installation in progress.


Figure 9) Fuel plug-in installation.

Create OpenStack Environment

Create a new OpenStack environment and configure it to your requirements. Figure 10 shows this part of

the GUI.

Figure 10) OpenStack environment creation.

No other changes are necessary in this wizard. Choose defaults on the Compute, Networking Setup,

Storage Backends, Additional Services, and Finish wizard pages.


Add Nodes and Roles

After the environment is created, a series of tabs is available to configure the cloud. The Dashboard tab,

shown in Figure 11, provides a summary of the cluster configuration.

Figure 11) Fuel UI summary.

Start building the cloud by adding nodes and assigning appropriate roles using the Dashboard tab. The

example shown in Figure 12 includes three controller nodes and one compute node. The specifications of

each node are automatically shown on the right side of the tab view.


Figure 12) Assign roles in Fuel UI.

Configure Networking

Use the Networks tab to configure networks and the Nodes tab to configure node networks and disk

layout. An example is shown in Figure 13.


Figure 13) General network configuration.

Configure the network according to the Mirantis OpenStack 7.0 Reference Architectures documentation.

Figure 14 shows this part of the GUI.



Figure 14) Nodes network configuration.

Enable Plug-In

The Settings tab has a “Cinder and NetApp Integration” section in which the plug-in can be enabled and

all necessary configuration fields can be filled in. This part of the GUI is shown in Figure 15.


Figure 15) Enable and configure NetApp plug-in.

At present, the following Fuel deployment options are available and recommended:


Data ONTAP Cluster. Leverages clustered Data ONTAP (NetApp FAS storage systems). This Fuel deployment option supports NFS and iSCSI.

E-Series. Leverages NetApp E-Series storage systems. This Fuel deployment option supports iSCSI.

Deploy Changes

After configuring all cluster settings, click Deploy Changes in the Dashboard tab, as shown in Figure 16.

Figure 16) Deploy changes.

Deployment of MOS infrastructure can take anywhere from one hour to several hours, depending on the

size of your MOS cluster and the hardware and software configuration chosen for the cloud. For large

installations, Mirantis OpenStack automatically deploys the compute nodes in batches to avoid

overloading the network or the MOS server.

7 Verification and Testing

Fuel integration for NetApp Cinder drivers was tested extensively, both for functionality and UI. The

following sections cover at a high level the tests performed.

7.1 Functional Testing

The functional tests performed included:

Comparison and verification of the Fuel plug-in to Cinder configuration file changes (cinder.conf)

Plug-in functionality with clustered Data ONTAP and E-Series

Attachment and use of Cinder volumes with clustered Data ONTAP and E-Series storage systems

Verification and use of Cinder snapshots with clustered Data ONTAP and E-Series storage systems

Note: Currently, the Mirantis Fuel plugin for NetApp Cinder drivers supports the following storage systems and protocols:

Clustered Data ONTAP storage systems with NFS and iSCSI protocols

E-Series storage systems with iSCSI protocol


7.2 System Testing

In addition to validating functionality, installation and deployment, modification of the environment using

the plug-in, and uninstall were thoroughly tested and verified for production use with Mirantis OpenStack.

Note: The NetApp Cinder drivers for Fuel plug-in integration are validated only on Mirantis OpenStack based on Kilo (MOS 7.0).

Note: The Cinder service must be enabled on all controller nodes.

7.3 Performing Functional Testing

To verify that the NetApp storage service worked correctly with deployed MOS, we prepared the

environment and performed the following steps:

Test Preparation

Log in to MOS master node (Fuel):

# ssh root@<FUEL_IP_ADDRESS>

Get list of environments (if several environments have been deployed):

# fuel env list

Get list of nodes for particular environment:

# fuel --env-id <ENVIRONMENT_ID> node

Log in to any controller node:

# ssh node-<CONTROLLER_NODE_ID>

Get admin rights:

# source ~/openrc

Tests Performed

Test plug-in functionality with clustered Data ONTAP and E-Series:

# nova volume-create --volume-type netapp --display-name test_volume 1

# nova volume-list

(New volume should show status “Available.”)

Create a Nova instance:

# nova boot <INSTANCE_NAME> --flavor m1.tiny --image cirros

Attach and use Cinder volumes with clustered Data ONTAP and E-Series storage systems:

# nova volume-attach <INSTANCE_ID> <TEST_VOLUME_ID>

# nova volume-status

(The volume should show the status “In-use” and you should see the instance id where the volume is connected.)

Also, you can log in to the instance and mount a new volume if you need to.

Verify and use Cinder snapshots with clustered Data ONTAP and E-Series storage systems:

# nova volume-snapshot-create --display-name test_snapshot

<TEST_VOLUME_ID>

# nova volume-snapshot-list

(A new snapshot should show the status “Available.”)

# nova nova volume-create --snapshot-id <SNAPSHOT_ID> --volume-type

netapp

--display-name test_volume_from_snapshot 1


# nova volume-list

(A new volume should show the status “Available.”)

8 Support

Support for NetApp clustered Data ONTAP and E-Series storage systems with Mirantis OpenStack is

provided jointly by NetApp and Mirantis. Call either NetApp or Mirantis to have your issue resolved

accordingly. In general, NetApp storage–related and driver-related issues will be resolved by NetApp

Support and Mirantis OpenStack–related issues will be resolved by Mirantis Support.

9 Conclusion

OpenStack storage is becoming increasingly complex. This reference architecture from NetApp and

Mirantis provides a stable and performance-oriented solution for customers whose business depends on

their ability to store, protect, and serve data. The reference architecture should be easy to install and

maintain. The combination of NetApp reliability, Mirantis OpenStack 7 ease of deployment, and a tested

and certified MOS 7 plug-in enables a short time to market and a reliable and performance-oriented base

for long-term business success.

The configurations in this reference architecture and the MOS 7 plug-in were tested and verified by

Mirantis in collaboration with NetApp and are presented jointly by both companies. Mirantis and NetApp

recommend implementing NetApp storage in a Mirantis OpenStack context with this reference

architecture. Deviations from the reference architecture are not advised unless directed by Mirantis and

NetApp.

On request, the expert teams at Mirantis and NetApp can assist with a reference architecture deployment

or a custom architecture for use cases not covered by this reference architecture.

Appendix: Software and Documentation

Mirantis OpenStack 7.0

Mirantis OpenStack 7.0 NetApp Fuel Plug-In

Mirantis OpenStack 7.0 Documentation

Mirantis OpenStack 7.0 Reference Architectures

Fuel User Guide

Mirantis OpenStack Operations Guide

Highly Available OpenStack Deployments Built on NetApp Storage Systems | TR-4323-DESIGN

OpenStack Security Guide

Best Practices Guidelines for MySQL | TR-3657

Online MYSQL Backup Using NetApp Snapshot Technology | TR-3601

Mirantis Support

NetApp Support

NetApp E-Series Storage Systems Failover Drivers Guide

NetApp OpenStack Deployment and Operations Guide



https://www.mirantis.com/support/enterprise-support-services/

https://www.mirantis.com/products/mirantis-openstack-software/

https://www.mirantis.com/products/openstack-drivers-and-plugins/fuel-plugins/



https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#user-guide

https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#operations-guide





https://www.mirantis.com/support/enterprise-support-services/


https://library.netapp.com/ecm/ecm_download_file/ECMP1394845

http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/ch_executive-summary.html


Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact product and feature versions described in this document are supported for your specific environment. The NetApp IMT defines the product components and versions that can be used to construct configurations that are supported by NetApp. Specific results depend on each customer's installation in accordance with published specifications.

Trademark Information

NetApp, the NetApp logo, Go Further, Faster, AltaVault, ASUP, AutoSupport, Campaign Express, Cloud

ONTAP, Clustered Data ONTAP, Customer Fitness, Data ONTAP, DataMotion, Fitness, Flash Accel,

Flash Cache, Flash Pool, FlashRay, FlexArray, FlexCache, FlexClone, FlexPod, FlexScale, FlexShare,

FlexVol, FPolicy, GetSuccessful, LockVault, Manage ONTAP, Mars, MetroCluster, MultiStore, NetApp

Insight, OnCommand, ONTAP, ONTAPI, RAID DP, RAID-TEC, SANtricity, SecureShare, Simplicity,

Simulate ONTAP, SnapCenter, Snap Creator, SnapCopy, SnapDrive, SnapIntegrator, SnapLock,

SnapManager, SnapMirror, SnapMover, SnapProtect, SnapRestore, Snapshot, SnapValidator,

SnapVault, StorageGRID, Tech OnTap, Unbound Cloud, WAFL, and other names are trademarks or

registered trademarks of NetApp Inc., in the United States and/or other countries. All other brands or

products are trademarks or registered trademarks of their respective holders and should be treated as

such. A current list of NetApp trademarks is available on the web at

http://www.netapp.com/us/legal/netapptmlist.aspx. TR-4478-1215

Copyright Information

Copyright © 1994–2015 NetApp, Inc. All rights reserved. Printed in the U.S. No part of this document covered by copyright may be reproduced in any form or by any means—graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an electronic retrieval system—without prior written permission of the copyright owner.

Software derived from copyrighted NetApp material is subject to the following license and disclaimer:

THIS SOFTWARE IS PROVIDED BY NETAPP "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL NETAPP BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

NetApp reserves the right to change any products described herein at any time, and without notice. NetApp assumes no responsibility or liability arising from the use of products described herein, except as expressly agreed to in writing by NetApp. The use or purchase of this product does not convey a license under any patent rights, trademark rights, or any other intellectual property rights of NetApp.

The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications.

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7103 (October 1988) and FAR 52-227-19 (June 1987).

http://support.netapp.com/matrix/mtx/login.do

http://www.netapp.com/us/legal/netapptmlist.aspx

Technical Report NetApp Mirantis Unlocked Reference ... Report NetApp Mirantis Unlocked Reference...

Documents

Transcript of Technical Report NetApp Mirantis Unlocked Reference ... Report NetApp Mirantis Unlocked Reference...