Although there are lots of improvements to Virtual San 6.1, here are 3 that I truly like.
1. No more upgrading the VMFS-L to VsanFS via the RVC.
Wednesday, September 23, 2015
3 Cool New Features of Virtual SAN 6.1
Virtual Sans Stretched Clusters
Introduction to Stretched Clusters
Stretched clusters extend the Virtual SAN cluster from a single site to two sites for a higher level of availability and intersite load balancing. Stretched clusters are typically deployed in environments where the distance between data centers is limited, such as metropolitan or campus environments.
You can use stretched clusters to manage planned maintenance and avoid disaster scenarios, because maintenance or loss of one site does not affect the overall operation of the cluster. In a stretched cluster configuration, both sites are active sites. If either site fails, Virtual SAN uses the storage on the other site. vSphere HA restarts any VM that must be restarted on the remaining active site.
You must designate one site as the preferred site. The other site becomes a secondary or nonpreferred site. The system uses the preferred site only in cases where there is a loss of network connection between the two active sites, so the one designated as preferred is the one that remains operational.
A Virtual SAN stretched cluster can tolerate one link failure at a time without data becoming unavailable. A link failure is a loss of network connection between the two sites or between one site and the witness host. During a site failure or loss of network connection, Virtual SAN automatically switches to fully functional sites.
For more information about working with stretched clusters, see the Virtual SAN Stretched Cluster Guide.
Witness Host
Each stretched cluster consists of two sites and one witness host. The witness host resides at a third site and contains the witness components of virtual machine objects. It contains only metadata, and does not participate in storage operations.
The witness host serves as a tiebreaker when a decision must be made regarding availability of datastore components when the network connection between the two sites is lost. In this case, the witness host typically forms a Virtual SAN cluster with the preferred site. But if the preferred site becomes isolated from the secondary site and the witness, the witness host forms a cluster using the secondary site. When the preferred site is online again, data is resynchronized to ensure that both sites have the latest copies of all data.
If the witness host fails, all corresponding objects become noncompliant but are fully accessible.
The witness host has the following characteristics:
The witness host can use low bandwidth/high latency links.
The witness host cannot run VMs.
A single witness host can support only one Virtual SAN stretched cluster.
The witness host must have at least one VMkernel adapter with Virtual SAN traffic enabled, with connections to all hosts in the cluster.
The witness host must be a standalone host dedicated to the stretched cluster. It cannot be added to any other cluster or moved in inventory through vCenter Server.
The witness host can be a physical host or an ESXi host running inside a VM. The VM witness host does not provide other types of functionality, such as storing or running VMs. Multiple witness hosts can run as VMs on a single physical server. For patching and basic networking and monitoring configuration, the VM witness host works in the same way as a typicalESXi host. You can manage it with vCenter Server, patch it and update it by using esxcli or vSphere Update Manager, and monitor it with standard tools that interact with ESXi hosts.
You can use a witness virtual appliance as the witness host in a stretched cluster. The witness virtual appliance is an ESXihost in a VM, packaged as an OVF or OVA. The appliance is available in different options, based on the size of the deployment.
Stretched clusters extend the Virtual SAN cluster from a single site to two sites for a higher level of availability and intersite load balancing. Stretched clusters are typically deployed in environments where the distance between data centers is limited, such as metropolitan or campus environments.
You can use stretched clusters to manage planned maintenance and avoid disaster scenarios, because maintenance or loss of one site does not affect the overall operation of the cluster. In a stretched cluster configuration, both sites are active sites. If either site fails, Virtual SAN uses the storage on the other site. vSphere HA restarts any VM that must be restarted on the remaining active site.
You must designate one site as the preferred site. The other site becomes a secondary or nonpreferred site. The system uses the preferred site only in cases where there is a loss of network connection between the two active sites, so the one designated as preferred is the one that remains operational.
A Virtual SAN stretched cluster can tolerate one link failure at a time without data becoming unavailable. A link failure is a loss of network connection between the two sites or between one site and the witness host. During a site failure or loss of network connection, Virtual SAN automatically switches to fully functional sites.
For more information about working with stretched clusters, see the Virtual SAN Stretched Cluster Guide.
Witness Host
Each stretched cluster consists of two sites and one witness host. The witness host resides at a third site and contains the witness components of virtual machine objects. It contains only metadata, and does not participate in storage operations.
The witness host serves as a tiebreaker when a decision must be made regarding availability of datastore components when the network connection between the two sites is lost. In this case, the witness host typically forms a Virtual SAN cluster with the preferred site. But if the preferred site becomes isolated from the secondary site and the witness, the witness host forms a cluster using the secondary site. When the preferred site is online again, data is resynchronized to ensure that both sites have the latest copies of all data.
If the witness host fails, all corresponding objects become noncompliant but are fully accessible.
The witness host has the following characteristics:
The witness host can use low bandwidth/high latency links.
The witness host cannot run VMs.
A single witness host can support only one Virtual SAN stretched cluster.
The witness host must have at least one VMkernel adapter with Virtual SAN traffic enabled, with connections to all hosts in the cluster.
The witness host must be a standalone host dedicated to the stretched cluster. It cannot be added to any other cluster or moved in inventory through vCenter Server.
The witness host can be a physical host or an ESXi host running inside a VM. The VM witness host does not provide other types of functionality, such as storing or running VMs. Multiple witness hosts can run as VMs on a single physical server. For patching and basic networking and monitoring configuration, the VM witness host works in the same way as a typicalESXi host. You can manage it with vCenter Server, patch it and update it by using esxcli or vSphere Update Manager, and monitor it with standard tools that interact with ESXi hosts.
You can use a witness virtual appliance as the witness host in a stretched cluster. The witness virtual appliance is an ESXihost in a VM, packaged as an OVF or OVA. The appliance is available in different options, based on the size of the deployment.
Friday, September 4, 2015
Useful VSAN Network Troubleshooting Tools
Virtual SANs are dependent on the correct configuration of the VSAN network. Incorrect ip settings, multicast address, MTU mistmatches will prevent the normal operations of your VSAN cluster.
What follows below is what you DON'T want to see...
VMware provides a set of utilities for troubleshooting, both within the esxi host and through the RVC. Here is a short list.
1. The vsan.reapply_vsan_vmknic_config RVC utility to refresh networking settings
2. The tcpdump-uw -i vmk? udp port 23451 -v utility to verify multicast settings
3. The tcpdump-uw -i vmk? igmp utility
4. The esxcli network vswitch standard list utility to verify the MTU of the switch
5. The esxcli network ip interface list utility to verify the MTU settings of the vmk ports
What follows below is what you DON'T want to see...
VMware provides a set of utilities for troubleshooting, both within the esxi host and through the RVC. Here is a short list.
1. The vsan.reapply_vsan_vmknic_config RVC utility to refresh networking settings
2. The tcpdump-uw -i vmk? udp port 23451 -v utility to verify multicast settings
3. The tcpdump-uw -i vmk? igmp utility
Subscribe to:
Posts (Atom)