Disaster Recovery para SAP utilizando

Disaster Recovery para SAP utilizando
BusinessShadow®
Agenda
Projeto de Disaster Recovery (DR)
Principais Arquiteturas de DR para SAP
Utilizando BusinessShadow® para DR do SAP
Credenciais e Contatos
Agenda
Projeto de Disaster Recovery (DR)
Principais Arquiteturas de DR para SAP
Utilizando BusinessShadow® para DR do SAP
Credenciais e Contatos
Porque realizar um projeto de Disaster Recovery?
 Aumento considerável da dependência dos processos de negócios em relação à TI
→ Ex.: Quais funções de negócios podem ser realizadas sem o SAP?
 Filiais comerciais no mundo possuem dependência da TI central
→ Ex.: Tragédia em Nova Orleans tem pouca relação com operações de negócios da empresa na Califórnia e América do Sul.
 Regulações / Legislações: SOX, Regulações da Bolsa de Valores, Basel II, …
→ Ex.: Problemas de responsabilidades, Perda de Dados da Produção...
 Ameaças devido a desastres naturais e outros incidentes
→ Risco / probabilidade de incêndios, inundações, terremotos, furações...
 Acessibilidade: Queda dos preços de HW, link e SW
→ A redução do investimento inicial e do custo operacional aumentam o ROI do projeto
Objetivos de um projeto de Disaster Recovery
Qualquer projeto de Disaster Recovery se inicia com as questões: “Em caso de desastre...
...qual a perda aceitável de dados?”
(Recovery Point Objective ou “RPO”)
...qual o tempo máximo até que o usuário
consiga acessar o sistema de contingência?”
(Recovery Time Objective ou “RTO”)
Os valores alvo RPO e RTO precisam ser determinados pela área de negócio e ponderados pelo
Retorno de Investimento do projeto de DR (quanto menor o RPO / RTO, maior o investimento).
Agenda
Projeto de Disaster Recovery (DR)
Principais Arquiteturas de DR para SAP
Utilizando BusinessShadow® para DR do SAP
Credenciais e Contatos
Envio de Fitas de Backup para Outro Site

Disaster Recovery com tradicionais fitas de backups

Estratégia cuja a maioria das empresas já utilizam como parte de seus procedimentos de backup

Uma fita de backup é utilizada para criar uma cópia completa da base de dados e arquivos SAP em intervalos
regulares.

Estas fitas são então enviadas para o site de DR definido
Vantagens



Alta integridade transacional
Proteção contra a corrupção de dados
Baixo custo de implantação
Desvantagens






Elevada perda de dados na incidência de desastre
(RPO)
Elevado tempo de restauração no site de DR (RTO)
Necessidade de equipe no site de DR
Riscos de erro humano (procedimento manual)
Sem estratégia fail-back
Custos altos com prestadores de serviços para
execução do DR
Replicação Storage Block-Based

A replicação Block-Based é um método/tecnologia de replicação dos dados através do cópia dos blocos de
disco de storage

Pode ser implementado usando dois sistemas de storage ou componentes SAN

Os produtos incluem SRDF (EMC), PPRC (IBM), CA (HP), SnapMirror (NetApp), Recovery Point (EMC), etc.

A replicação é tipicamente assíncrona para distâncias maiores do que 100 milhas entre os sites
Vantagens




Solução única para todas as situações
Produtos tipicamente estáveis, maduros
Pouca perda de dados na incidência de desastre
(RPO)
Independência do host server
Desvantagens










Solução única precisa se adaptar a todas as situações
Baixa integridade transacional
Requer storages idênticos
Elevados requisitos de rede de dados
Baixa amplitude de controle (span of control)
Recuperação manual ou shell scripts
Será possível levantar a base de dados?
Elevado esforço para realização de testes de DR
Sem possibilidade de definir ponto no tempo para
recuperação
Investimentos muito altos = Baixo ROI
Replicação Storage Block-Based
1º Desafio da Replicação Storage Block-Based: Integridade dos Dados
Alta Integridade
Transacional
SAP Application(s)
Online Logs
Data Files
Offline Logs
Database Level
Database
Files
Files
Files
File Level
Server / Operating System
Storage System / Storage Blocks
Storage Level
Baixa Integridade
Transacional

