CONTINUIDADE DE NEGÓ CIOS ESSENCIAIS DA EMC PARA SAP

Transcrição

1 White paper CONTINUIDADE DE NEGÓ CIOS ESSENCIAIS DA EMC PARA SAP Gerenciamento simplificado para alta disponibilidade e continuidade de negócios Implementações do SAP essenciais e adaptáveis Datacenters ativo-ativo EMC Solutions Group Resumo Este white paper descreve a transformação de uma implementação tradicional do SAP em uma solução de continuidade de negócios essencial com datacenters do tipo ativo-ativo. A solução é viabilizada pelo EMC VPLEX Metro, EMC Symmetrix VMAX, VMware vsphere High Availability, Oracle RAC, sistema de rede Brocade e SUSE Linux Enterprise Server para aplicativos SAP. Novembro de 2012

2 Copyright 2012 EMC Corporation. Todos os direitos reservados. A EMC assegura que as informações apresentadas neste documento estão corretas na data da publicação. As informações estão sujeitas a alterações sem prévio aviso. As informações nesta publicação são fornecidas "no estado em que se encontram". A EMC Corporation não garante nem representa qualquer tipo de informação contida nesta publicação e especificamente se isenta das garantias implícitas de comercialização ou uso a um propósito específico. O uso, a cópia e a distribuição de qualquer software da EMC descrito nesta publicação exigem uma licença de software. Para obter a lista atualizada de produtos da EMC, consulte "EMC Corporation Trademarks" no site VMware, VMware vsphere, ESXi, vcenter e vmotion são marcas registradas ou comerciais da VMware, Inc. nos Estados Unidos e/ou em outras jurisdições. Brocade, DCX, MLX, VCS e VDX são marcas comerciais ou registradas da Brocade Communications Systems, Inc. nos Estados Unidos e/ou em outros países. Todas as outras marcas comerciais aqui utilizadas pertencem a seus respectivos proprietários. Número da peça H

3 Índice Resumo executivo... 5 Business case... 5 Visão geral da solução... 5 Principais benefícios... 6 Introdução... 7 Finalidade... 7 Escopo... 7 Público-alvo... 7 Terminologia... 7 Visão geral da solução... 9 Introdução... 9 Arquitetura da solução Camadas de proteção Perfil do banco de dados e da carga de trabalho Recursos de hardware Recursos de software Infraestrutura de armazenamento da EMC Introdução EMC Symmetrix VMAX 10K Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX Configuração do VMAX Infraestrutura EMC VPLEX Metro Introdução Mobilidade de dados do VPLEX Configuração da solução VPLEX Metro Configuração do VPLEX Monitoramento de desempenho do VPLEX Infraestrutura virtual do VMware Introdução Implementações do VMware no VPLEX Metro Configuração estendida de cluster VMware Configuração do VMware vsphere HA Configuração do VMware vsphere DRS EMC Virtual Storage Integrator e VPLEX

4 Arquitetura do sistema SAP Introdução Configuração do sistema SAP Configuração do SUSE Linux Enterprise High Availability Extension Arquitetura de banco de dados Oracle Introdução Oracle RAC e VPLEX Configuração do Oracle ACFS Oracle Extended RAC no VPLEX Metro Configuração do grupo de discos do Oracle ASM Infraestrutura de rede da Brocade Introdução Configuração de rede IP Configuração de rede SAN Alta disponibilidade e continuidade de negócios Teste e validação Introdução Falha do processo de serviço de enfileiramento do SAP Falha de máquina virtual da instância do SAP ASCS Falha de nó do Oracle RAC Falha do local Isolamento de cluster VPLEX Conclusão Resumo Resultados Referências EMC Oracle VMware SUSE SAP Apêndice: Exemplos de configuração Configuração de amostra de CRM Perfil de instância de amostra do ASCS Perfil de instância de amostra do ERS Perfil START de amostra do ERS DI sample instance profile

5 Resumo executivo Business case Para continuarem competitivas, as empresas globais exigem disponibilidade ininterrupta das informações e dos aplicativos. A solução da EMC descrita neste white paper oferece uma estratégia de continuidade de negócios e alta disponibilidade para aplicativos essenciais, como SAP ERP. Os RPOs (Recovery Point Objectives, objetivos de ponto de recuperação) e os RTOs (Recovery Time Objectives, objetivos de tempo de recuperação) são medidas-chave durante o planejamento de uma estratégia de continuidade de negócios essenciais. Eles respondem a duas questões fundamentais que as empresas têm quando consideram o possível impacto de um desastre ou falha: Que volume de dados podemos perder (RPO)? Com que rapidez precisamos que o sistema ou o aplicativo seja recuperado (RTO)? A continuidade de negócios essencial para SAP exige RPOs e RTOs agressivos para minimizar a perda de dados e o tempo de recuperação. Os principais desafios que as empresas devem considerar ao elaborar uma estratégia incluem: Minimizar o RPO e o RTO Eliminar SPOFs (Single Points of Failure, pontos únicos de falha): Tecnologia, pessoas, processos Maximizar a utilização de recursos Reduzir custos de infraestrutura Gerenciar a complexidade da integração, da manutenção e de testes de várias soluções pontuais Este white paper apresenta uma solução da EMC que supera todos esses desafios para aplicativos SAP ERP com uma camada de banco de dados Oracle RAC (Real Applications Clusters) 11g. A solução demonstra um modelo inovador de implementação ativo/ativo para datacenters a até 100 km de distância. Isso transforma o modelo de DR (Disaster Recovery, recuperação de desastres) ativo/passivo tradicional em uma solução de continuidade de negócios com alta disponibilidade de aplicativos (24 horas por dia, 7 dias por semana), sem nenhum ponto único de falha e com RTOs e RPOs próximos de zero. Visão geral da solução O EMC VPLEX Metro é a principal tecnologia de ativação desta solução. O VPLEX Metro é uma solução de federação baseada em SAN que fornece federação local e distribuída de armazenamento. Sua tecnologia inovadora, AccessAnywhere TM, permite que os mesmos dados existam em dois locais geograficamente separados e sejam acessados e atualizados em ambos os locais ao mesmo tempo. Com a adição do VPLEX Witness à solução, os aplicativos continuam disponíveis, sem nenhuma interrupção ou tempo de inatividade, nem mesmo em caso de interrupção em um dos datacenters. O white paper demonstra como as seguintes tecnologias criam essa solução inovadora de continuidade de negócios: O EMC VPLEX Metro fornece a camada de armazenamento virtual que ativa um datacenter Metro ativo-ativo. 5

6 A mobilidade de dados do VPLEX permite uma movimentação dos dados que não causa interrupções na camada de armazenamento. O EMC VPLEX Witness dá suporte à disponibilidade contínua de aplicativos, até mesmo em caso de interrupção em um dos datacenters. Os storage arrays EMC Symmetrix série VMAX 10K com Enginuity, a disponibilidade comprovada de 99,999%, o suporte para FAST (Fully Automated Storage Tiering, armazenamento com classificação totalmente automatizada por níveis) e uma escolha de tecnologias de replicação fornecem a solução às plataformas de armazenamento de nível corporativo. A migração de um banco de dados de instância única para Oracle RAC em clusters de longa distância remove pontos únicos de falha na camada do banco de dados, à distância. O VMware vsphere virtualiza os componentes de aplicativo SAP e eliminaos como pontos únicos de falha. O VMware High Availability (HA) protege as máquinas virtuais no caso de falhas do servidor físico e dos sistemas operacionais. O SUSE Linux Enterprise Server pra aplicativos SAP com SUSE Linux Enterprise High Availability Extension e SAP Enqueue Replication Server (ERS) protege os serviços centrais do SAP (servidor de mensagens e servidor de enfileiramento) em dois nós de cluster para eliminar esses serviços como pontos únicos de falha. Os fabrics Brocade Ethernet e os roteadores de núcleo MLXe fornecem um sistema de rede perfeito e extensão Layer2 entre locais. Os backbones Brocade DCX 8510 oferecem infraestrutura redundante de SAN, incluindo extensão de fabric. Principais benefícios A solução aumenta a disponibilidade dos aplicativos SAP da seguinte maneira: Com a eliminação de pontos únicos de falha em todas as camadas no ambiente para criar um sistema SAP distribuído e altamente disponível Com o fornecimento de datacenters ativo-ativo com suporte para RPOs e RTOs próximos de zero e continuidade de negócios essenciais Os benefícios adicionais incluem: O Symmetrix VMAX 10K oferece ambientes de armazenamento validados e confiáveis para SAP Tratamento de falhas totalmente automático Melhor utilização de ativos de hardware e software: Uso ativo/ativo de ambos os datacenters Balanceamento de carga automático entre datacenters Manutenção com zero tempo de inatividade Gerenciamento simplificado de alta disponibilidade do SAP Implementação simplificada do Oracle RAC em clusters de longas distâncias Redução dos custos com o aumento da automação e a utilização da infraestrutura Movimentação rápida e fácil de dados entre storage arrays 6

7 Introdução Finalidade Este white paper descreve uma solução que aumenta a disponibilidade de aplicativos SAP criando datacenters do tipo ativo-ativo em locais geograficamente separados e eliminando pontos únicos de falha em todas as camadas no ambiente. Nos ambientes SAP, a interrupção dos negócios pode ocorrer devido a falhas técnicas, lógicas ou logísticas. Esta solução aborda a continuidade de negócios de uma perspectiva técnica. Escopo O escopo do white paper é para: Apresentar as tecnologias de habilitação principais Descrever a arquitetura e o design da solução Descrever como os principais componentes são configurados Apresentar os resultados dos testes executados para demonstrar a eliminação de pontos únicos de falha em todas as camadas no ambiente Identificar os benefícios de negócios principais para a solução Público-alvo Terminologia Este white paper destina-se a Administradores Basis SAP, DBAs Oracle, administradores de armazenamento, arquitetos de TI e gerentes técnicos responsáveis pelo projeto, criação e gerenciamento de aplicativos SAP essenciais em ambientes 24 horas por dia, 7 dias por semana. Este white paper inclui os termos em Tabela 1. Tabela 1. Termo AAS ABAP ACFS ASCS ASM CIFS CNA CRM DI DPS DRS dvswitch DWDM ERP ERS FAST VP FCoE Terminologia Descrição Servidor de aplicativos adicional do SAP SAP Advanced Business Application Programming Oracle ASM Cluster File System Serviços centrais do ABAP SAP Gerenciamento de armazenamento automático Oracle Common Internet File System (sistema comum de arquivos da Internet) Adaptador de rede convergente Gerenciador de recursos do cluster Instância de diálogo Seleção de caminho dinâmico VMware vsphere Distributed Resource Scheduler vsphere distributed switch Dense wavelength division multiplexing (Multiplexação densa por divisão de comprimento de onda) Planejamento de recursos corporativos Enqueue Replication Server Fully Automated Storage Tiering for Virtual Pools (armazenamento com classificação totalmente automatizada por níveis para pools virtuais) Fibre Channel over Ethernet (Fibre Channel sobre Ethernet) 7

