搭建Win2008故障转移群集、如何搭建服务器集群、2008故障转移群集搭建方法

IT168 技术故障转移群集可以配置使用多种不同的配置。组成群集的服务器可以是活跃状态或不活跃状态，而不同服务器可以被配置为在活跃服务器故障后立刻接管相应的资源。一般故障转移的过程只需要几分钟的时间，至于时间的长短主要取决于群集的配置和具体应用，当节点处于活跃状态时，该节点上可以使用所有资源。

当服务器故障后，在这台服务器上配置了故障转移群集的资源组就会被其他服务器所接管。当故障服务器重新上线后，群集服务可以配置为允许让原服务器进行故障回复，或者是让当前服务器继续处理新的客户端请求。本文章将讲述基于Windows Server 2008 R2的故障转移群集实现。

安装故障转移群集：

下面就开始在两个节点上安装群集服务。在此以server1为例，安装方法是：打开服务器管理器图标----添加功能，从中选择故障转移群集。

当两个节点安装完群集服务后，我们需要运行群集配置验证程序，来检查节点服务器、网络和存储设备是否符合群集要求。

仅当完整配置(服务器、网络和存储)可以通过验证配置向导中的所有测试时，微软才支持故障转移群集解决方式，另外，解决方案中的所有硬件组件均必须标记为certified for windows server 2008 R2。

方法是在server1或者是server2上进入故障转移群集管理器，单击验证配置。如下图所示：

因为我们需要验证的是群集中的所有节点，所以我们需要把所有节点都添加进来，如下图所示：

点击下一步之后，我们需要运行所有测试，如下图所示：

给出验证清单，也就是所要进行验证的项目。点击，下一步之后，开始出现下面的验证过程：

经过耐心的等待后，出现下图所示：

查看报告，只有一处关于网络的IP地址的警告，这应该是检测到节点间只有一块网卡相连，没有实现冗余，这不影响群集的创建。

点击故障转移群集管理器中的创建一个群集，如下图所示：

再次提示添加要加入群集的所有服务器，如下图所示：

下面，我们需要输入用于管理群集的访问点，也就是群集的名称和对应的 VIP。

接着，需要确认所输入的信息是否正确，如下图所示：

点击，下一步，开始创建群集：

最后，出现摘要信息，群集创建结束。

返回到故障转移群集管理器，查看群集的工作状态，可以看到，仲裁磁盘是我们前面所创建的quorum磁盘，如下图所示：

当前的仲裁配置模式是：节点和磁盘多数，这是因为我们所创建的群集是偶数个节点。

如果希望，更改群集的仲裁配置，可以点击下图所示的操作中，在此不再演示。

群集网络的配置：

下面需要对群集内的各个网络进行相应的配置，以确定它们的用途。

针对public网络，我们需要允许客户端进行访问，所以进行下图所示的操作：

注意，千万不要选错了网络，可以观察IP地址，点击属性，出现下图：

Heart网络的配置： 此网络只用于节点间的通讯，所以不应该允许客户端访问，操作同上，取消客户端的访问。允许群集使用，但不允许客户端访问。

针对store存储网络： 则是不允许群集使用，如下图所示：

群集已经搭建成功了，下面我们就来看看如何在上面安装具体的应用了，本篇先介绍一个简单的应用，实现文件服务器的故障转移群集，我们另一篇文章会详细介绍如何实现SQL Server 2008 R2的故障转移群集。

防火墙准备：节点服务器上必须允许远程卷管理，不然无法在群集内创建共享文件夹。操作方法是在public网络所在网络位置上，允许远程卷管理，如下图所示：

从这个图中可以看出public网络属于域网络，所以，我们只需要在域网络上允许远程卷管理即可。

当然，也可以直接将防火墙禁用。注意，所有节点上都要进行此步操作。

两个节点上都需要安装文件服务器角色，安装方法是服务器管理---角色----添加角色。如下图所示：

