2014年7月30日水曜日

Amazon zocalo の public preview が登録できたので使ってみた。

Amazon Web Service (AWS) から、新しいサービス Amazon Zocalo （ソカロと読むらしい）が登場しました。zocalo は台座の基底部という意味らしいです。現在 Public preview となっており、使用に当たっては事前に登録が必要です。

基本的には、BOXや、DropBox などと同じファイル共有の仕組みです。他のアカウントとは全く関係ない、任意のアカウントを登録して使うことができます。

何となく申し込んでおいたら、OKが来たので実際に使ってみました。

登録完了のメールのリンクをクリックしていつものマネジメントコンソールからログインすると、以下のような画面が表示されます。

特に迷わず "Get Started Now" をクリックします。するとQuick Start と Standard Setup が選べますが、この手のツールは難しいことしたら負けなので、"Quick Start" を選びます。


次にURLと管理者の登録画面になります。特に難しい入力項目もないので、適当にURLとメールアドレス、名前を入力して"complete setup" をクリックします。URLは後で共有するときに利用します。
画面が変わって "Initializing" となります。10分ほど待ちます。
ちょっとまってリロードすると、"Active" になりました。

先ほど登録したメールアドレスにパスワード変更用のURLが届きます。



Get Started をクリックして、パスワードを設定します。
パスワード以外は登録時の情報が入力されています。パスワードの制限は以下の通り。

少し待つとWelcome の画面が表示されて利用可能になります。
とりあえず ×してWelcome 画面を閉じると利用可能になります。 Review 機能等がありお仕事で利用する文書を管理するときには便利そうです。

Administration をクリックして管理画面を表示します。
Invite Users をクリックして共有するユーザーを指定します。ユーザーは一度に複数指定できるようです。
追加したユーザーに先ほどと同じパスワード変更依頼のメールが届くので、パスワードなどを登録してもらいます。以上で準備は完了です。

既にApp Store や Google Play に モバイル用のアプリも登録されているようですが、Apple 用は iPad にしか対応しておらず、私の スマフォ は未対応となってインストールできませんでした。
基本的にタブレットしか対応していないようです。

気になるお値段ですが、月200Gで$5 です。ファイル共有だけならば、S3よりもずっと簡単です。l
今後スマフォ等の対応が広がれば個人的にはファイルサーバを構築する必要はないように思います。AD連携ができれば、もっといいかもしれません。

投稿者 時刻: 0 件のコメント:

2014年7月2日水曜日

Amazon Web Service (AWS) EC2 に新しく T2 インスタンスファミリーが加わりました。

Amazon Web Service (AWS)  のコンピュートサービスであるEC2 に T2 インスタンスファミリーが加わりました。これまでの m1.small や t1.micro を置き換えるものです。

正直 t1.micro は無料利用枠が利用できることもあり、よく利用していましたが若干力不足があったのは確かです。ちょっと大きなビルドを通そうとすると、すぐにメモリ不足でビルドが失敗していました。

新しい t2 インスタンスファミリーは以下の3つのインスタンスタイプです。

インスタンスタイプ vCPUs メモリー (GiB)
t2.micro 1 1
t2.small 1 2
t2.medium 2 4

うれしいのは、搭載メモリが増えたことと、CPU クロックの上限が上がったことでしょうか?

東京リージョンでの時間当たりの価格は以下の感じです。
インスタンスタイプ一時間の料金
t2.micro$0.020
t1.micro$0.026
t2.small$0.040
m1.small$0.061
t2.medium$0.080
t2.small と 同じ1 vCPU の m3.medium が $0.101 ですからぐっとお安い感じです。 また m1.small や t1.micro と比較して、お値段がぐっと安くなっています。 t2.micro は 無料利用枠で利用できるようになっています。

t2 インスタンスファミリーの興味深いところは CPU 性能がバーストすることです。 EBS gp2 と同じく CPU クレジットを受け取り、一定以上のCPU利用率でクレジットを消費します。

インスタンスタイプイニシャルクレジット一時間当たりの補充量ベースパフォーマンス最大クレジット残高
t2.micro30610%144
t2.small301220%288
t2.medium602440%576

