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.
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.
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.
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.
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.
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: ...
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.
– 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.
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.
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.
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.
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.
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 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.
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.
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.
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).
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.
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.
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.
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.
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.
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).
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>] |...
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.
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.
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.
Need help?
Do you have a question about the Whitewater and is the answer not in the manual?
Questions and answers