3 / 612345...Last »

Nightlyビルド公開します

Pacemaker本家コミュニティにて、開発最新版のPacemaker 1.1.10 がリリースされました。本バージョンに大きな問題がなければ、Pacemakerはメジャーバージョンアップするとの予告が出ており、1.1.10 は重要なバージョンと言えそうです。

これを記念して、Linux-HA Japanでは、いち早く最新のパッケージを使ってみたいという方のために、RHEL6(x86_64)および互換OS向けのNightlyビルドを公開したいと思います。

http://linux-ha.sourceforge.jp/nightly/

ビルド対象のパッケージは、Pacemaker 1.0系(安定版)、1.1系(開発版)、および周辺コンポーネントです。

Nightlyビルドには、Pacemaker 1.0系と1.1系両方のコンポーネントが混在しているため、どのコンポーネントを組み合わせればよいかわからない人は以下を組み合わせてみてください。

Pacemaker 1.0系 (安定版)

cluster-glue . . . → Read More: Nightlyビルド公開します

Fedora 19 上でPostgreSQL ストリーミングレプリケーションのクラスタリング

先日リリースされたFedora 19には、Linux-HA Japanで開発したPostgreSQLのストリーミングレプリケーションのクラスタリング機能がついに同梱されました。

Pacemaker のバージョンも開発版で比較的新しい 1.1.9 が同梱されているので、これを使ってPostgreSQLストリーミングレプリケーションのクラスタリングに挑戦してみたいと思います。

環境

今回、Fedoraのインストール手順方法は割愛しますが、以下の環境を用意してください。
※ 超スモール構成のため、商用での利用は推奨しません。信頼性を確保するには、Pacemaker用やレプリケーション用の専用LANを準備し、STONITHの導入を検討してください。

fe19-sr

  • ホスト名は、52-fe19 と 53-fe19 とします。 (単に私の手元の環境で使っているホスト名で、深い意味はありません。。。)
  • 皆大好きなSELinuxやファイアウォールは無効にしておきます。
  • 設定が複雑になるので、ネットワーク監視やディスク監視は行いません。
  • 超スモール環境のためネットワークは2本で挑戦します。なお、よく悪者扱いされるNetworkManagerは停止し、IPは手動で設定してください。また、/etc/hostsにホスト名を定義するとトラブル可能性があるので定義しないでください。
    • 1本目用途 : PostgreSQLへのアクセス用+Pacemaker通信用
      • 52-fe19のIP 192.168.0.152
      • 53-fe19のIP 192.168.0.153
      • PostgreSQLアクセス用の仮想IP(vip-master) 192.168.0.252
    • 2本目用途 : レプリケーション用 + Pacemaker通信用
      • 52-fe19のIP 192.168.1.152
      • 53-fe19のIP 192.168.1 .153
      • レプリケーション用仮想IP(vip-rep) 192.168.1.252

インストール

両ノードに、yumを使って必要なパッケージを一気にインストールし、PostgreSQLのアーカイブディレクトリを作成しておきます。(両ノードで実行)

# yum install postgresql-server pacemaker corosync pcs
読み込んだプラグイン:langpacks, refresh-packagekit
(省略)
完了しました!
# su - postgres
$ mkdir /var/lib/pgsql/pg_archive

PostgreSQLの設定

PostgreSQLのデータベースクラスタを作成します。(52-fe19上で実行)

$ cd /var/lib/pgsql/data
$ initdb
データベースシステム内のファイルの所有者は"postgres"ユーザでした。
このユーザがサーバプロセスを所有しなければなりません。
(省略)
成功しました。以下を使用してデータベースサーバを起動することができます。

    postmaster -D /var/lib/pgsql/data
または
    pg_ctl -D /var/lib/pgsql/data -l logfile start

postgresql.conf ファイルに以下を設定します。その他の設定はデフォルトのままで構いません。なお、synchronous_standby_names パラメータが設定されている場合は、必ずコメントアウトして無効にしておいてください。(52-fe19上で設定)

listen_addresses = '*'
wal_level = hot_standby
synchronous_commit = on
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/pg_archive/%f'
max_wal_senders=5
wal_keep_segments = 32
hot_standby = on
restart_after_crash = off
replication_timeout = 5000
wal_receiver_status_interval = 2
max_standby_streaming_delay = -1
max_standby_archive_delay = -1
synchronous_commit = on
restart_after_crash = off
hot_standby_feedback = on