1 CPU クレジットは、おおよそ1分間 100 % の使用率に相当します。
これまでの t1.micro でのバーストの仕方とずいぶん変わりました。 クレジットの残量は CloudWatch で確認できます。
  • CPUCreditUsage
    期間中に消費されたクレジットの量。5分間隔で更新される。
  • CPUCreditBalance
    クレジットの残高。5分間隔で更新される。
その他の主な制限事項は以下の通りです。。
  • HVM タイプの AMI しか利用できない。
    この制限があるので、現在 VPC NAT インスタンスとして利用できない。
    でもいつの間にか VPC NAT インスタンスで t1.micro が使えるようになっていた。
  • VPC 内でしか起動できない。
  • インスタンスタイプ毎に起動できるのは20インスタンスまで
  • 24時間で起動できるのは100インスタンスまで
  • もちろん spot instance もダメ
利用シーンとしては、それほどアクセスの内WEBサイトや、短時間で終了するバッチジョブのような用途でしょうか。
クラウドウォッチでクレジット残高を監視しながら残高不足になるようであれば、他のインスタンスサイズへの変更を検討することになると思います。

Amazon Elastic Compute Cloud User Guide (API Version 2014-06-15) T2 Instances
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html

 Amazon EC2 Pricing
http://aws.amazon.com/ec2/pricing/

Amazon Web Service ブログ
【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス
http://aws.typepad.com/aws_japan/2014/07/low-cost-burstable-ec2-instances.html
投稿者 時刻: 0 件のコメント:

2014年6月30日月曜日

OSv を AWS EC2 からアップロードしたメモ

先日どこかのもくもく会で取り上げられていましたが、OSvという OS があります。 designed for cloud と銘打っておりクラウド向けに最適化されたOSを目指しています。
OSv is designed from the ground up to execute a single application on top of a hypervisor, resulting in superior performance and effortless management
現代のOSは Linux を含めて、非常に高機能で複雑になっています。
これはオンプレミス上で多様な機器をサポートしたり、さまざまなワークロードに単体で対応する必要があるからです。

一方でクラウドをはじめとする仮想化環境ではハードウェア自体は仮想化され、もともとOSが担っていた多くの機能に関してはクラウドベンダやハイパーバイザが担っているため、ゲストOS側ではミドルウェアで必要とする最低限のインターフェイスだけを残しておけばいいという考え方でOSvは設計されています。

というわけで、実際にためしてみたいと思います。今回はまずOSのイメージを AWS 上に転送するところから始めて見たいと思います。

手順はここを参考にしました。

AMI の起動

AWS Linux では、いくつかのパッケージが不足しているので、Red Hat (Cent OS) もしくは、Fedora の AMI がお勧めだそうです。今回は私は、RHEL-6.5_GA-x86_64-7-Hourly2 (ami-aa8bfe9a)を利用しました。 普通に起動して、SSH 接続します。RHEL も時間課金で利用できるので、気楽に利用できます。

必要なパッケージ、ツールのインストール

パッケージのインストールから、github からのダウンロードまでやってしまいます。
sudo yum install git
sudo yum install ant autoconf automake boost-static gcc-c++ genromfs libvirt libtool flex bison
sudo yum install qemu-system-x86 qemu-img maven maven-shade-plugin python-dpkt tcpdump gdb
git clone https://github.com/cloudius-systems/osv.git
cd osv
git submodule update --init --recursive


AWS CLIのインストール

wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
unzip awscli-bundle.zip
sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws

同じく AMI ツールのインストール

wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
sudo mkdir /usr/local/ec2
sudo unzip ec2-api-tools.zip -d /usr/local/ec2

環境変数の設定 

export AWS_ACCESS_KEY_ID=AKI.........................
export AWS_SECRET_ACCESS_KEY=XXX........................
export EC2_HOME=/usr/local/ec2/ec2-api-tools-1.7.1.0/
export JAVA_HOME="/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/"
EC2_HOME のバージョンは各自確認してください。
AMI ツールは IAM ロール未対応 なので、IAMロールを設定した場合でもアクセスキー、シークレットキーの設定は必要なようです。


実行

ここまでで、環境の準備は終わりです。時間は30分もかからないでしょう。
vim 等のテキストエディタで以下の内容でテキストファイルを作成します。
ファイル名は例えば、"images_0.09.txt" などとします。

