摘要

在信息化社会，企事业单位业务对信息系统高度依赖，而信息系统维护人员往往拥有系统最高管理权限，其操作行为必须得到有效监管与审计。作为运维操作审计最佳解决方案的堡垒机通常会给人一种神秘莫测的感觉，为了让大家更清楚的了解堡垒机和运维操作审计，本文对堡垒机的概念及主要工作原理进行简要分析。

前言

当今的时代是一个信息化社会，信息系统已成为各企事业单位业务运营的基础,由于信息系统运维人员掌握着信息系统的最高权限，一旦运维操作出现安全问题将会给企业或单位带来巨大的损失。因此,加强对运维人员操作行为的监管与审计是信息安全发展的必然趋势。在此背景之下,针对运维操作管理与审计的堡垒机应运而生。堡垒机提供了一套多维度的运维操作控管控与审计解决方案，使得管理人员可以全面对各种资源(如网络设备、服务器、安全设备和数据库等)进行集中账号管理、细粒度的权限管理和访问审计，帮助企业提升内部风险控制水平。

堡垒机概念和种类

"堡垒"一词的含义是指用于防守的坚固建筑物或比喻难于攻破的事物，因此从字面的意思来看"堡垒机"是指用于防御攻击的计算机。在实际应用中堡垒机又被称为"堡垒主机"，是一个主机系统，其自身通常经过了一定的加固，具有较高的安全性，可抵御一定的攻击，其作用主要是将需要保护的信息系统资源与安全威胁的来源进行隔离，从而在被保护的资源前面形成一个坚固的"堡垒"，并且在抵御威胁的同时又不影响普通用户对资源的正常访问,堡垒机还集成了行为审计和权限控制，从而加强了堆操作和安全的控制。

基于其应用场景，堡垒机可分为两种类型：
1、网关型堡垒机

网关型的堡垒机被部署在外部网络和内部网络之间，其本身不直接向外部提供服务而是作为进入内部网络的一个检查点，用于提供对内部网络特定资源的安全访问控制。这类堡垒机不提供路由功能，将内外网从网络层隔离开来，因此除非授权访问外还可以过滤掉一些针对内网的来自应用层以下的攻击，为内部网络资源提供了一道安全屏障。但由于此类堡垒机需要处理应用层的数据内容，性能消耗很大，所以随着网络进出口处流量越来越大，部署在网关位置的堡垒机逐渐成为了性能瓶颈，因此网关型的堡垒机逐渐被日趋成熟的防火墙、UTM、IPS、网闸等安全产品所取代。

2、运维审计型堡垒机

第二种类型的堡垒机是审计型堡垒机，有时也被称作"内控堡垒机",这种类型的堡垒机也是当前应用最为普遍的一种。

运维审计型堡垒机的原理与网关型堡垒机类似，但其部署位置与应用场景不同且更为复杂。运维审计型堡垒机被部署在内网中的服务器和网络设备等核心资源的前面，对运维人员的操作权限进行控制和操作行为审计;运维审计型堡垒机即解决了运维人员权限难以控制混乱局面，又可对违规操作行为进行控制和审计，而且由于运维操作本身不会产生大规模的流量，堡垒机不会成为性能的瓶颈，所以堡垒机作为运维操作审计的手段得到了快速发展。

最早将堡垒机用于运维操作审计的是金融、运营商等高端行业的用户，由于这些用户的信息化水平相对较高发展也比较快，随着信息系统安全建设发展其对运维操作审计的需求表现也更为突出，而且这些用户更容易受到 "信息系统等级保护"、"萨班斯法案"等法规政策的约束，因此基于堡垒机作为运维操作审计手段的上述特点，这些高端行业用户率先将堡垒机应用于运维操作审计。

随着互联网的快速发展，web 2.0快速化和互联网公司运维人员对编程技能的掌握程度越来越重要，互联网公司安全意思越来越强，好多公司都已经开发使用堡垒机，作为权限控制和运维行为审计。

堡垒机运维操作审计的工作原理

作为运维操作审计手段的堡垒机的核心功能是用于实现对运维操作人员的权限控制与操作行为审计。

1、主要技术思路

如何实现对运维人员的权限控制与审计呢？堡垒机必须能够截获运维人员的操作，并能够分析出其操作的内容。堡垒机的部署方式，确保它能够截获运维人员的所有操作行为，分析出其中的操作内容以实现权限控制和行为审计的目的，同时堡垒机还采用了应用代理的技术。

运维审计型堡垒机对于运维操作人员相当于一台代理服务器(Proxy Server)，其工作流程示意图如下所示：

