Software Defined Storage SDS for OwnCloud on Debian

-
= Objetivo =
Estudo sobre storage defined storage focado em cenário de servidor de arquivos, especificamente o OwnCloud, em escala governamental.
Existia uma implantação sobre máquinas físicas rodando RHEL e gravando em GFS2 mas que não atingia resultados satisfatórios nem em desempenho nem estabilidade e disponibilidade.
Um estudo emergencial para uma nova proposta rodando sobre máquinas virtuais Debian que deveria satisfazer requisitos de dobro de desempenho foi realizado  ainda para alcançar estabilidade e disponibilidade de serviço com menores recursos.

== Perfil de uso ==
Um servidor de arquivos , e especificamente o OwnCloud, deverá ter o perfil de escritas e leituras assíncronas aleatórias paralelas simultâneas de arquivos médios.
Usaremos o perfil obtido segundo bibliografia:
Web File Server, 64KB, 95% RD vs. 5% WR, 75% RAND vs. 25% SEQ, 0,02 IOPS/active_user avg, 0,8 IOPS/active_user peak.
Teremos de modelar da melhor forma possível a distribuição de quantidade por tamanho de arquivos conforme a expressão 2 e o histograma gerado da figura 4 no documento http://www.iaeng.org/publication/WCECS2012/WCECS2012_pp1400-1404.pdf , com pico máximo em 4 KB.
(Passos de RAZÃO 4 no gráfico logarítmico)
=== Requisitos não funcionais ===
Há ainda outros requisitos a considerar, como thin provisioning, compressão, desduplicação (custo X benefício), latência, IOPS, throughput, escalabilidade vertical e horizontal, SPOF, recursos de gerenciamento, suporte técnico, garantias de integridade de informação, soluções de alta disponibilidade, file/block/object storage, disaster recovery, backup and restore, maturidade, estabilidade sob carga, bugs, recuperação de falhas (fsck, journal), recuperação de inconsistências (split-brain), compatibilidade com padrões abertos, multiplataforma, flexibilidade de configurações a diferentes cenários, compatibilidade com soluções de virtualização e containers utilizadas, compatibilidade com owncloud, licença livre, fornecedores de soluções integradas.
= Análise =
****** O protocolo NFS lançado em público como v2 em maio de 1985 é o padrão de fato para acesso compartilhado a um sistema de arquivos. Só a partir da v4 o protocolo suporta configurações em cluster distribuidos, mas ainda poucos fornecedores implementaram desta forma. Todos os fornecedores e softwares estão preparados para trabalharem com o protocolo v3 e a maioria com o v4. Alguns estão já atendendo v4.1. Mas um servidor pNFS v4.0 livre ainda é restrito ao Ganesha. As outras implementações são proprietárias em fornecedores de storages.
É um meta sistema de arquivos, fornecendo acesso compartilhado a um sistema de arquivos nativo estável. Também tem a vantagem de ser protocolo exportado (em algumas ou até todas versões) por todos os fornecedores de NAS Storage Servers. A partir de NFSv4, tem conformidade POSIX.
***** A primeira versão do GlusterFS foi lançada em público em julho de 2006. Similar ao NFS apenas neste aspecto, é um meta sistema de arquivos fornecendo acesso compartilhado, a um sistema de arquivos nativo estável. E que suporte atributos estendidos. Diferentemente do NFS, é um sistema de arquivos em cluster, podendo ser distribuido também. De arquitetura modular, sem SPOF, com metadados distribuidos, viabiliza configurações apropriadas a diferentes cenários, incluindo replicação, striping, compressão. É um sistema de arquivos em cluster compartilhado e distribuído que já alcançou massa crítica e com bons conceitos de arquitetura. Desde 2011 a Red Hat assumiu a liderança no desenvolvimento, e é suportado em outras distribuições e kernels, pois opera em user space (para o bem e para o mal). O GlusterFS mantém os arquivos inteiros em cada brick subjacente utilizado, tornando possível uma recuperação emergencial com ferramentas nativas de cada filesystem nativo em caso das alternativas de self healing normais falharem. Existe um módulo servidor NFSv3 em kernel, um cliente fuse, e um servidor Ganesha NFSv4 em user space. A RedHat também fez parcerias com a OwnCloud. O GlusterFS tem restrições de cenário de aplicabilidade conhecidas, pois têm dificuldades de desempenho em arquivos pequenos, gravações síncronas e aleatórias, típicas de ambientes transacionais. Também depende de uma veloz rede de interconexão entre os servidores para troca de metadados especialmente em caso de cache miss. Originalmente in band, pode ser contornado por designação de porta em outra rota. Por isso na tecnologia atual de redes é homologado até 64 nós. Não é restrição técnica de variáveis ou constantes do software, mas da arquitetura e do hardware. Se reduzirem o tamanho dos metadados, o algoritmo (talvez aproveitando o conceito CRUSH do Ceph), possa aumentar mais. O conceito de metadados distribuidos o torna resiliente e conceitualmente escalável, mas paga um preço no desempenho. Afortunadamente, o projeto é modular e "translators" alternativos como um (triste e limitador) centralizador de metadados, e talvez até novo algoritmo, possam ser opcionalmente implantados conforme a necessidade e riscos. Tem conformidade POSIX. É um projeto que já alcançou massa crítica de desenvolvedores e usuários e razoável estabilidade, mas ainda tem limitações de desempenho para arquivos pequenos pela arquitetura atual.
*** O Ceph é um sistema de arquivos em cluster distribuido de acesso compartilhado. Não tem o volume único e é nativo. Começou o desenvolvimento em torno de 2007 e a primeira versão lançada em 2012, pela InkTank. Em 2014 a RedHat adquiriu a InkTank e a liderança do desenvolvimento do Ceph, mantendo o código livre. O conceito de metadados out of band é atrativo mas na versão de abril de 2015 ainda mantém um servidor único de metadados, com potencial gargalo e SPOF. Futuramente, sem data, haverá uma versão estável de cluster de metadados distribuidos sem SPOF. As medidas de recuperação de falhas (fsck e split-brain) ainda são incipientes, dependendo quase completamente das medidas em tempo real de self-healing sobre os volumes redundantes. Por causa do striping nativo, quase não é viável a recuperação de falhas catastróficas examinando volumes individuais. Não é modular como o GlusterFS. Mas a arquitetura é planejada para futuramente ser muito escalável, com metadados mínimos, algoritimo CRUSH , cluster de metadados e out of band. Como já foi aceito no kernel Linux, há uma boa velocidade de desenvolvimento e em poucos anos deverá lançar os recursos que faltam e depois buscar a estabilização. As outras distribuições e fornecedores têm suporte pois está no kernel. Mas outros kernels como FreeBSD, Solaris, Illumos, ainda não o suportam. Existe um esforço de viabilizar inicialmente para o FreeBSD. Além de filesystem, pode ser configurado como block storage e object storage. Ceph tem boa conformidade POSIX, mas não total. É um projeto que atrai uma massa crítica de desenvolvedores e usuários, mas ainda não está completamente implementado e nem estabilidade para produção. Acreditamos que com a quantidade de desenvolvedores e usuários possa atingir boa estabilidade já em 2017.

