TECHNICAL ADDENDUM 01

Transcription

1 TECHNICAL ADDENDUM 01

2 What Does An HA Environment Look Like? An HA environment will have a Source system that the database changes will be captured on and generate local journal entries. The journal entries will transfer via remote journaling to a Target system. On the Target system the replication software will read the remote journal data and apply the changes to the backup copy of the databases. The collecting of the data, transferring to the Target and applying into the backup database would be real time as the changes occur, which would provide a Target system with the same information as the Source so in an event that affected the Source system, the Target system could take over role of the Source system providing the HA environment. Replication Overview Types IBM s PowerHA is considered Hardware Replication while products like Maxava HA are known as Software (or logical) Replication. There are pros and cons with each approach. Hardware Replication is an option for businesses that have the infrastructure (SAN), bandwidth and implementation of iasp architecture, which is necessary for use of PowerHA. The IBM Lab Services group in Rochester teaches classes on how to use iasp with various applications. With Hardware Replication, the backup database is passive and is not available for use for other purposes such as query lookups or running reports. More importantly when it is being backed up changes are cached on the source system and during this period you do not have HA/DR. A total failure would mean lost data. The use of Metro Mirror assists in this area; however it is the more expensive option. Not only that, if someone was to update some of the data on the Target iasp whilst it was varied on being backed up, a full refresh would need to be performed to re-sync the data once more. This all requires extra time and effort. Logical Replication does not require iasps or SAN based storage (although they are supported by Maxava HA). The backup database can be used for non-update workload such as tape backups, queries and reporting without the need to halt the send of journal data from the source system. Logical Replication also has the ability to rollback any partial or corrupt transactions via journaling while Hardware Replication currently does not support this and any updates necessitate a full refresh. 02 Logical replication which allows Library Redirect also allows for multiple source systems to replicate to a single

3 large target system. This is useful where you have a system which cannot be LPARed for cost or other reasons. When considering the choice between Hardware and Software Replication, you should carefully assess your options in the context of how your production environment is setup, your technical minimum requirements, the project budget, ease of implementation and ongoing use and the technical skills and resources necessary and available to you. How Does HA Work? An Overview Of Remote Journaling On the Source system all database files that will be replicated will have local journaling attached to them. This local journal function will mean any activity performed on the database file will be recorded automatically by the IBM Operating System and recorded as journal data in the associated journal receiver attached to the local journal. With the journal data being recorded and stored in the journal receiver, the IBM remote journal feature can be associated to the local journal, which will allow a connection to be created to a Target system for the remote journal and when activated will transfer the same journal data being stored locally to be sent and stored on the Target system remotely. The remote journaling feature being native to the IBM i is all controlled by the IBM Operating System. The sending, receiving and validation of the remote journal data is all handled internally by the IBM i. Remote Journaling is part of the IBM i Operating System (ios) and is available at no extra cost on your IBM i. According to Larry Youngren (IBM i Developer of Remote Journaling), Remote Journaling is sometimes referred to as better plumbing for high availability environments. Part of that reputation stems from its ability to perform certain operations more efficiently than other approaches can. Data is written to local journals and then sent to duplicate remote journals on another LPARs or machines across any distance. It can be run in synchronous or asynchronous modes. In synchronous mode, the preferred choice, data is written to the backup database first and then it is written to the primary database. This option requires enough bandwidth to send in real time, otherwise jobs on the Source system have to wait for confirmation of the remote write before continuing. This method guarantees that data updates are written to the target journal before the Source and therefore there is little or no opportunity for entries to be lost if the Source system were to fail. In asynchronous mode, data is written to the primary database first and then sent to the target journal. Therefore, there is no wait restriction on locally running jobs. Most HA/DR sites operate in asynchronous mode. If all the activity is collected from the various journals on the Production Machine, the decision to be made is: 1. SORT the activity into the right sequence, and then SEND the activity to the Backup Machine or 2. SEND the activity to the Backup machine, then SORT the activity when it gets there IBM s introduction of remote journaling promotes the choice of SEND/SORT, as this gets the data sent quicker and takes the sort load off the Production Machine. The quicker it s sent, the less latency has been introduced. Data Activity is recorded in Data Journals by the IBM i OS. We have the option of reading the Local Data Journal or the Remote Data Journal, to discover the information we need to know about Data Activity. We need that information, so we can replicate it. So, a job must be running either on the Source to read the Local Journal, or on the backup, to read the Remote Journal. If we read the Local Journal, then we need our own mechanism to relay that information to the Backup. If we read the Remote Journal, the relaying is done for us by the OS at the microcode level. Maxava chose to read the Remote Data Journal, to take advantage of the auto-relaying by the OS, to ensure the information gets to the backup in real-time, rather than after-the-event, and to move any processing load off the Source system. Role Swap What Is It And How Does It Work Role Swap has two parts. There is the part that is controlled by the replication that processes the journal data and there is the part that is the environment. The replication component is based on the configurations, which perform the replication and these are *Primary types for the Source system and *Backup types for the Target system. 03

