Free Press

暗号化モードでConsulを実行する詳細については、オンラインドキュメントを参照してください。

Consul プロセスは、設計概要で説明したようにデフォルト以外のポート (7xxx) で実行されていることに注意してください。

Consulリーダ選挙プロセスの詳細については、オンラインドキュメントを参照してください。 単一のHA Vaultクラスタでは、すべてのノードが同じストレージバックエンドを共有しているため、データを共有することができます。 Vaultは、Vaultサーバーの1つがデータストア内のロックを取得し、アクティブなVaultノードとなり、書き込み権限を持つことでこれを実現します。 リーダーを失った場合は、別のVaultノードがシームレスにリーダーとしてその地位を引き継ぎます。 n-2の冗長性（障害領域内の2つのオブジェクトの損失が許容される）を達成するために、Vaultクラスタの理想的なサイズは3です。Consulはコンセンサスとgossipプロトコルによりレプリケーションとリーダーシップを実現します。 これらのプロトコルでは、リーダーはコンセンサスによって選出されるため、アクティブなサーバーのアクオラムは常に存在しなければなりません。 詳細はConsulInternalsを参照してください。

“Availability Zone

クラウド環境における典型的な分散方法は、AWSリージョンなどの広帯域、低遅延ネットワーク内の別々のAZにConsul/Vaultノードを分散することですが、これはデータセンターのインストールで、必要な遅延レベル内で1つのDCしかない場合には不可能かもしれません。

Consulのような高度に分散したシステムをより多く利用するようになった結果、要件やベストプラクティスが変化したことを理解することが重要です。 分散システムで構成される環境を運用する場合、基盤となるコンポーネントの冗長性係数に変化が生じることが求められています。 Consulはコンセンサスネゴシエーションによって情報の整理と複製を行っているため、意味のある信頼性を提供するためには、3つの独自のレジリエントパスを提供する必要があります。 基本的に、コンセンサスシステムは、いつでも利用可能なノードの単純多数決を必要とします。 3つのノードの例では、2つのノードが利用可能である必要があります。 この3つのノードが2つの障害ドメインに配置されている場合、1つの障害ドメインを失うと50%の確率で完全な停止が発生します。

“リージョン

リージョンレベルでの障害から保護し、さらに地理的なスケーリング機能を提供するために、Vault Enterpriseは以下を提供します：

• 災害復旧レプリケーション
• パフォーマンス・レプリケーション

これらのオプションに関する詳細については、Vault Replicationの推奨パターンをご覧ください。

上記のような制約があるため、推奨するアーキテクチャは、VaultとConsul Enterpriseをアクラスター内の3つのアベイラビリティゾーンに分散し、DRとパフォーマンスレプリケーションを使って地域間でクラスターをレプリケートするものです。 また、1つまたは2つのアベイラビリティゾーンとConsul OSSのためのいくつかの「ベストケース」アーキテクチャのソリューションがあります。

「推奨アーキテクチャ」

以下のアーキテクチャは、Vault導入の推奨ベストアプローチであり、あらゆるインストールのターゲットアーキテクチャとなるべきものです。 これは 2 つの部分に分かれています。

• Vault クラスタ – これは 1 つのエンティティとしての Vault クラスタの推奨アーキテクチャですが、2 番目の図に従ってレプリケーションも使用する必要があります
• Vault レプリケーション – これは、地域、パフォーマンス、障害復旧を可能にする複数の vault クラスタに対する推奨アーキテクチャです。

“Single Region Deployment (Enterprise)

このシナリオでは、Vault ノードとそれに関連する Consul クラスターは、3 つの利用可能ゾーン間にホストされています。 このソリューションでは、Vault のノード レベルに n-2 があり、Consul のノード レベルに n-3 があります。 AvailabilityZone レベルでは、Vault は n-2 であり、Consul は n-1 です。 これはOSSの設計と異なり、Consulクラスタには6つのノードがあり、そのうち3つは投票権を持たないメンバとなっています。 Consulクラスタは冗長ゾーンを使用して設定されており、いずれかのノードに障害が発生した場合、非投票メンバーがAutopilotによって昇格してフルメンバーになり、クォーラムを維持します。

「複数リージョン展開（エンタープライズ）」

「参考図 リージョン障害に対する回復力」