O GFS2 atualmente implantado é sensível a split brain e com restrições a recursos de software (não roda find). É um sistema de arquivos compartilhado nativo no kernel, exigindo hardware especial para um correto fencing. GFSv1 começou em 1995 para Irix. Em 1998 foi portado para Linux e aberto. Em 2001 foi fechado. Em 2003 a Red Hat comprou a Sistina Software e abriu o código, e patrocinou nova versão GFS2. Tem conformidade POSIX.
* O OCFS2 é mais simples, sendo um sistema de arquivos compartilhado, mas não distribuído, nativo em kernel. Tanto OCFS2 como GFS2 não apresentam significativas vantagens sobre o NFSv4 a não ser a implantação sobre Fiber Channel ser possível. OCFS foi lançado em 2003 pela Oracle e o OCFS2 foi aceito no kernel linux em março de 2006. Tem conformidade POSIX.
OpenAttic é um gerenciador de armazenamento interessante, mas ainda não consideramos com massa crítica.
OpenVstorage é um roteador virtualizador de armazenamento para virtualização a ser acompanhado com atenção devido aos conceitos. Ainda jovem e sem massa crítica, depende de sistemas de arquivos distribuidos e em cluster subjacentes, até mesmo object storage. Aproveita conceitos já vistos no ZFS, e também nos sistemas de arquivos em cluster em que se apoia. Mas ainda tem servidor de metadados centralizado. Muito interessante e deve ser acompanhado também.
RozoFS ainda é jovem e sem massa crítica, tem um servidor de metadados (SPOF e gargalo) mas adota uma forma de striping própria, com algoritmo próprio. O que também torna  inviável na prática (prazo, custos) a recuperação de falhas catastróficas.
***** OrangeFS descende de PVFS e PVFS2 que começou em 1993 e é um sistema de arquivos compartilhado e distribuído. Versões recentes já tem metadados distribuídos. Tem compatibilidade POSIX. Quais as empresas que suportam o OrangeFS? E no Debian? É preciso acompanhar. Tendo tantos anos de projeto deixa o sistema mais estável.
Lustre é um tradicional (desde 2003) e bem ativo sistema de arquivos distribuído e em cluster.  As versões recentes têm HSM e isso precisa ser acompanhado até em termos de solução turnkey integrada. Tem conformidade POSIX .  Foi aceito no kernel, mas o userland da 3.16 estava quebrado no Debian Jessie e estavam tentando backport da 3.17 e não foi viável a tempo para lançamento oficial. Outras distros suportam dependendo da versão do kernel. A Oracle fornece suporte para algumas versões. Infelizmente tem servidor centralizado de metadados, que embora com configuração HA em standby, ainda é potencial SPOF e gargalo. Muito embora o projeto tenha focado esforços em permitir múltiplas alterações paralelas simultâneas em um mesmo diretório, aumentando desempenho de metadados. ZFS também pode ser usado nos servidores de metadados e de gerenciamento em versões recentes. A partir da versão 2.4, subárvores de diretórios podem residir em servidores de metadados diferentes, aumentando a escalabilidade. Também a necessidade de acessos ao servidor de metadados foi reduzida, fazendo ACL e localização completa apenas. É preciso avaliar o desempenho HSM.
*** OpenArchive HSM e XtreemStore HSM são projetos livres impulsionados pela Graudata, que agora tem filial no Brasil. OpenArchive HSM é desenvolvido desde 1998 e tem licença AGPL. Oferece interface NFSv3 e desempenho para archiving. Sistemas HSM normalmente se apóiam sobre bancos de dados. Em todo caso, fitas são lentas.  É preciso determinar se fornece sistemas integrados turnkey. É preciso fazer um PoC do OpenArchive HSM se formos avaliar tais soluções, pois é um projeto longevo, com versão comercial com suporte técnico oficial no Brasil, e com versão para Debian.
Castor HSM é uma solução livre voltada ao ambiente científico, grandes arquivos e sem interface POSIX, dependendo de comandos específicos. Apesar de tradicional, desde 1999, seu cenário de uso é muito diverso da nossa necessidade e desempenho e operação serão inadequados. Há alternativas mais adequadas ao nosso cenário.

