Kontron OpenStack. Kontron OpenStack. Doc. Rev. 1.1

Transcription

1 Doc. Rev. 1.1

2 KONTRON OPENSTACK - USER GUIDE Disclaimer Kontron would like to point out that the information contained in this manual may be subject to alteration, particularly as a result of the constant upgrading of Kontron products. This document does not entail any guarantee on the part of Kontron with respect to technical processes described in the manual or any product characteristics set out in the manual. Kontron assumes no responsibility or liability for the use of the described product(s), conveys no license or title under any patent, copyright or mask work rights to these products and makes no representations or warranties that these products are free from patent, copyright or mask work right infringement unless otherwise specified. Applications that are described in this manual are for illustration purposes only. Kontron makes no representation or warranty that such application will be suitable for the specified use without further testing or modification. Kontron expressly informs the user that this manual only contains a general description of processes and instructions which may not be applicable in every individual case. In cases of doubt, please contact Kontron. This manual is protected by copyright. All rights are reserved by Kontron. No part of this document may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language or computer language, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without the express written permission of Kontron. Kontron points out that the information contained in this manual is constantly being updated in line with the technical alterations and improvements made by Kontron to the products and thus this manual only reflects the technical status of the products by Kontron at the time of publishing. Brand and product names are trademarks or registered trademarks of their respective owners by Kontron S&T AG Kontron S&T Ag Lise-Meitner-Str Augsburg Germany

3 Revision History Revision Brief Description of Changes Date of Issue 1.0 Initial Issue 2017-Oct Addition of Section 3 and modification of Section Jun-01 Customer Support Find Kontron contacts by visiting: Customer Service Kontron, a trusted technology innovator and global solutions provider, uses its embedded market strengths to deliver a service portfolio that helps companies break the barriers of traditional product lifecycles. Through proven product expertise and collaborative, expert support, Kontron provides unparalleled peace of mind when it comes to building and maintaining successful products. To learn more about Kontron s service offering including enhanced repair services, an extended warranty, and the Kontron training academy visit Customer Comments If you have any difficulties using this guide, discover an error, or just want to provide some feedback, please contact Kontron support. Detail any errors you find. We will correct the errors or problems as soon as possible and post the revised user guide on our website. Thank you. // 3

4 Table of Contents Table of Contents... 4 List of Tables... 5 List of Figures... 5 Symbols / Customer Journey Flow Choose Your Step / General Information Platform Description Platform MSP Node Roles High Availability Deployment Tools Add-ons Default Network Layout / Plan the Integration of the OSP in the Infrastructure Plan the Networks Plan the Physical Connections / Deploy the OpenStack Platform Unbox the Equipment Install the Platform in the Rack Gather the Material Required Connect the Power Supplies Establish a Serial Console Connection Modify the Configuration of the Platform Management Network Access the Deployment Node CLI Configure ShMC and MSP Node IP Addresses Configure the IP Addresses of the Switches Configure the Deployment Node Management IP Address Modify the Configuration of OpenStack Networks Configure the OpenStack Networks Connect the MS Platforms to the Enterprise Network Connect an MS2910 Platform Connect an MS2920 Platform Apply the Network Configuration Perform Verifications Deploy OpenStack Post-deployment Verifications Access the OpenStack Dashboard / Demo Mode Gather the Material Required Connect the MS Platform to a Laptop Configure the Laptop Network Set a Route to Reach MAAS and the OpenStack Dashboard Connect to the Deployment Node Using PuTTY Configure the Deployment Node Run Deployment Scripts Access the OpenStack Dashboard // 4

5 List of Tables Table 1: OpenStack services Table 2: Hubs and MSP nodes supported Table 3. Default network layout Table 4. Default network infrastructure, VLANs and subnets Table 5: User infrastructure equivalent form example using an MS2920 platform with 2 MSH8920 hubs and 9 MSP8060 nodes Table 6: IP jumps in a multi MS platform architecture according to component List of Figures Figure 1: OpenStack basic architecture... 9 Figure 2. MS2910 platform with MSH8910 series hubs Figure 3. MS2920 platform with MSH8920 series hubs Figure 4. Example of a minimal system with the different roles MS2900 series platform Figure 5. Kontron OSP default network layout Figure 6: Kontron platform infrastructure network topology Figure 7: network topology Figure 8: Physical connections for an OpenStack platform using MSH8910 series hubs Figure 9: Physical connections for an OpenStack platform using MSH8920 series hubs Figure 10. MS2910 platform production/operation mode connections Figure 11: MS2920 platform production/operation mode connections Figure 12: Juju and OpenStack service status result example // 5

6 List of Acronyms AMQP API BMC CLI DHCP FPGA Gbps HA Hub IaaS IPMI MAAS MMC Advanced Message Queuing Protocol Application Programming Interface Base Management Controller Command-Line Interface Dynamic Host Configuration Protocol Field-Programmable Gate Array Gigabit per second High Availability Switch with Shelf Management Controller Infrastructure as a Service Intelligent Platform Management Interface Metal as a Service Modular Management Controller MSP node NIC OSP QSFP RBD SFP SFP+ ShMC SM SSH VLAN Modular Server Processing node Network Interface Card Open Services Platform Quad Small Form-factor Pluggable RADOS Block Devices Small Form-factor Pluggable Small Form-factor Pluggable that supports data rates up to 10.0 Gbps Shelf Management Controller System Monitor Web Interface Secure Shell Virtual Local Area Network // 6

7 Symbols The following symbols may be used in this manual. DANGER indicates a hazardous situation which, if not avoided, will result in death or serious injury. WARNING indicates a hazardous situation which, if not avoided, could result in death or serious injury. CAUTION indicates a hazardous situation which, if not avoided, may result in minor or moderate injury. NOTICE indicates a property damage message. Electric Shock! This symbol and title warn of hazards due to electrical shocks (> 60 V) when touching products or parts of them. Failure to observe the precautions indicated and/or prescribed by the law may endanger your life/health and/or result in damage to your material. Please refer also to the "High-Voltage Safety Instructions" portion below in this section. ESD Sensitive Device! This symbol and title inform that the electronic boards and their components are sensitive to static electricity. Care must therefore be taken during all handling operations and inspections of this product in order to ensure product integrity at all times. HOT Surface! Do NOT touch! Allow to cool before servicing. This symbol indicates general information about the product and the user manual. This symbol also indicates detail information about the specific product configuration. This symbol precedes helpful hints and tips for daily use. // 7

