「Lustre」を含む日記

■ミラーリングはバックアップではない

京都大学でも意外とITの深いところまでは掘り下げないのね

スーパーコンピュータシステムのファイル消失のお詫び

2021年12月28日（火曜日）掲載

京都大学学術情報メディアセンター

センター長 岡部 寿男

2021年12月14日 17時32分 から 2021年12月16日 12時43分にかけて,スーパーコンピュータシステムのストレージをバックアップするプログラム(日本ヒューレット・パッカード合同会社製)の不具合により,スーパーコンピュータシステムの大容量ストレージ(/LARGE0) の一部データを意図せず削除する事故が発生しました.

皆さまに大変なご迷惑をおかけすることになり,深くお詫び申し上げます.

今後,再びこのような事態の生じることのないよう再発防止に取り組む所存ですので,ご理解をいただきますよう,どうぞよろしくお願いいたします.

ファイル消失の影響範囲

・対象ファイルシステム:/LARGE0

・ファイル削除期間:2021年12月14日 17時32分 ～ 2021年12月16日 12時43分

・消失対象ファイル:2021年12月3日 17時32分以降,更新がなかったファイル

・消失ファイル容量:約 77TB

・消失ファイル数:約 3400万ファイル

・影響グループ数:14グループ (うち,4グループはバックアップによる復元不可)

障害情報:【スパコン】ストレージのデータ消失について

http://www.iimc.kyoto-u.ac.jp/ja/whatsnew/trouble/detail/211216056978.html

ファイル消失の原因

スーパーコンピュータシステムの納入会社である日本ヒューレット・パッカード合同会社によるバックアッププログラムの機能改修において,不用意なプログラムの修正とその適用手順に問題があったことで,本来は不要になった過去のバックアップログファイルを削除する処理が,/LARGE0 ディレクトリ配下のファイル群を削除してしまう処理として誤動作しました.

日本ヒューレット・パッカード合同会社から提出された報告書を掲載します.

Lustreファイルシステムのファイル消失について (日本ヒューレット・パッカード合同会社)

今後の取り組み

現在バックアップ処理を停止しておりますが,プログラムの問題を改善し,確実に再発しない対策をした上で1月末までにはバックアップを再開する予定です.

ファイル消失後にバックアップが実行されてしまった領域のファイルの復元ができない状況となったことから,将来的にはこれまでのミラーリングによるバックアップだけでなく,1世代分の増分バックアップを残す等の機能強化を検討いたします.機能面だけでなく,再発防止に向けた運用管理についても改善に取り組みます.

一方で,機器故障や災害等によるファイル消失の可能性も含めて完全な対策は困難であるため,利用者の皆様におかれましても,重要ファイルについては別システムへのバックアップをお願い致します.

Permalink | 記事への反応(0) | 08:41

ツイートシェア

■On File Systems

