Remote Journaling

0

REMOTE JOURNALING WHITE PAPER

SCHOOL OF COMPUTER SCIENCES UNIVERSITI SAINS MALAYSIA CST 233 Information Security and Assurance

ASSIGNMENT 2 REMOTE JOURNALING LECTURER : DR. AMAN JANTAN NAME : OH YING SAN MATRIC NO: 107626

1


Contents1.0 Abstract.2 2.0 Introduction.2 3.0 Why We Need Remote Journaling..5 3.1 Efficiency.5 3.2 Data...5 3.3 Cost.6 3.4 Time6 4.0 Type of Remote Journaling7 4.1 Remote Journals of TYPE1..7 4.2 Remote Journals of TYPE2..8 5.0 How the Remote Journaling Works10 5.1 Traditional Approach of Remote Journaling-Asynchronous.10 5.2 Remote Journaling Enhancement-Synchronous.12 5.3 Remote Journaling Configurations15 5.3.1 Broadcast Configurations...15 5.3.2 Cascade Configurations...16 6.0 Case Study.17 7.0 Conclusion.18 8.0 References.19

2


1.0 AbstractThe remote journal allows us to establish journals and journal receivers on the target system that are associated with specific journals and journal receivers on the source system. Once the journal function is activated, the source system continuously replicates journal entries to the target system. The benefits of the remote journal are lowers the CPU consumption on the source machine, eliminates the need to buffer journal entries to a temporary area before transmitting and allows the journal receiver save and restore operations to be moved to the target system. Hence, the utilization on the source machine can be reduced.

2.0 IntroductionRemote journaling is one of the off-site disaster data storage. Remote journaling is merely a replication on a target machine of everything that flows into a local production journal receiver on the source machine in real-time. It provides an efficient way to replicate journal entries from one system to another and is often part of a high availability or disaster recovery solution. As high availability and disaster recovery solution have become a high priority in recent years, remote journaling has become more heavily used and multiple enhancements have been made in recent releases.

3


Nowadays, the remote journaling more efficient and to provide information on the status of the remote journal environment and it often related to the communication environment. However, network bandwidth, delays and

retransmission are among the top concerns for the remote journaling. From a remote journaling point of view, data areas, data queues and integrated file system object journaling are no different from database journaling. To the remote journal facility, they are just additional strings of bytes representing journal entries that need to be transported efficiently, through better plumbing, to the target system. On the other hand, one of the options can be used to reduce remote journal traffic is using the remote journal filtering. Remote journal filtering allows for the journal receiver on the target system to not be a complete copy of the journal receiver on the source system at the same time reducing the network bandwidth for remote journaling. Journal entries can be filtered in several ways which is before image filtering, filtering by object, and filter by program or combinations of these can be specified as well. Filtering allows some number of journal entries to not be sent to the target system and not sending all journal entries decreases the amount of data on the communication line. However, concerns must be taken when defining remote journal filtering to ensure that critical data is not filtered.

4


This paper focuses on the issues of the motive or reasons of the remote journaling exists, type of remote journaling, how the remote journaling works, and real case study about the remote journaling.

Figure 1: The remote journaling workshop and the central workshop [7]

5


3.0 Why we need Remote Journaling?As we know that, disaster such as fire, flood or theft might occur anytime and anywhere so we need the remote journaling to secure and replicate the data to the target system. [1] Therefore, whatever the business type or size have to prepare a remote journaling to recover and copy the journal entries from one source system to another target system. According to the statistic 90% of businesses which suffer a data loss as a result of disaster are forced to close within two years this is because data is the lifeblood of business and the total loss of this data would almost certainly be fatal. The reasons of using the remote journaling are: 3.1 Efficiency Remote journaling automatically protects all of the mission-critical data and replicating it frequently on security offsite storage location and the data is transferred to the highly secure surroundings. Efficiently and high availability of replicates journal entries from the local system to the journals and journal receivers

3.2

Data A full backup of the customers server including all the important data, IT applications and operating system and email accounts is taken and stored on the target system. When the disaster occurs, the company does not

6


need to suffer of the data loss and they can have a full backup of the precious data and information. In addition, they can operate the business as usual in the shorter time.

3.3

Cost The cost of being unable to operate the business for a period of time is not worth than the total cost of having a remote journaling. As some of the company might think cost of the maintenance for the remote journaling is quite high and not worth for it but the cost of suffered of data loss and unable to operate the company are much higher than it. Then, it can ensure all business critical software is recovery to the target site and reducing the cost for software. At the same time, increases confident of clients and reputation of the computer as the ability to maintain and safeguarding customers data.

3.4

Time The length of time between the disaster and recovery data is shorter. As the remote journaling frequently replicate the information and the data of the company and immediately start the recovery process to ensure business continuity if disaster strikes.

7


