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

Amazon.co.jpでお買い物をして、MobileEdyで支払うようにして、ケータイでメールを受信したら、iアプリ起動用の文字列がなんとなく壊れてた(これまでもMobileEdyは使っていたんだけど、iアプリが起動できなかったのは初めてだから、なんとなーく送ってくる文字列がおかしいのかな…と)

いつもなら、「お支払いはこちら」ってリンクがあって、それをクリックすればMobileEdyのiアプリが起動してささっと支払い完了となるんだけど、そこにiアプリ起動用の文字列がそのまま表示されてた。

–B:A

TEXT=”お支払いはこちら”

ADF=”http://xxxxxxxxxxx(bitwalletなドメインのURL)”

“P”=”an=xxxxxxxxxxxxxxx(なんかの文字列)”

結局、あがいてもしかたなさそうだったので、「お支払い番号をお届けします」メールに書かれていたURLを開き直して、pay-easyで支払うことにした。

…なんだかなぁ…。

2009/04/30追記：

Edyを運営しているbitwalletのサイトに密かにこんなこと(ドコモ携帯電話でMobileEdy（オンライン決済）をご利用のお客様へ（掲載日：2009年4月8日）)がリリースされていた。

電子マネー「楽天Edy（ラクテンエディ）」 | お知らせ

どうやらDoCoMoのケータイで、「『メールヘッダ情報受信設定』を“付加する”」に設定していると、

ドコモのおサイフケータイでMobileEdy（オンライン決済）をご利用頂く際に、「決済開始メール」の“お支払いはこちら”リンクが正常に機能せず、お支払い画面に移動できない（お支払いができない）

とのこと。対策はこれを”付加しない”に設定するしかないとのこと(汗)

VMWareをインストールしているマシンに新しく仮想マシンを作ってディスクを割り当てたら、ディスク使用率がどーんと跳ね上がったので、余らせておいた領域を割り当ててみることにした。今後、LVMのオンライン拡張とかやるときのためにメモ。

使ったマシンにはCentOS5.2のx86_64版がインストールしてあるのかと思いきや、i386版がインストールしてあった。で、もともと、LVM上のLogicalVolumeには100GBくらいを割り当てていたけれど、このマシンに刺さっているHDDは320GBのものなので、かなり余っている領域があるということで、それをどかっと割り当てることにする。

# df -h

Filesystem サイズ 使用 残り 使用% マウント位置

/dev/mapper/VG00-LV00

95G 46G 44G 52% /

/dev/sdb1 73G 12G 58G 17% /backup

/dev/sda1 99M 24M 71M 25% /boot

tmpfs 2.0G 0 2.0G 0% /dev/shm

で、まずはVolumeGroupとLogicalVolumeの状況確認から。

# vgdisplay VG00

— Volume group —

VG Name VG00

System ID

Format lvm2

Metadata Areas 1

Metadata Sequence No 2

VG Access read/write

VG Status resizable

MAX LV 0

Cur LV 1

Open LV 1

Max PV 0

Cur PV 1

Act PV 1

VG Size 290.17 GB

PE Size 8.00 MB

Total PE 37142

Alloc PE / Size 12500 / 97.66 GB

Free PE / Size 24642 / 192.52 GB

VG UUID f4MKYy-SAu8-Bh67-92QF-63w4-QgPa-dUcJpt

とりあえず、VGには余っている領域(Free Size)が192GBくらいあることがわかった。

# lvdisplay /dev/mapper/VG00-LV00

— Logical volume —

LV Name /dev/VG00/LV00

VG Name VG00

LV UUID 2q71Yr-RxYQ-P3zs-FKUE-hvBq-wlIZ-SfLJDU

LV Write Access read/write

LV Status available

# open 1

LV Size 97.66 GB

Current LE 12500

Segments 1

Allocation inherit

Read ahead sectors auto

– currently set to 256

Block device 253:0

LVはdfで見たように、だいたい100GBくらいありますね…と。

で、ここからLVのサイズをぐぐっとVG一杯まで広げていくわけだけど、きっちりサイズ指定して、微妙なあまりを発生させないようにしたいが、拡張コマンドに「192.52GB」とか指定すると、ちょこっと余ったりしそうなので、エクステントの数で指定して大きくしてみる。

上のVGの空き容量の横に「Free PE」って書いてあって、それが空いてるエクステントの数のようだ。というわけで、こんな感じでLVを広げてあげる。

# lvextend -l +24642 /dev/VG00/LV00

Extending logical volume LV00 to 290.17 GB

Logical volume LV00 successfully resized

これで、LVのリサイズが完了したけれど、ファイルシステムも併せて広げておかないと、使える領域は増えないので、ファイルシステムもリサイズする。容量指定しないときは、パーティションのサイズ、つまり、今回では、リサイズ後のLVのサイズになるようだ。

# resize2fs /dev/mapper/VG00-LV00

resize2fs 1.39 (29-May-2006)

Filesystem at /dev/mapper/VG00-LV00 is mounted on /; on-line resizing required

Performing an on-line resize of /dev/mapper/VG00-LV00 to 76066816 (4k) blocks.

The filesystem on /dev/mapper/VG00-LV00 is now 76066816 blocks long.

