搭建Hadoop集群，一个月6T的数量需要几台服务器？

最好是两个做成HA。

6T的数据容量,看你副本数量设置是多少,一般默认为3,那么仅这些就需要18T硬盘,稍微大一点20T吧;这仅仅是HDFS存储，(这里我说的是一个月的,你数据保存几个月,就乘几倍)。

如果你集群上面要跑计算,MR计算出来的数据要保存HDFS的,所以,还是要根据你的结果数据来做判断,大小就看你计算任务了。

一般是这样计算硬盘大小：

(原始数据+中间数据+结果数据)副本数量=总硬盘大小

随着单台服务器优势的减弱，相信越来越多的人开始逐渐耳闻“集群”这个概念，很大站长学会香港站群服务器，终于把网站搞上去了，对于热备份服务器系统来说同样有优势，服务器集群技术

呵呵 首先 你的2个服务器最好配置很相近 其次是用server2003 或者更高版本
其次 2台服务器是可以群集 但是最好是3台 其中有一个是域控制器，具体如何组件 请查看群集指南 微软官方就有，权威而且准确，又详细

详细安装访问： >群集方法介乎两种计算机系统结构之间。当把多台计算机配置或互连在一起时，可采取松散耦合或紧密耦合结构。网络就是一个松散耦合的系统，我们也称其为异类系统结构。网络把由各种CPU、应用软件、NIC（网络接口控制器）、甚至是 *** 作系统组成的多台计算机连接在一起。计算机之间的地理距离可以近在咫尺，也可以远在天边。可以用实时和/或异步方式耦合网络。

因特网就是一个典型的极为松散与异类配置的例子。因特网本身不能“实时”控制与它连接的任何主机。在松散耦合网络中，单机崩溃一般不会影响网络的其它部分。

相反，紧密耦合系统则高度依赖于构成系统的所有部件。当系统由相同部件组成，采用并行 *** 作方式并共享所有子系统（存储器）时，我们称其为同类系统结构。紧密耦合系统最常见的例子是SMP（对称多处理）。在SMP状态下，根据工作量的多少把任务分给几台处理器，这样可均匀地分配工作量，以便提高数据吞吐量。

我们举了两个典型的松散和紧密耦合系统的例子，群集就介于松散和紧密耦合系统之间。根据系统的配置，在某些方面（比如 *** 作系统），群集控制的系统也许更偏向紧密耦合的系统，或者偏向松散耦合的系统（比如独立计算能力，通过公共存储器连接）。

通常群集器放在同一设备区或同一办公楼里。从理论上说，群集控制方法可应用于闭路广域网环境中（现正在美国东北部地区进行试验）。可是在考虑到视频服务器应用时，一般来说只能把设备放在主要设施运行所在地。
公共数据共享

群集允许共享几个节点的数据。在此应用中，这些节点包括客户工作站、中央或多服务器。我们知道可以通过许多路径（比如星形结构）连接节点，客户可通过不同连接的节点路径存取数据。当节点就是服务器时便可共享公共存储器，某个服务器节点故障不会导致整个群集器系统瘫痪。

在12月专栏里，我们把群集描述成一个提供高可得性的系统。对广播或有线电视 *** 作来说，视频服务器必须要提供连续的或高可得性的数据。考虑到这一点，我们认为视频服务器体系结构采用群集是大有潜力的。

待命或无源服务器结构就是一种群集形式。在这种结构下，一个或多个服务器（或节点）平时保持在待命状态，随时可以启动。利用后台控制系统管理待命服务器内容数据。在未发生故障之前一般不启用无源服务器。

无源服务器未必就是主服务器的完全镜像，它也可以有一些有限的数据源，包括存储器，要经常清除这些数据，然后重新装入最新的节目或广告。通过这一循环过程把适量的数据（或视频媒介）保持在待命状态，在需要时随时可以上线使用。

