大規模グループ会社のクラウドプラットフォームアーキテクチャの分析アイデア

過去 20 年にわたり、多くの国内大手グループ会社は、OA システム、ERP システム、CRM システム、HRM システム、さまざまな業界アプリケーション システムを含む巨大なビジネス情報システムを構築してきました。これらのシステムを長期安定的に運用するために、監視システム、本人認証システム、セキュリティオペレーションセンターなどの情報システムを構築しています。しかし、これらの情報システムは通常、建設期間中に独自に入札・調達され、ソフトウェアやハードウェアのリソースを独占しており、入札の一元化や他のシステムとのリソースの共有が行われていないため、リソースの無駄や高額な構築コストの問題が蔓延しています。運用保守期間中も、独立した運用保守が採用され、運用保守の人員、ツール、技術が他のシステムと共有されないため、運用保守コストが高くつき、効率が低くなります。既存の情報システムの規模が拡大し、新たなシステムが追加されるにつれ、リソースの無駄、運用保守の非効率性、コストの高さといった問題が顕在化しています。そこで、これらの課題を解決するためにプライベートクラウドを導入する大手グループ企業が増えています。

ただし、大規模なグループ会社はITインフラ面での特徴が顕著であり、クラウドコンピューティングのニーズも比較的独特であるため、クラウドプラットフォーム全体のアーキテクチャを設計する際には、ITの現状と現状を組み合わせて設計する必要があります。大規模なグループ会社のクラウド コンピューティングのニーズ。本稿では、こうしたニーズに応えるため、業界標準のクラウドプラットフォームアーキテクチャをベースに、大規模グループ企業のクラウドコンピューティングニーズに対応できる適応性を備えたクラウドプラットフォームアーキテクチャを提案する。

大手グループ会社のITインフラの特徴

大規模なグループ会社での長年の情報化構築を経て、その IT インフラストラクチャは徐々に次のような特徴を形成してきました。

1) IT 組織構造は比較的複雑です。 大規模なグループ会社は、事業を遂行するために全国、さらには世界中に子会社を設立します。グループレベルでは、本社レベルの情報管理部門を設置します。子会社は通常、独自の IT 部門も設置します。一部の大規模グループ会社は、企業はITシステムの構築と運用保守を専門に行う子会社も設立する。さらに、大規模なグループ会社は長年にわたり事業開発のニーズに基づいて統合または分割されており、それに伴いIT部門も統合または分割されてきました。これらの要因は、大規模なグループ会社の非常に複雑な IT 組織構造に直接つながります。一般的には子会社が複数の情報システムの構築・運用・保守を請け負い、情報システムごとに専門のプロジェクトチームを設置します。

2) データセンターには階層構造があります。 大規模なグループ企業は通常、「2 か所 3 センター」の本社レベルのデータセンター アーキテクチャを構築しているか、構築する予定であり、各支店が近隣に地域データ センターを構築できるようにしています。本社レベルのデータ センターと地域レベルのデータ センターは、データ センターの 2 レベルのアーキテクチャを形成しており、この 2 つは WAN を通じて相互接続されています。通常、本社レベルのデータセンターはグループ会社全体で使用される情報システムを展開しますが、地域レベルのデータセンターは地域子会社専用の情報システムやネットワーク遅延の影響を受けやすい情報システムを展開します。

3) IT リソースは非常に多様です 大規模なグループ会社では、すでに多数の情報システムが存在します。各情報システムは、異なる時期に異なるプロジェクト チームによって構築され、購入したソフトウェアとハ​​ードウェアは異なるメーカーの異なる製品であるため、多数の情報システムが共存しています。異種の IT リソース。

4) IT リソースの割り当て戦略を多様化します。 大規模なグループ会社では、各情報システムのリソース割り当て戦略が異なる場合があります。基幹システムは最適なパフォーマンス割り当て戦略を採用する必要があり、非基幹システムは最適な使用率割り当て戦略を採用できます。パフォーマンス要件が必要 物理マシンのデプロイメントが使用され、パフォーマンス要件が低い一部のアプリケーションは仮想マシンにデプロイできます。

