if you lost your data and don’t have a plan, its too late to for … you lost your data and...
TRANSCRIPT
If you lost your data and don’t have a plan, its too late to for DR!
When Disaster strikes, will you have HA protection?
• Little about me
• Definitions
• History
• IBM I
• Disaster Recovery
• High Availability
• Disaster Recovery products
• How they Work
• Comparison
• Summary
• High Availability products
• How they Work
• Comparison
• Summary
• Things to consider
• Q & A
• My name is Robert Seal
• My first job in IT was Programmer on a 4341
• Worked on System 34 and loved the screen design aid
• Managed several IT departments
• Designed and created applications from Spare Parts inventory to Model Option Order entry/order processing
• Designed and created what became iTera HA
• Responsible for remote journaling being used by iTera
• Left to start my own company, iSam Blue, llc
• Channel Managers for a French HA company
• Created iSB-HA
• Know and used most HA products and many DR products
• Disaster Recovery products
• Performs a point in time save of your data
• Most perform snapshots
• Data can be stored many different types of media, including the cloud
• No Real time data replication
• Disaster Recovery Plus
• Some are really DR products
• Some are really HA products
• Vendors make a lot of claims
• High Availability products
• Provide real time data replication,
• keeping a target server in-sync with the Production server.
• In the event of a failure of your Production server you can route you users to the Target sever
• No Point in time / snapshot saves
8
•
Mostly un-structured, machine-generated
Mostly structured, human-generated
Archive Storage
Content or
Records
Management
Litigation
Support &
eDiscovery
Database
Archiving
Regulatory Archive
“Have to keep”
Digital
Media
Other
8
Regulatory Requirements - Unpredictable need for fast access
- Lifecycle management
Asset Requirements - Openness for flexible access
- Valuation management
- Longevity
Seismic
Telemetry
Asset Archive
“Want to keep”
Technical
Computing
Reference
Data
Experiments
Business
Analytics
Medical
Imaging
Surveillance
Digital
Preservation
Media
Production
Media
Distribution
System 3 • 1969-1985 • Single User • Single-platter Disk roughly the size of a large
pizza; initially each platter held 2.5 MB • Max 2.5 to 10 MG data storage Disaster Recover • 96 column punched card • each fixed disc could have a removable
cartridge disk attached High Availability was just a wild dream
System 32 • 1975-1977 • Single user • 5 , 9 , or 13 MB Disk Storage • Did not replace System 3 Disaster Recover • Introduced the an eight-inch Floppy High Availability lots of talk, but no action
System 34 • 1977-1984 • Multi-user, Multi-tasking • included System 3 and System 32 Processors • 8.6 – 326 MB of storage Disaster Recover leaped forward • "magazines" - boxes of 8-inch floppies • Tape Drive High Availability • First Applications created • Driven by
System 36 • 1983 to 2000 • 30 to 1.4 GB System 36 and System 34 were both being sold Disaster Recovery • Quarter-inch cartridge Tape drive High Availability was not available
• 1979 – System 38
• Disaster Recovery
• Save to Disk then to tape became popular
• Autoloader Tape drives became available
• High Availability leaped forward
• Journaling was added to the OS
• Journal entries were read on production system , sent to target, and applied.
• OMS/ODS, Mimix, and DataMirror started either on 34 or 38
• 1988 – Application System/400 or AS/400 replaces system 34 and 36
• Disaster Recovery also moved forward
• More Tape save options
• High Availability
• Additional object journaled
• 1994 - System/400
• Disaster Recovery
• More Tape save options
• High Availability
• First attempt at Remote Journaling – Failed
• Traders HA
• 2000 - eServer iSeries.
• Disaster Recovery
• People started to talk about Disk to disk options (Remote)
• High Availability
• Remote Journaling was moved to the Machine level
• All HA Vendors except Traders moved or added remote journaling
• IFS was journaled
• iTera –HA, Maxava, and Power HA
Remote Journaling was the biggest change to HA since Journaling.
Remote Journaling offered • Fastest communications • Improved data integrity • Lower Production CPU usage • OS handled communications • Easier for users
iTera-HA Changed HA • Easier for customer • No Journaling experience • Easier Startup • More Automation
• 2006, IBM System i.
• Disaster Recovery also moved forward • Transfer Saved data to offsite storage
• High Availability • IBM improved journaling, fewer errors • Apply Journal entry command improved • Bug Busters • Vision, iTera, and Mimix were all purchased by a private equity firm • IBM Purchased Data Mirror • IBM began pushing Power HA
• 2008 – power systems
• Disaster Recovery also moved forward • Transfer Saved data to offsite storage now called Cloud DR • Disaster Recovery Plus is born
• Using Journal receivers
• Saving ever few hours
• High Availability • IBM improved journaling, fewer errors • Apply Journal entry command improved • Sheilds • iSB-HA • Rocket buys DataMirror
New Products • Simplified Installation • One step commination setup • One step “Link” setup • Trainable Notification system
IBM Continue to improve Power HA • End to end integration • Improved small to large IBM i • Improved Switch
Where is HA going • Continued to improve automation • Journaling Improvements • More Cloud options • Improvement to security
• Tape
• Applications – Running on production server
• Devices – Emulating Tape Devices
• Home Grown
Dedicated System Save
• Quite your system
• Perform the save to tape
Non-Dedicated System Save
• Save using Save While active
• Watch out for add member issues
Emulates Tape
• Device issues Save Command
• IBM i writes to tape drive that is really the appliance
• After Save, tape image is sent to cloud
Application running on IBM i
• Makes a list of objects to save
• Save the object to file
• Some Send Delta changes others the complete save file to the appliance
• Appliance send to cloud
IBM has made this a lot better option by developing the Virtual Tape.
• Perform standard save command to virtual tape
• FTP Tape image to cloud
You can also use save to save file
Appliance Options Tape
Option Application Tape
Emulation Home Made
Replication Method
Blocks of Data No Yes No No Tape Image Yes No Yes Yes Save Check Point All Obj By object All Obj Option Object size reduction
Compression Yes Yes Yes Yes Delta Processing No Yes No No De-Dup ? No Option Yes Other items Runs Application on Prod.
No Yes No Yes
Use standard IBM Save Cmd
Yes No Yes Yes
SAVSYS Yes No Yes Option Use current save process
Yes No Yes Option
How is data stored
As a tape image Yes No Yes Yes Stored in blocks with index file(s)
No Yes No No
Summary
Tape
• option lower cost
Cloud Application
• Space saving
Cloud Tape Emulation
• Save System and Checkpoints
Home Grow
• You love what you make
Vendors
Tape
• Hardware vendors
Cloud Application
• Evault
• LaserVault
Cloud Tape Emulation
• IBM
• Tributary
Some products called High Availability are Disaster Recovery
• Nightly backup, change receivers, and save receivers every few hours
• Vendors call it High Availability
• They do not keep the backup in-sync real time
Some products called Disaster Recovery are High Availability
• Apply on target in near real time with manual failover
• Vendors call it Disaster Recovery
• They do not perform Snapshot or point in time save.
They do have a place, my only concern is that you classify them correctly.
Need simple solution
• Tape Backup
Have the time and resources
• Build your own
Checkpoints and SAVSYS
• Emulate Tape solutions
Cloud Backups
• Applications running on IBM i
Shorter RPO
• Disaster Plus
The one you
choose!
• Hardware Replication
• Logical or Software based Replication (apply journal entries)
• Harvest on Production
• Use Remote Journaling and Harvest on Target
Let’s see how each method works
• Requires SAN
• SAN storage is defined in blocks
• IBM i sees SAN as IASP
• IBM i sends update to SAN
• SAN sends changed blocks to target SAN
Main Site
DS5000
IASP Prod
Prod
Global Mirroring
DS5000
HA/DR
IASP Prod
HA/DR Site
PowerHA for i (automation & management)
• Some System Objects
must reside on system
ASP
• System ASP is replicated
by Logical Replication
Receiver 1
Your
Program
Table
Receiver 3
Receiver 1
Image of New Row
Type PT
New Row
Application Program
Change Data New Row
Receiver 2
Receiver 1
Receiver 1
Receiver 2
Image of New Row
Type PT New Row
New Row
Journal
1
2 3
Receiver 1
Table
Image of New Row
Type PT
New Row
Application Program
Change Data New Row
Image of New Row
Type PT New Row
New Row
Image of New Row
Type PT
Receiver 1
Image of New Row
Type PT
Image of New Row
Type PT Image of New Row
Type PT
1
2
3 2
3
• Sync
• A sync
Receiver 1
Your
Program
Table
Image of New Row
Type PT
New Row
Application Program
Change Data New Row
Image of New Row
Type PT New Row
New Row
Image of New Row
Type PT
Receiver 1
Image of New Row
Type PT
Image of New Row
Type PT Image of New Row
Type PT
Table
Receive/Apply Process
Image of New Row
Type PT
Image of New Row
Type PT
Image of New Row
Type PT
• Application Handles Apply
• System Handles Apply
Receiver 1
Your
Program
Table
Image of New Row
Type PT
New Row
Application Program
Change Data New Row
Image of New Row
Type PT New Row
New Row
Table
Receive/ Send Process
Receive/ Apply Process
Image of New Row
Type PT
Image of New Row
Type PT
Change Data Change Data
Change Data Image of New
Row Type PT
Hardware Logical Hardware Logical
Replication Method Special Requirements Blocks of Data Yes No SAN Yes Optional
Journaling / Save object Limited Yes IASP Yes Optional
Save and hold No PD Ability to use target
No Yes
Select / Omit No Yes Re-Sync restart Yes Optional
Objects Replicated All PD Audits No Yes
One step setup No PD Switch
Backups Configurable No PD
Automatic Snapshot Process Yes No Flexible No PD
Backup From Target Yes Yes How many steps ? PD
Communications Test Switch Opt. ? PD
Automatic Setup No PD Monitoring Remote Journaling Optional PD Required PD
Replication HA Independent Yes PD Trainable Notification system
PD
Bandwidth requirements High RJ – low NRJ Lower
Summary Hardware • Replicate Everything • Lot of bandwidth • Like idea of Block Replication • Willing to buy SAN • Using IASP is not a problem Logical • Ability to choose what to
replicate • Lower Bandwidth Requirements • More Testing Options • Use the backup for reports… Logical W/O Remote Journaling • Bandwidth constraints
Vendors Hardware
• IBM
• EMC
Logical W/O Remote Journaling
• Vision
• Traders (only option)
• Bug Buster
• iSB-HA
Logical using Remote Journaling
• Maxava
• Shields
• Vision
• Bug Buster
• iSB-HA
IASP not a problem, lots of bandwidth
• Hardware Replication
Want more control of what you replicate
• Logical Replication
Simplest communications
• Logical Replication
• Hardware replication
Bandwidth and issue
• Logical without Remote Journaling
The one you choose
• Recovery Point Objective – RPO
• Recovery Time Objective – RTC
• Service Level Agreement - SLA
• Total Cost of ownership – TCO
• Operating Cost
What are your customers Expectations?
• Auto industry charges 1 million an hour if line stops because of lack of parts
• SLA with Big Box Stores
Does your customer have a choice of vendors?
• Will they walk?
Do you have a paper Trail?
• Web
• Reduced paper to increase efficiency
• How are you going to find out what needs to be entered?
Are you Regulated?
Types of outages to be addressed • Unplanned (for example, a hardware failure)
• Planned (for example, a software upgrade)
• Backups (for example, create copy of disk for on-line save to tape)
• Disasters (for example, site loss, power grid outage, etc).
Communications • Bandwidth requirements
• Reliability
• Pointing users to Target system
Robert Seal can be contacted: 801.368.9400 [email protected] This presentation is copyrighted by iSam Blue, llc 1188 w 2000 n, Mapleton, UT 84664 Isamblue.buz