English Version O TS7300 na minha bancada de testes (clique para ampliar), mostrando o consumo de energia. Ignore os dados de temperatura, eu desativei esses sensores.

Alta Disponibilidade e o TS7300

Rec 19-jan-2008 09:42

Um desafio clássico em monitoração de redes é o seguinte: quando você projeta um sistema para monitorar a disponibilidade de outro, o primeiro tem de ser mais disponível/confiável do que o segundo. Digamos que queremos monitorar um punhado de servidores redundantes que ficam 99,99% do tempo no ar; o sistema de monitoração deve ser ainda mais confiável, estável e disponível que isso -- digamos, 99,999%.

Por isso, quando eu estava escolhendo um hardware para um sistema de monitoração lá da Tempest, eu queria um computador fisicamente pequeno mas robusto que tivesse boa redundância interna e confiabilidade espetacular. Essencialmente, um computador que não quebre, nem trave, nem endoide. As causas mais comuns de falhas em PCs são quando pifam os "coolers" (fritando as CPUS), as fontes ou discos rígidos. Vamos começar substituindo o disco rígido por memória flash que, sem partes móveis, duram muito mais.

Também queria que o sistema continuasse vivo mesmo no caso de uma falha de energia de 48 horas. Não há muitos no-breaks que consigam manter PCs comuns por tanto tempo; e os que conseguem custam uma pequena fortuna. Já que não podemos aumentar o no-break, vamos reduzir os requisitos de energia e adotar um computador que requeira menos de 3W de energia (em contraste, PCs comuns consomem por volta de 100W).

Ainda assim, eu quero um computador poderoso o bastante para rodar um Debian Linux completo -- o nosso software de monitoração, tal como a maior parte dos nossos sistemas de produção, roda nessa plataforma. Estaremos rodando diversos de scripts em Perl para checar os serviços e contar há quantos minutos eles estão operado em modo totalmente redundante, nos vários possível modos degradados e quanto tempo permaneceram offine. Haverá uns 30 ou 40 desses monitoradores.

Esse computador vai servir também a outro propósito: como uma estação de acesso de emergência para que possamos acessar os consoles dos servidores através de suas portas seriais. A maior parte dos nossos servidores oferecem console via serial, o que nos dá a capacidade de fazer uma reinstalação do sistema operacional de forma totalmente remota. Mas, para isso, vamos precisar de um monte de portas seriais -- no mínimo 8, pra começar. Também quero uma porta USB para podermos conectar um modem GSM em casos de falha do acesso à Internet e também para mandar alertas via SMS.

Também precisamos de duas portas Ethernet para conectar a dois switches em configuração redundante. 100BaseT é mais do que suficiente; não há necessidade de velocidades Gigabit.

Há pelo menos um computador que se encaixa perfeitamente nesses quesitos: o TS-7300 da Technologic Systems. Ele usa um processador ARM de 200MHz com 128MiB de RAM e 2 conectores para cartão SD, que fazem as vezes dos discos rígidos de um computador convencional. A performance é modesta: aproximadamente a mesma de um Pentium clássico de 166MHz. Contudo, para esta aplicação, é mais do que suficiente -- além do que nada no computador esquenta, dispensando os famigerados "coolers" que vivem pifando.

Esse processador ARM é muito parecido com os presentes na maioria dos telefones celulares de hoje em dia. Em outras palavras: se os celulares viessem com portas ethernet, ele poderiam ser perfeitamente usados nesse projeto.

O cartão SD que vem com o TS7300 inclui uma distribuição completa do Debian-ARM já instalado, pronto para rodar, de sorte que não haverá grandes complexidades adicionais no que tange ao software.

Uma esquisitice é que o sistema de arquivos raiz é um ext2. Que o bootloader requeira isso é compreensível, por ter de ser muito pequeno e simples. Mas usar o ext2 para a distro completa do Debian me parece uma má idéia; primeiro, sempre ouvi falar que, para dispositivos de armazenamento baseados em memória flash, é melhor usar sistemas de arquivos otimizados para isso, tais como o jffs2 ou o yaffs -- ou será que aquela velha limitação de 100.000 escritas em um mesmo setor já foi consertada e eu não fiquei sabendo? Eu lembro vagamente de ter lido que o firmware de alguns SD cards guardam setores de reserva para realocá-los quando algum falhe, tal como fazem os discos rígidos convencionais, mas não faço idéia do quão eficiente isso é na vida real.

