ESXi 클러스터는 vSphere 고가용성(HA)으로 구성됩니다. 복원력을 고려해 한 개 이상의 예비 노드를 보유하도록 클러스터의 크기를 조정합니다.
vSAN은 중복 기본 스토리지를 제공하며 단일 장애를 방지하기 위해 노드가 3개 이상 필요합니다. 큰 클러스터의 경우 더 높은 복원력을 제공하도록 vSAN을 구성할 수 있습니다.
vCenter, PSC, NSX Manager 가상 머신(VM)은 스토리지 장애를 방지하기 위해 RAID-10 스토리지로 구성됩니다. vSphere HA에서 VM의 노드 및 네트워크 장애를 추가로 방지합니다.
ESXi 호스트에는 중복 팬과 NIC가 있습니다.
TOR 및 스파인 스위치는 복원력을 제공하도록 HA 쌍으로 구성됩니다.
VMware Engine은 업타임을 지속적으로 모니터링하고 가용성을 모니터링한 후 다음 유형의 VM에 가용성 SLA를 제공합니다.
ESXi 호스트
vCenter
PSC
NSX Manager
VMware Engine은 다음 항목에 오류가 있는지 지속적으로 모니터링합니다.
하드 디스크
물리적 NIC 포트
서버
팬
전력
스위치
스위치 포트
디스크 또는 노드에 장애가 발생하면 VMware Engine은 영향을 받는 VMware 클러스터에 새 노드를 자동으로 즉시 추가하여 서비스 운영을 복원합니다.
프라이빗 클라우드의 다음 VMware 요소는 백업, 유지보수, 업데이트됩니다.
ESXi
vCenter 플랫폼 서비스 컨트롤러
vSAN
NSX
백업 및 복원
백업에는 다음이 포함됩니다.
vCenter, PSC, DVS 규칙에 대한 야간 증분 백업
애플리케이션 레이어에서 구성요소를 백업하기 위한 vCenter 기반 API
VMware 관리 소프트웨어를 업데이트하거나 업그레이드하기 전의 자동 백업
유지보수
다음 유형의 계획된 유지보수가 포함됩니다.
백엔드 및 내부 유지보수
백엔드 및 내부 유지보수에는 일반적으로 물리적 애셋 재구성 또는 소프트웨어 패치 설치가 포함됩니다. 서비스 중인 애셋의 일반 소비에는 영향을 주지 않습니다. 각 물리적 랙으로 이동하는 중복 NIC를 사용할 때 일반 네트워크 트래픽 및 프라이빗 클라우드 운영에는 영향을 주지 않습니다. 조직에서 유지보수 간격 중 전체 중복 대역폭 사용이 예상되는 경우에만 성능 영향을 발견할 수 있습니다.
포털 유지보수
제어 영역 또는 인프라를 업데이트할 때는 일부 제한된 서비스 다운타임이 필요합니다. 유지보수 간격은 매월 1회로 빈번하게 수행될 수 있으며 시간 경과에 따라 실행 빈도가 감소할 것으로 예상됩니다.
VMware Engine에서는 임박한 포털 유지보수에 대해 알리고 유지보수 간격을 가능한 한 짧게 유지하도록 최선을 다하겠습니다. 포털 유지보수 간격 중에도 다음 서비스는 영향을 받지 않고 계속 작동합니다.
VMware 관리 영역 및 애플리케이션
vCenter 액세스
모든 네트워킹 및 스토리지
VMware 인프라 유지보수
가끔씩 VMware 인프라의 구성을 변경해야 합니다. 1~2개월마다 변경해야 할 수 있지만 시간이 지나면서 빈도가 감소할 것으로 예상됩니다. 이러한 유형의 유지보수는 일반적으로 일반 프라이빗 클라우드 소비를 방해하지 않고 수행될 수 있습니다. VMware 유지보수 기간 중에 다음 서비스는 아무런 영향 없이 계속 작동합니다.
VMware 관리 영역 및 애플리케이션
vCenter 액세스
모든 네트워킹 및 스토리지
업데이트 및 업그레이드
VMware Engine은 프라이빗 클라우드에서 VMware 소프트웨어(ESXi, vCenter, PSC, NSX)의 수명 주기 관리를 담당합니다.
소프트웨어 업데이트에는 다음이 포함됩니다.
패치: VMware에서 출시한 보안 패치 또는 버그 수정
업데이트: VMware 스택 구성요소의 부 버전 변경사항
업그레이드: VMware 스택 구성요소의 주 버전 변경사항
VMware Engine은 중요 보안 패치가 VMware에서 제공되는 즉시 이를 테스트합니다. SLA에 따라 VMware Engine은 제공 후 1주일 내에 프라이빗 클라우드 환경에 출시할 것을 목표로 합니다.
새로운 주 버전의 VMware 소프트웨어가 출시되면 VMware Engine은 고객과 협력하여 업그레이드 적용에 적합한 유지보수 기간을 조정합니다. VMware Engine은 주 버전이 출시되고 최소 6개월 후에 주 버전 업그레이드를 적용하고 주 버전 업그레이드를 적용하기 1개월 전에 고객에게 알립니다.
또한 주 버전 업그레이드를 시작하기 전에 VMware Engine은 주요 업계 공급업체와 협력하여 최신 VMware 소프트웨어 버전을 지원하는지 확인합니다. 특정 공급업체의 지원에 대한 자세한 내용은 Cloud Customer Care에 문의하세요.
인증서 업데이트 책임
인증서 업데이트는 Google에서 담당합니다. 인증서 업데이트 오류가 발생하면 별도의 조치가 필요 없으며 인증서는 만료 전에 갱신됩니다. 하지만 LDAPS가 프라이빗 클라우드에 구성된 경우 해당 오류와 연결된 특정 인증서에 대한 책임은 전적으로 개발자에게 있습니다.
준비
업데이트 또는 업그레이드를 시작하기 전에 다음을 준비하는 것이 좋습니다.
스토리지 용량 확인:SLA를 유지하기 위해 vSphere 클러스터의 스토리지 공간 사용률이 80% 미만인지 확인합니다. 사용률이 80%를 초과하는 경우 업그레이드가 평소보다 오래 걸리거나 완전히 실패할 수 있습니다. 스토리지 사용률이 70%를 초과하는 경우 노드를 추가하여 클러스터를 확장하고 업그레이드 중 다운타임이 발생하지 않도록 합니다.
FTST를 0으로 설정하여 vSAN 스토리지 정책 변경: 허용되는 장애(FTT)가 0인 vSAN 스토리지 정책으로 구성된 VM을 FTT가 1인 vSAN 스토리지 정책으로 변경하여 SLA를 유지합니다.
VM CD 마운트 삭제: vMotion과 호환되지 않는 워크로드 VM에 마운트된 CD를 삭제합니다.
VMware 도구 설치 완료: 예약된 업그레이드가 시작되기 전에 VMware 도구의 설치 또는 업그레이드를 완료합니다.
VM에서 SCSI 버스 공유 삭제: VM을 끄고 싶지 않으면 VM에서 SCSI 버스 공유를 삭제합니다.
액세스되지 않는 VM 및 Datastore 삭제: vCenter 인벤토리에서 사용되지 않고 액세스할 수 없는 VM을 삭제합니다. 액세스할 수 없는 외부 Datastore를 삭제합니다.
Distributed Resource Scheduler(DRS) 규칙 사용 중지: VM을 호스트에 고정하는 DRS 규칙으로 인해 노드가 유지보수 모드로 전환되지 않습니다. 업그레이드 전에 DRS 규칙을 사용 중지하고 업그레이드가 완료된 후 사용 설정할 수 있습니다.
VMware 부가기능 및 서드 파티 솔루션 업데이트: 프라이빗 클라우드 vCenter에 배포된 VMware 부가기능 및 타사 솔루션이 이전에 언급된 업그레이드 후 버전과 호환되는지 확인합니다. 도구 예시로는 백업, 모니터링, 재해 복구 조정, 기타 유사한 기능 등이 있습니다. 솔루션 공급업체에 문의하여 업그레이드 후 호환성을 보장하기 위해 필요한 경우 미리 업데이트하세요.
유지보수 프로세스에 영향을 줄 수 있는 구성
VMware Engine은 VMware의 유지보수 모드를 활용하여 업그레이드, 업데이트, 노드 유지보수를 수행합니다. 이는 프라이빗 클라우드 워크로드를 계속 사용하는 데 도움이 됩니다. 그러나 다음 구성에서는 노드가 유지보수 모드로 전환되기 전에 추가 단계가 필요할 수 있습니다.
DRS 규칙: VM을 특정 노드에 강제로 유지하는 MUST 규칙입니다.
SCSI 버스 공유: SCSI 버스를 공유하도록 구성된 VM입니다.
CD-ROM 마운트: CD-ROM이 연결된 VM입니다(특히 vMotion을 사용하여 CD-ROM을 다른 노드로 이동할 수 없는 경우).
직렬 포트 연결: vMotion을 사용하여 다른 노드로의 이동을 방지하는 직렬 포트 연결을 사용하는 VM입니다.
원시 기기 매핑(RDM): 물리적 스토리지 기기에 직접 액세스하는 VM입니다.
조치가 필요한 경우
이러한 구성이 노드에 있으면 Cloud Customer Care에서 프라이빗 클라우드의 가용성을 유지하는 데 필요한 해결 단계를 수행하기 최소 24시간 전에 알림을 표시합니다. 일부 경우 VM을 끄고 vMotion으로 이동한 다음 전원을 켜거나 CD-ROM을 삭제하는 등의 단계로 잠시 동안 워크로드가 중단될 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-03-04(UTC)"],[],[],null,["# Private cloud maintenance and updates\n=====================================\n\nPrivate cloud environments are designed in the following ways to have no single\npoint of failure:\n\n- ESXi clusters are configured with vSphere high availability (HA). Clusters are sized to have at least one spare node for resiliency.\n- vSAN provides redundant primary storage, requiring at least three nodes to provide protection against a single failure. For larger clusters, you can configure vSAN to provide higher resiliency.\n- vCenter, PSC, and NSX Manager virtual machines (VMs) are configured with RAID-10 storage to protect against storage failure. The VMs are additionally protected against node and network failures by vSphere HA.\n- ESXi hosts have redundant fans and NICs.\n- TOR and spine switches are configured in HA pairs to provide resiliency.\n\nVMware Engine continuously monitors uptime, monitors availability,\nand provides availability SLAs for the following types of VMs:\n\n- ESXi hosts\n- vCenter\n- PSC\n- NSX Manager\n\nVMware Engine continuously monitors the following for failures:\n\n- Hard disks\n- Physical NIC ports\n- Servers\n- Fans\n- Power\n- Switches\n- Switch ports\n\nIf a disk or node fails, VMware Engine immediately and automatically\nadds a new node to the affected VMware cluster to restore service operability. The following processes take place on your private cloud:\n\n- **Automated monitoring and alerting**: Our monitoring system constantly tracks the health of your nodes. When an issue is detected that indicates a potential hardware failure, an alert is triggered.\n- **Human-in-the-loop for diagnosis**: While the system is designed for automated replacement, our engineers review these alerts to quickly determine the root cause. This ensures that we're addressing the correct issue and prevents unnecessary node replacements when a simpler solution (like a reboot) is recommended. For example, temporary network issues or software glitches can trigger similar alerts to hardware failures, and we want to avoid impacting your cluster with node replacement when it might not be the recommended action. An unnecessary node replacement triggers a full vSAN Resync, which is a storage I/O intensive operation.\n- **Automated node replacement for hardware failures**: If our engineers confirm a hardware failure, the automated node replacement process begins immediately. A new node is added to your cluster, and vSAN initiates the data resync on that node.\n\nThe following VMware elements in private clouds are backed up, maintained, and\nupdated:\n\n- ESXi\n- vCenter Platform Services Controller\n- vSAN\n- NSX\n\nBackup and restore\n------------------\n\nBackups include the following:\n\n- Nightly incremental backups of vCenter, PSC, and DVS rules.\n- vCenter native APIs to back up components at the application layer.\n- Automatic backup prior to update or upgrade of the VMware management software.\n\nMaintenance\n-----------\n\nThe following types of planned maintenance are included.\n\n### Backend and internal maintenance\n\nBackend and internal maintenance typically involves reconfiguring physical\nassets or installing software patches. It doesn't affect normal consumption of\nthe assets being serviced. With redundant NICs going to each physical rack,\nnormal network traffic and private cloud operations aren't affected. You might\nnotice a performance impact only if your organization expects to use the full\nredundant bandwidth during the maintenance interval.\n\n### Portal maintenance\n\nSome limited service downtime is required when the control plane or\ninfrastructure is updated. Maintenance intervals can be as frequent as once per\nmonth, and are expected to decline in frequency over time.\nVMware Engine notifies you about impending portal maintenance and\nmakes an effort to keep the maintenance interval as short as possible. During a\nportal maintenance interval, the following services continue to function without\nany impact:\n\n- VMware management plane and applications\n- vCenter access\n- All networking and storage\n\n### VMware infrastructure maintenance\n\nIt's occasionally necessary to make changes to the configuration of the VMware\ninfrastructure. These intervals can occur every one to two months, but the\nfrequency is expected to decline over time. This type of maintenance can usually\nbe done without interrupting normal private cloud consumption. During a VMware\nmaintenance interval, the following services continue to function without any\nimpact:\n\n- VMware management plane and applications\n- vCenter access\n- All networking and storage\n\nUpdates and upgrades\n--------------------\n\nVMware Engine is responsible for lifecycle management of VMware\nsoftware (ESXi, vCenter, PSC, and NSX) in private clouds.\n\nSoftware updates include the following:\n\n- **Patches:** security patches or bug fixes released by VMware\n- **Updates:** minor version change of a VMware stack component\n- **Upgrades:** major version change of a VMware stack component\n\nVMware Engine tests critical security patches as soon as they become\navailable from VMware. Google will aim to commence the rollouts of relevant\ncritical patches to private cloud environments within one week of their\navailability. The actual patching completion timeline will vary depending on\nscheduling availability and the need to time the patching to avoid any downtime\nfor customer workloads.\n\nWhen a new major version of VMware software is available,\nVMware Engine works with customers to coordinate a suitable\nmaintenance window for applying the upgrade. VMware Engine applies\nmajor version upgrades at least six months after the major version is released\nand notifies customers one month in advance of applying major version upgrades.\n\nVMware Engine also works with key industry vendors to ensure that\nthey support the latest VMware software version before rolling out a major\nversion upgrade. For information about support for specific vendors, [contact\nCloud Customer Care](/vmware-engine/docs/getting-support).\n\n### Certificate update responsibility\n\nCertificate updates are a Google-owned responsibility. If you get a certificate\nupdate error, no action is required and the certificate is renewed before\nexpiration. However, if LDAPS is configured in your private cloud, you are\nsolely responsible for the specific certificate associated with that error.\n\n### Preparation\n\nGoogle recommends taking the following preparations before starting an update or\nupgrade:\n\n- **Check storage capacity:** Ensure your vSphere cluster's storage space utilization is lower than 80% to maintain the [SLA](/vmware-engine/sla). If the utilization is higher than 80%, upgrades might take longer than normal or fail completely. If your storage utilization is higher than 70%, [add a node](/vmware-engine/docs/private-clouds/howto-manage-private-cloud#add-nodes) to expand the cluster and avoid any potential downtime during upgrades.\n- **Change vSAN storage policies with FTT of 0:** Change VMs configured with a vSAN storage policy for Failures to Tolerate (FTT) of 0 to a vSAN storage policy with FTT of 1 to maintain the SLA.\n- **Remove VM CD mounts:** Remove any CDs mounted on your workload VMs that are not compatible with vMotion.\n- **Complete VMware tool installations:** Complete any installations or upgrades of VMware tools before the scheduled upgrade begins.\n- **Remove SCSI bus sharing on VMs:** Remove SCSI bus sharing on VMs if you don't want the VMs to be powered off.\n- **Remove inaccessible VMs and datastores:** Remove unused and inaccessible VMs from the vCenter inventory. Remove any inaccessible external datastores.\n- **Disable Distributed Resource Scheduler (DRS) rules:** DRS rules that pin a VM to a host prevent a node from entering maintenance mode. You can disable the DRS rules before the upgrade and enable them after the upgrade is complete.\n- **Update VMware add-ons and third-party solutions:** Verify that VMware add-ons and third party solutions deployed on your private cloud vCenter are compatible with the post-upgrade versions mentioned previously. Examples of tools include those for backup, monitoring, disaster recovery orchestration, and other similar functions. Check with the solution vendor and update ahead of time if necessary to ensure compatibility after the upgrade.\n\nConfigurations that might affect maintenance processes\n------------------------------------------------------\n\nVMware Engine leverages VMware's Maintenance Mode to carry out\nupgrades, updates, and node maintenance. This helps ensure continued operation\nof your Private Cloud workloads. However, the following configurations might\nrequire additional steps before a node can enter Maintenance Mode:\n\n- **DRS rules:** MUST rules that force VMs to stay on a specific node.\n- **SCSI bus sharing:** VMs configured to share SCSI buses.\n- **CD-ROM mounts:** VMs with CD-ROMs attached, especially if those CD-ROMs cannot be moved to another node using vMotion.\n- **Serial port connections:** VMs using serial port connections that prevent them from being moved to another node using vMotion.\n- **Raw device mappings (RDM):** VMs directly accessing physical storage devices.\n\n| **Important:** Proactively managing these configurations can help streamline future VMware Engine maintenance procedures.\n\n### If action is necessary\n\nIf any of these configurations exist on a node, Cloud Customer Care notifies you\nat least 24 hours before taking the remediation steps required to maintain the\navailability of your Private Cloud. In some cases, steps such as powering off a\nVM and moving it with vMotion and then powering it on, or removal of CD-ROMs,\nmight briefly disrupt your workload.\n\nWhat's next\n-----------\n\n- Learn about [VMware Engine security](/vmware-engine/docs/concepts-security)"]]
