高可用性 (HA)

IBM® watsonx.data は、 と の両方でマルチゾーン・リージョン（MZR）を使用し、高可用性を提供している。 IBM Cloud AWS watsonx.data のさまざまなコンポーネントは、高い可用性と回復力を確保するために、アクティブ・アクティブとアクティブ・オンリーのセットアップで展開される。

アクティブ/アクティブ

Active-Activeセットアップでは、コンポーネントの複数のインスタンスが、異なるアベイラビリティゾーン（AZ）で同時に実行される。 これらのインスタンスは負荷分散されており、リクエストを並行して処理することができる。

主な特徴

• 冗長性 - 1つのインスタンスまたはAZに障害が発生しても、他のインスタンスはトラフィックを中断することなくサービスを継続します。
• 負荷分散 - トラフィックがすべてのアクティブなインスタンスに分散されるため、パフォーマンスが向上し、待ち時間が短縮されます。
• 自動フェイルオーバー - 手動で操作する必要はなく、システムが自動的にトラフィックを迂回させます。

メリット

• 高い耐障害性。
• ゾーン障害時のシームレスなユーザー体験。
• より良いリソース使用。

watsonx.data、ほとんどのコンポーネントは、継続的な可用性を確保するために、複数のゾーンにレプリカを持つActive-Activeセットアップでデプロイされる。 例えば、エンタープライズプランのメタデータサービス（MDS）。

アクティブのみ

Active-Onlyセットアップでは、コンポーネントは一度に1つのAvailability Zoneでのみ実行される。 そのゾーンに障害が発生した場合、コンポーネントを再起動するか、別のゾーンに再デプロイする必要がある。

主な特徴

• コンポーネントごとに単一のアクティブ・インスタンス。
• 故障時に新しいゾーンで自動再スタート。
• フェイルオーバーの際、再起動に時間がかかるため、若干の遅れが生じる。

メリット

• よりシンプルなアーキテクチャ。
• 資源消費の削減。
• フェイルオーバー時の短時間のダウンタイムによる回復力。

watsonx.data では、シングル・テナント・コンポーネントはアクティブ・オンリーのセットアップでデプロイされる。 これらのシングルテナント・コンポーネントは、 Presto エンジンとメタストア・コンポーネントを含み、キャパシティとフェイルオーバーのために3つのAZに戦略的に分散されている。 これらのコンポーネントは、障害発生時に新しいゾーンで再始動します。 例えば、ライトプランのメタデータ・サービス（MDS）。

マルチゾーン・リージョン（MZR）では、 Prestoとデータシートは異なるゾーンに分散される。

単一のアベイラビリティー・ゾーンが MZR で失敗した場合、またはいずれかのリージョンでハードウェア障害が発生した場合、ワークロードは自動的に失敗し、そのリージョン内の他のゾーンで再始動します。 すべての watsonx.data インスタンスには、デフォルトの Cross-Regional Metadata バケットとオプションの Trial バケット (10 GB) が付属しています。 どちらのバケットも、IBM Cloud® Object Storage Versioningで有効になっています。 データは、別の IBM Cloud Object Storage アカウントへのレプリケーションを有効にすることでバックアップされます。 しかし、顧客がwatsonx.data インスタンスに持ち込む外部バケットについては、それらのバックアップは顧客の責任となります。

地域の災害では、実行する必要があるすべての手順が記載された E メールが届きます。 watsonx.dataの責任を参照してください。 シングル・テナント・コンポーネントは、「アクティブのみ」モデルで動作し、障害が発生した場合に同じサービスを提供する新規ノードで即時に再始動できるようにします。

シングル・テナント・コンポーネントは、信頼性を高めるために戦略的に 3 つの AZ に分散されます。 AZ に障害が発生すると、使用可能な AZ 上で必要なサービスを開始するための十分な容量が確保されます。 これにより、AZ の停止による影響を最小限に抑えることができます。

責任

アプリケーション・レベルの高可用性

ネットワークとクラウド・サービスを介して通信するアプリケーションは、一時的な接続障害の影響を受けます。 デプロイメントまたは IBM Cloudへの接続が一時的に失われてエラーが発生した場合に接続を再試行するようにアプリケーションを設計します。 watsonx.data はマネージド・サービスであるため、定期的なアップデートやメンテナンスは通常業務の一環として行われます。 このような保守により、一時的なサービスの中断が発生することがあります。

サービスの一時的な中断を処理し、失敗したコマンドのエラー処理を実装し、一時的な中断から復旧するための再試行ロジックを実装するようにアプリケーションを設計する必要があります。

以下に、一時サービスの中断中に予期される可能性のあるエラー・コードをいくつか示します。

Presto コーディネーター・ノードが再始動した場合、保守のため、またはシステム障害のために、アプリケーションは Presto エンジンとの接続を再確立する必要があります。

数分間の使用不能や接続の中断は想定されていない。 接続できない時間が1分以上ある場合は、サポートチケットに詳細を記入してください。

災害復旧戦略

復旧時間目標（RTO）とは、システムまたはサービスが障害発生後に利用できなくなる許容可能な最大時間のことである。 業務に重大な支障をきたさないために、どの程度迅速にシステムを復旧させなければならないかを定義するものである。 watsonx.data、RTOは以下の点に依存する：

• 直近のバックアップポイント。
• ログのアーカイブ状況。
• メタデータの復元には手作業が必要。

RPO（Recovery Point Objective）とは、障害発生時に許容できる最大データ損失量のことである。 これは、直近のバックアップまたはスナップショットに基づいて、システムがどの程度過去にさかのぼってデータを復元できるかを示す。 リカバリは、最後に成功したメタデータ・バックアップとログ・アーカイブに基づく。 障害が発生してから復旧するまでに時間がかかるかもしれない。

データの耐障害性を強化し、潜在的な損失を最小限に抑えるため、 SaaS 環境の Milvus サービスのバックアップ頻度を増やした。 この変更により、RPO（Recovery Point Objective）がわずか2時間に短縮され、障害発生時に、より新しい時点からデータを復元できるようになった。

ロケーション