** Btier como HSM é uma idéia muito atrativa. Btier faz tiering de BLOCK devices, sem compartilhamento como DRBD, mas é possível criar volumes num compartilhamento NFS !!! Se unirmos tal recurso com LTFS, poderemos ter um HSM interessante.
É preciso formatar com algum sistema de arquivos sobre ele.
Mas atenção que LTFS sem suporte de apoio de uma solução com banco de dados fica BEM lento, pois os metadados têm de ser lidos das fitas ao longo de seu comprimento. Confere isso?
É um projeto jovem, 2012, mas usuários já relatam como suficientemente estável, devido a simplicidade alavancando outros recursos de kernel. A conferir. Projeto ativo, mas ainda não parece ter massa crítica. Dependendo do cenário de aplicação, pode ser interessante. Ainda não há quem forneça soluções integradas no Brasil em abril 2015.
Quantacast FS é um projeto livre jovem de sistema de arquivos em cluster distribuído , patrocinado por uma empresa, mas que ainda não tem representante no Brasil. Tem servidor de metadados centralizado.  Possui alguns conceitos interessantes como o uso de algoritmo Reed Solomon, o mesmo das fitas LTO, para garantia de integridade de informações, pois faz striping. O algoritmo permite uma eficiência de uso do espaço físico das mídias melhor que alternativas de crc ou paridade. Falta comparar com CEPH por exemplo. Mas parece ainda sem massa crítica, embora tal empresa apoie suas operações nele.
Oracle SAM QFS HSM compartilhado iniciou desenvolvimento em 2001 sob a Sun Microsystems. Teve código liberado durante o período do OpenSolaris, o que viabilizou forks como o SGI SAM QFS HSM da Versity. Hoje são sistemas proprietários na prática. E relatos em fóruns avisam que a implantação é problemática, exigindo cliente próprio sem protocolo padrão.
GPFS LTFS HSM foi das primeiras implementações de solução LTFS pela IBM. É um sistema proprietário e exige protocolo próprio em cliente nativo.
Nexenta Edge ainda está sendo desenvolvido como um object storage sobre ZFS. Licença poderá ser proprietária.
**** OpenAFS é um tradicional, 2001, meta sistema de arquivos distribuídos e compartilhados. É um metasistema de arquivos, precisando um filesystem LOCAL subjacente. Não deve ser outro filesystem externo montado e reexportado ou pode haver problemas na ordem de carga de módulos (o que pode ser até contornado; estudar). Tem um grande foco na quantidade de clientes conectados, documentados 25 mil clientes conectados numa instalação. Usa um cache weak consistency model e file locking callback para aumentar desempenho que podem inviabilizar uso em bancos de dados, mas pode ser suficiente para um servidor de arquivos. Conceitos dele serviram de base ao NFSv4. Está incorporado nos pacotes Debian. Resumidamente, é equivalente a um pNFS v4.x , e até serviu de inspiração em alguns conceitos. Com a vantagem de já ser um projeto livre tradicional e armazenar os arquivos inteiros sobre outros sistemas de arquivos locais. Também é possível exportar via protocolo NFSv3 para clientes, embora o acesso sofra desempenho pelo uso de mais uma camada NFS/AFS Translator. Não estava completamente em conformidade POSIX em 2011, pois retornava true sempre para algumas chamadas.
** XtreemFS é um sistema de arquivos distribuído, com replicação ou striping (não ambos simultaneamente), com foco em uso em WAN. Tem servidor de metadados e outro de diretório. Tem repositório próprio para Debian. Tem ferramenta xtfs_scrub . Em desenvolvimento desde 2007. Tem conformidade POSIX. Como o cenário de uso é para redes WAN, o desempenho não é o foco principal, mas a disponibilidade resiliente a falhas inclusive de rede e a integridade de dados. Deve ser resistente a situações split-brain.
* O BeeGFS é o antigo FhFS, que tem licença grátis mas não livre. Freeware. Talvez venha a ser open source no futuro. É um meta filesystem, dependendo de outro sistema de arquivos subjacente. Tem versão para Debian. Distribui os metadados entre vários servidores de metadados out-of-band. Faz striping, aumentando desempenho. Iniciou desenvolvimento em 2005. Focado em alto desempenho. Mas roda em user space. Bastante linear na escalabilidade conforme os benchmarks listados na sua página da wikipedia.
* O MooseFS é um sistema de arquivos distribuídos, livre desde 2008, com conformidade POSIX. Tem servidor de metadados centralizado out-of-band, mas ainda um SPOF. Implementa RAID para o striping, e precisa bom espaço para replicação. Tem o recurso de lixeira nativo, configurável em número de dias a armazenar. Também faz SNAPSHOTS, mas ainda precisamos saber a eficiência e desempenho. Opera em FUSE e é multiplataforma, inclusive FreeBSD. É ativamente mantido. Tem um servidor de logs transacionais de backup, para replay em caso de um crash do master de metadados. Tem recurso nativo de TIERING.