v0.09-small
http://downloads.osv.io.s3.amazonaws.com/cloudius/osv/osv-v0.09.qemu.qcow2
small
一行目が作成されるイメージの名前、2行目が元イメージがおいてある URL 3 行目がインスタンスサイズのようですが、内容は未確認です。

cd osv
./scripts/upload-ec2.sh < ~/images_0.09.txt
これでほおっておくと勝手に AMI が出来上がります。時間は結構かかります。
やっていることはおおよそ以下の通りです。
  1. イメージをダウンロード
  2. qcow2 のイメージを raw イメージに変換
  3. イメージを S3 にアップロード
  4. S3 上のイメージを EBS に変換
  5. 新しいインスタンスを作成して stop する
  6. インスタンスの EBS を差し替え
  7. AMI を作成する。
  8. インスタンスのTerminate

この手順を実施すると、N.Virginia (us-east-1) に public な AMI が作成されます。
きっとリリース手順をそのまま書いたのでしょう。紛らわしいので、私のAMIは削除しておきます。

OSv designed for cloud
http://osv.io/

Upload OSv AMI from EC2 instance
https://github.com/cloudius-systems/osv/wiki/Upload-OSv-AMI-from-EC2-instance
投稿者 時刻: 0 件のコメント:

2014年6月25日水曜日

Amazon Elastic Block Store (EBS) General Purpose (SSD) volumes (gp2) の バースト特性

先週リリースされた EBS gp2 タイプですが、これまでのスタンダードタイプよりバースト性能が改善されています。 バーストの仕様についてはマニュアルや公式ブログにかなり詳しく記載されていますが、実際に動作確認を行ってみました。

まずはおさらい

この前の記事にも記載しましたがEBS gp2 のバースト仕様を簡単におさらいしておきます。
  • バースト時の最大出力は 3000 IOPS
  • バーストの制御方法は、Token Bucket 方式
  • Token は容量1GBあたり毎秒3個づつ補給される。
  • Token 一個は 1 I/Oに相当
  • Token はEBS 1 個あたり最大 5,400,000 個 保存できる。
  • EBS作成時は、5,400,000 個 Token が補充される。

今回のテスト環境

今回使用した環境は、m3.xlarge を使用しました。OS側の影響を少なくするために少し大きめのインスタンスを利用しています。I/O 処理する分と、dd が動作する分と、sar と ssh が動く分でCPU 4つぐらいあれば大丈夫かな? という程度の考え方です。

EBS は gp2 タイプ 100 GB 確保して、ブートディスクとは別にインスタンスにアタッチしました。

単純に IOPS がでればいいので、以下のコマンドラインで負荷をかけました。

while true ; do dd if=/dev/zero of=/dev/xvdb bs=4k ; done 

以前はIOPSでの課金があったので、ベンチマークを実施するときはお財布を気にしながらでしたが、EBS gp2 タイプでは従量課金がなくなったので安心して負荷をかけることができます。

プレウォームを実施

EBSは特性上、プレウォームを実施すると全体の特性が良くなります。
今回もプレウォームを実施しました。

実施結果

cloudwatch の VolumeWriteOps の結果です。
CloudWatch では、EBS の IO 数を 5 分間隔で取得できます。
5分間のIO数合計が出力されます。

左から一つ目の山がプレウォーム時のものです。プレウォーム時で5分間に 約 600,000 IO 出ています。60s × 5 = 300 s で割ると、 2,000 IOPS ぐらいです。プレウォームしないと、3,000 IOPS は出ません。 

二つ目の山が、プレウォーム後少しおいて再度負荷をかけた時のものです。大体 800,000 IO 出てますので、およそ 2,666 IOPS です。 3,000 ぴったりにはなっていないですが、大体いい値ではないでしょうか。

その後は大体 300 IOPS で安定しています。
バーストしている時間はプレウォームの期間も含めておよそ30分強でした。これも仕様と大きく離れていません。

復活するか

その後2時間ほど負荷を停止して token がたまるのを待って見ました。満タンになるのに5時間ほどかかってしまうので、2時間ほどでどれだけ復活するか見てみました。
最後の山が復活した時のものです。たしかに停止するとバーストは復活します。ただためている時間が短いので、10分程度しか持ちませんでした。

