彭毅：优化性能，提高利用率——SSD助力搜狐服务器应用

2014年7月31日，由DOIT传媒和存储在线举办的首届中国闪存峰会在亮马河饭店盛大召开，来自搜狐研究院基础架构部的彭毅为我们分享了《优化性能，提高利用率——SSD助力搜狐服务器应用》，与大家共同探讨搜狐在服务器应用中把SSD引入到基础架构中所带来的收益。

以下是演讲文字实录：

大家好，我是来自搜狐研究院基础架构部的彭毅，很高兴跟大家探讨一下搜狐在服务器应用中把SSD引入到搜狐的基础架构中给搜狐带来的收益。

搜狐公司旗下有很多的业务，包括搜狐的门户业务，还有搜狐独立的上市子公司，专门做游戏领域的畅游，以及搜狐视频，搜狐焦点，还有我们经常做一些搜索使用的搜狗，搜索引擎，及搜狗地图，还有大家耳熟能详的搜狗输入法等。在这些业务中，当然搜狐还有很多其他的一些业务。

在这些主要的业务中，各个业务部门的技术人员与搜狐基础架构的技术人员在经常探讨业务与基础架构的有机整合。在业务对性能需求的同时，基础架构会针对业务的需求给他们提供各种各样的解决方案，在其中，搜狐在使用SSD的业务是在2008年的8月份左右。首先是在搜狗的搜索引擎其中的一个索引的这么一个模块出现了一个非常强的一个I/O的瓶颈。在这个时候我们为这个业务寻找解决方案的时候，我们看到了SSD给我们带来的一些益处。

当时我们部署SSD的动力，发现在搜狐的业务中，有很多像数据库业务，像其他的一些比如说搜索引擎，还有一些视频业务，在解决I/O的时候往往都是在传统方式下使用多硬盘解决I/O的性能问题。但是，随着传统硬盘的发展，我们发现一个很大的问题，就是硬盘的容量增长远远大于它的性能增长。传统磁盘靠转速和吞吐量解决性能问题，但是容量增长远远大于转速。当搜狐使用1500转的传统硬盘时，不仅仅是在功耗上、在制冷上，在大量引入1500转的春秋硬盘对机房产生的功耗及散热也给我们的基础架构带来非常大的挑战。我们需要有一种技术手段，或者一种新兴技术帮助我们解决我们遇到的问题。

在搜狐对SSD进行研究的过程中，我们发现SSD性能上已经完完全全满足了我们业务上遇到的一些问题。但是，最关键的问题主要是成本与容量比值的问题，也就是说，我们互联网公司经常讲的性价比的问题。就是我们解决一个性能问题的同时，它所付出的成本是什么样的。

在搜狐部署SSD的应用过程中，我们也有很多对能耗的考虑。因为像互联网公司它的服务器规模非常大，一般互联网公司在几万台服务器的规模，在大量的数据中心服务器运转的时候要消耗大量的电能，传统磁盘是机械格式的硬盘，在工作当中要消耗大量的电力。我们部署SSD的时候同时也能减少我们服务器对能耗的消耗，对我们数据中心的减耗也带来了一个非常明显的变化。而且还有在一个比较突出的情况是什么呢?就是比如我们有一些，像08年奥运会的时候北京有很多地区对电力的需求是突增的，包括有一些数据中心有大量的用户在互联网进行访问，当时搜狐是2008奥运会互联网的赞助商，当时有很多用户访问我们公司的服务器，对整个机房能耗的增长是非常大的。

那么，在这个时候因为电力属于这个机电设施，它不能很快的顺应我们的需求，它有一定的滞后性。那么，在这个时候，我们就利用SSD代替传统磁盘，减少I/O消耗的同时对电力的增加。从2008年的下半年开始，在搜狐的各个业务线上我们开始寻找有可能启用SSD的一些业务，寻找这些业务的同时，我们首先有我们的部门对传统的磁盘和SSD进行了一些相应的研究和一些报告的制作。当时我们针对普通磁盘的转速，内部传输速率，包括接口方式等等一些相关的传统磁盘的指标的评定点与SSD进行了一些相关的对比。在这一块，我们得到就是说，传统磁盘的容量非常大，但是成本非常低，而且这种磁盘是非常成熟的，而SSD性能非常高，功耗也是极低的，而且存储结构非常简单，减少了很多机械结构。但是，SSD也有一定的问题，就是单盘的容量在2008年那个时候还是非常低，和传统磁盘的容量比还是有非常大的差异。我们当时启用的最大容量是160G的SSD，而且对SSD使用的性能相关指标的时候都有一个写入寿命的非常强烈的一个指标，在这一块也是我们当时启用SSD的时候考虑的一个关键的点，我们在可能启用的SSD的业务上进行了三年的预算，就是对业务线目前的I/O的写入量进行了三年的估算。当我们的估算值不低于这个写入寿命的时候，我们在业务上推荐使用SSD。