8 Termo FEC FRA HA HAIP HBA IDES ISL LACP LAG LLDP LUW MCT MPLS MPP NAS NFS NL-SAS OCR Oracle Extended RAC RAC RFC RPO RTO SAN SBD SFP SLES SLE HAE SMT SPOF STONITH TAF ToR VCS vlag vlan VMDK VMFS VMware HA VPLS VPN VRF VSI Descrição Forward Error Correction (Correção antecipada de erros) Flash Recovery Area (Área de recuperação flash) Alta disponibilidade Highly available virtual IP (IP virtual altamente disponível) Adaptadores de barramento do host SAP Internet Demonstration and Evaluation System Inter Switch Link (link entre switches) Link Aggregation Control Protocol Link Aggregation Group Link Layer Discovery Protocol Logical Unit of Work Troncos Multi-Chassis Rótulo de Multi-Protocol Multipathing plug-in Armazenamento conectado à rede Network file system SAS near-line (Serial Attached SCSI) Oracle Cluster Registry Oracle RAC em clusters de longa distância Real Application Clusters (clusters de aplicativos reais) Chamada de função remota Objetivo de ponto de recuperação Objetivo de tempo de recuperação SAN STONITH Block Device Small Form Factor Pluggable (conectável com fator de forma pequeno) SUSE Linux Enterprise Server SUSE Linux Enterprise High Availability Extension Ferramenta de gerenciamento de assinatura Ponto único de falha Shoot The Other Node In The Head Transparent Application Failover Top-of-Rack Virtual Cluster Switch Virtual Link Aggregation Group LAN Virtual Disco virtual Virtual Machine File System Alta disponibilidade do VMware Virtual Private LAN Service Virtual Private Network (Rede virtual privada) Virtual Routing and Forwarding Virtual Storage Integrator 8

9 Visão geral da solução Introdução Implementações do SAP: O desafio e a solução As implementações tradicionais do SAP têm vários SPOFs (Single Points of Failure, pontos únicos de falha), inclusive: Serviços centrais Servidor de enfileiramento* Servidor de mensagens* Servidor de banco de dados Implementação de local único Armazenamento em disco local * Nesta solução, os servidores de enfileiramento e de mensagens são implementados como serviços na instância de ASCS (ABAP SAP Central Services, serviços centrais do ABAP SAP). Este white paper apresenta uma solução para o aumento da disponibilidade de aplicativos SAP. A arquitetura e os componentes da solução criam uma solução em cluster ativo-ativo para toda a pilha SAP, com o objetivo de aprimorar a confiabilidade e a disponibilidade ao simplificar a implementação e o gerenciamento do ambiente. Essa solução oferece os seguintes benefícios: Elimina pontos únicos de falha em todas as camadas no ambiente para criar um sistema SAP distribuído e altamente disponível Fornece datacenters do tipo ativo-ativo para permitir a continuidade de negócios essenciais Figura 1 Ilustra os pontos únicos de falha em um ambiente SAP e os componentes de solução usados para abordá-los. Figura 1. Implementações do SAP: O desafio e a solução 9

10 Arquitetura da solução As seções a seguir descrevem as soluções implementadas em cada camada do ambiente para fornecer alta disponibilidade e continuidade de negócios, conforme mostrado em Figura 2. Figura 2. A jornada para a alta disponibilidade visão lógica Alta disponibilidade da camada de armazenamento Todo o armazenamento necessário por servidor no ambiente foi movido para storage arrays VMAX 10K e VMAX 20K corporativos. Os backbones Brocade 8510 foram implantados para oferecer um SAN fabric redundante para acesso ao armazenamento. Isso permite aproveitar o tempo de funcionamento comprovado de 99,999% oferecido pelos arrays e os Backbones de SAN, incluindo sua capacidade de gerenciamento avançada e recursos de continuidade de negócios. Figura 3. Storage HA Alta disponibilidade de banco de dados O servidor de banco de dados é o repositório de dados para o aplicativo SAP. Para essa solução, o banco de dados de back-end foi convertido de um banco de dados Oracle de instância única em cluster Oracle RAC de quatro nós. Isso elimina o servidor de banco de dados como ponto único de falha. Figura 4. Database HA 10

11 Alta disponibilidade de aplicativo SAP Os servidores de aplicativos SAP foram totalmente virtualizados com o VMware ESXi TM 5.0. Todas as máquinas virtuais SAP foram implementadas com o SUSE Linux Enterprise Server para aplicativos SAP 11 SP1 como o sistema operacional guest. O SUSE Linux Enterprise High Availability Extension e o SAP Enqueue Replication Server (ERS) também foram implementados para proteger tanto o servidor de mensagens SAP quanto o servidor de enfileiramento. Isso elimina os ASCS (Serviços Centrais ABAP SAP) como um ponto único de falha. Figura 5. Alta disponibilidade de aplicativo SAP Alta disponibilidade de datacenter A solução de cluster de alta disponibilidade descrita acima protege o SAP no datacenter. Para obter alta disponibilidade entre datacenters, a solução usa a tecnologia de virtualização de armazenamento EMC VPLEX Metro, conforme mostrado na Figura 6. A tecnologia exclusiva de cluster ativo-ativo VPLEX Metro Access Anywhere permite o acesso de leitura e gravação a volumes distribuídos em distâncias síncronas. Com o espelhamento de dados entre locais, o VPLEX permite que os usuários em ambos os locais acessem as mesmas informações ao mesmo tempo. Figura 6. Alta disponibilidade de datacenter Esta solução combina o VPLEX Metro com o SUSE Linux Enterprise High Availability Extension (na camada do sistema operacional) e Oracle RAC (na camada do banco de dados) para remover o datacenter como um ponto único de falha e oferece uma estratégia de continuidade de negócios robusta para aplicativos essenciais. 11

12 O Oracle RAC em clusters de longa distância sobre VPLEX oferece estes benefícios: O VPLEX simplifica o gerenciamento do Extended Oracle RAC, pois a alta disponibilidade entre locais é embutida no nível da infraestrutura. Para o Oracle DBA, a instalação, a configuração e a manutenção são exatamente iguais às da implementação de único local do Oracle RAC. O VPLEX elimina a necessidade de espelhamento baseado em host de discos ASM e os ciclos de CPU do host que consome. Com o VPLEX, os grupos de discos do ASM são configurados com redundância externa e são protegidos pelo espelhamento distribuído do VPLEX. Os hosts precisam se conectar ao seu cluster VPLEX local somente e o I/O é enviado somente uma vez desse nó. No entanto, os hosts têm acesso completo de leitura/gravação ao mesmo banco de dados em ambos os locais. Com o espelhamento baseado em host de grupos de discos do ASM, cada I/O de gravação deve ser enviado duas vezes, uma para cada espelho. Não é necessário implantar um Voting Disk Oracle em um terceiro local para atuar como um dispositivo de quórum no nível do aplicativo. O VPLEX permite criar grupos de consistência que protegerão vários bancos de dados e/ou aplicativos como uma unidade. A solução usa o VPLEX Witness para monitorar a conectividade entre os dois clusters VPLEX e assegurar a disponibilidade contínua no caso de uma falha de partição de rede entre clusters ou uma falha de cluster. O VPLEX Witness é implementado em uma máquina virtual em um terceiro domínio de falha separado (Local C). Alta disponibilidade de rede Em cada datacenter, um fabric Ethernet foi criado com a tecnologia Brocade VCS (Virtual Cluster Switch, switch de cluster virtual), que oferece uma camada de acesso de autocorreção e flexível com todo o encaminhamento de links. Os vlags (Virtual Link Aggregation Groups, grupos de agregação de links virtuais) conectam os fabrics VCS aos roteadores de núcleo Brocade MLXe que estendem a rede da Camada 2 aos dois datacenters. Figura 7 mostra a arquitetura física de todas as camadas da solução, incluindo os componentes de rede. 12

13 Figura 7. Arquitetura da solução 13

14 Camadas de proteção Tabela 2 resume as camadas de HA (High Availability, alta disponibilidade) que a solução usa para eliminar os pontos únicos de falha. Tabela 2. Alta disponibilidade local Alta disponibilidade local Armazenamento Local Componentes protegidos VMware HA e VMware DRS A e B Máquinas virtuais SAP SUSE Linux Enterprise HAE e SAP Enqueue Replication Server Várias instâncias de diálogo do SAP A e B A e B Servidor de enfileiramento SAP, servidor de mensagens SAP Processos de trabalho do SAP (DIA, UPD, UP2, SPO) VMware A, B e C Virtualização de servidor RAC Oracle A e B Oracle Database Oracle Clusterware A e B File system compartilhado SAP Oracle ACFS EMC Symmetrix VMAX 20K EMC Symmetrix VMAX 10K A e B A B SAP Oracle Home, diretório global SAP, diretório de transporte SAP, diretório ASCS SAP Armazenamento local, RAID, múltiplos caminhos Armazenamento local, RAID, múltiplos caminhos Em seguida, o VPLEX Metro estende a alta disponibilidade com uma arquitetura em cluster que ultrapassa os limites do datacenter e permite que os servidores em vários datacenters tenham acesso de leitura/gravação a dispositivos de armazenamento em block compartilhado. Essa transformação de datacenter eleva a alta disponibilidade tradicional a um novo nível de continuidade de negócios essenciais. Figura 8 ilustra esse design de alta disponibilidade, com o VPLEX Witness e a interconexão de clusters implementados para oferecer o nível mais alto de flexibilidade. 14

15 Figura 8. Alta disponibilidade local com VPLEX que permite a continuidade remota de negócios As tecnologias mostradas na Figura 8 são analisadas com mais detalhes nas seções relevantes do white paper. Perfil do banco de dados e da carga de trabalho Tabela 3 detalha o perfil do banco de dados e da carga de trabalho para a solução. Tabela 3. Perfil do banco de dados e da carga de trabalho Característica do perfil Detalhes Número de bancos de dados 1 Tipo de banco de dados Tamanho do banco de dados Nome do banco de dados RAC Oracle Perfil da carga de trabalho SAP OLTP 500 GB VSE 4 nós físicos Processos order-to-cash personalizados do SAP 15

16 Recursos de hardware Tabela 4 detalha os recursos de hardware para a solução. Tabela 4. Ambiente de hardware da solução Finalidade Quantidade Configuração Armazenamento (Local A) 1 Symmetrix série VMAX 20K com Enginuity: 2 engines 171 drives FC de 450 GB 52 drives SATA de 2 TB Armazenamento (Local B) 1 Symmetrix série VMAX 10K com Enginuity: 1 engine 30 drives NL-SAS de 2 TB 79 drives SAS de 600 GB Federação de armazenamento distribuído Servidores de banco de dados Oracle RAC Servidores VMware ESXi para SAP Servidor VMware ESXi para VPLEX Witness Switch de rede e plataforma de roteamento 2 Cluster VPLEX Metro, com: 2 engines VS2 4 4 CPUs de oito núcleos, 128 GB de RAM 4 2 CPUs de quatro núcleos, 128 GB de RAM 2 2 CPUs de dois núcleos, 48 GB de RAM 2 Backbone Brocade DCX 8510, com: Cartão de extensão de FC Fx blades de FC de 48 portas com suporte para velocidade de linha de FC de 16 Gb Roteador Brocade MLXe 4 Brocade VDX 6720 no modo VCS 16

17 Recursos de software Tabela 5 detalha os recursos de software para a solução. Tabela 5. Ambiente de software da solução Software Versão Finalidade EMC Enginuity Enginuity 5876 Q SR Ambiente operacional para Symmetrix VMAX EMC VPLEX GeoSynchrony 5.1 Patch 2 Ambiente operacional VPLEX EMC VPLEX Witness 5.1 Patch 2 Componente de monitoramento e arbitragem para manuseio de falha de cluster VPLEX e perda de comunicação entre clusters EMC Unisphere TM 5.1 Software de gerenciamento de VPLEX EMC Unisphere T Software de gerenciamento do VMAX EMC VSI (Virtual Storage Integrator) Integração de armazenamento VMware EMC PowerPath/VE 5.7 P01 (build 2) Software com múltiplos caminhos SUSE Linux Enterprise Server para aplicativos SAP, incluindo SUSE Linux Enterprise High Availability Extension 11 SP1 Sistema operacional para todos os servidores no ambiente VMware vsphere 5.0 atualização 1 Hipervisor que hospeda todas as máquinas virtuais Oracle Database 11g (com Oracle RAC e Oracle Grid Infrastructure) Enterprise Edition Software de cluster e banco de dados Oracle SAP ERP 6.04 Sistema SAP ERP IDES 17