Token はいつ補充されるのか

Token がどのタイミングで補充されるかはマニュアルに明確な記載がありません。ここからは完全な推測です。

上のグラフは sar で取得した await の出力をEXCEL でグラフにしたものです。
OS 側で取得したのでかなりばらつきが大きくなっています。

間隔は1秒間隔で取得しています。最初の塊がプレウォーム時のもので大体 70-80 ms で推移しています。これは実ブロックの割り当て処理のオーバーヘッドでしょう。

その後暫く休憩して次にバースト時のものです。大体 50-80 ms ぐらいです。

最後に値が大きくなっているのはバースト終了後のもので、大体 480 ms ぐらいです。
バースト時とバースト終了時の差分が大体 400ms ぐらいです。

この差分は、Token が補充されるまでの時間だと予測できます。
おそらく1秒間に3個補充されるのではなく、300数十ms に1個補充されているのではないでしょうか。
それで1秒あたり3個補充されていることになるかと思います。

まとめ

EBS gp2 タイプのバースト特性はおおよそ以下の通りだと思います。
  • token がある限り IO を払いだす。
  • 3000 IOPS が、おおよその性能上限
  • バースト時は結構ばらつきが大そう
  • token は、300 数十 ms 毎に補充される 
おまけ
私は個人的には実はIOPSはあんまり気にしていません。

IOが不足しているかどうかの判断は VolumeQueueLength を参考にしています。
もし IO が要求に追い付いていないならば、キューの値が増加して減らなくなります。
もしキューにIOが無いならば、そもそもIO要求が来ていないことになります。

またキューがたまっている状態では IOPS は最高値になっているはずで、それ以上にIOが必要なっていることを示すだけで、余りサイジングの参考になりません。長期的にみて増加傾向ならばその傾向からある程度、サイジングの参考にはなると思います。

投稿者 時刻: 0 件のコメント:

2014年6月18日水曜日

Amazon Elastic Block Store (EBS) で SSD がデフォルトになりました。


既にあちこちで取り上げられていますが、Amazon Web Service (AWS) のブロックストレージサービスである、Amazon Elastic Block Store (EBS) で SSD がデフォルトで利用できるようになりました。

マニュアルや料金表、SIMPLE MONTHLY CALCULATORも改版されています。

オンプレ環境と比較して速度的に劣るといわれていたEBSも、これで汚名を挽回できるでしょうか?

もちろんインスタンスのルートボリュームとしても利用できます。
（突然マネジメントコンソール上での、インスタンスウィザードからインスタンスを起動しようとしたら、SSDも選べるけどどうする?みたいなポップアップがでて大騒ぎしてしましました。）

もちろん30GB までの無料使用権も付いています。

EBSのタイプ

これまで "standard" ボリュームと表記されていたEBSタイプは、"Magnetic" と表記されるようになりましたが一覧表示等では、これまで通り "standard" と表示されるようです。

このアップデートでEBSのボリュームタイプは以下の3種類になります。
ボリュームタイプAPIと CLIのボリューム名
General Purpose (SSD)gp2
Provisioned IOPS (SSD)io1
Magneticstandard

さらに従来の standard ボリュームではわずかですが、IO量に応じた従量課金がありましたが、今回から廃止されました。プロビジョンしたディスク容量だけの課金となります。

EBSの性能

性能に関してはこれまでの standard ボリュームから大きく改善されています。最大 3000 IOPS のバースト性能を持ちます。これまでは Provisioned IOPS (PIOPS) を利用しない場合バーストでも数百 IOPS でしたから10倍以上の改善となります。バーストなので利用できるIOPSに制限がありますが、最低でもおよそ30分程度は継続して利用できます。

もっとも今時のSSD製品では数万IOPSを掲げる製品も出てきているので、今後の改善を期待したいところです。

IOPSの帯域制御は IO Credits という非常にユニークな方法を採用しています。

利用可能なIOPSは1GB あたり 3 IOPS が毎秒追加されます。例えば300GBのEBSを用意したとすると、毎秒 900 IOPS が追加されます。IOPSは一秒間にIOした回数なので、最低でも 900 IOPS は利用できるわけです。

