これも簡単で、tapインターフェースに指定すると、kbps単位で指定出来る。設定していない為、outgressは10G使えてしまう。できているなとおもって、使っていたが、いくつか問題が発生した。フローベースのアーキテクチャなので、DoSアタックなど、大量のフローが発生すると、転送性能が著しく低下する問題があった。vSwitchを通過する他のお客さんにも影響が発生した。Port番号など全部展開して、新規のフローについてはデーモンで動いているovs-vswitchdに問い合わせて、フローキャッシュとして、カーネルに保存します。新しいフロー、DoSアタックみたいに、パケット単位でフローが発生すると、問い合わせが発生つづけ、ovs-vswitchdのCPUが上昇し続けた。フローキャッシュは、未使用エントリは5秒で、expireする。5秒で通信されないフローについては、いったんデーモンに問い合わせるようになる。5秒以下でも、1000エントリ超えると、削除するようになる。1,000エントリは、DoSアタックを食らうと一瞬であふれてしまう。今の対策としては、1.2.1にバージョンアップした。フローのセットアップ性能が50倍になり、だいぶ影響が受けにくくなった。バージョンアップにより、ガベージコレクション開始の閾値を変更出来るようになった。フローキャッシュの最大エントリも128kなので、12万ぐらいに設定して、多少あふれても問題ないように設定した。vSwitch自体、Flowベースなアーキテクチャなので、根本的な解決は難しそうな気がしている。今のところで、お客さんの仮想ポート毎にフロー数をモニタして、フロー数が異常になったら、帯域制限を行うよな監視システムを作ろうとしている。vSwitchで仮想ポート毎に、フロー数の制限が出来るようになるとよいのかなと考えている。ここからL3の話をします。インターネットと接続する、エッジルータまでのネットワークで、エッジまではVLANを持ってきて、VLANインターフェースを作成し、エッジルータの2台にIPアドレスをを設定し、VRRP冗長している。すみません、SRにしたらやすくなったのでSRにしました。(資料の更新忘れ)管理ドメインが違うバックボーンが増えてきて、どのようにして接続するか、というのが課題になっており、プライベートASを使用したBGP接続が一般的ではないかなとおもい、BGPで接続している。ちなみに、上のバックボーンは運用部が運用している。これを設定した経路をそのまま上のバックボーンに経路を伝えると、クラウドコントローラーのバグなどにより、変な経路をバックボーンに流してしまったら、通信障害になるので、管理ドメインを分け、BGPで接続、プールするアドレスのみ受け入れるようにしている。クラウドで使用するアドレス(/20など)をあらかじめプールしておき、ルータの設定で、配下のVLANに割り当てている。ルータは、結構きびしいのがVRRPのインスタンスの数ではないかなともう。お客さんが使うVLANにIPアドレスをたくさん割り当てていく。VRRPは、VRIDはそもそも256個しかない。全部のVLANに別のVRIDを使うことが出来ない。別のVLANに同じVRIDを使える装置にしないといけないという制限がある。実のところをいうと、ARPのエントリが厳しい結果が得られた。ルータの下に、8,000VMとか収容するので、ARPのエントリを作らないといけない。実際にやってみると、VRRPのインスタンスを大量に作ると、VRRPの状態が変わり、フラックするという問題がある。HELLOパケットが流れることとなり、バックアップ側が受け取れずに、勝手にマスターに昇格してしまう。B社さんのルータで発生し、C社さんのルータでは発生する。ラインカードのCPU負荷が張り付いていて、メインのCPUは大丈夫だった。ルータ系のDDoSアタックを気にしている。グローバルなIPアドレスがついていると、インターネット側から攻撃されてしまう。某B社さんのルータの23ポートに対して、ショートパケットをワイヤーレートで送りつけたら、CLIが固まる。上側のグローバルのデフォルトゲートウェイについては、隠せないので、どうしてもオープンになってしまうので、耐性だけ確認している。配下に/16とかの大きな空間を作り、テスターで配下に12,800クライアントいるような環境で、トラフィックを流すとルータのCPU負荷が上昇し、CLIが操作出来なくなる。ルータについては我々は何も申しわげていない。B社とC社、両方買ってみた。よい方を正式サービスで使おうとした。それで、大阪には、AゾーンとBゾーンがある。結局石狩では何を使うか、わかったかと思う。ID数の克服として、ゾーンを分けることにしたが、お客様が、裏でゾーンをまたがる通信を接続したいという要望があることから、実装した。VLANを変換する装置となっている。VLAN100、ゾーン#2では、VLAN200だとしたときに、相互接続を行うため、VLANID変換装置で、VLAN同士をブリッジする。変換ルール数が250個ぐらいしかかけないという問題があり、別の機器の選定を行っている。~将来的には、すべてのゾーンをまたがる任意のVLANをつなげる装置を準備したい。先の話として、専用サーバ、さくらのVPSといった他のサービスとの相互接続などで、こういうったVLAN変換装置が使えないか考えている。プライベートクラウドとお客さんの広域イーサなどといった専用線との接続も出来たら、と考えている。今の仕組みでは、一カ所に集中しているので、網が広がっていたとき、そこをスケールするようなことを考えないといけない。Ether)などがあり、一カ所だった装置を網として広げていこうと考えている。網の中では、24bitのユーザの識別しがあり、各サービスのL2網から持ってきたVLANを共通のIS-IDにマッピングを行い、相互接続が出来るようなアーキテクチャにしていきたい。IDのことを考えていくと、どうやって網を作っていくか考えないといけない。発展途上であり、今使える技術としてはVLANしかなかった。InfiniBandを検討しており、InfiniBandにEtherをそのまま載せてしまう。石狩では検討し、実験しており、上がEthernetのネットワーク、ストレージのネットワークをInfiniBandで組んでいる。今までは、ホストサーバには、ストレージのネットワークとイーサのネットワークの両方を作らないといけなかったが、InfiniBandを使うと、ホストサーバとの接続をInfiniBandで束ねてしまいましょう。その上で、EtherとInifiniBandを束ねる装置をおいてしまう。この方式を、石狩で考えている。その上でNFSで動いている。InfiniBandなどもある。Etherのスイッチだと高いが、InfiniBandであれば、40Gのスイッチでもすごくやすく、帯域も簡単にアップできるし、網構成もシンプルに出来るという特徴がある。某社さん、某N社さん。NECさんですね!わかります。