GfarmFS está ativo, mas não tem documentação além do código fonte. Tem poucos colaboradores atuais. Não é viável apoiar operações corporativas em tal fase.
CohortFS contribui código Pnfs diretamente para Ganesha e para código pNFS ao Ceph.


== DISASTER RECOVERY ==
=== Snapshots ===
Utilizar snapshots para recuperação de desastres é muito conveniente pois é muito rápido a restauração. Mas ainda corremos o risco, pois o snapshot é armazenado nas mesmas mídias originais. Um dano físico afetaria ambas. Precisa ser usado em conjunto com outra medida de recuperação de desastres.
=== Remote tape filesystem / block device image copies ===
A utilização de cópias de imagem de sistema de arquivos ou de dispositivo de blocos em fitas é bem mais barata e segura e durável. É mais lenta que uma replicação, mas economiza energia, refrigeração e investimentos. Pode ser usada em conjunto com snapshots.
=== Replicação remota assíncrona ===
Uma replicação remota assíncrona viabilizaria uma segura proteção de rápida restauração. Mas o custo de energia, refrigeração e investimentos é maior.


== BACKUP e RESTORE ==
O backup diário deve durar menos de 24 horas. Uma abordagem diferencial tanto de imagem quanto de conteúdo pode ajudar nesse objetivo.
Se houver uma redução de atividade no fim de semana, é possível que eventuais atrasos possam ser compensados nesse período. Mas exigiria o recurso de snapshots como alimentadores.
Outra abordagem é paralelizar, e para isso dividir o problema em partes menores é necessário. Assim, poderemos executar backup e eventual restore de partes do conjunto de arquivos. Para viabilizar isso, testamos o recurso dependente do atributo jDirectory armazenado no LDAP, que pode ser usado para armazenar a informação de onde está o diretório que armazena os arquivos de cada usuário. Há de se criar uma boa regra de formação para preenchimento desse atributo. Com esse atributo, poderemos dividir usuários por instituição e até grupos menores. Sub árvores de diretórios poderão ser backupeadas e restauradas, sem afetar outras. Usaríamos pontos de montagem de armazenamentos externos sobre diretórios locais.
Com estas divisões, poderíamos gerenciar o espaço prevenindo a necessidade de sistemas de arquivos distribuídos e muito grandes, que elevariam o risco em caso de falhas e aumentariam a complexidade dos processos backup e restore.
Com divisões, poderíamos até ter diferentes desempenhos e disponibilidades de armazenamento até numa mesma instituição, viabilizando a separação dos vips.

