2013年1月31日木曜日

"fluentd(td-agent)"を"monit"で自動復旧

スズキです。

以前Monitで、いろいろと監視(自動復旧)する設定をしたのですが、
CentOS6にMonitをインストール&初期設定(auditd/crond/ntpd/rsyslog/sshd/postfix)
今回は、近頃よく利用している"fluentd(td-agent)"の監視(自動復旧)を行う設定も
用意してみます。

まず、下記の設定ファイルを用意しました。
# cat /etc/monit.d/td-agent.conf 
check process td-agent with pidfile /var/run/td-agent/td-agent.pid
    start program = "/etc/init.d/td-agent start"
    stop program = "/etc/init.d/td-agent stop"
    if 5 restarts within 5 cycles then timeout

次に、Monitを再起動します。
# /etc/init.d/monit restart
Stopping monit:                                            [  OK  ]
Starting monit: Starting monit daemon with http interface at [localhost:2812]
                                                           [  OK  ]

さらに、"fluentd(td-agent)"を停止します。
# /etc/init.d/td-agent status
td-agent (pid  21886) を実行中...
# /etc/init.d/td-agent stop
Shutting down td-agent:                                    [  OK  ]
# /etc/init.d/td-agent status
td-agent は停止しています

そして、下記のようなログが出力されると自動復旧です。
# cat /var/log/messages
...
Jan 31 21:57:04 ip-10-10-8-114 monit[22211]: 'td-agent' process is not running
Jan 31 21:57:04 ip-10-10-8-114 monit[22211]: 'td-agent' trying to restart
Jan 31 21:57:04 ip-10-10-8-114 monit[22211]: 'td-agent' start: /etc/init.d/td-agent
...

最後に、無事に復旧していることを確認します。
# /etc/init.d/td-agent status
td-agent (pid  22335) を実行中...

"fluentd(td-agent)"はデフォルト起動サービスになってしまった...
--------
http://www.suz-lab.com

"Corosync&Pacemaker"の自動フェイルオーバーでEC2(VPC)の"Public IP"と"Private IP"を同時に切り替える

スズキです。

下記のように、EC2(VPC)のIPの付け替え(Floating IPパターン)を試してきましたが、
いよいよ、"Corosync & Pacemaker"で自動的に付け替える(フェイルオーバ)部分を
紹介します。


といっても、次の記事の「"corosync"と"pacemaker"の導入と設定」までの
手順は同様となります。
"High Availability NAT"の作成(CentOS6)

そして、フェイルオーバに使うスクリプトは下記となり、
# cat /etc/init.d/associate-private-ip 
#!/bin/sh
#
# chkconfig: 2345 99 10
# description: Associate EIP

# Source Function Library
. /etc/init.d/functions

# System Variable
prog=${0##*/}
lock=/var/lock/subsys/$prog

# User Variavle
PRIVATE_IP=0.0.0.0

# Source Config
if [ -f /etc/sysconfig/$prog ] ; then
    . /etc/sysconfig/$prog
fi

#
case "$1" in
    start)
        touch $lock
        AZ=`curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`
        REGION=`echo $AZ | cut -c 1-$((${#AZ} - 1))`
        MAC=`curl -s http://169.254.169.254/latest/meta-data/mac`
        INTERFACE_ID=`curl -s http://169.254.169.254/latest/meta-data/network/interfaces/macs/$MAC/interface-id`
        aws --region $REGION ec2 assign-private-ip-addresses \
        --network-interface-id $INTERFACE_ID \
        --private-ip-addresses $PRIVATE_IP \
        --allow-reassignment \
        | logger -s -i -t $prog
        exit ${PIPESTATUS[0]}
        ;;
    stop)
        rm -f $lock
        exit 0
        ;;
    status)
        if [ -f $lock ] ; then
            exit 0
        else
            exit 3
        fi
        ;;
    *)
        echo "Usage: $0 {start|stop|status}"
        exit 1
esac
可変情報は、次のファイルに設定します。
# cat /etc/sysconfig/associate-private-ip 
PRIVATE_IP=10.10.8.200

