Riverbed Whitewater Quick Start Manual

Cloud storage gateway with ibm tivoli storage manager
Table of Contents

Advertisement

Quick Links

QUICK START GUIDE
Riverbed® Whitewater® Cloud Storage Gateway
Quick Start Guide for IBM® Tivoli Storage Manager®
Riverbed Technical Marketing
September 2012

Advertisement

Table of Contents
loading
Need help?

Need help?

Do you have a question about the Whitewater and is the answer not in the manual?

Questions and answers

Subscribe to Our Youtube Channel

Summary of Contents for Riverbed Whitewater

  • Page 1 QUICK START GUIDE Riverbed® Whitewater® Cloud Storage Gateway Quick Start Guide for IBM® Tivoli Storage Manager® Riverbed Technical Marketing September 2012...
  • Page 2 Pilot™, Shark®, AirPcap®, SkipWare®, TurboCap®, WinPcap®, Wireshark®, and Stingray™ are trademarks or registered trademarks of Riverbed Technology, Inc. in the United States and other countries. Riverbed and any Riverbed product or service name or logo used herein are trademarks of Riverbed Technology.
  • Page 3: Table Of Contents

    Riverbed Whitewater Cloud Storage Gateway Overview ............................5 Deploying Whitewater Gateways with IBM Tivoli Storage Manager ........................... 6 IBM Tivoli Storage Manager, Riverbed Whitewater Gateway, and Cloud Storage Configuration Example ............... 6 Pre-deployment Checklist ......................................6 Cloud Storage Provider Required Tasks ..................................7 Amazon S3 ..........................................
  • Page 4 Testing Tivoli Storage Manager with Whitewater ..............................24 Method 1: Whitewater Used as a Primary Storage Pool ..........................24 Method 2: Whitewater Used as the Next Primary Storage Pool in the Storage Pool Hierarchy ..............27 Method 3: Whitewater Used as a Copy Storage Pool ............................. 28 Appendix A.
  • Page 5: Executive Summary

    It is simple to set up the Whitewater gateway and start moving data to the cloud in a few hours, compared to setting up tape or other disk replication infrastructures which can take days. Leveraging Riverbed’s industry leading deduplication, compression and WAN optimization technologies, Whitewater gateways shrink data set sizes by 10 to 30x substantially reducing cloud storage costs, accelerating data transfers and storing more data within the local cache, speeding recovery.
  • Page 6: Riverbed Whitewater Cloud Storage Gateway Overview

    Whitewater gateway as a common target within its existing infrastructure. The backup server connects to the Whitewater gateway using standard CIFS or NFS protocols. When you backup to a Whitewater device, it performs byte-level inline deduplication of the backup data to minimize storage consumption and transmission times. Whitewater gateways also use their local disk cache for local storage and recovery of recent backups, providing LAN performance for the most likely restores.
  • Page 7: Deploying Whitewater Gateways With Ibm Tivoli Storage Manager

    Manager and Riverbed Whitewater gateway. 3. A Whitewater physical or virtual gateway needs to be online and connected to the physical network infrastructure. 4. You must procure and setup all necessary software licenses from each vendor, including Riverbed, using vendor-specific guidelines.
  • Page 8: Cloud Storage Provider Required Tasks

     UserName - Specify the user account name established during account registration.  Password - Specify the password established during account registration. Note: Users can get the Application Name/Key by going to https://nmp.nirvanix.com/applications.aspx © 2012 Riverbed Technology. All rights reserved.
  • Page 9: Emc Atmos

    RIVERBED WHITEWATER QUICK START GUIDE EMC Atmos Please refer to EMC Atmos documentation for information about preparing EMC Atmos for use with a Whitewater gateway. When ready, EMC Atmos will provide the following information for you to enter into the Whitewater GUI: ...
  • Page 10: Configuring The Whitewater Gateway

    After you install and start the Whitewater appliance, connect to the Whitewater CLI to configure the management interface: 1. If you are using a virtual Whitewater gateway, connect directly to the console session using the VMware vSphere client and skip to step 3.
  • Page 11: Connecting To The Management Console Gui

    – protocol is http or https. https uses the SSL protocol to ensure a secure environment. If you use https to connect, the system prompts you to inspect and verify the SSL key. – host is the host name you assigned to Whitewater during initial configuration. If your DNS server maps that IP address to a name, you can specify the DNS name.
  • Page 12: Configuring Whitewater Gateway Licenses

    Configuring Whitewater Gateway Licenses You can add or remove a license in the Configure > Maintenance > Licenses page. You install a license on a Whitewater gateway after receiving it from Riverbed Technical Support or Sales. To add or remove a license: 1.
  • Page 13: Configuring Cloud Settings

    You can specify cloud settings, replication scheduling, and bandwidth limit settings in the Configure > Storage > Cloud Settings page. Replication is the process that transfers deduplicated data from Whitewater to the cloud asynchronously. A storage replication service provides an extra measure of redundancy that can be invaluable if the main storage backup system fails.
  • Page 14: Configuring A Cifs Share

    Internet. The share you configured appears in the list of shares on the page. When you add a CIFS share to Whitewater, you can enable authentication or leave it disabled (allowing all users to access the CIFS share).
  • Page 15 Join Domain Displays the controls to add Whitewater to your AD domain. Specify the domain name of the AD that Whitewater must join. If your system has an AD domain, then you can add Whitewater to your AD Domain Name domain and create share permissions for AD users and groups.
  • Page 16: Configuring Ibm Tivoli Storage Manager

    When adding a Whitewater gateway to a Tivoli Storage Manager environment there are three primary tasks that are required. The first is to create a FILE device class, which is associated with a CIFS share created on the Whitewater gateway. The second is to create a storage pool using that FILE device class so data volumes can be written to Whitewater based storage.
  • Page 17: Create A File Device Class

    Tivoli Storage Manager associates device classes with physical storage. The following describes the steps to create a FILE device class and associate it to the Whitewater gateway. These steps use the best practice configuration for Tivoli Storage Manager with the Whitewater gateway.
  • Page 18 Figure 10. Click on Next to continue. Figure 10 Selecting a Device Type Drop Down 4. Provide a new device class name, Whitewater CIFS share path name, and set the mount limit and maximum size values, as shown in Figure 11. Click on Next to continue.
  • Page 19: Create A Primary Or Copy Storage Pool

    2. When the Stoage Pools panel appears, click the Select Action drop down menu and select Create A Storage Pool, as shown in Figure 13. Figure 13 Create a Storage Pool Drop Down © 2012 Riverbed Technology. All rights reserved.
  • Page 20 This value can be set to whatever value you need, but should represent the total size of the Whitewater cache storage when multiplied by the per volume size specified in the Device Class creation step above.
  • Page 21: Associate Backups To The New Primary Storage Pool

    Once the storage pool is created, TSM must be configured to send data to the storage pool. In method 1, a policy domain can be updated to send data to that storage pool. In method 2, an existing storage pool can be associated to send data to the Whitewater storage pool as the next pool in the storage hierarchy.
  • Page 22 5. After returning to the Policy Domain panel, you will need to activate the policy change. Click the Select Action drop down and select Manage Pending Changes, as shown in Figure 20. Figure 20 Manage Pending Changes Drop Down © 2012 Riverbed Technology. All rights reserved.
  • Page 23: Method 2: Assign The New Storage Pool As The Next Storage Pool In The Hierarchy

    Using a Whitewater gateway in this fashion will reduce the amount of simultaneous traffic on the network as opposed to method 1, since data flow to the Whitewater storage pool will be separate from backup data flow into the TSM server.
  • Page 24 RIVERBED WHITEWATER QUICK START GUIDE 2. Select the radio button for the storage pool that will send data to the Whitewater storage pool, and from the drop down menu select Modify a Storage Pool, as shown in Figure 23. Figure 23 Modify Storage Pool Drop Down 3.
  • Page 25: Testing Tivoli Storage Manager With Whitewater

    Method 1: Whitewater Used as a Primary Storage Pool Note: This test applies only if you configured Whitewater as a primary storage pool for backups from a policy domain. If you configured Whitewater as the next primary storage pool in a storage pool hierarchy, go to Method 2 below. If you configured Whitewater as a copy storage pool, go to Method 3 below.
  • Page 26 Figure 27 Backup Detailed Status Report 3. When the backup is complete, perform a restore to validate that Whitewater can restore the backed up data. From the Tivoli Storage Manager Backup-Archive GUI, click on Restore. In the Restore window that appears select the local drives or files to restore, and click Restore to begin the operation (Figure 28).
  • Page 27 4. Restore activity will be provided in the Task List window, as shown in Figure 29. By clicking the Report button you can view detailed status of the operation, including throughput metrics and object counts (Figure 30). Figure 29 Task List Status Figure 30 Restore Detailed Status Report © 2012 Riverbed Technology. All rights reserved.
  • Page 28: Method 2: Whitewater Used As The Next Primary Storage Pool In The Storage Pool Hierarchy

    Method 2: Whitewater Used as the Next Primary Storage Pool in the Storage Pool Hierarchy Note: This test applies only if you configured the Whitewater appliance as the next primary storage pool in a storage pool hierarchy. If you configured Whitewater as a copy storage pool, go to Method 3 below.
  • Page 29: Method 3: Whitewater Used As A Copy Storage Pool

    Method 3: Whitewater Used as a Copy Storage Pool Note: This test applies only if you configured Whitewater as a copy storage pool. If you configured Whitewater as a primary storage pool, go to Method 1 or Method 2 above.
  • Page 30 Select the copy storage pool from the Copy storage pool drop down as shown in Figure 35. Click on OK to begin the backup storage pool process. Figure 35 Copy Storage Pool Selection © 2012 Riverbed Technology. All rights reserved.
  • Page 31: Appendix A. Whitewater Best Practices For Ibm Tivoli Storage Manager

     Tivoli Storage Manager uses Whitewater CIFS shares as a FILE device class. Each FILE device class can point to one or more Whitewater CIFS share(s) via the directory option. It is recommended that each share path be comprised of a unique Whitewater hostname and share name value.
  • Page 32: Tsm Storage Pool Setup

    1. Setup the Whitewater appliance as a primary sequential storage pool behind the existing disk storage pool. TSM uses the existing disk storage pool for fast writes for backups, and then migrates the data during the day to the Whitewater appliance. This method separates the network requirements of backups from the migration operations that move data to the Whitewater appliance.
  • Page 33: Appendix B. Whitewater Best Practices For Solaris Operating Systems

    Appendix B. Whitewater Best Practices for Solaris Operating Systems NFS networking parameters on Solaris operating systems should be configured to optimally send data to Whitewater via configured NFS mounts. In addition to tuning the rsize and wsize mount options appropriately, nfs3_max_transfer_size and nfs3_bsize should also be tuned.
  • Page 34: Appendix D. Disaster Recovery (Dr) Procedures

    TSM server, are lost. However, at least one or more backups of that production environment exist in the cloud storage. To recover the data at the DR Site you need a new TSM server and a new physical or virtual Whitewater gateway (Diagram 3).
  • Page 35: Whitewater Gateway Recovery

    VMware environment at the DR Site. While not required, the Whitewater at the DR Site is suggested to have the same or greater local storage capacity as the original Whitewater at the lost Production Site, should you decide to make these resources at the DR Site your production resources after the DR is complete.
  • Page 36 Whitewater downloads all of the data from the cloud. Therefore, it is recommended that you also populate the actual data from the cloud back onto the new Whitewater in order to accelerate the recovery of your production systems. To do so, enter the following: whitewater (config) # datastore prepop {[num-days <number of days>] | [pattern <pattern>] |...
  • Page 37: Tsm Server Recovery

    Note: If the Whitewater gateway storage capacity is less than the space used in the cloud, you can still initiate the recovery process. However, in this case the Whitewater gateway will only recover as much actual data as the size of its storage. If the recovery process attempts to bring back more data than the disaster recovery Whitewater can handle, then the recovery process might fail.
  • Page 38 Figure 44 Primary Volumes Destroyed File 4. If the Whitewater appliance at the production site was used as a copy storage pool with TSM, edit the DRM file COPYSTGPOOL.VOLUMES.AVAILABLE.MAC and adjust the Whitewater copy storage pool volume directory path to reflect the new IP addressing of the Whitewater interfaces available at the DR site.
  • Page 39: Production Systems Recovery

    Production Systems Recovery From this point forward, Whitewater and TSM are now configured as they were prior to the disaster, and you can now begin system restores of any production systems that need to be recovered at the DR site using normal TSM recovery strategies.
  • Page 40: Conclusion

    Riverbed is extending its industry-proven deduplication to cloud storage. Riverbed deduplication make replication more efficient than in the past by reducing the amount of data that is transferred. Now, the Whitewater gateway will extend those industry- leading deduplication capabilities to cloud storage, cutting the cost of data backup and disaster recovery by significantly reducing the capital and operational costs of storage consumed as well as the bandwidth requirements for moving backup data into and out of the cloud.

Table of Contents