VMware虛擬化最佳實(shí)踐及規(guī)劃

虛擬化最佳實(shí)踐及規(guī)劃議程應(yīng)用實(shí)施范圍考慮服務(wù)器采購考慮虛擬機(jī)部署考慮管理維護(hù)考慮議程應(yīng)用實(shí)施范圍考慮服務(wù)器采購考慮虛擬機(jī)部署考慮管理維護(hù)考慮應(yīng)用實(shí)施范圍總體原則不適合采用虛擬化的應(yīng)用具有特殊硬件訪問要求的應(yīng)用高性能圖形顯卡

不適用虛擬化

特殊的串/并行加密設(shè)備不適用虛擬化USB設(shè)備連接需求

可能不適用，可采用外置USB設(shè)備代替，需經(jīng)過測試即使在高配置的服務(wù)器上仍然具有很高負(fù)載的應(yīng)用

可能不適用，需分析當(dāng)前服務(wù)器配置情況可以采用虛擬化的應(yīng)用除上述不適合采用虛擬化的應(yīng)用之外的所有應(yīng)用可根據(jù)應(yīng)用遷移的復(fù)雜程度決定虛擬化先后順序較易實(shí)現(xiàn)P2V的應(yīng)用可先做遷移，如可用Converter工具直接遷移的應(yīng)用較難或不能做P2V遷移的應(yīng)用可考慮采用重新安裝方式后遷根據(jù)管理的需要決定是否做虛擬化虛擬化轉(zhuǎn)變過程對現(xiàn)有業(yè)務(wù)的影響程度轉(zhuǎn)變?yōu)樘摂M化后對現(xiàn)有管理的影響程度部門之間協(xié)調(diào)的難易程度虛擬化宿主服務(wù)器的部署類型垂直擴(kuò)展與水平擴(kuò)展部署模式不同資源池的“量子化”模型物理主機(jī)HypervisorVMOSAppVMOSAppVMOSAppVMOSAppVMOSAppVMOSAppVMOSAppVMOSAppVMOSAppPhysicalHostHypervisorVMOSAppVMOSAppVMOSAppPhysicalHostHypervisorVMOSAppVMOSAppVMOSApp物理主機(jī)HypervisorVMOSAppVMOSAppVMOSApp不同資源池的類型垂直擴(kuò)展的主機(jī)模式提供更大的連續(xù)性資源空間更容易滿足不同負(fù)載的吻合性要求可提供更高的資源利用率水平擴(kuò)展的集群主機(jī)模式更像是一組小池子的集合多組小容量資源池需要更多的監(jiān)控管理模塊化使用既有優(yōu)點(diǎn)也有缺點(diǎn)影響虛擬化部署的參數(shù)體系功能的多樣化服務(wù)器的重要性獨(dú)立服務(wù)器不重要重要(獨(dú)立的,本地存儲等等)(群集的,多主機(jī)的等等)服務(wù)器農(nóng)場(水平擴(kuò)展服務(wù)器群集，公用服務(wù)器等等)(后端辦公,本地應(yīng)用等等)負(fù)載約束技術(shù)約束商業(yè)約束困難度增加負(fù)載約束不同的資源組都需要分別考慮CPU利用率磁盤I/O網(wǎng)絡(luò)I/O內(nèi)存利用率虛擬化造成的額外負(fù)載通常也要做一定考慮，如磁盤和網(wǎng)絡(luò)的I/O會增加CPU的負(fù)擔(dān)iSCSI存儲訪問也會增加CPU負(fù)擔(dān)運(yùn)維的周期性負(fù)載變化也必須考慮進(jìn)來月末負(fù)載變化年末負(fù)載變化技術(shù)約束技術(shù)約束通常主要是指：兼容性（指系統(tǒng)/應(yīng)用的兼容性）關(guān)聯(lián)性（如系統(tǒng)是摩格邏輯組的一部分）大部分環(huán)境下，這些約束包括了：網(wǎng)絡(luò)連接（子網(wǎng)段級別）應(yīng)用之間的互連性相關(guān)的存儲使用技術(shù)所用的硬件和外設(shè)軟件支持度和認(rèn)證這些約束條件根據(jù)虛擬化在內(nèi)核上下實(shí)現(xiàn)的不同而有所不同共享與分離OS鏡像模式商業(yè)和流程的約束規(guī)模較小或集中的情況下容易被忽略的約束在實(shí)驗(yàn)室的測試環(huán)境可以不考慮，但生產(chǎn)環(huán)境必須要考慮在虛擬化中常見的商業(yè)和流程約束包括：維護(hù)窗口和凍結(jié)改變地理位置和其他物理限制運(yùn)維環(huán)境，安全區(qū)域，應(yīng)用分層部署考慮商業(yè)組織，部門以及客戶法規(guī)政策的考慮與限制忽視這些約束條件將可能導(dǎo)致不可預(yù)知的結(jié)果具體情況具體分析，根據(jù)目標(biāo)制定計(jì)劃議程程應(yīng)用用實(shí)實(shí)施施范范圍圍考考慮慮服務(wù)務(wù)器器采采購購考考慮慮虛擬擬機(jī)機(jī)部部署署考考慮慮管理理維維護(hù)護(hù)考考慮慮虛擬擬化化中中使使用用的的硬硬件件應(yīng)應(yīng)滿滿足足兼兼容容性性列列表表要要求求ESX服務(wù)務(wù)器器硬硬件件配配置置考考慮慮要要點(diǎn)點(diǎn)–CPUsESX調(diào)度度CPU周期期滿滿足足虛虛擬擬機(jī)機(jī)和和ServiceConsole的處處理理請請求求可用用的的CPU目標(biāo)標(biāo)數(shù)數(shù)量量越越多多，，ESX管理理這這個(gè)個(gè)調(diào)調(diào)度度機(jī)機(jī)制制的的效效果果越越好好（單單臺臺服服務(wù)務(wù)器器配配置置8個(gè)以以上上的的CPU核會會有有最最好好的的效效果果）超線線程程技技術(shù)術(shù)并并不不能能提提供供等等同同于于多多核核處處理理器器的的好好處處；；建建議議關(guān)關(guān)閉閉CPU的超超線線程程功功能能（（如如果果有有的的話話））使用用具具有有EM64T能力力的的IntelVT或AMDV技術(shù)術(shù)的的CPU可以以同同時(shí)時(shí)支支持持運(yùn)運(yùn)行行32位和和64位的的虛虛擬擬機(jī)機(jī)采用用同同一一廠廠商商、、同同一一產(chǎn)產(chǎn)品品家家族族和和同同一一代代處處理理器器的的服服務(wù)務(wù)器器組組成成的的集集群群，，可可以以獲獲得得最最好好的的VMotion兼容容能能力力ES的EnhancedVMotion兼容容性性擴(kuò)擴(kuò)大大了了原原有有VMotion的兼兼容容能能力力-《AlleviatingConstraintswithResourcePoolsLiveMigrationwithEnhancedVMotion》》參見見《BestPracticesforSuccessfulVIDesign》》ESX服務(wù)務(wù)器器硬硬件件配配置置考考慮慮要要點(diǎn)點(diǎn)-內(nèi)存存內(nèi)存存資資源源往往往往比比CPU資源源更更會會成成為為潛潛在在的的瓶瓶頸頸在某某些些時(shí)時(shí)候候，，虛虛機(jī)機(jī)環(huán)環(huán)境境的的內(nèi)內(nèi)存存使使用用量量可可能能會會超超過過物物理理內(nèi)內(nèi)存存值值：：Hostswapfile(盡量量少少用用以以獲獲得得最最佳佳性性能能)TransparentPageSharing（多多個(gè)個(gè)虛虛機(jī)機(jī)共共享享相相同同內(nèi)內(nèi)存存頁頁面面））注意意服服務(wù)務(wù)器器特特定定的的內(nèi)內(nèi)存存配配置置要要求求DIMMsizes,bankpairing,parity,upgradeconsiderations(mixandmatchorforkliftreplacement)盡可可能能將將服服務(wù)務(wù)器器配配置置到到最最大大內(nèi)內(nèi)存存，，采采用用最最大大容容量量的的內(nèi)內(nèi)存存條條（（特特別別是是當(dāng)當(dāng)沒沒有有配配滿滿全全部部內(nèi)內(nèi)存存條條時(shí)時(shí)））參見見《BestPracticesforSuccessfulVIDesign》》虛擬擬架架構(gòu)構(gòu)的的基基本本網(wǎng)網(wǎng)絡(luò)絡(luò)連連接接部部件件組組成成(Managementvirtualmachine)(Vmotion,iSCSI,NFS)(VMconnectivity)PortGroupPortGroupPortGroupESX服務(wù)務(wù)器器硬硬件件配配置置考考慮慮要要點(diǎn)點(diǎn)-網(wǎng)絡(luò)絡(luò)參見見《BestPracticesforSuccessfulVIDesign》》最少少配配置置一一個(gè)個(gè)虛虛擬擬交交換換機(jī)機(jī)，，測測試試環(huán)環(huán)境境可可用用2個(gè)虛擬交交換機(jī)，，生產(chǎn)環(huán)環(huán)境建議議最少配配置3個(gè)虛擬交交換機(jī)虛擬交換換機(jī)可同同時(shí)支持持3種類型的的端口組組(ServiceConsole,VMkernel,VM)建議將ServiceConsole、VMkernel和虛機(jī)端端口組各各自使用用自己的的虛擬交交換機(jī)可用VLAN技術(shù)分割割不同的的端口組組對于使用用VMotion和DRS功能的服服務(wù)器集集群，網(wǎng)網(wǎng)絡(luò)配置置應(yīng)該相相匹配（虛擬交交換機(jī)的的數(shù)量與與網(wǎng)絡(luò)卷卷標(biāo)名應(yīng)應(yīng)保持一一致）ESX服務(wù)器ServiceConsole使用固定定IP，配置正正確的speed和duplex。ESX服務(wù)器硬硬件配置置考慮要要點(diǎn)-網(wǎng)絡(luò)-虛擬交換換機(jī)和端端口組參見《BestPracticesforSuccessfulVIDesign》ESX服務(wù)器，，虛擬交交換機(jī)，，物理網(wǎng)網(wǎng)卡出于冗余余的考慮慮，每個(gè)個(gè)虛擬交交換機(jī)建建議至少少分配兩兩個(gè)物理理網(wǎng)卡每個(gè)ESX服務(wù)器的的物理網(wǎng)網(wǎng)卡/口數(shù)量取取決于準(zhǔn)準(zhǔn)備配置置的虛擬擬交換機(jī)機(jī)的數(shù)量量如果3種類型的的端口組組（SC,VMkernel,VM）都在不不同的虛虛擬交換換機(jī)上，，生產(chǎn)環(huán)環(huán)境建議議至少6個(gè)物理網(wǎng)網(wǎng)卡/口如果給包包含虛擬擬機(jī)端口口組的虛虛擬交換換機(jī)分配配更多的的物理網(wǎng)網(wǎng)卡/口，可以以獲得負(fù)負(fù)載均衡衡的好處處ESX服務(wù)器硬硬件配置置考慮要要點(diǎn)-網(wǎng)絡(luò)基本本組件參見《BestPracticesforSuccessfulVIDesign》物理網(wǎng)卡卡/口與物理理交換機(jī)機(jī)同一個(gè)虛虛擬交換換機(jī)上的的不同物物理網(wǎng)卡卡/口應(yīng)連接接到不同同的物理理交換機(jī)機(jī)上將一個(gè)集集群中所所有服務(wù)務(wù)器的VMotion功能端口口組所使使用的物物理網(wǎng)卡卡/口都連到到同一套套物理交交換機(jī)上上（同樣遵遵循上述述第一條條規(guī)則））ESX服務(wù)器硬硬件配置置考慮要要點(diǎn)-與物理網(wǎng)網(wǎng)絡(luò)的連連接參見《BestPracticesforSuccessfulVIDesign》Example1:BladeServerwith2NICPortsvSwitchvmnic0SCvmkernelActiveStandbyvmnic1CandidateDesign:TeambothNICportsCreateonevirtualswitchCreatethreeportgroups:UseActive/StandbypolicyforeachportgroupPortgroup1:ServiceConsole(SC)Portgroup2:VMotionPortgroup3:VMtrafficUseVLANtrunkingTrunkVLANs10,20,30oneachuplinkPortgroup1