4.0 Types of Remote JournalingThere are two remote journal types which are TYPE1 and TYPE2. Eventually, TYPE1 gives a greater flexibility to save and restore but limits the naming conventions while the TYPE2 gives a greater flexibility in naming conventions to remote journals and receivers but it can limit the save and restore strategy.

4.1 Remote journals of TYPE1

Figure 2: Naming convention for the Remote Journal TYPE1 [8]

8


From the Figure 2 shows that the journal name for the remote journal must be the same as the source journal. Then, the journal library name can be redirected to a single different library from that of the local journal. All remote journals of TYPE1 which are associated with the given local journal must reside in the same named library. Besides that, the receiver library name can be redirected to a single different library from that of the local journal. All receivers attached to remote journals of TYPE1 which are associated with the given local journal must reside in the same named library. Receivers associated with the local journal or any of the TYPE1 remote journals can be saved and restored to the local system or to any of the systems where the TYPE1 remote journals reside and be linked into the correct receiver chain of the journal.

4.2 Remote journals of TYPE2

Figure 3: Naming convention for the Remote Journal TYPE2 [8]

9


The Figure 3 illustrates the naming convention for the remote journal TYPE2. The journal name can be different from the source journal. There are no restrictions for journal library redirection and there are no restrictions for journal receiver library redirection. Receivers associated with a given TYPE2 remote journal can be saved and restored to the local system or to the same system where the TYPE2 remote journal resides and be linked into the correct receiver chain of the journal.

10


5.0 How the Remote Journaling WorksThe way of traditional approach of remote journaling and remote journaling enhancements work will be discuss below.

5.1 Traditional Approach of Remote Journaling-Asynchronous

Figure 4: The traditional remote journaling solution [8] The figure4 shows the traditional approach of the remote journaling. In a traditional environment, a users applications that run on a source (production)

11


system generate database changes. Then, these changes create journal entries written to a local journal receiver. On the source side, the entries are received from the journal and buffered in a communications staging area and the data is transmitted asynchronously to the target system using existing communications gear. On the other side, a high availability application running in the target system receives the journal entries into a temporary storage location, usually a user space. After that, many jobs replays the changes into a copy of the source database and at the same time an exact copy of the production database is copied to the target machine. However, this traditional approach has two major drawbacks which are: I. The asynchronous mode of operation means data latency. The source system may fail while there are some journal entries waiting for transmission to the target machine. Therefore, a few final database transactions are trapped on the source system. Then, the database replicate on the target system lags behind the production database on the source system. II. Secondly, the traditional approach increased CPU utilization. The data passes many layers of the system software and it crosses the Machine Interface boundary several times. Hence, it costs extra CPU cycles.

12


5.2 Remote Journaling EnhancementSynchronous

Figure 5: The remote journaling enhancement solution [8] The remote journaling enhancement provides a much more efficient transport of entries than the traditional approach. When a user application makes changes to a database file, there is no need to buffer the resulting journal entries to a staging area on the production (source) system unlike the traditional approach of remote journaling. Transmit the journal entries directly from the source system to associated journals and journal receivers on a target system.

13


More CPU cycles are available on the production machine for other important tasks. This is because the remote journal activated in synchronous mode, replicates journal entries to the backup machines main storage updating the productions system database and the data latency is driven to zero. Hence, the remote journaling enhancements solved the problems in the traditional approach by reducing the CPU cycles and the data latency. [3] Remote journaling enhancements have the filtering capabilities. Traditionally, a remote journal receiver has been a duplicate of the journal receiver associated with the local journal. However, the remote journal capable in filtering out journal entries that are not absolutely needed on the target system can decrease the amount of data sent across the communication line. The remote journaling filtering has three criteria which are before images, individual objects and program names. [2]

Figure 6: Verify remote journaling filtering rules (before images) [9]

14


Figure 6 shows the filtering before images journal entries no sent to the remote journal. On the target system, the before image journal entries may not be of any application, so implementing this filtering option should enhance the throughput between source and target system.

Figure 7: Verify remote journaling filtering rules (individual objects) [9] Figure 5 shows the remote journaling filtering criteria of individual objects can be implemented via CHGJRNOBJ or the INHRULES on STRJRNLIB commands. The remote journaling enhancement can fully take advantage of this more efficient transport mechanism. A high availability solution is still necessary in most customer environments to apply the application-dependent data to a replicate database.

15


5.3 Remote Journaling ConfigurationsThere are two basic remote journal configurations which are broadcast configuration and cascade configuration will be further discuss in the below.

5.3.1

Broadcast Configurations

In a broadcast configuration, one system replicates the local journal entries to one or many remote journal simultaneously. A broadcast configuration can run both in synchronous and asynchronous modes. The maximum broadcast configuration is limited to 255 remote systems so only one journal is activated in synchronous mode.

Remote journal

Local journal Remote journal

