Nas server for CAD projects

[sebastien_seb]

Hi,
I work in a small engineering office with two partners. We use Pro/engineer Cad software and we’d like to set up NAS server to storing and accessing 3D cad projects.

Currently we have a small Synology NAS only used to back up and exchange heavy files. When we work on cad project we copy files locally to work and then copy back on the nas. It’s a waste of time and we can make mistakes easily (erasing versions accidentally …).

Do you know if we can use NAS to storing and accessing files over my small network (3 computers)? We want just to access those files through the network in the centralized location.

On average CAD files project sized 200 Mo and we have gigabit network (switch, Ethernet card, …). We won’t work at the same time on the same project.

After reading some tests, I am interesting by Qnap Ts-119P+. Do you think it’s suitable for our use?

Thanks !
Seb

 

[thiggins]

What model Synology do you have and have you tried editing files directly on it? You might get better performance using iSCSI, which will support block level transfers.

 

[sebastien_seb]

Hi Tim,
we've got Synology DS107+ however it plugs on our standard Ethernet 100 Mb. This NAS works when we open small CAD assemblies (20Mo max.). About our "network CAD project", we plane to set up gigabyte network. I've checked Qnap Ts-119P+ specifications and it's suitable with iSCSI protocol.

 

[thiggins]

Both Synology and QNAP support iSCSI. But you might find QNAP's iSCSI implementation has more features.

If you're going to stick with lower-end products, spend a bit more for the highest-end Marvell processor you can get, which would mean the just-introduced TS-119P II.

 

[GregN]

Hi Tim,
we've got Synology DS107+ however it plugs on our standard Ethernet 100 Mb. This NAS works when we open small CAD assemblies (20Mo max.). About our "network CAD project", we plane to set up gigabyte network. I've checked Qnap Ts-119P+ specifications and it's suitable with iSCSI protocol.

With iSCSI, you get better performance, but NTFS is not a shared filesystem, you'll be unable to share files from the NAS across workstations. Neither is HFS+

For better performance take a look at QNap TS-219P+, if you put a managed switch, which supports aggregation in from of the NAS you'll get much better performance.

The other option is to run iSCSI through a plain old pc, and put your managed switch in-front of that, aggregating both the connection to the PC (SMB2) and the NAS (iSCSI).

In this config the filesystem management and sharing are handled by the PC, block storage is handled by the NAS. This configuration is recommended for cheap animation workstations, where I/O is critical for rendering.

Hope that helps

 

[thiggins]

With iSCSI, you get better performance, but NTFS is not a shared filesystem, you'll be unable to share files from the NAS across workstations. Neither is HFS+

Can you elaborate, Greg? QNAP's iSCSI implementation supports shared LUNs, doesn't it? So multiple users will be able to access the same iSCSI target, no?

His application doesn't require simultaneous multiple user access to a file.

 

[GregN]

Can you elaborate, Greg? QNAP's iSCSI implementation supports shared LUNs, doesn't it? So multiple users will be able to access the same iSCSI target, no?

His application doesn't require simultaneous multiple user access to a file.

The issue isn't whether you can share a LUN, it appears that QNap will allow you to share a LUN. The problem is with the filesystem you put on the LUN. iSCSI just serves up raw blocks, filesystem I/O and maintenance is done by the systems mounting the LUN.

The filesystem has to be a shared filesystem if you don't want to risk corruption.

Sharing of a single file isn't the issue, it is making sure there isn't any write block or FS meta-data collisions - causing corruption.

Many folks solve this problem by using a VM filesystem on the LUN, such as VMFS from VMWare, but that has its own set of restrictions. The hypervisor coordinates the writing - insuring no corruption of the underlying filesystem ( or blocks ).

 

[stevech]

for the OP's need - if each user had his/her own folder, with owner-only access, then file sharing, in the sense of 2+ users having the same file open for writing, wouldn't be an issue?

 

[GregN]

for the OP's need - if each user had his/her own folder, with owner-only access, then file sharing, in the sense of 2+ users having the same file open for writing, wouldn't be an issue?

What if the file User 1 is working on expands, just as User 2 downloads a new template - who gets the next free block? What happens to the corresponding pointers? Who is in charge of the free block garbage list?

The nature of iSCSI is commands are formed like "Write this data to this block", "Read that block" - there is no inherent locking, no concept of "open for writing", or even what a file is - the Filesystem handles all that bookkeeping, and iSCSI has no understanding of the overriding filesystem. With a non-shared filesystem, there is the expectation of single machine access, P&V atomic semaphores, etc. They don't work across machines.

Imagine highways and byways without a stop light or even a yield sign. With a few cars you can probably get away with it, but would you put your kid in one of those cars?

Sooner or Later, a matter of time, there will be corruption - structuring the data this or that way can only reduce the probability - you need a filesystem that is designed to deal with the inherent conflicts and race conditions.

 

[GregN]

A Picture of the suggested high performance iSCSI approach

 

[stevech]

