IP Expo 2009 - How To Backup and Protect Your Data in a Virtual Environment

784 views

Published on

Are you still using traditional backup methods in your virtual environment? If so, you know these methods can create resource contention and capacity issues that eat up the cost-savings you were hoping to realize from your virtual infrastructure. Traditional backup is not efficient or effective in a virtual environment. You need an evolutionary shift in your backup strategy. You need EMC’s next generation backup technologies for your VMware environment.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
784
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

IP Expo 2009 - How To Backup and Protect Your Data in a Virtual Environment

  1. 1. How To Backup and Protect Your Data in a Virtual Environment <br />Ian Wells<br />Regional Director | Data Protection Solutions | UKI<br /> wells_ian@emc.com |  07919 212697<br />
  2. 2. Journey towards Virtualized Data Centre<br />
  3. 3. VMware Environment:Business Problem and the Required Solution<br />Business Problem<br />Backup challenges limiting VMware ROI <br />Not meeting VMware consolidation goals or backup and recovery SLAs<br />Higher costs & increased Ops/Mgmt<br />Technical Description<br />Traditional backup processes cause backup bottlenecks<br />Extended backup & restore times; limited server consolidation - increased hw spend<br />Solution Required – Efficient VMware Backup, Maximizing ROI<br />Minimal impact on virtual environment <br />Achieve or exceed consolidation and migration goals – 2X consolidation ratio!!<br />One step recovery; Flexible backup options for greater efficiency<br />Results if achieved<br />Increased server consolidation, lower HVAC/Floor space<br />Lower operational costs, fewer host servers required<br />Operational Mgmt Efficiency – greater TB’s per FTE, one-step recovery (file or image)<br />
  4. 4. Server A<br />Server B<br />Server C<br />100%<br />80%<br />60%<br />CPU Utilization<br />CPU Utilization<br />40%<br />20%<br />0%<br />Virtualization Backup and Recovery Challenges<br />Virtualization changes the IT paradigm…<br />Backup must evolve to deliver even greater consolidation and value<br />NEW PARADIGM<br />Virtual Environment: High overall server utilization and littlebandwidth for backup<br />OLD PARADIGM<br />Physical Environment: Low overall server utilization and plenty of bandwidth for backup<br />Virtual Server A<br />Virtual Server B<br />Virtual Server C<br />100%<br />80%<br />60%<br />CPU Utilization<br />CPU Utilization<br />40%<br />20%<br />Shared Physical Resources<br />0%<br />20 percent resource utilization<br />80 percent resource utilization<br />
  5. 5. How to Backup VMware<br />VMwareConsolidated Backup<br />Guest<br />x86 Architecture<br />VMware Virtualization Layer<br />Application<br />Application<br />Operating System<br />Operating System<br />Avamar<br />server<br />Virtual Machines<br />App<br />App<br />App<br />Centralized<br />Data Mover<br />VCB proxy server<br />with Avamar agent<br />OS<br />OS<br />OS<br />ESX Server<br />MOUNT<br />SNAPSHOT<br />SNAPSHOT<br />SNAPSHOT<br />Physical<br />Server<br />SAN<br />Storage<br />Backup client software runs on the VCB proxy server<br />Backup client software runs directly on each virtual machine<br />Avamar<br />agents<br />CPU<br />NIC<br />Disk<br />Memory<br />The Way we WANT to do it!<br />The Way We HAVE to do it!<br />
  6. 6. Using VCB<br />
  7. 7. VCB concerns<br /><ul><li>Large investment in hardware
  8. 8. Proxy servers (1 per 3 ESX hosts)
  9. 9. 50% more disk required
  10. 10. San infrastructure for tape environment
  11. 11. Tape infrastructure
  12. 12. Implementation
  13. 13. Custom scripting required
  14. 14. No GUI interface
  15. 15. Encryption for tape infrastructure
  16. 16. Licensing
  17. 17. Additional backup server licences
  18. 18. Workflow
  19. 19. 2 Backups required to allow VMDK and file level restores
  20. 20. Restores are difficult and may need level 2 support
  21. 21. Vmotion, DRS, SRM are difficult to use with VCB
  22. 22. How do you replicate offsite?</li></li></ul><li>Using VCB to Protect 20Tb of Cloud!<br /><ul><li>VCB and Tape Management System Acquisition
  23. 23. Hardware Purchase- IBM TS3500 with 10 TS1120 tape drives
  24. 24. $200,000
  25. 25. 7 Net Backup VCB SAN Media servers
  26. 26. 70,000
  27. 27. Software Purchase, Net Backup- 7 San Media server licenses
  28. 28. $35,000
  29. 29. San Infrastructure to support 7 Hosts and 10 tape drives
  30. 30. $34,000
  31. 31. Custom scripting and implementation for 7 VCB servers
  32. 32. 100,000
  33. 33. TS1120 tapes- 25 incrementals and 17 fulls plus offsite clones
  34. 34. 442 tapes to support 1 year retention
  35. 35. $22,100
  36. 36. Vaulting
  37. 37. $75,000 for three years
  38. 38. Storage
  39. 39. 50% More storage required for VCB
  40. 40. 10 TB’s at $8 per GB= $80,000</li></ul> Soft costs<br /><ul><li>1 FTE to manage environment =120k x 3 years = 360K</li></ul>Virtual Machines<br />NetBackup<br />VCB Media Servers<br />NetBackup<br />Master Server<br />SAN Infrastructure<br />MOUNT<br />TS 3500 tape<br /> library<br />20TB’s of disk<br />50 GB’s per guest equals 400 hosts on 20 ESX servers<br />1 Proxy host per 3 VCB servers<br />7 VCB servers required<br />SNAPSHOT<br />SNAPSHOT<br />SNAPSHOT<br />Cost to the Business: $1,126,100<br />SAN<br />Storage<br />50% more storage <br />required with VCB<br />
  41. 41. Why use Guest level backup ?<br /><ul><li>Guest level backup are efficient; sourced based de-dupe allows for
  42. 42. Very efficient use of NIC, on average only .03% of data gets moved daily
  43. 43. Low disk/CPU utilization
  44. 44. Full backups take a fraction of the time versus traditional backups
  45. 45. Consolidate more guests per ESX server
  46. 46. Storage and protocol agnostic
  47. 47. Implementation
  48. 48. No Custom scripting required
  49. 49. Easy GUI interface
  50. 50. Built in encryption
  51. 51. Licensing
  52. 52. No client licenses
  53. 53. Workflow
  54. 54. Operations can easy manage a large Vmware environment
  55. 55. File level restores take seconds
  56. 56. No issues with Vmotion, DRS or SRM
  57. 57. Replication is very efficient. No need for backup tapes</li></li></ul><li>The Alternative : Avamar/ Guest Level<br />Avamar agents<br />x86 Architecture<br />VMware Virtualization Layer<br />Application<br />Application<br />Operating System<br />Operating System<br />NIC<br />CPU<br />Disk<br />Memory<br /><ul><li>Avamar agent resides inside each virtual machine
  58. 58. De-duplicates data within the virtual machine, as if they were physical servers
  59. 59. Moves minimal backup data
  60. 60. Reduces resource contention and accelerates backups
  61. 61. Provides file-level restore for Windows, Linux, and Solaris</li></ul>Cost to the Business: $554,000<br />Saving for the Business: $572,100<br />
  62. 62. Further Real World Proof ....<br /><ul><li>59 ESX Servers Saved
  63. 63. $6.8M Saved over 3 Years</li></li></ul><li>EMC Avamar #1 Source De-Dupe Technology<br />Integrated backup solution with source-based deduplication<br /><ul><li>Next generation backup solution</li></ul>Integrated software & hardware solution with global source-based deduplication<br />Deduplicates across sites and servers globally<br />Effective full backup every time<br />Single step recovery<br />Backup process reduces data sent over the network and stored <br />Variable-length subfile segments for optimal deduplication<br /><ul><li>Integrated high availability and reliability </li></ul>RAIN for high availability and fault tolerance<br />Avamar server and data recoverability verified daily<br />Replication between servers <br />Avamar<br />Scalable, turnkey solution small offices to datacenters<br />
  64. 64. Source and Target Deduplication<br />Network<br />Network<br />There are strong use cases for both technologies… but only source deduplication reduces network bandwidth requirements and decreases resource utilization during backups.<br />DEDUPLICATION AT SOURCE<br />DEDUPLICATION AT TARGET<br /><ul><li>Moves ~ 200 percent of primary data weekly
  65. 65. Up to 50 times reduction backup storage
  66. 66. Backups are typically restored from full and incremental images
  67. 67. Data viewed as file systems and/or virtual tape library target for traditional backup environments
  68. 68. Moves ~ 2 percent of primary data weekly
  69. 69. Up to 50 times reduction in backup storage
  70. 70. Up to 500 times reduction in network impact
  71. 71. Up to 10 times faster daily full backups
  72. 72. All backups are full; immediate, single-step recovery
  73. 73. Next-generation backup and recovery</li></li></ul><li>Resource Usage Comparison<br />CPU Usage<br />Network Usage<br />Disk Usage<br />Significantly less CPU impact<br />Give CPU cycles back to the applications<br />Significantly less Network utilization<br />Don’t be a backup scheduling master<br />Significantly less Disk I/O<br />Give back to the application<br />At the end of the day your production applications should control the size of your VM infrastructure<br />Backup is not ‘strategic’, it is a necessity – don’t let it control your VM infrastructure <br />Avamar<br />Traditional<br />
  74. 74. Avamar Solutions for VMware Infrastructure<br />Avamar VM<br />Operating System<br />(ENCRYPTED)<br />(ENCRYPTED)<br />x86 Architecture<br />x86 Architecture<br />x86 Architecture<br />x86 Architecture<br />x86 Architecture<br />x86 Architecture<br />VMware Virtualization Layer<br />VMware Virtualization Layer<br />VMware Virtualization Layer<br />VMware Virtualization Layer<br />VMware Virtualization Layer<br />VMware Virtualization Layer<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />App<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />OS<br />Disk<br />NIC<br />Memory<br />CPU<br />Disk<br />NIC<br />Memory<br />CPU<br />Disk<br />NIC<br />Memory<br />CPU<br />Disk<br />NIC<br />Memory<br />CPU<br />Disk<br />NIC<br />Memory<br />CPU<br />Disk<br />NIC<br />Memory<br />CPU<br />(ENCRYPTED)<br />CPU<br />Disk<br />NIC<br />Memory<br />Remote Offices without VMware<br />Remote Offices with VMware<br />Hardware<br />ESX Server<br />Application<br />WAN<br />Operating System<br />Avamar agent moves data to Avamar Virtual Edition for VMware; data is then replicated to the corporate data center<br />Avamar agent moves data to a physical Avamar Single Node server; data is then replicated to the corporate data center, OR an Avamar agent can back up directly to the data center over the WAN<br />VMware Data Center with Guest-Level Backup<br />VMware Data Center with VMware Consolidated Backup<br />LAN/<br />SAN<br />SAN<br />VCB Proxy Server<br />
  75. 75. Building the Business Case<br />
  76. 76. Will this work for me ??<br />
  77. 77. ^<br />virtualized<br />

×