Chinaunix首页 | 论坛 | 博客
  • 博客访问: 11589845
  • 博文数量: 8065
  • 博客积分: 10002
  • 博客等级: 中将
  • 技术积分: 96708
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-16 17:06
文章分类

全部博文(8065)

文章存档

2008年(8065)

分类: 服务器与存储

2008-07-23 11:02:50

自从SAN(存储区域网络)诞生以来,客户总是抱怨存储区域网络难于管理。除了互用性的问题之外,缺乏健全的SAN管理手段是阻碍IT市场广泛采用SAN的重要原因。尽管在互用性的前沿已经取得了进展,但SAN管理方面,人们付出了许多努力,但却僵滞不前。存储网络行业协会(Storage Networking Industry Association,SNIA)的《存储管理倡导》(Storage Management Initiative,SMI)是第一个行业性的并由多家厂商参与的联合行动,旨在为实现多重传输和应用之间的存储管理奠定坚实的基础。

  除了推动公共信息模型(Common Information Model,CIM)架构发展之外,SMI将促成软件厂商和硬件厂商按照共同的标准开发SAN管理解龇桨福?纱颂峁└?康幕ビ眯圆⒓蚧?突У墓芾砉ぷ鳌H欢?琒MI不是万能药,并不能完全解决SAN的实施和支持中的所有问题。这里并不是说有很多SAN管理上的问题亟须解决,而是说SAN的覆盖范围太大、太复杂,不能包含在一个单一的管理构架内。

  把存储设备和网络整合成为一个存储区域网络(SAN),实现了很多新的功能,大大超过了其各个组成部分的功能之和。例如,传统网络管理的重点在于数据源和目标之间的数据传输。地址分发、设备设置、带宽分配、路由协议、传输监控和为容量规划服务的历史报告(historical reporting for capacity planning)等功能可以整合到某个网络管理应用中,以确保可通过网络架构进行正常的数据传输。传统的存储管理重点可能在于通过LUN分配、RAID级别、存储利用和备份安排来实现存储资源分配。


  SAN管理新增的复杂性

  实施SAN解决方案,将存储设备接入网络,使得所有的这些管理需求都得到整合,同时,还引入了一些由于存储设备和网络结合而产生的新特性:设备发现、分区、LUN映射、 可选路径和失效容忍(alternate pathing and failover)、集中式备份、第三方副本、HBA(主机总线适配器)和结构管理以及SAN内的存储资源虚拟化带来的新的管理任务,这在直附存储解决方案中是不存在的。尽管这些SAN的特有功能向客户提供了用于管理存储数据的强有力的工具套件,但是它们也使存储管理工作变得更为复杂。

  人们相信,对SAN的管理是基于大量功能的,如果SAN要正常运作,这些功能必须能够协同工作。每一种设备都应该按其特定的要求进行设置。每一个HBA设备提供商、交换机生产商、存储阵列生产商或磁带设备生产商都各自提供他们自己的设备管理工具(至少在初始化设置的时候必须调用一次)。LUN必须创建,端口必须激活,参数必须设置。一旦每个组件都能正常运作,你就必须对组件间的关系进行定义。

  你必须给特定的存储LUN指定HBA,同时,给交换机的端口或附连设备划分区域,还必须为故障或负载均衡设置交换机互连链接。高可用性的解决方案还要求有额外的管理手段,以确保:冗余链接能够正常工作;集群软件已正确设置;磁盘对磁盘的数据复制需求得到满足。考虑到冗余的目的,管理、快照(snapshot)、备份计划和分级别的磁盘对磁盘或对磁带应用均各自需要手动的设置和监控。一些辅助功能,比如存储资源利用率清单、安全策略和容量规划(capacity planning)也可以执行。

  位于这些存SAN管理工具顶层的存储虚拟软件必须将SAN及其管理底层的复杂性隐藏起来,但是在今天的SAN产品中,进行虚拟设置比非虚拟的存储管理方式,需要付出更多的手工劳动。在过去的几年中,管理软件提供商一直在努力将这些各不相同的功能整合成为一个单一的平台,可是只取得了局部的成功。


  一揽子解决方案短期内无望推出

  目前,存储产业正努力为SAN管理定义一种共同的标准,这将有利于创建可协同工作的管理框架,但是,不会立即推出那种能对SAN进行全方位管理的一揽子解决方案。客户仍不得不操作SAN管理中分别针对特定功能而设计的多重实例。比如备份目前一般来说是通过没有直接整合到SAN传输管理框架的独立应用来执行的。多重应用意味着需要多个管理员、多个用于管理的工作站,独立的培训和技术以及独立的效果和支持成本,此外,还常常需要用以设置并监控SAN的独立管理访问方式。制定公共的管理标准后,这些需求依旧存在,但它们却是迈向SAN管理整合的重要一步。

  此外,经过简化并更有效率的SAN管理方式是符合将管理对SAN架构自身的影响降到最低程度的原则的。举个例子,在一个复杂的SAN中,存储磁盘阵列、磁带子系统、SAN交换机和主机总线适配器可能会被多个管理应用同时搜索,同时,每个管理应用都试图为界定狭窄的管理任务发出对小部分信息的访问请求。对于终端设备和存储网络来说,这是一种不经济的做法。

  尽管每个厂商都迫切给其产品追加价值,并努力拓展其管理应用软件的功能,逐步超越对硬件设备的即时设置和监控的范畴,但对这种情况来说,不会有任何的帮助。比如,一家SAN交换机生产商可能会提供用于交换机设置的工具包,其中还包含能够绘制SAN及其附连设备完整关系图的工具。同样地,存储阵列生产商可能会提供有助于RAID和LUNs管理的工具包,此外,也许还会提供涉及SAN管理其他方面的工具。

  这样做会使得其他管理应用的工作翻倍增长,经常会导致对存储资源过多的搜索,而实际上却不能给客户带来多大的效益。尽管通过这种做法可能会获取大批量的原始管理数据点,但是这些数据没有关联,无法形成SAN及其不同功能的综合视图。对于客户来说,监视和控制一个单一的SAN居然要用到5个或6个管理应用,无疑是一件令人气恼的事情。


  将SAN管理整合到操作系统的解决方案

  将事务处理置于无序状态的解决方案不像是存储厂商和管理应用提供商为了分割SAN管理区域而达成的绅士协定。由于SAN管理对于客户来说有巨大的意义,因此,每家厂商都出于本能地在这个领域展开竞争。目前,前期开始生产增值精密存储阵列的厂商已在从事可以监控并管理其他厂商SAN产品的SAN管理软件的销售。毕竟,软件的利润要大大高于硬件,而且不管底层的硬件怎么变化,软件的利润率都是保持不变的。共同的管理标准实际上将会加剧这个领域的竞争,这是因为标准化使得厂商可以把重心放在增值的功能以及更大的市场差异之上。

  最终要实现的综合的SAN管理解决方案很有可能不是来源于传统的SAN提供商本身,而是来自操作系统和应用程序(当初,正是操作系统和应用促成了SAN的发展)。举个例子,微软公司正在把API(应用程序接口)引入到其Windows Server 2003操作系统中,在操作系统的支持下,它能够实现用于存储目标路径失效后的可选路径、快照备份和存储虚拟池,同时还支持IP SAN环境下的iSCSI和iSNS设备发现。

  如果将过去独立的SAN管理应用集成进操作系统,这对竞争厂商是不利的,但是客户将会最终从削减的成本和统一的软件界面中受益。尽管这是一种容易激发人们提出反托拉斯倡议的作法,但这种在SAN管理市场内解决方案正经历着一种自然选择的过程,打个比方,在今天,对打印机的共享和管理,没有人会作出太多地思索,这是因为这些功能目前已被无缝整合到操作系统中去了,在底层硬件架构以及软件应用之间搭起了一座桥梁。


  结论

  SANs固有的复杂性需要人们在管理框架上进行更多的研究,以使目前需要手工介入的整个管理过程变得简单而富有效率。尽管将来SAN不太可能实现自我设置和自我管理,但是随着SAN感知功能(SAN-aware functionality)与操作系统的整合以及不同厂商工具包之间的重复功能减少,客户能够更加轻松地部署并支持富有成效的SAN环境,而无需面临今天SAN管理所遇到的难点。

阅读(246) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~