因为传统磁盘我们知道一旦出现一些灾难的情况下，当然传统磁盘可以有很好的保护，比如说备份手段，可以很好的解决数据的安全问题。但是，在SSD的年代，SSD的盘还非常贵，我们引入Rade技术相应不是很现实。然后我们看到这个传统磁盘的时候，对它进行数据恢复的时候，它相应的数据恢复技术是非常成功的。但是，电存储，尤其SSD这种电存储技术，当数据盘，尤其Flash这种颗粒级损坏的时候我们数据是非常难以恢复的，所以这一块也是对我们在寻找可使用SSD这个业务时候对我们提出了比较大的挑战。我们就找了一些搜狐内部首先是允许有一些数据丢失的业务，就是它从架构上已经解决了数据丢失之后，它的数据可以从架构上进行重构。

当时我们选用SSD的时候也看到很多的固态硬盘它带有缓存，就是写入的时候有一个低RAM缓存。但是，所有带有低RAM缓存的SSD产品都需要已有电容给它供电，保证突然断电的时候数据不会丢失，这也是我们选择SSD盘的时候给我们带来的一些比较大的挑战。

目前在搜狐的SSD硬盘的使用中主要带来两个场景的应用，一个是把相对大容量的固态硬盘作为我们数据盘存储真实的数据，然后它我们的收益主要有大幅度提高了I/O性能，节省了很多的功耗，提高了处理器的利用率。在一台服务器中，因为现在CPU的速度越来越快，我们知道计算机系统遵循木桶原理，所有它的性能取决于最短的板，SSD的引入对我们服务器的处理器的利用率提高了很多。

目前这种大容量的固态硬盘作为数据盘主要应用在像搜索、地图，包括视频，还有一些数据库应用中，他们作为我们的数据盘来存储。在这一块，我们数据库这一块的引入相对来说比较晚，搜狐在数据库应用中是在2009年下半年，接近年末的时候才开始尝试使用固态硬盘，因为像数据库业务是相对来说比较核心的业务，它对数据的安全是非常在意的。数据库的DBI他们更愿意用传统成熟的技术有效的解决数据安全问题。在这一块，他们会采取传统的技术手段，然后比如一些相关的手段，用大型的盘阵系统，提高整个系统的I/O水平。但是，从2009年开始，我们不断和他们进行沟通，跟他们说大家可以尝试一下这个SSD这个固态硬盘，他们会给你们提供大量的收益，而且在这一块也不会造成非常突发的数据的损坏。

所以，在2009年的时候我们数据库开始尝试在一些备库上开始使用SSD固态硬盘，在正式的产品库上，实际上最早应用是在2010年的上半年，在搜狗的输入法，在索引库上，输入法的词库上成功的使用了固态硬盘。因为这个业务它的特点是和固态硬盘的标准的应用领域有些差异，我们在寻找固态硬盘作为我们内部应用点的时候，我们会着重找业务的情况是什么呢?它要大量的读写，而没有很大量的数据写入的情况下来进行选取，而输入法的词库它正好和我们之前选取的这个点有一个相反的地方，就是它有大量的数据写入，每天都有大量的数据写入，而读取和写入的比大概是一个5：5的比例。所以，在这一块，是我们也做了一些技术处理，后面我们会讲到这个应用的场景。

