Qstack architects infrastructure into a self-service single pane of glass platform, that solves the fragmentation of IT management. This document outlines core Qstack concepts and how Qstack provides the ideal platform for any workload.
When configuring Qstack, users will arrange their cloud infrastructure using the following nomenclature: Regions, Zones, Pods, Clusters and Hosts. Once configured, Qstack installation is ready to use and end-users can begin to provision and manage instances.
Infrastructures are arranged in hierarchies with ‘Regions’ at the top of the hierarchical structure. Regions represent geographical locations e.g. separate private data center locations or public cloud regions.
Second in the hierarchy are ‘Zones’ that are used to map a deployment to a physical data center location. When configuring a Zone, the user can also configure networking properties such as VLANs and IP ranges.
A ‘Pod’ is the third level concept in the infrastructure hierarchy. Pods are a virtual grouping that can correspond to physical servers racks within a data center.
Following Pods, ‘Clusters’ are next in line in the infrastructure hierarchy. Clusters are a collection of hosts of the same type. For example, if the Cluster is composed of hypervisor hosts, they must be of the same hypervisor type. Shared storage is used for live workload migration in the cluster when taking down hosts for maintenance.
Last in the infrastructure hierarchy, are ‘Hosts’. Hosts represent physical machines that can, through Qstack, be provisioned by end-users for VM based workloads or as dedicated ‘bare metal’ workload servers.
Qstack supports many hypervisors and each hypervisor has its own unique characteristics. What Qstack calls a ‘Hypervisor’ are:
1) Hosts dedicated to running virtual machines
2) Dedicated servers – otherwise known as bare metal.
This naming convention is for simplicity’s sake because Qstack abstracts the complexities of each hypervisor away from the end user and that includes bare metal instances with no virtualization layer involved.
Qstack supports the industry standard KVM, VMware, and Hyper-V hypervisors and any dedicated server hardware that can provide IPMI or similar management capabilities.
KVM is the default bundled hypervisor in Qstack and requires zero config to set up. Qstack ships with a built-in network boot-services so new physical hosts can be auto-discovered and provisioned as KVM hypervisors simply by adding them to Qstack’s management network. Communications with the hypervisor host is done through an agent which is preinstalled on each auto-configured hypervisor host. Because KVM is the default hypervisor in Qstack, it does not require additional licensing to operate VM workloads.
Qstack deployment with KVM
VMware is the most commonly used virtualization technology used by enterprises today. From an end-user’s perspective, VMware behaves on Qstack much like its KVM counterpart; the differences can be seen on the administrative or infrastructure side of the Qstack. Qstack utilizes VMware’s vCenter to control VMs and discover hypervisor Hosts through the vCenter API. Qstack also integrates with vMotion to allow for better management of resources, general maintenance, etc.
Qstack deployment with VMware
In a recent Qstack release we added support for the increasingly popular Hyper-V. Hyper-V supports Windows Server 2012 R2 and Hyper-V 2012 R2. One of the features that sets Qstack apart from other CMPs using Hyper-V, is that it does not depend on System Center, which is an additional Microsoft component. Instead, Qstack communicates directly with the Hyper-V host API. Additionally, Qstack has built-in functionality that matches the other hypervisors — including live snapshotting and migration.
Qstack deployment with Hyper-V
Qstack workloads on bare metal work like on any other hypervisor from an end-user’s perspective even though bare metal is not technically a hypervisor. Qstack has a built-in PXE boot server, provisioned with preconfigured PXE templates and with images or “clones” of existing servers. Qstack has the ability to work with any modern, industry-standard hardware and has built in templates for the most commonly used operating systems making bare metal support incredibly easy to implement.
Each bare metal zone can be deployed with a flat network topology or with Qstack’s automatic physical switch support which allows for more advanced network topologies and bare metal multi-tenancy.
Also, just like for all supported hypervisors, Qstack supports a virtual serial/TTY browser based console view for bare metal servers. This enables secure multi-tenant management of the console screens of bare metal servers directly from the web user interface with no need to go through rigid and insecure vendor-specific solutions.
Qstack deployment with bare metal Hosts
Qstack with multiple hypervisors in separate Zones
There are two main network models in Qstack, typically defined on a ‘per zone’ basis. The first is a simple case that we call ‘basic’ networking which is essentially a flat network structure. The basic network is similar to the ‘AWS Classic’ networking mode, using security groups or firewalling to implement security.
The second networking model is what we call ‘advanced’ networking, which allows for even greater network security and implementation of dynamic VLANs. The advanced mode has an additional component, a Virtual Router, which operates as a gateway and firewall for the network. There is typically one VLAN per end-user account; however, each account can be defined as a ‘project’ for one user or shared between several users. In addition, there is also a private network that can be configured on a custom network like a 10.0.0.0/24, which can translate traffic in both directions–inbound and outbound from the private network to the outer network. The advanced networking model closely resembles the ‘AWS EC2 VPC’ networking mode.
Advanced networking mode in Qstack
‘Security Groups’ (to use a term borrowed from AWS), also known as firewalls in Qstack, are a way to group ports that can be open or closed and associated with a set of instances. Security Groups in Qstack can be altered at any time through a UI and API which makes it easy change port settings and also to set ingress rules for specified IP address ranges.
There are two types of vendor-agnostic Instance storage in Qstack. We call them Primary and Secondary storage.
Primary storage is used with live virtual machines and the backing technology can differ depending on the hypervisor used e.g. KVM might utilize local storage, NFS, or SAN; VMware might utilize VMFS which can be used with local storage; and Hyper-V can utilize Windows series protocol or SMB/CIFS.
Secondary storage is used for storing base operating system templates and custom templates as well as instance snapshots. Because the type of data on secondary storage is written with much less frequency, it can live on a slower storage option; however, it must be housed in mass storage – either NFS or SMB/CIFS – and can be backed up by object storage (S3 or Swift API).
Qstack’s web based user interface has different views for 3 types of user roles; end-users, admins and infrastructure operators. End-users can run any type of workload using the self service portal and admins can administer and support their departments and users, set permissions and quotas, generate usage reports etc. Infrastructure operators can focus on the infrastructure side of their hybrid cloud and easily setup new Zones and Regions and scale and maintain existing zones as well as create new compute and storage offerings for admins and end-users.
End-user created servers are called Instances in Qstack. This is a common term in cloud computing because the underlying server technology may differ but from an API perspective an instance is some kind of server. An Instance in Qstack can be a virtual machine or a physical machine (bare metal). Qstack automates the lifecycle of the Instance as well as network services, storage provisioning, IP pooling, firewalling and more.
In addition to managed Instances Qstack also manages end-user created Kubernetes clusters just like Google’s GKE but on your private infrastructure. End-users do not need any experience with Kubernetes to launch full blown stateful or stateless applications or microservices because Qstack automates the creation and configuration of Instances to deploy and maintain scalable Kubernetes clusters.
Qstack’s Kubernetes cluster management view
Leveraging Qstack’s core technologies i.e. the multitenant security model, storage abstraction, networking and load-balancer automation and hypervisor agnostic Instances – An end-user can start a new managed private or shared Kubernetes cluster simply by choosing a pre-packaged application from the Qstack UI. The cluster can then be customized using the Qstack UI or the standard kubectl command line tool or Kubernetes API.
Qstack managed Kubernetes brings the power of the excellent container scheduler without the complexities. The UI shows changes in real-time and knows what an Application is and how to install, configure, scale and even upgrade or downgrade an application using rolling updates. Qstack manages the Kubernetes backend and makes it easy to add Nodes (the Kubernetes term for workload Instances) or scale existing Nodes to increase workload capacity.
The role of Qstack’s Application Orchestration support is to accelerating DevOps success in companies not just for developers and operations but for any role so we made Helm, the Kubernetes application packaging format and cli tool, into a multitenant capable API and App store for end-users.
Qstack’s application orchestration creation wizard and app store
To further make Kubernetes clusters as easy to use as possible Qstack installs Cluster Services that help developers and other end-users create and debug their apps. Once a Kubernetes app or service is installed that requires persistent storage, firewall changes or publicly exposed load-balanced services Qstack’s Cluster Services will detect those requirements and automate the creation, formatting and mounting of persistent storage for the application, create the needed security groups and open up the necessary firewall ports as well as provision a software based load-balancer bound to a public IPv4 address. Just like for Instances Qstack also provides a browser based TTY console to any running container and additionally live logging and resource metrics that enable the end-user to easily create auto-scaling rules for their applications.
A multi-tiered application management view
API’s & Command Line Tools
All Qstack functionality is API driven and automatable from the infrastructure side to end-user workloads.
Qstack includes a hybrid native API that makes it possible to consume public cloud services just like Qstack controlled private infrastructure using encrypted and secured end-user api keys. The API is AWS EC2 compatible and by default supports AWS’s public cloud using the EC2 protocol and can also translate commands to the native API of other public clouds. This enables a seamless single pane of glass user interface and a single API for company wide infrastructure whether public or private and on any hypervisor.
Qstack’s hybrid cloud instances view
There are multiple command line tools and configuration management platforms that can control Qstack resources because of Qstack’s EC2 and Kubernetes compatibility including the official AWS and Kubernetes toolset. We have also made sure to make Qstack mashable with any cloud based services by providing a Hashicorp Terraform plugin.
This article hopefully gave you a good high level overview of Qstack’s architecture and its core concepts. For more information go to the official Qstack documentation. Also for a detailed presentation of Qstack’s architecture, tune into this webinar or request a personalized demo!