如何按网络规模划分服务器等级

按网络规模划分，服务器分为工作组级服务器、部门级服务器、企业级服务器。

工作组级服务器

用于联网计算机在几十台左右或者对处理速度和系统可靠性要求不高的小型网络，其硬件配置相对比较低，可靠性不是很高。

部门级服务器

用于联网计算机在百台左右、对处理速度和系统可靠性中等的中型网络，其硬件配置相对较高，其可靠性居于中等水平。

企业级服务器

用于联网计算机在数百台以上、对处理速度和数据安全要求最高的大型网络，硬件配置最高，系统可靠性要求最高。

需要注意的是，这三种服务器之间的界限并不是绝对的，而是比较模糊的，比如工作组级服务器和部门级服务器的区别就不是太明显，有的干脆统称为“工作组/部门级”服务器。

一般情况下，我们可能想测试一下服务器上的文件（用户上传的或者后台写入的）是否可以被外网访问到，以进一步测试文件下载等功能。

我原本想尝试从服务器的任意目录访问文件，但是经过数次的尝试，网上教的通过修改Tomcat路径映射和自定义XML来进行文件映射都不能成功访问到目标文件。

最后查到，把文件放在Tomcat的ROOT目录下，就可以用服务器域名+“/”+“文件名（带后缀）”直接访问到文件，亲测成功，。

满足功能需求只是对一个软件基本的要求，作为一个好的软件必须关注一系列的非功能的要求，比如容易部署，界面友好，可以扩展，性能优良，等等。

一些软件框架以不同的维度提出了自己的非功能需求列表，供评估和提出需求时参考，自己也在开发过程中针对服务端软件，按照软件生命周期过程中参与服务端软件不同操作的不同人员，以及这些人员对系统的关注点不同，拟出了一个服务端软件的非功能需求指标框架，可以用于提出指标，也可以用于进行软件评估。

第一层的划分是来自于询问自己的一个问题：软件生命周期中，都有谁会关注这个软件，他和软件有什么操作，他关注软件的哪些部分？从这个问题出发，可以得到软件生命周期中有以下相关方：

软件本身的正常和异常运行

    开发人员 ：软件本身的设计和实现中的要求

    运维人员 ：操作/监测/部署升级 这三类运维人员在履行自己职责时对软件的要求

    安全人员 ：从安全角度出发对系统各个方面的要求

    用户人员 ：软件的不同用户对软件界面和接口的要求

    机房/审计人员： 对软件的效能进行审计和控制

这样基本保证了指标的完整性，也许还有其他的点，后续继续补充了。

　　很多企业在进行服务器租用时总是想着租用一台高档服务器，独享多大的带宽，费用越高越好，而不根据企业网站的需求来选择合适的空间以及带宽，这种方式既增加了用户的资金投入有浪费了资源。因此，企业在进行服务器租用业务时应考虑以下几点因素：

　　第一、根据企业需求选择合适的应用服务

　　企业在建设网站或是开展电子商务时，可以根据自己的实际应用需求，来企业决定购买自己的服务器品牌和配置标准。确定服务需要的硬件和软件的配置以前企业在准备服务器托管时，总是先想好购买一台高档服务器，然后希望租用多大的带宽而不是从自己的实际需求出发来选择服务器和IDC服务商，但这样的方式既浪费资源又增加了用户的资金投入，因此，企业建站是应根据网站需求考虑是共享服务器带宽还是独享服务器带宽独享多少M带宽等。

　　如果做数据库查询服务，那么内存一定要大些;如果网站的访问量很大，就需要采用负载均衡技术;如果数据量很大，那么数据备份和意外事故的数据恢复技术一定要强。总体来说，企业选择服务器时，一定要从自己的应用需求出发来选择品牌和服务器的配置，能满足自己的需求就是最好。

　　第二、服务器专用性明显

