Planning for Catastrophe: WebSphere Application Server Disaster Recovery Tom Alcott STSM IBM TAW-1791

Transcription

1 Planning for Catastrophe: WebSphere Application Server Disaster Recovery Tom Alcott STSM IBM TAW-1791

2 Please Note IBM s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. 2

3 This Session This session will focus on the architectural and operational issues that need to be considered when planning and implementing a Disaster Recovery plan with WebSphere Application Server. Topics will include use of multiple data centers, geographic separation constraints, supporting software components disaster recovery and other common deployment issues. Though focused primarily on WebSphere Application Server, this session also applies to Pure Application System, Portal, ESB and WPS. While not a prerequisite, attendees should be familiar with the material covered in " Preparing to Fail, Practical WebSphere Application Server High Availability 3

4 Introduction For want of a nail the shoe was lost; For want of a shoe the horse was lost; For want of a horse the battle was lost; For the failure of battle the kingdom was lost; All for the want of want of a horse-shoe nail. -Unknown 4

5 Introduction Why Are We Here? To Avoid This 5

6 Agenda Concepts Multiple Cells and Data Centers Disaster Recovery Other Software Final Thoughts 6

7 Definitions Redundancy the provision of additional or duplicate systems, equipment, etc., that function in case an operating part or system fails, as in a spacecraft. Isolated separated from other persons or things; alone; solitary Independent not dependent; not depending or contingent upon something else for existence, operation, etc. All of the Above are Fundamental for Effective High Availability and Disaster Recovery 7

8 Definitions High Availability (HA) Ensuring that the system can continue to process work within one location after routine single component failures Usually we assume a single failure Usually the goal is very brief disruptions for only some users for unplanned events Continuous Operations Ensuring that the system is never unavailable during planned activities E.g., if the application is upgraded to a new version, we do it in a way that avoids all downtime 8

9 Definitions Continuous Availability (CA) High Availability coupled with Continuous Operations No tolerance for planned downtime Little unplanned downtime as possible Very expensive Note that while achieving CA almost always requires an aggressive DR plan, they are not the same thing 9

10 Definitions Disaster Recovery (DR) Ensuring that the system can be reconstituted and/or activated at another location and can process work after an unexpected catastrophic failure at one location Often multiple single failures (which are normally handled by high availability techniques) is considered catastrophic There may or may not be significant downtime as part of a disaster recovery This environment may be substantially smaller than the entire production environment, as only a subset of production applications demand DR Normally based on justifiable business need. Recovery Time Objective (RTO) Service Recovery with little to no interruption Recovery Point Objective (RPO) Data Recovery and acceptable data loss 10

11 HA Gold Standard Dual Cells in One Data Center Cells are Isolated and Independent Assuring Effective Redundancy 11

12 Isolation, Independence, Redundancy In Context of the Gold Standard Isolation and independence of function is fundamental to HA. High Availability at it s core is about providing redundancy Effective redundancy requires isolation and independence of the redundant components This Means Two (or More) Cells/Domains/Data Centers Two (or More) Cells Hardware Isolation Software Isolation Available Even With Planned Maintenance Insurance Against Catastrophic Outage May Require More Administrative Effort The Gold Standard provides this for WAS-ND Additional Components Need to be Considered As Well 12

13 Definitions Service Levels (SLAs ) cover many things, our focus is availability aspects You need a clear set of requirements that define precisely the availability requirements of the system, taking into account Components of the system A system has many pieces and business aspects, how do their requirements differ? Responsiveness and throughput requirements 100% of requests aren't going to work perfectly 100% of the time Degraded services requirements Does everything have to meet the responsiveness requirements ALL the time? Dependent system requirements What are the implications if a system on which you depend is down? Data Loss Application Data Application State (Is this Critical in a Disaster?) Maintenance Change occurs, how does that affect availability? Disaster Recovery The unimaginable happens, then what? 13

