Whitepaper business shadow_portugues

White Paper

Alta disponibilidade (HA) e Recuperação de
Desastres (DR) com Libelle BusinessShadow®

A Libelle AG tem fornecido suas Soluções de Alta Disponibilidade (HA – High
Availability) e Recuperação de Desastres (DR – Disaster Recovery) para o mercado
corporativo há mais de uma década. Presente em quase 400 sites de clientes ao
redor do mundo e superando 1.000 instalações, a Libelle demonstrou sua
capacidade de obter amplo sucesso no atendimento das necessidades mais
complexas.

Neste White Paper, serão apresentados os fundamentos de Alta Disponibilidade e
Recuperação de Desastres e as tecnologias de apoio ao carro chefe da Libelle - a
solução Mirroring BusinessShadow ® - para HA (High Availability) e DR (Disaster
Recovery). Inclui uma visão geral sobre como a solução está posicionada no
mercado empresarial, bem como considerações importantes para a criação de
soluções de replicação para a área de TI das empresas.

White Paper

1. Introdução
Alta Disponibilidade (HA) e Recuperação de Desastres (DR) são freqüentemente utilizados
como termos soltos dentro das especificações, projetos e soluções de TI. Para proporcionar
ao leitor uma melhor compreensão das informações apresentadas, vamos começar este
White Paper, destacando nossos conceitos e métodos.

1.1. Terminologia
Usamos os termos "Recuperação de Desastres" (DR) e “Alta Disponibilidade” (HA)
extensivamente neste White Paper. As arquiteturas que estamos desenvolvendo ao longo
deste documento abordam ambos os cenários, HA e DR. Nossa experiência mostra que
mesmo os profissionais, às vezes, se confundem na abrangência dos conceitos. Como os
termos definem o intuito dos projetos queremos ser claros sobre os detalhes:
Entendemos “Alta Disponibilidade” (HA) como todas as ferramentas, políticas e
procedimentos para garantir a disponibilidade local de sistemas, incluindo proteção contra
falhas de hardware ou erros de software/usuário. Casos típicos de ferramentas para
fornecer HA são clusters de servidor ou banco de dados, componentes redundantes, SAN
(Storage Area Networks) para falhas de hardware, e backup / restore de banco de dados
em standby para erros de software, erros do usuário, ou corrupção de dados.
Entendemos "Recuperação de Desastres" (DR) como todas as ferramentas, políticas e
procedimentos para assegurar a operação de TI após uma falha total ou parcial do site.
Ferramentas que fornecem capacidades de DR são tipicamente de backup e recuperação
com acesso a outro site (‘cold standby’), ou a replicação de dados e reativação em site
secundário pré-configurado (‘warm standby’ or ‘hot standby’).
Além disso, o termo "Planejamento de Continuidade de Negócios (BCP - Business
Continuity Planning) é usado para expressar o lado da Instituição na Recuperação de
Desastres: papéis, responsabilidades e modelo organizacional, incluindo uma Análise de
Impacto ao Negócio (BIA - Business Impact Analysis).
A solução de software Libelle BusinessShadow aborda as exigências HA e DR e especifica
cenários possíveis para cada lado.

1.2. Alta Disponibilidade (HA)
Geralmente, cenários de alta disponibilidade podem ser categorizados em dois grupos de
problemas: hardware e software/usuário causando potencial indisponibilidade do sistema.
Do lado do hardware, a inatividade tornou-se uma questão menor, pois a tecnologia de
hardware evoluiu provendo sistemas quase totalmente tolerantes a falhas.
No entanto, a disponibilidade de hardware tem pouco a ver com a disponibilidade das
aplicações críticas em si. Um hardware ou banco de dados em cluster poderá fornecer
capacidade de restauração em questão de segundos, mas o aplicativo pode demorar um
pouco para estar totalmente disponível novamente.
Software e incidentes relacionados ao usuário são motivos de preocupação, pois muitas
vezes causam a maioria dos incidentes de inatividade. Especialmente com a crescente
complexidade de hardwares interdependentes e componentes de software, a
disponibilidade global do sistema está constantemente em risco. Pela nossa experiência,
vemos que os sistemas estão longe de atingir a métrica de disponibilidade de 99,999%.

©Libelle AG. All rights reserved. Printed: October 2010 1/25

White Paper

1.3. Recuperação de Desastres (DR)
Em comparação com os problemas locais, tais como problemas de servidor ou problemas
de usuário ou software, o cenário de recuperação de desastres é a segmentação de
eventos como incêndios, inundações, atentados terroristas, ou a ampla comunicação à
distância e falta de energia.
Vemos Recuperação de Desastres (DR) e de Alta Disponibilidade (HA) como
diametralmente proporcionais em relação à sua probabilidade e impacto: questões locais
podem acontecer com frequência, mas podem ser cobertos e corrigidos rapidamente com
impactos mínimos. Por outro lado, um incidente de Recuperação de Desastres (DR) tem
baixa probabilidade, mas apresenta impactos enormes quando o site de produção torna-se
completamente indisponível.

2. Definindo o HA e DR
Neste White Paper, estamos nos concentrando na arquitetura técnica de HA e soluções de
DR. Antes de especificar a arquitetura, torna-se necessário definir o escopo.

2.1. Arquitetura de TI Corporativa
Geralmente, a TI é a soma de uma série de componentes de infraestrutura, rede,
armazenamento e servidores para suportar Aplicativos Corporativos como soluções de ERP
da SAP AG, Oracle, Microsoft, Infor e muitos outros com centenas ou milhares de usuários.
A fundação destas aplicações são principalmente de médio para high-end UNIX ou
Windows Server executando bases de dados como o IBM DB2, o MaxDB, MySQL,
Microsoft SQL Server e Oracle.

A Empresa de IT
Arquitetura ilustra os
componentes críticos
para Alta Disponibilidade
e Recuperação de
Desastres.

