VSAN-Troubleshooting-Reference-Manual

Recommendations

Info

Diagnostics and Troubleshooting Reference Manual – Virtual SAN Anatomy of a read in all-flash configurations The major difference between a read in a hybrid configuration and a read in an allflash configuration is that in an all-flash configuration, the flash cache is not used for caching reads. It is dedicated as a write cache only. If the read operation does not find the block in the flash cache in an all-flash configuration, then it is read directly from the ‘capacity’ flash device. The block does not get placed in the tier1 flash cache, like a hybrid configuration. The performance of the all-flash capacity tier is more than enough for reads. Anatomy of a write in all-flash configurations In the all-flash configuration, the tier1 flash cache is now used for write caching only, what can be considered a write back cache. When the working set is bigger than write cache, old data blocks are evicted from the tier1 write cache to the flash capacity devices. If the working set fits of the virtual machine fits completely in the tier1 write cache, there are no data blocks written to the flash capacity device at all. Virtual SAN caching algorithms Virtual SAN implements a distributed persistent cache on flash devices across the Virtual SAN cluster. In Virtual SAN 5.5 and 6.0 hybrid configurations, caching is done in front of the magnetic disks where the data lives. It is not done on the client side, i.e. where the virtual machine compute resides. A common question is why we took this approach to caching? The reason for this is because such distributed caching results in better overall utilization of flash, which is the most valuable storage resource in our cluster. Also, with DRS and vMotion, virtual machines move around hosts in a cluster. You don’t want to be moving GBs of data around or rewarming caches every time a VM migrates. Indeed, in Virtual SAN you will see no performance degradation after a VM migration. Enhancements to caching algorithms in 6.0 Virtual SAN 6.0 uses a tier-1 flash device as a write cache in both hybrid and all-flash disk groups. However, the caching algorithm optimizes for very different goals in each case. In hybrid groups, the caching algorithm aims at accumulating large proximal chunks of data for each magnetic disk. The priority is to maximize the write performance obtained from the magnetic disks by applying a nearly sequential workload to them when destaging from the flash cache (elevator algorithm) to magnetic disks. V M W A R E S T O R A G E B U D O C U M E N T A T I O N / 2 4 8
Diagnostics and Troubleshooting Reference Manual – Virtual SAN In the case of all-flash disk groups, the goal is to keep as many hot blocks (written often) in the flash cache device. Thus, a flash cache device that has a higher endurance will be able to satisfy a higher rate of write operations. There is no attempt made to optimize all-flash configurations for proximal destaging, as flash devices handle random workloads very well. Latency consideration with distributed cache A common question related to the latency the network introduces, if you need to access data that resides on another host in the cluster. Typical latencies in 10GbE networks are in the range of 5 – 50 microseconds. When you see the specs of flash devices you hear about latencies in the range of 50 – 100 microseconds. But these are latencies values when you send one I/O at a time. When you operate those flash devices at thousands of IOPS, then latency values start to grow to 1 millisecond or even higher in some cases. Adding something like 10 microseconds on top of 1 millisecond of latency doesn’t make a huge difference to the overall performance. How VM Storage Policies impact performance Where stripe width helps and where it may not While setting disk striping values can sometimes increase performance, that isn’t always the case. As an example, if a given test is cache-friendly (e.g. most of the data is in cache), striping won’t impact performance significantly. As another example, if a given VMDK is striped across disks that are busy doing other things, not much performance is gained, and may actually become worse. A word of caution on flash read cache reservation The policy setting of Flash Read Cache Reservation (applicable to hybrid only) should be used only in the event of an identifiable performance improvement. If you set a read cache reservation in a policy, and you associate it with multiple virtual machines, you could consume a significant amount of flash on the host or hosts in question, thus starving the other virtual machines of valuable cache resources. Handle with care! Since all virtual machines will share the read cache and write buffer equally, it is strongly recommended that you do not assign a dedicated amount of read cache to virtual machines unless there is a pressing need to solve an underlying performance issue for a specific set of virtual machines. V M W A R E S T O R A G E B U D O C U M E N T A T I O N / 2 4 9
Page 1 and 2:
Diagnostics and Troubleshooting Gui
Page 3 and 4:
Diagnostics and Troubleshooting Ref
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198: Diagnostics and Troubleshooting Ref
Page 247: Diagnostics and Troubleshooting Ref
Page 295: Diagnostics and Troubleshooting Ref
show all

VSAN-Troubleshooting-Reference-Manual

Create successful ePaper yourself

Delete template?

Save as template?