こんにちは。@jedipunkz です。 僕は Chef 使いなのですが、Chef はオーケストレーションまで踏み込んだツールでは ないように思います。せいぜいインテグレーションが出来る程度なのかなぁと。 しかもインテグレーションするにも Cookbooks の工夫が必要です。以前聞いたことの ある話ですが Opscode 社のエンジニア曰く「オーケストレーション等へのアプローチ はそれぞれ好きにやってね」だそうです。 個人的にオーケストレーションをテーマに色々調べようかと考えているのですが、 Serf という面白いツールが出てきました。‘Serf’ はオーケストレーションを手助けし てくれるシンプルなツールになっています。 もう既にいろんな方が Serf について調べていますが、どのような動きをするのかを自 分なりに理解した点を記しておこうと思います。 参考にしたサイト 公式サイト http://www.serfdom.io/ クラスメソッド開発者ブログ http://dev.classmethod.jp/cloud/aws/serf_on_ec2/ Glidenote さん http://blog.glidenote.com/blog/2013/10/30/serf-haproxy/ Serf とは Serf は gossip protocol をクラスタにブロードキャストする。gossip protocol は SWIM : Scalable Weakly-consistent Infecton-style process Group Membership Protocol” をベースとして形成されている。 SWIM Protocol 概略 serf は新しいクラスタとして稼働するか、既存のクラスタに ‘join’ する形で稼働 するかのどちらかで起動する。 新しいメンバは TCP で状態を ‘full state sync’ され既存のクラスタ内にて ‘gossipin (噂)される。この ’gosiping’ は UDP で通信されこれはネットワーク使 用量はノード数に比例することになる。 ランダムなノードとの ‘full state sync’ は TCP で行われるけどこれは ‘gossiping’ に比べて少い ...

こんにちは。@jedipunkz です。 以前、“Swift HA 構成を Chef でデプロイ” というタイトルで記事を書きました。 http://jedipunkz.github.io/blog/2013/07/26/swift-ha-chef-deploy/ こちらですが、Swift-Proxy, MySQL, Keystone をそれぞれ haproxy, keepalived で HA 組みました。ですが、これは実用的なのかどうか自分でずっと考えていました。 MySQL と KeepAlived はできればシングル構成にしたいのと、Swift-Proxy は HA で組 みたい。MySQL は Master/Master レプリケーション構成になり、どちらかのノードが 障害を起こし万が一復旧が難しくなった時、構築し直しがしんどくなります。かと言っ て Swift-Proxy をシングル構成にすると今度はノード追加・削除の作業時にサービス 断が発生します。Swift-Proxy を再起動書ける必要があるからです。なので Swift-Proxy は引き続き HA 構成にしたい。 もう一点、見直したいと思っていました。 日経コンピュータから出版されている “仮想化大全 2014” の記事を読んでいて 気がついたのですが。Swift には下記の通りそれぞれのサーバがあります。 swift-proxy-server swift-account-server swift-container-server swift-object-server Swift には下記のような特徴がある事がわかりました。 swift-object swift-object は swift-accout, swift-container とは物理リソースの扱いに全く異な る特性を持っています。swift-account, swift-container はクライアントからのリクエ ストに対して “アカウントの存在を確認”, “ACL 情報の確認” 等を行うサーバであるの に対して swift-object はストレージ上のオブジェクトをクライアントに提供、または 逆に格納するサーバです。よって、Disk I/O の利用特性として swift-account, container は SSD 等、高スループットの Disk を利用するケースが推奨されるのに対 して swift-object はオブジェクトの実体を格納する必要があるため Disk 容量の大き なストレージを要する。 ...

