分散スイッチングと分散ルーティング (3)

さて、このシリーズを終わらせないと年が越せない(^_^;)ということで、vExpert Advent Calendar連続投稿中の @interto さんにも鬼振り？されちゃったりしていますが、今年最後のエントリーになるかもですがいってみましょー。

すでに何を書くつもりだったのか半ば忘れているのですが、前々回のエントリーで「オーバーレイプロトコルと集中管理を組み合わせることによって、何が可能となるのか」について書くと予告していたみたいなので、そのあたりから始めてみます…。ただ、せっかく広げるなら今年最後だし最大限の大風呂敷を！ということで、オーバーレイプロトコルに限らず、OpenFlowでもSDNでもなんでもいいんですが、様々な方式を使ったネットワークの集中管理によって、何が可能になるのか、考えてみたいと思います。風呂敷広げすぎて、もはや畳めない、というオチになりそうですし、そもそもタイトルの分散スイッチングと分散ルーティング、からすでにだいぶ乖離してしまっている気もしますが…気にしない！

なお、本エントリーではWANやオフィス／キャンパスネットワークではなく、基本的にデータセンターネットワークを対象にしております。

集中管理されたネットワークのメリットとデメリット

そもそも、なぜデータセンターのネットワークを集中管理したいのでしょうか？それは、サーバ仮想化などによってインフラを動的なリソースとして扱う様になってきたことに伴って、ネットワークもまた同じように、よりリソース的に扱いたいから、つまりは動的な変化と拡張に対応させたいから、といった感じではないでしょうか。さらには、集中管理することによって、次のステップとしての自動化がより実現しやすくなるから、ということも理由といえるかもしれません。

ネットワークの集中管理をするべきなのかどうか、その判断基準はネットワーク規模の大小、ではありません*1。どちらかといえば、メリットの大小、こそが重要なポイントです。つまり、ネットワークを集中管理することによって得られるメリットがとても大きいのであれば、小規模のネットワークであったとしても集中管理を検討すべきですし、逆にどんなに大規模なネットワークだとしても自律分散動作の方が適しているのであれば、ネットワークは集中管理に移行するべきではない、といえます。

また、集中管理＝自動化ではないことは理解しておく必要があるでしょう。前述したとおり、確かに集中管理することによって自動化へは一歩前進することができます。なぜならば、管理対象への接点が1箇所になることによって、自動化はより実現しやすくなるから、です。しかし、集中管理されたネットワークは、単にそれだけでは自動化には結びつきません。また、何でもかんでも管理しようとすることは、逆に自動化を阻害することにも繋がる場合もあり得ますので注意が必要です。たとえばOpenFlowはフロー制御を集中管理するための仕組みを作ろうとしている取り組みですが、全ての通信に対してOpenFlowによってルールを定義しようと思ったらおそらくそれは非常に困難であり、自律分散に基づくネットワークよりも大きなメリットにはなり得ない場合もあるかもしれません*2。

単に複雑性にはふたをしてしまおう、というアプローチにも注意が必要です。たとえば、物理ネットワークのトポロジーを一切意識する必要のない論理ネットワークをオーバーレイによって実現する手法はとても便利ですし、手軽に実現できる「自由にネットワークを構成する」手法ではあるのですが、この手法をネットワーク全体に広げるべきなのかどうかはよく考えてから行うべきであるといえるでしょう。たとえば、VMwareは先日、『VMware NSX Virtualization Network Design Guide』(PDF)というドキュメントを公開しましたが、このドキュメントにおいては、VMware NSXを導入するネットワークにおいては、その基板となる物理ネットワークとしてはいわゆるSpine-Leafトポロジーのフルメッシュアクティブなネットワーク(つまりはEthernet Fabric構成)を構成することが望ましいと記載されています。オーバーレイのネットワークであっても、最終的にはパフォーマンスや安定性などの性能は物理ネットワークに依存するため、(理論的にはIPリーチャビリティさえあればどんな物理ネットワークでも可、とはいえども)物理ネットワークにはボトルネックのない、フラットかつスケールするネットワークが必要とされます。

また、オーバーレイによる論理ネットワークは、仮想マシンと同様に自由に、手軽に構成・追加できるが故に、いわゆるスプロール現象ともいわれる、無秩序な増加が起きてしまう可能性がありえます。VXLANなどのオーバーレイプロトコルによって、VLAN数という制約は超えられるかもしれませんが、それでもむやみなネットワークの増加は、セキュリティ面でも問題を引き起こす可能性があるなどのため、仮想マシンの増加以上に望ましくはない状態となる可能性があり得ます。運用管理にオーバーレイネットワークを組み込むのであれば、ネットワークの追加だけではなく、管理ルール、そして不要になったネットワークの適切な削除までを含めて管理できる方法を明確にしておくべきです。

また、論理ネットワークを構成する、ということは物理ネットワークとは別の、しかし物理ネットワークの影響を受ける新たなネットワークを増やすということに他なりません。それぞれをどういうポリシーで、誰が、どのような方法で管理するのか。それぞれのトポロジーをどう把握し、トラブルシュートや影響範囲の対応は問題なく行うことが可能か、など、導入するのであれば考慮すべき事項は多くあります。

このように、気軽に新しいネットワークを構成することができるということは、大きなメリットであると同時に、デメリットにもなり得る、という点をしっかりと理解した上で集中管理されたネットワークの導入は検討されるべきです。

なぜネットワークを集中管理したいのか？

結局のところ、何のためにネットワークを集中管理したいのか、その目的がぶれないようにすることこそが重要でしょう。ネットワークの管理は、目的ではなく手段であるべきです。ビジネスのスピードに対してITインフラ提供のスピードが足を引っ張っていて、その原因がネットワークの構成や管理に時間がかかることにあるのであれば、ネットワークの管理方法について改善を検討すべきであり、その結果として集中管理する手法が適していると判断したのであれば、そこで始めて「どうやってネットワークを集中管理するか」の検討を始めるべきなのです。

ネットワークを集中管理する方法には様々な手法があります。ネットワークの集中管理、というとらえ方を、単に1箇所にControllerとなる要素を配置するという方式だけに制限せずに、複数台のデバイスから構成されるネットワークを一体化して管理するバリエーションと捉えれば、ハードウェア中心の取り組みからソフトウェア中心の取り組み、両者を組み合わせた方式、オープンソースプロジェクトからベンダーによる独自実装まで、まさに様々、です。

