Manutenção do servidor MMORPG

Parece que a maioria dos jogos mmorpg tem alguma manutenção regular do servidor, alguns todos os dias, outros uma vez por semana. O que é que eles realmente precisam fazer e por que é necessário?

Se você começar com um projeto assim, o que você pode fazer para evitar isso?

Eu suspeito que eles estejam implantando a versão mais recente de seu código, o que exige que eles reiniciem o aplicativo (e esperemos que executando alguns testes antes de reativar o acesso). Desse ponto de vista, é mais um problema StackOverflow e menos um ServerFault.

Eu acho que é possível criar um sistema de hot-patch, mas seria necessariamente incrivelmente complicado. Pelo que entendi, um "aplicativo" do servidor MMO consiste em vários componentes diferentes -

• Servidor de login - lida com autenticação e atua como um "hub" entre servidores de jogo. Quando um cliente está no jogo, ele não interage mais com o servidor de login. Nesse sistema, você pode aplicar patches e reiniciar o servidor de login sem interferir na jogabilidade (embora você tenha um período de tempo em que as pessoas não poderão fazer login).

• Servidores de jogabilidade - Clusters de máquinas agrupadas em unidades independentes lógicas ("mundos" etc.). Supõe-se que cada cluster de jogabilidade use algum tipo de protocolo de comunicação interna para corresponder o estado um ao outro; você provavelmente precisará corrigir cada cluster de uma só vez. Uma maneira possível de fazer isso é corrigir um failover quente. Você precisaria ser capaz de ambos

  1. Sinalize o cliente para conectar-se ao failover quente e desconecte-se do cluster antigo.
  2. Mantenha o estado sincronizado entre o failover e o servidor de aplicativos desatualizado enquanto todos os clientes são transferidos.

• Servidores de banco de dados - algum tipo de armazenamento de dados persistente, como um RDBMS. Espero que você não esteja fazendo alterações no armazenamento de dados com tanta frequência. Presumivelmente, cada servidor / cluster de jogabilidade possui um armazenamento de dados independente. Você pode usar o mesmo truque com um failover quente (e dizer aos servidores de jogo para desconectar, aguardar a sincronização dos bancos de dados antigos e de failover e reconectar-se ao failover), mas isso me parece bastante arriscado.

Todos os casos acima adicionam uma quantidade incrível de complexidade a um sistema já complexo e introduzem vários locais onde uma falha no código pode causar perda ou corrupção de dados.

Outra solução é usar uma linguagem projetada para 100% de tempo de atividade e com recursos internos para código de execução de hotpatching. Erlang é uma boa opção ( exemplo de hotpatching ) e Java tem uma funcionalidade semelhante .

Ninguém mais tem experiência realmente executando algo assim? Hã.

Há várias razões que unem o código e os sistemas. Primeiro, lembre-se de que a maioria dos atuais 'grandes' mecanismos MMO foram programados há vários anos e, apesar das atualizações gráficas e tecnológicas desde então, ainda dependem da maneira como muitos desses sistemas foram escritos em 2000. O Eve-Online, por exemplo, ainda é executado em uma grande instância do Microsoft SQL Server, e é por isso que eles estão sempre tentando extrair mais disso, atualizando o hardware.

Um exemplo de melhoria desde o início do WoW e EVE é o trabalho realizado em bancos de dados de chave / valor distribuídos, como o MapReduce do Google (e sua implementação de código aberto, Hadoop), serviços de fila de processamento de resposta afirmativa extremamente rápidos (Amazon SQS) e outros " tecnologias orientadas à nuvem ".

Eu tenho mais experiência com EVE (eu sou mais um cara de laser do que um cara de batalha), então alguns desses exemplos são mais orientados a EVE.

No que diz respeito às razões dos sistemas:

• Nós físicos falham em uma base consistente. Quando um nó falha, normalmente sua atividade é migrada para outro local usando qualquer número de meios. No entanto, o nó precisa ser colocado em serviço o mais rápido possível. No caso do EVE, eles usam uma linguagem de processamento sem pilha e servidores virtuais; Não tenho certeza de como é a arquitetura da Blizzard.
• A consistência do banco de dados precisa ser verificada, os logs precisam ser liberados e os índices e caches de dados precisam ser reconstruídos. Isso é especialmente importante em um sistema como o EVE com apenas uma instância de banco de dados "ativa".
• As correções do sistema operacional precisam ser aplicadas no momento em que eles podem reiniciar os nós sem precisar ter muita atividade migrando para outro lugar. A migração consome muitos recursos de rede que poderiam ser dedicados ao processamento online.
• Os MMOs baseados em RDBMS têm grandes problemas com bloqueio de dados e integridade referencial. O tempo de inatividade é usado para limpar bloqueios obsoletos e quebras de integridade dos logs de atividades.
• A maioria dos jogos implementa caches de dados geograficamente localizados para informações estáticas ou semi-estáticas (veja dados resumidos de cache abaixo) em áreas de uso intenso, como costa leste e costa oeste dos EUA. Esses caches são atualizados manualmente durante o tempo de inatividade.

No que diz respeito às razões do software:

• Os jogos, quando operam, usam muito tipo de OLTP - que é o processamento de transações on-line - leituras / gravações em bancos de dados. No entanto, às vezes você quer um relatório resumido ... como quantos animais em particular você matou nos últimos 3 anos de moagem. Isso é melhor tratado por um relatório OLAP - que é o Processamento analítico on-line - que contém informações de resumo com base em muitas linhas em um conjunto de dados gigante. Na realidade, os jogos implementam sistemas que usam OLAP para criar um cache para limitar o número de consultas que precisam ser lidas - ou seja, eles criam um total a partir de uma determinada data e, quando você faz a pergunta, eles apenas lêem as linhas do repositório OLTP que resume o período desde a data certa. Mesclar os dois, e você pode realmente quantificar o quão inútil sua vida se tornou.
• O hot-patch mencionado acima, que eu vejo como um problema de software, mas os desenvolvedores de software veem como um problema de sistemas. ;)
• Reabastecendo lojas de itens - em Eve, os cinturões de asteróides são atualizados todas as noites e certos complexos também são reciclados. Isso pode ser feito até certo ponto enquanto on-line, mas alguns dos algoritmos são muito complexos e precisam ser feitos no modo off-line, porque trazem brevemente o banco de dados de joelhos enquanto resumem a atividade econômica do dia anterior.

Administrar uma economia com loops fechados e abertos é um problema para os operadores de MMO - se você não acredita em mim, leia alguns dos artigos acadêmicos que foram escritos sobre economias de jogos e alguns dos estudos de jogos antigos como Ultima Online que tinha economias relativamente primitivas. A análise que precisa acontecer para reabastecer os loops abertos e identificar trapaças e outras atividades econômicas negativas precisa ocorrer offline com uma captura instantânea dos dados, que às vezes só pode ser realizada enquanto o banco de dados estiver totalmente bloqueado.

Se você notar, a manutenção de Eve acontece quando é meio-dia na Inglaterra, onde está o datacenter principal.

Suspeito que o tempo total que a Blizzard (estou deduzindo, considerando que é uma manhã de terça-feira que você está postando sua pergunta) cita a manutenção é para todo o cluster; nem todo servidor leva tanto tempo para executar o trabalho.

Embora possa ser possível recuperar servidores individuais mais rapidamente, isso geraria gritos de favoritismo contra jogadores cujos domínios caíram mais cedo no cronograma. Como tal, eles mantêm tudo em ordem até todo o trabalho; com centenas de domínios para trabalhar, eles provavelmente fazem grande parte do trabalho em paralelo, mas ainda serializam uma verificação final antes de colocar as coisas novamente online. Se você estiver fazendo uma atualização de hardware, isso provavelmente será serializado em tantos data centers quanto eles.

Quanto ao motivo pelo qual eles executam a manutenção, algumas podem ser apenas uma reinicialização do desempenho. Embora seja ótimo se essas reinicializações não forem necessárias, o custo de fazer isso versus o impacto de não fazer isso pode estar direcionando sua escolha aqui.

Quando você examina por que eles não podem agrupar os processos e executar manutenção rotativa, o que pouca gente sabe da infraestrutura do WoW sugere que várias máquinas fornecem serviços para cada região (por exemplo, uma para o mundo, uma para instâncias e invasões e outra para campos de batalha) , etc.) eles não usam uma configuração de processo ativo-ativo compartilhada pelo estado. Não há compartilhamento de estado ativo, apenas dados persistentes por meio de um banco de dados.

No final, a mecânica de fornecer um serviço online estável a uma base tão grande de assinantes desafia algumas das melhores práticas que podemos adotar ao falar sobre um site ou outro serviço tradicional baseado na Internet.

Algumas das paradas mais recentes no EvE Online foram sobre a instalação de novo hardware, como uma SAN mais rápida. Embora seja possível mover tecnicamente a maior parte dos dados criando um novo grupo de arquivos na nova unidade e depois esvaziando a principal, isso resultaria em um período prolongado de desempenho reduzido devido à E / S constante. Então, eles optaram por desanexar o banco de dados de 1,1 TB e movê-lo de uma só vez.

A resposta a esta pergunta também se baseia no aplicativo específico. Por exemplo, um servidor que lida com um sistema em estrela específico não pode ser afetado por hotspots sem interromper o jogo; portanto, o tempo de inatividade é usado para reatribuir servidores mais poderosos a potenciais hotspots. Além disso, os cálculos de propriedade (soberania) dos sistemas estelares são calculados. Isso depende das dezenas de variáveis ​​diferentes, as quais podem mudar dependendo das ações do jogador. Escusado será dizer que fazer isso ao vivo pode causar bloqueio excessivo e / ou outros problemas de simultaneidade. Mas é melhor deixar isso de lado para o stackoverflow .

presumivelmente algo com o qual você não poderia lidar via cluster / balanceamento de carga, como as principais alterações no esquema do banco de dados.

Em um tópico recente Com que frequência devo reiniciar os servidores Linux, outro ponto positivo foi mencionado, verificando se tudo é iniciado corretamente em uma reinicialização ou após qualquer alteração (importante) na configuração.

Uma simples atualização de hardware (ou substituição de hardware) também é apresentada como "manutenção do servidor" pelos jogos do MMORPG. Tão trivial que muitas vezes esquecemos disso.

Eu implementei uma arquitetura MMO em Erlang que suporta atualizações e distribuição de códigos quentes. Por exemplo, um "GamePlay Server" pode ser executado em um número arbitrário de máquinas, se for necessário um upgrade de hardware, seus objetos podem ser transferidos (em tempo real) para outras máquinas. Isso permite atualizações no hardware do software sem nenhum tempo de inatividade.

Você pode conferir o meu site em http://www.next-gen.cc .

Sou levado a acreditar que a janela de manutenção também permite a substituição rotineira de hardware para garantir que os componentes não falhem.