july techfesta2014 f30

Copyright © 2013 NTT DATA Corporation

「 OpenStack Swift 」を Puppet で数百台自動構築して見えた課題と現状のベストプラクティス2014 年 6 月 22 日株式会社 NTT データシステム方式技術事業部柿沼基樹

クラウドストレージを

自前で構築できる

2Copyright © 2014 NTT DATA Corporation

アジェンダ

1 OpenStack Swift とは

2OpenStack Swift を数百台自動構築して見えた今後の課題

3これからのインフラプロビジョニング

ベストプラクティス


自己紹介

氏名：柿沼基樹所属：株式会社 NTT データ　基盤システム事業本部　　　　　　システム方式技術事業部

経歴：自社クラウドサービス (BizXaaS) の開発等を担

当。 OpenStack と出会い、 Swift の評価を担当。 OpenStack Swift の自動構築を担当。現在は Immutable なインフラを検討する R&D

を実施。


1.OpenStack Swift とは


米国 RackSpace のオンラインストレージサービスで使われていた基盤ソフト

KVMv

m

vm

KVMv

m

vm

IaaS (nova) で使うなら VM イメージのバックアップストレージ

世界中でエンタープライズ用途での適用が進行中


技術概要

利用者端末

ストレージサーバ



プロキシサーバ

外部 NW

PUT/GET/DELETE

○

○ ○ ○

○ リングファイル

ユーザデータ（オブジェクト）

2 2

712

105

2

パーティション


○

2

a b c d

Proxy は振分け、 Storage はデータ格納

1 2 3 … 2^n

格納先ディスク ID 　①

a b c … z

格納先ディスク ID 　②

b c a … q

格納先ディスク ID 　③

c d d … w

退避先ディスク ID 　①

d a b … a

… … … … … …

退避先ディスク ID 　 x y z … d

乱数表（リングファイル）


パーティション番号 (n=1…32)

システム内の全物理ディスク

物理ディスク

/swift/2 ∟ 0241.data ∟ 0432.data

/swift/105 ∟ 0314.data ∟ 0431.data

/swift/712 ∟ 0324.data ∟ 0531.data ∟ 0621.data

オブジェクト（ = ファイル）

パーティション（＝ディレクトリ）


技術概要

利用者端末




プロキシサーバ

外部 NW

PUT/GET/DELETE

○

1 2 3 … 2^n

格納先ディスク ID 　① a b c … z

格納先ディスク ID 　② b c a … q

格納先ディスク ID 　③ c d d … w

退避先ディスク ID 　① d a b … a

… … … … … …

退避先ディスク ID 　 x y z … d

乱数表（リングファイル）


パーティション番号 (n=1…32)

システム内の全物理ディスク

○ ○ ○

○ リングファイル

ユーザデータ（オブジェクト）

2 2

712

105

2

物理ディスク


/swift/2 ∟ 0241.data ∟ 0432.data

/swift/105 ∟ 0314.data ∟ 0431.data

/swift/712 ∟ 0324.data ∟ 0531.data ∟ 0621.data

オブジェクト（ = ファイル）

パーティション（＝ディレクトリ）


○

2

退避

a b c d

監視＆

検知

故障に備えて複数のレプリカを書き込む


技術概要

(1) 定期的にお互いのオブジェクトを監視

(4) ディスク復旧時の回復

(3) オブジェクトの退避

(2) ディスク障害発生と検知

Swift プロセス

ディスク

( ５ ) 退避オブジェクトの削除

Node 1 Node 2 Node 3 Node 4

Node 2 Node 3 Node 4


通常

障害

復旧


Node 1

Node 2 Node 3 Node 4Node 1

ディスク故障時やデータ復旧時は自動復旧


技術概要

Proxy

Storage

Storage

Storage

Proxy( 増設 )

（１）プロキシサーバ増設（２）ストレージサーバ増設①

②

Proxy を増やせばスループットが増える Storage を増やせば容量が増える

Proxy

Storage

Storage

Storage

Proxy

Storage( 増設 )

リバランス

①

②

③

④

10

Copyright © 2014NTT DATA Corporation

