クラウド向け分散ファイルシステム

クラウド用の分散ファイル システムは、多くのクライアントがデータにアクセスできるようにし、そのデータに対する操作 (作成、削除、変更、読み取り、書き込み) をサポートするファイル システムです。各データ ファイルは、チャンクと呼ばれる複数の部分に分割できます。各チャンクは異なるリモート マシンに保存できるため、アプリケーションの並列実行が容易になります。通常、データは階層ツリー内のファイルに保存され、ノードはディレクトリを表します。分散アーキテクチャでファイルを共有する方法はいくつかあります。各ソリューションは、アプリケーションの複雑さに応じて、特定の種類のアプリケーションに適している必要があります。同時に、システムのセキュリティを確保する必要があります。機密性、可用性、整合性は、安全なシステムの主な鍵です。

クラウド コンピューティングにより、ユーザーはインターネット経由でコンピューティング リソースを共有できます。クラウド コンピューティングは、通常、物理サーバー、アプリケーション、仮想化され動的に割り当てられるサービスなど、スケーラブルで柔軟なリソースを特徴としています。すべてのデバイスを最新の状態に保つには、 同期が必要です。

分散ファイル システムにより、多くの大規模、中規模、小規模の企業は、ローカル データと同様にリモート データを保存およびアクセスできるようになり、さまざまなリソースの使用が容易になります。

今日、分散ファイルシステムの実装は数多く存在します。最初のファイルサーバーは 1970 年代に研究者によって開発されました。Sun Microsystem のネットワークファイルシステムは1980 年代に利用可能になりました。それ以前は、ファイルを共有したい人はスニーカーネット方式を使用していました。これは、ファイルをストレージメディア上で物理的に場所から場所へと運ぶものでした。コンピュータネットワークが普及し始めると、既存のファイルシステムには多くの制限があり、マルチユーザー環境には適していないことが明らかになりました。ユーザーは最初、ファイル共有にFTP を使用していました。 ^[1] FTP は1973 年末にPDP-10で初めて実行されました。FTP を使用した場合でも、ファイルをソースコンピューターからサーバーにコピーし、次にサーバーから宛先コンピューターにコピーする必要がありました。ユーザーは、ファイル共有に関係するすべてのコンピューターの物理アドレスを知っている必要がありました。^[2]

現代のデータ センターは、さまざまな容量の多数のコンピューターで構成される大規模で異機種環境をサポートする必要があります。クラウド コンピューティングは、データ センター ネットワーキング(DCN)、並列および分散システムでデータ集約型コンピューティングアプリケーションをサポートするMapReduceフレームワーク、動的なリソース割り当てを提供し、複数のオペレーティング システムを同じ物理サーバー上で共存できるようにする仮想化技術などの技術を使用して、このようなすべてのシステムの操作を調整します。

クラウドコンピューティングは、必要なCPUとストレージリソースを完全な透明性を持ってユーザーに提供できるため、大規模なコンピューティングを実現します。このため、クラウドコンピューティングは、大規模な分散処理を必要とするさまざまな種類のアプリケーションをサポートするのに特に適しています。このデータ集約型コンピューティングには、仮想マシン（VM）間でデータを共有できる高性能なファイルシステムが必要です。 ^[3]

クラウドコンピューティングは必要なリソースを動的に割り当て、タスクが完了するとそれらを解放します。ユーザーは、多くの場合、サービスレベル契約を通じて、必要なサービスに対してのみ料金を支払う必要があります。クラウドコンピューティングとクラスターコンピューティングのパラダイムは、実験を実行するために大量のコンピューターが必要になることが多い天文学や物理学などの産業データ処理や科学アプリケーションにとってますます重要になっています。 ^[4]

ほとんどの分散ファイル システムはクライアント サーバー アーキテクチャに基づいて構築されていますが、他の分散型ソリューションも存在します。

ネットワーク ファイル システム(NFS)は、クライアント サーバー アーキテクチャを使用しており、ネットワーク上の複数のマシン間で、ファイルがローカルにあるかのようにファイルを共有できるため、標準化されたビューが提供されます。NFS プロトコルを使用すると、異なるマシンや異なるオペレーティング システムで実行されている可能性のある異機種クライアントのプロセスが、ファイルの実際の場所を無視して、遠く離れたサーバー上のファイルにアクセスできます。単一のサーバーに依存すると、NFS プロトコルの可用性とスケーラビリティが低下する可能性があります。複数のサーバーを使用しても、各サーバーが独立して動作しているため、可用性の問題は解決されません。^[5] NFS のモデルはリモート ファイル サービスです。このモデルは、アップロード/ダウンロード モデルとは対照的に、リモート アクセス モデルとも呼ばれます。

• リモートアクセスモデル: 透過性を提供し、クライアントはファイルにアクセスできます。クライアントはリモートファイルにリクエストを送信します（ファイルはサーバー上に残ります）。^[6]
• アップロード/ダウンロード モデル: クライアントはローカルでのみファイルにアクセスできます。つまり、他のクライアントが使用するには、クライアントがファイルをダウンロードし、変更を加えて再度アップロードする必要があります。

NFS で使用されるファイル システムは、 Unixシステムで使用されるファイル システムとほぼ同じです。ファイルは、ディレクトリとファイルがノードで表された命名グラフに階層的に編成されます。

クラスターベースのアーキテクチャは、クライアント サーバー アーキテクチャの問題の一部を改善し、アプリケーションの並列実行を改善します。ここで使用される手法はファイル ストライピングです。つまり、ファイルは複数のチャンクに分割され、複数のストレージ サーバーに「ストライピング」されます。目的は、ファイルのさまざまな部分に並列でアクセスできるようにすることです。アプリケーションがこの手法のメリットを享受できない場合は、さまざまなファイルをさまざまなサーバーに保存する方が便利です。ただし、Amazon や Google などの大規模なデータ センターの分散ファイル システムを編成する場合、Web クライアントに多数のコンピューターに分散された多数のファイルに対する複数の操作 (読み取り、更新、削除など) を許可するサービスを提供する場合は、クラスターベースのソリューションの方が有利になります。コンピューターの数が多いと、ハードウェア障害が増える可能性があることに注意してください。^{[7]このタイプの最も広く使用されている分散ファイル システム (DFS) の 2 つは、} Google ファイル システム(GFS) とHadoop 分散ファイル システム(HDFS)です。両方のファイルシステムは、標準オペレーティングシステム（ GFSの場合はLinux ）上で実行されるユーザーレベルのプロセスによって実装されています。 ^[8]

