technical report netapp private storage for softlayervirtual machines (vms) or bare-metal computing...

Technical Report

NetApp Private Storage for SoftLayer Solution Architecture and Deployment Guide

Mark Beaupre, NetApp

October 2014 | TR-4326

Abstract

This document describes the architecture of the NetApp® Private Storage for SoftLayer

solution and provides procedures for deploying and testing the solution.

2 NetApp Private Storage for SoftLayer Solution Architecture and Deployment Guide

© 2014 NetApp, Inc. All rights reserved.

TABLE OF CONTENTS

1 NetApp Private Storage for SoftLayer Solution ................................................................................ 3

2 Solution Architecture ........................................................................................................................... 4

2.1 Solution Architecture Components ..................................................................................................................4

2.2 Solution Architecture Diagrams ..................................................................................................................... 10

2.3 Solution Architecture Data Security Elements ............................................................................................... 12

3 NetApp Private Storage for SoftLayer Deployment ........................................................................ 13

3.1 Deployment Workflow Overview ................................................................................................................... 13

3.2 Sign Up for SoftLayer Account and Order Computing and Network Services ............................................... 13

3.3 Create a SoftLayer Direct Link Network Connection ..................................................................................... 16

3.4 Configure Local Network BGP Peering ......................................................................................................... 19

3.5 Configure NetApp Storage Network Connectivity to SoftLayer Direct Link ................................................... 21

4 NetApp Private Storage for SoftLayer Testing ................................................................................ 25

4.1 Test Procedures ............................................................................................................................................ 25

4.2 Performance Test Guidelines ........................................................................................................................ 54

Reference ................................................................................................................................................... 56

LIST OF TABLES

Table 1) SoftLayer network PoP locations......................................................................................................................8

Table 2) SoftLayer webpage links. .................................................................................................................................9

Table 3) Prerequisites for signing up for a SoftLayer account and ordering computing and network services. ............ 13

Table 4) Prerequisites for creating a SoftLayer Direct Link network connection........................................................... 16

Table 5) Prerequisites for configuring local BPG peering. ............................................................................................ 19

Table 6) Prerequisites for configuring the NetApp storage network connectivity to SoftLayer Direct Link. ................... 21

Table 7) Test case for verifying SoftLayer Direct Link network connection. ................................................................. 25

Table 8) Test case for verifying iSCSI session connectivity. ........................................................................................ 30

Table 9) Test case for verifying iSCSI LUN access. ..................................................................................................... 40

Table 10) Test case for verifying CIFS protocol connectivity. ....................................................................................... 47

Table 11) Test case for verifying NFS protocol connectivity. ........................................................................................ 53

LIST OF FIGURES

Figure 1) SoftLayer Direct Link network architecture. .....................................................................................................7

Figure 2) NetApp Private Storage for SoftLayer solution architecture. ......................................................................... 11

Figure 3) Sample local network configuration (Cisco® NX-OS). ................................................................................... 21



1 NetApp Private Storage for SoftLayer Solution

This document describes the storage architecture of the NetApp Private Storage for SoftLayer solution

and provides procedures for deploying and testing the solution.

Overview

The NetApp Private Storage for SoftLayer solution is a hybrid cloud architecture that allows enterprises to

build an agile cloud infrastructure that combines the scalability and flexibility of the SoftLayer Direct Link

service with the control and performance of NetApp enterprise storage.

NetApp storage is deployed at a colocation facility where the SoftLayer Direct Link service is available,

and the NetApp storage is connected to SoftLayer computing resources through the SoftLayer Direct Link

service.

Typical use cases for the NetApp Private Storage for SoftLayer solution include the following:

Oracle®, Microsoft

® SQL Server

®, and SAP

® primary workloads

Disaster recovery

Development and testing

Big data analytics

Data with compliance requirements

Data center migration and consolidation

A NetApp Private Storage for SoftLayer solution that is deployed at a colocation facility can also be

connected to on-premises data centers through multiprotocol label switching (MPLS) or through a point-

to-point virtual private network (VPN). Customers can then use efficient NetApp SnapMirror® and

SnapVault® storage replication to move data closer to SoftLayer computing resources.

From a business perspective, the solution offers customers the ability to shift capital expenses to

operational expenses. Customers can dynamically allocate computing, application, or backup resources

instead of building out on-premises data centers and infrastructure.

Note: Initially, the NetApp Private Storage for SoftLayer solution is available only through IBM Global Technology Services (GTS).

IBM GTS has an existing relationship with NetApp for resale of NetApp products. The IBM GTS team is trained and capable, with the services staff needed to deploy and configure NetApp FAS storage systems today. For more information about how to purchase the NetApp Private Storage for SoftLayer solution, contact your NetApp account team.

Technical Overview

The NetApp Private Storage for SoftLayer solution combines computing resources from SoftLayer with

NetApp storage deployed at a colocation facility where the SoftLayer Direct Link network point of

presence (PoP) is available. Connectivity from the NetApp storage to the SoftLayer cloud is made

possible by the SoftLayer Direct Link network service.

The SoftLayer Direct Link network service offers dedicated high-bandwidth, low-latency, secure network

connectivity to the SoftLayer cloud. The service is provisioned through the SoftLayer customer portal.

Both 1Gb/sec and 10Gb/sec network connections are available. The connections are provisioned

manually by cross-connect in the colocation facility where the SoftLayer Direct Link service is available.

In the colocation facility, the customer provides layer 3 network equipment and NetApp storage systems.

Virtual machines (VMs) or bare-metal computing in the SoftLayer cloud connect to the NetApp storage

through IP-based storage protocols (iSCSI, CIFS, or NFS) over the Direct Link network connection.

Additional MPLS or point-to-point VPN network resources can be used to provide connectivity between

regions where SoftLayer PoPs are located as well as to on-premises data centers.



Glossary of Terms

This section defines the terms used to describe the technical architecture of the solution.

SoftLayer Private Network

The SoftLayer private network service uses an isolated private (RFC 1918) IP address range

(192.168.0.0/16). A private network can be connected to other networks through a Direct Link network

connection or through Internet Protocol security (IPsec) VPN connections.

SoftLayer Public Network

The SoftLayer public network service allows for redundant and resilient 1Gb/sec connectivity to the

Internet.

SoftLayer Management Network

The SoftLayer management network service enables out-of-band management, operating system (OS)

updates, and centralized backup. It also provides access to the SoftLayer software repository.

Direct Link

Direct Link is a network service offered by SoftLayer and by colocation providers that have SoftLayer

PoPs to establish a high-speed connection to customer-provided network equipment in the colocation

facility.

Border Gateway Protocol

Border Gateway Protocol (BGP) is the layer 3 routing protocol used by SoftLayer Direct Link to advertise

routes between the private network and the customer network in the colocation facility. BGP configuration

on the customer network switch is used to advertise routes from the customer network to the private

network.

Virtual Servers

The SoftLayer virtual server service provides computing resources through VM OSs for the SoftLayer

cloud. SoftLayer virtual servers can run either Microsoft Windows® or Linux

® OSs.

Bare-Metal Servers

The SoftLayer service provides computing resources through bare-metal (dedicated physical) servers in

the SoftLayer cloud. This level of computing offers a higher level of performance and greater

configuration flexibility for processor-intensive and I/O-intensive workloads.

2 Solution Architecture

This section describes the components of the solution architecture and explains the data security

elements that are included.

2.1 Solution Architecture Components

The solution architecture consists of the following components:

SoftLayer servers

SoftLayer private network

SoftLayer Direct Link



SoftLayer Direct Link PoP colocation facilities

BGP

Customer-provided layer 3 network equipment

NetApp FAS storage and FlexArray

SoftLayer Servers

The SoftLayer server service offers both virtual and bare-metal servers. Both types of servers can be

connected to the customer-owned network equipment and to the NetApp storage in the colocation facility

with IP storage protocols (iSCSI, SMB, NFS, and NDMP) through the Direct Link network connection.

