AIX Patch Management With Ansible, and the Broader Benefits of Automation
I made one of the classic blunders during a recent trip to the Grand Canyon. This had nothing to do with a land war, or a Sicilian, but as an Arizona resident and avid hiker I should know better: always, always carry your water bottle, especially during the summer.
I venture to the Grand Canyon fairly often. This year alone I’ve been to the South Rim twice, in April and again in June. I’ve also traveled to the North Rim. I’ve hiked and/or biked while camping at Mather, Desert View and the North Rim campgrounds. Most recently, I was driving along the North Rim, making occasional stops at various scenic views and overlooks. Even though it wasn’t anything strenuous, as always, I packed my vehicle with salty snacks and plenty of water. Both are essential when engaging in physical activity in the desert.
However, at one stop, I left my water bottles—along with two 7-gallon containers of water and a cooler full of snacks—behind in my vehicle. I figured I wasn’t going far and that I’d quickly return. I figured wrong. The journey from the car to the overlook was longer than I realized, and the overlook itself branched out into multiple trails. Temps were only in the mid 90s, but with the elevation, low humidity, and lack of shade, the onset of thirst arrives pretty quickly. You can go from feeling fine to having a problem in the blink of an eye.
Of course my provisions did me no good sitting in the car. If I wanted to head out on the trails, I realized I had to first return to my vehicle. Once I’d hydrated and snacked, I loaded my day pack with more food and water. Now I was ready to go back to the overlook and check out the trails for a bit.
Systems Management Planning
In a similar vein, I believe it’s easy to underestimate what we’re getting ourselves into when managing our systems. On first glance we may think we can make a quick fix, but how often do seemingly minor issues end up being something more complicated? Or we may write a few simple scripts and then see that remedy balloon into a hodgepodge of methods and tools that differ from site to site, and sometimes even from admin to admin. Only then do we realize that what works across a handful of systems won’t cut it in a large environment of many systems.
Is there a way out of these dilemmas? Talor Holloway attempts to answer this question in his recent blog post, “AIX Patch Management with Ansible.”
He states: “Leading enterprises today use the Red Hat Ansible automation platform to provision, configure, manage, secure and orchestrate hybrid IT environments. A common misconception is that Ansible is just used to manage the Linux operating system. This is a false belief. Ansible supports Linux, Windows, AIX, IBM i and IBM z/OS environments. This blog will help AIX system administrators get started with Ansible on AIX, and introduce a patching use case … As enterprises move to a modern, enterprise-wide automation strategy with the Ansible automation platform, extending automation to AIX is a great method to simplify and develop consistency in the way AIX systems are supported, all while using the same automation tools that can be used across the enterprise.”
The Benefits of Automation
Automation enables us to do more with less effort, while greatly reducing the potential for human error. It allows us to standardize, allowing for uniformity of tens or hundreds of LPARs in a single environment.
Of course we still must do the work. Planning and testing, which have always been essential to systems management, are also critical with automated solutions. Make a mistake while implementing these tools and you could blow up several of your machines at once. Ultimately though, it’s worth the effort. The more we can automate, the easier our jobs will become. Automation saves time, time that we can spend more productively. In the big picture, we can redirect our newfound time into keeping our skills sharp and passing on our knowledge on to those who will eventually take our place on the raised floor.
VIOS Post-Migration Performance Tip, and Details on the POWER9-Based HMC CR2
On Twitter, Chris Gibson linked to an IBM support document that explains why the emfc_kpr process consumes so much CPU in AIX 7.2 following an upgrade to VIOS 3.1.
The emfc_kpr process is a kernel process that was added for handling the 16Gb and higher speed fibre channel adapters.
Instead of processing the threads via the protocol driver (as it works in previous releases), emfc_kpr process is now processing them.
If there are virtual FC adapters configured in the environment (with VFC), then emfc_kpr works in conjunction with the npivk process.
The emfc_kpr process (and npivk process in NPIV / VFC environment) processes will consume CPU as I/O is moved/passed through.
The doc goes on to explain that the emfc_kpr is designed to enhance the overall adapter driver performance, so despite its CPU usage, overall system performance should improve, though if high I/O throughput is in place, additional CPU resources may be needed.
In a recent Power VUG Technical Webinar Series presentation, Nigel Griffiths takes a “first look” at the new POWER9-based HMC CR2.
The Advanced Technology team were very impressed with the construction and design of the new POWER9-based HMC (7063-CR2). It operates very much like the older POWER8-based model (7063-CR1), but is faster. It is very much worth the upgrade if you still have the older & slower x86-based HMC. Make sure you are ready for your Power10 servers expected later in 2021, by having the new HMC up and running.
Watch the video replay and download the slides from the July 14 presentation here.