(http://www.kev009.com/wp/2008/11/on-file-systems/)

訳した。分からなかったところは英語のまま。ファイルシステムについて完全な素人なので変な所があるかも。

Introduction(前置き)

ファイルシステムはOSの重要な要素だが最近ではあまり関心を払われていない。ビットが入ってきてビットがでていく……デスクトップシステムにとっては、たいてい十分に働いてくれる……ただし、電源が落ちるまでは。しかし、そんな状況ですら近頃ではあまり困ったことにはならない。

Linuxのファイルシステムの分野には競合製品が多い。ext2が長い間標準とされてきたが、2001年辺りから他の選択肢も主流となった。あまり歴史に深入りせずに要約すると(順番は適当)、ext2が進化してext3となり、ジャーナリング機能が付いた。ReiserFSがリリースされた。SGIはXFSを移植した。IBMはJFSを移植した。

いくつかの理由があって(主に政治的な理由で)ext3がLinuxのデファクトのファイルシステムとなった。

Classic File Systems(古典的ファイルシステム)

私が古典的ファイルシステムと呼ぶとき、基本的にいつも同じ概念を指している。つまり古典的なUnixレイアウトのファイルシステムにジャーナリング機能を追加したものだ。ここに述べるのは、それら古典的ファイルシステムのハイライトである。

• ReiserFS (Reiser3) はLinuxのジャーナリングファイルシステムとしては最初期のものである。成長の痛みはあったが、Kernel 2.6からは良いファイルシステムとなった。小さなファイルを扱うときの性能には目を見張るものがあるが、スケーラビリティについてはLinuxエリートから疑問視されていた。(http://en.wikipedia.org/wiki/Reiserfs). そしてHans Reiserは(本質的には書き直しである)Reiser4を開発することになった。 SUSE LinuxはいまなおReiserFSの開発者を小数抱えているが、いずれ「既に死んだファイルシステム」であることが明らかとなるだろう。

• XFSは巨大なファイルやファイルシステムへの素晴らしいサポートを持ち、拡張、遅延アロケーション、オンラインデフラグメンテーションなどの近代的な機能を備えていたため一部の人に歓迎された。(http://en.wikipedia.org/wiki/Xfs)しかしながらXFSにも欠点が無いわけではない。私の意見ではXFSの移植は中途半端であり、IRIXを起源としている事に起因する原因により(性能は他のファイルシステムと引けを取らぬものの)CPU使用率は比較的高い。(http://www.debian-administration.org/articles/388) 停電やクラッシュの後は、データが良く悲惨な事になる。それは設計上の決定ですらある。このLKMLへのポストは腹が立った。ハードウェア側では、いろいろな不具合が起き得る。 そしてファイルシステムがこれを感知しなければ、それは災害への序章となる。 そこでは(後に触れる)ZFSはチェックサムを持った英雄である。ただXFSは今なお開発中であり、将来への整ったロードマップ (http://www.xfs.org)があることは言及しておこう。

• IBMのJFSもUNIXからの移植である。JFSは1990年のIBM社AIXに起源し.IBMのチームがOS/2での利用のために移植と改良を行い、後にコードをフリー (FOSS)で公開した。結果として生まれたLinux版のJFSはスケーラブルで, 回復力を持ち、CPUへの負担が少ない (http://en.wikipedia.org/wiki/JFS_(file_system))事に定評がある. JFSは拡張もサポートしている。理由はともかくカーネルコミュニティとディストリビュージョンはJFSにやっきにならなかったので. JFSは基本的に穏かに保守が行なわれている。

• ext3はext2にジャーナリング機能を付けたものである。この世代のファイルシステムの中で最も技術的な先進性が無い。拡張のような機能も持っていなかった。それは比較的単純なコードベースで、多くの支持を受けるためユーザーに簡単な移行の手段を提供しようとしたからだった。(http://en.wikipedia.org/wiki/Ext3) その結果、ext3は広く受け入れられたので、多くのユーザーとディストリビューションにとってext3が勝者となった。そして今、もっとも安定し、サポートされているLinuxのファイルシステムでもある。

これは後知恵だが、JFSやXFSが牽引力を持たずに、ext3が人々を古典的時代に停滞させたのは一種の悲劇だった。しかしながらext3は信頼性を証明し、きちんと動くように一貫として保守されてもいる。

NextGen File Systems(新世代ファイルシステム)

2005年にSunはZFSという爆弾をリリースした。ZFSは私が次世代ファイルシステムと呼ぶ時代への案内人である。

ハードディスクが大きくなるにつれて、バックアップの戦略、完全性(integrity)の検証、巨大なファイルのサポートは前より遥かに重要になってきている。

ここあげるファイルシステムは古典的なVFS lineを曖昧にしたりLVMとRAIDを強固な結合することによって管理を楽にする事を目的としている。

ダメなハードウェアで起きる静かな(観測されない)データの破損も心配の種である。これに対抗するために、次世代のファイルシステムはチェックサムを供えている。

いろんな意味でLinuxのコミュニティーは完全に油断しきっており、多くの開発者はZFSがリリースされるまで次世代ファイルシステムについて真剣に考えてこなかった。Reiser4はいくつかの新しいアイデアを持っていてキラーファイルシステムとなろうとしたが、Hans Reiserは、他のカーネル開発者との著しく酷い関係を楽しんでいたのだった。ただ幸運な事に、いまではいくつかの、より先進的なファイルシステムが登場しようとしている。

• Reiser4がLinuxの次世代ファイルシステムに向けて行われた最初の努力である。2004年に紹介されたそれは、いくつかの新たな技術を供えているように思われた。トランザクション、遅延アロケーション、そして興味深いのはプラグインアーキテクチャーで、暗号化や圧縮などの機能を付け加えられるようになっていた。開発者のHans Reiserは、ファイルシステムを直接、発展的なメタデータを使ってデータベースとして使用できるとすら宣伝していた。Hansは、自分のファイルシステムを擁護するときにしばしば他のカーネル開発者を怒らせてきた。コードスタイルや設計上の決定について質問されるとHansは保守的になるようであった。特にプラグインアーキテクチャーについてはそうだった。私が思うに、この問題の多くは誤解と短気にあるように思えたが、いまだにReiser4はLinuxnのカーネルツリーにはいっていない。Hans Reiserに2008年に殺人の有罪判決が出されたため、Reiser4の将来性は疑問視されるようになった。現時点においてReiser4が上流において採用されるような事があるとは思えない。しかし、そこで試されたいくつかのアイデアは、既に他の次世代ファイルシステムに統合されている。

• ext4の開発は64 bit ext3を巨大なファイルシステムをサポートさせる事が目的で開始された。後に、Lustre, IBM, Bullなどが関わるようになり様々な特徴が追加された。拡張,遅延アロケーション、オンラインデフラグメンテーション等である。(http://en.wikipedia.org/wiki/Ext4)ext4はext3と前方互換性があり、ext4特有の拡張を使わなければ後方互換性もある。 明かな利点は安定したext3の土台を元に改良しているので、簡単な移行の手段も提供できるということである。開発者も大勢参加している。しかし、ext4はまだ古典的なファイルシステムといえる。他の次世代ファイルシステムが供えてるようなレベルの特徴やスケーラビリティを供えているとは言えない。

• BtrfsがZFSへのLinux側からの返事なのは明らかだ. Oracleによって始められたこのプロジェクトは,今や全ての主要なLinux関連会社を背後につけている。TrafficはLKML(Linux Kernel Mailing List)で、Btrfsがext4の後継者となるべきだと提案している。Btrfsの主要なデザインの特徴はcopy-on-writeである。それはバックアップやリカバリーに便利な負担の小さなスナップショットを可能とする。Btrfsの目標はZFSを完璧に上回ることだ。しかしながら、多くの興味深い特徴はいまなお開発中である。(data/journal checksums, tight device-mapper integration, built in RAID, オンラインfsck, SSD最適化オプション、環境の整ったext3からのアップグレードですら)

• Btrfsを追いかける他の先進的なファイルシステムTux3が発表された。このプロジェクトの開発者はFUSEを使って素早くプロトタイプを作ってアイデアを検証した。まだKernel portへの最初の仕事がポストされたばかりである。 (http://lkml.org/lkml/2008/11/26/13). このプロジェクトは古典的なジャーナリングを排除して、そのかわりに、playing back the logs (or recovering) on every mount できるようにするのが目的だ。 また、負担の小さなスナップショットやバージョニングも特徴である。このプロジェクトの開発者は自らのアイデアを擁護するのが非常に得意だが、私の予想では、メインストリームの使用への準備が整うには3年は待たねばならないだろう。まだコーディングは始まったばかりだからだ。(http://tux3.org/).

Conclusion(結論)

kernel 2.6.28と一緒にext4がリリースされるが、BtrfsやTuxs3が安定するのを待った方がよい。Btrfsの開発陣は短距離走開発を行っているので、Linuxのカーネルの開発サイクルに次か、あるいはその次で取り込まれると思われる。

SSDが普及するのは明白だ。理論的に速度の面で磁気ストレージより圧倒的に早く、現実にも既に書き込み速度が追い付きはじめている。最新のIntelのランダムアクセスやIOPSは非常に印象的である。Btrfsは当初からSSDへの最適化を取りいれようとしている。しかし、これらの新しいデバイスは、更に速度の早い新しいファイルシステムを生むだろう。

私自身の考えでは、ウェアレベリングやFATエミュレーションがSSDの性能を押し止めているため、 新たなファイルシステムが登場すればパフォーマンスを改善できるだろう。

Permalink | 記事への反応(2) | 16:09

ツイートシェア