Branch Office Windows File Server with Steelhead EX + Granite

DEPLOYMENT GUIDE

Branch Office Windows File Server with Steelhead EX + Granite Deployment Guide Riverbed Technical Marketing

Branch Office Windows File Server with Steelhead EX + Granite

© 2012 Riverbed Technology. All rights reserved. 2

© 2012 Riverbed Technology. All rights reserved. Riverbed®, Cloud Steelhead®, Granite™, Interceptor®, RiOS®, Steelhead®, Think Fast®, Virtual Steelhead®, Whitewater®, Mazu®, Cascade®, Cascade 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. All other trademarks used herein belong to their respective owners. The trademarks and logos displayed herein cannot be used without the prior written consent of Riverbed Technology or their respective owners. Akamai® and the Akamai wave logo are registered trademarks of Akamai Technologies, Inc. SureRoute is a service mark of Akamai. Apple and Mac are registered trademarks of Apple, Incorporated in the United States and in other countries. Cisco is a registered trademark of Cisco Systems, Inc. and its affiliates in the United States and in other countries. EMC, Symmetrix, and SRDF are registered trademarks of EMC Corporation and its affiliates in the United States and in other countries. IBM, iSeries, and AS/400 are registered trademarks of IBM Corporation and its affiliates in the United States and in other countries. Linux is a trademark of Linus Torvalds in the United States and in other countries. Microsoft, Windows, Vista, Outlook, and Internet Explorer are trademarks or registered trademarks of Microsoft Corporation in the United States and in other countries. Oracle and JInitiator are trademarks or registered trademarks of Oracle Corporation in the United States and in other countries. UNIX is a registered trademark in the United States and in other countries, exclusively licensed through X/Open Company, Ltd. VMware, ESX, ESXi are trademarks or registered trademarks of VMware, Incorporated in the United States and in other countries.



Table of Contents

Introduction ............................................................................................................................. 5

Audience .................................................................................................................................. 5

Additional Resources ................................................................................................................ 5

Granite Overview ..................................................................................................................... 6

Branch Office Data Backup Challenges ...................................................................................... 7

Granite Solution ....................................................................................................................... 7

Use Case: Branch Office Windows File Server with Steelhead EX + Granite ............................... 8

Deployment Prerequisites ........................................................................................................ 8

Reference Architecture ............................................................................................................. 9 Storage System ............................................................................................................................................................ 9 Granite Appliances ..................................................................................................................................................... 9 Steelhead Appliances ................................................................................................................................................ 9 ESX Server ..................................................................................................................................................................... 9 WAN simulator ............................................................................................................................................................ 9 Configure the LUNs at the Data Center ................................................................................... 10 Create the OS drive and file share LUNs on the NetApp storage system ........................................ 10 Create an aggregate .................................................................................................................................................................. 10 Create a volume ........................................................................................................................................................................... 12 Configure volume snapshot schedule ................................................................................................................................. 14 Enable iSCSI ................................................................................................................................................................................... 14 Create an iSCSI LUN ................................................................................................................................................................... 15

Install Microsoft Windows operating system into the OS drive LUN ............................................... 16 Associate the OS drive LUN to a ESX server located at the Datacenter .............................................................. 16 Import OS drive LUN into the data center ESX server ................................................................................................ 18 Deploy the Windows file server operating system on the NetApp iSCSI LUN ................................................... 21 Optionally install and configure the Riverbed Hardware Snapshot Provider ................................................. 23 Install and configure the Riverbed Turbo Boot plugin ............................................................................................... 24 Unmount the Windows file server OS drive LUN from the ESX Server ................................................................ 25 Unmount the Windows file server OS drive LUN from the NetApp storage system ....................................... 26

Map the OS drive and file share LUNs to the Granite Core appliance ............................................... 26 Create an Initiator Group for the Granite Core appliance ........................................................................................ 26 Map the OS drive and file share LUNs to the Granite initiator group ................................................................. 27

Configure the Granite Appliances ........................................................................................... 29 Configure Granite Edge ......................................................................................................................................... 29 Configure Granite Core ......................................................................................................................................... 30 Add Granite Edge appliance ................................................................................................................................................... 30 Add initiators ................................................................................................................................................................................ 31 Add iSCSI Portal ........................................................................................................................................................................... 31 Discover iSCSI targets ............................................................................................................................................................... 33 Add snapshot configuration ................................................................................................................................................... 33 Verify Snapshot configuration .............................................................................................................................................. 34



Expose the discovered LUNs to the Granite Edge appliance .................................................................................... 37 Execute a final check ................................................................................................................................................................. 39

Boot and Configure the virtual Microsoft Windows file server at the Branch Office ................ 40 Import OS drive LUN into the branch ESX server ..................................................................................... 40 Import the file share LUN in the branch Window file server ............................................................... 42 Enable Windows persistent bindings for the file share LUN .................................................................................... 45

Setup Data Protection ............................................................................................................ 48

Option #1: Granite Hardware Snapshots ................................................................................. 49 Configure Riverbed Granite hardware snapshots on the file share LUN ........................................ 49 Recover files from Riverbed Granite hardware snapshots at the branch ...................................... 49 Recover files from Riverbed Granite hardware snapshots at the data center .............................. 53 Recover files from media server backups at the data center ............................................................... 55 Recover files from NDMP backups at the data center ............................................................................. 55

Option #2: Windows Software Snapshots ............................................................................... 55 Configure Windows software snapshots on the file share LUN .......................................................... 55 Option #1: Set the shadow copies storage volume on the file share volume ................................ 56 Enable Shadow Copies .............................................................................................................................................................. 56

Option #2: Set the shadow copies storage volume on the local ESX datastore ............................ 58 Create a new storage volume to host the shadow copies .......................................................................................... 58 Enable Shadow Copies .............................................................................................................................................................. 60

Recover files from Windows software snapshots (Shadow Copies) ................................................. 62 Option #3: NetApp Snapshots ................................................................................................. 65 Configure NetApp snapshots on the file share LUN ................................................................................. 65 Recover files from NetApp snapshots at the data center ....................................................................... 65

Share the file share drive on the Windows file server ............................................................. 67

Enable Data Prepopulation ..................................................................................................... 69 Enable LUN Level Block Prepopulation ......................................................................................................... 69 Enable Folder Level Block Prepopulation .................................................................................................... 72

Conclusion .............................................................................................................................. 75

About Riverbed ...................................................................................................................... 75



Introduction This deployment guide describes how to deploy a Microsoft Windows file server in a branch office environment using Riverbed® Steelhead + Granite™ appliances in combination with a NetApp storage system and an ESX server. In summary this deployment guide describes how to: 1. Create, setup and configure the LUNs on a NetApp storage system located at the datacenter to host a

virtualized Microsoft Windows file server and its file share LUN. With steps on how to configure the LUNs on a NetApp storage system, install a virtualized Windows file server and map those LUNs to the Granite Core appliance.

