服务器选型：怎样的一款服务器产品才算是优秀的

对于一款服务器产品而言，我们可以从三个角度去评估它——质量、功能和服务。

质量是产品可用的第一要素，这里主要是指硬件的故障率，这个数值应当低于2%，一些厂商的硬件质量甚至可以做到小于1%。不要小看这个数字的变化，对于海量模式的硬件平台，基数越大差距效果就越明显。假设服务器总量是三万台，多出一个1%就意味着平均每天会多触发一次故障事件。即便是更换硬盘的维修，也会对生产系统的运行产生一定影响。故障率如果控制不住的话，那么SLA的承诺就是一纸空谈。

同时质量也直指另外一个重要指标，那就是性能。在这里，我们把产品性能也纳入到质量里面去。为什么这样讲呢？如果一个产品的性能很差，意味着它的可用性就很差，一个不可用的产品，从概念上讲基本就等同于质量不合格。一个性能极差的产品基本上就是不可用的，对生产业务的正常运行是非常不利的。

功能是另外一个很重要的影响因素。如果说质量关系到业务的正常运行，那么功能就关系到业务的高效维护。一般所谓的功能主要是指服务器的带外管理功能。因为在硬件配置方面，除了RAID卡和电源以外，能够相互一较高下的地方并不太多。但是服务器的带外管理功能确实可以有效地拉大不同产品之间的距离。

质量和功能是在我们的技术评估中是占有很大比重的，而服务部分会相对偏轻一些。服务好不如质量好，手册好不如产品好。如果一款产品，质量可靠有保障，使用简单不求人，那么谁还会需要售后服务和说明书呢？如果产品的质量跟不上去，功能又有缺陷，那么服务再好也是没有意义的。相反的，如果产品功能强大且质量过关，我们反而很少会使用到售后服务。

在海量模式下的运维场景中，甲方都有自己专门的运维团队。当触发任何紧急事件时，第一时间都需要运维团队自己解决。我们不可能像过去传统的系统集成那样，把所有工作交付给厂商来完成。这涉及到一个时间成本的问题。一个线上系统发生故障了，难道你要我打800开Case，再等着厂商派工程师出现场吗？这显然是不可能的。业务就算停止一分钟的损失都难以估计，你根本就等不起。只有像硬件维修或是技术咨询这类不紧急的问题，我们才会依靠厂商来支持。

另外，服务是一个长期积累的过程。一个厂商的服务好与坏，在短期内是很难做出评判的。对于那些以前根本就没有使用过的产品，服务这一项也仅能通过测试阶段的售前表现来看。这也是不能把服务占比过重的一个客观因素。

带外管理有多重要

做系统运维的同学会经常提到带内管理与带外管理这两个名词。所谓的“内”、“外”之分，就是指管理通讯链路和业务生产通讯链路之间的关系。如果我们使用业务所在的链路进行消息传递和管理，我们就称之为带内（In Band），反之就是我们所讲的带外（Out of Band）。

我们日常维护生产环境，主要是通过带内网络进行管理。所依靠的手段，无非就是RDP、VNC、SSH、TELNET这些方式。但是，这些服务都运行在操作系统上面，并且通过网络远程访问，其中就存在很多不稳定的因素。比如硬件故障，操作系统崩溃，或者是人为操作失误导致系统无法访问等等。由此看来，带内管理这条通道是很脆弱的。我们需要使用另外一个备用的手段，来确保我们对设备和操作系统的控制权。

带外管理是完全独立于现有生产环境的，从硬件接口、网络链路，再到存储和操作系统都是单独分离出来的。带外管理系统存放在一个很小的控制芯片上面ie浏览器老是停止工作，里面是一个经过修剪的、只读的最小系统环境，通过单独的接口与网络去访问。所以它的可靠性比带内管理网络要高得多。只要控制芯片加电且带外的网络正常，我们就可以始终把控制权牢牢地掌握在手中。

当带内管理网络崩溃时，我们依旧可以凭借带外管理提供的虚拟控制台，远程登录生产系统的本地console界面，这相当于在机房里面直接接上KVM（Keyboard-Video-Mouse）设备。是我们处理故障最有效的保障手段。除了断后之外，带外管理也扮演着开路先锋的角色。在设备刚刚上架加电的时候，我们是没有带内环境的，系统的安装部署，服务器的开关启停都离不开带外管理。