在如上图所示的界面中，选择文件服输，下一步后，出现下图所示，一定要选择文件服务器。

节点2上进行同样的操作，安装文件服务器角色。

然后，回到群集中，单击服务和应用程序，右边的配置服务或应用程序。

选择配置服务或应用程序后，出现下面的界面：

点中，文件服务器，此时系统会检查所有节点中是否已经安装了该服务，如果安装不正确，会报错。接下来需要输入客户端访问点的信息，如下图所示：

在此界面中，需要输入客户端访问此服务或应用程序时将使用的名称。名称我们就使用clusterFs，IP地址是客户端访问时所要使用的IP地址。此名称和IP地址会被注册到DNS服务器内。

选择分配给文件服务器的存储磁盘，在此，除了仲裁就是群集磁盘2了，如上图所示。出现确认信息后，开始进行配置，出现下图，表示配置结束。

回到故障转移群集管理器中，可以看到目前提供此服务的是Server1。

下面，我们就就来添加共享文件夹，点击下图中的添加共享文件夹按钮。

下面我们准备将资源磁盘中的文件夹TMG2010共享出来，供企业员工使用。如下图所示：

接下来，需要设置此文件夹的NTFS的权限，可以根据需要进行更改，我们在此就不做修改了。

在下图所示的界面中，可以设备此共享名，根据需要设置一个便于记忆的，有意义的名称。

下面根据需要，依次进行SMB设置、SMB权限设置、DFS命名空间发布等，我们在此都使用默认值，然后需要对该设置进行复查，下图所示：

点击创建，如果一切正常，就如下图所示：

大势至公司可以独家提供从局域网网络行为管理、电脑资料防止泄密管控和信息安全防护一站式解决方案聚生网管网络管理系统（下载）是一款专门的办公室电脑监控软件、局域网网络控制软件，可以禁止网络游戏、禁止上班炒股、禁止P2P软件下载、禁止在线看视频、局域网限制别人网速等，以及绑定局域网IP和MAC地址，防止ARP攻击行为等。大势至文件共享管理软件（下载）是一款专门的共享文件夹访问日志记录软件、服务器共享文件访问权限设置软件，可以实现只让读取共享文件而禁止复制共享文件、只让打开共享文件而禁止另存为本地和禁止拖拽共享文件以及只让修改共享文件而禁止删除共享文件，保护服务器共享文件安全，防止共享文件越权访问。大势至企业数据泄密防护系统（下载）是一款专门保护电脑文件安全，防止U盘复制文件、禁用USB端口的软件，同时还可以屏蔽邮件附件、禁止登录网盘上传文件、禁止FTP软件发送文件、禁止微信发送文件、禁止QQ发送文件等，防止各种途径泄密。大势至局域网接入认证系统（下载）是一款专业的局域网网络准入控制系统，有效阻止外来电脑接入局域网、禁止外来上网上网、禁止非单位电脑访问局域网共享文件、隔离局域网电脑、进行IP和MAC地址绑定、禁止修改IP地址等，保护局域网安全。

可以，集群不要求配置一样~

集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性。--

集群下不同节点去实现对应的功能，可以对应功能去搭配合适的硬件，所以不会要求配置一样。

最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。 

整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。 

1集群架构改造的目标

在之前也总结过目前存在的一些潜在问题，也是本次部署架构改进的目标：

1）之前 的GP segment数量设计过度 ，因为资源限制，过多考虑了功能和性能，对于集群的稳定性和资源平衡性考虑有所欠缺，在每个物理机节点上部署了10个Primary,10个Mirror，一旦1个服务器节点不可用，整个集群几乎无法支撑业务。

2）GP集群 的存储资源和性能的平衡不够 ，GP存储基于RAID-5,如果出现坏盘，磁盘重构的代价比较高，而且重构期间如果再出现坏盘，就会非常被动，而且对于离线数仓的数据质量要求较高，存储容量相对不是很大，所以在存储容量和性能的综合之上，我们选择了RAID-10。

