Shulou(Shulou.com)06/02 Report--

Click here to view the original text

Catalogue

I. capacity planning 1

1) Raw capacity 1

2) number of failures allowed 1

3) calculate the required capacity 2

4) guidelines for setting capacity size 3

5) considerations for virtual machine objects 4

II. SSD cache design plan 5

1) choose between PCIe or SSD flash devices 5

2) Flash device as Virtual SAN cache 6

Third, use SSD as capacity design 7

1) choose between PCIe or SSD flash devices 7

2) SSD device as Virtual SAN capacity device 7

Fourth, use HDD as the capacity design 8

1) determine the size and number of disks in a mixed configuration according to storage space and performance requirements. eight

2) disk as Virtual SAN capacity 9

Fifth, the design of storage controller 10

1) the storage controllers contained in the hosts of the Virtual SAN cluster should best meet the performance and availability requirements. ten

VI. Design of Virtual SAN mainframe 11

1) memory and CPU 11

2) Host network 11

3) multiple disk groups 12

7. Virtual SAN cluster design 13

1) resize the Virtual SAN cluster to allow failure 13

2) restrictions on three-host cluster configuration 14

3) balanced and unbalanced cluster configurations 15

8. Virtual SAN network design 16

IX. Network failover and load balancing 16

4) Multicast considerations in Virtual SAN networks 16

5) use Network I Control O Control to allocate bandwidth to Virtual SAN 17

6) Mark Virtual SAN traffic 18

7) segmenting Virtual SAN traffic in VLAN 19

8) Giant frame 19

10. Virtual SAN fault-tolerant design 19

1) about the fault tolerance domain 19

2) Fault-tolerant domain construction 20

3) use fault-tolerant domain to deal with the failure of multiple hosts

Capacity planning raw capacity

To determine the raw capacity of the Virtual SAN data storage, multiply the total number of disk groups in the cluster by the size of the capacity devices in the disk group, and then subtract the overhead required for the Virtual SAN disk format.

Number of failures allowed

"when planning the capacity of Virtual SAN data storage, you must consider the allowable number of failures and fault tolerance method attributes for the virtual machine storage policy of the cluster."

For example, if the fault tolerance method is set to RAID-1 (mirroring)-performance and the number of failures allowed is set to 1, the virtual machine can use approximately 50% of its raw capacity. If the allowed number of failures is set to 2, the available capacity is approximately 33%. If the allowable number of failures is set to 3, the available capacity is approximately 25%.

For example, if the fault tolerance method is set to RAID-5/6 (remove Encoding)-capacity and the number of failures allowed is set to 1, the virtual machine can use approximately 75% of the original capacity. If the allowed number of failures is set to 2, the available capacity is approximately 67%.

Calculate the required capacity

Plan the capacity required for virtual machines in the cluster with RAID 1 mirroring according to the following criteria:

Calculate the storage space required by virtual machines in the Virtual SAN cluster.

Expected overall consumption = number of VMs in the cluster * expected percentage of consumption per VMDK

Consider the allowable number of failures attributes configured in the storage policy for virtual machines in the cluster. This property directly affects the number of copies of VMDK files on hosts in the cluster.

Datastore capacity = expected overall consumption * (Number of failures to tolerate + 1)

Estimate the overhead requirements for the Virtual SAN disk format.

Disk format 3.0 and later adds additional overhead, usually no more than 1-2% capacity per device.

If deduplication and compression and software checksum are enabled, each device requires an additional overhead of approximately 6.2% capacity.

Disk format version 2.0 adds additional overhead, usually no more than 1-2% capacity per device.

Disk format version 1.0 adds additional overhead of approximately 1 GB per capacity device.

Guidelines for setting capacity size

Leave at least 30% unused space to prevent Virtual SAN from rebalancing the storage load. As long as the consumption on a single capacity device reaches 80% or more, Virtual SAN rebalances the components in the cluster. The rebalance operation may affect the performance of the application and the storage consumption should be less than 70%.

Plan additional capacity to handle potential failures or replace capacity devices, disk groups, and hosts. When a capacity device is inaccessible, Virtual SAN recovers components in other devices in the cluster. Virtual SAN recovers components from the entire disk group when the flash cache device fails or is removed.

