JP6511013B2

JP6511013B2 - Ｓｆｃシステム、および、ｓｆｃ制御方法

Info

Publication number: JP6511013B2
Application number: JP2016100723A
Authority: JP
Inventors: 裕朗河原崎
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2016-05-19
Filing date: 2016-05-19
Publication date: 2019-05-08
Anticipated expiration: 2036-05-19
Also published as: JP2017208735A

Description

本発明は、ＳＦＣシステム、および、ＳＦＣ制御方法の技術に関する。

ＤＰＩ（Deep Packet Inspection）やＦＷ（FireWall）などのネットワークサービス機能であるＳＦ（Service Function）を複数組み合わせて、論理的に１つのサービスを提供するＳＦＣ（Service Function Chaining）という枠組みが非特許文献１にて提案されている。このＳＦＣにより、様々なフローに対して様々なＳＦを提供するときの組み合わせを容易に管理することができ、豊富かつ拡張性の高い通信システムを構築することができる。

Internet Engineering Task Force (IETF)、"Service Function Chaining (SFC) Architecture"、［online］、2015年10月、［2016年5月9日検索］、インターネット〈URL：https://tools.ietf.org/html/rfc7665〉

通信システムの入口にロードバランサが設置されるような既存の負荷分散システムをそのまま１つのＳＦとしてＳＦＣシステム内に組み込むと、ＳＦＣシステム全体が複雑になってしまう。

そこで、本発明は、既存の負荷分散システムを効率的にＳＦＣシステムに組み込むことを、主な課題とする。

前記課題を解決するために、本発明のＳＦＣシステムは、以下の特徴を有する。
つまり、ＳＦＣシステムは、同じＳＦを実行する複数のサーバをメンバとするＳＦＧ（Service Function Group）として、メンバの順序が互いに異なるサーバの台数分のＳＦＧが定義されており、
受信したパケットをフローに分類し、分類されたフローが経由するＳＦＧを決定するクラシファイヤ装置と、
前記クラシファイヤ装置から転送されたパケットについて、そのパケットが経由するＳＦＧに含まれるサーバからメンバ選択アルゴリズムにより選択したサーバに対してパケットを転送するＳＦＦと、を有することを特徴とする。

クラシファイヤ装置がＳＦＧを決定し、ＳＦＦがＳＦＧ内のメンバの選択を行うことで、同じＳＦを実行する複数のサーバからいずれか１つのサーバを選択するロードバランサ機能を実現できる。よって、ロードバランサを単体の装置として増設する必要がなくなるので、既存の負荷分散システムを効率的にＳＦＣに組み込むことができる。

本発明は、前記ＳＦＦが、前記メンバの順序をもとにしたメンバ選択アルゴリズムとして、稼働チェックにより稼働が確認されたサーバのうちの最も順序が先であるサーバを、パケットの転送先として決定することを特徴とする。

これにより、稼働していないサーバにフローを流してパケットロスをする障害を予防できる。

本発明によれば、既存の負荷分散システムを効率的にＳＦＣに組み込むことができる。

本実施形態に係わるＳＦＣのＳＦＣシステムの構成図である。本実施形態に係わる図１のＳＦＣシステムに、負荷分散構成の既存サーバを適用した構成図である。本実施形態に係わる図２のＳＦＣシステムにおいて、負荷分散の第１収容形態を示す構成図である。本実施形態に係わる図２および図３それぞれに使用されるデータの一例を示す。本実施形態に係わる図１のＳＦＣシステムに、負荷分散構成の既存サーバを適用した構成図である。本実施形態に係わる図５のＳＦＣシステムにおいて、負荷分散の第２収容形態を示す構成図である。本実施形態に係わる図６に使用されるデータの一例を示す。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、ＳＦＣシステムの構成図である。
このＳＦＣシステムは、発信装置１と、クラシファイヤ装置２と、ＳＦＦ（Service Function Forwarder）装置（図１のＳＦＦ３１、３２）と、ＤＰＩ−ＳＦ４０と、ＦＷ−ＳＦ５０と、着信装置７とがネットワークで接続されて構成される。ＳＦＦなどのＳＦＣの構成要素の定義は、非特許文献１に記載されている。
なお、ＳＦＣシステムの各装置は、それぞれＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。

ＳＦＰ（Service Function Path）８，９は、ＳＦＣシステム内に設定される通信路（パス）である。これらのパスは、発信装置１から送信されるパケットのフローごとに設定され、そのフローのパケットについて、どのＳＦを経由させてから着信装置７に転送するかを示す。
ＳＦＦ３１、３２は、１つ以上のＳＦを収容する。ＳＦＦ３１、３２は、ＳＦＰ８，９を流れるパケットのＳＦＣカプセル化された情報をもとに、配下のＳＦにパケットを転送するか否かを決定する。

