What's the difference between SAN and NAS?

[Michael]

It's a bit like some NVRs (Network Video Recorders), which have the cameras on their own range 192.168.254.xx, instead of your normal internal range 192.168.0.xx. Typically you can then only talk to the NVR directly, rather than the cameras.

 

Likewise, you can only talk to the SAN via your Windows Server, not your SAN directly, whereas you can talk to a NAS directly as it's on the same range (normally).

[Norphy]

So is a SAN used more where it's a permanent fixture (as in, the same result could be created by slapping another disk in a server)?

 

There is no right or wrong answer to this. I've used SANs just to provide additional storage to servers before. Hell, a few years ago @Roberto and I used an incredibly expensive HP Storageworks Fibre SAN as the database store for our Exchange server. Terribly overengineered but the SAN was bought for a clustering project which failed and up until that point, it was just holding the desk down. The advantage is that the data isn't stored on the server itself so it goes bang, you can just connect another server to the LUN and be off. SANs tend to be more resilient than servers on their own so there are advantages to doing that way.

 

Databases, for example, were mentioned earlier. I'm guessing a SAN wouldn't be used for, say, user home folders, but might be used to ensure a server could always access the database (and users would run whatever software needed the database from the server?) rather than being used for users to access files?

 

I was talking more about clustered databases. Have a pair of servers connected to the SAN in an active/passive or active/active configuration. If one of the servers dies, it switches over and there is no service loss. Also helps for load balancing where the disk throughput isn't the issue.

 

Or could it be used for user home folders by cutting the drive into smaller chunks and assigning each user their own individual LUN?

 

You could but that would be a hell of a lot of management overhead. Not ideal.

 

If the SAN exists separate from the main network, what bridges the gap?

 

The server itself is still connected to your main network. The server will have two or more NICs. One will be connected to the main network switch, the other will be connected to a switch which has the storage devices on. Your clients don't connect to the SAN directly, they connect to the servers which are connected to the SAN.

Edited June 13, 2016 by Norphy

[Oaktech]

In my particular network, I have both SAN and NAS.

 

The servers themselves have 2x 300gb SSD in them in a raid 1 holding just the OS (in VMware it's possible to do this with just an SD card) this allows me to then set up HyperV on the machines and to see the SAN as locally attached storage which can then contain the hard drives of other virtual machines.

 

The SAN is an enclosure with 17TB in it. It is connected for data movement to 2 servers via 4x 10gb fibre with a pair of 10gb fibre switches in the middle of it all. The fibre network is not connected to the normal gigabit network in any way. The SAN enclosure is connected for management to the normal gigabit network on a special vlan that only the servers and my workstation have access to, this is a nice touch, but not 100% necessary.

 

I use iSCSI and multipath IO to point the 2x 10gb adapters in the servers, to the 2x interfaces on the SAN. They use static IPs in the 10.10.0.0 and 10.11.0.0 ranges. The Switches are redundant in as much 1 sits in the 10.10 range and one sits in the 10.11 range. Because each server has one adpater in each range if one switch expires, or one adapter expires, or one controller in the SAN expires the other will simply continue to function at a reduced rate.

 

Because my servers are clustered my SAN is set up with 1 LUN and 2 volumes. The LUN is mapped to both servers and using MS HyperV clustering one volume is the Quorum witness and one is the general storage. Windows maps the general storage with a disk letter on the owner server, and as a folder within the C drive structure. The server which is not the owner has it mapped solely in the C drive structure so both servers can see the same storage simultaneously. This setup is curious to HyperV and I recommend you read up about how VMWare does it because it is significantly simpler in VMware.

 

The Servers are connected to the normal gigabit network via 4x network adapters configured in a team to give failover should one cable/port expire. Each server is connected to a different infrastructure switch. Should an individual switch expire HyperV will notice this and transition the running Virtual machines from the network disconnected host to one with network using a separate network card within each server which is designated within HyperV for the purpose.

 

The NAS is a box that contains our backups. It is connected to our normal gigabit network with an IP reservation. It has 2 network interfaces which can be set up in a variety of ways - specific to a separate VLAN, load balancing, teaming, or redundancy. We have it set load balancing. Each of our servers is mapped directly to it within Windows Server Backup using a UNC path (mapped drives are not a good idea in case of ransomware) The credentials and permissions are maintained within the NAS although the NAS has the facility to read AD to set windows permissions. It can also set permissions based on MAC or Linux.

 

I expect I've just muddied the waters, but I hope this is in some way interesting.

[Davit2005]

Typically SAN would consist of multiple hardware dedicated to storage. If you look at Fibre Channel it is a bit more defined as a SAN as you will most likely have dedicated hardware such as Fibre Channel switches.

 

But yes it is a bit muddied, for instance you can run iSCSI from FreeNAS and present the storage to VMWare and then format it within VMWare.

 

However with a NAS you could set up as FTP, SMB etc and access from any machine.

 

Hope not even more

Edited June 13, 2016 by Davit2005

[pcstru]

So is a SAN used more where it's a permanent fixture (as in, the same result could be created by slapping another disk in a server)?

Not really. A SAN decouples raw storage from physical servers in a way that makes provision of raw (block) storage very flexible. When you add more storage to the SAN, it is potentially available to any server with some basic software configurations changes. With the right kind of file system making use of the block storage, it can be available to multiple servers (physical or logical) simultaneously. So we can plug a big block of SAN storage into 3 different physical boxes running VMWare's ESXi, and then we can store our VM's on that and run up the guest on any of the 3 boxes.

 

An NAS on the other hand IS a complete file server. It's aim is to service end users directly. A SAN usually only services infrastructure directly - i.e. someone uses it as the back end of their file server (and typically many other servers).

[mavhc]

The reason to get a SAN is because you have 10s of VMs and multiple VM hosts. The VMs can then be moved between the hosts easily, because the storage is not in the hosts, it's on another device that hopefully is so simple it doesn't need rebooting, security updates, etc.

 

100s of teachers doing reports in SIMS? Move the other VMs to another host so SIMS can use all 64GBs of RAM.

 

So it's sold as an external storage that's almost as fast as having it internal, but can be shared between machines (though not at the same time normally). It's networked to get multiple users, not to get to computers 100s of metres away. So the network is generally within your network cabinet(s) in one room, and fiber optic for speed.

 

NAS is a computer with drives in, like any other, but with more drives, and probably only does a few things, might run Windows/Linux, or some custom NAS OS maybe based on one of those if it's more of an appliance.

 

In general iSCSI is used for SANs, and SMB etc for NAS, but as they're just software both can do both.