18 Infraestrutura de armazenamento da EMC Introdução Visão geral Esta seção descreve a infraestrutura de armazenamento para a solução: Um array Symmetrix VMAX 20K array oferece a plataforma de armazenamento no Local A Um array Symmetrix VMAX 10K array oferece a plataforma de armazenamento no Local B Os dois arrays de armazenamento são implementados com uma configuração de LUN correspondente. EMC Symmetrix VMAX 10K O Symmetrix VMAX 10K é uma nova plataforma de armazenamento corporativo criado para fornecer os principais recursos de armazenamento virtual de high-end a um número crescente de organizações de TI e provedores de serviço com requisitos exigentes de armazenamento e recursos limitados. O VMAX 10K foi projetado para instalação, configuração e uso fáceis. Ele é ideal para os clientes que precisam melhorar o desempenho no modo de falha e é uma entrada ideal para uma infraestrutura de armazenamento baseada no Symmetrix. Ao aproveitar a Virtual Matrix Architecture, o VMAX 10K oferece confiabilidade de nível corporativo, disponibilidade e facilidade de manutenção. O VMAX 10K também inclui pré-configuração para fácil instalação no mesmo dia em que o array é recebido, com uma instalação que leva menos de quatro horas. O VMAX 10K é um sistema 100% provisionado virtualmente. O Virtual Provisioning faz com que um host, aplicativo ou file system pareçam ter uma quantidade de armazenamento maior do que a fornecida fisicamente. O armazenamento físico só é alocado quando os dados são gravados e não quando o aplicativo é configurado pela primeira vez. Ele elimina os cálculos manuais e também pode reduzir os custos de energia e refrigeração, diminuindo a quantidade de armazenamento ocioso no array. A adição do FAST VP ao armazenamento hierárquico totalmente automatizado facilita a instalação e a operação diária para organizações de TI com recursos e equipe de TI limitados. Criado com base na integração de VMware líder do setor da EMC, agora, o VMAX 10K oferece um armazenamento corporativo ainda mais eficiente graças à nova integração com a plataforma de infraestrutura de nuvem do VMware vsphere 5. O EMC Virtual Storage Integrator (VSI) for VMware simplifica o processo de integração do armazenamento da EMC em um ambiente virtualizado. O ambiente operacional EMC Enginuity fornece a inteligência que controla todos os componentes em um array VMAX 10K. 18

19 Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX O ambiente operacional Enginuity 5876 Q SR fornece a inteligência que controla todos os componentes em um storage array EMC Symmetrix. O Enginuity é um SOE (Storage Operating Environment, ambiente operacional de armazenamento) inteligente, multitarefas e preventivo que controla o fluxo de dados de armazenamento. Ele dedica-se inteiramente às operações de armazenamento e é otimizado para os níveis de serviço exigidos em ambientes high-end. Essa versão do Enginuity tem foco no seguinte: Facilidade de uso, gerenciamento Multi-tenancy Otimização VMAX 10K O VMAX 20K oferece um equilíbrio perfeito entre a facilidade de uso, o desempenho, a alta disponibilidade e o preço para empresas menores ou clientes de nível intermediário superiores que precisam de um design de armazenamento com vários controladores. O VMAX 20K oferece níveis mais altos de escala, capacidade e desempenho para clientes com requisitos mais exigentes. Todos os sistemas VMAX foram criados com base no Virtual Matrix Architecture padrão do setor, executam o mesmo código Enginuity e compartilham uma única interface para o gerenciamento centralizado: EMC Unisphere for VMAX. O Unisphere for VMAX é uma GUI de interface que oferece uma experiência comum aos usuários da EMC nas plataformas de armazenamento. O Unisphere for VMAX permite que os clientes provisionem, gerenciem e monitorem facilmente os ambientes de VMAX, conforme mostrado na Figura 9. Figura 9. Unisphere for VMAX 19

20 Configuração do VMAX Layout do armazenamento Para a solução, o VPLEX Metro, o Oracle Extended RAC e os volumes SAP são distribuídos com o uso do Virtual Provisioning. Essa configuração coloca os arquivos de dados Oracle e arquivos de registro em thin-pools separados e permite que cada um deles use proteção de RAID distinta. Os arquivos de dados residem em um pool RAID 5 protegido e os redo logs ficam em um pool RAID 1 protegido. O armazenamento não foi pré-alocado para nenhum dispositivo, exceto para os dispositivos de REDO log Oracle. A EMC recomenda que esses dispositivos sejam totalmente pré-alocados durante a criação, usando a alocação persistente. Isso assegura que seu armazenamento esteja disponível com antecedência e, se uma recuperação de espaço nulo for executada no pool em qualquer estágio, sua capacidade pré-alocada não seja retornada ao espaço livre do pool. Figura 10 é uma representação lógica do modo como o layout de armazenamento corresponde aos grupos de discos do Oracle ASM. Figura 10. Grupos de armazenamento e grupos de discos do ASM Tabelas de dispositivos Tabela 6 mostra o tamanho e o número de dispositivos configurados para cada grupo de discos do ASM. Tabela 6. Tamanhos de dispositivos Grupo de armazenamento Número de dispositivos OCR 5 8 FRA 4 16 REDO 8 16 DADOS ACFS 4 16 Tamanho do dispositivo (GB) 20

21 Tabela 7 mostra o tamanho e o número de dispositivos configurados para VPLEX Metro. Tabela 7. Tamanho e número de dispositivos configurados para VPLEX Metro Dispositivo VPLEX Número de dispositivos Metadados VPLEX 2 80 Volume de registro VPLEX 2 20 Backup de metadados VPLEX 2 80 Tamanho do dispositivo (GB) 21

22 Infraestrutura EMC VPLEX Metro Introdução Visão geral Esta seção descreve a infraestrutura VPLEX Metro para a solução, que abrange os seguintes componentes: Cluster EMC VPLEX Metro em cada datacenter (Local A e Local B) EMC VPLEX Witness em um domínio de falha separado (Local C) EMC VPLEX O EMC VPLEX é uma solução de virtualização de armazenamento para arrays EMC e não EMC. A EMC fornece o VPLEX em três configurações para lidar com as necessidades de alta disponibilidade e mobilidade de dados do cliente, conforme mostrado na Figura 11: VPLEX local VPLEX Metro VPLEX Geo Figura 11. Topologias VPLEX Para obter descrições detalhadas dessas configurações VPLEX, consulte os documentos listados em Referências na página 72. EMC VPLEX Metro Essa solução usa o VPLEX Metro, que usa uma arquitetura de clustering exclusiva para ajudar os clientes a ultrapassar os limites do datacenter e permitir que os servidores em vários datacenters tenham acesso simultâneo de leitura/gravação a dispositivos de armazenamento em block compartilhado. O VPLEX Metro oferece acesso em nível de block ativo-ativo aos dados em dois locais em distâncias síncronas com um tempo de ida e volta de até 5 ms. EMC VPLEX Witness O VPLEX Witness é um servidor externo opcional que é instalado como uma máquina virtual em um domínio de falha separado dos clusters VPLEX. O VPLEX Witness se conecta a ambos os clusters VPLEX usando uma VPN (Virtual Private Network, rede virtual privada) sobre a rede IP de gerenciamento; isso requer um tempo de ida e volta que não exceda 1 segundo. 22

23 Reconciliando as próprias observações com as informações relatadas periodicamente pelos clusters, o VPLEX Witness possibilita que o cluster ou os clusters distingam entre falhas de partição de rede entre clusters e falhas de clusters, retomando automaticamente o I/O no local apropriado. A semântica de manuseio de falha do VPLEX Witness se aplica apenas aos volumes distribuídos em um grupo de consistência e somente quando as regras de dissociação identificam um cluster preferencial estático para o grupo de consistência (consulte Grupos de consistência do VPLEX na página 24 para obter mais detalhes). EMC Unisphere for VPLEX Você pode gerenciar e administrar um ambiente VPLEX com a GUI baseada na Web do Unisphere for VPLEX (conforme mostrado na Figura 12) ou pode se conectar diretamente a um servidor de gerenciamento e iniciar uma sessão do VPlexcli (interface de linha de comando do VPLEX). Figura 12. EMC Unisphere for VPLEX Alta disponibilidade do EMC VPLEX O VPLEX Metro permite a mobilidade de aplicativos e dados e, quando configurado com o VPLEX Witness, fornece uma infraestrutura de alta disponibilidade para aplicativos em cluster, como o Oracle RAC. O VPLEX Metro permite criar um cluster estendido ou ampliado, como se fosse um cluster local, e remove o datacenter como um ponto único de falha. Além disso, como os dados e os aplicativos estão ativos em ambos os locais, a solução oferece uma estratégia de continuidade de negócios simples. Ao usar uma configuração de interconexão de clusters VPLEX, você pode obter um grau de disponibilidade ainda mais alto. Nesse caso, cada host é conectado aos clusters VPLEX em ambos os locais. Isso assegura que, no improvável caso de uma falha total de cluster VPLEX, o host terá um caminho alternativo para o cluster VPLEX restante. 23

24 Estruturas de armazenamento lógicas do VPLEX O VPLEX encapsula os dispositivos de storage array físicos tradicionais e aplica camadas de abstração lógica a essas LUNs exportadas, conforme mostrado na Figura 13. Volumes virtuais Dispositivo Dispositivo Extent Volume de armazena mento Figura 13. Estruturas de armazenamento lógicas do VPLEX Um volume de armazenamento é uma LUN exportada de um array e encapsulada pelo VPLEX. Um extent é o mecanismo que o VPLEX usa para dividir os volumes de armazenamento e pode utilizar toda ou parte da capacidade do volume de armazenamento subjacente. Um dispositivo encapsula um extent ou combina vários extents ou outros dispositivos em um dispositivo maior com um tipo de RAID específico. Um dispositivo distribuído é um dispositivo que encapsula outros dispositivos de dois clusters VPLEX separados. Na camada superior de armazenamento VPLEX, as estruturas são volumes virtuais. Eles são criados com base em um dispositivo de nível superior (um dispositivo ou dispositivo distribuído) e sempre usam a capacidade total do dispositivo de nível superior. Volumes virtuais são os elementos que o VPLEX expõe aos hosts usando suas portas de front-end. O VPLEX apresenta um volume virtual a um host por meio de uma exibição de armazenamento. O VPLEX pode encapsular dispositivos em storage arrays heterogêneos, incluindo dispositivos thin provisionados virtualmente e LUNs tradicionais. Grupos de consistência do VPLEX Os grupos de consistência agregam volumes virtuais em conjunto para que as mesmas regras de desanexação e outras propriedades possam ser aplicadas a todos os volumes no grupo. Existem dois tipos de grupo de consistência: Grupos de consistência síncronos: Usados no VPLEX Local e no VPLEX Metro para aplicar as mesmas regras de desanexação e outras propriedades a um grupo de volumes em uma configuração. Isso simplifica a configuração e a administração em sistemas grandes. 24

25 Os grupos de consistência síncronos usam armazenamento em cache write through (conhecido como modo de cache síncrono) e, com o VPLEX Metro, têm suporte nos clusters separados por até 5 ms de latência. O VPLEX Metro envia gravações para os volumes de armazenamento de back-end e confirma uma gravação no aplicativo somente quando os volumes de armazenamento de back-end em ambos os clusters confirmam a gravação. Grupos de consistência assíncronos: Usados para volumes distribuídos no VPLEX Geo, em que os clusters podem ser separados por até 50 ms de latência. Regras de desanexação Regras de desanexação são regras predefinidas que determinam a semântica de processamento de I/O para um grupo de consistência quando a conectividade com um cluster remoto é perdida, por exemplo, no caso de um particionamento de rede ou falha de cluster remoto. Os grupos de consistência síncrona dão suporte às seguintes regras de desanexação para determinar o comportamento de cluster durante uma falha: A regra de preferência estática identifica um cluster preferencial A regra de nenhum vencedor automático suspende o I/O em ambos os clusters Quando a conectividade entre clusters é perdida, a regra de desanexação configurada é chamada automaticamente. No entanto, o VPLEX Witness pode ser implantado para substituir a regra de preferência estática e assegurar que o cluster não preferencial permaneça ativo se o cluster preferencial falhar. Mobilidade de dados do VPLEX Visão geral O recurso de mobilidade de dados do VPLEX permite que os elementos de armazenamento, extent ou dispositivos, sejam migrados sem causar interrupções dentro de clusters ou entre eles. A mobilidade de dados oferece as seguintes vantagens: Consolidação de datacenters Migração rápida de dados entre datacenters Mover e realocar aplicativos e dados à distância Migração de dados entre arrays diferentes para: Realocar um dispositivo "dinâmico" do armazenamento mais lento para o mais rápido Realocar um dispositivo "inativo" do armazenamento mais rápido para o mais lento Desativar um volume de armazenamento ou array 25

26 Migrações de extent Use as migrações de extent para mover dados entre extents no mesmo cluster. Os volumes de armazenamento podem ser localizados nos mesmos arrays ou em outros. Figura 14 ilustra a migração de extent. Figura 14. Migração de extent em um cluster VPLEX Migração de dispositivo Os dispositivos não distribuídos do tipo RAID 0, RAID 1 ou RAID C podem usar a migração de dispositivo para mover dados entre dispositivos no mesmo cluster ou em clusters diferentes. Os dispositivos podem ser embutidos em um ou vários extents ou dispositivos. Figura 15 ilustra a migração de dispositivo. Figura 15. Migração de um dispositivo em clusters VPLEX ou entre eles Essa solução usa dispositivos distribuídos. Para esse tipo de dispositivo, as migrações de extent são usadas para migrar o extent subjacente em cada trecho do dispositivo. Não há suporte para migrações de dispositivo entre dispositivos distribuídos. 26

27 Configuração da mobilidade de dados Os pré-requisitos para o dispositivo ou extent de destino são os seguintes: O destino deve ser do mesmo tamanho ou maior do que o dispositivo ou extent de origem. Se o destino for maior do que a origem, o espaço extra não poderá ser usado. O destino não deve ter nenhum volume existente nele. Os trabalhos de mobilidade de dispositivos e extent podem ser criados, executados e monitorados a partir de: VPLEX CLI: As migrações podem ser executadas como trabalhos de uso único ou como trabalhos em lotes com arquivos de plano de migração reutilizáveis. Consulte o EMC VPLEX CLI Guide para obter mais informações. GUI do Unisphere for VPLEX: A GUI não dá suporte a trabalhos de mobilidade em lotes. No entanto, é possível migrar vários extents/dispositivos com o uso de um assistente. Em um cluster VPLEX, até 25 migrações locais e 25 migrações distribuídas podem estar em andamento ao mesmo tempo. As migrações além desses limites ficarão enfileiradas até uma migração existente ser concluída. Figura 16 mostra a criação de vários trabalhos de mobilidade de extent com o assistente de Mobilidade de extent no Unisphere for VPLEX. Também mostra os trabalhos que estão sendo executados e o status do trabalho. Figura 16. Criação e monitoramento de trabalhos de mobilidade de extent 27

28 Mobilidade de dados nesta solução Esta solução usa uma infraestrutura existente do VPLEX Metro. Como parte de uma atualização de tecnologia, os storage arrays de back-end foram trocados e substituídos pelos arrays VMAX. Os trabalhos de mobilidade de dados VPLEX foram usados para migração de dados sem causar interrupção dos arrays originais para os novos arrays. Os sistemas, nesse caso, os servidores ESXi e as máquinas virtuais, foram ligados e estão disponíveis durante toda a migração, como mostrado na Figura 17. Figura 17. Os servidores ESXi, as máquinas virtuais e os datastores estão disponíveis durante a migração Configuração da solução VPLEX Metro Estruturas de armazenamento Figura 18 mostra a estrutura de armazenamento físico e lógico usado pelo VPLEX Metro no contexto desta solução. Há um mapeamento do tipo um para um entre os volumes de armazenamento, extents e dispositivos em cada local. Todos os dispositivos do cluster-1 são espelhados remotamente no cluster-2, em uma configuração distribuída de RAID 1, para criar dispositivos distribuídos. Esses dispositivos distribuídos são encapsulados por volumes virtuais, que são apresentados aos hosts por meio de exibições de armazenamento. 28

29 Figura 18. Estruturas de armazenamento físico e lógico do VPLEX para a solução Grupos de consistência Os grupos de consistência são particularmente importantes para bancos de dados e seus aplicativos. Por exemplo: Fidelidade da ordem de gravação: Para manter a integridade dos dados, todas as LUNs de banco de dados Oracle (por exemplo, dados, controle e arquivos de registro) devem ser reunidas em um único grupo de consistência. Dependência transacional: Com frequência, vários bancos de dados têm dependências de transação, por exemplo, quando um aplicativo emite transações para vários bancos de dados e espera que os bancos de dados sejam consistentes entre si. Todas as LUNs que exigem a preservação da dependência de I/O devem residir em um único grupo de consistência. Dependência de aplicativo: O Oracle RAC mantém o OCR (Oracle Cluster Registry) e os arquivos do Voting em um conjunto de discos que devem estar acessíveis para manter a disponibilidade do banco de dados. O banco de dados e os discos de OCR devem residir em um único grupo de consistência. Para a solução, um único grupo de consistência síncrona Extended_Oracle_ RAC_CG contém todos os volumes virtuais que armazenam os binários do banco de dados Oracle 11g, os grupos de discos Oracle ASM e os arquivos de OCR e do Voting. A regra de desanexação do grupo de consistência tem cluster-1 como o cluster preferencial. 29

30 Processo de configuração Para a solução, as estruturas de armazenamento lógico VPLEX Metro são configuradas da seguinte maneira (as Figura 19 a Figura 23 mostram extrações dos assistentes de configuração fornecidos pelo VPLEX Management Console): Volume de armazenamento: Um volume de armazenamento é uma LUN exportada de um array e encapsulada pelo VPLEX. Figura 19 mostra vários volumes de armazenamento criados no Local A, conforme exibido no VPLEX Management Console. Figura 19. Volumes de armazenamento EMC VPLEX (Local A) Extent: Na solução, há um mapeamento "um para um" entre extents e volumes de armazenamento, conforme mostrado na Figura 19 e na Figura 20. Figura 20. Assistente de criação de Extent do EMC VPLEX Dispositivo: Na solução, há um mapeamento um para um entre dispositivos e extents. Figura 21 mostra a opção usada para configurar esse mapeamento um para um. Figura 21. Assistente de criação de Dispositivo do EMC VPLEX Dispositivo distribuído: Na solução, os dispositivos distribuídos foram criados pelo espelhamento de um dispositivo remotamente em uma configuração distribuída de RAID 1, conforme mostrado na Figura

31 Figura 22. Assistente de criação de Dispositivo do EMC VPLEX Volume virtual: Na solução, todos os dispositivos de nível superior são dispositivos distribuídos. Esses dispositivos são encapsulados por volumes virtuais, que o VPLEX apresenta aos hosts por meio de exibições de armazenamento. As exibições de armazenamento definem quais hosts acessam quais volumes virtuais em quais portas do VPLEX. Grupo de consistência: Figura 23 mostra o grupo de consistência criado para esta solução Extended_Oracle_RAC_CG. Figura 23. Assistente para Criar grupo de consistência do EMC VPLEX Configuração do VPLEX A solução usa o VPLEX Witness para monitorar a conectividade entre os dois clusters VPLEX e assegurar a disponibilidade contínua no caso de uma falha de partição de rede entre clusters ou uma falha de cluster. Considerada uma configuração de alta disponibilidade do VPLEX Metro, pois a disponibilidade de armazenamento é assegurada no local sobrevivente. O VPLEX Witness é implementado em um terceiro domínio de falha separado (Local C) e conectado aos clusters do VPLEX no Local A e no Local B. O Local C fica a uma distância de menos de 1 segundo de latência dos Locais A e B. Após a instalação e a configuração de um VPLEX Witness, o VPLEX Management Console exibe o status dos componentes de testemunha do cluster, conforme mostrado na Figura

32 Figura 24. Componentes e status do EMC VPLEX Witness Monitoramento de desempenho do VPLEX O VPLEX 5.1 oferece monitoramento de desempenho aprimorado por meio do painel de controle de monitoramento de desempenho. Esse painel de controle oferece uma exibição personalizável do desempenho do sistema VPLEX e permite visualizar e comparar aspectos diferentes do desempeno do sistema, no nível do director. Atualmente, há muitas métricas diferentes, como: Gráfico de Latência de front-end Gráfico de Largura de banda de front-end Gráfico de Throughput de front-end Gráfico de Utilização da CPU Gráfico de Status de reconstrução Gráfico de Desempenho de link de WAN Gráfico de Latência de back-end Figura 25 mostra o front-end e o desempenho da CPU no cluster-1 (o Local A VPLEX) após a coleta das estatísticas Oracle no banco de dados SAP VSE. Figura 25. Painel de controle de monitoramento de desempenho do VPLEX 32

33 Infraestrutura virtual do VMware Introdução Visão geral Para a solução, os servidores de aplicativo SAP foram totalmente virtualizados com o VMware vsphere 5. Esta seção descreve a infraestrutura de virtualização, que usa estes componentes e opções: VMware vsphere atualização 1 VMware vcenter TM Server VMware vsphere vmotion VMware vsphere High Availability (HA) VMware vsphere Distributed Resource Scheduler TM (DRS) EMC PowerPath /VE for VMware vsphere versão 5.7 EMC Virtual Storage Integrator for VMware vsphere versão 5.1 VMware vsphere 5 O VMware vsphere 5 é a plataforma de virtualização mais completa, dimensionável e poderosa do setor, com serviços de infraestrutura que transformam o hardware de TI em uma plataforma de computação compartilhada de alto desempenho e serviços de aplicativo que ajudam as organizações de TI a oferecerem os níveis mais altos de disponibilidade, segurança e dimensionamento. VMware vcenter Server O VMware vcenter é a plataforma de gerenciamento centralizado para ambientes vsphere, proporcionando controle e visibilidade em todos os níveis da infraestrutura virtual. VMware vsphere vmotion O VMware vsphere vmotion é a tecnologia VMware que dá suporte à migração em tempo real de máquinas virtuais em servidores sem interrupção para os usuários ou perda do serviço. O Storage vmotion é a tecnologia VMware que permite a migração em tempo real do armazenamento de uma máquina virtual sem nenhuma interrupção na disponibilidade da máquina virtual. Isso permite a realocação de máquinas virtuais em tempo real para novos datastores. VMware vsphere High Availability O VMware vsphere High Availability (HA) é um componente do vsphere que oferece alta disponibilidade para qualquer aplicativo em execução em uma máquina virtual, independentemente de seu sistema operacional ou configuração de hardware subjacente. VMware vsphere Distributed Resource Scheduler O VMware vsphere Distributed Resource Scheduler (DRS) balanceia de modo dinâmico e automático a distribuição de carga e o posicionamento de máquina virtual em vários servidores ESXi. 33

