report

1 minute read

こんにちは。@jedipunkz です。

今日、JTF2014 (July Tech Festa 2014) というイベントで Ceph のことを話してきま した。Ceph ユーザ会の会員として話してきたのですが Ceph ユーザ会は実は最近発足 したばかりのユーザ会で、まだまだ活動が活発ではありません。もし興味がある方いらっ しゃいましたら是非参加よろしくお願いしますー。下記の Google Groups になります。

https://groups.google.com/forum/#!forum/ceph-jp

ユーザ会としての勉強会として初になるのですが、今回このイベントで自分は Ceph-Deploy について話してきました。とりあえず皆さんに使ってもらいたかったので この話をしてきました。が、予定時間がメチャ短かったので超絶早口で頑張った分、皆 さんに理解してもらえなかった気がしてちょっと反省…。なので、このブログを利用 して少し細くさせてもらいます。

今日の発表資料はこちらです!

今日のテーマは 「Ceph-Deploy を使って Ceph を構築してみる」だったのですが、下 記のテーマを持って資料を作っています。

  • 単にミニマム構成ではなく運用を考慮した実用性のある構成
  • OSD, MON, MDS の各プロセスとノード・ディスクの数の関係を知ってもらう

特に「実用性のある..」は意識したつもりでした。そのために前提とした構成に下記の 特徴を持たせています。(資料 6 ページ目に構成図があります。確認してみてください。)

  • オブジェクト格納用ディスクは複数/ノードを前提
  • OSD レプリケーションのためのクラスタネットワークを用いる構成
  • OSD の扱うジャーナル格納用ディスクは高速な SSD を用いる
  • MDS は利用する HW リソースの特徴が異なるので別ノードへ配置

ストレージ全体を拡張したければ

  • 図中 ceph01-03 の様なノードを増設する
  • ceph01-03 にディスクとそれに対する OSD を増設する

ですが、前者がベストでしょう。ノード増設の場合 ceph-deploy を用いて

  • ceph-deploy mon create <新規ホスト名> で MON を稼働
  • ceph-dploy disk zap, osd create で OSD を稼働

で簡単に可能です。MDS の増設も負荷状況を見ながらするといいでしょう。自分はまだ Ceph を運用していないので、各プロセスがどのようなリソースの消費の仕方をするの か知りません。MDS がどのような数で運用していくべきなのか。早く運用から得たノウ ハウが共有されないかなぁと期待しています。

また今回話すのを忘れたのですが SSD をジャーナル格納用ディスクとして用いたのは ハードディスクに対して高速でアクセス出来ること・またメタデータはファイルオブジェ クトに対して小容量で済む、といった理由からです。メタデータを扱うのに適している と思います。また将来的には幾つかの KVS データベースソフトウェアをメタデータ管 理に使う実装がされるそうです。

以上です。皆さん、是非 Ceph を使ってみてください! また興味のある方はユーザ会 への加入をご検討くださいー。

1 minute read

こんにちは。@jedipunkz です。

昨晩、第17回 OpenStack 勉強会が開催されました

http://connpass.com/event/4545/

ここで発表をしてきましたぁ!発表タイトルは “rcbops/chef-cookbooks” です。

何を発表したかと言うと詳しくは上記のスライドを見ていただくとして、簡単に言うと “RackSpace 社のエンジニアが管理している Chef Cookbooks でOpenStack 構成を作ろ う” ってことです。

今日知ったのですがどうも昨晩は初心者向けの勉強会という位置付けだったらしく..少 しだけディープな話題を話してしまったかもしれません!すいません!><

でもとても楽しく発表出来ましたし、逆に質問のコーナーで最新の情報も教えてもらえ たり!なんと Havana 対応の v4.2.0 以降では Swift の Cookbooks が消えてしまった とか!… 皆 Swift 好きくないの?…; ;

rcbops/chef-cookbooks はずっと追っていますが、ものすごいスピードで開発進んでい るので、今後ぜひみなさん使ってみて下さいー。

最後に詳しい利用方法を記した僕のブログの URL を貼り付けておきます。

  • OpenStack Havana を Chef でデプロイ

http://jedipunkz.github.io/blog/2013/11/17/openstack-havana-chef-deploy/

  • Swift HA 構成を Chef でデプロイ

