fukuoka.pm第一回定例会開催

いやー　楽しかった。
何がって？
fukuoka perl mongerが開催されたんだよ。

福岡でperlでやっている人が今まで会った事なかったから、非常にうれしかった。
言い過ぎかもしれないけど夢のようでした。
perl関係の勉強会参加するにはshibuya.pmなど東京の方にいかないとなかった（金かかる）。
それをperl歴５年間、思い続けたんだよね。

ではfukuokaとshibuyaとの違いをはっきりしておきたい。
fukuoka.pmでは飲み中心。
shibuya.pmでは技術中心。

fukuokaだめじゃん。

fukuoka.pmとしてはまだほやほやであるが、技術力＋さまざまな事例からのベストプラクティス構築＋アウトプットしていければと思う。

がんばるばい。

クラスタリングについて

drbd,gnbdなどの記事を上げましたが、なんでそんなことしてるんだという人がいます。ここでクラスタリングについての必要性について記事を書こうと思います。
私はサービスの突然の停止を何回も経験してきました。

まず一つにraid 1の方系運転に気がついていなくて落ちてしまうケース。
これは気がつけばいい話、と思われるかもしれませんが、これには引き継ぎなどによる情報伝達不足などのケアレスミスなどでも起こりえますし、エラー通知などの構成がハードウェアーによって違っていたりして通知されないケースも考えられます。
２つ目にディスク論理エラー(kernel panic)。
論理なのでraidなんて”関係ねー”です。fsckで修復をかけるとまったくディスク領域にアクセスできなくなってしまったりします。怖い怖い
３つ目にハードウェアーの故障
壊れやすい機器として、１位、HDD、２位、電源、３位、メモリ？！っとさまざまです。某D○○○なんかはたちがわるくて運用一週間後とかに初期不良なんかありましたね。
４つ目にメンテナンス中のケアレスミスによるデータ消去またはSQLインジェクションなどのデータ改ざんなども考えられます。

これらの障害要因があるなかで保守コストは一緒というのは割に合わなすぎです。しかもこれらが起った時点で自動的に責任がプログラマーに遷移します。前からいってたじゃんっていうのはいいわけらしいです。

そこで冗長構成をサービスの必須条件にすることで上記の問題を緩和することができます。つまりよく眠れるということです。

しかしそんな予算もって来れないよっとおっしゃる方もいるでしょう。確かにそうです。想定できないものにお金を払うことは現実的には厳しいですからね。

それではどうすればいいか。それはなぞです。というかいい方法を教えてください。

私のやり方は自腹を切るもしくはなんとか説得するということしか思いつきませんでした。

しかし、技術がなければ、説得も運用実績もつくれません。そこで私はこのブログでレポートを書きながら何かサービスを立ち上げ、運用実績を作って行こうと思います。

なんか不平不満みたいになってしまいました（＾＾;;

ipod touch 一週間後の感想

一週間前にipod touch+leopardをGETしました。

さすがに面白い。UIがいい。洗練されています。

なにより、bsdが使えちゃうところ、簡単なアプリならperlで組めちゃいますね。
apiは用意されていませんが、safari上でlocalhostにアクセスすればlocalweb上でいろんなことができそう。夢が広がりますね。

さて、導入したアプリなんですが、


iphoneから

• maps
• mail
• memo
• 天気
• 株価

（iphoneのパッケージから取ってきたのにちゃんと日本語化されちゃってる。）

• installer(JailBreakMe)から
• NES（遊び道具）
• VNsea(VNCViewer・・・用は遠隔GUIを操作できる)
• Term-vt100(bsdシステムへのターミナル)
• PDFViewer(PDFを見るやつ)
• mobileJuhu(モバイルjaiku　使い方がまだわかってない)

こんな感じです。
これらのインストールで困ったなって方がいたらコメントください。

わかる範囲でお答えします。

clusterまでの道のり：drbd編

drbdによるactive/active+gfsを試してみます。わかる人はわかると思いますが、この方法は失敗していますので参考にしようとしている人は見ない方がいいかもしれません。

yum install -y cman lvm2 lvm2-cluster gfs2-utils cluster-cim ricci luci

luci_admin init

yum install -y drbd kmod-drbd

#マシンを再起動
/bin/reboot

#drbd構成を定義
$vi /etc/drbd

この辺はどこでも紹介されているのでこちらでは紹介しません。

#ディスク内に情報を書き込む（何の情報かは不明）
$drbdadm create-md r0
v08 Magic number not found
v07 Magic number not found
About to create a new drbd meta data block
on /dev/data/data1.

==> This might destroy existing data! <==
Do you want to proceed?
[need to type 'yes' to confirm] yes
Creating meta data... initialising activity log
NOT initialized bitmap (32 KB)
New drbd meta data block sucessfully created.
$/etc/init.d/drbd start

経験エラー： >Device has a net-config (use disconnect first)
hostnameが同じだとだめみたい。
/etc/sysconfig/network
-hostname localhost.localdomain
+cm*
$/etc/init.d/network restart

$drbdadm primary all

経験エラー：
State change failed: (-2) Refusing to be Primary without at least one UpToDate disk
Command 'drbdsetup /dev/drbd0 primary' terminated with exit code 11
drbdsetup exited with code 11
解決：
すでにファイルシステムを作成したなどディスクに書き込まれている場合だと、上書きをしないといけないようです。

$drbdsetup /dev/drbd0 primary -o
or
$drbdadm -- --overwrite-data-of-peer primary all

同期が始まります。

両サーバーをactive/active構成にします。

mkfs.gfs2 -p lock_dlm -t cluster1:drbd0 -j 2 /dev/drbd0
mount -t gfs2 /dev/drbd0 /mnt

chkconfig ricci on
chkconfig luci on
chkconfig cman on
chkconfig clvmd on

まとめ。

基本的にdrbdによるActive/Active構成であってもGFS上では不都合が多いようです。
・同じファイルには片方からしか扱うことができません。
　　下手に触ってしまうと書き込みプロセスが書き込みロジックで停止してしまいました。Lockが効いており、プロセスも正常に動作していると思い込み、書き込みを待っているようです。
・方系のダウンを実践してみたのですが、lockがinternal(サーバー自身が管理)なため、一度落としてしまうと正常なサーバーのファイルシステムを落とし、drbdadm create-md r0を実行しなくてはいけません。

よってdrbdによるactive/active構成は難しいということがわかったのですが、本題はここではありません。
gnbd+clvm+gfs+cman・・・を実践したいと思います。

ためにならない情報開始

遅ればせながらブログをはじめようと思う。

今更なぜブログを始めようと思ったのか。それは技術の溜め込みすぎで公開用にまとまっていない情報が私のマシン（相棒）に入っており、このままだったらせっかく時間をかけて溜め込んだ情報が台無しじゃんと思い、メモ用紙代わりに残していこうと思っているからです。

っと言っても最新の情報などありません。基礎的な情報だったり、ほかの情報に比べると屁です。（笑）

技術情報についてはいっさい責任を老いかねますのでこの情報による不具合などのご報告はご遠慮いただきたい。

よろしくおねがいします。