Step-By-Step Guidelines to Formulate a High Availability Strategy for Your Business Objects Landscape Eric Vallo EV Technologies

Transcription

1 Step-By-Step Guidelines to Formulate a High Availability Strategy for Your Business Objects Landscape Eric Vallo EV Technologies 2012 Wellesley Information Services. All rights reserved.

2 In This Session Look at various architectural options for disaster recovery s Leveraging local data centers or third-party vendors Help you determine the ideal level of deployment for your disaster recovery initiatives Construct a fault-tolerant SAP BusinessObjects enterprise architecture Support high availability clusters without going over budget Identify the appropriate mix of minimum availability to recovery need s Ensuring the ongoing availability of mission critical business analytics Learn how to create a recoverable and scalable environment even with limited resources 1

3 What We ll Cover Considering Availability Constructing A Fault-Tolerant Architecture Supporting High Availability Clusters Achieving Disaster Recovery Readiness Creating a Backup and Recovery Strategy Wrap-up 2

4 Budgets Come in All Shapes and Sizes Thank you sir...may I have another? s Budget? What budget? Alright, how much is this going to cost me? s Organizational awareness is there that these strategies are needed, but general trust in the needed investment is not totally there. More money than sense. s Money is no object. Make sure SAP BusinessObjects works ALL THE TIME. 3

5 Define Redundant Merriam-Webster Dictionary defines "Redundant" as: serving as a duplicate for preventing failure of an entire system (as a spacecraft) upon failure of a single component See also: no longer needed for a job and hence laid off (maybe that s not right) 4

6 Achieving Redundancy We achieve redundancy in an SAP BusinessObjects environment within a few major categorizations of redundancy s Failover s High Availability s Disaster Recovery s Backup and Recovery 5

7 Achieving Redundancy (cont.) Failover High Availability Disaster Recovery Backup and Recovery 6

8 The Politics of Upgrades Greg Myers, also of EV Technologies, put it best in a recent SAP Inside Track Presentation on The Politics of Upgrades s Never give up! Be the true-believer and keep driving the agenda s Show management the benefit to customers s Use small words so they understand s Talk in terms of benefits and risks s Remember the risk of doing nothing! s When all else fails, quit and go work for your pals. Playback of this presentation is available on the SAP Community Network: wiki.sdn.sap.com/wiki/display/events/sap+inside+track +Washington+DC

9 What We ll Cover Considering Availability Constructing A Fault-Tolerant Architecture Supporting High Availability Clusters Achieving Disaster Recovery Readiness Creating a Backup and Recovery Strategy Wrap-up 8

10 Fault Tolerance Fault tolerance, while not necessarily defining characteristics of a system that is highly available or disaster resistant, is the first building block Conveys that the architecture can withstand a failure of a single hardware or software component Fulfilled by: s Identifying the percentage of utilization that must be achieved during a hardware or software failure s Creating components that can sustain increased load due to peer component failure Does not necessarily prevent short term outage, but creates opportunity to avoid a longer term outage 9

11 Fault Tolerant Components Denotes Active vs. Passive cluster nodes 10

12 Achieving Fault Tolerance Server Level Fault Tolerance s Acquire servers with: Multi-CPU/multi-core architecture Sufficient RAM to cope with failed sticks RAID disk for local storage Redundant network cards Redundant cooling Redundant power 11

13 Achieving Fault Tolerance (cont.) Cluster Level Fault Tolerance s Acquire secondary/tertiary servers that mirror a primary node or nodes Carefully consider and review licensing with vendors to understand cost implications of passive cluster nodes Size passive cluster nodes based on the known SLA for the percentage of users that must be supported in an outage Mirror the active cluster node in configuration so that on activation, it can assume the role of the active node 12

14 Achieving Fault Tolerance (cont.) Web Tier Fault Tolerance s Assuming the Web tier has been decentralized from the app tier Ensure physical hardware or virtualized Web servers have an active or passive node Ensure that any load balancing capability has a redundant device or server Caution: DNS load balancing is known to cause unpredictable results and should be avoided 13

15 Achieving Fault Tolerance (cont.) Other opportunities to avoid fault s File repository storage should be present on redundant disk in a storage mechanism that can operate in a hot-swap mode s Network infrastructure should be capable of bypassing faulty hardware s Database infrastructure should function on hardware that can be successfully failed-over to secondary hardware to ensure availability of the cluster Do not co-locate SAP BusinessObjects CMS and Audit databases with reporting data sources Ensures availability of reporting despite unrelated database server maintenance 14