一方利用しなかったIOPSは、最大 5,400,000 IOPS分まで蓄積できます。蓄積されたIOPSは最大3000IOPSまで一度に消費できます。

300 GBの EBS ならば、900 IOPS は最低利用できるので、3000 - 900 = 2100 IOPS が消費されるます。5,400,000 ÷ 2,100 = 2571.4... なので、およそ42分ぐらいは、バーストを継続できます。もちろん最大 1 TB = 1000 GB を確保すると、毎秒 3000 IOPSをずっと利用できるわけです。

このバースト性能が向上しているのは LINUX で ext4 のようなファイルシステムを利用している場合は非常に有利です。

ext4 は、基本的にはIOPSを可能な限り押さえるように動作します。そのためメモリ上にたくさんバッファしておいてあるときにまとめて書き出すようになっています。

メモリが不足してバッファを解放するような処理を実施したときに大量のIOPSが一時的にそれも間欠的に発生する場合があります。

このときプロセスはメモリ獲得待ちになりIOが完了するまで待たされます。

これはプロセスが直接メモリ獲得要求を実施した場合だけでなくシステムコールの延長線上で一時的なメモリ確保が発生した場合でもメモリ獲得待ちになり処理遅延につながります。最悪 OOM Killer の餌食になってしまいます。

そのような場合に一時的にでも多くのIOPSが使えると非常にシステム上は有利になります。

コスト

コスト的には、東京リージョンで 1GB あたり 1ヵ月 $0.12です。
100GB利用して月1000円ぐらいです。

120GBのSSDが8000円台で入手できることを考えると少し高い気がしますが、自分で設置したり、故障交換したりデータセンターに置いたりのコストを考慮すると、まぁ妥当な値段かと思います。

ただ注意しなければいけないのは PIOPS (io1) との使い分けです。

例えば、io1 で100GB で 1000 PIOPS プロビジョニングすると

容量  $0.142 × 100GB      = $14.2  
PIOPS $0.074 × 1000 PIOPS = $74 
合計                         $88.2 
(7月からの新料金で計算)

になります。一方で GP2 で 400 GB 相当確保した場合は容量課金だけなので

$0.12 × 400GB =$48 

です。これで 400GB × 3 IOPS/GB なので、1200 IOPS 確保できて、
容量も 4 倍なので非常にお得感があります。

もっとも PIOPSのようにIOPSを保証するとは言っていないのでその点は考慮する必要がありますが、3000 IOPS を超えるような IO 帯域が常時必要なユースケースは限られるので、名前の通り通常は GP2 を選択して問題ないのではないでしょうか。

また standard ボリュームからみると、値上がりしていますが 10 倍程度の性能差と 100 GB あたり $4 程度の差分なのでよほどコストにシビアでない限り GP2 を選択することになるとおもいます。

もしコスト重視ならば EBS ではなく S3 や Glacier の利用もできるので、standard ボリュームが選択される機会は減っていくのではないでしょうか。

また IOPS を重視するならば、いっそデータをファイルに置かずに、Dynamo DB に格納してしまうという方法もあります。

小さなデータを大量に読み書きする場合は、PIOPS を利用するよりも安くなるユースケースもあるとおもいます。何よりもストレージのサイズを気にしなくてよくなります。

Introducing the Amazon EBS General Purpose (SSD) volume type

【AWS発表】新しいSSDベースのElastic Block Storage

【超速報】Amazon EBSに「SSD」が追加されてるぞ！

Amazon Elastic Block Store (Amazon EBS) (マニュアル)

Amazon EBS Volume Types

Amazon EBS の価格

SIMPLE MONTHLY CALCULATOR

Intel SSD 320 Series (600GB, 2.5in SATA 3Gb/s, 25nm, MLC)
投稿者 時刻: 1 件のコメント:

2014年5月30日金曜日

EBS で暗号化がサポートされたのでベンチマークしてみた。

Amazon Web Service (AWS) のブロックストレージサービスEBSで暗号化がサポートされました。
使い方はとても簡単 EBS を作成するときに Encryption チェックボックスにチェックを入れるだけ。


一覧表示でもEncrypt の項目が追加されています。


残念ながら、ルートボリュームでは利用できないようです。


