Pemeliharaan server MMORPG

Tampaknya sebagian besar game mmorpg memiliki beberapa pemeliharaan server reguler, beberapa setiap hari, beberapa sekali seminggu. Apa yang sebenarnya harus mereka lakukan, dan mengapa itu perlu?

Jika Anda memulai dengan proyek seperti itu, apa yang dapat Anda lakukan untuk menghindari hal ini?

Saya menduga mereka sedang menyebarkan versi terbaru dari kode mereka, yang mengharuskan mereka me-restart aplikasi (dan mudah-mudahan menjalankan beberapa tes sebelum mengaktifkan kembali akses). Dari sudut pandang itu, ini lebih merupakan masalah StackOverflow dan lebih sedikit dari yang ServerFault.

Saya pikir itu mungkin untuk membuat sistem hot-patching, tetapi tentu akan sangat rumit. Dari apa yang saya mengerti, "aplikasi" server MMO terdiri dari beberapa komponen yang berbeda -

• Login server - Menangani otentikasi dan bertindak sebagai "hub" antara server gameplay. Setelah klien berada dalam gim, mereka tidak lagi berinteraksi dengan server masuk. Dalam sistem seperti itu Anda bisa menerapkan tambalan dan memulai kembali server login tanpa mengganggu gameplay (meskipun Anda akan memiliki periode waktu di mana orang tidak akan bisa masuk).

• Server gameplay - Cluster mesin yang dikelompokkan ke dalam unit logis independen ("dunia", dll). Diasumsikan bahwa masing-masing kluster gameplay menggunakan semacam protokol komunikasi internal untuk saling berhubungan satu sama lain; Anda mungkin harus menambal setiap cluster sekaligus. Salah satu cara yang mungkin untuk melakukan ini adalah dengan menambal failover hangat. Anda kemudian harus bisa melakukan keduanya

  1. Memberi tanda klien untuk terhubung ke failover hangat dan memutuskan sambungan dari kluster lama.
  2. Tetap sinkronkan keadaan antara failover dan server aplikasi yang ketinggalan zaman saat semua klien transfer.

• Server database - Semacam datastore persisten, seperti RDBMS. Semoga Anda tidak membuat perubahan pada datastore sesering itu. Agaknya setiap server permainan / cluster memiliki datastore independen. Anda mungkin dapat menggunakan trik yang sama dengan failover hangat (dan memberi tahu server gameplay untuk memutuskan sambungan, tunggu database lama dan failover untuk disinkronkan, lalu sambungkan kembali ke failover) tetapi itu tampaknya cukup berisiko bagi saya.

Semua kasus di atas menambah kompleksitas yang luar biasa ke sistem yang sudah kompleks dan memperkenalkan banyak tempat di mana kegagalan kode dapat menyebabkan kehilangan data atau kerusakan.

Solusi lain adalah dengan menggunakan bahasa yang dirancang untuk 100% uptime dan memiliki kemampuan bawaan untuk hotpatching kode yang sedang berjalan. Erlang adalah pilihan yang baik ( contoh hotpatching ), dan Java memiliki fungsi serupa .

Tidak ada orang lain yang memiliki pengalaman menjalankan sesuatu seperti ini? Hah.

Ada beberapa alasan yang menjembatani kode dan sistem. Pertama, ingat bahwa sebagian besar mesin MMO 'besar' saat ini diprogram beberapa tahun yang lalu, dan meskipun ada peningkatan grafis dan teknologi sejak itu, masih tergantung pada cara banyak sistem ini ditulis pada tahun 2000 atau lebih. Eve-Online, misalnya, masih berjalan pada satu contoh besar Microsoft SQL Server, itulah sebabnya mereka selalu berusaha menarik lebih banyak darinya dengan memutakhirkan perangkat keras.

Contoh peningkatan sejak WoW dan EVE dimulai adalah pekerjaan yang dilakukan dalam database kunci / nilai terdistribusi seperti Google MapReduce (dan ini adalah implementasi open-source, Hadoop), layanan antrian pemrosesan respons afirmatif yang sangat cepat (Amazon SQS), dan lainnya " cloud "berorientasi teknologi.

Saya memiliki pengalaman paling banyak dengan EVE (saya lebih seperti pria laser daripada pria battleaxes), jadi beberapa contoh ini lebih berorientasi pada EVE.