8 1/ Customer Journey Flow Choose Your Step This document is a user guide that describes how to deploy, operate, monitor, scale, backup, maintain and upgrade the solution designed for Kontron Open Services Platforms (OSP). The OpenStack platform customer journey flow is as follows: Plan the integration of the OSP in the infrastructure Unbox the equipment Perform initial platform connections Configure platform management Configure platform deployment Integrate the OSP in the infrastructure Deploy the OSP Access dashboards and start a VM Operate and monitor the OSP Scale the OSP Backup and restore the OSP Maintain and troubleshoot the OSP This guide is separated into sections which sometime cover multiple journey steps. At each step of the process, part of the flow diagram above will be shown to highlight the previous, current and next steps. The current step will be shown in blue. To know which section to go to, determine what you need to do: Plan the integration of the OSP in the infrastructure and ensure all prerequisites are fulfilled before unboxing and deploying the OSP (Section 3/) Deploy OpenStack networks are planned and prerequisites are fulfilled (Section 4/) Operate OpenStack (Section to come) Monitor OpenStack (Section to come) Scale OpenStack (Section to come) Backup and restore the OSP (Section to come) Perform maintenance tasks on the OSP (Section to come) Troubleshoot the OSP (Section to come) Upgrade the OSP (Section to come) Obtain general information about the OSP (Section 2/) Run the OSP in Demo mode (Section 5/) // 8

9 2/ General Information OpenStack is an open source software created to offer cloud-computing services on standard industry hardware. It can be used for the deployment and management of a cloud infrastructure as a service (IaaS) platform. It supports private and public cloud deployments, satisfying two important requirements of cloud systems: scalability and simplicity of implementation. OpenStack controls the groups composed of Compute, Storage and Network resources through a dashboard that gives administrators control and enables users to instantly provision these resources. One of the most powerful features of OpenStack is its ability to perform infrastructure automation, which reduces the turn-around time for developers provisioning resources and enables agility and faster time-to-market. Figure 1: OpenStack basic architecture Source: openstack.org // 9

10 Table 1: OpenStack services Service Service name Description Compute Nova Provides a way to provision compute instances (aka virtual servers) Object storage Block storage Network management Swift Cinder Neutron Constitutes a highly available, distributed and eventually consistent object/blobstore Provides permanent block storage where block devices can be attached and detached from instances Enables network connectivity between the instances through virtual networks Authentication Keystone Enables authentication for OpenStack users and services Image service Glance Allows disk image storage and retrieval for use by compute instances Billing service Ceilometer Monitors and measures the use of cloud resources for billing and benchmarking Dashboard Keystone Constitutes a web-based user interface for OpenStack services, including Nova, Swift and Keystone, from where users can create, run and manage instances and their resources and connectivity BareMetal Ironic Provides a way to provision BareMetal machines instead of virtual machines For more information, refer to OpenStack documentation at // 10

11 2.1. Platform Description Kontron has created a turnkey deployment based on the Canonical OpenStack Distribution. This solution is designed for Kontron MS platforms. MS platforms include up to nine modular server processing nodes (which are also called sleds or MSP nodes) and two redundant Ethernet switches with a shelf management controller (ShMC), including a serial console port, a management port and SFP/QSFP ports for connectivity. MS platforms with OpenStack are delivered ready to deploy in a network infrastructure or in a quick trial setting. Figure 2. MS2910 platform with MSH8910 series hubs Figure 3. MS2920 platform with MSH8920 series hubs For more information about SYMKLOUD MS products, visit Symkloud.com Platform MSP Node Roles When planning MSP nodes and roles, Kontron determined the level of high availability (HA) and the hardware required. All platforms have one Deployment node, three Controller nodes and two Network nodes. The remaining MSP nodes can be configured as Compute nodes or as any other roles. In a fully deployed OpenStack environment, roles and workloads must be spread over as many servers as possible to make it fully redundant, highly available and with no performance bottlenecks. OpenStack can also be deployed on smaller hardware configurations by combining multiple roles on the MSP nodes and mapping multiple logical networks to a single physical NIC. MSP nodes and command and control (CC) servers can have one of many roles in the OpenStack platform: Deployer: Hosts deployment tools (MAAS and juju) and different virtual machines (juju controller, Nagios, etc.). A Deployment node is responsible for deploying OpenStack services on all the other MSP nodes. Controller: Hosts services for storage (Nova Cloud Controller, Ironic, Ceph, Glance, Keystone, Swift, etc.) and the different APIs and accesses. A Controller node handles requests to and from users and directs the requests to the // 11

12 MSP node running the service agents that will execute the action; it does not run virtual machine instances. For example: A user sends a request for the deployment of a VM. This request is received by the Controller node, and the Controller node directs it to the Compute node that executes the request by deploying a VM. The Controller then informs the user that the action has been performed. Network: Hosts virtual network services (Neutron network worker daemon). The Neutron service provides services such as giving an IP address to a booting Nova instance. The Neutron service runs on the Network node to service the Networking API and its extensions. It also enforces the network model and IP addressing of each port. The Neutron server requires indirect access to a persistent database. This is accomplished through plugins, which communicate with the database using AMQP (Advanced Message Queuing Protocol). Compute: Hosts Nova related services. A Compute node hosts the basic services required to manage VM instances and runs a hypervisor to instantiate and host VMs, which are deployed on Compute nodes. This means each time a VM instance is launched, all the associated computing resources (vcpu, RAM, HDD) are consumed from the Compute node, which hosts the VM. Storage: Hosts the storage for images and instances using storage services such as Ceph. Ceph is the OpenStack storage backend and supports high availability. A Ceph storage cluster is a group of MSP nodes that communicate together to replicate and redistribute data dynamically. A Ceph cluster can persistently handle all sorts of data for Glance, Cinder and Nova that are required for OpenStack instances. Ceph s RADOS Block Devices (RBD) ensure all object replica are stored on different MSP nodes so that MSP node and hard drive failures can be handled without any data loss, as the replicas hosted on different MSP nodes would get redistributed among the Storage nodes. BareMetal: Hosts a BareMetal node that is managed by Ironic. These MSP nodes are available as compute resources for Nova, which is then allowed to provision BareMetal instances. Figure 4. Example of a minimal system with the different roles MS2900 series platform Table 2: Hubs and MSP nodes supported Component type Hub Supported component and associate OpenStack roles MSH8910 series MSH8920 series MSP8040 series All roles possible MSP node MSP8050 series BareMetal only MSP8060 series All roles possible // 12

