Plan9日記

2014-12-22

AIST Super Green CloudにおけるCloudStack運用話

本エントリはCloudStack Advent Calendar 2014の22日目のエントリとして書きました。

はじめに

今年の7月からApache CloudStackを用いてプライベートクラウドを運用しています。オープンソース版のCloudStackを155台(プロセッサ数3100)の計算機で運用するというのは、それなりの規模だと自負しています。InfiniBand + PCIパススルーでHPC用途でも使える性能を持った仮想クラスタを提供するという点が目玉です。詳細は次の2つのスライドを参照してもらうとして、本エントリでは、現在に至るまで遭遇したCloudStackの問題をまとめてみました。

プライマリストレージローカルディスクセカンダリストレージがS3互換のCephオブジェクトストレージという具合に、一般的な構成とはちょっと違っているのでコーナーケースをいろいろ踏んでいる模様です。通常はプライマリストレージとしてNFSなどの共有ストレージが使われます。CloudStackでは、スケジューラが選んだホストにVMデプロイし、何か問題があると、VMマイグレーションで別ホストに動かすという処理を行うことがあります。共有ストレージの場合はまったく問題ないのですが、ローカルストレージだとマイグレーションできず、そこでジ・エンドです。例えば、以下のリストには挙げてませんが、仮想クラスタを作成するとき、複数のVMを同時並行にデプロイします。この際、タイミングによっては、スケジューラは同じホストを選択することがあります。しかし、PCIパススルーを使う場合はホストに1 VMしか実行できないので、後続のVMリソース不足でデプロイに失敗します。すると、そのVMを次の候補のホストにマイグレーションしようとするのですが、前述のようにプライマリストレージがローカルストレージだとマイグレーションに失敗し、デプロイもエラーになります。(補足:PCIパススルー拡張の有無に関わらず、デプロイに失敗した場合にこの問題は起きえます。)

当初はMLやJIRAにリポートしても反応が薄く(というか無反応)でかなり気持ちが萎えたのですが、年末に近づくにつれパッチも取り込まれ始め安堵しています。まだまだ抱えている問題は山積しているので、来年は開発コミュニティに対してもっとプレゼンスを上げていきたいと考えています。また、運用で得た知見も別途機会を設けて共有したいですね。

運用中に踏んだ地雷リスト

以下に、我々が遭遇した不具合を列挙します。なお、我々はバージョン4.3を使っており、独自に開発したSR-IOV対応パッチを取り込んでいます。以下でたびたび「sriov-43」というgitブランチ名が出てきますが、これはプライベートなgitリポジトリのブランチです。