Segundo, quando você reinicia o sistema sem antes tê-lo desligado por software, lá vem de novo o maldito e demorado fsck (essa é a razão pela qual há anos eu venho usando o reiserfs). Vou tentar ver um meio de criar novas partições com sistemas de arquivos melhores e ver como encaixar isso no procedimento de inicialização do sistema.

Aliás, a partida do TS7300 é bem interessante. O código da ROM pode tirar um checksum de parte do conteúdo do cartão (inclusive seu número de série) e se recusar a continuar se não bater com um valor pré-programado. Isso torna o sistema um pouco mais difícil de subverter do que apenas trocar o cartão SD. Se o checksum bater sem problemas, a imagem do kernel e o initrd são carregados, potencialmente lhe aterrisando na linha de comando meros 1,7 segundos após o dispositivo ser ligado. O initrd padrão vem com o busybox e outras bonanças. O script linuxrc padrão lhe dá a opção de pivotar para outra raiz contendo um sistema Debian completo -- que, como em um PC comum, demora um pouco para dar partida por causa dos init scripts. Fico pensando o quão rápida poderíamos tornar a partida se usássemos substitutos do init, tal como o runit juntamente com o daemontools e serviços minimalistas à la os do DJB.

Uma característica intrigante do TS7300 é que muitos dos periféricos -- tais como a segunda porta Ethernet, a placa de vídeo, 8 das dez portas seriais e os dois blocos de GPIO -- são implementados em uma FPGA (ahá -- isso seu telefone celular não tem... ainda). Isso significa que podemos mudá-los -- planejo deletar a placa de vídeo, substituí-la por mais 8 UARTs e adicionar uma placa-filha com conversores de nível MAX232 e conectores D-Sub9. No final, isso me dará uma máquina com 18 portas seriais, suficiente para um rack cheinho de servidores.

Anseio por pelo dia, não muito distante, em que os PCs comuns vão ter não apenas uma, mas provavelmente várias, FPGAs grandes e capazes -- isso abrirá fantásticas possibilidades em termos de computação de alta performance.

Na figura você pode ver o TS7300 na minha bancada de testes, ligado a uma fonte que eu projetei que mede o consumo de energia. Os 9V é a voltagem da entrada, provido por uma fonte-tijolo. Meu circuito converte isso para os 5VDC regulados que o TS7300 requer. Na foto, vemos que o consumo dele é de uns 480mA quando ocioso a 200MHz. Medi que quando a CPU vai a 100%, ele chega a consumir uns 600mA. Baixando o clock para 42MHz reduz o consumo para uns 380mA em modo ocioso. Quando baixei a CPU para o mínimo possível -- 14MHz -- ele consumiu ainda menos, mas a porta Ethernet deixou de funcionar. Nota para mim mesmo: fazer o watchdog monitorar isso e reverter -- senão vai que algum operador faz isso e torna o disposivo inacessível.

Estou usando esses dados para projetar uma placa-filha misto de fonte+multiserial. A própria Technologic Systems oferece uma placa-filha com um sistema de bateria de reserva chamado TS-BAT3, mas, com capacidade de 1000mAh, manteria o sistema vivo por apenas umas 2 horas. Pretendo usar dois bancos de 6 pilhas alcalinas grandes comuns de 15.000mAh para exceder a marca desejada de 48 horas.

Experimentei também plugar um minimodem GSM TS9989i que a Claro está empurrando pra todo mundo, mas não funcionou. Suspeito que o minimodem está pedindo mais corrente do que a porta USB pode prover; vou fazer um cabo USB com fonte própria pra testar isso. Se eu estiver certo, vou acabar precisando de mais baterias ainda!

E a coisa boa é que o TS7300 tem um preco aceitável -- o de teste que eu comprei saiu por USD $420, que, naturalmente, sai meio salgado aqui no Brasil por causa dos 60% de imposto de importação. E isso inclui os extorsivos US$ 100 cobrados pela UPS (cujo sistema de rastreamento, por sinal, não funciona direito aqui no Brasil -- o pacote foi entregue no mesmo dia em que o sistema ainda dizia que ele estava parado em Campinas). Mas, coloquemos em perspectiva -- há celulares e PCs que custam mais que isso. Pra um computador que não quebra, não está lá tão ruim assim.
topo