Planejamento de Capacidade e Desempenho de Backup em Disco

Proibida cópia ou divulgação sem permissão escrita do CMG Brasil.

Artigo

Kleber José da Silva Brasil ICT – 07/08/2013

PLANEJAMENTO DE CAPACIDADE E DESEMPENHO DE BACKUP EM DISCO


Agenda 1. Introdução

2. Contexto

3. Conceitos de Backup

4. Trabalhos relacionados

5. Integridade e Janela de Backup

6. Estudo de Caso

7. Desempenho

8. Trabalhos futuros

9. Conclusão


Nesse artigo será apresentado um estudo

de planejamento de capacidade e

desempenho da utilização de Storage para

Backup em disco. Algumas funcionalidades

como Snapshots, Desduplicação e

Compressão de dados serão abordadas,

com o objetivo de avaliar esse novo método,

comparando com o backup tradicional em

fita, a fim de fornecer subsídios na escolha

ou substituição de um método por outro.

1 - Introdução


2 - Contexto

Backup de Servidores, físicos ou virtuais.

A aplicação deve ser considerada no método,

para garantir a integridade do Backup.


3 – Trabalhos relacionados

[TOME01] Antonio Valceni de Oliveira Tomé et al;

“Comparação do Desempenho entre Ferramentas

de Código Livre para a Realização de Backups”,

Artigo, Universidade Federal de São Carlos (2012):

- O artigo comparou o desempenho de backup e

restauração de algumas ferramentas gratuitas no

método tradicional de cópia completa (full) e então

incremental. O comando nativo TAR do linux obteve

o melhor resultado.


4 – Conceitos de Backup

• Um backup é uma cópia ou

uma versão dos arquivos que

deve ser criada para garantir a

restauração em caso de falha.

• Uma falha pode ser desde

uma corrupção de arquivos,

falha de hardware, sinistros

(incêndio, enchentes,

meteoro, etc) até erro de

usuário (deleção acidentais,

exclusão de arquivos, má

aplicação de atualizações)


4.1 – Escopo do Backup

• Backups lógicos: Que contêm dados e/ou

definições de objetos. Ex.: uma exportação

realizada por ferramentas específicas de cada

sistema nos servidores. No caso de banco de

dados, ele gera um arquivo binário com as

definições de estrutura, índices, e dados para

importação.

• Backups físicos: Contém uma imagem

completa dos arquivos físicos do servidores.

Ex.: Arquivos de dados e logs de servidores de

banco de dados = data1.dbf e log1.dbf. Pode

ser feito por um software de backup ou alguma

funcionalidade no servidor ou storage.


4.2 – Métodos de Backup

a) Backup em fita: é o tipo de backup tradicional que a maioria

das empresas tem usado por anos. É composto por:

Servidor com Software de Backup de um fornecedor

especializado ou em raros casos uma ferramenta nativa do S.O.

Agentes de Backup instalados nos demais servidores

Biblioteca de Fita (tape library) conectada a um servidor de

mídia (media server)



a) Backup em fita:



b) Backup em disco: com a redução dos custos de discos

magnéticos e aumento de sua capacidade (discos SATA), surgiu

como alternativa a possibilidade de utilização desses ao invés

das fitas, em duas opções

b.1 - Virtualizador de Fita

(VTL – Virtual Tape Library):

utiliza os mesmos

componentes do backup em

fita e o servidor de backup

emula a VTL como se fosse

um biblioteca física.



b.2) Solução de Softwares e Storage SATA: neste caso, o

software de backup foi projetado para armazenar os dados no

próprio Storage sem necessidade de emulação de biblioteca,

com tecnologia de Snapshots.

Ambas soluções baseadas

em disco possuem

tecnologia de

desduplicação de dados,

que apresentam vantagens

de economia de espaço em

relação ao backup em fita

que possuem normalmente

a compressão.

Alternativa: armazenar o Backup na nuvem.


4.2.1 – Desduplicação

A seguir, um exemplo com desduplicação no nivel de blocos

(4KBytes). OBS.: No nivel de arquivos seria diferente.


