Disaster Recovery para SAP utilizando BusinessShadow

(1)

(2)

Agenda

Projeto de Disaster Recovery (DR)

Principais Arquiteturas de DR para SAP

(3)

Agenda

Projeto de Disaster Recovery (DR)

Principais Arquiteturas de DR para SAP

(4)

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

(5)

Objetivos de um projeto de Disaster Recovery

...qual o tempo máximo até que o usuário

consiga acessar o sistema de contingência?”

(Recovery Time Objective ou “RTO”)

...qual a perda aceitável de dados?”

(Recovery Point Objective ou “RPO”)

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).

(6)

Agenda

Projeto de Disaster Recovery (DR)

Principais Arquiteturas de DR para SAP

(7)

Desvantagens

Vantagens

 _{Alta integridade transacional}

 Proteção contra a corrupção de dados  Baixo custo de implantação

 _{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

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.

(8)

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

 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

 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}

(9)

 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}

Baixa Integridade

Transacional

Alta Integridade

Transacional

Storage System / Storage Blocks Server / Operating System

SAP Application(s) Database Data Files Online Logs Offline Logs Files Files Files Storage Level File Level Database Level

1º Desafio da Replicação Storage Block-Based: Integridade dos Dados

(10)

Clientes geralmente precisam reduzir a distância planejada para 1-20 milhas

volume de

dados será

replicado 3X

2º Desafio da Replicação Storage Block-Based: Volume de Dados/Rede de Dados

(11)

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)

 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

 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

(12)

Porque existe a necessidade de uma alternativa?

Método

Principais Características



Alto tempo de recuperação, perda

potencial de dados, trabalho intenso,

risco de erro humano



Alto custo, perda de integridade

transacional, elevados requerimentos

de rede de dados



Não suporta plataformas múltiplas,

elevado consumo de tempo com

administração, intervenções manuais

Envio de Fitas de Backup

para Outro Site

Replicação

SAN/block-based

(13)

Agenda

Projeto de Disaster Recovery (DR)

Principais Arquiteturas de DR para SAP

Utilizando BusinessShadow® para DR do SAP

(14)

SAP Database: Oracle,

MaxDB, DB2, SQL Server

SAP Flat Files: User

Profiles, Spool Files, etc.

SAP Host Name: IP

Address, NetBIOS, Host

SAP Database: Oracle,

MaxDB, DB2, SQL Server

SAP Flat Files: User

Profiles, Spool Files, etc.

SAP Host Name: IP

Address, NetBIOS, Host

Site Produção

Site Espelho

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)

Arquitetura do BusinessShadow

(15)

Arquitetura do BusinessShadow (detalhes)

SAP Central Instance Server

Application Server(s)

SQL Server, DB2, Oracle, or MaxDB,

SAP GUI

CS = SAP System Central Services SAP Application Server(s)

SQL Server, DB2, Oracle, or MaxDB, SAP ABAP App Server Web Browser SAP J2EE App Server SAP ABAP App Server SAP J2EE App Server SAP ABAP CS IP SAP ABAP _CS IP Files SAP J2EE CS IP SAP J2EE _CS IP Files IP IP

SAP Standby Server

(16)

Garantia de Integridade dos Dados

 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

Alta Integridade

Transacional

Storage System / Storage Blocks Server / Operating System

(17)

Espelho Produção

Alta compressão dos Archive Files

BusinessShadow PAS Parallel Archive Shipping

BusinessShadow VLP Very Large IP Packages

TCP/IP

Redução dos Requisitos de Rede de Dados

 _{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

(18)

Time-Funnel – Proteção dos Dados Replicados

Mudanças em produção são enviadas imediatamente para o site espelho, mas precisam passar por um “time-funnel” antes de serem aplicados no ambiente espelho.

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.

Time-funnel

fechado

Operação Normal

(19)

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.

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.

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.

(20)

Libelle

BusinessShadow Log Shipping

Replicação Block-level (hardware-based) Replicação Block-level (Software-based)

Produtos Oracle DataGuard, DB2

HADR, MS Log Shipping.

Continuos Access PPRC, SRDF, Recovery

Point,…

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 Permite longas

distâncias para DR Por default Por default

Necessidade de componentes / redes

adicionais

Altos requisitos de rede

Suporte para banco de dados

Sim. Suporta: Oracle, MaxDB, MS

SQL Server, DB2

Sim, mas cada banco requer sua ferramenta

própria

Sim. Independe do banco de dados.

Suporte para Flat File

Sim. Suporte UNIX e WINDOWS flat

files

Não Sim. Espelhamento completo do volume

Sim. Espelhamento completo do volume

(21)

Libelle

Replicação Block-level (hardware-based) Replicação Block-level (Software-based) Cobre IP/Hostname failover? Sim. Fornece automação para IP fail

over

Não Não Alguns cobrem

Gerenciada tipicamente por

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

Controle de tempo para espelhamento dos dados

Sim. Controle total do tempo para espelhamento dos dados (por default).

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).

(22)

Libelle

Block-level Replication (hardware-based) Block-level Replication (Software-based) Fail-Over 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

Requerimentos de

Rede Muito baixo Baixo Alto Alto

Backup dos dados de produção no servidor de espelho Sim. Na camada de banco de dados e com automatização via GUI 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

(23)

Libelle

Block-level Replication (hardware-based) Block-level Replication (Software-based) Uso para atualizações

em QA / DEV Fácil e automatizado via GUI Fácil. Apenas na camada de banco de dados Manual Manual Verificação de integridade Permanente (aplicado a todo arquivo de log

através da instância de banco de dados)

Permanente (aplicado para todo arquivo de

log através da instância de banco de dados) Em conseqüência da incidência de desastre Em conseqüência da incidência de desastre

Failover Seletivo Por sistema SAP Somente por Banco de Dados Somente o volume de storage completo Somente o volume de storage completo Verificação de Integridade com o banco de dados Mecanismos de backup e recuperação