CODA e Caching CODA. Ideia principal. Usar cache. Geralmente ligado ao aumento de desempenho Novidade: aumentar a disponibilidade

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. The Coda Distributed File System,Braam, P. J.,Linux Journal, June 1998 CODA CODA (COnstant Data Availability) é 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 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 Ideia principal Usar cache Geralmente ligado ao aumento de desempenho Novidade: aumentar a disponibilidade Markus Endler 3 1

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 (acessível) com réplicas dos volumes daquele usuário. 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 em ordem total. Funcionamento de MultiRPC: encaminhamento para um S AVSG, que executa um atomic multicast com os demais servidores em AVGS. Markus Endler 4 Arquitetura S2 S4 VSG S1 S3 S5 AVSG 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 dados nos servidores AVSG (através do modify-timestamp) e executar um multirpc para sincronizar o arquivo/diretório. Markus Endler 5 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: Exemplos: 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, tenta-se sincronizar os arquivos/ diretórios 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 em uma das partições), a estratégia otimista garante maior disponibilidade Markus Endler 6 2

3 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 as consequências de mobilidade e desconexões, e opera 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 também ser atualizados pelo cliente durante uma desconexão (abordagem otimista para replicação) Markus Endler 7 Estados de Venus Terminou a sincronização re-integrating hoarding UM se reconectou sem diferenças UM se reconectou com diferenças UM se desconectou disconnected Markus Endler 8 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, mantém-se preparada 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 processos 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) 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 de quebra de callback Obs: Hoarding = pre-fetching mais neurótico (quanto mais, melhor) Markus Endler 9 3

4 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 máximo no momento do acesso), mas que vai decaindo com o tempo arquivos que atingem a prioridade mínima são candidatos a serem substituídos (política LRU) arquivos modificados permanecem com prioridade máxima Markus Endler 10 O estado Hoarding 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 (recursivo) Markus Endler 11 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 padrão é 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 foram os arquivos usados por suas aplicações. Markus Endler 12 4

5 Hoard Walk É um procedimento que a cada 10 minutos, 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. Markus Endler 13 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 esta não anula uma entrada anterior No entanto, quando o CML ficar cheio, Venus suspende qualquer nova alteração Markus Endler 14 O estado Re-integração Após a reconexão com o AVSG, Venus: propaga todas as atualizações 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 15 5

6 O estado Re-integração Fases do processamento do log CML: todos os arquivos referenciados no log são bloqueados valida-se cada operação no log (existe espaço em disco?, não há violação de acesso?, operação causaria perda de consistência do sistema de arquivos?) o conteúdo dos arquivos referenciados no log é copiado para os servidores todos os bloqueios são liberados Markus Endler 16 O estado Re-integração 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 e 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 17 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 no servidor e no cache (exemplo: rwx bits) Conflito em Arquivos: quando Venus detecta divergências em um arquivo, procura um programa (Application Specific Resolver - ASR) para este arquivo Se existe, invoca o programa que: modifica a cópia do arquivo local (cache) e copia a versão modificada de 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 Markus Endler 18 6

7 Conectividade Fraca Define um modo de interação entre UM e rede quando o enlace sem fio apresenta alta latência, alto custo, conectividade intermitente, ou alta taxa de erros (baixa confiabilidade) Em sistemas de arquivos, as abordagens para lidar com conectividade fraca se diferenciam nos seguintes aspectos: tratamento de cache misses propagação das 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 transmitidas? escolha dos objetos (arquivos/diretórios) a serem transmitidos transmissão do arquivo completo, ou somente das diferenças? interpretação sobre a validade dos objetos cacheados Markus Endler 19 Conectividade Fraca em CODA Técnicas usadas para lidar com conexão (lenta/ruim) com a rede: 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 é função logarítmica sobre prioridade Trickle Reintegration (Reintegração pingada ) processo em background envia arquivos modificados para o AVSG (em momentos de pouca utilização) Markus Endler 20 Conectividade Fraca em CODA Técnicas (cont.) Aging somente arquivos que já estejam a 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 enviá-las para o AVGS Coêrencia do Cache é verificada por demanda (em vez de hoard walks periódicos, que fazem o download automático caso haja quebra de callbacks) antes de abrir um arquivo, verifica-se se versão local é atual Markus Endler 21 7

8 Segurança Autenticação e conexão segura Senha para os usuários Em seguida chave para a sessão Vários tipos de conexão Aberta, autenticada, só cabeçalho, total Controle de acesso (ACL) Para arquivos e BDs 22 Markus Endler CODA: Experimentos Em 1993, estudo envolvendo aprox. 25 usuários em 1 semana. Resultados: Disco local 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 poucos conflitos do tipo write-write baixo grau de compartilhamento Replicação do UNIX FileSys em 4 servidores: Desempenho do Andrew Benchmark apenas 5% pior do que sem replicação CODA apresentou fraca escalabilidade (no de usuários concorrentes) CODA mostrou que Sistemas de Arquivos são um modelo de compartilhamento de dados compatível com operação desconectada! 23 Markus Endler AFS vs CODA Markus Endler (Gaich Muramatsu) 24 8

9 Será que isto é muito antigo Conceitos do AFS aparecem no linux Kernel v2.6.1 Kernel v3.3.1 Security, File reading and writing, Automounting, Local caching (via fscache) OpenAFS Começou em 2006 Última versão: OpenAFS (04/2012) Markus Endler 25 9