Embed Size (px)
Citation preview
i
Faculdade de Tecnologia de Americana
Curso Superior de Tecnologia em Desenvolvimento de Jogos
Digitais
DATA SHARING: CLUSTERIZAÇÃO DE DB2 NA PLATAFORMA Z (MAINFRAME) PARA JOGOS
MMO
RODOLFO CUSTODIO
Americana, SP 2012
ii
Faculdade de Tecnologia de Americana
Curso Superior de Tecnologia em Desenvolvimento de Jogos
Digitais
DATA SHARING: CLUSTERIZAÇÃO DE DB2 NA PLATAFORMA Z (MAINFRAME)
RODOLFO CUSTODIO
Trabalho de Conclusão de Curso desenvolvido em cumprimento à exigência curricular do Curso Superior de Tecnologia em Desenvolvimento de Jogos Digitais, sob a orientação do Prof. Me. José Alberto F. Rodrigues Filho.
Área: Jogos Digitais
Americana, SP 2012
III
BANCA EXAMINADORA
Prof. Me. José Alberto F. R. Filho (Orientador) Prof. Me. Cleberson Forte Prof. José William Pinto Gomes
IV
AGRADECIMENTOS
Em primeiro lugar, gostaria de agradecer ao Professor Mestre José Alberto F.
R. Filho pela sua ajuda na execução do trabalho. Estendo meus agradecimentos ao
meus amigos de classe que me ajudaram de várias maneiras e aos colegas de
trabalho que me ajudaram na escolha do tema para o trabalho.
V
DEDICATÓRIA
Dedico esse trabalho aos meu pai e minha mãe in memory, que sempre
estiveram ao meu lado assim como minha irmão. Também dedico à toda minha
família.
VI
RESUMO
Jogos Massively Multiplayer Online (MMO) atualmente tem uma enorme
participação no mercado e muitos usuários ao redor do mundo. Devido a isso, uma
quantia de servidores necessários para suprir essa demanda o e além disso,
precisam ser altamente disponíveis, escaláveis e confiáveis. O texto conceitua o que
são esses sistemas e como o DB2 na plataforma mainframe pode usufluir da
arquitetura SYSPLEX para implementar o DataSharing. Por fim, tem-se um exemplo
de implementação de um jogo MMO usando o DB2 datasharing com um servidor de
aplicação.
Palavras Chave: DataSharing, Alta Disponibilidade, MMO.
VII
ABSTRACT
Massively Multiplayer Online (MMO) today has a huge market share and lot ot
players around the world. Due that, an amount of servers are needed to support this
demand and besides these servers needs to be very high availables, scalables and
reliables. The text conceptualizes what are these systems and how DB2 in
mainframe platform can use the SYSPLEX model to implement DataShating. In thi
end, there’s an example of a MMO game implementation using DB2 DataSharing
and an application Web server.
Keywords: DataSharing, High Availability, MMO.
VIII
SUMÁRIO
1 INTRODUÇÃO....................................................................................................1
2 REVISÃO BIBLIOGRÁFICA ..............................................................................2
2.1 ALTA DISPONIBILIDADE E PROCESSAMENTO PARALELO .............................. 2
2.2 DB2 PARA MAINFRAME E CLUSTERIZAÇÃO ...................................................... 8
2.3 JOGOS MMO............................................................................................................. 18
3 DB2 DATASHARING PARA JOGOS MMO.....................................................21
4 CONSIDERAÇÕES FINAIS..............................................................................22
5 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................23
IX
LISTA DE FIGURAS E DE TABELAS
Figura 1 – MTTR, MTTF, MTBF, Bauer et all (2009)...................................................3 Figura 2 – Principais Causas de Interrupções, Gartner Group (1999) ........................4 Tabela 1 – Tipos de sistemas e suas respectivas disponibilidades.............................5 Tabela 2 – Diferente formas de transparência em um sistema distribuído Tanenbaum; Steen (2006)...........................................................................................5 Figura 3 – Simplificação da lei de Amdahl, Sironi (2008) ............................................6 Figura 4 – Arquitetura Shared-Nothing........................................................................7 Figura 5 – Arquitetura Shared-Data ............................................................................8 Figura 6 – Arquitetura do DB2 no zOS........................................................................9 Figura 7 – Exemplo de um índice do tipo B+.............................................................10 Figura 8 – Estrutura dos address space no z/OS, IBM (2010) ..................................12 Figura 9 – Estrutura de um SYSPLEX ......................................................................13 Figura 10 –DB2 data sharing. Mullins (2004) ............................................................14 Figura 11 – Fluxo das páginas de um buffer pool, IBM (2010)..................................15 Figura 12 – Diferença entre DB2 e Oracle RAC, Sironi (2008) .................................16 Figura 13 – Capacidade de Utilização pelo número de clusters. ITG (2003) ............17 Figura 14 – Exemplo de uma arquitetura de um jogo MMO, CEREJA (2008)...........19 Figura 15 – Arquitetura de um jogo MMO (Alto Nível), IBM (2008) ...........................20 Figura 16 – Arquitetura de um jogo MMO com WebSphere e DB2 ShataSharing ....21
1
1 INTRODUÇÃO
No cenário onde a tecnologia está cada vez mais presente na vida das
pessoas e conseqüentemente sendo utilizada em sistemas de grande necessidade
como saúde, governo e financeiro, é necessário que esses sistemas sejam
confiáveis e sempre disponíveis, que é a grande busca de empresas de grande
porte e governamentais.
O objetivo geral foi conceituar o que são sistemas disponíveis, confiáveis e
paralelos e ver como o DB2, em mainframe, oferece uma arquitetura que prima por
essas qualidades.
O trabalho foi estruturado em 3 capítulos, sendo que o primeiro conceitua o
que são sistemas confiáveis e disponíveis. Também aborda conceitos de arquitetura
paralela e o DB2 assim como a arquitetura de um cluster em mainframe.
O segundo capítulo aborda como é feita a implementação do DB2 em
DataSharing, ou seja, além do hardware e software discutido no capítulo anterior,
outros objetos necessários para que esse modelo seja ativado. Também fala-se
sobre o principal concorrente, o ORACLE RAC e um breve comparativo entre
ambos.
Com base nas informações conseguidas a partir dos estudos realizados no
capítulo anterior, o último capítulo se reserva às considerações finais.
2
2 REVISÃO BIBLIOGRÁFICA
2.1 ALTA DISPONIBILIDADE E PROCESSAMENTO PARALELO
Para Rausand (2004), disponibilidade é a habilidade de um item executar sua
determinada função em um dado instante e período de tempo, ou seja, que ele
esteja funcionando (operando ativamente ou esperando por serviço) em um nível
aceitável em relação a duração em que permanece no ar, normalmente 99,7% ou
mais.
A sociedade cada vez mais está dependente destes serviços que necessitam
de alta disponibilidade como financeiros, seguro, saúde, governamentais e assim por
diante. Para suprir essa necessidade, tanto empresas privadas e públicas investem
pesado em sistemas de grande porte para que forneçam a alta disponibilidade
requerida.
Segundo uma estimativa da consultoria Gartner, os investimentos com TI no
Brasil podem chegar a US$ 143,8 bilhões em 2012, comparado a 2010 isso equivale
a um crescimento de 10%. Ainda de acordo com a consultoria, entre as áreas que
mais receberão investimentos são as de informação e análise de dados e também a
área de computação em nuvem.
De acordo com Neaga (1998), operação contínua é a característica de um
sistema de prover serviços aos seus usuários o tempo todo, seja de dia ou de noite,
sem interrupções agendadas para manutenção de sistemas ou dados.
Neaga também enfatiza que sistemas de alta disponibilidade que
compartilham da operação contínua são possuem uma característica conhecida
como Disponibilidade Contínua, isto é, propriedade de um sistema prover operação
contínua e alta disponibilidade ao mesmo tempo. O sistema deve ser desenvolvido
de maneia que os usuários não percebam interrupções agendadas ou não.
Para todo sistema altamente disponível, é necessário também que o mesmo
seja confiável. A ISO8402 descreve confiabilidade como sendo a capacidade de um
3
item para executar uma função requerida sob condições estabelecidas por um
determinado período de tempo.
Bauer et all (2009) definem alguns parâmetros de medição da confiabilidade
de um sistema, entre eles, tem-se: tempo de paralisação, MTBF, MTTR e MTTF. A
figura abaixo mostra, durante um período de tempo, o estado que esse sistema
pode estar (ativo ou inativo) e as respectivas métricas.
Figura 1 – MTTR, MTTF, MTBF, Bauer et all (2009)
Tempo de paralisação (ou “downtime” em inglês): refere-se a paradas no
sistema e podem ser divididos em dois tipos: as paralisações planejadas para
mudanças no sistema ou nos dados, ou não planejadas quando há falhas tanto nos
dados ou no sistema.
O tempo médio entre falhas (MTBF “Mean Time Between Failures” em inglês)
é “tempo médio que um item de configuração ou um serviço de TI pode exercer sua
tarefa sem interrupção” (Tradução Nossa, Sironi, 2008, p.39)
O tempo médio para reparo (MTTR “Mean Time To Recovery” em inglês)
como “o tempo médio que um item de configuração ou um serviço de TI irá levar
para recuperar de alguma falha” (Tradução Nossa, Sironi, 2008, p.39). MTTR é
considerado o\u tempo de paralisação.
4
Por último, o tempo média para falhas (MTTF “Mean Time To Failure” é
caracterizado pela “média de tempo esperado para que um sistema esteja disponível
antes que uma fala ocorra” (Tradução Nossa, Bauer et all, 2009, p.223).
Embora muitos pensam que problemas de hardware e desastres naturais
sejam os maiores causadores de interrupções, eles representam apenas 20% do
total de falhas segundo a Gartner Group.
A maioria dos erros ocorrem por causas humanas como erros de lógica,
manutenção programada e erros de usuários como mostra o gráfico abaixo:
Figura 2 – Principais Causas de Interrupções, Gartner Group (1999)
Para Chumash, “disponibilidade é medida em noves que significam a
quantidade de tempo por ano que um serviço está ativo …. cada nível na tabela está
associado à custo, que pode crescer conforme o nível sobe”. A medição em noves
citada por Chumash quer dizer que, quanto maior o número de nove na
porcentagem de disponibilidade, mais disponível é esse sistema, como mostra na
tabela abaixo:
Tipo de Sistema Interrupções / ano Disponibilidade Noves Não Gerenciado 52,560 min 90,0%1 nove
Principais Causas de Interrupcões
Hardware e Desastres Naturais
20%
Erros de Usuário Final40%
SO e Aplicações40%
Hardware e DesastresNaturais
Erros de Usuário Final
SO e Aplicações
Fonte: Gartner Group
5
Gerenciado 5,256 min 90,9%2 noves Bem Gerenciado 526 min 99,9%3 noves Tolerante a Falhas 52 min 99,99%4 noves Altamente Disponível 314 seg 99,999%5 noves Muito Altamente Disponível 31 seg 99,9999%6 noves Ultra Altamente Disponível 3 seg 99,99999%7 noves
Tabela 1 – Tipos de sistemas e suas respectivas disponibilidades
A tabela de disponibilidade acima é calculada de acordo coma seguinte
fórmula: DISPONIBILIDADE = MTBF/(MTBF+MTTR). De maneira prática, ela pode
ser utilizada para descobrir a porcentagem de disponibilidade de um determinado
sistema.
Sistemas distribuídos ou sistema processamento paralelo é um modelo da
informática onde um processo que antes executava em um único processador,
possa ser dividido em vários outros ou clusterizado. “Um sistema distribuído é uma
coleção de computadores independentes que aparenta para seus usuários como um
único sistema” (Tanenbaum; Steen, 2006, p.2).
O objetivo da clusterização no processamento paralelo visa a alta
disponibilidade e aumento no desempenho uma vez que os problemas da
informática estão cada vez maiores levando à necessidade da divisão do trabalho
em diversos clusters. Para Tanenbaum; Steen (2006), a transparência do sistema
também deve ser um objetivo do processamento paralelo e podem ser aplicados em
vários aspectos do sistema, conforme mostra a tabela 2.
Transparência Descrição Acesso Esconder diferenças na representação de dados e como os recursos são acessados Localização Esconder onde um recurso está localizado Migração Esconder que um recurso pode mover-se para outra localidade
Relocação Esconder que um recurso pode ser movido para outra localidade enquanto estiver em uso
Replicação Esconder que um recurso é replicado Concorrência Esconder que um recurso pode ser compartilhado por muitos usuários Falhas Escondar a falha e a recuperação de um recurso Tabela 2 – Diferente formas de transparência em um sistema distribuído Tanenbaum; Steen (2006).
Sistemas paralelos possuem uma característica que é a escalabilidade, isto é,
estão preparados para o crescimento uniforme ou uma demanda específica que
aumente a sua carga de trabalho.
6
Segundo Amdahl (1967) “por mais de uma década profetas têm manifestado a
afirmação de que a organização de um único computador atingiu os seus limites e
que um avanço verdadeiramente significativo pode ser feito apenas pela interligação
de vários computadores de tal forma a permitir uma solução cooperativa”. De
maneira geral, o que ele quis enfatizar é que o processamento chegou a um limite
que compensa dividir um trabalho paralelamente do que executá-lo serialmente
como mostra a figura 3.
Figura 3 – Simplificação da lei de Amdahl, Sironi (2008)
Porém, embora Amdahl tenha dito que o processamento paralelo possa
economizar tempo na resolução de tarefas, podem existir exceções e é necessário
avaliar quantos processadores a mais serão necessários de acordo com o tamanho
do problema.
Os maiores sistemas de gerenciamento de banco de dados no mercado: DB2,
Oracle, SQL Server oferece algum tipo de paralelismo.
Pode-se dividir o paralelismo dos SGBDs em dois tipos: “Shared Nothing”
onde nada é compartilhado entre os nós, ou “Shared Data” onde os membros
compartilham os mesmos dados.
No artigo de Hamilton, Hellerstein e Stonebraker (2007) eles definem que um
sistema paralelo shared-nothing é composto de um cluster de máquinas
7
independentes que se comunicam através de uma rede de alta velocidade ... .Não
há nenhuma maneira para um determinado sistema acessar diretamente a memória
ou um disco de um outro sistema.
Podemos ilustrar a arquitetura shared-nothing da seguinte maneira:
Figura 4 – Arquitetura Shared-Nothing
Uma das características dessa arquitetura é que cada cluster é proprietário de
exclusivo de seus dados. Quanto ao processamento de queries, o cluster que é
coordenador recebe a query, a distribui pelos outros clusters, agrupa os result sets e
retorna a resposta ao usuário.
Normalmente, neste tipo de arquitetura, há um overhead tanto de CPU quanto
de rede. Existe também o risco de ocorrer deadlocks quando há alguma transação
executando uma atualização. Arquitetura shared-nothing é pouco utilizada hoje em
dia. Ainda é encontrada em ambientes de data warehousing e aplicações de apoio à
tomada de decisões.
Para Hamilton, Hellerstein e Stonebraker (2007), na arquitetura shared-data os
membros, ou cluster, do SGBD compartilham os mesmo dados. Os principais
sistemas que fornecem esse tipo de arquitetura é o Oracle RAC e o DB2 para
Mainframe. Como os discos são compartilhados entre os clusters, a tecnologia
shared-data vem crescendo devido a popularidade das “SAN”s – Storage Area
Network – ou uma rede de armazenamento. A tecnologia SAN permite que discos
8
lógicos sejam montados por um ou mais sistemas fazendo com que a configuração
de compartilhamento seja mais simples.
Embora o investimento para se ter uma arquitetura shared-data seja alta, o
custo de administração é baixo perto do retorno em desempenho e disponibilidade.
Figura 5 – Arquitetura Shared-Data
Nesta arquitetura pode-se encontrar múltiplos SGBDs que compartilham tanto
seu catálogo quanto os dados, portanto, todos os seus membros são proprietários
dos dados.
Para obter integridade dos dados um mecanismo de locking global é
necessário. Outro ponto importante é que, como os dados poder estar na memória
de vários membros, se um dado é atualizado, outros membros precisam estar com a
mesma informação, ou no mínimo, invalidar o dado que está em sua memória.
2.2 DB2 PARA MAINFRAME E CLUSTERIZAÇÃO
Antes de descrever como o DB2 implementa as características de shared-
data, é necessário conhecer a estrutura desse sistema no ambiente mainframe.
O DB2 é um sistema de gerenciamento de banco de dados da IBM criado e
lançado no mercado em 1983. Atualmente existem versões nas mais variadas
plataformas: desde smartphones até o mainframe. No z/Series (ou mainframe) ele
roda sobre o sistema operacional z/OS.
9
A figura abaixo ilustra a arquitetura do DB2 no ambiente mainframe:
Figura 6 – Arquitetura do DB2 no zOS
Os principais objetos do DB2 que deve ser destacado com relação à dados
persistentes, ou seja, dados que são armazenados em disco são: Databases,
tablespaces e indexspaces, BSDS e as logs. Já com relação aos dados em
memória, tem-se o EDM pool e o Buffer Pool
No DB2, DATABASE é um conjunto lógico de tablespaces e indexspaces.
Podem ser classificados em três tipos:
Database de sistema: Somente dois por DB2, são conhecidos como catálogo
(internamente chamado de DSNDB06) e o diretório (DSNDB01). Ambos possuem os
metadados do DB2 e são como o inventário dos objetos e das autorizações que o
sistema possui.
Database de usuário: na atual versão (10) podem existir até 65271 databases
em um sistema. São nesses databases que os dados de aplicativos são
armazenados.
10
Database temporário: Também conhecido como DSNDB07, é onde o DB2 faz
operações de sort ou gera os result sets das queries dos usuários.
Tablespace é o arquivo onde o DB2 armazena o dado fisicamente. É uma
estrutura do tipo VSAM e os dados são armazenados em páginas de tamanhos
múltiplos de 4. O tamanho das páginas de uma tablespace pode ser 4k, 8k, 16k e
32k. As tablespaces podem armazenar uma ou mais tabela dependendo de seu tipo,
que pode ser: Segmentada, particionada, universal, LOB e XML.
Similar às tablespaces, os indexspaces são arquivos onde o DB2 armazena
os índices. Também são VSAM e pode armazenar um ou mais índice.
Os índices são uma árvore do tipo B+ e são um conjunto de ponteiros que
apontam para as linhas das tabelas.
Figura 7 – Exemplo de um índice do tipo B+
Como todo sistema de gerenciamento de banco de dados, o DB2 mantém
uma estrutura de logs para controlar suas atividades nas tabelas. As informações
gravadas são todas as execuções de SQL que alteram algum tipo de dado como
inserção, deleção e atualização.
TableSpace
RID RID RID
11
Para toda transação, o DB2 cria um registro de log inicial para que, caso haja
alguma interrupção na execução da mesma, ele tem um ponto de reparo. Além do
primeiro registro, para cada atualização desta transação até seu final, um registro de
log também é criado.
Esse registro de logs também conhecido como RBA (Relative Byte Address)
são armazenados em arquivos de log chamados log ativa. Uma vez que o arquivo
atinge seu tamanho máximo, ou DB2 faz o offload para um dispositivo secundário:
fitas ou discos de menor velocidade.
O BSDS (BootStrap Data Set) é um arquivo onde o DB2 utiliza como um
índice de suas logs. É no BSDS que ele verifica durante sua inicialização, se existe
alguma transação que precisa ser recuperada.
O BSDS mantém uma lista de até 10000 arquivos de log. Para cada arquivo,
ele possui a informação de inicio e fim de registro de log. Quando uma tabela precisa
ser recuperada em algum ponto no tempo, é no BSDS que o DB2 procura em quais
arquivos estão os registros de log.
O DB2 mantém, enquanto executa, duas estruturas principais na memória do
sistema operacional, são eles o EDM Pool e o Buffer Pool.
O EDM Pool é utilizado pelo DB2 para aumentar seu desempenho na
execução de queries. É nele que ficam os esqueletos dos planos, pacotes e os
descritores do ambiente. Esses descritores informam ao DB2 o estado dos objetos
como database, tablespace, indexspace, tabelas e assim por diante.
O BufferPool é uma área de memória onde o DB2 carrega as páginas das
tabelas. Assim como nas tablespaces, existem 4 tipos de bufferpool: 4k, 8k, 16k e
32k. Se um usuário requisitar um dado de uma tabela de 4k, o resultado será
carregado no bufferpool de 4k.
Em mainframes, o sistema operacional que roda nessa plataforma é o z/OS.
Cada processo que é executado nesse SO pode ser um job, uma tarefa ou um
12
usuário. Esses processos rodam em espaços de memória chamados address space
como mostra a figura 8.
Por ser uma máquina de grande porte, em um mainframe pode-se ter vários
sistemas rodando, esses sistemas rodam em partições lógicas onde o administrador
do sistema distribui os recursos entre eles dependendo de sua criticidade como
sistemas de teste e produção.
Figura 8 – Estrutura dos address space no z/OS, IBM (2010)
A implementação da clusterização no mainframe é dada por uma estrutura
chamada SYSPLEX. Nela, são necessário hardwares adicionais como um sysplex
timer e a coupling facility.
O sysplex timer é um hardware e seu objetivo é sincronizar o relógio dos
sistemas operacionais. A coupling facility gerencia os recursos que estão em disco e
em quais sistemas estão sendo alocados em um determinado momento.
Com essa estrutura, alta disponibilidade e operação contínua a nível de SO
são implementadas, porém, para que o DB2 trabalhe em uma estrutura shared-data,
é necessário algumas definições adicionais.
13
Figura 9 – Estrutura de um SYSPLEX
Utilizando da arquitetura de SYSPLEX visto no capítulo anterior, o DB2 tira
vantagem dessa facilidade e permite que se tenha vários membros rodando em
sistemas diferentes em um modelo shared-data. Esse modelo é nomeado DATA
SHARING.
Existe alguns fatores que levam as organizações a utilizarem o datasharing. A
primordial é alta disponibilidade, o data sharing fornece cinco noves de
disponibilidade, ou seja, 99,999% disponível durante o ano. Outro fator é a
consolidação da base de dados facilitando o gerenciamento.
14
Figura 10 –DB2 data sharing. Mullins (2004)
A imagem acima mostra a implementação básica de um datasharing com dois
membros. No caso um DB2 chamado DB2A e outro DB2B. Todo subsistema
instalado no z/OS possui um SSID (ou subsystem id que identifica a instância em
que está rodando). Quando o DB2 roda em datasharing, tanto seu catálogo quanto o
diretório são compartilhado entre os clusters. Porém cada DB2 tem sua
implementação de logs e BSDS.
No SYSPLEX, o DB2 utiliza diretamente o sysplex timer e a coupling facility.
Cada um tem uma função crítica no funcionamento do data sharing. O sysplex timer
sincroniza o horário entre os subsistemas, isso é necessário devido ao fato de que
as logs utilizam o horário para gerar a sequência de registro de log ou LRSN (Log
record sequence number). Já a coupling facility mantém as estruturas de group
buffer pool, lock e SCA.
Quando utiliza-se datasharing, a coupling facility possui três estruturas para o
seu funcionamento. São elas: group buffer pool, lock e SCA.
15
Embora cada membro de um datasharing possua seu próprio buffer pool, ou
seja, área de memória onde o DB2 carrega as páginas de dados, para manter uma
coerência do cache entre os membros, o group buffer pool é utilizado como uma
ponte ou um intermediário no cache entre os clusters.
Figura 11 – Fluxo das páginas de um buffer pool, IBM (2010)
A SCA (shared communications area ou área compartilhada de comunicação)
é uma lista que contém o nome de todos os membro e seus respectivos BSDS,
estado dos databases, por exemplo, um database que seu estado seja somente
leitura, essa informação fica armazenada na SCA.
Se uma página começa a ser atualizada em um dos membros do data sharing,
o DB2 necessita de uma maneira de gerenciar para que outro membro não tente
atualizar a mesma página. Para isso, ele conta com a estrutura chamada LOCK.
Cada membro possui um processo que executa em formato de tarefa chamado
IRLM que é responsável pelo travamento dos objetos e garantir a integridade e
coerência dos dados. No datasharing isso não é diferente, porém, eles comunicam
entre si através da estrutura de lock da coupling facility.
16
O principal concorrente do DB2 Data Sharing é o Oracle RAC. Embora as
plataformas sejam diferentes, ambos utilizam a mesma metodologia de shared-data,
como mostra a imagem abaixo:
Figura 12 – Diferença entre DB2 e Oracle RAC, Sironi (2008)
A maneira como ambos implementam as travas nos objetos difere um do
outro, o DB2 utiliza hardware e é centralizado na couping facility, já no Oracle RAC é
feito por meio de emulação, ou software em cada membro.
A ITG, uma consultoria americana, a pedido da IBM fez uma pesquisa sobre
escalabilidade levando em consideração quantidade de membros de um shared-data
e sua capacidade real de utilização. Nessa pesquisa, foram questionadas nove
empresas que utilizam Oracle RAC e 15 DB2 Datasharing. O estudo mostrou que o
DB2 possui uma escalabilidade maior com relação ao Oracle conforme o gráfico
abaixo:
17
Figura 13 – Capacidade de Utilização pelo número de clusters. ITG (2003)
18
2.3 JOGOS MMO
Jogos MMO (Massive Multiplayer Online) “é um videogame onde um jogador
se conecta através da internet em um mundo virtual persistente, unindo-se a
centenas de milhares de jogadores em uma experiência compartilhada” CEREJA
(2008).
Segundo Assiots, Tzanov (2006) os sistemas que englobam uma arquitetura
para jogos MMO devem ser escaláveis pois a medida que a popularidade de um
jogo aumenta, seu número de usuários aumentam consideravelmente. Para isso é
necessário acomodar o ambiente de acordo com o crescimento da demanda.
Outro ponto levantado por eles é a tolerância à falhas. Jogadores esperam
que o jogo esteja disponível a maior parte do tempo. Em julho de 2005 houve uma
queda no serviço da Blizzard para uma manutenção nos servidores do jogo World of
Warcraft, de acordo com Miller, o prejuízo ficou próximo aos US$26198 por hora.
A arquitetura utilizada em jogos MMO é a distribuída ou também conhecida
como Cliente/Servidor. Para esses jogos, normalmente centenas ou até milhares de
servidores trabalham em conjunto para que os usuários tenham a melhor
experiência possível.
Na figura 14 vemos um exemplo de uma arquitetura de um jogo MMO onde
jogadores (através de um celular) se conectam com o servidor e esse servidor
acessa um database server.
19
Figura 14 – Exemplo de uma arquitetura de um jogo MMO, CEREJA (2008)
Em um nivel mais alto de arquitetura, um jogo MMO necessita dos seguintes
principais componentes:
• Um cliente para renderizar o jogo (a máquina do usuário propriamente dita)
• Um Game Server para interagir com o cliente
• Um servidor de aplicação WEB para integrar com o Game Server e o cliente
• Um DataBase Server para armazenar e recuperar os dados de usuários.
A figura abaixo traz um exemplo de uma arquitetura com os componentes
acima descritos:
20
Figura 15 – Arquitetura de um jogo MMO (Alto Nível), IBM (2008)
Na figura acima, o exemplo utilizado foi de uma engine de jogo chamada
TGEA (Torque Game Engine Advanced). O servidor de aplicação WEB existem
vários no mercado que podemos destacar: IBM WebSphere, BEA WebLogic, ou
Apache Tomcat. Já os sistemas gerenciadores de banco de dados por ser qualquer
um no mercado, os mais utilizados em jogos MMO são IBM DB2, Oracle e MySQL.
21
3 DB2 DATASHARING PARA JOGOS MMO
O DB2 Datasharing pode servir de um dataserver para jogos de MMO onde é
necessário alta disponibilidade e também escalabilidade. No capítulo anterior viu-se
que além do servidor do jogo e da máquina do cliente, pode-se usar um servidor de
aplicação Web e um sistema de gerenciamento de banco de dados (SGBD).
Para otimizar a conexão de um jogo MMO com o DB2 DataSharing pode-se
utilizar um WebSphere Application Server junto a um concentrador, ou gerenciador,
de conexões. Esse concentrator tem o objetivo de balancear a carga entre as
instâncias de um datasharing group.
A imagem abaixo ilustra um exemplo de arquitetura para jogos MMO utilizando
o DB2 DataSharing em z/OS e o WebSphere Application Server:
Figura 16 – Arquitetura de um jogo MMO com WebSphere e DB2 ShataSharing
22
4 CONSIDERAÇÕES FINAIS
Jogos MMO são sistemas críticos que devem estar sempre disponíveis como
também ter propriedade de ser tanto confiável, quanto prover alta disponibilidade.
Caso ocorra algum tipo de perda do serviço, o prejuízo devido à quantidade de
usuários que o utilizam é enorme.
Os jogos MMO possuem uma característica de rodar em plataformas com
uma arquitetura distribuída, ou um processamento paralelo, ou seja, a tarefa do
sistema dividido em várias máquinas, aumentando a disponibilidade e desempenho.
Na plataforma mainframe, o SYSPLEX é a arquitetura de processamento
distribuído ou paralela onde se tem vários sistemas que compartilham os mesmos
dado em formato de SHARED DATA. O DB2 para mainframe com suas estruturas
como database, tablespaces e assim por diante, implementa o que é chamado de
DataSharing.
Para além de estar sempre disponível, oferecer confiabilidade, o DataSharing,
em uma plataforma mainframe dispõe de objetos que favorecem para que os dados
estejam sempre íntegros, esses objetos são conhecidos como LOCK, SCA e
GROUP BUFFER POOL.
Além do DB2 DataSharing, existe no mercado um produto concorrente que é o
ORACLE RAC. Embora a plataforma de ambos seja diferente, a idéia de prover um
sistema de compartilhamento de dados em um modelo SHARED DATA é a mesma.
O jogos MMO podem utilizar das características do DB2 na plataforma z para
prover alta disponibilidade e escalabilidade. Um exemplo de arquitetura para um jogo
MMO que queira utilizar o DB2 em modo datasharing é também a utilização de um
servidor de applicação que auxilia no balanceamento de cargas durante o seu
trabalho.
23
5 REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, Maria S. How to Setup Application Server to Access DB2 for z/OS
with High Availability. In: DB2 z/OS 2009 Technical Conference. Estados Unidos. 32
páginas.
ASSIOTIS, Marios; TZANOV, Velin. A Distributed Architecture for MMORPG.
Massachusetts Institute of Technology, Estados Unidos, 2006.
BAUER, Eric; ZHANG, Xuemei; KIMBER, Douglas A. Practical System
Reliability. Estados Unidos, 2009.
CALTAGIRONIE, Sergio; SCHLIEF, Bryan; KEYS, Matthew; WILLSHIRE, Mary
J. Architecture for a Massively Multiplayer Online Role Playing Game Engine.
University of Portland, Estados Unidos, 2002.
CATTERAL, Robert. Ultra-Availability: How Far Can You Go?. In: IDUG , 2008,
Europa. 42 páginas.
CEREJA, Joni B. ARQUITETURA SERVIDORA DE JOGOS DE CELULAR
ONLINE MASSIVAMENTE MULTIPLAYER, Universidade Regional de Blumenal,
Blumenal, SC, Brasil, 2008.
CHUMASH, Tzvi. Obtaining Five “Nines” of Availability for Internet Services.
Rutgers Escola de Arte e Ciência, 2005. No prelo
Gartner: Investimento em TI no Brasil deve subir 10% ao ano até 2014.
Disponível em: http://oglobo.globo.com/economia/mat/2011/10/25/gartner-
investimento . Acesso em: 05 de nov. 2011.
Gartner Group Making Smart Investments to Reduce Uplanned Downtime.
Disponível em:
http://www.maoz.com/~dmm/complexity_and_the_internet/downtime.pdf Acesso em:
16 de nov. de 2011.
24
HELLERSTEIN, Joseph M. STONEBRAKER Michael, HAMILTON James.
Architecture of a Database System. Massachusetts, Estados Unidos. 2007.
IBM Building a simple yet powerful MMO game architecture. Disponível em:
http://www.ibm.com/developerworks/library/ar-powerup1/#resources Acesso em: 10
de jan. de 2012.
IBM The role and importance of DB2 group buffer pools in data sharing groups.
Disponível em:
http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?topic=%2Fcom.ibm.o
megamon.xe_db2.doc%2Fbpobpe1025.htm . Acesso em: 14 de nov. de 2011.
ISO8402:1994. Disponível em:
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumb
er=20115 Acesso em 10 de nov. de 2011.
ITG Enterprise Database Cluster Solutions. Business Case for IBM DB2
Parallel Sysplex. Disponível em: ftp://ps.boulder.ibm.com/software/data/pubs/tech-
consult/itg0310-2.pdf Acesso em: 18 de nov. de 2011.
MILLER, Rich, Extended Outages for World of Warcraft. Disponível em:
http://news.netcraft.com/archives/2005/07/26/extended_outages_for_world_of_warcr
aft_2.html Acesso em: 22 de dez. de 2011
MULLINS, Craig S. DB2 Developer's Guide. 5ª Edição. Estados Unidos. 2004.
NEAGA, Gregor; et al. Continuous Availability Systems Design Guide. Estados
Unidos. 1998.
RAUSAND, Marvin; HOYLAND Arnljor. System Reliability Theory. 2ª Edição.
New Jersey, Estados Unidos. 2004.
25
SIRONI, Angelo. Parallel Computing and RDBMS. ROMATRE Universitá Degli
Studi. Roma, Itália. 2008.
System IPL: Address space creation and subsystem initialization. Disponível
em http://publib.boulder.ibm.com/infocenter/zos/basics/topic/com.ibm.zos.zsysprog/z
sysprogc_sysaddrspaces.htm . Acesso em: 10 de nov. de 2011.
TANENBAUM, Andrew S.; STEEN, Maarten Van. Distributed Systems:
Principles and Paradigms. 2ª Edição. Amsterdã, Holanda. 2007.
IBM The role and importance of DB2 group buffer pools in data sharing groups.
Disponível em:
http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?topic=%2Fcom.ibm.o
megamon.xe_db2.doc%2Fbpobpe1025.htm . Acesso em: 14 de nov. de 2011.
WEBER, Taisy Silva. Um roteiro para exploração dos conceitos básicos de
tolerância a falhas. Instituto de Informática – UFRGS.
What is a clustered database?. Disponível em:
http://insidehpc.com/2006/07/14/what-is-a-clustered-database/ Acesso em: 07 de
nov. 2011.
