Tag Archives: SDS

Virtual SAN 6.2 – Deduplication And Compression Deep Dive

Virtual SAN 6.2 – Deduplication And Compression deep dive


Virtual SAN 6.2 introduced several highly anticipated product features and in this blog, we’ll focus on some of the coolest ones: Dedupe & Compression. These features were requested by VMware customers and I am glad that we listened to the customer. When talking about Dedupe and Compression, one first needs to determine why an organization would want to use Dedupe & Compression and what these features actually do. One of the many reasons for using Dedupe and Compression is to lower TCO for customers. Customers benefit from space efficiency as the Virtual SAN cluster will not utilize as much storage as it would if it was not using Dedupe and Compression, hence saving dollars. It is also important to note that Dedupe and Compression are supported on All Flash Virtual SAN configurations only.

What are Dedupe and Compression?

The basics of deduplication can be seen in the figure below. What happens is that blocks of data stay in the cache tier while they are being accessed regularly, but once this trend stops, the deduplication engine checks to see if the block of data that is in the cache tier has already been stored on the capacity tier. Therefore only storing unique chunks of data.

Pic 1

So imagine if a customer has lots of VM’s sharing a datastore and these VM’s keep using the same block of data due to a certain file being written too often. Each time a duplicate copy of data is stored, space is wasted. These blocks of data should only be stored once to ensure data is stored efficiently. The Deduplication and Compression operation happens during the destage from the cache tier to the capacity tier.

In case you are wondering how all these blocks of data are tracked, hashing is used. Hashing is the process of creating a short fixed-length data string from a large block of data. The hash identifies the data chunk and is used in the deduplication process to determine if the chunk has been stored before or not.

Together with Deduplication, Compression is enabled at the cluster level. It will not be enabled using Storage Policy Based Management. The default block size for dedupe will be 4k. For each unique 4k block, compression will only be performed if the output block size will be smaller than the fixed compression block size. The goal is to get this 4k block compressed to a size of 2k as seen below. A compressed block will be allocated and tracked in translation maps.


Enabling Dedupe & Compression

To enable Dedupe and Compression is not rocket science by any means. Simply go to the Virtual SAN Cluster and enable it from the Edit Virtual SAN Settings screen. Once dedupe has been enabled, all hosts and disk groups in the cluster will participate in deduplication. In this discussion, dedupe domains will be the same as a disk group; therefore, all redundant copies of data in the disk group will be reduced to a single copy, however redundant copies across disk groups will not be deduped. So the space efficiency is limited to the disk group. This means that all components that are in a disk group will share one single copy if multiple components are using the same block.

Dedupe can be enabled and disabled on a live cluster, however there are some implications to doing this. Turning on dedupe means going through all disk groups in the cluster and evacuating all of the data and reformatting the disk group. After this, Virtual SAN will perform dedupe on the disk groups.

So it’s a rolling upgrade. It’s important to remember that dedup and compression are coupled, therefore, once you enable deduplication you are also enabling compression as seen below.


IO Intensity

Dedupe is an IO intensive operation. In a non-dedupe world, data is written from tier 1 to tier 2, however with dedupe, things remain the same for the first part. With this in mind, more operations are inherently performed during destaging. IO will go through an additional dedupe path. This will happen regardless of the data being dedupe friendly or not.

Read – When performing a read, extra reads need to be sent to the capacity SSD in order to find the logical addresses and therefore find the physical capacity (SSD) address

Write – During destage, extra writes are required to the Translation Map and to the Hash Map tables. The translation map and hash map tables are used to reduce overheads. So this needs to be accounted for that this overhead is incurred and that a 4k block size is being used.


Dedupe Ratio

When looking in the Summary screen for the Datastore, different capacities and dedupe ratios can be viewed. Logical capacity is a new term. It is the capacity footprint seen if Dedupe and Compression are not turned on. So in the example below, the Physical used is 10G and the dedupe ratio is 3.2. Therefore logical capacity is 32G



In summary Dedupe and Compression are fantastic features that are going to be very useful to customers that have all flash configurations, it will reduce their TCO, and from a technical stand point, it is very simple to implement. Customers do not really need to learn anything new so there is no ramp-up on the technology from a learning perspective.

(Courtesy of VMware vSphere Blog)

VMware Social Media Advocacy

NSX 6.2 inside Autolab 2.6 – Part 1

The Ravello Systems blueprint of Autolab 2.6 is a great point of start for any deployment vSphere based.

In this case, I’ll report my experience where I used Autolab 2.6 for NSX 6.2 deployment.