另外的一种应用就是我们选取了相对容量较小的SSD，我们当时宣传40G的SSD作为我们的系统盘。当时是我们给一个业务线在寻找解决一个盘类的情况下，大概也是在2009年的下半年的时候，存储服务器那个时候突然就兴起了在国内，所有的IT公司基本上都在研究存储服务器的应用空间。这个时候搜狐也在选择和考虑使用这种存储服务器作为我们大量的数据存放的点。但是这个时候我们传统的服务器基本上那个时候的磁盘还在146G，SAS 10K的146G，300G这个容量，因为搜狐根据它的传统的做法会找出一块单独的盘进行OS的部署，然后其他的磁盘来存数据。当存储服务器上来的时候，它的磁盘都是以T级为单位。这个时候我们如果要是由一块磁盘装SSD对我们来说空间的浪费非常大，这时候我们有几种办法，要么改变传统的运维的相关工具，重新制定一套运维的标准及进行一些运维工具的二次开发，重新改变我们之前的运维习惯。或者我们进行一种特殊的手段，然后进行数据存储。

后来我们和ODM一块儿进行了一些研究，我们成功在一个存储服务器内部安装了一个40G的SSD，然后通过性能的连接，然后进行了一些改造，然后把这个盘成功引入进去，然后直接在主办的蓝桥上把这块盘识别起来，装上SSD，这样给我们带来的收益非常大。以前一台存储服务器，按照原来标准使用只能使用一块盘，只有11T的空间，现在我们又得到更多的盘位，现在这块服务器就变成了12块数据盘。后来这个案例进行了一些宣传，后来看到很多做存储服务器的厂商都陆陆续续推出了“12+2”的规格，就是12块大盘加2块小盘的规格。而且最开始我们作为系统盘仅仅想给我们节省出一个盘位来，后来把SSD引入到系统盘这个应用场景中，我们发现还有其他很多收益。因为互联网公司服务器的上线基本上成批量，一次上线几百台，几千台，数据的输送对互联网公司来说是比较痛苦的过程。SSD作为系统盘之后，我们发现在OS的部署这一块对我们来说很轻松，以前基本上30分钟左右才能部署完一台服务器，现在十几分钟就可以部署完，在这个场景下，也给我们节省了大量的时间成本，这一块对我们收益也是非常大的。而且因为我们的使用基本上都是Linux的系统，在那个年代内存还不是很大，基本上16G，32G就已经算非常豪华的配置了。在那个时候有很多的应用，在调用大量内存的时候，它没有更多的可靠空间的时候，它就会在磁盘上开一个smart区域，把暂时不用的数据写到Smart空间。在这个场景下，不仅仅是给我们解决了服务器的存储容量的问题，而且还给我们得到了系统的性能的提升。

目前SSD作为一个系统盘基本上已经成为搜狐的一个标配了，在这一块我们基本上所有的非特定业务的服务器都会有一块到两块SSD作为OS盘。目前，我们现在看到的SSD的容量越来越大，成本也越来越低，我们选用的一个小容量的SSD目前也已经停产了。这一块我们这个部门还在做一些更深的研究，我们现在在利用技术把笔记本的一些SSD再引入到服务器中来，通过这些技术降低我们在服务器应用中的成本。

现在和大家分享一下搜狐在SSD的选用场景应用还有一些我们在使用SSD中的一些特殊的技术相关的一些东西。我这个部门是基础架构部门，它负责搜狐硬件的一些评测相关的东西，还有一些基础架构的应用场景的研究工作。在SSD这块评测中，我们通过之前对SSD的了解及技术的跟踪，我们发现对影响SSD这块的主要性能，第一部分就是主控芯片，主控芯片有很多家，英特尔等。第二个影响它的速度就是NAND Flash芯片，还有就是缓存，还有比如它采用的是几路并发，什么接口，这些也会影响。但从我们评测的过程中得到的数据分析，这三部分是影响一个SSD它的最关键的三个要素，所以在这一块，我们在做SSD测试的时候，我们不仅仅是在进行一个跑分的测试，还要对固态硬盘进行一些排解，要看到你的主控芯片是什么等级，NAND Flash芯片是什么等级，缓存是什么样的。我们认为这些技术可能相对来说对企业级的应用场景，尤其像数据库的应用可能不太适合，我们就会选择其他的进行缓冲技术处理的SSD。