3)集 群的异常场景的恢复需要完善， 集群在异常情况下（如服务器异常宕机，数据节点不可用，服务器后续过保实现节点滚动替换）的故障恢复场景测试不够充分，导致在一些迁移和改造中，相对底气不足，存在一些知识盲区。

4）集群版本过 低 ，功能和性能上存在改进空间。毕竟这个集群是4年前的版本，底层的PG节点的版本也比较旧了，在功能上和性能上都有一定的期望，至少能够与时俱进。

5）操作系统版本升 级 ，之前的操作系统是基于CentOS6，至少需要适配CentOS 7 。

6）集群TPCH 压测验收 ，集群在完成部署之后，需要做一次整体的TPCH压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能目标。

此外在应用层面也有一些考虑，总而言之，是希望能够解决绝大多数的痛点问题，无论是在系统层面，还是应用层面，都能上一个台阶。

2集群规划设计的选型和思考

明确了目标，就是拆分任务来规划设计了，在规划设计方面主要有如下的几个问题：

1）Greenplum的版本选择 ，目前有两个主要的版本类别，一个是开源版（Open Source distribution）和Pivotal官方版，它们的其中一个差异就是官方版需要注册，签署协议，在此基础上还有GPCC等工具可以用，而开源版本可以实现源码编译或者rpm安装，无法配置GPCC。综合来看，我们选择了 开源版本的6162 ，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性bug修复的版本。

2）数据集市的技术选型 ，在数据集市的技术选型方面起初我是比较坚持基于PostgreSQL的模式，而业务侧是希望对于一些较为复杂的逻辑能够通过GP去支撑，一来二去之后，加上我咨询了一些行业朋友的意见，是可以选择基于GP的方案，于是我们就抱着试一试的方式做了压测，所以数据仓库和和数据集市会是两个不同规模体量的GP集群来支撑。

3）GP的容量规划 ，因为之前的节点设计有些过度，所以在数量上我们做了缩减，每台服务器部署12个segment节点，比如一共12台服务器，其中有10台服务器是Segment节点，每台上面部署了6个Primary,6个Mirror，另外2台部署了Master和Standby，就是即（6+6）10+2，整体的配置情况类似下面的模式。

4）部署架构方案选型 ，部署架构想起来比较容易，但是落实起来有很多的考虑细节，起初考虑GP的Master和Standby节点如果混用还是能够节省一些资源，所以设计的数据仓库和数据集市的部署架构是这样考虑的，但是从走入部署阶段之后，很快就发现这种交叉部署的模式是不可行的，或者说有一些复杂度。

除此之外，在单个GP集群的部署架构层面，还有4类方案考虑。

  方案1 ：Master,Standby和segment混合部署

  方案2 ：Master,Standby和segment独立部署，整个集群的节点数会少一些

  方案3 ：Segment独立部署，Master,Standby虚拟机部署

  方案4 ：最小化单节点集群部署（这是数据集市最保底的方案）  

这方面存在较大的发挥空间，而且总体来说这种验证磨合的成本也相对比较高，实践给我上了一课， 越是想走捷径，越是会让你走一些弯路 ，而且有些时候的优化其实我也不知道改怎么往下走，感觉已经无路可走，所以上面这4种方案其实我们都做了相关的测试和验证。

3集群架构的详细设计和实践

1）设计详细的部署架构图

在整体规划之上，我设计了如下的部署架构图，每个服务器节点有6个Primary,6个Mirror,服务器两两映射。

2）内核参数优化

按照官方文档的建议和具体的配置情况，我们对内核参数做了如下的配置：

vmswappiness=10

vmzone_reclaim_mode = 0

vmdirty_expire_centisecs = 500

vmdirty_writeback_centisecs = 100

vmdirty_background_ratio = 0 # See System Memory

