WIXLIB

Performance and SizingConsiderationsTRW AutomotivesChin, Kar WaiGlobal DC Services Delivery ManagerEmail : karwai.chin@trw.comHttp://www.trw.com

Performance and Sizing ConsiderationsUnderstanding what’s a Virtual MachineCandidate SelectionsBuilding your application on VM e.g. Exchange, SAPSizing/Performance consideration for your VMSupport from major ISVBuilding a solid foundation with VMware Plan & Design

Anatomy of a Virtual MachineEach Virtual Machine is a complete system encapsulated in aset of software areVirtual MachinesESX Server(X86) Physical Server

Candidate SelectionsNon-CandidatesPoor-CandidatesCandidates – requires additional resourcesVirtualizable Candidates

Candidate SelectionsNon-CandidatesApplication requires more resources than can be made availableto a single Virtual Machinemore than 4 active NIC ports, more than 64GB RAM, more than 4 physicalCPUshttp://www.vmware.com/pdf/vi3 35/esx 3/r35u2/vi3 35 25 u2 config max.pdfOS supportabilityhttp://www.vmware.com/pdf/GuestOS guide.pdf

Candidate SelectionsApplication which uses specialized peripherals not supported inVirtual Machinessuch as fax server cards, modems, encryption cards, other specializedPCI/expansion cards, some dongles;Application which uses specialized peripherals for licensingwhich are not supported in VM’ssuch as fax server cards, modems, encryption cards, video capture cards,other specialized PCI/expansion cards, some dongles;

Candidate SelectionsPoor-CandidatesApplications that require a serial connector, or parallel portconnector for the licensingCan mount port to VM, but locked to specific host, No VmotionTape Backup Server – SCSI attachedOnly Adaptec SCSI adaptersGenerally highly utilized - CPU, Memory, Network and DiskTrue Real-time application – one clock cycle to one eventApplications that use hard-core 3D graphics

Candidate SelectionsCandidates – requires additional resourcesApplications that require a USB key for licensingUSB over IP e.g. AnywhereUSB (Digi)Applications that use licensing to a specific MAC addresscan set a static MAC address in the VM’s configuration file (.vmx)

What about therest?

95% ApplicationsAre good candidates for running on VMware Infrastructure

Building yourApplication on VM

95% of Applications Match or Exceed NativePerformance on VMware InfrastructureESX 2Proportion of Apps Performing Well100%OverheadESX 3ESX 3.5Future 30% - 60% 20% - 30% 10% - 20% 2% - 10%VM CPU 1 vCPU 2 vCPU 4 vCPU 8 vCPUVM Memory 3.6 GB 16 GB 64 GB 256 GB 100,000 IOPS 200,000 IOPS 9 GBits 40 GBitsIO 10,000 IOPS 380 MBits 800 MBitsESX Versions

Support Large Oracle DatabasesDatabase Requirementsvs. VI CapacityDisk IOperSecond100,000100K80K60K40KVI supports 80X IOthroughputrequirement ofaverage 4-CPUOracle Database20K1,200DB requirements(4-CPU Oracle DB)VICapacitySource: VMware Capacity Planner analysis of 700,000 servers in customer production environments

Run SAP with 10% Overhead# SDUsersSAP SD ativeVMwareCentraIInstance& DBCentraIInstance& DBCentraIInstance& DB1 vCPU4 Gb2 vCPU8 Gb44 vCPUvCPU1616 GbGb

12-Dec-2007: SAP Support for VMwareProduction Support for Windows and LinuxVMware now a SAP Global Technology Partner[ .]

Server SprawlTypicalSAP DeploymentDevelopmentTrainingQA / TestDevProduction

The Dynamic SAP DatacenterSAP ERP Resource PoolSAP BI Resource PoolTest & Dev Resource PoolSAP HRSAP ERPSAP ERPSAP CRMSAP BITest & DevTest & tionServersApplicationServersRed HatLinuxVirtual MachineWindows2003 ServerVirtual MachineRed HatLinux 64 BitVirtual MachineWindows64 BitVirtual MachineWindows2000 ServerVirtual MachineWindows64 BitVirtual MachineSuSE LinuxVirtual MachineSAP HR SystemSAP ERP ClusterSAP Business IntelligenceSAP Test & Development SystemsVMware VMotion TechnologyVMware ESX ServerVMware ESX ServerVMware InfrastructureStorageNetworkServers

