LeoFS の概要
Apr 16, 2013動機
会社内でストレージの問題に気づきました。多くのサービスがイメージ、ドキュメントなどのような構造化されていないデータを保持している高価な ストレージに依存しています。
3つの問題を解決しなければなりません:
- LowROI:
- 低予算のサービスは高価なストレージを使用する場合に支払うことができません。
- SPOFの可能性:
- 予算によりますが、高価な製品を使った冗長構造を作ることは難しいです。
- データが増える間にストレージを拡張することは難しい:
- "高価なストレージ"を追加(拡張)することは簡単では無い。
目的
試行錯誤の結果、以下の3つのことでストレージの要求を満たすことができました:
- 一つの大きなストーレジ:
- ストレージプラットフォームと呼ばれます。
- 停止しないストレージ:
- ストレージシステムは多くのwebサービスからリクエストされるため、常に動作することが求められます。
- Webに特化:
- 全てのwebサービスはストレージシステムと簡単に通信できる必要があります。そこで、NOT FUSE ではなく REST-API over HTTPを提供することに決めました。FUSEの使用は特定のストレージに依存するため、完全にスケールすることができません。
LeoFS の概要
LeoFSは画像、ドキュメント、映像、ログデータのような様々な種類の非構造データを格納することができます。LeoFSはすでに小さなサイズのファイルから巨大なサイズのファイルまでをカバーしています。クラウドでのストレージプラットフォームの実現を狙っています。
S3-APIは多くの言語のクライアント、GUIクライアントなどを提供しているので、ストレージプラットフォームを構築するためにS3-APIを提供しようと思っています。また、それらはLeoFSと柔軟に通信することができます。
私たちの会社でLeoFSで中央化されたストレージプラットフォームを構築するのに3つのことが必要です。
- 高コストパフォーマンス率
- 高信頼性
- 高スケーラビリティ
LeoFSは3つの機能からなります - Storage, Gateway および Manager、これらはErlangに依存しています。
- ゲートウェイ
- ゲートウェイは REST=APIあるいはS3-APIを使う時にどのようなクライアントからでも http-request/response を扱います。そして、 ゲートウェイは組み込みのオブジェクトキャッシュ機構を既にもっています。
- ストレージ
- ストレージはオブジェクトおよびメタデータの GET, PUT および DELETE を処理します。また、ストレージ は実行の維持および一貫性の維持のためにリプリケータ、リカバラーおよびキューの機構を持ちます。
- マネージャー
- マネージャーはゲートウェイノードおよびストレージノードを常に監視します。主な監視ステータスは、実行の維持および一貫性の維持のためのノードステータスおよびRINGのチェックサムです。
LeoFSのシステム構成はとても単純です。LeoFSはマスターサーバを持たないため、SPOFがありません。また、LeoFSはSNMPエージェントを既に提供しています。NagiosおよびZabbixのような監視ツールを使ってLeoFSを簡単に監視することができます。
LeoFSの内部
Mutual function set of loosely connect with Erlang’s RPC as well as the internal storage-cluster.
LeoFS ゲートウェイ
LeoFSゲートウェイはステートレスプロキシとオブジェクトキャッシュからなります。高負荷の場合は簡単にゲートウェイノードを増やすことができます。We chose Cowboy as Gateway’s HTTP-Server, because we expected HIGH-Performance.
既にRestAPIとS3-APIが提供されています。それらは単純なAPIです。it requests to a storage node when inquiring RING, which is based on consistent-hashing.
Also, Object-cache mechanism (hierarchical cache) realizes reduction of traffic between Gateway and Storage.
LeoFS ストレージ
LeoFS-Storage consists of storage-engine, object-replicator, object-repairer, message queuing, and so on. Also, each storage-engine’s worker consists of metadata(s) and object-container(s) which is log-structured file.
A file (a raw data) is replicated to other nodes up to defined a number of replicas as well as metadata.
LeoFS’s data structure has 3-layers. Metadata consists of filename, file-size, checksum, and so on. An actual object is retrieved with file-name, file-size and offset. Needle is LeoFS’s original file format. A needle consists of metadata, an actual-file and footer. It’s able to recover metadata from a needle.
An object container consists of super-block and any needles.
- In case of retrieving an object from the storage:
- Storage's engine retrieves a metadata from the metadata-storage
- Retrieves an object from the object-container when using file-size and container’s offset
- In case of inserting an object into the storage:
- First, Storage's engine inserts a metadata into the metadata-storage
- Appends an object into the object storage container
This mechanism occurs side-effects. Storage's engines sometimes need to remove unnecessary objects as well as metadata. LeoFS has been taking a measure for less an effect of compaction, which is phased-compaciton. We’re considering to support auto-compaction.
LeoFS マネージャー
Manager distributes RING and Storage cluster’s members. It always monitors Node status and RING status, because LeoFS is required to realize high availability.
Also, Manager provides that it’s able to easily operation methods (suspend/resume/detach/whereis etc) for Gateway and Storage and provide RING to Gateway and Storage, so “LeoFS-manager” manages “RING”. If it found incorrect RING, it fixes RING’s consistency. If Storage found that, it notify that to Manager. Eventually, the problem is resolved by Manager.
Wrap Up
What we're really focused on is high cost performance ratio, high reliability and high scalability in order to realize to build a storage platform in our company. It will not succeed, even if one of them is lacking, I believe.