LANパーティーサーバーガイド：ゲーム、ファイル、ボイスチャットをローカルでホストする

実証済みの1つのローカルネットワーク上で、ゲームホスティング、ファイル配布、ボイスチャットに個別の役割を割り当ててLANパーティーサーバーを構築します。

優れたLANパーティーは、インターネットが遅くなったり、ゲストが遅れて参加したり、いずれかのサービスを再起動したりしても動作し続けるべきです。そのため、サーバーにはゲームを起動するのに十分なCPUだけでは不十分です。予測可能なローカルアドレス、分離されたサービスデータ、制御されたファイルアクセス、永続的なゲームセーブ、公開プラットフォームに依存しない音声経路、そしてすべてのコンポーネントを再構築せずにイベントを復旧できる計画が必要です。

プレイヤー、ゲーム、ローカルワークフローを中心にLANパーティーを計画する

まずサーバーハードウェアではなく、イベントから始めます。参加するプレイヤー数、プレイするゲーム、各タイトルが専用サーバーに対応しているか、またはピアホスト方式でしかプレイできないか、クライアントが使用するオペレーティングシステム、リモート参加者の有無を記録します。同じ部屋で6人が過ごす夜と、複数のゲームを同時に実行する20人参加の週末イベントでは、ネットワークとコンピューティングの負荷が異なります。

参加者リストをクライアントマップに変換します。

• プレイヤー名とデバイス名
• 有線イーサネットまたはWi-Fi接続
• オペレーティングシステムとゲームプラットフォーム
• 必要なゲームバージョン、MOD、ダウンロードコンテンツ
• ヘッドセットとローカルのボイスチャットクライアント
• 共有ファイルのアップロードまたはダウンロード権限
• インターネットアクセスが必要か、ローカル限定で参加するか

このマップは、仕様の検討に入る前にワークロードを明確にします。サーバーは、アクティブなゲームセッション、音声接続、ファイルのダウンロード、セーブデータの書き込み、管理作業が正当に同時発生する最も負荷の高い組み合わせに対応できなければなりません。プレイ中に必要のないワークフローは、すべてのタスクを同時に処理できるようサーバーを設計するのではなく、イベント時間外にスケジュールしてください。

ゲームホスティング、ファイル配布、ボイスチャットに個別の役割を割り当てる

1台の物理マシンで3つすべてのサービスをホストできますが、それぞれを論理的に分離された役割として維持する必要があります。ゲームサービスは、ライブセッション、マップ、MOD、設定、セーブデータを管理します。ファイルサービスは、インストーラー、承認済みのMODパック、マップ、スクリーンショット、イベント関連文書を管理します。ボイスサービスは、チャンネル、ユーザーアクセス、一時的な通信状態を管理します。

各サービスに、他のサービスへの無制限のアクセス権を与えないでください。ファイル共有用アカウントにゲームのセーブデータへの書き込み権限は必要ありません。ゲームコンテナに音声データベースを操作する権限は必要ありません。音声管理者が自動的にホストOSの管理者になるべきでもありません。論理的な分離によって、不正なMod、誤った削除、公開されたゲスト認証情報による被害を抑えられます。

まず1台のホストを選び、テストで必要になった場合にのみ役割を分離する

小規模または中規模のLANパーティーでは、Ethernetで接続したx86ホスト1台が、通常もっとも簡単な開始トポロジーです。ゲームサーバー、ファイルサービス、音声サービスは、明示的なポート、ストレージパス、リソース要件を設定したうえで、別々のコンテナ、仮想マシン、またはネイティブサービスとして実行します。目的はコンポーネント数を最大化することではなく、運用上分離することです。

ZimaSpaceのNAS OSとゲームサーバー向けLinuxの比較は、プラットフォームの判断に役立ちます。NAS指向のシステムはストレージやアプリケーションの管理を簡単にできる一方、一般的なLinuxはゲームランタイム、コマンドラインによる更新、Modローダー、カスタムサービス定義をより直接的に制御できます。

