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

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

HPがSolarisを売り始めたらしい件。

今更ながら、メモっておく。

日本HP プレスリリース HP ProLiant向けSolarisおよび関連サービスの提供開始 2009年9月15日

HPが自社のx86サーバ「Proliant」に、Solarisを載せて売り始めたらしい。SunがOracleに買収する前に結ばれていた契約に基づくものらしいが、HPもなかなかおもしろいことをやるなぁと思った。

そもそも、Solarisのいいところって、その堅牢性とかZFSのような先端的な機能もさることながら、ローエンドからミドルレンジ、そしてハイエンドなマシンまで、スケールアップしても、Solarisで面倒見てもらえることだと思っていた。例えば、Sun FireV100のようなSPARCが1個のったマシンからE25Kのような何個SPARCが刺さってるのかよくわからんマシンまでSolarisが動作するわけでスケールアップできるレンジの広さはさすがSolarisかなぁと。Solarisを選んでおけば、スケールアップに伴うOSマイグレーションなんて心配しなくていい…みたいな。

そういう観点からすれば、x86なProliantにSolaris乗っけても、HP的な「先」は見えていて、きっと、HP-UXと「Integrity」な世界だろうから、「先」に行くためには、SolarisからHP-UXのマイグレーションをやらなきゃいけなくなるんだろう。システムが成長して、HP-UXと「Integrity」な世界に入らなきゃいけない頃には結構ミッションクリティカルなシステムになってて、SolarisとHP-UXの間でややこしいことになりそうなんじゃないか…と。

じゃ、やや暴力的だけど、そういう可能性があるなら、最初からHP-UXで作っておくのがいいんじゃないかと思ったりするわけだし、x86命でがんばるのであれば、スケールアウトしてずらっと並べる使い方が多いような気がしていて、そうなると、可用性や堅牢性も(何をもってそう言うか…は検討の余地ありまくりだけど)そこそこであればいいのではないかと思うし、安けりゃ安いにこしたことがないような気がする。そうなると、SolarisもRHELも(…そして、CentOSも…)変わらないような気がするんだけどなぁ(…無知ですか、そうですね)

ぼんやりとそんなことを考えると、HP-UX+Integrity以前の規模で、まず、x86サーバを選択したとして、わざわざSolarisを積極的に採用する理由ってなんだろうか(まぁ、ミドルウェアがSolarisじゃなきゃダメなんですとか、お客さんがSolarisが好きなんです…とかいろいろありそうではあるんだけど。でも、そういう時の「Solaris」って、x86じゃなくてSPARCとの組み合わせが必要なんじゃないかとふと思う。)

それでも、HPはSolarisを載っけたサーバを売り始めるわけだから、お客さんがいるという想定だろう。そういったお客さんにとって、どの辺がSolarisの選択理由になっているのか少し気になる。もしかして、とにもかくにもSolaris最高!って感じのSolaris信者のみなさま方って、意外と元気だったりするんだろうか。

…なんちゃって(汗)

安いNICはもうイヤだ~makuosanとVIA Velocity編~

最近、KLabさんがオープンソースで公開している「makuosan」を使ってみようと、意気込んでセットアップしていたら、以下のようなエラーに直面して、どうにもならなくなっていた。

CentOSが動いている「とあるホスト」にインストールしてあるmakuosanが以下のようなエラーメッセージを/var/log/meassageに残して、接続先(まぁ、同期対象のホスト群)を見失ってしまうというエラーで、回復するためには放置しても無駄で(汗)makuosanを再起動するしかなささそうだけど、再起動してもしばらくするとエラーメッセージ(ちょっと加工してますが)を吐いて接続先を見失うという無限ループ(汗)

Sep 4 11:38:01 centos makuosan: root: mrecv_gc: pong timeout some.host.net

Sep 4 11:38:01 centos makuosan: root: [error] member_del_message: pong time out: XXX.XXX.XXX.XXX(some.host.net)

これが発生するのは、makuosanを起動、もしくは再起動してからだいたい5分後。起動直後の5分間はまともに接続先が見えているんだけどなぁ…と思いつつ、なんとなくiptablesの設定を疑って他のマシンの設定ファイルとdiffを取ってみたり、makuosanを再インストールしてみたり…と、とっても五里霧中な感じのトラブルシューティングが続いた。

