とあるオンラインサービスの拠点NWを作った話

2022年6月22日 15:38

まただいぶ長い期間が空いてしまいました。
今回はそれなりに長期にわたってPL(Playing Leader)をやったのでそのことを書いていきます。
ちなみに、こちらでは薄めに書きますが、現弊社のTechBlogの方でも本件について書く予定ですので、もしかしたら詳細はそちらで知れるかもしれません。

案件について

この案件は端的に表すと
- オンラインサービス
- 某Cloudと連携
- 収容Node数は4桁
- Trafficは~10Gbps
- DHCPも(要件追加)
と言った形のNWを構築して提供する、がベースでした。

NW構成について

なので、この要件を満たせる機器の内、コスト的に優れていて、冗長化箇所の障害時切り替わりの速度が速いものを選定しました。
数機種分の機器検証~構成検証をやったのでなかなかに骨が折れました。
収容NodeがSingleなのでFHRPは無しです。
また、某Cloudとの接続については、1:1NATでInternet経由かクラウド接続線経由にするかで検討し、設定コストやスループットの安定の観点からクラウド接続線経由での接続としました。
拠点内は一般的なRoutingProtocolで経路を回すClos構成とし(ECMP)、拠点間部分についてはスクエア構成での接続としました。
(DFを引いてWDMをおくか、予算が潤沢で専用線を複数引ける場合は拠点間もClosの構成で良いと思いますが)
また、DHCPは各セグメントの収容機器ではなく、DHCP Serverを構築して管理する形としました。当方NW担当でServerの知識は薄い為、DHCPの払い出し方式の検討に頭を悩ませました。

DHCPについて

ここが割と肝になる部分でした。
どこまで書いていいのかわからないので割愛しますが、DHCPのOptionを利用して、Relay時に情報を付加し、その情報を元にServerがアドレスを払い出すようにしました。
これにより、固定DHCPといえばmac-addressベースのところを収容機器のIFベースにすることができ、収容Nodeの故障時はただ差し替えるだけで同じIPが払い出されるようにしました。

構築方法について

NWエンジニアの方ならある程度規模感わかるかと思いますが、4桁のNodeを収容するNWの構築は割と台数が多くなり手間がかかります。
さらに、選定した機種にAnsibleのModuleが存在しないため構築方法に悩みました。
ただ、
- 一度構築したら拡張や設定変更は発生しないという前提があった
- ZTPは対応している
- Closで構成がext-spine-leafの役割単位でIPなどのパラメータ以外同一
上記3点から、ZTPで完成形のconfigを配布すれば良い、AnsibleのTemplate Module + Jinja2でconfigを生成すれば楽、ということでそのように構築しました。
あとはZTPするにあたって、DHCPのOptionがベンダー固有だったため、DHCP Serverにその設定を追加して(3週間くらい方法で悩んだけど)無事に実装できました。
これにより、機器へのConfig投入が並列で行うことが可能となり、3時間ほどで全機器にconfigの投入ができました。
半導体不足の影響でNW機器の納品が遅くなっていたため、結果的に機器設定に工数を取られずに済んでよかったです。
JuniperやAristaなどのsession configuretionができる機器ならともかく、CiscoのIOSと同様にコマンドの投入順を気にしなければいけない機器だったため、手作業よりはるかに時短できました。

障害試験のログ取りについて

こうして構築した環境においての障害試験を実施する場合、
1箇所の障害により問題が発生して通信影響でないかを確認する必要が出てきます。
１項目ごとに各機器でshowコマンドを取得するようにしているのですが、環境の機器の台数が多いと取得が大変になります。
今回はAnsibleが使えない機器のため(2度目)、Pythonのparamikoを使って機器にログインして情報を取得しました。
Ansibleと違ってPython/paramikoならSSHさえできればとりあえず色々できるのが強みですね。手軽さならAnsibleなんですが。

まとめ

文字で起こすと大したことしてない気もしてきますが、結構大変でした。
SESさんに確認者として諸々対応してもらいましたが、主担当として設計検証構築を実施して無事ロールアウトできたのは良き経験になりました。
ちなみに700↑で採用したい、という企業の方がいらっしゃいましたらコメントください。お話伺わせていただきます(ゲス顔)