Implementation Guide for EMC for VSPEX Private Cloud Environments. CloudLink Solution Architect Team

Transcription

1 VSPEX IMPLEMENTATION GUIDE CloudLink SecureVSA Implementation Guide for EMC for VSPEX Private Cloud Environments CloudLink Solution Architect Team Abstract This Implementation Guide describes best practices for the design and architecture of CloudLink SecureVSA into VSPEX for private cloud environments enabling multi-tenant, agentless, storage layer encryption. April 2014

2 Contents Copyright 2014 All Rights Reserved. CloudLink is a registered trademark of CloudLink Technologies (formerly AFORE Solutions, Inc.). All other trademarks, trade names, service marks and logos referenced herein belong to their respective companies. EMC 2, EMC, the EMC logo, VSPEX are registered trademarks or trademarks of EMC Corporation in the United States and other countries. 2

3 Contents Contents Chapter 1 Introduction 4 Purpose of this guide...4 Business value...4 Scope...5 Audience...5 Terminology...5 Product description...5 Solution tested...7 Chapter 2 SecureVSA Design Planning 8 Chapter 3 Implementation Process Overview 15 Pre-deployment Deployment Chapter 4 Key Store Configuration 17 Selecting a key store for the SecureVSA deployment Configuring Active Directory as a key store RSA Data Protection Manager configuration Chapter 5 Installation and Configuration 20 Process overview Deploying CloudLink Center Deploying vnodes for Datastore mode Deploying a vnode for NAS mode Chapter 6 Testing and Verification 51 Appendix A Pre-Deployment Checklist 52 Appendix B Troubleshooting 61 Appendix C CLOUDLINK Support Contact Information 62 3

4 Chapter 1: Introduction Chapter 1 Introduction Purpose of this guide This Implementation Guide assists with the implementation of CloudLink SecureVSA (Secure Virtual Storage Appliance) into VSPEX private cloud environments. Business value SecureVSA s data-at-rest encryption and data-in-motion encryption solution enables customers to cost-effectively address compliance requirements and security best practices while maximizing use of storage resources. Implementing SecureVSA as part of a VSPEX private cloud environment offers many benefits. VSPEX optimization. SecureVSA data-at-rest encryption is specifically designed for virtualized environments providing the optimal solution for the VSPEX private cloud deployments. This Implementation Guide walks partners step-by-step through the deployment, configuration, sizing, and tuning processes to ensure optimal performance. Simple deployment. As an agentless solution, SecureVSA alleviates the challenge of installing and managing software on individual virtual machines. IT personnel can quickly and easily deploy data encryption when and where needed, all while managing and reporting from a central security management console. The net impact is lower TCO and improved business agility. Granular encryption. Unlike other approaches that force encryption of the entire storage infrastructure, SecureVSA enables granular encryption on a per-application, per-tenant basis. SecureVSA s approach makes efficient resource use of the storage array by encrypting only the application data that needs to be encrypted. Granular key management policy. For multi-tenant clouds that include individual business lines within an organization that requires data isolation and encryption such as departments, agencies, or groups SecureVSA supports unique encryption keys for each individual entity, placing key control in the hands of data owners. Data-at-rest encryption for both new and existing storage arrays. SecureVSA can be used as a data-at-rest encryption platform for new VSPEX-based storage environments. SecureVSA can also be used to encrypt existing storage arrays that do not support encryption natively, such as EMC Clarion, VNX, VMAX, vblock, and so on. Hybrid cloud support. SecureVSA is designed to protect customer data regardless of its location, whether that is an on-premise VSPEX private cloud implementation or one or more public cloud environments. SecureVSA provides customers with a single, extensible data encryption policy management capable of addressing all of their data-at-rest encryption requirements. 4

5 Chapter 1: Introduction Compliance and regulatory standards support. SecureVSA meets critical requirements for internal and external compliance programs, and standards such as HIPAA, PCI, CSA, and NIST, through implementation of a data-at-rest encryption solution. Data remanence support. SecureVSA ensures that data remanence requirements are met. Should servers or applications be decommissioned (terminated) in the future, any related data will be inaccessible. Scope This Implementation Guide provides a brief overview of SecureVSA, design and architecture considerations for various deployment scenarios, and installation instructions. This Implementation Guide provides partners with the knowledge necessary to customize the SecureVSA configuration for a particular customer s environment and application requirements, as necessary. Audience Users of this document must be knowledgeable about VMware, EMC Next-Generation VNX series storage systems, and networking concepts. At a minimum, a high-level understanding of how SecureVSA functions is also required. Terminology This Implementation Guide uses the following terminology. Table 1. Term CHAP Terminology Description Challenge-Handshake Authentication Protocol. CloudLink Center CloudLink Gateway CloudLink vnode SecureVSA RSA DPM Management console for SecureVSA that integrates with encryption key stores. See CloudLink Center. Software virtual appliance that provides encrypted storage. Software-defined storage layer encryption solution for virtualized and cloud environments. Components of this solution described in this guide include CloudLink Center and CloudLink vnodes. RSA Data Protection Manager. Product description SecureVSA is a virtual storage appliance for virtualized and cloud environments that provides a software encryption layer between virtualized applications and physical storage. SecureVSA provides an agentless encryption solution for virtual machines, 5