で、うろうろしたあげくに、makuosanのソースの「makuosan.h」を見てみると、以下のような記載があった。

/*----- timeout -----*/
#define MAKUO_SEND_TIMEOUT  500    /* 再送間隔(ms)                                 */
#define MAKUO_SEND_RETRYCNT 120    /* 再送回数                                     */
#define MAKUO_PONG_TIMEOUT  300000 /* メンバから除外するまでの時間(ms)             */
#define MAKUO_PONG_INTERVAL 45000  /* PONG送信間隔(ms)                             */
#define MAKUO_RECV_GCWAIT   180000 /* 消し損ねたオブジェクトを開放する待ち時間(ms) */

エラーメッセージに「pong timeout」と書いてあったことと、MAKUO_PONG_TIMEOUTの時間から察するに、makuosan起動直後からPING/PONGによる接続先生存確認に失敗してる感じかなぁとぼんやり妄想してみたが、やっぱりよくわからない。しかも、調べてみると、「とあるホスト」からは、周囲にいる接続先が見えなくなるけれど、周囲にいる接続先から「とあるホスト」は見えたまま…とうアンシンメトリーな状態だったことがわかり、なんとも気持ち悪かった。

…で、もうなんとなくやることがなくなって、唐突ではあるけれど「NICが怪しい」と思い始めて調べてみた。この「とあるホスト」はコストをケチるために、オンボードのNICに加えて、玄人志向製の「GBE-PCI2」(…なんか安易な型番だな)を使っていて、使っているチップはVIAの「VT6122」とのこと。いわゆる、Velocityシリーズってやつ。

この「VIA Velocity」用のドライバは、私が知る限り、2種類あって、1つがCentOSに入ってる「via_velocity」で、もう1つがVIAのサイトからダウンロードできる「velocityget」。以前、とあるMLで「via_velocity」のデキがよろしくないようで、Sambaなどで性能劣化を起こすという投稿を見つけていたので、「とあるホスト」には、VIAのサイトから「velocityget」を落として組み込んであった。…はずだったが、先日、カーネルを更新した際に「velocityget」を再インストールするのを忘れてたらしく、lsmodしてみたら、いないはずの「via_velocity」がいらっしゃった!(modprobe.confでは「velocityget」を指定してあったけれど、肝心の「velocityget」が存在しないから、代わりに「via_velocity」が読み込まれて、何となく使えてたらしい)

目下、makuosanが接続先を見失う問題に対しては、特に打つ手もなかったので、期待を込めて「velocityget」をインストールしなおし、「via_velocity」を/etc/modprobe.d/blacklistに書き込んで、マシンを再起動してみた。

そして、makuosanが起動して5分後、やや緊張しながら/var/log/messageを覗くと…何にも出力されていない。「msync –member」をやってみても、makuosanは接続先を見失っていなかった!

…というわけで、起動して5分でmakuosanが接続先を見失うという問題は、makuosanとはまったく無関係な、安いNICと怪しげなドライバが原因だったという、なんともお粗末な結末…orz。

今度、マシンにNIC足すときは、なんとなくbroadcomとかIntelのNICにしようと決めた次第である。

*1:modprobe.confでは「velocityget」を指定してあったけれど、肝心の「velocityget」が存在しないから、代わりに「via_velocity」が読み込まれて、何となく使えてたらしい

パーソナルワイヤレスルータはNTTの秘密兵器か。

週刊ダイヤモンドがこんな記事「無線ネットワーク間を波乗り NTT陣営の隠れた秘密兵器」を載せていた。

うーむ、まぁ、個人的にはちょっと微妙な感じがするけどなぁ…。

要するに、NTT-BPが無線LANとHSDPA網を適宜使い分けられる無線LANルータを開発したってことらしい。無線LANルーターというと、インターネット側は有線で、イントラネット側は無線みたいな製品が多い中、インターネット側は無線(無線LAN/HSDPA)、イントラネット側も無線で接続されるってところが新しいようだ。

仮に、パーソナルワイヤレスルーター(=1人1台的なイメージ)だとすると、正直、無線LANは要らないんじゃないか…と。単純に1人に1台、HSDPA端末だけあればいいだろうし、HSDPAが使えないところでは、普通の3G網に繋がってもらっていいわけだし。それだけで、無線LAN網は十分に代替できるような気がする。それに、モバイルしてるときには、ある程度、帯域は諦めてる人が多いだろうし。