Negócio

Dados

Aplicação

Tecnologia

Infraestrutura


White Paper

Da perspectiva de recuperação de desastres, todos os componentes de apoio aos
processos de negócio devem ser parcialmente ou totalmente disponíveis em um site
alternativo. Com exceção de infraestrutura e dos componentes do negócio, esboçaremos
nossa perspectiva sobre as diferentes abordagens mais tarde.
Da perspectiva de alta disponibilidade, muitos fatores são importantes. Para fornecer uma
disponibilidade total, a provisão de redundância é essencial. Muitos componentes podem
fornecer uma redundância embutida de modo que uma falha, por exemplo, de um
controlador de armazenamento, uma CPU, ou um único disco, não será sequer notada.
O segundo passo para Alta Disponibilidade é fornecer o mesmo elemento duas vezes,
mesmo se eles já têm redundância embutida. Por exemplo, um software de cluster fornece
soluções de capacidades de failover do servidor em caso de uma falha total. Combinando
essa solução com o armazenamento local espelhado, “paths” redundantes entre servidor e
armazenamento, o failover para novos sistemas pode acontecer dentro de um período de
tempo relativamente curto. Middleware, banco de dados e aplicações adaptam-se ao
cluster, para que um aplicativo possa ser disponibilizado em um hardware diferente
normalmente em menos de cinco minutos até 10 minutos, dependendo da aplicação.
No entanto, a redundância de hardware não será efetiva contra a causa número um de
indisponibilidade, erros de usuário e de software, como corrupção de dados e configurações
defeituosas, se espalharão por todo o ambiente.