I will jump over the steps needed to deploy Autolab in Ravello, I’ll report it in another post. This first part will reach the point of deployment of NSX inside the Autolab’s vCenter.

We’ve to move away from standard in the moment when, to have 2 clusters, 3 hosts are nomore enough – 3 hosts is the standard of Autolab.

Luckily the guys at Labguides had a good intuition, so that they added at IPXE’s ESXi menu the “install fourth ESXi” line. So, my task was only to deploy a brand new application from blueprint, save one of the standard ESXi, delete that application and deploy this new ESXi in my current installation, modifying all the networks and hosts stuff.

So, installed the fourth as I did with previously ones, I planned to have 2 Clusters: Management and Prod.

The Management cluster will serve NSX Manager, the Prod is the resource cluster, so it will take care of the Edges.

I’ll put the Host1 and Host2 inside cluster “Management”, and Host3 to cluster “Prod”- before moving it I had to set it in Maintenance Mode


That’s the new host ready to be inserted in my Prod cluster:


Now proceeding with Add host:

We’ll answer “yes” to the security alert, and going straight forward with all the defaults:

Now we can assist at the import process.

In my case, I had to reboot the host to permit HA agent to be installed on it.

Since the Add Host wasn’t automated by Autolab as the previous ones, but manual, I had to add NIC1 in teaming to the first vSwitch, to create the other vSwitch and to recreate all the storage connections.


From the beginning, I had to modify, for Management network, NIC teaming, setting vmnic0 as active and vmnic1 as standby, overwriting switch failover order:


And then create the following portgroups: IPStore2



and vMotion:

We’re going to recreate the second switch, the one dedicated to VMs:

It’s time to reorder the storage connections too. We’ve to add, to the new host, the following:


I’ll jump this part since the purpose of the post is the NSX installation, and not recreate from scratch an host to be compliant with Autolab environment. Anyway, it’s simply a “copy&paste” process from the existing ones to the new one. Regarding iSCSI datastores, we’ll have to set up the HBA interfaces.

Time to deploy NSX. After download the OVA file we’ll use vCenter to deploy it on Management cluster. We’ll use the webclient and not C# client since the first one will give us more options (if we didn’t before, to deploy using webclient we need to download the client integration plug-in – link appears during deployment).