The SoftLayer Customer Portal web interface is used to deploy virtual server VM and bare-metal

computing resources for the NetApp Private Storage for SoftLayer solution.

Advanced SoftLayer users can programmatically deploy virtual server VMs through SoftLayer API

(SLAPI) or by using python scripts with the SoftLayer SLAPI command-line interface (CLI).

For more information about how to use the SLAPI CLI and the SLAPI, refer to the SoftLayer Developer

Network website.

SoftLayer Virtual Servers

SoftLayer virtual servers are VMs that customers can use to rapidly deploy computing resources. These

virtual servers are fully customizable, allowing customers to select CPU, memory, network, storage, OSs,

system add-ons, and monitoring options.

The tenancy of the virtual server can also be selected. In standard tenancy, the virtual server is deployed

to a multi-tenant environment. In private-node tenancy, the virtual server is deployed to a single-tenant

environment. Virtual servers deployed onto private nodes are ideal for workloads that have stringent

resource requirements.

The SoftLayer virtual servers connect to the NetApp storage in the colocation facility through guest-level

connectivity for iSCSI, NFS, or SMB.

Note: SoftLayer virtual servers do not support raw device–mapped (RDM) or pass-through logical unit numbers (LUNs).

For more information about SoftLayer virtual servers, refer to the SoftLayer Introduction to Virtual Servers

website.

SoftLayer Bare-Metal Servers

In addition to virtual servers, SoftLayer offers the option of deploying bare-metal servers or instances.

Bare-metal server is a monthly offering that provides customers a dedicated server with components that

can be customized. A bare-metal instance is a prebuilt server that comes in different configurations that

can be ordered on an hourly or monthly basis.

Bare-metal servers can be installed with virtualization software such as VMware® or Microsoft Hyper-V

® in

addition to OSs.

The SoftLayer bare-metal servers or instances connect to the NetApp storage in the colocation facility by

using connectivity for iSCSI (software initiator only), NFS, or SMB.

Note: If the virtualization software is installed on the bare-metal instance, RDM LUNs or pass-through LUNs stored on the customer NetApp storage can be used. That configuration is outside the scope of this document.

For more information about SoftLayer bare-metal servers, refer to the SoftLayer Bare Metal Server

website.

https://control.softlayer.com/

http://sldn.softlayer.com/

http://sldn.softlayer.com/

http://knowledgelayer.softlayer.com/learning/introduction-virtual-servers

http://knowledgelayer.softlayer.com/topic/bare-metal-server-0



Server Purchasing Options

There are two purchasing options for virtual server and bare-metal computing:

Monthly (bare-metal servers, bare-metal instances, or virtual servers)

Hourly (bare-metal instance, virtual servers)

For more information about SoftLayer virtual server and bare-metal server purchasing options, refer to the

SoftLayer Virtual Servers product website.

Available Operating Systems

SoftLayer virtual servers run different OSs from those of bare-metal servers. SoftLayer virtual server VMs

can run Windows or Linux OSs. Bare-metal instances can run Windows, Linux, and FreeBSD OSs.

For a list of available OSs, refer to the SoftLayer Software website.

SoftLayer also offers applications that can be installed on virtual or bare-metal servers:

Database servers

Virtualization (bare-metal servers or instances only)

Security

Control plane

For a list of available applications, refer to the SoftLayer Software website.

SoftLayer manages licensing and billing for OSs and applications offered through the SoftLayer Customer

Portal. In addition, customers can install their own OSs and software on bare-metal servers.

Note: Customers are responsible for licensing their own software that is not provided by SoftLayer.

Customers can also create their own virtual server image templates to be used for deploying virtual

servers. For more information about SoftLayer image templates, refer to the SoftLayer Image Template

website.

For each OS, hypervisor, and application type, validate version compatibility with the NetApp client

software and the Data ONTAP® version through the NetApp Interoperability Matrix Tool. (This site

requires a NetApp Support account login.)

Connecting to SoftLayer Servers

By default, all SoftLayer virtual and bare-metal servers are configured at launch with two network

interfaces:

A private network interface that is assigned an RFC 1918 private IP address

A management network interface that is assigned an RFC 1918 private IP address

The management network interface is used for out-of-band management, backup, and other SoftLayer

services.

Customers have the option of provisioning a public network interface that is assigned a public IP address.

Note: Customers cannot request specific private or public IP Classless Inter-Domain Routing (IP CIDR) blocks. Private IP addresses are assigned in 64 IP address blocks, and public IP addresses can be assigned in 4 or 8 IP address blocks.

To connect to an instance with a public IP address, customers can use a Secure Shell (SSH) client or a

Microsoft Remote Desktop Protocol (RDP) client to connect to the virtual or bare-metal server through the

public IP address.

http://www.softlayer.com/cloud-servers

http://www.softlayer.com/software

http://www.softlayer.com/software



http://knowledgelayer.softlayer.com/topic/image-templates

http://support.netapp.com/matrix



Note: When customers use public IP addresses, they must configure software firewalls on the servers that are assigned public IP addresses; alternatively, they can provision a firewall appliance through the SoftLayer customer portal.

To connect to an instance with no public IP address, customers must use a VPN connection to connect

through an SSH or RDP client.

For more information about how to use Secure Sockets Layer (SSL) to connect to the private network

interface on a virtual or bare-metal server, refer to the SoftLayer VPN website.

For bare-metal servers that have no OS installed, customers can use SSH to connect to the management

network IP address, or they can use the SoftLayer keyboard, video, and mouse (KVM) over IP (KVM/IP)

service. The SoftLayer KVM/IP service is offered free of charge. It allows customers to mount ISO images

remotely to support remote OS or application installation on bare-metal servers.

For more information about the SoftLayer KVM/IP service, refer to the SoftLayer KVM/IP website.


The SoftLayer private network service provides isolated RFC 1918 IPv4 address ranges (192.168.0.0/16)

to which virtual and bare-metal servers can be deployed.

A SoftLayer private network can be connected to the customer network in the Direct Link data center or to

on-premises customer networks through a point-to-point VPN.

For more information, refer to the SoftLayer Network website.


SoftLayer Direct Link is used to establish a dedicated network connection between the customer-provided

network equipment in the colocation facility and the SoftLayer private network. Direct Link supports the

use of industry standard 802.1Q virtual local area networks (VLANs).

By using multiple VLANs, customers can partition the Direct Link dedicated connection into multiple Direct

Link connections. As Figure 1 shows, each Direct Link private network is associated with a unique VLAN

tag.

This network segregation goes from the SoftLayer private network, across the Direct Link network

connection (cross-connect), through dedicated virtual routing and forwarding (VRF) instances, and then

down to VLAN interfaces used by logical interfaces (LIFs) on the storage virtual machines (SVMs,

formerly known as Vservers) on the NetApp storage cluster.

Figure 1) SoftLayer Direct Link network architecture.

http://knowledgelayer.softlayer.com/topic/vpn

http://knowledgelayer.softlayer.com/topic/kvmip

http://www.softlayer.com/network



Direct Link connections come in two types: 1GbE and 10GbE. A cross-connect cable is patched from the

SoftLayer PoP in the colocation facility to the customer network demarcation panel in the Direct Link data

center. An additional patch cable is patched from the demarcation panel to a port on the customer-

provided network equipment.

Peering IP addresses are assigned to the customer-provided network equipment and to the SoftLayer

back-end customer routers, creating a layer 2 connection between the customer network and the

SoftLayer network.

The routing between the customer network in the colocation facility and the SoftLayer private network

uses layer 3 routing over a layer 2 network connection. BGP is used to advertise routes from the

customer network to the SoftLayer private network and from the SoftLayer private network to the

customer network.

NetApp recommends configuring redundant Direct Link network connections to the customer-provided

redundant network equipment in the SoftLayer Direct Link data center.

For more information about SoftLayer Direct Link, refer to the SoftLayer Direct Link website.

SoftLayer Direct Link Point-of-Presence Colocation Facilities

