Talk:Storage area network/Archive 1

Tidy and trim

Just had a good go at the intro. It's not perfect, but this article *really* needs a thorough going over to get a lot more clarity and consistancy into it - imho !

Snori 18:58, 29 March 2007 (UTC)

After cleanup

I found some information to be false/irrelevant/confusing/redundant. I feel this artice is better without it. I'm saving it here as if anybody cares:

SAN storage is still a one-to-one relationship. That is, each device, or Logical Unit Number (LUN) on the SAN is “owned” by a single computer (or initiator).

A SAN attached storage array can replicate data belonging to many servers to a secondary storage array. This secondary array can be local or, more typically, remote. The goal of disaster recovery is to place copies of data outside the radius of effect of an anticipated threat.

Newer SANs allow duplication functionality such as “cloning,” “Business Continuance Volumes” (BCV) and “snapshotting,” which allows for real-time duplication of LUN, for the purposes of backup, disaster recovery, or system duplication. With higher-end database systems, this can occur without downtime, and is geographically independent, primarily being limited by available bandwidth and storage. Cloning and BCVs create a complete replica of the LUN in the background (consuming I/O resources in the process), while snapshotting stores only the original states of any blocks that get changed after the “snapshot” (also known as the delta blocks) from the original LUN, and does not significantly slow the system. In time, however, snapshots can grow to be as large as the original system, and are normally only recommended for temporary storage. The two types of duplication are otherwise identical, and a cloned or snapshotted LUN can be mounted on another system for execution, or backup to tape or other device, or for replication to a distant point.

These “islands” would be backed up over the network, and when the application data exceeded the maximum amount of data storable by the individual server, the end user would often have to upgrade his server to keep up.

In addition, modern SANs allow enterprises to intermix FC SATA drives with their FC SCSI drives. This allows enterprises to have multiple tiers of data that will migrate over time to different types of media. For example: many enterprises relegate files that are rarely accessed to FC SATA while keeping their frequently used data in FC SCSI.

This feature allows higher overall performance for writing to the controller, and in some cases (like for contiguous file access where read ahead is enabled) reading from the controller.

A centralized storage area network can contain many heterogeneous servers connected to one single storage space. The single storage space can have heterogeneous storage entities or disk drives. Centralized storage area networks are useful for simplifying the storage architecture in large organizations. The storage space can be treated as a black box so that administration of storage is easy. Centralized storage area networks are compatible with many different server environments including HP-UX, Solaris, Linux and Windows-based servers.

A distributed storage area network contains many geographically dispersed disk drive networks. All the networks are treated as one unit and are connected by the iSCSI storage area network protocol. Distributed storage area networks is a sub-network of shared storage devices that allows for all information stored to be shared among all of the servers on the network. Distributed storage area networks are most popular in large organizations with geographically dispersed storage pools, that can be connected and communicated through iSCSI.

The most common SAN technology is Fibre Channel networking with the SCSI command set.

It can also be extended natively using signal repeaters, high-power laser media, or multiplexers such as DWDMs.

In a typical large LAN-installation, each of a number of servers (and perhaps mainframes) may have its own dedicated storage device. If a client needs access to a particular storage device, it must go through the server that controls the device. In a SAN, no server sits between the storage devices and the network; instead, the storage devices and servers are each linked directly to the network. The SAN arrangement improves client-to-storage access efficiency, as well as direct storage-to-storage communications for backup and replication functions.

Remote replication enables the data center environment to exist in multiple locations for disaster recovery and business continuity purposes.

SANs in a Small Office / Home Office (SOHO)

With the increasing rise of digital media in all phases of life and its effect on storage needs, it’s natural that SANs have begun to enter into the SOHO market. Historically, this market was dominated by NAS systems, but SOHO is poised to become a major market for SAN infrastructure as SOHO performance requirements rise.

Systems such as film scanners and video editing applications require performance that cannot be provided by traditional file servers. For example, motion picture film at 2048x1536 requires more than 300 Mbyte/s for each real-time stream, and several of these streams can be required simultaneously. As a result, several Gigabits per second can be required, which creates a problem for standard NAS technologies. In addition, these systems need to work with the same files collaboratively, so they cannot be distributed through different file servers or DAS connections.

Instead of having many computers connected to the network, with each one requiring a low bandwidth and only the server being stressed under heavy traffic, the SOHO “real-time” area only needs to integrate a few systems, but all of them require high bandwidth to access the same files. These problems are addressed very well by 4 Gbit Fibre Channel SAN infrastructures, where the aggregated bandwidth for sequential I/O operations is extremely high.

