Friday, 11 December 2015

VMware Virtual SAN Cloud (VSAN)


Why do you and how to cook it
In the first post we mentioned about CloudLITE virtual store VMware Virtual SAN (VSAN). Today, we focus on the technology and more will tell you what to consider when creating a VSAN for the project.

Why do you VSAN
Traditional architecture consists of three key components:
1.     Servers,
2.     Storage system (DSS),
3.     Storage Area Network that connects storage to servers through a block (FC, FCoE, ISCSI) or file protocols (NFS, SMB) using the appropriate switches.

To manage this economy need three different interface, three different competences and, in an amicable way, three different specialist.  The deployment of this architecture takes a long time, and rapid scaling is also quite a trivial task. If your project involves predictable and systematic scale, to add a new store has a week, and in the state there are experts who will be engaged in the design, the traditional architecture - your choice.  When you have a project (for example, public cloud) is growing leaps, adding a new repository with minimal automation capabilities it will take a lot of time.
This is where it comes in a converged architecture VSAN, which allows to combine computing functions in the server and storage functions.

VSAN as a converged solution
The convergent solution enables you to create the infrastructure of the typical units that combine several functions (e.g., computing, storage). Management of such infrastructure through a single interface, and scalability - by adding a block.  In the case of VSAN each unit - a server. Not all, of course, but more on that later. How the server does performs the functions of storage? VSAN collects from local drives virtual servers "external" storage available to all computing nodes of the cluster virtualization. In this program part of VSAN runs on the same servers as the compute nodes. Thus, on one and the same machine and arranged calculator (compute node), and a part of the storage system (storage node) - all in one vial.

How it works
Each server has 1 to 5 disk groups. In each group - at least one SSD-drive (a necessary condition for building VSAN) and from 1 to 7 HDD-drives.
SSD-drives in the disk group is made ​​up of a common pool of data caching. VSAN first reads data from the cache; if data is not in cache, VSAN is sent to the HDD-drives.  For each virtual machine you can configure your FTT (failures to tolerate). The default is 2, ie. E., all data are written once virtual machines on 2 different server cluster. If one server fails, we will have a synchronous replica on another, and all the I/O operation will go to the second copy.

What to look for when designing VSAN
Relative ease of deployment does not negate careful design architecture VSAN. Here are a few points on which we would like to dwell:
1.     Compatible hardware. Although VSAN and gives a certain freedom in the choice of "iron", it is wise to stay within the list to ensure compatibility with VMware VSAN equipment. So you do not have an educated bet select compatible controllers, adapters and so on. In the case of CloudLITE on set of technical and economic parameters, we chose Huawei FusionServer RH5885 V3. This model has on board more efficient PCIe flash card (in comparison with the already became a classic SSD-drives), which, by the way, saves "slots for drives" and create more disk groups. In the near future it will arrange unboxing. Stay tuned :).
2.     Network.  In the configuration of a VSAN VM can work in one place, and stored - in the other. It makes quite high demands on the network: you must be at least 10 GB network.
3.     Performance disk controllers. The disk controller must provide a buffer to surround a large queue. Load it is significant: the controller will give the data necessary not only to that server, but to the entire cluster. For example, the reduction of the disposed disk group to the new group you want to record large amounts of data in a short time. Recording speed just will depend on the performance of the controller.
4.     The volume of discs. In this situation no longer is better. Quite the contrary. Although currently available disks 4, 6 TB, VSAN is better to build from 1TB drives. Let's imagine an emergency situation when the cache we do not gets (replacing "a melted" disk group, backup or vosstanavleniju backup): 6 TB drives will recover up to 6 times longer than the 1 TB drives (if ottalkivatcya the ratio of the speed of reading to the volume Stored data - IOPS / GB). Here we are, of course, talking about the worst case, but the situation is not out of the realm of fantasy. And the desire to use VSAN volume wheels completely fell off, just imagine how many will recover the data on the hard disk 7 to 6 TB.
5.     The ratio of the volume of SSD to the hard disk. It will directly affect the final performance of the disk group: the higher capacity SSD (the more data is in the cache), the better the performance. In CloudLITE used for caching PCIe flash cards - they have less latency compared to the SSD. Incidentally, in the VSAN
6.     Supports disk groups consisting only of SSD. 6. The ratio of computing power disk space. When designing VSAN should be all carefully bed: calculate the ratio of processors, memory, and number of disk groups, and calculate how much of the increase computing power that it was cost effective. When running the decision can no longer be on the fly add disk space for VSAN (storage node), not adding a new server, and therefore processor and memory. Alternatively, when the server is used only as a storage (t. E. Compute node of the server is idle), it is possible, but uneconomical: it is actually a return to the traditional configuration and the refusal of the benefits of a converged solution.