Home Bare Metal The Cloudification of Bare Metal

The Cloudification of Bare Metal

by Vamsi Chemitiganti

It is hard to believe that back in the day, every server was a bare-metal server. After all almost two decades of virtualization technology, bare metal servers are making a comeback at least from what I can tell in my almost daily engagement with enterprise technologists. The reasons are manifold ranging from the maturity & robustness of Bare Metal provisioning projects (such as OpenStack Ironic) which enable the pooling, sharing and cloud-like provisioning of these servers. Bare metal servers are also key in achieving the multitude of Edge computing use-cases covered in various posts here – http://www.vamsitalkstech.com/?s=edge

A Quick Definition of Bare Metal

Definitions first, a bare-metal server is a single-tenant server that is physical and by extension not shared by other tenants.  They are different from their VM cousins in that they’re neither virtualized and typically are dedicated to a single team. The single-tenant thus has complete access to all of the resources on the server. What makes bare-metal servers all the more useful in a hybrid cloud is that both their provisioning process and their ability to run workloads can be integrated with those on VMs – thus leading to a mix-and-match paradigm.

The “Bare Metal as a Service” Workflow

Bare metal infrastructure once had a reputation for being difficult to deploy and operate at scale, however, with the emergence of projects such as Ironic, it has now become way easier to take leverage these for enterprise use cases.

Bare Metal provisioning follows the above generic workflow

The cycle of Bare Metal provisioning generally follows the below workflow –

  • servers are discovered and then bootstrapped
  • a cloud controller allocates these to users typically using a UI or API
  • a full certified, secure and compliant Linux OS is deployed on the server along with any other application software as applicable. All of this is done in an automated fashion
  • these instances are made available in a pool, much like VMs orchestrated by a cloud controller
  • applications running on these servers are made available to users

The most popular bare metal provisioning technology is Ironic, which is an OpenStack project. Ironic can be used either standalone or alongside a regular VM based Openstack cloud. It performs this via integration with other projects in the ecosystem –  OpenStack Identity (keystone), Compute (nova), Network (neutron), Image (glance), and Object (swift) services. Ironic manages hardware through general protocols such as PXE/IPMI and also using hardware OEM specific remote management protocols e.g. Cray, Fujitsu, Dell, etc. Using Ironic APIs, projects such as Nova can manage bare metal servers as though they’re virtual.

The OpenStack Foundation recently announced that Ironic is powering millions of cores of compute all over the world, turning bare metal into automated infrastructure ready for today’s mix of virtualized and containerized workloads.

Ironic Deployment Architecture

OpenStack Ironic allows users to manage bare metal infrastructure like they would virtual machines. Thus Ironic enables the above ‘bare metal as a service’ workflow.

This Ironic service consists of the following main components:

  1. The Ironic API: This API is a RESTful API that interfaces with cloud admin to process user requests. It does this by forwarding them to the Ironic Conductor via RPC.  The API component can be run as a separate process.
  2. Ironic conductor:  The conductor is the main component that provisions the bare-metal servers and manages their lifecycle. Using IPMI or vendor-specific management tool, the conductor starts and stops the servers.
  3. Ironic Python Agent: The agent runs on the deploy server and provides the conductor with remote access for band hardware control and hardware introspection.

Ironic Deployment Architecture [1]

As illustrated above, the cloud admin uses the Ironic RESTful API service to enroll perform the provisioning lifecycle shown above in the first diagram.  Multiple instances of the API service can be running so that the cloud admin can register the hardware while providing properties such as MAC addresses and IPMI credentials.  The Ironic conductor then carries out the work and is typically running on a separate host. It is the only component common to both the data plane and the  IPMI control plane. Multiple instances of the conductor are recommended to be run so it can support various drivers as applicable and also for failover purposes.

The Ironic API supports exposing the list of supported drivers as well as the conductor hosts that support provisioning using those drivers.

Advances in the Ironic project over the last 18 months have improved the overall provisioning process from a performance and speed standpoint. For instance, the OpenStack Rocky release included a RAMdisk interface that allows clusters of bare-metal servers to have their images booted from the main memory as opposed to using storage. Ironic also supports the configuration of high-speed features such as SR-IOV which speed up packet processing. Recovery from power faults is now automatic thus resolving a long-standing complaint with the project. The latest OpenStack release – Train has experimental support for building software RAID [2].

As with other OpenStack projects, Ironic plugins can be used not just with server OEMs such as Dell, HP but also with networking vendors such as Juniper, Cisco, Arista which allows network automation (e.g virtual LAN configuration).

Bare Metal In Banking and Telecommunications

The telco & the communication service provider (SP) vertical has been a huge focus of mine in both 2018 and 2019. I have captured some insights in a previous post. In 2019, the OpenStack Foundation announced that Ironic is powering millions of cores of compute. A lot of those workloads were in the financial services and the SP (service provider) space.

Why Cloud Native Technology Will Drive The Service Provider (SP) Market in 2020

Openstack has become an essential choice in these industries both from the perspective of hosting business applications as well as running NFV (Network Functions Virtualization) services. Ironic and bare-metal provisioning becomes especially important from a carrier-grade performance and scalability standpoint. While VNF technology has been dominated by VMs, their successor CNF (Container Network Functions) will likely trend bare metal. As SP’s move into CNF, they should be able to realize all the advantages of containers and bare metal infra – higher density, platform independence, faster DevOps cycles, and increased automation.

The Benefits of Bare Metal

The biggest benefit of bare metal provisioning in addition to performance and hard multitenancy is time savings.  Ironic can take the time down to provision bare metal servers from weeks to seconds or minutes. Thus, bare-metal servers can help accelerate customers’ time to value. At Platform9, our heavy use of Ironic results in huge value in our customer environments. We have taken an erstwhile manual ticketing process that encompasses racking and stacking, switch configuration, network configuration, server provisioning to OS image deployment to a totally automated all via simple single-click self-service experience. At Platform9 we also provide an operations console that provides complete visibility of all the regions and the bare metal/virtualized/ public cloud resources within. For bare-metal servers, this provides a view of the inventory in terms of their location (racks, etc.) and their specific configurations (CPU, RAM, storage and special hardware such as GPU).

Now, let us change gears and build on the concepts discussed above. Many posts in this blog have discussed how Kubernetes will be the universal standard for the containerized application lifecycle. The key manner in which Kubernetes augments containerized bare-metal deployments is by raising the notion of multitenancy up to at the application layer. Thus a fleet of bare-metal servers can be single-tenant (e.g an organization or a department) yet run many different applications. In the New Year, we will discuss best practices and key considerations in running Kubernetes clusters on bare-metal servers.

References

[1] Ironic Project at OpenStack foundation – https://docs.openstack.org/ironic/

[2]  Highlights in OpenStack Train release – https://docs.openstack.org/releasenotes/ironic/train.html

Discover more at Industry Talks Tech: your one-stop shop for upskilling in different industry segments!

You may also like

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.