JF Linux Kernel 3.x/2.6 Documentation: /usr/src/linux/Documentation/filesystems/ceph.txt

filesystems/ceph.txt

ceph 分散ファイルシステムの解説 [プレインテキスト版]


=========================================================
これは、
Linux-3.4.1/Documentation/filesystems/ceph.txt の和訳です。
翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
更新日 : 2012/6/13
翻訳者 : Seiji Kaneko < skaneko at mbn dot or dot jp >
=========================================================
#Ceph Distributed File System
#============================
Ceph 分散ファイルシステム
=========================

#Ceph is a distributed network file system designed to provide good
#performance, reliability, and scalability.
Ceph は良好な性能、信頼性、拡張性を追求して設計された分散ネットワークファ
イルシステムです。

#Basic features include:
以下の基本機能が提供されています。

# * POSIX semantics
# * Seamless scaling from 1 to many thousands of nodes
# * High availability and reliability.  No single point of failure.
# * N-way replication of data across storage nodes
# * Fast recovery from node failures
# * Automatic rebalancing of data on node addition/removal
# * Easy deployment: most FS components are userspace daemons
 * POSIX 互換
 * 1 から数千のノードまでシームレスに拡張可能
 * 高可用、高信頼性。単一故障点の排除
 * ストレージノード間での N-way 複製機能
 * ノード故障からの速やかな回復
 * ノード追加・削除に対するデータの自動再バランス
 * 容易なノード展開: 殆どの FS コンポーネントはユーザ空間で動作するデー
   モン
 
#Also,
# * Flexible snapshots (on any directory)
# * Recursive accounting (nested files, directories, bytes)
また
 * 柔軟なスナップショット (どのディレクトリでも可)
 * 再帰アカウンティング (ファイル、ディレクトリ、バイトデータのネスト)

#In contrast to cluster filesystems like GFS, OCFS2, and GPFS that rely
#on symmetric access by all clients to shared block devices, Ceph
#separates data and metadata management into independent server
#clusters, similar to Lustre.  Unlike Lustre, however, metadata and
#storage nodes run entirely as user space daemons.  Storage nodes
#utilize btrfs to store data objects, leveraging its advanced features
#(checksumming, metadata replication, etc.).  File data is striped
#across storage nodes in large chunks to distribute workload and
#facilitate high throughputs.  When storage nodes fail, data is
#re-replicated in a distributed fashion by the storage nodes themselves
#(with some minimal coordination from a cluster monitor), making the
#system extremely efficient and scalable.
GFS、OCFS2 そして GPFS などのクラスタファイルシステムは、各クライアント
からの共有ブロックデバイスへの対称なアクセスを前提としていますが、Ceph 
は Lustre と似た、データとメタデータを分離して独立のサーバクラスタに置
く構成を採っています。一方、Lustre とは違ってメタデータとストレージノ
ードは完全にユーザ空間デーモンで走ります。ストレージノードはデータオブ
ジェクトの格納に btrfs を使って、その先進機能 (チェックサム、メタデータレ
プリケーション) を活用しています。ファイルデータは、大きなチャンク単位
でストレージノード間でストライプされ、負荷を分散して高いスループットを
実現しています。一つのストレージノードが故障した場合、クラスタモニタの
最小限の介入だけで、ストレージノード間自身でデータのレプリケーションが
再実行されるため、システムは極めて効率的で拡張性に富んだものとなってい
ます。

