With the recent announcement of our VMware Cloud Foundation (VCF) powered UCP RS system to deliver a hybrid cloud reality (check Dinesh's blog here for details), one of the interesting questions from early prospects is advice or guidance on how others are managing a hybrid private environment which consists of a traditional VMFS environment (and lately VVol) as they bring VMware vSAN based architectures into their environments. The basis for this question or the outcome they want to meet is to provide a pool of resources accessible to the various line of business or application teams which should provide different characteristics while providing those consumers with some level of intuitive control on where their assets will run to ensure they can meet their intended SLAs.
Here are some Amazon EBS Storage options to give a perspective on why this will be important in your VMware powered private hybrid cloud designs.. Each separate EBS volume can be configured as EBS General Purpose (SSD), Provisioned IOPS (SSD), Throughput Optimized. (HDD), or Cold (HDD) as needed. They have stated that some of the best price/performance balanced workloads on EC2 do take advantage of different volume types on a single EC2 instance. For example, they mention they see Cassandra using General Purpose (SSD) volumes for data but Throughput Optimized (HDD) volumes for logs, or Hadoop using General Purpose (SSD) volumes for both data and logs. This level of differentiation is first step in providing tiers of service to consumer of cloud resources.
Source: AWS Storage Options
But again, performance is just one layer. There are many characteristics when it comes to SLAs. Take the "availability" characteristic. As you may know, because an EBS volume is created in a particular availability zone, the volume will be unavailable in other availability zones if original availability zone itself became unavailable. Resources aren't replicated across regions unless you do so specifically. Again, that might be an important characteristic to an app service being rolled out (To be fair to AWS, they recommend creating snapshots as snapshot of volume(s) are available across all of the availability zones within a region)
This is an area that I've put some cycles into with the team when we defined the requirements around the latest release of our Hitachi VASA Provider (VP) version 3.4 to operationally enhance the right consumption of resources for vSAN, VMFS and/or VVol. Based on the VVol/SPBM program, we took advantage of some of the storage container concepts and latest tagging capabilities in vSphere 6.x to provide a better experience. With the latest Hitachi VP software, VMFS datastores (that may be adding additional datastore resources to an existing VCF based vSAN deployment or separate traditional VMFS environment), will be automatically tagged in vCenter with their specific SLA including cost characteristics. Click to enlarge GIF below to get a perspective of how the new VP WebUI (and API) provides the facility to assign capabilities to infrastructure resources, including automated vCenter tagging of VMFS datastores while allowing vSAN datastore(s) to be similar tagged with appropriate category capabilities. The end result is much more intuitive description of the resource capabilities available across vSAN, VMFS and VVol.
With this automated tagging of capabilities to existing and new datastores, vSphere policies can now be much richer and descriptive to consumers. Click to enlarge animated GIF below as it rolls through a typical vSphere policy, in this case a policy describing "Tier 1 Performance and DR Availability" with rulesets for VMFS, VVol and vSAN within the same policy. In my lab environment, this policy with its Tier 1 performance, Tier 2 availability and lowest cost capability found matching storage on all three entities allowing consumer to pick one of choices
The VMFS datastore highlighted below was configured to provide the highest level of availability and performance (GAD multi-datacenter active-active replicated enabled LDEV using accelerated flash on F1500 with data at rest encryption) and the VP software automatically tagged the corresponding datastore with the following capabilities; Tier 1 availability and performance, encryption and cost between 750 and 1000 units. This datastore would be a match when app owners or admins selected the "Tier 1 Performance, Encrypted and Active-Active availability" policy which in my lab environment ruled out vSAN or VVol as potential targets.
Taking the Apache Cassandra application example from Amazon, which I wanted to deploy on the VCF powered UCP RS system. During provisioning, I assigned the appropriate application owner understandable policy for each of the disks:- the high performance data disks for Cassandra VM with lower capacity landed on the vSAN datastore, while the log disk, 10x the size, landed on the iSCSI VMFS datastore. I didn't consume unnecessary storage from my all-flash vSAN as the VMFS datastore (and VVol datastore) was a suitable match for the characteristics for the log data in this example. There is so much more that can be exploited when you think of these capabilities can easily be extended and expressed for other infrastructure resources.
In summary, when it comes to provisioning resources, whether its from vSphere Client or vRealize Automation with its SPBM awareness, these richer policies are select-able to ensure appropriate resources are selected at VM level or indeed VMDK level. Taking a leaf out of Amazon's trees in EC2, this is the type of resource variability and ease of consumption needed to run a sustainable cloud environment meeting diverse needs across many application services as you update and modernize your infrastructure.
Check out the live demonstration of VCF powered UCP RS and Hitachi VASA (VP) Software at #VMworld 2017