ラベル データ保護 の投稿を表示しています。 すべての投稿を表示
ラベル データ保護 の投稿を表示しています。 すべての投稿を表示


2011年8月28日日曜日

RHEL ストレージ関連のエントリーまとめ


このエントリーをはてなブックマークに追加


情報がバラバラなので整理

マルチパス系

仮想環境を使って簡単にRHEL6のiscsiマルチパスを検証する
RHEL6でiscsiマルチパスを検証するためのHow to。実際に動かしてみて動作イメージをつかむ。

RedHat における iSCSI 設定とマルチパス
上と内容がかぶってます。RHEL5の場合の設定の流れを記載してます。

マルチパスI/Oの設定(RedHat)
一般的なマルチパスストレージの話。


iSCSI系

RedHat Enterprise Linux iSCSIコマンドまとめ(iscsiadm)
iscsiadmコマンドのリファレンス

RedHat のiSCSI でLUNサイズを変更する手順(未確認)
ストレージ側でLUNのサイズ変更した場合のiscsiクライアントの話。環境が無いのでマニュアルからの推定操作を記載。

iSCSIストレージ構築のポイント
iscsiストレージを使う場合のネットワーク構成の話。


DeviceMapper系

RHEL Device Mapper と LVM
DeviceMapperって何?という話。

RHEL LVM2でシンプロビジョニング
LVM2を使ったなんちゃってシンプロビジョニング。


Global File System系

RHEL6.1 を使い倒す Resilient Storage(GFS2)
GFS2(Global File System)の使い方。

RHEL6.1 を使い倒す Resilient Storage(Clustered Samba)
GFSを使った並列アクセス可能なsamba環境の構築。


2011年5月14日土曜日

Ultra24/27が最強ZFSストレージサーバになる奇跡のパーツを発見!


このエントリーをはてなブックマークに追加


Sun Ultra24/27は外見、スペック共に最高グレードだと勝手に思い込んでるんだけど、唯一の欠点が内蔵HDDを4台しか搭載できないこと。
http://www.sun.com/desktop/workstation/ultra24/

今回はその欠点を覆す救世主を発見したのでご紹介。



2010年10月11日月曜日

ZFS スナップショットレプリケーション


このエントリーをはてなブックマークに追加



ZFS send/recv を使った、サーバ間でのレプリケーションを試してみる。

Table of Contents
=================
1 ZFS スナップショットレプリケーション
    1.1 準備するもの
    1.2 今回テストした環境
    1.3 基本的な転送方法
        1.3.1 送信元でスナップショットを取得する
        1.3.2 フル転送する
            1.3.2.1 zfs recv のオプション
            1.3.2.2 転送時の注意
            1.3.2.3 SSHの利用
        1.3.3 転送先での状態1
        1.3.4 差分転送する
            1.3.4.1 zfs send のオプション
            1.3.4.2 zfs recv のオプション
            1.3.4.3 差分転送前の注意
            1.3.4.4 疑問
        1.3.5 転送先での状態2
    1.4 ちょっと高度に使ってみる
        1.4.1 差分圧縮転送
            1.4.1.1 スナップショットの作成
            1.4.1.2 対象のファイルシステムをアンマウント
            1.4.1.3 増分を圧縮転送する
            1.4.1.4 ファイルシステムをマウントする
        1.4.2 フル圧縮転送
    1.5 転送時間



2010年8月8日日曜日

スナップショットからリストアする時はディスク負荷に注意


このエントリーをはてなブックマークに追加


 NASとかによくあるスナップショット機能。ちっちゃいファイルを戻すには便利だけど、巨大なファイルや大量のファイルをリストアする場合は注意が必要。

 書き込み負荷 = 1
 読み込み負荷 = 1
 スナップショット維持コスト = 1

の場合、普通に使うだけなら常に負荷1~2なのであんまり問題ない。

 しかし、スナップショット領域から、元の領域へ巨大なファイルを戻そうとすると。

 スナップショットを読み込む・・・1
 それを元の領域に書き込む・・・1
 書き込みによって生じるスナップショット維持コスト・・・1

となり、合計負荷が3になる。小さいファイルなら問題ないあが、巨大なファイルでは顕著にリストア時間に差が出てくる。100MB/sでReadできるNASでも、この方法だと、単純計算でも33MB/sまで落ちることになるが、実際はもっと落ちる。この3つのアクションは完全に単一ボリュームへのランダムアクセスになるので転送速度は1/5~1/20まで落ちると考えた方が良い。VMwareやKVM等の巨大な領域をリストアする場合はリストアスケジュールを事前に考えておこう。

 こういう状態を回避するために、NAS製品では良くスナップショットを実ボリュームと入れ替えてしまうオプションがある場合もある。もし使えるなら有効活用しよう。

結論を言うと、ZFSのスナップショット最強ってことで。



2010年5月23日日曜日

100年間デジタルデータを保持するためのガイドライン


このエントリーをはてなブックマークに追加


ストレージネットワーキング・インダストリ・アソシエーション(Storage Networking Industry Association 略称=SNIA ) が公開しているデータ長期保存のためのガイドライン。
http://www.snia-j.org/tech/save/hb.html

情報を記録する媒体は遥か古代から進化し、記録密度は飛躍的な発展を遂げてきた。

石版 →羊皮紙→紙→アナログ磁気メディア→デジタル磁気メディア

しかし記録密度が上がるにつれ、記憶可能な時間は短くなっている。特に現代のデジタル磁気メディアは複数の要因により長期保存にはあまり向いていない。
「データを保存する」とは、SNIAの定義から引用すると、