5) レガシーな情報システムがたくさんあります。 クラウドプラットフォームを構築する前に、大規模なグループ会社はすでに監視システム、ITSMシステム、CMDB、本人認証システム、セキュリティオペレーションセンターなどの支援情報システムを保有しており、これらの支援情報システムが提供する機能は完全なクラウドに属する必要があります。一部ではありますが、クラウド基盤を構築する前からすでに存在しているため、クラウド基盤を構築する際に改めて構築する必要はなく、どのように統合するかを検討する必要があります。

大規模グループ会社のクラウドコンピューティングビジネスニーズ

大規模なグループ会社の IT インフラストラクチャの特性により、クラウド プラットフォームのビジネス要件も比較的独特です。

1) クラウドプラットフォームのテナントシステムは多層構造として設計する必要があります。

図 1 に示すように、クラウド プラットフォームのアーキテクチャでは、マルチレベルのテナントを設計する必要があります。ルート テナントはグループ会社全体に相当し、グループ会社内のすべてのクラウド リソース、つまりすべてのクラウド リソースを一元的に管理および分散します。クラウドプラットフォームによって管理されるリソース。第一階層テナントは子会社階層に相当し、情報システムの構築・管理単位となり、一つの子会社が複数の情報システムを管理することができます。セカンダリテナントは、情報システムの具体的な構築や運用保守のプロジェクトチームである情報システムレベルに対応することができ、大規模子会社の場合は、社内部門にマッピングしてその配下に設置することも可能です。第三層テナントの情報システムへ。下位テナントがリソースを必要とする場合、上位テナントにリソース割り当てを申請し、上位テナントは現在テナントが利用可能なリソース割り当てを確認し、十分であれば下位テナントに割り当てます。 -level tenant. 足りない場合は、上位テナントからリソース クォータを申請します。ルート テナントのリソース割り当ては、クラウド プラットフォームで使用可能なすべてのリソースのセットであり、ルート テナントのリソース割り当てが不足している場合は、リソースの拡張を適時に実行する必要があることを意味します。このマルチレベル テナント アーキテクチャは、設計パターンにおける複合パターンの特定のアプリケーションです。

図 1 – クラウド プラットフォームのテナント システム

2) クラウド プラットフォームのリソース管理システムは、データ センターの 2 レベルのアーキテクチャを考慮する必要があります。

図 2 に示すように、クラウド プラットフォームは 2 レベルのリソース管理システムを設計する必要があります。ローカル リソース管理モジュールは、このデータ センター内のリソースを管理および制御し、このデータ センターのリソース リストとリソース使用状況を報告します。グローバル リソース管理モジュールに送信され、グローバル リソース管理モジュールによって発行された命令を受信して​​実行します。グローバル リソース管理モジュールは、各ローカル リソース管理モジュールによって報告されたリソース情報を収集および要約して、リソースのグローバル ビューを形成し、リソースを均一に管理およびスケジュールします。すべてのデータセンターに配置され、ローカルのリソース管理モジュールに指示を発行します。導入の観点から見ると、ローカル リソース管理モジュールは本社レベルのデータ センターや地域データ センターを含むすべてのデータ センターに導入されますが、グローバル リソース管理モジュールは本社レベルのデータ センターにのみ導入されます。

図 2 – クラウド プラットフォームのリソース管理システム

3) クラウド プラットフォームのリソース管理モジュールは、さまざまな異種リソースをサポートする必要があります。

大規模なグループ会社には多くの異種リソースがあるため、リソース管理モジュールは、API または CLI を介してさまざまな基盤となるリソースを直接操作することを避け、代わりに、リソース アダプターがさまざまな基盤となるリソースに適応できるように、中間にリソース アダプターを追加する必要があります。さまざまなメーカーやモデルのリソースに対応するため、図 3 に示すように、リソース アダプタはリソース管理モジュールに統合リソース管理 API を提供します。新しい異種リソースに適応する必要がある場合は、リソース管理モジュールのコードを変更せずに、リソース アダプターを適応して統合するだけで済みます。これは実際、デザイン パターンにおけるファサード パターンの具体的な応用例です。

