ただつらつらと日記が書かれていくようです。

カテゴリー: ITめいたこと (23ページ目 (31ページ中))

HPのccissドライバがなんとなく怪しい。

最近、HP製Proliantを複数台導入してみたわけだが、これまたなんだか調子がよろしくない。ちなみに、使っているOSは「CentOS5.5のX86_64」で、RAIDカードは、HP製SmartArray(/dev/cciss/c0d0…みたいな。)

発生した事象としては、以下のような感じ。

  • いきなり平均負荷率が急上昇(Gangliaのレポートによると)
  • CPUのiowaitが100%。(これまた、Gangliaのレポート)
  • SSHでログイン不可。
  • Pingには応答あり。
  • トリガー不明。

なんとなくだけど、OSとかアプリケーションは起動状態だけど、Diskにアクセスしようとしてアクセスできなくて、そのまま、プロセスが待っている(待っているプロセス分、平均負荷率が上昇するような感じ)SSHでログインしようとするけれど、応答がない(おそらく、パスワード認証のためにファイルを参照しようとするがファイルが見られないんだろうなぁ)

そんなわけで、現地まで赴いてみたが、コンソールからもログインできない。ま、出来ることといえば、電源の長押しくらいなので、素直にぽちっと押して強制再起動してきた。(現地に到着してから、ProliantにはiLOがあったことを思い出すが、マネジメントポートにLANケーブルを刺すことから忘れてるわけで。orz)

…とまぁ、そんなことがあったけれど、トリガーが何だったのかがよくわかんない。思い出したようにサーバのサーバの負荷が上がり出すしたようにしか見えないので、とりあえず原因不明。まぁ、でも、ディスクにアクセスできない感じなので、CCISSドライバとか、RAIDカードのファームウェアとか、ext3とか…なんかその辺が怪しそうな気がする。

んで、RedHatのBugzillaを覗いていたら、治ってるのも含めて、ccissドライバ関連のバグをいくつか見つけた。RHEL4の頃から、ccissドライバ関連でバグがちらほら見られるようだ。ま、もうちょっと調べてみるか、と。

spawn-fcgiでphp-cgiを起動できずにハマる。

…実にがっかりなことでハマったので記録しておくことにする。

さくらのVPSにnginxとfastcgiのPHPをインストールしてある。要するにHTTPはnginxが受け付けて、PHPのリクエストに関しては、nginxからFastCGIで常駐しているPHP-cgiを呼び出して処理する…そんな構成になっている。

このサーバでは、WordPressが動いているのだが、nginxが軽いせいか、普通にApache httpd+mod_php5の組み合わせよりも体感速度は速い。

nginxとFastCGIで起動してあるphp-cgiは連携はしているものの、起動するプロセスの数を制御する関係にはないので、FastCGIで常駐しているphp-cgiの数以上は同時にリクエストを捌けないという欠点もある。しかし、この欠点が問題になるようなシーンでは、動的にいくつもプロセスを起動すれば解決するような気もしない(結局、山ほどプロセス起動してみても、足りないリソースが増えるわけじゃないし)から、あんまり気にしてない。裏側のphp-cgiが足りなくなったら、nginxがBad Gatewayあたりを返しそうな気がするから、それを見かけたら、リソース見合いでFastCGIで起動するphp-cgiの数を増やすかなぁという感じ。

そんな構成のサーバに対して、久々にメンテナンスでもするかってことで、PHP5のバージョンアップを行うことにした。

いつも通りのPHPのビルドオプションでビルド(…実はコレがまずかったのだが、すぐに気づくこともなく…)に成功。make installでインストールを完了して、CLIのPHPを実行してみたら、普通に動作するのだが、php-cgiを常駐させるために使っているspawn-fcgiがうまく動かない。

メンテナンス前に普通に使えていた起動スクリプトからphp-cgiを常駐させようとしても、なぜか、子プロセスがexitしてしまい、pidファイルがむなしく残る…と。いろんなログを見てみても、何も出力されておらず、ただ、起動直後に子プロセスがexitしていることだけがわかった。

まぁ、PHPを新バージョンにするまでは普通に動いていたわけだから、PHPが問題ってのはわかったので、1バージョン前のPHPをビルドし直してみたり、なぜかspawn-fcgiのバージョンを更新してみたり…ひたすら迷走。

