Self-Service Cloud Infrastructure For Dynamic IT Environments

(1)

Self-Service Cloud Infrastructure

For Dynamic IT Environments

A Validated Reference Design developed for an OpenStack Cloud

Infrastructure using SolidFire’s All-Flash block storage system, Dell compute

and networking, and Red Hat Enterprise Linux OpenStack Platform

SOLIDFIRE

(2)

SOLIDFIRE

2 solidfire.com

SOLIDFIRE

Intro & Exec Summary

The agility, efficiency and scale benefits demonstrated from the move to cloud computing infrastructure has raised the bar on the expectations for IT service delivery globally. This paradigm shift has established a new benchmark for delivering IT services that is as much about self-service and automation as it is about cost. To stay ahead, in the face of these heightened service delivery standards, CIOs are searching for more innovative ways to deliver infrastructure resources, applications and IT services, in a more agile, scalable, automated and predictable manner. Helping make this vision a reality is the promise of the Next Generation Data Center.

Closing the service delivery gap that exists between IT today and the Next Generation Data Center will not be easily accomplished using tools and technologies designed for legacy infrastructure. The challenges IT departments are faced with today (see Figure 1) present an entirely different set of problems than those addressed by legacy vendors. The innovation currently occurring up and down the infrastructure stack from vendors across the ecosystem is a direct reflection of this trend.

Figure 1: The Challenges of The Next Generation Data Center

Properly harnessing these innovations into an easily consumable solution is not without its own challenges. With the many piece parts that compose a cloud infrastructure, the ability to successfully design and deploy a functional cloud environment is often impaired by issues encountered at various stages of implementation including setup, configuration and deployment. Introducing powerful, yet complex, tools like OpenStack into the equation can make the task even more daunting.

(4)

SOLIDFIRE

4 solidfire.com

Figure 2: Agile Infrastructure for OpenStack

With SolidFire AI, customers can stand up a dynamic self-service cloud infrastructure in significantly less time, less space and for less money than alternative converged infrastructure offerings. AI allows enterprises to experience the benefits of Next Generation Data Center design today without creating unnecessary hardware or software lock-in. By combining best-of-breed tools and technologies into a modular pre-validated design, AI drastically reduces the complexity of adopting OpenStack, while increasing the agility, predictability, automation and scalability of an enterprise IT infrastructure.

Relative to alternative approaches, unique attributes of the AI solution for OpenStack include;

Best-of-Breed Design

• AI has been built using best-of-breed technology across all layers of the stack to deliver a fully featured cloud infrastructure solution

True Scale-Out

• Scale-out design across compute, network and storage allows for a more flexible and cost effective design as infrastructure expands

No Lock-In

• Modularity at each layer of the stack eliminates threat of hardware or software lock-in

Accelerated OpenStack Time to Value

• Pre-validated solution drastically reduces complexity of adopting OpenStack infrastructure in a Next Generation Data Center design

Guaranteed Performance

• With SolidFire’s unique QoS controls, AI can easily accommodate mixed workload environments without compromising performance to any one application

The configuration utilized to achieve these benefits, including SolidFire’s leading all-flash storage system, is described throughout the remainder of this document.

(5)

SOLIDFIRE

Reference Architecture Scope

The document is intended to be used as a design and implementation guide to assist enterprise IT administrators and managers in deploying a fully-functional OpenStack cloud infrastructure. The reference architecture included in this document extends up to, but not including, the service layer above the infrastructure. Specifically, the technologies outlined in this document encompasses cloud management software, configuration tools, compute, networking and block storage. Services such as load balancing, firewalls, VPN and core network are outside the scope of this document.

From a sizing perspective, the Agile Infrastructure design outlines a baseline configuration from which users can expect to accommodate a certain size and scale of environment. Throughout this document there are tips to consider when evaluating variation and scale considerations that deviate from the initial configuration. For additional assistance with specific configuration or sizing

details that fall outside the scope of this document, please contact SolidFire Support at [email protected] or visit www.solidfire.com/support.

Audience

This document is intended for IT infrastructure administrators (server, virtualization, network and storage) and IT managers that have been tasked with designing enterprise-class cloud infrastructure. The detail covered in this document encompasses the necessary software, hardware components, as well as key operations and integration considerations.

(6)

SOLIDFIRE

6 solidfire.com

How We Got Here

The SolidFire AI design was architected with a focus on modularity, flexibility and scalability. The design validation and testing

performed against this infrastructure was tailored to specifically highlight the enhanced operational experience customers can expect from deploying this reference architecture in dynamic IT-as-a-Service style offerings such as Test & Development or Private Cloud.

Validated Benefits

Following a comprehensive validation process, SolidFire AI has proven to deliver a scalable OpenStack cloud infrastructure design in significantly less time, less complexity and less footprint than what could be achieved with alternative converged infrastructure solutions. Figure 3 below outlines these specific benefits in more detail.

(7)

SOLIDFIRE

SolidFire Agile Infrastructure (AI)

SolidFire Agile Infrastructure (AI) is a series of pre-validated reference architectures that are thoroughly tested and validated by SolidFire. Built with SolidFire’s all-flash storage system at the foundation, each AI design also includes leading compute, networking and orchestration technologies that dramatically reduces the cost and complexity of deploying a cloud infrastructure for

enterprise-class data centers.

Each AI reference architectures is constructed with a focus on modularity. Individual components can be scaled independently of each other depending on use case as well as the density, size and scale priorities of the environment.

The AI Advantage

SolidFire AI combines industry leading technologies into a more easily consumable reference architecture that has been tested and validated by SolidFire. The AI validated design provides the reference architecture, bill of materials, configuration details, and implementation guidelines to help accelerate your IT transformation. AI is intended help to accelerate time-to-value for operators and administrators deploying a functional cloud infrastructure. Leveraging AI, IT departments can confidently design a cloud infrastructure to help them achieve greater infrastructure agility, automation, predictability and scale.

AI for OpenStack

SolidFire AI for OpenStack is a pre-validated solution built specifically for enterprise-class environments looking to accelerate the deployment of a functional OpenStack cloud. While the flexibility of AI allows it to easily accommodate mixed workload environments, the specific OpenStack use case covered in this document focuses on building a self-service cloud infrastructure for dynamic IT-as-a-Service style offerings such as Test & Development or Private Cloud.

(8)

SOLIDFIRE

8 solidfire.com

Configuration Detail

For this specific use case, we targeted a mid to large size OpenStack cloud infrastructure configuration. The specific hardware configuration (see Figure 4) was designed to accommodate up to 70 vCPUs per compute node. Across the 15 compute node deployment utilized in this reference architecture, assuming a conservative oversubscription rate of 1.5, total vCPU count aggregates to 980. Assuming that VM provisioning in this environment adheres to the same vCPU oversubscription rate, this would translate to at least 1000 VMs within this footprint. These metrics can vary considerably depending on instance sizing and resource requirements.

