PGW(on epc)のHighAvailabilityについて

SGWとPGWのLayer2接続において、PGW側のエラー発生について考察する
この時、発生する障害には、次の二つが考えられ、これらのソリューションを定義した

PGWモジュール障害
mysqlデータベース障害

前提条件

前提として、PGW ControlPlaneは、ホストプロトコルスタック上に実装した一般的なBSD-Socketアプリケーションであり、例えば、CPU[10-14]の各コアに割り当てる
PGW DataPlaneは、netmap/dpdk等で実装したプロトコルスタックを介さない高速パケットプロセッシングアプリケーションであり、例えば一つのNIC-ringをCPU[28]に割り当てる

また、ControlPlaneとDataPlane間はデータ共有が必要であり、CPUコア間（スレッド共有）データは非ロック（mutex、semaphoreの同期waitを利用しないデータ同期プロトコル）データ共有とする[^1]

また、コア間データ共有には、http://qiita.com/l2nw/items/c0f7c5bb572cad31da3c
PGWシステム特性に特化した二面ロックフリー構造とする

PGWモジュール障害

今回設計したPGWモジュールは、ControlPlaneとDataPlaneを１モジュールとしているので、PGWモジュール自体はエラー発生時にプロセスダウンさせることで（具体的には、例外をスローしてプロセスを終了させている）、SGWが別PGWグループに再接続することでfailoverが実現できる

mysqlデータベース障害

mysql（筐体故障を含む）データベース障害発生時には、主に２パターンが考えられる

マスターデータベース障害
スレーブデータベース障害（マスター、スレーブ間接続障害含む）

mysqlに注目した正常動作時イメージ

障害発生時（パターンA）

パターンAは、PGWモジュールと、mysqlマスターデータベース間に何らかのエラーが発生し、その復旧には、mysqlへの再接続を必要とするパターンを表す
このケースでは、エラーを検知したPGWモジュールがサービス停止することにより、gtpv2プロトコルによって、SGWがバックアップPGWへ再接続する

障害発生時（パターンB）

パターンBは、定期的なSHOW SLAVE STATUSと、エラー判定を契機として、ステータス管理テーブルにactive=0(非アクティブ：GTPU-Echoに応答しない)を書き込む、その結果プライマリPGWはGTPU-Echoに応答せず、gtpv2プロトコルによって、バックアップPGWに再接続する

[^1] この例では、PGWの１パケット処理はCPUコア[28]スレッドで高速に連続実行させるため、１パケット処理毎にmutex-lock/unlock処理を行うと、高確率でContext-Switchを必要となる。40Gbps等50Mppsオーバーを必要とするパケットプロセッシングではContext-Switch発生を低く保たなければ到達できない

[^2]http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/xeon-lock-scaling-analysis-paper.pdf

のロック・スケール章の記述通り、コア間をまたいだリソースはコスト高であった
実際に実装・評価してみて重要なコンフィグ、実装手法を以下に示す

NIC割り込み先のCPUコアをPCIEが直接接続されているコアに設定
ユーザランドアプリケーションの各スレッドは一つのコアで実行
各スレッドは、そのコンテキスト毎にオペレーションに必要なデータ（例えばstd::map）を[スレッドの起動時に]インスタンシエートし、コンテキストをまたいだデータ領域は行わない）
ミューテクス、セマフォ等の同期オブジェクトが必要な処理としない
広帯域でインスタンス化する変数を配列の形式で宣言しない(optimizeレベルで大きなパフォーマンス差異が発生する、CPU L2キャッシュを汚染）