Sunday, December 29, 2013

Running hardware diagnostics using the sldiag command


Steps to be followed on NetApp system to diagnose the hardware issue
Note: To test the interconnect, enable the interconnect device and then run the interconnect tests. The interconnect device is disabled by default.
In addition, the interconnect tests have to be run without testing other device types. The interconnect device will only show up in SLDIAG in a 2 head configuration where both heads (storage controllers) have ONTAP booted to either maintenance or normal mode. It does not matter if the head not being tested is booted to maintenance mode or normal mode.
  1. From the loader prompt, type boot_diags to boot Data ONTAP to maintenance mode.
  2. From the maintenance mode prompt, type sldiag device show to view the list of devices that can be tested:
    *> sldiag device show
    DEV NAME SELECTION
    ------------- ----------- ----------
    interconnect ib2b disabled
    nic e0a enabled
    nic e0b enabled
    nic e0c enabled
    nic e0d enabled
    nic e0M enabled
    acp acpview enabled
    acpm 3b.0.A enabled
    acpm 3b.0.B enabled
    acpm 3a.1.A enabled
    acpm 3a.1.B enabled
    fcal 0a enabled
    fcal 0b enabled
    fcal 0c enabled
    fcal 0d enabled
    mem mem enabled
    storage 3a disabled
    storage 3c disabled
    storage 3b disabled
    storage 3d disabled
    bootmedia bootmedia enabled
    environmentals environmentals enabled
    serviceProcessor serviceProcessor enabled
    nvram slot2 enabled
    .
    .
    .
  3. Enable the device:*>sldiag device modify -dev interconnect -sel enable
    SLDIAG: no tests are enabled for ib2b

    *> sldiag device show
    DEV NAME SELECTION
    ------------- ------ ----------
    interconnect ib2b enabled
    nic e0a enabled
    nic e0b enabled
    .
    .
    .
  4. Enable the test:*> sldiag test modify -dev interconnect -sel enable
    *> sldiag test show -dev interconnect
    INDEX DEVTYPE TEST NAME SELECTION
    ----- ------------ ----- ------------------- ---------
    7 interconnect RDMA Basic pattern R/W Test enabled
    8 interconnect RDMA Complementary pattern R/W Test enabled
    9 interconnect RDMA Random pattern R/W Test enabled
    10 interconnect RDMA CheckerBoard pattern R/W Test enabled
    11 interconnect RDMA Basic pattern S/R Test enabled
    12 interconnect RDMA Complementary pattern S/R Test enabled
    13 interconnect RDMA Random pattern S/R Test enabled
    14 interconnect RDMA CheckerBoard pattern S/R Test enabled
    Note: Prior to running the interconnect tests, clear the results from the previous tests by typing *>sldiag device clearstatus
  5. Run the test:*>sldiag device run -dev interconnect
    *> <SLDIAG:_ALL_TESTS_COMPLETED>
  6. Run the following command to view the results summary:*> sldiag device status -dev interconnect

    Use the 
    -long option to view the details:sldiag device status -long
    Device TestName StartDate EndDate Status Loop
    ------ ---------------- ------------------- ------------------- ------ ----
    ib2b RDMA Basic Sat Aug 13 22:31:48 Sat Aug 13 22:31:52 PASSED 1/1

    pattern R/W Test
    ib2b RDMA Complementary Sat Aug 13 22:31:52 Sat Aug 13 22:31:59 PASSED 1/1

    pattern R/W Test
    ib2b RDMA Random Sat Aug 13 22:32:00 Sat Aug 13 22:32:03 PASSED 1/1
    pattern R/W Test

    ib2b RDMA CheckerBoard Sat Aug 13 22:32:04 Sat Aug 13 22:32:08 PASSED 1/1
    pattern R/W Test

    ib2b RDMA Basic pattern Sat Aug 13 22:32:09 Sat Aug 13 22:32:13 PASSED 1/1
    S/R Test
    ib2b RDMA Complementary Sat Aug 13 22:32:14 Sat Aug 13 22:32:20 PASSED 1/1
    pattern S/R Test
    ib2b RDMA Random Sat Aug 13 22:32:21 Sat Aug 13 22:32:24 PASSED 1/1

    pattern S/R Test
    ib2b RDMA CheckerBoard Sat Aug 13 22:32:25 Sat Aug 13 22:32:29 PASSED 1/1

Brocade FOS Up gradation Steps



Brocade FOS Up gradation Steps.
1.       Backing up the existing switch configuration to the local server by cmd “configupload”.
For Example:
switch1:admin> configupload
Server Name or IP Address [host]: 1.2.3.4
User Name [user]: matty
File Name [config.txt]: switch1_config.txt
Protocol (RSHD or FTP) [rshd]: ftp
Password:
upload complete
For download put configdownload.