6 Chapter 1: Introduction regardless of the underlying storage array environment (such as Clarion, VNX, or legacy storage arrays) that is completely transparent and requires no modification to the virtual machines and applications using SecureVSA encrypted storage. SecureVSA supports two deployment modes: encrypted datastore mode encrypted NAS mode CloudLink Center includes advanced key management including per-tenant unique keys and key rotation. CloudLink Center also provides a variety of key storage options, including Microsoft Active Directory or, for advanced protection, RSA Data Protection Manager. SecureVSA encrypted datastore mode SecureVSA s encrypted datastore mode provides encrypted storage for hypervisor use (VMware vsphere and Microsoft Hyper-V). In this mode, virtual machines (VM) associated with the encrypted datastore can be thought of as running in an encrypted container from the perspective of the VMDK files associated with the VM that resides in the encrypted datastore. The entire VM can reside within the encrypted datastore. Alternatively, administrators can associate just the data volumes with the encrypted datastore, and the operating system and application volume can be run out of a standard datastore. Administrators can combine or aggregate volumes into a single large datastore. Alternatively, each attached volume can be encrypted with unique encryption keys and shared as individual datastores. The benefit of encrypted datastore mode is that it is completely transparent to the VMs running with the encrypted datastore, requiring no changes or modifications to virtualized servers and applications (agentless). This mode also offers the benefits of supporting standard VMware features such as DRS, HA, FT, and Storage vmotion. SecureVSA encrypted NAS mode SecureVSA s encrypted NAS mode provides encrypted storage at the network level for servers and end users. Like encrypted datastore mode, encrypted NAS mode is an agentless data-at-rest encryption solution, with the encryption being completely transparent to the server and application attaching or mapping to the network 6

7 Chapter 1: Introduction attached storage. Administrators can combine or aggregate volumes into a single large network share. Alternatively, each attached volume can be encrypted with unique encryption keys and shared individually. CloudLink Center integration for key stores CloudLink Center supports the ability to use either Microsoft Active Directory or RSA Data Protection Manager (DPM) as a key store for production deployments. Optionally, a local key store can be used for trials and evaluations. RSA DPM is an integrated security solution that delivers extremely efficient and comprehensive data protection. RSA DPM is designed to ensure that large numbers of keys are preserved, across geographic and organizational boundaries, without risks of key loss or compromise. It distributes encryption keys when and where they are needed, protecting them in transit and ensuring they are provided only to authenticated and authorized entities. SecureVSA features and benefits summary Agentless encryption model Transparent to virtualized servers and applications Central management Support for on-premise, hybrid, and multi-cloud deployments Support for partial encryption Spans heterogeneous storage environments Support for RSA Data Protection Manager and Active Directory key stores Highly scalable Simplified deployment and management FIPS validation Solution tested SecureVSA was tested and validated in the EMC VSPEX lab using the same storage and VM configuration defaults that were detailed in the reference architecture described in the Proven Infrastructure Guide: EMC VSPEX Private Cloud, VMware vsphere 5.5 for up to 1,000 Virtual Machines document. For completeness, the SecureVSA design described in this guide is configured to support and showcase both the encrypted datastore and NAS implementation models. Partners and customers can choose the appropriate deployment model that best meets their specific requirements. 7

8 Chapter 3: Implementation Process Overview Chapter 2 SecureVSA Design Planning SecureVSA is designed and implemented as an overlay for the EMC VSPEX private cloud reference architecture described in the Proven Infrastructure Guide: EMC VSPEX Private Cloud, VMware vsphere 5.5 for up to 1,000 Virtual Machines document. For solution consistency, the SecureVSA design uses the same sizing and profiling data and tools as the reference architecture. The EMC VSPEX private cloud reference architecture is available at VSPEX for Private Cloud Reference Architecture. This Implementation Guide refers to the reference architecture as the VSPEX for private cloud reference architecture or reference architecture. The reference architecture has the following characteristics that are important for SecureVSA designs. VNX configuration for block versus file (NFS) access The VNX storage array supports both block and file access to the VMware vsphere virtual environment. For SecureVSA deployments, block access to the VNX storage array provides significantly higher performance than file access. Once the VNX storage array has been configured to support block access, the next decision is to determine whether raw data mapping (RDM) or VMFS access should be configured for SecureVSA. Note: SecureVSA supports both physical and virtual RDM, with virtual RDM recommended in order to preserve VMware snapshot functionality. Advantages of vrdm versus VMFS Higher performance when the SecureVSA is configured as an iscsi datastore (approximately 12,000 IOPS) VMFS requires SecureVSA to be configured as an NFS datastore, which introduces additional overhead and limits performance (approximately 3,000 IOPS) Disadvantages of vrdm versus VMFS vrdm requires the entire LUN to be assigned to SecureVSA VMFS can easily be used to create the desired SecureVSA datastore size by adding one or more virtual disks to SecureVSA New SecureVSA datastores can be created independently of storage administrators streamlining management When performance is the primary consideration, we recommend implementing RDM and SecureVSA iscsi datastores. When ease of administration and flexibility in terms of the size of datastores to be provisioned are priorities, we recommend VMFS and SecureVSA NFS datastores. This Implementation Guide describes a VMFS and SecureVSA NFS datastore configuration. 8