4 04 Implementing The Complete HA Solution If your organisation is looking to introduce data replication for DR and HA and you are considering a logical replication solution then you need to consider the following questions: Does the product use Remote Journaling? Does it use the Audit Journal and if so, what impact will that have on the production machine? Is processing carried out on the Source of Back-up machines Is it truly a real-time solution? Are you confident that the solution will replicate your transaction workload without latency? Does the product enable Before and After image testing to ensure data integrity? What monitoring tools are available and can the environment be remotely monitored via Smartphone or tablet mobile device? Is the role-swap an uncomplicated process? Is role-swap testing included in the implementation? Not only do the systems need to be catered for, but also the Environment that the systems are located in, the power supply, network access and the redundancy requirement for all these utilities must be considered. Having the systems available will not provide HA if they cannot be accessed and used when needed. Design Building Your Hardware Topology Your systems must cater for more work than what they will be used for to allow for growth and for events that could temporarily increase work load on the systems (monthend, year-end, failover, processing delay catch-up, etc.) The Source and Target systems should ideally be the same specs, which allows for either system to be the Production environment. Under specing the Target system would allow replication to run and basic jobs to run on the Target (such as Backups or Reporting), but in an event of Role Swap or Failover the Target system may not perform or run the required processing as needed for a Production environment, which may mean restrictions are needed when the Target becomes the Production system. Also a major consideration is storage and how this is made up. High Input/Output (I/O) application perform better when there are more disk arms to process the I/O requests. If you have more disk arms on one system and less on the other, this can affect how the processing performs on the systems. Replication Model Application, Common Libraries/Folders When setting up replication it would be best practice to replicate all databases, but there should be planning as to what is critical to the business as the priority. Identifying the critical databases can allow for the configuration setup to group these together (or individualise them) but allow them to be configured as priority for replication and allow adequate apply groups to be set to perform the replication in the quickest way possible. Less critical databases can then be grouped separately and managed in a way that does not affect the priority replication from occurring first. Also by grouping the databases in certain configurations, this will allow activity such as upgrades or backups to be performed without having to stop unrelated replication occurring while the event is taking place. Network Topology Latency The ability to maintain near real-time updating depends on getting the transactions from the Source system to the Backup environment. Hardware replication transfers data at the iasp level. Software (Logical) replication solutions typically use either their own proprietary transfer protocols or utilise the Remote Journaling functionality of the IBM i operating system. Implementation Maxava HA Example Detailed below is the defined configuration scope for the setup of replication for each production environment. If your configuration requirements exceed the parameters shown then additional fees may apply.

5 Replication of production environments for a one [1] Primary system / LPARs and one [1] Target system / LPARs. Libraries Limit Maxava Configs Database replication In Scope 50 5 Object Limit Maxava Configs Object replication In Scope 15,000 All Groups Limit Maxava Configs IFS/MQ/QDLS replication In Scope 3 3 System access connection VPN (remote installation) A typical project will be delivered remotely and will be supported by your technical staff as required. After installation Maxava gives an assurance that your HA software will perform as designed and configured by providing technical support for thirty (30) days. Configure Enhanced Features Following the base install the enhanced Maxava HA features will be configured. The enhanced features include: Autonomics and work scheduling System auditing and reporting Configure replication for User Profile/ ID s and passwords and spool files Configure Sweeper Setup a test instance with a standard and IFS role swap test configuration to verify a role swap can be carried out Maxava HA Administration Training The Maxava HA Administration training is a series of online sessions based on a training configuration setup in your environment. The training covers the following topics: Day to day operations and navigation using the GUI Managing journals & using Maxava tools Troubleshooting problems Setup and performing a role swap Autonomics overview 05