VLAN10Portgroup3

VLAN30Portgroup2

VLAN20VLANTrunks(VLANs10,20,30)Example2:Serverwith4NICPortsvmnic0SCvmkernelActiveStandbyvmnic1CandidateDesign:CreatetwovirtualswitchesTeamtwoNICstoeachvSwitchvSwitch0(useactive/standbyforeachportgroup):Portgroup1:ServiceConsole(SC)Portgroup2:VMotionvSwitch1(useOriginatingVirtualPortID)Portgroup3:VMtraffic#1Portgroup4:VMtraffic#2UseVLANtrunkingvmnic1andvmnic3:TrunkVLANs10,20vmnic0andvmnic2:TrunkVLANs30,40Portgroup4

VLAN40VLANs10,20vSwitch0Portgroup1

VLAN10Portgroup2

VLAN20vSwitch1vmnic2vmnic3Portgroup3

VLAN30VLANs30,40Example3:Serverwith4NICPorts(SlightVariation)vmnic0SCvmkernelActiveStandbyvmnic1CandidateDesign:CreateonevirtualswitchCreatetwoNICteamsvSwitch0(useactive/standbyforportgroups1&2):Portgroup1:ServiceConsole(SC)Portgroup2:VmotionUseOriginatingVirtualPortIDforPortgroups3&4Portgroup3:VMtraffic#1Portgroup4:VMtraffic#2UseVLANtrunkingvmnic1andvmnic3:TrunkVLANs10,20vmnic0andvmnic2:TrunkVLANs30,40VLANs10,20vSwitch0Portgroup1

