Redes de Distribuicao de Conteudos (RDCs)

Felipe Uderman1 uderman@ic.uff.br Universidade Federal Fluminense

1

1. Introducao
O aumento crescente da popularidade dos servicos oferecidos atrav s da Internet tende e a impulsionar de forma signicativa a demanda por conte dos, por parte dos usu rios. u a Novos desaos est o associados a este aumento na demanda por conte dos, j que a u a servicos atualmente populares na Internet frequentemente experimentam problemas de congestionamento e consequente indisponibilidade. Estes momentos de indisponibili` dade s o geralmente associados a problemas do tipo ash crowds [Arlitt and Jin 1999], a que consistem em um aumento repentino e signicativo da demanda de um determinado conte do. Estes eventos devem ser evitados para aumentar a Qualidade de Servico experu imentada pelos cada vez mais exigentes clientes destes conte dos. u Uma Rede de Distribuicao de Conte dos (RDC) pode ser denida como u uma rede sobreposta de servidores colaborativos, que s o utilizados para posia cionar r plicas de conte dos a serem acessados de forma transparente pelos clientes e u [Rajkumar Buyya 2008]. Devido ao crescimento do n mero de requisicoes por conte dos u u na Internet, as redes de distribuicao de conte dos est o cada vez mais sendo utilizadas u a pelos provedores de servicos. Esta armacao e especialmente verdadeira para conte dos u multimdia, que normalmente possuem requisitos de qualidade de servico mais restritos. Uma RDC e capaz de posicionar os servidores de conte do mais pr ximos aos u o ` clientes, replicar conte dos para estes servidores e atender as requisicoes dos clientes, u indicando qual servidor deve ser utilizado. Estas funcionalidades produzem efeitos positivos no desempenho do servico tanto sob o ponto de vista do usu rio, que ir experi a a mentar um menor atraso de rede, maior banda de transmiss o disponvel e maior disponia bilidade do conte do, quanto sob o ponto de vista dos provedores de RDCs, que pou dem otimizar o atendimento das requisicoes, reduzindo seus custos operacionais e conse quentemente aumentando a sua lucratividade. O objetivo deste trabalho e prover informacoes gerais sobre as tecnologias e de ` saos associados as RDCs. Por se tratar de um tema muito amplo, somente alguns dos ` muitos t picos relevantes as RDCs s o tratados. O restante deste trabalho est organio a a zado da seguinte maneira: a Secao 2 aborda o tema de uma maneira generalizada, eluci ` dando os principais conceitos referentes as RDCs. Exemplos de implementacoes comer ciais e acad micas de RDCs s o descritos. A Secao 3 trata de um importante problema, e a abordando mecanismos de replicacao de conte dos em RDCs. Al m de conceitos so u e bre mecanismos de replicacao tradicionais, e apresentado o mecanismo SCAN (Scalable Content Access Network), que resolve este problema a partir de uma formulacao din mica a e e um sistema de localizacao de recursos distribudo. A Secao 4 aborda conceito rela cionados com a entrega de conte dos em ambientes Web, destacando as peculiaridades u ` relativas as arquiteturas de RDCs otimizadas para este ambiente. Por m, a Secao 5 cont m coment rios nais sobre o tema e perspectivas para trabalhos futuros. e a

2. Vis o geral sobre as RDCs a

` Primeiramente, alguns conceitos relacionados as RDCs devem ser denidos, para melhorar a compreens o do restante do texto: a Entrega de conteudos: A acao de servir conte dos aos clientes, a partir de suas u requisicoes. Conteudo: Dados ou recursos digitalizados, divididos em duas partes principais: mdia codicada e metadados. Mdia codicada: Dados est ticos, din micos ou contnuos, como audio, vdeo, a a imagens, documentos e p ginas Web. a Metadados: Descricao do conte do, que permite a sua identicacao, u interpretacao e gerenciamento. Provedor de Conteudos: Entidade que delega a um provedor de RDC a tarefa de entregar os seus conte dos para os clientes. u Provedor de RDC: Organizacao ou empresa que prov a infraestrutura necess ria e a para entregar conte dos a clientes de maneira satisfat ria. u o Usu rios nais: S o os usu rios da RDC que acessam os conte dos disponibia a a u lizados na RDC. Servidores substitutos: Tamb m chamados de caches ou servidores de borda, e s o distribudos em diferentes localizacoes geogr cas desntro da abrang ncia da a a e RDC e preenchidos com conte dos que s o entregues aos clientes, a partir de suas u a requisicoes. O objetivo principal das RDCs e entregar os conte dos aos clientes, atendendo u ` as restricoes de qualidade de servico impostas. Para cumprir este objetivo, as RDCs ir o posicionar servidores de conte dos pr ximos aos clientes e implementar mecanismos a u o diversos de gerenciamento e operacao. A gura 2.1 exemplica um modelo b sico de a uma RDC, onde cada servidor substituto realiza a entrega de conte dos para clientes u geogracamente relacionados:

Figura 2.1. Modelo basico de uma RDC [Rajkumar Buyya 2008].

Um provedor de RDC deve oferecer servicos tanto aos clientes da RDC, que bus cam conte dos diversos, quanto aos contratantes do provedor de RDC, representados peu los provedores de conte do. Os principais servicos oferecidos por um provedor de RDCs u s s os seguintes: a Servico de redirecionamento de requisicoes e entrega de conte dos, para realizar u o atendimento da maneira menos custosa possvel para o provedor de RDC. Servicos de distribuicao, para replicar conte dos entre seus servidores originais e u os demais servidores da RDC. Servico de negociacao do atendimento, para atender aos requisitos de Qualidade de Servico heterog neos. e Servico de gerenciamento, para gerenciar os componentes da RDC, lidar com a contabilidade do servico e gerar relat rios sobre o uso da rede e popularidade dos o conte dos. u 2.1. Componentes de uma RDC A gura 2.2 mostra componentes gerais de uma RDC. Diferentes t cnicas e algoritmos e podem ser utilizados para implementar estes servicos. E imprescindvel que estes servicos sejam implementados de forma eciente, para garantir a viabilidade t cnica e econ mica e o das RDCs:

Figura 2.2. Componentes de uma RDC [Rajkumar Buyya 2008].

Componente de entrega de conte dos, que consiste de um servidor original e uma u s rie de servidores substitutos que entregam c pias dos conte dos aos clientes. e o u Componente de redirecionamento de requisicoes, respons vel por redirecionar as a requisicoes dos clientes aos servidores substitutos apropriados. Componente de distribuicao, que replica os conte dos do servidor original para os u servidores substitutos, garantindo a consist ncia dos conte dos na rede. e u

 Componente de contabilidade, respons vel por manter registro das atividades dos a clientes e estatsticas de uso da RDC. Estas informacoes podem ser utilizadas para cobranca dos servicos prestados. Diversos tipos de conte dos podem ser disponibilizados pelas RDCs, tais como u conte dos est ticos (p ginas HTML, imagens, documentos), transmiss o de mdia ( udio u a a a a e vdeo em tempo real) e conte dos diversos (transfer ncia de arquivos, servicos de di u e ret rio), ilustrados na gura 2.3. Como diferentes conte dos possuem requisitos de qualo u idade distintos, e natural que as RDCs apliquem precos diferenciados para a entrega dos conte dos, baseados principalmente nos seguintes fatores: u

Figura 2.3. Exemplos [Rajkumar Buyya 2008].

de