Pacemakerへの登録は下記の通りです。
crm configure property no-quorum-policy="ignore" stonith-enabled="false"
crm configure rsc_defaults resource-stickiness="INFINITY" migration-threshold="1"
crm configure primitive httpd lsb:httpd op monitor interval="5s"
crm configure primitive associate-private-ip lsb:associate-private-ip
crm configure group ha-web httpd associate-private-ip
※Apacheに障害が発生したらフェイルオーバー(IPの切り替え)を行うようにしています。

ここまでで、下記のような状態になっているはずです。
# crm_mon
============
Last updated: Wed Jan 30 20:46:08 2013
Last change: Wed Jan 30 20:46:01 2013 via cibadmin on ip-10-10-8-114
Stack: openais
Current DC: ip-10-10-8-122 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ip-10-10-8-122 ip-10-10-8-114 ]

 Resource Group: ha-web
     httpd (lsb:httpd):    Started ip-10-10-8-114
     associate-private-ip (lsb:associate-private-ip):     Started ip-10-10-8-114

アクティブなEC2の方でApacheを停止すると、
# service httpd stop
httpd を停止中:                                            [  OK  ]
下記のようにフェイルオーバーされ、IPアドレスが切り替わります。
============
Last updated: Wed Jan 30 20:48:08 2013
Last change: Wed Jan 30 20:46:01 2013 via cibadmin on ip-10-10-8-114
Stack: openais
Current DC: ip-10-10-8-122 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ip-10-10-8-122 ip-10-10-8-114 ]

 Resource Group: ha-web
     httpd (lsb:httpd):    Started ip-10-10-8-122
     associate-private-ip (lsb:associate-private-ip):     Started ip-10-10-8-122

Failed actions:
    httpd_monitor_5000 (node=ip-10-10-8-114, call=4, rc=7, status=complete): not running
※AWSコンソールで実際のIPアドレスの切り替わりは確認できます。

ちなみに、二つ目のIPアドレスをCentOS6で利用するためには、
下記で紹介したような手順が実際には必要になります。
ENIに"Secondary IP"をつけてCentOS(6)で利用

実際にApacheのフェイルオーバー時の停止時間を確認したところ、
下記のように、約10秒程度でした。
connected to 54.249.50.18:80 (198 bytes), seq=272 time=2.40 ms 
connected to 54.249.50.18:80 (198 bytes), seq=273 time=4.78 ms 
connected to 54.249.50.18:80 (198 bytes), seq=274 time=2.65 ms 
could not connect (Connection refused)
could not connect (Connection refused)
could not connect (Connection refused)
could not connect (Connection refused)
could not connect (Connection refused)
could not connect (Connection refused)
connected to 54.249.50.18:80 (198 bytes), seq=281 time=8201.49 ms 
connected to 54.249.50.18:80 (198 bytes), seq=282 time=3.06 ms 
connected to 54.249.50.18:80 (198 bytes), seq=283 time=2.86 ms 

これも自動で作成できるようにしたい...
--------
http://www.suz-lab.com

2013年1月30日水曜日

EC2(VPC)の"Public IP"と"Private IP"を同時に切り替えるスクリプト

スズキです。

下記で紹介した切り替えはAWSコンソール上で手動で行うものでしたが、
EC2(VPC)の"Public IP"と"Private IP"を同時に切り替える
当然、APIが提供されているAWS、切り替えスクリプトも作成してみました。

まずは切り替え対象の二つのEC2のENIの確認です。

【アクティブEC2】


【スタンバイEC2】


上記の状態で、スタンバイEC2にて下記のスクリプトを、
#!/bin/sh

AZ=`curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`
REGION=`echo $AZ | cut -c 1-$((${#AZ} - 1))`
MAC=`curl -s http://169.254.169.254/latest/meta-data/mac`
INTERFACE_ID=`curl -s http://169.254.169.254/latest/meta-data/network/interfaces/macs/$MAC/interface-id`