16 The Role of Virtualization Virtualization is an excellent candidate for failover nodes in a cluster Consider that typical failover scenarios do not require 100% availability for all end users A VM may exist as a passive node in a cluster in a paused state with little-to-no impact on a VM farm Other ancillary services such as BI Mobile, Metadata Manager, etc., may be excellent candidates for virtualization and as passive cluster nodes 15

17 What We ll Cover Considering Availability Constructing A Fault-Tolerant Architecture Supporting High Availability Clusters Achieving Disaster Recovery Readiness Creating a Backup and Recovery Strategy Wrap-up 16

18 High Availability High availability clusters imply that all consideration is given to creating a cluster with no single-points of failure A hardware or software failure at any point of the SAP BusinessObjects architecture will not cause an outage, including: s Application tier s Web tier s File repositories s Central Management Server database and Auditor database s Network architecture In an environment where high speed interconnects exist between data centers, clusters are spread across each 17

19 High Availability Components (Mostly) Denotes Active/ Active cluster nodes Denotes Active/ Active cluster nodes Database and File Repository components should not be assumed HA 18

20 Achieving High Availability Server Level High Availability no different than Failover hardware requirements Cluster Level High Availability s Two or more cluster nodes exist in an active state s One or more passive nodes are still an option to ensure an increased opportunity for failover s Know what percentage of users must be supported in a failure Web Tier High Availability s Two or more Web servers are present and can concurrently handle the additional load of this environment Database Infrastructure for CMS and Audit database should exist on clustered database to ensure no single point of failure File Repository storage for the CMS must exist on hardware that can provide active-failover to another node 19

21 Load Balancing Load balancing is the distribution of workload across multiple, concurrent/active components of an architecture There are several areas of a high availability architecture where load balancing comes into play s Web tier across multiple web servers s Application tier between multiple SAP BusinessObjects servers s CMS/Auditor database with multiple database servers s The SAN for the file repository servers 20

22 Load Balancing (cont.) Web tier load balancing may be achieved in one of two ways s Software load balancing is built in to many Windows and *nix architectures Uses components of the operating system and DNS to reroute load Must be carefully designed also to ensure no single point of failure on this server s Hardware load balancing networking components are commodity hardware in recent years Easily scaled/redundant with dual load balancers Common terms and configurations to optimize distribution of load across web tier nodes 21

23 Load Balancing (cont.) Application tier load balancing is part of SAP BusinessObjects secret sauce Thanks to tried and true Crystal Enterprise Services Oriented Architecture, it is cluster-aware out of the box s SAP BusinessObjects Edge and Crystal Reports Server customers need not apply Regular, repeated health checks to other cluster nodes and services ensure the platform knows where to process requests 22

24 The Role of Virtualization Virtualization is a questionable alternative in newer SAP BusinessObjects deployments s System requirements are far more substantial than releases prior to XI 3.1 Consider the fact that there is some percentage loss of capacity on a VM farm to decide if an active/active cluster can sustain that loss in capacity Ensure that if selected, VM nodes do not co-exist on a single VM host to distribute load and failure points s Relying on components like vmotion to dynamically move VMs may prove unpredictable for performance 23

25 What We ll Cover Considering Availability Constructing A Fault-Tolerant Architecture Supporting High Availability Clusters Achieving Disaster Recovery Readiness Creating a Backup and Recovery Strategy Wrap-up 24

26 Disaster Recovery Clusters that are designed to provide availability in the instance of a cataclysmic event What defines a cataclysmic event? s Flood s Fire s Earthquake s Meteor strike s Zombie apocalypse s Insert disaster that knocks a data center offline here If SAP BusinessObjects is considered a mission critical application, a disaster recovery plan is imperative 25

27 Achieving Disaster Recovery One data center is insufficient to satisfy a disaster recovery scenario Large enterprises should leverage corporate data centers in other parts of the country (or even globally) to satisfy up time requirements Smaller enterprises should consider third-party disaster recovery data centers which can mimic entire environments Like fault tolerance, plan for the percentage of reporting operations that must be satisfied When alternate data center is used for High Availability, remember, milliseconds can be like hours to users 26

28 Achieving Disaster Recovery (cont.) HA cluster spans two data centers for DR requirement fulfillment 27

29 The Role of Virtualization VM technology can provide significant benefit for ramping up systems in disparate data centers s Modern deployments can quickly move live/running VMs to alternate data centers Consider the fact that there is some percentage loss of capacity on a VM farm to decide if an active/active cluster can sustain that loss in capacity Ensure that if selected, VM nodes do not co-exist on a single VM host to distribute load and failure points s Relying on components like vmotion to dynamically move VMs may prove unpredictable for performance 28