• 独自管理ツールによる構成管理
• 裏側では単にTelnet/SSHでネットワーク機器に接続してコマンドによる構成を投げ込んでいる類のツールを使った構成管理
• SNMPによる構成管理
• NETCONFによる構成管理
• OpenFlowによる構成管理
• onePKなどのオープンではあってもベンダー独自のAPIによる構成管理
• Cisco FabricPathやBrocade VCSなどといったTRILLベースのEthernet Fabricネットワーク
• AvayaやHuaweiなどのSPBベースのEthernet Fabricネットワーク
• Junipar QFabricなどの独自ベースのEthernet Fabricネットワーク
• Cisco Application Centric Infrastructure (ACI)によるオーバーレイプロトコルも包含したEthernet Fabricネットワーク

などなど…。

どの方式を選択するのか、選定のポイントはコストパフォーマンスやらベンダーロックイン回避やら、ユーザによって重要視するポイントは色々あるでしょうが、結局のところは最もユーザにとってもメリットが大きいと判断した方式を選択することになるでしょう。もちろん、メリットだけではなくデメリットもしっかりと確認し、妥協できない点があるのであれば、そもそも集中管理方式を選択しない、という選択肢もあるはずです。

また、点を統合するサーバ仮想化に対して、ネットワークは面を構成する要素であるため「他に影響を与える要素」です。サーバであれば物理から仮想に変わっても、影響を受けるのはそのサーバ自身と、そのサーバとの通信を行うシステムやユーザに限られますが、ネットワークは点と点をつなぎ合わせる線の集合としての面、ですのでサーバ仮想化のようには、単純に物理から引きはがす、ということは容易ではありません。合わせて、本エントリーシリーズのタイトルでもある分散スイッチングや分散ルーティングなどの技術も、整合性を確保するためには基本的には対象範囲のネットワーク全体が集中管理されているからこそ実現できる方式といえます。

ネットワークの目的は点と点を結びつけること、ですが、現在ではそこに様々な要素が複雑に介在しています。セキュリティ、パフォーマンス、暗号化、ロードバランシング、最適化、帯域制御、等々…。ネットワークの集中管理は、柔軟性や拡張性といった大きなメリットを得ることができますが、単純な「点と点を結びつける」ネットワークならまだしも、これらの様々な要素が結びついたネットワークを集中管理したいと考えるのであれば、必要としている要素はどのように組み込むことができるのか、きちんと押さえていく必要があります。置き換える手法はあるかもしれませんが、それに伴って利便性が向上するなどのメリットが生まれるのかどうかも重要な考慮点です。

究極的には、ユーザにとって、さらにはビジネスにとって価値がある、利便性が向上する、課題が解決する、それらの目的のために、メリットを提供することができるネットワークの集中管理とはどういう方式なのか。コストパフォーマンスはどの程度なのか。その方式にすることによるデメリットはどういう部分で、それは許容できたり、妥協できるものなのか。技術の進歩は日進月歩であり、今、解決できていない問題であっても、近い将来、それを解決する技術が登場するかもしれません。選択肢は数多く、どうしても決断が必要な部分はいつであっても出てくるでしょうが、軸とする目的の部分だけはぶれることのない判断が必要でしょう。

サービス化していくITリソース

ネットワークを集中管理するやり方には様々な方式があり、OpenFlowとEthernet Fabricなんかは対極にあるような気もしてしまうのですが、意外と目指している方向性は似たような感じで、使い分けというか、融合というか、次第に実用的で現実的？な仕様と実装に終着しつつあるように思えます。管理手法としても、GUIの見た目や操作性などに注目が向くのですが、CLIの使い勝手やトラブルシュート性、Scriptingのためのインターフェイスやバリエーション、そしてなんといってもAPIのオープン性など、総合的な管理性を持っていることがより重要になっていくでしょう。

ITインフラを構成する要素としては、ざっくり分類するとOS/Hypervisor、サーバ、ネットワーク、ストレージといった感じに分類できるかと思いますが、これらの中で、ネットワークはCLIに最適化されすぎていたが故に、GUIやAPIなどといった他のインターフェイスへの対応が遅れていたのかもしれません。しかし、ここ数年で急速にネットワークは集中管理への対応と合わせて、それらへの対応が急速に充実しつつあります。API制御されたネットワークがどのような使われ方をするようになるのか、その下準備が急速に進んだ2013年から、その使われ方が次第に明確になっていくであろう2014年へと、まだまだネットワークまわりは興味深い動きが続くことになるでしょう。

正直、これまでのPrivate Cloudは、Public Cloudの後追いというか、ぶっちゃけ劣化コピーのような感じがあったような気がします。しかし、ITインフラリソースを所有しない・管理しないということから得られるメリットに対して、ITインフラを所有し管理することによって得られる自身のために最適化されたITリソースのメリットはもっとあってよいと思います。

PublicにしろPrivateにしろ、ITリソースはよりサービス化することが求められるようになっていくでしょう。新しいネットワークのカタチが、どのような使われ方をされるようになっていくのか。楽しみですね。

The tomorrow's entry of vExpert Advent Calendar return to @interto .
Merry Christmas!! & A Happy New Year!!

今年も1年間、ありがとうございましした。来年も、よろしくお願いします。

*1:もちろん、人間による人海戦術ではもはやどうすることもできない超大規模環境においては、もはや考えるまでもなく自動化が必要であり、その手法としてネットワークの集中管理は使用されているわけですが。

*2:そもそもの問題点としては、エントリーできるフロー数には制限があり、大規模環境が必要とするすべてのフローをプログラマブルに制御することは事実上困難です。自律分散制御の中に、意図した制御のための処理のためにフロー制御を混ぜ込むような使い方が現実的なのかもしれません。

Cisco UCS Manager と PowerTool のちょっとしたTips

vExpert Advent CalendarもWeek3に入り、皆さんのステキなエントリーが続いていますね！今回は「分散スイッチングと分散ルーティング」のシリーズは１回お休み？して、今回は閑話休題 的なTipsエントリーをば。

Cisco UCSサーバを統合管理する機能といえばUCS Managerです。実体は Fabric InterConnect (FI) のフラッシュメモリに格納されたプログラムであり、FIに接続されたブレードサーバやラックマウントサーバ、シャーシ、各モジュール、FI自身に対する管理機能を提供しています。

