A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

サーバを考える

滅多に書かない鯖管のつぶやき二回目です。
今回はマイクラサーバを建てる上でのハードウエアをどう考えるかについてつぶやいてみようと思います。

お金がジャブジャブにあればお金を掛けてリッチなサーバを建てればいいんですが、そうも行きません。限られたお金を使って必要最低限のリソース(CPU、メモリ、ディスク、電気、etc…)を買う必要があります。
ってことで、マイクラサーバを建てる場合の考え方を書いてみようと思います。

補足:このページはJava1.7ベースでの解説になってます。Java1.8では起動オプションやメモリの考え方が若干変わっているので、ご注意下さい。

CPU

CPUのリソースの尺度は、コア数と速度が主だと思いますが、マイクラサーバはシングルスレッドプログラムだそうです(ちゃんと調べてないけどそうらしい)。

なので、CPUのコア数がいくら多くても、サーバは1コアしか使えません。プラグインとかModとかの作りで2コア以上使ったりするかもしれませんが、まぁ細かいことは気にしないでいいでしょう。

だから、CPUを選ぶ場合は、コア数は少なくていいので、クロック周波数が早いのを選ぶのが吉です。

メモリ

どのくらいがイイというのは難しいです。私の管理しているAlicornは6GByte割り当ててますが、10人くらい入っても重くはならないです。

マイクラはJavaという環境の上で動いてますが、メモリに限って言うとチューニングが物を言うことが多いです。

Javaはガベージコレクションという、簡単に言うとメモリの管理する仕組みがあるんですが、それがバケツの様にメモリの器を用意してます。それがあふれると要らないメモリを掃除するのですが、そのときに「ラグ」が発生します。そのメモリの掃除の事をFullGCと言うんですが、それをなるべく発生させないように調整するのが重要です。

どう調整するかはちょっと難しいのですが、詳しそうなサイトを探してそこに書いてある値を丸パクりするのが吉だと思います。実際には以下の様にデータを見てみないと判断出来ません。

jstat__heap-day

Javaメモリの状況(枠のギザギザが細かいところがFullGCが頻発してるっぽい?所)

マイクラは人が少なくてもそれなりにメモリを消費するので、完全に無くす事ができません。また、FullGC以外にもチューニングポイントがあるので何とも言えませんね。
ちなみにメモリ使用量の指定は、マイクラサーバを起動する際に以下のような指定をします。

java -server -Xmn5120M -XX:PermSize=256M -XX:MaxPermSize=256M -Xms6144M -Xmx6144M -jar craftbukkit.jar nogui

私も詳しい訳では無いですが、最低限、「-serverを指定する」「メモリのMINとMAXを同じにする」というのは基本として押さえた方がいいです(これをしないとサーバの稼働状況でメモリ使用量が可変し、その分オーバヘッドがかかる)

とりあえず経験的にはサーバは2~4GByte程度だとかなり厳しいです。6GByteくらいあるならチューニングすればそれなりに行けます。10GByteとかならチューニングとかしなくてもソコソコ行けますが、ログイン人数にも依存するので何とも言えません。

ディスク

ディスクはいろんな観点で考えなければならない要素があります。

先ずはディスク容量。マイクラプログラムは大したことが無いです。1GByteあればおつりが来ます。
問題はデータの方で、半径1500ブロックのワールドなら200MByte程度です。これが半径5000ブロックになると2GByteくらいにまでふくれあがります。

2GByteくらいなら、今のご時世たいしたことが無いかもしれません。しかし、これだけじゃ無いです。
これをDynmapなどでWebに出す場合はWeb用データで1ワールドあたり10~15GByteくらい必要です。(Dynmapは解像度を選べて綺麗なほどデータ量が大きいです。よって設定により節約ができます)

容量とは別に、もう一点ディスクを考える上で重要な観点があります。「データの保護」です。
データの守り方は、大きく「バックアップ」と「冗長化(ミラーコピー)」の2つがあります。この2つは良く混同されますが扱いがかなり違くて、マインクラフトは「バックアップ」が重要になります。
何故なら、マインクラフトで発生しがちなデータ消失が「チャンクの破損」か「荒らし行為」が主だからです。

