データセンターのコアスイッチをリプレースしました

インフラ オンプレミス

はじめに

皆さんお久ぶりです。以前DirectConnectで記事を書かせて頂きました TK と申します。 直近で弊社のデータセンターでルーティングを行っているコアスイッチのリプレースを行いました。

今回は特殊な方法を使って切り替えを行いましたので、備忘録も兼ねて記事にします。

背景

コアスイッチのリプレースにおいてアドウェイズのネットワークはどのようになっているのでしょうか？

2013年入社当初と比較して、仮想化技術の普及、クラウドへの移行推進により、ネットワーク基盤の見直しも行われています。
その中でサービスの全通信を経由する機器を交換する際のダウンタイムは短くする必要がありました。

私が入社した2013年頃は、ネットワーク機材メンテナンスに伴うサービスのダウンタイムは AM02:00 ~ 05:00の間で切り替え・切り戻しをそれぞれ5秒以内で行えるように準備した後実施していました。
理想としては、月曜日のAM03:00 ~ 04:00の間でで1～2秒程度の停止ですむことを目指していました。

データセンターのネットワーク機器の停止は、オンプレミスで稼働している全てのサービスが止まってしまうため、メンテナンス時間を設けるにしても、分単位や数時間単位での停止は難しく、通信断は数秒レベルに抑えなければなりません。

とはいえベンダーによっては、停止時間を設けて機器の交換や入れ替えを行うことを推奨されることが多々ありますが、Disaster Recoveryやネットワークを迂回できる環境もないため、停止時間を少なくするためにAdwaysでは推奨方法を使わないケースもあります。

11月12日に公開予定の記事では、弊社のセキュリティ機器をリプレースした際のことを、一緒に作業したメンバーが執筆しますので、ダウンタイムを短くするために行ったケースの一例として是非お目通し下さい。

データセンターのネットワーク

データセンターのネットワークと聞くと、何台もスイッチがあってダイナミックルーティングやVPN、専用線、MPLS、VXLANでアンダーレイとオーバーレイを分離してOpenFlowで機器機能を一括操作してなど思われるかも知れませんが、弊社では個々人がトラブルシュートし辛いというのもあり、ダイナミックルーティングやVXLANは使っていません。（悲しいね。。。。）

ちなみにMulti-Chassis Link Aggregation （以下MLAG）の機能を持つスイッチの投入により、SpanningTreeも使わなくなりました。（なのでCCNAの勉強でSTPプロトコルが実感湧かなくて苦労しています。。。）

個人的にはVXLANとか、OSPFとか色々とネットワーク周り触りたいと思っているのですが、いかんせんそこに時間を掛けるメリットが減ってきているのですよね。。。

前置きが長くなりましたが、今回リプレースする機器の周囲に接続されている機器のイメージは以下の図の通りとなります。

f:id:AdwaysEngineerBlog:20211013174403p:plain

VMが稼働しているハイパーバイザーからストレージ、データベースまでに経由する機器数が多かったりするのはツッコミ無しでお願いします。

スイッチのリプレースにおける問題点

L2レベルの接続ではリプレース対象のArista1~4からVLANを延伸し、ハイパーバイザーやストレージを空にした状態でポートを抜いて挿しなおすことで対応しましたが、ルーティングを行うためのL3部分の移行 で問題が発生しました。 VRRPやHSRPといったプロトコルでは、2台以上の機器をグループに属することによって旧機器から新しい機器へMasterを切り替えることによりゲートウェイのIPを移行することが可能ですが、AristaのVARPはMLA Gの設定を組んだ2台のみしか設定が行えず、新しい機器へゲートウェイのIPを移行することができません。

　

やりたかったこと

新旧のSwitch4台でMLAGとRoutingの冗長化を組み、ルーティングをnew-Switch1,2に寄せる
Switch1,2に繋がっている機器はVLANを延伸したnew-Switch1,2配下に移動する

f:id:AdwaysEngineerBlog:20211013174426p:plain

結論

SwitchのMLAGとRouting冗長化は機器固有の機能で2台構成までしかできず実現不可能
VRRPの場合は2台を超えてグループを組むことができるので実現可能だったかも知れない

　

Aristaのリプレースを行うにあたり、Aristaの購入を検討しているベンダーさん、メーカーさんと会議を行ったところ一つの案が出てきました。

その名は config replace

config replace ってネットワークのプロトコル？冗長化の仕組み？と思われるかも知れませんが違います。 config replace はその名の通り config の replace（置換）。つまりAristaの running-config を別の running-config に瞬間的に置き換えることです。

稼働しているスイッチの設定を瞬間的に書き換えるというのは、恐怖以外の何事でもありません。とはいえ他に良い方法が思いつかないのも事実です。なので config replace がどのくらいの通信断で行えるのか検証する運びとなりました。

config replace を使うと何ができる？

config replace を使うとなぜゲートウェイのIPの切り替えがうまくいくのか？ということですが、config replace を使うと次のような荒業を行うことが可能になります。

f:id:AdwaysEngineerBlog:20211013174447p:plain