SoftLayer Direct Link data centers provide connectivity to the SoftLayer cloud through Direct Link PoP

network connections. Table 1 lists the available colocation facilities.

Note: Initial availability of the NetApp Private Storage for SoftLayer solution is limited to the seven Equinix PoP facilities listed in Table 1.

IBM GTS is certified to resell Equinix colocation services today. For more information about IBM GTS or about how to purchase the NetApp Private Storage solution, contact your NetApp account team.

Table 1) SoftLayer network PoP locations.

Location SoftLayer Network PoP Provider

Atlanta, GA ATL01 Telx

Chicago, IL CHI01 Equinix

Dallas, TX DAL03 Equinix

Denver, CO DEN03 Coresite

Los Angeles, CA LAX01 Coresite

Miami, FL MIA01 Terremark

New York City, NY NYC01 Telx

San Jose, CA SJC02 Equinix

Seattle, WA SEA02 The Westin

Toronto, Ontario, Canada TOR02 Cologix

Washington, DC WDC02 Equinix

Hong Kong HKG01 Pacnet

Singapore SNG01 Equinix

Tokyo TOK01 Equinix

http://www.softlayer.com/direct-link



Location SoftLayer Network PoP Provider

Amsterdam AMS02 Equinix

Frankfurt FRA01 InterXion

London LON01 TelecityGroup

Customers who use the SoftLayer data centers designated for government (SoftLayer DAL08 and

WDC03) can connect their on-premises NetApp storage to SoftLayer through VPN connections. No Direct

Link locations are able to connect to these data centers.

For more information about SoftLayer government solutions, Direct Link locations, and data centers, refer

to the webpages listed in Table 2.

Table 2) SoftLayer webpage links.

SoftLayer Webpage

Government solutions SoftLayer Government

Direct Link locations SoftLayer Direct Link

Data centers SoftLayer Data Centers

The colocation facilities that host SoftLayer network PoPs offer secure, highly available environments for

the customer-owned NetApp storage and network equipment of the NetApp Private Storage for SoftLayer

solution. These locations provide a high degree of physical and operational security.

Geographically, many of the SoftLayer PoP colocation facilities are located close to the SoftLayer

computing fleet; therefore, the latencies between the NetApp storage and the SoftLayer computing

resources are low to very low. NetApp has observed the following latencies for the following locations:

San Jose PoP (Equinix SV5) to San Jose (SJC02): from <1ms to 1ms

Washington, DC, PoP (Equinix DC2) to Washington, DC (WDC02): from <1ms to 1ms

Note: Because customers might experience varying latencies, NetApp recommends validating the latency of the connectivity to SoftLayer before deploying workloads to the NetApp Private Storage for SoftLayer solution.

Border Gateway Protocol

BGP is used to support network routing between the SoftLayer private network and the customer network

over the SoftLayer Direct Link network connection.

The customer network in the colocation facility is directly connected to the customer-provided layer 3

network equipment. The BGP configuration advertises local network routes to the SoftLayer private

network, and it receives BGP advertisements from the SoftLayer private network over the Direct Link

network connection.

Customer-Provided Layer 3 Network Equipment

The customer-provided network equipment is in the same colocation facility as the NetApp storage.

NetApp does not certify specific network equipment to be used in the solution; however, the network

equipment must support the following features:

BGP

One 9/125 single-mode fiber (SMF) port (1Gb/sec or 10Gb/sec)

1000BASE-T Ethernet ports

http://www.softlayer.com/government

http://www.softlayer.com/direct-link

http://www.softlayer.com/data-centers



802.1Q VLAN tags

The following features are optional:

Open Shortest Path First (OSPF) protocol

VRF

Redundant network switches

Redundant 9/125 SMF (1Gb/sec or 10Gb/sec) ports

10GbE ports

Required Feature Description

BGP is used to route network traffic between the local network in the colocation facility and the SoftLayer

private network.

Direct Link requires a minimum of one physical connection (9/125 SMF) from the customer network

equipment to the SoftLayer PoP.

1000BASE-T network ports on the switch provide network connectivity from the NetApp storage cluster.

Although these ports can be used for data, NetApp recommends using 1GbE ports for node management

and for out-of-band management.

802.1Q VLAN tags are used by Direct Link network connection to segregate network traffic on the same

physical network connection.

Optional Feature Description

If there are additional network connections back to on-premises data centers or to other NetApp Private

Storage for SoftLayer solution locations, the OSPF protocol is used to help prevent routing loops.

Redundant network switches protect data centers against a loss of Direct Link service caused by switch

failure.

Note: For information about configuring redundant network switches, consult your network equipment vendor’s documentation.

Redundant 9/125 SMF ports protect data centers against a loss of Direct Link service caused by a port or

cable failure.

Note: NetApp highly recommends configuring redundant Direct Link connections.

Connecting 10GbE ports on the storage to the switch provides the highest amount of bandwidth capability

between the switch and the storage to support data access.

Note: Although 10GbE Direct Link connections are not required, NetApp recommends them.

NetApp FAS Storage and FlexArray

Both NetApp clustered Data ONTAP and Data ONTAP operating in 7-Mode can function with the NetApp

Private Storage for SoftLayer solution; however, NetApp highly recommends using clustered Data

ONTAP with the solution.

2.2 Solution Architecture Diagrams

Figure 2 shows the architecture of the NetApp Private Storage for SoftLayer solution with redundant

10Gb/sec Direct Link network connections.



Figure 2) NetApp Private Storage for SoftLayer solution architecture.



2.3 Solution Architecture Data Security Elements

According to many customer surveys, data security is the primary concern of enterprises as they move

data to the cloud. Regulatory compliance prohibiting the storage of data in the cloud is another major area

of concern. NetApp Private Storage for SoftLayer allows customers to store their data on NetApp storage

that they own or control so that they can maintain the compliance and security of their data.

The solution contains the following security-related elements:

SoftLayer private network


Colocation facility physical security

NetApp storage encryption

Third-party network security hardware and software


The SoftLayer private network provides network isolation for the resources (virtual servers, bare-metal

servers, services, and so forth) that are provisioned in it. SoftLayer virtual and bare-metal servers

provisioned in a SoftLayer private network can communicate with each other in the private network.

Resources external to the SoftLayer private network do not have access to the resources in the SoftLayer

private network.

SoftLayer private networks can be accessed securely through a site-to-site VPN or through a SoftLayer

Direct Link network connection at a colocation facility where there is a Direct Link PoP.


SoftLayer Direct Link is a private, secure network connection that does not traverse the Internet. The

connectivity to SoftLayer from the NetApp storage in the colocation facility is achieved through physical

cross-connects that are not shared with other customers.

Colocation Facility Physical Security

The colocation facilities for the SoftLayer PoPs provide state-of-the-art physical and operational security.

The data centers have security guards and security systems to provide video surveillance. The security

systems have biometric hand scanners combined with mantrap interlocks to restrict access to authorized

personnel only.

Currently, Equinix is the only colocation partner that has the NetApp Private Storage for SoftLayer

solution available.

For more information about Equinix physical security, refer to the Equinix Physical Security webpage.

NetApp Storage Encryption

NetApp Storage Encryption software is the NetApp implementation of full-disk encryption that uses self-

encrypting drives from leading vendors, allowing data on NetApp storage to be fully encrypted while

maintaining storage efficiency and performance.

For more information, refer to NetApp Storage Encryption.

Third-Party Network Security Hardware and Software

Third-party security hardware and software devices can be used with the NetApp Private Storage for

SoftLayer solution, provided that the security solution can work in a TCP/IP environment. This

requirement exists because the NetApp Private Storage for SoftLayer solution does not support Fibre

Channel or Fibre Channel over Ethernet. NetApp does not certify third-party security solutions that can be

http://www.equinix.com/insight-center/videos/tour-an-ibx-data-center/physical-security/

http://www.netapp.com/us/products/storage-security-systems/netapp-storage-encryption.aspx



