i

Faculdade de Tecnologia de Americana Curso Superior de Tecnologia em Desenvolvimento de Jogos Digitais

DATA SHARING: CLUSTERIZAO 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: CLUSTERIZAO DE DB2 NA PLATAFORMA Z (MAINFRAME)

RODOLFO CUSTODIO
custodior@gmail.com

Trabalho de Concluso de Curso desenvolvido em cumprimento exigncia curricular do Curso Superior de Tecnologia em Desenvolvimento de Jogos Digitais, sob a orientao 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 execuo do trabalho. Estendo meus agradecimentos ao meus amigos de classe que me ajudaram de vrias maneiras e aos colegas de trabalho que me ajudaram na escolha do tema para o trabalho.

DEDICATRIA Dedico esse trabalho aos meu pai e minha me in memory, que sempre estiveram ao meu lado assim como minha irmo. Tambm dedico toda minha famlia.

VI

RESUMO Jogos Massively Multiplayer Online (MMO) atualmente tem uma enorme participao no mercado e muitos usurios ao redor do mundo. Devido a isso, uma quantia de servidores necessrios para suprir essa demanda o e alm disso, precisam ser altamente disponveis, escalveis e confiveis. O texto conceitua o que so 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 implementao de um jogo MMO usando o DB2 datasharing com um servidor de aplicao.

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, theres an example of a MMO game implementation using DB2 DataSharing and an application Web server.

Keywords: DataSharing, High Availability, MMO.

VIII

SUMRIO

1 2 2.1 2.2 2.3 3 4 5

INTRODUO....................................................................................................1 REVISO BIBLIOGRFICA ..............................................................................2 ALTA DISPONIBILIDADE E PROCESSAMENTO PARALELO .............................. 2 DB2 PARA MAINFRAME E CLUSTERIZAO ...................................................... 8 JOGOS MMO............................................................................................................. 18 DB2 DATASHARING PARA JOGOS MMO.....................................................21 CONSIDERAES FINAIS..............................................................................22 REFERNCIAS BIBLIOGRFICAS ................................................................23

IX

LISTA DE FIGURAS E DE TABELAS Figura 1 MTTR, MTTF, MTBF, Bauer et all (2009)...................................................3 Figura 2 Principais Causas de Interrupes, Gartner Group (1999) ........................4 Tabela 1 Tipos de sistemas e suas respectivas disponibilidades.............................5 Tabela 2 Diferente formas de transparncia em um sistema distribudo Tanenbaum; Steen (2006)...........................................................................................5 Figura 3 Simplificao 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 pginas de um buffer pool, IBM (2010)..................................15 Figura 12 Diferena entre DB2 e Oracle RAC, Sironi (2008) .................................16 Figura 13 Capacidade de Utilizao pelo nmero 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 Nvel), IBM (2008) ...........................20 Figura 16 Arquitetura de um jogo MMO com WebSphere e DB2 ShataSharing ....21

1 1 INTRODUO

No cenrio onde a tecnologia est cada vez mais presente na vida das pessoas e conseqentemente sendo utilizada em sistemas de grande necessidade como sade, governo e financeiro, necessrio que esses sistemas sejam confiveis e sempre disponveis, que a grande busca de empresas de grande porte e governamentais. O objetivo geral foi conceituar o que so sistemas disponveis, confiveis e paralelos e ver como o DB2, em mainframe, oferece uma arquitetura que prima por essas qualidades. O trabalho foi estruturado em 3 captulos, sendo que o primeiro conceitua o que so sistemas confiveis e disponveis. Tambm aborda conceitos de arquitetura paralela e o DB2 assim como a arquitetura de um cluster em mainframe. O segundo captulo aborda como feita a implementao do DB2 em DataSharing, ou seja, alm do hardware e software discutido no captulo anterior, outros objetos necessrios para que esse modelo seja ativado. Tambm fala-se sobre o principal concorrente, o ORACLE RAC e um breve comparativo entre ambos. Com base nas informaes conseguidas a partir dos estudos realizados no captulo anterior, o ltimo captulo se reserva s consideraes finais.

2 2 REVISO BIBLIOGRFICA

2.1

ALTA DISPONIBILIDADE E PROCESSAMENTO PARALELO Para Rausand (2004), disponibilidade a habilidade de um item executar sua