4.2.1 – Desduplicação Moe’s presentation.ppt

20 x 4K blocos

Larry’s presentation.ppt

Arquivo idêntico: 20 x 4K blocos

Curly’s presentation.ppt

Arquivo editado: 25 x 4K

blocos

Shemp’s resume.doc

Arquivo diferente: 10 x 4K blocos

= Blocos Idênticos

Dados gravados em Disco:

Com desduplicação: 38 blocos

Sem desduplicação: 75 blocos


5 – Integridade e Janela de Backup

• Backups não íntegros: Feitos com a base de dados

ou máquina virtual aberta e gerando transações nos

arquivos de dados. Neste caso não há garantia de

recuperação dos dados, ou seja, não devem ser

considerados. Essa forma é indicada apenas para

servidores de arquivos ou servidores web que não

mantém relação de consistência entre eles.


5 – Integridade e Janela de Backup

• Backups íntegros: Feitos com a base de dados ou

máquina virtual “desligada” (backup consistente ou backup

cold) ou em modo backup online (backup inconsistente).

• Deve-se fazer um backup sem que a base esteja com

transações ativas (backup cold) ou com os arquivos de

dados intactos (backup online), garantindo assim que todas

as transações previamente realizadas estejam

consistentes.

• Um pré-requisito para executar o backup online é que a

aplicação suporte esse modo. OBS.: O Oracle é um SGBD

que suporta esse modo com a habilitação dos archivelogs.


5.1 – Janela de Backup Janela de Backup: define o tempo que o processo (job) de

backup gastou para ser concluído. Esse tempo é proporcional

ao tamanho da base de dados ou da máquina virtual e a

velocidade de cópia dos dados.

- Quanto maior for a

base de dados e mais

lento o dispositivo de

armazenamento do

backup, maior será a

janela de backup, o que

pode implicar em

percepção de lentidão

para o usuário final.


5.2 – Snapshots • Backups Snapshots: uma alternativa para reduzir janelas de

backups, alguns sistemas operacionais e storages suportam a

tecnologia de Snapshots para serem usados como backup

(versões) no próprio armazenamento principal.

- Não é gasto tempo de

cópia para um outro

dispositivo no

momento do backup

(pode ser feito

posteriormente,

independente do

estado do banco ou

máquina virtual).


5.2.1 – Tipos de Snapshots

Snapshot 1

D’ A B C D

FileSystem ativo

Bloco em

Disco

Cria ponteiros, não dados

Snapshot

I/O

0 Meter

1

A B C D

FileSystem ativo

Blocos em

Disco

Snapshot 1

D D’

Copia dados

Area de Snapshot

I/O

0 Meter

1 2 3 4 5

• Snapshot baseados em

ponteiros • Snapshot baseados em

cópia na escrita (copy-on-

write)

• Em ambos: não há conceito de full + incremental como em fita.

Novos snapshots são relacionais ao criado anteriormente.


6 – Estudo de Caso Aplicação: Um ambiente com servidores de banco de

dados SQL responsável por vários serviços públicos,

dentre eles a emissão de notas fiscais e guias da

prefeitura de uma cidade do estado de SP.

Infra: Servidores físicos, switches Ethernet e Storage

iSCSI alocados em um Data Center na grande São

Paulo. Capacidade física dos BDs: 2TB

Cenário anterior do backup: Serviço de backup

terceirizado no Data Center. Frequencia: 1x por dia.

Retenção: 1 ano (backup semanal). SLA para

restauração: 8h + tempo de aplicação de archiving logs

do banco de dados sob responsabilidade do cliente.


6 – Estudo de Caso Novo cenário de backup: Aquisição de um novo

Storage com discos SATA alocado em outro Data

Center, com conectividade TCP/IP com o anterior.

- Software de gerenciamento do Backup instalado em

um servidor virtual, com conectividade em ambos DC

- Configuração de política de Backup em Snapshots

dos logs do BD a cada 2h, durante horário comercial, e

1 backup online dos datafiles do BD às 18h,

armazenados no Storage SAS e no SATA.

