Over the past two decades, enterprise IT architecture has undergone a dramatic transformation. What began as siloed, three-tier environments has evolved through converged and hyper-converged infrastructure (HCI) to today’s cutting-edge disaggregated platforms. This journey is more than a story of hardware innovation-it’s the foundation for the next era of data-driven business, especially as generative AI (GenAI) workloads reshape the technology landscape.
From Three-Tier to Hyper-Converged: The Drive for Simplicity
Three-tier architecture-with separate compute, storage, and networking-offered flexibility, but at the cost of complexity and inefficiency. IT teams often faced overprovisioning, stranded resources, and operational headaches.
The arrival of converged infrastructure bundled these elements into pre-validated stacks, simplifying procurement and deployment. Yet, the fundamental silos remained, limiting agility and resource utilization.
Hyper-converged infrastructure (HCI) took consolidation further by merging compute and storage into modular nodes managed by software. According to Fortune Business Insights, the global HCI market is projected to reach $65 billion by 2029, reflecting enterprises’ desire for simplified management and scalability. However, HCI’s tightly coupled design makes it difficult to scale compute and storage independently-a critical limitation for today’s AI and data-intensive workloads.
The Rise of Disaggregated Platforms: Built for GenAI
Enter disaggregated infrastructure: an architecture that decouples compute, storage, and networking into independent resource pools. This approach is rapidly gaining traction, with the composable/disaggregated infrastructure market expected to triple to over $19 billion by 2029 (MarketsandMarkets).
Why Disaggregation Matters-Especially for GenAI
Independent Scaling GenAI workloads are unpredictable and data-hungry. Disaggregated platforms allow organizations to scale storage for massive datasets or add GPU-rich compute nodes as needed-without unnecessary overprovisioning.
Superior Resource UtilizationDell reports that disaggregated architectures can deliver “orders of magnitude higher” core utilization and reduce server and software licensing costs by up to 50%.
Performance for AI Technologies like NVMe-over-Fabrics and CXL memory pooling enable low-latency, high-throughput access to data-keeping GPUs saturated and AI pipelines moving at full speed.
Hybrid and Edge Flexibility Disaggregated storage and compute pools can be orchestrated across on-premises, cloud, and edge environments, supporting the distributed nature of modern AI applications.
Many vendors/startups are rapidly evolving their portfolio to embrace disaggregation, making it the new default for enterprises scaling GenAI and other advanced workloads.
Edge AI is now viable, with lightweight models running inference on disaggregated clusters far from the data center.
The shift to disaggregated infrastructure is not just a technological trend-it’s a strategic imperative for organizations embracing GenAI and next-generation workloads. By enabling independent scaling, maximizing resource efficiency, and supporting hybrid deployment models, disaggregated platforms are redefining what’s possible in the data center.
In the age of AI, flexibility is the ultimate competitive advantage. Is your infrastructure ready?
Let’s connect and discuss how your organization can leverage disaggregated architectures to accelerate GenAI and future-proof your digital transformation.
Artificial Intelligence (AI) has revolutionized businesses, streamlining and optimizing operations while increasing efficiency and productivity. However, companies often face challenges in the implementation and management of AI; this could either be a failure to identify the appropriate use cases for AI or guaranteed functionality and efficiency.
AI adoption calls for a comprehensive understanding of its lifecycle, and companies need to make sure they focus on three critical areas – Silicon, Software, and Services.
In this blog post, we’ll delve into these areas, their importance, and their relevance in the AI Lifecycle.
Silicon: Silicon-based chips, are a foundational material in modern AI infrastructure. It comprises traditional components such as the central processing unit (CPU), the graphics processing unit (GPU), memory, network, and data storage. A scalable and resilient AI infrastructure creates a solid foundation for enterprise deployment, capable of supporting complex algorithms, data storage, and analysis. A robust infrastructure facilitates the acceleration of the AI process, enabling businesses to handle large amounts of data and process information in real-time. Therefore, reliable modern infrastructure components are essential for AI success.
The use of modern AI infrastructure also allows for optimal performance. Modern silicon-based processors are specifically designed for tasks such as machine learning and intensive data processing. They offer high computational power, increased energy efficiency, and real-time parallelism capabilities. This combination of performance and efficiency ensures the smooth operation of AI applications, providing users with fast and accurate results.
Furthermore, it plays a crucial role in the data storage and transmission of data required for AI. Modern data infrastructure enables quick access to large data sets making sure processing cycles are not wasted. Additionally, modern networking facilitates fast and reliable data transfer between different components of the AI infrastructure.
Silicon is the essential element of modern AI infrastructure. With its high performance, energy efficiency, and data storage and transmission capabilities, silicon enables businesses to successfully deploy advanced AI solutions.
Software: The software layer is equally as important as the hardware layer and is a critical component of the overall AI ecosystem. The software layer encompasses a wide range of AI algorithms that support the general AI infrastructure to achieve business outcomes.
These AI ecosystem can vary from simple “no-code” tools that allow users to manage AI operations and pipelines, to “Super User” tools that assist users in building and operating flexible and precise AI models. These tools are vital in identifying the necessary AI use cases and implementing optimal solutions. In your AI journey, there must be a recognition of different types of software to streamline AI operations, manage costs, and ensure maximum efficiency. By understanding the software layer of AI, businesses can establish a solid foundation to harness the full potential of this groundbreaking technology.
AI software ecosystem is dynamic and evolving rapidly. Below is the AI software market glance from IDC’s point of view.
Services: Services play a critical role in the AI ecosystem. The tools and software utilized in the AI lifecycle are still new and evolving, which is why services are crucial to ensuring smooth integration and efficient operation. Services have so far been ignored by most businesses, but as AI operations become more complex, businesses need to incorporate them into their operations to avoid operational challenges. The services layer includes workforce preparedness to scale and support AI operations, operationalizing data management and analytics workloads, and delivering workload automation.
Understanding the AI lifecycle is critical for implementing and maintaining AI solutions successfully; companies should prioritize and focus on the Silicon, Software, and Services layers. It is crucial to have a reliable infrastructure regardless of the hardware used and to implement software tools that correlate with the AI problems faced to ensure smooth operations. Finally, businesses must recognize the pivotal role played by the services layer and adequately plan for its integration into their AI ecosystem.
In summary, businesses that identify the appropriate use cases for AI and implement optimal solutions will reap numerous benefits and gain a competitive edge in today’s fast-paced technological environment. Here are my 3 suggestions to increase changes in your AI pilot
Incorporate Real-World Business Use Case
Develop a Technology Infrastructure and Integrate AI as a tenant
However, while showing the demos and having conversations with customers, I can see a question coming up more often. How do we cope with errors? It makes sense that this question is coming up now. We are taking the automation conversation out of the realm of the datacenter and elevating it all the way to the end-user in the ITSM world. This means “Enterprise” requirements, which in turn means less room for failure. Also, if we expose it to the end-user we are no longer talking about dozens of engineers, now we have potentially thousands of possible consumers.
A sample architecture like shown in the videos is as follows:
The requirements are:
let the user know that the workflow didn’t complete so that they are not sitting there waiting. Depending on the error they might want to retry
inform the engineers that a specific workflow is failing and they need to look into it
This can and should be done both at the ServiceNow level and the Ansible level. In this post we are going to focus on the Ansible side of things. Most mature organizations use RedHat Ansible Automation Platform. I have also included the old name Ansible Tower because somehow is still stuck in people’s heads … it is certainly shorter and easier to pronounce. Of course this is also applicable to AWX, the community support edition
From an Ansible syntax perspective you can do error handling with things like “blocks and rescue” or other techniques. However, our guiding principle here is not so much to make sure the playbook continues despite errors and ends gracefully. What we want in this case is to make sure that both the engineer and/or user gets notified. For this purpose I find the “Notifications” functionality does the job nicely. You can find “Notifications” on the left bar under the Administration menu. If you click the “Add” button you get a menu like this
After providing a name you need to select the notification “Type”. Depending on your selection a number of relevant configuration options are shown. For example if email is selected it will ask for IP and port of the SMTP server and so on. Once you fill those details scroll to the very bottom and slide the “Customize messages” button. This will reveal the syntax of the notification messages. The tool supports sending notification on 7 different types of events including start, error, time out and even the outcome of an approval. Notice how the prepopulated messages use variables with the double curly bracket syntax.
In my example I have created a notification to send emails to a Zimbra SMTP server we have in the lab. As you saw in the previous image is called “Zimbra email”. For testing purposes I have created a job template that runs a playbook called “wrong.yml”. This is single task playbook that uses the “uri” module to access a webpage. I have fed the task with an IP address that doesn’t exist, so the playbook will fail
From the template we click in the “Notifications” tab. It will show you all the notifications you have configured. In my example “Zimbra email” is the only one. On the right side you will have the opportunity to enable any of the available notifications when the template starts, succeeds or fails. If you do the same thing for a “workflow template” it will show an additional slide button named “Approval”
All is left to do is to run the template. When I run it fails as expected and I get an email in my Inbox with the following message. Notice how the body of the email maps to the syntax we saw in the “Customize messages” menu
These messages could be sent to a group of engineers that look after the platform. I particularly like the fact that there is a “Webhook” type. This opens the possibility of sending a notification to a Teams channel which is a more popular choice than email these days. You can see in this previous post how to send notifications to a Teams channel. Additionally it would make sense to create an incident automatically in your ITSM tool. Some time ago we also published a tutorial to show you how to create incidents in ServiceNow programmatically.
In the world of software development, Murphy’s law holds an unassailable truth: Anything that can go wrong, will go wrong. As a proud member of this masochistic club, you might be looking for innovative ways to stall your Kubernetes enterprise rollout. Maybe you want to add a little chaos to your routine CI/CD workflow, or perhaps you’re just a thrill-seeker who loves the high stakes game of orchestration roulette. Either way, you’ve come to the right place. Sit back, relax, and let us guide you through the delightful maze of missteps and detours that will ensure your Kubernetes enterprise rollout is anything but a walk in the park.
Ah, Kubernetes! The open-source platform that’s become the equivalent of a Hollywood blockbuster in the tech world. It’s like the Iron Man of container orchestration, bringing together an array of superpowers including automation, scaling, and management of container deployment. Enterprises are lining up to get their tickets, excited by the promises of streamlined application deployment. But before you go head over heels for Kubernetes, remember, even Iron Man had his quirks. Navigating the CI/CD waterfall can sometimes feel more like a rollercoaster ride without a seatbelt. So before you charge headfirst into your enterprise rollout, take a moment to consider Murphy’s Law – anything that can go wrong, will go wrong. So buckle up, my friends, it’s going to be a wild ride.
Indeed, Kubernetes is a boon for developers, cloud-native architects, and business owners alike. Its versatility and flexibility can make you feel like a superhero orchestrating seamless deployments. But when it comes to deploying and scaling in Enterprise data centers, Kubernetes might just swap its Iron Man suit for a Godzilla costume, spawning fresh challenges born out of its cloud-native architecture. This transition can lead to excessive mental gymnastics as you grapple with these new beasts of burden. So, if you’re feeling like a deer caught in the headlights, staring down the Kubernetes-python poised to gobble up your Enterprise applications, fear not! This blog is your sanctuary, your guide, your ‘how-to-tame-your-dragon’ manual. Stay with us, as we venture into the labyrinth of Kubernetes deployment and come out the other side grinning. 🙂
Let’s dive into the 10 ways you might unintentionally stall your enterprise Kubernetes rollout, and inadvertently send your organization spiraling back to the ‘golden age’ of monolithic architecture:
1.Do Not Plan Your Deployment: Some may argue that the beauty of Kubernetes lies in its simplicity, and indeed, the internet is abundant with blogs and videos promoting the notion that the deployment process is a walk in the park. Following such advice without investing time in understanding your unique use case could be a significant pitfall. Kubernetes deployments require thoughtful planning, taking into account the intricacies of workload requirements, resource allocation, and network architecture. The idea of “Kubernetes is the easy button for everything” is a perilous assumption that can easily derail your enterprise rollout. Always remember, while Kubernetes does a spectacular job in many aspects, it’s not a one-size-fits-all solution for every enterprise problem.
2. Avoid Using Certified Kubernetes Distributions: Now this one’s a head-scratcher, isn’t it? Here’s the thing, though: Kubernetes is powerful, flexible, and can be customized to a dizzying degree. However, this does not mean you should do everything from scratch. Consider this – why would you build your car when you can buy a perfectly good one off the lot? Certified Kubernetes distributions, like Red Hat OpenShift or VMware Tanzu, come with the assurance of being properly configured, tested, and meeting industry standards. They’re like your ready-to-drive cars, offering robust features and world-class support. By choosing to bypass these options, you’re essentially signing up for unnecessary headaches that could easily stall your enterprise rollout. Remember, Kubernetes is a tool, not an ideology. There’s no virtue in unnecessary complexities.
3. Do NOT Implement Security Best Practices: This one’s a classic misstep in the tech world. Yes, Kubernetes is inherently secure, but that doesn’t mean it’s invincible. If you’re looking to stall your enterprise rollout, then by all means, ignore security best practices. However, if you’re keen on a smoothly functioning system, pay close attention to security measures like access control, network segmentation, and encryption. It’s akin to leaving your car unlocked in a crowded parking lot — sure, it might have an immobilizer and alarm system, but why invite trouble? Access control ensures only authorized personnel can interact with your Kubernetes clusters, network segmentation limits the blast radius of potential breaches, and encryption keeps your sensitive data safe in transit and at rest. Failing to implement these measures is like leaving the keys in your car with the engine running – a surefire way to invite mischief. Remember, in the world of Kubernetes deployments, security is not an afterthought, it’s a primary driver of successful CI/CD pipelines and enterprise rollouts.
4. Forget about Using CI/CD Pipelines: There’s a certain masochistic charm in choosing not to use CI/CD pipelines in your enterprise rollout. After all, who needs automation when you can manually deploy your applications, right? CI/CD pipelines, or Continuous Integration/Continuous Deployment pipelines, are like that studious classmate who always double-checks their work before submitting it – they automate the deployment process and ensure that all changes are thoroughly examined and validated before entering the production environment. If you’re a fan of chaos and unpredictability (and potentially stalling your Kubernetes enterprise rollout), then by all means, go ahead and give CI/CD pipelines a pass. However, if you value efficiency, reliability, and sanity, incorporating CI/CD pipelines into your operations could be a game-changer. They ensure a streamlined, error-free process that keeps your applications updated and secure, allowing your team to focus on what truly matters – building and improving your products. But hey, if you’re in the market for a bit of pandemonium, feel free to ignore this advice!
5.Visibility/Observability, what’s that?: There’s something rather intriguing about stumbling in the dark, isn’t there? For those of you who enjoy a good surprise, why not apply this approach to your Kubernetes deployment? Think about it, with no comprehensive monitoring solution in place, every day is like a thrilling game of hide-and-seek with your application’s performance, capacity, and availability. However, if you (like most sane people) prefer to know what’s happening under the hood, it’s time to incorporate a robust monitoring solution into your Kubernetes enterprise rollout. Think of it as a reliable co-pilot that keeps an eye on the road while you’re busy steering the ship. It helps you identify potential roadblocks or speed bumps, ensuring your journey toward a successful enterprise rollout is as smooth as possible. So go ahead, embrace the unknown, or better yet, ensure your unknowns are known with a comprehensive monitoring solution. But remember, no pressure; after all, it’s only your Kubernetes deployment we’re talking about here!
6.Don’t care about Config Management Tools: If you’re fond of unpredictability and enjoy the thrill of variance, throwing caution to the wind when it comes to config management could be your next adrenaline spike! Who needs tools like Ansible or Puppet that automate the configuration of your Kubernetes deployment and ensure consistent settings across your environment? Why make life easier and your enterprise rollout smoother when you can indulge in the chaotic symphony of inconsistency? Sure, these tools can simplify the management of your Kubernetes configuration, reduce errors, and ensure uniformity across your deployment, but where’s the fun in that? So sit back, relax, and let the inconsistencies rollick through your deployment, because who wouldn’t love a good configuration surprise?
7.Forget about Disaster Recovery: If you’re the type who loves to live on the edge, why not take a leap of faith with your Kubernetes rollout too? After all, implementing disaster recovery measures like backup and recovery procedures is like carrying an umbrella all the time just because it might rain. Sure, these measures could prevent your enterprise from figuratively getting drenched in the event of an unexpected outage or data loss, but what’s a little water, right? Having a disaster recovery plan could mean the difference between a minor hiccup and a full-fledged organizational crisis during a catastrophe, but let’s face it, who doesn’t love a little game of Russian Roulette with their Kubernetes deployment? So, go ahead and roll the dice. After all, disaster recovery is just for those who aren’t fans of suspense, right?
8.Train Your Staff (or Don’t): Now, here’s a real knee-slapper: education. Nothing quite like seeing your team scramble around like a bunch of cats on a hot tin roof because they don’t know their Pods from their Nodes. Who needs well-trained staff, conversant with Kubernetes best practices, when you can bask in the glorious pandemonium of mismanaged deployments instead? Sure, giving your employees the necessary skills to effectively manage and operate your Kubernetes deployment might lead to fewer issues, greater efficiency, and a more successful enterprise rollout. But let’s be real, why stifle the potential theatre of the absurd that could result from untrained staff wrestling a mammoth like Kubernetes? Life is a stage, after all, and in your Kubernetes drama, training is just too mainstream a script. So, sit back, grab some popcorn, and enjoy the show!
9.Live in the Past: Here’s a revolutionary idea – rolling with the times. You could, if you’re feeling particularly adventurous, actually stay up-to-date with the latest Kubernetes releases and security patches. That, of course, would imply that you’re interested in ensuring your deployment operates with the latest features and security updates. But hey, who doesn’t love a little nostalgia? Sure, you could prioritize keeping your enterprise rollout in line with the newest, slickest versions of Kubernetes, ensuring that your CI/CD pipelines are as cutting-edge as they come, but isn’t there a certain charm in running your enterprise on an antiquated version that’s as outdated as a floppy disk in an AI lab? After all, cybersecurity threats, outdated functionalities, and inefficiencies are just minor speed bumps on the road of enterprise rollouts. So, why not kick back, ignore those pesky update notifications, and let your Kubernetes deployment bask in the warm glow of obsolescence? Just remember – living in the past is only fun until the ghosts of security vulnerabilities and outdated features come knocking on your door.
10.Embrace Impermanence (non-persistence): In the grand scheme of things, isn’t Kubernetes is supposed to be ephemeral? Why should your data be any different? Go ahead, live dangerously. Don’t bother with planning for data persistence in your Kubernetes rollout. Imagine the thrill of living on the edge, knowing that you could lose all your data the moment a pod goes down or the system crashes. Sure, you could use the Kubernetes Persistent Volume (PV) and Persistent Volume Claim (PVC) architecture to ensure your data survives even when your pods don’t, but where’s the fun in that? Data persistence is so pedestrian. Remember, the goal here is to stall your Kubernetes enterprise rollout, not to make it robust, resilient, and reliable. So, go ahead, and throw caution (and your data) to the wind. It’s only important business information after all, right?
But hey, here’s a novel idea – what if you actually wanted to succeed in your cloud-native strategy? I know, I know, it sounds a bit radical given our prior conversation. But bear with me. For those of you who enjoy sailing smoothly on the seas of enterprise IT, without the thrill of hitting every possible iceberg, Dell has created a glorious solution. A tool, that’s as much a life preserver as it is a nautical chart, guiding you safely through the treacherous waters of Kubernetes enterprise rollouts. This magic wand is called the Container Storage Modules (CSM).
This isn’t just any tool – it’s your co-pilot on the journey to a seamless Kubernetes implementation. It’s like having a Swiss army knife for enterprise data management. The CSM ensures that your data persistence strategies are as solid as a rock, ensuring that no pod crash or system failure can sweep your data into the abyss. With CSM, you can laugh in the face of data loss, secure in the knowledge that your enterprise information is safe and sound. So, for the daredevils who actually like to succeed in their endeavors, the Dell Technologies CSM is the perfect tool to ensure your Kubernetes enterprise rollout is as smooth and trouble-free as a hot knife through butter.
I hope this post proves helpful, regardless of which direction you choose for your enterprise cloud journey. If you’re inclined to thrill and enjoy the odd game of Russian roulette with your data, you now have some innovative strategies to stall your Kubernetes rollout. However, if your preference is smooth as a jazz tune and your data as secure as Dell’s Project Fort Zero, then Dell’s Container Storage Modules (CSM) is the tool you need. The CSM is your beacon in the foggy world of Kubernetes enterprise rollout, ensuring that no data loss or system failure can derail your cloud-native strategy. It’s your data’s best friend, your enterprise’s lifeline, and your ticket to a successful Kubernetes implementation.
Enjoy the journey, and remember – with the right tools and strategies, Murphy’s Law doesn’t stand a chance!
In this blog post, we will install Dell EMC PowerStore collection on Ansible AWX and go through the next steps.
As we all know that Ansible has moved to Collections – a new ways of managing integrations and content management. Dell EMC has already started working towards this and have released several collections for multiple Dell EMC portfolio products, few of which are listed below.
Apart from this list you can find other Dell portfolio collections (like OpenManage) on this link
For the scope of this blog post we will focus on installing Dell EMC PowerStore Ansible collection on Ansible AWX. Technically, all the collections can be installed using similar steps.
As a Pre-Requisite, this blog post assumes that you have –
Access to operating system / machine having Ansible AWX installed
Access to PowerStore storage system (with credentials)
Additionally, if you’re getting started with Ansible AWX and/or integration with Dell EMC’s storage products then you can follow this blog series to get started from scratch.
As part of the installation collection installation steps we need to Ansible AWX machine and then connect to the awx_task docker container.
Login to the AWX machine. You can list the running AWX containers using below command
[root@awx ~]# docker container list
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6ced2eccbd7b ansible/awx_task:11.2.0 "tini -- /bin/sh -c …" 13 months ago Up 6 days 8052/tcp awx_task
42b14fbd15ad ansible/awx_web:11.2.0 "tini -- /bin/sh -c …" 13 months ago Up 6 days 0.0.0.0:80->8052/tcp awx_web
4c08c0e39128 memcached:alpine "docker-entrypoint.s…" 13 months ago Up 6 days 11211/tcp awx_memcached
42224676c21a redis "docker-entrypoint.s…" 13 months ago Up 6 days 6379/tcp awx_redis
37d0ca0c67bc postgres:10 "docker-entrypoint.s…" 13 months ago Up 6 days 5432/tcp awx_postgres
Then connect to the awx_task container using below command
# docker exec -it awx_task bash
Next, install the PowerStore Ansible Modules collection in awx_task container
# ansible-galaxy collection install dellemc.powerstore
Process install dependency map
Starting collection install process
Installing 'dellemc.powerstore:1.2.1' to '/home/awx/.ansible/collections/ansible_collections/dellemc/powerstore'
Then logout from the container.
bash-4.4# exit
Now you have successfully installed the Dell EMC PowerStore Ansible Modules collection. Next step post installing collection are
Create the PowerStore credentials on the Ansible AWX
All Dell EMC’s published collections comes with sample playbooks to test the functionality and also to get you started with integrations. When it comes to PowerStore you can see them under /home/awx/ansible-powerstore/dellemc_ansible/powerstore/samples directory
# cd /home/awx/ansible-powerstore/dellemc_ansible/powerstore/samples
# ls -l
-rw-r--r-- 1 root root 1892 Jun 4 2020 capacity_volumes.yml
-rw-r--r-- 1 root root 1042 Jun 4 2020 create_multiple_volumes_async.yml
-rw-r--r-- 1 root root 799 Jun 4 2020 create_multiple_volumes.yml
-rw-r--r-- 1 root root 790 Jun 4 2020 delete_multiple_volumes.yml
-rw-r--r-- 1 root root 1710 Jun 4 2020 find_empty_volume_groups.yml
-rw-r--r-- 1 root root 1141 Jun 4 2020 search_volumes.yml
You can re-use these sample playbooks to quickly get started with storage automation tasks. Sample playbooks in the collection has multiple variables like –
Once Dell Storage credential type is created then you can add PowerStore array details and credentials using AWX credential manager.
Ansible AWX – Dell EMC Storage Credential
After adding PowerStore credential you can use the same in the AWX automation job template creation. Additional variables (like volume names, size, host etc.) can be captured using extra_vars
Ansible AWX – Job Template Creation
Additionally you can create survey to capture the required variables and also workflow visualizer to create multi-step breakdown of the automation tasks including but not limited storage automation. Below is the example of breaking down the storage provisioning workflow in the logical steps (like approval, quota management, provisioning, etc.)
Ansible AWX – Workflow Visualizer
Hope this helps everyone.
Update: Please note that the latest version of AWX has moved to Kubernetes (instead of Docker). Please use the below steps to install the PowerStore modules.
[root@awx ~]# kubectl -n awx exec -it awx-844c574f84-bc4ww -c awx-ee -- /bin/bash bash-4.4$ ansible-galaxy collection install dellemc.powerstore -c Starting galaxy collection install process Process install dependency map Starting collection install process Downloading https://galaxy.ansible.com/download/dellemc-powerstore-1.6.0.tar.gz to /home/runner/.ansible/tmp/ansible-local-3648wbuk4c_/tmprzm8bse6/dellemc-powerstore-1.6.0-ltamh_71 Installing 'dellemc.powerstore:1.6.0' to '/home/runner/.ansible/collections/ansible_collections/dellemc/powerstore' dellemc.powerstore:1.6.0 was installed successfully bash-4.4$
There are many use cases where VxRAIL manager, VMware vCenter Console, or vSuite will not be enough for your goals in mind. So, for monitoring and management of your VxRAIL cluster, you can utilize the VxRAIL REST API for achieving your end goal in mind.
There are multiple ways to get your hands around the VxRAIL REST API
VxRAIL Swagger UI is always (default) runs on the VxRAIL cluster and can be accessed using a browser. Link for accessing the VxRAIL Swagger UI is – https://<VxRAIL_Manager_IP>/rest/vxm/api-doc.html
VxRAIL – Swagger UI
From the Swagger UI (top right – Select a definition drop-down) you can select the categories of API calls. By default, Swagger UI opens into the Day 1 Bring Up Configuration.
Additionally VxRAIL Swagger UI allows you to play with the APIs on the same page. For this you’ll need to Authorize the page using VxRAIL manager credentials. This is to make sure that user is restricted to the right level of authorization based on their user type.
For executing / trying the APIs on the VxRAIL cluster you can simply choose the definition from the drop-down. In this case I’ve selected Cluster definition.
VxRAIL – Select Definition
If you expand the selected API it will show you multiple sections (Cluster Information in this example)
VxRAIL – Cluster Information
Parameters – Some APIs needs parameters as input for the successful exectution. If applicable they will be listed here
Responses – This section shows you the possible response codes for selected API with example output snippet.
When you click on the Try it out button page gets into the run-mode. Once you enter required parameters (not required in this example) you can click on Execute. At this point request will be sent to VxRAIL manage and response (body and headers) will be shown on the same screen.
Way Forward
I hope this gave you the high level overview of VxRAIL APIs and how to access them. Though Swagger has built-in option to try the APIs, but that is the just a API explorer tool. Additionally you can also use the REST clients – like Postman – to interact with the API. Eventually you’ll integrate these APIs with your automation tools – those can be VMware vRA, Ansible, Terraform, or it can be your own developed tool. Technically speaking you can use any tool as far as it has option to interact with REST API.
In the last (5th part) of this blog series, we discussed how to install Ansible AWX / Tower in a docker container and Dell EMC Ansible modules inside the Ansible AWX / Tower container.
So first let’s get started with creating a Credential type for Dell EMC storage array. Login to your Ansible AWX / Tower console. In the navigation pane (on left) click on “Credential Types”. Then click on the green “+” icon on the right to add a new credential type.
Ansible AWX / Tower – Create New Credential 1
In the “New Credential Type” creation page enter below details and then click on Save
Once Credential type is created, click on the “Credentials” in AWX / Tower navigation pane. Then click green “+” button on right to create new Credential.
Ansible AWX / Tower – Create New Credential 3
In the “New Credentials” page enter below details.
Name – User Friendly Name to identify the storage array. In this example “Production PowerMax”
Description – Optional description
Organization – You can choose appropriate Organization as per your configuration. Note that Organization can help you to mask these credentials to few users. I have selected Default in my example
Credential Type – Choose “Dell EMC Storage”. This is the credential type we have created in earlier step. Credential type which we create earlier will be available on last few pages of the pop-up list. Alternatively you can search the same with “Dell EMC Storage”
Type Details
Array IP Address – Enter the management IP address of storage array
Array Username – Username (I suggest creating separate user for automation)
Array Password – Password for the entered username
Ansible AWX / Tower – Create New Credential 4
As per your environment you can create multiple credentials, each for one array.
Ansible AWX / Tower – Create New Credential 5
Once credentials are created you can now go ahead and create new Ansible AWX / Tower Templates using storage credentials we just created. In the playbook you can mention storage array credentials as variables (username and password). Using these variables you don’t have to mention array credentials as plain text in the playbooks.
Additionally, you can add other infrastructure / application credentials using the same process.
I hope this helps everyone. In next post I will take you through creating new Project and Template.
In this 5th part, we will discuss about Ansible Tower (using AWX) and how to install and configure the same.
Overview
In my posts till now you might noticed that I have only used command line option to run any Ansible commands. There’s a reason for that. By default, when you install Ansible it only installs Ansible Engine, which only has Ansible CLI option. This is where Ansible Tower comes in picture. Note that AWX is the open source project for Ansible Tower.
While Ansible Tower has many features, below are few features which are my personal favorites. Since data storage management operations can be data destructive, below features are the reasons I am highly recommending using Tower / AWX for automating storage tasks.
Web Interface – To manage Ansible using Web interface
REST API Support – To manage and integrate Ansible Tower in other platforms. For example – integrating Ansible Tower with Jenkins
Task Engine – To create scheduled job and centralized operations.
Role Based Access Control – To control Enterprise level access across different team member and limit their visibility to information. This will make sure only designated users are having access to critical data/tasks.
Installing Ansible Tower (using AWX)
Make sure that you’ve supported operating systems installed and running. In my case I am using CentOS V7 virtual machine
Prerequisites –
Make sure below packages are installed on your machine
This will create awx directory. cd into the awx/installer directory.
[root@dw-test-1 installer]# cd awx/installer
This folder has inventory file which has all the AWX parameters. Most important details in this file are passwords which are needed for logging into the AWX post installation. Note that AWX supports installation on Kubernetes and Openshift as well. In this example we will be using docker-compose.
Most important parameters in inventory file are as mentioned below. In my case I created the vars.yml file with below inputs and used the same while running the installation.
Note – I faced couple of errors which running this playbook. I suggest taking a look at this link if you face the same.
Once playbook execution is completed you can run below command to validate the installation.
[root@dw-test-1 installer]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
23b236356057 ansible/awx_task:10.0.0 "/tini -- /bin/sh ..." 6 minutes ago Up 2 minutes 8052/tcp awx_task
a23edc05283e ansible/awx_web:10.0.0 "/tini -- /bin/sh ..." 6 minutes ago Up 2 minutes 0.0.0.0:80->8052/tcp awx_web
385de9d395da postgres:10 "docker-entrypoint..." 6 minutes ago Up 2 minutes 5432/tcp awx_postgres
125b9e551823 redis "docker-entrypoint..." 2 hours ago Up 2 minutes 6379/tcp awx_redis
2a8ad285e2d5 memcached:alpine "docker-entrypoint..." 2 hours ago Up 2 minutes 11211/tcp awx_memcached
At this point AWX is installed. It takes some time for container to start and configure the AWX. Run the below command and wait till the time you see similar output
Now we will need to install prerequisites for DellEMC Ansible module – PyU4V package. Follow below steps to install DellEMC Ansible module dependencies.
Once completed you can check installed version using
bash-4.4# pip3 list | grep PyU4V
PyU4V (9.1.1.0)
At this point you have AWX up and running and can be reached on http://localhost:80.
Tower is now running on the host at port 80. The rest of the setup is handled by the web interface . If you did this on the system you are using you can use http://localhost.
If everything went well then you can see login prompt similar to the below screenshot. Login credentials for AWX are as per inventory file.
This concludes Ansible Tower (AWX) installation process. In next posts we will discuss on configuring Ansible Tower / AWX.
In the first part of this blog series, we discussed what is REST API and different usage options
Second part was about managing DellEMC PowerMax storage arrays using REST API
In this post, we will discuss how you can use manage DellEMC Unity storage using REST API. We will be using the Postman tool during the entire blog series. So let’s get started with automating the DellEMC Unity storage system.
The DellEMC Unity REST API Background
DellEMC Unity is of the most user-friendly storage systems. The most common management tools for Unity systems are
Unisphere UI (Embedded) – An HTML5 graphical user interface used to manage Dell EMC Unity systems
Unisphere Command Line Interface (UEMCLI) – UEMCLI allows a user to perform tasks on the storage system by typing commands instead of using the graphical user interface
The Dell EMC Unity includes complete REST API support, providing a developer-friendly way to manage Dell EMC Unity systems and automate various tasks.
Dell EMC Unity’s REST API fully supports all the management tasks that a user can perform in the Unisphere GUI. Dell EMC Unity’s REST API response formats all communication in JSON notation. Users can send REST API requests using their favorite REST API tools to manage Dell EMC Unity systems in their environment. This provides flexibility in management and opens possibilities for more complex operations.
DellEMC Unity Management Options
Assessing DellEMC Unity’s REST API
Once a Unity system is up and running, users can navigate to the following web addresses to get access to the REST API documentation:
REST API Programmer’s Guide –https://{{unisphere_management_address}}/apidocs/programmers-guide/index.html
REST API Reference Guide – https://{{unisphere_management_address}}/apidocs/index.html
DellEMC Unity’s REST API is available via Unisphere running on the array via the following Base URL.
https://{{unisphere_management_address}}/api
{{unisphere_management_address}} – Replace with IP Unisphere IP address or hostname
Supported DellEMC Unity REST APIOperations
DellEMC Unity’s REST API supports the following types of REST calls.
GET – Get information on objects. For example – Get Unity storage system’s details
POST – Create an Object. For example – Create new LUN/s
PUT – Making changes to an objects. For example – Change size of the existing LUN
DELETE – Remove an object. For example – Delete existing LUN/s
Usually the REST client (like Postman) can be used to help figure out what REST calls you want to run.
Building your REST API calls
Now let’s get started with creating REST API calls. In this example we will create sample REST API call to list all the available storage pools.
Before we get started make sure you’ve Postman installed and Unisphere is reachable.
Open Postman and click on New. Under new drop-down, select Request
DellEMC Unity REST API – Postman tool GUI – 1
In New Request pop-up enter Request name, Description (optional) and Name of the Collection. Then click on Save.
DellEMC Unity REST API – Postman tool GUI – 2
Click on the request type drop-down and select GET.
Please note that we are selecting GET because is this example we are creating sample REST API call to list all the available storage pools.
This option will be different based on type of REST API operation
DellEMC Unity REST API – Postman tool GUI – 3
Enter below Request URL
1.1.1.1 – Replace with Unisphere IP address/hostname
https://1.1.1.1/api/types/pool/instances
DellEMC Unity REST API – Postman tool GUI – 4
Click on the Authorization. Enter Unisphere Username and Password.
DellEMC Unity REST API – Postman tool GUI – 5
Note that Unity REST API GET request needs below 3 headers. Click on Headers and enter below header details as shown in the screenshot. Then click Send
Accept – application/json
Content-type – application/json
X-EMC-REST-CLIENT – true
DellEMC Unity REST API – Postman tool GUI – 5
In the Postman Response section you’ll see REST API response. In this case you’ll see list of all the storage pools in Unity array.
DellEMC Unity REST API – Postman tool GUI – 6
Additionally please note that POST/PUT/DELETE requests need one additional Header – EMC-CSRF-TOKEN. This token is generated using GET request.
So, let’s create one POST request for creating new LUN.
Follow above-listed GET request steps. Click on Headers under GET Response. Copy the EMC-CSRF-TOKEN from the Headers
DellEMC Unity REST API – Postman tool GUI – 7
Now click on New and Under new drop-down, select Request (screenshot in GET request steps)
In New Request pop-up enter Request name, Description (optional) and Name of the Collection. Then click on Save. (screenshot in GET request steps)
Click on the request type drop-down and select POST.
Please note that we are selecting POST because is this second example we are creating REST API call to create new LUN.
Click on the Authorization. Enter Unisphere Username and Password.
Under Params enter below details.
Name – Name of the LUN
Pool – Storage Pool in which LUN will be created
Size – LUN size
DellEMC Unity REST API – Postman tool GUI – 7
Click on Headers and enter below header details as shown in the screenshot. Then click Send
Accept – application/json
Content-type – application/json
X-EMC-REST-CLIENT – true
EMC-CSRF-TOKEN – Copied from GET response
DellEMC Unity REST API – Postman tool GUI – 8
Dell EMC and REST API – Way Forward
I hope this clarifies many basics for getting started with REST API and DellEMC Unity storage. You might also have understood that creating creating valid URLs is very important aspect of using REST API. Having this in mind we have created ready Postman collection for DellEMC Unity storage. Here’s the GitHub link to the repository. Feel free to download and share.
Below are the additional resources available for taking REST API usage to next level.
This blog post is 2nd part of REST API with DellEMC Storage blog series. In the first part of this blog series, we discussed what is REST API and different usage options. I highly encourage you to go through the first part before you get started with this post.
In this post, we will discuss how you can use manage DellEMC PowerMax storage using REST API. We will be using the Postman tool during the entire blog series. So let’s get started with automating the DellEMC PowerMax storage system.
The PowerMax REST API Background
There are many different ways to manage the PowerMax storage system. You can refer to this link for more details around each. Traditionally many customers using the VMAX family systems are using the Solutions Enabler tool. This is a comprehensive tool that allows storage administrators to automate many different storage tasks using scripting (Bash, Perl, Shell scripts, etc.).
PowerMax Unisphere GUI is HTML5 based management interface, it’s beautiful and functional and provides a web-based interactive experience for users. Unisphere has a lot of automation baked in, and it’s intuitive wizards eliminate complexity and can often provide the right amount of automation for organizations where there isn’t a lot of change. With Unisphere version 8 everything you can do in the GUI is supported using REST API.
DellEMC PowerMax Management Options
Assessing DellEMC PowerMax REST API
DellEMC PowerMax’s REST API is available via Unisphere (installed or embedded) running on the array via the following Base URL.
Click on the Authorization. Enter Unisphere Username and Password. Then click Send
DellEMC PowerMax REST API – Postman tool GUI – 5
In the Postman Response section you’ll see REST API response. In this case you’ll see list of all the SRPs in PowerMax array.
DellEMC PowerMax REST API – Postman tool GUI – 6
Dell EMC and REST API – Way Forward
I hope this clarifies many basics for getting started with REST API and DellEMC storage. You might also have understood that creating creating valid URLs is very important aspect of using REST API. Having this in mind we have created ready Postman collection for DellEMC PowerMax storage. Here’s the GitHub link to the repository. Feel free to download and share.
Below are the additional resources available for taking REST API usage to next level.
REST API client for Unisphere – This is simple GUI tool which allows you to to construct REST API calls. Best part of this tool is having a tree view of all resources on the Unisphere to which the users can navigate through to select the desired REST call.