pg_hba.conf ファイルを設定します。(セキュリティは全く考慮していません) (52-fe19上で設定)

host    all             all     127.0.0.1/32        trust
host    all             all     192.168.0.0/16      trust
host    replication     all     192.168.0.0/16      trust

PostgreSQLを起動します。(52-fe19上で実行)

$ pg_ctl -D . start
サーバは起動中です。

53-fe19 にデータをコピーします。(53-fe19上で実行)

# su - postgres
$ pg_basebackup -h 192.168.0.152 -U postgres -D /var/lib/pgsql/data -X stream -P

手動でレプリケーション接続できるか試します。53-fe19に/var/lib/pgsql/data/recovery.confを作成します。

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.152 port=5432 user=postgres'
restore_command = 'cp /var/lib/pgsql/pg_archive/%f %p'
recovery_target_timeline = 'latest'

53-fe19のPostgreSQLを起動します。(53-fe19上で実行)

$ pg_ctl -D /var/lib/pgsql/data/ start

52-fe19上で以下のSQLを使ってレプリケーションの状態を確認します。

$ psql -c "select client_addr,sync_state from pg_stat_replication;"
  client_addr  | sync_state 
---------------+------------
 192.168.1.153 | async
(1 行)

無事レプリケーション接続できました。では、一旦両ノードのPostgreSQLを停止します。(両ノードで実行)

$ pg_ctl -D /var/lib/pgsql/data stop
$ exit

Corosyncの設定

corosyncの設定ファイル/etc/corosync/corosync.confを用意します。(両ノードで作成)

quorum {
           provider: corosync_votequorum
           expected_votes: 2
}
aisexec {
    user: root
    group: root
}
service {
    name: pacemaker
    ver: 0
    use_mgmtd: yes 
}
totem {
    version: 2
    secauth: off 
    threads: 0
    rrp_mode: active
    clear_node_high_bit: yes 
    token: 4000
    consensus: 10000
    rrp_problem_count_timeout: 3000
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.0.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }   
    interface {
        ringnumber: 1
        bindnetaddr: 192.168.1.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }   
}
logging {
    fileline: on
    to_syslog: yes 
    syslog_facility: local1
    syslog_priority: info
    debug: off 
    timestamp: on
}

Corosyncを起動します。(両ノードで実行)

# systemctl start corosync.service

/var/log/messages に以下のようなメッセージが出ればcorosyncの起動成功です。

[MAIN  ] main.c:275 Completed service synchronization, ready to provide service.

ちなみに私の環境では、52-fe19でこのログが出続けていますが、原因はよくわかりません。。。とりあえず動いているようなのでこのまま先に進みます。(おぃ! )

Incrementing problem counter for seqid 2087 iface 192.168.0.152 to [1 of 10]

次はPacemkaerの起動・設定に入っていきます。

crmコマンドを用いたPacemaker のリソース設定方法

Pacemaker で制御するリソースを設定するには、crm コマンドを使用します。以下にcrmコマンドの基本的な使い方を記述します。前提として、CentOS 5上にPacemakerのインストールが完了し、Pacemakerが起動しているとします。クラスタ制御部は、Corosync、Heartbeat どちらでも構いません。

まず、crm コマンドを起動します。(以下太字が実際に入力する部分です)

[root@pm01 ~]# crm
crm(live)#

リソースの設定モードに入ります。

crm(live)# configure
crm(live)configure#

現在の設定をshowコマンドで確認します。何も設定をしていないので、表示されるのはノード名(サーバ名)と、バージョン、使用しているクラスタ制御部名(以下の例ではHeartbeat3を使用)だけです。

crm(live)configure# show
node $id=”0c140f90-7de3-438f-b1b5-3b9722bbde21″ . . . → Read More: crmコマンドを用いたPacemaker のリソース設定方法

Pacemaker-1.0 インストール方法 CentOS 5編

CentOS5.5 x86_64 にPacemakerをインストールする方法は、主に以下の4つがあります。

ここでは、下記の1, 2 の方法について記述します。

yum を使ってネットワークインストール

Pacemaker本家(clusterlabs) の yumのリポジトリを使用

インターネット接続必須
最新の安定バージョンをいち早く使ってみたい人向け (?)

Linux-HA Japan 提供のローカルリポジトリ . . . → Read More: Pacemaker-1.0 インストール方法 CentOS 5編