#Metadata servers effectively form a large, consistent, distributed
#in-memory cache above the file namespace that is extremely scalable,
#dynamically redistributes metadata in response to workload changes,
#and can tolerate arbitrary (well, non-Byzantine) node failures.  The
#metadata server takes a somewhat unconventional approach to metadata
#storage to significantly improve performance for common workloads.  In
#particular, inodes with only a single link are embedded in
#directories, allowing entire directories of dentries and inodes to be
#loaded into its cache with a single I/O operation.  The contents of
#extremely large directories can be fragmented and managed by
#independent metadata servers, allowing scalable concurrent access.
メタデータサーバは、実効的には上記のファイル名前空間に対する、巨大で整
合性の採れた分散インメモリキャッシュを構成します。このメタデータサーバ
は極めて拡張性が高く、負荷の変動に伴って動的にメタデータを再配置し、
(まぁ、特にまずい場合でなければ) 任意のノードの故障に耐えるようになっ
ています。
メタデータサーバでは、一般的な負荷での性能を大きく向上するため、メタデ
ータストレージとしてはやや一般的ではない手法を採っています。特に、リン
クの一つしかない inode はディレクトリに埋め込まれ、dentry と inode の
ディレクトリ全体が一つの I/O 処理でキャッシュに取り込めるようにしてい
ます。極めて巨大なディレクトリの内容は複数の独立なメタデータサーバに分
割されて管理されるため、拡張性に優れた並行アクセスが可能になっています。

#The system offers automatic data rebalancing/migration when scaling
#from a small cluster of just a few nodes to many hundreds, without
#requiring an administrator carve the data set into static volumes or
#go through the tedious process of migrating data between servers.
#When the file system approaches full, new nodes can be easily added
#and things will "just work."
システムでは、管理者のデータセット指定なしの、小さな (数ノード) クラス
タから数百までの拡張を行った場合の、自動データ再バランス/マイグレーショ
ン機能を提供しています。管理者は固定サイズのボリュームにデータセットを
作成したり、サーバ間でデータの移動を行ったりの疲れる作業から解放されま
す。また、ファイルシステムが一杯になりつつある場合、新しいノードを簡単
に追加し、「即動作」を可能としています。

#Ceph includes flexible snapshot mechanism that allows a user to create
#a snapshot on any subdirectory (and its nested contents) in the
#system.  Snapshot creation and deletion are as simple as 'mkdir
#.snap/foo' and 'rmdir .snap/foo'.
Ceph には柔軟なスナップショット機能が提供されていて、ユーザはシステム
の任意のサブディレクトリ (およびネストされたコンテンツ) のスナップショ
ットを作成可能です。スナップショットの作成と削除は、'mkdir .snap/foo' 
と 'rmdir .snap/foo' を行うだけの簡単さです。

#Ceph also provides some recursive accounting on directories for nested
#files and bytes.  That is, a 'getfattr -d foo' on any directory in the
#system will reveal the total number of nested regular files and
#subdirectories, and a summation of all nested file sizes.  This makes
#the identification of large disk space consumers relatively quick, as
#no 'du' or similar recursive scan of the file system is required.
さらに、Ceph ではネストされたディレクトリやデータに対する再帰的アカウ
ンティング機能が提供されています。具体的には、システムのどのディレクト
リででも 'getfattr -d foo' を実行すれば、ネストされた通常のファイルとサ
ブディレクトリ数、ネストされたファイルサイズの合計が得られます。これに
より、du などのファイルシステムの再帰スキャン処理を必要とせずに、多量
のディスクを消費している犯人を比較的速く摘発できます。


#Mount Syntax
#============
マウントの書式
==============

#The basic mount syntax is:
基本的なマウントの書式は以下のとおりです。

 # mount -t ceph monip[:port][,monip2[:port]...]:/[subdir] mnt

#You only need to specify a single monitor, as the client will get the
#full list when it connects.  (However, if the monitor you specify
#happens to be down, the mount won't succeed.)  The port can be left
#off if the monitor is using the default.  So if the monitor is at
#1.2.3.4,
一つ以上のモニタを指定する必要はありません。クライアントは接続時にモニ
タ全体のリストを取得するためです。但し、指定したモニタが万が一ダウンし
ていた場合、マウントは失敗します。ポートは、モニタが既定値を用いている
場合、指定する必要はありません。まとめると、モニタが 1.2.3.4 にある場
合、以下の指定で十分となります。

 # mount -t ceph 1.2.3.4:/ /mnt/ceph

#is sufficient.  If /sbin/mount.ceph is installed, a hostname can be
#used instead of an IP address.
/sbin/mount.ceph がインストールされているなら、IP アドレスの代わりにホ
スト名も使えます。