服务器在待命状态时通常由少量的部件组成，比如编解码器，在出现故障或另一个服务器需要它支持的时候，该服务器可立即被集成到系统中应用。此时，服务器进入负载均衡状态。
数据共享

数据共享是群集器需要提供的最基本功能之一。我们还是以视频服务器的应用为例，多个编辑站在这里独立地工作，不过利用一组公共服务器来管理数据和应用层的处理。

在这个例子中，多个新闻编辑站（或客户工作站）可以选择用哪个编辑服务器（包括编辑用的软件和硬件）来进行编辑。这些服务器控制对公共媒体数据库的存取，编辑站只是这些服务器的简单控制器GUI（图形用户界面）。编辑服务器进一步控制接入另一个更大的数据存储库（通常是新闻档案）。

这个概念可通过群集软件实现。在独立的编辑站通过群集器存取数据的过程中，编辑与数据存取或存储处理自动进行，不会影响其它的客户编辑站或预放站。通过提供连续的数据可得性，每个服务器可以是有源的，也可以是无源的，视工作负荷而定。假如有一个服务器发生了故障，该结构也可提供冗余或保护方式。

共享一个 *** 作系统和平台是群集的又一个共同特点。让硬件与软件平台同属一类，也就是说，基本上是相同的，就可采用公用互连方案与公共文件格式结构。在SMP这样的系统中，所有部件都依赖于公用硬件而像单独部件一样运行。正如我们已提到的，群集可以让一部分系统保持同类结构，但脱离所有系统都有的依赖性，其它性能就会下降。
其它优点

我们现在还是回到基于群集服务器的编辑环境中来，我们又发现了其它一些优点。服务器硬件具有的冗余性可对数据起保护作用。在新闻编辑环境中，当即将播放时，一个或更多的服务器便可将客户工作站的功能变成播出功能，直接把新闻播出去。这样还能让所有客户和服务器接入别的服务器的数据，包括在最后一分钟直接存取中央存储库的数据。

通过使用多个服务器（每个服务器收集、编辑、存档和重放的资源是一个类型的），系统便可对硬件进行备份。在某个服务器出现故障时，可把资源转给或分给其它用户，系统的其余部分仍继续工作。

除了上述的数据共享外，其它群集器结构也是可行的。在有些情况下，某些资源可被一个特定的节点“拥有”，在未接到指令前不会放弃。可将该系统的结构配置成一个节点有多个输入编码器，但只有一个输出解码器。另一个节点可能没有输入，但有好几个输出供放像和预看用。如果某一个节点出现故障，可让与它相对应的节点顶替它，直到它被修复为止。
非共享结构

从硬件上说，每个节点的能力（或资源）基本上相同，但内部系统配置是用各种形式锁定的，除非另有要求。按照群集语言可把此结构

叫做非共享结构。在此结构里，某些资源在未被传送给其它节点或者该节点未出故障之前归一个节点所有。在采用非共享结构的计算机与模式里运用群集法通常会把硬盘等设备分配给一个节点，并阻止其他人使用它，除非将其开放或该节点发生故障。

群集结构的其它实施方面增加了系统的复杂程度。除了非共享结构外（只提供最简单的性能和可得性），还有磁盘共享结构。磁盘共享可提高存储接入不同主机系统的能力。

从硬件的角度看，系统的磁盘阵列控制器可以很容易地管理这个共享结构。比较难办的是在最低级别（文件或记录层）上协调更新数据。

协调工作必须成为群集软件的一部分。可以设想一下，如果两个用户同时接入同一记录层会发生什么情况。假定每个用户都修改了文件。用户1先把数据写入服务器，他发现用户2做了完全不同的修改并且把修改后的文件用同一文件名存入相同的磁盘，或许存在另一个服务器上，这样就有可能把第一个用户修改的文件冲掉。没有一个控制方案，就会乱成一团。

