distribuição de mídia contínua replicacao de conteudo jussara m. almeida abril 2005

Distribuição de Mídia Contínua

Replicacao de Conteudo

Jussara M. Almeida

Abril 2005

Onde Fazer Replicacao de Conteudo?

Rede Remota

Rede“Loca

l”

Rede“Loca

l”

Rede“Loca

l”

Servidor Origem

Servidor Proxy

Servidor Proxy

Servidor Proxy

Nos clientes: reduz jitterNos proxies: reduz latencia e demanda por banda na rede e servidorNo servidor: reduz atraso e demanda por banda do disco

Politica de Replicacao• Politica de insercao

– Criterio para determinar se um novo conteudo deve ser inserido no cache

• Politica de remocao– Criterio para determinar qual objeto,

armazenado no cache, deve ser removido para liberar espaco para novo conteudo

Politicas de Replicacao Tradicionais (Web)

• Politicas de Insercao: tipicamente nao sao explicitamente definidas, isto e, sempre insere conteudo requisitado no cache.

– Desastre em potencial para Midia Continua• Politicas de remocao

– Least Recently Used (LRU):• Remove do cache conteudo menos recentemente

acessado para liberar espaco para novo arquivo– Least Frequently Used (LFU):

• Remove do cache conteudo menos frequentemente acessado para liberar espaco para novo arquivo

– Variacoes (Greedy-Dual)• Leva em consideracao recencia, tamanho, custo, etc

Numero de arquivos novos acessados Somente 1 vez em cada hora: tempo ate proximo

acesso:

• Resultados similares para: h 1,2,4,8, multiplos dias, ambos servidores, e segmentos no

eTeach• Armazenar todo arquivo que nao e encontrado no cache nao e

boa ideia

Acessos a Objetos Pouco Populares

0

10

20

30

7AM 11AM 3PM 7PM 11PM 3AMHour

Num

ber

of F

iles

Unique Files New Files New Files Accessed Once

Arquivo novo = arquivo nao acessado nas ultimas h horas

0%20%40%60%80%

100%

1 2 4 8 16 32 64 128Time Until Next Access (Hours)

Cum

ulat

ive

%

New Files Accessed Once

Midia Continua: O Que Replicar?• Arquivos inteiros

– Arquivos grandes, restricao de espaco • Espaco e barato

– Interatividade• Alguns trechos de um video sao mais populares

• Segmentos– Qual o tamanho do segmento

• Camadas– Codificacao em camadas

• Intervalos– Entidade dinamica, refletem a recencia dos acessos

Intervalo• Buffer circular com conteudo dinamico

Arquivo f

S1

0 T

Tempo

S2 S1

0 T

i

S2 S1

0 T

i0 T

S2 S1

Intervalo• Tamanho do intervalo reflete recencia

dos acessos– Menores intervalos, acessos mais proximos,

arquivo mais popular

• Demanda por banda de disco:– Um fluxo escritor (preceding stream) e um

fluxo leitor (following stream)

• Demanda por espaco:– Tempo entre acessos X bitrate do arquivo

Interval Caching (IC)• Armazena os “menores” intervalos

– Objetivo: max # fluxos servidos do cache– Se arquivos com bitrate diferentes

• Armazena intervalos com menor demanda por espaco– Cada intervalo economiza um fluxo do disco (leitor)

– Se arquivos com bitrates iguais• Armazena no cache blocos que serao utilizados de

novo no futuro mais proximo (LRU)

• Adaptacao dinamica a variacoes na carga• Pouco efetiva se arquivo pequeno /interatividade

– Pequena prob. de multiplos acessos por playback

Generalized Interval Caching (GIC)

• Extensao de IC para cargas heterogeneas– Acessos a arquivos longos– Acessos a pequenos clips / interatividade

• Arquivos longos:– Multiplos acessos ao mesmo arquivo durante

playback• Arquivos pequenos:

– Tipicamente, somente um acesso em andamento, em um dado momento

GIC: Conceitos• Intervalos: entre dois fluxos simultaneos

(arquivos longos)– Tamanho do intervalo: tempo entre dois acessos– Demanda por espaco:

tempo entre dois acessos X bitrate do arquivo

• Intervalos antecipados: tempo entre dois acessos consecutivos (fluxos nao simultaneos, arquivos pequenos)– Tamanho do intervalo: tempo entre dois acessos

(estimado com base nos dois ultimos acessos)– Demanda por espaco: tamanho do arquivo

(se decidir cachear, arquivo inteiro e armazenado)

Politica GIC

Politica GIC• Ordena intervalos (reais ou antecipados)

em ordem de tamanho do intervalo– Mesmo principio da LRU