14 HA Service Level Example (1 of 2) SLA External Commitment SLA Internal Target Service Timeframe 7 x 24 7 x 24 Application Processing Availability 99.5% per month 99.7% per month Recovery Time Objective 4 Hours 1 Hour Maintenance Window Tue-Thurs 3:00-6:00 am Tue-Thurs 3:00-6:00 am 99.5% = 3.60 Hours Downtime/Month 99.7% = 2.16 Hours Downtime/Month 14

15 HA Service Level Example (2 of 2) - System shall be available to process requests from midnight Sunday night / Monday morning until 8:00 pm Sunday evening. When system maintenance is not required system shall also be available from 8:00 pm Sunday night until midnight Sunday night/monday morning - System will be considered to be available unless 5 or more consecutive requests fail to complete or fail to complete within performance requirements - 98% of all work order inquiry requests will compete within 2 seconds, except for...<list of long running work centers, ones with large number of work orders>...which will complete within 5 seconds % of all work order updates will complete within 5 seconds, except for...<list of long running work centers, ones with large number of work orders>...which will complete within 10 seconds....list of other transaction types and response times - availability of individual terminals or workstations is exempt from this agreement Note: no mention of disasters no mention systems on which it depends 15

16 DR Service Level Example SLA External Commitment SLA Internal Target Recovery Time Objective 16 Hours 4 Hours Recovery Point Objective ~ 0 (No Data Loss) ~ 0 (No Data Loss) 16

17 Agenda Concepts Multiple Cells and Data Centers Disaster Recovery Other Software Final Thoughts 17

18 Multiple Cells and Data Centers Why Do You Have Multiple Cells? To Eliminate the Cell as a SPOF Why Do You Have Multiple Data Centers? To eliminate the data center as a SPOF In Both Cases Increased Reliability and Insurance Against Disaster Disaster - a sudden calamitous event bringing great damage, loss, or destruction (Merriman-Webster Dictionary) 18

19 Multiple Cells and Data Centers A Disaster is Often the result of the Unthinkable or Unimaginable If Something is Unthinkable or Unimaginable You can t plan it or simulate it effectively o Fire o Flood o A Lightning Strike o Human error that destroys the cell. You CAN T prevent these types of problems. o Independent cells and data centers are the only solution. 19

20 What s Wrong With This Architecture? 20

21 How About this Architecture? Data Center 1 HTTP WAS WAS AppWAS App App Node Agent Deployment Manager IP Sprayer WAS WAS App WAS App App Node Agent HTTP Network Switch Clustered External JMS Applicaton, LDAP and Session Data Center 2 HTTP IP Sprayer WAS AppWAS App App Node Agent HTTP WAS WAS App WAS App App Node Agent Deployment Manager 21

22 Need a Hint? Isolation and Independence Are Lacking Dependencies Between Cells/Data Centers Exist Often The Result of Infrastructure Silos with Continuous Availability Expectation Fragmented Data Availability (DB) and Request Availability (App Server) Responsibility (aka Not my responsibility ) Issues/Problems Can Propagate From One Cell to The Other This Compromises Redundancy and Resiliency Worst Case a Outage Cascades Across Both Data Centers o This isn t Theoretical o A Single Malfunctioning Router Sending Out Random Packets Can (and Has) Disable(d) an Entire Network And Everything Attached to the Network!! 22

23 Multiple Cells and Data Centers WAS ND High Availability Design Criteria Recovery and redirection of work in the event of the loss of a single cluster member Consider a Network Failure Between the Data Centers Loss of ½ of a Cell is Several Orders of Magnitude Greater than the WAS ND High Availability Design Criteria 23

24 Network Outage with Single Cell & Two Data Centers What Happens? Core Group View Must Be Recreated o CPU and I/O Intensive, Which Will Halt/Stall Application Processing Web, EJB Web Service WLM Endpoints o Connection and Request Timeouts Needed to Mark Servers as Unavailable o Once Usable Cluster Members Discovered Processing Resumes Until Retry Interval Elapses ( Rinse and Repeat ) Deployment Manager o Loss Of Management Ability for Cell Members in 1 Data Center o A Bad Day is now a Very Bad Day! Persistent Service Recovery (Transactions and Messaging) o HA Core groups don't require quorum, so both halves can continue to run o If the Outage Lasts Longer than the File System Lease Lock Time? The data center with the logs will probably carry on as usual...and the other data center will do the same if it can access the logs! The two data centers could move to inconsistent transactional states!! Note: Clusters cannot span core groups, so a cluster with members in each data center will be in a single core group. 24

