Whitepaper business shadow_portugues
Upcoming SlideShare
Loading in...5
×
 

Whitepaper business shadow_portugues

on

  • 469 views

Solução para Alta Disponibilidade (HA/DR) para ambientes SAP

Solução para Alta Disponibilidade (HA/DR) para ambientes SAP

Statistics

Views

Total Views
469
Views on SlideShare
466
Embed Views
3

Actions

Likes
0
Downloads
2
Comments
0

2 Embeds 3

http://www.linkedin.com 2
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Whitepaper business shadow_portugues Whitepaper business shadow_portugues Document Transcript

  • White PaperAlta disponibilidade (HA) e Recuperação deDesastres (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 Paper1. 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 proporcionarao leitor uma melhor compreensão das informações apresentadas, vamos começar esteWhite Paper, destacando nossos conceitos e métodos.1.1. TerminologiaUsamos 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 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 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 dehardware 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á fornecercapacidade 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%.©Libelle AG. All rights reserved. Printed: October 2010 1/25
  • White Paper1.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 DRNeste 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 CorporativaGeralmente, 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 IT Arquitetura ilustra os componentes críticos para Alta Disponibilidade e Recuperação de Desastres. Negócio Dados Aplicação Tecnologia Infraestrutura©Libelle AG. All rights reserved. Printed: October 2010 2/25
  • White PaperDa perspectiva de recuperação de desastres, todos os componentes de apoio aosprocessos 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 detempo 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çãoAmbos 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çãoO 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 acontecerautomaticamente 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 servidordisponí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©Libelle AG. All rights reserved. Printed: October 2010 3/25
  • White Paperde rede separado. Com um site secundário em hot-standby espelhado, é possível chegarRTO’s de 2 a 4 horas, se procedimentos e tecnologias estiverem em vigor.2.4. Consistência dos Objetivos de RecuperaçãoUm 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 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çãoO 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.©Libelle AG. All rights reserved. Printed: October 2010 4/25
  • 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 / passivo3.1. Camada de Banco de Dados, Camada de Arquivo, e Camada de ArmazenamentoOs aplicativos são principalmente baseados em bancos de dados e “Flat Files” (binários daaplicaçã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.©Libelle AG. All rights reserved. Printed: October 2010 5/25
  • 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 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íncronaCom 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 dedesempenho 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:©Libelle AG. All rights reserved. Printed: October 2010 6/25
  • White Paper Réplica síncrona Réplica com AtrasoAbrangendo erros de Sim SimHardware?Abrangendo erros de Não SimSoftware?Abrangendo errosoperacionais de Não Simusuários?Abrangendo erros Não Simcorrupção de dados?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ê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® ResumoO 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.©Libelle AG. All rights reserved. Printed: October 2010 7/25
  • White Paper4.1. Componentes do SoftwareO 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 BusinessShadowTodos 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 Design4.2.1.DBShadow e FSShadowA 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.©Libelle AG. All rights reserved. Printed: October 2010 8/25
  • 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ó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”, porexemplo, 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 estivertemporariamente 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 DistanceUm 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.SwitchApplicationFinalmente, 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.©Libelle AG. All rights reserved. Printed: October 2010 9/25
  • White Paper SwitchApplication fornece uma solução para adicionar e remover IPs Virtuais e servidores (hostnames) automaticamente através do failover do DBShadow ou FSShadow4.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 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)©Libelle AG. All rights reserved. Printed: October 2010 10/25
  • White Paper4.3. Cenário de Alta DisponibilidadeO 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 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 corrompidosPor outro lado, se um erro humano está corrompendo a base de dados de produção, porexemplo, 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 inferiora 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.©Libelle AG. All rights reserved. Printed: October 2010 11/25
  • 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 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 DesastreA 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 dezenasde 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©Libelle AG. All rights reserved. Printed: October 2010 12/25
  • White Paperdesastres 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 SAP4.5.1.Compromisso da Libelle para o Mercado SAPA 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 ServidorMicrosoft 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 SAPCom 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 causarproblemas 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.©Libelle AG. All rights reserved. Printed: October 2010 13/25
  • White Paper BusinessShadow Integração típica de Instância SAPFinalmente, 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 BusinessShadow5.1. Agentes Centrais do ServidorOs 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.©Libelle AG. All rights reserved. Printed: October 2010 14/25
  • 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 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 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.©Libelle AG. All rights reserved. Printed: October 2010 15/25
  • 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 asreinicializaçõ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 DadosA 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.©Libelle AG. All rights reserved. Printed: October 2010 16/25
  • 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 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 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.©Libelle AG. All rights reserved. Printed: October 2010 17/25
  • White Paper5.3. Espelhamento dos Flat FilesO 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 quantopara 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.©Libelle AG. All rights reserved. Printed: October 2010 18/25
  • White Paper5.4. Otimização em WAN: Option Long DistanceAmbos 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 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 AplicativoLibelle 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ênciaDurante 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©Libelle AG. All rights reserved. Printed: October 2010 19/25
  • White Paperbanco de dados para o nome do banco de dados de produção e executa outras tarefasadicionais, 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 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 SwitchApplicationOutra 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 umsistema 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 failoverFSShadow 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©Libelle AG. All rights reserved. Printed: October 2010 20/25
  • White Paperativar o recurso cluster de endereço de IP, uma vez que o mesmo estiver indisponível naProduçã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 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áriosTodos 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 umgrupo 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 sertão simples como acionar failovers de outro sistema, até executar um plano sofisticado de©Libelle AG. All rights reserved. Printed: October 2010 21/25
  • White Papervários passos de controle e execução de tarefas de failover, que costumavam ser feitasmanualmente.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 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" é 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.©Libelle AG. All rights reserved. Printed: October 2010 22/25
  • 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. ResumoNeste 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-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.©Libelle AG. All rights reserved. Printed: October 2010 23/25
  • 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.©Libelle AG. All rights reserved. Printed: October 2010 24/25