統合した負荷に対して応答性と復旧性を維持できる場合は、ホストを1台にまとめます。大容量の転送によってライブセッションに遅延が生じる場合は、ファイル配信を別のストレージに分離します。ゲームタイトルで互換性のないライブラリ、別のオペレーティングシステム、または他のサービスと競合するメンテナンス時間が必要な場合は、ゲームの役割を分離します。ゲームの再起動やリソース不足によって通信が繰り返し中断される場合に限り、音声通信を分離します。新しいノードにはそれぞれ、測定可能で継続的な役割を持たせる必要があります。

ゲームサービスをインストールする前に有線ネットワーク経路を構築する

重要なローカル経路はシンプルです。

プレイヤーPC
    │
    ├── 有線Ethernet ──> 中央スイッチ ──> LANパーティーサーバー
    │                              │
    │                              └──> ルーター／インターネット（任意）
    │
    └── WI-FI（セカンダリまたはモバイルクライアント）

ローカルのプレイヤーとサーバー間の通信にはスイッチを使い、DHCP、DNS、必要に応じたインターネット接続にはルーターを使います。SUPERJUMPのLANパーティーガイドでは、スイッチとルーターの機能上の違いと、中央ネットワークスイッチが自然なローカル接続ポイントである理由を説明しています。

可能な限り、サーバーと主要なゲーミングPCはEthernetで接続します。スマートフォン、管理作業、ケーブルを接続できないプレイヤー向けにWi-Fiを利用できる状態にしておくのは構いませんが、ホストや特に低遅延が求められるクライアントの接続をWi-Fiだけにしてはいけません。スイッチは中央に設置し、すべてのケーブルの両端にラベルを付け、通路を保護し、予備のケーブルを1～2本と空きポートを確保しておきます。

ポート数はプレイヤー数だけでなく、トポロジー全体から決めます。サーバー、ルーターのアップリンク、無線アクセスポイント、管理用ノートパソコン、予備のプレイヤー席、その他のストレージノードを含めます。スイッチに16ポートあり、計画で16ポートすべてを使用するなら、ネットワークには復旧の余裕がありません。

インターネットに依存せずローカルアドレスを機能させる

クライアントが各サービスを安定して見つけられるようにする必要があります。プレイヤーのデバイスにはルーターからDHCPでアドレスを割り当て、LANパーティーサーバーには予測可能なアドレスを予約します。イベントネットワークにDHCPサービスがない場合を除き、ゲスト全員に手動で固定アドレスを割り当てるのは避けます。重複アドレスは、イベント当日に不要な障害を引き起こします。

次の情報を含む簡潔な接続情報シートを作成します：

• サーバーのホスト名とローカルIPアドレス
• ゲームサービスのポートと参加方法
• ボイスサーバーのアドレス
• ファイル共有のアドレスと許可された認証情報
• 使用する場合は、Wi-Fi名とゲストパスワード
• イベント管理者の名前

インターネット回線を切断した後、すべてのローカル名とアドレスをテストします。ゲーム、ファイル共有、またはボイスサービスを見つけるために、公開DNSレコード、クラウドログイン、オンラインに保存されたチャットメッセージのいずれかしか使えない場合、LANはまだ自立していません。接続情報シートを印刷するか、ローカルでホストしたコピーを用意します。

ゲームサーバーをリアルタイム運用の役割として構築する

ゲームサービスを優先します。応答がアクティブな全プレイヤーに同時に影響するためです。予定している各タイトルについて、正確なサーバービルド、ランタイム、ポート、マップローテーション、セーブ場所、MOD構成、プレイヤー上限、再起動動作を確認します。起動に1度成功しただけで、イベントに対応できる状態だと判断しないでください。

ゲームのバイナリを永続状態から分離します：

GAME_SERVERS/
├── game-a/
│   ├── application/
│   ├── config/
│   ├── mods/
│   ├── saves/
│   └── logs/
└── game-b/
    ├── application/
    ├── config/
    ├── saves/
    └── logs/

アプリケーションディレクトリは、多くの場合、再構築または更新できます。設定、承認済みのMOD、ワールドデータ、セーブデータは、意図的に保持する必要があります。ログはイベントの原因を調べるのに役立ちますが、保持期間は短くても構いません。各サーバーを起動するコマンドまたはサービス定義を文書化し、復旧が端末の履歴に依存しないようにします。

