PacemakerでENIを付替えるResource Agentを書いてみた

懲りずに4回目のPacemaker on AWSネタです。
前回はPacemakerでパブリックIPアドレスであるEIPを付け替えてAWSクラウドデザインパターンFloating IPパターンを実現しました。
今回はEIPではなく、仮想NICであるENIを付け替えるRA(Resource Agent)を書いてみました。
冒頭で先に言っときますが、今回のRAはあまり実用的ではなく、いろいろ弄ってみた結果生まれただけのものなので、実用的なRAをお求めの方は前回の記事をご参照ください:D

aws-eni-resource-agentという名前でGithubに置いておきました。
例によってバグ報告、Pull Request、大歓迎です。

ちなみに過去のPacemakerネタはこちら。

以下で詳細について説明していきます。

eni_after_fo


環境

今回使用したのは下記のインスタンスです。

  • Red Hat Enterprise Linux 6.5 (PV) 64bit (t1.micro)

Pacemakerパッケージとしては、過去2回と同様、Linux-HA Japan提供のPacemaker 1.0.13-1.2を使用しています。
他のOS、他のversionでも動作すると思いますが、テストしていません。


セットアップ

まず、クラスタを構成する各インスタンスにawscli(AWS Command Line Interface)をインストールします。
awscliのインストールにはpipが必要なので、先にpipをインストールしておきましょう。

wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py

awscliをインストールします。

pip install awscli

各インスタンスからAWSにアクセスできるように、必要に応じてアクセス設定をしておきます。

aws configure

aws-eni-resource-agentのリポジトリから各インスタンスにeni resource agentをDownloadまたはCloneします。

git clone https://github.com/moomindani/aws-eni-resource-agent.git
cd aws-eni-resource-agent

eni resource agentをインストールします。

mv eni /usr/lib/ocf/resource.d/heartbeat/
chown root:root /usr/lib/ocf/resource.d/heartbeat/eni 
chmod 0755 /usr/lib/ocf/resource.d/heartbeat/eni

Pacemakerは下記の記事をもとに、あらかじめセットアップして起動しておきます。
今回はCorosyncで設定しました。

付け替え対象とするENI(Floating NIC??)として使うENIあらかじめマネジメントコンソールから作成し、EIPを割り当ておきましょう。
ちなみに、今回作成したENIのIDはeni-2a718a5dでした。

Pacemakerのcrmのconfigを作成しましょう。
今回はこんな感じのcrmファイルを用意しました。

eni-sample.crm

property \
    no-quorum-policy="ignore" \
    stonith-enabled="false" \
    crmd-transition-delay="0s"

primitive eni ocf:heartbeat:eni \
    params \
        interface_id="eni-2a718a5d" \
        device_index="1" \
        device_name="eth1" \
        gateway="172.31.0.1" \
        wait="60" \
        table_id="100" \
        table_priority="100" \
    op start   timeout="120s" interval="0s"  on-fail="stop" \
    op monitor timeout="60s" interval="10s" on-fail="restart" \
    op stop    timeout="120s" interval="0s"  on-fail="block"

設定を反映します。

crm configure load update eni_sample.crm

動作確認

では、eni resource agentがどうなっているのか、crm_monコマンドで確認していきましょう。

# crm_mon -fA
Connection to the CIB terminated
Reconnecting...[root@ip-172-31-8-160 aws-eni-resource-agent]# crm_mon -f1
============
Last updated: Wed May 14 09:44:44 2014
Stack: openais
Current DC: ip-172-31-0-7.ap-northeast-1.compute.internal - partition with quorum
Version: 1.0.13-30bb726
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ ip-172-31-0-7.ap-northeast-1.compute.internal ip-172-31-8-160.ap-northeast-1.compute.internal ]

 eni	(ocf::heartbeat:eni):	Started ip-172-31-0-7.ap-northeast-1.compute.internal

Migration summary:
* Node ip-172-31-0-7.ap-northeast-1.compute.internal: 
* Node ip-172-31-8-160.ap-northeast-1.compute.internal: 