conteudos

disponibilizados

em

RDCs

Taxa de transmiss o experimentadas pelos clientes. Quanto maior a taxa utilizada, a maior o valor cobrado. Variacao da distribuicao de tr fego ao longo do tempo. Em perodos de maior a congestionamento na rede, a entrega de conte dos ser mais cara. u a Tamanho dos conte dos replicados entre os servidores originais e substitutos na u rede. N mero de servidores substitutos, que representam a habilidade da RDC em manu ter a qualidade do servico oferecido em situacoes adversas. Conabilidade, estabilidade e seguranca da RDC. 2.2. Evolucao das RDCs A evolucao das RDCs se deu a partir de outros tipos de tecnologias que, apesar de n o a possurem os mesmos objetivos das RDCs, possuem caractersticas desej veis para au a mentar o desempelho de servicos de entrega de conte dos. Algumas destas t cnicas s o: u e a Melhoria de hardware nos servidores de conteudo: Apesar destas melhorias aumentarem a capacidade dos servidores em prover conte dos para os clientes, u elas n o s o exveis e escal veis o suciente, j que pequenas melhorias nem a a a a sempre s o possveis, e eventualmente todo o sistema dos servidores teria que ser a substitudo para acomodar o crescente n mero de requisicoes. u

 Posicionamento de servidores do tipo Proxy Caching pelos Provedores de Servico de Internet em locais pr ximos aos clientes: Esta t cnica melhora o o e desempenho da entrega de conte dos para clientes com banda de acesso limiu tada, al m de reduzir o tr fego total na Internet. Os Proxy Caching ir o guardar e a a uma c pia dos conte dos previamente solicitados, para que novas requisicoes para o u estes mesmos conte dos possam ser atendidas diretamente pelo Proxy Caching, u sem necessidade de acionar o servidor original do conte do. u Posicionamento de diferentes nveis hier rquicos de servidores Cache locais, a regionais e internacionais: Esta t cnica, conhecida como Hierarchical Caching, e e capaz de prover um aumento adicional no desempenho da entrega de conte dos, u assim como na economia de banda. Al m disto, a utilizacao de Server Farms, que e consiste em m ltiplos servidores que compartilham a responsabilidade de entregar u o conte do requisitado, tem se mostrado uma solucao mais escal vel, al m de u a e prover uma redund ncia natural ao sistema. a Ainda que estas t cnicas produzam bons resultados, elas s o insucientes para e a garantir a qualidade do servico de entrega de conte dos em situacoes adversas, j que u a atuam sem uma infraestrutura dedicada, din mica e colaborativa para a entrega dos a conte dos. A primeiras geracoes de RDCs foram criadas para proteger a entrega de docu umentos Web de eventos do tipo Flash Crowd. J a geracao atual mudou o foco para a entrega de vdeo sob demanda e transmiss o de audio e vdeo. E possvel antecipar que a a terceira geracao de RDCs ser voltada para a disseminacao de conte dos gerados por a u pessoas comuns, a chamada Community-based CDNs. A gura 2.4 ilustra este cen rio. a

Figura 2.4. Evolucao das RDCs [Rajkumar Buyya 2008].

As RDCs modernas evoluram a partir de outros tipos de sistemas distribudos para compartilhamento de recursos ou acesso a conte dos digitais. Estes sistemas possuem u caractersticas e mecanismos de operacao relevantes para a composicao das arquiteturas de RDC modernas. Data Grids s o ambientes de computacao intensiva que prov em a e servicos de processamento de grandes conjuntos de dados para usu rios em diferentes a localizacoes geogr cas. Existem duas funcionalidades dos Data Grids que s o especial a a mente relevantes no contexto das RDCs: transfer ncia con vel de dados e mecanismos e a

de busca e replicacao de objetos. Al m disto, a seguranca e a integridade dos dados s o e a fatores relevantes para os Data Grids. Apesar disto, as RDCs se diferem dos Data Grids principalmente pelo fato do objetivo principal dos Data Grids ser fazer com que uma grande massa de dados seja transferida para um stio de alta concentracao de poder com putacional para serem processados, enquanto que o objetivo principal das RDCs e fazer com que clientes geogracamente espalhados possam ter acesso a dados que originalmente se encontram em ambientes com alta capacidade de armazenamento. Outros sistemas relacionados s o os Bancos de Dados Distribudos (BDD) , que a consistem em uma colecao de dados logicamente organizados em n s com diferentes o localizacoes geogr cas. Neste tipo de sistema, cada n pode agir como cliente, servi a o dor ou ambos, a depender da situacao. Os BDDs surgiram para suprir a necessidade de grandes corporacoes que desejavam substituir bancos de dados centralizados por um sis tema distribudo capaz de integrar os bancos de dados existentes a novos bancos de dados, que surgem a partir de novas unidades corporativas. A principal diferenca entre os BDDs e as RDCs e o fato de que os diversos stios que comp em os BDDs possuem um grau de o independ ncia de operacao e gerenciamento elevados, enquanto que nas RDCs os servie dores que comp em o sistema t m sua operacao regida por um sistema integrado. Al m o e e disto, as RDCs possuem o objetivo de entregar conte dos aos seus clientes, enquanto que u os BDDs fazem parte de sistemas de consulta e processamento de dados. Por m, as redes Peer-to-Peer (P2P), projetadas para o compartilhamento direto dos recursos computacionais dos clientes, sem o interm dio de uma entidade intere medi ria com uma infraestrutura dedicada, tamb m possuem caractersticas compatveis a e com as RDCs modernas. Em redes P2P, cada cliente, ou peer, possui total autonomia para se juntar ou deixar a rede, e adicionar ou remover conte dos em seu espaco de aru mazenamento. As redes P2P s o mais indicadas para o compartilhamento de conte dos a u est ticos, j que caractersticas da sua arquitetura n o conseguem acomodar de forma a a a eciente conte dos din micos. Estes sistemas possuem um alto grau de escalabilidade, u a e idealmente n o possuem um ponto unico de falha. Entretanto, em contraste com as a RDCs, as redes P2P t m seu desempenho altamente afetados pela n mero de clientes pare u ticipantes na rede. Al m disto, o principal objetivo das redes P2P e prover um mecanismo e eciente para busca e transfer ncia de arquivos em meio aos clientes participantes, ene ` quanto que as RDCs possuem o principal objetivo de atender as requisicoes dos clientes observando os seus requisitos de desempenho. 2.3. Desaos das RDCs O principal objetivo das RDCs e atender provedores de conte dos ou clientes que deseu jam ter seus requisitos de desempenho atendidos, em um ambiente seguro e con vel. a Portanto, algumas regras de neg cio devem nortear o desenvolvimento das arquiteturas o de RDCs: Escalabilidade: A RDC precisa lidar com grandes volumes de dados e requisicoes por conte dos, sem que os usu rios e clientes experimentem uma u a queda de desempenho. E muito importante que uma RDC seja capaz de se adequar dinamicamente a variacoes abruptas na demanda por determinados conte dos, alo u cando espaco de armazenamento quando houver necessidade, e consequentemente reduzindo os custos operacionais da RDC.

 Seguranca: Prover solucoes de seguranca para conte dos condenciais e de alto u valor e um grande desao para as RDCs. Sem um forte esquema de seguranca, as RDCs est o sujeitas a fraudes, ataques de negacao de servico distribudo( Disa tributed Denial-of-Service - DDOS), vrus e outros incidentes indesej veis. Desta a forma, uma arquitetura de RDC, em um cen rio ideal, deve incorporar diversos a nveis de seguranca( fsica, de rede, de dados e de procedimentos), para que solucoes de seguranca de terceiros, que geralmente possuem um custo elevado, n o precisem ser contratadas. a ` Conabilidade, correspond ncia e desempenho: Conabilidade se refere a uma e alta disponibilidade esperada para determinado servico. Uma maneira de se prover conabilidade a uma RDC e alocar diversos servidores, em diferentes regi es geo ogr cas diferentes, para reduzir ao m ximo as chances do cliente n o ser atena a a ` dido devido a indisponibilidade da RDC. Correspond ncia est relacionado com e a o tempo necess rio para que a RDC consiga restabelecer o seu padr o original de a a qualidade no funcionamento, em caso de possveis indisponibilidades do servico ou reducao da qualidade no atendimento. Por m, o desempenho de uma RDC est altamente relacionado com a localizacao do conte do distribudo, mecanisa u mos de roteamento empregados e com as estrat gias de replicacao de dados e e caching empregados. 2.4. Arquiteturas Existentes Para RDCs Atualmente, diversas arquiteturas de RDC est o em operacao, tanto no ambito comera cial quanto no acad mico. Dentre as RDCs comerciais, algumas merecem destaque por e estarem em operacao est vel a alguns anos: Akamai, EdgeStream, Limelight Networks e a Mirror Image. 2.4.1. RDCs Comerciais A Akamai [aka 2010] foi fundada em 1998 em Massachusetts, a partir de um esforco do MIT para resolver o problema de ash crowd. Atualmente, a Akamai e considerada a empresa lder no mercado de RDCs. A abordagem da Akamai e baseada na premissa de quer prover conte dos a partir de uma unica fonte centralizada representa um grande u ` problema de escalabilidade. Desta forma, seu sistema e projetado para para atender as requisicoes por conte dos a partir de diversos servidores substitutos na borda da rede. A u Akamai distribui conte dos est ticos (p ginas HTML, arquivos e documentos), conte dos u a a u din micos (animacoes, scripts e DHTML), assim como transmiss es de audio e vdeo. a o A Akamai implementa um mecanismo de alocacao din mica de servidores para a amenizar ocorr ncias de ash crowds. Atrav s de um balanceamento de carga via DNS, a e e Akamai mapeia as requisicoes aos servidores baseado no servico requisitado, localizacao do usu rio e condicoes da rede. Al m disto, agentes que simulam o comportamento dos a e usu rio nais s o utilizados para realizar medicoes de qualidade que tamb m alimentam a a e o sistema de balanceamento de carga, protegendo servidores que se encontram conges tionados. Outras t cnica utilizada e a fragmentacao de conte dos, que s o tratados como e u a objetos independentes. A EdgeStream [edg 2010] foi fundada em 2000 na Calif rnia como um provedor o

