本日もTeraStationネタです。
現在、ファイルサーバの信頼性向上案件に携わっているのですが、
事の発端は、以下のような経緯でした。
誤ってファイルサーバ上のデータを、古いデータで上書きしてしまった
ため、ミラー側(このシステムは、rsyncで別サーバにミラーを行って
います)から復旧できないか、と相談を受けました。
連絡を頂いたタイミングでは、既にrsyncのコピーが走った後だった
ため、復旧は不可能である旨をお伝えしました。
そこから、一日単位でよいから、世代管理を出来ないかとご相談を頂き、
現在に至ります。
で、提案したのが、TeraStationを用いた世代管理(pdumpfsを利用)。
ファイルサーバが、CentOSだったため、mount.cifsコマンドでTeraStasionを
マウントし、pdumpfsでコピーするまではよかったのですが...
du -hs * で、日々のコピー要領を確認すると.....
Windowsでも、ハードリンクを扱えるようになっているはずですが、CIFS
では、?な使用量を報告され、一時パニック状態です。
CIFSって、ハードリンクの元(こういう表現が正しいのか疑問ですが)の
容量を参照してしまうようですね。
同領域をNFSマウントした場合は、想定どおりの結果を返してくれましたし、
TeraStationの設定画面で見える使用量は、NFSで確認した容量と
ほぼ一致していたため、CIFSのお馬鹿仕様と勝手に判断してしまいました。
このあたりに事情に詳しい方がいらっしゃいましたら、ご教示頂ければと、
切に願います。
て、なんて無責任で、他人だよりなブログエントリーですね ;-<
2012年2月8日水曜日
2012年1月15日日曜日
TeraStation はエンタープライズ用途に耐えるのか?
法人向け製品としてリリースされている、某社の「TeraStation」シリーズを、自宅に導入した。
某県庁からも、内部システムの代替機移行に際した、データ移行ワークディスクとして利用する
構想を聞かされているため、どの程度の柔軟性があるのかを確認してみた。
結論から言うと、そう言った用途に利用する場合、スクリプトなどの「作り込み」が必要となりそう。
先ず第一に、NFSの利用に制限があること。
LinuxにおけるNFSの実装上当然の使用なのですが、root 権限での書き込みが出来ない。
OSの環境を変更することが可能であれば、"no_root_squash"オプションを追加することで
回避可能なのですが...
ネット上には、TELNETデーモンを組み込んで、改変する手法が氾濫していますが、個人
利用ならともかく、保証が受けられなくなる改変を加えたものを利用するなど、信用問題と
なるのは必至。
では、CIFSではどうか。
NetBSD上で、"mount_smbfs"コマンドを利用し、共有領域をマウントした上で、pdumpfs
コマンドで、コピーを実施したところ...
No buffer space available
エラーが発生。
検証した環境の問題かもしれないが、もう少し検証が必要という結論に。
今のところ、エンタープライズ用途には、適さないというのが、私の判断。
どうしても、TeraStation にこだわるのであれば、せめて iSCSI 機能を搭載したシリーズを
選定するべきですね。
某県庁からも、内部システムの代替機移行に際した、データ移行ワークディスクとして利用する
構想を聞かされているため、どの程度の柔軟性があるのかを確認してみた。
結論から言うと、そう言った用途に利用する場合、スクリプトなどの「作り込み」が必要となりそう。
先ず第一に、NFSの利用に制限があること。
LinuxにおけるNFSの実装上当然の使用なのですが、root 権限での書き込みが出来ない。
OSの環境を変更することが可能であれば、"no_root_squash"オプションを追加することで
回避可能なのですが...
ネット上には、TELNETデーモンを組み込んで、改変する手法が氾濫していますが、個人
利用ならともかく、保証が受けられなくなる改変を加えたものを利用するなど、信用問題と
なるのは必至。
では、CIFSではどうか。
NetBSD上で、"mount_smbfs"コマンドを利用し、共有領域をマウントした上で、pdumpfs
コマンドで、コピーを実施したところ...
No buffer space available
エラーが発生。
検証した環境の問題かもしれないが、もう少し検証が必要という結論に。
今のところ、エンタープライズ用途には、適さないというのが、私の判断。
どうしても、TeraStation にこだわるのであれば、せめて iSCSI 機能を搭載したシリーズを
選定するべきですね。
2012年1月7日土曜日
性能試験の結果
先日の、某県庁での性能試験の結果ですが、想像どおり何も準備が
出来ておらず、試験準備で終わってしまいました。
テストシナリオはおろか、テスト計画すら策定できておりず、ヒアリング
から始める始末。さらには、JMeterの操作方法のレクチャーまで...
県職員とはいえ、"情報政策課"所属で、日々サーバの運用管理を
実施されているのですから、もう少し基礎知識的な部分があることを
期待していたのですが...
とは言え、簡単な試験で、DBサーバよりもWEBサーバが先に音を
上げる事が確認出来たので、少しは貢献できたかと思われる。
ついでに、アプリ開発者にDBに一番負荷がかかる操作はどういった
ものなのかも確認していますし、再試験の方向性については示せた
かと思う。
出来ておらず、試験準備で終わってしまいました。
テストシナリオはおろか、テスト計画すら策定できておりず、ヒアリング
から始める始末。さらには、JMeterの操作方法のレクチャーまで...
県職員とはいえ、"情報政策課"所属で、日々サーバの運用管理を
実施されているのですから、もう少し基礎知識的な部分があることを
期待していたのですが...
とは言え、簡単な試験で、DBサーバよりもWEBサーバが先に音を
上げる事が確認出来たので、少しは貢献できたかと思われる。
ついでに、アプリ開発者にDBに一番負荷がかかる操作はどういった
ものなのかも確認していますし、再試験の方向性については示せた
かと思う。
2012年1月3日火曜日
性能試験
明日は、某県庁より、WEBアプリ性能試験のお手伝いを依頼されている。
使用ツールは、Apache JMeter。
バックエンドのデータベースサーバに負荷をかけるのが目的だとか。
単純に負荷をかけるだけならば、更新系の処理を想定同時アクセス数(約3000)で
短時間に繰り返せばと思いますが、はたしてそれが利用実態に則しているのか、と
言うところが気に掛かる。
県庁側からは、利用実態の想定に関しては、何ら情報なし。
明日、現地でそのあたりをヒアリングしながら、プランとシナリオを作成することに
なるのかな。
使用ツールは、Apache JMeter。
バックエンドのデータベースサーバに負荷をかけるのが目的だとか。
単純に負荷をかけるだけならば、更新系の処理を想定同時アクセス数(約3000)で
短時間に繰り返せばと思いますが、はたしてそれが利用実態に則しているのか、と
言うところが気に掛かる。
県庁側からは、利用実態の想定に関しては、何ら情報なし。
明日、現地でそのあたりをヒアリングしながら、プランとシナリオを作成することに
なるのかな。
登録:
投稿 (Atom)