UCS Managerは標準のGUIおよびCLIを提供していますが、バックエンドの処理インターフェイスはすべてXML APIとなっていますので、やろうと思えば、XML APIをダイレクトに叩いて操作することも可能ですし、UCS Managerを叩くAPIを使ってアプリケーションやフロントエンドインターフェイスを別途実装してもらうことも可能です。

Cisco自身が提供しているUCS ManagerのAPIに対するツールとしては、PowerToolと呼ばれるPowerShellのCmdletモジュールやMicrosoft SystemCenterに対するプラグインモジュールなどがあります。これらのツールは、Ciscoのウェブサイトよりダウンロード頂くことが可能です。

PowerToolは、PowerShellを通じてUCS Managerを管理できるように、.NETネームスペースとUCSが標準で持つXML APIを変換するモジュール群といえます。PowerToolをWindowsインストールして "Get-Command -Module CiscoUcsPS | Measure-Object" *1で確認してみたところ、現行の1.01リリースでは1706個のCmdletを提供しているようです。UCS Managerの標準GUIを通じてできる操作をカウントすることは難しいのですが、おおよそすべての管理機能をPowerTool経由で操作できるといってよいかと思います。

…なんて書いてきましたが、まぁそうした細かいことはおいておいて、今回のエントリーはこのPowerToolを使った、ちょっとした使い勝手に関するTipsが今回のテーマです。

UCS Managerの標準GUIでは、管理されている各サーバは下記のようにツリー表示されます。

サーバの一覧を表示すれば、各サーバの詳細情報として、モデル名や搭載CPU、メモリサイズなどの情報も確認することが可能です。

こうした情報の取得はもちろんPowerToolを使っても可能で、Get-UcsBlade Cmdletを叩けば全情報をずらっと取得することができます。
たとえば、サーバの管理情報、モデル名、CPU情報、メモリサイズを取得したいと思った場合には、Get-UcsBladeや、Get-UcsComputeBoard、Get-UcsProcessorUnitなどのCmdletを使えばいいわけですが、それらの出力からSelectで必要な情報だけ抜き出して毎回確認するとか、めんどうですよね。

そんなわけで、ちょっとした情報の確認程度であればGUIの方が便利なわけですが、人間はわがままなもので、わざわざ左側のプルダウンメニューからServerを選択して右側の画面で詳細情報を表示して確認する、という一手間ですら面倒になってくるわけです…^_^;

なので、だったら右側のツリーメニューに最小限でも必要な情報を表示してしまえばいいではないか！ということで、使える機能がユーザラベルです。

この欄に情報を入力しておくと、ツリー表示にもその情報が表示されます。よって、この欄に情報を入力しておけばOK！めでたしめでたし！で済めば楽なんですが、1台や2台ぐらいならともかく、UCS Managerで管理されているたくさんのサーバの情報を1台ずつ確認して手入力していくなんてやってられるか！という声が聞こえてきます…。

じゃ、改めてPowerToolを活用しましょう、ということで、PowerToolを使ってこのユーザラベルに必要な情報を手軽に？書き込んでみたいと思います。

各サーバのユーザラベル情報の入力は、Set-UcsBlade Cmdletの -UsrLbl オプションで設定することができます。具体的には、こんな感じですね。

Set-UcsBlade -UsrLbl "Sample Text" -Force

UCS Manager管理下のブレードサーバ全台のユーザラベルにシリアル番号の情報を入れたければ、こんな感じでしょうか。そうそう、UCS Managerへのログインなどはスクリプトに含めてありませんので、下記コマンドを実行する前に、 "Connect-UCS" Cmdletで対象のUCS Managerに接続しておくことをお忘れなく。

foreach($ucsblade in Get-UcsBlade) {
    $serial = $ucsblade.Serial
    $ucsblade | Set-UcsBlade -UsrLbl $serial -Force
}

ここまでできれば、あとはそんなに難しい話じゃありません。下記サンプルではCisco UCSって文字列をモデル名から省略するとか、CPUモデルを省略表示するためにグチャグチャやってる*2とか、メモリサイズをGB単位にするとか、いろいろ整形関係もしてありますが、それらを除けばかなりシンプルなスクリプトで実装できます。

こんな感じでPowerShellスクリプトを書いて実行すれば、この通り！

foreach($ucsblade in Get-UcsBlade) {
    $model = ($ucsblade | Get-UcsCapability).Name -replace "Cisco UCS ", ""
    $long = $ucsblade | Get-UcsComputeBoard | Get-UcsProcessorUnit -Id 1 | select -ExpandProperty Model
    if($long -match 'Intel.*?([EXL\-57]+\s*\d{4}L*\b(\sv2)?)')
    {
        $cpu = $Matches[1] -replace '- ', "-"
    }
    else
    {
        $cpu = "unknown"
    }
    $mem = $ucsblade.TotalMemory / 1KB
    $custom_label = "$model / $cpu / $mem"
    $ucsblade | Set-UcsBlade -UsrLbl $custom_label -Force
}

ふむ、できました。便利ですね！ユーザラベルはシャーシ単位とかにも記述できますので、シャーシ単位でも搭載FEXモデルとか、ラックマウントの場所とか、何か有用な情報を書いておくと、より便利かもしれません。

本エントリーは、CiscoのCommunityサイトに掲載されている "UCS Inventory Based User Labels for Servers PowerShell Script" の情報を参考にしてお送りいたしましたー。

次回は、改めて「分散スイッチングと分散ルーティング」の最終回？をお届けしたいと思います。明日からは、 @interto さんの怒濤の連載シリーズが始まります。楽しみですね！

*1:Measure-ObjectはmeasureでもOKですね。

*2:現在、UCSはIntel CPUの搭載モデルしかないからこの程度で済んでますけどね…(^_^)v

分散スイッチングと分散ルーティング (2)

vExpert Advent Calendarも2週目に突入。ちっともやり遂げられるかどうか、ネタが続くのかどうか、どちらも自信がありません！(^_^;) さーて、そんな先の不安なひとまず置いておいて、今週もいってみましょう！

そもそも、自律分散というネットワークの仕組みはよくできている

