Most HPE servers have an Integrated Lights Out (iLO) management controller. Its original purpose is to remotely manage the server: turning on / off, intercepting the graphical console, connecting media devices – as the name “Lights-Out” illustrates – in the data center where HPE servers work, the administrator does not need to be around. All actions with servers can be performed from anywhere in the world. The iLO functionality has been constantly expanding and now it can be called a server flight control center, in fact, it is a mini-computer inside a large computer. The iLO has a processor, RAM and flash memory, an Ethernet port and, of course, a management interface: a web browser, command line, scripts and REST APIs. Through the REST API, automated management of HPE servers is carried out in accordance with the Redfish standard, which replaced the outdated IPMI.

The next layer of HPE infrastructure management is HPE OneView software. For rack and blade servers, c-Class is a virtual machine (all major hypervisors are supported), for the HPE Synergy platform, this is a hardware module – Composer. HPE OneView is managed in a similar way to iLO: web interface, scripts, and RESTful API / Redfish commands.

HPE OneView provides complete “low-level” server infrastructure management: BIOS setup, network interface configuration, SAN connectivity, volume creation on external storage systems (HPE Primera, HPE Nimble, HPE 3PAR), driver and firmware monitoring, and updates. All of these steps can be performed on one or more servers, either using the browser console or using PowerShell or Python scripts. But the most interesting results can be achieved by integrating OneView with the tools for deploying operating systems and applications. In this case, the administrator does not need to contact OneView at all, all the necessary actions are performed in the upstream management console. For example, vCenter serves as a single console for VMware, and Windows Admin Center for Microsoft.

REST and Redfish

If we talk about REST (Representational State Transfer), then it is a regular HTTP(s) request, passing the necessary data as request parameters. Unlike Redfish (a more modern version of REST), REST is not standardized in any way, it is just an architectural style that allows you to adhere to certain sequences such as request, request body, and request parameters. At the same time, which request tree, according to which standard the request body is transmitted (JSON, XML, or other), each manufacturer decides at its discretion. As a result, this led to the fact that if a user worked with REST interfaces from several vendors, then they required a different approach, and often a different set of code, which did not allow scaling solutions based on REST requests.

Unlike REST, Redfish is a standardized interface and allows a user to work with different vendors with the same approach and thus ensure the scalability of the solution. HPE introduced the Redfish standard in ILO4 (v2.30) and later.

HPE Deployment Automation Solution

When overcoming a certain number of information systems and an increase in requests from the business, the support department employees often come to the feasibility of automating daily, routine operations. This helps to introduce and maintain information systems faster and helps employees concentrate on more important tasks. Typically, administrators try to automate tasks on their own and using their usual means. A wide range of tools such as Ansible, Python, Puppet, and others help them in this. At the same time, as a rule, self-written scripts often have to be edited, especially when scaling a solution in a productive environment.

Deployment Automation Solution is a service for customizing an open-source solution to automate daily operations or their commercial counterparts that are already in use in the enterprise. Thus, consumers of the solution will be able to make edits, both in the solution itself, making it more tailored for a specific organization, and add their own developments to the solution, thereby expanding the functionality of the basic solution. Deployment Automation Solution is based on standard software components such as Ansible for automation and orchestration, Nginx for providing a library of microcode images, operating systems and configuration files, and GitLab as a way to centrally deliver scripts and Ansible playbooks. Thus, leveraging industry-standard tools through Ansible scripting linked to the underlying code repository and infrastructure DevOps pipeline through GitLab makes the approach systemic and scalable. Most of the components work in containers, which makes it possible to quickly deploy and update the solution itself.

The entire communication process is built on software-defined infrastructure through the use of existing rich OneView Ansible collection / REST APIs for HPE OneView management environment, or Redfish / iLO for managed environments without OneView, as well as data warehouse APIs. APIs of a specific software manufacturer are also used, for example:

• RHEL’s Ansible Playbooks can communicate with Linux servers over SSH;
• Connection to VMware can be done via REST API or SSH;
• Communication with Windows can be via WinRM.

For the convenience of orchestrating the solution and building complex automation workflows, AWX (https://github.com/ansible/awx, upstream project for Ansible Tower) or Ansible Automation Platform (https://www.ansible.com/integrations/infrastructure/ hpe) to bundle and encapsulate atomic infrastructure as basic code operations into automation workflows for provisioning and lifecycle management tasks. This modular approach allows flexible customization of the integration of hardware and software elements of the solution. At the same time, AWX, or Ansible Automation Platform is not a required attribute. All workflows are accessible through the REST API and can be called from any existing solution such as HPE ServiceNow or Morpheus. the solution is flexible enough to integrate with the management portal of each customer’s choice and provides integration with any third-party solution.

In its base solution, HPE provides two main use cases:

• Installation of operating systems, including setting up hardware components: presentation of storage volumes, setting up zoning for SAN, etc., as well as software components, including security settings and software manipulation;
• Updating microcodes, including without interrupting the work of servers.

This will give the customer access to a repository with playbook updates to support new scripts and components. Out of the box, the solution is tailored for the HPE hardware platform, including the latest hardware resources: DL Gen10, Synergy, Apollo, and 3PAR / Primera / Nimble, but open source and support for a variety of APIs will allow users to integrate third-party solutions.

Conclusion

The possibilities for automating daily IT operations are very wide: preparing and deploying new servers, connecting to data networks and storage systems, installing operating systems, monitoring and updating drivers and firmware, reconfiguring systems to meet changing application requirements.