2. Install and configure Riverbed Turbo Boot and Riverbed Hardware Snapshot provider on the Microsoft Windows file server. With steps and instructions on where to download the plugins and install them. Riverbed Turbo Boot allows for faster remote boot of the server. Riverbed Hardware Snapshot provider allows for end-to-end snapshot integration between the Microsoft Windows file server and the NetApp storage system.

3. Mount the LUNs on the Granite Core appliance, expose them to the Granite Edge appliance and configure initiators groups and optionally Granite block store encryption.

4. Boot and configure the virtualized Microsoft Windows file server at the branch office. Import the LUNs/ Datastore to the branch office ESX server, add the virtualized Microsoft Windows file to ESX inventory and power it up. Importing the remote file share using Microsoft iSCSI initiator, setup properties and share the LUN.

5. Configure snapshots schedule using Microsoft Windows Diskshadow utility in combination with the Riverbed Hardware Snapshot Provider.

6. Recover lost files at the branch office and at the data center using array-based snapshots and from NDMP backups.

Audience This paper is written for server, storage, backup and network administrators familiar with administering and managing distributed office environments using common network and storage protocols such as iSCSI, SCSI, TCP, CIFS, HTTP, FTP, and NFS. You must also be familiar with:

• Riverbed Steelhead® appliance installation and configuration process • Riverbed Steelhead management interface

Additional Resources For a complete list and the most current version of Riverbed documentation log in to the Riverbed support website located at https://support.riverbed.com. The Riverbed Knowledge Base is a database of known issues, how-to documents, system requirements, and common error messages. You can browse titles or search for key words and strings. To access the Riverbed Knowledge Base, log in to the Riverbed Support site located at https://support.riverbed.com.



Granite Overview Granite products enable users and applications in branch office locations to write to and access centrally managed storage while maintaining local disk performance. By accelerating branch access to data center deployed Storage Area Networks (SANs), IT organizations no longer need to provision and maintain dedicated storage resources in branch offices. The Granite solution is deployed in conjunction with Steelhead appliances and consists of two components:

• Granite Core – a physical or virtual appliance that resides in the data center alongside centralized storage

• Granite Edge – a module that runs on a Steelhead EX appliance in the branch office Granite Core mounts iSCSI LUNs provisioned in the data center and shares the storage resources with branch offices running the Granite Edge module. Granite Edge virtually presents one or more iSCSI targets in the branch which can be utilized by services and systems running both within the Riverbed Virtual Services Platform (VSP) as well as externally to the Steelhead EX appliance. Granite Core inspects mounted file systems and is able to proactively stream data to the branch locations utilizing innovative block-level prediction algorithms. This industry-first capability allows data from centralized storage to be available wherever and whenever it is needed. Through asynchronous block-based write acceleration, Granite Edge ensures that data created in branch office locations is securely stored in the data center.

Figure 1: Granite Core and Granite Edge high level network topologies



Branch Office Data Backup Challenges Geographically distributed organizations face major challenges managing their remote office and branch office storage needs, whether they decide to store the data locally or at the data center. Today more than ever they are experiencing an explosion in data growth, together with a request to improve their backup and recovery processes, while containing storage costs and keeping the data secure. On top of that, growing concerns include having adequate lab space for all the storage and IT gear and finding qualified IT personnel with the appropriate storage skills to manage and configure it. Today’s solutions to these challenges vary depending on the size, the distance, and the geographical location of these remote branch offices leaving IT storage administrators to implement a variety of different approaches. One approach for example is to back up the data locally. This approach provides fast recovery but requires deploying expensive and complicated to manage storage arrays and/or backup tapes at the branch and does not provide geographical disaster recovery protection. Moreover maintaining tapes and running backup agents is fragile and error prone. Another approach is to centrally back up branch data to the data center. While this approach provides geographical disaster recovery protection, it requires expensive data replication software and/or licenses and will slow down the data recovery process in the event of a disaster it requires a restore of all the data back to the branch office before you can resume operations.

Granite Solution With the Granite solution, data is consolidated in the data center where backup can be done centrally and where skilled IT storage personnel resides and can manage and configure the storage and deal with any unforeseen issues. This eliminates the need for data backup or replication software and hardware in the branch. In case of disaster, data can be streamed on the fly resuming operation in the order of minutes. Moreover Granite products work with both traditional backup and advance array-based snapshot methodologies.



Use Case: Branch Office Windows File Server with Steelhead EX + Granite A typical use case for file server implementation in a branch office environment using Steelhead EX + Granite appliances is when a customer has file sharing needs at many remote sites and wants to have local performance, 100% uptime even during WAN outages, and wants to constantly protect the data at a centralized location in case of disaster at any of the branch offices. The ability to centrally provision new file servers, new file shares, centrally perform regular backups and centrally monitor the overall infrastructure is also an important aspect of this use case.

Figure 2: Topology for ABC corporation with remote file servers

Deployment Prerequisites • A NetApp storage system with a valid iSCSI license • A NetApp storage system with a valid FlexClone license, if the user intends on taking Volume Snapshot

Service (VSS) snapshots • Administrator access to the NetApp storage system and Granite appliances to make changes such as

enabling iSCSI, adding initiator groups, etc. • Granite Core and Granite Edge appliances installed and powered up.



Reference Architecture Figure 3 shows the reference architecture and the topology that was configured and tested to develop this deployment guide.

Figure 3: Reference architecture

Storage System The storage system used was a NetApp FAS2050 storage system.

Granite Appliances The Granite Core appliance used was virtual Granite Core VGC-1000-M running software version 1.0.1. The Granite Edge appliance used was physical Steelhead EX 560 + Granite license running:

• Steelhead EX software version 1.0.2 • RiOS software version 7.03 • Granite Edge software version 1.0.1

Steelhead Appliances The datacenter Steelhead appliance was Steelhead 550M running RiOS software version 7.0.0.

ESX Server The ESX server was a general-purpose x86 platform running VMware software version 5.0.

WAN simulator The WAN simulator was operating as a T1 (1,5 Mbps) link with 100 milliseconds round-trip delay and was connecting the branch office and data center setups.



Configure the LUNs at the Data Center Create the OS drive and file share LUNs on the NetApp storage system On the NetApp storage system located at the datacenter create 2 LUNs. One LUN will be used to host the Windows file server operating system drive and one LUN will be use to host the file share. To be able to create a LUN, first create an aggregate and then create a FlexVolume. Note: FlexVolume and FlexClone license are required if you intend on taking VSS snapshots using the Riverbed Hardware Snapshot Provider. Create an aggregate 1. To create an aggregate, open aggregates from the left menu of NetApp FilerView, select add to open

the aggregate wizard, and select Next to start the wizard, as shown in Figure 4.

Figure 4: Aggregate create window

2. Name the aggregate and enable double parity to enable protection against double disk failures, as

shown in Figure 5.

Figure 5: Aggregate parameters window

