はじめに

今回で 16回目の開催となる OpenStack Summit が 11月6~8日の 3日間にわたりオーストラリア シドニーで行われました。
南半球に位置するオーストラリアは日本とは季節が逆になり、11月は春に当たりますが、とても寒かったり、雨風が強い日もあり、残念ながらあまり天候には恵まれませんでした。

今回の Summit は参加者数が約 2,300人でした。最近は参加者数が 5,000人を超える Summit が続いていましたので大幅に減少する結果となりました。これは欧米からの移動距離などの地理的要因もあるようです。

OpenStack Foundation Keynote

Jonathan Brice 氏が OpenStack Summit 1回目から今回開催の16回目までの OpenStack の道のりを紹介し、OpenStack コミュニティは現時点で、82,000人、187 の企業が携わり、20,000 ものイベントが開催されるまでに成長したと発表しました。
そして、Foundation の今後の方針として、以下の4つの方針を挙げていました。

  • ユースケースからわかりやすい事例などを見つけ、
  • 他のコミュニティと連帯し、
  • 信頼性の向上と標準化を進める
  • そして、必須の技術を構築して徹底的にテストする

また、Superuser Awards は、Tencent Tstack Team が受賞するなど、今回は中国企業の参加が目立ちました。OpenStack ユースケースの紹介を聞いていると、OpenStack の Edge Computingの側面を強調しているように感じた今回の基調講演でした。

技術セッション・ワークショップ

Tricircle - Project Update

Tricircle のセッションに参加しました。参加人数は 10人ぐらいです。
PTL を務める Huawei 社の Dawuan 氏が Tricircle について説明しました。Tricircle とは、異なる OpenStack クラスターの Neutron を相互に接続するプロジェクトです。物理的に離れたデータセンターの別の OpenStack のインスタンス VM が VxLan を横断して同じネットワークにいるようなイメージです。

Tricircle の構成要素を以下のように紹介していました。

  • Tricircle Local Neutron Plugin
    Neutron サーバの下で動く OVN/Dragonflow のようなプラグインです。このプラグインは Neutron の自動横断のきっかけを処理しています。
    これはコアプラグインと Neutron サーバの間のレイヤーです。このプラグインがインストールされた Neutron サーバを Local Neutron サーバと呼びます。
  • Tricircle Central Neutron Plugin
    Neutron サーバの下で動く OVN/Dragonflow のようなプラグインです。このプラグインはテナントの L2/L3 ネットワーク自動横断 (マルチ OpenStack のインスタンス間) を処理しています。
    このプラグインがインストールされた Neutron サーバを Central Neutron サーバと呼びます。
  • Admin API
    OpenStack のインスタンスと AZ 間のマッピングを管理する API です。
  • Xjob
    Admin API または Tricircle Central Neutron Plugin からの非同期ジョブを受け取って処理します。Admin API, Tricircle Central Neutron Plugin は非同期ジョブを RPC API (Xjob が提供) 経由で Xjob に送ることができます。
  • Database
    Tricircle は自身のデータベースを持っており、主に AZ マッピング、ジョブ、ルーティングテーブルに利用します。また、Neutron のデータベースも再利用されます。

基本的に Local Neutron は単体で従来の Neutron のサービスを提供し、中央に Central Neutron を置き、Local Neutron を管理するようなモデルになっています。Local Neutron と Central Neutron が互いにどのように動いているかのフローも紹介していました。

TripleO - Project Update / TripleO - Project Onboarding

TripleO のセッションに参加しました。参加人数は 15人ぐらいです。TripleO (OpenStack-On-OpenStack) は OpenStack そのものを使って OpenStack のインストール、更新、操作をするプロジェクトで、主に Heat, Puppet を使用しています。
Pike 版における特徴は、以下の通りです。

  • カスタマイズした Kolla のコンテナを使用している
  • Heat, Ansible, Paunch を用いてオーケストレーションもできる
  • 全てのサービスはコンテナに乗せている、ただしベアメタルにデプロイもできる
  • 自動でコンテナイメージを作成する CLI ツールが用意されている
  • HA 構成も可能
  • DPDK もサポート (OVS 2.6) されている
  • CI はサービスやユースケースを中心にカバーしている

Queens 版への動向としては、CLI/UI の改良と Ansible をより使えるようにすることが挙げられていました。

How does Neutron do that?: A Hands-On Workshop with Neutron Networking

Rackspace が主催したワークショップに参加しました。 参加人数は 70人ぐらいです。
このワークショップでは、実際のマシンを使って手動で namespace や veth の作成、vxlan の作成と設定をしました。また、Neutron が裏で何をしているのかを説明しており、この辺は devstack 任せだったので理解を深めることができました。

Neutron networking demystified for beginners