34 EMC PowerPath/VE O EMC PowerPath/VE for VMware vsphere oferece os recursos de múltiplos caminhos do PowerPath para otimizar ambientes virtuais do VMware vsphere. O PowerPath/VE é instalado como um módulo de kernel no host ESXi e funciona como um MPP (Multipathing Plug-in, plug-in de múltiplos caminhos) que fornece recursos aprimorados de gerenciamento de caminho para hosts ESXi. EMC Virtual Storage Integrator for VMware vsphere O EMC VSI (Virtual Storage Integrator) for VMware vsphere é um plug-in para o VMware vsphere que fornece uma interface única de gerenciamento que é usada para gerenciar o armazenamento do EMC no ambiente vsphere. O VSI oferece uma experiência de usuário flexível e unificada, permitindo que cada um dos recursos seja atualizado de forma independente e que novos recursos sejam introduzidos rapidamente em resposta aos requisitos dinâmicos do cliente. Quando o PowerPath/VE é instalado em um host ESXi, o VSI apresenta detalhes importantes de múltiplos caminhos para dispositivos, como a política de balanceamento de carga, o número de caminhos ativos e o número de caminhos inativos. Implementações do VMware no VPLEX Metro O EMC VPLEX Metro oferece acesso simultâneo ao mesmo conjunto de dispositivos em dois locais fisicamente separados e, portanto, fornece a infraestrutura do tipo ativo-ativo que permite clusters ampliados geograficamente com base no VMware vsphere. O uso da tecnologia Brocade vlag (Virtual Link Aggregation Group) permite a extensão de VLANs e, portanto, sub-redes, em datacenters físicos diferentes. Com a implementação dos recursos e componentes do VMware vsphere junto com o VPLEX Metro, as seguintes funções podem ser obtidas: vmotion: A capacidade de migrar em tempo real as máquinas virtuais entre sites com antecedência de eventos planejados, como manutenção de hardware. Storage vmotion: A capacidade de migrar um armazenamento de máquina virtual sem nenhuma interrupção na disponibilidade da máquina virtual. Isso permite a realocação de máquinas virtuais em tempo real para novos datastores. VMware DRS: Distribuição automática de carga e posicionamento de máquina virtual em locais com o uso de grupos DRS e regras de afinidade. VMware HA: Um ambiente VPLEX Metro configurado com VPLEX Witness é considerado uma configuração do VPLEX Metro HA, pois isso assegura a disponibilidade de armazenamento no local sobrevivente no caso de uma falha de nível de sistema. A combinação do VPLEX Metro HA com uma tecnologia de cluster de failover de host, como VMware HA, fornece reinicialização automática de aplicativo para desastres em qualquer nível. Figura 26 ilustra essa arquitetura de alta disponibilidade. 34

35 Figura 26. VMware HA com VPLEX Witness exibição lógica Interconexão de clusters VPLEX Metro HA: É possível aumentar ainda mais a proteção do cluster VMware HA com a adição de uma interconexão de clusters entre os servidores VMware ESXi locais e o cluster VPLEX no local remoto. Eventos de indisponibilidade de dados locais, não reconhecidos pelo VMware vsphere 5.0, podem ocorrer mesmo que não haja uma falta de energia completa. A interconexão de ambientes vsphere com clusters VPLEX protege contra isso e assegura que as máquinas virtuais com falha sejam movidas automaticamente para o local sobrevivente. A Interconexão de clusters VPLEX está disponível por até 1 ms da latência induzida à distância. Esta solução usa o VPLEX Metro HA com interconexão de clusters para maximizar a disponibilidade de máquinas virtuais do VMware, conforme mostrado na Figura Para obter informações detalhadas, consulte o TechBook da EMC: EMC VPLEX Metro Witness Technology and High Availability. 35

36 Figura 27. VMware HA com VPLEX Witness e interconexão de clusters exibição lógica Configuração estendida de cluster VMware O VMware e a EMC dão suporte a uma configuração estendida de cluster que inclui hosts ESXi de vários locais 2. Para a solução, um único cluster do vsphere é estendido entre os Locais A e B usando um volume virtual VPLEX distribuído com VMware HA e VMware DRS. Há quatro hosts no cluster, dois em cada local. A Interconexão de clusters VPLEX Metro HA fornece maior flexibilidade à configuração. No vcenter, é fácil exibir a configuração desse cluster SiteAandSiteB e os recursos ativados para ele, conforme mostrado na Figura 28. Essa exibição também mostra a memória, a CPU e os recursos de armazenamento disponíveis para o cluster. Figura 28. Cluster vsphere com HA e DRS ativados 2 Para obter requisitos e cenários detalhados, consulte o artigo da base de dados de conhecimento do VMware: Usando o VPLEX Metro com o VMware HA 36

37 Cada servidor ESXi é configurado com dois adaptadores físicos de 10 GbE para fornecer failover de rede e alto desempenho. Um dvswitch (switch distribuído do vsphere) 3 oferece um único switch comum entre todos os hosts. Os adaptadores físicos de 10 GbE (também conhecidos como adaptadores de uplink) são atribuídos ao dvswitch. Dois grupos de portas distribuídos são atribuídos ao dvswitch: dvportgroupsiteab: Para o tráfego de rede de máquina virtual Rede de gerenciamento: Para tráfego do VMkernel e, em particular, tráfego do vmotion Figura 29 mostra a configuração do dvswitch. Como os switches distribuídos vsphere 5.0 e os switches Brocade VCS dão suporte ao LLDP (Link Layer Discovery Protocol), as propriedades dos switches físicos associados também podem ser facilmente identificadas do vcenter. Figura 29. Configuração do dvswitch e detalhes do LLDP O datastore EXT_SAP_VPLEX_DS01 foi criado em um volume distribuído de VPLEX de 1 TB e apresentado aos hosts ESXi no cluster estendido. Todas as máquinas virtuais foram migradas para esse datastore, usando o Storage vmotion, pois precisam compartilhar discos virtuais ou executar vmotion entre os locais. Figura 30 mostra os detalhes de configuração do datastore. 3 Um dvswitch fornece uma configuração de rede que abrange todos os hosts membros e permite que as máquinas virtuais mantenham uma configuração de rede consistente quando migrarem entre os hosts. Para obter mais informações, consulte o documento VMware vsphere Networking ESXi

38 Figura 30. Datastore EXT_SAP_VPLEX_DS01 e hosts e máquinas virtuais associados Configuração do VMware vsphere HA Ativação do VMware vsphere HA e do VMware vsphere DRS O vsphere HA aproveita vários hosts ESXi, configurados como um cluster, para permitir recuperação rápida de paralisações e alta disponibilidade econômica para aplicativos em execução nas máquinas virtuais. 4 O vsphere HA protege a disponibilidade de aplicativo das seguintes maneiras: Ele protege contra uma falha de servidor reiniciando as máquinas virtuais em outros servidores ESXi no cluster. Ele protege contra a falha de aplicativo com o monitoramento contínuo de uma máquina virtual e sua redefinição no caso de uma falha do sistema operacional guest. Para a solução, o vsphere HA e DRS foram ativados, conforme mostrado na Figura 31. Figura 31. Assistente do vsphere HA 4 Para obter mais informações sobre o vsphere HA, consulte o documentovmware vsphere Availability ESXi

39 Monitoramento da máquina virtual O monitoramento de máquina virtual foi configurado para reiniciar máquinas virtuais separadas se o heartbeat delas não for recebido em 60 segundos. Opções de reinicialização de máquina virtual A opção Prioridade de reinicialização de máquina virtual das quatro máquinas virtuais do SAP foi definida como Alta. Isso assegura que essas máquinas virtuais sejam ligadas primeiro no caso de uma falta de energia. Figura 32 mostra essa configuração e a configuração de Resposta de isolamento de host (padrão). Figura 32. Configurações de Prioridade de reinicialização de máquina virtual e Resposta de isolamento de host Heartbeat do datastore Quando você cria um cluster vsphere, um único host é selecionado automaticamente como o host master. O host master monitora o estado de todas as máquinas virtuais protegidas e dos hosts escravos. Quando o host master não consegue se comunicar com um host escravo, ele usa o heartbeat de datastore para determinar se o host escravo falhou, está em uma partição de rede ou está isolado da rede. Para cumprir os requisitos de vsphere HA para heartbeat de datastore, um segundo datastore EXT_SAP_VPLEX_HA_HB foi criado em um volume distribuído do VPLEX de 20 GB e apresentado a todos os hosts ESXi, conforme mostrado na Figura 33. Em um ambiente de produção, o vcenter seleciona automaticamente dois ou mais datastores para essa finalidade, com base na visibilidade do host. Figura 33. Status do cluster vsphere HA datastores de heartbeat 39

40 Configuração do VMware vsphere DRS Grupos de hosts e grupos de máquinas virtuais do VMware DRS Os grupos de hosts e os grupos de máquinas virtuais do DRS simplificam o gerenciamento de recursos de host ESXi. Esses recursos não eram necessários para essa solução. Regras de afinidade do VMware DRS O DRS usa as regras de afinidade para controlar o posicionamento de máquinas virtuais nos hosts em um cluster. O DRS fornece dois tipos de regra de afinidade: Uma regra de afinidade de VM-Host especifica uma relação de afinidade entre um grupo de máquinas virtuais e um grupo de hosts. Uma regra de afinidade de VM-VM especifica se determinadas máquinas virtuais devem ser executadas no mesmo host ou se devem ser mantidas em hosts separados. Tabela 8 e Figura 34 mostram a regra de afinidade de VM-VM usada pela solução. Tabela 8. Regra de afinidade do VMware DRS Regra de afinidade de VM-VM SAPASCS Separado Mantenha as máquinas virtuais SAPASCS2e SAPASCS3 em hosts separados. Figura 34. Regra de afinidade de DRS VM-VM para o cluster vplex_esxi_metro_ha EMC Virtual Storage Integrator e VPLEX O EMC VSI (Virtual Storage Integrator) oferece melhor visibilidade para o VPLEX diretamente da GUI do vcenter. Os recursos Storage Viewer e Gerenciamento de caminhos podem ser acessados por meio da guia EMC VSI, conforme mostrado na Figura 35. Na solução, os volumes distribuídos do VPLEX hospedam o datastore VMFS (Virtual Machine File System) EXT_SAP_VPLEX_DS01, e o Storage Viewer fornece detalhes sobre os volumes virtuais, os volumes de armazenamento e os caminhos do datastore. Conforme mostrado na Figura 35, as LUNS que constituem o datastore são quatro volumes distribuídos do VPLEX Metro RAID 1 de 256 GB que podem ser acessados via PowerPath. 40

41 Figura 35. VSI Storage Viewer datastores 41