也许在一些人看来，带外管理不过是提供了一个远程的虚拟控制台而已。但实际上，它所能完成的任务远远不止这些。优秀的带外管理可以说是提供了所有你在本地操作面前能做的一切功能，甚至还有额外的增值项目。我们可以借此获取详尽的硬件清单配置列表，收集监控数据信息，设置BIOS参数，甚至操控硬件。

异构平台融合能力

从管理角度讲，单一使用一家厂商的产品，对于资产的统一管理与配置是有利的。如果出货量大，双方相互之间还可以签署框架协议，进一步推动价格成本控制和产品定制化。这对于平台初期的快速建设是有一定帮助的。不过，当平台规模从溪流模式发展到江河模式或者海量模式的时候，一些政策法规不允许只此一家的这种采购形式的存在，同时单一化产品也存在品牌绑架的风险。这个时期，就会突然涌现出许多不同品牌，它们都有可能在未来同时入驻到我们的服务体系当中去。由于来自不同产品之间的差异会带来多样化管理的难题，这就对服务器的异构平台融合能力提出了严苛的要求。我们不希望看到，因为产品差异化而增加运维的管理成本。因此，必须弱化这种差异效应，让运维团队的成员感受不到不同产品之间的切换与变化。

支持并使用标准的公有开放式协议是异构融合的关键。私有协议不管做的多好，对于一统天下是没有任何帮助的。除非你没有竞争对手，或者你的私有协议能成为公认的标准。

IPMI协议尽管发展使用了将近20年的时间，可以方便地为用户提供电源控制、传感器监控等通用型功能，但是它已经是一个落后于时代的产物了。作为x86平台的工程师，我们一直都很羡慕小型机上面有专门获取硬件信息的命令。而IPMI对于这方面需求的发展一直是难有作为。事实上，一些厂商像Dell、联想在IPMI上也有oem接口，但是IPMI所能作的工作实在是太有限了，我们需要一个新的方案来解决异构平台上的管理难题。

WS-Management，全称叫做Web Services-Management，是DMTF组织基于SOAP(Simple Object Access Protocal，简单对象访问协议)制定的一种开源标准。该标准致力于在不同的x86设备厂商当中，提供一种IT基础架构信息访问与修改的统一接口。这对于那些支持该标准的厂商来说，会给用户有效地管理资产配置工作提供极大的帮助。例如，我们有很多来自不同厂商的服务器设备。如果它们都能够很好地支持WS-Management标准的话，那么就可以通过wsmancli工具，统一采集或修改所有服务器的硬件配置信息，而不必因为私有化工具分治的问题而形成多头管理的局面。像AMD、Dell、Intel、Microsoft这些知名厂商都是该项标准组的成员。

这里我们就目前已经实际应用了WS-Management协议的DELL服务器为例，如果我们需要获取网卡的MAC地址的话，可以使用如下命令实现。

使用WS-Management，必须先在客户端上面安装名为wsmancli软件包。DELL在这方面走得还是非常靠前的，官网上不但给出了wsman的使用实例，同时还在git上面提供了一整套范例脚本。具体内容请读者自行参考如下链接。

3）范例脚本下载地址和说明：

q

q

q

q

除了WS-Management以外，类似的标准还有Redfish，最新版本是2.0。它是一个通过RESTful接口利用JSON数据来实现的集成解决方案。Redfish的是一个更加轻量级的协议。比起WS-Management来，它同样借助了HTTP模式，但传输数据更少，协议层更加简单，Redfish所能够支持的成员也更多。国内一些厂家已经在推动Redfish项目的进程了。具体的详细内容可以参考如下链接：。

另外一点就是兼容性。兼容性的优势将使产品在未来异构融合的竞争中处于有利的位置。我们可以回顾一下历史，看一看WinZip为什么会输给了WinRAR。当年WinZip是压缩软件界的老大哥，而WinRAR只是初出茅庐的毛头小子而已。不过，WinRAR在推广自己压缩率更高的rar格式的同时，也兼容了zip格式。而WinZip却不愿意把rar格式纳入到自己的帐下，也许WinZip觉得这样做实在是丢不起那个人。这两种策略最终形成了两种完全不同的结果。尽管后来各式各样的压缩软件如雨后春笋般的出现，但都无法撼动WinRAR霸主的地位。原因就在于WinRAR能够谨记WinZip失败的教训，不断地兼容后来者的各项功能，稳固了自己的江山。