在SSD选用的应用场景下，我们基本上着重在两点选用。第一点就是具有非常高的IO瓶颈的这样一个应用。首先这样的应用有非常强烈的使用SSD，就是更快能解决IO瓶颈的这些设备跟技术的强烈的愿景。然后，我们会选取大量的以读为主的业务，而且它的读，绝大部分读操作是随机的读取，而不是顺序的读取。在这一块我们选择业务的时候，尤其是搜狐初期使用SSD，那个时候相对来说还比较新，很多业务使用传统磁盘他们觉得可以满足自己的需求，但是IO也是他们一个比较突出的问题。然后有新技术突然出现的时候，有新的设备，他们觉得这个东西还比较早，不成熟，然后他们在应用的时候也会有一些担心，我们开始就按这两点去寻找一些内部应用的场景。但是，这一块随着我们的实践，我们还是得到了非常大的收益，目前现在各个业务线基本上已经对固态硬盘有了非常大的认识，然后他们一旦在服务器应用中遇到了IO瓶颈的问题，但是首先肯定会想到SSD。

然后，SSD的写入寿命是一个最大的应用的难题。在这一块，我们开始对写入寿命这一块还没有特别大的在意，我们只是在场景中，在上线之前我们会进行一个特定的时间点的场景的计算，在一定时期看这个业务线会不会把这个磁盘的写入容量写满，一到写满的时候，会有一些性能的问题。在这一块的时候，我们刚才提到的那个输入法的词库，在这一块我们遇到一个非常大的挑战。这个业务它有非常明显的IO瓶颈问题，而且它的读写几乎全是随机的。在这一块，我们和业务线带一块儿进行沟通的时候，进行了一些预计算，给我们得出的结论非常恐怖。基本上它的场景的写入量，基本上一块SSD一年就会让他们写报废，这一块对于我们来说是不可接受的，一旦数据写入过来之后，而且服务器都是批量上线，如果一批SSD，或者一个集群同时出现这个问题，对用户的影响是非常大的。那么，这一块我们和SSD的技术人员进行了深入沟通，然后我们发现在超量控制技术这一块可以有效的解决我们的问题。当时我们是在这个业务线上进行了一些测算之后，然后我们选取了一个160G的SSD，我们利用超量供给技术，将一块160G的SSD改成120G上线。

当时我们是考虑到三年的场景，虽然容量上对我们有一些损失，我们只使用了3/4的容量，但是这个时候，从目前看，这批的词库，目前所使用的这批，从160G修改到120G的SSD目前还在使用，已经基本上将近四年多的时间，快到五年了。亲戚我们还没有进行大量的SSD的监控，后期我们考虑到SSD有可能，因为很多业务线的集群基本上都是批量上的，这一块我们为了防止突发的故障，我们在2013年的年底搜狐内部启动了一个新的项目叫SMART项目，它不仅仅能监控所有的底层的硬件服务器的各种应用状态，而且着重对搜狐内部所有的SSD进行寿命预期，就是通过这个SMART这个信息对SSD寿命及业务的写入量读取量的一个分析，然后进行了一个场景的综合的一个计算之后，它会对每台机器上的SSD进行一个生命预言，这个生命预言就是你从使用到现在已经使用了多长时间，那么，预计你的这个业务在同样的IO写入下还能继续写入多少天，做了这样一个功能，给使用SSD的部门进行一个有效的对它购买新的SSD，然后进行一些业务迁移，给它一个很好的指导。

通过SMART监控SSD这个技术，每个SSD厂商的SMART监控值所能提供的信息量也是不一样的。像有些好一些的，它会在所有的SMART关键的技术上会罗列的非常清楚。但是，我们从前期的IT测试中，我们通过标准的SMART工具读取出来的每家所能提供的详细点是差异非常大的。在这一块，由于搜狐和英特尔一直保持着非常良好的关系。然后在这一块，我们在底层监控这一块得到英特尔工程师大量的技术支持，他们给了我们很多的指导，所以才有我们后来SMART对SSD寿命预言的这么一个功能。

我们在应用SSD这个时候，我们会对很多场景，SSD这个写入进行一些预期分析。其实这个预期分析我们在做所有的场景启用之前，我们只能是对当前这个点，或者说它最繁忙的这个点进行一个预期上面的预算。但是，在我们这套系统上了之后，我们会发现很多业务它的写入和读取，它的分布是非常奇特的，和它的业务非常有相关性。比如说我们的游戏业务，它的写入情况和Web的服务所写入的分布是非常不一样的。Web的业务分布基本上在下午两点到六点是写入量频繁的时间，然后有一个空缺的时间，然后在游戏的时间基本上从十点到夜里两点的时候是写入最频繁的时刻。这个时刻，虽然SSD我们能预言他的时间点是这样，但是它每天平均的写入量又是不一样的。在这一块，我们后来采用了某一应用的一个特定场景的一个段之间的预算，我们在某一个场景下，我们选取它一个月，最长到三个月的写入的统计，然后根据它的业务写入的特性，然后进行了一些分析，然后就更准确的能针对我们的场景进行一些挑选。

