 |
gildot |
 |
| |
| | RAID em Linux: software ou hardware? | | |  | Contribuído por AsHeS em 27-04-04 8:46
do departamento hw ou sw ?? | |  | |  | | |  daveiro escreve "Viva! Investiguei esta questão pela net e pela informação que encontro, dá-me a ideia que com um bom hardware (CPU, Mainboard e memória) o RAID por SW supera o por HW em termos de performance e custos. Gostava de obter feedback dos leitores do gildot e gerar uma discussão em relação a esta conclusão a que cheguei, nomeadamente experiências que tenham tido ou fontes de informação em relação a este aspecto (testes, benchmarking, etc.) Aqui está o que encontrei de relevante (com respectivos URLs fonte): " | | | | | |
" página - During the tests, the RAID5 daemon fluctated between 1% of the CPU and 7% of the CPU. For modern processers, the overhead will be negligible. (Isto num Pentium 3 a 650 MHz)
página - On a dual PPro SMP system, it has been reported that Software-RAID performance exceeds the performance of a well-known hardware-RAID board vendor by a factor of 2 to 5. (Onde está este report, não sei...)
página - yes, for 'very fast' raid it is hard to beat software raid on a pe2650 since basically you have turned the entire machine into a raid controller and there not not many dual 2Ghz/2G of ram embedded hardware raid controllers out there :-). But if your application is also heavily cpu/io dependant than you might run into contention issues with this path (e.g database servers and/or anything with high transaction rates).
página - With today's fast CPU's, software RAID performance can hold its own against hardware RAID in all but the most heavily loaded systems. The current Linux Software RAID is becoming increasingly fast, feature-rich and reliable, making many of the lower-end hardware solutions uninteresting. Expensive, high-end hardware may still offer advantages in management, reliability, dual hosting, hot-swap, etc. but are no longer required for low-end casual deployment.)
Eu vou configurar um servidor com as seguintes características base:
Tyan Mainboard S2880GNR (Dual Opteron, DDR333, 2GbE LAN, 64 bit PCI-X, 8 MB graphics, SATA) c/ 2 AMD Opteron 1.4GHz e 1GB RAM
E estou na dúvida entre usar RAID por HW com controladoras da 3ware e RAID por SW com controladoras da Promise (Ambos os casos RAID 5 com hotspare).
No meu caso a questão não é bem o dinheiro, mas sim o facto de se a controladora avariar, ser só uma questão de colocar outra em funcionamento, não necessariamente da mesma marca, uma vez que o RAID por SW em Linux cria independência das especificidades das controladoras no que toca à maneira em que os chunks de dados são gravados nos vários discos.
Mas se esta capacidade toda de processamento pode tornar o RAID por SW mais eficiente que por HW, é definitivamente uma solução a considerar!
Ainda por cima, este servidor (ao qual estarão ligadas cerca de 4 dezenas de estações de trabalho) terá pouca carga em termos de processamento, pois terá apenas partilha de ficheiros (com no máximo 10 estações de trabalho a mexer activamente em algumas centenas de MB) e um web server interno a servir de interface para um motor de indexação de PDFs (Word Indexer) e um gestor de fotos (Photo Organizer).
Obrigado por qualquer tipo de informação/conselho! :-) " < Palestra sobre segurança | "Implante de visão" à la RPG futurista > | | gildot Login | | | Referências | | | Perguntas | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Eu penso que, mas se calhar já estou desactualizado, que onde o raid por software perde para o raid por hardware é quando há algum problema e tens que reconstruir o array de discos demora um bom bocado mais de tempo.
"Para mim a tecnologia é como as tangerinas, na medida em que não consigo fazer uma analogia decente sobre nenhuma das duas neste momento" Scott Adams |
| | | | | | Mas sai mais baratinho...
Acho que se o facto limittivo é o preço, sigra por software.
Não ficas mal servido, mas tb não é a solução mais optimizada :)
"Everyone has the right to be stupid. Some just abuse the privilege" |
| | | | O preço não é limitativo. Aqui o mais importante é fiabilidade e depois a performance.
As placas da 3ware supostamente tem um MTB entre 100.000h e 1.000.000h, ou seja a primeira falha ocorre na pior das hipóteses depois de 11 anos de uso...
Se isto é mesmo assim em princípio será a escolha, mas se não for, quero ter a flexibilidade de poder usar outra controladora e continuar a usar o array de discos transparentemente.
Mas mesmo que a 3ware seja ultra fiável, se com este CPU/Mainboard/Memória, o SW RAID fica mesmo mais rápido então vale a pena.
|
| | | | Por acaso, um dos sustos que uma vez apanhei, teve a ver com uma controladora RAID compaq que se avariou e que para se recuperar o conteudo dos discos tinha que se ter uma controladora igual (ou semelhante, pelo menos assim dizia a assistência da compaq que já não tinha placas compatíveis), felizmente na altura trabalhava numa empresa que pertencia a um grupo grande, e outra empresa do grupo tinha uma controladora que nos pode emprestar para recuperar os dados :D.
Desde aí, que comecei a achar o RAID por software mais simpático e com menos uma ponta por onde falhar ;).
"Para mim a tecnologia é como as tangerinas, na medida em que não consigo fazer uma analogia decente sobre nenhuma das duas neste momento" Scott Adams |
| | | | "As placas da 3ware supostamente tem um MTB entre 100.000h e 1.000.000h, ou seja a primeira falha ocorre na pior das hipóteses depois de 11 anos de uso..."
Ai essa Estatística!...
O MTB refere-se ao comportamento estatístico do conjunto das placas, e não a uma placa em particular. A primeira falha de uma placa pode ocorrer em qq altura, na "pior das hipóteses".
|
| | | | A primeira falha de uma placa pode ocorrer em qq altura, na "pior das hipóteses". Pelas leis de Murphy, isto significa que a placa falhará de certeza...
-=[ Rui Lameiro ]=- |
| | | | Provavelmente na altura mais critica
Mindstorm |
| | | | "Provavelmente na altura mais critica"
Seguramente na altura mais crítica... :-)
|
| | | | Que vai ser na altura em que alguém remover 90% dos ficheiros, quando não houver backups operacionais :-)
Jazzy |
| | | | Backups esses que quando falharem ninguém se vai aperceber até ser tarde demais.
"Para mim a tecnologia é como as tangerinas, na medida em que não consigo fazer uma analogia decente sobre nenhuma das duas neste momento" Scott Adams |
| | | | 3ware sem dúvida alguma. Uso várias placas 3ware IDE e SATA sem quaisquer problemas. Isto sem falar da performance das mesmas.
Quanto a essa board, todas as que usei em modo raid deram problemas (ficheiros corrompidos) com o controlador Promise em vários sistemas operativos (FreeBSD, Windows 2000 e Windows 2003).
No entanto aconselho a ter sempre uma placa 3ware extra caso algo falhe...
|
| | | | | | Eu não ia usa a Promise para fazer RAID, mas sim usá-la apenas para aceder aos discos directamente (em modo JBOD), para que o Kernel faça RAID por SW logo esse problema não se põe no meu caso (penso eu de que).
|
| | | | Atenção que no caso da controladora promise que vem nas boards Abit nf7-s e an7 os problemas que causávam corrupção de ficheiros foram resolvidos com um simples update de driver da controladora, embora aconcelhe a num usar os ultimos drivers(os incluídos na bios) pois no caso de instalar windows XP dão problemas pois a instalãção crasha a meio, mas pelo contrário dão-me problemas que se fartam na instalação de Suse 9.1. Agradecia que me aconcelhassem na versão do driver a usar pois se uso o ultimo num dá pra windows, se uso o anterior num dá pra Suse, seuso o 1º fico com ficheiros corrompidos
|
| | | | Apesar de não estar familiarizado com a implementação de raid por software no linux, (uso vinum e raidframe em BSD, e com diversas limitações de implementação), sem duvida que optaria por uma solução dedicada por hardware. Uma configuração de raid-5 por software implica não só o calculo da paridade, mas também 2 operações de escrita em vez de 1 (dados e chunk de paridade), repartidas por 3 discos, e coordenadas pelo sistema operativo, o que terá sem duvida impacto na performance da máquina. Uma opção por hardware trata de todo o caching e gestão de escritas de forma transparente. A noção que o precioso cpu do servidor desempenha bem a função de cálculo de paridade é absolutamente falaciosa. Um servidor ocupado dificilmente consegue bater um i960 (usado por exemplo nas antigas mylex) em calculos de paridade e checksum. Quanto à possibilidade de falha das controladoras, o raid-5 assegura redundancia e integridade, mas não substitui um sistema de backup. Para finalizar (e não, não li os benchmarks e os artigos, estou apenas a relatar a minha experiência prática) acabei de montar um servidor FreeBSD com controlador raid-5 ATA da 3ware, e a performance é excelente. Melhor que a configuração de mirror que tenho com vinum em discos scsi 10krpm num servidor similar.
|
| | | | | | Retirado desta mailing list.
Yes, but follow this logic.
1)You are willing to devote 10% of 2Ghz xeon to software raid.
2)A $500+ controller has a 100Mhz proccessor.
Thus just from this you could guess that software raid has x2 as many clock cycles availble to it. It's even worse when you realize the 2Ghz xeon is a better proccessor in many more ways than just clock cycles.
The reasons to use that 500-1000 raid controller are due the features the controller gives you. Things like gracefull recovery from bad sectors, and SAF-TE support.
Ou seja com um duplo Opteron e havendo pouca carga de processamento, a máquina que vou configurar parece que fica com um RAID 5 muito mais potente que por HW
O maior problema que vejo é no caso de o sistema (kernel) crashar, os dados poderem ficar inválidos. Já alguém assistiu a crashs deste tipo?
|
| | | | Pois, mas tens efeito de afunilamento nos dispositivos ATA, estás sujeito às variações de carga do servidor, e em caso de operações inválidas por erros no código, o software pode invalidar completamente o filesystem. Além de que, apesar dos Mhz e da velocidade de cálculo de checksum num cpu poder ser mais elevada, o acesso ao disco é forçosamente mais lento. Repara, vai fazer 2 escritas independentes. Isso significa ocupar o barramento o dobro do tempo e ocupar o dobro da memória em buffers. Quando o raid estiver em estado crítico, vai ser mais lento também em leitura por causa da recuperação de dados. Em ATA é mesmo significativamente mais lento, por características da interface.
Outro problema q pode surgir é inconsistência nas tabelas de partição (embora só tenha visto isso acontecer em windows). Um raid por hardware comporta-se como um disco só, todas as estruturas são replicadas (inclusive a propria configuração do raid), logo será menos sujeito a esse tipo de falha.
Para finalizar, por algum motivo existem controladores raid dedicados. São caros, mas a meu ver representam sempre a melhor escolha.
E... duplo Opteron com pouca carga de processamento? Se tem pouca carga porque não usas só um cpu, ou um mais barato? Mais dinheiro sobra para o raid...
|
| | | | Tem cuidado com as placas promise em linux.
A placa S150 Tx2Plus(dois canais, raid 0,1,1+0) e detectada em linux como uma controladora scsi com 2/3 discos ( discos estes sata ), em vez de ser detectada como um sistema raid.
Nao sei se isto se aplicara a que tens em mente... mas ja ficas com este feedback ;)
Isso deve-se a nao haver drivers que a suporte direta... o driver open source que anda por ai apenas compila no kernel 2.4 .
Claro que este e um problema que vai ser resolvido... mas enquanto nao o e, estou a usar 2 destas placas raid como "reles" placas controladoras sata...
( embora ache que mal as tenha a funcionar como deve ser, estas fiquem mais lentas do que estao actualmente.... )
Em termos "raid" generalistas... aconselho-te o software raid do linux, de preferencia, o EVMS. Ja o tenho a funcionar em maquinas de producao ( raid5, 4 discos ) ... e, com o "bad block replacement", ainda nao tive de mudar um unico disco aos servidores ( ainda nao detectei nenhum bad block nestas maquinas... mas em testes com discos cravados deles, o sistema nao abortava... simplesmente alocava outro sector por software para cobrir o danificado... et voila, continua na boa ... ate acabarem os sectores disponiveis na tabela de bbrs :P )
Se te certificares que nao desligas as maquinas "a bruta" ( aka ups :) ), so mesmo devido a problemas com as controladoras/discos/cabos e que poderas vir a chatear...
Em termos de recuperacao de dados, em caso de crash... tens muitas mais possibilidades de seres tu a faze-la com raid por software do que usando uma "caixinha negra proprietaria".
( Ja consegui recuperar dados de um array raid 5 na qual 2 discos perderam a sincronia, e um destes queimou - na comparacao com os backups, apenas um ficheiro swap do vi e que estava diferente :) )
Miguel Costa
|
| | | | | | como disse já numa resposta anterior, só iria usar as promises como controladoras SATA para permitir o acesso directo aos discos :)
E que tal é a performance dessas máquinas de produção?
Qual a % de CPU usada pelo RAID deamon?
Tens termos de comparação com controladoras por HW?
Thanks pela info :)
|
| | | | As maquinas sao muito heterogeneas. Tenho desde um dual p2@350, um p3@600, um amd xp1700 e dois pentium 4 2.4 ( todos com 512mb ram, excepto o amd xp e um dos pentium 4, que tem 1GB ).
Por ordem de maquinas... 4 ide ata raid5; 3 scsi 160 raid5; 3 scsi 160 raid5; 2 sata raid0; 2 sata raid1 .
Para ser "pessimista", a maquina onde se sente mais o raid5 e o dual350 ( porque normalmente esta restrito a so usar um processador nessas tarefas, visto o outro ja ter mais que fazer ;) ).
Normalmente esta entre o 2 e os 10%, dependendo muito da carga. Como sao discos ide ata 100, consigo velocidades de leitura de 80mbyte/s, quando se le ficheiros grandes. O limite aqui e o barramento pci, que fica atafulhado ;)
Quando tenho de reconstruir o array, um cpu sobe bem aos 50% ( entre tempo gasto pelo proprio raid5d e em iowait, que , infelizmente, tambem se tem de contar :( )
A maquina amd1.7 com o raid5 scsi... como esta a receber mail, porta-se fantasticamente bem. 2% a 3%, nao o tenho visto a "comer" mais.
Quando se tem de reconstruir o dito cujo, chega aos 15%.
As maquinas com sata, raid 0 e raid 1 ... sao... rapidissimas, especialmente a raid0 ( obviamente ), que consegue ser quase 2 vezes mais rapida a ler e a escrever ( a raid1 e duas vezes mais rapida a ler, e escreve a velocidade normal... ou talvez um pouco mais lento... mas nada que se note ).
As duas maquinas sata sao as que tem as placas promise "raid"...
Comparativamente com uma solucao raid a "serio"... o sistema que "heidei" na empresa foi uma maquina pentium3/800+ , com 3 discos scsi u 160 e uma placa raid DAC960 ( chipset, nao me perguntes o resto.... ). A maquina , quando o vento era de feicao, lia a 20mbytes/s e escrevia a 6 . raid5.
Quando tive o estouro neste servidor, o disco ide que la foi colocado era quase tao rapido quanto o raid5 ( mas nao aguentava muitas leituras em simultaneo, obviamente ).
Conforme ja por ai tenho lido, o melhor mesmo e te regeres por quanto queres gastar de tempo e dinheiro no sistema.
_Supostamente_ o raid por software e seguro... mas se a informacao que la estiver dentro for importante demais, nada como teres.... backups :)
Um abraco,
Miguel Costa
|
| | | | Só para acrescentar mais um dado:
Os controladores raid adicionam mais um nivel de abstração o que normalmente é bom. Esta abstração permite que o sistema, por exemplo, nem se aperceba que um disco falhou. É tudo tratado por eventos (normalmente no /proc, mas depende do controlador de raid...).
Uma solução baseada em PATA não é a melhor solução se pretendes ter uptime (PATA não tem suporte decente para hotplug) porque provavelmente vais ter que rebootar (ou a máquina crasha mesmo) quando um dos discos queimar.
SATA, por outro lado, já tem suporte hotplug mas nem todos os controladores SATA suportam. Esta máquina onde estou neste momento tem um chipset da intel (ICH5) que basicamente é um PATA com conector SATA. Se arrancasse a ficha de um dos discos e ligasse outro disco provavelmente ia ter que rebootar para voltar a poder utilizar o interface. Outros controladores SATA suportam hotplug bastante bem (um bom recurso é a libata do Jeff Garzik, para linux).
Dito isto: a solução, em termos de fiabilidade, é um controlador raid por hardware porque isola-te destes problemas... Tens os 3ware se quiseres usar discos IDE e tens os classicos (SAC, xtreme, etc) se quiseres usar discos scsi. Se o dinheiro não é problema vai pelos scsi :-)
Falando nisso, uma empresa que está com uma solução interessante em termos de storage é a apple, com o xraid (isto é fiber, por isso se calhar não é o que pretendes), que é relativamente barato para o sistema que é, juntamente com o xserve G5... Mas também se liga a linux se aplicares um patch para o linux reconhecer os LUNs todos.
A performance, num servidor, fica em segundo lugar comparada com a fiabilidade ;-)
paz,
ratao |
| | | | Uma vez andei a compilar um kernel 2.4.x num sistema com software raid 1 SCSI (Era um p2@300).
Os benchmarks foram interessantes: com ou sem raid1 a compilacao demorava quase o mesmo.
Especulei que isto se devia provavelmente a escrita ser 2x mais lenta, mas a leitura 2x mais rapida, por hipotese.
## I should be working... |
| | | | | | talvez porque o que limite a velocidade seria o CPU e nao o disco...
se tivesses um CPU bastante mais rapido talvez visses mais o efeito, assim a compilacao apenas gasta uns 10% do tempo a ler e escrever do disco
(isto assumindo que tinhas memoria suficiente, senao, testavas era o swap, que nao esta em raid)
Higuita |
| | | | Acho que a questão é mesmo:
Tens dinheiro ou não para comprar um controlador decente de raid?
Hoje em dia existem boards que suportam ROMB, que basicamente é usar os conectores ja existentes scsi da board mas agora com uma controladora que não tem interfaces nela própria, é giro, não sei os detalhes profundos, mas funciona bem e os ulvd 320 mexem bem nela.
|
| | | | |
|
