Arquivo da tag: Storage

Quando os cães não caçam

Sabe aquele dito popular, “quem não tem cão caça com gato”? Em tecnologia, às vezes os gatos podem aprender e caçar melhor que os cães.

O senso comum nos diz que quando alguém tem uma boa parte de um mercado, acaba tendo mais recursos para lançar inovações nesse mercado. Recursos como conhecimento do mercado, rede de relações, propriedade da tecnologia e marca. Só que o senso comum não leva muito em consideração que empresas que estão em uma situação confortável acabam ficando mais… confortáveis, vamos dizer assim. Elas estão vendo os sacos de dinheiro entrando pela porta da frente, estão vendo que tem uma parcela de investimento indo para o pessoal de pesquisa e desenvolvimento de produtos, então todo mundo fica feliz.

Nos últimos anos, duas empresas grandes resolveram que queriam mercados diferentes do que já tinham e resolveram inovar e partir para cima do pessoal que já domina a área. Os gatos inovando para tentar caçar melhor que os cães.

O primeiro caso já tem alguns anos, que são os serviços de hosting de storage (S3) e de servidores (EC2) da Amazon. A Amazon é uma empresa grande, uma marca forte… como loja online, principalmente de livros. De repente eles resolveram vender como serviço muitas das tecnologias que eles mesmo utilizam para fazer funcionar um dos sites mais famosos do mundo. E está aí, hoje você pode contratar espaço em storage ou configurar um servidor virtual lá na Amazon, o que diminui brutalmente os custos para empresas que não tem como investir em um CPD. A Amazon saiu bem na frente de muitos provedores de hosting para servidores, gente que teoricamente poderia ter pensado nesse  modelo de negócios.

O segundo caso é bem mais recente e ainda está meio nebuloso. A Cisco está fazendo um barulho anunciando que vai entrar no mercado de servidores x86. Um nome muito tradicional quando se fala em equipamentos de rede, a Cisco vai lançar em breve um servidor blade desenhado para aproveitar melhor recursos de virtualização e cloud computing, para bater de frente com os grandes. Ainda não foram revelados muitos detalhes sobre o produto, e porque ele seria tão competitivo em relação aos concorrentes. Mas nós vamos descobrir em breve se esse negócio de esconder o jogo é só para fazer barulho sem na verdade ter algo realmente inovador ou se vamos ver o mercado de servidores se redesenhando este ano.

Enquanto isso nós ficamos aqui esperando a Sony lançar um carro ou o Google lançar um plano de saúde.

P.S.: Reparem que os dois casos citados estão fortemente ligados à virtualização, mostrando que ainda é um assunto quente.
Anúncios

Storage Area Networks e frigideiras de peixe

Quando os discos internos dos servidores começaram a se tornar um gargalo para o crescimento de alguns sistemas, os engenheiros tiveram a idéia de montar discos externos em dispositivos separados e ligar os servidores com essas máquinas que rodavam os discos. Nesse dia nasceram as Storage Area Networks, mais conhecidas como SAN´s.

A arquitetura mais popular de SAN utiliza o protocolo FCP (Fibre Channel protocol), em que o cabeamento é realizado com cabos de fibra ótica e a “língua” utilizada para conversar nessa rede é SCSI (a mesma utilizada pelos discos SCSI que são ligados diretamente/internamente nos servidores). Normalmente, para simplificar o gerenciamento da estrutura física, são instalados switches de fibra entre os servidores e o storage.

Uma SAN dentro da elipse

Uma SAN dentro da elipse

Para quem lida com redes de computador deve ficar bem óbvia a semelhança com a arquitetura mais comum em redes Ethernet + TCP/IP. O switch de fibra é um primo não muito distante, e que fala outra língua, do switch Ethernet. Os cabos de fibra são os equivalente aos cabos de cobre ou par trançado. A placa HBA é equivalente à placa de rede (e deveria ter um nome mais intuitivo também, como placa de storage ou algo assim).

Mas se as arquiteturas são tão parecidas, porque afinal esses engenheiros reinventaram a roda? Porque não se utiliza a infraestrutura de rede para criar SAN´s? Na verdade existem alternativas que utilizam a infra de rede Ethernet para criar SAN´s, onde o padrão mais utilizado é o iSCSI. Mas quando as empresas começaram a utilizar SAN´s FC, as redes TCP/IP ainda não eram tão confiáveis e nem tinham muita performance. Os engenheiros queriam uma solução que fosse desenhada para operações de I/O para discos, não queriam a gordura que existe nos protocolos de rede e ainda por cima usar uma mídia física que gerasse uma taxa de transferência muito melhor. E por isso reinventaram a roda. Simplesmente fizeram uma roda especialmente para um tipo de estrada.

