Thursday, September 12, 2019

Datacenter Fabric for HCI in scale

I'm currently designing a brand new data center based on VMware HCI for one of my customers. Conceptually, we are planning to have two sites in the metro distance (~10 km) for disaster avoidance and cross-site high availability. For me, a cross-site high availability (stretched metro clusters) is not a disaster recovery solution, so we will have the third location (200km+ far from the primary location) for DR purposes. We are also considering remote clusters in branch offices to provide services outside the datacenters. The overall concept is depicted in the drawing below.
Datacenter conceptual design
The capacity requirements lead to a decent number of servers, therefore the datacenter size will be somewhere around 10+ racks per site. The rack design is pretty simple. Top of rack switches and standard rack servers connected to TOR switches optimally by 4x 25Gb link.
Server rack design
However, we will have 10+ racks per site so there is the question of how we will connect racks together? Well, we have two options. Traditionally (Access / Aggregation / Core) or Leaf/Spine. In our case, both options are valid and pretty similar because if we would use Traditional topology, we would go with collapsed Access / Core topology anyway, however, the are two key differences between Access/Core network and Leaf/Spine fabric

  1. Leaf/Spine is always L3 internally keeping L2/L3 boundary at TORs. This is good because it splits the L2 fault domain and mitigates risks of L2 networking with STP issues, broadcast storms, unknown unicast flooding, etc.
  2. Leaf/Spine supports additional fabric services like automation, L2 over L3 to have L2 across the racks (PODs), Life Cycle Management (fabric level firmware upgrades, rollbacks, etc.), Single Point of Management/Visibility, etc.

We are designing the brand new data center which has to be in production for the next 15+ years and we will need very good connectivity within the data center supporting huge east-west traffic, therefore leaf-spine fabric topology based on 100Gb/25Gb ethernet makes a perfect sense. The concept of data center fabric in leaf-spine topology is depicted in the figure below.
Datacenter fabric
Ok. So, conceptually and logically we know what we want but how to design it physically and what products to choose?

I've just starting to work for VMware as HCI Specialist supporting Dell within our Dell Synergy Acceleration Team, so there is no doubt VxRAIL makes a perfect sense here and it perfectly fits into the concept. However, we need a data center fabric to connect all racks within each site and also interconnect two sites together.

I have found that Dell EMC has SmartFabric Services. You can watch the high-level introduction at
https://www.dellemc.com/en-us/video-collateral/dellemc-smartfabric-services-for-vxrail.htm

SmartFabric Services seems very tempting.  To be honest, I do not have any experience with Dell EMC SmartFabric so far, however, my regular readers know that I was testing, designing and implementing Dell Networking a few years ago. At that time I was blogging about Force10 Networking (FTOS 9) technology and published a series of blog posts available at https://www.vcdx200.com/p/series.html 

However, DellEMC SmartFabric Services are based on a newer switch operating system (OS 10) which I do not have any experience yet, therefore, I did some research and I found a very interesting blog posts about Dell EMC SmartFabric published by Mike Orth aka @HCIdiver and Hasan Mansur. Here are links to blog posts:


So the next step is to get more familiar with DellEMC SmartFabric Services because it can significantly simplify data center operations and split the duties between the datacenter full-stack engineers (compute/storage/network) and traditional network team.

I personally believe, that datacenter full-stack engineer should be responsible not only for compute and storage (HCI) but also for data center fabric. And the traditional networking team takes the responsibility at network rack where the fabric is connected to the external network. You can treat datacenter fabric as a new generation of SAN which is nowadays operated by storage guys anyway, right?

Hope this makes sense and if there is anybody with Dell EMC SmartFabric experience or with a similar design, please feel free to leave the comment below or contact me on the twitter @david_pasek.

Wednesday, September 11, 2019

New job role - vSAN rulez

Hey, my readers.

Long-time readers of my blog know that I'm working with VMware datacenter technologies since 2006 when I moved from software development to data center infrastructure consulting. In June 2006, VMware released VMware Virtual Infrastructure 3 and it was for me the first production-ready version for hosting business applications. Back in the days, it was a very simple platform (at least for end-users / administrators) and very functional piece of software with huge business benefits.

Let me share with you one secret I have discovered. As I have the software background, over the years I personally developed a lot of software on my own and also in the development teams so there is the law I personally discovered during my developer days in 90' and 2000' ... "The 3rd version of the developed software code is production-ready and to develop three software versions usually takes around 5 years." There are multiple reasons for this statement but this is beyond the scope of this post.