SDNやらOpenFlowやらが流行って？きて、なんだか『旧来のネットワークはもはや古くて、SDNこそが新しいネットワークだ』的な風潮がちょっとあるような気もするのですが、実際のところは今までのネットワークのままで特に困っていない場合も多いのではないでしょうか。各ネットワークデバイスが他に依存することなく「それぞれが自律的に動作」しつつも「標準化プロトコル仕様に基づいて情報交換をする」ことなどによって非常に小規模なものからインターネットのような世界規模のものまでもの「面としてのネットワーク通信を成立させている」という仕組みは、改めて考えてみると とてもよくできていると思います。管理・使用上におけるシングルポイントが存在しませんし、ルールにさえ則っていれば、誰かが全体を把握して管理する必要がない、という仕組みであったからこそ、ネットワークは成り立ってきたのです。きっと、多くのネットワークがこれからも、10年後も、これまでの方法で管理されていくことになるでしょう。

しかし唯一、自律分散よりも集中管理の方がメリットが大きくなる場合がありうるネットワークが「データセンターにおけるネットワーク」です。なぜならば、データセンターにおけるネットワークは「サーバ仮想化に追随する『柔軟性』」と「インフラ基盤をささえる『可用性』」、さらには「個別管理というよりも全体管理のための『自動化』」などのニーズと必要性が高くなる使い方も増えつつあり、これらの課題を解決するためには、自律分散よりも集中管理の方が適していることもあるからです。

では、どうやってネットワークは集中管理すればいいのでしょうか？ネットワークにおいては「つながり」の技術ですので管理ツールそのものよりも、集中管理を実現するための方法が注目を集めています。本エントリーではOpenFlowやonePKなどという方法もありますが、今回はそれらはおいておいて<(_ _)>オーバーレイプロトコル、という方法について考えていきたいと思います。

オーバーレイプロトコルをどう使うのか

オーバーレイプロトコルはその名の通り、物理ネットワーク*1への依存を断ち切って、どんなネットワークトポロジーであろうとも疎通を可能としようとするやり方です。たとえESXiホスト間のセグメントが分離していようとも、仮想スイッチ(VTEP / Virtual Tunnel End Point)間でトンネルを張ることによって論理的なL2接続を構成します。粗い言い方をしてしまえば、物理ネットワークには単純にIPレベルでの相互到達性だけを求め、それ以外はすべて論理的なオーバーレイプロトコルで集中管理を実現しよう、という方式です。

オーバーレイプロトコルは仮想スイッチにおける実装から始まり、CiscoのNexus 1000VやVMwareのvCloud Network & Security (vNS)におけるVXLAN対応や、Microsoft Hyper-V / System Center Virtual Machine Manager (SCVMM)におけるNVGRE対応、旧NiciraのOpen vSwitch拡張のSTT対応などがよく知られている実装例かと思います。しかし別にオーバーレイプロトコルは仮想スイッチのためだけの仕様ではありませんので、物理スイッチや各種物理ネットワークデバイスにおける対応も現在は各ベンダーが対応を進めています*2。

仮想スイッチでのオーバーレイプロトコル

仮想スイッチを中心としてVXLANなどのオーバーレイプロトコルを使用する場合、基本的には仮想マシンに対して「物理ネットワークに依存しない」論理ネットワークを提供することになります。メリットとしては、仮想マシンを管理する管理ツール自身を使ってサーバ仮想化とネットワーク仮想化の両方をまとめて管理できる点でしょう。インフラを構成しているサーバが全て(もしくはその大半が)仮想マシンなのであれば、管理ポイントが1箇所となり、論理的なサーバとネットワークを一元管理することが可能となります。ただし、このネットワークに物理サーバが接続したり、そもそもオーバーレイとなっていないネットワークとの接続点としては、ゲートウェイを配置してオーバーレイとアンダーレイを結びつける必要があります。少なくとも1箇所にはかならずゲートウェイとなる箇所を構成する必要があるはずです。

また、物理ネットワークに依存しないとはいえ、物理ネットワークがなくてはオーバーレイネットワークも成り立ちませんし、最終的にはオーバーレイネットワークの性能は物理ネットワークに依存することとなりますので、仮想スイッチでのオーバーレイネットワークを使用する場合であってもその下の物理ネットワークにはファブリックネットワークが推奨されます。確かに、すべてのパスがアクティブで、ネットワーク自身がその機能として冗長性や可用性を担保するファブリックネットワークは、オーバーレイネットワークに足りない部分を補完して安定した物理ネットワークを提供する構成として、最適といえるでしょう。

物理スイッチでのオーバーレイプロトコル

物理スイッチを中心としてVXLANなどのオーバーレイプロトコルを使用する場合、自身ではオーバーレイプロトコルをしゃべらない物理サーバをオーバーレイネットワークに自然に組み込むことができますが、逆に仮想スイッチの扱いについては対応が必要となります。なぜなら、仮想スイッチが存在している場合、物理スイッチがVTEPとなってしまうと仮想スイッチがあるために仮想マシンまでのステップができてしまうからです。最も単純な対応方法は、物理サーバに対しては物理スイッチが、仮想マシンに対しては仮想スイッチがVTEPとなる構成をとることですが、その場合はどのように物理スイッチと仮想スイッチの両方に対して統合的な管理を実現するか考慮する必要がありますし、VTEPに対応した仮想スイッチも合わせて用意しなければならないということになります。

ただ残念なのは、現在VXLAN対応をうたっている物理スイッチにおけるVXLAN実装のほとんどが、VXLAN-VLANゲートウェイとしての役割であることです。物理サーバをVXLANに組み込むために必要な機能ではあるのですが、物理サーバのためのVXLANオーバーレイネットワークへの出入り口としての役割だけではあまり価値を出せていない使い方であるような気がしています。また、物理スイッチにおけるVXLAN実装はブリッジング機能のみが搭載されており、分散ルーティングには対応していません。

オーバーレイプロトコルと分散スイッチング／分散ルーティング

ここまでで見てきたように、オーバーレイプロトコルは基本的に論理的にL2ネットワークを構成する技術です。オーバーレイプロトコルを使用する上で分散スイッチングは必須というわけではありませんが、実際には分散スイッチングを構成する仮想スイッチ＝Hypervisorについて、物理ネットワークへの接続構成を制限しないための仕組みがオーバーレイプロトコルであるともいえます。このように、分散スイッチングとオーバーレイプロトコルは相性が非常に良いというか、基本的には組み合わせて使う仕組み同士であるといえるでしょう。