2.       Tag all the fiber cable and unplug it from the switch.
3.       Download the FOS version 6.1.0c from the brocade site.
4.       Take the putty of the switch.
5.       Enter the version cmd to check the current version.
6.       Enter the nsShow cmd to check the entire device directly connected to the switch.
7.       Enter the nsAllShow cmd to check the entire connected device to the fabric.
8.       Enter the fabricshow cmd to check all switches in the fabric
9.       Enter the Firmwareshow cmd to chek the primary and secondary partion.
10.   Enter the Firmwaredownload cmd to download the new version.
For example:
switch:admin> firmwaredownload 
Server Name or IP Address: 10.22.127.127
FTP User Name: JohnDoe
File Name:  /release.plist
FTP Password:
You can run firmwaredownloadstatus to get the status
of this command.
This command will cause the switch to reset and will
require that existing telnet, secure telnet or SSH
sessions be restarted.
Do you want to continue [Y]: y
11.   Enter the firmwaredownloadstatus cmd to check the current status of the upgrade process.
12.   Enter the firmwareshow cmd to check the primary and secondary partition version.
13.   Plugin all the fiber cable and check the connectivity.
14.   Enter the nsShow cmd to check the entire device directly connected to the switch.
15.   Enter the nsAllShow cmd to check the entire connected device to the fabric.
16.   Enter the fabricshow cmd to check all switches in the fabric.



Backing up Brocade switch configurations
Brocade switches have become one of the most widely deployed componets in most Storage Area Networks (SANs). One thing that has led to Brocade’s success is their robust CLI, which allow you to view and modify almost every aspect of their switch. This includes zoning configurations, SNMP attributes, domain ids, switch names and network addresses, etc. All of this configuration information is necessary for the switch to function properly, and should be periodically backed up to allow speedy recovery when disaster hits.
Each Brocade switch comes with the “configUpload” and “configDownload” commands to back up a switch configuration to a remote system, or to restore a configuration from a remote system. ConfigUplaod has two modes of oepration: interactive mode and automatic mode. To use the interactive mode to upload a config from a switch named switch1 to an ftp server with the IP address 1.2.3.4, configUpload can be run to walk you through backing up the configuration:
switch1:admin> configuploadServer Name or IP Address [host]: 1.2.3.4User Name [user]: matty
File Name [config.txt]: switch1_config.txt
Protocol (RSHD or FTP) [rshd]: ftp
Password:
upload complete
After the configuration is uploaded, you will have a text file with you switches configuration on the remove server:
$ ls -l sw*
-rw-r--r--   1 matty    other       7342 Jul  7 09:15 switch1_config.txt
To restore a configuration, you can use the configDownload command. Both of these commands allow the paramters to be passed as arguments to the script, so they are ideal for automation (there is a backup script on the Brocade support site that can be used to automate configuration backups)

NetApp Snap Mirror


NetApp Snap Mirror
Well every NetApp engineer will be aware of the snapmirror , it’s a common and important feature of the NetApp, so today I thought of writing something about snapmirror , May be my blog on snapmirror can help you to understand the snapmirror more nicely.
Why we need a snapmirror.
SnapMirror is replication feature of NetApp and it is fast and flexible enterprise solution to replicate your critical and very precious data over local area, wide area and fiber channel networks to the destination/different location, and it is the very good solution for the disaster and even good solution for the online data migration without any additional overhead.
Snapmirror have three modes.
Async: Replicates snapshot copies from a source volume or qtree to a destination volume or qtree. Incremental updates are based on schedules or are performed manually using the snapmirror update command. It works both in volume level and qtree level.
Sync: Replicates writes from a source volume to a secondary volume at the same time it is written to the source volume. Snap mirror Sync is used in environments that have zero tolerance for data loss.
Semi-sync: It is between the Async and sync mode with less impact on performance. It can configure a snapMirror sync replication to lag behind the source volume by a user-defined number of write operations or milliseconds.
Volume snapmirror enables block-for –block replication. The entire volume, including its qtrees, and all the associated snapshot copies, are replicated to the destination volume. The source volume is online/writable and the destination volume is online/readonly and when the relationship is break the destination volume becomes writable.
Initial Transfer and Replication.
To initialize a snapmirror relation, you first have to restrict the destination volume in which the replica will reside. During the baseline transfer, the source system takes a snapshot copy of the volume. All data blocks referenced by this snapshot copy, including volume metadata such as language translation settings, as well as all snapshot copies of the volume are transferred and written to the destination volume.
After the initialization completes, the source and destination file systems have one snapshot copy in common. Update occur from this point and are based on the schedule specified in a flat-text configuration file known as the snapmirror.conf file or by using the snapmirror update command.
To identify new and changed blocks, the block map in the new snapshot copy is compared to the block map of the baseline snapshot copy. Only the blocks that are new or have changed since the last successful replication are sent to the destination. Once the transfer has completed the new shapshot copy becomes the baseline snapshot copy and the old one is deleted.
Requirements and Limitations
Destinations Data Ontap version must be equal to or more recent than the source. In addition, the source and the destination must be on the same Data ontap release.
Volume snapMirror replication can only occur with volumes of the same type either traditional volumes or both flexible volumes.
Destination volumes capacity equal to or greater than size of the source, Administrators can thin provision the destination so that it appears to be equal to or greater than the size of the source volume.
Quota cannot be enabled on destination volume.
It is recommended that you allow a range of TCP ports from 10565 to 10569.

