Network Ports for NetApp Products

Product/Source	Port	Protocol	Target	Direction
SnapDrive dfm integration	8088	http	DFM server	bi-directional
SnapDrive dfm integration - secure	8488	https	DFM server	bi-directional
snapdrive webservice	4094	http	filer/vfiler	bi-directional
snapdrive webservice - secure	4095	https	filer/vfiler	bi-directional
Snapdrive autosupport	25	TCP	SMTP server	one way
Snapdrive iscsi	3260	TCP	filer/vfiler	bi-directional
Snapdrive netbios RPC	137	TCP	filer/vfiler	bi-directional
	138	TCP	filer/vfiler	bi-directional
	139	TCP	filer/vfiler	bi-directional
	1512	TCP	filer/vfiler	bi-directional
Snapmanager for SQL	808	TCP	SQL server	bi-directional
Snapmanager for Exchange	808	TCP	SQL server	bi-directional
OSSV-ndmp	10000	TCP	DFM server	bi-directional
OSSV-snapvault	10566	TCP	filer/vfiler	bi-directional
Snapvault-ndmp	10000	TCP	DFM server	bi-directional
Snapvault-traffic	10566	TCP	filer/vfiler	bi-directional
Snapmirror Source	10566	TCP	filer/vfiler	bi-directional
" " " "	10569	TCP	filer/vfiler	bi-directional
Snapmirror Destination	10565	TCP	filer/vfiler	bi-directional
" " " "	10567	TCP	filer/vfiler	bi-directional
" " " "	10568	TCP	filer/vfiler	bi-directional
SMVI	8043	TCP	filer/vfiler	bi-directional

NetApp SnapLock

Hello Guys, You know not all storage companies provide this amazing feature but NetApp does ..!

 

SnapLock is NetApp WORM (Write Once Read Many)
Some regulated environment require business records be archived on WORM media to maintain a non-erasable and non rewritable electronic audit trail that can be used for discovery or investigation.

DataONTAP SnapLock software complies with the regulations of those markets. With SnapLock, the media is rewritable but the integrated hardware and software controlling access to the media prevents modification or deletion.

 SnapLock is available in tow version: SnapLock compliance for strict regulatory environment, and SnapLock Enterprise, for more flexible environments. SnapLock can integrates with the snap Mirror and snap vault, and snap mirror allows the SnapLock volumes to be replicated to another storage FAS1 and Lock vault backs up SnapLock volumes to a secondary storage FAS1 to ensure that if the original data is destroyed than the data can be restored or accessed from another location.

Once the data is created in the SnapLock volume they comes under the retention period and these files get treated as WORM, so that nobody can delete or modify the data until and unless it reach to its retention period, the SnapLock volumes cannot be deleted by the user, administrator nor by the application, the retention date on a WORM file is set when the file is committed to WORM state, but it can be extended at any time. The retention period can never be shortened for any WORM file.



SnapLock Compliance (SLC)
SnapLock Compliance is used in strictly regulated environment, where data is retained for longer period of time and these data are accessed frequently only for readable purpose. SnapLock Compliance even does not allow the storage administrator’s to perform any operations that might modify the file, it uses the feature called “ComplianceClock” to enforce the retention periods. SnapLock Compliance requires the SnapLock license to enable the SnapLock features and to restrict the administration access to the file.



SnapLock Enterprise (SLE)

SnapLock Enterprise allows the administrator to destroy the SnapLock volume before all the file on the volume reach their expiration date. However no one else can delete or modify the files.

It requires the SnapLock _enterprise license

Important **:
1. From dataontap 7.1 and later, SnapLock compliance and SnapLock Enterprise can be installed on the same storage FAS1.
2. Uninstalling the SnapLock license does not undo the SnapLock volume or the Worm file properties. When uninstalling the license, existing SnapLock volumes are still accessible for general reading and writing, but won’t allow new files to be committed to WORM state on the SnapLock volume, or the creation of any new SnapLock volumes.


SnapLock Configuration Steps :

   1.       Verify that the storage FAS1s time zone time and date are correct.
   2.       License SnapLock.
   3.       Initialize  the compliance clock
   4.       Create SnapLock aggregate and volume.
   5.       Set retention periods
   6.       Create files in the SnapLock volume
   7.       Commit files to a WORM stat.

*Use the “date –c initialize” command to initialize the compliance clock.