…と穿った見方をすると、HSDPA端末に、なんとか無線LAN機能をねじ込みたくて、ルーター機能を内蔵したというのが顛末ではないだろうか。NTT-BPからすれば、自社インフラの無線LAN網の利用機会を上げられる製品になるだろうけれど、一方、例えば、DoCoMoからすればHSDPAのトラフィックが無線LAN網に逃げてるわけで、おいしいとは言えないんじゃないか。

 過去7年間、ずっと赤字だが、今ではNTT西日本、NTTドコモ、NTTコミュニケーションズも株主に加わる。すなわち、これはNTT陣営の隠れた“秘密兵器”なのである。

NTT事業会社がこぞってNTT-BPの株主になっているのって、まったく別の背景がありそうな気がするんだけど、違うのかなぁ。

例えば、NTT東日本の「フレッツスポット」、NTTDoCoMoの「MZone」など、各NTT事業会社が自由に作っちゃった無線LAN網は、各会社がそれぞれにがんばっても、広域をカバーする「面」にはなりづらい…と。だから、その辺のインフラ部分をNTT-BPに集めて、1つのインフラとして「面」がカバーできる状態にしつつ、各事業会社が、そのインフラを使って、それぞれ無線LANサービスを提供できるようにするために、各事業者が集まってNTT-BPに出資してインフラを委譲するってことをやったんじゃなかったかと。

…今回の「パーソナルワイヤレスルータ」は、週刊ダイヤモンドの記事が言うような「NTTグループの秘密兵器」とはほど遠くて、実態はWiMAXやHSDPA、LTEなどの登場で、既存の無線LAN網の資産価値を失いつつあるNTT-BPの悪あがき…のような気がしないでもないけどなぁ(汗)

さくらのサポートにメールしたら…がっかり。

さくらインターネットのサポートに、「XXXXってできますか?」ってYes/Noで答えられる質問を投げかけたら、しれっと設定例が返ってきた…って、設定例じゃ答えになってないんだけどなぁ…。むしろ、非公式FAQの方が役に立つってオチですか、そうですか。

さくらインターネットも台数が増えて、顧客が増えて…って流れの中でサポートセンターの中の人のテクニカルなレベルが低下してるんだろうかとふと思う。

livedoorのサーバOSはFreeBSDじゃなくてCentOSなのか、そうなのか。

WikipediaのFreeBSDのページを見てると、使用例の欄に以下のような記載がある。

ライブドア – ほとんどのサーバOSがFreeBSD

そんなわけで、「そうか、livedoor(のポータル)って、FreeBSDで動いているんだ」と思っていた。で、NetCraftで調べてみると、確かに、しばらく前までFreeBSDだったんだけど、最近はF5なBIG-IPになっていて、きっとBIG-IPの配下でFreeBSDががんばってるんだと思っていた。

しかし、livedoor開発blogの「1000台の子供達 – livedoorを支えるサーバ群 –」ってエントリーを拝見すると、

現在のポータルサーバの主流OSはCentOSです。新規にセットアップされるものの99%が、このOSになります。

…って(汗)ああ、そうなのか、livedoorはCentOSなのか。BIG-IPの配下でがんばってるのは、FreeBSDなサーバではなく、CentOSなIBMサーバ群ってのが真相のようで。きっと、膨大なサーバ群をリプレースしていく過程で、OSもFreeBSDからCentOSに変えていったのかと思うと、さすがlivedoorさんだなぁ…なんて思ったりする今日この頃。

個人的には、CentOSが何かと楽ちんな気がするけれど、FreeBSDの無骨な感じ(特にインストーラーとか)も悪くないし、デフォルトの設定が「堅い」(最初から誰でもsuでrootになれないとか)のはFreeBSDの方だったりするんじゃないかと思ったりする。…と、偉そうなことを書いてる割には、FreeBSDを触って1週間ですが、何か(汗)

CPUの熱でポテトは揚げられる…のかな。

GIGAZINEに「CPUから発する高熱でポテトを揚げる」って記事が載っていた。

