Self-Service Cloud Infrastructure For Dynamic IT Environments

Transcription

1 The All-Flash Array Built for the Next Generation Data Center 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

2 Table of Contents Intro & Exec Summary 3 Reference Architecture Scope 5 Audience 5 How We Got Here 6 Validated Benefits 6 The AI Advantage 7 AI for OpenStack 7 Configuration Detail 8 Workload/Use Case Detail 9 Solution Overview 11 Design Components 12 Compute / Storage Infrastructure 13 Network Infrastructure 13 Operations Environment 14 OpenStack Services 14 Network Architecture 15 Hardware Deployment 17 Network Switch Configuration 17 Preparing OpenStack Nodes For Automated Bare-Metal Provisioning 19 SolidFire Cluster Configuration 25 OpenStack Configuration and Deployment via Foreman 33 Installing and configuring the Foreman server 33 Install Foreman Packages 34 Configuring Foreman Server and installing Foreman 35 Building an OpenStack Cloud with Foreman 49 Appendix 69 Appendix A: Bill of Materials 69 Appendix B: Support Details 69 Appendix C: How to Buy 70 Appendix D: Data Protection Considerations 70 Appendix E: Scripts & Tools 70 Appendix F: Agile Infrastructure Network Architecture Details 71 Appendix G: Agile Infrastructure Node Network Interface Configuration 76 Appendix H: Rack Configuration 77 Solution Validation 58 Deployment 58 Integration/Interoperability 59 Operational Efficiency 59 Quality of Service 62 Storage Efficiency 66 Conclusion 68 2 solidfire.com

3 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. To help accelerate an enterprises ability to embrace these innovations, SolidFire has aligned with leading technology partners to deliver a pre-validated design for customers looking to deploy a self-service OpenStack cloud infrastructure. The SolidFire Agile Infrastructure (AI) reference architecture for OpenStack, as shown in Figure 2, is the result of an extensive configuration design, testing and validation effort. 3 solidfire.com

4 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. 4 solidfire.com

5 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 support@solidfire.com or visit 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. 5 solidfire.com

6 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. Figure 3: The Operational Benefits of SolidFire AI 6 solidfire.com

7 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. 7 solidfire.com

8 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 8 solidfire.com

9 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 Software Development Lifecycle (e.g. Test/Dev, QA Staging, Production) Large Scale Web Applications (e.g. 3-Tier LAMP stack) Persistent Block Storage/On-Premise version of Amazon Elastic Block Storage (EBS) or Provisioned IOPS (piops) Database Consolidation/Database-as-a-Service (DBaaS) IT Consolidation Workload Description Creating logical segmentation between development tiers as we as QoS-enabled performance isolation between tiers Running presentation, middleware and database systems on the same system, without causing resource contention issues Leading support for OpenStack Cinder, allowing for easy deployment of persistent storage via OpenStack APIs 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) 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. 9 solidfire.com

10 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. Figure 7: AI Per Resource Capacity Threshold (15 Compute Nodes) 10 solidfire.com

11 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. SOLIDFIRE 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 knowledge, integrations, partnerships and proof points within the OpenStack ecosystem, unlike any other storage vendor in the market. 11 solidfire.com

12 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 highavailability, 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: 12 solidfire.com

13 Compute / Storage Infrastructure Role Platform Configuration Provisioning / Configuration Management (Foreman) (1) Dell PowerEdge R620 CPU: 2 x Intel Xeon CPU E GHz, 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 E GHz, 12 core RAM: 256GB Network: 2 x 1GbE, 2 x 10Gbe RAID: Integrated Drives: 2 x 250GB OpenStack Cloud Compute (15) Dell PowerEdge R620 CPU: 2 x Intel Xeon CPU E GHz, 12 core RAM: 256GB Network: 2 x 1GbE, 2 x 10Gbe RAID: Integrated 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 General Openstack Infrastructure connectivity / SolidFire Storage Access (2) Dell s55 Switches 44 10/100/1000Base-T ports 4 GbE SFP ports Reverse Airflow (2) Dell s4810 Switches 48 line-rate 10 Gigabit Ethernet SFP+ ports 4 line-rate 40 Gigabit Ethernet QSFP+ ports Reverse Airflow 13 solidfire.com

14 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 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 14 solidfire.com

15 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). Figure 9: Physical Topology Overview 15 solidfire.com