After compliance clock is initialized, it cannot be altered and WORM files, SnapLock compliance volumes, or aggregates cannot be destroyed. As compliance volume get in sync mode with the FAS1 clock, so when the volumes is taken offline then the compliance volume will get out of sync with the FAS1 clock, but when the volumes is brought online back the data ontap will start to make up the time difference, the rate at which the compliance clock catches up depends on the version of data ontap your FAS1 is running.

Creating the snaplock volumes
Snaplock type, compliance or Enterprise, is determined by the installed license.

Creating the snap lock traditional volumes
“vol create –L vol_name <n_disk>”

For example :

FAS1> vol create viptrd –L 14

For creating the SnapLock flexible volumes, you need to create the snaplock aggregate first

“aggr create –L aggr_name <n_disks>”
“vol create vol_name aggr_name <size>”

For example :
FAS> aggr create vipaggr –L 3
FAS> vol create vipflex  vipaggr 100m
FAS1> vol status vipflex (for checking the status of the vipflex volume)

Volume Retention Periods
The retention periods are the volume’s attributes. If you do not explicitly specify an expiration date for a WORM file, the file inherits the retention periods set at the volume level.

There are three retention periods per volume: a minimum, a maximum and a default.
1. Until you explicitly reconfigure it, the maximum retention period for all WORM files in a snap Lock Compliance volume is 30 years.
2. If you change the maximum retention period on a SnapLock Compliance volume, you also change the default retention period.
3. If you change the minimum retention period on a SnapLock Enterprise volume you also change the default retention period. The minimum retention period is 0 years.

 How to set the Retention Periods.

Use the vol options command to set the retention period values.

For example:
FAS1> vol options vol_name snaplock_minimum_period [{period} |min |max | infinite <count>d|m|y]
FAS1>vol options vipvol snaplock_minimum_period 1d
FAS1> vol options vipvol snaplock_default_period min

Min is the retention period specified by the snaplock_minimum_period option, max is the retention period specified by the snaplock_maximum_period option, infinite specifies that files committed to WORM state are retained forever.

For storage FAS1 using dataOntap 7.1 and later , the maximum retention period can be extended up to 70 years.
You can also extend the retention date for a WORM file before or after the file retention date has expired by updating its last accessed timestamp. This will re_enable WORM protection on the file as if it were being committed for the first time. Once the retention date expires, you can re_enable the write permission on the file and then delete it. However the file contents still cannot be modified.

Note: the SnapLock volume maximum retention period restrictions are not applied when extending the retention date of a WORM file.

Committing Data to WORM
After placing a file on a snaplock volume, the file attributes must be explicitly changed to read-only before it becomes a WORM file. These operations can be done interactively or programmatically, the exact command or program required depends on the file access protocol (CIFS, NFS, and so on) and client operating FAS1 being used.

Below command could be used to commit the document .txt file to a WORM state, with a retention date of November 21,2020 ,using a unix shell.

touch –a –t 202011210600 document.txt

chmod –w document.txt

For a windows client, to make a file read-only, right-click the file, select properties, checks the read only checkbox and then clicks OK.

The last accessed timestamp of the file at the time it is committed to WORM state becomes its retention date unless it is limited by the minimum or maximum retention period of the SnapLock volume. If the date was never set, the default retention period of the SnapLock volume is used.

If a file is initially copied read-only, it is not automatically committed to WORM state. The only way to guarantee that a file is committed to WORM state is explicitly assign a read-only attribute and optionally modify the last access time to set a retention date while the file is in the SnapLock volume.

Auto-Committing Files
A time-delay commit to WORM with an adjustable timer is available in Data Ontap 7.2 or later. If the file does not change during the delay period, the file is committed to WORM at the end of the delay period. Auto-commit does not take place instantly when the delay period ends. Auto-commit are performed using a scanner and can take some time. The retention date on the committed file will be determined by the volume’s default retention period.

To specify a time delay, set the global option snaplock.autocommit_period to a value consisting of an integer count followed by an indicator of the time period: “h” for hours, “d” for days. “m” for months, or “y” for years.

FAS1> options snaplock.autocommit_period none | [count (h | d | y)]

The default value is none and the minimum delay that can be specified is two hours.

The following example sets the auto-commit period to 24 days.

FAS1> options snaplock.autocommit_period 24d



Appending WORM File
A WORM file can be appended by simple creating an empty Snaplock file, appending data to it, and then locking the file in place again, data is committed to WORM state in 256 Kb chunks; the previous 256 kb segment automatically becomes immutable. This procedure can be done from ontap7.1 onward.

 For example:
  1.       Inside a WORM volume create a zero-length file with the desired retention date.
touch  -a  -t  303012160600 file

  2.       Update the file access time to indicate the file’s desired expiration.

  3.       Make the file read-only.
