Site-A

鯖管のつぶやきってことで、偶に他愛もないことを書き殴ってますが、今回は私の管理しているAlicorn/Avalonサーバの裏話的なことを書いてみたいと思います。

[…]

裏側って程の記事じゃないけど、作成に使ったツールはPowerDirector13というツール。

http://jp.cyberlink.com/products/powerdirector-ultimate-suite/features_ja_JP.html

今まではフリーのツールをいろいろ駆使してたけど、不安定で、特に容量が大きくなると重いし落ちるしでイライラしながら作ってたので思い切ってソフトを買ってみました。

やはり金額相応ですね。軽いし、安定して動作するし、何よりエフェクトが多くていろいろできます。エンコードもフリーのツールに比べると早いです。使い勝手的には前に使ってたVideoPadに近いですね。マニュアルとか読まなくてもすんなり使えました。

なんか、ステマみたいな記事になってしまったｗ

ちょっと専門書を読んでたのでメモメモ。ちなみに仮想化ソフトウェアはKVMを使ってます。 ほとんどマイクラとは関係のない話題なので、無関心な人は無視して下さい。

ちなみにマイクラプラグインの負荷を調査したいなら、/timingコマンドについて調査すると良い。

CPU Planningで使用するCPUは固定化すること。好きなCPUを選ばせるとマイクラ側がラグが強烈に発生する。（mpstatの%stealが増えるのでわかる） CPUはゲストOSで使用しない分を一つ残す方がいいらしい。つまり、CPU2個ずつ使うゲストOSを3個作った場合は、CPUの数は2×3+1(ホストOS用)が最低数。 たぶん、10人くらいログインするサーバならCPU2つで十分。Avalonは念のため4つにしてる。 CPU2つって言っても、ハイパースレッディングなので、物理コアが一つなのに注意。マイクラはかなり一つのCPUに負荷をかけるので、CPU2個(2スレッド)で回すのは微妙？ やはりCPU数よりもスピード重視がいい。(マイクラは) 2.4GHzのCPUに10人くらいログインして、CPU使用率は80%/1コアくらい。 お金がないからやってないけど、物理CPUを増やすなら、1つのゲストOSのvCPUを2つの物理CPUに分けるのはやめた方がいいらしい。 マイクラサーバは一度CPU使用率が上がる、さほど上がらない傾向があるので、毎日再起動した方がよい。 メモリ 一番謎が多く、課題として取り組んでいるポイント。たぶんプラグイン毎のメモリ使用数とか分析しないとわからなさそう。 言うまでもないがホストOSに32bit OSは使わない(メモリ上限の問題) 起動時のJAVAの-serverオプションは必須なのは当然なのだが、そうすると「ほぼ」常時-Xmx分を使用する。(厳密には起動直後だけあまり使わない)。 多かろうが、少なかろうが「設定しただけ使われる」。 -Xmnは-Xmxの1/3～1/2の間くらいがちょうどいいみたい。これ以上減らすとFullGCの発生数が増えるし、増やしても変化が少なくなる。 -XX:PermSizeと-XX:MaxPermSizeは少ないと明らかに不具合が起きるが、どこまで増やしていいかは謎。256Mくらいで動かしてる。 やはり起動しっぱなしだとFullGCの時間が徐々に増えていくようなので、毎日再起動した方が安定していそう。 HugePage?→要調査 ディスク やはり、パフォーマンスはノーマルなrawやqcow2よりも、sparse化したrawが最強らしい。今のサーバはLVMでパーテーションをマルっとディスクに割り当ててるけど、遅い気がする？ qcow2はスナップショットが作れるのであればあったで便利。不具合があった場合に一瞬で巻き戻しできるし。 2つのマイクラサーバを、2つのゲストOSで稼働させているが、そのファイルを1つのディスク上に展開しているのは超失敗、、、。片側のI/Oが上がると、もう片方のマイクラがラグる。気にするほどじゃないけど、ddコマンドとかでrawファイルを作ったり、dynmapでマップ生成を別ゲストで実施しても、影響が出る。 特にHDDの場合は、2ゲストを1HDD上に置くとシークタイムが増えて、パフォーマンスが激減するらしい。 ただ、単純にディスクを分ければいいのか、それともコントローラまで分けないと意味がないのかは不明。 まぁ、今の時代はSSD。 ミラーリングの必要性は疑問。マイクラサーバは(最近は安定しているけど)、OSが強制停止したりするとチャンク欠落などが高い確率で発生する。 だから、障害発生時は「巻き戻し」が必要なので、バックアップの多世代化が必要。特にサーバ異常停止→自動起動の仕組みにしている場合は、障害データのまま古いバックアップを上書き削除する場合がある。 たとえば、1時間毎10世代とかのバックアップをするなら、ディスクが壊れてデータ欠損をしたところで、1時間前のバックアップがあればそこから戻せるので、あまり問題は起きない。だから、ミラーリングにお金をかけるくらいなら、単構成にしてバックアップ世代数を増やした方が安全な気がする(当然バックアップの物理ディスクは分ける) ファイルシステムはext3より、XFSの方が性能がいいらしい。 ディスクパーテーションの論理的な開始位置と物理的な位置がずれるとパフォーマンスが落ちるらしい。Linuxは4kb単位らしいが、ゲストOSからは512kbに見える？よくわからないので調査が必要。 仮想ディスクのディスクパスはやはりvirtioにするのがパフォーマンス上よい。IDEは最悪らしい。 I/Oスケジューラはdeadlineがいいらしい。SSDの場合はnoopもいいらしいけど、技術資料には「負荷状況にもよるが、ホスト側もゲスト側もdeadlineにするとベンチマーク結果が安定する」って書いてあった。ちなみにデフォルトはCFQ また、新しめのOSでも、ホストOSのバージョンが古いとディスクパフォーマンスが低下するらしい。 IOモードががnativeの場合、ブロックサイズを大きくした方が、高速でCPU負荷が減るらしい。(32kぐらいがいい?) ネットワーク デバイスモデルはvirtioを使う。CentOSならドライバもあるから選択の余地なし。rtl8139が一番パフォーマンスが悪いらしい。 仮想化環境用クローズドネットを作った方がいいね。作って無いや…

 