aws --region $REGION ec2 assign-private-ip-addresses \
--network-interface-id $INTERFACE_ID \
--private-ip-addresses 10.10.8.200 \
--allow-reassignment
次のように実行してみます。
# ./test.sh 
{
    "return": "true", 
    "requestId": "ddccfc4b-b387-4cbc-9161-718e6d96572b"
}
※Python版AWSコマンドラインツールを"IAM Role"で利用しています。
Python版AWSコマンドラインツールをCentOS6で使ってみた

すると、次のようにスタンバイEC2に両IPアドレスが移っています。


あとは、フェイルオーバースクリプトに組み込むだけ...
--------
http://www.suz-lab.com

EC2(VPC)の"Public IP"と"Private IP"を同時に切り替える

スズキです。

Floating IPパターン」の実装方法の一つです。


上記のようにインターネットからアクセスされる"Public(Elastic) IP"と、VPC内から
アクセスされる"Private IP"をEC2の障害時に同時に切り替える方法です。

まずは、二つ目の"Private IP"をアサインしておきます。(詳しくは下記記事を参照)
ENIに複数のプライベートIPをアサインするときの"Allow reassignment"


そして、"Public(Elastic) IP"もアサインします。


ここで、"Public(Elastic) IP"は"Private IP"と関連づけられるので、上記でアサインした
二つ目の"Private IP"に関連づくようにします。



ちなみに"、Public(Elastic) IP"アサイン時にも"Allow Reassociatation"を有効に
できますが、今回は、むしろ関連づけた"Private IP"から勝手に外したくないので
無効にしています。

すると、"Private IP"の横に関連づけた"Public(Elastic) IP"も表示されます。


ここで、もう一方のENIに上記の"Private IP"をアサインします。


すると、"Private IP"と一緒に関連づけられた"Public(Elastic) IP"もアサインされて
いることがわかります。




当然、もとのENIからは"Private IP"も"Public(Elastic) IP"も両方はずれています。


ということで、"Private IP"と"Public(Elastic) IP"を同時に切り替えたい場合は、
該当する"Public(Elastic) IP"を切り替えに使う"Private IP"に関連づけることで、
"Private IP"の切り替えだけで実現できることになります。

あとは"Corosync & Pacemaker"で上記を自動フェイルオーバーに組み込むだけです...
--------
http://www.suz-lab.com

ENIに複数のプライベートIPをアサインするときの"Allow reassignment"

スズキです。

以前、下記でENIに2つ目のプライベートIPを付けたのですが、
"Floating IPパターン"をENIの"Secondary IP"で試してみた
そのときにチェックできた"Allow reassignment"がよくわからないままだったので、
挙動を確認してみました。


プライベートIPの管理ウィンドウを表示




二つ目のプライベートIPをアサインするモード




"Allow reassignment"を付けずにアサイン



もう一つのENIで上記のプライベートIPと同じものをアサイン



既にアサインされているのでエラー



再度はじめのENIで"Allow reassignment"を付けてアサイン



同様にもう一つのENIで上記のプライベートIPと同じものをアサイン



今度は他にアサインされていても(移動)成功




当然ながら以前のENIからはアンアサイン




紐づくEIPはどうなるんだろう?
--------

SecureCloudで鍵情報の抽出と適用(鍵管理サーバが利用できないときに)

スズキです。

以下で紹介したEBS暗号化ツールのSecureCloudですが、
EBS暗号化ツールSecureCloudを使ってみる(登録編)

EBS暗号化ツールSecureCloudを使ってみる(CentOS6編)
暗号化に利用する鍵を外部の鍵管理サーバで管理しているため、
鍵管理サーバと通信できなくなった場合、"SecureCloud Agent"を再起動すると、
暗号化されたEBSをマウントできなくなってしまいます。

当然その場合の対策は用意されていて、その方法は、事前に鍵情報を管理コンソールから
抽出しておき、問題発生時に、その鍵情報を"SecureCloud Agent"に適用する形と
なっています。

実際の手順は下記の通りです。

管理コンソールでの作業


Roleが"Security Administrator"のユーザーを作成します。


確認メールが送信されるので、文中のリンクをクリックします。


上記で作成したユーザーのパスワードを設定しログインします。


対象のEBSボリュームを選択してExportします。


パスフレーズの入力が必要になるので、適当なもの(後で必要)を入力します。


