分散アーキテクチャはデータセンターの未来でしょうか?

1. データセンターとは何ですか?

データセンターとは何ですか? Baidu 百科事典では、データ センターは、インターネット インフラストラクチャ上でデータ情報を送信、加速、表示、計算、および保存するために使用される特定のデバイスのグローバルな共同ネットワークであると定義されています。データセンター内のほとんどの電子部品は、低電圧の DC 電源で駆動されます。

データセンターの出現により、人々の理解は定量的で構造化された世界から不確実で非構造化された世界へと移行しました。交通やネットワーク通信と同様に、データセンターも徐々に現代の社会インフラの一部となり、多くの産業にプラスの影響を与えるでしょう。しかし、データセンターが真に価値ある役割を果たし、急速な社会変革を促進するためには、データセンターの開発は経験だけに頼るのではなく、実践と真に結び付けられる必要があります。

[[281406]]

分散型データセンターがなぜ必要なのでしょうか?

発展といえば、さまざまな産業が栄える中、データセンターが急速に建設されつつあります。クラウドコンピューティング、ビッグデータ、モノのインターネットなどの新技術の大規模な利用により、医療、政府、インターネット、金融などの業界ではデータセンターの建設が注目されるようになりました。特に銀行や保険の分野では、基幹業務を担い、データの途切れが許されず、業務の変化に迅速に対応し、一定の柔軟性が求められることから、データセンターはまさに「生産拠点」となっています。データセンターを見ると、従来の集中型アーキテクチャでは、もはや新しい時代のビジネスニーズを満たすことができません。分散アーキテクチャに基づくデータセンターは、集中型アーキテクチャに対応する技術システムです。これには、分散ビジネス展開、分散コンピューティング、ストレージ、ネットワーク セキュリティなどの分散テクノロジのコレクションが含まれます。従来のデータ センターではビジネスの応答性、継続性、柔軟性を保証できず、開発が一定のボトルネックに達すると、分散アーキテクチャが必然的に選択されます。

データセンター構築の初期の頃は、ほとんどの IT ビルダーは、どのような技術アーキテクチャを採用するかはそれほど重要ではないと考え、あまり注意を払っていませんでした。データセンター構築の重点は、そこに搭載される業務システムの安定した運用を確保し、サーバー、ストレージ、ネットワーク機器に良好な動作環境を提供し、業務システムが簡単に「クラッシュ」しないようにすることです。そのため、初期のデータセンターのほとんどは、煙突型のアーキテクチャで設計されていました。各業務システムには独立したハードウェア機器が装備されており、データは完全に断片化されていたため、機器の使用率が非常に低く、リソースを共有することがまったくできませんでした。一般的な「標準構成」ソリューションは、2 台のハイエンド ミニコンピュータ (または X86 サーバー) をデュアル データベース サーバーとして使用し、2 台以上のアプリケーション サーバーを追加し、バックエンドを 2 台の FC スイッチ (または IPSAN スイッチ) とストレージ デバイスに接続することです。現在でも、多くの入札書類で同様の構成スキームが見られます。もちろん、この構成が悪い、または間違っているということではありません。適切な計画と合理的な使用がなければ、このような構成ではデータセンターのスペース、エネルギー消費、冷却の大幅な増加につながるとしか言えません。また、設備の恣意的な増加は、運用・管理の効率に重大な影響を及ぼします。