クラシファイヤ装置２は、発信装置１から送信されるパケットのフローを識別するClassifierである。クラシファイヤ装置２はパケットの送信元アドレスなどを参照してフローを識別することで、どのＳＦＰにパケットを流すかを決定する。

ＳＦＰ８は、ユーザ用のパケットのフローを通過させるＳＦＰである。一般ユーザには、正規のユーザだけでなく不正な攻撃者も含まれていることもある。よって、ＳＦＰ８は、ネットワークへの不正アクセスを遮断するＦＷ−ＳＦ５０だけでなく、パケットにウィルスが混入していないかなどのパケットの中身をチェックするＤＰＩ−ＳＦ４０も経由させる。
つまり、ＳＦＰ８の経路は「発信元→ＤＰＩ−ＳＦ４０→ＦＷ−ＳＦ５０→着信先」である。

一方、ＳＦＰ９は、例えば、ＳＦＣシステムを運営する事業者の社員用のパケットのフローを通過させるＳＦＰである。よって、ＳＦＰ９は、ＤＰＩ−ＳＦ４０の経由を省略し、ＦＷ−ＳＦ５０だけ通過させればよい。
つまり、ＳＦＰ９の経路は「発信元→ＦＷ−ＳＦ５０→着信先」である。

図２は、図１のＳＦＣシステムにおいて、ＤＰＩ−ＳＦ４０に、負荷分散構成の既存サーバを適用した構成図である。
負荷分散構成の既存サーバとして３台のＤＰＩサーバ４２〜４４を導入するとともに、その既存サーバのいずれかにパケットを負荷分散するＬＢ（Load Balancer）４１を導入する。なお、ＤＰＩサーバ４２〜４４などの実際にＳＦを提供するサーバの台数は３台に限定されず、任意の台数としてもよい。
このように、ＤＰＩ−ＳＦ４０の内部が複数の物理計算機によって構成されていても、論理的に１つのＳＦとしてＤＰＩ−ＳＦ４０を提供する。これにより、図１のＳＦＰ８の経路「発信元→ＤＰＩ−ＳＦ４０→ＦＷ−ＳＦ５０→着信先」をそのまま図２でも活用することができる。

一方、ＤＰＩサーバ４２〜４４に加えて、ＬＢ４１を新たに用意することで、ＳＦＣシステムが複雑化してしまい、装置の導入コスト、設置コスト、保守コストなどが余分にかかってしまう。

図３は、図２のＳＦＣシステムにおいて、負荷分散の収容形態を示す構成図である。
図３では、図２のＬＢ４１を省略する代わりに、ＬＢ４１の配下であった（同じＤＰＩ−ＳＦ４０として負荷分散先であった）各ＤＰＩサーバ４２〜４４を、ＤＰＩ−ＳＦｂ４９としている。ＤＰＩ−ＳＦｂ４９に対してメンバの順序が互いに異なる３つのＳＦＧが以下に示すように定義される（図４のサービスファンクショングループ表１０２で後記）。
・「ＤＰＩサーバ４２→ＤＰＩサーバ４３→ＤＰＩサーバ４４」の順に構成される「DPI-SFG1」
・「ＤＰＩサーバ４３→ＤＰＩサーバ４４→ＤＰＩサーバ４２」の順に構成される「DPI-SFG2」
・「ＤＰＩサーバ４４→ＤＰＩサーバ４２→ＤＰＩサーバ４３」の順に構成される「DPI-SFG3」

そして、図２のＬＢ４１が行っていた、「どのパケットをどのＤＰＩサーバ４２〜４４に割り当てるか」というロードバランス処理は、図３では、クラシファイヤ装置２とＳＦＦ３１とで分担して実行される。具体的には、クラシファイヤ装置２がＳＦＧ表１０１を参照してＳＦＧを選択し、ＳＦＦ３１がサービスファンクショングループ表１０２を参照してＳＦＧからメンバを選択する。
なお、標準化に提案されているＳＦＧ選択アルゴリズムは、以下の文書に記載されている。
The OpenDaylight Foundation、"Service Function Scheduler Type"、［online］、［平成28年5月9日検索］、インターネット〈URL：https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-scheduler-type.yang〉

なお、ＬＢ４１がＳＦＣの機構（クラシファイヤ装置２、ＳＦＦ３１、３２）に対して、独立した１装置として組み込まれている図２の形態を「独立形態」と呼ぶ。一方、ＬＢ４１がＳＦＣの機構（クラシファイヤ装置２、ＳＦＦ３１、３２）に収容されている（独立していない）図３の形態を「収容形態」と呼ぶ。なお、「収容形態」は図３の構成だけでなく後記の図６の構成も挙げるため、両者を区別するために図３の形態を「第１収容形態」とする。

