이 페이지에서는 Google Cloud VMware Engine의 컴퓨팅 권장사항을 설명합니다.
애플리케이션에 가장 적합한 리전 선택
애플리케이션에 가장 적합한 리전을 선택하려면 다음 요소를 고려합니다.
네트워크 지연 시간을 최소화하고 고객 경험을 개선하려면 사용자와 가장 가까운 곳에 위치를 선택합니다. Google Cloud 콘솔은 리전 간 및 인터넷 사용자와 Google Cloud 리전 간 모두에서 지연 시간을 시각화하는 데 도움이 되는 실시간 성능 대시보드를 제공합니다.
애플리케이션 성능을 유지하려면 가장 가까운 Google Cloud 리전을 선택하여 온프레미스 시설에 대한 연결을 최적화합니다.
멀티 클라우드 배포의 경우 다른 클라우드 공급업체 리전과의 근접성을 고려합니다.
VMware Engine은 특정 리전에서 영역 중복성을 제공합니다. 이러한 리전에서 내결함성이 향상될 수 있도록 프라이빗 클라우드를 확장된 클러스터로 배포할 수도 있습니다.
이러한 리전에 대한 자세한 내용은 VMware Engine 출시 노트를 참조하세요.
확장 클러스터로 배포하면 프라이빗 클라우드에 독립 영역 2개의 노드가 있습니다. 이 설계를 지원하려면 각 영역의 노드 수가 동일해야 합니다. 이러한 설계는 영역 복원력과 VMware vSphere 고가용성을 통한 애플리케이션 가용성을 보장합니다.
확장된 프라이빗 클라우드를 프로비저닝할 때 VM은 확장된 프라이빗 클라우드 양쪽에서 실행될 수 있습니다. 어피니티 규칙을 사용하여 클러스터 내 호스트에 있는 워크로드 VM을 그룹하고 한 사이트로 고정해 위치를 제어할 수 있습니다. 이러한 설계는 애플리케이션 고가용성(HA)을 통한 영역 복원력을 보장합니다.
여러 프라이빗 클라우드에서 환경 분리
프라이빗 클라우드는 vCenter Server에서 관리하는 독립적인 VMware Cloud Foundation 스택입니다.
여러 프라이빗 클라우드에서 VMware Engine 사용 공간을 분리할 수 있습니다. 예를 들어 다음과 같은 경우에는 전용 vCenter Server를 사용합니다.
복원력을 고려해 예비 노드가 최소 하나 이상 있도록 VMware Engine 클러스터 크기를 조정해야 합니다. 이 예비 노드는 클러스터에서 사용 가능하며 부하가 높거나 경합이 많은 시간에 추가 용량과 리소스를 제공할 수 있습니다. 이러한 예비 노드에 대한 요금은 기존 프라이빗 클라우드의 일부로 청구됩니다.
더 높은 신뢰성이 필요한 경우 유지보수 기간 중에 사용할 수 있도록 더 많은 예비 노드를 클러스터에 추가하는 것이 좋습니다. 워크로드가 이러한 예비 노드에서 실행되도록 예약하면 프라이빗 클라우드에서 클러스터 사용을 최적화할 수 있습니다.
허용할 수 있는 실패 수 정의
VMware vSAN의 경우 vSAN 스토리지 정책의 허용되는 실패(FTT) 속성을 사용하여 클러스터가 데이터 무결성이나 VM 가용성에 영향을 미치지 않고 허용할 수 있는 실패 수를 정의합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-21(UTC)"],[],[],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."]]