Qtree SnapMirror
Qtree snapMirror is a logical replication. All the files and directories in the source file system are created in the target destination qtree.
Qtree Snap Mirror replication occurs between qtrees regardless of the type of the volume (traditional or flexible).Even qtree replication can occur between different releases of Data ONTAP.
Source volume and qtree are online/writable in qtree replication and Destination volume is also online/writable (in qtree replication).
NOTE: Unlike volume snapMirror , a qtree snapMirror does not require that the size of the destination volume be equal to or greater than the size of the source qtree.
In initial baseline transfer you not need to create the destination qtree , it gets automatically created upon first time replication.
Requirements and limitations
Support Async mode only
Destination volume must contain 5% more free space than the source qtree and destination qtree cannot be /etc
Qtree snapMirror performance is impacted by deep directory structure and large number (tens of millions) of small files replicated.

Configuration process of snapmirror
1.    Install the snapMirror license
For ex: license add <code>

2.    On the source, specify the host name or IP address of the snapMirror destination systems you wish to authorize to replicate this source system.
For Ex: options snapmirror.access  host=dst_hostname1,dst_hostname2

3.    For each source volume and qtree to replicate, perform an initial baseline transfer, For volume snapmirror restrict the destination volume.
For Ex: vol restrict dst_volumename

 Then initialize the volume snapmirror baseline, using the following syntax on the destination:
For Ex: snapmirror initialize –S src_hostname:src_vol dst_hostname:dst_vol

For a qtree snapmirror baseline transfer, use the following syntax on the destination
Snapmirror initialize –S src_hostname: /vol/src_vol/src_qtree dst_hostname:/vol/dst_vol/dst_qtree

4.    Once the initial transfer completes, set the snapmirror mode of replication by creating the /etc/snapmirror.conf file in the destination’s root volume.
Snapmirror.conf
The snapmirror.conf configuration file entries define the relationship between the source and the destination, the mode of replication, and the arguments that control SnapMirror when replicating data.
Entries can be seen like this in snapmirror.conf file
For ex:  Fas1:vol1 Fas2:vol1 – 0 23 * 1,3,5
Fas1:vol1 : source storage system hostname and path
Fas2:vol1: destination storage system hostname and path
“-“: Arguments: Arguments fields let you define the transfer speed and restart mode and “– “  indicate the default mode is selected
Schedules
0: updates on the hours
23: updates on 11PM
*: Updates on all applicable days of the months
1,3,5: updates on Monday,Wednesday,Friday
You can Monitor transfer by running the cmd “snapmirror status”  this cmd can be run on source as well as on the destination also, it comes with two options –l and –q
-l : option display the long format of the output.
-q: option displays which volumes or qtree are quiesced or quiescing.
You can list all the snap shot copies of particular volumes by “snap list volumename” cmd, snapmirror snapshot copies are distinguished from system snapshot copies by a more elaborate naming convention.
The snap list command display the keyword snapmirror next to the necessary snapshot copy
Log files
Snapmirror logs record whether the transfer finished successfully or failed. If there is a problem with the updates , it is useful to look at the log file to see what has happened since the last successful update. The log include the start and end of each transfer, along with the amount of data transferred.
For ex: options snapnmirror.log.enable (on/off) by default it is on.
Log files are stored in the source and the destination storage system root volume, in the /etc/logs/snapmirror directory.
This guides you quickly through the Snapmirror setup and commands. 

1) Enable Snapmirror on source and destination filer 
source-filer> options snapmirror.enable
snapmirror.enable            on
source-filer>
source-filer> options snapmirror.access
snapmirror.access            legacy
source-filer> 

2) Snapmirror Access
Make sure destination filer has snapmirror access to the source filer. The snapmirror filer's name or IP address should be in /etc/snapmirror.allow. Use wrfile to add entries to /etc/snapmirror.allow.

source-filer> rdfile /etc/snapmirror.allow
destination-filer
destination-filer2
source-filer>


