Download
large environment migrations to vsphere 4 0 u1 architecture considerations n.
Skip this Video
Loading SlideShow in 5 Seconds..
Large Environment Migrations to vSphere 4.0 U1 & Architecture Considerations PowerPoint Presentation
Download Presentation
Large Environment Migrations to vSphere 4.0 U1 & Architecture Considerations

Large Environment Migrations to vSphere 4.0 U1 & Architecture Considerations

107 Views Download Presentation
Download Presentation

Large Environment Migrations to vSphere 4.0 U1 & Architecture Considerations

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Large Environment Migrations to vSphere 4.0 U1 & Architecture Considerations Victor Barra & Chris Hayes IT ArchitectureSiemens Health ServicesEnterprise Hosting Solutions

  2. Discussion Topics • vSphere4 Real World Upgrades • Architecture & Deployment Considerations • Observations

  3. The Upgrade Process “Real World”

  4. vCenter and ESX Upgrade Summary • vSphere 4 Upgrade Process • Confirm Hardware Compatibility & Versions (vCenter and ESX) • Confirm vCenter Server hardware scalability • Conduct RDBMS version upgrade (where applicable) • vCenter 4.0 • Configure SNMP • Confirm Security Roles • Install\configure Update Manager • Build Update Manager Baseline • Confirm Alerts\Thresholds • ESX 4.0, Update1 • Rebuild or Update Manager (very effective) • Remediate: By cluster or by host (1.5 hours per host) • Update Licensing • VM Tools Upgrade (reboot required) • Update Manager (very effective) • Virtual Hardware 4 Upgrade (reboot required & complicated with static addressed environments)

  5. vCenter and ESX Upgrade Details • Check hardware compatibility guides (vCenter and ESX) (http://www.vmware.com/resources/compatibility/search.php) • Be sure to check for ESX hosts and vCenter server hardware • Confirm Capability for 3rd party components and hardware updates • vCenter: plugins, agents, etc. • ESX: hardware, storage microcode and agents • RDBMS considerations: Upgrade or New; What version; Remote or Local? • Configure: SQL permissions, ODBC client, etc. • vCenter Configuration (varies based on upgrade process) • Security Roles: re-map new granular and new feature function roles • Update Manager: download content; build baseline & schedulesz—ESX and VMs • Monitoring\Alerting: current and new feature triggers & alarms • ESX Configuration (varies based on upgrade process) • Upgrade via VMUM: set and forget • Reinstall 3rd parties impacted by upgrade • Siemens average timing: 1.5 hours per host

  6. vCenter and ESX Upgrade Details • Licensing…what’s new is old • No licensing server • Keys are simple 25-character strings • Consolidated license keys (versus separate vmotion, HA/DRS, keys) • VM Tools Upgrade • Update Manager: typically set and forget • Helpful resources for when VMTools installs fail: • Run Setup –c (automates otherwise manual cleanup) • http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015572 • http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1014169&sliceId=1&docTypeID=DT_KB_1_1&dialogID=61282982&stateId=0%200%2062711545 • http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1308

  7. vCenter and ESX Upgrade Details • Virtual Hardware 4 Upgrade • Execution completion takes 30 seconds, however… • Process Requires Outage to VM--multiple reboots • Is like replacing the motherboard in a physical machine • Installs new devices (disk, NIC and RAID) • Uses a VMUpgradeHelperto facilitate upgrade (collects supplies VM’s information) • Old devices not always cleaned-up (as seen in next slide) • Process is Not static IP friendly (loses WINS info) • http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015572 • Overhead of these complications can significantly impact upgrade project timeline

  8. vCenter and ESX Upgrade Details Hardware, Upgrade Version 4 to 7

  9. vCenter and ESX Upgrade Details, How to check for “hidden devices”

  10. Architecture & Deployment Considerations • LUN Device Naming • Service Console Redundancy • Guest Network Redundancy • Console Memory Allocation • Host Partitioning (ESX 4 TBD) • Cluster Size • Large-footprint VM hosting • Planning for cloning, snap-shots, etc. • Distributing Administration and Support Roles • Storage Migration • Thin Provisioning • vNetwork Distributed Switch • Host Profiles

  11. Base Deployment (Close Up View)

  12. Console Memory • Service Console Memory (Right Sizing) • Find the right size for the Service Console up to the maximum of 800MB, depending on installed 3rd party software (remember the “Free” command) • Mileage may vary depending on 3rd-party agents and overhead

  13. LUN Naming Considerations for Large Environments • LUN Naming Example – <ESX Farm name><Array Serial Number><Device ID>where array serial number is the last 4 digits of the array serial number and volume number is exactly 4 digits in length.  ex. dvlp41691249 • Example of the host-to-device mappings for 11 of a 22-host farm:

  14. Reminder: VMWare Infrastructure 3 Support Life Cycle • http://www.vmware.com/support/policies/lifecycle/vi/eos.html

  15. Observations… • ESX 1.0 to ESX 4.0: from industry buzz to organizational transformation • Challenging transition from consolidation to tiered hosting model • Native and 3rd party tools started to encourage organizational adoption • vCenter manageability\accessibility advantages • Robust Networking appliances, Storage APIs • Hardware heath monitoring\alerting integration • Executive leaders finding value in abstraction, but is still a sell • Fewer ROI hearings, some things just need to be done • Technology availability and social computing impact platform expectations • Generic tools not cutting it, but limited funding for vi-specific solutions • Business Recovery tools in unique demand, but data-rep still obstacle

  16. Questions & Answers • Victor Barra & Christopher HayesIT Architecture, Siemens Medical Solutions vic.barra@siemens.com christopher.hayes@siemens.com