ラベル AWS の投稿を表示しています。 すべての投稿を表示
ラベル AWS の投稿を表示しています。 すべての投稿を表示

2017-06-27

AWS Management ConsoleのS3新UIで、deletedなオブジェクトをprefix指定でフィルタリング表示する

バージョン管理をenableにしたS3バケットで、大量のdeletedなオブジェクトの中からprefix指定でオブジェクトをピックアップしようとしてみたところ

No keys were found for prefix search.


と言われてしまい、deletedなオブジェクトに対してprefix指定での検索ができませんでした(´・ω・`)



ブラウザ上の操作では

Type a prefix and press Enter to search. Press ESC to clear.

と書かれているフォームにprefixを指定してみても、deletedではない現行バージョンに対して検索してしまうようです。



ワークアラウンドとして、次のように直接URLで指定してあげるとdeletedなオブジェクトに対して検索することができましたよヽ(´ー`)/
https://console.aws.amazon.com/s3/buckets/<バケット名>/<prefix>?showdeleted=true

2016-04-15

CloudWatchのSumな統計値の最新値を採用してはいけない件

Periodとして指定できる最低値は60秒なのだが、最低値の60秒を指定してSumな統計値を取得してみると

最新値は取得タイミングによって変化していく



なので、最新値はfixされている保証がないのでこの値を採用してしまうと後で変わる可能性がある

最新より1つ以上前の値を採用しましょうヾ(*・ω・)シ

$ aws cloudwatch get-metric-statistics \
--region us-east-1 --metric-name Requests \
--namespace AWS/CloudFront \
--statistics Sum \
--dimensions 
 Name=DistributionId,Value=xxxxxxxxxxxxxx \
 Name=Region,Value=Global \
--start-time `date --iso-8601=seconds -d '3 minute ago'` \
--end-time `date --iso-8601=seconds` \
--period 60 \
--output text|sort -k3

Requests
DATAPOINTS 4231.0 2016-04-15T06:54:00Z None
DATAPOINTS 4389.0 2016-04-15T06:55:00Z None
DATAPOINTS 1205.0 2016-04-15T06:56:00Z None

$ aws cloudwatch get-metric-statistics \
--region us-east-1 --metric-name Requests \
--namespace AWS/CloudFront \
--statistics Sum \
--dimensions 
 Name=DistributionId,Value=xxxxxxxxxxxxxx \
 Name=Region,Value=Global \
--start-time `date --iso-8601=seconds -d '3 minute ago'` \
--end-time `date --iso-8601=seconds` \
--period 60 \
--output text|sort -k3

Requests
DATAPOINTS 4231.0 2016-04-15T06:54:00Z None
DATAPOINTS 4389.0 2016-04-15T06:55:00Z None
DATAPOINTS 4380.0 2016-04-15T06:56:00Z None

2016-04-06

ELBのログよりWEBサーバーのログが多くなる件

ELBはクライアントへ応答を返した時点
WEBサーバーはELBへ応答を返した時点
でログを出力するので、ELBからクライアントへの応答が受信キャンセルや回線断などで中断されるとWEBサーバーのログへは残るがELBへのログには残らないという事象が発生する

* test?escapeはレスポンス受信中にescapeボタンを押してレスポンス受信を中断
* test?timeoutはレスポンス受信中にELBのタイムアウトにひっかかり応答中断…この場合はWEBサーバーからELBの応答完了は、ELB→クライアントの応答中断の後となるがWEBサーバーのログには残る
* test?linkdownはレスポンス受信中に回線断で中断


■Apacheのログ抜粋
[06/Apr/2016:10:39:40 +0000] "GET /test?escape HTTP/1.1" 200 95 35008269
[06/Apr/2016:10:41:00 +0000] "GET /test?timeout HTTP/1.1" 200 95 35008254
[06/Apr/2016:10:43:47 +0000] "GET /hoge HTTP/1.1" 403 213 92
[06/Apr/2016:10:43:52 +0000] "GET /piyo HTTP/1.1" 403 213 95
[06/Apr/2016:11:06:39 +0000] "GET /test?linkdown HTTP/1.1" 200 95 35009322
[06/Apr/2016:11:07:30 +0000] "GET /ok HTTP/1.1" 403 211 86

■ELBのログ抜粋
2016-04-06T10:41:00.811664Z 504 0 0 0 "GET https://xxx:443/test?timeout HTTP/1.1"
2016-04-06T10:43:47.905126Z 403 403 0 213 "GET https://xxx:443/hoge HTTP/1.1"
2016-04-06T10:43:51.996916Z 403 403 0 213 "GET https://xxx:443/piyo HTTP/1.1"
2016-04-06T11:07:30.187571Z 403 403 0 211 "GET https://xxx:443/ok HTTP/1.1"

2016-02-04

Amazon Linuxで無料のウイルススキャン実施

オープンソースなantivirus engineであるClamAVが利用できます。

■インストール
# yum install clamav

■設定
# vi /etc/freshclam.conf
Example  表記をコメントアウト

■定義ファイル更新
freshclam

■スキャン実行
clamscan --exclude-dir="/sys/" -r -i /

※以下のようなエラーが出るので、回避策として/sys/を除外しています
LibClamAV Warning: fmap_readpage: pread fail: asked for 4085 bytes @ offset 11, got 0

2013-10-31

S3でディレクトリのファイル一覧を表示する

設置すべきファイルは3つ

<html lang="ja">
<head>

S3 File List



</head>
<body onload="loadXML();">
<div id="result"style="white-space:nowrap;" >
</div>
</body>
</html>

S3のバケットポリシーを設定する
ここでは、ListとGetをxxx.xxx.xxx.xxx/32のアドレスのアクセスのみに絞って許可
{
 "Version": "2008-10-17",
 "Statement": [
  {
   "Sid": "AllowUser",
   "Effect": "Allow",
   "Principal": {
    "AWS": "*"
   },
   "Action": [
    "s3:List*",
    "s3:Get*"
   ],
   "Resource": [
    "arn:aws:s3:::s3-bucket-name",
    "arn:aws:s3:::s3-bucket-name/*"
   ],
   "Condition": {
    "IpAddress": {
     "aws:SourceIp": ["xxx.xxx.xxx.xxx/32"]
    }
   }
  }
 ]
}

これでhttpでhtmlファイルにアクセスすると一覧が表示される

2013-09-08

非RDSのMySQLをRDSへ短時間メンテナンスで移行する方法

