glusterfs, イベント, インフォメーション, ネットワーク, 仮想化, 勉強会, 負荷分散装置, 運用管理

July Tech Festa 2014で発表させていただいたスライドを公開しました。

発表の機会をいただきありがとうございました。>JTF2014実行委員会様

 

JTF2014−presentation

なんとベストプレゼンテーション賞もいただきました。

ベストプレゼンテーション賞

機会があればもっと喋りますので気軽にお声がけくださいませ。

FhGFS, glusterfs, クラウド

始めましたといっても検証しているだけです。すいません

FhGFS、正式にはFraunhoferFSとのことでハイパフォーマンスを想定した分散並列ファイルシステム。

GlusterFSのようにフォールトトレラントな分散並列ファイルシステムではなく、
どこかのサーバが停止すれば障害となります。現状のバージョンでは運用でカバーするしかなさそうです。

特徴としてはストライピングによる高速化とメタデータサーバの分散化による高速化
GlusterFSに比べて小さいファイルでもパフォーマンスを発揮します。
グラフィカルなツールで管理やモニタリングが可能な点もGlusterFSにはない機能です。

とにかく、実際に試してみないとわからないので

インストール&パフォーマンス比較を行ってみます。

まずは役割を確認します。

■役割

5つの役割が存在します。

1.Management service server(fhgfs-mgmt)

management,metadata,storage,clientへシステムコンフィグレーションを提供するサーバ

2.Metadata servers(fhgfs-meta)

メタデータを保管するサーバ

3.Storage servers(fhgfs-storage)

実データを保管するサーバ

4.Graphical administration and monitoring system server(fhgfs-admon)

グラフィカルなJAVAのツールからこのサーバを経由してFhGFSの管理やパフォーマンスグラフのモニタリングを行う

5.Clients(fhgfs-helperd,fhgfs-client)

データをmountするサーバ。

■サーバの準備

パブリッククラウド上でサーバを立ち上げます。すべて下記の環境で立ち上げます。
CentOS-6.4 64bit 20GB 4CPU 4GB

各サーバでrootで公開鍵の登録を行いiptablesとselinuxは切っておきます。

1 * Management server 192.168.0.101
2 * Metadata servers 192.168.0.151-152
8 * Storage servers 192.168.0.201-208
1 * Admon server 192.168.0.251
1 * Clients 192.168.0.51
1 * 作業サーバ(インターネットへのGWにもなっています) 192.168.0.1

の計14台を構築しました。クラウドならこの段階まで10分以内で構築可能です。

作業サーバのhostsを登録します。

すべてのサーバに配布もしておきます。

準備は以上です。

■パッケージインストール

パッケージのインストールはすべて作業サーバから行います。

Management server向け

Metadata servers向け

Storage servers向け

Admon server向け

Clients向け

■InfiniBand用の設定

今回はイーサネット環境ですので設定しません。

■各環境設定(各環境で設定)

Management server向け

Storage server向け

Admon server向け

Clients向け

■サービススタート(作業サーバから)

問題なければこれでclinetでdfすると

このようになっているはずです。mountされ使えるようになっています。

■メタデータとストレージデータの冗長化

メタデータの冗長化(client環境にて)

この設定でメタデータが2重化されます。ただしフォールトトレランスではなく復旧には手動での作業が必要です。

ストレージデータの冗長化

raid10設定とすることでデータの2重化が可能。ただし復旧は手動での作業です。

■admon server

admonサーバは8000番ポートで待ちうけてます。

今回は作業サーバにインターネットからのポートフォワーディングによって自身の環境から繋ぎます。

GWサーバ(eth0:external eth1:internal)にてマスカレードとポートフォワーディングの設定を行っています。

あとは、http://作業サーバのIP:8000

ツールのダウンロードリンクが表示されますのでダウンロード

ダウンロードしたJAVAツールを起動させログインすれば下記のようなモニタリングや各種管理が可能となります。

初期のログインはAdministrator:adminでのログイン

admon

■パフォーマンス比較 GlusterFS(stripe 4 replica 2) vs FhGFS(raid10)

dd、catやlsを利用したパフォーマンス比較です。

 

 filesystem write(1M 1000個) write(1M 10000個) write(5G 1個)  read(5G 1個)  ls(1000個のファイル)  ls(10000個のファイル)
 FhGFS  91s  196s  90s  55s  0.5s  5.6s
 Glusterfs  186s  430s  186s  49s  1.2s  14s

これを見るとFhGFSのほうが書き込みと小さいファイルが得意。

小さいファイルで書き込みパフォーマンスが必要かつ障害がある程度許容されるサービスに限定すれば使いどころはあるかなあ。

