Internet SCSI (iSCSI) 是相对较新的技术,使您能够以对操作系统无缝的方式远程地存储数据。下面是用于优化 iSCSI 存储解决方案中的可靠性和性能的最佳做法。
网络附加存储是新增的、Exchange 2003 支持的存储体系结构。但是,对于 Exchange 2003 组织,建议在采用网络附加存储解决方案的基础上再实现存储区域网络 (SAN) 解决方案。如果决定实现网络附加存储,请务必先熟悉一下本指南前面的“多种体系结构通用的最佳做法”中介绍的常规最佳做法。
在较小型的 Exchange 部署中,直接附加存储 (DAS) 是常见情形。大多数适用于 DAS 的最佳做法在其他情形下也是适用的,因此在本指南前面的“多种体系结构通用的最佳做法”中已进行了讨论。对于 DAS,唯一增加的最佳做法是为所有存储组件和电源实现冗余,这是为了防止可能会出现的单点故障。
除了实现适用于所有存储体系结构的最佳做法,还应熟悉每种类型的存储体系结构所特有的优点、缺点以及最佳做法。表 8 列出了这些体系结构类型以及每种类型的优缺点。
计算每个邮箱 IOPS 值并了解 I/O 要求之后,应使用该信息来优化存储体系结构。不管您正在使用的是直接附加存储 (DAS)、存储区域网络 (SAN)、网络附加存储还是 Internet SCSI (iSCSI) 存储体系结构,都有几个可以实现的最佳做法。
如果已经部署 Exchange,则应使用现有的生产环境来确定 I/O 要求。监视生产环境的好处是,您的数据可以包括所有应用程序(包括第三方应用程序)上发生的所有 I/O。
如果没有安装 Exchange,但想规划一下由于 Exchange 部署而产生的即将到来的存储需要,则可以使用已经收集到的数据。该数据采用邮箱配置文件的形式,邮箱配置文件描述了 Exchange 邮箱的常规使用模式。
既然了解了哪些 Exchange 活动和组件会生成磁盘 I/O 以及如何配置存储来支持它们,那么,您必须为您的用户计算磁盘 I/O 要求。计算磁盘 I/O 要求最终将允许您优化磁盘子系统,以便为用户提供最佳支持。
熟悉生成磁盘 I/O 的 Exchange 活动之后,就应该以能够发挥最佳性能的方式组织存储系统。表 5 列出了放置每个数据文件的最佳做法。
除了数据库文件访问,还有一些其他活动会导致磁盘 I/O。表 4 列出了这些活动和它们对磁盘 I/O 的影响。
每次从 Exchange 读取数据或将数据写入 Exchange 时,都将生成磁盘 I/O。了解 Exchange 磁盘 I/O 的来源,可以帮助您在规划和配置磁盘子系统时采用性能最佳的方式。考虑 Exchange 磁盘 I/O 来源时,请主要集中于访问日志文件和数据库文件期间所生成的 I/O 行为。
在性能有限的C P U上执行指令的进程被称为处理器受限而受到I / O执行速度限制的进程称为I / O受限。虽然处理器受限的进程不一定是I / O问题,但任何来自那个进程的I / O都将被延迟。从这个意义上说,处理器延迟影响I / O性能。
带有多于三个P C I插槽的系统可能有多P C I总线,这些总线通过P C I桥加入系统。当计算多总线系统的吞吐量时,要注意:不要把所有总线的累积总量当作系统性能。例如,一个拥有三条总线的系统,其性能决不会变成三倍。图5 - 2 6显示的系统由控制器2连接了两条总线,它们经由控制器1再连接到系统内存总线。
虽然关于系统性能泛泛的推测对一个特别的实现并不准确,但却给了系统设计者一个合理的希望值,帮助他们预言将来实现的系统性能。根据自1 9 8 3年以来的P C系统发展历史,可以推测系统I / O总线的性能最大值约为C P U吞吐量的5 %。
从历史上看,在对I / O性能做概括时,总是离不开处理器的类型和速度。例如,对于基于4 8 6的系统,其I / O性能限制在4 5 M B / s,而对于基于P e n t i u m的系统,其阵发传输的理论值接近于1 3 2 M B / s。虽然影响系统性能的因素很多,但计算机工业力求提供平衡的系统也是事实。
举一个例子,假如包括所有处理器操作和I / O操作在内,一个进程在当前的系统上运行需要花费1 0秒钟。详细分析这个进程的执行情况,结果是5秒钟花费在处理器的操作上,5秒钟花费在I / O操作上。换言之,处理器和I / O操作是错开进行的,它们之间没有重叠。
系统性能分析是一个极端宽泛和复杂的问题,涉及系统中的每一个组件,其中最重要的是那些属于存储和I / O技术类的组件。本节将在系统整体性能的大背景下,着重考察这些组件。