Databases for Elasticsearch の高可用性と災害復旧について
高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。 サービスについては、可用性はサービスレベル契約で定義されています。 可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。 ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計の処理能力を超えている。、サービスインスタンスを稼動状態に回復させるプロセスである。
Databases for Elasticsearch は、標準プランで定義された サービスレベル目標（SLO ）を満たす地域サービスである。
詳しくは、 サービス・レベル・アグリーメント（SLA ）を参照。 Databases for Elasticsearch で利用可能な IBM Cloud リージョンとデータセンターの詳細については、 ロケーション別のサービスとインフラの可用性を 参照してください。
高可用性アーキテクチャ
Databases for Elasticsearch は、レプリケーション、フェイルオーバー、および高可用性機能を提供し、インフラストラクチャのメンテナンス、アップグレード、および一部の障害からデータベースとデータを保護します。 デプロイメントには、3 つのデータ・メンバーを持つクラスターが含まれています。 Elasticsearch 各インデックスにはプライマリシャードとレプリカシャードがある。 Elasticsearch は、プライマリ・バックアップ・モデルに基づくデータ・レプリケーション・モデルを採用している。 プライマリ・シャードはインデックス操作のメイン・エントリー・ポイントとして機能し、他のコピーはレプリカ・シャードとして知られている。 レプリカシャードを最新の状態に保つために、非同期レプリケーションが採用されている。 Elasticsearch クラスタ状態の安定性を確保し、フェイルオーバーを容易にします。 マスター・ノードが利用できなくなった場合、新しいマスターが選出され、新しいマスター上のレプリカ・シャードがマスターに昇格する。 リーダーシャードとレプリカシャードは、クラスター内の異なるゾーンに地理的に分散されており、同時障害のリスクを軽減している。
インデックスにさらにレプリカを追加することで、高可用性をさらに拡張することができますが、これには考慮すべき追加ストレージ・コストがかかります。
Elasticsearch、 レプリケーション技術に関するドキュメントを確認し、デフォルトで導入されている非同期レプリケーション戦略に関連する制約とトレードオフを理解する。
高可用性機能
Databases for Elasticsearch は以下の高可用性機能をサポートしている：
| 特長 | 説明 | 考慮事項 |
|---|---|---|
| 自動フェイルオーバー | すべてのクラスタに標準装備され、ゾーンや単一メンバーの障害に強い。 | |
| メンバー数 | 最低3名。 デフォルトはスタンダード3展開。 | |
| 水平スケーリング | Elasticsearch ノード（メンバーとも呼ばれる）を追加することで、 IBM Cloud Databases for Elasticsearch デプロイメントを水平方向に拡張することが可能です。 ノードを増やすことで、容量と信頼性が向上する。 |
災害復旧アーキテクチャ
ディザスターリカバリー機能
Databases for Elasticsearch は、以下のディザスタリカバリ機能をサポートしている：
| 特長 | 説明 | 考慮事項 |
|---|---|---|
| バックアップ・リストア | 以前に作成したバックアップからデータベースを作成する。 詳細については、 Cloud Databases バックアップの管理を 参照してください。 | 復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。 |
| 水平スケーリング | Elasticsearch ノード（メンバーとも呼ばれる）を追加することで、 IBM Cloud Databases for Elasticsearch デプロイメントを水平方向に拡張することが可能です。 より多くのノードを追加することで、複数のゾーン障害に対するデータベースの耐性を高めることができます。 | |
| スナップショット | スナップショットは、複数のリージョンからアクセス可能なスナップショットリポジトリに保存できます。 しかし、スナップショットはリアルタイムではないため、通常は即時のフェイルオーバーではなく、バックアップとリストアの目的で使用される。 障害が発生した場合は、スナップショットから手動でリストアする必要があります。 |
DRの計画
災害復旧の手順は、定期的に実践されなければならない。 計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。
| 失敗 | 解決方法 |
|---|---|
| ハードウェア障害（シングルポイント） | IBM は、ゾーン内の単一ハードウェア障害から回復力のあるデータベースを提供します。 |
| ゾーン障害 | 自動フェイルオーバー。 データベースのメンバーはゾーン間で分散される。 3つのメンバーを構成することで、複数のゾーン障害に対する回復力がさらに高まる。 |
| データ破損 | バックアップ・リストア。 リストアしたデータベースを本番環境またはソース・データで使用し、リストアしたデータベースの破損を修正する。 |
| 地域的な失敗 | バックアップ・リストア。 リストアしたデータベースを本番環境で使用する。 |
アプリケーション・レベルの高可用性
ネットワークとクラウド・サービスを介して通信するアプリケーションは、一時的な接続障害の影響を受けます。 配備先または IBM Cloud への接続が一時的に失われたことが原因でエラーが発生した場合に、接続を再試行するようにアプリケーションを設計します。
Databases for Elasticsearch はマネージド・サービスであるため、定期的な更新とデータベースのメンテナンスは通常業務の一環として行われます。 これにより、データベースを使用できなくなる、短時間の中断が発生することがあります。 また、データベースの正常なフェイルオーバー、再試行、および再接続が実施される可能性もあります。 レプリカであるメンバーとリーダーであるメンバーをデータベースが判別するのに短い時間がかかるため、短い接続の中断が発生する可能性があります。 フェイルオーバーにかかる時間は通常、30 秒未満です。
アプリケーションを設計する際には、データベースへの一時的な割り込みの処理、失敗したデータベース・コマンドのエラー処理の実装、一時的な中断から復旧するための再試行ロジックの実装を含める必要があります。
データベースを使用できない状態や接続の中断が数分に及ぶことは想定されていません。 接続できない時間が1分以上ある場合は、詳細を添えて サポート・ケースを 作成してください。
接続制限
Databases for Elasticsearch は、REST APIを使ってデータベースとやりとりするため、データベースへの接続数に制限はない。 Elasticsearch のデフォルト設定は、全文検索、ハイライト、集計、インデックス作成などの基本的な操作において、すぐに使える優れたエクスペリエンスを提供する。
データベースのパフォーマンスを向上させたい場合は、 Optimize Elasticsearch のページをご覧ください。
HAとDRの責任
以下の情報は、HAとDRのプランを作成し、継続的に実践するのに役立つ。
バックアップからデータベースをリストアする場合、またはポイントインタイム・リストアを使用する場合、新しい接続文字列で新しいデータベースが作成されます。 既存のワークロードとプロセスは、新しい接続文字列を消費するように調整されなければならない。
復旧したデータベースも、災害データベースと同じように、顧客が作成した依存関係を必要とする場合がある。 これらのサービスやその他のサービスが復興地域に存在することを確認する：
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
データベースを削除すると、関連するバックアップも削除されることを忘れないでください。 しかし、削除されたデータベースは、限られた時間枠内であれば復元できる可能性がある。 詳細については、データベース復旧手順の具体的な詳細については、 バックアップ FAQ ドキュメントを 参照してください。
IBM Cloud、バックアップをコピーすることはできないため、追加のバックアップにはデータベース固有のツールを使用することを検討してください。 悪意のあるデータベースの削除に続き、データベースの再削除からの復旧が必要になる場合があります。 データベースへのIAMアクセスを注意深く管理することで、この問題にさらされる機会を減らすことができる。
各特徴に関連する以下のチェックリストは、プランの作成と実践に役立つ。
- バックアップ・リストア
- RPO要件を満たすために、望ましい頻度でバックアップが利用可能であることを確認する。 Cloud Databases バックアップの管理は、バックアップの頻度を文書化する。
- データベースのリストア領域にはいくつかの制限があります。リストアの目標が達成できるかどうかは、 Cloud Databases バックアップの管理を 参照してください。
- バックアップの保存期間が要件を満たしていることを確認する。
- テストリストアを定期的にスケジュールし、実際のリストア時間が定義されたRTOを満たしていることを検証する。 データベースのサイズはリストア時間に大きく影響することを忘れないでください。 大規模なデータベースをより小さく管理しやすい単位に分割したり、未使用のデータをパージするなど、リストア時間を最短化する戦略をご検討ください。
- Key Protect サービスを確認する。
Databases for Elasticsearch を使用する際の顧客と IBM Cloud との間の責任分担については、 Cloud Databases の責任分担を 参照のこと。
最新情報： IBM
顧客のワークロードに影響を与えるアップデートは、 IBM Cloud の通知で知らされる。 本サービスに関連する計画的なメンテナンス、アナウンスメント、リリースノートに関する情報を入手するには、 モニタリングの通知とステータスの ページを参照してください。 さらに、 バージョン・ポリシーの ページを定期的に確認し、End-of-Lifeのバージョンと日付に関する最新のアップデートを確認してください。