気になるのは暗号化による性能劣化です。マニュアルにも以下の記載があります。

 you can expect the same provisioned IOPS performance on encrypted volumes as you would with unencrypted volumes with a minimal effect on latency.
暗号化ボリュームでも最小限のレイテンシで暗号化していないボリュームと同じプロビジョンドIOPS性能を期待できる。
実際に iozone で測定してみました。使用したインスタンスサイズは、m3.midium です。
まずは暗号化なしの場合。


こんな感じです。大きくへこんだところがあるのは多分の測定時に何か撹乱要因があったのでしょう。
次は暗号化ありの場合



ほとんど違いが分かりません。ちなみにこれは書き込みの場合をグラフ化したものです。
読み込みはほとんどIOPSが出ず、メモリに収まった感じだったので、省略します。

ファイルシステムを利用した場合は、ワークロードによっても影響度が変わってくると思いますが、暗号化のオーバーヘッドはほとんど無視できるようです。


投稿者 時刻: 0 件のコメント:

2014年5月20日火曜日

Amazon Web Service (AWS) で一つの EC2 インスタンスにいくつ EBS がつけられるか試してみた。

EC2インスタンスに何個EBSがつけられるの？

Amazon Web Service (AWS) で 一つのEC2インスタンスに何個 EBS がくっつけられるのかマニュアルを探してみたけれど、以下の記載しかなくどうもはっきりしたことが分からないので、実際にためしてみた。

やってみる

Management Console から インスタンスウィザードを起動して、"Step 4: Add Storage"のところで、"Add New Volume" を連打した。"/dev/sdb" からはじまり、"/dev/sdz" を通り過ぎて "/dev/xvdz" が表示されたあたりで、このあたりで許してあげようと思い "Launch Instance"。

結果

