CODA (COnstant Data Availability) foi um sistema de arquivos experimental desenvolvido pelo grupo do Prof. Satyanarayanan (CMU) nos anos 90.

Transcrição

1 CODA e Caching Referências: Kistler, Satyanarayanan. Disconnected Operation in the Coda File System, ACM Trans. on Computer Systems, 10(1), February, 92. Kumar, Satyanarayanan. Flexible and Safe Resolution of File Conflicts, Proc. USENIX Winter 95 Conference, New Orleans, Jan. 95. Barbará, Imielinski. Sleepers and Workaholiks: Caching Strategies in Mobile Environments. Proc. ACM SIGMOD 94, p CODA CODA (COnstant Data Availability) foi um sistema de arquivos experimental desenvolvido pelo grupo do Prof. Satyanarayanan (CMU) nos anos 90. Objetivos: oferecer aos usuários (em UM ou na rede) acesso contínuo a arquivos & diretórios UNIX mesmo em caso de falhas de servidores, partições na rede ou desconexões das UMs sistema de arquivos com alta disponibilidade tornar mobilidade transparente para a camada de aplicação usa a mesma API UNIX (system calls) para acesso a arquivos variações na conectividade (p.ex. desconexões) são tratadas de forma transparente CODA foi o 1 o sistema a definir e implementar o modo de operação desconectado Markus Endler 2

2 Arquitetura Na rede, servidores CODA armazenam volumes (subdiretórios UNIX,). Cada volume é replicado em um conjunto de servidores (pelo menos 2) denominado Volume Server Group - VSG As réplicas no VSG são mantidas sincronizadas. Para cada cliente, existe um subconjunto de VSGs chamado AVSG com réplicas dos volumes daquele usuário (p.exemplo: /home/user1, /var/spool/mail/user1.) Cada atualização é propagada para todos os AVSGs e posteriormente para todos os VSGs (antes de qq outro acesso) assim garante-se réplicas consistentes Usa-se um RPC com multicast, multirpc, que garante que os multicasts são tratados de forma atômica (& ordem total). Funcionamento de MultiRPC: encaminhamento para um S AVSG, que executa um atomic multicast não bloqueante com os demais servidores em AVGS. Markus Endler 3 Arquitetura Perspectiva de usuário u S2 S4 VSG S1 S3 S5 AVSG u multirpc cliente Qualquer servidor pode sair e posteriormente se re-integrar ao grupo, e quando isto ocorre, nenhuma ação imediata é tomada. Através do multirpc o cliente pode detectar diferenças entre os volumens nos servidores AVSG (através do modify-timestamp) e forçar a sincronização do arquivo/diretório. Markus Endler 4

3 Arquitetura A replicação de volumes aumenta a disponibilidade de dados para os clientes. Mas como a detecção/resolução de réplicas inconsistentes é feita pelos clientes, isto não garante consistência total das réplicas: Exemplo: enquanto não houver um cliente requisitando os dados, dois servidores podem permanecer com dados inconsistentes quando ocorre uma partição da rede (no conjunto dos AVSGs), somente alguns servidores do AVSG receberão as atualizações. Quando a partição deixa de existir e houver demanda por um cliente, arquivos/diretórios são sincronizados. Abordagem otimista para replicação: permitir atualizações concorrentes e (tentar) fazer a reconciliação na reconexão. Comparada com a abordagem pessimista (= permitir atualizações somente quando possível em todas partições), a estratégia otimista Markus Endler 5 garante maior disponibilidade. Arquitetura Clientes executam um Gerente de Cache (Venus), que mantém no cache arquivos e diretórios frequentemente acessados no disco local da UM Venus (um client-side proxy) é responsável por lidar com os efeitos de possíveis desconexões, e Funciona em 3 possíveis estados: hoarding (normal) desconectado (emulando) re-integração Os dados cacheados por Venus são de segunda ordem: menos seguros, possivelmente incompletos ou imprecisos e menos persistentes mas podem ser atualizados pelo cliente durante uma desconexão (abordagem otimista para replicação) Markus Endler 6

