January – 2016 – Chan's Blog

Time of the Hybrid Cloud?

January 22, 2016Chan Leave a comment

A little blog on something slightly less technical but equally important today. Not a marketing piece but just my thoughts on something I came across that I thought would be worth writing something about.

Background

I came across an interesting article this morning based on a Gartner research on last years global IT spend where it was revealed that global IT spent was down by about $216 Billion during 2015. However during the same year data center IT spend was up by 1.8% and is forecasted to go up to 3% within 2016. Everyone from IT vendors to resellers to every IT sales person you come across these days, on Internet blogs / news / LinkedIn or out in the field seem to believe (and make you believe) that the customer owned data center is dead for good and everything is or should be moving to the cloud (Public cloud that is). If all that is true, it made me wonder how the data center spend went up when in fact that should have gone down? One might think this data center spend itself was possibly fuelled by the growth in the public cloud infrastructure expansion due to increased demand on Public cloud platforms like Microsoft Azure and Amazon AWS. Make total sense right? Perhaps in the outset. But upon closer inspection, there’s a slightly complicated story, the way I see it.

Part 1 – Contribution from the Public cloud

Public cloud platforms like AWS are growing fast and aggressively and there’s no denying that. They address a need in the industry to be able to use a global, shared platform that can scale infinitely on demand and due to the sheer economy of scale these shared platform providers have, customers benefit from cheaper IT costs, especially compared to having to spec up a data center for your occasional peak requirements (that may only be hit once a month) and having to pay for it all upfront regardless of the actual utilisation can be an expensive exercise for many. With a Public cloud platform, the up front cost is cheaper and you pay per usage which makes it an attractive platform for many. Sure there are more benefits of using a public cloud platform than just the cost factor, but essentially “the cost” has always been the most key underpinning driver for enterprises to adopt public cloud since its inception. Most new start ups (Netflix’s of the world) and even some established enterprise customers who don’t have the baggage of legacy apps, (By legacy apps, I’m referring to client-server type of applications typically run on Microsoft Windows platform), are by default electing to predominantly use a cheaper Public cloud platform like AWS to locate their business application stack without owning their own data center kit. This will continue to be the case for those customers and therefore will continue to drive the expansion of Public cloud platforms like AWS. And I’m sure a significant portion of the growth of the data center spend in 2015 would have come from the increase of these pure Public cloud usage causing the cloud providers to buy yet more data center hardware.

Part 2 – Contribution from the “Other” cloud

The point is however, not all the data center spend increment within 2015 would have come from just Public cloud platforms like AWS or Azure buying extra kit for their data centres. When you look at numbers from traditional hardware vendors, HP’s numbers appear to be up by around 25% for the year and others such as Dell, Cisco, EMC also appear to have grown their sales in 2015 which appear to have contributed towards this increased data center spend. It is no secret that none of these public cloud platforms use traditional data center hardware vendors kit in their Public cloud data centres. They often use commodity hardware or even build servers & networking equipment themselves (lot cheaper). So where would the increased sales for these vendors have come from? My guess is that they likely have come from most enterprise customers deploying Hybrid Cloud solutions that involves customers own hardware being deployed in their own / co-location / off prem / hosted data centres (customer still own their kit) along with using an enterprise friendly Public cloud platform (mostly Microsoft Azure or VMware vCloud Air) acting as just another segment of their overall data center strategy. If you consider most of the established enterprise customers, the chances are that they have lots of legacy applications that are not always cloud friendly. By legacy applications, I mean typical WINTEL applications that typically conform to the client server architecture. These apps would have started life in the enterprise since Windows NT / 2000 days and have grown with their business over time. These applications are typically not cloud friendly (industry buzz word is “Cloud Native”) and often moving these as is on to a Public cloud platform like AWS or Azure is commercially or technically not feasible for most enterprises. (I’ve been working in the industry since Windows 2000 days and I can assure you that these type of apps still make up a significant number out there). And this “baggage” often prevents many enterprises from purely using just Public cloud (sure there are other things like compliance that gets in the way too of Public cloud but over time, Public cloud system will naturally begin to cater properly for compliance requirements…etc. so these obstacles would be short lived). While a small number of those enterprises will have the engineering budget and the resources necessary to re-design and re-develop these legacy app stacks to be a more modern & cloud native stack, most of them will not have that luxury. Often such redevelopment work are expensive and most importantly, time consuming and disruptive.