SAP Sizing - GuidelinesStart with small units. Smaller units are better manageable andload balancing is easier.Scale-out instead of scale-up. e.g. deploy additional ApplicationServers if necessaryVirtualization may not fit every customer, but often leaving ahighly utilized Database on a ‚“native“ host and virtualising theremaining components is a viable option.SD Benchmark results are around 400 SD users for 2 vCPU with8GB and around 700 SD users for 4 vCPU with16GB.

Sizing andPerformanceConsiderations

Sizing ConsiderationsBasic Concepts - CPUCPU PerformanceVirtual CPUs map to physical CPU coresMulti-vCPUs from a single VM must be scheduled simultaneouslyConfigure only as many vCPUs as needed Impose unnecessary scheduling constraints on ESX ServerWaste system resources (idle looping, etc.)Idle vCPUs will compete for system resourcesUnavailable pCPUs can result in VM “ready time.”# of total vCPUs 1 # of total cores per ESX hosts (High-Performance)Ensure application is support for multithread if assign multiple Vcpu to singleVM

Sizing dule - 1C- 0C- 1D- 0D- 1Schedule - 2A-0A-1B-0E-0Schedule - 3Contending for CPU resources !

Sizing 4C- 0CPU-5C- 1CPU-6D- 0Optimized VM ratio to pCPU on host!CPU-7D- 1Schedule - 1

Sizing ConsiderationsBasic Concepts - MemoryVAMemory PerformanceService Console: 272 MBVMkernel: 100 MB Per-VM memory space overhead increases with: PANumber of VCPUsSize of guest memoryDo not over allocate – for intensive workloadsMA

Sizing ConsiderationsESX ServerBasic Concepts - NetworkingNetworking PerformanceVirtualMachinesVM3VirtualNICsNIC teamingUse separate NICs to avoidcontentionVSwitchVSwitchUse same virtual switchto connect communicating VMsUse vmxnet virtual device in guestRequires CPU 1000Mbps

Performance Considerations - VM NetworkVirtual SwitchSeparate multiplesubnet into differentvirtual switchReduce network hoopfrom each virtualswitches to improvenetwork efficiencyProper planning onnetwork infrastructureand VM guest IPaddress and subnetStandardize VirtualSwitch name for HA,DRS and VMotionpurposes

Performance Considerations - VM NetworkEnsure Physical NetworkCards is slotted at PCI-X toimprove networkperformanceSeparate the VM networktraffic from Service Consoleand VMkernelReside the VMs whichrequire connectivity to eachothers into same virtualswitches to improveefficiencyMultiple mode of the physicalNIC must match with theswitch configuration

Virtualization Storage Best PracticesStandardize the VMFS datastore size with storage best practices recommended bydifferent storage vendorsAvoid high intensive I/O workload VM guests access to the same datastore at the sametimeAssign separate Virtual Disks and Virtual Controller if require for better managementcapability and performance purposeSelect RDM for huge storage requirement in single volumeAvoid extra multi path if do not require as it will impact the total numbers of LUNs to bepresented to each ESX hostsCreate separate VMkernal for Software ISCSI adaptor or select the right ISCSI HBAcards for ISCSI storage protocolSufficient Swap Space require in each datastore to ensure the allow the memory overcommit on ESX servers

Round RobinRound RobinLoad Balance across allavailable pathsImprove I/Os throughputAvoid Bottleneck on dedicatedpath for performanceperspectiveExperimental at current ESX 3.5

Performance Considerations - Memory ReservationMemoryReservationIncrease physicalmemory respondtimeImprove dataprocessing efficiencyShare value impactthe resources priorityto VMOnly reserve ifneeded

Performance Considerations - CPU ReservationCPU ReservationCPU reserve for HighCPU contending VMImprove performanceReduce available CPUprocessing power tothe rest of VM onsame ESX HostOnly reserve theamount which neededShares value willimpact theprioritization of VM inthe ESX host

