2011 q1-indy-vmug
•Als PPT, PDF herunterladen•
0 gefällt mir•576 views
The document provides best practices for storage and VMware as of 2010-2011. It discusses protocols like iSCSI and Fibre Channel, configuring multipathing, using plugins and VAAI, tracking alignment, and keeping storage layouts simple. The key recommendations are to pick protocols based on your needs, leverage vendor documentation, configure multipathing properly, use free vCenter plugins to automate best practices, and leverage thin provisioning and large datastores for simplicity.
![Indianapolis VMUG Next Generation Best Practices for Storage and VMware Brian Lewis vSpecialist – Central US [email_address]](https://image.slidesharecdn.com/2011-q1-indy-vmug-110130190719-phpapp02/85/2011-q1indyvmug-1-320.jpg)
![The “Great” Protocol Debate ,[object Object],[object Object],[object Object],[object Object],Conclusion: there is no debate – pick what works for you! The best flexibility comes from a combination of VMFS and NFS](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie 2011 q1-indy-vmug
Ähnlich wie 2011 q1-indy-vmug (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
2011 q1-indy-vmug
- 1. Indianapolis VMUG Next Generation Best Practices for Storage and VMware Brian Lewis vSpecialist – Central US [email_address]
- 3. Key things to know – “A – F” Best Practices circa 2010/2011
- 4. “ A” Best Practices circa 2010/2011 Leverage Key Documentation
- 7. “ B” Best Practices circa 2010/2011 Configure Multipathing
- 8. Understanding the vSphere Pluggable Storage Architecture (PSA)
- 9. What ’s “out of the box” in vSphere 4.1? [root@esxi ~]# vmware -v VMware ESX 4.1.0 build-260247 [root@esxi ~]# esxcli nmp satp list Name Default PSP Description VMW_SATP_SYMM VMW_PSP_FIXED Placeholder (plugin not loaded) VMW_SATP_SVC VMW_PSP_FIXED Placeholder (plugin not loaded) VMW_SATP_MSA VMW_PSP_MRU Placeholder (plugin not loaded) VMW_SATP_LSI VMW_PSP_MRU Placeholder (plugin not loaded) VMW_SATP_INV VMW_PSP_FIXED Placeholder (plugin not loaded) VMW_SATP_EVA VMW_PSP_FIXED Placeholder (plugin not loaded) VMW_SATP_EQL VMW_PSP_FIXED Placeholder (plugin not loaded) VMW_SATP_DEFAULT_AP VMW_PSP_MRU Placeholder (plugin not loaded) VMW_SATP_ALUA_CX VMW_PSP_FIXED_AP Placeholder (plugin not loaded) VMW_SATP_CX VMW_PSP_MRU Supports EMC CX that do not use the ALUA protocol VMW_SATP_ALUA VMW_PSP_RR Supports non-specific arrays that use the ALUA protocol VMW_SATP_DEFAULT_AA VMW_PSP_FIXED Supports non-specific active/active arrays VMW_SATP_LOCAL VMW_PSP_FIXED Supports direct attached devices
- 11. What ’s “out of the box” in vSphere? HOWTO – setting PSP for a specific device (can override default selected by SATP detected ARRAYID): esxcli nmp device setpolicy --device <device UID> --psp VMW_PSP_RR (check with your vendor first!)
- 12. Or the New Way…
- 13. Changing Round Robin IOOperationLimit esxcli nmp roundrobin setconfig --device <device UID> –iops check with your storage vendor first! This setting can cause problems on arrays. Has been validated ok, but not necessary in most cases
- 14. Effect of different RR IOOperationLimit settings NOTE: This is with a SINGLE LUN. This is the case where the larger IOOperationLimit default is the worst In a real-world environment – lots of LUNs and VMs results in decent overall loadbalancing Recommendation – if you can, stick with the default
- 17. Understanding MPIO MPIO is based on “initiator-target” sessions – not “links”
- 25. General NFS Best Practices – HA and Scaling 10GbE? One VMKernel port & IP subnet Support multi-switch Link aggr? Use multiple links with IP hash load balancing on the NFS client (ESX) Use multiple links with IP hash load balancing on The NFS server (array) Storage needs multiple sequential IP addresses Use multiple VMKernel Ports & IP subnets Use ESX routing table Storage needs multiple sequential IP addresses Yes No Yes
- 29. “ C” Best Practices circa 2010/2011 Track Alignment
- 36. “ D” Best Practices circa 2010/2011 Utilize free vCenter plugins and VAAI
- 40. “ E” Best Practices circa 2010/2011 Keep it Simple
- 42. “ F” Best Practices circa 2010/2011 Use SIOC (if you can)
- 44. Best Practices circa 2010/2011 General ‘Gotchas’
- 47. Best Practices circa 2010/2011 When do the best practices not apply?
Hinweis der Redaktion
- Title Month Year
- Title Month Year
- Title Month Year
- Title Month Year
- Hyper-consolidation of virtual machines can lead to complex storage architectures. Mapping dozens of LUNs accessed by 100 ’s of VMs to channels is a laborious and complex job. Further, as virtual machines move around in the cluster, the IO loads on the channel can change significantly. EMC ’s industry-leading PowerPath significantly reduces the effort required to set up the SAN environment. PowerPath lets you treat the connections between the ESX servers and the EMC storage as a pool. With PowerPath, you don’t have to try to figure out which LUNs should share which channels. PowerPath uses all available paths to access all devices. Dynamic load balancing algorithms will continuously adjust IO routing to provide the best overall performance. So when DRS kicks in and moves VMs around in the cluster, PowerPath will automatically adjust how the I/Os transit the SAN, providing predictable performance. Some VMs and applications are more important and have higher or more critical disk IO workloads. PowerPath provides the ability to set priorities on the most important LUNs to help ensure that the critical applications are getting the data they need to run smoothly. Coupled with DRS and array based QOS (NQM or Priority Manager), you have end to end QOS control of your storage environment. PowerPath also provides channel fault protection, so the loss of an HBA, cable, switch, or array connection will be invisible to ESX or the application. Animation Control: Slide comes up with one row of VMs. <click> causes IOs to begin going to/from the storage. Story: With a few VMs, mapping IO to drives and channels is fairly simple. But when you start adding more VMs more IO load is put on the SAN. <click> causes more VMs to appear with more IO With hyperconsolidation, you can have 100 ’s of independent VMs running within the environment. The VMware admin can even put on that IO intensive app ( look in the second row, fourth from the right) that disrupts IO from other apps in the environment. Setting this up to ensure that all of the VMs get the IO response time they need is very difficult. Then add VMotion, DRS, HA, and any assumption you have about which IO streams will be sharing which channels are invalidated. <click> PowerPath is installed on the ESX servers, then all the paths are masked. PowerPath will manage all of this complexity, constantly adjusting the IO path usage to the changes in IO loads coming from the VMs. PowerPath lets you ignore all of the complexity of what goes where. Simply assign all devices to all paths, and turn PowerPath loose to do it ’s thing, optimizing the overall IO performance for the ESX environment. If need be, you can provide additional QOS management for the most important application by managing LUN and path prioritization.