[]运维人员在操作过程中首先连接到堡垒机，然后向堡垒机提交操作请求;[/][]该请求通过堡垒机的权限检查后，堡垒机的应用代理模块将代替用户连接到目标设备完成该操作，之后目标设备将操作结果返回给堡垒机，最后堡垒机再将操作结果返回给运维操作人员。[/]

 

通过这种方式，堡垒机逻辑上将运维人员与目标设备隔离开来，建立了从“运维人员->堡垒机用户账号->授权->目标设备账号->目标设备”的管理模式，解决操作权限控制和行为审计问题的同时，也解决了加密协议和图形协议等无法通过协议还原进行审计的问题。

2、工作原理简介
下面就简单介绍一下堡垒机运维操作审计的工作原理，其工作原理示意图如下：

在实际使用场景中堡垒机的使用人员通常可分为管理人员、运维操作人员、审计人员三类用户。

管理员最重要的职责是根据相应的安全策略和运维人员应有的操作权限来配置堡垒机的安全策略。堡垒机管理员登录堡垒机后，在堡垒机内部，“策略管理”组件负责与管理员进行交互，并将管理员输入的安全策略存储到堡垒机内部的策略配置库中。

"应用代理"组件是堡垒机的核心，负责中转运维操作用户的操作并与堡垒机内部其他组件进行交互。"应用代理"组件收到运维人员的操作请求后调用“策略管理”组件对该操作行为进行核查，核查依据便是管理员已经配置好的策略配置库，如此次操作不符合安全策略“应用代理”组件将拒绝该操作行为的执行。

运维人员的操作行为通过"策略管理"组件的核查之后"应用代理"组件则代替运维人员连接目标设备完成相应操作，并将操作返回结果返回给对应的运维操作人员;同时此次操作过程被提交给堡垒机内部的"审计模块"，然后此次操作过程被记录到审计日志数据库中。

最后当需要调查运维人员的历史操作记录时，由审计员登录堡垒机进行查询，然后“审计模块”从审计日志数据库中读取相应日志记录并展示在审计员交互界面上。

如何选择一款好的堡垒机产品

对于信息系统的管理者来说除了工作原理以外可能更关心如何选择一款好的运维审计堡垒机产品。一个好的运维审计堡垒机产品应实现对服务器、网络设备、安全设备等核心资产的运维管理账号的集中账号管理、集中认证和授权，通过单点登录，提供对操作行为的精细化管理和审计，达到运维管理简单、方便、可靠的目的。

1、管理方便

应提供一套简单直观的账号管理、授权管理策略，管理员可快速方便地查找某个用户，查询修改访问权限;同时用户能够方便的通过登录堡垒机对自己的基本信息进行管理，包括账号、口令等进行修改更新。

2、可扩展性

当进行新系统建设或扩容时，需要增加新的设备到堡垒机时，系统应能方便的增加设备数量和设备种类。

3、精细审计

针对传统网络安全审计产品无法对通过加密、图形运维操作协议进行为审计的缺陷，系统应能实现对RDP、VNC、X-Window、SSH、SFTP、HTTPS等协议进行集中审计，提供对各种操作的精细授权管理和实时监控审计。

4、审计可查

可实时监控和完整审计记录所有维护人员的操作行为;并能根据需求，方便快速的查找到用户的操作行为日志，以便追查取证。

5、安全性

堡垒机自身需具备较高的安全性，须有冗余、备份措施，如日志自动备份等

6、部署方便

系统采用物理旁路，逻辑串联的模式，不需要改变网络拓扑结构，不需要在终端安装客户端软件，不改变管理员、运维人员的操作习惯，也不影响正常业务运行。

总结

上面简要分析了堡垒机的概念以及其运维操作审计的主要工作原理。随着信息安全的快速发展，来自内部的安全威胁日益增多，综合防护、内部威胁防护等思想越来越受到重视，而各个层面的政策合规，如“萨班斯法案”、“信息系统等级保护”等等也纷纷对运维人员的操作行为审计提出明确要求。堡垒机作为运维安全审计产品将成为信息系统安全的最后一道防线，其作用也将越来越重要，应用范围势必会快速扩展到各个行业的信息系统。因此在当前的形势之下，让大家更加清楚的了解堡垒机也就十分必要了。

原由

局域网双机拷贝单个大文件 【200G大小】，不要问我是啥！ 也不要问我为毛会生成那么大的单文件，事实就是这样！然后就开始了操蛋之旅！再次做下记录备忘！

方法尝试对比

方式一：scp

什么是scp: scp 命令是 SSH中最方便有用的命令了，scp就是secure copy，是用来进行远程文件拷贝的。数据传输使用 ssh，并且和ssh 使用相同的认证方式，提供相同的安全保证。 与rcp 不同的是，scp 在需要进行验证时会要求你输入密码或口令。

