ZFS parte 2: lições aprendidas sobre thin provisioning e hot spares para Data Storage Servers de alto desempenho
Este é o novo artigo de uma série sobre ZFS e Btrfs.
Abordaremos possíveis ganhos, dicas e erros a evitar sobre thin provisioning e uso de discos hot spare em pools ZFS para Data Storage servers de alto desempenho, com uma boa BIBLIOGRAFIA selecionada. Este artigo não é um tutorial iniciante, tampouco em modo acadêmico. É um resumo de lições aprendidas para quem trabalha ou vai adquirir / trabalhar com Data Storages. Leia a bibliografia selecionada para detalhes e tutoriais. Inclusive daprimeira parte. Esta parte é focada nos tópicos para análise e consideração no projeto.
Sparse ZVOL
Se o Volume no sistema de arquivos dentro do pool for criado como sparse, ele não pré-alocará espaço significativo no disco. Apenas alguns estruturas de controle. O dispositivo de blocos resultante declarará o espaço especificado, mas consumirá muito menos fisicamente no disco.
Apenas ocupará efetivamente quando dados forem escritos. É o thin provisioning.
O administrador de sistemas deverá acompanhar a mudança no espaço efetivo utilizado e, caso necessário, aumentar o tamanho físico do pool incluindo novos dispositivos de blocos.
ZVOL não é recurso implementado no zfs-fuse. ZVOL é disponível nas implementações em kernel, como as distribuições baseadas em kernel Illumos (OpenIndiana, Nexenta, Illumian, Omnios, etc), Solaris, OpenSolaris, FreeBSD.
Desempenho ZFS thin provisioning
O potencial de ganhos com thin provisioning é bom. A Intel administra mais de 34 Peta Bytes internamente em 2011 e obteve quase 25% de ganhos em espaço com thin provisioning.
Não existe almoço grátis. O impacto em desempenho pode alcançar 60%.
Se planeja usar thin provisioning, redimensione adequadamente seu hardware para tal impacto.
E o impacto é bastante afetado pela taxa de ocupação efetiva dos discos usados na formação dos vdev.
Quanto menor a ocupação, mais na borda externa estão os dados e menor o movimento das cabeças para lerem os setores físicos.
E no lado do software, todos sistemas de arquivos ficam mais lentos para alocar espaço quando ficam mais preenchidos. Acima de 80% é alerta total. Acima de 90% o sistema ficará muito lento e acima de 95% prepare-se para tamanha lentidão (alta latência) que levará seus sistemas em produção ao colapso em cascata.
Monitoração de espaço livre
Com thin provisioning você ficará tentado a praticar overcommit (overbooking) do seu espaço físico.
Isto troca a necessidade de planejar antecipadamente suas aplicações e o data storage por uma exigência de monitoração sofisticada e agilidade na aquisição de novos discos.
A vantagem é diminuir o desperdício antecipado.
Mas a monitoração e administração ficam complicadas com thin provisioning ainda mais quando se usamsnapshots.
As escritas de um sistema de arquivos Copy on Write, CoW, com snapshots ocupam espaço neles. A menos que snapshots sejam apagados criteriosa e regularmente.
Você terá de monitorar com freqüência suficiente o espaço real disponível com o comando "zfs --list" ou em telas de sua interface gráfica e implantar comandos de monitoração como por exemplo o plugin Nagios.
http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch04s05.html
http://www.googlux.com/nagios.plugin.zfs.usage.html
Se sua empresa não tem agilidade na compra de discos, ou use uma margem de segurança alta como 80%, planeje em conjunto com os administradores das aplicações, ou mesmo abandone a idéia de usar thin provisioning.
Imagine o efeito numa aplicação em produção se um ZVOL não conseguisse alocar espaço físico em disco. Isso enquanto o host servidor informa à aplicação que existe espaço disponível no sistema de arquivos daLUN, Logical Unint Number.
Um zfs pool se comporta MUITO mal quando fica preenchido. Você não consegue sequer apagar arquivos para liberar! Claro, é um CoW e iria escrever controles movendo para área de snapshot. Veja algumas alternativas de solução em http://www.quora.com/ZFS/What-are-the-steps-to-recover-from-a-full-ZFS-pool
Para limitar os efeitos do fator humano em ocupar todo espaço disponível, implante um método de cobrança ou centro de custos por espaço efetivo utilizado em vez de apenas espaço total disponível. Forme um custo composto dos dois fatores. Aumentará as chances do thin provisioning ficar em limites razoáveis.
O NexentaStor já tem scripts parametrizáveis rodando em cron jobs a cada hora para monitorar também o espaço disponível nos pools. Napp-It já tem cron jobs (usando auto-services) mas você ou um contratado (o próprio desenvolvedor original?) teria de criar o script de monitoração de espaço disponível do pool.
Hot spares
A HP tem dados sobre a confiabilidade dos discos rígidos para consumidores e para os enterprise.
Discos para consumidores são especificados para funcionar durante menos que 40% do prazo de garantia, que também é 33% do prazo de garantia dos discos enterprise.
Isso quer dizer alguma coisa sobre como você pode utilizar os discos para consumidores domésticos, não é?
Se você utilizar discos para consumidores durante 24x7, a probabilidade de estragarem aumentará MUITO.
Mesmo discos rígidos enterprise estragam em algum momento.
Então temos a utilidade de hot spares.
Mas existe preço tanto em dinheiro quanto em desempenho.
Um hot spare é acionado quando o ZFS identifica que um disco rígido que faz parte de um vdev está danificado. Neste momento o pool entra em modo DEGRADED e o hot spare assume a posição do disco e é iniciado um processo de reconstrução chamado RESILVERING.
Ocorre que o resilvering é extremamente exigente em IOPS. Todos os blocos de todos os discos serão lidos, os checksums verificados e as informações de paridade utilizadas para reconstruir os blocos no disco de hot spare.
Dependendo da quantidade de dados gravados (ao menos não repassa blocos ainda não gravados), o processo pode levar dias ou até semanas.
O pool continuará respondendo a comandos e requisições, porém com uma latência muito elevada, que pode ser desastrosa para as aplicações.
E existe o processo de retorno: um hot spare é SEMPRE um hot spare. Muda apenas o estado para em uso ou pronto para uso.
Você terá de substituir o disco estragado, também com os comandos apropriados, e assim o novo disco é quem receberá os dados do hot spare. Este voltará ficar em estado pronto para uso.
Não haverá indisponibilidade, mas a latência será afetada.
Quais as alternativas para evitar a alta latência?
Se usando mirror, aumentar o número de espelhos. É caro, mas a latência quase não será impactada pois o uso de cpu e ram será mínimo para copiar os dados de um mirror bom para o substituto.
Se usando RAID-Z, optar por utilizar RAID-Z2 ou até RAID-Z3. O custo aumentará um pouco mais, a latência será mais preservada, e o custo é menor que aumentar os espelhamentos.
Alternativa para baixar o custo em hot spares:
Se optar por continuar com RAID-Z1, existe ainda a opção em versões de pool recentes, de COMPARTILHAR hot spares de forma global, entre mais de um pool. Dado que os discos hot spare sejam ***IGUAIS*** ou explicitamente maiores que o maior dos discos dos pools, é possível fazer linha de comando para designar um mesmo hot spare para mais de um pool. (Um disco de 500 GB de um fabricante MUITO provavelmente não contém o mesmo número de setores utilizáveis que um disco de 500 GB de outro fabricante, e o resilvering vai falhar).
Geralmente as interfaces gráficas não permitem isso, por considerarem excesso de economia.
Você pode diminuir o risco de ficar sem hot spares suficientes configurando uma quantidade adequada para todos os pools.
Como sugestão, podes estimar 1 hot spare para cada 8 discos consumer grade e 1 hot spare para cada 20 discos enterprise.
Por exemplo, 27 discos consumer grade em 3 pools RAID-Z1 poderiam ser atendidos por 3 hot spares compartilhados entre os 3 pools. Não faria mal arredondar para 4.
Qual utilizar? Depende de seu cenário específico de uso do pool.
O perigo de discos consumer grade e RAID-Z1 é que o resilvering exige MUITO da mecânica dos discos. E se um já falhou, indica que outros estão próximos de falharem. Justamente então se inicia um processo que exige muito acionamento mecânico.
Se um segundo disco falhar durante o resilvering, o pool desaba.
Para prevenir melhor, use ao menos RAID-Z2. Se o valor e disponibilidade rápida dos dados justificar, opte por RAID-Z3. E sempre tenha backups com restores testados periodicamente.
Lembrar sempre que um pool em RAID-Z serve para aumentar o espaço utilizável, mas não aumenta o desempenho em IOPS, que continua sendo o IOPS do mais lento vdev.
Um vdev pode ser formado por 1 ou mais discos rígidos.
Repare no exemplo abaixo, com atribuição de hot spare feito por linha de comando, que o c2t10d0 é listado em DOIS pools.
zpool status
pool: nappitzfspool01
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM CAP Product
nappitzfspool01 ONLINE 0 0 0
c2t2d0 ONLINE 0 0 0 17.18 GB HARDDISK
spares
c2t10d0 AVAIL 4.29 GB HARDDISK
errors: No known data errors
pool: nappitzfspool02
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM CAP Product
nappitzfspool02 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c2t3d0 ONLINE 0 0 0 4.29 GB HARDDISK
c2t4d0 ONLINE 0 0 0 4.29 GB HARDDISK
mirror-1 ONLINE 0 0 0
c2t5d0 ONLINE 0 0 0 4.29 GB HARDDISK
c2t6d0 ONLINE 0 0 0 4.29 GB HARDDISK
logs
mirror-2 ONLINE 0 0 0
c2t8d0 ONLINE 0 0 0 4.29 GB HARDDISK
c2t9d0 ONLINE 0 0 0 4.29 GB HARDDISK
cache
c2t7d0 ONLINE 0 0 0 4.29 GB HARDDISK
spares
c2t10d0 AVAIL 4.29 GB HARDDISK
errors: No known data errors
pool: rpool1
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM CAP Product
rpool1 ONLINE 0 0 0
c2t0d0s0 ONLINE 0 0 0 34.36 GB HARDDISK
errors: No known data errors
Bibliografia
http://www.cuddletech.com/blog/pivot/entry.php?id=729
http://serverfault.com/questions/319331/when-using-thin-provisioning-with-zfs-how-do-you-make-sure-you-dont-run-out-of ******
https://blogs.oracle.com/jamesblog/entry/my_thin_provisioning_zfs_test ***
http://zfsguru.com/forum/zfsgurusupport/379.1
http://www.manpagez.com/man/8/zfs/
http://southbrain.com/south/2009/08/zfs-shares-part-ii-iscsi-nfs-a.html
http://thegreyblog.blogspot.com.br/2010/02/setting-up-solaris-comstar-and.html#!/2010/02/setting-up-solaris-comstar-and.html
http://joyeur.com/2006/08/29/thin-provisioning-in-zfs/
http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-is-better-than-btrfs ****
http://thestoragearchitect.com/2012/06/11/short-review-infortrend-eonnas-pro-200/ performance thin provisioning zvol *************************
http://mail.opensolaris.org/pipermail/zfs-discuss/2011-August/049562.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2007-February/008518.html **
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-January/035832.html **
http://thr3ads.net/zfs-discuss/2007/02/359733-ZFS-and-thin-provisioning
http://oldmangriffous.blogspot.com.br/2009/01/zfs-sparse-provisioning-with_11.html *
http://www.c0t0d0s0.org/archives/4222-Less-known-Solaris-Features-iSCSI-Part-4-Alternative-backing-stores.html *
http://vkoolaid.blogspot.com.br/2010/11/thinprovisioning-solaris-vm-with-zfs.html
http://www.filibeto.org/~aduritz/truetrue/solaris10/zfs/ZFSNinja-Slides.pdf
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-November/046010.html
http://blogs.hds.com/hu/2007/05/thin_and_wide_.html *
http://storagemojo.com/2006/08/18/lies-damn-lies-storage-performance/
http://storagemojo.com/2006/08/15/zfs-performance-versus-hardware-raid/ *
http://blog.laspina.ca/ubiquitous/running-zfs-over-iscsi-as-a-vmware-vmfs-store ****
http://constantin.glez.de/blog/2010/06/closer-look-zfs-vdevs-and-performance ***
http://blog.laspina.ca/ubiquitous/running-zfs-over-iscsi-as-a-vmware-vmfs-store
http://forums.oracle.com/forums/thread.jspa?threadID=2164466
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-April/039857.html ****
http://thestoragearchitect.com/2009/06/04/enterprise-computing-why-thin-provisioning-is-not-the-holy-grail-for-utilisation/ ****
http://lwn.net/Articles/237963/ wafl != zfs
http://www.storage-switzerland.com/Articles/Entries/2009/9/10_What_is_OpenStorage_and_ZFS.html **
http://docs.oracle.com/cd/E23824_01/html/821-1448/practice-2.html ****
http://www.googlux.com/nagios.plugin.zfs.usage.html **************
http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch04s05.html ******
http://www.quora.com/ZFS/What-are-the-steps-to-recover-from-a-full-ZFS-pool *****
http://docs.oracle.com/cd/E19963-01/html/821-1462/fsstat-1m.html#REFMAN1Mfsstat-1m ***
http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch05s06.html ***
http://forums.whirlpool.net.au/archive/1885131 ***
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/data-storage-solutions-paper.pdfresultados da intel com thin provisioning, tiered storage, deduplicação *****************
http://www.ruslansivak.com/index.cfm/2009/7/30/XenServer-Converting-Local-Storage-to-NFS-and-thereby-enabling-sparse-provisioning
hot spares
https://blogs.oracle.com/eschrock/entry/zfs_hot_spares
http://www.solarisinternals.com/wiki/index.php/ZFS_Configuration_Guide
http://docs.oracle.com/cd/E19082-01/817-2271/gcvcw/index.html global hot spares, pool sharing hot spares **************
http://docs.oracle.com/cd/E19082-01/817-2271/gcvdi/index.html resilvering
http://jmlittle.blogspot.com.br/2009/11/zfs-resilver-quirks-and-how-it-lies.html *
http://hydra.geht.net/tino/howto/zfs/blog/20080728/
http://forums.freebsd.org/showthread.php?t=25118 resilvering woes
http://forums.freebsd.org/showthread.php?t=26176 resilvering slow
http://forums.freebsd.org/archive/index.php/t-4641.html resilvering slow 24 vdevs
http://www.c0t0d0s0.org/archives/6618-Slowing-down-resilvering-of-ZFS.html
Discos rígidos: estudos confiabilidade.
http://dl.acm.org/citation.cfm?id=1288785&coll=GUIDE&dl=GUIDE&retn=1#Fulltext Understanding disk failure rates: What does an MTTF of 1,000,000 hours mean to you?
http://www.usenix.org/events/fast07/tech/schroeder/schroeder.pdf Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?
http://research.microsoft.com/apps/pubs/default.aspx?id=64599 Empirical Measurements of Disk Failure Rates and Error Rates
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01071496/c01071496.pdf disks reliability *************
Abordaremos possíveis ganhos, dicas e erros a evitar sobre thin provisioning e uso de discos hot spare em pools ZFS para Data Storage servers de alto desempenho, com uma boa BIBLIOGRAFIA selecionada. Este artigo não é um tutorial iniciante, tampouco em modo acadêmico. É um resumo de lições aprendidas para quem trabalha ou vai adquirir / trabalhar com Data Storages. Leia a bibliografia selecionada para detalhes e tutoriais. Inclusive daprimeira parte. Esta parte é focada nos tópicos para análise e consideração no projeto.
Sparse ZVOL
Se o Volume no sistema de arquivos dentro do pool for criado como sparse, ele não pré-alocará espaço significativo no disco. Apenas alguns estruturas de controle. O dispositivo de blocos resultante declarará o espaço especificado, mas consumirá muito menos fisicamente no disco.
Apenas ocupará efetivamente quando dados forem escritos. É o thin provisioning.
O administrador de sistemas deverá acompanhar a mudança no espaço efetivo utilizado e, caso necessário, aumentar o tamanho físico do pool incluindo novos dispositivos de blocos.
ZVOL não é recurso implementado no zfs-fuse. ZVOL é disponível nas implementações em kernel, como as distribuições baseadas em kernel Illumos (OpenIndiana, Nexenta, Illumian, Omnios, etc), Solaris, OpenSolaris, FreeBSD.
Desempenho ZFS thin provisioning
O potencial de ganhos com thin provisioning é bom. A Intel administra mais de 34 Peta Bytes internamente em 2011 e obteve quase 25% de ganhos em espaço com thin provisioning.
Não existe almoço grátis. O impacto em desempenho pode alcançar 60%.
Se planeja usar thin provisioning, redimensione adequadamente seu hardware para tal impacto.
E o impacto é bastante afetado pela taxa de ocupação efetiva dos discos usados na formação dos vdev.
Quanto menor a ocupação, mais na borda externa estão os dados e menor o movimento das cabeças para lerem os setores físicos.
E no lado do software, todos sistemas de arquivos ficam mais lentos para alocar espaço quando ficam mais preenchidos. Acima de 80% é alerta total. Acima de 90% o sistema ficará muito lento e acima de 95% prepare-se para tamanha lentidão (alta latência) que levará seus sistemas em produção ao colapso em cascata.
Monitoração de espaço livre
Com thin provisioning você ficará tentado a praticar overcommit (overbooking) do seu espaço físico.
Isto troca a necessidade de planejar antecipadamente suas aplicações e o data storage por uma exigência de monitoração sofisticada e agilidade na aquisição de novos discos.
A vantagem é diminuir o desperdício antecipado.
Mas a monitoração e administração ficam complicadas com thin provisioning ainda mais quando se usamsnapshots.
As escritas de um sistema de arquivos Copy on Write, CoW, com snapshots ocupam espaço neles. A menos que snapshots sejam apagados criteriosa e regularmente.
Você terá de monitorar com freqüência suficiente o espaço real disponível com o comando "zfs --list" ou em telas de sua interface gráfica e implantar comandos de monitoração como por exemplo o plugin Nagios.
http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch04s05.html
http://www.googlux.com/nagios.plugin.zfs.usage.html
Se sua empresa não tem agilidade na compra de discos, ou use uma margem de segurança alta como 80%, planeje em conjunto com os administradores das aplicações, ou mesmo abandone a idéia de usar thin provisioning.
Imagine o efeito numa aplicação em produção se um ZVOL não conseguisse alocar espaço físico em disco. Isso enquanto o host servidor informa à aplicação que existe espaço disponível no sistema de arquivos daLUN, Logical Unint Number.
Um zfs pool se comporta MUITO mal quando fica preenchido. Você não consegue sequer apagar arquivos para liberar! Claro, é um CoW e iria escrever controles movendo para área de snapshot. Veja algumas alternativas de solução em http://www.quora.com/ZFS/What-are-the-steps-to-recover-from-a-full-ZFS-pool
Para limitar os efeitos do fator humano em ocupar todo espaço disponível, implante um método de cobrança ou centro de custos por espaço efetivo utilizado em vez de apenas espaço total disponível. Forme um custo composto dos dois fatores. Aumentará as chances do thin provisioning ficar em limites razoáveis.
O NexentaStor já tem scripts parametrizáveis rodando em cron jobs a cada hora para monitorar também o espaço disponível nos pools. Napp-It já tem cron jobs (usando auto-services) mas você ou um contratado (o próprio desenvolvedor original?) teria de criar o script de monitoração de espaço disponível do pool.
Hot spares
A HP tem dados sobre a confiabilidade dos discos rígidos para consumidores e para os enterprise.
Discos para consumidores são especificados para funcionar durante menos que 40% do prazo de garantia, que também é 33% do prazo de garantia dos discos enterprise.
Isso quer dizer alguma coisa sobre como você pode utilizar os discos para consumidores domésticos, não é?
Se você utilizar discos para consumidores durante 24x7, a probabilidade de estragarem aumentará MUITO.
Mesmo discos rígidos enterprise estragam em algum momento.
Então temos a utilidade de hot spares.
Mas existe preço tanto em dinheiro quanto em desempenho.
Um hot spare é acionado quando o ZFS identifica que um disco rígido que faz parte de um vdev está danificado. Neste momento o pool entra em modo DEGRADED e o hot spare assume a posição do disco e é iniciado um processo de reconstrução chamado RESILVERING.
Ocorre que o resilvering é extremamente exigente em IOPS. Todos os blocos de todos os discos serão lidos, os checksums verificados e as informações de paridade utilizadas para reconstruir os blocos no disco de hot spare.
Dependendo da quantidade de dados gravados (ao menos não repassa blocos ainda não gravados), o processo pode levar dias ou até semanas.
O pool continuará respondendo a comandos e requisições, porém com uma latência muito elevada, que pode ser desastrosa para as aplicações.
E existe o processo de retorno: um hot spare é SEMPRE um hot spare. Muda apenas o estado para em uso ou pronto para uso.
Você terá de substituir o disco estragado, também com os comandos apropriados, e assim o novo disco é quem receberá os dados do hot spare. Este voltará ficar em estado pronto para uso.
Não haverá indisponibilidade, mas a latência será afetada.
Quais as alternativas para evitar a alta latência?
Se usando mirror, aumentar o número de espelhos. É caro, mas a latência quase não será impactada pois o uso de cpu e ram será mínimo para copiar os dados de um mirror bom para o substituto.
Se usando RAID-Z, optar por utilizar RAID-Z2 ou até RAID-Z3. O custo aumentará um pouco mais, a latência será mais preservada, e o custo é menor que aumentar os espelhamentos.
Alternativa para baixar o custo em hot spares:
Se optar por continuar com RAID-Z1, existe ainda a opção em versões de pool recentes, de COMPARTILHAR hot spares de forma global, entre mais de um pool. Dado que os discos hot spare sejam ***IGUAIS*** ou explicitamente maiores que o maior dos discos dos pools, é possível fazer linha de comando para designar um mesmo hot spare para mais de um pool. (Um disco de 500 GB de um fabricante MUITO provavelmente não contém o mesmo número de setores utilizáveis que um disco de 500 GB de outro fabricante, e o resilvering vai falhar).
Geralmente as interfaces gráficas não permitem isso, por considerarem excesso de economia.
Você pode diminuir o risco de ficar sem hot spares suficientes configurando uma quantidade adequada para todos os pools.
Como sugestão, podes estimar 1 hot spare para cada 8 discos consumer grade e 1 hot spare para cada 20 discos enterprise.
Por exemplo, 27 discos consumer grade em 3 pools RAID-Z1 poderiam ser atendidos por 3 hot spares compartilhados entre os 3 pools. Não faria mal arredondar para 4.
Qual utilizar? Depende de seu cenário específico de uso do pool.
O perigo de discos consumer grade e RAID-Z1 é que o resilvering exige MUITO da mecânica dos discos. E se um já falhou, indica que outros estão próximos de falharem. Justamente então se inicia um processo que exige muito acionamento mecânico.
Se um segundo disco falhar durante o resilvering, o pool desaba.
Para prevenir melhor, use ao menos RAID-Z2. Se o valor e disponibilidade rápida dos dados justificar, opte por RAID-Z3. E sempre tenha backups com restores testados periodicamente.
Lembrar sempre que um pool em RAID-Z serve para aumentar o espaço utilizável, mas não aumenta o desempenho em IOPS, que continua sendo o IOPS do mais lento vdev.
Um vdev pode ser formado por 1 ou mais discos rígidos.
Repare no exemplo abaixo, com atribuição de hot spare feito por linha de comando, que o c2t10d0 é listado em DOIS pools.
zpool status
pool: nappitzfspool01
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM CAP Product
nappitzfspool01 ONLINE 0 0 0
c2t2d0 ONLINE 0 0 0 17.18 GB HARDDISK
spares
c2t10d0 AVAIL 4.29 GB HARDDISK
errors: No known data errors
pool: nappitzfspool02
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM CAP Product
nappitzfspool02 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c2t3d0 ONLINE 0 0 0 4.29 GB HARDDISK
c2t4d0 ONLINE 0 0 0 4.29 GB HARDDISK
mirror-1 ONLINE 0 0 0
c2t5d0 ONLINE 0 0 0 4.29 GB HARDDISK
c2t6d0 ONLINE 0 0 0 4.29 GB HARDDISK
logs
mirror-2 ONLINE 0 0 0
c2t8d0 ONLINE 0 0 0 4.29 GB HARDDISK
c2t9d0 ONLINE 0 0 0 4.29 GB HARDDISK
cache
c2t7d0 ONLINE 0 0 0 4.29 GB HARDDISK
spares
c2t10d0 AVAIL 4.29 GB HARDDISK
errors: No known data errors
pool: rpool1
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM CAP Product
rpool1 ONLINE 0 0 0
c2t0d0s0 ONLINE 0 0 0 34.36 GB HARDDISK
errors: No known data errors
Bibliografia
http://www.cuddletech.com/blog/pivot/entry.php?id=729
http://serverfault.com/questions/319331/when-using-thin-provisioning-with-zfs-how-do-you-make-sure-you-dont-run-out-of ******
https://blogs.oracle.com/jamesblog/entry/my_thin_provisioning_zfs_test ***
http://zfsguru.com/forum/zfsgurusupport/379.1
http://www.manpagez.com/man/8/zfs/
http://southbrain.com/south/2009/08/zfs-shares-part-ii-iscsi-nfs-a.html
http://thegreyblog.blogspot.com.br/2010/02/setting-up-solaris-comstar-and.html#!/2010/02/setting-up-solaris-comstar-and.html
http://joyeur.com/2006/08/29/thin-provisioning-in-zfs/
http://rudd-o.com/linux-and-free-software/ways-in-which-zfs-is-better-than-btrfs ****
http://thestoragearchitect.com/2012/06/11/short-review-infortrend-eonnas-pro-200/ performance thin provisioning zvol *************************
http://mail.opensolaris.org/pipermail/zfs-discuss/2011-August/049562.html
http://mail.opensolaris.org/pipermail/zfs-discuss/2007-February/008518.html **
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-January/035832.html **
http://thr3ads.net/zfs-discuss/2007/02/359733-ZFS-and-thin-provisioning
http://oldmangriffous.blogspot.com.br/2009/01/zfs-sparse-provisioning-with_11.html *
http://www.c0t0d0s0.org/archives/4222-Less-known-Solaris-Features-iSCSI-Part-4-Alternative-backing-stores.html *
http://vkoolaid.blogspot.com.br/2010/11/thinprovisioning-solaris-vm-with-zfs.html
http://www.filibeto.org/~aduritz/truetrue/solaris10/zfs/ZFSNinja-Slides.pdf
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-November/046010.html
http://blogs.hds.com/hu/2007/05/thin_and_wide_.html *
http://storagemojo.com/2006/08/18/lies-damn-lies-storage-performance/
http://storagemojo.com/2006/08/15/zfs-performance-versus-hardware-raid/ *
http://blog.laspina.ca/ubiquitous/running-zfs-over-iscsi-as-a-vmware-vmfs-store ****
http://constantin.glez.de/blog/2010/06/closer-look-zfs-vdevs-and-performance ***
http://blog.laspina.ca/ubiquitous/running-zfs-over-iscsi-as-a-vmware-vmfs-store
http://forums.oracle.com/forums/thread.jspa?threadID=2164466
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-April/039857.html ****
http://thestoragearchitect.com/2009/06/04/enterprise-computing-why-thin-provisioning-is-not-the-holy-grail-for-utilisation/ ****
http://lwn.net/Articles/237963/ wafl != zfs
http://www.storage-switzerland.com/Articles/Entries/2009/9/10_What_is_OpenStorage_and_ZFS.html **
http://docs.oracle.com/cd/E23824_01/html/821-1448/practice-2.html ****
http://www.googlux.com/nagios.plugin.zfs.usage.html **************
http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch04s05.html ******
http://www.quora.com/ZFS/What-are-the-steps-to-recover-from-a-full-ZFS-pool *****
http://docs.oracle.com/cd/E19963-01/html/821-1462/fsstat-1m.html#REFMAN1Mfsstat-1m ***
http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch05s06.html ***
http://forums.whirlpool.net.au/archive/1885131 ***
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/data-storage-solutions-paper.pdfresultados da intel com thin provisioning, tiered storage, deduplicação *****************
http://www.ruslansivak.com/index.cfm/2009/7/30/XenServer-Converting-Local-Storage-to-NFS-and-thereby-enabling-sparse-provisioning
hot spares
https://blogs.oracle.com/eschrock/entry/zfs_hot_spares
http://www.solarisinternals.com/wiki/index.php/ZFS_Configuration_Guide
http://docs.oracle.com/cd/E19082-01/817-2271/gcvcw/index.html global hot spares, pool sharing hot spares **************
http://docs.oracle.com/cd/E19082-01/817-2271/gcvdi/index.html resilvering
http://jmlittle.blogspot.com.br/2009/11/zfs-resilver-quirks-and-how-it-lies.html *
http://hydra.geht.net/tino/howto/zfs/blog/20080728/
http://forums.freebsd.org/showthread.php?t=25118 resilvering woes
http://forums.freebsd.org/showthread.php?t=26176 resilvering slow
http://forums.freebsd.org/archive/index.php/t-4641.html resilvering slow 24 vdevs
http://www.c0t0d0s0.org/archives/6618-Slowing-down-resilvering-of-ZFS.html
Discos rígidos: estudos confiabilidade.
http://dl.acm.org/citation.cfm?id=1288785&coll=GUIDE&dl=GUIDE&retn=1#Fulltext Understanding disk failure rates: What does an MTTF of 1,000,000 hours mean to you?
http://www.usenix.org/events/fast07/tech/schroeder/schroeder.pdf Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?
http://research.microsoft.com/apps/pubs/default.aspx?id=64599 Empirical Measurements of Disk Failure Rates and Error Rates
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01071496/c01071496.pdf disks reliability *************
Comentários
Postar um comentário