The French word for "without" is sans—an appropriate word to use if you're talking about Windows environments and Storage Area Networks (SANs). The groundswell of SAN deployments in the IT industry has only recently begun to reach the Windows world. Let's look at why SAN adoption has been slow in the Windows environment and why SANs are an important technology that every Windows administrator can leverage.
Content with the Status Quo?
Strategic Research (http://www.sresearch.com) estimates that between 1996 and 1998, data stored on worldwide Windows NTbased systems grew from 11PB to 39PB and by the end of 2002 will grow to more than 260PB. Despite this rapid data growth, Direct Attached Storage (DAS) remains the mainstay in the Windows environment. Most Windows administrators have been content with the simple and straightforward configuration and management, excellent performance, and low cost that DAS provides. Storage vendors haven't helped much. Most enterprise-class storage vendors, such as EMC, Hewlett-Packard (HP), Hitachi, and IBM, have been slow to recognize the Windows storage market; they've been content to revel in their huge installed base in mainframe and midrange environments. However, many of these vendors are beginning to realize that Windows represents the largest growth area in the storage business.
Microsoft has been equally slow in embracing new storage technologies. Not long ago, if you talked to Microsoft about deploying Windows, Microsoft Exchange Server, or Microsoft SQL Server on a SAN or Network Attached Storage (NAS) device, you'd get that "deer in the headlights" look. In Microsoft's defense, the company must ensure supportability of its products, and the investment of capital, process, and personnel to test its products with SAN and NAS is substantial. But Microsoft has made the necessary investments to position the company to maximize the value that technologies such as SAN bring to the Windows environment. Windows .NET Server (Win.NET Server) includes features such as multipath I/O (MPIO), Host Bus Adapter API (HBA API), Volume ShadowCopy Service (VSS), and support for booting the OS from a SAN. These important features, plus enhancements in other areas (e.g., a completely redesigned storage driver and port model in Win.NET Server), will finally let the Windows OS take full advantage of the new storage technologies.
Two factors that have caused Windows administrators to lag behind in SAN implementation are cost and complexity. First, until recently, IT has linked storage investment decisions to the purchase of an individual server, making the cost easily justifiable based on the application or service that the server will provide. DAS requires no more infrastructure than power cords and SCSI cabling, which add relatively little complexity to the environment. SANs, however, require a substantial investment in infrastructure and personnel. SANs rely on a full-blown Fibre Channel infrastructure complete with hubs, expensive switches, and costly fiber cabling.
Second, SAN technology requires a significant learning curve for existing personnel or a substantial investment in additional personnel who have SAN experience. Implementing a SAN affects storage design, capacity planning, provisioning, and disaster recovery. Consequently, implementation provides a substantial barrier to entry for smaller organizations, and in many cases, only large enterprises with large budgets and on-staff expertise can make the jump to SANs in the Windows environment.
What Do SANs Offer?
Until now, Windows administrators haven't been sufficiently motivated to move en masse to SANs. However, storage-data growth in every environment, including Windows, has left administrators, system designers, and IT managers scrambling for technologies that can quench their thirst for data scalability, availability, reliability, manageability, and lower total cost of ownership (TCO). Many enterprises have reached the limits of DAS, but SANs fulfill all these needs.
Scalability. SANs shine when it comes to capacity scalability. Although using DAS to build a 300GB server is rather easy and inexpensive, using DAS to build a 4TB or 5TB server isn't palatable. By letting designers build disk units on the SAN controller to present to the OS as LUNs, SANs make such a task much more feasible. System designers who use SAN technology can plan for systems that have multiple terabytes of storage and still leave plenty of room for growth.
Scaling large amounts of storage also requires that you maintain adequate levels of performance for that storage. A misconception among many users is that SANs provide better performance than DAS does. Although the SAN interconnect (100MBps to 2GBps) is inherently faster than SCSI bus speeds (40MBps to 80MBps), anyone who has been around most business applications in the Windows environment (e.g., SQL Server, Exchange Server) knows that what matters is I/Os per second, not megabytes per second.
Inherently, SANs don't necessarily deliver more I/Os per second for a given LUN than DAS does. However, SANs do deliver an infrastructure based on Fibre Channel, which provides a fabric that can support a greater degree of scalability than traditional DAS implementations based on SCSI buses. In terms of general I/O performance, most users find that SANs deliver levels of performance that are equivalent to those of DAS. However, designing for greater I/O performance involves increasing the number of disk devices available in a given unit. In general, most SAN implementations provide a greater degree of disk-per-LUN scalability than DAS does. Although SAN technology doesn't provide any raw performance advantages over DAS, it provides a way to scale I/O performance while scaling capacity.
Prev. page
[1]
2
next page 