=== Fitas, LTFS ===
Fitas LTO ainda são a melhor forma de armazenamento offline em termos de durabilidade e consistência de dados em longo prazo. E hoje temos o formato LTFS padronizado que viabiliza o intercâmbio de fitas entre fornecedores e pode até ser operado de forma similar a uma mídia de acesso aleatório removivel, como cdrom ou pendrive. Claro que o desempenho em acesso aleatório é extremamente baixo. A mídia e controladores atuais não reordenam requisições aleatórias. Se for o caso, utilizam-se de softwares de bibliotecas que incluem bancos de dados que processam tais informações.
Como fitas LTO recentes, como LTO-4,5,6 são cada vez mais rápidas para acesso seqüencial de arquivos grandes, são muito adequadas para backups de imagem de sistema de arquivos.
=== Granularidade do backup e restore ===
Acesso aleatório direto a arquivos armazenados em fitas têm muito baixo desempenho e eventuais restores granulares a arquivos seriam penalizados. Embora muito práticos, podem não ser viáveis para recuperação de desastres.
Um backup de imagem de dispositivo de blocos ou de sistema de arquivos deveria ser incremental.
Portanto, uma abordagem dupla, sendo uma de imagem de dispositivo de blocos ou de sistema de arquivos, com maior desempenho para recuperação de desastres, e outra granular com acesso direto a arquivos, para restaurações por usuário, poderia ser implantada.
As diferentes abordagens exigirão planejamento e escolha adequada de solução de armazenamento, pois a divisão em sub-árvores de diretórios poderia dificultar o backup e restore de imagem sem um isolamento adequado dos pontos de montagem.
Pode ocorrer de mesmo dividindo, seja inviável o tempo de backup e restauração granular. Neste caso seria necessário utilizar a restauração de imagem em um disco temporário para então acessar e recuperar o arquivo desejado. Por ser mais trabalhoso, recomendamos planejar e dimensionar as divisões buscando a viabilização desses tempos.


=== HSM ===
Cogitamos utilizar solução HSM como armazenamento primário, porém mesmo obtendo desempenho aceitável, ainda precisaríamos de solução de contingência.  HSM não é backup, é solução de tiering incluindo fitas ou mídias óticas para redução de custos. Uma solução de backup e uma de DR ainda é necessária.
Se for o caso, será melhor utilizar um protocolo NFS padrão para a comunicação, prevenindo o uso de clientes ou drivers específicos que exigiriam manutenção e upgrades ao longo de anos. Situação ainda pior caso seja escolhida solução proprietária.

=== Object storage para backup ===
E o consumo de energia, refrigeração e durabilidade?
Utilizar object storage para backup está sendo defendido por uma corrente de sysadmins. Há várias alternativas de object storage que desempenham bem e são muito escaláveis. Mas é preciso lembrar que object storage desempenha melhor para arquivos grandes, o que não parece ser o perfil atual de nossos usuários. Para armazenar imagens de sistemas de arquivos seriam bons. Ainda é preciso lembrar que haveria um consumo bem maior de energia e de refrigeração. Também é preciso lembrar da durabilidade da consistência de dados nas fitas LTO. Os discos e mídias têm durabilidade consistente menor que as fitas LTO.


== SUPORTE INTERNO OU EXTERNO? ==
A definição de quem fará o suporte técnico total final é importante fator para definição da escolha. Suporte técnico externo restringirá as opções entre o leque de ofertas de mercado. O suporte interno ampliará as opções.

== Integrador interno ou externo? ==
Se a integração final será feita por equipe externa, dependerá de ofertas de mercado ou chamada pública para interessados. Sendo equipe interna terá de haver qualificação. A integração e suporte também dependem da opção ser puramente de software e se apoiada ou não sobre máquinas virtuais e qual tecnologia de virtualização. Também dependerá do protocolo utilizado viabilizar ou não o completo isolamento da opção de armazenamento.
Por exemplo, a opção por NFS permite que até mesmo NAS data storage servers possam atender diretamente as necessidades, ampliando o leque de opções entre internas ou externas.




== Peculiaridades do Owncloud ==
O uso do Owncloud traz suas peculiaridades que podem ajudar.
O conceito de external storage não se demonstrou boa prática, pois apesar de permitir até uso de object storage, colocou todos os arquivos num repositório de uso comum e quase livre acesso.
Então, para obter melhor controle de acesso, teremos de utilizar o conceito de grupos. Cada empresa ou instituição seria classificada como um grupo, pelo menos. Poderíamos até criar grupos na estrutura flat, que seriam efetivamente subgrupos de um grupo pai logicamente.
'''Com a utilização do plugin de autenticação LDAP, é possível usar o atributo jDirectory para definir o diretório de armazenamento de arquivos de cada usuário individualmente.'''
'''Portanto, se for idealizado uma boa estratégia de definição desses diretórios, poderemos dividir o armazenamento em diferentes diretórios por empresas e assim poder utilizar múltiplos pontos de montagem.'''
Isso é vital para a flexibilidade entre as opções. Não seremos obrigados a colocar todos os arquivos em um único filesystem, forçando a escolha de algum filesystem muito escalável e até distribuído.