chmod 444 file

  4.     Make the file writable again.
chmod 755 file

  5.      Start writing data to the file.
echo test data > file

at this stage you have a WORM appendable file. Data is committed to WORM in 256 kb chunks. Once data is written to byte n*256K+1 of the file, the previous 256Kb segment is in a WORM state and cannot be rewritten.

  6.       Make the file read-only again. The entire file is now in the WORM state and cannot be overwritten or erased.

chmod 444 file

 Deleting WORM volumes and Aggregates

You cannot delete SnapLock compliance volumes that contain unexpired WORM data. You can delete the volume only when all the WORM files have passed their retention dates.

Note: If a compliance volume cannot be destroyed, it remains offline. It should be immediately brought online so that retention period problem can be fixed and to keep the complianceclock from falling behind.

You can destroy the compliance aggregates if they don’t contain volumes. The volume contained by a snaplock compliance aggregate must be destroyed first.

You can destroy SnapLock Enterprise volumes at any time, provided you have the appropriate authority.



**************** Please don’t forget to leave your comments ***************

NetApp Disk Sanitization

WHAT IS DISK SANITIZATION?

Disk sanitization is the process of obliterating stored data by means of overwriting patterns on NetApp system drives in a manner that prevents recovery of that data by any known recovery methods. The process consists of a drive format operation followed by the specified overwrite patterns repeated for the specified number of cycles. For SATA drives, the drive format operation is skipped because the SCSI format command is not supported on these drives.

DO I NEED A LICENSE TO RUN DISK SANITIZATION? HOW MUCH DOES IT COST?

A license is required to run disk sanitization; however, the license is free.

IS DISK SANITIZATION SUPPORTED IN DATA ONTAP OPERATING IN CLUSTER-MODE?

Yes. Data ONTAP operating in Cluster-Mode does include the disk sanitization feature.

WHY WOULD I WANT TO SANITIZE A DISK?

There are several reasons to sanitize a drive. For example, compliance or security protocols might require that drives that have been used to store sensitive data undergo a process that guarantees that the sensitive

data is not recoverable from the drive. Perhaps drives are being repurposed for a different system and need to be sanitized before being deployed. Whatever the reason, once a drive is sanitized, the data is not recoverable.

HOW DO I KNOW IF DISK SANITIZATION IS SUPPORTED ON A PARTICULAR DRIVE?

To determine whether disk sanitization is supported on a specific drive, run the storage show disk

command. If the vendor of the drive in question is listed as NetApp, then drive sanitization is supported. Disk sanitization support was introduced in Data ONTAP 8.1.1 for the NetApp 100GB SSD drive, X441A.

WHAT SECTORS OR DATA DOES DISK SANITIZATION OVERWRITE?

Disk sanitization overwrites the entire contents of the drive.

HOW DOES SANITIZATION DIFFER FROM STANDARD ZEROING?

With sanitization, any pattern can be written, including all zeroes. Random patterns can also be written. Zeroing a drive clears only the file data areas; it does not clear the entire drive.

HOW ARE BAD BLOCKS AFFECTED BY DISK SANITIZATION?

Bad blocks are removed from the grown defect list during formatting. If the bad block can be written to, then it is also sanitized.

WHAT ARE THE DIFFERENCES, IF ANY, BETWEEN FC/SAS AND SATA DISK SANITIZATION?

For SATA drives, the drive format operation is skipped because the SCSI format command is not supported.

IS IT ADVISABLE TO BYPASS THE FORMAT OPERATION ON FC/SAS DRIVES?

Yes. There is no real advantage to the format operation if there are no grown defects.

CAN YOU SANITIZE INDIVIDUAL FLEXVOL VOLUMES, LUNS, OR FILES?

No. You can only sanitize individual drives.

Performance issue on NetApp filer

Incase you receive incident from HOST/System team that there is performance issue, what will be your very basic steps for troubleshooting? 

 

1               Steps

The performance issue on filer is generally related to one of the below activities on filer:

1. SnapVault replication in progress
2. Snapmirror replication in progress
3. NDMP tape backup in progress
4. More than one of the above activities running simultaneously.

 

1.1            Check CPU utilization:

To verify that the issue is actually related to CPU utilization on filer run the below command.

As per the output below the CPU utilization is around 96% which is high and need corrective action.