9 Solution hardware Chapter 3: Implementation Process Overview EMC VNX5400 array provides storage to vsphere hosts for up to 300 virtual machines EMC VNX5600 array provides storage to vsphere hosts for up to 600 virtual machines EMC VNX5800 array provides storage to vsphere hosts for up to 1,000 virtual machines Version of VMware supported VMware vsphere 5.1 and 5.5 with VMFS for disk configuration. Client virtual machine characteristics Characteristic Virtual machine operating system Value Microsoft Windows Server 2012 Data Center Edition Virtual processors per virtual machine 1 RAM per virtual machine Available storage capacity per virtual machine 2 GB 100 GB IOPS per virtual machine 25 I/O pattern Random I/O read/write ratio 2:1 Storage allocation table for block data Configuration Number of pools Number of 15K SAS drives per pool Number of flash drives per pool Number of LUNs per pool LUN size (TB) 300 virtual machines Total x 7 TB LUNs 2 x 3 TB LUNs 600 virtual machines Total x 7 TB LUNs 2 x 6 TB LUNs 1000 virtual machines Total x 7 TB LUNs Note: Each virtual machine occupies 102 GB in this solution, with 100 GB for the operating system and user 9

10 Chapter 3: Implementation Process Overview space, and a 2 GB swap file. Validation test profile Profile characteristic Value Number of virtual machines 300/600/1,000 Virtual machine OS Windows Server 2012 Data Center Edition Processors per virtual machine 1 Number of virtual processors per physical CPU core RAM per virtual machine Average storage available for each virtual machine Average IOPS per virtual machine Number of LUNs or NFS shares to store virtual machine disks Disk and RAID type for LUNs or NFS shares 4 2 GB 100 GB 25 IOPS 62 or 63 per LUN or NFS share RAID 5, 600 GB, 15k rpm, 3.5 inch SAS disks SecureVSA design considerations From the perspective of the SecureVSA design described in this Implementation Guide, the following summarizes the most important VSPEX for private cloud reference architecture data points: total number of VMs to be supported dictates VNX model used number of pools number of LUNs per pool size of LUNs number of VMs supported on a per LUN basis VM IOPS performance profile baseline The SecureVSA design is based on a VSPEX for private cloud 600 VM configuration, which includes 4 ESXi hosts and a VNX 5600 storage array. This Implementation Guide provides detailed guidance that administrators can use to scale the SecureVSA design as required to meet a specific deployment requirement. In addition, the SecureVSA design is based on a model where 50 percent of the application data requires data-at-rest encryption. If a higher or lower percentage of data encryption is required, administrators can refer to information later in this chapter that explains how to adapt the SecureVSA design appropriately. 10

11 Chapter 3: Implementation Process Overview The VSPEX for private cloud reference architecture for up to 600 VMs has the following characteristics that apply to the SecureVSA design: 5 pools 2 LUNs per pool (10 total) 8 x 7 TB per LUN (56 TB) 2 x 6 TB per LUN (12 TB) 62 VMs per LUN The VSPEX architecture used for the purpose of this Implementation Guide includes 4 ESXi hosts with 1 ESXi host dedicated to hosting infrastructure components such as AD, DNS, and so on. The three remaining hosts were dedicated to hosting VM workloads (50 VMs per host). Each ESXi host is assigned a LUN from which a datastore is created from (7 TB in size) to support 50 VMs on each host. This SecureVSA design assumes that 50 percent of the workload VMs requires data-at-rest encryption, which translates to 2.5 TB of encrypted storage (25 VMs x 100 GB of allocated disk space). An additional 1 TB of storage is allocated to accommodate Storage vmotion and DRS capacity balancing operations. These assumptions result in a total of 3.5 TB of encrypted storage per host. This SecureVSA design assumes no data-at-rest encryption requirements for the infrastructure components, and allocates 7 TB of standard datastore storage to the host for the management infrastructure VMs. Based on this configuration, the following SecureVSA design is implemented: 1 CloudLink Center for management of the CloudLink vnodes. CloudLink Center is installed on the same ESXi host used to host other infrastructure components such as AD, DNS, and so on. 3 vnodes configured in encrypted datastore mode, each provisioned to provide 3.5 TB of encrypted storage. Each CloudLink vnode is installed on the ESXi hosts used to support VM workloads. 1 vnode configured in encrypted NAS mode to provide 1 TB of encrypted storage. This CloudLink vnode also resides on one of the ESXi hosts used to support VM workloads. The following diagram shows a high-level representation of the SecureVSA design. Note that the SecureVSA node representing CloudLink Center is referred to as the CloudLink Gateway. 11

12 Chapter 3: Implementation Process Overview SecureVSA performance sizing SecureVSA is licensed to support up to 10 TB of encrypted storage per CloudLink vnode. However, the allocated size of encrypted storage per CloudLink vnode depends on the number of VMs allocated per CloudLink vnode and the individual VMs performance requirements from an IOPS and latency perspective. Measuring performance is always subjective as many factors can influence the performance seen in labs versus production environments, and even between two nearly identical environments. As a baseline reference point, a single CloudLink vnode can support up to 3000 IOPS, assuming the network, compute and storage resources are available to support the CloudLink vnode s resource requirements and that a typical VNX storage configuration has been implemented (that is, a combination of SSD and SAS drives). Performance will vary, so this baseline information is as guidance only, with the implemented solution validated using the intended environment. Notes: For environments that require a higher number of IOPS, we recommend configuring the VNX storage array to provide vrdm access to the SecureVSA and iscsi datastores. VSPEX testing has demonstrated throughput speeds of up to 12,000 IOPS for this configuration. SecureVSA iscsi datastore mode is supported only when the VNX storage array is configured for RDM access. VNX with VMFS access is only supported with SecureVSA NFS datastores. Reference virtual machine resources Resource Value for reference virtual machine Relationship between requirements and equivalent reference virtual machines CPU 1 Equivalent reference virtual machines = resource requirements Memory 2 Equivalent reference virtual machines = 12