25 Multiple Cells and Data Centers Network Your Network Team Assures You That Can (or Have) Constructed a Network Link Between Data Centers I Agree, It Is possible to construct a network so that latency is NOT an issue Under Normal Conditions Even so, WANs are Less Reliable than LANs. o And Much Harder To Fix! But You re Missing The Point! Network Interdependency Between Data Centers Means That the Data Centers are Not Independent Question Do You Want to Have to Explain to Your CIO Why A Problem In One Data Center Impacted The Other and Resulted in a Outage Because You Didn t Have Cells Aligned to Data Center Boundaries? 25

26 Network Latency and Shared Application Data A 3 rd Party Perspective Since the latency or round trip time for a network is usually correlated to the length of the network, or the physical distance between the two end points (in this case the primary and standby), Maximum Protection and Maximum Availability modes are not recommended for Data Guard deployments over a Wide Area Network (WAN). Note that this recommendation is driven by the laws of physics (speed of light limitation) - the greater the distance of a network, the longer it will take for data packets to traverse the network, and hence the longer it will take for primary database transactions to commit. 26

27 What s Wrong With This Picture? A former employer of mine has two data centers at two facilities approximately 2.6 miles (or 4.2 KM) apart. 27

28 Need a Hint? What happens when? There s an earthquake There s a Civil Insurrection A Hazardous Chemical Spill Occurs o And The Wind Is Blowing the Chemical Cloud from West to East (or vice versa) Your DC May Not Be Located in a Locale Prone to Earthquakes But what about the other catastrophes??? They can, *and* will happen!! There s No Substitute For Isolation Between Data Centers And the Data Centers Should Be Sufficiently Distant So That a Single Event Doesn t Impact Both!! 28

29 The Better Gold Standard - Across Data Centers Application Data is Worth Preserving Between Data Centers, Is Application State? 29

30 Multiple Data Center Options (1/3) Classic Active/Active Two Data Centers Serving Requests for Same Applications Requires Shared Application Data o Application Data Consistency is prerequisite to any other planning o Simultaneous Reads/Writes = Geographic Synchronous Disk Replication Additional Hardware and Disk Capacity Required e.g. IBM High Availability Geographic Cluster (HAGEO), Sun Cluster Geographic Edition Expectation of Continuous Availability and Transparent Failover o Requires Sharing Application State Expectation Seldom Realized Outage of One Data Center, Stops Disk Writes in Both, No Longer Transparent Hardest and Costliest to Achieve Note: Disk Replication only employed for Application Data and Application State, WAS-ND cell configuration, software updates, and application maintenance should maintained independently in order to insure isolation (and availability) 30

31 Multiple Data Center Options 2/3 Active/Passive Two Data Centers, one Serving Requests the other Idling Easier Than Active/Active User and Application State Synchronization are Less Critical Asynchronous Replication Is Likely Sufficient Lower Cost for Network and Hardware Capacity From a Capacity perspective one data center is being underutilized. Typically Does Not Incur S/W License Charges When Idle If You Don t Pay for S/W Licenses Is Cost and Underutilization Still a Concern? WebSphere License Provides for o Hot Processing Requests License Required o Warm Started But Not Processing Requests, License Not Required o Cold Installed, But Not Started, License Not Required DB2 and MQ Require > 100 % of Hot Licenses for Replication 31

