
Enhancing Satellite Node Management at Scale
Tue, 15 Mar 2022 20:30:40 -0000
|Read Time: 0 minutes
Satellite nodes are a great addition to the VxRail portfolio, empowering users at the edge, as described in David Glynn’s blog Satellite Nodes: Because sometimes even a 2-node cluster is too much. Although satellite nodes are still new, we’ve been working hard and have already started making improvements. Dell’s latest VxRail 7.0.350 release has a number of new VxRail enhancements and in this blog we’ll focus on these new satellite node features:
- Improved life cycle management (LCM)
- New APIs
- Improved security
Improved LCM
The first way we’ve improved satellite nodes is by reducing the required maintenance window. To do this, the satellite node update process has now been split in two. Instead of staging the recovery bundle and performing the update in one step, you can now stage the recovery bundle and perform the update separately.
Staging the bundle in advance is great because we know bandwidth can be limited at the edge and this allows ample time to transfer the bundle in advance to ensure your update happens during your scheduled maintenance window. Once your bundles are staged, it’s as simple as scheduling the updates and letting VxRail execute the node update. This improvement ensures that you can complete the update within the expected timeframe to minimize downtime. Satellite nodes sit outside the cluster and, as a result, workloads will go offline while the node is updated.
New APIs
Do you have a large number of edge locations that could use satellite nodes and need an easier way to manage at scale? Good news! These new APIs are perfect for making edge life at scale easier.
The new APIs include:
- Satellite node LCM
- Add a satellite node to a managed folder
- Remove a satellite node from a managed folder
The introductory release of VxRail satellite nodes featured LCM operations through the VxRail Manager plug-in, which could be quite time consuming if you are managing a large number of satellite nodes. We saw room for improvement so now administrators can use VxRail APIs to add, update, and remove satellite nodes to simplify and speed up operations.
You can use the satellite node LCM API to adjust configuration settings that benefit management at scale, such as adjusting the number of satellite nodes you want to update in parallel. For example, although the default is to update 20 nodes in parallel, you can initiate updates for up to 30 satellite nodes in parallel, as needed.
There is also a failure rate feature that will set a condition to exit from an LCM operation. For example, if you are updating multiple satellite nodes at one time and nodes are failing to update, the failure rate setting is a way to abort the operation altogether if the rate surpasses a set threshold. The default threshold is 20% but can be set anywhere from 1% to 100%. Using the VxRail API, you can adjust settings like this that are not available in the VxRail Manager.
These new APIs are great for users with a large number of VxRail satellite nodes. Adding, removing, and updating satellite nodes can now be automated through the new APIs, saving you precious time across your edge locations.
Improved Security
VxRail satellite nodes can now use Secure Enterprise Key Management (SEKM), made available through the Dell PowerEdge servers that VxRail is built on. What is SEKM you might ask? Well, SEKM gives you the ability to secure drive access using encryption keys stored on a central key management server (not on the satellite node).
SEKM is great for many reasons. First, an edge location might be more exposed and have less physical security than your typical data center but that doesn’t mean securing your data is any less important. SEKM keeps your data drives locked even if the entire server is stolen. When paired with self-encrypting drives, you can secure the data even further. Second, the encryption keys are stored in a centralized location, making it easier to manage the security of large numbers of satellite nodes instead of having to manage each satellite node individually.
In this blog we’ve highlighted some exciting new satellite node features, including an improved update process, new APIs, and enhanced security, all of which enhance managing the edge at scale. Check out the full VxRail 7.0.350 release and see the full list of enhancements by clicking the link below.
Thanks for reading!
Resources
Author: Stephen Graham, VxRail Tech Marketing
Related Blog Posts