used with the NetApp Private Storage for SoftLayer solution. To implement a security solution with the

NetApp Private Storage for SoftLayer solution, contact your NetApp account team for further guidance.

3 NetApp Private Storage for SoftLayer Deployment

This section describes the standard deployment methodology for NetApp Private Storage for SoftLayer.

Because no two customer environments are the same, however, NetApp has delivery partners who

specialize in deploying NetApp Private Storage solutions. These partners are experienced and can help

make your NetApp Private Storage for SoftLayer deployment a success. For more information about

NetApp Private Storage delivery partners, contact your NetApp account representative.

3.1 Deployment Workflow Overview

The workflow for deploying the NetApp Private Storage for SoftLayer solution includes the following tasks:

1. Sign up for a SoftLayer account and order SoftLayer computing and network services.

2. Create a SoftLayer Direct Link network connection.

3. Configure local network BGP peering.

4. Configure NetApp storage connectivity to SoftLayer Direct Link.

3.2 Sign Up for SoftLayer Account and Order Computing and Network Services

This procedure describes how to sign up for a SoftLayer account and order SoftLayer computing and

network services. Table 3 lists the sign-up prerequisites.

Table 3) Prerequisites for signing up for a SoftLayer account and ordering computing and network services.

Description

The customer must have an Internet-connected computer that has web browser software installed.

The customer must have a valid e-mail address.

The customer must have a valid credit card, with a valid telephone number and billing address for the credit card.

The system must meet the documented network requirements (public CIDR block size, bandwidth, and so forth) for the computing service.

The system must meet the documented system configuration requirements (CPU, RAM, local storage, and so forth) for the computing service.

To sign up for a SoftLayer account, complete the following steps:

1. From an Internet-connected computer, open a web browser and go to the SoftLayer website.

2. Click Order Now to start the SoftLayer ordering process.

http://www.softlayer.com/



Note: If there are special requirements for the SoftLayer configuration, click the Live Chat button to speak with a SoftLayer representative.

3. Determine which type of computing resource (virtual or bare-metal or servers) you want to order for connecting to the NetApp storage through Direct Link. Below the heading for that type, select one of the options for ordering computing resources on an hourly or monthly basis (Order Hourly or Order Monthly).

4. On the Configure Your Cloud Server ordering webpage, provide the following parameters and then click Add to Order:

Quantity: Provide the number of servers to be provisioned.

Location: Select the location to which to deploy the computing resource.

Note: This location should be near the SoftLayer PoP where the NetApp storage will be deployed.

System Configuration: Select the CPU, RAM, OS, local disk, network options, and so forth.

Note: The SoftLayer private network subnet size is 64 IP addresses. SoftLayer public network subnet sizes are available in 4 or 8 IP addresses.



Currency: Select the currency that will be used to complete the purchase.

5. Review the order page. Read and accept the Master Service Agreement and click Submit Order.

6. After you submit the order, wait to receive an email confirming it. A SoftLayer representative will contact you to review the order.

7. Review your order with the SoftLayer representative. After your order has been reviewed, it will be approved, and a SoftLayer account will be created.

Note: For virtual servers, the provisioning time generally takes a few minutes. For bare-metal servers, the service-level agreement (SLA) time to provision is 1 to 4 hours.



3.3 Create a SoftLayer Direct Link Network Connection

This procedure describes how to create a SoftLayer Direct Link network connection. Table 4 lists the

connection prerequisites.

Table 4) Prerequisites for creating a SoftLayer Direct Link network connection.

Description

A SoftLayer account and password must be available.

There must be an Internet-connected computer with web browser software installed.

The colocation facility (or the SoftLayer network PoP location) where the SoftLayer Direct Link will be deployed must be identified.

Customer-provided network equipment must be deployed at the Equinix colocation facility (or the SoftLayer network PoP location) where the SoftLayer Direct Link will be deployed.

Customer-provided network equipment must support 9/125 duplex SMF optic cable LC connections.

Customers deploying NetApp Private Storage for SoftLayer at Equinix must have created an Equinix Customer Portal account.

The VLAN number of the Direct Link connection must be identified.

The autonomous system number (ASN) that will be used by the customer-provided network equipment must be identified.

To create a SoftLayer Direct Link network connection, complete the following steps:

1. Open a web browser and go to the SoftLayer Customer Portal. Log in to the management console with your SoftLayer account credentials.

https://portal.equinix.com/





2. Click Network > Direct Link.

3. On the Direct Link dashboard, provide the following parameters and then click Submit:

Select POP Location for Endpoint: From the drop-down list, select the SoftLayer PoP that will be connected to the NetApp storage in the colocation data center.

Connection Speed: Select the port speed of the Direct Link connection (in this example, 1G,

indicating 1Gb/sec).

Remote Deployment: Select whether this is a new or existing deployment (in this example, New).

When Do You Expect the Physical Circuit To Be Delivered and Deployed? Provide the estimated date when the cross-connect in the colocation data center will be provisioned.



4. Verify that the Direct Link dashboard shows that a service ticket was created for the Direct Link request.

5. Wait for a SoftLayer representative to contact you to verify the Direct Link order. After the Direct Link request has been verified, request that a letter of authorization be e-mailed to you from SoftLayer. This letter is used to provide authorization for the colocation technicians to patch a cross-connect from the customer demarcation panel to the SoftLayer PoP.



6. When you receive the letter of authorization, contact your colocation data center provider to request a cross-connect to the SoftLayer PoP.

For Equinix customers, log in to the Equinix Customer Portal and open a cross-connect request.

7. After the cross-connect for the Direct Link network has been patched to the customer demarcation panel in the colocation facility, connect the customer network switch to that panel.

Note: The SMF cable used in the Direct Link network connection has two strands of fiber optic cable (for transmitting and receiving). When the cable is patched properly, the link is established, and the link lights on the switch are lit.

Note: If the cable is not patched properly and the lights are not lit, switch the strands that are patched to the transmitting and receiving ports. If link is still not established, work with Equinix (or the SoftLayer network PoP location) to check the health of the cross-connect.

8. After the SoftLayer Direct Link cross-connect is patched correctly, use the SoftLayer Customer Portal to submit a support ticket requesting BGP peering IP addresses, a BGP authentication key, and the 802.1q VLAN ID number used for the Direct Link connection.

SoftLayer provides a /31 CIDR block of addresses for peering (for example, 10.254.0.104). The SoftLayer peering IP address has the lower numbered IP address (for example, 10.254.0.104), and the customer peering IP address has the higher numbered IP address (for example, 10.254.0.105).

3.4 Configure Local Network BGP Peering

This procedure describes how to configure local network BGP peering. Table 5 lists the configuration

prerequisites.

Table 5) Prerequisites for configuring local BPG peering.

Description

Customer-provided network equipment must be installed in the Equinix colocation data center (or the SoftLayer network PoP location) where the NetApp storage is installed.

Customer-provided network equipment must have the BGP feature licensed and enabled.

There must be administrative access to customer-provided network equipment.

SoftLayer Direct Link cross-connects must be patched to the customer demarcation panel.

Customer network equipment must be patched to the customer demarcation panel with SMF optic cable.

There must be an IP address plan for the local network in the Equinix colocation data center (or the SoftLayer network PoP location) where the NetApp storage is installed (IP CIDR block, subnet, VLAN, and VLAN interface information).

The VLAN ID used by the SoftLayer Direct Link connection must be available.

SoftLayer must have assigned the BGP peering IP addresses between the local network and the SoftLayer network.

There must be an ASN for the local network in the Equinix colocation data center (or the SoftLayer network PoP location).

Note: Private ASNs are supported. The Internet Assigned Numbers Authority (IANA) has designated private ASNs in the range of 64512 through 65535.

There must be a BGP key for the authenticated BGP session between the SoftLayer network and the local network in Equinix.





To configure local BGP peering, complete the following steps:

1. Open a console session to the network switch or router in the Equinix colocation data center (or the SoftLayer network PoP location) and log in with a user account that has administrative rights on the network switch.

