Amazon RedshiftとEC2のインスタンスタイプに於ける”MTU”の関係について
RedshiftとEC2に関するちょっとした小ネタです。
Redshiftに対してEC2サーバからのアクセス確認を行っていた所、『インスタンスタイプによってRedshiftにアクセス出来るものと出来ないものがある』という事象に直面しました。分かってみると『なるほど〜』という内容でしたのでここにその経緯と対応をまとめてみたいと思います。
当エントリについて結論から先に申しますと『EC2にはMTU(Maximum Transmission Unit: 最大トランスミッション単位)というものがあり、インスタンスタイプ毎にその値は異なる』『EC2からAmazon Redshiftにアクセスする際、そのMTUの値が影響する(インスタンスタイプによってアクセス出来るものと出来ないものがある)』のです。
当該問題の言及箇所
インスタンスタイプ毎のMTU値に関する言及はこちら。
インスタンスの最大トランスミッション単位(MTU)はインスタンスタイプに依存します。CC2、C3、CG1、CR1、G2、HS1、HI1、I2、M3 の各インスタンスタイプは、9001 MTU(ジャンボフレーム)を提供します。他のインスタンスタイプは、1500 MTU(Ethernet v2 フレーム)を提供します。
MTU自体の詳細については以下サイトなどをご参照下さい。
- Maximum Transmission Unit - Wikipedia
- MTU / MSS / RWINとは
- [Amazon VPC]ハードウェアVPN接続のMTUとTCP MSSの最適値を探す | Developers.IO
そして、Redshiftに於けるMTUの制限に関する言及はこちら。
we recommend disabling TCP/IP jumbo frames by setting the maximum transmission unit (MTU) to 1500 on the network interface (NIC) in the EC2-VPC instance. (EC2-VPCインスタンスに於いては、ネットワークインタフェース(NIC)のMTUの値を1500にする事でTCP/IP ジャンボフレームを無効にする事を推奨します)
と、仕様的にもMTUの値が1500でないインスタンス(CC2、C3、CG1、CR1、G2、HS1、HI1、I2、M3)からはデフォルト値のままではRedshiftのアクセスが出来ないようです。
実際に試してみる
では、実際に試してみましょう。MTU=9001の値で起動するEC2インスタンスを1つ用意しログイン。確かにMTUの値が9001を示しています。
$ ssh -i xxxxxxxxxxxxxxx.pem ec2-user@xxx.xxx.xxx.xx $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX: inet addr:10.0.0.0 Bcast:10.0.0.0 Mask:255.255.255.0 inet6 addr: XXXX::443:XXXX:XXXX:XXXX/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 【←MTU値=9001】 RX packets:1961 errors:0 dropped:0 overruns:0 frame:0 TX packets:1648 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:710688 (694.0 KiB) TX bytes:173423 (169.3 KiB) Interrupt:26
Redshiftにログイン、任意のSQLを実行してみます。ログインまでは問題無く進めましたが、クエリを実行した段階で返答がなくなってしまい、固まってしまいました。
$ -h xxxxxxxx.ap-northeast-1.redshift.amazonaws.com -d sampledb -U sampleuser $ (パスワードを入力) # SELECT * FROM ..... (ここで固まる...)
解決策としては以下の様にifconfigコマンドを使ってMTUの値を変更する事で対応が可能となります。
$ sudo ifconfig eth0 mtu 1500 【←このコマンドをそのまま実行】 $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX: inet addr:10.0.0.0 Bcast:10.0.0.0 Mask:255.255.255.0 inet6 addr: XXXX::443:XXXX:XXXX:XXXX/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1【←再度確認。今度はMTU値=1500となっている】 RX packets:2128 errors:0 dropped:0 overruns:0 frame:0 TX packets:1793 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:730489 (713.3 KiB) TX bytes:198797 (194.1 KiB) Interrupt:26 $
改めて接続確認をしてみます。今度は問題無く繋がるかと思います。
$ -h xxxxxxxx.ap-northeast-1.redshift.amazonaws.com -d sampledb -U sampleuser $ (パスワードを入力) # SELECT * FROM ..... (結果表示!)
再起動しても設定を維持出来る用に、設定ファイルに内容を追記しておきましょう。対応詳細は以下エントリをご参照ください。
$ echo 'MTU=1500' >> /etc/sysconfig/network-scripts/ifcfg-eth0
2015/05/01追記:
直近の当ケースに該当する環境では、これまでの設定方法では起動時にMTU時がリセットされてしまう様です。以下エントリでその対応策がまとめられていますので、こちらでもその内容を参考にしつつ手順を追記してみたいと思います。
変更前のインスタンス。確かにMTU値が9001となっています。
$ ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000 link/ether 02:c9:ae:87:5d:2b brd ff:ff:ff:ff:ff:ff inet 10.0.1.124/24 brd 10.0.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::c9:aeff:fe87:5d2b/64 scope link valid_lft forever preferred_lft forever
対象ファイルに所定の行を追記。
$ cat /etc/dhcp/dhclient.conf timeout 300; $ sudo vi /etc/dhcp/dhclient.conf timeout 300; default interface-mtu 1500; supersede interface-mtu 1500;
networkサービスを再起動。
$ sudo service network restart Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: Determining IP information for eth0... done. [ OK ]
変更後のインスタンスで状況を確認。MTU値が1500となっている事を確認出来ました。この値はEC2を再起動してもそのまま維持されていました!2015年以降のEC2インスタンス(AWS Linux)でこの事象に遭遇された方はご参考にして頂ければと思います。
$ ip addr show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 02:c9:ae:87:5d:2b brd ff:ff:ff:ff:ff:ff inet 10.0.1.124/24 brd 10.0.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::c9:aeff:fe87:5d2b/64 scope link valid_lft forever preferred_lft forever
まとめ
以上、Amazon RedshiftとEC2のちょっとした関係について書いてみました。今回取り上げたようなインスタンスタイプから接続・処理を行うようなケースが発生した場合は『こういう事もあるんだな』と頭の片隅に置いておき、対処に役立てて頂けると幸いです。