dell-readynode-logoI’ve been waiting and looking forward to this moment for some time now; the Dell FX2 server platform is now officially listed in the VMware Compatibility Guide. Customers are now able easily to choose from a list of available ready nodes one of the most powerful converge server platforms currently available today.

I have used the FX2 server platform for a number Virtual SAN projects and use cases ranging from VDI, Management Cluster, DMZ, Business Critical Application (Microsoft Exchange, Microsoft SQL, Oracle), and multi-site Stretched Cluster deployments and the platform has delivered the goods every single time.

The Dell’s FX2 server platform is an ideal solutions for VMware’s hyper-converged infrastructure (HCI) with VMware Virtual SAN. The FX2 value proposition complements with the principal values of Virtual SAN around simplicity, ease of management, scalability, and cost effectiveness.

The Dell FX2 Virtual SAN Ready Nodes are now available in the following models and configurations:


Read Full Article →


One of the primary goals of the Storage and Availability team at VMware is to validate business critical application running on Virtual SAN continuously. It is of the utmost importance for us to deliver the necessary information to customers, so they feel confident about the storage platform they are considering or plan to use to run their business critical applications. At the same time, we want to provide the necessary data points for them to understand how the platform will deliver the capacity, performance, and availability services that are demanded by their applications.

Below is a sample of the information that can be found on a performance study performed on SAP IQ, a mission critical application running on VMware Virtual SAN.

SAP IQ is an intuitive, cost-effective, and highly optimized RDBMS that is fast and efficient for extreme-scale data warehousing and big data analytics. SAP IQ is a distributed application with multiplex nodes, which may have different roles with different capabilities. This is unlike other database cluster architectures, which usually follow either a shared-everything or shared-nothing architecture. The multiplex server configuration can be described as an “asymmetrical cluster” One node is designated as the coordinator; the remaining nodes are query nodes and may be either Readers or Writers. In addition to its role of handling transaction management, the coordinator can also serve as a Reader or Writer in the multiplex.

Distributed Query Processing uses the available memory and CPU resources of all available nodes to process queries. Performance is therefore determined by the overall workload in the cluster as a whole at any given time. In a single run of a long-running query, the work distribution may change over the course of a query execution as the load balance changes across worker nodes.
The node at which a query is submitted becomes the leader node for that query, and the remaining nodes assume the worker role. Any node in the cluster can be the leader node; similarly, a worker node is any node that is capable of accepting distributed query processing work. Work is performed by threads running on both the leader and worker nodes, and intermediate results are transmitted between nodes by one of two mechanisms: through a shared disk space, or over an inter-node network. Read Full Article →

vsan-robo-witSince my previous post about VMware Virtual SAN ROBO Edition, I received some requests for a recorded demonstration of the configuration procedure for the Virtual SAN cluster for ROBO. Well, it happens to be a very simple process so I able to put a couple of systems together and record a demo.

There is one question in particular that I have been asked a few times that has to do with the configuration of the Fault Domains and the wizard that is utilized that I want to briefly discussed. The question I have been asked is:

Why is it that when configuring a Virtual SAN Cluster for ROBO, the wizard says – Configure VSAN Stretched Cluster when in reality this is not a stretched cluster configuration?

First of all, great observation and I think it is an observation that deserves an explanation. The reality is that from a configuration semantics perspective, the configuration procedure for creating a Virtual SAN Stretched Cluster and a Virtual SAN Cluster for ROBO are the same. Both capabilities are built upon Virtual SAN’s Fault Domain feature, which is a way in which the system qualifies logical failures zones.


Read Full Article →

Since the initial release of Virtual SAN, customers have been asking for a version and licensing package of Virtual SAN conducive to the demands of smaller environments such as Remote Office / Branch Office (ROBO). Customers want all of the benefits provided around manageability, performance, and availability in a traditional Virtual SAN cluster implementation without the minimum requirement of three nodes. Today, Virtual SAN 6.1 introduces Virtual SAN for ROBO, a supported solution specifically designed and packaged to satisfy the demands of smaller ROBO environments and suitable use cases.

Virtual SAN for ROBO is built on the foundation of Fault Domains, where in this case the required failure zonesvsan-robo-wit are based on three nodes (two physical nodes and witness virtual appliance). The witness virtual appliance is uniquely designed with the sole purpose of providing cluster quorum services during failure events and to store witness objects and cluster metadata information.

The use of the witness virtual appliance eliminates the requirement of a third physical node. This is what ROBO customers were looking for as lower costs is one of cornerstones for ROBO use cases.

A couple of facts about the Virtual SAN Witness Virtual Appliance:

  • One witness virtual appliance is required per Virtual SAN ROBO cluster.
  • The appliance does not contribute compute nor storage resources to the cluster and it is not able to host virtual machines.
  • The witness virtual appliance is exclusively available and supported ONLY for Virtual SAN Stretched Clusters and Virtual SAN ROBO edition.
  • Much like the Virtual SAN Stretched Cluster, the Virtual SAN ROBO edition is only capable of supporting a single failure within the cluster (FTT=1) due to the support of only three fault domains.

Read Full Article →

vsan-sc-demoSince the announcement of the Virtual SAN Stretched Cluster feature last week at VMworld and the sessions I presented on the topic, the customer responses have been overwhelmingly positive with lots of  excellent questions.

Since then, I have received a number of requests by several folks asking to provide public access to the configuration and complete site failure demonstration I utilized during the VMworld sessions. There is one thing I would l like to point out about the demonstrations. The demonstration in the “Building Stretched Clusters with Virtual SAN” session that I presented with Duncan Epping was a recorded, but the other demonstration from the “Building Geographically Dispersed SQL Clusters with Virtual SAN” session was live!. Read Full Article →