すべての IT システムには目的があります。 その目的を果たすためには、使用できる状態である必要があります。 一部の IT システムはビジネスにとって不可欠なので、高可用性であることが求められます。つまり、部分的あるいは完全に利用できない状態が発生しないか、発生したとしても最小限に抑えられる必要があります。 他のシステムはそれほど重要ではなく、計画的なダウンタイムまたは予定外のダウンタイムはある程度許容されます。たとえば、ユーザーが別のワークフローに頼ることができる場合や、システムが再び利用可能になるまで待つことができる場合などがこれに該当します。 多くのシステムは、これら 2 つの中間に位置します。
HA (高可用性) は、システムが特定の期間にわたって事前に設定されたレベルの運用パフォーマンスを満たすことを可能にする設計アプローチです。 高可用性システムは、サービス提供に関するビジネス要件か、それ以上の要件を満たす信頼性の高いシステムと環境を顧客に提供します。これにより、期待される品質レベルでパフォーマンスを発揮します。
高可用性は、DR (ディザスター リカバリー) に関連していますが、別の概念です。 一般に、HA はサービス提供のための計画外のダウンタイムを回避することに重点を置いていますが、DR は、災害後にシステムを以前の許容可能な状態に復元するために必要なデータとリソースを保持することに重点を置いています。 DR 計画が実装されると、システムが復元されるまでサービス提供が中断されるのが一般的です。 詳細については、「バックアップと障害復旧」をご参照ください。
この分野で一般的に使用される別の用語は「地理的な冗長性」です。追加のシステムまたはバックアップ システムを別の地理的位置で利用可能にすることで、データ センターが完全に停止してもアプリケーションまたはシステムを存続させるという設計目標を指します。 このアプローチは、自然災害、停電、またはデータ センターの可用性へのその他の障害から保護するのに役立ちます。
多くのアーキテクトは、高可用性に対するシステムまたはコンポーネント レベルのアプローチについて言及し、詳細に説明するために、共通の用語を使用しています。 この分野で使用される最も一般的な用語は次のとおりです。
可用性を測定する指標の 1 つとして稼働時間があります。これは通常、システムが一定期間に「利用可能」であった時間の割合として測定されます。 利用可能の定義は主観的であるため、この目標について合意が得られるよう、システム設計プロセスの早い段階で設定する必要があります。 望ましい可用性レベルは、目標とする稼働時間として定義されることが多く、多くの場合は 9 で表されます。 例:
可用性目標は、システムのユーザーとそのシステムを運用する組織との間の SLA (サービス レベル アグリーメント) の形で形式化できます。 多くの場合、SLA には、純粋な可用性目標だけでなく、予想される応答時間などパフォーマンス関連のメトリックも含まれており、ベンダーと顧客の関係がある場合は、それらの目標の達成に伴うペナルティーを定義できます。 内部 SLA も同様に重要ですが、一般的には、顧客向け SLA のペナルティー要件や報告要件は含まれていません。
組織の可用性に対するもう 1 つのアプローチは、組織が保守するシステムの重要度の層を確立することです。システムの停止が組織に与える影響の程度に応じて、重要度の低いものから基本的なものまでを分類します。 考慮事項には、ユーザー エクスペリエンス、財務、評判、規制への影響などがあり、重要度の階層ごとに異なる目標 SLA 定義が定められる場合があります。 一部の組織では、特定のシステムを「Tier 1」または「ビジネス クリティカル」と呼び、他のシステムを「Tier 2」またはビジネス クリティカルが低いものとして位置付け、制約を少なくしたり、異なる構成にしたりします。
事前に定義されたレベルの可用性を満たすようにシステムを設計および構築するには、次のようなさまざまな側面やトピック領域を考慮した全体的なアプローチが必要です。
より高い稼働時間の要求に対応するシステムを構築するには、通常、標準レベルの可用性を満たすベースラインと比較して、時間とリソースの大幅な先行投資と継続的な投資が必要です。ただし、高可用性はイエスかノーかの提案ではなく、IT システムのビジネス価値に大きな影響を与えることなく可用性の目標を緩和できるサブシステムがあるかどうかを検討することは、有用であるケースがほとんどです。
高可用性システムの設計プロセスは、空のキャンバスから始まるわけではありません。 ほとんどの場合、組織の既存の IT インフラストラクチャー、ポリシー、専門分野、および好みによって、エンタープライズ GIS システムが対応する必要がある全体的なフレームワークが決まります。 これには、サポートするシステムの稼働時間や可用性の期待値、および高可用性を実現するために利用できる IT コンポーネントが含まれます。 意思決定間の相互依存性を考慮します。1 つの設計上の意思決定が別の意思決定を生むこともよくあるからです。 これらの詳細の多くは、設計上の制約として捉えることができます。組織がすでに確立した標準に従い、コスト、管理性、およびその他の要素を考慮しながら、システムが全体的な要件を満たすという相互の合意に向けて、設計プロセスを導くのに役立ちます。
多くの場合、設計上の制約は次のカテゴリーに分類されます。
同様に、IT 組織は、物理ハードウェアのメーカーやモデル、仮想化レイヤー、ストレージ システム、ロード バランサー、リバース プロキシーなど、インフラストラクチャーの選択肢をさらに限定する場合があります。
商用クラウドベースの IaaS (Infrastructure as a Service)、つまり仮想マシンや Kubernetes クラスターなどを活用すると、選択肢が制限されます。
ArcGIS Enterprise では、高可用性とは、ArcGIS Enterprise の 1 つのデプロイメントの可用性を向上させる手段を指します。 レプリケートされたデプロイメントは、通常、別のデータ センターまたは別のクラウド リージョンに地理的に分散しており、障害復旧機能を提供します。 ArcGIS Enterprise の高可用性の詳細をご参照ください。
ArcGIS Enterprise は、異なる構成の複数のコンピューターを組み合わせることで、より高いレベルの可用性を提供します。 ArcGIS Enterprise のコンポーネントは、高可用性を実現するためにさまざまなアプローチを使用します。
可用性の高いポータル サイトは、HA サイトを作成するために結合された 2 つのサーバーで構成されます。 これらはそれぞれ完全に冗長化されていますが、システムは 1 台のコンピューターをプライマリー ノードとして保持し、もう 1 台のコンピューターをスタンバイ ノードとして維持します。 プライマリー コンピューターに障害が発生した場合、スタンバイ マシンは障害を検出し、自身をプライマリー コンピューターに昇格させます。
Web サーバー レベルでは、各ポータル ノードが受信リクエストを処理でき、検索インデックスが両方のシステム間で同期されるため、システムはアクティブ/アクティブです。 ただし、状態の変更を処理するのは 1 つのノードのみで、編集、メンバーの招待、および構成はポータル データベースに保存されるため、システム全体はアクティブ/パッシブと見なされます。
可用性の高いポータルでは、2 つのノード間でリクエストを分散するためにロード バランサー (通常はラウンドロビン方式) も必要です。 プライマリー ノードとスタンバイ ノードは、ポートを介したコンピューター間通信とデータベース同期を通じて状態を共有しますが、ポータルのコンテンツ ディレクトリーの共有ファイル ストレージ (NFS ファイル共有、UNC ファイル共有、またはクラウドネイティブ オブジェクト ストレージ) にも依存します。
可用性の高い Portal for ArcGIS デプロイメントの構成の詳細をご参照ください。
可用性の高い GIS サーバー サイトは、2 台以上の完全に冗長なコンピューターで構成され、これらのコンピューターを ArcGIS Server の「サイト」に結合することで、ワークロードがすべてのノードで負荷分散されます。これをアクティブ/アクティブ構成と呼びます。 可用性の高い GIS サーバーには、メンバー コンピューターにリクエストをルーティングするためのロード バランサー (通常はラウンドロビン方式) も必要ですが、Web トラフィックはプライマリー/スタンバイ方式でルーティングすることもできます。
サイト内のコンピューターは、主にサーバー ディレクトリーと構成ストアの共有ストレージの場所 (通常は NFS タイプまたは UNC ベースのファイル共有) を介して状態を共有します。 クラウド システムでは、AWS の DynamoDB や S3 ストレージ、Microsoft Azure の Azure Files ストレージなど、構成ストアでクラウドネイティブ オプションも利用できます。
GeoEvent Server など、一部の特殊な GIS サーバー ロールは、複数コンピューターのサイトで実行するように構成できないことに注意してください。 そのため、これらの GIS サーバー ロールにおいてより高い可用性を実現するには、特別な考慮が必要です。
ArcGIS Server の高可用性デプロイメントを実現するための複数コンピューターのサイト構成の詳細をご参照ください。 単一コンピューターの高可用性デプロイメントのリソースもあります。
Web Adaptor は 2 台以上のコンピューター間で冗長的にデプロイでき、各インスタンスはアクティブ/アクティブ構成で完全に冗長化されます。 この構成には、クライアントがリクエストを送信するフロントエンド ロード バランサーが必要です。このロード バランサーは両方の Web Adaptor ホストにリクエストを分散します。 その他のリソースはドキュメントで入手できます。
リレーショナル データ ストア 高可用性リレーショナル データ ストアは、アクティブ/アクティブ クラスター構成の 2 つの完全冗長インスタンスで構成されます。 プライマリー データ ストア コンピューターに障害が発生した場合、スタンバイ コンピューターが障害を検出し、自身をプライマリー コンピューターに昇格させるため、クライアントは中断することなくホスト フィーチャ サービスを引き続き使用できます。
グラフ データ ストア: 高可用性グラフ ストアは、アクティブ/アクティブ クラスター構成の正確に 3 つの完全冗長インスタンスで構成されます。
オブジェクト ストア: オブジェクト ストアの高可用性はクラスター モードでサポートされます。このアーキテクチャーには少なくとも 3 台のコンピューターが必要です。 クラスター モードでは、データは 3 台のコンピューター間でレプリケートされるため、1 台のコンピューターが停止した場合でもデータ ストアは引き続き使用できます。
時空間ビッグ データ ストア: このタイプのデータ ストアは、クラスター モードもサポートしています。 クラスターには、奇数のコンピューター (メンバー間の合意形成に必要) と、少なくとも 3 台のコンピューターを含める必要があります。 これらの構成はすべてアクティブ/アクティブの高可用性構成です。
ドキュメントのトピック「可用性の高い管理データ ストアの構成」には、追加のガイダンス、手順、および推奨事項が記載されています。
データベース リソースの可用性は、データベース サービスごとに多くのプロバイダー固有のオプションがある特殊なアーキテクチャーの分野で、アクティブ/アクティブ パターンとアクティブ/パッシブ パターンの両方が含まれます。 一般的に、ArcGIS は、サービスのアクセスや公開に用いるデータ登録プロセスで DNS エイリアスまたはフレキシブル IP が使用されている場合に、これらの構成に接続できます。常に ArcGIS からアクセスされますが、プライマリー システムに障害が発生した場合、別のバックエンド データベースを指すこともあります。 このシナリオでは、ArcGIS コンポーネントはバックエンド データベースの変更を認識してせず、同じ認証情報、スキーマ、および行が使用可能であると想定して、期待どおりに動作し続けます。
高可用性に関連する賢明かつ効果的な選択を行うには、次の設計上の推奨事項を検討してください。