determinada funo em um dado instante e perodo de tempo, ou seja, que ele esteja funcionando (operando ativamente ou esperando por servio) em um nvel aceitvel em relao a durao em que permanece no ar, normalmente 99,7% ou mais. A sociedade cada vez mais est dependente destes servios que necessitam de alta disponibilidade como financeiros, seguro, sade, governamentais e assim por diante. Para suprir essa necessidade, tanto empresas privadas e pblicas investem pesado em sistemas de grande porte para que forneam a alta disponibilidade requerida. Segundo uma estimativa da consultoria Gartner, os investimentos com TI no Brasil podem chegar a US$ 143,8 bilhes em 2012, comparado a 2010 isso equivale a um crescimento de 10%. Ainda de acordo com a consultoria, entre as reas que mais recebero investimentos so as de informao e anlise de dados e tambm a rea de computao em nuvem. De acordo com Neaga (1998), operao contnua a caracterstica de um sistema de prover servios aos seus usurios o tempo todo, seja de dia ou de noite, sem interrupes agendadas para manuteno de sistemas ou dados. Neaga tambm enfatiza que sistemas de alta disponibilidade que

compartilham da operao contnua so possuem uma caracterstica conhecida como Disponibilidade Contnua, isto , propriedade de um sistema prover operao contnua e alta disponibilidade ao mesmo tempo. O sistema deve ser desenvolvido de maneia que os usurios no percebam interrupes agendadas ou no. Para todo sistema altamente disponvel, necessrio tambm que o mesmo seja confivel. A ISO8402 descreve confiabilidade como sendo a capacidade de um

3 item para executar uma funo requerida sob condies estabelecidas por um determinado perodo de tempo. Bauer et all (2009) definem alguns parmetros de medio da confiabilidade de um sistema, entre eles, tem-se: tempo de paralisao, MTBF, MTTR e MTTF. A figura abaixo mostra, durante um perodo de tempo, o estado que esse sistema pode estar (ativo ou inativo) e as respectivas mtricas.

Figura 1 MTTR, MTTF, MTBF, Bauer et all (2009)

Tempo de paralisao (ou downtime em ingls): refere-se a paradas no sistema e podem ser divididos em dois tipos: as paralisaes planejadas para mudanas no sistema ou nos dados, ou no planejadas quando h falhas tanto nos dados ou no sistema. O tempo mdio entre falhas (MTBF Mean Time Between Failures em ingls) tempo mdio que um item de configurao ou um servio de TI pode exercer sua tarefa sem interrupo (Traduo Nossa, Sironi, 2008, p.39) O tempo mdio para reparo (MTTR Mean Time To Recovery em ingls) como o tempo mdio que um item de configurao ou um servio de TI ir levar para recuperar de alguma falha (Traduo Nossa, Sironi, 2008, p.39). MTTR considerado o\u tempo de paralisao.

4 Por ltimo, o tempo mdia para falhas (MTTF Mean Time To Failure caracterizado pela mdia de tempo esperado para que um sistema esteja disponvel antes que uma fala ocorra (Traduo Nossa, Bauer et all, 2009, p.223). Embora muitos pensam que problemas de hardware e desastres naturais sejam os maiores causadores de interrupes, eles representam apenas 20% do total de falhas segundo a Gartner Group. A maioria dos erros ocorrem por causas humanas como erros de lgica, manuteno programada e erros de usurios como mostra o grfico abaixo:

Principais Causas de Interrupces

SO e Aplicaes 40%

Hardware e Desastres Naturais 20%

Hardware e Desastres Naturais Erros de Usurio Final

Erros de Usurio Final 40%

SO e Aplicaes

Fonte: Gartner Group

Figura 2 Principais Causas de Interrupes, Gartner Group (1999)

Para Chumash, disponibilidade medida em noves que significam a quantidade de tempo por ano que um servio est ativo . cada nvel na tabela est associado custo, que pode crescer conforme o nvel sobe. A medio em noves citada por Chumash quer dizer que, quanto maior o nmero de nove na porcentagem de disponibilidade, mais disponvel esse sistema, como mostra na tabela abaixo:
Tipo de Sistema No Gerenciado Interrupes / ano Disponibilidade Noves 52,560 min 90,0%1 nove

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 Disponvel 314 seg 99,999%5 noves Muito Altamente Disponvel 31 seg 99,9999%6 noves Ultra Altamente Disponvel 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 frmula: DISPONIBILIDADE = MTBF/(MTBF+MTTR). De maneira prtica, ela pode ser utilizada para descobrir a porcentagem de disponibilidade de um determinado sistema.

Sistemas distribudos ou sistema processamento paralelo um modelo da informtica onde um processo que antes executava em um nico processador, possa ser dividido em vrios outros ou clusterizado. Um sistema distribudo uma coleo de computadores independentes que aparenta para seus usurios como um nico sistema (Tanenbaum; Steen, 2006, p.2). O objetivo da clusterizao no processamento paralelo visa a alta disponibilidade e aumento no desempenho uma vez que os problemas da informtica esto cada vez maiores levando necessidade da diviso do trabalho em diversos clusters. Para Tanenbaum; Steen (2006), a transparncia do sistema tambm deve ser um objetivo do processamento paralelo e podem ser aplicados em vrios aspectos do sistema, conforme mostra a tabela 2.
Transparncia Acesso Localizao Migrao Descrio Esconder diferenas na representao de dados e como os recursos so acessados Esconder onde um recurso est localizado Esconder que um recurso pode mover-se para outra localidade Esconder que um recurso pode ser movido para outra localidade enquanto estiver em Relocao uso Replicao Esconder que um recurso replicado Concorrncia Esconder que um recurso pode ser compartilhado por muitos usurios Falhas Escondar a falha e a recuperao de um recurso Tabela 2 Diferente formas de transparncia em um sistema distribudo Tanenbaum; Steen (2006).

Sistemas paralelos possuem uma caracterstica que a escalabilidade, isto , esto preparados para o crescimento uniforme ou uma demanda especfica que aumente a sua carga de trabalho.

6 Segundo Amdahl (1967) por mais de uma dcada profetas tm manifestado a afirmao de que a organizao de um nico computador atingiu os seus limites e que um avano verdadeiramente significativo pode ser feito apenas pela interligao de vrios computadores de tal forma a permitir uma soluo 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 Simplificao da lei de Amdahl, Sironi (2008)

Porm, embora Amdahl tenha dito que o processamento paralelo possa economizar tempo na resoluo de tarefas, podem existir excees e necessrio avaliar quantos processadores a mais sero necessrios 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 ns, 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 mquinas

7 independentes que se comunicam atravs de uma rede de alta velocidade ... .No h nenhuma maneira para um determinado sistema acessar diretamente a memria ou um disco de um outro sistema. Podemos ilustrar a arquitetura shared-nothing da seguinte maneira:

Figura 4 Arquitetura Shared-Nothing

Uma das caractersticas dessa arquitetura que cada cluster proprietrio 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 usurio. Normalmente, neste tipo de arquitetura, h um overhead tanto de CPU quanto de rede. Existe tambm o risco de ocorrer deadlocks quando h alguma transao executando uma atualizao. Arquitetura shared-nothing pouco utilizada hoje em dia. Ainda encontrada em ambientes de data warehousing e aplicaes de apoio tomada de decises. 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 so compartilhados entre os clusters, a tecnologia shared-data vem crescendo devido a popularidade das SANs Storage Area Network ou uma rede de armazenamento. A tecnologia SAN permite que discos

8 lgicos sejam montados por um ou mais sistemas fazendo com que a configurao de compartilhamento seja mais simples. Embora o investimento para se ter uma arquitetura shared-data seja alta, o custo de administrao baixo perto do retorno em desempenho e disponibilidade.

Figura 5 Arquitetura Shared-Data

Nesta arquitetura pode-se encontrar mltiplos SGBDs que compartilham tanto seu catlogo quanto os dados, portanto, todos os seus membros so proprietrios dos dados. Para obter integridade dos dados um mecanismo de locking global necessrio. Outro ponto importante que, como os dados poder estar na memria de vrios membros, se um dado atualizado, outros membros precisam estar com a mesma informao, ou no mnimo, invalidar o dado que est em sua memria.

2.2

DB2 PARA MAINFRAME E CLUSTERIZAO Antes de descrever como o DB2 implementa as caractersticas de shared-

data, necessrio conhecer a estrutura desse sistema no ambiente mainframe. O DB2 um sistema de gerenciamento de banco de dados da IBM criado e lanado no mercado em 1983. Atualmente existem verses 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 relao dados persistentes, ou seja, dados que so armazenados em disco so: Databases, tablespaces e indexspaces, BSDS e as logs. J com relao aos dados em memria, tem-se o EDM pool e o Buffer Pool No DB2, DATABASE um conjunto lgico de tablespaces e indexspaces. Podem ser classificados em trs tipos: Database de sistema: Somente dois por DB2, so conhecidos como catlogo (internamente chamado de DSNDB06) e o diretrio (DSNDB01). Ambos possuem os metadados do DB2 e so como o inventrio dos objetos e das autorizaes que o sistema possui. Database de usurio: na atual verso (10) podem existir at 65271 databases em um sistema. So nesses databases que os dados de aplicativos so armazenados.

10 Database temporrio: Tambm conhecido como DSNDB07, onde o DB2 faz operaes de sort ou gera os result sets das queries dos usurios. Tablespace o arquivo onde o DB2 armazena o dado fisicamente. uma estrutura do tipo VSAM e os dados so armazenados em pginas de tamanhos mltiplos de 4. O tamanho das pginas 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 so arquivos onde o DB2 armazena os ndices. Tambm so VSAM e pode armazenar um ou mais ndice. Os ndices so uma rvore do tipo B+ e so um conjunto de ponteiros que apontam para as linhas das tabelas.

RID

RID

RID

TableSpace
Figura 7 Exemplo de um ndice do tipo B+

Como todo sistema de gerenciamento de banco de dados, o DB2 mantm uma estrutura de logs para controlar suas atividades nas tabelas. As informaes gravadas so todas as execues de SQL que alteram algum tipo de dado como insero, deleo e atualizao.

11 Para toda transao, o DB2 cria um registro de log inicial para que, caso haja alguma interrupo na execuo da mesma, ele tem um ponto de reparo. Alm do primeiro registro, para cada atualizao desta transao at seu final, um registro de log tambm criado. Esse registro de logs tambm conhecido como RBA (Relative Byte Address) so armazenados em arquivos de log chamados log ativa. Uma vez que o arquivo atinge seu tamanho mximo, ou DB2 faz o offload para um dispositivo secundrio: 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 inicializao, se existe alguma transao que precisa ser recuperada. O BSDS mantm uma lista de at 10000 arquivos de log. Para cada arquivo, ele possui a informao 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 esto os registros de log. O DB2 mantm, enquanto executa, duas estruturas principais na memria do sistema operacional, so eles o EDM Pool e o Buffer Pool. O EDM Pool utilizado pelo DB2 para aumentar seu desempenho na execuo 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 memria onde o DB2 carrega as pginas das tabelas. Assim como nas tablespaces, existem 4 tipos de bufferpool: 4k, 8k, 16k e 32k. Se um usurio 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 usurio. Esses processos rodam em espaos de memria chamados address space como mostra a figura 8. Por ser uma mquina de grande porte, em um mainframe pode-se ter vrios sistemas rodando, esses sistemas rodam em parties lgicas onde o administrador do sistema distribui os recursos entre eles dependendo de sua criticidade como sistemas de teste e produo.

Figura 8 Estrutura dos address space no z/OS, IBM (2010)

A implementao da clusterizao no mainframe dada por uma estrutura chamada SYSPLEX. Nela, so necessrio hardwares adicionais como um sysplex timer e a coupling facility. O sysplex timer um hardware e seu objetivo sincronizar o relgio dos sistemas operacionais. A coupling facility gerencia os recursos que esto em disco e em quais sistemas esto sendo alocados em um determinado momento. Com essa estrutura, alta disponibilidade e operao contnua a nvel de SO so implementadas, porm, para que o DB2 trabalhe em uma estrutura shared-data, necessrio algumas definies adicionais.

13

Figura 9 Estrutura de um SYSPLEX

Utilizando da arquitetura de SYSPLEX visto no captulo anterior, o DB2 tira vantagem dessa facilidade e permite que se tenha vrios membros rodando em sistemas diferentes em um modelo shared-data. Esse modelo nomeado DATA SHARING. Existe alguns fatores que levam as organizaes a utilizarem o datasharing. A primordial alta disponibilidade, o data sharing fornece cinco noves de disponibilidade, ou seja, 99,999% disponvel durante o ano. Outro fator a consolidao da base de dados facilitando o gerenciamento.

14

Figura 10 DB2 data sharing. Mullins (2004)

A imagem acima mostra a implementao bsica 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 instncia em que est rodando). Quando o DB2 roda em datasharing, tanto seu catlogo quanto o diretrio so compartilhado entre os clusters. Porm cada DB2 tem sua implementao de logs e BSDS. No SYSPLEX, o DB2 utiliza diretamente o sysplex timer e a coupling facility. Cada um tem uma funo crtica no funcionamento do data sharing. O sysplex timer sincroniza o horrio entre os subsistemas, isso necessrio devido ao fato de que as logs utilizam o horrio para gerar a sequncia de registro de log ou LRSN (Log record sequence number). J a coupling facility mantm as estruturas de group buffer pool, lock e SCA. Quando utiliza-se datasharing, a coupling facility possui trs estruturas para o seu funcionamento. So elas: group buffer pool, lock e SCA.

15 Embora cada membro de um datasharing possua seu prprio buffer pool, ou seja, rea de memria onde o DB2 carrega as pginas de dados, para manter uma coerncia do cache entre os membros, o group buffer pool utilizado como uma ponte ou um intermedirio no cache entre os clusters.

Figura 11 Fluxo das pginas de um buffer pool, IBM (2010)

A SCA (shared communications area ou rea compartilhada de comunicao) uma lista que contm o nome de todos os membro e seus respectivos BSDS, estado dos databases, por exemplo, um database que seu estado seja somente leitura, essa informao fica armazenada na SCA. Se uma pgina comea a ser atualizada em um dos membros do data sharing, o DB2 necessita de uma maneira de gerenciar para que outro membro no tente atualizar a mesma pgina. Para isso, ele conta com a estrutura chamada LOCK. Cada membro possui um processo que executa em formato de tarefa chamado IRLM que responsvel pelo travamento dos objetos e garantir a integridade e coerncia dos dados. No datasharing isso no diferente, porm, eles comunicam entre si atravs 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 Diferena 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 emulao, ou software em cada membro. A ITG, uma consultoria americana, a pedido da IBM fez uma pesquisa sobre escalabilidade levando em considerao quantidade de membros de um shared-data e sua capacidade real de utilizao. 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 relao ao Oracle conforme o grfico abaixo:

17

Figura 13 Capacidade de Utilizao pelo nmero de clusters. ITG (2003)

18

2.3

JOGOS MMO Jogos MMO (Massive Multiplayer Online) um videogame onde um jogador

se conecta atravs da internet em um mundo virtual persistente, unindo-se a centenas de milhares de jogadores em uma experincia compartilhada CEREJA (2008). Segundo Assiots, Tzanov (2006) os sistemas que englobam uma arquitetura para jogos MMO devem ser escalveis pois a medida que a popularidade de um jogo aumenta, seu nmero de usurios aumentam consideravelmente. Para isso necessrio acomodar o ambiente de acordo com o crescimento da demanda. Outro ponto levantado por eles a tolerncia falhas. Jogadores esperam que o jogo esteja disponvel a maior parte do tempo. Em julho de 2005 houve uma queda no servio da Blizzard para uma manuteno nos servidores do jogo World of Warcraft, de acordo com Miller, o prejuzo ficou prximo aos US$26198 por hora. A arquitetura utilizada em jogos MMO a distribuda ou tambm conhecida como Cliente/Servidor. Para esses jogos, normalmente centenas ou at milhares de servidores trabalham em conjunto para que os usurios tenham a melhor experincia possvel. Na figura 14 vemos um exemplo de uma arquitetura de um jogo MMO onde jogadores (atravs 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 mquina do usurio propriamente dita) Um Game Server para interagir com o cliente Um servidor de aplicao WEB para integrar com o Game Server e o cliente Um DataBase Server para armazenar e recuperar os dados de usurios. A figura abaixo traz um exemplo de uma arquitetura com os componentes acima descritos:

20

Figura 15 Arquitetura de um jogo MMO (Alto Nvel), IBM (2008)