"SecureCloudDeviceKeys-2013-01-29.zip"のようなファイル名でキーが抽出できます。

EC2(SecureCloud Agent)での作業


展開したキーファイルを配置します。
# cd /root/
# ls -1
vol-xxxxxxxx.xml

キーファイルを適用します。
# cd /var/lib/securecloud
# ./keyexporter.sh /root/vol-xxxxxxxx.xml 
Enter Backup Password: 
Please enter original Access Key ID: ACCESS_KEY
Please enter original Secret Access Key: SECRET_KEY

Accessing device. Please wait....

The device [vol-xxxxxxxx] has been mounted to [/mnt/test]. Once finished, run 'umount /mnt/test'

これで鍵管理サーバと通信できなくても、暗号化ディスクをマウントすることができます。

ぶっちゃけ、作業メモです。。。
--------
http://www.suz-lab.com

2013年1月29日火曜日

"Openswan on EC2"で"VPC"と"VPN Connection"

スズキです。

EC2(CentOS6)上にOpenswanをインストールして、まずはVPCの
"Virtual Private Gateway"に"VPN Connection"を張ってみました。


VPCの準備


"Customer Gateway"はあらかじめ取得しておいたEIP(z.z.z.z)を指定します。
(RoutingはとりあえずStaticです)


上記の"Customer Gateway"と"Virtual Private Gateway"から"VPN Connection"を
作成します。"Static Routing"の"IP Prefix"は、とりあえず上記のEC2が所属する
VPCのCIDRブロックにしています。


二つのトンネルが準備され、その"IP Address"に対してIPsecを張ることになります。
(Tunnel1: x.x.x.x, Tunnel2: y.y.y.y)


EC2の準備


EIP(z.z.z.z)をつけて、"Security Group (Outbound)"は下記のようにしておきます。
("x.x.x.x"と"y.y.y.y"に対してUDPの500番と4500番を許可します)


Openswanのインストールと設定準備


"yum"でインストールできます。
# yum -y install openswan lsof
...

カーネルパラメーターも調整しておきます。
# cat /etc/sysctl.conf 
...
net.ipv4.ip_forward = 1
...
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
# sysctl -p
...

Openswanの設定と接続


全体の設定です。
# cat /etc/ipsec.conf 
version 2.0

config setup
 protostack=netkey
 nat_traversal=yes
 oe=off