Performance Considerations - Advance CPUCPU ReservationKeep the setting todefault for hyperthreaded coresharingScheduling Affinityallow specify Vcputo be assigned tospecify physicalCore in ESXserversDistribute workloadto underutilizephysical cores ifneededRecommended tokeep as defaultsetting

Performance Considerations - DRS Best PracticesReside VMs which require communication in same host will reduce communicationlatencySeparate VMs with same functionality to different hosts to maintain maximumavailabilityRight aggressive mode for migration threshold and fully automateEnable EVC to improve VMotion Capability

Time Synchronization – Why is it so important?MS Kerberos implementation allows a 5 minute toleranceActive Directory operations are critically time dependentFile Replication Services (FRS) synchronizes scripts, databasechanges/updates, policies based, in part, on time-stamping

Time SynchronizationNo CPU cycles needed – none given!Clock drifts can be significant in a relatively short periodIdle cycles in a virtual machine is an Active Directory domain’sworst enemyHow do you combat time synchronization issues?More than a 28minute drift!

Time Synchronization–Option A – Using W32TimeUse Windows Time Service – NOT VMware ToolsMicrosoft KB article # 816042 provides instructions for thisprocess1. Modify registry settings on the PDC emulator for the forest root ime\ParametersChange Type REG SZ value from NT5DS to NTPChange NtpServer value from time.windows.com,0x1 to an external stratum 1 time source, olSet\Services\W32Time\ConfigChange AnnounceFlags REG DWORD from 10 to 52. Stop and restart time service – net stop w32time net start w32time3. Manually force update w32tm /resync /rediscover

Time Synchronization–Option B – VMware ToolsModify Windows Time Service – Use VMware ToolsImplement Domain Controllers Group Policy to modify registry:ModifyEnable ESX server NTP daemon to syncwith external stratum NTP sourceVMware Knowledge Base ID# 1339Enable ESX server NTP daemon to sync withexternal. Use VMware Tools time synchronization within the virtual machineNOTE: VMware Tools time sync is designedto play “catch-up”, not slow down!

Time Synchronization - SummaryUse one method or the otherDo NOT use both!!!Decisions should be based on current time managementinfrastructure or organization’s policiesEnsure Multiple NTP servers synchronize option is beenconfigured on each ESX Host

Exchange and MS SVVPOng, Kok LeongSenior Consultant, VMware ASEANe klong@vmware.comm 60-12-4706070w http://www.vmware.com/

Double Capacity of Exchange 2007 HostsNativeVMware Infrastructure8 VM16 core128 GB16 core128 GB8K mailboxes16K mailboxes

Proving to be Better Than NativeThe experiment: 2,000 user Exchange multi-role VMsThe hardware:IBM x3850 M24 x quad-core Intel Xeon 7350128G RAMThe criteria: LoadGen test pass

Scaling Exchange (Natively) On a Single Server8 CoresMax

Single-Server Native Exchange Scaling16K14KMailboxes12K10K8 core max8K6KOutside ofMicrosoftrecommendations5M/mailbox perf.threshold4KHighestPerformance2K246810CPUs (or cores)121416

Multi-VM Scaling of Exchange on VI316K12KBuilding blocks stay withinMicrosoft recommendations: 1,000 mailboxes/core 5MB/mailbox Three building blocksbreaks through previrtual memoryboundaries10KMaximum performance! Five building blocksshatters pre-virtualCPU limitationsMailboxes14K8K5 MB/mailbox perf.6K threshold Eight building blocksenables 16,000usersEight core limitrecommendedby Microsoft4K2K24681012CPUs (or cores)1416VI3 providesnative-matchingperformance andcomplete resourceutilization

Exchange Sizing ConsiderationsConsiderationsDo not over-commit pCPUs when running Exchange VMs.Do not over-allocate vCPUs; try to match the exact workload.If the exact workload is unknown, start with fewer vCPUs initially and increaselater if necessary.Memory pages can be shared across VMs that have similar data (e.g. sameguest OS)Memory can be over-committed, (i.e. allocating more memory to VMs than isphysically available on the ESX Server)Ensure heavily-used VMs not all accessing same LUN concurrently.