Volume-level vs. File-level sharing

The simplest form of SAN management consists in allowing one computer to write to a given volume while other computers can only read from it. To achieve this, a SAN management software only needs to mark the given volumes so they appear as “read only” to the OS on all but one computer, and let the OS manage the volume as it normally does.

By allowing all computers in the SAN to participate in both read and write operations on a common volume, file-level sharing offers significant savings and workflow benefits over the volume-level approach. Superior collaboration results when everyone has full access to files, folders, and projects. In addition, no storage provisioning is required as the entire volume’s space is available to all projects. However, resolving arbitration at the file-level is far more complex. A reliable mechanism must ensure that multiple computers writing to a shared volume do not corrupt the shared file system.

Storage Virtualization is commonly used in SANs. Virtualization of storage helps achieve location independence by abstracting the physical location of the data.

--Kubanczyk 19:05, 24 August 2007 (UTC)

It isn't really necessary to save old material in the talk page; if anyone cares about it, it's all in the page history. Paul Koning 20:18, 24 August 2007 (UTC)

Doh, it would be lost then. Nobody actually reads for fun through all the history. I included it, because it is not totally useless, it just doesn't fit here. Some people, including me, might re-use it in future (add to other suitable article?). --Kubanczyk 20:35, 24 August 2007 (UTC)

References

Commercial Links

Perhaps I'm just naive, but there seem to be a lot of commercial links that have been added over time. (And are being removed...) Is this typical for articles about technologies like this? Feel free to smack me down if I remove a link that should stay. Straif 15:52, 8 March 2006 (UTC)

If a commercial link is present, isn't it up to the reader to decide whether or not to go to that page? It doesn't say that a particular company is the best to get this product from, it just says if you want info go to this link. It isn't as if you go to this one site you have to buy something from them. In the end, shouldn't it just be the reader's choice? Gigeoff 17:30, 13 September 2007 (UTC)

No. It's [WP:SOAP|Wikipedia policy]. Paul Koning 17:50, 13 September 2007 (UTC)