2. Configure the VLAN interfaces and the BGP configuration.

Note: The following commands are for Cisco Nexus® (NX-OS) switches. If you are using different

network equipment, refer to your network equipment vendor’s documentation:

config t

vlan <<vlan_ID>>

exit

vrf context <<vrf_name>>

exit

interface vlan <<vlan_ID>>

no shutdown

vrf member <<vrf_name>>

ip address <<cust_peer_address>>/30

ip address <<local_subnet_gateway_address>>/<<CIDR>> secondary

exit

router bgp <<ASN>>

vrf <<vrf_name>>

address-family ipv4 unicast

network <<local_subnet>>/<<CIDR>>

neighbor <<softLayer_peer_address>> remote-as 7224

password 0 <<bgp_key>>


exit

end

copy running-config startup-config

Where:

<<vrf-name>> is the VRF name. As a best practice naming convention, NetApp recommends

embedding the VLAN ID in the VRF name (for example, vrf-400).

<<vlan_ID>> is the VLAN number of the VLAN used by the SoftLayer Direct Link network

connection.

<<cust_peer_address>> is the customer peer address for the SoftLayer Direct Link network

connection.

<<local_subnet_gateway_address>> is the gateway address of the local subnet used by

the NetApp SVM.

<<ASN>> is the ASN of the customer network (which can be private or public).

<<CIDR>> is the CIDR number for the local subnet.

<<softLayer_peer_address>> is the SoftLayer peer address for the SoftLayer Direct Link

network connection.

<<bgp_key>> is a text string used to secure the BGP peering session.

Note: The SoftLayer ASN is 13884.

<<local_subnet>> is the local subnet network.

Figure 3 shows a sample local network configuration.



Figure 3) Sample local network configuration (Cisco® NX-OS).

vrf context vrf-400

vlan 400

interface vlan 400

no shutdown

vrf member vrf-400

no ip redirects

ip address 10.254.0.105/31

ip address 192.168.24.97/28 secondary

router bgp 64514

vrf vrf-400


network 192.168.24.96/28

neighbor 10.254.0.105 remote-as 13884

password 3 c795f21d4db2228d6994ff14ab50f309da01a8c45c416690


3. After the local network BGP configuration has been completed, run the following command to verify the BGP session status:

sv5-sw1# show ip bgp summary

4. Find the peer and verify that the state of the BGP session shows as 1, indicating that the BGP

session is up.

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.254.0.104 4 13884 254336 234469 4029 0 0 01:22:31 1

Note: If the BGP session state shows as Idle, check the BGP configuration on the customer network equipment. Refer to your network equipment vendor for proper BGP troubleshooting commands. SoftLayer support can also assist in troubleshooting BPG sessions.

3.5 Configure NetApp Storage Network Connectivity to SoftLayer Direct Link

This procedure describes how to configure NetApp storage network connectivity to SoftLayer Direct Link.

Table 6 lists the configuration prerequisites.

Table 6) Prerequisites for configuring the NetApp storage network connectivity to SoftLayer Direct Link.

Description

There must be a Windows 8 or Windows Server® 2012 host with the NetApp Data ONTAP PowerShell Toolkit

PowerShell modules installed and configured.

The Windows 8 or Windows Server 2012 host on which the NetApp Data ONTAP PowerShell Toolkit PowerShell modules are installed must be connected to the customer-provided network equipment in the Equinix colocation facility.

A customer-provided NetApp storage cluster must be installed in the Equinix colocation data center (or the SoftLayer network PoP location) where the customer provided-network equipment and SoftLayer Direct Link are deployed.

A minimum of one NetApp storage cluster network port on each cluster node must be patched to the customer-provided network equipment in the Equinix colocation data center (or the SoftLayer network PoP location).

A NetApp storage cluster must be set up and configured correctly, with an IP address accessible from the Windows host.

The local administrator must have access to the NetApp storage cluster.

The VLAN number of the SoftLayer Direct Link network must be available.



Note: This procedure assumes the use of NetApp clustered Data ONTAP. For the Windows PowerShell

® commands that apply to Data ONTAP operating in 7-Mode, refer to the Data

ONTAP PowerShell Toolkit documentation, which is available with the NetApp PowerShell Toolkit download on the NetApp Support website.

To configure NetApp storage connectivity to Direct Link, complete the following steps:

1. Open a Windows PowerShell session on the Windows host and run the following commands to authenticate with the NetApp cluster:

import-module dataontap

connect-nccontroller <cluster_ip>> -Credential <<admin_username>>

Where:

<<cluster_ip>> is the cluster IP address of the NetApp cluster.

<<admin_username>> is the user name of an account that has administrative rights on the

NetApp cluster.

For example, 192.168.1.20 is the cluster IP address, and admin is the user account that has

administrative rights on the NetApp cluster.

2. Provide the password for the user name and click OK.

3. When authentication is successful, the Windows PowerShell session shows the IP address, version, and operating mode of the NetApp cluster.

Name Address Vserver Version

---- ------- ------- -------

192.168.1.20 192.168.1.20 NetApp Release 8.2.1RC2X6 Cluster-

Mode: Wed Dec 18 19:14...

4. Run the following command to list existing network ports on each cluster node, repeating it for each cluster node:

get-ncnetport –Node <<node_name>>

Port PortType Role LinkStatus Node

---- -------- ---- ---------- ----

e0a physical cluster up sv5-cluster1-01

e0b physical cluster up sv5-cluster1-01

e0c physical cluster up sv5-cluster1-01

e0d physical cluster up sv5-cluster1-01

e0e physical data up sv5-cluster1-01

e0f physical data down sv5-cluster1-01

e0g physical data up sv5-cluster1-01

e0h physical data down sv5-cluster1-01

https://support.netapp.com/



e0i physical data up sv5-cluster1-01

e0j physical data up sv5-cluster1-01

e0k physical data down sv5-cluster1-01

e0l physical data down sv5-cluster1-01

e0M physical node_mgmt up sv5-cluster1-01

Where:

<<node_name>> is the name of the cluster node. The node name in this example is sv5-

cluster1-01.

Note: Note the physical interfaces listed under the PortType column and keep them available for use in the next step.

5. Run the following command to create VLAN interfaces, repeating it for each physical port on each cluster node that will be connected to the Direct Link private virtual interface:

New-NcNetPortVlan <<phys_port>> -node <<node_name>> -VlanId <<vlan_ID>>

Where:

<<phys_port>> is the physical port on the cluster node.

<<node_name>> is the name of the cluster node.

<<vlan_ID>> is the VLAN number of the Direct Link network connection.

6. Run the following command to create network failover groups, repeating it for each physical port on each cluster node that will be added to the failover group:

Invoke-NcSsh -Command "network interface failover-groups create -failover-group <<fg_name>> -node

<<node_name>> -port <<vlan_int>>"

Where:

<<fg_name>> is the name of the failover group.

<<node_name>> is the name of the cluster node.

<<vlan_int>> is the name of the VLAN interface on the node created in step 5.

7. Run the following command to list the VLAN interfaces that are members of the failover group created in step 6:

Get-NcNetFailoverGroup -Name <<fg_name>>

Where:

<<fg_name>> is the name of the failover group.

8. Optional: If a VLAN interface is missing, go back to step 6 and add the VLAN interface to the failover group.

9. Run the following command to create an SVM to which the virtual servers will connect:

New-NcVserver –Name <<svm_name>> -RootVolume <<svm_root_vol>> -NameServerSwitch <<ns_switch>> -

RootVolumeSecurityStyle <<root_vol_sec>> -Language <<lang>> -RootVolumeAggregate <<aggr_name>>

Where:

<<svm_name>> is the name of the SVM.

<<svm_root_vol>> is the name of the SVM root volume.

<<ns_switch>> sets name server configuration settings for the SVM. The possible values are

file, ldap, and nis. Select the value that is appropriate for your environment.

