存储架构

存储架构

相关问题:在构建存储区域网络时,存储管理员通常根据 I/O 类型(顺序访问与随机访问)创建物理磁盘阵列,并将这些阵列中的 LUN 配置给需要该特定类型 I/O 的主机吗?

答案1

我尝试将预期的 I/O 需求与架构相匹配。对于我所做的几乎所有事情,SAN 方法如果你投入足够多的磁盘,总 I/Ops 可以超过所有工作负载,但专业工作负载除外最终效果很好。如果我有 96 个主轴在使用,那么我所拥有的总 I/Ops 足以保证 SQL 服务器日志文件的传输,即使 Exchange 服务器也在同一个磁盘上运行。

理论(I/O 分离是最佳实践)与现实的冲突在于这些大型 SAN 阵列的设计方式。虽然顺序的四个 15K RPM 磁盘的 I/Ops 相当高,许多此类阵列故意随机化块布局,因此即使您创建专门用于一个 SQL 日志卷的 4 磁盘磁盘组,您也无法获得这种性能。它们可能会遇到一些顺序优势,因为块大小通常大于磁盘本身使用的 4K,但它不会像纯顺序加载那样令人尖叫。

如果我建造投入的数据库的存储。这假设这项服务的 I/O 需求非常大,或者 I/O SLA 足够严格,因此必须提供性能保证。在这种情况下,我实际上会为 Log、TempDb 和 DB 卷等创建离散磁盘组。这种设计并不常见,实际上非常罕见。

答案2

视情况而定™。对于标准的低使用率虚拟机,我通常会将大多数虚拟机放在几个 RAID 6 上,让缓存和分层处理突发情况。对于像 Exchange DB 服务器或 SQL Server 这样的高负载服务器,它们通常具有专为其需求而设计的专用 LUN。

但这确实取决于您的存储架构。

答案3

我很想对此说“是”,因为这会让我看起来非常专业,但老实说,99% 的时间我都会购买我需要的任何类型的阵列(目前正在经历 3Par 阶段,但这些年来我已经经历了大多数阶段)并购买尽可能多的架子,然后用数量和速度合适的磁盘填充它们,然后创建符合 RAID 级别和性能要求的 LUN - 虽然我通常不考虑性能是随机的还是顺序的。我倾向于假设除了备份之外的所有内容都是随机 IO,因此基于此做出假设,至少这样,如果我确实获得了一些缓存或顺序优势,那么这只是“意外收获”。我知道这听起来有点懒,但我照看了很多阵列,除非您有一组非常固定的要求,否则在加载阵列时总是需要一些“回旋余地”,否则您永远不可能第一次就做对。

话虽如此,对于本地 DAS,我确实倾向于更加具体,因为它更难改变,但我通常不会使用太多。

答案4

不会,因为 SAN 上的大多数卷都会有多种类型的 IO。如果您可以预测环境中的某个部分(例如数据库服务器 80% 是随机读取,或者备份服务器 90% 是顺序写入),那么在以下情况下将其分离可能会对您有益:(a) 没有宽条带化,并且仍在将卷放在特定 RAID 上,(b) 控制器已经过时,您可以使用 RAID-10 获得相当可观的性能。

编辑:点击后,出于多种原因,将数据库日志和数据分开是一个好主意,而不仅仅是 RAID 类型。即使您使用相同的 RAID 类型,您也希望将它们分开,以便控制器可以为每个卷使用不同的缓存优化算法。

如果您有池,将这些工作负载分离到自己的磁盘池中所带来的好处通常不值得付出性能成本。除了少数例外,最佳做法是将所有操作系统类型的所有卷放入包含所有资源的单个大型池中。

相关内容