想定するプレイヤー数で代表的なマッチを1回実行します。CPU使用率、メモリ圧迫、ネットワークトラフィック、セーブの遅延、ゲームで確認できる場合はティックやシミュレーションの安定性を測定します。ファイルサービスが大容量ダウンロードを処理し、ボイスサービスにアクティブユーザーがいる状態でもテストを繰り返します。アイドル状態のダッシュボードではなく、最も負荷が重なる状態によって、ホストに十分な性能があるかどうかを判断します。

ダウンロードで試合を妨げずにゲームファイルを配布する

遅れて到着した参加者やバージョンの不一致によって、インターネット接続がイベントのボトルネックになることがあります。承認済みのModパック、カスタムマップ、サーバー構成例、その他の再配布可能なイベントファイルを、ゲストが到着する前に準備します。プラットフォームとライセンスで許可されていない限り、商用ゲームのファイルをミラーリングしないでください。

承認済みクライアント間のローカル転送に対応するプラットフォームでは、実際のイベントネットワーク上で機能をテストします。ある運営者が行ったSteamの転送実験では、HDDとSSDの両方を搭載した古いギガビット対応ノートパソコンでも、便利なローカルゲーム転送ソースとして機能することが確認されました。重要な教訓は構成にあります。転送経路には、ソースディスク、サーバーリンク、スイッチのアップリンク、受信側クライアントのすべてが関与します。

最大規模の転送は試合開始前に予定します。プレイ中もダウンロードを継続する必要がある場合は、転送速度を制限するか、テストによって再現性のある遅延やストレージ競合が発生すると確認できた場合に限り、別のストレージ経路やネットワーク経路に配置します。ゲームサービスを不安定にするなら、ファイルサービスが高速でも成功とはいえません。

イベント専用の権限でローカルファイル共有を作成する

ファイルサービスはゲストにとってシンプルで、範囲を限定したものにします。承認済みのダウンロード用に読み取り専用領域を用意し、スクリーンショット、録画、またはプレイヤーが提供したいファイル用に別のドロップフォルダーを設けます。個人のバックアップ、ホームメディア、管理用スクリプト、ホストのファイルシステムは公開しないでください。

LAN_PARTY_FILES/
├── READ_ONLY/
│   ├── connection-info/
│   ├── approved-mods/
│   ├── custom-maps/
│   └── utilities/
├── PLAYER_UPLOADS/
└── ADMIN_REVIEW/

恒久的な管理者パスワードを共有するのではなく、イベント用アカウントを使用します。ネットワーク自体を信頼できる場合に限り、読み取り専用ライブラリへのゲストアクセスを広く許可します。アップロードはアカウント、容量、またはフォルダー単位で制限し、承認済みライブラリに移動する前に確認します。パーティー終了後はイベント用認証情報を削除または無効化します。

ファイル配布は利便性のための役割なので、安全に停止できるようにすべきです。共有が停止しても、進行中のゲームやボイスチャットは継続できるようにします。ゲストが十分なデータをアップロードしてアップロード領域を使い切った場合でも、ゲームセーブ用ボリュームとシステムボリュームには予約済みの空き容量が残るようにします。

独立した通信経路としてローカルでボイスチャットをホストする

同じ部屋にいるプレイヤーでも、特に複数の部屋に分かれる場合やチームゲーム中は、ヘッドセットが必要になることがあります。また、ローカルのボイスサーバーがあれば、外部チャットプラットフォームやインターネット接続が利用できなくなっても連携を維持できます。

Mumbleは、サーバーコンポーネントをセルフホストでき、チャンネルとアクセス制御で整理できる実用的な例です。独立したDockerの手順では、永続的な設定と権限管理を備えたセルフホストMumbleサーバーを紹介しています。これは実装方法の1つとして利用し、LANトポロジーを特定のボイスアプリケーションに依存させないでください。

イベントの前にチーム用チャンネルと一般ロビーを作成します。プレイヤーには通常の参加者アカウントを使用し、管理者認証情報は分離して保管します。複数のクライアントOSから、マイク音量、プッシュ・トゥ・トーク、チャンネル切り替え、再接続をテストします。

ボイスチャットは大容量ストレージをほとんど必要としませんが、安定した可用性が必要です。データベースと設定は永続的なアプリケーションストレージに保持します。ボイスチャットを利用可能な状態に保つ必要がある場合は、ゲームサーバーの再起動、ファイル転送ジョブ、実験用コンテナによってホスト全体が自動的に再起動されないようにしてください。

