Rachel Zhu Blog

I introduced Citrix ShareFile and why NetApp is the best storage for ShareFile. Now we are ready to set a production ShareFile environment on NetApp. To deploy Citrix ShareFile, you need the following components:

Any type of hypervisors 

–       Two VMs: Windows Server 2008 R2 with IIS and Citrix StorageZones Controller software.

–       Two VMs: Windows Server 2008 R2 with Active Directory^® and Domain Name Service (DNS) functions. NetApp recommends using the existing AD and DNS infrastructure.

Note that physical servers can also be used to run the above-mentioned server roles.

NetApp Storage

Note that Data ONTAP systems running 7-mode are also supported for the ShareFile solution.

• Licenses: CIFS protocol and deduplication
• Additional Licenses: snaprestore, snapmirror and snapvault (based on NRM-CS configuration)

Recommended management software: OnCommand System Manager 2.0 and Virtual Storage Console (VSC) 2.0 for Citrix XenServer

A CIFS share needs to be created for ShareFile:

• A New CIFS Share. Citrix ShareFile requires a CIFS share with no data in it since the system will create its own folder structure. The object files created by users are stored in a folder called persistentstorage (see Figure 9). Follow the NetApp best practices to set up a virtual storage server with a dedicated CIFS share.
• CIFS Share Permissions. Once the setup is completed, configure the new CIFS share using System Manager. It is important to remove the default account permissions (everyone) and enter a dedicated administrative account for the StorageZones Controller to access the CIFS share through SMB. Specifying an administrative account to access the users’ files will prevent untrusted users from accessing this UNC path.

For detailed information about clustered Data ONTAP, refer to TR-3982 and TR-3967.

NetApp recommends creating a redundant infrastructure for the platform depending on the customer’s infrastructure, different approaches are available to configure redundant network access.

Citrix ShareFile StorageZones and NetApp offer a cost-effective and scalable file sharing solution with the following key benefits.

• Storage efficiency
• On-demand flexibility
• Nondisruptive operations
• Unified storage architecture
• Data protection

Storage Efficiency

With the ShareFile object storage–based architecture, every update to the user’s files results in the creation of a new file on the back-end storage. Therefore, NetApp storage efficiency technologies help deduplicate the storage required for this highly duplicated data, thereby allowing storage cost savings. Additional savings are also obtained with the use of cross-file deduplication. Customers simultaneously achieve mobility and transparent data access with Citrix ShareFile.

On-Demand Flexibility

NetApp storage can have up to 24 nodes can be nondisruptively added to a clustered Data ONTAP deployment. A single CIFS share can span multiple nodes. As a result, customers can scale out transparently without downtime.

Nondisruptive Operation

NetApp nondisruptive operations (NDO) allow seamless storage operations without downtime. Storage upgrades and maintenance can easily be achieved without interrupting the user’s access to files.

File sharing is critical to business users; any downtime results in loss of productivity. More importantly, it can result in poor customer satisfaction. NDO in Data ONTAP provides the following benefits.

• Refresh hardware and software transparently without losing access to the customer’s data. When it is time for an update, administrators can simply move the CIFS volume to another node within the cluster nondisruptively to retire the old hardware from the cluster.
• Move data to a different node to redistribute the workload across a cluster. This task can be accomplished during normal business hours, allowing for a more dynamic platform, without waiting for the next maintenance window.
• Maintenance operations on specific hardware or software components can also be accomplished transparently. For example, adding a Flash Cache^™ acceleration card or redistributing data across controllers can be done nondisruptively.

Unified Storage Architecture

The NetApp storage array can be shared between Citrix ShareFile, Citrix XenApp, and Citrix XenDesktop deployments. Several protocols can be leveraged on the same physical array. For example, numerous volumes are required when building a XenDesktop environment with Citrix Provisioning Server (PVS). It is possible to host the write-back cache files on an NFS volume where the desktop images (vDisk) will be set up on an iSCSI LUN or CIFS share. Additionally, the user profiles and ShareFile folders will remain on two separate CIFS shares.

NetApp Snapshot Based Backups

NetApp Snapshot^™ technology provides great value when backing up the CIFS share object repository for ShareFile StorageZones since it does not require plenty of storage. By implementing Snapshot, administrators can benefit from a quick backup, flexible schedule, and custom retention policies. Remote replication of the backups can be achieved by leveraging NetApp SnapMirror^® technology. Secondary backups can be achieved using NetApp SnapVault^® technology.

NetApp OnCommand System Manager should be leveraged to configure backup and replication polices for the CIFS share.

After all these great points, NetApp has developed NetApp Recovery Manager for Citrix ShareFile (NRM-CS). NRM-CS  is a Citrix Ready certified product which provides an administrator driven user file(s) recovery solution for Citrix ShareFile StorageZone’ s deployments using on-premise NetApp Storage.  I will discuss ShareFile deployments and NRM-CS in my next two blogs.

