Whitepaper_BusinessShadow_portugues

8/7/2019 Whitepaper_BusinessShadow_portugues

http://slidepdf.com/reader/full/whitepaperbusinessshadowportugues 1/25

White Paper

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

A Libelle AG tem fornecido suas Soluções de Alta Disponibilidade (HA – HighAvailability) e Recuperação de Desastres (DR – Disaster Recovery) para o mercadocorporativo há mais de uma década. Presente em quase 400 sites de clientes aoredor do mundo e superando 1.000 instalações, a Libelle demonstrou suacapacidade de obter amplo sucesso no atendimento das necessidades maiscomplexas.

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



White Paper

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

1. IntroduçãoAlta Disponibilidade (HA) e Recuperação de Desastres (DR) são freqüentemente utilizadoscomo 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 esteWhite 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 longodeste documento abordam ambos os cenários, HA e DR. Nossa experiência mostra quemesmo os profissionais, às vezes, se confundem na abrangência dos conceitos. Como ostermos 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 contrafalhas de hardware ou erros de software/usuário. Casos típicos de ferramentas parafornecer 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 dadosem 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 eprocedimentos 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çãocom acesso a outro site (‘cold standby’), ou a replicação de dados e reativação em sitesecundário pré-configurado (‘warm standby’ or ‘hot standby’).

Além disso, o termo "Planejamento de Continuidade de Negócios (BCP - BusinessContinuity Planning) é usado para expressar o lado da Instituição na Recuperação deDesastres: papéis, responsabilidades e modelo organizacional, incluindo uma Análise deImpacto ao Negócio (BIA - Business Impact Analysis).

A solução de software Libelle BusinessShadow aborda as exigências HA e DR e especificacenários possíveis para cada lado.

1.2. Alta Disponibilidade (HA)

Geralmente, cenários de alta disponibilidade podem ser categorizados em dois grupos deproblemas: 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 dasaplicaçõ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 umpouco para estar totalmente disponível novamente.

Software e incidentes relacionados ao usuário são motivos de preocupação, pois muitasvezes causam a maioria dos incidentes de inatividade. Especialmente com a crescentecomplexidade de hardwares interdependentes e componentes de software, adisponibilidade 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 problemasde usuário ou software, o cenário de recuperação de desastres é a segmentação deeventos 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) comodiametralmente proporcionais em relação à sua probabilidade e impacto: questões locaispodem acontecer com frequência, mas podem ser cobertos e corrigidos rapidamente comimpactos mínimos. Por outro lado, um incidente de Recuperação de Desastres (DR) tembaixa probabilidade, mas apresenta impactos enormes quando o site de produção torna-secompletamente indisponível.

2. Definindo o HA e DR

Neste White Paper, estamos nos concentrando na arquitetura técnica de HA e soluções deDR. 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 ERPda 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 ouWindows Server executando bases de dados como o IBM DB2, o MaxDB, MySQL,

Microsoft SQL Server e Oracle.

A Empresa de ITArquitetura ilustra oscomponentes críticospara Alta Disponibilidadee Recuperação deDesastres.

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 sitealternativo. Com exceção de infraestrutura e dos componentes do negócio, esboçaremosnossa perspectiva sobre as diferentes abordagens mais tarde.

Da perspectiva de alta disponibilidade, muitos fatores são importantes. Para fornecer umadisponibilidade total, a provisão de redundância é essencial. Muitos componentes podemfornecer uma redundância embutida de modo que uma falha, por exemplo, de umcontrolador 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 fornecesoluções de capacidades de failover do servidor em caso de uma falha total. Combinandoessa solução com o armazenamento local espelhado, “paths” redundantes entre servidor earmazenamento, 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 aocluster, para que um aplicativo possa ser disponibilizado em um hardware diferentenormalmente 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 deindisponibilidade, erros de usuário e de software, como corrupção de dados e configuraçõesdefeituosas, 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 casode 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çaentre HA e DR é que as falhas locais costumam ter tempos de resposta e failover maisrá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 dereplicação síncrona, até alguns minutos, em uma configuração de replicação assíncrona, oucom 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 oaplicativo esteja disponível após uma falha do componente. Failover pode acontecer automaticamente em modelo HA ou parcialmente automatizados depois de uma Declaraçãode Desastre em contextos em modelo DR.

