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

タグ: はてなダイアリーからの移行記事 (13ページ目 (18ページ中))

SUPERMICROでAtomサーバ。

最近、keepalivedなんかを動かすために、強烈なCPUパワーはないけれど、そこそこ動いて、低電力で小型なサーバがないものかと漁っていたら、SUPERMICROがAtomを搭載したマザーボードをリリースしたらしい。

ページが見つかりませんによると、

サーバ向けをうたうSUPERMICRO製のAtomマザーボード。Atom 230搭載/デュアルチャネルメモリアクセス対応で、ICHには同種製品で初めてICH7Rを採用している。フォームファクタはFlex ATX。

紹介されているのは、Atom N230を搭載した安いモデルだけど、Atom N330(デュアルコア)で、かつ、オンボードでNICが2枚刺さっている上位モデル(「X7SLA-H」)がいい感じだと思われ。でも、NICが蟹さんってのがなぁ…あんまり好きになれないような気がするが、ま、仕方ない。

X7SLA-H

で、SUPERMICROは、このマザーボード用に(NECのハーフサーバ風の)1Uのシャーシもリリースするらしい。シャーシの奥行きが短いので、ラックの前と後ろと前からサーバを刺して、1Uなのにサーバが2台刺さっている状況が作れるのかも。

SC502L-200B

ま、Atomマシンなら、電源が200Wくらいあれば十分そうだし、3.5インチドライブ1個の代わりに、2.5インチドライブを2つ搭載して、RAIDってのも実現できそうだし。用途は慎重に選択する必要があるのかもしれないけれど、サーバを安く構築できそうで、なかなか悪くないような気がする。

CCCが価格.comの株式を20%取得ですとな。

…なんとなく意外な組み合わせだなぁと。

でも、実際に店舗を持っているビジネス界隈では存在感のあるTポイントも、ネット界隈だとさっぱり存在感を感じなかったりするのは私だけだろうか。ネットにどっぷり感のある私からすれば、Tポイントより、むしろ楽天ポイントの方が身近な気がする(汗)まぁ、もしかすると、CCCはその辺をなんとかしたかったりするんだろうか。

…とはいえ。

価格.comも、当初はパソコン中心だったけれど、今ではいろんなモノを取り扱うようになっているが、やっぱりモノを売っているサイトではない。そうなると、ポイントとの距離感は近くないような気がする。それに、既存のTポイントの会員をネットに誘導する(=IDをひもづける)のも、ビックカメラやヨドバシカメラががんばっているのを見ていると容易ではないんだろうなぁと思う(Tカードを持ってないので詳しくはわからないんだけど、今ではTカードを作れば、ネットでのID/PASSもセットで発行されるんだろうか)単に、Tポイントの企業のプロモーションを価格.comでやるっていうのなら、資本提携するほどのことでもなさげだし。

ふと、デジタルガレージの決算短信をぼーっと眺めてみると、子会社のテクノラティジャパンなどの業績不振に伴う資産価値の減損処理と、株式の評価損による特別損失を抱えているみたいだったけど…(汗)その辺も関係あるんだろうか。

参考:

デジタルガレージ「平成21年6月期 第3四半期決算短信」:

http://www.garage.co.jp/ir/pdf/090514_dg_tanshin.pdf

gangliaの「cpu_aidle」と「cpu_idle」って。

gangliaでサーバを監視させようとしたら、gmond.confで監視対象とするmetricを設定するというところまでは、わかったんだけど、CPU関連の「cpu_aidle」と「cpu_idle」ってなんだろうというのがよくわからず。

…似たような名前で、遊んでるマシンを監視対象とした場合、(ぱっと見た感じ)似たような値を出力してくれてるので、どっちかでいいかなぁと思ったりして。

で、Google先生に聞いても教えてくれないので、gangliaのソースを解凍して、./gmond/modules/cpu辺りのmod_cpu.cをなんとなく眺めてみたら、それっぽい配列があった。