É aí que entra uma história que um amigo meu me contou uma vez sobre sua avó. A avó dele, sempre cortava o peixe em pedaços menores antes de colocar na frigideira para fritar. Ele então perguntou o porquê disso, já que não via uma razão aparente. A avó dele respondeu rapidamente que ela sempre cortava o peixe em pedaços porque antigamente todas as panelas que utilizava para fritar peixe eram muito menores. Por força do hábito, depois de tantos anos cortando o peixe para que pudesse ser frito, ela continuou preparando o peixe daquele jeito, e talvez nem percebesse que estava fazendo isso.

E é o que eu acho que acontece hoje com SAN´s. Hoje os dispositivos, software e protocolos de redes Ethernet e TCP/IP estão muito mais confiáveis. Hoje já temos o padrão de Ethernet com velocidade de 10 Gbps (a velocidade máxima da fibra ainda é de 8 Gigabits por segundo). É muito mais fácil resolver problemas em redes, já que existem muito mais ferramentas para isso. É muito mais fácil montar uma equipe para cuidar da sua infraestrutura, porque é difícil encontrar profissionais que sejam muito bons para lidar com SAN de fibra (e provavelmente na sua equipe já existem várias pessoas que sabem lidar com redes).

Óbvio que alguns fabricantes de hardware e gerentes de infraestrutura de TI vão defender com unhas e dentes as soluções de fibra. Mas os primeiros são como os fabricantes da faca para cortar o peixe. E os últimos, como a avó do meu amigo.

Evolução do backup de banco de dados

A principal razão para quedas de cabelos e noites mal dormidas de DBAs e System Engineers, quando o assunto é banco de dados, é com certeza o backup. Dependendo de como é feito, o backup pode gerar muita dor de cabeça mesmo quando está funcionando bem. E custar alguns empregos se não funcionar (e claro que as pessoas só descobrem isto quando precisam restaurar alguma coisa).

Reação de DBA quando perguntada sobre o backup

Reação de DBA quando perguntada sobre o backup

Os principais problemas (e RISCOS) relacionados aos métodos de backup de bancos de dados atualmente são:

  • Janela de backup: a execução de backup precisa começar e terminar dentro de um certo período de tempo. Porém, dependendo da carga no banco de dados, velocidade do storage, rede, da forma como os dados são jogados para fita ou área de armazenamento de backup, etc., um job de backup pode acabar levando tanto tempo que acaba sendo executado em horários em que o sistema está em produção, ou seja, acaba afetando a performance dos servidores e sistemas que utilizam o banco. Nos piores casos pode até chegar a mais de 24 horas, inviabilizando a execução de backups diários e tornando o risco de perder dados críticos seu companheiro de trabalho permanente.
  • Tempo para recuperação: Shit happens, e quando o pior acontece você precisa rezar para aquela fita com o último backup full esteja funcionando direitinho. Só que em alguns casos, cada minuto em que o sistema fica fora do ar, é dinheiro que está escoando pelo ralo, são clientes perdidos, é credibilidade descarga abaixo. E restaurar backups de fita sempre vão levar muitos minutos, às vezes horas. Mesmo que o cliente possa fazer restaurações demoradas sem perder dinheiro, esse é o tipo de tarefa capaz de gerar úlceras de preocupação nos donos dos dados e no pobre do operador de backup (que usa o tempo de restore para enviar currículos caso a tarefa não seja bem sucedida).
  • Confiabilidade: Mesmo que tenham melhorado muito, backups em fita, que ainda são a principal forma de armazenar backups, não são confiáveis o suficiente. Pelo menos não o suficiente para que um DBA não se apavore caso precise da fita. E como um restore normalmente leva muito tempo e pode precisar de várias fitas, você pode demorar muito tempo para descobrir que está ferrado.
  • Ponto de recuperação: O quanto de seus dados você pode perder? Óbvio que a maioria das pessoas vai responder que não pode perder nada, mas isso não é uma expectativa realista. Em caso de um problema com seu banco de dados (como um ataque de rinocerontes em seu data center), alguns dados, os dados mais recentes, você vai perder. Ou eles acabam não indo para o backup por serem extremamente recentes, ou não houve tempo para replicá-los no banco de dados espelho. A frequência de seus backups e a forma como você planeja seu DR (disaster recovery) podem definir o quanto você vai perder. O problema é que normalmente é simplesmente inviável aumentar a frequência dessas operações.

Isso ainda é verdade tanto para bancos de dados mais “maduros”, como o Oracle, quanto para bancos que estão amadurecendo, como o SQL Server da Microsoft. Isso sem falar em MySQL, Sybase, DB2, PostgreSQL e outros mais obscuros. Realizar backups com todos estes problemas já é prática a tanto tempo, que a maioria das pessoas nem cogita outras possibilidades. É a operação padrão, ao projetar um sistema com um banco de dados, a equipe de TI automaticamente se prepara para montar todo esse esquema.

