smellman's Broken Diary

クソみたいなもんです

Linux-HA Japan第四回勉強会参加

Linux-HA Japan第四回勉強会に参加してきました。会場に到着するなり、「スタッフですか?」と誤解されたり(前回はスタッフだった)、うさみみを渡されて装着していたり(途中で返した)していました。
今回はわざわざ代休をとっていたってのもあり、荷物が3DS, PSP, ラノベ2冊, Pomeraというとてもやる気がない感じ。3DSでH_Shinonomeさんを3Dで撮影するというよくわからない事をしたりしていました(てへ
とりあえずメモ書きからさらっとまとめてみます。

前説

前回は司会に声優を起用するというよくわからない勉強会でしたが、今回もやらかしてくれました。
前説が丹下桜のフリートーク。
いちおうHigh Availability(高可用性)というテーマの勉強会なのにまったくもって意味がわからないwww

Red Hat High Availability Add-on

Red Hatの中井さんによるプレゼンテーション。RHEL6から登場したHigh Availability Add-on(以下HAAddon)についての解説です。
RHEL6からクラスタ関係がアドオンという形になってHAクラスタが必要な人はHAAddonを購入すれば簡単に導入できるようになったらしい。サブスクリプション価格はそんなに高くなく、1ノードにつき1サブスクリプション必要。
標準で監視できるものはいろいろついているけど、監視スクリプトで無いものは自作する必要がある。と言っても /etc/init.d に置く奴みたいな感じらしい。
特別な要件じゃない限りはアクティブスタンバイ構成(2ノード)を推奨。
DRBDはそもそもRHEL6に入っていない(この件については飲み会で結構文句出てたw)のでサポート外。
共有ディスクにQuorum Diskという領域を作るとQuorum Diskを通してお互いの状態を認識することができる。
HAAddonを構成するサービスはClustor Manager - cman(中身はcorosync)とResource Group Manager - rgmanager の二種類。
リソースを落とすのはぶっちゃけSTONITHなので自殺ではなく他殺。
cmanのfanceはハードウェアの機能を用いて強制再起動をかける。
設定ファイルは /etc/cluster/cluster.conf にすべて記載(中身はXMLっぽかった)、全部の設定ファイルが一つのファイルに集約されているので、マジ便利。設定はGUIでもいじれるみたいだけど、viで書いた方が500倍ぐらい効率的らしいwww
Quorum DiskにあったQuorum計算を用いるとノードではなくネットワーク側に障害が発生した場合にお互いを殺し合わないように過半数ルールを適応するもの。3ノードとかで有効。2ノードの時は相打ちしてしまうので、RHEL6の場合は2つ対処方法がある。一つは早い者勝ち。もう一つはQuorum Diskを通して情報をやりとりする。
デモンストレーション。中井さんが先日cluster fsの勉強会に参加したらしくiSCSIではなくcluster fsに変更した急遽変更したらしいw
HAAddonの関連サービスとして設計フェーズからレッドハットのエンジニアが設計支援をしたり、ノウハウをレクチャーしてくれるビジネス・スタートアップサービスなどがある。担当エンジニアとして中井さんを指名できるらしく、指名料も無いらしいw
ちなみに、High Availability Add-onは読みづらいというので司会の赤井さんが「はぁん」と命名していたw

LifeKeeper

サイオステクノロジー三井さん、大野さんによるプレゼンテーション。HAAddonと同じく商用のHAクラスタソフトウェアLifeKeeperの解説。
ライセンスはノード単位で、32ノードまでいけるらしい(さすがにほとんどやらないけど)。Shared NothingっていうDRBDっぽいのがあるみたい。
まずはApplication Recovery Kitについての解説。
Application Recovery Kitはアプリケーションごとに最適な制御の仕組みを提供している(後述のOracle Recovery Kitの参考)。GUI管理コンソールによるGUIでの管理機能や、I/O Fancingというどうやって自殺するのかという機能を持つ。
Application Recovery Kit自体は監視をしていてだめだったらフェイルオーバーしてサービスを復旧させるという一連の動作(起動、監視、回復、停止)を行い、これらがアプリケーションごとに最適化された設計となっている。
アプリケーションごとに最適化された例としてOracle Recovery Kitは以下のようになる(個人的にはリスナーを監視している部分が最適化された例としてわかりやすかった)。

  • Oracleを監視: プロセス監視、リスナー疎通確認、SQLによるクエリ発行
  • Oracleを回復: DB再起動、リスナー再起動、プロセス稼動状態確認、リスナー疎通確認、クエリ発行
  • フェイルオーバー: DB通常停止、DB強制停止、リスナー停止
  • サービス復旧: ...

Application Recovery Kitは多くのプロダクト向けに提供されている。Oracle, MySQL, PostgreSQL, Postfix, Apache, NFS, LVM, Software RAID(MD), NAS, Sambaなど。マルチパスストレージにも対応。
Generic APKを使うとApplication Recovery Kitでカバーされていないものに対して監視などをすることができる。標準で提供されているもの以上にカバーしたい場合に作成をする。
Generic APKの記述自体はシェルスクリプトなどで可能、単純にexit 1を返せば異常、exit 0を返せば正常となる(つまりなんでもOK)。
GUI管理コンソールは見たらわかるもの。基本的に全ての制御が可能。TwitterJava Appletって書かれてたけど、デモを見るとJava Web Startっぽい?
I/O Fancingについて。スプリットブレイン(両方マスターになって両方からデータ書いて地獄ってやつ)を防ぐために方法を3つ解説。
1つ目はSCSI Reservation方式。SCSIのコマンドのRESERVEという命令を与えて他のノードからアクセスできなくする(アクセスするとReservation Conflictとなる)仕組みを用いた方法。
LifeKeeperでのフロー。まずnode1からRESERVEをかけておく。node2からBUS_RESETをかけてRESERVEを解除して、いきなりRESERVEをしてnode1からアクセスできなくする。node1はReservation ConflictをするのでそれをLifeKeeperが検知して自分を再起動する、つまり自殺する。
SCSI Reservation方式はストレージに応じてサポート可否があるので注意。
2つ目はQuorum / Witness Server。別のサーバ(Witness Server)を用意しておき、そのサーバが多数決を実現する。ストレージに依存しない構成が可能。Witness Server自体の堅牢性や、Standbyからの人為的なmountには対応不可なのが欠点。堅牢にするにはRESERVE+Quorumがよいらしい。
3つ目はIPMIを用いたSTONITH。最近サポートされたもので、他のHAクラスタで使われているハードウェアによる他殺。ただし、相打ちは起こりえるので注意。

Linux-HA

うさみみをつけたNTTデータ先端技術株式会社の森さん(@ksk_haさん)によるLinux-HAのプレゼン。Pacemakerなどのプロダクトについて解説してくれました。
Pacemakerのいいところは4つ。オープンソースである事、いろいろなところで使える事、複雑な構成が組める事、応援キャラがいる事(!?)
事例紹介では4つのパターンを紹介。データベースサーバの冗長化、Hadoopマスターノードの冗長化(詳細は翔泳社のHadoopの本にあるらしい)、3ノードアクティブ構成(落ちたら隣のマシンにサービスを移して継続させる)、N+2構成(一台壊れたらまるごともう一台へサービスを移動させる。Standbyになるのが2台なのでN+2で、12ノードぐらいまでやったことがあるらしい)
Pacemakerのクラスタ構成はリソースと制約条件。Heartbeatの後継という扱いで、Haertbeat v2まで単一パッケージだったものを複数のパッケージに分けた。
Pacemakerのパッケージ構成はPacemakerの生い立ちによるもの。Heartbeat v1は設定が簡単だけど監視がちゃんとできなかった。Heartbeat v2はCRMという機能がついて柔軟になった。PacemakerはHeartbeat v2におけるCRMの部分。PacemakerはHeartbeat v3の代わりにcorosyncが選べるのが特徴。
Pacemakerなどの発展によってクラスタソフトウェアを超えたコンポーネントの共通化がされている。実際、HAAddonのrgmanagerをPacemakerに置き換えたいという活動がある。
Linux-HAでの活動紹介。Linux-HA JapanではPostgreSQL 9.1 SR対応リソースエージェントの開発(詳しくはLinux-HA JapanのMLで)や、KVM対応仮想環境連携機能の開発をしている。本家ではディザスターリカバリ対応や、クラウド対応(ハイパーバイザ上のPackemakerからVM内監視機能)、PacemakerとHAAddonの統合という動きがある。

パネルディスカッション〜HA戦略聞きましょうか〜

丹下桜のフリートークに続き、今度は廻るピングドラムネタからスタートするという狂気。どうしてこうなった。
プレゼンを担当した方々が全員登場して質問に答える形式でパネルディスカッションを行いました。森さんは相変わらずうさみみ装備。
以下適当に抜粋。

  • 新卒二年目だけどクラスタ組んでる。
  • 面白いHA構成はないかという質問で、森さんは仮想IPアドレス200個フェイルオーバーっていう話をうけたことがあるらしい(なんか某ゲーム会社で似たような話なかったっけ?)。中井さんはRedhatに話持ってきてる段階でだいたいお堅い案件らしいので、変な構成はほとんど無いらしい。
  • HAの構成組むときに特に注意するところはどこかって質問したんだけど、その時に僕の事例でタイムアウトの話したらみんなタイムアウトについて語ってしまう罠w
  • プロダクトに足りないものっていうのでログの話がでてきた。中井さん曰く、どういう作業したかっていうのを全部ロギングする機能が欲しいと。これまじで欲しい...
  • Cluster Proが来なかった理由は都合が付かなかったから。
  • 森さん曰く、N+2の構成例はあるけど結局運用管理システムとどうやって連携するかが重要とのこと。
  • 萌え系マーケティングについてLifeKeeperが大変興味を示し(ry
  • 中井さんが「はぁん」っていうのが普通に面白かった
  • 1000円払ってこんなマニアックな勉強会が成立することが意味不明らしいw
  • 今日覚えてかえる事は、「STONITH」と「はぁん」
  • STONITHの使い方「組長をSTONITHする」やめろwww

そして、エンディングも丹下桜でした。なんだよこれwww

飲み会

サイオステクノロジーの発表者ともう一人と飲んでいたのですが、一人がtlec関係者で僕の事覚えてくれていて、もう一人はtlecにいた友達の元同僚で、もう一人は塚田くんクラスタでした。なにこの世間の狭さw あー、僕に某組にいた人の事を聞くのはやめてくださいwww
Linux-HA Japanの人、声優にオムライスネタ演じさせるのはやめろwww
途中からうさみみ装着していた。写真取った人はあとでURL送って下さい。Twitterで@smellman宛によろしくです。
で、朝までクラスタがあるみたいな流れだったので、終電余裕でスルーしたところ、明日も勉強会あると言うことで朝までクラスタが成立せず。しょうがないので、千葉駅から2時間歩いて帰りましたよ...