http://jedipunkz.github.io/blog/2013/07/26/swift-ha-chef-deploy/

  • 実用的な Swift 構成を Chef でデプロイ

http://jedipunkz.github.io/blog/2013/10/27/swift-chef/

3 minute read

こんにちは。@jedipunkz です。

DevOps Day Tokyo 2013 に参加してきました。たくさんの刺激を受けたのでレポート書 いておきます。

開催日 : 2013年09月28日
場所   : 東京六本木ミッドタウン Yahoo! Japan さま
URL    : http://www.devopsdays.org/events/2013-tokyo/

Making Operation Visible

Nick Galbreath (@ngalbreath) さん

DevOps の拠点 Etsy に努めた経緯のある DevOps リーダ Galbreath さん。DevOps の 概略から何が必要でありどう行動に起こせばよいか説明してくださいました。

Making operations visible - devopsdays tokyo 2013 from Nick Galbreath

こちら、Galbreath さんの当日の資料。

DevOps が実行出来ない理由

  • Tool が足りない
  • 社風の影響
  • 見えないモノが価値がないと事業から考えられている

出来る事は、価値があるモノの社内への説明と、Tool を使った可視化。データの可視 化が重要。Ops の人は結構「データをどこそこの部署に見せても理解してもらえない」 だとか「データを閲覧させると万が一の時にシステムが破損する」等と考えがち。が、 ビジネス寄りの人にとって重要なグラフが含まれていたり、アカウント担当の人に役立 つものも含まれている。ましてシステムが破損することなど決して無い。

重要なのは “運用のメトリクスを公開する” こと!

Graphite

  • グラフ描画ツール
  • まず完成度が高いわけではない
  • 同類のソフトウェアでは行えないクエリが発行出来る
  • REST API
  • Flexible Input & Output
  • Simple UI & Dashboard
  • 3rd Party Custom Client Side Dashboard あり
  • URL 型なので Dashboard 開発が楽ちん
  • 稼働させるための物理インフラリソースは結構必要
  • apt-get install graphite できるよ

statd

  • UDP 使ってる
  • Event Data を Application から statd へ

下記は例。ログイン情報を送るためのコードはこれだけ。

StatD::increment('logins')

国別にも出来る。

StatD::increment('logins');
$kuni = geoip2country($ipv4);
StatD::increment('logins.$kuni')

後に DataDog の方から詳しく説明がある。

Sensu

Sean Porter さん

メモとりにくいプレゼンだったので思い出しながら….

Sensu は Nagios のプラグイン等がそのまま再利用できる監視ツール。API を介してア ラートの具合やクライアントのリスト・監視項目のリスト等が取得できます。Nagios を使った場合、ターゲットノードの追加のたびにコンフィギュレーションを生成しなく てはならなかったり不便だったのが Sensu を開発しようとした動機だとか。Chef との 親和性が高く、Chef Cookbook の公開もしている。私も実際に使っていますが、

  • Sensu サーバの構築
  • 監視項目の追加
  • ターゲットノードへのアージェントの追加

等はすべて Chef の Knife コマンドで出来ます。特に Chef からの影響だと思われる が Omnibus 形式のパッケージを採用していることもあり、エージェントのインストー ルは簡単です。パッケージの中に動作に必要な Ruby 一式も含まれています。

ドキュメントは下記のところにあります。

http://docs.sensuapp.org/0.10/index.html

puppet

max martin

for next level +++

  • Puppet 3.x
  • Hiera integration
  • PuppetDB
  • Mcollective 2.x
  • Geppetto : IDE
  • Puppet Forge : web site

Puppet が提供するソフトウェアやサービス達。DevOps の次のステップへの必要な技術 要素。

puppet 3.x

  • pupput2 に比較して speedup x 3
  • agents/server : 100% up
  • これらは理論値ではなく実効値!

Puppet2 と比較してかなりの性能アップらしい。処理速度3倍は実効値だそうです。

puppet3.0 = hiera functions + data bindings

  • hiera : hierarchical key value store with pluggable backend (json, yaml..)
  • keep site specific data out of puppet code
  • parameter values are now automatically looked up in hiera
  • data bind でコードがシンプルに : include ntp -> yaml, json..

json や yaml でパラメータを記述出来るのでコードがシンプルで綺麗になるよ、との こと。Chef でいう Attributes だと思われる。

