究竟一个SAN的哪些部分应该设计成共享式的、又有多少部分应该设计成交换式的，这个问题必须视具体情况而定。在这一问题上，不应该将所存储的数据量作为决定组建何种类型的SAN网络的主要因素。相反，应该从数据的重要程度、网络的距离要求、存储设备的管理需求、数据的可用性和灾难恢复的需求以及管理和应付配置改变的能力方面来考虑。

 

    首先，应考虑企业内部如何进行重要数据的访问。例如，对于通过并行的SCSI接口连接的存储设备，服务器是控制中心。当服务器发生问题时，可能需要30到90秒才能够正常复位。对于提供电子商务服务的公司，这段时间足以带来致命的打击，因此不能采用共享介质的SAN。因为这种网络不能够消除复位时间，而且由于令牌环还要进行一个环初始化过程(Loop Initialization Process)，这将导致所有设备的复位。

 

    假如对数据的访问具有相互竞争的需求，那交换式的结构体系则正好符合要求。假如对于存储有距离要求(如跨越建筑物或是跨越园区内的多幢建筑物)，则SCSI可能就不是一种合适的选择，因为SCSI的传输有70米的距离限制，即使使用了SCSI集线器或者中继器也没有用处。假如想要监视位于多个建筑物中的设备的状态，光纤通道的SAN比较适合，因为它本身就能够提供管理特性。使用位于环上的JBOD设备的部门，可以直接连接到位于SAN网络主干上的交换机上，交换式主干于是就与服务器以及位于环上的存储阵列直接连接，创建了一个虚拟的数据中心，为网络管理员提供管理数据和信息。

 

    最后，从灾难恢复的角度来看，交换式的结构也是一个正确的选择。在10公里或更远距离以外创建一个冗余(备份)的数据中心，需要非常高的带宽来进行数据同步，这一要求目前只有交换的方式能够提供。

 

SAN的ASP

 

    对于不同专业的从业人员，ASP有着不同的含义。但是当它和支持Web功能的ERP以及电子商务应用发生联系时，ASP只能是可用性、灵活性和性能(Availability、Scalability、Performance)的代名词。在这种解释之下的ASP带来了很多技术难题，那就是要求向用户提供跨越网络的可以持续稳定访问的应用系统。

 

    网络上这种开放的服务刺激了用户数量和数据的传输量，同时在应用上也产生了许多不可预知的问题。那些大型的ERP和电子商务系统遍布全球，为了提高性能，对这种应用的访问需要强有力的数据缓存。沿用以前的系统(如大型主机)来装载新的应用是一个极端，而选择基于PC的低端服务器运行应用则是另外一个极端。相比之下，SAN是最佳的选择，它能够减轻所有这些问题。

 

SAN和集群

 

    SAN可以被用作所有存储资源的高级网络主干，其中包括硬盘、磁带、光纤通道的硬盘和遥控设备，它们在网络上的所有服务器节点之间共享。支持SAN功能的集群使用了集群技术，也就是两台或多台互相之间知道彼此配置和所提供的服务/应用的计算机系统完全协同工作在SAN拓扑环境中。一个真正意义上的SAN网络早已超越了任意连通性、任意服务器到任意存储系统的连通的观念。事实上，通过将所有存储系统从一个高速的网络主干上隔离出来，或是通过在数据、存储管理和使用这些数据的应用之间引入逻辑层/物理层，这种好处是相当巨大的。

 

    为了实现无缝的存储管理，SAN结构本来应该在所有存储资源(如磁盘阵列、备份设备、逻辑卷的管理、文件系统管理和备份管理)以及所有需要这些资源的应用系统基础之上，引进一个软件层。那些运行在CPU数目满足需求的服务器上的应用服务(如应用服务器、数据库管理系统、中间件、HTTP服务器)能够提供负载均衡和故障切换功能，而不需要专门的存储设备。

 

    这些应用服务并不知道数据存储方面的有关信息，比如数据实际上究竟存放在什么地方、数据是否已经了镜像和分布式处理等。所有基于网络的RAID、分布式I/O、数据冗余、配置冗余、硬盘组、逻辑卷、动态的多个路径、分层存储、在线的高速备份等有关的问题都由存储管理系统来处理。一个正确的SAN是一个能够提供高可用性、增强的灵活性和改良的性能的基础构架。

 

    SAN能够提供一个理想的拓扑结构来实现集群系统，因而其中一个系统的故障并不意味着所提供的服务会发生任何中断。参与这一集群的其他一个或多个生还的结点将自动处理由故障结点所提供的应用或服务。支持SAN的集群的一个优点就是在集群环境中发生故障时恢复速度快。由于数据是持续可用的，问题仅仅是由备用或协同工作的应用来访问原先由故障结点来访问的数据。在能够容忍的灾难发生之后，SAN能够通过光纤通道从10公里以外提供数据。

 