非RDSのMySQLをRDSに移行する方法としてまず思い浮かぶのが

  1. 移行先のRDSを用意
  2. メンテナンスを入れて非RDSへの書き込みがなくなるようにする
  3. 非RDSからmysqldump
  4. mysqldumpしたデータをRDSへ投入
  5. 利用するDBをRDSに切り替え
  6. 動作確認
  7. メンテナンス解除

といった具合ですが、データベースに格納されているデータが大きいとメンテナンス時間は長時間に及びます
mysqldumpした後のデータサイズが約40GBの状態で試算してみると
mysqldumpに1時間、投入に3時間ぐらいは掛かりそうな雰囲気でした
これだけ長時間になるとサービスに与える影響が大きいなぁということで、いろいろと調べていてたどり着いたのがこの方法

  1. 非RDSからmysqldump
  2. 移行先のRDSを用意
  3. mysqldumpしたデータをRDSへ投入
  4. RDSを非RDSをマスターとしてレプリケーションするように設定
  5. メンテナンスを入れて非RDSへの書き込みがなくなるようにする
  6. RDSのレプリケーション設定を解除して、マスターモードで稼働するよう設定
  7. 利用するDBをRDSに切り替え
  8. 動作確認
  9. メンテナンス解除
※ただし、RDSを非RDSからレプリケーションさせるには5.5系だと5.5.33以降、5.6系だと5.6.13以降である必要あり

この方法ならば、長時間に及ぶ作業はメンテナンス前に実施してしまい
メンテナンス中に行う作業は短時間の作業のみにできます
1時間もあれば十分な感じです

具体的な方法は次の通り

1.RDS Parameter Groupを3つ準備(デフォルトから変更するパラメータのみ記載)
・データ投入向け RDS Parameter Group
autocommit=0
innodb_flush_log_at_trx_commit=0
innodb_support_xa=0
character-set-client-handshake=0
character_set_client=utf8
character_set_connection=utf8
character_set_database=utf8
character_set_filesystem=utf8
character_set_results=utf8
character_set_server=utf8
・レプリケーション向けRDS Parameter Group
innodb_flush_log_at_trx_commit=0
character-set-client-handshake=0
character_set_client=utf8
character_set_connection=utf8
character_set_database=utf8
character_set_filesystem=utf8
character_set_results=utf8
character_set_server=utf8
・本番運用向けRDS Parameter Group
innodb_flush_log_at_trx_commit=2
character-set-client-handshake=0
character_set_client=utf8
character_set_connection=utf8
character_set_database=utf8
character_set_filesystem=utf8
character_set_results=utf8
character_set_server=utf8

2.RDS起動
5.5系なら5.5.33以降、5.6系なら5.6.13以降を選択
データ投入向けRDS Parameter Groupを選択
binlogを出力しないよう設定(Enabled Automatic BackupsをNoに設定)
Multi AZ=No

3.非RDSでmysql binlogが出力されるよう設定
/etc/my.cnfに以下を設定してrestart
[mysqld]
log-bin=mysql-bin
expire_logs_days=7

4.非RDSでレプリケーション用ユーザ作成
mysql> grant all on *.* to replicator identified by 'password';
Query OK, 0 rows affected (0.09 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.04 sec)

5.非RDSの3306ポートにRDSから接続できるようFWやセキュリティグループを設定

6.既存DBから、フルダンプをファイルに書き出しつつRDSに投入
(投入速度をあげるために、ユニークキー、外部キーのチェックをOFFにしている)
$ (echo "SET unique_checks=0;SET foreign_key_checks=0;"; mysqldump --order-by-primary --add-drop-table --add-locks --master-data=2 --quick --all-databases -udbuser -p) | tee /mnt/storage/dump.sql | mysql -f -urdbuser -p -h xxx.yyy.ap-northeast-1.rds.amazonaws.com database_name

待つこと数時間…

7.書き出したファイルからbinlogのファイル名とポジションを確認
$ grep -m 1 MASTER_LOG /mnt/storage/dump.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000242', MASTER_LOG_POS=24812749;

8.RDSでレプリケーションの設定
CALL mysql.rds_set_external_master('10.xxx.xxx.xxx',3306,'replicator','password','mysql-bin.000242',24812749,0);
Query OK, 0 rows affected (0.11 sec)

CALL mysql.rds_start_replication;

+-------------------------+
| Message    |
+-------------------------+
| Slave running normally. |
+-------------------------+
1 row in set (1.05 sec)

Query OK, 0 rows affected (1.05 sec)

9.RDSでレプリケーションステータスの確認
mysql> show slave status \G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 11069

10.念のためマスター側(非RDS)の方でもプロセスを確認
mysql> show processlist;
| 123 | replicator | ip-10-xxx-xxx-xxx.ap-northeast-1.compute.internal:57028 | NULL    | Binlog Dump |   77 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL  
RDSから接続が来ていますね

このあたりが確認できれば接続はOK
あとは、マスターDBからの遅延時間
Seconds_Behind_Master: 11069
が0になってくれるまで待機


11.待っている間にレプリケーション中にエラーが起きた場合は、内容を確認してスキップするなどして対処する
mysql> CALL mysql.rds_skip_repl_error;
+-------------------------------------+
| Message         |
+-------------------------------------+
| Statement in error has been skipped |
+-------------------------------------+
1 row in set (0.04 sec)

+---------------------------+
| Message      |
+---------------------------+
| Slave is running normally |
+---------------------------+
1 row in set (2.05 sec)

Query OK, 0 rows affected (2.05 sec)

12.Enabled Automatic BackupsをYesに設定
Modifyして1日以上に設定

13.マスター稼働用のパラメータグループに変更

14.RDSをマスターモードに切り替え
mysql> CALL mysql.rds_stop_replication;
+---------------------------+
| Message      |
+---------------------------+
| Slave is down or disabled |
+---------------------------+
1 row in set (1.08 sec)

Query OK, 0 rows affected (1.08 sec)

mysql> CALL mysql.rds_reset_external_master;
+----------------------+
| message        |
+----------------------+
| Slave has been reset |
+----------------------+
1 row in set (0.18 sec)

Query OK, 0 rows affected (0.18 sec)

ここまで来たら、あとは動作確認して終了ヾ(*・∀・)ノ"

2013-08-28

S3とCloudfrontのapache benchによるベンチマーク

条件
S3バケット、apache benchを動作させるEC2インスタンス共に東京リージョン
EC2インスタンスはc1.medium
独自ドメインはR53で管理