Para um cenário de HA, um RTO pode ser zero ou quase zero, caso a aplicação permitacomponentes redundantes, tais como servidores de bancos de dados em um ambienteRAC, 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 umservidor 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 comsistemas 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 deConsistência Objetiva. O RCO aplica objetivos de consistência de dados para a arquiteturaHA e DR. Seguindo as definições de RPO e RTO, o RCO define uma medida deconsistência dos dados de negócios distribuídos nos sistemas interligados após umincidente 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 deConsistência deRecuperaçãocomparados

RPO= Quanta perda dedados?

RTO= Quantainatividade?

RCO= Consistência detransações de negócioentre sistemas nomesmo “landscape”.

3. Replicação

O conceito geral de qualquer solução de replicação é o de fornecer cópias dos dados deprodução e aplicativos críticos a um ou vários sistemas espelhados no mesmo local (HA) ouem 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 umpassivo.

Existem soluções deréplica ativa / ativa, mascontanto que o aplicativoem si não seja parasuportar talconfiguraçã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 umbanco de dados) dedicados. O banco de dados, propriamente dito, também é baseado emFlat 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 essesarquivos são armazenados e recuperados dos sistemas de armazenamento.



White Paper


Diferentes metodologiascopiam sistemas emdiferentes camadas.

Camadas de banco dedados garantemintegridade do nível dobanco de dados,enquanto a camada dearmazenamento apenasgarante integridade nonível dearmazenamento.

Em seguida, aplicamos esse modelo de camada à réplica síncrona e assíncrona ecomparamos os diferentes níveis de réplica. É fundamental entender como os aplicativosfuncionam e armazenam seus dados em todas as camadas, para obter aplicações úteis edados da aplicação sobre o failover. A réplica pode ser feita em qualquer uma destascamadas. A réplica de armazenamento incidirá sobre o espelhamento e integridade deblocos de armazenamento, enquanto uma Réplica de Arquivo fará o mesmo para osarquivos, 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 é relativamenteirrelevante, até porque o sincronismo no nível de armazenamento se propagará até o nívelde aplicação. Isso faz com que soluções de HA, como clusters de servidores comarmazenamento 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 debanco de dados (cluster de aplicação real, recursos de particionamento direto), aplicaçõescom 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 altalatência de rede e as restrições de banda quando o espelhamento excede grandesdistâncias), nem desejável (adicionando infra-estrutura complexa e restrições de

desempenho na produção). Arquiteturas DR são tipicamente baseadas em RéplicaAssí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ópiascom tempo de atraso (time-delayed mirroring) para cobrir estes incidentes. As diferençassão ilustradas na tabela a seguir:



White Paper


Réplica síncrona Réplica com Atraso

Abrangendo erros deHardware?

Sim Sim

Abrangendo erros deSoftware?

Não Sim

Abrangendo errosoperacionais deusuários?

Não Sim

Abrangendo erroscorrupção de dados?

Não Sim

3.3. Réplica AssíncronaNo momento em que começar a replicar os dados de forma assíncrona, é de sumaimportância, em qual camada (Aplicativo/ Banda de Dados/ Arquivo/ Armazenamento) areplicação está funcionando, e se quaisquer considerações de consistência no nível deaplicaçã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 sistemaespelhado 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ênciaem 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çãona camada de banco de dados (DBShadow) e de arquivos (FSShadow). É estendido comautomatização failover de aplicativos (SwitchApplication) e uma edição especial paraRéplica WAN (Opção de longa distância). BusinessShadow é usado para HA, DR, e váriascombinaçõ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 dasprincipais aplicações.

FSShadow é usado para espelhar dados críticos de aplicações, que não estão retidos nabase de dados, por exemplo, binários, dados de perfil, interface EDI, ou outros aplicativosespecí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 doDBShadow e FSShadow para dar suporte as configurações de Wide Area Network.

Visão geral dosprincipais doscomponentes doBusinessShadow

