July Tech Festa 2014で発表してきました

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

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

 

JTF2014−presentation

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

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

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

FhGFS始めました。

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

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を登録します。

192.168.0.101 s01 mgmt001
192.168.0.151 s02 meta001
192.168.0.152 s03 meta002
192.168.0.201 s04 str001
192.168.0.202 s05 str002
192.168.0.203 s06 str003
192.168.0.204 s07 str004
192.168.0.205 s08 str005
192.168.0.206 s09 str006
192.168.0.207 s10 str007
192.168.0.208 s11 str008
192.168.0.251 s12 admon001
192.168.0.51 s13 client001

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

# for i in `seq -w 1 13`; do scp hosts s$i:/etc/; done

準備は以上です。

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

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

# wget -P /etc/yum.repos.d/ http://www.fhgfs.com/release/latest-stable/dists/fhgfs-rhel6.repo
# for i in `seq -w 1 13`; do scp /etc/yum.repos.d/fhgfs-rhel6.repo s$i:/etc/yum.repos.d/; done

Management server向け

# ssh mgmt001 yum -y install fhgfs-mgmtd

Metadata servers向け

# for i in `seq 1 2`; do ssh meta00$i yum -y install fhgfs-meta; done

Storage servers向け

# for i in `seq 1 8`; do ssh str00$i yum -y install fhgfs-storage; done

Admon server向け

# ssh admon001 yum -y install fhgfs-admon

Clients向け

# ssh client001 yum -y install fhgfs-client fhgfs-helperd fhgfs-utils

■InfiniBand用の設定

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

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

Management server向け

# ssh mgmt001
# vi /etc/fhgfs/fhgfs-mgmtd.conf
storeMgmtdDirectory=/data/fhgfs/fhgfs_mgmtd

Metadata server向け

# ssh meta001とmeta002
# vi /etc/fhgfs/fhgfs-meta.conf
storeMetaDirectory=/data/fhgfs/fhgfs_meta
sysMgmtdHost=mgmt001

Storage server向け

# ssh str001からstr008
# vi /etc/fhgfs/fhgfs-storage.conf
storeStorageDirectory=/data/fhgfs/fhgfs_storage
sysMgmtdHost=mgmt001

Admon server向け

# ssh admon001
# vi /etc/fhgfs/fhgfs-admon
sysMgmtdHost=mgmt001

Clients向け

# ssh client001
# vi /etc/fhgfs-client.conf
sysMgmtdHost=mgmt001
# vi /etc/fhgfs/fhgfs-mounts.conf
/mnt/fhgfs /etc/fhgfs/fhgfs-client.conf

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

# ssh mgmt001 /etc/init.d/fhgfs-mgmtd start
# for i in `seq 1 2` ssh meta00$i /etc/init.d/fhgfs-meta start; done
# for i in `seq 1 2` ssh str00$i /etc/init.d/fhgfs-storage start; done
# ssh admon001 /etc/init.d/fhgfs-admon start
# ssh client001 /etc/init.d/fhgfs-helperd start
# ssh client001 /etc/init.d/fhgfs-client start

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

[root@client001 ~]# df -h /mnt/fhgfs
Filesystem Size Used Avail Use% Mounted on
fhgfs_nodev 106G 29G 78G 27% /mnt/fhgfs

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

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

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

# fhgfs-ctl --mirrormd /mnt/fhgfs

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

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

# fhgfs-ctl --setpattern --raid10 --chunksize=1m --numtargets=4 /mnt/fhgfs

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

■admon server

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

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

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

# vi /etc/sysctl.conf
net.ipv4.ip_forward = 1
# sysctl -p
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# iptables -I FORWARD -i eth1 -o eth0 -j ACCEPT
# iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8000 -j DNAT --to 192.168.0.2:8000
# iptables-save > /etc/sysconfig/iptables

あとは、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の小ネタ

ほんとに小ネタです。

# gluster volume create stripe 4 replica 2 str01:/brick01 str02:/brick01 str03:/brick01 str04:/brick01 str05:/brick01 str06:/brick01 str07:/brick01 str08:/brick01

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

# gluster volume create stripe 4 replica 2 str0{1..8}:/brick01

コンテンツ系サーバ

 

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

写真 (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に設定しているだけです。

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