de transmiss es de vdeo pela Internet. Prov servicos de vdeo sob demanda e transo e miss es IPTV para possibilitar o transporte de vdeos de alta qualidade pela Internet. Para o atingir m tricas de lat ncia de rede, perda de pacotes e evitar caminhos congestionados, a e e EdgeStream desenvolveu t cnicas de Continuous Route Optimization Software (CROS), e Internet Congestion Tunnel Through (ICTT) e Real Time Performance Monitoring Service (RPMS). A Limelight [lim 2010] Networks foi fundada em 2001 no Arizona. Seu foco e a distribuicao de conte dos via plataforma Web, incluindo vdeos, mu sica, jogos e aplica u u tivos. Al m disto, tamb m prov servicos de transmiss o de audio e vdeo. Empresas e e e a carregam seus conte dos nos servidores da Limelight, que s o distribudos sob demanda, u a para seus diversos clusters de servidores espalhados pelo mundo. Tamb m utiliza DNS e para redirecionar as requisicoes dos clientes para servidores locais. Este sistema de redi recionamento e alimentado por mapas detalhados da topologia da Internet, construdos atrav s de medicoes pr prias e informacoes do protocolo BGP. e o A Mirror Image [mir 2010] foi fundada em 1999 em Massachusetts como um provedor de conte do online, transmiss es de audio e vdeo e computacao via Web. A u o sua arquitetura e baseada na alocacao de grandes clusters de servidores Web, localizados em regi es geogr cas densamente povoadas. A Mirror Image utiliza uma infraestrutura o a ` sobreposta a Internet denominada Content Access Point (CAP), para prover conte dos u aos seus usu rios. Atrav s de um balanceamento de carga via DNS, as requisicoes s o a e a enviadas para a localizacao CAP com o tempo de resposta mais r pido. Caso o conte do a u requisitado esteja presente na localizacao CAP escolhida, o atendimento e realizado. Caso contr rio, o atendimento e realizado a partir do servidor de origem do conte do, e uma a u c pia e realizada para a localizacao CAP para futuras requisicoes. o 2.4.2. RDCs Acad micas e Em oposicao as RDCs comerciais, o uso de tecnologias P2P e muito comum nas RDCs ` acad micas. Desta forma, as requisicoes s o atendidas de forma distribuda por todos os e a participantes da rede. Estas RDCs baseadas em tecnologias P2P s o ecientes apenas a para conte dos est ticos, sendo incapazes de lidar com conte dos que podem ser dinamiu a u camente modicados. Alguns exemplos de RDCs acad micas s o: CoDeeN, Coral e e a Globule. CoDeeN [Wang et al. 2004] e um sistema de servidores proxy baseado em P2P, implementada sob a rede PlanetLab que possibilita aos seus usu rios um dempenho mela hor ao acessar a maioria das p ginas Web da Internet. O princpio de funcionamento a do CoDeeN consiste em congurar os navegadores Web dos usu rios participantes para a utilizarem um dos caches do CoDeeN como proxy. Para cada requisicao dos clientes, o servidor proxy selecionado ir tentar entregar o conte do solicitado. Caso ocorra a a u falta deste conte do no cache, os algoritmos de redirecionamento implementados pelo u CoDeeN ir o para qual cache esta requisicao deve ser enviada. Os algoritmos de redirea cionamento levam em consideracao a localizacao da requisicao, a carga e conabilidade do sistema e informacoes de proximidade. Caso a requisicao n o possa ser atendida por a nenhum dos servidores cache do CoDeeN, a requisicao e redirecionada para o servidor de origem.

 Coral [Freedman et al. 2004] e uma RDC gratuita, baseada em tecnologia P2P e ` implementada sob a rede PlanetLab. Seu objetivo e prover a maioria dos seus usu rios a um desempenho melhor ao acessar p ginas Web participantes. Coral utiliza a banda de a transmiss o de volunt rios para evitar eventos do tipo ash crowd e reduzir a carga nos a a servidores originais dos Web sites participantes. As requisicoes dos clientes s o redi a recionadas para servidores caches do Coral pr ximos de forma transparente, atrav s de o e redirecionamento via DNS. Sempre que possvel, dados s o transmitidos entre servidores a cache adjacentes, para reduzir tanto a carga no servidor Web original quanto a lat ncia de e rede experimentada pelos clientes. Globule [Pierre and Steen 2006] e uma RDC colaborativa com implementacao em c digo aberto. Seu objetivo e permitir que provedores de conte do Web possam se orgao u nizar e operar sua pr pria plataforma de armazenamento de escala global. Os usu rios o a participantes constituem n s das rede Globule e oferecem recursos de armazenamento, o banda de transmiss o e poder de processamento. Globule prov mecanismos de replicacao a e de conte dos, monitoramento de servidores e redirecionamento de requisicoes para as u r plicas pr ximas disponveis. e o

3. T cnicas de replicacao de Conteudos e

Devido aos grandes avancos nas areas de desempenho de processadores, capacidade de armazenamento e disponibilidade de recursos de rede, e cada vez mais frequente a implantacao de sistemas computacionais distribudos, compostos de milhares de elemen tos auto-organiz veis posicionados em diferentes localizacoes geogr cas. Apesar disto, a a estes tipos de sistemas est o frequentemente sujeitos a falhas em seus componentes e a indisponibilidades na rede, ou at mesmo uma reducao tempor ria do desempenho, que e a podem isolar as diversas partes destes sistemas distribudos. Desta forma, no contexto das RDCs, o uso eciente de recursos locais, atrav s de uma poltica eciente de posicionae mento de r plicas de conte dos e extremamente importante, tanto para o desempenho e u quanto para a disponibilidade do sistema. Uma abordagem comum para uma poltica de replicacao de conte dos eciente u e particionar o sistema em duas camadas de r plicas: uma primeira camada (primarye tier) que deve ser pequena e dur vel e uma segunda camada (second-tier) que deve ser a grande, por m vol til. O primary-tier pode ser representado por um servidor Web que e a cont m a c pia mais atualizada do conte do, e pode ser abstrado como a localizacao de e o u origem, ou fonte do conte do. J o second-tier pode ser representado por uma RDC, com u a seu conjunto de servidores armazenando r plicas do conte do com origem no primarye u tier. Requisitos de qualidade de servico (Quality of Service - QoS) podem ser utilizados para determinar o n mero e posicao das r plicas de conte dos na RDC, ou second-tier da u e u rede. Como o posicionamento de uma r plica em um servidor da RDC consome recursos, e e desej vel que os requisitos de QoS sejam satisfeitos com o mnimo de r plicas possveis a e distribudas na RDC. Desta forma, a depender da popularidade dos conte dos, requisitos u de QoS das requisicoes e outros fatores, o n mero de r plicas de cada conte do na RDC u e u pode variar signicativamente. 3.1. Localizacao de Conteudos Um importante problema relacionado com a replicacao de objetos em RDCs e o da determinacao da localizacao dos conte dos entre os diversos servidores ou caches que u

comp em a RDC. Diversos trabalhos abordaram ente problema, em diferentes contextos. o Estas abordagens podem ser classicadas em tr s grandes grupos: Servicos de Diret rio e o Centralizados (SDC), Servicos de Diret rios Replicados (SDR) e Servicos de Diret rios o o Distribudos (SDD). A abordagem SDC consiste em um unico servidor de diret rios que prov o e informacoes sobre a localizacao de cada objeto presente na rede. Por ser constituda de apenas um servidor, esta abordagem e bastante vulner vel a ataques de negacao de a servico (Denial of Service - DoS). A abordagem SDR, ilustrada na gura 3.1 pode ser considerada uma variante da abordagem SDC, e consiste na exist ncia de diversos servie dores de diret rios, nos quais a base de dados que mapeia a localizacao dos conte dos e o u replicada. Esta abordagem prov uma maior disponibilidade, por m acrescenta um overe e ` head adicional no sistema, relativo a replicacao e manutencao de consist ncia da base de e dados.

