My six-year-old asked me to tell him a bedtime story and it went something like this.
Jimmy and Tommy are both vRA admins. Jimmy works for a large financial company and Tommy works for a large company that makes really cool stuff. Both Jimmy and Tommy made great decisions to use vRA to automate their private clouds. Jimmy decided his organization was going to build all their own integrations. Tommy decided to use the SovLabs plugin for all his organizations needs.
Four weeks after Tommy’s vRA deployment his company was using vRA to deploy 75% of their virtual deployments. Meanwhile after four weeks Jimmy is just getting started designing the first of many needed integrations. Fast forward a year and Tommy’s organization is now deploying 100% of their workloads. They have reduced management overhead by 45%, and are able to deploy new server requests in under an hour.
A year later Jimmy’s company is still working out bugs with their custom code. Their administrative overhead is up 55% and it still takes over two-weeks for new server requests to be fulfilled. Jimmy is working 80+ hours a week and perpetually stressed. Tommy on the other hand is working 30 hours a week, but don’t tell his boss. He is enjoying his job and has next to no stress.
I then ask my six-year-old who he would rather be Jimmy or Tommy? He responded neither daddy I would rather be you. I asked him why he said he wanted to be me. He responded, because daddy you helped Tommy only have to work 30 hours a week.
If you were at VMworld and caught the Day 1 General Session you may have heard Pat Gelsinger say “The rule of the cloud – Ruthlessly Automate Everything”. This should be a wakeup call for anyone who has not begun or has done very little with automation.
GSS has decided on a number of design considerations for their vRA implementation. GSS is currently using a consumption based model for their resource allocation. They don’t pre-reserve any amount of resources for specific groups within the organization. GSS feels their current consumption model allows them to more efficiently manage their resources. It also prevents them from having pockets of idol resources that may never get used. Based on this utilization model GSS will be implementing the following elements within vRA.
GSS considered having a business group for each environment (Dev, Test, Stage, and Production). To evaluate how they would like to proceed they asked to have 5 initial tenants created. One for each of their environments and one to evaluate a collapsed model of all environments in one group.
Development – All Developers across all groups within GSS
In my previous article The Road to automation with VMware vRA I discussed I would be published a company profile for my fictitious company GSS. In this article we will be digging into GSS to take a look at where it is today, its challenges, processes, systems, and automation use cases.
Company: (GSS) Gregarious Simulation Systems Profile: Successful Video Game Manufacturer Employees: 1200+ IT Staff: 80+ vSphere Sockets: 200+ Managed VMs: 3000+ Server Build Team: 12 Environments: Development, Test, Stage, Production
I think we need to take a few steps back and focus on vRA architecture and design. I’ve had many questions, requests, and discussions with some of my readers on this topic. Implementing vRA can lead to many rewarding outcomes, but as some have discovered it can also lead to aggravating outcomes if not designed properly upfront.
At first it can seem very straight forward. Create some endpoints, groups, reservations, and blueprints. Sprinkle in some integrations for custom hostname, IPAM, DNS and AD and you are on your way to fully automating your workload deployments, right? Not exactly. You can certainly do this and at first it will seem amazing, but as you mature and start to scale out your new catalog of services the lack of up front design and planning will quickly start to reveal itself.
Many of you may have already heard after 6 years at VMware I decided to spread my wings and go back to the world from which I came. I joined VMware when they acquired DynamicOps a little over 6 years ago, and after 6 great years at VMware I decided to move on to something new, but not so new.
If it doesn’t show from my blog I am very passionate about automation. I’m even more passionate about helping organizations overcome all the challenges they face during their journey towards automation. Having been working with vRA for over 10 years I’ve learned a lot. I’ve learned the countless ways different organizations go about achieving the same end result. I’ve learned the challenges with automation in the datacenter. I’ve learned I could probably write endlessly about what I have learned
Many of you have utilized the Custom Hostname module that has been made available by Tom Bonanno here on Dailyhypervisor. Those that use have probably noticed that it is no longer maintained. This is because there are supportable modules available like the one I’m writing about now by SovLabs. The Sovlabs module offers more flexibility and is a supported product making it a best of breed solution for this task. Whats even better is their is a common framework that exists within the SovLabs platform that greatly extends the capabilities of each module. More of the framework to come. For now let’s go ahead and configure the custom hostname module.
Within the SovLabs custom naming module hostnames are broken in to two parts. A Naming Sequence and a Naming Standard.
Naming sequences are exactly exactly what they sound like. They basically define how are we going to sequence the names that are created. Sounds basic right? Well SovLabs has taken sequencing to a whole new level. Most of you are probably familiar with using a standard decimal based sequence that might look like host001, host002, and so on. SovLabs has added the ability to use HexaDecimal, Octal, and Pattern based sequences for your naming needs. Pattern based sequences are insanely powerful. Pattern naming sequences can contain Decimal, HexaDecimal, Octal, Binary, and Alpha. Below are an examples of what you can achieve with Pattern Based naming sequences: Continue reading “vRA 7.3 – Configuring SovLabs Custom Naming Module”
In my previous article about the SovLabs plugin I covered some pre-requisites and sent you over to the SovLabs documentation to finish the installation. Once you have installed the vRO plugin using the vRO Control Center you will go to your vRO Client and see a new folder that has all the Sovlabs vRO modules.
If you haven’t read Part 1 of this article you will want to go back and read it before you proceed. In part 2 we will build on the installation that we performed in part 1. Let’s just dig right in and get started.
How this integration works
Configuring the integration to use native vRA authentication requires the user to login to ServiceNow and vRA both. When the user logs into ServiceNow they are redirected to the vRA Login page and was logged in they are then redirected back to ServiceNow. This allows requests the user makes to be passed to vRA as that user. The main difference between this and the SAML (ADFS) integration is the user only need to login to vRA the very first time they use it and never again as the user is auto-magically logged in to vRA in the background using the SAML token. This is a great option for testing the integration without having to touch your Identity Management configuration.
It seems like everyone these days wants to use ServiceNow as their catalog for vRA. It use to be that everyone just wanted to create or update CI records. Before I get into the weeds on how to get vRA and ServiceNow talking together I wanted to take a few minutes to discuss the integration, the pros, the cons, and it’s limitation.