Yes UNC is supported because many customers use NAS devices for their storage such as NetApps

Have you validated the Share and NTFS permissions are allowing the EV Service account full access?

this should help when coming to moving the indexes

http://seer.entsupport.symantec.com/docs/273141.htm

I've successfully moved the Indexes several times on various systems at various versions but this one was hte first that I've tried a UNC path and it failed at first. I think it might be a permissions issue on the Share but the Vault Stores are in the same location and functioning fine.
I moved the Indexes to a diffferent location but would still like confirmation that a UNC path for the Index location(s) is a compatible design.

The basic requirement is that it be NTFS storage. This could be block or file based storage. See the compatibility guide: http://seer.entsupport.symantec.com/docs/276547.htm

You will want to make sure it is performant and redundant to ensure a lengthy index rebuild process is not necessary.

I've been successful in a number of installations utilizing NAS-based CIFS shares.  One consideration is that opportunistic locking must be turned off the index location if the NAS supports it.  This is evident in Sun and NetApp storage but probably has implementation in other vendors.

Key thing here, is its defnatly not best practice to have indexes on NAS.  Ask any one who knows something and they will tell you you are looking for trouble.......

As I stated above, its a temporary solution, in the option between having no Enterprise Vault funcitonality versus poor functionality, poor functionality wins for a temporary stop gap which the customer was aware of.

Op Locks are disabled, that was one of the first things I verified and I've had no issues with the Vault Stores on UNC path just never performed the Index Locaitons.

Hiya Scott,

Long time no chat.....

Are you going to be archiving or just Read Only?  If you are going to be writing you could, I'm not saying you will but you could run into index corruptions.....  but as for a temp solution, I missed that part it should be OK, its better than nothing I guess ;)

--wayne

Hey Wayne. I'm curious why you are stating it is not a best practice to have the index on NAS. You certainly need to make sure the disk subsystem supports the throughput of the index. Many NAS vendors are producing very performant and affordable storage. With these centralized network storage solutions you receive a number of benefits such as the ability to create snapshots, mirror to a DR site and quickly add storage. You get a balance of performance as well as low cost.

I've spoken to Symantec engineers about this. They've stated having the index on NAS is perfectly acceptable. I've done quite a bit of extensive testing with EV, having the indexes on both SAN and NAS.

BTW, interesting EV sites. You've got some good information and products.

Ryujin,

When I was working in Engineering Support most of the issues I dealt with index's where on NAS devices. There are a couple of other things that need to be taken into consideration however.  Before Eng Sup I was in consultancy @ Symantec and there too we stayed away from NAS on index's, but again that was on large orgs with high IOPS requirements. Index disks must be high performance, fiber-channel preferred you cannot compare SAN or DAS to NAS, there is no comparison.......

Take this one design I'm doing now, I need 2000 IOPS for searching requirements, 700 for normal journaling with the amount of volume I am dealing with, now there is no way in hell I could even consider a NAS....

--wayne

Hi Wayne,

Time for a disclaimer: I work at a large storage solutions company. We partner with Symantec in many areas, in particular archiving.

I agree about the latency problems, especially with discovery. However, a well designed storage platform should be able to easily manage those IOPs requirements even on NAS. I'm conducting some EV8 performance tests on our storage systems. Even our storage from three years ago is able to handle the archive (on SATA NAS), index (on SATA NAS) and database (on FC SAN) on a single storage controller for several thousands of users...in addition to managing more than just EV.

As long as the storage can provide the required throughput, an archive administrator shouldn't have to think or care about where the data are stored. It should be a service that you subscribe to and you should only pay for what you drink.

I personally would like to see some enhancements in the performance guide to indicate what peak and average IOPs or MB/s are needed for a particular workload. It does a great job of helping with storage sizing, but not so much with storage throughput.

Anyway...now we're a little off topic

^_^