Figura 3.1. Sistema de Diretorios Replicados: O diretorio centralizado pode ser replicado para pontos remotos da rede [Rajkumar Buyya 2008].

Em contraste com as demais abordagens, SDDs s o implementados a partir de a uma infra-estrutura descentralizada, normalmente baseadas em P2P, para localizar objetos de maneira r pida e com sucesso garantido. Nesta abordagem, os pedidos de localizacao a de objetos s o passados para os diversos servidores de diret rios da rede, at que algum a o e ` destes servidores possua a informacao requisitada. Devido a sua caracterstica distribuda, esta abordagem prov uma alta disponibilidade, mesmo sob ataque. e 3.2. Disseminacao de atualizacoes Um outro problema est relacionado com a disseminacao de mensagens de atualizacoes a de conte dos na RDC. Uma abordagem tradicional utiliza IP Multicasting para realizar u esta tarefa. Entretanto, IP Multicasting possui caractersticas incompatveis com a sua utilizacao em uma arquitetura de distribuicao de conte dos na Internet. Essencial u mente, IP Multicasting funciona somente atrav s do espaco, e n o atrav s do tempo e a e [Francis 2001]. Isto signica que, apesar dos n s de um grupo multicast serem orgao nizados de maneira hier rquica para facilitar a disseminacao de informacoes, n o existe a a nenhuma garantia de que todos os n s estar o prontos para receber atualizacoes no moo a mento em que esta seja disseminada via IP Multicasting, o que geraria a necessidade de novas mensagens IP Multicasting, at que todos os n s recebessem as atualizacoes. e o Como alternativa ao IP Multicasting, diversos sistemas multicast em nvel de aplicacao (Application Level Multicast - ALM) foram propostos, sendo alguns focados em aplicacoes de pequena escala e m ltiplas fontes, como vdeo-confer ncias, e outros u e

 focados em aplicacoes de grande escala e uma unica fonte, como transmiss o multicast a de mdia. Entretanto, estes sistemas geralmente s o suscetveis a problemas de escalabil a idade, j que um unico n central deve manter informacoes sobre o estado de todos os a o outros n s da rede. o

3.3. Estrat gias Para Replicacao de Conteudos e O principal desao da replicacao de conte dos nas RDCs e prover um atendimento com u bons nveis de QoS para os clientes, enquanto os recursos da RDC s o consumidos de a maneira eciente e balanceada. A banda disponvel em rede e o espaco de armazenamento disponveis nos servidores s o os principais recursos da RDC que precisam ser preserva a dos, e normalmente os esquemas de replicacao aplicam uma relacao de compromisso ` entre estes dois par metros. J os requisitos de QoS, tipicamente, dizem respeito a banda a a de rede mnima e atraso de comunicacao m ximos aceitos pela requisicao. Os principais a modelos de arquitetura para replicacao de conte dos em second-tier s o os seguintes: u a Web Caching, un-cooperative pull-based CDN e cooperative push-based CDN.

3.3.1. Web Caching Existem dois tipos de arquitetura de servidores Cache Web: iniciada pelo cliente e iniciada pelo servidor. Na arquitetura iniciada pelo cliente, c pias de conte dos s o aro u a mazenadas nas m quinas dos clientes ou em caches locais. Ambas estas abordagens posa ` suem limitacoes devido a falta de cooperacao entre os n s de armazenamento, j que o o a armazenamento de conte do na m quina de um cliente em nada ajuda o desempenho em u a um cliente vizinho. De maneira similar, o armazenamento de conte do em um determiu nado cache local em nada ajuda um outro cache local vizinho. As arquiteturas de Cache iniciadas pelos servidores constituem uma possvel ` solucao para os problemas inerentes as arquiteturas de cache iniciadas pelos clientes, j que e permitido ao servidor de origem determinar em quais caches o seu conte do a u deve ser replicado. De forma geral, as RDCs podem ser consideradas arquiteturas de Cache iniciadas pelos servidores, com servidores de borda dedicados. Arquiteturas pushcaching replicam automaticamente dados entre os servidores cache participantes, baseados na topologia da rede e nos padr es de acesso dos usu rios. Mais recentemente, eso a quemas de Web caching adaptativos foram propostos para permitir o compartilhamento de servidores cache entre diferentes servidores proxies. Ainda que esta abordagem represente uma melhoria signicativa quando comparado com arquiteturas de Caches iniciadas pelo cliente, existe uma grande limitacao no que diz respeito a sua escalabilidade. Esta limitacao ocorre pela necessidade de cada cache participante ter que, periodicamente, in formar todos os demais caches participantes sobre quais conte dos ent o sendo armazenau a dos. Al m disto, sem uma infraestrutura de RDC dedicada, estas solucoes n o podem se e a adaptar a momentos de congestionamentos ou falhas na rede ou prover esquemas de balanceamento de carga distribudos de forma eciente.

