关系数据库产品简单分析
- 概述
分析目前市场上流行的关系数据库系统，为核心数据仓库、数据中心及专项系统数据库选择提供依据。
- 市场分析
目前市场上流行的关系型数据库系统有DB2,Oracle,SyBase,SQL Server,MySQL等。据美国Gartner公司统计,截止20##年底,ORACLE在全球以48.8%的市场占有率继续领跑关系数据库市场,已连续两年稳固该市场老大的地位,下图为Gartner公司的分析报告：
在数据库许可证收入方面Oracle也远远超过其竞争对手IBM、微软和SAP，这也从另一方面折射出Oracle产品的稳定性和服务方面到保证性。从产品方面讲，Oracle支持所有的操作系统，数据库的兼容性、稳定性、高可用性、数据的可移植性非常高。从服务方面讲，Oracle针对数据库有非常细分的服务级别定义，不仅能满足客户最低层次的技术服务需求，也对高端客户进行了针对性的服务定制，提供了很多实用的数据库管理工具，整体上降低了数据库项目实施的成本。 这也是Oracle引领全球市场的主要原因。
- 特性介绍
下面简单介绍下常用关系性数据库的一些自身特点。
Oracle
作为全球最大的，领先的数据库巨头，Oracle涉及了数据库行业的所有领域，产品线强大，在数据仓库、数据分析、在线事务处理方面都具有很强的表现。综合对比Oracle具有以下优点:
ñ 兼容性
Oracle 数据库采用ANSI SQL设计，能和目前市场上所有的SQL范式兼容，与IBMSQL/DS、DB2、INGRES、IDMS/R等标准兼容，方便数据交换和数据对接。
ñ 移植性
Oracle的产品可运行于大多数硬件与操作系统平台上。可以安装在多种不同的大、中、小型机上；可在VMS、DOS、UNIX、Windows，Linux等多种操作系统下工作，支持多种网络协议，这为以后的系统升级和平台迁移提供了方便。
ñ 高可用性
在一个大型数据库或数据仓库环境，数据库是基础中的基础，数据库服务的连续性和可用性非常关键，为保证中心数据库的持续可用，Oracle提供了一系列高可用性产品，比如RAC,DataGuard,Streams Replication等。在数据备份方面，提供了全球最为强大的可免费使用的RMAN备份工具，RMAN备份是给予物理级别的，不及备份了数据还备份了数据相关的文件和日志，这样关键时期可以缩短数据恢复的时间。RMAN包含在Oracle数据库的所有版本中。大多数商业数据库，企业级的备份需要支付昂贵的License.
ñ 开放性
Oracle数据库具有高度的开放性，为了满足学者了解和学习Oracle数据库，Oracle公司提供了开发许可License，这个License不需要支付费用，Oracle官网提供了可下载学习的数据库产品 ，并且在产品中包含了这个License。也就是我们可以合法免费的使用部分Oracle数据库产品进行学习。Oracle支持多种驱动程序和开发工具，开发者可以很轻松的开发基于Oracle数据库的产品。
ñ VLDB的支持
Oracle天生为大型和超级数据库提供了支持和扩展，Oracle Table Partition( 数据表分区)提供了在数据表很大的情况下，可以对表进行物理分区，解决大表管理困难和数据查询或更新导致的性能问题，同时数据表分区也有利于解决数据迁移的问题。
ñ ASM的支持
从10G开始，Oracle提供了自己的数据库存储管理解决方案，引入了ASM（Automatic Storage Management)，ASM是Oracle的一个附属系统。解决了三个问题：1）从整体上将数据库的逻辑定义和物理存储分开管理；2）在线存储添加和卸载，Oracle数据库从操作系统接管了部分物理存储管理权限，在不影响数据库业务的情况下可以很轻松的在线完成ASM磁盘的添加删除任务；3）数据均匀分布，在我们每次对ASM完成磁盘调整工作之后，Oracle会自动重新分布数据调整数据，这样可以提高数据库的查询性能，避免了磁盘热点问题。
ñ 数据库仓库
Oracle提供了作为数据仓库所必须或者扩展的功能，1）Table Compress（表压缩），数据仓库中保存了很多的历史数据，这些数据的结构相同，数据规整整洁，可以通过表压缩功能对数据进行压缩，通过压缩不仅可以节省存储空间，还可以提高数据搜索的效率(磁盘I/O读取减少）；2）Materialized View，这是Oracle独有的特别针对数据仓库设计的一种数据存储解决方案，数据仓库通常要进行复杂的聚合计算，这些计算需要复杂的SQL计算逻辑，为了应用方便，可以将这部分计算创建成Mater VIEW。 Mater VEW和普通View的区别在与，Mater VIEW是一种物理视图，结果可以物理保存，可定期刷新视图获取最新的结果。
DB2
DB2是IBM旗下的关系型数据库，作为和Oracle同步起家的产品，DB2身上照耀了很多的关怀，关键的一环是出在IBM的怀抱。业绩方面，DB2在企业级的应用最为广泛，在全球的500家最大的企业中，几乎85%以上都用DB2数据库服务器，而国内到1997左右年约占5%。随着Oracle的改革，从2002开始，Oracle改写了这一辉煌。DB2的成功莫过于IBM自身的硬件和强大的软件支持，大多数企业选择了IBM的小型机后，经过IBM的关系营销，也会选择IBM的软件，包括DB2。
DB2的整体特性有：
ñ 支持多种操作系统，支持目前流行的Linux(IBM自身的Linux OS)，Windows等，Unix只支持IBM自己的AIX；
ñ 对硬件有一定的要求，最初只支持IBM的AS/400系统，现在支持INTEL部分硬件；
ñ 兼容Oracle，DB2兼容Oracle大多数的数据类型和SQL语言，比如PL/SQL；
ñ 开放性不高，没有Oracle，SQL Server，MySQL高度开放；
ñ 可靠性好，尤其和IBM的小型机可以集合起来;
SQL Server
SQL Server是由微软开发的数据库管理系统，是Web上最流行的用于存储数据的数据库，它已广泛用于电子商务、银行、保险、电力等与数据库有关的行业，目前最新版本是SQL Server 2012。SQL Server只能在Windows上运行，操作系统的系统稳定性对数据库十分重要。并行实施和共存模型并不成熟，很难处理日益增多的用户数和数据卷，伸缩性有限。
SQL Server 提供了众多的Web和电子商务功能，如对XML和Internet标准的丰富支持，通过Web对数据进行轻松安全的访问，具有强大的、灵活的、基于Web的和安全的应用程序管理等。而且，由于其易操作性及其友好的操作界面，深受广大用户的喜爱。作为开发和测试，SQL Server可以是个不错的选择。
MySQL
MySQL是最受欢迎的开源SQL数据库管理系统，它由 MySQL AB开发、发布和支持。MySQL AB是一家基于MySQL开发人员的商业公司。MySQL是MySQL AB的注册商标，2010 年MySQL被Oracle收购。
MySQL是一个快速的、多线程、多用户和健壮的SQL数据库服务器。MySQL服务器支持关键任务、重负载生产系统的使用，也可以将它嵌入到一个大配置(mass- deployed)的软件中去。
与其他数据库管理系统相比，MySQL具有以下优势：
ñ MySQL也是一个关系数据库管理系统；
ñ MySQL是开源的；
ñ MySQL服务器是一个快速的、可靠的和易于使用的数据库服务器；
ñ MySQL服务器工作在客户/服务器模式或嵌入式的系统中；
ñ 有大量的MySQL软件可以使用；
ñ 支持多种数据库引擎，这是MySQL一大特色，在读密集和事务密集形应用中，可以选择不同的数据库引擎。
ñ 可以快速部署的主/备复制模式
第二篇：为什么要用非关系型数据库
bNoSQL数据库探讨 -- 非关系型数据库
随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域， 非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不 从心，暴露了很多难以克服的问题，例如：
1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到 每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网 站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需 求。
2、Huge Storage - 对海量数据的高效率存储和访问的需求
类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到 了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登 录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求 在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展 是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：
1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负 担。
2、数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
3、对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值 数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference，各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：
Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB ， ......
这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，看都看不过来了，这 些NoSQL数据库大致可以分为以下的三类：
一、满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare
高性能Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis，Tokyo Cabinet， Flare，这3个Key-Value DB都是用C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的功能：
1、Redis
Redis是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统 统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是我知道的性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，例如从 List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要 依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有 github，Engine Yard。
2、Tokyo Cabinet和Tokoy Tyrant
TC和TT的开发者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS网站mixi.jp上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value 数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供
了多线程高并发服务器，性能也非常出色，每秒可以处理 4-5万次读写操作。
TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件查询， 分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一，有一个 Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。
TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能 的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的NoSQL数据 库。
TC主要的缺点是没有scale的能力，如果单机无法满足要求，只能通过主从复制的方式扩展，另外有人提到TC的性能会随着数据量的增加而下降，当数据量 上亿条以后，性能会有比较明显的下降。
这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考
3、Flare
TC是日本第一大SNS网站mixi开发的，而Flare是日本第二大SNS网站green.jp开发的，有意思吧。Flare简单的说就是给TC添加了 scale功能。他替换掉了TT部分，自己另外给TC写了网络服务器，Flare的主要特点就是支持scale能力，他在网络服务端之前添加了一个 node server，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。如果你的使用场景必须要让TC可 以scale，那么可以考虑flare。
flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的 key-value数据结构存储。
二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB
面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。MongoDB是用C++开发的，而 CouchDB则是Erlang开发的：
1、MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似 json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几 乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上
的时候，Mongo的数据库访问速度是MySQL的10倍以 上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。 因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认 为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。
最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是 特别复杂的Web应用，比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著 的提升。
MongoDB也有一个ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几 乎和DataMapper一模一样，功能非常强大易用。
2、CouchDB
CouchDB现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。
三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort
面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同 构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因 此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的： 1、Cassandra
Cassandra项目是Facebook在20xx年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而开源出来 的Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了 Facebook之外，twitter和digg.com都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到 其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在 群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。
Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台 架构部门领导Evan Weaver写了一篇文章介绍Cassandra：/articles/2009/07/06
/up-and-running-with-cassandra/，有非常详细的介绍。
Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对 这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取 决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。
2、Voldemort
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个SNS网 站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如 Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读 写性能也很不错，每秒超过了1.5万次读写。
从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库，特别是对 数据库的scale能力方面的需求是多么殷切。前面提到，web应用的架构当中，web层和app层相对来说都很容易横向扩展，唯有数据库是单点的，极难 scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在Cassandra这么热门的 主要原因。
========================================================================
Storage Area Network and SAN Protocols （SAN：存储区域网络及其协议 ） 存储区域网络（SAN）是一种高速网络或子网络，提供在计算机与存储系统之间的数据传输。存储设备是指一张或多张用以存储计算机数据的磁盘设备。一个 SAN 网络由负责网络连接的通信结构、负责组织连接的管理层、存储部件以及计算机系统构成，从而保证数据传输的安全性和力度。 典型的 SAN 是一个企业整个计算机网络资源的一部分。通常 SAN 与其它计算资源紧密集群来实现远程备份和档案存储过程。SAN 支持磁盘镜像技术（disk mirroring）、备份与恢复（backup and restore）、档案数据的存档和检索、存储设备间的数据迁移以及网络中不同服务器间的数据共享等功能。此外 SAN 还可以用于合并子网和网络附接存储（NAS：network-attached storage）系统。 当前常见的可使用 SAN 技术，诸如 IBM 的光纤 SCON，它是 FICON 的增强结构，或者说是一种更新的光纤信道技术。另外存储区域网络中也运用到高速以太网协议。SCSI 和 iSCSI 是目前使用较为广泛的两种存储区域网络协议。
===============================================================================
FC存储的尴尬与IP 存储的未来
我们H3C基于IP构件了存储理念，那存储的未来是ISCSI吗？FC的前景又如何呢？请看本文。4Gb FC技术是新技术吗？
20xx年4Gb FC技术的应用终于得到了广泛的普及应用。但业内人士都知道，这种灵验背
后大多带有浓重的“政治”色彩，光纤协议技术的升级也难逃嫌疑。本身和周边配套设备，似乎都在暗示着4Gb FC更像是一个迟来的“新”技术。
实际上在物理层上，4Gb FC并无设计阻力，采用的是与2Gb FC完全相同的接口标准——LC SFP，而且我们完全有理由相信，在未来的8Gb FC技术中，依然会沿用这一标准。因为这本来就是10Gbps以太网络中的XFP标准。也就是说，物理介质方面根本没有技术瓶颈，4Gb和8Gb只是用来吸引用户眼球的数字游戏而已。
也许大家认为4Gb FC和8Gb FC采用了新的芯片的设计，但是实际上早在20xx年的时候，Brocade公司就已经开始在其Fabric光纤交换机中使用8Gb带宽的端口控制芯片了。同样是在20xx年，Vixel公司被Emulex收购之前，推出过一款做在芯片上的交换机。这款SOC（Switch on Chip）在一颗芯片上就实现了20个FC端口的交换。在2Gb FC推出之后，SOC迅速支持了2Gb FC，其总交换带宽在20xx年就已经达到了40Gb之多。
PCI总线带宽曾经是个经常被提及的瓶颈。然而时过境迁，如今的PCI技术不仅可以支持全64位工作，而且已经PCI-E已经实现了串型结构，已经可以达到将近40Gb的带宽。这个数字是4Gb FC理论带宽的10倍之多！
我们从存储设备的角度来看，似乎FC是高性能的代表，但实际上中端磁盘阵列的控制器可以支持8Gb甚至更大带宽的比比皆是。其实正是由于光纤通道协议升级不够及时，为了充分发挥控制器的能力，才迫使各磁盘阵列厂商在设计控制器时拼命的增加后端磁盘环路数量。20xx年开始，四个甚至八个后端磁盘环路的设计开始盛行。要是4Gb FC发布的早些，这些阵列控制器的设计肯定会精炼得多。
了解过物理介质、核心芯片、总线技术和阵列控制器的发展状况之后，回头再看4Gb FC的出现。才真正有发展速度滞后的感觉。 打开“光纤协会”网页就会发现，与其他IT技术协会相比，这个协会中缺少几个重要的会员——IBM、英特尔、微软、思科，甚至连惠普和Sun均缺席其列。这些公司对IT技术发展的影响之大路人皆知，因没有这些公司的支持而没落甚至胎死腹中的例子也比比皆是。古有NetWare与Windows NT之争，今有1394“火线”技术与USB之战，还有数不清的大小战役，都结结实实的证明了强者与趋势之间的同一关系。而翻看“光纤协会”的会员名单，其中强者寥寥，更多的是名不见经传的“潜力股”或是本行业中位列二流的“趋势追随者”。以这样的班底，实难长期领跑于产业前沿。
在那些“巨无霸”之中，最让人看不懂的就是思科公司。事实上，思科公司在两年以前就已经开始生产光纤交换设备。时至今日，其该领域全球市场份额已经位列三甲之中。但“光纤协会”的会员列表中，至今也没有思科的影子，而且思科却在FCoe的协议上下了很大的功夫。桌面上的理由版本众多，而真正的玄机或许不久就可以揭晓。
。
磁盘SAS FC未来是谁呢？
从技术角度看，光纤通道占据了两个阵地：一是高端磁盘的端口；二是高端系统中主机与存储设备连接。而随着SAS技术和iSCSI技术这些“后浪”的日益成熟，两个阵地都遭受着强烈的炮火轰击，随时有失守的可能。
首先，在磁盘端口方面，光纤通道技术在扩展连接能力、性能和管理能力等方面明显优于传统SCSI技术，所以博得了高端用户的青睐。自产生之初，就牢牢的占据了高端磁盘端口这个阵地。然而SAS（串行SCSI）的出现，已经彻底打破了光纤通道技术的优势。
表面上4Gb FC与3Gb SAS相比，仍然具有一定的性能优势。但是实验室中的测试结果证明，事实并非如此。为什么呢？原因其实也很简单。大家都知道单个磁盘的性能瓶颈，主要是盘体内的机械部分，即硬盘的内部传输速率，而绝非端口部分。也就是说，对单个磁盘而
言，无论是3Gb SAS还是4Gb FC，都已经足够宽阔。磁盘端口协议的瓶颈效应，只有在磁盘数量足够多的时候才会显现。而SAS技术的优势也正是在此体现。
对光纤通道技术的研究表明，当50～60颗磁盘连接在一个光纤环路上的时候，光纤通道基本达到性能上限。换句话讲，当一个光纤环路连接的磁盘数量少于50的时候，最大性能由盘体决定。而当磁盘数量超过60时，所有磁盘的总体性能就基本等于此光纤通道的最大性能。请记住：是一条光纤通道的最大性能！在SAS磁盘系统中，各个磁盘是以交换的方式连接，不存在共享的通道带宽，自然就不存在性能上限瓶颈。在达到前端控制器最大能力之前，总体性能基本完全由盘体决定。而SAS磁盘和光纤磁盘的盘体部分，包括NCQ（指令优化队列深度）都完全相同。自此不难得出结论：当磁盘数量较少时，SAS磁盘系统与光纤通道磁盘系统的性能基本相同；当磁盘数量超过60时，SAS磁盘系统性能更优。
环路连接方式不仅拖累了光纤通道磁盘系统的性能，也影响了系统扩展能力。光纤通道协议规定，每个环路最多可以连接126个设备。这其实也是一些中高端磁盘阵列厂商拼命增加环路数的原因之一，否则怎能推出那些动辄支持数百上千颗磁盘的系统呢。SAS技术在这一点上进步了不小，其协议机制可以支持到每交换域16384个节点，比光纤通道的扩展连接能力足足提高了一百多倍。
当然，光纤技术可以将其交换机制使用在这个阵地上，依此收复一些性能和连接性方面的失地。但那样做的结果只能是，性能方面勉强与SAS技术持平，价格方面却高出太多。要知道，脱胎于SCSI技术的SAS，其控制芯片成本比光纤环路控制芯片都要低很多，更不要说光纤交换芯片了。
与SAS技术相比，光纤通道技术唯一的优势就是连接距离。SAS可以支持8米的连接线缆，而光纤通道技术则是傲人的10公里之多。不过很遗憾，在磁盘端口这个阵地上，光纤通道的这个强项恐怕无用武之地了。谁会需要磁盘与背板之间的连接在数公里之遥？
磁盘端口这个阵地频频吃紧的同时，主机连接那个阵地上，光纤通道技术的日子也不好过。面临来自iSCSI和SAS的双重威胁，光纤通道技术已经难有腾挪的空间了。
SAS技术支持了交换式连接机制，也可以构建具有相当复杂结构的存储网络。而且SAS由传统SCSI脱胎而来，很快各个主流服务器厂商就会在其主板内附带SAS控制器。显然，届时基于SAS的SAN，将比基于光纤通道的SAN更具成本优势。
目前的SAS主机连接端口采用4条均衡负载的3Gb SAS链路，这样不仅提高了连接可靠性和容错能力，更重要的是使每根实际物理连接承载的带宽达到了12Gb.这一性能是4Gb FC的三倍之多。如此看来，以SAS实现DAS或SAN的连接，不仅成本非常低，而且性能也会比4Gb FC高出很多。如此说来，为什么还需要4Gb FC呢？答案是…
从存储的发展来看，iSCSI才是未来！
在iSCSI技术刚刚诞生之初，曾经被贬其为低端技术，冠以“小型系统适用”的名分。而当时iSCSI性能的确乏善可陈，客观上纵容了这种言论流行坊间。然而，随着万兆以太网的降临，这种言论已经越来越站不住脚了。4Gb FC与10Gb以太网哪个更快？这个问题小学生都可以回答。
业界对iSCSI性能表现的微词，其中最常见的就是以太网的性能保证问题。用术语讲，叫做QoS问题。但置疑这些问题，大多引用的都是过时的老黄历。以今天以太网交换技术的发展，识别并保证数据库和媒体应用数据流的QoS都不在话下，iSCSI协议里面这点小问题早就不成问题了。
另外一个问题是针对磁盘动作的，大意是讲iSCSI协议需要经过太多的拆包动作才可以指挥磁盘。不像光纤通道，主机端与磁盘端口协议相同，根本无需拆包。这个说法看似有理，实则纯属无稽。除非我们讨论的是iSCSI接口的JBOD，否则主机端根本无需也无法直接与磁盘通讯。磁盘动作实际上是经由磁盘阵列控制器指挥完成的。而在这种情况下，主机与阵列控制器间无论采用iSCSI还是光纤通道连接，都要经过拆包，将数据还原为SCSI-3指令。两者的劳动量和复杂程度几乎是一样的。此前iSCSI设备性能较低，其实是因为IP的包头相对于FC多，而且有效数据只有1.5K效率不高，并且这个拆包动作由主CPU完成，耗费过多系统资源。而光纤通道技术从诞生第一天，采用的就是专用芯片处理拆包。所幸现在各个主流适配器厂商都发布了基于硬件处理的iSCSI适配器，而且iSCSI协议提供现在采用9K的巨桢方式，拆装包效率已经完全不逊色于光纤通道技术了。
至于iSCSI技术的连接能力、扩展能力以及先天的成熟性等方面的优势，就不再赘述了。这里再强调一点，在安全性方面，iSCSI完全是压倒式胜出。细数光纤通道技术中对安全性的设计，就会发现，这里简直就是光纤通道技术的不毛之地。仅有的分区（zoning）和卷隔离（LUN Masking）概念，也完全是照搬以太网几辈子之前的老套路。如果哪天光纤通道技术从这个世界上消失了，罪魁祸首绝对是安全性方面的严重设计缺陷。以架设存储专用网络为初衷的技术，怎么对安全性的关注这么低？难到存储专用网络就不是网络，就不需要安全了吗？
在未来的存储协议技术上，我们看好iSCSI，而且不仅仅是出于技术层面的原因，或许“政治”因素才真正使iSCSI胜券在握。看看iSCSI阵营中的主力——IBM、英特尔、微软、思科……当今IT世界中主掌生杀大权的角色悉数到齐。这场角逐实力对比之悬殊，不需多言。实际上，以HDS、EMC为首的光纤通道已经倒戈投降了，以EMC为例，EMC CX3系列全部有了C后缀支持iSCSI的产品，甚至DMX也全线支持。目前仍在真正奋力抗争的，只剩下博科这样的公司。他们的业务几乎100%是来自光纤通道市场，如果让他们放弃光纤通道技术，基本等于自杀。不过，07年博科也在考虑全面介入iSCSI市场了。不禁让人想起了当年Novell公司那婉转的投降标语：“从今天起，不要讲?Novell or NT?，而要说?Novell
and NT?就对了。”
存储架构师对集成iSCSI和FC存储的解析
集成iSCSI 和FC SAN有五种常见的方法，各有优缺，适应环境也各不相同。
不久前，中小公司开始部署iSCSI，以前他们都采用直连式存储；大公司一直采用FC SAN，而且技术更加成熟。但是，iSCSI技术成本较低、简单明了，《财富》1000强公司中已经有越来越多的公司开始利用iSCSI SAN实施FC基础架构，用以保护数据，实现Tier-2存储。
集成iSCSI 和FC也存在很大挑战。将iSCSI引入现有的FC SAN中，不仅会产生集成问题，还会导致一些存储架构变复杂，因为存储架构不仅需要了解IP和FC，还要有能力管理和调试多协议存储环境。试图这么做的存储架构师必须非常熟悉iSCSI的设计选项，因为这些设计会影响集成产品的性能、安全和可用性。
性能
iSCSI的一些新特性与IP协议的性质密切相关。FC协议适合于连接服务器和阵列的网络，基于IP协议的iSCSI可能会与非存储IP流量竞争。为了减少IP流量混乱带来的影响，数据中心的管理员应该通过专用iSCSI网络分离iSCSI流量和非存储流量，因为专用iSCSI网络与网络其他部分没有物理连接，或者采用访问控制清单、虚拟局域网（VLAN）等以太网隔离技术。华盛顿Spokane公共学校的高级网络管理员Kevin Mount说：“为了避免内部LAN产生干涉，我们决定在Foundry公司生产的48端口以太网交换机中独立运行iSCSI网络。”
尽管物理隔离和虚拟隔离技术大大提高了安全和性能，存储管理员依然需要在网络交换机和适配器中利用以太网巨帧和流量控制等先进技术，缓减阻塞，优化吞吐量。当一条千兆链路的网络带宽不够用时，可以利用以太网链路聚集（trunking）或链路汇集，将多条链路连接成一条聚集链路；这样就不必部署价格昂贵的10Gb以太网基础设施，又能克服网络带宽的限制。
在主机方面，TCP卸载引擎（TOE）和iSCSI HBA可以有效节省CPU周期，尤其是对速度较慢但注重性能的应用程序服务器。SNIA IP存储论坛主席David Dale认为，尽管TCP和iSCSI的传输速率为1Gb/s，不足最先进服务器硬件速率的10%，而目前85%的iSCSI在部署过程中只采用iSCSI Initiator软件，但是一旦10Gb iSCSI 得到普及，TOE和iSCSI HBA的作用就会越来越大。除了改善I/O性能，iSCSI HBA还会增加从SAN启动和加密等服务。
在多协议环境中，存储管理员需要注意以太网的特性，如以太网交换机和网络接口卡（NIC）之间的容错速度/方式会产生自适应问题，可能对iSCSI网络的性能产生不利影响。Mount 说：“为了降低自适应问题发生的概率，我们对所有的交换机和服务器以太网端口设置不可更改的编码。”
安全
iSCSI和FC采用不同的方法保证存储访问的安全，这可能是多协议存储架构师必须解决的最大问题。FC利用FC交换机实行分区，通过全局名称排列LUN编号和主机标识，而iSCSI采用上述隔离iSCSI的物理和虚拟方法，通过IP地址、主机系统和存储设备的名称、内部/外部CHAP身份验证等方式限制访问，从而保证存储安全。
实行多种iSCSI身份验证方式似乎让人不知所从，其实规则很简单：对于基于IP实现隔离的iSCSI网络，主机系统和存储设备的名称就已经足够验证用户身份。在iSCSI与LAN之间存在物理连接的情况下，应该部署更加严密的CHAP身份验证方式，消除IP地址访问iSCSI LUN时带来的外部影响。当环境中拥有大量iSCSI设备时，可以采用Radius服务器实现集中验证，这样就不需要在iSCSI的存储设备中管理用户证书。
休斯顿贝勒医学院企业服务与信息系统主管Mike Layton采用了类似的策略，他利用主机系统和存储设备名称实现iSCSI授权，验证访问其FC SAN的少量服务器。他的基于日立数据系统（HDS）公司的FC SAN，在隔离的iSCSI LAN中采用NetApp FAS980c网关产品。
集成iSCSI和FC的最大好处在于：支持IP协议中的IPsec加密协议，IP流量出现故障时，都应该集成iSCSI和FC.但是，当服务器处于繁忙状态时，IPsec加密协议的开销非常大。在采用IPsec协议的环境中，服务器和网络带宽匮乏的计算机都应该凭借Cavium网络公司等公司提供的硬件加密技术，配备iSCSI HBA或NIC.从网络层面讲，Decru公司（现为NetApp）、NeoScale系统公司等公司都提供加密产品，设置在数据存取路径中，在FC和iSCSI数据抵达网络附属存储阵列之前，就对其进行加密。
存储管理接口很容易受到安全漏洞的攻击，但是在存储设计过程中又通常遭到忽视。不设密码、所有存储设备只设一个密码或者从不更改密码，都会使设计良好的SAN面临危险。只有特定系统和密码策略非常有效的VLAN才能访问管理接口，在具有大量IP设备的环境中采用集中化的Radius身份验证服务器，这些措施可以降低未获认证的管理变化带来的风险。
可用性
可用性是包括iSCSI SAN在内的SAN最重要的性能需求，需要在服务器、网络和阵列等层面上进行部署。在网络层面上，可以成对部署交换机，采用生成树状动态路由等以太网故障转移技术，实现冗余。在服务器层面上，通过双连服务器和以太网交换机，实现高可用性。凭借微软公司20xx年发布的iSCSI Initiator 2.0版，多路径IO（MPIO）使主机能够与iSCSI网络实现冗余连接。“我们的主机全都运行MPIO，而且与iSCSI SAN实现双连接。”麻省 Babson 学院和Wellesley学院开发体系结构主任Kuljit Dharni解释道：“主板上的NIC卡用于常规的LAN访问，以太网端口和英特尔PCI千兆网络适配器与iSCSI SAN相连。”
iSCSI存储设备的冗余选项根据供应商和产品种类而定。iSCSI网关产品、智能存储交换机和基于服务器的iSCSI存储设备，都可以在群集配置中见到，所谓群集配置是指两套设备以双机互备援（active-active）模式或双机热备份（active-passive）模式运行。一些中端存储阵列产品支持iSCSI，如EMC公司的Clariion CX3-20和CX3-40产品，可以通过双控制器架构提供冗余。高端阵列——如EMC 公司的Symmetrix DMX系列产品——需要底盘，只是简单地添加多个iSCSI刃片就能实现冗余。 iSCSI集成选项
将iSCSI集成到FC SAN中的方法多样、程度不一，取决于现有的存储环境和集成目的。一方面，存储架构师都有各自的目标，如贝勒学院的Layton希望通过iSCSI访问所有的FC存储。另一方面，存储管理员也有各自的目标，如Dharni完全实施iSCSI，不再使用FC SAN.另外，还可以同时运行FC 和iSCSI SAN，Spokane公立学校的Mount和伊利诺伊北伯克（Northbrook）Logs金融服务公司的数据系统管理员Dan Schneidemantle就采用这种方法。
在上述的最后一种情况中，设计时需要考虑的关键因素是iSCSI和FC SAN集成的程度。在多协议环境中，存储架构师往往部署iSCSI SAN，并使其与现有的FC架构同时运行，独立管理，以避免产生复杂的集成问题。EqualLogic 产品管理部主任Eric Schott 说：“我们的大多数客户独立运行iSCSI SAN和FC SAN.”“iSCSI LUN和FC LUN采用不同的安全模式，要将其匹配可不是件容易的事。”Schott补充道，“对许多存储架构师而言，就算集成好处再多，如果会增加系统复杂性也就不值得了。”
对于由一个供应商提供的多协议存储阵列，可以统一管理iSCSI和FC SAN.EMC、HDS、HP和 Net-App等公司都提供多协议阵列，统一管理iSCSI和FC，在某些情况下还可以管理NAS.FalconStor软件公司、 NetApp公司和Sanrad 公司提供的iSCSI虚拟化产品也可以实现统一存储管理。存储管理员若要将iSCSI集成到现有的SAN中，需要考虑以下集成问题：
iSCSI网关
支持iSCSI的FC交换机和导向器
智能存储交换机和网关
基于阵列的iSCSI集成方式
基于服务器的iSCSI集成方式
支持iSCSI的FC交换机
iSCSI网关
iSCSI网关可以转换协议，将iSCSI协议转化为FC协议，反之亦然。通常，iSCSI网关至少具有两个FC端口，可以连接到终端FC存储设备；至少具有两个1Gb的以太网端口，和服务器进行IP连接。iSCSI网关把FC LUN作为iSCSI的存储设备，通过IP就可以访问FC存储，无需在服务器中设置FC HBA.常见的网关产品有：博科通讯公司的iSCSI网关、思科系统公司的MDS 9216i、Emulex公司的725/735 iSCSI存储路由器、以及QLogic公司的SANbox 6140智能存储路由器。
在SAN中利用iSCSI网关产品实现存储需要两大步骤。首先，FC存储管理员为iSCSI网关提供LUN，然后在iSCSI网关限制iSCSI对FC LUN的访问，只有特定的IP地址、主机系统和存储设备、或者CHAP证书才能访问LUN.一旦完成这些设置，并且在iSCSI客户机上正确配置iSCSI存储设备，就可以在本地磁盘驱动器中看到指定存储。
iSCSI网关的主要好处就是，可以十分容易、毫无故障地将其添加到现有的FC SAN中。iSCSI网关不需要FC网络改变架构，只需简单地配置iSCSI Initiator软件，服务器就能访问FC存储。但是，iSCSI网关价格较贵——一套iSCSI网关产品的市场价大约为10，000美元。Windows系统和Linux系统的FC HBA至少需要花费400美元，因此有必要分析成本与收益：只有当大量服务器采用iSCSI网关时，才比较合算。服务器数量较少时，可以在服务器中添加FC HBA，直接连到FC SAN，这样显得更合算。博科公司市场产品部主任Mario Blandini说：“你至少需要拥有100台服务器，才能看到iSCSI网关的性价优势。”
支持iSCSI的FC交换机
如果你运行高端FC交换机和导向器，你的供应商很有可能会竭力推荐iSCSI网关，这样你就不必独立部署网关产品。将iSCSI网关放入FC导向器中，你就拥有了独立的管理控制台，继承导向式交换机的所有冗余和性能优势。
博科公司提供的SilkWorm 48000交换器就配备SilkWorm FC4-16IP iSCSI网关，交换器具有8个4Gb/sec的FC端口，8个1Gb的以太网端口，聚集的吞吐量达64Gb/sec.同理，思科公司供应IP存储服务模块（8个1Gb的以太网端口）和多协议服务模块（14个2Gb/sec的FC端口、2个1Gb的以太网端口），分别匹配MDS 9200 系列的多层网络交换机and MDS 9500系列的多层导向器。
供应商将iSCSI协议载入FC交换机，提供独立的iSCSI网关产品不具备的特性。例如，思科的产品支持虚拟路由冗余协议（VRRP），存储架构师就能为以太网与iSCSI的连接配置可选路径，这时如果主要端口发生故障，以太网端口能继续传输iSCSI.思科的iSCSI服务器负载平衡（iSLB），使存储管理员可以利用一个iSCSI目标入口（target-portal）的IP地址，配置所有的服务器，将以太网端口的任务传输到交换机。交换机将以太网端口的内容传输到iSCSI客户机，这么做不仅可以简化存储管理，还可以设计冗余充分的iSCSI网络，只要允许iSLB通过VRRP自动重新分配无效端口即可。
智能存储交换机和网关
iSCSI网关受到协议转换的限制，而智能交换机和网关却能提供虚拟化、快照、复制、镜像等存储服务。换句话说，智能交换机和网关就类似于多协议存储阵列，只是它们他们没有附属存储设备。
智能交换机和网关可以帮助存储架构师聚集现有存储，添加多协议支持（包括iSCSI），并且在单方管理协议下提供虚拟化、存储管理。NetApp的V系列网关是NetApp的存储控制台，没有附属存储设备，可以将iSCSI、FC和NAS连接到中央存储池。贝勒学院的Layton说：“我们用NetApp [FAS] 980c网关替代HDS FC SAN，使得SAN的iSCSI和NAS容量均有所增长。”
Sanrad公司的iSCSI V-Switch交换机能连接末端的SCSI、FC、iSCSI阵列，同时能将iSCSI连接到前端服务器。与NetApp的V系列网关相似，V-Switch存储服务平台也支持虚拟化、监管、镜像、快照和复制功能。Spokane 公立学校的Mount说：“Sanrad公司的iSCSI V-Switch交换机不仅能以iSCSI方式连接到Xiotech公司的FC阵列，也使我们能够统一管理FC存储和SCSI附属SATA存储。”
但是这种方法也有缺点。LeftHand网络公司解决方案市场部经理Pete Caviness说：“交换机中如果没有附属存储设备，虚拟化就会变得很贵，因为你需要为交换机付款，需要获取存储。”
基于阵列的iSCSI集成方式
EMC、HDS、HP、NetApp等大型存储阵列供应商都声称自己的阵列最适用于iSCSI和FC的集成。一些公司根据供应商调整基础架构，多协议阵列，能够统一管理iSCSI和FC，因此非常吸引这些公司的注意力。EMC公司存储产品市场部高级管理员Peter Lavache认为：“EMC公司的Navisphere管理套件能从监管、设置、复制等方面对iSCSI和FC实现透明管理。”
采用多协议阵列，就不必部署iSCSI架桥和网关，主机可以通过iSCSI直接与存储阵列相连。但是这些供应商出售的FC阵列并非全都支持iSCSI，是否支持iSCSI主要取决于阵列的种类和年代。NetApp公司支持iSCSI已有时日， 20xx年开始，NetApp公司的所有产品都支持iSCSI.目前，所有的NetApp存储盒默认状态下都支持iSCSI.其它供应商采取的措施相对谨慎。EMC公司的高端产品Symmetrix一开始就支持iSCSI，但是直到不久前，EMC公司才开始提供支持iSCSI的终端产品——Clariion CX3-20和CX3-40阵列。同样，惠普公司的高端产品StorageWorks XP阵列一直支持iSCSI，但是知道20xx年才推出支持iSCSI的终端产品
StorageWorks EVA阵列
目前，微软公司的Windows Storage Server 2003 R2也支持iSCSI.FalconStor公司在IPStor平台中添加FC，在一个存储盒中支持iSCSI、FC和 NAS.IPStor与智能存储交换机类似，拥有存储虚拟化、快照、镜像和复制等先进的存储功能。
IPStor与Sanrad公司的iSCSI V-Switch交换机也极为相似，不过有一处差别：IPStor软件几乎可以在所有的配置环境下、在任意服务器平台中运行。Logs金融服务公司的Schneidemantle说：“我们之所以选择FalconStor公司的IPStor，是因为IPStor非常灵活，这样，我们就能集成现有的HP MSA1000 FC阵列和FalconStor SATA存储，而这一切都通过IPStor加以管理。”他在主数据中心，配置一级、二级数据中心以及IPStor群集中心，二级数据中心可以通过iSCSI将数据复制到IPStor群集中心。
基于服务器的iSCSI集成技术最大的好处在于，能够很灵活地提供大量集成需求。缺点是，运行标准服务器的软件很容易产生问题，就如Schneidemantle所发现的那样。他说：“我们调整了双机互备援（active-active）模式的IPStor群集故障转移，将其改变为手动转移电力故障，这样两台机器不会产生群集节点。”
10GbE有望实现
10GbE以太网的价格有望下降，成为iSCSI网络有力负担的选择方式。届时，存储架构师也可以采用iSCSI部署高端应用程序，而过去人们一直采用FC存储部署这些程序。IDC研究副主席Robert Grey说：“现有的应用程序仍将采用FC，但是越来越多的新型应用程序将会选择iSCSI.”
FC SAN存储技术分析：如何解决存储问题
.cn/cio/ 20xx年04月27日11：23 来源：eNet硅谷动力 作者:LSI逻辑 SAN适配
器产品经理 Steve Looby 字号：小 | 大
基于光纤通道 (FC) 的存储局域网络 (SAN) 约占存储设备总销售额的 40%。这意味着，一半以上的存储基础设施都采用了基于数据块的 DAS 和 NAS 外存贮器技术。人们经常问，是否可用作为现有存储投资的补充来部署光纤通道，以构建真正的异构存储元件集合。
答案是肯定的，我们将在下面讨论几个相关的案例分析。
案例分析 1：由 Ultra320 SCSI、ATA、SATA 等组成的、完全基于 DAS 的基础设施
在这个案例中，存储设备是在几年内分批采购的，现在有数十、甚至数百台计算机 － 数十个、甚至数百个存储设备“容器”。每个节点的容量可能有很大差别，而且利用率的差别也很大 － 这是个大问题。但是，从许多层次上看，通过一次性采购来升级到 SAN、购买所有新的存储设备并将现有存储设备迁移到新卷的方式并不具吸引力。首先，执行数据复制过程需要很多的人力和 IT 资源，成本很高，而且不可避免地会出现员工生产效率丧失的阶段。其次，如果现有 DAS 存储设备过早报废也会造成很大的资本帐面损失。
解决方案 1：虚拟化
现在市场上有许多软件虚拟化产品可供选择，使您可以将现有 DAS 基础设施连接到 SAN。例如，FalconStor 推出了 IPSTOR 产品，它允许公司把现有 DAS 存储连接到该设备的后面，从而使得原有的存储设备可在光纤通道网络上使用。所有数据都在原处保存，不要求执行复制或迁移。而且，原有节点还能够配备 2Gb 光纤通道主机适配器。采用 SAN 的优势在于投资保护，可在原有存储基础设施上简便地共享、开展和构建多种功能。利用可随需求增长的 SAN，您可以引入新的本地光纤通道存储设备和光纤通道交换机，在计算机间高效地共享可用存储容量。因此，部署的异构系统可同时支持 DAS 和 SAN 组件。
案例分析 2：有网络设备组成的、主要基于 NAS 的基础设施
用户可能会感到惊讶，NAS 设备可将光纤通道等数据块存储设备转变为在以太网上显示的“文件视图”。连接到 NAS 的用户可以看到文件夹和文件，甚至可能不知道外存贮器使用了光纤通道。问题是，许多应用程序（例如 Microsoft Exchangereg;）在允许直接与光纤通道数据块存储设备通信时表现的性能更好；这是因为，他们能够避免与以太网和 TCP/IP 文件处理相关的开销。（这是一种广义上的概念， NAS 缓冲的大小仍然对顺序数据读写和随机数据读写的应用产生影响）。如同其他数据块技术（Ultra320 SCSI 和串行SCSI -SAS），光纤通道的时延也非常低。
解决方案 2：在 外存贮器上增加光线通道数据块访问功能
为了适应优化用来利用数据块存储设备的应用程序，用户可以在 NAS 设备上添加光纤通道目标接口。这个过程涉及到在以目标模式运行的 外存贮器中插入经过认可的光纤通道 HBA （主机总线适配器）。这样允许在 SAN 中通告一个或多个 LUN。然后，在每个希望访问这些 LUN(LUN，逻辑单元号, Logic Unit Number) 的计算机上安装单独的光线通道 HBA。最后，使用设备提供的管理 GUI，用户可向每个 LUN 分配 外存贮器的剩余容量。因此，部署的异构系统可同时支持文件和数据块级的数据访问。
案例分析 3：光纤通道存储设备“机架”太昂贵、不适于融合近线存储应用
许多 IT 机构的企业环境中都会积累数以千 G 的数据，几乎不可能在工作日之间的夜晚八个小时内完全备份到磁带中。市场上有许多磁带虚拟化产品，如 EMC 的 CDL （CLARiiON 磁盘库）和 Neartek 的 Virtual Storage Engine (VSE2)，他们可将基于 RAID 的磁盘设备转变为许可磁带设备，而且还可能具有很高的写入性能。各种应用以为它们在与磁带外设进行数据通讯，但实际上数据被写入了 RAID 设备中。这些 RAID 设备的速度允许 IT 管理员在指定的夜间时段内轻松地完全备份数据。此后，在第二天的工作过程中，可进行真正的磁带备份，而且还不会影响到 SAN 的性能。问题是，本机光纤通
道磁盘驱动器价格昂贵，不适用于这种“近线性存储”应用。
解决方案 3：使用 SAS/SATA 磁盘驱动器的光纤通道存储 JBOD
许多厂商都在推出内部使用 SAS/SATA 硬盘驱动器的光线通道 JBOD 机架。JBOD 无论采用哪种驱动器都能很好地工作。如果应用要求冗余端口、高 I/O 性能和最高的 平均无故障时间 等级时，用户可以选择更加可靠（也更昂贵）的 SAS 驱动器。对于近线性存储应用，用户可以选择使用不太昂贵的大容量 (300GB) SATA 驱动器。SATA 技术适用于大数据块、低 I/O 工作负载的近线性存储设备，适合与光纤通道“前端”连接集成。
案例分析 4：大量光纤通道存储设备采用物理距离很远的服务器
尽管光纤通道能够支持超过 10km 的光缆，但这经常不切实际，或者距离甚至会超出光线通道的适应能力。在这些情况下，企业往往会发现，无法在企业数据中心和工作现场的服务器间建立连接，使得服务器无法联网。
解决方案 4：ISCSI 和 FCIP 桥接产品
现在，供应商提供了一些新产品，允许不能联网的服务器以某种方式访问光线通道 SAN。第一种方式，采用 FCIP 或 iFCP；这些隧道技术允许在 SAN 间建立 广域网 距离的链路。例如，从技术角度讲，以太网被用来通过隧道将光纤通道从一侧的 SAN 连接到另一侧的 SAN。McData 推出了几种具备这种能力的新型交换机产品。第二种方法是以网桥的方式使用 iSCSI。光线通道 SAN 上的额外的存储容量作为在以太网网络上被声明为iSCSI的LUN。远程位置的服务器能够通过基于硬件的 iSCSI 适配器或基于软件的 iSCSI 驱动程序访问 iSCSI LUN。有免费的 iSCSI 驱动程序可用于 Windowsreg; 和 Linux 操作系统。这些驱动程序利用远程服务器上已有的以太网连接。尽管用户可以选择购买 1Gb iSCSI HBA，但他们必须考虑到许多远程办公室只有 T1 和部分 T1 WAN 连接，而不可能进行持续的 1Gb 传输。现在，McData 和 Maranti Networks 等许多公司都在销售具备光纤通道到 iSCSI 桥接功能的光线通道交换设备。值得一提的是，有些网络设备现在也可以提供 iSCSI LUN 功能。
作为一项技术，FC在海量存储方面有着极强的优势：简化的管理、更好的空间利用、更短的反应时间和高带宽。在过去十年中，FC在提高协同性、降低复杂性和减少成本方面等方面有了巨大的改进。这些改进已使FC超越企业级数据中心的应用，进入中小企业领域。上面一系列的例子旨在证明，在现实情况下，光线通道、NAN 和 DAS 的混合部署能够为用户带来很大的利益。
云计算与数据存储结合的难点分析
在现实生活中，我们会将大部分积蓄存放在银行或者委托金融机构进行管理。同时，在钱包中也会存有一定量的余钱，已被不时之需。其实这个道理就是云存储的实现模型。在云存储中，会有一个公共的存储中心（如网络上的某个数据存储服务器）用来像银行一样来保存企业的数据。同时一些比较常用的数据也会保存在本地（这就好像用户的钱包），以方便用户的使用。这就是云计算与数据存储结合的基本原理。这个设想是好的。但是具体实现起来，还是有一定的困难。笔者在这篇文章中对一些难点进行分析，以供大家参考。
一、 数据委托第三方管理，企业放心吗？
在银行刚出现的时候，没有多少人愿意将数据存放在银行中。即使到现在，一有风吹草动（如银行要倒闭了），储户还是会将钱从银行中取出来。这也就是说，钱存在银行中还是有一定风险的。而且用户对银行的接受有一个过程。其实云存储也有这方面的顾虑。对于大部分企业来说，客户信息、产品信息等方面的资料，都是企业赖以生存的源泉。他们是否会将这些数据存放在第三方那边呢？他们是否会担心信息泄露的风险呢？如果要让企业接受云存储产品，那么供应商就应该先让用户打消这个顾虑。让用户能够相信存放在他们那里的数据是安全的，是不会被未经授权的第三方获取的。
不过让企业接受这方面的信息具有一定的难度。其实早期的SaaS应用与云存储具有一定的相似性。都是将数据存放在第三方那边。但是SaaS的推行并没有被企业用户所广泛接受。其中很重要的一个原因就是因为企业担心敏感的业务数据被第三方泄露。其实从某种角度讲，现在企业用户对私密信息的泄漏深恶痛绝。连政府部门的信息（如考生信息）都会被当作商品来买卖。那谁又能够保证存放在第三方那边的信息不会被拿出来买卖呢？其实从数据安全的角度讲，包括三个层面。一是数据传输过程中的安全；二是数据保存时的安全；三是数据管理时的安全。其中传输中的安全，凭现在的安全技术应该不存在问题。数据保存时的安全，通过数据备份等技术也不会出现疏漏。而企业比较担心的就是数据管理时的安全。简单的说，就是其他人（如空间提供商的员工）他们能否接触到具体的业务数据，然后将这些数据拿出来卖。这不仅仅是一个技术问题，更是一个管理上的难题。现在私人信息经常被当作商品拿出来卖。这种事件多了，企业用户也对此产生了比较大的担忧。这是可以理解的。
在种种现实的压力下，让企业用户放心的将数据交给第三方来进行管理，这有一定的难度。这也是推广云存储产品时第一个需要解决的信任问题。云存储产品应该从技术与管理上，让用户放心将他们的数据保存在你那边。
二、 内部网路与外部网络之间连接的稳定性。
企业将大部分数据保存在互联网上的存储服务器上。当需要某个数据时，就可能要同互联网上的服务器进行交互。这也就是说，内部网络要与外部网络之间的连接具有很好的稳定性。但是要提高这个稳定性具有一定的难度。
像银行、证券等金融机构，他们要求网络的可用性达到99%以上。不过要达到这个稳定性的话，需要一定的投资。如在网络组件时，需要考虑到网络的冗余。简单的说，就是他们连接到总公司或者上级的网络，有多条路径。主网络路径发生故障时，会自动切换到辅助网络中。通过冗余网络，就可以大幅度的提高网络的可用性。但是大部分企业，能够采用冗余网络设计吗？恐怕不行。因为多一条网络路径，意味着企业需要额外的投资。根据笔者的了解，现在大部分企业采用的都是单条网络路径。当这条网络发生故障（如光纤因为施工被挖断）等原因，从而导致网络的中断。此时企业如果需要用到某个数据的话，就无法从互联网上的云存储服务器上取得。
而如果将数据存储在本地，这可以避免这种麻烦。即使企业内部的网络因为病毒或者其他原因发生故障，那么网络管理员加班加点也可以迅速解决。换句话说，此时主动权是掌握在企业自己的手中。
中国国内互联网的稳定性相比美国等国家来说，还有一定的差距。为此在国内推广云存储解决方案时，这也是一个难点。现在有些厂家在推广跟网络相关的产品时，在合同中都会加一条免责条款：因为网络故障导致的业务失败企业概不负责。从这里也可以看出，网络连接的稳定性会增加云存储产品的使用风险。为此根据笔者的了解，很多IT负责人宁愿自己花钱购买设备，将数据存放在企业内部。也不愿意将数据存放在互联网上。因为IT负责人很难保证网络的稳定性，而当网络出现故障时企业的用户又会将责任归结在他们身上。所以IT负责人也不愿意被这个黑锅。
故笔者认为这是云存储产品推广过程中遇到的第二个难点。在云存储解决方案中需要考虑到网络稳定性的因素，预先提供一定的预防措施。如在企业本地也提供一个数据的完整副本等等。
三、 费用的问题。
云存储的实质就是在网络上服务器提供商提供一个空间，然后企业租用他们的空间来存储数据。这中间必定会有费用的发生。这就像在银行中办理业务时，需要支付一定的手续费。可是现在银行手续费的涨价声，已经引起了很多的怨言。在这种背景下企业如果选择云存储产品时，就会考虑，以后这个费用是否也会涨价呢？等到绝大部分企业开始接受这个云存储产品，价格的主动权是否会在供应商那边呢？在这种情况下，如果从长远的情况看，IT负责人就需要考虑，自己投资与租用空间，到底哪个合算？
为此空间供应商往往需要对未来的费用做一个承诺。如未来十年之内的租用费用。在实际工作中，由于未来存在着不确定性。如对于服务器硬件来说，一般很难用到十年。如果未来硬件的购买成本增加，那么这个多出来的费用该如何处理呢？是转嫁到企业身上还是自己的消化呢？这些内容都会影响到未来空间的租用费用问题。由于未来的不确定因素太多，为此要做好这个费用的预算具有一定的难度。
为此笔者认为，费用也是影响企业是否接受云存储这个产品的重要因素。费用太高企业可能认为还是自己部署合算。而费用太低，则难于提供长期的、稳定的高质量服务。 最后需要说的是，现在的云存储一般都是与虚拟化存储结合使用的。简单的说，就是通过虚拟化技术将云存储空间划分成相对独立的区域，然后租用给企业用户。如此的话，就可以减少相互之间的干扰。这也就是说，在考虑云存储遇到的挑战时，还需要考虑虚拟化技术带来的风险。简单的说，就是空间提供商鼓吹他们的服务器有多高的配置。但是企业需要清醒的认识到，这个服务器并不是供你一家使用的。而是有很多用户同时使用。这就好像3G技术一样。有专家就指出，3G用户少时，网络速度还不错。但是等到用户数量一多，那么其性能就会成直线下降。对于云存储来说，也有这方面的顾虑。当用户的数量增多，同时服务器提供商又没有改善设备，则表示多个用户之间需要共享服务器的资源。那么用户数据存取的性能也就会下降。这也是企业在选择使用云存储产品时需要考虑的一个风险因素