Fujitsu K5 Technology Shared Service Design Pattern – 高可用性

2017-01-13

Machine-translated — the English original is authoritative.

以下の設計パターンは、K5上でテクノロジー共有サービスプラットフォームを実装する方法の例です。このアーキテクチャと以前の共有サービスに関するブログ記事との違いは、異なるアベイラビリティゾーン（AZ）内のサブネット間で内部高速リンクを提供するために、Inter-Availability-Zoneコネクタを含めた点にあります。これにより、従来のアプリケーションやクラウドネイティブアプリを2つのAZ間で簡単に分散配置することが可能になりました。ネットワークトラフィックはインターネットを通過しません。以下に示す全体アーキテクチャは、HEATスタック、すなわちK5/OpenStackのインフラストラクチャオーケストレーションプロジェクトのおかげで、最小限の労力で自動的にデプロイすることができます。

ネイティブOpenStackユーザーへの注意：ここで議論されているInterProjectおよびInterAvailability Zoneリンクは、Fujitsuがパブリッククラウドで使用するためにOpenStack Neutron APIに対して行った機能強化です。

DMZ

DMZプロジェクトは、ソリューションへのトラフィックのルーティングおよびソリューションからのトラフィックのルーティングに使用されます。プロキシサーバーを使用して、他のプロジェクトへのインターネットアクセスを提供/制御することができます。各DMZには、サーバーコンソールへの冗長アクセスを提供するために、GuacamoleなどのHTTPSターミナルサーバーをインストールできます。

各AZには2つの仮想ルーターがインストールされます。1つはすべてのプロジェクト間ルーティングを管理し、もう1つはFWaaSと組み合わせてインターネット境界でのアクセスを制御するために使用されます。オプションとして、GuacamoleサービスのHAを提供するために、パブリック向けLBaaSインスタンスをここに配置することもできます。

共有サービス

このプロジェクトは、メール（ただし、K5がPaaSオファリングとしてもこれを提供していることを忘れないでください）、ファイル共有、gitリポジトリなど、他のプロジェクトに提供したいすべての共有サービスをホストするために使用されます。ネットワークコネクタを使用して、アベイラビリティゾーン間の共有サービスサブネットをリンクし、クリティカルなサービス間でデータの高速同期を可能にします。必要に応じて、内部向けLBaaSもここで使用できます。設計上、これらのサブネットにはDNATおよびSNATの機能がありません。これを実現するには、DMZ内のプロキシサービス（K5の一部ではありません）を活用する必要があります。代替案としては、このサブネットを別の仮想ルーターを介してインターネットに直接リンクし、必要なモデルを破棄することが考えられますが、それは推奨されません 🙂

部門A/B/C…など

これらはエンドユーザーが消費するプロジェクトです。これらには、共有サービスプロジェクトで利用可能なのと同じHA機能が公開されます。このモデルにより、コアサービスを維持したまま、需要に対応するために迅速かつ容易なデプロイ、破棄、再デプロイが可能になります。

セキュリティグループは、すべてのホストに対してネットワークセキュリティの追加レイヤーを提供するために全体で使用されます。

概要

完全な共有サービスモデルは、K5のInfrastructure as Code（IaC）HEATテンプレートを使用して、迅速かつ一貫して繰り返しデプロイすることができます。ますます多くの顧客が、Continuous IntegrationおよびContinuous Deployment（CI/CD）の取り組みを支援するために、このようなモデルを活用しています。これにご関心がある場合は、急速なアプリケーション開発のためにCloud Foundryも検討することをお勧めします。K5はCloud Foundryプラットフォームも提供しています。

Happy Stacking.

withk5youcan

Originally published on allthingscloud.eu (2017-01-13).