図 3 – リソース アダプター

4) クラウド プラットフォームは、リソース割り当て戦略のカスタマイズをサポートする必要があります。

クラウド プラットフォームには、いくつかの共通のリソース割り当て戦略が組み込まれますが、クラウド プラットフォームにすべてのリソース割り当て戦略が組み込まれることは不可能です。クラウド プラットフォームでは、情報システム管理者が次の基準に従ってリソース割り当て戦略をカスタマイズできる必要があります。ビジネス ニーズに合わせてクラウド プラットフォームを設計する必要があります。 ポリシーの定義、解析、実行を担当するポリシー エンジン モジュール。これは、デザイン パターンにおける Strategy パターンの具体的な応用でもあります。

5) クラウド プラットフォームは、既存のサポート情報システムと統合する必要があります。

クラウド プラットフォーム自体もサポート情報システムです。完全なクラウド プラットフォームには、監視、本人認証、ログ分析などの機能が必要です。ただし、これらの機能は既存のサポート情報システムにすでに存在していることがよくあります。クラウドを設計するときは、これらの既存のサポート情報システムの再利用と既存の IT 投資の保護を十分に検討するには、クラウド プラットフォームがこれらのシステムとのデータ交換やアプリケーション統合のためのさまざまな統合インターフェイスを予約する必要があります。ここではデザインパターンのAdapterパターンを使用します。

大手グループ会社のクラウドプラットフォームアーキテクチャの概要

前述の大規模グループ会社のクラウド コンピューティング ビジネス ニーズを考慮し、産業用クラウド コンピューティング プラットフォーム アーキテクチャと関連する国際標準を参照して、この記事では図 4 に示すようなクラウド プラットフォーム アーキテクチャを提案します。

クラウド プラットフォーム フレームワークには、リソース アダプター、リソース プール、リソース管理モジュール (ローカル リソース管理モジュールおよびグローバル リソース管理モジュールを含む)、ポリシー エンジン、プロセス エンジン、リソース オーケストレーション モジュール、サービス管理モジュール、ポータル モジュール、運用管理が含まれます。モジュール、運用保守管理モジュール、プラグイン管理モジュール。以下のリソース アダプターは、基礎となる異種 IT リソースを適応、編成、統合してさまざまなリソース プールを構築する役割を果たし、上位のリソース管理モジュールに統合リソース管理 API を提供します。リソース管理モジュールは、リソース プールの管理、リソース ライフ サイクルに応じたリソース プール内のリソースの管理、およびユーザーのニーズに応じたリソース プールからのリソースの割り当てとスケジューリングを担当します。

リソースをより柔軟に割り当ててスケジュールするために、このアーキテクチャではプロセス エンジン、ポリシー エンジン、およびリソース オーケストレーション モジュールが設計されています。プロセス エンジンは、さまざまな自動プロセスを実現するためにさまざまな操作ステップを接続する役割を果たします。ポリシー エンジンは、管理者がビジネス ニーズに応じてリソース割り当て戦略をカスタマイズできるようにします。リソース オーケストレーション モジュールは、さまざまなクラウド リソースを調整して接続し、関連するリソース構成を形成する役割を果たします。テンプレートを使用して、複雑な情報システムの迅速な導入または拡張を可能にします。サービス管理モジュールは、クラウド サービスのライフ サイクルに従ってクラウド サービスを管理します。ポータルモジュールは、クラウドプラットフォーム利用者、テナント管理者、プラットフォーム管理者それぞれに統一された操作インターフェースを提供します。運用保守管理モジュールは、クラウド プラットフォームとリソース プールの技術的な運用保守を担当し、ITIL v3 標準に準拠し、マシンとシステムを対象としています。運用管理モジュールは、ユーザーやテナントと対峙するクラウドプラットフォームの業務運営を担当します。プラグイン管理モジュールは、クラウド プラットフォーム用のプラグイン メカニズムを提供し、さまざまなプラグインを通じて既存のサポート情報システムと統合します。各ビジネス情報システムは、ビジネス ニーズに基づいて必要なクラウド サービスを特定し、クラウド プラットフォームでのサービスの作成とリリースを完了し、サービス カタログを作成し、クラウド サービスを申請することで情報システムの導入を完了します。