我们就拿虚拟控制台举例，绝大多数服务器的虚拟控制台依旧是通过Java程序来实现的。而HP提供的C/S模式的工作效率显然要比Java高很多，并为本地登录提供了冗余手段。按理说，HP能做到这一步，在众多厂商里面已经算是很领先的了。但是DELL的思维模式却显得更加前卫，它把VNC服务直接嵌入到带外管理模块中，在本地登录的时候使用VNC Viewer就可以了，而不是像HP那样要安装一个私有化的客户端。使用开放标准的VNC协议的优势就在于没有开发成本，而且它的通用性和可行性都很强，在未来异构平台融合的大背景下具有很大的竞争优势。在写这本书的时候，我已经在和华为、联想、浪潮的销售与技术团队的技术交流中ie浏览器老是停止工作，建议厂商尝试在带外管理中嵌入VNC服务。这也许将在未来形成一种趋势，我个人希望借助宣讲和推动，为业界产品的异构融合迈出坚实的第一步。

完善的信息数据展示

信息展示分为静态和动态两个部分，静态信息是指硬件清单的配置信息，动态信息是指部件状态的实时监测数据。

硬件清单的配置信息用于资产管理和安装部署之用，采购的机型不止一种，所以需要通过硬件清单列表的详细内容对服务器进行辨识，同时也有助于我们检查供货设备硬件配置的准确性。硬件配置清单列表中应当尽可能地包括如表1所示的内容信息。

表1 Business-IP的对应关系表

Items

Detail

CPU

Vendor, Type, Frequency, Amount

Memory

Vendor, Type, Size, Amount

RAID

Vendor, Type, RAID info

PD

Vendor, Type, Size, SN, Amount

LD

Pool info, Size

NIC

Vendor, Type, Port, MAC, Amount

Power

Power, Amount

OOB

MAC, Firmware

Server

Vendor, Type, SN, Service Tag, BIOS

部件状态的实时监测数据分为两种。第一种是硬件的健康状态，表明它是好的还是坏的。第二种是温度、电压、电流、风扇转速、能耗等传感器的实时读数。

软硬件环境兼容性

软硬件环境的兼容性的优劣，决定了一款产品应对使用场景的灵活性和适用性。如果适用性太差，就很难去推广到大规模、多样化的应用场景里去。

1. 浏览器兼容性

基于B/S架构的图形化管理是带外管理最早的表现形式。说到B/S架构，我们就不得不提到浏览器这个话题。近年来，Chrome和Firefox确实比较流行，但是我希望更多情况下，产品对于IE浏览器的兼容性还是要多考虑一些。毕竟IE是Windows原生的，而很多工作我们还是要基于Windows平台来实现的。

2. JRE兼容性

绝大部分产品都是基于Java开发的，所以JRE是远程虚拟控制台和一些私有化管理工具必不可少的运行支持环境。然而不幸的是，因为厂家众多，产品的生命周期也不尽相同。一些产品只能运行在老版本的JRE上面，而另一些产品则必须使用最新版本的JRE。一个平台下同时使用多套JRE环境是很麻烦的。一个兼容性差的产品就像一个不合群的人一样，会受到别人排挤的。我们对待产品也是一样，少数要服从多数，新来的要入乡随俗，只有那些能够向下兼容的产品才会被留下来。

3. 协议兼容性

比较常用的协议有FTP、LDAP、HTTP、HTTPS、NTP、SMTP、SNMP、SSH、rsyslog等，而且类似SNMP、SSH等还有多个不同版本。对于产品所支持的协议的种类与版本，肯定是越多越好。

4. 硬件及驱动程序兼容性

这个问题主要体现在和部署系统的配合上面。例如因为硬件特殊或是驱动程序的问题，使得部署系统无法识别，从而导致安装失败。这种问题严格来讲，不能全都赖在厂商这边。但是用户作为甲方，是有一定话语权的。能够解决问题是最好不过了，但如果解决不了，或者解决成本太高，有可能用户会因此令你出局。

用户体验