vmdirty_ratio = 0

vmdirty_background_bytes = 1610612736

vmdirty_bytes = 4294967296

vmmin_free_kbytes = 3943084

vmovercommit_memory=2

kernelsem = 500 2048000 200 4096

4集群部署步骤

1）首先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。 

2）配置用户，很常规的步骤

groupadd  gpadmin

useradd gpadmin -g gpadmin

passwd gpadmin

3）配置sysctlconf和资源配置

4）使用rpm模式安装

# yum install -y apr apr-util bzip2 krb5-devel  zip

# rpm -ivh open-source-greenplum-db-6162-rhel7-x86_64rpm

5）配置两个host文件，也是为了后面进行统一部署方便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理一些较为复杂的批量操作

6）通过gpssh-exkeys来打通ssh信任关系，这里需要吐槽这个ssh互信，端口还得是22，否则处理起来很麻烦,需要修改/etc/ssh/sshd_config文件

gpssh-exkeys -f hostlist

7）较为复杂的一步是打包master的Greenplum-db-6162软件，然后分发到各个segment机器中，整个过程涉及文件打包，批量传输和配置，可以借助gpscp和gpssh，比如gpscp传输文件，如下的命令会传输到/tmp目录下

gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6162targz =:/tmp

或者说在每台服务器上面直接rpm -ivh安装也可以。

8）Master节点需要单独配置相关的目录，而Segment节点的目录可以提前规划好，比如我们把Primary和Mirror放在不同的分区。 

mkdir -p /data1/gpdata/gpdatap1

mkdir -p /data1/gpdata/gpdatap2

mkdir -p /data2/gpdata/gpdatam1

mkdir -p /data2/gpdata/gpdatam2

9）整个过程里最关键的就是gpinitsystem_config配置了，因为Segment节点的ID配置和命名，端口区间都是根据一定的规则来动态生成的，所以对于目录的配置需要额外注意。

10）部署GP集群最关键的命令是

gpinitsystem -c gpinitsystem_config -s standby_hostname

其中文件gpinitsystem_config的主要内容如下：

MASTER_HOSTNAME=xxxx

declare -a DATA_DIRECTORY=(/data1/gpdata/gpdatap1  /data1/gpdata/gpdatap2 /data1/gpdata/gpdatap3 /data1/gpdata/gpdatap4 /data1/gpdata/gpdatap5 /data1/gpdata/gpdatap6)

TRUSTED_SHELL=ssh

declare -a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1  /data2/gpdata/gpdatam2 /data2/gpdata/gpdatam3 /data2/gpdata/gpdatam4 /data2/gpdata/gpdatam5 /data2/gpdata/gpdatam6)

MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts

整个过程大约5分钟~10分钟以内会完成，在部署过程中建议要查看后端的日志查看是否有异常，异常情况下的体验不是很好，可能会白等。

5集群部署问题梳理

集群部署中还是有很多细节的问题，太基础的就不提了，基本上就是配置，目录权限等问题，我提另外几个：

1） 资源配置问题 ，如果/etc/security/limitsconf的资源配置不足会在安装时有如下的警告：

2） 网络问题 ，集群部署完成后可以正常操作，但是在查询数据的时候会抛出错误，比如SQL是这样的，看起来很简单：select count() from customer,但是会抛出如下的错误：

这个问题的主要原因还是和防火墙配置相关，其实不光需要配置INPUT的权限，还需要配置OUTPUT的权限。 

对于数据节点可以开放略大的权限，如：

入口的配置：

-A INPUT -p all -s xxxxx    -j ACCEPT

出口的配置：

-A OUTPUT -p all -s xxxxx    -j ACCEPT

3）网络配置问题 ，这个问题比较诡异的是，报错和上面是一样的，但是在排除了防火墙配置后，select count() from customer；这样的语句是可以执行的，但是执行的等待时间较长，比如表lineitem这表比较大，过亿的数据量，,在10个物理节点时，查询响应时间是10秒，但是4个物理节点，查询响应时间是在90秒，总体删感觉说不过去。

