kirie.net blog

前に書いた『IAMを使って特定の人に特定のbucketのみ操作を許可する』は操作だけの話だったんですが
AWS Management Consoleを使おうとしたらハマったのでメモ。

1. IAMでユーザ作成。
2. ユーザのポリシーに以下を指定

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Sid": "Stmt1382001691000",
      "Resource": [
        "*"
      ],
      "Effect": "Allow"
    },
    {
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Sid": "Stmt1382001709000",
      "Resource": [
        "arn:aws:s3:::hoge-bucket"
      ],
      "Effect": "Allow"
    },
    {
      "Action": [
        "s3:*"
      ],
      "Sid": "Stmt1382001730000",
      "Resource": [
        "arn:aws:s3:::hoge-bucket/*"
      ],
      "Effect": "Allow"
    }
  ]
}

以上。

ハマったところは
“arn:aws:s3:::hoge-bucket”に対する操作に”s3:ListBucket”を指定するよう書いてるサイトが多いんですが
試したところ、これだけだとバケットを開こうとすると
“Sorry! You were denied access to do that.”
とエラーメッセージが出ます。
AWS Management Consoleでアクセスできるようにするには
“s3:GetBucketLocation”も追加すると操作できるようになりました。

OpenStackは以下を参考にインストール。
http://docs.openstack.org/grizzly/basic-install/apt/content/

インストールバージョンはgrizzly。
OSはUbuntu12.04。
コントローラノード1台、ネットワークノード1台、コンピュータノード2台の構成。

で、インストール後管理画面を開くと異様に遅いOpenStackが。

とりあえずvmstatで状況を確認。

hoge@fuga:~$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  1  34888  73116  35168 881976    0    0  2151   139   83    6  6  1 51 41
 0  1  34888  68032  35200 887116    0    0  5068    76  638 1142  4  1 48 47
 1  0  34888  75720  35144 879248    0    0  6944    48  580 1052  3  1 49 48
 0  1  34888  72124  35144 882692    0    0  4816     0  316  653  1  1 50 49
 2  0  34888  67412  35184 887384    0    0  4736   828  576 1058  3  1 48 48
 0  1  34888  74232  35168 880540    0    0  5580    64 1149 2193  7  1 45 46
 0  1  34888  70512  35192 884328    0    0  3712    80  885 1625  5  1 45 49
 0  1  34888  65428  35200 889336    0    0  5008    24  473  899  2  1 45 53
 0  1  34888  73240  35120 881360    0    0  5872    28  458  847  2  1 51 47
 0  1  34888  68776  35160 885860    0    0  4480   104  672 1174  4  1 40 56
 0  1  34888  64808  35176 889948    0    0  4016    52  547 1064  3  1 49 48
 0  1  34888  72124  35148 882600    0    0  5120     0  300  638  1  0 50 49
 0  1  34888  66420  35148 888280    0    0  5664     0  310  627  1  1 50 49
 0  1  34888  75100  35100 879676    0    0  3760    52 1135 2110  9  1 42 49
 0  1  34888  71504  35180 883196    0    0  3620  1052 1161 2023  6  2 43 50

CPUのwaitが高過ぎますね。

hoge@fuga:~$ top

top - 14:37:50 up 2 days, 21:56,  1 user,  load average: 1.67, 1.54, 1.46
Tasks: 138 total,   2 running, 136 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.8%us,  1.0%sy,  0.0%ni, 47.8%id, 47.3%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   2050020k total,  1977740k used,    72280k free,    23848k buffers
Swap:  2097148k total,    34888k used,  2062260k free,   894848k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1436 mysql     20   0 1310m 191m 3928 S    2  9.6 100:21.52 mysqld
 1996 rabbitmq  20   0 1139m 106m 1844 S    2  5.3  97:33.42 beam.smp
 1341 quantum   20   0  186m  39m 3748 S    1  2.0 100:18.12 python
 1345 cinder    20   0 91428  19m 3324 S    1  1.0  22:43.32 cinder-volume
 1362 nova      20   0  213m  49m 3712 S    0  2.5   1:44.69 nova-consoleaut
 1397 cinder    20   0  197m  35m 3672 S    0  1.8   2:20.62 cinder-schedule
    1 root      20   0 24584 2156 1132 S    0  0.1   4:37.98 init

