Tom White, HDFS の信頼性(原題:HDFS Reliability)

オリジナルドキュメント:HDFS Reliability

HDFS の信頼性

HDFS Reliability

Tom White, Cloudera, 2008年1月12日
Tom White, Cloudera, 12 January 2008

Hdoop分散ファイルシステム(HDFS)は、数ペタバイトにおよぶデータを高い信頼性をもって保存するための、一般的なハードウェアによるクラスター上で動作する分散ストレージ・システムである。 この短い論文は、HDFSの信頼性を評価し、HDFSを導入する際に参考となるベストプラクティスを提供する。

The Hadoop Distributed Filesystem (HDFS) is a distributed storage system for reliably storing petabytes of data on clusters of commodity hardware. This short paper examines the reliability of HDFS and makes recommendations for best practices to follow when running an HDFS installation.

HDFSの概要
Overview of HDFS

HDFS のノードには3つのクラスが存在する:

  • 一つの名前ノード、ファイルシステムのメタデータの管理に責任を負う。
  • 一つのセカンダリー名前ノード、名前ノード障害をチェックする責任を負う。
  • 多数のデータノード, ファイルデータを保存する責任を負う。
HDFS はファイルを複数のブロックからなる1つの列として保存する。 各ブロックはデフォルトで64MBのサイズである。 1つのブロックはデータノードにおけるストレージの単位である:データノードはブロックを保存し、検索するが、それらのブロックから構成されるファイルに関する情報は一切もたない。 ブロックはデータノードの下層に位置するファイルシステム上に保存される。 これは、データノードによる個別のストレージ管理を、通常のファイルシステムにおけるカーネルレベルのファイルシステム管理と対比できる。 名前ノードはファイルからブロックへのマップを保持しており、そのマップは名前ノードのメモリ上に保存されているが、同時に、永続的なメタデータとしてディスク上のファイル(イメージファイル(FsImage)と編集ログ(EditLog))にも保存されている。 ブロックとそのブロックが配置されているデータノード間のマッピングは、永続的に保存されてはいない。 マッピングは、永続的な保存ではなく、名前ノードのメモリ上に保存されており、そのマッピングはデータノードから名前ノードへ送られてくる定期的なブロックのレポートから構築される。 データノードが起動した際、まずはじめに実行することのひとつは、ブロックレポートを名前ノードに送信することである。 このブロックレポートの送信によって、名前ノードはクラスター内に存在するブロックの分布図を迅速に構成することが可能になる。

HDFS has three classes of node:

  • a single name node, responsible for managing the filesystem metadata
  • a single secondary name node, responsible for checkpointing the name node's persistent state
  • many data nodes, which are responsible for storing the file data
HDFS stores files as a series of blocks, each of which is by default 64MB in size. A block is the unit of storage for data nodes: they store and retrieve blocks, and have no concept of the files that are composed of these blocks. Blocks are stored on the underlying filesystem of the data node, as opposed to the data node managing their own storage, as a kernel-level filesystem would do. The name node holds that mapping from files to blocks, which it stores in memory as well as in a persistent metadata store on disk (in the image file and edit log). The mapping between blocks and the data nodes they reside on is not stored persistently. Instead, it is stored in the name node's memory, and is built up from the periodic block reports that data nodes send to the name node. One of the first things that a data node does on start up is send a block report to the name node, and this allows the name node to rapidly form a picture of the block distribution across the cluster.

正常に動作しているデータノードは、3秒毎に名前ノードへハートビートを送信する。 この機構はデータノードと名前ノード間の通信チャンネルを構成している: ときに、名前ノードはコマンドを付与してハートビートへのレスポンスをデータノードへ送る。 コマンドの例としては、"ブロックbのコピーをデータノードdへ送れ"などである。

Functioning data nodes send heartbeats to the name node every 3 seconds. This mechanism forms the communication channel between data node and name node: occasionally, the name node will piggyback a command to a data node on the heartbeat response. An example of a command might be "send a copy of block b to data node d".

ブロックのレプリカ
Block replicas

ブロックのレプリカ(このドキュメントでは単に"レプリカ"とする)は(データノードの障害に対処する為に)異なるデータノード、もしくは、(ラックの障害に対処する為に)異なるラックへ書き込まれる。 このラック配置ポリシー1は名前ノードにより管理されており、レプリカは次のように配置される:

  1. 第1レプリカはクラスター内のランダムに選ばれたノードに配置される。 書き込みはクラスター内部で開始されるが、この段階ではローカルノードにて開始される。
  2. 第2レプリカは第1レプリカとは異なるランダムに選択されたラックに書き込まれる。
  3. 第3レプリカは第2レプリカと同じラックに属する異なるノードに書き込まれる。
  4. 続く第4レプリカはランダムに選択されたノードに配置されるが、 多くのレプリカが存在するラックはバイアスをかけられ、 したがって、クラスター内にレプリカが散在するようになる。
ファイルが書き込まれている際、データノードは順番にレプリカを書き込むパイプラインを構成する。 データは(1個のブロックよりも小さい)パケットとしてパイプラインに送り込まれ、 各パケットは書き込み成功としてカウントされた旨の受領通知を受け取る必要がある。 ブロックが書き込まれている際にあるデータノードが失敗した場合、そのブロックはパイプラインから削除される。 現在書き込み中のブロックに対して、名前ノードは、失敗したデータノードに書き込まれるはずであった失われたレプリカを補うために、そのレプリカを再複製する。 残りの部分列を構成するブロックは、必要となるデータノードの個数をもつ新たなパイプラインを使用して、再書き込みされる。