Mas graças a Santo Isidoro, hoje existem maneiras muito melhores para acabar com esses problemas, para transformar o backup em uma brisa ao invés de um inferno. O grande problema é que estas formas mais evoluídas  não são muito conhecidas, mesmo por DBAs e administradores de storage. Mas para entender porque isso representa uma grande evolução na forma de se fazer backup, precisamos fazer uma rápida revisão sobre os métodos ultrapassados.

  • Pré-história: A forma mais primordial consistia em desligar o banco de dados, realizar o backup e depois colocar o banco no ar novamente. Porém muitos sistemas não podem ser simplesmente desligados todo dia por várias horas (pelo menos é o que os pacientes de hospitais informatizados preferem acreditar). Outra forma é um dump lógico dos dados, extrair os dados do banco para um arquivo que pode ser importado caso fosse necessário restaurar os dados. Isto gera dados com um tamanho que pode ser bem maior que o banco de dados original, problemas de formatos na recuperação e impacto de performance. Ainda são formas utilizadas para bancos menores e menos importantes.
Métodos antigos de backup de BDs

Métodos antigos de backup de BDs

  • Atual mas ultrapassado: Hoje existe uma proliferação de softwares para backup, com integração com storage e dispositivos de fita, com automatização do processo de backup, possibilidade de realizar backups incrementais para diminuir as janelas de backup, luzinhas piscando para todos os lados, etc.. Os grandes problemas são os custos dessas soluções, a fauna bastante diversificada de software que precisa ser instalada nos clientes para integrar tudo, necessidade de técnicos que praticamente tem PhD em backup, além de não resolver muito bem as 4 grandes questões já citadas: janela de backup, tempo para recuperação, confiabilidade e ponto de recuperação. Obviamente muito melhor que os métodos pré-históricos, mas ainda geradores de dor de cabeça.
Métodos atualmente mais usados

Métodos atualmente mais usados

O futuro!

Como o backup deveria ser

Como o backup deveria ser

Hoje, com a ajuda de hardware altamente integrado com software, é possível realizar backups de bancos de dados e superar os 4 cavaleiros do apocalipse do backup (também conhecidos como os 4 problemas anteriormente citados). Vou falar mais especificamente do storage da NetApp, mas existem alternativas. Como não conheço bem as alternativas, não posso me pronunciar sobre a qualidade dessas soluções.

Storage NetApp família FAS3100

Storage NetApp família FAS3100

Basicamente a solução de seus piores pesadelos envolve armazenar seu banco de dados em uma dessas máquinas. Além delas terem uma performance muito boa para bancos de dados ( e estou tomando o Oracle como referência), elas já vêm de fábrica com alguns truques muito espertos para facilitar o backup (aliás, não só de bancos de dados). Não vou entrar em detalhes de quais são os grandes truques para que isto funcione desta forma (talvez em posts futuros), mas já aviso aos que não conhecem NetApp tudo o que eu disser vai parecer um exagero, o tipo de mentira que o pessoal de marketing gosta de contar, mas asseguro que é tudo de verdade e que muitos clientes (incluindo a própria Oracle) utilizam este tipo de solução.  Ok, vamos aos fatos que vão te fazer parar de sofrer com a menção da palavra “backup”.

  • Janela de backup: Imagine conseguir realizar backups full de seu banco de dados em menos de 2 minutos, mesmo que ele tenha TeraBytes de dados. Imagine realizar diversos backups full ao longo do dia. E imagine que isso não envolve copias brutas de todos os dados e tenha um impacto imperceptível no banco de dados e no storage. Tudo isso é real e possível! As palavras chaves para este truque são NetApp e Snapshot!
  • Tempo para recuperação: Da mesma forma que o backup é feito em um piscar de olhos, a recuperação também é muito rápida. Você nunca mais vai precisar passar a noite inteira rezando um terço do lado de seu servidor pedindo para que a recuperação de seu banco de dados corrompido funcione. A recuperação é tão rápida que você só tem tempo para uma “Ave Maria”.
  • Confiabilidade: O storage possui diversos mecanismos de hardware e software para garantir a integridade dos dados: RAID-DP, checagem e realocação de bad blocks, memória NVRAM com bateria, Snapshots, cluster ativo-ativo, replicação para outro storage. Além disso, quando se fala em Oracle, o NetApp é o storage mais barato que implementa o Oracle HARD.
  • Ponto de recuperação: Como os backups podem ser realizados com maior frequência, a probabilidade de perder dados em caso de algum problema no banco é bastante diminuída.
  • Hoje o NetApp possui softwares para integração com Microsoft SQL Server e Oracle (sem falar em Exchange, SAP e VMware). Mesmo assim, não é coisa do outro mundo integrá-lo com um MySQL ou outro banco por exemplo. Para ver o SnapManager para Oracle em funcionamento, assista o seguinte vídeo feito pelo Neto da NetApp.