load averageも高い。動いてるのは強いて言えばmysqldぽい。
beam.smpは見かけない子なのでググってみるとRabbitMQの関係の子らしい。特に原因には関係ないぽい。

ひたすらwaitなのでIOも確認してみる。

hoge@fuga:~$ sudo iotop
Total DISK READ:       4.95 M/s | Total DISK WRITE:     144.30 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
22748 be/4 mysql       4.78 M/s    0.00 B/s  0.00 % 96.90 % mysqld
 2227 be/4 rabbitmq    0.00 B/s    7.80 K/s  0.00 % 17.65 % beam.smp -W w -K true -A30 -P 1048576 --~ir "/var/lib/rabbitmq/mnesia/rabbit@fuga"
27136 be/4 www-data    0.00 B/s    0.00 B/s  0.00 %  0.00 % apache2 -k start
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]

mysqldが犯人で確定。

mysqlが何してるのか確認してみる。

mysql> show processlist;
+------+----------+-----------+----------+---------+------+--------------+------------------------------------------------------------------------------------------------------+
| Id   | User     | Host      | db       | Command | Time | State        | Info                                                                                                 |
+------+----------+-----------+----------+---------+------+--------------+------------------------------------------------------------------------------------------------------+
| 1923 | quantum  | localhost | quantum  | Sleep   |    1 |              | NULL                                                                                                 |
| 1924 | nova     | localhost | nova     | Sleep   |    1 |              | NULL                                                                                                 |
| 1925 | nova     | localhost | nova     | Sleep   |    1 |              | NULL                                                                                                 |
| 1926 | nova     | localhost | nova     | Sleep   |    6 |              | NULL                                                                                                 |
| 1927 | cinder   | localhost | cinder   | Sleep   |    3 |              | NULL                                                                                                 |
| 1928 | cinder   | localhost | cinder   | Sleep   |    7 |              | NULL                                                                                                 |
| 1929 | nova     | localhost | nova     | Sleep   |   11 |              | NULL                                                                                                 |
| 1931 | nova     | localhost | nova     | Sleep   |    7 |              | NULL                                                                                                 |
| 1932 | nova     | localhost | nova     | Sleep   |    7 |              | NULL                                                                                                 |
| 1933 | quantum  | localhost | quantum  | Sleep   |    1 |              | NULL                                                                                                 |
| 1935 | quantum  | localhost | quantum  | Sleep   |    1 |              | NULL                                                                                                 |
| 1936 | quantum  | localhost | quantum  | Sleep   |    0 |              | NULL                                                                                                 |
| 1938 | nova     | localhost | nova     | Sleep   |   16 |              | NULL                                                                                                 |
| 1939 | nova     | localhost | nova     | Sleep   |    6 |              | NULL                                                                                                 |
| 1946 | quantum  | localhost | quantum  | Sleep   |    2 |              | NULL                                                                                                 |
| 1949 | nova     | localhost | nova     | Sleep   |    1 |              | NULL                                                                                                 |
| 1950 | keystone | localhost | keystone | Query   |  238 | Sending data | SELECT token.id AS token_id, token.expires AS token_expires, token.extra AS token_extra, token.valid |
| 1951 | root     | localhost | NULL     | Query   |    0 | NULL         | show processlist                                                                                     |
+------+----------+-----------+----------+---------+------+--------------+------------------------------------------------------------------------------------------------------+

keystoneがデータを送り続けてるらしい。

keystoneのログを見てみる。

root@fuga:/var/log/keystone# tail -f keystone.log
2013-05-27 14:50:00     INFO [sqlalchemy.engine.base.Engine] SELECT role.id AS role_id, role.name AS role_name, role.extra AS role_extra_
FROM role_
WHERE role.id = %s_
 LIMIT %s
2013-05-27 14:50:00     INFO [sqlalchemy.engine.base.Engine] ('bc1d3f04415a4feb89fee7ad327a9f6b', 1)
2013-05-27 14:50:00    DEBUG [keystone.policy.backends.rules] enforce admin_required: {'tenant_id': u'b1493d6491b54dcabb33792632df4945', 'user_id': u'6b06407ab6be40c7a90185774d082921', u'roles': [u'_member_', u'admin']}
2013-05-27 14:50:00     INFO [sqlalchemy.engine.base.Engine] SELECT token.id AS token_id, token.expires AS token_expires, token.extra AS token_extra, token.valid AS token_valid, token.user_id AS token_user_id, token.trust_id AS token_trust_id_
FROM token_
WHERE token.expires > %s AND token.valid = %s
2013-05-27 14:50:00     INFO [sqlalchemy.engine.base.Engine] (datetime.datetime(2013, 5, 27, 5, 50, 0, 186563), 0)