So, for most of these customers, the immediate tactical solution is to resort to a Hybrid cloud solution where the legacy “baggage” app stack live on a legacy data center and all newly developed apps will likely be developed as cloud native (designed and developed from ground up) on an enterprise friendly Public cloud system such as Microsoft Azure or VMware vCloud Air. An overarching IT operations management platform (industry buzz word “Cloud Management Platform”) will then manage both the customer owned (private) portion and the Public portion of the Hybrid cloud solution seamlessly (with caveats of course). I think this is what has been happening in 2015 and this may also explain the growth of legacy hardware vendor sales at the same time. Since I work for a fairly large global reseller, I’ve witnessed this increased hardware sales first hand from the traditional data center hardware vendor partners (HP, Cisco…etc.) through our business too which adds up. I believe this adoption of Hybrid cloud solutions will continue through out 2016 and possibly beyond for a good while, at least until such time that all legacy apps are eventually all phased out but that could be a long while away.

Summary

So there you have it. In my view, Public cloud will continue to grow but if you think that it will replace customer owned data center kit anytime soon, that’s probably unlikely. At least 2015 has proved that both Public cloud and Private cloud platforms (through the guise of Hybrid cloud) have grown together and my thoughts are that this will continue to be the case for a good while. Who knows, I may well be proven wrong and within 6 months, AWZ & Azure & Google Public clouds will devour all private cloud platforms and everybody would be happy on just Public cloud :-). But the common sense suggest otherwise. I can see lot more Hybrid cloud deployments in the immediate future (at least few years) using mainly Microsoft Azure and VMware vCloud Air platforms. Based on technologies available today, these 2 in my view stand out as probably the best suited Public cloud platforms with a strong Hybrid cloud compatibility given their already popular presence in the enterprise data center (for hosting legacy apps efficiently) as well as each having a good overarching cloud management platform that customers can use to manage their Hybrid Cloud environments with.

Thoughts and comments are welcome….!!

3. VMware vSphere 6.x – vCenter Server Appliance Deployment

January 15, 2016Chan 2 Comments

<- Index page – VMware vSphere 6.x Deployment Process

In the previous article, we deployed an external PSC appliance and replaced it’s default root CA cert with a cert from an existing enterprise CA, such that every time VMCA assigns a cert to either vCenter or in turn, ESXi servers, it will have the full enterprise CA certificate chain rather than just vSphere’s cert chain.

Note the below design notes related to the vCenter server deployment illustrated here

Similar to PSC, vCenter server will also be deployed using the VMware appliance (VCSA)
A single vCenter instance is often sufficient with most requirements given that VMware HA will protect it from hardware failures.

Lets now quickly look at a typical deployment of the vCenter server (appliance)

Note: Deployment of vCenter server using the VCSA is somewhat identical to the earlier illustrated deployement of PSC, in that its the same appliance being deployed, and instead of selecting PSC mode, we are selecting the vCenter Server mode this time.

