There are several general questions and answers.

ONTAP Select Deploy is the utility used to create ONTAP Select clusters. Currently ONTAP Select Deploy is the only method available for creating a production cluster. ONTAP Select Deploy can also be used to create an evaluation Select cluster to allow clients to test and document the actual steps of a production deployment. ONTAP Select Deploy can also convert an evaluation cluster to a production cluster using an appropriate Capacity Tier license with sufficient capacity to cover the space consumed during the evaluation.

ONTAP Select Deploy is a virtual machine that contains an image of ONTAP Select. During cluster installation, ONTAP Select Deploy enforces several checks to help make sure that the ONTAP Select minimum requirements are met. The ONTAP Select Deploy VM and Select clusters can be upgraded separately.

Just like ONTAP on FAS, performance data should be collected using the perfstat utility. Here is a sample command:

No. The ONTAP Select VM uses independent-persistent drives, which are excluded from VMware-based snapshots. The only supported method for backing up ONTAP Select is SnapMirror or SnapVault.

Contact ng-ses-ontap-select@netapp.com.

There are several questions and answers dealing with licenses, installation, upgrades, and reverts.

Yes. The ONTAP Select Deploy utility can be upgraded separately from the ONTAP Select cluster. Similarly, the Select cluster can be upgraded separately from the ONTAP Select Deploy utility.

Yes, the upgrade procedure for a Select cluster is identical to the upgrade of a FAS cluster, although the ONTAP Select upgrade binary is a separate download from the ONTAP on FAS upgrade binary.

Yes, the revert procedure for an ONTAP Select cluster is almost identical to the revert procedure for a FAS cluster. There are a few differences however:

Yes.

Changes to the following ONTAP Select cluster properties are recognized by ONTAP Select Deploy using the cluster refresh operation available through the GUI, CLI, or REST API:

The following ONTAP Select VM changes are also recognized:

Upgrading to ONTAP Select Deploy 2.6 enables support for these changes for any ONTAP Select cluster that is already deployed but has not been changed from its original configuration. In other words, if the ONTAP Select cluster properties mentioned above were changed using System Manager or vCenter, then upgrading to ONTAP Select Deploy 2.6 will not fix these inconsistencies. The ONTAP Select property changes must be first rolled back for ONTAP Select Deploy to add its unique metadata to each ONTAP Select VM.

Modifying the networking details of the Deploy instance after it's running in an environment is not supported. For more information, see the Knowledge Base article - Modifying DNS configuration of ONTAP Deploy instance.

The method is the same for all licenses, although the specifics vary depending on whether it is a capacity tier or capacity pool license.

Purchasing, generating, and uploading an updated license file is how Deploy detects renewed licenses and support contracts.

If a capacity tier support contract end date has passed, the node can keep running, but you won't be able to download and install ONTAP updates, or call NetApp technical support for assistance without first bringing the support contract up-to-date.

If a capacity pool subscription lapses, the system warns you first but after 30 days, if the system shuts down, it won't reboot until an updated subscription is installed on the Deploy server.

There are several questions and answers dealing with storage.

Yes. ONTAP Select Deploy can be installed on either KVM or ESX, and both installations can create ONTAP Select clusters on either hypervisor.

If the ESX hosts are properly licensed, then there is no need for the ESX hosts to be managed by a vCenter Server. However, if the hosts are managed by a vCenter server, then you must configure ONTAP Select Deploy to use that vCenter Server. In other words, you cannot configure ESX hosts as standalone in ONTAP Select Deploy if they are being actively managed by a vCenter Server. Note that the ONTAP Select Deploy VM relies on vCenter to track all ONTAP Select VM migrations between ESXi hosts due to a vMotion or VMware HA event.

ONTAP Select can use servers without a hardware RAID controller. In this case, the RAID functionality is implemented in software. When using software RAID, both SSD and NVMe drives are supported. The ONTAP Select boot and core disks must still reside inside a virtualized partition (storage pool or datastore). ONTAP Select uses RD2 (root-data-data partitioning) to partition the SSDs. Therefore, the ONTAP Select root partition resides on the same physical spindles that are used for the data aggregates. However, the root aggregate and the boot and core virtualized disks do not count against the capacity license.

All RAID methods available on AFF/FAS are also available to ONTAP Select. This includes RAID 4, RAID DP, and RAID-TEC. The minimum number of SSDs varies depending on the type of RAID configuration chosen. Best practices require the presence of at least one spare. The spare and parity disks do not count toward the capacity license.

Software RAID is a layer in the ONTAP software stack. Software RAID provides more administrative control because the physical drives are partitioned and available as raw disks within the ONTAP Select VM. Whereas, with hardware RAID, a single large LUN is usually available that can then be carved out to create VMDISKs seen within ONTAP Select. Software RAID is available as an option and can be used instead of hardware RAID.

Some of the requirements for software RAID are as follows:

When installing on KVM, you must use a single bond and a single bridge. A host with two or four physical ports should have all the ports in the same bond.