13 2.3. High Availability High Availability HA systems are leveraged to minimize the following issues: System downtime: When any service is unavailable beyond a specified maximum amount of time. Data loss: Accidental deletion or destruction of data. Kontron offers the following HA functionalities: Protection against cascading failures, where a single failure deteriorates into a series of consequential failures. This is achieved with redundant PSUs and switches at platform level. Provision for running redundant instances (3 Controllers and 2 Networks) of each service on redundant hardware, thereby eliminating single points of failure Deployment Tools MAAS MAAS (Metal as a Service) is a tool created by Canonical that helps with server provisioning and can be used to ensure MS platform processing unit discovery and states are as expected. It is used to make hardware available for the OpenStack deployment. Juju Canonical s juju is a tool that allows orchestration of application deployment and is used to deploy OpenStack on the MS platforms. It relies on MAAS to take control of the hardware and deploy required software Add-ons Several add-ons can be deployed on the Kontron OSP, including: 6Wind VA virtual accelerator to power the hypervisor for virtual networking infrastructures. Nagios monitoring and alerting service. Landscape management tool to deploy, manage and monitor Ubuntu servers. BareMetal // 13

14 2.6. Default Network Layout Table 3. Default network layout Kontron network name OpenStack name Definition and main OpenStack services available Canonical name Kontron platform infrastructure networks Used by MAAS to PXE boot the servers during the enlistment, commissioning and deployment phases. It cannot be in a VLAN. Provisioning (PXE) Internal Management Chassis Management LAN Services: MAAS, DHCP, DNS Used exclusively by the SYMKLOUD management platform for internal communication. This VLAN cannot be changed. Services: No user service Used through the SYMKLOUD platform to access the different management devices: system monitor, MSP node BMCs and MMCs, and switch Web GUI and CLI. The Management port is configured to access this VLAN by default. Services: IPMI OpenStack networks OpenStack Management Management + API 1 admin-api + internal-api OpenStack Data LAN Tenant Guest data or compute-data 2 OpenStack Data LAN Storage Storage Management storage-data + storage-cluster OpenStack Data LAN Public Used for internal communication between OpenStack components and by the APIs of services to manage the platform and automate administrative tasks. This network should only be reachable within the data center. Services: MAAS GUI, juju GUI, OpenStack Horizon, Neutron, Nova, Ceph, Keystone, Glance Used for VM data communication within the cloud deployment. Services: Neutron, Nova Used to expose and access storage resources (object store and block devices). Services: Neutron, Nova, Ceph Used to reach OpenStack virtual machines from external networks. External Services: Neutron compute-external or external Used to deploy BareMetal instances. OpenStack Data LAN BareMetal Deploy Services: Ironic 1 When a + is used between two names, this means the network named includes both of the OpenStack or Canonical networks. 2 When an or is used between two names, this means OpenStack or Canonical refer to the network by both names. // 14

15 Figure 5. Kontron OSP default network layout // 15

16 3/ Plan the Integration of the OSP in the Infrastructure Plan the integration of the OSP in the infrastructure Unbox the equipment Perform initial platform connections Configure platform management The integration planning step is a prerequisite to OpenStack platform deployment. The proper planning of the integration and handling of prerequisite steps will ensure a smooth OSP deployment. The platform was designed based on a fixed parameter set. If you require a different network configuration, please contact Kontron s technical support Plan the Networks The architecture of the platform includes 8 networks. They are described in Table 4 and their topology is shown in Figure 6 and Figure 7. The VLANs, subnets and IPs provided are the default Kontron values. A valid equivalent must be determined for all the values shown in bold orange based on your infrastructure. Refer to Table 5 for a form that includes the Kontron defaults and space to enter the network infrastructure equivalents. The 3 Kontron platform infrastructure networks are used for provisioning and enlistment, which is performed by MAAS. Once MAAS has enlisted and provisioned the infrastructure, the 5 OpenStack networks can be deployed and configured. Table 4. Default network infrastructure, VLANs and subnets Kontron network name OpenStack name Canonical name VLAN Subnet Definition and main OpenStack services available Kontron platform infrastructure networks Provisioning (PXE) None /16 Used by MAAS to PXE boot the MSP nodes during the enlistment, commissioning and deployment phases. It cannot be in a VLAN. Services: MAAS, DHCP, DNS Internal Management 4092 Not exposed Chassis Management LAN /24 OpenStack networks Used exclusively by the SYMKLOUD management platform for internal communication. This VLAN cannot be changed. Services: No user service Used through the SYMKLOUD platform to access the different management devices: system monitor, MSP node BMCs and MMCs, and switch Web GUI and CLI. The Management port is configured to access this VLAN by default. Services: IPMI // 16

17 Kontron network name OpenStack name Canonical name OpenStack Management Management + API 1 admin-api + internal-api OpenStack Data LAN Tenant Guest data or compute-data 2 OpenStack Data LAN Storage Storage Management storage-data + storage-cluster OpenStack Data LAN Public External compute-external or external OpenStack Data LAN BareMetal Deploy VLAN Subnet Definition and main OpenStack services available None / untagged / / / /24 Used for internal communication between OpenStack components and by the APIs of services to manage the platform and automate administrative tasks. This network should only be reachable within the data center. Services: MAAS GUI, juju GUI, OpenStack Horizon, Neutron, Nova, Ceph, Keystone, Glance Used for VM data communication within the cloud deployment. Services: Neutron, Nova Used to expose and access storage resources (object store and block devices). Services: Neutron, Nova, Ceph Used to reach OpenStack virtual machines from external networks. Services: Neutron Used to deploy BareMetal instances /24 Services: Ironic 1 When a + is used between two names, this means the network named includes both of the OpenStack or Canonical networks. 2 When an or is used between two names, this means OpenStack or Canonical refer to the network by both names. // 17