3. Create the RAID group with the default size of 16 for FCAL drives and 14 for ATA drives (including 2

parity disks). This provides an optimal level of performance with increased resiliency against multiple drive failures, as shown in Figure 6.



Figure 6: Raid parameters window

4. Allow Data ONTAP to select disk type and size automatically.

5. Create the largest aggregate possible. Try to maximize the number of disks in any aggregate, especially

during the creation of the aggregate and when you have a good idea about the amount of data to be stored on this aggregate. This maximizes the performance (random read throughput) available to the aggregate and allows all the storage provisioning benefits of the flexible volumes to be realized, as shown in Figure 7.

Figure 7: Number of disk window

6. Commit the aggregate to the system, as shown in Figure 8.

Figure 8: Aggregate commit window

7. Verify the aggregate creation in the Manage Aggregate window, as shown in Figure 9. A refresh of the

window may be necessary.

Figure 9: Manage aggregates window



Create a volume 1. A NetApp Data ONTAP software creates volumes from aggregates. Volumes are easily created,

exported, and mounted onto servers using CIFS and NFS or LUNs. To create a volume, open volumes from the left menu of FilerView and select add to open the volume wizard. Select Next to start the wizard, as shown in Figure 10.

Figure 10: Manage volumes window

2. Choose volume type in the Volume Type window. Select Flexible over Traditional to create a

FlexVolume and later use the Riverbed Hardware Snapshot Provider (RHSP), as shown in Figure 11.

Figure 11: Volume type window

3. Name the volume in the volume parameters window and select the other settings following NetApp best

practices.

Figure 12: Volume parameters window



4. Assign the volume to the previously created aggregate in the flexible volume parameters window and

select the other settings following NetApp best practices, as shown in Figure 13.

Figure 13: Flexible volume parameters window

5. Set the volume size in the flexible volume size window. Total size will create the volume to the exact

specifications set, while usable size will increase the volume size to enable disk space overhead. Set the snapshot reserve following NetApp best practices, as shown in Figure 14.

Figure 14: Flexible volume size window

6. Commit the Volume to the system, as shown in Figure 15.

Figure 15: Volume commit window

7. Verify volume creation in the FilerView Manage Volumes window, as shown in Figure 16.

Figure 16: Manage volume window



Configure volume snapshot schedule By default NetApp Data ONTAP software automatically creates a snapshot schedule: one nightly snapshot copy Monday through Saturday at midnight, and four hourly snapshot copies at 8 a.m., noon, 4 p.m., and 8 p.m. Data ONTAP retains the two most recent nightly snapshot copies and the six most recent hourly snapshot copies, and deletes the oldest nightly and hourly copies when new copies are created. Note: These automatically generated snapshot copies are only crash-consistent since there is no coordination with the branch office application or operating system. To obtain application-consistent snapshot copies the Riverbed Hardware Snapshot Provider must be installed in the branch office file server and the Granite Core appliance needs to be configured. To change a volume snapshot schedule navigate to Volumes -› Snapshots -› Configure, as shown in Figure 17.

Figure 17: Configure snapshots window Enable iSCSI iSCSI is enabled in the Enable/Disable LUNs window found in the left menu of FilerView. Select LUNs › Enable/Disable to find the enable check-box, select it and click apply, as shown in Figure 18.

Figure 18: Enable iSCSI window



Create an iSCSI LUN LUNs are created from volumes. LUNs are managed in the manage LUNs window found in the left menu of FilerView. Select LUNs › Manage to find the LUNs, LUNs description, and associated initiator groups

Figure 19: Manage LUN window Click on Add New LUN to create a new LUN, as shown in Figure 19, and configure the LUN with the following parameters, as shown in Figure 20 and Figure 21:

• Path: <type the full path of the LUNS>. In this reference architecture the paths were /vol/NewYorkWindowsFiler/OSdrive for the OS drive LUN and /vol/NewYorkWindowsFiler/fileshare for the file share LUN.

• LUN Protocol type: <choose VMware for the OS drive LUN and Windows for the file share LUN> • Description: <An optional description of the LUN>. • Size/Units: < Set the LUN size for the OS drive LUN and the file share LUN in accordance with your

requirements>. In this reference architecture we choose 20GB for the OS drive LUN and 60 GB for the file share LUN.

• Space Reserved: <Select the checkbox>. And click the Add button to commit the operation.

Figure 20: OS Drive LUN

Figure 21: File Share LUN



Install Microsoft Windows operating system into the OS drive LUN Associate the OS drive LUN to a ESX server located at the Datacenter NetApp Data ONTAP software uses initiator groups to group to map LUNs according to the parameters of the environments or servers they serve. 1. From the left menu of FilerView select LUNs › Initiator Groups › Add to open the add initiator group

window and create an initiator group. Configure with the following parameters, as shown in Figure 22:

• Initiator Group name: <this is how you want to name the initiator group>. In this reference architecture we named it ESX.

• Initiator Group type: <choose iSCSI>. • Operating System type: <choose VMware>. Since the LUN will be used as a VMware ESX

Datastore to host the file server OS drive. • Initiators: <insert the ESX server IQN name>. In this reference architecture the ESX server IQN

name was iqn.2003-10.com.riverbed:esx.

Click on the Add button to commit the operation.

Figure 22: Initiator group window

2. For a LUN to be activated and made accessible to the ESX server, it must be added to the Initiator

Group. Select the LUN and click on the No Maps link, as shown in Figure 23.

Figure 23: LUN mapping link



3. Click on Add Groups to Map link and click on the Apply button to confirm the operation, as shown in Figure 24.

Figure 24: Apply LUN mapping

4. Select the previously created ESXServer group and click on the Add button, as shown in Figure 25.

Figure 25: Select initiator group window

5. Commit the operation by clicking the Apply button, as shown in Figure 26.

Figure 26: Apply LUN mapping

6. Verify that the LUN has now the ESXServer Group associated to it, as shown in Figure 27.

Figure 27: LUN initiator group mapping



Import OS drive LUN into the data center ESX server 1. To import the OS drive LUN into the ESX server navigate to the Configuration tab and open the

Properties window from the left Storage Adapters menu of VMware vSphere client, as show in Figure 28.

Figure 28: ESX iSCSI Configuration

2. Navigate to the Dynamic Discovery tab of the iSCSI Initiator Properties window, click on the Add…

button to enter the IP address of the NetApp storage array into the iSCSI Server field, as show in Figure 29.

Figure 29: Add iSCSI Portal



3. Close the window, answer Yes to the request coming from the VMware ESX server to rescan the host

bus adapter, as shown in Figure 30.

Figure 30: Host Bus Adapter Rescan

4. Navigate to the Storage menu of the ESX server Configuration tab, click on the Add Storage… link to

open the Add Storage wizard, as show in Figure 31.

Figure 31: Add Storage



5. Follow the wizard and as Storage Type select Disk/LUN and as File System Version select VMFS-3, click on the Finish button to complete the operation, as shown in Figure 32.