永続状態、共有ファイル、キャッシュ、バックアップを分離する

すべてのサービスを1つの書き込み可能なディレクトリに指定しないでください。失失時の影響と復旧アクションに応じてデータを分離します。

1台のマシンで複数のサービスを共有する場合も、役割を優先する考え方が当てはまります。ZimaSpaceの複数のセルフホストアプリを安全に実行する方法ガイドでは、統合ホスト上でも永続状態、大容量ファイル、破棄可能な作業データ、競合するリソースを分離して管理する方法を説明しています。

ゲストアクセスとサーバー管理を分離する

LANパーティーでは、サーバー所有者が管理していないデバイスを意図的に接続します。プレイヤーアクセス、サービス管理、ホスト管理を別々の信頼レベルとして扱いましょう。プレイヤーに必要なのはゲームポート、ボイスチャットへのアクセス、限定的なファイルパスです。サービス管理者はゲームを再起動したりチャンネルを変更したりできます。コンテナ、ストレージ、ファイアウォールルール、バックアップ、オペレーティングシステムを管理できるのは、ホスト管理者だけにしてください。

利用可能なルーターとスイッチが対応しており、分離によって必要なローカル検出が妨げられない場合は、ゲストネットワークまたは専用のイベントVLANを使用します。むやみにセグメント化しないでください。ローカル転送や検出の一部の機能は、クライアント同士が互いを見つけられることに依存しています。ファイアウォールルールを適用した後、サービスの一連の動作を実際にテストしましょう。

ZimaSpaceのコンシューマールーターと専用ファイアウォールの比較は、ゲスト分離、VLANポリシー、イベントの頻度が基本的なホームルーターの範囲を超えた場合に、次の判断を行うための参考になります。

管理インターフェースを共有ファイルページから分離し、接続情報シートに管理者パスワードを記載しないでください。イベント終了後は一時アカウントを削除し、共有パスワードを変更し、不要なポートを閉じ、サーバーを通常の家庭内サービスに再接続する前にアップロードされたファイルを確認します。

イベントを過剰設計せずにインターネットと停電に備える

ローカルサーバーを使うとインターネットへの依存を減らせますが、すべてのゲームが自動的にオフライン対応になるわけではありません。各タイトルで、プラットフォーム認証、ライセンス確認、マッチメイキング、ワークショップのダウンロード、クラウド専用サービスのいずれが必要かを確認します。イベント前に必要なサインインとアップデートを済ませ、アップリンクを切断した後も何が動作するかをテストしましょう。

ルーター、スイッチ、サーバーを安定した電源系統に接続します。UPSがあれば安全にシャットダウンする時間を確保できますが、すべてのゲーミングPCをUPSに接続する必要はありません。シャットダウンの順序を文書化し、ストレージをアンマウントする前にゲームサービスがワールドやセッションの状態を保存できるようにします。

リスクに見合った代替策を準備しましょう。サーバー設定とセーブデータのコピーを別のドライブに保存します。接続情報シートはオフラインでも確認できるようにしておきます。メインのゲームが認証できない場合に備え、ゲストを待たせたままネットワークを作り直そうとするのではなく、動作確認済みのローカルな代替ゲームを1～2本用意しておきましょう。

想定される最も忙しい重複状態でLAN全体を検証する

イベントを、3つのアプリケーションを個別に起動するのではなく、ワークフローとしてテストします。代表的なクライアントデバイスを接続し、予定している中で最大規模のゲームセッションを開始し、ユーザーを音声チャンネルに参加させ、承認済みの大容量ファイルを転送し、ゲームのセーブデータを書き込み、管理ページを開いたままにします。

• すべてのクライアントが一意のアドレスを取得し、サーバーを名前解決できることを確認します。
• 参加にかかる時間、ゲームの応答性、パケット損失、サーバーのリソース使用量を測定します。
• ファイル転送によってゲームや音声に支障が生じないことを確認します。
• ファイルや音声の役割を中断せずに、ゲームサービスを1つ再起動します。
• システムやセーブデータ用ボリュームを満杯にせず、アップロード容量の上限までファイルを転送します。
• インターネットを切断し、ローカル参加をもう一度行います。
• バックアップからゲームのセーブデータを1つとサービス設定を1つ復元します。