18 Figure 6: Kontron platform infrastructure network topology // 18

19 Figure 7: network topology When planning the network integration, make sure the provisioning network runs a DHCP and PXE server. The data uplink providing the DHCP and PXE services must not be connected to any enterprise network as it can create potential conflicts. Table 5: User infrastructure equivalent form example using an MS2920 platform with 2 MSH8920 hubs and 9 MSP8060 nodes Elements to plan per network Kontron default User value Comment Provisioning (PXE) Provisioning VLAN None Cannot be configured PXE_IP_ADDRESS IP on the Deployment MSP node used to provide PXE and DHCP during provisioning PXE_CIDR /16 Subnet used for provisioning Available IP range used for MSP PXE_DHCP_START nodes during DHCP requests in PXE PXE_DHCP_END provisioning Internal Management Internal Management VLAN 4092 VLAN ID Internal Management subnet Not exposed Cannot be configured Chassis Management LAN INTERNAL_IPMI_VLAN_NAME IPMI VLAN name INTERNAL_IPMI_VLAN 4093 VLAN ID INTERNAL_IPMI_CIDR /24 Subnet used for IPMI devices INTERNAL_IPMI_ADDRESS / IP on the Deployment MSP node used 24 to reach IPMI devices INTERNAL_IPMI_SERVICE1_START INTERNAL_IPMI_SERVICE1_END Reserved IP range for IPMI devices // 19

20 Elements to plan per network Kontron default User value Comment INTERNAL_IPMI_SERVICE2_START INTERNAL_IPMI_SERVICE2_END INTERNAL_IPMI_GW ShMC 1 (active) IP ShMC 2 (standby) IP Switch 1 IP Switch 2 IP MSP node 1 BMC IP MSP node 2 BMC IP MSP node 3 BMC IP MSP node 4 BMC IP MSP node 5 BMC IP MSP node 6 BMC IP MSP node 7 BMC IP MSP node 8 BMC IP MSP node 9 BMC IP Reserved IP range for IPMI devices Used to route the IPMI network externally Hub 1 management IP Hub 2 management IP Hub 1 switch IP Hub 2 switch IP (if switches are stacked there is only 1 switch IP) MSP node BMC IP If MSP8060 nodes are used: MSP node 1 MMC 1 IP MSP node 1 MMC 2 IP MSP node 2 MMC 1 IP MSP node 2 MMC 2 IP MSP node 3 MMC 1 IP MSP node 3 MMC 2 IP MSP node 4 MMC 1 IP MSP node 4 MMC 2 IP MSP node 5 MMC 1 IP MSP node 5 MMC 2 IP MSP node 6 MMC 1 IP MSP node 6 MMC 2 IP MSP node 7 MMC 1 IP MSP node 7 MMC 2 IP MSP node 8 MMC 1 IP MSP node 8 MMC 2 IP MSP node 9 MMC 1 IP MSP node 9 MMC 2 IP MSP node MMC 1 IP MSP node MMC 2 IP Deployment MSP node MAAS configuration variables MAAS_MANAGEMENT_IP IP to reach MAAS on the mngt network MAAS_PUBLIC_IP /24 IP on the Deployment node used to provide Internet on the public network MAAS_UPSTREAM_DNS_IP MAAS upstream DNS IP to reach Internet OpenStack Management (DHCP server and Internet access required for deployment and configuration) MANAGEMENT_VLAN_NAME Management VLAN name MANAGEMENT_VLAN untagged VLAN ID MANAGEMENT_CIDR /24 Subnet used for management network MANAGEMENT_GW IP used to provide Internet access // 20

21 Elements to plan per network Kontron default User value Comment MANAGEMENT_VIP_START MANAGEMENT_VIP_END MANAGEMENT_VIP_KEYSTONE MANAGEMENT_VIP_NOVA MANAGEMENT_VIP_CINDER MANAGEMENT_VIP_GLANCE MANAGEMENT_VIP_HORIZON MANAGEMENT_VIP_NEUTRON MANAGEMENT_VIP_MYSQL MANAGEMENT_VIP_CEPH_RADOSG W MANAGEMENT_VIP_HEAT MANAGEMENT_VIP_CEILOMETER Virtual IPs for OpenStack services The VIP addresses are used to provide predictable access point to services in HA Ensure the values do not create conflicts with an existing network infrastructure OpenStack Data LAN Tenant (no DHCP server) TENANT_VLAN_NAME Tenant VLAN name TENANT_VLAN 10 VLAN ID TENANT_CIDR /24 IP range TENANT_GW Default gateway OpenStack Data LAN Storage (no DHCP server) STORAGE_VLAN_NAME Storage VLAN name STORAGE_VLAN 20 VLAN ID STORAGE_CIDR /24 IP range STORAGE_GW Default gateway OpenStack Data LAN Public (no DHCP server and Internet access recommended) PUBLIC_VLAN_NAME Public VLAN name PUBLIC_VLAN 30 VLAN ID PUBLIC_CIDR /24 IP range PUBLIC_GW IP used to provide Internet access PUBLIC_FLOATING_START PUBLIC_FLOATING_END IPs reserved for use as floating IPs in OpenStack OpenStack Data LAN BareMetal Deploy (no DHCP server) BAREMETAL_VLAN_NAME Baremetal VLAN name BAREMETAL_VLAN 40 VLAN ID BAREMETAL_CIDR /24 IP range BAREMETAL_GW IP on the Deployment node used to reach the BareMetal server on the network BAREMETAL_DEPLOY_START BAREMETAL_DEPLOY_END IPs reserved for use as floating IPs in OpenStack BAREMETAL_NEUTRON_NETWORK _NAME baremetal_netw ork Network name BAREMETAL_NEUTRON_SUBNET_N AME baremetal_subn et Subnetwork name // 21