対して、分散ルーティングは一見すると、オーバーレイネットワークによってせっかく物理ネットワークにおけるL3境界を越えてL2ネットワークを広げたのに、そこにL3境界をわざわざ持ち込む仕組みとも言えるわけですが、分散ルーティングなきオーバーレイネットワークは「論理的に分離されたオーバーレイネットワークのセグメント間で通信したい場合は、いったんどこかのゲートウェイを通じてルーティングされて折り返されてこなければならなくなる」わけで、こちらもまたオーバーレイネットワークを使用するのであれば必要な仕組みともいえるかと思います。

必要なのはオーバーレイプロトコルそのものではない

さて、ここまでオーバーレイプロトコルについて書いてきたわけですが、そもそもの原点に立ち返ってみると、ユーザにとってはオーバーレイプロトコルを使うこと自体は目的ではありません。変な言い方ですが、オーバーレイプロトコル自体に価値があるのであれば、すでに数年前にVXLANが登場した時点で、多くのユーザが飛びついていたはずです。しかし実際には、多くのユーザがすでにVXLANを使用してはいますが、データセンターにおけるネットワーク構成において主流にはまだなってはいません。冒頭に書いた通り、オーバーレイプロトコルは集中管理を実現するための手段です。オーバーレイプロトコルを仕組みとしてどう活用するか、ということが重要です。そしてさらに書けば、『オーバーレイプロトコルを活用して何をしたいのか』こそが最も重要な点といえます。

次回は、オーバーレイプロトコルと集中管理を組み合わせることによって、どんなことが可能となるのか、という点について書いてみたいと思います。はたして、次回はどうなるのでしょうか？^_^;
vExpert Advent Calendar 明日は、データセンタークイーン^_^; こと @mihiguch さんのBlog 『インフラエンジニアあるある日記』 です！

*1:オーバーレイプロトコルに対して、アンダーレイプロトコルと呼ばれたりもしますが…別に下に入ってきたというよりこちらこそが本来は元から存在していたんですけどね…。

*2:今のところ、VXLAN対応のスイッチが大多数かと思いますが。

分散スイッチングと分散ルーティング (1)

クリスマスシーズン到来ですね。vExpert Advent Calendar に参加することにしましたので、ちょっと怠け気味のこのBlogについても、一応4回以上、12月にエントリーをUpできれば…と考えております。果たして穴を開けずに乗り切る？ことができるのでしょうか(^_^;)。では、第1回の @mihochannel さんの エントリー『Fusion 6 で OSX Marvericks ゲストを立ててみた』 に続いて2日はこんな感じでまずは…。

分散ってどういうこと？

VXLANやNVGREなどのオーバーレイプロトコルが登場し、データセンターにおけるネットワークの考え方が変わってきたことに伴い、データセンターのネットワークでは分散スイッチングと分散ルーティングといった仕組みが一般化していくことになりそうです。分散スイッチングは、VMware vSphereでいえば いわゆるvDS / Nexus 1000Vで、すでに3年ぐらい前からありますのでだいぶ認知も広がっていますし、実際にご利用頂いている方も多くいらっしゃるのではないかと思います。

分散スイッチングは、下図のように実際のスイッチング処理は各Hypervisorに分散していながらも、管理的には全体が統合して論理的には1台の仮想スイッチであるかのように動作する「分散仮想スイッチ」と呼ばれる仕組みです。(分散仮想スイッチが構成された範囲内であれば)どこのHypervisorに仮想マシンが移動しても、対象の仮想マシンに紐付けられた論理ポートが変化しませんので、管理上も継続的な統計データを取得することができますし、構成としてもセキュリティや設定情報をHypervisor間で移動＆再設定などをすることなく維持することが可能です*1。

分散ルーティングは、分散仮想スイッチにおける機能をさらに拡張し、L2スイッチングに加えて、L3ルーティングまでエッジ部分で処理してしまおう、という仕組みです。分散仮想スイッチにおいては、数多くのセグメント内通信が処理されてきたわけですが、いざセグメント間で通信しようとするとルーティング処理が必要となり、分散仮想スイッチ内だけで処理を完結することができませんでした。分散ルーティングは、スイッチングのためのMACアドレステーブルだけでなく、ルーティングのためのルーティングテーブルまでエッジに提供し、いわばこれまでL2スイッチであった分散仮想スイッチをL3スイッチにグレードアップする仕組み、といってもよいかもしれません*2。

このように、分散スイッチングも分散ルーティングも、要は論理的には1台のスイッチであったり、1台のルータ／L3スイッチであったりする概念上のネットワークモジュールを、物理的・仮想的には分散されたかたちで実装する技術です。実装方式は2パターン。仮想スイッチを使った実装方式と、物理スイッチを使った実装方式です。

分散スイッチング

仮想スイッチを使ったパターンの分散スイッチは、VMware vSphereにおける分散仮想スイッチによって、概念が一般化したといえます。複数台のESXホストにまたがった仮想スイッチを論理的な1台のスイッチとして扱う仕組みです。VMware標準の分散仮想スイッチを使用することもできますし、サードパーティ製の仮想スイッチ機能を組み込むことも可能です。CiscoのNexus 1000Vは、VMwareの標準 分散仮想スイッチを置き換えるとともに、Microsoft Hyper-Vにおいても、同様に分散仮想スイッチを実現しています。今後、KVMに対してもOpen vSwitchを拡張するカタチで同様のNexus 1000Vとしての分散仮想スイッチ実装を提供する予定です。

物理スイッチを使ったパターンの分散スイッチは、要はファブリック型仮想ネットワークです。サーバからは普通のスイッチに対する接続とかわらない＝意識しませんが、スイッチ間の通信は、これまでの一般的なL2スイッチングではなく、L2ルーティングともいえる実装構成とすることにより、ブロックされる経路を持たず、かつ全ての経路を使用する完全アクティブで可用性のあるネットワークをスイッチ同士が内部的に構成します。CiscoのFabricPathや、BrocadeのVCS Fabricなどの実装がすでに提供されています。スイッチ間通信はスイッチングされずに、入口のスイッチから出口のスイッチまでEthernetフレームがルーティングされるように送られるため、概念的には複数台の物理スイッチがまるで1台の論理的なスイッチであるかのように動作します。つまり、これも一種の分散スイッチ実装といえるでしょう。

分散ルーティング

