こんにちは。@jedipunkz です。 またまた OpenStack のデプロイをどうするか？についてです。 今まで自分の中では Rackspace Private Cloud で使われている Rackspace 管理の rcbops/chef-cookbooks が今現在使うならベストの選択だと思っていました。これは内 部で Chef が使われていてしかも Cookbooks が Github 上で公開されています。 Apache ライセンスで使えるので、サービス構築にも使えちゃうというモノ。 先日、ある OpenStack コアデベロッパーの方から「jedipunkz さん、やっぱり rcbops がいいですか？運営とかどうなっているんでしょう？マージの規準とかどうなのかな？」 と質問受けました。確かにマージの基準は Rackspace Private Cloud がベースになり ますし、管理しているエンジニアの一覧を見ていると Rackspace 社のエンジニアがメ インですし、今後どうなるのか分からない…。 逃げ道は用意したほうが良さそう。 ということで、以前自分も暑かったことのある StackForge の openstack-chef-repo を久々に使ってみました。Icehouse 構成がこの時点で既に組めるようになっていて、 以前よりだい〜ぶ完成度増した感があります。今回は nova-network 構成を作ってみた のですが、Neutron 構成ももちろん出来そうなので後に調べてまた公開したいです。 StackForge とは StackForge は OpenStack のデプロイ・CI の仕組みとして公式に用いられているもの。 公式サイトは下記の場所にある。 http://ci.openstack.org/stackforge.html StackForge の openstack-chef-repo は下記の場所にある。 https://github.com/stackforge/openstack-chef-repo openstack-chef-repo はまだ ‘stable/icehouse’ ブランチが生成されていない。が直 ちに master からブランチが切られる様子。 ...

こんにちは。@jedipunkz です。 皆さん、Mirantis OpenStack はご存知ですか？ OpenStack ディストリビューションの 1つです。以下、公式サイトです。 http://software.mirantis.com/main/ この Mirantis OpenStack を使って OpenStack Havana (Neutron GRE) 構成を作ってみ ました。その時のメモを書いていきたいと思います。 構成は? 構成は下記の通り。 ※ CreativeCommon 特徴は Administrative Network : Fuel Node, DHCP + PXE ブート用 Management Network : 各コンポーネント間 API 用 Public/Floating IP Network : パブリック API, VM Floating IP 用 Storage Network : Cinder 配下ストレージ <-> インスタンス間用 要インターネット接続 : Public/Floating Networks Neutron(GRE) 構成 です。タグ VLAN 使って物理ネットワークの本数を減らすことも出来るはずですが、僕 の環境では何故かダメだったので上記の4つの物理ネットワークを別々に用意しました。 Fuel ノードの構築 Fuel ノードとは、OpenStack の各ノードをデプロイするための管理ノードのことです。 DHCP + PXE を管理する Cobbler やデプロイツールの Puppet が内部で稼働し、 Administrative Network 上で稼働したノードを管理・その後デプロイします。 ...

こんにちは。@jedipunkz です。 今週 Redhat が ‘Redhat Enterprise Linux Atomic Host’ しましたよね。Docker を特 徴としたミニマムな OS だとのこと。その内部で用いられている技術 Geard について 少し調べてみました。複数コンテナの関連付けが可能なようです。ここでは調べた結果 について簡単にまとめていきます。 参考資料 http://openshift.github.io/geard/deploy_with_geard.html 利用方法 ここではホスト OS に Fedora20 を用意します。 まず Geard をインストール % sudo yum install --enablerepo=updates-testing geard 下記の json ファイルを作成します。ここにはコンテナをデプロイするための情報と関 連付けのための情報を記します。 $ ${EDITOR} rockmongo_mongodb.json { "containers":[ { "name":"rockmongo", "count":1, "image":"derekwaynecarr/rockmongo", "publicports":[{"internal":80,"external":6060}], "links":[{"to":"mongodb"}] }, { "name":"mongodb", "count":1, "image":"ccoleman/ubuntu-mongodb", "publicports":[{"internal":27017}] } ] } 上記のファイルの解説。 コンテナ ‘rockmongo’ と ‘mongodb’ を作成 それぞれ1個ずつコンテナを作成 ‘image’ パラメータにて docker イメージの指定 ‘publicports’ パラメータにてコンテナ内部とホスト側のポートマッピングを行う ’links’ パラメータで ‘rockmongo’ を ‘mongodb’ に関連付け では、デプロイ開始します。 ...

