|
||||||
|
およそ10年維持してきたMinecraftのサーバですが、2025年末をもって閉鎖することにしました。 特になにか切っ掛けがあったわけではないです。基本的に手を掛けなくても安定的に動作するサーバを目指していたし、サーバのリソースも余りまくってるので、全然維持は可能なんですが、なんせログインしてなにかすることも無いし、バージョンアップもしてない（というかプラグインが多すぎて途中からどうにもならなくなった）。既にまともにプレイしている人も、数カ月前に一人くらいみたいなそんな感じになってたので、閉じて残念と思う人も流石にいないでしょってことで、ここいらでスパッと閉じる感じです。 そんな感じですが、これまでの運用について少し書き残しておきます。 […] 調査の進捗状況 ずいぶん延期されてる気がしますが、マイクラJEの1.13のリリース日がアナウンスされたので、私の管理しているサーバの対応も準備を始めたいと思います。今回はアイテムIDが大幅に変更されてるので、ちょっと大変そう。 注意：ここに掲載されている情報は、2018/8/14時点の情報です。情報が最新ではないかもしれないので、ご注意を！ 現在の進捗状況は以下の様な感じ。 【済】テストサーバ構築(Alicorn) 【対応中】テストサーバ構築(Avalon) 【済】サーバプログラムを1.13化し確認 【対応中】プラグインの最新化 【対応中】非対応プラグインをなんとかする 【未】資源生成準備 【未】リリース […] 調査の進捗状況 マイクラサーバが1.12に対応したので、私の管理しているサーバのspigotプラグインも対応してるかなどの調査メモです。 注意：ここに掲載されている情報は、2017/6/21時点の情報です。最新ではないかもしれないので、ご注意を！ 2017/6/21 サーバを1.12へ上げたので、このページの更新は終わります。実際にサーバへ入れたのは一部もう少し新しいバージョンになってたりします。 現在の進捗状況は以下の様な感じ。 【済】テストサーバ構築(Alicorn) 【済】テストサーバ構築(Avalon) 【済】サーバプログラムを1.12化し確認 【済】プラグインの最新化 【済】非対応プラグインをなんとかする※一部後回し 【済】資源生成準備 【済】リリース(6/21) […] 
自分でも忘れそうなので、メモがてらSpongeForge Serverのセットアップ方法を書いておきます。 OSはLinux7系、マイクラは1.11系で記載しています。 Firewall/iptablesの設定などの基本的な設定や、各種ファイルのDL方法、その他OSの基本的な使い方などは書いていませんので、ご自分で調べて下さい。 […] 調査の進捗状況 マイクラサーバが1.11に対応したので、私の管理しているサーバも対応させる為のメモです。 注意：ここに掲載されている情報は、2016/11/27時点の情報です。最新ではないかもしれないので、ご注意を！※サーバのバージョンアップが完了したので、以後更新はしない予定。 【済】テストサーバ構築(Alicorn) 【済】テストサーバ構築(Avalon) 【済】サーバプログラムを1.11化し確認 【済】プラグインの最新化 【済】非対応プラグインをなんとかする 資源生成準備←延期(森の館の発生率が非常に低いので対策検討) 【済】リリース […] 注意：ここに掲載されている情報は、2016/6/11時点の情報です。最新ではないかもしれないので、ご注意を！ 1.9からわずか3ヶ月すかorz… […] 注意：ここに掲載されている情報は、2016/3/6時点の情報です。最新ではないかもしれないので、ご注意を！ 私の管理しているAlicornサーバとAvalonサーバをマイクラ1.9ベースに上げましたが、1.9化で発生していた問題等々について掲載しておきます。サーバプログラムはspigotを使ってます。もちろんバニラサーバです。 […] 
前のサーバはマイクラを始める前に構築したんですが、構築当初から2つのマイクラサーバ(今のAlicornとAvalon)を運営するつもりで設計していた訳ですが、マイクラサーバの運営1年目に入って次のフェーズを検討する上でリソースが足りなくなってきたので、サーバの構成の見直しを図りました。 構築後の全体の構成は図のような感じです。コンセプト的には、 今まで通り、サーバを仮想化して機能(リソース)を分割し、負荷分散。 ハードはそれなりにお金をかけているけど、ソフトウェア部分はタダ！(OSSを利用)ちなみにハードの部分も完全に入れ替えでは無く、過去のハードに追加する形を取ってるので、ゼロから作るよりもかなり安く済んでます。 [仮想化]各サーバの構成(OS部分)をなるべく同じにしてメンテナンス性の向上。監視機能が同じなので管理しやすくなってるのと、バックアップ/データシェアを統一の構造にしたので、バックアップ処理やデータ交換が楽になってます。 [CPU]Minecraftはシングルスレッドプログラムなので、CPUを増やしても意味が無いです。ただプラグインやOS処理を考えると基本的にはCPUを2つ割り当てれば十分です。ただ、昨今のCPUはハードウェアマルチスレッディング(Hyper Threadingとか)でCPU数を倍化してるので、1つのCoreに負荷がかかると共連れ的にもう一つのCoreの性能も落ちます。なので、Minecraftサーバへ割り当てるCPUは4つと考えてます。そう考えるとやはりCPU自体の速度では無く、Core数を増やす必要が出てくるので、今回はデュアルCPU構成にしました。物理CPU数=2、物理Core数=12、論理Core数=24(物理Core12×2スレッド)という数になってます。 [DISK]いわゆる円盤を使ったHDDに比べるとSSDは極端に故障率が低い(HDDは経験的に2～4年くらいで壊れてる気がする)ので、今回はミラーリングをやめました。ストライピングも物理ディスクの情報が見づらくなるのと故障率の高さから、基本的にRAID構成をやめてます。何より見た目上2本だった構成から、今回の構成変更＆買い足しでディスクが6本になったので、パラレル処理性能が抜群に上がってます。ミラーをやめたから信頼性が下がるかというと、OS部分を仮想ディスクにしてジョブでバックアップしたりしてます。Minecraftはそもそも1時間毎にバックアップ/1日毎に外部保管してるので、壊れても最悪でも１日分巻き戻りで済むから、「我慢できるレベルの」信頼性低下になってる感じです。また、今回は仮想化ホスト以外は、LVM(LogicalVolumeManager)構成なので、ゲームを止めずにディスク間のデータ移動が可能です。さらにホットスワップ可能なベイにディスクを装填しているので、その気になればゲームを無停止でディスクの交換も出来るようになってます。 [NET]表ネットワーク(インターネットに繋がる側)と裏ネットワーク(管理用)とでネットワークを分離。気持ちパラレル処理で性能は上がるかもしれないけど、物理的には１本なのでさほどでは無いです。目的は分割することでデータ流量を見やすくすることかな。 Minecraft部分のディスクを、それぞれOS・Data・Dynmapに分けてます。Database(巻き戻し用のログ記録や、mcMMOなどの共有データ)も別サーバに分けてるし、DynmapのWebはWebサーバ側でデータをキャッシュして負荷軽減してます。この辺は元々からやってたことだけど、上記の[DISK]にも書いた通り、物理ディスクが分かれた事での並列処理の能力が上がってるので、この構成の恩恵がさらに高くなってる感じです。 日々のバックアップや定期再起動などはジョブコントローラで制御してます。前の構成だと物理ハードの再起動とかは出来なかったんだけど、今回はちゃんと出来るような構成にしてあります。なので、仮想サーバを全停止→OSイメージをバックアップ→物理ハードを再起動(リフレッシュ)ってのも出来ちゃいます。 という事で、ハード的には複雑になり、仮想サーバも増えましたが、管理面ではむしろ楽になった感じですね。 ちなみに自宅サーバなので、うるさいと困るからFANとかを自作して取り付けてたりもします。※FANは大きい程安くて静音性が高くなります。 とりあえず今回のリプレースでより高度な仮想化基盤が出来たので、次はゲーム環境の強化ですかね。 サーバスペック CPU:Intel XEON E5-2620v2 2.1GHz x2 MEM:64GB HDD:2.5TB(512GBx4、215GBx2) […] 
ちょっと専門書を読んでたのでメモメモ。ちなみに仮想化ソフトウェアは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 マインクラフトをマルチサーバ運営する方法について語ってみたいと思います。 マルチサーバと言っても、マルチワールドやマルチができるサーバのことではありません。マインクラフトサーバ(bukkitやspigotなども同様)を複数起動して運営することです。単一の物理サーバに複数のマインクラフトを立ち上げる事もあるし、物理サーバを分けて運営することもできます。物理サーバを分けた場合は、データ連係をどうするかが多少面倒になりますね。 そもそもなんでマルチサーバ運営を考える必要があるのか？ 負荷分散。PvPサーバ運営者が気にする点かな。 複数管理者連携。 バニラサーバとModサーバ運用←私はこれ その他（ログイン人数を合算させたりなど、見た目上一つにしたいとか） ちなみにかなり面倒なので、心して掛かった方がいいです。 以下、考えなければならないことと、実現方法です。 ベースシステム サーバを束ねるには、親となるシステムを構築する必要があります。マインクラフトクライアントからはそこにログインし、そこから適切なサーバへ振り分けられます。 マインクラフトサーバ bukkit…プラグインが豊富なサーバ。広く使われてるので情報が多く扱いやすい。 spigot…bukkit互換の軽量サーバ。後述のcauldron、BungeeCordとの親和性が高い。 forge…Modサーバを作るためのフレームワーク。Modの前提となっている場合が多い。また、クライアント側にもModが必要となるので、参加者側のハードルが上がる。当然、bukkitプラグインなどは使えない。 cauldron…spigot＋forge。以前はMCPCという名称だった。 マルチサーバ管理 BungeeCord…複数のマイクラサーバを連動させることができる。見た目上はバニラでは無いサーバに見えてしまいますが、ログイン先がバニラならバニラで入れます。サーバ間移動も相手がオフラインだったり、前提Modが必要だったりする場合は移動しないよう制御をしてくれます。 BungeeCordの説明は過去に書いてるのでそっちを見て下さい。 単純に入れればマルチサーバ化できる訳では無く、前提がいろいろあるので注意が必要です。 データ連動 サーバが違うとデータも別扱いです。お金、経験値、アイテムなどです。 ちなみに同じデータファイルを複数のサーバで共有した場合、競合が発生して高い確率でデータが壊れるか、書き込みができなくなります。なので、通常のデータ連係はデータベースを使わなければなりません。 幸いにもbukkit系のプラグインはデータベースに対応しているものが多いので、それを使っていきましょう。データベースの種類はSQLiteかMySQLがほとんどです。 MySQLの方がサーバを建てなければならないなど難易度が高いですが、使い方を覚えてしまえば連携のしやすさはこっちが容易です。 SQLiteはサーバが必要無い為、使用するのは容易ですが、サーバが無い分、マルチサーバからアクセスするのが難しいです。っていうかそもそもどういうやり方がいいのか想像付きません。 私の管理しているサーバでは以下の連動ができることを確認してます。それ以外もできるかもしれませんが、未検証です。 お金 CraftConommyを使ってます。元々Essentialsを使ってましたが、これはDBに対応してませんね。CraftConommyはDBに対応してるし、Essentialsのお金データをインポートできるので楽です(他の経済プラグインも対応してます)。 なお、変換の際にプレイヤー名にハイフンかアンダーバーが使われてると勝手に変換される(どちらかというとEssential側の仕様)ので、注意して下さい。 mcMMO、Jobs これらもDBに対応しており、複数サーバから同時にアクセスできます。私のサーバはJobsを連携してませんが、これはゲーム性の観点でしてないだけで、技術的にはできます。 注意しなければならないのは、例えばTownyの様なプラグインはデータ連係できますが、サーバ間データ連動ができないので問題が起きます。例えばサーバ二カ所でTownyを起動した場合、税金は二重課金されます。さらにお金が連動できていなければ片側のサーバでお金不足になる事もあります。 HarkEyeなども連動できそうですが、怖いのでやってません。 念のため補足しておきますが、DB連動できたとしてもお互いのトランザクション処理がちゃんとできているかは別問題です。上記のレベルであれば今の所問題は起きてません。 機能連携 ゲームでの機能連携ですが、だいたい以下の方法でできます。詳しくは過去のコンテンツを見て下さい。 Dynmap Dynmap-MultiServerを使う事で連動できます。 投票 BVotifierでできます。Votifierと連動もできます。 チャット CloudChatというツールでできます。私は使いたいと思ってますがまだ使ってません。ローマ字変換とか無いので。 サーバ間ゲート TeleportSignsでできます。他にもHomeコマンド連動とかできるのも有るみたい。 運用 マルチサーバを運用する上でいくつか気になることもあると思います。思いつく限り書き連ねてみようと思います。 ロビーとなるサーバは安定させるべき 単体でロビーサーバがあるのがベターですが、Modサーバなど安定しないサーバがある場合、ログインできなかった場合の待避サーバが設定できますので、そこにロビーサーバなどの安定したサーバを指定すべきです。そうすることで一カ所のサーバが死んでもプレイヤーは別のサーバで遊ぶことができます。 BungeeCordの扱いが難しい これが止まるとどのサーバにも入れません。また、管理者コマンドが少ないので、何かあったときに自由がきかないでやむを得ず再起動しなければならなくなる曲面も多いです。 ワールド名は同一にしない。 同じ名前のワールドがあるとおかしな動きをする物があります。特にデフォでworldという名前が使われているので、ここがネックになる場合があります（server.propertiesで変えられます） サーバ同士の連動性 例えばMySQLのDBサーバを建てた場合、マインクラフトサーバを上げたまま、DBサーバを止めてはダメです。ちゃんと、 […] |
||||||
|
Copyright © 2026 Site-A - All Rights Reserved Powered by WordPress & Atahualpa |
||||||
2026/01/1 | 
カテゴリ: 