为了排查网络问题，使用gpcheckperf等工具也做过测试，4节点和10节点的基础配置也是相同的。

gpcheckperf -f /usr/local/greenplum-db/conf/seg_hosts -r N -d /tmp

$ cat /etc/hosts

127001   localhost localhostlocaldomain localhost4 localhost4localdomain4

::1      localhost localhostlocaldomain localhost6 localhost6localdomain6

#127001    test-dbs-gp-128-230

xxxxx128238 test-dbs-gp-svr-128-238

xxxxx128239 test-dbs-gp-svr-128-239

其中127001的这个配置在segment和Master,Standby混部的情况是存在问题的，修正后就没问题了，这个关键的问题也是郭运凯同学发现的。

5集群故障恢复的测试

集群的故障测试是本次架构设计中的重点内容，所以这一块也是跃跃欲试。

整体上我们包含两个场景，服务器宕机修复后的集群恢复和服务器不可用时的恢复方式。

第一种场景相对比较简单，就是让Segment节点重新加入集群，并且在集群层面将Primary和Mirror的角色互换，而第二种场景相对时间较长一些，主要原因是需要重构数据节点，这个代价基本就就是PG层面的数据恢复了，为了整个测试和恢复能够完整模拟，我们采用了类似的恢复方式，比如宕机修复使用了服务器重启来替代，而服务器不可用则使用了清理数据目录，类似于一台新配置机器的模式。

1）服务器宕机修复后集群恢复

select from gp_segment_configuration where status!='u';

gprecoverseg  -o /recov

gprecoverseg -r

select from gp_segment_configuration where status='u'

2）服务器不可用时集群恢复

重构数据节点的过程中，总体来看网络带宽还是使用很充分的。

select from gp_segment_configuration where status='u'

select from gp_segment_configuration where status='u' and role!=preferred_role;

gprecoverseg -r

select from gp_segment_configuration where status='u' and role!=preferred_role;

经过测试，重启节点到数据修复，近50G数据耗时3分钟左右

6集群优化问题梳理

1）部署架构优化和迭代

对于优化问题，是本次测试中尤其关注，而且争议较多的部分。 

首先在做完初步选型后，数仓体系的部署相对是比较顺利的，采用的是第一套方案。

数据集市的集群部分因为节点相对较少，所以就选用了第二套方案

实际测试的过程，因为配置问题导致TPCH的结果没有达到预期。

所以这个阶段也产生了一些疑问和怀疑，一种就是折回第一种方案，但是节点数会少很多，要不就是第三种采用虚拟机的模式部署，最保底的方案则是单节点部署，当然这是最牵强的方案。

这个阶段确实很难，而在上面提到的修复了配置之后，集群好像突然开悟了一般，性能表现不错，很快就完成了100G和1T数据量的TPCH测试。

在后续的改造中，我们也尝试了第三套方案，基于虚拟机的模式，通过测试发现，远没有我们预期的那么理想，在同样的数据节点下，Master和Standby采用物理机和虚拟机，性能差异非常大，这个是出乎我们预料的。比如同样的SQL,方案3执行需要2秒，而方案2则需要80秒，这个差异我们对比了很多指标，最后我个人理解差异还是在网卡部分。

所以经过对比后，还是选择了方案2的混合部署模式。

2）SQL性能优化的分析

此外整个过程的TPCH也为集群的性能表现提供了参考。比如方案2的混合部署模式下，有一条SQL需要18秒，但是相比同类型的集群，可能就只需要2秒钟左右，这块显然是存在问题的。 

在排除了系统配置，硬件配置的差异之后，经典的解决办法还是查看执行计划。

性能较差的SQL执行计划：

# explain analyze select count()from customer;

QUERY PLAN   