Sejauh alasan Sistem:

• Node fisik gagal secara konsisten. Ketika sebuah simpul gagal, biasanya aktivitasnya dimigrasi ke tempat lain menggunakan sejumlah cara. Namun, simpul perlu dimasukkan kembali ke layanan secepat mungkin. Dalam kasus EVE, mereka menggunakan bahasa pemrosesan stackless dan server virtual; Saya tidak yakin seperti apa arsitektur Blizzard.
• Konsistensi basis data perlu diperiksa, log harus disiram, dan indeks dan cache data perlu dibangun kembali. Ini sangat penting dalam sistem seperti EVE dengan hanya satu contoh basis data "langsung".
• Tambalan sistem operasi perlu diterapkan pada saat mereka dapat mem-boot ulang node tanpa harus memiliki terlalu banyak aktivitas yang bermigrasi ke tempat lain. Migrasi membutuhkan banyak sumber daya jaringan yang dapat didedikasikan untuk pemrosesan online.
• MMO berbasis RDBMS memiliki masalah besar dengan penguncian data dan integritas referensial. Downtime digunakan untuk membersihkan kunci basi dan jeda integritas dari log aktivitas.
• Sebagian besar game menerapkan cache data yang berlokasi geografis untuk informasi statis atau semi-statis (lihat data ringkasan cache di bawah) di area penggunaan berat, yaitu pantai timur vs pantai barat AS. Tembolok ini diperbarui secara manual selama waktu henti.

Sejauh alasan Perangkat Lunak:

• Game, saat beroperasi, menggunakan banyak OLTP - yaitu On Line Transaction Processing - jenis membaca / menulis ke basis data. Namun, terkadang Anda menginginkan laporan ringkasan ... seperti berapa banyak binatang buas tertentu yang telah Anda bunuh dalam 3 tahun terakhir penggilingan. Itu paling baik ditangani oleh laporan OLAP - yaitu On Line Analytical Processing - yang berisi informasi ringkasan berdasarkan banyak baris dalam dataset raksasa. Pada kenyataannya, gim menerapkan sistem yang menggunakan OLAP untuk membangun cache untuk membatasi jumlah kueri yang perlu dibaca - yaitu, mereka membangun total pada tanggal tertentu, dan kemudian ketika Anda mengajukan pertanyaan mereka hanya membaca baris dari toko OLTP yang merangkum periode waktu sejak tanggal tertentu. Gabungkan keduanya, dan Anda benar-benar dapat menghitung seberapa tidak berharga hidup Anda jadinya.
• Hot-patching yang disebutkan di atas, yang saya lihat sebagai masalah perangkat lunak tetapi pengembang perangkat lunak melihat sebagai masalah sistem. ;)
• Mengisi ulang toko barang - di Eve, sabuk asteroid disegarkan setiap malam dan kompleks tertentu didaur ulang juga. Hal ini dapat dilakukan sampai batas tertentu saat online, tetapi beberapa algoritma terlalu kompleks dan perlu dilakukan dalam mode off-line karena mereka secara singkat membawa database ke lutut sementara mereka merangkum kegiatan ekonomi hari sebelumnya.

Menjalankan ekonomi dengan loop tertutup dan terbuka adalah salah satu masalah bagi operator MMO - jika Anda tidak percaya, baca beberapa makalah akademis yang telah ditulis tentang ekonomi gim dan beberapa studi gim lama seperti Ultima Online yang memiliki ekonomi yang relatif primitif. Analisis yang perlu terjadi untuk mengisi loop terbuka dan untuk mengidentifikasi kecurangan dan kegiatan ekonomi negatif lainnya perlu terjadi secara offline dengan snapshot data, yang kadang-kadang hanya dapat diambil ketika database sepenuhnya terkunci.

Jika Anda perhatikan, pemeliharaan Eve terjadi saat ini siang di Inggris, di mana pusat data utama berada.

Saya menduga bahwa total waktu Blizzard (saya menyimpulkan bahwa mengingat hari Selasa pagi bahwa Anda memposting pertanyaan Anda) mengutip untuk pemeliharaan adalah untuk seluruh cluster; tidak setiap server membutuhkan waktu lama untuk melakukan pekerjaan.