ふと、PHPのビルドオプションを確認し直しているときに、軽いめまいが…。いつものPHPのビルドオプション=Apache httpd + mod_php5用なんだった(涙)端的に言えば、FastCGIで常駐させるってのにPHP5のビルドオプションに「–enable-fastcgi」が追加されてなかった。そりゃ、起動スクリプトで起動しようとしても終了するわけだ(汗)

…というわけで、PHP5を「–enable-fastcgi」付でビルド(実は、ダメ押しで「–with-fastcgi」なんて謎のオプションつけてconfigureかけちゃったのは秘密)したら、何事もなくFastCGIでphp-cgiを常駐させられた…と。

ま、いくらネタがないからってケアレスミス(構成管理ミス…か)をネタにしちゃいけないなぁ…なんて思いながら、しっかり書いちゃった(汗)

システム監視をどうしようか…って、Nagiosとmuninか…的メモ

postfixやBINDなんかの各種デーモンや、MySQLやApacheなど死んでもらったらとっても困る各種プロセスなどをどうやって監視しようかなんてことを最近ぼんやりと考えている。

システム監視と称してやりたいこととしては、だいたい以下の3つか。管理とは言いつつも、見張ってくれるだけでよくて、自動的にリカバリーしてくれってところまでは贅沢しない(涙)ということで。

  • 死活管理
    • 気持ち的には「各種プロセスよ、死んでくれるな」と言いたいところだけど…、ま、もし死んだら通知して欲しい。
  • リソース管理
    • いきなりDiskFullとかになっちゃうとイヤだけど、毎日、ディスクの空き容量を眺めるのもだるい。他にも空きメモリ量(…正確な数字を追い始めると深みにはまりそうなので、ざっくりと)とか気になる数字はいくつかあって、ある種の閾値を設定しておいて、もし、超えたら教えて欲しい。
  • 流量(?)管理
    • Webサーバとかルータにどれくらいのパケットが流れているのか…というところも取っておきたいような気がする。何に使うかは微妙だけど、例えば、サーバの負荷が高くなっているときにソフトウェア/ハードウェアがおかしくて負荷が高くなっているのか、流入するリクエストが増えているのかくらいはさくっと切り分けられたらいいのかな…とか。

リソース管理や流量(?)管理に関しては、ヒストリーというか、数字の変化をグラフで見られるとうれしいかなぁとか思ってしまう。

結局、いろいろとWebを探してみたら、NagiosとMuninを両方入れた方がいいのかなぁという気がしてきた。Nagiosは「現時点」の状況を管理するのはできそうだけど、ヒストリー管理はあんまり協力じゃない気がするが(…って、使い込んでないだけなのかも…)Muninはほぼデフォルトに近い設定でも、いい感じのグラフを書いてくれそう(ただ、MuninはPerlモジュールをいろいろと入れないといけないのが面倒そうなのが辛い…)ただ、2本のアプリで監視するとなると、監視される側もちょっと面倒なのかもなぁと思ったりすると遠い目にならざるを得ず、ちょっとどうなんだろう。

一応、NTTデータのHinemosも運用管理できそうだけど、導入事例をちらっと見てみると、なんかちょっとジョブマネージャとして使われている事例が多いような感じ。「うち、ややこしいバッチをパズルのように組んだりしてないから、ジョブマネージャはとりあえずいらないんだけどなぁ」という状況なので、あんましフィット感はないのかも。Hinemosは、日立のJP1をオープンソースでリプレースするような用途にはいいのかもなぁ…という印象を受けた。まぁ、ある意味、NTTデータ出身のOSSらしいのかもしれず(汗)

あと、死活管理は、モノによってはロードバランサが担っている部分もあるわけで、その辺との棲み分けも考慮する必要がありそう。

私はmuninのことをどこでどう間違ったか【mumin】と覚えていて(汗)Google先生の検索結果に、例のムーミン谷の生き物がごろごろ出てきて、かなり途方に暮れていたとかいないとか(涙)いやはや、かなり痛い午後だった。…って、何の告白なんだよ。orz

同僚のGalaxySを眺めてみた。

f:id:y_fudi:20110125012008j:image

同僚がDoCoMoのGalaxySを買ったということで、眺めてみたら…なんか悲惨なことになっていた。購入して間もないGalaxySのパネルがなんでこんなことになってしまったのか聞いてみた。

彼曰く「液晶保護シートを買ったんですけど、裏表を逆に付けちゃって…」って、とのこと。