マイクラ以外のサーバ運用の場合、「ハードウェア故障からのデータ保護」が重要ですが、システム停止を防ぐ手段が「冗長化(ミラーコピー)」です。しかし、「チャンクの破損」や「荒らし行為」はいくらミラーコピーをしても、発生すればミラー側も同じく使い物にならなくなるので、あまり意味がありません。だから「過去の状態を記憶したバックアップから戻す」ということを十分検討する必要が出てきます。

補足:冗長化について
冗長化もあればいいです。
ただ、二重化した場合は故障率は2倍ですし、片ハイが壊れてもう一方のディスクも引きずられて調子が悪くなることもあります。

HDDは故障率が高かったので、冗長構成にした方が故障時の対応が楽でした。SSDなら故障率が極端に低いので、あえて冗長化せずに、ディスクを複数に分けてある程度空き容量に余裕を持たせて運用しておけば、SSD1本が故障しても、別のディスクをマウントしてバックアップから復旧した方が管理が楽だったりしますね。

個人運用のPCサーバのレベルで、たかだか数時間の停止を避けるのにお金を掛けて冗長化するのはどうかと思うし、やるならホットスペアまで実現しないとあまり意味が無いので、そのスキルと長時間の環境維持をしっかりできるなら実現する意味はあると思います。

Dynmapはワールドデータがあればいくらでも作り直せるのでバックアップは考える必要が無いと思います。

しかしワールドデータをいつ発生するかわからない「チャンクの破損」や「荒らし行為」から守るにはかなり多くの世代管理が必要になります。
例えば私の場合、日中は仕事をしているので、データ破壊が発生した場合は対応が最遅で12時間程度後になってしまいます。なので、そのデータ破壊から復元するには12時間前のバックアップが必要です。しかし、発生から1時間程でデータ破壊が見つかった場合に12時間前に戻したら巻き戻りすぎでプレイヤーさんが困ります。

だから、この場合は1時間毎12時間分のバックアップを取ればだいたいどのような状況にも対応できます。しかしそうなると、例えば2GByteのワールドデータなら、

12時間分×2GByte=24GByte

のディスクが必要になります。また、データ破損以外にも様々な状況に対応できるように日次のバックアップも必要です。私の場合は過去10日分のバックアップを残してるので、

 10日×2GByte=10GByte

が必要となります。ってことで、1ワールドのバックアップ容量は、

24GByte+10GByte=34GByte

です。
これは1ワールド当たりのデータ量なので、さらにマルチワールド運用の場合はワールドが増えればデータ量も増えます。サーバにもよりますがバックアップサイズはだいたい100G~200G程度のサイズになります。

長くなりましたが、つまり1マイクラサーバを安全に運用するには、実可動データ+バックアップ+Dynmapデータということで、300GByte以上が必要になります。
ちなみにHawkEyeなどの巻き戻し用のデータとかもそれなりに大きいですが、ここでは割愛します。

なので、世の中1TByteのHDDが当たり前かもしれませんが、決して余裕がある容量ではありませんね。
ここまで厳重にバックアップを取らなくても、運用は可能です。ただ、バックアップを取っていなかったばかりに障害発生→閉鎖というサーバも少なくないのは事実です。少なくとも日次で2世代以上は取っておくべきだと思います。

また、ディスクの選択肢としてはHDDやSSDがありますが、24時間可動のサーバの場合、HDDの寿命は短くて3年、長くても5年くらいと見ておいた方がいいです。壊れたら復旧が大変なのでミラー構成にするのもいいでしょう。本当はSSDがいいですが、300GByteも入るSSDともなるとかなりの値段になるので、SSD運用をするならちゃんとデータサイズ計算をして必要最低限のサイズを割り出さないとダメですね。

電気