I/Oスケジューラの扱い方(カーネル2.6.17以上かも) 以下の例は物理デバイスが/dev/vdaの場合。ちなみに再起動すると戻るので、bootオプションにもつけないとダメ。

確認 # cat /sys/block/vda/queue/scheduler noop anticipatory deadline [cfq] 設定 # echo deadline > /sys/block/vda/queue/scheduler 確認 # cat /sys/block/vda/queue/scheduler noop anticipatory [deadline] cfq

サーバの運用をする上で、他のサーバがどのような運営をしているか参考にすることは多々あるんだけど、「これってどう実現してるんだろう？」って感じる運営をしているサーバが偶にあります。 当然、プレイヤーさんのサポートを充実した方が参加者が楽しくプレイできる訳ですが、とは言えできないこともあります。特に営利目的でサーバ管理をやっている訳じゃ無いから、どこまで自分の生活を削ってやるのか？なんてのも悩むポイントになりますね。

少なくとも私の場合は「出来ないことはやらない」というのが一つのポリシーなので、そういう所でプレイヤーさんから批判を受けることもあります。 まぁ後々になってから「ごめんなさい」をするより、初めから「出来ませんごめんなさい」って言っておいた方が、私もプレイヤーさんも後々困らないので、初めから「出来ないことはやらない」というスタイルで運営してます。

特に、これからサーバ管理者になる人、サーバ管理者に対して疑問を感じてる人は参考にしては如何でしょうか？

24時間サポートはできない

仕事や学校に行ってる時間は当然できませんし、勤めて無くても寝てたり外出してたりとかありますからね。旅行とかで数日間留守にすることもあります。

サブ管理者を立ててある程度は対処は可能ですね。サブ管理者というのは聞こえはいいですが、結構難しい問題が沢山あります。

その人をどう信用するのか。 どこまで権限を付与するか。 運営ポリシーをどうやって共有するか。（管理者としての対応にバラツキを出しちゃまずいので） お願いする人・したくない人の線引き。断るときはどう断るのか。 着任・退任の判断。 そもそも何をさせるのか。

個人的に、サーバ管理者はとても楽しい遊びのスタイルだと思います。だから、サブ管理者というのはある意味「軽い責任でサーバ管理者を楽しめる」手段かもしれないですね。 ただ、リアルの知り合いでは無い人に対し、ある程度の権限を与えなければならないので、選任基準は厳密にしておかないと危険だと思います。 また、後述の通り、サーバ管理者にとって負荷のかかる部分は、サブ管理者に任せるのはとても難しいです。逆にそういう所を任せないのであれば、単純に管理の負担が増えるだけで意味がありません。 また、着任・退任の方法も難しくて、あまり任せたくない人が「サブ管理者やらせて！」と言うことも多いです。また、旨く管理者が出来てない場合や、来なくなった場合にどう退任させるかというのも悩まなければなりませんね。

まぁ、そんな感じなので私の場合は「サブ管理者」はお願いすることは考えてません。将来的にサーバの運営スタイルの一つとしてお願いする可能性があるかもしれませんが、そもそも「私の出来ないことはやらない」ポリシーだから、基本的に必要では無い感じですね。

プレイヤーさんのModを知ることはできない

