Scalability for Virtual Worlds

Transcrição

1 Sistemas Distribuíds e Tlerância a Falhas Jsé Castanheira Óscar Pint m3852 m4360 Scalability fr Virtual Wrlds

2 Intrduçã Ambientes virtuais em rede (AVR) sã cnsiderads a próxima nda de entreteniment digital. Exempl ppular sã s Massively Multiplayer Online Games (MMOs). Arquitecturas actuais MMO sã centradas n servidr em que tda a lógica d jg é executad ns servidres da empresa que hspeda jg. Leva a graves prblemas de escalabilidade MMOs exigem gráfics e sistemas de física mais realístic pssível.

3 Intrduçã Exempls Secnd Life Micrsft ESP Wrld f Warcraft Hab Htel Outras áreas de aplicaçã sã ensin e simulações militares para fins de frmaçã e táctica.

4 Intrduçã Cm a chegada da banda larga, a internet cm baixa latência é agra mnipresente. Mas ist nã é suficiente para reslver questões de escalabilidade que s AVR cmeçam a ter. Estes prblemas de escalabilidade surgem em parte devid à necessidade de manter a cnsistência entre tds s jgadres. N melhr ds cass, a incerência pde ser só passageira sem cnsequências a lng praz. N entant, na prática, pde facilmente causar prblemas muit mais graves, cm bjects perdids u duplicads durante uma peraçã financeira.

5 Intrduçã A escalabilidade de uma aplicaçã está frtemente relacinada cm a pegada cmputacinal de um únic utilizadr.

6 NETWORKED VIRTUAL ENVIRONMENTS (NVE) A cnsistência é imprtante. Para ser realista, tds precisam partilhar de uma visã única d ambiente virtual, estad d mund. Nrmalmente armazenam estad d mund numa base de dads (BD). Qualquer interacçã cm mund pde ser pensada cm uma transacçã Fazer uma bservaçã é uma cnsulta à BD sbre estad d mund. Uma mudança de estad é uma actualizaçã da BD.

7 NETWORKED VIRTUAL ENVIRONMENTS (NVE) Devid a prblemas cm as BD cmerciais, ptaram pr utilizar BD cmerciais apenas para cnfirmar e ler em checkpints periódics. Para interacções em temp real, geralmente implementa-se uma camada própria de transacçã antes da BD. Esta decisã nã surgiu prque as transacções de BD sã inadequadas para a tarefa! Mas sim, prque as BD nã sã ptimizadas para tip de prcessament que as NVE necessitam para um bm desempenh em temp real.

8 NVE - Arquitecturas - Centralizadas Empresas nrmalmente usam uma arquitectura cm múltipls servidres centrais para alcançar a escalabilidade. As técnicas mais utilizadas para atingir escalabilidade além de um únic servidr sã as seguintes: Zning Técnica de Particinament Gegráfic. Cerca de 12 Servidres e alguns milhares de utilizadres. Sharding Idêntic à anterir mas precupa-se cm fact ds utilizadres pderem estar espalhads pr td mund, levand a delays enrmes. Instancing A cntráris das anterires, limita -se apenas a pequenas partições d ambiente virtual. Limita severamente ai nteraçã d jgadr.

9 NVE - Arquitecturas - Distribuídas Uma alternativa a váris servidres centrais, é mdel distribuíd. Cmputaçã distribuída pels utilizadres = escalabilidade. Existe mdel P2P mas acarreta mais falhas e ineficiências, nã havend escalnament. Existe apenas uma sincrnizaçã virtual que garante a cnsistência na rdem ds events em tds s utilizadres. Em geral, mdel distribuíd cliente-servidr traz um equilíbri entre a preservaçã ds interesses das empresas em exercer cntrle, a escalabilidade d sistema e atenuar ds prblemas de nenhum cntrl centralizad em relaçã a uma arquitectura P2P. Extensões para uma arquitectura híbrida que prcura um equilíbri entre P2P e cliente-servidr sã caminh para futur.

