Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

What You Can (and Cannot) Change in a vSAN ReadyNode™ (52084)

Last Updated: 12/15/2023Categories: InformationalTotal Views: 45642Language:
Chinese (Simplified)JapaneseEnglish

43 like this article

Subscribe to get an email
newsletter with new updates

43 people found this helpful Please provide article feedback:

Purpose

Overview

VMware vSAN has taken the Hyper-Converged Infrastructure (HCI) market by storm. More than 30,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 VMware Compatibility Guide (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 ReadyNodeTM is optimally configured for vSAN with the required amount of CPU, memory, network, I/O controllers, and storage (SSDs, HDDs, or flash devices). Each ReadyNodeTM 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 ReadyNodeTM build of materials (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 ReadyNodeTM BOM that you can change and there are things you cannot.

Impact / Risks

[email-masked]

Resolution

To provide guidelines for what can be changed in a ReadyNodeTM, we are taking a two-phased approach.

Provide guidance to customers, partners, and field on what we allow to modify within a vSAN ReadyNodeTM BOM today by means of this blog which will be linked to the official vSAN VMware Compatibility Guide

Subsequently, build a tool that enables customers, partners, and field to select changed configuration automatically and create in runtime a vSAN ReadyNodeTM BOM from a supported list of components on the vSAN VCG.

In this blog, I will outline the first approach “Guidance on which the tool is going to be built upon”.

To begin with, below is an example for vSAN ReadyNodeTM BOM in vSAN VCG:

Sample vSAN ReadyNodeTM BOM

If we look at components in vSAN ReadyNodeTM BOM, most of them are allowed to be changed based on some guidelines and the below table describes those guidelines.

Memory: Adding more memory than what is listed is supported. Please maintain a balanced memory population configuration where possible.

Allowable Changes in vSAN ReadyNodeTM BOM

For your reference, caching tier guidelines can be read here, and boot device KB available here.

As you can see, vSAN ReadyNodeTM 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 ReadyNodeTM server platform is built on a “standard x86 server platform” that needs to be ESXi (vSphere) certified.  This is a pre-requisite for ReadyNodeTM listing.

Expanding on the above thoughts, I would like to highlight the flexibility we have on storage sub-systems of vSAN ReadyNodeTM  BOM as shown below:

Allowable Changes in Storage Sub-Systems of vSAN ReadyNodeTM BOM

Note: Performance characteristics of the ReadyNodeTM may vary if you change any component.

Lastly, I have put some FAQs which will help address few additional areas on that.

vSAN ReadyNodeTM  Storage Component FAQ:

Q: - Can I choose a different make and model of cache and capacity tier drive vSAN ReadyNodeTM BOM?

Please refer to the table above for guidelines.

Q: - Can I replace HDD with SSD in the capacity tier in vSAN ReadyNodeTM ?

No. vSAN ReadyNodeTM 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 ReadyNodeTM ?

IO controller is one of the key components in vSAN ReadyNodeTM 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 a lower vSAN ReadyNodeTM profile to a 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 ReadyNodeTM.

vSAN ReadyNodeTM configurator is a lightweight tool with minimum inputs. BOM customization will be a part of vSAN sizer.

Q: - Do we need Boot Device Certification?

We do not need to certify the boot device for vSAN.  Please follow the guidelines laid out in this KB article.

Q: - Do we need to certify the NIC in a ReadyNodeTM BOM?

There is no separate NIC certification required for vSAN.  NIC cards qualified under IOVP certification are used for vSAN ReadyNodeTM BOM.

Q: - Do we use Expander or add a 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 as increased performance for the ReadyNodeTM .

Additionally, some systems are built with an onboard expander and you may not need to put additional expander but you can add a controller in such a scenario for better performance.

We allow expander support only on ReadyNodeTM. If you are building your own (BYO) vSAN, we do not support the expander.

Q: - Can we use M.2 devices for vSAN?

We see this device getting more attention as a 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 the 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 the following changes:

You can put more memory than listed in the ReadyNodeTM.

You can choose different DIMM size (16GB, 32 GB, etc...) to meet your memory requirement(Please do not mix DIMM sizes in the same platform).

You can choose the same or higher memory frequency than listed as part of the BOM.

Please work with your OEM vendor for an optimal configuration.

Please note that some applications are memory intensive and may require the exact specifications to be met. In such cases, the 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 ReadyNodeTM listing for belonging to the profile.

Q:- Can we swap my 512n HDD device with 512e or vice versa in a ReadyNodeTM?

Yes, you can. If the ReadyNodeTM 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.

Q:- What is vSAN Secure-wipe capable ReadyNodeTM ?

vSAN SecureWipe capable ReadyNodeTM is a ReadyNodeTM whose components (IO Controllers, Expanders, SAS/SATA/NVMe SSD Drives) are certified for Disk Sanitization.

Q:- Do we support the BYO scenario for Secure-wipe?

No, vSAN Secure-Wipe capable feature is not supported for the BYO scenario.

Q. What is vSAN support for PMem?

Please refer to KB vSphere/vSAN Support for Intel's Optane Persistent Memory (Pmem) (67645) for vSAN support of PMem in Memory Mode.

Q:- Is 4S Sapphire Rapids supported in OSA?

Sapphire Rapids 4S servers are not supported for BYO at this time.

For any questions on vSAN hardware, please reach out to vSAN Hardware PM at [email-masked].
To learn more about vSAN, visit VMware vSAN

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
Download and Install VMware Fusion (2014097)

Results 1-2 of 2

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vSAN

Related Versions:

Take Our Survey

Support Assistant