产品生产出来就是给人用的，评价一件产品的优劣往往是很主观的，这就是我们常说的用户体验。对于产品研发来说，良好的用户体验是至关重要的。如果你把产品当成一个人，当你和这个人接触过一段时间之后，他或多或少地都会给你留下一个印象，那么你对这个人的评价就来源于你对他的印象。当然，这个评价可能好的，也可能差的，就是所谓的用户体验。一个获得好评的人，双方以后相互往来的可能性就会增加，反之人们就会疏远他。同样的，如果一个产品的用户体验很差劲，那么用户最终的感受就是——“我再也不想见到你了”。

用户体验是在用户使用产品的过程中建立起来的感受。但是对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好的设计来实现的。产品设计的中心原则就是以用户为中心、以人为本。

1. 响应时间

鲁迅先生说过：“生命是以时间为单位的，浪费别人的时间等于谋财害命；浪费自己的时间，等于慢性自杀。”不错的，我想这世界上没有比等待更令人烦躁的事情了。如果点击一个页面之后，等了半天没有反应，实在是很令人沮丧。在毫无提示的情况下，等待会让人不知所措。尤其是在我们急于得到结果的时候，这种慢吞吞的节奏令人感到非常的不合拍。

2. 用户界面

我们不得不承认这是一个看脸的时代，“颜值”在产品里面也显得十分重要。

我认为DELL的导航菜单做得最为出色。它的界面完全符合web页面的浏览习惯，隐藏类细节信息都会以加号展开的方式展现。操作方式也十分便捷，只需要点击两次鼠标，就完成大多数的操作与信息展示。DELL的所有操作和信息展示都是在同一个页面下完成的，而不会给你弹出一堆pop窗口，也不会利用超链接给你跳转到另一个页面去，如图1所示。

图1 DELL服务器的带外管理界面

H3C也很有特点，从管理界面和菜单结构上，还是可以看到很多HP的影子的。不过相比HP，我认为H3C还是有一些自己的特色在里面的。比如说Overview这个总览页面的右下角，汇集了很多常用的功能，点击对应的快捷方式可以方便的跳转到相应的功能当中去。如图2所示。

本来对于超链接，我还是不太推荐的。因为很多产品在设计的时候，乱用超链接。看上去很方便，实则不停地跳转页面，像goto语句一样把用户搞得晕头转向。而H3C的这个超链接设计却是可行的。它把所有常用功能都放到了一起，相当是一个门户页面的结构，还有类似Dash Board的关键数据展示。这个设计思路还是很用心的。

图2 H3C服务器的带外管理界面

3. 产品逻辑

产品设计的优先级顺序应该是：逻辑性>稳定性>性能>功能。

产品的逻辑性非常重要，一个产品的使用逻辑有问题，往往就带来极其糟糕的用户体验。使用一个逻辑混乱，结构模糊的产品，对用户就是一种折磨。

在这里，我举两个例子。

第一个例子是我们在调试一款产品的功能时发现的。我们要求服务器厂商提供的产品，在系统配置上必须有图形和命令行两套接口。图形主要适用于调试使用，而命令行则有利于我们日常的批量设置。我在配置一个新的参数时，发现在命令行里找不到这个参数，而且文档里面也没有提及。之所以我找不到，是因为图形界面里面菜单的组织形式和命令行中树形的组织形式不完全一样。这样一来，我没法根据图形界面的菜单去定位它在命令行树形结构中的位置。最后我不得不采取了一个笨办法，把根目录下的所有属性都列了出来，再通过过滤关键字的方式来搜索答案。

第二个例子是在一次测试过程中遇到的。我个人负责产品测试，另外一个同事负责安装部署测试。有一款产品，我先对它做了功能评估的测试，然后转给同事去测试安装部署。过了一会，同事转过头跟我说，这个产品不行，好多硬件信息根本看不到。我笑着告诉他，其实信息是有的，只是它们因为害羞躲起来了。那些硬件信息的细节全部都被隐藏起来了，而且隐藏得太好了，导致我的同事根本没有发现。因为它们的打开方式并不统一，窗口、标签和链接，可以说是各式各样。如果不仔细看的话，就会给人造成信息缺失的假象。

关于产品的逻辑问题还有很多，但我想原因只有一个，归根到底是设计人员从来不用自己设计的产品造成的。