このシナリオでは、クラスタは全リークジョン障害に備えるためにレプリケーションされています。 3つのパフォーマンス・レプリカVaultクラスタ（クラスタA、B、C）があり、それぞれ別のリージョンに独自のDRクラスタ（クラスタD、E、F）を持っています。 このアーキテクチャでは、すべてのシークレットとシークレットエンジンがすべてのクラスタにレプリケートされている場合、リージョンレベルでn-2が可能です。 完全なRegion1が故障した場合、DRクラスタFを昇格させる必要があります。 これが行われると、VaultsolutionはRegion1が回復するまで冗長性を失いつつも完全に機能します。

“参照図 クラスタ障害に対する耐障害性

このソリューションはクラスタレベルで完全な耐障害性を備えていますが、パフォーマンス レプリカのDRクラスタが同じ地域にあるため、地域の障害に対しては保護されません。 GDPRなどのガバナンスの制約により、データを他の地域にレプリケートできない場合、この方法が望ましいユースケースもあります。 また、インフラストラクチャのフレームワークによっては、アプリケーションのトラフィックを異なるリージョンにルーティングする機能がない場合もあります。

“ベストケースアーキテクチャ

一部の展開では、乗り越えられない制約があるため、推奨アーキテクチャが実現しない場合があります。 これは、利用可能なゾーンがないことや、Vault OSS を使用していることが原因である可能性があります。 このような場合、以下のアーキテクチャは、利用可能な最良のケースのオプションの詳細です。

これらのアーキテクチャでは、Consul リーダーは 5 つの Consul サーバー ノードのいずれかになり、Vault アクティブ ノードは 3 つの Vault ノードのいずれかになることに注意してください

“Vault in one Availability Zone (all)

このシナリオでは、すべての Vault ノードとその関連 Consul クラスタは 1 つの Availability Zone 内にホストされます。 このソリューションでは、アベイラビリティ ゾーン レベルで単一障害点がありますが、Consul と Vault の両方のノード レベルで n-2 が発生します。 これは、可用性ゾーン・レベルでの冗長性がないため、Hashicorp が本番システムに推奨するアーキテクチャではありません。 このシナリオでは、Vault ノードとそれに関連する Consul クラスターは、2 つの可用性ゾーンの間でホストされます。 このソリューションでは、Vault と Consul のノード レベルで n-2、利用可能ゾーン レベルで Vault の n-1 がありますが、利用可能ゾーンの追加によって Consul クラスターの利用可能性が大幅に向上することはありません。 これは、Raftプロトコルが(n/2)+1のアクオラムを必要とし、上の図でゾーンBが失敗した場合、クラスタがクォーレートされないため、失敗することになるからです。 これは、可用性ゾーンレベルでは部分的な冗長性しかなく、可用性ゾーンの障害が停止に至らない可能性があるため、Hashicorp が本番システムに推奨するアーキテクチャではありません。

「2つの可用性ゾーンでの Vault 展開（エンタープライズ）

Consul クラスタで定足数を保つ必要があるため、可用性ゾーンを 2つだけ設けることは理想的ではありません。 Consul クラスターを 2 つの AZ に分散して、回復力を追加する保証はありません。 Vault Enterpriseの最良のケースは、2つのAZをリージョンとして扱い、それぞれに別のVaultクラスタを設置することです。

セカンダリ Vault クラスターは、パフォーマンス レプリカまたは DR レプリカのいずれかになり、それぞれに利点があります。

• PR セカンダリ： Vault アドレスが Consul またはロード バランサーによって管理されている場合、アプリケーションまたは Vault エージェントに、クラスター間で複製されないトークンを再度要求して管理するロジックがある場合、いずれかのクラスターの障害によって、障害なしでトラフィックはもう一方のクラスターに転送されます。
• DR セカンダリ: この場合、プライマリ クラスターで障害が発生すると、DR をプライマリに昇格させるためにオペレーターの介入が必要になりますが、すべてのリリースとトークンがレプリケートされるため、アプリケーションでこれを処理するための追加のロジックは必要ありません。

“Deployment of Vault in three Availability Zones (OSS)

このシナリオでは、Vault のノードと関連する Consul クラスタは 3 つの Availability Zone の間でホスティングされます。 このソリューションは、VaultとConsulのノードレベルでn-2、Vaultの可用性ゾーンレベルでn-2を持ちます。また、Consulの可用性ゾーンレベルでn-1を持ち、そのため、単一のVaultクラスタとOSS製品のConsulストレージバックエンドに対するすべてのアーキテクチャの中で最も弾力性があると見なされています。