図 4 – クラウド プラットフォームのアーキテクチャ

大規模なグループ会社は、多数の異種ネットワーク、ストレージ、仮想化、および物理マシンのリソースを保有しています。ネットワーク リソースには、さまざまなメーカーのさまざまな技術仕様を持つファイアウォール、ロード バランシング、ネットワーク スイッチなどが含まれます。ストレージ リソースには、さまざまなメーカーやモデルのストレージ アレイや SAN スイッチが含まれます。仮想化リソースには、さまざまなメーカーやさまざまなバージョンのハイパーバイザーが含まれます。;物理マシンリソースには、さまざまなメーカーやモデルの x86 サーバーやミニコンピューターが含まれます。クラウド プラットフォームのリソース管理モジュールに統一された API インターフェイスを提供するために、ネットワーク リソース アダプター、ストレージ リソース アダプター、仮想化アダプター、物理マシン アダプターなど、クラウド プラットフォーム アーキテクチャ内のリソースの種類ごとにリソース アダプターが設計されます。これらのアダプターは、基になるリソースの異質性や複雑さからリソース管理モジュールを保護します。リソース管理モジュールはアダプターの API を呼び出すだけでよく、アダプターは実際に基になるリソースを制御します。さらに、アダプターは、ネットワーク リソース プール、ストレージ リソース プール、仮想サーバー リソース プール、および物理サーバー リソース プールを形成するようにさまざまな異種リソースを適応させることにより、さまざまな異種リソースを編成、統合、およびプールします。もちろん、クラウド プラットフォームは、同じ機能と属性を持つリソースを一定のルールに従って同じリソース プールに配置する必要があります。たとえば、高性能のストレージ リソースをゴールド ストレージ リソース プールに配置し、中性能のストレージ リソースをゴールド ストレージ リソース プールに配置する必要があります。シルバーストレージリソースプール。リソース管理モジュールの観点からは、基盤となる異種リソースではなく、さまざまなリソース プールが表示されます。

リソース プールの上には、ローカル リソース管理モジュールとグローバル リソース管理モジュールを含むリソース管理モジュールがあります。ローカル リソース管理モジュールは、ローカル データ センターのリソース プールの管理と制御、リソース プール内のリソースのクラウド プラットフォームへの管理に重点を置き、グローバル リソース管理モジュールによって発行されたリソース展開コマンドの実行、割り当て、スケジューリング、および拡張および監視し、その結果をグローバル リソース管理モジュールにフィードバックします。リソース割り当てとは、システムの展開時にシステムに最適なリソースを選択することを指します。リソース スケジューリングとは、リソースの垂直方向または水平方向のスケーリングを指します。システム運用中の業務量の増減。グローバル リソース管理モジュールは、各ローカル リソース管理モジュールによって報告されたリソース情報を収集および要約して、リソースのグローバル ビューを形成します。グローバル ビューは、テナント、データ センター、リソース タイプ、およびその他の次元に応じて表示できます。さまざまなデータセンター リソースの場所を均一に監視、割り当て、スケジュール設定します。また、グローバル リソース管理モジュールは、ユーザー リソース展開リクエストの統合処理と、各ローカル リソース管理モジュールへのリソース割り当ておよびスケジュール コマンドの発行も担当します。ローカル リソース管理とグローバル リソース管理は 2 レベルのリソース管理システムを構成し、リソースの集中管理と制御、および分散展開の効果的な組み合わせを実現します。