Todos os componentes estão disponíveis especificamente aos respectivos sistemasoperacionais (HP-UX, IBM AIX, Solaris, Tru64 UNIX, a maioria das distribuições Linux, etodas as plataformas Windows). Grande parte das implementações do Libelle AG sãoespelhamento de aplicativos da SAP AG, com uma edição especial do BusinessShadowpara soluções SAP e Integração Certificada SAP(http://ecohub.sdn.sap.com/irj/ecohub/solutions/BusinessShadow) . Outras implementaçõesincluem Oracle, Microsoft Dynamics, Soluções ERP da Infor Global Solutions, e muitosoutros 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 maissistemas espelhados.



White Paper


Agentes dos servidoresdo DBShadow e doFSShadow comunicam-se entre si, e com umainterface gráfica (GUI),que permitegerenciamentocentralizado, emonitoração daoperação.

Depois que uma réplica é construída inicialmente entre os dois sistemas com uma "CópiaInicial” (Initial Copy), um processo de arquivamento (“Archiver”) coleta alterações em bancode 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 aoRPO - 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 sistemaespelhado está aplicando as alterações que recebe do processo Archiver e aplicando-os emum banco de dados (DBShadow) ou em um sistema de arquivos (FSShadow). Todos osprocessos podem operar de forma independente se um ou outro sistema estiver temporariamente indisponível, e retornar assim que a conexão for restabelecida, masgeralmente 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 siatravés de “sockets” de rede especializada. O Aplicativo Libelle GUI permite interceptar acomunicaçã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 dearquivamento 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 outrasferramentas de gerência de sistemas.

4.2.2. Option Long Distance

Um componente adicional do BusinessShadow é a opção “Option Long Distance” paraestender 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çãoe espelho com latência da rede, normalmente, elevada.

4.2.3. SwitchApplication

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



White Paper


SwitchApplicationfornece uma soluçãopara adicionar e remover IPs Virtuais e servidores(hostnames)automaticamenteatravés do failover doDBShadow ouFSShadow

4.2.4. Console de Gerenciamento GUI (Graphical User interface)

Para permitir um único ponto de controle para o administrador, a Libelle fornece umaInterface Gráfica de Usuário (GUI), que se comunica com qualquer número de Agentes doServidor. 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ênciaou testes de Recuperação de Desastres. Como os agentes do servidor estão fazendo astarefas de replicação, o GUI serve apenas para monitoramento e operação, mas não umaparte ativa do processo de réplica.

Os agentes agem de forma independente e podem enviar mensagens (SMTP ou não), esão geridos também por linha de comando.

BusinessShadow

GUI na Versão 5.

Este exemplo mostra aGUI exibindo seis gruposdo sistema no ladoesquerdo, mostrando ogrupo 'Produção' nomeio.

Cada grupo contémalguns erros.

A marca de verificaçãoverde um status 'ok'. O Xvermelho ilustra "erros"(como base de dadosinativa). Marca de

explicação Amarela,ilustra advertências(‘warnings’ - por exemplo, a falta deespaço em disco)



White Paper


4.3. Cenário de Alta Disponibilidade

O BusinessShadow, para alta disponibilidade, pode fornecer uma réplica local de sistemasespelhados para qualquer sistema de produção. O software pode ser usado como umasolução de failover sem perda de dados para um sistema espelhado com armazenamentocompartilhado, ou solução de perda mínima de dados sem armazenamento compartilhado.

O primeira implementação do BusinessShadow para HA é o conceito de um espelhamentocom atraso (time-delayed) para proteger contra erros de software e / ou usuário. Aarquitetura é baseada em um espelhamento intencionalmente atrasado entre os doissistemas. Alterações do sistema de produção são aplicadas no seu espelho com atraso detempo, por exemplo, 2 ou 4 horas para permitir uma janela de reação no caso de danoscausados por erros de software, erros de usuário, erros de configuração, atualizações desistema mal planejadas ou executadas, e outras situações levando a dados corrompidos ouinutilizáveis.

DBShadow e FSShadowdurante a operaçãonormal.

As transações sãoenfileiradas no sistemaespelhado antes deserem aplicadas,permitindo uma janelade reação para dadoscorrompidos

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, oadministrador vai usar a GUI BusinessShadow ou a interface Shell para uma recuperaçãoautomatizada de cada instante que precedeu o erro ocorrido. Transações equivalentes a umintervalo de quatro horas de transações podem normalmente ser aplicadas em prazo inferior a 20 minutos, dependendo do desempenho do hardware. Comparando isto com aalternativa de uma restauração completa da fita, esta metodologia é a maneira mais rápidapossível para restaurar um sistema após ser corrompido.



White Paper


DBShadow e FSShadowdurante a operação deemergência causadapela corrupção de dados

O sistema espelhadoprovê restauração daaplicação com dadospré-corrupção em estadoconsistente.

Geralmente nós estamos alvejando RTO - Objetivos de Recuperação de Tempo (tempo defailover), que inclui reiniciar o aplicativo, de menos de 25-40 minutos, no caso de umsistema de produção corrompido causado por erros de usuário / software com atraso dequatro horas. Para implementações sem atraso de tempo, Objetivos de Recuperação deTempo 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 notempo, por isso pode variar desde cinco minutos até 4 horas, por exemplo. Será o queAdministrador Libelle quiser ou não recuperar. Uma vez que o administrador decida qual oponto no tempo, todas as tarefas relacionadas ao banco de dados (recuperação, renomeiode banco de dados, tablespaces gerenciadas localmente, etc) serão totalmenteautomatizadas.

Para um failover sem perda de dados, os últimos 5 ou 10 minutos de logs on-line quepodem não ter sido enviados, devem estar localizados em um armazenamentocompartilhado 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 derecuperação de desastres. Os agentes de baixo impacto dos servidores e a baixa exigênciada rede fazem a solução adequada para espelhar qualquer tamanho de ambiente para umlocal remoto. As instalações de DR da podem variar desde uma única aplicação de 400 GB espelhadasobre 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 atrasotem menos importância. O Archiver é geralmente definido baixo o suficiente para atender osRPO’s (por exemplo, máxima de perda de dados de 10-15 minutos no caso de uma falha nosite), 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 dedesempenho na rede e no servidor).

