1 / 33

EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP

EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP. EMC VPLEX, EMC Symmetrix VMAX, EMC VNX, VMware vSphere HA, Brocade Networking, Oracle RAC, SUSE Linux Enterprise. EMC Solutions Group. Agenda. Solution overview and architecture Solution components and configuration EMC VPLEX Metro

vivian
Download Presentation

EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP EMC VPLEX, EMC Symmetrix VMAX, EMC VNX, VMware vSphere HA, Brocade Networking, Oracle RAC, SUSE Linux Enterprise EMC Solutions Group

  2. Agenda • Solution overview and architecture • Solution components and configuration • EMC VPLEX Metro • VMware vSphere • SAP system architecture • Oracle database • Brocade network • EMC storage • Testing and validation • Summary and conclusion

  3. Mission-Critical Business Continuity for SAP • Eliminate single points of failure at all layers in environment • Provide active/active data centers with near-zero RPOs and RTOs • Fully automatic failure handling and load balancing • Zero downtime maintenance • Simplified deployment of Oracle RAC on Extended Distance Clusters • Increased infrastructure utilization • Active/active data centers • Near-zero RTOs and RPOs • 24/7 application availability • No single points of failure • Simplified high availability management

  4. The Challenge; the Solution The ChallengeSAP single points of failure The SolutionHigh availability and business continuity

  5. Eliminating Single Points of Failure

  6. Solution Components • Mission-critical business continuity for SAP ERP is delivered by combination of technologies from EMC, VMware, Oracle, SUSE, and Brocade • EMC VPLEX Metro • EMC VPLEX Witness • EMC Symmetrix VMAX and EMC VNX • Oracle RAC on Extended Distance Clusters • VMware vSphere • VMware vSphere High Availability • SUSE Linux Enterprise Server for SAP Applications, with SUSE Linux Enterprise High Availability Extension • SAP Enqueue Replication Server • Brocade MLXe core routers • Brocade DCX 8510 Backbones

  7. Solution Architecture

  8. Protection Layers

  9. VPLEX Metro – Introduction Site A Site B VPLEXCross-Cluster Connect • SAN-based storage federation • Active/active data centers • ~100 km distance • Workload rebalancing • Near-zero RPO/RTO • Data center migration VPLEX WITNESS Site C • VPLEX High Availability • VPLEX Witness • VPLEX Cross-Cluster Connect AccessAnywhere Active Active

  10. VPLEX Metro Configuration • VPLEX logical structures • Consistency group • Virtual volume • Distributed device • Device • Extent • Storage volume

  11. VMware Virtualization Components • vSphere 5.0 • vMotion • Storage vMotion • VMware HA • DRS (Distributed Resource Scheduler) • EMC PowerPath/VE • EMC Virtual Storage Integrator (VSI)

  12. VMware vSphere with VPLEX Metro Cross-Cluster Connect

  13. VMware Stretched Cluster Configuration vCenterscreenshots

  14. VMware HA and DRS Configuration HA Restart Priority for SAP VMs HA and DRS enabled for VMware stretched cluster HA heartbeat datastores DRS VM-VM affinity rule

  15. EMC Virtual Storage Integrator and VPLEX • EMC VSI tab in vCenter GUI

  16. SAP System Architecture • SAP application software • SAP Enhancement Package 4 for SAP ERP 6.0 IDES • SAP NetWeaver Application Server for ABAP 7.01 • SAP Enqueue Replication Server • Operating system • SUSE Linux Enterprise Server (SLES) for SAP Applications 11 SP1 • SUSE Linux Enterprise High Availability Extension • Virtualization • SAP services on VMware virtual machines • Oracle RAC database on physical servers

  17. SAP System Architecture – Design Considerations • Enqueue and message servers decoupled from Central Instance and implemented as services within ASCS instance • ERS installed as part of HA architecture to provide zero application lock loss • Two dialog instances provide redundant work processes such as dialog, background, update, spool • ASCS instance installed with virtual hostname to decouple it from VM hostname • ERS instance installed with different instance number to avoid confusion when both ASCS and ERS are under cluster control

  18. SAP System Architecture – Design Considerations -Continued • SAP update processes configured on additional application server instances • ASCS, ERS, start, and dialog instance profiles updated with ERS configurations • SAP shared file systems stored on Oracle ACFS and mounted as NFS shares on SAP VMs – presented as highly available NFS resource managed by Oracle Clusterware • Storage for entire SAP environment encapsulated, virtualized, distributed across two sites, and made available to SAP servers through VPLEX Metro

  19. SUSE Linux Enterprise HAE Configuration • SLES HAE protects enqueue and message servers across two cluster nodes built on VMware VMs • VMware High Availability protects the VMs • Virtual IP address, master/slave, and SAPInstance resource agents monitor and control resource availability • SAPInstance agent controls ASCS and ERS instances – configured as master/slave resource to ensure ASCS and ERS are never started on same node • VMDK partition used as SBD STONITH device – with multi-writer option configured to enable write access by multiple VMs

  20. Oracle Database Architecture • Oracle components • Oracle Database 11g Release 2 Enterprise Edition • Oracle ASM • Oracle ACFS • Oracle Clusterware • Single-instance database migrated to 4-node physical RAC cluster on ASM • Oracle Extended RAC Over VPLEX • Simplified management • Hosts connect only to their local VPLEX cluster • Hosts send I/O only once to the local cluster – dual writes not required • No need to deploy Oracle voting disk and Clusterware on third site • Eliminates costly host CPU cycles consumed by host-based mirroring • Protect multiple databases and/or applications as a unit

  21. Oracle Database Configuration • 4 ACFS volumes mounted across RAC cluster • TRANS, ASCS500, SAPMNT exported as NFS shares to SAP servers • Shared file systems presented as highly available NFS resource managed by Oracle Clusterware • ASM disk groups configured to reflect existing single-instance layout

  22. Brocade Network Infrastructure IP network SAN

  23. EMC Storage Layout • Site B – EMC VNX5700 • Traditional RAID groups and LUNs Site A – EMC Symmetrix VMAX • Virtual Provisioning

  24. Testing and Validation Tests • SAP enqueue service process failure • SAP ASCS instance virtual machine failure • Oracle RAC node failure • Site failure (VPLEX cluster, ESXi server, network, RAC nodes) • VPLEX cluster isolation • Expected behaviorApplication continues without interruption

  25. SAP Enqueue Service Process Failure 1 SAPInstance resource agent detects/reports failure. Master/slave resource agent promotes SAPASCS1 to master (which hosts ASCS services). Master/slave resource agent starts ERS on SAPASCS2 when it rejoins cluster. Replicated lock table restored. 2 • Application continues without interruption • No administrative intervention required 3 4 Result

  26. SAP ASCS Instance VM Failure SAPASCS2 becomes unavailable from vSphere Client. SAPInstance resource agent detects/reports failure. VMHA restarts failed VM on surviving ESXi host. Master/slave resource agent promotes SAPASCS1 to master (which hosts ASCS services) and starts ERS on SAPASCS2 when it rejoins cluster. Replicated lock table restored. 1 2 • Application continues without interruption • No administrative intervention required 3 4 5 Result

  27. Oracle RAC Node Failure Result RAC node goes offline – instance VSE003 unavailable. SAP instance work process connects to another RAC node. • End user experiences longer transaction response time when DI work process reconnects to other RAC node. • Uncommitted transactions rolled back at DB level to guarantee data consistency; end user receives system error message and needs to restart transaction. • No administrative intervention required. 1 2

  28. Environment Status Before Site Failure Status • All RAC nodes running. • VPLEX clusters available on both sites. • ESXi servers available on both sites. • Site A and Site B SAP virtual machines up.

  29. Site Failure VPLEX Witness overrides consistency group detach rule so VPLEX on Site B remains available. RAC nodes on Site B remain available. VMHA restarts SAPASCS1 and SAPDI1 on Site B. SLE HAE detects failure of SAPASCS1 and restarts ERS when that node rejoins cluster. End users on SAPDI1 lose their sessions, but can log in again when it restarts on Site B. During restart, new users are directed to SAPDI2. 1 2 3 4 5

  30. VPLEX Cluster Isolation VPLEX Witness overrides consistency group detach rule so VPLEX on Site B remains available. RAC nodes on Site B remain available. RAC nodes on Site A are ejected. ESXi servers on Site A remain available. Virtual machines SAPASCS1 and SAPDI1 remain active due to VPLEX Metro HA Cross-Cluster Connect. 1 2 3 4 5

  31. Testing and Validation Tests • SAP enqueue service process failure • SAP ASCS instance virtual machine failure • Oracle RAC node failure • Site failure (VPLEX cluster, ESXi server, network, RAC nodes) • VPLEX cluster isolation • Observed behaviorApplication continues without interruption

  32. Solution combines EMC, SAP, VMware, Oracle, SUSE, and Brocade technologies to: Eliminate single points of failure at all layers in environment Provide active/active data centers with near-zero RPOs and RTOs Enable mission-critical business continuity for SAP applications Summary and Conclusion • Fully automatic failure handling and load balancing • Zero downtime maintenance • Simplified deployment of Oracle RAC on Extended Distance Clusters • Increased infrastructure utilization • Active/active data centers • Near-zero RTOs and RPOs • 24/7 application availability • No single points of failure • Simplified high availability management

More Related