vRealize Network Insight - The Power it brings

I happen to do some hands-on for vRealize Network Insight (VRNI) yesterday and realized how powerful this tool is. 
So far in all our discussions with customers we talk about how micro-segmentation and security brings in so many benefits to customer but the ball drops when we come to plan and architect the deployment for NSX.
That's because, migrating a brown-field setup and introducing NSX in an existing environment needs a deep level analysis of existing network infrastructure, layout, policies etc. Its a humongous exercise in itself, thus for architects to craft the best design it takes in a lot of efforts and due diligence. This is where VRNI comes into picture.

One of the major use cases and benefits of VRNI as i see is, it allows you to do most granular level assessment of Network in your Datacenter. It gives you visibility and analytics across virtual and physical networks. It shows complete packet walk, data path between 2 tiers, 2 zone, 2 PGs or 2 components (as you may want to see) of your Datacenter.

This makes it very useful and easy for Network & Security architects to design the environment by effectively planning using the recommendation around micro-segmentation security.

Besides this it also helps in ensuring that the NSX deployment is healthy and operational the way it should be. If there are any glitches in implementation like maybe overlapping firewall rules - it would highlight them straight up for the admin to remediate them.

Taken at VMworld 2016 Las Vegas

VMware at VMworld 2016 announced the new Cross Cloud Architecture using VMware Cloud Foundation. The architecture allows you to extend your private cloud workloads to the public cloud along with Management, Governance and Security extension across public clouds including AWS, Azure and IBM Cloud.




One of the challenges which Cloud Foundation allows us to over come is Network and Security extension from Private to Public clouds. VRNI is the tool which runs in the background which does the assessment/designing of security policies on the Public cloud workloads and make changes to it to matching with Private cloud.

We should see some cool labs around the same coming up VMware HOL soon, so suggest stay tuned. 

Fun Video - VMware cost advantage over Hyper-V

Total Cost of Ownership from VMware Videos on Vimeo.

VSAN 6.2 - Cache to Capacity Ratio

One of the integral component of VSAN storage subsystem is a Disk-group. A Disk-group in VSAN comprises of Cache Tier and Capacity Tier.

We need to have One Cache drive and maximum of seven Capacity drives to form a disk group. 

In case of a All Flash VSAN solution both Cache and Capacity tiers are flash drives, whereas in a Hybrid VSAN solution Cache tier is a flash drive and Capacity tier is a mechanical drive (SAS/NL-SAS).

While creating a VSAN based solution, below are the high level steps involved...

• We decide how many hosts needed to meet the Compute requirement.
• How much Usable and hence derived Raw capacity (based on FTT levels) needed.
• Considering each host have at-least one disk-group (Cache and Capacity tier), the required capacity is divided across the hosts. If the capacity requirement is high, sometimes we may end up having more than one disk-groups per host. 

At this stage its important to also consider Cache to Capacity ratio.

In a VSAN sizing, defining a Disk-group composition is a critical point. This has quite frequently come up in many of my discussions with OEM partners and customers.

To answer that let's look into the role of Cache a bit more granularly.

Purpose of Cache

Like in any Enterprise Storage, caching helps in improving performance of your Read and Write IOs.

The Cache tier in Hybrid VSAN solution caches both read and write IOs. By Default 30% is used for Write back Cache buffers and 70% for Read cache.

Whereas in an All-Flash VSAN solution, 100% cache is used for Write Back Cache buffers. The Read IOs are directly moved to capacity tier (which can be a low endurance, low cost but higher capacity flash drives).

On this note...its important to mention that having a Enterprise class, High endurance Cache tier is highly recommended, as it caches most of the write operations first. It also helps in increasing the life of a flash capacity drives.

Also read cache is only relevant in Hybrid solution, where it caches the most recently read blocks and blocks in vicinity (read ahead) to increase the cache hit ratio. This is most effective in environment with similar data across VMs or with sequential IOs. e.g. VDI/RDSH environments.

The VSAN read cache algorithm is also improved by uniquely design Distributed data locality feature. Read here

For more on VSAN Caching Algorithm in general, read here

So even if it may not explicitly come up but workload characteristics largely defines the Read/Write Cache distribution, which in turn contributes to the Cache size.

Besides this there are plenty of other disk related factors (like DWPD, TBW, Write Amplification etc.) which contributes to the Cache to Capacity ratio. 

With support of some scientific calculations, VMware suggests 10% as a general guideline for Cache to Capacity ratio.

Which means that the Suggested Cache size = 10% of the Required Usable Capacity (before considering FTT, Erasure Coding or De-duplication and Compression).

NEVER consider Raw Capacity for this calculation but only required usable capacity.

What fits your environment - Sizing for a VDI environment (Part 2)

So once User Profiling is done (here), next is to size for the environment.

This page talks about how do we conceive sizing for VDI workload and what parameters to be considered before we jump into a calculation.

While there are plenty of calculators available online, but one should not blindly follow them. 