速度：刚开始的时候33M/s 持续3分钟左右就跌落到3M左右的传输速度

方式二：rsync

什么是rsync: rsync是rcp的替代品之一，rsync 是一款高效的远程数据备份和镜象工具，

速度：无响应

方式三：wget

什么是wget: wget 是一个经由 GPL 许可的可从网络上自动获取文件的自由软件包。它是一个非交互式的命令行工具。支持 HTTP，HTTPS 和 FTP 协议，支持代理服务器以及断点续传功能。 wget 可实现递归下载，即可跟踪 HTML 页面上的链接依次下载来创建远程服务器的本地版本，完全重建原始站点的目录结构，实现远程网站的镜像。在递归下载时，wget 将页面中的超级链接转换成指向本地文件，方便离线浏览。由于非交互特性，wget 支持后台运行，用户在退出系统后，仍可继续运行。功能强大，设置方便简单。

速度：刚开始的时候50M/s 持续3分钟左右就跌落到3M左右的传输速度

方式四：bbcp

什么是bbcp: bbcp 是由SLAC(斯坦福直线加速器中心)的Andy Hanushevsky创立的点对点网络文件拷贝工具。经过简单测试，发现速度比 scp 快了10倍左右，因此推荐大家采用bbcp来取代scp等老家伙 :)

速度：针对20G的文件进行了测试，测试下来平均下来速度在21M左右，耗时16分钟

附图为2G文件的传输速度：

总结

不同的应用场景使用不同的工具，单个大文件个人感觉bbcp还是极好极好的！

安装bbcp【两端都要安装】

wget http://www.slac.stanford.edu/~abh/bbcp/bin/amd64_rhel60/bbcp -O /usr/bin/bbcp

chmod +x /usr/bin/bbcp

来自http://heylinux.com/archives/2984.html的中文参数解释：

-k 保留所有未传输完成的文件，并允许在重试时进行覆盖

-a 保留checkpoint信息用于校验文件的完整性

-r 递归传输指定路径下的所有文件

-P 2 每两秒显示传输的进程

-V 打印调试信息

-f 强制清除远程主机上传输失败的数据

-w 设置Disk (I/O) buffers

   算法为(window = netspeed/8[i]RTT = 1000Mb/8[/i]74ms = 1000/1000/8*74 = 9.25 M)

   对应链接：http://www.slac.stanford.edu/~abh/bbcp/#_Toc332986061

-s 16 设置并发数为16

      参考官方建议：http://www.slac.stanford.edu/~abh/bbcp/#_Streams_(-s)

-T "ssh -x -a -p 2222 -oFallBackToRsh=no -i /home/dong.guo/.ssh/id_rsa -l heydevops heylinux.com /usr/bin/bbcp" 

   指定远端主机的认证方式：

   采用-p 2222指定端口；

   设置-oFallBackToRsh=no减少ssh响应时间；

   设置-i /home/dong.guo/.ssh/id_rsa指定SSH Key；

   设置-l heydevops指定登陆用户；

   heylinux.com为远程主机地址；

   /usr/bin/bbcp为远程主机的bbcp路径；

参考文档：

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm 
http://heylinux.com/archives/2984.html 
http://imysql.cn/2008_12_08_using_bbcp_instead_scp 
http://linux.cn/article-4527-1-rss.html 
http://teachmyself.blog.163.com/blog/static/188814229201242314917237/
阅读分享原文：http://www.dwz.cn/2D55vI

什么是IDC

IDC即是Internet Data Center，是为集中式收集、存储、处理和发送数据的设备提供运行维护的设施以及相关的服务体系，通俗来讲，IDC就是机房。

IDC提供的主要业务包括主机托管(机位、机架、VIP机房出租)、资源出租(如虚拟主机业务、数据存储服务)、系统维护(系统配置、数据备份、故障排除服务)、管理服务(如带宽管理、流量分析、负载均衡、入侵检测、系统漏洞诊断)，以及其他支撑、运行服务等。

什么是ISP和ICP

ISP：

ISP的英文是Internet Service Provider,翻译为互联网服务提供商,即向广大用户综合提供互联网接入业务、 信息业务、和增值业务的电信运营商。像我们熟知的中国电信,之前的中国网通现在的新联通,中国移动,中国铁通等等,都是主要的ISP运营商。

ICP：

ICP的英文是Internet Content Provider,翻译为互联网内容提供商,即向广大用户综合提供互联网信息业务和 增值业务的电信运营商。一般网站都应该算为ICP运营商,这也是为什么我们常有需要ICP备案,而ICP在国内也分为商业ICP和非商业ICP。