Figure 4: AI Rack Configuration

(9)

SOLIDFIRE

Workload/Use Case Detail

To help infrastructure administrators better comprehend the usable capacity of the architecture, Figure 5 defines some sample enterprise use-cases. While singling out specific workloads in these examples, it is important to understand that SolidFire’s unique storage quality-of-service controls allows administrators to confidently mix-and-match most any workload types within the shared infrastructure while still ensuring predictable performance to each individual application. This QoS mechanism affords administrators the flexibility to run many of one workload (an entire architecture dedicated to serving OLTP workloads, for example) or run any combination of block storage workloads without compromising performance.

Figure 5: Reference Workloads For AI

Sample AI Workload

Workload Description

Software Development Lifecycle (e.g. Test/Dev, QA Staging, Production)

Creating logical segmentation between development tiers as we as QoS-enabled performance isolation between tiers

Large Scale Web Applications (e.g. 3-Tier LAMP stack) Running presentation, middleware and database systems on the same system, without causing resource contention issues

Persistent Block Storage/On-Premise version of Amazon Elastic Block Storage (EBS) or Provisioned IOPS (pIOPS)

Leading support for OpenStack Cinder, allowing for easy deployment of persistent storage via OpenStack APIs

Database Consolidation/Database-as-a-Service (DBaaS)

Ability to run multiple database types and workloads on the same platform and eliminate storage resource contention. Database types supported include both SQL (Microsoft SQL Server, MySQL) and NoSQL (MongoDB)

IT Consolidation Moving from multiple, siloed, fixed-use platforms to a single,

consolidated, virtualized platform allows infrastructure teams to scale better, operate more efficiently and eliminate unnecessary cost and complexity

Since workload types have varying characteristics, we have included a baseline virtual machine workload size in Figure 6. This reference workload does not represent any individual application, but is designed to be a point of reference when comparing the resource demands of different application workloads.

(10)

SOLIDFIRE

10 solidfire.com

Figure 6: Reference Virtual Machine Specification

Definition

Value

Operating System Red Hat Enterprise Linux 6

Storage Capacity 100GB

IOPS 25

I/O Pattern Random

I/O Read/Write Ratio 2:1

vCPU 1

vRAM 2GB

Using this reference VM size, Figure 7 shows the total workload capacities for each of the different system resources. Regardless of which resource you evaluate, each runs into available capacity constraints well before the storage performance. Available vCPU in this base configuration could support up to 540 of the reference VMs, while storage capacity (GBs) and vRAM and could support up to 614 and 2400 reference VMs respectively. These metrics pale in comparison to the 10,000 reference VMs that could be supported from the available IOPS in the configuration.

(11)

SOLIDFIRE

The point of this exercise is to convey the amount of headroom in storage performance left in the system when other resources are fully utilized. Using our reference VM profile from Figure 6, the utilization of the storage performance when the other resources are fully depleted is not more than 25%. Upon adding additional compute resources, either within or beyond the single rack configuration, the excess storage performance (IOPS) can easily be used to host additional enterprise application load such as databases, VDI or virtual server infrastructure. SolidFire’s ability to guarantee performance per volume allows additional applications to be hosted in parallel from the shared storage infrastructure without creating performance variability from IOPS contention.

Solution Overview

The validated design reviewed in this document was built using the Red Hat Enterprise Linux OpenStack Platform and related OpenStack configuration services including Foreman. The hardware components included in the design include Dell compute and networking, and SolidFire’s all-flash block storage system. A brief overview of each of these vendor and communities behind these technologies is included below;

Launched in 2010, OpenStack is open source software for building clouds. Created to drive industry standards, accelerate cloud adoption, and put an end to cloud “lock-in”, OpenStack is a common, open platform for both public and private clouds. The open source cloud operating system enables businesses to manage compute, storage and networking resources via a self-service portal and APIs on standard hardware at massive scale.

Red Hat is the world’s leading provider of open source software solutions, taking a community-powered approach to reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As the connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT.

Dell is a leading provider of compute, networking, storage and software solutions for enterprise IT infrastructure. As one the earliest vendor contributors to the OpenStack project, Dell has developed significant expertise within the OpenStack ecosystem across their hardware and software portfolio.

SOLID

FIRE

Built for the Next Generation Data Center, SolidFire is the leading block storage solution in OpenStack. For enterprise IT environments that require scalable, highly available, predictable and automated block storage there is no better option in OpenStack. SolidFire has the

(12)

SOLIDFIRE

12 solidfire.com

Design Components

The design and implementation for each OpenStack cloud deployment will vary depending on your specific needs and

requirements. This reference architecture includes the components to deploy a robust, operational, OpenStack infrastructure for a medium to large-scale environment. A logical view of the AI design can be seen in Figure 8.

Figure 8: AI Design Components

The components used in this reference architecture were chosen to reduce the complexity of both the initial deployment, while easily accommodating future scale requirements. The specific configuration details of each infrastructure component is outlined below. While not documented in this reference architecture, a user may choose to add or change services or components, such as high-availability, advanced networking or higher density SolidFire storage options, to meet changing requirements. Outlined below are the specific components used for each layer of the AI design:

(13)

SOLIDFIRE

Compute / Storage Infrastructure

Role

Platform

Configuration

Provisioning / Configuration Management (Foreman)

(1) Dell PowerEdge R620 CPU: 2 x Intel® Xeon® CPU E5-2695 v2 @ 2.40GHz , 12 core RAM: 256GB

Network: 2 x 1GbE , 2 x 10Gbe RAID: Integrated

Drives: 2 x 250GB

OpenStack Cloud Controller (2) Dell PowerEdge R620 CPU: 2 x Intel® Xeon® CPU E5-2695 v2 @ 2.40GHz, 12 core RAM: 256GB

Drives: 2 x 250GB

OpenStack Cloud Compute (15) Dell PowerEdge R620 CPU: 2 x Intel® Xeon® CPU E5-2695 v2 @ 2.40GHz , 12 core RAM: 256GB

Drives: 2 x 250GB

Shared Storage (5) SolidFire SF3010 Single cluster of 5 SF3010 nodes

250,000 random IOPS 60TB effective capacity

Network Infrastructure

Role

Platform

Configuration

Admin Connectivity / OpenStack Provisioning / SolidFire Management

(2) Dell s55 Switches 44 10/100/1000Base-T ports 4 GbE SFP ports

Reverse Airflow General Openstack

Infrastructure connectivity /

(2) Dell s4810 Switches 48 line-rate 10 Gigabit Ethernet SFP+ ports 4 line-rate 40 Gigabit Ethernet QSFP+ ports

(14)

SOLIDFIRE

14 solidfire.com

Operations Environment

Role

Vendor

Description