仮想スイッチを使った分散ルーティングは、VMware NSXやMidokura Midonetなどのオーバーレイ型の、いわゆる「ネットワーク仮想化」と呼ばれる技術に含まれる要素となっています。同一のHypervisor上のVM間であれば、別セグメントと扱われるネットワーク間のルーティングであっても、上位のL3スイッチまでいったんパケットを送ってルーティングしてもらうことなく、仮想マシンと接続したエッジ部分の仮想スイッチがルーティング処理してしまいます。また、他のHypervisor上のVM間のスイッチング／ルーティングであった場合には、オーバーレイのためのトンネリングプロトコルでくるんで送受信を行うことで、Hypervisor間の物理ネットワークがL2であろうとL3であろうと、違いを生じさせない＝意識させない仕組みを実装しています。分散ルーティングを実現するためには、中央で制御を行うController実装が(それ自体が分散実装だとしても)必ず必要であり、VMware NSXの場合はNSX Controllerが各HypervisorのNSX vSwitchにおける分散ルーティングを統合制御しています。また、ルータとしてネットワーク内の他の物理ルータなどとの間でOSPFやBGPなどといったダイナミックルーティングプロトコルのやりとりを行ったりするために、NSX Controllerとは別に、各セグメントのネットワークに組み込まれたカタチで、論理ルータの管理VMとして動作する仮想アプライアンスが別途必要となります。

物理スイッチを使った分散ルーティングは、CiscoのDynamic Fabric Automation (DFA)などが実装例として挙げられるでしょう。DFAもFabricPathと同様にエッジ接続を収容するスイッチ＝Leafと、網内通信を中継するスイッチ＝Spineの2段階でのメッシュネットワークを基本としますが、各LeafスイッチがDefault G/Wとしての応答を返す動作をすることにより、L3ルーティングの境界も各Leafスイッチに落とし込んでいる点が大きな違いといえます。仮想スイッチの場合と同様にDFAの場合でも分散ルーティングを実現するためには中央制御のControllerとなる要素が必要となり、その役割はDFAの場合にはDCNM (Data Center Network Manager)が担っています。

このように、分散スイッチングや分散ルーティングが普及してくると、さらなる自由度を得ることを目的としてオーバーレイプロトコルなどが検討されるようになるわけですが…次回は、分散スイッチングや分散ルーティングを「どこで」処理するかによって生じる「違い」について考えてみたいと思います。…毎度おきまりですが、たぶん。ですよ。

ところで、さっそく明日の vExpert Advent Calendar の担当者がこれを書いている時点で未決定です。誰かー！！！！(>_<)

*1:VMware vSphere標準の分散仮想スイッチを使用する場合は、構成管理機能はvCenter Serverに統合されます。Cisco Nexus 1000Vを使用する場合は、構成管理機能はvCenter Serverとは別に、VSM(Virtual Supoervisor Module)の役割を持った仮想アプライアンスが担います。ただしその場合も、API連携先はvCenterサーバとなります。

*2:仮想スイッチ自体にルーティング機能を付加するだけですので、構成的な絵としては大きな違いはありません。

あなたのネットワークにVMware NSXは必要ですか? - (3)

勢いで(3)です。...といっても、2週間ぶりですかね。(1)はこちら、(2)はこちら。なお、おきまりのお約束ですが、ここは個人ブログ。会社の見解などは含まれていませんし、情報の正確性も保証されませんのでそこのところはよろしく。

さて、(1), (2), と多分に推測や個人的な認識を元に色々と自由気ままに書いてきましたが、先々週に ipSpace.net で NSX Architecture というタイトルでWebinarがあり、さらに参加者向けにVMworld2013資料の公開も始まるなど、だいぶNSXの仕様などについて理解を深めることができましたので、(3)として書くことにします。なお、WebinarのプレゼンターはipSpaceを管理しているIvan Pepelnjakさん( @ioshints )に加え、VMwareのBrad Hedlund( @bradhedlund / Blog )さんとScott Lowe( @scott_lowe / Blog )さんでした。

まずは、やはりNSXは以下の2つがあるようです。将来的には統合される方向性であることは間違いありませんが、まずはそんなかたちでリリースされそうです。

• NSX for Multi-Hypervisor ...Nicira NVPベース
• NSX for vSphere ...Nicira NVP + vCNS

APIレベルではNicira NVPとvCNSを統合したNSX APIとなるようですが、管理性や機能についても違いがある模様。元々vCNSの機能であった、同一サブネット内Firewall機能や、L/B、NAT、VPN機能などは NSX for vSphere に限られるようです。

NSX for Multi-Hypervisorの場合、KVMおよびXenに対しては拡張されたOpen vSwitch、ESXiに対してはNSX vSwitchを使用します。これまでのNicira NVPで対応していた「拡張された」Open vSwitchに加えて、NSX ControllerはESXiのVMkernelレベルでの実装として新たにNSX vSwitchが追加されてESXiの管理にも対応することになります(おそらく標準ではなくVIBとしてインストールすることになるのでは、と思いますが…)。また、オーバーレイ方式としてはSTTおよびGREに加えて、VXLANも使用できる様になります。スイッチベンダー各社がNSX対応を表明したHardware VTEPについては、こちらのNSXのみが対応し、Hypervisor間についてはTCPセグメンテーションオフロードなどが有効なSTTが引き続き使用される仕様となる模様です。

対してNSX for vSphereの場合、だいぶvCNSからの移行／継続性が強く意識された仕様となるようです。これまでの仮想スイッチの仕様を残しながらNSXにも対応するために、VMkernelレベルでTCPスタックを2種類用意し、これまで通りの使い方と、NSX Controllerからの管理に対応した機能それぞれに対応します。分散Firewall機能および分散L3フォワーディング機能がVMkernelレベルの機能として追加されますが、こちらはNSX vSwitchを使用するのではなく、分散仮想スイッチの拡張となる模様。よって、分散仮想スイッチが使用できるESXi Editionと、vCenter Serverが必ず必要となると思われます。

NSX Controllerに対するAPIはオープンとなる予定のため、NSXを管理するCMP (Cloud Management Platform) については汎用的な対応とされていますが、基本的にはNSX for Multi-HypervisorについてはOpenStackが、NSX for vSphereについてはvCloud Director / vCloud Automation Center が主に想定されて開発が進められていると思われます。この辺りについても、VMware自身が開発をリードしVMwareフルスタックとなるvCD/vCACに対して、OpenStackの場合はNetworkモジュールであるNeutronに対するPlug-inとしての対応となることとなるため、全ての機能をOpenStackを通じて管理・制御できることにはならないかもしれません。