• Armazena o maior numero de intervalos, dado o espaco existente

Politica GIC• Detalhes de implementacao (Figs 2 e 3 )

Politica GIC• Detalhes de implementacao (Figs 2 e 3 )

– Mudancas na lista de intervalos ocorrem somente quando da chegada ou termino de um novo fluxo: simplicidade

• E com operacoes de VCR?

Avaliacao da Politica GIC• Simulacao (modelos analiticos sao dificeis)• Carga: duas classes de objetos

– Arquivos longos (92 arquivos)• Distribuicao de popularidade: Zipf (0.271)• Tamanho: 90 mins ou 1 GB

– Clips (interactive workload)• Popularidade: 80% acessos para 20% dos clips• Tamanho do arquivo: uniforme (1-30 segs)• Tempo de visualizacao: exponencial

media =30 segs (banners) e min= 5segs• Duracao da sessao: 30 mins

Avaliacao da Politica GIC• Interactive probability: prob de sessao de cliente

ser para clips• Processo de chegada de clientes: Poisson• Servidor:

– Memoria: sequencia de blocos – Se nao faz caching: 2 blocos alocados para cada

fluxo • Resultados

Replicacao em Discos• Replicacao em servidores proxy localizados mais

proximo dos clientes– Rede entre proxies e servidor origem passa a ser o

gargalo (antes era disco)

• Arquivos grandes com demanda por espaco e largura de banda

• Restricao de largura de banda ignorada por:– Politicas de caching de blocos /arquivos em memoria

principal– Politicas de caching de objetos Web em disco

Replicacao em Discos• Politicas de caching tradicionais

– Algoritmos baseados na frequência (ex: LFU).• Se comportam melhor para cargas que mantem um

padrão mais constante de acesso. • Funcionam bem para mídia contínua. • Não reagem bem a mudanças na carga.

– Algoritmos baseados na Recência (ex: LRU).• Exploram a localidade de referência de um arquivo.

Muito sensível a mudanças temporárias na carga.– Métodos Híbridos (LRFU, LRU-k):

• Algoritmos que exploram a recencia e freqüência.

Replicacao em Discos

• Interval Caching: boa ideia?

Desperdicio de 50% da banda do disco do proxy:

Um escritor para cada leitor

Resource-Based Caching para Midia Continua

• Objetivos:– Tentar manter a utilização de banda e

espaço equivalentes. (“andar na diagonal do gráfico”)

Resource-Based Caching para Midia Continua

• Objetivos:– Replicar o conteúdo requisitado num futuro

mais próximo (recência).– Ser um algoritmo de “replicação flexível”

(distribuindo diversos tipos de mídia) decidindo em tempo real “o que replicar” de um determinado arquivo.

– Permite a replicação de diferentes tipos de entidade

RBC – Entidade• Uma entidade é uma unidade atômica de um

objeto que será armazenada na cache.• Tipos de Entidade:

– Objetos estáticos: arquivos inteiros.– Objetos dinâmicos:

•Armazenados em Intervalos (como no IC).•Armazenados em Runs:

• Somente arquivos MC são armazenados desta forma. Objetos não-MC são armazenados inteiros e distribuidos com melhor-esforço.

• Run pode ser vista como a extensão do intervalo em uma entidade única.

• Quando mais de dois usuários acessam o mesmo arquivo concorrentemente pode ser interessante compartilhar o escritor(wi)

• Cada run possui um escritor (wi) e diversos leitores (ri) concorrentes.

Runs

• Cada entidade possui demanda por recursos:

•Arquivo Inteiro:– = Tamanho do Arquivo.– = número estimado de requisições durante o playback.

•Intervalo:– = di*bi, onde d = intervalo o acesso corrente e o último.– = (ri + wi)*bi => 2*bi.

•Run:– = di*bi.

– = (ri + wi)*bi.

RBC – Entidade

RBC – Atributos da Entidade

• Caching Gain:– BHR (Byte Hit Ratio): razão entre a

quantidade de bytes servidos pelo cache e número total de bytes requisitados

– O HR (Hit Ratio): razão entre a quantidade de acessos para arquivos presentes na cache pelo número total de acessos.

RBC – Atributos da Entidade

•Goodness: usado para escolher qual entidade sera retirada do cache

•Bw_goodness = gi/bi

•Space_goodness = gi/si

RBC – Seleção da Entidade para entrar na Cache

• Seja Us = utilização de espaço e Ub = utilização de banda

Se Ub > Us + e:Escolher entidade com o

menor “overhead de escrita” => min(wi/(wi + ri))

Se Us > Ub + e:Escolher a entidade com

