Designing A Business Objects Enterprise Environment For High Availability


Published on

Covers the facets of High Availability for BusinessObjects Enterprise installations

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Housekeeping notesWill break for questions at the end of each section. Please hold questions for the breaks to make sure we have time to cover all of the material.
  • High Availability is not for everyone. Complicates the landscape – lots of ‘moving parts’. Let the need drive the solution. Who is using the system, how critical is the BI to accomplishing their job. Are they local? National? Global? What is your IT budget like? Do you have a Data Center? Do you have support from Data Center staff? From your Management? HA can be a bit more costly to set up, but the payback comes from never being down. You don’t have to implement everything you see here today. You can just implement pieces and see improvements.
  • Ask for show of hands how many people have a “Black Box” install of BO. Quickly describe that and how it differs from horizontal.
  • External layerThe external system layer is comprised of a BusinessObjects client, a reverseproxy server that sits outside the corporate firewall, and a load balancer thatdistributes end-user system requests.The client machine is a Windows desktop machine that accessesBusinessObjects applications through a web browser. Because the clientrepresented in the Windows pattern diagram sits outside the corporatefirewall, only HTTP client applications are available from this client machine.Applications that require a direct connection to the BusinessObjects CentralManagement Server (CMS), such as Universe Designer, must run from acomputer that resides within the system security perimeter.The reverse proxy machine runs Apache HTTP Server 2.0 and has twonetwork cards (NICs). One network card is used to communicate externallywith clients, and the other is used for internal facing communications. Thetwo network-card configuration helps conceal internal IP addresses.The load balancer is a Cisco Content Services Switch that distributes clientrequests between the two web servers.
  • Web server layerThe web server layer consists of two machines running Apache HTTP Server2.0.Can also contain static content from BusinessObjects web applications. If you perform a Distributed Install, all jpegs, gifs, and other static files will reside on the Web Layer. This can help reduce the load going to your Application Server and improve performance. (If you use Apache/Tomcat, you have a Distributed Install already)
  • Application server layerThe application server layer includes two application server machines and an LDAP-based authentication server running Active Directory Application Mode (ADAM). Application server software includes BusinessObjects Web Component Adapter (WCA) with Tomcat. CMC and InfoView will also reside in this layer.If you use Oracle (BEA) WebLogic or IBM WebSphere, you can cluster your application servers together as well. Will touch on more in the clustering section of this preso.
  • BusinessObjects Enterprise layerThe BusinessObjects Enterprise layer includes a cluster of three machinesrunning BusinessObjects Enterprise servers, and a separate machine thathosts the BusinessObjects Central Management Server (CMS) database,auditing database, and File Repository Server (FRS).The BusinessObjects Enterprise layer also includes Oracle clients, whichare installed on each of the three machines in the BusinessObjects servercluster. The Oracle clients allow the BusinessObjects servers to accesssystem databases.* Request ports and configuring BOE for use behind a firewall. ** FRS on SAN or Windows File Server Cluster if SAN not available. Latency is key. Measure it.
  • Data layerThe data layer includes an Oracle database server that hosts the corporatedatabase. This is simplified, of course. Will most likely be several different machines or silos where your data comes from. Most important layer to secure. Houses your critical and proprietary corporate data. Customer information? Privacy Act or HIPAA protected? Etc.
  • Basics of incremental vs. full backups Hot vs. cold backups Cold require downtime, however, with a clustered environment, can take down one BOE at a time to back up. Difficult to keep transactions from happening while the backup occurs. In 3.1, use the Repository Diagnostic Tool to reconcile. Hot backups are supported! Use the RDT to reconcile afterwards. Cold backups are better if you can afford the downtime.
  • Memory usage is big. Watch Webi or Crystal servers for how much memory they have allocated and have alerts set when they crest.
  • I can send you any of the referenced documents or presentations upon request.
  • Designing A Business Objects Enterprise Environment For High Availability

    1. 1. [<br />[<br />[<br />ATUL PATANKAR<br />LINDA WILSON<br />JUERGEN LINDNER<br />ASUG INSTALLATION MEMBER MEMBER SINCE: 2000<br />ASUG INSTALLATION MEMBER MEMBER SINCE: 1999<br />SAP POINT OF CONTACT MEMBER SINCE: 1998<br />]<br />Designing a BusinessObjects Enterprise Environment for High Availability <br />Availability<br />Greg Myers<br />Senior Business Intelligence Engineer<br />SEI<br />[<br />March 11th, 2010<br /> Greg Myers, BOCP<br />[<br />
    2. 2. Agenda<br /><ul><li>Overview
    3. 3. Horizontal BusinessObjects Enterprise Architecture
    4. 4. Clustering
    5. 5. Backup and Recovery
    6. 6. Monitoring and Alerting</li></li></ul><li>Overview<br />Why HA?<br /><ul><li> What is your need?
    7. 7. User base ?
    8. 8. Budget?</li></ul>What will HA accomplish?<br /><ul><li> Multiple layers of security
    9. 9. No Single Point of Failure
    10. 10. Ability to stay up 24X7
    11. 11. Can respond to demanding work loads
    12. 12. Fault tolerant</li></li></ul><li>Agenda<br /><ul><li>Overview
    13. 13. Horizontal BusinessObjects Enterprise Architecture
    14. 14. Clustering
    15. 15. Backup and Recovery
    16. 16. Monitoring and Alerting</li></li></ul><li>Horizontal Architecture<br /><ul><li>External Layer
    17. 17. Web Server Layer
    18. 18. Application Server Layer
    19. 19. BusinessObjects Enterprise Layer
    20. 20. Data Layer</li></li></ul><li>Horizontal Architecture – External Layer<br /><ul><li> Key Components:
    21. 21. Client systems
    22. 22. Reverse proxy
    23. 23. Load balancer</li></li></ul><li>Horizontal Architecture – Web Server Layer<br /><ul><li> Key Components:
    24. 24. Apache HTTP servers
    25. 25. Load balancer auto routes to either server
    26. 26. First firewall</li></li></ul><li>Horizontal Architecture – App Server Layer<br /><ul><li> Key Components:
    27. 27. Application server machines
    28. 28. Includes BO Web Component Adapter
    29. 29. LDAP-based authentication server (Sun One, Windows Active Directory)
    30. 30. Second firewall</li></li></ul><li>Horizontal Architecture – BOE Layer<br /><ul><li> Key Components:
    31. 31. Cluster of 3 BOE servers
    32. 32. Separate machine for CMS database and Auditor Schemas
    33. 33. Separate machine for FRS (not pictured)
    34. 34. Third firewall</li></li></ul><li>Horizontal Architecture – Data Layer<br /><ul><li> Key Components:
    35. 35. Corporate Data Stores (Data Warehouse, data marts, etc.)</li></li></ul><li>Horizontal Architecture<br />Questions?<br />
    36. 36. Agenda<br /><ul><li>Overview
    37. 37. Horizontal BusinessObjects Enterprise Architecture
    38. 38. Clustering
    39. 39. Backup and Recovery
    40. 40. Monitoring and Alerting</li></li></ul><li>Clustering<br />What is a CMS Cluster?<br />Multiple CMS services accessing a common repository database<br />Why use CMS Clustering?<br />• Failover Redundancy<br />• Increased System Availability<br />• If one server fails, the system remains up<br />• Distributed Work Load<br />• Increased System Performance<br />• Work is shared across multiple machines<br />
    41. 41. Clustering<br />When should you Cluster?<br />• More than 20 simultaneous users processing requests<br />• More than 20 simultaneous scheduled jobs<br />• High system availability is considered critical<br />• Users are getting error messages that system resources<br /> are unavailable (e.g. WebI servers out of memory)<br />• Scheduled jobs are not completing on time<br />
    42. 42. Clustering - How to Create a CMS Cluster<br />• Clustering Two Existing Machines<br />1. Machine 1: Rename Cluster<br />2. Machine 2: Create Connection to CMS DB<br />3. Machine 2: Stop CMS<br />4. Machine 2: Change DB connection to CMS DB for machine 1<br />5. Machine 2: Restart CMS; Machine 2 joins the cluster<br />Note: You may need to migrate content from Machine 2 to Machine 1 using the Import Wizard prior to clustering the two machines.<br />• Adding a New Machine to an Existing Cluster<br />1. Machine 1: Rename Cluster<br />2. Machine 2: Create Connection to CMS DB<br />3. Machine 2: Install BOE, using Expanded Option<br />
    43. 43. How Does a Cluster Work?<br /><ul><li> Node Servers share db and FRS space
    44. 44. Nodes are Active-Active
    45. 45. FRS is Active-Passive
    46. 46. Clustername is not ‘real’
    47. 47. Client ws requires reg key
    48. 48. Web Apps require xml entry
    49. 49. Services require –ns entry</li></li></ul><li>Clustering – Other forms of Clustering<br /><ul><li>The CMS Database can configured for failover/HA by using DBMS methods (for example, Oracle or MS SQL Server Clustering, etc.) which are transparent to BusinessObjects
    50. 50. The FRS can be configured for failover/HA by using a SAN, which is transparent to BusinessObjects
    51. 51. Consider clustering your Web and Application Servers
    52. 52. For example – Managed Servers in WebLogic</li></li></ul><li>Clustering – Best Practices<br />• All machines should be alike:<br />• Same number and type of processors<br />• Same amount of hard drive and RAM<br />• Same OS and software<br />• Same middleware (ODBC, etc.) connections<br />• This keeps the load balancing working properly<br />The CMS doesn’t have the ability to assign tasks according to a machines size or capacity. All machines in the cluster are treated as equal. <br />• All machines should be in the same time zone<br />• This keeps the scheduled tasks and audit data in sync<br />• All servers should be on same subnet<br />• Communication between machines needs to be as fast as possible, and not hindered by other network traffic<br />• Begin with twice the capacity needed<br />• Add new servers when system usage reaches 70% of estimated capacity<br />• Use Auditor to monitor usage <br />• Oversize from the beginning<br /><ul><li> Make sure both CMS servers are configured for auditing in exactly the same way. Any difference will make the CMS crash. </li></ul>The last thing you want is for users to get error messages that resources are not available. That will cause users to lose confidence in the system.<br />
    53. 53. Clustering<br />Questions?<br />
    54. 54. Agenda<br /><ul><li>Overview
    55. 55. Horizontal BusinessObjects Enterprise Architecture
    56. 56. Clustering
    57. 57. Backup and Recovery
    58. 58. Monitoring and Alerting</li></li></ul><li>Backup<br />Enterprise Content vs. Server Backup<br /><ul><li> Server backup
    59. 59. Captures every byte on every local hard disk in a server
    60. 60. Has a low frequency
    61. 61. Enterprise content backup
    62. 62. Focuses on the essential components of BOE only
    63. 63. More frequent
    64. 64. Recommendation
    65. 65. Perform server backups after major system upgrades or initial installation
    66. 66. Focus on enterprise content backup as core to backup plan</li></li></ul><li>Backup<br />Incremental vs. Full Backup<br /><ul><li> Incremental backup
    67. 67. Captures only those files changed since last backup
    68. 68. Full backup
    69. 69. Captures every targeted byte
    70. 70. Recommendation
    71. 71. Perform full backups on a weekly basis
    72. 72. Perform incremental backups daily, at a minimum</li></ul>Cold vs. Hot Backup<br /><ul><li> Cold backup
    73. 73. Requires system downtime
    74. 74. Assures the most accurate snapshot of the system
    75. 75. Hot backup
    76. 76. Can occur while a system is live
    77. 77. Can occur at more frequent intervals
    78. 78. Higher risk of inconsistencies
    79. 79. Recommendation
    80. 80. Perform cold backups if a feasible window of downtime exists</li></li></ul><li>Recovery<br />Full vs. Partial Restore<br /><ul><li> Full Restore
    81. 81. Restore the whole system including the Operating System
    82. 82. Byte by Byte re-creation of the system from the time of backup
    83. 83. Can take a long time to restore
    84. 84. Partial Restore
    85. 85. Re-install BusinessObjects on a new server
    86. 86. Re-load your Enterprise Content from a BIAR file
    87. 87. Much faster, but can have issues (root level security in XIr2)</li></ul>In-place vs. Disaster Recovery<br /><ul><li> In-place Restore is recovery of your Prod system on the same hardware
    88. 88. DR is recovery of your Prod system in a remote location
    89. 89. Know how to do both!</li></li></ul><li>Backup and Recovery – Best Practices<br /><ul><li>Validate your backups are completing on schedule
    90. 90. Actually restore them once in a while
    91. 91. Practice, Practice, Practice!</li></li></ul><li>Backup and Recovery<br />Questions?<br />
    92. 92. Agenda<br /><ul><li>Overview
    93. 93. Horizontal BusinessObjects Enterprise Architecture
    94. 94. Clustering
    95. 95. Backup and Recovery
    96. 96. Monitoring and Alerting</li></li></ul><li>Monitoring and Alerting<br />You don’t know what you don’t know!<br /><ul><li> Critical points to watch
    97. 97. CMS
    98. 98. FRS (input and output)
    99. 99. Webi Crystal Deski, whichever you use
    100. 100. Web Server
    101. 101. App Server
    102. 102. Enterprise apps are the best, CA Wiley, IBM Tivoli, etc.
    103. 103. Monitoring Probes from BO Labs (SAP Innovation Center)</li></li></ul><li>Monitoring and Alerting – Best Practices<br /><ul><li> You never want your end users to be your monitoring system
    104. 104. Have alerts sent to your cell phone, pager or e-mail
    105. 105. Have alerts go to your 24X7 command center or </li></ul> help desk with an escalation plan <br />
    106. 106. Monitoring and Alerting<br />Questions?<br />
    107. 107. General Best Practices <br /><ul><li>Make sure you can access the SAP Support Portal quickly – No matter where you are
    108. 108. Designate a Substitute while you are on vacation
    109. 109. Watch your Auditor Reports – know when you are approaching boundaries
    110. 110. If you have other teams involved, educate them on:
    111. 111. What BOE is
    112. 112. What BOE does
    113. 113. How BOE works at a high level</li></li></ul><li>Where to Learn More<br />Windows Pattern Book<br />SAP<br />BusinessObjects Enterprise Server Administrator's Guide<br />SAP<br />BusinessObjects Enterprise XI - Clustering Servers<br />Michael Welter, Sr BI Consultant, Idhasoft<br />Best Practices for Backup and Disaster Recovery of Business Objects<br />Enterprise XI 3.1 <br />Mike Stamback, Director of Product Management, SAP<br />Disaster Recovery and Business Continuance <br />Kevin McManus, McManus Software + Consulting<br />
    114. 114. Questions and Contact<br />Greg Myers<br /><br />LinkedIn:<br /><br />Twitter:<br />@gpmyers<br /> @gpmyers/businessobjectsgurus<br /><br />Greg Myers BusinessObjects Admin Blog<br />Please consider joining ASUG and the BusinessObjects Security & Administration Special Interest Group <br />