存储解决方案：构建中小企业的SAN的几个方面

    前言：中小企业为了满足存储需求，是否应该转到SAN架构？SAN无疑有优点，但是省下来的资金和人力成本是否足够多呢？
  
    随着技术革新及用户需求的变化，大型IT公司的IT运行方式有所变化。这些变化也逐渐影响了中小企业。主要表现在下面几个方面：

• 全天候地使用Web进行事务处理，这已成趋势 ；


• 客户关系管理（CRM）软件的可靠性逐渐提高，以便指导销售工作；


• 公司主管更加重视公司数据的价值，以及重视备份和安全方面的安全隐患所带来的风险。


• 使用单任务的1U机架式服务器和刀片服务器。

    面临着来自新业务环境的压力也是同样存在的，中小企业的 IT部门也经常把三到四台服务器集成起来完成一件特定的任务（例如，Windows域控制器为台式机和移动PC提供文件，打印服务，以及单一的登陆服务；还有建立Linux Web服务器， Linux或者Windows邮件服务器。） 
  
    在新的IT环境中，使得成本增加明显的是数据存储。随着硬盘的容量增长迅猛，但这存储成本并没有随之节省了。传统的方法是在每一个主机上配置专用的基于SCSI的存储设备，这似乎可以满足数据安全性的需要，但不省钱。实际上，目前的存储实现方法将使得成本急剧上升。 
  
    主动－主动的控制器配置在SuSE Linux和Windows Server 2003的效果不同， 对于nStor 4520F系统，每个控制器对应一个阵列，两种操作系统均认出每个逻辑阵列的两个卷。在Linux中，可以访问第二个映像，而 Windows Server 2003则阻止访问第二个映象。从管理的角度看，这个方法简化了管理员的工作，但是在不重启动的情况下，就无法进行失效切换。
  
    存储成本的增加，使得IT人员使用RAID阵列来提高数据安全性的做法越来越不经济。虽然RAID 阵列提供了数学意义上的保证，来消除单点故障，RAID策略需要采用多个硬盘驱动器，这就增加了成本，因为需要维护奇偶位，使用冗余硬盘作为备用，也需要硬盘的副本作为镜像集合。（例如，RAID-10和RAID-50配置） 
  
    除了增加成本之外，多数站点通过昂贵的集成了板内缓存和电池备份的RAID控制器，来实现RAID功能。更糟的是， RAID性能的优化是通过提高硬盘的数目进行的，单考虑性能，硬盘容量是无关的。这就使得大容量硬盘变得有点浪费，而无法节省开销。
  
    在大型企业数据中心，总硬盘存储容量以terabytes字节计，存储容量节省下来的效果比SMB网站更可观，所以，在基于光纤通道的SAN中，对物理硬盘实现存储虚拟化，这对大企业特别有吸引力。 
  
    虽然早期SAN的成本和复杂性很高，大企业中所用到的存储容量从经济上看是划算的。
  
    如今，随着技术的革新和价格的下降，就像大企业购得起第一代的SAN一样，中小企业也有机会购买SAN设备了。技术革新推出了容量为200GB的硬盘，这就使得中小企业有机会实现SAN方案了，这些硬盘很容易构建 terabyte数量级的RAID阵列。虽然只有少数中小企业需要terabyte数量级的存储容量，不少SMB站点 发现总体存储容量正在快速转向terabyte数量级。
  
    如今的大容量硬盘仅仅只是让企业有机会降低成本，但并不等于在SMB环境中配置了SAN，就一定能够保证对硬盘的利用率是经济的。对于传统的SAN拓扑结构的维护和配置，其相应的费用较高，如果对于中小企业来说，也采用同样的方案，运营费用也降不下来。
  
    随着技术进步，SAN在其整个生命周期中的配置和管理均得到简化，所以，在中小企业，对于配置SAN的看法开始转变。
  
    我们强调“开始转变”，因为在构建光纤通道SAN中的不少费用，同诸如以太网这样的技术相比，价格仍然居高不下。 
  
    在传统的“不包括电池”这样的角度看，SAN交换机端口和不少SAN设备没有同光纤电缆直接连接的接口，这个表面上的疏忽实质上是交换机可以用于各种类型的不同波长和不同模式的光纤电缆。这些差异就是SAN的连接距离最大可达到 120公里。结果是，交换机端口设计成“通用的”，且需要价格为200到300美元的SFP收发器，把光纤电缆连接到交换机。
  
    在SMB中设置SAN时，我们主要关注的是先配置一个基本的可以正常工作的SAN架构，然后再扩展该架构。 目标用户应该是一个没有SAN设计和管理经验的系统管理员。 
  
    目标环境由三台运行不同操作系统的服务器构成，SuSE Linux Professional version 9和Windows Server 2003。我们的计划是要求每台服务器通过共享集中化的RAID存储系统，可访问多个逻辑硬盘分区。我们测试SMB的商业环境是需要提供全天候24小时，每周7天能够访问到所有的系统。 
  
    对于那些不熟悉SAN的人来说，重要的是知道处于低层的物理设备是 RAID阵列，通过阵列为每台服务器提供其对应的分区集。 这与通过NFS或者CIFS来共享文件系统是不一样的。 
  
    一旦打开了Brocade的WebTools软件，就会出现管理界面，其中网络中的所有的交换机的架构树图标就会展示出来，同时也包括管理功能菜单。点击一个交换机图标，就会实时显示出该交换机的状态，包括状态灯。通过交换机的实时视图，管理员可以打开属性页来管理交换机，包括授权序列号。
  
    SAN中的存储设备没有内置智能化的功能，来支持文件共享功能。文件共享的所有细节都是由操作系统来处理的。目前，带有对应文件系统的Linux或者Windows都无法支持SAN中的存储设备。实际上，从SAN架构中进行任何一项简单的路径错误的恢复工作，更多的表现为外在的，伤筋动骨的事件，而不是透明的事件。 
  
    我们使用三种服务器建立了测试环境。两台服务器基于 Intel Xeon的，带有PCI-X扩展槽： HP ProLiant ML 350 G3和Appro 2400Xi。每台服务器都安装了Emulex LightPulse 9802 Fibre Channel主机总线适配器（host bus adapter，简称HBA），支持最大可达133MHz的 PCI-X。我们的第三台服务器是Dell的PowerEdge 2400，带有Intel Pentium-III CPU和 64位 66MHz PCI槽。为了同SAN连接，该服务器安装了Emulex LightPulse 9002 HBA。 
  
    我们的SAN中的共享硬盘存储是由nStor 4520F Series硬盘阵列来处理的，4520F带有两个RAID 控制器，以主动－主动的方式配置的。每个控制器配置了一个 600MHz的 Intel RISC芯片，且包含1GB缓存，板内电池备份卡，以及两个SAN端口。
  
    结果是，SAN拓扑结构可由多达4个连接到nStor 阵列的交换机来配置。这就为系统管理员提供了很多的灵活性，以便优化连接到服务器的 I/O传输。重要的是，这样的配置消除了硬盘控制器出现单点故障的可能性。无论如何，在每台服务器上，对硬盘配置的复杂性有所增加。nStor 系统所表现出来的每个逻辑硬盘单元将出现多次，每次nStor SAN连接时就出现一次。
  
    最初我们采用了四个Hitachi UltraStar Fibre Channel硬盘和四个Seagate Cheetah Fibre Channel硬盘，来建立nStor系统，这些硬盘被格式化成两个独立的RAID-0阵列，总存储容量接近1TB。之后，我们在每个阵列上创建了三个逻辑单元分区 (LUN)，每台服务器可以从每个阵列访问一个LUN。
  
    为了实现nStor 阵列的主动－主动的双控制器配置所提供的容错功能，我们为SAN架构选择了一个基本的双交换机拓扑。由于连接到我们的SMB SAN环境中的设备数量不多，一个8端口的 Brocade SilkWorm 3200交换机足够支持目前的架构。但是，单交换机拓扑将使得交换机具有单点脆弱性，且无法提供24×7可用性的目标。 在我们的测试SMB环境中一旦有这些商业要求，就需要一个关键的评估要求，即迅速建立一个初始的两交换机架构并正常运行。 
  
    Emulex HBA和Brocade交换机的安装相对快速和简单，但是一旦有了测试要求，安装就需要多试几次。 
  
    由于我们的操作系统中有HBA驱动程序，所以在Windows Server 2003和 Linux中安装HBA很顺利。 在Linux中有点不同的是需要编译驱动程序源代码，并重建内核。这是不少小站点为了避免麻烦而采取的措施。然而，SuSE Linux 中的Emulex LightPulse模块并不是万能的。 
  
    Emulex对其软件的设计极为严格，Emulex把其驱动模块注册为控制Fibre Channel 接口而非硬盘控制器，结果是SuSE Linux并没有自动在 initrd 中包含Emulex驱动模块，这种做法对于熟练的Linux管理员来说是显然的：假如已经安装了基于SAN的硬盘，系统重启动将会失败。这是因为启动时系统运行 fsck，检查/etc/fstab中列出的每个硬盘，而Emulex驱动程序在启动时并不加载。解决的方法也是简单的：在 /etc/sysconfig/kernel 中添加Emulex模块，之后运行 mk_initrd，后者可以容易地使用YaST2完成。仍然有个问题：对于转向Linux的SMB网站来说，这样做是否过于复杂？
  
    类似的，对于系统管理员来说，使用Brocade交换机需要使用专用的串行电缆，需要使用telnet和命名行接口。当建立 Brocade交换机时，系统管理员将会发现没有NAS应用中常用的简单的网络发现机制。 
  
    一旦所有的SilkWorm交换机被赋予合适的网络地址，可以使用 Brocade的WebTools软件，以可视化方式进行管理和监控， WebTools是驻留在单个交换机中的基于Java的Web应用程序。这些交换机可以通过以太网以out-of-band方式访问，或者通过基于光纤通道的IP协议以in-band方式访问，后者是通过具有以太网连接的主交换机进行的。 
  
    Brocade的 WebTools的文档中介绍了运行该应用程序需要支持Java的浏览器；正式的系统需求是在 Windows平台上运行Internet Explorer，在Solaris平台上使用Netscape Navigator浏览器。此时Java的老问题再次出现：编译一次，调试多次。所以当一些 Java applets在SuSE Linux 9.0的Mozilla 上运行出现故障时，我们并不感到惊奇。幸运地是，虽然加载Java classes时速度较慢，我们可以在SuSE上使用Konqueror来运行。
  
    我们使用了Brocade的WebTools软件的性能检测功能，来演示一下ISL干线合并（ISL trunking）的效果。在 Dell服务器上我们安装了一个LUN，其是由连接不同的交换机上的初始控制器来提供服务的。当我们使用64KB I/O来运行oblFileLoad时，峰值传输速度为188MBps（8个硬盘阵列），当打开干线合并功能时，数据传输通过端口 6和7进行，这就形成了连接到nStor阵列的交换机的ISL干线合并，数据传输的平衡效果很好。
  
    WebTools 提供了直观的界面，来管理整个架构和配置单个交换机的属性，诸如IP地址，交换机名称，简单网络管理协议（Simple Network Management Protocol，简称SNMP）设置。使用WebTools，管理员可以识别出连接到架构中的设备，升级交换机的固件，管理授权序列号，以便使用可选功能。
  
    传统的SAN拓扑是每个交换机之间相互连接成网状结构，这样的安排可以使得在发送设备到目标设备之间传输数据时，在交换机之间的数据包的转跳数达到最小。 
  
    nStor的StorView可提供可一个直观的，易用的界面。所有系统组件中的重要状态信息可以容易地获得，同时进行详细的管理和配置也是小菜一碟。
  
    在SAN中配置ISL可以减少拆东墙补西墙的问题。系统管理员必须决定交换机中要保留多少用于数据连接的端口，以及多少端口用于连接其他交换机。这个决定定义了“注册比例”，即用于连接设备的总端口数同用于创建ISL所使用的总端口数之比。在一个8口交换机中，保留6个端口用于设备连接，2个端口用于ISL，其注册比例为3比1，这个数字被认为是性能良好的。
  
    不幸的是，对于SAN来说，规则并不是显而易见的。在两个交换机之间简单地连接一组端口，并不能自动地把产生一个高带宽的逻辑连接。 多数数据传输在端口到端口的流动过程中将不可避免地降低速度，形成瓶颈。为了防止这种现象的发生，Brocade交换机中提供了可实现特定的干线合并的固件，以便在相邻的端口集合中实现负载平衡，以便形成单一的逻辑干线。这个能够提供负载平衡的干线合并功能，并不便宜。本案例中，Brocade交换机添加了合并功能，价格就增加了$3,800美元，使得交换机总体上的开销达到 $10,000美元。 (编者：该测评是在今年三月进行的，反映的是当时的市场价。） 
  
    一旦我们的架构开始工作了，就可转向存储阵列的配置。nStor系统的建立过程可以独立于SAN，以传统方式进行：用一根串行电缆连接，运行VT100终端仿真程序。更为有趣的是，nStor的基于主机的客户／服务器软件StorView，可以运行在 Linux和Windows两种平台上。
  
    StorView服务器模块作为后台进程运行。其任务之一是在in-band (Fibre Channel)和out-of-band (LAN)连接方式下，使用multi-casting技术，来自动发现所有已经安装的nStor存储系统。为了同StorView GUI进行通信，服务器组件使用了Apache 2.0，我们把Apache 2.0安装在Windows服务器上。除非IIS正在监听端口 9292，否则Apache不会同现有的IIS发生冲突。结果是，管理员可在能够访问到nStor server的任何系统上运行StorViewde GUI。
  
    LUN映射是SAN管理员的重要工作，为简化这一工作， StorView为管理员提供了SAN中发现的每个HBA的唯一的WWN。为了识别WWN对应的物理服务器和HBA，管理员可以使用 Brocade的 WebTools软件。架构名称服务器列出连接到整个架构的任何交换机端口的每个initiator 的WWN（诸如Emulex LightPulse HBA)，以及每个目标设备 (诸如 nStor Wahoo控制器）的WWN。
  
    高端系统中需要的任何RAID管理功能都可以在 StorView找到。所有的高端RAID级别，包括RAID 10和 RAID 50（并不是所有的基于主机的控制器都支持）StorView也支持。诸如阵列，LUN和HBA这样的存储对象可赋予用户友好的名称。更为重要的是，对于数据快速增长的站点，可以使用任何可用的空余空间来扩展任何现有的LUN。
  
    使用光纤通道环路来连接硬盘，可以使得 nStor存储系统配置为多达64个阵列，每个阵列16个硬盘 。而且，硬盘的容量没有限制。然而，LUN的数量有限制：512。另外，32位的寻址极限限制了每个LUN的最大存储容量，为2,198GB。 
  
    SAN中的LUN管理存在一个缺点，如果没有干预，每个系统将会多次看见每个LUN－存储系统和架构之间的每次物理连接之后，就会看见一次。配置了双端口的nStor Wahoo控制器之后，nStor 4520系统上创建的每个LUN将会出现四次。在我们的SMB测试场景中，我们仅用了两个交换机，采用了优化的拓扑方法，即把每个控制器的一个端口连接到不同的交换机。 这样配置之后，一旦架构中有一个端口，控制器或者交换机出现故障，我们可以恢复。 
  
    但是，如果管理员使用的操作系统对SAN的支持不够好，SAN的这种出错恢复功能，就会引起严重的配置问题。Windows Server 2003和Linux都属此类。局部地，Windows Server 2003和Linux将会看到可以访问到任何LUN的所有映象。但是Windows Server 2003处理这些映象的方式不同于Linux。 一旦安装和格式化了其中的一个映象，在打算访问其他映象时，操作系统就产生一个系统错误。在Linux中不存在这个机制，系统管理员在理论上可以安装任何映象。实际上，这是个坏主意。 
  
    问题出现在用于硬盘卷的文件系统元数据的处理方式。例如：在Linux系统上，从IBM硬盘阵列中安装LUN的两个副本： /dev/sda1和/dev/sdc1，这两个安装点都没有反映出LUN内容的真正状态。两个安装点仅仅表明通过各自的安装点发生了两个事件。要同步得到一个安装点，且LUN中驻留的是实际的内容，唯一途径是卸装它，并手工运行 fsck，且调用 rebuild-tree 选项。自然地，系统的任何重启动将会失败，需要管理员进行干预，并运行fsck 命令，重建两个卷的inode结构。
  
    元数据的不一致问题，对系统之间共享LUN影响很大。虽然Windows Server 2003将阻止对同一个卷的多次安装，但没有机制可以阻止在不同的服务器上同时安装同一个卷。一旦发生这样的情况，结果是不寻常的。
  
    因为删除一个文件也就是把它从主文件表中 （MFT）去掉，在一台服务器的卷上被删除的文件，不会自动从另外一台服务器上删除。所有其他服务器将继续指向相应的硬盘块，且容易地找到该文件。此时， LUN的物理状态将变得不确定。当这个事情发生后，服务器的逻辑视图将同物理卷一致，这样的事态将一定会同其他服务器的视图之间出现混乱。
  
    I/O命令的大小表明了 Linux和Windows在进行I/O请求操作方面是不同的。在服务器上的Linux下运行oblDisk（其I/O命令几乎都绑定了 128KB的读写请求)，在Windows 服务器上我们重复了同样的I/O读写模式。Windows Server并不绑定 I/O，结果是为了优化性能，nStor硬盘系统在聚集I/O时，做了更多工作。
  
    在服务器上的Linux下运行oblDisk（其I/O命令几乎都绑定了 128KB的读写请求），在Windows 服务器上我们重复了同样的I/O读写模式。Windows Server并不绑定 I/O，结果是为了优化性能，nStor硬盘系统在聚集I/O时，做了更多工作。
  
    显然，无论是Windows还是 Linux都无法应付LUN共享中出现的复杂情况，所以两台服务器不安装同一个LUN是很重要的。要对付这个问题，最简略的方法是通过架构分区，即把switch 交换机端口组合起来，端口之间的通信限制为在组成员之间进行。只要端口连接不再重新配置，这个方案是相当好的。另一个复杂些的方案是利用基于HBA的独一无二的节点WWN，把LUN限制为同到特定的HBA对应。这正是nStor的LUN映射所采用的方案。
  
    结果是StorView GUI列出了SAN中发现的每个HBA的唯一的WWN，不幸的是，要让管理员能够准确地识别出哪个WWN对应哪一个HBA，这是不大可能的。幸运的是，这个问题可以很容易地通过 Brocade的WebTools来解决，WebTools含有一个简单的名称服务器。
  
    虽然nStor提供了一个功能强大的工具，来防止不同系统之间由于不合适的共享，而导致LUN的崩溃，但还是存在一个基本的失效切换的问题。失效切换的问题其逻辑上是本地LUN共享的一个实例。结果是，失效切换更多的是外在的而非透明的问题。
  
    Windows Server 2003处理该问题时措施很严格。有问题的卷从视图中消失，所有的通信被终止。只有通过从不同的路径进行通信，进行重启动方可恢复失效卷的一个新实例。
  
    另一方面，Linux允许多个安装点，这个功能看起来可以使得失效切换变得半透明。在破裂性的失效切换之后，Linux中的应用程序将一直运行。 例如，我们拔掉了硬盘的连接端口，之后我们打算运行一些应用程序。 除了两个例外之外，其他所有的应用程序都正常运行。这两个例外是：oblDisk基准测试程序，该程序显然是需要调用设备的，以及SuSE的YaST2硬盘分区工具，该程序一直不结束。这不是一个好现象。
  
    重启动系统时，Windows Server 所采取的严格方案有其合理之处， 要成功地重启动SuSE Linux，因为我们已经安装了该驱动器两次，所以必须手工干预，即重建该驱动器硬盘的目录树。
  
    从这些事实和数字来看，nStor系统并不受限于32位 WinTel架构。特别地，为了改进磁盘分段效率，nStor系统有一个最小的起始块尺寸：64KB， 这是Windows环境下的I/O的最大尺寸。该块尺寸可以设置为128KB，这是Linux环境下的最佳的I/O尺寸，尺寸最大可到256KB。 
  
    自然，这种多样性扩展了该存储系统的性能监控能力，这一点是很重要的，因为在调整硬盘阵列和服务器操作系统的I/O传输优化方面，需要这些信息。关于LUN的性能数据包括：读写传输率；I/O读写命令大小；读写字节调整；nStor阵列生成提前读请求的频率；阵列群写命令的频率。
  
    总的目标是在硬盘上避免写入块的分裂。理想的情形通过写命令，把数据块作为一个整体放置在每个硬盘中， 数据块的数目同组成整个条带的硬盘数目相等。这一点对于RAID-5 and RAID-50阵列的写性能尤其重要。
  
    我们将在InfoStor的下一篇文章中详细了解SAN的性能,因为我们将深入研究在SMB环境下构建SAN的性能和成本。
  
    实验室场景
  
    检查内容：2Gbps SAN架构
  
    测试内容：两只Brocade SilkWorm 3200交换机