I will just give you two examples related to the topic of this article.

  1. ESX 1.0 was released on March 2001 and production-ready (at least for me) was the version ESX 3.0 released on June 2006 ... 5 years of software development and continuous improvements based on customers feedback 
  2. vSAN 1.0 was released in 2013 and production-ready (at least for me) vSAN 6.7 U1 in October 2018 ... .. 5 years of software development and continuous improvements based on customers feedback 
But let's go back to the topic of this blog post. Since 2006, I'm dealing with various adventures and challenges with server virtualization and software-defined infrastructure as the whole. It was and still is a very interesting journey and great industry and community to be as the infrastructure principles do not change very often and it was mainly about the better manageability, scalability, and simpler infrastructure consumption for application admins. Well, when I'm saying that key principles in IT infrastructure do not change very often there are few innovations over decades which change the industry significantly.
  • Think about "The Flash" (SLC, MLC, QLC, Intel Optane, NVMe) which already changed the storage industry.
  • Think about the concept of Composable Disaggregated Infrastructure
  • Think about software-defined infrastructures in compute, storage and network
Few innovations mentioned above are changing the technologies but it always takes some time because the most resistant for change are humans. On the other hand, resistance or conservatism if you will, is not always bad because, at the end of the day, the infrastructure is just another tool in the toolbox of IT guys supporting the business.

Well, this is a pretty important thing to realize.
Infrastructure is not here for the sake of the infrastructure but to support software applications. And software applications are not here for the sake of applications but to support some business, whatever the business is. And each business supports some other business. So generally speaking, the quality of the support and simplicity in consumption is the key to have satisfied customers and be successful in any business.
During my datacenter career, I worked for two infrastructure giants - Dell and Cisco - delivering server, storage, and network virtualization consulting to simplify sometimes pretty complex infrastructures. If you ask me for one reason why this is the interesting industry to be, my answer would be - THE SIMPLIFICATION BY ABSTRACTION.

When I look back retrospectively, this is the reason why I have decided to focus on VMware platform and invest my time (13+ years) into this technology. Back then, I have chosen VMware because they were emulating physical infrastructure components as a logical software constructs all backed by API with automation in mind from day zero. Another reason to chose the virtualization abstraction is that I'm a big believer of standardization and commoditization. It allowed me to leverage my existing knowledge about infrastructure principles. The disk is the disk, logically does not matter if it is connected locally through SATA, SCSI or remotely over Fibre Channel, iSCSI. At the end of the day, the disk is there to have a block device on a server and store some data on it. Period. And similarly, you can think about other infrastructure components like NIC, Switch, Router, File Storage, Object Storage, you name it.

My decisions and good intuition always paid back. Nowadays, nobody doubts about server virtualization and business-critical apps and even mission-critical apps are virtualized or planned to be virtualized soon. It's all about x86 commoditization and "good enough" technology. Compare it with another example in ICT. Do you remember the Telco battle between traditional telephone and IP telephony? I do. And do you see such discussions nowadays? No, no. It was accepted as a "good enough" technology even you do not have 100% guarantee you own the line during the telephone conversation. However, it has a lot of other benefits.

And we are in the same situation with PRIMARY STORAGE in datacenters. During the last 10+ years, I was dealing with or witnessing multiple storage issues in various data centers. I'm always saying NO STORAGE = NO DATACENTER. The storage system is a critical component of any datacenter. The major incidents and problems were caused because of
  • environment complexity (SAN fan-in / fan-out ratios, micro-bursting, and "slow-drain" issues)
  • overloaded storage systems from a performance point of view (any overloaded system behaves unpredictable, even a human body).
  • human mistakes
I was witnessing all these issues not only as a data center consultant but also as VMware Technical Account Manager during last 4 years, helping few assigned VIP VMware accounts to keep lights up and think strategically how to simplify data center infrastructures and deliver the value to the business.

Since 2013, VMware is developing the next big thing, software-defined storage. As I've mentioned above, from a technical point of view, I believe vSAN 6.7 U1 is the production-ready piece of software and from now it will be better and better. I'm not saying there are not or will not be any problems. The problems are everywhere around us, the failure is inevitable, but it is about the availability and recoverability options and how fast any solution can be fail-over or recovered. This is again beyond the scope of this article but I hope you understand the point.

Nevertheless, the software eats the world and I believe, there is the momentum for Hyper-Converged Infrastructures which in VMware means vSAN. Of course, it will require some time to convince traditional storage architects, engineers, and operation guys but the trend is absolutely clear. For the transition period, VMware has other storage technologies to leverage not only vSAN but consume traditional storage systems more intelligently with vVols and evolve into software-defined datacenter (SDDC) eventually.

