仙石浩明の日記: NFS と AUFS (Another Unionfs) を使って、ディスクレス (diskless) サーバ群からなる低コスト・高可用な大規模負荷分散システムを構築する
ディスクレス (diskless) サーバを多数運用しようとしたときネックとなるのが、 NAS (Network Attached Storage) サーバの性能。 多数のディスクレスサーバを賄え、かつ高信頼な NAS サーバとなると、 どうしても高価なものになりがちであり、 NAS サーバ本体の価格もさることながら、 ディスクが壊れたときの交換体制などの保守運用費用も高くつく。 それでも、多数のハードディスク内蔵サーバ (つまり一般的なサーバ) を 運用して各サーバのディスクを日々交換し続ける (運用台数が多くなると、 毎週のようにどこかのディスクが壊れると言っても過言ではない) よりは、 ディスクを一ヶ所の NAS にまとめたほうがまだ安い、 というわけで NAS/SAN へのシフトは今後も進むだろう。 そもそも CPU やメモリなどとハードディスクとでは、 故障率のケタが違うのだから
HRS's Web Page - The Design and Implementation of the Gracious Days
新しい秩序の確立は、他の何にも増して難しく、 成功する可能性が低く、危険な事業である。 改革者は旧秩序から利益を得ている 全ての者を敵にまわし、 新秩序から利益を受けるはずの者からは 及び腰の支持しか集められない。 --- Niccolo Machiavelli, The Prince この種の「保護」は初心者を保護するかも知れないが、 熟練ユーザを窮地に追い込むことになる。 というのは、何が親切であり、何が適切でないかかという オペレーティングシステムの考え方の裏をかくことばかりに かなりの労力を費やさなければならないからである。 --- A.S.Tannenbaum, Modern Operating Systems 不定期更新の日記です。ディスクスペースの関係上、 あまりに古くなったものは順次消していきます。 この日記の更新は、今野さんの *BSD Diary Links から取得す
Server File Cache → Storage
4. Server File Cache → Storage 図4. nfs request flow 本章では図4の赤い部分、 Server File Cache から Storage までの経路に焦点を当てる。 ここは最後のパス、 Storage と IO しなくてはいけない 場合に必ず通るパスである。 図上では Server File Cache, Local File System, Storage は 3つの異なるユニットであるかのように描画しているが、 実際にはこの3ユニットの性能と特性は互いに影響しあって 全体で1つの性能を引き出す。 このため、この3つのユニットはバラバラに評価するわけには行かない。 普通に言う場合は、 この3つのユニットの性能を逢わせて Local File System の性能 と呼ぶ。 広義の nfs では、 Storage の部分は他の物にもなりうる
Softupdate のひみつ
最近の Unix では、UFS (スーパープロックとデータブロックがあるいわゆる Unix のファイルシステム)に対して、sync、async、softupdate という書き込み方があります。特徴を表にすると以下のようになります。 速度 安全性 sync 遅い 安全 async 速い 危険 softupdate 速い 安全 まず速度。メモリへの書き込みは速いが、ディスクへの書き込みは遅いというのが大前提です。速度を向上するには、ディスクの内容をメモリにキャッシュし、メモリを書き換えることで、書き込みの速度を向上させます。これを定期的にディスクに書き出します(delayed write)。昔は、update デーモンくんが 30 秒に一回書き出していました。 次に安全性ですが、 ファイルシステムの構造を維持できること だとします。(ファイルの内容が壊れないことじゃないよ。) 具体的には、
Kernel 2.2.x におけるディスクの同期、非同期のパフォーマンス差
最近、本業のデータベースシステムのパフォーマンス劣化で悩む日々が続いております。いろいろ分析をしているのですが、何しろ Miracle Linux 1.0 を使っていて、Kernel が 2.2 系とちょっと古いのが痛い。情報が少ないんですよね・・・。 さて、パフォーマンスの問題は更新型データベースにありがちな、I/O 周りのパフォーマンス問題。 Linux の I/O 関係は Solaris に比べるといろいろと問題が発生しやすいのも事実で、例えば、とあるベンダーでは Ext3 を別名Exorcist3 （エクソシスト３）と皮肉ったりしています。実際、ウチの環境では Kernel 2.2 系のサーバで Ext3 を使ったパーティションは、良く問題を起こします。例えば、 ジャーナルファイル破損 mount を非同期モードの async にすると、メモリ上だけのデータが更新され物理ディスク上
FreeBSD UFS/ZFS Snapshot Management Environment
Problem The FreeBSD UFS (both UFS1 and UFS2) and ZFS filesystems provides the possibility to create snapshots of live filesystems. On UFS is already best known (and can be easily used) for allowing fsck(8) to run in the background (see rc.conf variable background_fsck) and to create consistent filesystem dumps (see dump(8) option -L). In ZFS snapshots even can be used with the zfs(8) send and rece
Background fsck - Wikipedia
Background fsckとは、Soft updatesで以前マウントしていて、意図しない停止をしたファイルシステムにmountされた状態のままfsckしてファイルシステムを修復することである。 概要[編集] ファイルシステムをアンマウント(unmount, 使用を止めてマウントしていない状態にすること)しないままシステムが停止してしまった場合、通常はファイルシステムの一貫性が壊れてしまい、ファイルシステムをfsckによって修復しなければ再びマウントして使用することはできなくなる。 しかし、Soft updatesを使うとシステムがいつ停止してもファイルシステムの一貫性は基本的に壊れない。 再起動後にfsckを実行しなくてもファイルシステムをそのままマウント(mount)して使用できる。 唯一起きる矛盾は、使用されていないはずの領域が使用されているとマークされて、その領域が無駄になるこ
分散ストレージについて再び(6) - pekeqのブログ
LustreでもAFSでもないと思って探した結果、見つけたのがGfarmだった。これはかなりすてきな分散ファイルシステムで、なぜこれがこんなに知られていないのかさっぱりわからない。どこかのメジャーな技術系ブロガーが記事一本書けばブレイクするんじゃないかと思う。ぼくのブログじゃ無理だ。 メタデータサーバとストレージノードが分かれたアーキテクチャ メタデータサーバはPostgreSQLで動く メタデータキャッシュサーバを立てることができ、メタデータサーバの負荷が高まらないようにできる（！） レプリケーション可能。しかもファイル単位で設定できる（！！！） 巨大なファイルを複数ノードに分散させることも可能 分散処理コマンドが豊富。gfgrepなんてもうシビれる 並列分散処理のための基盤としても使うことができる などなど、すてきな機能が盛りだくさん 詳しくはGfarm Workshopのページに資料
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OpenAFS