• 8个 2Gbs端口 (SFP)


• ISL 端口干线合并


• 用于架构监控的WebTools软件


• 基于端口的SAN分区


• nStor 4520 存储系统


• 两个WahooXP RAID控制器

    1GB 缓存

    双 Fibre Channel端口 (SFP)

• 主动-主动配置


• RAID level 10 和50阵列


• 可扩展容量LUN

    nStor StorView管理软件

• 基于主机的HTML软件


• LAN 和in-band Fibre Channel IP连接


• 自动发现服务器的HBA


• 综合性能监控

    四个 Hitachi GST UltraStar硬盘

• FC-AL, 2Gbps


• 10,000 rpm


• 147GB

    四个 Seagate Cheetah硬盘

• FC-AL, 2Gbps


• 10,000 rpm


• 73GB

    两个Emulex LightPulse 9802 主机总线适配器（HBA ）

• 全双工2Gbps Fibre Channel


• 自动拓扑配置


• 自动速度协商


• 133/100/66MHz PCI-X和兼容PCI

    一个Emulex LightPulse 9002L 主机总线适配器（HBA ）

• 全双工 2Gbps Fibre Channel


• 兼容66/33MHz PCI

    测试方法：

•     SuSE Linux 9.0 Professional


•     Linux Kernel 2.4.21


•     Windows Server 2003


•  .NET Framework 1.1

    HP ProLiant ML350 G3 服务器

• 双2.4GHz Intel Xeon CPU


• 1GB PC2100 DDR内存


• 四个100MHz PCI-X扩展槽

    Appro 1224Xi 1U 服务器

• 双 2.4GHz Intel Xeon CPU


• 1GB PC2100 DDR 内存


• 133MHz PCI-X 扩展槽

    Dell PowerEdge 2400 服务器

• 800MHz Intel PIII CPU


• 512MB ECC registered SDRAM 内存


• 四个 66MHz PCI扩展槽

    基准测试软件

• oblLoad v2.0


• oblDisk v2.0


• oblFileLoad v.1.0

    重要发现：所有需要用到的驱动程序都包括在SuSE Linux和Windows Server 2003中。四硬盘阵列的传输速度可以同本地的Ultra360 SCSI性能媲美。Fibre Channel下的大阵列扩充性更好。SAN的失效切换在Windows Server 2003或者SuSE Linux中并不是一个透明的过程。

未经允许不得转载：DOIT » 存储解决方案：构建中小企业的SAN的几个方面