このように、2台のクラスタノード(172.31.0.7と172.31.8.160)のうち、172.31.0.7側にENIが付けられていることがわかります。
図にするとこんな感じです。

eni_before_fo

ちなみに、マネジメントコンソールからみてみると、こんな感じになっていました。
(instance_id=i-f5afdff3のPrivate IP Addressが172.31.0.7です。)

eni before fo

では、172.31.0.7側のpacemakerをdownさせ、eni resourceが172.31.8.160側にフェイルオーバーし、ENIが172.31.0.7から172.31.8.160に付け替えらることを確認します。

service corosync stop

crm_monコマンドで状態を確認します。

# crm_mon -f1
============
Last updated: Wed May 14 09:53:45 2014
Stack: openais
Current DC: ip-172-31-8-160.ap-northeast-1.compute.internal - partition WITHOUT quorum
Version: 1.0.13-30bb726
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ ip-172-31-8-160.ap-northeast-1.compute.internal ]
OFFLINE: [ ip-172-31-0-7.ap-northeast-1.compute.internal ]

 eni	(ocf::heartbeat:eni):	Started ip-172-31-8-160.ap-northeast-1.compute.internal

Migration summary:
* Node ip-172-31-8-160.ap-northeast-1.compute.internal: 

このように、172.31.8.160側にEIPが付け替えられたことがわかります。
図にするとこんな感じです。

eni_after_fo

ちなみに、マネジメントコンソールからみてみると、こんな感じになっていました。
(instance_id=i-f1afdff7のPrivate IP Addressが172.31.8.160です。)
eni after fo

フェイルオーバー前後のpingの結果はこんな感じでした。

# ping 54.178.202.118
64 bytes from 54.178.202.118: icmp_seq=657 ttl=50 time=21.805 ms
64 bytes from 54.178.202.118: icmp_seq=658 ttl=50 time=20.149 ms
64 bytes from 54.178.202.118: icmp_seq=659 ttl=50 time=20.454 ms
Request timeout for icmp_seq 660
Request timeout for icmp_seq 661
Request timeout for icmp_seq 662
(中略)
Request timeout for icmp_seq 1004
Request timeout for icmp_seq 1005
Request timeout for icmp_seq 1006
64 bytes from 54.178.202.118: icmp_seq=1007 ttl=51 time=21.162 ms
64 bytes from 54.178.202.118: icmp_seq=1008 ttl=51 time=19.622 ms
64 bytes from 54.178.202.118: icmp_seq=1009 ttl=51 time=20.775 ms

設定反映待ちのために眺めのtime waitをかけているだけあり、切り替えにかなり時間かかってます。


おわりに

前回のEIP付け替え用RAに比べ、今回のENI付け替え用RAは下記の観点からあまり現実的ではありません。

今回のENIの付け替え時には、単一のインスタンスに2枚のENIを差すことを想定しています。
このとき、同一サブネットに2枚のENIを差すと、そのままでは2枚目のENIに対する通信への応答を1枚目のENIから返却してしまうなどして、外部からの疎通がとれなくなります。
このような場合、OS側でマルチホーミングの設定が必要(iproute2の出番!)になり、それ用のパラメータとしてdevice_name, gateway, table_id, table_priorityを用意しました。
このときにプライベートIPアドレスが必要になるため、ENIをattachしてからdhcpでプライベートIPアドレスが割り振られるのを待機するために、time waitをパラメータとして設定しています。
このtime waitは数十秒程度要することになるので、結局、ENIの切替完了にかなりの時間がかかってしまうことになります。

また、あえてEIPではなくENIを付け替えることによるメリットが特に思い当たりません。

結論として、本RAによるENIの付け替えでCDP:Floating IPパターンを実現するのは、かなり自虐的な行為と言わざるを得ません(ぉぃ
あくまで検証やお遊び用途、ENIの付け外しやattachment_idの取得、マルチホーミング等の参考程度にとらえていただければと思います。

広告
  1. 2014年 7月 21日

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。