The basic OpenStack TripleO deployment utilises the so called provisioning / control plane network for all types of traffic (internal API, tenant, storage, storage management, etc…), that run across the whole OpenStack installation. The Undercloud node, which is used for Overcloud deployment, becomes a kind of a gateway for Overcloud nodes to the external network. This solution has a major disadventage: the single point of access which is here the Undercloud node, can quickly turn into a single point of failure, if Undercloud fails, cutting us out from Overcloud nodes. Moreover, any diagnostic steps, in case of network issues, bottle necks, etc., become more difficult , since all the traffic runs in one big tube, which is provisioning / control plane network.
Continue reading “OpenStack Pike TripleO Overcloud Deployment using VLAN based Network Isolation”
Category: Cloud Computing
Extending Minimum Time Between IPMI Operations in OpenStack Ironic
In TripleO based installations of OpenStack the deployment of Overcloud nodes is coordinated by so called Ironic module, which was developed in general to deploy OS on bare metal servers. There is a number of IPMI (Intelligent Platform Management Interface) drivers supported by Ironic, like pxe_ilo for HP Proliant Gen8+, pxe_drac for DELL 12G+, ipmi for generic servers, etc… In case of the generic ipmi driver, Ironic script, which is installed on undercloud (or OSP director), uses a Linux command line ipmitool to send IPMI messages to the Overcloud nodes to control them during TripleO deployment.
Continue reading “Extending Minimum Time Between IPMI Operations in OpenStack Ironic”
OpenStack Pike TripleO Undercloud and Overcloud Deployment on 3 Bare Metal Servers
Nowadays Packstack based OpenStack installations are used for proof-of-concept and demonstration purposes only. The official RDO community points TripleO (OpenStack On OpenStack) as a recommended OpenStack deployment method for production cloud. TripleO is an automated installation tool, based on Ironic OpenStack node provisioning software, intended for deployments on bare metal servers, that is, on physical hardware. TripleO generally requires using servers equipped with BMC (Baseboard Management Controller) or IPMI (Intelligent Platform Management Interface) modules, like HPE iLO (integrated Lights Out) in order to be able to manage and controll servers during OpenStack deployment, maintenance and node introspection procedures.
Continue reading “OpenStack Pike TripleO Undercloud and Overcloud Deployment on 3 Bare Metal Servers”
MariaDB high CPU usage in OpenStack Pike
Testing OpenStack Pike after Packstack based deployment I realised MySQL daemon was utilizing 100% CPU resources without any specific reason, but I had never faced such problem before in previous OpenStack releases. The problem also has never appeared during my TripleO based OpenStack Pike deployments, so looks like it’s strictly Packstack related issue.
The situation heppened on few bare metal installations on pretty powerful servers. Restarting mariadb service was helpful just for the first few minutes after service restart, then the problem would happen again and again, what resulted in frequent Horizon Dashboard and Keystone inaccessibility and partial Controller unavailability.
Continue reading “MariaDB high CPU usage in OpenStack Pike”
OpenStack Pike VLAN and Flat network based installation using Packstack
In previous articles regarding OpenStack RDO installations we presented OpenStack deployments using Packstack automated installer script, which still required some post-installation networking configuration to be performed in order to accomplish whole deployment. This time we will try to prepare Packstack configuration file (answers.txt) in such way, that it does all the magic and no post-installation configuration is required. We will make full bridge:interface mapping so, that no further bridge setup is needed and the environment should be ready to use immediately after Packstack deployment.
Continue reading “OpenStack Pike VLAN and Flat network based installation using Packstack”
How to find qbr,qvo interfaces of the particular Instance in OpenStack
OpenStack networking topology is pretty complicated structure, even with it’s, let’s say, default configuration based on OVS (OpenVSwitch), not even mentioning about additional overlays, like OpenDaylight or Nuage.
If you are troubleshooting network issues in regard to a particular Instance (VM), it’s good to locate network overlay interfaces (qbr, qvo) assigned to that Instance to have a starting point to begin your network analysis from. You can then analyze inbound/outbound traffic on those interfaces using network protocol analyzers, like tcpdump/wireshark.
Below you can find few steps, how to locate qbr,qvo interfaces belonging to a particular Instance:
Continue reading “How to find qbr,qvo interfaces of the particular Instance in OpenStack”
Deploy project tenant in OpenStack using Heat orchestration stack
Heat is an OpenStack Orchestration service, which implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code. Heat service is able to read YAML (.yaml, .yml) files and perform different tasks inside OpenStack environment included in YAML components. Using Heat Orchestration we can create instances, networks or even whole tenants with just single mouse click in OpenStack dashboard (Horizon), if we have previously prepared YAML file with Heat instructions to be performed in OpenStack cloud.
In this tutorial we will create example .yaml file for Heat orchestration containing instructions and components needed to deploy project tenant in OpenStack and launch instances inside the tenant. Next, we will create our stack on single OpenStack all-in-one node based on CentOS 7.3 operating system.
Continue reading “Deploy project tenant in OpenStack using Heat orchestration stack”
Create tenant in OpenStack Newton using command line interface
OpenStack comes out of the box with it’s dashboard called Horizon. Horizon provides GUI, which let us manage our OpenStack environment in pretty easy and inuitive way. However basic tasks, like tenant creation or instance commissioning, can be time consuming when performed in Horizon. Using command line interface with previously prepared command templates can be more efficient and faster.
In this tutorial we present how to create Project Tenant in OpenStack Newton using command line intrerface and launch Cirros based Instances inside the Tenant.
Some time ago OpenStack Community introduced new tool called OpenStackClient (OSC) with it’s openstack command utility to unify OpenStack management, which encompasses the following components: Compute, Identity, Image, Object Storage and Block Storage APIs. So far keystone command utility was withdrawn from OpenStack as deprecated and replaced by mentioned openstack command utility. In this tutorial for Newton release we are going to use openstack commands where possible to become familiar with OpenStackClient CLI.
Continue reading “Create tenant in OpenStack Newton using command line interface”
Install OpenStack Newton All In One with Heat Service on CentOS 7
In OpenStack all-in-one configuration all OpenStack nodes (controller node, compute node, network node) are installed on a single machine. All in one configuration can be quickly deployed for testing purposes and is often recommended for developers to test their applications on top of OpenStack environment.
In this tutorial we install OpenStack Newton release from RDO repository including Heat Orchestration service on single node (all-in-one installation) based on CentOS 7 / RHEL 7 using packstack installer script.
Continue reading “Install OpenStack Newton All In One with Heat Service on CentOS 7”
OpenStack Newton VXLAN based installation on 3 CentOS 7 nodes
OpenStack is a free and open source cloud computing platform developed as a joint project of Rackspace Hosting and NASA, consisting of many well know technologies like: Linux KVM, LVM, iSCSI, MariaDB (MySQL), RabbitMQ or Python Django.
In our previous articles we presented OpenStack installations based on VLAN internal networking.
In this article we will install OpenStack Newton release from RDO repository on three CentOS 7 based nodes (Controller, Network, Compute), but this time, unlike our previous articles, we will use VXLAN based internal networking for communication between Nova Instances.
Continue reading “OpenStack Newton VXLAN based installation on 3 CentOS 7 nodes”