Google File System (GFS) とHadoop Distributed File System (HDFS) は、非常に大規模なデータセットのバッチ処理を処理できるように特別に構築されています。そのためには、次の仮説を考慮する必要があります。^[9]

• 高可用性:クラスターには数千のファイルサーバーを含めることができ、そのうちのいくつかはいつでもダウンする可能性があります。
• サーバーは、ラック、部屋、データセンター、国、大陸に属しており、地理的な位置を正確に特定できます。
• ファイルのサイズは数ギガバイトから数テラバイトまでさまざまです。ファイルシステムは膨大な数のファイルをサポートできる必要があります。
• 追加操作をサポートし、ファイルの書き込み中でもファイルの内容を表示できるようにする必要性
• 動作中のマシン間の通信は信頼性があります。TCP /IPはリモートプロシージャコールRPC通信の抽象化で使用されます。TCPを使用すると、クライアントは問題が発生して新しい接続を確立する必要がある場合に、ほぼ即座にそれを知ることができます。^[10]

負荷分散は、分散環境での効率的な運用に不可欠です。これは、同じ時間でより多くの作業を完了し、クライアントに迅速にサービスを提供するために、作業を異なるサーバー間で公平に分散^することを意味します。クラウド内に N 個のチャンクサーバー (N は 1000、10000、またはそれ以上) を含むシステムでは、一定数のファイルが格納され、各ファイルは固定サイズ (たとえば 64 メガバイト) のいくつかの部分またはチャンクに分割され、各チャンクサーバーの負荷はサーバーによってホストされるチャンクの数に比例します。^[12]負荷分散されたクラウドでは、リソースを効率的に使用しながら、MapReduce ベースのアプリケーションのパフォーマンスを最大化できます。

クラウドコンピューティング環境では、障害は当たり前のことであり、^{[13] [14]}チャンクサーバーはアップグレード、交換、システムへの追加が行われる可能性があります。また、ファイルは動的に作成、削除、追加される可能性があります。これにより、分散ファイルシステムの負荷の不均衡が生じ、ファイルチャンクがサーバー間で公平に分散されなくなります。

GFSやHDFSなどのクラウドの分散ファイルシステムは、メタデータと負荷分散を管理するために、中央またはマスターサーバーまたはノード（GFSの場合はマスター、HDFSの場合はネームノード）に依存しています。マスターは定期的にレプリカのバランスを取り直します。最初のサーバーの空き容量が特定のしきい値を下回った場合、データを1つのデータノード/チャンクサーバーから別のデータノード/チャンクサーバーに移動する必要があります。^[15 ]ただし、この集中型のアプローチは、マスターサーバーが大量のファイルアクセスを管理できなくなった場合、すでに重い負荷をさらに増加させるため、ボトルネックになる可能性があります。負荷の再バランスの問題はNP困難です。^[16]

多数のチャンクサーバーを連携させ、分散ファイルシステムにおける負荷分散の問題を解決するために、移動コストを可能な限り削減しながらチャンクを可能な限り均一に分散できるようにファイルチャンクを再割り当てするなどのいくつかのアプローチが提案されている。^[12]

最大のインターネット企業の 1 つである Google は、Google のデータ処理ニーズの急速な増加に対応するために、Google File System (GFS) という独自の分散ファイル システムを作成し、すべてのクラウド サービスで使用しています。GFS は、データ集約型アプリケーション向けのスケーラブルな分散ファイル システムです。多数のクライアントが同時にアクセスする場合でも、フォールト トレラントで高性能なデータ ストレージを提供します。

GFSはMapReduceを使用しており、並列化や負荷分散の問題を気にすることなく、プログラムを作成して複数のマシンで実行することができます。GFSのアーキテクチャは、複数のチャンクサーバーと複数のクライアントに対して単一のマスターサーバーを持つことを基本としています。^[17]

専用ノードで実行されるマスターサーバーは、ストレージリソースの調整とファイルのメタデータ（たとえば、従来のファイルシステムのinodeに相当）の管理を担当します。^[9] 各ファイルは64メガバイトの複数のチャンクに分割されます。各チャンクはチャンクサーバーに保存されます。チャンクはチャンクハンドルによって識別されます。チャンクハンドルは、チャンクが最初に作成されたときにマスターによって割り当てられる、グローバルに一意の64ビット番号です。

マスターは、ファイル名、ディレクトリ、各ファイルのデータを含むチャンクのリストへのファイルのマッピングなど、ファイルのメタデータをすべて管理します。メタデータは、チャンクへのファイルのマッピングとともに、マスターサーバーのメインメモリに保存されます。このデータの更新は、ディスク上の操作ログに記録されます。この操作ログは、リモートマシンに複製されます。ログが大きくなりすぎると、チェックポイントが作成され、メインメモリのデータがBツリー構造に保存され、メインメモリへのマッピングが容易になります。^[18]

フォールトトレランスを容易にするために、各チャンクは複数の（デフォルトでは3つの）チャンクサーバーに複製されます。^[19]チャンクは少なくとも1つのチャンクサーバーで利用できます。この方式の利点はシンプルさです。マスターは各チャンクのチャンクサーバーを割り当てる責任があり、メタデータ情報に関してのみ接続されます。他のすべてのデータについては、クライアントがチャンクサーバーと対話する必要があります。

マスターはチャンクがどこにあるかを追跡します。しかし、チャンクの位置を正確に維持しようとはせず、チャンクサーバーにどのチャンクが保存されているかを確認するために時々接続するだけです。^[20]これによりスケーラビリティが確保され、作業負荷の増加によるボトルネックを防ぐことができます。^[21]

GFSでは、ほとんどのファイルは新しいデータを追加することで変更され、既存のデータは上書きされません。一度書き込まれると、ファイルは通常ランダムではなく順番に読み取られるため、このDFSは、多くの大きなファイルが一度作成され、何度も読み取られるシナリオに最適です。^{[22] [23]}

クライアントがファイルに書き込み/更新をしたい場合、マスターはレプリカを割り当てます。これが最初の変更であればプライマリレプリカになります。書き込みのプロセスは2つのステップで構成されます。^[9]

• 送信: まず、最も重要なことですが、クライアントはマスターに連絡して、どのチャンク サーバーがデータを保持しているかを調べます。クライアントには、プライマリ チャンク サーバーとセカンダリ チャンク サーバーを識別するレプリカのリストが提供されます。次に、クライアントは最も近いレプリカ チャンク サーバーに連絡して、データを送信します。このサーバーは、データを次に近いサーバーに送信し、そのサーバーはさらに別のレプリカにデータを転送します。この処理が繰り返されます。その後、データは伝播されてメモリにキャッシュされますが、ファイルにはまだ書き込まれません。
• 書き込み: すべてのレプリカがデータを受信すると、クライアントはプライマリ チャンク サーバーに書き込み要求を送信し、送信フェーズで送信されたデータを識別します。プライマリ サーバーは、受信した書き込み操作にシーケンス番号を割り当て、シリアル番号順にファイルに書き込みを適用し、その順序で書き込み要求をセカンダリに転送します。その間、マスターはループから外れます。