Reserve additional capacity to ensure that Virtual SAN recovers components in the event of a host failure or if the host enters maintenance mode. To allow rebuilding after a failure, there must be at least three hosts.

Provide sufficient temporary storage space to make changes in the Virtual SAN virtual machine storage policy. When you dynamically change the virtual machine storage policy, Virtual SAN may create a layout for the copies of the constituent objects. When Virtual SAN instantiates these copies and synchronizes them with the original, the cluster must temporarily provide additional space.

If you plan to use advanced features such as software checksum or de-duplication and compression, leave extra space to handle operational overhead.

Considerations for virtual machine object

When planning storage capacity, consider the space required for virtual machine home page namespace objects, snapshots, and swap files.

Virtual machine home page namespace. You can assign a storage policy specifically to the home page namespace object of the virtual machine. Plan the storage space to meet the storage policy requirements assigned to the virtual machine home page namespace with more than 0 allowed failures.

Snapshot. The incremental device inherits the policy of the underlying VMDK file. Plan additional space based on the required size and number of snapshots, as well as the settings in the Virtual SAN storage policy.

Exchange files. Virtual SAN uses a separate storage policy for swap files for virtual machines. This policy allows one failure, no striping and read cache reservations are defined, and forced provisioning is enabled.

The SSD cache design plan chooses between PCIe or SSD flash devices

Compatibility.

Performance. PCIe devices generally have higher performance than SSD devices.

Capacity. The maximum capacity available for PCIe devices is usually greater than the maximum capacity for SSD devices.

Write lifetime. The write lifetime of a PCIe or SSD device must meet the capacity or cache requirements in an all-flash configuration and the cache requirements in a mixed configuration.

Cost. The cost of PCIe equipment is usually higher than that of SSD equipment.

Flash devices act as Virtual SAN caches

Use SSD as the capacity design to choose between PCIe or SSD flash devices

Select a PCIe or SSD flash device based on the performance, capacity, write lifetime, and cost requirements for Virtual SAN storage.

Compatibility. The "Virtual SAN" section of the VMware compatibility guide should list the model number of the PCIe or SSD device.

Performance. PCIe devices generally have higher performance than SSD devices.

Capacity. The maximum capacity available for PCIe devices is usually larger than the maximum capacity listed for SSD devices for Virtual SAN in the current VMware compatibility guide.

Write lifetime. The write lifetime of a PCIe or SSD device must meet the capacity or cache requirements in an all-flash configuration and the cache requirements in a mixed configuration.

Cost. The cost of PCIe equipment is usually higher than that of SSD equipment.

SSD device as Virtual SAN capacity device

In an all-flash configuration, Virtual SAN does not use cache for read operations, nor does it apply the read cache reservation setting in the virtual machine storage policy.

For cache devices, a small amount of more expensive flash memory with high write persistence can be used. For capacity devices, lower-cost flash memory with lower write persistence can be used.

Follow these guidelines to plan the configuration of flash capacity devices:

For better Virtual SAN performance, use more disk groups made up of devices with smaller flash capacity.

For balanced performance and predictable behavior, use the same type and model of flash capacity devices.

Use HDD as the capacity design to determine the size and number of disks in a mixed configuration according to storage space and performance requirements.

SAS, NL-SAS, and SATA disk Devic

Compatibility. The disk model must be certified and listed in the "Virtual SAN" section of the VMware compatibility guide.

Performance. SAS and NL-SAS devices perform better than SATA disks.

Capacity. Consider using multiple small devices instead of a small number of large devices.

Cost. SAS and NL-SAS devices are more expensive than SATA disks.

In environments where capacity and cost take precedence over performance, SATA disks (rather than SAS and NL-SAS devices) should be used.

Disk as Virtual SAN capacity

For better Virtual SAN performance, use multiple small capacity disks.

There must be enough disks to provide sufficient summary performance for data transfer between cache and capacity. Using more small devices can provide higher performance than large devices that use less.

In an environment with multiple virtual machines, the number of disks is also important for read operations when the data is not in the read cache, so Virtual SAN needs to read data from disks. In an environment with a small number of virtual machines, if the number of disk strips per object in the active virtual machine storage policy is greater than 1, the number of disks affects the read operation.