3.3.2. Un-Cooperative Pull-Based CDN Uma outra solucao em replicacao de conte dos, que e bastante utilizada pelos prove u dores comerciais de RDC, e chamada de un-cooperative pull-based CDN. Basicamente, os conte do s o copiados para os servidores de borda da RDC, a partir de uma requisicao u a por parte dos clientes. Apesar de existirem diversas t cnicas disponveis para direcionar e as requisicoes dos clientes para os conte dos solicitados, o redirecionamento baseado u em DNS e o mais utilizado, devido ao alto nvel de transpar ncia disponibilizado ao e usu rio. Desta forma, cada requisicao DNS por conte dos e direcionada para um servia u dor de nomes local da RDC, que ir redirecionar a requisicao para um dos servidores de a conte do da RDC. A gura 3.2 ilustra este mecanismo de replicacao: u

Figura 3.2. Un-Cooperative Pull-Based CDN: Servidor de nomes local informa ao cliente qual servidor de conteudos deve ser acessado [Rajkumar Buyya 2008].

Entretanto, o servidor de nomes local da RDC que atende um grupo de clientes nem sempre e capaz de armazenar registros de quais conte dos est o presentes em todos u a os servidores de conte do, o que faz com que a escolha do servidor de conte dos seja u u baseada somente na proximidade de rede, disponibilidade de banda e carga do servidor. Desta forma, existe a possibilidade do servidor de conte dos escolhido n o possuir uma u a r plica do conte do requisitado. Neste caso, o servidor de conte do ir requisitar uma e u u a c pia do conte do do servidor original ( ou de algum outro servidor que possua uma c pia o u o ` ` deste conte do), antes de atender a requisicao. Devido as caractersticas n o cooperativas u a desta abordagem, para manter nveis de qualidade de servico aceit veis, geralmente exis a tem mais r plicas na rede de cada conte do do que realmente seria necess rio, caso uma e u a abordagem cooperativa fosse utilizada. 3.3.3. Cooperative Push-Based CDN Recentemente, diversos trabalhos propuseram mecanismos pr -ativos de replicacao de o conte dos que posicionam replicas dos conte dos nos servidores da RDC baseado em u u padr es de acesso dos clientes e na topologia global da rede. A principal vantagem desta o

t cnica, denominada cooperative push-based CDN, n o reside do fato da replicacao ocore a rer de forma pr -ativa ao inv s de mecanismos reativos, mas sim no compartilhamento coo e laborativo das r plicas nos servidores. Este compartilhamento colaborativo das r plicas, e e gerenciado por uma entidade centralizada, permite a reducao do n mero de r plicas de u e conte dos existentes na RDC, que consequentemente reduz o custo de replicacao. Este u mecanismo de replicacao e ilustrado na gura 3.3.

Figura 3.3. Cooperative Push-Based CDN: Servidor de nomes deve manter reg istros sobre as replicas distribudas na RDC [Rajkumar Buyya 2008]

Para cada replicacao realizada, e necess rio informar ao servidor de nomes local a este fato, para que os registros que mapeiam qual conte do est localizado sejam atuu a alizados. A depender das caractersticas da RDC, manter tal registro em cada servidor de nomes local pode ser uma tarefa muito custosa. Entretanto, para reduzir a complexidade desta tarefa, pode-se agrupar diversos conte dos em apenas um registro ou limitar o u n mero de servidores que cada servidor de nomes local e capaz de gerenciar. u

3.3.4. SCAN: Scalable Content Access Network SCAN e um sistema de replicacao de conte dos auto-organiz vel e soft-state, como pode u a ser observado na gura 3.4. SCAN utiliza o Tapestry como seu SDD, que prov um e ambiente de ger ncia de conte dos colaborativo e descentralizado. Atrav s do Tepestry, e u e SCAN posiciona r plicas dinamicamente entre os servidores de borda e as auto organiza e em uma arvore multicast em nvel de aplicacao para disseminar as atualizacoes. SCAN ` calcula as decis es referentes as replicacoes de conte dos de maneira din mica, o que o u a permite a adaptacao da rede perante eventos adversos. Tapestry e um servico de localizacao de P2P descentralizado que exp e o informacoes de localidade de objetos em mensagens de roteamento. Devido a sua abor dagem descentralizada, Tapestry foi utilizado como um sistema base para o desenvolvimento de SCAN. Seus principais componentes s o: a

 Figura 3.4. Sistema de Diretorios Replicados: O diretorio centralizado pode ser replicado para pontos remotos da rede [Rajkumar Buyya 2008].

Tapestry Routing Mesh: Ger ncia o descobrimento de rotas dentro da rede e ` Tapestry. Cada novo n , ao se juntar a rede, deve se conectar a um novo n o o existente, formando um link de vizinhanca. O n existente prov ao novo n rotas o e o para todos os n s da rede, atrav s da computacao de algoritmos baseados em DHT o e ( Distributed Hash Table). Tapestry Distributed Location Service: Implementa o servico de localizacao do Tapestry. Um GUID (Globally Unique ID ou Identicador Unico Global) e as sociado a cada objeto, e para cada GUID e associado um unico servidor raiz. Os servidores de armazenamanto anunciam seus conte dos em direcao ao serviu dor raiz, e depositam mensagens de localizacao, que apontam para a localizacao do objeto, em cada n intermedi rio. Os clientes, quando necessitam conhecer o a a localizacao de algum conte do, enviam requisicoes para seus vizinhos, at en u e contrar um registro correspondente. A dist ncia m dia percorrida ao se localizar a e ` objetos e proporcional a dist ncia do objeto. a O problema de replicacao din mica de conte dos pode ser modelada como um a u problema de otimizacao. Pode-se, por exemplo, modelar um problema que visa minimizar ` o tr fego total na RDC durante o atendimento as requisicoes dos clientes, enquanto as a restricoes de QoS e limitacoes de desempenho da infraestrutura da RDC s o respeitadas. a Outra abordagem seria minimizar o tempo de reposta total, experimentado por todos os clientes da RDC. SCAN tenta minimizar o n mero total de r plicas de cada conte do u e u posicionadas na RDC, enquanto mant m ader ncia aos requisitos de QoS impostos. e e A formulacao matem tica adotada para nortear o desenvolvimento de SCAN a foi a seguinte: Dada uma rede G com C clientes e S servidores, cada cliente ci com sua restricao de lat ncia di e cada servidor sj com um conjunto de restricoes de e carga/banda/armazenamento lj . O problema consiste em encontrar um valor mnimo para K, tal que um conjunto S S, com |S | = K e c C, sc S tal que distancia(c, sc ) dc . Os clientes C e os servidores S devem se auto-organizar em uma arvore ALM tendo C como suas folhas e si S , o n mero de clientes conectados u satisfacam a relacao f (si ) li .

