Page 1

Yo u r P u r e, A I X, a n d I B M i Au t h o r i t y

Au g u s t 2 0 1 2 / V o l . 1 / NO. 4

A P e n to n P u b l i c at i o n

Business Continuity from the


Disaster Recovery Q&A with Richard Dolewski Quick and Easy DB2 HADR Setup for AIX Managing the IBM Flex System Manager Appliance An Introduction to Linux Security

Plus >>

Cover Story ▼

AU g u s t 2012 / Vo l. 1 / n o. 4

Exploiting the Cloud for Business Continuity ­— Mel Beckman Business continuity is more than just the ability to restart a business after a disaster; it also ensures that your applications continue operating through natural and man-made catastrophes. The cloud, of course, brings new options to AIX, IBM i, and Linux IBM Power users.


Features 39 Make Remote File Replication Part of Your AIX Disaster Recovery Plan

David Tansley


AIX System Recovery Tips and Techniques

In Every Issue 5 Power Community 15 23

David Tansley


Quick and Easy DB2 HADR Setup


Managing the IBM Flex System Manager Appliance

David Tansley

Secrets of an AIX Administrator, Part 2

Christian Pruett

Power at Work 75 The Network Port Requirements for IBM Systems Director

Erwin Earley


An Introduction to Linux Security


AIX 60-Second Snapshot Commands

Erwin Earley

Industry Issues: Disaster Recovery Q&A with Richard Dolewski Chris Maxcer


Greg Hintermeister


Hot New Products

Global Power Action: Security of the Damned Seamus Quinn


Hot or Not: Cloud Simulations Sean Chandler


Advertising Index

Chat with Us

Anthony English

Access articles online at


Cover Story

Cover Story

Cloud Exploiting the

for Business Continuity

D Cloud resources lower BC costs while delivering geographic diversity By Mel Beckman w I T EP RroI. Tc oPmR O / A u g u s T 2 0 1 2 1w w . P O WPEOR W

isasters happen, happen, and prepared prepared businesses survive survive them. them. But businesses simple survival survival is is no longer simple enough in in today’s today’shighly highlycompetitive competienough tive business climate. With traditional business climate. In traditional disasdisaster recovery thinking, ter recovery (DR) (DR) thinking, after a disaster occurs, occurs, athe business relocates disaster business relocates to to another location adequate another location with with adequate comcompute resources, restores its applipute resources, restores its applications cations from and and data and from data backup, andbackup, goes to work goes“recovery” to work in mode. “recovery” That in Thatmode. approach approach in processing the batch processworked in worked the batch era, but ing era, but doesn’t work so well it doesn’t workit so well with modern IT with modern IT of systems composed systems composed interwoven server of interwoven server Today’s and database and database complexes. IT data complexes. Today’s dataand centers centers weren’t built inITa day, they weren’t built inthat a day, andeither. they can’t can’t be rebuilt quickly, beTo rebuilt that quickly, either. accommodate contemporary IT To accommodate IT resilience needs, the contemporary industry devised resilience needs, industrycontinudevised the concept of the business the (BC). concept of business ity Systems designedcontinuity with BC (BC). BC are designs systems to be operarobust in mind robust in normal in normal operation, withtothe ability tion and have the ability switch to P O W E R I T P ro / AWuWgWu.sPtO2W 0 1E 2R I T P R O . 31 cOm

Cover Story

Mel Beckman is senior technical editor for POWER IT Pro. Email Website

backup compute and storage resources on short notice in response to disasters ranging from a server crash to a tsunami. BC aims to keep businesses functioning as close to normally as possible during a disaster, rather than running in post-disaster recovery mode. Initially, BC plans relied on either standby “hot sites” or parallel, full-time data centers to replicate core business processes such as email, voice communications, and essential applications. This form of BC essentially doubles IT expenses, making it available to only the most well-heeled enterprises. The advent of elastic, pay-as-you-go, cloud-based IT infrastructure dramatically lowered BC implementation costs, bringing new options to the table. Cloud computing offers several services that can both aid traditional DR processes and dramatically lower the cost of meaningful BC, giving you new options that you should evaluate today and begin integrating into your BC plan as soon as possible. To select appropriate BC measures, you first need to gain fluency in some BC terminology. You’ll then be able to review the available cloud resources and determine if cloud capabilities can transition your organization from DR to BC while potentially lowering total IT expenditures.

The Language of BC BC planning has a formal methodology behind it. Disaster mitigation experts have established two key metrics you must determine for your organization before you can implement effective BC processes: the recovery time objective (RTO) and recovery point objective (RPO). The RTO is the maximum elapsed time you consider acceptable between a disaster and recovery of critical business application functionality. This might vary among applications; for example, the RTO for order processing might be an interval of mere hours, whereas the RTO for payroll could be measured in days. The RPO defines the point in time to which you’ll restore a given application once you’ve restarted operations from your backup data sources. RPO effectively defines the maximum age of the data you 32

P O W E R I T P ro / A u g u s t 2 0 1 2

www . P O W E R I T P ro . c o m