include /etc/ipsec.d/*.conf

Tunnel1の"Pre-Shared Key"の設定です。
# cat /etc/ipsec.d/tunnel1.secrets 
z.z.z.z x.x.x.x: PSK "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
※キーはAWSコンソールの"VPN Connection"からダウンロードできる設定中にあります。

Tunnel1の本体の設定です。
# cat /etc/ipsec.d/tunnel1.conf 
conn tunnel1
    type        = tunnel
    authby      = secret
    left        = %defaultroute
    leftid      = z.z.z.z
    leftnexthop = %defaultroute
    right       = x.x.x.x
    auth        = esp
    keyexchange = ike
    ike         = aes128-sha1-modp1024
    ikelifetime = 28800s
    pfs         = yes
    esp         = aes128-sha1
    salifetime  = 3600s
    dpdtimeout  = 10
    dpddelay    = 3
    auto        = start


Openswanを起動(service ipsec start)すると、下記のようにAWSコンソールで
接続確認できます。



Tunnel2の"Pre-Shared Key"の設定です。
# cat tunnel2.secrets 
z.z.z.z y.y.y.y: PSK "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY"
※キーはAWSコンソールの"VPN Connection"からダウンロードできる設定中にあります。

Tunnel2の本体の設定
# cat tunnel2.conf 
conn tunnel2
    type        = tunnel
    authby      = secret
    left        = %defaultroute
    leftid      = z.z.z.z
    leftnexthop = %defaultroute
    right       = y.y.y.y
    auth        = esp
    keyexchange = ike
    ike         = aes128-sha1-modp1024
    ikelifetime = 28800s
    pfs         = yes
    esp         = aes128-sha1
    salifetime  = 3600s
    dpdtimeout  = 10
    dpddelay    = 3
    auto        = start

Openswanを再起動(service ipsec restart)すると、下記のようにAWSコンソールで
接続確認できます。


これで、"Openswan on EC2"から"VPC"の"Virtual Private Gateway"に
"VPN Connection"を張ることができました。
※ちなみにログは"/var/log/secure"に出力されます。

次は、対向に"ping"が通るまで...
--------
http://www.suz-lab.com

2013年1月28日月曜日

"High Availability NAT"の作成(CentOS6)

スズキです。

久しぶりのCDPネタです。
今回は「High Availability NATパターン」(Incubator & 未完成)です。


上記をCentOS6上でCorosyncとPacemaker、そしてPython版コマンドラインツールで
構築してみました。
※上記のVPC/EC2/セキュリティグループなどの設定は適切に行われているものとします。

AWS(EC2)と"iptables"の設定


下記参照。
VPCのNATインスタンスを作ってみる(環境準備編)

VPCのNATインスタンスを作ってみる(iptables編)
次のようになっていれば、OKです。
# iptables --list -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere            
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

"corosync"と"pacemaker"の導入と設定


下記参照
Corosync & Pacemaker on EC2
次のようになっていれば、OKです。
# crm_mon
============
Last updated: Mon Jan 28 18:21:56 2013
Last change: Mon Jan 28 18:20:39 2013 via crmd on ip-10-10-8-122
Stack: openais
Current DC: ip-10-10-8-122 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ ip-10-10-9-111 ip-10-10-8-122 ]

"iptables"のモニタリングとフェイルオーバーの設定


下記参照。
"Corosync & Pacemaker"で"iptables"のフェイルオーバー
次のようになっていれば、OKです。
# crm_mon
============
Last updated: Mon Jan 28 18:24:36 2013
Last change: Mon Jan 28 18:24:34 2013 via cibadmin on ip-10-10-8-122
Stack: openais
Current DC: ip-10-10-8-122 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ ip-10-10-9-111 ip-10-10-8-122 ]

iptables        (lsb:iptables): Started ip-10-10-9-111

フェイルオーバー時の"Route Table"の変更設定

ここからが、本番です。

下記のような初期起動スクリプトを用意します。
# cat /etc/init.d/associate-nat 
#!/bin/sh
#
# chkconfig: 2345 99 10
# description: Associate EIP

# Source Function Library
. /etc/init.d/functions

# System Variable
prog=${0##*/}
lock=/var/lock/subsys/$prog

# User Variavle
ROUTE_TABLE_ID=rtb-xxxxxxxx
DESTINATION_CIDR=0.0.0.0/0

# Source Config
if [ -f /etc/sysconfig/$prog ] ; then
    . /etc/sysconfig/$prog
fi

#
case "$1" in
    start)
        touch $lock
        AZ=`curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`
        REGION=`echo $AZ | cut -c 1-$((${#AZ} - 1))`
        INSTANCE_ID=`curl -s http://169.254.169.254/latest/meta-data/instance-id`
        aws --region $REGION ec2 replace-route    \
        --destination-cidr-block $DESTINATION_CIDR \
        --route-table-id         $ROUTE_TABLE_ID  \
        --instance-id            $INSTANCE_ID     \
        | logger -s -i -t $prog
        exit ${PIPESTATUS[0]}
        ;;
    stop)
        rm -f $lock
        exit 0
        ;;
    status)
        if [ -f $lock ] ; then
            exit 0
        else
            exit 3
        fi
        ;;
    *)
        echo "Usage: $0 {start|stop|status}"
        exit 1
esac

それに実行権限を与えます。
# chmod 755 /etc/init.d/associate-nat

さらに"Route Table ID"も設定します。
# cat /etc/sysconfig/associate-nat 
ROUTE_TABLE_ID=rtb-yyyyyyyy

そして実行すると"Route Table"で指定しているNATインスタンスが自分自身の
インスタンスIDに変更されます。
# service associate-nat start
associate-nat[9971]: {
associate-nat[9971]:     "return": "true", 
associate-nat[9971]:     "requestId": "e9220a00-e8c0-4c20-b42a-f3e5af3d9dc7"
associate-nat[9971]: }