情報化の急速な発展に対応し、設備の利用度と柔軟性を向上させるために、クラウドコンピューティング技術が大規模に推進され、導入されています。クラウド コンピューティングは、利用可能で便利なオンデマンドのリソースを提供できるため、徐々に主流のデータ センター アーキテクチャになりつつあります。現在、ほとんどの業界のデータセンターにはすでにクラウド コンピューティング機能が備わっている。大規模データベースなどの一部のビジネス シナリオを除き、新しいビジネス アプリケーションは基本的にクラウド モデルを使用して構築されます。同時に、既存のビジネス アプリケーションの多くがクラウド コンピューティング環境に継続的に移行しています。仮想化環境でアプリケーション システムを実行することが標準になっているようです。クラウド コンピューティング環境では、サーバー仮想化は基本的なクラウド コンピューティング テクノロジの 1 つです。仮想化ソフトウェアベンダーは、物理リソースに基づくデータセンターを仮想化リソースに基づくデータセンターに徐々に移行し、データセンター内のサーバーの数と規模の増加を効果的に制御し、サーバーの利用効率を向上させています。同時に、仮想化システムの特性により、データセンター システムの信頼性が大幅に向上します。特に、アクティブ運用・保守、災害復旧構築、障害切替の面では、データセンターの事業継続性にとって質的な飛躍となります。この段階では、仮想化テクノロジを大規模に適用することで、従来のデータセンターは集中型アーキテクチャを変更することなく、最大限のリソース統合と共有を実現できるようになりました。ただし、アーキテクチャはあまり変更されておらず、むしろサービス モデルの変革でした。

クラウドコンピューティングアーキテクチャに基づくデータセンターの構築は主流の構築モデルとなっていますが、アーキテクチャにはまだ改善の余地が多く残っています。

1. クラウド コンピューティング アーキテクチャに基づくデータ センターでは、単一のデータ センター内でのリソースの共有や使用などの問題しか解決できず、リソースの柔軟な拡張の問題を解決できません。リソースの増加は依然として垂直アーキテクチャを採用しています。個々のコンピューティング、ストレージ、またはネットワークデバイスにはパフォーマンスの限界があるため、一定の容量まで拡張した後は分割してリソースプールに再構築する必要があります。これにより、新しいリソースアイランドが形成され、データセンターの開発の問題が根本的に解決されません。

2. さまざまな業界で情報化が進むにつれ、さまざまな地域に複数のデータセンターを構築する必要のある企業が増えています。例えば、銀行業界と保険業界では、中国銀行業監督管理委員会と中国保険業監督管理委員会の要件に従って災害復旧センターを構築し、グループ会社は支店データセンターを構築します。これらのデータ センターを統一的に管理および適用し、ビジネスの継続性を確保し、ビジネス コラボレーションの問題を解決する方法は、従来のデータ センターにとって大きな課題です。

クラウド コンピューティング ベースのデータ センターは、より多くのサービスを提供します。通常、クラウド コンピューティングについて話すときは、コンピューティング、ストレージ、ソフトウェア、およびその他のサービスの相互作用と使用のモードを意味します。分散アーキテクチャに基づくデータ センターは、サービスの形式ではなく、データ センターのコンピューティング モデルを指します。クラウド コンピューティング データ センターの技術的な基盤と拡張です。

3. 集中型データセンターと分散型データセンターの違い

技術的なレベルでは、分散アーキテクチャ データ センターには、主に、単一のデータ センター内の分散アーキテクチャと複数のデータ センターの分散アーキテクチャという 2 つの概念が含まれます。

単一のデータセンター内の分散アーキテクチャには、主に、分散コンピューティング、ストレージ、安全なネットワークなどのさまざまな分散テクノロジの集合が含まれます。複数のデータ センターの分散アーキテクチャとは、主に複数の従来のデータ センターを 1 つのデータ センターに統合することを指します。事業継続、災害復旧、マルチセンター運用管理などを実現します。例：統合管理プラットフォームを使用して、地域や規模の異なる複数のデータセンターのリソースを管理し、統合運用プラットフォームを使用して統合運用を実現します。

3.1 分散コンピューティングアーキテクチャ

分散コンピューティングの定義によれば、ネットワークを使用して数千台のコンピュータを接続し、仮想スーパーコンピュータを形成して、単一のコンピュータでは解決できない超大規模な問題を解決することです。

データ センターにおける分散コンピューティングは、分散ソフトウェア アーキテクチャを指します。これは、分散コンピューティング テクノロジに基づくソフトウェア アーキテクチャであり、大規模な問題を解決するために使用されます。分散ソフトウェア アーキテクチャは優れたスケーラビリティを備えており、特にビッグ データの問題を処理する場合、分散アーキテクチャによって処理速度が大幅に向上します。一般的な分散ソフトウェア アーキテクチャには、分散オペレーティング システム、ファイル システム、データベースが含まれます。