Download the VMware vCSA appliance ISO from VMware and mount the ISO image on you workstation / jump host and launch the vcsa-setup.html file found on the root of the ISO drive.
Now click install.
Accept EULA and click next
You can deploy the appliance directly to an ESXi host or deploy through a vCenter. Provide your target server details here with credentials.
Type the appliance’s VM name & root password for the appliance’s Linux OS. Make a note as you’d need this later.
Select the appropriate deployment type. We are deploying an external vCenter server here for an external PSC.
We are now connecting the vCenter VCSA to the previously deployed PSC instance and the SSO details we configured.
Select the appropriate vCenter server VCSA appliance size, based on the intended workload of the vCenter.
Select the destination datastore to deploy the vCSA appliance on to
Now select the vCenter database type. I’m using PostgreSQL here (built-in) as this will now likely be the preferred choice for many enterprise customers as its decent enough to scale up to 10,000 VMs and you don’t have to pay for an SQL server license. Those handful of customers who have an existing Oracle DB server can use Oracle here too.
Now provide the IP & DNS details. Ensue you provide a valid NTP server and check that the time syncs properly from this source.
1. Note here that you need to manualy create the DNS server entry (if you hadn’t done this already) for the VCSA appliance and ensure it resolves the name correctly to the IP used here, before proceeding any further..!
Verify the settings and proceed to start deploying the appliance.
Deployment progress and completion

SSL Certificate verifications & Updates (Important)!!

We’ve already updated the PSC’s default root certificate with a Enterprise CA signed root certificate in a previous step (Section “Optional – Replace the VMCA root certificate as explained here). So when you add the vCenter appliance to the PSC (which we’ve already performed earlier in this article, all the relevant certificates are supposed to be automatically created and allocated by the VMCA on to the vCenter. However I’ve seen issues with this so just to be on the safe side, I recommend we follow the rest of the steps involved in the KB article 2111219, under section “Replacing VMCA of the Platform Services Controller with a Subordinate Certificate Authority Certificate” as follows

Replacing the vSphere 6.0 Machine SSL certificate with a VMware Certificate Authority issued certificate (2112279) – On the vCenter Server Appliance
Replacing the vSphere 6.0 Solution User certificates with VMware Certificate Authority issued certificates (2112281) – On the vCenter Server Appliance
If you use Auto Deploy, may want to consider applying the fix mentioned in the KB article 2123631. Otherwise, go the next task
Follow the VMware KB 2109074 and
1. Follow the listed “Task 0 – Validating the sslTrust Anchors for the PSC and vCenter” – This need to be tested on both the PSC appliance as well as the vCenter appliance as instructed.
2. If the certificated don’t match, also follow the rest of the tasks as indicated
3. Validating this here can save you lots of headache down the line…!!

That’s pretty much it for the deployment of the VCSA appliance in vCenter mode rather than the PSC mode.

Adding ESXi Servers to the vCenter server

Important note: If you decide to add the ESXi nodes to the vCenter straight away, please we aware of the fact that if the Enterprise subordinate certificate that replaced the VMCA root certificate has been valid for less than 24 hours, you CANNOT add any ESXi hosts as this is by design. See the KB2123386 for more information. In most enterprise deployments where the Enterprise subordinate certificate would have been likely issued few days in advance of the actual PSC & VCSA deployment, this would be a non issue but if you are one of those where you’ve obtained the cert from your Enterprise CA less than 24 hours ago, you need to wait before you can add ESXi servers to the vCenter server.

That’s it. Now its the time to configure your vCenter server for AD authentication via the PSC and all other post install config tasks as required.

Cheers

Chan

2. VMware vSphere 6.x – Platform Service Controller Deployment

January 2, 2016Chan Leave a comment

<- Index page – VMware vSphere 6.x Deployment Process

Following on from the previous article, lets now look at how we go about carrying out a typical enterprise deployment of vSphere 6 and first up is the deployment of PSC. (note that normally, the 1st thing to do is to deploy ESXi but since the ESXi deployment with 6.x is pretty much the same as its 2 previous iterations, I’m going to skip it, assuming that its somewhat mainstream knowledge now)

Given below are the main deployment steps involved in deploying the Platform Service Controller. Note the below notes regarding the PSC design being deployed here.

Single, external PSC appliance will be deployed with 2 vCenter server appliances associated with it (topology 2 of the recommended deployment topologies listed here by VMware) as this is likely going to be the most popular deployment model for most people.
Lot of people may wonder why no resiliency for PSC here. While PSC can be deployed behind a load balancer for HA, its a bit of an overkill, especially with vSphere 6.0 Update 1 which now supports pointing an existing vCenter Server to another PSC node if its in the same SSO domain. For more information, see this priceless article by William Lam @ VMware which also shows how you can automate this manual repointing if need be.

Lets take a look at the PSC appliance deployment steps

Download the VMware vCSA appliance ISO from VMware and mount the ISO image on you workstation / jump host and launch the vcsa-setup.html file found on the root of the ISO drive. Since this has not specifically been mentioned, it should be noted that the PSC appliance deployment is part of the same vCenter Server Appliance (vCSA) but during the deployment, you specify you only want PSC services deployed)
Now click install.
Accept EULA and next
You can deploy the appliance directly to an ESXi host or deploy through a vCenter. Provide your target server details here with credentials.
Type the appliance’s VM name & root password for the appliance’s Linux OS. Make a note as you’d need this later.
Select the appropriate deployment type. We are using the external PSC here.
We are creating a new SSO domain here so provide the required details here.
Appliance size is not modifiable here as we’ve selected the PSC mode earlier (where the size is same for all).
Select the destination datastore to deploy the PSC appliance on to.
Now provide the IP & DNS details. Ensue you provide a valid NTP server and check that the time syncs properly from this source.
1. Ensure the DNS entries are manually added to the AD for PSC before proceeding with this step as the PSC deployment may return errors if the FQDN cannot be resolved correctly.
Review the deployment settings and click finish to proceed with the appliance deployment.
Deployment progress and completion
Once complete, ensure you can connect to the PSC web page using the URL http://<PSC FQDN>/websso
You can also connect to the appliance configuration page using the port 5480 as is the case with most VMware products that ships as appliances. The URL is http://<FQDN of the PSC appliance>:5480 and the credentials are root and the password specified during deployment earlier.