De qualquer maneira, com BusinessShadow espelhando o landscape de aplicativos paraqualquer 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 dosanos 90. O primeiro banco de dados suportado foi o Oracle 6, e como uma empresalocalizada na Alemanha, desde o início sempre tivemos o acesso a uma grande base declientes 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 estendeuseu 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 umaparticipaçã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 (SAPBasis Market).

4.5.2. Requisitos de Landscape SAP

Com a mais moderna arquitetura Netweaver, a SAP AG proveu uma sofisticada arquiteturaorientada a serviços. Funcionalidades adicionais acrescentaram um alto grau decomplexidade em desenho técnico e operação, especialmente se comparadas às anterioresdo SAP/R3, baseadas em uma instalação ABAP “single-stack” com uma ou duas instânciasSAP.

Ao menos que implementemos uma replicação síncrona de 100%, qualquer solução dereplicaçã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. logshipping) vão omitir grande quantidade de dados armazenados em flat files, e por issotambém deverão ter problemas na realização do failover.

A ilustração abaixo mostra como o BusinessShadow é integrado em uma única instânciaSAP. Embora a ilustração mostre um sistema de produção de um “nó”, a maioria dossistemas de clientes são baseados em sistemas de cluster de dois nós.



White Paper


BusinessShadowIntegração típica deInstância SAP

Finalmente, a maioria das instalações SAP é baseada em sistemas múltiplos. Parte doprojeto 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 umprocesso 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 agentesresidentes 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 comoserviç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 emelhorias, e foi instalado e opera em mais de 1000 instalações, sejam pequenas, médias ougrandes. Hoje, são ambientes ativos para espelhar desde pequenos bancos de bados de100GB, ou até banco de dados de 18TB, em instalações de instância única, ou emlandscapes complexos com 50 ou mais servidores, em configurações UNIX e Windows.



White Paper


Agentes do Servidor iDBShadow eFSShadow estão secomunicando com ospróprios soquetes TCP /IP.

A ilustração mostra osprincipais processos“lnitial Copy”, “Archiver”,e “Structure” rodando emprodução e o processo“Recover” em execuçãono espelho.

Depois do failover, ospapéis são invertidos e aréplica vai à direçãooposta.

Os agentes gerenciam a comunicação entre os dois sistemas e são controlados por linha decomando ou interface gráfica do usuário (GUI). Eles guardam informações sobre asatividades em curso na memória compartilhada, podendo ser acessadas por ambos oslados.

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 delog do Oracle 11i ao seu sistema espelhado.

Processo de Recuperação DBShadow para Windows aplica e monitora a recuperação dosbackups dos arquivos de log transacionais com um certo atraso de tempo em seu sistemaespelhado.

FSShadow para Processo Archiver IBM AIX verifica a lista definida de Flat Files emproduçã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 paratransações no-logging, novos arquivos de dados, ou novos diretórios, e atualiza o espelhoem 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 umatela GUI de memóriapartilhada recuperada deum sistema espelhado.A mesma informaçãopode ser recuperadapelo servidor através deum comando shell.

Como o nome indica, ainformação é mantidaem memória nossistemas de produção edo espelho.

Isto permite continuar aoperação deespelhamento apósqualquer interrupção,pois as informaçõesconstam nos doissistemas.

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 problemastípicos na operação de uma LAN ou WAN. Nos parágrafos seguintes, vamos analisar emdetalhe a forma como os processos interagem com o ambiente para permitir umaconfiguraçã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çaspara o sistema espelhado pelo processo Archiver .

