Are these two separate questions ?

Yes. I should had made it clear.

> We have MultiScan running on cluster so often, also snapshot delete because the replication policies runs for every hour. So there is very less time frame left for FSA and it hardly succeeds for every 3 days. Unable to determine why MultiScan is running very often.

Are these separate MultiScan jobs, or is it a single one that is interrupted often? (Check for the job id.)

Do the MultiScan jobs (including recent ones) succeed, fail or get system-cancelled?

Are you seeing nodes reboot, or are you smart-failing and re-adding drives?

Is upgrading to 7.1 an option, where (certain, but reasonable combination of) jobs can run in parallel?

Its the same MultiScan job running for days and completes once in a while.

There was a node reboot because of a big related to time sync issue. We were said to setup NTP as a workaround by EMC.

No drive failures from the past 1 month, so no smart fail and re-adding drives.

Up gradation is not an option for coming few weeks.

i am using CNAME records that point to NS records, probably an overkill because in case of a disaster i could change my NS record to point to the A record of DR cluster.

Ok, so it's just working as designed.

We allow SnapshotDelete to run only once a day for upto 4 hours

via a special impact policy modeled after the OFF_HOURS policy.

Seems that MultiScan can work more efficiently when not interrupted too often.

Did you ever had issues using CNAME records - intermittent connection issues for SMB shares, mentioned by Higgs

I haven't noticed any kind of drive failures, looked at the change request management tool and no requests about drive replacements. Is there a specific log in Isilon that logs the drive failure ?

MultiScan job dint fail but its interrupted by SnapshotDelete all the time, and still unable to figure out whats causing the MultiScan job to run so often. Does replication policies has any kind of impact on MultiScan? we have replication jobs that runs for every 10-15 minutes

no issues, we have had our cluster for 3 years now. I have multiple subnets, each subnet has two pools, one pool is for CIFS client and is configured using Static IP allocation, second pool is for NFS clients and is configured with Dynamic IP allocation. DNS configuration is like this:

CNAME > NS Record

NS Record > A Record (this A record is configured as SmartConnect service IP)

> I haven't noticed any kind of drive failures, looked at the change request management tool and no requests about drive replacements. Is there a specific log in Isilon that logs the drive failure ?

For a drive to be replaced an event will be triggered

(only AFTER the FlexProtect job has succeed, which is faster than MultScan).

isi status -n

will show show you the status of all drives.

/var/log/messages has the drive stalls and group changes, 

in case you see excessive amounts of those without drives getting

smartfailed, have the logs reviewed by support.

> MultiScan job dint fail but its interrupted by SnapshotDelete all the time, and still unable to figure out whats causing the MultiScan job to run so often. Does replication policies has any kind of impact on MultiScan? we have replication jobs that runs for every 10-15 minutes

Confused. Now what exactly do you mean by so often? MultiScans proceeds when job engine policies permits it,

so a single job pops up again and again in the intervals between the SnapshotDeletes, until it finishes.

No magic in here, what else would you expect?

(As said earlier, that interval better be a day rather than a hour.)

Or do you mean, why does one job take so long? Yes, it can take days to weeks,  often seen on high density nodes

(like NL 400 with 3TB or 4TB drives), and with "many" files (like hundreds of millions on small clusters).

Replication (SyncIQ)  isn't part of the job engine, so there is no connection through policies or priorities.

But for sure it adds load to the cluster when running. Same statements are true for NDMP backups.