やっていることはルーティングを行っているArista1,2との接続しているポートを閉じ、Arista1,2と同じSVI、VARP関連の設定をnew-Arista1,2に入れるだけです。

具体的な移行手順

  1. 新しいAristaの設置

    f:id:AdwaysEngineerBlog:20211013174546p:plain

  2. 配線の収容替え 個々の機器をそれぞれ停止やFailoverを行いつつ new-Aristaに移動する

    f:id:AdwaysEngineerBlog:20211013174618p:plain

  3. コンフィグリプレースの実施 Arista1,2へのポートをシャットダウンするのとSVI、VARPの設定を入れたコンフィグにnew-Arista1,2をフラッシュする

    f:id:AdwaysEngineerBlog:20211013174637p:plain

この方法で切り替えた場合のダウンタイム

さて理論上は切り替え可能ではありますが、その際のダウンタイムは如何ほどでしょうか？

前提としてArista の config replace は running-config を 指定した config で flush するため、running-config の量に比例して時間が掛かります。
また、STPやOSPFといったルートの計算を行ったり結果の収束が必要なプロトコルを使っている場合は以下の表の限りではないので参考に留めておいてください。

ダウンタイムの計測にはVMからSwitchのSVIに対して1秒間に1つずつPINGを打ち続けて計測

実施機器 Arista(VARP) 　検証機(VRRP)
config replace のダウンタイム 1sec 3 ~ 20sec*1
切り戻し時のダウンタイム 24sec 24sec　

config replace のダウンタイムについて

config replace による切り替えで Arista(VARP), 検証機(VRRP) での違いについて補足です。
VARPとVRRPで切り替え時のダウンタイムと切り戻し時のダウンタイムでなぜここまで差が出るのかについて説明します。

まず個々の機器の違いについて説明します。

  • Arista
    • L2冗長化機能：MLAG
    • L3冗長化機能：VARP（VRRPも選択可能）
  • 検証機
    • L2冗長化機能：MLAG（メーカーによってはMC-LAGなど呼び方が異なる）
    • L3冗長化機能：VRRP

VARPとVRRPの挙動について違いを挙げていきます。

  • VARP

    • Master, Backupという概念がなく、両機がActiveとして稼働する
    • 機器間で同じMACアドレスとIPアドレスを持つ
    • ルーティングを行う際には、パケットが最初に到達した機器でルーティングを行う

  • VRRP

    • Master,Backupを最初に決める
    • グループ内のMasterのみVIPを持ち、Masterが変わってもVIPとMACアドレスを引き継ぐ
    • MLAGと併せて利用することでBackup側の機器でもパケットをルーティングことが可能な機器もある

Aristaと検証機では両方の機器がトラフィックを処理するので機能的には問題ないようにみえますが、Aristaは設定を反映した瞬間に両機でIPの応答を行うのに対し、検証機ではMaster,　Backup の選定が完了 するまではパケットの処理が行えない状態となります。

切り戻し時のダウンタイムについて

ネットワークエンジニアたるもの万事うまく行くことが大事だと思いますが、予想外のことは突然起こるものです。問題発生時の切り戻しも視野に入れて作業をしなければ被害は大きくなります。 切り戻しの際のダウンタイムですが、意外な結果となりました。

この24秒というのはconfig replace による設定の書き換え後に、VARPやSVI、ポートシャットダウンの設定が無い状態に戻す作業のことですが、なぜこれ程時間が掛かってしまったのでしょうか？

結論から言いますと、ポートのリンクアップ＋LAG（LACP）のネゴシエーション、そしてMACアドレステーブルの更新が必要となるからです。

そのためMACアドレステーブルを一度クリアすれば良いのですが、中継する機器を全部クリアするのも骨が折れますし、そもそもなぜ切り替えの際にはMACアドレステーブル周りの問題は発生しなかったのでしょうか？

config replace の際に VARPで利用するMACアドレスを引き継ぐことで通信断を最小化

config replace の際に ip virtual-router mac-address でArista1,2と同じMACアドレスを設定したことで、VMや個別の機器でのARPの変更は発生せず、また中継する機器においてもMACアドレステーブルの更新 が最低減で済んだためにダウンタイムが小さくなったと想定できます。

最後に

さてこのコアスイッチのリプレースプロジェクトですが、config replace を使った手法を提案してくれたベンダー様、そしてメーカーのArista様に最大の感謝を
Adwaysの基礎となるネットワークを設計された方からは
「コアスイッチの交換作業においてPINGロスが1秒程度なのは過去最高の成果」
との言葉も頂きました。
また、本作業の際に各種調整や予算の確保、上長との調整など私の苦手とする部分をプロジェクトのメンバー間対応して頂けて私一人ではこのPJはうまくいかず挫折していたのではと思います。
長くなりましたが、以上で今回のブログを終了します。
ブログの執筆は苦手でお見苦しい所も多々あったと思いますが、何卒ご容赦頂けますと幸いです。

*1:HelloタイマーとHoldタイマーにより差が変わる