別冊あんどりゅーくん(第2号)


7月14日(金)と15日(土)に開催されたOSC2011 Kansai@Kyotoに行ってきました。
クリアフォルダ250枚と団扇300枚は2日目の
終了3時間前くらいになくなってしまいました。

次回のOSC@名古屋でも配布する予定なので
ご希望の方はお早めにブースまでお越しください。

 

 

 

 

 

 

 

 

 


 

また、猛暑にもかかわらず、2日目11時からのセミナーには40名の方に参加していただきました。
講師は「あ、eject の方?」でお馴染みの、たなかさんでした。おつかれさまでした!
当日の資料はこちらからダウンロードすることができます。

今回は、ブースでお留守番をしていたときにいただいた質問と、
セミナーの最後にいただいた質問をおさらいしてみようと思います。


ブースでいただいた質問

(1) Pacemakerは仮想環境でも使用できるか?
(2) 必要なNICの本数は?
(3) 事例は公開されているか?
(4) 将来の目標は?
(5) 読み方はピースメーカー?ペースメーカー?
(6) BSDで使えるか?


(1) Pacemakerは仮想環境でも使用できるか?


使えます。

OSC関西@京都のセミナーでは仮想環境でデモを行いました。
資料にも「本日のPacemakerデモ環境」として仮想環境でのクラスタ構成が紹介されています。
仮想環境の構成には

  • ゲストOSにPacemakerをインストールするパターン
  • ホストOSにPacemakerをインストールするパターン

の2パターンがあります。

ゲストOSにPacemakerをインストールするパターンは、ゲストOS≒物理サーバです。

ホストOSにPacemakerをインストールするパターンは、ゲストOSを「リソース」として
VirtualDomain RAで監視します。
ゲストOSのマイグレーションとかもできます。
このパターンでは、ゲストOS上で起動している特定のプロセスは監視できないので、
ホストOSにもゲストOSにもPacemakerをインストールする多層式の構成となる場合もあります。


(2) 必要なNICの本数は?

ノード間で生死を確認しあうためのインターコネクトLANは絶対に必要です。
なので、インターコネクトLAN用に最低でも1本は必要です。
ただし、インターコネクトLANは2本以上用意して冗長性を確保することが推奨されています。
その他にも、WebサーバやDBなど、外部からアクセスするための仮想IPアドレスが必要なサービスの場合は仮想IP用のサービスLANも必要となります。

サービスLANは2本以上用意して冗長性を確保することが推奨されています。
サービスLANを冗長化する場合はbondigを利用してください。

そういえば、インターコネクトLANはbondingしなくていいの?と思われるかもしれませんが、
メッセージングレイヤにHeartbeatを使用する場合は、bondingでもbondingでなくてもどっちでもいいです。

ただし、Corosyncを使用する場合はbondingを使用したほうがよいかもしれません。
Corosyncは複数のインターコネクトLAN構成で、接続が切れたり繋がったりしたときの
「表示系」がまだちょっと弱かったような気がする。。

動作は問題ないはず(たぶん)。
最近は直ってきたのかもしれません。v1.4でたし!?

一方、メッセージングレイヤにHeartbeatを使用する場合は、bondingを使わない場合が多いような気がします。
ha.cfにインターフェース名を複数書けばいいだけの話しなので、わざわざbondingにしなくてもいいよねえ、というかbondingドライバのバグにはまっちゃうとヤダとかそういうのもあったような気がする。

インターコネクトLAN、サービスLANの他に、管理者や運用担当者、もしくは運用管理ツールがPacemakerの実行状況などを確認するための管理LANも別系統であると便利かもしれません。
管理LANはそれほどがつがつ使うこともないはずなのでインターコネクトLANまたはサービスLANと兼用でも問題ありません。

DRBDも組み合わせて使用する場合は、DRBDの同期LANも必要となります。
DRBDは、一つの同期リソースにつき、1本の同期LANしか設定することができないので
bondingで冗長化することが推奨されています。
同期リソースが複数ある場合は、同期LANの本数を増やす、もしくは
1本の同期LANで複数のポートを使用することになります。

というわけで

最小構成(合計1本)

  • インターコネクトLAN    1本

冗長構成(合計7本)

  • インターコネクトLAN    2本
  • サービスLAN               2本(bondingで1本に集約)
  • 管理LAN                     1本
  • DRBDの同期LAN          2本(bondingで1本に集約)

となります。


(3) 事例は公開されているか?

Linux-HA Japanの公式サイトで事例の公開は行っていません。
お隣にブースを出していただいた株式会社サードウェアさんのWebサイト「Linux-HA (DRBD) ユーザ事例」からDRBD関連の事例をダウンロードすることができます。
Linux-HA Japanの公式サイトにも事例を公開していきたいのですが、いろいろと大人の事情で難しいようですね…。
「公開しても問題ありません」という案件や実際に稼動しているシステムがあれば、ぜひメーリングリストまでご連絡ください。

 

(4) 将来の目標は?

ちょっとのけぞりましたが、これって今後のロードマップってことですね。

一瞬、小学校の卒業文集的なナニカかと思いましたよ…。
ちなみに、あんどりゅーくんのつくったロードマップはこちら。

ロードマップというより、これから実装していきたい機能の落書き帳的なものなので、実装予定期日は決まっていません。
他にも

  • 仮想環境対応(キーワード:Matahari)
  • 大規模クラスタ対応

などがメーリングリストで話題になっています。

 

(5) 読み方はピースメーカー?ペースメーカー?

ペースメーカーです。
ピースメーカーだと Peacemakerになっちゃう気がします。Pacemakerです。


(6) BSDで使えるか?

残念ながらBSDは未踏領域です。人柱大募集です。
Linux-HA Japan では、RedHat, CentOS用のRPMを作成していますが、
あんどりゅーくんの管理している clusterlabs からは
Fedora, openSUSE, EPEL用のRPMがダウンロードできます。

Debianは「はらくん」がパッケージングしてくれるらしいよ。

はらくん(高校2年生)

めっさいじられてますけど。

Pages: 1 2

Comments are closed.