Glusterfsのほうがインストールも設定も運用も簡単でバランスは良いように思います。

 

glusterfs

ほんとに小ネタです。

って数が多くなればなるほど面倒くさいのですが、下記のようにまとめる事が出来ます。

glusterfs, インフラ全般

 

旧世代のコンテンツサーバ

写真 (28)

 

raid10の構成としデータの2重化で保護を行うタイプ

ただのスタンドアローンな構成です。

この構成でのメリットとしては

  1. 運用のしやすさ
  2. 低コスト
  3. データの2重化
  4. 小回りが利くのでいろんなネットワークへ簡単に移植できる。

デメリット

  1. サーバ障害時のサービス停止
  2. 2重化であってもRAIDのコントローラーの障害により、ごく稀ですがデータを失う可能性がある。
  3. パフォーマンスの向上が見込めない。

コンテンツサーバは大容量であるためデータがロストしない事が前提じゃないと運用が難しい。

この世代より前の世代ではraid50だったのですが、意外とデータがロストしてしまっていたのでraid10が標準となりました。

ただ、raid10であってもデータのロストの可能性がありますし、

このスタンドアロンな構成ではサーバ障害時にサービス停止が避けられません。

データロストやサーバ障害によるサービス停止リスクはコンテンツサーバが増えれば増えるほど増大いくことになります。

つまり、リスクが増えるにつれ運用の負担も大きくなっていく事になります。

そこで、我々はこれを解決するための新しい構成が必要となりました。

それが下記の構成です。

写真 (29)

 

2台で1セットの構成です。

RAIDは5へと変更し、2台のサーバでGlusterの構成を組みます。

もちろん、replica2の構成でネットワーク的なraid1を実現します。

これにより、サーバ障害時であってもサービスの停止とはならず、

さらに1台のサーバでraidコントローラーの障害でデータをロストしたとしても別のサーバ側でデータは保護されます。

データの保護は2重化と変わらないものの、これによるデータのロストはほぼなくなったと言えます。

サーバのパフォーマンスも2台でサービスを行うことで分散処理されますので向上します。

ただ、これによりコストが少しだけあがります。

が、

2台で3TBほどの領域を差し出すだけで、

これだけのメリットが創出できます。

障害発生時はデータの復旧にパフォーマンスの低下が発生し、さらにそれが長時間続く状態となるのですが、自社のキャッシュサーバやCDNを利用することでオフロードすることになります。

dmmでは

windowsサーバ、linuxサーバ

スタンドアロンなサーバや数十台単位ののGluster環境もあります。

さらにはストレージアプライアンスを使っていたりして、いろんな構成が混在しています。

その中でもこの2台1セットの構成が一番リスクが低く小回りの利く構成だと思っています

glusterfs

 

2GBの10個のファイルを生成し、そのスループットの最大値と
そのファイルをすべて読み込んだ時のスループットを計測してみました。

すっぱい計測結果ですが、とりあえずあるものは共有します。^^;

ディスクタイプ Peer台数 タイプ インターフェース 2GB書き込み(最大時) 読み込み時のスループット ローカルドライブにて読み込み時のスループット
SAS 14台 ストライプ 1G 108MB/s 101MB/s
SATA 16台 レプリカ2 10G 52MB/s 285MB/s
SATA 4台 ストライプ 1G 32MB/s 100MB/s
SATA 8台 レプリカ2 1G 51MB/s 100MB/s
iodrive 3台 レプリカ3 10G 80MB/s 170MB/s 1110MB/s

 

※書き込み:for i in seq 1 10;do dd if=/dev/zero of=testfile${i} bs=1M count=2048;done
※読み込み:time cat testfile* > /dev/null

実運用のせいもあってか書き込みのテストで、ストライプ4台の構成で速度が出ていないものがありますが、実際はレプリカよりは早いと思います。

読み込みについてですが残念ながら1Gインターフェースのせいで頭を打っており最大スループットがわかりません。すみません。

レプリカであろうがストライプであろうが、10Gインターフェースが重要なのかがわかるかと思います。

ストライプで10GインターフェースのGlusterも現在構築中ですので、

このあたりの実測値は後日、ここのコメントでお知らせ出来ればと思っています。

ちなみに

画像サーバはiodriveでglusterというお話をさせていただいたかと思いますが、

ピア3台レプリカ3で構成しているので、すべてのサーバで同じファイルを持っています。

そのファイルをGlusterのボリューム経由ではなくiodriveから直接読み込むことで、

上記の実測値にある170MB/sではなく1110MB/sが叩き出せるようになっています。

簡単な話、nginxのドキュメントルートをiodriveにあるbrickに設定しているだけです。

読み込みしかさせないため、このような工夫で高速化を図っています。

PAGE TOP