22 3.2. Plan the Physical Connections The physical connections used between the MS platform and the enterprise network depend on the hub model used. Redundancy connections with hub 2 were intentionally left out of this document. This type of redundancy requires advanced network configurations for both the MSH switches and the switches of the enterprise network. If redundancy is needed, please contact Kontron s technical support. The platform was designed with a specific network architecture. If you require a different network configuration, please contact Kontron s technical support. Figure 8: Physical connections for an OpenStack platform using MSH8910 series hubs In this configuration, hub 1 offers one RJ45 connection (green), four SFP+ connections (red and blue) and one QSFP+ connection (which is not used in the architecture used by Kontron). // 22

23 Figure 9: Physical connections for an OpenStack platform using MSH8920 series hubs In this configuration, hub 1 offers one RJ45 connection (green), three QSFP28 connections (2 100GbE in blue and 1 40GbE in red). The switches used in the enterprise network must support the uplinks of the MSH switches. To deploy the OSP, an external gateway (see MANAGEMENT_GW in Table 5) that can provide Internet access to the Deployment node is needed. The deployment also requires another external gateway for the OpenStack Data (see PUBLIC_GW in Table 5). The Platform Management LAN does not need Internet connectivity. You have now completed the Planning the integration of the OSP in the infrastructure step. You should now have: All the information required to perform the management configuration and deployment. You can now proceed with Unbox the equipment. Plan the integration of the OSP in the infrastructure Unbox the equipment Perform initial platform connections Configure platform management // 23

24 4/ Deploy the OpenStack Platform This section describes how to set up OpenStack in MS platforms for use in a fully deployed environment. The setup includes the network configuration of the platform to match the enterprise environment. The figures show the MS2910 platform with MSH8911 hubs as an example; however, all the instructions apply to the other MS platforms supported Unbox the Equipment Plan the integration of the OSP in the infrastructure Unbox the equipment Perform initial platform connections Configure platform management Platform RJ45 to DB9 serial adaptor Kontron part number: One-page document listing reference documentation available online // 24

25 4.2. Install the Platform in the Rack Install the platform in the rack according to the instructions in the documentation provided with the rail kit purchased Gather the Material Required The following is required to proceed with setup in a fully deployed OpenStack environment: A laptop with a DB9 serial connector or the equivalent (i.e., a console server) The serial RJ45 to DB9 adapter provided with the platform SFP+ cables (refer to Figure 10 or Figure 11 to determine the number of cables required based on the desired configuration) A top-of-rack switch that is VLAN-aware and segmented for the different VLANs used (refer to Table 4) Minimum Linux tools and command-line skills are required to perform the steps described in this guide. You have now completed the Unboxing step. You should now have: A platform installed in the rack and ready for initial connections and all the material required to proceed with connections. You can now proceed with Initial Platform Connections. Plan the integration of the OSP in the infrastructure Unbox the equipment Perform initial platform connections Configure platform management // 25

26 4.4. Connect the Power Supplies Unbox the equipment Perform initial platform connections Configure platform management Configure platform deployment Connect appropriately rated cables from an external power source to each power supply on the rear of the platform. The platform will power on as soon as external power is applied. AC Power Supply DC Power Supply 4.5. Establish a Serial Console Connection The ShMCs and BMCs are preconfigured with addresses within the xxx range. If the enterprise network uses that specific range, plugging in the system could cause IP address conflicts with undesired side effects. Use the RJ45 to DB9 adapter provided with the platform to connect a (non-crossover) Ethernet cable to establish a serial connection between the technician s PC and the RJ45 console port (labeled IOIOI) of the hub with the active ShMC of the MS platform. The hub with the active ShMC is the one with the solid green Power LED. // 26

27 Configure a serial console tool (e.g.: PuTTY) with the correct COM-port for your system using the following parameters: You have now completed the Initial Platform Connections step. You should now have access to: The platform serial console used to access and configure management and payload components. You can now proceed with Platform Management Configuration. Unbox the equipment Perform initial platform connections Configure platform management Configure platform deployment // 27

28 4.6. Modify the Configuration of the Platform Management Network Perform initial platform connections Configure platform management Configure platform deployment Integrate the OSP in the infrastructure The instructions included in the following sections use the Kontron default values (shown in bold orange) as a reference for demonstration purposes only. The values to be used are those defined for your network environment in Table 5. This table contains the Kontron default values and the User equivalent values for the enterprise network Access the Deployment Node CLI Set up access to the Deployment node CLI by directing the serial connection to MSP node 1 (the Deployment node) and establishing an SSH connection. COMMAND MSH891X login: Ctrl+g 1 MAAS login: ubuntu Password: kontron [ubuntu@maas ~]$ PURPOSE Use HOTKEY to redirect serial console multiplexer to MSP node 1 components. Enter credentials to access the Deployment(MAAS) MSP node. The Ctrl+g 1 command is performed by pressing the Ctrl and g keys simultaneously, then pressing on 1 (the MSP node number), followed by the Enter key. This sets the serial multiplexer mechanism to the latest targeted component of the MSP node (for an MSP node with dual CPUs, the default redirection will be on server 1). The ASCII control code for Ctrl-g is 7. You have reached the CLI of the Deployment node. Prompt [ubuntu@maas ~]$ should be displayed. All the commands described in Section 4/ are run from the Deployment node (MSP node 1) unless otherwise specified. You can refer to the sections below for configuration instructions Configure ShMC and MSP Node IP Addresses The commands shown in the sections below use a simple algorithm to allocate IP addresses in a class C network with prefix /24. Use the following commands to configure the chassis management network settings for the ShMC of both hubs and the BMC (and MMC in certain configurations) of all MSP nodes. Refer to Table 5 for the values to be used in the commands. // 28

29 1. Target the IPMI addresses of the active and standby ShMCs via the active ShMC IP address. Define the static IP addresses and the netmask (jump 10 between IPs), the default gateway IP address and the VLAN ID (IPMI VLAN) for both ShMCs. ~]$ /opt/osp/bin/symconf -H configure shmcs --ip /24 --jump 10 --gateway V Target BMCs via the active ShMC IP address. Define the static IP addresses and the netmask (jump 1 between IPs), the default gateway IP address and the VLAN ID (IPMI VLAN) for all MSP nodes. [ubuntu@maas ~]$ /opt/osp/bin/symconf -H configure nodes --ip /24 --jump 1 --gateway V 4093 If the platform is equipped with MSP8060, perform step 3. If not, skip to step Target the MMCs of each MSP node via the active ShMC IP address. Define the static IP address and the netmask (jump 10 between IPs) and the VLAN ID (IPMI VLAN). One command must be executed for each MSP node. The default gateway IP address is set by the parent MSP node. [ubuntu@maas ~]$ /opt/osp/bin/symconf -H configure node 1 mmcs --ip /24 --jump 10 -V 4093 ubuntu@mass]$ /opt/osp/bin/symconf -H configure node 2 mmcs --ip /24 --jump 10 -V 4093 [ ] [ubuntu@maas ~]$ /opt/osp/bin/symconf -H configure node 9 mmcs --ip /24 --jump 10 -V Repeat steps 1, 2 and 3 (if the system is equipped with MSH8060 MSP nodes) for each MS platform (there can be up to 6). Use distinct values and the appropriate jumps between IPs (10 for ShMCs, switches and MMCs and 1 for MSP nodes). Refer to Table 6 for jump calculation. Table 6: IP jumps in a multi MS platform architecture according to component Component IP address for chassis position 1 Jump calculation IP address calculation example for chassis position 2 ShMC 1 active chassis_position ShMC 2 standby chassis_position Switch 1 active chassis_position Switch 2 standby chassis_position MSP node 1 BMC [ ] MSP node 9 BMC When MSP8060 nodes are used MSP node 1 MMC 1 IP MSP node 1 MMC 2 IP [ ] MSP node 9 MMC 1 IP MSP node 9 MMC 2 IP node_position + 30*(chassis_position -1) 10*MMC_position + node_position + 30*(chassis_position -1) [ ] [ ] Configure the IP Addresses of the Switches For a system with MSH8910 series hubs, there is only one switch IP address as the system handles the two switches as one. // 29

30 For a system with MSH8920 series hubs, there are two switch IP addresses as the system handles the two switches independently. Configure the management network settings of the switches. Refer to Table 5 for the values to be used in the commands. 1. Target switches via the active ShMC IP address. Define the static IP addresses and netmask (jump 10 between IPs), the default gateway IP address and the VLAN ID (IPMI VLAN). [ubuntu@maas ~]$ /opt/osp/bin/symconf -H configure switches --ip /24 --jump 10 --gateway V Repeat step 1 for each MS platform (there can be up to 6). Use distinct values and the appropriate jump between IPs (10 for switches). Refer to Table 6 for jump calculation Configure the Deployment Node Management IP Address Configure the IP address of the Deployment Node. 1. Target the Deployment node via the IP address of the active ShMC in the chassis containing the Deployment node. Define the Deployment node IP address and netmask. Refer to Table 5 for the values to be used in the commands. [ubuntu@maas ~]$ /opt/osp/bin/symconf -H configure deployer /24 You have now completed the Platform Management Configuration step. You should now have: Configured the management components of the platform. You can now proceed with Configure Platform Deployment. Perform initial platform connections Configure platform management Configure platform deployment Integrate the OSP in the infrastructure // 30

31 4.7. Modify the Configuration of OpenStack Networks Configure platform management Configure platform deployment Integrate the OSP in the infrastructure Deploy the OSP Follow the steps in the sections below to configure the 4 OpenStack networks Configure the OpenStack Networks Refer to Table 5 for the values to be used in the commands. The values to change are shown in bold orange. 1. From the CLI, open the configuration file in the editor. [ubuntu@maas ~]$ editor /opt/osp/etc/install.conf 2. From the editor, edit the PXE Provisioning network values. PXE_IP_ADDRESS=" " PXE_CIDR=" /16" PXE_DHCP_START=" " PXE_DHCP_END=" " 3. From the editor, edit the OpenStack Management network values. MAAS_MANAGEMENT_IP=" " MAAS_PUBLIC_IP=" /24" MAAS_UPSTREAM_DNS_IP=" " MANAGEMENT_VLAN_NAME="Management" MANAGEMENT_VLAN="untagged" MANAGEMENT_CIDR=" /24" MANAGEMENT_GW=" " MANAGEMENT_VIP_START=" " MANAGEMENT_VIP_END=" " MANAGEMENT_VIP_KEYSTONE=" " MANAGEMENT_VIP_NOVA=" " MANAGEMENT_VIP_CINDER=" " MANAGEMENT_VIP_GLANCE=" " MANAGEMENT_VIP_HORIZON=" " MANAGEMENT_VIP_NEUTRON=" " MANAGEMENT_VIP_MYSQL=" " MANAGEMENT_VIP_CEPH_RADOSGW=" " MANAGEMENT_VIP_HEAT=" " MANAGEMENT_VIP_CEILOMETER=" " 4. From the editor, edit the OpenStack Data LAN Tenant network values. TENANT_VLAN_NAME="Tenant" TENANT_VLAN="10" TENANT_CIDR=" /24" TENANT_GW=" " 5. From the editor, edit the OpenStack Data LAN Storage network values. STORAGE_VLAN_NAME="Storage" STORAGE_VLAN="20" STORAGE_CIDR=" /24" STORAGE_GW=" " 6. From the editor, edit the OpenStack Data LAN Public network values. // 31