確かにkeystoneが投げてるクエリっぽい。

mysqlに入って実行してみる。

mysql> SELECT token.id AS token_id, token.expires AS token_expires, token.extra AS token_extra, token.valid AS token_valid, token.user_id AS token_user_id, token.trust_id AS token_trust_id  FROM token  WHERE token.expires > '2013-05-27 06:11:45' and token.valid = 0;
Empty set (4 min 44.50 sec)

5分近くかかってる。こいつがつまってそう。

レコード数を確認してみる。

mysql> select table_name,table_rows,data_length/1024/1024 as 'data/MB',index_length/1024/1024 as 'index/MB' from information_schema.TABLES where table_schema='keystone';
+------------------------+------------+---------------+------------+
| table_name             | table_rows | data/MB       | index/MB   |
+------------------------+------------+---------------+------------+
| credential             |          0 |    0.01562500 | 0.03125000 |
| domain                 |          1 |    0.01562500 | 0.01562500 |
| ec2_credential         |          0 |    0.01562500 | 0.00000000 |
| endpoint               |         18 |    0.01562500 | 0.01562500 |
| group                  |          0 |    0.01562500 | 0.01562500 |
| group_domain_metadata  |          0 |    0.01562500 | 0.01562500 |
| group_project_metadata |          0 |    0.01562500 | 0.01562500 |
| migrate_version        |          1 |    0.01562500 | 0.00000000 |
| policy                 |          0 |    0.01562500 | 0.00000000 |
| project                |          3 |    0.01562500 | 0.01562500 |
| role                   |          3 |    0.01562500 | 0.01562500 |
| service                |          6 |    0.01562500 | 0.00000000 |
| token                  |     152946 | 1098.00000000 | 0.00000000 |
| trust                  |          0 |    0.01562500 | 0.00000000 |
| trust_role             |          0 |    0.01562500 | 0.00000000 |
| user                   |          6 |    0.01562500 | 0.01562500 |
| user_domain_metadata   |          0 |    0.01562500 | 0.01562500 |
| user_group_membership  |          0 |    0.01562500 | 0.01562500 |
| user_project_metadata  |          6 |    0.01562500 | 0.01562500 |
+------------------------+------------+---------------+------------+
19 rows in set (0.07 sec)

多いな。

インデックスを確認してみる。

mysql> show index from token;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| token |          0 | PRIMARY  |            1 | id          | A         |      145268 |     NULL | NULL   |      | BTREE      |         |               |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
1 row in set (0.17 sec)

idにしかふられてない。

こいつじゃないかなー。こいつっぽい気がするなー。
10万行超えるレコードを毎回フルスキャンは遅いんじゃないかなー。
expiresとvalidにも張っておいたほうがいいんじゃないかなー。

index作ってみる。

