Tenho lido muito sobre controladores/configurações RAID e uma coisa que aparece muito é como os controladores de hardware sem cache oferecem o mesmo desempenho que o RAID de software. É este realmente o caso?
Sempre pensei que as placas RAID de hardware ofereceriam melhor desempenho mesmo sem cache. Quer dizer, você tem hardware dedicado para executar as tarefas. Se for esse o caso, qual é o benefício de obter uma placa RAID sem cache, algo como um LSI 9341-4i que não é exatamente barato.
Além disso, se um ganho de desempenho só for possível com o cache, existe uma configuração de cache que grava no disco imediatamente, mas mantém os dados no cache para operações de leitura tornando um BBU não uma prioridade?
Resumindo: se estiver usando uma placa RAID de baixo custo (sem cache), faça um favor a si mesmo e mude para RAID por software. Se estiver usando uma placa de médio a alto nível (com BBU ou NVRAM), o hardware geralmente é (mas nem sempre! Veja abaixo) uma boa escolha.
Resposta longa: quando o poder de computação era limitado, as placas RAID de hardware tinham a vantagem significativa de descarregar o cálculo de paridade/síndrome para esquemas RAID envolvendo-as (RAID 3/4/5, RAID6, ecc).
No entanto, com o desempenho cada vez maior da CPU, essa vantagem basicamente desapareceu: até mesmo a antiga CPU do meu laptop (Core i5 M 520, geração Westmere) tem desempenho XOR de mais de 4 GB/s e desempenho da síndrome RAID-6 acima de 3 GB/s por single núcleo de execução .
A vantagem que o RAID de hardware mantém hoje é a presença de um cache DRAM protegido contra perda de energia, na forma de BBU ou NVRAM. Esse cache protegido fornece latência muito baixa para acesso de gravação aleatória (e lê esse hit) e basicamente transforma gravações aleatórias em gravações sequenciais. Um controlador RAID sem esse cache é quase inútil . Além disso, alguns controladores RAID de baixo custo não vêm apenas sem um cache, mas desativam à força o cache DRAM privado do disco, levando a um desempenho mais lento do que sem placa RAID. Um exemplo são as placas PERC H200 e H300 da DELL: elas desativam totalmente o cache privado do disco e (se o firmware mais recente não mudou isso) proíbem ativamente de reativá-lo. Faça um favor a si mesmo e não, nunca, nuncacomprar tais controladores. Embora até os controladores mais sofisticados geralmente desativem o cache privado do disco, eles pelo menos têm seu próprio cache protegido - tornando o cache privado do HDD (mas não do SSD!) um tanto redundante.
Este não é o fim, no entanto. Mesmo controladores capazes (aquele com cache BBU ou NVRAM) podem fornecer resultados inconsistentes quando usados com SSD, basicamente porque os SSDs realmente precisam de um cache privado rápido para programação/exclusão eficiente de páginas FLASH. E enquanto alguns (a maioria?) controladores permitem que você reative o cache privado do disco (por exemplo: PERC H700/710/710P), se esse cache privado for volátil, você corre o risco de perder dados em caso de perda de energia. O comportamento exato realmente depende do controlador e do firmware (por exemplo: em um DELL S6/i com cache WB de 256 MB e cache de disco habilitado , não tive perdas durante vários testes de perda de energia planejada), gerando incerteza e muita preocupação.
Os RAIDs de software de código aberto, por outro lado, são bestas muito mais controláveis - seu software não está contido em um firmware proprietário e possui padrões e comportamentos de metadados bem definidos. O RAID de software faz a suposição (correta) de que o cache DRAM privado do disco não está protegido, mas ao mesmo tempo é crítico para um desempenho aceitável - então, em vez de desativá-lo, eles usam comandos ATA FLUSH / FUA para gravar dados críticos em armazenamento estável. Como eles costumam ser executados a partir das portas SATA conectadas ao chipset SB, sua largura de banda é muito boa e o suporte ao driver é excelente.
No entanto, se usado com HDDs mecânicos, padrões de acesso de gravação aleatórios e sincronizados (por exemplo: bancos de dados, máquinas virtuais) sofrerão muito em comparação com um controlador RAID de hardware com cache WB. Por outro lado, quando usado com SSDs corporativos (ou seja: com um cache de gravação protegido contra perda de energia), o RAID de software geralmente se destaca e oferece resultados ainda melhores do que os cartões RAID de hardware. Infelizmente, os SSDs de consumo possuem apenas cache de gravação volátil, fornecendo IOPS muito baixo em cargas de trabalho de gravação sincronizada (embora muito rápido em leituras e gravações assíncronas).
Considere também que os RAIDs de software não são todos iguais. O RAID de software do Windows tem uma má reputação, desempenho sábio e até mesmo o espaço de armazenamento não parece muito diferente. O Linux MD Raid é excepcionalmente rápido e versátil, mas a pilha de E/S do Linux é composta de várias partes independentes que você precisa entender cuidadosamente para extrair o desempenho máximo. ZFS parity RAID (ZRAID) é extremamente avançado, mas, se não for configurado corretamente, pode fornecer IOPs muito ruins; mirroring+striping, por outro lado, funciona muito bem. De qualquer forma, ele precisa de um dispositivo SLOG rápido para manipulação de gravação síncrona (ZIL).
Resumindo:
Você desejará uma solução de cache com bateria ou flashback para qualquer controlador de hardware que adquirir. A maioria se arrepende de não ter feito isso .
Mas, para responder à sua pergunta, a maioria dos controladores tem taxas de cache configuráveis... portanto, 100% de cache de leitura e 0% de cache de gravação elimina a necessidade de proteção BBU. Seu desempenho de gravação será péssimo.
Não posso responder à sua pergunta sobre RAID de software porque depende. Linux MD RAID é diferente do Windows Software RAID, que é diferente de algo como ZFS . Soluções como o ZFS podem ter um desempenho melhor do que o hardware porque aproveitam os recursos de RAM e CPU do servidor.
O controlador RAID que você está de olho é barato e é basicamente um fakeraid. Depende até da sua placa-mãe para fornecer algumas funções como memória e não muitas placas-mãe têm suporte para isso, o que resulta em que você não pode carregar o driver.
Sobre HW vs SW-RAID em si. Não estou mais usando o HW-RAID, a menos que seja uma caixa com o logotipo da EMC, por exemplo. Para todo o resto, acabei de voltar para o SW-RAID muitas luas novamente por alguns motivos muito simples.
Você precisa de hardware adicional e precisa combiná-los. Você também precisa combinar o firmware e mantê-lo sincronizado. Muitos discos não funcionarão corretamente e você terá picos em sua latência de E/S sem motivo claro.
Hardware adicional é caro, então você pode usar esses US $ 1.000 adicionais (controlador decente com dois/três discos) para uma pequena solução melhor. Invista em mais discos e controladores padrão, memória ECC, CPU mais rápida. E um disco sobressalente no local, talvez se você planeja executá-lo por mais tempo do que o período de garantia ou não deseja pagar as taxas expressas pelo envio noturno.
A atualização é um problema, pois você precisa acompanhar os patches do sistema operacional e o firmware do disco e do controlador. Isso pode resultar em uma situação em que o upgrade/atualização não seja mais possível.
Em formatos de disco. Muitos fornecedores usam algum layout interno para armazenar dados vinculados a uma revisão de sua combinação de hardware e firmware. Isso pode resultar em uma situação em que uma peça de reposição impossibilita o acesso aos seus dados.
É um SPOF e um gargalo. Ter apenas um controlador atrás de apenas uma ponte PCI não oferece o desempenho e a redundância de que você realmente precisa. Com isso também não existe caminho de migração para migrar dados para outro diskset fora do alcance dos controladores.
A maioria desses pontos foi resolvida com as novas gerações de software SW-RAID ou soluções como ZFS e BtrFS. Lembre-se de que, no final, você deseja proteger seus dados e não um lixo de acesso rápido, mas redundante.
Passei o último ano (interrompendo 2014-2015) testando várias configurações paralelas do CentOS 6.6 RAID 1 (espelhado) usando 2 LSI 9300 HBA versus 2 LSI 9361-8i controladores RAID com sistemas construídos no seguinte: 2U Supermicro CSE- Chassi 826BAC4-R920LPB, uma placa-mãe ASUS Z9PE-D16, 2 processadores Intel Xeon E5-2687W v2 de oito núcleos de 3,4 GHz, Seagate ST6000NM0014 espelhado 6 TB SAS 12 Gbs, 512 GB de RAM. Observe que esta é uma configuração totalmente compatível com SAS3 (12 Gbps).
Eu vasculhei artigos escritos sobre software de ajuste e usei RAID de software Linux por mais de 10 anos. Ao executar testes básicos de E/S (dd-oflag=arquivos diretos de 5k a 100G, hdparam -t, etc.), o RAID de software parece ser favorável ao ataque de hardware. O software RAID espelhado por meio de HBAs separados. Cheguei ao ponto de fazer testes com as configurações padrão do kernel CentOS 6, kernel-lt e kernel-ml. Também tentei vários ajustes de mdadm, sistema de arquivos, subsistema de disco e sistema operacional sugeridos por uma variedade de artigos on-line escritos sobre RAID de software Linux. Apesar de ajustar, testar, ajustar e testar, ao executar em um mundo de leitura, sistema de processamento de transações (tendo um banco de dados MySQL ou Oracle), descobri que a execução de um controlador RAID de hardware resulta em um aumento de 50 vezes no desempenho.
Por muitos e muitos meses, não fiquei convencido de que o RAID de hardware poderia ser muito melhor; no entanto, após pesquisas exaustivas sobre RAID de software Linux, testes e ajustes, esses foram meus resultados.
A maioria dos escritores aqui simplesmente ignora o " buraco de gravação ". Esta é a base que permite clamar por unidades de backup de bateria de RAIDs de hardware versus ausência de tal para RAIDs de software. Bem, por exemplo, a implementação de RAID de software Linux suporta bitmaps de operações de gravação ou recálculo completo de "paridade" em caso de desligamento incorreto. O ZFS sempre se esforça para gravações completas para evitar essa inconsistência ou adiar sua nova verificação. Portanto, para resumir, o RAID de software inteligente o suficiente hoje em dia costuma ser bom o suficiente para ser usado em vez do "quem sabe o que está dentro" do chamado "RAID de hardware".
Quanto à parte do cache da questão, realmente não importa muito, porque o próprio cache de gravação do sistema operacional pode ser muito maior do que o adaptador de "hardware".
Eu trabalho isso o tempo todo. Depende muito do que você está fazendo e do nível de ataque que você está apoiando. Um controlador de SW executando um Raid 0 ou 1 para o sistema operacional e nada de especial está bem. Executar um controlador de SW com um Raid 5 em um banco de dados está causando problemas! ALGUNS controladores de hardware oferecem melhor desempenho, mas depende se ele pode armazenar em cache e o chipset do processador da placa raid. Além disso, nem todos os controladores de software são suportados por todos os sistemas operacionais. Então, às vezes, você pode ter que comprar um HW para rodar o ESXi... A menos que você use conexões sata.