13 Chapter 3: Implementation Process Overview (resource requirements)/2 IOPS 25 Equivalent reference virtual machines = (resource requirements)/25 Capacity 100 Equivalent reference virtual machines = (resource requirements)/100 Calculating resource consumption of a SecureVSA software appliances Server resources Storage resources Application vcpus Memory (GB) IOPS Capacity (GB) Equivalent reference VMs CloudLink Center SecureVSA vnode Resource Requirements Equivalent reference VM Resource Requirements Equivalent reference VM N/A * N/A * Note: This value is the storage capacity of the CloudLink vnode itself and does not include allocated encrypted storage. 13

14 Chapter 3: Implementation Process Overview Calculating reference VM IOPS requirements for SecureVSA A CloudLink vnode supports 3000 IOPS, on average, when implemented using VMFS disk and configured as an NFS datastore IOPS translates to 120 equivalent reference VMs in total per CloudLink vnode (3000/25 = 120). Based on this average, use the following worksheet to calculate the number of reference VMs that can be supported by a particular CloudLink vnode from an IOPS perspective. Based on the number of VMs requiring encrypted storage and the IOPS required, the number of implemented CloudLink vnodes to be implemented can be adjusted. Storage resources Allocated storage SecureVSA supports up to 120 reference VMs per vnode Application IOPS GB Equivalent reference VMs Application #1: custom built app Application #2: point of sale system Application #3: decision support database Application #4: Application #5: Application #6: Resource requirements Equivalent reference VM Resource requirements Equivalent reference VM Resource requirements Equivalent reference VM Resource requirements Equivalent reference VM Resource requirements Equivalent reference VM Resource requirements Equivalent reference VM N/A N/A N/A N/A N/A N/A Total number of reference VMs must be below

15 Chapter 3: Implementation Process Overview Chapter 3 Implementation Process Overview This section provides an overview of the implementation process from pre-deployment preparation to deployment verification. Pre-deployment 1. Prepare design. Complete the checklist provided in Appendix A: Pre-Deployment Checklist, which includes information such as the volume of data under management, the applications accessing the data, and the location of the data in the network. 2. Design solution. Using the VSPEX for private cloud reference architecture, engineer the system resources based on actual workloads in place of VSPEX reference workloads. For information about breaks requirements for CPU, memory, storage size and storage IO components, see the following sections in Chapter 4 Solution Architecture Overview of the reference architecture document: Sizing guidelines, Reference workload, and Applying the reference workload. For convenience, this information has been included this Implementation Guide in Chapter 1 SecureVSA Design Planning. Follow these same guidelines when designing the SecureVSA configuration. 3. Plan deployment. Procure solution components. Determine order of installation of the solutions components. Verify correct operation of each component using appropriate methods. Work with members of IT team to plan updates (for example, reachability between network nodes). 4. Confirm pre-requisites prior to deployment. 10G connections between the storage array and all ESXi hosts as per the VSPEX for private cloud reference architecture. 10G ESXi interconnect as per the VSPEX for private cloud reference architecture. Validate the VSPEX configuration is operating properly before starting the SecureVSA deployment. For example, all components are accessible and communicating without interference from firewalls, and so on. 15

16 Chapter 3: Implementation Process Overview Deployment 5. Install and configure. Start from the physical, computing storage, and networking as per the VSPEX for private cloud reference architecture. Overlay encrypted storage on the design. Add SecureVSA. Add guest VMs (servers and/or clients). For SecureVSA, test a single vnode first before deploying all vnodes. Refer to the CloudLink SecureVSA VMware VSphere Deployment Guide for specific instructions. 6. Test and verify. Verify system components (such as hardware) as they are installed. The SecureVSA design assumes that physical hardware is fully verified prior to SecureVSA installation. We recommend using two validation profiles: a small profile for validation of the first encrypted storage function and a full-scale profile for validation of the entire encrypted storage solution. The full-scale profile can initially be validated with test applications and revalidated as the actual applications and guests are installed and integrated onto the system. Perform performance tuning as required (including alignment, caching, SSD, and boot volume). 16

