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
- Test – All QA engineers within GSS
- Stage – All production teams
- Production – All Production teams
- Gregarious – All Dev, QA, and Production teams
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
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.
There are lots of reasons to want to export and import blueprints from one vRA instance to another. My current motives are to move blueprints from my vRA 7.2 environment to my newly deployed vRA 7.3 environment. In vRA 7.3 their is a great new free feature available, the Code Stream Management Pack for IT Devops that is free. However if you are running a pre vRA 7.3 environment you may want to get that content from that environment backed up so you can use it in another instance. Cloud Client is a great option.
THIS EXTENSION IS NO LONGER MAINTAINED
I want to thank all of you that have downloaded and used this module. We never expected it to be as widely used as it has been. We decided to stop maintaining this because it was originally built as an example of how one could achieve this capability. Much to our surprise it has been deployed into countless production environments. As a result we have received countless requests for support which we cannot provide.
Their is good news however. Their is a commercially available supported product that is capable to doing much more than this module is capable of. For more information See article on SovLabs Hostname Module
One of the most frequent asks when using vRA is, “How do I deploy machines using my company’s hostnaming standards automatically using vRA?” Since the out-of-the box hostnaming only provides a way to do prefix-suffix, the answer to this question usually is that it will require customization.
This solution is intended to provide a way to implement this functionality by using a small, highly versatile custom extension which can handle 95% of use cases without writing custom code.
The rest of this article contains instructions on installing and configuring the vRA Custom Hostnaming Extension. This extension allows administrators to model very specific custom hostnaming schemes for their vRA virtual machines, Deployments, and vCloud Director vApps using vRA custom properties, with dynamic creation of stock machine prefixes and index tracking for each unique hostname combination.
This extension is proof-of-concept or demo grade. While it runs well and consistently, it has not been put through a formal quality assurance process, so please use with caution.