3) Initializing a Snapmirror relation 
Volume snapmirror : Create a destination volume on destination netapp filer, of same size as source volume or greater size. For volume snapmirror, the destination volume should be in restricted mode. For example, let us consider we are snapmirroring a 100G volume - we create the destination volume and make it restricted.

destination-filer> vol create demo_destination aggr01 100G
destination-filer> vol restrict demo_destination


Volume SnapMirror creates a Snapshot copy before performing the initial transfer. This copy is referred to as the baseline Snapshot copy. After performing an initial transfer of all data in the volume, VSM (Volume SnapMirror) sends to the destination only the blocks that have changed since the last successful replication. When SnapMirror performs an update transfer, it creates another new Snapshot copy and compares the changed blocks. These changed blocks are sent as part of the update transfer.

Snapmirror is always destination filer driven. So the snapmirror initialize has to be done on destination filer. The below command starts the baseline transfer.

destination-filer> snapmirror initialize -S source-filer:demo_source destination-filer:demo_destination
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.
destination-filer
>

Qtree Snapmirror : For qtree snapmirror, you should not create the destination qtree. The snapmirror command automatically creates the destination qtree. So just volume creation of required size is good enough.

Qtree SnapMirror determines changed data by first looking through the inode file for inodes that have changed and changed inodes of the interesting qtree for changed data blocks. The SnapMirror software then transfers only the new or changed data blocks from this Snapshot copy that is associated with the designated qtree. On the destination volume, a new Snapshot copy is then created that contains a complete point-in-time copy of the entire destination volume, but that is associated specifically with the particular qtree that has been replicated.

destination-filer> snapmirror initialize -S source-filer:/vol/demo1/qtree destination-filer:/vol/demo1/qtree Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.

4) Monitoring the status : Snapmirror data transfer status can be monitored either from source or destination filer. Use "snapmirror status" to check the status.

destination-filer> snapmirror status
Snapmirror is on.
Source                          Destination                          State          Lag Status
source-filer:demo_source        destination-filer:demo_destination   Uninitialized  -   Transferring (1690 MB done)
source-filer:/vol/demo1/qtree   destination-filer:/vol/demo1/qtree   Uninitialized  -   Transferring (32 MB done)
destination-filer> 

5) Snapmirror schedule : This is the schedule used by the destination filer for updating the mirror. It informs the SnapMirror scheduler when transfers will be initiated. The schedule field can either contain the word sync to specify synchronous mirroring or a cron-style specification of when to update the mirror. The cronstyle schedule contains four space-separated fields.
If you want to sync the data on a scheduled frequency, you can set that in destination filer's /etc/snapmirror.conf . The time settings are similar to Unix cron. You can set a synchronous snapmirror schedule in /etc/snapmirror.conf by adding “sync” instead of the cron style frequency.

destination-filer> rdfile /etc/snapmirror.conf
source-filer:demo_source        destination-filer:demo_destination - 0 * * *  # This syncs every hour
source-filer:/vol/demo1/qtree   destination-filer:/vol/demo1/qtree - 0 21 * * # This syncs every 9:00 pm
destination-filer>


6) Other Snapmirror commands
  • To break snapmirror relation - do snapmirror quiesce and snapmirror break.
  • To update snapmirror data  - do snapmirror update
  • To resync a broken relation - do snapmirror resync.
  • To abort a relation - do snapmirror abort
Snapmirror do provide multipath support. More than one physical path between a source and a destination system might be desired for a mirror relationship. Multipath support allows SnapMirror traffic to be load balanced between these paths and provides for failover in the event of a network outage.
Some Important Points to be known about SnapMirror
Clustered failover interaction.The SnapMirror product complements NetApp clustered failover (CF) technology by providing an additional level of recoverability. If a catastrophe disables access to a clustered pair of storage systems, one or more SnapMirror volumes can immediately be accessed in read-only mode while recovery takes place. If read-write access is required, the mirrored volume can be converted to a writable volume while the recovery takes place. If SnapMirror is actively updating data when a takeover or giveback operation is instigated, the update aborts. Following completion of the takeover or giveback operation, SnapMirror continues as before. No specific additional steps are required for the implementation of SnapMirror in a clustered failover environment

 Adding disks to SnapMirror environments.When adding disks to volumes in a SnapMirror environment always complete the addition of disks to the destination storage system or volume before attempting to add disks to the source volume.
Note: The dfcommand does not immediately reflect the diskor disks added to the SnapMirror volume until after the first SnapMirror update following the disk additions.