4 Estados de Venus Terminou a sincronização re-integrating hoarding UMse reconectou sem diferenças UM se reconectou com diferenças UM se desconectou disconnected Markus Endler 7 O estado Hoarding * Este é o estado normal, no qual a UM do cliente está conectada com a rede (os servidores do AVSG). Neste estado Venus, toma ações preventivas para uma desconexão súbita: trata de manter em cache todos os arquivos/diretórios potencialmente necessários (ou em uso) por cada um dos aplicativos no cliente A escolha dos arquivos é feita em um esquema de prioridades misto que combina: informações implícitas derivadas do histórico de acessos recentes informações explícitas fornecidas pelo usuário (hoarding dadabase) (*) Hoarding = pre-fetching mais neurótico (quanto mais, melhor) Markus Endler 8

5 O estado Hoarding Periodicamente, Venus re-avalia quais objetos merecem permanecer no cache (hoard walking) a consistência entre a cópia em cache e no AVSG é sinalizada através de callback: quando arquivo original é modificado no servidor, este envia aos clientes notificações Invalidation Report (na terminologia CODA: quebra de callback ) Cliente móvel Hoard A database Venus cache Notificação: quebra de callback callback Servidores CODA A AVSG Markus Endler 9 O estado Hoarding Informações implícitas: sempre que um arquivo é usado (ou aberto) por um processo, uma cópia do mesmo é feita para o cache do Venus Exemplo: bibliotecas, includes, arquivos do /usr/bin, etc. cada arquivo recebe uma prioridade (setada para valor maximo no momento do acesso), mas que vai decaindo com o tempo (política aging ) arquivos que atingem a prioridade mínima são candidatos à substituição arquivos modificados permanecem com prioridade máxima Informações explícitas (perfil definido pelo usuário): Hoard database contém os arquivos mais utilizados (com prioridades) usuário dispõe de ferramentas para adicionar/remover arquivos/diretórios (pode adicionar também um sub-diretório completo) Markus Endler 10

6 Hoard Profiles Pedidos de adição de arquivos/diretórios ao Hoard Database são feitos através de Hoard Profiles. Exemplo: #personal files a /home/endler/docs 100:d+ a /home/endler/bin d #system files a /usr/bin 100:d a /usr/lib 100:d a /usr/local/gnu 100:d O + indica que todos arquivos/subdiretórios devem ser cacheados com a mesma prioridade. Prioridade default é 10. Para permitir a resolução do caminho (PATH), quando um arquivo é cacheado, todos os diretórios superiores também são cacheados com a mesma prioridade. Para facilitar a edição do Hoard Profile, CODA disponibiliza a ferramenta spy, através da qual o usuário pode monitorar quais são os arquivos usados por suas aplicações. Markus Endler 11 Hoard Walk A cada 10 segundos, Venus analisa todos os arquivos em cache: cada arquivo com um callback quebrado é atualizado no AVSG usando um multirpc para cada diretório na Hoard DB, é verificado se houve alguma modificação (adição/remoção de algum arquivo/diretório) Note que uma preocupação de qualquer politica de gerência de cache deve ser a estabilidade do cache. Exemplo: se o cache estiver cheio, e um arquivo A for acessado uma única vez, começará com alta prioridade, (eventualmente fazendo com que um outro arquivo B saia), mas com o decorrer do tempo arquivo A perderá prioridade e será candidato a sair, fazendo com que possivelmente B seja copiado de volta para o cache. Para evitar isto: garantir um tempo mínimo de permanência (independente de acessos) Markus Endler 12

7 O estado Desconectado Neste estado, Venus assume o papel de um servidor AVSG operando somente sobre os arquivos em cache. Exemplo: abre arquivos/diretórios, permite alterações, fornece fileids, etc. No entanto, todas as operações são tentativas e deverão ser posteriormente confirmadas (após a reconexão). Cache misses geram excessões para programas de aplicação. Devido à abordagem otimista, cliente desconectado pode fazer as mesmas atualizações do que um cliente conectado. Todas as atualizações são registradas em um log (CML), que é implementado usando um mecanismo de transações A fim de limitar/reduzir o tamanho do log, antes de adicionar uma entrada ao log, verifica-se se a nova entrada anula uma anterior. Exemplo: write(a,data), del(a) Se o CML ficar cheio, Venus suspende qualquer nova alteração em qualquer arquivo/diretório. Markus Endler 13 O estado Re-integração Após a reconexão com o AVSG, Venus: propaga todas as atualizações registradas no CML para todos os AVSGs atualiza o cache com a nova versão dos arquivos/diretórios A propagação ocorre em 2 etapas: 1) Venus requisita fileids definitivos para os fileids locais de arquivos eventualmente criados, e faz a substituição destes no CML log 2) envio do log CML em paralelo para todos os servidores AVSG, que executam o log como uma transação atômica (se uma atualização falha, toda transação de reintegração é cancelada) Markus Endler 14

