クラウド ストレージ製品の簡単な分析

主なクラウド ストレージ製品には、オブジェクト ストレージ、ブロック ストレージ、ネットワーク ファイル システム (NAS)、そして最も高価な CDN などがあります。クラウド ストレージの選び方を知っていただくために、これらの主流製品の機能について説明します。もちろん、技術著者として、実装のアイデアについても簡単に説明します。情報セキュリティ上の理由により、産業用ソリューションを完全に説明することは不可能です。業界の大手メーカーの上位ストレージ製品の多くは、基盤となるファイル システムに大きく依存しています。ストレージの元祖であるDFSについてもお話ししましょう。

1. Linux IOスタック

クラウド コンピューティングの本質は、単一のマシンの計算能力を究極的に拡張することです。まず、単一のマシンのファイルと IO 管理を見てみましょう。 Linux オペレーティング システムでの IO 操作は、ファイル システム vfs、スケジューリング アルゴリズム、ブロック デバイス レイヤーを経由して、最終的にディスクに到達する必要があります。

• vfsレイヤーは、ネットワークプロトコルから派生したNAS製品向けの特定のNFS/smbfsサポートを備えています。
• VFS には、ユーザー モード コンテキストに切り替えることができるヒューズ ファイル システムもあります。上位層の分散ストレージがLibfuseインターフェースに適合していれば、バックエンドストレージにアクセスできる。
• デバイス層では、ISCSI ネットワーク プロトコルを拡張することによってブロック ストレージが導出されます。

2. ストレージ製品アーキテクチャスクール

1. 階層化または平準化

たとえば、HBase は HDFS ファイル システムに基づいています。 HBase はレプリケーションを考慮する必要がなく、独自のドメインの問題に集中できます。

特徴: 開発コストを大幅に削減します。安定性は基盤となるストレージに依存します。基盤となるストレージが不安定な場合、上位層に影響が出ます。

2. シャフト

独自のレプリケーション、独自のコピーリカバリ、独自の書き込み時リカバリを実行します

マスタースレーブシステムアーキテクチャ

多数の小さなファイルを解決するための 2 層インデックス システム:

• ***層では、マスターはルーティングテーブルを維持し、fileurlを通じて対応するスレーブの場所（IP+ポート）を見つけます。
• 2番目の層であるスレーブスタンドアロンインデックスシステムは、特定の場所を見つけて生データを読み出す。

ドフス

3. 特徴

豊富なPOSIXライクなセマンティクス、追加専用ストレージを特徴とし、pwriteをサポートしない

4. 問題が発生する可能性がある

• EB レベルではなく、Pb レベルのストレージ ソリューションです。理由: Namenodeは集中型サーバーであり、メモリとQPSのボトルネックがあり、コウモリサイズの企業は何百ものクラスターを運用および維持する必要がある。
• デフォルトでは 3 つのコピーが作成されますが、コストがかかります。
• 強力な一貫性のある書き込み、遅いノードの問題

5. 進化

GFS2 はネームノードをディレクトリ ツリー、ブロック サービス、およびフェデレーションに分割しますが、名前空間集中型サーバーの欠陥は残ります。同時に、イメージを分割するにはサービスを停止する必要があり、水平方向の拡張はあまり使いやすくありません。

3. オブジェクトストレージ

1. メタデータ管理

Blobstorage: blobid->[生データ]

メタストア、aws s3、別名キーマップは、本質的には kv システムです。ストレージコンテンツ file_url->[blobid list]

2. I/Oパス

• httpserverは複数部から成るフォームを受け取り、固定サイズの生データを受け取り、それをK個の等長ストリップに分割する。
• ストリップは EC として使用され、(NK) 個のコーディング ブロックが生成され、合計 N 個のシャードが生成されます。ここで問題となるのは、これらのN個のデータのコピーをどこに保存するかである。
• クライアント エージェントは、Blobstorage からグローバル ID を申請し続けます。この ID は、実際のバックエンド ノードのアドレスと、このノードによって管理される実際の物理ボリュームを表します。各シャード データはこれらの物理ボリュームに均等に保存されます。
• データのコピーを N 個配布して書き込みます。安全なコピーの数が満たされると、書き込み成功が返されます。書き込みが失敗した場合、EC メソッドを遅延させて修復することができます。
• httpserver は、ファイル ファイルと対応するシャード リストを KV 形式でメタストアに書き込みます。

3. 特徴

http プロトコル ws サービスに基づいており、インターフェースはシンプルで、put/get であり、レイテンシは高くなります。クラウド製品に適した EB レベルのストレージ ソリューション。深いディレクトリ ツリーは 2 レベルのディレクトリ構造 (バケット + オブジェクト) になります。

4. デメリット

POSIX セマンティック インターフェイスは少なすぎて、ランダム書き込みはおろか、追加セマンティクスも提供されません (実際には上書きによって提供されます)。

ブロックストレージ

1. iSCSI モデル

バックエンドと対話する部分はカーネルに実装されています。バックエンド ターゲットは、iscsi プロトコルを解析し、要求をバックエンドの分散ストレージにマップします。

2. 特徴

• リクエスト サイズのほとんどは 4 KB に揃えられたブロック サイズです。ブロック デバイスは通常、上位レベルのファイル システムで使用され、ほとんどの主流のファイル システムのブロック サイズは 4 KB です。ファイル操作の最小粒度はブロックなので、ほとんどの IO 要求は 4 KB に揃えられます。
• 強い一貫性。ブロック デバイスは強力な一貫性を提供する必要があります。つまり、書き込みが戻った後、書き込まれたデータを読み取ることができます。
• ランダム書き込みと低レイテンシをサポートします。ユーザーは仮想ブロックデバイスに基づいてファイルシステム (ext4) を構築します。ファイル編集操作は非常に頻繁に行われるため、ランダム書き込みのサポートが必要です。 NAS/Fuse 製品よりも優れたパフォーマンス。ブロックデバイスの読み取り/書き込みのみがハッキングされます。上位層の dentry 検索は、依然として元の IO パスに従います。 NAS/FUSE dentry ルックアップによって開始される複数の RPC の問題はありません。
• 事前に容量を購入する必要があり、容量拡張には再マウントが必要で、NASに比べてスペースを無駄にする可能性が高くなる

