磁盘系统

许多客户会问如何选择磁盘驱动之类的问题，典型问题从是否应该使用SSD到如何以及在哪里使用RAID等等不一而足。我们也经常发现，客户花了钱买错了系统，不能够实现预期使用目的，要么花了很多的钱，要么钱花不到点子上。一位客户对自己的服务器展开了讨论，我们受到了启发，所以想借助该博客，阐述一下我们对于磁盘系统原理知识的观点。

首先，经常有人问我们一些关于SSD的问题，问是否需要使用SSD，而实际情况是，很少有应用程序确实需要使用SSD。SSD不但价格昂贵，也很难得到合理的使用。SSD确实很好，但是前提是您的负载是否的确很高？您能否合理地加以选择、配置并对其进行管理？他们并非您所想的那样，在很多方面速度很快。此外，很难对其进行校准，这一点无人不知，着实令人头疼。而且可靠性也不是很好，所以对于储存关键数据，您需要使用RAID1和一个很好的控制器。

当今时代，使用常规磁盘，当然是速度越快越好。如果可以，我们会尽可能选用15k SAS，其空间限制为600GB，但是若您需要使用900GB的磁盘，您得采用10k的SAS。此外，若我们必须要用SATA，我们就会使用戴尔的Near-Line SAS，其实就是一个SATA磁盘驱动配置了一个SAS接口，通过该接口可实现许多功能包括快速及更好地进行有标记的排序。随着技术的发展，如果选用3.5”的磁盘，我们可使单个磁盘空间最大达到3TB。我们通常采用上述两种磁盘，取长补短，例如，数据库用两个600GB SAS 15k；其它的程序则采用2个3TB Near-Line SAS (SATA)。（如果是小型系统，则采用2个300GB 和2个1TB）

RAID控制器和写缓存是选择常规磁盘时要考虑的重中之重。在戴尔系统上，我们使用不同的中型PERC控制器，效果很好；尽管每几个月要检查电池学习循环无异于自杀，但是至少不必在R x20的服务器上采用最新的PERC 710；找到一个好控制器、对其进行合理配置并关闭磁盘缓存！

对于数据库而言，系统中的许多清理设置是很重要的，因为他们在平衡系统性能及扩展性和维护数据稳定性方面起到重要作用。对于MySQL的这种平衡，我们了如指掌，但是，Postgres也有一些类似的控制器，通常对通过fsync（）将日志写入磁盘的频率进行控制。默认情况下，我们希望在每次事务处理结束后，对其进行清理，但是若事务率很高的话，这样做就很消耗资源而且每秒要清理100多个事务，所以得采用控制器 – 对于每个事务(db log, binlog, XA sync)而言，InnoDB 需要3个fsync() head movements。

对于性能要求很高的系统，就必须将数据和日志分开管理，将小日志放置到SSD或者某个独立的磁盘，而数据则存储到大磁盘。这在Oracle和其它系统中很常见，但是要在MySQL上实现却很困难，尤其是如果您需要进行快照式的备份，就是您必须同步快照备份InnoDB日志和所有的表空间的时候，要想对日志和数据进行分离式存储确实很难实现。

可以考虑使用更好的文件系统，但是ext3 有许多问题，性能不是很好，如果用在Amazon中，由于LVM带有激活的快照功能、删除速度很慢而且InnoDB要对每个节点信息进行锁定，所以分配速度很慢，性能会更差，问题会更多。如果系统是Centos 6 或者是基于Debian的话，可以使用ex4，但是ex4 不能用在Centos 5上。无论如何，对于数据库系统而言，XFS仍然是一种文件系统选择方案，因为它速度快、可靠性好、有良好的口碑。

如果要解决硬件问题，我们通常使用Hot-Swap，因为它便于维护而且能很快地替代掉故障磁盘。出于存储空间的考虑，我们通常选用3.5"的磁盘，但是也在考虑使用2.5"的磁盘，因为它的总体存储空间可以更大，而且使用灵活，有利于后续扩展。

现今，有许多好磁盘、好控制器可供选择，而且我们能够对其进行很好的配置、监控和管理，所以，要建立高性能的磁盘系统是轻而易举的。我们随时待命，助您一臂之力。

（Authored by Steve Mushero / ChinaNetCloud CEO & CTO  本博客英文原文请）