長くなってしまったのでサラっと書きます。
サーバ運用は電気代が掛かります。だいたい月に1000~3000円程度でしょう。省電力サーバにするポイントはだいたい以下の点です。

  • 節電CPUを使う。Wikipediaとかを見ればTDPという単位で書かれてるので少ないのを選びます。
  • なるべくサーバの構成パーツを減らす。DVDドライブとか常時使わないなら外す(USBドライブとかにしておくといいかも)、グラボもサーバでは性能はいらないので、CPU内蔵の物などを選択するといいでしょう。
  • とにかくHDDを減らす、あるいはSSDにする。

ちなみにHDD→SSDにすると、サーバ全体の電気使用量が1~2割程度減るのでかなり節電効果が高いです。また、SSDは故障率が極端に低いので、あえてミラー構成にしないことで節電するのも有りかもしれませんね。(HDDの故障率を甘く見ない方がいいです)

また、安いのでもかまわないので、UPS(無停電電源装置)も導入することをお勧めします。単純にサーバ停止に備えるだけで無く、突然の電源断はサーバの故障にとても繋がりやすいです。電源断だけでなく、家庭用の電源は掃除機やエアコンなどの大きな電力を消費する機器の影響で電圧が安定しません。この不安定な電圧もサーバの故障の原因になります。UPSはこういった不安定な電圧をカバーする為の保護にも繋がるので、そういう意味でもお勧めです。

仮想化

家庭内サーバを運用する場合は、仮想化して運用するのもかなりメリットが大きいです。
CPUの所で記載しましたが、マイクラはCPUを1つしか使わないので、マルチコアCPUを使う場合などは無駄が大きいです。また、メモリをかなり使うので、例えばDBサーバと同居させるとメモリの取り合いでボトルネックになることもあります。

私の管理しているサーバも以下の様な感じで仮想化してます。(仮想化基盤はLinux KVM(タダ)を使用)

kvm

 

  • マイクラ専用仮想サーバは2つ。
  • DBは別サーバにすることで負荷分散。
  • バックアップもマイクラサーバとは別にすることで、バックアップに掛かる負荷も分散(例えばデータ圧縮でもCPUを使うので)
  • Dynmapが意外と負荷の原因となることがありますが、WebサーバをリバースProxyとして、機能を分散化。
  • 当然、Webページもマイクラサーバとは別のWebサーバ上に設置。
  • 上図には書いてないですが、テストサーバもあり、テストサーバに負荷が掛かっても公開サーバへの影響はほとんど無い。

仮想化はお互いの負荷の干渉を減らすと同時に、例えば上記の絵だと、DBやバックアップのあるサーバには外部から直接入れないので、セキュリティの向上にも一役買えます(外部からマイクラサーバをぶっ壊されても、バックアップは守れる)。

なお、サーバを仮想化した場合は消費電力が1~2割程度増えます(物理的に増やすよりかはかなりの節電ですけどね)

難易度は高いですが、メリットも多いので、技術に自信がある方はチャレンジしてみるのもいいかもしれませんね。
※個人的にはもっと効率がいいと言われているLXCにしたい・・・

なお、仮想サーバにする場合、CPUはゲストOSに紐付けて固定化することをお勧めします。仮想サーバはマルチコアCPUを使っていると処理毎にCPUを切り替えるのですが、マイクラのようにリアルタイム処理上でこれが発生すると、かなりの頻度で小さなフリーズ・巻き戻りが発生します。(発生時は、mpstatなどの監視ツールで確認すると「%steal」という値が増加します)
処理するCPUの切り替えが発生しないようにするのは、CPU PinnningとかCPUアフィニティとか言うんですが、それを設定することで、これが相当抑制できます。

長くなりましたが今回はこのへんで。

2のコメントがあります : サーバを考える

  • smk7758

    java -server -Xmn5120M -XX:PermSize=256M -XX:MaxPermSize=256M -Xms6144M -Xmx6122M -jar craftbukkit.jar nogui

    -Xms6144M -Xmx6122Mの部分を同じに・・

    java -server -Xmn5120M -XX:PermSize=256M -XX:MaxPermSize=256M -Xms6144M -Xmx6144M -jar craftbukkit.jar nogui

    修正お願いします。

コメントを残す

これらのHTMLタグが利用可能です

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

Time limit is exhausted. Please reload CAPTCHA.

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.