#Mount Options
#=============
マウントオプション
==================

  ip=A.B.C.D[:N]
#	Specify the IP and/or port the client should bind to locally.
#	There is normally not much reason to do this.  If the IP is not
#	specified, the client's IP address is determined by looking at the
#	address its connection to the monitor originates from.
	クライアントがローカルで設定すべき IP および/または ポートを指
	定します。通常はこれを行う理由はあまりありません。IP 番号が指
	定されていない場合、クライアントの IP アドレスはモニタへの接続
	を行った接続元アドレスを調べることで決定されます。

  wsize=X
#	Specify the maximum write size in bytes.  By default there is no
#	maximum.  Ceph will normally size writes based on the file stripe
#	size.
	書き込める最大のバイト数を指定します。既定値としては、最大値制
	限はありません。Ceph は通常はファイルストライプサイズを基準に
	書き込みを行います。

  rsize=X
#	Specify the maximum readahead.
	先読みの最大長を指定します。

  mount_timeout=X
#	Specify the timeout value for mount (in seconds), in the case
#	of a non-responsive Ceph file system.  The default is 30
#	seconds.
	Ceph ファイルシステムが応答しない場合、マウント時のタイムアウ
	ト時間を秒で指定します。既定値は 30 秒です。

  rbytes
#	When stat() is called on a directory, set st_size to 'rbytes',
#	the summation of file sizes over all files nested beneath that
#	directory.  This is the default.
	stat() がディレクトリに対して呼ばれた場合、st_size に rbytes、
	つまりディレクトリ以下にネストされているファイルサイズの合計値
	を代入します。これが既定値です。

  norbytes
#	When stat() is called on a directory, set st_size to the
#	number of entries in that directory.
	stat() がディレクトリに対して呼ばれた場合、st_size にディレク
	トリ内のエントリ数を代入します。

  nocrc
#	Disable CRC32C calculation for data writes.  If set, the storage node
#	must rely on TCP's error correction to detect data corruption
#	in the data payload.
	データ書き込み時に CRC32C 計算を行いません。このフラグがセット
	されている場合、ストレージノードのデータペイロードの破壊検出は
	TCP のエラー訂正機能に依存します。

  dcache
#        Use the dcache contents to perform negative lookups and
#        readdir when the client has the entire directory contents in
#        its cache.  (This does not change correctness; the client uses
#        cached metadata only when a lease or capability ensures it is
#        valid.)
	クライアント側でディレクトリの内容全体をキャッシュしている場合、
	readdir リクエスト処理を行う際と、逆ルックアップ (negative lookup)
	の際に、dcache キャッシュを利用しません (これはファイルシステムの正
	当性には影響しません。クライアントは、リースまたはケーパビリティに
	よってキャッシュされたメタデータが有効であることが保証されている場
	合にのみ、キャッシュされたデータを用いるからです)。

  nodcache
#        Do not use the dcache as above.  This avoids a significant amount of
#        complex code, sacrificing performance without affecting correctness,
#        and is useful for tracking down bugs.
	上記のような dcache 利用を行なわない。この指定では、ファイル整合性
	に影響することなしに性能を犠牲にし、複雑なコードのかなりの部分の実
	行を回避します。バグ追跡の際に有用です。

  noasyncreaddir
#	Do not use the dcache as above for readdir.
	readdir に対して、上記のような dcache 利用を行ないません。


#More Information
#================
追加情報
========

#For more information on Ceph, see the home page at
#	http://ceph.newdream.net/wiki
Ceph についてもっと知りたい場合は、以下のホームページをご覧ください。
	http://ceph.newdream.net/wiki

#The Linux kernel client source tree is available at
#	git://ceph.newdream.net/git/ceph-client.git
#	git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git
Linux カーネルのクライアントソースツリーは以下から提供されています。
	git://ceph.newdream.net/git/ceph-client.git
	git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git

#and the source for the full system is at
#	git://ceph.newdream.net/git/ceph.git
システム全体のソースは以下から提供されています。
	git://ceph.newdream.net/git/ceph.git

Linux カーネル 3.x/2.6 付属文書一覧へ戻る