When using a hardware RAID controller, ONTAP Select is largely unaware of underlying server issues. If the server is configured according to our best practices, a certain amount of redundancy should exist. We recommend RAID 5/6 to survive drive failures. For software RAID configurations, ONTAP is responsible for issuing alerts about disk failure and, if there is a spare drive, initiate the drive rebuild.

You should use a minimum of two physical NICs to avoid a single point of failure at the network layer. NetApp recommends that Data, Mgmt, and Internal port groups have NIC teaming and bonding configured with two or more uplinks in the team or bond. Such configuration ensures that, if there is any uplink failure, the virtual switch moves the traffic from the failed uplink to a healthy uplink in the NIC team. For details about the recommended network configuration, see Summary of best practices: Networking.

All other errors are handled by ONTAP HA in the case of a two-node or four-node cluster. If the hypervisor server needs to be replaced and the ONTAP Select cluster needs to be reconstituted with a new server, contact NetApp Technical Support.

All configurations, including vSAN, support 400TB of storage per ONTAP Select node.

When installing on datastores larger than the supported maximum size, you must use Capacity Cap during product setup.

ONTAP Select Deploy contains a storage add workflow that supports the capacity expansion operation on an ONTAP Select node. You can expand the storage under management by using space from the same datastore (if any space is still available) or add space from a separate datastore. The mixing of local datastores and remote datastores in the same aggregate is not supported.

Storage add also supports software RAID. However, in the case of software RAID, additional physical drives must be added to the ONTAP Select VM. The storage add in this case is similar to managing a FAS or AFF array. RAID group sizes and drive sizes must be considered when adding storage to an ONTAP Select node using software RAID.

ONTAP Select Deploy and ONTAP Select for ESX support the configuration of an ONTAP Select single-node cluster using either a vSAN or an external array type of datastore for its storage pool.

ONTAP Select Deploy and ONTAP Select for KVM support the configuration of an ONTAP Select single-node cluster using a shared logical storage pool type on external arrays. The storage pools can be based on iSCSI or FC/FCoE. Other types of storage pools are not supported.

Multinode HA clusters on shared storage are supported.

Multinode clusters using external storage (multinode vNAS) are supported for both ESX and KVM. Mixing of hypervisors in the same cluster is not supported. An HA architecture on shared storage still implies that each node in an HA pair has a mirror copy of its partner data. However, a multinode cluster brings in the benefits of ONTAP nondisruptive operation as opposed to a single-node cluster which relies on VMware HA or KVM Live Motion.

Although ONTAP Select Deploy adds support for multiple ONTAP Select VMs on the same host, it does not allow those instances to be part of the same ONTAP Select cluster during cluster creation. For ESX environments, NetApp recommends creating VM anti-affinity rules so that VMware HA does not attempt to migrate multiple ONTAP Select VMs from the same ONTAP Select cluster onto a single ESX host. Furthermore, if ONTAP Select Deploy detects that an administrative (user-initiated) vMotion or live migration of an ONTAP Select VM has resulted in a violation of our best practice such as two ONTAP Select nodes ending up on the same physical host, ONTAP Select Deploy posts an alert in the Deploy GUI and log. The only way that ONTAP Select Deploy becomes aware of the ONTAP Select VM location is as a result of a Cluster Refresh operation, which is a manual operation that the ONTAP Select Deploy administrator must initiate. There is no functionality in ONTAP Select Deploy that enables proactive monitoring, and the alert is only visible through the Deploy GUI or log. In other words, this alert cannot be forwarded to a centralized monitoring infrastructure.

NSX-V VXLAN port groups are supported. For multinode HA, including ONTAP MetroCluster SDS, make sure that you configure the internal network MTU to be between 7500 and 8900 (instead of 9000) to accommodate the VXLAN overhead. The internal network MTU can be configured with ONTAP Select Deploy during cluster deployment.

ONTAP Select VMs that run on external array storage pools support virsh live migrations.

No, all versions are supported regardless of whether the external array or vSAN configurations are all flash.

The Select VM inherits the vSAN datastore storage policy, and there are no restrictions on FTT/FTM settings. However, note that, depending on the FTT/FTM settings, the ONTAP Select VM size can be significantly larger than the capacity configured during its setup. ONTAP Select uses thick-eager, zeroed VMDKs that are created during setup. To avoid affecting other VMs using the same shared datastore, it is important to provide enough free capacity in the datastore to accommodate the true Select VM size as derived from the Select capacity and the FTT/FTM settings.

It is possible to configure multiple ONTAP Select nodes on the same host for vNAS configurations only, as long as these nodes are not part of the same ONTAP Select cluster. This is not supported for DAS configurations because multiple ONTAP Select nodes on the same physical host would compete for access to the RAID controller.

You can use a single 10GE port to connect to the external network. However, NetApp recommends that you use this only in constrained small form-factor environments. This is supported with both ESX and KVM.

You must install and run open-source CLVM and pacemaker (pcs) components on each host participating in the live migration. This is required to access the same volume groups on each host.

There are several questions and answers dealing with VMware vCenter.

