プライベート クラウドのメンテナンスと更新

プライベート クラウド環境は、単一障害点のないように設計されています。

  • ESXi クラスタは、vSphere High Availability(HA)で構成ています。クラスタは、復元力を確保するために少なくとも 1 つの予備ノードを備えるようにサイズ設定されています。
  • vSAN は、単一障害に対する保護を確保するために少なくとも 3 つのノードを必要とする冗長プライマリ ストレージを提供します。大規模なクラスタの場合は、復元性を高めるように vSAN を構成できます。
  • vCenter、PSC、NSX Manager 仮想マシン(VM)は、ストレージ障害から保護するために RAID-10 ストレージで構成されています。また、VM は vSphere HA によってノード障害やネットワーク障害から保護されます。
  • ESXi ホストには冗長なファンと NIC があります。
  • TOR スイッチとスパイン スイッチは、復元力を確保するため HA ペアで構成されています。

VMware Engine は、稼働時間を継続的にモニタリングし、可用性をモニタリングして、次の VM に対して可用性 SLA を提供します。

  • ESXi ホスト
  • vCenter
  • PSC
  • NSX Manager

VMware Engine は次のものに関するエラーを継続的にモニタリングします。

  • ハードディスク
  • 物理 NIC ポート
  • サーバー
  • ファン
  • 電源
  • スイッチ
  • スイッチポート

ディスクまたはノードに障害が発生した場合、VMware Engine は直ちに、該当する VMware クラスタに新しいノードを自動的に追加して、サービスのオペレーションを復元します。

プライベート クラウドの次の VMware 要素は、バックアップ、保守、更新されます。

  • ESXi
  • vCenter Platform Services Controller
  • vSAN
  • NSX

バックアップと復元

バックアップには次の機能が用意されています。

  • vCenter、PSC、DVS ルールの夜間増分バックアップ。
  • アプリケーション レイヤでコンポーネントをバックアップするための vCenter ネイティブ API。
  • VMware 管理ソフトウェアを更新またはアップグレードする前の自動バックアップ。

メンテナンス

次のタイプの定期メンテナンスが実施されます。

バックエンドと内部のメンテナンス

バックエンドと内部メンテナンスには通常、物理的なアセットの再構成やソフトウェア パッチのインストールが含まれます。提供するアセットの通常の消費には影響しません。冗長 NIC が各物理ラックに配置されるため、通常のネットワーク トラフィックとプライベート クラウドの運用に影響はありません。メンテナンス期間中に組織のエキスパートが冗長帯域幅をすべて使用することを想定している場合にのみ、パフォーマンスに影響が見られる可能性があります。

ポータルのメンテナンス

コントロール プレーンやインフラストラクチャが更新されるときに、限定的なサービスのダウンタイムが必要になります。メンテナンスの間隔は月に 1 回程度です。頻度は時間の経過とともに減少することが想定されます。VMware Engine は、間近に迫ったポータルのメンテナンスを通知すると同時に、メンテナンス間隔をできる限り短くするよう努めています。ポータルのメンテナンス期間中、次のサービスは影響を受けずに引き続き機能します。

  • VMware 管理プレーンとアプリケーション
  • vCenter へのアクセス
  • すべてのネットワークとストレージ

VMware インフラストラクチャのメンテナンス

VMware インフラストラクチャの構成を変更する必要がある場合もあります。頻度は 1~2 か月に 1 回程度で、時間の経過とともに減少することが想定されます。このタイプのメンテナンスは普通、通常のプライベート クラウドの使用を中断することなく行うことができます。VMware のメンテナンス期間中、次のサービスは影響を受けずに引き続き機能します。

  • VMware 管理プレーンとアプリケーション
  • vCenter へのアクセス
  • すべてのネットワークとストレージ

更新とアップグレード

VMware Engine は、プライベート クラウドの VMware ソフトウェア(ESXi、vCenter、PSC、NSX)のライフサイクル管理を担当します。

ソフトウェア アップデートには、次のものが含まれます。

  • パッチ: VMware によってリリースされるセキュリティ パッチまたはバグの修正。
  • アップデート: VMware スタック コンポーネントのマイナー バージョンの変更。
  • アップグレード: VMware スタック コンポーネントのメジャー バージョンの変更。

重要なセキュリティ パッチは、VMware から利用可能になり次第、VMware Engine でテストされます。SLA に基づき、VMware Engine によるセキュリティ パッチのプライベート クラウド環境へのロールアウトは、1 週間以内を目標としています。

VMware ソフトウェアの新しいメジャー バージョンが利用可能になると、VMware Engine はお客様と協力してアップグレードを実施するための適切なメンテナンスの時間枠を調整します。VMware Engine は、メジャー バージョンのリリースから遅くとも 6 か月後にメジャー バージョン アップグレードを適用し、メジャー バージョン アップグレードの 1 か月前にお客様に通知します。

VMware Engine は主要な業界ベンダーと連携して、メジャー バージョン アップグレードのロールアウト前に最新の VMware ソフトウェア バージョンをサポートしていることを確認します。特定のベンダーのサポートについては、Cloud カスタマーケアにお問い合わせください

準備

更新またはアップグレードを開始する前に、次の準備を行うことをおすすめします。

  • ストレージ容量を確認する: SLA を維持するには、vSphere クラスタのストレージ容量の使用率が 75% 未満であることを確認してください。使用率が 75% より高いと、アップグレードに通常より時間がかかることや、完全に失敗することがあります。ストレージの使用率が 70% を超える場合は、クラスタを拡張するためにノードを追加し、アップグレード中にダウンタイムが発生しないようにしてください。
  • FTT 0 の vSAN ストレージ ポリシーを変更する: 許容障害数(FTT)が 0 の vSAN ストレージ ポリシーで構成されている VM は、SLA を維持するために FTT が 1 の vSAN ストレージ ポリシーに変更されます。
  • VM の CD マウントを削除する: ワークロード VM にマウントされた CD をすべて削除します。
  • VMware ツールのインストールを完了する: スケジュールされたアップグレードを開始する前に、VMware ツールのインストールまたはアップグレードを完了します。
  • VM の SCSI バス共有を削除する: VM の電源が停止しないようにするには、VM の SCSI バス共有を削除します。
  • アクセスできない VM とデータストアを削除する: vCenter インベントリから孤立した、アクセスできない VM を削除します。アクセスできない外部データストアを削除します。
  • DRS ルールを無効にする: VM をホストに固定する DRS ルールにより、ノードがメンテナンス モードに入ることができなくなります。アップグレード前に DRS ルールを無効にし、アップグレードが完了したら有効にします。
  • VMware アドオンとサードパーティ ソリューションをアップデートする: プライベート クラウドの vCenter にデプロイされた VMware アドオンとサードパーティ ソリューションが、前述のアップグレード後のバージョンと互換性があることを確認します。ツールの例としては、バックアップ、モニタリング、障害復旧、オーケストレーション、その他類似の機能などがあります。アップグレード後に互換性を確保するには、ソリューション ベンダーに確認し、必要に応じて事前に更新してください。

更新中またはアップグレード中に行われるアクション:

  • DRS ルール: アップグレード中は、すべての DRS ルールが無効になります。アップグレードが完了すると、ルールが再適用されます。
  • シリアルポート: アップグレード中に、すべてのシリアルポート マッピングが削除されます。
  • VM の CD マウント: アップグレード中に、すべての CD マウントが削除されます。

次のステップ