その結果、データフローと制御フローの2種類のフローを区別することができます。データフローは送信フェーズに関連付けられ、制御フローは書き込みフェーズに関連付けられます。これにより、プライマリチャンクサーバーが書き込み順序を制御することが保証されます。マスターが書き込み操作をレプリカに割り当てると、チャンクバージョン番号が増加し、そのチャンクを含むすべてのレプリカに新しいバージョン番号が通知されることに注意してください。チャンクバージョン番号により、チャンクサーバーがダウンしたためにレプリカが更新されなかった場合に、更新エラーを検出できます。^[24]

いくつかの新しいGoogleアプリケーションは64メガバイトのチャンクサイズではうまく動作しませんでした。この問題を解決するために、GFSは2004年にBigtableアプローチの実装を開始しました。^[25]

Apache Software Foundationによって開発されたHDFSは、非常に大量のデータ (テラバイトまたはペタバイト) を保持するために設計された分散ファイルシステムです。そのアーキテクチャは GFS に似ており、サーバー/クライアント アーキテクチャです。HDFS は通常、コンピューターのクラスターにインストールされます。Hadoop の設計コンセプトは Google のコンセプトに影響を受けており、Google File System、Google MapReduce、Bigtable は、それぞれ Hadoop Distributed File System (HDFS)、Hadoop MapReduce、Hadoop Base (HBase) によって実装されています。^[26] GFS と同様に、HDFS は write-once-read-many ファイル アクセスのシナリオに適しており、ランダムな読み取りと書き込みの代わりにファイルの追加と切り捨てをサポートして、データの一貫性の問題を簡素化します。^[27]

HDFS クラスターは、単一の NameNode と複数の DataNode マシンで構成されています。マスター サーバーである NameNode は、RAM 内のストレージ DataNode のメタデータを管理および維持します。DataNode は、実行されているノードに接続されたストレージを管理します。NameNode と DataNode は、日常的に使用するマシンで実行するように設計されたソフトウェアで、通常は Linux OS で実行されます。HDFS は、Java をサポートする任意のマシンで実行できるため、NameNode または Datanode ソフトウェアのいずれかを実行できます。^[28]

HDFS クラスターでは、ファイルは 1 つ以上の同じサイズのブロックに分割されますが、最後のブロックが小さくなる可能性はあります。各ブロックは複数のデータノードに保存され、可用性を保証するために複数のデータノードに複製されることがあります。デフォルトでは、各ブロックは 3 回複製され、このプロセスは「ブロック レベル レプリケーション」と呼ばれます。^[29]

NameNodeは、ファイルやディレクトリのオープン、クローズ、名前変更などのファイルシステムの名前空間操作を管理し、ファイルアクセスを規制します。また、ブロックとDataNodeのマッピングも決定します。DataNodeは、ファイルシステムのクライアントからの読み取りおよび書き込み要求の処理、ブロックの割り当てまたは削除の管理、ブロックの複製を担当します。^[30]

クライアントがデータを読み書きする場合、NameNode に接続し、NameNode はデータの読み取り元または書き込み先を確認します。その後、クライアントは DataNode の場所を把握し、読み取りまたは書き込み要求を DataNode に送信できます。

HDFSは、データ再バランス方式との互換性が特徴である。一般的に、データノード上の空き領域の管理は非常に重要です。空き領域が十分でない場合は、データをあるデータノードから別のデータノードに移動する必要があります。また、追加のレプリカを作成する場合は、システムのバランスを確保するためにデータを移動する必要があります。^[29]

分散ファイルシステムは、さまざまな目的に合わせて最適化できます。GFSなどのインターネットサービス用に設計されたものなど、スケーラビリティに最適化されているものもあります。分散ファイルシステムの他の設計は、通常並列で実行されるパフォーマンス重視のアプリケーションをサポートします。^[31]例としては、MapRファイルシステム（MapR-FS）、Ceph-FS、Fraunhoferファイルシステム（BeeGFS）、Lustreファイルシステム、IBM General Parallel File System（GPFS）、Parallel Virtual File Systemなどがあります。

MapR-FS は、MapR Converged Platform の基盤となる分散ファイルシステムで、分散ファイルストレージ、複数の API を備えた NoSQL データベース、統合メッセージストリーミングシステムなどの機能を備えています。MapR-FS は、スケーラビリティ、パフォーマンス、信頼性、可用性に最適化されています。ファイルストレージ機能は Apache Hadoop Distributed File System (HDFS) API と互換性がありますが、HDFS とは異なる設計上の特徴がいくつかあります。最も顕著な違いは、MapR-FS が完全な読み取り/書き込みファイルシステムであり、ファイルとディレクトリのメタデータが名前空間全体に分散されているため、NameNode が存在しないことです。^{[32] [33] [34] [35] [36]}

Ceph-FSは、優れたパフォーマンスと信頼性を提供する分散ファイルシステムです。^[37]巨大なファイルやディレクトリの処理、数千のディスクのアクティビティの調整、大規模なメタデータへの並列アクセスの提供、科学的および汎用的なワークロードの操作、大規模な認証と暗号化、頻繁なデバイスの廃止、デバイスの障害、クラスターの拡張による動的な増減などの課題に応えます。^[38]

BeeGFSは、フラウンホーファー高性能コンピューティングコンピテンスセンターの高性能並列ファイルシステムです。BeeGFSの分散メタデータアーキテクチャは、HPCや高I/O要求のアプリケーションを実行するために必要なスケーラビリティと柔軟性を提供するように設計されています。^[39]

Lustreファイルシステムは、分散システムに従来見られるボトルネックの問題に対処するために設計され、実装されました。Lustreは、効率性、スケーラビリティ、冗長性が特徴です。^[40] GPFSも、このようなボトルネックを解消することを目的として設計されました。^[41]

分散ファイルシステムの高性能化には、コンピューティングノード間の効率的な通信とストレージシステムへの高速アクセスが必要です。そのパフォーマンスを確保するには、開く、閉じる、読み取り、書き込み、送信、受信などの操作を高速に行う必要があります。たとえば、各読み取りまたは書き込み要求はディスクストレージにアクセスし、シーク、回転、ネットワークの遅延が発生します。^[42]