Figure 32: Create Datastore



Deploy the Windows file server operating system on the NetApp iSCSI LUN The ESX server should now show a new Datastore, as shown in Figure 33.

Figure 33: NetApp iSCSI LUN Datastore Deploy a Windows server virtual machine into this new Datastore. One way to do it is to deploy an OVA file. To do so from the ESX Server file menu select Deploy OVF Template…, browse to the location of the OVA file and follow the wizard. Make sure you select the newly added NetApp iSCSI LUN Datastore as virtual machine location, and for disk format Thin Provision is recommended.

Figure 34: OVA deployment wizard



When the deployment process is finished you can power up the virtual file server, install any patches needed and install the Riverbed Hardware Snapshot Provider and the Turbo Boot plugin.

Figure 35 Power on the virtual server



Optionally install and configure the Riverbed Hardware Snapshot Provider These steps are only required if you intend on using the Riverbed Granite snapshots feature. If you will be using Microsoft Windows shadow copies or NetApp snapshots you can skip steps 1 and 2. 1. Download the Riverbed Hardware Snapshot Provider plugin from the Riverbed support website located

at https://support.riverbed.com and install it on the Windows file server virtual machine, as shown in Figure 36.

Note: RHSP uses TCP Port 4000 to communicate with Granite Edge.

Figure 36: RHSP install wizard

2. Verify that the Riverbed Hardware Snapshot Provider is installed and registered by executing the list

providers command from the Microsoft Windows diskshadow utility, as show in Figure 37.

Figure 37: Verify Riverbed Snapshot Hardware Provider Install



Install and configure the Riverbed Turbo Boot plugin 1. Download the Riverbed Turbo Boot plugin from the Riverbed support website located at

https://support.riverbed.com and install it on the Windows file server virtual machine, as shown in Figure 38.

Figure 38: Turbo Boot plugin install wizard

Figure 39: Turbo Boot Install completed

2. Reboot the virtual server. During the reboot process the Riverbed Turbo Boot software will learn all the blocks needed for the operating system to boot and the system will be ready for a fast boot across the WAN later.



Unmount the Windows file server OS drive LUN from the ESX Server After the virtual Windows file server comes up you can power it down, remove it from the ESX server inventory, and unmount the datastore. 1. To remove the virtual Windows file server from the inventory right click on the virtual machine name and

click on Remove from Inventory link (don’t click on Delete from Disk link), as shown in Figure 40.

Figure 40: Remove from inventory

2. To unmount the datastore, navigate to the ESX server Configuration tab, click on the Storage menu,

right click on the FileServerOSdrive datastore and click on the Unmount link, as shown in Figure 41.

Figure 41: Unmount datastore window



Unmount the Windows file server OS drive LUN from the NetApp storage system Unmount the LUN from the NetApp storage system so that the Granite Core appliance can mount it. To unmount the LUN navigate to the LUN > Map LUNs window and check the Unmap check box, as shown in Figure 42.

Figure 42: LUN unmap window

Map the OS drive and file share LUNs to the Granite Core appliance Create an Initiator Group for the Granite Core appliance Like for the ESX server create an initiator group for the Granite Core appliance. Note: at the iSCSI level Granite Core is an iSCSI initiator. 1. To create an initiator group, from the left menu of FilerView select LUNs › Initiator Groups › Add to

open the add initiator group window. Configure with the following parameters, as shown in Figure 43:

• Initiator Group name: <this is how you want to name the initiator group>. In this reference architecture we named it GraniteCore1.

• Initiator Group type: <choose iSCSI>. • Operating System type: <choose Windows>. • Initiators: <insert the Granite Core IQN name>. In this reference architecture the Granite Core IQN

name was iqn.2003-10.com.riverbed:core1 Click on the Apply button to commit the operation.



Figure 43: Initiator group for Granite Core

Map the OS drive and file share LUNs to the Granite initiator group 1. Select the OSdrive LUN and click on the No Maps link, as shown in Figure 44.

Figure 44: LUN mapping window

2. Click on the Add Groups to Map link to continue with the mapping, as shown in Figure 45.

Figure 45: Add groups to map link

3. Select the previously created GraniteCore group and click on the Add button, as shown in Figure 46.



Figure 46: Select Granite Core group

4. Click the Apply button to commit the operation, as show in Figure 47.

Figure 47: Complete the mapping

5. Verify that the LUN has now the Granite Core initiator group associated to it, as shown in Figure 48.

Figure 48: Verification window

6. Repeat these steps and add the fileshare LUN. Verify that both LUNs are associated to the Granite

Core initiator group, as shown in Figure 49.

Figure 49: Final configuration check



Configure the Granite Appliances Configure Granite Edge From the Steelhead EX + Granite web user interface, go to Configure › Branch Storage and configure with the following parameters:

• Hostname: <the Granite Core ip address> • Granite Edge Identifier: <This is how you want to name the Granite Edge device>. In this

reference architecture we named it EdgeNewYork. Please remember this identifier (case sensitive), you will need to enter it again in the Granite Core configuration page.

• Port: 7970 (Leave the default 7970 port) • Network Interface: <Select Primary or In_Path based on you network configuration>. Take a look

at the Granite Best Practices Guide for more information. Click on the Add Core button to commit the operation.

Figure 50: Granite Edge branch storage configuration tab

Note: the Granite Core appliance will currently show as Not Connected, and the Granite Edge health state will be Degraded. This will change when you complete the dependencies on the Granite Core.

Figure 51: Granite Edge showing granite Core in Not Connected state



Configure Granite Core In the Granite Core appliance execute these 4 steps: 1. Add the Granite Edge Appliance 2. Add NetApp Storage to Granite Core 3. Discover the NetApp iSCSI target and its LUNs on the Granite Core appliance 4. Expose the discovered LUNs to the Granite Edge appliance Add Granite Edge appliance Go to the Granite Core web user interface, navigate to Configure › Storage › Granite Edges and click on Add a Granite Edge. Enter the following parameters:

1. Granite Edge Identifier: <type EdgeNewYork>. Remember we chose this name in the previous section (this field is case sensitive).

2. Blockstore Encryption: <select the desired encryption Level>. In this reference architecture we chose AES 256 bit key.

Click on Add Granite Edge button to commit the operation.

Figure 52: Granite Core Add Edges configuration tab

If the Granite Core appliance is able to discover the Granite Edge appliance the screen should display the newly added device showing Connected and the Granite Edge’s device IP address, as shown in Figure 53.

Figure 53: Granite Edge and Core appliances connection



Add initiators Add the initiators IQN names of the ESX server that will access the OS drive LUN and of the Windows file server that will access the file share LUN at the branch office. 1. Navigate to Configure › Granite Edges, under the EdgeNewYork section click on the Initiators tab

and click on the Add an Initiator button. 2. Type the Branch ESX Server Initiator name: iqn.2003-10.com.riverbed:newyorkbranchesx and click

