MMORPGサーバーのメンテナンス
ほとんどのmmorpgゲームには、定期的なサーバーメンテナンス、毎日のメンテナンス、週に1回のメンテナンスがあるようです。彼らが実際にしなければならないことは何ですか、そしてなぜそれが必要なのですか？
そのようなプロジェクトから始める場合、これを回避するために何ができますか？
彼らは最新バージョンのコードをデプロイしていると思います。アプリケーションを再起動する必要があります（うまくいけば、アクセスを再度有効にする前にいくつかのテストを実行します）。その観点からすると、それはStackOverflowの問題であり、ServerFaultの問題ではありません。
ホットパッチシステムを作成することは可能だと思いますが、それは必然的に信じられないほど複雑になるでしょう。私が理解していることから、MMOサーバー "アプリケーション"はいくつかの異なるコンポーネントで構成されています-
ログインサーバー-認証を処理し、ゲームプレイサーバー間の「ハブ」として機能します。クライアントがゲーム内に入ると、クライアントはログインサーバーと対話しなくなります。このようなシステムでは、ゲームプレイを妨げることなく、パッチを適用してログインサーバーを再起動できます（ただし、他の人がログインできない期間があります）。
ゲームプレイサーバー-論理的に独立したユニット（「ワールド」など）にグループ化されたマシンのクラスター。各ゲームプレイクラスターは、状態を相互に対応させるために、ある種の内部通信プロトコルを使用すると想定されています。おそらく、各クラスターに一度にパッチを適用する必要があります。これを行う1つの可能な方法は、ウォームフェイルオーバーにパッチを適用することです。次に、両方ができる必要があります
- ウォームフェイルオーバーに接続し、古いクラスターから切断するようにクライアントに通知します。
- すべてのクライアントが転送している間、フェイルオーバーと古いアプリケーションサーバーの間で同期された状態を維持します。
データベースサーバー-RDBMSのようなある種の永続的なデータストア。データストアにそれほど頻繁に変更を加えていないことを願っています。おそらく、各ゲームプレイサーバー/クラスターには独立したデータストアがあります。ウォームフェイルオーバーでも同じトリックを使用できる場合があります（そして、ゲームプレイサーバーを切断し、古いデータベースとフェイルオーバーデータベースが同期するのを待ってから、フェイルオーバーに再接続するように指示します）。
上記のすべてのケースは、すでに複雑なシステムに信じられないほどの複雑さを追加し、コードの障害がデータの損失や破損を引き起こす可能性のある場所をたくさんもたらします。
もう1つの解決策は、100％の稼働時間用に設計され、実行中のコードをホットパッチする機能が組み込まれている言語を使用することです。 Erlang は良い選択です（ ホットパッチの例 ）、そして Javaには同様の機能があります 。
このようなものを実際に実行した経験は誰もありませんか？ええと。
コードとシステムの両方をブリッジする理由はいくつかあります。まず、現在の「大きな」MMO=エンジンのほとんどは数年前にプログラムされており、それ以来グラフィックとテクノロジーのアップグレードにもかかわらず、これらのシステムの多くが2000年に書かれた方法に依存していることを覚えておいてください。たとえば、Eve-Onlineは、依然として1つの巨大なMicrosoft SQL Serverインスタンスで実行されているため、ハードウェアをアップグレードすることで常にそれを最大限に活用しようとしています。
WoWとEVEが開始されてからの改善の例は、GoogleのMapReduce（およびオープンソース実装であるHadoop）などの分散キー/値データベース、非常に高速な肯定応答処理キューサービス（Amazon SQS）、およびその他の「クラウド」指向のテクノロジー。
私はEVEの経験が最も豊富です（私はBattleaxesの男よりもレーザーの男です）。これらの例のいくつかは、よりEVE指向です。
システムの理由による限り：
- 物理ノードは一貫して失敗します。ノードに障害が発生すると、通常、そのアクティビティは任意の数の手段を使用して他の場所に移行されます。ただし、ノードはできるだけ早くサービスを再開する必要があります。 EVEの場合、それらはスタックレス処理言語と仮想サーバーの両方を使用します。 Blizzardのアーキテクチャがどのようなものかはわかりません。
- データベースの整合性をチェックし、ログをフラッシュし、インデックスとデータキャッシュを再構築する必要があります。これは、「ライブ」データベースインスタンスが1つしかないEVEのようなシステムでは特に重要です。
- オペレーティングシステムのパッチは、他の場所に移行するアクティビティが多すぎることなくノードを再起動できるときに適用する必要があります。移行には、オンライン処理専用のネットワークリソースが大量に消費されます。
- RDBMSベースのMMOには、データのロックと参照整合性に関する大きな問題があります。ダウンタイムは、古くなったロックとアクティビティログからの整合性の破壊をクリーンアップするために使用されます。
- ほとんどのゲームは、静的または半静的（以下の要約データのキャッシュを参照）情報の地理的に配置されたデータキャッシュを実装しており、米国東海岸と西海岸の使用頻度の高い地域で使用されています。これらのキャッシュは、ダウンタイム中に手動で更新されます。
ソフトウェアの理由による限り：
- ゲーム、操作時には、OLTP-オンライントランザクション処理-データベースへの読み取り/書き込みのタイプです。ただし、要約レポートが必要な場合があります...過去3年間の粉砕で殺した特定の獣。これは、OLAPレポート-オンライン分析処理-レポートの多くの行に基づく要約情報を含む巨大なデータセット。実際には、ゲームは、OLAPを使用してキャッシュを構築し、読み取る必要のあるクエリの数を制限するシステムを実装します。つまり、特定の日付の合計を構築します。 、そして質問をすると、彼らはOLTPストアから特定の日付以降の期間を要約する行を読み取ります。2つをマージすると、実際にあなたの人生の価値がないことを数量化できますなる。
- 前述のホットパッチは、ソフトウェアの問題と見なされますが、ソフトウェア開発者はシステムの問題と見なされます。 ;）
- アイテムの店の補充-イブでは、小惑星帯が毎晩更新され、特定の複合施設もリサイクルされます。これはある程度オンラインで実行できますが、一部のアルゴリズムは複雑すぎてオフラインモードで実行する必要があります。これは、前日の経済活動を要約している間、データベースが一時的に停止するためです。
MMO演算子-閉じたループと開いたループの両方でエコノミーを実行することは、私が信じられない場合は、ゲームエコノミーについて書かれた学術論文のいくつかと比較的原始的な経済があったウルティマオンラインのような古いゲームの研究。オープンループを補充し、不正行為やその他のマイナスの経済活動を特定するために必要な分析は、データのスナップショットを使用してオフラインで行う必要があります。データベースが完全にロックされている間に取得されます。
気づくと思いますが、イブのメンテナンスは、プライマリデータセンターがあるイギリスの正午に行われます。
Blizzard（火曜日の朝であるため、質問を投稿していることを考えると）がメンテナンスのために引用する合計時間は、クラスター全体に対するものだと思います。すべてのサーバーで作業を実行するのにそれほど時間がかかるわけではありません。
個々のサーバーをより迅速に再起動することは可能かもしれませんが、それはたまたまレルムがスケジュールの早い段階で落ちたプレイヤーに不利な叫びを引き起こします。そのため、すべての作業が完了するまで、すべてを抑制します。何百ものレルムで作業するため、おそらく彼らは多くの作業を並行して行いますが、最終的なチェックをシリアル化してから、物事をオンラインに戻します。ハードウェアのアップグレードを行っている場合、これはおそらく、できるだけ多くのデータセンターでシリアル化されます。
なぜメンテナンスを実行するのかについては、パフォーマンスの再起動だけの場合もあります。このような再起動が必要ないのは素晴らしいことですが、そうすることのコストとそうしないことの影響が、ここでの選択に影響を与える可能性があります。
プロセスをクラスター化してローリングメンテナンスを実行できない理由を見ると、WoWインフラストラクチャについてほとんど知られていないことから、複数のマシンが各レルムにサービスを提供していることがわかります（1つは世界、1つはインスタンスとRAID、1つは戦場に）など）、状態共有のアクティブ/アクティブプロセス設定を使用しません。ライブ状態の共有はなく、データベースを介した永続データのみが共有されます。
結局、その大規模な加入者ベースにステートフルなオンラインサービスを提供するメカニズムは、ウェブサイトや他の従来のインターネットベースのサービスについて語るときに推奨されるいくつかのベストプラクティスに挑戦します。
EvEオンラインの最近の拡張ダウンタイムの一部は、より高速なSANなどの新しいハードウェアのインストールに関するものです。新しいドライブに新しいファイルグループを作成し、メインのファイルグループを空にすることで、データの大部分を技術的に移動することはできますが、I/Oが一定しているため、パフォーマンスが長期間低下することになります。したがって、それらは opted を使用して1.1TBデータベースを切り離し、一度に移動します。
この質問への答えも、特定のアプリケーションに依存しています。たとえば、特定のスターシステムを処理するサーバーは、ゲームのプレイを中断することなくホットスワップできないため、ダウンタイムを使用して、より強力なサーバーを潜在的なホットスポットに再割り当てします。さらに、星系の所有権計算（主権）が計算されます。これは何十もの異なる変数に依存し、それらはすべてプレーヤーのアクションに応じて変化する可能性があります。言うまでもなく、そのライブを行うと、過度のロックやその他の同時実行性の問題が発生する可能性があります。しかし、それらのアドレス指定は stackoverflow に任せるのが最善です。
私はMMOアーキテクチャをErlangに実装して、ホットコードのアップグレードと配布をサポートしています。たとえば、オブジェクトのハードウェアアップグレードが必要な場合、1台の「GamePlay Server」を任意の数のマシンで実行できます。他のマシンに（リアルタイムで）転送できるため、ダウンタイムなしでソフトウェアハードウェアをアップグレードできます。
http://www.next-gen.cc で私のサイトをチェックアウトできます。
メンテナンスウィンドウでは、コンポーネントが故障しないようにするために定期的なハードウェアの交換も可能であると思います。
おそらく、DBスキーマの大きな変更など、クラスタリング/負荷分散では処理できなかったものです。
最近のトピック Linuxサーバーを再起動する頻度 別の良い点が述べられており、再起動時または（大きな）構成変更後にすべてが正しく起動することを確認します。
ハードウェアの単純なアップグレード（またはハードウェアの交換）もMMORPGゲームによって "サーバーメンテナンス"として表示されます。そのため、簡単に忘れてしまいがちです。