17 Chapter 3: Implementation Process Overview Chapter 4 Key Store Configuration Selecting a key store for the SecureVSA deployment Before starting the SecureVSA deployment, determine the encryption key store that will be used: Microsoft Active Directory or RSA Data Protection Manager (DPM). For deployments with higher security assurance requirements, we recommend using RSA DPM as the encryption key store. Configuring Active Directory as a key store To use Active Directory to store SecureVSA encryption keys, deploy a Windows Server so that it will be accessible by CloudLink Center from its private network. During this procedure, you must provide the host name of the Windows Server. To use the host name, you must have already set up the DNS server. To configure the Active Directory for the SecureVSA encryption key store on Windows 2003 or 2008 Server that is configured as a domain controller: 1. Setup Organization unit on Windows Server: a. On the Windows taskbar, click the Start button, select All Programs -> Administrative Tools, and select Active Directory Users and Computers. b. Create an Organization Unit by expanding your domain name. Right-click and select New, Organizational Unit. c. Specify a Name (for example, SecureVSA_OU). d. Right-click the Organization Unit (for example, SecureVSA_OU) and select New, Group. e. Specify the group name (for example, SecureVSA_Group). 2. Create a bind user. a. Select Global and Security. b. Right-click the Organization Unit (for example, SecureVSA_OU) and select New, User. c. Specify the First Name (for example, Cloud), Last Name (for example, Link), login name and click Next. d. Specify the Password and click Finish. e. Right-click the Organization Unit (for example, SecureVSA_OU) and select Delegate Control. f. Click Next to follow setup wizard. g. Click Add and specify the SecureVSA group name (for example, SecureVSA_Group). Click OK and then click Next. 17

18 Chapter 3: Implementation Process Overview h. Select Create a custom task to delegate and click Next. i. Select the first bullet--this folder, existing objects in this folder, and creation of new objects in this folder--and select Next. j. Select Full Control and click Next. k. Select Finish. 3. Add the bind user to the security group. a. Double-click Security Group. b. Click the Members tab. c. Click Add. d. Type the bind user name. e. Click OK. 4. Record the DN of SecureVSA. a. Click the Start button and select Run. b. Enter cmd and select OK. c. Enter dsquery OU (Support tool is required) and record the DN (for example, OU=SecureVSA_OU,DC=company,DC=com). 5. Apply domain controller in SecureVSA. a. Log in to CloudLink Center as the secadmin user. b. Select CloudLink Center in the topology tree. c. Click the Security tab. d. Click the Key Store tab. e. Click the Active Directory link in Options. f. Enter the host name of the Windows Server for Host. To use the host name, you must first set up the DNS server. g. Enter the DN recorded in step 4 (for example, OU=SecureVSA_OU,DC=company,DC=com) for Base DN. h. Enter login name for the bind user from step 2c for User and select Apply. Right-click the Organization Unit (for example, SecureVSA_OU) and select Delegate Control. Tip: If the password for the bind user changes, repeat Step 5 and provide the new password. 18

19 RSA Data Protection Manager configuration Chapter 3: Implementation Process Overview To use RSA DPM to store SecureVSA encryption keys, ensure that an RSA DPM host is accessible by CloudLink Center via its private network. To configure RSA DPM for storage of SecureVSA encryption keys: 1. Log onto the RSA Data Protection Manager console. 2. Create an identity that belongs to a particular RSA DPM identity group. 3. Create a security class object with Infinite duration that belongs to the same RSA DPM identity group. To configure RSA DPM as the SecureVSA key store location: 1. Open the CloudLink Center on the CloudLink Gateway using the secadmin user account. 2. On the left side of the window, at the top of the VMs list in the Topology Tree, select the Gateway. 3. Click Security tab and then the Key Store tab. 4. To configure the SecureVSA to use RSA Data Protection Manager for encryption key storage, click the RSA DPM link in the Location panel. 5. In the RSA DPM Configuration panel, specify the RSA DPM parameters Host: The RSA DPM host IP address. Port: The TCP port number configured on the RSA DPM host (default 443). Security Class Name: The name of the security class configured on the RSA DPM host for the RSA DPM client. Trust Certificate: The RSA DPM server certificate. Client Certificate: The RSA DPM client certificate. Password: The password used during the RSA DPM client certificate creation. Important: Ensure that RSA DPM server and client certificates are created and saved on the RSA DPM host. 19

20 Chapter 5: Testing and Verification Chapter 5 Installation and Configuration Process overview The following workflow identifies the primary tasks for installing and configuring SecureVSA into VSPEX for private cloud environments. Start Deploy CloudLink Center Deploy three CloudLink vnodes for Datastore mode Deploy one CloudLink vnode for NAS mode End In this SecureVSA design, CloudLink Center manages multiple vnodes. A CloudLink vnode is the software appliance that performs the data encryption operation. Four SecureVSA vnodes are deployed: three CloudLink vnodes configured for Datastore mode and one vnode configured for NAS mode. The three vnodes configured for Datastore mode are each assigned 3.5 TB of disk. The fourth vnode deployed in NAS mode is assigned 1 TB of disk. This configuration means that two of the ESXi nodes have one vnode each and a third ESXi host has two vnodes deployed. Deploying CloudLink Center This section describes how to deploy CloudLink Center, which is the first task in the workflow for installing and configuring SecureVSA into VSPEX for private cloud environments. This SecureVSA design consists of a single CloudLink Center that manages multiple vnodes. Start Deploy CloudLink Center Deploy three CloudLink vnodes for Datastore mode Deploy one CloudLink vnode for NAS mode End Deploying CloudLink Center consists of the following procedures: 1. Deploy the CloudLink Center OVF template. 2. Add a network adapter to CloudLink Center. 3. Configure CloudLink Center. 4. Log into CloudLink Center. 20

21 Chapter 5: Testing and Verification Deploy the CloudLink Center OVF template CloudLink Center is packaged as an OVF template to simplify installation. To deploy a CloudLink Center OVF template: 1. From the VMware vsphere client, select the VMware vsphere File > Deploy OVF Template menu item to access the Deploy OVF Template window. 2. Navigate to the template folder and select a CloudLink Center template, and click Next. 3. Verify the OVF template details and click Next. 4. Type a name and select an inventory location for the deployed template, and click Next. 21