尽管每个文件或记录层都有简单的口令或锁定保护，但要确保用文件的正确版本存成另一个文件名或是“正式”版，则要求具有更高层的数据控制与管理能力。磁盘快速缓存问题又是另一种情形，我们等一会儿再说。

另一个防止错误数据覆盖正确数据的方法是在修改未最后定之前限制接入某一特定文件。在计算机数据域中，用一个称为信息传送的程序通知管理员（通常是应用后台软件的一部分）文件存取被锁定，直到修改程序结束为止。
原子 *** 作

原子 *** 作的三个步骤是：读数据、修改数据、然后重新写入新数据。在原子 *** 作过程中，在未执行完 *** 作之前不会受到任何干扰。还必须有其他保护措施，以防隐藏的备份文件在以后某个无法预测的时间改写其它的文件。

当数据分布在不止一个存储磁盘上时，或者当公共存储阵列中的数据被不同用户在不同时间存取时，如何防止数据不一致是群集软件需要解决的又一个问题。无论是通过硅缓存器还是通过远程接入的临时磁盘缓存器（甚至分区）进行高速缓存都会遇到定时和同步的问题。我们把这个问题叫做缓存相关性，它是因磁盘驱动器定时问题引起的。

磁盘驱动器并不一定能马上写入数据，磁头也许定位在错误的磁道上，导轮也许偏离相位190度，等结束运转后才能开始磁头的写入 *** 作，或许还因为温度问题造成暂时性延缓，直到一切都符合条件为止。

这通常被称为等待时间，磁盘驱动器的机械部分要求在驱动器等待写入时暂存一下数据。最常见的方法是在驱动器上安一个硅缓存器，这个过程被叫做写回高速缓存。在把主机储存器中的数据转存到磁盘驱动器的过程中，设一个写回缓存器标识，对数据源表示写入程序成功了。实际上，得过一会儿才能开始真正的电磁机械式的数据储存过程。

假如系统上的另一个节点也从这个驱动器读数据，（这是经过许可的 *** 作，因为数据发生器已接到通知，新数据已发送到了这个位置），那么缓存器已在指定位置存储了正确新数据的指示信号就不见了。我们用失效数据一词来表示未更新数据进入新数据区的状态。
无效数据

RAID控制器在各自磁盘阵列的写回缓存器里为与这个特殊的阵列有关的磁盘管理失效数据。假如在软件里设一些适当的开关来检测和阻止它发生，那么数据相关性就只是一个小问题了。

当系统是由多层阵列构成的时候，控制失效数据问题的任务就交给高级别软件去完成，把信号传送给各自的阵列，就不会发生孤立或失效数据问题了。

在这个简化的单一视频服务器模型里，媒体是通过单编码器输入的，并存在一个单实体阵列上。由一个更高级别（通常是第三方API，应用程序接口）登记和管理活动图像数据。通常将其作为任选的“媒体管理”或“资产管理器”包出售。通过这个软件，控制活动图像和数据的过程成为一个闭路过程，因为输入与输出指令必须通过这个管理软件包。该软件在自己的数据库里始终跟踪着数据的有效性。

如果有好几个服务器，每个服务器有自己的任务，情况就变得比较复杂了。这时可以让几个信号源的输入进入不同的编码器，并存在一个较大的磁盘阵列里。这些阵列通常与光纤通道仲裁环相连，由于它的连接方式决定，它可迫使部分重写动作由服务器推迟到存储器，直到有了充足的带宽来把该数据从这个存储器存入另一个存储器。

在类似的应用中，媒体管理软件就更完善，更必不可少了。有时候制造商会提供一个完全独立的CPU和资源管理软件包（作为选件）。这个软件包就像看门狗那样管理服务器之间的数据共享 *** 作。除了这些基本概念外，还有大量的定时和数据验证问题，这些问题会经常在服务器结构的软件与子系统中碰到。

