[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-11。"],[],[],null,["# Compute best practices\n======================\n\nThis page presents compute best practices for Google Cloud VMware Engine.\n\nSelect the best region for your application\n-------------------------------------------\n\nTo pick the best region for your applications, consider the following factors:\n\n- To minimize network latency and improve the customer experience, select a location that's closest to your users. The Google Cloud console provides a [real-time performance dashboard](/network-intelligence-center/docs/performance-dashboard/how-to/view-google-cloud-latency) that can help you visualize the latency both between regions and between internet users and a Google Cloud region.\n- To maintain application performance, optimize the connectivity to on-premises facilities by selecting the closest Google Cloud region. For multicloud deployments, consider the proximity to the regions of other cloud vendors.\n- To ensure that your applications maintain compliance with regulations, such as [Payment Card Industry (PCI) compliance policies](https://www.pcicomplianceguide.org/faq/) or the [European General Data Protection Regulation (GDPR)](https://gdpr.eu/), select a region that supports those requirements.\n- Costs and pricing vary per region. Ensure that you account for these regional differences when planning your deployment.\n- When selecting a location, some SKUs might be available only in some regions and not in others.\n\nDecide when to choose a multi-region design\n-------------------------------------------\n\nIn the following situations, you might want to deploy to multiple\nVMware Engine private clouds across regions for the same workload or\nproject scope:\n\n- Disaster recovery implementations that use [Site Recovery Manager (SRM)](/vmware-engine/docs/vmware-ecosystem/howto-disaster-recovery-srm) or [Zerto](/vmware-engine/docs/vmware-ecosystem/howto-disaster-recovery-zerto).\n- Applications that require global availability or low latency to their user base.\n- Capacity planning requirements that are region specific.\n\nDesign for zone resilience\n--------------------------\n\nVMware Engine provides zone redundancy in specific regions. In these\nregions, for increased fault tolerance, you can also deploy private clouds as a\n[stretched cluster](/vmware-engine/docs/concepts-stretched-private-cloud).\nFor information about these regions, see the [VMware Engine release notes](/vmware-engine/docs/release-notes).\n\nWhen deployed as a stretch cluster, your private cloud has nodes in two\nindependent zones. You must have an equal number of nodes in each zone to\nsupport this design. Such a design ensures application availability through\nzone resilience and [VMware vSphere High Availability](https://www.vmware.com/products/vsphere/high-availability.html).\n\nWhen provisioning a stretched private cloud, VMs might run on both sides of a\nstretched private cloud. Use\n[affinity rules](https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-resource-management/GUID-793013E2-0976-43B7-9A00-340FA76859D0.html)\nto control the placement of workload VMs on hosts within a cluster by grouping\nthem and pinning them to a site. Such a design assures zone resilience through\napplication high availability (HA).\n\nSegregate environments across several private clouds\n----------------------------------------------------\n\nA private cloud is an independent VMware Cloud Foundation stack managed by a\nvCenter Server.\n\nYou can segregate your VMware Engine footprint across multiple\nprivate clouds. For example, use a dedicated vCenter Server in the following\ncases:\n\n- For a specific workload type, such as [Virtual Desktop Infrastructure (VDI)](https://www.vmware.com/products/horizon.html)\n- When the [limits of a private cloud](/vmware-engine/docs/concepts-vmware-components#vsphere-limits) are inadequate\n- For licensing and software management\n- For cost transparency and simplicity\n- For monitoring\n- For compliance with regulatory requirements\n- For multi-tenancy at all layers, including management components and infrastructure\n\nTo avoid the unnecessary proliferation of management endpoints, use only the\nrequired number of private clouds.\n\nOptimize the core count\n-----------------------\n\nVMware Engine lets you reduce the number of effective\nCPU cores that are exposed to the ESXi hypervisor.\nThis might be desirable, or required, under some software license agreements.\n\nReducing the core count of the first cluster is not recommended because it\nhosts key components, such as vCenter and NSX Manager.\n\nReducing the number of effective cores in a cluster does not change the cost of\nrunning the cluster, specifically for Oracle workloads. For more information,\nsee the guidance regarding [support and licensing](/vmware-engine/docs/concepts-third-party-solutions).\n\nFor more information, see [Custom core count limitations](/vmware-engine/docs/concepts-private-cloud#custom-core-count-limits).\n\nAdd spare nodes for resilience\n------------------------------\n\nVMware Engine clusters should be sized to have at least one\nspare node for resilience. This spare node is available to the cluster and can\nprovide additional capacity and resources during times of high load or\ncontention. These spare nodes are billed as part of the existing private cloud.\n\nIf higher reliability is required, consider adding more spare nodes to the\ncluster to be available during maintenance windows. Scheduling workloads to run\non these spare nodes helps optimize the use of the clusters in private clouds.\n\nDefine the number of failures to tolerate\n-----------------------------------------\n\nFor [VMware vSAN](https://docs.vmware.com/en/VMware-vSAN/index.html), use the\nFailures to tolerate (FTT) attribute in [vSAN storage policies](/vmware-engine/docs/concepts-vmware-components#vsan_storage_policies)\nto define the number of failures that a cluster can tolerate without affecting\nits data integrity or VM availability.\n\nThe higher the FTT value, the more the capacity hosts that are required.\n\nWhat's next\n-----------\n\n- Read about best practices for [networking](/vmware-engine/docs/best-practices-networking), [security](/vmware-engine/docs/best-practices-security), [storage](/vmware-engine/docs/best-practices-storage), [migration](/vmware-engine/docs/best-practices-migration), and [costs](/vmware-engine/docs/best-practices-costs).\n- Read about [Private cloud VMware Engine components](/vmware-engine/docs/concepts-vmware-components).\n- Try out VMware Engine. Visit [features, benefits, and use\n cases](/vmware-engine/docs/overview) for more information.\n- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Visit [Cloud Architecture Center](/architecture) for more information."]]
