21,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
- Veröffentlichungsjahr: 2009
If you've been charged with setting up storage area networks for your company, learning how SANs work and managing data storage problems might seem challenging. Storage Area Networks For Dummies, 2nd Edition comes to the rescue with just what you need to know. Whether you already a bit SAN savvy or you're a complete novice, here's the scoop on how SANs save money, how to implement new technologies like data de-duplication, iScsi, and Fibre Channel over Ethernet, how to develop SANs that will aid your company's disaster recovery plan, and much more. For example, you can: * Understand what SANs are, whether you need one, and what you need to build one * Learn to use loops, switches, and fabric, and design your SAN for peak performance * Create a disaster recovery plan with the appropriate guidelines, remote site, and data copy techniques * Discover how to connect or extend SANs and how compression can reduce costs * Compare tape and disk backups and network vs. SAN backup to choose the solution you need * Find out how data de-duplication makes sense for backup, replication, and retention * Follow great troubleshooting tips to help you find and fix a problem * Benefit from a glossary of all those pesky acronyms From the basics for beginners to advanced features like snapshot copies, storage virtualization, and heading off problems before they happen, here's what you need to do the job with confidence!
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 647
Ähnliche
Storage Area Networks For Dummies®, 2nd Edition
Table of Contents
Introduction
About This Book
Foolish Assumptions
Conventions Used in This Book
How This Book Is Organized
Icons Used in This Book
Part I: SAN 101
Chapter 1: The Storage Area Network
Defining a SAN
Fiber versus Fibre
How a SAN Makes Computing Different
Understanding the Benefits of a SAN
Finding Out Whether a SAN Is Right for You
Who should use a SAN?
Who should not use a SAN?
Dissecting a SAN (The Four Ps)
The Parts of a SAN
The host layer
The fabric layer
The storage layer
Storage arrays
The SAN Protocols
The SAN Players
The SAN Platforms
Applications that benefit from a SAN
Applications that require a SAN
Chapter 2: SAN Building Blocks
SAN Components and How They’re Used
The Host Layer
Host bus adapters
Gigabit gadgets: GBICs and GLMs
The Fabric Layer
Understanding storage fabrics
SAN hubs
SAN switches
Data routers
Cables
Cable-connector types
SAN ports and port naming
Basic SAN port modes of operation
Protocols used in a Fibre Channel SAN
The Storage Layer
Storage arrays: Storing your data
Explaining Redundant Array of Inexpensive Disks (RAID)
RAID benefits
RAID types
Logical Unit Numbers (LUNs)
Understanding storage-array classification
Modular versus monolithic
Monolithic (Enterprise)
Modular (Departmental)
Why Cache memory makes a difference
Chapter 3: What Makes a SAN Go
Networking Basics
Moving Data at the Speed of Light
Bandwidth
Fibre Channel Protocols
The arbitrated loop
Loop addressing
The Switched Fabric
The fabric protocol
Fabric addressing
Chapter 4: What Makes a SAN Stop
Discovering What Causes SAN Problems
Preventing Poor SAN Design
Bandwidth
Too much distance between components
Excess latency
Congestion
Over-subscription
Using the Right Cables in the Right Way
Avoiding connection issues
Macro- and micro-bends, and the patch panel pain
Cable labeling
Choosing the right host bus adapter for your computer
Going with a single vendor
Mixing switch vendors
Part II: Designing and Building a SAN
Chapter 5: Designing the SAN
Basic SAN Designs: Understanding the Layers
Point-to-Point Topology
Arbitrated Loop Topology
Cascading hubs
Loop of hubs
Creating resilient hub networks
Fault-tolerant loops
Switched Fabric Topology
Types of SAN switches
Choosing which switches to use
Using the right bandwidth for the job
Trunking and what it’s used for
Basic Fabric Topologies
Dual switches, the SAN fabric building block
Loop-of-switches topology
Meshed fabric topology
Star topology
Core-edge topology
Understanding Zoning
The parts of a zone
Types of zoning
Zone alias names
Initial Switch Setup
Setting up a Brocade switch
Setting up an original McData (Brocade) director switch
Best Practices — Tips from the Trenches
When to choose a director-class switch
Standardize on a single vendor’s switches
Standardize your firmware versions
Standardize your HBA drivers
Use unique zone alias names
Using storage from multiple vendors
Always use two fabrics
Chapter 6: SANs and Disaster Recovery
How Much Downtime Can You Afford?
Gathering the data for a disaster-recovery plan
Create a detailed plan that meets your requirements
Recognizing the Importance of Distance, Bandwidth, and Latency
Distance
Bandwidth
Latency
Choosing the Recovery Site
Existing facility
Co-location facility
Choosing Where to Run the Data Replication Process
Host-based data replication solutions
Appliance-based data replication solutions
Array-based data replication solution
Shipping tapes as a solution
The Importance of Testing
Chapter 7: Putting It All Together
Building a SAN by Hand
The SAN Plan
Fabric Zoning 101
LUN security
Setting Up the SAN
Keeping good notes
Setting up the switches
Preparing the Servers
Loading the driver
Customizing the HBA card’s configuration
Planning the HBA connections
Configuring the Array
The hardware
RAID setup
Plugging Things In
Configuring the Zones
Mapping the zones first
I’m zoning out . . .
Back to the Servers: Did It Work?
Unix servers
Windows system
iSCSI, You SCSI, We All SCSI
Initiators and targets
IQN: iSCSI qualified name
SCSI Name Service
Data domains
Getting started with iSCSI
Getting serious with iSCSI
Data Migration
Network migration
Backup/restore migration
Disk-to-SAN migration
Part III: Using Advanced SAN Features
Chapter 8: Networking SANs
Defining a SAN Island
Connecting SAN Islands
Disk/data sharing
Data copying
The Storage WAN, MAN, and SWAN
Using the network only for storage management
The storage SWAN
Choosing and Using SAN Extenders
Choosing the Correct Link for the Job
IP connections
OC-type connections
Reducing Costs with Compression, Data De-duplication and WAN Tuners
Compression
De-duplication
WAN tuners
SAN Connection Protocols
FCIP: The SAN tunnel
iFCP: The SAN gateway
Stretching the SAN (The Rubber-Band Approach)
Using Connected SAN Islands (The Two-Rubber-Bands Approach)
Using a SAN as Network Attached Storage
iSCSI: An Alternative Method
Chapter 9: SAN-Based Backup
Understanding Backup
Understanding SAN Backup
The backup window
Tape drives
Tape libraries
Backup policy
Choosing a Backup Solution
Integrated tape drive in each server
Backup over a corporate LAN to a tape drive connected to an independent backup server
Backup over corporate network to robotic tape library connected to an independent backup server
LAN-less backup to shared tape library over SAN
Serverless backup to shared tape library through SAN
Disk-to-disk backup
Image copy and snapshots in the SAN
SAN data replication/remote backup
Determining How Long a Backup Will Take
Determining backup speeds
The formula for backup
Chapter 10: Mirror, Mirror: Point-in-Time Copies
The Uses of Point-in-Time Technology
Make backups
Make corruption-recovery images
Save space
The possibilities are endless
Complete versus Metadata Copies
Which PiT Type Should You Use?
Creating a PiT Copy
Managing Your Point-in-Time Copies
Pair up your volumes
Create the pairs
Splitting the mirror, snapping a copy
Doing a resync: Refresh and restore
I need my data now!
Using a PiT copy
The Finer Points of PiT
Guideline #1: Understand when to snap a copy
Guideline #2: Keep your PiT pairs separated
Guideline #3: Use the right disk storage for PiT copies
Questions to ask your SAN vendors
Part IV: SAN Management and Troubleshooting
Chapter 11: Approaches to SAN Management
Management: From Simple Networking to SANs
SAN Management from the Ground Up
Start small; think big
Documentation is key
Cable Management: Spaghetti, Anyone?
Physical cable management
Logical cable management
Labeling Your Cables
Data center coordinate system
Standard naming convention
Documenting the cable arrangements
Using a SAN Management Framework
Working with SAN management software
Communicating in a common language
Speaking the language yourself
Putting everything together
What SAN Management Gives You
A bird’s-eye view of your network
Agent-based management
Health monitoring
Records of events
Change management
Predictions of problems
Streamlining SAN Administration
Step-by-step administration
Using a framework
Automating Your System: “SAN? Do You Read Me, SAN?”
Backing up
Managing database storage
Providing a Service Level Agreement
Simple versus complex SLAs
Setting service levels
Building a Storage Management Team
SAN architects
SAN engineers
Monitoring team
SLA and performance specialists
Provisioning staff
Planning for the future
Common responsibilities
Chapter 12: Troubleshooting SANs
The Best Method: Prevention
Troubleshooting Methodology
Go with what you know
Elementary, my dear Watson
Didn’t read the manual, did you?
Build a golden configuration
Typical Problem Types
Obvious problems
Phantom problems
Continuous problems
Catastrophic problems
Example Scenarios
Scenario #1
Scenario #2
Scenario #3
Part V: Understanding the Cool Stuff
Chapter 13: Using Data De-Duplication to Lighten the Load
Understanding Data De-Duplication
Benefits of data de-duplication
How de-duplication works
Data De-Duplication in the Datacenter
The de-duplication vendors
How data gets de-duplicated
In-band versus out-of-band data de-duplication
Using Data De-Duplication in a SAN
Files: Honey, I shrunk the files
Blocks: Been there, stored that
What about hash collisions?
Why Data De-Duplication Is Important
When to Use Data De-Dupe (And When Not To)
Applications for which data de-duplication makes sense
Applications for which data de-duplication doesn’t make sense
De-Duplication in Action
Chapter 14: Continuous Data Protection
Understanding What Continuous Data Protection Is
How CDP Makes Storage Work Like a Database
CDP data journaling
Splitting the writes
CDP makes everything different
Sizing a CDP journal
Best Practices for Storage When Configuring CDP Solutions
The Truth about Near CDP and True CDP Solutions
Example 1: Recovering a database with traditional backup
Example 2: Recovering a database from a snapshot
Example 3: Recovering a database using near CDP
Example 4: Recovering a database using true CDP
CDP versus Snapshots
Using CDP to Eliminate Backups
Using CDP to Simplify Recovery and Reduce Costs
Knowing Your CDP Vendor
Chapter 15: Everything You Ever Wanted to Know about Virtualization
Understanding What Virtualization Is
Exploring the Types of Virtualization
Implementing Virtualization in a Datacenter
Server virtualization
Storage virtualization
In-Band versus Out-of-Band Virtualization
In-band virtualization
Out-of-band virtualization
The Virtualization Vendors and Where They Play
Host-based storage virtualization vendors
Fabric-based virtualization storage vendors
Storage-array-based virtualization
Part VI: The Part of Tens
Chapter 16: Ten Reasons to Use a SAN
You Want Better Disk Utilization
You Need a Good Disaster Recovery Solution for Multiple Applications
You Need Better Availability for Your Applications
You Need More Storage Room
Backup Is Taking Too Long
You’re Focusing on Server and Storage Consolidation
You’ve Been Tasked to Save Your Company Money
You Need to Manage Storage for Many Locations from a Central Site
You Need to Decrease IT Management Costs
You Need Better Performance for Your Applications
Chapter 17: Ten Reasons NOT to Use a SAN
You Need Larger File Servers
You Only Have a Few Inexpensive Servers
You Want to Save Your Company Money This Year
You Want to Use the Latest and Greatest Solutions Available
You Need a Disaster-Recovery Solution for a Single Application
You Want a SAN but Don’t Have the Budget
You Use Gigabit Ethernet on Your LAN
Everything Already Runs Fine
You Need to Back Up Multiple Remote Offices over Slow Links
You Need to Replicate Your Data for Disaster Recovery but Can’t Afford Fast WAN Connections
Storage Area Networks For Dummies®, 2nd Edition
Christopher Poelker
and
Alex Nikitin
Storage Area Networks For Dummies®, 2nd Edition
Published byWiley Publishing, Inc.111 River St.Hoboken, NJ 07030-5774www.wiley.com
Copyright © 2009 by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.
Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services, please contact our Customer Care Department within the U.S. at 800-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002.
For technical support, please visit www.wiley.com/techsupport.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.
Library of Congress Control Number: 2008942264
ISBN: 978-0-470-38513-5
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
About the Authors
Christopher Poelker has been in the field of computer technology since 1974. Chris was an electronics engineer in the U.S. Army, and tried to stay out of trouble by hiding in tanks while installing laser range finders and computer-aided ballistic trajectory systems. After leaving the service, Chris went to school in New York City at good old Control Data Institute and was hired as a field engineer by Digital Equipment Corporation. In his spare time, Chris started his own software company, developed databases, and became a Microsoft MCSE and instructor. Chris worked for Digital for 18 years until it was bought by Compaq, where he stayed on as a StorageWorks systems engineer until joining Sun Microsystems in 2000. Chris left Sun to become a consulting storage architect for Hitachi Data Systems and became the district storage manager for HDS in New York City. In 2006, Chris left HDS for FalconStor software, where he now works as the Vice President of Enterprise Solutions. Chris has designed and implemented storage networks for many of the Fortune 100 companies in the U.S. and around the world. In his spare time, Chris sometimes speaks at industry forums, writes magazine articles, and has acted as the SAN expert at SearchStorage.com.
Alex Nikitin, currently a systems expert at HBO, has logged in 15 years in the Information Technology industry. Alex has worn many hats in this industry, ranging from application programmer and network administrator to the ultimate responsibility over large server farms, and storage and backup solutions for some of the world’s top financial and pharmaceutical companies. Alex and Chris worked together at Hitachi Data Systems in New York, where Alex was the “go to” guy for difficult storage designs and implementations. Prior to joining HDS, he also spent time growing the install base of Storage Area Networks as a Professional Services Consultant for EMC Corporation, implementing SAN solutions for various companies, large and small, on Windows NT/2000, Solaris, HP/UX, AIX, and Linux platforms. Seemingly always cast in a storage-centric capacity, his career has focused on caring for and reliably delivering vast amounts of storage to his user community.
Dedication
Christopher Poelker: To my sister Nancy, whose love and friendship meant the world to me.
Author’s Acknowledgments
Christopher Poelker: I would have never been given the chance to write this book if it weren’t for my friends at TechTarget, who used to run the SearchStorage.com Web site: Michelle Hope and Maryann Tripp. These two wonderful women were the reason I was introduced to Melody Layne and Susan Christophersen of Wiley Publishing, who made the first book possible, along with Teresa Artman, who spent many a long night copy-editing the manuscript and making up for my horrible writing skills. (I should have paid closer attention during eighth-grade English!) For this second edition, I would like to thank Kyle Looper and Kim Darosett for their patience during deadlines when my day job was getting in the way of keeping this edition on track.
I’d also like to thank my partner in crime and co-author, Alex Nikitin, who again saved my marriage and my duty as a father to my children by taking over some of the load and helping me crank out some of these chapters. Alex is one of the best storage guys I have ever had the privilege of working with.
Thanks also need to go this time to FalconStor software, for letting me proceed with this project and letting me play hooky now and then to crank out a chapter or two. Thanks to ReiJane Huai, Wendy Petty, Wayne Lam, Alan Chen, Tom Strumpf, Bruce Sasson, Joanne Ferrara, and everyone else at FalconStor who filled in or helped me out to give me time during the writing of this book.
Special thanks to all the folks who taught me most of the things I know about storage: my brothers, Lenny Poelker and Greg Poelker, who are a heck of a lot smarter than I! Also to my mentors: Wayne Lam, Wai Lam, Stanley Qin, Irving Moy, David Shyu, Cartic Vengkatraman, Gene Chesser, Steve Sicola, Paul Kruschwitz, Jimmy Wu, Raymond Tong, Paul Mitchell, Mike Mendola, Jo McCausland, John Lallier, Nick Sinish, Brian Rice, Steve O’Rielly, Catherine Brown, Frank Cizin, Leonard Hayward, Charlie Mulrooney, Paul Poon, Don Thatcher, Tony Merschdoff, Jeff Sinisgalli, John Fonseca, Marty Citron, Al Catalano, Tom Lindemann, Roland Song, Pierre Dansereau, Mike Pierro, and most of all, Kevin Shumacker, whose help over the years I could never repay. Thanks to Ken Garnau, Nancy Berliner, and Charlie Santana for help with the mainframe stuff, and everyone I ever met from Brocade/McData, and Emulex.
Tom Clark and Robert Stout, Nancy Jennings, and John Dorl from the original Nishan systems were a big help with helping me figure out SAN extensions, (especially Tom’s books!), and Mark Farley’s book was the first I read on SAN and still is one of the best. (I guess I learned things the hard way, by just doing it.)
Finally, thanks for the support of my family: Deborah, my wife, for being a single mother again while I was writing the book, and of course, my children Cole, Chris, and Rachel for all their support and being the wonderful people they turned out to be.
Publisher’s Acknowledgments
We’re proud of this book; please send us your comments through our online registration form located at www.dummies.com/register/.
Some of the people who helped bring this book to market include the following:
Acquisitions, Editorial, and Media Development
Project Editor: Kim Darosett
Executive Editor: Steven Hayes
Copy Editors: Barry Childs-Helton, Susan Pink, Kathy Simpson
Technical Editor: Michael Vannette
Editorial Manager: Leah Cameron
Editorial Assistant: Amanda Foxworth
Sr. Editorial Assistant: Cherie Case
Cartoons: Rich Tennant (www.the5thwave.com)
Composition Services
Project Coordinator: Patrick Redmond
Layout and Graphics: Samantha Allen, Reuben W. Davis, Melissa K. Jester, Christine Williams
Proofreader: Broccoli Information Management, Amanda Graham
Indexer: Broccoli Information Management
Publishing and Editorial for Technology Dummies
Richard Swadley, Vice President and Executive Group Publisher
Andy Cummings, Vice President and Publisher
Mary Bednarek, Executive Acquisitions Director
Mary C. Corder, Editorial Director
Publishing for Consumer Dummies
Diane Graves Steele, Vice President and Publisher
Composition Services
Gerry Fahey, Vice President of Production Services
Debbie Stailey, Director of Composition Services
Introduction
Welcome to Storage Area Networks For Dummies, 2nd Edition!The first edition was the book we wish was around when we were trying to learn about this stuff! We tried to take a fairly mundane topic and make it a fun read so you could get up to speed on storage networking as quickly and painlessly as possible. This second edition is written in the same spirit as the first.
When the first edition was written in 2003, very few books on storage area networks (SANs) were available. The books that were available were very narrow and extremely technical in focus. They were about as fun to read as the directions for setting up a DVD player. Although more books about storage networking are available now, most are still very technical and about as fun to read as the U.S. tax code (nothing against accountants here!).
Over the years, this book has become the standard bearer in keeping the subject concise, simple, and fun, and has now been updated to include all the new cool stuff and changes that have occurred since the original printing. Let’s face it — most folks typically look for a fast and easy way to get information; you want the information you need to know, and not everything there is to know, so this second edition uses that same point of view common to all of us poor slobs who need to make a SAN work with no budget, no training, and no time. So don’t worry, be happy — and just have some fun!
About This Book
The mission of this book is to help you find your way around while exploring the topic of storage area networking. The book is dedicated to individuals who, for better or for worse, have been tasked with designing, implementing, configuring, or troubleshooting a storage area network. We hope that the information here will enable both the beginner and the moderately expert storage professional sort through the ins and outs of a SAN. We use familiar language to demystify the technology and translate the jargon as necessary. You’ll discover how to choose the right hardware for the job, design a SAN by using the best practices in the industry, connect everything to make it work, and troubleshoot the SAN to fix problems when they occur.
You also get to delve into the hard stuff — the stuff that many companies pay expensive consultants for (who have usually just read a book like this just before they were hired!), so be brave, and we’ll do our best to make this painless. If you want to understand what a SAN is and what it does, you’ve come to the right place. Everything you should need (or want) to know about storage area networks is here in one location.
Foolish Assumptions
We have one or two foolish assumptions about you, the reader of this book:
You are responsible for or have worked with computer storage before.
You might want to continue working in that field of endeavor.
You want to find an easy way out of your networking storage problems so you can get home and play video games, watch TV, and drink beer with your friends.
We also assume that you don’t want to become an instant expert. You want to know just enough to be able to speak intelligently on the subject matter but also know when it’s time to call in an expert.
This book tries to you get past all the little details that get in the way of understanding a subject by using a real-world approach. We didn’t create the technology; we just know how to make it work because we’ve been in the field for more years than we care to say. This book tries to impart just enough good info to help you make your stuff work — and to understand enough to know when someone is misleading you or trying to rip you off. The best defense is a good offense.
Conventions Used in This Book
We want you to understand all the instructions in this book, and in that spirit, we’ve adopted a few conventions.
When you hit a chapter in which we ask you to do something, you will be prompted by a numbered list. The numbers in the list are the order of the steps that you need to take to accomplish the task at hand. Just follow the steps listed, and everything should be just fine. If you need to enter something on the keyboard, we ask you to type it. If you need to use your mouse, we ask you to click it. That’s all there is to it.
How This Book Is Organized
This book is designed as a reference, so you don’t have to read the book cover to cover. Just look in the Table of Contents to find the topic you’re interested in and start reading. If you’re unsure of some of the acronyms you’ve been hearing out there, check out the Cheat Sheet at the front of this book for easy reference.
The book is organized in seven parts.
Part I: SAN 101: This part covers the basics of storage area networks, including what you need to know if you’re going to buy a SAN, build one yourself, or have someone build it for you.
Part II: Designing and Building a SAN: This part of the book handles all the fun stuff, such as how to add more storage to your servers and how to connect everything and get it running. It also covers what you need to know if you already have a SAN in place or need to know how to use it or set it up properly.
Part III: Using Advanced SAN Features: If you’ve always wanted to know what the heck a snapshot copy was, this is the place to find out. This part also covers advanced topics such as backing up your data, which will help you get more bang for your buck out of your SAN.
Part IV: SAN Management and Troubleshooting: Every now and then, something goes bump in the night. This part shows you how to manage and troubleshoot problems when they occur as well as how to avoid having to face those problems in the first place.
Part V: Understanding the Cool Stuff: This part covers the cool new advances in storage area networking since 2003, such as storage virtualization, data de-duplication, and advances in data protection and replication such as Continuous Data Protection (CDP). You find out how to use these technologies to help you save money and become more productive and better prepared when trouble happens.
Part VI: The Part of Tens: This part includes ten reasons to use a SAN and ten reasons not to.
We’ve also provided a bonus chapter titled “Outsourcing SAN Solutions” that you can download from the book’s companion Web site at www.dummies.com/go/sanfd2e.
Icons Used in This Book
To help you get the most out of this book, we’ve placed icons here and there. Here’s what the icons mean:
Next to the Tip icon, you can find shortcuts and tricks of the trade to make you more productive without even realizing it.
Where you see the Warning icon, tread softly and carefully. It means that we’ve been burned by this already and don’t want you to have to learn the hard way, as we did.
Stuff marked with the Remember icon is like jotting a note to yourself in a class. Make an effort to bend the ear of the page so that you don’t forget it.
Okay, we probably put too many of these icons in the book. But what the heck . . . sometimes trying to explain this stuff is like writing a book on Brain Surgery For Dummies. We need to point out the details at times so you don’t end up with a migraine.
Part I
SAN 101
In this part . . .
The computer industry is funny. As soon as you get comfortable with the latest technology and become the resident expert, something new comes out, and the whole learning process starts all over again. Some people enjoy the challenge of learning about something new, and some think it just makes life more difficult. This first part of the book tries to make things easier by introducing you to storage area networks, or SANs. Just like in high school shop class, when you were introduced to the drill press, the table saw, and the first aid stations, we introduce you to the various tools that you use to build a SAN. We tell you what each tool does, why it’s necessary, and how you can use it in your new SAN project.
Chapter 1
The Storage Area Network
In This Chapter
Understanding storage area networks (SANs)
Determining whether a SAN is right for you
Looking at SAN layers and protocols
Figuring out which operating systems benefit from SANs
Discovering which applications can use or require SANs
This chapter is dedicated to helping you get a handle on what a storage area network (SAN) is, the basics of how one works, and whether one is right for your needs. You’ll discover all the parts that make up a SAN, the things that make one run, and who actually makes all the different parts that you can buy. Putting a SAN together is somewhat like putting together one of those high-end stereo systems; you have many components and many different manufacturers to choose from. This chapter helps you choose the ones that suit your needs and create something that you can be proud of.
These days, becoming proficient with SANs can mean a major boost to your career. Perhaps you’re bored to death in your current position and would like a change of pace. SAN administration is one of the highest-paying jobs in Information Technology (IT) today. If you add storage area networking to your résumé, you may find your phone ringing off the hook as headhunters vie to offer you a six-figure income (hey, might as well dream big).
Defining a SAN
First, the basics. In today’s terms, the technical description of a SAN (Storage Area Network) is a collection of computers and storage devices, connected over a high-speed optical network and dedicated to the task of storing and protecting data.
In a nutshell, you use a SAN to store and protect data. A SAN uses the SCSI (Small Computer Storage Interconnect) and FC (Fibre Channel) protocols to move data over a network and store it directly to disk drives in block format. Today, that high-speed network usually consists of fiber-optic cables and switches that use light waves to transmit data with a connection protocol known as Fibre Channel. (A protocol is a set of rules used by the computer devices to define a common communication language.) More and more, regular Internet protocol (IP)–based corporate networks, and even the Internet, are being used as the network part of a SAN. IP networks that are already in place can be used by other storage connection protocols such as iSCSI (internet Small Computer Storage Interconnect) to move and store data.
Using a network to create a shared pool of storage devices is what makes a SAN different. A SAN moves data among various storage devices, allows sharing data between different servers, and provides a fast connection medium for backing up, restoring, archiving, and retrieving data. SAN devices are usually bunched closely in a single room, but they can also be connected over long distances, making a SAN very useful to large companies.
Many of today’s SAN components are pretty much plug-and-play. To create a simple SAN, you just connect all the devices together with cables, and off you go. Creating larger SANs with many storage switches can become complex, though, and that’s the reason for this book: to give you a handle on what you need to know about large, complex SANs.
Fiber versus Fibre
No, it isn’t just a snooty way of spelling fiber. (Well, okay, not only that.) Networking geeks use the fibre spelling (reversing the er to re) to refer specifically to fiber-optic cables used in a SAN. The idea is to differentiate SAN cables from the optical cables used in other networks (such as TCP/IP Networks). That’s because SAN devices use a different language to communicate with each other than do the devices in other networks. This is why the main protocol used in a SAN (snooty or not) is called Fibre Channel.
All network protocols are divided into layers, like a layer cake. All the layers in the cake are logically tied together into a stack. Each layer of the stack provides different functionality, and each device in the network uses the stack like a language to communicate with other devices in the network. The bottommost layer of the stack is hardware-based (as opposed to software-based), and thus is referred to as the physical layer.
The physical layer consists of tangible hardware stuff such as cables, switches, and connectors. This is where the fiber-optic cables are. On top of the physical layer are the software layers that make up the protocol stack. In a Fibre Channel SAN, those layers make up the Fibre Channel protocol.
Each type of network uses a different protocol to handle data. The Internet, for example, uses a protocol stack called the Transmission Control Protocol/Internet Protocol (TCP/IP). The physical layers of both Internet and SAN can transmit data as light pulses over fiber-optic cables — which (as you might expect) makes the data move nearly as fast as light. The only difference between regular fiber-optic computer networks such as the Internet and a fiber-optic SAN is the protocol and the switches used by the devices to talk to each other over the network. SANs use the Fibre Channel protocol and Fibre Channel switches, and the Internet uses the TCP/IP protocol and Ethernet switches. Fibre Channel was developed to move data really fast between computers and disk drives; TCP/IP (or “Internet Protocol”) was developed to move files over long distances between computers.
How a SAN Makes Computing Different
Using a SAN can really change how you think about computing. In the past, there was the mainframe, which was a gigantic computer that could run all the programs in a large business. All the computer stuff was gathered in one place called a data center. All the storage that the mainframe needed was directly connected to it. Everything was located and managed as a single, large entity.
The PC revolution changed a lot of things. Everything started to spread out. Data was moved off the mainframe and stored in server computers. The servers were then dispersed throughout the enterprise to bring computing power closer to the actual users. The servers became connected by a network, called a local area network, or LAN. This was cool because now the computing power was spread out and made more available to end users. Eventually, LANs were connected to create the Internet.
Networks enabled people who used computers in far-flung places to communicate and share information with each other. In business, problems arose when inter-networking finally took off. A great deal of data was now being stored with no effective way to manage it all. Managing all the scattered data dispersed throughout the network became a nightmare.
Because all data storage was located inside each individual server, you had no effective way to efficiently allocate storage space between all the servers. Sure, users could share files over a LAN, but you still needed a way to share access to physical disks, rather than using dedicated disks inside every server. Hence the advent of the SAN.
Since the original TCP/IP network protocols used in a LAN (Local Area Network) were built to move and share files, they had no built-in way to directly access disk drives. As a result, very high-performance applications needed direct access to block-based disk drives to move and store data very fast. (Data is stored as blocks on a disk drive.)
Disk drives in a SAN are stored in a dedicated storage device called a disk array. All the servers connect to the storage device over a high-speed network using the Fibre Channel protocol, which enables very fast access to disks over a network. Using a SAN gives businesses shared and consolidated access to data storage — available to any server connected to the SAN.
Putting a SAN in place makes individual server computers less important and more peripheral to the data stored in the SAN. After all, the data is what is important to your business. If you lose a server, you can buy a new one. If you lose your data, it’s “Adiós, amigo” for your business.
Understanding the Benefits of a SAN
The typical benefits of using a SAN are a very high return on investment (ROI), a reduction in the total cost of ownership (TCO) of computing capabilities, and a pay-back period (PBP) of months rather than years. Here are some specific ways you can expect a SAN to be beneficial:
Removes the distance limits of SCSI-connected disks: The maximum length of a SCSI bus is around 25 meters. Fibre Channel SANs allow you to connect your disks to your servers over much greater distances.
Greater performance: Current Fibre Channel SANs allow connection to disks at hundreds of megabytes per second; the near future will see speeds in multiple gigabytes to terabytes per second.
Increased disk utilization: SANs enable more than one server to access the same physical disk, which lets you allocate the free space on those disks more effectively.
Higher availability to storage by use of multiple access paths: A SAN allows for multiple physical connections to disks from a single or multiple servers.
Deferred disk procurement: That’s business-speak for not having to buy disks as often as you used to before getting a SAN. Because you can use disk space more effectively, no space goes to waste.
Reduced data center rack/floor space: Because you don’t need to buy big servers with room for lots of disks, you can buy fewer, smaller servers — an arrangement that takes up less room.
New disaster-recovery capabilities: This is a major benefit. SAN devices can mirror the data on the disks to another location. This thorough backup capability can make your data safe if a disaster occurs.
Online recovery: By using online mirrors of your data in a SAN device, or new continuous data protection solutions, you can instantly recover your data if it becomes lost, damaged, or corrupted.
Better staff utilization: SANs enable fewer people to manage much more data.
Reduction of management costs as a percentage of storage costs: Because you need fewer people, your management costs go down.
Improved overall availability: This is another big one. SAN storage is much more reliable than internal, server-based disk storage. Things break a lot less often.
Reduction of servers: You won’t need as many file servers with a SAN. And because SANs are so fast, even your existing servers run faster when connected to the SAN. You get more out of your current servers and don’t need to buy new ones as often.
Improved network performance and fewer network upgrades: You can back up all your data over the SAN (which is dedicated to that purpose) rather than over the LAN (which has other duties). Since you use less bandwidth on the LAN, you can get more out of it.
Increased input/output (I/O) performance and bulk data movement: Yup, SANs are fast. They move data much faster than do internal drives or devices attached to the LAN. In high-performance computing environments, for example, IB (Infiniband) storage-network technology can move a single data stream at multiple gigabytes per second.
Reduced/eliminated backup windows: A backup window is the time it takes to back up all your data. When you do your backups over the SAN instead of over the LAN, you can do them at any time, day or night. If you use CDP (Continuous Data Protection) solutions over the SAN, you can pretty much eliminate backup as a separate process (it just happens all the time).
Protected critical data: SAN storage devices use advanced technology to ensure that your critical data remains safe and available.
Nondisruptive scalability: Sounds impressive, doesn’t it? It means you can add storage to a storage network at any time without affecting the devices currently using the network.
Easier development and testing of applications: By using SAN-based mirror copies of production data, you can easily use actual production data to test new applications while the original application stays online.
Support for server clusters:Server clustering is a method of making two individual servers look like one and guard each other’s back. If one of them has a heart attack, the other one takes over automatically to keep the applications running. Clusters require access to a shared disk drive; a SAN makes this possible.
Storage on demand: Because SAN disks are available to any server in the storage network, free storage space can be allocated on demand to any server that needs it, any time. Storage virtualization can simplify storage provisioning across storage arrays from multiple vendors.
Finding Out Whether a SAN Is Right for You
Though SANs can offer many advantages, they aren’t for everyone. If you own a small business and use just a few computers to keep it going, using a SAN is probably overkill for you. Sometimes the cost isn’t justified by the benefits. The more servers you have in your organization — and the more data that you need to store — the more benefit you’ll see from a using a SAN. Prices have come down a lot since the first writing of this book, but storage networking equipment isn’t cheap. For example, a single high-performance host bus adapter (more about that later) can cost more than a thousand dollars; a storage switch can cost tens of thousands.
A good guideline that we use is what we call The Rule of 16. If you have 16 or fewer servers, using a SAN probably doesn’t make sense. (Of course, you may still benefit from a less expensive NAS- or iSCSI-based solution, which we touch on later.) You can easily manage 16 or fewer servers with one person, and data-storage needs shouldn’t be that high. If you use more than 16 servers, or servers that run large databases, you’re a good candidate for a SAN. If you’re responsible for hundreds of servers, using a SAN will probably dramatically reduce the cost of managing data.
Who should use a SAN?
You should use a SAN if you work in a large organization (more than 16 servers, or servers that run large databases) in which data management or data backup is becoming a problem. (By server here, we mean the hardware you buy to run your applications. When it runs your applications, it is the “server” part of a client/server implementation.) Your servers might be running out of disk space all the time, and you might have no room left in the servers to add disk drives. A business in this server pickle is a typical SAN candidate. You might have way too much data to be backed up or restored in a timely fashion. Using a SAN can fix that, too.
The following checklist details the types of server resources, both software and hardware, that should be included in a SAN:
Database servers: Oracle, Sybase, SQL, DB2, Informix, AdaBase, and other databases love to make use of the extremely fast disks in a SAN.
File servers: Using SAN-based storage for Windows or Unix computers acting as file servers lets you expand your file-server storage resources quickly, makes them run better, and improves overall management. Specialized devices called NAS (Network Attached Storage) servers can supply shared access to stored files over a standard TCP/IP network.
Backup servers: Connecting all your servers (including backup servers) to a SAN enables you to back up your data through a SAN rather than through a LAN — and SAN-based backup is dramatically faster.
Voice/video servers: Voice and video servers tend to push large amounts of data very quickly. That’s what SANs are built to do.
Mail servers: Using SAN-based storage for mail servers enables quick restoration of data in case of corruption or viruses. It also lets you back up your mail servers faster, and you can use clusters as mail servers.
High-performance application servers: ASAN’s capabilities benefit applications for managing documents, scientific computations, customer relationships, billing, data warehouses, and other high-performance business functions.
Who should not use a SAN?
You don’t really need to use a SAN if your organization is small (16 servers or fewer) or where data management, application performance, or backup is not currently a problem for you.
For that matter, the technology you have may not be a good fit with a SAN. Here’s a checklist of the types of servers that should not be included in a SAN. Such servers are usually better off staying on their internal disk drives; they don’t benefit from SAN-based storage (which is also more expensive):
Web servers: Computers set up as Web servers don’t usually have large storage needs; they’re usually connected to larger servers that run the databases from which Web pages are automatically built. Although Web servers are good candidates for NAS, database servers can make better use of SAN disks.
Infrastructure servers: Server applications that handle the chores of network infrastructure — such as Domain Name Servers (DNS), Windows Internet Naming Servers (WINS), and Domain Controllers (DC, PDC) — are better left on the server computers’ internal disks. They don’t need a lot of disk space, and their performance requirements are minimal.
All desktop PCs: Personal computers are not good SAN candidates because they usually connect to corporate servers for any applications that require high performance. Those corporate servers, however, could use a SAN.
Servers needing less than 10GB of storage: Face it: Internal storage is cheaper than SAN storage. If your server has no performance problems and will never need more than 10GB of storage space, leave it alone.
Servers that don’t need fast access to data: If performance is good already and you don’t mind maintaining the server separately, don’t bother hooking it up to a SAN.
Servers that have to share files: Such servers are better off connected to a Network Attached Storage (NAS) server. NAS servers store and transfer data as files, and not blocks of data, so they don’t need the high-speed Fibre Channel protocol used in a SAN. NAS devices are best for file-based uses such as user home directories and shared documents.
Dissecting a SAN (The Four Ps)
We divide this section into four parts, which we call the four Ps — namely the parts, protocols, players, and platforms you can choose from when creating a SAN. We don’t go into all the gory details because it would take up too much space here and most likely be better for bedtime reading (you’re getting sleeeepy). We just give you a general overview of the following:
The parts: All the hardware you use to create a SAN; the switches, cables, disk arrays, and so forth
The protocols: The languages that the parts use to talk to each other
The players: The folks who build the parts
The platforms: The computer applications that benefit from using SAN
The Parts of a SAN
It’s most convenient to imagine the parts of a SAN in three layers. The top layer is the host layer, which includes the server computers and everything that goes into them. The middle layer is the fabric layer, which includes all the cabling and switches that connect everything. The bottom layer is the storage layer, where all the storage devices are located.
The host layer
The major components in this layer are the servers themselves, the host bus adapters (HBAs, which include a part called the Gigabit Interface Converter, or GBIC), and all the software running on the server that enables the host bus adapter to communicate with the fabric layer.
The host bus adapter (HBA)
The server connects to the SAN through a host bus adapter (HBA) — an I/O adapter card that fits inside your server and connects it to the fabric layer.
The Gigabit Interface Connector (GBIC)
The Gigabit Interface Converter (GBIC) is where the cable plugs into the HBA card. Every HBA has a GBIC that snaps into an opening in the card or is soldered to the card. The openings in the GBIC extend out the back of the server so you can plug in the cable. The GBIC houses the laser and electronics that convert the data inside your server into light pulses that travel over the cables. GBICs are used not only in the HBA, but in every device in the SAN. Anywhere an optical cable has to be plugged in, you find a GBIC.
Fiber-optic cables
Fiber-optic cables are unique in that they are really part of all three layers in a SAN (such as the GBICs where the cables are plugged in). These cables, which connect everything in a SAN, use glass fibers to transmit light waves from one device to another. You can use one of three optical cable types, depending on the distance between connections and the wavelength of light used to transmit data. (See Chapter 2 for more information.)
The fabric layer
The fabric layer, or the middle layer of a SAN, is the actual network part of a SAN. The network — where all the cables are connected — is also where you find hubs, switches, gateways, and routers, which tie all the cables together into a logical and physical network. Its components include
Hubs: A hub is a simple electronic device that physically connects the cables into a logical loop of cable. This is why hub-based SANs are called SAN loops. The hub has connection points — ports — where the cables get plugged in. These ports use GBICs to connect the cables to the hub. In a hub, the light coming in from a cable can pass through the hub to a device connected to another port. The light travels around the loop to each port in the hub. Because hub ports are connected in a loop, only one device can communicate through a hub at one time.
Switches: A switch is a smart electronic device that physically connects cables. Switches are the heart of a SAN network. This is where a lot of the intelligence resides. The switches reliably route your data from the host layer to the storage layer.
Think of a switch as working like a telephone switchboard operator. Every incoming call gets connected to its destination over the wires in the switchboard, and the operator knows which wire to plug in where to make this happen.
Gateway: A gateway (also referred to as a bridge) is a smart electronic device that physically or logically enables devices to communicate over one protocol to talk to devices that use a different protocol. For example, an iSCSI gateway can connect hosts that use the iSCSI protocol to storage devices that use the Fibre Channel protocol in a Fibre Channel SAN fabric.
Router: A router is another smart device that physically or logically routes data between two individual networks.
The storage layer
The storage layer is where all your data resides on the SAN. This is the layer that contains all the disk drives, tape drives, and other storage devices, like optical storage drives. The storage layer’s devices include some intelligence, such as Redundant Array of Inexpensive (or Independent) Disks (RAID) and snapshot or other data-replication technologies to help protect data. The capabilities of the storage devices can affect what you can do with a SAN.
Storage arrays
A disk is a disk — two disks are (okay) a couple of disks, and an array of disks is just a bunch of disks (also called a JBOD) all located in the same place. But a storage array adds extra intelligence to the controllers within the array — which allows you to do cool stuff like RAID, so it’s no longer just a bunch of stupid disks. The intelligence built into the storage controllers in the storage array is what enables this additional functionality.
A storage array is a big box that has a bunch of disk drives in it, running smart code called firmware that makes it more intelligent. Of course, you could go to a computer store and buy a bunch of hard drives, but how would you connect them to your server? Today’s storage arrays use fast, dedicated microprocessors to run complex software that makes them more useful than they’d be if you just connected a bunch of disks to your servers. (More on storage arrays in Chapter 2.)
The storage arrays connect to the fabric layer with cables that run from the devices in the fabric layer to the GBICs in the ports on the array. Many types of storage arrays are available, but they come in two basic flavors: modular and monolithic. Both these types use built-in computer memory to help speed up or cache access to slow disk drives; each uses the memory cache differently. Memory is expensive, so the more expensive monolithic arrays usually have more cache memory than modular arrays. Here’s a closer look.
Modular arrays
Modular arrays have fewer port connections than do monolithic arrays; they usually store less data, and connect to fewer servers. They’re designed so you can start small, with only a few disk drives, adding more drives to the array as your storage needs grow. Modular arrays come with shelves that hold the disk drives. Each shelf can hold between 10 to 16 drives, depending on the model and manufacturer. Modular arrays usually fit into industry-standard 19" racks, so you can have all your servers and SAN disks in the same rack.
Modular arrays are perfect for smaller companies looking to install a SAN on a limited budget. They’re also good for large companies with many remote offices, because they are much cheaper and smaller than big monolithic arrays, so they can be placed into smaller offices. Modular arrays almost always use two controllers with separate cache memory in each controller, and then mirror the cache between the controllers to prevent data loss. Most modern modular arrays have between 16 and 32GB of cache memory.
Monolithic arrays
Monolithic arrays are those big, refrigerator-size collections of disk drives you see sitting next to mainframes in a data center. These disk arrays are loaded with advanced technology that almost always prevents them from going down. Monolithic arrays can accommodate hundreds of disk drives, can store data for a lot more servers than a modular array can, and usually connect to mainframes. Monolithic arrays have many controllers, and those controllers can share direct access to a global memory cache (up to hundreds of gigabytes) of fast memory. This method of sharing access to a large global or monolithic cache is why these arrays are also called monolithic.
Modular versus monolithic in large-scale enterprise use
At larger scales of operation, modular arrays are often used as midrange arrays and monolithic arrays are often used as enterprise arrays. The main difference here, however, is functional: Although some enterprise-class arrays can be modular in design, they can also connect to and store mainframe data (which a modular array usually can’t do). Typically enterprise-class monolithic arrays are much more expensive, and have better built-in redundancy features that make them extremely reliable.
Whether modular or monolithic, each array type has its advantages and disadvantages. Modular arrays are generally less expensive but can handle large-scale workloads if you add enough disk shelves or controller shelves to do the job. When you add controller shelves, you get more horsepower. When you add more disk shelves, you get more storage.
Modular arrays are designed from the ground up to be extremely fast when connected to just a few servers. If you need to add servers, you just buy more controllers. Many companies like that kind of flexibility. Monolithic arrays, on the other hand, can be connected to mainframe computers. They also usually have many more physical ports on them to connect to the SAN, allowing many more servers to use the array. Many companies use monolithic arrays to help consolidate more storage into less space without losing performance when servers are added. Monolithic arrays are almost always more expensive than modular arrays, but you get what you pay for.
The SAN Protocols
As mentioned earlier, a protocol is a type of computer language used by a computer system to communicate with other devices. By language, we don’t mean a programming language. It’s more like a set of agreed-upon methods — a way for computers to communicate so they can cooperate in moving data over the network.
Each type of computer device uses a different protocol to communicate with other devices. After two devices find a common language, they establish a communication session by greeting each other with a friendly exchange of code called a handshake. In effect, they have a conversation to find things out about each other and to negotiate the best or fastest way to communicate.
There are two major protocols (languages) used in Fibre Channel SANs: the Fibre Channel protocol (used by the hardware to communicate) and the Small Computer System Interface (SCSI) protocol (used by software applications to talk to hard drives). Here’s a closer look:
Fibre Channel protocol: This is the language used by the HBAs, hubs, switches, and storage controllers to talk to each other. The Fibre Channel protocol is a low-level language; it’s the means of communication between actual hardware components, and not between the applications that run on the hardware.
Actually, two protocols make up the Fibre Channel protocol: Fibre Channel Arbitrated Loop (FC-AL), which works with hubs; and Fibre Channel Switched (or FC-SW), which works with switches. (Chapter 2 has more on the Fibre Channel protocols.)
Fibre Channel is the building block of the SAN highway. It’s like the road of the highway, where other protocols can run on top of it, just as different cars and trucks run on top of an actual highway. In other words, if Fibre Channel is the road, then SCSI is the truck that moves the data cargo down the road.
SCSI protocol: This is the language used by SAN-attached server applications on the server computers to talk to the disk drives. This protocol lies on top of the Fibre Channel protocol.
This book is focused on Fibre Channel-based storage networks, so we only briefly touch on other protocols such as iSCSI (the SCSI protocol used over an IP network rather than a Fibre Channel network) and the Infiniband-based protocols (such as iSER and SRP) that can also be used to create a high-speed storage network. Infiniband itself can be a whole other book; it’s used increasingly in GRID computing — connecting many low-cost servers over a high-speed network to act like one very fast computer. Storage is always the slowest part of any computer, so using a high-speed SAN with a GRID is essential. NASA and the CIA use GRID computing networks to gather and analyze massive amounts of data.
Even though most storage array manufacturers now use Fibre Channel disks in their storage arrays, the disks themselves still use the legacy SCSI protocol to communicate with applications over the Fibre Channel network. All the SCSI messages are encapsulated (packaged) into the Fibre Channel protocol. It’s kind of like writing a letter to your dear Aunt Sally. (Aunt Sally is your disk drive here.) You write a letter (your data) and address the envelope (a SCSI block) to Aunt Sally (your disk). You want it to get there fast, though, so you put the letter into a FedEx package (you encapsulate the SCSI block in the Fibre Channel frame) and send it off. The Fibre Channel switch in the SAN opens the FedEx package (Fibre Channel frame), looks at the original address on the envelope (SCSI block), and sends it along its merry way at light speed to Aunt Sally (your disk).
How SAN devices communicate
Using English as a metaphor, think of a typical protocol conversation like this:
HBA in the server: ”Hey! How are you? I’m in this server, and I’m trying to find a disk drive to store this data. Who are you?”
Switch: “Hi. I’m a Fibre Channel switch. I see that you can speak Fibre Channel. Let’s talk using the new version 2 dialect, okay?”
HBA in the server: “Okay. Look, do you know of any good disk drives I can use to store the data?”
Switch: “Sure, according to your address, I’ve been authorized to give you access to a drive on my Port 3. Would you like to speak with her? Remember, SCSI drives speak a different language. Do you speak SCSI?”
HBA in the server: “Nope, but the server’s application does! Thanks. I’ll have him send you all the data using the SCSI protocol. Can you forward this to the disk?”
Switch: “Done deal. Hey, SCSI drive on Port 3, here’s a message for you!”
At this point, the session is established; the switch now passes SCSI messages through to the disk drive. The drive acknowledges the messages and does what the server tells it to do.
All Fibre Channel devices work this way. The language for communication with storage devices is SCSI. Fibre Channel is just the FedEx way of getting it there faster, like a postal deliverer running at light speed. SANs work by giving the SCSI protocol a free ride on top of the Fibre Channel protocol to make communication happen much faster.
The SAN Players
The players are the companies that are the driving force in the SAN industry. Hundreds of companies are selling SAN equipment these days, each selling products that fit into a particular niche. You can break the players down into the different types of products that they sell. Some companies can sell everything you need, including servers. Server companies sometimes buy other companies’ products and resell them as their own. (Most of us can’t be good at everything