挑战ERP和电子商务

 

    在可用性、灵活性和性能要求很高的大型的、支持Web功能的ERP和电子商务环境中，SAN和支持SAN的集群解决了一些主要的技术问题，如更为灵活的备份手段、更快的恢复、正常运行时间更长。

 

    从更高层次来看，现在具有三层或更多层结构的ERP和电子商务体系都向着一个方向发展，同时Baan公司、Oracle公司、PeopleSoft公司和SAP公司等不同厂商的系统之间还存在差别。现今所有ERP和电子商务应用都是支持Web功能的构件，就象OLAP构件、应用构件、数据库构件一样，在逻辑上是互相独立的。

 

    在应用结构适合SAN以后，最严重的问题便是这些模块化的应用所访问的大部分数据都集中在一个或很少几个数据库中(数据相当集中)。在这种情况下，一般可以对数据进行复制，以支持数据仓库或是其他负载分解方式。由于这些应用支持Web功能，使消费者能够对全球范围的用户分发他们的操作执行动作，这就使大量协同用户同时访问这些ERP和电子商务应用成为可能。

 

    而市场的这一趋向又带来了系统的可伸缩性问题。由于这些用户遍布世界各地，所提供的服务就要求不能因为时间原因而中断。这一趋势同样带来了可用性问题。随着用户以显著的速度增加，所收集和分发的数据的总量也以几何级数的速度快速增长。随之而来的便是要求对通过ERP和电子商务系统所收集到的数据(数据已经复制到了数据仓库)进行分析、加以分类，并通过现存的和新启用的应用进行扩充，于是这又带来了与性能和速度有关的问题。所有这些因素更加明确地向结构体系提出了要求，要能够解决可用性、灵活性和性能问题。

 

可用性(Availability)

 

    可用性是持续正常运行时间的一个衡量指标。当然，目标是100%的正常运行时间，这表明ERP和电子商务应用服务没有停工时间。通过对基础构造的所有构件部分都建立冗余(即使这一冗余是明显多余的，这是完全有可能达到的。

 

    为所有冗余部件建立冗余备份的观念能够应用到SAN中的所有硬件和软件中，如处理器、应用服务器、中间件、DBMS等。如今，为了实现高可用性和容错，在ERP和电子商务应用环境中集群扮演了统治地位的角色。基于共享(如Oracle公司的产品)或非共享(如Sybase公司的产品)结构将两台或多台服务器组成集群协同工作，是目前常用的方式。

 

    在这两种结构中，在系统和它们的存储单元之间都有着必须的大量冗余的互连，这一问题直到SAN出现才解决。随着SAN和基于SAN的集群的推出，由于在存储系统和服务器之间引入了一个逻辑/物理层，因而消除了这种连接要求。SAN中的每一台参与集群工作的服务器都能够访问SAN中的存储空间中的每一个字节，因而消除了系统和它们的存储系统之间的所有的互连需求。