CONTINUIDADE DE NEGÓCIOS ESSENCIAIS DA EMC PARA … · Availability, Oracle RAC, sistema de rede Brocade e SUSE Linux Enterprise Server para aplicativos SAP. Novembro de 2012

White paper

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

CONTINUIDADE DE NEGÓ CIOS ESSENCIAIS DA EMC PARA SAP EMC VPLEX, EMC Symmetrix série VMAX 10K com Enginuity

Gerenciamento simplificado para alta disponibilidade e continuidade de negócios

Implementações do SAP essenciais e adaptáveis Datacenters ativo-ativo

Continuidade de negócios essenciais da EMC para SAP EMC VPLEX, EMC Symmetrix série VMAX 10K com Enginuity

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 http://brazil.emc.com.

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 H11069

3 Continuidade de negócios essenciais da EMC para SAP EMC VPLEX, EMC Symmetrix série VMAX 10K com Enginuity

Í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 ............................................................................................................... 10

Camadas de proteção ................................................................................................................ 14

Perfil do banco de dados e da carga de trabalho ........................................................................ 15

Recursos de hardware ................................................................................................................ 16

Recursos de software ................................................................................................................. 17

Infraestrutura de armazenamento da EMC ..................................................................................... 18

Introdução ................................................................................................................................. 18

EMC Symmetrix VMAX 10K ......................................................................................................... 18

Enginuity .................................................................................................................................... 19

EMC Symmetrix VMAX 20K ......................................................................................................... 19

EMC Unisphere for VMAX ........................................................................................................... 19

Configuração do VMAX ............................................................................................................... 20

Infraestrutura EMC VPLEX Metro ................................................................................................... 22

Introdução ................................................................................................................................. 22

Mobilidade de dados do VPLEX .................................................................................................. 25

Configuração da solução VPLEX Metro ....................................................................................... 28

Configuração do VPLEX .............................................................................................................. 31

Monitoramento de desempenho do VPLEX ................................................................................. 32

Infraestrutura virtual do VMware .................................................................................................. 33

Introdução ................................................................................................................................. 33

Implementações do VMware no VPLEX Metro ............................................................................. 34

Configuração estendida de cluster VMware ................................................................................ 36

Configuração do VMware vSphere HA ........................................................................................ 38

Configuração do VMware vSphere DRS ....................................................................................... 40

EMC Virtual Storage Integrator e VPLEX ...................................................................................... 40


4

Arquitetura do sistema SAP .......................................................................................................... 42

Introdução ................................................................................................................................. 42

Configuração do sistema SAP ..................................................................................................... 43

Configuração do SUSE Linux Enterprise High Availability Extension ............................................ 45

Arquitetura de banco de dados Oracle .......................................................................................... 53

Introdução ................................................................................................................................. 53

Oracle RAC e VPLEX .................................................................................................................... 54

Configuração do Oracle ACFS ..................................................................................................... 54

Oracle Extended RAC no VPLEX Metro ......................................................................................... 55

Configuração do grupo de discos do Oracle ASM ....................................................................... 56

Infraestrutura de rede da Brocade ................................................................................................. 57

Introdução ................................................................................................................................. 57

Configuração de rede IP ............................................................................................................. 59

Configuração de rede SAN .......................................................................................................... 60

Alta disponibilidade e continuidade de negócios Teste e validação ............................................... 61

Introdução ................................................................................................................................. 61

Falha do processo de serviço de enfileiramento do SAP ............................................................. 61

Falha de máquina virtual da instância do SAP ASCS ................................................................... 63

Falha de nó do Oracle RAC ......................................................................................................... 65

Falha do local............................................................................................................................. 66

Isolamento de cluster VPLEX ...................................................................................................... 68

Conclusão .................................................................................................................................... 70

Resumo ...................................................................................................................................... 70

Resultados ................................................................................................................................. 70

Referências .................................................................................................................................. 72

EMC ........................................................................................................................................... 72

Oracle ........................................................................................................................................ 72

VMware ...................................................................................................................................... 72

SUSE .......................................................................................................................................... 73

SAP ............................................................................................................................................ 73

Apêndice: Exemplos de configuração ............................................................................................ 74

Configuração de amostra de CRM ............................................................................................... 74

Perfil de instância de amostra do ASCS ...................................................................................... 74