ポリシー エンジンは、リソース割り当てポリシーの定義、解析、実行を担当し、ポリシーに基づいて自動割り当てとスケジューリングを実現します。ポリシー ウェアハウス内のポリシーがビジネス要件を満たさない場合は、管理者がポリシーをカスタマイズすることもできます特定のポリシーによってリソースが割り当てられ、スケジュールが設定され、カスタマイズされたポリシーはポリシー ウェアハウスに保存され、他の情報システムで再利用できます。この戦略には、情報システムの導入時に最適なリソースを選択する戦略である割り当て戦略と、システムの保守や増強の要求に応じてリソースを調整および移行する戦略であるスケジューリング戦略が含まれます。またはシステム稼働時の業務量の減少。

プロセス エンジンは、リソース割り当て、スケジューリング、構成、運用および保守プロセスに含まれる実際の運用ステップを接続して、運用ステップの自動フローを実現し、サーバー自動化プロセスやネットワーク自動化などの複雑な自動化プロセスをさらに実現します。プロセス、ストレージ自動化プロセスなどプロセス エンジンを使用すると、管理者はプロセスを定義および調整できます。実際のリソース割り当て、スケジューリング、構成、および運用およびメンテナンスのプロセス中に、プロセス エンジンは関連するプロセスを解析して実行し、自動化されたプロセスに構成可能な機能を提供します。管理者が作成したプロセスをプロセス ウェアハウスに保存し、プロセスを再利用できます。

サービス管理は、クラウド サービスをライフ サイクルに従って管理します。これにより、管理者はクラウド サービスの展開モデルと機能モデルを定義し、展開モデルに対して特定の自動プロセスと配布戦略を設定できるようになり、管理者はクラウド サービスのアプリケーションを設定できるようになります。ユーザー入力パラメータ。ユーザーが必要なクラウド サービスを申請した後、サービス管理モジュールはサービスをアクティブ化し、サービスのアクティブ化に関連する自動プロセスをプロセス エンジンに通知します。プロセス エンジンはそれを解析して実行し、サービスのアクティブ化に関連するリソース割り当て戦略を割り当てます。サービスのアクティブ化。ポリシー エンジンに通知し、ポリシー エンジンがそれを解析して実行します。ポリシー エンジンは、リソース割り当て要求をグローバル リソース管理モジュールに送信し、最後にサービス管理モジュールに返して、サービス アクティベーション アクションを完了します。サービスがアクティブ化された後、クラウド プラットフォームは、標準化された運用および保守作業を通じて、提供されるサービスの SLA がユーザーの要件を満たしていることを確認する必要があります。

リソース オーケストレーション モジュールは、管理者 (テナント管理者またはプラットフォーム管理者) がクラウド プラットフォーム内のさまざまなクラウド リソースを構成、結合、オーケストレーション、接続して、情報システムの特定のトポロジに適応するリソース テンプレートを形成するためのグラフィカル インターフェイスを提供します。管理者がリソース テンプレートを定義した後、それを新しい複合クラウド サービスとして公開できます。複合クラウド サービスに対するユーザーのアプリケーションは、サービスのアクティベーションをトリガーします。リソース オーケストレーション モジュールは、リソース テンプレートとユーザー入力パラメーターを解析して、リソースの種類、属性、数量に関する特定の要件を生成し、それらをグローバル リソース モジュールに渡します。リソースの割り当てと展開。管理者は、テンプレート ウェアハウスの組み込みテンプレートを変更して、自分のニーズを満たすリソース テンプレートをすばやく定義できます。作成したリソース テンプレートは、再利用するためにテンプレート ウェアハウスに保存することもできます。

ポータル モジュールは、ユーザー ポータル、テナント管理ポータル、プラットフォーム管理ポータルを提供します。ユーザー ポータルは、クラウド サービスのエンド ユーザーに直感的で使いやすいセルフサービス インターフェイスを提供し、エンド ユーザーはサービス アプリケーション、リソースの表示、リソースの操作などを完了できます。テナント管理ポータルは、テナント管理者に直観的で使いやすいセルフサービス管理インターフェイスを提供します。このインターフェイスでは、テナント管理者はクォータの適用、ユーザーの作成、このテナントに表示されるサービスの定義、リソース テンプレートの定義、割り当ての定式化を行うことができます。このテナントに適した戦略など。プラットフォーム管理ポータルは、クラウド プラットフォーム管理者に直感的で使いやすい操作インターフェイスを提供し、システムの保守と運用の分野でさまざまなタスクを完了するのに役立ちます。

