glusterfs, linux

DMMで利用されているGlusterfs

ちょっとした工夫で耐障害性を向上させています。

通常は下記のようにサーバがfuseによってglusterのボリュームをマウントします。

※nfsでもcifsでもマウントできますがfuseが推奨されているようです。残念ながらWindows版のfuseクライアントは開発途中です。

この場合Glusterpeerで冗長性が取られていたとしてもサーバがマウントしているGlusterサーバが落ちるとサーバ側にも障害が発生してしまいます。しかも裏側が死んでいるのにもかかわらずフロント側のアプリケーションがサービスを受け続ける状態となってしまうのでやっかいな状態となる。

これを回避するために書き込みができるかどうかの監視を行い障害箇所を切り離すようするのですが、リアルタイムではないので問題は完全に解決しません。

fuse_mount

そこで我々がとったアプローチは下記の構成です。

サーバもglusterpeerに参加させ、そのpeer上でGlusterボリュームをマウントする。

こうする事でGlusterサーバのA,B,Cのどれが落ちても冗長性が保てるようになります。

Glusterpeer_mount

 

サーバはpeerに参加はするのですがbrickは一つも提供しません。

また、別のアプローチとしてglusterサーバ上にアプリケーションを乗っけてそのまま運用している場合もあります。

用途に合わせた使い分けを行うのが重要です。

みなさんはどのようにお使いですか?ぜひ教えてください。

co-location, hardware

サーバなど付属の電源ケーブルは2mや3mの長さが標準です。

これらのケーブルを使用するとラック内がスパゲッティ状態となり、さらに空調の妨げにもなります。

昔の写真をお見せしますね。これだ

lanケーブルのカーテン

 

お恥ずかしい限りです。LANケーブルのカーテンができています。

これらをすっきりさせるため

dmmではラック内の空調の流れを妨げないよう50cm、70cmの短いケーブルを特注しこれらのケーブルを使うことにしています。

SAMSUNG

機器の外観のチェックや調査などにも役に立ちますのでおすすめです。

もちろん、ネットワーク機器などの精密な機器と思われる機器や指定されている機器は付属のものを利用していますのでご安心を。

艦これ

おかげさまで大好評をいただいております艦隊これくしょん。

我々、エンジニアでもはまっていますよ。楽しいですよね。

最初はとっつきにくいのですが、進めるにつれてキャラクターに思い入れが出てきて、 かつての日本帝国軍のすごさを肌で感じるでしょう。

大和型戦艦が出るまではやめられない

みんな、お金を支払わず試行錯誤しながら楽しんでいます。

演習なんかは毎日のルーチン作業に組み込まれているようです。^^;

hardware

SASよりSSDのほうが0.1Aほど省電力らしい

8発のHDDがのるサーバを利用すれば0.8Aも違う。コストと電力や用途などのバランスを考えてSSDの検討がいいと思います。

dmmではデータベースなどの用途やproxyサーバやapサーバなど多くのスケールアウトが必要なサーバで利用されています。
ところで、

nandフラッシュと呼ばれているSSDですが、いくつか種類があります。

下記はDELLからのSSDに関するFAQからの抜粋です。

SLC SSD 書き込みキャッシュと、読み取りキャッシュアプリケーション (読み取りがラ
ンダムで、書き込みが集中するアプリケーション) に適しています。書き換え可能サイクル10万回
eMLC SSD 今後、読み取り・書き込みが混在するワークロードで人気のオプションにな
ると見られており、特に予算に制限がある場合は歓迎されます。書き換え可能サイクル3万回
MLC SSD 読み取りが集中するアプリケーション (データベーステーブルへのアクセスな
ど) で、最もコストパフォーマンスに優れたソリューションとなります。書き換え可能サイクル3000回

DMMでは用途に係らずSSDはすべてMLCを使うようにしていますが、その寿命を補うような冗長な構成を取るようにしています。

MLCの寿命について200GB*8の構成で考えてみます。
合計で1600GBで一つのCELLが3000回の書き込みが保障されているということは4.8PBの書き換えが可能になる。
1日10GBの書き換えがあるとして1315年。1日100GBの書き換えで13年

極限性能が求められない場面では正直性能差は感じられません。
上記のように安価なMLCモデルで容量を調整することによって予定寿命をコントロールするほうが現実的なように思います。

きちんと設計することで必要な条件ははじき出せると思っています。みなさんはいかがでしょうか?ご意見お待ちしております。

実はTLCという種類のSSDもあるのですが、信頼性を犠牲にし容量をSLCの3倍とするものですが、
1玉あたり2TBクラスになってきたらSATAに変わりクラスターストレージの用途で検討できたらなと思っています。

 

linux

bondingについてはここで説明するよりも過去の先人たちの記事のほうが参考になるかと思いますので割愛します。

bondingを利用するということはsofをなくすための構成をとるということになりますが、そのためには

動作が把握しやすいactive-backupモード(mode=1)を利用し、
同一L2スイッチ内で接続が完結する場合は「miiリンク監視」
その他は「arp監視」を選択するのが冗長性を担保するために良い選択となると思います。

が、

dmmでは基本的には設定が簡単で運用が楽なmiiリンク監視をどの場面でも利用しています。

miiを冗長構成できちんと構成するためにはspanningtreeなどの駆使する必要があるのですが、dmmではspanningtreeは原則使っていないので、
ポート障害を防ぐためのスイッチ間リンクの二重化で耐障害性を高めるなどの措置をとっています。

なるべく状況が把握しやすく確実にコントロールが可能なコントローラブル設計が基本となります。

どうしても落としたくないサービスは別の構成を考えますが、
現在はそんな場合でもスイッチドファブリック技術(vcs fabricpath,qfabric,vena)を投入し冗長性を保ちます。

意識せずともmiiリンク監視が標準となる日が近くなっています。

arp監視:無駄なパケットがブロードキャストドメイン内に流れます。mii監視より切り替わりに時間がかかる。arpの監視先のメンテナンス性が損なわれる。監視先で障害が発生すると全面的に断となる。監視先を設定しなくてはいけない。

mii監視:リンクのアップダウンだけで切り替えができるので切り替えが早い。hsrp、vrrp、nsrpなどのL3レベルの切り替えがわからない。gsrpなどのl2レベルでの切り替えもわからない。自身以外のリンクの状態がわからない。接続するスイッチでスパニングツリーもしくはファブリック技術やopenflowなどのSDNソフトウェアによる制御が冗長の条件となる。

PAGE TOP