Host Operating System Red Hat Red Hat Enterprise Linux OpenStack Platform 4.0

Configuration Management & Provisioning Server

Red Hat Red Hat Enterprise Linux OpenStack Platform’s Foreman

tool is responsible for provisioning Openstack systems and performing ongoing configuration management

Storage Operating System SolidFire SolidFire Element OS 5.1289

OpenStack Services

Role

Openstack Service

Description

Authentication/Identity Keystone The OpenStack Identity (Keystone) service provides a central

directory of users mapped to the OpenStack services they can access. It acts as a common authentication system across the cloud operating system and can integrate with existing backend directory services like LDAP.

Dashboard / UI Horizon The OpenStack dashboard (Horizon) provides administrators

and users a graphical interface to access, provision and automate cloud-based resources. The extensible design makes it easy to plug in and expose third party products and services, such as billing, monitoring and additional management tools.

Block Storage Cinder OpenStack Block Storage Service (Cinder) provides

persistent block level storage devices for use with OpenStack compute instances. The block storage system manages the creation, attaching and detaching of the block devices to servers.

Network Nova-Network Core Network functionality is provided by the Nova-network

service, allowing for anything from very simple network deployments to more complex, secure multi-tenant networks

Virtual Machine Images Glance The OpenStack Image Service (Glance) provides discovery,

registration and delivery services for disk and virtual machine images. Stored images can be used as a template to get new servers up and running quickly. Stored images allow OpenStack users and administrators to provision multiple servers quickly and consistently.

Compute Nova OpenStack Compute provisions and manages large

networks of virtual machines. It is the backbone of OpenStack’s Infrastructure-as-a-Service (IaaS) functionality

(15)

SOLIDFIRE

Network Architecture

SolidFire’s Agile Infrastructure is designed to allow easy integration into your existing enterprise data center environment, while retaining the flexibility to address the ever-changing needs of today’s data center. Leveraging best-of-breed top-of-rack (TOR) switching, and single rack-unit server and storage hardware, the architecture design provides a cost-effective path to incrementally scale compute, network, and storage as your needs dictate.

The density of the chosen hardware configuration allows a complete solution stack including compute, networking and storage to be contained within a single rack. Scaling the solution beyond a single rack is easily done by replicating the entire reference architecture design as a single building block.

The network architecture is designed to provide full physical redundancy to maximize uptime and availability of all physical infrastructure components (See Figure 9).

(16)

SOLIDFIRE

16 solidfire.com

Data Center Integration

The SolidFire AI design, as documented here, provides connectivity only at Layer-2 (L2); No Layer-3 (L3) routing exists within this design. L2 and L3 connectivity is separated at the data center network aggregation layer.

Integration of into the existing data center environment is achieved by establishing L2 uplinks to the aggregation layer. As additional racks are added to scale the solution, inter-rack connectivity is maintained strictly at the L2 domain boundary

L3 connectivity between existing enterprise users and/or systems, and the applications and services that are provided by SolidFire’s Agile Infrastructure, is provided upstream by the data center aggregation or core network infrastructure.

For more specific network architecture and configuration details, please refer to Appendix F.

Network Topology

The network topology consists of (5) separate networks to segregate various types of traffic in order to provide security, as well as to maximize performance and stability. Figure 10 depicts the network architecture used in SolidFire’s Agile Infrastructure design.

Figure 10: Network Topology

(17)

SOLIDFIRE

It is necessary to point out that the network subnets referenced throughout this document were sized according to the reference architecture environment. It is important to properly size your networks according to your specific requirements and needs, particularly when considering future scale-out expectations. For more detail on the purpose of each network defined above in Figure 10 refer to Appendix F.

Hardware Deployment

After the installation and cabling of the infrastructure (see Appendix F for more detail), the setup of the environment described in this reference architecture is comprised of the following steps:

1. Network Switch Configuration

2. Prepare the Openstack nodes for Automated Bare-Metal Provisioning 3. SolidFire Cluster Configuration

Network Switch Configuration

The following steps outline key configuration settings and steps to setup the network infrastructure according to the design outlined in this reference architecture.

Key Considerations

Ensure that all OpenStack and SolidFire Node 10G switch ports are configured to meet the following requirements:

OpenStack Node Ports

• 802.1Q VLAN tagging enabled

• MTU 9212 enabled

• Spanning-Tree edge-port (portfast) enabled

• Member of OpenStack Service, Public/DC, Private, and Storage Networks

SolidFire Node Ports

• MTU 9212 enabled

• Spanning-Tree edge-port (portfast) enabled

• Member of the Storage VLAN/Network

Switch Configuration Steps

1. Define VLAN IDs for each of the networks defined in this reference architecture. (Refer to Network Topology section above)

(18)

SOLIDFIRE

18 solidfire.com

5. On each s4810 switch, ensure that all physical port, VLAN, and Port-Channel interfaces have settings according to the requirements listed above.

6. On each s4810 switch, configure VLANs and VLAN port membership according to the network topology defined in the Network Topology section of this document. This will be based on the specific physical port allocations determined at the time of the physical cabling of each system. For Openstack node ports, ensure that VLAN tagging is properly configured for the required VLANs. For more detail refer to Appendix G: OpenStack Node Network Interface Configuration.

7. On each s4810 switch, setup and configure SolidFire node switch ports for LACP bonding. Sample configuration templates are as follows:

a. Create a port channel for each individual node;

interface Port-channel 31 description SF-OS-1 no ip address mtu 9212 switchport vlt-peer-lag port-channel 31 no shutdown

b. Assign the switch ports for a particular node to their respective port channel interface

s4810 Switch A: interface TenGigabitEthernet 0/1 description SF-OS-1:Port 1 no ip address mtu 9212 flowcontrol rx on tx off ! port-channel-protocol LACP port-channel 31 mode active no shutdown s4810 Switch B: interface TenGigabitEthernet 0/1 description SF-OS-1:Port 2 no ip address mtu 9212 flowcontrol rx on tx off ! port-channel-protocol LACP port-channel 31 mode active no shutdown

At this point the network should be ready to move on to the next step. If you are deploying this configuration to ultimately connect to the data center aggregation / core infrastructure, ensure that all VLANs are tagged on all uplink interfaces as required.

(19)

SOLIDFIRE

Preparing OpenStack Nodes For Automated Bare-Metal Provisioning

SolidFire’s Agile Infrastructure facilitates quick deployment of an OpenStack infrastructure by utilizing automated Bare-Metal Provisioning (BMP). By utilizing automated BMP, OpenStack nodes can be deployed and redeployed at the click of a button, taking a physical system from no configuration or operating system, to a fully operational OpenStack node in a matter of minutes.

Prior to deployment into the OpenStack environment via automated BMP, each physical system destined to be an OpenStack Node needs to have certain features enabled

in the System Setup configuration in order to support automated provisioning.