So let me announce publically, that since September 1st, I work for VMware as a Senior Systems Engineer for Hyper Converged Infrastructure (HCI). As a VMware Systems Engineer for HCI, I'm responsible for driving the technical solutions to ensure customer success and revenue goals derived from VMware software and solutions. I'm focused on HCI solutions for assigned Alliance Partner (Dell Technologies) working closely with both the Alliance Partner and VMware technical teams to build the differentiation with that Alliance. I will be also able to bring feedback from the field to VMware and Alliance Product Management teams.

So what you, my blog readers, can expect? More storage-related blog posts about vSAN, vVols, vSphere Replications, SRM, I/O filters leveraged for 3rd party solutions, etc.


I'm excited and looking forward to this new journey. Hope I will have enough spare time to blog about the journey and share it with great VMware community. 

Wednesday, August 28, 2019

VMware Ports and Protocols

VMware recently released a very interesting tool. The tool documents all network ports and protocols required for communication from/to some VMware products. At the moment, there are the following products

  • vSphere
  • vSAN
  • NSX for vSphere
  • vRealize Network Insight
  • vRealize Operations Managers
  • vRealize Automation
I believe other products will follow. See the screenshot of the tool below.



The tool is available at https://ports.vmware.com/

I'm pretty sure technical designers and implementation engineers will love this tool.

Wednesday, August 21, 2019

VMware vSphere 6.7 Update 3 is GA

VMware vSphere 6.7 Update 3 is GA as of August 20, 2019.

The most interesting new feature is the possibility to change the Primary Network Identifier (PNID) of vCenter Server Appliance

With vCenter Server 6.7 Update 3, you can change the Primary Network Identifier (PNID) of your vCenter Server Appliance. You can change the vCenter Server Appliance FQDN or hostname, and also modify the IP address configuration of the virtual machine Management Network (NIC 0).

I wrote about PNIC last year here on this blog post What is vCenter PNID?
It is a great improvement that you can change vCenter FQDN, however, the process has some 

For further operational details on how to change vCenter Server's FQDN/PNID read the blog post - Changing your vCenter Server’s FQDN.

There are a few more new features and enhancements

  • vCenter Server 6.7 Update 3 supports a dynamic relationship between the IP address settings of a vCenter Server Appliance and a DNS server by using the Dynamic Domain Name Service (DDNS). The DDNS client in the appliance automatically sends secure updates to DDNS servers on scheduled intervals.
  • With vCenter Server 6.7 Update 3, you can publish your .vmtx templates directly from a published library to multiple subscribers in a single action instead of performing a synchronization from each subscribed library individually. The published and subscribed libraries must be in the same linked vCenter Server system, regardless if on-premises, on cloud, or hybrid. Work with other templates in content libraries does not change.
  • With vCenter Server 6.7 Update 3, if the overall health status of a vSAN cluster is Red, APIs to configure or extend HCI clusters throw InvalidState exception to prevent further configuration or extension. This fix aims to resolve situations when mixed versions of ESXi host in a HCI cluster might cause vSAN network partition.
  • ixgben driver enhancements
  • VMXNET3 enhancements
  • NVIDIA virtual GPU (vGPU) enhancements
  • bnxtnet driver enhancements
  • QuickBoot support enhancements
  • Configurable shutdown time for the sfcbd service

For further information read ESXi Release Notes here, vCenter Release Notes here and VMware Update Manager here.


Tuesday, August 20, 2019

VMware vSAN 6.7 U3 has been released

VMware vSAN 6.7 U3 is GA as of August 20, 2019!
This is a great release. I was waiting mainly for Native support for Windows Server Failover Clusters which is now officially supported so no more vSAN iSCSI targets and in-Guest iSCSI for shared disks across the WSFC as vSAN VMDKs now support SCSI-3 persistent reservations. This is a great improvement and significant simplification for vSphere / vSAN architects, technical designers, implementers, and operational guys. For further details see blog post "Native SQL Server Cluster support on vSAN