menor tamanho => min(si)

Se |Us -Ub| < e:Escolher entidade max


• Seja Us = utilização de espaço e Ub = utilização de banda

Se Ub > Us + e:Escolher entidade com o menor “overhead de

escrita” => min(wi/(wi + ri))Se Us > Ub + e:

Escolher a entidade com menor tamanho => min(si)

Se |Us -Ub| < e:Escolher entidade max

RBC – Algoritmo de Inserção de Entidades na

Cache• Estados da Cache:

– Sem Restrição: banda e espaço excedem os requisitos para a entidade sendo alocada. Neste caso a entidade é colocada na cache.

– Restrição de Espaço: cache tem banda para alocar a entidade mas não tem espaço livre suficiente.

– Restrição de banda: cache tem espaço para alocar a entidade mas não tem banda livre suficiente.

– Restrição de banda de espaço: cache não tem espaço nem banda livres para alocar a entidade.

RBC – Algoritmo de Inserção de Entidades no

CacheIf ( && )

– insert_in_cache(Ei);If ( && )

– space_constrained-policy(Ei);If ( && )

– bandwidth_constraint_policy(Ei);If ( && )

– Bw_space_constrained_policy(Ei);

RBC – Algoritmo de Substituição de Entidades no

Cache

RBC - Detalhes de Implementação• Estimativa do número de leitores:

– ri = (duração do arquivo)/(TTR)

• Calculando o Inter-arrival Time (TTR = 1/l*pi):– Análise Estatística.– Contador de Referência: Método baseado em frequência

(LFU). Pouco sensível a mudanças.– Tempo de Acesso: Método baseado em Recência (LRU-

k). Sensível a mudanças. (LRU < LRU-k < LFU)– Método utilizado: MTTR (híbrido).

– MTTR(t0) = (1 – a)(t0 – t1) + a*MTTR(t1)» Aumenta a (recência)» Diminui a (freqüência)

Experimentos: Carga Utilizada

• Caracterização de carga utilizada:– Baseado nos logs da NLANR, NCSA e NASA– Distribuição dos Dados: Predominância de

arquivos de texto e imagens. (1% dos acessos para CM)

– Popularidade: Modelado com Zipf– Tamanho dos objetos: Uniformemente

distribuidos com os objetos de não-CM sendo algumas ordens de magnitude menor que os objetos do tipo CM.

Resultados dos Experimentos

• Comparação do RBC com diferentes tipos de Entidade– Teste com intervalo e arquivo inteiro:

•Banda restrita:– Armazena mais arquivo inteiro

•Espaço Restrito:– Armazena mais intervalo

– Testes utilizando runs, intervalos e arquivo inteiro

•RBC utilizando runs foi melhor.

• Comparação do RBC com outros algoritmos.– Quanto a BHR:

• RBC superior a LRU-2 (arquivos inteiros) e WLRU-n (arquivos inteiros).

– Quanto a HR:• RBC superior a LRU-2, WLRU-n e LRU-min.

• Comparação do RBC com variedade de cargas:– Foi comparado com o LRU-2, LRU-min e o WLRU-n.– 80% de cargas não-CM e 20% de carga CM.– O RBC foi superior.

Resultados dos Experimentos

Comentários Finais• Observações sobre os gráficos:

– Gráficos e parâmetros não foram explicados.– Valores muito fora da realidade para banda e

espaço.– Inconsistência de dados.

• Complexidade do Algoritmo:– Em nenhum momento do texto a

complexidade do algoritmo é discutida.

Caching Cooperativo• Múltiplos proxies cooperam para

atender requisições de clientes• Questões importantes:

– Protocolo de comunicação entre proxies

– Replicação independente ou não•Múltiplas cópias de um mesmo objeto•Uma única cópia do objeto

– Consistência entre cópias– Balanceamento de cargas

Middleman : A Video Caching Proxy Server

• Arquitetura distribuída com múltiplos servidores proxy– Rápida comunicação entre servidores– LAN ou campus network

• Avaliação de diferentes políticas de caching

• Projeto baseado no estudo de cargas reais de video sob demanda na Internet

Observações em Cargas de Vídeo Reais

• Tamanhos de vídeos variados– Tamanhos de vídeos na Web em torno de

1MB, mas tendência a crescimento– Tamanho em rede de banda larga (Suécia)

era em torno de 96MB– Sistema de cache tem que ser flexível

• Vídeos are WORM – write once read many– Consistência do cache não é um problema

Observações em Cargas de Vídeo Reais

• Padrões de acesso:– 61% dos acessos foram para arquivos

inteiros– 39% pararam logo no início do vídeo– Cache tem que permitir armazenamento

