特許第6556875号(P6556875)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 華為技術有限公司の特許一覧

特許6556875ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法
<>
  • 特許6556875-ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法 図000005
  • 特許6556875-ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法 図000006
  • 特許6556875-ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法 図000007
  • 特許6556875-ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法 図000008
  • 特許6556875-ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法 図000009
  • 特許6556875-ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法 図000010
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6556875
(24)【登録日】2019年7月19日
(45)【発行日】2019年8月7日
(54)【発明の名称】ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法
(51)【国際特許分類】
   H04L 12/717 20130101AFI20190729BHJP
   H04L 12/70 20130101ALI20190729BHJP
   H04L 12/803 20130101ALI20190729BHJP
【FI】
   H04L12/717
   H04L12/70 D
   H04L12/803
【請求項の数】20
【全頁数】28
(21)【出願番号】特願2017-564843(P2017-564843)
(86)(22)【出願日】2015年12月31日
(65)【公表番号】特表2018-522471(P2018-522471A)
(43)【公表日】2018年8月9日
(86)【国際出願番号】CN2015100222
(87)【国際公開番号】WO2017113344
(87)【国際公開日】20170706
【審査請求日】2017年12月14日
(73)【特許権者】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】HUAWEI TECHNOLOGIES CO.,LTD.
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】武 杰
(72)【発明者】
【氏名】左 少夫
【審査官】 鈴木 肇
(56)【参考文献】
【文献】 特開2013−105308(JP,A)
【文献】 中国特許出願公開第104753715(CN,A)
【文献】 米国特許出願公開第2015/0124812(US,A1)
【文献】 特開2005−151107(JP,A)
【文献】 特開2015−002438(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 13/00
H04L 12/00−12/955
(57)【特許請求の範囲】
【請求項1】
ソフトウェアディファインドデータセンタにおけるサービスクラスタのための配置方法であって、前記ソフトウェアディファインドデータセンタはソフトウェアディファインドネットワーキング(SDN)コントローラ及び複数のエッジスイッチを有し、前記複数のエッジスイッチは前記SDNコントローラに通信可能に接続され、複数の静的バーチャルマシーンは前記ソフトウェアディファインドデータセンタにおいて定義され、各静的バーチャルマシーンはIPアドレス及び媒体アクセス制御MACアドレスによって設定され、同じサービスクラスタに属し、前記複数の静的バーチャルマシーンにある静的バーチャルマシーンのIPアドレスは共有IPアドレスとして設定され、
当該方法は、
前記SDNコントローラが、第1のエッジスイッチによって送信されるバーチャルマシーンゴーオンラインイベントを取得するステップであって、前記第1のエッジスイッチは新たなオンラインバーチャルマシーンによってアクセスされるエッジスイッチである、取得するステップと、
前記SDNコントローラが、前記新たなオンラインバーチャルマシーンのMACアドレスを取得し、前記新たなオンラインバーチャルマシーンのMACアドレスと前記複数の静的バーチャルマシーンから選択された候補バーチャルマシーンのMACアドレスとの間のマッチングを実行し、前記候補バーチャルマシーンの前記MACアドレスが前記新たなオンラインバーチャルマシーンのMACアドレスと同じであるとき、前記候補バーチャルマシーンが前記新たなオンラインバーチャルマシーンであると判定し、前記第1のエッジスイッチを前記候補バーチャルマシーンにバインドするステップと、
前記SDNコントローラが、前記新たなオンラインバーチャルマシーンのIPアドレスが共有IPアドレスであるか特定し、前記新たなオンラインバーチャルマシーンのIPアドレスが前記共有IPアドレスである場合、前記共有IPアドレスに対応するサービスクラスタに前記新たなオンラインバーチャルマシーンを配置するステップと、
を有する方法。
【請求項2】
前記SDNコントローラが、前記新たなオンラインバーチャルマシーンの前記MACアドレスを取得する前に、当該方法は更に、
前記SDNコントローラが、前記複数の静的バーチャルマシーンから前記候補バーチャルマシーンを選択するステップを有し、
前記SDNコントローラが、前記新たなオンラインバーチャルマシーンのMACアドレスを取得するステップは、
前記SDNコントローラが、前記候補バーチャルマシーンのゲートウェイをシミュレートすることによって、特定リクエストメッセージを前記新たなオンラインバーチャルマシーンに送信するステップであって、前記特定リクエストメッセージは、前記新たなオンラインバーチャルマシーンのMACアドレスを報告するよう前記新たなオンラインバーチャルマシーンに指示するのに用いられる、送信するステップと、
前記SDNコントローラが、前記特定リクエストのものであって、前記新たなオンラインバーチャルマシーンによって送信されるレスポンスメッセージを受信し、前記特定リクエストのレスポンスメッセージにおいて搬送される前記新たなオンラインバーチャルマシーンのMACアドレスを取得するステップと、
を有する、請求項1記載の方法。
【請求項3】
前記特定リクエストメッセージは、アドレス解決プロトコル(ARP)リクエストパケットであり、前記特定リクエストのレスポンスメッセージは、ARPレスポンスパケットであり、前記ARPリクエストパケットのARPリクエスト部分におけるデスティネーションMACアドレスは、特別なフィールドで埋め込まれ、前記特別なフィールドは、前記デスティネーションMACアドレスが応答側によって埋め込まれるべきであることを示す、請求項2記載の方法。
【請求項4】
前記SDNコントローラが、前記新たなオンラインバーチャルマシーンの前記MACアドレスを取得するステップは、
前記SDNコントローラが、前記新たなオンラインバーチャルマシーンによって送信され、前記第1のエッジスイッチによって転送される特定リクエストメッセージを受信するステップと、
前記SDNコントローラが、前記特定リクエストメッセージにおいて搬送される前記新たなオンラインバーチャルマシーンのMACアドレスを取得するステップを有する、請求項1記載の方法。
【請求項5】
前記SDNコントローラが、前記共有IPアドレスに対応する前記サービスクラスタに前記新たなオンラインバーチャルマシーンを配置する前に、当該方法は更に、
前記サービスクラスタが生成されているか確認し、前記サービスクラスタが生成されていない場合、前記共有IPアドレスを識別子として用いることによって前記サービスクラスタを生成するステップを有する、請求項1乃至4何れか一項記載の方法。
【請求項6】
前記SDNコントローラが、前記サービスクラスタに含まれる何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定し、何れかのオンラインバーチャルマシーンのIPアドレスが無効であると判定すると、前記無効なアドレスを有する前記オンラインバーチャルマシーンを前記サービスクラスタから削除するステップを更に有する、請求項1乃至5何れか一項記載の方法。
【請求項7】
前記SDNコントローラが、前記サービスクラスタにおける何れかのオンラインバーチャルマシーンの前記IPアドレスが無効であるか判定する前に、当該方法は更に、
前記SDNコントローラが、前記サービスクラスタのヘルスチェックを開始し、前記ヘルスチェックの結果に従って、前記サービスクラスタにおける何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定するステップを有する、請求項6記載の方法。
【請求項8】
前記SDNコントローラが、前記サービスクラスタの前記ヘルスチェックを開始し、前記ヘルスチェックの前記結果に従って、前記サービスクラスタにおける何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定するステップは、
前記SDNコントローラが、少なくとも1つのエッジスイッチによって送信されるポート状態イベントを受信するステップと、
インタフェース状態が異常であるポートに対応するオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、前記ポート状態イベントに従ってインタフェース状態が異常であるポートを判定するステップと、
を有する、請求項7記載の方法。
【請求項9】
前記SDNコントローラが、前記サービスクラスタの前記ヘルスチェックを開始し、前記ヘルスチェックの前記結果に従って、前記サービスクラスタにおける何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定するステップは、
前記SDNコントローラが、前記サービスクラスタにおける前記オンラインバーチャルマシーンにリンク状態検出リクエストを周期的に送信するステップと、
レスポンスメッセージタイムアウトに遭遇したオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、前記リンク状態検出リクエストのものであって、前記サービスクラスタにおける前記オンラインバーチャルマシーンによって返されるレスポンスメッセージが所定の時間内に受信されるか監視するステップと、
を有する、請求項7記載の方法。
【請求項10】
前記SDNコントローラが、前記サービスクラスタの前記ヘルスチェックを開始し、前記ヘルスチェックの前記結果に従って、前記サービスクラスタにおける何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定するステップは、
前記SDNコントローラが、経時転送フローテーブルイベントに対応するオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、少なくとも1つのエッジスイッチによって送信される前記経時転送フローテーブルイベントを受信するステップであって、前記経時転送フローテーブルイベントは、転送フローテーブルのアイドル時間が経時時間まで累積すると、前記転送フローテーブルが削除されることを示す、受信するステップを有する、請求項7記載の方法。
【請求項11】
ソフトウェアディファインドデータセンタであって、前記ソフトウェアディファインドデータセンタはソフトウェアディファインドネットワーキング(SDN)コントローラ及び複数のエッジスイッチを有し、前記複数のエッジスイッチは前記SDNコントローラに通信可能に接続され、複数の静的バーチャルマシーンは前記ソフトウェアディファインドデータセンタにおいて定義され、各静的バーチャルマシーンはIPアドレス及び媒体アクセス制御(MAC)アドレスによって設定され、同じサービスクラスタに属し、前記複数の静的バーチャルマシーンにある静的バーチャルマシーンのIPアドレスは共有IPアドレスとして設定され、
前記複数のエッジスイッチは、前記SDNコントローラからパケット転送情報をリクエストし、前記SDNコントローラによって配信される転送フローテーブルに従ってパケットを転送するよう構成され、
共有IPアドレスにより設定されるバーチャルマシーンは、前記ソフトウェアディファインドデータセンタにおけるネットワークにアクセスした後、オンラインバーチャルマシーンとして前記共有IPアドレスに対応するサービスクラスタを加えるよう構成され、
前記SDNコントローラは、第1のエッジスイッチによって送信されるバーチャルマシーンゴーオンラインイベントを取得し、前記第1のエッジスイッチは新たなオンラインバーチャルマシーンによってアクセスされるエッジスイッチであり、前記新たなオンラインバーチャルマシーンのMACアドレスを取得し、前記新たなオンラインバーチャルマシーンのMACアドレスと前記複数の静的バーチャルマシーンから選択された候補バーチャルマシーンのMACアドレスとの間のマッチングを実行し、前記候補バーチャルマシーンの前記MACアドレスが前記新たなオンラインバーチャルマシーンのMACアドレスと同じであるとき、前記候補バーチャルマシーンが前記新たなオンラインバーチャルマシーンであると判定し、前記第1のエッジスイッチを前記候補バーチャルマシーンにバインドし、前記新たなオンラインバーチャルマシーンのIPアドレスが前記共有IPアドレスであるか特定し、前記新たなオンラインバーチャルマシーンのIPアドレスが前記共有IPアドレスである場合、前記共有IPアドレスに対応するサービスクラスタに前記新たなオンラインバーチャルマシーンを配置するよう構成されるソフトウェアディファインドデータセンタ。
【請求項12】
前記SDNコントローラは、前記複数の静的バーチャルマシーンから前記候補バーチャルマシーンを選択し、前記候補バーチャルマシーンのゲートウェイをシミュレートすることによって、特定リクエストメッセージを前記新たなオンラインバーチャルマシーンに送信し、前記特定リクエストメッセージは、前記新たなオンラインバーチャルマシーンのMACアドレスを報告するよう前記新たなオンラインバーチャルマシーンに指示するのに用いられ、前記特定リクエストのものであって、前記新たなオンラインバーチャルマシーンによって送信されるレスポンスメッセージを受信し、前記特定リクエストのレスポンスメッセージにおいて搬送される前記新たなオンラインバーチャルマシーンのMACアドレスを取得するよう構成される、請求項11記載のソフトウェアディファインドデータセンタ。
【請求項13】
前記SDNコントローラは、前記新たなオンラインバーチャルマシーンによって送信され、前記第1のエッジスイッチによって転送される特定リクエストメッセージを受信し、前記特定リクエストメッセージにおいて搬送される前記新たなオンラインバーチャルマシーンの前記MACアドレスを取得するよう構成される、請求項11記載のソフトウェアディファインドデータセンタ。
【請求項14】
前記SDNコントローラは更に、前記サービスクラスタに含まれる何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定し、何れかのオンラインバーチャルマシーンのIPアドレスが無効であると判定すると、前記無効なアドレスを有する前記オンラインバーチャルマシーンを前記サービスクラスタから削除するよう構成される、請求項11乃至13何れか一項記載のソフトウェアディファインドデータセンタ。
【請求項15】
前記サービスクラスタにおける何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定する前に、前記SDNコントローラは更に、前記サービスクラスタのヘルスチェックを開始し、前記ヘルスチェックの結果に従って、前記サービスクラスタにおける何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定するよう構成される、請求項14記載のソフトウェアディファインドデータセンタ。
【請求項16】
前記SDNコントローラは、
少なくとも1つのエッジスイッチによって送信されるポート状態イベントを受信し、インタフェース状態が異常であるポートに対応するオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、前記ポート状態イベントに従ってインタフェース状態が異常であるポートを判定するよう構成される、請求項15記載のソフトウェアディファインドデータセンタ。
【請求項17】
前記SDNコントローラは、
前記サービスクラスタにおける前記オンラインバーチャルマシーンにリンク状態検出リクエストを周期的に送信し、レスポンスメッセージタイムアウトに遭遇したオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、前記リンク状態検出リクエストのものであって、前記サービスクラスタにおける前記オンラインバーチャルマシーンによって返されるレスポンスメッセージが所定の時間内に受信されるか監視するよう構成される、請求項15記載のソフトウェアディファインドデータセンタ。
【請求項18】
前記SDNコントローラは、
経時転送フローテーブルイベントに対応するオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、少なくとも1つのエッジスイッチによって送信される経時転送フローテーブルイベントを受信するよう構成され、前記経時転送フローテーブルイベントは、転送フローテーブルのアイドル時間が経時時間まで累積すると、前記転送フローテーブルが削除されることを示す、請求項15記載のソフトウェアディファインドデータセンタ。
【請求項19】
プロセッサ、メモリ、バス及び通信インタフェースを有する計算デバイスであって、
前記メモリは実行可能な命令を記憶するよう構成され、前記プロセッサ及び前記メモリは前記バスを用いることによって接続され、前記計算デバイスが実行されると、前記プロセッサは、
第1のエッジスイッチによって送信されるバーチャルマシーンゴーオンラインイベントを取得するステップであって、前記第1のエッジスイッチは新たなオンラインバーチャルマシーンによってアクセスされるエッジスイッチである、取得するステップと、
前記新たなオンラインバーチャルマシーンのMACアドレスを取得し、前記新たなオンラインバーチャルマシーンのMACアドレスと複数の静的バーチャルマシーンから選択された候補バーチャルマシーンのMACアドレスとの間のマッチングを実行し、前記候補バーチャルマシーンの前記MACアドレスが前記新たなオンラインバーチャルマシーンのMACアドレスと同じであるとき、前記候補バーチャルマシーンが前記新たなオンラインバーチャルマシーンであると判定し、前記第1のエッジスイッチを前記候補バーチャルマシーンにバインドするステップと、
前記新たなオンラインバーチャルマシーンのIPアドレスが共有IPアドレスであるか特定するステップと、
前記新たなオンラインバーチャルマシーンのIPアドレスが前記共有IPアドレスである場合、前記共有IPアドレスに対応するサービスクラスタに前記新たなオンラインバーチャルマシーンを配置するステップと、
を実行するため、前記メモリに記憶される実行可能な命令を実行する計算デバイス。
【請求項20】
コンピュータによって実行されると、
第1のエッジスイッチによって送信されるバーチャルマシーンゴーオンラインイベントを取得するステップであって、前記第1のエッジスイッチは新たなオンラインバーチャルマシーンによってアクセスされるエッジスイッチである、取得するステップと、
前記新たなオンラインバーチャルマシーンのMACアドレスを取得し、前記新たなオンラインバーチャルマシーンのMACアドレスと複数の静的バーチャルマシーンから選択された候補バーチャルマシーンのMACアドレスとの間のマッチングを実行し、前記候補バーチャルマシーンの前記MACアドレスが前記新たなオンラインバーチャルマシーンのMACアドレスと同じであるとき、前記候補バーチャルマシーンが前記新たなオンラインバーチャルマシーンであると判定し、前記第1のエッジスイッチを前記候補バーチャルマシーンにバインドするステップと、
前記新たなオンラインバーチャルマシーンのIPアドレスが共有IPアドレスであるか特定するステップと、
前記新たなオンラインバーチャルマシーンのIPアドレスが前記共有IPアドレスである場合、前記共有IPアドレスに対応するサービスクラスタに前記新たなオンラインバーチャルマシーンを配置するステップと、
を前記コンピュータに実行させる命令を有するコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、IT技術に関し、特にソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法に関する。
【背景技術】
【0002】
一般に、3つのクラウド配置モデル、パブリッククラウド(Public Cloud、別の組織又は個人の計算リソースへの手頃な価格での迅速なアクセスを提供するため、いくつかの企業によって所有及び運営される)、プライベートクラウド(Private Cloud、単一の企業又は個人によって所有される)、及びハイブリッドクラウド(Hybrid Cloud、プライベートクラウドに基づき、戦略的レベルでパブリッククラウドサービスと組み合わされる)がある。バーチャルプライベートクラウド(Virtual Private Cloud、VPC)は、パブリッククラウドによって提供される共有計算リソースに基づき確立される動的コンフィギュレーションプールである。パブリッククラウドにおけるVPCは互いに分離され、VPCにおけるテナントはオンデマンドで様々なバーチャル化されたリソースを申請しうる。テナントは、パブリックIPアドレスを用いることによってVPCをパブリックネットワークに直接接続してもよいし、あるいは、バーチャルプライベートネットワーク(Virtual Private Cloud, VPN)を用いることによってVPCを従来のDC(Data Center、DC)に接続してもよい。
【0003】
ソフトウェアディファインドネットワーキング(Software Defined Networking, SDN)は、米国のスタンフォード大学におけるClean Slate研究グループによって提唱されたネットワーク設計概念であり、ソフトウェアディファインドネットワークの核心のアイデアは、ネットワークデバイスのデータプレーンから制御プレーンを分離し、ネットワーク制御権を集中化し、オープンプログラマブルインタフェースを提供することである。SDNコントローラは、リソースバーチャル化を実現するため、周知のOpenFlowプロトコルなどの標準的なサウスバウンドインタフェースを用いることによってボトムレイヤ物理転送デバイス間の相違を遮蔽し、上位レイヤサービスがネットワークコンフィギュレーションを実行し、オンデマンドでネットワークリソースを呼び出すための柔軟なノースバウンドインタフェースを提供する。
【0004】
SDN技術及びバーチャル化技術を用いることによって確立されるデータセンタは、ソフトウェアディファインドデータセンタ(Softwares Defined Data Center、SDDC)として参照され、このようなデータセンタのネットワークは、ソフトウェアディファインドデータセンタネットワーク(Software Defined Data Center Network、SDDCN)である。
【0005】
従来のデータセンタでは、複数の等価なサーバが、ユーザに効率的、信頼できる、安全な安定的なサービスを提供するため、サービスを提供しうる1つのサーバクラスタを形成する。サーバクラスタは、ロードバランシング技術を用いることによって、全てのサーバの間でサービストラフィックを均等に共有し、サーバクラスタにおける全てのサーバの間でロードバランシングを実現するため、サーバクラスタにおけるサーバに等しくリクエストを割り当てる。現在のソフトウェアディファインドデータセンタSDDCでは、ロードバランサが、既存の技術を用いることによってSDDCNにおいて確立されてもよく、ロードバランサは、サーバクラスタにおけるサービングノードにタスクを割り当てる。しかしながら、SDDCにおけるテナントがVPCにおいてロードバランサ(例えば、バーチャルマシーンが実装のため用いられる)クラスタ及びサービスクラスタを柔軟に設定可能であるという特徴は、この解決策においては考慮されておらず、それによって、複雑で柔軟性のないコンフィギュレーションを生じさせる。
【発明の概要】
【0006】
本発明の実施例は、柔軟性があって、クラウド環境により適したサービスクラスタ管理モードを提供するため、ソフトウェアディファインドデータセンタにおけるサービスクラスタのためであるソフトウェアディファインドデータセンタ及び配置方法、スケジューリング方法、ヘルスチェック方法及びトラフィックモニタリング方法を提供する。
【0007】
第1の態様によると、本出願は、ソフトウェアディファインドデータセンタにおけるサービスクラスタのための配置方法を提供し、ここで、サービスクラスタは同じサービスを提供する複数のサービングノードを含み、本実施例では、サービングノードはオンラインバーチャルマシーンを用いることによって実現される。ソフトウェアディファインドデータセンタはSDNコントローラ及び複数のエッジスイッチを含み、ここで、複数のエッジスイッチはSDNコントローラに通信可能に接続される。複数の静的バーチャルマシーンはソフトウェアディファインドデータセンタにおいて定義され(例えば、バーチャルマシーンは、静的コンフィギュレーション情報によって設定されるが、オフラインである)、各静的バーチャルマシーンはIPアドレス及びMACアドレスによって設定される。同じサービスクラスタに属する静的バーチャルマシーンのIPアドレスは共有IPアドレスとして設定される。具体的には、配置方法は、
SDNコントローラが、新たなオンラインバーチャルマシーンによってアクセスされたエッジスイッチによって送信されるバーチャルマシーンゴーオンラインイベントを取得し、新たなオンラインバーチャルマシーンのMACアドレスを取得し、新たなオンラインバーチャルマシーンのMACアドレスと複数の静的バーチャルマシーンから選択された候補バーチャルマシーンのIPアドレスとの間のマッチングを実行し、候補バーチャルマシーンのMACアドレスが新たなオンラインバーチャルマシーンのMACアドレスと同じであるとき、候補バーチャルマシーンが新たなオンラインバーチャルマシーンであると判定し、第1のエッジスイッチを候補バーチャルマシーンにバインドするステップと、SDNコントローラが、新たなオンラインバーチャルマシーンのIPアドレスが共有IPアドレスであるか特定し、新たなオンラインバーチャルマシーンのIPアドレスが共有IPアドレスである場合、共有IPアドレスに対応するサービスクラスタに新たなオンラインバーチャルマシーンを配置するステップとを含む。
【0008】
上記の配置方法によると、SDNコントローラは、集中化された方式でサービスクラスタを管理する。SDNコントローラは、共有IPアドレスを用いることによってサービスクラスタを管理し、バーチャルマシーンがオンラインを取得すると、新たなオンラインバーチャルマシーンを自動的に特定可能であり、新たなオンラインバーチャルマシーンが属するサービスクラスタの自動特定及び新たなオンラインバーチャルマシーンの自動特定に基づき、サービスクラスタの容量を拡張するか、あるいは、サービスクラスタを生成し、これにより、サービスクラスタの配置方法は柔軟的であり、テナントからの手動の介入が必要とされず、テナント経験は良好である。
【0009】
第1の態様の1つの実現方式では、SDNコントローラが、新たなオンラインバーチャルマシーンのMACアドレスを取得する前に、当該方法は更に、SDNコントローラが、複数の静的バーチャルマシーンから候補バーチャルマシーンを選択するステップと、対応して、SDNコントローラが、候補バーチャルマシーンのゲートウェイをシミュレートすることによって、特定リクエストメッセージを新たなオンラインバーチャルマシーンに送信するステップであって、特定リクエストメッセージは、新たなオンラインバーチャルマシーンのMACアドレスを報告するよう新たなオンラインバーチャルマシーンに指示するのに用いられる、送信するステップと、SDNコントローラが、特定リクエストのものであって、新たなオンラインバーチャルマシーンによって送信されるレスポンスメッセージを受信し、特定リクエストのレスポンスメッセージにおいて搬送される新たなオンラインバーチャルマシーンのMACアドレスを取得するステップとを含む。
【0010】
好ましくは、特定リクエストメッセージは、アドレス解決プロトコルARPリクエストパケットであり、特定リクエストのレスポンスメッセージは、ARPレスポンスパケットであり、ARPリクエストパケットのARPパケット部分におけるデスティネーションMACアドレスは、特別なフィールドで埋め込まれ、ここで、特別なフィールドは、デスティネーションMACアドレスが応答側によって埋め込まれるべきであることを示す。
【0011】
第1の態様の他の実現方式では、SDNコントローラが、新たなオンラインバーチャルマシーンによって送信され、第1のエッジスイッチによって転送される特定リクエストメッセージを受信し、特定リクエストメッセージにおいて搬送される新たなオンラインバーチャルマシーンのMACアドレスを取得する。
【0012】
SDNコントローラが、新たなオンラインバーチャルマシーンをアクティブに特定するか、あるいは、新たなオンラインバーチャルマシーンをパッシブにキャプチャすることによって、新たなオンラインバーチャルマシーンの特定を実現し、これは、サービスクラスタの柔軟な配置のための必要条件である。
【0013】
第1の態様の他の実現方式では、SDNコントローラが、共有IPアドレスに対応するサービスクラスタに新たなオンラインバーチャルマシーンを配置する前に、当該方法は更に、サービスクラスタが生成されているか確認し、サービスクラスタが生成されていない場合、共有IPアドレスを識別子として用いることによってサービスクラスタを生成するステップを含む。
【0014】
第1の態様の他の実現方式では、SDNコントローラが、サービスクラスタに含まれる何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定し、何れかのオンラインバーチャルマシーンのIPアドレスが無効であると判定すると、無効なアドレスを有するオンラインバーチャルマシーンをサービスクラスタから削除する。
【0015】
好ましくは、SDNコントローラが、サービスクラスタのヘルスチェックを開始し、ヘルスチェックの結果に従って、サービスクラスタにおける何れかのオンラインバーチャルマシーンのIPアドレスが無効であるか判定する。
【0016】
上記の実現形態に基づき、SDNコントローラは、サービスクラスタにおけるバーチャルマシーンの状態を時間内に知り、バーチャルマシーンの状態に従ってサービスクラスタの容量を低減し、これにより、サービスクラスタの処理対象のサービスは、問題が発生するサービングノードに配信されず、それによって、サービスクラスタのサービス処理の効率性を確保する。
【0017】
好ましくは、第1の態様は更に、SDNコントローラがサービスクラスタのヘルスチェックを実行する3つの方式を提供し、
SDNコントローラが、少なくとも1つのエッジスイッチによって送信されるポート状態イベントを受信し、インタフェース状態が異常であるポートに対応するオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、ポート状態イベントに従ってインタフェース状態が異常であるポートを判定するステップ、又は、
SDNコントローラが、サービスクラスタにおけるオンラインバーチャルマシーンにリンク状態検出リクエストを周期的に送信し、レスポンスメッセージタイムアウトに遭遇したオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、リンク状態検出リクエストのものであって、サービスクラスタにおけるオンラインバーチャルマシーンによって返されるレスポンスメッセージが所定の時間内に受信されるか監視するステップ、又は、
SDNコントローラが、経時転送フローテーブルに対応するオンラインバーチャルマシーンのIPアドレスが無効であると判定するため、少なくとも1つのエッジスイッチによって送信される経時転送フローテーブルイベントを受信するステップ、
を含む。
【0018】
上記の解決策によると、SDNコントローラは、サービスクラスタの状態を時間内に正確に知るため、サービスクラスタのヘルスチェックを実行する。
【0019】
第2の態様によると、本出願は、ソフトウェアディファインドデータセンタを提供し、ここで、ソフトウェアディファインドデータセンタはSDNコントローラ及び複数のエッジスイッチを含み、複数のエッジスイッチはSDNコントローラに通信可能に接続され、複数の静的バーチャルマシーンはソフトウェアディファインドデータセンタにおいて定義され、各静的バーチャルマシーンはIPアドレス及び媒体アクセス制御MACアドレスによって設定され、同じサービスクラスタに属し、複数の静的バーチャルマシーンにある静的バーチャルマシーンのIPアドレスは共有IPアドレスとして設定され、
複数のエッジスイッチは、SDNコントローラからパケット転送情報をリクエストし、SDNコントローラによって配信される転送フローテーブルに従ってパケットを転送するよう構成され、
共有IPアドレスにより設定されるバーチャルマシーンは、ソフトウェアディファインドデータセンタにおけるネットワークにアクセスした後、オンラインバーチャルマシーンとして共有IPアドレスに対応するサービスクラスタを加えるよう構成され、
SDNコントローラは、第1の態様に従ってサービスクラスタのための配置方法を実現するよう構成される。
【0020】
第3の態様によると、本出願は、プロセッサ、メモリ、バス及び通信インタフェースを有する計算デバイスを提供し、ここで、
メモリは実行可能な命令を記憶するよう構成され、プロセッサ及びメモリはバスを用いることによって接続され、計算デバイスが実行されると、プロセッサは、当該装置が第1の態様に従ってサービスクラスタのための配置方法を実行するように、メモリに記憶される実行可能な命令を実行する。
【0021】
対応して、本実施例は更に、サービスクラスタの配置、スケジューリング又はトラフィック監視方法の何れか1つをコンピュータが実行することを可能にするコンピュータ実行可能命令を記憶するよう構成される対応するコンピュータ可読媒体を提供する。
【0022】
本出願によると、LBerとして、SDNコントローラは、制御レイヤでSDNの動的な拡張容量を再利用し、ネットワーク転送レイヤでSDNネットワークのネットワークリソースを再利用してもよく、これは容易且つ低コストで実現可能であり、このとき、SDNコントローラは、共有IPアドレスを用いることによってクラスタを管理し、SDNコントローラは、サービスクラスタの生成、容量拡張、容量低減及び削除を自動的に完了させ、これにより、テナントからの手動の介入は必要とされず、テナント経験が良好である。
【図面の簡単な説明】
【0023】
本発明の実施例における技術的解決策をより明確に説明するため、以下は、実施例を説明するのに必要とされる添付図面を簡単に説明する。明らかに、以下の説明における添付図面は本発明のいくつかの実施例を示し、当業者は、創作的な努力なく、これらの添付図面から他の図面を依然として導出してもよい。
図1図1は、本発明の実施例によるソフトウェアディファインドデータセンタの概略的な構成図である。
図2図2は、本発明の実施例による他のソフトウェアディファインドデータセンタの概略的な構成図である。
図3図3は、本発明の実施例による新たなオンラインバーチャルマシーンを特定する概略的なフローチャートである。
図4図4は、本発明の実施例によるARPパケットのフォーマット構成の概略図である。
図5図5は、本発明の実施例によるサービスクラスタトラフィック分布の概略的なフローチャートである。
図6図6は、本発明の実施例による汎用計算デバイスの概略的な構成図である。
【発明を実施するための形態】
【0024】
以下は、本発明の実施例における添付図面を参照して本発明の実施例における技術的解決策を明確且つ完全に説明する。明らかに、説明される実施例は、本発明の実施例の全てでなくいくつかである。創作的な努力なく本発明の実施例に基づき当業者によって取得される他の全ての実施例は、本発明の保護範囲内に属する。
【0025】
本発明の詳細な説明の簡単化のため、本発明に関係する概念がまず以下に説明される。
【0026】
テナントネットワーク:SDDCにおけるテナントによって確立されるネットワーク。一般に、テナントネットワークはVPCに対応している。
【0027】
サービスクラスタ:ユーザに同じサービスを提供するサービングノードから構成されるクラスタ。
【0028】
サービングノード及びバーチャルマシーン:サービングノードはサービスクラスタにおけるサービスを提供するノードを参照し、バーチャルマシーンはクラウド環境におけるバーチャル化によって取得されるノードである。本発明の実施例は、サービングノードはバーチャルマシーンを用いることによって実現され、SDDCにおける全てのバーチャルマシーンがサービングノードを実現するため構成されるとは限らない。他のサービスを実行するバーチャルマシーンがあってもよい。
【0029】
静的バーチャルマシーン:クラウド管理プラットフォームによって静的コンフィギュレーション情報により設定されたバーチャルマシーン。バーチャルマシーンはオンラインで進まず、すなわち、バーチャルマシーンはエッジスイッチに接続されない。
【0030】
オンラインバーチャルマシーン:バーチャルマシーンのアクティブ化された状態を表す。オンラインバーチャルマシーンは、処理を実行し、他の関連するデバイスと通信できる。
【0031】
バーチャルマシーンゴーオンライン:バーチャルマシーンがアクティブ化された状態に入ると行われる関連するアクション又はイベントを表す。
【0032】
共有IPアドレス:同じサービスクラスタに属するサービングノードは、共有IPアドレスとして設定される。共有IPアドレスは、同じIPアドレスであってもよいし、あるいは、いくつかの異なるIPアドレスのセットであってもよい。IPアドレスのセットは、サービスクラスタにおけるサービングノードによって共有される。例えば、サービスクラスタにおける全てのサービングノードのIPアドレスはIP1として設定され、IP1は共有IPアドレスである。他の具体例について、サービスクラスタにおける共有IPアドレスはIP1及びIP2であり、サービスクラスタにおけるサービングノードのIPアドレスは、IP1又はIP2の何れかとして設定されてもよい。
【0033】
図1は、本発明において例示されるクラウドデータセンタの構成図である。図1において、インフラストラクチャレイヤ1は、計算デバイス、ストレージデバイス、物理的スイッチングデバイスなどのクラウドデータセンタを構成するハードウェア施設及び構成要素を含む。ハードウェア施設は、単一のタイプの専用デバイスであってもよいし、あるいは、計算、記憶及びスイッチングを統合する統合デバイスであってもよい。インフラストラクチャレイヤ1における物理的スイッチングデバイスは、指定されたアーキテクチャに従ってネットワークを形成し、ネットワークコアエリアを形成する。バーチャルスイッチは、ネットワークコアエリアにおいてバーチャル化されてもよい。バーチャルスイッチは、ネットワークコアエリアを越えてネットワークエッジエリアを形成する。コアエリア及びエッジエリアにおけるスイッチングデバイスは、SDDCインフラストラクチャネットワークを結合的に構成するよう相互接続される。インフラストラクチャレイヤ1におけるリソースは、バーチャル化レイヤ2によってバーチャル化された後、バーチャルマシーン(Virtual Machine、バーチャルマシーン)を導出してもよい。バーチャルマシーンは、ネットワークにアクセスするため、バーチャルスイッチにアクセスする。図1に示されるように、バーチャルマシーン61、バーチャルマシーン62、バーチャルマシーン71、バーチャルマシーン72及びバーチャルマシーン73はバーチャルマシーンであり、エッジスイッチ51、52、53、54及び55はバーチャルスイッチである。
【0034】
バーチャルスイッチは、SDDCNネットワークを形成する。SDDCNネットワークはSDNネットワークであり、SDNコントローラ30を含む。エッジスイッチ51〜55は、SDNコントローラ30の指示に従ってパケットを交換する。SDNコントローラ30は更に、図1におけるテナントネットワーク31及びテナントネットワーク32などのネットワークインフラストラクチャのセット上で複数のテナントネットワーク(又はVPCとして参照されてもよい)をカスタマイズしてもよい。全てのテナントネットワークは、互いに論理的に隔離される。各テナントは、バーチャルマシーンを配置し、アプリケーションソフトウェアをインストールし、排他的なテナントネットワークにおけるユーザにサービスを公開することが可能とされる。可用性及びパフォーマンスを考慮すると、テナントは更に、サービスに対してマルチポイント配置を実行し、サービスクラスタを構築することが可能とされ、全てのサービングノードは、外部に対して同質なサービスを提供する。図1に示されるように、テナントネットワーク31は、サービスクラスタ7を定義する。SDDCネットワークはまた、図1における外部ネットワーク4などの外部ネットワークと相互動作しうる。ユーザ63は、外部ネットワーク4を用いることによってSDDCにおけるユーザ又はサービスに接続する。
【0035】
クラウド環境では、LBロードバランサ(Load Balancer、LBer)のキャリアがバーチャルマシーンである。各バーチャルマシーンのモノマー性能は限定される。テナントネットワークVPCにおけるロードバランシングのスケジューリング能力を確保し、サービスクラスタにおける線形増加の要求を満たすため、一般に複数のバーチャルマシーンが、LBerクラスタを構築するのに用いられる必要がある。継続的に調整されたLBerクラスタについて、LBer間の同期の一貫性及び適時性は、サービスのゴーオンラインレートに影響を与えうる。他方、クラウド環境におけるサービスクラスタコンフィギュレーションは柔軟的である。テナントは、いつでもサービスクラスタを柔軟に設定してもよく、容量拡張及び容量低減は比較的頻繁である。サービスクラスタの確立、容量拡張、容量低減及び削除は、テナントの手作業による介入を必要とし、柔軟性が不良である。
【0036】
上記の問題を解決するため、本発明の本実施例は、図1におけるSDNコントローラ30などのSDNコントローラが、LBerのスケジューリング及び判定機能を実現するのに用いられ、SDNコントローラが、同じサービスクラスタにおけるサービングノードの同じIPアドレス又は共有IPアドレスに従ってサービスクラスタに対して自動化された管理を実行するという技術的解決策を提供する。第1に、本発明の本実施例では、LBer又はLBerクラスタは別々には確立されず、SDNコントローラは、LBerのスケジューリング及び判定機能を実現するのに用いられる。第2に、サービスクラスタにおける全てのノードが共有IPアドレスとして設定される。SDNコントローラは、テナントネットワークにおけるIPアドレス競合をキャプチャし、共有IPアドレスを特定し、共有IPアドレスに基づきサービスクラスタを管理し、媒体アクセス制御(Media Access Control、MAC)アドレスを用いることによってサービスクラスタにおける異なるサービングノードを区別する。さらに、SDNコントローラは、サービングノードLBの原理に従い、ユーザトラフィックを指定されたサービングノードに向けるようスイッチに指示するため、パケット転送フローテーブルをカスタマイズする。スイッチは、SDNコントローラによって配信された転送フローテーブルを受信し、転送フローテーブルの指示に従ってトラフィックを配信する。
【0037】
SDDCNネットワークのコアとして、SDNコントローラは、比較的強力な能力によって構成される。本発明の本実施例では、SDNコントローラは、LBerのスケジューリング及び判定機能を実現するのに用いられる。SDNの動的な拡張能力は制御レイヤにおいて多重化されてもよく、SDNネットワークのネットワークリソースはネットワーク転送レイヤにおいて多重化されてもよい。実装の複雑さが低く、投資コストが低い。さらに、SDNコントローラは、共有IPアドレスを用いることによってクラスタを管理し、SDNコントローラは、テナントの手動の介入を必要とすることなく、サービスクラスタの確立、容量拡張、容量低減及び削除を自動的に完了し、テナント経験は良好である。さらに、SDNコントローラはLBerとして用いられ、それによって、ユーザトラフィックは常にLBerにルーティングされ、その後に別のLBerが用いられるときにサービングノードに転送又はリルーティングされるため、長い転送経路及び低い転送効率の従来技術の問題を回避する。ユーザトラフィックは、SDNネットワークの入口におけるエッジスイッチ上で分散され、SDNコントローラは最適なパスを選択する。転送経路は短く、転送効率は高い。
【0038】
以下は、具体的な実現方式を参照して本発明の本実施例における具体的な実現の詳細を詳細に説明する。
【0039】
サービスクラスタ配置及び管理
本発明の本実施例では、SDNコントローラは、サービスクラスタの確立、容量拡張、容量低減及び削除を含むサービスクラスタを管理する。サービスクラスタ管理は更に、サービスクラスタのヘルスチェックを含んでもよい。
【0040】
図2を参照して(図1及び図2におけるテナントによって設定されるエッジスイッチ及びサービスクラスタ状態は異なり、この相違は具体的な実現形態におけるテナントコンフィギュレーション状態の多様性を表すためにのみ用いられ、図1及び図2がシステム構成及び方法の実現形態における実質的な相違を有することを表すものでない)、図2は、同じテナントによって確立されたサービスクラスタA及びサービスクラスタBを示す。サービスクラスタAの共有IPアドレスはIP0として設定され、サービスクラスタAの共有IPアドレスはIP1として設定される。テナントによって設定されたサービスクラスタAは3つのサービングノードを含み、サービングノードA1のIPアドレス及びMACアドレスはそれぞれ(IP0, MAC1)であり、サービングノードA2のIPアドレス及びMACアドレスはそれぞれ(IP0, MAC2)であり、サービングノードA3のIPアドレス及びMACアドレスはそれぞれ(IP0, MAC3)であると仮定される。サービスクラスタBは3つのサービングノードを含み、サービングノードB1のIPアドレス及びMACアドレスはそれぞれ(IP1, MAC4)であり、サービングノードB2のIPアドレス及びMACアドレスはそれぞれ(IP1, MAC5)であり、サービングノードB3のIPアドレス及びMACアドレスはそれぞれ(IP1, MAC6)である。
【0041】
SDNコントローラ30は、共有IPアドレスに従ってテナントのサービスクラスタを管理し、テナントネットワークにおける共有IPアドレスのサービスノードを特定し、共有IPアドレスのサービングノードに基づきサービスクラスタを確立し、サービスクラスタの容量を拡張し、サービスクラスタにおける各ノードのヘルス状態を定期的に検出し、ヘルスチェック結果に従ってサービスクラスタの容量を低減するか、あるいは、サービスクラスタを削除する。
【0042】
(1)サービスクラスタを構築するか、あるいは、サービスクラスタの容量を拡張する
【0043】
SDNコントローラ30は、サービングノード(バーチャルマシーンを用いるなど)をサービスクラスタに追加するか、あるいは、サービングノードに従って新しいサービスクラスタを確立する。オンラインではなく実行中であるバーチャルマシーンがサービスクラスタに追加され、バーチャルマシーンがサービスクラスタにおいてタスクを実行するよう構成されるが、バーチャルマシーンがオンラインでない場合、サービスクラスタのサービス処理が影響を受けるため、バーチャルマシーンがオンラインであって実行中であると判定される必要がある。従って、SDNコントローラ30は、バーチャルマシーンがオンラインであって実行中であると判定されると、オンラインであって実行中であるバーチャルマシーンをサービスクラスタに追加するか、あるいは、バーチャルマシーンに従って新しいサービスクラスタを確立する必要がある。本発明の本実施例では、サービングノードは、SDDCにおいてバーチャルマシーンを用いることによって実現される。ネットワークを引き継いだ後、SDNコントローラ30は、SDDCにおける各静的バーチャルマシーンの静的コンフィギュレーション情報、例えば、各静的バーチャルマシーンが属するテナント及びサブネットなどの情報、バーチャルマシーンのMACアドレス、IPアドレス及びゲートウェイなどを、クラウド管理プラットフォームから取得し得る。しかしながら、SDNコントローラ30は、各静的バーチャルマシーンの実際の実行状態を知ることはできず、静的バーチャルマシーンがテナントネットワークのエッジスイッチにアクセスしているか直接確認することはできない。本発明の本実施例は、オンラインバーチャルマシーンを特定するためSDNコントローラ30によって用いられる方法を提供する。オンラインバーチャルマシーンを特定した後、SDNコントローラ30は、サービスクラスタを確立するか、あるいは、確立されたサービスクラスタにバーチャルマシーンを追加する。具体的には、SDNコントローラ30は、新しいオンラインバーチャルマシーンのエッジスイッチによって送信されたバーチャルマシーンゴーオンラインイベントを取得する。SDNコントローラ30は、新たなオンラインバーチャルマシーンのMACアドレスを取得し、新たなオンラインバーチャルマシーンのMACアドレスと複数の静的バーチャルマシーンから選択された候補バーチャルマシーンのIPアドレスとをマッチングし、候補バーチャルマシーンのMACアドレスが新しいオンラインバーチャルマシーンのMACアドレスと一致したとき、候補バーチャルマシーンを新しいオンラインバーチャルマシーンとして判定し、新しいオンラインバーチャルマシーンのエッジスイッチを候補バーチャルマシーンにバインドする。SDNコントローラ30は更に、新しいオンラインバーチャルマシーンのIPアドレスが共有IPアドレスであるか特定し、新しいオンラインバーチャルマシーンのIPアドレスが共有IPアドレスである場合、共有IPアドレスに対応するサービスクラスタに新しいオンラインバーチャルマシーンを配置する。
【0044】
本発明の本実施例では、SDNコントローラ30は、アクティブ特定及びパッシブキャプチャリングの2つの方式のいずれかでオンラインバーチャルマシーンを特定してもよい。SDNコントローラ30によるアクティブ特定は、SDNコントローラ30が、新しいオンラインバーチャルマシーンを特定するため、バーチャルマシーンがエッジスイッチにおいて直近にオンラインになったことを知った後、新しいオンラインバーチャルマシーンに特定リクエストメッセージをアクティブに送信し、バーチャルマシーンのMACアドレスを取得する。SDNコントローラ30によるパッシブなキャプチャリングは、SDNコントローラ30が、新しいオンラインバーチャルマシーンを特定するため、新しいオンラインバーチャルマシーンのMACアドレスをチェックすることであってもよい。
【0045】
図3は、SDNコントローラ30(サービングノードが、バーチャルマシーンを用いることによって実現される)によってバーチャルマシーンをアクティブに特定する実現フローチャートである。S31.新しいオンラインバーチャルマシーンが第1のエッジスイッチに接続されると(新しいオンラインバーチャルマシーンは、現在のSDDCのテナントのため設定された複数のバーチャルマシーンのいずれか1つであり、第1のエッジスイッチは、新しいオンラインバーチャルマシーンとの接続を確立し、SDDCネットワークにおける複数のエッジスイッチのものであるエッジスイッチである)、SDNコントローラ30は、インタフェースUPイベントなどの第1のエッジスイッチによって送信されたバーチャルマシーンゴーオンラインイベントを受信する。
【0046】
S32.SDNコントローラ30は、候補バーチャルマシーンを選択する。
【0047】
第1のエッジスイッチのインタフェース報告イベントを受信した後、SDNコントローラ30は、バーチャルマシーンゴーオンラインイベントが発生したと判定し、静的コンフィギュレーション情報がSDNコントローラ30に記憶されている複数の静的に設定されたバーチャルマシーンの何れか1つが新しいオンラインバーチャルマシーンであると更に判定する必要がある。本実施例では、SDNコントローラ30はまず、静的コンフィギュレーション情報がSDNコントローラ30において記憶されている静的に設定されたバーチャルマシーンから候補バーチャルマシーンを選択する(SDNコントローラ30によって選択された候補バーチャルマシーンは候補バーチャルマシーンセットを構成し、候補バーチャルマシーンセットは1つ又は少なくとも2つの候補バーチャルマシーンを含み、本発明の本実施例は、候補バーチャルマシーンセットが1つの候補バーチャルマシーンを含んでもよい特別なシナリオを提供する)。候補バーチャルマシーンを選択する目的は、候補バーチャルマシーンが新しいオンラインバーチャルマシーンであるか検証することである。検証の正確さを確保するため、選択された候補バーチャルマシーンセットの範囲は、SDNコントローラ上の全ての静的に設定されたバーチャルマシーンであってもよい。選択された候補バーチャルマシーンは更にフィルタリングされてもよく、例えば、特定のエッジスイッチにバインドされているバーチャルマシーンは、全ての静的に設定されたバーチャルマシーンから削除される。具体的な選択方式は、SDNコントローラ30はまず、特定のエッジスイッチにバインドされていない静的に設定されたバーチャルマシーンのセットを判定し、SDNコントローラ30が新しいオンラインバーチャルマシーンに関する特定を完了するまで、判定されたセットにおける静的に設定されたバーチャルマシーンを1つずつ選択するというものである。
【0048】
S33.SDNコントローラ30は、特定リクエストメッセージを新しいオンラインバーチャルマシーンに送信するため、候補バーチャルマシーンのゲートウェイをシミュレートし、ここで、特定リクエストメッセージは、新しいオンラインバーチャルマシーンにそれのMACアドレスを報告するよう指示するのに用いられる。
【0049】
特定リクエストメッセージの1つの特定の実現方式は、アドレス解決プロトコル(Adress Resolution Protocol、ARP)リクエストを用いることである。ARPリクエストは、候補バーチャルマシーンのゲートウェイをシミュレートすることによって、SDNコントローラ30によって送信される。ARPリクエストの目的は、候補バーチャルマシーンにそれの媒体アクセス制御(MAC)アドレスを報告するよう要求することである。
【0050】
図4は、イーサネットに基づくARPパケットのフォーマット構成の概略図である。ARPデータパケットは2つの部分を含み、第1の部分はイーサネットヘッダであり、第2の部分はAPRリクエスト/レスポンス部分である。本実施例では、候補バーチャルマシーンのゲートウェイをシミュレートすることによってSDNコントローラ30によって構築されるARPリクエストパケットのイーサネットヘッダにおけるデスティネーションMACアドレスは、FF:FF:FF:FF:FF:FFによって充填され、ARPパケットがブロードキャストの形式で送信されることを表す。ARPリクエストパケットのイーサネットヘッダにおけるソースMACアドレスは、候補バーチャルマシーンのゲートウェイのMACアドレスにより充填され、ARPリクエストパケットの第1のホップが候補バーチャルマシーンのゲートウェイを介し送信されることを表す。ARPリクエストパケットのAPRリクエスト部分のソースIPアドレス及びソースMACアドレスはそれぞれ、候補バーチャルマシーンのゲートウェイのIPアドレス及びMACアドレスによって充填され、ARPリクエストパケットが候補バーチャルマシーンのゲートウェイによって生成及び送信されることを表す。ARPリクエストパケットのAPRリクエスト部分のデスティネーションIPアドレスは、候補バーチャルマシーンのIPアドレスによって充填される。ARPリクエストパケットのAPRリクエスト部分のデスティネーションMACアドレスは、00:00:00:00:00:00などの特別なフィールドによって充填され、デスティネーションMACアドレスが応答側によって充填されるべきであることを表す。
【0051】
SDNコントローラ30は、候補バーチャルマシーンセットにおける各候補バーチャルマシーンに対して1つのARPリクエストパケットを構築し、各ARPリクエストパケットは、各候補バーチャルマシーンに対応する。このステップでは、SDNコントローラは、静的に設定されるバーチャルマシーンを1つずつトラバースし、1つの候補バーチャルマシーンが決定されると、1つのARPリクエストパケットを構築し、構築されたARPリクエストパケットを送信するか、あるいは、全ての候補バーチャルマシーンが選択された後、各候補バーチャルマシーンに対してARPリクエストパケットを構築し、構築された複数のARPリクエストパケットを同時に送信してもよい。上記の2つの具体的な実現方式は、双方とも本発明の本実施例に適用可能である。
【0052】
S34.SDNコントローラ30は、新しいオンラインバーチャルマシーンによって送信された特定リクエストレスポンスメッセージを受信し、ここで、特定リクエストレスポンスメッセージは、新しいオンラインバーチャルマシーンのMACアドレスを搬送する。
【0053】
具体的には、SDNコントローラ30は、第1のエッジスイッチによって報告されたPacketInイベントを受信し、ARPレスポンスパケットを取得するため、パケットを解析する。
【0054】
S35.SDNコントローラ30は、ARPレスポンスパケットにおけるソースMACアドレスが候補バーチャルマシーンの静的コンフィギュレーション情報におけるMACアドレスと一致するか確認する。ARPレスポンスパケットにおけるソースMACアドレスが候補バーチャルマシーンの静的コンフィギュレーション情報におけるMACアドレスと一致する場合、新しいオンラインバーチャルマシーンが、SDNコントローラ30によって特定され、候補バーチャルマシーンは、ARPレスポンスを送信する新しいオンラインバーチャルマシーンとマッチングし、第1のエッジスイッチが候補バーチャルマシーンにバインドされる。
【0055】
具体的には、第1のエッジスイッチに関する情報が、決定された候補バーチャルマシーンの静的コンフィギュレーション情報に記録される。
【0056】
本実施例では、非同期モードがS33、S34及びS35において用いられてもよい。すなわち、S33において、候補バーチャルマシーンが選択された後、ARPリクエストパケットが選択された候補バーチャルマシーンについて送信され、S34において、ARPレスポンスパケットが受信された後、以前に送信されたARPリクエストレスポンスパケットが当該候補バーチャルマシーンのためのものであることは判定できず、この場合、S35において、候補バーチャルマシーンセットにおける候補バーチャルマシーンが1つずつ確認されてもよい。
【0057】
新しいオンラインサービングノードをアクティブに特定する実現方式に加えて、SDNコントローラ30は更に、パッシブキャプチャリングの方式で新しいオンラインサービングノードを特定してもよい。新しいオンラインバーチャルマシーンによって送信され、エッジスイッチによって転送される特定リクエストメッセージを受信した後、SDNコントローラ30は、新たなオンラインバーチャルマシーンを特定するため、特定リクエストメッセージによって搬送される新しいオンラインバーチャルマシーンのMACアドレスと候補バーチャルマシーンのMACアドレスとの間の整合性を検出する。新しいオンラインバーチャルマシーンによって送信される特定リクエストメッセージはまた、ARPリクエストパケット(フリーARPリクエストを含む)であってもよい。SDNコントローラ30は、受信したARPリクエストパケットに従って、新たなオンラインバーチャルマシーンとしてARPリクエストを送信したバーチャルマシーンを決定し、更にARPリクエストのソースMACと候補バーチャルマシーンの静的コンフィギュレーション情報のMACとの間の整合性を確認する。ARPリクエストのソースMACが候補バーチャルマシーンの静的コンフィギュレーション情報のMACと一致する場合、新しいオンラインバーチャルマシーンが候補バーチャルマシーンと一致すると判定され、新しいオンラインバーチャルマシーンがSDNコントローラ30によって特定され、新しいオンラインバーチャルマシーンのエッジスイッチが候補バーチャルマシーンにバインドされる。
【0058】
SDNコントローラ30が新たなオンラインバーチャルマシーンを特定した後、SDNコントローラ30は、新たなオンラインバーチャルマシーンのIPアドレスとテナントの他のバーチャルマシーンのIPアドレスとが同一であるか確認する(あるいは、新しいオンラインバーチャルマシーンのIPアドレスとサービスクラスタの所定の共有IPアドレスとが同じであるか確認する)。新しいオンラインバーチャルマシーンのIPアドレスとテナントの他のバーチャルマシーンのIPアドレスとが同じである場合、SDNコントローラ30は、新しいオンラインバーチャルマシーンのIPアドレスが確立されたサービスクラスタに対応するか確認する。新しいオンラインバーチャルマシーンのIPアドレスが確立されたサービスクラスタに対応する場合、SDNコントローラ30は、確立されたサービスクラスタに新しいオンラインバーチャルマシーンを追加する。新しいオンラインバーチャルマシーンのIPアドレスが対応する確立されたサービスクラスタを有さない場合、新しいサービスクラスタが、新しいオンラインバーチャルマシーンのIPアドレスを識別子として用いることによって確立され、新しいオンラインバーチャルマシーンが新たに確立されたサービスクラスタに配置される。SDNコントローラ30はまた、新しいオンラインバーチャルマシーンのIPアドレスとサービスクラスタの所定の共有IPアドレスとが同一であるか確認してもよい。新しいオンラインバーチャルマシーンのIPアドレスとサービスクラスタの所定の共有IPアドレスとが同じである場合、SDNコントローラ30は、共有IPアドレスに対応する確立されたサービスクラスタに新しいオンラインバーチャルマシーンを追加するか、あるいは、共有IPアドレスを識別子として用いることによって新たなサービスクラスタを確立し、新しいオンラインバーチャルマシーンを確立されたサービスクラスタに加える。
【0059】
本発明の本実施例では、SDNコントローラ30は、全てのユーザアクセストラフィックを共有するため共有IPアドレスにより設定された複数のバーチャルマシーンについてサービスクラスタを確立する。図2に示されるように、テナントネットワークは2つのサービスクラスタを有する。サービングノードA1、サービングノードA2及びサービングノードA3は、IPアドレスIP0を共有し、MACアドレスはそれぞれMAC1、MAC2及びMAC3であり、サービングノードB1、サービングノードB2及びサービングノードB3は、IPアドレスIP1を共有し、MACアドレスはそれぞれMAC4、MAC5及びMAC6である。テナントネットワークはオーバラップを許容するため、SDDCNにおいて、SDNコントローラ30は、テナントとIPとの組み合わせを用いることによって、サービスクラスタを一意的に特定してもよい。
【0060】
上記のバーチャルマシーンゴーオンラインは、新たに確立されたバーチャルマシーンが実行を開始するシナリオだけでなく、バーチャルマシーンを新たに追加するか、あるいは、IPアドレスを変更するなど、バーチャルマシーンの新しいIPアドレスを有効にするようトリガする他のシナリオもまた含む。
【0061】
(2)サービスクラスタを削除するか、あるいは、サービスクラスタの容量を低減する
【0062】
サービスクラスタは動的にスケーラブルである。SDNコントローラが、共有IPによって設定されたバーチャルマシーンがテナントネットワークにおいてオンラインになったことを検出すると、SDNコントローラは、指定されたIPアドレスに対応するサービスクラスタの容量を拡張し、SDNコントローラが、サービスクラスタの容量低減イベントが発生したことを発見すると、SDNコントローラは、サービスクラスタの容量を低減する。
【0063】
サービングノード又は他の管理ノードは、SDNコントローラ30にサービスクラスタ容量低減イベントを通知してもよく、あるいは、SDNコントローラ30は、SDNコントローラを用いることによって開始されたサービスクラスタのヘルスチェックなど、サービスクラスタ容量低減イベントをアクティブに検出及び発見してもよい。サービスクラスタ容量低減イベントは、サービングノードのIPアドレスの障害を含んでもよい。サービングノードがバーチャルマシーンを用いることによって実現されるとき、サービングノードのIPアドレスの障害は、バーチャルマシーンゴーオフライン、変更、障害又はIPアドレス削除などの何れかの条件であってもよい。
【0064】
バーチャルマシーンのIPアドレスが故障していると判定されると、SDNコントローラ30は、故障状態にあるバーチャルマシーンのIPアドレスがサービスクラスタに対応しているか確認する。故障状態にあるバーチャルマシーンのIPアドレスがサービスクラスタに対応している場合、SDNコントローラ30は、故障したバーチャルマシーンのIPアドレスに対応するサービスクラスタから故障したバーチャルマシーンを削除し、サービスクラスタの残りのサービングノードの数が1より大きいか確認する。サービスクラスタの残りのサービングノードの数が1以下である場合、IPアドレスに対応するサービスクラスタは削除される。
【0065】
(3)サービスクラスタに対するヘルスチェック
【0066】
本発明の本実施例では、SDNコントローラ30は、サーバ容量低減イベントが発生しているかアクティブに検出してもよい。例えば、SDNコントローラ30は、サービスクラスタにおけるサービングノードに対してヘルスチェックを定期的に実行し、故障しているサービングノードを適時的な方式でサービスクラスタから削除し、以降のアクセストラフィックが故障しているサービングノードに向けられないことを保証するため、ヘルス状態が要求を充足しないサービングノードの元のIPアドレスを無効にし、それによって、テナントサービスの高い可用性を確保する。本実施例では、SDNコントローラ30は、ポート状態監視、リンク状態検出又はフローテーブル監視の3つの方式の何れか1つ又は組み合わせにおいて異なるネットワークレベルからサービスクラスタにおけるサービングノードのヘルス状態を確認し、ヘルスチェック結果に従って、サービスクラスタの何れかのオンラインバーチャルマシーンのIPアドレスが故障しているか判定してもよい。
【0067】
ポート状態監視:ポート状態監視の方式は、一般にサービングノードの物理レイヤの故障を検出するのに用いられる。SDNコントローラ30は、SDDCNにおける各エッジスイッチがサービスクラスタにおける各サービングノードのインタフェース状態をリアルタイムに検出するように、管理者のリアルタイムコマンド又は静的コンフィギュレーションを用いることによって、各エッジスイッチ上にポート状態監視ロジックを設定してもよい。何れかのサービングノードのインタフェース状態が変化するとき、ポート状態(PortStatus)イベントがSDNコントローラ30に報告される。例えば、サービングノードとして用いられるバーチャルマシーンのパワーオフ、再スタート、インタフェース障害又はシャットダウンは、バーチャルマシーンのインタフェース状態をゴーオンライン(UP)からゴーオフライン(DOWN)に変更するようトリガしてもよい。SDNコントローラ30は、少なくとも1つのエッジスイッチによって送信されたポート状態イベントPortStatus(バーチャルマシーンインタフェースゴーオフラインなど)を受信し、ポート状態イベントに従って異常なインタフェース状態を有するポートを判定し、異常なインタフェース状態を有するポートに対応するオンラインバーチャルマシーンのIPアドレスが故障していると判定する。
【0068】
リンク状態検出:リンク状態検出の方式は、一般にサービングノードのリンクレイヤ障害を検出するのに用いられる。SDNコントローラ30は、サービスクラスタにおける各サービングノードのゲートウェイをシミュレートし、バーチャルマシーンのIPアドレスに従ってARPリクエストを構成するなど、リンク状態検出リクエストメッセージを定期的に構築し、構築されたARPリクエストのパケットPacketOutをバーチャルマシーンに対応するエッジスイッチに送信するのに用いられる。サービングノードがARPリクエストを受信した後に適時的な方式で応答しない場合、ARPレスポンスは失効しうる。有効期限の回数が所定の閾値を超えると、SDNコントローラ30は、期限切れのARPリクエストのデスティネーションIPアドレス(すなわち、バーチャルマシーンのIPアドレス)を故障状態としてマークする。
【0069】
フローテーブル監視:フローテーブル監視の方式は、一般にサービングノードのネットワークレイヤ及びトランスポートレイヤの障害を検出するのに用いられる。SDNコントローラ30は、ユーザのサービスリクエスト及びサービングノードのサービスレスポンスを転送するため、各エッジスイッチに転送フローテーブルを配信する。エッジスイッチは、転送フローテーブルのアイドル時間をリアルタイムで検出するとして構成される。転送フローテーブルが何れのパケットとも一致しないとき、アイドル時間は連続的に累積する。アイドル時間が経時時間までになると、エッジスイッチは、転送フローテーブルを削除し、フローテーブル削除FlowRemoved又はフローテーブル満了(Flow Expiry)イベントなど、転送フローテーブル経時イベントをSDNコントローラ30に報告する。FlowRemoved(Expiry)イベントを受信した後、SDNコントローラ30は、フローテーブル削除又はフローテーブル満了イベントに対応するバーチャルマシーンのIPアドレスを故障状態としてマークする。
【0070】
上記の3つの何れか1つでヘルスチェックを実行することによって、バーチャルマシーンのIPアドレスが故障していると判定した後、SDNコントローラ30は、サービスクラスタの削除又は容量低減の上記の処理プロセスに従って、サービスクラスタから故障しているIPアドレスを有するバーチャルマシーンを削除してもよい。
【0071】
SDNコントローラによるLBトラフィック配信の実行
SDNコントローラ30がサービスクラスタを確立するか、あるいは、サービングノードをサービスクラスタに新たに追加した後、SDNコントローラ30は、ロードバランシングの原理に従ってサービスクラスタにおけるサービングノードに対するトラフィックを分散させてもよい。図2に示されるように、ユーザ1のサービスリクエストは、ユーザ側のエッジスイッチ200を用いることによってテナントネットワークに向けられ、SDNコントローラ30によって指示された後にネットワークコアエリアを横断し、サービス側のエッジスイッチ201を用いることによってテナントネットワークから向けられ、最終的にサービスクラスタAにおけるサービングノードA1に流入する。他方、サービングノードA1のサービスレスポンスは、エッジスイッチ201を用いることによってテナントネットワークに向けられ、SDNコントローラ30によって指示された後にネットワークコアエリアを横断し、エッジスイッチ200を用いることによってテナントネットワークから向けられ、最終的にユーザ1に流入する。転送プロセス全体において、SDNコントローラ30は、エッジスイッチを制御し、エッジスイッチの転送フローテーブルをカスタマイズ及び配信し、パケットソース及びデスティネーション情報をマッチングし、転送パスをパケットにカプセル化してパケットを転送する必要がある。
【0072】
図2におけるデータセンタを参照して、図5は、ユーザトラフィック配信のフローチャートである。具体的なステップは以下のとおりである。
【0073】
S51.ユーザ1は、サービスクラスタにおけるサービングノードにサービスを提供するよう要求し、ユーザ1のサービスリクエストパケットは、ユーザ1のエッジスイッチ200に渡される。
【0074】
S52.ユーザのエッジスイッチ200は、サービスリクエストパケットを受信した後、一致した転送フローテーブルを検出せず、SDNコントローラ30にルーティング情報を配信するようリクエストするため、PacketInイベントをSDNコントローラ30に報告する。
【0075】
S53.SDNコントローラ30は、サービスリクエストパケットのパケットソース及びデスティネーション情報を解析し、サービスリクエストパケットのデスティネーションIPアドレス情報に従って、サービスリクエストパケットに対応するサービスクラスタを決定し、所定のロードバランシングポリシーに従ってサービスクラスタAにおけるサービングノードA1をターゲットサービングノードとして選択し、サービングノードA1のエッジスイッチ201とユーザ1との間の転送情報を計算し、決定された転送情報に従ってエッジスイッチ201及びエッジスイッチ200のそれぞれの転送フローテーブルを生成し、ユーザ1のエッジスイッチ200及びサービングノードA1のエッジスイッチ201にそれぞれの転送フローテーブルをそれぞれ配信する。
【0076】
SDNコントローラ30は、ユーザ1及びサービングノードA1にそれぞれ対応するそれぞれの転送フローテーブルを生成し、エッジスイッチ200及びエッジスイッチ201に転送フローテーブルをそれぞれ配信する。SDNコントローラ30は、フローテーブルを同時に配信するか、あるいは、エッジスイッチ201の転送フローテーブルをまず配信するか、あるいは、エッジスイッチ200の転送フローテーブルをまず配信してもよい。転送フローテーブルをエッジスイッチ201にまず配信することは、主としてサービングノードA1のエッジスイッチ201が、パケットが到着する前に利用可能な転送フローテーブルを有することを確実にし、サービングノードA1のエッジスイッチ201がPacketInイベントをSDNコントローラ30に報告することを防ぐことである。エンドツーエンド通信は常に相互的である。エッジスイッチ200及びエッジスイッチ201にSDNコントローラ30によって配信される転送フローテーブルは、順方向及び逆方向の2方向を含み、順方向フローテーブルは、ユーザ1のリクエストをサービングノードA1に転送することに適用可能であり、逆方向フローテーブルは、サービングノードA1のサービスレスポンスをユーザ1に転送することに適用可能である。
【0077】
S54.エッジスイッチ200は、SDNコントローラによって配信された転送フローテーブルに従って、サービングノードA1のエッジスイッチ201にサービスリクエストパケットを転送する。
【0078】
S55.サービングノードA1のエッジスイッチ201は、サービスリクエストパケットをサービングノードA1に転送する。エッジスイッチとして、サービングノードA1のエッジスイッチ201は、アクセスホストが確定している場合、パケットにおけるデスティネーションMACアドレスに従ってパケットを転送しさえすればよい。
【0079】
S56.サービングノードA1は、ユーザ1のリクエストに応答し、サービングノードA1のエッジスイッチ201にサービスレスポンスを送信する。
【0080】
S57.サービングノードA1のエッジスイッチ201は、SDNコントローラ30によって配信される転送フローテーブルに従ってサービスレスポンスを転送し、ユーザ1のエッジスイッチ200にサービスレスポンスパケットを転送する。
【0081】
S58.ユーザ1のエッジスイッチ200は、サービスレスポンスをユーザ1に転送する。ユーザ1のエッジスイッチ200は、アクセスホストが確定している場合、パケットにおけるデスティネーションMACアドレスに従ってパケットを転送しさえすればよい。
【表1】
【0082】
上記のテーブルは、ユーザ1とサービングノードA1との間のインタラクションプロセスにおける関連するエッジスイッチのためにSDNコントローラによってカスタマイズ及び配信される転送フローテーブルを列記する。ユーザ1のリクエストに対して、エッジスイッチ200は、パケットソースIP11及びデスティネーションIP0をマッチングし、エッジスイッチ200への転送経路をパケットにカプセル化し、パケットをコアネットワークの入口に送信する。IP11及びIP0が同じネットワークセグメントに属する場合、パケットのデスティネーションMACアドレスは、サービングノードA1のMACアドレスMAC1によって直接充填され、これは変わらない。IP11及びIP0が同じネットワークセグメントにない場合、パケットのデスティネーションMACアドレスは、サービングノードA1のゲートウェイMACアドレスによって充填される。エッジスイッチ201は、パケットのデスティネーションMACアドレスをサービングノードA1のMACアドレスMAC1に変更する必要がある。エッジスイッチ201は、パケットのデスティネーションMAC1に一致し、パケットをサービングノードA1に送信する。サービングノードA1のレスポンスに対して、エッジスイッチ201は、パケットのデスティネーションIP11に一致し、エッジスイッチ200への転送経路をパケットにカプセル化し、パケットをコアネットワークの入口に送信する。エッジスイッチ200は、パケットのデスティネーションMAC11に対してマッチングを実行し、パケットをユーザ1に送信する。
【0083】
ユーザ1とサービングノードA11との間のサービスリクエスト及びサービスレスポンスの以降の転送プロセスは、サービスリクエストの第1のパケット及びサービスレスポンスの第1のパケットの転送プロセスと同様である。
【0084】
上記の解決策は、SDNコントローラ30が、ロードバランシングの原理に従ってユーザの第1のパケットについてサービスノードを最初にどのように分散するかを説明する。実際のサービスでは、トラフィック配信の他のシナリオがある。サービスクラスタのサービングノードが障害に遭遇すると、SDNコントローラ30は、新しいオンラインユーザトラフィックを障害のあるサービングノードに向けることができず、障害のあるサービングノードに向けられたユーザトラフィックをサービスクラスタにおける他の正常なサービングノードにリダイレクトする必要が更にある。SDNコントローラ30は、エッジスイッチ上にあって、ユーザ及びサービングノードに対応する配信された転送フローテーブルを適時的な方式で削除し、ユーザトラフィック配信プロセスに従ってユーザトラフィックについて新たなサービングノードを再指定し、新たな転送フローテーブルを配信する必要がある。
【0085】
サービスクラスタにおけるサービングノードに対するロード監視
本発明の本実施例では、LBerとして、SDNコントローラ30は、サービングノードLB原則に従い、指定されたサービングノードにユーザトラフィックを向けるようエッジスイッチに指示するため、パケット転送フローテーブルをカスタマイズする。SDNコントローラ30は、サービスクラスタにおけるサービングノードのロードを監視し、ロード監視結果に従ってLBerのロードバランシング機能を実行し、ターゲットバーチャルマシーンを選択してもよい。ロード監視の通常の実務は、SDNコントローラ30が、各サービングノードのCPUリソース使用、メモリ使用、キャッシュ使用、ハードディスク使用、帯域幅利用の何れかのリソースの使用状況又はこれらのリソースの何れかの組み合わせを監視するなど、各サービングノードのリソース使用状況を監視してもよい。本発明の本実施例では、SDNコントローラ30によるロードバランシングを実現するため、従来技術におけるサービングノードのリソース使用状況に従ってロードバランシング決定を行うことに加えて、新たな実現方式が更に提供される。SDNコントローラ30は、サービングノードトラフィックのロードバランシング原理に基づきロードバランシングスケジューリングを実行し、エッジスイッチにトラフィックを分散するよう指示するため、対応する転送フローテーブルをカスタマイズする。
【0086】
SDNコントローラ30は、サービスクラスタにおけるオンラインバーチャルマシーンに対してリソースロード監視又はトラフィックロード監視を実行し、ロード監視結果からサービスクラスタにおける各オンラインバーチャルマシーンのリソースロード情報又はトラフィックロード情報を周期的に取得する。SDNコントローラ30は、サービスクラスタにおける各オンラインバーチャルマシーンのリソースロード情報又はトラフィックロード情報を取得した後、最小リソースロード又は最小トラフィックロードを有するバーチャルマシーンをターゲットバーチャルマシーンとして選択する。
【0087】
SDNコントローラ30は、転送フローテーブルを各エッジスイッチに配信するとき、各転送フローテーブルのトラフィックを監視するよう各エッジスイッチに指示するか、あるいは、システムは、各エッジスイッチが各転送フローテーブルのトラフィックを監視することを各エッジスイッチ上のロジックに設定してもよい。SDDCネットワークにおけるエッジスイッチは、SDNコントローラ30によって配信された転送フローテーブルに従って、ユーザのサービスリクエスト及びサービングノードのサービスレスポンスを転送し、各転送フローテーブルによって累積的に処理されるパケットの量又は長さをリアルタイムで統計的に収集する。サービングノードのエッジスイッチ上でサービングノードのサービスレスポンスによって累積的に処理されるパケットの量は、サービングノードによって応答されるユーザリクエストの量を表し、サービングノードのロードを間接的に反映する。SDNコントローラ30は、サービングノードのエッジスイッチから、エッジスイッチによって統計的に収集された各転送フローテーブルのトラフィック統計結果を周期的に収集し、サービングノードのトラフィックロードの監視を実現するため、各転送フローテーブルのトラフィック統計結果からサービスレスポンストラフィックデータをフィルタリングする。
【0088】
図2に示されるように、テナントネットワークにおけるサービスクラスタBは、1つのIPアドレスIP1を共有する3つのサービングノードB1、B2及びB3を有する。合計5人のユーザが、サービスクラスタからサービスをリクエストする。ユーザ1及びユーザ4はサービングノードB1によってサービス提供され、ユーザ2及びユーザ5はサービングノードB2によってサービス提供され、ユーザ3はサービングノードB3によってサービス提供される。各サービングノードのエッジスイッチは、サービスリクエスト及びレスポンスパケットを転送及び統計的に収集し、関連する転送フローテーブルの統計フィールドに統計データを記録する。SDNコントローラは、転送フローテーブルのトラフィック統計データ抽出リクエストを周期的又は定期的に配信し、抽出リクエストレスポンスを受信した後、サービスレスポンスによって累積的に処理されたパケットの量を取得する。過去のサンプリングデータを参照して、特定の期間においてユーザに対して指定されたサービングノードによって提供されたサービストラフィックが計算可能であり、サービングノードのロードがサービストラフィックに従って決定される。
【表2】
【0089】
SDNコントローラは、時間期間に従ってエッジスイッチ上のトラフィック統計データを収集する。テーブル2は、異なる時点における各エッジスイッチ上の異なる転送フローテーブルのサービスレスポンスに対応するトラフィック統計データを列記する。サービングノードB1は、時点T1においてユーザ1及びユーザ4のサービスレスポンスフローテーブルのためのN11及びN14個のパケットを別々に処理し、時点T2においてN11+ΔN11及びN14+ΔN14個のパケットを別々に処理する。サービングノードB2は、時点T1においてユーザ2及びユーザ5のサービスレスポンスフローテーブルのためのN22及びN25個のパケットを別々に処理し、時点T2においてN22+ΔN22及びN25+ΔN25個のパケットを別々に処理する。サービングノードB2は、時点T1においてユーザ3のサービスレスポンスフローテーブルのためのN33個のパケットを処理し、時点T2においてN33+ΔN33個のパケットを処理する。
【0090】
SDNコントローラ30は、ある時間期間における指定されたサービングノードのロードを取得するため、サンプリング期間における異なるユーザのサービスレスポンスフローテーブルについて各サービングノードによって処理されたパケットの増加量を合算する。
【表3】
【0091】
テーブル3は、SDNコントローラによって計算された期間Tにおける各サービングノードのノードロードを列記する。期間TにおけるサービングノードB1のノードロードはΔN11+ΔN14であり、期間TにおけるサービングノードB2のノードロードはΔN22+ΔN25であり、期間TにおけるサービングノードB3のノードロードはΔN33である。
【0092】
当業者は、実施例のステップの全て又は一部が、ハードウェア又は関連するハードウェアを指示するプログラムによって実現されうることを理解しうる。プログラムは、コンピュータ可読記憶媒体に記憶されてもよい。記憶媒体は、読み出し専用メモリ、磁気ディスク又は光ディスクを含んでもよい。
【0093】
本発明の本実施例におけるSDNコントローラは、ソフトウェアコンポーネント/プログラム又は特定の回路モジュールなどのハードウェアモジュールを用いることによって実現されてもよい。SDNコントローラがソフトウェアコンポーネントを用いることによって実現される場合、ソフトウェアコンポーネントは、コンピュータデバイス上で実行されてもよいし、あるいは、メディア媒体に記憶されてもよい。ソフトウェアコンポーネントをロードするコンピュータデバイス又はソフトウェアコンポーネントを記憶するメディア媒体もまた、本発明の本実施例の特定の実現形態に関する。
【0094】
図6に示される計算デバイス600は、プロセッサ602、メモリユニット604、入出力インタフェース606、通信インタフェース608、バス610及びストレージデバイス612を含む。プロセッサ602、メモリユニット604、入出力インタフェース606、通信インタフェース608及びストレージデバイス612は、バス610を用いることによって相互通信接続を実現する。
【0095】
プロセッサ602は、本発明の本実施例において提供される技術的解決策を実現するため、計算デバイス600の制御センタであり、関連するプログラムを実行するよう構成される。任意的に、プロセッサ602は、例えば、図6に示される中央処理ユニット1及び中央処理ユニット2など、1つ以上の中央処理ユニット(Central Processing Unit、CPU)を含む。任意的に、計算デバイス600は更に複数のプロセッサ602を含んでもよく、各プロセッサ602はシングルコアプロセッサ(1つのCPUを含む)又はマルチコアプロセッサ(複数のCPUを含む)であってもよい。プロセッサ602は、汎用中央処理ユニット、マイクロプロセッサを利用するか、あるいは、特定用途向け集積回路(Application Specific Integrated Circuit、ASIC)又は1つ以上の集積回路を利用してもよい。
【0096】
プロセッサ602は、バス610を用いることによって1つ以上のストレージ手段に接続されてもよい。ストレージ手段は、メモリユニット604及びストレージデバイス612を含んでもよい。ストレージデバイス612は、読み出し専用メモリ(Read Only Memory、ROM)、スタティックストレージデバイス、ダイナミックストレージデバイス又はランダムアクセスメモリ(Random Access Memory、RAM)であってもよい。メモリユニット604は、ランダムアクセスメモリであってもよい。メモリユニット604は、プロセッサ602と一体化されてもよいし、あるいは、プロセッサ602内に一体化されてもよいし、あるいは、プロセッサ602とは独立した1つ以上のストレージユニットであってもよい。
【0097】
プロセッサ602又はプロセッサ602内のCPUによって実行されるプログラムコードは、ストレージデバイス612又はメモリユニット604に記憶されてもよい。任意的に、ストレージデバイス612内に記憶されたプログラムコード(オペレーティングシステム、アプリケーションプログラム、リソース割当モジュール又は通信モジュールなど)は、プロセッサ602によって実行されるため、メモリユニット604にコピーされる。
【0098】
ストレージデバイス612は、物理ハードディスク若しくは物理ハードディスクのパーティション(スモールコンピュータシステムインタフェースメモリ又はグローバルネットワークブロックデバイスボリュームを含む)、ネットワークストレージプロトコル(ネットワークファイルシステムNFSなどのネットワーク又はクラスタファイルシステムを含む)、ファイルに基づくバーチャルストレージデバイス(バーチャルディスクミラーリング)又は論理ボリュームに基づくストレージデバイスであってもよい。ストレージデバイス612は、高速ランダムアクセスメモリ(RAM)を含んでもよく、例えば、1つ以上のディスクメモリ、フラッシュメモリ又は他の不揮発性メモリなどの不揮発性メモリを含んでもよい。いくつかの実施例では、ストレージデバイスは更に、通信インタフェース608を用いることによって通信ネットワークにアクセスするウェブディスクなど、1つ以上のプロセッサ202から分離されたリモートメモリを含んでもよく、通信ネットワークは、インターネット、イントラネット、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WLAN)、ストレージエリアネットワーク(SAN)又は上記のネットワークの組み合わせであってもよい。
【0099】
オペレーティングシステム(Darwin、RTXC、LINUX、UNIX、OS X、WINDOWS又はVxWorksなどの組み込みオペレーティングシステムなど)は、ルーチンシステムタスク(メモリ管理、記憶デバイス制御及び電力管理など)を制御及び管理し、各種ソフトウェアコンポーネントとハードウェアコンポーネントとの間の通信を実現するよう構成される各種ソフトウェアコンポーネント及び/又はドライバを含む。
【0100】
入出力インタフェース606は、入力されたデータ及び情報を受信し、処理結果などのデータを出力するよう構成される。
【0101】
通信インタフェース608は、計算デバイス600と他のデバイス又は通信ネットワークとの間の通信を実現するため、例えば、限定することなく、送受信機などの送受信装置を利用する。
【0102】
バス610は、計算デバイス600におけるコンポーネント(プロセッサ602、メモリユニット604、入出力インタフェース606、通信インタフェース608及びストレージデバイス612など)の間で情報が送信されるチャネルを含んでもよい。任意的に、バス610は、有線接続方式を利用するか、あるいは、無線通信方式を利用してもよく、本出願はそれに対して限定を設定しない。
【0103】
計算デバイス600について、プロセッサ602、メモリユニット604、入出力インタフェース606、通信インタフェース608、バス610及びストレージデバイス612のみが図6に示されていることが留意されるべきである。しかしながら、特定の実現プロセスにおいて、当業者は、計算デバイス600が更に通常処理を実現するのに必要とされる他のコンポーネントを含むことを理解すべきである。
【0104】
図6に示される計算デバイスは、本発明の実施例において提供されるサービスクラスタ配置方法、サービスクラスタスケジューリング方法、サービスクラスタヘルスチェック方法又はサービスクラスタトラフィック監視方法を実行することに適用されてもよい。
【0105】
例えば、計算デバイス600のメモリユニット604は、配置モジュールを含み、プロセッサ602は、サービスクラスタ配置方法を実現するため、配置モジュールにおけるプログラムコードを実行する。
【0106】
例えば、計算デバイス600のメモリユニット604は、スケジューリングモジュールを含み、プロセッサ602は、サービスクラスタスケジューリング方法を実現するため、配置モジュールにおけるプログラムコードを実行する。
【0107】
例えば、計算デバイス600のメモリユニット604は、ヘルスチェックモジュールを含み、プロセッサ602は、サービスクラスタヘルスチェック方法を実現するため、配置モジュールにおけるプログラムコードを実行する。
【0108】
例えば、計算デバイス600のメモリユニット604は、トラフィック監視モジュールを含み、プロセッサ602は、サービスクラスタトラフィック監視方法を実現するため、配置モジュールにおけるプログラムコードを実行する。
【0109】
配置モジュール、スケジューリングモジュール、ヘルスチェックモジュール又はトラフィック監視モジュールのいずれか1つは、1つ以上の処理命令を含んでもよく、これにより、計算デバイス600は、上記の説明に従って1つ以上の方法ステップを実行する。配置モジュール、スケジューリングモジュール、ヘルスチェックモジュール又はトラフィック監視モジュールはまた、SDNコントローラのサービスクラスタ管理機能コンポーネントなど、サービスクラスタ管理のための完全な解決策を提供するため、1つの機能モジュールに一体化されてもよい。
【0110】
上記の説明は、本発明の単なる具体例の実施例であり、本発明を限定することを意図するものではない。本発明の精神及び原理から逸脱することなく行われる何れかの修正、等価な置換及び改善は、本発明の保護範囲内に属する。
図1
図2
図3
図4
図5
図6