目前现在在搜狐有大量的数据库的机器，数据库现在我们采用了传统盘式的SSD，而且因为现在虚拟化技术都比较普及，我们在搜狐的很多的数据库应用下也启用了虚拟化技术。但是，虚拟化现在目前看到最大的一个问题是，因为CPU是非常快的，内存的容量添加现在也是非常大。那么，就是IO这个问题是最大的问题。数据库业务它的IO其实是非常的敏感，它的IO的瓶颈是非常大的。那么，我们在这个数据库业务启用虚拟化之后，确实因为数据库业务我们能看到有大量的CPU的空闲，也有内存的空闲，网络的空闲，就是IO非常满。我们针对这个数据库的业务这个场景我们进行了一个设计，我们对一台服务器，对它添加八块SSD，八块传统的盘式的SSD，对服务器进行虚拟化，我们在搜狐很多数据库进行了这样的改造，目前这种应用基本上对我们读写分离的数据库场景都采用了，这是对我们应用比较大的一个改变。因为互联网公司在之前提出的一些技术方向就是分布式，然后小型化这样的一个过程。那么，这样对我们来说没有很多大型的像EMC，Oracle他们提供了很多的更大型的，更安全的数据存储系统，也有更快的存储系统，但是对互联网的技术来说，可能利用那样的技术，或者那样的系统，可能在快速变更这一块，在运营过程中会给我们带来更大的挑战，所以互联网公司基本采取小型分布式的结构。在数据库的应用中，SSD的应用模型对我们来说也是非常巨大的，这个场景基本上是在去年把它变成数据库标准的一个应用。

还有一个就是SSD的电气特性，就是说，我们在改造之前提到的那个硬盘存储服务器的这一块。我们发现很多的传统的服务器具有热插拔功能的传统服务器，它的背板在设置上有很多设置都是为传统磁盘设计的，而没有考虑SSD的这个引入。虽然SSD盘现在在接口形式上或者在数据存储过程中，它在尽量的模拟传统硬盘，但是它毕竟是一个电存储设备，它不是一个机械存储设备。在这一块，我们有一批高性能服务器想添加SSD的时候遇到一个非常大的问题就是背板的问题，这一块后来我们也是采取办法，因为服务器的厂商不给我们支持，他们认为他们服务器设计之初就没有设想用户会使用其他的非磁盘性的存储。后来因为场景的IO出现了非常严重的问题，我们又不得不上，后来我们又通过一些特殊的装置，我们做了一个转化托架，因为我们很多服务器都是有一个笔记本是光驱类的，我们做了一个托架，包括供电的问题，实际上在服务器中，添加非设计的盘类的存储空间的时候，它的供电是一个非常大的挑战。我们后来经过一些测算之后，我们通过服务器内制的USB口进行取电，来给SSD供电。

还有一个问题就是安置，春秋的服务器它基本上设计完成之后四个盘就是四个盘位，我们想添加额外的盘位不是很现实，我们就需要在内部空间上寻找可能性，去添加SSD。那么，在内部添加SSD的时候要考虑的因素就非常多，因为添加了设备，而破坏了原设计者对服务器内部风道的设计，而对散热产生更多的影响，这个时候我们也会针对不同的服务器进行一些特殊的设置。

还有就是连接的问题，就是所有的数据线与主办的连接问题，服务器内部和PC不太一样，它对内部散热有非常强烈的要求，而且有很多的硬盘，然后风扇也是非常多的在内部。服务器内部它的振动远远大于我们平时接触的PC机和笔记本。所以在连接的一块，数据线的连接简简单单插在上面是不行的，我们需要有特殊的办法进行连接加固，进行一些稳定性的东西。后来我们在这一块基本上会采用定制某一种内置到2.5的转接盒，另外就是带不影响风道设计的地方把它固定下来，我们用热熔胶，或者其他方式固定好，用这种方式来解决。我的分享就到这儿，谢谢大家!