42 Arquitetura do sistema SAP Introdução Visão geral Esta seção descreve a arquitetura do sistema SAP implementada para a solução nos dois datacenters. A camada de aplicativo SAP usa estes componentes SAP e SUSE: Aplicativo SAP SAP Enhancement Package 4 para SAP ERP 6.0 IDES Servidor de aplicativos SAP NetWeaver para ABAP 7.01 SAP Enqueue Replication Server Sistema operacional SUSE Linux Enterprise Server para aplicativos SAP 11 SP1 SUSE Linux Enterprise High Availability Extension O sistema SAP é executado em um ambiente híbrido, com serviços SAP nas máquinas virtuais e o banco de dados nos servidores físicos. Todas as instâncias do SAP são instaladas nas máquinas virtuais VMware vsphere com SUSE Linux Enterprise Server para aplicativos SAP como o sistema operacional. O banco de dados subjacente é um banco de dados Oracle RAC físico no ASM. Os ambientes VMware e Oracle são descritos em seções diferentes do white paper (consulte Infraestrutura virtual do VMware e Arquitetura de banco de dados ). SAP ERP 6.0 O SAP ERP 6.0, desenvolvido com a plataforma de tecnologia SAP NetWeaver, é um aplicativo ERP (Enterprise Resource Planning) totalmente integrado que atende às necessidades de negócios principais de empresas de médio porte e grandes empresas em todos os setores e mercados. O SAP ERP 6.0 fornece um conjunto abrangente de processos de negócios interfuncionais integrados e pode atuar como uma plataforma sólida de processo de negócios que oferece suporte ao crescimento contínuo, à inovação e à excelência operacional. O SAP IDES (Internet Demonstration and Evaluation System) dá suporte a demonstrações, testes e avaliação funcional com base em dados e clients préconfigurados. O IDES contém dados de aplicativo de vários cenários de negócios, com processos de negócios projetados para refletir os requisitos de negócios reais e que têm acesso a muitas características realistas. Essa solução usa o IDES para representar uma empresa modelo para fins de teste. SUSE Linux Enterprise Server para aplicativos SAP O SUSE Linux Enterprise Server é um sistema operacional de servidor altamente confiável, dimensionável e seguro criado para aplicativos físicos, virtuais e de nuvem. É uma plataforma Linux preferencial para SAP. O SUSE Linux Enterprise Server para aplicativos SAP, com base na tecnologia SUSE Linux Enterprise Server mais nova, é otimizado para todas as soluções e dispositivos de software SAP NetWeaver essenciais. A SAP e a SUSE validam e certificam o SUSE Linux Enterprise Server para aplicativos SAP em conjunto para eliminar possíveis incompatibilidades de software. Essa parceria integra totalmente a carga de trabalho do aplicativo ao sistema operacional e elimina a possibilidade de incompatibilidades durante a aplicação de patches aos aplicativos ou ao sistema operacional. 42

43 SUSE Linux Enterprise High Availability Extension O SUSE Linux Enterprise Server para aplicativos SAP inclui o SUSE Linux Enterprise High Availability Extension, que oferece serviço de alta disponibilidade e cluster de aplicativos, file systems e file systems em cluster, NAS (Network Attached Storage), file systems de rede, gerenciadores de volumes, SAN e drivers, além dos meios para gerenciar todos esses componentes operando em conjunto. O SUSE Linux Enterprise High Availability Extension fornece uma solução de cluster integrado para implementações Linux físicas e virtuais, o que permite a implementação de clusters Linux altamente disponíveis e elimina pontos únicos de falha. Configuração do sistema SAP Arquitetura do sistema SAP A solução implementa uma arquitetura de sistema SAP de alta disponibilidade, conforme mostrado na Figura 36. Figura 36. Arquitetura do sistema SAP 43

44 O servidor de enfileiramento e o servidor de mensagens são dissociados da Instância central e implementados como serviços na instância do ASCS 5. O SAP ERS é instalado como parte da arquitetura de alta disponibilidade para oferecer zero perda de bloqueio de aplicativo e mais proteção ao servidor de enfileiramento 6. Duas instâncias de diálogo são instaladas para fornecer processos de trabalho redundantes, como dialog (DIA), background (BGD), update (UPD), spool (SPO) e gateway. Considerações de projeto principais O sistema SAP implementado para a solução implementa estes recursos de projeto principais: A instância do ASCS é instalada com um nome de host virtual (SAPVIPE), para dissociá-la do nome de host da máquina virtual. A instância do ERS é instalada com um número de instância diferente (01), para evitar confusão no futuro quando o ASCS e o ERS estiverem sob o controle do cluster. Os patches do SAP, os parâmetros, as configurações básicas e as configurações de balanceamento de carga são instalados e configurados de acordo com o guia de instalação do SAP e as Notas do SAP listadas na página 72. As práticas recomendadas do VMware para SAP são adotadas nesta solução 7. Os processos de atualização do SAP (UPD/UP2) são configurados nas instâncias adicionais de servidor de aplicativos. O perfil de instância do SAP ASCS, a instância do ERS e os perfis iniciais e os perfis de instância de diálogo são atualizados com as configurações do ERS. Consulte o Apêndice: Exemplos de configuração para obter amostras de configurações. Os file systems compartilhados SAP, como /sapmnt/<sid> (disponível para todas as instâncias do SAP) e /usr/sap/<sid>/ascs00 (disponível para nós de cluster do SAP, a instância do ASCS e a instância do ERS), são armazenados no ACFS (Oracle ASM Cluster File System) e montados como compartilhamentos de NFS (Network File System) nas máquinas virtuais do SAP. Esses file systems compartilhados são apresentados como um recurso NFS altamente disponível gerenciado pelo Oracle Clusterware. 5 O servidor de enfileiramento gerencia bloqueios lógicos, com o objetivo de minimizar a duração de um bloqueio de banco de dados. Diferentemente dos bloqueios de banco de dados, um bloqueio SAP pode existir em várias LUWs de banco de dados. O servidor de mensagens informa a todos os servidores (instâncias) em um sistema SAP sobre a existência dos outros servidores. Outros clients (por exemplo, SAPlogon e RFC com balanceamento de carga) também poderão contatá-lo para obter informações sobre o balanceamento de carga. 6 O SAP ERS fornece um mecanismo de replicação para o servidor de enfileiramento mantendo uma cópia da tabela de bloqueio em seu segmento de memória compartilhado. A instalação do ERS para Linux não faz parte do processo SAPInst padrão. Para obter instruções de instalação, consulte o portal de ajuda do SAP Enqueue Replication Server em help.sap.com. 7 Para obter detalhes, consulte: SAP Solutions on VMware: Guia de práticas recomendadas. 44

45 Algumas funções do IDES, por exemplo, sincronização com o sistema GTS externo, são desativadas para eliminar interfaces externas desnecessárias que estejam fora do escopo da solução. O armazenamento para todo o ambiente SAP é encapsulado e virtualizado para essa solução. O armazenamento é distribuído nos dois locais e disponibilizado para os servidores SAP com o VPLEX Metro. Configuração do SUSE Linux Enterprise High Availability Extension Arquitetura de máquina virtual do SAP com SUSE Linux Enterprise High Availability Extension A solução usa o SUSE Linux Enterprise High Availability Extension para proteger os serviços centrais (servidor de mensagens e servidor de enfileiramento) nos dois nós de cluster embutidos nas máquinas virtuais do VMware. O VMware High Availability (VMware HA) protege todas as máquinas virtuais do SAP, incluindo ASCS e o servidor de aplicativos adicional (AAS). Figura 37 mostra essa arquitetura. Figura 37. Arquitetura do cluster SAP ASCS com SUSE Linux Enterprise HAE Estes são alguns dos componentes principais do SUSE Linux Enterprise High Availability Extension implementados nesta solução: OpenAIS 8 /Corosync 9, um gerenciador de cluster de alta disponibilidade que dá suporte a failover de vários nós Agentes de recurso (endereço IP virtual, master/escravo e SAPInstance) para monitorar e controlar a disponibilidade de recursos GUI de alta disponibilidade e várias ferramentas de linha de comando 8 O OpenAIS é uma implementação aberta da AIS (Application Interface Specification, especificação de interface de aplicativo) fornecida pelo Service Availability Forum (SA Forum). 9 O Corosync Cluster Engine é um sistema de comunicação de grupo com recursos adicionais para a implementação de alta disponibilidade em aplicativos. 45

46 Tabela 9 mostra a configuração de máquinas virtuais SAP. Tabela 9. Máquinas virtuais SAP Função de VM Quantid ade vcpus Memória (GB) Bootdisk de sistema operacional (GB) Nome de VM SAP ASCS SAPASCS2 SAP ERS SAPASCS3 SAP AAS SAPDI SAPDI2 Processo de instalação e configuração O white paper SUSE Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack descreve como instalar e configurar o software SUSE e o SAP NetWeaver. Apêndice: Exemplos de configuração fornece uma amostra de arquivo de configuração que dá suporte aos recursos e à funcionalidade validada por esta solução. Você deve considerar os valores de tempo (timeout, intervalos etc.) aqui como valores iniciais a serem ajustados e otimizados para o seu ambiente em particular. Para a solução, o SUSE Linux Enterprise High Availability Extension foi instalado e configurado com o YaST e o Pacemaker GUI. Aqui está um resumo do processo de instalação e configuração: 1. Configure um SMT Server (para fins de segurança) para atualizar todos os pacotes de software para as versões mais recentes. 2. No módulo Gerenciamento de software YaST, selecione Patterns > High Availability para instalar a High Availability Extension, conforme mostrado na Figura

47 Figura 38. Instalação do SUSE Linux Enterprise High Availability Extension 3. No módulo Cluster YaST, defina as configurações básicas de cluster, conforme mostrado na Figura 39. Figura 39. Definição de configurações básicas de cluster 47

48 4. Na GUI do Pacemaker, defina as configurações globais de cluster, conforme mostrado na Figura 40. Figura 40. Definindo configurações globais de cluster 5. Na GUI do Pacemaker, abra a categoria Resources e configure os recursos IPaddr2, master/escravo e SAPInstance, conforme mostrado na Figura 41. Figura 41. Configuração de recursos 48

49 6. Na GUI do Pacemaker, defina as dependências dos recursos, conforme mostrado na Figura 42. Figura 42. Configuração de dependências de recursos 7. Na GUI do Pacemaker, inicie o cluster e verifique se o cluster e todos os agentes de recursos são abertos normalmente, conforme mostrado na Figura 43. Figura 43. Verificação do status do cluster 49

50 Considerações de projeto principais Configuração de dispositivo STONITH O SBD (STONITH Block Device) e o STONITH (Shoot The Other Node In The Head) permitem o isolamento de nós em um cluster por meio do armazenamento compartilhado. Esta solução usa uma partição de um disco virtual (VMDK) como um dispositivo SBD STONITH. 10 Portanto, ambos os nós de cluster precisam de acesso simultâneo a esse disco virtual. O disco virtual é armazenado no mesmo datastore das máquinas virtuais SAP. Ele é provisionado e protegido pelo VPLEX e está disponível em ambos os locais. Por padrão, o VMFS impede que várias máquinas virtuais acessem e gravem no mesmo VMDK. No entanto, você pode permitir o compartilhamento configurando a opção multi-writer 11, conforme mostrado na Figura 44. Figura 44. Opção Multi-writer O dispositivo SBD é protegido pelo VPLEX e acessado por meio do software de múltiplos caminhos EMC PowerPath/VE. Os parâmetros de timeout do dispositivo SBD devem ser configurados de modo apropriado para considerar o timeout de cluster Oracle RAC subjacente, bem como com o processo de isolamento do VLEX. Figura 45 mostra a configuração usada para esta solução. Figura 45. Configuração de dispositivo SBD 10 O SBD é essencial para manuseio de cenários de desconexão do cluster. Um único dispositivo SBD é configurado para esta solução. Essa configuração de dispositivo SBD único destina-se a fins de teste apenas; para configuração de produção, consulte Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack. 11 Para obter informações detalhadas, consulte o artigo da Base de conhecimentos : Disabling simultaneous write protection provided by VMFS using the multi-writer flag. 50

51 Configuração de master/escravo O agente de recurso SAPInstance controla a instância do ASCS, bem como a instância apropriada do ERS. Ele é configurado como um recurso de master/escravo que estende as funções do recurso de started e stopped para master e slave. Uma instância master inicia a instância do SAP ASCS. A instância escrava inicia a instância do ERS. O modo master/escravo assegura que uma instância do ASCS nunca seja iniciada no mesmo nó do ERS. Figura 46 mostra a configuração do agente de recurso SAPInstance. Figura 46. Configuração do agente de recurso SAPInstance Figura 47 mostra a configuração do agente de recurso master/escravo. Figura 47. Configuração do agente de recurso master/escravo 51