- Retenção: armazenamento do backup no Storage

SATA: das 18h diario por 7 dias, semanal por 4

semanas e mensal durante 24 meses.


6.1 – Topologia

Storage

SAS

Storage

SATA

Backup

1 dia de

snapshots

1 ano de

snapshots

DC 1 DC 2


6.2 – Capacidade

Consumo de espaço de 1 volume secundário (SATA)

===== DF –g =====

Filesystem Gbytes used

/vol/SnapMgr_SQLServer_SBSQL01_backup_1/ 939G 432G

/vol/SnapMgr_SQLServer_SBSQL01_backup_1/.snapshot 232G (53%)

Snapshots consumindo 53% da área de produção para 1 e 1/2

ano de Backup = Desduplicação + Compressão + Granularidade

no nivel de Blocos (e não de arquivos).


6.3 – Custo Antes da implementação desse projeto, a empresa

avaliou outras soluções de Backup tradicional em Fita,

porém o custo seria equivalente devido a maior

capacidade necessária de fitas, mesmo estas sendo

mais baratas que o Storage com discos SATA.

Atualmente já estão disponíveis os discos SATA de

3TB que facilitam a competição de custo com as

bibliotecas de fita.

Um fato que encarece a solução de fita é o custo da

licença de agente de backup de sistemas de arquivos

para cada servidor, o que normalmente não é cobrado

na solução de software e storages SATA.


7 – Desempenho

Horas

Recuperação de Fita

Log

Minutos

Snapshot Full I I I Log

Recuperação de Disco

Processo com

procedimentos manuais

Mais demorado e a fita

apresenta risco de se

danificar com o tempo

7.1 - Restauração

Processo com procedimentos

feitos no gerenciador de bkp

Recuperação mais rápida.

Disco é uma mídia mais

confiável


7.2 – Incremental Arquivos x Blocos

Disco

20TB

1 Day

20TB

Storage

Minutos

Horas

Fita

Copia 20GB

Blocos alterados

Copia 2TB

Arquivos alterados

Fita ou Storage

7 – Desempenho


7 – Desempenho 7.3 – Otimização de WAN

Um dos pontos que podem prejudicar o desempenho

de uma solução de backup em disco, quando há a

exigência de manter o Storage SATA em um site

secundário, é o desempenho do Link WAN.

Como complemento da solução nestes casos, pode-se

utilizar softwares ou appliances de otimização de WAN

nos dois lados para dar a percepção de rede local

entre origem e destino, por meio dos mecanismos de

cache e compressão destes.


8 – Trabalhos futuros • Analisar mecanismos de segurança a serem

implementados no método de backup em

disco como encriptação de Storage,

comparando o impacto de desempenho.

• Estudar e desenvolver uma fórmula para

calcular a retenção x custo benefício da

solução de fita ou disco ou nuvem.

• Pesquisar se há soluções similares para o

ambiente de alta plataforma e avaliar se

haveria algum benefício.


9 – Conclusão -Pelas comparações apresentadas, o backup em disco

aparenta ser a opção mais eficiente.

-A escolha pela implementação de backup em disco ou

fita depende de outros fatores a considerar:


9 – Conclusão

Retenção dos dados. Se a necessidade é manter o

backup por mais de 2 anos com uma probabilidade

baixa de restauração de dados antigos, o backup em

fita pode se tornar uma solução mais barata. Neste

caso, deve-se analisar uma arquitetura híbrida com a

retenção dos backup em disco durante os primeiros

meses, e depois para fita até o final do prazo.

Operação. O backup em fita gera mais trabalho por

parte do operador de Backup no manuseio das fitas na

tape library


9 – Conclusão Garantia. O Storage utilizado para backup em disco

deve estar sempre sob suporte e garantia, enquanto

que no backup em fita, apenas a tape library, as fitas

não possuem essa necessidade.

Cenários. Deve-se avaliar cada cenário específico

pelas suas aplicações e necessidades do negócio da

organização. Nem sempre o melhor para um é o

melhor para outro.


Technology

Planejamento de Capacidade e Desempenho de Backup em Disco