こんにちは。@jedipunkz です。 前回、OpenStack と test-kitchen を使った環境構築方法を書きました。下記の記事で す。 http://jedipunkz.github.io/blog/2013/10/13/test-kitchn-openstack-chef-cookbooks-test/ 今回は実際にテストを書く方法を記していたい思います。 今回使用するテストツールは下記の2つです。 rspec と serverspec busser-bats 参考資料 Creationline lab さんの資料を参考にさせて頂きました。 http://www.creationline.com/lab/2933 用意するモノ達 OpenStack にアクセスするためのユーザ・パスワード Keystone の AUTH_URL テストに用いる OS イメージの Image ID テナント ID nova 管理のキーペアの作成 これらは OpenStack を普段から利用されている方なら馴染みのモノかと思います。 .kitchen.yml ファイルの作成 下記の通り .kitchen.yml ファイルを test-kitchen のルートディレクトリで作成しま す。今後の操作は全てこのディレクトリで作業行います。 “<>” で括った箇所が環境に合わせた設定になります。 また、ここでは前回同様に ’ntp’ の Cookbook をテストする前提で記します。 +++ driver_plugin: openstack suites: - name: default run_list: - recipe[ntp::default] attributes: {} platforms: - name: ubuntu-12.04 driver_config: openstack_username: <openstack_username> openstack_api_key: <openstack_password> openstack_auth_url: http://<openstack_ip_addr>:5000/v2.0/tokens image_ref: <image_id> flavor_ref: 1 key_name: <key_name> openstack_tenant: <tenant_name> username: <ssh_username> private_key_path: <path_to_secretkey> - name: centos-64 driver_config: openstack_username: <openstack_username> openstack_api_key: <openstack_password> openstack_auth_url: http://<openstack_ip_addr>:5000/v2.0/tokens image_ref: <image_id> flavor_ref: 1 key_name: <key_name> openstack_tenant: <tenant_name> username: <ssh_username> private_key_path: <path_to_secretkey> busser-bats テスト +++ ...

こんにちは。@jedipunkz です。 test-kitchen + Vagrant を利用して複数環境で Chef Cookbooks のテストを行う方法は 結構皆さん利用されていると思うのですが Vagrant だと手元のマシンに仮想マシンが バシバシ立ち上げるので僕はあまり好きではないです。そこで、OpenStack のインスタ ンスをその代替で使えればいいなぁと結構前から思っていたのですが、今回うまくいっ たのでその方法を記します。 用意するモノ OpenStack 環境一式 Chef がインストールされた OS イメージとその ID test-kitchen を実行するワークステーション (お手持ちの Macbook 等) OS イメージの作成ですが Veewee などで自動構築できますし、インスタンス上で Chef のインストールを行った後にスナップショットを作成してそれを利用しても構いません。 test-kitchen のインストール test-kitchen をインストールします。versoin 1.0.0 はまだリリースされていないの で github から master ブランチを取得してビルドします。直近で OpenStack に関連 する不具合の修正等が入っているのでこの方法を取ります。 % git clone https://github.com/opscode/test-kitchen.git % cd test-kitchen % bundle install % rake build # <--- gem をビルド % gen install ./pkg/test-kitchen-1.0.0.dev.gem 現時点 (2013/10/13) で berkshelf の利用しているソフトウェアと衝突を起こす問題 があるので bundle で解決します。下記のように Gemfile に gem ‘kitchen-openstack’ と記述します。 ...

こんにちは。@jedipunkz です。 GlusterFS をちょっと前に調べてました。何故かと言うと OpenStack Havana がもうす ぐリリースされるのですが、Havana から GlusterFS がサポートされる予定だからです。 この辺りに色々情報が載っています。 http://www.gluster.org/category/openstack/ その前に GlusterFS を構築出来ないといけないので、今回はその方法を書いていきま す。各クラスタタイプ毎に特徴や構築方法が異なるのでその辺りを重点的に。 環境 Ubuntu Server 12.04.3 LTS PPA レポジトリ利用 /dev/sdb を OS 領域とは別の disk としてサーバに追加する 用いる PPA レポジトリ Ubuntu 12.04.3 LTS の GlusterFS バージョンは 3.2 です。3.4 系が今回使いたかっ たので下記の PPA レポジトリを利用させてもらいます。ちゃんと構築するなら自分で パッケージを作成することをオススメします。 https://launchpad.net/~semiosis/+archive/ubuntu-glusterfs-3.4 準備 ここからの手順は全てのサーバで操作します。 レポジトリの利用方法 % sudo aptitude install python-software-properties % sudo add-apt-repository ppa:semiosis/ubuntu-glusterfs-3.4 % sudo apt-get update GlusterFS3.4 のインストール % sudo apt-get install glusterfs-server gluserfs-client xfsprogs のインストール glusterfs は xfs を扱うため xfsprogs をインストールする。 ...