Infrastructure as Code with VxRail Made Easier with Ansible Modules for Dell VxRail
Tue, 15 Nov 2022 16:27:36 -0000
|Read Time: 0 minutes
Many customers are looking at Infrastructure as Code (IaC) as a better way to automate their IT environment, which is especially relevant for those adopting DevOps. However, not many customers are aware of the capability of accelerating IaC implementation with VxRail, which we have offered for some time already—Ansible Modules for Dell VxRail.
What is it? It's the Ansible collection of modules, developed and maintained by Dell, that uses the VxRail API to automate VxRail operations from Ansible.
By the way, if you're new to the VxRail API, first watch the introductory whiteboard video available on YouTube.
Ansible Modules for Dell VxRail are well-suited for IaC use cases. They are written in such a way that all requests are idempotent and hence fault-tolerant. This means that the result of a successfully performed request is independent of the number of times it is run.
Besides that, instead of just providing a wrapper for individual API functions, we automated holistic workflows (for instance, cluster deployment, cluster expansion, LCM upgrade, and so on), so customers don't have to figure out how to monitor the operation of the asynchronous VxRail API functions. These modules provide rich functionality and are maintained by Dell; this means we're introducing new functionality over time. They are already mature—we recently released version 1.4.
Finally, we are also reducing the risk for customers willing to adopt the Ansible modules in their environment, thanks to the community support model, which allows you to interact with the global community of experts. From the implementation point of view, the architecture and end-user experience are similar to the modules we provide for Dell storage systems.
Getting Started
Ansible Modules for Dell VxRail are available publicly from the standard code repositories: Ansible Galaxy and GitHub. You don't need a Dell Support account to download and start using them.
Requirements
The requirements for the specific version are documented in the "Prerequisites" section of the description/README file.
In general, you need a Linux-based server with the supported Ansible and Python versions. Before installing the modules, you have to install a corresponding, lightweight Python SDK library named "VxRail Ansible Utility," which is responsible for the low-level communication with the VxRail API. You must also meet the minimum version requirements for the VxRail HCI System Software on the VxRail cluster.
This is a summary of requirements for the latest available version (1.4.0) at the time of writing this blog:
Ansible Modules for Dell VxRail | VxRail HCI System Software version | Python version | Python library (VxRail Ansible Utility) version | Ansible version |
1.4.0 | 7.0.400 | 3.7.x | 1.4.0 | 2.9 and 2.10 |
Installation
You can install the SDK library by using git and pip commands. For example:
git clone https://github.com/dell/ansible-vxrail-utility.git cd ansible-vxrail-utility/ pip install .
Then you can install the collection of modules with this command:
ansible-galaxy collection install dellemc.vxrail:1.4.0
Testing
After the successful installation, we're ready to test the modules and communication between the Ansible automation server and VxRail API.
I recommend performing that check with a simple module (and corresponding API function) such as dellemc_vxrail_getsysteminfo, using GET /system to retrieve VxRail System Information.
Let's have a look at this example (you can find the source code on GitHub):
Note that this playbook is run on a local Ansible server (localhost), which communicates with the VxRail API running on the VxRail Manager appliance using the SDK library. In the vars section, , we need to provide, at a minimum, the authentication to VxRail Manager for calling the corresponding API function. We could move these variable definitions to a separate file and include the file in the playbook with vars_files. We could also store sensitive information, such as passwords, in an encrypted file using the Ansible vault feature. However, for the simplicity of this example, we are not using this option.
After running this playbook, we should see output similar to the following example (in this case, this is the output from the older version of the module):
Cluster expansion example
Now let's have a look at a bit more sophisticated, yet still easy-to-understand, example. A typical operation that many VxRail customers face at some point is cluster expansion. Let's see how to perform this operation with Ansible (the source code is available on GitHub):
In this case, I've exported the definitions of the sensitive variables, such as vcpasswd, mgt_passwd, and root_passwd, into a separate, encrypted Ansible vault file, sensitive-vars.yml, to follow the best practice of not storing them in the clear text directly in playbooks.
As you can expect, besides the authentication, we need now to provide more parameters—configuration of the newly added host—defined in the vars section. We select the new host from the pool of available hosts, using the PSNT identifier (host_psnt variable).
This is an example of an operation performed by an asynchronous API function. Cluster expansion is not something that is completed immediately but takes minutes. Therefore, the progress of the expansion is monitored in a loop until it finishes or the number of retries is passed. If you communicated with the VxRail API directly by using the URI module from your playbook, you would have to take care of such monitoring logic on your own; here, you can use the example we provide.
You can watch the operation of the cluster expansion Ansible playbook with my commentary in this demo:
Getting help
The primary source of information about the Ansible Modules for Dell VxRail is the documentation available on GitHub. There you'll find all the necessary details on all currently available modules, a quick description, supported endpoints (VxRail API functions used), required and optional parameters, return values, and location of the log file (modules have built-in logging feature to simplify troubleshooting— logs are written in the /tmp directory on the Ansible automation server). The GitHub documentation also contains multiple samples showing how to use the modules, which you can easily clone and adjust as needed to the specifics of your VxRail environment.
There's also built-in documentation for the modules, accessible with the ansible-doc command.
Finally, the Dell Automation Community is a public discussion forum where you can post your questions and ask for help as needed.
Conclusion
I hope you now understand the Ansible Modules for Dell VxRail and how to get started. Let me quickly recap the value proposition for our customers. The modules are well-suited for IaC use cases, thanks to automating holistic workflows and idempotency. They are maintained by Dell and supported by the Dell Automation Community, which reduces risk. These modules are much easier to use than the alternative of accessing the VxRail API on your own. We provide many examples that can be adjusted to the specifics of the customer’s environment.
Resources
To learn more, see these resources:
- On-demand recording of the recent Tech Exchange Live session: "Infrastructure as Code with VxRail," where I dive a bit deeper into the Ansible Modules for VxRail, and my colleague Steffen from VMware discusses the basics of Terraform integration with VxRail.
- Ansible Modules for Dell VxRail on GitHub, which is the central code repository for the modules. It also contains complete product documentation and examples.
- Try the new VxRail API Hands-on-Lab available in the Dell Technologies Demo Center, which we introduced at Dell Technologies World earlier this year. Module 3: Cluster Expansion or Scaling Out allows you to get hands-on experience with the modules without the need to have access to a VxRail system. Your Dell account team can help you access the lab.
The following links provide additional information:
- YouTube video: Ansible Modules for Dell VxRail
- Dell Automation Community
- YouTube video: Level up your HCI automation with VxRail API
- Blog: VxRail API—Updated List of Useful Public Resources
Author: Karol Boguniewicz, Senior Principal Engineering Technologist, VxRail Technical Marketing
Twitter: @cl0udguide

