NetApp的技术日记

打扰的存在和职位的情况下。 这是过去一年过山车人身伤害和平了工作日程，所以我很少有时间或动机到博客或显示我的脸，周围的社区。 我向你道歉，我决心要打破这种习惯，并再次进入回事情！ 但足够的喋喋不休，著作...

这不是我常看的很，但是当我这样做，这是有趣的统计为自己说话。 我几年前了他们的NetApp房地产的脚本部署与客户，它没有过多的照顾或注意（我要讨论的另​​一天）设计或交付。 与SQL，Exchange和其他的事情，他们有一个VMware的房地产。 这一切都贯穿共有超过100 15K FC纱锭。 与其他网站相比，它不是一个巨大的房地产，所以我到他们为什么有这样的性能问题感兴趣。

现在，当您通过“SYSSTAT-U”运行，你可以看到，文件管理器本身做的很少，很乐意应该做些什么。 但磁盘往往达到100％。 立刻，这表明磁盘问题。 他们需要更多的纱锭，很明显吗？

首先是主轴不平衡。 他们有一个伙伴控制器，只有测试卷上的第二个总。 我得到的许可，以消除和热，我重新分配这些其他控制器和扩大现有的总和。 这双打主轴计数，但我知道它不会做任何现有的业绩（在该数据将不会自动重新分配本身！）。

如果我通过“：*：统计显示磁盘disk_busy”跑，我可以看到很明显的。 达到100％，在整个系统中，有一个单一的磁盘，其余的都没有。 还有一堆其他磁盘（约10），正在运行的50-60％，然后滴答作响在20-30％左右，其余的磁盘。 因此，这里发生了什么事情？ NetApp技术应防止任何形式的热系统中的主轴。

这是我的理论。 被折磨的文件管理器和堆叠的开箱，但总没有增长（3磁盘聚合，1数据2校验）。 一些存储配置和数据迁移。 他们跑出来的空间，因此增长的总和（少许），然后复制到磁盘一束更多的数据。 这一切后，他们再加入其余的磁盘。 现在，因为数据不会自动重新分配上的苍蝇，任何数据不变（VM系统磁盘，旧的Exchange电子邮件，和老数据仓库数据会发生），那么他们仍坐在原来的主轴，甚至作为他们第一次安装时的主轴。

所以我现在就盼着周末。 我们将它们升级至Data ONTAP 7.3.2，然后我就可以运行一些再分配，扫描，不影响整个系统的快照空间使用情况（巨额奖金，感谢你NetApp的！）。 我希望，这将消除热主轴问题。 我之前统计，我拉出后统计下周。 我会更新这个职位。

从这个故事的教训？ 设置存储系统完全，彻底，然后再开始扔在它的数据。 不要使用新的存储玩具兴奋，立即抛出数据。 我看过多次的上述情况，现在，和前ONTAP的7.3，它是一个痛苦的修复。

快速快照的统计输出。 请记住，在集群，这将显示所有磁盘，使所有磁盘的统计是完全相关的。 只是在这里忙碌的磁盘，不添加到实际系统中的磁盘数量，你可以清楚地看到一个忙碌的磁盘。

> SYSSTAT-U 1
CPU总净kb / s的磁盘kb / s的磁带kb / s的Cache缓存CP CP的磁盘
OPS /在输出读写，读写年龄命中时间TY UTIL
3220 6942 3270 4232 0 0 0 12 95％0％ - 60％11％
2898 7385 4030 4892 0 0 0 11 94％0％11％ - 69％
3547 1820 3496 3920 24 0 0 11 93％0％9％ - 89％
2329 1160 3048 3892 0 0 0 11 93％0％7％ - 81％
3173 2055 4851 4644 8 0 0 11 93％0％ - 67％10％
2491 1860 4547 4568 24 0 0 11 91％0％9％ - 98％
2523 2960 4404 5372 0 0 0 11 90％0％9％ - 89％
5136 8173 4465 3352 0 0 0 11 95％0％ - 81％​​14％

>统计显示盘：*：disk_busy
......喀嚓......

......喀嚓......

一般 的磁盘性能 ， 分散 ， 热锭 ， NetApp的 再分配 ， 统计资料显示