16 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 16 solidfire.com

17 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) 2. Configure s55 TOR switches in stacking mode. These are the Admin/Provisioning switches. 3. On the s55 TOR switch, configure VLANs and VLAN port membership. This will be based on the specific physical port allocations determined at the time of the physical cabling of each system. The only VLAN required on this switch should be the Administrative VLAN. 4. Configure s4810 TOR switches in VLT mode. 17 solidfire.com

18 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. 18 solidfire.com

19 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 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. 3. From the System Setup Screen, select Device Settings. The Device Settings screen will be displayed: 19 solidfire.com

20 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: Example: Main Configuration Page 20 solidfire.com

21 Example: NIC Configuration Page a. For Integrated NIC 1 Ports 1, 2, and 4, do the following: i. Select NIC Configuration ii. iii. Set Legacy Boot Protocol to None 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. iii. Set Legacy Boot Protocol to PXE 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. 21 solidfire.com

22 7. Select System BIOS, then Boot Settings, to enter the Boot Settings page. 22 solidfire.com

23 8. Within the Boot Settings page, select BIOS Boot Settings, then on the next page, select Boot Sequence. 23 solidfire.com

24 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. 24 solidfire.com

25 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 Prior to configuring the SolidFire Cluster, for each SolidFire node it is important to first determine the following; Hostname Management IP Storage IP In addition, it is necessary to define the SolidFire cluster name, management virtual IP address (MVIP), and storage virtual IP address (SVIP). 25 solidfire.com

26 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: Gateway: Storage IP Address (SIP) Mask: Gateway: none SF-OS SF-OS SF-OS SF-OS SF-OS Cluster Name Cluster MVIP Cluster SVIP OSCI-SolidFire 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: 26 solidfire.com

27 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. 4. Select the s key on the keyboard to save the settings. At this point, the node will have an Management IP address which can be used to configure the remaining node settings to prepare the node to be added to the SolidFire Cluster. 27 solidfire.com

28 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: The Network Settings tab is displayed automatically and opened to the Network Settings Bond1G page. Figure 13: SolidFire Node Bond1G settings 28 solidfire.com

29 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. 4. Click Save Changes to have the settings take effect. 29 solidfire.com

30 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. After this process is completed for all nodes, you are ready to create a SolidFire cluster. 30 solidfire.com

31 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 ( ), enter the following URL in a web browser 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. 5. Select Create Cluster. The system may take several minutes to create the cluster depending on the number of nodes being added to the cluster. A small cluster of five nodes, on a properly configured network, should take less than one minute. After the cluster has been created, the Create a New Cluster window will be redirected to the MVIP URL address ( for the cluster and you will be required to log in using the credentials defined in the steps above. 31 solidfire.com

32 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) Figure 18: SolidFire Cluster summary screen 32 solidfire.com

33 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 2. Node acquires DHCP address configuration from Foreman Server, including PXE boot information. 3. Node retrieves custom PXE configuration file from Foreman server. This file contains instructions on which image to load for this particular node. 4. Node retrieves custom Kickstart image and initial configuration settings from Foreman server. 5. Reboot is issued to the node 6. Provisioning and deployment complete. 33 solidfire.com

34 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 34 solidfire.com

35 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= 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 # vi /usr/share/openstack-foreman-installer/bin/seeds.rb Replace password and Controller private/public IP settings %s/securerandom.hex/ mypassword /g %s/ / /g %s/ / /g 35 solidfire.com

36 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 The user name is admin and default password is changeme. Please change the password at Then you need to alter a few parameters in Foreman. Visit: 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 ( 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. Figure 20: Foreman Login Screen 36 solidfire.com

37 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 # sudo cp -R /mnt/rhel-iso/* \ /var/lib/foreman/public/repo/rhel/6.5/isos/x86_64/ 37 solidfire.com

38 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 NOTE: If these entries are not filled in, that s an indication that your host does not have it s FQDN set properly. 38 solidfire.com

39 Hardware Models We ll let Puppet/Foreman populate this after discovery, just skip for now Installation Media 39 solidfire.com

40 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. Navigate to the Templates tab and set the provision and PXELinux drop downs. 40 solidfire.com

41 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; 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). 41 solidfire.com

42 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. 42 solidfire.com

43 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 43 solidfire.com

44 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) 44 solidfire.com