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.
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
Continue reading “Road to Automation with VMware vRA – vRA Design Part 1”
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
Continue reading “Road to Automation with VMware vRA – GSS Company Profile”
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.
Continue reading “The road to automation with VMware vRA”
Many of you may have heard about Amazon’s latest product named Lightsail. This service is designed to competed with shared hosting providers. A few years back I moved my websites from shared hosting, to self hosing, and ultimately to a dedicated server with 1&1 hostsing. For $85 a month it wasn’t a bad deal. Although the server seemed very sluggish at times and the network wasn’t very fast it was still better than shared hosting.
Over the course of the last two weeks I moved all my web assets to Amazon Lightsail and I couldn’t be happier. The Amazon network is lightening fast and the $5 per month instance is out performing the dedicated server I had from 1&1 hosting. Lightsail offers many plans starting at $5 a month all the way to $80 a month.
Continue reading “Hello Amazon Lightsail, Good by 1&1 dedicated server”
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.
Continue reading “vRA 7.3 – Configuring the SovLabs Plugin”
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.
Continue reading “vRA 7.3 – Installing and configuring vRA plugin for ITSM – ServiceNow – Part 2”
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.
Continue reading “vRA 7.3–Installing and configuring vRA plugin for ITSM–ServiceNow–Part 1”
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.
You can download Cloud CLient 4.4.0 here. Continue reading “Using the vRA Cloud Client to export and import blueprints”