Hardware de servidores
De uma forma geral, qualquer PC pode ser usado com um servidor, basta instalar os softwares apropriados. Para tarefas leves, até mesmo máquinas antigas podem prestar bons serviços. Na época em que o ADSL e outras opções de banda larga começaram a se popularizar, muitos passaram a usar micros 486 e Pentium para compartilharem a conexão, usando o Coyote e outras distribuições minimalistas. Alguns deles ainda continuam funcionando até os dias de hoje, resistindo à passagem do tempo.
Entretanto, quando falamos de servidores de hospedagem e servidores usados em grandes empresas o cenário é um pouco diferente. Além de rodarem serviços e aplicativos muito mais pesados, atendendo a centenas de usuários simultâneos, estes servidores realizam tarefas essenciais, de forma que qualquer interrupção em suas atividades pode representar um grande prejuízo, ao contrário de um desktop, onde o usuário pode simplesmente reiniciar depois de uma tela azul, como se nada tivesse acontecido.
Um bom servidor deve ser capaz de funcionar por anos a fio, com pouca ou nenhuma manutenção. Além de ser otimizado para um conjunto específico de tarefas, ele precisa ser muito mais estável e confiável do que um desktop típico, o que leva a diferenças nos componentes usados. Vamos então a um resumo da ópera.
A função de um servidor é disponibilizar serviços (HTTP, FTP, DNS, e-mail, bancos de dados e muitos outros) para um grande número de usuários simultaneamente. De acordo com os serviços usados, determinados componentes são mais importantes do que outros.
Um servidor de bancos de dados, por exemplo, depende basicamente do desempenho de acesso a disco em operações de acesso aleatório (um grande volume de pequenas leituras, com setores espalhados por diversos pontos dos discos), o que torna necessário utilizar vários HDs em RAID (em geral é utilizado RAID 5 ou 6) e uma grande quantidade de memória RAM, usada para cache de disco.
É essencial que os HDs ofereçam suporte a NCQ (o que permite que o HD altere a sequência das leituras, de forma que elas sejam feitas da forma mais eficiente, levando em consideração a disposição dos dados nos discos magnéticos), o que limita as escolhas possíveis. Antigamente, os HDs SCSI eram norma, pois os HDs IDE não ofereciam suporte a NCQ, o que fazia com que o desempenho fosse ridículo quando eram feitas muitas requisições simultâneas. Mais recentemente, os HDs SATA passaram a oferecer suporte a NCQ, o que fez com que eles passassem a substituir os caros HDs SCSI em cada vez mais aplicações, principalmente com a introdução de modelos de 10.000 e 15.000 RPM.
HD sem NCQ (à esquerda) e com NCQ
Por outro lado, um servidor destinado a rodar aplicativos, como um servidor de acesso remoto por exemplo, precisa predominantemente de processamento e memória. O desempenho do HD não é tão importante (pois os aplicativos usados quase sempre já estarão carregados na memória ou no cache de disco), mas um processador com vários núcleos e muito cache L2 é essencial para rodar o brutal número de processos simultâneos. Antigamente, era comum o uso de placas com suporte a dois ou quatro processadores, mas com o lançamento dos processadores dual-core e quad-core elas se tornaram menos comuns.
Além da questão do desempenho, o servidor precisa ser muito confiável, o que leva ao uso de componentes redundantes. Por exemplo, a maior parte das falhas de hardware são causados por problemas nos HDs ou nas fontes de alimentação. É muito difícil manter um servidor funcionando continuamente por 10 anos (por exemplo) se a vida útil média da fonte é de 3 anos e a do HD é de 4 anos, por exemplo. Não é possível fazer o HD trabalhar continuamente por 10 anos na base do decreto, mas é possível usar uma controladora RAID que ofereça suporte a hot-swap e usar dois HDs em RAID 1, por exemplo. Dessa forma, o servidor pode continuar funcionando depois da falha em um dos HDs e a substituição pode ser feita a quente, com ele funcionando. O mesmo pode ser feito com a fonte de alimentação, com o uso de uma fonte redundante, onde temos duas fontes independentes e a segunda é ativada automaticamente em caso de problemas com a primeira.
Outro ponto em que os servidores se diferenciam dos desktops é nos barramentos usados. Enquanto os desktops usavam apenas slots PCI e AGP, os servidores utilizavam slots PCI de 64 bits e slots PCI-X, que apesar da maior complexidade e custo, ofereceriam taxas de transferência maiores, necessárias para acomodar controladoras Ultra320 SCSI e placas de rede Gigabit Ethernet. O PCI-X é uma versão atualizada do padrão PCI, que opera a 133 MHz, com transferências de 64 bits, o que resulta em uma taxa de transferência teórica de 1.06 GB/s, contra os 533 MB/s do PCI de 64 bits (que opera a 66 MHz) e 133 MB/s do PCI tradicional (32 bits a 33 MHz).
O cenário mudou com o lançamento do PCI Express, que oferece taxas de transferências mais altas, mas apesar disso o PCI-X ainda continuará sendo usado por algum tempo, já que os servidores possuem uma vida útil, muito maior, o que faz com que a adoção de novas tecnologias seja mais lenta.
Controladora SCSI sendo encaixada em um slot PCI-X
Como pode ver, os servidores evoluíram de forma diferente, mas a partir de um certo ponto, passaram a utilizar componentes similares aos dos micros desktop. Um servidor típico do final da década de 90 utilizaria dois processadores em SMP, HDs SCSI e uma placa Gigabit Ethernet espetada em um slot PCI de 64 bits, enquanto um servidor típico atual utilizaria um processador dual-core, HDs SATA e uma placa Gigabit onboard, configuração muito mais similar à de um desktop típico.
Esta mudança é causada por um fator muito simples: o custo. Enquanto os componentes usados em desktop eram inadequados para uso em servidores (HDs IDE, placas-mãe com slots PCI de 32 bits, etc.) era necessário recorrer a tecnologias mais caras (como no caso do PCI-X). Entretanto, conforme os componentes foram evoluindo, eles passaram a ser “bons o bastante” mesmo para os servidores, o que levou a uma grande economia de custos. Se você precisa de 4 núcleos de processamento no seu servidor, faz muito mais sentido usar um Core 2 Quad do que usar uma placa-mãe com 4 processadores separados.
Entretanto, os componentes internos não são o único fator que diferenciam os servidores dos desktops. Temos ainda a questão da redundância e do formato.
Redundância e RAID
Redundância significa ter componentes “de reserva”, a postos para substituir o principal caso ele falhe por qualquer motivo. Existem fontes redundantes, arrays de discos redundantes e até mesmo servidores redundantes, onde temos dois servidores completos, sincronizados em tempo real, onde o segundo servidor monitora o primeiro e assume suas funções em caso de problemas.
As fontes redundantes são chamadas de RPS (Redundant Power Supply) e se baseiam no uso de módulos substituíveis. Para servidores menores, é mais comum o uso de fontes 1×1, onde temos dois módulos independentes e um circuito central, que monitora as tensões ativa o segundo módulo em caso de problemas com o primeiro. Para servidores que precisam de mais do que 350 ou 400 watts de energia é comum o uso de fontes 2×1, onde são usados três módulos, onde dois deles fornecem energia ao servidor (o que permite somar as capacidades) e o terceiro módulo fica de reserva caso qualquer um dos dois falhe:
Naturalmente, fontes redundantes são consideravelmente mais caras, não apenas por que os circuitos são todos duplicados, mas também por que elas precisam ser muito mais compactas do que uma fonte tradicional, já que temos essencialmente duas ou três fontes no espaço de uma.
Na maioria dos casos, os módulos podem ser substituídos a quente (hot-swap), sem necessidade de desligar o servidor. Um alarme sonoro ou visual avisa do problema, permitindo que o administrador substitua o módulo defeituoso assim que possível.
No caso dos discos rígidos, temos os diferentes modos de operação do RAID, que permitem adicionar redundância, aumentar o desempenho, ou ambas as coisas combinadas.
De acordo com o número de HDs disponíveis e o recursos oferecidos pelo sistema operacional usado, os modos RAID disponíveis são:
RAID 0 (Striping): No RAID 0 todos os HDs passam a ser acessados como se fossem um único drive. Ao serem gravados, os arquivos são fragmentados nos vários discos, permitindo que os fragmentos possam ser lidos e gravados simultaneamente, com cada HD realizando parte do trabalho. Isso permite melhorar brutalmente a taxa de leitura e de gravação e continuar usando 100% do espaço disponível nos HDs. O problema é que no RAID 0 não existe redundância. Os HDs armazenam fragmentos de arquivos, e não arquivos completos. Sem um dos HDs, a controladora não tem como reconstruir os arquivos e tudo é perdido. Isso faz com que o modo RAID 0 seja raramente usado em servidores.
RAID 1 (Mirroring): No RAID 1 são usados dois HDs (ou qualquer outro número par). O primeiro HD armazena dados e o segundo armazena um cópia exata do primeiro, atualizada em tempo real. Se o primeiro HD falha, a controladora automaticamente chaveia para o segundo HD, permitindo que o sistema continue funcionando. Em servidores é comum o uso de HDs com suporte a hot-swap, o que permite que o HD defeituoso seja substituído a quente, com o servidor ligado. A desvantagem em usar RAID 0 é que metade do espaço de armazenamento é sacrificado.
RAID 10 (Mirror/Strip): Este modo combina os modos 0 e 1 e pode ser usado com a partir de 4 HDs (ou outro número par). Metade dos HDs são usados em modo striping (RAID 0), enquanto a segunda metade armazena uma cópia dos dados dos primeiros, oferecendo redundância.
RAID 5: Este é o modo mais utilizado em servidores com um grande número de HDs. O RAID 5 usa um sistema de paridade para manter a integridade dos dados. Os arquivos são divididos em fragmentos e, para cada grupo de fragmentos, é gerado um fragmento adicional, contendo códigos de paridade. Os códigos de correção são espalhados entre os discos. Dessa forma, é possível gravar dados simultaneamente em todos os HDs, melhorando o desempenho.
O RAID 5 pode ser usado com a partir de 3 discos. Independentemente da quantidade de discos usados, sempre temos sacrificado o espaço equivalente a um deles. Em um NAS com 4 HDs de 1 TB, por exemplo, você ficaria com 3 TB de espaço disponível, em um servidor com 10 HDs de 1 TB, você ficaria com 9 TB disponíveis e assim por diante. Os dados continuam seguros caso qualquer um dos HDs usados falhe, mas se um segundo HD falhar antes que o primeiro seja substituído (ou antes que a controladora tenha tempo de regravar os dados), todos os dados são perdidos. Você pode pensar no RAID 5 como um RAID 0 com uma camada de redundância.
RAID 6: O RAID 6 dobra o número de bits de paridade, eliminando o ponto fraco do RAID 5, que é a perda de todos os dados caso um segundo HD falhe. No RAID 6, a integridade dos dados é mantida caso dois HDs falhem simultaneamente, o que reduz brutalmente as possibilidades matemáticas de perda de dados.
A percentagem de espaço sacrificado decai conforme são acrescentados mais discos, de forma que o uso do RAID 6 vai tornado-se progressivamente mais atrativo. No caso de um grande servidor, com 20 HDs, por exemplo, seria sacrificado o espaço equivalente a apenas dois discos, ou seja, apenas 10% do espaço total. O maior problema é que o RAID 6 exige o uso de algoritmos muito mais complexos por parte da controladora, de forma que ele não é suportado por todos os dispositivos.
JBOD: No JBOD (Just a Bunch Of Disks) os HDs disponíveis são simplesmente concatenados e passam a ser vistos pelo sistema como um único disco, com a capacidade de todos somada. Os arquivos são simplesmente espalhados pelos discos, com cada um armazenando parte dos arquivos (nesse caso arquivos completos, e não fragmentos como no caso do RAID 0). No JBOD não existe qualquer ganho de desempenho, nem de confiabilidade, ele é apenas uma forma simples de juntar vários HDs de forma a criar uma única unidade de armazenamento. Ele não é uma boa opção para armazenamento de dados importantes, mas pode ser usado para tarefas secundárias, como no caso de servidores de backup.
Existem três categorias de RAID: RAID via hardware, RAID via software e fake-RAID.
No RAID via hardware é utilizada uma controladora dedicada, que realiza todas as funções. Este modo é o ideal tanto do ponto de vista do desempenho quanto do ponto de vista da compatibilidade e confiabilidade, já que a própria controladora executa todas as funções necessárias, de forma independente. A única desvantagem é o custo da controladora, já que uma boa controladora, destinada a uso em servidores custa a partir de US$ 300.
O RAID via software é executado pelo próprio sistema operacional, sem necessidade de nenhum hardware adicional. É possível criar arrays RAID via software tanto no Linux quanto no Windows 2000, XP, 2003 Server e Vista, utilizando HDs ligados às próprias interfaces SATA da placa-mãe.
O fake-RAID é o modo utilizado pela maioria das controladoras RAID onboard, sobretudo nos micros desktop. Nele é utilizada uma combinação de funções adicionais no BIOS da placa e um driver que roda pelo sistema operacional. No final, tudo é processado via software, de forma que não existe ganho de desempenho em relação a utilizar RAID via software. Apenas a configuração é simplificada.
O procedimento de troca dos HDs defeituosos varia de acordo com os recursos oferecidos pela controladora. Ao utilizar RAID via software ou uma controladora fake-RAID, o processo de substituição do HD é inteiramente manual. Você você desligar o servidor, substituir o HD, ligar novamente o servidor, acessar a interface de gerenciamento e recriar o array, processo no qual a controladora reconstrói os dados usando os bits de paridade (no caso do RAID 5) ou copia os dados armazenados no segundo HD (no caso do RAID 0). Ou seja, os dados são preservados, mas é necessário desativar o servidor temporariamente.
Para permitir que o servidor continue funcionando continuamente, é necessário usar uma controladora dedicada, que ofereça suporte a hot-swap e seja capaz de reconstruir o array automaticamente após a substituição do HD defeituoso (recurso chamado de “automatic array rebuilding”), além de um gabinete que ofereça baias removíveis para os HDs:
As três coisas somadas permitem que os HDs sejam substituídos rapidamente, sem desligar o servidor e sem interrupção no serviço. Outro recurso desejado é o “hot drive sparing”, que permite utilizar um drive extra (hot-spare) que é usado automaticamente em caso de falha de qualquer um dos drives do array, minimizando a possibilidade de perda de dados.
Clusters de alta disponibilidade
Em vez de montar um único servidor com componentes redundantes, existe também a opção de usar um cluster de alta disponibilidade (chamados de “high-availability clusters” ou “failover clusters”), onde são usados dois servidores completos, onde a única função do segundo servidor é assumir a posição do primeiro em caso de falhas (modo chamado de ativo/passivo), diferente de um cluster com balanceamento de carga, onde os servidores dividem as requisições (ativo/ativo).
Existem diversas soluções para clusters de alta disponibilidade. Entre as soluções abertas, uma das mais usadas é o projeto Linux-HA (High-Availability Linux, disponível no http://www.linux-ha.org), que desenvolve o heartbeat, um daemon responsável por monitorar o status dos servidores do cluster e permitir que o segundo servidor assuma as funções do primeiro em caso de pane.
Cada um dos servidores possui pelo menos duas placas de rede, o que permite que eles sejam simultaneamente ligados à rede e ligados entre si através de um cabo cross-over ou de um switch dedicado. A conexão interna é usada pelo heartbeat para as funções de monitoramento e sincronismo dos processos, de forma que o segundo servidor possa assumir imediatamente a função do primeiro quando necessário, assumindo o endereço IP anteriormente usado por ele.
É comum também o uso de uma terceira interface de rede em cada servidor (ligada a um switch separado), destinada a oferecer uma conexão de backup com a rede. Isso permite eliminar mais um possível ponto de falha. Afinal, de nada adianta ter servidores redundantes se o switch que os liga à rede parar de funcionar 
.
Em geral, o heartbeat é usado em conjunto com o Drbd (http://www.drbd.org), que assume a função de manter os HDs dos dois servidores sincronizados, como uma espécie de RAID 1 via rede. Ao usar o Drbd, o HD do segundo servidor assume o papel de unidade secundária e é atualizado em relação ao do primeiro em tempo real. Quando o primeiro servidor para, a unidade de armazenamento do segundo servidor passa a ser usada como unidade primária. Quando o servidor principal retorna, o HD é sincronizado em relação ao secundário e só então ele reassume suas funções.
Outra opção é utilizar uma SAN (que veremos em mais detalhes nas partes seguintes do tutorial) para que os dois servidores compartilhem a mesma unidade de armazenamento. Nesse caso, não é necessário manter o sincronismo, já que os dados são armazenados em uma unidade comum aos dois servidores.
Como pode ver, adicionar componentes redundantes, sejam fontes, HDs ou servidores adicionais aumentam consideravelmente os custos. A principal questão é avaliar se o prejuízo de ter o servidor fora do ar por algumas horas ou dias durante as manutenções, acidentes e imprevistos em geral é maior ou menor do que o investimento necessário.
Um pequeno servidor de rede local, que atende a meia dúzia de usuários em um pequeno escritório dificilmente precisaria de redundância, mas um servidor de missão-crítica (como no caso de um banco) com certeza precisa. Cada nível de redundância adiciona um certo valor ao custo dos servidores, mas reduz em certa proporção o tempo de downtime.
A disponibilidade do servidor é genericamente medida em “noves”. Um nove indica uma disponibilidade de 90%, ou seja, uma situação em que o servidor fica fora do ar até 10% do tempo (imagine o caso de uma máquina instável, que precisa ser frequentemente reiniciada, por exemplo), o que não é admissível na maioria das situações.
Com dois noves temos um servidor que fica disponível 99%, o que seria uma boa marca para um servidor “comum”, sem recursos de redundância. Por outro lado, uma disponibilidade de 99% significa que o servidor pode ficar fora do ar por até 7 horas e 18 minutos por mês (incluindo todas as manutenções, quedas de energia, operações de backup que tornem necessário parar os serviços e assim por diante), o que é tolerável no caso de uma rede local, ou no caso de um servidor que hospeda um site fora da área de comércio eletrônico, mas ainda não é adequado para operações de missão crítica.
Para adicionar mais um nove, atingindo 99.9% de disponibilidade (o famoso “three nines”) não é possível mais contar apenas com a sorte. É necessário começar a pensar nos possíveis pontos de falha e começar a adicionar recursos de redundância. Entram em cena as fontes redundantes, o uso de uma controladora RAID com suporte a hot-swap, uso de um nobreak com boa autonomia para todo o equipamento de rede, de forma que o servidor continue disponível mesmo durante as quedas de luz, e assim por diante. Afinal, 99.9% de disponibilidade significa que o servidor não fica fora do ar por mais de 43 minutos por mês.
No caso de servidores de missão crítica, qualquer interrupção no serviço pode representar um grande prejuízo, como no caso de instituições financeiras e grandes sites de comércio eletrônico. Passa então a fazer sentido investir no uso de um cluster de alta disponibilidade e em links redundantes, de forma a tentar atingir 99.99% de disponibilidade. Esta marca é difícil de atingir, pois significa que o servidor não deve ficar mais do que 4 minutos e meio (em média) fora do ar por mês, incluindo aí tudo o que possa dar errado.
Como sempre, não existe uma fórmula mágica para calcular o ponto ideal (é justamente por isso que existem consultores e analistas), mas é sempre prudente ter pelo menos um nível mínimo de redundância, nem que seja apenas um backup atualizado, que permita restaurar o servidor (usando outra máquina) caso alguma tragédia aconteça.
HDs e interfaces
Quando falamos em HDs para servidores, a primeira sigla que vem à mente é o SCSI, mas o antigo barramento SCSI paralelo está dando lugar a uma versão serial, o SAS, da mesma forma que os antigos HDs IDE deram lugar aos HDs com interface SATA.
O SAS (Serial Attached SCSI), é um barramento serial, muito similar ao SATA utilizado em HDs domésticos em diversos aspectos, mas que adiciona várias possibilidades interessantes voltadas para o uso em servidores. As versões iniciais do SAS suportavam taxas de transferência de 150 e 300 MB/s. Recentemente foi introduzido o padrão de 600 MB/s e passou a ser desenvolvido o padrão seguinte, de 1.2 GB/s. A evolução é similar à do padrão SATA (note que as velocidades são as mesmas), porém o SAS tende a ficar sempre um degrau acima.
A maior velocidade é necessária, pois o SAS permite o uso de extensores (expanders), dispositivos que permitem ligar diversos discos SAS a uma única porta. Existem dois tipos de extensores SAS, chamados de “Edge Expanders” e “Fanout Expanders”. Os Edge Expanders permitem ligar até 122 discos na mesma porta (existem originalmente 128 endereços, mas apenas 122 deles podem ser usados, por limitações do protocolo de endereçamento), enquanto os Fanout Expanders permitem conectar até 128 Edge Expanders (cada um com seus 122 discos!), chegando a um limite teórico de até 15.616 discos por porta SAS. Naturalmente, conectar tantos HDs a uma única porta não seria nada bom do ponto de vista do desempenho, já que a interface se tornaria um grande gargalo, mas a possibilidade existe.
Este recurso foi desenvolvido pensando sobretudo nos servidores de armazenamento, que armazenam um grande volume de informações acessadas com pouca frequência. Com a popularização dos webmails e outros serviços, o armazenamento de grandes quantidades de dados tornou-se um problema. Não estamos falando aqui de alguns poucos gigabytes, mas sim de vários terabytes ou mesmo petabytes de dados. Imagine o caso do Gmail, por exemplo, onde temos vários milhões de usuários, cada um com mais de 2 GB de espaço disponível.
Os extensores SAS normalmente possuem a forma de um gabinete 1U ou 2U, destinados a serem instalados nos mesmos racks usados pelos próprios servidores. É muito comum que eles sejam chamados de “JBOD”. Nesse caso, a sigla não faz referência ao JBOD que vimos na descrição sobre os modos RAID, mas sim ao fato de o expander simplesmente oferecer acesso aos discos, sem implementar nenhum dos modos RAID por si mesmo. A tarefa no caso fica a cargo da controladora.
Na maioria, os discos são instalados em gavetas removíveis e podem ser trocados com o servidor ligado (hot swap). Isto permite substituir rapidamente HDs defeituosos, sem precisar desligar o servidor:
Adaptec S50 JBOD: SAS Expander com 12 baias
Nesses casos, seria utilizado um sistema RAID, onde parte do espaço e armazenamento é destinado a armazenar informações de redundância, que permitem restaurar o conteúdo de um HD defeituoso assim que ele é substituído, sem interrupção ou perda de dados. Ao contrário das controladoras RAID de baixo custo, encontradas nas placas-mãe para desktop, que executam suas funções via software, as controladoras SAS tipicamente executam todas as funções via hardware, facilitando a configuração (já que deixa de ser necessário instalar drivers adicionais) e oferecendo um maior desempenho e flexibilidade.
As controladoras SAS incluem normalmente 4 ou 8 portas e são instaladas em um slot PCI-X, ou PCI Express. Nada impede também que você instale duas ou até mesmo três controladoras no mesmo servidor caso precise de mais portas:
Controladora SAS
Veja que além do conector interno, a controladora possui um conector externo que, apesar de pequeno, concentra 4 portas adicionais, o que (no SAS 300) resulta em uma banda total de 1.2 GB/s, quase 4 vezes o oferecido por uma controladora SCSI 320. Este conector, chamado SFF-8470, é justamente destinado à conexão de extensores externos.
Um detalhe interessante é que o padrão SAS oferece compatibilidade retroativa com os HDs SATA, permitindo que você use HDs SATA convencionais em conjunto com uma controladora SAS, como uma forma de cortar custos, sem ter que abrir mão da possibilidade de usar os extensores. É possível também combinar HDs dos dois padrões, usando HDs SATA comuns em tarefas que demandem um nível menor de confiabilidade (unidades de backup, por exemplo), reservando os caros HDs SAS para as tarefas principais.
Como citei no início do capítulo, uma das principais desvantagens do uso de HDs IDE em servidores era a ausência do suporte a NCQ, o que os tornava muito mais lentos que os SCSI em operações de acesso aleatório (que são justamente as operações predominante em servidores), mesmo que as demais características dos HDs fossem similares. Com a popularização dos HDs SATA com suporte a NCQ, esta barreira deixou de existir, fazendo com que o desempenho dos HDs para uso doméstico ficasse muito mais próximo do dos HDs SCSI para uso em servidores, que são muito mais caros.
A maior parte dos HDs de alto desempenho, com rotação de 15.000 RPM, que antes só existiam em versão SCSI, estão sendo lançados também em versão SAS. Nos próximos anos é de se esperar que o SAS substitua gradualmente o SCSI, assim como o SATA já substituiu o IDE quase que completamente nos micros novos.
Você pode se perguntar como HDs SAS e SCSI, destinados a servidores conseguem conviver com HDs SATA tradicionais, que em muitos casos oferecem um custo por megabyte até 10 vezes menor.
O primeiro fator é a questão do desempenho, já que muitos HDs para servidores oferecem rotação de 15000 RPM e utilizam discos de 2.5″ (mesmo que o HD em si ocupe uma baia de 3.5″), como no caso deste Hitachi 15K300 SAS:
Em situações normais, discos menores significam um desempenho mais baixo (como no caso dos HDs para notebook), mas nestes casos, a combinação de mecanismos de movimentação especialmente desenvolvidos e a maior velocidade de rotação permitem que o HD trabalhe com tempos de acesso bastante baixos, o que resulta em um desempenho em leituras aleatórias muito superior ao de um HD de 10000 PRM tradicional.
Em um servidor típico, são realizadas um enorme número de pequenas leituras, que são usadas para montar as páginas ou arquivos que serão enviados aos clientes. Um fórum com um grande número de mensagens pode facilmente resultar em um banco de dados de 10 ou mesmo 20 GB, contendo uma infinidade de pequenas mensagens de texto e ter 1000 ou 2000 visitantes simultâneos em determinados períodos.
Para cada página a ser exibida, o servidor precisa ler várias entradas dentro do banco de dados (o tópico propriamente dito, informações sobre os usuários e assim por diante). Mesmo com o uso de caches, não é difícil imaginar que tantas requisições simultâneas levam o desempenho dos HDs ao limite. Nesse cenário, qualquer redução no tempo de acesso representa um grande ganho de desempenho.
O segundo fator é a questão da confiabilidade. Os HDs usados em servidores são submetidos a um regime de trabalho muito mais intenso do que em um desktop típico e, quase sempre, operam continuamente, até que sejam substituídos. HDs destinados a servidores utilizam cabeças de leituras mais rígidas, motores de rotação mais confiáveis, carcaças mais resistentes e oferecem uma qualidade de construção menor, já que o fabricante pode se dar o luxo de usar os melhores materiais disponíveis, sem precisar contar os centavos como em um HD para desktop.
Isso não significa que os HDs para desktop não possam ser usados em servidores. A grande maioria dos servidores web e pequenos servidores em geral (que são a esmagadora maioria quando falamos em números absolutos) utilizam HDs SATA tradicionais. Existem inclusive muitos casos de servidores que ainda utilizam discos IDE e provavelmente vão continuar utilizando até que eles parem definitivamente de funcionar por um defeito mecânico qualquer.
A principal questão é que a possibilidade de um HD SATA destinados a desktops apresentar um defeito prematuro quando submetido à pesada carga de trabalho de um servidor é maior do que a de um HD SAS especialmente construído. É a velha questão da confiabilidade versus custo. Se o objetivo é oferecer um servidor dedicado de baixo custo, que será locado por 80 dólares mensais, é natural que o datacenter irá utilizar HDs tradicionais, oferecendo provavelmente um plano de backup opcional. Uma parte dos HDs vai apresentar defeitos nos dois primeiros anos de uso, mas os demais irão continuar funcionando por 4 anos, ou até mais. Se o custo relacionado à possibilidade de perda de dados e o ao downtime relacionado à substituição dos HDs e reconfiguração dos servidores for inferior à economia, então a escolha vale à pena.
Entretanto, quando falamos de servidores de missão crítica, o caminho natural passa a ser usar os HDs mais confiáveis, já que qualquer interrupção no serviço pode custar muito mais do que qualquer economia feita nos HDs. Temos também os casos em que o ganho por utilizar HDs SAS de alto desempenho pode compensar o maior investimento, já que um melhor desempenho equivale a mais requisições e, conseqüentemente, mais clientes atendidos. A perda acumulada de algumas visitas diárias, ao longo de alguns anos, poderia corresponder a um prejuízo equivalente a várias vezes o valor investido nos HDs, embora cada caso seja um caso.
Entretanto, vale lembrar que a confiabilidade pode ser obtida também através do uso de RAID, de forma que muitos preferem utilizar HDs domésticos, reservando mais discos do array RAID para redundância. Se um HD SAS custa o dobro de um HD SATA equivalente, por exemplo, faria mais sentido comprar dois HDs SATA e usá-los em RAID 1, do que usar um único HD SAS.
Um bom exemplo de uso desta filosofia é o Google, que utiliza servidores de baixo custo, montados com HDs e placas comuns, o que permite que construam seus gigantescos datacenters a preços relativamente baixos. Quase todas as funções de redundância e tolerância a falhas são implementadas via software as transferências executadas usando interfaces de rede.
Existem ainda casos de HDS SATA destinados a uso em servidores (procure dentro da seção “enterprise” nos sites dos fabricantes), como o Seagate NL35 e o Western Digital WD2500YD, que oferecem uma boa confiabilidade e são bem mais baratos que um HD SAS típico.
Racks, blades e torres
Rack com três gabinetes 1U e rack vazio
Os servidores no formato 1U são preferidos por empresas de hospedagem e para uso em datacenters, pois são bastante compactos (apenas 4.4 cm de altura), o que permite instalar um grande número de servidores por rack. As principais limitações do formato são as limitações com relação à ventilação (devido ao pequeno espaço interno), o que dificulta o uso de processador com consumo elétrico elevado e a necessidade de usar coolers e fontes especiais, o que encarece os projetos. Além dos componentes básicos, sobre em geral espaço para instalar 2 ou 4 HDs de 3.5″ (de acordo com a disposição dos demais componentes) e uma única placa de expansão, instalada na horizontal, com a ajuda de um riser:
Servidores em gabinetes 1U
Alguns servidores utilizam drives ópticos, como este das fotos anteriores, mas eles são mais a exceção do que a regra. Embora muitos servidores ainda sejam instalados seguindo o processo manual, dando boot usando a mídia de instalação e seguindo os passos do instalador, cada vez mais empresas (sobretudo empresas de hospedagem) optam por utilizar imagens pré-configuradas, instaladas através da rede. Nesse caso o servidor dá boot via PXE e um servidor de boot remoto fornece a imagem binária com o sistema, o que resulta em uma brutal economia de tempo em datacenters com muitos servidores.
Continuando, temos os gabinetes 2U. Eles utilizam fontes e coolers “normais” e por isso acabam sendo um pouco mais baratos. O maior espaço interno torna o formato 2U mais adequado para servidores com dois ou mais processadores, ou que utilizam processadores de alto consumo. A altura ainda não é suficiente para instalar placas de expansão na vertical, como nos desktops, mas é possível usar um riser (como no caso dos 1U), ou utilizar placas half-height, as placas mais baixas, que possuem metade da altura das placas normais.
Servidor em gabinete 2U
Finalmente, temos os servidores maiores, que utilizam gabinetes 3U ou 4U. Existem ainda servidores 6U, mas eles são raros. Normalmente este formato é usado por arrays de disco e gabinetes para blade servers (veja o tópico a seguir). Usar um gabinete 3U ou maior elimina completamente os problemas com espaço, permitindo utilizar placas de expansão na vertical e um grande número de HDs instalados em baias removíveis.
Gabinete 3U
Os racks permitem instalar um grande volume de servidores, switchs, roteadores e outros equipamentos em uma área relativamente pequena, além de facilitar a administração, já que permitem organizar melhor o cabeamento (e reduzir o comprimento dos cabos) e podem ser rapidamente substituídos. No caso de um data-center, onde o espaço é limitado e o número de servidores instalados chega às dezenas de milhares, os racks são uma solução natural.
Naturalmente, colocar tantos servidores em um espaço físico tão pequeno torna necessário o uso de um sistema de ar condicionado, para manter a temperatura e a umidade do ambiente em níveis ideias. Uma temperatura mais baixa e a pouca entrada de ar externo ajudam a aumentar a confiabilidade dos servidores, já que temperaturas mais baixas ajudam a aumentar a vida útil da maioria dos componentes e menos poeira significa menos problemas relacionados aos coolers.
Outro formato que vem se tornando cada vez mais popular são os blade servers (a palavra blade vem de “lâmina”, indicando as dimensões reduzidas do formato), uma idéia engenhosa para aumentar ainda mais a densidade dos servidores e permitir o compartilhamento de componentes em comum, como fontes de alimentação e discos ópticos.
A idéia é que ao invés de ter 10 servidores 1U, com 20 fontes (duas para cada servidor, já que são usadas fontes redundantes), 20 cabos de rede (cada servidor usa tipicamente dois cabos, um para a rede e outro para gerenciamento), além de cabos de força, cabos usados pelo KVM e assim por diante, você possa usar um único gabinete, com um número equivalente de blade servers:
Gabinete com 10 blade servers
Esse design permite simplificar bastante o design. Ao invés de duas fontes para cada servidor, o gabinete utiliza duas ou quatro fontes de maior capacidade, além de um switch, KVM e outros componentes compartilhados. Todos os conectores são agrupados em uma backbone, no fundo do gabinete, de forma que os servidores são simplesmente encaixados, como cartuchos, que podem ser substituídos sem precisar desligar todo o conjunto. Atualmente, existem modelos com até 12 servidores em um único gabinete 4U, ou mesmo 3U, o que permite instalar 100, 120 ou até mesmo 150 servidores em um único rack.
Cada blade é um servidor completo, com processador, memória, placa de rede e discos. Devido ao tamanho reduzido, os blade servers utilizam tipicamente processadores de baixo consumo e discos de 2.5″. No início, era comum o uso de processadores da Transmeta e da VIA, mas eles acabaram sendo quase que completamente substituídos por processadores Core 2 Duo e versões atualizadas do Xeon (no caso dos Intel) ou processadores Athlon X2, Opteron ou Phenom (no caso dos AMD), que são muito mais rápidos, mas ainda assim relativamente econômicos. No caso dos HDs, os discos de 2.5″ são preferidos por que oferecem tempos de acesso mais baixos (embora percam com relação à taxa de transferência), além do consumo elétrico e dimensões reduzidas.
Apesar do custo unitário ser muitas vezes mais alto (sem falar no custo por megabyte), é possível instalar 4 HDs de 2.5″ em aproximadamente o mesmo espaço de um único HD de 3.5″. Naturalmente, 4 HDs de 2.5″ em RAID oferecem um desempenho muito superior ao de um único HD de 3.5″, de forma que eles acabam fazendo mais sentido quando é necessário oferecer o melhor desempenho de acesso a disco possível e o espaço é um fator limitante. Em muitos casos, os HDs locais podem ser substituídos por um array de discos compartilhado, como veremos mais adiante no tópico sobre SAN.
HP BL35p, um exemplo de blade server
Note que as principais vantagens dos blade servers são a possibilidade de instalar mais servidores no mesmo espaço físico e reduzir o volume de trabalho consumido pelo cabeamento e manutenção dos servidores. Os blade servers não são necessariamente mais baratos (pelo contrário), de forma que, em ambientes onde o espaço não é problema, usar servidores tradicionais, em gabinetes 1U ou 2U acaba fazendo mais sentido, já que eles são (quase sempre) mais baratos e oferecem melhores possibilidades de expansão.
Uma outra forma de aumentar a densidade dos servidores, sem precisar colocar mais máquinas no mesmo espaço físico é usar virtualização. Um único servidor, com vários processadores, muita memória e muito espaço de armazenamento pode ser então dividido em vários servidores virtuais, utilizando o VMware GSX Server (a versão mais parruda do VMware Server) o Xen ou outra solução similar. Devido ao compartilhamento de recursos, os servidores virtuais podem até mesmo oferecer um desempenho superior ao de vários servidores menores no mesmo espaço físico.
Servidores em gabinetes torre também existem e respondem por quase 1/4 dos servidores vendidos (sem contar os servidores montados, que utilizam componentes e gabinetes de micros desktop), mas eles são mais comuns em redes locais e empresas com poucos servidores, onde a questão do espaço não é um problema.
É importante lembrar que uma das melhores formas de reduzir o custo de administração de uma rede local é justamente concentrar os serviços em menos servidores. Se levarmos em consideração todos os custos envolvidos, incluindo energia elétrica, mão de obra e perdas relacionadas ao downtime dos servidores, usar um único servidor parrudo, com fonte redundante e outros apetrechos pode sair mais barato a longo prazo do que usar 5 servidores menores montados com componentes padrão, mesmo que o custo inicial seja mais alto.
KVM
Embora os servidores sejam quase sempre administrados remotamente, é comum que seja usado um KVM para permitir o acesso local aos servidores quando necessário. Um KVM é um chaveador, que permite que um único conjunto de teclado, mouse e monitor seja usado para controlar várias máquinas, chaveando entre elas conforme necessário.
Existem KVMs voltados especificamento ao uso em servidores, que oferecem um grande número de saídas, são instalados diretamente no rack com os servidores e já incluem um conjunto de tela, teclado e mouse instalados dentro de uma gaveta, de forma a facilitar o acesso e reduzir o espaço ocupado:
Alguns aparelhos atuais são acessíveis via rede (KVM over IP), utilizando o protocolo TCP/IP. Isso permite que vários KVMs sejam ligados, usando o próprio cabeamento de rede já existente, a um KVM central, permitindo que o administrador tenha acesso local a qualquer um dos servidores a partir de um único ponto.
Outra opção é o uso de um terminal serial, onde toda a saída de texto (incluindo as mensagens exibidas durante o boot e a tela do Setup) são direcionadas para uma porta serial e exibidas em um terminal remoto, uma opção muito útil em casos onde o servidor parou misteriosamente de responder via SSH ou outros métodos de acesso remoto.
Um outro servidor da rede, equipado com uma placa multi-serial tem cabos seriais ligados a vários outros servidores. Hoje em dia os cabos seriais são feitos usando cabos de rede, aproveitando a boa qualidade e o baixo custo dos cabos.
Quando um deles deixa de responder através da rede, você ainda pode acessar a máquina com os consoles seriais (mesmo remotamente) e acessar o servidor através dele. Alguns administradores chegam a deixar um modem programado para receber conexões, como uma última linha de defesa para o caso do switch ou gateway da rede cair e todo o datacenter ficar inacessível remotamente.