When you setup XenDesktop deployment on NetApp Cluster ONTAP, it is important to set LIF user defined failover groups. LIF failover refers to the automatic migration of a LIF in response to a link failure on the LIF’s current network port. When such a port failure is detected, the LIF is migrated to a working port.

It is best practice to use 10Gb network ports for data LIFs and  1GB network ports for management LIFs. So when the cluster failover, the 10GB data LIF will not fall into 1 GB management LIF. It is also best practice to create a LIF for each volume. So you need to modify each LIF to a proper failover group.

We have four networks in 2000 seat XenDesktop 7 virtual desktop environment and five failover groups.

Failover group:

• Fg-cifs-3048  – CIFS for user data/profile
• Fg-cifs-3073   – server data share, optional
• Fg-nfs-3074 – Storage network, NFS volumes or iSCSI LUNs
• fg-cluster_mgmt – Cluster management
• fg-node_mgmt – Node management

Here is output of failover groups and ports configured on a 4 nodes cluster.

Failover

Group               Node              Port

——————- —————– ———-

fg-cifs-3048

ccr-cmode-01-01   a0a-3048

ccr-cmode-01-02   a0a-3048

ccr-cmode-01-04   a0a-3048

ccr-cmode-01-03   a0a-3048

fg-cifs-3073

ccr-cmode-01-01   a0a-3073

ccr-cmode-01-02   a0a-3073

ccr-cmode-01-04   a0a-3073

ccr-cmode-01-03   a0a-3073

fg-nfs-3074

ccr-cmode-01-01   a0a-3074

ccr-cmode-01-02   a0a-3074

ccr-cmode-01-04   a0a-3074

ccr-cmode-01-03   a0a-3074

fg-cluster_mgmt

ccr-cmode-01-01   e0a

ccr-cmode-01-02   e0a

ccr-cmode-01-04   e0a

ccr-cmode-01-03   e0a

fg-node-mgmt-01

ccr-cmode-01-01   e0M

ccr-cmode-01-01   e0b

fg-node-mgmt-02

ccr-cmode-01-02   e0M

ccr-cmode-01-02   e0b

fg-node-mgmt-03

ccr-cmode-01-03   e0M

ccr-cmode-01-03   e0b

fg-node-mgmt-04

ccr-cmode-01-04   e0M

ccr-cmode-01-04   e0b

Once you create the failover group, you are ready to create LIF and assign the LIF to the proper failover group.

Make sure the following highlighted values are set probably.

1. Avert True is to revert the LIF back to the primary port when the partner node gives back the control to the primary node.
2. Home port and current port is different when the LIF failover to the other storage node.
3. User failover should enable and failover group name.

ccr-cmode-01::> net int show -vserver hsvdi -lif hswc

(network interface show)

Vserver Name: hsvdi

Logical Interface Name: hswc

Role: data

Data Protocol: nfs

Home Node: ccr-cmode-01-01

Home Port: a0a-3074

Current Node: ccr-cmode-01-01

Current Port: a0a-3074

Operational Status: up

Extended Status: –

Is Home: true

Network Address: 172.20.74.107

Netmask: 255.255.255.0

IPv4 Link Local: –

Bits in the Netmask: 24

Routing Group Name: d172.20.74.0/24

Administrative Status: up

Failover Policy: nextavail

Firewall Policy: data

Auto Revert: true

Use Failover Group: enabled

Fully Qualified DNS Zone Name: none

Failover Group Name: fg-nfs-3074

FCP WWPN: –

Comment:

Proper configuration ensure the production systems continue to be functioning and no performance impact.

I have not posted blogs for a while. In last a few weeks, I was heads down configuring NetApp FlexPod with XenDesktop. I would like to share some best practices on NetApp cluster OnTAP storage configuration in my next a few blogs.

One best practice with NetApp Cluster OnTAP is using load sharing SnapMirror for virtual storage server’s root volumes.

In Cluster-Mode, NAS clients can use a single NFS mount point or CIFS share to access a namespace of potentially thousands of volumes. The root volume for a Vserver namespace contains the paths where the data volumes are junctioned into the namespace. NAS clients cannot access data if the root volume is unavailable.

Every Vserver has a root volume that serves as the entry point to the namespace provided by that Vserver. The root volume of a Vserver is a FlexVol volume that resides at the top level of the namespace hierarchy and contains the directories that are used as mount points, the paths where data volumes are junctioned into the namespace.

In the unlikely event that the root volume of a Vserver namespace is unavailable, NAS clients cannot access the namespace hierarchy and therefore cannot access data in the namespace. For this reason, it is a NetApp best practice to create a load-sharing mirror for the root volume on each node of the cluster so that the namespace directory information remains available in the event of a node outage or failover.

The procedure is also stated in NetApp FlexPod Animal CVD.

I am configuring 2000 seats XenDesktop 7 deployment these days. 

1000 Hosted Shared Desktop, 500 Hosted VDI (Pool desktops), and 500 Hosted VDI with personal vDisk. I used NetApp VDI Sizer to get the work loads spread to NetApp FAS 3240 2 nodes cluster with 4 SAS 15K RPM 600 GB disk shelves. 