データ通信（送信/受信）操作は、アプリケーション バッファからマシン カーネルにデータを転送します。TCPは、このプロセスを制御してカーネルに実装します。ただし、ネットワークの輻輳やエラーが発生した場合、TCP はデータを直接送信しないことがあります。カーネル内のバッファからアプリケーションにデータを転送している間、マシンはリモート マシンからバイト ストリームを読み取りません。実際、TCP はアプリケーションのデータをバッファリングする役割を担っています。^[43]

ファイルの読み取りと書き込み、またはファイルの送受信のためのバッファサイズの選択は、アプリケーションレベルで行われます。バッファは、循環リンクリストを使用して管理されます。^[44]これは、一連の BufferNode で構成されます。各 BufferNode には DataField があります。DataField には、データと、次の BufferNode を指す NextBufferNode と呼ばれるポインタが含まれます。現在の位置を見つけるには、CurrentBufferNode と EndBufferNode という 2 つのポインタが使用されます。これらは、最後の書き込み位置と読み取り位置の BufferNode 内の位置を表します。BufferNode に空き領域がない場合、使用可能な領域ができるまで待機するようにクライアントに待機信号が送信されます。^[45]

アドホック接続を備えた複数のデバイスを持つユーザーが増えています。これらのデバイスに複製されたデータセットは、任意の数のサーバー間で同期する必要があります。これは、バックアップやオフライン操作にも役立ちます。実際、ユーザーのネットワーク状態が良くない場合、ユーザーデバイスは、後でオフラインで変更されるデータの一部を選択的に複製します。ネットワーク状態が良くなると、デバイスは同期されます。^[46]分散同期の問題に対処するには、ユーザー制御のピアツーピア同期とクラウドマスターレプリカ同期の2つのアプローチがあります。^[46]

• ユーザー制御のピアツーピア: rsyncなどのソフトウェアを、データを含むすべてのユーザーのコンピューターにインストールする必要があります。ファイルはピアツーピア同期によって同期されますが、ユーザーはネットワーク アドレスと同期パラメータを指定する必要があり、手動のプロセスになります。
• クラウド マスター レプリカ同期: クラウド サービスで広く使用されており、マスター レプリカがクラウド内に維持され、すべての更新と同期操作がこのマスター コピーに対して行われるため、障害発生時にも高いレベルの可用性と信頼性が実現します。

クラウドコンピューティングにおいて、最も重要なセキュリティ概念は、機密性、完全性、可用性（「CIA」）です。機密性は、個人データの漏洩を防ぐために不可欠です。完全性は、データが破損しないことを保証します。^[47]

機密性とは、データと計算タスクが機密であることを意味します。クラウドプロバイダーも他のクライアントもクライアントのデータにアクセスできません。機密性はクラウドコンピューティングにとって依然として課題となる重要なポイントの1つであるため、機密性については多くの研究が行われてきました。クラウドプロバイダーへの信頼の欠如も関連する問題です。^[48]クラウドのインフラストラクチャは、顧客のデータが権限のない第三者によってアクセスされないようにする必要があります。

サービスプロバイダーが以下の全てを実行できる場合、環境は安全ではなくなります。^[49]

• クラウド内の消費者データを見つける
• 消費者データにアクセスし取得する
• データの意味を理解する（データの種類、アプリケーションの機能とインターフェース、データの形式）。

データの地理的な場所は、プライバシーと機密性を決定するのに役立ちます。クライアントの場所を考慮する必要があります。たとえば、ヨーロッパのクライアントは、データの機密性の保証に影響を与えるため、米国にあるデータセンターを使用することに関心がありません。この問題に対処するために、一部のクラウドコンピューティングベンダーは、顧客とのサービスレベル契約のパラメーターとしてホストの地理的な場所を含め、^[50]ユーザーがデータをホストするサーバーの場所を自分で選択できるようにしています。

機密性を保つためのもう一つのアプローチは、データの暗号化です。^[51]そうしないと、不正使用の重大なリスクが生じます。機密データのみを暗号化する^[52]や、計算を簡素化するために一部の操作のみをサポートするなど、さまざまな解決策があります。^{[53]さらに、} FHEなどの暗号化技術やツールは、クラウドでのプライバシーを保護するために使用されます。^[47]

クラウド コンピューティングにおける整合性とは、データの整合性とコンピューティングの整合性を意味します。このような整合性とは、データがクラウド サーバーに正しく保存され、障害や誤ったコンピューティングが発生した場合に問題が検出される必要があることを意味します。

データの整合性は、悪意のあるイベントや管理エラー（バックアップと復元、データ移行、 P2Pシステムでのメンバーシップの変更など）によって影響を受ける可能性があります。^[54]

整合性は暗号化（通常はデータブロック上のメッセージ認証コード（MAC）を介して）を使用することで簡単に実現できます。 ^[55]

データの整合性に影響を与えるチェックメカニズムが存在します。例:

• HAIL（高可用性および整合性レイヤー）は、一連のサーバーがクライアントに対して保存されたファイルが無傷であり取得可能であることを証明できるようにする分散暗号化システムです。^[56]
• Hach POR（大規模ファイルの検索可能性の証明） ^[57]は対称暗号化システムに基づいており、ファイルの整合性を向上させるためにファイルに保存する必要がある検証キーは1つだけです。この方法は、ファイルFを暗号化し、暗号化されたファイルの末尾に追加する必要がある「sentinel」という名前のランダムな文字列を生成します。サーバーは他のブロックと区別できないsentinelを見つけることができないため、小さな変更でもファイルが変更されたかどうかがわかります。
• PDP (証明可能データ保有) チェックは、信頼できないサーバー上のデータの整合性を効率的にチェックする手段を提供する、効率的で実用的な方法のクラスです。
  • PDP: ^[58]データをサーバーに保存する前に、クライアントはメタデータをローカルに保存する必要があります。後で、データをダウンロードせずに、クライアントはサーバーにデータが改ざんされていないかどうかを確認するように要求できます。このアプローチは静的データに使用されます。
  • スケーラブルPDP: ^[59]このアプローチは対称鍵を前提としており、公開鍵暗号化よりも効率的です。いくつかの動的操作（変更、削除、追加）をサポートしていますが、公開検証には使用できません。
  • 動的PDP: ^[60]このアプローチはPDPモデルを拡張して、追加、挿入、変更、削除などのいくつかの更新操作をサポートし、集中的な計算に適しています。

可用性は一般にレプリケーションによって実現されます。^{[61] [62] [63] [64]}一方、一貫性は保証されなければなりません。しかし、一貫性と可用性は同時に達成することはできません。どちらか一方を犠牲にして優先されます。バランスを取る必要があります。^[65]