mysql> alter table token add index expires(expires);
Query OK, 0 rows affected (6 min 6.79 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table token add index valid(valid);
Query OK, 0 rows affected (2 min 59.38 sec)
Records: 0  Duplicates: 0  Warnings: 0

効果を確認。

mysql> explain SELECT token.id AS token_id, token.expires AS token_expires, token.extra AS token_extra, token.valid AS token_valid, token.user_id AS token_user_id, token.trust_id AS token_trust_id  FROM token  WHERE token.expires > '2013-05-27 06:11:45' and token.valid = 0;
+----+-------------+-------+------+---------------+-------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key   | key_len | ref   | rows | Extra       |
+----+-------------+-------+------+---------------+-------+---------+-------+------+-------------+
|  1 | SIMPLE      | token | ref  | expires,valid | valid | 1       | const |    4 | Using where |
+----+-------------+-------+------+---------------+-------+---------+-------+------+-------------+
1 row in set (0.02 sec)

mysql> SELECT token.id AS token_id, token.expires AS token_expires, token.extra AS token_extra, token.valid AS token_valid, token.user_id AS token_user_id, token.trust_id AS token_trust_id  FROM token  WHERE token.expires > '2013-05-27 06:11:45' and token.valid = 0;
Empty set (0.00 sec)

効いてる効いてる。

hoge@fuga:~$ top

top - 17:48:25 up 3 days,  1:07,  2 users,  load average: 0.16, 0.35, 0.61
Tasks: 144 total,   2 running, 142 sleeping,   0 stopped,   0 zombie
Cpu(s):  4.6%us,  1.0%sy,  0.0%ni, 93.9%id,  0.5%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2050020k total,  1932860k used,   117160k free,    19116k buffers
Swap:  2097148k total,    52204k used,  2044944k free,   862236k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1341 quantum   20   0  186m  39m 3732 S    4  2.0 104:51.66 python
 1996 rabbitmq  20   0 1132m 105m 1860 S    3  5.3 101:57.68 beam.smp
 1384 nova      20   0  226m  61m 3740 S    1  3.1  17:19.29 nova-conductor
 1345 cinder    20   0 91428  17m 3324 S    0  0.9  23:46.03 cinder-volume
 1436 mysql     20   0 1310m 185m 4196 S    0  9.3 105:59.44 mysqld
 2309 root      20   0 91016 4328 2116 S    0  0.2   0:05.59 apache2

load average下がった。

hoge@fuga:~$ sudo iotop

Total DISK READ:       0.00 B/s | Total DISK WRITE:       2.76 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 1739 be/4 mysql       0.00 B/s  769.22 K/s  0.00 %  0.82 % mysqld
  387 be/3 root        0.00 B/s   26.92 K/s  0.00 %  0.31 % [jbd2/dm-12-8]
 2079 be/4 mysql       0.00 B/s    3.85 K/s  0.00 %  0.03 % mysqld
22747 be/4 mysql       0.00 B/s    3.85 K/s  0.00 %  0.03 % mysqld
 1511 be/4 mysql       0.00 B/s    3.85 K/s  0.00 %  0.02 % mysqld
    1 be/4 root        0.00 B/s    7.69 K/s  0.00 %  0.00 % init

mysqlのIOも下がった。

hoge@fuga:~$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0  52328 130860  24160 847128    0    0  2140   139   15   38  6  1 51 41
 0  0  52328 130852  24160 847132    0    0     0     0  155  297  0  0 100  0
 0  0  52328 130852  24176 847116    0    0     0    52  368  664  2  1 97  0
 0  0  52328 130852  24192 847124    0    0     0   404  959 1834  8  1 91  1
 0  0  52328 130852  24240 847112    0    0     0  1628  598 1147  4  0 96  0
 0  0  52328 130844  24272 847156    0    0     0    64  386  744  2  1 97  0
 0  0  52328 130844  24288 847156    0    0     0    48  484  876  3  0 97  0
 0  0  52328 130844  24312 847160    0    0     0    76  524  991  3  1 96  0
 0  0  52328 130844  24328 847172    0    0     4    44  360  666  2  1 97  1
 0  0  52328 130844  24328 847192    0    0     0     0  151  289  0  0 100  0

waitも下がった。

これで管理画面も正常に動作するようになったよ！

Configuring Windows Components on Amazon EC2
http://aws.amazon.com/articles/1802

見つかりにくいのでメモメモ。

Amazonから提供されているWindows Server 2008のv1.02以前のAMIを利用して作成したサーバを
VPC内で利用しようとするとActivationを要求されます。
その対策。

1.VPCで起動したサーバのActivation先の変更
以下の2つのIPアドレスが提供されているらしい。

• 169.254.169.250
• 169.254.169.251 (backup)

上記IPを指すように手動で設定を変更。　※Administratorで実行しよう

Slmgr.vbs /skms 169.254.169.250
Slmgr.vbs /ato

2.Ec2Configの設定変更
Ec2ConfigにActivation先が登録されているようで
今後VPCで起動するAMIはEc2Configの変更が必要。

C:\Program Files\Amazon\Ec2ConfigService\Settings\ActivationSettings.xml

<?xml version=”1.0″ encoding=”utf-8″?>
<ActivationSettingsTable>
    <!– 
        KMS Servers are searched for/activated against based on 
        settings in this file.  Each “methodSettings” section is
        attempted until a KMS server is found and instance is 
        successfully activated.
    –>
    <!– Try autodiscovery first… –>
    <!– NOTE: Autodiscover clears any KMS that is already set! –>
    <MethodSettings>
        <SetAutodiscover>true</SetAutodiscover>
        <TargetKMSServer/>    
        <DiscoverFromZone/>
        <ReadFromUserData>false</ReadFromUserData>
        <LegacySearchZones>false</LegacySearchZones>
        <DoActivate>true</DoActivate>
    </MethodSettings>
    <!– Try the first virtual IP for VPC instances –>
    <MethodSettings>
        <SetAutodiscover>false</SetAutodiscover>
        <TargetKMSServer>169.254.169.250</TargetKMSServer>
        <DiscoverFromZone/>
        <ReadFromUserData>false</ReadFromUserData>
        <LegacySearchZones>false</LegacySearchZones>
        <DoActivate>true</DoActivate>
    </MethodSettings>
    <!– Try the backup IP for VPC instances… –>
    <MethodSettings>
        <SetAutodiscover>false</SetAutodiscover>
        <TargetKMSServer>169.254.169.251</TargetKMSServer>
        <DiscoverFromZone/>
        <ReadFromUserData>false</ReadFromUserData>
        <LegacySearchZones>false</LegacySearchZones>
        <DoActivate>true</DoActivate>
    </MethodSettings>
    <!– 
        Now search the DNS suffix list.
        This should already have been set by the SetDNSSuffix plugin,
        controlled by the setting in the primary config file.
    –>
    <MethodSettings>
        <SetAutodiscover>false</SetAutodiscover>
        <TargetKMSServer/>
        <DiscoverFromZone/>
        <ReadFromUserData>false</ReadFromUserData>
        <LegacySearchZones>true</LegacySearchZones>
        <DoActivate>true</DoActivate>
    </MethodSettings>
    <GlobalSettings>
        <LogResultToConsole>true</LogResultToConsole>
    </GlobalSettings>
</ActivationSettingsTable>

以上です。

参考サイト
Release: Amazon Virtual Private Cloud on 2011-03-27

S3を使う時に特定の人に特定のbucketだけを許可したい場合。

1. AWS Management Consoleにログイン
2. IAMタブを開く
3. Groupsで「Create New Group」をクリックしWizardを開く
4. Select Policy Templateで「Amazon S3 Full Access」を「Select」
5. 下記の内容にPolicy Documentを修正
6. 「Continue」をクリック「Create Group」でグループを作成
7. 作成したグループに権限を割り当てたいユーザを加えて完了

Pollcy Documentはこんな感じ

{
  “Statement”: [
    {
      “Effect”: “Allow”,
      “Action”: “s3:*”,
      “Resource”: “arn:aws:s3:::hoge.bucket.hoge”
    },
    {
      “Effect”: “Allow”,
      “Action”: “s3:*”,
      “Resource”: “arn:aws:s3:::hoge.bucket.hoge/*”
    }
  ]
}

デフォルトではs3の全てのアクションが全てのリソースに対して許可されたものが作成されます。
そこでテンプレのResourceを修正して特定のbucketのみに変更。

ARNはAmazon Resource Nameの略でリソースを指定していることを表してるようです。
続いてawsのs3を指定しています。
そのあと:を3つ続けbucketを指定します。

ここで一つ目には
arn:aws:s3:::hoge.bucket.hoge
を指定。
これはbucket内のファイルリストの表示などbucketを指定しての操作を許可してます。

続いてコピペでもうひとつ作って修正。
変更点は
arn:aws:s3:::hoge.bucket.hoge/*
とResourceに bucket/* を指定することで
bucket内のオブジェクト全てに対する操作を許可してます。
これでダウンロードやアップロードが可能になるみたい。

何ができるか、についてはActionを指定するらしい（やってない）。

ElasticfoxはFirefox4.0までしか入れられないし
Ubuntu11.04の環境のせいなのかバージョン騙してもうまく入らなかったので
その対応メモ。

まずはElasticfoxのソースコードを落とします。

$ svn co https://elasticfox.svn.sourceforge.net/svnroot/elasticfox elasticfox

プロジェクトのホームはここ。
http://sourceforge.net/projects/elasticfox/

次にバージョン制限を外すため
4.0が上限になっているので、適当に5.0とかに変えてあげます。

elasticfox/trunk/src/install.rdf

<em:maxVersion>4.0</em:maxVersion>

を

<em:maxVersion>5.0</em:maxVersion>

そしてxpiにします。
JAVA_HOME が必要なのでインストールして設定。

$ sudo apt-get install openjdk-6-jdk
$ echo “export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/” >> ~/.profile

そして作成

$ cd elasticfox/trunk
$ ./make.sh

distディレクトリの中にできたxpiをFirefoxにインストールで動きました。

ap-northeast-1も最初から使えるのでgood。

カスタマイズkernelを利用するときに必要なAKIで
先日できたばかりの東京リージョン（AP-northeast-1）が
まだ資料に載っていなかったので
その一覧。

aki-d209a2d3 ec2-public-images-ap-northeast-1/pv-grub-hd0-V1.01-i386.gz.manifest.xml
aki-d409a2d5 ec2-public-images-ap-northeast-1/pv-grub-hd0-V1.01-x86_64.gz.manifest.xml
aki-d609a2d7 ec2-public-images-ap-northeast-1/pv-grub-hd00-V1.01-i386.gz.manifest.xml
aki-d809a2d9 ec2-public-images-ap-northeast-1/pv-grub-hd00-V1.01-x86_64.gz.manifest.xml

hd0がS3 Instance用。
hd00がEBS Instance用。

※自分のkernelの利用手順はこちら
Enabling User Provided Kernels in Amazon EC2
http://aws.amazon.com/articles/3967

概要メモ

• MySQL5.1
• 普通に全機能使える
• RDS 用の API ツールで起動、終了
• 使用料金はEC2インスタンスよりも30%高い
• ストレージ料金はEBSと同じ
• ストレージのサイズは5GBから1TBまで
• 稼働させたままスケールアップ/スケールダウンができる（接続はちょっと切れるみたい）
• インスタンスクラスは自由に変更可能
• ストレージ容量を増やす場合は使用中の容量より10%以上を指定する必要があるらしい
• ストレージ容量の指定は最低でも今と同容量なので減らすことはできない
• バックアップは自動
• バックアップ領域はストレージサイズと同容量が無料
• それ以上は追加料金 $0.15/GB
• スナップショットも作れる
• プレミアムサポートの対象

ついでにDBを使うときの選択指針みたいなものが書いてあった。

• Amazon RDS
  • アプリケーションやツールでRDBが必要な人。
  • MySQL を利用したいが、インフラと DB の管理をしたくない人。
  • 処理性能やストレージ容量を柔軟に拡張して、使った分だけ利用料を払いたい人。
• Amazon EC2 + DB
  • データベースエンジンを自由に選びたい人。
  • データベースサーバーを完全に管理したい人。
• Simple DB
  • 複雑な RDB 処理よりも、検索を主に使う人。
  • データ構造管理の負担が嫌な人。
  • 利用者の介入なしで、自動でスケールアップやスケールダウンのサービスが欲しい人。
  • データのバックアップやソフトウェアのメンテナンスでもサービスの停止が許容できず、常に動いている環境が必要な人。

｜ω・）　＜放置しすぎて書きにくいんだよ

Amazon Relational Database Service という RDB サービスが開始されたので使ってみたよ。

1.使います！
RDSのサイトからサインアップして使います宣言をしてください。
http://aws.amazon.com/rds/

2.APIツールのダウンロード
まずはツールのダウンロード。
Amazon RDS Command Line Toolkit
このあたりにあった。
落としたファイルを適当な場所に展開。
うちはこんな場所へ。

C:\AmazonEC2\RDSCli-1.0.001

3.アクセスキーと環境変数の設定
アクセスキーとシークレットキーを指定してあげる必要がある。
展開したディレクトリの中に

credential-file-path.template

こんなファイルがあるはずなので、このファイルにアクセスキーとシークレットキーを指定。

AWSAccessKeyId=＜Write your AWS access ID＞
AWSSecretKey=＜Write your AWS secret key＞

templateじゃかわいそうなのでファイル名を適当に変更。

credential-file

次に環境変数の設定。

AWS_RDS_HOME=C:\AmazonEC2\RDSCli-1.0.001
AWS_CREDENTIAL_FILE=%AWS_RDS_HOME%\credential-file

RDSのホームと、さきほどのアクセスキーのファイルパスを指定。

準備完了。

4.起動してみる
コマンド

C:\AmazonEC2\RDSCli-1.0.001\bin > rds-create-db-instance testdb01 -s 10 -c db.m1.small -e MySQL5.1 -u master -p

パラメータの意味はこんな感じ。

• testdb01って名前
• ストレージは10GB
• smallインスタンスで
• MySQL5.1のエンジン使う（まだ他は選べないよね？
• ユーザ名はmaster
• パスワードは入力したやつ

結果

DBINSTANCE testdb01 db.m1.small mysql5.1 10 master creating 1
SECGROUP default active
PARAMGRP default.mysql5.1 in-sync

おおおお、creating されてます！

5.確認してみる
コマンド

C:\AmazonEC2\RDSCli-1.0.001\bin>rds-describe-db-instances

結果

DBINSTANCE testdb01 db.m1.small mysql5.1 10 master creating us-east-1d 1
SECGROUP default active
PARAMGRP default.mysql5.1 in-sync

まだ creating 中！
ちょっと急ぎすぎた、おれ。

6.起動完了
再度確認コマンド。結果のヘッダも出力してみた。

C:\AmazonEC2\RDSCli-1.0.001\bin>rds-describe-db-instances –headers

結果

DBINSTANCE DBInstanceId Created Class Engine Storage Master Username Status Endpoint Address
Port AZ Backup Retention
DBINSTANCE testdb01 2009-10-29T03:23:02.312Z db.m1.small mysql5.1 10
master available testdb01.cvircfsordtw.us-east-1.rds.amazonaws.com 3306 us-east-1d 1
SECGROUP Name Status
SECGROUP default active
PARAMGRP Group Name Apply Status
PARAMGRP default.mysql5.1 in-sync

available きたこれ！

testdb01.cvircfsordtw.us-east-1.rds.amazonaws.comってアドレスに
ポート3306でつながるようです。

7.つないでみた
mysql でつないでみた（なぜかこれだけLinux）。

$ mysql -h testdb01.cvircfsordtw.us-east-1.rds.amazonaws.com -P 3306 -u master -p

あれ。。。つながらない。

どうやらセキュリティの設定変更をしなければいけないらしい。

C:\AmazonEC2\RDSCli-1.0.001\bin>rds-authorize-db-security-group-ingress default –cidr-ip 0.0.0.0/0 –headers

これでインターネットのどこからでもつながるぜ！
（ちゃんと使う人はこんなことしちゃいけないんだぞ

再度接続。

$ mysql -h testdb01.cvircfsordtw.us-east-1.rds.amazonaws.com -P 3306 -u master -p

結果

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 34 to server version: 5.1.38-log

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> show databases;
+——————–+
| Database　　　 |
+——————–+
| information_schema |
| innodb　　　　　 |
| mysql　　　　　　|
| tmp　　　　　　　|
+——————–+
4 rows in set (0.19 sec)

つながった！
見える！見えるぞ！

8.スケールアップしてみた
スケール変更ってすごくね？
smallからlargeへ変更を試してみた。

コマンド

C:\AmazonEC2\RDSCli-1.0.001\bin>rds-modify-db-instance testdb01 -c db.m1.large –apply-immediately

結果

DBINSTANCE testdb01 2009-10-29T03:23:02.312Z db.m1.small mysql5.1 10
master available testdb01.cvircfsordtw.us-east-1.rds.amazonaws.com 330
6 us-east-1d 1 db.m1.large
SECGROUP default active
PARAMGRP default.mysql5.1 in-sync

ん？何も変化がなさそうだぞ。

状態を確認。
コマンド

C:\AmazonEC2\RDSCli-1.0.001\bin>rds-describe-db-instances

DBINSTANCE testdb01 2009-10-29T03:23:02.312Z db.m1.small mysql5.1 10
master modifying testdb01.cvircfsordtw.us-east-1.rds.amazonaws.com 330 6 us-east-1d 1 db.m1.large
SECGROUP default active
PARAMGRP default.mysql5.1 in-sync

modifying。
しばし待たれよ。

7分くらい経過後。。。

コマンド

C:\AmazonEC2\RDSCli-1.0.001\bin>rds-describe-db-instances

結果

DBINSTANCE testdb01 2009-10-29T03:23:02.312Z db.m1.large mysql5.1 10
master available testdb01.cvircfsordtw.us-east-1.rds.amazonaws.com 330 6 us-east-1d 1
SECGROUP default active
PARAMGRP default.mysql5.1 in-sync

db.m1.large きたこれ！

ところで modifying 中ってどうなってるの？
再度mysqlで確認。

mysql> show databases;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect…
ERROR 2003 (HY000): Can’t connect to MySQL server on ‘testdb01.cvircfsordtw.us-east-1.rds.amazonaws.com’ (111)
ERROR:
Can’t connect to the server

あ、切れた。

mysql> show databases;
No connection. Trying to reconnect…
ERROR 2003 (HY000): Can’t connect to MySQL server on ‘testdb01.cvircfsordtw.us-east-1.rds.amazonaws.com’ (111)
ERROR:
Can’t connect to the server

つながらない。

mysql> show databases;
No connection. Trying to reconnect…
Connection id: 173
Current database: *** NONE ***
mysql> show databases;

+——————–+
| Database　　　 |
+——————–+
| information_schema |
| innodb　　　　　 |
| mysql　　　　　　|
| tmp　　　　　　　|
+——————–+
4 rows in set (0.19 sec)

つながった。
ちょっと（数分？）切れるけれど、アドレスの変更なくそのまま再開されるようです。

ちなみにスケールダウンもできました。

9.遊び終わったので終了
コマンド

C:\AmazonEC2\RDSCli-1.0.001\bin>rds-delete-db-instance testdb01

結果

Once you begin deleting this database, it will no longer be able to accept
connections.
Are you sure you want to delete this database? [Ny]y
rds-delete-db-instance: Malformed input-FinalDBSnapshotIdentifier is required u
nless SkipFinalSnapshot
is specified.

スナップショットどうするか聞かれた。。。ごめん。
そのまま落とせないなんて親切なやつだな！

スナップショットとらないよオプション付きで実行。

コマンド

C:\AmazonEC2\RDSCli-1.0.001\bin>rds-delete-db-instance testdb01 –skip-final-snapshot

結果

Once you begin deleting this database, it will no longer be able to accept
connections.
Are you sure you want to delete this database? [Ny]y
DBINSTANCE testdb01 2009-10-29T03:23:02.312Z db.m1.small mysql5.1 10
master deleting us-east-1d 1
SECGROUP default active
PARAMGRP default.mysql5.1 in-sync

終了！

とりあえず
起動 -> スケールアップ -> 終了
まで試してみた。

かなり簡単です。
スケールアップもスケールダウンも自由自在です。
バックアップも勝手にしてくれるようです。

ちなみに11月1日からAmazon EC2のインスタンス料金が下がるんですが
下がったインスタンス料金と比較するとRDSは30%高いです。

いいサービスなんだが。。。高いか安いかはまた考えよう。

Amazon EC2のLinuxでX Windowを使うべく設定。

最初はX11 fowardingでなんとかなるんじゃないかと思ったんですが
うまくいかなかったです。。。

そんなわけでVNCに逃げ。

テストにはamazon公式のfedora8(32bit) v1.08を使用しました。

1.インストール
必要パッケージをさくっとインストール。

# yum install vnc-server
# yum groupinstall “X Window System” “GNOME Desktop Environment”

とりあえず一度vncserverを起動させてパスワードと設定ファイル作成。

# vncserver

設定ファイルの修正。
/root/.vnc/xstartup

xterm -geometry 80×24+10+10 -ls -title “$VNCDESKTOP Desktop” &
twm &

をコメントアウト。

exec gnome-session &

を追加。

vnc serverを一度止めて

# vncserver -kill :1

再起動

# vncserver

これで使えるようになります。

ポート番号の話だったりは適当にその他vncの解説を見てください。

2.トラブル発生と対応
ただこのままだと再起動をしたりAMIに保存して起動させようとすると
カーネルパニックが起きました。

Kernel panic – not syncing: Attempted to kill init!

ログを読んでみると原因はSELinuxの様子。

デフォルトではSELinuxは無効になっているんですが
“X Window System”をインストール時にSELinuxのポリシーがインストールされて有効になります。
このロードに失敗して起動中止しているみたいです。

そんなわけでSELinuxを無効化。
/etc/selinux/config

SELINUX=enforcing

を

SELINUX=disabled

に変更。

これで再起動可能になりました。