図４は、図３に使用されるデータの一例を示す。図４では本発明の説明に必要な情報のみを記載している。

図３の第１収容形態で使用されるＳＦＧ表１０１では、ＳＦＧの数をサーバの台数分（ここでは３つ）用意する。

図３の第１収容形態で使用されるサービスファンクショングループ表１０２は、ＳＦＧ表１０１のＳＦＧごとに、パケットの転送先であるメンバを選択するときのメンバ選択アルゴリズムと、選択候補のメンバの順序リスト（第１メンバ、第２メンバ、第３メンバ）とを対応付けている。
メンバ選択アルゴリズム「FAST_FAILURE」は、以下の文書に記載されているように、グループのメンバのノードを先頭から順にチェックし、稼働している最初のサーバを選択するアルゴリズムである。
The OpenDaylight Foundation、"Service Function Group Algorithms"、［online］、2015年4月9日、［平成28年5月9日検索］、インターネット〈URL：https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-group-algorithm.yang〉

また、サービスファンクショングループ表１０２などに記載されるＳＦＧの形式については、以下の文書に記載されている。
The OpenDaylight Foundation、"Service Function Group"、［online］、［平成28年5月9日検索］、インターネット〈URL：https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-group.yang〉

クラシファイヤ装置２は、ＳＦＧ表１０１内に登録された複数のＳＦＧから、ラウンドロビンなどの選択アルゴリズムを用いて、フローが経由する１つのＳＦＧを決定する。

例えば、ＤＰＩサーバ４３が故障中であり、ＤＰＩサーバ４２とＤＰＩサーバ４４とが稼働中であるとする。そして、クラシファイヤ装置２が「DPI-SFG2」のＳＦＧに割り当てたパケットを、ＳＦＦ３１が受信した場合を考える。ＳＦＦ３１は、クラシファイヤ装置２が記載したパケットのＳＦＣカプセル化された情報をもとにフローが経由するＳＦＧ「DPI-SFG2」を特定する。
そして、ＳＦＦ３１は、サービスファンクショングループ表１０２の「DPI-SFG2」に対応する「FAST_FAILURE」に従って、「DPI-SFG2」の第１メンバである「ＤＰＩサーバ４３」へのサーバヘルスチェック（稼働チェック）を行う。しかし、「ＤＰＩサーバ４３」は前記したとおり、故障中である。

よって、ＳＦＦ３１は、第２メンバ「ＤＰＩサーバ４４」へのサーバヘルスチェックにより稼働を確認した後、そのＤＰＩサーバ４４に対してＳＦＧ「DPI-SFG2」のパケットを転送する。
これにより、ＬＢ４１をわざわざ別装置として用意することなくロードバランサ機能が実現され、システム構成がスリムになる。

図５は、図１のＳＦＣシステムに、負荷分散構成の既存サーバを適用した構成図である。図５でＤＰＩ−ＳＦ４０として適用する負荷分散構成は、特開２０１２−１６００７５号のトランザクション処理システムである。このトランザクション処理システムは、データの所在を考慮した負荷分散処理により、処理効率を向上させている。

ＤＰＩ−ＳＦ４０は、ＳＦＦ３１からパケットを受け付ける窓口となるＬＢ４１に加え、ＬＢ４１からのパケットの転送先となる転送サーバ（ＤＳ）６１〜６３と、ＤＳ６１〜６３のいずれかから転送されたフローのデータを処理する処理サーバ（ＰＳ）７１〜７３と、処理対象のデータを格納するデータ管理装置（ＤＭ）８１〜８３とを有する。なお、１つの処理サーバは、１つのデータ管理装置と密に（直接）接続されており（例えばＰＳ７１とＤＭ８１との間）、高速にアクセス可能である。

図５では、ユーザ用のパケットのフローについてＤＰＩ−ＳＦ４０を経由させることを決定する。そして、ＬＢ４１は各パケットを転送サーバ（ＤＳ）６１〜６３のいずれかに転送する。
しかし、図５のシステムでは、図２と同様に、ＬＢ４１が１つの外付け装置として追加されるので、システム構成が複雑化してしまう。

そこで、図６のシステムでは、図３と同様に、ＤＰＩ−ＳＦｂ４９で複数のサーバをグループ化し、ＬＢ４１の負荷分散処理をクラシファイヤ装置２とＳＦＦ３１とが代行することで、システム構成を簡略化する。つまり、ＤＰＩ−ＳＦｂ４９に対してメンバの順序が互いに異なる３つのＳＦＧが以下に示すように定義される（図７のサービスファンクショングループ表１１２で後記）。
・「ＤＳ６１→ＤＳ６２→ＤＳ６３」の順に構成される「DPI-SFG1」
・「ＤＳ６２→ＤＳ６３→ＤＳ６１」の順に構成される「DPI-SFG2」
・「ＤＳ６３→ＤＳ６１→ＤＳ６２」の順に構成される「DPI-SFG3」