52 Restrições de recursos A instância do ASCS e seu IP virtual são vinculados na ordem apropriada e com restrições de colocação. Figura 48 mostra a configuração das restrições de Colocação de recurso e Ordem de recursos. Figura 48. Configuração das restrições de Colocação de recurso e Ordem de recursos Conceito de pesquisa O SUSE Linux Enterprise High Availability Extension pode monitorar continuamente o status de processos SAP em cada nó de cluster e tomar as decisões corretas para promover/rebaixar as instâncias do ASCS e do ERS respectivamente. Não é necessário implementar o conceito de pesquisa SAP. Verifique se esse recurso NÃO está ativado no perfil de instância do ERS. Para obter uma amostra de perfil de instância do ERS, consulte Perfil de instância de amostra do ERS na página

53 Arquitetura de banco de dados Oracle Introdução Visão geral Esta seção descreve a grade e o banco de dados por trás dos aplicativos SAP na solução. O banco de dados originado como uma instância única do Oracle Database 11g físico. Para eliminar o servidor de banco de dados como um ponto único de falha, o banco de dados de instância única foi migrado para um cluster Oracle RAC 11g físico de quatro nós com o banco de dados Oracle residindo no ASM. A solução usa estes componentes e opções Oracle: Oracle Database 11g Release 2 Enterprise Edition Oracle ASM (Automatic Storage Management) e Oracle ACFS (ASM Cluster File System) Oracle Clusterware Oracle RAC (Real Applications Clusters) 11g em clusters de longa distância Oracle Database 11g R2 O Oracle Database 11g Release 2 Enterprise Edition oferece desempenho líder do setor, dimensionamento, segurança e confiabilidade em uma opção de servidores em cluster ou únicos executando o Windows, o Linux ou o UNIX. Isso oferece recursos abrangentes para o processamento da transação, business intelligence e aplicativos de gerenciamento de conteúdo. Oracle ASM e Oracle ACFS O Oracle ASM é um file system integrado de banco de dados com reconhecimento de cluster e gerenciador de discos. O file system ASM e os recursos de gerenciamento de volume são integrados com o kernel de banco de dados Oracle. No Oracle Database 11g R2, o Oracle ASM também foi estendido para incluir o suporte para OCR e os arquivos do Voting a serem colocados nos grupos de discos do ASM. O Oracle ACFS, um recurso no ASM no Oracle Database 11g, estende a funcionalidade do ASM para atuar como um file system de cluster de uso geral. Os binários de banco de dados Oracle podem residir no ACFS, assim como os arquivos de suporte, como registros de rastreamento e alerta, e os arquivos de aplicativos não desenvolvidos pela Oracle, como o SAP ERP. Os servidores não desenvolvidos pela Oracle podem acessar volumes ACFS usando protocolos NAS padrão do setor, como NFS e CIFS (Common Internet File System, sistema comum de arquivos da internet). Oracle Clusterware O Oracle Clusterware é uma solução portátil de gerenciamento de cluster integrada ao banco de dados Oracle. Ela fornece a infraestrutura necessária para execução do Oracle RAC, incluindo Serviços de gerenciamento de cluster e Serviços de alta disponibilidade. Um aplicativo não desenvolvido pela Oracle também pode ser altamente disponibilizado no cluster com o uso do Oracle Clusterware. Oracle GRID Infrastructure No Oracle Database 11g R2, o Oracle Grid Infrastructure combina o Oracle ASM e o Oracle Clusterware em um único conjunto de binários, separado do software de banco de dados. Agora, essa infraestrutura fornece todo o cluster e serviços de armazenamento necessários para execução de um banco de dados Oracle RAC. 53

54 Oracle Real Application Clusters 11g O Oracle RAC é, basicamente, uma solução de alta disponibilidade para aplicativos de banco de dados Oracle no datacenter. Ele permite que várias instâncias Oracle acessem um único banco de dados. O cluster consiste em um grupo de servidores independentes que cooperam como um sistema único e compartilham o mesmo conjunto de discos de armazenamento. Cada instância é executada em um servidor separado no cluster. O RAC pode fornecer alta disponibilidade, dimensionamento, tolerância a falhas, balanceamento de carga e benefícios de desempenho, além de remover qualquer ponto único de falha da solução de banco de dados. Oracle RAC em clusters de longa distância O Oracle RAC em clusters de longa distância (Oracle Extended RAC) é uma arquitetura que permite que os servidores no cluster residam em locais fisicamente separados. Isso elimina o datacenter como ponto único de falha. O Oracle Extended RAC ativa todos os nós no cluster, independentemente de local. Ele fornece alta disponibilidade e continuidade de negócios durante uma falha de local ou de rede, da seguinte forma: O armazenamento e os dados permanecem disponíveis e ativos no local sobrevivente. Os Serviços Oracle executam o balanceamento de carga e o failover para os nós do Oracle RAC no local sobrevivente. O Oracle TAF (Transparent Application Failover, failover transparente de aplicativos) permite o failover automático das sessões para nós do Oracle RAC no local sobrevivente. Os aplicativos de terceiros colocados sob o controle do Oracle Clusterware podem executar o balanceamento de carga e o failover para os nós do Oracle RAC no local sobrevivente, por exemplo, NFS ou Apache httpd. Os nós do Oracle RAC no local sobrevivente continuam processando as transações. A Oracle afirma que a arquitetura do Oracle Extended RAC é mais adequada quando os dois datacenters estão relativamente próximos (a uma distância de até 100 km) 12. Oracle RAC e VPLEX Configuração do Oracle ACFS Normalmente, o Oracle RAC é executado em um datacenter local devido ao possível impacto da latência induzida pela distância e a complexidade relativa e a sobrecarga de estender o Oracle RAC nos datacenters com espelhamento baseado em host usando o Oracle ASM. No entanto, com o EMC VPLEX Metro, uma implementação do Oracle Extended RAC, da perspectiva do Oracle DBA, se torna uma instalação e configuração padrão do Oracle RAC 13. Esta solução usa quatro volumes do ACFS montados no cluster do Oracle RAC, conforme mostrado na Tabela 10. Três desses volumes, SAPMNT, USRSAPTRANS e ASCS00, foram exportados como compartilhamentos do NFS para os servidores SAP, usando um endereço IP virtual e um recurso do NFS altamente disponível sob o controle do Oracle Clusterware. 12 Consulte o white paper da Oracle: Oracle Real Application Clusters (RAC) on Extended Distance Clusters. 13 Consulte o white paper da EMC: Oracle Extended RAC with EMC VPLEX Metro Best Practices Planning. 54

55 Tabela 10. Volumes e pontos de montagem do Oracle ACFS Volume do ACFS Tamanho (GB) Ponto de montagem Descrição SAP_O_HOME 16 /oracle/vse/112 ORACLE_HOME para banco de dados VSE compartilhado em todos os nós do Oracle RAC SAPMNT 16 /sapmnt/vse Diretório SAP global, que armazena kernels e perfis, compartilhados em todas as máquinas virtuais SAP USRSAPTRANS 16 /usr/sap/trans Diretório de transporte SAP, que armazena os arquivos de transporte, compartilhados em todas as máquinas virtuais SAP Dialog Instance ASCS00 16 /usr/sap/vse/ascs00 Diretório de instância SAP ASCS, que armazena os arquivos relacionados à instância, compartilhados nos nós de cluster do SUSE Linux Enterprise High Availability Extension Oracle Extended RAC no VPLEX Metro Figura 49 fornece uma representação lógica da implementação do Oracle Extended RAC no VPLEX Metro para a solução. Figura 49. Oracle Extended RAC sobre EMC VPLEX Metro 55

56 Configuração do grupo de discos do Oracle ASM Tabela 11 mostra o layout e a configuração do grupo de discos do ASM. Tabela 11. Grupo de discos do ASM* Tamanho e configuração do grupo de discos do Oracle ASM Número de discos Tamanho do grupo de discos (GB): Redundância OCR 5 40 Normal EA_SAP_ACFS 4 64 Externo EA_SAP_DATA Externo EA_SAP_REDO 4 64 Externo EA_SAP_REDOM 4 64 Externo EA_SAP_FRA Externo * O prefixo EA_SAP_ é usado para identificar exclusivamente os grupos de discos do ASM relacionados ao aplicativo SAP no Extended Oracle RAC. Conexão com o Oracle RAC a partir do SAP Para permitir que o SAP se conecte ao banco de dados Oracle RAC, tnsnames.ora foi colocado em cada uma das máquinas virtuais SAP (SAPDI1 e SAPDI2), conforme mostrado na Figura 50. VSE.WORLD= (DESCRIPTION = (LOAD_BALANCE = OFF) (FAILOVER = ON) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = sse-ea-erac-scan-c01.sse.ea.emc.com) (PORT = 1521) ) ) (CONNECT_DATA = ) ) (SERVICE_NAME = VSE.sse.ea.emc.com) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC)) Figura 50. Entrada do arquivo de amostra tnsnames.ora para o banco de dados Oracle RAC O TAF (Transparent Application Failover, failover transparente de aplicativos) é um recurso do lado do client que permite que os clients se reconectem às instâncias sobreviventes no caso de falha de uma instância de banco de dados. O TAF pode ser configurado com o uso de uma string de conexão especificada do lado do client ou atributos de serviço do lado do servidor. Na solução, o serviço do banco de dados VSE.sse.ea.emc.com foi configurado para TAF no Oracle RAC. Também foi configurado no lado do client para permitir o uso do TAF pelo SAP. O TAF foi definido para estabelecer conexões no momento do failover e para permitir que os usuários com cursores abertos continue extraindo-os após a falha das operações selecionadas. 56

57 Infraestrutura de rede da Brocade Introdução Visão geral Esta seção descreve as redes IP e SAN implementadas para a solução nos dois datacenters e a extensão da Camada 2 entre os datacenters. A infraestrutura de rede foi criada com o uso destes componentes Brocade: Rede IP Switches de datacenter Brocade VDX 6720 Roteadores Brocade série MLX CNAs Brocade 1020 SAN Backbones Brocade DCX 8510 HBAs Brocade 825 Brocade VDX 6720 O Switch de datacenter Brocade VDX 6720 é um switch de porta fixa com velocidade de transmissão de dados de 10 GbE, latência ultrabaixa e alto desempenho. Foi projetado especificamente para melhorar a utilização de rede, maximizar a disponibilidade do aplicativo, aumentar o dimensionamento e simplificar radicalmente a arquitetura de rede nos datacenters virtualizados. Com um conjunto rico de recursos da Camada 2, o Brocade VDX 6720 é uma plataforma ideal para implementações de switch ToR (Top-of-Rack) tradicionais. Com o fornecimento da tecnologia de fabric Brocade VCS, o Brocade VDX 6720 permite que as organizações criem fabrics Ethernet de datacenter, revolucionando o design de redes da Camada 2 e fornecendo uma base inteligente para datacenters otimizados para a nuvem. Brocade série MLX Os roteadores Brocade série MLX foram projetados para permitir redes otimizadas para a nuvem fornecendo densidade de velocidade de transmissão de dados de 100 GbE, 10 GbE e 1 GbE líder do setor; IPv4, IPv6, MPLS (Multi-VRF, Multiprotocol Label Switching) e recursos Ethernet de operadora; além do switch da Camada 2. Com o aproveitamento do Brocade série MLX, os datacenters essenciais podem dar suporte a mais tráfego, obter maior virtualização e fornecer serviços baseados na nuvem de alto valor usando menos infraestrutura, simplificando as operações e reduzindo os custos. Além disso, o Brocade série MLX pode reduzir a complexidade em redes grandes de campus recolhendo camadas de núcleo e agregação, além de fornecer conectividade entre locais usando MPLS/VPLS. Todos os roteadores Brocade série MLX ajudam a reduzir os custos de energia e refrigeração com o mais baixo consumo de energia e dissipação de calor em sua classe. Projetado para sistemas de rede ininterruptos, o Brocade série MLX inclui MCT (Multi-Chassis Trunking), que fornece mais de 30 TB/s de largura de banda de chassis dual, links de roteamento ativo-ativo completos e fluxo de tráfego ininterrupto no caso de failover do nó. As organizações podem obter alta flexibilidade por meio de fabrics de switch totalmente redundantes, módulos de gerenciamento, fontes de alimentação e sistemas de refrigeração. Para assegurar ainda mais a disponibilidade de rede e aplicativo, o sistema operacional Brocade IronWare tem failover de gerenciamento hitless e upgrades de software. 57