Optional – Replace the VMCA root certificate

This is only required if you have an enterprise CA hierarchy already in place within your organisation, such as a Microsoft CA. However, if you are a WINTEL house, I would highly recommend that you deploy a Microsoft Enterprise CA using Windows Server as it is quite useful for many use cases, including automation tasks involved with XaaS platforms. (i.e. Running vRO workflows to create an Active Directory user cannot happen without an LDAPS connection for which the Domain Controllers need to have a valid certificate….etc.). So, if you have an Enterprise CA, you should make the PSC a subordinate certificate authority by replacing its default root cert with a valid cert from the Enterprise CA.

Note that this should ideally happen before deploying the vCenter server appliance, in order to keep the process simple.

To do this, follow the steps listed out in this VMware KB 2111219, under the section “Replacing VMCA of the Platform Services Controller with a Subordinate Certificate Authority Certificate” (To be specific, if your deployment is greenfield and you are following my order of component deployment, which means vCenter server has not yet been deployed, ONLY follow the first 3 steps listed under the “Replacing VMCA of the Platform Service Controller with a subordinate Certificate Authority Certificate” section. I’ve listed them below FYI.
DO NOT follow the rest of the steps yet (unless you already have a vCenter server attached to the PSC) as they are NOT YET required.

PSC configuration

There is not much to configure on PSC at this stage as the SSO configuration and integration with AD will be done at a later stage, once the vCenter Server Appliances have also been deployed with the vCenter Server service.

There you have it. Your PSC appliance is now deployed and the default VMCA root certificate is also replaced with a subordinate certificate from your existing enterprise CA, so that your VMware vSphere components that receive a cert from VMCA will have the full organisational cert chain, all the way from the enterprise root CA cert, to the VMCA issued cert.

Next, we’ll look at the VCSA appliance deployment and configuration.