一見インスタンス自体は問題なく起動しようとしているように見える。がいつまでたってもSSHログインできない。get system log をみると以下のように、Bug を踏んでいた。
4394230.182195] kernel BUG at fs/sysfs/group.c:65!
[4394230.182198] invalid opcode: 0000 [#1] SMP
[4394230.182203] Modules linked in:
[4394230.182207] CPU: 0 PID: 19 Comm: xenwatch Tainted: G        W    3.10.35-43.137.amzn1.x86_64 #1
[4394230.182215] task: ffff88002492c710 ti: ffff880024936000 task.ti: ffff880024936000
[4394230.182219] RIP: e030:[<ffffffff811eb772>]  [<ffffffff811eb772>] internal_create_group+0x202/0x230
[4394230.182228] RSP: e02b:ffff880024937c50  EFLAGS: 00010246
[4394230.182232] RAX: 0000000000000400 RBX: ffff880003544000 RCX: 0000000000000000
[4394230.182236] RDX: ffffffff8184dfc0 RSI: 0000000000000000 RDI: ffff880003544080
[4394230.182241] RBP: ffff880024937c88 R08: 00000000000163c0 R09: ffff8800260163c0
[4394230.182245] R10: ffffea0000927d00 R11: ffffffff81311bb2 R12: ffff880003590000
[4394230.182250] R13: ffffffff8184dfc0 R14: 0000000000000000 R15: ffff880003544070
[4394230.182259] FS:  0000000000000000(0000) GS:ffff880026000000(0000) knlGS:0000000000000000
[4394230.182264] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[4394230.182268] CR2: 0000000000000000 CR3: 000000000180c000 CR4: 0000000000002660
[4394230.182273] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[4394230.182277] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[4394230.182281] Stack:
[4394230.182284]  ffff880003544080 ffffffff81256951 ffff880003544000 ffff880003590000
[4394230.182291]  ffff880003544000 ffff880003544070 ffff880003544070 ffff880024937c98
[4394230.182298]  ffffffff811eb7b3 ffff880024937ca8 ffffffff810f84b4 ffff880024937ce8
[4394230.182305] Call Trace:
[4394230.182311]  [<ffffffff81256951>] ? kobj_kset_leave+0x51/0x60
[4394230.182316]  [<ffffffff811eb7b3>] sysfs_create_group+0x13/0x20
[4394230.182324]  [<ffffffff810f84b4>] blk_trace_init_sysfs+0x14/0x20
[4394230.182331]  [<ffffffff8123ecfd>] blk_register_queue+0x3d/0x110
[4394230.182336]  [<ffffffff81245a0d>] add_disk+0x1cd/0x4a0
[4394230.182341]  [<ffffffff81324a1d>] blkback_changed+0xd3d/0x1010
[4394230.294407]  [<ffffffff812da098>] xenbus_otherend_changed+0x98/0xa0
[4394230.294418]  [<ffffffff812dc083>] backend_changed+0x13/0x20
[4394230.294433]  [<ffffffff812d9436>] xenwatch_thread+0xb6/0x170
[4394230.294440]  [<ffffffff81070e10>] ? wake_up_bit+0x30/0x30
[4394230.294454]  [<ffffffff812d9380>] ? unregister_xenbus_watch+0x230/0x230
[4394230.294462]  [<ffffffff8106fee0>] kthread+0xc0/0xd0
[4394230.294477]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120
[4394230.294485]  [<ffffffff8144a12c>] ret_from_fork+0x7c/0xb0
[4394230.294498]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120
[4394230.294503] Code: 8b 7d d0 89 4d c8 e8 8e e7 ff ff 4c 8b 65 d0 8b 4d c8 e9 28 ff ff ff 4c 8b 65 d0 e9 1f ff ff ff 48 83 7f 30 00 0f 85 3e fe ff ff <0f> 0b b8 ea ff ff ff e9 29 ff ff ff be c3 00 00 00 48 c7 c7 ff

以下のようなログも出力していたので、多分デバイス名の付け方に問題があったのだろう。

[4394230.181916] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0xa5/0xd0()
[4394230.181921] sysfs: cannot create duplicate filename '/class/block/xvdt'
[4394230.181925] Modules linked in:
[4394230.181931] CPU: 0 PID: 19 Comm: xenwatch Not tainted 3.10.35-43.137.amzn1.x86_64 #1
[4394230.181937]  0000000000000009 ffff880024937b50 ffffffff8143c559 ffff880024937b88
[4394230.181945]  ffffffff8104bac1 00000000ffffffef ffff88000358acb0 ffff880024937c38
[4394230.181961]  ffff880024aad000 0000000000000001 ffff880024937be8 ffffffff8104bb2c
[4394230.181969] Call Trace:
[4394230.181986]  [<ffffffff8143c559>] dump_stack+0x19/0x1b
[4394230.181995]  [<ffffffff8104bac1>] warn_slowpath_common+0x61/0x80
[4394230.182000]  [<ffffffff8104bb2c>] warn_slowpath_fmt+0x4c/0x50
[4394230.182015]  [<ffffffff811e9955>] sysfs_add_one+0xa5/0xd0
[4394230.182020]  [<ffffffff811ea5a5>] sysfs_do_create_link_sd+0x105/0x200
[4394230.182026]  [<ffffffff811ea6c1>] sysfs_create_link+0x21/0x40
[4394230.182041]  [<ffffffff81311de4>] device_add+0x3e4/0x6d0
[4394230.182047]  [<ffffffff81310517>] ? dev_set_name+0x47/0x50
[4394230.182061]  [<ffffffff812459fd>] add_disk+0x1bd/0x4a0
[4394230.182068]  [<ffffffff81324a1d>] blkback_changed+0xd3d/0x1010
[4394230.182084]  [<ffffffff812da098>] xenbus_otherend_changed+0x98/0xa0
[4394230.182091]  [<ffffffff812dc083>] backend_changed+0x13/0x20
[4394230.182097]  [<ffffffff812d9436>] xenwatch_thread+0xb6/0x170
[4394230.182110]  [<ffffffff81070e10>] ? wake_up_bit+0x30/0x30
[4394230.182117]  [<ffffffff812d9380>] ? unregister_xenbus_watch+0x230/0x230
[4394230.182124]  [<ffffffff8106fee0>] kthread+0xc0/0xd0
[4394230.182137]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120
[4394230.182145]  [<ffffffff8144a12c>] ret_from_fork+0x7c/0xb0
[4394230.182157]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120

まとめ

AWS 的には、EBSを何個つけても問題なさそうだが、実際にたくさんEBSを付ける場合にはいろいろ考慮が必要なようだ。

投稿者 時刻: 0 件のコメント:
登録: 投稿 (Atom)