Remote journal

Figure 8: Broadcast Configuration [8]

16


5.3.2

Cascade Configurations

In the cascade configuration, one system replicates the journal entries to a remote journal on another system and that remote journal can replicate the journal entries to another remote journal and without limit. The local journal on the source machine can be attached to the remote journals on the first target machine either in synchronous or asynchronous mode.

Remote journal

Local journal Remote journal

Remote journal

Figure 9: Cascade Configuration [8]

17


6.0 Case StudyAs the IT Manager at Breazeale Sachse & Wilson LLP, a law firm in Baton Rouge, Louisiana with 160 users, I have to make sure email is up and running 24/7. Email touches every aspect of our business, and we cant afford any loss of information or downtimein a law firm, time is literally money, as we work by billable hours. In the past, we had issues with our email appliances delaying, which lead us to seek a system that didnt require a person to monitor a physical device. With a location in the Gulf Coast and office in New Orleans, our business is in an area prone to natural disasters and hurricanes. When Hurricane Katrina struck in 2005, we had to evacuate and severs had to be shut down, risking critical client information. We had to go into New Orleans under armed guard to regain access to documents and email that had not yet been captured by the tape backup system prior to Katrinas landfall. After this devastating experience, we began the disaster recovery plan to our company this is because if we ever face another natural disaster, our uptime wont be at the mercy of our physical location. Therefore, form this case study we realized that the importance of the remote journaling as it is essential for every company to send the data to target system.

18


7.0 ConclusionDisaster could happen at any time to users business and therefore it is important users to take actions to back up copies of data and documentation. The remote journaling is one of the options to provide security to users business to reduce suffering from financial loss during the period of disaster and even to avoid business failure. The remote journaling some sort like a stand-by system and alternative methods for the continued operation of users business as after the disaster occurred the all the critical data and information still in remote journal site. From my research of case study for the remote journaling, many company had suffered loss data due to the disaster occurred unexpectedly and they did not back up and replicate the data. For example, the tragedy of the World Trade Centre on September 11th 2001 something that no one would have predicted and certainly the total loss of the trading itself. Hence, the remote journaling is very important to every company this is because it can replicate, secure and back up all the data to the target system with the high availability and efficiency back up. Throughout this white paper, we can identify which type of remote journaling and understand how the remote journaling works to copy the original data from the production (source) system to the target system. In conclusion, remote journaling can reduce the need for decision making when disaster happens and guarantees the availability of stand-by systems which

19


provides us with a back up information and documents. The aim of this white paper is to help user aware of potential disasters and choose the suitable remote journaling to avoid the financial loss and business failure before it is too late.

20


8.0 References[1] Disaster Recovery http://www.bizhelp24.com/small-business/disaster-

recovery.html Date accessed: 8th Apr 2012 [2]IBM: Remote Journal Concepts http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Frzaki %2Frzakirconcepts.htm Date accessed: 8th Apr 2012 [3] Remote Journal Function http://issuu.com/tanguyjanssens/docs/remote_journal_function Date accessed: 8th Apr 2012 [4]Filtered Remote Journal http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frza ki%2Frzakirfiltrj.htm Date accessed: 8th Apr 2012 [5]Remote Journal Filtering http://ibmsystemsmag.blogs.com/i_can/2012/02/remote-journal-filteringreduces-network-traffic.html Date accessed: 9th Apr 2012 [6]Remote Journal Enhancement by Sandra Cabral http://www.mcpressonline.com/system-administration/high-availability-disasterrecovery/ibm-i-71-journal-and-remote-journal-enhancements.html Date accessed: 9th Apr 2012

21


[7] Figure 1:http://www.citejournal.org/vol6/iss4/science/article1.cfm Date accessed: 9th Apr 2012 [8] Figure 2, 3, 4, 5, 8 & 9 Remote Journal Function by Patrick Sheehy https://docs.google.com/viewer?a=v&q=cache:Wm21SVSi2l4J:www.redbooks.ib m.com/redbooks/pdfs/sg245189.pdf+Cascade+Configurations,Broadcast+Config uration&hl=en&gl=my&pid=bl&srcid=ADGEESgl7SEeU9iDeTBTxesH3gJz292ElfRV D3UDtZpkywM52TdLIbk3o2cQ29HcB4wkSWQdcCRkkp0RWkeqGNmTVuR4BdUmgebJljjlwrFE7DfoIkg JBWB7lmPjn_ScXyilQHarLqU&sig=AHIEtbQot-zdwMUEoi3Q8pvUeNcQeiSORw Date accessed: 9th Apr 2012 [9] Figure 6, 7 http://www.mcpressonline.com/system-administration/high-

availability-disaster-recovery/ibm-i-71-journal-and-remote-journalenhancements.html Date accessed: 9th Apr 2012

Documents

Remote Journaling