2013年2月25日月曜日

StorageGatewayってなんじゃ?(Gatewayインスタンスの冗長化:GlusterFS編)

StorageGatewayのiSCSIボリュームをEC2にマウントし、アプリケーションシステムの中で使おうとする場合、冗長化という課題が持ち上がってきます。


ここで、いくつか冗長化の可能性を考えてみました。


マルチパス(


その場合、iSCSIとしての冗長化に合わせると、マルチパスという方法があるようです。
イメージとしては、以下のような感じでiSCSIターゲットであるgatewayインスタンスに複数のIPを付与し、それぞれの接続先の複数のデバイスを1つのデバイスとして認識させ、1つの接続が切れても他のNICで接続ができる方法です。



これはそもそもGatewayインスタンスの冗長化ではなく、ネットワーク・インターフェースの冗長化になりますが、ちょっと試してみます。
2番目のENIIを10.0.1.6として追加し、gatewayインスタンスにアタッチします。





そして、マウント用のEC2から10.0.1.6のiSCSIを調べてみますが、接続できないようです。
(既存のENIのセカンダリIPに付与しても同じでした。)
# iscsiadm --mode discovery --type sendtargets --portal 10.0.1.6:3260
iscsiadm: cannot make connection to 10.0.1.6: Connection refused
iscsiadm: cannot make connection to 10.0.1.6: Connection refused
iscsiadm: cannot make connection to 10.0.1.6: Connection refused


その後、ググってみると、いろいろなことがわかりました。

また、EC2インスタンスのゲートウェイには通常のログインができないようです。
替わりにAWSのサポートにトラブルシュートをしてもらうために以下のsshコマンドだけ受け付けているそうです。
ssh -i IDENTITY_FILE sguser@INSTANCE_IP_ADDRESS grant-aws-support-access
ssh -i IDENTITY_FILE sguser@INSTANCE_IP_ADDRESS revoke-aws-support-access
(試したところ、理由はわかりませんが、上記のコマンドもPermission denied (publickey).がでてアクセス出来ませんでした。。)



ソフトウェアRAID(


2つのGatewayインスタンスを複数のイニシエータにマウントしそれぞれでソフトウェアRAID1を試してみましたが、
一方の変更が他方のイニシエータ上に反映されませんでした。クラスタファイルシステムなどを利用する必要があるようです。





DRBD


DRBD + iSCSIはiSCSIターゲット側でDRBDを行うことが通常のようですが、Gateway on EC2ではGatewayインスタンスにはログインできないようなので、マウント側のEC2でDRBDを行うことになります。
このケースも試してみたいのですが、今回は見送ります。


GlusterFS


今回はGlusterFSという分散ファイルシステムを使用してみます。



前回の記事までは、Gatewayインスタンスが1つでしたがこれを2つにして、冗長化を図ります。
また、これらのGatewayインスタンスにさらに複数のイニシエータが接続し、それぞれが担当するGatewayのiSCSIをマウントし、もう一方をGlusterFSで互いをレプリカとしてミラーリングしあいます。

まず、前回と同じ手順でStorageGatewayをもう一つ登録し、Gatewayインスタンスを2つの状態にしておきます。
2つのGatewayインスタンスの内部IPは 10.0.1.5, 10.0.1.6とします。
また、マウント用のインスタンスを2つ用意し、10.0.1.8, 10.0.1.9とします。

そして、10.0.1.8は10.0.1.5の、10.0.1.9は10.0.1.6のGatewayインスタンスのiSCSIボリュームをそれぞれマウントします。


10.0.1.8
# mkdir /mnt/sgw
# iscsiadm  --mode node --targetname iqn.1997-05.com.amazon:memorycraft-sgw --portal 10.0.1.5:3260,1 --login

# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root  9  2月 25 00:08 2013 ip-10.0.1.5:3260-iscsi-iqn.1997-05.com.amazon:memorycraft-sgw-lun-0 -> ../../sda
lrwxrwxrwx 1 root root  9  2月 25 00:48 2013 ip-10.0.1.6:3260-iscsi-iqn.1997-05.com.amazon:memorycraft-sgw2-lun-0 -> ../../sdb
lrwxrwxrwx 1 root root 11  2月 23 17:54 2013 xen-vbd-2049 -> ../../xvde1

# mkfs.ext4 /dev/sda
# mount /dev/sda /mnt/sgw


10.0.1.9
# mkdir /mnt/sgw2
# iscsiadm  --mode node --targetname iqn.1997-05.com.amazon:memorycraft-sgw2 --portal 10.0.1.6:3260,1 --login


# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root  9  2月 25 00:08 2013 ip-10.0.1.5:3260-iscsi-iqn.1997-05.com.amazon:memorycraft-sgw-lun-0 -> ../../sda
lrwxrwxrwx 1 root root  9  2月 25 00:48 2013 ip-10.0.1.6:3260-iscsi-iqn.1997-05.com.amazon:memorycraft-sgw2-lun-0 -> ../../sdb
lrwxrwxrwx 1 root root 11  2月 23 17:54 2013 xen-vbd-2049 -> ../../xvde1


# mkfs.ext4 /dev/sdb
# mount /dev/sdb /mnt/sgw2


次に、10.0.1.8で10.0.1.9をGlusterのピアとして登録し、互いをレプリカとしてGlusterボリュームを作成します。

10.0.1.8
# gluster peer probe 10.0.1.9
# gluster volume create gv0 replica 2 10.0.1.8:/mnt/sgw 10.0.1.9:/mnt/sgw2

すると、双方にgv0というデバイスが接続されるので、これをglusterfsとしてマウントします。


10.0.1.8, 10.0.1.9
# mount -t glusterfs 10.0.1.8:/gv0 /mnt/gv
# ls -l /mnt/gv
drwx------  2 root root     16384  2月 25 00:47 2013 lost+found


一方でファイルを作成すると、

10.0.1.8
# echo "hoge" > /mnt/gv/hoge.txt


10.0.1.9
# ls -l /mnt/gv
-rw-r--r--  1 root root         5  2月 25 01:26 2013 hoge.txt
drwx------  2 root root     16384  2月 25 00:47 2013 lost+found


もう一方にも更新が反映されています。
また、一方のゲートウェイインスタンス(10.0.1.6)を落としても、、、


それぞれのイニシエータでは問題なくファイル操作できるようです。


10.0.1.8
# echo "111" > /mnt/gv/111.txt

# ls -l /mnt/gv/
-rw-r--r--  1 root root         5  2月 25 03:42 2013 111.txt
-rw-r--r--  1 root root         5  2月 25 01:26 2013 hoge.txt
drwx------  2 root root     16384  2月 25 00:47 2013 lost+found


10.0.1.9
# echo "222" > /mnt/gv/222.txt
# ls -l /mnt/gv/
-rw-r--r--  1 root root         5  2月 25 03:42 2013 111.txt
-rw-r--r--  1 root root         4  2月 25 03:42 2013 222.txt
-rw-r--r--  1 root root         5  2月 25 01:26 2013 hoge.txt
drwx------  2 root root     16384  2月 25 00:47 2013 lost+found


とりあえず、これで冗長化はできました。
GlusterFSはFUSEを使うこともあり少しパフォーマンスが落ちますが、
GlusterFSに関わらず、以下のような対策でパフォーマンスは上がるかもしれません。

  • fuseのバージョンを変えてみる
  • ファイルシステムをxfsにしてみる、
  • EBS-Optimizedインスタンスにしてみる
  • PIOPS-EBSにしてみる
  • GlusterFSを4台構成でstriped + replicaにしてみる
などなどです。

また、他のクラスタソリューションを試してみても良いかもしれません。

  • GFS
  • OCFS
  • Lustre
  • ....

また、lsyncd+rsyncdなど二重化をするほうほうなど方法はまだまだありますので、要件にあわせていろいろ探ってみるのも良いと思います。

以上です。

StorageGatewayってなんじゃ?(スナップショットからの復元)

前回、Storage GatewayをEC2にマウントしてみました。
運用中、ボリュームのデータがおかしくなったり、オペレーションミスで以前の状態に復旧したい場合があります。

その場合の定期的なスナップショットから復元する方法です。




ざっくりですが、少し試してみました。
まず、StorageGateway画面で、スナップショットをとりました。



スナップショットはEBSボリュームとして作成されるようで、StorageGatewayの「Snapshots」からも参照できます。




そして、「CreateVolume」を選択します。
すると、ボリューム作成画面が表示されますが、名前を「memorycraft-sgw2」、ホストIPを「10.0.1.5」にして「Create Volume」をクリックします。ちなみにホストIPをNICの別のIPを選ぶと、iSCSIのエンドポイントが変わるため、既存の接続が切れてしまうので注意が必要です。



すると、ボリュームが1つ追加されました。
そして、EC2のマウント用インスタンスで10.0.1.5のインターフェースを探してみると、、、
# iscsiadm --mode discovery --type sendtargets --portal 10.0.1.6:3260
10.0.1.5:3260,1 iqn.1997-05.com.amazon:memorycraft-sgw
10.0.1.5:3260,1 iqn.1997-05.com.amazon:memorycraft-sgw2


認識されました。とりあえず、このsgw2の方をログインしてみると、
# iscsiadm  --mode node --targetname iqn.1997-05.com.amazon:memorycraft-sgw2 --portal 10.0.1.5:3260,1 --login
Logging in to [iface: default, target: iqn.1997-05.com.amazon:memorycraft-sgw2, portal: 10.0.1.5,3260] (multiple)
Login to [iface: default, target: iqn.1997-05.com.amazon:memorycraft-sgw2, portal: 10.0.1.5,3260] successful.
# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root  9  2月 23 19:27 2013 ip-10.0.1.5:3260-iscsi-iqn.1997-05.com.amazon:memorycraft-sgw-lun-0 -> ../../sdb
lrwxrwxrwx 1 root root  9  2月 24 03:08 2013 ip-10.0.1.5:3260-iscsi-iqn.1997-05.com.amazon:memorycraft-sgw2-lun-0 -> ../../sda
lrwxrwxrwx 1 root root 11  2月 23 17:54 2013 xen-vbd-2049 -> ../../xvde1

sdaにアタッチできたようです。
また、sgwの方をログアウトします。
# iscsiadm  --mode node --targetname iqn.1997-05.com.amazon:memorycraft-sgw --portal 10.0.1.5:3260,1 --logout
Logging out of session [sid: 2, target: iqn.1997-05.com.amazon:memorycraft-sgw, portal: 10.0.1.5,3260]
Logout of [sid: 2, target: iqn.1997-05.com.amazon:memorycraft-sgw, portal: 10.0.1.5,3260] successful.


次にsdaの方を/mnt/sgwにマウントしなおします。
# umount /mnt/sgw
# mount /dev/sda /mnt/sgw

# ls -l /mnt/sgw
合計 44
drwxr-xr-x 14 root root  4096  2月 23 19:19 2013 cassandra
drwxr-xr-x 25 root root  4096  2月 23 19:12 2013 linux
drwxr-xr-x  3 root root  4096  2月 23 19:40 2013 linux2
drwx------  2 root root 16384  2月 23 18:37 2013 lost+found
drwxr-xr-x 28 root root  4096  2月 23 18:43 2013 perl
drwxr-xr-x  7 root root  4096  2月 23 19:18 2013 redis
drwxr-xr-x  4 root root  4096  2月 23 18:48 2013 symfony
drwxr-xr-x 11 root root  4096  2月 23 18:47 2013 v8


データが正しくコピーされたようです。
また、StorageGatewayではスナップショットを定期的にとるように設定することができます。
これらの操作はAPIでも提供されていますし、ある時点までの自動バックアップ-リストアはできそうです。


以上です。

2013年2月23日土曜日

Storage Gatewayってなんじゃ?(EC2のCentOSにS3をマウント)

AWSにStorageGatewayというサービスがあります。StorageGatewayはオンプレミスのデータをS3へ直接保存するための接続サービスですが、EC2の世界でも利用することができます。

今回は、StorageGatewayでS3の領域をVPC内のEC2にマウントしてみたいと思います。


ゲートウェイの作成


StorageGatewayの画面の左ペインに「Deploy a new Gateway on Amazon EC2」というリンクをクリックします。




するとダイアログが立ち上がり、アクティベーションダイアログが起ち上がります。
赤枠の「Launch Gateway AMI」のリンクをクリックします。



StorageGateway用のAMIの説明画面が開きます。
「Continue」ボタンをクリックします。




AMIの選択画面になり、「1-Click Launch」と「Launch with EC2 Console」のタブがあるので選択肢、TokyoリージョンのAMIをクリックします。料金表をみるとGatewayインスタンスはxlargeから使用可能のようです。




すると確認画面が表示されるので、「Continue」をクリックします。



先ほど「Launch with EC2 Console」を選んだので、EC2のダイアログが起ち上がります。
一番グレードの低いxlargeを選択し、今回はVPCのprivateサブネットを選択します。



あとは通常どおりに進んでいきます。ここではプライベートIPを10.0.1.5に割り当てます。




そのまま次へ進んでいきます。EBSボリュームの設定画面が表示されます。
StorageGatewayではストレージボリューム以外にもキャッシュやバッファ用のボリュームが必要です。ここで追加することも可能ですが、今回はこのまま進み、後から追加することにします。



セキュリティグループのところでは、あとでiscsiを使用するため、このインスタンスをマウントするEC2からiscsiインターフェスでマウントするためデフォルトポート3260をセキュリティグループに含めます。また、設定作業用のSSHポートもあけておきます。
  • 22  10.0.0.0/16
  • 3260 10.0.0.0/16




後はそのまま進み、インスタンスが起ち上がったらEIPを付与します。
VPCの場合でもアクティベーションに使用するので、一時的にEIPをつけておきます。




ここで、先ほどのStrageGatewayの画面にもどり、IPアドレス欄にEIPを入力して、「Proceed to Activation」をクリックします。



するとStrageGatewayのコンソールにゲートウェイのVMの設定が表示されます。
タイムゾーンを選択し、Gatewayの名前を入力して「Activate My Storage Gateway」をクリックします。


すると、以下のような画面になり、ゲートウェイが表示されます。



次に、キャッシュとバッファ用のEBSを作成し、ゲートウェイインスタンスにアタッチします。(インスタンス作成の時に同時に行なっても構いません)


StorageGatewayの画面に戻り、「Create Volume」をクリックするとダイアログが現れるので、キャッシュボリュームとアップロードバッファのデバイスをそれぞれ選択します。今回はキャッシュボリュームに20GB、バッファボリュームに10GBのボリュームを割り当てます。




「Next」をクリックすると、このキャッシュとバッファのボリュームのそれぞれ使用容量のアラームの設定画面が表示されるので、適宜設定していきます。
今回はデフォルトのままメールアドレスを入力し次へすすみます。




すると、ゲートウェイ用ボリュームの設定になります。ここでは実際に使用するファイルストレージとしての容量とiSCSIのターゲットのエンドポイントを決めるIDを入力します。
ここでは、容量は1TB、iSCSIターゲットのIDをmemorycraft-sgwとして最後に「Create Volume」ボタンをクリックします。




するとゲートウェイボリューム作成完了と表示されます。



ここまで出来たらゲートウェイ自体は完了です。




ゲートウェイボリュームをEC2(CentOS)にマウント


次に、作成したゲートウェイボリュームをEC2上のCentOSインスタンスにマウントします。

このボリュームをマウントするためのインスタンスを新たに立ち上げます。



ここから先は、このインスタンスにSSH接続しての設定になります。
StorageGatewayはiSCSIインターフェースなので、このインスタンスをiSCSIイニシエータにするための設定を行います。

まずiSCSIイニシエータツールをインストールして、設定ファイルをStorageGateway用に変更し、起動します。
AWSの資料では、設定は例としてカスタマイズしたほうがよいそうで、それにならって変更します。
実際には用途に応じて適切な値を設定することをお勧めします。
# yum install -y iscsi-initiator-utils
# vim /etc/iscsi/iscsid.conf
~

node.session.timeo.replacement_timeout = 600
node.conn[0].timeo.noop_out_interval = 60
node.conn[0].timeo.noop_out_timeout = 600

~
# /etc/init.d/iscsi start


iscsiadmコマンドでネットワーク内のiscsiターゲットを探してみます。
ゲートウェイインスタンスはVPC内で10.0.1.5を設定したため、10.0.1.5を探します。
# iscsiadm --mode discovery --type sendtargets --portal 10.0.1.5:3260
iscsid を起動中:                                           [  OK  ]
10.0.1.5:3260,1 iqn.1997-05.com.amazon:memorycraft-sgw


StorageGatewayで作成したボリュームが見つかりました。
これに接続します。
# iscsiadm  --mode node --targetname iqn.1997-05.com.amazon:memorycraft-sgw --portal 10.0.1.5:3260,1 --login
Logging in to [iface: default, target: iqn.1997-05.com.amazon:memorycraft-sgw, portal: 10.0.1.5,3260] (multiple)
Login to [iface: default, target: iqn.1997-05.com.amazon:memorycraft-sgw, portal: 10.0.1.5,3260] successful.


次に、デバイスとしてアタッチされているか見てみます。
# ls -l /dev/disk/by-path/
合計 0
lrwxrwxrwx 1 root root  9  2月 23 18:09 2013 ip-10.0.1.5:3260-iscsi-iqn.1997-05.com.amazon:memorycraft-sgw-lun-0 -> ../../sda
lrwxrwxrwx 1 root root 11  2月 23 17:54 2013 xen-vbd-2049 -> ../../xvde1


/dev/sdaにアタッチされているようです。
これをマウントしてみます。
# mkfs.ext4 /dev/sda

ke2fs 1.41.12 (17-May-2010)
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
67108864 inodes, 268435456 blocks
13421772 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
8192 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
 102400000, 214990848

Writing inode tables: done                           
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

# mkdir /mnt/sgw
# mount /dev/sda /mnt/sgw
# df -h

Filesystem            Size  Used Avail Use% マウント位置
/dev/xvde1            6.0G  2.6G  3.1G  47% /
none                  3.7G     0  3.7G   0% /dev/shm
/dev/sda             1008G  200M  957G   1% /mnt/sgw


おー、ちゃんと1TBがマウントされたようです。
ここに、以前s3syncのときにつかった大量のファイルを置いてみます。
# cd /mnt/sgw/

# git clone https://github.com/mirrors/perl.git
# git clone https://github.com/apache/cassandra.git
# git clone https://github.com/v8/v8.git
# git clone https://github.com/symfony/symfony.git
# git clone https://github.com/torvalds/linux.git

# tree -L 2 .
.
|-- cassandra
|   |-- CHANGES.txt
(略)
|   `-- tools
|-- linux
|   |-- COPYING
(略)
|   `-- virt
|-- perl
|   |-- AUTHORS
(略)
|   `-- x2p
(略)
|   `-- utils
|-- symfony
|   |-- CHANGELOG-2.0.md
(略)
|   `-- src
`-- v8
    |-- AUTHORS
(略)
    `-- tools

# du -sh

1.9G .


ファイル配置も問題ないようです。
また、s3cmdやs3fsのようにファイルリストの取得だけで重くなってしまうことはないようですが、キャッシュボリュームがあるためかも知れません。ファイル総量がキャッシュを超えた時の挙動などはまたの機会に試してみたいと思います。
また、EBSをPIOPSにしたり、EBSOptimizedインスタンスにした場合など、ボトルネックや、冗長化などなど考えると奥が深そうです。

現在のところでは、接続先のS3領域はS3コンソールやAPIからは秘匿されているようです。これらにアクセスできるとまた別の使い方ができるかもしれません。

以上です。

2013年2月22日金曜日

EMRってなんじゃ?(HiveScriptの場合)

前回の記事ではSSHでEMRの中でhiveコンソールをつかって手動でクエリを打ちましたが、通常のプログラムなどからではHiveScriptで起動と同時に実行することが多いと思うので、細かいことですが前回との違いを紹介します。

HiveScriptの場合はスクリプトファイルの場所と、オプションで入力ファイルのS3ロケーションと出力ファイルのS3ロケーションなどを設定します。
前回やったとおり、入出力のロケーションについてはHiveScript中にもEXTERNAL TABLEとして記載できるのでここではHiveScriptのみの設定でOKです。

ただしHiveScriptの場合、スクリプトのS3ロケーションの部分を前回と内容を少しかえる必要があります。
前回は入力のバケットファイルをファイルパスまで指定しましたが、今回はバケットフォルダで指定し、その下の全てのファイルが入力となります。



hive.q
CREATE EXTERNAL TABLE IF NOT EXISTS csv_origin (yyyy string, mm string, dd string, title string, body string) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' LOCATION 's3://csv-origin/input/';

CREATE EXTERNAL TABLE IF NOT EXISTS csv_archive (dd string, title string, body string) PARTITIONED BY (yyyy string, mm string) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' STORED AS TEXTFILE LOCATION 's3://csv-archive/rslt/';                                                              

set hive.exec.dynamic.partition=true;
set hive.exec.dynamic.partition.mode=nonstrict;
FROM csv_origin co INSERT OVERWRITE TABLE csv_archive PARTITION (yyyy, mm)
SELECT
 co.dd,
 co.title,
 co.body,
 co.yyyy,
 co.mm
DISTRIBUTE BY co.yyyy, co.mm;



スクリプト用のバケットにスクリプトファイルを配置します。



EMRでJob Flowを作成し、Hive Programを選択します。
いまアップしたスクリプトファイルの場所を設定します。

Script Location: s3://hivescript-test/hive.q



あとはそのまま実行します。
しばらくするとジョブが終了し、出力を確認できます。




03,title32,body32
16,title33,body33



以上です。

2013年2月19日火曜日

RDSってなんじゃ?(MySQL on EBS-PIOPS vs RDS-PIOPS)

最近、Provisioned IOPS(以下PIOPS)という機能がEBSとRDSで使用できるようになりました。
そこで、EBS with PIOPS上のMySQLと、RDS with PIOPSでベンチマークを取ってみました。


RDSの準備


  • db.m1.large
  • 100GB/1000 IOPS 

MySQLインスタンスの起動設定をします。
インスタンスタイプはdb.m1.largeにして、ストレージは100GB、use Provisioned IOPSにチェックをいれて、IOPSを1000に設定します。



あとは手順にしたがって進みます。





EBSの準備


  • EC2はm1.largeのEBS Optimized
  • EBSは(100GB/1000 IOPS)をマウント
  • MySQLのデータディレクトリをEBS上に配置
  • なるべく設定をDBパラメータグループに合わせる


準備


 以下のようにm1.largeを選び、EBS-Optimized instanceにチェックを入れます。



EBS VolumesでVolume Sizeを100GiBにして、Volume TypeをProvisioned IOPSにして、IOPSを1000に設定します。



立ち上がったら、SSHで入ります。
まずEBSをマウントします。
# yum install -y xfsprogs
# mount /dev/xvdf /mnt/data

次に、RDSと同じバージョンのmysqlをインストールします。
# cd /usr/local/src
# curl -OL http://downloads.mysql.com/archives/mysql-5.5/mysql-5.5.27.tar.gz
# tar xzvf mysql-5.5.27.tar.gz
# cd mysql-5.5.27/
# yum install -y cmake ncurses-devel
# cmake . -DCMAKE_INSTALL_PREFIX=/usr/local/mysql -DDEFAULT_CHARSET=utf8 -DDEFAULT_COLLATION=utf8_general_ci -DENABLED_LOCAL_INFILE=true -DWITH_INNOBASE_STORAGE_ENGINE=1 -DWITH_EXTRA_CHARSETS=all -DWITH_READLINE=OFF
# make
# make install

# cat /etc/my.cnf

[mysqld]
user=mysql

datadir=/mnt/data/mysql
socket=/var/lib/mysql/mysql.sock

binlog_cache_size = 32768
binlog_format = MIXED
innodb_additional_mem_pool_size = 2097152
innodb_buffer_pool_size = 4509715660
innodb_file_per_table = 1
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 8388608
innodb_log_file_size = 134217728
key_buffer_size = 16777216
local_infile = 1
log_output = TABLE
log-error = /var/log/mysql/error.log
max_binlog_size = 134217728
max_connections = 477
read_buffer_size = 262144
read_only = false
read_rnd_buffer_size = 524288
thread_stack = 262144
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

# cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysql

mysqlを立ち上げます。
/etc/init.d/mysql start


ベンチマーク用インスタンスの準備


新しくインスタンスを立ち上げ、mysql-benchをインストールします。
mysql-benchの使い方は、以下のサイトに詳しく書かれています。
suz-lab: "mysql-bench"でMySQLのベンチマークの比較
# yum -y install mysql-bench

ベンチマークの実行


# cd /usr/share/sql-bench/
# chmod 755 run-all-tests
# chmod 755 compare-results

RDS
# ./run-all-tests --host=rds-iops.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com --server=mysql --cmp=mysql --machine=rds --database=hoge --user=memorycraft --password=xxxxxxxxxx --log

EBS
# ./run-all-tests --host=ec2-46-51-237-207.ap-northeast-1.compute.amazonaws.com --server=mysql --cmp=mysql --machine=ebs --database=hoge --user=memorycraft --password= xxxxxxxxxx --log


比較


# ./compare-results --cmp=mysql

The test was run with limits from: mysql

The result logs which where found and the options:
 1 mysql-ebs                               : MySQL 5.5.27 
 2 mysql-rds                               : MySQL 5.5.27 

=====================================================
Operation                           |      1|      2|
                                    |mysql-e|mysql-r|
-----------------------------------------------------
Results per test in seconds:                        |
-----------------------------------------------------
ATIS                                |  31.00|  20.00|
alter-table                         |  28.00|  29.00|
big-tables                          |  16.00|  16.00|
connect                             | 339.00| 345.00|
create                              | 707.00|1003.00|
insert                              |2929.00|2092.00|
select                              | 331.00| 301.00|
wisconsin                           |  65.00|  35.00|
-----------------------------------------------------
The results per operation:                          |
-----------------------------------------------------
alter_table_add (100)               |  13.00|  14.00|
alter_table_drop (91)               |  12.00|  14.00|
connect (10000)                     |  26.00|  24.00|
connect+select_1_row (10000)        |  25.00|  26.00|
connect+select_simple (10000)       |  24.00|  25.00|
count (100)                         |   9.00|   8.00|
count_distinct (1000)               |   6.00|   5.00|
count_distinct_2 (1000)             |  13.00|  13.00|
count_distinct_big (120)            |  23.00|  14.00|
count_distinct_group (1000)         |  13.00|   9.00|
count_distinct_group_on_key (1000)  |  11.00|   9.00|
count_distinct_group_on_key_parts (1|  12.00|   9.00|
count_distinct_key_prefix (1000)    |   5.00|   4.00|
count_group_on_key_parts (1000)     |   6.00|   6.00|
count_on_key (50100)                |  78.00|  77.00|
create+drop (10000)                 | 124.00| 160.00|
create_MANY_tables (10000)          | 117.00| 187.00|
create_index (8)                    |   0.00|   0.00|
create_key+drop (10000)             | 424.00| 631.00|
create_table (31)                   |   0.00|   0.00|
delete_all_many_keys (1)            |  25.00|  26.00|
delete_big (1)                      |   0.00|   0.00|
delete_big_many_keys (128)          |  25.00|  26.00|
delete_key (10000)                  |  12.00|   8.00|
delete_range (12)                   |   3.00|   3.00|
drop_index (8)                      |   1.00|   0.00|
drop_table (28)                     |   0.00|   0.00|
drop_table_when_MANY_tables (10000) |  38.00|  20.00|
insert (350768)                     | 695.00| 357.00|
insert_duplicates (100000)          |  39.00|  39.00|
insert_key (100000)                 | 224.00| 141.00|
insert_many_fields (2000)           |   6.00|   6.00|
insert_select_1_key (1)             |   3.00|   3.00|
insert_select_2_keys (1)            |   4.00|   5.00|
min_max (60)                        |   5.00|   5.00|
min_max_on_key (85000)              |  39.00|  38.00|
multiple_value_insert (100000)      |   2.00|   2.00|
once_prepared_select (100000)       |  45.00|  44.00|
order_by_big (10)                   |  18.00|  18.00|
order_by_big_key (10)               |  17.00|  17.00|
order_by_big_key2 (10)              |  16.00|  17.00|
order_by_big_key_desc (10)          |  17.00|  17.00|
order_by_big_key_diff (10)          |  17.00|  16.00|
order_by_big_key_prefix (10)        |  17.00|  17.00|
order_by_key2_diff (500)            |   1.00|   2.00|
order_by_key_prefix (500)           |   1.00|   1.00|
order_by_range (500)                |   1.00|   1.00|
outer_join (10)                     |  11.00|  11.00|
outer_join_found (10)               |  11.00|  11.00|
outer_join_not_found (500)          |   9.00|   8.00|
outer_join_on_key (10)              |   8.00|   7.00|
prepared_select (100000)            |  52.00|  48.00|
select_1_row (100000)               |  38.00|  38.00|
select_1_row_cache (100000)         |  38.00|  38.00|
select_2_rows (100000)              |  40.00|  48.00|
select_big (80)                     |  17.00|  17.00|
select_big_str (10000)              |  43.00|  42.00|
select_cache (10000)                |  49.00|  46.00|
select_cache2 (10000)               |  55.00|  47.00|
select_column+column (100000)       |  39.00|  38.00|
select_diff_key (500)               |   1.00|   0.00|
select_distinct (800)               |   3.00|   2.00|
select_group (2911)                 |  12.00|  11.00|
select_group_when_MANY_tables (10000|   4.00|   5.00|
select_join (100)                   |   0.00|   0.00|
select_key (200000)                 |  99.00|  95.00|
select_key2 (200000)                | 119.00| 113.00|
select_key2_return_key (200000)     | 117.00| 116.00|
select_key2_return_prim (200000)    | 115.00| 110.00|
select_key_prefix (200000)          | 108.00| 103.00|
select_key_prefix_join (100)        |   4.00|   4.00|
select_key_return_key (200000)      |  96.00|  93.00|
select_many_fields (2000)           |  10.00|  10.00|
select_range (410)                  |  30.00|  33.00|
select_range_key2 (25010)           |   9.00|  10.00|
select_range_prefix (25010)         |   9.00|  10.00|
select_simple (100000)              |  33.00|  34.00|
select_simple_cache (100000)        |  33.00|  32.00|
select_simple_join (500)            |   1.00|   1.00|
update_big (10)                     |  29.00|  37.00|
update_of_key (50000)               |  99.00|  56.00|
update_of_key_big (501)             |  28.00|  19.00|
update_of_primary_key_many_keys (256|  74.00|  86.00|
update_with_key (300000)            | 596.00| 307.00|
update_with_key_prefix (100000)     | 198.00|  99.00|
wisc_benchmark (114)                |   3.00|   3.00|
-----------------------------------------------------
TOTALS                              |4452.00|3852.00|
=====================================================


 RDSの方が良い数値のようです。やはり最適化されているみたいですね。

ちなみに、ベンチマーク中のCloudWatchでも性能差が出ていました。
どちらもディスク操作/秒の値です。


RDS


1000 IOPSを上回る数値が出ています。
その後、落ち着くと1000で頭打ちになりました。




EBS


最初から1000で頭打ちで、ベンチマーク自体もRDSより時間がかかっています。




EBSの方は、設定やチューニングなどでもっとRDSの値に近づけられるのかもしれませんが、RDSならその手間も必要なく簡単に使うことができるということでしょうか。


以上です。

2013年2月18日月曜日

S3ってなんじゃ?(ダウンロードだけを特定のIPに制限する)


S3の特定のフォルダだけダウンロードをIP制限したい場合があります。
こういった場合には、S3のBucketPolicyが便利です。

たとえば以下のようなフォルダ内の画像ファイルにアクセスします。




すると以下の画像が表示されます。




この画像が入っているフォルダに対してIP制限してみます。
バケットポリシー画面を開きます。




ここに以下のように入力します。
{
  "Version": "2008-10-17",
  "Id": "Policy1360868462747",
  "Statement": [
    {
      "Sid": "Stmt1360868457064",
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::myfirst-bucket/img/*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "xxx.xxx.xxx.xxx/32"
        }
      }
    }
  ]
}

ジェネレータで作成しても構いません。

内容としては、
  • 全てのAWSアカウントを対象に
  • myfirst-bucket/img/*にマッチするファイルへの
  • s3のGetObjectのアクセスに関して
  • xxx.xxx.xxx.xxx/32以外のIPからの要求を
  • 拒否します

ということになります。

「Save」で設定したあと、再度アクセスしてみると



このようにエラーとなり、xxx.xxx.xxx.xxxのIP以外からのアクセスでは画像が表示されなくなりました。
他にもActionを色々変えたり追加することによって、アップロードを制限したり、一覧を制限したりすることができます。

以上です。

2013年2月14日木曜日

Cassandraってなんじゃ?(EC2でDataStaxOpsCenterを動かす)

前回の記事で、Cassandraでクラスタリングをした場合、クラスタの情報をみるためのnodetoolの紹介をしました。
ただ、nodetoolやcassandra-cliでは、ノードの構成や配置が複雑だったりデータの分布を直感的に確認することは大変です。

そんな場合、DataStax社が提供しているOpsCenterという管理画面ツールを使うと便利なようです。DataStaxはApache Cassandraのプロジェクトリーダーが起こした会社でcassandraのコミッタの多くが在籍しているそうです。

DataStax OpsCenterに関しては、以下のサイトで紹介されています。
Cassandraクラスタと、DataStax OpsCenterの構築

また、DataStaxの公式サイトに詳細なガイドがあります。
DataStax OpsCenter Documentation

これらのサイトを参考に、OpsCenterをEC2にインストールしてみました。いくつかEC2ならではの部分やはまった点に触れながら手順を紹介しようと思います。


OpsCenterのインストール


前回の記事でAPIアクセスをしたpublicサブネットのappサーバーにインストールします。

# cd /usr/local/src/
# rpm -Uvh http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
# cat /etc/yum.repos.d/datastax.repo
[datastax]
name= DataStax Repository
baseurl=http://rpm.datastax.com/community
enabled=1
gpgcheck=0
# yum install opscenter-free -y

接続先の設定をします。
opscenterd.confで設定します。
ここで、seed_hostsには、前回設定したseedインスタンスのIPを指定します。
また、ここではuse_sslをfalseにしてHTTPアクセスにしておきます。

# vi /etc/opscenter/opscenterd.conf
---

[jmx]
port = 7199
[webserver]
port = 8888
interface = 0.0.0.0
[cassandra]
seed_hosts = 10.0.1.10

[agents]
ssh_port = 22
use_ssl = false
https_port = 61621
incoming_port = 61620

---


セキュリティグループの設定


OpsCenterでは、以下のサイトに説明があるように接続に複数のポートを使用するようです。
OpsCenter and OpsCenter agent ports

ここでは以下のようにポートを設定します。

app(OpsCenter)インスタンス
  • 22  10.0.0.0/16 →ssh(natから入る想定)
  • 80  0.0.0.0/0  →通常のWEB接続
  • 8888  0.0.0.0/0  →OpsCenterコンソールのUI画面
  • 61620  10.0.0.0/16 →cassandraの各ノードからOpsCenterへ情報を送るポート

cassandraインスタンス
  • 22  10.0.0.0/16 →ssh(natから入る想定)、agentのインストールに必要
  • 7000  10.0.0.0/16 →cassandraノード同士の通信
  • 7199  10.0.0.0/16 →JMXポート
  • 9160  10.0.0.0/16 →Thrift API
  • 61621  10.0.0.0/16 →OpsCenterから各ノードへの情報取得用ポート


赤字が前回から新たに付与する設定です。


ここまでできたらOpsCenterを起動します。
# /etc/init.d/opscenterd start



ブラウザで確認


それでは、ブラウザでOpsCenterでUIを確認してみます。
app(OpsCenter)インスタンスにEIPをつけて、
http://インスタンスのEIP:8888/
を確認してみます。


おお!表示されました。
seedインスタンスのIPしか設定しませんでしたが、ノードが3つあることは理解されているようです。

しかし現時点では、情報が空のようです。
これは、cassandra側にOpsCenterのエージェントツールがないためです。


エージェントのインストール


次にエージェントをインストールします。
適切な設定がしてあると、OpsCenter側からcassandraにインストールすることが出来るようです。

タイトル部分の「Fix」というリンクをクリックします。



すると、以下のようなダイアログが開き、3つのノードのIPが表示されます。



ここで、「Edit Credentials」というリンクをクリックします。
すると、別のダイアログが更に開き、これらのインスタンスに入るためのユーザーとパスワードなどを聞かれます。


ここでは、rootユーザーか、もしくはsudoersに登録されているユーザーとパスワードを指定します。
sshがパスワードログインを許可していない場合は、「Private Key」に鍵ファイルのテキストをペーストします。
また、ここで登録された情報は永続化されることはない旨の説明が表示されています。
入力を終えたら「Done」ボタンをクリックします。

元のダイアログに戻るので、「Install on all nodes」ボタンをクリックします。
すると、SSHのフィンガープリントを確認されるので、「Accept Fingerprint」ボタンをクリックします。



エラー


しばらくすると、エラーダイアログが表示されてしまいました。



そこで、cassandra側を見てみます。
# ls -l /etc/init.d/ | grep ops
なにもインストールされていないようです。

インストールログがあるようなので、確認します。
# tail -1000f /var/log/opscenter-agent/installer.log
2013-02-13 23:12:09 +0900  Started: Wed Feb 13 23:10:26 2013 - 04:15 ago
2013-02-13 23:12:09 +0900  State  : Sleeping, pid: 25343
2013-02-13 23:10:27 +0900  Could not retrieve mirrorlist http://www.atomicorp.com/mirrorlist/atomic/centos-6-x86_64 error was
2013-02-13 23:10:27 +0900  12: Timeout on http://www.atomicorp.com/mirrorlist/atomic/centos-6-x86_64: (28, 'connect() timed out!')
2013-02-13 23:10:27 +0900  Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os error was
2013-02-13 23:10:27 +0900  12: Timeout on http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os: (28, 'connect() timed out!')
2013-02-13 23:10:27 +0900  Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64 error was
2013-02-13 23:10:27 +0900  12: Timeout on https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64: (28, 'connect() timed out!')
これは、VPCでEIPをつけずにyumインストールをするときによく見るログです。
OpsCenterはSSHでcassandraノードに入ってyumでエージェントをインストールしようとしているようです。


なので、エージェントをインストールするときだけ、各ノードにEIPを付与してあげます。



では同じ手順でリトライしてみます。
OpsCenterの画面で再度「Install on all nodes」をクリックします。



。。。。やはりエラーになります。


くわしい原因が書かれていないので、OpsCenterのログを見てみます。
# tail -1000f /var/log/opscenter/opscenterd.log
2013-02-13 23:30:41+0900 [Test_Cluster]  INFO: Beginning install of OpsCenter agent to 10.0.1.176
2013-02-13 23:30:42+0900 [Test_Cluster]  INFO: Installing rpm package on 10.0.1.176
2013-02-13 23:31:12+0900 [Test_Cluster]  WARN: HTTP request http://10.0.1.227:61621/cluster/datacenter?node_ip=10.0.1.176 failed: Connection was refused by other side: 111: Connection refused.
2013-02-13 23:31:12+0900 [Test_Cluster]  WARN: Unable to collect datacenter, rack information: Failed query to http://10.0.1.227:61621/cluster/datacenter?node_ip=10.0.1.176 : Connection was refused by other side: 111: Connection refused.
2013-02-13 23:31:12+0900 [Test_Cluster]  WARN: HTTP request http://10.0.1.227:61621/cluster/datacenter?node_ip=10.0.1.10 failed: Connection was refused by other side: 111: Connection refused.
2013-02-13 23:31:12+0900 [Test_Cluster]  WARN: Unable to collect datacenter, rack information: Failed query to http://10.0.1.227:61621/cluster/datacenter?node_ip=10.0.1.10 : Connection was refused by other side: 111: Connection refused.
2013-02-13 23:31:12+0900 [Test_Cluster]  WARN: HTTP request http://10.0.1.10:61621/cluster/datacenter?node_ip=10.0.1.227 failed: Connection was refused by other side: 111: Connection refused.


どうやら61621ポートでHTTPリクエストが拒否されているようです。
再度cassandra側を見てみます。
# ls -l /etc/init.d/ | grep ops
-rwxr-xr-x 1 opscenter-agent opscenter-agent  3197  7月  3 05:39 2012 opscenter-agent


今度はインストール自体はできているようです。
このファイルの中を見てみます。
# cat /etc/init.d/opscenter-agent
...
OPSC_ADDR_DIR="/var/lib/opscenter-agent/conf"
...


/var/lib/opscenter-agent/confがcassandra側のエージェント設定ディレクトリのようです。
confディレクトリにはaddress.yamlしかないので、中身を見てみます。
# cat /var/lib/opscenter-agent/conf/address.yaml
stomp_interface: "10.0.0.39"


ググってみたところ、OpsCenter側でSSLをOFFにしてある場合エージェント側でもHTTPSをHTTPに切り替える必要があるようで、use_sslを0に設定するといいようです。
そこで3つのcassandraノードに以下のように設定しました。
# cat /var/lib/opscenter-agent/conf/address.yaml
stomp_interface: "10.0.0.39"
use_ssl: 0



そして、再びOpsCenterの画面をみると、以下の状態になっているので同じ手順で再度「Install on all nodes」をクリックします。





すると、うまくいったようで、OpsCenterの画面が更新されて、情報が表示されるようになりました!





左ペインのメニューを適当にクリックしてみると、、、

CLUSTER:RING VIEW」:ハッシュの分散状態を確認できます。




CLUSTER:PHYSICAL VIEW」:ap-north-eastにまとまっていることがわかります。(Ec2Snitchの場合)




CLUSTER:LIST VIEW」:リスト状にノードが表示されます。




PERFORMANCE」:各ノードや全体平均のパフォーマンス統計情報が表示されます。




Data Modeling」:KeySpaceやColumnFamilyなど、データモデルを追加編集できたりします。




Data Explorer」:登録されているデータも見ることができます。




EVENT LOG」:クラスタに起こったイベントのログを確認できます。



EDIT CLUSTER...」:クラスタの簡単な編集もできるようです。



CLUSTER」の各ビューでは各ノードのアクション(CLEAR、DISCOMMISION、REPAIRなど)もできるようです。一部は有償のEnterprise版にしかできない機能もあるようです。


まとめ



cassandraクラスタの状態がかなり直感的にわかりとても便利そうです。
そして、ここまでできて無料というのはすごいです。

これから勉強しながらちょっとずつ利用してみたいと思います。