Replicação assíncrona “Storage Block-Based” garante apenas a integridade dos dados nos blocos de
disco, o que está longe de garantir a integridade dos banco de dados e dados SAP.

Após a ocorrência do desastre, a base de dados SAP estará em estado de shutdown não controlado
Replicação Storage Block-Based
2º Desafio da Replicação Storage Block-Based: Volume de Dados/Rede de Dados
volume de
dados será
replicado 3X
Clientes geralmente precisam reduzir a distância planejada para 1-20 milhas
Standby Databases

Standby Databases são ferramentas que vem com o banco de dados e permitem aos clientes a criação de
uma cópia do banco de dados

Algumas ferramentas são mais automatizadas que outras: ’Data Guard’ – Oracle; ‘HADR’ ou scripts
personalizados - DB2 (IBM); ‘Log Shipping’ - SQL Server (Microsoft); Scripts customizados - MaxDB (SAP)
Vantagens





Sem requisitos específicos de hardware
Ferramenta de base de dados gratuita
Poucos requisitos de rede de dados
Integridade transacional
Sem limitação de distancia
Desvantagens








Cobre apenas o base de dados e omite os flat-files
(Profiles? Java?)
Falta de otimização de rede
Complexo para configurar e operar (requer
intervenção manual)
Dependente 100% da equipe para operação e
failover
Não há suportes para ambientes mistos (SCM
LiveCache?)
Falta de recursos específicos para SAP
Sem estratégia fail-back
Aumento de complexidade com o número de
sistemas SAP
Porque existe a necessidade de uma alternativa?
Método
Principais Características
Envio de Fitas de Backup
para Outro Site

Alto tempo de recuperação, perda
potencial de dados, trabalho intenso,
risco de erro humano
Replicação SAN/blockbased

Alto custo, perda de integridade
transacional, elevados requerimentos
de rede de dados
Standby databases com
ferramenta nativa de BD

Não suporta plataformas múltiplas,
elevado consumo de tempo com
administração, intervenções manuais
Agenda
Projeto de Disaster Recovery (DR)
Principais Arquiteturas de DR para SAP
Utilizando BusinessShadow® para DR do SAP
Credenciais e Contatos
Arquitetura do BusinessShadow
A solução é composta por 4 módulos:
Site Espelho
Site Produção
SAP Database: Oracle,
MaxDB, DB2, SQL Server
SAP Flat Files: User
Profiles, Spool Files, etc.
SAP Host Name: IP
Address, NetBIOS, Host
DBShadow
(replicação log do banco de
dados)
FSShadow
(replicação flat files)
SwitchApplication
(controle dos servidores)
LongDistance
(módulo opcional para longas
distâncias)
SAP Database: Oracle,
MaxDB, DB2, SQL Server
SAP Flat Files: User
Profiles, Spool Files, etc.
SAP Host Name: IP
Address, NetBIOS, Host
Arquitetura do BusinessShadow (detalhes)
SAP GUI
Web
Browser
SAP Application Server(s)
SAP ABAP
App Server
Application Server(s)
SAP ABAP
App Server
SAP J2EE
App Server
SAP Central Instance Server
IP
SAP J2EE
CS
IP
SAP ABAP
CS
Files
SAP Standby Server
IP
IP
SQL Server, DB2,
Oracle, or MaxDB,
SQL Server, DB2,
Oracle, or MaxDB,
DBShadow®
FSShadow ®
SwitchApplication
CS = SAP System Central Services
SAP J2EE
App Server
SAP ABAP
CS
Files
IP
SAP J2EE
CS
IP
Garantia de Integridade dos Dados
SAP Application(s)
Online Logs
Data Files
Offline Logs
Database Level
Database
Files
Files
Alta Integridade
Transacional
Files
File Level
Server / Operating System
Storage System / Storage Blocks
Storage Level

