I often get questions on setting up virtual environments. Which design to adopt for SMB or (and) enterprise environment, which storage, which how much RAM, etc. Some businesses might grow at slower pace and some might don't grow at all. It's often important to start small and have a possibility to upgrade when a business grows. If you don't plan your architecture ahead, you might find yourself in a situation where you simply cannot upgrade due to a wrong architectural decision. Today's post is about StarWind Virtual SAN Getting Started document which discuss two different virtualization architectures.
Traditional shared storage architecture creates the usual “silos” of a compute and storage clusters. Hyper-converged architectures (starting with 2 nodes minimum) provides linear performance and capacity increase. As SMBs usually don't have a high budget for their IT, Starwind VirtualSAN is one of those very flexible solutions allowing you to start small, and grow up later. Starwind VirtualSAN can leverage 2-nodes cluster where even costly 10 Gb switch isn't necessary – 2 Nodes 10GbE Switch-Less Configs from Starwind.
Our readers know Starwind quite well as the solution has been here for quite a long time and it is a software-only solution which is quite easy to setup. (Note that they also have partnership with Dell for the hyper-converged appliances – hardware+StarWind).
Starwind Architecture.
The document I want to point today discusses two scenarios and it is destined to IT managers or administrators:
- Separate compute and storage nodes (storage node as usually shared storage, on separate box)
- Hyper-Converged architecture (storage and compute on the same box. 2 nodes minimum)
Starwind VirtualSAN uses local disks in each host and creates a mirror between those two nodes and uses a network connection for synchronization and heartbeat. The mirror “partition” (datastore) is mounted as iSCSI target and allows VMs to be located there. In case one of those nodes fails, the second node restarts the VMs which were running on the failed host.
Local Caching
Caching is great. Not only it allows to push more IOPs into your storage system but also, in the case of Starwind, RAM caching can preserve the SSD tier. Local disks in each node can leverage RAM for Level 1 cache or SSD for Level 2 as a high-speed write back cache.
The caching system has two levels:
- Level 1: RAM
- Level 2: SSD
StarWind uses RAM as a write buffer Level 1 cache to absorb all writes which are going to the datastore. SSD as Level 2 cache in this scenario is used less for writes so it lasts longer as we all knows that SSDs has a lifetime which is specified in DWPD (drive writes per day). Even if enterprise-class Flash can absorb hundreds of terabytes of writes, one day it after too many writes, it will finish by failing. So having fewer writes going to the flash layer the life expectation of the SSD gets longer.
Starwind also uses other space reduction technologies like in-line deduplication and compression. By using those techniques you're eliminating, even more, writes and uses less capacity in final. StarWind Virtual SAN implements in-line deduplication using 4 KB block. The in-line deduplication occurs in real time compared to post-process deduplication.
Inline deduplication looks for duplicate blocks of data as the data is ingested to the target device. This method of data deduplication requires less disk space than post-process deduplication because duplicate data is removed as it enters the system.
Post-process deduplication waits for data to land in full on disk before initiating the deduplication process. They increase lag time before deduplication is complete and, by extension, when replication completes as it's highly advantageous to replicate only deduplicated (small) data.
Starwind VirtualSAN needs Windows system to be installed onto, but in case you're using Hyper-V it can use directly the Windows OS to be installed onto, instead of being installed in a Windows VM, lowering even further the overhead caused via the virtualization layer.
In case of deployment on VMware it's transparent as the product is managed through its own console.
StarWind supports different hypervisors:
- VMware
- Microsoft
- KVM
- Xen
Get the PDF here – StarWind Virtual SAN Getting Started
We like the product for its flexibility and simplicity.
More posts about StarWind:
- 2 Nodes 10 GbE Switch-Less Configs from Starwind
- Free vs Paid – StarWind Virtual SAN
- StarWind Virtual SAN Getting Started – [This Post]
- StarWind Hyper-Converged Appliances (HCA) for ROBO and SMB
- VMware VSAN Ready Nodes in StarWind HyperConverged Appliance
- Starwind Storage Appliance Protects up to 4 disk failures