Block replicas (referred to as "replicas" in this document) are written to distinct data nodes (to cope with data node failure), or distinct racks (to cope with rack failure). The rack placement policy1 is managed by the name node, and replicas are placed as follows:

  1. The first replica is placed on a random node in the cluster, unless the write originates from within the cluster, in which case it goes to the local node.
  2. The second replica is written to a different rack from the first, chosen at random.
  3. The third replica is written to the same rack as the second replica, but on a different node.
  4. Fourth and subsequent replicas are placed on random nodes, although racks with many replicas are biased against, so replicas are spread out across the cluster.
When files are being written the data nodes form a pipeline to write the replicas in sequence. Data is sent through the pipeline in packets (smaller than a block), each of which must be acknowledged to count as a successful write. If a data node fails while the block is being written, it is removed from the pipeline. When the current block has been written, the name node will re-replicate it to make up for the missing replica due to the failed data node. Subsequent blocks will be written using a new pipeline with the required number of data nodes.

クライアント
Clients

ファイルシステムのクライアントは、名前ノードと通信を行い、(ディレクト階層や、ファイルからそのファイルに対応するブロックへのマッピング等の)メタデータを受け取り、データノードと通信することによってデータを所得する。 重要な点は、クライアントはデータノードから直接ファイルのデータを所得することであり、名前ノードを通して所得を行っていないことである。 名前ノードを通してデータを所得することは、名前ノードにおけるボトルネックを引き起こし、クライアントへ提供可能なバンド幅の総量を厳しく制限してしまうことになる。

Filesystem clients communicate with the name node to retrieve metadata (such as information about the directory hierarchy, or the mapping from a file to its blocks), and with the data nodes to retrieve data. It is important that clients retrieve the file data direct from the data nodes rather than having it routed via the name node, as the latter would create a bottleneck at the name node and severely limit the aggregate bandwidth available to clients.

セカンダリー名前ノード
Secondary Name Node

セカンダリー名前ノードの役割は、その誤解を招きやすい名前の為に、Hadoopユーザーに少なからぬ混乱を招いている。 セカンダリー名前ノードは名前ノードのバックアップではない。 セカンダリー名前ノードは、プライマリー名前ノードの機能を引き継ぐわけではなく、チェック機構を提供する。 稼動中の名前ノードはファイルシステムの状態をあらわす2つのデータ構造をディスク上に保持している:イメージファイルと編集ログである。 イメージファイルは、ある時刻におけるファイルシステムのメタデータのチェックポイントであり、編集ログは、イメージファイルが構築された後の、ファイルシステムに対するメタデータの変更すべての処理内容を保存した再試行可能なログである。 ファイルシステムのメタデータに対する変更(例えば、新規ファイルの作成など)は、編集ログ2に記録される。 名前ノードが起動すると、編集ログを再現することにより、現在の状態を再構築する。 制限なくログが増加することはないように、ある一定の期間において編集ログはローテーションされ、古い編集ログがイメージに反映されることにより、新しいチェックポイントが作成される。 このプロセスはセカンダリー名前ノードのデーモンにより実行されるが、プライマリ名前ノードでない異なるマシン上で行われるのは、そのチェックポイント作成タスクが名前ノードそれ自身と同等のメモリ容量を必要とするからである。 チェックポイント機構の副作用として、セカンダリー名前ノードは、プライマリ名前ノードの永続的な状態の古いコピーをもつことになるが、これは非常時にファイルシステムの状態を復旧するのに利用することができる。

The role of the secondary name node has caused considerable confusion for Hadoop users, since it has a misleading name. It is not a backup name node in the sense that it can take over the primary name node's function, but rather a checkpointing mechanism. During operation the name node maintains two on-disk data structures to represent the filesystem state: an image file and an edit log. The image file is a checkpoint of the filesystem metadata at a point in time, and the edit log is a transactional redo log of every filesystem metadata mutation since the image file was created. Incoming changes to the filesystem metadata (such as creating a new file) are written to the edit log2. When the name node starts, it reconstructs the current state by replaying the edit log. To ensure that the log doesn't grow without bound, at periodic intervals the edit log is rolled, and a new checkpoint is created by applying the old edit log to the image. This process is performed by the secondary name node daemon, often on a separate machine to the primary since creating a checkpoint has similar memory requirements to the name node itself. A side effect of the checkpointing mechanism is that the secondary holds an out-of-date copy of the primary's persistent state, which, in extremis, can be used to recover the filesystem's state.

名前ノードの真の意味でのバックアップ作成は現在開発中であり、 それはプライマリーノードにおける障害に対する名前ノードのフェイルオーバーとなるであろう3

There is ongoing work to create a true backup name node, which would be a failover name node in the event of the primary failing3.

セーフモード
Safe mode

名前ノードが起動すると、ファイルシステムはリードオンリーの状態になり、いかなるブロックの複製、もしくは、削除が行われない。 このような状態は、"セーフモード"と呼ばれる。 セーフモードは名前ノードが以下の2つのことを行うのに必要である:

  1. イメージファイルをメモリに読み込み、編集ログを再試行することにより、ファイルシステムの状態を再構成する。
  2. データノードがチェックインするのに十分な時間をとって待機し、ブロックからデータノードへのマッピングを作成する。
