ちょっと話題の記事

Amazon RedshiftとEC2のインスタンスタイプに於ける”MTU”の関係について

しんや

2014.05.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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自体の詳細については以下サイトなどをご参照下さい。

そして、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のちょっとした関係について書いてみました。今回取り上げたようなインスタンスタイプから接続・処理を行うようなケースが発生した場合は『こういう事もあるんだな』と頭の片隅に置いておき、対処に役立てて頂けると幸いです。

スキルアップ|初心者向け|書評|デベキャン|AWS認定|スキルアップ|デベキャンだより|勉強会|コミュニティ

関連記事

영어판 Windows Server 2022를 한국어로 변경 하는 방법에 대해 알아보자!

KeumSangwon

2024.04.24

EC2 Instance Connect Endpoint 를 이용해서 Private EC2에 접속하기

Lee Sujae

2024.04.23

Amazon EC2 Windows インスタンス起動時に追加した複数のEBSボリュームを有効化する手順2選

平井裕二

2024.04.23

CDKでNatInstanceProviderV2を使ってNATインスタンスを構築できるようになりました

アッキー

2024.04.16