什么是带宽独享和共享

顾名思义，独享带宽，就好比该线路是您服务器的专用高速公路，线路上传输的只有您自己服务器的数据，当然传输的量有一定限制，是根据用户要求来配备，一般是以100M为一个递增单位；而共享带宽，就是说有多台服务器在共同享受这条线路，线路上除了您，还有其他用户服务器的数据传输。

独享与共享各自的优、缺点?
独享带宽

[]优点：可自由使用带宽量，能保证速度和网络质量；[/]
• 缺点：费用昂贵，一般100M的独享带宽，每月费用从上万到数万不等；

共享带宽

[]优点：价格比独享方式低廉不少，并且可以实现同线路上的高速资源共享；[/][]缺点：速度相对较低且不稳定，传输速率随线路上网络数据传输运行状态而有所变化；[/]

What VPS/虚拟主机

VPS是利用VPS（Virtual Private Server）技术，在一台服务器上创建多个相互隔离的虚拟专用服务器的优质服务。每个VPS的运行和管理都与一台独立主机完全相同，都可分配独立公网IP地址、独立操作系统Windows/Linux、独立超大空间、独立内存、独立CPU资源、独立执行程序和独立系统配置等。用户除了可以分配多个虚拟主机及无限企业邮箱外，更具有独立服务器功能，可自行安装程序，单独重启服务器，总而言之，VPS是一项具备高弹性、高质量及低成本效益的服务器解决方案。

虚拟主机（Virtual Host Virtual Server）是使用特殊的软硬件技术，把一台计算机主机分成一台台“虚拟”的主机，每一台虚拟主机都具有独立的域名和IP地址（或共享的IP地址），具有完整的Internet服务器功能。

云时代IDC运营商面临的挑战

业务：[list=1][]同质、低价、低水平的无序竞争，缺乏增值业务;[/][]缺乏灵活的运营模式和技术架构，业务创新困难;[/][]运营商面临转型："卖资源" ->  "卖服务" ->  "卖能力"[/]成本：[list=1][]庞杂的设备，每天都会产生巨额的财务成本[/][]各类业务系统结构复杂重复，服务器、存储设备的无序扩张[/][]人力成本[/]能耗：[list=1][]设备以专用方式分配，产生资源孤岛，机器利用率低[/][]按传统设计方式，无论运营商业务量有多大，设备始终运行，导致其设备始终按最大容量耗电[/]管理：[list=1][]缺乏完善的流程定义，当前多采用人工方式，缺少相应的平台支持[/][]资源管理缺乏自动化，大量人力资源耗费在繁重的重复性工作上，无法关注业务发展和服务质量[/]

企业节能减排需求

引入云计算的新一代IDC

IDC融合架构组件

云计算对运营商的影响- IT技术架构

 云计算将促使运营商的IT技术架构将从分散、独立、非标准的IT系统转变为集中、共享、标准的云服务

IDC未来

 Elasticsearch更名为Elastic后，Kibana、Sense等一大票工具不再免费了 (具体价格可以参见 -Subscriptions)，让人有点伤心。呵呵，毕竟是个好项目，人家也要挣钱去养家糊口，希望之后的版本能够更稳定，特别是在系统升级的稳定性方面。最近刚将生产环境由1.2.2升级到 1.5.2，相对上一次1.1.1到1.2.2，这次总体还是平稳的，但还是有些意料之外的问题 - checksum check。

       Elasticsearch是构建在Java之上的、开源的、分布式搜索和分析引擎，因此JVM的性能对Elasticsearch性能至关重要。在负载超出节点所能承受的情况下，JVM垃圾内存回收的“Stop-The-World”会造成节点被踢出Elasticsearch集群。如果只是偶尔发生，Elasticsearch的冗余设计可以克服（如: Replica # = 1）。但如果是经常出现节点被踢出的情况，则会对整个集群的稳定造成很致命的影响，很可能会造成数据的丢失，这就需要认真排查一下节点被踢出的原因。
       如果是因为JVM的“Stop-The-World”造成的，则在Elasticsearch的日志中一定可以看到[monitor.jvm ]日志。根据程度不同，它分为 INFO, WARN和DEBUG。下面是一些笔者遇到过的例子：

Example 1

[2016-01-11 14:09:52,783][INFO ][monitor.jvm             ] [ES-DIAG2-16-data] [gc][young][3402090][244044] duration [887ms],collections [1]/[1.5s], total [887ms]/[3.3h], memory [4.5gb]->[4gb]/[6.9gb],all_pools {[young] [499.4mb]->[782.8kb]/[532.5mb]}{[survivor][32.7mb]->[30.2mb]/[66.5mb]}{[old] [3.9gb]->[3.9gb]/[6.3gb]}