もし名前ノードがデータノードのチェックインを待機しなければ、ブロックは複製を作成している途中であると認識され、クラスター内でのブロックの複製の再作成が開始されてしまうと思うかもしれない。 実際にはそうではなく、名前ノードは、設定可能な割合(99.9%がデフォルトである)のブロックが利用可能となるように、十分な台数のデータノードがチェックインするまで待機する。 また、その待機は、最小限の複製レベル(1がデフォルトである)が満たされるまで、行われる。 名前ノードは、さらに固定された時間(デフォルトでは30秒)の間待機を行い、セーフモードを抜ける前にクラスターを安定させる。

When the name node starts it enters a state where the filesystem is read only, and no blocks are replicated or deleted. This is called "safe mode". Safe mode is needed to allow the name node to do two things:

  1. Reconstruct the state of the filesystem by loading the image file into memory and replaying the edit log.
  2. Generate the mapping between blocks and data nodes by waiting for enough of the data nodes to check in.
If the name node didn't wait for the data nodes to check in, it would think that blocks were under-replicated and start re-replicating blocks across the cluster. Instead, the name node waits until enough data nodes check in to account for a configurable percentage of blocks (99.9% by default), which satisfy the minimum replication level (1 by default). The name node then waits a further fixed amount of time (30 seconds by default) to allow the cluster to settle down before exiting safe mode.

Hadoop の dfsadmin コマンドを利用することにより、管理者は名前ノードのセーフモードへの移行と解除を手動で行える。 これは、パフォーマンスのアップグレード(以下の"バックアップとアップグレード手続きの定義"を参照)、もしくは、クラスターの問題点の診断の際に利用できる。 また、最小限のレプリカ要求を満たすためのブロック割合を100%以上に設定することにより、セーフモードを自動的に解除しないようにクラスターを起動する手法としても利用可能である。

An administrator can make the name node enter or leave safe mode manually using Hadoop's dfsadmin command. This is useful when performing upgrades (see "Define backup and upgrade procedures" below), or diagnosing problems on the cluster. It is also possible to start the cluster is such a way that it will never leave safe mode automatically, by setting the percentage of blocks that meet the minimal replication requirement to over 100%.

Tools
ツール

distcp4 は HDFS クラスター内、もしくはクラスター間での分散ファイルコピーのためのツールである。 このツールは、MapReduce により実装されており(したがって、操作を行う HDFS クラスタ上で動作する MapReduceクラスターが必要である)、したがって、ファイルのコピーを並列に行うため非常に効率がよい。 また、異なる Hadoop のバージョンが動作している HDFS クラスター間のデータコピーも可能である。 これは、hftp ファイルシステムを使用しているからであり、hftp は HTTP による HDFS へのアクセスを可能にしているためである。

distcp4 is a tool for performing a distributed copy of data within an HDFS cluster, or between HDFS clusters. It is implemented using MapReduce (so it needs a MapReduce cluster to be overlaid on the HDFS cluster), and therefore is very efficient since it can copy files in parallel. It is also possible to copy data between HDFS clusters running different versions of Hadoop, by using the hftp filesystem, which permits accessing HDFS over HTTP.

時間が経過すると、HDFS クラスター上のブロックの分散は偏ることある。 バランサー5 ツールは、バックグランド・プロセスとして動作し、クラスター上のブロックを平均からの偏差がある一定のしきい値(デフォルトは10%)以下となるまで再分散する。 このツールは、新しいデータノードをクラスターに追加した場合、特に有効である。 なぜなら、HDFS は新しいデータノードが追加されても自動的にブロックの再分散を行わないからである。

Over time the block distribution on an HDFS cluster can become unbalanced. The balancer5 tool can be run as a background process to re-distribute blocks across the cluster until the deviation from the average is below a certain threshold (default 10%). This tool is especially useful when adding new data nodes to a cluster, since HDFS does not automatically re-distribute blocks in this case.

スナップショット
Snapshots

HDFS でのスナップショットのサポートは、現在開発中である6。 スナップショットとはある時点でのファイルシステムの状態である。 HDFS の信頼性の観点からすれば、スナップショットによってクラスターのインクリメンタルなバックアップが可能となる。

Work is ongoing to support HDFS snapshots6. A snapshot is the state of the filesystem at a point in time. From the point of view of HDFS reliability, snapshots will enabled incremental backup of a cluster.

障害のタイプ
Types of failure

これより議論する障害のタイプについて、明確にする必要がある。 データの消失はつぎの理由により起こる:

  1. ハードウェア障害、もしくは誤動作。 1つ以上のハードウェア構成要素の障害がデータ消失を引き起こす。
  2. ソフトウェアエラー。 ソフトウェアのバグがデータ消失を引き起こす。
  3. ヒューマンエラー。 例えば、オペレーターが不注意により以下のタイピングを行いファイルシステム全体が消去:

    hadoop fs -rmr /
本論では、主にはじめの2つのタイプの障害を扱うが、3番目の障害についても本論の後半にて別途簡単にふれる。

We need to be precise about the types of failure that we are discussing. Data loss can occur for the following reasons:

  1. Hardware failure or malfunction. A failure of one or more hardware components causes data to be lost.
  2. Software error. A bug in the software causes data to be lost.
  3. Human error. For example, a human operator inadvertently deletes the whole filesystem by typing:

    hadoop fs -rmr /
This paper is mostly concerned with the first two types of failure, but we briefly consider the third separately, later on in the paper.

ハードウェア障害
Hardware failures

ハードウェア障害は多くの異なる状況で現れる。 ここでの解析に適切な障害発生は以下の2つである:

  1. いくつかのハードウェアコンポートが同時に障害に陥る。
  2. ディスク上のデータの崩壊