32 PUBLIC_VLAN_NAME="Public" PUBLIC_VLAN="30" PUBLIC_CIDR=" /24" PUBLIC_GW=" " PUBLIC_FLOATING_START=" " PUBLIC_FLOATING_END=" " 7. From the editor, edit the Chassis Management LAN INTERNAL_IPMI_VLAN_NAME="IPMI" INTERNAL_IPMI_VLAN="4093" INTERNAL_IPMI_CIDR=" /24" INTERNAL_IPMI_GW=" " INTERNAL_IPMI_ADDRESS=" /24" INTERNAL_IPMI_SERVICE1_START=" " INTERNAL_IPMI_SERVICE1_END=" " INTERNAL_IPMI_SERVICE2_START=" " INTERNAL_IPMI_SERVICE2_END=" " 8. From the editor, edit the OpenStack Data LAN BareMetal Deploy BAREMETAL_VLAN_NAME="Baremetal" BAREMETAL_VLAN="40" BAREMETAL_CIDR=" /24" BAREMETAL_GW=" " BAREMETAL_DEPLOY_START=" " BAREMETAL_DEPLOY_END=" " BAREMETAL_NEUTRON_NETWORK_NAME="baremetal_network" BAREMETAL_NEUTRON_SUBNET_NAME="baremetal_subnet" 9. Save the file and exit the editor. 10. If a field has been modified in the install.conf file, run the following script to reconfigure the default setup. [ubuntu@maas ~]$ bash /opt/osp/installation_scripts/kontron_server_setup.sh You have now completed the Platform Deployment Configuration step. You should now have: An install.conf file containing the values mapped to the enterprise network. You can now proceed with Integrate the OSP in the infrastructure. Configure platform management Configure platform deployment Integrate the OSP in the infrastructure Deploy the OSP // 32

33 4.8. Connect the MS Platforms to the Enterprise Network Configure platform deployment Integrate the OSP in the infrastructure Deploy the OSP Access dashboards and start a VM For an MS2910 platform using MSH8910 series hubs, go to Section For an MS2920 platform using MSH8920 series hubs, go to Section Connect an MS2910 Platform Connect multiple MS platforms using the top-of-rack switch (ToR) based on the wiring shown in Figure 10 and the detailed instructions that follow the figure. Figure 10. MS2910 platform production/operation mode connections 1. Connect the OpenStack Management port (SFP+ port 1) of the first hub on each MS platform to an infrastructure network or switch partition with Internet access (red lines on Figure 10). The deployment tools (MAAS) include a DHCP server on the OpenStack Management subnet. Be careful not to connect this subnet to a network where another DHCP server is present to avoid interference. 2. Connect the OpenStack Data ports (SFP+ ports 2, 3 and 4) of the first hub on each MS platform to the enterprise network for Internet and user access (blue lines on Figure 10). See Table 4 for VLAN and subnet descriptions. 3. Connect the Platform Management port (Management port) of the first hub on each MS platform to the enterprise management network (green lines on Figure 10). This is done to facilitate management through the IPMI and web interfaces of the hubs and the System Monitor. 4. Connect to the Internet. An Internet connection is required to complete system deployment. See Section 3.2 for more details. // 33

34 Connect an MS2920 Platform Connect multiple MS platforms using the top-of-rack switch (ToR) based on the wiring shown in Figure 11 and the detailed instructions that follow the figure. Figure 11: MS2920 platform production/operation mode connections 1. Connect the OpenStack Management port (QSFP port 2) of the first hub on each MS platform to an infrastructure network or switch partition with Internet access (red lines on Figure 11). The deployment tools (MAAS) include a DHCP server on the OpenStack Management subnet. Be careful not to connect this subnet to a network where another DHCP server is present to avoid interference. 2. Connect the OpenStack Data ports (QSFP ports 1 and 3) of the first hub on each MS platform to the enterprise network for Internet and user access (blue lines on Figure 11). See Table 4 for VLAN and subnet descriptions. 3. Connect the Platform Management port (Management port) of the first hub on each MS platform to the enterprise management network (green lines on Figure 11). This is done to facilitate management through the IPMI and web interfaces of the hubs and the System Monitor. 4. Connect to the Internet. An Internet connection is required to complete system deployment. See Section 3.2 for more details Apply the Network Configuration Run the following script to apply the new network configuration. This should take a few minutes to complete. Wait until the system sends the message: Finished script. [ubuntu@maas ~]$ /opt/osp/installation_scripts/kontron_configure_network_and_nodes.sh The script includes sanity checks to ensure the network configuration has been set correctly. These checks include a verification of Internet connectivity (required on the OpenStack Management network) Perform Verifications // 34

35 At this point, the MS platform is fully configured and connected to the enterprise networks. Perform simple verifications to ensure the systems are adequately connected. 1. From a computer with access to the Chassis Management network: COMMAND [user@pc ~]$ ping -c PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.256 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.170 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.181 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.237 ms ping statistics packets transmitted, 4 received, 0% packet loss, time 2997ms rtt min/avg/max/mdev = 0.170/0.211/0.256/0.036 ms PURPOSE Run the ping command to validate connectivity with the Deployment node whose value corresponds to the IP address of the INTERNAL_IPMI_ADDRESS (see Table 5). 2. From a computer with access to the OpenStack Management network: COMMAND [user@pc ~]$ ping -c PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.226 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.187 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.191 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.157 ms ping statistics packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.157/0.190/0.226/0.026 ms PURPOSE Run the ping command to validate connectivity with the Deployment node whose address corresponds to the value of the MAAS_MANAGEMENT_IP (see Table 5). 3. From a computer with access to the OpenStack Public network: COMMAND [user@pc ~]$ ping -c PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.410 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.190 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.152 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.263 ms PURPOSE Run the ping command to validate connectivity with the Deployment node whose address corresponds to the MAAS_PUBLIC_IP (see Table 5) ping statistics packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.152/0.253/0.410/0.100 ms If all the tests above are successful, the MS platform is properly configured and connected. You are now ready to proceed with OpenStack deployment. Configure platform deployment Integrate the OSP in the infrastructure Deploy the OSP Access dashboards and start a VM // 35

36 4.11. Deploy OpenStack Integrate the OSP in the infrastructure Deploy the OSP Access dashboards and start a VM Operate and monitor the OSP Run the following script to proceed with deployment. It will take between one and two hours for the process to be completed, depending on your Internet connection speed. Wait until the system sends the message: Finished script. [ubuntu@maas ~]$ /opt/osp/installation_scripts/kontron_openstack_deploy.sh Post-deployment Verifications At this point, OpenStack should be fully deployed. Perform simple verifications to ensure the system was successfully deployed and to assess system sanity. 1. Verify Juju and OpenStack service statuses COMMAND [ubuntu@maas ~]$ juju status PURPOSE Shows the status of OpenStack deployment, including application, unit and machine statuses. The status of all applications should be "active" or "unknown" (the "unknown" status is normal for memcached and mongodb). The status of all units should be "active". The status of all machines should be "started". Figure 12: Juju and OpenStack service status result example 2. Verify OpenStack service sanity Nova services // 36