<<root_vol_sec>> is the security style of the root volume. The possible values are unix,

nfts, and mixed. Select the value that is appropriate for your environment.

<<lang>> is the language setting for the SVM root volume. Select the value that is appropriate

for your environment.



<<aggr_name>> is the name of the aggregate where the SVM root volume will be created.

10. After the SVM has been created, run the following command to create a NAS-only LIF or a combination NAS and management LIF for the SVM:

New-NcNetInterface –Name <<lif_name>> -Vserver <<svm_name>> -Role data -Node <<node_name>> -Port

<<vlan_int>> -DataProtocols <<protocol_list>> -Address <<lif_ip>> -Netmask <<lif_mask>> -

FirewallPolicy <<fw_policy>> -FailoverGroup <<fg_name>> -AdministrativeStatus up

Where:

<<lif_name>> is the name of the LIF.

<<svm_name>> is the name of the SVM that owns the LIF.

<<node_name>> is the home cluster node of the LIF.

<<vlan_int>> is the name of the VLAN interface created in step 5.

<<protocol_list>> is the list of protocols for the LIF. For NAS-only or combination NAS and

management LIFs, the available values are nfs and cifs.

<<lif_ip>> is the IP address assigned to the LIF. This IP address should be from the CIDR

block assigned to the local subnet for the SVM.

<<lif_mask>> is the netmask of the IP address assigned to the LIF. The netmask value is

derived from the CIDR number for the local subnet for the SVM.

<<fw_policy>> is the firewall policy set on the LIF. For NAS-only LIFs, the value is data. For

combination NAS and management LIFs, the value is mgmt.

<<fg_name>> is the name of the failover group created in step 6.

11. Run the following command to create an iSCSI logical interface for the SVM:

New-NcNetInterface –Name <<lif_name>> -Vserver <<svm_name>> -Role data -Node <<node_name>> -Port

<<vlan_int>> -DataProtocols iscsi -Address <<lif_ip>> -Netmask <<lif_mask>> -FirewallPolicy

<<fw_policy>> -AdministrativeStatus up

Where:

<<lif_name>> is the name of the LIF.

<<svm_name>> is the name of the SVM that owns the LIF.

<<node_name>> is the home cluster node of the LIF.

<<vlan_int>> is the name of the VLAN interface created in step 5.

<<lif_ip>> is the IP address assigned to the LIF. This IP address should be from the CIDR

block assigned to the local subnet for the SVM.

<<lif_mask>> is the netmask of the IP address assigned to the LIF. The netmask value is

derived from the CIDR number for the local subnet for the SVM.

<<fw_policy>> is the firewall policy set on the LIF. For iSCSI LIFs, the value is data.

Note: iSCSI LIFs do not use failover groups. At least two iSCSI LIFs should be created, and any virtual server VMs connected to the iSCSI LIFs should be configured for multipath input/output (MPIO).

12. Repeat steps 9 and 10 for each additional logical interface to be created for the SVM.

13. Run the following command to unlock the default vsadmin user account for the SVM:

UnLock-NcUser -Name vsadmin -Vserver <<svm_name>>

Where:


14. Run the following command to set the password for the default vsadmin user account for the SVM:

Set-NcUserPassword -VserverContext <<svm_name>> -Credential vsadmin



Where:


Note: By default, the SVM password policy requires using a minimum of eight characters and a mix of letters and numbers. In addition, the password cannot repeat any of the previous six passwords.

4 NetApp Private Storage for SoftLayer Testing

This section provides the procedures used to test the NetApp Private Storage for SoftLayer solution and

explains the concepts and guidelines underlying performance testing of the solution.

4.1 Test Procedures

This section provides test procedures for verifying the connection to the SoftLayer Direct Link network,

verifying access to the iSCSI LUN, and verifying connectivity for the iSCSI session and the CIFS and NFS

protocols.

Verify SoftLayer Direct Link Network Connection

This procedure describes how to test the SoftLayer Direct Link network connection. Table 7 provides a

template for the test case details, including prerequisites and the expected outcome.

Table 7) Test case for verifying SoftLayer Direct Link network connection.

Test Case Details

Test number NPSSLBGP-1

Tester

Date

Test prerequisites Physical network connectivity has been established from SoftLayer to the NetApp storage through a Direct Link network connection.

The network interface for the NetApp storage has been configured to use the Direct Link network connection.

A Windows Server 2012 OS virtual or bare-metal server has been deployed to the SoftLayer private network that is connected to Direct Link, and the server is operational.

The virtual server is configured with a virtual network interface to communicate with the NetApp storage.

Local administrator access to the virtual server has been obtained.

There is a BGP configuration on the customer-provided network equipment in the colocation facility.

There is an Internet-connected Windows host with an Internet browser and an RDP client installed.



Test Case Details

Expected outcome The SoftLayer Direct Link network is properly configured between the virtual server VM instance and the NetApp storage, the ping test succeeds (0% packet loss), and the network information is displayed as shown in the following example:

Pinging 192.168.1.102 with 32 bytes of data:

Reply from 192.168.1.102: bytes=32 time=2ms TTL=251




Ping statistics for 192.168.1.102:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 1ms, Maximum = 2ms, Average = 1ms

Test results Passed/failed

Comments

Test Procedure

1. Using an Internet browser, log in to the SoftLayer Customer Portal. Click Devices > Device List.




2. Document the public IP address of the virtual or bare-metal server deployed to the private network.

Click the icon.

3. Select the Show Password checkbox to display the local administrator password for the virtual or bare-metal server.



4. Start the Remote Desktop Client on the Windows host. Enter the public IP address of the virtual or bare-metal server that was deployed and click Connect.

5. Before the RDP session is established, a security prompt warns you that the remote connection is not trusted. Click Connect.

6. The remote desktop client prompts you for credentials to log in to the virtual or bare-metal server. Provide the following information and then click OK:

Username: Provide the user name of the local administrator account on the VM.

Password: Provide the password of the local administrator account on the VM.

Remember My Credentials: This option allows you to save your credentials.



7. When the RDP client displays another security prompt, click Yes.

8. After successful authentication, the RDP client displays the Server Manager or desktop of the virtual or bare-metal server.

9. Open a command prompt and enter the following command to perform a ping test against one of the

network interfaces on the NetApp storage (in this example, 192.168.1.102):

ping 192.168.1.102



Verify iSCSI Session Connectivity

This procedure describes how to test the iSCSI session connectivity. Table 8 provides a template for the

test case details, including prerequisites and the expected outcome.

Table 8) Test case for verifying iSCSI session connectivity.

Test Case Details

Test number NPSSLiSCSI-1

Tester

Date




The virtual or bare-metal server is configured with a network interface to communicate with the NetApp storage.

There is a BGP configuration on the customer-provided network equipment in the Equinix colocation data center (or the SoftLayer network PoP location).


The NetApp storage has been licensed for the iSCSI protocol.

The iSCSI service on the NetApp SVM has been started.

A NetApp SVM has been created on the NetApp storage cluster with an iSCSI LIF.

Local administrator access to the virtual or bare-metal server has been obtained.

Expected outcome An iSCSI session is established from the virtual or bare-metal server to the NetApp SVM iSCSI LIF, as shown in step 14 of the test procedure.


Comments



Test Procedure



Click the icon.




9. On the SoftLayer virtual or bare-metal server, use the iSCSI Control Panel applet to view the iSCSI Initiator Properties dialog box. Click the Discovery tab.



10. In the Discovery tab, click the Discover Portal button.

11. In the Discover Target Portal dialog box, type the IP address of the iSCSI LIF on the NetApp storage

VM (in this example, 192.168.1.26). Click OK.



12. Back in the Discovery tab of the iSCSI Initiator Properties dialog box, verify that the IP address of the iSCSI LIF appears in the list of target portals. Click the Targets tab.



13. In the Targets tab, click Connect to establish the iSCSI session.

14. In the Connect to Target dialog box, click OK.



15. Back in the Targets tab of the iSCSI Initiator Properties dialog box, verify that the status of the iSCSI