puppetdb

  • puppet データすべてを格納 (facts, catalogs, reports,..)
  • replaces existing library is much faster and more faster
  • postgreSQL, Clojure, JVM -> JAR ファイルで展開
  • クエリシンタックスを自ら定義可能
  • API がシンプルなので dashboard などの開発も簡単

PostgreSQL が最近あちらの国ではイケてるっていう話はよく聞いていたけど Puppet3 は PostgreSQL, Clojur, JVM の組み合わせで構成されているらしい。Chef も Erlang に置き換わったあたりを見ての反応かなぁ?と想像。

MCollective

  • orchestration engine
  • ruby を使って独自のエージェント開発可能
  • mco rpc service restart service=httpd –nodes=hosts.txt # query a file
  • mco rpc service restart service=httpd -W country=uk -dm=puppetdb # discover
  • mco rpc rpcutil ping -I example.com # direct addressing
  • ruby のライブラリとして利用可能

query a file のサンプル

c = rpcclient("service")
c.discover :nodes => File.readline("host.txt").map {|i| i.chomp}
printrpc c.restart(:service => "httpd")

これはオーケストレーションツール。ホスト名の記述されたファイルから、それらのホ ストに対して一斉に指示を送ったり検索を行ったりコマンドの実行が出来る。これは Ruby ライブラリとして再利用出来るらしい。これは便利。

Geppetto

  • IDE for developing puppet modules and code
  • git & svn
  • Linux, Mac OSX, Windows

Linux, Mac, Windows 用の IDE まで提供してるんですね。驚き。Puppet ものすごい勢 い。

Puppet Forge

  • module repository
  • 1,500+ modules
  • puppet module install foo/foo
  • module のためのチームが内部にある

コミュニティの作ったモジュールを公開しているレポジトリ WEB サービス。1,500 以 上のモジュールが公開されているらしい。このためのチームも Puppet 社内にいるとか。

迷ったら健全な方を

Cookpad Naruta Issei さん

印象的なプレゼンでした。

現実に起こった問題を切り口に Devops について語っていました。リリース日当日 Ops が「今日リリースだと初めて知る」という事件。繰り返さないためにどうするか?

  • リリース日の決定に Ops の承認が必要なルールにする?
  • Ops 「ソースコードが fix してからリリース日まで3営業日必要?」

このようなルールを作りがちだけど、これでは Ops が権威になってしまう。Ops の立 場からしてこの「権威」になりやすいという特徴があるが、Ops はそう振る舞ってはい けない!という話。DevOps に必要なコミュニケーションで回避出来ると。DevOps であ る限り仕事は楽しくなくてはならない。承認を取るテクニック・政治が発生するのもこ れまた問題。

Cookpad はこれからもコミュニケーションでこういった問題をクリアしていく!と宣言 がありました。最後は若干 Ops 避難のようなプレゼンを Ops の前でするかのような状 況に Issei さんも声を震わせながらのプレゼンでしたが、逆にそれが僕には響きまし た。ぼくも Ops 出身だし、こういった問題は嫌になる程見てきているので、この訴え かけはガツンときた。プレゼン最高でした!

DataDog

Alexis Lê-Quôc さん

監視ツールにとっての重要な要素

  • Timely
  • Correct
  • Comprehensive (包括的)

これらを満たせなければ全く無駄。

  • 前提条件を元にメトリクスを決めている -> 不完全なメトリクスが多い
  • -> 最低限の条件でメトリクスに要素を追加できることが重要だと考える

statd types

  • gauges
  • counters
  • histgrams
  • timers
  • sets

参考資料

statd と graphite の連携

https://github.com/etsy/statsd/blob/master/docs/graphite.md

サポートされているバックエンド一覧

https://github.com/etsy/statsd/blob/master/docs/backend.md

まとめ

とても有意義だった。丸一日、最後まで聞いているのも辛かったけど、運営されている 側の方々はもっと大変だったでしょう。ありがとうございました。日本ではなかなか話 を聞けないめちゃホットな方々の話を直に聞けるなんて無いのでホント貴重でした。ま たディスカッションには参加出来なかったけど、久しぶりに会えた方がいてめちゃ良かっ たです。同じ方向向いている方々がこれだけ社外には居るんだという気付きもあったり。

皆さん、ありがとうございました!