何を入れてるかはわかりません。Forgeサーバであれば、Forgeクライアントの情報はわかります。これはどういうことかというと、以下の事を一発で特定することはできないと言うことです。

チートModの検出 透過テクスチャなどの検出

基本的にFly・高速移動・鉱石探知などは、その行動パターンから疑いを掛けて、後はストーキングするとかしか無いですね。不正Modの調査と言いつつも透明化してプレイヤーさんを小一時間ストーキングするなんて調査もざらにあります。

ちなみにバグ利用はログで発見できることがあります。

サーバ・プラグイン・Modを改造することは難しい

これには、以下の条件があります。

サーバ管理者に技術があること。 プラグインやModの元となるソースプログラムが配布されていること。

マイクラはJavaというプログラミング言語で作成されているので、Java言語を知ってるならある程度触れますが、Java言語はその特性上、プログラムを作成する環境作りの難易度が高いです。また、知ってたとしても、マイクラ独自の「プログラミングのルール」があるので、それを勉強しなければならないので、それもまた難しいことです。

ましてや、世の中のITのプロフェッショナルで、サーバ（機器など）の管理ができて、プログラミングができて、プレイヤーさんと旨くコミュニケーションができるスーパサイヤ人はほとんど居ません。

他のサーバでプログラムの専門家やサーバの専門家など分業で運営してるサーバもありましたね。まぁ、そういう恵まれた環境ってのも少ないです。

また、私はプラグインの改造（主に動かない場合に直すだけ）はしますが、これをやるにしても元々のプログラムソースファイルが配布されていなければできません。これ自体は配布されてなければゼロから作るしか無いので、実質無ければどうにもならないです。ましてや、プラグインではなくサーバ本体に手をつけるのは非常に厳しいですね。

ちなみに「ゲームプログラミング」というのはプログラミング業界の中ではかなり難易度の高い分野です。ちょっとなおしたり、新しいプラグインを開発するのはものすごい時間の掛かることなので、サーバ管理者をやりながら開発するのもこれまた困難なことですね。

BANは大変

BANはとても大変です。何が大変かは後述の通りですが、できることなら「自動的にBAN」すると非常に管理の負担が減りますね。

本人からの反発が多い 「何故BANなの？」というのに答えなければなりません。 ある意味当然のことで、悪いことをしたとは言え、数十時間というプレイ時間を一瞬で奪うので、こういう反発は多いです。適当にあしらうと炎上なんてことにもなりかねませんからね。 他のプレイヤーからの反発が多い 概して「仲の良いグループ」と「そうでないグループ」というのができますが、不満は「そうでないグループ」からきます。それでBANすれば「仲の良いグループ」から不満がでますので、そこからも説明が求められることが多いです。場合によってはグループごと他サーバに移住することもあるので、サーバを盛り上げたい場合は慎重に説明しなければなりません。 希に親からの反発も・・・ 後述してますが、マイクラの年齢層は意外と低いので、BANするとその親から質問が来ることもあります。 曖昧なBANルール MCBansというツールがありますが、これはBANルールがはっきりしてるので、これに準じるといいでしょう。ただし、運営する上ではこれでは不完全です。特に一番扱いが難しいのは「マナー違反」系の問題ですね。 「迷惑を掛けない」とか曖昧なルールは主幹の相違が起きるので、それに伴う反発も発生しやすいです。 証拠の確保 MCBansで反発が発生した場合は証拠が必要になります。基本的に管理者はログインしていない時間が多いので、証拠が不十分になりがちです。ログはあくまで機械的な部分しか取れないので、細かい表現などをログから知るのは骨の折れる作業です。 明らかな違反行為(破壊とか)で無い場合の証拠の確保は非常に大変で、私の場合でも、BANの確認だけで、２，３時間掛けるのはザラにあります。 その他

探せばいっぱい「出来ないこと」はありますが、書き殴ってみると以下の様な感じ

ワールドデータの改変は困難。 「ワールド内のアイテムデータを一斉変換」とか「ワールド内のニワトリを全部殺す」とかは実はほとんどできません。 そういうツールもありますが、変換作業に数時間かかる上に、データ構造を理解してちゃんと変換しないとワールドデータが壊れるので、技術的にも困難です。（例えばチェストを削除する場合は中身のデータも削除が必要だとか） プレイヤーデータの改変は困難。 ログインしてる人のデータ改変は比較的楽ですが、データ異常でログイン出来なくなった場合の修正は難しいです。 なので、プレイヤーデータをこまめにバックアップして、簡単に巻き戻せるようにしておいた方が楽ですね。
若年者の管理が大変 マイクラの年齢層は案外？若年層が多いです。マルチプレイヤーの1/3くらいは小中学生みたいですね。 詳しくは書きませんが、若い人ほどルールの順守率は落ちるので、そこは気にして置いた方がいいでしょう。