群集的过程和功能正在扩展到设备内和设备间应用中。群集器理念最终将允许整个广播集团通过光纤或通过广域网共享资源。虽然可以让设施连成网共享媒介，可是在这些设施相互离得很远的情况下实现节点资源共享的设想似乎还很遥远。

集群架设服务器数量：2台
集群架设方法：（设定：主服务器IP：192168011 从服务器 192168012）
第一步：架设主服务器
1、 利用启动器配置好完整的服务端程序 （举例：比如服务器名：测试 服务器IP：192168011 登陆网关端口 7000 角色网关端口 7100 游戏RUN端口 7200 7300 7400），利用启动器配置好后，那么你的主服务器是一个完整的服务端了
2、 修改配置文件：（修改配置文件的目的是为了让你的从服务器能够跟这台主服务器进行通讯，具备负担的条件）
1> DBServer !addrtabletxt 此文档含义：允许连接DBS管理器的IP列表，一般写上 127001 主IP 192168011 从IP 192168012 三个IP独立成行
2> DBServer ！serverinfotxt 此文档含义：主服务器 从服务器 的网关IP以及端口，可以设置如下
192168011 192168011 7200 192168011 7300 192168011 7400
192168012 192168012 7200 192168012 7300 192168012 7400
3> LogunSrv !addrtabletxt 此文档 实际上是一个角色网关跟登陆网关直接通讯路由标识表 在最后加一个 从服务器的IP跟端口即可
比如：127001 127001 192168011:7100 192168012:7100
4> LogunSrv !serveraddrtxt 允许连接IDDBS 同DBServer !addrtabletxt
主服务器架设完毕 架设完毕后切忌不要再用启动器配置了 否则要从来再配置一遍，就麻烦啦。
第二步：架设从服务器
1、 从服务器只需要开 SELATE RUNGATE
1> SELATE 开启的目的是 登陆7000之后 可以选择到这台从服务器的网关 记得配置文件网关地址写本服务器IP地址 192168012 服务器地址写 192168011
2> RUNGATE 手动配置3个 7200 7300 7400 服务器地址写上 主服务器地址 192168011
架设完毕主服务器利用启动所有程序 从服务器手动开 角色网关 和三个游戏网关
在主服务器的M2上面能看到 从服务器的IP过来就说明通讯成功，如果看不到，说明自己哪里设置错了，仔细检查下！原理很简单的，自己实践吧！

运维人员的工作每天基本上都是在检查问题，枯燥但又重要， 要是你的某一个环节出现问题并没有及时发现问题，对于企业来说损失可能非常大，基本上运维人每天的工作我罗列了下，有这几种：

1、负责服务器的硬件配置、软件安装、机房上下架等技术维护工作

2、负责虚拟化技术产品物理机配置、管理和日常运行监控和维护

3、负责独立主机或虚拟应用产品的开通使用、日常维护、故障诊断和排除

4、提供独立主机或虚拟应用客户产品 *** 作和应用方面的技术支持

5、监视分管的服务器，及时发现问题，并积极解决问题

现在信息化数字时代，单靠人工去检查出现错误几率会很大，而且有的运维人还不只管理两台服务器，像我们公司的运维每人至少要管理30台服务器，这样子单靠人工运维耗费的人工成本和时间是非常大的，所以还是推荐你用运维工具吧，比如云帮手（）

1支持跨云商批量管理服务器

2兼容性强大，兼容市面基本所有的云商云主机，兼容 *** 作系统；

3 *** 作简单，可视化界面预览资源、一键修复、一键部署；

4 可以远程登录云主机FTP桌面，处理云主机上的文件；

5监控和资源还有告警功能，这个是挺好的，不用盯着看；

6系统修复功能，这个是挺实用也比较必须的；

7免费使用。总得来说功能还是挺全的，不存在需要又要另外找软件的尴尬。

你好，很高兴回答你这个问题。从运维的角度来讲，服务器的数量少并不意味着我们的运维工作就非常轻松，相反我们更应该重视此阶段的工作。

