Introdução

Por conta de sua arquitetura, dCache possui uma flexibilidade incomparável. Assim, a primeira parte deste artigo descreve as capacidades do dCache através de pequenos cenários. No final existe um pequeno sumário com estas capacidades.

Para começar, podemos pensar em cenários de um storage distribuido geográficamente, ou localmente. Ambos são comtemplados em todas as feauteres que se espera de storages nestes cenários. De fato pode-se ter os dois ao mesmo tempo,  com métodos de acesso dos mais variádos, que vão so GridFTP à uma simples montagem nfs.

Um uso mais inteligente do hardware é possível com dCache com a devida configuracão de “réplica” no cenário em que o número de arquivos que realmente são imprecindívels é lfutuante. Por exemplos, em vez de se usar raid5 em todo o storage, pode-se apenas marcar os arquivos ou pastas que se quer ter redundantes. Pode-se marcar apenas dados de usuários, ou de pesquisas em andamentos por exemplo. Em casos em que grandes quantidades de dados de colaborações são dispensáveis, isso pode economizar muito espaço, utilizando raid0 e replicando apenas os dados de interesse. Se houver o desejo de limitar o espaço utilizado com determinadas réplicas, pode-se ainda apenas utilizar alguns pools com “réplica” ativados, limitando assim o uso do storage para esse fim.

Armazenar pools pagos por grupos distintos numa mesma instância dCache é relativamente comum, e pode aumentar muito a disponibilidade e capacidade do storage e ao mesmo tempo assegurar o uso do hardware comprado por um grupo específico para membros deste grupo. Com dCache você pode dizer que dados podem ou não ficar num determinado pool, por exemplo, apenas dados do grupo que comprou o hardware podem ser alojados neste hardware. No caso de um storage geográficamente distribuído, dados utilizados por usuários fisicamente próximos ao pool podem ter prioridade sobre os outros arquivo. Pode-se ainda configurar prioridades entre os usuários deste grupo. Estas prioridades contemplam tanto localização na fila de acesso aos arquivos como localização dos arquivos em um determinado pool, ou seja, um usuário com mais prioridade que outro vai acessar os dados do seu pool com mais rapidez do que o segundo usuário no caso de concorrência, e se houver espaço apenas para os dados do primeiro usuário, os dados do segundo seguirão para um pool mais distante ( se não houver mais pools na mesma rede) que possa aceitar os dados deste usuário.

Estas restrições podem ser totalmente restritivas ou parcialmente restritivas, ambas com suas vantagens e desvantagens. Uma restrição total significa que um pool apenas aceita determinados arquivos de um usuário, grupo, domínio ou ip de onde vem o dado, etc. Outro exemplo de restrição total é a negação destes critérios, ou seja, o pool não aceita apenas dados de um determinado usuário, grupo ou ip. Uma restrição parcial significa que um pool dá prioridade a dados de um usuário, grupo, etc, mas continua aceitando outros dados se houver espaço ou conectividade desponíveis.

Mesmo em casos restrições totais, um pool pode armazenar temporariamente um arquivo que normalmente não faria. Isso porque dCache é projetado para proporcionar o mair trougthput possível. Assim, se o pool de um usuário que tem prioridade está muito ocupado, o dcache faz o cálculo do custo da transferência  para o cache de um outro pool disponível, e se o tempo for inferior ao de espera do usuário na fila do pool ocupado para obter os recursos, então o dCache faz a cópia para o cache do pool disponível, e com a liberação dos recursos no pool ocupado, ele procede a cópia do cache para o pool em que o usuário tem preferência. Para o usuário isso é transparente. Para ele o arquivo foi de fato copiado para o lugar que ele designou no pool onde tem preferência no ato da cópia. Não faz diferença se o pool mais disponível é um pool com restrições totais, ou seja, se o usuário que está tentando fazer a cópia não tem permissão de escrever no pool que está livre, pois a cópia vai para um cache e ficará ali temporariamente. Asim, quanto mais pools você agregar no seu storage, maior vai ser a sua capacidade de atendimento de usuários, mesmo que todos tenham restrições totais. De fato o dCache tenta distribuir o load por todo o storage. Ele procura por "hotspots", arquivos que são muito utilizados por usuários, e automaticamente faz novas cópias destes arquivos no caches de vários pools, para aumentar a sua disponibilidade. 