target shows as Connected. Click OK to close the dialog box.



Verify iSCSI LUN Access

This procedure describes how to test the access to the iSCSI LUN. Table 9 provides a template for the


Table 9) Test case for verifying iSCSI LUN access.

Test Case Details

Test number NPSSLiSCSI-2

Tester

Date




The virtual or bare-metal server is configured with a network interface to communicate with the NetApp storage.





The NetApp storage has been licensed for the iSCSI protocol.

The iSCSI service on the NetApp SVM has been started.


The local administrator has access to the virtual or bare-metal server.

An iSCSI session is established from the virtual or bare-metal server to the NetApp storage SVM iSCSI LIF.

The NetApp Data ONTAP PowerShell Toolkit is installed on the virtual or bare-metal server.

Expected outcome An iSCSI LUN on the NetApp SVM can be mounted and accessed as shown in step 19 of the procedure.


Comments



Test Procedure



Click the icon.






9. After successful login, open a Windows PowerShell session on the Windows virtual or bare-metal server and run the following commands to connect to the NetApp SVM with the NetApp PowerShell Toolkit:

Set-ExecutionPolicy Unrestricted

Import-Module DataONTAP

Connect-NcController <<mgmt_lif>> -Credential vsadmin

Where:

<<mgmt_lif>> is the IP address or DNS name of the SVM.



10. At the authentication prompt, provide the password and click OK.

11. After successful authentication, the connection to the SVM is displayed. The following example shows

a connection to an SVM (sv5-csg-01) with the management LIF IP address of 192.168.1.27:

Name Address Vserver Version

---- ------- ------- -------

192.168.1.27 192.168.1.27 sv5-csg-01 NetApp Release 8.2.1RC2X6 Cluster-

Mode: Wed Dec 18 19:14...

Note: The text in this example is wrapped, and the version of Data ONTAP might be different from the version used in your environment.

12. Run the following command to verify that the iSCSI session created in the previous procedure

(NPSSoftLayeriSCSI-1) is present:

Get-NcIscsiConnection

ConnectionId InterfaceName RemoteIpAddress ConnectionState Vserver

------------ ------------- --------------- --------------- -------

1 lif2 10.0.10.170 full_feature_phase sv5-csg-01

13. Run the following command to create a volume on the SVM where the LUN will be located:

New-NcVol -Name <<vol_name>> -Aggregate <<aggr_name>> –Size <<vol_size>> -JunctionPath <<path>> -

Language en_US -Type rw -State online -SecurityStyle unix

Where:

<<vol_name>> is the name of the volume.

<<aggr_name>> is the name of the aggregate.

<<path>> is the junction path.

<<vol_size>> is the size of the volume.

14. Run the following command to create a windows_2008 LUN on the volume created in step 13:

New-NcLun -Path /vol/<<vol_name>>/<<lun_name>> -Size <<lun_size>> -OsType windows_2008

Where:


<<lun_name>> is the name of the LUN.

<<lun_size>> is the size of the LUN.

Note: The OS type of the LUN might change based on the OS version used by the virtual server VM that is mapped to this LUN.



15. Run the following command to create an interface group (igroup) that will be used to map the LUN to the virtual server VM:

New-NcIgroup -Name <<igroup_name>> -Protocol iscsi -Type windows

Add-NcIgroupInitiator <<igroup_name>> <<iqn>>

Where:

<<igroup_name>> is the name of the igroup.

<<iqn>> is the iSCSI qualified name (IQN) string of the iSCSI software initiator on the virtual

server VM.

16. Run the following command to map the LUN created in step 14 to the igroup created in step 15:

Add-NcLunMap /vol/<<vol_name>>/<<lun_name>> <<igroup_name>>

Where:

<<igroup_name>> is the name of the igroup.

<<vol_name>> is the name of the volume where the LUN is located.

<<lun_name>> is the name of the LUN.

17. Run the following command to enumerate the LUN that has been mapped to the host and its Windows disk ID number:

Start-NcHostDiskRescan

Get-NaHostDisk -Uninitialized

18. Run the following command to initialize the Windows disk, set the Windows disk online, create a Windows volume on the disk, and assign a mount point to the Windows disk:

Initialize-NcHostDisk <<disk_id>>

Set-NcHostDisk <<disk_id>> -Online

New-NcHostVolume <<disk_id>> <<drive_letter>>

Where:

<<disk_id>> is the Windows disk ID number.

<<drive_letter>> is the mount point.

Note: Answer Y when prompted to bring the Windows disk online.

19. Run the following command to navigate to the new iSCSI LUN that has been mapped to the Windows virtual or bare-metal server:

cd <<drive_letter>>

Where:

<<drive_letter>> is the mount point assigned to the new iSCSI LUN.



Verify CIFS Protocol Connectivity

This procedure describes how to test the CIFS protocol connectivity. Table 10 provides a template for the


Table 10) Test case for verifying CIFS protocol connectivity.

Test Case Details

Test number NPSSLCIFS-1

Tester

Date




The virtual or bare-metal server is configured with a network interface to communicate to the NetApp storage.

A user account with local administrator rights has been created on the virtual or bare-metal server.



The NetApp storage has been licensed for the CIFS protocol.


A user account with local administrator rights has been created on the NetApp SVM.

The NetApp Data ONTAP PowerShell Toolkit is installed on the virtual or bare-metal server.

A Microsoft Active Directory® domain controller is available, and a domain user

account with domain administrator rights has been created.

The CIFS service is set up on the NetApp SVM and started.

A NAS data LIF has been created on the NetApp SVM.

An aggregate has been created and assigned to the NetApp SVM.

The time difference between the NetApp cluster, the Active Directory domain, and the virtual or bare-metal server has been verified as less than 5 minutes.

Expected outcome A drive letter is mapped to a CIFS share on the NetApp SVM, as shown in steps 14 and 15 of the test procedure.


Comments



Test Procedure

1. Using an Internet browser, log in to the SoftLayer Customer Portal and click Devices > Device List.


Click the icon.





4. Start the remote desktop client on the Windows host. Enter the public IP address of the virtual or bare-metal server that was deployed and click Connect.





9. After successful login, open a Windows PowerShell session on the virtual server Windows VM and run the following commands to connect to the NetApp SVM with the NetApp PowerShell Toolkit:

Set-ExecutionPolicy Unrestricted

Import-Module DataONTAP

Connect-NcController <<mgmt_lif>> -Credential vsadmin

Where:

<<mgmt_lif>> is the IP address or DNS name of the SVM.

10. At the authentication prompt, provide the password and click OK.



11. Run the following command to create a flexible volume on the aggregate assigned to the SVM:

new-ncvol –Name <<vol_name>> -Aggregate <<aggr_name>> -JunctionPath <<path>> -size <<vol_size>> -

state online -type rw –language en_US

Where:


<<aggr_name>> is the name of the aggregate where the volume is located.

<<path>> is the junction path to the volume.


12. Run the following command to create a CIFS share mapped to the volume that was created in step 11:

Add-NcCifsShare –Name <<share_name>> -path <<path>>

Where:

<<share_name>> is the share name of the volume.

<<path>> is the junction path of the volume.

13. On the SoftLayer virtual or bare-metal server, open a Windows PowerShell or Windows command shell session and run the following command to map a drive to the CIFS share created in step 12:

net use <<drive_letter>>: \\<<svm_name>>\<<share_name>> /user:<<username>>@<<domain>>

/persistent:yes

Enter the password for '<<username>>@<<domain>>' to connect to '<<svm_name>>':

Where:

<<drive letter>> is the drive letter to be mapped to the CIFS share.

<<svm_name>> is the name of the SVM where the CIFS share is hosted.

<<share_name>> is the name of the CIFS share on the SVM.

<<username>> is the user name of the user account that has permissions on the CIFS share.

<<domain>> is the name of the Active Directory domain (for example, csg.netapp.com).

