InstructLab の高可用性と災害復旧について

高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。 サービスについては、可用性はサービスレベル契約で定義されています。 可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。 ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計が処理できる能力を超えています。、サービスインスタンスを稼動状態に回復させるプロセスである。

Red Hat AI InstructLab Red Hat AI InstructLab は、標準プランで サービスレベル目標(SLO)を 満たすように設計されている。

利用可能な地域とデータセンターのロケーションの詳細については、 ロケーション別のサービスとインフラの可用性を ご覧ください。

高可用性アーキテクチャ

caption-side=bottom"
Red Hat AI InstructLab アーキテクチャ アーキテクチャ アーキテクチャ図

高可用性機能

Red Hat AI InstructLab は以下の高可用性機能をサポートしている:

HA機能 Red Hat AI InstructLab
特長 説明 考慮事項
グローバル・ロード・バランシング ノードまたはアベイラビリティゾーンに障害が発生した場合、APIリクエストはグローバルロードバランサーを経由して生き残ったHAインスタンスノードにルーティングされ、サービスは実行され続ける。 ゾーン内のノードで実行されているアクティブな合成データ生成ジョブやアクティブなモデルアライメントジョブは、障害が発生すると自動的に別のゾーンのノードで再試行されます。 容量の制約から、モデルアライメントノードが1つのゾーン内に配置される地域もある。 ゾーンをアクティブに戻すと、モデルのアライメントジョブは自動的に再試行される。 障害が発生してからグローバルロードバランサが障害を認識するまでに短い時間(数秒)があり、その間に障害が発生したインスタンスにリクエストが送られることがあります。

ディザスターリカバリー機能

Red Hat AI InstructLab は、以下のディザスタリカバリ機能をサポートしている:

DRの特徴 Red Hat AI InstructLab
特長 説明 考慮事項
InstructLab は地域展開モデルに従っている。 地域に障害が発生した場合、地域が復旧するまでAPIが利用できなくなる可能性がある。 InstructLab が配置されている他のアクティブな領域は、その領域が回復するまで、合成データの生成とモデルアラインメントの実行に使用できる。
Object Storage レプリケーション InstructLab は、すべての SDG およびアラインメントされたモデルを クライアントが提供するオブジェクトストレージバケットに永続化します。 ディザスタリカバリ戦略については、 Object Storage サービスのドキュメントを参照してください。 バケット・レプリケーションを使って、タクソノミーのコンテンツ、生成された合成データ、整列されたモデルを別の地域に複製することができます。 詳細については、 高可用性とディザスタリカバリについて IBM Cloud® Object Storage を参照してください。

DRの計画

DRステップは定期的に練習しなければならない。 計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。

DRシナリオ
失敗 解決方法
ハードウェア障害(シングルポイント) IBM は、ゾーン内の単一ハードウェア障害に強いインスタンスを提供します。 設定は不要。
ゾーン障害 IBM はゾーン障害に強いインスタンスを提供する。 設定は不要。
データ破損 InstructLab 復元はサービスチームが行います。
地域的な失敗 InstructLab 復旧はサービスチームが行う。

HAとDRの責任

HAとDRのプランを継続的にテストするのは、あなたの責任です。

ネットワーク接続の中断や短時間のサービス利用不能が発生する可能性があります。 アプリケーションの高可用性を維持するために、アプリケーションのソースコードに クライアント可用性再試行ロジックが 含まれていることを確認するのは、あなたの責任です。

各特徴に関連する以下のチェックリストを、計画の作成と実践に役立ててください。

各特徴に関連する以下のチェックリストを、計画の作成と実践に役立ててください。

オブジェクト・ストレージのレプリケーション

オブジェクト・ストレージ・レプリケーションのチェックリスト例

- [ ] Create a primary InstructLab instance in primary region.
- [ ] Create a primary Cloud Object Storage bucket in primary region.
- [ ] Create a secondary InstructLab instance in secondary region.
- [ ] Create a secondary object storage bucket in secondary region.
- [ ] Enable object replication from primary object bucket to secondary object bucket
- [ ] Upload taxonomy to primary object storage bucket and create taxonomy object in primary InstructLab instance
- [ ] Ensure taxonomy object storage bucket object replicates to secondary region
- [ ] Generate training data from taxonomy in primary Instructlab Instance
- [ ] Ensure training data file replicates from primary object storage bucket to secondary object storage bucket
- [ ] Fine tune a model in the InstructLab primary instance
- [ ] Ensure model alignment file replicates from primary object storage bucket to secondary object storage bucket

お客様と IBM Cloud for Red Hat AI InstructLab との間の責任の所在に関する詳細については、「 お客様の責任 」をご参照ください。

復旧時間目標(RTO)と復旧時点目標(RPO)

RTO/RPO機能 Red Hat AI InstructLab
特長 RTOとRPO
バックアップ InstructLab インスタンスによるオブジェクト・ストレージ・レプリケーション RTO=数分、RPO=0に近い

変更管理

変更管理には、アップグレード、構成変更、削除などのタスクが含まれる。

ユーザーとプロセスに、業務に必要な最小限の権限を持つ IAM ロールとアクションを付与する。 詳細については、 「誤ってサービスを削除しないようにするにはどうすればよいですか?

Red Hat AI InstructLab の新しいバージョンにアップグレードする前に、タクソノミー、生成されたデータ、および整列されたモデルの手動バックアップを作成することを検討してください。

IBM 地域の失敗からどう回復するか

IBM、サービス・インスタンスをリストアできない場合は、「 ディザスタリカバリの計画 」の説明に従ってサービスをリストアする必要があります。

IBM サービスの維持方法

  • すべてのアップグレードは、リカバリプランとロールバックプロセスを含む、 IBM サービスのベストプラクティスに従います。
  • 定期的なメンテナンスにより短時間の中断が発生する可能性があるが、 クライアントの可用性再試行ロジックにより 緩和される。
  • IBM は、不具合の最初の兆候でアップデートを元に戻します。
  • 複雑な変更は、露出をコントロールする機能フラグで有効・無効にする。
  • 顧客のワークロードに影響を与える変更は、 IBM Cloud 通知で詳述される。

本サービスに影響を与えるメンテナンスの予定、お知らせ、リリースノートについては、以下のリンクをご参照ください。