テストが十分な余裕をもって成功したら、複雑さを増やすのをやめます。適切なスケジューリングと制限を行っても同じリソース競合が再発する場合は、その原因となっている役割を分離します。ゲームでCPUボトルネックが繰り返し発生するなら専用コンピュートを、ファイル転送が共有ストレージを飽和させるなら別のデータパスを、ホストのメンテナンス中に音声が途切れるなら独立した軽量ノードを用意する根拠になります。

ポータブルLANパーティーホストが再利用可能なローカルサーバーになるとき

テスト済みのワークロードを維持でき、故障しても家庭の重要なデータが危険にさらされない場合は、予備のノートパソコンやデスクトップで一度きりの実験には十分です。イベントが繰り返される場合、複数のサービスをセッション間でも設定済みの状態に保つ必要がある場合、またはゲーミングPCを転用せずにホストを持ち運ぶ必要がある場合は、専用のコンパクトサーバーがより役立ちます。

このコンパクトなコンピュートおよびネットワークサービスの役割には、ZimaBoard 2 Mini Home Serverが、デュアル2.5GbE LAN、2つのSATAポート、PCIe拡張を備えたx86プラットフォームを提供します。これらのインターフェースにより、有線サーバーパスと計画的なローカルストレージの選択肢が生まれますが、適切なエディションとストレージ構成は、テスト済みのゲーム、プレイヤー数、サービスの重複、保持要件によって異なります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

定義されていないトポロジーの修正まで製品に担わせないでください。まず、ゲーム、ファイル、音声、ID、バックアップ、復旧の各役割を決めます。ファイルライブラリが後に小規模な2ドライブ構成の役割を超えて拡大した場合は、大容量ストレージを専用NASに移し、ゲームと音声のサービスはコンピュートノードに残します。そのストレージ優先の役割に測定可能な必要性が生じた場合にのみ分離してください。

再構築が難しい状態をバックアップする

ゲームのセーブデータ、ワールドデータ、サービス設定、承認済みMODマニフェスト、ボイス権限、スクリプト、接続情報シートを優先します。ゲームバイナリやキャッシュは置き換えられる場合がありますが、グループで使用した正確な正常構成は保持する価値があります。

最終的に成功したリハーサルの後、イベント前のスナップショットまたはバックアップを取得します。パーティー後にも、進行状況、スクリーンショット、録画、設定に変更があれば、もう一度取得します。少なくとも1つのコピーはサーバーの外部に保存してください。RAIDやミラーリングディスクはドライブ故障後の可用性を高める可能性がありますが、削除、問題のあるアップデート、認証情報の漏洩、ホスト全体の喪失からデータを保護するものではありません。

サーバーに長期保存するワールド、コミュニティファイル、その他再作成できないデータが蓄積され始めたら、ZimaSpaceの3-2-1バックアップ戦略を使用します。コピーしたフォルダーが正しく起動すると決めつけず、クリーンなサービスパスに復元してテストしてください。

LANパーティーサーバーのセットアップチェックリスト

1週間前

• 参加人数、ゲーム、バージョン、MOD、プラットフォーム要件を確認します。
• ゲーム、ファイル、ボイスサービスの役割を定義します。
• スイッチのポート、Ethernetケーブル、サーバーアドレス、任意のインターネット uplinkを対応付けます。
• イベント用アカウントを作成し、永続データ用のパスを分離します。

1日前

• 複数の負荷が重なる状況を想定した完全なリハーサルを実施します。
• アップデートと必要なオンライン認証を完了します。
• インターネット接続を切った状態で、ローカルからの参加を確認します。
• 正常な状態が確認できているバックアップを取得し、代替ゲームを用意します。

LANパーティー開催中

• イベント用の認証情報を使用し、ホスト管理情報を非公開にします。
• ライブセッションに影響が出る場合は、大容量転送の速度を制限するか、後回しにします。
• 空き容量、温度、サービスの状態、セーブの動作を監視します。
• ゲストがアップロードしたファイルをレビュー領域に移動します。

イベント終了後