Logging. The SnapMirror log file (located in /etc/logs/snapmirror.log) records the start and end
of an update as well as other significant SnapMirror events. It records whether the transfer finished successfully or whether it failed for some reason. If there is a problem with updates, it is often useful to look at the log file to see what happened since the last successful update. Because the log file is kept on the source and destination storage systems,quite often the source or the destination system may log the failure, and the other partner knows only that there was a failure. For this reason, you should look at both the source and the destination log file to get the most information about a failure. The log file contains the start and end time of each transfer, along with the amount of data transferred. It can be useful to look back and see the amount of data needed to make the update and the amount of time the updates take.
Note: The time vs. data sent is not an accurate measure of the network bandwidth because the transfer is not constantly sending data

Destination volume.For SnapMirror volume replication, you must create a restricted volume to be used as the destination volume. SnapMirror does not automatically create a volume.

Destination volume type.The mirrored volume must not be the root volume.

Data change rate.Using the ‘snap delta’ command, you can now display the rate of change stored between two Snapshot copies as well as the rate of change between a Snapshot copy and the active file system. Data ONTAP displays the rates of change in two tables. The first table displays rates of change between successive Snapshot copies. The second table displays a summary of the rate of change between the oldest Snapshot copy and the active file system.

Failed updatesIf a transfer fails for any reason, SnapMirror attempts a retransfer immediately, not waiting for the next scheduled mirror time. These retransfer attempts continue until they are successful, until the appropriate entry in the /etc/snapmirror.conf file is commented out, or until SnapMirror is turned off. Some events that can cause failed transfers include:

Loss of network connectivity
Source storage system is unavailable
Source volume is offline

SnapMirror timeoutsThere are three situations that can cause a SnapMirror timeout:
Write socket timeout. If the TCP buffers are full and the writing application cannot hand off data to
TCP within 10 minutes, a write socket timeout occurs. Following the timeout, SnapMirror resumes
at the next scheduled update.

Read socket timeout. If the TCP socket that is receiving data has not received any data from the application within 30 minutes, it generates a timeout. Following the timeout, SnapMirror resumes at the next scheduled update. By providing a larger timeout value for the read socket timeout, you can be assured that SnapMirror will not time out while waiting for the source file to create Snapshot copies, even when dealing with extremely large volumes. Socket timeout values are not tunable in the Data ONTAP and SnapMirror environment.

Sync timeoutsThese timeouts occur in synchronous deployments only. If an event occurs that causes a synchronous deployment to revert to asynchronous mode, such as a network outage, no ACK is received from the destination system.

Open Files
If SnapMirror is in the middle of a transfer and encounters an incomplete file (a file that an FTP server is still transferring into that volume or qtree), it transfers the partial file to the destination. Snapshot copies behave in the same way. A Snapshot copy of the source would show the transferring file and would show the partial file on the destination.
A workaround for this situation is to copy a file to the source. When the file is complete on the source, rename the source file to the correct name. This way the partial file has an incorrect name, and the complete file has the correct name.

Friday, November 22, 2013

Netapp: How to create VLANS on a Vif

Netapp: How to create VLANS on a Vif

How to create VLANs on a Vif
View Environment section
Symptoms
I want to aggregate bandwidth and allow the filer to load balance across multiple subnets.
Example:
Management on 192.168.x.x
Server to Server on 172.32.x.x
Production on 10.x.x.x
I want to place the management VLAN on a vif used by Server to Server, Production traffic, or place all traffic on 1 vif across multiple ports to allow maximum bandwidth for production during peak hours and Server to Server backup during non peak hours.
How do I create VLANs on a Vif?
Keywords: aggregated
Solution
1. Create vif  (Do not hyphenate vif name. The ifconfig will attempt to use the first hyphen to identify the VLAN ID)
2. Create VLANs on the vif (substitute the vif name for the interface name)
3. Configure VLAN interface(s)
Example:
Vif create multi Vif1 e0a e0b e0c e0d
Vlan create Vif1 10 172 192
Ifconfig Vif1-10 10.x.x.x netmask 255.x.x.x
Ifconfig Vif1-172 172.32.x.x netmask 255.x.x.x
Ifconfig Vif1-192 192.168.x.x netmask 255.x.x.x
If the Filer is part of a cluster, the partner command may be used.
Example:
Ifconfig Vif1-10 10.x.x.x netmask 255.x.x.x Partner Vif1-10
Or
Ifconfig Vif1-10 Partner Vif1-10
To make these configurations persistent across reboots, these commands must be added to the /etc/rc file.
Note:
Prior to Ontap 7.3.3, when using Vlans on a Vif, changing the MTU size could affect all Vlans.
For example:
Configuring vif1-10 with an MTU of 9000 (jumbo frames) wouldl change the MTU of all Vlans  and interfaces. This could cause the filer to send packets larger than the hosts other Vlans can process and result in poor or no connectivity on these hosts/Vlans.
Configuring an interface in a VLAN
Using the ifconfig command, you can configure all the parameters for a VLAN interface that you can for a physical interface. The parameters you can configure are
* IP address
* Network mask
* Interface status
* Media type
* MTU size
* Flow control
* Partner
Enter the following command:
ifconfig ifname-vlanid IP_address netmask mask
ifname-vlanid is the VLAN interface name.
IP_address is the IP address for this interface.
mask is the network mask for this interface.
Example
You can configure a VLAN interface e4-10, created in the previous example, using the following command:
ifconfig e4-10 172.25.66.11 netmask 255.255.255.0