Note: This process simply enables the system to support the automated BMP process. Before actual provisioning of a node can be started, further configuration is necessary to “register” the system in the Foreman provisioning server and define system profiles. See Appendix G: Bare Metal Provisioning With Foreman to complete this process.

System Setup

Note: The following steps are based on Dell System BIOS version 2.1.3 , and iDRAC version 1.51.51

1. Establish a console connection by connecting a keyboard and monitor to the system. 2. Power on the system. When the options appear, select <F2> to enter System Setup.

(20)

SOLIDFIRE

20 solidfire.com

From here, proceed to modify the NIC configurations for each NIC as described in the steps below.

4. For each Integrated NIC Port, configure settings as directed below. Refer to the following example configuration screens for visual reference:

(21)

SOLIDFIRE

Example: NIC Configuration Page

a. For Integrated NIC 1 Ports 1, 2, and 4, do the following: i. Select “NIC Configuration”

ii. Set “Legacy Boot Protocol” to “None”

iii. Select “Back” button, or ESC to return to Main Configuration Page. Select “Finish” to save changes for the NIC. b. For Integrated NIC 1 Port 3 do the following:

i. Select NIC Configuration

ii. Set ‘Legacy Boot Protocol” to “PXE”

iii. Select “Back” button, or ESC to return to Main Configuration Page. Select “Finish”. Select “Yes” when prompted to save changes.

5. Once all NIC configuration changes have been completed, select the “Finish” button or press ESC to exit the Device Settings Page and return to the System Setup page. Then from the System Setup page, select the “Finish” button to exit and reboot. 6. During system reboot, press <F2> to enter System Setup again.

(22)

SOLIDFIRE

22 solidfire.com

(23)

SOLIDFIRE

(24)

SOLIDFIRE

24 solidfire.com

9. Modify the order such that “Integrated NIC 1 Port 3..” is first in the boot order, above “Hard drive C: “, then select “OK” button to return to Boot Settings Page.

10. From the Boot Settings Page, press the “Back” button to return to the System BIOS Settings page. Select the “Finish” button, and select “Yes” when prompted to save changes. You’ll be returned to the System Setup Main Menu page.

11. From the System Setup Page, select the “Finish” button to exit and reboot. The system is now enabled for automated BMP deployment.

(25)

SOLIDFIRE

SolidFire Cluster Configuration

Each SolidFire storage node is delivered as a self-contained storage appliance. These individual nodes are then connected over a 10Gb Ethernet network in clusters ranging from 5 to 100 nodes. Scaling performance and capacity with a SolidFire system is as simple as adding new nodes to the cluster as demand dictate. The Agile Infrastructure design in this document consists of 5 x 3010 SolidFire storage nodes, yielding 250,000 IOPS and 60 TBs of effective capacity. (Figure 11: SF3010 Node Front/Rear) A 100 node cluster scales to 7.5M IOPS and 3.4 PBs, with the ability to host more than 100,000 volumes from within a single management domain.

Figure 11: SF3010 Node Front/Rear View

IP Address Assignment and Cluster Settings

(26)

SOLIDFIRE

26 solidfire.com

A dedicated management network IP, and a dedicated storage network IP is assigned to each SolidFire cluster node. In our configuration, we use the following settings:

SolidFire Node Hostname

Management IP Address (MIP)

Mask: 255.255.255.0 Gateway: 172.27.30.254

Storage IP Address (SIP)

Mask: 255.255.255.0 Gateway: none SF-OS-1 172.27.30.31 172.27.32.31 SF-OS-2 172.27.30.32 172.27.32.32 SF-OS-3 172.27.30.33 172.27.32.33 SF-OS-4 172.27.30.34 172.27.32.34 SF-OS-5 172.27.30.35 172.27.32.35

Cluster Name

Cluster MVIP

Cluster SVIP

OSCI-SolidFire 172.27.30.30 172.27.32.30

SolidFire Node Configuration

The Terminal User Interface (TUI) is used to initially configure nodes and assign IP addresses and prepare the node for cluster membership. While the TUI can be used to configure all the required settings, here we initially just use the TUI to configure the Management IP. Then we proceed to configure the remaining settings via the per-node Web UI.

Initial Management IP Configuration

With a keyboard and monitor attached to the node and the node powered on, the TUI will display. The TUI will display on tty1 terminal display. See Figure 12.

Note: DHCP generated IP addresses or self-assigned IP addresses may be available if your network supports it. If they are available you can use these IP addresses to access a new node in the Element UI or from the API to proceed with the remaining network configuration. All configurable TUI fields described in this section will apply when using the per node UI to configure the node. When using this method of accessing the node use the following format to directly access the node: https://<IP_ADDRESS>:442

(27)

SOLIDFIRE

To manually configure network settings for a node with the TUI, do the following: 1. Attach keyboard and monitor to the video console ports

2. The terminal User Interface (TUI) will initially display the “Network Settings” tab with the 1G and 10G network fields.

Figure 12: Example Terminal User Interface - Network Settings

3. Use the on-screen navigation to configure the 1G (MIP) Network settings for the node. Optionally, note the DHCP IP address which can be used to finish initial configuration.

(28)

SOLIDFIRE

28 solidfire.com

Finalizing Node Configuration

1. Using the Management IP (MIP) of the SolidFire node, enter the Management URL for the node in a web browser. Example: https://172.27.30.31:442

The Network Settings tab is displayed automatically and opened to the Network Settings – Bond1G page.

Figure 13: SolidFire Node Bond1G settings

(29)

SOLIDFIRE

2. Click Bond10G to display the settings for the 10G network settings.

Figure 14: SolidFire Node Bond10G settings

3. Enter the Storage IP (SIP) address for the node. The Gateway Address field will stay blank as there is no gateway for the storage network.

(30)

SOLIDFIRE

30 solidfire.com

5. Click the “Cluster Settings” tab. The Cluster Settings page appears.

Figure 15: SolidFire Node Cluster Settings

6. Enter the cluster name in the “Cluster:” field. Each node must have the same cluster name in order to become eligible for cluster membership.

7. Click “Save Changes” to have the settings take effect.

(31)

SOLIDFIRE

SolidFire Cluster Creation

Creating a new cluster initializes a node as communications owner for a cluster and establishes network communications for each node in the cluster. This process is performed only once for each new cluster. You can create a cluster by using the SolidFire user interface (UI) or the API.

To create a new cluster, do the following:

1. Using the Management IP (MIP) first SolidFire node, SF-OS-1 (172.27.30.31), enter the following URL in a web browser https://172.27.30.31. The “Create a New Cluster” window displays.

Figure 16: Create New Cluster dialog

2. Enter the Management VIP (MVIP) address and a iSCSI (Storage) VIP (SVIP) address. Note: The MVIP and SVIP cannot be changed after the cluster is created.

