DeNAにおけるOpenStack運用#2

こんにちは。IT基盤部でOpenStackの運用をしています酒井です。
私からは弊社OpenStack環境で使用しているSDNについてご紹介したいと思います。前回の記事で紹介しましたように、弊社ではBigSwitch Networks社のBig Cloud Fabric（以下BCF）を使用しています。本エントリーでは弊社がどのようにBCFをOpenStackとインテグレーションしているか、どのように運用しているのかについて紹介させていただきます。

OpenStackとSDNの導入の狙い

従来はネットワークのconfig変更をする場合、サーバエンジニアからネットワークエンジニアにその作業を「依頼」する形を取っていたのですが、この「依頼」を無くすことが狙いでした。依頼内容としてはスイッチへのVLAN設定やACL設定、LBへのオブジェクト追加など比較的簡単な作業です。しかし、依頼件数が多い時などはネットワークエンジニアがその依頼を作業するまでに数日要することもあり、スピード感に欠ける状況となっていました。それをOpenStackとSDNの導入によって、自動化したり、サーバエンジニアが自ら行うことができるようにすることで作業のスピードを上げることができ、またネットワークエンジニアもより高度なスキルを要する業務に集中できるのではないかと考えました。

構成

OpenStack + BCF 構成パターン

BCFをOpenStackと共に使用する方法としては3パターンあります。一つめはOpenStackのアンダーレイネットワークとしてBCFを使用する方法でこの場合はOpenStackとBCFの連携はありません。二つ目はP-Fabricと呼ばれる方法でOpenStackとBCFでLayer2の情報のみ連携しルーティングは物理ネットワーク上で行います。それに対しP+V FabricというパターンではLayer2, Layer3が連携され、各Compute Node上で分散ルーティングされます。P+V Fabricの方が柔軟なネットワーク構成が可能ではあるのですが、NATが必須となる仕様となっておりNATの運用に手間をかけたくなかったため、弊社ではP-Fabricのパターンを採用しました。

BCFの構成

BCFはリーフ&スパイン型のスイッチ郡とBCFコントローラから構成されます。BCFコントローラが全スイッチを集中管理しており、設定作業をする際も個別のスイッチにログインする必要はなくBCFコントローラで全ての作業ができます。POD全体を一つの大きなスイッチ（文字通りBIG SWITCH）のように扱うことができる、というのが特徴です。また、BCFコントローラ、スイッチともLinuxが動作しているため、いざとなればサーバ管理者が慣れ親しんだLinuxコマンドでトラブルシューティングする、ということも可能です。弊社ではスイッチにはDELL社の製品を使用し、リーフ - スパイン間は40Gbps、リーフ - サーバ間は10Gbpsで接続しています。

OpenStackのネットワーク構成

OpenStackのネットワーク構成としては、ネットワークオプションの一つであるプロバイダーネットワークとして構成しています。Controller Nodeでneutron-serverが動作し、各Compute Nodeではneutron-openvswitch-agentが動作します。neutron-serverではbigswitch社のプラグインである bsnstacklib と弊社内製プラグインの networking-bigswitch-l3-pe を使用しています。内製プラグインを開発した背景については後述します。

OpenStackとBCFの連携

ここではOpenStackがどのようにBCFと連携をしているのかを具体的に紹介したいと思います。こちらがBCFのコンフィグの例になります。

tenant demo.openstack
  id 1a2cf63967ca4f26ae5356bb2e6c818c
  origination openstack
  !
  logical-router
    route 0.0.0.0/0 next-hop tenant system
    interface segment net_demo
      ip address 10.66.16.1/24
    interface tenant system
  !
  segment net_demo
    id 5310d836-c170-4fda-882c-8a61324d90c6
    origination openstack
    !
    endpoint 0485e7a0-198f-4b88-a877-ca79d3e882bc
      attachment-point interface-group osvdev0013 vlan 300
      ip 10.66.16.2
      mac fa:16:3e:ef:4f:f4
      origination openstack
    !
    member interface-group osvdev0013 vlan 300
      origination openstackdev

OpenStackとBCFのオブジェクトの対応は以下の通りです。

OpenStack	BCF
Project	tenant
Network	segment
Port	endpoint
Router	logical-router

前述したようにP-fabricの構成ではLayer 2の情報が連携されます。具体的には、Project, Network, Portの情報がneutron-serverのbsnstacklibプラグインによってBCF Controllerに同期されます。しかし、Layer 3の情報に相当する logical-router のコンフィグは同期されない仕様となっています。そのため、プロジェクト毎にネットワークを作成する場合はlogical-router部分の設定を手動で追加する必要がありましたが、これでは不便なためnetworking-bigswitch-l3-peプラグインを開発しました。BCF ControllerにはAPIが用意されており、このように pluginからAPIをコールしています。

障害事例

ここでOpenStack + BCF環境で弊社が遭遇した障害の一つとその解決方法についてご紹介しましょう。

障害内容

ある時、新規に作成したインスタンスが通信できないという障害が発生しました。各Compute Node上のneutron-openvswitch-agentのログを調べてみると、以下のようなneutron-serverに対するリクエストが失敗し続けていました。

2016-08-31 03:48:25.294 9269 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-57ee640e-5534-4c17-8818-4ec71381ab07 - - - - -] process_network_ports - iteration:1081082 - failure while retrieving port details from server

調査してみると、neutron-sererのbsnstacklibプラグインの不具合が原因となりリクエストがタイムアウトしていました（この不具合については既に修正済みとなっています）。neutron-openvswitch-agentはこのリクエストが失敗すると全ての管理情報を再同期しようとするため（ソースコードだとこの辺り）、さらにneutron-serverに大量のリクエストが集まり処理しきれず再度失敗する、ということを繰り返していました。

復旧方法

まずneutron-serverの負荷を減らしリクエストを捌ききるために、各Compute Node上のneutron-openvswtich-agentを1台ずつ止めていく、というオペレーションをしていきました。すると無事neutron-serverに溜まっていたリクエストがなくなりました。次は止めたneutron-openvswitch-agentを起動していくわけですが、しかし、ここで一つ問題ありました。その時使用していたneutron-openvswitch-agentのバージョン(liberty, 2:7.0.4-0ubuntu1~cloud0)だと、起動時にインスタンスの通信が数秒途切れることが分かっていました。neutronのリポジトリを調べてみるとこれらのパッチ（ Cleanup stale OVS flows for physical bridges , Don’t disconnect br-int from phys br if connected ）で修正されていることが分かりました。これらのパッチを適用した後、止めていたneutron-openvswitch-agentを一つずつ起動しneutron-serverがリクエストを処理し終わるのを待つ、というオペレーションをしていくことで無事復旧することができました。

まとめ

OpenStack環境のSDNに使用しているBCFについて紹介させていただきました。当初の狙い通り、OpenStackとBCFを連携させることで、ネットワークエンジニアへ依頼をすることなく、サーバエンジニアが自らネットワーク構築や設定変更ができる環境を構築することができました。
BCFとのインテグレーションについてご紹介したように、製品自体がユースケースに合わない場合でもAPIを完備していることでユーザ自身がカスタマイズできることはSDN製品の良いところだと思います。またトラブルシューティングについても、OpenStackやそのプラグインはオープンソースなのでいざとなればユーザ自身が調査し問題解決できることもご理解いただけたかと思います。

次回はいよいよSDS編です。