こんにちは！@jedipunkz です。 今回は Havana 版の OpenStack Glance, Cinder と分散ストレージの Ceph を連携させ る手順を書いていきます。元ネタはこちら。下記の Ceph の公式サイトに手順です。 https://ceph.com/docs/master/rbd/rbd-openstack/ この手順から下記の変更を行って、ここでは記していきます。 Nova + Ceph 連携させない cinder-backup は今のところ動作確認出来ていないので省く 諸々の手順がそのままでは実施出来ないので補足を入れていく。 cinder-backup は Cinder で作成した仮想ディスクのバックアップを Ceph ストレージ 上に取ることが出来るのですが、そもそも Ceph 上にある仮想ディスクを Ceph にバッ クアップ取っても意味が薄いですし、まだ動いていないので今回は省きます。LVM やそ の他ストレージを使った Cinder 連携をされている方にとっては cinder-backup の Ceph 連携は意味が大きくなってくると思います。 構成 下記の通りの物理ネットワーク6つの構成です。 OpenStack, Ceph 共に最小構成を前提にします。 +--------------------------------------------------------------------- external | +--------------+--(-----------+--------------+------------------------------------------ public | | | | | +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ | controller | | network | | compute | | ceph01 | | ceph02 | | ceph03 | +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ | | | | | | | | | | | | | | | | +--------------+--(-----------+--(-----------+--(--(--------+--(--(--------+--(--(------- management | | | | | | | | | | | +--------------+--(-----------(--(-----------(--(-----------(--(------- guest | | | | | | | | +--------------------------------+-----------+--(-----------+--(-----------+--(------- storage | | | +--------------+--------------+------- cluster 特徴 ...

こんにちは。@jedipunkz です。 追記 2014/03/20 : 一旦削除していた記事なのですが、無事動作が確認出来たので再度アッ プします！ 第17回 OpenStack 勉強会で rcbops/chef-cookbooks の話をしてきたのですが会場から 質問がありました。「Havana の Swift 構成を作る Cookbooks はどこにありますか？」 と。私が試したのが Grizzly 時代のモノで、よく rcbops/chef-cookbooks を見てみる と Havana ブランチ又は Havana に対応したリリースタグのファイル構成に Swift が 綺麗サッパリ消えているではありませんか・・！下記の Swift の Cookbooks は幸い github 上に残っていました。 https://github.com/rcbops-cookbooks/swift が rcbops/chef-cookbooks との関連付けが切れています・・。ぐあぁ。 ということで Havana 構成の Keystone 2013.2.2 と Swift 1.10.0 の構成を Chef で 作らねば！と思い色々試していたら結構あっさりと出来ました。今回はその方法を書い ていきたいと思います！ 構成 構成は…以前の記事 http://jedipunkz.github.io/post/swift-chef/ と同じです。 +-----------------+ | load balancer | +-----------------+ | +-------------------+-------------------+-------------------+-------------------+---------------------- proxy network | | | | | +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ | chef server | | chef workstation| | swift-mange | | swift-proxy01 | | swift-proxy02 | +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ ...> scaling | | | | | +-------------------+-------------------+-------------------+-------------------+-------------------+-- storage network | | | | | | +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ | swift-storage01 | | swift-storage02 | | swift-storage03 | | swift-account01 | | swift-account02 | | swift-account03 | +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ ..> scaling 手順 では早速手順を記していきますね。毎回なのですが Chef ワークステーション・Chef サーバの環境構築については割愛します。オムニバスインストーラを使えば Chef サー バの構築は簡単ですし、ワークステーションの構築も Ruby インストール -> gem で Chef をインストール -> .chef 配下を整える、で出来ます。 ...

こんにちは。@jedipunkz です。 今まで監視システムの Sensu やクラウドプラットフォームの OpenStack、コンフィギュ レーションマネージメントツールの Chef やクラウドライブラリの Fog 等使ってきま したが、これらを組み合わせるとオレオレオートスケーラ作れるんじゃないか？と思い、 ちょろっと作ってみました。 ちなみに自分はインフラエンジニアでしかも運用の出身なので Ruby に関しては初心者 レベルです。Chef で扱っているのと Rails アプリを作った経験はありますが、その程 度。Fog というクラウドライブラリにコントリビュートしたことはアリますが..。ちな みに Fog のコントリビュート内容は OpenStack Neutron(当時 Quantum) の仮想ルータ の操作を行う実装です。 そんな自分ですが…設計1周間・実装1周間でマネージャと CLI が出来ました。 また暫く放置していたマネージャと CLI に WebUI くっつけようかなぁ？と思って sinatra の学習を始めたのですが、学習を初めて 1.5 日で WebUI が動くところまで行 きました。何故か？Ruby には有用な技術が揃っているから・・！(´；ω；｀)ﾌﾞﾜｯ オレオレオートスケーラ ‘sclman’ の置き場所 https://github.com/jedipunkz/sclman スクリーンショット +++ 構成は？ +-------------- public network +-------------+ | |sclman-api.rb| +----+----+---+ | sclman.rb | | vm | vm |.. | |sclman-cli.rb| +-------------+ +-------------+ +-------------+ +-------------+ | openstack | | chef server | | sensu server| | workstation | +-------------+ +-------------+ +-------------+ +-------------+ | | | | +---------------+---------------+---------------+--------------- management network ‘sclman’ っていう名前です。上図の workstation ノードで稼働します。処理の流れは ...