` O posicionamento din mico das r plicas tenta satisfazer as restricoes de lat ncia a e e ` dos clientes e as restricoes de carga dos servidores. O objetivo e satisfazer estas restricoes minimizando o n mero de r plicas posicionadas, mantendo as arvores ALM balanceadas u e e gerando o mnimo de tr fego de atualizacoes possveis. SCAN implementa algorit a mos heursticos para solucionar este problema. Quando comparado com mecanismos implementados em arquiteturas tradicionais de RDCs, SCAN posiciona cerca de 6-8% do n mero de r plicas na rede. u e

4. Gerenciamento e Entrega de Conteudos em Ambientes Web

A Internet e os sistemas Web, nos ultimos anos, evoluram de um meio de distribuir conte dos est ticos de interesse marginal para a principal plataforma de comunicacao u a mundial, onde conte dos e servicos crticos s o entregues aos seus usu rios. Esta u a a evolucao foi acompanhada por uma preocupacao dos provedores de conte dos com u relacao o desempenho da entrega dos conte dos percebida pelos usu rios, que por muitas u a vezes contrataram servicos dos provedores de RDC, para manter este desempenho em nveis aceit veis. a As primeiras geracoes de RDCs para entrega de conte dos Web se concentravam u na distribuicao de conte dos est ticos e possuam o objetivo de amenizar eventos de con u a gestionamento em p ginas Web com alta demanda. Entretanto, o cen rio Web atual sofreu a a ` modicacoes marcantes no que diz respeito a sosticacao e complexidade dos servicos oferecidos, evidenciadas principalmente pela presenca macica de conte dos gerados di u namicamente e personaliz veis. Desta forma, as arquiteturas de RDC sofreram diversas a modicacoes e aprimoramentos ao longo dos anos para serem capazes de lidar de forma eciente com esta nova realidade dos ambientes Web, que possuem servicos mais com plexos, usu rios mais exigentes e uma grande quantidade de conte dos gerados dinamia u camente e personaliz veis por seus usu rios. a a 4.1. Camadas L gicas dos Sistemas Web o De forma geral, pode-se dizer que os sistemas Web s o baseados numa arquitetura a l gia multi-camada que separa em diferentes componentes a interface HTTP, a l gica o o da aplicacao, um reposit rio ou banco de dados e um banco de informacoes relacionadas o com os usu rios que acessam o sistema. Estes diferentes componentes ou camadas podem a ser referenciadas, respectivamente, como front-end, application, back-end e user prole. A gura 4.1 ilustra estes componentes: Front-end layer: Esta camada funciona como uma interface entre os usu rios a do sistema e a camada application. A partir das requisicoes HTTP dos clientes, conte dos est ticos s o buscados em um sistema de arquivos e entregue aos u a a clientes de maneira simplicada. Alguns exemplos de conte dos est ticos que u a podem ser manipulados pelo front-end s o os seguintes: objetos embutidos em a p ginas Web como imagens, style sheets e animacoes em ash e conte dos mula u timdia como audio e vdeo, que geralmente s o entregues via HTTP Streaming. a Application layer: Esta pode ser considerada a principal camada dos sistemas Web, j que e respons vel por toda a l gica de processamento do servico ima a o plementado no sistema Web. Uma funcionalidade interessante desta camada e realizar o processamento necess rio para geracao de conte dos din micos ou pera u a sonaliz veis, a partir das informacoes fornecidas pelos usu rio via o front-end a a

 Figura 4.1. Camadas logicas de um sistema Web [Rajkumar Buyya 2008]

layer e dados armazenados no back-end layer e no user prole layer. Alguns exemplos de conte dos din micos que podem ser gerados por esta camada s o os u a a seguintes: respostas obtidas a partir de fontes de informacoes como carrinhos de compras e formul rios de busca e conte dos gerados a partir do comportamento a u social dos usu rios, como p ginas de f runs ou blogs. a a o Back-end layer: Esta camada gerencia o principal reposit rio de informacoes do o sistema Web e, tipicamente, e constitudo de um servidor de banco de dados e armazenamento. Os conte dos armazenados neste sistema podem ser utilizados u para a geracao de conte dos din micos. Listas de produtos de uma loja virtual e u a p ginas ou artigos de blogs ou f rum s o exemplos de informacoes que podem ser a o a armazenadas nesta camada. User prole layer: Esta camada armazena dados de prefer ncias dos usu rios, e a que podem ser utilizadas na geracao de conte dos din micos personaliz veis. u a a Informacoes fornecidas pelos usu rios atrav s de formul rios, para adicionar ou a e a editar suas prefer ncias e informacoes inferidas por sistemas de an lise de come a portamento dos usu rios, para geracao de an ncios de publicidade direcionados, a u s o exemplos de informacoes que podem ser armazenadas nesta camada. a 4.2. Arquiteturas de RDC Para Entrega de Conteudos Web Uma abordagem simplicada de uma RDC para conte dos Web, ilustrada na gura 4.2 u se baseia no princpio da replicacao dos recursos do sistema, ou seja, dos servidores Web, para melhorar o desempenho percebido pelos usu rios ao acessarem a enorme quantidade a de conte dos, que geralmente est o presentes nestes sistemas. Esta replicacao de recursos u a pode se dar de forma local ou distribuda. Na replicacao local, diversos servidores local izados na mesma rede local (Local Area Network - LAN) compartilham a mesma conex o a para o restante da Internet, e funcionam como um cluster de servidores. Desta forma, este cluster de servidores se comporta como um unico sistema computacional de alto desempenho, o que de certa forma aumenta a escalabilidade do sistema e a sua toler ncia a fala has. Entretanto, quando as p ginas Web armazenadas neste cluster de servidores possuem a uma alta popularidade, problemas graves de escalabilidade podem surgir, principalmente

` no que diz respeito a conex o Internet compartilhada pelos servidores que comp em o a o cluster, que pode funcionar como um gargalo no desempenho do sistema, al m de repree sentar um ponto unico de falha. Desta forma, um alto tr fego de rede na zona em que o a cluster est localizado, falhas em roteadores e componentes externos ou ataques do tipo a DoS podem tornar o sistema indisponvel, independente do poder computacional alocado no cluster.

Figura 4.2. Arquitetura de RDC simplicada [Rajkumar Buyya 2008].