32 Multiple Data Center Options (3/3) Hybrid Active/Active (Partitioned by Applications) Two Data Centers, both Serving Requests, but Running Different Applications or New Application Tests o No Shared Application State, No Shared Application Data o If running same application in both sites In the event of a disaster, there will be a loss of service Users failover from one DC to the other Asynchronous Replication Sufficient o Be Aware of the implications of losing 50% of your system capacity should one data center go out of service. Provides Most of the Benefits of Classic Active/Active without the Cost and Complexity 32

33 Hybrid Active/Active 33

34 Loss of DC (or System) = Loss of Capacity If one entire data center fails ( a disaster") You want the remaining data center to be able to handle the workload Choose Your Deployment Carefully Plan Carefully For This Especially if Running Active/Active o If Both DC s Are Running at 60% o 60% + 60% = 120% of Capacity in Surviving DC! o WAS-ND V8.5 Intelligent Management Can Help Alleviate the Impact of Overloads With a DC Don t Forget Rule of 3 With 2 of Everything o o 34 An Outage (Planned or Unplanned) Reduces Capacity by 50% Is No Longer Fault Tolerant

35 Agenda Concepts Multiple Cells and Data Centers Disaster Recovery Other Software Final Thoughts 35

36 Disaster Recovery Develop a Disaster Recovery Plan Group Business Needs and Associated Applications into Tiers Group into tiers based on the hard/soft dollar impact on the organization Categorize by RPO and RTO. The top tier likely includes zero data loss and either no downtime or perhaps just a few minutes of down time Subsequent tiers have an RTO of 24 hours, then 48 to 72 hours, then perhaps 72 to 96 hour Essential Part of Any Plan Who approves DR move/recovery? Automated site failover is a bad idea o Typically triggering DR is very expensive o You do not want to trigger a DR by accident because of some transient issue just makes the situation worse 36

37 Disaster Recovery Objectives Recovery Time Objective How quickly the system will be able to accept traffic after the disaster Shorter times require progressively more expensive techniques o e.g., a tape backup and restore is relatively inexpensive o e.g., a fully redundant fully operational data center is very expensive One challenge is detection time It takes time to determine you are in a disaster state and trigger disaster procedures o While you are deciding if you are down, you are probably missing your SLA. o Does the RTO include detection time? 37

38 Disaster Recovery Objectives Recovery Point Objective How much data you are willing to lose when there is a disaster Limiting data loss raises costs o e.g., restoring from tape is relatively inexpensive but you'll lose everything since the last backup o e.g., asynchronous replication of data and system state requires significant network bandwidth to prevent falling far behind o e.g., synchronous replication to the backup data center guarantees no data loss but requires VERY fast and reliable network and will significantly harm performance Warning: results in increased latency which means capacity must be increased at all layers 38

39 Disaster Recovery Objectives Most RTO and RPO goals will deeply impact application and infrastructure architecture and can't be done after the fact e.g., if data is shared across data centers, your database and application design will have to be careful to avoid conflicting database updates and/or tolerate them e.g., application upgrades have to account for multiple versions of the application running at once which can affect user interface design, database layout, etc Extreme RTO and RPO goals tend to conflict e.g., using synchronous disk replication of data gives you a zero RPO but that means the second system can't be operational, which raises RTO Trying to Achieve a Zero RTO *and* a Zero RPO is Mutually Exclusive 39

40 DR Solution Ranges Implement the technology infrastructure necessary to provide recovery in the required times Be Aware of Practical Limitations o How Many Servers and Storage Can You *Actually* Recover Per Hour/Day/Week? Backup and Restore File Replication Shared File Systems Zero 40 Seconds Minutes Hours Days RPO time

41 Zero RPO and Zero RTO Achieving Zero RPO Between Data Centers Application Data Consistency is Primary Driver Zero RPO Requires Synchronous Application Data Replication o May or May Not Be Achievable, Depending on the network speed, bandwidth, reliability. o Most Software/DB Replication Mechanism Advise *Against* Attempting Synchronous Replication Achieving Zero RTO Between Data Centers Network Failover, in front of the data centers, is the Primary Driver o How quickly can failure be detected and requests redirected Components Inside Each Data Center (including WAS) o Processes are active in each site ready to service requests, This is best achieved by providing independent infrastructure in each site. A WAS-ND Cell Spanning Data Centers will interfere with Zero RTO o Refer to prior list of issues with a cell spanning data centers 41

42 How Do I Recover WebSphere Application Server? File System or OS Backup and Recovery Disk or Tape WAS backupconfig/restoreconfig Build from Scratch o Only a Realistic Option with Complete Set of Scripts and Rigorous Change Control Best Options File System/OS Backup & Recovery backupconfig/restoreconfig Both From Last Know Working Production Configuration Otherwise No Assurance Recovery Will Succeed o Same Concern with Build From Scratch May Need to Change Cell and Host Names Will the Original Data Center Be Restored, Or Is it Gone (for Good)? 42

43 Transaction Recovery Options Recovery on Separate (Physical) Server Non-Distributed Transactions (non-xa) Move/Mount the Transaction Logs to Physical Server Hosting Application Server with Access to Same Resources (e.g. JDBC, JMS) If Recovery Occurs in Different Cell use wsadmin to Configure the Same JAAS Alias for Accessing XA Resources o With adminconsole the node name gets prefixed to the alias. Distributed Transactions o Same as Above *PLUS* o WAS-ND server must have the same host name and host IP address, Distributed transactions that access multiple servers log information about each server involved in the transaction. Including the server name and the IP address of the machine on which the server is running. During recovery the server will try to contact the distributed servers and vice versa using the original name We Need Your Help! Vote for RFE to Relax the Requirement for Same Host Name and IP Address 43

44 Cross Data Center Transaction Recovery Active/Active Some Small Capacity Needs to be set Aside for Transaction Recovery (same Host/IP as Primary Data Center) Active/Passive Easiest if Sites Have Same Host/IP s Hybrid Active/Active Failover Applications Map to Machine with Same Host/IP as Primary 44

45 Transaction Recovery Options Welcome to the Doorstep of Hades 45

46 Cross Data Center - Message Engine Recovery MEUUID Attribute Used to Obtain Exclusive Lock on Persistent Message Store MEUUID Created During Message Engine Creation o No Mechanism for Modification Prior to V8.5 recovermeconfig AdminTask Command Retrieves MEUUID From Persistent Message Store and Updates Message Engine Configuration Allows Recovery of Stranded Messages After Catastrophic ME Loss recovermeconfig ME Configuration 4 Read Config on Startup 46 Application Server with Messaging Engine Persistent Message Store 5 Process Messages

47 Disaster Recovery Testing The DR hardware Should Be Put Into Actual Production Usage o Otherwise How Can You Be Sure It Will Work When You REALLY Need It. A Corollary of Murphy s Law The larger the numbers, the less likely all Tier 1 machines can be successfully restored to operations. Other Issues In a Real Disaster Will your key staff want to travel? Will they be able to travel? 47

48 Agenda Concepts Multiple data centers Disaster Recovery Other Software Final Thoughts 48

49 WebSphere Stack Products All Depend on WebSphere Application Server Infrastructure Same Issues to Consider as Previously Described 49

50 Portal Server Shared Data Suitable for Multiple Cells in a Single DC Dispatcher Site A Deployment Mgr Deployment Mgr Dispatcher Site A and Site B concurrently serve user requests. DR and continuous availability Dispatcher Dispatcher Dispatcher Dispatcher Caching proxy Caching proxy Caching proxy Caching proxy CBR CBR CBR CBR WebSphere Portal WebSphere Portal WebSphere Portal WebSphere Portal Portal Search Portal Search Portal Search Portal Search Content Apps Content Apps Content Apps Content Apps Site B Deployment Mgr Deployment Mgr Directory Server Database Server Directory Server Directory Server Database Server Directory Server Shared DB: Customization Data Community Data Database Server Database Server Unique DB(s): Release Data JCR Data Replicated Data Recommended for Cells in Separate DCs 50

51 WPS Recovery WPS Maintains State in database, queues, and transaction logs All State must be consistent for WPS to recover correctly. Employ Disk Volume Replication All WPS runtime, databases, MQ stores in the same replication consistency group, Likely the only viable option o Independent Disk Snapshots and DB Replication Can t Guarantee Consistency Recover to Cell o Has to have the same logical topology as the original cell o All the nodes as the original cell may not necessarily be active (Some of the nodes are not "on ) Some data loss likely with asynchronous replication, synchronous replication minimizes data loss 51

52 WebSphere extreme Scale Alternative to DB Replication for Application State Independent of WAS-ND Cell Infrastructure Servlet Filter Replacement for Session Manager Installs in Any J2EE Application Replication Zones Allows Alignment Along Data Center Boundaries Available in Appliance Form Factor WebSphere Datapower XC-10 52

53 Pure Application System V1.0 DR in PureApplication System consists of three basic steps Replicate the management data Deploy patterns on both systems (Export/Import) Manual Network Change Active (primary) Standby (backup) copy **Management Data Replicate the App Data and App State File System DB Replication External Shared FS *Application State Redirect network traffic from the primary to the backup Each tier has different data loss toleration which dictates different approaches that meet different levels of RPO 53 * Application State includes messages in queues, Database contents, Transaction logs, etc. ** Management data includes pattern definitions, User ids, cloud group definitions, etc.

54 Pure Application System V Simplified DR Automated virtual image backups Backup of virtual images is optional user decides if they want their images to be backed up or not. They are not backup by default. Backups are deltas First backup exports all images (in parallel) to the external backup location Subsequent backups only exports new images since the last backup Both images in the Default-Data, as well as third-party and customer created images will be backed up. Restore virtual image from backup Restore only shows images that are in the backup, and not already exist on the rack. Images are compared by their name, version, and image reference ID (build). Multiple images can be restored at the same time Restore virtual image backed up from another rack To retrieve images from another racks backup, the host, path, and credentials of the external backup host for the other rack is required Additional Improvements For More Information Attend Session TES-1164 Performance Certificate Handling 54 Progress Indicators Implementing Business Continuity with PureApplication Tuesday 5:15 pm or Thursday 1:00 pm Palazzo J

55 High Availability for Non-WAS Components Firewall IP Sprayer WebSphere MQ Security Registry Database Server SOA Appliance (DataPower) File System Make all HA! Via hardware clustering or software clustering 55

56 Agenda Concepts Multiple Cells and Data Centers Disaster Recovery Other Software Final Thoughts 56

57 Final Thoughts - Other Aspects to Consider HA Solutions Cost Of An Outage One minute of system downtime can cost an organization anywhere from $2,500 to $10,000 per minute. Using that metric, even 99.9 data availability can cost a company $5 million a year - The Standish Group To Implement a Solution Recovery Time Implement a Solution Appropriate to Your Business Requirements 57

58 Final Thoughts Operational Control Hardware is Incredibly Reliable Fault Tolerant Hardware and Software Allows Creation of Stable Highly Available Infrastructures Who Is the Weakest Link? Humans! Human Error can Cause Outages Human Error can Turn Small Problems into Disasters (oops, where is that backup tape?) 58

59 Final Thoughts Operational Control Automate Processes for Repeatability and Consistency Scripting Point and Click is Not Repeatable Discipline and Practice are Essential Well Defined Procedures for Every Contingency You Do Not Want to Learn During an Outage Practice Those Procedures o Won t Make Mistakes in Crisis o Validates that Procedures Actually Work o Practice Backup and Recovery, System Failures, Disaster Recovery, etc. Goal: Make Daily Operations Boring. This is Not a Job You Want to be Exciting The Crew of USAir 1549 Would Gladly Trade Boring for Exciting! 59

60 Final Thoughts - Learn from Your Mistakes Mistakes and failures will occur, learn from them What separates mediocre organizations from the good and great isn't so much perfection as it is the constant striving to get better to not repeat mistakes After every outage perform Root cause analysis o Capture diagnostic information o Meet as a team including all key players to discuss o Determine precisely what went wrong Wrong doesn't mean Bob made an error. Find the process flaw that led to the problem Determine a corrective action that will prevent this from happening again o If you can't, determine what diagnostic information is needed next time this happens and ensure it is collected Implement that corrective action o All too often this last step isn't done o Verify that action corrected problem A senior manager must own this process 60

61 Indispensable When Planning for Catastrophe 61

62 Questions? 62

63 We love your Feedback! Don t forget to submit your Impact session and speaker feedback! Your feedback is very important to us we use it to improve next year s conference Go to the Impact 2013 SmartSite ( Use the session ID number to locate the session Click the Take Survey link Submit your feedback 63

64 64

65 Legal Disclaimer IBM Corporation All Rights Reserved. The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. If the text contains performance statistics or references to benchmarks, insert the following language; otherwise delete: Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. If the text includes any customer examples, please confirm we have prior written approval from such customer and insert the following language; otherwise delete: All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full name and include appropriate trademark symbols (e.g., IBM Lotus Sametime Unyte ). Subsequent references can drop IBM but should include the proper branding (e.g., Lotus Sametime Gateway, or WebSphere Application Server). Please refer to for guidance on which trademarks require the or symbol. Do not use abbreviations for IBM product names in your presentation. All product names must be used as adjectives rather than nouns. Please list all of the trademarks that you use in your presentation as follows; delete any not included in your presentation. IBM, the IBM logo, Lotus, Lotus Notes, Notes, Domino, Quickr, Sametime, WebSphere, UC2, PartnerWorld and Lotusphere are trademarks of International Business Machines Corporation in the United States, other countries, or both. Unyte is a trademark of WebDialogs, Inc., in the United States, other countries, or both. If you reference Adobe in the text, please mark the first use and include the following; otherwise delete: Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. If you reference Java in the text, please mark the first use and include the following; otherwise delete: Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. If you reference Microsoft and/or Windows in the text, please mark the first use and include the following, as applicable; otherwise delete: Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. If you reference Intel and/or any of the following Intel products in the text, please mark the first use and include those that you use as follows; otherwise delete: Intel, Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. If you reference UNIX in the text, please mark the first use and include the following; otherwise delete: UNIX is a registered trademark of The Open Group in the United States and other countries. If you reference Linux in your presentation, please mark the first use and include the following; otherwise delete: Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. If the text/graphics include screenshots, no actual IBM employee names may be used (even your own), if your screenshots include fictitious company names (e.g., Renovations, Zeta Bank, Acme) please update and insert the following; otherwise delete: All references to [insert fictitious company name] refer to a fictitious company and are used for illustration purposes only. 65

66 Shameless Self Promotion IBM WebSphere Deployment and Advanced Configuration By Roland Barcia, Bill Hines, Tom Alcott and Keys Botzum ISBN:

67 Another Recommended Book IBM WebSphere v5.0 System Administration By Leigh Williamson, Lavena Chan,Roger Cundiff, Shawn Lauzon and Christopher C. Mitchell ISBN:

68 Licensing Servers as Back Up Servers From IBM Contracts and Practices Database The policy is to Charge for HOT, and not for WARM or COLD back ups. The following are definitions of what constitutes HOTWARM-COLD backups: All programs running in backup mode must be under the customer's control, even if running at another enterprise's location. COLD - a copy of the program may be stored for backup purpose machine as long as the program has not been started. There is no charge for this copy. WARM - a copy of the program may reside for backup purposes on a machine and is started, but is "idling", and is not doing any work of any kind. There is no charge for this copy. HOT - a copy of the program may reside for backup purposes on a machine, is started and is doing work. However, this program must be ordered. There is a charge for this copy. 68 "Doing Work", includes, for example, production, development, program maintenance, and testing. It also could include other activities such as mirroring of transactions, updating of files, synchronization of programs, data or other resources (e.g. active linking with another machine, program, data base or other resource, etc.) or any activity or configurability that would allow an active hot-switch or other synchronized switch-over between programs, data bases, or other resources to occur