Business Continuity in the Cloud can tolerate and still resume viable operations. If your offsite backups can be up to a week old, you’ve implicitly accepted an RPO of seven days. (Your BC plan will have to include some means for catching up any missing data, which might entail re-entering transactions from paper records or re-executing transactions from a database transaction log.) These two metrics already exist in your organization, even if you don’t know what they are. To move forward with cloud-based BC, you must know—or better yet, consciously define—these metrics in light of your operational requirements. The technology exists to meet RTO and RPO times of less than one second. Obviously, management would be delighted for you to report such a vaunted achievement— at least until you presented the bill. Realistically, though, few enterprises can approach, yet alone realize, zero RTO/RPO. That’s where cloud IT infrastructure comes in. Because you pay for cloud resources only when you use them, you can shift much of the recurring expense of a traditional hot-site BC approach to when you actually need the resources. You’ll still spend money planning and implementing cloud failover mechanisms, but you’ll mitigate the high price of ongoing readiness.

Head in the Clouds Perhaps the simplest use of cloud resources is as a safe, offsite data repository. Cloud storage is reliable and cheap: It’s typically less than $100/month per terabyte, and prices are steadily declining. To augment legacy tape backups (where tapes must be physically relocated to a secure site on a daily basis), implement disk-to-disk backup locally, then mirror the disk backup over the Internet to cloud storage. Mirroring only needs to copy the data that has changed, and it can be performed at regular intervals (e.g., daily) or continuously. You can usually specify a geographic region for your cloud repository that enhances disaster resilience; for example, an earthquake-prone West Coast company can choose an East Coast region for storage, w w w . P O W E R I T P ro . c o m

P O W E R I T P ro / A u g u s t 2 0 1 2


Cover Story whereas a hurricane-endangered East Coast business might prefer a land-locked central U.S. region. Offshore storage is available at slightly higher costs. The advantages of disk-to-disk backups are well-established and in use for tape already. Disk-to-disk backups are faster to perform, require no human intervention, and permit faster recovery in non-disaster situations, such as when an application must be reset to a previous state. The vast majority of incidents requiring backup data aren’t true disasters but are temporary urgencies, and disk-to-disk backup is both cost-effective and timely for that purpose. The disk-to-disk process lets you streamline tape handling, shifting it to normal daylight hours, and consolidate backups to reduce media requirements. But the cloud adds the advantage of geographically diverse storage that you can restore rapidly into a cloud-based server infrastructure (as described in the next section) without the need to physically transport tapes to a recovery site or worry about compatible reader devices. The cloud copy process can occur automatically (without incurring overtime labor), during late-night periods when Internet bandwidth is typically most available. Two aspects of cloud backup require some thought, however. First, given today’s Internet bandwidth costs, small- and medium-sized businesses typically have only a few megabits per second of available outgoing Internet throughput, even at night. Larger organizations might have 100Mbps, but they will have correspondingly higher data quantity needs. Both types of businesses face the same problem: Making an initial full backup of all mission-critical data to the cloud is likely impractical, because by the time the backup finished after several days, it would be too outdated to be useful. The second cloud backup aspect that requires careful thought is the process of recovering your data from the cloud. Recovery is the inverse of the backup requirement, only now you have the pressures of a disaster complicating your decision. You could reverse the procedure you used to upload data, bringing recovery media to your 34

P O W E R I T P ro / A u g u s t 2 0 1 2

www . P O W E R I T P ro . c o m

Business Continuity in the Cloud cloud provider to download the backup at high speed, which entails a modest service charge. Depending on the timeliness of your backup mirroring process, the RPO can be encouragingly short—as brief as a few minutes or hours. The time to execute the backup download, however, must be factored into your RTO. It’s difficult to envision this being less than a day. But there’s an alternative way to use your cloud-ensconced backups: resuming operation in the cloud itself.

Mighty Clouds One oft-unappreciated aspect of cloud IT infrastructure is that it relies heavily on virtualization (i.e., simulating computers and OSs on generic hardware running within a hardened data center). The inherent cost savings of virtualization is what makes cloud computing possible in the first place. Virtualization also presents a low-cost alternative to hot-site DR. Cloud infrastructure services go far beyond storage—they deliver utility compute and networking services a la carte as well. You pay for compute and network services only as you use them, because cloudprovider economies of scale let you ensure that those resources, in the form of virtual machines (VMs) and Internet transport, can be purchased on the spot. Moreover, it’s common for cloud providers to let you attach VMs dynamically to cloud storage, which means you can “spin up” a pre-configured cloud VM and connect it to your backup repository in seconds. You’ve now completely eliminated the backup download time requirement, letting you achieve an RPO commensurate with your RTO (minutes or hours, rather than days). The easiest way to partake of this cloud option is to employ virtualization yourself, running your application workloads in VMs compatible with the VM capabilities of your cloud provider. You simply include VM images, commonly called Virtual Disks (VDKs), in your cloud backup process, then reboot those images into a cloud VM instead of your local virtual infrastructure, effectively reconstituting your IT environment “in the sky.” w w w . P O W E R I T P ro . c o m

P O W E R I T P ro / A u g u s t 2 0 1 2


POWER IT Pro - Aug. 2012  
POWER IT Pro - Aug. 2012  

POWER IT Pro offers an array of resources, news, and perspectives on IBM Power systems and servers, including Pure, AIX, and IBM i.