8 O estado Re-integração Etapas do processamento do log CML: 1. todos os arquivos referenciados no log são bloqueados 2. valida-se cada operação no log (existe espaço em disco?, há permissão de acesso?, operação causaria perda de consistência do sistema de arquivos?) 3. o conteúdo dos arquivos referenciados no log é copiado para os servidores 4. todos os bloqueios são liberados Se reintegração falha, é gerado um novo log indicando os problemas da reintegração. CODA disponibiliza ferramentas para analisar este log, comparar o conteúdo dos arquivos/diretórios no AVSG e no cache e editar o log CML a fim de remover operações que tenham causado conflito Depois, o usuário pode tentar novamente a reintegração com o log modificado. Markus Endler 15 Resolução de Conflitos CODA oferece flexibilidade para a resolução de conflitos: Conflito em Diretórios: conflito somente se: novo nome de arquivo é igual a um nome existente; se um objeto foi modificado e ao mesmo tempo removido; atributos de um objeto tenham sido modificados diferentemente no servidor e no cache (exemplo: rwx bits) Conflito em Arquivos: quando Venus detecta divergências em um arquivo, procura por um programa (Application Specific Resolver - ASR) para este arquivo. Se existe, invoca o programa que: modifica a cópia do arquivo local l (cache) e copia a versão modificada d para o servidor (enquanto isto, arquivo fica bloqueado). Se não existir um ASR para um arquivo, usuário tem que fazer manualmente as mudanças no arquivo a fim de resolver o conflito. Obs: CODA não garante que o dado em seu cache é o mais atual (p.ex. Dados sendo modificados por outro cliente) não implementa semântica de compartilhamento de arquivos UNIX Markus Endler 16

9 Conectividade Fraca É um modo de interação entre UM e rede quando o enlace sem fio: apresenta alta latência, alto custo, baixa vazão, p.ex. devido a alta taxa de erros Em sistemas de arquivos, as abordagens para lidar com conectividade fraca podem variar nos seguintes aspectos: Como tratar cache misses? Como/quando propagar as atualizações dos objetos no cache para a rede se periódico, com qual frequência? se esporádico, em qual momento atualizações devem ser propagadas? Para quais arquivos/diretórios? transmissão do arquivo completo, ou somente das diferenças? Como interpretar a validade dos objetos cacheados? Markus Endler 17 Conectividade Fraca em CODA Técnicas usadas para lidar com conectividade fraca: Tratamento seletivo de cache misses cache miss só causa cópia do arquivo do AVSG se o tempo de transmissão da cópia for menor do que limite de paciência para aquele arquivo limite de paciência é logaritmico no tamanho do arquivo (e depende de sua prioridade) Reintegração pingada (Trickle Reintegration) processo em background envia arquivos modificados para o AVSG (em momentos de pouca utilização) Markus Endler 18

10 Conectividade Fraca em CODA Técnicas (cont.) Aging somente arquivos que já estejam certo tempo no cache devem ser transferidos (para evitar que arquivos modificados, mas ainda em uso sejam transferidos) Transmissão de blocos de dados acumula-se várias atualizações antes de envia-las para o AVGS Coerencia do Cache é verificada por demanda (em vez de hoard walks periódicos, que fazem o download automatico caso haja quebra de callbacks) antes de abrir um arquivo, verifica-se se versão local é atual Markus Endler 19 CODA: Experimentos Em 1993, estudo envolvendo aprox. 25 usuários durante 1 semana. Resultados: Disco local l de 100 Mbytes mostrou-se suficiente para cache+log para operação desconectada por 1 semana. (reintegração diária) Tempo gasto para reintegração após 1 dia desconectado = 5 min. 99% das modificações em arquivos UNIX são feitos pelo mesmo usuário da modificação anterior Devido ao baixo grau de compartilhamento, ocorreram poucos conflitos do tipo write-write Replicação do UNIX FileSys em 4 servidores: Desempenho apenas 5% pior do que sem replicação (usando Andrew Benchmark) CODA apresentou baixa escalabilidade (n o de usuários concorrentes) CODA mostrou que Sistemas de Arquivos são um modelo de compartilhamento de dados compatível com operação desconectada! Markus Endler 20