つまり、つるつるの方をGalaxySのパネルに貼り付けて、静電気などでパネルに張り付きやすい方を外に向けて貼り付けてたらしい。シートの表面にホコリは付くし、タップしにくいし…ということで、裏表逆に付けていたことに気がついたらしいが、それまでに既に液晶保護シートが写真のザマになっていたらしく。

…それでも、一応、液晶保護シートを貼り付けて持ってきた結果が、上記の写真らしい。確かに、液晶保護シートの裏表はわかりづらいかもしれないけどなぁ(遠い目)

GoDaddy.comで安いSSL証明書を買ってみた。

さて、SSL証明書の有効期限が近づいてきたなぁ…と思ったので、前々から気になっていたGoDaddy.comでSSL証明書を買ってみることにした。

そもそも、SSL証明書ってブラウザとサーバ間の通信の秘匿性を確保するためには必要なものではあるんだけど、PCについては(逆に言えば、ガラケーあたりは除外して考えると)SSL証明書のベンダー間の差違を感じづらい商品だと思っている。

まぁ、確かに、EV SSL証明書なんてのもあるけれど、一般的なサイト利用者を想定すれば、ブラウザのアドレスバー辺りが緑になるなんて野はどっちかというと誤差に等しく、SSL通信を始める際にブラウザがエラーを出さなきゃOKくらいの感覚…が正確な表現だろうか。

SSL証明書を購入する側がそんな感覚なのに、ベンダーによって値段がピンキリだったりするのが、SSL証明書のややこしいところだ。

確かに、購入サポートというか、期限切れになりそうになったら懇切丁寧にリマインドしてくれるとか、簡単にSSL証明書を更新できるとか、そういった部分も考慮に入れる余地はあるけれど、あくまでSSL証明書に付帯するサービスという位置づけに過ぎないと思う。

要するに、PCのサイトとメジャーなブラウザで使えればいいことを前提にすれば、SSL証明書なんて安いもので十分ではないかという結論に至った。

そんなわけで、GoDaddyである。GoDaddyは、アメリカでドメインだのレンタルサーバだのSSL証明書だのを売っているサイトで、国内で売っているSSL証明書と比較すると、破格の安さで提供されている。

例えば、シングルドメインのSSL証明書(SSL証明書を買った組織の存在証明とかしないでドメインの確認だけ行うタイプ)で、だいたい4000円/年くらい。いやはや、これは激安。しかも、複数年契約するとディスカウント(確か、私が買ったときにはお買上額から-10%だったかな)されてしまうという、うれしいサービスまであった。

とりあえず、記憶が曖昧ではあるんだけど、3年分を買って1万円くらいだったかなぁ…と。GoDaddyでSSL証明書を買うまでは、この値段で、だいたい1年分買えれば安いなぁ…という感覚だったような気がする。

ここまでだと、GoDaddyサイコーとなってしまうが、それなりにやっかいなことがあるので、それをメモっておく。

  • 日本語使えません(笑)

GoDaddyのサイトはもちろん英語。しかも、なまじ日本円で値段が表示されたりするから、うっかり期待してしまうけれど、購入完了まで日本語が出てくることはなかったような気がする。

とはいえ、国内のサイトでSSL証明書を買ったことがあれば、必要な手続きはわかっているはずなので、うろ覚えの英語で必要な手続きをやれば、SSL証明書は発行される…と思う(まぁ、保証はできないけども…)

  • 決済にはPayPalを使いました。

GoDaddyにお金を支払う際に、クレジットカードも使えますが、PayPalも使えるみたいだったので、私はPayPalで支払い。まぁ、GoDaddyがサイトで商品の値段を日本円で表示しているけれど、結局、ドル建てで決済したような気がするが、どうだったか…と(これまた記憶が曖昧)

もし、PayPalのアカウントもなく、国際決済できるクレジットカードもないとなると…ハードル高いかなぁという印象はあるかなーと(日本とアメリカの銀行間の少額決済とか高そうだし)

  • ぶしつけに確認メールが飛んでくる

一応、手順的には、まずオンラインカート機能を使って、SSL証明書を発行してくれる権利を買って、その後でCSRなんかを入力して、最後にドメインのValidationってことで、ドメインのWHOISに載ってるアドレスに承認を求めるメールを”いきなり”送ってくる。今回はco.jpドメインだったが、JPRSのWHOISに登録されている「登録担当者」のメールアドレスにメールが飛んできた。