What if the file User 1 is working on expands, just as User 2 downloads a new template - who gets the next free block? What happens to the corresponding pointers? Who is in charge of the free block garbage list?

The nature of iSCSI is commands

I was thinking about simpler SMB/file system shares for their NTFS based computers.

 

[GregN]

I was thinking about simpler SMB/file system shares for their NTFS based computers.

To quote the late Gilda Radner/Emily Litella, "Oh, nevermind"

3D CAD packages exist in that special category of applications, they need fast disk access - as fast as possible. Slow disk, slow render time....


( and I really don't understand the big deal about Gov. Perry's Deaf Penalty stance... he wants to give them all possible hearing )

 

[thiggins]

So how does Windows Server work using NTFS?

 

[GregN]

So how does Windows Server work using NTFS?

Not sure the question, what do you mean? iSCSI vs SMB? Collision Management? Filesystem semantics?

iSCSI just operates at a different level of abstraction. NTFS/CIFS understands what a file is, has locking semantics, etc

 

[thiggins]

I meant that Windows Server uses NTFS volumes, so why does it provide reliable shared storage while a shared iSCSI LUN that is NTFS formatted does not.

You provided the answer in that it is CIFS (or AFP or NFS) that provides the coordination mechanisms for shared volumes.

This might be a good article...

 

[teknojnky]

iscsi is to sharing, in the same way that an external drive connected to 2 computers (if that were possible).

iscsi has no built-in method of access arbitration/file-locking/etc.

it simply provides a block level device (raw drive), that a remote computer can connect to. The remote computer is the device which understands the media format (ntfs/ext3/4/hfs/etc) and controls access to the files contained within.

The iscsi server/service, does not know or care anything about the data or how it is arranged (formatted).

You can not simply connect multiple computers to the same iscsi disk, because each remote computer is not aware of what the other remote computers are read/writing. And attempting to do so, will sooner or later trash any data stored on the iscsi disk.

Note however, that iscsi can be shared in certain circumstances, such as virtual servers clustered together, but understand it is the cluster that controls access and prevents the servers from mangling the filesystem, not the iscsi itself.

 

[GregN]

NTFS does not support unarbitrated sharing. The operating system on the machine that the disks are connected to arbitrates file access, using queuing, locking, permissions etc to access/change to the file system. iSCSI skips past that arbitration.

In File sharing systems you address the file, in iSCSI you address the disk blocks directly.

There are file systems that do handle sharing, the Global Filesystem (GFS) from Redhat, VMFS from VMWare, XSan from Apple. They come in two flavors ( sort of ) Symmetrical and Asymmetrical. The difference is that asymmetrical uses a metadata server to arbitrate the block access, where symmetrical each node arbitrates access using stored metadata.

I talked about this in my forum posts around my DIY SAN article, about the need for a DAS server.

This might be a good article...

*chuckling* I pitched you (obviously not very well) an article about this very subject ( and multi-pathing, FC & iSCSI ), it is sort of the holy grail of problems, how do you get a whole set of windows machines to share a LUN via iSCSI?

One approach is to share a LUN via VMFS, you'd need a separate virtual machine for each network node on the target SAN. The iSCSI servers ( under either a virtualized FreeNAS or OpenFiler instance ) would talk to the VMFS through the hypervisor, which would do the arbitration. This would allow you to mount, using the MS iSCSI initiator, the same NTFS hard disk (LUN) on each client windows machine - it would look like just another local disk. Very Cool.

The downside to that approach is that VMFS is currently limited to 2TB LUN size.

I don't see another open-source sol'n right now, GFS2 is open source, but as far as I know there is no GFS driver for windows. You would need a way to tell diskpart (and windows) how to handle GFS formatted disks.

There are shared filesystems that have a windows driver, but they are all pay for, like Oracle's.

 

[sebastien_seb]

Hi everybody,
many thanks for your responses, I haven't expected so much !
I am not yet very sharp in local network and some terms are very confusing for me but I keep pushing.

I give you just some details. We've planed to invest in a PLM system to manage CAD projects between three CAD workstations. For the moment issue is the cost, average 30 000 $ including training, server, software,.... Concequently we postpone our PLM project.

For few months we'd like to try the low cost "NAS solution". We are aware it is less efficient like PLM system especially concerning files access between users, etc... But we can resume our use like this way : one engineer will work one day on one project, just like that. We will never work together on the same CAD project the same day with our NAS system.

If we respect this way everyday I believe we can avoid some back up crash files or other inconvenient, don't we ?

Seb

 

[teknojnky]

If we respect this way everyday I believe we can avoid some back up crash files or other inconvenient, don't we ?

most likely you should be fine.

I would still highly recommend a scheduled backup of files (hourly and/or nightly), even if you simply copy the files to a backup share, it will help avoid downtime just in case some file becomes corrupted.

an external usb drive with weekly backups also a good idea.

 

[GregN]

Seb,

You were looking for a solution and fell into a nerdfest around wire protocols and filesystems, sorry.

Did you see the picture I posted?

How big an issue for you is performance? That would be my only concern on a simple NAS approach.