11 Caching em Redes Móveis Caching de dados/objetos nos clientes móveis técnica essencial para garantir o funcionamento de aplicações em redes móveis. Vantagens: evita que cliente perceba a latência de enlaces lentos menos transmissões pelo enlace sem fio economia de energia da bateria menor gasto da largura de banda passante do meio sem fio permite operação em modo desconectado aumenta a escalabilidade dos servidores na rede fixa Principais problemas: como garantir a atualidade dos objetos cacheados? como fazer a resolução de conflitos de alterações efetuadas nos objetos cacheados por vários clientes? Markus Endler 21 Política de Caching: Principais questões Onde manter o cache? (UM, ERB?). Usar vários níveis de cache? Qual deve ser a granularidade dos objetos a serem cacheados? (arquivos, segmentos de arquivo, registros de BD?) Como invalidar objetos cacheados quando a cópia original foi modificada? Como notificar UMs desconectadas? Quais são as garantias de consistência que podem ser dadas ao usuário? Vale a pena manter a consistência entre cópia na rede e cópia em cache? Quais são as consequências sobre o tempo de resposta (de acesso aos objetos) e o overhead na rede, e o throughput do sistema (taxa global de finalizações) Não dá para decidir sem conhecer a aplicação, o tipo de rede e o perfil de uso. Markus Endler 22

12 Caching em Redes Móveis As seguintes características devem ser consideradas para a escolha do mecanismo de cache e sua política: Com relação a aplicação: Frequência de acesso a dados Frequência de atualização de dados Grau de Compartilhamento dos dados Requisitos de disponibilidade vs. consistência de dados Política de Descarte de objetos do Cache (ex. LRU, validade) É possível antecipar/prever quais dados serão necessários em determinado momento ou local? Markus Endler 23 Caching em Redes Móveis Características a serem consideradas: Com relação a rede móvel: Custo da comunicação no enlace sem fio e na rede Padrão de mobilidade dos clientes Padrão de conectividade dos clientes Frequência de desconexões Duração ç média das desconexões Largura de banda e latência média do enlace sem fio Com relação aos dispositivos: Capacidade de memória para manter dados em cache. Markus Endler 24

13 Classificação de Esquemas de Invalidação de Caches Quem é responsável por detectar/notificar inconsitencias? Servidor (push) ou cliente (pull): callbacks ou validation checks Servidor deve manter o estado de acesso para cada cliente? Statefull vs. Stateless server Como servidor envia Invalidation Reports? Forma síncrona vs. assíncrona: com ou sem confirmação da UM Conteúdo de um Invalidation Report o novo estado do objeto ou a(s) atualização(ões) realizadas Codificação dos Invalidation Reports Simples ( plain ) ou compactados Markus Endler 25 Principais Abordagens para Manutenção de Caches Hoarding em CODA assíncrono e stafull server (que notifica sobre callbacks quebrados) cliente (venus) faz a validação dos objetos em cache Difusão de Invalidation Reports [Barbara94] servidor stateless difunde periodicamente (cada t) IRs sobre todos os objetos cacheados em clientes e que foram modificados durante o último período k* t clientes usam IRs para atualizar os objetos cacheados. Consulta local só retorna, ao receber um novo IR cliente (desconectado) que deixa de receber k IRs remove todos os objetos do cache Asynchronous Stateful Caching Scheme [Kahol et al.2000] Markus Endler 26

14 Asynchronous Stateful Caching Scheme Motivação: Problemas das outras abordagens: Difusão de IRs: consulta local precisa aguardar um IR não dá suporte a quaisquer padrões de desconexão CODA: servidores stateful: informações sobre objetos cacheados nos clientes Ideia Central do ASC Scheme: mantém um HomeLocationCache no home MSS, que reflete o estado do cache na UM. MSS recebe os IRs (mantendo o timestamp do IR mais recente) e realiza a consulta aos novos valores em nome da UM o cache na UM também tem um cache timestamp (ts do último IR recebido) ao se reconectar, UM envia um probe para o MSS para descobrir se perdeu algum IR durante a desconexão, e atualiza o seu cache Markus Endler 27 Exemplo do ASC MSS Fetch y from server New x add (y,t2) New y New z (x,t1) Query (z,t4) (y,t1) (y,t3) (y,t2) (*,t2) (y,z,t5) MH t0: t1: t2: Lost IR t2: t5: [x,z] [z] [y,z] [y,z] [] ASC lida com períodos arbitrários de desconexão. Markus Endler 28