== Considerações ==
O protocolo NFS é suportado por quase todo tipo de sistema operacional. O NFSv4, tendo conformidade POSIX , deve ficar transparente a toda aplicação. Mesmo o NFSv3 é bastante suportado em muitas aplicações.
Se pudermos manter as opções suportando este protocolo, aumenta a flexibilidade de alternativas de implantação. Poderíamos delegar muitas tarefas a uma solução de data storage server que exportasse compartilhamentos NFS, como por exemplo o livre FreeNAS ou sua versão comercial suportada TrueNAS, ou o gratuito/comercial NexentaStor baseado no kernel Illumos, ou o livre Napp-It.
Com a viabilidade de definir diretório de armazenamento individualmente por usuário, poderemos agrupar usuários de uma mesma instituição em um subdiretório de outro que seria um ponto de montagem NFS. Dividiríamos o problema em partes menores e gerenciáveis. Quando o espaço exigido por uma instituição excedesse a capacidade de um data storage server poderíamos ou subdividir ainda mais ou adotar um sistema de arquivos em cluster e distribuído escalável.
A tarefa de backup e restore  dos recursos também precisa ser avaliada, assim como os recursos de verificação de integridade (fsck, scrub, verify, etc).
O fator desempenho não é tão crítico como foi na análise para servidores de email, e portanto o striping e acesso paralelo têm importâncias menores.
Devido aos custos de armazenamento, o recurso de thin provisioning e compressão têm elevada importância. Disponível em alguns data storage servers , até livres alguns baseados em ZFS, disponibilizado também via protocolo NFS de forma transparente.
A característica de ter ou não gargalos arquiteturais e SPOF é importante para a escalabilidade horizontal ao porte governamental. Portanto metadados distribuídos são importantes.
A resistência a situações de split-brain é bem importante.
Recursos de alta disponibilidade são importantes.
Os outros fatores listados nos objetivos também são considerados, com peso menor.
Devemos considerar importante a viabilidade de implantação completa em software, sem exigência de hardwares exóticos , como para fencing, e a compatibilidade com virtualizadores e contâineres, em implantação externa ou interna a eles.

= Conclusões =
'''Soluções em protocolo NFSv4 são as que atendem melhor simultaneamente o maior número dos requisitos para uso no Owncloud em 2015 com plugin LDAP'''.
A implantação de todos os clientes sobre um mesmo namespace aumentaria a complexidade e riscos, exigindo sistemas de arquivos em cluster, talvez distribuídos, replicados e até paralelos. Se pudermos manter a implantação o mais simples possível, haverá maior estabilidade de serviço. '''Com o recurso disponibilizado pelo plugin LDAP do Owncloud, o particionamento em vários pontos de montagem NFS será viável por ao menos até 2017 (estimado).'''
Quando não mais for assim, devemos reavaliar a situação do GlusterFS, Ceph, OpenAFS, OrangeFS, XtreemFS, MooseFS, BeeGFS '''nesta ordem'''.
OpenAFS é mais antigo e estável, com massa crítica e incorporado no repositório Debian, mas não tem plena compatibilidade POSIX e com limitações em pontos de montagem e complexidade de implantação. Ceph é muito imaturo ainda mas tem o mais veloz desenvolvimento entre todos. A ordem dependerá da data em que for reavaliado. Se for antes de 2017, pode ser que Ceph ainda não tenha alcançado maturidade suficiente. GlusterFS é o mais simples, flexível, com abrangentes recursos e o que mais atende simultaneamente os requisitos depois do NFSv4, que não é distribuído nem paralelo como pNFSv4. Mas com limitações importantes conforme a análise, que '''podem''' impactar na aplicação pretendida se o perfil continuar com arquivos pequenos conforme observado até agora. É a plataforma de referência da Owncloud.

Precisamos lembrar que demora anos para um sistema de arquivos alcançar estabilidade e massa crítica de desenvolvedores e usuários, para uso em criticidade de produção com SLA. A experiência mostrou que 10 anos é um prazo normal médio, podendo variar com o investimento em desenvolvimento e testes e quantidade de usuários em diversos cenários. Uma boa quantidade de usuários garante exposição a diferentes cenários de uso, expondo bugs obscuros.
'''Solução de disaster recovery, backup, restore, serão melhor técnica e economicamente implantadas com alternativa baseada em biblioteca de fitas LTO e formato LTFS, para imagem de filesystem e também para alta granularidade de arquivos em sub árvores de diretórios viáveis no prazo diário ou de SLA conforme o caso'''.  Alguns sistemas de arquivos têm requisitos complexos de backup e restore para os metadados. Soluções NFS são as mais tradicionais e consolidadas em termos de disaster recovery, backup e restore.


= Bibliografia =
== Tamanho e distribuição de quantidade por tamanho de arquivos, variação no tempo e idade ==
Distribuição por tamanho dos arquivos:
O comando abaixo executará com timeout 180s, com prioridade 19  e abortará no timeout com sinal 9.
timeout -s 9 180s nice -n 19 find . -type f -print0 | xargs -0 ls -l | \
awk '{size[int(log($5)/log(2))]++}END{for (i in size) printf("%10d %3d\n", 2^i, size[i])}' | sort -n
Exemplo de resultado possível, que pode alimentar uma planilha e gerar gráfico:
         0 1144
         1  32
         2 1168
         4 101
         8 399
        16 3025
        32 23235
        64 11550
       128 6507
       256 8548
       512 18663
      1024 29183
      2048 20472
      4096 18165
      8192 13098
     16384 13097
     32768 8055
     65536 5508
    131072 1853
    262144 1068
    524288 611
   1048576 516
   2097152 239
   4194304 148
   8388608  77
  16777216  82
  33554432  47
  67108864  22