For balanced performance and predictable behavior, disks of the same type and model should be used in the Virtual SAN data store.

Specify a sufficient number of disks to match the number of failures allowed in the defined storage policy and the disk stripe property value for each object.

The design of the storage controller the hosts of the Virtual SAN cluster should have storage controllers that best meet performance and availability requirements.

Use the storage controller model and driver and firmware versions listed in the VMware compatibility guide.

If possible, use multiple storage controllers, which can improve performance and isolate only potential controller failures to a subset of the disk group.

Use the storage controller with the highest queue depth in the VMware compatibility guide. Using a controller with a higher queue depth can improve performance.

Use the storage controller in pass-through mode to achieve the best performance of Virtual SAN. Compared with the storage controller in cut-through mode, the storage controller in RAID 0 mode requires a higher amount of configuration and maintenance.

Design memory and CPU of Virtual SAN host

Host network

If you plan to use a host with an 1-GbE adapter, dedicate the adapter to Virtual SAN. For all-flash configurations, schedule hosts with dedicated or shared 10-GbE adapters.

If the 10-GbE adapter is shared with other traffic types, use vSphere Distributed Switch so that Virtual SAN traffic is isolated by using Network I Control O Control and VLAN.

Create physical adapter groups for Virtual SAN traffic to ensure redundancy.

Multiple disk groups

In Virtual SAN data storage, a disk group represents a single failure domain. If the flash cache or storage controller stops responding, the capacity of the disk group will be inaccessible. As a result, Virtual SAN rebuilds all components in the disk group from other locations in the cluster.

Multiple disk groups with less capacity are designed due to the following advantages and disadvantages:

Performance is improved because the data store has more summary caches and the Icano operation is faster

Advantages

Because Virtual SAN rebuilds fewer components, it increases the number and size of failure domains and improves performance when a disk group failure occurs

Because two cache devices instead of one are used for the same cache size, it drives up the cost

Inferior position

More memory is required to handle more disk groups

Multiple storage controllers are required to reduce failure domain

Blade servers and external Stora

Due to the limited number of disk slots in blade servers, the capacity of blade servers in Virtual SAN data storage usually cannot be expanded. To expand the planned capacity of the blade server, use an external storage chassis.

Device hot plug and interaction

Consider using storage controller pass-through mode support to easily hot-plug or replace disk and flash capacity devices on the host. If the controller is in RAID 0 mode, additional steps must be performed for the host to discover the new drive.

Virtual SAN cluster design resizes the Virtual SAN cluster to allow failures

Configure the allowed number of failures attribute in the virtual machine storage policy to handle host failures. The number of hosts required for the cluster is calculated as 2 * number of failures to tolerate + 1. The more failures the cluster is configured to allow, the more capacity hosts are required.

If you connect a clustered host in a rack server, you can organize the host into a fault-tolerant domain to improve fault management.

Restrictions on host cluster configuration

In a three-host cluster configuration, only one host failure can be allowed by setting the allowed number of failures to 1. For the two required copies of the virtual machine data, Virtual SAN saves each copy on a different host. The witness is on the third host. Due to the small number of hosts in the cluster, the following restrictions exist:

When one host fails, Virtual SAN cannot rebuild the data on another host to prevent another failure.

If a host enters maintenance mode, Virtual SAN cannot reprotect the data that has been withdrawn. If the host is in maintenance mode, there may be problems with the data.

As a result, virtual machines will be at risk because they will not be accessible if another failure occurs.

Balanced and unbalanced cluster configuration

Virtual SAN is best suited for running on hosts with a unified configuration.

If the Virtual SAN cluster uses hosts with different configurations, there are the following disadvantages:

Storage performance is less predictable because Virtual SAN does not store the same number of components on each host.

The maintenance steps are different.

For hosts with fewer or different types of cache devices in the cluster, performance will be degraded.

Virtual SAN Network Design Network failover and load balancing

Virtual SAN does not bind the Nic for load balancing.

If you plan to configure network card groups for availability, consider these failover configurations.

Virtual SAN supports IP hash load balancing, but there is no guarantee of improved performance for all configurations.

Virtual SAN does not support multiple VMkernel adapters on the same subnet. By grouping physical network adapters, network availability can be more easily achieved with fewer settings.

Multicast considerations in Virtual SAN Network