　　目前，通用服务器将在转变专用服务器，以电子邮件服务为例，以前只需要在任何一台服务上装上一套电子邮件软件即可以提供电子邮件服务，不管它的稳定性能如何和处理邮件的能力如何，只要能用就可以。但事实远不如想象的那么简单，对电子邮件的服务与对Web服务是不同的，稳定性和服务器的响应速度非常重要。所以，需要有专用服务器来提供服务。未来企业邮局服务器的发展趋势应该是易用性和专用性，服务器的选择和配置都应该相对简单，不需要有太高的技术门槛，并且专用性的发展趋势会非常的明显

　　第三、软件与硬件互补性强，综合考虑选择标准

　　客户在选择服务器时应该从软件与硬件两方面来考虑。如果要运行大量应用软件，则需要大的内存;如果需要负载大访问量，就需要考虑较大的内存。硬件与软件的配合良好才能发挥服务器的良好性能，仅仅追求服务器的硬件高档化，如果没有软件的配合，也无法保证最终服务的高性能和稳定性。因此，在选择服务器时应该从两方面综合考虑，以综合指标来选择服务器。

　　第四、服务器租用稳定性和扩展性最为重要

　　选择服务器租用时要考虑兼容性和稳定性。托管服务器后，随着客户访问量和服务变化，服务器需要不断地增加硬件资源，以达到提高服务水平和服务能力，所以服务器一定要有很强的可扩展性，为客户提供可扩展的空间。

评估机柜服务器的功耗是数据中心设计师的最大挑战，没有绝对的答案，也没有简单的解决方案。

在设计服务器总功耗时，千瓦每机柜的方案远比瓦特每平方英尺来的有用，但这个方法还没有经过多年的验证。想得到良好的评估，不仅需要采用好方法，还取决于你对现有的运作以及可能的增长趋势有何种程度了解。

创建有代表性的设备分组作为容量单位，但不需要太精细。大型、独立而牢不可破的系统可能由单个容量单位组成，但在10,000平方英尺的数据中心里，普通

机柜容纳8到12个容量单位应该十分充裕。不需要为每个机柜开发单独的容量单位，因为IT设备也不可能完全按照理想设计来安装。意义在于开发切合实际、满

足通用需求的，可以推广到整个空间的设计方案。

不要高估能量消耗。IT设备铭牌编号上的备注毫无用处，它们可能导致离谱的高估。如果可能，就采用硬件制造商在线配置方案的结果。最终手段，采用服务器供应商电源额定功率值——一个300瓦电源的服务器绝对不可能达到800瓦的功耗。根据实际需求负载来判断供电系统符合。

双路设备为IT设备增加了硬件冗余，也共享了电力负载。如果一个双路服务器有两个300瓦电源，在能耗设计里，它依旧不会超出300瓦，因为每个电源都需要能够承载服务器的满负荷状态能耗(不包括电源效率计算)。

估算服务器功耗的另一种方法是采用行业标准。除非有承载高性能计算，大概可以判断分为三级密度：低密度机柜运行在35至5千瓦;中密度运行在5到10千

瓦;高密度运行在10至15千瓦。每个机架类型分配量级取决于你的运营策略。一般来说，数据中心承载着大约50%的低密度机柜，35%的中等密度机柜以及

15%的高密度机柜。

当你采用这些方法后，需要做个全面检查，将现有的不间断电源供电总量除以现有的机柜数，得到一个平均值。然后将你计划部署的机柜数与总估算的部署服务器用电负荷总数相除。要记得，很少服务器部署能够真正接近设计师的初始估计负载最大值。

如果你的预测值大于实际平均值15倍，就需要进一步查看这些数字了。如果你预期密度将显著增加，那么这样的预测没有问题，比如新业务需求或者增加虚拟化引入刀片服务器等。但如果没有理由来证明密度增长的预测，重新审视设计吧。

首先看类型，如果是官方网站，一般同时在线的人数不多，可以选择1核2G1m就可以了

如果是做小程序商城，这就要看同时在线的人数是多少了，常规选择2核4G5m或者4核8G5m，如果您还不会，我可以给你指导性的选择意见。

Windows服务器中自带的性能监控工具叫做Performance Monitor；

