CentOS6.5 HVM インスタンスを SR-IOV化する
2016.01.25 dkmsが抜けている手順のためカーネルアップデート後に正常に起動しないはずです。実際にはdkms化も加えてください。(参照)
2016.01.25 CentOS6.7, RHEL6.7はカーネルにSR-IOVドライバが入っていますのでわざわざ6.5でこのような面倒なことは避けたほうがよいです。
ーーー
素のCentOS6.5 なHVM AMIの作成方法についてはこちら。
CentOS6.5を VM ImportでEC2にインポートする - aws memo
最近のインスタンスタイプでは、Enhanced Networking というSR-IOVによるネットワークの機能強化に対応している。(C3, I2, R3)
Enhanced Networkingを使うには、いくつかの条件を満たす必要がある。
- VPC内に起動した HVM インスタンスであること
- カーネル2.6.32以降であること
- SR-IOVドライバが組み込まれていること
- AMI もしくはインスタンスの attributeでSR-IOVが有効になっていること
ということで、素のCentOS6.5 HVM インスタンスを SR-IOV化する手順のメモ。
流れ
手順
まずは CentOS6.5 HVM AMIを、VPC内に起動し、sshログイン。
SR-IOVドライバを取得する。ドライバはこちらから取得する。(2014年4月時点では2.14.2が最新)
Intel Ethernet Drivers and Utilities - Browse /ixgbevf stable at SourceForge.net
ビルド・設定する。大枠の手順はこちら(
Enabling Enhanced Networking on Linux Instances in a VPC - Amazon Elastic Compute Cloud
)
yum -y update && sudo yum -y install gcc make kernel-devel kernel-headers yum -y install perl man pciutils reboot ---- tar zxvf ixgbevf-2.14.2.tar.gz cd ixgbevf-2.14.2/src make install echo "options ixgbevf InterruptThrottleRate=1,1,1,1,1,1,1,1" > /etc/modprobe.d/ixgbevf.conf
ここで、udevによる悪さ対策をしておく。(これをしないと、SR-IOVなNICがうまく認識されず、bootしてもsshログインできなくなる)
rm /etc/udev/rules.d/70-persistent-net.rules cp /lib/udev/rules.d/75-persistent-net-generator.rules ~ vi /lib/udev/rules.d/75-persistent-net-generator.rules diff /lib/udev/rules.d/75-persistent-net-generator.rules ~/75-persistent-net-generator.rules 93c93 < #DRIVERS=="?*", IMPORT{program}="write_net_rules" --- > DRIVERS=="?*", IMPORT{program}="write_net_rules" reboot
udevで新しいeth0を認識しても そのルールを /etc/udev/rules.d/に書かないようにすることと、既存の ルールを削除しておくことの2点。
参考: SIOS "OSSよろず" ブログ出張所: CentOS 6 系で NIC 交換すると eth0 と認識されない
次に、インスタンスをstopし、属性変更してSR-IOVを有効にする( on Mac OSX)
$ ec2-stop-instances --region us-west-2 i-xxxxxxx $ ec2-modify-instance-attribute --region us-west-2 --sriov simple i-xxxxxxx $ ec2-describe-instance-attribute --region us-west-2 --sriov i-xxxxxxx sriovNetSupport i-xxxxxxx simple $ ec2-start-instances --region us-west-2 i-xxxxxxx
その後sshでログインして確認。
# lsmod | grep ixgbevf ixgbevf 58629 0 # modinfo ixgbevf ilename: /lib/modules/2.6.32-431.11.2.el6.x86_64/kernel/drivers/net/ixgbevf/ixgbevf.ko version: 2.14.2 license: GPL description: Intel(R) 82599 Virtual Function Driver author: Intel Corporation, <linux.nics@intel.com> srcversion: 50CBF6F36B99FE70E56C95A alias: pci:v00008086d00001515sv*sd*bc*sc*i* alias: pci:v00008086d000010EDsv*sd*bc*sc*i* depends: vermagic: 2.6.32-431.11.2.el6.x86_64 SMP mod_unload modversions parm: InterruptThrottleRate:Maximum interrupts per second, per vector, (956-488281, 0=off, 1=dynamic), default 1 (array of int) # ethtool -i eth0 | grep driver driver: ixgbevf # dmesg | grep ixgbevf ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver - version 2.14.2 ixgbevf 0000:00:03.0: setting latency timer to 64 ixgbevf: eth%d: ixgbevf_check_options: dynamic interrupt throttling enabled ixgbevf 0000:00:03.0: irq 48 for MSI/MSI-X ixgbevf 0000:00:03.0: irq 49 for MSI/MSI-X ixgbevf 0000:00:03.0: irq 50 for MSI/MSI-X ixgbevf 0000:00:03.0: Multiqueue Enabled: Rx Queue count = 2, Tx Queue count = 2 ixgbevf: eth0: ixgbevf_probe: Intel(R) 82599 Virtual Function ixgbevf: eth0: ixgbevf_probe: GRO is enabled ixgbevf: eth0: ixgbevf_probe: Intel(R) 10 Gigabit PCI Express Virtual Function Network Driver ixgbevf 0000:00:03.0: NIC Link is Up 10 Gbps ixgbevf: eth0: ixgbevf_change_mtu: changing MTU from 1500 to 9001
ここでcreate imageでHVM AMIを作成すると、SR-IOV属性が付いたHVM AMIが作成される。作成したHVM AMIを、VPC内にC3で起動すると、同じようにixgbevfドライバになっているはず。C3/I2/R3以外のタイプで起動する、or VPC外で起動すると通常のvifドライバになることを確認する。
CentOS6.5を VM ImportでEC2にインポートする
CentOS6.5を EC2にインポートする手順のメモ。
( CentOS6.5 HVM AMI (SR-IOV対応) - aws memo の公開でやった手順のメモ)
準備
VirtualBoxをインストールしておく
CentOS6.5 minimal CD のisoファイルをダウンロードしておく
EC2 API Tools をセットアップしておく(参考)
手順
- VirtualBox上にCentOS VMを作成し、ディスクイメージを用意する
- VM Import用のS3 Bucketを作成する
- VM Import実行
- インポートしたEC2インスタンス(stop状態)をStartし内容を確認した後にAMIを作成する
- 作成したAMIからインスタンスを起動して動作確認
手順詳細
VirtualBoxでCentOS6.5をisoファイルから普通にOSインストールする(インストール手順は省略)
- Linux 2.6/3.x (64bit)
- メモリ 1024MB
- 仮想ハードドライブ: VDI (VirtualBox Disk Image)形式 8GB (可変サイズ)
インストール時に注意する点は以下の通り。
- eth0 が起動時に有効になり、DHCPになっていること
- iptablesで22番ポート(ssh)を開けて、リモートからssh接続できること
- GRUBでbootし、ファイルシステムがext3,ext4,xfs等になっていること
※こちらもチェック(Step 2: Prepare Your VM - Amazon Elastic Compute Cloud)
インストール後にVMにログインして確認・設定等を行い、VMをシャットダウンする
# /etc/sysconfig/network-scripts/ifup eth0 # ifconfig # vi /etc/sysconfig/network-scrpits/ifcfg-eth0
# cat /etc/sysconfig/network-scrpits/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp # chkconfig iptables off
# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup-lv_root 6.7G 725M 5.6G 12% / tmpfs 7.3G 0 7.3G 0% /dev/shm /dev/xvda1 485M 32M 428M 7% /boot # cat /etc/fstab UUID=ed0a37a2-065d-42ed-8169-e67f73aae9d2 / ext4 defaults 1 1 UUID=ab3a3168-8adc-4419-98d9-17079234cd03 /boot ext4 defaults 1 2 UUID=55476664-15fb-470d-9905-d6585ae4470b swap swap defaults 0 0 # shutdown -h now
VM Import用に、RAWフォーマットのVMイメージファイルを作成する ( on Mac or Windows) 。
$ VBoxManage clonehd /path/to/CentOS6_5.vdi /path/to/CentOS6_5.raw --format RAW
次に、VM Importを行うために、S3にBucketを作成する(例: example-bucket )。この時、VM Import先のリージョンと同じリージョンにBucketを用意することに注意する。
次に、VM Importを行う( on Mac or Windows)
ec2-import-instance \ /path/to/CentOS6_5.raw \ -t m3.xlarge \ -f RAW \ -a x86_64 \ -p Linux \ --region us-west-2 \ --bucket example-bucket \ -o $AWS_ACCESS_KEY \ -w $AWS_SECRET_KEY Requesting volume size: 8 GB TaskType IMPORTINSTANCE TaskId import-i-fgeezt5f ExpirationTime 2014-04-15T01:55:43Z Status active StatusMessage Pending InstanceID i-0e256006 DISKIMAGE DiskImageFormat RAW DiskImageSize 8589934592 VolumeSize 8 AvailabilityZone us-west-2c ApproximateBytesConverted 0 Status active StatusMessage Pending : Downloaded 0 Creating new manifest at example-bucket/93b196ad-71c8-466e-8bdf-226ed25c9e17/CentOS.rawmanifest.xml Uploading the manifest file Uploading 8589934592 bytes across 820 parts 0% |--------------------------------------------------| 100% |===================================
といった表示になる。 上記の例だと、s3://example-bucket/93b196ad-71c8-466e-8bdf-226ed25c9e17/ に RAWファイルが10MB毎に分割されてUPされる。
ec2-import-instance コマンドを実行すると、conversion taskとして次の処理が行われる。
- インポート先のインスタンス作成( stop状態)
- VMイメージファイルを S3に分割アップロード ( 10分程度)
- 分割したイメージファイルを結合 (10分程度)
- EBSボリュームが自動で作成され、インポート先インスタンスにアタッチされる(10分程度)
定期的にec2-describe-conversion-tasks を実行して、進捗状況を確認する
ec2-describe-conversion-tasks --region us-west-2 TaskType IMPORTINSTANCE TaskId import-i-fgeezt5f ExpirationTime 2014-04-15T01:55:43Z Status active StatusMessage Pending InstanceID i-0e256006 DISKIMAGE DiskImageFormat RAW DiskImageSize 8589934592 VolumeSize 8 AvailabilityZone us-west-2c ApproximateBytesConverted 6731857920 Status active StatusMessage Progress: 75%
この状態で完了。
ec2-describe-conversion-tasks --region us-west-2 TaskType IMPORTINSTANCE TaskId import-i-fgeezt5f ExpirationTime 2014-04-15T01:55:43Z Status completed InstanceID i-0e256006 DISKIMAGE DiskImageFormat RAW DiskImageSize 8589934592 VolumeId vol-cb45eec7 VolumeSize 8 AvailabilityZone us-west-2c ApproximateBytesConverted 6731857920 Status completed
stop状態のインスタンスをstartさせ、sshログインする。
動作に問題なければ、適切な設定を施した上で Create Imageすると、HVM AMIが作成される。
うまく動作確認ができれば、S3上のファイルは不要なので削除する
ec2-delete-disk-image \ --task import-i-fgeezt5f \ --region us-west-2 \ -o $AWS_ACCESS_KEY \ -w $AWS_SECRET_KEY
参考
VM Import (仮想サーバーイメージのインポートとエクスポート機能)| アマゾン ウェブ サービス(AWS 日本語)
Prerequisites - Amazon Elastic Compute Cloud
SR-IOV対応版CentOS6.5 HVM AMI 作成手順
SR-IOV対応版CentOS 5.6 HVM AMI を作ったので、その流れをメモ。
概要
VM Import/Export でHVM なインスタンスを作り、設定を行ってAMIを作るイメージ。
手順
- オンプレミスで 仮想マシンとしてCentOS5.6をセットアップする
- VMImport の機能で仮想マシンを EC2としてインポートする
- インポートしたEC2インスタンスからHVM AMIを作成する
- HVM AMIから起動したEC2インスタンスで、SR-IOV化を施す
- SR-IOV化したインスタンスから、公開用のAMIを作成する
1,2の手順はこちら。
CentOS6.5を VM ImportでEC2にインポートする - aws memo
3の手順はこちら。
VM ImportしたCentOS6.5のAMIを作る前の手順 - aws memo
4,5の手順はこちら。
CentOS6.5 HVM インスタンスを SR-IOV化する - aws memo
CentOS6.5 HVM AMI (SR-IOV対応)
作ったので公開。
2015/1/14追記: C4対応のCentOS6.6を公開したので、そちらを使ってください
C4.8xlarge対応 HVM AMI ( SR-IOVも対応) - aws memo
----
簡単な内容
(作成方法は別エントリ)
- CentOS-6.5-x86_64-minimal.iso ベース( 2.6.32-431.11.2.el6.x86_64)
- SR-IOV Driver ixgbevf-2.14.2 設定済み
- 追加パッケージ : gcc,make,kernel-deve,perl,man,pciutils
- ログインアカウント: root
- Cloud-init未対応
CentOS6.5_HVM_SR-IOV_ixgbevf-2.14.2
- Virginia: ami-0bc9d462
- Oregon: ami-4c85ee7c
- Tokyo: ami-7fa6fe7e
CentOS6.5_HVM_SR-IOV_ixgbevf-2.14.2_16cores_for_c3.8xlarge
- Virginia: ami-37c9d45e
- Oregon: ami-a499f294
- Tokyo: ami-e5f688e4
(ブートパラメータにmaxcpus=16 を記載しているので、c3.8xlargeを16コアで使う場合にはこちら)
2014.8.12追記
yum updateでカーネルアップデートすると、ドライバが読み込めなくなった時は、こちらを参照のこと。
SR-IOV対応版AMIでのカーネルアップデート時は注意 (自分用メモ) - matetsuだもんで
DynamoDBやSQSといったAPIを高頻度に使うときに忘れずにセットしておきたいカーネルパラメータ
DynamoDB, SQSなどは、Linux内部から高頻度に HTTP APIを叩きに行くことになる。( Fluentdやら、memcachedやらも同じかも)
通常のLinuxのカーネルパラメータ設定で、本番環境や、負荷テスト環境に使うと、おそらくネットワーク障害のような状況に陥るはず。
その時、「DynamoDBの IOPS不足?」「 SQSのAPI スロットリング?「AWSの限界?」と思う前に、これチェック!
netstat -an
この結果に、大量のTIME_WAITが表示された場合は、 エフェメラルポートが枯渇して socket作れない状態に陥っている。つまり、DynamoDBやSQSまでパケット届いていない状態なのでAWS側は原因ではない。
ということで、エフェメラルポートを最大限使うようにカーネルパラメータを設定しておくことを忘れないようにするためのメモ。
$ sudo cp /etc/sysctl.conf /etc/sysctl.conf.bak $ sudo vi /etc/sysctl.conf $ sudo diff /etc/sysctl.conf /etc/sysctl.conf.bak #変更内容確認 < net.core.somaxconn = 10240 < net.core.netdev_max_backlog = 10240 < net.ipv4.tcp_max_syn_backlog = 10240 < net.ipv4.tcp_max_syn_backlog = 10240 < net.ipv4.tcp_tw_recycle = 1 < net.ipv4.tcp_tw_reuse = 1 < net.ipv4.ip_local_port_range = 1024 65535 < net.ipv4.tcp_fin_timeout = 10 $ sudo reboot #reboot # reboot後に再度ログインして確認 $ cat /proc/sys/net/ipv4/tcp_tw_recycle 1
これでOK
Spotインスタンスで Private IPを指定して起動する
VPC内でspot requestする際、Management Consoleでは Private IP を指定する項目が無いため、指定したサブネット内の空きアドレスが自動で振られることになる。(正確には、サブネット内の空きアドレスの一つからENIが作られ割り振られる)
コマンドラインでは、既存ENIを指定することが可能。なので、まずは事前にspotで使いそうな数だけENIを作っておく。
# 例オレゴンリージョンのVPCの サブネットsubnet-a5b991d1 に、 # 172.16.1.101〜108のENIを作成する $ for i in {101..108} ; do ec2-create-network-interface --region us-west-2 --private-ip-address 172.16.1.$i subnet-a5b991d1; done
その上で、起動時には
# 172.16.1.102 のeni-idを取得する $ ENIID=`ec2-describe-network-interfaces --region us-west-2 | grep 172.16.1.102 | grep eni | awk '{print $2;}'` # eniをeth0としてスポットリクエスト発行 $ ec2-request-spot-instances ami-f8f297c8 --region us-west-2 \ --instance-type c3.8xlarge --k id_rsa \ --network-attachment $ENIID:0 \ -p 2.0
ちなみに、通常のオンデマンドインスタンス起動でもこのテクニックは利用可能。コマンドが異なるだけで、オプションはほぼ一緒である(値段指定が無いくらい)ことがわかる。
# 172.16.1.102 のeni-idを取得する $ ENIID=`ec2-describe-network-interfaces --region us-west-2 | grep 172.16.1.102 | grep eni | awk '{print $2;}'` # eniをeth0として起動 $ ec2-run-instances ami-f8f297c8 --region us-west-2 \ --instance-type c3.8xlarge --k id_rsa \ --network-attachment $ENIID:0
これをうまくスクリプト化しておくと便利。
カスタムのRHEL 6.4 HVM AMIを作る時の注意点
C3で、RHEL 6.4 HVM AMIにSR-IOVドライバを入れる手順はこちら
[HPC] C3.8xlarge のRHEL6.4 HVMで SR-IOVを有効にする - aws memo
で、ドライバが入った状態のカスタムAMIを作っておきたいと思うのが人情。
この時、create image する前に2つ注意点。(2013年 11月28日時点。RHEL AMIが改善されれば不要になるはず)
1. udev に注意
[症状]
作成したカスタム RHEL AMIで起動すると、 status checkがエラーになり、ssh接続もpingも通らない。
[原因]
/etc/udev/rules.d/70-persistend-net.rules が存在している状態でAMIを作ると、このファイルを持ったままになる。そのAMIで起動すると、本来 eth0として使いたいNICがeth1として認識してしまう。(rulesに書いてあるMACアドレスをeth0として確保しようとするため)
この状態になると
[対策]
AMIを作る前に、 このファイルをrmしておく。
sudo rm /etc/udev/rules.d/70-persistend-net.rules
2. rc.local に注意
[症状]
udevの対策をして作成したカスタムRHEL AMIで起動すると、 pingは通るが sshが通らない( connection refusedになる)
[原因]
/etc/rc.local のバグで、 /etc/ssh/sshd_config がおかしい状態でAMIを作ってしまう。
そのため、AMIから起動すると、sshdが起動しなくなる。こちらにも書いてある。
[対策]
/etc/rc.localを修正する。sshd_configをいじってるところをコメントアウト
$ diff rc.local /etc/rc.local 19,21c19,21 < #cat <> /etc/ssh/sshd_config < #UseDNS no < #PermitRootLogin without-password --- > cat < > /etc/ssh/sshd_config > UseDNS no > PermitRootLogin without-password