1. cloudstack-agent jsvc gets too large virtual memory space. (JIRA #7951)

物理メモリの搭載量の大きいマシンで、cloudstack-agent が過剰に仮想メモリを確保するため、インスタンス作成時にQEMUがメモリを確保できず起動に失敗する場合がある。cloudstack-agent のメモリ使用量を制限するパッチを作成した。パッチは本家に報告して取り込まれた。

ホスト起動時は問題ないが、数日経つとVMデプロイに失敗するという現象が発生する。メモリリーク等を疑ったが、結局cloudstack-agentの問題だった。cloudstack-agent(jsvcプロセス)が30GB超のメモリを確保していた。

2. listUsageRecords generates NPEs for expunging instances (JIRA #6472)

アカウンティング情報を取得する API を呼び出す際に、破棄されたリソースがあると NullPointerException が発生する不具合があった。修正パッチが既に本家に取り込まれていたが、この修正に不十分な部分があり、NullPointerException は発生しないものの必要な情報(virtualmachineid)が含まれない状態で結果が返ってきていた。取得情報に virtualmachineid も含める修正パッチを作成し、本家に報告して取り込まれた。

3. Duplicate usage records when listing large number of records (JIRA #2625)/Small page sizes return duplicate results (JIRA #3401)

アカウンティング情報を取得する際の SQL 文が適切ではなく、ページサイズ等の条件によっては内容の重複する結果が返ってくる場合があった。既知のバグでありパッチも存在したので、sriov-43 ブランチにcherry-pick した。

4. Public key content is overridden by template's meta data when you create a instance (JIRA #6869)

インスタンスROOT ボリュームからテンプレートを作成すると、そのインスタンスの下記の情報もテンプレートの属性情報として記録されていた。

そのテンプレートから新しいインスタンスを作成する際、user data 経由でSSH 公開鍵を渡そうとしても、強制的にテンプレート付属の SSH 公開鍵がインスタンスに渡されていた。本家に報告後、開発者(Harikrishna Patnala)により修正パッチが作成されたので、sriov-43ブランチにcherry-pickした。

5. Attaching a data disk created on local storage to a VM is failing (JIRA Migration of a VM with volumes in local storage to another host in the same cluster is failing #6802)/Migration of a VM with volumes in local storage to another host in the same cluster is failing (JIRA #6810)

プライマリストレージローカルディスクを使用する構成での不具合である。特定の物理マシンの host id を指定してインスタンスを作成すると失敗する場合があった。storage poolallocator の処理に不具合があった。既存のバグであり、パッチも存在したので、sriov-43ブランチにcherry-pickした。

6. Negative ref_cnt of template(snapshot/volume)_store_ref results in out-of-range error in Mysql (JIRA #6236)

セカンダリストレージに S3 を使用する構成での不具合である。セカンダリステージングストア上に作成されるテンプレートキャッシュ排他制御ができておらず、タイミングによってキャッシュの参照カウンタが -1になる場合があった。参照カウンタが -1 となったテンプレートはそれ以後使用できなくなる(ゴミとして残る)。本家に workaround する本パッチが報告されていたが、排他制御を行う根本的な対処ではなく、参照カウンタが 0 の時はそれ以上デクリメントしないという処理を追加するパッチであった。ただしこのパッチにもバグがあり、修正すべきメソッドとは別のメソッドに処理が追加されていたため、我々で修正した上でsriov-43ブランチに適用した。

7. [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1) (JIRA #7539)

上記のパッチ(CLOUDSTACK-6236)適用後も別の処理で参照カウンタが -1 になる現象が発生したため、根本対策としてキャッシュの処理部分に lock による排他制御を追加するパッチを作成した。本家に報告、パッチの送付を行ったが、未だに放置されている。

8. Can't create proper template from VM on S3 secondary storage environment (JIRA #7412)

セカンダリストレージに S3 を使用する構成での不具合である。インスタンスのボリュームからテンプレートを作成する際にも、セカンダリステージングストア上でボリュームがキャッシュされる不具合があった。同じインスタンスのボリュームから複数回テンプレートを作成すると、2回目以降はプライマリストレージ上のオリジナルのボリュームではなく、セカンダリステージングストア上のキャッシュされた古いボリュームからテンプレートが作成されていた。インスタンスのボリュームからテンプレートを作成する際は、セカンダリステージングストアでキャッシュしないパッチを作成した。パッチは本家に報告して取り込まれた。

9. Fails to attach a volume (is made from a snapshot) to a VM with using local storage as primary storage. (JIRA #8085)

これもプライマリストレージローカルディスクの場合に起きる(マイグレーションを前提としていることに起因する)バグ。スナップショットから作成したボリュームがアタッチできない。バグ報告済み。

クラスタ管理ソフトウェアとの相性

ASGCのもう一つの特徴として、いわゆるスパコン上でクラウドを運用している点が挙げられます。ASGCのハードウェアは、Cray社製のスパコン(PCクラスタ)です。Crayのスパコンには標準のクラスタ管理ソフトウェアとしてACEが搭載されており、ASGCでも使っています。ACEスパコンとして運用することを前提に作られたソフトウェアなので、CloudStackなどのクラウドミドルウェアを動かすことは念頭になく、ホストでcloudstack-agentが動作するまでに結構苦労しました。この手のクラスタ管理ソフトウェアクラウドミドルウェア親和性が高くなると、運用する側としてはとってもうれしいです。

ACEでは、ネットワークブートでディスクイメージを各ホストに展開しますが、/work以外のディレクトリはread onlyになります。一般的なスパコン運用であればこれで問題ないのですが、これではCloudStackは動きません。具体的には、次のような問題があり、地道に問題を潰していきました。ファイル一つの変更でもディスクイメージの作り直しが必要になります。。

  • /etc や /var/lib/libvirt 上のファイルが編集できない。/etc/cloudstack/agent/agent.properties などの cloudstack-agent が書き換える事を前提としているファイルを全て洗い出し、それらのファイルを /work に移しシンボリックリンクを貼る。
  • /etc/{cgconfig.conf,cgrules.conf} など、CloudStack 関連以外のファイルも cloudstack-agent が書き換えるため、/work に移してリンク

謝辞

上記の問題を解決し、日々ASGCの安定運用に尽力しているASGCサポートチームの面々(少数精鋭!)に感謝して、本エントリを閉じます。

2014-09-29

[] AWSおさらい

Amazon Web Services 基礎からのネットワークサーバー構築」という本が出ていたので、AWSのおさらいも兼ねて読んでみる。AWSの上で、インフラ技術を学ぶという趣旨。クラウドが当たり前になって、クラウドじゃないレガシーなシステムが目の前から消えていくと(半分現実になりつつある気がするが)、近い将来にはこんなテイストのテキストが普通になるのかなと感じた。本書はAWSの入門に必要最低限のネットワーク周りの解説が載っているけど、教科書的解説+クラウドで演習といった形式でね。

さて、VPCを触るのは初めてだけど、VPCを作って、その中のインスタンスApacheを動かすところまで確認した。Tokyo regionだと、RTTは9秒強ぐらいだな。

インスタンスをstopして、続きはまた明日。

余談だけど、Amazon Linuxはちゃんとshellshock対策されてるね。

[ec2-user@ip-10-0-1-10 ~]$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

2014-09-16

Vagrant Google Compute Engineプロバイダ

Vagrant本によるとAWSプロバイダがあるそうで、GCE版もあるかとググったところ、案の定、Vagrant GCE Providerが見つかった。プロバイダとはハイパーバイザやクラウドのように、仮想環境を実行するプラットフォームのことで、VirtualBox以外にVMWareやHyper-V、Docker、AWSなどに対応している。

GCEプロバイダはプラグインとして提供されているので、ホームページにしたがってインストールを進める。

$ vagrant plugin install vagrant-google
Installing the 'vagrant-google' plugin. This can take a few minutes...
Installed the plugin 'vagrant-google (0.1.3)'!

前準備として、GCEのDeveloper consoleの"API & Auth" -> CredentialsからClient IDを生成する。アプリケーションタイプはService account。生成が終わると、秘密鍵(*.p12)が自動的にダウンロードされ、パスワードがポップアップされる。これでプラグインの利用に必要なE-mailアドレスがページに表示されているはず。

続いてダミーのboxを追加する。

$ vagrant box add gce https://github.com/mitchellh/vagrant-google/raw/master/google.box
==> box: Adding box 'gce' (v0) for provider: 
    box: Downloading: https://github.com/mitchellh/vagrant-google/raw/master/google.box
==> box: Successfully added box 'gce' (v0) for 'google'!

次にVagrantfileを編集する。試しに作ったのはこんな感じ。GCEだとユーザ名はVagrantではなく、ローカルユーザ名と同じになるので、それに合わせてoverrideする。Project IDなどは直接書くのは(gitなどで管理するには)セキュアじゃないので、環境変数で与えるようにしておく。

Vagrant.configure("2") do |config|
  config.vm.box = "gce"

  config.vm.provider :google do |google, override|
    google.google_project_id = ENV['GCE_PROJECT_ID']
    google.google_client_email = ENV['GCE_CLIENT_EMAIL']
    google.google_key_location = ENV['GCE_KEY_LOCATION']

    google.image = "centos-7-v20140903"
    google.machine_type = "f1-micro"
    google.zone = "asia-east1-c"

    override.ssh.username = "oraccha"
    override.ssh.private_key_path = "~/.ssh/google_compute_engine"
  end
end

vagrant upする。なんだか共有フォルダ(正確にはrsyncを使ったsynched folderだっけ)の作成でエラーが出ているけど、とりあえず無視する*1

$ vagrant up --provider=google
  :
Vagrant::Errors::VagrantError: The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mkdir -p '/vagrant'

Stdout from the command:



Stderr from the command:

sudo: sorry, you must have a tty to run sudo

はい、ちゃんとSSHできた。

$ vagrant ssh
[oraccha@i-2014091622 ~]$ sudo virt-what 
kvm

vagrant destroyでVMインスタンスは破棄される。あと、vagrant suspendやhaltには対応していないみたいね。

実践 Vagrant

実践 Vagrant

*1:CentOS 7のsudoersファイルでは、requirettyがデフォルトで有効になっているのが問題の原因なんだろうけど、どうしたらよいのかな?

2013-01-28

[] Trema Day #1でOpenFlow 1.3について思ったこと

f:id:oraccha:20130128100658j:image

Trema Day #1に参加した。まったりとした雰囲気の中、Tremaに限らずSDN関連のいろんな発表聴けて休日を潰しても十分元を取れた。その中でOpenFlow 1.3の話がいくつか出てきたので、まとめておきたいと思う。当日の様子はust録画されているとのことなので、まだ視聴できると思う。

1.0から1.3への変更について、機能レベルでIPv6やMPLS、PBBなどに対応したというのはあちこちで耳にするので、ここでは踏み込まない。グループやQoSのあたりも、具体的にどう使うのかいまいち分かっていないし。個人的には予想以上にプロトコルが変わっているという印象を強く受けた。詳しくは後で書くけど、packet inに関わる部分は特に変わりすぎじゃないかな。現実に即すように変更されたのだとは思うけど。Trema開発の中心人物である須堯さんは、1.0と1.3の互換性を取りながらコントローラを作るのは無理じゃないかとおっしゃっていた。このレベルの変更をあの頻度にやられると、確かにベンダは着いて来られないよな。1.3で仕様策定をペースダウンしましょうというONFの判断は納得できる。

packet inはOpenFlowがもたらす柔軟性の肝である。OpenFlowが出てきたとき、フローテーブルはproactiveにもreactiveにも設定できるけど、packet inを使ってreactiveにやるのがOpenFlow流みたいに私は受け取った。その後、本当にそうなのかなと悶々としていたけど、ComSys 2012で藤田@NTTさんが「packet inしたら負け」というのを講演冒頭からおっしゃっていて、スッキリした。OpenFlowだから何でもできるわけじゃなくて、適用できる範囲というものが徐々に明らかになってきたのだろう。OpenFlowの仕様もそれに合わせて変わってきたのだと思う。@tsuboiさんによると、クラウド/通信事業者がOpenFlowを適用するときの動機として、運用の自動化が大きい。reactiveでは、自動化の阻害要因になりかねないので、proactiveを中心にしたアーキテクチャとして検討され直したのだろうとのことである。なるほど。

まず1.3になると、デフォルトではpacket inはコントローラに上がってこない。これは結構衝撃的だった。packet inが必要な場合は、コントローラが明示的にflow modで設定する必要がある。packet inに付属する情報も(後述するように)変わっていて、肥大化の傾向にある。当然コントローラの負荷は増える。そこでセキュアチャネル以外に、Auxiliary Connections(これはUDP?)を使って、packet inをオフロードしようという話もあるようだ。また、1.0のflow modはマッチしたらアクションを実行するという単純なものだったが、インストラクションが入って、アクションをパイプライン化することが可能になった。会場からは本当にハードウェア化できるのか、やるなら何段?という質問も出ていた*1

あとはスイッチのポート情報がfeatures replyで上がってこないので、自力で検索する必要があるとか。たぶん大規模データセンタでの運用を見据えた変更だろうけど、Tremaアプリを書く人は気をつける必要がある。

話は変わるが、OpenFlow対抗?として、JuniperやCiscoらがIETFで標準化を進めているI2RS (Interface to the Routing System)ワーキンググループの動向も気になる。何でもプログラマブルに対する揺り戻しとして、どのあたりに着地点を設定してくるのだろうか。

ちなみに上の写真は懇親会でもらったTrema Tシャツ。packet_in構造体の定義がなぜTrema?と思ったら、Trema独自の抽象化が入っているので、Open vSwitchのものとは違うそうだ。TシャツにもあるTremaの定義(src/lib/openflow_application_interface.h)は次の通り。

typedef struct {
  uint64_t datapath_id;
  uint32_t transaction_id;
  uint32_t buffer_id;
  uint16_t total_len;
  uint16_t in_port;
  uint8_t reason;
  const buffer *data;
  void *user_data;
} packet_in;

これに対して、Open vSwitchの定義(include/openflow/openflow-1.0.h)ではこうなる。

struct ofp10_packet_in {
    ovs_be32 buffer_id;     /* ID assigned by datapath. */
    ovs_be16 total_len;     /* Full length of frame. */
    ovs_be16 in_port;       /* Port on which frame was received. */
    uint8_t reason;         /* Reason packet is being sent (one of OFPR_*) */
    uint8_t pad;
    uint8_t data[0];        /* Ethernet frame, halfway through 32-bit word,
                               so the IP header is 32-bit aligned.  The
                               amount of data is inferred from the length
                               field in the header.  Because of padding,
                               offsetof(struct ofp_packet_in, data) ==
                               sizeof(struct ofp_packet_in) - 2. */
};

なるほど、datapath_id、transaction_id、user_dataあたりがTremaでは追加されている。ちなみにOpenFlow 1.3ではtable_inやcookieが追加され、in_portが削除されている。packet_inでin_portはわからないのでmatchを検索しろと言うことらしい。

Open vSwitchのmasterブランチにはopenflow-1.3.hは含まれているけど、次のlong term supportになる1.9系ではOpenFlow 1.3は対応されないらしい。OpenFlow 1.3対応がそろってくるのはもう少し先になるのかな。Tremaが1.1と1.2を飛ばして1.3対応したことに対して、会場では概ね納得という反応だった。Pica8は最近のUpdate(PicOS 1.6)でOpen vSwitch 1.7.1ベースになり、OpenFlow 1.2対応と刻んできた。AcctonもOpenFlow 1.2対応と言っていたはず(AcctonのスイッチもOpen vSwitchベースなのかな?)。その辺にはいろいろ大人の事情があるんだろう。

Trema edgeが正式リリースされれば、packet_inの定義も1.3対応されるので、新しいTシャツが作られるとのこと。Trema DayでLTしたり、Tremaにパッチを投げたりしたら、Tシャツもらえるかも。ちなみにTrema Dayは、今後も3ヶ月に一度ぐらいの頻度で開催予定ということだ。

個人的にはOpenFlowの仕様書を一度真面目に読んでみようと思った。

(追記)はてブにPlan9日記なのにPlan 9について書かれていないじゃないかみたいなことが書かれていたので、ちょっとだけ蛇足。Trema Dayの懇親会でPlan 9とacmeの話が出ていたらしい。次回は宴会芸として、acmeへの愛を語りたい!?

*1:ONFの仕様策定方法についても話題に上った。スタンフォード大学が音頭を取っていた1.0までは、実装がないと標準化しないというポリシだった。しかし、ONF設立後、実装がないまま1.1がなし崩し的にリリースされてしまうと、それが慣習となってしまった。ONF内の力関係がどうなっているか知らないけど、ハードウェアベンダよりもNiciraのようなソフトウェアベンダの力の方が強く、ハードウェア化が困難なものも入ってしまうのかなと思ったり。

2012-11-12

[] スパコンとは何か

SC2012に向けての機内で金田先生の「スパコンとは何か」を読んだ。2009年の京、そして2011年のHPCIの事業仕分けに仕分け人として関わった東大情報基盤センタの金田先生によるスパコン解説本である。京はLLNLのSequoia (BG/Q)に抜かれてTOP500の2位になったが、今回のTOP500の目玉はORNLのTitan (Cray XK7)。TitanはOpteron + GPUというアーキテクチャで、ピーク性能は20PFLOPSと言われている。一般的にGPUの実効性能は高くないけど、NVIDIA Tesla K20xはDGEMMでも結構いい性能が出るらしいし、当然1位を狙ってくるはずだ。

さて、本書は以前取り上げた姫野さんと同様にスパコン啓蒙本なのだが、京のお膝元と仕分け人という立場の違いがある。私は金田先生がなぜ京にダメ出ししたのか、その背景にどんな問題提起があったのかしか興味がなかったのだが、結局、京の何が問題だったかというのは漠然としか書かれていない。同業者から相当叩かれたのではと想像するし、外野としてはその辺のことをぶちまけてもらいたかったのだが、やっぱりそれは無理らしい。京で一時的にLINPAC性能1位になっても、元々プロジェクトが掲げていた目標(1)スーパーコンピューター技術の伝承、(2)競争環境を用意すること、(3)スーパーコンピューター設置環境の整備、(4)人材育成の継続性は達成できないだろう。だから一度立ち止まって計画を立て直すべきということらしい。(2)に関して、米国では常に複数の国プロが走っているが、日本では地球シミュレータ、京のように単発である。これでは厳しいというのは同感。幸いTSUBAMEやT2Kがそれを補っている面はあるが。米国流のマッチングファンドは参考になるか? また、10PFLOPSのフラグシップを1台作るのではなく、1PFLOPSマシンを10台各大学・企業に作って競争する方が、よっぽど安上がりで業界の発展に貢献すると主張する。日本において中規模スパコンの層が薄いのは、計算機の低価格化と個々の研究者に割と潤沢な予算があることで、こまごました計算機ばかりが増えている事情があると言う。それらを数100TFLOPS規模の計算機に集約して、計算機センターの役割を再考するというのはありかも。でも、現実的には7大学以外の計算機センターはもう成り立たなくなっているのだろうか? HPCIにぶら下がるのでもいいだろうし、いっそEC2などのクラウドでいいのかも。どちらにしろ、ヨーロッパ(や韓国)のように、スパコン開発はあきらめ、コストパフォーマンスのよい計算機を買ってきて、自分たちはソフトウェアの開発に注力するというのは一つのモデルである。わからないことはないけど、ここでレールから降りると、2度と復活できないのではないだろうかという危惧を感じる。走りながら考える必要があるのではないか。

そのほか、教科書ではなかなか知ることができない政治的な事情も書かれていて、その点を面白く思う人がいるかもしれない。7大学計算機センターの生い立ちとか、政府調達でスパコンの定義が1.5TFLOPSに定められている理由とか。スパコンを持っている大学は限られているし、コミュニティの近くにいないとこの辺の事情は(調べようと思えば調べられると思うが)わからない、というか、そもそも興味も持たないか。

話は変わるが金田先生には専門の円周率計算を中心に計算機の歴史について語る本を書いてもらいたい。HITAC 5020、SR2201、SR8000とか日立中心になりそうだけど。

あぁ、時差ぼけのぼ〜っとした頭で文章がまとまらないが、この辺で。

関連:

(追記:2012-11-12)最新のTOP500が発表になり、Titanが17.59PFLOPS(ピークは27PFLOPS強)で1位になった。これで京は3位。噂によると今回はGPUしか使ってないらしいし、実行時間も1時間未満だったとか。ノミネートにギリギリ間に合ったという感じなのかな。

スパコンとは何か (ウェッジ選書46)

スパコンとは何か (ウェッジ選書46)