10 NVE Cliente-Servidr Cnsiste num cluster de servidres n qual tds s utilizadres se cnectam. Principal cmpnente é seu prtcl de cnsistência. Uma vez que a cmputaçã é feita pels utilizadres, um prtcl deve ser estabelecid entre s clientes e servidr, garantind assim a cnsistência e durabilidade de dads. Existem 3 classes de prtcls.

11 NVE Cliente-Servidr Prtcls Lck Based Prtcls: A fim de prcessar uma transacçã, cliente deve adquirir blqueis glbais sbre s bjects lids e gravads pela peraçã. Cliente cntacta servidr para um blquei. Se btém tds s blqueis necessáris, cliente executa a transacçã n seu estad lcal e transmite s efeits da peraçã para servidr. O servidr transmite este efeit a tds s utrs clientes que actualizam s seus estads lcais, prsseguind lg de seguida para a próxima transacçã. Este prtcl tem um grave prblema, temp que demra a prcessar a próxima transacçã é dbr d temp de ida e vlta entre cliente e servidr

12 NVE Cliente-Servidr Prtcls Timestamp Based Prtcls: Neste prtcl cntrl é efectuad através de timestamps. Asscia-se uma versã a cada bject e um timestamp a cada transacçã. Os utilizadres executam as suas acções lcalmente, pr vezes cm versões bsletas ds bjects. O servidr recebe as diversas histórias ds diferentes clientes e cria uma multiversã glbal da história.

13 NVE Cliente-Servidr Prtcls Object Ownership: Difere ds prtcls lckbased, pis cada bject é detid e gerid pr exactamente um utilizadr, cnhecid cm dn d bject. As utrs utilizadres é permitid armazenar em cache uma versã d bject, mas nã estã autrizads a fazer mdificações n seu estad. Embra este prtcl seja altamente escalável, nã permite qualquer tip de cntençã d bject n ambiente. Se dis clientes querem alterar estad d mesm bject, apenas cliente que pssuir bject lhe é permitid fazê-l. O servidr é respnsável pr garantir a equidade em quem deve ter a prpriedade ds bjects.

14 Prtcls Baseads em Acçã A Prpsta Prtcls anterires baseavam-se ns bjects. Estes prtcls verificam a cnsistência a nível da acçã. Ex: Funções para actualizar estad d jg. Verificam a cnsistência a nível da acçã. Sã altamente escaláveis.

15 Prtcls Baseads em Acçã - Algritms Básics Mensagens passadas entre s clientes e servidr sã cnstituída principalmente pr acções, a invés de bjects. O estad d mund virtual é uma base de dads de bjects, estad d mund. Cada prgrama cliente mantém duas versões d estad d mund: uma visã ptimista (VO) e uma versã estável (VE). Para executar uma acçã a, um cliente aplica a na VO, enviand também a para servidr afim de ser serializada.

16 Prtcls Baseads em Acçã - Algritms Básics Paralelamente, cliente recebe d servidr um flux serializad das acções riginadas pr tds s clientes, e aplica-as na VE. Os resultads da aplicaçã de acções riginadas lcalmente n VO e VE sã cmparads e as discrdâncias sã cnciliadas, se necessári. A única funçã d servidr é fazer timestamp e serializar as acções ds clientes. Este timestamp virtual, juntamente cm as psições de acções na fila n servidr, estabelece uma sincrnia virtual entre servidr e s clientes.

17 Prtcls Baseads em Acçã - Vantagens Garante uma respsta em cada cmunicaçã (ida e vlta), permitind qualquer tip de interacçã em simultâne. Uma segunda vantagem é que servidr central nã executa qualquer acçã e, prtant, está livre da lógica d jg. O servidr apenas acções faz timestamp as acções, clcand-as em filas de entrega para s clientes e gerind tráfeg de rede. Permite a servidr lidar cm um númer muit grande de clientes.

18 Prtcls Baseads em Acçã - Desvantagens Cada cliente vê e executa tdas as acções para td mund. Resulta numa carga cmputacinal elevada ns clientes. Requisits de largura de banda cnsiderável tant n cliente cm servidr. Escalabilidade muit limitada, temp de respsta cmunicaçã é uma viagem de ida e vlta. Para cnseguir uma melhr escalabilidade há que explrar a semântica da aplicaçã.