Friday, November 8, 2013

Howto enable passwordless SSH on NetApp filer

When working in an environment with lots of filer servers, you might consider enable password less SSH on the filer for easier administration (from some administration host).
The concept stays the same, public keys exchange, but as you know the NetApp OnTapp OS uses slightly different syntax, so I decided to write this small guide that will help you out:

OK, let's get busy , I'll assume that the filer has already has networking configured correctly.


1) The filer does not have SSH enabled by default, so login via telnet:
admin_host> telnet filer01


2) Set up root password:
filer01> passwd


3) Next, you need to enable SSH (preferably version 2 - as it's more secure):
filer01> secureadmin enable ssh2
filer01> secureadmin setup ssh


4) Make sure you exports file is edited correctly and vol0 is exported to admin_host
admin_host> showmount -e filer01

You can edit exports file from the filer with "wrfile" command, if you have modified the file remmember to re-export the new exports with:

filer01 >exportfs -av

5) Next, mount  vol0 from the NetApp filer on the amdministration host:

admin_host> mkdir -p /nfs/filer01/vol0
admin_host> mount -t nfs filer01:/vol/vol0 /nfs/filer01/vol0

Check that you see the mounted volume:

admin_host> ls /nfs/filer01/vol0

If not you're probably having some issue with your firewall, or exports on the filer side.

6) This is the most critical part, here you will create the ssh directory and append your root public key to authorized_keys of the filer:

admin_host> mkdir -p /nfs/filer01/vol0/etc/sshd/root/.ssh/

admin_host> cat /root/.ssh/id_rsa.pub >> /nfs/filer01/vol0/etc/sshd/root/.ssh/authorized_keys


7) Last, you may want to turn down rsh and telnet services (for obvious security reasons):

filer01> options rsh.enable off
filer01> options telnet.enable off

How to improve the Netapp storage performance

 How to improve the Netapp storage performance?

There is no direct answer for this question but we shall do it in several way.
If volume/lun present in ATA/SATA harddisk aggregate, then the volume can be migrated to FC/SAS disk aggregate.
For NFS/CIFS instead of accessing from single interface, multi mode vif can be configured to get better bandwidth and fault tolerance.
Always advised to keep aggr/vol utilization below 90%.
Avoid doing multiple volume backup in single point of time.
Aggr/volume/lun reallocation can be done to re–distribute the data to multiple disk for better striping performance.
Schedule scrubbing and deduplication scanning after business hours.
Avoid connecting different types of shelf in a same loop.
Avoid mixing up different speeds of disk and different types of disk in a same aggregate.
Always keep sufficient spare disk to replace incase of disk failure. Because reconstruction time will take more time and cause negative performance.
Keep the advised version of firmware/software which is recommended by netapp.
Better to have nearstore functionality to avoid backing up data from source filer.

Unable to map lun to solaris server, but solaris server side no issue. How to resolve the issue?

FROM STORAGE SIDE:
Verify iscsi/fcp license is added in storage
Verify iscsi/fcp session is logged in from server side
Verify luns are mapped to the corresponding igroup.
Verify whether correct host type is mentioned while creating igroup and lun
Verify whether correct iqn/wwpn number is added to igroup
Verify zoning is properly configured from switch side.
How to create the LUN for solaris server?
lun create –s size –t solaris /vol/vol1/lunname

How to create qtree and provide the security?

Qtree create /vol/vol1/qtreename
Qtree security /vol/vol1/qtree unix|ntfs|mixed

How to copy filer to filer?

ndmpcopy or snapmirror

How to resize the aggregate?

Aggr add agg(name) no.of.disk

How to increase the volume?

Traditional

Vol add vol(name) no.of.disk

Flexiable

Vol size vol(name) +60g

What is qtree?

Qtree are Logical partition of the volume

What is the default snap reserve in aggregate?

5%

What is snapshot?

Copy(read only) of active file system

What are the raid groups netapp supporting?, what is the difference between them?

Raid_dp(double parity,diagonal parity) ,raid4(striping&dedicated parity)
What are the protocols you are using?

Say some protocols like NFS, CIFS, ISCSI and FC
What is the difference between iscsi and fcp?

