Em janeiro entrará em operação Gordon, o primeiro supercomputador baseado em armazenamento SSD.
Com um investimento de U$20milhões (financiado pela National Science Foundation) o supercomputador chama a atenção por seus números surpreendentes e, sobretudo, por ser pioneiro na adoção de armazenamento em memórias Flash (daí o nome Gordon, Flash Gordon!).
Alerta: S5520HCR e S5500HCVR usam a mesma serigrafia
Consegue notar a diferença entre as placas acima?
Os modelos de placa mãe de servidor S5500HCVR e S5520HCR (Hanlan Creek) compartilham o mesmo PCB, ou seja, a "placa" é a mesma. O que muda são os componentes aplicados em cada modelo.
No modelo S5500HCVR o chipset empregado é o Intel® 5500 e há 9 slots de memória (note na imagem que o segundo processador agrega apenas 3 slots.
Já no modelo S5520HCR, o chipset é o Intel® 5520 (Tylersburg) e estão presentes 12 slots de memória (note que há 6 slots para cada processador).
Como o PCB é o mesmo, em ambos os modelos a placa vem serigrafada como S5520HC!
A Intel já tem circuitos de 14nm rodando em seus laboratórios, revela executivo
"A Intel já tem circuitos de 14nm rodando em seus laboratórios", revelou Pat Bliemer, executivo da fabricante para o norte da Europa.
A Intel foi a primeira fabricante de semicondutores a empregar tecnologia de 32 nanômetros para produção em massa de microprocessadores e, até o final do primeiro trimestre do próximo ano, vai apresentar processadores sob a nova arquitetura Ivy Bridge, com litografia de 22 nanômetros e suporte dos revolucionários transistores 3D (Tri-gate).
Com o lançamento da família Ivy Bridge a Intel estará uma volta e meia à frente dos concorrentes - que ainda enfrentam grandes problemas para estabilizar seus processos abaixo dos 20nm.
A Intel foi a primeira fabricante de semicondutores a empregar tecnologia de 32 nanômetros para produção em massa de microprocessadores e, até o final do primeiro trimestre do próximo ano, vai apresentar processadores sob a nova arquitetura Ivy Bridge, com litografia de 22 nanômetros e suporte dos revolucionários transistores 3D (Tri-gate).
Com o lançamento da família Ivy Bridge a Intel estará uma volta e meia à frente dos concorrentes - que ainda enfrentam grandes problemas para estabilizar seus processos abaixo dos 20nm.
Intel anuncia queda de receita devido à escassez de HDs
As enchentes na Tailândia que afetaram a produção de HDs começam a causar reflexos em outros segmentos da indústria de TI.
Hoje foi a vez da Intel anunciar uma redução das receitas para o quarto trimestre de 2011, reflexo da escassez de HDs causada pelas enchentes de outubro na Tailândia.
Segundo Stacy Smith (foto), CFO da Intel, a fabricante espera faturar cerca de U$13,7 bilhões (as expectativas anteriores ao desastre apontavam para U$14,7 bilhões).
Hoje foi a vez da Intel anunciar uma redução das receitas para o quarto trimestre de 2011, reflexo da escassez de HDs causada pelas enchentes de outubro na Tailândia.
Segundo Stacy Smith (foto), CFO da Intel, a fabricante espera faturar cerca de U$13,7 bilhões (as expectativas anteriores ao desastre apontavam para U$14,7 bilhões).
Custos muito próximos nos SSDs das séries 320 e 510 da Intel®
Muitos usuários já perceberam que os SSDs Intel® de 120GB e 160GB tem custos próximos, assim como os modelos de 250GB e 300GB.
Qual a vantagem de escolher um SSD menor, já que o custo é praticamente o mesmo?
Um detalhe que tem passado despercebido para alguns usuários é a série desses SSDs! Um detalhe que pode significar muita diferença no desempenho.
Qual a vantagem de escolher um SSD menor, já que o custo é praticamente o mesmo?
Um detalhe que tem passado despercebido para alguns usuários é a série desses SSDs! Um detalhe que pode significar muita diferença no desempenho.
Por onde andam os servidores Apple Xserve?
Poucos usuários chegaram a conhecer, mas a Apple lançou uma linha de servidores em 2002 e, após 8 anos, retirou os produtos do mercado em novembro de 2010.
Apesar do reconhecimento mundial da marca, da admiração de uma legião de seguidores e dos incontestáveis sucessos comerciais - como os iMacs, MacBook Pro, MacBook Air e, sobretudo, o iPhone - o fabricante não conseguiu replicar esse sucesso no segmento de servidores.
Apesar do reconhecimento mundial da marca, da admiração de uma legião de seguidores e dos incontestáveis sucessos comerciais - como os iMacs, MacBook Pro, MacBook Air e, sobretudo, o iPhone - o fabricante não conseguiu replicar esse sucesso no segmento de servidores.
Mesmo fora de linha, fabricantes insistem em oferecer processadores obsoletos no Brasil
Estamos praticamente em 2012 e o número de cotações solicitando servidores com processadores Xeon® 5500 "Nehalem" ainda nos causa espanto!
Mesmo tendo migrado dos antigos processadores Xeon® 5500 para os atuais Xeon® 56xx (Westmere) em junho de 2010, diariamente ainda recebemos usuários que especificam servidores baseados na família antiga.
Identificamos dois principais motivos para essa insistência nos modelos antigos. Uma entendemos... A outra repudiamos...
Mesmo tendo migrado dos antigos processadores Xeon® 5500 para os atuais Xeon® 56xx (Westmere) em junho de 2010, diariamente ainda recebemos usuários que especificam servidores baseados na família antiga.
Identificamos dois principais motivos para essa insistência nos modelos antigos. Uma entendemos... A outra repudiamos...
Hoje é Dia de Backup
Mais um mês acaba e, como sempre, lembramos a importância de manter um backup confiável e protegido!
Confiável porque o backup, apesar de ser uma rotina automatizada, precisa ser checado e testado regularmente. Há caminhos que mudam, novas pastas são criadas, outras deixam de ser importantes... Por isso é preciso estruturar um mapa consistente de conteúdo e certificar-se que todas as informações importantes estão cobertas pela cópia de segurança.
Testado, porque não são raras as vezes em que os dados não chegam íntegros ao backup e, quando realmente são necessários, a decepção é arrasadora!
RAID, fontes redundantes e balanceamento de carga não substituem o backup...
As tecnologias que asseguram o uptime dos servidores facilitam muito a gerência de TI, mas não substituem o backup!
RAID, como já comentamos em postagem anterior, é uma tecnologia fantástica. Permite que um servidor mantenha-se acessível mesmo durante uma falha de I/O.
Fontes redundantes também visam manter um servidor operante, mesmo que uma das fontes de alimentação (uma das origens de energia) venha a ser desligada.
Esse recurso é crucial em modelos onde a energia seja fornecida por duas vias distintas, em especial por dois no-breaks alimentados por concessionárias diferentes.
A solução baseada em fontes redundantes é altamente arriscada quando há apenas uma origem de energia e, nessa, há excessos de ruídos e/ou sobretensão. Havendo apenas uma origem de energia, quando ocorrer uma sobretensão, acontecerá a queima da primeira fonte e, logo em seguida, da segunda; já que a origem do problema persiste atacando ambos os módulos de fonte!
Balanceamento de carga, além de manter o servidor online no caso de pane em um dos links, ainda traz ganhos quando ambos estiverem ativos, pois permitirá distribuir o tráfego de rede por caminhos físicos individualizados.
Nenhuma dessas tecnologias assegura a integridade das informações no caso de acidentes, sabotagens, desastres naturais e tantos outros riscos que envolvem a disponibilidade de uma aplicação.
Desastres acontecem...
Em geral cultivamos um pensamento otimista e acreditamos que problemas nunca afetarão nossas operações. Porém, se considerarmos que as informações de uma empresa são seu ativo mais precioso, é preciso prever o pior e planejarmos um processo de backup para que essas informações estejam seguras fora do nosso ambiente de trabalho.
Chuvas na região serrana...
No verão de 2011, quando deslizamentos de encostas assolaram a região serrana do RJ, diversas empresas foram afetadas e, muitas delas, tiveram suas instalações inundadas e destruídas.
As empresas que mantinham um backup consistente enfrentaram problemas, mas conseguiram restabelecer o acesso aos dados em pouco tempo.
Adquirir um novo servidor e providenciar um link em outra cidade é algo simples de se obter em poucos dias. Se o gestor dessas informações configurar um novo servidor e restaurar um backup atualizado, terá alcance às suas informações em tempo.
Até o Cloud da Amazon caiu...
A computação em nuvem vem ganhando cada vez mais destaque e, como toda tecnologia que ganha ares de celebridade, é alardeada como a cura para todos os problemas!
É notório que o serviço de cloud da Amazon está entre os melhores do mundo e, mesmo assim, em abril de 2011 o serviço ficou cinco dias fora do ar, afetando centenas de clientes e acarretando perda de informação para alguns (o número de clientes prejudicados não foi divulgado e há um grande esforço em manter esse número em sigilo).
Vale lembrar que o serviço EC2 da Amazon segue a filosofia de distribuir a nuvem entre datacenters geograficamente independentes (veja o exemplo a seguir para entender o que acontece quando a nuvem inteiro fica em apenas 1 datacenter) e, mesmo assim, o serviço caiu!
Os clientes que mantinham cópia de seus dados em local seguro tiveram a opção de aguardarem o sistema voltar e, se o problema persistisse, poderiam injetar seus dados em uma nuvem concorrente e restabelecerem seus sistemas. Já quem não tinha...
Pane elétrica na Alog-RJ...
Mesmo contando com no-breaks inteligentes e geradores plenamente funcionais, em julho de 2011 o datacenter da ALOG no RJ sofreu uma pane elétrica que acarretou em 2 dias de desligamento e inúmeras perdas de dados com corrupção de bancos de dados!
Diversas empresas mantinham infraestrutura no datacenter e, durante 2 dias, somente aquelas que possuíam um backup confiável conseguiram levantar seus serviços em outro datacenter e sustentarem suas aplicações online.
Nós mesmos passamos por essa situação!
Alguns de nossos serviços rodam em servidores que ficam nesse datacenter e, quando ocorreu o desastre elétrico, migramos os sites para nossa rede interna e levantamos com nosso backup. Para nossos clientes e funcionários nossas atividades operacionais passaram despercebidas, sendo notada apenas uma lentidão, já que nosso link interno não era tão largo.
Esse exemplo mostra que um servidor com fontes redundantes, diversos no-breaks e balanceamento de carga não valeria de nada em um desastre elétrico como esse!
Explosão em restaurante carioca prejudica 136 salas comerciais...
Em 13 de outubro de 2011, retorno de feriado, um acúmulo de gás provocou a explosão de um restaurante que funcionava no centro do RJ.
O restaurante ocupava o andar térreo de um edifício com 12 andares e 136 salas comerciais.
Desde então o edifício está LACRADO e, segundo a Defesa Civil do RJ, o edifício não será reaberto em 2011.
Nas 136 salas comerciais funcionavam empresas de contabilidade, advocacia, webdesign, representação comercial, etc...
Esse exemplo mostra que a preocupação não deve ser apenas em empresas grandes.
Todos os escritórios e microempresas que mantinham backup de suas informações foram surpreendidas com a explosão na volta de um feriado mas, bastando adquirir novos PCs, levantaram suas operações no mesmo dia.
Já as empresas que não tinham backup dos dados, mesmo não tendo qualquer ligação com o restaurante, viram seu negócio ruir quando não tiveram mais acesso ao prédio.
Prevenir ainda é melhor que remediar...

Confiável porque o backup, apesar de ser uma rotina automatizada, precisa ser checado e testado regularmente. Há caminhos que mudam, novas pastas são criadas, outras deixam de ser importantes... Por isso é preciso estruturar um mapa consistente de conteúdo e certificar-se que todas as informações importantes estão cobertas pela cópia de segurança.
Testado, porque não são raras as vezes em que os dados não chegam íntegros ao backup e, quando realmente são necessários, a decepção é arrasadora!
RAID, fontes redundantes e balanceamento de carga não substituem o backup...
As tecnologias que asseguram o uptime dos servidores facilitam muito a gerência de TI, mas não substituem o backup!
RAID, como já comentamos em postagem anterior, é uma tecnologia fantástica. Permite que um servidor mantenha-se acessível mesmo durante uma falha de I/O.
Fontes redundantes também visam manter um servidor operante, mesmo que uma das fontes de alimentação (uma das origens de energia) venha a ser desligada.
Esse recurso é crucial em modelos onde a energia seja fornecida por duas vias distintas, em especial por dois no-breaks alimentados por concessionárias diferentes.
A solução baseada em fontes redundantes é altamente arriscada quando há apenas uma origem de energia e, nessa, há excessos de ruídos e/ou sobretensão. Havendo apenas uma origem de energia, quando ocorrer uma sobretensão, acontecerá a queima da primeira fonte e, logo em seguida, da segunda; já que a origem do problema persiste atacando ambos os módulos de fonte!
Balanceamento de carga, além de manter o servidor online no caso de pane em um dos links, ainda traz ganhos quando ambos estiverem ativos, pois permitirá distribuir o tráfego de rede por caminhos físicos individualizados.
Nenhuma dessas tecnologias assegura a integridade das informações no caso de acidentes, sabotagens, desastres naturais e tantos outros riscos que envolvem a disponibilidade de uma aplicação.
Desastres acontecem...
Em geral cultivamos um pensamento otimista e acreditamos que problemas nunca afetarão nossas operações. Porém, se considerarmos que as informações de uma empresa são seu ativo mais precioso, é preciso prever o pior e planejarmos um processo de backup para que essas informações estejam seguras fora do nosso ambiente de trabalho.
Chuvas na região serrana...
No verão de 2011, quando deslizamentos de encostas assolaram a região serrana do RJ, diversas empresas foram afetadas e, muitas delas, tiveram suas instalações inundadas e destruídas.
As empresas que mantinham um backup consistente enfrentaram problemas, mas conseguiram restabelecer o acesso aos dados em pouco tempo.
Adquirir um novo servidor e providenciar um link em outra cidade é algo simples de se obter em poucos dias. Se o gestor dessas informações configurar um novo servidor e restaurar um backup atualizado, terá alcance às suas informações em tempo.
Até o Cloud da Amazon caiu...
A computação em nuvem vem ganhando cada vez mais destaque e, como toda tecnologia que ganha ares de celebridade, é alardeada como a cura para todos os problemas!
É notório que o serviço de cloud da Amazon está entre os melhores do mundo e, mesmo assim, em abril de 2011 o serviço ficou cinco dias fora do ar, afetando centenas de clientes e acarretando perda de informação para alguns (o número de clientes prejudicados não foi divulgado e há um grande esforço em manter esse número em sigilo).
Vale lembrar que o serviço EC2 da Amazon segue a filosofia de distribuir a nuvem entre datacenters geograficamente independentes (veja o exemplo a seguir para entender o que acontece quando a nuvem inteiro fica em apenas 1 datacenter) e, mesmo assim, o serviço caiu!
Os clientes que mantinham cópia de seus dados em local seguro tiveram a opção de aguardarem o sistema voltar e, se o problema persistisse, poderiam injetar seus dados em uma nuvem concorrente e restabelecerem seus sistemas. Já quem não tinha...
Pane elétrica na Alog-RJ...
Mesmo contando com no-breaks inteligentes e geradores plenamente funcionais, em julho de 2011 o datacenter da ALOG no RJ sofreu uma pane elétrica que acarretou em 2 dias de desligamento e inúmeras perdas de dados com corrupção de bancos de dados!
Diversas empresas mantinham infraestrutura no datacenter e, durante 2 dias, somente aquelas que possuíam um backup confiável conseguiram levantar seus serviços em outro datacenter e sustentarem suas aplicações online.
Nós mesmos passamos por essa situação!
Alguns de nossos serviços rodam em servidores que ficam nesse datacenter e, quando ocorreu o desastre elétrico, migramos os sites para nossa rede interna e levantamos com nosso backup. Para nossos clientes e funcionários nossas atividades operacionais passaram despercebidas, sendo notada apenas uma lentidão, já que nosso link interno não era tão largo.
Esse exemplo mostra que um servidor com fontes redundantes, diversos no-breaks e balanceamento de carga não valeria de nada em um desastre elétrico como esse!
Explosão em restaurante carioca prejudica 136 salas comerciais...
Em 13 de outubro de 2011, retorno de feriado, um acúmulo de gás provocou a explosão de um restaurante que funcionava no centro do RJ.
O restaurante ocupava o andar térreo de um edifício com 12 andares e 136 salas comerciais.
Desde então o edifício está LACRADO e, segundo a Defesa Civil do RJ, o edifício não será reaberto em 2011.
Nas 136 salas comerciais funcionavam empresas de contabilidade, advocacia, webdesign, representação comercial, etc...
Esse exemplo mostra que a preocupação não deve ser apenas em empresas grandes.
Todos os escritórios e microempresas que mantinham backup de suas informações foram surpreendidas com a explosão na volta de um feriado mas, bastando adquirir novos PCs, levantaram suas operações no mesmo dia.
Já as empresas que não tinham backup dos dados, mesmo não tendo qualquer ligação com o restaurante, viram seu negócio ruir quando não tiveram mais acesso ao prédio.
Prevenir ainda é melhor que remediar...
Comparar MTBF de marcas diferentes não é uma opção segura
Na postagem de hoje tentamos exemplificar com uma situação prática sobre um assunto mal compreendido: o MTBF de discos rígidos.
Tomando como exemplo que um disco rígido padrão de mercado apresenta MTBF de 500.000 horas, se dividirmos 500.000 por 24 horas chegaremos a 57 anos de ciclo de vida. Algum HD dura 57 anos? Certamente não!
MTBF
Mesmo sendo o artigo Wikipédia sobre MTBF pouco esclarecedor, ele elucida que o cálculo de MTBF envolve (além de incontáveis variáveis), uma metodologia baseada em estatística.
A indústria de discos rígidos, em geral, adotada uma amostragem de 1.000 peças, portanto, se montarmos um cenário de 1.000 HDs com MTBF de 500.000 horas, essas unidades terão uma estatística de 1 falha a cada 500 horas (ou seja, a cada 20,8 dias).
Na prática...
Em um parque de servidores com 1.000 HDs com MTBF de 500.000 horas - ou seja, com uma falha a cada 20,8 dias - e arbitrando um ciclo de vida de 3 anos (tempo de garantia do fabricante), teremos:
3 anos = 1095 dias de uso
1 falha a cada 20,8 dias (500 horas)
Total : 52 HDs falharão ao longo de 3 anos.
Taxa média de falha : 5% no ciclo de vida, ou 1,7% por ano.
Porém... Falha não é defeito...
Olhando a simulação acima o usuário pode pensar que o índice de RMA de HDs é de 5%.
Os índices de RMA da indústria são bem abaixo disso e, como demonstramos no exemplo, o acervo de 1.000 discos rígidos apresentou 5% de falhas no ciclo de vida, mas não de defeitos.
Falhas podem compreender eventos simples - como a perda do fluxo de gravação de um arquivo - até mesmo eventos críticos - como a quebra mecânica, levando à condenação da unidade.
Critérios proprietários
Infelizmente, para fins de comparação, o cálculo de MTBF não segue uma norma padronizada para toda a indústria de HDs.
Cada fabricante define seus critérios para medição de MTBF e, por isso, algumas marcas (menos criteriosas) apresentam estimativas de MTBF bem mais infladas para seus produtos. Isso gera uma expectativa de confiabilidade bem distinta entre modelos e marcas.
Critérios adotados pela Seagate®
Como trabalhamos exclusivamente com discos rígidos da Seagate®, os critérios de cálculo são padronizados pela fabricante para todas as linhas de produtos e, portanto, são válidos para comparação entre modelos diferentes do fabricante.
Todavia, como outros fabricantes adotam parâmetros distintos, não é válido comparar os valores apresentados para MTBF entre unidades Seagate® e unidades fabricadas por outras marcas.

Tomando como exemplo que um disco rígido padrão de mercado apresenta MTBF de 500.000 horas, se dividirmos 500.000 por 24 horas chegaremos a 57 anos de ciclo de vida. Algum HD dura 57 anos? Certamente não!
MTBF
Mesmo sendo o artigo Wikipédia sobre MTBF pouco esclarecedor, ele elucida que o cálculo de MTBF envolve (além de incontáveis variáveis), uma metodologia baseada em estatística.
A indústria de discos rígidos, em geral, adotada uma amostragem de 1.000 peças, portanto, se montarmos um cenário de 1.000 HDs com MTBF de 500.000 horas, essas unidades terão uma estatística de 1 falha a cada 500 horas (ou seja, a cada 20,8 dias).
Na prática...
Em um parque de servidores com 1.000 HDs com MTBF de 500.000 horas - ou seja, com uma falha a cada 20,8 dias - e arbitrando um ciclo de vida de 3 anos (tempo de garantia do fabricante), teremos:
3 anos = 1095 dias de uso
1 falha a cada 20,8 dias (500 horas)
Total : 52 HDs falharão ao longo de 3 anos.
Taxa média de falha : 5% no ciclo de vida, ou 1,7% por ano.
Porém... Falha não é defeito...
Olhando a simulação acima o usuário pode pensar que o índice de RMA de HDs é de 5%.
Os índices de RMA da indústria são bem abaixo disso e, como demonstramos no exemplo, o acervo de 1.000 discos rígidos apresentou 5% de falhas no ciclo de vida, mas não de defeitos.
Falhas podem compreender eventos simples - como a perda do fluxo de gravação de um arquivo - até mesmo eventos críticos - como a quebra mecânica, levando à condenação da unidade.
Critérios proprietários
Infelizmente, para fins de comparação, o cálculo de MTBF não segue uma norma padronizada para toda a indústria de HDs.
Cada fabricante define seus critérios para medição de MTBF e, por isso, algumas marcas (menos criteriosas) apresentam estimativas de MTBF bem mais infladas para seus produtos. Isso gera uma expectativa de confiabilidade bem distinta entre modelos e marcas.
Critérios adotados pela Seagate®
Como trabalhamos exclusivamente com discos rígidos da Seagate®, os critérios de cálculo são padronizados pela fabricante para todas as linhas de produtos e, portanto, são válidos para comparação entre modelos diferentes do fabricante.
Todavia, como outros fabricantes adotam parâmetros distintos, não é válido comparar os valores apresentados para MTBF entre unidades Seagate® e unidades fabricadas por outras marcas.
Fontes com PFC Ativo e certificação 80 Plus
A tolerância a um amplo espectro de tensões permite que essas fontes entreguem energia estável aos componentes de um servidor, independentemente da tensão de entrada (full range voltage suporta tensões de entrada desde 90V até 264V sem necessidade de comutação de chave alguma).
Além disso, fontes com PFC Ativo são mais resistentes a espúrios, transientes e surtos de tensão na entrada que fontes "normais".
RAID não é Backup!
É importante reforçarmos aos usuários que uma solução de RAID não é uma solução de BACKUP em si só! Uma estratégia de backup bem planejada - e cumprida à risca - é fundamental e indispensável em qualquer ambiente, seja empresarial, ou mesmo doméstico.
A Wikipédia precisa da sua ajuda para se manter livre? Ou deve ceder à propaganda?
A Wikipédia é grátis, mas custa U$20milhões por ano!
Seu fundador, Jimmy Wales, afirma sua postura contrária a inserir publicidade na Wikipédia:
Seu fundador, Jimmy Wales, afirma sua postura contrária a inserir publicidade na Wikipédia:
"O comércio é uma coisa boa. A publicidade não é malvada.
Mas não tem lugar aqui. Não na Wikipédia."
Mas não tem lugar aqui. Não na Wikipédia."
Assinar:
Postagens (Atom)