22 Chapter 5: Testing and Verification 5. Select a host or cluster to run the deployed template and click Next. 6. If a series of warnings is displayed, click Yes to continue with the deployment. These warnings are displayed for versions of ESX prior to 5.1, and don t require any action from you to resolve. 7. Select a resource pool and click Next. 8. Select a location for the virtual machine files and click Next. 22

23 9. Select the disk format for the virtual disk and click Next. Chapter 5: Testing and Verification 10. If CloudLink Center requires a public interface, select an adapter for the public network and click Next. For this deployment, the public network is optional as CloudLink Center will not be connecting to vnodes. 11. After template has deployed, from the Deployment Settings panel, review the selected options and click Finish. Click Back to make changes. 12. Wait until CloudLink Center deployment is complete and you see the Deployment Completed Successfully window. Click Close. 23

24 Chapter 5: Testing and Verification Adding a network adapter to CloudLink Center After deploying an OVF template for CloudLink Center, one network adapter is assigned to it, which is used for the public interface. The reference to a public interface does not mean that it will be used for Internet connectivity, but instead, refers to a network adapter that will be use for communication with CloudLink vnodes and by browser-based administration. You need to add a second network adapter configured as a private interface. This interface is not used in the planned configuration, but it does need to be defined. In summary, you define two network interfaces in the following order: a public interface defined in the OVF template a private interface that you add after deploying the OVF template To add a network adapter: 1. From the VMware vsphere client, right-click CloudLink Center and select Edit Settings. 2. From the Virtual Machine Properties window, click Add, select Ethernet Adapter, and click Next. This Ethernet Adapter will be used for the private interface. 24

25 Chapter 5: Testing and Verification 3. From the Add Hardware window, select VMXNET 3 as the Adapter Type and click Next. 4. Select Finish. 5. Select OK. Configuring CloudLink Center After deploying a CloudLink Center OVF template and adding the necessary components, you are ready to configure CloudLink Center. To configure CloudLink Center: 1. From the VMware vsphere client, right-click CloudLink Center and select Power On. 2. From the VMware vsphere client, right-click CloudLink Center and select Open Console. Log in to the VM console on CloudLink Center using the login name gateway and the default password gateway. You can navigate the interface with the keyboard arrow keys, the Tab key, and the Enter key. 3. If you agree to the terms outlined in the End User License Agreement, select Accept. Otherwise, select Cancel. 25

26 Chapter 5: Testing and Verification 4. When prompted, type a new password for the CloudLink Center console and click OK. You are required to change the default password. Subsequent logins to the console prompt for the new password. You can change the password after configuring CloudLink Center for the first time. Every time you login to the CloudLink Center console, the Update menu is displayed. Use the Password command on the Update menu to change the password. 5. Click Confirm after reviewing the configuration information. The configuration information to be verified depends on the choices you made when you deployed the CloudLink Center OVF template. 6. Enter the hostname for CloudLink Center and click OK. For example: 7. Select L3 Routing mode for the CloudLink Center VPN and click OK. 8. Do one of the following: If you selected L3 Routing, specify a tunnel network address and click OK. This address must be an address that is not used anywhere else on the network. For example: Specify whether the CloudLink Center public network uses DHCP or a static IP address. To use DHCP, first make sure that a DHCP server is available on CloudLink Center public network. Select DHCP, click OK, and go to Step 10. If a DHCP server is not available, select Static, click OK, and go to Step If you selected Static, you are prompted to enter the IP address, network mask, and gateway address for the CloudLink Center public network interface. Type the addresses and click OK. 26

27 Chapter 5: Testing and Verification 10. Specify whether the CloudLink Center private network uses DHCP or a static IP address. To use DHCP, first make sure that a DHCP server is available on the CloudLink Center public network. Select DHCP and click OK. Go to Step 12. If a DHCP server is not available, select Static, click OK, and go to Step If you selected Static, you are prompted enter the IP address, network mask, and gateway address for the CloudLink Center private network interface. Type the addresses and click OK. Entering the gateway IP address for the private network is optional if you selected L Wait for the configuration to complete. A summary of the CloudLink Center settings is then displayed. For example: Use the Up and Down arrow keys to scroll the Summary window. Note: The CloudLink Center coordinates are displayed at the top of the Summary window. You can use these coordinates to access CloudLink Center from a web browser. After configuring CloudLink Center, every time you log in using the VM Console, the Update menu is displayed. To view the summary of the CloudLink Center settings, select Summary. To change the password, select Password. To change the network settings, select Network. Warning: If you select to reconfigure your network settings, all current network settings will be lost. To configure static routing, select Routes. Click Add to define a static route for CloudLink s private network interface. If you re prompted for the IP address of the gateway on the CloudLink private network interface, type it and select OK. Next, type the specific IP address to which you want to route. Select OK. After CloudLink validates this IP address, select OK. Tip: From the Static Routes menu, you can click List to display any existing static routes. You can also click Delete to remove an existing static route. 27