134217728  13
268435456  10
536870912  22
1073741824  18
2147483648  14
4294967296  14
8589934592   9
17179869184   1
68719476736   1
 
Exemplo de possível teste sintético parametrizável de carga usando fio. Será necessário criar outro para simular o perfil identificado na bibliografia.
Command line :
{{{
QUEUE_DEPTH=${qd} RAMP_TIME=${warm_time} DISK=${disk} SIZE=${size} RECORD_SIZE=${record_size} RUNTIME=${run_time} \
fio --output ${your_output_file_name} --section ${your_job_name} all.fio
}}}
Fio configure file :
{{{
[global]
iodepth=${QUEUE_DEPTH}
runtime=${RUNTIME}
ioengine=libaio
direct=1
size=${SIZE}
filename=${DISK}
ramp_time=${RAMP_TIME}
[seq-read-64k]
rw=read
bs=${RECORD_SIZE}
iodepth_batch_submit=8
iodepth_batch_complete=8
[seq-write-64k]
rw=write
bs=${RECORD_SIZE}
iodepth_batch_submit=8
iodepth_batch_complete=8
[rand-write-64k]
rw=randwrite
bs=${RECORD_SIZE}
iodepth_batch_submit=1
iodepth_batch_complete=1
[rand-read-64k]
rw=randread
bs=${RECORD_SIZE}
iodepth_batch_submit=1
iodepth_batch_complete=1
[rand-write-4k]
rw=randwrite
bs=${RECORD_SIZE}
iodepth_batch_complete=1
iodepth_batch_submit=1
[rand-read-4k]
rw=randread
bs=${RECORD_SIZE}
iodepth_batch_submit=1
iodepth_batch_complete=1
[seq-read-4k]
rw=read
bs=${RECORD_SIZE}
iodepth_batch_submit=8
iodepth_batch_complete=8
[seq-write-4k]
rw=write
bs=${RECORD_SIZE}
iodepth_batch_submit=8
iodepth_batch_complete=8
}}}


== Owncloud external storage ==

== NFSv4 HA ==

== NFS performance ==
http://www.fsl.cs.stonybrook.edu/docs/nfs4perf/nfs4perf-microscope.pdf***************************************************************************


== pNFS , NFS 4.1 cluster ==
Debian 8.x Jessie já suporta NFSv4.1 por default mas parece não suportar pnfs option em exports.
invoke-rc.d nfs-kernel-server
cat /proc/fs/nfsd/versions
cat /proc/fs/nfsd/versions
http://www.spinics.net/lists/linux-nfs/msg50613.html *************************************

== OpenAttic ==

== OpenVstorage ==
== RozoFS ==


== GlusterFS ==
https://access.redhat.com/articles/88723 **************************  glusterfs i/o profile restrictions


== OrangeFS ==
http://lvee.org/en/abstracts/33 Introduction to distributed file systems. OrangeFS experience

== Lustre cluster FS HSM ==

== Ceph ==
http://tracker.ceph.com/issues/4137 fsck scrubbing ***********

== OpenArchive HSM XtreemStore FileLock ==


== Castor HSM ==

== OHSM ==

== OCFS2 ==
== GFS2 ==


== Btier ==


== Quantacast FS ==

== Oracle SAM QFS HSM ==
http://www.oracle.com/us/products/servers-storage/storage/storage-softwa... Oracle Hierarchical Storage Manager (formerly StorageTek Storage Archive Manager)


== SGI SAM QFS HSM ==




== GPFS HPSS HSM ==

== GPFS LTFS HSM ==


== Nexenta Edge ==

== ZFS as base of GlusterFS brick, as ZFS is not a cluster fs ==

== AFS Andrew File System, OpenAFS , kAFS ==

== Gfarm FS ==


== Hadoop FS ==

== MooseFS ==

== XtreemFS ==


== Object Storage ==

== ZFS ==
http://cuddletech.com/blog/pivot/entry.php?id=984 Understanding ZFS: Replication, Archive and Backup


== Outros ==
http://www.oracle.com/us/products/servers-storage/storage/tape-storage/b... Oracle StorageTek Storage Archive Manager ZFS HSM
http://www.tack.ch/unix/dmapi/ XFS DMAPI old but will be ressurrected in future kernels *****


== Backup billion files ==

== LTFS NAS, LTFS LE NAS, LTFS EE NAS ==
https://www-304.ibm.com/partnerworld/wps/servlet/download/DownloadServle...$cnt&attachmentName=automating_data_tiering_with_ibm_linear_tape_file_system.pdf&token=MTQyNzkxMzM0MTc5MA==&locale=en_ALL_ZZ