Also I listed the virtual storage servers and volumes below. You can put all these volumes in one virtual storage server if you want. Virtual storage server can separate different work load and give users more secure and flexible environment. 

SAN boot Hypervisor is optional in any deployment. 

I am working on vSphere 5.1 with Citrix XenDesktop 7 on Cisco UCS project these days.  CIFS share is created in a virtual storage server as desktop home directory or as a share between the infrastructure VMs.

I was setting up CIFS with ONTAP 8.1.2 with my old note from my last project ( create root user, create PC user/group). Now I found out a much easier way to create a vServer with CIFS and would love to share with you.  vServer setup wizard will save you a lot of time and headache. Don’t manually configure the CIFS in CLI or system manager unless you want to spend your whole morning troubleshooting like I did yesterday.  The wizard takes you 5 minutes.

Here are the four key points:

• Volume language has to be “C”  not English or Japanese
• Root volume needs to be NTFS
• DNS must work
• Server and storage time difference cannot be more than 5 minutes

Below is the screenshot of my system:

ccr-cmode-01::> vserver setup
Welcome to the Vserver Setup Wizard, which will lead you through
the steps to create a virtual storage server that serves data to clients.

Step 1. Create a Vserver.
Enter the Vserver name: serverdata

Choose the Vserver data protocols to be configured {nfs, cifs, fcp, iscsi}:
cifs
Choose the Vserver client services to be configured {ldap, nis, dns}:
dns
Enter the Vserver’s root volume aggregate {aggr01, aggr02, aggr03, aggr04}
[aggr03]: aggr02
Enter the Vserver language setting, or “help” to see all languages [C]:       <—– Notice it has to be C  ( not US-English)

Enter the Vserver root volume’s security style {unix, ntfs, mixed} [unix]:
ntfs
Vserver creation might take some time to finish….Vserver serverdata with language set to C created. The permitted protocols are cifs.

Step 2: Create a data volume
You can type “back”, “exit”, or “help” at any question.

Do you want to create a data volume? {yes, no} [yes]: yes
Enter the volume name [vol1]: serverdata
Enter the name of the aggregate to contain this volume {aggr01, aggr02, aggr03,
aggr04} [aggr03]: aggr02
Enter the volume size: 1TB
Enter the volume junction path [/vol/serverdata]:
It can take up to a minute to create a volume…Volume serverdata of size 1TB created on aggregate aggr02 successfully.

Step 3: Create a logical interface.
You can type “back”, “exit”, or “help” at any question.

Do you want to create a logical interface? {yes, no} [yes]: yes
Enter the LIF name [lif1]: serverdata
Which protocols can use this interface [cifs]:
Enter the home node {ccr-cmode-01-01, ccr-cmode-01-02, ccr-cmode-01-04,
ccr-cmode-01-03} [ccr-cmode-01-03]: ccr-cmode-01-02
Enter the home port {a0a, a0a-3048, a0a-3073, a0a-3074, e0a, e0b} [a0a]:
a0a-3073
Enter the IP address: 172.20.73.60
Enter the network mask: 255.255.255.0
Enter the default gateway IP address: 172.20.73.1

LIF serverdata on node ccr-cmode-01-02, on port a0a-3073 with IP address
172.20.73.60 was created.
Do you want to create an additional LIF now? {yes, no} [no]: no
Step 4: Configure DNS (Domain Name Service).
You can type “back”, “exit”, or “help” at any question.

Do you want to configure DNS? {yes, no} [yes]:
Enter the comma separated DNS domain names: ccr.rtp.netapp.com
Enter the comma separated DNS server IP addresses: 172.20.73.41

DNS for Vserver serverdata is configured.

Step 5: Configure CIFS.
You can type “back”, “exit”, or “help” at any question.

Do you want to configure CIFS? {yes, no} [yes]:
Enter the CIFS server name [SERVERDATA-CCR-]: cifsdata
Enter the Active Directory domain name: ccr.rtp.netapp.com

In order to create an Active Directory machine account for the CIFS server, you
must supply the name and password of a Windows account with sufficient
privileges to add computers to the “CN=Computers” container within the
“ccr.rtp.netapp.com” domain.

Enter the user name [administrato]: administrator
Enter the password:

CIFS server “CIFSDATA” created and successfully joined the domain.
Do you want to share a data volume with CIFS clients? {yes, no} [yes]:
yes
Enter the CIFS share name [serverdata]:
Enter the CIFS share path [/vol/serverdata]:
Select the initial level of access that the group “Everyone” has to the share
{No_access, Read, Change, Full_Control} [No_access]: Full_Control

The CIFS share “serverdata” created successfully.
Default UNIX users and groups created successfully.
UNIX user “pcuser” set as the default UNIX user for unmapped CIFS users.
Default export policy rule created successfully.

Vserver serverdata, with protocol(s) cifs, and service(s) dns has been
configured successfully.

ccr-cmode-01::>