1.物理的にアクセス可能
2.論理的に利用可能
3.利用したデータに破損がない

この3つの条件を満たした状態を「データを保存する」と定義している。

数年単位で考えるならば、それほど難しいハードルではないが、50年、100年という単位で考えると実に難しい。

紹介したドキュメントにはデータの長期保存について、考慮すべき要因が網羅的に記載されているので、興味があればご一読を。


2010年5月15日土曜日

ディスクの振動とパフォーマンス


このエントリーをはてなブックマークに追加


ディスクの振動は昔から故障に大きく影響していると言われてきたが、最近ではパフォーマンスに与える影響も大きいというデータが出始めている。

その影響力は絶大で、実験結果を見ると、意図的に微細な振動を稼働中のHDDに与える事でパフォーマンスは20〜90%も低下すると言う。

当然の事ながら振動を受けるHDDの故障率があがり機器のパフォーマンスだけでなく、システムや業務のパフォーマンスが低下してしまう。

(1)Unusual disk latency
http://blogs.sun.com/brendan/entry/unusual_disk_latency
Sun の ブログ。ストレージに対して振動(大きな音)を与えることで、
ストレージのパフォーマンスが低下する様子を動画で公開している。


(2)クラスタノードの高密度実装における振動等の問題について
http://datafarm.apgrid.org/pdf/SWoPP2003-shimizu.pdf
産業技術総合研究所における、大規模グリッド環境において発生した、
振動によるパフォーマンス低下についての論文。
実験の背景や、特定周波数におけるパフォーマンス低下について実験に基づく
数値を根拠に考察している。分かりやすい。

(3)ディスクの振動を抑える事でパフォーマンスは向上する
http://slashdot.jp/hardware/article.pl?sid=10/05/12/0455237


機器の振動発生源は主にファンやハードディスク等の物理的に駆動するものだ。
最近ではデータセンタに機器が集約され高密度にラッキングされることで、一つ一つは無視できる範囲の振動でも、共鳴して大きな振動を生み出してしまう可能性もある。

もし管理している機器が性能を発揮出来ない場合や故障率が高い場合は 振動 という観点も考慮に入れる必要がありそうだ。
(もちろん、温度やアプリの作り、物理設計といったその他の要因も忘れてはいけない)

- Posted using BlogPress from my iPhone


2010年3月2日火曜日

このブログの趣旨


このエントリーをはてなブックマークに追加


データを保護するためにどのような方針を練るか。

HDDの物理的な破損に対してはRAIDを。
ユーザ操作ミスによるファイル削除にはスナップショットを。
論理的、または人為的な大規模なファイル破損にはテープでのバックアップを。

とさまざまな対策をデータの重要度や予算に応じて皆様も考えていると思います。


ここで下記のブログを参照させていただき、今までは考えなかった現象に初めて気がつかされました。

あなたのデータは既に壊れているかもしれない(Silent Data Corruption)
http://raven.air-nifty.com/night/2009/07/silent-data-cor.html


ハードディスクに書き込まれたデータが人知れず壊れている可能性があるという内容の記事です。実に怖い。
ただ思い返してみると、久々に読もうと思ったファイルが開けない、という事が何回かあった気がします。
全てがこの現象によって引き起こされているとは思わないですが、もしかすると該当するものもあったかも知れません。

実家で父が大量にため込んだFDD(5インチ)をようやく処分しようとして、
事前にデータをHDDに移そうと、どこで買ってきたのか、
USB-シリアルの変換ケーブルを使って、5インチFDをつなげてデータをサルベージしていた事がありました。

使わなくなって15年?ほど経過し、その間押入れの奥にしまわれていた
約300枚のFDを1週間ほどかけて順に読み取っていましたが実に半分のFDDが壊れていたとのこと。
(逆に半分も読めたことが脅威なのでしょうか?)

今とは精度が比べ物にならないにせよ、磁気データのもろさを実感させられます。


前置きが長くなりましたが、Silent Data Corruption とは、
保存したはずの磁気データがいつの間にか消えてしまうことを指します。
全部が突然消失するわけではなく、

00001000000000011111111101010001001001010

といったデータの1つまたは複数のビットがOSの指示なく突然反転してしてしまう現象を指します。
当然、ファイルフォーマットとの一部が破損することで、アプリケーションからはファイルが開けなくなり、「ファイルが壊れた」状態になってしまいます。

*ビット列の壊れ方にも何パターンかあるようです。
*詳細については上記紹介ブログでリンクされているpdfドキュメントをご参照ください。
http://fuji.web.cern.ch/fuji/talk/2007/kelemen-2007-C5-Silent_Corruptions.pdf


上記リンク先では保存したデータが「人知れず、前触れもなく」破損するという事実を実験的に証明しています。


恐らくこの現象は磁気ディスク装置が世の中に出回ったことから在る現象なのでしょうが、それほど大きな問題にはなっていませんでした。
そもそも壊れたのが、ディスクビット列の反転なのか、保存する際の予期せぬ動作によるものなのか、ファイルシステムのバグなのか、それともディスク装置の不良なのかを後から判別することがきわめて困難だからです。
また磁気ディスク装置というものがそれほど信用されていなかったという背景もあるかもしれません。

しかし最近はありとあらゆるデータが電子化され、磁気ディスクへ保存されるようになり、取り扱われるデータの量は1企業内でも簡単に100TBを超え、入出力の過程で一時的に書き込まれるファイルの量を加味すればPBオーダーでのデータが日々磁気ディスクに書き込まれていることになります。

このブログではこれらのコンピュータを使って生み出されたデータを如何に安全に保存していくか、という内容を中心にソフトやハードについて紹介していく予定です。