• ゲームサービスを正常に停止し、最終セーブを確認します。
• 承認済みの変更内容とプレイヤーの貢献データをバックアップします。
• 一時アカウントを無効化し、共有認証情報を更新します。
• 次回のイベントでトポロジーを変更する前に、ボトルネックを記録します。

プレイヤーがゲームに参加し、承認済みファイルをダウンロードし、文書化された手順でローカルボイスチャットを利用でき、各サービスが他のサービスの管理権を奪わずに再起動・復旧できれば、セットアップは完了です。

LANパーティーサーバーに関するよくある質問

インターネット接続なしでLANパーティーを開催できますか？

はい。選択したゲームがローカルプレイまたは専用サーバープレイに対応しており、必要な認証、アップデート、ライセンス、マップ、MODを事前にすべて準備している場合は可能です。一部のゲームはオンラインプラットフォームのサービスに依存しているため、インターネット接続を切った状態で、参加手順全体をテストしてください。

LANパーティーにはルーターが必要ですか、それともスイッチだけで十分ですか？

スイッチはローカルデバイスを接続できますが、ルーターはDHCPを提供してアドレス設定を簡単にし、任意でインターネットアクセスも提供できます。一般的な家庭のイベントでは、サーバーとプレイヤーを中央のスイッチに接続し、そのスイッチをルーターに接続してください。

すべてのゲーミングPCでイーサネットを使うべきですか？

可能な限り、サーバーと遅延に敏感なゲーミングPCには有線イーサネットを使用してください。Wi-Fiはモバイル端末、管理、予備クライアントに利用できますが、主要なゲーム通信経路として頼る前に、実際の部屋の環境でテストしてください。

1台のマシンで複数のゲームサーバーを同時にホストできますか？

ホストのテスト済み容量の範囲内にCPU、メモリ、ストレージ、ネットワークの合計負荷が収まるなら、可能です。各ゲームに専用のポート、永続データ、再起動手順を用意し、想定する同時プレイヤー数でテストしてください。

LANパーティー用サーバーでは、どのファイルを共有すべきですか？

カスタムマップ、MODパック、設定ガイド、ユーティリティ、イベント情報など、承認済みで合法的に再配布できるコンテンツのみを共有してください。ダウンロードは読み取り専用にし、プレイヤーのアップロードは確認用の別の制限付きフォルダーに保存します。

Steamでローカルネットワーク経由でゲームを転送できますか？

Steamは、対象となるクライアント間でローカルネットワーク経由のゲーム転送に対応していますが、アカウント権限、クライアント設定、ゲームの状態、ストレージ速度、ネットワーク構成によって結果が左右されます。イベント前に、使用するクライアントとスイッチ構成を実際にテストし、代替手段なしで依存しないようにしてください。

全員が同じ建物にいるのに、なぜボイスチャットをローカルでホストするのですか？

ローカルボイスチャットは、部屋をまたいでチームを分散させやすく、ヘッドセットでの通話品質を一定に保ち、公開チャットプラットフォームに依存しない手段を提供します。ゲームサーバーの再起動後も稼働する独立したサービスとして構成すると、特に便利です。

ゲームサーバーにはコンテナと仮想マシンのどちらを使うべきですか？

ゲームが互換性のあるホストOSとランタイムを共有する場合、コンテナは効率的です。タイトルによって異なるライブラリ、管理ツール、または保守上の分離が必要な場合は、仮想マシンのほうがOSを強力に分離できます。流行ではなく、互換性と復旧性を基準に選んでください。

リモートの友人は、ローカルLANパーティー用サーバーにどう参加できますか？

リモートプレイヤーには、認証済みのプライベートネットワークや、ゲームごとに慎重に設定した公開経路など、意図的に保護された接続経路が必要です。リモートアクセスは、すべてのローカルサービスを公開するのではなく、インターネット帯域幅、認証情報、ファイアウォール、セキュリティ要件を備えた別のトポロジーとして扱ってください。

イベント前に何をバックアップすべきですか？

ゲームのセーブデータ、ワールドデータ、設定、承認済みのMODリスト、ボイス設定、サービス定義、スクリプト、接続情報をバックアップします。少なくとも1つのコピーがLANパーティー用サーバーの外部に保存されていることを確認し、クリーンリストアを1回テストします。