Matahari Project の現状について

しばらくさぼっていましたが9月分のリリース情報をまとめて投稿します!

2012年9月3日にMatahari Projectから悲しいお知らせが(TДT)

As will be evident to those of you who have . . . → Read More: Matahari Project の現状について

JPUG 第24回しくみ+アプリケーション勉強会 セミナー資料公開

2012/9/29 開催の第24回PostgreSQLのしくみ分科会、アプリケーション分科会への参加ありがとうございました。
当日の発表資料、”HAクラスタでPostgreSQLを高可用化(後編) 〜レプリケーション編〜”を公開します。

PostgreSQLを高可用化(後編) 〜レプリケーション編〜(PDF)

発表内容転記 : 『オープンソースのHAクラスタソフトPacemakerに、PostgreSQLのストリーミングレプリケーション構成をクラスタリングする機能がマージされました。この新機能の概要、および動作について解説いたします。』

前編の資料はこちらです。

 

English version . . . → Read More: JPUG 第24回しくみ+アプリケーション勉強会 セミナー資料公開

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

先日、Pacemaker 1.1.7のリリースノートを紹介させていただきましたが
そのなかで気になっていた項目を調べてみました。

  • 順序制約の新機能について
  • 複数STONITHの設定について
  • 故障時にフェイルカウントがインクリメントされない
  • on-failの設定が反映されない

順序制約の新機能について
順序制約にrequire-allを設定すると、次のような動作が可能となります。
例) リソースAもしくはリソースBのいずれかが起動していればリソースCは起動することができる。

今回は、A,Bという2個のリソースに対してrequire-allを設定しましたが、3個以上のリソースに対しても同様の条件を設定することができます。

設定例)

<resources>
 <primitive class="ocf" id="A" provider="pacemaker" type="Dummy"/>
 <primitive class="ocf" id="B" provider="pacemaker" type="Dummy">
 <primitive class="ocf" id="C" provider="pacemaker" type="Dummy"/>
</resources>

<constraints>
 <rsc_order id="order01">
   <resource_set id="require-all-set-1" sequential="false" require-all="false">
     <resource_ref id="A"/>
     <resource_ref id="B"/>
   </resource_set>
   <resource_set id="require-all-set-2">
     <resource_ref id="C"/>
   </resource_set>
  </rsc_order>
</constraints>

えーっと、いつもの便利なcrm shellさんは、まだrequire-allに対応していません!
というわけで久しぶりにXMLでごりごり設定してみましたが、require-allはまだちょっと微妙だなーということがわかりました。
上記の設定を使用して、1ノードで動作を確認してみると確かに期待通りに動いています。
でも、2ノードで試してみると、colocationとかlocationを設定していないのでAとBが別のノードで起動しちゃうんですよね。
AとBとCは同じノードで起動させたい場合が多いんじゃないかなと思うんですがcolocationを設定するとrequire-allが効いてませんでした。
これはまだちょっとお披露目程度の機能だと思っていたほうがよいですね。

月刊あんどりゅーくん(3月号)

今年は閏年だから一日得したーと思っていましたが
やっぱ二月は逃げ足はえーなおいまてこら
ということで、今月もリリース情報と知恵袋です。

リリース情報

  1. Corosync 1.99.x
  2. LCMC 1.3.0
  3. libqb version 0.10.x
  4. fence-virt 0.3.0

1. Corosync 1.99.x

Corosync v2に向けたベータ版がほぼスケジュール通りにリリースされています。

The schedule:
Alpha January 17, 2012 version 1.99.0
Beta January 31, 2012 version 1.99.1
RC1 February 7, 2012 version 1.99.2
RC2 February 14, 2012 version 1.99.3
RC3 February 20, 2012 version 1.99.4
RC4 February 27, 2012 version 1.99.5
RC5 March 6, 2012 version 1.99.6
Release 2.0.0 March 13, 2012 version 2.0.0

アルファリリース(1月24日)
Corosync 1.99.0 (Alpha release of Needle 2.0) available at ftp.corosync.org!