Perfil de instância de amostra do ERS ........................................................................................ 75

Perfil START de amostra do ERS .................................................................................................. 75

DI sample instance profile .......................................................................................................... 76


Resumo executivo

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.

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, AccessAnywhereTM, 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.

Business case

Visão geral da solução


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 elimina-os 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.

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

Principais benefícios


Introdução

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.

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

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

Termo Descrição

AAS Servidor de aplicativos adicional do SAP

ABAP SAP Advanced Business Application Programming

ACFS Oracle ASM Cluster File System

ASCS Serviços centrais do ABAP SAP

ASM Gerenciamento de armazenamento automático Oracle

CIFS Common Internet File System (sistema comum de arquivos da Internet)

CNA Adaptador de rede convergente

CRM Gerenciador de recursos do cluster

DI Instância de diálogo

DPS Seleção de caminho dinâmico

DRS VMware vSphere Distributed Resource Scheduler

dvSwitch vSphere distributed switch

DWDM Dense wavelength division multiplexing (Multiplexação densa por divisão de comprimento de onda)

ERP Planejamento de recursos corporativos

ERS Enqueue Replication Server

FAST VP Fully Automated Storage Tiering for Virtual Pools (armazenamento com classificação totalmente automatizada por níveis para pools virtuais)

FCoE Fibre Channel over Ethernet (Fibre Channel sobre Ethernet)

Finalidade

Escopo

Público-alvo

Terminologia


8

Termo Descrição

FEC Forward Error Correction (Correção antecipada de erros)

FRA Flash Recovery Area (Área de recuperação flash)

HA Alta disponibilidade

HAIP Highly available virtual IP (IP virtual altamente disponível)

HBA Adaptadores de barramento do host

IDES SAP Internet Demonstration and Evaluation System

ISL Inter Switch Link (link entre switches)

LACP Link Aggregation Control Protocol

LAG Link Aggregation Group

LLDP Link Layer Discovery Protocol

LUW Logical Unit of Work

MCT Troncos Multi-Chassis

MPLS Rótulo de Multi-Protocol

MPP Multipathing plug-in

NAS Armazenamento conectado à rede

NFS Network file system

NL-SAS SAS near-line (Serial Attached SCSI)

OCR Oracle Cluster Registry

Oracle Extended RAC Oracle RAC em clusters de longa distância

RAC Real Application Clusters (clusters de aplicativos reais)

RFC Chamada de função remota

RPO Objetivo de ponto de recuperação

RTO Objetivo de tempo de recuperação

SAN SAN

SBD STONITH Block Device

SFP Small Form Factor Pluggable (conectável com fator de forma pequeno)

SLES SUSE Linux Enterprise Server

SLE HAE SUSE Linux Enterprise High Availability Extension

SMT Ferramenta de gerenciamento de assinatura

SPOF Ponto único de falha

STONITH Shoot The Other Node In The Head

TAF Transparent Application Failover

ToR Top-of-Rack

VCS Virtual Cluster Switch

vLAG Virtual Link Aggregation Group

vLAN LAN Virtual

VMDK Disco virtual

VMFS Virtual Machine File System

VMware HA Alta disponibilidade do VMware

VPLS Virtual Private LAN Service

VPN Virtual Private Network (Rede virtual privada)

VRF Virtual Routing and Forwarding

VSI Virtual Storage Integrator


Visão geral da soluçã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

Introdução


10

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

Arquitetura da solução


Alta disponibilidade de aplicativo SAP

Os servidores de aplicativos SAP foram totalmente virtualizados com o VMware ESXiTM 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.


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.


Figura 7. Arquitetura da solução


14

‎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

A e B Servidor de enfileiramento SAP, servidor de mensagens SAP

Várias instâncias de diálogo do SAP

A e B 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 A e B SAP Oracle Home, diretório global SAP, diretório de transporte SAP, diretório ASCS SAP

EMC Symmetrix VMAX 20K A Armazenamento local, RAID, múltiplos caminhos

EMC Symmetrix VMAX 10K B 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.

Camadas de proteção


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.

‎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 SAP OLTP

Tamanho do banco de dados 500 GB

Nome do banco de dados VSE

RAC Oracle 4 nós físicos

Perfil da carga de trabalho Processos order-to-cash personalizados do SAP