3. Create Cluster Admin user account. The Cluster Admin will have permissions to manage all cluster attributes and can create other cluster administrator accounts. Note that this Cluster Admin username and password is also used by OpenStack to provision volumes on the SolidFire cluster.

a. Enter a username to be used for authentication in the Create User Name field. User name can be upper and lower case letters, special characters and numbers.

b. Enter a password for future authentication in Create Password c. Enter (confirm) password in Repeat Password

4. Nodes must have the same version of Element software installed that is currently installed on the node selected to create the cluster. If not, then the node will show “incompatible” and cannot be added to the cluster. Ensure all nodes are of the same Element OS version.

(32)

SOLIDFIRE

32 solidfire.com

Adding Drives to the Cluster

Drives can be added to the cluster after it has been created. Node and drive information is gathered when a new cluster is created and is displayed when the cluster is ready for use. A progress bar will display the progress of the drive search and you can choose to add the drives at the current time or add them at a later time.

Figure 17: Cluster Ready Window

Once drives have been added, the cluster is available for use. Refer to the SolidFire Summary Report to view total space available on the cluster for provisioning (See Figure 18)

(33)

SOLIDFIRE

OpenStack Configuration and Deployment via Foreman

The Foreman Provisioning Server from Red Hat provides all the necessary network services such as DHCP, PXE and TFTP, as well as any required operating system images, to support automated deployment of OpenStack nodes.

Note: The Admin network/VLAN is used for all bare-metal provisioning, as well as ongoing configuration management after deployment. Since the Provisioning server provides DHCP, DNS, PXE, and TFTP services locally on the Admin network, these services do not need to be configured elsewhere in your data center environment in order for automated provisioning and deployment to work.

After preparing bare-metal systems for the BMP process (As outlined in “Preparing OpenStack Nodes For Automated Bare-Metal Provisioning” section), the next step is the provisioning and deployment of OpenStack. For this reference architecture we deployed Red Hat Enterprise Linux 6.5 on the bare-metal nodes and subscribed them to the following channels:

• Red Hat Enterprise Linux Server 6.5

• Red Hat Enterprise OpenStack 4.0

A user can opt for different operating system deployment methods if they desire. The requirement here is just that you have Red Hat Enterprise Linux 6.5 enabled with the appropriate subscriptions.

Installing and configuring the Foreman server

Preview of Foreman configuration and deployment: • Networking topology requirements

• Local media via http on the Foreman server

• Customized PXE template

• Customized Kickstart template

• Customization of Host Group parameters

There are two different modes which Foreman can be configured to run in. The first is Provisioning mode, and the alternative is non-provisioning mode. Provisioning mode adds the capability to use Foreman to do bare-metal deployment of your OS. This configuration mode sets the foreman server to act as a PXE, TFTP, DNS and DHCP server, and allows you to configure a boot and kickstart image to perform custom OS installs all from the Foreman server.

Provisioning consists of the following general steps: 1. Power on Node

(34)

SOLIDFIRE

34 solidfire.com

The provisioning process and required network topology is shown in Figure 19:

Figure 19: Bare-Metal provisioning process overview

Install Foreman Packages

Configure the firewall settings on the foreman server using either lokkit or disabling the firewall altogether if your environment permits run the set of commands associated with your configuration as root:

Method 1 - Using lokkit

# lokkit --service http # lokkit --service https # lokkit --service dns # lokkit --service tftp # lokkit --port 8140:tcp

Method 2 - Disabling local server firewall settings altogether

# service iptables save

# service iptables stop # chkconfig iptables off

(35)

SOLIDFIRE

Install the foreman packages as root

# yum install -y openstack-foreman-installer foreman-selinux

Configuring Foreman Server and installing Foreman

To enable provisioning:

As root, edit /usr/share/openstack-foreman-installer/bin/foreman_server.sh; uncomment the variables and add the values as follows: • FOREMAN_GATEWAY=172.27.30.254

• FOREMAN_PROVISIONING=true

Configuration Best Practices

By default the Host Groups that we will configure in the next few sections set their default values via a default ruby file. You have a choice here to modify the default settings in the foreman seed files using a text editor of your choice, or you can override the parameters via the Foreman Web UI during Host Group configuration.

For our deployment we chose to modify the seed files to limit the need for modifications later. The advantage to modifying the seed file is that your default Host Groups will be require less modification via the Web Interface and as a result you will be less prone to making mistakes in your customization. In our case we’re using our Foreman server fairly heavily to deploy multiple OpenStack clouds in various topologies and configs. The one parameter of interest in our case was the password settings. By default Foreman will generate a random hex string for passwords. This may be fine, but in our case we wanted to simplify things a bit and set all of our passwords to our own custom value to make access and maintenance easier.

You can edit /usr/share/openstack-foreman-installer/bin/seeds.rb and set things like passwords. You can also pre-configure things such as IP ranges, and specific service settings. Don’t worry if you make a mistake you can still edit this via the Web UI later. In our case we’re just going to modify the passwords to make things easier for us to remember when we go to use our Cloud. Changing the values in the seeds file is convenient because you can use an editor like vim to easily search and replace items, and it eliminates a chance of error when trying to find all of the passwords or IP entries in the Foreman web interface.

Save a copy of the original seeds file

# cp /usr/share/openstack-foreman-installer/bin/seeds.rb seeds.orig.rb

Open the seeds file with the vi editor

(36)

SOLIDFIRE

36 solidfire.com

Run the openstack-foreman-installer

# cd /usr/share/openstack-foreman-installer/bin/ # sh ./foreman_server.sh

Upon successful installation you should see the following messages and instructions:

Foreman is installed and almost ready for setting up your OpenStack You’ll find Foreman at https://os-11.solidfire.net

The user name is ‘admin’ and default password is ‘changeme’.

Please change the password at https://os-11.solidfire.net/users/1-admin/edit Then you need to alter a few parameters in Foreman.

Visit: https://os-11.solidfire.net/hostgroups

From this list, click on each class that you plan to use

Go to the Smart Class Parameters tab and work though each of the parameters in the left-hand column

Then copy /tmp/foreman_client.sh to your openstack client nodes Run that script and visit the HOSTS tab in foreman. Pick some host groups for your nodes based on the configuration you prefer

Login and change the password