“Vault Replication (Enterprise Only)

これらのアーキテクチャでは、Vaultクラスタは単一のエンティティとして図示され、利用可能ゾーンの数に基づいて、上記の単一のクラスタの1つになります。 複数のVaultクラスタが1つのVaultsolutionとして動作し、それらの間でレプリケーションを行うことは、Enterprise Vaultでのみ可能です。 OSSVaultは、複数のクラスタでセットアップすることができますが、それらはそれぞれ個別のVaultソリューションとなり、クラスタ間のレプリケーションをサポートしません。

Vaultドキュメントでは、VaultEnterprise内のレプリケーション機能に関するより詳細な情報を提供しています。静的シークレット、認証方法、および承認ポリシーは、複数の場所で有効かつ利用できるようにレプリケートされますが、リーズストークンおよび動的シークレットはそうではありません。

“災害復旧レプリケーション

Vault 災害復旧レプリケーションは、スタンバイ Vault クラスターがアクティブ Vault クラスターとキーピング同期されることを保証します。 このモードのレプリケーションには、エフェメラル認証トークン、タイムベーストークン情報、およびトークン使用状況データなどのデータが含まれます。 これにより、一時的な運用データの損失を防ぐことが最も重要である環境において、積極的なリカバリーポイントの目標を設定することができます。

「破損または妨害によるディザスタ リカバリ」

保護すべきもう1つの一般的なシナリオは、非常に高いレベルの内在的回復力を提供するクラウド環境において、データと構成の故意または偶発的な破損、およびクラウドアカウントの制御損失が発生する可能性があることです。 VaultのDRレプリケーションは、ライブデータを複製するように設計されており、意図的または偶発的なデータの破損や削除が伝搬される可能性があります。 これは、定期的なアーカイブバックアップを自動化できるConsulSnapshot機能によってサポートされています。 冷えたサイトや新しいインフラストラクチャは、Consul スナップショットから再水和されます。

“Replication Notes

1 レプリケーションセット内のクラスタ数には、制限は設けられていません。 今日の最大規模のデプロイメントでは、30クラスタ以上の範囲になります。 パフォーマンス・レプリカ・クラスターは、それに関連するディザスター・リカバリー・クラスターを持つことができ、また、複数のディザスター・リカバリー・クラスターにレプリケーションできます。

Vaultクラスターは、レプリケーション・ロール（またはロール）を所有できますが、インフラの点で特別な配慮は不要で、クラスターは別のロールへの就任（または昇進または降格）することが可能です。 マウント フィルターとハードウェア セキュリティ モジュール (HSM) の使用に関連する特別な状況では、役割の割り当てが制限される場合がありますが、これらは特定の組織の構成に基づいています。

「HSM 統合に関する考慮事項

自動開封処理のためにハードウェア セキュリティ モジュール (HSM) または雲の自動開封デバイスと統合した Vault クラスタでレプリケーションを使用するには、計画段階で理解しておくべきいくつかの詳細事項があります。

• パフォーマンス プライマリ クラスターが HSM を使用する場合、そのレプリケーション セット内の他のすべてのクラスターも同様に HSM を使用する必要があります。
• パフォーマンス プライマリ クラスタが HSM を使用しない場合 (Shamir 秘密分散方式を使用)、そのレプリケーション セット内のクラスタは混合することができ、一部は HSM を使用し、その他は Shamir を使用することが可能です。 下流の Shamir クラスターは、鍵所有者の閾値がマスター鍵を作成することができるため、レプリケーション グループに潜在的な攻撃ベクトルを提示し、したがって、上流の HSM 鍵保護をバイパスします。 Vault 1.3 では、マスター・キーは、マスター・キーがオート・アンシール・キーによって暗号化され、ディスクに保存されるのと同様に、共有キーで暗号化され、ディスクに保存されます。 これにより、Shamirの秘密分散アルゴリズムまたは自動解除のいずれを使用しているかにかかわらず、一貫した動作が提供され、上記の3つのシナリオをすべて有効にすることができるようになります。 しかし、Vaultがガバナンスや規制コンプライアンス要件の対象となるデータを保護している場合、自動開封のためにダウンストリームHSMを実装することをお勧めします。

listen vault bind 0.0.0.0:80 balance roundrobin option httpchk GET /v1/sys/health server vault1 192.168.33.10:8200 check server vault2 192.168.33.11:8200 check server vault3 192.168.33.12:8200 check

Copy