My public speaking experience

It can be a bit of a hassle; working on cool projects as a contractor and finding the time to take days off to visit and/or present at a VMworld, VMUG or other industry events. And that is next to putting in the hours to co-write some pretty awesome books if I may say so myself.

Busy but fun times! However, it is really important to me to keep attending industry events. I genuinely love to visit and present as I really see it as a investment in myself and our community. Meeting new people is always fun and interesting, and listening in on sessions is very educational. While doing so, I get the chance to practise public speaking.

The article by Duncan Epping (http://www.yellow-bricks.com/2018/03/08/confessions-of-a-vmug-speaker-the-prequel-speakerfail/) made me recap and think about my experiences with public speaking so far.

The First Time

It’s only been 2 years since I’ve started to (co-)host presentations. It was the NLVMUG in 2016. I can relate to the excess of rehearsing as Duncan described in his article. I was pretty psyched but mostly nervous to present at a VMUG. I talked in front of customers a lot, but public speaking felt like a totally different ballgame.

But there I was, presenting in front of peers. Looking back at the recordings, there are so many points I want to improve on. And the best way to learn and improve is to do it more often. Around that time, Frank and I started writing our Host Deep Dive book. We got the chance to present some of the content at both VMworlds in 2016.

I remember that VMworld US 2016 was the second or third time I was on stage, but the first time not speaking native tongue. We had a big room and something in the range of 800 registrants! Once we walked to our room, Oceanside D, we witnessed a large amount of people waiting to get into the room. I managed to film the part when they opened the doors:

Very cool to witness, but a little bit scary as well. I kicked of the introductions only to stumble on the very first sentences and had trouble pronouncing our own session title. Talking about #speakerfail. Once I was up to do my part, the nerves settled and I had a lot of fun presenting. Afterwards, people who attended the session were positive and we scored a top-10 session which was awesome!

Since then, I had the chance to do several VMUGs with Frank next to the NLVMUG and both VMworlds again in 2017. We presented at the German, London, Italy and the Nordic VMUG.

Moral of the this short write-up;

If I can do it, you most certainly can!

I talked to a lot of people who want to present at a VMUG or other events, but it looks like they worry far too much to go through with it. It’s okay to be nervous, but don’t let it get you. It’s that thing about stepping outside your comfort zone and into the zone where the magic happens… Presenting is a great opportunity to share your knowledge and experience, and in the process, put your name on the charts.

Upcoming Schedule

Hopefully, I’ll get the chance to present at VMworld 2018. Two session are submitted, session ID 1738 and 1735. Pretty cool as one session will be together with a lead-engineer who works on Network DRS within VMware!

With the support of the VMUG organization and our friends at Rubrik, we will attend the Indianapolis VMUG at the 10th of July. Attending and presenting at one of the largest US based VMUGs will be a very good experience.

Also, the VMUG at Prague on the 24th of May is on the schedule, really looking forward to that one!

There are some other opportunities that are work in progress.

To Conclude

I honestly hope that my experience can encourage others to take the leap of faith and contribute at an upcoming VMUG. Think about that project you’re working on and the design choices you made for it to succeed. Or what about that issue you ran into and solved. All very good content to convey to our VMware community.

Like the Nike campaign launched in 1988 stated; Just do it!!

Read More

FREE vSphere 6.5 Host Resources Deep Dive E-Book

In June of this year, Frank and I published the vSphere 6.5 Host Resources Deep Dive, and the community was buzzing. Twitter exploded, and many community members provided rave reviews.

This excitement caught Rubriks attention, and they decided to support the community by giving away 2000 free copies of the printed version at VMworld. The interest was overwhelming, before the end of the second signing session in Barcelona we ran out of books.

A lot of people reached out to Rubrik and us to find out if they could get a free book as well. This gave us an idea, and we sat down with Rubrik and the VMUG organization to determine how to cater the community.

We are proud to announce that you can download the e-book version (PDF only) for free at rubrik.com. Just sign up and download your full e-book copy here.

 

Spread the word! And if you like, thank @Rubrik and @myVMUG for their efforts to help the VMware community advance.

 

A quick impression of the buzz at the Rubrik booth at VMworld:

Read More

TCP Segmentation Offload in ESXi explained

TCP Segmentation Offload (TSO) is the equivalent to TCP/IP Offload Engine (TOE) but more modeled to virtual environments, where TOE is the actual NIC vendor hardware enhancement. It is also known as Large Segment Offload (LSO). But what does it do?

When a ESXi host or a VM needs to transmit a large data packet to the network, the packet must be broken down to smaller segments that can pass all the physical switches and possible routers in the network along the way to the packet’s destination. TSO allows a TCP/IP stack to emit larger frames, even up to 64 KB, when the Maximum Transmission Unit (MTU) of the interface is configured for smaller frames. The NIC then divides the large frame into MTU-sized frames and prepends an adjusted copy of the initial TCP/IP headers. This process is referred to as segmentation.

When the NIC supports TSO, it will handle the segmentation instead of the host OS itself. The advantage being that the CPU can present up to 64 KB of data to the NIC in a single transmit-request, resulting in less cycles being burned to segment the network packet using the host CPU. To fully benefit from the performance enhancement, you must enable TSO along the complete data path on an ESXi host. If TSO is supported on the NIC it is enabled by default.

The same goes for TSO in the VMkernel layer and for the VMXNET3 VM adapter but not per se for the TSO configuration within the guest OS. To verify that your pNIC supports TSO and if it is enabled on your ESXi host, use the following command: esxcli network nic tso get. The output will look similar the following screenshot, where TSO is enabled for all available pNICs or vmnics.

(more…)

Read More

Virtual Networking: Poll-mode vs Interrupt

The VMkernel is relying on the physical device, the pNIC in this case, to generate interrupts to process network I/O. This traditional style of I/O processing incurs additional delays on the entire data path from the pNIC all the way up to within guest OS. Processing I/Os using interrupt based mechanisms allows for CPU saving because multiple I/Os are combined in one interrupt. Using poll mode, the driver and the application running in the guest OS will constantly spin waiting for an I/O to be available. This way, an application can process the I/O almost instantly instead of waiting for an interrupt to occur. That will allow for lower latency and a higher Packet Per Second (PPS) rate.

An interesting fact is that the world is moving towards poll-mode drivers. A clear example of this is the NVMe driver stack.

The main drawback is that the poll-mode approach consumes much more CPU time because of the constant polling for I/O and the immediate processing. Basically, it consumes all the CPU you offer the vCPUs used for polling. Therefore, it is primarily useful when the workloads running on your VMs are extremely latency sensitive. It is a perfect fit for data plane telecom applications like a Packet GateWay (PGW) node as part of a Evolved Packet Core (EPC) in a NFV environment or other real-time latency sensitive workloads.

Using the poll-mode approach, you will need a pollmode driver in your application which polls a specific device queue for I/O. From a networking perspective, Intel’s Data Plane Development Kit (DPDK) delivers just that. You could say that the DPDK framework is a set of libraries and drivers to allow for fast network packet processing.

Data Plane Development Kit (DPDK) greatly boosts packet processingperformance and throughput, allowing more time for data plane applications. DPDK can improve packet processing performance by up to ten times. DPDK software running on current generation Intel®Xeon® Processor E5-2658 v4, achieves 233 Gbps (347 Mpps) of LLC forwarding at 64-byte packet sizes. Source: http://www.intel.com/content/www/us/en/communications/data-planedevelopment-kit.html

DPDK in a VM

Using a VM with a VMXNET3 network adapter, you already have the default paravirtual network connectivity in place. The following diagram shows the default logical paravirtual device connectivity.

(more…)

Read More

Why we chose vSAN for our business critical apps

Looking at the IT infrastructure at several production sites within my customer’s organization, we quickly noticed IT infrastructure components (mainly compute and storage related) that were not up to par from an availability and performance perspective. The production sites all run local business critical ERP application workloads that are vital to the business processes. After researching and discussing a lot, I proposed my customer a new blueprint. The blueprint consists of a new compute and storage baseline for the site local datacenters. The idea was to create a platform that allows for a higher availability and more performance while reducing costs.

We researched the possibility to step away from the traditional storage arrays and move towards a Hyper Converged Infrastructure (HCI) solution. Because IT is not the main business of the company, we were trying to keep things as simple as possible. We defined several ‘flavors’ to suit each production location to its needs. For example, the small sites will be equipped with a ROBO setup, the medium sites with a single datacenter cluster and the large factories are presented a stretched cluster solution. A stretched cluster setup will allow them to adhere to the stated availability SLA in the event of a large scale outages on the plant for their most important applications that do not offer in-application clustering/resiliency.

Benefits

Since my customer is running VMware solutions in all of its datacenters, VMware vSAN was the perfect fit. It allows the customer to lean on the already in-house VMware knowledge while being able to move towards less FTE for managing the storage backend. Implementing stretched clusters on multiple sites using storage arrays can be a daunting task. And although there are prerequisites, implementing VMware vSAN is implemented fairly easy, even if you opt for a stretched cluster configuration. This allowed for very short time from the moment of receiving hardware to a fully operational vSphere and vSAN cluster. Because the customer is in the process of renewing its IT infra for a number of sites, it really helps to tell the business we can deliver within weeks rather than months.

Using the VMware vSAN ready nodes allowed us to exceed the required storage capacity and performance requirements while being more cost efficient in comparison to traditional storage arrays. As management loves lowered costs, both capex and opex, HCI was the way to go. From a manageability point-of-view, it is a big plus that all VMware datacenters and (vSAN) clusters are managed from a centralized VMware vCenter UI. Another plus was the savings in rack units as those are scarce in some site-local datacenters.

(more…)

Read More

Distributed Storage Network Topology

This is a short write-up about why you should consider a certain network topology when adopting scale-out storage technologies in a multi-rack environment. Without going into too much detail, I want to accentuate the need to follow the scalable distributed storage model when it comes to designing your Ethernet storage network. To be honest, it is probably the other way around. The networking experts in this world introduced scalable network architectures, while maintaining consistent and predictable latency, for a long time now. The storage world is just catching up.

Today, we have the ability to create highly scalable distributed storage infrastructures, following Hyper-Converged Infrastructures (HCI) innovations. Because the storage layer is distributed across ESXi hosts, a lot of point-to-point Ethernet connections between ESXi hosts will be utilized for storage I/O’s. Typically, when a distributed storage solution (like VMware vSAN) is adopted, we tend to create a pretty basic layer-2 network. Preferably using 10GbE or more NIC’s, line-rate capable components in a non-blocking network architecture with enough ports to support our current hosts. But once we scale to an extensive number of ESXi hosts and racks, we face challenges on how to facilitate the required network interfaces to connect to our ESXi hosts and how to connect the multiple Top of Rack (ToR) switches to each other. That is where the so-called spine and leaf network architecture comes into play.

Spine-Leaf

Each leaf switch, in a spine-leaf network architecture, connects to every spine switch in the fabric. Using this topology, the connection between two ESXi hosts will always traverse the same number of network hops when the hosts are distributed across multiple racks. Such a network topology provides a predictable latency, thus consistent performance, even though you keep scaling out your virtual datacenter. It is the consistency in performance that makes the spine/leaf network architecture so suitable for distributed storage solutions.

An exemplary logical spine-leaf network architecture is shown in the following diagram:

(more…)

Read More