Continuamente aplica as alterações do banco de dados de produção para o banco dedados 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 eatualiza o banco de dados espelhado.



White Paper


Os principais processos,“Cópia Inicial”,”Archiver”, e“Recuperação”interagindo comsistemas de produção eseu espelho

Um processo “Estrutura”adicional verifica osdados de produção ecoordena asatualizações de estruturapara o banco de dadosespelhado com o

processo derecuperaçã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 MSSQL Server, por exemplo. O mesmo se aplica aos processos de cópia inicial, recuperação eestrutura em operação normal de réplica, e de operação de failover de emergência, onde osistema espelhado é ativado pelo BusinessShadow.

Esta ilustração mostra oArchiver DBShadowpara banco de dadosOracle.

DBShadow suportaOracle 8i-11g, todasversões de MS SQLServer desde 2000 a2008, a maioria dasversões MaxDB, DB2V7-9, e MySQL

Cada banco de dadostem seus própriosmétodos e

considerações especiais,e o DBShadow os refletena 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. Ocomponente FSShadow mantêm cópias dos flat files para todos os arquivos definidos noprocesso de espelhamento, ou que foram adicionados depois. Inicialmente, o processo deCópia Inicial (Initial Copy) cria uma cópia idêntica de arquivos no sistema espelhado. Emseguida, um processo Flat File Archiver verifica os arquivos do sistema de produção emintervalos customizados, por exemplo, a cada 30 minutos ou a cada 5 minutos, dependendodo 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 nosistema espelhado. Tal como acontece com DBShadow, a arquitetura contempla um tempode 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 dereação em caso de dados de Flat File corrompidos tanto para Alta Disponibilidade quanto

para Recuperação de Desastres.

O FSShadow copiadiretórios completos ouflat files isolados.

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

Uma vez configurado, oFSShadow inicializa aréplica, gerencia

transferência de dadosno sistema espelhado, emonitora 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 filespermitem 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 umaLAN 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 derede com distâncias superiores a 85 kilômetros. Para tratar essas questões, a opção deOption Long Distance ajusta os stacks Libelle TCP / IP com extensões customizadas queincluem:

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 dedados que são enviados, em paralelo, para o sistema espelhado e, em seguida, entregueao banco de dados espelhado.

Tecnologia de Grandes Pacotes: Esta opção “LongDistance” aumenta o tamanho padrãodo pacote TCP/IP. O tamanho padrão dos pacotes é voltado para redes locais e, muitasvezes 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 modode 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 Processaplicam as alterações que recebem do processo Archiver no banco de dados do espelho ouno “File System” do espelho. Durante uma situação de emergência, onde um failover e aativação do sistema espelhado são necessários, o mesmo processo de recuperação vaioperar 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 relacionadasa banco de dados, tais como a execução de uma recuperação automatizada Point-In-Timeaté um determinado momento (customizado). O DBShadow aplicará, então, todos osarquivos de log pendentes.

O processo de recuperação também permite uma troca de função automatizada entreproduçã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 oespelho 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 atrasoconfigurado, clientes podem especificar um time-stamp até qual flat file deve ser recuperadoe, em seguida, fornece ao sistema espelhado a estrutura exata arquivo, como desejado.

BusinessShadow GUIcom a opção de failover para DBShadow paraMS SQL Server.

A parte inferior da telamostra as opções defailover e a imagemacima reflete ossistemas de produção eseu espelho.

As “balas” verdesrepresentam os arquivosde log configurado no“funil do tempo” (timefunnel) com aporcentagem de espaçoem disco utilizado.

A GUI exibe o tempoatual do sistema de cada

servidor e a lista deespelhos do ladoesquerdo.

5.5.2. Libelle SwitchApplication

Outra parte essencial de failover de um ou vários sistemas de um landscape de produçãopara seu espelho é ativar automaticamente os endereços IP e hostnames no destino e - sedesejado pelo cliente – removê-los do sistema origem.

Libelle SwitchApplication é um produto de software baseado em agentes (de servidor) euma 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 eWindows. O processo de adição e remoção de nomes/endereços não exige a reinicializaçãode, por exemplo, um servidor Windows. A ferramenta se compara a uma forma básica deum 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 maioriados clientes, entretanto, já tem software de cluster implementado em seus sistemas deProduçã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 seuespelho, estejam na mesma rede, pois o SwitchApplication não executa nenhum controlesobre roteamento ou tabelas de DNS. Para DR, o cliente poderia implementar uma LANvirtual com a mesma sub-rede. Se não for possível, os sistemas podem ficar em redesseparadas e o failover dos aplicativos é realizado através da atualização de entradas deDNS ou por outros meios.

