殻を破れないエンジニアの雑記

エンジニアの卵。ずっと卵。

事件は会議室で起きているんじゃない!お前の頭の中で起きているんだ!

○インボーブリッジ封鎖できません!

おはようございます。くろのです。

くろのですと言う部分に苗字を書いてしまいそうになるのは完全に職業病な気がする今日この頃、皆さまいかがお過ごしでしょうか。

早いもので今年ももう1/12が終わろうとしています。

1/12にして僕の転職活動は、佳境に入り始めています。

最終面接が来週になったので、なんとしてでもスタートダッシュをして今年をもっと良いものにしていきたいところです。


さて、今日もまた現場の話です。

弊社のネットワークチームは本日研修で全員不在だったところ、とある40代後半のメンバーが慌てた顔をしてこちらにやってきました。

「サーバーに端末から通信できない!ファイアウォールは穴が開いているのになんで!?」

少しだけ秘密保持契約に抵触しない範囲で環境の説明をしたいと思います。

サーバー側はVxLANと呼ばれる特別なネットワークセグメントにいます。

これはL3ネットワーク上に論理的にL2ネットワークを構築するプロトコルです。

これにより、拠点間の異なるセグメントでも同一のL2として取り扱う事が可能になり、L3を超えてマシン(この場合はVM)の移動が可能になります。

ただし、導入には当然制約もあります。

VxLAN対応のスイッチを使わなければならなかったり、スイッチにつなぐサーバー側のMTUをスイッチ側のMTU-50未満にするなどなどです。

ネットワークチームはいないのですが、私が対応することにしました。

おおよその検討はついていましたので・・・。

すると・・・

VM基盤側でファイアウォールの設定ってないの?」

と聞いてきます。

至極最もな話ではあるのですが、該当ネットワークの別サーバーには普通にアクセスできているので問題はノード単位と推測できます。

とはいえ、引き下がりそうになかったので、VM基盤側で管理しているファイアウォールの設定をやりたくなかったけど確認しつつ、かねてから言いたかったことを伝えました。

「サーバー側のMTUの値を調べてもらってもいいですか?」

上でも少し触れたMTUの設定です。

MTUとは(イーサ)ネットワークにおいて1度に転送できる最大のデータサイズになります。

これが大体サーバー側では1500となっています。

ネットワーク機器もジャンボフレームを扱わない設計になっているので、1500としています。

それじゃーいけるじゃないか!?

と、思われるかもなのですが、実はこのVxLANというやつが曲者なのです。

サーバー側では1500バイトでNICからデータが送出されますが、対向物理スイッチに至るまでにある、仮想スイッチ側でVxLAN用のタグ50バイト分をこの1500バイトの塊につけるという挙動をします。

それにより、対向スイッチに至るまでにこの塊は1550バイトとなってしまいます。

つまりどういう事だってばよ!

高さ1500のトンネルに車高1550のダンプは通れねえってことだよ!

雑ですみません。。。

結果として、MTUを下げてもらうことで通信ができるようになりました。

さて、ここからがちょっとした問題。

この環境でサーバーを立てるのに注意事項と設計懸念点をこの方にメールと口頭両方でお伝えさせて頂きました。

しかも数人から・・・。

それにも関わらず抜けてしまうのは、間違いなく別の問題があると感じています。

構築する際にはあらかじめ詳細設計まで落とし込んでから行うものだと思っています。

しかしそれが出来ていない事がわかります。

過去の経験上、設計せず構築して場当たり的な対処でパラメータを変えていくのはシステムトラブルの元になります。

ある程度設計を行った上での気付きなら良いと思います。

そこには軸になる設計がありますので、パラメータ変更についても影響範囲が何となくつかめます。

多分導入ベンダーに構築した後に設計書作らせるんだろうな・・・

残り5営業日、それとなく方向修正しようと思いますが受け入れてくれるかどうか。


初めてこのブログで技術的な話をした気がします…。

きっと読者の方々は僕の事を転職芸人か何かだと思っていらっしゃる方がいそう。

その辺りの誤解も今後は解けたらいいなと…おもい…ません!

では今日はこの辺で!