Swift を使うのはどんなとき？

• スモールスタートしたい• 終局の見積が難しい／見積したくないスケールアウト型

• ハードベンダを非依存にしたい• 激甚対策したい長期保存型

• １つのファイルにアクセスが集中する• 利用対象ユーザが多い高速・性能重視

11

Copyright © 2014NTT DATA Corporation

利用例：階層型ストレージ

システムイメージ・利用イメージ背景・ニーズ

① 過去の資料を廃棄できない・部門ファイルサーバなど

② 頻度は多くないが閲覧は必要・複数年分保存が必要な場合が大半・厳しい容量制限はやりづらい

概要

現行のストレージに加え、前年度以前のデータを Swift に格納するタイプ

選定ポイント

① スモールスタート・最小限の初期投資

② データ増量に応じて拡張・上限は（ほぼ）なし・拡張時も無停止で実施可能

※ あくまで一般的なお話です。当社顧客とは一切関係がございません。

windowsexplorer

Swift 用explorer

エンドユーザ

システム A

システム B Connecter(FUSE/ISCSI)

Swift

現行サーバ


2.OpenStack Swift を数百台、自動構築して見えた今後の課題


自動構築に至った理由と目標

構築サーバ

検証／本番環境

品質

メンバ…よし、自動構築しよう

数百台

合計 6 セット

高水準

少人数

目標・品質 / 期限は守る（基盤・ Swift の試験は全部やる）・構築期間は定時に帰る（社内で成功例を！）


自動構築で主に利用したもの

# 利用項目利用用途

1 kickstart OS ・パッケージのインストールを自動化

2 Puppet設定ファイルのデプロイを、マニフェストに従って一括デプロイ

3 Subversion マニフェスト及び構築資材の配布

4 pssh並列シェルの実行 (並行でファイル転送、取得 )

5 IPMI 電源管理。リモートから電源を ON するため。


Puppet とは

ツールの概要システムを事前定義に従って構成するプロビジョニングツール

開発元 Puppet Labs.

ライセンス Apache 2.0 (ver2.6以下は GPLv2)

開発言語 Ruby

マニフェスト記法独自 DSL

利用例

１）ファイルをデプロイする

例） /etc/puppet/hoge/hosts を、　　 /etc/hosts に　　パーミッション 644　　グループ、オーナを root:root　　で配置

２）プロセスを起動する

例 ) /etc/puppet/hoge/httpd.conf を /etc/httpd/conf/httpd.conf に　パーミッション 644　グループ、オーナを root:root　で配置したのち、 httpd プロセスを起動する

・実行の都度毎回確認・何度実行しても同じ（冪等性）


Puppet を利用する上での懸念

Puppet はサーバ／クライアント構成で利用できない

初期：数百台

・・・・・・

終局：千台以上

Puppetマスタサーバ

終局見積もりが千台を超える。 Puppetマスタは耐えられるか？

いつか限界を逢えるのは必至・・・


ローカルデプロイ方式

クライアント／サーバ方式

✖故障があると、 SSL証明書の削除手順が発生✖台数が増えるとレスポンスが悪くなる

ローカルデプロイ方式

○故障があっても手順が増えない○台数が増えてもスケールする○メンテ時は差分しか送信されないため、負荷軽減が可能

PuppetMaster

PuppetClient

PuppetClient

……

証明書 DB

マニフェストデプロイ資材

各ホスト毎必要な資材をMaster が判断してデプロイする

構成管理

PuppetClient

PuppetClient

……

マニフェストデプロイ資材

pssh で各ホストに全資材を配布(subversion)

各ホストで必要な資材を判断してデプロイSSL

SSL

Puppet の利用方式をクライアント／サーバ方式から、ローカルデプロイ方式（分散方式）とした


自動構築のフロー

構成管理

SVN

Proxy Storage

(1)IPMI で全台電源ON

(2)Kickstart で OS インストール ( 自動 )

(3) 資材とマニフェストを一括チェックアウト (pssh)

(4)Puppet を使って一括ファイルデプロイ (pssh)構築完了！！

(0) 構成管理サーバ構築（手動）