J em abordagens de replicacao distribudas, dois tipos de servidores existem na a RDC: servidores de borda e servidores de n cleo. Os servidores de borda devem ser u posicionados o mais pr ximo possvel dos clientes, e geralmente est o localizados em o a pontos de presenca (Points of Presence - POP) de diversos provedores de servico de Inter net (Internet Service Providers - ISP). Estes servidores s o respons veis principalmente a a pela interacoes com os clientes, j que as requisicoes lhes s o encaminhadas, geralmente a a por meio de redirecionamento via DNS. Os servidores de n cleo s o entidades l gicas u a o que geralmente realizam funcoes relativas ao gerenciamento da RDC, coordenacao das polticas de distribuicao de requisicoes e contabilidade. Os servidores de n cleo podem u ser implementados como um multi-cluster, que pode ser denido como um grupo de clus ter que trabalham de forma colaborativa para se comportarem como um unico sistema computacional virtual com alta disponibilidade e poder computacional. Al m destes dois e tipos de servidores, o chamado servidor de origem do conte do tamb m deve existir, de u e ` forma integrada a RDC. O servidor original deve sempre conter uma c pia atualizada o de determinados conte dos e e acessado sempre que necess rio, ou seja, quando os serviu a dores de borda n o possuem, ou n o podem entregar uma determinada r plica aos clientes. a a e 4.3. Replicacao das Camadas L gicas de Sistemas Web o De forma geral, o objetivo principal em se utilizar uma RDC para entrega de conte dos u Web e o de acelerar a entrega dos conte dos aos clientes, com ader ncia aos requisiu e tos de QoS impostos e minimizando os custos operacionas de se manter r plicas destes e conte dos e de transmiti-los. Dentro deste contexto, os servidores de borda da RDC e u o servidor de origem de cada conte do s o os mais relevantes, j que s o estes os reu a a a spons veis pela entrega dos conte dos e relacionamento direto com o cliente. Desta a u forma, como pode ser obsevado na gura 4.3 as quatro camadas l gicas que comp em o o os servidores Web (Front-end, Application, Back-end e User prole) podem ser replicados dos servidores de origem para os servidores de borda da RDC, para permitir a

aceleracao da geracao e entrega de diferentes tipos de conte dos (est ticos, din micos e u a a personaliz veis). a

Figura 4.3. Replicacao [Rajkumar Buyya 2008].

das

camadas

logicas

dos

sistemas

Web

4.3.1. Replicacao do Front-end Layer Na replicacao do Front-end, ilustrada na gura 4.4 os servidores de borda s o re a spons veis apenas pelo gerenciamento e entrega de conte dos est ticos, com o objea u a tivo de melhorar o desempenho e a escalabilidade deste servico. Neste caso, os servi dores de borda se comportam como proxies reversos ou caches para acelerar a entrega de conte dos que podem ser armazenados em sistemas de arquivos. Este tipo de replicacao u ajuda a aumentar a disponibilidade, desempenho e a escalabilidade deste servico, j que a ao trazer os conte dos est ticos para os servidores de borda, que est o mais pr ximos u a a o aos clientes, problemas de indisponibilidade, desempenho e limitacoes de capacidade em links de longa dist ncia n o mais afetar o a qualidade de servico experimentada pelo a a a cliente.

Figura 4.4. Replicacao do Front-end Layer [Rajkumar Buyya 2008]

A utilizacao de um provedor de RDC para entrega de conte dos est ticos na Web u a ` e uma abordagem bastante comum, e remete as primeiras geracoes de RDCs. Entretanto, a entrega de conte dos est ticos ainda e uma tarefa crtica, devido principalmente ao u a

continuado aumento da quantidade de conte dos multimdias na Web. Mover a responu sabilidade de entrega deste tipo de conte do para os servidores de borda de uma RDC u gera grandes benefcios para os clientes, devido a dois motivos. Primeiramente, dado que estes tipos de conte dos normalmente possuem um tamanho relativamente grande, atrasos u de rede impactam signicativamente a performance do servico percebida pelos usu rios. a ` Al m disto, devido a disseminacao de t cnicas de streaming via HTTP na entrega destes e e conte dos, a reducao da vari ncia do atraso de rede resulta em uma execucao ou exibicao u a mais suave e est vel. a Entretanto, nem sempre e possvel replicar todo o conte do multimdia para os u servidores de borda, devido a restricoes de espaco de armazenamento. Neste caso, ape nas partes dos conte dos devem ser replicados, t cnica esta chamada de segment caching. u e Segment chaching pode ser implementada de duas maneiras: sequential caching e inter leaved caching. A t cnica de sequential caching e aplicada em conte dos com uma forte e u sem ntica temporal, e neste caso apenas as partes inciais do conte do s o replicadas, para a u a evitar o tempo de buferizacao. J para conte dos que s o acessados a partir de uma quan a u a tidade signicativa de operacoes de busca por suas partes, t cnicas de interleaved caching e s o aplicadas, em que segmentos mais populares dos conte dos s o replicados. a u a O conceito de segment caching pode ser estendido para p ginas Web formadas por a diferentes fragmentos ou objetos independentes. Neste caso, existe um aumento de complexidade nas funcoes desempenhadas pelo Front-end que foi replicado para um servidor de borda da RDC, j que este precisa gerenciar o armazenamento e a entrega destes difera entes fragmentos, ao inv s de uma p gina Web como um unico objeto. Entretanto, os e a servidores de borda tamb m se beneciam desta t cnica, j que sua utilizacao implica e e a num uso mais otimizado do espaco em disco utilizado para armazenar os objetos replica dos, pois objetos compartilhados por diferentes p ginas Web s precisariam de uma c pia a o o armazenada. Al m disto, caso ocorra uma atualizacao nos conte dos de alguma p gina e u a Web, somente os fragmentos modicados precisam ser atualizados, e n o toda a p gina. a a J para os servidores de origem, duas vantagens podem ser observadas: este servidor n o a a mais precisar montar a p gina Web e apenas uma fracoes dos conte dos armazenados a a u precisar o ser entregues ao cliente. Esta geracao din mica de p ginas Web pelos Fronta a a end replicados nos servidores de borda tende a melhorar o tempo de resposta de entrega de conte dos, melhorando a desempenho do servico observado pelo usu rio nal. u a 4.3.2. Replicacao do Application Layer Um gargalo de desempenho na replicacao do front-end layer e que o application layer do sistema, respons vel pela l gica de geracao de conte dos din micos no sistema Web, a o u a continua centralizado no servidor de origem. A replicacao do application layer para servidores de borda de uma RDC, chamada de computacao de borda ou edge computing, tem o objetivo de reduzir a carga do servidor de origem, o que implica em um maior desempenho, disponibilidade e escalabilidade dos sistemas Web. O back-end layer e user prole layer ainda permanecem como uma base de dadaos centralizada no servidor de origem, compartilhada entre os servidores de borda, como pode ser observado na gura 4.5. Duas solucoes de arquitetura para replicacao do application layer podem ser

Figura 4.5. Replicacao do Application Layer [Rajkumar Buyya 2008]

denidas, baseadas na capacidade dos servidores de borda em diferenciar requisicoes transacionais e n o transacionais. Uma requisicao transacional e um conjunto at mico a o de operacoes de banco de dados que geralmente envolve o travamento de uma parte do banco de dados e atualizacoes em seus registros. J uma requisicao n o transacional re a a aliza apenas operacoes de leitura no banco de dados. Se os servidores de borda da RDC n o s o capazes de fazer esta distincao, todas as requisicoes s o encaminhadas para seus a a a respectivos application layers, onde s o processadas. A l gica do application layer ir a o a ent o realizar chamadas no banco de dados centralizado do sistema. J se os servidores a a de borda s o capazes de realizar esta distincao, apenas as requisicoes n o transacionais a a s o processadas pelo application layer local, enquanto que as requisicoes transacionais a s o encaminhadas diretamente para o application layer do servidor de origem, que ir a a processar a requisicao acessando o seu banco de dados centralizado. 4.3.3. Replicacao do Back-end Layer A computacao de borda n o resolve todos problemas de desempenho em ambientes Web, a j que em alguns sistemas o gargalo da performance reside no back-end layer, ou seja, no a acesso aos registros do banco de dados. Ao replicar o back-end layer para os servidores de borda de uma RDC, como pode ser observado na gura 4.6 um provedor de conte dos u ` ` delega a RDC a funcao de gerenciar os dados da sua aplicacao e responder as requisicoes por dados a partir da borda da rede. A replicacao do back-end layer pode ser encarada ` como um complemento a replicacao do application layer, j que, para que se alcance uma a melhoria de desempenho com esta estrat gia, e preciso que os dados do back-end layer e sejam acessados pela aplicacao do application layer localmente. Dentro do contexto dos sistemas Web, a replicacao do back-end layer pode se dar de de forma parcial ou integral. As replicacoes parciais podem se basear em estrat gias de e caching para melhorar o seu desempenho. Com o mecanismo de Content-Blind Caching, os dados mais populares s o replicados para os servidores de borda. J com o mecanismo a a de Content-Aware Caching, porcoes do back-end Layer s o replicadas ativamente para a os servidores de borda baseado em padr es de acesso dos clientes e condicoes da rede e o da infraestrutura de servidores. Dentre estes dois mecanismos, n o existe um vencedor a