14. Verify that the drive letter is mapped, as indicated by the following output of the command in step 13:

The command completed successfully.

15. Run the following command to navigate to the mapped CIFS volume:

cd <<drive_letter>>

Where:

<<drive_letter>> is the drive letter mapped to the CIFS volume.



Verify NFS Protocol Connectivity

This procedure describes how to test the NFS protocol connectivity. Table 11 provides a template for the


Table 11) Test case for verifying NFS protocol connectivity.

Test Case Details

Test number NPSSLNFS-1

Tester

Date

Test prerequisites Physical network connectivity has been established from SoftLayer to the NetApp storage through a SoftLayer Direct Link network connection.


A Linux virtual or bare-metal server has been deployed to the SoftLayer private network that is connected to Direct Link, and the server is operational.

The virtual or bare-metal server is configured with a network interface to communicate to the NetApp storage.



There is an Internet-connected Windows or Linux host with an Internet browser and an SSH client installed.

The NetApp storage has been licensed for the NFS protocol.

The NFS service is set up on the NetApp SVM and is started.

A NAS data LIF has been created on the NetApp SVM.

An aggregate has been created and assigned to the NetApp SVM.

An Linux virtual or bare-metal server is up and running in the SoftLayer private server connected to Direct Link.

Local administrator access to the NetApp SVM has been obtained.

Expected outcome An NFS export on the NetApp SVM is mounted to the Linux virtual or bare-metal server and can be accessed, as shown in step 9 of the test procedure.


Comments

Test Procedure

1. Log in to the storage console of the SVM by using an SSH client (for example, PuTTY) with a user account that has administrative access to the NetApp SVM.

2. Run the following command to create an NFS export rule for the default NFS policy:

export-policy rule create -policyname default -clientmatch 0.0.0.0/0 -rorule any -rwrule any -

ruleindex 1

3. Run the following command to create an NFS export policy:

export-policy create -policyname <<policy_name>>



Where:

<<policy_name>> is the name of the export policy.

4. Run the following command to create NFS export rules for the policy created in step 3:

export-policy rule create -policyname <<policy_name>> -ruleindex 1 -protocol nfs -clientmatch

0.0.0.0/0 -rwrule any -rorule none -anon 65534 -allow-suid true -allow-dev true

Where:

<<policy_name>> is the name of the NFS policy.

Note: This command creates an NFS export policy rule with an index of 1. The rule enables all NFS access and access from all clients. It enables read-write access for all clients and read-only access for no clients. Anonymous users are mapped to nobody (65534). The rule enables modification of the set owner user ID up on execution (SUID) and set group ID up on execution file permissions and allows the creation of devices.

5. Run the following command to create a flexible volume on the aggregate assigned to the SVM:

volume create -volume <<vol_name>> -aggregate <<aggr_name>> -junction-path <<path>> -size

<<vol_size>> -state online -type RW –language en_US –policy <<policy_name>> -unix-permissions 777

Where:


<<aggr_name>> is the name of the aggregate where the volume is located.



<<policy_name>> is the NFS export policy assigned to the volume.

6. From an Internet-connected Windows or Linux host, open an SSH client and log in to the virtual server Linux VM, providing the IP address and the administrator user name and password for the virtual server Linux VM.

7. Run the following command to create an NFS mount point directory:

mkdir /mnt/<<mount_point>>

Where:

<<mount_point>> is the name of the mount point directory.

8. Run the following command to mount the exported volume:

mount –t nfs <<nfs_lif>>:<<path>> /mnt/<<mount_point>>

Where:

<<nfs_lif>> is the IP address of the NAS data LIF on the SVM.


<<mount_point>> is the name of the mount point directory.

9. Verify that the NFS export is mounted by navigating to the volume through the mount point.

cd /mnt/<<mount_point>>

pwd

/mnt/<<mount_point>>

4.2 Performance Test Guidelines

The concepts underlying performance testing for the NetApp Private Storage for SoftLayer solution are

similar to those for performance testing in other environments. The following sections describe



considerations for conducting performance testing in the NetApp Private Storage for SoftLayer solution

environment.

Goals of Performance Testing

Performance tests are used to validate the performance of the storage, network, and computing

resources, given a specific workload that is an estimate of a real-world workload.

All architectures have limits to their performance. The goal of performance testing is not to see how much

load you can put in the environment before things break. Instead, the goal is to follow an iterative,

deliberate process that results in data that can be plotted and analyzed so that architects can anticipate

performance based on a given workload (that is, performance curves).

NetApp Storage Considerations for Performance Testing

The considerations for sizing NetApp storage are the same in the NetApp Private Storage for SoftLayer

solution architecture as in typical deployments of NetApp storage. NetApp storage requires the following

considerations:

Number and type of NetApp controllers. Are the number and type of controllers used in the testing appropriate for the performance testing?

Number and type of disks in the aggregates. Do the number and types of disks in the aggregate used in the testing have enough IOPS and storage capacity for the testing?

NetApp Flash Cache™

caching. Are Flash Cache adapters installed in the storage controller nodes?

Cluster node network connectivity. What is the bandwidth of network connections (1GbE or 10GbE), and how many connections are used to connect the storage to the network equipment in the colocation facility that is connected to the SoftLayer cloud?

Network Equipment Considerations for Performance Testing

The considerations for the network equipment in the NetApp Private Storage for SoftLayer solution

architecture are the same as those in typical network environments. The network equipment requires the

following considerations:

Available CPU and memory. Does the switch that is being used have enough resources to support the performance testing? Adding more workload to an oversubscribed network switch might contribute to invalid performance testing results.

Network ports used. What is the bandwidth of network connections (1Gb/sec or 10Gb/sec), and how many connections are used to connect to the storage and to SoftLayer? Is enough bandwidth available to accommodate a performance test?

SoftLayer Considerations for Performance Testing

It is very important to understand how the components of the SoftLayer cloud can affect performance

testing. The following consideration applies to the SoftLayer cloud:

SoftLayer Direct Link network connection. Is there enough bandwidth available to accommodate performance testing? Contention for network bandwidth can affect performance testing results. Be sure there is enough network bandwidth to support the testing.

Load-Generation and Monitoring Tools Used for Performance Testing

The load-generation and monitoring tools used for performance testing with the NetApp Private Storage

for SoftLayer solution architecture are the same as those used in typical NetApp storage environments.

Consider the following guidelines:



Know what tool you will use. Each tool has advantages and disadvantages. Understanding the correct tool for your performance testing can provide more accurate test results.

Know your workload. What kind of workload will you be testing? Understanding the I/O patterns of the workloads you are testing helps make it possible to configure the load generation tool correctly so that the testing can accurately model the performance.

Monitor the stack. Implement monitoring for the computing, network, and storage resources so that bottlenecks can be identified. Collect performance data from each stack so that analysis can provide a more complete picture of how the NetApp Private Storage for SoftLayer solution architecture is performing.

Reference

The following reference was used in this TR:

SoftLayer KnowledgeLayer http://knowledgelayer.softlayer.com/

http://knowledgelayer.softlayer.com/



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.

Copyright Information

Copyright © 1994–2014 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).

Trademark Information

NetApp, the NetApp logo, Go Further, Faster, ASUP, AutoSupport, Campaign Express, Cloud 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, SANtricity, SecureShare, Simplicity, Simulate ONTAP, Snap Creator, SnapCopy,

SnapDrive, SnapIntegrator, SnapLock, SnapManager, SnapMirror, SnapMover, SnapProtect,

SnapRestore, Snapshot, SnapValidator, SnapVault, StorageGRID, Tech OnTap, Unbound Cloud, and

WAFL are trademarks or registered trademarks of NetApp, Inc., in the United States and/or other

countries. A current list of NetApp trademarks is available on the Web at

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

Cisco and the Cisco logo are trademarks of Cisco in the U.S. and other countries. All other brands or

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

such. TR-4326-1014

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

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

technical report netapp private storage for softlayervirtual machines (vms) or bare-metal computing...

Documents