国内の某SSL証明書ベンダーから買ったときには、@の左側の候補(info@とかadmin@とか)がいくつか提示されて、どのアドレス宛に承認を求めるメールを送ればいいか聞かれたような記憶がうっすらとあるが、GoDaddyはWHOISを参照してどーんと送ってくる。

そういう意味では、GoDaddyでSSL証明書を購入するつもりなら、SSL証明書を発行する対象のドメインのWHOISをきれいにしておくことが必須だろうと思う。

  • なんとなくヘルプは薄め

これまた個人的な印象ではあるけれど、GoDaddyにヘルプ(やっぱり英語)もあるけれど、これがあんまり親切な感じではなかった。日本の某SSL証明書ベンダーのように、手続きを1から終わりまで列記してくれるとありがたいんだけど…そんなわけにもいかず(汗)

結局、お金をいつ払って、CSRをどこで入力すればいいのかとか、結構、慣れないとSSL証明書ベンダー毎にシステムが違ってたりするから、これまたややこしさ満載ではあるんだけど、GoDaddyはその部分について親切とは言い切れなかったなぁと。

まぁ、とりあえず私は無事に購入できたし、GoDaddyのSSL証明書(中間証明書込みで)を組み込んだサイト(確か、プラットフォームは、さくらインターネットのレンタルサーバのビジネスプロ)の方も何事もなく動いているみたいだ。

これをメリットというと少しアレだけど、GoDaddyからディスカウントコードが届くようになってしまった。時折、.comドメインとか.imfoドメインあたりが、期間限定で30%引きになったりするらしい。

とりあえず、今度、ケータイ(ガラケー)を前提から外せるサイトのSSL証明書を調達するのであれば、GoDaddyで十分だと思っている。

追記:

若干のドヤ顔気味で「GoDaddyで十分だと思っている。」とか書いちゃってますが、godaddy.comのSSL証明書よりもイイ感じの証明書を見つけてしまいました。→「また安いSSL証明書を探してみた。

なんかルーターの交換(RTX-1100)でハマった。

昨日、会社のルーター(RT57i)がパフォーマンス不足になって、ちょっとややこしいことになったので、勢いよくRTX-1100に交換してみたら、きれいにはまった(涙)

まぁ、もともと使っていたRT57iの設定を流用しつつ、無駄なNAT設定や意味不明な設定を見直そうとしたときに、コンフィグに余計な設定を追加しちゃったのが原因だったことが後からわかる…のだが、ま、その時は気がつかないわけで(汗)

RTX-1100に交換して何が起こったのかというと、RTX-1100に交換してパフォーマンスの向上を期待したにも関わらず、すさまじいパフォーマンスのダウン。

とりあえず、つながっているんだけども、SFTPでファイルをダウンロードし始めたら、スループットがRT57iを使っていた時の10%くらいになってた(涙)

さらに、イントラネットのマシンからイントラネット側のIPアドレスにPingを打ったらRTTがすんごいことになった。ファストイーサネットなLAN(間に入ってるスイッチングハブが2つくらい)なのに、RTX-1100にPingを打つと600msとかかってる(汗)てか、太平洋超えても200msくらいじゃないのか…と。

まず、RTX-1100に余計なフィルター設定をしたんじゃないかと思って見直してみたが、その辺はRT57iの時と変わらず。RTX-1100にすることでハードウェア性能は向上しているはずなので、同じ設定であれば、こんなことは起きるはずもない。

イントラネット側のIPアドレス宛のPingのRTTがすんごいことになっているにも関わらず、RTX-1100のCPU使用率は10%以下のまま。RTX-1100自体が輻輳している訳じゃないことがわかった。

…で、設定を見ながら、ふと目にとまったのがこの1行。RT57iの頃にはなかった設定で、なんとなく追加した1行。

lan type lan1 100-fdx

この設定は、RTX-1100に搭載されてるイーサネットポートの通信速度を100BASE-TXのFull Duplexに固定する設定と。

そういえば、RTX-1100が刺さってるのは、非管理型のギガビットイーサ対応のスイッチングハブ…(汗)あ、やばいかも。

というわけで、この設定を

lan type lan1 auto

に、変えた瞬間にSFTPのスループットもPingのRTTも大幅に改善するわ…と。とりあえず、問題は解消。