Easing Life Cycle Management with VxRail
Thu, 13 Oct 2022 22:47:20 -0000
|Read Time: 0 minutes
This is the second article in a series introducing VxRail concepts.
I mentioned in the introduction blog that I previously worked in Technical Support for Dell. That experience really set the stage for me to embrace VxRail because the VxRail approach to life cycle management eases a lot of the pain points I saw in support engagements. Many of the issues I saw were resolved with system updates, and VxRail makes moving through the life cycle significantly easier than with traditional hardware or an internally built solution. We do this with our state management model, known as Continuously Validated States. Let’s take some time to understand what these are, because they help enable VxRail customers to do more with their infrastructure more easily than before.
Defining a state
I’m someone who likes to be thorough, so if you already understand what a system state is, then you can skip this section. But for readers newer to infrastructure, this might be a different way to think about things. A system state, be it good or bad, refers to the hardware, firmware, drivers, and system software that power the infrastructure. When your servers or clusters are in a “good” or “happy” state, then everything is working optimally. A “bad” or “faulty” state might have a compatibility issue creating crashes, or it might contain failed hardware. Replacing failed hardware is an example of modifying the hardware state. Modifying the software state might look like an update to VMware software. All these changes then represent new individual states.
VxRail takes the chaos out of traditional state management for customers and replaces it with confidence. VxRail Continuously Validated States make the exchange from chaos to confidence possible. Updating a cluster, such as to a new vCenter version, means changing a cluster, and that change introduces uncertainty. That uncertainty is natural because customers are moving their infrastructure into new unknown configurations.
Let’s discuss the “Validated” portion of Continuously Validated States. VxRail engineering validates the current state, the state you intend to go to, and the continuity through the update cycle. Customers can gain tremendous value by relying on VxRail Engineering to validate all three aspects of an upgrade. This is the “Validated” part of Continuously Validated States that completely inverts the experience I got used to while working in Technical Support.
Moving to a new state
When you make a change, such as adding a driver or updating system software, you are modifying the system state. Making changes to system states has always been a problem with different remediation strategies that have revealed new IT challenges. I believe the challenge that Continuously Validated States best addresses can be described as, “I need my infrastructure to help me respond to new business needs and make moving through the life cycle as easy as possible.” Modifying an HCI cluster designed internally would present additional difficulties because you don’t know what kind of behavior to expect without testing.
This kind of change anxiety is what the validation process in our state-creation process aims to correct. Before the VxRail Engineering team releases a new VxRail update package—a package that would change your cluster’s system state, the package is tested in the team’s dedicated testing facility for nearly 800,000 cumulative hours. The facility has comprehensive access to the hardware that VxRail supports, allowing thorough testing. The purpose of this testing is to first ensure that all the new supported configurations are stable and then ensure that the move from old cluster states to the new states is a reliable process.
Lifecycle continuity
The creation of a series of known-good configurations isn’t the only benefit VxRail can provide with this different approach to state management. Let’s talk about the continuity that Continuously Validated States provide. VxRail clusters spend their entire lives conforming with and moving between different configurations supported and defined by the Continuously Validated State. This creates a continuity that begins from the time a cluster is first unloaded from the truck, persists through the changes of both the update cycle and hardware modification, and continues on to the final point of cluster retirement.
Let’s tie these ideas together. I like to think of Continuously Validated States as being like a GPS that helps avoid road construction during a cluster’s life. VxRail can do this because our engineering teams are building the roads and identifying the best routes. Go ahead and imagine a map for me. I like to imagine a map of my home state. No matter what kind of map, it’s going to have a bunch of points and show you how to move from one point to another. Continuously Validated States serve a similar role for your clusters. Much like the points on your map, each of these states verifies new hardware and software versions for customers to move their clusters to. These states serve another role like that of a GPS—they help identify the ideal paths between states and help clusters efficiently move between them. As you might have guessed, the Continuously Validated States model isn’t simple cartography. This ideal path is identified through hundreds of thousands of testing hours performed by VxRail Engineering team members in a massive million-dollar lab environment. Those movement paths, in combination with software tooling in the update process, create continuity for clusters as they move between states and proceed through their life cycles.
Conclusion
Hopefully, this blog has helped distinguish how Continuously Validated States change configuration management for the better. Changing the configuration state of production clusters is an anxiety-generating action that VxRail eases by creating, testing, and validating known-good configuration states for customers. The result is that customers can update their equipment with more confidence than ever and spend more IT resources focused on enabling business projects than on performing maintenance tasks. Mike Athanasiou, a colleague of mine, did a fantastic job with our Interactive Journey video series. In the videos, Mike shows how the use of Continuously Validated States enhances different areas of cluster management. I found the videos helpful in better understanding VxRail.
The next entry in this blog series will address the advantage that VxRail offers in the update process.