こんにちは。@jedipunkz です。 Mesos アーキテクチャについて2つめの記事です。 http://jedipunkz.github.io/blog/2013/09/28/mesos-architecture-number-1/ 上記の前回の記事で Mesos 自体のアーキテクチャについて触れましたが、今回は Mesos + Marathon + Docker の構成について理解したことを書いていこうと思います。 mesos クラスタは 幾つかの mesos masters と沢山の mesos slaves から成っており、 mesos slaves の上では docker を操作する executor が稼働している。marathon は mesos master の上で稼働する mesos framework である。init や upstart の様な存在 であることが言え、REST API を持ち container の動作を制御する。marathon には ruby の client 等も存在する。下記がそれ。 https://github.com/mesosphere/marathon_client 構成 +-----------------+ | docker registry | index.docker.io (もしくは local registry) +-----------------+ | +----------------+ | | +--------------+ +--------------+ | mesos master | | mesos master | +--------------+ +--------------+ | | |----------------+-----------------------------------| +--------------+ +--------------+ +--------------+ | mesos slave | | mesos slave | ... | mesos slave | +--------------+ +--------------+ +--------------+ | | | +--------------+ +--------------+ +--------------+ | mesos slave | | mesos slave | ... | mesos slave | +--------------+ +--------------+ +--------------+ . . . . . . . . . +--------------+ +--------------+ +--------------+ | mesos slave | | mesos slave | ... | mesos slave | +--------------+ +--------------+ +--------------+ オファから docker が稼働するまでの流れ 上記の構成の図を見ながら理解していきましょう。 ...

こんにちは。@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 の人は結構「データをどこそこの部署に見せても理解してもらえない」 だとか「データを閲覧させると万が一の時にシステムが破損する」等と考えがち。が、 ビジネス寄りの人にとって重要なグラフが含まれていたり、アカウント担当の人に役立 つものも含まれている。ましてシステムが破損することなど決して無い。 ...

こんにちは。@jedipunkz です。 今回はクラスタマネージャである Mesos について書こうと思います。 Mesos は Apache Software Foundation によって管理されるソフトウェアで分散アプリ ケーションをクラスタ化することが出来るマネージャです。Twitter が採用しているこ とで有名だそうで、開発にも積極的に参加しているそうです。 http://mesos.apache.org/ @riywo さんが既に Mesos + Marathon + Zookeper + Docker な構成を組む手順をブロ グで紹介されていますので是非試してみると面白いと思います。 http://tech.riywo.com/blog/2013/09/27/mesos-introduction-1/ 私は理解した Mesos のアーキテクチャについて少し書いていきたいと思います。 全体の構造 +-----------+ | zookeeper | | quorum | +-----------+ | +----------------+----------------+ | | | +--------------+ +--------------+ +--------------+ | mesos-master | | mesos-master | | mesos-master | | active | | hot standby | | hot standby | +--------------+ +--------------+ +--------------+ ... | +----------------+----------------+ | | | +--------------+ +--------------+ +--------------+ | mesos-slave | | mesos-slave | | mesos-slave | | executor | | executor | | executor | | +----++----+ | | +----++----+ | | +----++----+ | | |task||task| | | |task||task| | | |task||task| | | +----++----+ | | +----++----+ | | +----++----+ | +--------------+ +--------------+ +--------------+ ... 基本的に few masters + many slaves の構成です。task は slaves の上で走ります。 master はオファーによりアプリケーション(フレームワーク)に対して CPU, メモリの リソースをシェア出来ます。リソースは slave ID, resource1: amount1, resource2, amount2, … といった配列を含みます。master はポリシに従いそれぞれ のフレームワークに対してリソースをどれだけ提供するか決定します。プラグイン形式 で様々なポリシを取り込む仕組みになっています。 ...