Migrate to libqb (https://github.com/asalkeld/libqb/wiki)
———————————————————
– Common features like IPC is now shared between Corosync and other
projects, so it’s probably better tested.
– Corosync is now single threaded (with exception of logging), so no
longer problems with deadlock, race conditions, … Also IPC speed
should be better

  • IPC(プロセス間通信)のライブラリとしてlibqbを採用しました。
  • ログ出力以外の処理はシングルスレッドで実行します。
    このためデッドロックや競合は発生しません。IPCの速度も向上しているはずです。

OBJDB/CONFDB replaced by ICMAP/CMAP
———————————–
– Significantly simplified API

  • OBJDB/CONFDBはICMAP/CMAPへ変更されました。
    なんかよくわかんないですけど、「simplified」って書いてあるからまあいいかな…?

Plugins are gone
—————-
– For creators of plugins it means, that code need to be built on top of CPG.

  • CPG(Closed Process Group) APIを使用して、プロセスグループの単位でメンバシップを管理します。
    なお、現在のプラグインインタフェースは廃止されます。

Votequorum improved
——————-
– Votequorum now contains almost all functionality of CMAN quorum
– Many new features implemented (auto_tie_breaker, wait_for_all, …)

  • クォーラム機能のアレコレが取り込まれています。
    2.0.0がリリースされたら動作検証してみないと!

    この後も続々とベータ版がリリースされていますが、やはりクォーラム関連の機能追加は
    今回のリリースにおける大きな目玉の一つです。

あれ?
1.99.3がどっかいったような気がするけどそれはきっと気のせいだ。

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

Pacemaker Cloud v0.5.0の動作確認をしてみた \(^o^)/

Pacemaker Cloud Projectは、クラウド環境におけるHA機能の実装を目的としたプロジェクトです。

Pacemaker Cloudはクラウドを構成する各コンポーネントの故障や孤立を検知して
コンポーネントの再起動を実行します。
また、コンポーネントの再起動処理が指定回数以上失敗した場合は
下位レイヤへ故障をエスカレーションする機能も実装予定です。

ソースコードはこちらで公開されています。

ちょっと楽しげな雰囲気ですけど、ナンナンデスカコレハ?ということでキーワードをちょっと調べてみました。

  • Assembly

仮想マシンや監視エージェント、アプリケーションなどの集合体。
VM(Virtual Machine)と、ほぼ同義です。
監視エージェントは後述のMatahariを想定しています。
アプリケーションは、Pacemakerでいうところのリソース(=サービス)ですね。
DBとかWebサーバとかファイルシステムとかサービスを提供するためのアプリケーションです。

  • Deployable

Assembliesの集合体です。
異なる物理マシンで起動するVM(=Assmbly)も同じDeployableに含めることができます。

  • Deployable Policy Engine(DPE)

Deployableを制御するコンポーネントです。

  • Cloud Policy Engine(CPE)

クラウド上で実行される仮想環境間の依存関係や可用性を保証するコンポーネントです。
Deployableの起動 停止処理を実行します。

  • Matahari

システムを管理・監視するためのAPIの集合です。
Pacemakerのlrmdに似ています。
ノードおよびリソースの起動停止、監視処理を実行します。
これはPacemaker Cloudとは別のプロジェクトです。
ソースコードはこちらで公開されています。

  • Pacemaker Cloudのざっくりしたイメージ

正常起動時 → Assemblyがサービスを提供
Assemblyが提供しているサービスが故障 → DPEがサービスを再起動
Assembly(=仮想マシン)故障 → DPEが仮想マシンを再起動
サービスや仮想マシンの再起動が指定回数以上失敗 → DPEが別のAssemblyを起動
DPEが故障 → CPEがDPEを再起動(このときAssemblyは再起動しないはず)


んー、まだちょっとふらふらしたイメージなので、実際に環境構築をして動作を確認してみることにしました。

環境構築の手順は以下のサイトを参考にしました。
http://ahsalkeld.wordpress.com/a-mash-up-of-openstack-and-pacemaker-cloud/ http://ahsalkeld.wordpress.com/better-integration-of-openstack-and-pacemaker-cloud/
http://www.pixelbeat.org/docs/pacemaker-cloud/

Fedoraにはもう取り込まれているので、今回はFedora 16で動作を確認することにします。

月刊あんどりゅーくん(2月号)

「一月は往ぬる、二月は逃げる、三月は去る」というわけで一月はいぬってしまいました。
いぬるってなんとなく意味わかるけどなんでしたっけこれ。

【往ぬる/去ぬる(いぬる)】
(元のいたところへ)帰る、(本来の場所へ)戻っていく、過ぎ去る、去る
【いぬ】のナ行変格活用連体形

ナ変!

【ナ行変格活用】
未然形-な
連用形-に
終止形-ぬ
連体形-ぬる
已然形-ぬれ
命令形-ね

この活用をするのは「死ぬ」「往ぬ(去ぬ)」の二語のみだそうです。
ナ変、積極的に活用していきましょう!
というわけで、今月もリリース情報と知恵袋です。

リリース情報

  • 1. LCMC 1.1.2
  • 2. Pacemaker Cloud 0.6.0
  • 3. libqb 0.9.0
  • 4. Corosync 2.0.0(リリース予定)
  • 5. DRBDのバージョンについて
  • 6. LCA 2012のレポート


1. Announce: LCMC 1.1.2 / Pacemaker, DRBD, KVM GUI

LCMCのversion 1.1.2が1月4日にリリースされました。

LCMCは、クラスタの状態を表示するためにPacemakerのptestコマンドを使用していたのですが
Pacemaker 1.1系ではptestコマンドが廃止され、crm_siumulateコマンドが導入されました。
crm_simulateコマンドは開発途中であるため、glibのバージョンによっては
コマンドの実行中に突然クラッシュしてしまうこともあるようです。
ただし、ptestとcrm_simulateが共存しない環境
つまりPacemaker 1.0系もしくはPacemaker 1.1系の単一環境においては
crm_simulateのクラッシュは報告されていないようです。
ptestの機能はcrm_simulateに引き継がれているので
機能的なデグレードは発生していません。

また、現段階ではあくまで「実験的な実装」なのですが、リモートホストに対してcrm shellを実行できるようになったようです。
実際に試したわけではないので、たんなる想像なのですが
ホストのアイコンをクリックするとcrm shellのポップアップが表示されたり
ペインが切り替わったりするとかそういう感じなんですかね?
Rastoさん曰く、「機能が安定するまでは、デフォルトでdisabled(使用不可)にしようと思ってたけど
experimental(実験的)って但し書きをつけとけば
びびって誰も使わないかなと思って、デフォルトで使えるようにしてみた」
ということなので、勇気のあるかたはクリッククリック!

 

2. [ANNOUNCE] Release of Pacemaker Cloud 0.6.0

Pacemaker Cloudのversion 0.6.0が1月25日にリリースされました。

追加された機能の一覧

  • OpenStackとの連携機能を追加しました。
  • パッケージを分割しました(詳細は後述)。
  • assemblyにUbuntuのサポートを追加しました

現在サポートされているOSはFedora 14, 15, 16, RHEL 6.1, Ubuntu 10.03です。
現在サポートされているアーキテクチャはx86_64のみです。

  • WordPressとMySQLのデモンストレーションを追加しました。
  • イベント実行時に出力されるメッセージを改善しました。
  • assemblyの生成時にsshのキーを追加しました。
  • 故障回復からのエスカレーション機能を実装しました。
  • いくつかのバグを修正しました。
  • パフォーマンスの改善をおこないました。

パッケージの分割について
メーリングリストにこのような提案がポストされたことがありました。
Pacemaker Cloudはaeolus, libvirt, openstack, ovirtとの連携を目指しているのですが

ぞれぞれのパッケージに依存するコンポーネントは別々にインストールできるようにしたいというのが提案の主旨です。
上記の提案がいよいよv0.6.0に取り込まれたようなので、Fedora 16でRPMをつくってみました。

# cat /etc/fedora-release
Fedora release 16 (Verne)
# uname -a
Linux fedora16 3.1.9-1.fc16.x86_64 #1 SMP Fri Jan 13 16:37:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
# yum-builddep pacemaker-cloud
# git clone http://github.com/pacemaker-cloud/pacemaker-cloud
# git checkout v0.6.0
# ./autogen.sh
# ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
# make rpm

Wrote: /home/ikedaj/pacemaker-cloud/pacemaker-cloud-0.6.0-1.fc16.src.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-0.6.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-debuginfo-0.6.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-core-0.6.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-libvirt-0.6.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-openstack-0.6.0-1.fc16.x86_64.rpm

あ、ほんとだ。なんか増えてる。
ちなみにv0.5.0はこんな感じです。

# git checkout v0.5.0
# ./autogen.sh
# ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
# make rpm

Wrote: /home/ikedaj/pacemaker-cloud/pacemaker-cloud-0.5.0-1.fc16.src.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-0.5.0-1.fc16.x86_64.rpm
Wrote: /home/ikedaj/pacemaker-cloud/x86_64/pacemaker-cloud-debuginfo-0.5.0-1.fc16.x86_64.rpm

せっかくRPMをつくったのでv0.6.0をインストールしてみました。

# cd /home/ikedaj/pacemaker-cloud/x86_64
# rpm -ihv pacemaker-cloud-0.6.0-1.fc16.x86_64.rpm
error: Failed dependencies:
 pacemaker-cloud-core = 0.6.0-1.fc16 is needed by pacemaker-cloud-0.6.0-1.fc16.x86_64
 pacemaker-cloud-libvirt = 0.6.0-1.fc16 is needed by pacemaker-cloud-0.6.0-1.fc16.x86_64
 pacemaker-cloud-openstack = 0.6.0-1.fc16 is needed by pacemaker-cloud-0.6.0-1.fc16.x86_64

おい。結局、openstackとの依存関係はあるんかい。
そういやaeolusとかovirtはどこいったんだ。
依存関係、えらいっこちゃです。

# grep Requires pacemaker-cloud-0.6.0/pacemaker-cloud.spec.in
Requires: %{name}-core = %{version}-%{release}
Requires: %{name}-libvirt = %{version}-%{release}
Requires: %{name}-openstack = %{version}-%{release}
BuildRequires: autoconf
BuildRequires: automake
BuildRequires: glib2-devel
BuildRequires: dbus-glib-devel
BuildRequires: libxml2-devel
BuildRequires: libqb-devel
BuildRequires: pacemaker-libs-devel
BuildRequires: libtool-ltdl-devel
BuildRequires: qmf-devel
BuildRequires: libxslt-devel
BuildRequires: libmicrohttpd-devel
BuildRequires: systemd-units
BuildRequires: libcurl-devel
BuildRequires: python-nova
BuildRequires: python-glance
Requires: python-daemon
Requires: python-qmf
Requires: qpid-cpp-server
Requires: oz > 0.5.0-1
Requires: %{name}-core = %{version}-%{release}
Requires: %{name}-core = %{version}-%{release}
Requires: openstack-nova
Requires: python-nova
Requires: openstack-glance
Requires: python-glance

しょうがないのでopenstackナントカたちもインストールしました。

# yum install openstack-glance
# yum install openstack-nova

めんどくさくなってきたので、とりあえず全部インストールしました。

# rpm -ihv pacemaker-cloud-*
Preparing...                ########################################### [100%]
 1:pacemaker-cloud-core   ########################################### [ 20%]
 2:pacemaker-cloud-libvirt########################################### [ 40%]
 3:pacemaker-cloud-opensta########################################### [ 60%]
 4:pacemaker-cloud        ########################################### [ 80%]
 5:pacemaker-cloud-debugin########################################### [100%]

ブローカーを起動させます。

# systemctl start pcloud-cped.service

v0.5.0でつくったデモが動くかなー。

# pcloudsh deployable_start dep01

ゲストの起動は成功しましたが、ゲストに定義したリソースが起動しませんでした。
ノード故障を発生させても無反応でした。
(´・ω・`)
まだ設定が甘いんだな…。

v0.5.0のデモは「別冊あんどりゅーくん」でご紹介する予定です。
試してみたことは、このリンクとほとんど同じことなのでこちらも参考にしてください。
「クラウド」とか偉そうなこといってるけど、まだv0.5.0だからたいしたことはできませんよーだ。

ところで、Pacemaker Cloudの環境構築を行う際は
ホストに pacemaker-cloud、ゲストに matahari, resource-agentsをインストールします。
ホストの pcloud-qpidd.service をブローカ、
ゲストの matahari-host.service, matahari-service.service をエージェントとして
Qpid Management Framework(QMF)に準拠したメッセージが
Advanced Message Queuing Protocol (AMQP) を使用してやり取りされます。
そして!我らがStevenくん曰く!
「MQじゃなくて!sshでノードとかリソースとかの状態を監視するっていうのもアリじゃね!」
というわけで、こちら。
Adding second monitoring method to Pacemaker Cloud – sshd

ノードの生死確認はuptimeを使ったりしています。
v0.7.0から利用可能な機能です。

3 / 612345...Last »