O BusinessShadow garante a integridade do banco de dados e da aplicação.

Cobre os principais banco de dados: Oracle, MS SQL, MaxDB e DB2

Cobre todas as plataformas Unix e Windows
Baixa Integridade
Transacional
Redução dos Requisitos de Rede de Dados
Alta compressão dos
Archive Files
Produção
BusinessShadow PAS
Parallel Archive Shipping
TCP/IP
BusinessShadow VLP
Very Large IP Packages
Espelho


Pouca dependência do fator latência, permitindo replicação síncrona mesmo em longas distâncias. Motivos:

Otimização da transferência de dados (alta compactação; fragmentação dos dados; transmissão paralela)

Referência incremental das informações
Criptografia dos dados
Time-Funnel – Proteção dos Dados Replicados
Operação Normal
Mudanças em produção são enviadas
imediatamente para o site espelho,
mas precisam passar por um “timefunnel” antes de serem aplicados no
ambiente espelho.
Operação com Crash
Time-funnel
fechado
No caso de corrupção ou qualquer
outro acidente o “time-funnel” pode
ser fechado, impedindo que os dados
corrompidos sejam inseridos no site
espelho. Os usuários passam a acessar
o ambiente espelho enquanto o
ambiente de produção é corrigido.
Utilização do BusinessShadow
Disaster Recovery = Proteção contra falhas no site de produção
Após a ocorrência do desastre, BusinessShadow irá automaticamente recuperar os
arquivos de log remanescentes e ativar o sistema espelho.
Alta Disponibilidade = Proteção contra Erro de Usuário/ Software:
Após a identificação de erros de usuário/software, o BusinessShadow irá realizar a
recuperação automática em um ponto no tempo, antes da ocorrência do crash, e ativar
o espelho.
Atualização de Sistema
BusinessShadow pode ser usado para atualizar sistemas de QA / DEV / Sandbox a partir
de produção ou sistema espelho existente
Benefício Adicional: Downtime Planejado, ex.: Cenários de Evacuação, incluso
BusinessShadow pode reverter os papéis e a direção do “time-funnel”. O usuário
trabalha temporariamente no sistema secundário até voltar para a situação original.
Posicionamento do BusinessShadow (1/4)
Libelle
BusinessShadow
Log Shipping
Oracle DataGuard, DB2
HADR, MS Log Shipping.
Produtos
Replicação
Block-level
(hardware-based)
Continuos Access
PPRC, SRDF, Recovery
Point,…
Replicação
Block-level
(Software-based)
Double Take, Veritas
Volume Replicator, …
Solução baseada em
Server Agents no
host primário e
secundário
Característica do banco
de dados, ex.: Enterprise
Mgr.
Solução proprietária
de storage ou
aplicação SAN
Funcionalidades de
O/S de plataforma
baixa, servidor de
gerenciamento
Solução em Hardware
ou Software?
Software
Software
Hardware
Software
Por default
Necessidade de
componentes / redes
adicionais
Altos requisitos de
rede
Sim, mas cada banco
requer sua ferramenta
própria
Sim. Independe do
banco de dados.
Sim. Independe do
banco de dados.
Não
Sim. Espelhamento
completo do volume
Sim. Espelhamento
completo do volume
Permite longas
distâncias para DR
Por default
Sim. Suporta:
Suporte para banco de
Oracle, MaxDB, MS
dados
SQL Server, DB2
Sim. Suporte UNIX
Suporte para Flat File
e WINDOWS flat
files
Posicionamento do BusinessShadow (2/4)
Log Shipping
Replicação
Block-level
(hardware-based)
Replicação
Block-level
(Software-based)
Sim. Fornece
automação para IP fail
over
Não
Não
Alguns cobrem
Equipe SAP Basis ou
Banco de Dados
Equipe de Banco de
Dados
Equipe de Storage
Equipe de Storage
Responsável pelo SAP
failover
Equipe SAP Basis
Equipe SAP Basis
Equipe SAP Basis
Equipe SAP Basis
Host / Volume no site
espelho
Up
Up
Down
Down
Sim. Por Script
Não. Espelhamento
Assíncrono ou 10-20
minutos de buffering
dos dados (não é
controle do tempo
para espelhamento).
Não. Espelhamento
Assíncrono ou 10-20
minutos de buffering
dos dados (não é
controle do tempo
para espelhamento).
Cobre IP/Hostname
failover?
Gerenciada
tipicamente por
Controle de tempo
para espelhamento
dos dados
Libelle
BusinessShadow
Sim. Controle total do
tempo para
espelhamento dos
dados (por default).
Posicionamento do BusinessShadow (3/4)
Log Shipping
Block-level
Replication
(hardware-based)
Block-level
Replication
(Software-based)
Automatizado.
Incluindo várias
opções de tempo e
de log para o fail-over
Parcialmente
automatizado;
intervenção manual
necessária
Recuperação manual
de falhas
Recuperação manual
de falhas
Objetivos do Ponto
de Recuperação
Último arquivo de
Log (ex. 15 minutos)
Último arquivo de
Log (ex. 15 minutos)
Normalmente < 1 até
5 minutos
Normalmente < 1 até
5 minutos
Requerimentos de
Rede
Muito baixo
Baixo
Alto
Alto
Sim. Na camada de
banco de dados.
Sim. Na camada de
storage LUN , porém
o banco de dados de
produção precisa
estar configurado
para iniciar modo de
backup
Sim. Na camada de
storage LUN , porém
o banco de dados de
produção precisa
estar configurado
para iniciar modo de
backup
Fail-Over
Backup dos dados de
produção no servidor
de espelho
Libelle
BusinessShadow
Sim. Na camada de
banco de dados e
com automatização
via GUI
Posicionamento do BusinessShadow (4/4)
Libelle
BusinessShadow
Uso para atualizações
em QA / DEV
Verificação de
integridade
Failover Seletivo
Verificação de
Integridade com o
banco de dados
Investimento
Log Shipping
Fácil. Apenas na
camada de banco de
dados
Permanente (aplicado
Permanente (aplicado
para todo arquivo de
a todo arquivo de log
log através da
através da instância
instância de banco de
de banco de dados)
dados)
Fácil e automatizado
via GUI
Por sistema SAP
Somente por Banco
de Dados
Mecanismos de
Mecanismos de
backup e recuperação backup e recuperação
dos arquivos de log
dos arquivos de log
Software e
Implementação
Consultoria para
scripts e recursos
para manutenção
Block-level
Replication
(hardware-based)
Block-level
Replication
(Software-based)
Manual
Manual
Em conseqüência da
incidência de
desastre
Em conseqüência da
incidência de
desastre
Somente o volume de Somente o volume de
storage completo
storage completo
Nenhum
Nenhum
Investimentos com
overhead de
hardware e rede
Software e
Implementação
Interface: BusinessShadow® 5.0
Agenda
Projeto de Disaster Recovery (DR)
Principais Arquiteturas de DR para SAP
Utilizando BusinessShadow® para DR do SAP
Credenciais e Contatos
Consumidores Globais BusinessShadow
 Mais de 300 clientes no mundo
 Mais de 1,000 instalações de DBShadow® no mundo
 BusinessShadow® Certificado pela SAP em 2005
 SAP Walldorf utiliza BusinessShadow através do SAP Hosting
 Relacionamento com Departamento de Desenvolvimento do MaxDB na SAP Berlin
Entre em contato conosco
Contatos
Profits Consulting
www.profitsconsulting.com.br
[email protected]
+55 (21) 4105-5441