2014年3月25日火曜日

AWS VPC で VPC 間接続がサポートされたので試してみた。

AWS で VPC間の接続(Peering) がサポートされたので試してみました。
現在同一リージョン内のみで接続可能です。

今回不幸にも Management Console の更新が出ていたにも関わらず、うっかり NO とか 押してしまったためにコマンドライン(ec2-apitool)で実行してみました。
aws cli は、git 版も含めて現在サポートされていないようです。

まずec2-apitoolを最新化します。現在 1.6.13.0 でピアリング関係のコマンドが追加されています。
以下はAWS LINUXで標準でインストール されているコマンドを置き換える例です。
$ wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
$ cd /opt/aws/apitools
$ sudo unzip ~/ec2-api-tools.zip
$ sudo mv ec2-api-tools-1.6.13.0 ec2-1.6.13.0
$ sudo rm -f ec2
$ sudo ln -s ec2-1.6.13.0 ec2
$ cd ec2/bin
$ sudo rm -f *.cmd
$ cd /opt/aws/bin
$sudo find /opt/aws/apitools/ec2-1.6.13.0/ -iname "ec2-*" -exec ln -f -s {} . \;
VPC はマネージメントコンソールで適当に作成しておきます。 今回は異なるアカウント間で試してみました。
ピアリングのリクエストは以下のコマンドラインで設定します。 $ ec2-create-vpc-peering-connection --region us-west-2 -c vpc-526xxxxx -p vpc-576bxxxx -o 1xxxxxxxxxx0
VPCPEERINGCONNECTION pcx-e96xxxxx Tue Apr 01 11:42:46 UTC 2014 initiating-request: Initiating Request to 1xxxxxxxxxx0
REQUESTERVPCINFO vpc-526xxxxx 10.1.0.0/16 4xxxxxxxxxx6
ACCEPTERVPCINFO vpc-576bxxxx 1xxxxxxxxxx0
ec2-create-vpc-peering-connection
  • --region : リージョンを指定します。今回はoregon を使用しました。
  • -c : 接続元のvpc-id を指定します。
  • -r : 接続先のvpc-id を指定します。
  • -o : 接続先のアカウントIDを指定します。

VPC ピアリングコネクション ID ( pcx-e96xxxxx ) を控えて、接続先に連絡します。
ピアリングリクエストをアクセプトするためには、接続先のアカウントで以下の コマンドを実行します。 $ ec2-accept-vpc-peering-connection --region us-west-2 pcx-e96xxxxx
VPCPEERINGCONNECTION pcx-e96xxxxx provisioning: Provisioning
REQUESTERVPCINFO vpc-526xxxxx 10.1.0.0/16 4xxxxxxxxxx6
ACCEPTERVPCINFO vpc-576bxxxx 10.0.0.0/16 1xxxxxxxxxx0
ec2-create-vpc-peering-connection
  • --region : リージョンを指定します。
  • pcx-e96xxxxx : 先ほど控えた VPC ピアリングコネクション ID
さらに接続元、接続先でルーティングテーブルにエントリを追加します。
[接続元]
$ec2-create-route --region us-west-2 rtb-e67xxxxx -r 10.1.0.0/16 -p pcx-e96xxxxx
ROUTE 10.0.0.0/16 pcx-e96xxxxx
[接続先]
$ec2-create-route --region us-west-2 rtb-187xxxxx -r 10.1.0.0/16 -p pcx-e96xxxxx
ROUTE 10.1.0.0/16 pcx-e96xxxxx
ec2-create-vpc-peering-connection
  • --region : リージョンを指定します。
  • -r : 相手ネットワーク の CIDRブロックを指定します。 VPC 全体でも、サブネットでもかまいません。
  • -p : VPC ピアリングコネクション ID を指定します。
両方合わせてわずか、4コマンドで接続できました。詳細は現在英語版だけですが、マニュアルを参照してください。

2014年3月3日月曜日

電力効率がいいワークキューって?

 Linux Foundation の LTSI(Long Term Support Initiative) v3.10 公開 という記事のなかで、 "電力効率のよい workqueue" という機能がマージされたとのこと。
なぜ workqueue の変更で電力効率が変わるんだ? ということで調べたメモ。
※K.T. さん情報提供ありがとうございます。

workqueue

workqueue というのは、簡単にいうとLinux カーネルのなかで処理を遅延させる 仕組みのこと。
LINUX kernelに限らず、現代のOSは機能が豊富でたくさんの仕事をしなければいけない。

一方でOSは通常のプロセスとは違い特権モードで動作しているので、 あんまりお仕事をしすぎるとユーザープロセスの動作が遅れてしまう。

本来OSの利用者は、自分のプロセスが高速に動作することを期待しているので、 OSがお仕事しすぎてユーザープロセスが遅れては本末転倒である。

そこでOSのお仕事のうち、待ちが発生するものや、今すぐにやらなくてもいいこと を順番待ちに登録(queueing)して、後から適切な時に実行するのが workqueue という仕組み。

なんで仕事の順番を替えるだけで、電力消費が減るんだろう?というのが今回の 疑問。その前に少しだけ、MPUのお話。

big.LITTLE処理

最近のARMプロセッサでは「big.LITTLE処理」という機能が搭載されている。 これは簡単に言うと、高速で消費電力が大きい(big)プロセッサ(ARM Cortex™-A15プロセッサ) と、低速で消費電力が小さい(LITTLE)プロセッサ(Cortex™-A7)を両方搭載して、 処理の内容や、タイミングなどによって使い分けようという考え方。

電力効率のよい workqueue

この"big.LITTLE処理" を workqueue に適用して、できるだけLITTLE側に処理を 振ることで電力効率を改善するというのが今回マージされた機能ということに なる。わかってみればそれほど難しい話ではない。

一般のスケジューラでは?

処理をできるだけ LITTLE 側に振るだけで、電力消費が減るならば一般のプロセス スケジューラでも適用できるのでは?と思ってちょっと調べてみた。
現在、IKS と呼ばれる方式と、GTS(big.LITTLE MP)と呼ばれる2つの方式が 提案されているようだ。IKS は cpufreq という電力管理の延長線上で big と LITTLE の切り替えを行う方式。

GTS は、スケジューラ(sched) に変更を加えてbig と LITTLEにプロセスを 割り当てる方式。

さすがに sched に手を入れた場合は影響範囲が大きいのでメインストリーム には取り込まれておらず、特定の機器で取り込まれている模様。

SMP でない環境でのスケジューリングはいろいろ議論があって面白そう。

参考

workqueue については例えば、以下のIBM developerWorks の記事などを参照
「カーネル API: 第 2 回、遅延可能な関数、カーネルのタスクレット、およびワークキュー」
http://www.ibm.com/developerworks/jp/linux/library/l-tasklets/

big.LITTLE処理
http://www.arm.com/ja/products/processors/technologies/biglittleprocessing.php

後藤弘茂のWeekly海外ニュース
「 2014年のARMのSoCの中核技術となる「big.LITTLE MP」」
http://pc.watch.impress.co.jp/docs/column/kaigai/20131220_628480.html

Linaro Blog 「big.LITTLE Software Update」
http://www.linaro.org/linaro-blog/2013/07/10/big-little-software-update/

LWN.net「 Queue work on power efficient wq 」
http://lwn.net/Articles/548281/