-
Notifications
You must be signed in to change notification settings - Fork 6
Home
##Terminology
- UnifiedStack : One-touch Openstack installer solution, which is being prototyped here.
- Openstack : Open-Source Cloud Operating System.
- UCS : Cisco's Server Offerings. C-Class are rack mounted. B-Class are chassis mounted blades.
- FI : Cisco's Fabric Interconnect Solution.
- UCSM : Cisco's Server Management ultility.
- Packstack : RedHat's Openstack Installer Solution based on puppet.
- OSP5 : RedHat's Openstack Platform 5. Containing Openstack's Icehouse release.
- Icehouse : Openstack's Current Release.
- BuildServer : Logical reference to the server that houses Packstack's Build node.
- Masternode : a UnifiedStack term only, referring to build server + cobbler server combination. Is central orchestration point wrf UnifiedStack.
- Integrator : a UnifiedStack term only, referring to the script that calls and integrates all the submodules in the project.
UnifiedStack is a one-touch Solution being prototyped here. UnifiedStack aims for easy automated deployment of OpenStack over Cisco Hardware [Topology consisting of UCS (B-Class, C-Class),FI, Nexus and Catalyst Switches]. The aim is to deliver a solution keeping in mind that the customer is new to Cisco hardware. This solution would not only help the customer to install an Openstack Setup with minimum effort but also to configure the hardware.
Currently, the configuration file contains the topology related information and machine details. The program reads this file as input and installs the complete hardware and software components on top of the hardware as specified. This file also supports a few advanced level configurations for which, default values would be assigned. The user would change these settings only if he wants an advanced setup. Going forward, this configuration file will also be populated via a self-service portal making it even easier for the user to redesign his topology.
Note : the current version is based on RHEL-7.0 . However, other distros of choice could be easily integrated since the code is not tightly coupled with the Operating System.
- UCS-Servers (B-class and C-class)
- Cisco Switches ( Both IOS or NX-OS based - tested with 2960,3750 and 9300)
- Server Management via Cisco UCSM-FI modules or CIMC based upon what is available.This is configurable in .conf file.
- RHEL - Openstack (Icehouse) Packstack (OSP5)
- Deployer (User) configures wiring on the hardware.
- Provides Management IP to one UCS-Server and one terminal Server
- Installs RHEL(or Other) OS on above UCS-Servers and Configures hostname/networking.Completes Subscriptions (if uses RHEL)
- Downloads UnifiedStack.
- Fills the info about his topology on Forms on a UI -> UI writes the UnifiedStackconfiguration file internally. Alternately he directly manually alters the configuration file.
- Runs UnifiedStack. UnifiedStack first configures the management IPs on the hardware, then configures them and installs Openstack on top of it according to the topology defined. User waits till his Openstack gets ready.
UnifiedStack components/Modules
- A UI based front-end built using Angular JS and bootstrap.
- a universal UnifiedStack.conf configuration file.
- FI/CIMC configuration Module. (base module)
- Switch configuration Module. (base module)
- MasterNode Configuration Module. (base module)
- Openstack-Packstack Configuration Module. (base module)
- Integrator Module
Interaction of the modules : The Integrator module reads the configuration file and calls each of the base modules with the required parameters. The hardware setup is configured before the Packstack configuration is triggered. When all configurations are set properly, it runs the packstack to get the Openstack setup up according to the topology defined in the configuration file.
Current Topology This defines the current Topology defined in the configuration file and how hardware is wired in the lab. This topology can be changed as required provided the changes are represented accordingly in the configuration file.
This is the only single place to provide inputs to the UnifiedStack programs. All the modules in UnifiedStack take input from this configuration file. It contains several logical sections which cover grouped information regarding the Hardware topology,setup, Openstack configuration,passwords.
Today, this file is manually edited by the user. Later a Self-Service Designer Portal would take inputs from user and write into this configuration file.
Not all parameters need to be necessarily changed by the user. Details of each parameter in the configuration file is mentioned on a separate page in this wiki.
- Portal to define topology and take user inputs about the system to be installed.
- Add terminal server support so that initial management IP can be provided as a part of one-touch solution.
- Add support for Ceph.
The script has been developed in a completely modular fashion. To give a broader view, We have an integrator script which calls the wrapper functions of each module separately and also keeps track of the amount of implementation that has been done. The wrapper functions in turn call the individual components of the particular modules. The configuration parameters are stored in a config file which are parsed and provided as inputs to the individual components.
As per the current design, all the required features in UCSM (UCS manager) has been automated. The code configures server ports, uplinks ports , the required pools such as UUID pool, MAC pool, and IP pool. It cretaes service profile with no restriction on number of VNICs and VLANs. The service profile creation code pulls the required pools which is created previously. The code clones the service profile and required number of profiles can be created. It then binds the profiles to respective servers and completes the entire process.The automation script is written in Python and it uses UCS python SDK module. The code also automates the required CIMC features for UCS C series servers.
Future Enhancements
- The FI initialization process will also be automated using a terminal server. The user will just wire the server setup and even the management IPs will be configured through script.
- The IP pool binding to the CIMC address will also be automated.
- The RAID configuration will be taken care through scripts.
As per the current design, Switches that are required are 1.Nexus 9396 – For connecting the Network node of OpenStack to the compute devices for tenant network purposes. 2.Catalyst 3750 – Acts as aggregation point for all the nodes connecting them to the WAN. The switch configurator script invokes the methods to configure each switch namely the Nexus 9396 and Catalyst 3750. Within the individual methods, a function is used to configure the device by first establishing an interactive SSH session, thereafter sending the IOS commands to the interface of the switch. The commands are read from a text file which is supplied as input. Exception handling of SSH session is done and a retry limit of 3 has been configured if the connection breaks during the execution of commands.
Limitations
- Currently, the management IPs to the switches needs to be given manually which is used for connecting to the switch using SSH.
Future Enhancements
- As of now, the IP addresses to which the SSH sessions need to be established have been provided as a static value within the code which will be moved to the centralized file containing all configuration parameters in the later stage of development.
- The topology will be modified to include a terminal server which will then be used to assign management IPs and connect to all the devices. A configurator file for configuring the terminal server will be included in the wrapper. SSH session will then be established only to the TS and all connections to the switches will then go through it. The text file containing configuration commands will be modified accordingly.
- Automation and control of CIMC of the C series servers will be done using the 2960 switch.
- Once the TS has a management IP, the solution becomes one touch since the management network for the topology devices would also become remotely configurable.
MasterNode Module is the build server which will act as cobbler node. This module installs the cobbler and then configures it. Under the configuration is sets and configures the PXE. It also makes a system entry in cobbler corresponding to each physical machine. This performs automated install of operating system on all the nodes.
Under the packstack module, the program downloads the openstack-packstack utility on the build-server. It then generates the answers file and sets the values in the answers file accordingly. The utility then runs the packstack for the installation of Openstack as specified in the UnifiedStack.conf
This module reads the configuration file (UnifiedStack.conf) and then calls each of the base module listed above in correct sequence to initialise and configure hardware and then install OS on top of the configured hardware. And once all this is done it installs packstack and configures the packstack build-node. Once the answers file of the packstack is configured it runs the packstack utility to install Openstack.
- UCS C-series Server - 4 Nos / Alternately can use B-series as well.
- Cisco 2960 Switch
- Cisco 3750 Switch
- Cisco 9300 Switch
- In the initial version only RedHat openstack - Packstack is supported.
- On UCS C-class server - the RAID configuration needs to be manual for now. (if required)
- Ceph is still not integrated.