データベースを例にとると、従来のデータセンターは主に単一のデータベースに基づいており、データはサーバーまたはストレージに集中的に保存され、データ処理も単一または複数のクラスターノード（通常 2 ～ 8 個）に集中しています。従来のデータセンター データベースは主に Oracle、Db2、または MySql です。ただし、単一のテーブル内のデータ量が爆発的に増加したり、単一のデータベースが高強度の I/O に耐えられなくなったりすると、集中型アーキテクチャではパフォーマンスとデータ処理のボトルネックの問題を解決できなくなります。 Taobao は初期の頃は Oracle データベースを使用しており、世界最大の Oracle データベース クラスターを構築していました。しかし、Taobaoのユーザー数と商品情報が増えるにつれて、分散データベースルートを採用する必要が生じました。分散データベースは柔軟なアーキテクチャを備えており、分散管理と制御に適しており、スケーラビリティに優れ、拡張が容易です。もちろん、分散データベースにも、データの一貫性が低い、ネットワーク通信のオーバーヘッドが高い、データ アクセス構造が複雑であるなど、独自の欠点がいくつかあります。ただし、一部のアプリケーション シナリオでは、分散データベース アーキテクチャなしではデータの管理と構築が困難であることは否定できません。

3.2 分散ストレージアーキテクチャ

データセンター内のビジネスデータが継続的に増加するにつれて、大規模なデータマイニングとビッグデータのログ分析が徐々に主要なアプリケーションシナリオになりつつあります。極めて柔軟なストレージ ニーズとパフォーマンス要件に直面して、従来のデータ センターの単一マシンまたは独立した SAN ストレージ デバイスでは、基本的にビッグ データ処理のニーズを満たすことができません。データベース システムと同様に、独立したストレージ デバイスは、パフォーマンスとデータ ストレージ容量の点で特定のボトルネックに直面します。

従来のデータ センターでは、通常、集中型のストレージ アーキテクチャが採用されています。単一の SAN または IPSAN ストレージ デバイスは通常、2 ～ 8 個のコントローラで構成され、容量はストレージ拡張キャビネットによって拡張されます。パフォーマンスを向上させるには、コントローラーとキャッシュを追加するか、ストレージ デバイス モデルをハイエンド ストレージに置き換える必要があります。集中型ストレージ アーキテクチャでは、単一のストレージのパフォーマンスと拡張機能は制限されており、通常は線形拡張を実現できません。ストレージ容量が増加すると、ストレージ パフォーマンスは最初は向上しますが、一定のボトルネックに達すると徐々に低下します。なぜなら、最初はディスクを大量に追加することでストレージ全体の読み取りおよび書き込みパフォーマンスが向上しますが、ディスクのパフォーマンスがコントローラーのパフォーマンスに達すると、コントローラーのデータの処理と操作に重大な影響を及ぼし、パフォーマンスが徐々に低下するからです。

膨大な PB レベルのデータに直面した場合、従来の独立した SAN ストレージ デバイスを使用すると、拡張機能が実現できないか、拡張機能は膨大な PB レベルに達しても容量とパフォーマンスが直線的に増加せず、将来のストレージ拡張と運用および保守コストも非常に高くなります。

データセンターにおけるビッグデータ サービスの需要が高まる中、まず必要なのは大量のデータを保存できることです。従来のストレージ システムは容量が限られており、複数のストレージ デバイスにまたがることはできません。仮想化技術を使用してストレージ リソースを統合した場合でも、ストレージ単位のコストは非常に高くなり、データ処理パフォーマンスは制限されます。