58 Backbone Brocade DCX 8510 As redes precisam evoluir para dar suporte às demandas crescentes de ambientes altamente virtualizados e arquiteturas de nuvem privada. Atualmente, o FC (Fibre Channel) é o padrão de facto para sistemas de rede de armazenamento no datacenter. A introdução do Fibre Channel de 16 Gb/s estende o ciclo de vida dessa tecnologia robusta, confiável e de alto desempenho. Isso permite que as organizações continuem aproveitando seus investimentos existentes em TI, enquanto superam seus desafios de negócios mais difíceis. Os Backbones Brocade DCX 8510 são a infraestrutura de switch Fibre Channel de 16 Gb/s mais poderosa do setor e oferecem a base de alto desempenho mais confiável e dimensionável para armazenamento na nuvem privada e ambientes altamente virtualizados. Eles foram projetados para aumentar a agilidade dos negócios e, ao mesmo tempo, oferecer acesso ininterrupto às informações e reduzir a infraestrutura e os custos administrativos. O recurso FC de 16 Gb do Brocade DCX 8510 oferece benefícios significativos de datacenter para a conectividade SAN Metro com o datacenter: A opção de 16 Gb fornece o FC de throughput máximo e mais baixa latência para implementações que utilizam conexões Fibre entre datacenters. Velocidade opcional de linha de FC de 10 Gb para utilização ideal se uma rede DWDM for implementada entre os locais. Esse recurso requer uma licença. Entroncamento ISL (Inter Switch Link, link entre switches) de nível de quadro que permite a alta utilização, em comparação com o entroncamento DPS padrão. Esse recurso requer uma licença. Compactação opcional dos ISLs entre os datacenters. Isso oferece mais largura de banda para implementações em que o número de conexões de local para local é limitado. Dados opcionais na criptografia em trânsito para os ISLs entre os datacenters para implementações que exigem níveis muito altos de segurança de dados. Detecção e recuperação de perda de crédito do buffer. FEC (Forward Error Correction, correção antecipada de erros) automática, que corrige proativamente até 11 erros de bit por quadro FC de 2112 bits. O modo de diagnóstico das portas ISL entre os datacenters pode ser usado em qualquer porta ISL (off-line) e oferece os seguintes recursos: Testes de loopback elétrico e óptico Testes de saturação de link Precisão da medição da distância de link em 5 m quando usada com 8 Gb SFP+ e 50 m quando usada com 10 GbE SFP+ 58

59 Configuração de rede IP Para a solução, a rede IP em cada datacenter é criada com o uso de dois switches Brocade VDX 6720 em uma configuração VCS. Todos os servidores são conectados à rede por meio de conexões 10 GbE redundantes fornecidas por CNAs Brocade Os dois switches Brocade VDX em cada local são conectados a um roteador Brocade série MLX com um vlag (Virtual Link Aggregation Group, grupo de agregação de links virtual). Os roteadores Brocade série MLX estendem a rede da Camada 2 entre os dois datacenters. Observação Um vlag é um serviço de fabric que permite a um LAG (Link Aggregation Group, grupo de agregação de links) se originar de vários switches Brocade VDX. Do mesmo modo que um LAG padrão, um vlag usa o LACP (Link Aggregation Control Protocol, protocolo de controle de agregação de links) para controlar o acompanhamento de várias portas físicas em conjunto para formar um único canal lógico. O Oracle RAC depende de um IP virtual altamente disponível (interconexão HAIP ou RAC) para a comunicação de rede privada. Com HAIP, o balanceamento de carga do tráfego interconexão é realizado no conjunto de interfaces identificado como a rede privada. Para a solução, uma VLAN separada, a VLAN 10, é usada para interconexão. A VLAN 20 manipulou todo o tráfego público. Todo o tráfego entre os Locais A e B é roteado por meio dos roteadores Brocade MLX usando várias portas configuradas como um LAG. Figura 51 mostra a infraestrutura de rede IP. Figura 51. As redes IP da solução 59

60 Configuração de rede SAN A SAN em cada datacenter foi criada com Backbones Brocade DCX 8510, conforme mostrado na Figura 52. Todos os servidores são conectados à rede por meio de conexões 8 GbE redundantes fornecidas por HBAs Brocade 825. A conexão VPLEX a VPLEX entre os datacenters usa várias conexões FC entre os Backbones Brocade DCX Elas são usadas no modo ativo-ativo com failover. Figura 52. As redes SAN da solução 60

61 Alta disponibilidade e continuidade de negócios Teste e validação Introdução Falha do processo de serviço de enfileiramento do SAP Inicialmente, a equipe de validação da EMC instalou e validou o ambiente sem nenhum esquema de alta disponibilidade ou continuidade dos negócios. Em seguida, transformamos o ambiente na solução de continuidade de negócios essenciais descrita neste white paper. Realizamos os seguintes testes para validar a solução e demonstrar a eliminação de todos os pontos únicos de falha do ambiente: Falha do processo de serviço de enfileiramento do SAP Falha de máquina virtual da instância do SAP ASCS Falha de nó do Oracle RAC Falha do local Isolamento de cluster VPLEX Cenário do teste Este cenário de teste verifica se ocorre falha no serviço de processo de enfileiramento de serviço, o cluster SUSE Linux Enterprise High Availability Extension promove a instância do SAP ERS a uma instância do ASCS totalmente funcional e assume a tabela de bloqueio sem interrupção para o usuário final. Para testar esse cenário de falha, terminamos o processo de enfileiramento no nó ASCS ativo executando o comando kill: kill -9 <process id> Comportamento do sistema O sistema responde à falha do processo de serviço de enfileiramento da seguinte forma: 1. O agente de recursos SAPInstance detecta e relata a falha, conforme mostrado na Figura 53. Figura 53. O agente de recurso SAPInstance detecta e relata a falha 61

62 2. O agente de recurso master/escravo promove o nó escravo anterior (SAPASCS2) a nó master, que hospeda os serviços ASCS e inicia o ERS como um escravo no outro nó (SAPASCS3) quando reingressa no cluster (consulte a Figura 54). Figura 54. O agente de recurso master/escravo alterna os nós master e escravo 3. A tabela de bloqueio replicada é restaurada, conforme mostrado na Figura 55. Figura 55. Tabela de bloqueio replicada restaurada Resultado O usuário final não percebe a falha do processo de enfileiramento, a menos que uma operação de enfileiramento esteja em execução. Nesse caso, o usuário final observa um tempo de resposta de transição mais longo durante o switchover. Os novos usuários podem fazer log-in no sistema imediatamente após o switchover do servidor de mensagens. Nenhuma intervenção administrativa é necessária. 62

63 Falha de máquina virtual da instância do SAP ASCS Cenário do teste Este cenário de teste verifica se, no caso de uma falha inesperada de servidor ESXi (equivalente a uma falha de máquina virtual), o cluster de Extensão de alta disponibilidade promove a instância do SAP ERS para uma instância ASCS totalmente funcional e assume a tabela de bloqueio, sem interrupção do usuário final. Para testar esse cenário de falha, desligamos (por meio do console físico remoto) o servidor ESXi que hospeda a máquina virtual da instância do SAP ASCS. Em seguida, reiniciamos o servidor sem entrar no modo de manutenção. Comportamento do sistema O sistema responde à falha da máquina virtual da seguinte forma: 1. O SAPASCS2 fica indisponível do vsphere Client (consulte a Figura 56). Figura 56. Falha de máquina virtual 63

64 2. O agente de recursos SAPInstance detecta e relata a falha (consulte a Figura 57). Figura 57. O agente de recurso SAPInstance detecta e relata a falha 3. O VMware HA reinicia a máquina virtual que falhou SAPASCS2 no host ESXi sobrevivente, conforme mostrado na Figura 58. Figura 58. O VMware HA reinicia a máquina virtual que falhou 4. O agente de recurso master/escravo promove o nó escravo anterior (SAPASCS3) a nó master, que hospeda os serviços ASCS e inicia o ERS como um escravo no outro nó (SAPASCS2) quando reingressa no cluster (consulte a Figura 59). 64

65 Figura 59. O agente de recurso master/escravo alterna os nós master e escravo 5. A tabela de bloqueio replicada é restaurada (consulte a Figura 60). Figura 60. Tabela de bloqueio replicada restaurada Resultado O usuário final não percebe a falha do processo de enfileiramento, a menos que uma operação de enfileiramento esteja em execução. Nesse caso, o usuário final observa um tempo de resposta de transição mais longo durante o switchover. Os novos usuários podem fazer log-in no sistema imediatamente após o switchover do servidor de mensagens. Nenhuma intervenção administrativa é necessária. Falha de nó do Oracle RAC Cenário do teste Este cenário de teste verifica se, no caso de uma falha inesperada de nó RAC, as instâncias do SAP se conectam automaticamente a outros nós RAC. Os usuários finais podem continuar suas transações sem interrupção, a menos que as transações não confirmadas (no nível do banco de dados) estejam sendo executadas no nó RAC que falhou. Para testar esse cenário de falha, reiniciamos o servidor para causar uma falha de nó Oracle. 65

66 Comportamento do sistema O sistema responde à falha do nó RAC da seguinte forma: 1. O nó RAC fica off-line e a instância VSE003 fica indisponível, conforme mostrado na Figura 61. Figura 61. oracle@sse-ea-erac-n01:~> srvctl status database -d VSE A instância VSE001 está em execução no nó sse-ea-erac-n01 A instância VSE002 está em execução no nó sse-ea-erac-n02 A instância VSE004 está em execução no nó sse-ea-erac-n03 A instância VSE003 não está em execução no nó sse-ea-erac-n04 O nó RAC fica off-line 2. O processo de trabalho de instância SAP se conecta a outra instância RAC, conforme mostrado na Figura 62.. Figura 62. A instância SAP se conecta a outro nó RAC Resultado O usuário final observa um tempo de resposta de transação mais longo quando o processo de trabalho de instância de diálogo se reconecta a outro nó RAC. As transações não confirmadas são revertidas no nível do banco de dados para garantir a consistência dos dados. O usuário final recebe uma mensagem de erro do sistema (short dump) e precisa reiniciar a transação. Nenhuma intervenção administrativa é necessária. Falha do local Cenário do teste Esse cenário de teste verifica se, no caso de uma falha total de local, os nós RAC sobreviventes preservam as operações de banco de dados. Para testar esse cenário de falha, simulamos uma falha completa do Local A, incluindo cluster VPLEX, servidor ESXi, rede e componentes de nó Oracle RAC. O VPLEX Witness permaneceu disponível no Local C. No Local B, o cluster-2 VPLEX permaneceu em comunicação com o VPLEX Witness. 66