Uma utilização mais inteligente de hardware não se limita só ao espaço. Pode-se selecionar pools específicos de entrada e saída de dados vindos de um determinado usuário, domínio ou mesmo ip. Isso é muito importante, por exemplo, quando se quer manter disponibilidade do storage para seus usuários e ao mesmo tempo sustentar grandes transferências de dados do LHC. Assim, pode-se selecionar apenas alguns pool que podem receber arquivos de entrada e saída vindos do LHC. Mais ainda, se um usuário solicitou a cópia de entrada de um arquivo qualquer, e o pool do seu grupo está ocupado, pois também está selecionado para aceitar grandes transferências de um experimento específico do LHC, outro pool irá atender a solicitação deste usuário, armazenando temporariamente este aquivo. Assim que os recurso do pool pertencente ao grupo do usuário forem liberados, este arquivo será automaticamente copiado para ele.

Pode-se ter pools destinados apenas à desafogar o tráfego ou utilização de espaço em situações críticas. Estes “fall back” pools aceitam cópias para o seu cache no caso de todos os pools terem sua rede ou discos criticamente ocupados. Eles também são utilizados para compensar a possível queda ou inacessibilidade de um pool, possibilidade que merece atenção em storages geograficamente distribuídos

O dCache também se conecta de forma transparente a dispositivos de fita (HSM). O pool que o HSM está conectado pode conter discos e ser configurado para receber dados como os outros pools, ou pode ser apenas uma máquina interface para o HSM. Neste caso ele será configurado para receber dados que estão marcados para serem armazenados em fita. Os dados que serão armazenados em fita pode ser marcados para tal diretamente por algum usuário, ou por alguma política de armazenagem, por exemplo, baseada no tempo em que os arquivo residem nos pools de disco sem serem utilizados.

A disponibilidade de recursos distribuídos geograficamente para usuários também distantes geograficamente, é acessível por uma grande variedade de protocolos, mas simplicidade do serviço nfs que pode ser exportado pelo dcache torna para usuários locais o acesso a estes recurso uma experiência bastante confortável.

Além de toda a sua flexibilidade, o suporte dado pelo time de desenvolvimento do dCache, além do fornecido pela comunidade que usa o dCache, é um fator que deve ser decisivo na escolha de uma solução de storage distribuído para grandes e médios sites.

Possuir úm único serviço no qual todos os os outros são agregados torna o dCache admin um single point of failure. Apesar do dCache não contemplar redundância para o dcache admin e tão pouco para o name service em sua arquitetura, não é difícil de se implementar alguma ferramenta externa para se promover redundância a estes serviços, especialmente em se tratando do name service.

A concentração de arquivos específicos em pools específicos diminui a tolerância a downtime dos pools.

Vantagens do dCache

• Grande variedade de protocolos nativos suportados: gridftp, gsiftp, (gsi)dCap, xRoot, SRM e NFS 2/3/4.1.
• Permite balanceamento de carga entre os pools e servidores gridftp.
• Possibilidade de adicionar réplica de dados que exijam redundância ou que sejam acessados simultâneamente por vários clientes, tornando o dado acessível em mais de um pool.
• Mecanismo de administração por linha de comando (admin interface).
• Conexão transparente com unidades de fita, atuando como simples pools.
• Pode utilizar diferentes esquemas de autorização de usuários ( dcache.kpw , gums, voms, gridmapfile.
• Grande número de sites que fazem debug e deployment: 40 tiers II e 9 tiers I (CMS+Atlas+NorduGrid).
• Nenhuma alteração no kernel é necessária para implementação de seu sistema de arquivos.
• Cáculo do custo de transferências.
• Detecção de hotspots.
• FallBack pools.

Desvantagens do dCache

• Não é um sistema 100% unix like como desejado.
• Várias camadas de processos java, consumindo grande quantidade de memória.
• Complexidade de administração e configuração do sistema.
• Não faz uso de um database residente na memória como o BerkeleyDB no caso do Bestman, o que diminui sua eficiência.
• Não permite o uso do file protocol dentro de programas de análise, o que é permitido por sistemas de arquivos distribuídos como GPFS ou Lustre.
• Não contempla redundância do dcache admin, sendo este um Single point of Failure, necessitando de mecanismos externo para corrigir o problema.