Hadoop を例に挙げてみましょう。これは、ビッグデータ処理用の比較的成熟しており、広く使用されている分散オープンソースソフトウェアです。その基盤となるのは HDFS 分散ストレージです。 HDFS 設計の本質は、大量のデータの分散ストレージを可能にすることです。 HDFS はさまざまなマシンにデータを保存できます。ユーザーは特定のデータがどこにあるかを心配する必要はなく、HDFS がデータを管理します。 HDFS は、耐障害性が非常に高い分散ストレージ システムです。分散方式で展開し、ストリーミング アクセス モードでアプリケーション データにアクセスできるため、システム全体のデータ スループットが大幅に向上します。非常に大きなデータセットを扱うアプリケーションに非常に適しています。さらに、分散ストレージ システム全体が拡張するにつれて、容量とパフォーマンスが正比例して直線的に増加するため、ビッグ データのビジネス処理やアプリケーションに非常に適しています。

分散アーキテクチャに基づくデータベースとストレージは、将来のデータセンターの重要な開発方向の 1 つです。分散アーキテクチャがなければ、データセンターはビッグデータを管理できません。

3.3 分散セキュリティネットワーク

クラウド コンピューティング テクノロジーをベースとしたデータ センターは、アプリケーションの展開に柔軟性と弾力性のあるリソース構成をもたらし、ハードウェア リソースの使用率を向上させ、展開時間を短縮しましたが、同時に新たなセキュリティ問題も生じています。

従来のデータセンター ネットワーク セキュリティは、セキュリティ ドメインとセキュリティ境界に基づく保護メカニズムです。これは、ビジネス トラフィックのアクセス制御のみに焦点を当て、トラフィック セキュリティ制御を唯一の計画上の考慮事項とする一連の垂直セキュリティ戦略です。

仮想化テクノロジーの広範な使用により、ネットワーク境界が曖昧になり、セキュリティ トラフィックを他の物理サーバーに動的に移行できるようにするために、主に水平セキュリティ戦略に依存するようになりました。仮想化環境に基づく従来のアプリケーション モデルでは、仮想化環境のニーズを満たすことができなくなりました。仮想化されたサービス提供モデルでは、ユーザーの ID、権限、動作を識別、制御、監査することがより困難になります。これにより、従来のデータセンターに基づく多くのセキュリティ対策が無効になります。

クラウド コンピューティング データ センターでは、サーバー デバイス上で複数の仮想マシンが実行されます。仮想マシンは仮想化スイッチを介して接続され、通信トラフィックは外部のスイッチング デバイスを通過しないため、従来のセキュリティ デバイスではこの部分のトラフィックを監視できなくなります。現在、ほとんどの仮想化ソフトウェア ベンダーは、仮想マシン通信における東西トラフィックの効率的な検出および分離方法を提供していません。仮想マシンにセキュリティ上の問題がある場合、関連するリソース プールに重大なセキュリティ上の脅威が生じる可能性があります。さらに、仮想マシンはいつでも他のサーバーデバイスに移行できるため、セキュリティドメインの境界が動的になり、従来のデータセンターの固定境界の保護対策は無効になります。仮想マシンを新しいサーバー デバイスに移行した場合、新しいサーバー デバイスに対応するセキュリティ保護ポリシーがないと、移行された仮想マシンにセキュリティ上の脅威が生じる可能性があります。

クラウド コンピューティング データ センターに存在するセキュリティ問題を解決するには、セキュリティ管理ソフトウェアまたはシステムを分散形式で展開する必要があります。通常、分散ネットワーク セキュリティ製品は、集中管理プラットフォーム + 分散セキュリティ管理ソフトウェアで構成されます。集中管理プラットフォームは、セキュリティ ポリシーの集中管理を担当し、セキュリティ ポリシーの移行をサポートします。同時に、仮想化されたセキュリティデバイスからログや統計情報を受信し、データセンター全体のセキュリティ状況を分析します。

セキュリティ ソフトウェアは、仮想マシンおよび仮想化プラットフォーム上に分散して展開されます。従来の物理セキュリティ デバイスの制限を克服し、仮想マシンの場所に近づき、転送またはリダイレクト メカニズムを使用してすべての仮想マシンのトラフィックを取得し、分散セキュリティ保護を実現します。