参加人数は 50人ぐらいです。Neutron の歴史や構成などの簡単な説明と Neutron の具体的なトラブルシューターを紹介していました。

  • 順番としてはまず、Neutron サーバのログとコンピュートノード上の Neutron エージェントのログ両方を見ること
  • そのログを grep でエラートレースすること、コマンド「grep -i “trace|error” <server>.log <agent>.log」を試してみる
  • 次に、コマンド「openstack port show <port-UUID>」を実行して、そのコンピュートノード上でportの紐付けが成功しているかどうかをチェックする
  • 次に、コマンド「openstack network agent list」を実行して、各コンピュートノード上の Neutron エージェントの状態を確認する
  • ネットワークノード上では L2 plugin, Metadata, DHCP, L3 エージェントが動いており、コンピュートノード上では L2 Plugin エージェントのみが動いているはず
  • 次に、コンソールログを見て、インスタンスが IP アドレスを正しくもらっているか、また cloud-init が正しく実行されたかを確認する
  • コマンド「openstack console log show <instance-name|UUID>」を実行する
  • それでも通信できない場合は、Security Group をチェックする。デフォルトではすべてのポートが閉じられているため、必要なポートを開く
  • 次に、ネットワークノード上の Routerまたは DHCP の namespace からネットワークの接続をテストする
  • コマンド「sudo ip netns exec qrouter-<Network-UUID> ping <VM’s IP>」を実行する
  • 最後に、tcpdump を使って問題の箇所を特定する

How to deploy 800 nodes in 8 hours automatically

参加人数は 30人ぐらいです。Tencent Tstack Team が 春節時の旅行ラッシュに備えて China Railways のサーバを増強した事例紹介で、大量のノードを自動的にデプロイするノウハウを公開しました。8時間で 800ノードを用意する必要があったが、その際に使用したのが Cobbler と Ansible だったそうです。

  • 1. 自動的に OS をノードにインストールする (各物理ノードは PXE と Kickstart でブートできるとのこと)
      – 最初に PXE クライアントが DHCP サーバから IP アドレスと TFTP サーバのアドレスをもらう
      – 次に、NBP、Kernel を TFTP サーバからもらう
      – 最後に、HTTP サーバにアクセスして kickstart ファイルとインストールパッケージを取得する
  • 2. 自動的に OpenStack をデプロイする
      – Ansible Playbook を使用
      – 以下の 4つのポイントに注意
        1) gather_facts 機能を無効にすること
        2) パイプライン機能を有効にすること
        3) fork の数の増やすこと
        4) ssh をアップグレードし、ControlPersist を有効にすること

 

注意事項やポイントなどを示していましたが、つねに監視することが最も重要と話していました。

Adding Cellsv2 to your existing Nova Deployment / Cellsv2 Forum

Nova Cells V2 のフォーラムとセッションに参加しました。参加人数は 20人ぐらいです。
まず Cells V1 は Rocky で廃止が決定したので、Cells V1 から Cells V2 にアップデートで起こる問題を議論しました。Cells V1 ではどれぐらいのインスタンスを動かすことができるかを事前に知ることができますが、Cells V2 では同様のことをするにはどうすればいいのかを議論しましたが、具体案はでませんでした。

  • Queens 版での修正箇所
    Nova ではスケジュールのリトライ機能があります。これは、あるホストでインスタンス作成に失敗した場合、他のコンピュートノードに再スケジュールする機能です。Pike 版では個々のセルのサービス (nova-cond,nova-compute) は API-cell の nova-api データベースを操作できません。また、RPC 経由で API-cell のサービス (nova-scheduler) にもアクセスできません。これによって、個々のセル側で失敗すると API-cell 側ではそれを認識できず、スケジュールのリトライができない問題が発生します。Queens 版ではこの問題を解決する予定です。

    個々のセルのデータベースが独立しているため、Pike 版ではインスタンスのリスト検索の結果は、検索したデータベースの順番のまま表示されます (それぞれのデータベース内の結果はソートされます)。Queens 版では複数のセルのデータベースの結果をまとめてマージソートで検索できる機能を追加する予定です。

 

  • その他
    Pike 版ではセル間のマイグレーションはサポートされません。これは、あるセルのホスト上のインスタンスを別のセルのホストに移行する機能です。将来的にサポートされるかもしれませんが、今のところ議論されていません。ただし、同セル上の異なるホストのマイグレーションはサポートされています。

    Kolla でのマルチセル構成についての議論もありました。また、セッションでは、Cells V2 を担当する Red Hat 社の Dan Smith 氏が Cells V2 を採用した方が良い条件を説明しました。主に、今のスケールでは DB・MQ に限界を感じている、あるいは HA 構成とは違うパフォーマンスが欲しいとのことでした。
    基本的に、Cells v2 にアップデートすることを推奨しますが (単体セルでの利用)、無理にマルチセルにしなくとも良いとも言っていました。

その他

NFV や DPDK, CPU-pinning のフォーラムに参加しました。参加人数は 20人ぐらいです。DPDK を CPU-Pinnig と一緒に組み込むべきという意見がありましたが、結局まとまりませんでした。異なる NUMA ノードで OVS-DPDK と SR-IOV の組合せをしようとしたが上手くいかなかったという意見に対し、テクニックは必要だがシングルノードでできるという意見もありました。

まとめ

かつて OpenStack のコンポーネントは数個しかありませんでしたが、今や 100 以上にまで拡張しています。今後は様々な分野で活用して、ユースケースを共有し様々なコミュニティにも協力する意向を感じました。
次回の OpenStack Summit は来年 5月にバンクーバーで開催される予定です。