図７は、図６の構成で使用されるデータの一例を示す。
ＳＦＧ表１１１は、図４のＳＦＧ表１０１と同様に、サービスファンクショングループ表１０３のメンバ（ＤＳ６１〜６３）ごとに別々のＳＦＧ（DPI-SFG1〜DPI-SFG3）が用意される。
サービスファンクショングループ表１１２は、図４のサービスファンクショングループ表１０２と同様に、具体的に選択候補のメンバから転送先のメンバを選択するための情報がＳＦＧごとに対応付けられている。つまり、図４のサービスファンクショングループ表１０２と図７のサービスファンクショングループ表１１２との違いは、メンバ構成（第１メンバ〜第３メンバ）である。

図４の説明で示したように、図７でもクラシファイヤ装置２がＳＦＧ表１１１を参照し、ラウンドロビンなどの選択アルゴリズムを用いて、同じＳＦを提供するＳＦＧ（「DPI-SFG1〜DPI-SFG3」）からフローが経由するＳＦＧを選択する。
そして、ＳＦＦ３１は、サービスファンクショングループ表１１２を参照し、受信したパケットのＳＦＧに対応する「メンバ選択アルゴリズム（FAST_FAILURE）」に従って、最終的に１台のメンバを選択する。ＳＦＦ３１は、選択したメンバ（ＤＳ６３など）へフローのパケットを転送する。

以上説明した本実施形態では、負荷分散のために設置された複数のサーバをＳＦＧとしてグループ化する。このＳＦＧは、サーバの台数分だけ設けられ、各ＳＦＧは他のＳＦＧと比べると、メンバのサーバの順序が互いに異なっている。
そして、クラシファイヤ装置２は受信したパケットのフローをＳＦＧ選択アルゴリズムに従ってＳＦＧに分類する。ＳＦＦ３１は、グループ化されたサーバ群から最終的に選択したサーバに対してパケットを転送する。
これにより、ＬＢ４１をわざわざ別装置として用意することなくロードバランサ機能が実現され、システム構成がスリムになる。

１発信装置
２クラシファイヤ装置
７着信装置
８，９ＳＦＰ
３１，３２ＳＦＦ
４０ＤＰＩ−ＳＦ
４１ＬＢ
４２〜４４ＤＰＩサーバ
４９ＤＰＩ−ＳＦｂ
５０ＦＷ−ＳＦ
１０１，１１１ＳＦＧ表
１０２，１１２サービスファンクショングループ表

Claims

同じＳＦ（Service Function）を実行する複数のサーバをメンバとするＳＦＧ（Service Function Group）として、メンバの順序が互いに異なるサーバの台数分のＳＦＧが定義されており、
受信したパケットをフローに分類し、分類されたフローが経由するＳＦＧを決定するクラシファイヤ装置と、
前記クラシファイヤ装置から転送されたパケットについて、そのパケットが経由するＳＦＧに含まれるサーバからメンバ選択アルゴリズムにより選択したサーバに対してパケットを転送するＳＦＦと、を有することを特徴とする
ＳＦＣシステム。
前記ＳＦＦは、前記メンバの順序をもとにしたメンバ選択アルゴリズムとして、稼働チェックにより稼働が確認されたサーバのうちの最も順序が先であるサーバを、パケットの転送先として決定することを特徴とする
請求項１に記載のＳＦＣシステム。
ＳＦＣシステムは、クラシファイヤ装置と、ＳＦＦとを含めて構成され、
同じＳＦ（Service Function）を実行する複数のサーバをメンバとするＳＦＧ（Service Function Group）として、メンバの順序が互いに異なるサーバの台数分のＳＦＧが定義されており、
前記クラシファイヤ装置は、受信したパケットをフローに分類し、分類されたフローが経由するＳＦＧを決定し、
前記ＳＦＦは、前記クラシファイヤ装置から転送されたパケットについて、そのパケットが経由するＳＦＧに含まれるサーバからメンバ選択アルゴリズムにより選択したサーバに対してパケットを転送することを特徴とする
ＳＦＣ制御方法。
前記ＳＦＦは、前記メンバの順序をもとにしたメンバ選択アルゴリズムとして、稼働チェックにより稼働が確認されたサーバのうちの最も順序が先であるサーバを、パケットの転送先として決定することを特徴とする
請求項３に記載のＳＦＣ制御方法。