Few important factors should be strongly considered before the rubber hits the road.

Listing down the important building blocks and pointers around them.

CPU:  

VDI is an independent OSE for a user (not shared), hence we start our sizing by knowing how much CPU cycles a user would consume for his day to day activity.

• The best way to find out is to use capacity planner tools like lakeside (check out assessment.vmware.com).
• In case that’s not possible, you can refer to benchmarks available by VMware for Task Worker, Knowledge workers and Power Users etc. as guidelines.
• Make sure you factor CPU overheads for antivirus or software updates (unless planned to be staggered in non-peak hours or other considerations like agent-less AV)
• Assigning more vCPU to a VDI need not necessarily improve the performance. It largely depends on the type of application running inside the VDI. Its only multi-threaded applications (which are compute intensive) which can benefit from multiple vCPU using SMP (symmetric multiprocessing) to improve performance. For lighter workloads or single threaded application single vCPU per VDI is sufficient

Memory: 

The next is to identify how much Memory needs to be assigned per VDI. Insufficient RAM allocations can cause excessive Windows paging, generating I/O load causing performance impact.

• Additional memory needs to be considered for Video RAM / PCOIP Display overhead.
• To avoid excessive use of TPS, Ballooning or Paging, its better we do not consider Memory overcommitment. Rather Memory Reservation is good idea (subject to the scenario) to ensure there is no lack of resources
• For Graphic rendering workload (if not using vSGA or vDGA), we need to ensure enough additional memory is allocated for Software based 3D Graphic rendering. For more details check VMware Horizon 3D Engineering Workloads Reference Architecture

Storage: 

Storage for VDI environment can be a topic in itself, however there are few usually ignored areas while sizing.

• Sizing for Full Clone and Linked clone are 2 separate methods. I'll try to write a page for both maybe in some time. However the more complex is Linked clone sizing, hence i would take that as a reference for now.
• Make sure you factor Swap file and log file capacity requirement per VDI VM.
• Storage optimization can be only be achieved for OS drive (C: drive) and NOT User data drive (D: drive).
• Make sure you factor a growth percent for Delta disk (in Linked clone setup) for Linked Clone VDI.
• Depending on number of pools to be created, capacity for Golden Images and Replica Image needs to be factored.
• Make sure you factor for User profile capacity besides User Data. Persona Management/Roaming profile/UEM can help you manage the User Profile data in better way.
• Additional storage needs to be factor for Infra VMs like vCenter, Connection Server/Replica Server/Security Servers, Composer, Databases, App Volumes, UEM Manager etc.
• For vSphere 5.1 and Horizon 5.2 and above, space reclamation with SE Sparse disk is must mechanism for efficient management of the Linked clone VDI environment. You can read more about SE Sparse disks and Space Reclamation here
• Besides Capacity, Performance happens to be an important factor when talking about storage. Performance is measured by 2 parameters.
• IOPS : Once we have calculated the capacity requirement, we need to check how many IOPS would be needed per user per VDI. IOPS per VDI is sub-divided in 2 sections
• OS+ Application IOPS : This is catered by Delta Disk and Replica Disk
• User Data and Profile IOPS: This is catered by Delta Disk and User Data disk
• Latency: I have seen many projects where Capacity and IOPS were rightly considered but latency of the disks were ignored, leading to unsatisfactory performance results. Latency is factor of type of disk catering to your IOs (SSD/SAS/NL-SAS). While it largely depends on user workload but in a Tiered storage architecture we can follow the below guidelines around latency requirements.
• Replica Disk < 1 ms
• Linked Clone Disk / Delta Disk < 5 ms
• User Data Disk < 10ms

What fits your environment - VDI or RDSH/App Publishing (Part 1)

One of the most important and first step in any End User Computing based project is Plan and Design. And the most important step off Plan and Design is User Profiling.

I have seen numerous projects failing in absence of appropriate planning and profiling of Users.

By User Profiling I mean to look into below classifications

• Which user categories are considered as a part of EUC Project ?
• What is their working nature, e.g. field sales, front desk, developers etc.?
• What applications do they use?
• What Operating System does the end user use for day to day work?
• Do they use any specific external devices with their desktops?
• Do they need admin rights to install and applications?

And so on…

The more you know and understand end user environment, the better will be plan and design outcome.

These factors also decide the which technology would be appropriate - A true VDI or a Shared Desktop.

To illustrate with an example: -

·    If I have a developer who needs to run scripts, test different application and do a lot of custom work, I will choose to give him Full Clone Desktop or Linked Clone Desktop with a Writable Volume attached.

·    However, if my user is a field sales guy and only access his desktop occasionally to update his CRM application, RDSH or App Publishing is most appropriate.

Once you have decided on the technology the next step of Planning is Sizing for the environment.

You can read my below posts on details around sizing

• Sizing for a VDI environment
• Sizing for a Hosted Desktop or Application Publishing environment