|
Home > Archive > Data Storage > December 2007 > Promise VTRAK SAN box
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Promise VTRAK SAN box
|
|
| Darren K. Murray 2007-12-14, 1:16 am |
| Hello all,
I am new to SAN technology and I have what may be a dumb question but
here goes (first a little background):
My understanding is that one of the main differences between NAS and SAN
is the location of the file system. NAS appliances have an embedded OS
with 2 or more hard disks formatted with a file system such as NTFS.
Network access to the disks is done using a file-level protocol.
SAN appliances such as our Promise VTRAK have a bank of hard disks
connected to the network through an iSCSI controller. A server on the
network runs an iSCSI initiator to connect to the SAN appliance. It
mounts the drives, creates a LUN through which Windows (or whatever OS)
can "see" the storage as a drive letter. Communication over the network
takes place at the block-level.
My question is: with a SAN, where does the file system actually reside?
In other words, if I had the VTRAK configured as JBOD ie. 15 individual
logical drives (no RAID), could I remove one of the hard drives, put it
in a PC and see the files? Or does the server somehow create a "virtual
file system" meaning that the only way to access the data on the disks
is via the server?
Thank you in advance for any clarification that could be offered.
| |
| Lon Stowell 2007-12-14, 7:12 pm |
| Darren K. Murray wrote:
> Hello all,
>
> I am new to SAN technology and I have what may be a dumb question but
> here goes (first a little background):
>
> My understanding is that one of the main differences between NAS and SAN
> is the location of the file system. NAS appliances have an embedded OS
> with 2 or more hard disks formatted with a file system such as NTFS.
> Network access to the disks is done using a file-level protocol.
A NAS device has as many disks as it needs to provide the storage it
offers at the performance level it offers. This can range from a value
of one disk to literally thousands. To be picky, it could mean no disks
at all, using some other form of non-volatile storage.
The internal file system of the NAS device is essentially a black box to
the NAS client. The NAS client cannot directly access the file system
on the NAS device, it must use a file sharing protocol to do so, for
example CIFS [windows file and printer sharing] or NFS or for most
larger NAS devices both at once.
The OS of the NAS device may be imbedded or it may not. Again, the OS
or knowledge of the OS is off limits to the NAS client.
The protocol is not file level, it includes authentication protocols as
well as mounting and unmounting and may include network locking.
>
> SAN appliances such as our Promise VTRAK have a bank of hard disks
> connected to the network through an iSCSI controller. A server on the
> network runs an iSCSI initiator to connect to the SAN appliance. It
> mounts the drives, creates a LUN through which Windows (or whatever OS)
> can "see" the storage as a drive letter. Communication over the network
> takes place at the block-level.
>
> My question is: with a SAN, where does the file system actually reside?
The file system exists only in the SAN client. A SAN device only
provides logical disk blocks to the client. The client is totally
responsible for any data or file systems put on that SAN device.
> In other words, if I had the VTRAK configured as JBOD ie. 15 individual
> logical drives (no RAID), could I remove one of the hard drives, put it
> in a PC and see the files? Or does the server somehow create a "virtual
> file system" meaning that the only way to access the data on the disks
> is via the server?
>
> Thank you in advance for any clarification that could be offered.
Note: The SAN or NAS device may have its own operating system. That
operating system is for managing the SAN or NAS device...not providing
operating system services to the clients. The operating system inside
the SAN or NAS device might be windows based, unix/linux based, a
variety of realtime operating systems, or totally proprietary to the
vendor.
Inside the SAN or NAS device, the data or locks may be scattered all
sorts of internal arrays either for data protection, data redundancy, or
performance or all of the above.
| |
| Darren K. Murray 2007-12-15, 1:18 am |
| Thank you for the detailed explanation. If I understand you correctly,
since the file system only exists on the SAN client, if I were to remove
one of the disks from the SAN appliance and install it in a PC, I would
not see files and folders. All I would see is a jumble of raw data.
This would not be the case with a NAS appliance because the disks inside
the NAS box are formatted with a file system such as FAT, NTFS, etc.
Therefore if the NAS controller died, one could still remove the
physical disks, install them in a PC and gain access to the stored data.
Thanks again for the info and the quick response.
Lon Stowell wrote:
> Darren K. Murray wrote:
>
> A NAS device has as many disks as it needs to provide the storage it
> offers at the performance level it offers. This can range from a value
> of one disk to literally thousands. To be picky, it could mean no disks
> at all, using some other form of non-volatile storage.
>
> The internal file system of the NAS device is essentially a black box to
> the NAS client. The NAS client cannot directly access the file system
> on the NAS device, it must use a file sharing protocol to do so, for
> example CIFS [windows file and printer sharing] or NFS or for most
> larger NAS devices both at once.
>
> The OS of the NAS device may be imbedded or it may not. Again, the OS
> or knowledge of the OS is off limits to the NAS client.
>
> The protocol is not file level, it includes authentication protocols as
> well as mounting and unmounting and may include network locking.
>
>
>
>
>
> The file system exists only in the SAN client. A SAN device only
> provides logical disk blocks to the client. The client is totally
> responsible for any data or file systems put on that SAN device.
>
>
>
>
> Note: The SAN or NAS device may have its own operating system. That
> operating system is for managing the SAN or NAS device...not providing
> operating system services to the clients. The operating system inside
> the SAN or NAS device might be windows based, unix/linux based, a
> variety of realtime operating systems, or totally proprietary to the
> vendor.
>
> Inside the SAN or NAS device, the data or locks may be scattered all
> sorts of internal arrays either for data protection, data redundancy, or
> performance or all of the above.
>
>
>
| |
| Maxim S. Shatskih 2007-12-15, 7:15 am |
| > This would not be the case with a NAS appliance because the disks inside
> the NAS box are formatted with a file system such as FAT, NTFS, etc.
I'm not sure NASes use NTFS on disks. They can use their proprietary FS.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
| |
| Lon Stowell 2007-12-15, 1:12 pm |
| Darren K. Murray wrote:
> Thank you for the detailed explanation. If I understand you correctly,
> since the file system only exists on the SAN client, if I were to remove
> one of the disks from the SAN appliance and install it in a PC, I would
> not see files and folders. All I would see is a jumble of raw data.
You wouldnt even see that much if you used an ordinary file system type
utility. The only way you would see anything would be to use a raw
block based utility or something like dd.
>
> This would not be the case with a NAS appliance because the disks inside
> the NAS box are formatted with a file system such as FAT, NTFS, etc.
> Therefore if the NAS controller died, one could still remove the
> physical disks, install them in a PC and gain access to the stored data.
Wrong.
Simple nas devices might use something like windows with ntfs with disks
lain out as simple drive letters. Or Linux with ext2/ext3 file
systems, or similar. Even a simple nas device might use a proprietary
or very limited operating system with a file system optimized for
storage.
Larger nas devices use multiple disk controllers and multiple arrays.
Yes, it is possible to move those devices, but only if you move them to
something that understands the exact structure and format of the data
and you also move the metadata that describes the exact layout of the
data as it existed inside that NAS device. For all practical purposes,
this could be done on those nas architectures where the metadata and raw
device layout is contained on the physical devices, or you also moved
the hardware that contained similar info in non-volatile format.
[vbcol=seagreen]
>
> Thanks again for the info and the quick response.
>
>
> Lon Stowell wrote:
| |
| nik Simpson 2007-12-17, 1:18 am |
| Darren K. Murray wrote:
> Thank you for the detailed explanation. If I understand you correctly,
> since the file system only exists on the SAN client, if I were to remove
> one of the disks from the SAN appliance and install it in a PC, I would
> not see files and folders. All I would see is a jumble of raw data.
>
What he means is that the SAN client is the one responsible for actually
creating the file system on the disk, any SAN client that understands
the file system should be able to read the disk. For example...
1. disk served up to a Windows host
2. Windows disk management tools used to create a NTFS file system on
the disk
3. Data written to the disk
4. SAN tools used to move the dsk so that iti is seen by a different
Windows host
5. New Windows host can still read the file system, though it may have
some issues with file permissions depending on the network setup (i.e.
standalone Windows machines vs. a Windows AD environment with central
sign-on and domain accounts.)
> This would not be the case with a NAS appliance because the disks inside
> the NAS box are formatted with a file system such as FAT, NTFS, etc.
> Therefore if the NAS controller died, one could still remove the
> physical disks, install them in a PC and gain access to the stored data.
Depends on the NAS, most NAS use their own file system format (depending
on the heritage of that OS running on the NAS, this could a UNIX
derived, LINUX derived or Windows derived file system. Best bet for
recovering data from a NAS device would be to install the drive in a
similar make & model of NAS device which will understand the file system
format.
--
Nik Simpson
| |
| Spindle 2007-12-21, 1:18 am |
| On Dec 13, 11:58 pm, "Darren K. Murray" <it...@shaw.ca> wrote:
> Hello all,
>
> I am new to SAN technology and I have what may be a dumb question but
> here goes (first a little background):
Not a dumb question at all.
>
> My understanding is that one of the main differences between NAS and SAN
> is the location of the file system.
Not quite. A NAS gives you access to a file system using networking
protocols. A SAN gives you access to a virtual volume, a LUN, using
a connectivity protocol suc as iSCSI or FC
> NAS appliances have an embedded OS
> with 2 or more hard disks formatted with a file system such as NTFS.
> Network access to the disks is done using a file-level protocol.
Correct!
> SAN appliances such as our Promise VTRAK have a bank of hard disks
> connected to the network through an iSCSI controller
There isn't such a thing as an iSCSI controller or a FC controller for
that matter. It helps to think of both protocols as shuttle services
that move data and SCSI commands between two points: an initiator
(the server) and a target (the storage device)
> A server on the
> network runs an iSCSI initiator to connect to the SAN appliance.
correct so far
> mounts the drives,
No, what drives are you talking about? The drives are on the target.
The server cannot mount drives.
> creates a LUN
The server doesn't create the LUN, the target does, using extents from
the drives available locally. The server simply gains access to that
LUN via iSCSI
> through which Windows (or whatever OS)
> can "see" the storage as a drive letter. Communication over the network
> takes place at the block-level.
Yes
>
> My question is: with a SAN, where does the file system actually reside?
here is the same conceptual error again: A SAN doesn't know what a
file system is. Your server creates the FS
after making a volume out of a LUN prepared by the iSCSI target and
accessed from (made available thanks to) the iSCSI initiator
> In other words, if I had the VTRAK configured as JBOD ie. 15 individual
> logical drives (no RAID), could I remove one of the hard drives, put it
> in a PC and see the files?
Oh my! When the target creates a LUN you have no idea on the
server if that LUN fits exactly a volume or not.
> Or does the server somehow create a "virtual
> file system" meaning that the only way to access the data on the disks
> is via the server?
Again not the server, but the target creates that LUN (no knowledge of
file systems in a SAN, remember?) so only the target has the pointers
to retrieve that LUN and the coordinates of the file system the
server created
>
> Thank you in advance for any clarification that could be offered.
You're welcome. But feel free to ring again if it's not clear.
[vbcol=seagreen]
| |
| Darren K. Murray 2007-12-21, 1:18 am |
|
Thank you for the clarification. I understand now that many of the
functions I was attributing to the initiator and server are actually
being done by the target at the other end of the network.
Until recently I had only worked with direct attached storage and I was
having a hard time wrapping my head around the low level details of a
SAN. Thanks again for taking the time to write.
Spindle wrote:
> On Dec 13, 11:58 pm, "Darren K. Murray" <it...@shaw.ca> wrote:
> Not a dumb question at all.
>
> Not quite. A NAS gives you access to a file system using networking
> protocols. A SAN gives you access to a virtual volume, a LUN, using
> a connectivity protocol suc as iSCSI or FC
>
>
> Correct!
>
> There isn't such a thing as an iSCSI controller or a FC controller for
> that matter. It helps to think of both protocols as shuttle services
> that move data and SCSI commands between two points: an initiator
> (the server) and a target (the storage device)
>
>
> correct so far
>
> No, what drives are you talking about? The drives are on the target.
> The server cannot mount drives.
>
> The server doesn't create the LUN, the target does, using extents from
> the drives available locally. The server simply gains access to that
> LUN via iSCSI
>
> Yes
>
> here is the same conceptual error again: A SAN doesn't know what a
> file system is. Your server creates the FS
> after making a volume out of a LUN prepared by the iSCSI target and
> accessed from (made available thanks to) the iSCSI initiator
>
> Oh my! When the target creates a LUN you have no idea on the
> server if that LUN fits exactly a volume or not.
>
> Again not the server, but the target creates that LUN (no knowledge of
> file systems in a SAN, remember?) so only the target has the pointers
> to retrieve that LUN and the coordinates of the file system the
> server created
> You're welcome. But feel free to ring again if it's not clear.
>
| |
|
| In article <LXo8j.2234$_r2.1227@pd7urf1no>, itech@shaw.ca says...
>
>Hello all,
>
>I am new to SAN technology and I have what may be a dumb question but
>here goes (first a little background):
>
>My understanding is that one of the main differences between NAS and SAN
>is the location of the file system. NAS appliances have an embedded OS
>with 2 or more hard disks formatted with a file system such as NTFS.
>Network access to the disks is done using a file-level protocol.
>
>SAN appliances such as our Promise VTRAK have a bank of hard disks
>connected to the network through an iSCSI controller. A server on the
>network runs an iSCSI initiator to connect to the SAN appliance. It
>mounts the drives, creates a LUN through which Windows (or whatever OS)
>can "see" the storage as a drive letter. Communication over the network
>takes place at the block-level.
>
>My question is: with a SAN, where does the file system actually reside?
>In other words, if I had the VTRAK configured as JBOD ie. 15 individual
>logical drives (no RAID), could I remove one of the hard drives, put it
>in a PC and see the files? Or does the server somehow create a "virtual
>file system" meaning that the only way to access the data on the disks
>is via the server?
>
>Thank you in advance for any clarification that could be offered.
it's even easier than that
a NAS iks a disguised file server that looks like a storage subsystem
a RAID (which is what your SAN storage is) is a bunch of hard drives,
typically striped together using a hardware controller in the same enclosure
that makes them all look lile one large hard drive) that "acts" the same way
as the hard drive that's attached directly to your computer. In computer talk
the NAS is called "file level" storage & the SAN storage is called "block
mode" storage.
& BTW, since SAN means Storage Area Network. w/ Network being the operable
word, if you attach a RAID to an iSCSI network OR a Fibre Channel network
they will be functionally the same.
_____ . .
' \\ . . |>>
O// . . |
\_\ . . |
| | . . . |
/ | . www.EvenEnterprises.com . . . |
/ .| info@EvenEnterprises.com . . . |
/ . | 310-544-9439 / 818-302-3344 fax . . . o
----------------------------------------------------------------------
Authorized - DIRECT VAR/VAD/Distributor for new mid-high end storage
iSCSI/NAS/SAN/RAID/Tape Libraries from HP, Quantum, White Box, Etc.
|
|
|
|
|