こんにちは。@jedipunkz です。 毎度お馴染みになった OpenStack の Chef によるデプロイですが、今回は OpenStack Havana 構成を Chef でデプロイする方法についてです。使用するのは今回も rcbops/chef-cookbooks です。ブランチは ‘havana’ を用います。 早速ですが構成について。4.1.2 辺りからだと思うのですが構成の前提が物理ネットワー ク4つを前提にし始めました。public, external (VM) を別ける必要が出てきました。 通信の特性も異なるので (public は public API を。external は VM 用) 、別けるの が得策かもしれません。 構成 +--------------+------------------------------------------------------- external | | +--------------+--(-----------+--(-----------+--------------+---------------------------- public | | | | | | | +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ | controller | | network | | network | | compute | | compute | | workstation| +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ | | | | | | | | | | +--------------+--(-----------+--(-----------+--(-----------+--(-----------+------------- management | | | | +--------------+--------------+--------------+------------------------- guest 上記の構成の特徴 4つの物理ネットワークを前提 public ネットワーク : 外部 API 用ネットワーク external ネットワーク : インスタンス外部接続用ネットワーク guest ネットワーク : インスタンス内部用ネットワーク management ネットワーク : 各コンポーネント接続用ネットワーク public, external のみグローバルネットワーク controller : 2 nics, network : 4 nics, compute : 3nics の構成 controller はシングル構成 network ノードは台数拡張可能, agent 単位でノード間移動可能 compute ノードも台数拡張可能 workstation は chef-repo の所在地, management ネットワークに所属 各ノードの準備 OS インストール後、各ノードのネットワークインターフェースの設定を下記の通り行っ てください。また LVM を使うのであれば cinder ボリュームの設定も必要になってきます。 ...

こんにちは。@jedipunkz です。 第2回 Elasticsearch 勉強会に参加してきました。箇条書きですが参加レポートを記し ておきます。 開催日 : 2013/11/12 場所 : 東京駅 グラントウキョウサウスタワー リクルートテクノロジーズさま URL : http://elasticsearch.doorkeeper.jp/events/6532 Routing 周りの話 株式会社シーマーク　大谷純さん (@johtani) Index 構成 cluster の中に index -> type が作成される index は shard という部分的な index の集まり shard 数は生成時のみ指定可能 node ごとに replica, primary を別ける replica 数は後に変えられる doc -> hash 値を shard 数で割って replica, primary に登録 doc の id の ハッシュ値を利用 type も含める場合はかの設定を true に クライアントはどのノードに対してクエリを投げても OK routing id の代わりに routing (URL パラメータ) で登録 url リクエストパラメータとして登録時にルーティングパラメータを登録 id の代わりにパラメータで指定された値のハッシュ値を計算して利用 検索時 routing 指定で関係のある shard のみを指定出来る スケールアウト sharding によるスケールアウト数 = インデックス作成時に指定 shard によるインデックスの分割以外にインデックス自体を複数持つことによるスケール 複数のドキュメントをエイリアス書けることが可能 所感 個人的には非常に興味のあるところでした。mongodb のような sharding をイメージし てよいのか？そうでないのか？すら理解出来ていなかったので。sharding を理解する 前提知識の話もあって非常に参考になりました。 ...

こんにちは。@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 が稼働するまでの流れ 上記の構成の図を見ながら理解していきましょう。 ...