parcial de arquivos

• Alta localidade temporal nos acessos– Caching é uma boa estratégia

Middleman: Principais Componentes

• Dois componentes principais– Coordenadores– Servidores proxy

•Servidores proxy locais•Servidores proxy de armazenamento

• Coordenador:– Tipicamente um por sistema– Mantém registro do que está armazenado

em cada proxy – Toma as decisões de subsituição de

conteúdo do cache para o sistema inteiro


• Servidores proxy locais– Responsáveis por atender requisições de

clientes– Podem rodar na mesma máquina do cliente

(browser plug-in)– Alternativamente, podem rodar em máquinas

específicas do sistema, responsáveis por um conjunto de usuários

• Servidores proxy de armazenamento– Armazenam dados– Não respondem a requisições de clientes


• Proxy cluster: coleção de servidores proxy (locais e de armazenamento) rodando em uma LAN e organizados por um único coordenador

Vantagens:• Redução da latência• Grande quantidade de espaço• Redução da carga

(servidor e proxies)• Escalabilidade

Desvantagens:• O Coordenador é um possível gargalo e ponto único de falha

Middleman: Política de Caching• Caching de blocos de arquivos

– Cada arquivo é segmentado em uma sequência de blocos

– Blocos são armazenados de forma independente, possivelmente em servidores diferentes

– Possível atraso na troca de servidores para blocos diferentes

– Blocos são armazenados à medida que forem requisitados pelos usuários

– Blocos não requisitados não são armazenados

Middleman: Política de Caching• Não tem política explícita para inserção de

conteúdo : sempre insere– Problema em potencial

• Remoção de blocos de arquivos– Aplica política para escolher qual arquivo deve

ser removido (ex: arquivo menos popular)– Remove bloco por bloco, à medida que for

necessário, a partir do último bloco (inspirado na caracterização de carga anterior)

Middleman: Exemplo de Funcionamento

Funcionamento: Cache Miss Cliente B1

requisita arquivo M e a requisição é interceptada pelo servidor local LP1

Overhead de comunicação entre servidores proxy e coordenador

Cancelamento de Requisição• Cliente interrompe fluxo durante visualização de bloco M2 • Browser interrompe conexão com servidor proxy local (LP)• Se requisição era cache hit, LP interrompe demais

conexões e informa coordenador• Se requisição era cache miss: LP notifica coordenador

– Se este é o único usuário acessando o arquivo no sistema:

• Coordenador informa LP que ele pode interromper demais conexões

• Todas referências a M2 são apagadas. M1 permanece armazenado no sistema

– Se há outros usuários acessando o arquivo:• Coordenador pede LP para continuar a baixar M2 e

salvá-lo em algum servidor proxy de armazenamento

Avaliação• Simulação com traces de acesso a um

servidor educacional/entretenimento na Univ. Lulea (Suécia)– Traces cobrem 2 anos e 2 meses– Carga muito baixa

• Cache size agregado, normalizado pela quantidade total de dados

Políticas de Remoção de Conteúdo• LRU, LFU, FIFO

• LRU-K– Mantém um histórico dos últimos k acessos de

cada objeto no cache– Remove o último bloco do arquivo com a maior k-

distance– A k-distance de um arquivo em um dado instante

é a diferença entre o tempo corrente e o instante em que o k-esimo acesso foi realizado

• HistLRUpick: – Roda LRU-k e desempata escolhendo bloco do

servidor menos carregado– Balanceamento de carga

Byte Hit Ratio

Balanceamento de Carga entre Proxies

Codificação em CamadasHierárquica

• Hierarchical Layered Encoding– Fluxo dividido em n camadas– Camada básica fornece um mínimo de qualidade– Camadas superiores provêm melhorias de qualidade– Camada i só é útil na presença de camadas 0,1, …, i-

1• Útil para clientes heterogêneos

– Cliente com banda larga deseja receber fluxo de alta qualidade

Protocolo Cliente-Servidor para Adaptação de Qualidade

• Fluxos codificados em camadas• Servidor e cliente realizam controle de

congestionamento– Protocolo RAP– Taxa de transmissão muda dinamicamente em

função da banda disponível– Número de camadas adaptado dinamicamente

Adicionando Proxy Cache• Proxy realiza controle de congestionamento

com servidor e com clientes– Qualidade de um fluxo armazenado no cache

depende da banda disponível entre servidor e primeiro cliente

– Ajuste de qualidade de grão fino•Camadas divididas em segmentos de tamanho fixo

– Camadas superiores são gradualmente armazenadas no cache para melhorar a qualidade

