One of the biggest obstacles to deploying VDI is creating a storage architecture. First, you must determine whether the virtual desktop uses direct connection to storage or shared storage.
It is very difficult to deploy and manage storage for VDI. Because VDI has high requirements on disk I/O. Although you can reduce the I/O overhead by providing enough memory for each virtual desktop (this can reduce the Windows operating system's Pagefile. sys File dependency), but cannot reduce the virtual desktop I/O to too little.
This is especially true during busy hours. For example, opening a VM in the morning may trigger an I/O storm. Although the problem can be avoided by keeping the virtual machine in the starting state, the VM startup storm occurs once a day, so it is necessary to solve this problem,
But there is another type of I/O storm. For example, a user may cause a large number of I/O peaks when starting an application. Your VDI storage infrastructure needs to be highly efficient enough to effectively handle one or more I/O storms every day.
When selecting VDI storage, you have two major options: Local direct connection to storage or shared storage. The following are the differences between the two options.
Local direct connection to storage
The simplest VDI storage option with the lowest price and configuration is to directly connect to the storage (DAS ). The main advantage of using DAS is that hypervisor can communicate directly with storage. This means that the network bandwidth limit or delay will not affect the communication with the storage.
Another advantage is that when using DAS, other hosts do not affect disk I/O. In a shared storage environment, all host servers must share disk resources. If the host is carrying heavy workloads, the task of the host may potentially compete for disk I/O resources of other hosts. However, this problem does not exist when each host has its own storage.
Although DAS has these advantages, it is not always reliable. DAS does not provide a Failover mechanism. If the host server goes down, all the storage devices connected to the host cannot be accessed. For this reason, many VDI platforms on the market do not even support DAS.
Whether you can create a host server resource pool and configure local storage for each host depends on the platform you are using. If a server in the resource pool fails, the connection proxy can redirect the session to another host. However, this method does not support personal virtual desktops. This failover policy is effective only when each host maintains a set of identical virtual machines.
Shared storage
Shared storage is preferred for virtual desktops. In this architecture, each VM is connected to the central storage pool, and all the hard disk files of the virtual desktop are located in the central storage pool. All Hosts are connected to the central storage pool, so they can respond to host server faults. If a host fails, its workload can be migrated to another host in the cluster.
Although shared storage is a better architecture for most deployment methods (with exceptions), shared storage also has defects. First, the cost of deploying shared storage is high. If you are using SAN, the cost will be higher.
Even if you are using an iSCSI network to connect to the storage, the cost may be a problem, because the underlying storage hardware must have a fault tolerance function, so that the disk will not have a single point of failure. Similarly, the storage hardware must meet the I/O requirements of the entire VDI environment. This means that a large number of hard disks or even solid state disks will be used when deploying VDI.