28 Chapter 5: Testing and Verification The Diagnostics option is intended for use under the direction of CLOUDLINK Support. Log in to CloudLink Center With CloudLink Center deployed and its network interfaces configured, you can now use a web browser to connect to it and log in. To connect to and log in to CloudLink Center: In the web browser address bar, type the following: IpAddress:8443 where IpAddress represents the coordinates displayed at the top of the Summary. 28

29 Chapter 5: Testing and Verification Deploying CloudLink vnodes for Datastore mode This section describes how to deploy SecureVSA vnodes configured for Datastore mode, which is the second task in the workflow for installing and configuring SecureVSA into VSPEX for private cloud environments. You will deploy three CloudLink vnodes for this mode. Start Deploy CloudLink Center Deploy three CloudLink vnodes for Datastore mode Deploy one CloudLink vnode for NAS mode End Deploying a vnode for Datastore mode involves the following procedures: 1. Deploy the OVF template for a vnode. The base template deployment includes one network adapter for the public network. 2. Add network adapters and storage devices to the vnode. 3. Configure the vnode. 4. Configure the SecureVSA storage. 5. Configure secure ESX datastores. Note: Optionally, you can merge volumes later, after deploying the vnode. For more information, see the CloudLink SecureVSA VMware VSphere Administration Guide. Deploy the OVF template for the CloudLink vnode To deploy the OVF template for the CloudLink vnode: 1. From the VMware vsphere client, select the VMware vsphere File, Deploy OVF Template menu item to access the Deploy OVF Template window. 2. Navigate to the template folder and select a vnode template, and then click Next. 3. Verify the OVF Template Details and click Next. 4. Enter a name and select an inventory location for the deployed template, and click Next. 5. Select a host or cluster to run the deployed template and click Next. 6. Select a resource pool and click Next. 7. If a series of warnings is displayed, click Yes to continue with the deployment. These warnings are displayed for versions of ESX prior to 5.1, and don t require any action from you to resolve. 29

30 8. Select a location for the virtual machine files and click Next. Chapter 5: Testing and Verification 9. Select the disk format for the virtual disk and click Next. 10. Select a public network for the vnode and click Next. 11. From the Deployment Settings panel, review the selected options and click Finish to initiate the deployment. Click Back to make changes. 12. Wait until the vnode deployment is complete and you see the Deployment Completed Successfully window. Click Close. You now see a new vnode VM in the VMware vsphere Client VM list. You can rename the VM. 30

31 Chapter 5: Testing and Verification Adding network adapters and storage devices to the CloudLink vnode A network adapter forms part of the CloudLink vnode OVF template. The included network adapter is for the vnode public network interface. For this deployment configuration, you need to add two additional network adapters, in this specific order: The first network adapter that you add is for the SAN interface. The second network adapter that you add is for the private network interface. After adding the network adapters to the CloudLink vnode, you add one or more storage devices. To add a network adapter for the SAN: 1. From the VMware vsphere client, right-click a vnode and select Edit Settings. 2. From the Virtual Machine Properties window, click Add, select Ethernet Adapter, and click Next. 31

32 Chapter 5: Testing and Verification 3. From the Add Hardware window, do the following and click Next: Select VMXNET 3 as the Adapter Type. Select a SAN connection from the Network label drop-down list. Ensure that the Connect at power on checkbox is checked. 4. From the Options panel, verify the configuration and click Finish. Click Back to make changes. 5. From the Virtual Machines Properties, verify that the network adapter was added and click OK. To add a network adapter for the private network: 1. From the VMware vsphere client, right-click a vnode and select Edit Settings. 2. From the Virtual Machine Properties window, click Add, select Ethernet Adapter, and click Next. 3. From the Add Hardware window, do the following and click Next: Select VMXNET 3 as the Adapter Type. Select a private network connection from the Network Label drop-down list. Ensure that the Connect at power on checkbox is checked. 4. From the Options panel, verify the configuration and click Finish. Click Back to make changes. 5. From the Virtual Machines Properties, verify that the network adapter was added and click OK. 6. Select Finish. 32

33 Add one or more disks to be encrypted Chapter 5: Testing and Verification When the CloudLink vnode is configured in secure datastore mode, all encrypted volumes it provides are unavailable during format operations. We recommended that you format all volumes before using any of them for secure ESX datastores. When multiple virtual disks are assigned to a CloudLink vnode, there are two options for storage configuration: Each disk can be presented as a separate encrypted volume. The disks can be merged and presented as a single encrypted volume. You cannot use the storage until you apply the storage license, as described later in this section. If you want a volume that is larger than the maximum disk size, you must create multiple volumes and merge them later. For more information about merging volumes, see the CloudLink SecureVSA VMware VSphere Administration Guide. In this SecureVSA design, two disks are added to each vnode--a 2TB disk and a 1.5 TB disk--enabling 3.5 TB of encrypted storage for the three CloudLink vnodes configured in datastore mode. To create a hard disk for each volume you want to encrypt: 1. Right-click the vnode and select Edit Settings. 2. Click Add and select Hard Disk. 3. Create a new virtual disk specifying its capacity, type of provisioning, and location. Click Next. 33

