[[["易于理解","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-09-03。"],[],[],null,["# VMware Engine stretched private clouds\n======================================\n\nA Google Cloud VMware Engine stretched private cloud is a private cloud that is\nstretched across two data zones and a witness zone, all within the same Google Cloud region. Stretched private clouds use vSphere and vSAN stretched\nclusters to provide compute and storage high availability against zone-level\nfailures. All clusters of a stretched private cloud are considered VMware Engine stretched clusters, including the primary cluster.\n| **Note:** Once a stretched private cloud is created, it cannot be converted back to a standard private cloud. Additionally, you cannot convert an existing private cloud to a stretched private cloud.\n\nStretched private cloud operation\n---------------------------------\n\nAll of the clusters of a stretched private cloud are stretched across the same\ntwo data zones and share the same witness zone. Each stretched cluster has its\nown set of data nodes in each data zone, and each stretched cluster has a\nwitness node in the witness zone. Stretched qualifies as any two zones in a\ngiven Google Cloud region that are more than 10 Km geodesic distance apart\nbut have less than 5 msec RTT latency between them.\n\nThe witness node is managed by VMware Engine and runs on a\nCompute Engine instance running ESXi in nested mode. You don't need to specify\na witness zone and don't have to manage the lifecycle of the witness node.\n\nEach of the three zones used by a stretched cluster are independent failure\ndomains. The main benefit of this setup is that a cluster stretched across the\nthree zones can survive a complete failure of any single zone.\n\nStretched private cloud node configuration\n------------------------------------------\n\nStretched clusters have an equal number of nodes in data zones. For example,\nthree nodes in each data site - denoted as 3+3, or four nodes in each data site,\ndenoted as 4+4. Configurations such as 4+3, therefore, are not allowed in Google Cloud VMware Engine stretched private clouds. A stretched cluster in Google Cloud VMware Engine must have a minimum of six data nodes (3+3) and a maximum of 32 (16+16) data\nnodes.\n\nStretched private cloud environment\n-----------------------------------\n\nYou manage your stretched private clouds through the Google Cloud console. All\nstretched clusters in a stretched private cloud have half of their capacity in\neach zone - for example, an eight-node stretched cluster in a stretched private\ncloud must have four nodes in each zone. Only an identical number of nodes\nfrom each zone can be added and removed from the stretched clusters. For\nexample, you can add two nodes to each zone or remove three nodes from each zone\nin a stretched cluster.\n\nA stretched private cloud can have multiple stretched clusters, but each must\nhave exactly two Google Cloud zones for data nodes and one zone for the witness\nnode.\n\nvSAN data encryption in stretched private clouds\n------------------------------------------------\n\nvSAN data encryption at rest is enabled by default in all stretched clusters of\na stretched private cloud. By default, a Google key provider is used for vSAN\nencryption. This key provider uses Cloud Key Management Service and is deployed in a highly\navailable configuration across two zones. You can also use any external 3P\nCloud KMS server (deployed as an HA pair across the two zones) and\nmanage it yourself.\n\nStorage policies in stretched private clouds\n--------------------------------------------\n\nThe management VMs of a stretched private cloud run on the first stretched\ncluster (for example, 'cluster 0'). The management VMs are affixed to the\nprimary site of the stretched cluster using affinity rules and are configured\nwith the following storage policy:\n\n- Site Disaster tolerance=1 (protect against one site failure)\n- FTT=1 (for a six-node stretched ('cluster 0'))\n- FTT=2 (for a node stretched greater than or equal to 10 ('cluster 0'))\n\nThe default storage policy in a stretched cluster for workload VMs also follows\nthe previous policy.\n\nYou can create new storage policies for workload VMs, and each stretched cluster\nin a stretched private cloud can use different storage policies.\n\nWhat's next\n-----------\n\n- Learn about [VLANs and subnets](/vmware-engine/docs/concepts-vlans-subnets)."]]