30 Disaster Recovery Preparedness Simply designing for Disaster Recovery is insufficient Annual or semi-annual exercises should be executed to validate plans Plans must be kept up to date and relevant to current business and IT stakeholders to ensure a proper Disaster Recovery failover Any changes in hardware or software configuration at primary site should be mirrored at the recovery site as appropriate 29

31 What We ll Cover Considering Availability Constructing A Fault-Tolerant Architecture Supporting High Availability Clusters Achieving Disaster Recovery Readiness Creating a Backup and Recovery Strategy Wrap-up 30

32 Backup and Recovery Defines the processes to capture content to tape or alternative backup method Relevant in any of the previously mentioned scenarios s Failover s High Availability s Disaster Recovery Strives to create a recovery point for a server or set of servers which either a complete system can be recovered, or an individual report can be recovered from 31

33 Backup Strategies Cold Backups s Typically considered as the only way to get accurate, point-intime backups s Requires that both the CMS/Audit databases and the file repository servers are backed up at the same time s Requires that all SAP BusinessObjects services are brought to a stop Hot Backups s SAP BusinessObjects services can continue to run s CMS/Audit databases and file repository server backups are also timed together s In use/locked reports may not be backed up at the same time 32

34 Backup Strategies Snapshots Snapshots are a capability in many major architectures Consider an SAP BusinessObjects architecture leveraging Oracle for CMS/Audit databases, and EMC for SAN s Each technology provides a point-in-time recovery option s Times can be chosen based on a need, regardless of tape backup strategy Also known as a roll-back Importantly, get engaged with system admins and database admins to get an understanding if this capability exists within your environment 33

35 Recovery There are two approaches to consider in recovery from tape or snapshot s s Drop and Restore Completely destroys the content created since the backup which has been recovered from Lowest infrastructure cost is incurred End users lose newly generated content L Restore to Standby Use a standby SAP BusinessObjects server, database, and file repository server to recover to Expensive on large clusters with significant servers Easier if you know the individual reports to recover (requires knowledge of the report CUID) Migrate recovered content to production CMS 34

36 The Role of Virtualization VM usefulness is isolated to recovery environments Left paused until a recovery situation arises If possible, avoid placing on same network subnet as production cluster 35

37 What We ll Cover Considering Availability Constructing A Fault-Tolerant Architecture Supporting High Availability Clusters Achieving Disaster Recovery Readiness Creating a Backup and Recovery Strategy Wrap-up 36

38 Testing Each Scenario Like any project, testing is a critical component of a successful recovery strategy Failover Testing s Stop active cluster nodes and start the passive nodes to ensure operations can resume as normal High Availability Testing s Stop active cluster nodes and ensure that the environment does not encounter interruption Disaster Recovery Testing s Validate that a DNS or routing change can successfully reroute all traffic from your primary location to your alternate data center Backup and Recovery Testing s Can a file system restore to a mirrored system succeed? 37

39 Who Is Important to You? Each organization has layers of architects and administrators Find the right ones and partner up to meet your objectives s Windows/Unix/Linux Administrators to achieve buy in on your server deployments s Database Administrators know recovery capabilities for CMS and Audit databases as well as reporting data sources s Web Administrators are in tune with the current deployments of your Web applications s Network Administrators know network capacity, disaster routing, and other network infrastructure characteristics s Storage Administrators design best-case storage for applications s VM Administrators know the quick recovery capabilities for a virtualized environment 38

40 Audit Included with SAP BusinessObjects, is Auditor Use it to regularly monitor distribution of load at both a server level as well as an individual processing or job server level s Use to detect faults in components by simply observing for uneven distribution Use for validation in a post-failover scenario to ensure missioncritical processing was achieved 3 rd party tools provide additional inspection capabilities to validate common settings across servers 39

41 Additional Resources s SAP BusinessObjects BI 4.x Solution Architecture help.sap.com/businessobject/product_guides s Business Intelligence Platform Administrator Guide evtechnologies.com/blog s Blog on BI 4 wikipedia.org s Really, just about every definition for failover, high availability, and disaster recovery you could want short of hiring a consultant 40

42 7 Key Points to Take Home Fully comprehend the budget available Fully understand the enterprise resources to achieve redundant environments Weigh the pros and cons of virtualization to achieve redundancy Verify the required availability standards in the event of a failure Create a plan that carefully communicates how to manage failures Test the failure scenarios in your environment Develop an annual validation plan 41

43 Your Turn! How to contact me: Eric Vallo 42

44 Disclaimer SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP. 43