こんにちは、@jedipunkz です。 前回、‘Ceph のプロセス配置ベストプラクティス’ というタイトルで記事を書きました。 http://jedipunkz.github.io/post/ceph-process-best-practice/ 今回はこの記事にあるポリシに従って下記のような特徴を持った構成を作る手順を具体 的に書いていきたいと思います。 ceph01 - ceph04 の4台構成 ノードに HDD 2台搭載されていることを前提 (/dev/sdb, /dev/sdc) ノードに Journal 用 SSD 1台搭載されていることを前提 (/dev/ssd) ceph04 は mds サービス稼働 ceph05 は ceph-deploy を実行するためのワークステーション 最終的に ceph04 から Ceph をマウントする mon は ノード単位で稼働 osd は HDD 単位で稼働 mds は ceph04 に稼働 構成 : ハードウェアとノードとネットワークの関係 public network +-------------------+-------------------+-------------------+-------------------+--------- | | | | | +--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+ | ceph01 | | ceph02 | | ceph03 | | ceph04 | | ceph05 | | +-----+ +-----+ | | +-----+ +-----+ | | +-----+ +-----+ | | | | | | | sdb | | sdc | | | | sdb | | sdc | | | | sdb | | sdc | | | | | | | +-----+-+-----+ | | +-----+-+-----+ | | +-----+-+-----+ | | | | | | | ssd | | | | ssd | | | | ssd | | | | | | | +-------------+ | | +-------------+ | | +-------------+ | | | | | +--------+--------+ +--------+--------+ +--------+--------+ +-----------------+ +-----------------+ | | | cluster network +-------------------+-------------------+------------------------------------------------- 構成 : プロセスとノードとネットワークの関係 public network +-------------------+-------------------+-------------------+-------------------+--------- | | | | | +--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+ | ceph01 | | ceph02 | | ceph03 | | ceph04 | | ceph05 | | +-----+ +-----+ | | +-----+ +-----+ | | +-----+ +-----+ | | +-------------+ | | | | | osd | | osd | | | | osd | | osd | | | | osd | | osd | | | | mds | | | | | +-----+-+-----+ | | +-----+-+-----+ | | +-----+-+-----+ | | +-------------+ | | | | | mon | | | | mon | | | | mon | | | | | | | +-------------+ | | +-------------+ | | +-------------+ | | | | | +--------+--------+ +--------+--------+ +--------+--------+ +-----------------+ +-----------------+ | | | cluster network +-------------------+-------------------+------------------------------------------------- 注意 : 上記の図だと ssd : mon が対に見えますが、そうではありません。 ...

Ceph はブロック型の分散ストレージファイルシステムです。POSIX のファイルシステ ムとしてマウント出来ます。Linux の Kernel ドライバや FUSE ドライバを用いてマウ ントします。またブロックデバイスとしてマウントする方法もあります。 だいぶ前ですが、Ceph に関する記事を以前下記の通り書きました。 http://jedipunkz.github.io/post/ceph-cluster-network/ http://jedipunkz.github.io/post/ceph-deploy/ Ceph の構築方法について記したブログだったのですが、今まで mon, osd, mds の各プ ロセスをそれぞれ何台のノードに対して配置し、またそれぞれのプロセス幾つを何に対 して配置するのか？という疑問が付きまとわっていました。node, disk, process のそ れぞれの数の関係について知りたいなぁと思っていました。幾つかのドキュメントを読 んでいて、ぼんやり見えてきた事があるのでそれを今回はまとめたいと思います。 また、皆さん気になるトコロだと思われる容量設計についても軽く触れたいと思います。 参考資料 http://ceph.com/docs/master/rados/configuration/mon-config-ref/ http://www.sebastien-han.fr/blog/2013/12/02/ceph-performance-interesting-things-going-on/ 各要素の数の関係 ハードウェア要素である node, disk(hdd), ssd そしてソフトウェア要素である mon, osd, mds の数の関係はどのようにするべきか？基本となる関係は 1 mds process / node 1 mon process / node 1 osd process / disk n jornal ssd device / disk / node だと考えられます。僕が今のところ理想かなぁと思っている構成をまとめたいと思いま す。 下記の図がそれです。 +------------------------+ | client | +------------------------+ | +--------------------------+--------------------------+-------------------------------+------------------------- | | | | public network +------------------------+ +------------------------+ +------------------------+ +------------------------+ | mon | | mon | | mon | | mds | +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------------------------+ | osd | | osd | | osd | | osd | | osd | | osd | | osd | | osd | | osd | | | +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ | | | disk | | disk | | disk | | disk | | disk | | disk | | disk | | disk | | disk |....> | | +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+scale | node | | ssd | | ssd | | ssd | | | +------------------------+ +------------------------+ +------------------------+ | | | node | | node | | node | | | +------------------------+ +------------------------+ +------------------------+ +------------------------+ | | | | +--------------------------+--------------------------+-------------------------------+------------------------- cluster network mds と node の関係 mds はリモートクライアントへのファイルシステムサービスの提供を行うことや特性が 全く異なることから別ノードに切り出しました。また mds は幾つかのノードで稼働さ せる事も可能。が、mds はそれぞれのサービスを HA 組む仕組みは持っていないので どれか一方の mds をクライアントは指し示す必要があり、その mds が停止すれば直 ちに障害に発展します。 ...