JTF2014に行って来た　その4　OpenStack　Swift＋Puppet

２２日、JTF2014に行って来た話のつづき

「OpenStackSwift」をPuppetで数百台自動構築して見えた課題と現状のベストプラクティス

をメモメモ



・自己紹介

１．OpenStackSwiftとは
米国RackSpaceのオンラインストレージサービスで使われていた基盤ソフト
IaaS(nova)で使うならＶＭイメージのバックアップストレージ
世界中でエンタープライズ用途の適用

技術概要
・Proxyは振り分け、Storageはデータ格納
・リングファイル（郵便番号と住所の対応みたいなの）
・冗長度を確保しながらデータを書く→自動復旧

Ｐｒｏｘｙを増やすとスループットが増える
Ｓｔｏｒａｇｅを増やせば、容量が増える

Ｓｗｉｆｔを使うのは
・スケールアウト型
・長期保存型
・高速・性能重視
Ｓｗｉｆｔリードに性能が出る

利用例
・階層型ストレージ
　　バックエンド

２．数百台自動構築

自動構築に至った理由と目標
構築サーバー数百台、検証本番合計６セット
→自動構築

kickstart
puppet　設定ファイルのデプロイ
subversion　マニュフェスト及び構築資材の配布
pssh　並列シェルの実行（ぱられるしぇる）
IPMI　電源管理

puppetを利用する上の懸念
終局見積もりは千台をこえる、Puppetマスタは耐えられるか
ローカルデプロイ方式
　（クライアント／サーバー方式ではなく）
　理由：証明書

４ステップ
・構成サーバーＩＰＭＩで電源ＯＮ
・KickstartでＯＳ入れる
・資材とマニュフェストをチェックアウト
・puppetを使って一括ファイルデプロイ

自動試験も
・Tempest（てんぺすと）：Swift
　コミュニティ版１パターン通ればＯＫ
・Tempestでできないこと
　　TempestはＡＰＩ試験しかしない
　　自分で作る部分も

遭遇したトラブル
・検証環境のファイルを本番環境にデプロイ
・違う理由で止まっていたプロセス→puppetの実行で意図せず起動
・設定が反映されていないものがあり、想定外の事象

なぜ起きる
・本番環境へのプロビジョニング運用は正しくないのでは
　　puppetは悪くない→ヒューマンエラー

３．これからのインフラプロビジョニング
「１度構成したサーバーには２度と変更を加えない。
　更新時は新たな環境に差し替え」

ＯＳのイメージ作成から一貫してプロビジョニング
　→Packer,Docker

Packer　みっちぇるはしもとが作っている

Packerユースケース
　　クラウドの移行

Ｄｏｃｋｅｒの特徴
・ポータビリティ
・バージョニング
・ＡＰＩ

基本はPackerを使っておく、Ｄｏｃｋｅｒはプラットフォーム

これからのプロビジョニングのベストプラクティス
・コード化したインフラ／アプリ／テストコードをＣＩと連携してプロビジョニングする

今後取り組むべき課題
・ＤＢはImmutable
・ログ管理
・RHEL5
・プライベートリポジトリ管理

Immutableなインフラ→PackerとDocker