6 Failover, Planning and Support The failover service provides technical assistance with the planning and preparation to support the fail over testing of the production environment based on a system outage scenario. Review failover requirements, assist with defining failover plans Review replication environment, verify Maxava setup Configure Maxava HA to support role swap plans Run full audits to verify the integrity of the data Prepare technical support for failover tests performed maxview Setup and Support The maxview service provides technical assistance with the planning and setup of the maxview monitoring software. Review PC, system and smartphone requirements Advise on considerations for security Install maxview on nominated PC and servers Setup maxview on nominated PC and servers Provide basic training overview on use Critical Considerations for HA Configuration Grouping of databases Journaling Remote Journaling ASP / iasp considerations Naming Apply Group settings Role Swap / Failover Change Control A Change Control system/process is critical not only to track and plan activity for your Production environment but once you are replicating it is critical to track and plan activity that can affect either system. Changes need to be looked at as to what they can or will affect, how they will be implemented and what 06

7 safeguards are in place if the change needs to be removed and the original setting put back in place. Changes at a system level need to take into account how the Target system would be affected if it becomes the Production system. Verify Your Implementation Works Once replication has been set up, there needs to be checks in place to verify what has been done and to verify the integrity of the environments as an ongoing process. Auditing is the main recommendation to verify the environment but local integrity checks may also be used as well. Once you have setup your checking processes, the next stage is to plan and test your DR or HA strategy. This would involve Role Swap, Failover and Simulated Role Swap planning and testing as an ongoing process for your validation needs. Checklist For Success Ensure Data Integrity In order to check the data and object consistency of target databases, audit capabilities need to exist within your HA/DR solution. If users or processes accidentally manage to update the target system there needs to be a means of checking the data stored and correcting it. Maxava HA provides flexible auditing at multiple levels for customers to check their target databases: Existence audits check that an object is physically on the target system. Description audits check the object and its key attributes Content audits check the data contained within the object The Maxava HA audits can be run for a given configuration, library, object, generic list of named objects or by object type. Audits can be run in reporting only and full fix modes. Audit results are shown in easy to view logs via the Maxava HA GUI or TUI interfaces. Audit warningsand actions taken are clearly shown and where an audit was run in reporting only mode, there is the option to manually sync listed objects. In conjunction with the Maxava HA Autonomics process, partial database content audits can also be configured to run for large files where the information is checked and repaired at the block level. Maxava HA Technology Choice Maxava HA provides flexible auditing at multiple levels Benefits of using Maxava HA Autonomics include: Easy to run Existence, Description and Content options Able to run at configuration, library or object levels Can be run in reporting only or full fix mode Easy to view logs. Work in conjunction with Maxava HA Autonomics Role Swap For successful role-swaps, regular testing is the key. Can you switch your network to connect users and devices to the alternative system and will the Backup be ready is it in-sync with the Source? Going to your target system and doing some non-update work on it, - say a few stock enquiries -, will prove that the data you happen to view is valid. What it does not tell you is how your main applications and user access will work out when a full swap is performed. To check data consistency audits can be run to verify that all objects are the same, not just some of them, full or partial audits can be run at regular intervals. This again lets you know your data is correct, however does not test that all the required libraries, objects and user profiles exist to allow you to run your business successfully on the target. Only a role swap or failover test will do that. In order to run a full role swap test where data is going to be updated on the target system and sent back to the source system, a standard role swap or failover processes can be used. If your testing is going to run work which you do not want sent back to your source system, (e.g. a new billing run or a month end), then you need to take one of the following actions : 07