…今回のエントリーではあまりNSXの技術的な中身に入っていかずに、NSX for Multi-HypervisorとNSX for vSphereの違いについてフォーカスしちゃいましたね…。
そんなわけで、つづく!?のかな…

あなたのネットワークにVMware NSXは必要ですか? - (2)

(1)の続きです。

NSXにおいて、各Hypervisorに実装される論理ネットワーク機能(Kernelレベルでの機能)は分散仮想スイッチおよび分散仮想ルータの役割を担うものと思われます。マルチハイパーバイザー対応のために、NSXのオーバーレイスイッチ／ルータ機能はESXiにおいては標準のvSwitchとは分離されて実装されることになるかもしれません*1。一番シンプルに実装する方法としては、ESXに対して「Nicira NVPのためにKVMへの実装においてOpen vSwitchに施した拡張と同じもの」を既存の仮想スイッチとは別に、NSX vSwitchとして実装してしまうやり方でしょう。NSX vSwitchをVSSともVDSとも統合せずに別個の新しいネットワーク機能として実装することにより、vSphere的な管理を一切通さずにNSX Controllerから制御できることとなりますし、VSS/VDSにおけるこれまでの実装や拡張はNSXとは切り離しておくことで、「NSXを使わない構成における仮想スイッチ」であったり、「NSX管理範囲外の要素のための仮想スイッチ」であったりといった使用目的に使う場合には、これまでのやり方やノウハウ、ナレッジ、連携仕様・実装などをそのまま使うことができるからです*2。

前述の通り、どうやらNSXでは(少なくとも初期リリース時点においては)標準機能として実装されるのはまずはL2とL3まで、となると思われます(TCPポート番号などに基づくACLなどのフィルタリング機能は含まれると思いますが)。L2の分散仮想スイッチは既存のESX vSwitchおよびOpen vSwitchなどですでにある意味で実現されているわけですがオーバーレイネットワーク関連の機能が追加され、さらにはL3の分散ルータ機能が論理ネットワークに対して提供されることになります。L3分散ルータとしてのデータプレーン実装は各エッジノード上のNSX vSwitchなりOpen vSwitchの拡張なりに落とし込まれるようですが、各テナント毎に既存物理ネットワークとのダイナミックルーティング*3によるルーティングテーブルをやりとりするためのコントロールプレーンとしての役割を持った仮想アプライアンス(NSX Edge)がNSX Controllerとは別に必要となります(NSX ControllerはNSX vSwitchとは管理接続で繋がっているとしても、各テナントのネットワーク自体に疎通できるとは限らないため)。

下図はVMwareウェブサイトのブログから拝借したものですが、NSXが提供するオーバーレイネットワークに接続したVM間でのL3通信がNSX vSwitchで折り返されていることが図示されています。

また、下図では別ホスト上のVM間でのNSXによるオーバーレイネットワークを通じたL3通信が、オーバーレイの下ではL2スイッチングとして処理されていることが図示されています。

また、L4以上の機能についてもNSX自身がオプションとして？用意するFirewallやVPN、Load Balancerなどの機能も提供されることとなりそうですが、それらについてはNSX APIに対応したサードパーティ製のネットワークにも対応する予定とされており、基本的には仮想アプライアンスを使った実装形態となるでしょう(VMware標準の機能に対する管理はNSX Edgeに統合される可能性もありますが)。NSX ControllerにPlug-inのようなカタチで管理機能が付加されるのか、もしくは別途各ベンダー独自の管理ポイントとの連携となるのかはまだ明確ではありませんが、実際のL4-7処理を行う機能を持った仮想アプライアンスが各エンドノードに分散配置される構成を取るのであれば、いくら中央制御するとはいえそれらの間でどのようにL4-7の機能が整合性を持って処理されるのかは興味深いところです(各種仮想アプライアンスに対して処理を渡すルール管理はできても、実際のL4-7処理そのものは各アプライアンス側での処理となるでしょう)。また、物理アプライアンスや、分散配置されない仮想アプライアンスにも対応するようですので、そうした場合は分散制御は不要となりますが、今度はそこへのトラフィックがボトルネックとならないように注意する必要がでてきます。

下図も同じくVMwareブログからの拝借ですが(^_^;)、ここではFirewall処理についてもNSX vSwitchで処理している図となっています。しかし標準機能としてのプロトコルおよびポート番号ベースの標準Firewall機能を超える様々な実装やIDS/IPS、アンチウィルス処理など、ネットワークにおけるL4-7処理すべてをエッジ処理することはできないのではないかと思われ、どのように実装されることとなるのでしょうか。

そもそもオーバーレイである以上、オーバーレイに対応していない物理ネットワークとの接点や、物理サーバおよびオーバーレイに対応していない仮想環境との通信には、オーバーレイを解除するゲートウェイが必要となります。L2 Bridge機能のゲートウェイは複数あっても問題ないと思いますが、L3ゲートウェイは基本的には各ネットワークで1箇所となるでしょう(冗長構成にはできるでしょうけど)。また、NSXに対応する物理スイッチをL2ゲートウェイとすることで物理サーバとの接続性は確保できると思われますが、L3以上の機能を提供する物理アプライアンス・ネットワーク機器と基本的にすべてがオーバーレイであることを前提とするNSXを果たして有機的に組み合わせることができるのか、その辺りがどうなるのかはまだ私もよくわかりません。

そんなこんなで、NSXを使うことによって物理的なネットワークに依存しない論理ネットワークを構成することは確かにできるでしょうが、その上にL3-7までの様々な機能を盛り込んだネットワークを頑張って作り上げていったら、結局、物理ネットワークとはまた違った複雑性を持った新たな論理ネットワークがもう一つ出来上がっただけだった…とかなるとしたら…(^_^;)

そろそろお後がよろしいようで…。

はたして、(3)はあるのかないのか…。

*1:対して、すでに直接的に拡張を組み込んでいるOpen vSwitchを使用するKVMやXenについてはそのままの実装となるでしょう

*2:NSX機能をvSphere Clientを通じて操作するハンズオンもありましたので、「vSphere的な管理」にあえて統合する形式が選択されることになるかもしれません。NSX Managerを通してのAPI実装なんでしょうけど…マルチハイパーバイザーでの管理性を統合したいのであればちょっとどうかとも思いますが、vSphereだけで使うのであればWeb Clientへの統合は必要と判断したのかとも思います。はてさて…。

*3:BGP, OSPF, IS-ISなどに対応する模様です。