運用保守管理モジュールは、クラウドコンピューティングプラットフォームのシステム運用保守機能を担い、ITIL V3規格に準拠し、キャパシティ管理、パフォーマンス管理、セキュリティ管理、日常管理などの機能を提供します。キャパシティ管理は、リソースの過去の運用状況の統計分析を実行し、キャパシティ予測モデルに従って将来のリソース需要を予測します。性能管理では、リソースの性能指標をリアルタイムに収集することでリソースの稼働状況を監視し、指標が一定の閾値を超えた場合にアラームイベントを生成し、対応するイベント処理プロセスを呼び出します。セキュリティ管理には、サーバー セキュリティ、ストレージ セキュリティ、データ セキュリティ、ネットワーク セキュリティ、仮想化セキュリティが含まれます。日常管理には、障害管理、問題管理、構成管理、システム管理、監視管理、変更管理が含まれます。運用保守管理モジュールに係る機能が既存の支援情報システムに既に存在する場合、新たなクラウドプラットフォームに機能を実装する必要はなく、プラグイン管理モジュールにより既存の支援情報システムに対応します。 . 機能モジュールが統合されています。

運用管理モジュールは、ユーザー管理、テナント管理、クォータ管理、権限管理、計測および請求管理、その他の機能を含む、クラウド コンピューティング プラットフォームのビジネス運用機能を担当します。ユーザー管理では、ユーザーを作成、グループ化し、承認します。テナント管理は、マルチレベルのテナントの管理と構成、テナント間の親子関係、テナントとユーザーの使用関係、テナントとクォータの関連付けなどの維持を担当します。クォータ管理は、すべてのレベルのテナントによるリソースの使用がクォータを超えないように、すべてのレベルのテナントにリソースを割り当てる責任があります。権限管理は、ユーザーの操作およびデータの権限を指定する責任があります。メータリングと請求管理は、テナントのリソース使用量を測定し、メータリング データを保存し、メータリング レポートを定期的に生成します。メータリング情報には、リソース タイプ、リソース使用量、および使用時間が含まれます。プラットフォーム管理者は、さまざまなリソースの料金を設定できます。システムはテナントの費用を生成できます。メーター情報と料金に基づいたリスト。

プラグイン管理モジュールは、主に既存の支援情報システムと統合するように設計されており、プラグイン管理モジュールは、既存の支援情報システムがプラグインを通じてクラウド プラットフォームに必要な機能を提供できるようにするプラグイン メカニズムをセットアップします。同時に、他のビジネス情報システムがクラウド プラットフォームに機能を追加することもでき、クラウド プラットフォームは、さまざまなプラグインを通じて、既存の支援情報システムや他のビジネス情報システムとのデータ交換やアプリケーションの統合を実行します。クラウドプラットフォームの運用保守管理モジュールは不要です。監視機能を実装する代わりに、従来の監視システムの関連機能を監視プラグインを通じて再利用します。

要約

この記事で提案するクラウド プラットフォーム アーキテクチャは、大規模なグループ会社の IT インフラストラクチャの特性に適応するために、マルチレベルのテナント管理システム、2 レベルのリソース管理システム、リソース アダプタ モジュールを特別に設計しています。 、プラグイン管理モジュール、ポリシーエンジンなど、ある程度利用できる機能を備えており、大規模グループ会社のクラウドコンピューティングビジネスニーズにある程度対応できるが、クラウドの複雑性も増大する大規模なグループ会社がこのクラウド プラットフォーム アーキテクチャを参照する際には、その作業内容を詳細に評価する必要があります。また、このアーキテクチャは IaaS レベルに焦点を当てており、PaaS の特殊性は考慮されていないため、PaaS プラットフォームのアーキテクチャを設計する際には、関連する機能モジュールも補完する必要があります。

以上が大規模グループ会社のクラウドプラットフォームアーキテクチャの分析アイデアの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。