However, there are other operations, performance, and availability improvements in 6.7 U3. Let's highlight the key improvements.
What's New?
Cloud Native Applications
Cloud Native Storage: Introducing vSphere integrated provisioning and management of Kubernetes persistent volumes (PVs) and a CSI (Container Storage Interface) based plugin. This integration enables unified management of modern and traditional applications in vSphere.
Intelligent Operations
Enhanced day 2 monitoring: vSAN’s capacity dashboard has been overhauled for greater simplicity, and the resync dashboard now includes improved completion estimates and granular filtering of active tasks
Data migration pre-check report: A new detailed report for greater insight and predictive analysis of host maintenance mode operations
Greater resiliency with capacity usage conditions: Key enhancements include reduced transient capacity usage for policy changes, and improved remediation during capacity-strained scenarios
Automated rebalancing: Fully automate all rebalancing operations with a new cluster-level configuration, including modifiable thresholds
Native support for Windows Server Failover Clusters: Deploy WSFC natively on vSAN VMDKs with SCSI-3 persistent reservations
Enhanced Performance & Availability
Performance enhancements: Deduplication & compression enabled workloads will have improved performance in terms of predictable I/O latencies and increased sequential I/O throughput
Availability enhancements: Optimizations to sequential I/O throughput and resync parallelization will result in faster rebuilds

Thursday, August 08, 2019

vSAN Capacity planning - Understanding vSAN memory consumption in ESXi

It is very clear that VMware vSAN (VMware's software-defined storage) has the momentum in the field, as almost all my customers are planning and designing vSAN in their environments. Capacity planning is an important part of any logical design, so we have to do the same for vSAN. Capacity planning is nothing else than simple math, however, we need to know how the designed system works and what overheads we have to include in our capacity planning exercise. Over the years, a lot of VMware vSphere technical designers did get knowledge and practice how to do capacity planning for core vSphere because server virtualization is here for ages (13+ years). But we all are just starting (3+ years) with vSAN designs, therefore it will take some time to gain the practice and know-how what is important to calculate in terms of VMware hyper-converged infrastructure (VMware HCI = vSphere + vSAN).

One of the many important factors for HCI capacity planning is vSAN memory consumption from the ESXi host memory. There is very good VMware KB 2113954 explaining the math calculation and formulas behind the scene. However, we are tech geeks, so we do not want to do the math on the paper so here is the link to Google Sheets calculator I have prepared for vSAN (All-Flash) memory overhead calculation.

Here is the calculator embedded into this blog post, however, it is just in read-only mode. If you want to change parameters (yellow cells) you have to open Google Sheet available on this link.



Note: I did not finish the calculator for Hybrid configuration because I personally believe that 99% of vSAN deployments should be All-Flash. The reason for this assumption is the fact, that Flash capacity is only 2x or 3x more expensive than magnetic disks and the lower price of magnetic disks is not worth to low speed you can achieve by magnetic disks. In terms of capacity, advanced technics like erasure coding (RAID-5, RAID-6) and deduplication + compression can give you back capacity in All-Flash vSAN as these technics are available or make sense only on All-Flash vSAN. If you would like the same calculator for Hybrid vSAN, leave the comment below this blog post and I will try to find some spare time to prepare another sheet for Hybrid vSAN.

Let's document here some design scenarios with vSAN memory consumptions.

Scenario 1
ESXi host system memory: 192 GB
Number of disk groups: 1
Cache disk size in each disk group: 400 GB
Number of capacity disks in each disk group: 4
vSAN memory consumption per ESXi host is 17.78 GB.

Scenario 2
ESXi host system memory: 192 GB
Number of disk groups: 2
Cache disk size in each disk group: 400 GB
Number of capacity disks in each disk group: 2
vSAN memory consumption per ESXi host is 28 GB.

Scenario 3
ESXi host system memory: 256 GB
Number of disk groups: 2
Cache disk size in each disk group: 400 GB
Number of capacity disks in each disk group: 2
vSAN memory consumption per ESXi host is 28.64 GB.

Hope this is informative and it helps broader VMware community. 

Friday, August 02, 2019

Updating Firmware in vSAN Clusters from VUM

If you operate vSAN you know that correct firmware and drivers are super important for system stability as vSAN software heavily depends on IO controller and physical disks within the server.

Different server vendors have different system management. Some are more complex than other but typical vSphere admin is using vSphere Update Manager (VUM) so would not it be cool to do firmware management directly from VUM? Yes, of course, so how it could be done?

Well, there is a chapter in vSphere documentation covering "Updating Firmware in vSAN Clusters", however, there is no information what hardware is supported. I did some internal research and colleagues have pointed me to VMware KB 60382 "IO Controllers that vSAN supports firmware updating" where supported IO Controllers are listed.

At the time of writing this post, there are plenty of Dell IO Controllers, two Lenovo, two SuperMicro and one Fujitsu.

At the moment, you can update only IO Controllers but it may or may not change in the future.