hbstudy に参加してきました。
今回のお題は、さくらのクラウド。

特に、ネットワークの仮想化の設計および実装についての内容がテーマでした。

24時間以内のレポートはさすがに無理だぁ〜。てことで、2週明けにがっつりと書きましたよ〜。
Software Designが発売される前に、何とか出したかったのでがんばった！(笑）

「さくらのクラウド ネットワークの仮想化の設計と実装」 大久保氏





自己紹介を真面目にします。
2011/3/3 震災の少し前に、アマゾンが東京リージョンが開設すると言うことで、社長と石川さんがやってきて、「今からお前がクラウドの開発をやれ」と言うことでやり始まった。今で6ヶ月目ぐらいネットワークの設計と開発をやっている。



昨日、 publickeyさんより、 PR記事を書いていただきました。





さくらのクラウドでやるのは、IaaS、将来的にはSaaSもやるぞと社長は言っているが、今のところIaaSのみを考えている。



IaaSに求められることとして、CPUのコア数、メモリ、HDD、ネットワーク、割と自由に追加して、自分の作ったローカルのスイッチに接続できるといった、自由に構成が出来るのが特徴。仮想アプライアンス、データセンターにルータや、ファイアーウォール、ロードバランサーを持ち込んで、線を繋いでやっていた作業を全てクラウド上で出来るようにしましょうというのが、求められているのかなぁと思っている。




そういえば、1年ぐらい前に、社長がクラウドを作っていたが、それは、私的にはクラウドじゃない。VPSの延長じゃないかと思っていた。何故かというと、ネットワークの構成が出来ず、仮想マシンの構成の変更しか出来ない。ネットワークの構成変更が出来ず、私がプロジェクトに呼ばれたからには、色々と出来るようにしたい。



弊社では、ハウジングや専用サーバを借りて、大規模サイトを運用されるお客様が多い。1年ぐらい前から、VPSのサービスも提供させ頂いているが、色々なサービスは面倒くさいので、色々なサービスをクラウド上に乗せれるように、作りたい。



IaaS上での一般的なシステム構成。
ルータの下にファイアーウォール、ロードバランサーなどがあり、Webサーバを構築、バックエンドにDBサーバがある。
バックエンドを管理する為のVPN回線あるような構成が一般的ではないだろうか。

上記の構成を仮想化してみると、次のようになる。




IaaSネットワークの物理構成については、外部向けの回線をルータで受けてコアスイッチ2台で受けて、各ラックに設置しているエッジスイッチに分配していく。エッジスイッチは、サーバが増えれば増えるほど増設していく。

さくらでは、VLANを使って仮想マシン間を構成しており、仮想スイッチからルータまで、すべてVLANで構成されている。
VLANを使用した場合、VLAN-IDの制限があって、事前に4,000VLAN通しておく。
仮想サーバが立ち上がるたびに、仮想インターフェースをVLANに属させ、仮想ネットワークを組んでいる。



装置間の接続については、ユニークなVLANを割り当てていく。お客さんには見せていないので、気にする必要はないし、クラウドコントローラで自動で割り当てがされるようになっており、他のお客さんとかぶらないようになっている。



また、VM上のネットワークとして、仮想NICを仮想SWを経由して、VLANに接続される。



1ゾーンあたりの規模として、VLANは4,096個しか使えないので、VLANの単位でゾーンを分けている。
ホストサーバ500〜1000台ぐらい詰め込んで、VMは8000VMぐらいを想定し、1つのゾーンが構成される。
VMに仮想NICを平均2個搭載すると、MACアドレスは16,000程度必要となり、上記の用件を満たしたL2網を作らなければならない。



検討が必要な要素として、コアスイッチ、エッジスイッチ、仮想スイッチ、ルータなどをがある。



コアスイッチ、エッジスイッチの用件として、STPがよく使われるが、トラブルが多いので、さくらでは、STPは使わないということが目標であり、今ではスタック技術を積極的に使用し、冗長化している。エッジスイッチとの接続についてはLAG(リンクアグリゲーション)を使用し、スタックされた別々の装置に接続出来る構成になっている。その上に、すべてのVLANを通すような設定をしている。



コアスイッチの用件として、3,500以上のVLAN, 16,000以上MACアドレスの学習出来るスイッチを選定している。



エッジスイッチについても、L2網のため、コアスイッチとあまり変わらない。また、VLANおよびMACアドレス数が重要である。
スイッチの設定ミス等でループが起こらないようにその仮想マシンだけ切り離せるような構成にしている。



ベンダーのラボで検証したら、いろいろな問題が見つかった



ロジカルポート数の不足。カタログを見ると、4,000VLAN作れるが、すべてのポート、たとえば40ポートあるL2スイッチに、タグですべてのVLANを通す設定すると、設定できない箱が多い。ロジカルポートというのを内部で作るが、ポート数*VLAN数で4000*40で、16万ポートぐらいで、ほとんどの箱は12,000ぐらいか24,000ぐらいしかない。となると、3ポートとか6ポートしか割り当てが出来ない。選定の段階で問題がわかったので、選考から外すし、全ポートに全VLANを出すような箱を選定している。



次に、よくあるのがショートパケットでワイヤーレートが出ない。Etherフレームの最小フレーム地は64byteで、一番パケット数が多い。10Gでワイヤーレートを出すには、秒間14.88Mppsぐらいなので、結構装置にとっては、厳しい用件になってくる。
実際に満たす箱が無く、あきらめようとした。

なぜ64byteと決まっているかというと、CSMA/CD方式のコリジョン検出で、100m信号が伝わるためには、64byte出さないとコリジョンが検出出来ないため、決まった値である。128byteであれば、性能は半分でよかったのに。

考えた結果、「ワイヤーレートでなくてもいいんじゃね？」ということで、現実で問題のない範囲であればOKとしている。 具体的には80%、 DEL 98％しかでない 2%しか落とさないスイッチとか。

Q. 一番よかったスイッチのメーカーは？
A. えーっと....

Q. どこ採用されました？プレス出てました？
A. 出てましたね... ブロケードさん？



VLANは、歯抜けで使えないVLANが存在する。
BrocadeはFCoEで予約されてある1002番のVLANが使えない。
C社さんのスイッチは、1002-1006や、show vlan internal usage は、routed interfaceに割り当てられた内部VLANなどがあり、上記のVLANは使用できないように、クラウドコントローラで割り当てないように設定をしている。
そのほか、VLAN 3583までしか扱えない箱があったり。。
※ ソース： Brocade VDX AdminGuide: 3583. VLAN IDs 3584 through 4094 are internally-reserved VLAN IDs
実際に使えるVLAN数として、3500ぐらいが頭なのかなと考えている。



configが長くなる箱。非常に見にくく、メンテナンス性が悪い。



LACPがダウンする問題。ちゃんと冗長構成を取っているが、片方のコアスイッチを再起動すると、配下のエッジスイッチのLACPが一瞬ダウンして、通信が途絶えるということで、エッジスイッチのバグだったが、修正してもらって、現在は問題ない。

LACPは結構バグを踏むことがあり、Static LAGで組むのが一番良いが、KeepAliveしないので、リンクアップしたまま通信が止まるということがあり、通信ダウンがあるので、悩みどころ。今のところLACPを有効にして運用している。



MACアドレスのハッシュコリジョン問題。バグ^G^G仕様を踏むまで気づかなかった。
多くのL2スイッチのMACアドレスの学習にはハッシュテーブルを使用しており、ハッシュのコリジョンが発生する。コリジョンの発生してもよい許容量が決まっているが、それを超えると、MACアドレステーブルがすかすかなのに、学習出来ないMACアドレスが出始め、学習出来ないMACアドレスはUnknown Unicastとなり、Floodingする。さくらの場合は、Flooding系のフレームは帯域制限をかけるので、通信が遅くなるなどの悪影響が発生する可能性がある。

Q. MACアドレスをランダムにすると、MACアドレスが重複することが発生しないか？
A. コントローラですべて管理しているので、その問題は発生しないようにしている。



VLANでMACエントリを表皮する箱があり、某B社のスイッチでは、1VLAN設定すると内部で3エントリ消費してしまう。スペックでは、32,000VLANのスイッチで、4,000VLAN 作ると、12,000個のMACアドレスを消費してしまうので、残り20,000個しか使用出来ない。



先日OUI取得しました。
今では、9C-A3-BAでお客さんに割り当てている。

何で取得したかというと、Interクラウドで、他のクラウドでL2で接続しても、フレームをそのままとばしましょうという話があったり、事務所から、直接クラウドのサーバにL2-VPNで接続して直接接続してフレームをとばそうとすると、52-54-00などのKVMで使用しているMACアドレスを使用すると、お客さんが使っていると、ぶっちゃう可能性があるので、世界中でユニークなアドレスを取った方が良いよねということで、取得した。他のクラウドの相互接続性や物理ネットワークとの相互接続性などは問題無いようにしている。

Q. 本社の住所じゃないのはなぜですか？
A. (鷲北さん) 僕が、登録した。東京にいたもので、つい自分の名刺をみて、登録してしまった。

Q. 費用はどれぐらい発生するのですか？
A. 1750ドル、クレジットカードで決済出来る。
クレジットカードでOUIがとれる時代です。



仮想スイッチの用件として、次のものがあり、Open vSwitchを使用している。
スイッチでは、いろいろな用件があって、共有セグメントでは、他のお客のIPアドレスの乗っ取りが出来ないように、MAC Spoofing, ARP Spoofing, IP Spoofing の対策を行わないといけない。そのほか、仮想ポートで帯域制限が必要であり、帯域をお客さんに販売するので、契約帯域で絞るということをしている。



各ラックに設置されたエッジスイッチ(表裏)に、bondingで、冗長化するように、Open vSwitchに接続する。Open vSwitchまで、4,000VAN通して、クラウドコントローラでVMが起動するときに、tapインターフェースをOpen vSwitchに接続するときに、仮想ポートにvlanを割り当ている。仮想的なネットワークに接続することが出来る。

Q. ハイパーバイザーは？
A. KVMを使用している

Q. クラウドコントローラーは、自社開発ですか？
A. 自社開発で担当者1人で作ってる。

Q. VLANをたくさんつくるとき、どれぐらい起動に時間がかかりますか？
A. Open vSwitchはよくできていて、ポートをつなぐと、勝手に4000VLAN通る。
VLANをダイナミックに学習していて、来たフレームのVLANを自動で作り、
あらかじめVLANを作っておくという訳ではない。
4000 VLAN, 32,000 MAC通しても問題なく動くことを確認した。



Open vSwitchのMAC学習数に問題があり、デフォルトでは2,048となっていた為、ソースコードを書き換えた、32,768に書き換えて運用している。



フィルタでは、Open vSwitchはOpenFlowベースのアーキテクチャになっている。
ip, arpなどエントリを作ることでフィルタをする形になる。
src - mac , src - ip でフィルタしてる。



帯域制限。これも簡単で、tapインターフェースに指定すると、kbps単位で指定出来る。` 共有セグメントタイプであれば、100Mbps で指定している。
なお、現時点では、仮想スイッチからみて、ingress しか設定していない為、outgressは10G使えてしまう。



よくできているなとおもって、使っていたが、いくつか問題が発生した。
フローベースのアーキテクチャなので、DoSアタックなど、大量のフローが発生すると、転送性能が著しく低下する問題があった。
あるホストのVM当てにDoSアタックを食らうと、Open vSwitchを通過する他のお客さんにも影響が発生した。



カーネルモジュールのopenvswitch_modでパケットの転送処理を行っているが、いったんフローに展開するして、MAC Address, IP Address, Port番号など全部展開して、新規のフローについてはデーモンで動いているovs-vswitchdに問い合わせて、フローキャッシュとして、カーネルに保存します。なので、新しいフロー、DoSアタックみたいに、パケット単位でフローが発生すると、問い合わせが発生つづけ、ovs-vswitchdのCPUが上昇し続けた。フローキャッシュは、未使用エントリは5秒で、expireする。5秒で通信されないフローについては、いったんデーモンに問い合わせるようになる。5秒以下でも、1000エントリ超えると、削除するようになる。1,000エントリは、DoSアタックを食らうと一瞬であふれてしまう。



今の対策としては、1.2.1にバージョンアップした。
フローのセットアップ性能が50倍になり、だいぶ影響が受けにくくなった。
バージョンアップにより、ガベージコレクション開始の閾値を変更出来るようになった。
フローキャッシュの最大エントリも128kなので、12万ぐらいに設定して、多少あふれても問題ないように設定した。



根本的な解決策ではないくて、Open vSwitch自体、Flowベースなアーキテクチャなので、根本的な解決は難しそうな気がしている。今のところで、お客さんの仮想ポート毎にフロー数をモニタして、フロー数が異常になったら、帯域制限を行うよな監視システムを作ろうとしている。
あとは、Open vSwitchで仮想ポート毎に、フロー数の制限が出来るようになるとよいのかなと考えている。



ここからL3の話をします。
インターネットと接続する、エッジルータまでのネットワークで、エッジまではVLANを持ってきて、VLANインターフェースを作成し、エッジルータの2台にIPアドレスをを設定し、VRRP冗長している。

Q. LRなんですね？
A. すみません、SRにしたらやすくなったのでSRにしました。(資料の更新忘れ)

管理ドメインが違うバックボーンが増えてきて、どのようにして接続するか、というのが課題になっており、プライベートASを使用したBGP接続が一般的ではないかなとおもい、BGPで接続している。ちなみに、上のバックボーンは運用部が運用している。

これを設定した経路をそのまま上のバックボーンに経路を伝えると、クラウドコントローラーのバグなどにより、変な経路をバックボーンに流してしまったら、通信障害になるので、管理ドメインを分け、BGPで接続、プールするアドレスのみ受け入れるようにしている。



クラウドで使用するアドレス(/20など)をあらかじめプールしておき、ルータの設定で、配下のVLANに割り当てている。



ルータは、結構きびしいのがVRRPのインスタンスの数ではないかなともう。

お客さんが使うVLANにIPアドレスをたくさん割り当てていく。VRRPは、VRIDはそもそも256個しかない。全部のVLANに別のVRIDを使うことが出来ない。なので、別のVLANに同じVRIDを使える装置にしないといけないという制限がある。



実のところをいうと、ARPのエントリが厳しい結果が得られた。ルータの下に、8,000VMとか収容するので、ARPのエントリを作らないといけない。



実際にやってみると、VRRPのインスタンスを大量に作ると、VRRPの状態が変わり、フラックするという問題がある。試験したとき、2,000 VLANでIPアドレスを設定し、VRRPの設定を入れると、毎秒 2,000パケットのVRRP HELLOパケットが流れることとなり、バックアップ側が受け取れずに、勝手にマスターに昇格してしまう。

B社さんのルータで発生し、C社さんのルータでは発生する。

Q. VRRPを2000作ったとき、スレーブ側のCPU負荷はどうですか？
A. ラインカードのCPU負荷が張り付いていて、メインのCPUは大丈夫だった。



ルータ系のDDoSアタックを気にしている。 グローバルなIPアドレスがついていると、インターネット側から攻撃されてしまう。某B社さんのルータの23ポートに対して、ショートパケットをワイヤーレートで送りつけたら、CLIが固まる。
Q. マネージメントポートは使わないのか？
A. 上側のグローバルのデフォルトゲートウェイについては、隠せないので、どうしてもオープンになってしまうので、耐性だけ確認している。



配下に/16とかの大きな空間を作り、テスターで配下に12,800クライアントいるような環境で、トラフィックを流すとルータのCPU負荷が上昇し、CLIが操作出来なくなる。

Q. なぜ、ルータはB社さんを買ったのですか？なぜC社さんじゃない理由は？
A. ルータについては我々は何も申しわげていない。
B社とC社、両方買ってみた。よい方を正式サービスで使おうとした。
それで、大阪には、AゾーンとBゾーンがある。
全部試した。結局石狩では何を使うか、わかったかと思う。

てことで、Cisco採用されるそうです！！



VLAN ID数の克服として、ゾーンを分けることにしたが、お客様が、裏でゾーンをまたがる通信を接続したいという要望があることから、実装した。VLANを変換する装置となっている。




ゾーンをまたがる通信をするため、ゾーン#1 では、 VLAN100、ゾーン#2では、VLAN200だとしたときに、相互接続を行うため、VLANID変換装置で、VLAN同士をブリッジする。変換ルール数が250個ぐらいしかかけないという問題があり、別の機器の選定を行っている。~




将来的には、すべてのゾーンをまたがる任意のVLANをつなげる装置を準備したい。
だいぶ先の話として、専用サーバ、さくらのVPSといった他のサービスとの相互接続などで、こういうったVLAN変換装置が使えないか考えている。また、プライベートクラウドとお客さんの広域イーサなどといった専用線との接続も出来たら、と考えている。



今の仕組みでは、一カ所に集中しているので、網が広がっていたとき、そこをスケールするようなことを考えないといけない。



今考えているのは、PBB(Provider Backbone Bridge)や、KDDIさんがやっている、EoE(Ether over Ether)などがあり、一カ所だった装置を網として広げていこうと考えている。網の中では、24bitのユーザの識別しがあり、各サービスのL2網から持ってきたVLANを共通のIS-IDにマッピングを行い、相互接続が出来るようなアーキテクチャにしていきたい。

結局VLANで作ってきたが、スケーラビリティやVLAN IDのことを考えていくと、どうやって網を作っていくか考えないといけない。
発展途上であり、今使える技術としてはVLANしかなかった。



Ether over InfiniBandを検討しており、InfiniBandにEtherをそのまま載せてしまう。



内部資料をそのまま持ってきてしまったが、Ether over InfiniBand を石狩では検討し、実験しており、上がEthernetのネットワーク、ストレージのネットワークをInfiniBandで組んでいる。今までは、ホストサーバには、ストレージのネットワークとイーサのネットワークの両方を作らないといけなかったが、InfiniBandを使うと、ホストサーバとの接続をInfiniBandで束ねてしまいましょう。その上で、EtherとInifiniBandを束ねる装置をおいてしまう。この方式を、石狩で考えている。

IP over InfiniBand でその上でNFSで動いている。
そのほか、Ether over InfiniBandなどもある。

Etherのスイッチだと高いが、InfiniBandであれば、40Gのスイッチでもすごくやすく、帯域も簡単にアップできるし、網構成もシンプルに出来るという特徴がある。



完全トンネル方式。
Open vSwitch は某社さん、某N社さん。
NECさんですね！わかります。

GRETAPなど。。。

Q. MTUは？
A. 痛い問題ですね。基本的には、お客さんには、L2ネットワークだといっているので、IP-MTUは1500出さないといけないと考えている。バックボーンのMTUを大きくするか、トンネルするときに、フラグメントするか、どちらかで考えないといけないと思っている。~

今後Etherのスイッチを使わなくてもEtherのネットワークを作れる時代がくるのではないか！



クラウドでは、単純なネットワーク到達性では機能不足。従来のハードウェアアプライアンスに変わるものをクラウドで提供する。

仮想ルータ： Vyatta、IIJ SEIL/86(実験中)
仮想ファイアーウォール： pfSense、そのほか実装中
仮想ロードバランサ： 実装中
仮想ファイルサーバ：実装中



クラウドのネットワークはL2との戦いであり、研究レベルではL3到達性ではだめだと認識。
L2じゃないと、お客さんは使いにくい。L2でどのようにしてつなぐかが重要。
MACアドレス、VLAN数などの壁に当たるので、L2機器でがんばるのかトンネル方式でがんばるのか。

あとは、他のサービスとの相互接続性や、物理、既存のサービスの置き換えをしたい。