あなたのネットワークにVMware NSXは必要ですか？ - (1)

結局8月は1本もエントリー書けませんでした…。反省。

San Franciscoで8/25-29に開催されたVMworld 2013。やはり今年の目玉はVMware NSXということになりましたが、リリース予定はCY2013Q4。年内ではありますが、まだしばらくは待つ必要がありそうです。この段階で推測を多分に含んだカタチでエントリーを書くことはちょっと躊躇われるのですが、まぁ特に責任ある？企業ブログというわけでもなし、個人ブログに自由に書くなら盛り上がっているときでしょ！ということでタイトルもあえてちょっと挑発的にいってみることにします(^_^;)。

VMwareは2012年にNiciraを買収し、2013年3月にvCloud Network & SecurityとNicira NVPを統合するVMware NSXを発表、そして今回のVMworldにおいて製品としての提供開始予定時期が発表されるとともに各種ブレイクアウトセッションが行われ、さらにはβプレビューではありますがハンズオンラボなどで実際の動作を試すことができるようになりました。とはいえ、まだまだESXi側のNSX対応も開発途上なようで、NSXとひとくくりにしてはいてもNicira NVPなNSXと、Network & Securityの色を残したVMware的なNSXとではまだちょっと別物、といった感じでした。裏側の動作としてはNSXへのESXiの対応なども動作していましたので、おそらくリリースまでの数ヶ月で表側の見た目に対する開発が急ピッチで進められることになるのでしょう。そんなわけで、マルチハイパーバイザー対応をうたうVMware NSXですが、おそらく初期リリースではNicira NVPとして元々対応していたKVMとESXiへの対応というカタチとなるのではないかと個人的には推測しています。Open vSwitchを使用することが可能なXenはともかく、まだサードパーティ製のネットワーク機能の組み込みに制約の多いHyper-Vへの対応はなかなか難しいかもしれません。

さて、そんなNSX最大のメリットであり、考えようによってはデメリットでもあるとも思える点が「ネットワークの仮想化」を目的とした製品であるということ自体であると私は考えています。

全ての通信を基本的にはオーバーレイされた論理ネットワークで構成してしまおう、という考え方は OSにとっての仮想マシンと同じ様な発想に基づいています。VMware ESXはOSにとってのサーバを論理サーバ化してしまうことによって、物理的に固定化されていたサーバを動的なものとしてインフラの概念に根本的な革新をもたらしましたが、VMware NSXではこれと同じような変化をネットワークに対して実現しようとしています。

なるほど確かに、これまでのネットワーク機器は基本的には自律分散を基本としており、ダイナミックルーティングやVTPなど、仕様に基づいて相互に情報を交換することはあっても、基本的には各ノードが自律的に動作する仕組みが一般的です。この仕組みのメリットは、なんといっても中央制御されずともネットワークが成り立ち、部分的に障害が発生したとしても全体として調停する存在なく継続的に通信が維持される点です。しかし、この仕組みはエンドノードとしてのサーバが物理的に固定化されていた時代には十分に機能していたものの、過半数のサーバが仮想化された現在では、動的に変化していくサーバ群に対してより柔軟に対応するネットワークが求められており、そうした状況に対して様々な方法での対応が試みられている、というのが現在の状況といえるでしょう。そしてその試みの1つが、NSXが全面的に採用しているオーバーレイ方式のネットワークです。

L2(VLAN)/L3(Routing)の壁を超えたネットワークを実現するためにEndpoint間でのL2接続をオーバーレイによって実装する、というやり方は確かに非常に強力です。通信を必要としている動的な点と点を結びつけるために、その間のネットワーク全体を刻々と変化していく状況に追随してトポロジーを維持することはなかなか大変ですから、なのであれば通信を必要としている点を直下に持っているエンドノード同士が物理的なトポロジーに関係なくPoint to Pointでつながり合えばよい、という発想は たしかにネットワークにおける制約を乗り越えるために使うことができるやり方の1つであり、仮想環境を前提として考えるとある意味で必然ともいえる帰着点かもしれません。

しかしポイントは、オーバーレイ方式をネットワーク全体に適用することが果たして必要とされているのかどうか、という点です。会社のネットワークにはWANとLAN、有線と無線、様々なセグメントとそれらの間のFirewall、各種サーバやロードバランサ、データセンターとオフィス、さらにはサテライトオフィスやモバイルアクセスなどなど…様々な形態と要素が組み合わされています。サービスを提供する要素も、物理サーバや仮想サーバなどの汎用OS上にインストールされたソフトウェアベースのものだけではなく、各種センサーやアプライアンス製品、カメラやビデオなどのデバイス類、等々、とても多様です。オーバーレイはこれらエンドデバイス一歩手前の仮想スイッチや物理スイッチなどの段階でオーバーレイのエンドポイントを設けることで、各エンドデバイス自体でのオーバーレイ対応を不要としていますが、モバイル機器などの接続形態がLANに限定されないデバイスであったりなども多くオーバーレイ化が逆にネットワークの複雑性をもたらしてしまう場合も考えられます。また、物理的な接続ポイントはこれまでVLANであったりセグメントであったりなどの情報からロケーションを判断していたわけですが、オーバーレイによって物理的なネットワークとは別に、フラットな論理ネットワークが構成された場合にはどのように最短経路や最寄りのAD/DNSサーバ、各種キャッシュサーバなどを判断するかなどは新しい課題となるでしょう。

そもそも、オーバーレイ方式の論理ネットワークの下には必ず物理ネットワークが必要です。物理ネットワークはなくならないし、どちらかといえばオーバーレイなネットワークが上に構成されている場合には物理的にはどこにボトルネックが発生するか予測が付かなくなるが故に、基本的にはフルメッシュでActive/Activeで広帯域・低遅延なネットワークを実現するいわゆるFabric的なネットワークが必要となるでしょう。そして、それらの物理ネットワークの管理とステータスの把握は安定した通信を得るためには欠かせません。オーバーレイは完全に下回りとなるネットワークを切り離すため、上(オーバーレイネットワーク)からは下(物理ネットワーク)が、下からは上がお互いに把握できないが故に、ネットワークのトラブルシュート、特にパフォーマンスまわりについての切り分けはとても困難となることが想定されます。

まずはここまで！つづく。
なお、このシリーズは単なる批判というよりもちゃんと理解して、判断して、必要性をしっかり考えることを目的としたものですので、誤解なきよう！
...(^_^;)