Perfil do banco de dados e da carga de trabalho


16

‎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

2 Cluster VPLEX Metro, com:

2 engines VS2

Servidores de banco de dados Oracle RAC

4 4 CPUs de oito núcleos, 128 GB de RAM

Servidores VMware ESXi para SAP

4 2 CPUs de quatro núcleos, 128 GB de RAM

Servidor VMware ESXi para VPLEX Witness

2 2 CPUs de dois núcleos, 48 GB de RAM

Switch de rede e plataforma de roteamento

2 Backbone Brocade DCX 8510, com:

Cartão de extensão de FC Fx8-24

2 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

Recursos de hardware


‎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 Q4 2012 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 UnisphereTM 5.1 Software de gerenciamento de VPLEX

EMC Unisphere T1.5.0.151 Software de gerenciamento do VMAX

EMC VSI (Virtual Storage Integrator)

5.0.0.95 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 11.2.0.3

Software de cluster e banco de dados Oracle

SAP ERP 6.04 Sistema SAP ERP IDES

Recursos de software


18

Infraestrutura de armazenamento da EMC

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.

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.

Introdução

EMC Symmetrix VMAX 10K


O ambiente operacional Enginuity 5876 Q4 2012 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

Enginuity

EMC Symmetrix VMAX 20K

EMC Unisphere for VMAX


20

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

Tamanho do dispositivo (GB)

OCR 5 8

FRA 4 16

REDO 8 16

DADOS 16 128

ACFS 4 16

Configuração do VMAX


‎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

Tamanho do dispositivo (GB)

Metadados VPLEX 2 80

Volume de registro VPLEX 2 20

Backup de metadados VPLEX 2 80


22

Infraestrutura EMC VPLEX Metro

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.

Introdução


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.


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.

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.

Volumes virtuais

Dispositivo

Dispositivo

Extent Volume de armazenamento


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.

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

Mobilidade de dados do VPLEX


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.


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


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

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.

Configuração da solução VPLEX Metro


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.


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


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

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

Configuração do VPLEX


32

Figura 24. Componentes e status do EMC VPLEX Witness

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

Monitoramento de desempenho do VPLEX


Infraestrutura virtual do VMware

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 5.0 - atualização 1

VMware vCenterTM Server

VMware vSphere vMotion®

VMware vSphere High Availability (HA)