1. S3バケットポリシーでアクセス許可をしたtest.txtにS3のURLでアクセス
2. S3バケットポリシーでアクセス許可をしたtest.txtにStatic Website HostingのURLでアクセス
3. S3上のtest.txtにCloudfront経由での配信を設定しCloudfrontのURLでアクセス
4. S3上のtest.txtにCloudfront経由での配信を設定、独自ドメインを割り当て独自ドメインのURLでアクセス

Document Path: /test.txt
Document Length: 10 bytes

結論からいくと平均レスポンスタイムは

良い                                  悪い

パターン3≦パターン4<<超えられない壁(3~4倍の差)<<パターン1≦パターン2

な感じの模様
結果の詳細は以下の通り

1. $ ab -n 10000 -c 10 http://xxx.s3.amazonaws.com/test.txt
1回目
Concurrency Level: 10
Time taken for tests: 33.292 seconds
Complete requests: 10000
Failed requests: 0
Write errors:  0
Total transferred: 3780000 bytes
HTML transferred: 100000 bytes
Requests per second: 300.37 [#/sec] (mean)
Time per request: 33.292 [ms] (mean)
Time per request: 3.329 [ms] (mean, across all concurrent requests)
Transfer rate:  110.88 [Kbytes/sec] received

Connection Times (ms)
       min  mean[+/-sd] median max
Connect: 3   12 31.1   5    3017
Processing: 8   21 90.4  22    3024
Waiting: 8   21 90.4  22    3024
Total:        11   33 96.2  38    3044

Percentage of the requests served within a certain time (ms)
  50%   38
  66%   44
  75%   45
  80%   47
  90%   49
  95%   52
  98%   55
  99%   60
 100% 3044 (longest request)
2回目
Concurrency Level: 10
Time taken for tests: 19.364 seconds
Complete requests: 10000
Failed requests: 0
Write errors:  0
Total transferred: 3780000 bytes
HTML transferred: 100000 bytes
Requests per second: 516.41 [#/sec] (mean)
Time per request: 19.364 [ms] (mean)
Time per request: 1.936 [ms] (mean, across all concurrent requests)
Transfer rate:  190.63 [Kbytes/sec] received

Connection Times (ms)
       min  mean[+/-sd] median max
Connect: 3    6  3.4   9  40
Processing: 5   13 79.5  12    3012
Waiting: 5   13 79.5  12    3011
Total:  8   19 79.7  21    3021

Percentage of the requests served within a certain time (ms)
  50%   21
  66%   23
  75%   23
  80%   23
  90%   24
  95%   25
  98%   30
  99%   37
 100% 3021 (longest request)

2. $ ab -n 10000 -c 10 xxx.s3-website-ap-northeast-1.amazonaws.com
1回目
Concurrency Level: 10
Time taken for tests: 36.137 seconds
Complete requests: 10000
Failed requests: 0
Write errors:  0
Total transferred: 3560000 bytes
HTML transferred: 100000 bytes
Requests per second: 276.73 [#/sec] (mean)
Time per request: 36.137 [ms] (mean)
Time per request: 3.614 [ms] (mean, across all concurrent requests)
Transfer rate:  96.21 [Kbytes/sec] received

Connection Times (ms)
       min  mean[+/-sd] median max
Connect: 4    9 52.1  11    3009
Processing:    10   27 156.2  19    3062
Waiting:       10   27 156.2  19    3061
Total:        14   36 164.7  30    3074

Percentage of the requests served within a certain time (ms)
  50%   30
  66%   32
  75%   33
  80%   33
  90%   35
  95%   40
  98%   58
  99%   73
 100% 3074 (longest request)

2回目
Concurrency Level: 10
Time taken for tests: 31.559 seconds
Complete requests: 10000
Failed requests: 0
Write errors:  0
Total transferred: 3560000 bytes
HTML transferred: 100000 bytes
Requests per second: 316.86 [#/sec] (mean)
Time per request: 31.559 [ms] (mean)
Time per request: 3.156 [ms] (mean, across all concurrent requests)
Transfer rate:  110.16 [Kbytes/sec] received

Connection Times (ms)
       min  mean[+/-sd] median max
Connect: 3    8 42.6   4    3007
Processing:    10   23 116.4  19    3021
Waiting:       10   23 116.4  19    3021
Total:        14   31 124.0  30    3033

Percentage of the requests served within a certain time (ms)
  50%   30
  66%   32
  75%   32
  80%   33
  90%   34
  95%   37
  98%   49
  99%   66
 100% 3033 (longest request)

3. $ ab -n 10000 -c 10 http://xxx.cloudfront.net/test.txt
1回目
Concurrency Level: 10
Time taken for tests: 7.469 seconds
Complete requests: 10000
Failed requests: 0
Write errors:  0
Total transferred: 4161358 bytes
HTML transferred: 100000 bytes
Requests per second: 1338.85 [#/sec] (mean)
Time per request: 7.469 [ms] (mean)
Time per request: 0.747 [ms] (mean, across all concurrent requests)
Transfer rate:  544.09 [Kbytes/sec] received

Connection Times (ms)
       min  mean[+/-sd] median max
Connect: 2    3  0.5   3  12
Processing: 3    4  3.2   4 137
Waiting: 3    4  3.2   4 137
Total:  5    7  3.3   7 140

Percentage of the requests served within a certain time (ms)
  50%    7
  66%    8
  75%    8
  80%    8
  90%    9
  95%   10
  98%   11
  99%   14
 100%  140 (longest request)
2回目
Concurrency Level: 10
Time taken for tests: 8.182 seconds
Complete requests: 10000
Failed requests: 0
Write errors:  0
Total transferred: 4190808 bytes
HTML transferred: 100000 bytes
Requests per second: 1222.17 [#/sec] (mean)
Time per request: 8.182 [ms] (mean)
Time per request: 0.818 [ms] (mean, across all concurrent requests)
Transfer rate:  500.18 [Kbytes/sec] received

Connection Times (ms)
       min  mean[+/-sd] median max
Connect: 2    3  0.7   3  23
Processing: 3    5  2.0   5  41
Waiting: 3    5  2.0   5  41
Total:  5    8  2.2   8  44

Percentage of the requests served within a certain time (ms)
  50%    8
  66%    8
  75%    9
  80%    9
  90%   10
  95%   11
  98%   13
  99%   16
 100%   44 (longest request)

4. $ ab -n 10000 -c 10 http://xxx.hoge.com/test.txt
1回目
Concurrency Level: 10
Time taken for tests: 7.836 seconds
Complete requests: 10000
Failed requests: 0
Write errors:  0
Total transferred: 4190014 bytes
HTML transferred: 100000 bytes
Requests per second: 1276.15 [#/sec] (mean)
Time per request: 7.836 [ms] (mean)
Time per request: 0.784 [ms] (mean, across all concurrent requests)
Transfer rate:  522.18 [Kbytes/sec] received

Connection Times (ms)
       min  mean[+/-sd] median max
Connect: 2    3  1.8   3  27
Processing: 3    5  2.5   4  39
Waiting: 3    4  2.4   4  39
Total:  5    8  3.2   7  53

Percentage of the requests served within a certain time (ms)
  50%    7
  66%    8
  75%    8
  80%    8
  90%    9
  95%   12
  98%   20
  99%   21
 100%   53 (longest request)
2回目
Concurrency Level: 10
Time taken for tests: 8.473 seconds
Complete requests: 10000
Failed requests: 0
Write errors:  0
Total transferred: 4191311 bytes
HTML transferred: 100000 bytes
Requests per second: 1180.20 [#/sec] (mean)
Time per request: 8.473 [ms] (mean)
Time per request: 0.847 [ms] (mean, across all concurrent requests)
Transfer rate:  483.07 [Kbytes/sec] received

Connection Times (ms)
       min  mean[+/-sd] median max
Connect: 2    3  0.6   3  17
Processing: 3    5  5.7   4 198
Waiting: 3    5  5.7   4 198
Total:  5    8  5.7   8 201

Percentage of the requests served within a certain time (ms)
  50%    8
  66%    8
  75%    9
  80%    9
  90%   11
  95%   13
  98%   17
  99%   23
 100%  201 (longest request)

2013-01-24

S3バケットをアカウントを跨いでコピーしてみた

この方法は同じアカウント内でも利用できるので
バケット名の変更、リージョンの変更っていうことも別のバケットを作成してコピーすることで実現可能

利用したツールはDragonDiskというS3に対応したクライアントツール
まずは、コピー先となるアカウントのAWS Management ConsoleのS3の項目で、コピー元のアカウントに対してアクセス権限を付与
  1. 設定するバケット名をクリック
  2. Permissionsのところをクリックして開く
  3. Edit bucket policyをクリック
  4. bucket policyを入力してSaveをクリック
  5. PermissionsのところのSAveをクリック
bucket policyはこんな感じ
{
 "Version": "2008-10-17",
 "Id": "2c08cdf1-ddfc-4765-ac19-26b03a8e8b5e",
 "Statement": [
  {
   "Sid": "AllowUser",
   "Effect": "Allow",
   "Principal": {
    "AWS": "arn:aws:iam::<12桁の数字からなるAWSのユーザID>:root"
   },
   "Action": "s3:*",
   "Resource": [
    "arn:aws:s3:::[S3 bucket name]/*",
    "arn:aws:s3:::[S3 bucket name]"
   ]
  }
 ]
}
今回は、コピー先のS3バケットとその中のオブジェクトに対する全権限を付与しました
そして、いよいよDragonDiskの出番
DragonDiskにはコピー元のアカウントだけ登録されていればOK
  1. Rootのプルダウンからコピー元のアカウントを選択
  2. アクティブになったAdd external bucketをクリック
  3. コピー先になるS3バケット名を入力してOKをクリック
  4. 右ペインでもRootのプルダウンからコピー元のアカウントを選択
  5. ∞みたいなアイコンで追加されたコピー先のS3バケットを選択
  6. 左ペインでコピー元のS3バケットを選択
  7. コピー元のバケットのオブジェクトを選択し右ペインへドラッグアンドドロップ
以上で完了
約119.59GB
6,176ファイル
2,274フォルダ
のコピーが約1分で行えましたよヾ(*・ω・)シ
ちなみに、1ファイルで1GBぐらいあるとそれだけで1分ぐらい
52MBぐらいのファイルを東京→us-eastへのコピーだと70秒ぐらいを要しました

その際、Tools -> Options -> OperationsでMaximum number of concurrent operationsの値を256に
InterfaceのところでMaximum number of concurrent operationsの値を10に
変更して同時に行える処理量を増やしています

2012-11-15

AWS東京リージョンのゾーン間RTTを計測してみた

A,B,C各ゾーンに立てたインスタンスからpingを放ちRTT(Round Trip Time)が安定したところで5回の平均値を出してみた。
それぞれ1つのインスタンスでしか試してないので個体差があるだろうことは否めないので参考程度に。

2012-10-23

オンサービスのままGlusterFSのVolume容量追加してみた

EC2上の2台のサーバから1つずつbrickを提供しレプリケーションモードで動作させているVolumeに、オンサービスのまま容量を追加するという処理を行ってみました。 最初に試したのは、サーバに既存のBrick(/gfs)よりもサイズが大きい新たなEBSを追加し、これを/gfs2にマウントして既存のBrickと置換するという方法。 小さいファイル数個のおためし環境では
gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 start
で、置換開始
gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 status
で、completeになったことを確認
gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 commit
で、コミット の手順でうまくいったので、実際の環境に試してみました 10GBのVolumeには1.5GBぐらいのデータが書き込まれている状態です
gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 start
コマンドは通ったのですが、みるみるcpu使用率が上昇しコンソール操作もままならない程になってしまいました。 このとき利用していたインスタンスタイプはc1.mediumです。
1時間程経過しても処理は終わらないので一時停止
gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 pause
これでとりあえず負荷は下がったのですが、1GB程の一時領域に書き込みつつreplaceが行えるように待機をしている状態のようでした。
このままではよろしくないと、完全にキャンセルしてみました
gluster volume replace-brick vol1 x.x.x.x:/gfs x.x.x.x/gfs2 abort
それはそれで、マシンリソースを喰いまくり、コマンドライン操作を受け付けないほどになってしまったのでデーモン停止(´・ω・`)
service gluster stop
[失敗] だそうな。。。 なので仕方なくpkillしました
pkill gluster
このあと、安定状態に戻すまでかなりの奮闘をしたのでこの方法は避けた方が良さそうです。 次は、上手くいった方法 Volumeに容量の大きなBrick(/gfs2)を追加し、既存のBrick(/gfs)を削除するという方法
gluster volume add-brick vol1 x.x.x.x:/gfs2 y.y.y.y./gfs2
すんなり追加されました つづいて、既存のBrickを削除
gluster volume remove-brick vol1 x.x.x.x:/gfs y.y.y.y./gfs start
startをつけることで、安全にBrickを削除できるように削除対象ではないところにデータを移動してくれるようです。 cpu使用率が上昇しましたが、replaceのようにコンソール操作を受け付けなくなる程ではありませんでした。
gluster volume remove-brick vol1 x.x.x.x:/gfs y.y.y.y./gfs status
で、状態を確認しながらcompleteになるまで待機 8GB程データがある状態で40分程で終了しました あとはコミットするだけ
gluster volume remove-brick vol1 x.x.x.x:/gfs y.y.y.y./gfs commit
これで無事にオンサービスのまま容量を追加することができましたよヾ(*・ω・)シ

2012-09-07

AWS EC2上のCentOS5.8でhttpd-2.4.3(Apache2.4.3)のrpmを作成

まずは依存モジュールをyumで削除&インストール
yum -y erase apr
yum -y install db4-devel expat-devel postgresql-devel sqlite-devel freetds-devel unixODBC-devel nss-devel mysql-devel distcache-devel libuuid-devel lksctp-tools-devel doxygen openldap-devel openssl-devel pcre-devel lua-devel
yumでは入らない依存モジュールのダウンロード&ビルド&インストール
wget http://ftp.jaist.ac.jp/pub/apache/apr/apr-1.4.6.tar.bz2
rpmbuild -tb apr-1.4.6.tar.bz2
yum install --nogpgcheck /usr/src/redhat/RPMS/x86_64/apr-*

wget http://ftp.jaist.ac.jp/pub/apache/apr/apr-util-1.4.1.tar.bz2
rpmbuild -tp --nodeps apr-util-1.4.1.tar.bz2
sed -i "s/libuuid-devel/e2fsprogs-devel/" /usr/src/redhat/BUILD/apr-util-1.4.1/apr-util.spec
mv apr-util-1.4.1.tar.bz2 /usr/src/redhat/SOURCES
rpmbuild -bb /usr/src/redhat/BUILD/apr-util-1.4.1/apr-util.spec
とやったところ、テストでエラー(´・ω・`)
teststrmatch        : SUCCESS
testuri             : SUCCESS
testuuid            : SUCCESS
testbuckets         : SUCCESS
testpass            : SUCCESS
testmd4             : SUCCESS
testmd5             : SUCCESS
testcrypto          : 
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_ECB nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_ECB nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_192/MODE_ECB nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_192/MODE_ECB nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_128/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_128/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_128/MODE_ECB nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_128/MODE_ECB nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_128/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_128/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)                                                          passphrase: KEY_AES_256/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_ECB nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)                                                          passphrase: KEY_AES_256/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_ECB nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
passphrase: KEY_AES_256/MODE_CBC nss native error -8128:  (SEC_ERROR_NO_MODULE)
FAILED 6 of 13
testldap            : SUCCESS
testdbd             : SUCCESS
testdate            : SUCCESS
testmemcache        : SUCCESS
testxml             : SUCCESS
testxlate           : SUCCESS
testrmm             : SUCCESS
testdbm             : SUCCESS
testqueue           : SUCCESS
testreslist         : SUCCESS
Failed Tests            Total   Fail    Failed %
===================================================
testcrypto                 13      6     46.15%
Programs failed: testall
make: *** [check] エラー 1
+ exit 1
エラー: /var/tmp/rpm-tmp.35396 の不正な終了ステータス (%check)
調べてみた感じだとこのあたりにバグ報告されてて解決されてない??
てことで、とりあえずテストすっ飛ばしてビルドしちゃいました(…大丈夫か?)
sed -i "s/libuuid-devel/e2fsprogs-devel/" /usr/src/redhat/BUILD/apr-util-1.4.1/apr-util.spec
sed -i "s/make check || exit 1/make check || \"continue\"/" /usr/src/redhat/BUILD/apr-util-1.4.1/apr-util.spec
rpmbuild -bb /usr/src/redhat/BUILD/apr-util-1.4.1/apr-util.spec
yum install --nogpgcheck /usr/src/redhat/RPMS/x86_64/apr-util-*
wget http://ftp.kddilabs.jp/infosystems/apache/httpd/httpd-2.4.3.tar.bz2
rpmbuild -tp httpd-2.4.3.tar.bz2
mv httpd-2.4.3.tar.bz2 /usr/src/redhat/SOURCES
sed -i "s/%{epoch}://g" /usr/src/redhat/BUILD/httpd-2.4.3/httpd.spec
rpmbuild -bb /usr/src/redhat/BUILD/httpd-2.4.3/httpd.spec
yum install --nogpgcheck /usr/src/redhat/RPMS/x86_64/httpd-*
で、出来上がりヾ(*・ω・)シ

AWS EC2上のCentOS6.2でhttpd-2.4.3(Apache2.4.3)のrpmを作成

ググってみると色々参考記事はあったのですがどうもAWSのEC2上だと
ipv6が有効になってなかったりが原因なのか失敗してしまったので成功したやりかたのメモです。
まずは、依存モジュールのインストール
yum -y install libselinux-devel pcre-devel openldap-devel lua-devel openssl-devel libuuid-devel lksctp-tools-devel db4-devel expat-devel postgresql-devel sqlite-devel freetds-devel unixODBC-devel nss-devel mysql-devel
yumで入らない依存モジュールのダウンロード&ビルド&インストール
wget ftp://ftp.riken.jp/Linux/fedora/development/18/source/SRPMS/d/distcache-1.4.5-23.src.rpm
rpmbuild --rebuild distcache-1.4.5-23.src.rpm
rpm -i ~/rpmbuild/RPMS/x86_64/distcache-*

wget ftp://ftp.riken.jp/Linux/fedora/development/18/source/SRPMS/a/apr-1.4.6-3.fc18.src.rpm
rpmbuild --rebuild apr-1.4.6-3.fc18.src.rpm
rpm -i ~/rpmbuild/RPMS/x86_64/apr-*

wget ftp://ftp.riken.jp/Linux/fedora/development/18/source/SRPMS/a/apr-util-1.4.1-5.fc18.src.rpm
rpmbuild --rebuild apr-util-1.4.1-5.fc18.src.rpm
rpm -i ~/rpmbuild/RPMS/x86_64/apr-util-*
そしていよいよhttpd-2.4.3のダウンロード&ビルド&インストール
wget http://ftp.kddilabs.jp/infosystems/apache/httpd/httpd-2.4.3.tar.bz2
rpmbuild -tp httpd-2.4.3.tar.bz2
mv httpd-2.4.3.tar.bz2 ~/rpmbuild/SOURCES/
sed -i "s/%{epoch}://g" ~/rpmbuild/BUILD/httpd-2.4.3/httpd.spec
rpmbuild -bb ~/rpmbuild/BUILD/httpd-2.4.3/httpd.spec
rpm -i ~/rpmbuild/RPMS/x86_64/httpd-*

2012-08-24

GlusterFSとnfsを比較実験してみた

AWS上でサーバ1台とクライアント3台という構成で実験してみました
各サーバのスペックは
  • nfs,GlusterFSサーバ:t1.micro(ap-northeast-1a)
  • クライアント1:m1.small(ap-northeast-1b)
  • クライアント2:m1.small(ap-northeast-1a)
  • クライアント3:c1.medium(ap-northeast-1a)
という感じでクライアント1だけ別のAvailability Zoneで立てています
サーバのローカルディスクをGlusterFSとnfsそれぞれでマウントしてパフォーマンスと整合性について実験してみます
クライアント1~3でaaaaaaaa,試行回数を同じファイルに60秒間出力するようなコマンドを実行します
start=`date "+%s"`;i=1;while true; do echo aaaaaaaa,$i >> /gfs/test.log ;now=`date "+%s"`;if [ `expr $now - $start` -gt 60 ];then break;fi;i=`expr $i + 1`;done
aaaaaaaaの部分はクライアント1ではa,2ではb,3ではcと置き換えて実行しました
出力先の/gfsはGlusterFSでマウント
/nfsはnfsでマウントした領域です
結果は
GlusterFSでマウントした方は
$ wc -l /gfs/test.log
15841 /gfs/test.log
$ tac /gfs/test.log | grep aaa -m 1
aaaaaaaa,7639
$ tac /gfs/test.log | grep bbb -m 1
bbbbbbbb,4171
$ tac /gfs/test.log | grep ccc -m 1
cccccccc,4031
となり、15841=7639+4171+4031と整合性が保たれているようです
nfsマウントした方は
$ wc -l /nfs/test.log
5461 /nfs/test.log
$ tac /nfs/test.log | grep aaa -m 1
aaaaaaaa,2504
$ tac /nfs/test.log | grep bbb -m 1
bbbbbbbb,1678
$ tac /nfs/test.log | grep ccc -m 1
cccccccc,2484
となり、5461≠2504+1678+2484=6666となりファイルに不整合がでています
パフォーマンスも1/3ぐらいしかでませんでした

2012-07-25

IAM roles for EC2 instancesを使ってみた

EC2インスタンスのIAMロールとは?
  • 今までIPアドレスで利用範囲を絞っていたところを、このEC2インスタンスから!みたいな制約で利用できるようにする機能
  • aws-sdkを使えばcredentials周りのコードを簡略化できる
制約とか
  • roleは、EC2インスタンス起動時に選択することができる
  • roleは1つしか割り当てられない
  • 既存のインスタンスにはroleを割り当てることはできない
  • 既にroleが割り当てられているインスタンスからroleを外すことはできない
  • roleのPermissionsの変更は即時反映される
roleの作成
AWS ConsoleのIAMのところからCreate Roleをクリック
roleの名前を入力してContinue
適当なPolicyをSelect(後から編集もできるのでてきとーに)
Policyの名前を決めて、Policy Documentを確認したらContinue
内容を確認して問題なければCreate Role
はい、出来上がりましたヾ(*・ω・)シ
あとは、作成したroleを割り当ててインスタンスの起動
通常通りインスタンス起動のウィザードを辿っていくとInstance DetailsのところでIAM Roleの選択肢がでてくるので先ほど作成したroleを選択

起動を待っている間に、s3バケットのURLを一覧表示するようなサンプルプログラムの作成
通常版
#! /usr/bin/ruby
require 'rubygems'
require 'aws-sdk'

my_access_key_id = 'xxxxxxxxxxxxxxxxxxxx'
my_secret_key = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

AWS.config({
  :access_key_id => my_access_key_id,
  :secret_access_key => my_secret_key
})

sts = AWS::STS.new()
session = sts.new_session()
#puts "Session expires at: #{session.expires_at.to_s}"

#s3 = AWS::S3.new(session.credentials)

for bucket in s3.buckets
 puts bucket.url
end
てな具合で見慣れたCredentials周りのコードを書く訳ですがIAM roles for EC2 instances版だとここを省くことができます
#! /usr/bin/ruby
require 'rubygems'
require 'aws-sdk'

s3 = AWS::S3.new()

for bucket in s3.buckets
 puts bucket.url
end
と、こんな単純に。
実行結果はどちらも同じように
./list_s3_urls.rb
http://bucket1.s3.amazonaws.com/
http://bucket2.s3.amazonaws.com/
http://bucket3.s3.amazonaws.com/
みたいな感じで表示してくれます
aws-sdkを利用しない場合はcurlを使って
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role1
{
  "Code" : "Success",
  "LastUpdated" : "2012-07-25T04:43:21Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "xxxxxxxxxx",
  "SecretAccessKey" : "xxxxxxxxxx",
  "Token" : "xxx",
  "Expiration" : "2012-07-25T11:15:42Z"
}
みたいに最後の/の後にEC2インスタンスに割り当てられたroleの名前を入れてあげれば、一時的に利用できるAccessKeyIdとSecretAccessKeyを含むレスポンスが得られるのでこれを利用すれば良いみたいです。

2012-06-13

AWS IAMユーザにSigning Certificate(X.509証明書)を追加する

IAM(AWS Identity and Access Management)ユーザにAWS Consoleを利用してSigning Certificateを追加する方法はオフィシャルのドキュメントに書かれている訳ですが、IAM Foxといツールを利用して追加作業をやってみたのでメモφ(・ω・ )

まずは、肝心の鍵ファイルの作成
Linux上のopensslコマンドを利用しました。
1.Private Keyの作成
2048bitでhoge.keyというファイルを作成しました
$ openssl genrsa -des3 -out hoge.key 2048

openssl genrsa -out ozawa.key 2048
Generating RSA private key, 2048 bit long modulus
......................................................+++
.........................................................................+++
e is 65537 (0x10001)
Enter pass phrase for ozawa.key:
Verifying - Enter pass phrase for ozawa.key:
パスフレーズなしにしたい場合は-des3を抜けばOK 2.Certificate Signing Request (CSR)の作成
openssl req -new -key hoge.key -out hoge.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:JP
State or Province Name (full name) [Berkshire]:Tokyo
Locality Name (eg, city) [Newbury]:Tokyo
Organization Name (eg, company) [My Company Ltd]:company
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:hoge
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
住所やら所属やら聞かれるけれど適当に入力 3.Self-Signed SSL Certificatの作成 アップロードするのはこのファイルです。
openssl x509 -req -days 3650 -in hoge.csr -signkey hoge.key -out hoge.crt
Signature ok
subject=/C=JP/ST=Tokyo/L=Tokyo/O=company/CN=hoge
Getting Private key

予め、AWSのアカウントはIAM Foxに登録されていて、IAMユーザが作成されていることを前提にします
4.IAM FoxでSigning Certificateを追加したいユーザを右クリックしてCertificateを選択

5. Addボタンを押してNew Certificateにhoge.crtの中身を入力してOKボタン

6.追加されると、自動的に名前が付与され、StatusがActiveになります

Private Key Fileにあたるのがhoge.key
X.509証明書(X.509 Certificate)にあたるのがhoge.crt
になります。

2011-09-01

EC2インスタンス同士の通信速度を測定してみた

測定には、iperfというツールを用いた。

m2.4xlarge(ap-northeast-1b) <-> m1.large(ap-northeast-1a)の場合
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   929 Mbits/sec

m2.4xlarge(ap-northeast-1b) <-> c1.medium(ap-northeast-1a)の場合
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   935 Mbits/sec

m2.4xlarge(ap-northeast-1b) <-> m1.small(ap-northeast-1b)の場合
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   462 MBytes   388 Mbits/sec

m2.4xlarge(ap-northeast-1b) <-> t1.micro(ap-northeast-1a)の場合
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   176 MBytes   147 Mbits/sec

m1.small(ap-northeast-1b) <-> c1.medium(ap-northeast-1a)の場合
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   461 MBytes   387 Mbits/sec

という訳で、m1.small,t1.microはネットワークインタフェースの帯域が他のインスタンスタイプと比べて絞られているようです。
ゾーンa,bの間では同一ゾーン内でも跨いでも大きく違いは見られませんでした。

2011-08-24

EC2 t1.microインスタンスでCPU stealが発生しまくるっ!

ってことでなんとかできないかと試行錯誤してみました。

13:20頃が普通に負荷をかけた状況
13:40頃が試行錯誤後の状況です

今回負荷をかけるために使用したのは、super piというツール。

パラメータを21として早速実行してみました
./super_pi 21

一発目は3:39
------ Started super_pi run : 2011年 8月 24日 水曜日 13:19:24 JST
Start of PI calculation up to 2097152 decimal digits
End of initialization. Time=       0.543 Sec.
I= 1 L=       0        Time=       1.599 Sec.
I= 2 L=       0        Time=       1.859 Sec.
I= 3 L=       1        Time=       1.846 Sec.
I= 4 L=       2        Time=       1.870 Sec.
I= 5 L=       5        Time=       1.855 Sec.
I= 6 L=      10        Time=       1.846 Sec.
I= 7 L=      21        Time=       1.867 Sec.
I= 8 L=      43        Time=       1.998 Sec.
I= 9 L=      87        Time=       1.857 Sec.
I=10 L=     174        Time=       1.863 Sec.
I=11 L=     349        Time=       1.867 Sec.
I=12 L=     698        Time=       1.863 Sec.
I=13 L=    1396        Time=       1.851 Sec.
I=14 L=    2794        Time=       1.895 Sec.
I=15 L=    5588        Time=       1.973 Sec.
I=16 L=   11176        Time=       1.839 Sec.
I=17 L=   22353        Time=       1.820 Sec.
I=18 L=   44707        Time=       1.806 Sec.
I=19 L=   89415        Time=       1.761 Sec.
I=20 L=  178831        Time=       1.800 Sec.
End of main loop
End of calculation.    Time=      39.002 Sec.
End of data output.    Time=       0.171 Sec.
Total calculation(I/O) time=      39.173(       4.013) Sec.
------ Ended super_pi run : 2011年 8月 24日 水曜日 13:24:03 JST

後半はsteal発生しまくり
続けて二回目を実行すると最初からsteal発生しまくりで7:32
------ Started super_pi run : 2011年 8月 24日 水曜日 13:24:30 JST
Start of PI calculation up to 2097152 decimal digits
End of initialization. Time=       0.587 Sec.
I= 1 L=       0        Time=       1.706 Sec.
I= 2 L=       0        Time=       2.113 Sec.
I= 3 L=       1        Time=       2.018 Sec.
I= 4 L=       2        Time=       1.840 Sec.
I= 5 L=       5        Time=       1.844 Sec.
I= 6 L=      10        Time=       1.891 Sec.
I= 7 L=      21        Time=       1.954 Sec.
I= 8 L=      43        Time=       1.957 Sec.
I= 9 L=      87        Time=       1.878 Sec.
I=10 L=     174        Time=       1.857 Sec.
I=11 L=     349        Time=       1.871 Sec.
I=12 L=     698        Time=       1.944 Sec.
I=13 L=    1396        Time=       2.012 Sec.
I=14 L=    2794        Time=       2.037 Sec.
I=15 L=    5588        Time=       1.841 Sec.
I=16 L=   11176        Time=       1.852 Sec.
I=17 L=   22353        Time=       1.815 Sec.
I=18 L=   44707        Time=       1.793 Sec.
I=19 L=   89415        Time=       1.739 Sec.
I=20 L=  178831        Time=       1.616 Sec.
End of main loop
End of calculation.    Time=      39.638 Sec.
End of data output.    Time=       0.181 Sec.
Total calculation(I/O) time=      39.819(       4.014) Sec.
------ Ended super_pi run : 2011年 8月 24日 水曜日 13:32:02 JST

cpu使用率を制限しちゃえばsteal発生せずに済むんじゃね?
ってことで、cpulimitというツールを使ってcpu使用率を制限してみました。
こんな感じでsuper piのcpu使用率上限を18%に設定
cpulimit -e pi -l 18

1回目は殆どsteal発生せずで3:28
------ Started super_pi run : 2011年 8月 24日 水曜日 13:44:04 JST
Start of PI calculation up to 2097152 decimal digits
End of initialization. Time=       0.546 Sec.
I= 1 L=       0        Time=       1.637 Sec.
I= 2 L=       0        Time=       1.873 Sec.
I= 3 L=       1        Time=       1.865 Sec.
I= 4 L=       2        Time=       1.861 Sec.
I= 5 L=       5        Time=       1.878 Sec.
I= 6 L=      10        Time=       1.869 Sec.
I= 7 L=      21        Time=       1.879 Sec.
I= 8 L=      43        Time=       1.877 Sec.
I= 9 L=      87        Time=       1.864 Sec.
I=10 L=     174        Time=       1.873 Sec.
I=11 L=     349        Time=       1.877 Sec.
I=12 L=     698        Time=       1.882 Sec.
I=13 L=    1396        Time=       1.843 Sec.
I=14 L=    2794        Time=       1.858 Sec.
I=15 L=    5588        Time=       1.849 Sec.
I=16 L=   11176        Time=       1.860 Sec.
I=17 L=   22353        Time=       1.829 Sec.
I=18 L=   44707        Time=       1.829 Sec.
I=19 L=   89415        Time=       1.751 Sec.
I=20 L=  178831        Time=       1.654 Sec.
End of main loop
End of calculation.    Time=      38.643 Sec.
End of data output.    Time=       0.170 Sec.
Total calculation(I/O) time=      38.813(       3.936) Sec.
------ Ended super_pi run : 2011年 8月 24日 水曜日 13:47:32 JST

続けて2回目を実行しても殆どsteal発生せず1回目と同等の3:36
------ Started super_pi run : 2011年 8月 24日 水曜日 13:47:34 JST
 Start of PI calculation up to 2097152 decimal digits
 End of initialization. Time=       0.570 Sec.
 I= 1 L=       0        Time=       1.660 Sec.
 I= 2 L=       0        Time=       1.862 Sec.
 I= 3 L=       1        Time=       1.888 Sec.
 I= 4 L=       2        Time=       1.892 Sec.
 I= 5 L=       5        Time=       1.890 Sec.
 I= 6 L=      10        Time=       1.862 Sec.
 I= 7 L=      21        Time=       1.858 Sec.
 I= 8 L=      43        Time=       1.905 Sec.
 I= 9 L=      87        Time=       1.877 Sec.
 I=10 L=     174        Time=       1.882 Sec.
 I=11 L=     349        Time=       1.883 Sec.
 I=12 L=     698        Time=       1.862 Sec.
 I=13 L=    1396        Time=       1.873 Sec.
 I=14 L=    2794        Time=       1.865 Sec.
 I=15 L=    5588        Time=       1.870 Sec.
 I=16 L=   11176        Time=       1.864 Sec.
 I=17 L=   22353        Time=       1.842 Sec.
 I=18 L=   44707        Time=       1.830 Sec.
 I=19 L=   89415        Time=       1.756 Sec.
 I=20 L=  178831        Time=       1.645 Sec.
 End of main loop
 End of calculation.    Time=      38.825 Sec.
 End of data output.    Time=       0.170 Sec.
 Total calculation(I/O) time=      38.995(       3.964) Sec.
 ------ Ended super_pi run : 2011年 8月 24日 水曜日 13:51:10 JST

てことで、継続的に高いcpu使用率となるプロセスはインスタンス内でcpu使用率を制限してしまえばstealの発生を抑えられるようです。
合計で20%以下ぐらいになるように調整するとsteal発生せずに済むようです。

2011-07-29

S3のバージョン管理機能を試す

フリーのS3管理ツールであるDragonDiskを利用して試してみました。

まずはバケットを右クリックしてプロパティを開いてVersioningのチェックボックスをONにしてバージョン管理機能を有効にします。

続いて、HTTPで確認できるようにアップロードしたファイルを右クリックしてプロパティを開、SecurityタブでAddをクリックしてAll Usersを追加してDownloadのチェックボックスをONにしてやります。

ファイルを変更して、上書きすると変更前後のバージョンが維持されます。
ファイル名を右クリックしてプロパティを開いてやるとVersionsに2つの日時が確認でき、
古い方の日付を選択してWeb URLタブで確認できるURLにアクセスすると変更前の内容が確認できました。

削除は、最新版を削除しても古いバージョンは削除できず、ファイルのVersionsから消したいバージョンの日付を右クリックしてDeleteを選択することで明示的に削除する必要がありました。
最新版を削除してしまった場合は、DragonDiskからは削除できなくなってしまいます。
その時は、同じファイル名のオブジェクトを再度アップロードしてやると、そのプロパティから過去のバージョンが確認できます。

2011-07-13

Object#tapってなんやねん!

DEPRECATION WARNING: Object#returning has been deprecated in favor of Object#tap.

なんて警告が出たので調べてみるとAWS::S3の中で警告がでるような処理をしているようですね。
Gemfilesのaws-s3の部分を以下のように書き換えてbundle updateしてあげれば警告でなくなりましたよヾ(*・∀・)ノ"

gem 'aws-s3', :git => 'git://github.com/emk/aws-s3.git', :require => 'aws/s3'
gem 'xml-simple'

2011-06-23

別アカウントのIAMアカウントに対してs3へのアクセス権限を与える

IAM Policyの方は単純に
{
 "Statement": [
  {
   "Action": "s3:*",
   "Effect": "Allow",
   "Resource": "arn:aws:s3:::*"
  }
 ]
}
とかしちゃえば、s3に関してはなんでもOKになります。

あとは、対象のバケット側のACLで設定しちゃえば良いかと思ったのですが、IAMアカウントにはcanonical user IDが割り当てられていないので無理でした(´・ω・`)

さて、どうするか・・・
s3 Bucket Policyを使えば出来ましたヾ(*・∀・)ノ"
こんな感じ
{
  "Version": "2008-10-17",
  "Id": "2c08cdf1-ddfc-4765-ac19-26b03a8e8b5e",
  "Statement": [
    {
      "Sid": "AllowMyUser",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::012345678901:user/iam-user-name"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::bucket-name/*",
        "arn:aws:s3:::bucket-name"
      ]
    }
  ]
}

Resourceにはarn:aws:s3:::bucket-name/*だけではなく、arn:aws:s3:::bucket-nameも設定しておくのがミソです。
これがないと、アイテムの一覧を取得することができません。