37 COMMAND ~]$ source novarc ~]$ nova service-list PURPOSE Shows the status of Nova services. The status of all services should be "up". 3. Verify OpenStack service sanity Neutron services COMMAND ~]$ source novarc ~]$ neutron agent-list PURPOSE Shows the status of Neutron services. The alive status of all services should be ":-)" Access the OpenStack Dashboard Horizon, the OpenStack dashboard, is the web user interface to interact with OpenStack services (Nova, Neutron, Swift, Keystone, etc.). It is deployed during all OpenStack deployments and provides a user-friendly way to manage the cloud for administrators and users. From a web browser, type the IP configured in step 3 of Section for setting MANAGEMENT_VIP_HORIZON. Log in using the default credentials: Domain: admin_domain User: admin Password: admin Once connected, you will have full administrative rights over your OpenStack, allowing you to create public/private networks and spawn instances. Run the platform in production mode from the OpenStack dashboard. You have completed the OpenStack deployment step. // 37

38 You can now use the OpenStack solution. Integrate the OSP in the infrastructure Deploy the OSP Access dashboards and start a VM Operate and monitor the OSP // 38

39 5/ Demo Mode This section describes how to set up Demo mode and use the OpenStack platform with a laptop. Demo mode is intended to enable trials or demos and it should not be used in a fully deployed environment. To use the platform in a fully deployed environment, refer to Section 4/ Gather the Material Required The following is required to proceed with demo mode setup: A laptop with Wi-Fi shared Internet access and an Ethernet port PuTTY installed on the laptop An Ethernet cable to connect the laptop to the MS platform 5.2. Connect the MS Platform to a Laptop With the Ethernet cable, connect the laptop to the Management port of the MS platform as shown in the image Configure the Laptop Network From the laptop, enable network sharing from the Wi-Fi adapter to the Ethernet adapter (access the sharing parameters of the Wi-Fi adapter in your OS). The print screen is an example; the actual configuration window may differ on your computer. // 39

40 Change the Internet Protocol Version 4 (IPv4) properties of the Ethernet port of the laptop. Use the following: IP address: Subnet mask: The print screen is an example; the actual configuration window may differ on your computer Set a Route to Reach MAAS and the OpenStack Dashboard Set a static route to reach the various platform management web interfaces from the laptop. Make sure you are logged in as an administrator. From the Windows Command Prompt, run the following command: route -p ADD MASK Close the Command Prompt Connect to the Deployment Node Using PuTTY From PuTTY, establish an SSH connection using IP address: // 40

41 Log in to the CLI using the following credentials: User: ubuntu Password: kontron 5.6. Configure the Deployment Node 1. From the CLI, open the deployment file in the editor. ~]$ editor /opt/osp/etc/install.conf 2. From the editor, edit the elements shown in bold based on the IP scheme chosen by the administrator. # MAAS configuration variables MAAS_MANAGEMENT_IP=" " MAAS_PUBLIC_IP=" /24" MAAS_UPSTREAM_DNS=" " [ ] # IPMI network INTERNAL_IPMI_ADDRESS=" /24" INTERNAL_IPMI_GW=" " INTERNAL_IPMI_CIDR=" /24" [ ] 3. Save the file and exit the editor Run Deployment Scripts Run the following scripts to proceed with deployment. It will take between one and two hours for the process to be completed, depending on your Internet connection speed. Wait until the system sends the message: Finished script. COMMAND [ubuntu@maas ~]$ cd /opt/osp/installation_scripts/ [ubuntu@maas installation_scripts]$./kontron_configure_network_and_nodes.sh [ubuntu@maas installation_scripts]$./kontron_openstack_deploy.sh PURPOSE Change directory. Configure network platform. Deploy OpenStack. // 41

42 5.8. Access the OpenStack Dashboard Horizon, the OpenStack dashboard, is the web user interface to interact with OpenStack services (Nova, Neutron, Swift, Keystone, etc.). It is deployed during all OpenStack deployments and provides a user-friendly way to manage the cloud for administrators and users. From a web browser, type This is the Horizon address for demo mode. Log in using the default credentials: Domain: admin_domain User: admin Password: admin Once connected, you will have full administrative rights over your OpenStack, allowing you to create public/private networks and spawn instances. Run the platform in demo mode from the OpenStack dashboard. // 42

43 MS Platform OpenStack All data is for information purposes only and not guaranteed for legal purposes. Subject to change without notice. Information in this datasheet has been carefully checked and is believed to be accurate; however, no responsibility is assumed for inaccuracies. All brand or product names are trademarks or registered trademarks of their respective owners. About Kontron Kontron, a global leader in embedded computing technology and trusted advisor in IoT, works closely with its customers, allowing them to focus on their core competencies by offering a complete and integrated portfolio of hardware, software and services designed to help them make the most of their applications. With a significant percentage of employees in research and development, Kontron creates many of the standards that drive the world s embedded computing platforms; bringing to life numerous technologies and applications that touch millions of lives. The result is an accelerated time-to-market, reduced total-cost-of-ownership, product longevity and the best possible overall application with leading-edge, highest reliability embedded technology. For more information, please visit: CORPORATE OFFICES KONTRON CANADA EUROPE, MIDDLE EAST & AFRICA NORTH AMERICA ASIA PACIFIC 4555 Ambroise-Lafortune Boisbriand, QC Canada J7H 0A4 Tel.: Tel.: Lise-Meitner-Str Augsburg Germany Tel.: Fax: info@kontron.com Stowe Drive Poway, CA USA Tel.: Fax: info@us.kontron.com 1~2F, 10 Building, No. 8 Liangshuihe 2nd Street, Economical & Technological Development Zone, Beijing, , P.R. China Tel.: Fax: info@kontron.cn // 43