Multicast must be enabled on the physical switch to enable the exchange of detection signals and metadata between hosts in the Virtual SAN cluster.

If you have multiple Virtual SAN on the same network, change the multicast address of the new cluster before deploying another Virtual SAN cluster in production so that member hosts do not receive extraneous multicast messages from other clusters.

Use Network I Control O Control to allocate bandwidth to Virtual SAN

If Virtual SAN traffic uses 10-GbE physical network adapters that are shared with other system traffic types (HA traffic, virtual machine traffic, and so on), you can use vSphere Network I Control O Control in vSphere Distributed Switch to guarantee the amount of bandwidth required by Virtual SAN.

In vSphere Network I Control O Control, reservations and shares can be configured for Virtual SAN output traffic.

For example, specific bandwidth and share can be configured on 10-GbE physical adapters that handle Virtual SAN, vSphere vMotion, and virtual machine traffic.

If the 10-GbE adapter becomes saturated, the Network I Gbps O Control will allocate 5 Gbps to the Virtual SAN on the physical adapter.

Mark Virtual SAN traffic

Virtual SAN traffic can be assigned to a specific class, and traffic is marked accordingly with service class (Class of Service, CoS) values (range 0 to 7) through traffic filtering and tagging policies using vSphere Distributed Switch, where 0 is a high priority and 7 is a low priority.

Segmenting Virtual SAN traffic in VLAN

Consider isolating Virtual SAN traffic in VLAN to enhance security and performance, especially when sharing the capacity of backup physical adapters across multiple traffic types.

Giant frame

If you plan to use jumbo frames in Virtual SAN to improve CPU performance, verify that jumbo frames are enabled on all network devices and hosts in the cluster.

By default, the TCP Segmentation cleanup (TSO) and large receive cleanup (LRO) features are enabled on ESXi. Consider whether using jumbo frames will improve performance enough to cover the cost of enabling jumbo frames on all nodes in the network.

Virtual SAN Fault-tolerant Design about Fault-tolerant Domain

The Virtual SAN fault-tolerant domain feature instructs Virtual SAN to distribute redundant components to servers in each computer rack. As a result, the environment can be protected from rack-level failures, such as power outages or disconnections.

Fault-tolerant domain construction

Virtual SAN requires at least two fault-tolerant domains, each containing one or more hosts.

If possible, use at least four fault-tolerant domains. When using three fault-tolerant domains, some data withdrawal modes are not supported, and Virtual SAN cannot reprotect data after a failure.

"if the fault-tolerant domain is enabled, Virtual SAN applies the active virtual machine storage policy to the fault-tolerant domain (rather than a single host)."

Calculates the number of fault-tolerant domains in the cluster based on the allowed number of failures attribute specified in the storage policy that is scheduled to be assigned to the virtual machine.

Number of fault domains = 2 * number of failures to tolerate + 1

If the host is not a member of a fault-tolerant domain, Virtual SAN interprets it as a separate fault-tolerant domain.

Use fault-tolerant domains to deal with multiple host failures

Consider a cluster of four server racks, each containing two hosts. "if you set the allowed number of failures to 1 and do not enable the fault tolerance domain, Virtual SAN may store two copies of the object in the same cabinet as the host." Therefore, the application may have a potential risk of data loss in the event of a rack-level failure. When configuring hosts that may fail at the same time to a separate fault-tolerant domain, Virtual SAN ensures that each protection component (copy and witness) is placed in a separate fault-tolerant domain.

If you want to add hosts and capacity, you can use an existing fault-tolerant domain configuration or define a fault-tolerant domain.

Consider the following guidelines when using fault-tolerant domains to balance storage load and fault tolerance:

Provide sufficient fault-tolerant domains to meet the allowable number of failures configured in the storage policy.

Define at least three fault-tolerant domains. For best protection, define at least four fault-tolerant domains.

Assign the same number of hosts to each fault-tolerant domain.

Use a host with a unified configuration.

If possible, dedicate a fault-tolerant domain with available capacity to rebuild data after a failure.

The above content is summarized by Zhao Haibing, teacher of 51cto College, and shared with you.

Those who want to take the virtualization course can sign up for: http://edu.51cto.com/center/wejob/user/index?train_id=122

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.