on the Add Initiator button to commit the operation, as shown in Figure 54.

Figure 54: Add Initiator

3. Repeat the procedure to add the initiator name of the virtual Windows file server: iqn.1991-

05.com.microsoft:newyorkbranchwindows Add iSCSI Portal The iSCSI portal is usually the storage device’s IP address and TCP port pair. Adding an iSCSI portal to a Granite Core appliance will cause the Granite Core appliance to discover the targets and LUNs behind the portal. Note: By default all Granite Core appliances are configured with the same IQN name of iqn.2003-10.com.riverbed:core. IQN names are identifiers used to distinguish each iSCSI initiator. Edit the Granite Core Initiator name to make it unique across the network. 1. Navigate to Configure › Storage › iSCSI Configuration and modify the Initiator name. In this reference

architecture we changed it to iqn.2003-10.com.riverbed:core1.

Click on Apply button to commit the operation. 2. Expand Add an iSCSI Portal link and enter the IP Address of the NetApp iSCSI target. Click on the

Add an iSCSI Portal button, as shown in Figure 55.



Figure 55: iSCSI Portal configuration

If the Granite Core appliance is successful in logging into the NetApp storage system the IP of the NetApp will have a No Targets Added status, as shown in Figure 56.

Figure 56: iSCSI Portal Ready state



Discover iSCSI targets Execute these two step to add the storage system iSCSI target information to the Granite Core appliance. 1. Expand the iSCSI Portal and expand Add a Target tab. 2. Choose the target name from the combo box. Add snapshot configuration These steps are only required if you intend on using the Riverbed Granite snapshots feature. If you will be using Microsoft Windows shadow copies or NetApp snapshots you can skip steps 1 and 2.

1. Click on the Add new Snapshot Configuration link and fill in the required fields. 2. Click on Add Target button, as shown in Figure 57.

Figure 57: Add iSCSI target If the Granite Core appliance is able to discover the iSCSI target and connect with the NetApp storage system snapshot process the screen should display all green statuses, as shown in Figure 58.

Figure 58: Target discovery tab



Note. FlexClone license needs to be installed for snapshots to work and Granite Core will not check to see if the FlexClone license is installed. Verify Snapshot configuration Verify that Granite Core can take snapshots initiating a temporary debug snapshot and then remove it. 1. On the Granite Core web user interface locate the serial number of the file share LUN, as shown in

Figure 59.

Figure 59: Locate LUN serial number 2. On the Granite Core command line interface execute the following command to trigger a temporary

debug snapshot on the NetApp storage system:

Granite Core (config)# storage snapshot debug "-s {LUN SERIAL NUMBER} -u {USER NAME} -w {PASSWORD} -f {STORAGE SYSTEM HOSTNAME} -t {STORAGE SYSTEM TYPE: netapp | emc | eql} -o snap"

3. Verify that the command returns status OK and a snapshot gets created on the storage system, as

shown in Figure 60. Note down the serial number returned by the command, you will need it later to remove this snapshot LUN.

Figure 60: Snapshot creation command



4. Remove the temporary snapshot issuing the following command:

Granite Core (config)# storage snapshot debug "-s {NEW SERIAL NUMBER} -u {USER NAME} -w {PASSWORD} -f {STORAGE SYSTEM HOSTNAME} -t {STORAGE SYSTEM TYPE: netapp | emc | eql} -o remove "

5. Verify that the command returns status OK and a snapshot gets removed from the storage system, as

shown in Figure 61.

Figure 61: Snapshot remove command



Discover LUNs 1. Navigate to Configure › Storage › LUNs and click on the Add an iSCSI LUN button. 2. From the LUN Serial Number dropdown choose the previously configured LUNs 3. Enter a LUN Alias (The alias name will be used to identify this LUN as opposed to using the serial # of

the LUN provided by the NetApp storage system), In this reference architecture we used OSDrive and Fileshare.

4. Click on the Add iSCSI LUN button.

Figure 62: OSDrive LUN configuration example

Figure 63: Fileshare LUN configuration example



Expose the discovered LUNs to the Granite Edge appliance After the LUNs have been added, map them to the Granite Edge appliance. 1. Navigate to Configure › Storage › Granite Edges and click on the Map LUNs to Granite Edge button.

The aliases of the LUNs created in previous step should appear. 2. Click on the aliases and hit the Map these LUNs button, as shown in Figure 64.

Figure 64: Map LUNS to Granite Edge appliance

By default LUN access is denied to all iSCSI initiators at the branch. Modify the access list to allow access. 1. After the LUNs are mapped the access-list configuration should come up, click on Edit for the Initiators

Granted Access box.

Figure 65: Modifying access list



2. On the OS drive LUN add access to the Branch ESX server by highlighting its IQN name in the Not Granted section and clicking on the Add button to move it into the Initiator Granted Access section, as shown in Figure 66.

Figure 66: Granting Access to OS drive LUN

3. On the file share LUN add access to the branch virtual Windows file server by highlighting its IQN name

in the Not Granted section and clicking on the Add button to move it into the Initiator Granted Access section, as shown in Figure 67.

Figure 67: Granting access to file share LUN

Now the Granite Edge appliance will expose the LUN to the branch office Initiators/Servers connected to it. 4. Navigate to Configure › Granite Edges › EdgeNewYork and verify that the Accessible column shows

Yes for both the LUNs, as shown in Figure 68.



Figure 68: LUNs accessible state Execute a final check Go back to the Steelhead EX + Granite web user interface and navigate to Configure › Branch Storage and verify that the Granite appliances are now connected and LUNs are exported, as shown in Figure 69.

Figure 69: Granite Edge appliance view



Boot and Configure the virtual Microsoft Windows file server at the Branch Office Import OS drive LUN into the branch ESX server 1. Follow the same steps performed in the “Import OS Drive LUN into the Datacenter ESX Server”

section of this deployment guide to import the Microsoft Windows File Server OS drive datastore into the branch ESX server. This time, use the Steelhead EX + Granite IP address as iSCSI server location in the iSCSI Initiator Properties windows of the branch ESX server, as shown in Figure 70.

Figure 70: Import OS drive LUN

2. Navigate to the Storage menu of the ESX server Configuration tab and click on Add Storage… to

open the Add Storage wizard, as show in Figure 71.

Figure 71: Storage configuration tab



3. In the Mount Options step select the Keep the existing signature checkbox and click on the Next

button, as shown in Figure 72. Note: Select Assign a new signature if you are using at the branch the same Vcenter server that you used in the datacenter to deploy this VMDK.

Figure 72: VMFS mount options 4. Click on the Finish button to complete the Datastore import. 5. Next, right click on the FileServerOSdrive datastore to browse it and add the Windows File Server

OS .vmx file to the inventory, as shown in Figure 73.



Figure 73: Add virtual machine to inventory

6. Boot the virtual Windows file server in the branch office, as shown in Figure 74.