static Ganglia_25metric cpu_metric_info[] =
{
{0, "cpu_num",    1200, GANGLIA_VALUE_UNSIGNED_SHORT, "CPUs", "zero", "%hu",  UDP_HEADER_SIZE+8, "Total number of CPUs"},
{0, "cpu_speed",  1200, GANGLIA_VALUE_UNSIGNED_INT,   "MHz",  "zero", "%u",  UDP_HEADER_SIZE+8, "CPU Speed in terms of MHz"},
{0, "cpu_user",     90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the user level"},
{0, "cpu_nice",     90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the user level with nice priority"},
{0, "cpu_system",   90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of CPU utilization that occurred while executing at the system level"},
{0, "cpu_idle",     90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request"},
{0, "cpu_aidle",  3800, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percent of time since boot idle CPU"},
{0, "cpu_wio",      90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request"},
{0, "cpu_intr",     90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "cpu_intr"},
{0, "cpu_sintr",    90, GANGLIA_VALUE_FLOAT,          "%",    "both", "%.1f", UDP_HEADER_SIZE+8, "cpu_sintr"},
{0, NULL}
};

これによると、

cpu_idle: Percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request

cpu_aidle: Percent of time since boot idle CPU

ってことのようだ。

後者の「cpu_aidle」がbootしてからの経過時間に対して、CPUがなんにもしてなかった時間の割合、前者の

「cpu_idle」はCPUがなんにもしてなかった時間-(ディスクIOを待っていた時間)の割合ってことだろうか。

…ただ、グラフを眺める限りでは、「cpu_idle」は、bootからの経過時間で計算って感じではなさそうなので、なにか単位時間に対して、値を計算しているような気がする。

「cpu_aidle」の値を、長い期間、監視しつづければ、CPUが使われることによって値が低下してくことになるだろうから、サーバリソースの追加投入時期の検討なんかに使えそうな気がする。

一方、いつ、CPUにどれくらいの負荷がかかったかは「cpu_user」とか「cpu_system」で取得できそうな気がするので、「cpu_idle」はCPU負荷の監視項目としては要らない気がするなぁ…。うーむ(汗)とはいえ、CPU空き率(?)を見ようと思ったら、「cpu_user」と「cpu_system」などを足し算して、100から引くみたいなことをせざるを得ないので、それはそれであってもいいかなという気もしてみたり。

…とはいえ、古めのPC(NorthwoodなCeleron機…涙)にCentOSを入れて、Gangliaでグラフを書かせてみたら、グラフを書く負荷で、そのマシンの負荷が閾値を超えたりする始末なので、とりあえず何でもかんでもグラフを書きやがれってのも、多少、危ないかなという気もするし…と。

3wareがLSIに売却されたらしい。

…今更、気がついた(汗)

さっき、3wareの英語サイトを眺めていたら、フッターがLSIになっていて、なんかの間違いだろうと思って、Goolgle先生に聞いてみたら…。

AMC flogs 3Ware storage | TheINQUIRER

AMCCが$20 millionと引き替えに、3wareをLSIに売却したって書いてあった。MegaRAIDシリーズのLSIと、9650SEなどの3wareの組み合わせは悪くないのかなぁとおも思ったりして。

とりあえず、LSIは「LSI Welcomes 3ware」だそうだ。

LinkStation「HS-DHGL」のHDDを換装してみた。

こちらのエントリーに書いたように、ウチのNASの「HS-DHGL」のファームウェア更新に失敗し、とりあえず、中身をいじってなんとか復旧はさせたけれど、ついでなので、HDDを交換することにした…と。

まずは、買ってきた「WD10EADS」をSATA-USBケーブルに接続して、Ubuntuが入っているThinkpadに接続。で、自動マウントされるので、全部アンマウント。ドライブが/dev/sdbで見えてたので、

fdisk /dev/sdb

で、こちらのページを参考にしながら、領域を確保。ま、/bootの200MBは、このまま200MBで確保するのがいいのか迷ったけれど、そのまま200MBで確保しておいた。で、後は、mkfs.xfsとかのコマンドを使ってパーティションにファイルシステムを作った。

とはいえ、このままだとHDDの箱ができただけなので、NASとしてはbootせず…と。

で、Buffaloのサイトから適当なファームウェアをダウンロードしてきて、Windows上で解凍するといくつかファイルが現れる。Google先生に聞いた感じでは、この中のいくつかのファイルを/bootに放り込んで起動させれば、NASとして使えるようになるらしい。

どうやら、以下のファイルが/bootにあればよさげ…と。

  • initrd.img
  • hddrootfs.img
  • u-boot.buffalo.updated
  • uImage.buffalo

ただ、initrd.imgとhddrootfs.imgは、imgって拡張子になってはいるけれど、実態はパスワード付ZIP

らしく、そのパスワードは…インターネットのどこかにあるらしい…と。(笑)

これらのファイルをHDDの/bootにコピーして、HDDをHS-DHGLに接続しなおして起動すると、(おそらく普通に)NASとして使えるようになるはずだが、設定はきれいさっぱり初期設定状態なので、最初にセットアップした手順でほいほい設定すればよさげ。

で、もともと入っていたHDDに入っているデータは、NASにぶら下がっているUSB-HDDにバックアップを取ってあったので、そこから書き戻し。xfsを扱えるLinuxマシンだと、もともとのHDDを覗けるので、データを引っ張り出して、NASに書き込めばいいんじゃないかと。

たんたん刀削麺@秋葉原 刀削麺荘 唐家

NASのHDDを交換するべく、新しいHDDを購入にしに秋葉原に行ったついでに刀削麺を食べてきた。

f:id:y_fudi:20090509134300j:image

たんたん刀削麺 香菜増し

刀削麺荘 唐家には、オプションで「香菜」ってのがあって、刀削麺に乗っている香菜を増量できるのがすばらしい。この緑が溢れる感じ…完全に好みが分かれる領域だとは思うけれども、嫌いな人には精神的ブラクラになってしまったかもしれず、申し訳ない。

いやはや、この刀削麺の食感もスープも(もちろん香菜も)なんだかクセになってしまっている(汗)ような気がしていて、がんこラーメンやラホールといった、個人的なアキバ定番の訪問率が下がっている…。

LinkStation「HS-DHGL」のファームウェア更新に失敗した。

自宅のNASは、Buffalo LinkStation HS-DHGL。普通に使えていたので、ファームウェアをそのまま放置していたが、ふと、思いついて行進してみたら、「ACP STATE FAILURE」が出て失敗。再起動してみたり、もう一回ファームウェアを更新してみたり、いじくっているうちにまともに起動しなくなった(汗)

でも、google先生に聞いてみたら、同じような症状に直面している人が少なくないらしく、なんとかできるような気がしてきた(笑)

で、どうやら、HS-DHGLのケースを開けて、HDDを取り出さないといけないらしいので、じゃあ、ついでにHDDも交換しておくか(汗)ということで秋葉原へ行って、Western Digitalの「WD10EADS」を買ってきた。FAITHで\7,480。WD10EADSに交換することで、容量が320GB->1TBに増えることになる。

さて、いきなり新HDDにするのもアレなので、もともと入っていたHDDでなんとか起動する状態に戻してみようということで、作業にとりかかった。

こちらのblogを拝見したら、「ACP STATE FAILURE」が出てファームウェアの更新が失敗してしまう原因は、/boot領域にゴミが溜まってしまい、容量不足になって、ファームウェアのデータの書き込みに失敗することのようだ。対処法は、/boot領域のお掃除をすること…と。

/bootの容量不足で書き込み失敗ってのはなんともお粗末な印象…。

で、HS-DHGLの中身はどうやら、ARMで動いているLinux箱みたいなので、/boot領域のファイルシステムはext3になっているらしい。そこで、HS-DHGLのネジをいくつか外して、HDDを露出させて、UbuntuがインストールされているThinkpadを用意して、SATA-USBなケーブルでHDDを接続してみた。(事前に調べた情報で、Linux箱とはいえ、「/」とデータが収められているパーティションはxfsみたいなので、Ubuntuのパッケージマネージャから、xfs関係のモジュールをインストールしておいた)

そしたら、HDDはいくつかのパーティションが切られていて、/bootはext3だけど、システム領域(「/」ですな)と、ネットワーク越しに見えるデータ領域はxfsが使われていることを確認。

/bootがだいたい200MBほど確保されているけど、ファームウェアのデータがだいたい100MB近く。そもそも余裕がある設計になっていないようだ。

うーむ、未確認な妄想だけど、ファームウェア更新完了時に、新旧2つファームウェアのデータが/bootに存在することが必要で、再起動後に新ファームウェアからHDDにデータが展開された後に旧ファームウェアが削除されたりする仕組みなのだろうか。こういう仕組みだとすると、ファームウェアのバージョンアップに伴う肥大化によって200MBという領域が微妙に不足する(300MBくらい確保してたら回避できるのかも)のが、ACP STATE FAILUREの原因と言うことになるのかも。てか、そうでもないと、200MBの領域に100MBのデータを書き込むのに失敗する理由がよくわからん。もしかして、ファームウェアの更新処理に旧ファームウェアの削除処理が入っていないとかいうオチなんだろうか(汗)

ま、とりあえず、/bootに落ちているhddrootfs.buffalo.updatedとかhddrootfs.imgを削除(なんで同じようなファイル名で同じようなサイズのファイルが2つも落ちているんだろう)。ただ、rootが所有者なので、sudoしながらrmで削除。で、Ubuntu側でアンマウントして、HS-DHGLに接続しなおして起動してみたら、とりあえず起動したが、smbやWebインターフェイスなどは起動していないので、ファームウェア自体は書き込まれていない感じだろうか。というわけで、ネットワーク越しに北米バッファロー(汗)のサイトから落としてきた最新ファームウェア(Ver.2.11?)を書き込んでみたら、再起動がかかって、しばらく経過したら、Webインターフェイスにアクセスできるようなったので、とりあえず成功したっぽい。

HDD換装につづく。

人生ゲーム 極辛って。

ひさしぶりに人生ゲームってどうなっているんだろうなぁ…と思ってTAKARA TOMYのサイトを覗いてみたら「極辛」ってのが出てた…。

ちらっとマス目を見たら、こんなのがあるらしい。

  • クレジットカードをスキミングされる。
  • 新型ウィルスで高熱。
  • オレオレ詐欺にあう。
  • その場の空気が読めず大失敗。
  • 子供がケータイを使いすぎ。
  • マンションが傾いてきた。

などなど。

…いやはや、世知辛い世の中ですな。

「この指とまれ!」がサービス停止中

この指とまれ!、「甚大なトラブル」でサービス停止中」より

「この指とまれ!」のサポートセンターによれば、現在はシステムが全面的にダウンしており、原因究明と復旧作業を継続しているが、復旧のめどはたっていないという。

そういえば、doblogのサーバでディスクが2本故障して、RAID5が崩壊したときもこんな感じのサービス停止だったような気がするなぁ(汗)

サービスを全面的に、ある程度長時間にわたって停止せざるを得ない「甚大なトラブル」ってHDD周辺のトラブル(それもマスターサーバでのデータロストなんかのトラブル)くらいしかないんじゃないかなぁ(この手のサービスだと、サーバ自体は冗長化しているだろうから、もし、サーバが故障したといったトラブルだと、縮退してでも動きそうな気がするので)

「この指とまれ!」は使ってないとはいえ、早く復旧して欲しい気がする。

« Older posts Newer posts »