これをPacemakerに設定します。
# crm configure primitive associate-nat lsb:associate-nat
# crm configure group ha-nat iptables associate-nat

次のようになっていれば、OKです。
# crm_mon
============
Last updated: Mon Jan 28 20:26:37 2013
Last change: Mon Jan 28 20:26:17 2013 via cibadmin on ip-10-10-9-111
Stack: openais
Current DC: ip-10-10-8-122 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ip-10-10-9-111 ip-10-10-8-122 ]

 Resource Group: ha-nat
     iptables   (lsb:iptables): Started ip-10-10-9-111
     associate-nat (lsb:associate-nat):    Started ip-10-10-9-111

一方のEC2の"iptables"を停止すると、
# service iptables stop

次のようにフェイルオーバーされ、
# crm_mon
============
Last updated: Mon Jan 28 20:54:28 2013
Last change: Mon Jan 28 20:26:17 2013 via cibadmin on ip-10-10-9-111
Stack: openais
Current DC: ip-10-10-8-122 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ip-10-10-9-111 ip-10-10-8-122 ]

 Resource Group: ha-nat
     iptables   (lsb:iptables): Started ip-10-10-8-122
     associate-nat (lsb:associate-nat):    Started ip-10-10-8-122

Failed actions:
    iptables_monitor_5000 (node=ip-10-10-9-111, call=5, rc=7, status=complete): not running

"Route Table"も"associate-nat"が実行された(スタンバイ)EC2のインスタンスIDに
変更されます。


フェイルバックするためには、一旦、障害を起こしたEC2の"Failed Action"をクリアします。
# crm resource cleanup ha-nat ip-10-10-9-111
Cleaning up iptables on ip-10-10-9-111
Cleaning up associate-nat on ip-10-10-9-111
Waiting for 3 replies from the CRMd... OK

次のように"Failed Action"が消えていれば、OKです。
# crm_mon
============
Last updated: Mon Jan 28 21:04:02 2013
Last change: Mon Jan 28 21:04:02 2013 via crmd on ip-10-10-9-111
Stack: openais
Current DC: ip-10-10-8-122 - partition with quorum
Version: 1.1.7-6.el6-148fccfd5985c5590cc601123c6c16e966b85d14
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ip-10-10-9-111 ip-10-10-8-122 ]

 Resource Group: ha-nat
     iptables   (lsb:iptables): Started ip-10-10-8-122
     associate-nat (lsb:associate-nat):    Started ip-10-10-8-122

これを自動で作成できるようにしたい...
--------
http://www.suz-lab.com

2013年1月27日日曜日

SUZ-LAB謹製 CentOS AMI (6.3.7 ap-northeast-1)

スズキです。

下記をアップデートしました。
SUZ-LAB謹製 CentOS AMI (6.3.6 64bit ap-northeast-1)
AMIを「suz-lab_centos」で検索してもらえれば、次のように確認できます。


変更内容は下記の通りです。(SUZ-LAB AMI 6.3.7 Release)

※各課題のコメントに、本ブログの詳細記事へのリンクが張ってあります。

Enjoy!
--------
http://www.suz-lab.com

Python版コマンドラインツールを初回起動時に自動アップデート

スズキです。

以前、CentOS6上で下記のようにPython版コマンドラインツールをインストールしました。
Python版AWSコマンドラインツールをCentOS6で使ってみた
そして、このツールのアップデートは下記で行うことが可能です。
# pip-python install awscli --upgrade

当然、このアップデートは(EC2)初回起動時に行いたいわけですが、以前、下記で紹介した、
"cloud-init"を利用することで簡単に実現できます。
"cloud-init"でスクリプトが実行されるタイミングを調べてみた
実際には次のようなスクリプトを用意します。