Política de Caching• Baseada em prefetching de segmentos sob demanda

– Explora variações na popularidade dos arquivos e limitações de banda dos clientes interessados

• Política de substituição apenas (sempre insere)– Substituição na granularidade de segmentos

• Suporta interatividade (parcialmente)• Minimiza latência inicial• Qualidade de um fluxo transmitido a um cliente não é

limitada à banda disponível no servidor origem– Proxy “esconde” gargalos no caminho entre proxy e origem

Cache Miss• Proxy intercepta requisição e repassa ao

servidor• Conteúdo é enviado do servidor ao cliente pelo

proxy– Proxy armazena conteúdo localmente– Como servidor realiza adaptação de qualidade,

conteúdo armazenado tem qualidade variada

Cache Hit• Proxy deve realizar controle de

congestionamento e adaptação de qualidade– Se banda com cliente maior que qualidade do fluxo

armazenado, proxy deve enviar segmentos que não existem no cache

– Prefetching sob demanda, em resposta a novas requisições pelo mesmo conteúdo : explora popularidade do arquivo

– Proxy realiza prefetching de segmentos faltantes de camadas parcialmente armazenadas e também de camadas superiores (adição de novas camadas)

Prefetching

Prefetching• Quando realizar o prefetching de um segmento

faltante?– Quanto antes, maior a chance de recebê-lo a tempo,

mas menos precisa é a estimativa da qualidade • Janela de prefetching

– No instante tp de visualização, proxy examina o intervalo [tp+T, tp+T+] e identifica os segmentos faltantes das camadas no cache bem como novas camadas

– Proxy envia UMA requisição de prefetching ao servidor com todos os segmentos faltantes

– Servidor envia segmentos em ordem de prioridade– Novas requisições de prefetching preemptam

requisições em tratamento

Prefetching

Política de Substituição de Conteúdo do Cache

• Objetivo: convergir para estado eficiente do cache• Estado do cache é eficiente se:

– Qualidade média de qualquer fluxo no cache é diretamente proporcional à sua popularidade.

• Qualidade média de um fluxo deve convergir para banda média dos últimas transmissões para clientes interessados

– Variação na qualidade de qualquer fluxo no cache é inversamente proporcional à sua popularidade

• À medida que a popularidade de um fluxo correntemente no cache diminui, sua qualidade e seu tamanho (no cache) são reduzidos, até ser completamente removido do cache

Padrões de Remoção de Conteúdo

• Escolhe a camada mais superior como vítima da remoção– Utiliza função de popularidade

• Remove segmentos da camada vítima, do último para o primeiro– Evitar fragmentação– Manter prefixo para redução de latência inicial

• Se necessário, escolhe nova camada e repete processo• Primeiros segmentos da camada básica são mantidos no

cache: esconder latência inicial de requisições futuras

Prioridade para Remoção dentro de um Fluxo

Função de Popularidade• Weighted hit: mantido para cada camada de cada

fluxo– Whit = PlaybackTime / StreamLength– 0 whit 1

• Whit de uma sessão calculado ao final da mesma• Índice de popularidade de um arquivo: valor

acumulado do whit durante uma janela recente

• Interatividade capturada de forma restrita

Função de Popularidade: exemplo

Mecanismo de travamento• Enquanto um fluxo está sendo transmitido para

um cliente, suas camadas no cache são travadas (locked), não podendo ser removidas

• Evita remoção de segmentos finais da camada i para inserção de segmentos iniciais da camada i+1

Avaliação• Simulação para mostrar correção do mecanismo

– Cache atinge estado eficiente• Não avalia desempenho da política

– Experimentos simples• Métricas

– Completeza: % dos fluxos residindo no cache– Continuidade: tamanho médio das sequências de

segmentos consecutivos no cache•variação dos fluxos no cache

Resultados• Mecanismo de prefetching

– Cache size = infinito (sem substituição)– BW servidor-proxy = 56 Kbps– BW proxy-cliente = 1.5 MBs– Figura 9

•Convergência mais rápida para camadas mais básicas

Resultados• Política de substituição de conteúdo

– Cache size = 50% dos dados– BW servidor-proxy = 56 Kbps– 2 clientes : cliente 1 = 1.5 MBps e cliente 2 = 56 Kbps– Cenário 1: 95% requisições de cliente 1

•Figuras 10 e 11– Objetos mais populares têm mais camadas no

cache, e estas camadas têm melhor qualidade (completeza e continuidade)

– Cenário 2: 95% requisições de cliente 2 (banda do cliente limitada)

•Figuras 12 e 13

distribuição de mídia contínua replicacao de conteudo jussara m. almeida abril 2005

Documents