As you remember from my previous article, I have been interested in testing the performance levels of two virtual SAN configurations from different vendors. I got my results, but this experience prompted me to continue. Here, I’ve chosen to try another configuration for performance comparison, albeit with only a slightly different list of participants. Since no one needs an introduction from VMware vSAN, I’d like to say a few words about its companion – Ceph. Basically, it is an object-based software storage platform. I know that doesn’t sound epic at all, but Ceph is also completely fault-tolerant, uses off-the-shelf hardware, and is extremely scalable. The most interesting thing is that some Ceph releases apply erasure-coded data pools so that it would be a less resource-hungry solution than traditional replicated pools. In practice, that means the following: when you store an object in a Ceph storage cluster, the algorithm divides this object into data and coding chunks, stored in different OSDs (that way, the system could lose an OSD without actually losing the data). Now, that’s when I thought that theoretically, Ceph could make a good virtualization platform (proper configuration, of course), so I had to see whether it would be justified in terms of time and resources spent. Naturally, I hardly could have done it without a credible comparison, hence VMware vSAN (with a similar configuration, of course, otherwise it would make no sense). So, shall we?

As time goes on, fewer and fewer people tend to rely on cumbersome SANs. It doesn’t mean that they have become obsolete; it’s just that many small and medium-sized enterprises (SMEs) simply don’t require all the broad specter of services and resources that a storage area network system can offer. That makes perfect sense: if you can farewell with a less complicated and resource-hungry configuration – why pay more? Virtual SANs have become the newfound Holy Grail of small infrastructures. And why not? They offer software-defined storage solutions that support HCI systems and leave external shared storage out of the picture. An introduction of virtual SAN solutions to the market has changed a lot, opening the way for simple storage configurations that can provide maximum possible performance with minimum possible resources required, respectively. Since the market has emerged, it didn’t take long to recognize the leaders, which are StarWind Virtual SAN (VSAN) and VMware virtual SAN (vSAN). All else being equal, neither is considered better or worse. However, each IT environment is, in a way, unique. I don’t need to tell you about the multitude of configurations out there. So, with the diversity of HCI systems and hardware requirements in mind, this begets a question: are these solutions really giving away an equal performance, all things considered?

  Before starting to talk about new features and improvements, I suggest we take a little trip down memory lane.

Previously, I shared my experience with certain problems with NIC Load Balancing on ESXi host and how they can be solved with ESXCLI. Some of my colleagues have been asking me what the difference between several types of load balancing and which one is better for use is. So, now I’m sharing my thoughts about concepts of network environment load balancing on the infrastructure level.

As any other admin, you know that the VMs eventually start to suffer from disruptions, performance problems, or simply stop responding. That is a fact of life, unfortunately. Chances are, as a virtualization engineer, you’ve probably already met these problems at least once. And since the virtualized environment is quite a complicated system, there can be too many different reasons or factors that impact poor VM performance. Trying to find out what is wrong can take a lot of your time.

Recently at my job, I was faced with a task to develop a file server explicitly suited for the requirements of the company. Needless to say, any configuration of a kind depends on what the infrastructure needs. So, drawing from my personal experience and numerous materials on the web, I came up with the combination FreeBSD+SAMBA+AD as the most appropriate. This combination is a harmonic addition to the existing network configuration since and enables admins with a broad range of possibilities for access control in Windows-based infrastructures. Also, Samba allows you to apply its network resources for Windows client OSs without any additional configurations required. Moreover, FreeBSD is well-documented.

NIC or ports teaming in ESXi allows the hypervisor to share traffic among the physical and virtual networks, thereby increasing the bandwidth of vSphere virtual switch or a group of ports. It allows to load balance network traffic in the event of a hardware or network failure. Configuring the load balancing policy enables you to decide how exactly a standard switch is going to load balance the traffic between the physical NICs. The team load balancing policy specifies how the virtual switch will load balance the traffic between the groups of ports. Nevertheless, there’s, of course, a catch. In case the established load balancing policy doesn’t match the networking equipment your host is connected to, there’ll be problems connecting your recently configured ESXi. The team load balancing policy specifies how the virtual switch will load balance the traffic between the groups of ports. Nevertheless, there’s, of course, a catch. In case the established load balancing policy doesn’t match the networking equipment your host is connected to, there’ll be problems connecting your recently configured ESXi. This is precisely when the ability to configure the load balancing policy through the ESXi console has a moment to shine. It’s even more useful if a host is at a remote location. The point is, a lot of people think that not being able to ping the host is the end of the story. In most cases, this is quite possible, but if you still can console into the ESXi host through out-of-band remote management (IDRAC or else), all is not lost.

Every admin knows a few tricks to find a short way when testing your VMs. Some of them are neat, and some aren’t, such as snapshots. Disk Mode in VMware ESXI allows you to replace this technology with a safe alternative!

There are always several reasons to move on from your existing infrastructure. Some admins are pursuing recent versions of familiar products. Some, on the other hand, just want to get rid of the bugs they already learned to live with but would rather not. Others are attracted by promises to increase the performance of their environment. Finally, everybody wishes to go with the times and use the latest software. Whatever the reason, we all eventually come in terms with the necessity to upgrade the infrastructure to the most recent version.