これらのタイプの障害は共に、レプリケーションを行うことにより、保護できる。 既に述べたラック配置ポリシーは、クラスター内、もしくは、ラック全体の R-1 である任意のデータノードの障害に耐える(ここに R はクラスターにおけるレプリケーション因子である)。 同様に、ローカルな障害によってあるレプリカが崩壊した場合、他のレプリカが代わりに使用される。

Hardware failure can manifest itself in many different ways. Two manifestations that are pertinent to this analysis are

  1. The simultaneous failure of multiple hardware components
  2. The corruption of data on disk
Both of these types of failure are guarded against using replication. The rack placement policy described above can tolerate the failure of R-1 arbitrary data nodes in the cluster (where R is the replication factor in the cluster), or even a whole rack. Similarly, if a replica is corrupt due to a local failure, then the other replicas can be used instead.

Hadoopはどのようにハードウェア障害を検出するか?
How does Hadoop detect hardware failures?

例として、データノードに障害が起きたケースを考える。 名前ノードは該当のデータノードがハートビートを送信してこないことを感知すると、一定の時間(デフォルトでは10分)が経過した後、そのノードを不通になったものとし、この時点で障害が起きたデータノード上に存在するブロックの再レプリケーションを、クラスター内にある他のノードのレプリカを使用して開始する。

For example, consider the case of a data node failing. The name node would notice that the data node is not sending heartbeats, then after a certain time period (10 minutes by default) it considers the node as dead, at which point it will re-replicate the blocks that were on the failed data node using replicas stored on other nodes of the cluster.

データ破損の検知には、異なるアプローチが必要となる。 主な手法は、破損を検知するためのチェックサムを利用することである。 データの破損は、ネットワーク上にてブロックを転送する際に生じるか、あるいは、ブロックのディスクへの書き込み、もしくは、読み込み時に生じる。 Hadoop では、データノードにてブロックのレシートに存在するチェックサムを照合する。 もしチェックサムの不整合が検出されたら、データノードは苦情を申し立て、ブロックは再送される。 ブロックのチェックサムはデータブロックと共に保存されており、更なる管理用のチェックを行うことができる。

Detecting corrupt data requires a different approach. The principal technique is to use checksums to check for corruption. Corruption may occur during transmission of the block over the network, or when it is written to or read from disk. In Hadoop, the data nodes verify checksums on receipt of the block. If any checksum is invalid the data node will complain and the block will be resent. A block's checksums are stored along with the block data, to allow further integrity checks.

これだけでは、破損していない状態にあるディスクからのデータ読み込みが成功したことを保証するには十分でない。 故障は名前ノードに報告され、問題のないレプリカが再レプリケーションされる。

This is not sufficient to ensure that the data will be successfully read from disk in an uncorrupted state, so all reads from HDFS verify the block checksums too. Failures are reported to the name node, which organizes re-replication of the healthy replicas.

多くの場合、HDFS は読み込みが頻繁に行われないデータを保存する目的で利用されるため、読み込みが行われたときにデータの破損を検知するのでは、望ましい状態とは言えない: 長い期間における故障が検知できなくなり、その間に他のレプリカも故障してしまうかもしれない。 この問題の改善策は、ブロックの完全性をチェックするバックグラウンドのスレッドを各データノードが実行することである。 破損したブロックを発見した場合、データノードは名前ノードに破損していないレプリカからのブロックのレプリケートを要請し、破損したブロックの削除を行う。 ブロックは3週毎に照合され、常にディスクのエラーから保護される。 新しいブロックがはじめてチェックされると、それらのチェックにおいて多少の遅延が生じる。 (ブロックスキャンの監視方法に関する詳細は以下の"モニタリングの使用"を参照。)

Because HDFS is often used to store data that isn't read very often, detecting corrupt data when it is read is undesirable: the failure may go undetected for a long period, during which other replicas may have failed. To remedy this, each data node runs a background thread to check block integrity. If it finds a corrupt block, it informs the name node which replicates the block from its uncorrupted replicas, and arranges for the corrupt block to be deleted. Blocks are re-verified every three weeks to protect against disk errors over time. New blocks are checked first, but there is still some lag in checking them. (See "Employ monitoring" below for details on how to monitor block scans.)

ソフトウェアエラー
Software errors

ソフトウェアにおけるバグは常にある程度存在するものであるが、これまでと同様に、レプリケーションされたデータをもつことにより、バグに従う問題の多くを防ぐことができる。 もちろん、全てのレプリカに影響するソフトウェアのバグが存在する可能性もあるが、そのようなバグは非常に稀である。

Bugs in the software will always be present to some degree, but, again, having replicated data guards against a large class of these problems. Of course, it is possible to have software bugs that affect all replicas, but these are very rare.

このようなシナリオに対抗する強力な防御は、以下に挙げるような良いソフトウェア開発の習慣を維持することである。

  • ユニットテスト
  • コードレビュー (人間によるものと FindBugs のようなツールによるもの)
  • スケール毎のシステムテスト
Hadoop ではこれら全ての習慣を採用している。 しかし、常に改善すべき余地は残されており、Hadoop が成熟し、より多くの組織で採用されるにつれ、 上記の領域の全てにおいて新たな改善が行われるであろう。

The strongest defence against this scenario is maintaining good software development practices, including

  • Unit testing
  • Code review (human and with tools such as FindBugs)
  • System testing at scale