わずか４ステップ、３手順で一括構築を実現！


自動構築するのなら、自動試験も

OpenStack Swift の自動試験ツールを利用：Tempest

コミュニティ版は網羅性が不足しているため、独自で試験を追加。

基盤試験はお手製のツールで。


コミュニティ版との違い

コミュニティ版 NTT データ版差異各 API に対して 1 パターンの試験を実施

各 API に対して、複数 (網羅できるだけの ) パターンの試験を実施

例【 1 】試験名：オブジェクト PUT試験内容：オブジェクトＸＸＸを PUTする期待結果： HTTP レスポンス 201

【 1 】試験名：オブジェクト PUT+ メタデータ付与試験内容：オブジェクトＸＸＸをメタデータ付きでPUT する期待結果： HTTP レスポンス 201

【 2】試験名：オブジェクト PUT+Invalid Contentlength試験内容：不正な Content-length を設定してオブジェクトを PUT する期待結果： HTTP レスポンス 400 (BadRequest)

・・ etc

試験数例

オブジェクト PUT試験 :1 オブジェクト PUT試験 :103Tempest 全体で 416項目の試験を自動で実施


【注意】 Tempest では出来ないこと

Proxy

Storage#1 Storage#2 Storage#3

Tempest

proxy-server

acc/con/obj-server

acc/con/obj-replicator

con/obj-updator

account-reaper

acc/con/obj-auditor

acc/con/obj-server


con/obj-updator

account-reaper

acc/con/obj-auditor

acc/con/obj-server


con/obj-updator

account-reaper

acc/con/obj-auditor

Tempest で試験できる

Tempest で試験できない

Swift のバックグラウンド処理の試験はできないバックグラウンド処理の試験は、事前に別途実施した


自動構築＆自動試験の効果

目標・品質 / 期限は守る（基盤・ Swift の試験は全部やる）・構築期間は定時に帰る（社内で成功例を！）

品質は守れたか？

【結果】全部で一万項目以上の試験結果を報告

品質水準の充足達成！

定時に帰れたか？

【結果】構築期間は定時前に作業完了。サクサク帰宅。

WLB の充足達成！

一見すると大成功のサクセスストーリー。しかし・・・


遭遇したトラブル

構築直後のアップデート作業（運用作業）にて、トラブルに遭遇

トラブル①

検証環境のファイルを間違って本番環境へデプロイしてしまった

トラブル②

別の理由で停止していたプロセスが、 Puppet の実行により意図せず起動してしまった

トラブル③

ファイルは正確にデプロイした。しかし、設定が反映されていなかったため、想定外の事象が発生した


なぜ起きるか？　～今後解決すべき課題～

【仮説】本番環境へのプロビジョニング運用は、正しくないのでは？検証環境のファイルを間違って本番環境へデプロイしてしまった

別の理由で停止していたプロセスが、 Puppet の実行により意図せず起動してしまった

ファイルは正確にデプロイした。しかし、設定が反映されていなかったため、想定外の事象が発生した

Puppet は環境差分を管理してくれるわけではない。

Puppet は定義された通り起動しただけ。

Puppet は設定の反映までは面倒みてくれない。

本番環境へプロビジョニング運用し続けることはやめたい！


3. これからのインフラプロビジョニング


これからのインフラ～ Immutable Infrastructure～

「１度構成したサーバには２度と変更を加えない。変更時は新たな環境に差し替える。」

• 運用している間にシステムがつぎはぎになり、管理が難しくなるという課題に対する答えのひとつ

– Chef/Puppet などのコード化によって軽減はされるが、本質的な難しさは軽減されない

• 「 Blue Green Deployment 」という考え方を一歩進めた考え方– 環境を２面用意した上で、バージョンアップ時にロードバランサをもう片方の環境に切り替える

方式

• 必須条件は「環境をまっさらな OS イメージから再現できること」– インフラがコード化されている今、可能になった

@IT 「継続的デリバリ／デプロイを実現する手法・ツールまとめ (2/2) 」　 http://www.atmarkit.co.jp/ait/articles/1312/03/news033_2.html