19 Utilizand a Semântica da Aplicaçã O servidr restringe cnjunt de mensagens de actualizaçã enviadas para um cliente através de uma restriçã sintáctica. Ex: A visibilidade de um avatar n mund virtual. O servidr restringe cnjunt de mensagens de actualizaçã enviadas para um cliente através de uma restriçã sintáctica. Parece ser bm, mas só se aplica em acções que se saiba à partida mviment que cliente irá efectuar, gera prblemas em acções arbitrárias. Ex: Arquitectura Ring implica que designer crie uma camada de bstruçã que representa bject que blqueia a visibilidade d cliente.

20 Utilizand a Semântica da Aplicaçã - Prblema O us de restrições sintácticas, tais cm a visibilidade restrita, têm um prblema mais prfund: Nã se cnsegue manter a cnsistência. Nã é pssível abranger a transitividade das acções, as persnagens pdem interagir facilmente umas cm as utras, mesm sem se verem. A área real que pde influenciar um avatar é muit mair d que a regiã visível. Para um cliente determinar efeit de uma acçã a, precisa de ter bastante infrmaçã sbre mund virtual, para assim determinar tdas as acções cm ptencial de influenciar a. Esta dependência causal das acções depende da sua semântica e frequentemente nã pdem ser capturadas pr restrições sintácticas.

21 Mdel Incmplet d Mund Reslve prblema de cnsistência d mdel anterir. O cliente envia para servidr uma mensagem de cnclusã, sempre que é prduzid um resultad estável de uma acçã. O servidr utiliza essas mensagens para cnstruir um estad estável d mund. O servidr executa uma análise de leitura e escrita para determinar independentemente para cada cliente A vantagem deste mdel é que um cliente nã tem (necessariamente) de avaliar cada acçã, apenas aquelas que afectam. Pupa-se assim temp de execuçã n cliente, bem cm largura de banda na rede.

22 Mdel Incmplet d Mund Pde ser tlerante a falhas d cliente, cm um cust razável de largura de banda. Fazend cm que cada cliente envie mensagens de cnclusã para cada acçã realizada, e nã apenas as suas próprias acções. Cm esta mudança, únic cas em que servidr nã recebe uma respsta a alguma acçã é quand tds s clientes avaliam que acçã falhu. Em tais cass, é aceitável supr que a acçã nunca fi submetida. O cliente também pde ser ptimizad em terms de memória. O servidr pde infrmar cliente peridicamente da última acçã realizada, permitind a cliente eliminar as acções mais antigas e que já nã interessam.

23 First Bund Mdel Cm Mdel Incmplet, cada cliente avalia apenas um subcnjunt precis de acções, as acções que realmente pdem afectar. Surgind assim The First Bund Mdel para prever um limite d númer de acções que cada cliente pde avaliar. Dá assim um limite n númer de acções gerais que pdem afectar directamente td cnjunt de acções de um cliente. Sã exactamente essas acções que devem ser enviadas para cliente.

24 Infrmatin Bund Mdel O númer de acções nã autrizadas que pdem directa u indirectamente causar um cnflit é ilimitad. Este mdel decide se existe u nã uma acçã que deve ser abandnada. Cm tds s clientes nã enviam as acções exactamente a mesm temp, a rdem aleatória de chegada das acções n servidr vai garantir a equidade, u seja, a prbabilidade de uma acçã recebida ser abandnada é a mesma para tds s clientes. Algritm é cmputacinalmente barat e, prtant, mdel pde ser utilizad em ambientes de temp real.

25 First Bund Mdel & Infrmatin Bund Mdel Os dis mdel junts, geram dis limites. O primeir limite é númer máxim de acções que precisam de ser enviadas a um cliente devid a cnflits directs. Representad cm uma funçã d temp e distância n hiperespaç de atributs. O segund limite é númer máxim de acções que pdem fazer parte das acções de fech (final) Representad cm uma funçã da distância. Cmbinand estes dis limites, tems númer limite de acções enviadas para um cliente a cada instante, representada cm uma funçã de temp e distância.

26 Testes

27 Testes

28 Testes

29 Testes

30 FIM