さくらのVPSの複数台構成ローカルネットワーク接続でハマり中

「さくらのVPS」プラン拡充・機能追加などサービスリニューアルのお知らせ | さくらインターネット

このニュースにのって、今月1日にさくらのVPSのローカルネット対応等を期待して2Gを5台追加。とにかく試しに使ってみて、負荷をかけてみて今の本番環境と比較してみるのだ。
と張り切ってみたのだけど、二日間ぐらいはカスタムOSのインストールがスムーズにいかない。

こんなにカスタムOSのインストールに手間と時間がかかるのでは本末転倒なので、デフォルトのCentOS6で使ってみるかと試してみるも、こっちはこっちで慣れていなくて基本的な環境整備にひどく時間を取られる。はあ、もういやだ、とUbuntuのカスタムOSインストールをもう一度ためしてみると、数日前とはエライ違い。単に混み合っていたせいなのか、何か不具合が治ったのかはわからない。でもUbuntuなら慣れてるし助かる。

さて、5台分のOSを設定して、データベース・サーバとして2台、アプリケーションサーバを2台、リバースプロキシサーバを1台の構成を試す。が、MySQLがおかしい。1台だけどうしてもおかしい。mysqlクライアントでローカルネットワーク経由でデータベースサーバに接続して、SELECTするとハングアップしてしまう。色々試すと、だいたいパターンが見えてきた。
以下、ハングアップは、

  1. ローカルネットワーク接続の時にだけ起きる。グローバルネットワーク経由だと起きない。
  2. データ量として1kbぐらい（勘です）に閾値がある感じ。SELECT LIMITで件数を制限するとあるデータ量まではSELECTできるから。
  3. 接続先データベースサーバではなく、接続するクライアントマシン側の問題。接続先データベースサーバを変えても発生する場合も発生しない場合も状況は変化しない。
  4. 同じ構成のマシンで起きるマシンと起きないマシンがある（どうも収容ホストが違う気がする）。
  5. ローカルネットワークの割り当てを削除して再割当てしたりしてみたけど状況に変化ない。
  6. CentOS6で試したときにも起きていた。Ubuntuにしてからも起きている。条件は（たぶん）同じ。（CentOSのときはちゃんと調べなかった）

この件については、いろいろと検索してみたけれど、似たような状況は見当たらないし、サポートに問い合わせてみることにした。アプリケーションの話でしょ、と言われると弱いんだけどMySQLなんだからなんとか聞いてもらえないかなあ。ホントは他のアプリケーションでも現象を確認できるといいんだけど。続報を待て。

2013.11.5 追記
どうもその後の調査で特定の1台（a1とする）からのみハングアップするらしいことがわかった。a1,a2,b1,b2の4台の仮想マシンがある。b1とb2にMySQLサーバがインストールされている。a1,a2にはMySQLクライアントがインストール済み。
この時、a1からb1、a1からb2のデータベースへローカル接続した時のみハングアップの問題が起きる。b1からb2、b2からb1、a2からb1、a2からb2では問題は発生しない。いよいよa1の生成時に何かあったんじゃないかと考えてしまう。

2013.11.5 追記その2
mysqlだけじゃなあ、と思い立ってscpで何かコピーしてみよう。おおっ、stalled。ってことは。ファイルサイズを変えながらコピーしてみると、1405bytesまではコピーできる。MTUかも。と検索してみると、
networking – Why does SCP hang on copying files larger than 1405 bytes? – Unix & Linux Stack Exchange
ピタリ。これだ。母さん、これだよ。

sudo ip link set eth1 mtu 1400

してからコピーしてみるとできるできる。mysqlクライアントもちゃんと動く動く。ネットワークの問題や。このリンクをサポートに投げてみよう。

2013.11.5 追記その3
結局設定しろと言われる。さくらのVPSで回線速度が遅くアクセスに時間がかかります。
現象が違うので検索しても見つからんわなあ。 ubuntuの場合は、/etc/network/interfaceにoffload-tso offと書いておけば良い感じ。eth0は勝手に設定されているけど、eth1やeth2は自分で書くのでその時に忘れずに。少なくともさくらのVPSでは必須の設定みたい。収容ホストによって問題が出たり出なかったりするのかなあ。
まあこれはこれでよし。Close。

2013.11.7 追記
今日になってサポートから連絡。

本件についてご提示の情報を元に確認いたしましたところ、ホストサーバのMTU が適切でなかったことが判明いたしましたため、修正させていただきました。ご不便をおかけしまして、申し訳ございません。

ん？それじゃあ、offload-tso offの設定は生きてるのか生きてないのかどっちだ。今はMTU1500で通信できてるんだけど、一昨日の時点ではどうだったんだろ。こちらでは調べようもないし、これ以上手間かけたくないしほんとにClose。