The document provides an overview of storage systems and business continuity options. It discusses various types of storage including DAS, NAS and SAN. It then covers business continuity and disaster recovery strategies like replication, snapshots and mirroring. It also discusses how server virtualization can help improve disaster recovery.
83. Components of Effective DR DR Recovery Facility Primary Infrastructure Designed for Resilience and Recoverability Processes And Procedures Operational Disaster Recovery And Business Continuity Plan
84.
85.
86.
87.
88.
89.
90.
91.
92. Compare Recovery Steps Find hardware Configure hardware / partition drives etc. Install Operating System Adjust Registry entries, permissions, accounts Install backup agent Find hardware Install VMware with Templates “ Single-step automatic recovery” from backup server “ single-step automatic recovery” from backup server Physical to Physical Do Once Repeat for each box Physical to Virtual Repeat for each box
139. Virtualisation Improve Utilisation Spare Logical Drive 1 = 2 Disks Logical Drive 2 = 8 Disks Logical Drive 3 = 3 Disks 1 Hot spare 550 GB of wasted space 14 x 72 GB disks = 1 TB capacity Vol 0 Data Parity Database Data Data Data Data Data Data Data Parity Home Directories Data Data Parity 140 GB 370 GB 40 GB
140.
141.
142. Flexible Volumes Improve Utilisation Logical Drive 1 = 144GB Logical Drive 2 = 576GB Logical Drive 3 = 216GB 1 Hot spare Spare Database Home Dirs Vol0 400 GB used 600 GB of Free Space! 14 x 72 GB disks = 1 TB capacity Data Data Data Data Data Data Data Data Data Data Data Parity Parity Aggregate
149. The Unified Storage Architecture Advantage Incompatible silos Compatible family Platforms HP, EMC, DELL, IBM Storage Virtualisation Software & Processes Incompatible software; different processes Unified software; Same processes Experts & Integration Services Lots of experts and integration services Reduced training & service requirements
150.
151. Managing Disk Based Backup Through Storage Virtualisation Single Instance Storage (Deduplication)
152. Backup Integration Snapshot and Snapshot Restore Backup and Recovery Software Disk Based Target Secondary Storage Short-Term Local Snapshot Copies Mid- to Long-Term Disk to Disk Block-Level Backups Client Drag-and-Drop Restores Changed Blocks Primary Data 9AM 12PM 3PM Snapshot Snapshot Snapshot Primary Storage Instant Recovery
153. Advanced Single Instance Storage User1 presentation.ppt 20 x 4K blocks User2 presentation.ppt Identical file 20 x 4K blocks User 3presentation.ppt Edited, 10 x 4K User4 job-cv.doc Different file 8 new 4K blocks = Identical blocks Data Written to Disk: With ASIS: 38 blocks Without ASIS: 75 blocks
157. Snapshot Internals Active file system version of FILE.DAT is now composed of disk blocks A, B & C’. Snapshot file system version of FILE.DAT is still composed of blocks A, B & C C’ Snapshot File: FILE.DAT A B C Active File System File: FILE.DAT Disk blocks
158. Snapshot-Based Data Recovery User is offered this most recent previous version (and up to 255 older versions) User may drag any of these read-only files back into active service
162. SnapRestore Recovery snap X restore … Snapshot Active File System 2 N Active File System 1 2’ N’ 1’ … Marked as free blocks after Snapshot Restore
167. SnapMirror Function SAN or NAS Attached hosts Source Source Step 1: Baseline Step 2: Updates Target LAN/WAN Target LAN/WAN SAN or NAS Attached hosts OR Immediate Write Acknowledgement Immediate Write Acknowledgement … ... of source volume(s) Baseline copy … ... of changed blocks Periodic updates
169. Storage Mirroring Internals Source Volume Target Volume Completed Target file system is now consistent, and a mirror of the Snapshot A file system Source file system continues to change during transfer Snap A Baseline Transfer Common snapshot
170. Storage Mirroring Internals Source Volume Target Volume Snap B Target volume is now consistent, and a mirror of the Snapshot B file system Completed Incremental Transfer Snap A
171. Storage Mirroring Internals Source Volume Target Volume Snap C Completed Target volume is now consistent, and a mirror of the Snap C file system Incremental Transfer
183. The Pain of Development Prod Volume (200gb) Pre-Prod Volume (200gb) QA Volume (200gb) Dev Volume (200gb) Test Volume (200gb) Sand Box Volume (200gb) 1.4 TB Storage Solution 200 GB Free Create copies of the volume Requires processor time and Physical storage
184. Clones Remove the Pain Prod Volume (200gb) Pre-Prod Volume QA Volume Dev Volume Test Volume Sand Box Volume 1.4 TB Storage Solution Create Clones of the Volume – no additional space required Start working on Prod Volume and Cloned Volume Only changed blocks get written to disk! 1 Tb Free
185. Ideally… Primary Production Array Secondary Array Mirror Create Clones from the Read Only mirrored volume Removes development workload from Production Storage!
219. Oracle ASM Automatic Storage Management Disks Logical Vol File System Files Tablespace Tables Disk Group Logical Vol File System File Names Tablespace Tables Before ASM ASM Networked Storage (SAN, NAS, DAS) 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010
220. Compatible Storage Adds Value to Oracle ASM Yes Yes Yes Yes Yes Yes Yes Yes No No Yes Yes Yes Yes Yes Compatible Storage Yes No Thin provisioning of ASM Disks Yes No Space efficient Cloning Yes No Free space management across physical disks Yes No I/O prioritization Yes No Balance I/O across Physical Disks Yes No Stripe data across Physical Disks Yes Yes Balance I/O across ASM Disks Yes Yes Stripe data across ASM Disks Yes Yes Active Block corruption detection Yes Yes Passive Block corruption detection Yes No Lost disk write detection Yes Yes Protect against Single Disk Failure Yes No Storage Snapshot based Restores Yes No Storage Snapshot based Backups Data Protection Storage Utilization Performance Yes No Protect against Double Disk failure Data Resilience Oracle ASM + Compatible Storage Oracle ASM
221. Integrated Data Management Approach Go from this… Centralized Management X High cost of management X Long process lead times X Rigid structures X Low productivity + Administrator productivity + Storage flexibility + Efficiency + Response time … to THIS Server-Based Management Application-Based Management Storage Management Integration and Automation Data Sets and Policies
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234. Oracle Applications Lifecycle Need reliable backup and recovery solution Install Implement Re-organize Upgrade Patch Deploy Pain Points Plan Tune & Maintain Solutions Configure systems, forecast storage accurately Provision and maximize utilisation with FlexVol Testing requires duplicate data, lengthy and expensive process Flexible Clone: Fast & space-efficient data duplication Backup and Recovery solution with Snapshots, SnapShot Restore Mirror prod. data to test and dev system, lengthy process Mirror data with Storage Mirroring, ReplicatorX Create several clones, lengthy process, expensive Create clones with FlexClone, automate with SMO Need reliable backup and recovery solution Use Snapshots, SnapShot Restore, Need reliable backup restore, and DR solution Automate backups, restore with SMO, SnapMirror, ReplicatorX for DR
This picture represents the basic framework of RAID-DP that I’ll be using in the rest of the talk. The bracket shows one 4 KB block on each disk. Unlike regular RAID, we divide the blocks on each disk into chunks – four 1 KB chunks in this example. All of the techniques that I’m going to show will apply to every block on the disk, but to keep things simple, I’m just going to focus on this one block.
The left 5 disks are handled as regular RAID 4. So here you can see that I’ve put data in the disks using the example from the first page. And sure enough, 3 + 1 + 2 + 3 equals 9. One of the nice things about RAID-DP is that it is a strict super-set of RAID 4, which means that it’s easy to take a RAID 4 group and upgrade it to RAID-DP, or take a RAID-DP group and convert it back to RAID 4, to reclaim the extra disk. TRANSITION: Now let’s look at how the Diagonal Parity works.
Here I’ve marked off a diagonal in blue. Notice that the diagonal includes not only the data disks from the RAID 4 array, but also the parity. We store the diagonal parity on the DP disk. Although the diagonal parity goes down the block as a diagonal, the parity calculation itself works just the same. So you can verify in this example that 1 + 2 + 2 + 7 equals 12. Also note that I’ve only filled in numbers for a few of the chunks. Right now, I’m just trying to help you understand the very basic operation of RAID-DP. I’ll fill in more details later. TRANSITION: So now let’s look at what happens if we fail a drive.
If we fail just one drive, then we can reconstruct the data just with regular old RAID 4. Take 9 – 3 – 2 – 1 and you get 3, which is what was there. TRANSITION: But suppose a second disk fails… CLICK
Now we would be hosed with normal RAID 4, because we are missing two values, but we only have one equation. But notice, we do still have a diagonal row that is missing only one element. So we can use the diagonal to reconstruct the missing block on the second disk. Do the math: 12 – 7 is 5, minus 2 is 3, minus 2 is 1. TRANSITION: Sure enough… CLICK
Now we have enough data to do the reconstruction by normal RAID 4. Do the math: 9 minus 3 is 6, minus 2 is 4, minus 1 is 3. TRANSITION: And sure enough… CLICK.
At this point, we’ve only reconstructed the missing chunk for the top row, but this simple example should help build your intuition for the next step, when we look at how to reconstruct the missing chunks for all of the rows. So far so good, but things are about to get much more complicated, so let’s review what we are doing. Remember that the bracket identifies 4 KB worth of data on each disk (one WAFL block), and we’ve divided that into four chunks, so that each little red dot represents 1 KB of lost data. The trick now is to show how to extend this same technique to cover all of the missing chunks in the picture. And remember also that this same technique can be applied to each block in the entire disk.
You’ll just have to trust me that all of these add up the way they should. But just as an example, let’s look at the pink diagonal: 2 plus 1 is 3, plus 3 is 6, plus 5 is 11. Sure enough. Now is a good time to take a deep breath, look at this whole picture and make sure you understand all the working pieces. TRANSITION: Now let’s kill a couple of drives.
The shows a simple configuration for illustrative purposes where there are VMs on two sets of servers in a HA cluster. The VMs have Reservation (lower resource limits) and Limits (higher resource limits) values explicitly. The actual level of usage of the VMs is between these two values. When one of blades fails the failing servers will be restarted on the remaining blades in the HA cluster with the result that the allocated resources to the VMs will be reduced dynamically to a lower value closer to their reservation threshold in order to accommodate the new VMs. This contains a suggested approach for setting resource allocation values in order to configure effective automatic recovery in a HA cluster. The following terms are used to define resource requirements: NS Number of servers in one half of a symmetrical HA cluster defined across both HP sites NPPS Number of processors per server PP Processing power of processor HSH High share resource allocation relative ratio number MSH Medium share resource allocation relative ratio number LSH Low share resource allocation relative ratio number NHVM Number of VMs with a share value set to High for which automatic disaster recovery is to be allowed NMVM Number of VMs with a share value set to Medium for which automatic disaster recovery is to be allowed NLVM Number of VMs with a share value set to Low for which automatic disaster recovery is to be allowed RF Reservation Factor – this is a ceiling for the total of the Reservation values for all virtual machines for which recovery is to be automated. Reservation Factor should be set to less than .5 in order to allow for processing resources for the virtualisation hypervisor. TPMR Total physical machine processing resource capacity RVU Reservation value unit – this is a notional amount of resources that when multiplied by RV Reservation value set for a virtual machine RVH This is the suggested reservation value to be set for a virtual server with a High share resource RVM This is the suggested reservation value to be set for a virtual server with a Medium share resource RVL This is the suggested reservation value to be set for a virtual server with a Low share resource TR This is the total of all the reservation values for virtual machines in one side of a symmetrical
The following is one way of determining how the Reservation values should be set. (1) TPMR = NS x NPPS x PP (2) RVU = TPMR x RF / (NHVM x HSH + NMVM x MSH + NLVM x LSH) (3) RVH = RVU x HSH (4) RVM = RVU x MSH (5) RVL = RVU x LSH (6) TR = RVU x (NHVM x HSH + NMVM x MSH + NLVM x LSH) Number of servers in one half of a symmetrical HA cluster defined across both locations 8 Number of processors per server 2 Processing power of processor 3.2 High share resource allocation relative ratio number 2 Medium share resource allocation relative ratio number 1.5 Low share resource allocation relative ratio number 1 Number of VMs with a share value set to High for which automatic disaster recovery is to be allowed 20 Number of VMs with a share value set to Medium for which automatic disaster recovery is to be allowed 20 Number of VMs with a share value set to Low for which automatic disaster recovery is to be allowed 20 Reservation Factor – this is a ceiling for the total of the Reservation values for all virtual machines for which recovery is to be automated. Reservation Factor should be set to less than .5 in order to allow for processing resources for the virtualisation hypervisor. .45 (1) TPMR = 8 x 2 x 5.2 = 51.2 (2) RVU = 51.2 x .45 / (20 x 2 + 20 x 1.5 + 20 x 1) = 0.256 (3) RVH = 0.256 x 2 = 0.512 (4) RVM = 0.256 x 1.52 = 0.384 (5) RVH = 0.256 x 1 = 0.256 (6) TR = 0.256 x (20 x 2 + 20 x 1.5 + 20 x 1) = 23.04
VMware ESX Server. A robust, production-proven virtualisation layer run on physical servers that abstracts processor, memory, storage, and networking resources into multiple virtual machines. VirtualCentre Management Server (VirtualCentre Server). The central point for configuring, provisioning, and managing virtualised IT environments. Virtual Infrastructure Client (VI Client). An interface that allows users to connect remotely to the VirtualCentre Server or individual ESX Servers from any Windows PC. VMware Virtual Machine File System (VMFS ). This is a high-performance cluster file system for ESX Server virtual machines. VMware Virtual Symmetric Multi-Processing (SMP). Feature that enables a single virtual machine to use multiple physical processors simultaneously. VMware VMotion. Feature that enables the live migration of running virtual machines from one physical server to another with zero down time, continuous service availability, and complete transaction integrity. VMotion is a technology used by the VMware DRS components VMware HA. Feature that provides easy-to-use, cost-effective high availability for applications running in virtual machines. In the event of server failure, affected virtual machines are automatically restarted on other production servers that have spare capacity. VMware Distributed Resource Scheduler (DRS). Feature that allocates and balances computing capacity dynamically across collections of hardware resources for virtual machines. VMware Consolidated Backup. Provides an easy to use, centralised facility for agent-free backup of virtual machines. It simplifies backup administration and reduces the load on ESX Server installations.
This lists sample costs for various VMware configurations. VMware is priced per pair of processors on which the software runs. VirtualCentre is sold separately. Only one VirtualCentre instance is needed for a virtual infrastructure, subject to architectural limits.
The elements of this option are: The primary server virtualisation infrastructure consists of two servers There is a separate server to run VirtualCentre to monitor, administer and control the virtual server environment. Data will be stored on a high-capacity, highly-resilient and reliable SAN. Server data will be initially backed-up onto a high-capacity, low-cost disk storage unit. Server data will then be backed-up to a LTO3 tape autoloader unit. This will reduce the manual effort associated with tape handling. The VirtualCentre server will provide centralised management, administration and control of the virtual server infrastructure. In the event of failure of one of the physical servers in the primary site, the HA component of VMware will allow the virtual servers on the failing physical server to be recovered onto the other physical server automatically.
Data will be backed-up from the primary SAN to a low-cost, high-capacity disk storage unit. This will enable rapid backup with minimal impact on production systems during the backup process. Data will then be backed-up to an LTO3 tape autoloader. This will reduce the manual effort associated with tape handling during backup.
Data will be backed-up from the primary SAN to a low-cost, high-capacity disk storage unit. This will enable rapid backup with minimal impact on production systems during the backup process. Data will then be backed-up to an LTO3 tape autoloader. This will reduce the manual effort associated with tape handling during backup. The backup data on the primary disk backup unit will be copied to a storage unit in the backup site to provide a copy from which data can be restored in the event of failure of the primary site. Backup tapes can be moved from the primary site to the backup site.
There are a number of architectural limits that affect large scale implementation: Number of virtual machines (for management server scalability) 1500 Number of physical hosts per DRS cluster 32 Number of physical hosts per HA cluster 16 Number of physical hosts per VirtualCentre server 100 Ultimately this will require two or more entirely separate Virtual Infrastructures each of which will be managed by entirely separate VirtualCentre systems. In this configuration, each Virtual Infrastructure has three blade enclosures of 16 blade servers each in each data centre. This means each Virtual Infrastructure has 96 physical hosts – 48 in each data centre for symmetry. This will impose additional hardware requirements for VirtualCentre systems and VirtualCentre database servers. In reality the number of physical hosts per Virtual Infrastructure may be lower because of the number of virtual machines running on the physical servers. 96 physical hosts should be able to run a minimum of 750 virtual servers which is considerably less than the threshold of 1,500. This minimum of 750 is based on an average of around four virtual machines per blade processor.
Multiple Clusters are defined up to the current maximum of 16 physical servers per HA cluster. VMware clusters are defined symmetrically across both sites. So, for a cluster of 16 physical servers, eight are located in each site. The VMware Cluster is designed to maximise recoverability while meeting agreed any SLA terms for resilience and high availability, maximising resource utilisation and long-term flexibility and minimising physical resource requirement. There is no ideal design that optimises all the factors. Some compromise is required. The easiest VMware Cluster design consists of two sets of identical resources across both data centres.
Like any IT project, the investment in implementing server virtualisation should be justified to ensure that it delivers real benefits. A cost benefit analysis is important to l enable you to prepare a business case for server virtualisation safe in the knowledge that the information it contains is accurate and detailed. It will equip you with all the facts you need to understand if server virtualisation will deliver you bottom-line business benefits.
DSS recommend the nworks SCOM Management Pack for VMware is selected for SCOM integration if required. The nworks MP provides full Alerting and Performance charting on VMware VI3 enterprise system status, as well as operational information. It collects: Performance and Event data for VMware ESX Hosts, either from VirtualCentre or ESX directly Performance and Event data for VMware ESX Guest Virtual Machines, either via VirtualCentre or ESX directly Events and Alerts from VirtualCentre in many categories such as security, status/state-change, object creation/deletion and other management & admin actions taken in VirtualCentre. The Topology of the Virtual Infrastructure within VirtualCentre – Data centres, Folders, Clusters, Hosts and Guests Events and Alerts from nworks own VEM Collector service The detailed data available in the nworks MP is delivered by use of the VMware SDK on VirtualCentre, which gives an accurate picture of the status of VirtualCentre, the managed Hosts, and the Guest Virtual Machines. The SCOM Management Packs runs the nworks Collector. The nworks Collector component is a Windows service which can run on a physical server or a Virtual Machine. The Collector is also referred to as VEM (Virtual Enterprise Monitor). The VEM server can be a virtual server to reduce cost. The nworks Collector architecture does not require the installation of software on the ESX Server. The nworks SCOM Management Pack two versions: VMware Events Only MP for SCOM - handled only VMWare events VMware MP for SCOM - covers both events and performance logging The second version is more expensive but more functional. It can collect up to 300 metrics on the operation of virtual servers.
Now that’s all a grand oversimplification, since there are lots of forces at work. Let’s look at what’s really happening. First, let’s talk about Volumes. Volumes are the basic building block—the unit around which all data management is based. Therefore, the tools and processes that we have to manage our data acts on volumes—like snapshots, SnapVault, and backup & restore. When you can act on the smallest unit, you can have very precise control—all these things lead to a push to continue to control data at the volume level. Meanwhile, volumes themselves are getting bigger, and the disks that hold them are getting bigger, faster, and cheaper. (click) so creates an opposing dynamic—towards bigger and bigger physical storage. At one end, we’ve got increasing storage, performance and cost pressures driving the adoption of bigger and bigger disks. (what role does the grid and RAID DP play here?) At the same time, we know that the key to using these big disks efficiently is to have highly customized control over the management of all aspects of the data. Tools like SnapShots, SnapMirror and Snapvault all depend on optimizing configuations at the volume level. (more examples? ILM depends on each volume being managed by the demands of its types of data; automated migration, restore on demand, etc.)
In order to accomplish this we are introducing a new entity to capture the physical characteristics of disks – We call it an aggregate. An aggregate is a collection of raid groups and is used to provide a large pool of storage for use by flexible volumes. There can now exist multiple flexible volumes in a single aggregate each of which can be dynamically resized. Reallocation of space is now an instantaneous non-disruptive operation. The thing to note is that from a data management perspective the basic container of data and the basic building block for your storage architecture is still a volume and aside from new features it maintains its properties of the past.
Aggregate is representation of physical storage space provided by the combined raid groups – a collection of blocks. As a volume is created it takes some space to set up the meta data, file system view and provide a access point for the user, but no space is carved off of the aggregate space. As data is written in a volume, space from the aggregate is utilized just like we do for qtrees today. The blocks belonging to different flexible volumes are intertwined within an aggregate.
Goal of this slide: Demonstrate the difference and consequential value of the N series Unified Architecture approach. Script: One of the best examples of N series innovation is the Unified Architectural Model which provides the foundation for the dramatic differences in value N series is able to provide. First let’s look at the hardware platform model. No matter which of our competitors you look at, they all use the same approach—specialized, incompatible platforms for different functions. They may have a platform for low end, another for mid-range, yet another for high-end, and still another for compliance. Each of these platforms, while robust in its own area, forms an information silo, and an investment dead-end. By contrast, N series systems base solutions on one, extremely broad, scalable and fully compatible platform, totally eliminating the notion of information silos. And to help you get the most out of your investment dollars, every system can be easily upgraded without migrating the data. [Click mouse to build] This model starts to get even more compelling when you look at the software and processes required. The specialized hardware platforms each run their own, incompatible software, each with its own set of processes and “best practices”. In contrast, the N series family all runs the same set of software, with the same processes. So much so that we hear customers say that they only have to test an application with one N series system—they know what works on one, will work on all. [Click mouse to build] Add to this the people side of the equation, and you see that all those incompatible platforms each need their own experts, and getting them to work together requires even more people and expensive integration services. With n series, your people need less training, spend less time on making things work together, and because they’re familiar with the systems, they make fewer mistakes—the leading cause of downtime. I hope this helps you understand how simple concept like “architectural simplicity” can make a big impact to your bottom line.
EMC offers strong solutions in each of our markets including primary, secondary and backup. However, we can actually provide the simplification EMC can only talk about. Data ONTAP offers the user consistent management and functionality across all N series platforms. We mean not only in name by actual syntax and operational functionality from the low-end through the high-end. There is no need to re-train staff as another N series solution is added to the environment. EMC wide breadth of solutions have been acquired through a variety of acquisitions and partnerships resulting in not only different operating systems required for their products but often drastically different functionality implementation. Thus, the addition of another platform or the movement of staff to another EMC system required retraining and reeducation as to the capabilities and limitations of that system. Several of EMC’s products have a very narrow functionality limitations. One example is the CLARiiON CX which requires a separate platform to support FC and another platform to support iSCSI. N series allows customers to intermix. Other limitations include Centera’s scalability only by adding an additional frame, lack of a backup solution, lack of tape connectivity, lack of migration. As you can see with the complexity of EMC’s solutions, the only way to provide the integration for the customer is through the involvement of professional services. This not only increases the initial and on-going costs of the solution but locks the customer into the EMC solution.
Then use the picture from the Customer Preso… Integrated NAS Protection Key Messages: The co-developed solution integrates all stages of NAS data protection, while increasing performance and simplifying management. While most of the short-term and long-term integration is available today, they have been enhanced and now integrated across each stage. Organization’s can now manage all operations from a single, intuitive interface (NetBackup). Previously, an administrator would have to log into NAS multiple systems and interface with a number of tools to perform each operation. In addition, there was no understanding or logic of what administrators have protected with online snapshots compared to NDMP tape backups. Short-Term (the solution already offered with NetBackup 5.1) – no need to discuss this in a lot of detail here, as it was covered in the Overview section NetBackup (Advanced Client) integrates with NetApp’s Snapshot technology to schedule, manage, and catalog local disk-based snapshots. Snapshots can managed across multiple NSs and locations. Snapshots are space-optimized by providing only a map of the file system at a point-in-time. However, the space required to store snapshots increases in size when data is changes over time. NetBackup (Advanced Client) integrates with NetApp’s SnapRestore to rapidly restore a single file from the local snapshots or rollback a fie system to a point-in-time. Note: Same concept and benefits as NetBackup Advanced Client Instant Recovery feature. Note: This functionality has already been released with NetBackup 5.1. However, it the integration of all components is where customers will find value. Near-Term NetBackup (Advanced Client) integrates with NetApp’s SnapVault technology to provide disk-to-disk backups of NetApp NSs to a consolidated NetApp NearStore system. Backups can be performed at an incremental changed block-level for high-performance backups and reduced storage requirements. Leveraging SnapVault’s ability to send data great distances, organizations will be able to backup remote office NAS systems to a centralize disk repository. Additional benefits of NetBackup managing NetApp SnapVault: - Oracle application interface. - Consolidation of primary and secondary snapshots reduces storage - Ease of use – replaces cumbersome administrative CLI commands which must be run on both the primary and secondary systems. - Provides a “single pane of glass” for NAS NS administration, backups, and restores. - Improved scheduling of snapshot and snapvault transfers with finer time granularity with predictability. - Provides a user restore browse capability enabling efficient user directed restores. (.vs. ~snapshot copies) - Improved snapshot naming conventions combined with NetBackup cataloguing to identify images. ((( Long-Term NetBackup for NDMP Option will migrate (backup) snapshots from the NetApp NearStore to tape for long-term storage. NetBackup 6.0 will bring SSO (drive sharing) for NDMP NAS systems, WORM tape support, and directory level DAR (direct access recovery). )))
Another key element of Snapshots are that they are near instantaneous, as they only require copying a simple data structure, not copying the entire data volume. Taking a Snapshot requires virtually no storage. It is only as data changes in the volume that these changes are written. These changes are written to new disk locations thus the Snapshot doesn’t require extraneously copying data. In comparison, mirroring requires significant costs in terms of the bandwidth infrastructure, the potential for downtime, and the computing resource dedicated to doing the copies, as well as the management overhead of these time intensive tasks . Lastly, in comparison to expensive mirroring solutions, Snapshots are bundled in to Data ONTAP and come standard with every system we ship.
Aggregate is representation of physical storage space provided by the combined raid groups – a collection of blocks. As a volume is created it takes some space to set up the meta data, file system view and provide a access point for the user, but no space is carved off of the aggregate space. As data is written in a volume, space from the aggregate is utilized just like we do for qtrees today. The blocks belonging to different flexible volumes are intertwined within an aggregate.
Aggregate is representation of physical storage space provided by the combined raid groups – a collection of blocks. As a volume is created it takes some space to set up the meta data, file system view and provide a access point for the user, but no space is carved off of the aggregate space. As data is written in a volume, space from the aggregate is utilized just like we do for qtrees today. The blocks belonging to different flexible volumes are intertwined within an aggregate.
Aggregate is representation of physical storage space provided by the combined raid groups – a collection of blocks. As a volume is created it takes some space to set up the meta data, file system view and provide a access point for the user, but no space is carved off of the aggregate space. As data is written in a volume, space from the aggregate is utilized just like we do for qtrees today. The blocks belonging to different flexible volumes are intertwined within an aggregate.
Why Use NetApp for Exchange?
Key Message: NetApp has software specialized for Exchange environments Talking points: SnapManager - currently (Q3CY’03) supports Exchange 5.5 and Exchange 2000. SnapDrive – runs in both ethernet and fiber channel environments Single mailbox recovery software - works with Exchange 5.5 and Exchange 2000. Data Fabric Manager – Provides a central management consol for NetApp systems NetApp Software for Exchange
SnapManager for Exchange
SnapManager for Exchange Overview
SnapMirror (with SME)
Single Mailbox Restore
PowerControls Software
Notes: 1) Unified positioning of NetApp management tools: -Complete set of management tools -Built from the strong base of our existing products 2) Management tools stack composed of 4 software suites targeted to 3 different administrative needs and roles: -storage administrator: storage and data suite -server administrator: server suite -application administrator: application suite 3) Application Suite -provides application solutions on top of NetApp technology by providing an abstraction layer on top of Server, Data, and Storage Suites -application administrator does not need to worry about layers underneath the Application Suite - improves efficiency of application administrator by taking advantage of NetApp technology 4) SnapManager for SQL Server is part of the Application Suite: - allows database administrators to backup, restore, recover and clone the Oracle database with minimum storage knowledge -uses transparently SnapDrive for Windows which is part of the Server Suite
Here’s a chart with some of the features & benefits of SnapManager for Microsoft SQL Server. Backup& restore: First and foremost is the ability to make quick backups. As we had talked before, customers will be able to make backups that don’t impact the end user experience. This is a valuable feature. With organizations supporting users who the business application from across the globe, it is extremely hard to find times that the database servers can take a break. With SnapManager for SQL, this restriction can be removed. In the case of a disaster, like an accidental deletion or application misbehaviors, customers can stop their database system and get back to a good copy within minutes. This reduces downtime. The best news for this whole thing is that the benefits of rapid backup and restore can be achieved for any size of database installation. Hot backups to SnapShot : Wizards : One of the questions customers have when they buy a product is, “how long is it going to take to deploy this thing and how much time does it take to learn the product?” The beauty of NetApp’s SnapManager for Microsoft SQL Server, is that it is extremely simple to deploy and extremely simple to learn. The look and feel of the product is very much like Microsoft’s native backup tools that most Windows Administrators are familiar with. This makes the learning process extremely simple. MSCS Support: SnapManager for Microsoft SQL Server supports NetApp Cluster Failover for high availability of storage and integrates with MSCS for high availability of the Server Environment. This makes the entire Database infrastructure highly available. Cluster failover: Depending on customer’s needs, NetApp provides clustered or non-clustered storage appliance. For customers who run mission critical exchange servers, the clustered storage appliance is the best way to maximize on the high availability of the storage.
Here’s a chart with some of the features & benefits of SnapManager for Microsoft SQL Server. Volume Mount Point: Support for Volume Mount Points eliminates the limitations with drive letters. This is primarily a limitation for customers who have hundreds of databases. Also, customers might not want to have multiple databases on one/two LUN. Resource Database: Resource database is a read-only database that contains all the system objects in SQL Server 2005. It doesn’t contain any user data or metadata. Each SQL Server has only one instance of this database and is not shared with any other instance. The location of the resource database is dependent on the location of “master database”. This is only supported with SQL Server 2005.
Notes: Leverage larger servers to further consolidate
Key Message : SnapMirror can protect Exchange data from disasters or catastrophic natural events by replication to a remote site Talking Points: Economical remote replication : SnapMirror replicates Exchange data to a a target filer at a remote site with low impact on network traffic and economical deployment over WAN. SnapMirror only replicates incremental changes thus reducing the bandwidth requirements. Rapid recovery in the event of a disaster : When disaster strikes the primary location, a standby Exchange server at the remote location can connect to the Exchange data on the SnapMirror target volume to provide users with rapid access to their email data.
Here’s are the key reasons SnapManager on SQL is valuable to customers: It delivers high availability by making restores simple, reduces backup windows, increases availability of the database infrastructure and does all of this while delivering an easy to manage solution. NetApp’s Storage appliances, software solutions like SnapManager for Microsoft SQL and the services expertise that we bring in, make the transition to using our solution extremely simple, manageable and useful to the end customer. NetApp has a strategic partnership with Microsoft. Both companies collaborate on many fronts and this should give customers and prospects the necessary confidence in using our solutions together. This unbeatable combination of technology, partnership and services should help deliver the best solution for your customer’s environment.
Go to Oracle store to buy it, need to license it.
ASM provides its own portable Volume Management and File System services. These are Database orientated which aim to give the performance of raw disk with the ease of management of a file system. However, its not a general purpose file system (i.e. does not replace NFS, EXT3 etc.). Oracle’s “Automatic Storage Management” (ASM) is a powerful and portable storage manager designed to manage Oracle Database 10 g™ database files. ASM simplifies storage management so that DBAs worry less about Oracle Database file layout and management. ASM delivers lower total cost of ownership while increasing storage utilization, all without compromising performance or availability. With ASM, a fraction of the time is needed to manage your database files. ASM key features include: Volume Management Database File System with performance of RAW I/O Supports clustering (RAC) and single instance Automatic data distribution Online add/drop/resize disk with automated data relocation Automatic file management Flexible mirror protection
Focus on admin productivity across the IT organization Focus on increasing storage flexibility Result is much faster response time and dramatically improved efficiency
NetApp provides the other half of this efficient database management solution with SnapManager for Oracle (SMO). NetApp is the first to deliver a tightly integrated disk-based backup with granular recovery at the file level for Oracle customers using ASM technology. SnapManager for Oracle is a host-based management tool that integrates tightly with your Oracle Database to simplify, automate, and optimize database backup, recovery, and cloning Take snapshots with netapp, register with RMAN. SMO understands how ASM diskgroups translate into NetApp volumes. Can recover specific file or use RMAN SMO value is in recovery and cloning.
Backup and recovery to ensure availability and uptime is something that is top of mind for most if not all DBA’s. Ensuring high levels of availability means, taking backups often. This results in degraded performance (in hot backup mode) or system being taken offline (in cold backup mode). In addition to performance, backups also take significant time as they are limited by the speed of tape. The time to backup and recover reduces DBA productivity as well. Time to recover from tape is also prohibitive as it is limited by speed of tape. All this results in DBA’s taking backups less frequently. Highlight DBA spends time on maintaining backup scripts
A big DBA challenge is balancing BU/recovery, performance and space management. In some studies, work in these areas adds up to 50% of their time. NetApp Snapshot makes it simple. It alleviates the pain points we highlighted in the earlier slides regarding backup and recovery. NetApp allows the DBA to take backups more often as there is no performance or storage overhead. Given that we can store up to 255 snapshot copies, Snapshot can be taken every hour or less if needed Redo/transaction logs-tells you what changed over time
SnapManager for Oracle provides capabilities that enable instantaneous and efficient disk-based backups of Oracle ASM-based databases. In addition to fast backups, SnapManager supports rapid restore and recovery of a failed Oracle Database instance within minutes. It leverages Snapshot ™ technology to provide automated, instantaneous, and space-efficient backups of Oracle Databases. It utilizes SnapRestore® technology to provide automated and rapid restore and recovery of the Oracle Databases. It uses FlexClone ™ technology to provide fast, automated creation of database clones within minutes. SnapManager for Oracle combines these with the NetApp intelligent storage infrastructure to simplify and optimize data management operations. SnapManager for Oracle is also protocol agnostic: it provides the same protection across NFS, iSCSI, and FCP.
Why do you need to create copies of your database? There are a number of reasons (highlight list) Challenge is to be able to replicate data quickly and cost-effectively. Of
There are several ways to copy production data. Offline – stop your application, make sure it’s in a consistent place, then make copies. This isn’t efficient as it impacts production applications unless you have planned downtime. Challenges and pain points Limited storage resources 100% storage capacity overhead per instance, or custom partial extraction scripts Long lead-time requirements Process heavy (I.e., Many “approvals” required.) Storage resource allocation Manual or scripted operations subject to human error Downtime (offline) or degraded production system performance (online) during copy Restoring the baseline requires repeat of this process … your DBAs and application developers could create (and repetitively re-create) a consistent copy of a database application environment……. nearly instantaneously, using negligible incremental storage, as needed, even for individual developers with little or no support of a storage admin? How would that impact the efficiency of your application development team?
For example, supposed a volume is created for a production database. A Snapshot of that database is created for instant backup purposes. Recall that, with exception of a very small amount of metadata, the Snapshot does not occupy any more space. New blocks are allocated only as the active volume changes. A FlexClone can be created from that Snapshot, without creating any new blocks and another server can start a database instance against the cloned data (say for development). Additional space is consumed, only as the FlexClone changes. Hence, a rapid replica of a production volume can be created using a fraction of the storage. The benefits are self explanatory
So the new methodology, if you take the combined solution, would look something like this where you've got your production copies of the database and you may have a DR copy as well which is something Topio can provide as well. And then you're going to clone potentially off of a DR copy. This is just an example. You can do it right off the production if you like. But basically you would mirror production for initial copy and then use clones off of that copy in order to enable all the functionality we've been talking about. You can also leverage, of course, all the other things that are on the NetApp storage device. Snapshots are one thing that of course you can leverage, besides all the other things like RAID-DP and all the advantages that are part of the WAFL file system. So snapshots are one of those, and bottom line is you can take multiple mirrors and span those out to the multiple use cases or multiple developers.
An example. Typical test and dev environment with 3 copies for test and 3 for dev.
NetApp consumes disk only for changed blocks. If you assume a 10% change in the data, it results in 67% reduction in storage required. In addition you also have the flexibility to create and delete clones at will! So first of all we talked about reducing the storage capacity which obviously has a direct impact on the overall cost of the solution if they require less storage. That's done by leveraging NetApp first of all for tiered storage which is a lower cost alternative, it has very good price performance. And on that storage eliminating the need to have a full copy, full physical copy of the data. In terms of simplifying operations there is no impact to production applications while you're maintaining the copies. But you can do that without impacting the production environments. The copies can be distributed to multiple locations. As I talked about, you could have them locally or remote, but you could actually have multiple copies at the same time. You could have one local, one remote, maybe two remote. 08:44 We have the capability to do that simultaneously so that if there's people distributed in different areas or you actually have different needs and you want to split off clones at different points in time based on the requirements, you can do that as well. 08:57 And using the capabilities in the NetApp storage those copies are created in a nearly instantaneous fashion. 09:04 So bottom line is, this allows customers to create and manage more copies of their data in less time and in a more efficient manner, and it really enables them to improve their operations. 09:15 They have an always current set of data using the Topio replication technology, and allows them to create them in an on-demand fashion. 09:25