在开始-运行中输入‘perfmon’，然后回车即可运行。

Monitor本身也是一个进程，运行起来也要占用一定的系统资源。所以你看到的资源的使用量应该比实际的要稍微高一点。这个工具在帮助管理员判断系统性能瓶颈时非常有用；

举个列子来说，今天有个用户抱怨说他们项目组的服务器（这是一台虚拟机）运行起来非常慢，但也不知道具体问题出在什么地方。任务管理器里显示CPU和内存的使用量都不算高，但服务器的相应就是非常慢；

Monitor，让其运行一段时间后（因为参考平均值会比较准确），发现average disk queue的值比较高，这就说明物理服务器的硬盘负荷太重，I/O操作的速度跟不上系统的要求。关掉虚拟机，将其转移到另一台硬盘负载比较小的主机上，再打开虚拟机。

分析性能情况

1、内存泄露判断

虚拟内存字节数（VirtualBytes）应该远大于工作集字节数（Workingset），如果两者变化规律相反，比如说工作集增长较快，虚拟内存增长较少，则可能说明出现了内存泄露的情况。

对于Workingset、Private Bytes、Available bytes这些计数器，如果在测试期间内数值持续增长，而且测试停止后位置在高水平，则也说明存在内存泄露。

Windows资源监控中，如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Available

bytes计数器的值持续降低，则很可能存在内存泄漏。

2、CPU使用情况

一般平均不要超过70%，最大不要超过90%（好：70% 、坏：85%、 很差：90%）。

3、tps（每秒处理事务的数量，在SOAPUI中进行统计）

一般在10-100，不同应用程序具体值不同。

　　如果只有两个Guest OS,以规格来看，瓶颈应不会在CPU性能上，反而是硬盘I/O跟网络速度的性能比较有可能，而内存数量及使用规划也要注意。另外如果是无法长期停机的机器，需要评估备份或后备规划，以及后备系统版权授权规定及费用。

　　关键瓶颈是磁盘I/O,并非CPU。需要跟进的事情是﹕

　　1 在旧主机上面，先监测出跑报表所需要的IOPS有多少？并精算VM硬盘。

　　2 如果文档复制会占用主机所有的IOPS,这种工作不适合跟其他VM共享磁盘。

　　所以，如果要拆开，主因并不是CPU不够用（跑报表跟文档复制，根本用不到多少CPU资源），而是磁盘的I/O资源会被文档复制全部占用，造成其他的VM排队等候。

　　在虚拟化软件的选择上，如果是VMware ESX（i），可以透过vSphere Client或vCenter新增Resource pool,来设定Guest OS的CPU资源。

　　可以测试一下：报表跑数据大量择取的时候，使用“Windows工作管理员/处理程序”查看CPU与内存以及I/O的状态。

　　虽然将它们放在同一台主机，但是文档服务给它一个完全独立的磁盘子系统，不跟其他VM共用，那这样就不会有以上的顾虑，还是可以放在一起。

　　例如，你可以买一台SAN给文档服务的VM专用，但另买一台SAN给其他的VM共用，最后，数据库的问题还是要回到IOPS上来。我遇过80%以上想做虚拟化的新手，都不知道原本旧主机上数据库的瓶颈是在Disk I/O。一般说来，跑ERP报表吃掉1,000~3,000 IOPS是很常见的状况，这代表RAID至少要5到15颗以上来组合，才足够应付这样的IOPS。

　　根据以往的经验，在看到这个数据之前，用户都一直认为瓶颈是CPU,所以要换新主机来提升CPU,但看过监测数据之后才知道，其实瓶颈都在IOPS。

　　补充一下，一般状况下，一颗SATA硬盘的IOPS只有70到80左右，一颗15K SAS硬盘的IOPS,大约200到240左右。组成RAID多颗硬盘时，IOPS会跟着你的硬盘数量而增加，例如使用96颗硬盘组成RAID-5的一台Dell MD3200i,实测数据上，IOPS可以高达40,000。