要は、マザーボードごと食用油に浸し、なんか強烈な演算でもさせて、CPUやその他のチップから熱を発生させ、食用油を温めてポテトを揚げてしまおうってことらしく…。

ざっと、写真を見た感じでは、拡張カードらしきモノがささっているが、これがまた見慣れない感じ。なんとなくグラフィックカードっぽい形ではあるけれど…。で、上からの写真をよーく見てみると、マザーボードに刺さっているのは、伝説のファミカセ型CPUである「PentiumII」ではないでしょうか。まぁ、十分な発熱量があれば、フライヤー代わりには使えるかもしれませんが(汗)一般的にはゴミなハードウェアですな。

うーむ、PentiumIIの発熱量って微妙に記憶がないんだけど、ポテトが揚げられるくらい発熱してたっけ…。

…てか、(マザーボード上の)埃がたっぷりの油で揚げたポテトは食べたくないなぁ。

SeagateのHDDでRMAを使ってみた。

RMAってのは、Return Merchandise Authorizationの略らしく。要するに、SeagateのようなHDDメーカー自身が返品保証を付けて製品を流通させ、製品が故障するなどした場合に、ユーザーから直接HDDメーカーに返品することで代替製品を受け取れる…といった制度っぽい。ただ、Seagateの場合、返品する部分の輸送費はユーザーが負担しなくちゃいけないらしい。代替品の発送にかかる輸送費は負担してもらえる。

…で。

今回、社内のPCで使っていた「ST3500320AS」(ファームウェアバグで問題になったBarracuda 7200.11の500GB)は、ファームウェアの更新済みにも関わらず、使用開始から1年も経過していないのに(かつ、普通のPCの使い方しかしてないのに)に不良セクタ(代替処理済みセクタ、回復不能セクタ)が、かなりの数が発生していて、なんとなくこりゃまずそうだなと思い、交換用のHitachi(さすがに次もSeagateを選ぶ勇気はなかった)のドライブを買ってきて交換しておいた。

で、PCから外した、不安の残るBarracudaを捨てずに、RMAでSeagateに交換してもらうことにした次第。

まずは、Seagateのサイトで申し込み。トップページから「保証サービス」に飛んで、「ゲスト ユーザでドライブを返品する」に移動すると、返品するHDDのシリアルナンバーなどが聞かれるので入力し、保証が有効であることを確認。で、発送元の情報を入力すると、国内に送るか、シンガポール(…だったかな)に送るか選べるので、国内を選択。

で、私の場合は、SeagateのHDDを買ったときのブリスターパック(HDDを包むプラスチックケース)が置いてあったので、それで1段目の梱包とした。で、さらに、小さな段ボールに、ブリスターパック入りのBarracudaと、その周りに緩衝材を詰めて宅急便で返送完了。一応、RMA番号とSeagateのHDDが入っていることを品物欄に書いておいた。発送先は、成田にあるUPSの拠点っぽかった。

返送してしばらくは何の反応もなかったけれど、5日後にメールが届いた。タイトルは「Seagate RMS Receipt Acknowledgement」。どうやら、代替品をシンガポールから発送したっぽい。そのメールの中に、Tracking Numberが書いてあったのと、どうやらUPSで送られてくるらしいということで、UPSのサイトから代替品のHDDを追跡してみた。

UPSのサイトによれば

  1. シンガポール(出発)
  2. フィリピン(経由)
  3. 成田(到着)

という経路。「おお、本当に国際便だぁ」と、なぜかコーフンしてしまった(汗)

で、届いたのは、発送したときの小さな段ボールと比べると4倍くらいの大きさの段ボール。緩衝材も私が使ったような安物ではなくて、スポンジだった。でも、入ってるのはHDD一個。

f:id:y_fudi:20090709112600j:image

f:id:y_fudi:20090709112700j:image

で、届いた代替品をよく見てみると「Certified Repaired HDD」だった。うっかり新品を期待してしまったが、修理品とはいえ、きっと不良セクタがないドライブなんだから、まぁ、よしとしようかと(もともとバルクドライブで買ってるってのもあるし、HitachiだとRMA制度がないっぽいし。)

Firefoxの終了が遅い…てか、HDDに猛烈にアクセスやめれ。