Figure 74: Virtual machine boot

Import the file share LUN in the branch Window file server 1. On the virtual windows file server open Computer Manager by right clicking on the My Computer icon

and by clicking on Manage. Click on Disk Management and verify that only the internal hard drive is listed. See Figure 75.



Figure 75: Disk Management internal drive only

2. To launch Windows iSCSI initiator software simply type iscsi on the search bar and click on the iSCSI

Initiator software. Add the Steelhead EX + Granite appliance IP address (iSCSI portal information) by clicking on the Discovery Portal button and click OK, as shown in Figure 76.

Figure 76: Add Granite Edge appliance iSCSI Portal IP address

3. Login to the Granite Edge appliance iSCSI target, by clicking on the Targets tab, selecting the target

name and clicking the Connect button, as shown in Figure 77.



Figure 77: Target Login

Automatically Windows OS will discover the NetApp storage system file share LUN exported via Granite solution and will display it on the Computer Manager software, as shown in Figure 78.

Figure 78: Windows LUN Discovery



Enable Windows persistent bindings for the file share LUN It is recommended to make the file server iSCSI LUN persistent across reboots otherwise manual reconnection every time the server reboots. To configure the Windows server to automatically connect to the file server LUNs after system reboots, choose the Add this connection to the list of Favorite Targets check box when you connect to the Granite Edge iSCSI target, as shown on Figure 79

Figure 79: Favorite Targets To make Granite iSCSI LUNs persistent and make sure that Windows does not consider the iSCSI service fully started until connections are restored to all the Granite volumes on the binding list, add the Granite Edge iSCSI target to the iSCSI service's binding list. This is important since this LUN contains that other services depend on. The best option is to choose the Volumes and Devices tab from the iSCSI Initiator's control panel and click the Auto Configure button, as shown on Figure 80. This will bind all available iSCSI targets to the iSCSI startup process. If you want to choose individual targets to bind, click the Add button.

Figure 80: Target Binding



4. To continue importing the file share LUN first bring the LUN Online, as shown in Figure 81.

Figure 81: LUN online

5. Initialize the unknown disk, as shown in Figure 82.

Figure 82: Initialize disk

6. Create a simple volume, assign a drive letter, format the volume, and select explore to start using the

LUN, as shown in Figure 83.

Figure 83: Explore iSCSI LUN



7. Right click on the file share volume and select Explore to browse the newly mounted remote iSCSI

drive, as shown in Figure 84.

Figure 84: Explore iSCSI LUN



Setup Data Protection Data protection on the file share drive can be setup using these 3 different but not mutually exclusive ways: 1. Using Riverbed Granite hardware snapshots 2. Using Microsoft Windows software snapshots 3. Using NetApp storage system snapshots The following table lists the advantages and disadvantages of the three different approaches:

Advantages Disadvantages Riverbed Granite hardware snapshots

• Tight integration with storage array snapshots.

• File server is offloaded from taking snapshot.

• Extra disk not used for the shadow copies volume.

• Application consistent snapshots/backups at the branch and at the datacenter.

• No GUI based configuration in the windows file server.

• Configuration required on the Granite Appliances and Storage array.

• Only admin can recover lost files, however both admins at the branch and at the datacenter can.

Microsoft Windows software snapshots

• Simple GUI based configuration in the windows file server.

• No configuration required on the datacenter storage array.

• Users can recover lost files without admin intervention.

• Performance impact on the file server.

• Extra space on disk for shadow copies.

• Higher WAN utilization If the shadow copies volume is located on Granite LUN, but shadows copies will be present at the datacenter too.

• Shadow copies volume unprotected if kept on local ESX server disk, but zero impact on WAN utilization.

NetApp storage system snapshots

• No configuration required in the windows file server.

• No plugin to install.

• Recovery requires storage administrator at the datacenter intervention.

• Backups /Snapshots will be crash-consistent.



Option #1: Granite Hardware Snapshots Configure Riverbed Granite hardware snapshots on the file share LUN Since the Riverbed Hardware Snapshot Provider is already installed, Granite appliances and NetApp storage array are already configured for snapshots hardware support simply configure a schedule on the Windows file server to take periodic snapshots using the diskshadow utility. 1. First, create a simple text file (name it, for example, take_snaps.txt) with these Diskshadow commands:

begin backup add volume e: set context persistent create end backup delete shadows oldest e: exit

2. Second, create a .bat script (name it, for example, snap.bat) to run the Diskshadow commands in

take_snap.txt:

diskshadow /s take_snaps.txt /l C:\snap.log 3. Third, schedule the .bat script (snap.bat) to run on desired intervals. This procedure will create a new snapshot for e: drive and delete the oldest snapshot of e: drive. So, assuming you started using the script when you have N snapshots for the e: drive, you will have last N snapshots in the system. For more Information please refer to Microsoft Knowledge Base article: Diskshadow

Recover files from Riverbed Granite hardware snapshots at the branch Since the snapshots are taken at the branch using the Windows Volume Snapshot Service (VSS) in conjunction with the Riverbed Hardware Snapshot Provider (RHSP) VSS plugin, then each snapshot is available not only at the data center but also to the Windows file server as a separate drive. To recover a lost file, just browse to the drive associated to the desired snapshot, locate the file and restore it.

Figure 85: Recovery from Branch Snapshots



Consider, for example, that the test1.txt file has been mistakenly deleted and needs to be recovered as shown in Figure 86.

Figure 86: test1 file lost 1. To recover the file, locate the drive snapshot containing the deleted file, mount it as a new drive and

assign a new drive letter by clicking on the Change Drive Letter and Path… link as shown in Figure 87.

Figure 87: Mount snapshot drive



2. Click on add button, as shown in Figure 88.

Figure 88: Add drive letter

3. Assign a new drive letter by selecting the Assign the following drive letter check box and by selecting

and available letter on the dropdown menu, as shown in Figure 89.

Figure 89: Select drive letter

4. Explore the newly added drive by right clicking on the disk and selecting the Explore link, as shown in

Figure 90.

Figure 90: Explore snapshot drive



5. Copy the deleted file back to the E: drive, as shown in Figure 91.

Figure 91: Recover deleted file from Granite Edge snapshots



Recover files from Riverbed Granite hardware snapshots at the data center To recover the file from the NetApp storage system snapshots, present the snapshot to a Windows file server located at the data center and then browse the file system to retrieve the file.

Figure 92: Recovery from data center snapshot

Consider, the same example as in the previous section where the test1.txt file has been mistakenly deleted as shown in Figure 86, and needs to be recovered. 1. On the NetApp storage system use the snap list [vol_name] cmd to list the snapshots in the storage

array and locate the snapshot that contains the lost file, as shown in Figure 93.

Figure 93: Snapshot list

2. Locate the LUN clone snapshot in the NetApp web user interface by opening the Manage LUN window,

as shown in Figure 94.