Using IE11 I wasn’t able to use the plugin, and neither Windows Authentication. Following several forum’s advices (https://communities.vmware.com/thread/515713?start=0&tstart=0 is one of them), I downloaded and used Chrome.

By the way, I don’t know if this is only my problem, but my vC server didn’t start automatically the vSphere Web Client service, although set as automatic.

It’s important to check the box accepting the extra configuration options.

Autolab sets its storages not larger than 58GB, that is less than NSX requires in its “thick” deploy. We can use “thin”, and iSCSI2 that is the larger DS available. Storage policy will be the default one – we’re not using vSAN neither VVol

At this point I encountered a boring error: “A connection error occurred. Verify that your computer can connect to vCenter server”:


Since my computer IS the vCenter, this didn’t make sense. Googling the error I discovered a related KB – https://kb.vmware.com/kb/2053229 – stating that it depended on a bad DNS configuration. This did’n make sense too, since I connected the webclinet using the DNS name, but I double checked pinging tha name, and I understood that my server was using IPv6 – solution was to disable IPv6 on my VC NIC:

It works now, and I’m able to continue.

The network to map is the “Servers” one, but it’s not important: we only have one physical network, so it doesn’t matter. In the last page we’ll be asked a password for default CLI user, a password for privileged and Network infos. We’ll assign the NSX the IP, providing an entry in DNS too, as nsx.lab.local. The same DC server acts as NTP server.

In our installation we won’t use IPv6 (ok… shame on me!)

And this is the summary and deployment:

I don’t choose to start it automatically because I could be forced to modify the resources assigned to nsx: my ESXi’s could offer 24GB of RAM and 12 CPUs – yes, I modified the default values of Autolab.

IMPORTANT: you must change the vNIC from VMXNET3 to E1000, according to Martijn Smit’s post: https://www.vmguru.com/2016/01/ravello-systems-vmware-nsx-6-2-management-service-stuck-in-starting/ . DO IT BEFORE STARTING THE VM – it won’t work changing it after, I had to redeploy. AND you should do it via SSH’ing the ESXi, not deleting and recreating from GUI because if so, the VM will rename it in eth1.

Actually, the nsx doesn’t start:

I must reduce assigned RAM from 16GB to 12GB and CPU from 4 to 3, otherwise it won’t start.

After the first boot, although, if you shut down, you’ll be allowed to use 16GB and 4CPU, as adviced.

And that’s the result of our efforts:


Logging in, this is the main window:


And the summary page:


This is the end of this first part. In the next one we’ll configure the NSX manager and we’ll deploy our Edges and VXlans.

Thank you for following!


New All-Flash Array for Tintri

A new post about Tintri, again. But this is a news that I can’t ignore: its all-flash array line T5000 today has a new born. A little brother, T5040, up to 18TB and 1,500 VMs in a 2U box.
More over, a new version of Tintri OS 4.1 supporting Xenserver hypervisor, among other new features.
Last, “Tintri Analytics”: a predictive system at VM and application level.


This new all-flash array at a street price of 125k$ opens this technology to more companies with lower budgets, and aimed to serve all the applications requiring heavy workloads like large persistent databases or persistent VDIs.
The raw capacity is 5,76TB made by 24x240GB SSDs driven by a dual-controller.
At the moment Tintri can offer 3 All-Flash array models (T5000 series) and 3 Hybrid models (T800 models).

This new born device will be managed by the new OS 4.1, announced on December, in a webinar, from his co-founder and CTO Kieran Harty. The most important feature is the support of another hypervisor: Xenserver, but even the File-level Restore, Shared Snapshot Deletion, Openstack/Cinder and more.


Tintri Analytics go deep inside customer’s VMs and applications to shape the future needs in terms of space and performances – it will integrate the already complete Analytics. And you won’t run out of space since the analytics will predict you when and what to buy.


Another like-to-be success for the Californian Company.

Tintri: the VM-Aware Storage

We’re used to think at storage like some monolithic entities, black, inaccessible (only support can), and managed by strong specialists.
The Tintri concept is somehow different.

/content/dam/ready/partners/ti/tintri/tintri-vmstore/Tintri_VM Image.png Let’s start saying that this is a virtual-only storage: don’t even think at it for physical purposes, it will lose all its charm.
I’ll talk about the hybrid solution, T880 is the top device among Tintri’s hybrids.

 What’s different from others: the magic inside the (white – posh!) box. Actually, that’s simply a mix of SAS and SSD disks, so? So, the software is the difference.
Some of you could say “Well, so why have a complete box instead of simply a software”. Yes, it makes sense. The reason why they decided to join HW and SW is “compliance”. Offering their own mix of HW with their SW let them say exactly which the performances will be, that there are no conflicts inside and, last but not least, a single point of support.
Let’s have a look at the benefits.
I think that the main benefit is performance. Anyone used to traditional storage will be amazed. Latencies and IOPS are something that traditional storage can’t afford.
Setup – to set a box up in a rack will take no more than 30 minutes, its console configuration 5, its remote configuration 10. In less than 1 hour you’ll have your new datastore up&running.
Dedup and compression – somehow variable between 1,5 and 2 in practical world, and it is performed in-line with no loss of performances.
QoS – one of the reasons for the title. Tintri allows QoS per single VM, it means that if you need just a VM inside a group to be fast, is enough to work directly on it, should you decide that speed is no more necessary, again enough move the QoS crossbar. This also means having VIP customer and new marketing tools, if you’re a CSP like the company I work for.


TGC, a.k.a. Tintri Global Centre, an orchestrator of all the features of all the VMstore installed. It’s not only a single panel to control the storage, but an instrument for better global analytics, an overview on all the VMs and global performances of the whole system.
Storage management is unbelievably easier, all the time needed to manage LUNs and inflexible blocks can be allocated elsewhere.
Footprint – a T880 fills 4U, it’s power consumption is about like an hairdryer, need for cooling more or less as a couple of blades.
Now the unpopular items. If you have less than 80% virtualized, it’s not the best choice. If your budget is quite limited, you should look at traditional, even if slower, products. If you need performances, don’t have budget limits and your environment is pretty stable, look at all-flash arrays.

Finally, I’d like to spend some words for the quality of support. During our P.O.C. (which I strongly advice to ask for) we had an issue with a disk, of course the system wasn’t new. I was impressed by the time elapsed from ticket being opened, to call and web-ex received, and solution.

All in a flash, as the name “Tintri” in old Irish stands for. Good job guys, and “keep it simple”!

Hypervisor convergence: Nutanix paradigm

This morning I had the pleasure to attend a general demo from Alberto Filisetti about what Nutanix offers in the hyperconvergence market.
Nutanix based its datacenter on “building blocks”, each of them includes simply some servers and some storage, both standard, all managed by a “magic” software.
Their IT team had the idea to export this model on the enterprise virtual market. This idea was so successful that they were able to gain about 400 million dollar in 4 round fundings, and they’re going to be public in short time.
All this happened in USA. Nutanix landed in Europe in 2012, and suddenly they were successful. The VMware VSAN concept was in an embrional state inside Nutanix almost 5 years before VMware (note that EMC was the main shareholder)
Today Nutanix holds more than 50% of hyperconverged market, inside Gartner magic quadrand its position is the leaders quadrant – high vision and high execute.
The Nutanix “block” includes very standard computing hardware (Supermicro, Lenovo, Dell), managed by its real added value: the managing, orchestrator software, reachable even by API, and on it Nutanix assures reliability. Maybe the definition “orchestrator” is not completely suitable. Why uses standard hardware: for predictability of performances and to assure support by well-known vendors.
Which was the reason for this choise: latency is high when data reside on non-local storage. Implementing this solution, all the reads and writes happen locally.
The base unit so, it’s called a 2-unit “Block”, containing 2 or 4 servers, or “nodes”. In this way they’re able to become up&running in just 20 minutes after mounting in the rack.
As written above, inside a block you’ll find not only computational units, but even capacitivity power: disks, traditional and SSD aggregate only in one file system, connected by a 10Gbps ToR switch.
On every node runs a Nutanix Controller VM (CVM) that is the real brain of the whole system.  It resides on SSD and hosts the Nutanix software, serving all of the I/O operations for the hypervisor and all VMs running on that host. It’s hypervisor agnostic, his level is higher.
Among all the hypervisors, KVM is one of the less used because of its hard manageablity. Nutanix has a solution in this case too. They developed a kind of hypervisor based on KVM, Acropolis, that simplify its management. Just a note: Acropolis is just an option, it isn’t mandatory for the system.
You’ll find a very good and updated resource for all Nutanix structure at Nutanix Bible.
All the nodes are independent, from 3 to the infinite and could be added one at a time. Every node doesn’t add only computing (CPU and RAM) but also storage and IO since every of them brings a controller. Compared to an external storage so, these nodes have the advantage to grow in width, where the external ones have the same initial controllers as a funnel.
Geographical and multi direction DR is also included, RPO minimum 1h, or BC, but in this case latency can’t be higher than 5ms, or using a VMware streched cluster.
The main intention of Nutanix is to make the datacenter invisibile: before storage invisible and, at last, the whole virtualization and cloud invisible too.
The first step, hiding storage, is reached thanks to a fabric (Lenovo) distributing the file system and protecting it. at the beginning it was mainly used in VDI solution because of low latencies, today VDI represents only 30% of business, even thanks to applications certifications (just a.e.SAP, Splunk, MS Exchange).
Finally, virtualization and cloud invisibility: with Acropolis as a higher layer over hypervisors, and Prism, that manages all the hypervisors controllers, and even per-VM management, but in this case only for the servers running Acropolis. the wonder of this application is the one-click operation to add any eterogeneous hypervisor!
The same platform is issued in a community edition, of course with no support.
Now, to resume what’s inside the block: independent servers carrying and conected by 2/4 10Gb ports,redundancy ones and management ones. Adding a node means adding resources, computing and storage (3-direction growth). This growth could happen also with different hardware, in order to protect older investments.
Every software upgrade (for bugs solving, for customer requests and suggestions, and because of greater performances (usually from 20 to 80% more) is performed by one click, no interruptions, no vMotions, because upgrades happen in a CVM at a time using redundanced automation. Or manually, uploading an image that is processed by VMware automation.
Let’s have a look to the data flow, a. e. in a 3-nodes system: ESXi writes on traditional local disks and replicates to the neighboors 2 or 3 times according to the set policy, with a very low latency of nanoseconds. If and when a disk fails, metadata rbuild the data with no need of management, no need to wait for rebuild.
Reads take place on SSD, in case of vMotion data are relocalized on the new server. The data locality allows IOPS of 15-20k.
Conclusions, why should we choose Nutanix:
  1. dimensions, that means low power, low space needed;
  2. time to install;
  3. fast and easy to upgrade;
  4.  upgd veloce,
  5. data protection at 2 or 3 levels, and in case of DR, in a geographic way;
  6. high predicted performances;
  7. hypervisor agnostic, managed by a GUI;
  8. an high specialized and professional support, covering not only the software, but even the base hardware.
Some considerations: should we need more storage and nomore computing, they’ll provide a so called “passive node”: very low CPUs and RAM, with high capacity low performances storage, attached by network to the system
Other hardware could coexist, in his case this hardware wn’t have all the Nutanix software optimization.
Finally, I would underline once more that a cluster can be made with different hypervisors: one KVM, one ESXi, one Hyper-V, all controlled by Prism.
I can’t wait to have a test unit to verify all this!