上面这个例子的情况无须紧张，只是young gc，并且只用了887ms，对于Elasticsearch而言，没有啥影响。唯一需要留心的是，如果在日志中出现连续的和长时间的young gc，则需要引起警觉，可能是你的Heap内存分配不够。

Example 2

[2016-01-11 15:54:14,630][WARN][monitor.jvm             ] [ES-DIAG-35-data] [gc][old][76581][22] duration [3.1m], collections[2]/[3.1m], total [3.1m]/[3.1m], memory [3gb]->[1.2gb]/[3.4gb], all_pools{[young] [251mb]->[74.9mb]/[266.2mb]}{[survivor][25.8mb]->[0b]/[33.2mb]}{[old] [2.8gb]->[1.1gb]/[3.1gb]}

如果这种JVM出现，则你的节点一定被踢出了集群。old gc是比较耗时，上面这个例子用了3.1分钟，一定是出了啥大事，要不是然“世界”不会停转这么久的，呵呵！

Example 3

[2016-01-11 17:33:33,287][WARN][monitor.jvm             ] [ES-DIAG-X-master] [gc][old][160117][1326] duration [41.4s], collections [2]/[42.4s],total [41.4s]/[4.7h], memory [3.4gb]->[3.4gb]/[3.4gb], all_pools {[young][266.2mb]->[266.2mb]/[266.2mb]}{[survivor][33.2mb]->[33.2mb]/[33.2mb]}{[old] [3.1gb]->[3.1gb]/[3.1gb]}

       这个例子相对于例-2而言更为严重，虽然old gc只让“世界”停了41.4秒，但gc之后，young，survivor和old都已经没有有可用的内存空间了。这种情况发生时，你会看到日志中满满的都是这样的日志，也一定会有 "java.lang.OutOfMemoryError: Java heap space"相伴。你摊上事儿了，摊上大事儿了，呵呵！
 
       一般情况下造成JVM "Stop-The-World"的原因是由于heap内存分配不够，适当的增加内存可以解决问题。当然也不是heap内存越大越好，32GB是个极限，超过这个极限性能反而会下降，具体请参阅Limiting Memory Usage 和 Heap: Sizing and Swapping。

       此外，造成JVM "Stop-The-World"的原因也是多方面的，没有包治百病的神药，需要去分析和测试实际生产环境下Elasticsearch集群的负载和配置。Elasticsearch已经提供了很多内部参数帮助我们了解系统节点的运行情况，建议大家好好阅读Monitoring Individual Nodes 这篇文档，了解这些参数的意义。Six Ways to Crash Elasticsearch 也给出一些可以让Elasticsearch崩溃的例子。

分享原文：http://blog.csdn.net/quicknet/article/details/45148447
参考：http://jprante.github.io/2012/11/28/Elasticsearch-Java-Virtual-Machine-settings-explained.html

什么是服务器

简单的说,服务器就是在网络中为其他客户机提供服务的计算机

服务器是计算机的一种，它是在网络操作系统的控制下为网络环境里的客户机提供(如PC) 共享资源（包括查询、存储、计算等）的高性能计算机，它的高性能主要体现在高速度的CPU 运算能力、长时间的可靠运行、强大的I/O 外部数据吞吐能力等方面。

 

服务器主要为客户机提供Web 应用、数据库、文件、打印服务。

服务器分类

按处理器架构分类 ：

[] 巨型机与大型机（专用处理器）[/][] 小型机（IA-64,RISC处理器）[/][] PC服务器（CISC处理器）[/]

 

服务器基础知识之CPU

处理器是服务器工作的核心部件，对于双路和多路服务器来说，升级处理器对于服务器性能的提高非常重要。32-位处理器 （CISC）

[]广阔的兼容性 [/][]64位数据总线[/][]32位地址总线[/]

64-位处理器 （IA-64,RISC)

[]支持大容量内存[/][]64位数据总线[/][]64位地址总线[/][]需要 64位操作系统 [/]

PC服务器分类

按CPU个数来分:

[]4路及4路以上服务器（企业级服务器）[/][]2路服务器（部门级服务器）[/][]1路服务器（入门级服务器）[/]

 

内存错误和防止出现内存错误的方法 