A ilustração abaixo mostra a implementação de um landscape do BusinessShadow comSwitchApplication implementado na produção – e um espelho para os sistemas “standalone”e implementadas nos sistemas espelhados apenas para os sistemas de produção emcluster.

Integração doBusinessShadow em umlandscape complexoSAP.

SCM mostra duasinstâncias DBShadow,pois o aplicativo tem,tipicamente, um MaxDBe um banco de dadosOracle.

5.5.3. Failover- e Outras Interfaces de Usuários

Todos os componentes BusinessShadow vêm com um conjunto de interfaces de usuáriocustomizáveis que estão vazias no início de uma implementação. A instalação padrão deum sistema espelhado isolado requer apenas pequenas integrações adicionais, como aautomação do failover. Uma implementação de vários espelhos, porém, é muitas vezesestendida 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) ouon-line (execução de um script com opções de feedback), e podem residir em ambos ossistemas, 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 (RemoteTasks - disparam ações no seu parceiro de espelhamento).

Para o failover em si, uma interface central teria acionado antes, durante ou depois oDBShadow, 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 DBShadowFSShadow 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 GUIoferece uma interface central para instalar, configurar e ativar um ou vários sistemasespelhados.

O Menu 'Configurar' doBusinessShadow

destina-se a apoiar umafácil instalação econfiguração para cadaespelho.

Este exemplo mostra aconfiguração de umespelho 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" é aconfiguração de como os agentes devem reagir a “distúrbios” e se erros ou avisos deverãoser enviados por e-mail ou SMTP “traps”. Depois de criadas as configurações deespelhamento, o próximo passo é permitir a monitoração de múltiplos sistemas, comomostrado na próxima figura.



White Paper


O Monitoramento doBusinessShadowpermite uma visão por espelho, grupo ou lista.

Em instalações maiores,características de filtrocom sinalizadores emverde (OK), amarelo(aviso), ou vermelho(erro), permitem umafácil identificação deirregularidades naoperação deespelhamento.

A GUI também coleta eexibe as mensagens doservidor para o sistemaselecionado.

6. Resumo

Neste White Paper apontamos em detalhe os métodos diferentes de espelhamento tantopara Alta Disponibilidade e Recuperação de Desastre.

A Solução Libelle BusinessShadow permite o maior grau possível de consistência em nívelde banco / aplicação, já que o dado é espelhado em nível de banco de dados para todas asprincipais tecnologias de banco de dados. Por outro lado, ele fornece uma solução completapara espelhar diferentes bases de dados em diferentes plataformas e oferece uma soluçãosofisticada para espelhar flat files. Libelle atinge um local único entre replicação dearmazenamento aplicativo-agnóstico / baseada em blocos e soluções de envio de dadoscentrados em log.

Todas as soluções Libelle vêm com um conceito sofisticado de implementação e modelo deoperação para atender qualquer tamanho e grau de complexidade desde uma instalaçãosimples de espelhamento ou landscapes com mais de 100 servidores.

Existe uma grande variedade de funcionalidades, vantagens e conceitos não mencionadosneste White Paper. Entre em contato conosco para que nossos arquitetos de solução econsultores revisem seu landscape para delinear sua solução, implementação e abordagemoperacional 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-90minutos livre e sem obrigações onde nós lhe mostraremos uma simulação de DR de umsistema de produção baseado em um banco de dados de sua escolha e responderemossuas perguntas.



White Paper

North America All other Countries Libelle LLC Libelle AG 3330 Cumberland Blvd. Suite 500 Gewerbestr. 42Atlanta, 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üentesou indiretos decorrentes da leitura ou o uso desta informação não é justificado pela Libelle AG dentro dos limites legais. Todosos direitos autorais, especialmente reprodução, distribuição e tradução, são reservados. Nenhuma parte desta apresentaçãopode 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, seusagentes 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 fornecidasnesta apresentação. Libelle, o logotipo Libelle, BusinessShadow ®, DBShadow FSShadow ® e ® são marcas registradas daLibelle AG, G Alemanha .Todos os outros produtos e empresas mencionados no presente White Paper são marcasregistradas de seus respectivos proprietários.

Whitepaper_BusinessShadow_portugues

Documents

Transcript of Whitepaper_BusinessShadow_portugues