データにアクセスするには、ID が必要です。たとえば、Skute ^[61]は、キー/値ストレージに基づくメカニズムで、効率的な方法で動的なデータ割り当てを可能にします。各サーバーは、大陸-国-データセンター-部屋-ラック-サーバーの形式のラベルで識別される必要があります。サーバーは複数の仮想ノードを参照でき、各ノードには選択したデータ (または複数のデータの複数のパーティション) があります。各データは、一方向暗号化ハッシュ関数 ( MD5など) によって生成されるキー空間によって識別され、このキーのハッシュ関数値によってローカライズされます。キー空間は複数のパーティションに分割され、各パーティションがデータを参照します。レプリケーションを実行するには、仮想ノードを複製し、他のサーバーから参照する必要があります。データの耐久性とデータの可用性を最大化するには、レプリカを異なるサーバーに配置する必要があり、地理的な多様性に伴ってデータの可用性が向上するため、各サーバーは地理的に異なる場所に配置する必要があり、レプリケーションのプロセスには、各チャンク サーバーで特定の最小しきい値を超える必要があるスペースの可用性の評価が含まれます。それ以外の場合、データは別のチャンク サーバーに複製されます。各パーティション i には、次の式で表される可用性値があります。

${\displaystyle avail_{i}=\sum _{i=0}^{|s_{i}|}\sum _{j=i+1}^{|s_{i}|}conf_{i}.conf_{j}.diversity(s_{i},s_{j})}$

ここで、はレプリカをホストしているサーバーであり、はサーバーの信頼度であり（ハードウェアコンポーネントなどの技術的要因と国の経済状況や政治状況などの非技術的要因に依存）、多様性はと間の地理的距離です。^[66]${\displaystyle s_{i}}$${\displaystyle conf_{i}}$${\displaystyle conf_{j}}$${\displaystyle _{i}}$${\displaystyle _{j}}$${\displaystyle s_{i}}$${\displaystyle s_{j}}$

レプリケーションはデータの可用性を確保するための優れたソリューションですが、メモリスペースの面でコストがかかりすぎます。^[67] DiskReduce ^{[67] は、}RAIDテクノロジ (RAID-5 および RAID-6)に基づく HDFS の修正バージョンであり、複製されたデータの非同期エンコードを可能にします。実際、広く複製されたデータを検索し、エンコード後に余分なコピーを削除するバックグラウンド プロセスがあります。別のアプローチは、レプリケーションを消失訂正符号に置き換えることです。^[68]さらに、データの可用性を確保するために、データ回復を可能にする多くのアプローチがあります。実際には、データはコード化する必要があり、データが失われた場合は、コード化フェーズで構築されたフラグメントから回復できます。^[69]可用性を保証するために異なるメカニズムを適用する他のアプローチには、Microsoft Azure のリード ソロモン コードと HDFS の RaidNode があります。また、Google は消失訂正符号メカニズムに基づく新しいアプローチに取り組んでいます。^[70]

クラウドストレージにはRAID実装はありません。^[68]

クラウドコンピューティング経済は急速に成長しています。米国政府は、 2015年までに70億ドルに達すると予想される年間複合成長率（CAGR）の40％をクラウドコンピューティングに費やすことを決定しました。^[71]

膨大な量のデータを管理し、ストレージ容量の不足を克服するためにクラウドコンピューティングを活用する企業が増えています。クラウドコンピューティングでは、このようなリソースをサービスとして使用できるため、インフラストラクチャに投資することなくコンピューティングのニーズを満たすことができます（従量課金モデル）。^[72]

すべてのアプリケーションプロバイダーは、データのレプリカが保存されている各サーバーのコストを定期的に支払う必要があります。サーバーのコストは、ハードウェアの品質、ストレージ容量、クエリ処理と通信のオーバーヘッドによって決まります。^[73]クラウドコンピューティングにより、プロバイダーはクライアントの需要に応じてサービスを拡張できます。

従量課金モデルは、コンピューティング集約型ビジネスから利益を得たいと考えているスタートアップ企業の負担も軽減しました。クラウドコンピューティングは、そうでなければそのようなコンピューティングリソースを持たない多くの第三世界の国々にも機会を提供します。クラウドコンピューティングは、イノベーションに対するIT障壁を下げることができます。^[74]

クラウド コンピューティングは広く利用されていますが、信頼できないクラウドで大量のデータを効率的に共有することは依然として課題です。

• Andrew, S.Tanenbaum; Maarten, Van Steen (2006). 分散システムの原理とパラダイム(PDF)。2013-08-20 にオリジナル(PDF)からアーカイブ。2014-01-10に取得。
• Kon, Fabio (1996)。「分散ファイル システムの過去、現在、未来: 2006 年の分散ファイル システム」。ResearchGate。
• Pavel Bžoch. 「分散ファイル システムの過去、現在、未来 2006 年の分散ファイル システム (1996)」(PDF)。
• Sun Microsystem。「分散ファイルシステム - 概要」(PDF)。
• Jacobi, Tim-Daniel; Lingemann, Jan. 「分散ファイル システムの評価」(PDF)。2014 年 2 月 3 日にオリジナル(PDF)からアーカイブ。2014年 1 月 24 日に取得。