34 Chapter 5: Testing and Verification 4. On the Advanced Options screen, select a SCSI address for the Virtual Device Node. Make note of the address selected as this will correspond to the name of the resulting secure store. 5. From the Options panel, review the selected options and click Finish to complete the template deployment. Click Back to make changes. 6. From the Virtual Machines Properties, verify that the disk was added and click OK. Select the datastore and size of disk/volume to be attached to the vnode, add additional disks if multiple encrypted datastores are to be provisioned or if an encrypted datastore larger than 2 TBs is to be provisioned. CludLink vnode SAN configuration The next step in the vnode configuration after network adapters and storage devices have been attached and configured is to configure the CloudLink vnode SAN interface. To configure the properties for the SAN interface: 1. From the vsphere Client window, right-click a vnode and select Edit Settings. 2. In the Virtual Machine Properties window, select the Options tab. 3. In the list of vapp Options settings, select Advanced. 34

35 Chapter 5: Testing and Verification 4. Click Properties on the right to display the Advanced Property Configuration window. 5. In the VMware Advanced Property Configuration window, click New. 6. From the Edit Property Settings window, manually add the string sanip to the Label field and enter the IP address for the SAN network interface in the Default Value field. 7. Click OK. 8. In the VMware Advanced Property Configuration window, click New. 35

36 Chapter 5: Testing and Verification 9. From the Edit Property Settings window, manually add the string sanmask to the Label field and enter the network mask for the SAN network interface in the Default Value field. 10. Click OK. 11. Click OK in the Advanced Property Configuration window and then click OK in the Virtual Machine Properties window to return to the vsphere Client window. Configuring the CloudLink vnode After deploying a vnode OVF template and after adding the necessary components, you are ready to configure the vnode for encrypted Datastore mode. Note: Verify that VM Tools are installed and running before proceeding with the configuration. To configure a vnode with encrypted storage: 1. From the VMware vsphere client, right-click the vnode and select Power On. 36

37 Chapter 5: Testing and Verification 2. From the VMware vsphere client, right-click the vnode and select Open Console. Log in to the VM console on the vnode using login name vnode and default password vnode. You can navigate the interface with the keyboard arrow keys, the Tab key, and the Enter key. 3. If you agree to the terms outlined in the license, click Accept and proceed with the following steps to continue configuration. Otherwise, click Cancel. 4. When prompted, enter a new password for the vnode console. Click OK. You are required to change the default password. Subsequent logins to the console prompt for the new password. Every time you login to the console, the Update menu is displayed. Use the Password command on the Update menu to change the password. 5. The configuration information to be verified depends on the choices you made when you deployed the vnode. Click Confirm to proceed with configuring the vnode. Note: Although the console display indicates a NAS mode of NFS/SMB, you can change the NFS/SMB mode to iscsi after you deploy the vnode. For more information, see the CloudLink SecureVSA VMware VSphere Administration Guide. To change these settings before you proceed, click Cancel to shutdown the system and then return to the deployment procedure to revise them. 6. Enter the hostname for the vnode and click OK. A valid hostname is a letter followed by letters, numbers, dashes ( ), or dots (.). Letters can be lower or upper case. Underscores (_) are not supported. Make note of the configured vnode hostname. You will need the hostname for security token generation for secure VPN connection. 7. Select L2 Bridged or L3 Routing mode for the vnode VPN and click OK. CloudLink Center and all the vnodes must use the same VPN layer. 37

38 Chapter 5: Testing and Verification 8. Specify whether the vnode public network uses DHCP or a static IP address. To use DHCP, first make sure that a DHCP server is available on the vnode public network. Select DHCP, click OK, and proceed to step 10. If a DHCP server is not available, select Static, click OK, and proceed to step If you selected Static, you are prompted to enter the IP address and network mask for the vnode public network interface. Type the addresses and click OK. 10. You are prompted to configure the vnode private network. Specify the IP address, network mask, and gateway address for the vnode private network interface. To use DHCP, first make sure that a DHCP server is available on the vnode public network. Select DHCP, click OK, and proceed to step 12. If a DHCP server is not available, select Static, click OK, and proceed to step If you selected Static, you are prompted to enter the IP address, network mask, and gateway address for the vnode private network interface. Type the addresses and click OK. In L3 VPN mode with multiple vnodes and one CloudLink Gateway, each vnode s private network interface must be configured in a different network. 12. The vnode configuration process might take some time. A summary of the vnode settings is then displayed. 13. To make the VPN operational, perform the following actions: On the vnode console Update menu, select VPN and click OK. 38

39 Chapter 5: Testing and Verification Enter the IP address of the remote CloudLink Gateway public network interface and click OK. You are prompted for a 12-character one-time passcode to be used to authenticate the vnode to CloudLink Center. 14. To generate the 12-character one-time passcode, do the following: Open CloudLink Center using one of the URLs displayed at the top of the Summary, in the following format: Click the CloudLink Gateway. Click the Security tab and then select One-Time Passcode. Create a 15-minute, one-time password for the vnode host name. Click Add. 15. In the vnode console window, type the passcode that was generated in CloudLink Center. 39

40 Chapter 5: Testing and Verification 16. Click OK. The vnode appears in SecureVSA Map along with any other vnodes that have already been added. Configuring SecureVSA Storage As the last procedure in configuring a CloudLink vnode, you: upload a storage license to CloudLink Center apply the storage license to the CloudLink vnode format storage on the CloudLink vnode For information about configuring SecureVSA storage (including uploading and assigning a storage license, and formatting storage), see Configuring SecureVSA Storage in the earlier section named Deploying CloudLink vnodes for Datastore mode. 40