DASD B
WORK
DATA CENTER
B
DATA CENTERS Note that while both data centers do updates, data
may be logically split. For example, the primary databases for customers living west of the Mississippi may be in “Data Center A” with secondary, read-only data at “Data Center B.” Customers residing elsewhere would be the reverse. Ultimately, this means the network must be smart enough to know where a customer’s primary data resides.
Consider This Here are a few things to keep in mind:
• BATCH—In update-update mode, batch becomes problematic. An enterprise has to decide which side runs batch, or if batch should be run in both sites. There may also be some concerns with the bandwidth needed to shove updates from I/O bound batch jobs through the replication links. • REPLICATION DELAYS—Modern communication links are fast and reliable, but can still fail. Even the fastest, most perfect communication line won’t be nearly as quick and synchronous as DASD I/O. Therefore, the system infrastructure—and to some extent the applications— must be prepared to deal with delays and “stale” data. • COLLISIONS—Database Management Systems (DBMS) in different Sysplex’s can’t lock database records across wide distances. This leads to situations where the same database record may be updated at the same time in different data centers. Again, the infrastructure and applications need to be prepared to handle the conflicts. • CHANGE CONTROL—Infrastructure, application, and database design changes must be carefully managed to avoid breaking replication compatibility between partner data centers.
• DRIFT—No asynchronous replication technique working at the logical I/O layer is perfect, and enterprises may find themselves with slowing diverging data stores. Fixing the differences will require some sort of periodic reconciliation process. • DEATH—When should a data center be declared dead? The data centers keep in touch through replication traffic and heartbeats, but a slowdown in replication traffic may just indicate one data center is doing less work. Likewise, a few missing heartbeats may signal a network failure or slowdown instead of data center failure. Detecting and acting upon perceived failures requires
carefully crafted policies, mountains of automation, and careful data center management. The good news is that as geographically split data centers become normal, the policy for handling these issues should become more easily transcribed as a set of rules instead of code.
ABOUT THE AUTHOR Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI, and DB2.
15
Optimize Your Data
Center Operations PC Connection offers a variety of services to help you optimize your operations.
Turn to p. 17 to learn more!
PHOTOS © FOTOLIA
WWW.PCCONNECTION.COM
VOLUME 3 • ISSUE 3
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36