Aggregate  (cost=00043100 rows=1 width=8) (actual time=2479291624792916 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00043100 rows=1 width=1) (actual time=325516489394 rows=150000000 loops=1)

         ->  Seq Scan on customer  (cost=00043100 rows=1 width=1) (actual time=07801267878 rows=4172607 loops=1)

Planning time: 4466 ms

   (slice0)    Executor memory: 680K bytes

   (slice1)    Executor memory: 218K bytes avg x 36 workers, 218K bytes max (seg0)

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 24832611 ms

(9 rows)

Time: 24892500 ms

性能较好的SQL执行计划：

# explain analyze select count()from customer;                            

QUERY PLAN

Aggregate  (cost=00084208 rows=1 width=8) (actual time=15193111519311 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00084208 rows=1 width=8) (actual time=6347871519214 rows=36 loops=1)

         ->  Aggregate  (cost=00084208 rows=1 width=8) (actual time=14732961473296 rows=1 loops=1)

               ->  Seq Scan on customer  (cost=00083433 rows=4166667 width=1) (actual time=0758438319 rows=4172607 loops=1)

Planning time: 5033 ms

   (slice0)    Executor memory: 176K bytes

   (slice1)    Executor memory: 234K bytes avg x 36 workers, 234K bytes max (seg0)

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 1543611 ms

(10 rows)

Time: 1549324 ms

很明显执行计划是被误导了，而误导的因素则是基于统计信息，这个问题的修复很简单：

analyze customer;

但是深究原因，则是在压测时，先是使用了100G压测，压测完之后保留了原来的表结构，直接导入了1T的数据量，导致执行计划这块没有更新。

3）集群配置优化

此外也做了一些集群配置层面的优化，比如对缓存做了调整。 

gpconfig -c statement_mem -m 2457600 -v 2457600

gpconfig -c gp_vmem_protect_limit -m 32000 -v 32000

7集群优化数据

最后来感受下集群的性能：

1）10个物理节点，（6+6）10+2

tpch_1t=# iming on

Timing is on

tpch_1t=# select count()from customer;

   count   

-----------

150000000

(1 row)

Time: 1235801 ms

tpch_1t=# select count()from lineitem;

   count    

------------

5999989709

(1 row)

Time: 10661756 ms

2）6个物理节点，（6+6）6

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1346833 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 18145092 ms

3）4个物理节点，（6+6）4

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1531621 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 25072501 ms

4）TPCH在不通架构模式下的性能比对 ，有19个查询模型，有个别SQL逻辑过于复杂暂时忽略，也是郭运凯同学整理的列表。

在1T基准下的基准测试表现：

8000以下无法买真正意义上的服务器。

只能说，买个电脑做服务器。

补充：

我并不是说那玩不够，而是说不能买到真正意义上的服务器。

真正意义上的服务器基本上自已是无法组装的，就算组装也不如购整机划算（服务器配件贵得吓人）。

真正意义上的服务器（数据服务器）硬件上至少应具备下面的特点：

一、较高的多任务处理能力。

我们的个人机一般CPU用的是单块，而服务器常常是双CPU，甚至4CPU，它能处理的并发线程数是个人机的一倍至几倍。而且，服务器的CPU一般比我们普通的个人机的要好。

我们的台式机用于一个人操作，上上网，玩玩游戏，打点文章，和其它。一般情况下，无论你怎么玩，同时开多少程序，同时活动的进程（电脑同时在处理的事情）不会超过二、三十个。而一台服务器当有上百、上千个人同时向服务器提出某些工作请求时，服务器就要有几百上千个线程。就网站服务器来说，如果你的网站同时访问量达到千人时，你的服务器可能产生的并发线程至少有几百，这时，如果是一般的家用台式机，基本上就慢如蜗牛（感觉象死机）。