VLAN10Portgroup2

VLAN20vmnic2vmnic3Portgroup3

VLAN30VLANs30,40Portgroup4

VLAN40ServerswithMoreNICPortsMorethan4NICPorts——DesignConsiderationsWithTrunks(VLANtagging):UsepreviousapproachandscaleuptomeetadditionalbandwidthandredundancyrequirementsAddNICstoNICteamsupportingVMtrafficVLANTaggingalwaysrecommended,butoptionsifNICsavailable:DedicatedNICforVMotionAtleastoneNICDedicatedNICsforIPStorage(NFSand/oriSCSI)UsuallytwoteamedNICs(considerIP-hashðerchannelifmultipledestinations

andMulti-ChassisEtherchannelemployedonphysicalswitches)DedicatedNIC(s)forServiceConsoleAtleasttwoforavailabilityNote:easytoconsumemanyphysicalNICsandswitchportsifnotusingVLANtaggingESX服務(wù)器硬件件配置考慮慮要點(diǎn)-存儲應(yīng)盡可能采采用外置共共享磁盤陣陣列存放虛虛擬機(jī)文件件ESX服務(wù)器內(nèi)置置硬盤應(yīng)有有充分的冗冗余，建議議采用RAID1ESX服務(wù)器自身身對硬盤要要求，安裝裝時(shí)的Partition劃分：不建議用安安裝時(shí)的自自動硬盤劃劃分方法，，因?yàn)?、/var、/home會放再同一一個(gè)目錄下下，當(dāng)/(root)滿了時(shí)，ESX服務(wù)器會發(fā)發(fā)生嚴(yán)重問問題。建議議：/boot 50到100MB(PrimaryPartition)/ 8.0到18GB(PrimaryPartition)(swap) 2倍的ServiceConsole內(nèi)存,建議固定使使用1.6G/var4GB或更大建議足夠的的ESX服務(wù)器程序序空間大小小為18GB本地端的ISO以及其他文文本文件的的存放空間間要考慮存儲對于虛虛擬機(jī)的呈呈現(xiàn)方式7VM層數(shù)據(jù)存儲存儲陣列SCSI控制器虛擬磁盤呈呈現(xiàn)為SCSI控制器SCSI控制器顯示示為BUS或LSILogic磁盤控制器器一個(gè)VM可具有1到4個(gè)虛擬LSILogic或BusLogicSCSI適配器每個(gè)SCSI適配器包含含1到15個(gè)虛擬SCSI存儲設(shè)備虛擬磁盤駐駐留在可格格式化為VMFS、NFS或裸磁盤的的數(shù)據(jù)存儲儲中文件系統(tǒng)類類型由底層層物理磁盤盤驅(qū)動器器確確定VMFSNFSFCiSCSINAS卷、數(shù)據(jù)存存儲和LUN卷存儲陣列數(shù)據(jù)存儲8LUN1020GBLUN是一個(gè)邏輯輯空間可由存儲陣陣列的整個(gè)個(gè)空間創(chuàng)建建，也可由由其中的部部分空空間創(chuàng)建LUN映射到ESX后即成為卷卷當(dāng)卷被格式式化為某種種文件系統(tǒng)統(tǒng)之后即成成為數(shù)據(jù)存存儲不能在同一一個(gè)LUN中混用不同同類型的文文件系統(tǒng)每個(gè)LUN對應(yīng)一個(gè)VMFS卷虛擬機(jī)內(nèi)容容位于數(shù)據(jù)據(jù)存儲中數(shù)據(jù)存儲ESX數(shù)據(jù)存儲類類型：VMware文件系統(tǒng)（VMFS）使用VMFS的RDM網(wǎng)絡(luò)文件系系統(tǒng)（NFS）卷VM內(nèi)容ESX主機(jī)數(shù)據(jù)存儲采采用某種文文件系統(tǒng)格格式可以像操作作文件一樣樣操作數(shù)據(jù)據(jù)存儲每個(gè)系統(tǒng)具具有256個(gè)VMFS數(shù)據(jù)存儲每個(gè)系統(tǒng)具具有8個(gè)NFS數(shù)據(jù)存儲ISO映像、VM模板和軟盤盤映像9虛擬機(jī)內(nèi)容容文件名說明<VM名稱>.vmxVM配置<VM名稱>.vmdk虛擬磁盤<VM名稱>-flat.vmdk預(yù)分配的虛擬磁盤文件（包含數(shù)據(jù)）<VM名稱>.vswp交換文件nvram非易失性RAM文件<VM名稱>.vmemVM內(nèi)存<VM名稱>.vmssVM掛起文件<VM名稱>.vmsd快照數(shù)據(jù)<VM名稱>-Snapshot.vmsn快照狀態(tài)文件VMware-0.log、vmware-1.log等日志文件10文件夾/子目錄數(shù)據(jù)存儲類類型數(shù)據(jù)存儲VMFS數(shù)據(jù)存儲VMFS數(shù)據(jù)存儲NFSIP網(wǎng)絡(luò)VM內(nèi)容VM內(nèi)容FC交換機(jī)光纖通道SAN磁盤陣列iSCSISAN磁盤陣列NAS磁盤陣列VM1ESX主機(jī)1VM2VM1ESX主機(jī)2VM2VM內(nèi)容VM3VM312本地SCSIVMDKIP交換機(jī)ESX服務(wù)器建議議配置-新購為了盡可能能的發(fā)揮虛虛擬化的作作用，最大大限度的利利用單臺服服務(wù)器的資資源，建議議用于虛擬擬化宿主服服務(wù)器的配配置應(yīng)達(dá)到到或超過如如下標(biāo)準(zhǔn)：：服務(wù)器CPU路數(shù)雙路四路八路CPU（建議主頻2GHz以上）雙路四核四路雙核或四核四路雙核或四核+內(nèi)存16GB+32GB+64GB+千兆網(wǎng)口無外接存儲4+/6+4+/6+4+/6+使用FC存儲4+/6+4+/6+4+/6+使用IP存儲6+/8+6+/8+6+/8+FCHBA口（建議4Gb或8Gb產(chǎn)品）222內(nèi)置硬盤（使用外置磁盤陣列時(shí)）222電源雙冗余雙冗余雙冗余從性價(jià)比和和可用性考考慮，不建建議在單路路服務(wù)器上上部署虛擬擬化虛擬化宿主主服務(wù)器建建議配置-現(xiàn)有對于目前業(yè)業(yè)內(nèi)用的比比較多的四四路服務(wù)器器，建議議如下：四路單核服服務(wù)器：運(yùn)運(yùn)算能力較較弱，虛機(jī)機(jī)數(shù)量應(yīng)控控制在10個(gè)以內(nèi)，內(nèi)內(nèi)存配置建建議在12GB-16GB；四路雙核服服務(wù)器：運(yùn)運(yùn)算能力中中等，虛機(jī)機(jī)數(shù)量可做做到10-15個(gè)左右，內(nèi)內(nèi)存配置建建議在16GB-24GB；四路四核服服務(wù)器：運(yùn)運(yùn)算能力強(qiáng)強(qiáng)勁，虛機(jī)機(jī)數(shù)量可做做到15-30個(gè)左右，內(nèi)內(nèi)存配置建建議在24GB-32GB。VC服務(wù)器最佳佳配置建議議處理器：2.0GHz或更高的Intel或AMDx86處理器，VC支持多處理理，可支持持至多2個(gè)CPU。內(nèi)存：最低低需求為2GB，假使數(shù)據(jù)據(jù)庫和VC安裝于同一一臺，建議議增加至4GB。磁盤空間：：最小為560MB，建議2GB。網(wǎng)卡：建議議用Gigabit。最低硬件配配置單個(gè)2GHzCPU，2GB內(nèi)存，千兆兆網(wǎng)口可支持20個(gè)同時(shí)連接接，管理50臺物理機(jī)，，1000個(gè)虛擬機(jī)左左右建議配置雙CPU，4GB內(nèi)存，千兆兆網(wǎng)口可支持50個(gè)同時(shí)連接接，管理200臺物理機(jī)，，2000個(gè)虛擬機(jī)左左右議程應(yīng)用實(shí)施范范圍考慮服務(wù)器采購購考慮虛擬機(jī)部署署考慮管理維護(hù)考考慮虛機(jī)個(gè)數(shù)的的規(guī)劃單臺服務(wù)器器所能支持持虛機(jī)數(shù)量量的決定因因素：服務(wù)器的硬硬件配置CPU性能多核高主頻頻技術(shù)使得得CPU成為性能瓶瓶頸的可能能性越來越越低內(nèi)存大小做為硬指標(biāo)標(biāo)的內(nèi)存，，配置越高高，所能支支持的虛機(jī)機(jī)數(shù)量越多多網(wǎng)絡(luò)端口千兆網(wǎng)環(huán)境境已很普遍遍，網(wǎng)絡(luò)帶帶寬大多有有保證，更更多從管理理角度來考考慮HBA卡磁盤訪問性能能對虛機(jī)數(shù)量量有一定影響響，建議采用用4Gb或8GbHBA卡以減少鏈路路影響本地磁盤內(nèi)置磁盤的可可用性及IO吞吐能力均較較弱，不建議議在其上存放放虛擬機(jī)，推推薦使用外置置高性能磁盤盤陣列應(yīng)用負(fù)載大小小由于物理服務(wù)務(wù)器資源自身身的最大限制制，應(yīng)用負(fù)載載越大，所能能同時(shí)運(yùn)行的的虛機(jī)數(shù)量越越少建議將不同應(yīng)應(yīng)用訪問特性性的應(yīng)用混合合部署在同一一物理服務(wù)器器上靈活運(yùn)用DRS和VMotion技術(shù)可將物理理機(jī)與虛機(jī)的的比率關(guān)系調(diào)調(diào)到最優(yōu)考慮到HA及DRS所要求的資源源冗余，所有有運(yùn)行虛機(jī)在在正常負(fù)載下下，總體資源源使用率不超超過三分之二二會比較合適適經(jīng)驗(yàn)值：雙路路四核10個(gè)虛機(jī)左右，，四路四核15-30個(gè)虛機(jī)（僅為為參考）虛機(jī)資源的分分配CPU、內(nèi)存CPU分配原則：盡量使用最少少的vCPUs，如果是單線線程應(yīng)用，不不支持多線程程處理，請不不要使用virtualSMP虛擬CPU數(shù)量不要等于于或超過物理理CPU核數(shù)，如雙路路雙核服務(wù)器器配置的虛機(jī)機(jī)最多使用兩兩個(gè)虛擬CPU當(dāng)配置虛擬機(jī)機(jī)的時(shí)候須了了解ESX服務(wù)器本身也也有一些overhead。需注意不要要超過所有虛虛擬機(jī)使用率率和所有vCPU匯總數(shù)目。觀察”idleloopspin”功能參數(shù)，某某些操作系統(tǒng)統(tǒng)當(dāng)它們閑置置時(shí)，并不會會真正的釋放放virtualCPU。確認(rèn)配置了單單一處理器的的虛擬機(jī)為””UPHAL/kernel”，多處理器的的虛擬機(jī)必須須設(shè)定為”SMPHAL/kernel”。內(nèi)存分配原則則：內(nèi)存總量為在在資源評估后后，計(jì)算虛擬擬機(jī)評估結(jié)果果所需實(shí)際物物理內(nèi)存的總總和，其他由由于應(yīng)用程序序而產(chǎn)生的更更多內(nèi)存需要要可以用ESX的磁盤內(nèi)存來來解決關(guān)鍵應(yīng)用可考考慮固定內(nèi)存存的方法以保保證性能的穩(wěn)穩(wěn)定性DRSBestPractices:HardwareConfigurationEnsurehostsareCPUcompatibleIntelvsAMDSimilarCPUfamily/SSE3statusEnhancedVMotionCompatibility(EVC)“VMwareVMotionandCPUCompatibility”whitepaperCPUincompatibility=>limitedDRSVMmigrationoptionsLargerHostCPUandmemorysizepreferredforVMplacement(ifallequal)Differencesincacheormemoryarchitecture=>inconsistencyinperformanceDRSBestPractices:ClusterConfigurationHighernumberofhosts=>moreDRSbalancingoptionsRecommendupto32hosts/clusterMayvarywithVCserverconfigurationandVM/hostratioNetworkconfigurationonallhostsVMotionnetwork:Securitypolicies,VMotionnicenabled,GigEnetwork,etcVirtualMachinenetworkpresentonallhostsVMdatastoresharedacrossallhostsVMfloppy/CDconnectedtohostdeviceDRSBestPractices:VMResourceSettingsReservations,Limits,andSharesSharestakeeffectduringresourcecontentionLowlimitscanleadtowastedresourcesHighVMreservationsmaylimitDRSbalancingOverheadmemoryUseresourcepools(RP)forbettermanageabilityVirtualCPU’sandMemorysizeHighmemorysizeandvirtualCPU’s=>fewermigrationopportunitiesConfigureVMsbasedonneedDRSBestPractices:AlgorithmSettingsAggressivenessthresholdModeratethreshold(default)workswellformostcasesAggressivethresholdsrecommendedifHomogenousclustersandVMdemandrelativelyconstantandFewaffinity/anti-affinityrulesUseaffinity/anti-affinityrulesonlywhenneedAffinityrules:closelyinteractingVMsAnti-affinityrules:I/Ointensiveworkloads,availabilityAutomaticDRSmoderecommended(cluster-wide)Manual/Partiallyautomaticmodeforlocation-criticalVMs(perVM)PerVMsettingoverridescluster-widesettingHABestPractices-Setup&NetworkingProperDNS&NetworksettingsareneededforinitialconfigurationAfterconfigurationDNSresolutionsarecachedto/etc/FT_HOSTS(minimizingthedependencyonDNSserveravailabilityduringanactualfailover)DNSoneachhostispreferred(manualeditingof/etc/hostsiserrorprone)RedundancytoESXServiceConsolenetworkingisessential(severaloptions)ChoosetheoptionthatminimizessinglepointsoffailureGateways/isolationaddressesshouldrespondviaICMP(ping)EnablePortFast(orequivalent)onnetworkswitchestoavoidspanningtreerelatedisolationsNetworkmaintenanceactivitiesshouldtakeintoaccountdependenciesontheESXServiceConsolenetwork(s)VMwareHAcanbetemporarilydisabledthroughtheCluster->EditSettingsdialogValidVMnetworklabelnamesrequiredforproperfailoverVirtualmachinesusethemtore-establishnetworkconnectivityuponrestartHANetworkConfigurationAsingleserviceconsolenetworkwithunderlyingredundancyisusuallysufficient:Useateamof2NICsconnectedtodifferentphysicalswitchestoavoidasinglepointoffailureConfigurevNicsinvSwitchforActive/Standbyconfiguration(rollingfailover=““yes”,defaultloadbalancing=routebasedonoriginatingportID)Considerextendingtimeoutvalues&addingmultipleisolationaddresses(*seeappendix)Timeoutsof30-60secondswillslightlyextendrecoverytimes,butwillalsoallowforintermittentnetworkoutagesNetworkredundancybetweentheESXserviceconsolesisessentialforreliabledetectionofhostfailures&isolationconditionsHANetworkConfiguration(Continued)HAwilldetectanduseasecondaryserviceconsolenetworkAddingasecondaryserviceconsoleportgrouptoanexistingVMotionvSwitchavoidshavingtodedicateanadditionalsubnet&NICforthispurposeAlsoneedtospecifyanadditionalisolationaddressfortheclustertoaccountfortheaddedredundancy(*seeappendix)Continueusingtheprimaryserviceconsolenetwork&IPaddressformanagementpurposesBecarefulwithnetworkmaintenancethataffectstheprimaryserviceconsolenetworkandthesecondary/VMotionnetworkBeyondNICteaming,asecondaryserviceconsolenetworkcanbeconfiguredtoprovideredundantheartbeating&isolationdetectionHABestPractices–ResourceManagementLargergroupsofhomogenousserverswillallowhigherlevelsofutilizationacrossanHA/DRSenabledcluster(onaverage)Morenodespercluster(currentmaximumis16)cantoleratemultiplehostfailureswhilestillguaranteeingfailovercapacitiesAdmissioncontrolheuristicsareconservativelyweighted(sothatlargeserverswithmanyVMscanfailovertosmallservers)Todefinethesizingestimatesusedforadmissioncontrol,setreasonablereservationsastheminimumresourcesneededAdmissioncontrolwillexceedfailovercapacitieswhenreservationsarenotset;otherwiseHAwilluselargestreservationspecifiedasthe““slot”size.Ataminimum,setreservationsforafewvirtualmachinesconsidered““average”AdmissioncontrolmaybetooconservativewhenhostandVMsizesvarywidelyPerformyourowncapacityplanningbychoosing““Allowvirtualmachinestobepoweredoneveniftheyviolateavailabilityconstraints”.HAwillstilltrytorestartasmanyvirtualmachinesasitcan.議程應(yīng)用實(shí)實(shí)施范范圍考考慮服務(wù)器器采購購考慮慮虛擬機(jī)機(jī)部署署考慮慮管理維維護(hù)考考慮ImpactofVirtualCenterDowntimeComponentImpactExperiencedVirtualMachinesUnaffected,managementrequiresdirectconnectionstoESXServersESXServersUnaffected,managementrequiresdirectconnectionstoESXServersPerformance&MonitoringStatisticsHistoricalrecordswillhavegapsduringoutages,stillavailableviaESXServersVMotionUnavailableVMwareDRSUnavailableVMwareHAAgentsunaffected&providefailoverfunctionality,admissioncontrolunavailable參見《BulletproofVirtualCenter-AGuidetoProtectingVirtualCenter》》VirtualCenterComponentsVirtualCenterServerWebAccessLicenseServerADDomainControllerDNSServerDatabaseServer參見《BulletproofVirtualCenter-AGuidetoProtectingVirtualCenter》》VirtualCenter––RecommendedCollocationCollocationofVirtualCentercomponentsisdesirableformostenvironmentsFocusofthissessionisonprovidingprotectionforthesecomponentsIndustrystandardsolutionsassumedforothercomponentsOneServer,PhysicalorVirtualVirtualCenterServerWebAccessLicenseServerADDomainControllerDNSServerDatabaseServer參見《BulletproofVirtualCenter-AGuidetoProtectingVirtualCenter》》VirtualCenterComponents(AdditionalDetails)VirtualCenterService:almoststatelessInformationaboutinventorystoredinthedatabaseSomestatefilesstoredlocallyonVirtualCenterserverWebAccessNostateinformationLicenseServerLicensefilestoredlocally14dayGraceperiodifunavailable參見《BulletproofVirtualCenter-AGuidetoProtectingVirtualCenter》》VirtualCenter––LocalConfigurationFilesOneServer,PhysicalorVirtualVirtualCenterServerWebAccessLicenseServerDatabaseServerSSLCertificateLicenseFileConfig.FileUpgradeFiles參見見《BulletproofVirtualCenter-AGuidetoProtectingVirtualCenter》》Step1forHighAvailability:ProtecttheDatabaseDatabaseoutagewillterminateVirtualCenterserviceAsofVirtualCenter2.0.1Patch2,WindowsServiceManagerwillautomaticallyattempttorestartitevery5minutes,indefinitelyVirtualCenterDatabaseshouldbeindependentlyinstalledandmanagedForlocalavailabilityusethepreferredmechanismforthetypeofdatabasebeingused(VMwareHA,MSCS,Databasespecificmechanisms)Fordisasterrecovery,databaseshouldbereplicatedtoaremotesiteaspartofanoverallDRplan參見見《BulletproofVirtualCenter-AGuidetoProtectingVirtualCenter》》VCVCBang!FailoverStep2forHighAvailability:ProtectVirtualCenterVMwareHAandMicrosoftClusterServices(MSCS)arethetwomostpopularoptionsOther3rdpartysolutionspossible**Supporteddirectlyby3rdpartyOptiona):VMwareHAVirtualinstancesonlySubjecttosharedstorage/networkconstraintsOnlyrequiressingleOS&applicationinstance;noexplicitreplicationOptionb):MSCSVirtualCenter2.0.2patch2orbeyondPhysicalorvirtualinstancesRequires2identicalOS&applicationinstallations;explicitreplicationoffilesInvolvesadditionalconfigurationefforts&ongoingmaintenance參見見《BulletproofVirtualCenter-AGuidetoProtectingVirtualCenter》》VirtualCenter:Physicalvs.VirtualPhysicalVirtualBackupsdoneusingtraditionaltoolsBackupspossiblethroughtraditionaltools,VCB,snapshots,cloning,etc.DedicatedserverrequiredDedicatedservernotrequired,resourcescanbesharedwithothervirtualmachinesPerformancelimitedonlybyserverhardwarePerformancefromsharedresources;tuningmaybeneededVirtualCenterwithVMwareHA:Out-of-BandTwoapproachesTwoVirtualCenterinstancesmanageeachother(pictured)BothruninHAclusterEachmanagestheother’’sHAclusterSeparateVirtualCenterinstanceisusedtomanage2-nodeHAcluster(notpictured)vpxdvpxdVirtualCenterServermanagestheVMwareHAclusterprovidingitsprotectionWhentheESXhostswithVirtualCenterVMfails,VMisrestartedautomaticallybyHAFailoverfunctionalityprovidedbyHAisindependentfromVirtualCenter(post-configuration)vpxdVirtualCenterwithVMwareHA:In-BandVirtualCenterwithMSCS––PhysicalBestpractice:useMajorityNodeSetquorumwithwitnessshareMaybeusedasgeographicallydispersedclusterfordisasterrecoverysolutionVCDBmaybeusedinanotherclustergrouponthesameclusterRequiresathirdnodeEthernetNetworkvcdbvpxdVirtualCenterwithMSCS––VirtualRequiresuseofquorumdiskclustering:QuorumdiskonthesharedstorageSystemdisksforbothclusteredvirtualmachinesonlocalstorageIncompatiblewithVMotionorVMwareHASANLANvpxdRiseofthePhoenix-DisasterRecoveryVirtualCenterServerDatabaseServerVIServicesVIInventoryDatabaseServerStandardDRSolutionStandbyVirtualCenterServerPrimaryReplicationofstatefilesVirtualCenterDisasterRecoveryOverviewDisasterrecoverysolutionconsistsofthreepieces:VIInventorydataUsethestandardDRsolutionofthedatabasevendorVIServicesColdStandby–Re-installVirtualCenterandrestorelocalconfigurationfilesWarmStandby–Pre-installVirtualCenterandsynchronizelocalconfigurationfiles,butkeep2ndinstancedisconnectedAllotherinfrastructureservices:AD,DNS,etc.Useexistingproduct-specificsolutionsColdStandbyRecoveryProcedureAbletoassignprimary’sIPtostandby?MaintainseparateuptodatecopyoflocalconfigurationfilesInstallfresh