3.4 分散クラウドデータセンター

高いビジネス可用性を実現し、ビジネスの継続性を確保し、データ損失を防ぐために、従来のデータ センターでは、「同一都市のプライマリおよびバックアップ/アクティブ/アクティブ データ センター」または「2 つの場所、3 つのセンター」アーキテクチャを採用しています。ただし、どのアーキテクチャ ソリューションを採用したとしても、IT リソースの無駄は必ず発生します。 「プライマリおよびスタンバイ データ センター」はビジネス継続性の問題を解決しますが、通常は 1 つのデータ センター リソースのみが有効になり、もう 1 つはバックアップとして使用されます。 「アクティブ-アクティブ データ センター」は、高いビジネス可用性の問題を解決しますが、2 つのデータ センターで同じビジネスを展開して実行する必要があり、1 つのデータ センターのリソースも無駄になります。 「2 つの拠点と 3 つのセンター」は、ビジネスとデータのセキュリティをかなり考慮していますが、IT リソースの最も深刻な浪費も引き起こします。

分散型クラウド データ センターの概念では、複数のデータ センターはマスター/スレーブまたはアクティブ/アクティブの関係ではなくなります。代わりに、クラウド コンピューティング テクノロジー、WAN レイヤー 2 ネットワーク相互接続 (ビッグ レイヤー 2) テクノロジー、およびデータ複製テクノロジーを通じて、複数のデータ センターがセンターと地域にまたがる分散型の「仮想リソース プール」に編成されます。すべてのサービスとデータは必要に応じて異なるデータ センターに割り当てることができるため、「アクティブ/アクティブ」や「2 つの場所、3 つのセンター」よりも優れたビジネス展開ソリューションを実現できます。

これまで、分散アーキテクチャに基づくクラウド データ センターは、技術的な制限により実装が困難だった可能性があります。しかし、さまざまな技術の継続的な発展により、難易度は大幅に低下し、実現可能になりました。考慮する必要がある問題は、ビジネス アクセス ネットワーク、大規模なレイヤー 2 ネットワーク、データの同期とレプリケーションの 3 つです。ビジネス アクセス ネットワークは、グローバル ロード バランシング GLSB とインテリジェント DNS を通じてさまざまなエリアでのローカル アクセスを実現でき、大規模なレイヤー 2 インターネット テクノロジの使用により仮想マシンの移行問題を解決できます。データの同期とレプリケーションは、マイクロサービス + コンテナ + 分散ストレージ レプリケーション テクノロジーを使用して解決できます。ビジネスはマイクロサービスを通じて分離されます。ステートレス アプリケーションは、大規模なレイヤー 2 ネットワークを介してコンテナーを使用して移行されます。ステートフル アプリケーションは仮想マシンとともに移行できます。コールド データは可能な限り集中的に保存され、アクセスは共有されるため、過度なデータ移行を回避できます。

企業が分散アーキテクチャを備えたクラウド データ センターを実現するのに役立つ実現可能なソリューションはすでに存在します。同時に、データセンターのリソースの利用率を最大化し、運用・保守・管理コストを削減し、ビジネスの継続性をより確実にすることもできます。

3.5 2つのアーキテクチャの主な違い

リソース処理機能、ビジネス サポート機能、セキュリティ管理機能、可用性と一貫性、運用と保守、管理の観点から見た集中型アーキテクチャと分散型アーキテクチャの上記の分析から、次のことがわかります。

集中型アーキテクチャには、システムの複雑さ、データの一貫性、セキュリティ対策の実装の容易さ、運用および保守管理の複雑さの点で一定の利点があります。分散アーキテクチャには、リソース利用コストとスケーラビリティ、柔軟なビジネス展開、システムの可用性の点で明らかな利点があります。さらに、集中型アーキテクチャの複雑さは管理と設計の強化によって軽減され、セキュリティシステムと手段を追加することでセキュリティ対策が強化され、データの一貫性は高度な分散システムと大規模な運用保守プラットフォームによってサポートされる必要があります。もちろん、ある程度の可用性を犠牲にする必要があることが前提となります。これは分散アーキテクチャが直面する課題でもあり、これについては以下で詳しく説明します。