2.2. Objetivos de Pontos de Recuperação
Ambos os projetos HA e DR iniciam com a questão de perda potencial de dados em caso
de um incidente (Objetivo de Ponto de Recuperação ou “RPO – Recovery Point Objective”)
e o tempo necessário para que o sistema esteja instalado e funcionando no site secundário
(Objetivo de Tempo de Recuperação ou "RTO – Recovery Time Objective”). A diferença
entre HA e DR é que as falhas locais costumam ter tempos de resposta e failover mais
rápidos, até porque os servidores estão disponíveis localmente e na mesma rede.

Objetivos de Ponto de Recuperação podem variar de zero, em uma configuração de
replicação síncrona, até alguns minutos, em uma configuração de replicação assíncrona, ou
com o envio de log (log shipping).

2.3. Objetivos de Tempo de Recuperação
O Objetivo de Tempo de Recuperação é a quantidade de tempo que demora até que o
aplicativo esteja disponível após uma falha do componente. Failover pode acontecer
automaticamente em modelo HA ou parcialmente automatizados depois de uma Declaração
de Desastre em contextos em modelo DR.
Para um cenário de HA, um RTO pode ser zero ou quase zero, caso a aplicação permita
componentes redundantes, tais como servidores de bancos de dados em um ambiente
RAC, ou servidores de aplicação onde os usuários fazem logon para o próximo servidor
disponível. No entanto, muitos aplicativos requerem uma reinicialização após iniciar em um
servidor diferente e, com isso, o RTO pode variar entre 5 e 15 minutos.
Para um cenário DR, o RTO é normalmente mais alto porque um datacenter completo com
sistemas interdependentes é movido para um novo site, em muitos casos em um segmento


White Paper

de rede separado. Com um site secundário em hot-standby espelhado, é possível chegar
RTO’s de 2 a 4 horas, se procedimentos e tecnologias estiverem em vigor.

2.4. Consistência dos Objetivos de Recuperação
Um terceiro objetivo, mais recente que os tradicionais RTO e RPO, é a Recuperação de
Consistência Objetiva. O RCO aplica objetivos de consistência de dados para a arquitetura
HA e DR. Seguindo as definições de RPO e RTO, o RCO define uma medida de
consistência dos dados de negócios distribuídos nos sistemas interligados após um
incidente de desastre. A próxima ilustração apresenta a relação entre RPO, RTO, e RCO.

Ponto de Recuperação,
Tempo de Recuperação
e Objetivos de
Consistência de
Recuperação
comparados

RPO= Quanta perda de
dados?

RTO= Quanta
inatividade?

RCO= Consistência de
transações de negócio
entre sistemas no
mesmo “landscape”.

3. Replicação
O conceito geral de qualquer solução de replicação é o de fornecer cópias dos dados de
produção e aplicativos críticos a um ou vários sistemas espelhados no mesmo local (HA) ou
em um local diferente (DR). Numa situação de emergência, os sistemas espelhados tornam-
se ativos e em suas bases os usuários podem fazer login.


White Paper

A maioria dos aplicativos
é configurada para ter
um nó ativo e um
passivo.

Existem soluções de
réplica ativa / ativa, mas
contanto que o aplicativo
em si não seja para
suportar tal
configuração, o requisito
é ativo / passivo

3.1. Camada de Banco de Dados, Camada de Arquivo, e Camada de
Armazenamento
Os aplicativos são principalmente baseados em bancos de dados e “Flat Files” (binários da
aplicação, dados de configuração, e todos os dados críticos não armazenados em um
banco de dados) dedicados. O banco de dados, propriamente dito, também é baseado em
Flat Files, que são gerenciados pelo software de banco de dados. Em uma camada inferior,
um controlador e / ou sistemas de armazenamento, estão administrando como esses
arquivos são armazenados e recuperados dos sistemas de armazenamento.


White Paper

Diferentes metodologias
copiam sistemas em
diferentes camadas.

Camadas de banco de
dados garantem
integridade do nível do
banco de dados,
enquanto a camada de
armazenamento apenas
garante integridade no
nível de
armazenamento.

Em seguida, aplicamos esse modelo de camada à réplica síncrona e assíncrona e
comparamos os diferentes níveis de réplica. É fundamental entender como os aplicativos
funcionam e armazenam seus dados em todas as camadas, para obter aplicações úteis e
dados da aplicação sobre o failover. A réplica pode ser feita em qualquer uma destas
camadas. A réplica de armazenamento incidirá sobre o espelhamento e integridade de
blocos de armazenamento, enquanto uma Réplica de Arquivo fará o mesmo para os
arquivos, e uma Solução de Réplica de Banco de dados estará focada no banco de dados.

3.2. Réplica Síncrona
Com uma replicação 100% síncrona, a camada na qual o dado é replicado é relativamente
irrelevante, até porque o sincronismo no nível de armazenamento se propagará até o nível
de aplicação. Isso faz com que soluções de HA, como clusters de servidores com
armazenamento redundante, sejam uma solução muito popular. Existem vários conceitos,
tais como cluster de hardware (por exemplo, IBM HACMP, MC HP / SG, etc), cluster de
banco de dados (cluster de aplicação real, recursos de particionamento direto), aplicações
com base em escrita duplicada de dados ou uma combinação dos conceitos.
Para DR, nem sempre é viável atingir uma replicação 100% síncrona (por causa da alta
latência de rede e as restrições de banda quando o espelhamento excede grandes
distâncias), nem desejável (adicionando infra-estrutura complexa e restrições de
desempenho na produção). Arquiteturas DR são tipicamente baseadas em Réplica
Assíncrona.
Quanto à alta disponibilidade, a réplica síncrona não está cobrindo o erro de software /
usuário, ou corrupção de dados. Esta é a razão pela qual os clientes implementam cópias
com tempo de atraso (time-delayed mirroring) para cobrir estes incidentes. As diferenças
são ilustradas na tabela a seguir:


White Paper

Réplica síncrona Réplica com Atraso
Abrangendo erros de
Sim Sim
Hardware?
Abrangendo erros de
Não Sim
Software?
Abrangendo erros
operacionais de Não Sim
usuários?
Abrangendo erros
Não Sim
corrupção de dados?

3.3. Réplica Assíncrona
No momento em que começar a replicar os dados de forma assíncrona, é de suma
importância, em qual camada (Aplicativo/ Banda de Dados/ Arquivo/ Armazenamento) a
replicação está funcionando, e se quaisquer considerações de consistência no nível de
aplicação estão no lugar. Blocos de armazenamento de réplicas assíncronas, por exemplo,
não fazem consistência de arquivos, banco de dados ou aplicativos.
Com a Réplica Assíncrona baseada em blocos, é quase garantia de que um sistema
espelhado esteja em um estado inconsistente, a partir da perspectiva da aplicação:
1. Suponha que blocos de armazenamento são espelhados com pontos de consistência
em nível de armazenamento.
2. Arquivos consistem em múltiplos blocos de armazenamento: arquivos podem estar
inconsistentes.
3. Banco de dados consiste em múltiplos arquivos: banco de dados é suscetível de estar
inconsistente.
4. Aplicações consistem em múltiplas bases de dados: A aplicação é suscetível de estar
incompatível.
5. Processos de Negócio consistem em múltiplas aplicações: Processos estarão
inconsistentes.
Em resumo, nenhuma réplica assíncrona de consistência em níveis de bloco tornará
consistente uma aplicação espelhada.

4. BusinessShadow® Resumo
O Software BusinessShadow da Libelle é uma solução de software que replica a aplicação
na camada de banco de dados (DBShadow) e de arquivos (FSShadow). É estendido com
automatização failover de aplicativos (SwitchApplication) e uma edição especial para
Réplica WAN (Opção de longa distância). BusinessShadow é usado para HA, DR, e várias
combinações de ambos.


White Paper

4.1. Componentes do Software
O BusinessShadow possui os seguintes componentes:
DBShadow suporta os seguintes softwares de banco de dados: IBM DB2, o MaxDB,
Microsoft SQL Server, MySQL e Oracle. Ele é usado para espelhar bancos de dados das
principais aplicações.
FSShadow é usado para espelhar dados críticos de aplicações, que não estão retidos na
base de dados, por exemplo, binários, dados de perfil, interface EDI, ou outros aplicativos
específicos de flat files.
SwitchApplication é utilizado para ativar e desativar endereços IP das aplicações,
“hostnames”, e pode automatizar outras tarefas de failover de aplicativos específicos.
LongDistanceOption amplia a funcionalidade dos recursos de espelhamento do
DBShadow e FSShadow para dar suporte as configurações de Wide Area Network.

Visão geral dos
principais dos
componentes do
BusinessShadow

Todos os componentes estão disponíveis especificamente aos respectivos sistemas
operacionais (HP-UX, IBM AIX, Solaris, Tru64 UNIX, a maioria das distribuições Linux, e
todas as plataformas Windows). Grande parte das implementações do Libelle AG são
espelhamento de aplicativos da SAP AG, com uma edição especial do BusinessShadow
para soluções SAP e Integração Certificada SAP
(http://ecohub.sdn.sap.com/irj/ecohub/solutions/BusinessShadow) . Outras implementações
incluem Oracle, Microsoft Dynamics, Soluções ERP da Infor Global Solutions, e muitos
outros aplicativos.

4.2. Solução de Design

4.2.1.DBShadow e FSShadow
A arquitetura dos principais componentes do BusinessShadow, DBShadow e FSShadow, é
projetada para que cada “Espelho” consista em um sistema de produção e um ou mais
sistemas espelhados.


White Paper

Agentes dos servidores
do DBShadow e do
FSShadow comunicam-
se entre si, e com uma
interface gráfica (GUI),
que permite
gerenciamento
centralizado, e
monitoração da
operação.

Depois que uma réplica é construída inicialmente entre os dois sistemas com uma "Cópia
Inicial” (Initial Copy), um processo de arquivamento (“Archiver”) coleta alterações em banco
de dados e em Flat Files do sistema de produção, e as envia para o sistema espelhado,
usando o Libelle TCP / IP Stacks. O Archiver é adaptado às necessidades do aplicativo e ao
RPO - Objetivo de Ponto de Recuperação. Ele pode ser configurado para “disparar”, por
exemplo, a cada 5 ou 10 minutos. Um processo de recuperação em execução no sistema
espelhado está aplicando as alterações que recebe do processo Archiver e aplicando-os em
um banco de dados (DBShadow) ou em um sistema de arquivos (FSShadow). Todos os
processos podem operar de forma independente se um ou outro sistema estiver
temporariamente indisponível, e retornar assim que a conexão for restabelecida, mas
geralmente dependem uns dos outros para uma operação de HA ou DR coerente.
O software é baseado em poucos e pequenos agentes (memória compartilhada para UNIX,
serviços para Windows) que residem em cada servidor. Os agentes comunicam-se entre si
através de “sockets” de rede especializada. O Aplicativo Libelle GUI permite interceptar a
comunicação e gerenciar um ou vários sistemas espelhados através de um landscape.
A operação de réplica do dia-a-dia é, como se pode notar, baseada nos processos de
arquivamento e recuperação funcionando de forma contínua, monitorados pela GUI.
Irregularidades na operação são registradas no servidor e enviadas à GUI e/ou a outras
ferramentas de gerência de sistemas.

4.2.2.Option Long Distance
Um componente adicional do BusinessShadow é a opção “Option Long Distance” para
estender a transferência de dados comprimidos (TCP/IP) com compressão adicional,
paralelismo e configurações de pacotes, para atender às grandes distâncias entre produção
e espelho com latência da rede, normalmente, elevada.

4.2.3.SwitchApplication
Finalmente, o componente SwitchApplication pode gerenciar o failover de endereços IP
entre os dois sistemas, de modo que um servidor virtual adicional, ou endereço IP, em um
sistema de produção, seja movido facilmente para um sistema espelhado como parte do
processo de failover.


White Paper

SwitchApplication
fornece uma solução
para adicionar e remover
IPs Virtuais e servidores
(hostnames)
automaticamente
através do failover do
DBShadow ou
FSShadow

4.2.4.Console de Gerenciamento GUI (Graphical User interface)
Para permitir um único ponto de controle para o administrador, a Libelle fornece uma
Interface Gráfica de Usuário (GUI), que se comunica com qualquer número de Agentes do
Servidor. A GUI é o componente central para instalar, controlar e operar o espelhamento.
Ela também fornece uma interface gráfica simples para executar Failovers de Emergência
ou testes de Recuperação de Desastres. Como os agentes do servidor estão fazendo as
tarefas de replicação, o GUI serve apenas para monitoramento e operação, mas não uma
parte ativa do processo de réplica.
Os agentes agem de forma independente e podem enviar mensagens (SMTP ou não), e
são geridos também por linha de comando.

BusinessShadow
GUI na Versão 5.

Este exemplo mostra a
GUI exibindo seis grupos
do sistema no lado
esquerdo, mostrando o
grupo 'Produção' no
meio.

Cada grupo contém
alguns erros.

A marca de verificação
verde um status 'ok'. O X
vermelho ilustra "erros"
(como base de dados
inativa). Marca de
explicação Amarela,
ilustra advertências
(‘warnings’ - por
exemplo, a falta de
espaço em disco)


White Paper

4.3. Cenário de Alta Disponibilidade
O BusinessShadow, para alta disponibilidade, pode fornecer uma réplica local de sistemas
espelhados para qualquer sistema de produção. O software pode ser usado como uma
solução de failover sem perda de dados para um sistema espelhado com armazenamento
compartilhado, ou solução de perda mínima de dados sem armazenamento compartilhado.
O primeira implementação do BusinessShadow para HA é o conceito de um espelhamento
com atraso (time-delayed) para proteger contra erros de software e / ou usuário. A
arquitetura é baseada em um espelhamento intencionalmente atrasado entre os dois
sistemas. Alterações do sistema de produção são aplicadas no seu espelho com atraso de
tempo, por exemplo, 2 ou 4 horas para permitir uma janela de reação no caso de danos
causados por erros de software, erros de usuário, erros de configuração, atualizações de
sistema mal planejadas ou executadas, e outras situações levando a dados corrompidos ou
inutilizáveis.

DBShadow e FSShadow
durante a operação
normal.

As transações são
enfileiradas no sistema
espelhado antes de
serem aplicadas,
permitindo uma janela
de reação para dados
corrompidos

Por outro lado, se um erro humano está corrompendo a base de dados de produção, por
exemplo, o Banco de Dados espelhado não tem as últimas quatro horas aplicadas ainda,
mas continua na fila de acordo com o tempo de atraso. Para uma rápida restauração, o
administrador vai usar a GUI BusinessShadow ou a interface Shell para uma recuperação
automatizada de cada instante que precedeu o erro ocorrido. Transações equivalentes a um
intervalo de quatro horas de transações podem normalmente ser aplicadas em prazo inferior
a 20 minutos, dependendo do desempenho do hardware. Comparando isto com a
alternativa de uma restauração completa da fita, esta metodologia é a maneira mais rápida
possível para restaurar um sistema após ser corrompido.


White Paper

DBShadow e FSShadow
durante a operação de
emergência causada
pela corrupção de dados

O sistema espelhado
provê restauração da
aplicação com dados
pré-corrupção em estado
consistente.

Geralmente nós estamos alvejando RTO - Objetivos de Recuperação de Tempo (tempo de
failover), que inclui reiniciar o aplicativo, de menos de 25-40 minutos, no caso de um
sistema de produção corrompido causado por erros de usuário / software com atraso de
quatro horas. Para implementações sem atraso de tempo, Objetivos de Recuperação de
Tempo são normalmente inferiores a 10-15 minutos.
Objetivos de Pontos de Recuperação (perda de dados - RPO) são mais variados,
dependendo do tempo de atraso. Para um erro de software, nossa intenção é voltar no
tempo, por isso pode variar desde cinco minutos até 4 horas, por exemplo. Será o que
Administrador Libelle quiser ou não recuperar. Uma vez que o administrador decida qual o
ponto no tempo, todas as tarefas relacionadas ao banco de dados (recuperação, renomeio
de banco de dados, tablespaces gerenciadas localmente, etc) serão totalmente
automatizadas.
Para um failover sem perda de dados, os últimos 5 ou 10 minutos de logs on-line que
podem não ter sido enviados, devem estar localizados em um armazenamento
compartilhado que o sistema espelhados possa acessar.

4.4. Cenários de Recuperação de Desastre
A segunda aplicação do BusinessShadow é servir como uma solução completa de
recuperação de desastres. Os agentes de baixo impacto dos servidores e a baixa exigência
da rede fazem a solução adequada para espelhar qualquer tamanho de ambiente para um
local remoto.

As instalações de DR da podem variar desde uma única aplicação de 400 GB espelhada
sobre rede VPN de 3Mbit / s de rede, até grandes landscapes de 20-30 TB, com dezenas
de aplicativos espelhados em um link dedicado de 100 MBit / s WAN.
A metodologia é semelhante a uma implementação de HA, exceto que o tempo de atraso
tem menos importância. O Archiver é geralmente definido baixo o suficiente para atender os
RPO’s (por exemplo, máxima de perda de dados de 10-15 minutos no caso de uma falha no
site), mas também alto o suficiente para não afetar o desempenho do sistema de produção
(atualização de forma síncrona do sistema espelhado exigiria muita sobrecarga de
desempenho na rede e no servidor).
De qualquer maneira, com BusinessShadow espelhando o landscape de aplicativos para
qualquer número de sistemas, gera-se um abrangente sistema de recuperação de


White Paper

desastres em standby, que é constantemente atualizado com dados recentes de produção.
O failover em casos de emergência, ou até em testes de DR, é fortemente automatizado.

4.5. Integrações em soluções SAP

4.5.1.Compromisso da Libelle para o Mercado SAP
A Libelle tem fornecido suas soluções de software para o mercado SAP desde o final dos
anos 90. O primeiro banco de dados suportado foi o Oracle 6, e como uma empresa
localizada na Alemanha, desde o início sempre tivemos o acesso a uma grande base de
clientes da SAP. Depois de adicionar suporte para o DB2 da IBM, o MaxDB e Servidor
Microsoft SQL, a Libelle dá suporte a todos os ambientes SAP. Em 2005, a Libelle estendeu
seu foco para o mercado SAP com a Certificação Integrada SAP. Aplicativos SAP já
representam 80% da base de clientes da Libelle. Em 2009, a Libelle adquiriu uma
participação majoritária em uma empresa de consultoria SAP basis (SAP Basis Consulting),
localizada na Alemanha para aumentar sua exposição no mercado de SAP Basis (SAP
Basis Market).

4.5.2.Requisitos de Landscape SAP
Com a mais moderna arquitetura Netweaver, a SAP AG proveu uma sofisticada arquitetura
orientada a serviços. Funcionalidades adicionais acrescentaram um alto grau de
complexidade em desenho técnico e operação, especialmente se comparadas às anteriores
do SAP/R3, baseadas em uma instalação ABAP “single-stack” com uma ou duas instâncias
SAP.
Ao menos que implementemos uma replicação síncrona de 100%, qualquer solução de
replicação agnóstica a aplicação (por exemplo, a réplica baseada em bloco – block based)
que não está totalmente integrada a arquitetura SAP Netweaver, está condenada a causar
problemas no failover. Também, soluções específicas de cópias de banco de dados (ex. log
shipping) vão omitir grande quantidade de dados armazenados em flat files, e por isso
também deverão ter problemas na realização do failover.
A ilustração abaixo mostra como o BusinessShadow é integrado em uma única instância
SAP. Embora a ilustração mostre um sistema de produção de um “nó”, a maioria dos
sistemas de clientes são baseados em sistemas de cluster de dois nós.


White Paper

BusinessShadow
Integração típica de
Instância SAP

Finalmente, a maioria das instalações SAP é baseada em sistemas múltiplos. Parte do
projeto de réplica é desenvolver e testar exaustivamente um modelo para uma instalação e,
em seguida, replicar o modelo em todo o ambiente, seja repetindo a instalação ou com um
processo de implantação automatizada, dependendo do tamanho do projeto.

5. Tecnologia BusinessShadow

5.1. Agentes Centrais do Servidor
Os componentes centrais Libelle BusinessShadow baseiam-se em pequenos agentes
residentes nos servidores de produção e no seu espelho, que são codificados em C e C + +
e executados como processos de memória compartilhada em ambiente UNIX, ou como
serviços para sistemas Windows.

O código de hoje nas versões 4.5, 4.8 e 5.x contem mais de 14 anos de desenvolvimento e
melhorias, e foi instalado e opera em mais de 1000 instalações, sejam pequenas, médias ou
grandes. Hoje, são ambientes ativos para espelhar desde pequenos bancos de bados de
100GB, ou até banco de dados de 18TB, em instalações de instância única, ou em
landscapes complexos com 50 ou mais servidores, em configurações UNIX e Windows.


White Paper

Agentes do Servidor
iDBShadow e
FSShadow estão se
comunicando com os
próprios soquetes TCP /
IP.

A ilustração mostra os
principais processos
“lnitial Copy”, “Archiver”,
e “Structure” rodando em
produção e o processo
“Recover” em execução
no espelho.

Depois do failover, os
papéis são invertidos e a
réplica vai à direção
oposta.

Os agentes gerenciam a comunicação entre os dois sistemas e são controlados por linha de
comando ou interface gráfica do usuário (GUI). Eles guardam informações sobre as
atividades em curso na memória compartilhada, podendo ser acessadas por ambos os
lados.
Todos os processos contêm “processos principais” que iniciam, param e gerenciam
“processos filho” que executam tarefas dedicadas, como por exemplo:
Processo Archiver DBShadow para HP-UX inicia, o e monitora a cópia de um arquivo de
log do Oracle 11i ao seu sistema espelhado.
Processo de Recuperação DBShadow para Windows aplica e monitora a recuperação dos
backups dos arquivos de log transacionais com um certo atraso de tempo em seu sistema
espelhado.
FSShadow para Processo Archiver IBM AIX verifica a lista definida de Flat Files em
produção a cada 20 minutos e, copia as alterações em seu sistema espelhado.
DBShadow para Processo de Estrutura Solaris verifica o banco de dados Oracle para
transações no-logging, novos arquivos de dados, ou novos diretórios, e atualiza o espelho
em conformidade.
DBShadow para Processo de Recuperação IBM AIX realiza uma recuperação “Point-In-
Time” para um banco de dados DB2 no failover.


White Paper

A ilustração mostra uma
tela GUI de memória
partilhada recuperada de
um sistema espelhado.
A mesma informação
pode ser recuperada
pelo servidor através de
um comando shell.

Como o nome indica, a
informação é mantida
em memória nos
sistemas de produção e
do espelho.

Isto permite continuar a
operação de
espelhamento após
qualquer interrupção,
pois as informações
constam nos dois
sistemas.

O elemento chave para a operação dos agentes é a sua robustez, já que operam 24 horas /
7 dias da semana, 365 dias por ano e foram desenvolvidos para sobreviver as
reinicializações de servidor, interrupções prolongadas de rede, e/ou outros problemas
típicos na operação de uma LAN ou WAN. Nos parágrafos seguintes, vamos analisar em
detalhe a forma como os processos interagem com o ambiente para permitir uma
configuração de réplica.

5.2. Espelhamento de Banco de Dados
A replicação de banco de dados com Libelle DBShadow baseia-se nas seguintes etapas:
Criar uma cópia inicial de um banco de dados de produção no seu sistema espelhado.
Em intervalos configuráveis, por exemplo, a cada 10 minutos, verificar mudanças no
banco de dados de produção na forma de arquivos de log “offline” e envio das mudanças
para o sistema espelhado pelo processo Archiver.
Continuamente aplica as alterações do banco de dados de produção para o banco de
dados espelhado com um atraso customizável.
Em intervalos configuráveis, por exemplo, a cada 2 horas, verificar no banco de dados de
produção novos Data files, transações sem registro (no-logging), novos diretórios e
atualiza o banco de dados espelhado.


White Paper

Os principais processos,
“Cópia Inicial”,
”Archiver”, e
“Recuperação”
interagindo com
seu espelho

Um processo “Estrutura”
adicional verifica os
dados de produção e
coordena as
atualizações de estrutura
para o banco de dados
espelhado com o
processo de
recuperação.

Todos os processos DBShadow podem adequar-se a diferentes tipos de banco de dados.
Um processo Archiver para Oracle funciona diferente de um processo Archiver para MS
SQL Server, por exemplo. O mesmo se aplica aos processos de cópia inicial, recuperação e
estrutura em operação normal de réplica, e de operação de failover de emergência, onde o
sistema espelhado é ativado pelo BusinessShadow.

Esta ilustração mostra o
Archiver DBShadow
para banco de dados
Oracle.

DBShadow suporta
Oracle 8i-11g, todas
versões de MS SQL
Server desde 2000 a
2008, a maioria das
versões MaxDB, DB2
V7-9, e MySQL

Cada banco de dados
tem seus próprios
métodos e
considerações especiais,
e o DBShadow os reflete
na respectiva edição.


White Paper

5.3. Espelhamento dos Flat Files
O espelhamento dos flat files funciona de forma análoga para o espelhamento do banco. O
componente FSShadow mantêm cópias dos flat files para todos os arquivos definidos no
processo de espelhamento, ou que foram adicionados depois. Inicialmente, o processo de
Cópia Inicial (Initial Copy) cria uma cópia idêntica de arquivos no sistema espelhado. Em
seguida, um processo Flat File Archiver verifica os arquivos do sistema de produção em
intervalos customizados, por exemplo, a cada 30 minutos ou a cada 5 minutos, dependendo
do projeto, dos requisitos do cliente, e das considerações sobre o desempenho.
Finalmente, um processo de recuperação está conduzindo a recuperação dos arquivos no
sistema espelhado. Tal como acontece com DBShadow, a arquitetura contempla um tempo
de atraso designado. Os flat files não serão aplicados imediatamente ao chegar ao destino,
mas depois de um período designado de, por exemplo, 4 horas. Isso permite uma janela de
reação em caso de dados de Flat File corrompidos tanto para Alta Disponibilidade quanto
para Recuperação de Desastres.

O FSShadow copia
diretórios completos ou
flat files isolados.

As entradas podem ser
definidas via GUI ou um
arquivo ASCII simples,
diretamente no servidor.

Uma vez configurado, o
FSShadow inicializa a
réplica, gerencia
transferência de dados
no sistema espelhado, e
monitora a operação.


White Paper

5.4. Otimização em WAN: Option Long Distance
Ambos os componentes DBShadow para bancos de dados e FSShadow para flat files
permitem uma extensão dos serviços de comunicação para Wide Area Networks chamada
“Option Long Distance” (Opção de longa distância).
Desafios gerais de uma configuração de replicação de uma WAN, comparados aos de uma
LAN são tipicamente (1) largura de banda disponível drasticamente reduzida, (2), em geral,
redes instáveis com múltiplas quedas de linha durante o dia, e (3) muito elevada latência de
rede com distâncias superiores a 85 kilômetros. Para tratar essas questões, a opção de
Option Long Distance ajusta os stacks Libelle TCP / IP com extensões customizadas que
incluem:
Alta Compressão: Compressão adicional à existente antes do envio dos dados.
Transferência Paralela de Arquivo: Arquivos de log isolados são enviados em paralelo.
Por exemplo, um único arquivo de log de 200 MB pode ser dividido em vários pacotes de
dados que são enviados, em paralelo, para o sistema espelhado e, em seguida, entregue
ao banco de dados espelhado.
Tecnologia de Grandes Pacotes: Esta opção “LongDistance” aumenta o tamanho padrão
do pacote TCP/IP. O tamanho padrão dos pacotes é voltado para redes locais e, muitas
vezes inadequado para a réplica WAN.

5.5. Failover do Aplicativo
Libelle BusinessShadow fornece três componentes principais para o failover dos aplicativos,
em caso de emergência:
Processo de recuperação (Libelle DBShadow e FSShadow Recover Process) em modo
de emergência para executar automaticamente todas as tarefas relacionadas a failover de
banco de dados e flat files;
Libelle SwitchApplicationSoftware para automaticamente adicionar ou remover hostnames
e endereços IP entre sistemas de produção e seus espelhos;
Libelle DBShadow, FSShadow e SwitchApplication (interfaces de usuário) para
automatizar tarefas pré-definidas durante o failover.

5.5.1.Processo de Recuperação em Modo de Emergência
Durante o processo normal de réplica, o DBShadow e o FSShadow Recover Process
aplicam as alterações que recebem do processo Archiver no banco de dados do espelho ou
no “File System” do espelho. Durante uma situação de emergência, onde um failover e a
ativação do sistema espelhado são necessários, o mesmo processo de recuperação vai
operar no "modo de emergência” e garantir automaticamente que o sistema espelhado está
em estado adequado para assumir a produção.
Para o failover do banco de dados com DBShadow, isso inclui todas as tarefas relacionadas
a banco de dados, tais como a execução de uma recuperação automatizada Point-In-Time
até um determinado momento (customizado). O DBShadow aplicará, então, todos os
arquivos de log pendentes.
O processo de recuperação também permite uma troca de função automatizada entre
produção e espelho, em caso de failover planejado, para a maioria dos bancos de dados
(para o Oracle, por exemplo, ele aplicaria os logs de produção remanescentes e abriria o
espelho com a opção ‘no reset logs). Finalmente o processo automaticamente renomeia o


White Paper

banco de dados para o nome do banco de dados de produção e executa outras tarefas
adicionais, caso necessário.
O Flat File Failover com FSShadow opera de forma semelhante. Com um tempo de atraso
configurado, clientes podem especificar um time-stamp até qual flat file deve ser recuperado
e, em seguida, fornece ao sistema espelhado a estrutura exata arquivo, como desejado.

BusinessShadow GUI
com a opção de failover
para DBShadow para
MS SQL Server.

A parte inferior da tela
mostra as opções de
failover e a imagem
acima reflete os
seu espelho.

As “balas” verdes
representam os arquivos
de log configurado no
“funil do tempo” (time
funnel) com a
porcentagem de espaço
em disco utilizado.

A GUI exibe o tempo
atual do sistema de cada
servidor e a lista de
espelhos do lado
esquerdo.

5.5.2.Libelle SwitchApplication
Outra parte essencial de failover de um ou vários sistemas de um landscape de produção
para seu espelho é ativar automaticamente os endereços IP e hostnames no destino e - se
desejado pelo cliente – removê-los do sistema origem.
Libelle SwitchApplication é um produto de software baseado em agentes (de servidor) e
uma interface gráfica para gerenciar vários sistemas. Os agentes podem interagir com um
sistema de forma a adicionar ou remover hostnames ou IPs virtuais para servidores UNIX e
Windows. O processo de adição e remoção de nomes/endereços não exige a reinicialização
de, por exemplo, um servidor Windows. A ferramenta se compara a uma forma básica de
um cluster de servidores, mas é gerida e acionada pelo cliente ou pelo processo de failover
FSShadow DBShadow e FSShadow.
SwitchApplication pode ser instalado em ambos sistemas, produção e espelho. A maioria
dos clientes, entretanto, já tem software de cluster implementado em seus sistemas de
Produção, onde SwitchApplication então só pode ser instalado no sistema espelhado e


White Paper

ativar o recurso cluster de endereço de IP, uma vez que o mesmo estiver indisponível na
Produção.
Para a operação do SwitchApplication, é necessário que ambos sistemas, produção e seu
espelho, estejam na mesma rede, pois o SwitchApplication não executa nenhum controle
sobre roteamento ou tabelas de DNS. Para DR, o cliente poderia implementar uma LAN
virtual com a mesma sub-rede. Se não for possível, os sistemas podem ficar em redes
separadas e o failover dos aplicativos é realizado através da atualização de entradas de
DNS ou por outros meios.
A ilustração abaixo mostra a implementação de um landscape do BusinessShadow com
SwitchApplication implementado na produção – e um espelho para os sistemas “standalone”
e implementadas nos sistemas espelhados apenas para os sistemas de produção em
cluster.

Integração do
BusinessShadow em um
landscape complexo
SAP.

SCM mostra duas
instâncias DBShadow,
pois o aplicativo tem,
tipicamente, um MaxDB
e um banco de dados
Oracle.

5.5.3.Failover- e Outras Interfaces de Usuários
Todos os componentes BusinessShadow vêm com um conjunto de interfaces de usuário
customizáveis que estão vazias no início de uma implementação. A instalação padrão de
um sistema espelhado isolado requer apenas pequenas integrações adicionais, como a
automação do failover. Uma implementação de vários espelhos, porém, é muitas vezes
estendida a um quadro de interfaces onde um espelho principal pode iniciar o failover de um
grupo de aplicativos relacionados, ou de outros sistemas, automaticamente.
Interfaces de usuário podem executar tarefas off-line (por exemplo, executar um script) ou
on-line (execução de um script com opções de feedback), e podem residir em ambos os
sistemas, de produção e seu espelho. As tarefas podem ser executadas como tarefas locais
(Local Tasks - operam no mesmo servidor onde são definidas) ou tarefas remotas (Remote
Tasks - disparam ações no seu parceiro de espelhamento).
Para o failover em si, uma interface central teria acionado antes, durante ou depois o
DBShadow, ou FSShadow ter concluído suas tarefas de failover. Integrações podem ser
tão simples como acionar failovers de outro sistema, até executar um plano sofisticado de


White Paper

vários passos de controle e execução de tarefas de failover, que costumavam ser feitas
manualmente.

5.6. Interface Gráfica de Usuário (GUI)
O Libelle BusinessShadow GUI é o ponto central onde todas as configurações e DBShadow
FSShadow de um landscape são iniciadas, controladas, monitoradas e gerenciadas. A GUI
é uma aplicação JAVA e é normalmente instalado em uma estação de trabalho. A GUI
oferece uma interface central para instalar, configurar e ativar um ou vários sistemas
espelhados.

O Menu 'Configurar' do
BusinessShadow
destina-se a apoiar uma
fácil instalação e
configuração para cada
espelho.

Este exemplo mostra a
configuração de um
espelho MS SQL Server.

A parte inferior da imagem mostra a configuração atual dividida em opções 'Copy',
'Archiver', 'Recovery', e 'Structure', conforme descrito nos capítulos anteriores. "Alarm" é a
configuração de como os agentes devem reagir a “distúrbios” e se erros ou avisos deverão
ser enviados por e-mail ou SMTP “traps”. Depois de criadas as configurações de
espelhamento, o próximo passo é permitir a monitoração de múltiplos sistemas, como
mostrado na próxima figura.


White Paper

O Monitoramento do
BusinessShadow
permite uma visão por
espelho, grupo ou lista.

Em instalações maiores,
características de filtro
com sinalizadores em
verde (OK), amarelo
(aviso), ou vermelho
(erro), permitem uma
fácil identificação de
irregularidades na
operação de
espelhamento.

A GUI também coleta e
exibe as mensagens do
servidor para o sistema
selecionado.

6. Resumo
Neste White Paper apontamos em detalhe os métodos diferentes de espelhamento tanto
para Alta Disponibilidade e Recuperação de Desastre.
A Solução Libelle BusinessShadow permite o maior grau possível de consistência em nível
de banco / aplicação, já que o dado é espelhado em nível de banco de dados para todas as
principais tecnologias de banco de dados. Por outro lado, ele fornece uma solução completa
para espelhar diferentes bases de dados em diferentes plataformas e oferece uma solução
sofisticada para espelhar flat files. Libelle atinge um local único entre replicação de
armazenamento aplicativo-agnóstico / baseada em blocos e soluções de envio de dados
centrados em log.
Todas as soluções Libelle vêm com um conceito sofisticado de implementação e modelo de
operação para atender qualquer tamanho e grau de complexidade desde uma instalação
simples de espelhamento ou landscapes com mais de 100 servidores.
Existe uma grande variedade de funcionalidades, vantagens e conceitos não mencionados
neste White Paper. Entre em contato conosco para que nossos arquitetos de solução e
consultores revisem seu landscape para delinear sua solução, implementação e abordagem
operacional para seus requerimentos.

Mais Informações & Convite de Demo ao Vivo

Entre em contato conosco e se inscreva para uma demonstração técnica de 60-90
minutos livre e sem obrigações onde nós lhe mostraremos uma simulação de DR de um
sistema de produção baseado em um banco de dados de sua escolha e responderemos
suas perguntas.


White Paper

North America All other Countries

Libelle LLC Libelle AG
3330 Cumberland Blvd. Suite 500 Gewerbestr. 42
Atlanta, GA 30339, USA 70565 Stuttgart, Germany

T +1 770 / 435 1101 T +49 711 / 78335-0

sales@libelle.com sales@libelle.com

South America

Profits Consulting
Rio de Janeiro - Brazil
Rua da Lapa 180 / 2o andar

T +55 21 4105 5441

comercial@profitsconsulting.com.br

www.Libelle.com

Libelle não garante que a informação contida nesta apresentação é livre de erros. A responsabilidade por danos conseqüentes
ou indiretos decorrentes da leitura ou o uso desta informação não é justificado pela Libelle AG dentro dos limites legais. Todos
os direitos autorais, especialmente reprodução, distribuição e tradução, são reservados. Nenhuma parte desta apresentação
pode ser reproduzida (por microfilme, fotocópia ou outros), processados, reproduzida ou transmitida por meios electrônicos,
sem a aprovação explícita de Libelle. Sob nenhuma circunstância, incluindo mas não limitado a, negligência, a Libelle, seus
agentes ou prepostos, incluindo mas não limitado à sua controladora, controlada, ou empresas afiliadas, será responsável por
quaisquer danos diretos, indiretos, incidentais, especiais ou conseqüentes que resultar do uso das informações fornecidas
nesta apresentação. Libelle, o logotipo Libelle, BusinessShadow ®, DBShadow FSShadow ® e ® são marcas registradas da
Libelle AG, G Alemanha .Todos os outros produtos e empresas mencionados no presente White Paper são marcas
registradas de seus respectivos proprietários.


Whitepaper business shadow_portugues

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Whitepaper business shadow_portugues

Whitepaper business shadow_portugues