[]单位 (1位数据错误)[/][]多位 (超过1位数据错)[/][]硬件错 – 数据错误反复出现，即使在“擦除”错误以后  (来自:DRAM, DIMM插槽, 或控制器中的物理错误)[/][]软错误 – 在“擦除”错误以后 出现的数据错误(来自:由于高度活动的粒子产生断断续续的错误）[/]

[]先进的测试方法可以提高内存的可靠性 [/][]错误检查/纠正技术 [/][]ECC 内存 [/][]多位ECC内存 [/]

存储的演变

磁盘

常见的磁盘种类：

[]Serial ATA (SATA)磁盘[/][]Serial Attached SCSI (SAS)磁盘[/][]SSD 磁盘[/]

磁盘主要参数：

[]磁盘尺寸：3.5”/2.5”/1.8”[/][]磁盘容量：146GB/300GB/500GB…[/][]磁盘转速：10K/15K/7200[/][]是否支持热插拔[/][]平均无故障时间（MTBF）[/][]内外部传输速率[/][]平均寻道时间 [/][]IOPS[/]

传输率对比

机架式服务器

 

Raid基本概念

RAID （Redundant Array of Independent Disks）即独立磁盘冗余阵列，RAID技术将多个单独的物理硬盘以不同的方式组合成一个逻辑硬盘，从而达到提升存储容量、读写性能和数据安全性的目的。根据不同的组合方式可以分为不同的RAID级别

Raid出现原因

RAID 0 条带存储(Striping) 

RAID 1 镜像/双工 

RAID 5 (条带技术+分布式校验)

 

Raid级别比较

其中RAID3与RAID5的区别为：RAID3更适合于顺序存取，RAID5更适合于随机存取。需要根据具体的应用情况决定使用那种RAID级别。

RAID性能比较

存储体系架构介绍 

[] Direct Attached Storage(DAS)直接外挂存储 [/]

                      服务器直接后挂存储设备，最经济的一种结构。 

[] Network Attached Storage (NAS)网络连接存储 [/]

                     网络上直接挂接的存储设备，相当于一个网络文件共享服务器。 

[] Storage Area Network (SAN)存储区域网络应用光纤技术的SAN网络，传输介质为光纤，性能最高，目前使用较广  [/][]ISCSI(IP-SAN)[/]

                     iSCSI-利用TCP/IP协议连接存储设备,可以理解为SCSI over IP,是将SCSI命令封装到TCP/IP数据包中,通过IP网络传输SCSI数据。DAS

[]优点:  成本低，对于小型用户来说，易于维护[/][]缺点:  性能不高，系统停机多，资源无法共享，多系统环境下的管理成本增加[/]

NAS

[]优点:  方便，文件级的数据共享，集中化管理[/][]缺点:  需要贡献文件系统，安全性无法保障，性能一般，磁盘级数据无法共享／集中，复杂系统的成本大，维护难，扩容受限[/]

SAN

[]优点:  集中化的管理，高性能，减少停机时间，安全保障高[/][]缺点:  成本昂贵、系统复杂。磁盘阵列的兼容性限制了设备选择空间及资源共享。[/]

DAS、NAS、SAN与ISCSI性能比较

数据封装的图示

数据封装的例子 

基本网络设备

根据网络设备作用在OSI的层次，有以下几种类型:

[]第1层（物理层）                中继器  HUB[/][]第2层（数据链路层）        网桥  交换机[/][]第3层（网络层）                路由器[/]

 

交换机Switch/网卡

交换机是OSI模型的第二层设备,在OSI参考模型的数据链路层（第二层）工作，交换机根据进入端口数据帧的MAC地址来过滤、转发或扩散该数据帧。

提供计算机与计算机网络的数据传输,也称为网络适配器(LAN Adapter),集成在主板上，或插在主板的扩展槽中,可以是以太网卡、令牌环网卡或FDDI网卡

路由器Router

路由器在网络间传送基于网络层或者说第三层信息的的数据分组

路由器能够对智能判定数据在网络上传送的最佳路径

交换机和路由器的区别

[list=1][]工作层次不同;[/][]数据转发所依据的对象不同;[/][]是否可以分割广播域;[/][]路由器提供了防火墙的服务.[/]

传输介质

传输介质是网络中信息传递的载体。传输介质的性能直接影响网络的运行。网络常用的传输介质有同轴电缆、双绞线、光缆等。在这三种传输介质中，双绞线被广泛应用于电话系统中，它的性能较差，但价格也比较低；同轴电缆在有线电视系统中经常采用，它的性能较好，价格适中；光纤则是最先进的通信线路，它的各项性能指标都非常好，但成本很高而且连接起来有一定的难度。 

“该给ES分配多少内存？” 
“JVM参数如何优化?“
“为何我的Heap占用这么高？”
“为何经常有某个field的数据量超出内存限制的异常？“
“为何感觉上没多少数据，也会经常Out Of Memory？”

以上问题，显然没有一个统一的数学公式能够给出答案。 和数据库类似，ES对于内存的消耗，和很多因素相关，诸如数据总量、mapping设置、查询方式、查询频度等等。默认的设置虽开箱即用，但不能适用每一种使用场景。作为ES的开发、运维人员，如果不了解ES对内存使用的一些基本原理，就很难针对特有的应用场景，有效的测试、规划和管理集群，从而踩到各种坑，被各种问题挫败。

要理解ES如何使用内存，先要尊重下面两个基本事实:

1.  ES是JAVA应用
2.  底层存储引擎是基于Lucene的

看似很普通是吗？但其实没多少人真正理解这意味着什么。 

首先，作为一个JAVA应用，就脱离不开JVM和GC。很多人上手ES的时候，对GC一点概念都没有就去网上抄各种JVM“优化”参数，却仍然被heap不够用，内存溢出这样的问题搞得焦头烂额。了解JVM GC的概念和基本工作机制是很有必要的，本文不在此做过多探讨，读者可以自行Google相关资料进行学习。如何知道ES heap是否真的有压力了？ 推荐阅读这篇博客：Understanding Memory Pressure Indicator。 即使对于JVM GC机制不够熟悉，头脑里还是需要有这么一个基本概念: 应用层面生成大量长生命周期的对象，是给heap造成压力的主要原因，例如读取一大片数据在内存中进行排序，或者在heap内部建cache缓存大量数据。如果GC释放的空间有限，而应用层面持续大量申请新对象，GC频度就开始上升，同时会消耗掉很多CPU时间。严重时可能恶性循环，导致整个集群停工。因此在使用ES的过程中，要知道哪些设置和操作容易造成以上问题，有针对性的予以规避。

其次，Lucene的倒排索引(Inverted Index)是先在内存里生成，然后定期以段文件(segment file)的形式刷到磁盘的。每个段实际就是一个完整的倒排索引，并且一旦写到磁盘上就不会做修改。 API层面的文档更新和删除实际上是增量写入的一种特殊文档，会保存在新的段里。不变的段文件易于被操作系统cache，热数据几乎等效于内存访问。 
 
基于以上2个基本事实，我们不难理解，为何官方建议的heap size不要超过系统可用内存的一半。heap以外的内存并不会被浪费，操作系统会很开心的利用他们来cache被用读取过的段文件。

Heap分配多少合适？遵从官方建议就没错。 不要超过系统可用内存的一半，并且不要超过32GB。JVM参数呢？
对于初级用户来说，并不需要做特别调整，仍然遵从官方的建议，将xms和xmx设置成和heap一样大小，避免动态分配heap size就好了。虽然有针对性的调整JVM参数可以带来些许GC效率的提升，当有一些“坏”用例的时候，这些调整并不会有什么魔法效果帮你减轻heap压力，甚至可能让问题更糟糕。

那么，ES的heap是如何被瓜分掉的? 说几个我知道的内存消耗大户并分别做解读:

[] segment memory[/][]  filter cache[/][]  field data cache[/][]  bulk queue[/][]  indexing buffer[/][]  state buffer[/][]  超大搜索聚合结果集的fetch[/]

Segment Memory

Segment不是file吗？segment memory又是什么？前面提到过，一个segment是一个完备的lucene倒排索引，而倒排索引是通过词典 (Term Dictionary)到文档列表(Postings List)的映射关系，快速做查询的。 由于词典的size会很大，全部装载到heap里不现实，因此Lucene为词典做了一层前缀索引(Term Index)，这个索引在Lucene4.0以后采用的数据结构是FST (Finite State Transducer)。 这种数据结构占用空间很小，Lucene打开索引的时候将其全量装载到内存中，加快磁盘上词典查询速度的同时减少随机磁盘访问次数。
 
下面是词典索引和词典主存储之间的一个对应关系图:

Lucene  file的完整数据结构参见Apache Lucene - Index File Formats
 
说了这么多，要传达的一个意思就是，ES的data node存储数据并非只是耗费磁盘空间的，为了加速数据的访问，每个segment都有会一些索引数据驻留在heap里。因此segment越多，瓜分掉的heap也越多，并且这部分heap是无法被GC掉的！ 理解这点对于监控和管理集群容量很重要，当一个node的segment memory占用过多的时候，就需要考虑删除、归档数据，或者扩容了。

怎么知道segment memory占用情况呢?  CAT API可以给出答案。

1.  查看一个索引所有segment的memory占用情况:

 

1.  查看一个node上所有segment占用的memory总和:

那么有哪些途径减少data node上的segment memory占用呢？ 总结起来有三种方法:

1.  删除不用的索引
2.  关闭索引 （文件仍然存在于磁盘，只是释放掉内存）。需要的时候可以重新打开。
3.  定期对不再更新的索引做optimize (ES2.0以后更改为force merge api)。这Optimze的实质是对segment file强制做合并，可以节省大量的segment memory。

Filter Cache

Filter cache是用来缓存使用过的filter的结果集的，需要注意的是这个缓存也是常驻heap，无法GC的。我的经验是默认的10% heap设置工作得够好了，如果实际使用中heap没什么压力的情况下，才考虑加大这个设置。

Field Data cache

在有大量排序、数据聚合的应用场景，可以说field data cache是性能和稳定性的杀手。 对搜索结果做排序或者聚合操作，需要将倒排索引里的数据进行解析，然后进行一次倒排。 这个过程非常耗费时间，因此ES 2.0以前的版本主要依赖这个cache缓存已经计算过的数据，提升性能。但是由于heap空间有限，当遇到用户对海量数据做计算的时候，就很容易导致heap吃紧，集群频繁GC，根本无法完成计算过程。 ES2.0以后，正式默认启用Doc Values特性(1.x需要手动更改mapping开启)，将field data在indexing time构建在磁盘上，经过一系列优化，可以达到比之前采用field data cache机制更好的性能。因此需要限制对field data cache的使用，最好是完全不用，可以极大释放heap压力。 需要注意的是，很多同学已经升级到ES2.0，或者1.0里已经设置mapping启用了doc values，在kibana里仍然会遇到问题。 这里一个陷阱就在于kibana的table panel可以对所有字段排序。 设想如果有一个字段是analyzed过的，而用户去点击对应字段的排序表头是什么后果？ 一来排序的结果并不是用户想要的，排序的对象实际是词典； 二来analyzed过的字段无法利用doc values，需要装载到field data cache，数据量很大的情况下可能集群就在忙着GC或者根本出不来结果。

Bulk Queue

一般来说，Bulk queue不会消耗很多的heap，但是见过一些用户为了提高bulk的速度，客户端设置了很大的并发量，并且将bulk Queue设置到不可思议的大，比如好几千。 Bulk Queue是做什么用的？当所有的bulk thread都在忙，无法响应新的bulk request的时候，将request在内存里排列起来，然后慢慢清掉。 这在应对短暂的请求爆发的时候有用，但是如果集群本身索引速度一直跟不上，设置的好几千的queue都满了会是什么状况呢？ 取决于一个bulk的数据量大小，乘上queue的大小，heap很有可能就不够用，内存溢出了。一般来说官方默认的thread pool设置已经能很好的工作了，建议不要随意去“调优”相关的设置，很多时候都是适得其反的效果。

Indexing Buffer

Indexing Buffer是用来缓存新数据，当其满了或者refresh/flush interval到了，就会以segment file的形式写入到磁盘。 这个参数的默认值是10% heap size。根据经验，这个默认值也能够很好的工作，应对很大的索引吞吐量。 但有些用户认为这个buffer越大吞吐量越高，因此见过有用户将其设置为40%的。到了极端的情况，写入速度很高的时候，40%都被占用，导致OOM。

Cluster State Buffer

ES被设计成每个node都可以响应用户的api请求，因此每个node的内存里都包含有一份集群状态的拷贝。这个cluster state包含诸如集群有多少个node，多少个index，每个index的mapping是什么？有少shard，每个shard的分配情况等等 (ES有各类stats api获取这类数据)。 在一个规模很大的集群，这个状态信息可能会非常大的，耗用的内存空间就不可忽视了。并且在ES2.0之前的版本，state的更新是由master node做完以后全量散播到其他结点的。 频繁的状态更新都有可能给heap带来压力。 在超大规模集群的情况下，可以考虑分集群并通过tribe node连接做到对用户api的透明，这样可以保证每个集群里的state信息不会膨胀得过大。

超大搜索聚合结果集的fetch

ES是分布式搜索引擎，搜索和聚合计算除了在各个data node并行计算以外，还需要将结果返回给汇总节点进行汇总和排序后再返回。无论是搜索，还是聚合，如果返回结果的size设置过大，都会给heap造成很大的压力，特别是数据汇聚节点。超大的size多数情况下都是用户用例不对，比如本来是想计算cardinality，却用了terms aggregation + size:0这样的方式; 对大结果集做深度分页；一次性拉取全量数据等等。

小结

1.  倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment memory增长趋势。
2.  各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采用clear cache等“自欺欺人”的方式来释放内存。
3.  避免返回大量结果集的搜索与聚合。缺失需要大量拉取数据可以采用scan & scroll api来实现。
4.  cluster stats驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过tribe node连接。
5.  想知道heap够不够，必须结合实际应用场景，并对集群的heap使用情况做持续的监控。

分享阅读原文：http://elasticsearch.cn/article/32