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

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

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

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 Hardware?

Sim Sim

Abrangendo erros de Software?

Não Sim

Abrangendo erros operacionais de usuários?

Não Sim

Abrangendo erros corrupção de dados?

Não Sim

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 sistemas de produção e

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 sistemas de produção e

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

[email protected] [email protected]

South America Profits Consulting Rio de Janeiro - Brazil Rua da Lapa 180 / 2o andar T +55 21 4105 5441

[email protected]

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.

Documents

Whitepaper Business Shadow Portugues