Na figura acima, o exemplo utilizado foi de uma engine de jogo chamada TGEA (Torque Game Engine Advanced). O servidor de aplicao WEB existem vrios 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 so 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 necessrio alta disponibilidade e tambm escalabilidade. No captulo anterior viu-se que alm do servidor do jogo e da mquina do cliente, pode-se usar um servidor de aplicao Web e um sistema de gerenciamento de banco de dados (SGBD). Para otimizar a conexo de um jogo MMO com o DB2 DataSharing pode-se utilizar um WebSphere Application Server junto a um concentrador, ou gerenciador, de conexes. Esse concentrator tem o objetivo de balancear a carga entre as instncias 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 CONSIDERAES FINAIS Jogos MMO so sistemas crticos que devem estar sempre disponveis como tambm ter propriedade de ser tanto confivel, quanto prover alta disponibilidade. Caso ocorra algum tipo de perda do servio, o prejuzo devido quantidade de usurios que o utilizam enorme. Os jogos MMO possuem uma caracterstica de rodar em plataformas com uma arquitetura distribuda, ou um processamento paralelo, ou seja, a tarefa do sistema dividido em vrias mquinas, aumentando a disponibilidade e desempenho. Na plataforma mainframe, o SYSPLEX a arquitetura de processamento distribudo ou paralela onde se tem vrios 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 alm de estar sempre disponvel, oferecer confiabilidade, o DataSharing, em uma plataforma mainframe dispe de objetos que favorecem para que os dados estejam sempre ntegros, esses objetos so conhecidos como LOCK, SCA e GROUP BUFFER POOL. Alm do DB2 DataSharing, existe no mercado um produto concorrente que o ORACLE RAC. Embora a plataforma de ambos seja diferente, a idia de prover um sistema de compartilhamento de dados em um modelo SHARED DATA a mesma. O jogos MMO podem utilizar das caractersticas 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 tambm a utilizao de um servidor de applicao que auxilia no balanceamento de cargas durante o seu trabalho.

23 5 REFERNCIAS BIBLIOGRFICAS 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 pginas. 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 pginas. 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 Cincia, 2005. No prelo Gartner: Investimento em TI no Brasil deve subir 10% ao ano at 2014. Disponvel em: http://oglobo.globo.com/economia/mat/2011/10/25/gartnerinvestimento . Acesso em: 05 de nov. 2011. Gartner Group Making Smart Investments to Reduce Uplanned Downtime. Disponvel 16 de nov. de 2011. em: http://www.maoz.com/~dmm/complexity_and_the_internet/downtime.pdf Acesso em:

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. Disponvel 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. Disponvel megamon.xe_db2.doc%2Fbpobpe1025.htm . Acesso em: 14 de nov. de 2011. ISO8402:1994. er=20115 Acesso em 10 de nov. de 2011. ITG Enterprise Database Cluster Solutions. Business Case for IBM DB2 Parallel Sysplex. Disponvel em: ftp://ps.boulder.ibm.com/software/data/pubs/techconsult/itg0310-2.pdf Acesso em: 18 de nov. de 2011. MILLER, Rich, Extended Outages for World of Warcraft. Disponvel 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 Edio. Estados Unidos. 2004. NEAGA, Gregor; et al. Continuous Availability Systems Design Guide. Estados Unidos. 1998. RAUSAND, Marvin; HOYLAND Arnljor. System Reliability Theory. 2 Edio. New Jersey, Estados Unidos. 2004. Disponvel em: em: http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?topic=%2Fcom.ibm.o

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumb

25 SIRONI, Angelo. Parallel Computing and RDBMS. ROMATRE Universit Degli Studi. Roma, Itlia. 2008. System IPL: Address space creation and subsystem initialization. Disponvel 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 Edio. Amsterd, Holanda. 2007. IBM The role and importance of DB2 group buffer pools in data sharing groups. Disponvel megamon.xe_db2.doc%2Fbpobpe1025.htm . Acesso em: 14 de nov. de 2011. WEBER, Taisy Silva. Um roteiro para explorao dos conceitos bsicos de tolerncia a falhas. Instituto de Informtica UFRGS. What nov. 2011. is a clustered database?. Disponvel em: em: http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?topic=%2Fcom.ibm.o

http://insidehpc.com/2006/07/14/what-is-a-clustered-database/ Acesso em: 07 de