Hadoop employs all these practices. However, there is always room for improvement, and as Hadoop matures and is adopted by more organizations, there will be a push to improve in all of these areas.

ブロック切り詰めエラー
Block truncation errors

ある最近のソフトウェアエラーのケースは、不注意なブロックの切り詰めに関するエラーである7。 HDFS のあるバグによってときどき部分的に書き込まれるブロックが発生し、その為ブロックの長さが期待される長さより短くなってしまっていた。 問題を複雑にしてしまったことに、データノードは名前ノードにブロック全体の長さは正しく書き込まれたとレポートしていたのである。 さらに、ブロックスキャンは、ブロックのメタデータが切り詰められたブロックと一致している為、その切り詰めを検出することができなかった。 このブロックの"静かな破損"のケースは、(同じバグに遭遇したか、あるいは他の理由により)ブロックのレプリカが失われ、最終的にデータ損失を起こした。 この事例はネブラスカ大学の HDFS クラスターで起こり、200から300のファイルが喪失した8。 また、Yahoo!においても同様の事例が起こったが、この問題がどれほど波及したのかはわかっていない。

A recent case of software errors concerns inadvertent block truncation7. A bug in HDFS was occasionally causing blocks to be partially written, so their length was less than expected. To compound the problem the data node would report to the name node that the full length of the block was written correctly. Furthermore, the block scan would not detect the truncation since the block metadata was consistent with the truncated block. This case of "silent corruption" of a block ultimately led to data loss when replicas of the block were lost (either because the same bug hit, or for other reasons). This scenario has occurred an HDFS cluster at the University of Nebraska, where 200-300 files were lost8. The problem was also experienced at Yahoo!, however it is not known how widespread this problem was.

この論文執筆時点においてこのバグは修正中であるが、この事例が示していることは、 システムの異なる階層における安全対策が問題を検出するのに十分ないと、時期を逸してしまい、データが喪失してしまうということである。 このようなバグが見つかった場合、バグそのものを修正することはもちろん必要であるが、 より重要なことは、このような故障を引き起こすいくつか条件からシステムを防御できるように、システム内のチェックを改善することが必要である。

At the time of writing, this bug is still being fixed, but it illustrates how in this case safeguards at a different layer of the system were not sufficient to even detect the problem until it was too late and data was lost. When bugs like this are found the bug itself needs fixing of course, but perhaps even more importantly the checks in the system need to be improved to guard against the class of condition that caused the failure.

ベストプラクティス
Best Practices

標準的な設定の使用
Use a common configuration

Haddop は柔軟に設定を変更できるシステムであり、その為、設定可能な範囲が非常に広範囲となる。 異例な設定を用いてクラスターを稼動させることはバグを発見する良い方法であるが、信頼性を最大化するためには、既に誰かがテストした設定を用いる方がよく、また、同じようなスケールで稼動させている設定がより好ましい。

Hadoop is a highly configurable system, which makes the configuration space large. Operating a cluster using an unusual configuration is a good way to find bugs, so to maximize reliability, you should use a configuration that has been tested by others, preferably at the scale you operate at.

例えば、Yahoo! と Facebook は、十分に大規模な Hadoop を稼動させている組織であり、標準的なハードウェアの障害に対する経験を積んでいる。 HDFSの開発において、大規模に稼動させる際に9現れる多くのバグが発見された。(また、それらのバグはすぐに修正さた。) よって、設定を模倣することは良い設定の候補となります。

For example, Yahoo! and Facebook are two organizations that operate Hadoop at sufficiently large scale to experience regular hardware failures. During the course of development of HDFS, there have been many bugs that were detected (and subsequently fixed) due to operating at scale9, so these are good candidates to mimic in terms of configuration.

通常、このような慣習は可能ならばデフォルトの設定を使用することを意味しているが、一般的にデフォルトから変更する設定も存在する(例えば、Yahoo! では HDFS のブロックサイズを128Mにしている10)。

In general, this practice means using the default settings where possible, although there are some settings which are commonly changed from the default (for example HDFS block size is set to 128MB by Yahoo!10).

3個以上のレプリカを使用
Use three or more replicas

理論的には、レプリケーションレベルが2であれば、一つのノードの障害、もしくは、ラック全体におよぶ障害(異なるラックに全てのブロックの第二レプリカが存在する為)からも復旧には十分である。 実践的な問題として、バックアップ用のレプリカは破損するかもしれないし、ソフトウェアエラーが抜けが生じるかもしれない。

In theory a replication level of two is sufficient to recover from the failure of a single node, or even a whole rack (since the second replica of every block in on a different rack). The problem in practice is that the backup replica may be corrupt, or absent due to a software error.

ネブラスカ大学におけるファイル損失を拡大させてしまった原因は、一般的ではない設定(レプリカ因子が2であった)によって大規模なクラスターを稼動させていた為であり、それによってバグの影響をより受けやすくなっていた。 問題の核心は、破損したブロックが定期的なチェックにより検知されない場合、 もしくは、ソフトウェアのバグが不正なブロックを作成してしまった場合、 システムが、実際に存在するブロック以上に、正しいブロックが存在していると考えることができなかったことにあります。 たった1つのバックアップレプリカでは(これはレプリケーション因子が2の場合)、 バックアップが失敗するのはシステムがバックアップレプリカが存在しないと検知した場合のみであり、 そのときではデータを復旧するには遅すぎるのです。