会社で使ってるWindowsXpなPCにFirefox3が入っていて、普通に使っていたつもりだった…が、Firefoxを終了させた後で、プロセスが消えずに、そのまま居残った上で、なんだかもう他のアプリケーションの動きを一切許さないくらい猛烈にHDDにアクセスする(タスクマネージャで各プロセスごとのIOを眺めていたら、firefox.exeだった…と。)という謎の症状を見せており、最近、イラっとくるくらいに深刻になっていた。

で、google先生やbloggerのみなさまの知恵をお借りして、このFirefoxの挙動不審の解消に繋がりそうなことがいくつかわかった。

  • Firefoxはさまざまなデータ(閲覧履歴とか)の管理に、SQLiteを使ってるらしい。
  • SQLiteはPostgreSQLみたいに追記型なので、Vacuumしてあげないとデータサイズがふくらみ続ける。
  • FirefoxはVacuumしないっぽい。
  • SQLiteのデータが肥大化すると遅くなるらしい。

…というわけで、FirefoxのSQLiteのデータを見てみることにした。

「Documents and Settings」->「(ユーザ名)」->「Application Data」(隠しフォルダ)って探していって、さらに「Mozilla」->「firefox」のディレクトリの下にようやく「profiles」ってディレクトリがあって、さらに掘ると、拡張子が「sqlite」なファイルがいくつか見つかった。で、その中の「places.sqlite」が、中でも巨大で450MBくらいになっていた(汗)Firefox3がベータ版だった頃から使ってるプロファイルなので、どこかでうっかりでっかくなってしまったんだろうなぁ…。

で、FirefoxのSQLiteのデータにアクセスするためのFirefox Add-onを入れて、SQLiteのデータをVacuumしてみたが、たいして小さくならず…(汗)

このまま放置しても解決しそうになかったので、一旦、Firefoxを終了させて、勇気を出して「places.sqlite」を削除。で、Firefoxを再起動したら、「places.sqlite」が再び作られたので、とりあえず一安心。あと、終了後のHDD猛烈アクセスがなくなって、軽くなった気がする。(…ただ、起動はしたけど、履歴とか、ブックマークのFaviconとか消えたっぽいので、オススメはしないです)

SQLiteの絡みは、また再発しそうだったので、「SQLite Optimizer」ってAdd-onを入れてみた。これからしばらく経過観察する予定。

NagiosでMySQLのレプリケーションをチェックしたい。

NagiosでMySQLを監視してみたりしているが、これに関しては付属のプラグインを使って実現できた。じゃ、次にMySQLのレプリケーションがちゃんと動いているかどうかを監視しようとすると、Nagiosのサイトからダウンロードできるプラグインではちょっと難しそうだった。(確か、MySQLに対してクエリーを実行してくれるプラグインはあるんだけど、戻り値が数字じゃなきゃダメみたいな感じだったので…。)

そんなわけで、なんかないかなぁと思っていたら、Google CodeにPHPで書かれたNagiosプラグイン集があって、そのなかにMySQLのレプリケーションをチェックできそうな(…まだ見つけただけ)プラグインがあった。ちょっと試してみるか…と独り言。

内製とは言うけれど。~NTTデータの山下社長のインタビュー~

NTTデータの山下社長が日経コンピュータのインタビューに答えている記事を発見。

おぉ、さすがはNTTデータ。山下社長がやろうとしていることが壮大だ。「3倍速の開発」ということで、地球の自転に合わせて、仕様書とかソースコードといった成果物が世界中を飛び回る(…というよりは、地球上で、起きてる人たちが成果物を常にいじくり回してるって感じか…)ようなシステム開発をやるんだそうな。

会社が24時間眠らないで、24時間連続して開発を続けられる仕組みを作りたい。例えば、日本で8時間設計したら、インドかヨーロッパで8時間製造し、それを南米に持っていって8時間試験をする。日本から見ると、朝来ると、自分が設計したソフトが製造され、一通りの試験が終わって手元に来ている。

確かに、実現できれば、システム開発にかかる期間は短くなりそうだし、コスト削減効果も得られるのかもしれないなぁと思う。

…が、しかし(汗)

もし、NTTデータが受託するであろう規模の案件を、ウォーターフォール風の従来の開発プロセスのまま、「3倍速の開発」に放り込んだら、単なるオフショア開発みたいになるんじゃなかろうか。例えば、設計は日本で何ヶ月かかけてやるんだろうし、その後の製造、試験はインドや中国あたりに投げてやってもらうみたいな。…って、たいして速度は上げられなさそうだ(汗)。