Figura 4.6. Replicacao do Back-end Layer [Rajkumar Buyya 2008].

absoluto, j que diferentes sistemas Web possuem diferentes padr es de acesso. Desta a o forma, diferentes estrat gias de replicacao devem ser empregadas em diferentes sistemas e Web. 4.3.4. Replicacao do User Prole Layer O user prole layer se resume a um banco de dados para armazenamento de dados, assim como o back-end layer. Desta forma, as possveis estrat gias de replicacao mencionadas e na Secao 4.3.3 tamb m podem ser aplicadas para replicacao do user prole layer. En e tretanto, os padr es de acesso dos dados do user prole layer diferem signicativamente o dos do back-end. Em especial, cada usu rio ir se conectar a apenas um servidor de a a borda, fazendo com que os dados de cada perl precisem estar armazenados somente neste mesmo servidor de borda a RDC. Desta forma, uma replicacao integral do user prole layer e claramente desnecess ria, restringindo as t cnicas de replicacao a Contenta e Blind Caching e Content-Aware Caching. A gura 4.7 ilustra este cen rio. a

Figura 4.7. Replicacao do User-prole Layer [Rajkumar Buyya 2008]

E possvel que em determinado momento algum usu rio acesse o sistema Web a a partir de um servidor de borda diferente, o que gera a necessidade dos dados do user prole layer serem replicados para o novo servidor de acesso deste usu rio. O suporte a este a

tipo de comportamento n o e explicitamente tratado em t cnicas traicionais de replicacao a e do back-end layer, o que evidencia a necessidade de mecanismos otimizados para este m. CONCA e um exemplo de um framework gen rico com suporte a mobilidade do e usu rio, permitindo que seu user prole layer o siga. a

5. Conclus es e Trabalhos Futuros o

Este trabalho apresentou conceitos importantes sobre RDCs, no que diz respeito a conceitos b sicos, t cnicas de replicacao de conte dos e gerenciamento e entrega de a e u conte dos Web. Ainda assim, outros t picos relevantes, como o posicionamento e diu o mensionamento de servidores de armazenamento, e t cnicas de redirecionamento de e requisicoes n o foram tratados. Estes t picos devem, futuramente, ser includos, j que a o a representam segmentos importantes de informacoes necess rias para um pleno entendi a mento deste rico t pico, as RDCs. o As RDCs ir o desempenhar um importante papel no futuro dos sitemas de a informacao e comunicacoes modernos. A demanda por conte dos, assim como a com u plexidade e variedades destes, tende a crescer, e ser muito improv vel viabilizar a ena a trega destes conte dos sem mecanismos de planejamento e operacao otimizados. Ainda u que diversas iniciativas de pesquisa tenham desenvolvido mecanismos otimizados para ar quiteturas de RDCs, ainda e evidente que implementacoes reais de RDCs, principalmente as implementacoes comerciais, ainda se valem de mecanismos mais simplicados. O principal trabalho futuro, a ser desenvolvido pelo autor, corresponde ao estudo e implementacao de t cnicas de otimizacao aplic veis as RDCs. Para viabilizar e a as RDCs futuras, e preciso realizar seus projetos de maneira otimizada, para que suas implantacoes sejam economicamente vi veis. Os problemas encontrados no dimension a amento e operacao das RDCs, como o dimensionamento de servidores, determinacao da localizacao otima dos conte dos, mecanismos de replicacao de conte dos, redireciona u u mento de requisicoes e atendimento aos clientes podem ser modelados como problemas de programacao linear, como exemplicados em [Neves et al. 2008a, Neves et al. 2008b, Neves et al. 2009, Neves et al. 2010, Laoutaris et al. 2005]. Entretanto, em muitos casos, a solucao exata destes problemas possuem um custo computacional muito alto, o que in viabiliza a sua aplicacao pr tica. Desta forma, m todos heursticos devem ser estudados, a e concebidos e implementados. Desta forma, os resultados exatos tendem a determinar um limite de desempenho para os m todos heursticos. e

Refer ncias e
(2010). Akamai website. http://www.akamai.com/. (2010). Edgestream website. http://www.edgestream.com/. (2010). Limelight website. http://www.limelightnetworks.com/. (2010). Mirror-image website. http://www.mirror-image.com/. Arlitt, M. and Jin, T. (1999). Workload characterization of the 1998 world cup web site. Technical report, IEEE Network. Francis, P. (2001). Yoid: Your own internet distribution. http://www.isi.edu/div7/yoid/.

Freedman, M. J., Freudenthal, E., and Mazi` res, D. (2004). Democratizing content pube lication with coral. In NSDI04: Proceedings of the 1st conference on Symposium on Networked Systems Design and Implementation, pages 1818, Berkeley, CA, USA. USENIX Association. Laoutaris, N., Zissimopoulos, V., and Stavrakakis, I. (2005). On the optimization of storage capacity allocation for content distribution. Comput. Netw., 47(3):409428. Neves, T. A., Barboza, E. U., Drummond, L. M. A., and Albuquerque, C. V. (2008a). Otimizacao em redes de distribuicao de conte dos. XL Simp sio Brasileiro de Pesquisa u o Operacional (SBPO 2008). Neves, T. A., Drummond, L. M. A., Ochi, L. S., and Albuquerque, C. V. (2009). Replicacao e distribuicao Online em redes de distribuicao de conte dos. XLI Simp sio u o Brasileiro de Pesquisa Operacional (SBPO 2009). Neves, T. A., Drummond, L. M. A., Ochi, L. S., Albuquerque, C. V., and Barboza, E. U. (2010). Solving replica placement and request distribution in content distribution networks. International Symposium on Combinatorial Optimization (ISCO 2010). Neves, T. A., Ochi, L. S., Drummond, L. M. A., Barboza, E. U., and Albuquerque, C. V. (2008b). Optimization in content distribution networks. International Conference on Engineering Optimization (EngOpt 2008). Pierre, G. and Steen, M. (2006). Globule: A collaborative content delivery network. IEEE Communications Magazine, 44:127133. Rajkumar Buyya, Mukaddim Pathan, A. V. (2008). Content Delivery Networks. Springer. Wang, L., Park, K. S., Pang, R., Pai, V., and Peterson, L. (2004). Reliability and security in the codeen content distribution network. In ATEC 04: Proceedings of the annual conference on USENIX Annual Technical Conference, pages 1414, Berkeley, CA, USA. USENIX Association.