我们可以从以下几方面来开展我们的运维工作：

1应用服务器

我们可以从当前服务器中找出 至少2个节点装Vsphere虚拟化，建立一个数据中心、集群 ；如果你的服务器有多网卡和SCSI，还可以做一些更高级的应用，如vmotion、负载均衡、高可用等。当虚拟机或服务器故障，可以 实现故障自动转移，有效的避免了单节点的故障，提供服务器的容错率 。

我们可以在新建的虚拟机部署Web、API等各种应用，而且 虚拟机可以在vCenter图形化界面下统一管理 。这一般是中小公司的在服务器方面的解决方案。

当然，我们对docker比较熟悉，可以使用一套docker解决方案，这比Vsphere更能节省一部分资源。当然这个需要的技能要求也比较高，需要我们不断积累。

2数据库服务器

数据库服务器在此我们单独拿出来，是因为数据库对服务器性能、磁盘IO要求比较高，不太建议使用虚拟机，当然这需要根据业务的实际情况来做选择。 数据库我们需要通过一主一从、一主二从的方式实现高可用，来避免数据库单点问 题，我们还可以选择合适的proxy来进行读写分离、读负载均衡等。另外还要考虑数据的本地备份、异地备份，来确保数据可恢复。

3系统监控

当我们在应用服务器和数据库服务器上线一套系统后， 我们需要通过监控掌握从服务器硬件、基础状态、应用、数据库等从下到上的运行状态 ，以便我们能够对告警及时做出响应。考虑到报警的及时性，我们需要监控接入多种报警渠道，如微信、钉钉、邮件、短信等。监控的目的是发现问题、解决访问，因此我们需要踏实的做好这一步，才能为我们的业务保驾护航。

好了，其实不管服务器多少，我们都需要扎实的把基础打好，这样才能以不变应万变面对各种情形。希望我的回答能够帮到你。

题主没有详细说明具体应用系统的功能，比如是否单一的Web服务？有没有微服务、分布式、集群化扩展的潜在需求？

通常来说，建议使用云服务自动化运维。云服务已经成为IT技术的核心基础设施，充分利用云服务带来的d性和分布式优势，赋能自动化运维。

一，自动构建系统

如果需要构建应用，那么就建议配置使用CI/CD持续化集成和自动化部署，比如常用的Jenkins，配置Git代码提交时触发构建，然后自动部署。

二，日志收集处理系统

1，ELK是常见的日志收集管理系统，包括ElasticSearch, LogStash, Kibana三个服务，架构示意图如下：

2，在ELK系统中，Kibana是一个图形化展示工具，配置查询条件，运维人员随时可以搜索指定日志信息，分析处理故障。

三，服务监控

1，云监控CloudMonitor

主流云服务商都将监控功能集成到了基础架构中，以阿里云为例，云监控提供了多种配置，多维度全方位监控。

比如配置CPU使用率到达80%时，自动触发动作，增加服务器实例，同时邮件通知运维人员。

2，应用监控

以监控宝为例，配置服务地址，选择分布在不同地区和运营商的监测点。当监测点不能正常调用配置的服务地址时，将收到警告信息，可以选择邮件、短信、电话等通知方式。

四，潜在的系统扩展需求

1，是否集群化部署？需要AutoScaling自动伸缩吗？

小型化和集群化并不冲突。如果采用集群化部署，可以配置触发条件，满足时自动增加或者释放服务器资源。比如当CPU使用率达到75%或者内存占用率达到75%时，根据配置好的服务器和数量，自动触发。

2，是否使用Docker容器技术？

Docker将应用以及依赖打包到一个可移植的镜像中，可以实现虚拟化，有助于快捷高效的交付应用，结合Docker-compose资源编排，快速实现自动部署更新，不再需要常用的Jenkins构建服务器。