4. 分散アーキテクチャ構築の課題

データセンター内の情報システムの数が増え、処理されるデータの量が増加するにつれて、分散アーキテクチャの利点はますます明らかになります。しかし、アーキテクチャが高度になるほど、直面する課題も大きくなります。分散アーキテクチャはマルチノード設計を採用しているため、このアーキテクチャの最大の難しさは、データの一貫性と可用性に課題が生じることです。すべての分散アーキテクチャ設計では、これら 2 つの課題を回避することはできません。

分散アーキテクチャには、次のように定義される非常に有名な CAP 理論 (ブリューワーの定理とも呼ばれます) があります。

どのような分散コンピューティング システムでも、一貫性、可用性、ネットワーク パーティションに対する耐性という 3 つのポイントを同時に満たすことは不可能です。

一貫性は通常、データの一貫性を指し、すべてのノードのデータが一貫している必要があることを意味します。可用性を実現するには、障害が発生した場合でも各ノードがサービスを提供できる必要があります。ネットワーク パーティションを許容するということは、通常、ノード間のネットワーク通信パフォーマンスを指します。

CAP 理論によれば、分散システムは 3 つの要件のうち 2 つしか満たすことはできず、3 つすべてを満たすことはできません。

CP モデル: A (可用性) は考慮されず、複数のノード間のデータは強い一貫性を持ちます。ノードに障害が発生した場合、障害が発生したノードは破棄されます (A は無視されます)。それ以外の場合は、ノード間のデータ同期が無期限に延長されます。データの一貫性を確保するために、金融業界のほとんどの分散リレーショナル データベースはこのモデルを採用しています。

AP モデル: C (一貫性) は考慮されておらず、複数のノード間で高可用性が求められます。ノードに障害が発生し、他のノードとの接続が失われた場合、ノードの可用性を確保するために、グローバル データの一貫性は (C を考慮せずに) 放棄されます。ノードはローカル ノード データにアクセスして使用するため、ノード データ間に不整合が生じる可能性があります。ほとんどの非リレーショナル データベースでは、高度なデータ一貫性は必要ないため、このモデルが使用されます。

CA モデル: P (ネットワーク パーティションの許容度) は考慮されません。 2 つ以上のノードに可用性とデータの一貫性が必要です。ノードに障害が発生した場合、可用性とデータの一貫性の両方を確保するために、分散ネットワークを強制的に複数の異なるパーティションに分割して C と A を確保することしかできず、これによりパーティションが分割されます。

上記のモデルから、分散コンピューティング環境では P が現実的である必要があることがわかります。そうでないと、分散ネットワーク ノード間の通信に問題が発生するため、唯一の選択肢は C と A、つまり CP モデルまたは AP モデルのいずれかを選択することです。実際の選択は、それぞれのビジネスシナリオに基づいて、各モデルの特性に応じて行う必要があります。

高可用性を必要としない一部のオフライン アプリケーションまたはサービスでは、CP モデルを使用できます。このタイプのモデルは比較的単純ですが、その適用シナリオも限られています。たとえば、ログ データ分析システムでは、ほとんどのデータがローカルに保存されるため、分散アーキテクチャで特定の冗長ノードと回復メカニズムを構成するだけで済みます。ノードに障害が発生した場合、分析システムは他のバックアップ ノードが回復するまで自動的に待機してから実行を続行します。これは、短期間の停止はシステムに大きな影響を与えませんが、各ノードによって分析されるデータは一貫している必要があるためです。

データセンターでは、基幹システムや重要な業務システムが大きな割合を占めています。分散アーキテクチャを採用する場合、高可用性とデータの一貫性の両方が必要になる可能性があり、これは分散アーキテクチャの設計における大きな課題です。