Iscsi-sending block through(tcp,ip)

Fcp-send through fibre medium
What is the iscsi port number your are using?

860 and 3260

What is the difference between ndmp copy and vol copy?

Ndmp copy –network data management protocol(used for tape backup)

Vol copy – is used to transfer volume to same or another aggr

What is the difference between ONTAP 7 & 8?

In ONTAP 7 the individual aggregate is limited to maximum of 16 TB. Where ONTAP 8 supports the new 64 bit aggregate and hence the size of the individual aggregate extends to 100 TB.

What are the steps need to perform to configure SnapMirror?

The SnapMirror configuration process consists of the following four steps:

a. Install the SnapMirror license on the source and destination systems: license add <code>

b. On the source, specify the host name or IP address of the SnapMirror destination systems you wish to authorize to replicate this source system.

options snapmirror.access host=dst_hostname1,dst_hostname2

c. For each source volume or qtree to replicate, perform an initial baseline transfer. For volume SnapMirror,

restrict the destination volume first: vol restrict dst_vol

Then initialize the volume SnapMirror baseline, using the following syntax on the destination:

snapmirror initialize -S src_hostname:src_v

oldst_hostname:dst_vol

For a qtree SnapMirror baseline transfer, use the following syntax on the destination:

snapmirror initialize –S src_hostname:/vol/src_vol/src_qtree

dst_hostname:/vol/dst_vol/dst_qtree

d. After the initial transfer completes, set the SnapMirror mode of replication by creating the

/etc/snapmirror.conf file in the destination’s root volume.


While doing baseline transfer you’re getting error message. What are the troubleshooting steps you’ll do?


Check both the hosts are reachable by running “ping” command
Check whether the TCP port 10566 & 10000 are open
Check whether the snapmirror license are installed in both and destination

Explain the different types of replication modes.

The SnapMirror Async mode replicates Snapshot copies from a source volume or qtree to a destination

volume or qtree. Incremental updates are based on a schedule or are performed manually using the

snapmirror update command. Async mode works with both volume SnapMirror and qtree SnapMirror.

SnapMirror Sync mode replicates writes from a source volume to a destination volume at the same time it is

written to the source volume. SnapMirror Sync is used in environments that have zero tolerance for data loss.

SnapMirror Semi-Sync provides a middle-ground solution that keeps the source and destination systems more

closely synchronized than Async mode, but with less impact on performance.

How do you configure multiple path in Snapmirror?

Add a connection name line in the snapmirror.conf file
/etc/snapmirror.conf
FAS1_conf = multi (FAS1-e0a,FAS2-e0a) (FAS1-e0b,FAS2-e0b)

Explain how De-Duplication works?

In the context of disk storage, deduplication refers to any algorithm that searches for duplicate data objects (for example, blocks, chunks, files) and discards those duplicates. When duplicate data is detected, it is not retained, but instead a “data pointer” is modified so that the storage system references an exact copy of the data object already stored on disk. This deduplication feature works well with datasets that have lots of duplicated date (for example, full backups).

What is the command used to see amount of space saved using deduplication?

df –s <volume name>

Command used to check progress and status of deduplication?

sis status
How do you setup Snapvault Snapshot schedule?

pri> snapvault snap sched vol1 sv_hourly 22@0-22

This schedule is for the home directories volume vol1
Creates hourly Snapshot copies, except 11:00 p.m.
Keeps nearly a full day of hourly copies

What is metadata?

Metadata is defined as data providing information about one or more aspects of the data,

1. Inode file
2. Used block bitmap file
3. Free block bitmap file
How do you shutdown filer through RLM?

telnet “rlm ip address”
RLM_Netapp> system power on

After creating LUN (iSCSI) & mapped the lun to particular igroup, the client not able to access the LUN. What are the trouble shooting steps you take?

Check whether IQN number specified is correct
Check whether the created LUN is in “restrict” mode
Check the iscsi status

In CIFS how do you check who is using most?

Cifs top

How to check cifs performance statistics

cifs stat

What do you do if a customer reports a particular CIFS share is responding slow?

Check the r/w using "cifs stat" & "sysstat -x 1".
If disk & cpu utilization is more then problem is with filer side only.
CPU utilization will be high if more disk r/w time, i.e.,during tapeback up & also during scrub activities.

what is the degraded mode? You have parity for failed disks then why the filer goes to degraded mode?

If the spare disk is not added within 24hours,then filer will be shutdown auomatically to avoid further disk failures and data loss.

Did you ever do ontap upgrade? From which version to which version and for what reason?

Yes i have done ontap upgrade from version 7.2.6.1 to 7.3.3 due to lot of bugs in old version.

How do you create a lun ?

lun create -s <lunsize> -t <host type> <lunpath>

