Overview
vSAN has taken the Hyper-Converged Infrastructure (HCI) market by storm and more than 7,000 customers have now adopted vSAN with thousands of deployments, confirming its position as the leading product in hyper-converged infrastructure (HCI).
One of the consumption models of vSAN software is ReadyNodes and today we have more than 200 ReadyNodes listed in vSAN VCG from OEM partners across the globe.
So what are vSAN ReadyNodes?
vSAN ReadyNodes are x86 servers, available from all the leading server vendors, that have been pre-configured, tested and certified for VMware Hyper-Converged Infrastructure Software. Each ReadyNode is optimally configured for vSAN with the required amount of CPU, memory, network, I/O controllers and storage (SSDs, HDDs or flash devices). Each ReadyNode listed in vSAN VCG has an SKU. You can enter that SKU into OEM partners’ system configurator and it will generate a BOM that is “flexible”.
We often get asked by our field, partners and customers that “Can a ReadyNode BOM be changed?” e.g. can we use another capacity tier device or use a better processor than listed in the BOM. The short answer is “Yes” – there are things in a vSAN ReadyNode BOM that you can change and there are things you cannot.
To provide guidelines for what can be changed in a ReadyNode, we are taking a two-phased approach.
- Provide guidance to customers, partners and field on what we allow to modify within a vSAN ReadyNode BOM today by means of this blog which will be linked to the official vSAN VMware Compatibility Guide
- Subsequently, build a tool which enables customers, partners and field to select changed configuration automatically and create in runtime a vSAN ReadyNode BOM from supported list of components on the vSAN VCG.
In this blog, I will outline first approach “Guidance on which the tool is going to be built upon”.
To begin with below is an example for vSAN ReadyNode BOM in vSAN VCG:
Sample vSAN ReadyNode BOM
If we look at components in vSAN ReadyNode BOM, most of them are allowed to be changed based on some guidelines and below table describes those guidelines.
Allowable Changes in vSAN ReadyNode BOM
For your reference, caching tier guidelines can be read here and boot device KB available here.
As you can see, vSAN ReadyNode BOM is flexible enough to accommodate the change as long as the component is listed on the vSAN VCG or vSphere VCG, as applicable.
Before I discuss further on storage sub-systems items, I would like to highlight that each ReadyNode server platform is built on “standard x86 server platform” that needs to be ESXi (vSphere) certified. This is a pre-requisite for ReadyNode listing.
Expanding on above thoughts, I would like to highlight the flexibility we have on storage sub-systems of vSAN ReadyNode BOM as shown below:
Allowable Changes in Storage Sub-Systems of vSAN ReadyNode BOM
Note: Performance characteristics of the ReadyNode may vary if you change any component.
Lastly, I have put some FAQs which will help address few additional areas on that.
vSAN ReadyNode Storage Component FAQ:
Q: – Can I choose different make and model of cache and capacity tier drive vSAN ReadyNode BOM?
Yes. You can select new drive of same or higher performance and endurance class. Drives need to be certified and listed in vSAN VCG and with OEM. You can find the endurance and performance class requirement for caching and capacity disks here.
Q: – Can I replace HDD with SSD in the capacity tier in vSAN ReadyNode?
No. vSAN ReadyNode profile is meant for AF or HY. You cannot mix and match.
Q: – Why can’t I use a different IO controller than listed in ReadyNode?
IO controller is one of the key components in vSAN ReadyNode profile performance guidelines. We run an extensive performance test on IO controller before it is certified in a system. I/O controller pretty much defines how much I/O can be pushed down to the underlying storage subsystem and a substandard controller that is not certified for vSAN can result in performance and even availability issues.
Q: – Can I move from lower vSAN ReadyNode profile to higher by changing the configuration?
Yes, you are allowed to move to a higher configuration based on your IOPS and capacity needs. This guidance is primarily meant for helping to create flexibility within a vSAN ReadyNode.
Q: – We understand that vSAN ReadyNode BOM is modifiable. But how do I go about modifying it?
We expect a user to look into vSAN VCG and find out the equivalent components for now. We are working on a tool “vSAN ReadyNode Configurator” (Phase 2) which will allow selecting equivalent components and generate BOM with the changes.
Q: – When will vSAN ReadyNode Configurator be ready with these changes?
We are planning to release vSAN ReadyNode Configurator for BOM selection in the near future. Please reach out to vSAN PM [email protected] for timelines.
Q: – Do we need Boot Device Certification?
We do not need to certify boot device specific to vSAN. Please follow the guidelines laid out in this KB article.
Q: – Do we need to certify the NIC in a ReadyNode BOM?
There is no separate NIC certification required for vSAN. NIC card qualified under IOVP certification are used for vSAN ReadyNode BOM.
Q: – Do we use Expander or add new Controller for more drives.
It depends. If the workload needs storage dense configuration, we recommend using an expander. When the workload demands more performance or capacity beyond the number of drives tested for the expander, adding certified controllers and configuring disk groups behind the added controllers may help.
e.g. a P440 controller tested and certified up to 16 drives. If you need to configure up to 24 drives, you can put 16 drives beyond an expander and the additional 8 (1 + 7) drives (by adding a new disk group) beyond a new certified controller. It will provide additional storage as well increased performance for the ReadyNode.
Additionally, some systems are built with onboard expander and you may not need to put additional expander but you can add a controller in such scenario for better performance.
We allow expander support only on ReadyNode. If you are building your own (BYO) vSAN, we do not support expander.
Q: – Can we use M.2 devices for vSAN?
We see this device getting more attention as mirrored boot device configuration in a vSAN environment. For now, our guidance is to use mirrored M.2 as boot device connected to a controller in RAID 1 mode (which is different from the primary controller used for the vSAN datastore). This allows for high availability and self-contained storage for logs, traces, core dumps etc in addition to using it as a boot device. Putting the mirrored M.2s behind a controller separate from the controller behind which the vSAN datastore is a best practice that we highly recommend.
In future, we will look into this form factor for other areas.
Q:- What can be changed when we say “Adding more memory is allowed”?
You are allowed to do following changes:
- You can put more memory than listed in the ReadyNode
- You can choose different DIMM size (16GB, 32 GB etc…) to meet your memory requirement
- You can choose different memory frequency than listed as part of the BOM
Please note that some applications are memory intensive and may require exact specification to be met. In such cases, application owner needs to identify the exact requirement. Our general guidance is you are allowed to modify the above points and you will not require any additional certification or new ReadyNode listing for belonging to the profile.
Q:- Can a swap my 512n HDD device with 512e or vice versa in a ReadyNode?
Yes, you can. If the ReadyNode is listed 512e and swapped with 512n, you are expected to have better performance based on your workload. However, you may experience, especially with small block size workload, performance degradation when 512n is swapped with 512e HDD drives.
For any questions on vSAN hardware, please reach out to vSAN Hardware PM [email protected].
To learn more about vSAN, visit VMware vSAN
