know more about Remote mirroring
Instant copies are excellently suited for the copying of data sets within disk subsystems.However, they can only be used to a limited degree for data protection. Although data copies generated using instant copy protect against application errors (accidental deletion of a file system) and logical errors (errors in the database program), they do not protectagainst the failure of a disk subsystem. Something as simple as a power failure can prevent access to production data and data copies for several hours. A fire in the disk subsystem would destroy original data and data copies. For data protection, therefore, the proximity of production data and data copies is fatal.Remote mirroring offers protection against such catastrophes. Modern disk subsystem scan now mirror their data, or part of their data, independently to a second disk subsystem,which is a long way away. The entire remote mirroring operation is handled by the two participating disk subsystems. Remote mirroring is invisible to application servers and does not consume their resources. However, remote mirroring requires resources in the two disk subsystems and in the I/O channel that connects the two disk subsystems together,which means that reductions in performance can sometimes make their way through to the application. application that is designed to achieve high availability using remote mirroring. The application server and the disk subsystem, plus the associated data, are installed in the primary data centre. The disk subsystem independently mirrorsthe application data onto the second disk subsystem that is installed 50 kilometres away in the back-up data centre by means of remote mirroring. Remote mirroring ensures that the application data in the back-up data centre is always kept up-to-date with the time
Instant copies are excellently suited for the copying of data sets within disk subsystems.However, they can only be used to a limited degree for data protection. Although data copies generated using instant copy protect against application errors (accidental deletion of a file system) and logical errors (errors in the database program), they do not protectagainst the failure of a disk subsystem. Something as simple as a power failure can prevent access to production data and data copies for several hours. A fire in the disk subsystem would destroy original data and data copies. For data protection, therefore, the proximity of production data and data copies is fatal.Remote mirroring offers protection against such catastrophes. Modern disk subsystem scan now mirror their data, or part of their data, independently to a second disk subsystem,which is a long way away. The entire remote mirroring operation is handled by the two participating disk subsystems. Remote mirroring is invisible to application servers and does not consume their resources. However, remote mirroring requires resources in the two disk subsystems and in the I/O channel that connects the two disk subsystems together,which means that reductions in performance can sometimes make their way through to the application. application that is designed to achieve high availability using remote mirroring. The application server and the disk subsystem, plus the associated data, are installed in the primary data centre. The disk subsystem independently mirrorsthe application data onto the second disk subsystem that is installed 50 kilometres away in the back-up data centre by means of remote mirroring. Remote mirroring ensures that the application data in the back-up data centre is always kept up-to-date with the time
INTELLIGENT DISK SUBSYSTEMS
Intelligent disk subsystems represent the third level of complexity for controllers afterJBODs and RAID arrays. The controllers of intelligent disk subsystems offer additional functions over and above those offered by RAID. In the disk subsystems that are currently
available on the market these functions are usually instant copies remote mirroring and LUN masking Instant copies can practically copy data sets of several terabytes within a disk subsystem in a few seconds. Virtual copying means that disk subsystems fool the attached servers into believing that they are capable of copying such large data quantities in such a short space of time. The actual copying process takes significantly longer. However, the same server, or a second server, can access the practically copied data after a few seconds Instant copies are used, for example, for the generation of test data, for the back-up of data and for the generation of data copies for data mining. Based upon the case study in Section 1.3 it was shown that when copying data using instant copies, attention
should be paid to the consistency of the copied data. Sections 7.8.5 and 7.10.3 discuss in detail the interaction of applications and storage systems for the generation of consistent instant copies.There are numerous alternative implementations for instant copies. One thing that all implementations have in common is that the pretence of being able to copy data in a matter of seconds costs resources. All realizations of instant copies require controller computing time and cache and place a load on internal I/O channels and hard disks. The different implementations of instant copy force the performance down at different times.However, it is not possible to choose the most favourable implementation alternative depending upon the application used because real disk subsystems only ever realize one
implementation alternative of instant copy.Instant copies can practically copy several terabytes of data within a subsystem in a few seconds: server 1 works on the original data (1). The original dpractically copied in a few seconds (2). Then server 2 can work with the data copy, server 1 continues to operate with the original data (3)In the following, two implementation alternatives will be discussed that functi very different ways. At one extreme the data is permanently mirrored (RAID RAID 10). Upon the copy command both mirrors are separated: the separated can then be used independently of the original. After the separation of the mirro production data is no longer protected against the failure of a hard disk. Therefoincrease data protection, three mirrors are often kept prior to the separation of the m
(three-way mirror), so that the production data is always mirrored after the separatthe copy.At the other extreme, no data at all is copied prior to the copy command, only the instant copy has been requested. To achieve this, the controller administers two areas, one for the original data and one for the data copy generated by means of icopy. The controller must ensure that during write and read access operations to ordata or data copies the blocks in question are written to or read from the data arquestion. In some implementations it is permissible to write to the copy, in some not. Some implementations copy just the blocks that have actually changed (partial copy)
Intelligent disk subsystems represent the third level of complexity for controllers afterJBODs and RAID arrays. The controllers of intelligent disk subsystems offer additional functions over and above those offered by RAID. In the disk subsystems that are currently
available on the market these functions are usually instant copies remote mirroring and LUN masking Instant copies can practically copy data sets of several terabytes within a disk subsystem in a few seconds. Virtual copying means that disk subsystems fool the attached servers into believing that they are capable of copying such large data quantities in such a short space of time. The actual copying process takes significantly longer. However, the same server, or a second server, can access the practically copied data after a few seconds Instant copies are used, for example, for the generation of test data, for the back-up of data and for the generation of data copies for data mining. Based upon the case study in Section 1.3 it was shown that when copying data using instant copies, attention
should be paid to the consistency of the copied data. Sections 7.8.5 and 7.10.3 discuss in detail the interaction of applications and storage systems for the generation of consistent instant copies.There are numerous alternative implementations for instant copies. One thing that all implementations have in common is that the pretence of being able to copy data in a matter of seconds costs resources. All realizations of instant copies require controller computing time and cache and place a load on internal I/O channels and hard disks. The different implementations of instant copy force the performance down at different times.However, it is not possible to choose the most favourable implementation alternative depending upon the application used because real disk subsystems only ever realize one
implementation alternative of instant copy.Instant copies can practically copy several terabytes of data within a subsystem in a few seconds: server 1 works on the original data (1). The original dpractically copied in a few seconds (2). Then server 2 can work with the data copy, server 1 continues to operate with the original data (3)In the following, two implementation alternatives will be discussed that functi very different ways. At one extreme the data is permanently mirrored (RAID RAID 10). Upon the copy command both mirrors are separated: the separated can then be used independently of the original. After the separation of the mirro production data is no longer protected against the failure of a hard disk. Therefoincrease data protection, three mirrors are often kept prior to the separation of the m
(three-way mirror), so that the production data is always mirrored after the separatthe copy.At the other extreme, no data at all is copied prior to the copy command, only the instant copy has been requested. To achieve this, the controller administers two areas, one for the original data and one for the data copy generated by means of icopy. The controller must ensure that during write and read access operations to ordata or data copies the blocks in question are written to or read from the data arquestion. In some implementations it is permissible to write to the copy, in some not. Some implementations copy just the blocks that have actually changed (partial copy)
others copy all blocks as a background process until a complete copy of the original data has been generated (full copy).
In the following, the case differentiations of the controller will be investigated in more detail based upon the example from Figure 2.18. We will first consider access by server 1 to the original data. Read operations are completely unproblematic; they are always served
from the area of the original data. Handling write operations is trickier. If a block is changed for the first time since the generation of the instant copy, the controller must first copy the old block to the data copy area so that server 2 can continue to access the old
data set. Only then may it write the changed block to the original data area. If a block that has already been changed in this manner has to be written again, it must be written to the original data area. The controller may not even back up the previous version of the
block to the data copy area because otherwise the correct version of the block would be overwritten.The case differentiations for access by server 2 to the data copy generated by means of instant copy are somewhat simpler. In this case, write operations are unproblematic:the controller always writes all blocks to the data copy area. On the other hand, for readoperations it has to establish whether the block in question has already been copied or not. This determines whether it has to read the block from the original data area or readit from the data copy area and forward it to the server.
In the following, the case differentiations of the controller will be investigated in more detail based upon the example from Figure 2.18. We will first consider access by server 1 to the original data. Read operations are completely unproblematic; they are always served
from the area of the original data. Handling write operations is trickier. If a block is changed for the first time since the generation of the instant copy, the controller must first copy the old block to the data copy area so that server 2 can continue to access the old
data set. Only then may it write the changed block to the original data area. If a block that has already been changed in this manner has to be written again, it must be written to the original data area. The controller may not even back up the previous version of the
block to the data copy area because otherwise the correct version of the block would be overwritten.The case differentiations for access by server 2 to the data copy generated by means of instant copy are somewhat simpler. In this case, write operations are unproblematic:the controller always writes all blocks to the data copy area. On the other hand, for readoperations it has to establish whether the block in question has already been copied or not. This determines whether it has to read the block from the original data area or readit from the data copy area and forward it to the server.
No comments:
Post a Comment