FAS3050 > sysstat -c 5 -i -u -s 5

 CPU   Total    Net kB/s       Disk kB/s          Tape kB/s Cache Cache  CP  CP Disk

            ops/s    in   out          read  write          read write   age   hit time ty util

 95%    1630  5089  5448     69608   5591     0 60017     0s  58% 100%  #  22%

 98%     417    57     2114     93420      0        0 84689     0s  57% 100%  #  38%

 97%      10     4       41         86399      0        0 87375     0s  57% 100%  #  27%

 94%     851  3739   4182     91529  25743    0 73157     1s  57% 100%  b  24%

 95%    3805 19196 12931   50400  31652    0 14575     0s  61% 100%  :  50%

1.2            Check tape backup status:

The below output shows high tape write activity.We bring down CPU  utilization we can stop the tape bacukp.

FAS3050 > sysstat -c 5 -i -u -s 5

 CPU   Total    Net kB/s       Disk kB/s          Tape kB/s Cache Cache  CP  CP Disk

            ops/s    in   out          read  write          read write   age   hit time ty util

 95%    1630  5089  5448     69608   5591     0 60017     0s  58% 100%  #  22%

 98%     417    57     2114     93420      0        0 84689     0s  57% 100%  #  38%

 97%      10     4       41         86399      0        0 87375     0s  57% 100%  #  27%

 94%     851  3739   4182     91529  25743    0 73157     1s  57% 100%  b  24%

 95%    3805 19196 12931   50400  31652    0 14575     0s  61% 100%  :  50%

Stop tape backup from backup server:

1. Stop backup from backup server by aborting the related ndmpd backup group for the filer.
2. If  you still see nmdp save session on the backup server kill the save sessions.

Verify that the backup sessions are stopped on the filer by running the below command:

FAS3050 >  ndmpd status

ndmpd ON.

Session: 75

  Active

  version:                4

  Operating on behalf of primary host.

  tape device:    nrst3a

  mover state:    Active

  data state:     Active

  data operation: Backup

If you still see the active backup sessions running  issue the “ndmpd killall” command on filer.

1.3            Check SnapVault replication status:

To check the snapvault replication staus run the below command on affected filer:

FAS3050>snapvault status

Snapvault is ON.

Source                                     Destination                                 State          Lag        Status

FAS3050:/vol/VOLak1a/log  FAS6030:/vol/VOLak1asv/log  Source         09:15:13   Idle

FAS3050:/vol/VOLak2a/log  FAS6030:/vol/VOLak2asv/log  Source         08:12:43   Idle

If you see status as Transferring, Stop the snapvault replication if the CPU utilization is still very high and end users still feel slowness.

snapvault abort secondry_system:/vol/volx/secondry_qtree

For example:

FAS3050>snapvault abort FAS6030:/vol/ntest/sg

1.4            Check SnapMirror replication status:

FAS01> snapmirror status

Snapmirror is on.

Source              Destination       State          Lag        Status

              FAS01:VOL1    FAS02:VOL1     Source         02:16:47   Idle

              FAS01:VOL2    FAS02:VOL2     Source         02:19:02   Idle

              FAS01:VOL3    FAS02:VOL3     Source         02:17:30   Idle

FAS01:VOL4   FAS02:VOL4      Source     02:10:36  Transferring  (2080 MB    done)

If you see status as Transferring, Stop the snapmirror replication if the CPU utilization is still very high and end users still feel slowness.

snapmirror abort destination_filer:destination_volume

For example:

FAS02*> snapmirror abort FAS01:vol01

Mon Dec 13 20:00:51 GMT [replication.src.err:error]: SnapMirror: source transfer from asiambclr1mbdb9 to FAS01:vol01 : transfer failed.

1.5            Verify the CPU utilization

Issue “sysstat” command as below on filer to verify the current CPU utilization after performing the above steps.

FAS3050 > sysstat -c 5 -i -u -s 5

 CPU   Total    Net kB/s       Disk kB/s          Tape kB/s Cache Cache  CP  CP Disk

            ops/s    in   out          read  write          read write   age   hit time ty util

 55%    1630  5089  5448     69608   5591     0              0     0s  58% 100%  #  22%

 68%     417    57     2114     93420      0        0                0     0s  57% 100%  #  38%

 72%      10     4       41         86399      0        0      0     0s  57% 100%  #  27%

 64%     851  3739   4182     91529  25743    0      0     1s  57% 100%  b  24%

 65%    3805 19196 12931   50400  31652    0      0     0s  61% 100%  :  50%

 

1.6            Identify the cause of high CPU utilization:

Check the logs on filer and backup server to get the cause for the snapmirror/snapvault replication or ndmp tape backup were running out of window. For example: backup running out of backup window.