なんか、最近、データセンター用のL3スイッチいじってたから、通信方式は固定すべきなんて無意識に思ってたのが仇になった。確かに、データセンタに置かれてるような(高い)スイッチは、スイッチ側で通信方式を固定させられるから、接続するマシンの通信方式を固定しても、うまく接続できるわけで…。一方、オートネゴシエーションにするとややこしいことになるから、わざわざ、スイッチとマシンに設定を施して固定するという背景があることも確かだしなぁ(遠い目)

ただ、ポートの通信方式を設定できないスイッチにマシン(とか、NW機器)を接続するときは、とりあえず、オートネゴシエーション設定にするしか選択肢がないんだろうなぁ…って、そんなことは当たり前ですか、そうですか(涙)

…やっぱり、ネットワークは難しいなぁと…。

Xperiaを買ってみた。~その1~

とりあえず、なんとなくの勢いで「Xperia」を買ってみた。

f:id:y_fudi:20100829150116j:image

スマートフォンを使いたくてムラムラしてたとか、ガラケーに飽きてたとか、そういうことも特にない。まぁ、流行ってるみたいだし、触っといて損はないかなぁくらいの感覚で、それまで使ってた、DoCoMoのガラケー(N-01B)を持ちつつ(ま、ほとんどオサイフケータイのために持ってるようなもんだけど)、2台目として「Xperia」を買ってみた。

8月下旬、ふらっとヨドバシAKIBAに出かけてた。展示されてるXperiaをちょっといじってみて、「これの黒いのください」と店員さんに告げて、多めの書類に名前をいっぱい書いて申し込み完了。しばらくして、ヨドバシカメラのレジにて、シャリーンとEdyで代金を支払って、晴れて「Xperia」が手に入った。

値段は、確か、2年縛りの割引が付いていたので、3.5万円くらいだったかなと。溜まったままになっていたヨドバシのポイントを使ったりして、Edyでお買い上げしてみた。陸マイラーとしては、Edyでシャリーンと行きたいような気がしたけど、本当に正しかったのか…と言われると、ちょっと自信がない。

そういえば、9月になってから、DoCoMoがSPモード開始記念で本体価格の割引を始めた(買った翌日くらいに、キャンペーンの発表がなされるという…)ので、1週間くらい遅く契約していれば、5k円くらいは得したかもしれない。まぁ、残念といえば、8月下旬に買って、当然ながら、パケ・ホーダイダブルを付けたんだけど、スマートフォンでパケ・ホーダイダブルを使ったら、一瞬で上限価格に達するわけで…1週間しか使っていないにも関わらず、1ヶ月分のパケ・ホーダイダブルの上限金額を払わなきゃいけないのはなんとなく切なかった…か。とはいえ、DoCoMoのスマートフォンが欲しいと思う人達は、普通、その辺も考えて、ちゃんとSPモード記念の割引も適用され、パケ・ホーダイダブルの上限金額を支払いつつも、きっちり1ヶ月分使える、9月上旬の契約をされていることだろう。

これまで、N-01Bにパケ・ホーダイ(≠パケ・ホーダイダブル)を付けていたけれど、さすがに2台ともパケホーでがっつりお支払いするのもアレなので、N-01Bはパケ・ホーダイダブルに切り替えてみた。たまにメールが来たり、オサイフケータイのEdyやSuicaのチャージくらいなので、ほとんどパケット通信が発生せず…と。極めて、平和な状態だ。

そんなわけで、「Xperia」が手に入ってしまったわけだけだが、最初の充電をしながら、ふと思った。

「…Xperia、何に使うかなぁ」

続く。

Androidアプリ事典512
Androidアプリ事典512

posted with amazlet at 10.09.11
アンドロイダー
インプレスジャパン
売り上げランキング: 2305

HITACHIのHDDを買ったらリテールパッケージだった。

社内の開発用マシンのHDDを交換することになったので、とりあえず、HITACHI製のドライブを買ってみた。

プチプチに包まれたバルクドライブが届くつもりで待っていたら、届いたのは、なんかもう「the リテールパッケージ」って感じの箱入のハードディスク。

HITACHIのDESKSTARリテールパッケージの外観

外箱には、ご丁寧にHITACHIのロゴまで入っていて、ちゃんと「inspire the next」って書いてあったけど…ここまでする意図はなんだろうという感じ。バルクドライブのまま流通させたほうが安そうだし、こういうところにお金をかけて値上げされても辛いというか、こういうところ値上げされると、他のベンダーのHDDを買いそうになるのは私だけだろうか。(…ところが、こんなしっかりしたパッケージのHITACHI製ドライブがむしろ安かったのはどういうことだろう…)また、外箱には中に入っているHDDの型番を書いていなかったので、HDD好きな人にとっては型番を選べないのも辛いかもしれない。