VirtualCenterinstanceInstall

configfiles;connecttostandbyDBDisaster!ESXServerhosts

reconnectautomaticallyRunscripttoreconnectallESXServerhostsDoneyesnoWarmStandbyRecoveryProcedureAbletoassignprimary’’sIPtostandby?KeeplocalconfigurationfilessynchronizedbetweenprimaryandstandbyDisaster!ESXServerhostsreconnectautomaticallyRunscripttoreconnectallESXServerhostsDoneyesnoFasterend-to-endrecovery(RTO)AlsoallowsforscriptingandautomationReplicationofconfigurationfilesthroughhost-basedreplicationorbackuptoolsMonitoringIndividualVirtualCenterComponentsEntitySubentityComponentMetricTooltouseVirtualCenterServerVirtualCenterVirtualCenterService-vpxdvpxd.exefoundWMIvpxdisrunningasserviceWMIVirtualCenterCertificatesfilesareexistsWMIsizeWMImodificationdateWMILicenseServerLicenseServerServiceexefileexistsWMIserviceisupandrunningWMILicenseFilesfilesareexistsWMIsizeWMImodificationdateWMIWebServiceWebServiceexefileexistsWMIserviceisupandrunningWMIWebPagehttp://localhostisreachablePerlorvbsscript–HTTPGETcriticalfiles(?)arefoundWMIHostSystem(whereVCisrunningon)SystemCPUload<90%WMISystemdisk<80%FULLWMINetworkOKWMIDatabaseserverODBCConnectionConnectionworksWMIDatabaseintegritySome"select"statementoncriticaltablessqlFileContentsLocationFlexLicensefilesLicensekeysforallserver-basedlicensedfeaturesC:\ProgramFiles\VMware\VMwareLicenseServer\LicensesV