VSAN-Troubleshooting-Reference-Manual

Recommendations

Info

Diagnostics and Troubleshooting Reference Manual – Virtual SAN Some examples of random workloads include Online Transaction Processing (OLTP) database access, such as Oracle. A common way of testing random I/O is using DVDStore, which is an online e-commerce test application with a backend database component, and a client program to generate workload. Read versus write We already mentioned that hybrid Virtual SAN configurations use flash for read caching and write buffering. Sizing cache so that the workload can be largely contained in cache will produce the most desirable performance results from Virtual SAN. All of the writes will go to the write buffer in flash, but it is not guaranteed that all of the reads will come from the read cache, also in flash. However, that is what you would like to achieve, and avoid any read cache misses. Read cache sizing is very important; write cache sizing somewhat less so. Insufficient read cache causes cache misses, which are very expensive operations. Writes are different; they always go to cache and are eventually destaged. More write cache means that this destaging happens less often and more efficiently, but the effect of having less write cache is much less dramatic when compared to read cache. In the current release, there is no control over the read/write cache ratios. It is hard-coded at 70:30 write:read. However, there is the ability via the VM storage policy to set a read cache reservation for your particular virtual machine, if you think that it will benefit from having its own dedicated read cache, rather than sharing it with other virtual machine storage objects. But do so carefully! Where cache helps and where it may not Flash as cache helps performance in two important ways. First, frequently read blocks end up in cache, dramatically improving performance. Second, in hybrid configurations, all writes are committed to cache first, before being efficiently destaged to disks – again, dramatically improving performance. However, data still has to move back and forth between disks and cache. A sustained sequential write test ends up being a test of the back end disks, as does a sustained sequential read test. We also mentioned that long periods of “burstiness” could fill up the cache, and I/O may need to be satisfied from the magnetic disk layer. Also, you need to be aware that most real-world application workloads take a while for cache to “warm up” before achieving steady-state performance. 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 5 2
Diagnostics and Troubleshooting Reference Manual – Virtual SAN Working set size When working data set is 100% of the VMDK, the Virtual SAN read cache and write buffer gets filled up quickly. This will lead to steady state performance that is primarily supported by the back-end magnetic disks in a hybrid configuration. By using a smaller, more realistic working data set, Virtual SAN cache layer will give great performance. Guest file systems can matter There have been reports of significant differences in performance between different guest file systems and their settings, e.g. Windows NTFS and Linux. If you aren’t getting the performance you expect, consider investigating whether it could be a file system issue in the Guest OS. In many cases, consider using raw volumes rather than formatted file systems for benchmarking. What operations can impact performance? While no means complete, the following list discusses operations on Virtual SAN that might impact performance. These operations should be considered in detail, and perhaps scheduled during maintenance or out-of hour periods by a vSphere/Virtual SAN administrator. Rebuilding/resyncing operations There are a number of occasions when Virtual SAN will need to rebuild or resync objects and/or components: 1) When a host is placed in maintenance mode, and the administrator wishes to do a full data migration. The objects and components on the disks in that host will need to be located elsewhere. 2) When a user changes policy on an object (or set of objects), there is a good probability that Virtual SAN might get busy for a time by essentially recreating all objects affected by the policy change. 3) If there is failure in the cluster, and components need to be recreated elsewhere is the cluster. During these operations, resync I/O and virtual machine I/O will have to share the network and other resources, which may in turn affect overall virtual machine I/O performance. 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 5 3
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:
Page 199 and 200:
Page 201 and 202: Diagnostics and Troubleshooting Ref
Page 251: 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?