ONTAP Select Deploy uses the VMware VIX API to communicate with the vCenter and/or the ESX host. The VMware documentation states that the initial connection to either a vCenter Server or an ESX host is done using HTTPS/SOAP on TCP port 443. This is the port for secure HTTP over TLS/SSL. Secondly, a connection to the ESX host is opened on a socket on TCP port 902. Data going over this connection is encrypted with SSL. Additionally, ONTAP Select Deploy issues a PING command to verify that there is an ESX host responding at the IP address you specified.

ONTAP Select Deploy must also be able to communicate with the ONTAP Select node and cluster management IP addresses as follows:

For two-node clusters, ONTAP Select Deploy hosts the cluster mailboxes. Each ONTAP Select node must be able to reach ONTAP Select Deploy through iSCSI (port 3260).

For multinode clusters, the internal network must be fully opened (no NAT or firewalls).

The list of vCenter rights required is available here: VMware vCenter server.

There are several questions and answers dealing with HA pairs and clusters.

Unlike four-node, six-node, and eight-node clusters in which the ONTAP Select Deploy VM is primarily used to create the cluster, a two-node cluster continuously relies on the ONTAP Select Deploy VM for HA quorum. If the ONTAP Select Deploy VM is unavailable, then failover services are disabled.

MetroCluster SDS is a lower-cost synchronous replication option that falls under the category of the MetroCluster Business Continuity solutions from NetApp. It is available only with ONTAP Select, unlike NetApp MetroCluster that is available on FAS Hybrid Flash, AFF, NetApp Private Storage for Cloud, and NetApp FlexArray® technology.

MetroCluster SDS provides a synchronous replication solution and falls under NetApp MetroCluster solutions. However, the key differences are in the distances supported (~10km versus 300km), and the connectivity type (only IP networks are supported rather than FC and IP).

The two-node cluster is defined as a cluster for which both nodes are in the same data center within 300m of each other. In general, both nodes have uplinks to the same network switch or set of network switches connected by an Inter-Switch Link.

The two-node MetroCluster SDS is defined as a cluster whose nodes are physically separated (different rooms, different buildings, or different data centers) and each node’s uplink connections are connected to separate network switches. Although MetroCluster SDS does not require dedicated hardware, the environment should support a set of minimum requirements in terms of latency (5ms RTT and 5ms jitter for a max total of 10ms) and physical distance (10km).

MetroCluster SDS is a premium feature and requires the Premium or Premium XL license. A Premium license supports the creation of both Small and Medium VMs as well as HDD and SSD media. All these configurations are supported.

ONTAP MetroCluster SDS supports all type of storage configurations (DAS and vNAS).

Yes, Software RAID is supported with SSD media on both KVM and ESX.

Yes, although a Premium license is required, this license supports both small and medium VMs as well as SSDs and spinning media.

No, only two-node clusters with a Mediator can be configured as MetroCluster SDS.

The requirements are as follows:

ONTAP Select VMs that run on vSAN datastores or external array datastores (in other words, vNAS deployments) support vMotion, DRS, and VMware HA functionality.

Storage vMotion is supported for all configurations, including single-node and multinode ONTAP Select clusters and the ONTAP Select Deploy VM. Storage vMotion can be used to migrate the ONTAP Select or the ONTAP Select Deploy VM between different VMFS versions (VMFS 5 to VMFS 6 for example), but it is not restricted to this use case. The best practice is to shut down the VM before initiating a Storage vMotion operation. ONTAP Select Deploy must issue the following operation after the storage vMotion operation is completed:

Please note that a storage vMotion operation between different types of datastores is not supported. In other words, storage vMotion operations between NFS-type datastores and VMFS datastores are not supported. In general, storage vMotion operations between external datastores and DAS datastores are not supported.

These configurations are not supported. ONTAP Select does not have visibility into the status of the physical network uplinks carrying client traffic. Therefore, ONTAP Select relies on the HA heartbeat to make sure that the VM is accessible to clients and to its peer at the same time. When a loss of physical connectivity occurs, the loss of the HA heartbeat results in an automatic failover to the other node, which is the desired behavior.

Segregating the HA traffic on a separate physical infrastructure can result in a Select VM being able to communicate with its peer but not with its clients. This prevents the automatic HA process and results in data unavailability until a manual failover is invoked.

There are several questions and answers dealing with the mediator service.

A two-node cluster continuously relies on the ONTAP Select Deploy VM for HA quorum. An ONTAP Select Deploy VM taking part in a two-node HA quorum negotiation is labeled a Mediator VM.

Yes. ONTAP Select Deploy acting as a Mediator for a two-node HA pair supports a WAN latency of up to 500ms RTT and requires a minimum bandwidth of 5Mbps.

The Mediator traffic is iSCSI, originates on the ONTAP Select node management IP addresses, and terminates on the ONTAP Select Deploy IP address. Note that you cannot use IPv6 for the ONTAP Select node management IP address when using a two-node cluster.

Yes. Each ONTAP Select Deploy VM can serve as a common Mediator service for up to 100 two-node ONTAP Select clusters.

Yes. It is possible to use another ONTAP Select Deploy VM to host the Mediator service.

Only a two-node cluster with a Mediator is supported in a stretched HA deployment model.