The document provides recommendations for configuring NetApp CIFS audit logs. It recommends having at least 2GB of space per aggregate to enable auditing. It discusses configuring the destination volume for audit logs, including keeping it under 90% full through hourly monitoring. Testing was done to analyze log file sizes with different numbers of users moving, deleting, and mixing file types. Current utilization on nodes before and after enabling auditing is shown. The conclusion recommends a phased approach to enabling auditing on common shares to monitor performance impacts.

1. NetApp CIFS Audit
Recommendations:
Every aggregate should have minimum 2GB of space in order to enable the Audit including
aggr0.
NetApp recommends to use vserver security file-directory command to configure SACLS but
in our environment we cannot do it as it will replace existing permission. Need to follow
process for new volumes. (Required inputs from Harry/Karthik) .
NetApp recommends the following to configure a destination volume
The destination volume holds the consolidated audit log files. The destination volume must
be set while configuring the audit policy.
The destination volume should never be filled up to more than 90% at any point in time,
this rule should be followed in each SVM in the cluster. To prevent it we need hourly
monitoring for destination volume.
The optimal size of the destination volume depends on the generated log size, which in
turn depends on:
Destination volume size = generated log size x [rotate limit + 1].
In our case:
7-8GB (approx.) = 240MB x [30 + 1].
NetApp recommends keeping an additional buffer of 10% to 15% in the destination volume .
Currently we have 100GB volume.
NetApp recommends the following to configure guaranteed auditing:
Guaranteed auditing is a new feature enabled by default in clustered Data ONTAP , so
audit event recorded for each and every operation, thus provide highly reliable audit for
compliance.
When guaranteed audit is enabled and the destination and staging volume is full cifs
client operation are blocked.
NetApp recommends turning off this feature if regulatory requirements do not mandate
guaranteed auditing.

2. Testing:
Test Suite 1
Consider 1000 users are moving files at a given time(PDF File Only)
Current Size of
Evtx file
After Move
size of evtx
file size
Size of files
moved
Rotation Identifications Observation
4.94MB 6.94MB 1.39GB 1
evtx file size increased by 2MB
for moving 1.39GB files
Move will
generate
two events
one for
delete and
one for
move
Test Suite 2
Consider 1000 users are deleting files at a given time(PDF File Only)
Current Size of
Evtx file
After Move
size of evtx
file size
Size of files
moved
Rotation Identifications Observation
6.94MB 8MB 1.39GB 1
evtx file size increased by 1MB
for moving 1.39GB files
delete will
generate
one event
only
Test Suite 3
Consider 5000 users are moving files at a given time(PDF File Only)
Current Size of
Evtx file
After Move size
of evtx file size
Size of files
moved
Rotation Identifications Observation
11MB 21.6MB,32.3MB 6.98GB 2
evtx file size increasedby11MB
for moving 6.98GB files
Move will
generate
two events
one for
delete and
one for
move

3. Test Suite 4
Consider 5000 users are deleting files at a given time(PDF File Only)
Current Size of
Evtx file
After Move
size of evtx file
size
Size of files
moved
Rotation Identifications Observation
32.3MB 37.6MB 6.98GB 1
evtx file size increased by 5MB for
deleting 6.98GB files
delete will
generate
one event
only
Test Suite 6
Consider 5000 users are deleting files at a given time(Mix file types xls,doc,pdf)
Current Size of
Evtx file
After Move
size of evtx file
size
Size of files
moved
Rotation Identifications Observation
78.9MB 89.5MB 24.6GB 1
evtx file size increased by 10.6MB
for moving 24.6GB files
delete will
generate
one event
only
Considering 10,000 files being moved and deleted same time, it will generate 30MB of file
every hour, accounting that every 8 hour it will generate 240MB evtx file, currently we
have 200MB file setup with 30 files rotation which will cause approx. 6-7GB space on audit
log volumes, and we have 100GB total space on that volu me.
Test Suite 5
Consider 10,000 users are moving files at a given time(Mix file types xls,doc,pdf)
Current Size
of Evtx file
After Move size of
evtx file size
Size of files
moved
Rotation Identifications Observation
37.6MB 58.2MB,78.9MB 24.6GB 2
evtx file size increased by
20.6MB for moving 24.6GB
files
Move will
generate two
events one for
delete and one
for move

4. IOPs and CPU utilization report:
Vserver: IRV_CIFS01
We have enabled audit on 24/04/2018 and below is the screenshot of statistics for node7
and node8 before enabling audit.
Node8 Utilization before Audit enabling:
Node7 Utilization before Audit enabling:
After enabling the audit below are the observations.
Node8 Utilization After Audit enabled:

5. Node7 Utilization before Audit enabled:
-----------------------------------------------------------------------------------------------------------------
Observations:
1. Only enable audit on required volumes, do not enable it on landing zone or users
profile, otherwise it will be impossible to manage the log files.
2. we need to have another common volume where we must copy all log files on
common location in every week, based on SVM name.
3. need to monitor log location as files will be overwritten after 30 count .
Currently Enabled on two vservers in IRV:
1. IRV_CIFS01for log we have created Audit_IRV_CIFS01 volume allocated
100GBusage 5%  number of log files on the volume  30 log files.
2. IRV_APPS_DEV for log we have created Audit_test volume allocated
100GBusage 5%  number of log files on the volume 4 log files (as there is no
data deleted/moved so files will be less)

6. -----------------------------------------------------------------------------------------------------------------
Current Utilization of Atlanta Nodes:
Node 8:
We have captured last 3 months’ data and below are the details
CPU utilization is around 23%
Detailed IOPs, in this screen shot we can see Avg Iops is 1672 for last 3 months.
Expectations after implementing CIFS AUDIT for Node 8
Average IOPs should reach up to 2000-2200 and CPU utilization will go up to 30% as current
is 23%.
Note: there will be other factors needs to consider, for CPU and IOPs not just AUDIT.

7. -------------------------------------------------------------------- ---------------------------------------------
Node 7:
Average CPU utilization is around 23% for last 3 months
Detailed IOPs, in this screen shot we can see Avg Iops is 2000 for last 3 months.
Expectations after implementing CIFS AUDIT for Node 7
Average IOPs should reach up to 2000-2500 and CPU utilization will go up to 30% as current
is 23%.
Note: there will be other factors needs to consider, for CPU and IOPs not just AUDIT.

8. Conclusion:
We should .
OC_SComsh
OC_SComsh1
OC_SComsh2
OC_SComsh3
OC_SComsh4
OC_SComsh5
OC_SComsh6
OC_SComsh7
OC_SComsh8
OC_SComsh9
OC_SComsh10
OC_SComsh11
OC_SComsh12
OC_SComsh13
Ocwen_Share1
Ocwen_Share2
Phase I: enable AUDIT on 5 common share, observe the Iops and node utilization and then
proceed with next phases until we are satisfied with IOPS and Utilization of nodes.
How to access Audit logs:
TXIRVNAPSTG01-08_IRV_CIFSAudit_IRV_CIFS01
You can access share and view those in windows event viewer application.
Volumes included in Audit:
For example:
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
TXIRVNAPSTG01

9. MDV_aud_fdf16480ceb740f6ac0d320a7ea0f4ff
aggr0_TXIRVNAPSTG01_07_0
online RW 2GB 1.90GB 5%
we should be monitoring these volumes as these will be used to