で、外箱を開けて、中のHDDを引っ張り出してみると、HDDが箱の中でしっかり動かないように梱包されていて、かさ張るけれども、まぁ、これはこれでいい感じ。

HITACHIのDESKSTARリテールパッケージの中

日本語で書かれた保証書が付いていた。お買い上げ日から3年間保証らしい。ただ、SeagateのRMAなんかと違って、HDDが保証期間内に故障したら、お買い上げ店に持ち込んで…ということになってるのが面倒くさそうだ。普通に、RMA方式でいいじゃないかと思うのだが…。

もとい。こんなしっかりしたパッケージとバルクドライブを併売するのもナンセンスだろうから、日立が保証を付けてリテールパッケージ売りを始めるということは、そっち方面にシフトしていくということだろうなぁ。…てか、いつから始めたんだろう(汗)

ファーストサーバがさくらのレンタルサーバを狙ったサービスをローンチしてた件

ちょっと新しいレンタルサーバを調達するか、ということでレンタルサーバのサービスを探していたら、新しいサービスを見つけた。その名も「サーバーカウボーイ」。

…えーと。まぁ、ネーミングはさておいて、レンタルサーバの仕様を眺めてみると、さくらインターネットが提供している「さくらのレンタルサーバ」の仕様とそっくりだった。

レンタルサーバー機能一覧:

http://server-cowboy.jp/function.html

SSHを提供してみたり、Cronも開放してみたり…と、「さくらのレンタルサーバ」が、ちょっと特徴的なサービスを踏襲しつつ、マルチドメインの数を無制限にしたりと小技も使っていたりする。

価格についても、肌感覚で一番売れているであろう「さくらのレンタルサーバ」のスタンダードに合わせている感じがなんとも…。(しかも、ドメインの取得費用についても、さくらの値段に合わせている気がするのは私だろうか…)

従来のファーストサーバのサービスラインナップからすると、結構安くて、充実したスペックになっている印象がある。まぁ、やればできるんじゃんなんて感想を持ってしまった。

ただまぁ、このファーストサーバのサービスリリースを眺めている限りでは、さくらインターネットがレンタルサーバの価格とスペックの「標準」になっているということだろうし、従来からのレンタルサーバのスペックを「押し上げて」、価格を「押し下げた」ということだろう。また、ファーストサーバくらいの規模であれば、さくらインターネットと同じレベルのサービスを提供しながらも、同じくらいの価格設定ができるということも明らかになった気がする。

ということは、さくらインターネットやファーストサーバほどの規模がない中小のレンタルサーバ事業者にとっては厳しい事業環境になるんだろうなぁ…。

うちのHS-DHGLをFreeNASでリプレースしてみるかと思ってみるテスト

えーと、うちのNASはBuffaloの「HS-DHGL」。

確か、2006年頃に発売された製品だったか。いわゆる、家庭向けのLinkStationで、DLNA機能とか付いているけれど、ほとんど使ったことはなく、純粋にNASとしてしか使っていない。購入以来、HDDが容量不足になったのでHDDを換装してあったり(今、1TBのHDDがささってたはず)、ファームウェアも書き換えてあって、iSCSIとかしゃべれたりするのだが、これまた使っていない(汗)telnetログインできるんだが、なんだかエラーを吐いてるのが見える(WebのGUIにアクセスした途端に、error.cgiがCPUを食い始める…という)ので精神衛生上よろしくないかもしれない。

一応、このLinkStationにはUSB-HDDを接続して、そこにNASの中身をバックアップを取っていたんだが、このUSB-HDDがたまに書き込み不良になって、NASから切り離されたりする…というわけで、そろそろリプレースするか、となんとなく思い始めている。

とはいえ、次もLinkStationでは芸がないので、Atomを使った箱を作って、そこに「FreeNAS」をインストールしてしまおうかと。FreeNASは、名前の通り、FreeBSDベースと言うことで、あこがれのZFS(…RAIDカードなしに、RAID6相当の冗長性を確保できるのはいいと思うんだけど)も使えるし、GUIも付いているので管理も楽そうだ。うちのWindows7マシンからはiSCSIでマウントすることもできそうだし、…なかなか興味深い。

とりあえず、HDDがごそっとささるAtom箱を作るところからかー。

« Older posts Newer posts »