I've just read the article (as of 14:55, 25 September 2006 (UTC)) and I've found it to be very well written, however there did seem to be an undercurrent of bias towards particular technologies (note the explicitly listed out flaws in SATA, which aren't present in the SATA article), and a relatively low ration of wiki-links:volume text. -- Jon Dowland 14:55, 25 September 2006 (UTC)

The use of "network" in conjunction with Storage Area Network is oxymoronical at best. Fibre Channel is a channel protocol, not a network protocol. iSCSI does not make a SAN either, as it is an application operating over a TCP/IP network. Apparently, Wiki lacks standards about terminology accuracy as well as capitalization.

The important thing that is often overlooked about FC fabrics (oxymoronic "SANs") is that they deliver a "drink of storage" to any application that uses them for storing data. This drink of storage is undifferentiated, meaning that a high performance transaction processing app gets exactly the same drink as a very low performance app. Under the circumstances, and in the absence of good management technology, "SANs" tend to be the most expensive platform ever developed for storing data. They are a one-size-fits-most infrastructure that fits no application especially well.

These two insights are argued in The Holy Grail of Network Storage Management, which I wrote and which was published by Pearson/Prentice Hall in 2002. 207.90.20.22 23:14, 9 January 2007 (UTC)

Area Networks cruft?

Some strage text appears in line two. The text currently appears as:

Lailamillie Lahgfjcbc Bxhf

It appears to be a result of a reference to {{Area networks}}, as such:

The anomoly is affecting multiple pages with the same reference. Perhaps a wiki expert can track down the source?

Vandalism in the transcluded template reverted. Materialscientist (talk) 21:32, 25 October 2011 (UTC)

Thanks very much. — Preceding unsigned comment added by 74.95.36.73 (talk) 23:50, 25 October 2011 (UTC)

Citation

"Some studies indicate that SATA drives have lower performance, a higher failure rate, higher capacity, and lower prices than SCSI. This allows enterprises to have multiple tiers of data that will migrate over time to different types of ."

This needs some citation or further research even. From what I understand the latest studies don't necessarily show this trend.

You're wrong, this is a well known fact in hard disk manufacturing, you can convice yourself by looking for the price of an SAS disk 10k rpm 300 GB and a SATA disk 10k rpm 300 GB from the same manufacturer. Furthermore FC disk are much more expensive Thibault.ketterer (talk) 12:00, 19 December 2007 (UTC)

If something is a "well known fact" it should be easy to dig up a citation that says so. That's the whole point of asking for citations -- the article is supposed to inform those who are not insiders, and claims of fact should be supported by citations that someone can go read to see the original work and evidence.

That said, I would dispute your assertion for two reasons. First, there are studies (e.g., from Microsoft research, I'll have to dig up the citations :-) ) that show measured data for different drive types, and which contradict the "well known fact". Second, the fact that two products have different price just means they have different price -- it does not necessarily mean they have different reliability.

Paul Koning (talk) 17:42, 19 December 2007 (UTC)

Experience, as funny as that may sound, can still contradict research. Take a datacenter with a few thousand spindles on SAS/FC drives, and a few hundred on (enterprise grad, raid certified!!!) SATA drives. the failure rate on the SATA drives has been higher.

Agreed that the price is not an indicator, it could just be overpricing.about the raea of the computer of the differents of equipment pf networkt –— Fheigl (talk) 18:40, 22 January 2012 (UTC)

Network or device?

How can a network also be a device? Is it really correct to say that a SAN is a disk cabinet? —Preceding unsigned comment added by 193.45.143.134 (talk) 15:32, 24 January 2011 (UTC)

• No, it's generally wrong to call a disk array/cabinet a SAN. The connection from a cabinet to a host *might* be a SAN, even if in point-to-point fashion, and many arrays even included a full SAN in the backend or between replicated devices. (Examples: FC-AL in HP EVA or EMC CX series, or NetAPP Cluster / MetroCluster where there even will be switches between the "Heads"). Nonetheless, the Array itself presents one or multiple targets ON a SAN. If someone refers to a storage array as a "SAN" it might be caused by a general lack of understanding. This seems to be the case more often if a company does not have trained SAN admins.

Fheigl (talk) 18:50, 22 January 2012 (UTC)

wireless network intrensic secrecy

project details will you help YUVARAJ KUMAR K S (talk) 13:34, 6 March 2016 (UTC)

Hyperconverged storage area networks?

Yes, there is such a thing. This came up at DataCore Software, which used it as a buzzword. But it's real enough to have an organization, "hyperconverged.org" [1] and there even a book, "The Gorilla Guide to Hyperconverged Infrastructure Implementation Strategies". Anyone want to add a section on this? John Nagle (talk) 07:03, 23 August 2016 (UTC)

Zoning

Shouldn't the term "zoning" be included and explained in the article? 80.78.5.105 (talk) 09:23, 18 October 2016 (UTC)

Yes, although it would need to be sourced and it would be useful if the sources could give clear consistent definitions for the sub-types of zoning. Last time I looked this was a bit questionable, depending on who you asked.

Why not add something yourself? Andy Dingley (talk) 09:49, 18 October 2016 (UTC)

What is a SAN?

Added link to SNIA industry association definition of SAN — Preceding unsigned comment added by 4.28.11.157 (talk) 18:18, 22 January 2020 (UTC)

External link to IBM Redbook is broken

Perhaps this is the correct link: http://www.redbooks.ibm.com/abstracts/sg245758.html?Open --Todd B --July 11, 2006

Nope, that's dead. Here's an archive version. It looks like the broken link was replaced with this which seems reasonable. ~Kvng (talk) 14:19, 25 March 2020 (UTC)

iSCSI comments may be outdated/need citations/could be biased...

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

There are several points in this article that require cleanup, citations, or, more specifically, updating. iSCSI is repeatedly looked at as inferior technology:

"The iSCSI standard was ratified in 2003, so it has not yet had time to gather broad industry support. Fibre Channel has existed in production environments for over a decade and has already been widely deployed as strategic network infrastructure, so it will take iSCSI quite some time to make significant inroads into the installed-base of Fibre Channel SANs. It also underperforms Fibre Channel significantly, and may not be suitable for enterprise deployments."

"The performance issues inherent in iSCSI are likely to limit its deployment to lower-tier applications, with Fibre Channel remaining incumbent for high performance systems."

There are no references/citations on this, and these comments may now be outdated; yes, iSCSI had limitations in its first forays in 2004 and 2005, but there have been significant changes and improvements to the technology making it a much more viable solution in today's world.

JB —The preceding unsigned comment was added by Jbossbarr (talk • contribs) 07:05, 23 December 2006 (UTC).

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.