转载自：NAS vs. SAN
When ProfitLine went through the laborious process of choosing a storage technology, Don Lightsey was thrust into the center of the decision making. This is his first-person account.
Just like the age-old question of which operating system (OS) and computer platform to choose when buying a computer, both network-attached storage (NAS) and storage area network (SAN) technologies have their place in the network storage arena. For companies that need to move beyond direct storage, considering NAS or SAN makes sense.
|
|
How do you know which one will work for you? ProfitLine began to look at NAS and SAN solutions for centralized storage, storage management and storage scalability. ProfitLine manages the telecom expenses on behalf of large enterprises, so we receive thousands of phone bills daily that we process, audit and pay on our clients’ behalf, and we store all the data for a rolling 13 months for trending and reporting purposes. We were adding new clients quickly, and direct storage was clearly no longer a workable solution, as the company’s storage needs mushroomed.
Our new storage solution needed to support our rapidly escalating storage needs in processing and storing large volumes of call detail. Our storage needs were driven by the amount of client data processed, and that number was growing exponentially. The new storage needed to be scalable to dynamically allocate and easily manage disk space without incurring unneeded downtime and high administrative overhead. The security and availability of our clients’ data were top priorities.
At first glance, NAS and SAN may seem easy to tell apart. A SAN is a dedicated storage area network that is interconnected through a Fibre Channel protocol using either 1-gigabit or 2-gigabit Fibre Channel switches and Fibre Channel host bus adaptors. Devices such as file servers connect directly to the storage area network through the Fibre Channel protocol. Unlike a NAS filer, which uses standard TCP/IP over Ethernet to connect the storage to the network, SANs use Fibre Channel protocol to connect storage directly to devices/hosts.
NAS connects directly to the network using TCP/IP over Ethernet CAT 5 cabling. In most cases, no changes to the existing network infrastructure need to be made in order to install a NAS solution. The network-attached storage device is attached to the local area network (typically, an Ethernet network) and assigned an IP address just like any other network device.
The more we researched NAS and SAN, however, the muddier the waters became. Storage solutions vendors try to be all things to all people, and the definitions, value and benefits were hard to differentiate. To add to the confusion, SAN and NAS technologies are beginning to converge and blur the line even more.
CROSSOVER FEATURES
Features that were once only available in SAN solutions are now starting to become available in NAS products, and, likewise, products are now available that allow storage administrators to leverage parts of their SAN infrastructures to act as NAS filers through the use of technologies such as iSCSI. iSCSI (Internet small computer system interface) is an Internet protocol-based storage networking standard for linking data storage facilities. By carrying SCSI commands over IP networks, iSCSI is used to facilitate data transfers over intranets and to manage storage over long distances, loaning SAN a few of the NAS capabilities.
With a lot of research and business use cases, we were able to sort out fact from fiction. There are big differences between the technologies, and both have benefits.
SANs are highly redundant through the implementation of multipathing and the ability to create fully redundant fiber meshes; so there is no single point of failure. SANs feature block-level transfers instead of NAS file-level transfers. This is critical if you have database applications that read and write data at the block level.
SAN products run on Fibre Channel protocol and are entirely isolated from the IP network, so there is no contention over the TCP/IP offload engine (which optimizes throughput). NAS products run over your existing TCP/IP network, and, as such, are prone to latency and broadcast storms, and compete for bandwidth with users and other network devices.
You can leverage an existing SAN to act like a NAS with an iSCSI switch, which saves money.
With a SAN, there is higher security because SAN uses zoning and logical unit number (LUN) security. NAS security is typically implemented at the file-system level through traditional operating system access-control lists.
There is more flexibility for redundant array of independent disks (RAID) levels. While NAS products do support standard RAID levels, such as 0,1,5, you typically do not get the flexibility to mix RAID levels within the same device.
LOWER COSTS WITH NAS
File servers see SAN attached volumes as locally attached disks, whereas a NAS presents them as remote network file system (NFS) or new technology file system (NTFS) file shares. NTFS is the file system that the operating system uses for storing and retrieving files on a hard disk.
NFS is a client/server application that lets a computer user view and optionally store and update files on a remote computer as though they were on the user’s own computer. Some applications do not support remote drives and can only use a volume that is local to the OS.
NAS is cheaper than SAN. The initial investment in a SAN is expensive due to the high cost of Fibre Channel switches and host bus adaptors.
If you need just simple file storage, NAS is the way to go. A NAS product simply plugs into your existing IP network as any other device and looks like a normal file share on the network. So, a NAS can be dropped right into your existing IP network without any additional costs or infrastructure changes. Ethernet is a stable and mature protocol and most any IT administrator already knows Ethernet and TCP/IP, so there are no steep learning curves compared with learning and understanding the Fibre Channel protocol.
After carefully weighing all the benefits, ProfitLine chose to go with a Hitachi 9200 SAN infrastructure with Compaq/HP Proliant Servers because of its better support for databases and higher security. Since ProfitLine is processing tens of thousands of invoices monthly on behalf of its clients, and the number is only going up with the addition of new clients, we needed the more powerful and scalable SAN technology.
One of the limitations of the mid-class SAN that we purchased was the ability to resize existing LUNs without destroying all LUNs created after the LUN being resized. A LUN is a unique logical unit number that is used to create logical partitions of data that reside on one or many physical hard drives, and is similar to a volume or file system on a Windows or Unix operating system.
STORAGE SPACE UNAVAILABLE
We originally had not anticipated this limitation as being a big issue due to our fairly simple and straightforward storage needs. We soon found out further down the road, as we began to consume all of the storage space on the SAN, that this was a problematic issue for us because we did not have a clear strategy for allocating storage space to servers. The ability to go back and reclaim over-allocated and unused disk space was not possible without backing up, rebuilding and restoring data.
We now had a situation where we were running out of storage space to allocate to new servers, but still had roughly 50% raw storage that was not being used, just sitting on servers wasting away because we could not dynamically resize the LUNs. At first, we were disappointed with the SAN solution. This was the same type of problem that we regularly complained about with direct-attached storage on servers, and now here we were in the same situation.
At the same time that this issue started becoming a problem, we noticed that a few of the SQL servers were showing slightly high disk queuing values during peak times of the day. After some analysis in comparing the disk counters in Windows Performance Monitor with the data we were capturing from the Hitachi 9200 SAN and Brocade (Silkworm 3800) Fibre Channel switches, we determined that the operating systems, and not the SAN, were causing the disk I/O (input/output) performance problems.
All of our focus was on the I/O performance of the SAN, so we built our RAID arrays using lots of spindles, knowing that this was a good way to get I/O performance. We neglected to consider the operating system as part of the equation, however. We were allocating large LUN sizes to the operating system and placing the disk I/O bottleneck at the server.
After discussions with our SAN vendor, we came up with a strategy to solve both the disk-allocation problems and the performance issues.
To solve the disk-allocation problems, we broke up all of the LUNs on the SAN into two sizes, 10 gigabytes and 25 gigabytes, and used Veritas Volume Manager volume-management software on the Windows servers to strip multiple LUNs together. The new dynamically resized logical volumes were able to match changing storage needs, and we can now allocate disk space to servers by simply adding one or more LUNs together and stripping them together in the operating system.
For example, a server needing 20 gigbytes would get 2x10-gigabyte LUNs, a server needing 50 gigabytes would get 2x25-gigabyte LUNs, or a server needing 30 gigabytes would get either 3x10 gigabyte or 25 gigabytes + 10 gigabytes, and so on. In addition to making managing the storage needs easier, it also helped us eliminate unnecessary costs in purchasing additional storage capacity by reclaiming almost 40% of the previously unused storage space.
The performance problem was also solved with this same basic math. Our previous strategy was to allocate LUNs as large as needed to fit the application requirements. So, if an application needed 100 gigabytes of storage space, we would allocate a single 100-gigabyte LUN that had a single I/O stack.
By utilizing the new strategy of 10-gigabyte and 25-gigabyte LUNs, the 100-gigabyte LUN would be given 4x25-gigabyte LUNs and stripped in the operating system using the volume-management software. The new 100-gigabyte LUN would have four I/O stacks to use when reading and writing to the logical volume, which increases disk performance. Our SQL servers have benefited greatly from this new strategy, as a result.
We have since extended our SAN to support basic file storage needs for document imaging and EDI file storage for electronic processing. Our current SAN is a workhorse, and I/O performance is great. The SAN’s higher performance of Fibre Channel compared to Ethernet, its flexibility to support different RAID levels easily, and its strong support for databases and block-level data transfers made it the better choice for our dramatically growing business. Our clients see flawless, fast throughput of their telecom data, which leads to faster processing and quicker return on investment.
SAN and NAS both have their advantages, so be sure to assess your current and future storage needs, and understand the differences of how they could help your business succeed.