To some extent the file loss at the University of Nebraska was due to operating a large cluster with a non-standard configuration (two replicas), which made it more susceptible to bugs. The crux of the problem is that if corrupt blocks are not detected in a timely manner, or if a software bug masks invalid blocks, then the system thinks there are more valid blocks than there actually are. With only one backup replica (replication factor of two), it is only when the backup fails that the system detects that there are no block replicas, at which point it is too late to recover data.

3つのレプリカが存在すれば、システムには、第2のレプリカが破損した後、第3のレプリカを使用して再レプリケーションを行うことにより、その静かな破損を検知するチャンスがありました。

With three replicas the system has a chance to detect the silent corruption after the second replica fails, and to re-replicate using the third replica.

レプリカの個数は、ファイル作成時とファイルを閉じた際の両方の時点で、ファイル毎に設定することが可能である。 重要なファイルや広範囲に使用されるファイルに対しては、レプリケーションを3以上にすべきである。

The number of replicas can be set of a per file basis, either at the time of creation or after closing the file. For important or widely used files the replication should be increased above three.

名前ノードの保護
Protect the name node

名前ノードはひとつの障害のポイントである: 名前ノードに障害が起きると、HDFS クラスター全体は利用不能となる。 また、名前ノードが復旧できない場合、クラスター内の全てのデータが復旧できないことになる。 この崩壊シナリオを避けるために、名前ノードを特別な扱いにする必要がある:

  1. 名前ノードは永続的なメタデータを多重にローカルディスクへ書き込むべきである。 もしひとつの物理的なディスクに障害が起きても、他のディスクのバックアップが存在する。 このケースではRAIDも利用できる。
  2. 名前ノードは永続的なメタデータをリモートのNFSマウントされた領域に書き込むべきである。 名前ノードに障害が起きても、NFS上にバックアップが存在する。
  3. セカンダリー名前ノードは、プライマリー名前ノードとは異なるノードで実行されるべきである。 プライマリー名前ノードの(ローカルディスクとNFS上に存在する)データが失われた場合、 セカンダリー名前ノードは、少々古いものとなるメタデータとコピーを提供できる。 メタデータは少々古いものであるから、いくらかのデータ損失が生じるかもしれない。 しかし、セカンダリー名前ノードで行われるメタデータの周期的なバックアップは、設定されたスケジュールにもとづいている為、そのデータ損失の量は既知のものとなる。
  4. 名前ノードの永続的なメタデータのバックアップをとる。 異なる期間(1日、1週間、1ヶ月)毎に複数のコピーを行えば、それぞれの期間に対応して破損からのリカバリーを行うことが可能になる。 このようなバックアップを行う便利な方法は、セカンダリー名前ノードにおけるチェックポイントを、バックアップのソースとして使用することである。 これらのバックアップの整合性をチェックする; 現在、整合性をチェックする唯一の方法は、新しい名前ノードを(稼動中のクラスターには到達できないネットワーク上で、別個に)走らせることである。 これにより、ファイルシステムのメタデータが再構築可能であることを視覚的にチェックできる。
  5. ディレクトリの使用制限を用いて、ファイルシステムの名前空間に存在できるファイルの最大個数を指定する。 この評価基準は、システム内にあまりに多くのファイルが作成されたため、メモリー容量を越えて名前ノードが実行を続けるような不安定な効果を防ぐことができる。

The name node is a single point of failure: if it fails, then the whole HDFS cluster is unusable. If it is unrecoverable, then all of the data in the cluster is unrecoverable. To avoid this catastrophic scenario the name node should have special treatment:

  1. The name node should write its persistent metadata to multiple local disks. If one physical disk fails then there is a backup of the data on another disk. RAID can be used in this case too.
  2. The name node should write its persistent metadata to a remote NFS mount. If the name node fails, then there is a backup of the data on NFS.
  3. The secondary name node should run on a separate node to the primary. In the case of losing all of the primary's data (local disks and NFS), the secondary can provide a stale copy of the metadata. Since it is stale, there will be some data loss, but it will be a known amount of data loss, since the secondary makes periodic backups of the metadata on a configurable schedule
  4. Make backups of the name node's persistent metadata. You should keep multiple copies of different ages (1 day, 1 week, 1 month) to allow recovery in the case of corruption. A convenient way to do this is to use the checkpoints on the secondary as the source of the backup. These backups should be verified; at present the only way to do this is to start a new name node (on a separate, unreachable network to the production cluster) to visually check that it can reconstruct the filesystem metadata.
  5. Use directory quotas to set a maximum number of files that may live in the filesystem namespace. This measure prevents the destablizing effect of the name node running out of memory due to too many files being created in the system.

これまでに、名前ノードでの永続的なデータ保存に関して、復旧不能なデータ損失となるソフトウェアエラーは報告されていない。

There have been no reported software errors in the name node's persistent data storage that have caused unrecoverable data loss.

モニタリングの利用
Employ monitoring

可能なかぎり、Hadoop は障害を検知し、その障害を取り除こうとします。 しかし、それはクラスターの状態をオペレータに通知するモニタリングシステムの代替ではなく、 必要なときに早期の対応を行うことを可能にするものである。 Hadoop は JMX を通してモニタリング用のフック(訳注:モニタリングに必要な情報)を抜き取られており、それによりクラスターは Nagios や Gnglia といったツールを用いてモニタリング可能である。

Where possible, Hadoop strives to detect failure and work around it. However, this is no substitute for a monitoring system that informs operators of the health of the cluster, so they can take early action when needed. Hadoop exposes monitoring hooks via JMX, which allows the cluster to be monitored using tools like Nagios, or Ganglia.