Figure 94: LUN clone snapshot

3. Select the LUN and map it to a datacenter windows server, as shown in Figure 95.

Figure 95: LUN mapping

4. Recover the delete file by mounting the LUN on the data center windows file sever as described in the

previous sections.



Recover files from media server backups at the data center If the data center snapshots were backed up by a backup application via media server, as shown in Figure 96, recover the file from the tape by simply using the backup application to restore the file from the backup catalog. The media server would have mounted the snapshots and would have had access to all the files for backup purposes. Note that this is probably the most common version of backup practice. For more information follow the instructions from the backup application vendor.

Figure 96: Media server backup

Recover files from NDMP backups at the data center If the data center snapshots were backed up through (Network Data Management Protocol) NDMP, direct restore of individual files contained inside the LUN is not possible because the LUN is seen as a single large file. To recover the file perform a redirected restore of the LUN and then access the redirected LUN via a datacenter windows server and manually recover the file.

Option #2: Windows Software Snapshots Configure Windows software snapshots on the file share LUN Windows software snapshots (Volume Shadow Copies) can also be enabled at the branch on the file share LUN. When using Volume Shadow Copies the administrator and the users can right click on the shared drive, navigate to the previous version tab and recover deleted, damaged or overwritten files. Windows will use its default VSS software provider (instead of the Riverbed hardware service provider) and will backup up to the previous 64 versions of each file. The shadow copy system requires at least 300 MB of available space, however the total amount of space required will depend on the size of the LUN which is to be shadowed and the frequency and extent to which the files are likely to change (Microsoft recommends 10% of the size of the source volume). When the storage limit is reached, older versions of the shadow copies will be deleted. In addition to restoring individual files to a previous version, shadow copy also provides the ability to restore an entire volume. The shadow copies storage volume can reside on the on the file share volume exported via Granite appliances or on a local ESX datastore. Setting the shadow copies storage volume on file share volume results in higher WAN and Granite block store utilization but it has the advantage of backing up the shadow copies to the datacenter instead of leaving them unprotected in the branch. If WAN and Granite block store usage is of concern set the shadow copies storage volume on a local ESX datastore.



Option #1: Set the shadow copies storage volume on the file share volume Enable Shadow Copies 1. Right click on the file share volume in the Disk Management snap-in details pane and click on

Properties, as shown in Figure 97.

Figure 97: Open disk properties

2. Select the Shadow Copies tab and click on the Settings button to further limit the maximum size of the

shadow copies disk space, as shown in Figure 98.

Figure 98: Shadow copies settings



3. Adjust the maximum size limit as shown in Figure 99 and click the OK button.

Figure 99: Adjust maximum size

4. Complete the setup by clicking on the Enable button, as shown in Figure 100.

Figure 100: Enable shadow copies

Note: By enabling Shadow Copies of Shared Folders, Windows also create a default schedule and settings for subsequent shadow copies. To make changes to these defaults, click the Settings button.



Option #2: Set the shadow copies storage volume on the local ESX datastore Before you can set shadow copies storage volume on the local ESX datastore you need to create one. Create a new storage volume to host the shadow copies To create a new storage volume to host the shadow copies add a new hard disk to the virtual Windows file server. 1. From the ESX server Virtual Machine Properties window click on the Add… button, as shown in

Figure 101.

Figure 101: Add device

2. Select Hard Disk and click on the Next button as shown in Figure 102.

Figure 102: Select hard disk

3. Complete the wizard entering the following parameters:

• Disk: Create a new virtual disk • Disk Size: <expected size of storage volume>. Windows 2003 Server requires at least 300. The

default storage size is 10% of the size of the source volume (the file share drive). • Disk Provisioning: <select any of the choices> • Location: <select the local ESX server datastore> • Virtual Device Node: <leave default option>



And click on the Finish button to commit the operation. 4. Bring the volume online, initialize it, create a new simple volume, assign a drive letter and format the

disk. In this reference architecture drive letter F: was assigned to the shadow copies storage volume, as shown in Figure 103.

Figure 103: Shadow copies storage volume



Enable Shadow Copies 5. Right click on the file share volume in the Disk Management snap-in details pane and click on

Properties, as shown in Figure 104.

Figure 104: Open disk properties

6. Select the Shadow Copies tab and click on the Settings button to specify the location of the shadow

copies storage volume, as shown in Figure 105.

Figure 105: Shadow copies settings



7. Select the newly create volume, remove the maximum size limit as shown in Figure 106 and click the

OK button.

Figure 106: Select storage volume

8. Complete the setup by clicking on the Enable button, as shown in Figure 106.

Figure 107: Enable shadow copies

Note: By enabling Shadow Copies of Shared Folders, Windows also create a default schedule and settings for subsequent shadow copies. To make changes to these defaults, click the Settings button.



Recover files from Windows software snapshots (Shadow Copies) Consider, the same example as in the previous section where the test1.txt file has been mistakenly deleted as shown in Figure 108, and needs to be recovered.

Figure 108: test1.txt file lost 1. To recover the deleted file, navigate to the folder in which the deleted file had been stored, position the

cursor over a blank space in the folder and right-click the mouse, as shown in Figure 109.

Figure 109: Right click to recover



2. Select Properties from the bottom of the menu and click on the Previous Versions tab, as shown in Figure 110.

Figure 110: Previous version tab

3. Select the version of the folder that contains the file before it was deleted, and then click Open, as

shown in Figure 111.

Figure 111: Open previous version



4. View the folder and select the file to recover. Copy the shadow copy of the file back to the E: drive, as shown in Figure 112.

Figure 112: Recover deleted file from shadow copies



Option #3: NetApp Snapshots Configure NetApp snapshots on the file share LUN As described in a previous section by default NetApp Data ONTAP software automatically creates a snapshot schedule for all configured volumes. Note: NetApp snapshot copies are only crash-consistent since there is no coordination with the branch office application or operating system. Moreover the snapshot might not contain all the new data created at the branch at that particular time, since part of it might still be in flight. To change a volume snapshot schedule navigate to Volumes -› Snapshots -› Configure, as shown in Figure 17.

Recover files from NetApp snapshots at the data center To recover the file from the NetApp storage system snapshots, present the snapshot to a Windows file server located at the data center and then browse the file system to retrieve the file.

Figure 113: Recovery from data center snapshot

Consider, the same example as in the previous section where the test1.txt file has been mistakenly deleted



as shown in Figure 86, and needs to be recovered. 5. On the NetApp storage system use the snap list vol_name command to list the snapshots in the

storage array and locate the snapshot that contains the lost file, as shown in Figure 114.

Figure 114: Snapshot list

6. Execute the vol clone create new_vol_name –b vol_name snapshot to create clone volume named

new_vol_name based on the snapshot.

Figure 115: Create clone volume

7. Locate the LUN clone snapshot in the NetApp web user interface by opening the Manage LUN window, as shown in Figure 116.