金融業界を例にとると、ビジネスの継続性と高可用性を確保することは非常に重要な要件であり、これは AP モデルを使用して設計できます。ただし、金融システム内のデータに一貫性がない場合、深刻なデータの問題が発生するため、データの一貫性は可能な限り確保する必要があります。データの一貫性に関しては、分散アーキテクチャでは、強い一貫性、弱い一貫性、結果的な一貫性に分けられます。金融システムの高可用性とビジネス継続性を確保するには、強いデータ一貫性を実現することは難しく、弱い一貫性では要件を満たすことができません。トレードオフとして、最終的なデータの一貫性を実現できます。分散システムでは、データは複数のノードに保存されます。各ノードのデータがアプリケーションによって変更された後、結果整合性により、各ノードが同時にデータを更新する必要はありません。各ノードの更新されたデータをできるだけ早くシステム全体に配布することだけが必要です。これにより、システムの可用性を確保しながらデータの最終的な一貫性が実現され、金融業界のデータ要件を満たすことができます。もちろん、すべての金融サービスが最終的な一貫性ソリューションを採用できるわけではありません。たとえば、コアとなるリアルタイム取引システムは、データをリアルタイムで処理し、強力な一貫性を維持する必要があります。このため、ほとんどの金融機関のコア取引システムは依然として集中型アーキテクチャを使用しています。

分散型クラウド データ センターも、構築中に、主にネットワーク、ストレージ、コンピューティングの 3 つの側面でいくつかの課題に直面します。

ネットワーク面では、複数の分散クラウド データ センター間の通信が問題となります。複数の異なる領域でネットワーク アクセスと負荷分散の問題を考慮する必要があります。また、複数のクラウド データ センター間でのビジネス コミュニケーションと切り替えのニーズも満たす必要があります。現在主流の技術ソリューションは、複数のデータ ネットワークを接続して統合された論理ネットワークを形成する大規模なレイヤー 2 ネットワーク テクノロジに基づいています。しかし、各ネットワーク機器メーカー間ではレイヤー2ネットワークやプロトコルが統一されておらず、機器の互換性にも一定の問題があり、これも分散型クラウドデータセンターの変革において解決すべき問題です。

ストレージに関しては、リアルタイムのデータ同期、統合ストレージリソース共有の実現、信頼性の高いデータ保護メカニズムの確立が比較的厳しい課題です。複数のデータセンターが異なる地域に分散している場合があります。データセンター間のネットワーク帯域幅は限られており、リアルタイムのデータ同期が不可能な場合があるため、非同期伝送が唯一の選択肢となります。その場合、データの一貫性と整合性が保証されない可能性があります。前述のアプリケーション分離 + マイクロサービス アーキテクチャにより、いくつかの問題を解決できます。ただし、マイクロサービスに変換できない従来のアプリケーションでは、依然として問題が残ります。データの一貫性と可用性の間にはトレードオフが存在する場合があります。

コンピューティングの面では、テクノロジーは比較的成熟しています。リソースがクラウド化された後は、クラウド コンピューティング テクノロジを使用して、複数のクラウド データ センター内のコンピューティング リソースの統一されたスケジュール設定と管理を実現できます。きめ細かな管理のために権限を設定することもできます。コンピューティングにおけるいくつかの課題は、通常、コンピューティング リソースの管理に関係します。たとえば、アプリケーションに障害が発生した場合、リソースをローカルで再構築するか、他のクラウド データ センターに移行して再起動するかは、各ノードへの他の業務アクセスに影響を与えるため、事前に統一された計画と準備が必要です。

V. 結論

従来のデータセンターと比較して、分散アーキテクチャを備えたクラウド データセンターを構築することが非常に重要であり、これはデータセンター構築のあらゆる側面に影響します。将来、分散アーキテクチャを持たないデータセンターは、決して優れたデータセンターとは言えないでしょう。クラウドコンピューティング技術の継続的な開発と実践を通じて、分散アーキテクチャがデータセンターの将来の開発方向になると信じています。将来のデータ センターのアーキテクチャが完全に分散化されない場合でも、分散アーキテクチャがなくなることはなく、必ずその場所が確保されるでしょう。