当然，一般我们的网站能达到同时千人在线的不多，呵呵。如果你的网站能到平均二百人同时在线就非常吓人了，但是，这也不是一肌的家用电脑能受得了的（线程数在50以上）。如果你的网站只是准备玩玩，设计目标只是百人以下同时在线（这时并发线程应该在30以内），比较好的个人机还是能受得了的。

PS：对于网上一些超级大站，如中央电视台等等大网站他们是使用服务器组来对付千人以上同时在线的情况的，也就是说，用多台机采用集群等办法来对付。

二、稳定和巨量的内存。

1、服务器这东西首先必须保证的是稳定！因此最好要使用带ECC（"错误检查和纠正"）功能的内存。这种内存常常比我们常规内存慢，但是稳定度要高很多，也就是说，数据在内存中因硬件原因出错的可能性要小很多很多。

对于我们平常用的台式机来说，实际上在我们使用中内存很偶然地是会出错的，比如你家的机器在一个月内不明不白的死了两回机，你会根本不在意，因为偶然的死机对我们来说是司空见惯了，你也许会认为是软件的原因。我可以告诉你的是，基本上我们的普通电脑没有那台能不关机正常的使用一个月的，就算你使用的软件没有任何不应有的问题。问题在于我们的内存在一个月中亿万次的读写过程中总有几回不小心出了错。

而带有ECC功能的内存就能保证这个故障率在几个月甚至一二年中不出现一次。

当然，这是理论上的，如果你不在意你的网站偶然性的死两回，不在意用户的数据很偶尔的出点小错，用一般的内存问题也不大，呵呵。

2、内存在服务器上的原则也上越快越大越好，同时几百、上千人访问你的机器，机器为了应对他们消耗的内存当然也少不了！在当前，你至少也得二个G吧。

三、硬件冗余性。

打个比方，我们知道，我们一个人，如果左手断了，我们还可以用右手做事。我们身体上的很多部分都是这样。而我们普通的台式机就不同了，其本上稍重要一点的部件只要损坏，机器就无法开动了！

服务器则不然，部门级以上的服务器一般都拥有冗余能务，最典型的是：

1、配有多套电源供电系统，并外接两个（甚至多个）电源。也就是说，一台机器有两个电源插头，你可以将两个插头插向两个不同供电提供者的电源。当一个供电者出了问题，服务器可以正常工作。多套电源供电系统也保证了当服务器的一套电源供电部件中某个坏了，服务器还可以使用另一套正常工作。

2、配有多个CPU，其中的一个CPU坏了，多数情况下另一个还可以坚持工作。

3、硬盘镜像热备（这可能是最重要的了）。服务器上的数据对于很多应用来说，如果完蛋了损失可能是巨大的！硬盘镜像热备保证了你的服务器在某个硬盘损坏时你的数据不受任何影响，而且服务器还能正常工作。（当然，你得尽快买来新硬盘，否则，做热备的第二块也坏了那就真完完了）。

4、高速硬盘。一般服务器使用SCSI硬盘，这种硬盘的转速要几倍甚至几十倍于普通硬盘。这样才能应付快速的数据读写。而且在当前，硬盘镜像热备也一般依靠SCSI总线来完成。

四、拥有所有上面特点的服务器在当前的价位至少是2万以上（这几年便宜了很多哦，我们单位2003年购的一台这样的机器花了近7万）。具体价格很难说，一般网上查不到准确报价。如果你有兴趣，给你一个小窍门，打DELL的免费热线，就说你要买服务器，一般能搞到准确的价格（当然，你不要说实话）。

PS：在当前也有一些低档服务器根本没有上面的功能（或者只有上面的一两个），也叫服务器。那玩真不好怎么说了，呵呵。

当然了，如果你只是想玩玩，8千元买个大内存、好CPU、大硬盘的普通电脑做服务器玩，也不是不可以，不过，那只能是玩玩而已，只能叫用普通机做服务器，而不能叫买了台“服务器”（当然创业的起步也可以的）。