Figure 116: LUN clone snapshot

8. Select the LUN, bring it online and map it to a datacenter windows server, as shown in Figure 117.

Figure 117: LUN mapping

9. Recover the delete file by mounting the LUN on the data center windows file sever as described in the

previous sections. Share the file share drive on the Windows file server Share the file share LUN with the branch office clients, as shown in Figure 118 and by following your disk sharing best practices.



Figure 118: Windows drive sharing



Enable Data Prepopulation Enable LUN Level Block Prepopulation Optionally enable LUN Prepopulation for the File Share LUN. Granite Core will inspect the LUN and will prefetch all the blocks currently mapped to files. This means that, if the LUN is 1GB in size, for example, but files and folders occupy only 20%, only 200GB of data will be prefect in Granite Edge Blockstore cache. The pinning process however reserves space on the Granite Edge Blockstore cache for the entire LUN. If the size of the Files Share LUN is to big to be pinned, skip this paragraph and execute the steps described in the following Enable Folder Level Prepopulation section. To enable LUN level Prepopulation, first enable LUN pinning as shown in Figure 119. 1. Navigate to Configure > Storage > LUNs and under the Pin/Prepop tab change the Pin Status to

Pinned and click the Update button.

Figure 119: Enable LUN Pinning



2. After pinning is enabled, click the Add a Prepopulation Schedule button. Enter a schedule name, start and stop time. Click the Add Prepopulation Schedule button to apply, as shown in Figure 120.

Figure 120: Add Prepopulation schedule 3. Click enable to activate the Prepopulation service, as shown in Figure 121.

Figure 121: Enable Prepopulation service 4. Click Enable Immediate Prepopulation to start the Prepopulation immediately, as shown in Figure

122.



Figure 122: Enable immediate Prepopulation The Prepop field shows the percentage of completion. When the state changes to Complete, the Prepopulation process is completed and all the used blocks on the file share LUN are moved to the Blockstore cache on the Granite Edge appliance at the branch office.

Figure 123: Prepopulation status



Enable Folder Level Block Prepopulation If you want a particular set of files or folders to be prepositioned ahead of time on the Granite Edge Blockstore cache to ensure LAN performance at first user access you can use the Steelhead appliance CIFS Prepopulation feature instead of the Granite Core Pinning/Prepopulation feature. CIFS Prepopulation is designed to warm up the Steelhead Datastore when a branch office client is accessing a file server at the data center. However when the file server is moved to branch office and is getting its underlying storage from a Granite LUN, the process of CIFS Prepopulation will cause a Granite Edge Blockstore Prepopulation too. A CIFS Prepopulation schedule is like any other branch office application trying to access files on a Granite LUN, if the data is not already in the Granite Edge Blockstore cache, Granite Core prefetch mechanism will fetch it from the data center, effectively achieving files and folders level Block Prepopulation. Note: CIFS Prepopulation will not Pin the LUN but only prepopulate the files/blocks on the specified path. This means that this prepopulated data it is not sticky like in the Pin case and can be evicted from the blockstore cache. Importantly, CIFS Prepopulation does not require pinning to be enabled for a LUN. Other cases where you might want to use CIFS Prepopulation on Granite LUNs might include a day zero data migration scenarios or you might want to warm the cache with an old/archived project that is going to become active or you want to guarantee LAN performance of a folder by ensuring the Blockstore cache is always hot without having to PIN the entire LUN.

Figure 124: CIFS Prepopulation causes Granite Prepopulation In the File Server with Granite deployment scenario, the CIFS connections stay inside the branch office and do not span across the WAN, as in the standard CIFS with Steelhead appliances deployment. The CIFS Prepopulation process, on the other end, requires optimized CIFS connections between the steelhead appliances, to be enabled. For this reason to enable CIFS Prepopulation on a local file share first: 1. Disable CIFS Prepopulation dialect check using the hidden CLI command:

(config) # no prepop settings dialect-check enable Subsequently follow the standard CIFS Prepopulation configuration procedure: 2. From the Management Console, choose Configure › Optimization › CIFS Prepopulation and click the

Enable Prepopulation button, as shown in Figure 125.



Figure 125: Enable CIFS Prepopulation

3. Select Add a New Prepopulation Share. 4. Specify the remote path where data is stored: for example, \\fileserver\DeepDirectory\ 5. Specify the account username. This is the login name that has a minimum of read access to the

remote path.

6. Specify account password and confirm your password. 7. Specify a date and time for the initial synchronization to take place. 8. Enable the synchronization interval if you want to guarantee LAN performance for this folder. CIFS

Prepopulation does not pin the data on the Granite Blockstore cache and over time the Blockstore might fill up and the eviction of the prepopulated data might be required such that new data can be received.

9. Click Add as shown in Figure 126.

Figure 126: Add Prepopulation schedule

The share information appears as registered and appears in the list of shares. The CIFS Prepopulation process will start at the scheduled time and will cause the Granite Core appliance at the data center to prefetch the required blocks to the branch office file share drive.



Conclusion Riverbed continues to help organizations gain better control over their IT infrastructure and consolidate more to lower costs and risks without impacting the performance required to ensure user productivity in branch offices. With the Granite solution, Riverbed enables a global storage infrastructure by intelligently accelerating storage across the WAN, enabling new efficiency with data management, protection, and recovery while ensuring performance a the edge. With Granite, organizations can:

• Reduce costs by eliminating storage from branch offices • Improve management efficiency as maintenance and backup can take place at the data center • Recover faster and more effectively since the data is stored centrally, protected more frequently,

and can be streamed to the branch office as needed • Improve security of data assets via centralization and state-of-the-art encryption capabilities

About Riverbed Riverbed delivers performance for the globally connected enterprise. With Riverbed, enterprises can successfully and intelligently implement strategic initiatives such as virtualization, consolidation, cloud computing, and disaster recovery without fear of compromising performance. By giving enterprises the platform they need to understand, optimize and consolidate their IT, Riverbed helps enterprises to build a fast, fluid and dynamic IT architecture that aligns with the business needs of the organization. Additional information about Riverbed (NASDAQ: RVBD) is available at www.riverbed.com.

Riverbed Technology, Inc. 199 Fremont Street San Francisco, CA 94105 Tel: (415) 247-8800 www.riverbed.com

Riverbed Technology Ltd. One Thames Valley Wokingham Road, Level 2 Bracknell. RG42 1NG United Kingdom Tel: +44 1344 31 7100

Riverbed Technology Pte. Ltd. 391A Orchard Road #22-06/10 Ngee Ann City Tower A Singapore 238873 Tel: +65 6508-7400

Riverbed Technology K.K. Shiba-Koen Plaza Building 9F 3-6-9, Shiba, Minato-ku Tokyo, Japan 105-0014 Tel: +81 3 5419 1990

Branch Office Windows File Server with Steelhead EX + Granite

Documents

Transcript of Branch Office Windows File Server with Steelhead EX + Granite