1. Point your web-browser to the newly deployed Foreman server (https://<FQDN>/).

2. The login screen is displayed. Type admin in the Username field and changeme in the Password field. Click the Login button to log in.

(37)

SOLIDFIRE

3. The Overview screen is displayed. Select the Admin User My account option in the top right hand corner of the screen to access account settings.

Figure 21: Account Settings Navigation

4. In the resulting Edit User screen, enter your new Password as prompted 5. Click Submit to save changes

Configuring Foreman to perform provisioning

By default most of what’s needed for provisioning is already built and configured for you. It is necessary to go through the provisioning items however and make some adjustments. The first step is to setup a local media distribution.

You can set provisioning to use either an FTP or HTTP server as a media location. It’s convenient to use the Foreman server itself for this. Foreman has already installed a web-server for us, so the only thing that’s required is to create the local copy of the media on the server. The Foreman public web files are located in /var/lib/foreman/public. Add a directory there named “repo”. You’ll need to create the entire directory structure shown here: /var/lib/foreman/public/repo/rhel/6.5/isos/x86_64

There are a number of ways that a local media source can be setup. The most straightforward is to download a copy of the current Red Hat Enterprise Linux 6 server directly to your server, mount it and copy the contents from the mount directory. The following assumes we’ve downloaded an iso name rhel-server-6.5-x86_64 to our users Downloads directory.

# sudo mount -o loop /home/user/Downloads/rhel-server-6.5-x86_64-dvd.iso # /mnt/rhel-iso

# sudo mount -o loop /home/user/Downlaods/rhel-server-6.5-x86_64-dvd.iso # /mnt/rhel-iso

(38)

SOLIDFIRE

38 solidfire.com

Now you’re ready to configure the PXE, DHCP and DNS proxies in Foreman and set up your provisioning options. The following steps walk through the items that need to be modified or added using the Foreman web interface.

Architectures

• Add “RHEL Server 6.5” to the x86_64 Architecture

Domains

• Verify the Domain fields are populated

(39)

SOLIDFIRE

Hardware Models

• We’ll let Puppet/Foreman populate this after discovery, just skip for now

Installation Media

(40)

SOLIDFIRE

40 solidfire.com

Operating System

Navigate to the “Provisioning/Operating System” tab and create a new OS entry for Red Hat Enterprise Linux 6.5. Verify that you’ve selected; Architecture, Partition tables and Installation media as shown in the figure below.

(41)

SOLIDFIRE

Provisioning Templates

Provisioning templates are what allow you to provide information on how you would like your system configured during PXE boot deployment. For a Red Hat Enterprise Linux deployment you’ll need a PXELinux boot up file, as well as a Red Hat Kickstart file. In addition Foreman provides the ability for you to provide custom Snippets here that you can apply across multiple Kickstart files.

The default install includes a number of Templates, the included OpenStack Kickstart and PXE templates are complete and work for many installations. In our case however we had some variations, our PXE boot interface on our servers was configured to em3, so we wanted to be sure and set that up, as well as make the PXE boot and Kickstart run automated so we set the interface in the Template files ourselves.

In our RA we also utilized interface Bonding and VLAN’s. We added a networking snippet to run after base configuration to setup our nodes the way we wanted including entries for the /etc/hosts file. The templates we used can be downloaded and used as an example from the solidfire-ai git repository;

https://github.com/SolidFireInc/solidfire-ai/tree/master/sfai-openstack/provisioning_templates

Either modify the existing Templates to suit your needs from the Foreman UI or create your own. The Foreman UI provides a built in editor as well as the option of just importing the Template file from your local machine.

NOTE: When using the editor mouse clicks for things like copy/paste are disabled, you’ll need to utilize your keyboard short-cuts (ctrl-c/ctrl-v).

(42)

SOLIDFIRE

42 solidfire.com

After you’ve made your edits or added your new Template files, click on the “Build PXE Default” button located on the Provisioning Templates main page.

Create your subnets for provisioning

The provisioning process needs to know how you want the network configured for boot and install. To do this you’ll need to setup a “Subnet” object in the provisioning group. In our case we’re only creating a single subnet to get the system booted and on the network so that it can communicate with our Foreman server. The settings we used are shown in the figure below. Note that the machine “os-2. solidfire.net” in this example is the FQDN of our Foreman server.

(43)

SOLIDFIRE

Provisioning in Foreman is now configured and ready for use. The next section of the Foreman setup and configuration is the post provisioning components. This is the set of configuration options you need to set up in order to deploy OpenStack on a node after you’ve installed an OS and booted it. Note that in Foreman we’ll reference each server or node as a “Host”.

Setting Host-Groups in Foreman

Host-Groups specify what software packages should be deployed on a system via puppet and what role the host(s) within that Host-Group will fulfill. After a Host has been provisioned and has checked in to Foreman (is managed) you can auto deploy software packages by setting adding it to a Host-Group.

In our case we will utilize the default Controller(Nova-Network) and Compute(Nova-Network) Host-Group’s with some minor modifications. 1. Navigate to the Host Groups Configuration section

(44)

SOLIDFIRE

44 solidfire.com

Configure Controller (Nova Network) Host Group

The following OpenStack components will be deployed on our Controller node(s): • OpenStack Dashboard (Horizon)

• OpenStack Image service (Glance)

• OpenStack Identity service (Keystone)

• MySQL database server

• Qpid message broker

• OpenStack Scheduler Services

• OpenStack API Services

In addition to the default services listed above, the deployment process also includes adding the cinder-volume service to the control node as well. Since we’re using the SolidFire backend for our storage device we can utilize the Controller for our Cinder resources in most cases. If you were to add volume backends like the reference LVM implementation you should definitely deploy your cinder volume service on a dedicated node due to resource requirements. Keep in mind that as with most components of OpenStack you can also add additional cinder-volume nodes later without difficulty.

1. In the base configuration select the following items from the Drop Downs: a. Environment (production)

b. Puppet CA (hostname of our Foreman Server) c. Puppet Master (hostname of our Foreman Server)

(45)

SOLIDFIRE

(46)

SOLIDFIRE

46 solidfire.com

a. Expand the cinder class by clicking on the box to the left of the class-name

b. Add the Cinder::Volume::SolidFire class

(47)

SOLIDFIRE

3. Navigate to the Parameters tab and modify parameters

The Parameters tab displays the various OpenStack configuration variables that are associated with the services that run on the Controller. Here you’ll need to modify a few of the parameters which are typically defined during the network design planning phase prior to deployment. Most of what we’re doing here is ONLY setting appropriate network address information and changing some passwords.

Remember in our case we already set our custom passwords in the seeds file, so the only items we need to change here are the IP addresses and the three settings to set up the SolidFire Driver in Cinder.

(48)

SOLIDFIRE

48 solidfire.com

Configuring Compute (Nova Network) Host Group

The Compute Host Group is the main component of your OpenStack deployment. The Compute nodes that are deployed in this Host Group are the systems that will run our virtual machine instances. Their primary responsibility is to provide the compute virtualization, and enable network and storage access to the instances that a user creates on them.

The following services will be configured and run on these nodes: • OpenStack Compute (Nova)

• Networking (Nova-Network)

The process of updating the Compute Host Group is the same as the process we used to update the Controller Host Group. We won’t repeat all of the steps here, but instead just skip to the overrides page in the Host Group Parameters section:

Notice that we assigned a /21 network to our fixed range. It’s important to plan ahead and have an idea of how many instances you plan to support in your OpenStack deployment. In our case we want to support at least 1000 instances, so we chose a /21 (giving us 2000 IP’s) to ensure we had plenty of IP space and allowed for overhead.

We’re also sharing this on the same private network that we configured earlier so there’s some overhead we have to keep in mind for each Hosts private nic configuration.

<<WARNING>>

If your deployment is similar to what we’ve done here you MUST remember after deploying your Host Groups to use the nova-manage command to reserve the fixed IP’s that you’ve used on your nodes. Since we’re using FlatDHCP and we’re sharing the fixed range with the IP’s we’ve assigned to the nics on our hosts, the used IP’s need to be marked as reserved in the pool. If you don’t do this the result is that as you launch instances they’ll use the first available IP’s in the range. This will result in a duplicate IP assignment. The verification section below includes information on how to reserve these IP’s as well as information regarding a script available in the solidfire-ai Github repository.

(49)

SOLIDFIRE

Building an OpenStack Cloud with Foreman

Foreman is now configured and ready for use. At this point we can provision systems and deploy OpenStack on our bare metal servers. There are now just two steps required to get from “Bare Metal” to “OpenStack”;

1. Provision OS to hosts

2. Assign Host Groups after deployment

You will notice that in our deployment model we performed the Host Provisioning and OpenStack Host Group assignment in two separate steps. You could consolidate this to do the deploy and the Host Group assignment all in a single step. However, in our case we added some kernel modifications in our Kickstart file that required a reboot. Rather than implement reboot/updates during the Kickstart process we chose to separate the two steps. Instead we created a “Base” Host Group that didn’t have any Puppet Manifests associated with it. Using a “Base” Host Group like this is helpful, because it reduces the number of fields you have to enter when Provisioning a new host. Fields like “Puppet Server”, “Subnet” etc can all be associated automatically via the Host Group association. Some important things to keep in mind, Foreman deploys the OS for us and configures Puppet. After creation the Host will automatically check in with Foreman every 30 minutes (or on each reboot) via the local Puppet Agent.

Provision a Host

In order to provision a host there are two pieces of information that you need to have: 1. The MAC address for the NIC you want to PXE boot off of

2. The DHCP address you want to assign during PXE boot

Foreman will auto select the DHCP address for you, but in our case we utilize the DHCP address to make some settings in our Kickstart file. In order to track things better we find it helpful to keep a consistent pattern here. Rather than use the random DHCP address that Foreman provides, we’ll override it and match the hostname. For example if our Host is “os-1” we’ll be sure to select DHCP address “172.27.30.1”.

To provision a Host, we’ll need to add it and mark it for Build. Navigate to the Foreman Web UI Hosts page and click on “New Host” in the upper right corner.

(50)

SOLIDFIRE

50 solidfire.com

The “New Host” page has a number of items that need to be filled in. Most of the items here are drop-down selections, so the only pieces you’ll need to really know here are the name, mac-address and IP as mentioned earlier.

(51)

SOLIDFIRE

Set the MAC address for the interface that you want to PXE boot off of. Foreman will create an entry for this MAC address when you mark it for build. The DHCP and PXE servers will only respond requests from known MAC addresses that are currently marked for build.

Set Architecture, Operating system, Build mode, Media, Partition table and Root password. Not that most of these will be auto-populated once you select an architecture. Be sure to click “Provision Templates” after setting all of the fields.

NOTE: If you receive an error setting DHCP during the Resolve process it’s most likely a problem with the dchp.leases file. We ran into this occasionally and were able to fix it by cleaning the dhcpd.leases files, it’s important to make sure that there are NO Hosts marked for Build when you reset these:

# service dhcpd stop

# rm /var/lib/dhcpd/dhcpd.leases; touch /var/lib/dhcpd/dhcpd.leases # rm /var/lib/dhcpd/dhcpd.leases~; touch /var/lib/dhcpd/dhcpd.leases~ # service dhcpd start

(52)

SOLIDFIRE

52 solidfire.com

Clicking Submit will automatically mark the Host for build. This creates an entry for the MAC address in the PXE/DHCP directory and adds the host information to the dhcpd.leases file. Upon reboot the Host will receive a DHCP address from the Foreman Proxy, PXE boot into our PXELinux file and run the Kickstart Template. The install/provisioning is completely automated, the only step required is the reboot.

(53)

SOLIDFIRE

In our case we added all of our Hosts and marked for Build, then using our APC just power cycled all of them at once to kick off the process. You can also use the IDRAC to reboot and also monitor the process on the first run and make sure everything goes as planned. Upon completion of the Kickstart process, the Host status may go to an error state in the Foreman UI. In our case this was because we made a network change at the end of our kickstart file that made the Host unreachable. After the reboot, the Puppet Agent will check back in to the Foreman server and it’s status should update to “OK”. Your Host is now ready for Host-Group assignment and OpenStack deployment.

Assign and Deploy the OpenStack Controller via Host Group

The first node we have to deploy is the Controller node or Host Group. The Compute Nodes and all other OpenStack nodes are dependent on the Controller or Controllers if you’re doing HA.

1. Point your web-browser to the IP address of your Foreman Server 2. Login using the admin credentials you set up earlier

3. Click on the Hosts tab

4. Check the selection box to the left of the host you want to deploy OpenStack Controller 5. Click on Select Action from the drop down to the upper right and select Change Group

(54)

SOLIDFIRE

54 solidfire.com

6. Choose the Controller (Nova Network) Host Group from the selection list and click Submit

The next time the Client Node checks in with Foreman it will be listed as out of sync, and Foreman will deploy the Controller Host Group.

NOTE: If you don’t want to wait for the next host update cycle, you can force an update from the client using the following command:

# puppet agent -t

This will force the client node to check in with the Foreman server, download the current manifest and begin deployment of the updates.

Assign and Deploy the OpenStack Compute Nodes via Host Group

Once your Controller node has been deployed and is up to date according to the Foreman Web UI, you’re ready to start assigning the Compute Host Group to your nodes. This process is the same as the process you followed for the Controller Host Group. Everything is the same except Node selection and Host Group selection.

It’s STRONGLY recommended to start by deploying the Controller and just a single Compute node and then performing some basic functional testing. This way you can verify your Host Group configs are correct and that your deployment model is usable.

The steps below outline the minimum checks you should perform, in addition it’s a good idea to boot an instance, attach a volume and verify that you can log on to the instance, create partitions, format and mount the volume.

Once you’ve successfully completed these checks, you are ready to assigning the Compute Host Group to the rest of your nodes. Also keep in mind you don’t have to deploy everything now. You can come back and scale out your compute nodes later if you like.

(55)

SOLIDFIRE

Verifying the OpenStack deployment

You should now be able to log in to the OpenStack Dashboard. Using your web-browser point to the Dashboard and login as admin (the password can be obtained from your Controller Host Group’s parameters tab if needed):

Log in using the admin account and navigate to the “Access & Security” section, select “Download OpenStack RC File”. This RC file holds credentials to allow you to access the OpenStack Services API’s via http (curl or client utilities).

(56)

SOLIDFIRE

56 solidfire.com

Download and run SolidFire-AI openstack_verification_scripts

At this point we should have a functional OpenStack deployment. Upon completion of the OpenStack deployment, running the SolidFire AI Verification Script is recommended. The script and other useful tools are available in the solidfire-ai repository within the SolidFire Inc. public GitHub.com organization (https://github.com/SolidFireInc/solidfire-ai/).

Upload the credentials file you downloaded in the previous step to your newly deployed Controller Host and log in via ssh. Install git and clone the SolidFire-AI repo on the Host.

# git clone https://github.com/SolidFireInc/solidfire-ai.git

For now, we’re interested in the “sfai_openstack_config_scripts”, cd to that directory:

# cd solidfire-ai/sfai-openstack/openstack_config_scripts

Details describing what these scripts do and the order they should be run in are available in the Repos README file as well as comment/documentation headers in the scripts themselves. Be sure to take a look at these before executing the scripts to ensure they’re set up for your particular environment.

We will use the following scripts to test our deployment and make some configuration settings: • reserve_ips.sh

• Reserves our ranges of floating and fixed IP’s that we’re using on the Hosts

• basic_verify.sh

• Runs basic functionality exercises, creates an image, boots and instance, attaches a volume, etc.

• cloud_setup.sh

• Finishes up our configuration by creating SolidFire QoS Specification, Volume Types and downloads/creates a number of images to use in our Cloud as well as creates a default keypair to assign to instances. One critical piece here is to create a default

Upon successful running the scripts listed above, we should feel confident that we haven’t misconfigured our deployment options. If you ran these tests after a single Compute Host deployment (recommended), now we can go through and assign remaining Hosts to the Compute Host Group.

IMPORTANT: If you came across an issue such as an incorrect parameter being set in the Host Group, you can simply edit the Host Group Parameters via Foreman. The next time the Host checks in (30 minute interval), it will be notified that it’s out of sync and the changes will be pulled on to that Host. You can also force the check in from the Host using “puppet agent -t”.

Additionally it’s possible to configure Foreman to “push” puppet updates, however we chose not to implement that feature in our RA. From the Foreman WEB UI, navigate to the Hosts page and select all of the remaining Hosts that you’d like to deploy as Nova Compute Hosts. From the “Select Action” drop down in the upper right portion of the table, select “Change Group”, and select “Compute (Nova Network)” from the drop down and then Submit the changes.

(57)

SOLIDFIRE

At each selected Hosts check in they’ll receive notification that they’re out of Sync and they’ll be updated/reconfigured as specified by the indicated Host Group.

(58)

SOLIDFIRE

58 solidfire.com

Solution Validation

Throughout the validation process, specific tests were conducted against the outlined configuration using industry standard benchmarking tools in order to validate the AI design against the kind of workloads most often encountered in an IT-as-a-Service style cloud infrastructure. Each individual category below outlines the specific test conducted to validate the use case and highlight the key benefits of SolidFire AI.

Deployment

Through our testing we were able to validate significant acceleration of deployment times with the AI architecture. The targeted deployment for this validation was 18 nodes, composed of 2 Control nodes (HA), 15 Compute nodes and 1 Foreman node.

The key achievement from this effort was the deployment from bare metal to OpenStack in approximately one hour. Specific duration of key steps in this process include;

• Provision from bare metal to operating system 17 nodes within 30 minutes • Install and Configure OpenStack on the same 17 nodes in less than 30 minutes.

More specific details from important steps in the deployment process are highlighted below;

• Utilizing Foreman Provisioning (bare-metal deployment) and OpenStack deployment we were able to install, configure and register the 17 nodes into Foreman running OpenStack in less than 1 hour. For comparison purposes, deployments without Foreman typically entails a multi-day effort that is susceptible to error due to significant manual administration. Using Foreman not only expedites the install process in terms of time, it also results in a more accurate and repeatable process.

• In our setup we utilized a local mirror for OS install and provisioning, as well as customized Kickstart files for networking. The result was provision time from bare metal to operating system in under 30 minutes. This process included registration on the Red Hat Satellite, YUM updates, networking configuration, and installation and configuration of Foreman/Puppet Clients.

• At this point, deploying OpenStack components is simply a matter of adding a host (or hosts) to the appropriate host group. Foreman using Puppet to install and configure the select OpenStack packages during an update interval, this process completed within 30 minutes of the Hosts check in with the server.

• For the first step in our deployment sequence we deployed all of our bare metal systems. Next we deployed our OpenStack Controllers and a single OpenStack Compute node. We then ran our verification scripts (see GitHub) against the resulting OpenStack Cloud to ensure that everything worked correctly.

• Upon successful completion of verification checks we assigned the Compute Host Group to the remaining 15 nodes. The resulting configuration amounted to 2 controller nodes and 15 compute nodes ready for consumption inside of OpenStack.

(59)

SOLIDFIRE

Integration/Interoperability

Initial integration and interoperability of the reference architecture deployment was performed using two standard tests. These tests include the Red Hat Enterprise Linux OpenStack Platform Certification Test Suite and the Tempest Test Suite.

Red Hat Enterprise Linux OpenStack Certification Test Suite

This test is provided by Red Hat and is intended to ascertain that a third-party component is compatible with Red Hat Enterprise Linux OpenStack Platform. There are two parts to the Certification Test Suite, Storage and Networking. In our reference architecture we ran the Storage Certification suite to further verify the interoperability of our deployment.

Test Type

Status

RHEL OpenStack Certification Test Suite PASSED

Tempest Test

This pass/fail test evaluates interoperability of the majority of the functionality inside OpenStack.

The items tested by Tempest includes booting instances, creating/attaching volumes, creating bootable volumes, performing snapshots and much more.

This particular test-suite is utilized for the CI gating checks which run against every commit to the OpenStack code base.

Test Type

Status

Tempest Test Suite PASSED

Operational Efficiency

To demonstrate operational efficiency of the AI design we performed a number of test-scenarios. These ranged from testing functional scale limits of the deployment and timing, as well as real world simulations of various workloads running simultaneously in the AI Cloud.

Scalability

This Scalability test is intended to exercise the ability to scale Block Storage and Compute Instances in our AI cloud as well as dynamically add Compute Nodes into this environment. We started this test by reprovisioning all of the Hosts in our Deployment. We used the same process as in the initial deployment and loaded a fresh version of the Operating System on each Host. To start

Self-Service Cloud Infrastructure For Dynamic IT Environments