8 End replication and take a full backup of your target system before you start the test. When finished restore back to the save point and allow replication to continue once more. End replication and then run your test. When complete take a fresh save from your source system and refresh the target databases. Allow replication to continue from the new save point. If you use Maxava HA, Initiate the Maxava HA Simulated Role Swap (SRS) process and have your target system suspend, update and switch to primary mode. Run your tests. When complete end the Maxava HA SRS process. It will then roll back as many changes as possible. If there is anything that cannot be recovered in full, an audit or re-sync can be configured to request the required object from the source system. To assist customers in checking that they are Role Swap ready, Maxava HA customers have the ability to test using the Maxava HA Simulated Role Swap (SRS) procedure. SRS is a process, which allows the current Backup system to be used as a test Primary environment whilst the current production system remains in use. The Maxava HA Simulated Role Swap (SRS) will place the Backup environment into a test state and once complete will recover back to how the replication was before the testing occurred with minimal or no user intervention required. Maxava HA Simulated Role Swap (SRS) is not a replacement for Maxava HA Role Swap or Maxava HA Failover, but is a feature that allows certain testing to be performed on the Back-up system, that relates to what Role Swap and Failover need to use if they were invoked. It is important to note that switching the network is a physical exercise that cannot be fully proven virtually. A full monthly trial Role Swap is the recommended approach if you need to check user access, network interfaces, data consistency and application performance. If the goal of a role swap test is simply to investigate application function and performance on the target system, then instead of Role Swapping the machines, then Role Swapping them back again our recommended approach is to use the Maxava HA SRS (Simulated Role Swap). This allows you to continue using your source system whilst testing on the target. So no production system outage and when complete it will roll back the changes made in most instances without the need for major saves and restores. Automation Over time the same tasks will need to be performed day in and day out or as part of weekly, monthly or role swap related events. The best way to cater for these is to automate the processes to make the task easier or quicker to perform. If you have access to a programmer and have the required license on your systems these could be done via programs. However, not all sites have these resources available to them. To help provide automation replication products can provide tools to allow customers to set-up these tasks without needing all the resource overhead programming can occur. Tools such as Command Script Function (CSF) provided with the Maxava HA replication product can be used simply and easily by customers to setup command scripts to perform difficult or repetitive tasks for these needs. This tool does not require any additional licensing to the system and does not require any programming skills. This tool just uses standard IBM i or Maxava HA commands as you would do from a command line, with the feature of being able to group the commands together to run as they normally would on the system. Information such as communications link failures, exceeding disk utilization thresholds and replication issues are delivered to your mobile device or browser. With maxview Manager the interactive feature allows certain actions and requests to be sent back to the system, so you can answer messages, run jobs, start and stop configurations, run audits, even remotely role swap your systems if required. With the intuitive maxview interface, you will see a visual alert of system status and your Maxava HA environment, and be able to take action immediately. For any HA product, a primary requirement is to make sure that all jobs that should be running are running. Monitoring And Control Various HA/DR solutions offer different approaches to monitoring, control and remote access. Maxava HA has always had a GUI as the primary interface that allowed the monitoring and configuration of multiple systems. and configurations. The GUI utilizes IBM Client Access connections to communicate with all the required systems. 08

9 There is also a Green-screen alternative to the GUI, which allows the system it is running on to be monitored and administered. The Green-screen only requires 5250 access to be able to be run from a command line on the required system. The Green Screen interface is referred to as the TUI (Text User Interface). The GUI can show a composite view of all the Maxava HA environments for all machines (or LPARs) in a network. The TUI provides a view for one machine at a time. Maxava has also created maxview, with which you can access Maxava HA and key IBM i system resource information anywhere, anytime from a remote web device or Smartphone. Various maxview versions are provided with Maxava HA dependant on the particular version of Maxava HA selected. maxview and the GUI give an easy-to-read view of the current replication situation with alerts. The GUI also has a GUI traffic-light system (Red/Amber/Green) for highlighting any areas that may require attention. maxview makes real-time system information available remotely. Along with the system information, you can quickly view your Maxava HA environment, drill down to more detail and issue necessary commands if required. Most Maxava customers spend no more than 5 minutes per day, checking that everything is running normally and efficiently. Maxava HA issues alerts and other status information in such a way that it is extremely simple to integrate it into a Systems Management product. Managed Service Monitoring Packages are also available through the Maxava Services Department. the preferred method for whatever reason, the Maxava HA TUI allows you to perform most of the same functions available from the GUI, however just for that one system via the green screen interface. The maxview products allow system and HA monitoring to be accessible to not only the technical staff, but also management and operations. They allow you to be remote and still have control over your systems via your Smartphone. Best Practices In Implementing HA/DR The role of real-time HA/DR solutions is to maintain an identical copy of a production environment on a Backup system. The transactional activity that occurs on the Production environment must be recreated in real-time on the Backup system. The objective is to allow the customer to maintain two identical copies of their database, up to date to the second and often in locations many miles apart. It gives businesses the ability to switch or role-swap between the two database copies. Data can be replicated in various ways by a variety of products but at the fundamental level the options are Hardware Replication (Power HA) or Software Replication (often referred to as Logical Replication) such as Maxava HA. A primary responsibility of HA software should be to ensure all Object and Data Activity is relayed off the Source system with the absolute minimum of delay. HA/DR software must prepare for the possibility of the Source system failing without warning. Having activity which has occurred on the Source system but that has not yet been sent to the Back-up system will have the obvious repercussion of loss of data, an unacceptable result in today s time-critical business environments. Maxava Technology Choice Maxava HA provides multiple interfaces to allow monitoring and support of your systems no matter where you are. Benefits of using Maxava HA Interfaces include: Maxava has multiple interface choices. The Maxava HA GUI allows multiple systems to be configured, monitored and managed from a single interface. The Maxava GUI also has a traffic-light system (Red/ Amber/Green) for highlighting any areas that may require attention over and above the normal expected reporting options. If 5250 is the only communications option available or 09