== Zimbra HSM ==
ZxPowerstore
== BeeGFS , FhGFS ==
http://moo.nac.uci.edu/~hjm/fhgfs_vs_gluster.html **** Distributed Filesystems: Fraunhofer vs Gluster

== CohortFS ==

== Tools, statistics ==
http://arstechnica.com/civis/viewtopic.php?t=71230 *******************************************************

== Owncloud alternatives ==


== Problemas Owncloud ==
https://forum.owncloud.org/viewtopic.php?f=3&t=5952 Multiple Companies on a single Owncloud Installation
https://github.com/owncloud/core/issues/7072 Synchronizing small files = very slow
https://github.com/owncloud/client/issues/331 Upload of many Files really slow
https://github.com/owncloud/core/issues/5084 PROPFIND bug prevents larger number of files per directory (and causes connection timeouts)
https://github.com/owncloud/core/issues/6937 [6.0.1] Slow sync to oC server. Delay in sending packets from oC server to NFS server
https://github.com/owncloud/client/issues/1482  Sync (with large folders) gets timeout and restarts without uploading
https://github.com/owncloud/core/issues/3118 Multiple file uploading and deleting is very slow
https://forum.owncloud.org/viewtopic.php?f=14&t=17477&p=79098#p79073  Re: Poor performance with many small files??? antivirus workaround
https://forum.owncloud.org/viewtopic.php?f=31&t=27097&start=10 Discovering VERY slow and sync Speed VERY slow
https://forum.owncloud.org/viewtopic.php?f=31&t=27840&start=10  oc8 seems to drag apache down on high client sync loads
The post_max_size integer value must be larger than upload_max_filesize.


== Owncloud tuning ==

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Tutorial Cyrus IMAP aggregator (murder) 2.3.16 sobre Debian GNU Linux 5.x Lenny

-
Este tutorial completo mostrará como montar um LABORATÓRIO de infra-estrutura de e-mail bastante escalável, para centenas de milhares de contas. O que é Cyrus IMAP (Murder) Aggregator. Cyrus IMAP Aggregator (Murder) é um sistema de alto desempenho análogo a um cluster de servidores de e-mail. Extremamente escalável (para centenas de milhares de contas), permite recursos como compartilhamento de caixas postais entre servidores backend diferentes, mover caixas postais entre servidores, e adicionar novos servidores para aumento de capacidade em diferentes níveis de serviço, se for o caso. Curiosidade: Murder é coletivo de corvo, em idioma inglês. Agradecimentos a Lucas Zinato Carraro por apresentar o Cyrus Murder Aggregator. Objetivos deste tutorial Educacionais. Não haverá tuning de recursos computacionais nem preocupações com segurança, para evitar demasiada complexidade e aumento de variáveis. Cada ambiente de hardware e software, bem como cenários e perfis de ...
Leia mais

Instalar Squid forward proxy com SSL cache (SSL bump) em Rocky Linux 8.9 para cache de pacotes na infrestrutura

-
Imagem
    Objetivos: O objetivo é acelerar a instalação de pacotes de atualização de sistema operacional e outros arquivos numa infraestrutura com várias máquinas virtuais / virtual machines. É um acesso da infraestrutura interna para a internet aberta, até os repositórios de pacotes, com conexões SSL. Por isso o nome forward proxy. Note a diferença para um reverse proxy que, por exemplo, acelera a entrega de conteúdo de um servidor web para a internet pública. Utilizaremos Squid proxy, que é naturalmente um forward proxy. O Nginx é naturalmente um reverse proxy. Somente com uso de patch consegue fazer forward proxy, com protocolo HTTP CONNECT. E não conseguimos fazer cache de conteúdo https nele, nem com certificado auto-assinado, para descriptografar, armazenar, criptografar novamente. Usaremos a ferramenta mais adequada para a necessidade, neste caso, o Squid. Geralmente, os forward proxies apenas estabelecem a conexão SSL usando HTTP CONNECT, que cria um túnel entre o cliente lo...
Leia mais

How to configure multipath for high availability and performance on Debian and CentOS for storage at IBM DS8300 SAN

-
This detailed how to guides to achieve high availability and performance on Debian and CentOS for accessing storage space at IBM DS8300 Data Storage Systems. Tested on Debian GNU/Linux 5.x Lenny 64 bits and CentOS 5.3 64 bits running on 8 cores blades, with Host Bus Adapters Qlogic and Emulex Light Pulse Fiber Channel in deployed systems at SERPRO. Observations showed that Debian Lenny had the best performance, for our app load profile and hardware at that date in 2010.     Also, there are listed a number of previously not clearly documented critical pitfalls to avoid. STUDY whole articles, hints, implications, and cited resources before planning your deployment. Every detail matters . Before start, you  must  have LUNs at IBM DS8300 storage configured for high availability and performance as explained at the article  How to configure maximum performance storage space for Debian GNU/Linux on IBM DS 8300 Data Storage Systems ....
Leia mais