OpenStack Summit Sydney 2017

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 のセッションに参加しました。参加人数は 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 をより使えるようにすることが挙げられていました。

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

参加人数は　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 を使って問題の箇所を特定する

参加人数は 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 を有効にすること

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

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 の組合せをしようとしたが上手くいかなかったという意見に対し、テクニックは必要だがシングルノードでできるという意見もありました。