3. モデルを実装する

クラウド ディスクの論理ボリュームはブロックに分割されます。回復を容易にするために、1Gに分割されています。最上位レベルのルーティングは blockManager によって管理され、volumeid+offset に従って論理ブロックにマッピングされます。論理ブロックの場所は 3 つのブロック サーバー上にあります。 Blockserver は、書き込み処理中にスペース不足が発生しないように、事前に 1G のファイルを作成します (falloc)。これは物理ブロックと呼ばれます。論理ボリュームのこの間隔では、すべての IO 操作はこの物理ブロック ファイルで実行され、pwrite を簡単に実装できます。もちろん、OSの視点では大きなファイルであり、1Gの異なるファイルに分割できるRAWディスクをベースにすることもできます。

4. IOパス

ブロックデバイスの上位層にはファイルシステムが存在します。 IO スケジューリング アルゴリズムの後、IO 操作がマージされます。 isici プロトコルによって発行される IO 要求はすべてセクター LBA に対する操作であるため、ボリューム ID とオフセットに対する操作に簡単に抽象化できます。 EBS (Elastic Block Store) 層の IO パスについて簡単に説明します。

• ネットワークから送信されたIO要求は、書き込み要求であると仮定すると、ボリューム+オファーセット操作用である。
• blockManagerを通じて論理ブロックを見つける
• メモリ内のブロックに対応する物理アドレス（IP+ポート）とブロックのレプリケーショングループを見つける
• 業界で一般的なレプリケーション チェーン メソッド (raft プロトコルなど) を使用して、io 要求を replicationGroup に送信します。 Raftは書き込み失敗のtuncate問題を解決するのに役立ちます
• 単一のノードがIO要求を受け取り、LBAを実際のファイルオフセットに変換し、pwriteを使用して書き込みます。

5. 最適化

• このストレージ モデルでは、バックエンド ノードに大量のランダム書き込みが発生し、スループットが確実に高くならないと考えられます。最適化の余地はたくさんあります。ランダム書き込みは、LSM エンジンと同様の方法によって順次書き込みに変換できます。読者はそれについて深く考えることができるので、この記事では詳細には説明しません。
• 仮想ディスクはストリップに分割することができ、これは RAID ディスクの考え方に相当します。単一ディスクの IO が複数のディスクに変換され、スループットが向上します。

5. NAS

ユーザーはマウント ディレクトリを通じて共有ファイルにアクセスします。マウント ポイントは NFS プロトコルのファイル システムにマウントされ、TCP を介して NFS サーバーにアクセスします。

NFS サーバーは、最終的に libcfs を介してバックエンド ストレージ システムにアクセスするプロキシです。

1. バックエンドストレージシステム

DSには、inodeを管理するためのメタストアとデータストアが含まれています。

（１）メタストア

当社は、業界における DFS の欠点を十分に吸収し、Namenode 集中型サーバーのボトルネックを解決し、Bigtable のさまざまな利点を十分に考慮します。メタストアは分散データベース (newsql) をベースにすることができます。 BigTableを思い出してください。ユーザーのファイルは複数のタブレットサーバーに分散されています。ユーザーがタブレット サーバー間で名前を変更できるようにするには、上記の保証を完了するために分散トランザクションが必要です。 DFS を改善するために、ディレクトリ ツリーの永続性のために Linux fs dentry 管理を模倣します。マッピング ルールは次のとおりです: 2 つのテーブル、dentry テーブルと inode テーブル。 dentry テーブルはディレクトリ ツリーを記述し、inode テーブルはファイル ブロック リストと、atime、mtime、uid、gid などのソース情報を記述します。一般的に言えば、ハードリンクで十分です。このシナリオでは、dentry は複数のコピーになり、一緒に 1 つの inode を指すことができます。デントリーは外部キーを通じてinodeテーブルに関連付けられている

（２）デントリーテーブル

（３）iノードテーブル

たとえば、ルックアップ子ノード

SELECT i.* FROM Dentry d, Inode i WHERE d.PARENT_DID =$PARENT_ID AND d.NAME =$NAME AND d.FSID =$FSID and i.inode_id = d.inode_id;

（4）データストア

特徴: ランダム書き込みを提供する必要があるため、設計コンセプトはブロックストレージ EBS と同じです。大きなファイルはブロックに分割され、ブロックごとに整理されます。データサーバー上には実際の物理ブロック ファイルがあり、pwrite 操作を提供します。

2. 特徴

弾力性のある容量、無制限の容量、複数のマシンでの並列読み取りと書き込み、IO の線形増加、ランダム書き込みのサポート。ブロックストレージの利点は、使用した分だけ支払うことと、事前に容量を申請する必要がないことです。本当に弾力性があります。

3. デメリット

vfs レイヤー dentry ルックアップは、各レベルのディレクトリに対して rpc を開始するため、待ち時間が長くなります。

VI.結論

[この記事は、51CTO のコラムニスト「ビッグデータとクラウド コンピューティング」によるオリジナル記事です。転載する場合はWeChatの公開アカウントを通じて連絡し、許可を得てください。

この著者の他の記事を読むにはここをクリックしてください