Meskipun dimungkinkan untuk membuat server individual kembali lebih cepat, itu akan menyerukan teriakan favoritisme terhadap pemain yang wilayahnya jatuh lebih awal dari jadwal. Dengan demikian, mereka menyimpan semuanya sampai semua pekerjaan selesai; dengan ratusan bidang untuk dikerjakan, mereka mungkin melakukan banyak pekerjaan secara paralel, tetapi masih membuat serial pemeriksaan final sebelum membawa semuanya kembali online. Jika Anda melakukan pemutakhiran perangkat keras, ini mungkin diserialisasi di sebanyak mungkin pusat data.

Mengenai mengapa mereka melakukan pemeliharaan, beberapa di antaranya mungkin hanya reboot kinerja. Meskipun akan lebih bagus jika reboot seperti itu tidak diperlukan, biaya untuk melakukannya vs dampak dari tidak melakukannya mungkin mengarahkan pilihan mereka di sini.

Ketika Anda melihat mengapa mereka tidak dapat mengelompokkan proses dan melakukan pemeliharaan bergulir, apa yang diketahui sedikit orang tentang infrastruktur WoW menunjukkan bahwa beberapa mesin menyediakan layanan untuk setiap bidang (yaitu satu untuk dunia, satu untuk instance dan raid, satu untuk medan pertempuran , dll.) mereka tidak menggunakan pengaturan proses aktif-aktif yang dibagikan negara. Tidak ada pembagian status aktif, hanya data persisten melalui database.

Pada akhirnya, mekanisme penyediaan layanan online yang canggih untuk basis pelanggan yang besar menantang beberapa praktik terbaik yang mungkin kita dukung ketika berbicara tentang sebuah situs web atau layanan berbasis internet tradisional lainnya.

Beberapa waktu henti yang diperpanjang baru-baru ini di EvE Online adalah tentang memasang perangkat keras baru seperti SAN yang lebih cepat. Sementara seseorang dapat secara teknis memindahkan sebagian besar data dengan membuat grup grup baru pada drive baru dan kemudian mengosongkan yang utama, itu akan menghasilkan periode yang panjang dari penurunan kinerja karena I / O yang konstan. Jadi mereka memilih untuk melepaskan basis data 1.1TB dan memindahkannya dalam sekali jalan.

Jawaban untuk pertanyaan ini juga bergantung pada aplikasi spesifik. Misalnya, server yang menangani sistem bintang tertentu tidak dapat ditukar secara panas tanpa mengganggu permainan, jadi downtime digunakan untuk menetapkan kembali server yang lebih kuat ke dalam hotspot potensial. Selain itu, perhitungan kepemilikan (kedaulatan) sistem bintang dihitung. Ini tergantung pada puluhan variabel yang berbeda, yang semuanya dapat berubah tergantung pada tindakan pemain. Tak perlu dikatakan, melakukan itu langsung dapat menyebabkan penguncian yang berlebihan dan / atau masalah konkurensi lainnya. Tetapi mengatasi itu sebaiknya diserahkan ke stackoverflow .

mungkin sesuatu yang tidak bisa Anda tangani melalui pengelompokan / load-balancing seperti perubahan skema DB besar.

Dalam sebuah topik baru-baru ini Seberapa sering saya harus me-reboot server linux, ada baiknya juga disebutkan, memverifikasi bahwa semuanya berjalan dengan benar pada reboot atau setelah perubahan konfigurasi (utama).

Upgrade perangkat keras yang sederhana (atau penggantian perangkat keras) juga disajikan sebagai "pemeliharaan server" oleh game MMORPG. Jadi sepele kita sering melupakannya.

Saya telah mengimplementasikan arsitektur MMO di Erlang yang mendukung peningkatan dan distribusi kode panas. Sebagai contoh, satu "GamePlay Server" dapat berjalan melintasi sejumlah mesin arbiter, jika seseorang memerlukan upgrade perangkat keras, objeknya dapat ditransfer (dalam waktu nyata) ke mesin lain. Ini memungkinkan peningkatan perangkat keras perangkat lunak tanpa downtime.

Anda dapat memeriksa situs saya di http://www.next-gen.cc .

Saya percaya bahwa jendela perawatan juga memungkinkan penggantian perangkat keras rutin untuk memastikan komponen tidak rusak.