1. 建築、構造、デザイン:
   • Zhang, Qi-fei; Pan, Xue-zeng; Shen, Yan; Li, Wen-juan (2012)。「P2P に基づく小さなファイル用のクラウド ストレージ システムの新しいスケーラブル アーキテクチャ」。2012 IEEE 国際クラスター コンピューティング カンファレンス ワークショップ。浙江大学コンピューター科学技術学部、杭州、中国。p. 41。doi : 10.1109 /ClusterW.2012.27。ISBN 978-0-7695-4844-9.S2CID 12430485  。
   • Azzedin, Farag (2013)。「スケーラブルな HDFS アーキテクチャに向けて」。2013国際コラボレーション技術およびシステム会議 (CTS) 。キング ファハド石油鉱物大学情報およびコンピュータ サイエンス学部。pp. 155–161。doi :10.1109/ CTS.2013.6567222。ISBN 978-1-4673-6404-1. S2CID  45293053。
   • Krzyzanowski, Paul (2012). 「分散ファイル システム」(PDF) 。2013 年 12 月 27 日のオリジナル(PDF)からアーカイブ。2013年 12 月 27 日に取得。
   • 小林 功; 三上 俊一; 木村 秀; 建部 修 (2011).コンピューティングクラウド上の Gfarm ファイルシステム。並列分散処理ワークショップおよび Phd フォーラム (IPDPSW)、2011 IEEE 国際シンポジウム。筑波大学大学院システム情報工学研究科、筑波、日本。doi : 10.1109/IPDPS.2011.255。
   • Humbetov, Shamil (2012)。「MapReduce と Hadoop によるデータ集約型コンピューティング」。2012第 6 回国際情報通信技術応用会議 (AICT)。アゼルバイジャン、バクー、カフカズ大学コンピューター工学部。pp. 1–5。doi :10.1109 / ICAICT.2012.6398489。ISBN 978-1-4673-1740-5. S2CID  6113112。
   • Hsiao, Hung-Chang; Chung, Hsueh-Yi; Shen, Haiying; Chao, Yu-Chang (2013). 「クラウドにおける分散ファイルシステムの負荷再調整」。並列および分散システム、IEEE Transactions on . 24 (5). 国立成功大学、台南: 951–962. doi :10.1109/TPDS.2012.196. S2CID  11271386.
   • Kai, Fan; Dayang, Zhang; Hui, Li; Yintang, Yang (2013)。「HDFS における適応型フィードバック負荷分散アルゴリズム」。2013第5 回インテリジェント ネットワーキングおよびコラボレーション システムに関する国際会議。中国西安市西安電電大学統合サービス ネットワーク国家重点研究室。pp. 23–29。doi :10.1109 / INCoS.2013.14。ISBN 978-0-7695-4988-0.S2CID 14821266  。
   • Upadhyaya, B; Azimov, F; Doan, TT; Choi, Eunmi; Kim, Sangbum; Kim, Pilsung (2008)。「分散ファイル システム: データ アクセスと通信の効率実験」。2008第 4 回ネットワーク コンピューティングと高度情報管理に関する国際会議。School of Bus. IT、Kookmin Univ.、ソウル。pp. 400–405。doi :10.1109 / NCM.2008.164。ISBN 978-0-7695-3322-3. S2CID  18933772。
   • Soares, Tiago S.; Dantas†, MAR; de Macedo, Douglas DJ; Bauer, Michael A (2013)。「高性能分散ファイルシステムを利用したプライベートクラウドストレージ環境でのデータ管理」。2013ワークショップ「Enabling Technologies: Infrastructure for Collaborative Enterprises」。nf. & Statistic Dept. (INE)、Fed. Univ. of Santa Catarina (UFSC)、Florianopolis、ブラジル。pp. 158–163。doi : 10.1109 / WETICE.2013.12。ISBN 978-1-4799-0405-1. S2CID  6155753。
   • Adamov, Abzetdin (2012)。「データ集約型コンピューティングの基礎としての分散ファイルシステム」。2012第6 回国際情報通信技術応用会議 (AICT)。コンピュータ工学部、Qafqaz 大学、バクー、アゼルバイジャン。pp. 1–3。doi :10.1109 / ICAICT.2012.6398484。ISBN 978-1-4673-1740-5. S2CID  16674289。
   • Schwan Philip (2003)。「Lustre: 1,000 ノード クラスタ用のファイル システムの構築」(PDF) 。2003 Linux シンポジウムの議事録。Cluster File Systems, Inc.: 400–407。
   • Jones, Terry、Koniges, Alice、Yates, R. Kim (2000)。「IBM General Parallel File System のパフォーマンス」(PDF)。Parallel and Distributed Processing Symposium、2000。IPDPS 2000。議事録。第 14 回国際。ローレンス リバモア国立研究所。2013年 2 月 26 日にオリジナル(PDF)からアーカイブ。2014年 1 月 24 日に取得。
   • Weil, Sage A.; Brandt, Scott A.; Miller, Ethan L.; Long, Darrell DE (2006). Ceph: スケーラブルで高性能な分散ファイルシステム(PDF) 。第 7 回オペレーティングシステム設計および実装に関する会議 (OSDI '06) の議事録。2012年 3 月 9 日のオリジナル(PDF)からアーカイブ。2014 年 1 月 24 日に取得。
   • Maltzahn, Carlos; Molina-Estolano, Esteban; Khurana, Amandeep; Nelson, Alex J.; Brandt, Scott A.; Weil, Sage (2010)。Hadoop 分散ファイルシステムのスケーラブルな代替手段としての Ceph (PDF) (レポート)。
   • SA, Brandt; EL, Miller; DDE, Long; Lan, Xue (2003)。「大規模分散ストレージ システムにおける効率的なメタデータ管理」。20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies、2003 年。(MSST 2003)。議事録。Storage Syst . Res. Center、California Univ.、Santa Cruz、 CA 、USA。pp. 290–298。CiteSeerX 10.1.1.13.2537。doi :  10.1109 / MASS.2003.1194865。ISBN 978-0-7695-1914-2. S2CID  5548463。
   • Garth A. 、 Gibson、 Rodney、MVan Meter (2000 年 11 月)。「ネットワーク接続ストレージ アーキテクチャ」(PDF)。Communications of the ACM。43 ( 11): 37–45。doi :10.1145/353360.353362。S2CID 207644891  。
   • Yee, Tin Tin; Thu Naing, Thinn (2011)。「クラウド ストレージ向け PC クラスター ベースのストレージ システム アーキテクチャ」。arXiv : 1112.2025 [ cs.DC]。
   • Cho Cho, Khaing、Thinn Thu, Naing (2011)。「クラスターベースのプライベート クラウド データ センターにおける効率的なデータ ストレージ管理システム」。2011 IEEE 国際クラウド コンピューティングおよびインテリジェンス システム カンファレンス。pp . 235–239​​。doi :10.1109/ CCIS.2011.6045066。ISBN 978-1-61284-203-5. S2CID  224635。
   • SA, Brandt; EL, Miller; DDE, Long; Lan, Xue (2011)。「クラウド コンピューティングのためのキャリア グレードのサービス指向ファイル ストレージ アーキテクチャ」。2011第 3 回 Web 社会シンポジウム。PCN&CAD センター、北京郵電大学、北京、中国。pp. 16–20。doi :10.1109 / SWS.2011.6101263。ISBN 978-1-4577-0211-2. S2CID  14791637。
   • Ghemawat, Sanjay、Gobioff, Howard、Leung, Shun-Tak ( 2003)。「Google ファイル システム」。第 19 回 ACM オペレーティング システム原理シンポジウム議事録 - SOSP '03。pp. 29–43。doi :10.1145/ 945445.945450。ISBN 978-1-58113-757-6. S2CID  221261373。
2. 安全
   • Vecchiola, C; Pandey, S; Buyya, R (2009)。「高性能クラウドコンピューティング: 科学アプリケーションの視点」。2009第 10 回パーベイシブシステム、アルゴリズム、ネットワークに関する国際シンポジウム。メルボルン大学コンピュータ科学およびソフトウェア工学部、メルボルン、ビクトリア州、オーストラリア。pp . 4–16。arXiv : 0910.1979。doi : 10.1109 /I-SPAN.2009.150。ISBN 978-1-4244-5403-7.S2CID 1810240  。
   • Miranda, Mowbray; Siani, Pearson (2009)。「クラウド コンピューティング用のクライアント ベースのプライバシー マネージャー」。通信システム ソフトウェアとミドルウェアに関する第 4 回国際 ICST 会議議事録 - COMSWARE '09 。p . 1。doi : 10.1145 /1621890.1621897。ISBN 978-1-60558-353-2. S2CID  10130310。
   • Naehrig, Michael; Lauter, Kristin ( 2013)。「準同型暗号化は実用的か?」クラウド コンピューティング セキュリティ ワークショップに関する第 3 回 ACM ワークショップ議事録 - CCSW '11 。pp . 113–124。CiteSeerX 10.1.1.225.8007。doi :  10.1145 /2046660.2046682。ISBN 978-1-4503-1004-8. S2CID  12274859。
   • Du, Hongtao; Li, Zhanhuai (2012)。「PsFS: 安全なクラウド ストレージ システムのための高スループット並列ファイル システム」。2012国際計測情報制御会議 (MIC)。第 1 巻。Comput. Coll.、Northwestern Polytech. Univ.、西安、中国。pp. 327–331。doi :10.1109 / MIC.2012.6273264。ISBN 978-1-4577-1604-1. S2CID  40685246。
   • A.Brandt, Scott; L.Miller, Ethan; DELong, Darrell; Xue, Lan (2003)。「大規模分散ストレージ システムにおける効率的なメタデータ管理」(PDF)。第 11 回 NASA Goddard 大容量ストレージ システムおよびテクノロジ カンファレンス、カリフォルニア州サンディエゴ。カリフォルニア大学サンタクルーズ校ストレージ システム研究センター。2013年 8 月 22 日のオリジナル(PDF)からアーカイブ。2013年 12 月 27 日取得。
   • Lori M. Kaufman (2009)。「クラウド コンピューティングの世界におけるデータ セキュリティ」。セキュリティとプライバシー、IEEE。7 ( 4): 161–64。doi :10.1109/ MSP.2009.87。S2CID 16233643  。
   • Bowers, Kevin; Juels, Ari; Oprea, Alina ( 2009)。「HAIL: クラウド ストレージの高可用性と整合性レイヤー」。第 16 回 ACM コンピュータおよび通信セキュリティ会議の議事録。pp. 187–198。doi :10.1145/ 1653662.1653686。ISBN 978-1-60558-894-0. S2CID  207176701。
   • Juels, Ari; Oprea, Alina (2013 年 2 月)。「クラウド データのセキュリティと可用性に対する新しいアプローチ」。Communications of the ACM。56 ( 2): 64–73。doi : 10.1145 /2408776.2408793。S2CID 17596621  。
   • Zhang, Jing、Wu, Gongqing、Hu, Xuegang、Wu, Xindong (2012)。「リアルタイム クラウド サービスにおける Hadoop 分散ファイル システム用の分散キャッシュ」。2012 ACM/IEEE 第 13 回国際グリッド コンピューティング カンファレンス。中国合肥市、合肥工科大学、コンピュータ科学部。pp. 12–21。doi : 10.1109/ Grid.2012.17。ISBN 978-1-4673-2901-9.S2CID 10778240  。
   • A., Pan; JP, Walters; VS, Pai; D.-ID, Kang; SP, Crago (2012)。「クラウド コンピューティング環境での高性能ファイル システムの統合」。2012 SC コンパニオン: 高性能コンピューティング、ネットワーク ストレージおよび分析。電気工学およびコンピュータ工学部、パデュー大学、ウェスト ラファイエット、インディアナ州、米国。pp. 753–759。doi : 10.1109/ SC.Companion.2012.103。ISBN 978-0-7695-4956-9. S2CID  5554936。
   • Fan-Hsun, Tseng; Chi-Yuan, Chen; Li-Der, Chou; Han-Chieh, Chao (2012)。「信頼性が高く安全なクラウド分散ファイル システムの実装」。2012国際インテリジェント信号処理および通信システム シンポジウム。国立中央大学コンピュータ科学および情報工学部、台湾桃園。pp. 227–232。doi : 10.1109/ISPACS.2012.6473485。ISBN 978-1-4673-5082-2. S2CID  18260943。
   • Di Sano, M; Di Stefano, A; Morana, G; Zito, D (2012)。「File System As-a-Service: クラウド内の連携アプリケーションにファイルの一時的かつ一貫したビューを提供する」。2012 IEEE 21st International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises。Dept . of Electr., Electron. & Comput. Eng., Univ. of Catania, Catania, Italy。pp. 173–178。doi : 10.1109 / WETICE.2012.104。ISBN 978-1-4673-1888-4. S2CID  19798809。
   • Zhifeng, Xiao; Yang, Xiao (2013). 「クラウドコンピューティングにおけるセキュリティとプライバシー」. IEEE Communications Surveys and Tutorials . 15 (2): 843–859. CiteSeerX  10.1.1.707.3980 . doi :10.1109/SURV.2012.060912.00182. S2CID  206583820.
   • John B, Horrigan (2008)。「クラウド コンピューティング アプリケーションとサービスの使用」(PDF)。2013 年 7 月 12 日にオリジナル(PDF)からアーカイブ。2013年 12 月 27 日に取得。
   • Yau, Stephen; An, Ho (2010) 「クラウド コンピューティング システムにおける機密保護」Int J Software Informatics : 351–365。
   • Carnegie, Bin Fan; Tantisiriroj, Wittawat; Xiao, Lin; Gibson, Garth (2009)。「DiskReduce: データ集約型スケーラブルコンピューティングのための RAID」。ペタスケールデータストレージに関する第 4 回年次ワークショップの議事録。pp . 6–10。doi :10.1145 / 1713072.1713075。ISBN 978-1-60558-883-4.S2CID 15194567  。
   • Wang, Jianzong、Gong, Weijiao、 P ., Varman、Xie, Changsheng (2012)。「クラウド RAID システムにおける小規模書き込みボトルネック回避によるストレージ オーバーヘッドの削減」。2012 ACM/IEEE 第 13 回国際グリッド コンピューティング会議。pp. 174–183。doi :10.1109/ Grid.2012.29。ISBN 978-1-4673-2901-9. S2CID  16827141。
   • Abu-Libdeh, Hussam、Princehouse, Lonnie、Weatherspoon, Hakim (2010)。「RACS: クラウド ストレージの多様性の事例」。第 1 回 ACM クラウド コンピューティング シンポジウムの議事録。pp. 229–240。doi :10.1145 / 1807128.1807165。ISBN 978-1-4503-0036-0. S2CID  1283873。
   • Vogels, Werner (2009). 「最終的に一貫性がある」Communications of the ACM . 52 (1): 40–44. doi : 10.1145/1435417.1435432 .
   • Cuong, Pham; Cao, Phuong; Kalbarczyk, Z; Iyer, RK (2012)。「高可用性クラウドに向けて: 技術と課題」。IEEE /IFIP 国際ディペンダブルシステムおよびネットワーク会議ワークショップ (DSN 2012)。pp. 1–6。doi : 10.1109/ DSNW.2012.6264687。ISBN 978-1-4673-2266-9. S2CID  9920903。
   • A., Undheim; A., Chilwan; P., Heegaard ( 2011)。「クラウド コンピューティング SLA における差別化された可用性」。2011 IEEE/ACM 第 12 回国際グリッド コンピューティング会議。pp. 129–136。doi :10.1109 / Grid.2011.25。ISBN 978-1-4577-1904-2. S2CID  15047580。
   • Qian, Haiyang; D., Medhi; T., Trivedi (2011). 「クラウド コンピューティングでホストされるオンライン サービスのエクスペリエンス品質を評価する階層モデル」Communications of the ACM . 52 (1): 105–112. CiteSeerX  10.1.1.190.5148 . doi :10.1109/INM.2011.5990680. S2CID  15912111.
   • Ateniese, Giuseppe; Burns, Randal; Curtmola, Reza; Herring, Joseph; Kissner, Lea; Peterson, Zachary; Song, Dawn (2007)。「信頼できないストアでの証明可能なデータ所有」。第 14 回 ACM コンピュータおよび通信セキュリティ会議 - CCS '07 の議事録。pp. 598–609。doi : 10.1145 / 1315245.1315318。ISBN 978-1-59593-703-2. S2CID  8010083。
   • Ateniese, Giuseppe; Di Pietro, Roberto; V. Mancini, Luigi; Tsudik, Gene (2008)。「スケーラブルで効率的な証明可能なデータ保有」。通信ネットワークにおけるセキュリティとプライバシーに関する第 4 回国際会議の議事録- Secure Comm '08。p. 1。CiteSeerX 10.1.1.208.8270。doi :  10.1145 /1460877.1460889。ISBN 978-1-60558-241-2. S2CID  207170639。
   • Erway, Chris; Küpçü, Alptekin; Tamassia, Roberto; Papamanthou, Charalampos (2009)。「動的証明可能データ保有」。第 16 回 ACM コンピュータおよび通信セキュリティ会議議事録 - CCS '09。pp. 213–222。doi :10.1145 / 1653662.1653688。ISBN 978-1-60558-894-0.S2CID 52856440  。
   • Juels, Ari; S. Kaliski, Burton (2007)。「Pors: 大規模ファイルの検索可能性の証明」。第 14 回 ACM コンピュータおよび通信セキュリティ会議の議事録。pp. 584–597。doi : 10.1145 / 1315245.1315317。ISBN 978-1-59593-703-2. S2CID  6032317。
   • Bonvin, Nicolas、Papaioannou, Thanasis、Aberer, Karl (2009)。「クラウド ストレージ用の自己組織化、フォールト トレラント、スケーラブルなレプリケーション スキーム」。第 1 回 ACM クラウド コンピューティング シンポジウムの議事録 - SoCC '10。pp. 205–216。doi : 10.1145 / 1807128.1807162。ISBN 978-1-4503-0036-0. S2CID  3261817。
   • Tim, Kraska; Martin, Hentschel; Gustavo, Alonso; Donald , Kossma (2009)。「クラウドにおける一貫性の配給: 必要なときだけ支払う」。VLDB Endowment の議事録。2 (1): 253–264。doi : 10.14778 /1687627.1687657。
   • Daniel, J. Abadi (2009). クラウドでのデータ管理: 限界と機会 (レポート). CiteSeerX  10.1.1.178.200 .
   • アリ、ジュエルズ。 S.、バートン。ジュニア、カリスキー (2007)。 「Pors: 大きなファイルの取得可能性の証明」。ACM の通信。56 (2): 584–597。土井：10.1145/1315245.1315317。S2CID  6032317。
   • Ari, Ateniese; Randal, Burns; Johns, Reza; Curtmola, Joseph; Herring, Burton; Lea, Kissner; Zachary, Peterson; Dawn, Song (2007)。「信頼できないストアでの証明可能なデータ所有」。CCS '07 Proceedings of the 14th ACM conference on Computer and communications security. pp. 598–609. doi :10.1145/1315245.1315318. ISBN 978-1-59593-703-2. S2CID  8010083。
3. 同期
   • Uppoor, S; Flouris, MD; Bilas, A (2010)。「分散ファイル システム階層のクラウド ベースの同期」。2010 IEEE 国際クラスター コンピューティング ワークショップおよびポスター会議 (CLUSTER WORKSHOPS)。Inst. of Comput. Sci. (ICS)、Found. for Res. & Technol. - Hellas (FORTH)、ヘラクリオン、ギリシャ。pp. 1–4。doi : 10.1109 / CLUSTERWKSP.2010.5613087。ISBN 978-1-4244-8395-2. S2CID  14577793。
4. 経済的側面
   • Lori M.、 Kaufman (2009)。「クラウド コンピューティングの世界におけるデータ セキュリティ」。セキュリティとプライバシー、IEEE。7 ( 4): 161–64。doi : 10.1109/MSP.2009.87。S2CID 16233643  。
   • Marston, Sean; Lia, Zhi; Bandyopadhyaya, Subhajyoti; Zhanga, Juheng; Ghalsasi, Anand (2011)。クラウド コンピューティング - ビジネスの観点。意思決定支援システム、第 51 巻、第 1 号。pp. 176–189。doi : 10.1016/j.dss.2010.12.006。
   • Angabini, A; Yazdani, N; Mundt, T; Hassani, F (2011)。「科学データ分析アプリケーションに対するクラウド コンピューティングの適性: 実証的研究」。2011年国際会議 P2P、並列、グリッド、クラウド、インターネット コンピューティング。Sch. of Electr. & Comput. Eng.、テヘラン大学、テヘラン、イラン。pp. 193–199。doi :10.1109/ 3PGCIC.2011.37。ISBN 978-1-4577-1448-1. S2CID  13393620。