Production Manager?

Production manager will do the planning,co-ordinating and controlling the process.

Performance Manager?

Performance manager will analyses the performance trends of application.systems and services.

How do you monitor the filers?

Using DFM(Data Fabric Manager) or also using SNMP you can monitor the filer.

What are the prerequisites for a cluster?

cluster interconnect cable should be connected.

shelf connect should be properly done for both the controllers

cluster license should be enabled on both the nodes

Interfaces should be properly configured for fail over

cluster should be enabled

What are the scenarios you have for a cluster failover?

If disk shelf power or shelf port is down, then failover will not happen. It cannot access the mail box disk. Mail box disk stores the cluster configuration data.

What is the diff bet cf takeover and cf force takeover?

If partner shelf power is off (metrco cluster), the forcetakover will work else normal takeover will work.

Snap shot autodelete

Snap shot autodelete

1.0.1 The purpose of this policy is to provide guidance as to use the Netapp Default functioning of snapshot auto delete. Snapshot autodelete is a policy based space management feature that is implemented in Data ONTAP 7.1 in order to get back space in volume for user data. It allows the user to define a policy to automatically delete snapshots when the volume is nearly full. It keeps the amount of unused spaced in a filer to a minimum level. The snapshot autodelete is available for Flexible volumes only.

1.1 Scope

1.1.1 This policy applies to all the volumes in Netapp Filer which are upgraded to Data ONTAP 7.1 ( and subsequent Data ONTAP versions)

1.2 When Does Snapshot Delete Happen


1.2.1 When the “trigger” criteria is near full.
Volume: The volume is near full
Snap_reserve: The reserve is near full
Space_reserve: The Space reserved is near full.

1.2.2 What defines “near full” ?
By Default near full is defined as 98%
Default is controlled by the flag “wafl_reclaim_threshold”

1.2.3 How to change the Default “wafl_reclaim_threshold” value ?
Priv set diag
Setflag wafl_reclaim_threshold 

1.3 When Does Sanpshot Autodelete Stop ?
1.3.1 Once autodelete starts, explicit conditions need to be met to stop autodelete

1.3.2 When the free space in the “trigger” criteria reaches a particular user specified percentage, the snashot autodelete stops.

1.3.3 This percentage is controlled by the value of “target_free_space”. Default value of target_free_space is 20%

1.4 What Snapshots is autodelete allowed to delete ?

1.4.1 The user can protect certain kinds of snapshots by deferring their delete.
1.4.2 The “commitment” option defines this:
“try”: Delete snapshots which are not being used by any data mover, recovery or clones. (NOT LOCKED)
“disrupt”: Delete snapshots locked by datamovers – snap mirror, dump/restore ( Mirror, Dumps are aborted )
1.4.3 Snapshots locked by clones, snap restores, cifs shares are not deleted.
1.4.4 “disrupt” snapshots are only deleted if there are no “try” snapshots left to delete.

1.5 In what order are the snapshots deleted ?

1.5.1 The “Delete_order” option defines the age order. If the value is set to:
“oldest_first”: Delete older snapshots first.
“newest_first”: Delete new snapshots first.

1.5.2 The “Defer_delete” option defines the order on ‘name’. If defers the deletion
Of the snapshots to the end. If the value is set to:
“scheduled”: Delete the scheduled snapshots last. ( Identified by the scheduled snapshot naming convention)
“User_created”: Delete the user created snapshots last. Note: User_created here refer to everything-that-is-not-snap-sched-created-by-Data ONTAP itself.
“prefix”: Delete the snapshots with names matching the “prefix” string last.

1.5.3 The “Prefix” option value pair is only considered when “defer_delete” is set to
“prefix”. Otherwise it is ignored.

1.6 The Hierarchy for selection snapshots on different criteria is as follows:

1.6.1 commitment
1.6.2 defer_delete
1.6.3 delete_orader




1.7 EXAMPLES


Auto delete will first delete a “try” snashot which does not lie in the “defer_delete”
Criteria and is the oldest such snapshot. If such a snapshot is not found, the
“defer_delete” criteria would be ignored to find a snapshot. Lastly we would move
To the “disrupt” criteria (if commitment=disrupt) and attempt to find a snapshot.

1.7.1 snap autodelete vol1 on --- enables autodelete
1.7.2 snap autodelete vol1 off --- disables autodelete
1.7.3 snap autodelete vol1 show - shows the current settings
1.7.4 snap autodelete vol1 reset - resets all autodelete options to default for vol1
1.7.5 snap autodelete vol1 help - shows help commands


1.8 SNAPSHOT AUTO DELETE COMMAND SYNTAX

1.8.1 snap autodelete
snap autodelete [on off show reset help]
snap autodelete