で、このresize2fsは、マウントしたままで空き容量ががつがつ増えていくので、上記のコマンドを発行した後で、dfコマンドで何回か確認すると、/dev/mapper/VG00-LV00の空き容量が増えていき、使用率が下がっていく状況がつぶさに見られた。

resize2fsが完了した後、改めて確認すると以下のような感じだった。

# df -h

Filesystem サイズ 使用 残り 使用% マウント位置

/dev/mapper/VG00-LV00

282G 46G 221G 18% /

/dev/sdb1 73G 12G 58G 17% /backup

/dev/sda1 99M 24M 71M 25% /boot

tmpfs 2.0G 0 2.0G 0% /dev/shm

とりあえず、使える領域が増えたってことでめでたしめでたし。…てか、何で最初から領域を割り当ててないんだろうなぁ(汗)

元ネタはウォールストリートジャーナルのようで。

「「IBMがSun買収に向けて交渉」の報道」(http://www.itmedia.co.jp/news/articles/0903/18/news088.html)から引用。

米IBMが米Sun Microsystemsを買収する交渉を進めていると、Wall Street Journalが情報筋の発言として伝えた。

で、IBMが身を乗り出したのかと思いきや、実はSun側からの打診らしい。

Wall Street Journalによると、ここ数カ月の間、Sunは多数の大手IT企業に身売りの話を持ちかけていたという。米Hewlett-Packard（HP）はその話を断ったと同紙は伝えている。

Sunの持ち物で売れそうなものって考えると、ぱっと思いつくキーワードは

• SPARC
• Solaris
• MySQL
• Java

…ってところだろうか。IBM側から見てみれば、Java以外は競合製品(Power/AIX/DB2)を既に持っているわけだから、Sunに魅力を感じるのだろうかという気がしないでもない。ただ、Sunというライバルがいなくなることと、その顧客を手にすることは魅力的なのかもしれないが、前者はHPやDELLにとってもメリットを与えてしまうことになる。

むしろ、自社のx86サーバでSolarisのサポートを行うことを発表したHP(「HPとサン、Solaris搭載のHP ProLiantサーバに関するパートナーシップ契約を締結」http://jp.sun.com/company/Press/release/2009/0227.html)が、Sunの身売り提案を蹴ったというのが事実なら、それはそれで興味深いような気がする。自社のx86サーバユーザにUNIXの選択肢を提供するのには、SunのSolarisを使ってもいいけど、Sunを抱えるのはヤダってことだろうか(HP-UXをx86に移植したりはしないのね…笑)

むしろ、ハイエンドサーバの世界に進出したそうなDELLがSunに触手を伸ばしそうな気がしたんだけど、どうなんだろうか。PoweEdgeでSolarisをサポートした上で、PowerEdgeの最上位機種より先のスケールアップにSPARCってなしなのかな。そういえば、Solaris+SPARCで、Sunのカウンターパートになっている富士通はそれどころじゃないか(汗)

私が始めて触ったUNIXがSolarisだったせいか、SunのロゴがかつてのDECやCompaqのロゴのように過去のモノになっていくとしたら、それはちょっと忍びないような気がするなぁ、個人的に。

追記：

最初は日経の記事へのリンクを張ってましたが、リンクポリシー的にまずそうだったので、ITmediaの記事に変更。

以前も書いたけれど、Thunderbird2.0.0.19で、フォルダの中に何千通かメールが入っている状態で半分ぐらいのメールを一気に削除する(ゴミ箱に移動)すると、順調に削除件数が増えていくけれど、最後の最後でCPUとメモリを大量消費し始めて、メモリを食い尽くして死ぬという事象にまた直面した。

ちょびちょび消すしかなさげ…。

NTTデータ、「Doblog」の障害要因を説明。一部記事は復旧見込み

NTTデータのblogサービス「Doblog」がシステム障害で1週間以上アクセス不能になっている問題で、NTTデータが状況を明らかにしたらしい。上記の記事によると、

• データベースサーバーとバックアップサーバーのほか、Webサーバー2台とアプリケーションサーバー2台の計6台のサーバーを使用している。
• RAID 5を構成するデータベースサーバーで、6台のうち2台のHDDに発生したディスク障害。
• バックアップサーバーにも障害が波及。

ということのようだ。また、NTTデータのWebサイト(no title)によれば、

サービス開始時点から2008年8月4日の未明時点までのデータについては、復旧の見込みがあることを確認できております。

と言っているものの、

2008年8月4日から2009年2月8日朝までのデータに関しましては、完全な状態ではないものの、できる限り復旧させるよう取り組んでおります。

とも言っていて、データがロストした可能性を示唆している。

ま、RAID5でディスク2本が故障するというのはレアなケースだと思うが、絶対に起こりえないことではないと思う(RAID5って、HDDが1本壊れたら、新しいディスクを指して、rebuildかけてるときって、他のHDDにもかなりのアクセスが発生しそうだし)そういうリスクに備えて、dailyとまではいかないにしても、せめてweeklyくらいでデータのバックアップを取得しておく必要性がある…が、それを取得していたバックアップサーバでもディスク障害が起こったってことだろうか。

バックアップサーバの障害まで考えると、なんかとんでもない確率でアタリを引いちゃってるような印象を受けるなぁ…。