クラスターオペレーションチームが請け負うべき慣例的な管理作業も存在し、それには以下が含まれる:

  • HDFS の fsck (ファイルシステムチェック)ツールを毎日実行し、ファイルとブロックの状態に関するレポートを受け取る。
  • データノードブロックのスキャンレポートを以下で見る: http://datanode:50075/blockScannerReport11 

There are also routine administration activities that the cluster operations team should undertake, including:

  • Running HDFS's fsck (filesystem check) tool daily to get reports of file and block health
  • Viewing data node block scanner reports at http://datanode:50075/blockScannerReport11 

バックアップの定義とアップグレード作業
Define backup and upgrade procedures

パフォーマンスの向上やバグ修正のために、折にふれ HDFS がファイルシステムメタデータ、はデータ、もしくはその両方のディスク上のレイアウトを変更する必要がある。 このような場合において、Hadoop のアップグレード行う際には、ソフトウェアエラーによるデータ損失が起きる潜在な可能性がある為、特別な注意が必要となる。 推奨されているいくつかの予防措置は以下となる:

  • 小さなクラスターにおいて試行する。
  • クラスターにて行うアップグレード手順を文書化する。 アップグレート入門が Hadoop Wiki12 にあるが、 個別の設定に対する独自の手順がある場合、試行を行うことにより得た知識と合わせて、 ドキュメントを残すことは、将来再び同じ作業をする際にも必要となり、価値のあることである。
  • 常に、名前ノードのメタデータのバックアップを、複数別の場所に残す。
  • ディスク上のデータ(データノード上に蓄積されたデータ)のレイアウトが変更される場合、クラスターのバックアップを行うこと、もしくは、少なくとも最も重要なファイルのバックアップを行うことを考えるべきである。 全てのデータレイアウトの更新は、以前のフォーマットバージョンへロールバックする柔軟性をもっているが(これは古いレイアウトのデータのコピーをもつことにより実現されている)、可能ならば常にバックアップをすることが望まれる。 hftp 上の distcp ツールを用いて、第二の HDFS クラスタへバックアップをとることは、 バックアップを作成する良い方法の1つである。

To make performance enhancements or bug fixes it is occasionally necessary for HDFS to change its on-disk layout for filesystem metadata and/or data. In these cases, extra care is needed when performing an upgrade of Hadoop, since there is potential for data loss due to software errors. There are several precautions that are recommended:

  • Do a dry run on a small cluster.
  • Document the upgrade procedure for your cluster. There are upgrade instructions on the Hadoop Wiki12, but having a custom set of instructions for your particular set up, incorporating lessons learned from a dry run, is invaluable when it needs to be repeated in the future.
  • Always make multiple off-site backups of the name node's metadata.
  • If the on-disk data layout has changed (stored on the data node), consider making a backup of the cluster, or at least of the most important files on the cluster. While all data layout upgrades have a facility to rollback to a previous format version (by keeping a copy of the data in the old layout), making backups is always recommended if possible. Using the distcp tool over hftp to backup data to a second HDFS cluster is a good way to make backups.

ヒューマンエラー
Human error

ヒューマンファクターに従うデータ喪失のリスクを完全に取り除くことは不可能であるが (データを削除可能とする要求は、常に存在する。)、 幾つもの保護と、データ損失を最小にしようとする実行可能な操作が存在する。

While it is impossible to completely remove the risk of data loss due to human factors (since there will always be a requirement to be able to delete data - for whatever reason, legal etc.), there are a number of safeguards and working practices that can help minimize data loss.

ゴミ箱の柔軟性
Trash facility

ゴミ箱が利用可能な場合(そして、注意しておくべきことだが、デフォルトでは利用不可である)、 Hadoop ファイルシステムシェルを利用して削除されたファイルは、即座に削除される代わりに、隠された特別なゴミ箱ディレクトリに移動される。 ゴミ箱ディレクトリは周期的にシステムによって削除される。 間違って削除された任意のファイルは、ゴミ箱ディレクトリから移動することに、手動で復旧することができる。 ゴミ箱の削除周期は設定可能であり、賢明なデフォルトである24時間を推奨する。

If trash is enabled (and, it should be noted, by default it is not), files that are deleted using the Hadoop filesystem shell are moved into a special hidden trash directory, rather than being deleted immediately. The trash directory is deleted periodically by the system. Any files that are mistakenly deleted can be recovered manually by moving them out of the trash directory. The trash deletion period is configurable, we recommend 24 hours as a sensible default.

ゴミ箱削除はユーザーレベルの機能であり、プログラムから削除を行う為にこの機能を使うことはできない。 ベストプラクティスとしては、即座に削除が行われるのではなく、削除されたデータをゴミ箱ディレクトリに移動する(そして、ある程度の時間が経過した後、システムによって削除される)と考えることである。

The trash facility is a user level feature, it is not used when programmatically deleting files. As a best practice we recommend considering moving data to be deleted to the trash directory (to be deleted by the system after the given time), rather than doing an immediate delete.

パーミッション
Permissions

HDFS は、UNIX のユーザー/グループモデルをもとにしたパーミッションシステムをもっているが、 現在この機能は(NFS version 3のように)有効にはなっていない。 この機能は、共有クラスターにおいてデータ損失を防ぐように設計されている。(例えば、データプライバシーを提供するためではない。)

HDFS has a permissions system, based on the unix user/group model, that it is currently un-authenticated (like NFS version 3). It is designed to prevent data loss on a shared cluster (as opposed to providing data privacy, for example).