**ポイント **本番環境へプロビジョニングし

ない！


Immutable Infrastructure を実現するプロビジョニング

本番環境へのプロビジョニング運用はやめる。デプロイ毎に、プロビジョニングで作り直す。

ただし、今までのプロビジョニングツールをそのまま使うと・・

OS の設定はプロビジョニングツールでコード化できるけど…OS のイメージ作成から一貫してプロビジョニングできないのだろうか？

マルチプラットフォームイメージ作成ツール

PackerLinuxコンテナ管理アプリケーション

Docker

あります！今、ちょうど話題の！


packer

Packer とは

ツールの概要複数プラットフォームに対応した仮想マシンイメージのビルドツール

開発元 HashiCorp

ライセンス Mozilla Public License Version 2.0

開発言語 Go

仮想マシン定義

ファイル(json)

【プロビジョニング】


Packer ：ユースケース①

検証環境開発環境本番環境

Virtual BOX

packer

検討初期やデバッグ作業はデスクトップ上で

開発中の環境はリーズナブルに

本番環境でも開発環境と全く同じイメージをデプロイ

.qcow2.box AMI

仮想マシン定義

ファイル(json)

開発環境構築の効率化と本番環境との差異解消


Packer ：ユースケース②

初期中期後期

導入初期は安価なパブリック・クラウド

規模が大きくなってきたらプライベートクラウドへ移行

利用者の減退に伴い再度安価なクラウドへ移行

.qcow2 AMIAMI

packer仮想マシン

定義ファイル(json)

利用形態の変遷に伴うクラウド横断的なマイグレーション


Docker とは

ツールの概要 Linuxコンテナ (LXC) を用いたコンテナ管理アプリケーション

開発元 Docker Inc

ライセンス Apache License 2.0

開発言語 Go

Linux標準の機能 (cgroups, namaspaces) を用いて、ホスト上のコンテナ間のリソースを隔離している


Docker の特長

API ・ Docker Hub API による外部サービスとの連携

ポータビリティ・サイズが軽量なため、別環境への移行が簡単・ Docker リポジトリを利用した移行

バージョニング・コンテナをバージョン管理できる

1

2

3

http://blog.docker.com/2014/06/announcing-docker-hub-and-official-repositories/


仮想サーバ

Packer + Docker の使い分け

基本は Packer を使っておく。 (Dockerfile でビルドしない )

Docker はあくまでもプラットフォームとみなす。packer

Dockerリポジトリ

2面用意が難しい物理環境にもってこ

い

S3

container

物理サーバ

AMI

json


これからのプロビジョニングのベストプラクティス

コード化したインフラ／アプリ／テストコードを CI と連携してプロビジョニングする。

CIツール(jenkins)

Docker

① ビルド

独自レポジトリ

③war取得

ソースコミット

アプリ開発者

レシピコミット

インフラ開発者

Packer

③ ベースコンテナ取得

④コンテナ登録

② レシピ＆テストコード取得

【検証環境】

container

【本番環境】

テストコードコミット

④ビルド＆テスト

【机上環境】

連携

本番運用中！


今後取り組むべき課題

Linuxコンテナ (Docker) の利用はまだ課題がある

【現場の声】 DB とか Immutable にできるのか？ DBaaS にすべき？

ログ管理はどうする？集約型？ Fluentd?

RHEL7 から対応！？まだ現場は RHEL5 のみ対応アプリとか結構あるけど、ちゃんと動くか？

プライベートリポジトリの管理 …誰がやるの？・・・etc

いきなり全部を Immutable にするのは難しい。まずは徐々に改善ベースでやるのが最適。


まとめ


まとめ

OpenStack Swift を数百台自動構築しました。

構築は成功したものの、運用段階でトラブルが起き、プロビジョニングツールだけでの本番環境の運用の限界を感じました。

本番環境に直接プロビジョニングしない、” Immutable なインフラ”を実現してくれるPacker と Docker 、その使いドコロをご紹介しました。

しかし、これらの要素技術はまだ課題もあります。引き続き注意しながら、いいところは段階的に使っていきましょう。

july techfesta2014 f30

Documents