VMware vSphere Distributed Resource SchedulerTM (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.

Introdução


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.

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.

Implementações do VMware no VPLEX Metro


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 27.1

1 Para obter informações detalhadas, consulte o TechBook da EMC: EMC VPLEX Metro Witness Technology and High Availability.


36

Figura 27. VMware HA com VPLEX Witness e interconexão de clusters — exibição lógica

O VMware e a EMC dão suporte a uma configuração estendida de cluster que inclui hosts ESXi de vários locais2. 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 1026692 da base de dados de conhecimento do VMware: Usando o VPLEX Metro com o VMware HA

Configuração estendida de cluster VMware


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


38

Figura 30. Datastore EXT_SAP_VPLEX_DS01 e hosts e máquinas virtuais associados

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

Configuração do VMware vSphere HA


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


40

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

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.

Configuração do VMware vSphere DRS

EMC Virtual Storage Integrator e VPLEX


Figura 35. VSI Storage Viewer — datastores


42

Arquitetura do sistema SAP

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:

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.

Introdução

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


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.

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

Configuração do sistema SAP


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 ASCS5. 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 enfileiramento6. 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ção7.

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.

http://help.sap.com/


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.

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:

OpenAIS8/Corosync9, 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.

Configuração do SUSE Linux Enterprise High Availability Extension


46

‎Tabela 9 mostra a configuração de máquinas virtuais SAP.

Tabela 9. Máquinas virtuais SAP

Função de VM

Quantidade

vCPUs Memória (GB) Bootdisk de

sistema operacional (GB)

Nome de VM

SAP ASCS 1 2 4 32 SAPASCS2

SAP ERS 1 2 4 32 SAPASCS3

SAP AAS 2 2 4 32 SAPDI1

2 4 32 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 38.


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


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


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


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-writer11, 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 1034165: Disabling simultaneous write protection provided by VMFS using the multi-writer flag.


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


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


Arquitetura de banco de dados Oracle

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.

Introdução


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.

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

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.

Oracle RAC e VPLEX

Configuração do Oracle ACFS


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

‎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

Oracle Extended RAC no VPLEX Metro


56

‎Tabela 11 mostra o layout e a configuração do grupo de discos do ASM.

Tabela 11. Tamanho e configuração do grupo de discos do Oracle ASM

Grupo de discos do 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 16 2.048 Externo

EA_SAP_REDO 4 64 Externo

EA_SAP_REDOM 4 64 Externo

EA_SAP_FRA 4 256 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.

Configuração do grupo de discos do Oracle ASM


Infraestrutura de rede da Brocade

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:

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.

Introdução

Rede IP

Switches de datacenter Brocade VDX 6720

Roteadores Brocade série MLX

CNAs Brocade 1020

SAN

Backbones Brocade DCX 8510

HBAs Brocade 825


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+


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

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

Configuração de rede IP


60

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 8510. Elas são usadas no modo ativo-ativo com failover.

Figura 52. As redes SAN da solução

Configuração de rede SAN


Alta disponibilidade e continuidade de negócios Teste e validação

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

Introdução

Falha do processo de serviço de enfileiramento do SAP


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.


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.


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

Falha de máquina virtual da instância do SAP ASCS


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


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.

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.

Falha de nó do Oracle RAC


66


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.

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 VSE003 não está em execução no nó sse-ea-erac-n04

Figura 61. 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.

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.

Falha do local


‎Figura 63 mostra o status do ambiente antes da falha do local.

Figura 63. Status do ambiente antes da falha do Local A


O sistema responde à falha do local da seguinte forma:

Quando o Local A falha, o VPLEX Witness assegura que a regra de dissociação do grupo de consistência, que define cluster-1 como o cluster preferencial, seja sobreposta e que o armazenamento servido pelo cluster-2 VPLEX no Local B permaneça disponível.

Os nós RAC sse-ea-erac-n03 e sse-ea-erac-n04 no Local B permanecem disponíveis.

Quando os servidores ESXi no Local A falham, o VMware HA reinicia SAPASCS3 e SAPDI1 no Local B. SAPASCS3 é reiniciado em um host ESXi diferente para SAPASCS2, conforme prescrito pela regra de afinidade de VM-VM definida.

O SUSE Linux Enterprise High Availability Extension detecta a falha do nó de cluster SAPASCS3. Como o ERS estava sendo executado nesse nó, o cluster não executa nenhuma ação, exceto reiniciar o ERS quando SAPASCS3 reingressa no cluster. A tabela de bloqueio é preservada e permanece operacional o tempo todo.

Os usuários finais no SAPDI1 perdem suas sessões devido à falha de servidor ESXi. Durante o processo de reinicialização, os novos usuários são direcionados para SAPDI2. Quando o SAPDI1 é reiniciado no Local B, os usuários podem fazer log-in no SAPDI1 novamente.

‎Figura 64 mostra o status do ambiente depois da falha do local.

Figura 64. Status do ambiente após a falha do Local A

Resultado

‎Tabela 12 mostra os comportamentos esperado e observado do sistema quando o Local A falha.


68

Tabela 12. Comportamentos esperado e observado

Sistema Status antes do

teste Comportamento

esperado Comportamento

observado

Nós Oracle RAC (banco de dados VSE)

sse-ea-erac-n01 (Local A)


sse-ea-erac-n03 (Local B)


Todos disponíveis

Ejetado

Ejetado

Disponível

Disponível

Ejetado

Ejetado

Disponível

Disponível

Servidor ESXi Máquina virtual

sse-ea-r710a (Local A) SAPASCS3

sse-ea-r710b (Local A) SAPDI1

sse-ea-r710c (Local B) SAPDI2

sse-ea-r710d (Local B)

SAPASCS2

Todos disponíveis

Não disponível VMware HA reinicia o Local B


Disponível Disponível






Cluster VPLEX VPLEX1 – Local A – cluster-1

VPLEX2 – Local B – cluster-2 Todos disponíveis

Não disponível

Disponível

Não disponível

Disponível

Serviços SAP Enqueue Replication Server

Servidor de enfileiramento/ mensagens

Todos disponíveis

Não disponível

SLE HAE reiniciado após a reinicialização no Local B

Disponível

Não disponível

SLE HAE reiniciado após a reinicialização no Local B

Disponível

Cenário do teste

Este cenário de teste verifica se, no caso do isolamento de um cluster VPLEX, os aplicativos e banco de dados SAP continuem operando no local sobrevivente sem interrupção.

Para testar este cenário de falha, simulamos o isolamento do cluster preferencial no Local A, com a rede IP de Gerenciamento externo e a rede de comunicações VPLEX WAN particionada. A rede de LAG permanece disponível. O VPLEX Witness permanece disponível no Local C. No Local B, o cluster-2 VPLEX permanece em comunicação com o VPLEX Witness.


O sistema responde ao isolamento de cluster VPLEX da seguinte forma:

Quando o VPLEX no Local A é isolado, o VPLEX Witness assegura que a regra de dissociação do grupo de consistência, que define cluster-1 como o cluster preferencial, seja sobreposta e que o armazenamento servido pelo cluster-2 VPLEX no Local B permaneça disponível.

Os nós RAC sse-ea-erac-n03 e sse-ea-erac-n04 no Local B permanecem disponíveis e os nós RAC sse-ea-erac-n01 e sse-ea-erac-n02 no Local A são ejetados.

Os servidores ESXi no Local A permanecem disponíveis e as máquinas virtuais SAPASCS2 e SAPDI1 permanecem ativas devido ao uso da Interconexão de clusters VPLEX Metro HA.

Isolamento de cluster VPLEX


‎Figura 65 mostra o status do ambiente após o isolamento do VPLEX no Local A.

Figura 65. Status do ambiente após o isolamento do VPLEX no Local A

Resultado

‎Tabela 13 mostra os comportamentos esperado e observado do sistema quando o VPLEX no Local A é isolado.

Tabela 13. Comportamentos esperado e observado

de dados Status antes do teste

Comportamento esperado

Comportamento observado

Nós Oracle RAC (banco de dados VSE)





Todos disponíveis

Ejetado

Ejetado

Disponível

Disponível

Ejetado

Ejetado

Disponível

Disponível

Servidor ESXi

Máquina virtual

sse-ea-r710a (Local A)

SAPASCS2

sse-ea-r710b (Local A)

SAPDI1

sse-ea-r710c (Local B)

SAPDI2

sse-ea-r710d (Local B)

SAPASCS3

Todos disponíveis

Todos disponíveis

Todos disponíveis

Cluster VPLEX VPLEX1 – Local A – cluster-1

VPLEX2 – Local B – cluster-2 Todos disponíveis

Não disponível

Disponível

Não disponível

Disponível

Serviços SAP Enqueue Replication Server

Servidor de enfileiramento/ mensagens

Todos disponíveis

Todos disponíveis

Todos disponíveis


70

Conclusão

Esta solução demonstra a transformação de uma implementação SAP ativa-passiva tradicional em uma solução de continuidade de negócios altamente disponível com datacenters do tipo ativo-ativo e disponibilidade de aplicativo ininterrupta.

A solução combina componentes de alta disponibilidade EMC, VMware, Oracle, SUSE e Brocade com o seguinte:

Elimina pontos únicos de falha em todas as camadas do ambiente

Fornece datacenters ativo-ativo com suporte para RPOs e RTOs próximos de zero

Permite a continuidade de negócios essenciais para aplicativos SAP

Cada ponto único de falha foi identificado e reduzido com o uso de componentes tolerantes a falha e tecnologias de cluster de alta disponibilidade. A utilização de recursos aumentou com a ativação de acesso a dados ativo-ativo. O tratamento de falhas foi totalmente automatizado para eliminar o SPOF e, frequentemente mais imprevisível, da arquitetura: pessoas e processos.

As plataformas de armazenamento de classe corporativa EMC Symmetrix VMAX série 10K com Enginuity fornecem a base para a solução.

Além disso, o uso das ferramentas de gerenciamento e monitoramento, como vSphere Client, EMC Virtual Storage Integrator e das ferramentas de desempenho VPLEX simplifica o gerenciamento operacional e permite o monitoramento e o mapeamento da pilha de infraestrutura.

O Oracle RAC em clusters de longa distância sobre VPLEX oferece estes benefícios:

Gerenciamento simplificado da operação: A instalação, a configuração e a manutenção são iguais às de uma implantação RAC de local único.

O host se conecta apenas ao cluster VPLEX local, mas tem acesso completo de leitura-gravação ao mesmo banco de dados em ambos os locais.

Não é necessário implementar Voting Disk e Clusterware Oracle em um terceiro local

Elimina os caros ciclos de CPU de host consumidos pelo espelhamento ASM, o I/O é enviado somente uma vez do host para o VPLEX local.

Capacidade de criar grupos de consistência que protegem vários bancos de dados e/ou aplicativos como uma unidade

Para verificar a solução, a equipe de validação da EMC executou os seguintes testes e observou os comportamentos indicados:

Simulação de uma falha de processo de serviço de enfileiramento SAP

O aplicativo continua sem interrupção

Simulação de uma falha de máquina virtual da instância do SAP ASCS


Resumo

Resultados


Simulação de uma falha de nó Oracle RAC


Simulação de uma falha total de local


Validação da funcionalidade do VPLEX Witness durante o isolamento simulado de um cluster VPLEX


O teste demonstra como as soluções de alta disponibilidade VMware, SAP, SUSE e Oracle eliminam os pontos únicos de falha no nível local.

Também demonstra como o VPLEX Metro, em combinação com SUSE Linux Enterprise High Availability Extension, Oracle Extended RAC e sistemas de rede Brocade, amplia essa alta disponibilidade para ultrapassar 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. O VPLEX Witness e a Interconexão de clusters oferecem um nível de flexibilidade ainda mais alto.

Juntas, essas tecnologias permitem a transformação de uma implementação de datacenter ativo-passivo tradicional em uma solução de continuidade de negócios essenciais com datacenters do tipo ativo-ativo, disponibilidade de aplicativos 24 horas por dia, 7 dias por semana, nenhum ponto único de falha e RTOs e RPOs próximos de zero.


72

Referências

Para obter mais informações, consulte os seguintes documentos da EMC (disponíveis em brazil.emc.com e no site de suporte on-line da EMC):

EMC VPLEX Metro Witness Technology and High Availability

Using VMware vSphere with EMC VPLEX Best Practices Planning

Conditions for Stretched Hosts Cluster Support on EMC VPLEX Metro

Oracle Extended RAC with EMC VPLEX Metro Best Practices Planning

EMC VPLEX with GeoSynchrony 5.0 Configuration Guide

Implementation and Planning Best Practices for EMC VPLEX—Technical Notes

EMC VPLEX with GeoSynchrony 5.0 and Point Releases CLI Guide

EMC Simple Support Matrix for EMC VPLEX and GeoSynchrony

Validating Host Multipathing with EMC VPLEX—Technical Notes

EMC VPLEX CLI Guide

Para obter mais informações, consulte os seguintes documentos Oracle:

Moving your SAP Database to Oracle Automatic Storage Management 11g Release 2: A Best Practices Guide

SAP with Oracle Real Application Clusters 11g Release 2 and Oracle Automatic Storage Management 11g Release 2: Advanced Configurations & Techniques

Configuration of SAP NetWeaver for Oracle Grid Infrastructure 11,2.0,2 and Oracle Real Application Clusters 11g Release 2: A Best Practices Guide

Oracle Real Application Clusters (RAC) on Extended Distance Clusters

Oracle Database Upgrade Guide Upgrade to Oracle Database 11g Release 2 (11,2): UNIX For Oracle Patch Set Release 11.2.0.2 and 11.2.0.3

Para obter mais informações, consulte os seguintes documentos VMware:

VMware vSphere Networking ESXi 5.0

VMware vSphere Availability ESXi 5.0

Artigo da Base de conhecimentos VMware 1026692: Using VPLEX Metro with VMware HA

Artigo da Base de conhecimentos VMware 1034165: Disabling simultaneous write protection provided by VMFS using the multi-writer flag

SAP Solutions on VMware vSphere: High Availability

SAP Solutions on VMware: Best Practices Guide

EMC

Oracle

VMware


Para obter mais informações, consulte os seguintes documentos SUSE:

SUSE Linux Enterprise High Availability Extension – High Availability Guide

Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability – Simple Stack

SAP Applications Made High Available on SUSE Linux Enterprise Server 10

Protection of Business-Critical Applications in SUSE Linux Enterprise Environments Virtualized with VMware vSphere 4 and SAP NetWeaver as an Example

Para obter mais informações, consulte os seguintes documentos SAP:

SAP Note 1552925 – Linux High Availability Cluster Solutions

SAP Note 1431800 – Oracle 11,2.0 Central Technical Note

SAP Note 105047 – Support for Oracle Functions in the SAP Environment

SAP Note 1550133 – Oracle Automatic Storage Management (ASM)

SAP Note 527843 – Oracle RAC Support in the SAP Environment

SAP Note 989963 – Linux: VMware Timing Problem

SAP Note 1122388 – Linux: VMware vSphere Configuration Guidelines

SAP Note 1310037 – SUSE Linux Enterprise Server 11: Notas de instalação

SAP Installation Guide for SAP ERP 6.0 – EHP 4 Ready ABAP on Linux: Oracle - Based on SAP NetWeaver 7.0 including Enhancement Package 1

Portal de ajuda de Configuração do SAP Enqueue Replication Server

SUSE

SAP


74

Apêndice: Exemplos de configuração node SAPASCS2 \ attributes standby="off" node SAPASCS3 \ attributes standby="off" primitive rsc_IP_VSE_SAPVIPE ocf:heartbeat:IPaddr2 \ operations $id="rsc_IP_VSE_SAPVIPE-operations" \ op monitor interval="10s" timeout="20s" on_fail="restart" \ params ip="xxx.xxx.xxx.xxx" \ meta is-managed="true" primitive rsc_SAP_VSE_ASCS00_SAPVIPE ocf:heartbeat:SAPInstance \ operations $id="rsc_SAP_VSE_ASCS00_SAPVIPE-operations" \ op monitor interval="120" enabled="true" role="Master" timeout="60" start_delay="5" \ op start interval="0" timeout="180" \ op stop interval="0" timeout="240" \ op promote interval="0" role="Master" timeout="320" start_delay="0" \ op promote interval="0" role="Master" timeout="320" start_delay="0" \ params InstanceName="VSE_ASCS00_SAPVIPE" ERS_InstanceName="VSE_ERS01_SAPASCS2" AUTOMATIC_RECOVER="true" START_PROFILE="/sapmnt/VSE/profile/START_ASCS00_SAPVIPE" ERS_START_PROFILE="/sapmnt/VSE/profile/START_ERS01_SAPASCS2" \ meta target-role="Started" primitive sbd_stonith stonith:external/sbd \ meta target-role="Started" op monitor interval="15" timeout="15" start-delay="15" \ params sbd_device="/dev/sdb" group grp_sap_VSE rsc_IP_VSE_SAPVIPE \ meta is-managed="true" target-role="started" ms msl_sap_VSE_ASCS00_SAPVIPE rsc_SAP_VSE_ASCS00_SAPVIPE \ meta globally-unique="true" target-role="Started" clone-node-max="1" master-max="1" notify="true" colocation colocation_IP_ASCS inf: grp_sap_VSE:Started msl_sap_VSE_ASCS00_SAPVIPE:Master order ord_VSE_IP_Master : grp_sap_VSE msl_sap_VSE_ASCS00_SAPVIPE:promote symmetrical=false property $id="cib-bootstrap-options" \ dc-version="1,1.5-5bd2b9154d7d9f86d7f56fe0a74072a5a6590c60" \ cluster-infrastructure="openais" \ expected-quorum-votes="2" \ last-lrm-refresh="1329421965" \ default-resource-stickiness="1000" \ no-quorum-policy="ignore" \ stonith-timeout="180s"

SAPSYSTEMNAME = VSE SAPSYSTEM = 00 INSTANCE_NAME = ASCS00 DIR_CT_RUN = $(DIR_EXE_ROOT)/run DIR_EXECUTABLE = $(DIR_INSTANCE)/exe SAPLOCALHOST = SAPVIPE #----------------------------------------------------------------------- # SAP Message Server parameters are set in the DEFAULT.PFL #----------------------------------------------------------------------- ms/standalone = 1 ms/server_port_0 = PROT=HTTP,PORT=81$$ #----------------------------------------------------------------------- # SAP Enqueue Server

Configuração de amostra de CRM

Perfil de instância de amostra do ASCS


#----------------------------------------------------------------------- enque/table_size = 4096 rdisp/enqname = $(rdisp/myname) enque/snapshot_pck_ids = 100 ipc/shm_psize_34 = 0 enque/server/replication = true enque/server/max_requests = 1000 enque/enrep/stop_timeout_s = 0 enque/enrep/stop_retries = 0

SAPSYSTEM = 01 SAPSYSTEMNAME = VSE INSTANCE_NAME = ERS01 #-------------------------------------------------------------------- # Special settings for this manually set up instance #-------------------------------------------------------------------- DIR_EXECUTABLE = $(DIR_INSTANCE)/exe DIR_CT_RUN = /usr/sap/VSE/SYS/exe/run #-------------------------------------------------------------------- # Settings for enqueue monitoring tools (enqt, ensmon) #-------------------------------------------------------------------- enque/process_location = REMOTESA rdisp/enqname = $(rdisp/myname) #-------------------------------------------------------------------- # standalone enqueue details from ASCS instance #-------------------------------------------------------------------- ASCSID = 00 ASCSHOST = SAPVIPE enque/serverinst = $(ASCSID) enque/serverhost = $(ASCSHOST) #-------------------------------------------------------------------- # HA polling #-------------------------------------------------------------------- #enque/enrep/hafunc_implementation = script #enque/enrep/poll_interval = 10000 #enque/enrep/hafunc_init = #enque/enrep/hafunc_check = $(DIR_EXECUTABLE)/enqtest.sh

SAPSYSTEMNAME = VSE SAPSYSTEM = 01 INSTANCE_NAME = ERS01 #----------------------------------------------------------------------- # Special Settings for this manually set up instance #----------------------------------------------------------------------- ASCSID = 00 DIR_CT_RUN = /usr/sap/VSE/SYS/exe/run DIR_EXECUTABLE = $(DIR_INSTANCE)/exe _PF = $(DIR_PROFILE)/VSE_ERS01_SAPASCS2 SETENV_00 = LD_LIBRARY_PATH=$(DIR_EXECUTABLE) SETENV_01 = PATH=$(DIR_INSTANCE)/exe:%(PATH) #----------------------------------------------------------------------- # Copy SAP Executables #----------------------------------------------------------------------- _CPARG0 = list:$(DIR_EXECUTABLE)/ers.lst Execute_00 = immediate $(DIR_EXECUTABLE)/sapcpe$(FT_EXE) $(_CPARG0) pf=$(_PF) #----------------------------------------------------------------------- # Start enqueue replication server #----------------------------------------------------------------------- _ER = er.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)

Perfil de instância de amostra do ERS

Perfil START de amostra do ERS


76

Execute_01 = immediate rm -f $(_ER) Execute_02 = local ln -s -f $(DIR_EXECUTABLE)/enrepserver $(_ER) Restart_Program_00 = local $(_ER) pf=$(_PF) NR=$(ASCSID)

SAPSYSTEMNAME = VSE SAPSYSTEM = 00 INSTANCE_NAME = D00 DIR_CT_RUN = $(DIR_EXE_ROOT)/run DIR_EXECUTABLE = $(DIR_INSTANCE)/exe exe/saposcol = $(DIR_CT_RUN)/saposcol rdisp/wp_no_dia = 10 rdisp/wp_no_btc = 3 exe/icmbnd = $(DIR_CT_RUN)/icmbnd icm/server_port_0 = PROT=HTTP,PORT=80$$ SAPFQDN = sse.ea.emc.com SAPLOCALHOSTFULL = $(SAPLOCALHOST).$(SAPFQDN) ipc/shm_psize_10 = 136000000 ipc/shm_psize_40 = 112000000 rdisp/wp_no_vb = 1 rdisp/wp_no_vb2 = 1 rdisp/wp_no_spo = 1 enque/process_location = REMOTESA enque/serverhost = SAPVIPE enque/serverinst = 00 enque/deque_wait_answer = TRUE enque/con_timeout = 2000 enque/con_retries = 60

DI sample instance profile

Documents

CONTINUIDADE DE NEGÓCIOS ESSENCIAIS DA EMC PARA … · Availability, Oracle RAC, sistema de rede Brocade e SUSE Linux Enterprise Server para aplicativos SAP. Novembro de 2012