ということは、例えば、「設計して、作って、テストして」というプロセスをかなり小さくして、反復するような開発手法になるんだろうな。それも1日分の仕事を世界で分散するとなると、相当、細かくすることになりそう。でも、ウォーターフォール風の開発プロセスに慣れまくってる組織が新しい開発プロセスになじめるのかな。

あと、山下社長は、さりげなく「日本で設計して…」とおっしゃっているが、日本だけが設計工程を担当するよりも、もし、設計工程を世界中で分散できれば、開発速度は上がるんじゃないだろうか。そして、おそらくは製造、試験工程も同じことが言える(…むしろ、製造、試験の方が適用可能性が高いか…)ような気がするわけで、仮に、ウォーターフォール風の開発プロセスを採用するとしても、もし、世界中で、同じ仕事を同じレベルで分担できるのであれば、まさに「3倍速の開発」が可能なのかもしれない。

例えば、製造、試験工程であれば、日本でソースを書いたら、そのレビューとか試験を中国でやってもらって、さらに、インドで追記し、インド追記分のレビュー、試験をヨーロッパでやって、アメリカでさらにソースを追記し、そのレビューを日本でやるといったプロセスを延々と繰り返す…といった感じだろうか。

それは、この辺で山下社長が語っていることかも。

今でも、製造工程に入っている案件で海外に渡しているものはあります。例えば、日本で書いたソースコードを北京の子会社に送ると、北京の方でソースコードのチェックをわーっとやって、ぱっと返してくれる。こういうサービスは社内ではやっているんですよ。

でも、それはあくまでもソースチェッカーのところだけなので、もうちょっとロジックまで追って、びしっとやってみたいじゃないですか。自動生成したものも含めて、全体のロジックがきちっと確認できるとか、業務知識がからむところまで世界各国でやれるようになったら、すごく効率が上がると思う。

もし、そうなってくると、おそらくは設計書は英語で書かなきゃならないだろうし、ソースコードのコメントも、試験報告書もバグ票も英語ってことになるわけで、実は、日本の開発者が英語ができないこと(…あと、もしかすると、ソースコードを書けないこともか?)が、最大の障壁になりそうだが…根が深そうなので、この辺は簡単には解消しないだろうな。

確かに、「3倍速開発」は、NTTデータなどの日本のSIerにとってはチャレンジではあるんだけど、一方、世界的なパッケージソフト屋さんって、普通に、そういう世界分業体制を敷いてそうな気がするけど、どうなんだろうと、ふと思う。

もとい。

山下社長が興味深いことを語ってた。「ずっと気になっていたのだが、そもそもNTTデータの社員は開発をしているのか」という問いに対して、

非常に危機感を持っていて、現状は何しろ内製率が低い。正直にお話すると全部合わせても3割とか3割5分ぐらい。残りは協力会社の方々に手伝ってもらっている。

とのこと。

私、NTTデータで30%~35%も内製してたことに驚いてしまいました(汗)とはいえ、Intramartなんかのパッケージを作ってる部隊の数字も併せて全社平均してるような気がしないでもない今日この頃。。。

内製化率を増やしたいという考えは前からあった。そもそも大昔、電電公社がDIPSというメインフレームを手掛けていた頃は、みんな自分たちの手でプログラムを作っていた。それこそ私なんかも入社してからずっとデータベース担当だったから、設計の中身にまで携わってアセンブラまで使っていた。

…おっと、どっかで聞いたことある話だなぁ(笑)山下社長のような方が内製化を進めて「内製=コスト高」が目に見えるようになった頃に勇退。で、その後の偉い人が「コスト削減」を旗印に、外注率を上げていって勇退。で、次の人が、また危機感を覚えて内製率を上げていくということの繰り返しにならなきゃいいけど。

人生のどこかでプログラムを作る仕事を経験した方が絶対に面白い。一生やれと言われると少し考えるけれど。20代あるいは30代の前半くらいまでに真水の仕事をどれだけやったか、その後の人生の豊かさにつながります。

えーと、そろそろマジメに真水な(汗)コーディングしますか…ね(笑)

«過去の 投稿 新しい 投稿 »