机器数比较小的话，你可以用云的服务器，这样可以节省好多钱。找一个专门的运维，还不如让开发自己来搞，因为机器少运维他也应付得过来。现在都在搞云计算了，把你的机器放上阿里云或者腾讯云，你自己维护好很多，包括网络贷款都很容易扩容。上面这个我说到的只是说建议你如果你已经是自己的机器了。我建议你从我下面所说的来搞。

认为的整个过程的话一般分为三个阶段，第一的话是手工阶段，什么东西都是手工搞。

第2个阶段就是脚本阶段了，本来手工搞的东西全部脚本化。

第3个阶段就是平台化了，平台化了之后，所有东西都在页面上完成系统完成，不需要人工来干预，甚至不用运维来搞。

有一些人说既然认为就是最后的一个阶段，但是这个很不成熟。所以我就不说了。

针对你这个机器数少的，你可以手工认为，或者说用脚本认为都没问题。

在合适的阶段做合适的事情就是最好的。所以我建议你手工运维或者脚本运维。

我们项目用的 wgcloud运维监控系统 ，它前身是开源项目，后来推出的商业版，也有免费版

wgcloud运行很稳定，性能很好，部署和上手容易

wgcloud支持主机各种指标监控(cpu状态/温度，内存状态，磁盘容量/IO，硬盘smart监控，系统负载，网卡流量，硬件系统信息等)，数据可视化，进程应用监控，大屏可视化，服务接口检测，DOCKER监控，自动生成网络拓扑图，端口监控，日志文件监控，web SSH（堡垒机），指令下发执行，告警信息推送（邮件钉钉微信短信等）

可以装虚拟机代替，在同一个局域网情况下

找服务商外包服务，或者网上托管也不贵收费

服务器数量比较少，比如10台服务器，基本可以不设置运维岗位了，后端开发人员 或者架构师就能搞定。

我就是那种曾经在创业的小公司待过的开发人员，开发，运维我都干了。

但是想想如何更科学更高效的运维还是很有必要的。

运维的目的

软件系统的运行时环境：即公司的业务产线，靠它创造业务价值，这个是最核心的功能诉求。

实时监控系统: 任何时候都要对当前公司的产线的压力一清二楚，有问题功能随时解决，有性能问题及时扩容或者回收资源

降低服务器成本：在业务萎缩的情况下，准确评估哪些资源可以回收，降低服务器的支出

这个是当时我认为的运维的三个主要目的。

运维方案

开发半路出家，当时采用的是shell+python+ansible+jekins+elk的方式

首先，我会及时的更新业务产线的物理架构图，根据架构图来规划服务器的资源使用。

比如多少个web服务，数据库多少，zk,kafka,redis集群怎么分布。

集群部署一般是放在多个服务器上的，这个时候ansible就派上用场了。

jekins主要用来自动发布更新程序已经做定时回收磁盘的任务。

elk主要用来做应用的日志系统和监控告警； 可以通过看板随时知道产线的请求数量和并发数量；

以上的运维方案适用于小公司。运维工程师看到了可以补充

搞个zabbix刷

数量少。如果配置好可以虚拟化。然后跑容器

分布式与集群是不一样的，简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行改任务需10小时。

采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。

而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，10小后，10个任务同时完成，这样，整体来看，还是1小时内完成一个任务。

扩展资料

分布式系统可以分为机体内系统、建筑物内系统、建筑物间系统和不同地理范围的区域系统等，它们的耦合度依次由高到低按应用领域的性质决定耦合度，可以分成三类：

一、是面向计算任务的分布并行计算机系统和分布式多用户计算机系统，它们要求尽可能高的耦合度，以便发展成为能分担大型计算机和分时计算机系统所完成的工作。

二、是面向管理信息的分布式数据处理系统。耦合度可以适当降低。

三、是面向过程控制的分布式计算机控制系统。耦合度要求适中，当然对于某些实时应用，其耦合度的要求可能很高。

---