https://github.com/suz-lab/suz-lab-centos-ami/blob/master/bin/update-awscli
#!/bin/sh
set -e
trap 'echo "NG: $?"' ERR
pip-python install awscli --upgrade 2>&1 | logger -s -t ${0##*/}
exit 0

そして、次のように配置すればOKです。
# cd /var/lib/cloud/scripts/per-once
# ln -s /opt/suz-lab/bin/update-awscli update-awscli

すると、(EC2)初回起動時に下記のようなログが出力されるはずです。
# cat /var/log/messages
...
Jan 27 07:11:49 ip-10-146-26-215 update-awscli: Successfully installed argparse awscli botocore python-dateutil requests six
Jan 27 07:11:49 ip-10-146-26-215 update-awscli: Cleaning up...
...

とりあえず、6.3.7に組み込む課題は終了。
--------
http://www.suz-lab.com

"psacct"でコマンド履歴を残す(CnetOS6)

スズキです。

下記のようにログインユーザーの作業内容の履歴を残す仕組みを紹介してきましが、
今回は"psacct"を試してみました。

インストール&(自動)起動


"yum"でインストールできます。
# yum -y install psacct
...
# chkconfig psacct on
# service psacct start
プロセスアカウントを開始中:                                [  OK  ]

履歴の確認


履歴は"/var/account/pacct"に保存されていますが、バイナリ形式なので
閲覧には"lastcomm"を利用します。
# lastcomm
sshd              S     root     __         0.00 secs Sun Jan 27 07:09
sshd              SF    sshd     __         0.00 secs Sun Jan 27 07:09
khelper            F    root     __         0.00 secs Sun Jan 27 07:09
modprobe                root     __         0.00 secs Sun Jan 27 07:09
lastcomm                root     pts/1      0.00 secs Sun Jan 27 07:08
sshd              S     root     __         0.00 secs Sun Jan 27 07:08
sshd              SF    sshd     __         0.00 secs Sun Jan 27 07:08
khelper            F    root     __         0.00 secs Sun Jan 27 07:08
modprobe                root     __         0.00 secs Sun Jan 27 07:08
lastlog                 root     pts/1      0.00 secs Sun Jan 27 07:08
ls                      root     pts/1      0.00 secs Sun Jan 27 07:08
service                 root     pts/1      0.00 secs Sun Jan 27 07:07
psacct                  root     pts/1      0.00 secs Sun Jan 27 07:07
touch                   root     pts/1      0.00 secs Sun Jan 27 07:07
accton            S     root     pts/1      0.00 secs Sun Jan 27 07:07
※コマンドの引数は確認できないのでBash(History)と併用するのが効果的です。

履歴のクリア


履歴ファイル(/var/account/pacct)を削除します。
# rm -f /var/account/pacct
※削除すると"psacct"は機能しなくなるので、再び機能させるには"psacct"を再起動します。

とりあえずCentOSは、"psacct"、"bash(history)"、"audit(d)"、を入れておく感じかな?
--------
http://www.suz-lab.com

2013年1月25日金曜日

EMRとMahoutで「この商品を買った人はこんな商品も買っています」

スズキです。

以前、下記でEMR上でMahoutを使って、リコメンデーションを試してみました。
"Elastic MapReduce"で"Mahout"使ってリコメンデーション
今回は、同様に"EMR & Mahout"で、
「この商品を買った人はこんな商品も買っています」を試してみました。


実際に試すにあたり、"Mahout"の"ItemSimilarityJob"を利用したのですが、
下記の情報が大変参考になりました。(ありがとうございます!)
[Hadoop]Hadoop上でMahoutを使って「このアイテムを見た人は、
こちらのアイテムも見ています」というレコメンドをやってみる | GENDOSU@NET

S3にMahoutライブラリ(JAR)を配置



ライブラリ自体はこちらよりダウンロードしました。


S3に作業領域を作成



入力ファイルの配置先(input)とログの配置先(log)を用意しておきます。
EMRからの出力ファイルは"output"というディレクトリが自動作成後、配置されます。
("output"ディレクトリを予め作っておくとエラーになります)

入力ファイルの配置



ファイルの内容は下記(ユーザーID,商品ID,重み)の通りです。
100,200,10.0
100,201,10.0
100,202,10.0
100,203,10.0
100,204,10.0
100,205,10.0
100,206,10.0
100,207,10.0
100,208,10.0
100,209,10.0
101,200,10.0
101,201,10.0
101,202,10.0
101,203,10.0
101,204,10.0
101,205,10.0
101,206,10.0
101,207,10.0
101,208,10.0
102,200,10.0
102,201,10.0
102,202,10.0
102,203,10.0
102,204,10.0
102,205,10.0
102,206,10.0
102,207,10.0
103,200,10.0
103,201,10.0
103,202,10.0
103,203,10.0
103,204,10.0
103,205,10.0
103,206,10.0
104,200,10.0
104,201,10.0
104,202,10.0
104,203,10.0
104,204,10.0
104,205,10.0
105,200,10.0
105,201,10.0
105,202,10.0
105,203,10.0
105,204,10.0
106,200,10.0
106,201,10.0
106,202,10.0
106,203,10.0
107,200,10.0
107,201,10.0
107,202,10.0
108,200,10.0
108,201,10.0
109,200,10.0

今回のデータは、結果をわかりやすくするために、番号が一番若い(100)ユーザーは
すべての商品を買っており、ユーザーIDが増えるに従い購入商品を後ろから一つずつ
減らしていくようにしました。(109は200の商品しか購入していない)

一番多くのユーザーに購入されている200と201のペアが、類似度が一番高くなると
予想されます。

"Job Flow"の作成



"JAR Location"は上述した、
s3n://ap-northeast-1.lib.emr.cloudpack.jp/mahout/core/0.7-job.jar
を指定しています。

"JAR Arguments"も上述した"ItemSimilarityJob"や入出力ディレクトリを
指定しています。
org.apache.mahout.cf.taste.hadoop.similarity.item.ItemSimilarityJob
-Dmapred.output.dir=s3n://ap-northeast-1.tmp.emr.cloudpack.jp/suz-lab/output
-Dmapred.input.dir=s3n://ap-northeast-1.tmp.emr.cloudpack.jp/suz-lab/input
--similarityClassname SIMILARITY_COSINE


"Amazon S3 Log Path"も上述した、
s3n://ap-northeast-1.tmp.emr.cloudpack.jp/suz-lab/log
を指定しています。


出力結果


出力結果は"output"が作成され"part-r-00000"に下記のように書き出されます。
200 201 0.9486832980505138
200 202 0.8944271909999159
200 203 0.8366600265340756
200 204 0.7745966692414835
200 205 0.7071067811865475
200 206 0.6324555320336759
200 207 0.5477225575051661
200 208 0.4472135954999579
200 209 0.31622776601683794
201 202 0.9428090415820634
201 203 0.8819171036881968
201 204 0.816496580927726
201 205 0.7453559924999298
201 206 0.6666666666666666
201 207 0.5773502691896257
201 208 0.4714045207910316
201 209 0.3333333333333333
202 203 0.9354143466934852
202 204 0.8660254037844386
202 205 0.7905694150420948
202 206 0.7071067811865475
202 207 0.6123724356957945
202 208 0.4999999999999999
202 209 0.35355339059327373
203 204 0.9258200997725515
203 205 0.8451542547285167
203 206 0.7559289460184545
203 207 0.6546536707079772
203 208 0.5345224838248488
203 209 0.37796447300922725
204 205 0.9128709291752768
204 206 0.816496580927726
204 207 0.7071067811865475
204 208 0.5773502691896257
204 209 0.408248290463863
205 206 0.8944271909999159
205 207 0.7745966692414833
205 208 0.6324555320336758
205 209 0.4472135954999579
206 207 0.8660254037844386
206 208 0.7071067811865475
206 209 0.5
207 208 0.8164965809277259
207 209 0.5773502691896257
208 209 0.7071067811865475
フォーマットは、
商品ID 商品ID 二つの商品の類似度?
といった感じになります。

見ての通り、ほとんどのユーザーが購入している200と201のペアは類似度が高く
(0.9486832980505138)、誰も購入していない200と209のペアは類似度が低く
(0.31622776601683794)なっています。

あとは、上記の情報をDBなどに保存して、類似商品の選択に利用するだけです。

ちなみに、ログは下記のようにいろいろと出力されています。


次は、コマンドライン(Python版コマンドラインツール)からの利用です。
--------
http://www.suz-lab.com