Click to public concern number: VirtualMan More technical fault Solution!
This articles will focus on a number of important functions, vSAN 6.2 introduces a new feature, end to end software verification and can help customers avoid data integrity problems due to the problems caused by the underlying storage medium.
In vSAN 6.2, the checksum is enabled by default, but can / object to enable or disable the checksum passes VM storage policies for each virtual machine. The checksum is enabled by default, because we believe that customers want to use this powerful new features. The only reason to disable it is the application already contains this feature.
** New features checksum called "disables the object checksum." ** as shown below, and you can choose to disable it when you create a VM storage policy. Otherwise, it is always enabled.
vSAN checksum brief overview:
Checksum and using the very common vSAN cyclic redundancy check CRC-32C (Castagnoli) to achieve best performance, the use of special CPU instructions Intel processors. Each 4KB block of data has associated therewith a checksum. Checksum size of 5 bytes, the data is written, verification and validation is performed on the same host data source, to ensure that the event can capture any damage on the network. Checksum and saved with the data.
If the checksum is enabled in the subsequent data read process and also requires the checksum data.
If the checksum and display data in a way that was just read block is corrupt, Raid1 for objects from another copy the correct data read / mirror. For Raid5 / Raid6 objects, reconstructed from other components of the data blocks in the stripe Raid. On the host that contains the error components and vmkernel.log running VM files on the host will also record an error. In the following example, we deliberately covered zero data blocks with random data, and read data through the operating system:
**2016-02-16T07:31:44.082Z cpu0:33075)LSOM:RCDomCompletion:6706:
Throttled: Checksum error detected oncomponent
a3fbc156-3573-4f2c-f257-0050560217f4
(computed CRC 0x6e4179d7 != saved CRC 0x0)
2016-02-16T07:31:44.086Z cpu0:33223)LSOM:LSOMScrubReadComplete:1958:
Throttled: Checksum error detected oncomponent
a3fbc156-3573-4f2c-f257-0050560217f4, dataoffset 524288
(computed CRC 0x6e4179d7 != saved CRC 0x0)
2016-02-16T07:31:44.096Zcpu1:82528)WARNING: DOM:
DOMScrubberAddCompErrorFixedVob:327:Virtual SAN detected and fixed a
medium or checksum error for component
a3fbc156-3573-4f2c-f257-0050560217f4
on disk group521f5f1b-c59a-0fe2-bdc0-d1236798437c**
Scanning mechanisms:
In addition to reading operation outer checksum validation, VSAN and a disk scanning mechanism, the data on the disk for checking whether there is silence damage. The mechanism by default scan all the data once a year, but can be adjusted by the Advanced Settings VSAN.ObjectScrubsPerYear, to run more frequently. For example, if you want all checked weekly data, it can be set to 52, but be aware that there will be some performance overhead when running this operation.
to sum up:
All new features (e.g. Raid5 / Raid6, compression and de-emphasis) and configuration (e.g. vSAN extending clusters) are fully supported checksum. As mentioned earlier, by default it is enabled, so customers do not need to configure can be used directly. If for some reason do not want to use it, just as described above in the VM storage strategy can disable it. This feature will allow customers to vSAN detect data corruption due to the "latent sector error" caused by these "wrong sector error" is usually caused by a physical drive, or other problems caused by silent data corruption.