ベストプラクティスとして、データパイプラインにおける異なるプロセスを、 ファイルとディレクトリにおけるパーミッションコントロールを用いて、分離することができる。 例として、クラスターへローデータをフィードするプロセスは、他のユーザーに対してファイルをリードオンリーにすることができる。 ローデータを解析し変換する必要のあるプロセスは、データ削除の許可を必要とはしない。 さらに、複数のダウンストリームプロセスも考えられる: 各機能にもとづいた異なるユーザー名を設定することにより、それらプロセスが利用し作成するデータに対する許可を、注意深く制御することができる。

As a best practice, it is recommended that different processes in the data pipeline are segregated using the permissions controls on files and directories. For example, the process that feeds raw data into the cluster would make the files read only for other users. Processes that need to analyze and transform the raw data would not have permission to delete the data. Furthermore, there may be multiple downstream processes: these should have different user names depending on their role, so that the permissions on the data they consume and produce is carefully controlled.

HDFSの信頼性に関するベストプラクティスのまとめ
Summary of HDFS Reliability Best Practices

  1. 標準的な HDFS の設定の使用。
  2. レプリケーションレベル 3 (最小値として)の使用、もしくは、より重要な(もしくは広範囲に使用される)データに対してレプリケーションレベルを 3 以上にすること。
  3. 名前ノードの書き込みを複数のローカルディスクとNFS上とにする設定。 セカンダリー名前ノードの異なるノードでの実行。 名前ノードの永続的な状態の周期的な複数のバックアップの実行。
  4. HDFS クラスターの能動的な監視。
  5. バックアップとアップデート手続きの定義。
  6. HDFSのゴミ箱を有効にし、プログラムによる削除を避け、ゴミ箱削除を行うようにする。
  7. ワークフローに合わせて、ユーザー集合を作成し、各ユーザーに対する許可を設定する。

  1. Use a common HDFS configuration.
  2. Use replication level of 3 (as a minimum), or more for critical (or widely-used) data.
  3. Configure the name node to write to multiple local disks and NFS. Run the secondary on a separate node. Make multiple, periodic backups of name node persistent state.
  4. Actively monitor your HDFS cluster.
  5. Define backup and upgrade procedures.
  6. Enable HDFS trash, and avoid programmatic deletes - prefer the trash facility.
  7. Devise a set of users and permissions for your workflow.

本論文の草稿を読んでくださった Brian Bockelman、 Dhruba Borthakur、Jeff Hammerbacher、Aaron Kimball、Mike Olson、Matei Zaharia、そして Philip Zeyliger に感謝致します。

Thanks to Brian Bockelman, Dhruba Borthakur, Jeff Hammerbacher, Aaron Kimball, Mike Olson, Matei Zaharia, and Philip Zeyliger for reading drafts of this paper.


  1. 現在、この配置ポリシーは固定であるが、配置ポリシーをプラグイン可能とする提案が行われている。 https://issues.apache.org/jira/browse/HADOOP-3799を参照。
    Currently the policy is fixed, however there is a proposal to make it pluggable. See https://issues.apache.org/jira/browse/HADOOP-3799
  2. 編集ログへの書き込みは、アプリケーションへ成功コードが返却される以前に、ディスク上に反映され、同期される。 現在、作業中。
    Edit log writes are flushed and synced to disk before a successful return code is returned to the application. Work is ongoing
  3. "待機中の名前ノードに対するストリーミング編集", https://issues.apache.org/jira/browse/HADOOP-4539
    "Streaming Edits to a Standby Name-Node", https://issues.apache.org/jira/browse/HADOOP-4539
  4. http://hadoop.apache.org/core/docs/current/distcp.html
  5. http://hadoop.apache.org/core/docs/current/hdfs_user_guide.html#Rebalancer
  6. https://issues.apache.org/jira/browse/HADOOP-3637
  7. https://issues.apache.org/jira/browse/HADOOP-4692
  8. Hadoop ユーザメーリングリストの投稿を参照: http://www.mail-archive.com/core-user@hadoop.apache.org/msg06462.html
    See Hadoop User mailing list posting: http://www.mail-archive.com/core-user@hadoop.apache.org/msg06462.html
  9. 例えば、http://issues.apache.org/jira/browse/HADOOP-572。 Nigel Daleyの"Nigelの法則"というスケールテストに関するブログ投稿も参照 (http://weblogs.java.net/blog/nidaley/archive/2007/07/nigels_law.html)。
    For example, http://issues.apache.org/jira/browse/HADOOP-572. See also Nigel Daley's blog post about testing at scale "Nigel's Law" (http://weblogs.java.net/blog/nidaley/archive/2007/07/nigels_law.html).
  10. 最近のケースでは、ブロックサイズは4Gとの報告があるが(これは推奨されるサイズの何倍もの大きさである)、この設定はファイルアクセスに関する問題点により設定された値である。 http://www.mail-archive.com/core-user@hadoop.apache.org/msg06689.html
    There was a recent case reported where setting the block size to 4GB (which is many times larger than the recommended size), caused file access issues. http://www.mail-archive.com/core-user@hadoop.apache.org/msg06689.html
  11. 手動でブロックスキャンを実行するには Jira の問題がある。 https://issues.apache.org/jira/browse/HADOOP-4865を参照。
    There is a Jira issue to allow the block scanner to be run manually. See https://issues.apache.org/jira/browse/HADOOP-4865
  12. http://wiki.apache.org/hadoop/Hadoop%20Upgrade
Comments