[MASOCH-L] NAS

Mon Mar 24 22:42:56 BRT 2014

Rsrsrs... Deves ter rezado tantas vezes esse rosário para narrar tão bem...

Mas é verdade, DEDUP não é para qualquer cenário!
Assim como RAID 5 também não é para qualquer cenário...

Você não coloca as tabelas de Banco de Dados que exigem alto IO para rodar
em cima de RAID 5, e muito menos com DEDUP.
Nesse caso o indicado seria COMPRESSION, ou se for um cara mais conservador
como eu, não usar nenhum recurso de "economia de espaço". Nem thin
provision.

É importante lembrar que existe uma métrica para a definição de quantidade
de memória utilizada no DEDUP. Pode ser visto em:
http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html

Um recurso legal é que desde a versão(TAL) o ZFS permite colocar a
DDT(memória do DEDUP) em SSD. O que acaba tornando o projeto bem mais
acessível financeiramente.

P.S.: Como já comentei aqui na lista, um cenário em que o DEDUP fica LINDO
é para repositório de dados de Backup.
Mas é importante lembrar que, como a deduplicação é a nível de bloco, esse
recurso tem sua efetividade reduzida se for implementada alguma compactação
no backup.

Em 24 de março de 2014 19:45, Caio Zanolla <zanolla at gmail.com> escreveu:

> ZFS é fantástico e dedup é altamente viciante e quem experimenta fica
> amarradão imediatamente, afinal, dependendo do perfil de dados o cara
> consegue espremer um volume absurdo usando uma fração dos discos
> necessários.
>
> Então o administrador vai lá, testa, homologa, a solução funciona e se
> comporta bem. Na sequencia ele coloca em produção e fica feliz porque ZFS
> comanda. 1 ano depois, o storage continua funcionando perfeitamente, com
> 10x mais dados, continua rápido e responsivo, então um belo dia o hardware
> queima.
>
> O admin segue confiante, sabendo que o ZFS é sólido, afinal foi criado pela
> Oracle e tal. Vai lá substitui a caixa, recoloca os hds e continua
> tranquilo porque ele sabe que o ZFS vai enumerar os discos e disponibilizar
> o volume com pouca ou nenhuma intervenção. So que na hora H a importação do
> volume falha.
>
> Então ele vem na lista, se desespera, culpa o ZFS, diz que BSD nem é tao
> bom assim, e que isso e que aquilo. Reboota 10x, manda importar o volume e
> nada, o sistema fica parado, usando um monte de cpu e ele nao sabe o que
> está acontecendo, só sabe que não está acontecendo o que ele quer. Ele vai,
> troca memoria, troca placa mae, troca os discos de lugar, troca a
> controladora e nada. Espera 10 horas pra importar o volume, achando que só
> precisa dar tempo à maquina, e mesmo assim nao funciona.
>
> Depois de 2 dias de pesquisa, possivelmente a quebra do ZFS por acoes
> atrapalhadas e comandos sem função as 4 da manha, o cara descobre que na
> verdade a maquina está subdimensionada e que o ZFS não vai importar o
> volume com dedup a não ser que tenha Nx mais memória que tinha antes.
> Quanto? 16GB? 32GB? Ninguem sabe! hahahaha.
>
> Lembra do perfil de dados que falei antes? Pois é, storage de VM tem esse
> mesmo perfil perfeito pra dedup!
>
> Meus 2 centarro:
> ZFS comanda, mas não use dedup se seu rabo estiver na reta.
>
> Atenciosamente,
> Caio Zanolla
>
>
> 2014-03-24 16:46 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:
>
> > Outro aspecto sobre software-based-NAS é o seguinte...
> >
> > A não ser que tenhas uma CONTROLADOOOOORA, desabilite todas as features
> da
> > controladora e deixe por conta do S.O.
> >  - Mantenha o S.M.A.R.T., lógicamente...
> >  - E talvez use o buffer da controladora, mas tens que avaliar..
> >
> >
> >
> > Em 24 de março de 2014 16:41, Alexandre Pires Avilla [Dominioz Telecom] <
> > ale.avilla at dominioz.com.br> escreveu:
> >
> > > 16 gb
> > > mas acho que descobri o motivo
> > > o freebsd nao se da bem com a minha controladora SATA
> > > http://forums.freenas.org/index.php?threads/aoc-sat2-mv8-slow.11603/
> > > o povo do forum aconselhou o cara desta pergunta a comprar outra
> > > controladora :-)
> > >
> > >
> > > Atenciosamente,
> > >
> > > Alexandre Pires Avilla
> > > Gerente de Tecnologia e Redes
> > > Dominioz Serviços de Telecomunicações Ltda
> > >
> > > TargetNet - Banda Larga - www.targetnet.com.br
> > > Vale Link - Acesso Dedicado - www.valelink.com.br
> > > Dominioz - Hospedagem de sites - www.dominioz.com.br
> > >
> > > Av. Dr. Jorge Tibiriça, 105 - Centro
> > > Pindamonhangaba/SP
> > > Central de Atendimento:
> > > Pindamonhangaba [12] 3645.4975
> > > Outas Localidades 0800.940.4975
> > > Mobile: [12] 99745.9679
> > >
> > >
> > > Em 24 de março de 2014 15:34, Márcio Merlone <marcio.merlone at a1.ind.br
> > > >escreveu:
> > >
> > > > Em 23-03-2014 01:56, Alexandre Pires Avilla [Dominioz Telecom]
> > escreveu:
> > > >
> > > >  Giovani, estive testando o freenas e o openmedia,  você chegou a
> > > comparar
> > > >> a
> > > >> performance entre os dois? O openmedia é absurdamente mais rápido em
> > > >> questão de acesso aos arquivos.
> > > >>
> > > > O FreeNAS com menos de 8GB de RAM dizem que fica lento mesmo. Quanto
> de
> > > > memória ele tinha?
> > > >
> > > > --
> > > > *Marcio Merlone*
> > > >
> > > > __
> > > > masoch-l list
> > > > https://eng.registro.br/mailman/listinfo/masoch-l
> > > >
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação