OTPUB直播活动又双叒叕来喽！

直播主题

Excel的“天上人间”-“出台”到PPT的动态图表

直播时间

2017年4月25日 14:00-15:00
点击报名观看>>>


发展才是硬道理，企业中的各种制度目的终为了企业发展。在过去，我们总是在强调制度，由于企业是一个复杂的系统，企业的管理制度也必然是一个复杂的系统。任何一个制度的实施，都有可能由于相关方面制度的不完善或缺失而造成负面的影响。因此管理制度本身应该是完善的，涵盖企业管理系统的方方面面，并且随着企业内外环境的变化，不断地加以补充、修订和加强。
企业级管理及项目管理软件的发展趋势
经过数年的发展建设，企业信息化从部门级初步应用如办公、财务、人力等进入流程为中心的一体化管理模式，为提升企业管理效率的企业级。移动互联网、云计算发展迅速，企业管理在技术上也推行革新。很多企业借助科技发展带来的便利，随着大数据、商业智能、云计算这些技术而来，企业管理软件发展是这样的…
1、 一体化管理模式。企业管理系统是新的工作管理方式。互联网企业对软件、硬件、数据、计算等资源需求强烈。智能化的管理提供更多机会，相比传统的企业管理方案，一体化管理带来更完整的架构。
2、移动办公成主流。智能手机推动移动办公，手机、平板灯设备记录工作、管理工作流程越来越常见，经常外出的工作人员就可以方便使用。
3、个性化的管理定制。随着市场的发展变化，企业对管理方式的智能和个性化需求也凸显出来。根据不同的管理要求，可以通过自主灵活的定制功能来解决难题。
智能化企业管理服务的发展，让企业能够具备更快速的反应能力、打造更简洁的业务流程，强化了企业应对复杂环境的核心竞争力。而一体化管理模式将促进企业管理生态的形成和发展，通过一个系统能够快速调动各资源彼此配合，形成网状的交互生态圈，信息的实时共享大大提升了数据的安全性和可控度，为企业的信息化提供强有力的支撑。
关于项目管理软件
如今，项目管理备受重视，原因是项目管理在运筹与协同方面的方式方法恰好填充了其它管理体系或管理系统这方面的相对弱项；PMI的PMBOK或IPMA的ICB等关于项目管理的理论体系日臻完善，并在全球范围内展开几近商业性质的普及推广；项目管理软件软件功能及演绎理论能力的不断提高，使项目管理从理论走向实际实施进而发挥效益成为现实；引导企业管理风向标的跨国公司纷纷开始在企业中采用项目管理技术和项目管理解决方案，初步形成了企业项目管理化的局面。
随着越来越多的企业或组织对项目管理方法和技术的引入，以及大家对项目管理理解的深入，因此未来的项目管理软件市场的发展是机遇和挑战同时并存的。 用户的需求对于未来的企业级项目管理软件所采用技术也提出了更高的要求，如大数据量存储、大用户量并发访问、企业多分支机构的支持、大用户量的系统维护、系统的可扩展性/可集成性/可定制性等等。
由于国内项目管理软件开发起步较晚，涉足开发企业级项目管理软件的企业也微乎其微，目前国内企业级项目管理软件高端市场几乎由国外厂商垄断。
未来，企业级项目管理软件发展将会：1、通用型项目管理解决方案；2、IT项目管理解决方案；3、大核心功能实现度解决方案…,如今市场前景比较广阔，产品的先进性是重要的，但是满足不同层次客户的需求也是及其重要的。伴随着项目管理在中国的迅猛发展，客户对项目管理的理性认识，以及项目管理软件厂商对项目管理先进理念和方法的倡导，谁会是最后的赢家?是厂商、是客户、还是专业的咨询/服务公司？请拭目以待... 收起阅读 »

如果生产环境，可以利用heartbeta或者keepalived作高可用，下面介绍一下nfs服务安装过程。
 

一、安装环境

NFS服务器：CentOS6.5 192.168.0.10
NFS客户端：CentOS6.5 192.168.0.11
 

二、服务器端安装配置​

1、先用rpm -qa命令查看所需安装包（nfs-utils、rpcbind）是否已经安装：

[root@local /]# rpm -qa | grep "rpcbind"

rpcbind-0.2.0-11.el6.x86_64

[root@local /]# rpm -qa | grep "nfs"

nfs-utils-1.2.3-39.el6.x86_64

nfs4-acl-tools-0.3.3-6.el6.x86_64

nfs-utils-lib-1.1.5-6.el6.x86_64

2、如查询结果如上，说明服务器自身已经安装了NFS，如果没有安装，则用yum命令来安装：

[root@local /]# yum -y install nfs-utils rpcbind

3、创建共享目录：

[root@local /]# mkdir /sharestore

4、NFS共享文件路径配置：
编辑/etc/exports添加下面一行，添加后保存退出。
 

[root@local /]# vi /etc/exports

/sharestore     *(rw,sync,no_root_squash)

/sharestore   10.10.0.0/8(rw,sync,no_subtree_check,anonuid=48,anongid=48)

你也可以指定可以访问网段和用户id。
 
5、启动NFS服务（先启动rpcbind，再启动nfs；如果服务器自身已经安装过NFS，那就用restart重启两个服务）：

[root@local /]# service rpcbind start

Starting rpcbind:                                          [  OK  ]

[root@local /]# service nfs start

Starting NFS services:                                     [  OK  ]

Starting NFS quotas:                                       [  OK  ]

Starting NFS mountd:                                       [  OK  ]

Stopping RPC idmapd:                                       [  OK  ]

Starting RPC idmapd:                                       [  OK  ]

Starting NFS daemon:                                       [  OK  ]

[root@local /]#

6、设置NFS服务开机自启动：

[root@local /]# chkconfig rpcbind on

[root@local /]# chkconfig nfs on

三、客户端挂载配置

1、创建一个挂载点：
 

[root@localhost ~]# mkdir /mnt/store

2、查看NFS服务器上的共享：

[root@localhost /]# showmount -e 192.168.0.10

Export list for 192.168.0.10:

/sharestore *

3、挂载：

[root@localhost ~]# mount -t nfs 192.168.0.10:/sharestore /mnt/store

4、查看已挂载共享：

[root@localhost ~]# mount

/dev/mapper/VolGroup-lv_root on / type ext4 (rw)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw)

devpts on /dev/pts type devpts (rw,gid=5,mode=620)

tmpfs on /dev/shm type tmpfs (rw)

/dev/sda1 on /boot type ext4 (rw)

/dev/mapper/VolGroup-lv_home on /home type ext4 (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

nfsd on /proc/fs/nfsd type nfsd (rw)

192.168.0.10:/mailstore1/ on /mailstore_new type nfs (rw,vers=4,addr=192.168.0.10,clientaddr=192.168.0.11)

收起阅读 »

有时候云上部署环境，不能动态自设路由，没有公网ip地址的服务器，只能通过NAT的方式出外网，下面就记录一下设置过程。

当前状态

服务器A只有一个内网IP，不能上外网，内网IP与服务器B内网相通；服务器B有一个内网IP和公网IP。想实现服务器A也能上外网。

服务器A：内网网卡：eth0  内网IP：192.168.0.10

 

服务器B：内网网卡：eth0  内网IP：192.168.0.20

        外网网卡：eth1  外网IP：203.195.32.138

实现方法

1、在可以上外网的服务器B上，开启路由转发功能

echo 1 > /proc/sys/net/ipv4/ip_forward

注：上面命令在服务器重启之后会失效，可以编辑/etc/rc.d/rc.local把上面命令添加到最底部，实现开启自动执行。
 
或者进行如下操作：

编辑/etc/sysctl.conf

找到net.ipv4.ip_forward = 0 修改为 net.ipv4.ip_forward = 1 最后保存。

 

执行sysctl -p命令使配置生效：

# sysctl -p

2、在可以上外网的服务器B上执行添加SNAT规则

# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.10 -j SNAT --to 203.195.32.138

如果想让整个网段都通过服务器B上外网，修改上面规则命令中-s 192.168.0.10为-s 192.168.0.0/24，然后把想上外网的服务器默认网关改成192.168.0.20就可以了。
 
3、保存刚添加的iptables规则

# service iptables save

4、在需要上外网的服务器A上，修改内网网卡eth0的默认网关为192.168.0.20

# route add default gw 192.168.0.20

修改后，查看路由表，确认已修改成功，测试已经可以上外网了

# route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0

0.0.0.0         192.168.0.20    0.0.0.0         UG    0      0        0 eth0

测试你ping一下baidu.com 就好。 收起阅读 »

云计算解决方案可让企业快速部署服务以及降低总体拥有成本，这也是为什么首席信息官(CIO)转向软件即服务(SaaS)来提供有效高效服务的原因。
然而，尽管云计算解决方案有很多优势，但企业还必须考虑部署SaaS的安全影响。成功云计算转型的关键是在转移到SaaS解决方案时使用适当的安全控制。
部署SaaS最佳做法
部署SaaS并不会自动保证整体基础设施的安全性，企业应该查看需要保护的服务的安全控制情况。例如，你必须了解针对客户关系管理(CRM)解决方案的攻击的特定后果。同时，你必须确保你的安全信息和事件管理(SIEM)解决方案能够从这个CRM中收集数据。
同样重要的是管理联合身份，因为很多SaaS解决方案要求不同类型的身份验证。强迫用户输入多个密码并不足以构建正确的安全文化。
IT经理通常会基于不现实的战略决策来决定是否部署云计算交付模型。但如果公司决定不允许其员工利用云计算服务，可能为时已晚。云计算服务已经在企业功能中使用，例如很多库使用云端应用程序接口(API)，而员工早就开始使用云应用。
复杂的生态系统
云应用的生命周期必须包含动态安全分析，这些应用是复杂生态系统的一部分。它们可能今天很安全，第二天就布满漏洞，这主要取决于生态系统的状态。
企业应该专注于向服务安装安全控制，确保部署这些控制的技术不会依靠交付模型。否则，你可能会被迫部署不是基于战略决策的技术和业务模型，只是为了挽救以前的投资。为内部部署和云服务提供相同的安全控制是良好安全策略的关键因素。
SaaS提供商的责任
应用是恶意攻击者执行网络攻击的窗口，因此，安全应该成为这些应用开发周期的一部分。SaaS提供商需要不断测试他们的产品，并根据安全响应专家制定的流程和最佳做法对漏洞作出响应。
供应商还应该在非常坚实的基础设施即服务(IaaS)以及平台即服务(PaaS)上提供SaaS，最后，SaaS提供商还必须遵守隐私和数据管理法规。
OTPUB直播活动又双叒叕来喽！

直播主题

Excel的“天上人间”-“出台”到PPT的动态图表

直播时间

2017年4月25日 14:00-15:00

点击参与报名>>>
http://www.otpub.com/special/Excel0425/excel0425_baoming.html 收起阅读 »

最近我们的服务进程遇到kill -15后处于Z的状态，变为了僵尸进程，经过/proc/{thread_id}/stack查看其上线程的栈，发现是卡在了fwrite的过程中，而我们的系统中所有文件系统挂载参数都使用了delalloc参数，怀疑是这个原因：ext4挂载的时候打开了delalloc选项，然后系统在没有分配磁盘块的情况下写写写，到page cache被回写到磁盘时，发现磁盘已经满了，没办法分配新的磁盘块了，就Hang住了。
 
这篇文章是淘宝内核组的刘峥同学在内部技术论坛上发表的一篇文章，但是由于刘峥同学目前没有blog，征得本人同意，贴在我的blog上，如果大家喜欢，请去新浪微博关注他。:)
 
日前线上在升级到Ext4文件系统后出现应用写操作延迟开销增大的问题。造成这一问题的根源目前已经查明，是由于Ext4文件系统的一个新特性——Delay Allocation造成的。（后面简称delalloc）

在详细分析这一问题之前，先来介绍一下Ext4文件系统的delalloc特性。这一特性简要概括起来就是将以前在buffer IO中每次写操作都会涉及的磁盘块分配过程推迟到数据回写时再进行。我们知道，在进行Buffer Write时，系统的实际操作仅仅是为这些数据在操作系统内分配内存页（page cache）并保存这些数据，等待用户调用fsync等操作强制刷新或者等待系统触发定时回写过程。在数据拷贝到page cache这一过程中，系统会为这些数据在磁盘上分配对应的磁盘块。

而在使用delalloc后，上面的流程会略有不同，在每次Buffer Write时，数据会被保存到page cache中，但是系统并不会为这些数据分配相应的磁盘块，仅仅会查询是否有已经为这些数据分配过磁盘块，以便决定后面是否需要为这些数据分配磁盘块。在用户调用fsync或者系统触发回写过程时，系统会尝试为标记需要分配磁盘块的这些数据分配磁盘块。这样，文件系统可以为这些属于同一个文件的数据分配尽量连续的磁盘空间，从而优化后续文件的访问性能（因为传统机械硬盘顺序读写的性能要比随机读写好很多）。

了解完delalloc特性的工作过程后，我们开始分析线上遇到的问题。线上应用的I/O模式可以简化为一个单线程追加写操作的程序，每秒写入2、3M数据，写操作后等待系统自动将数据回写到磁盘。在使用delalloc后，每次Buffer Write操作，系统都会去查询数据是否分配了磁盘块，这一过程需要获得一把读锁 (i_data_sem)。由于这时还没有触发回写操作，因此可以顺利获取i_data_sem，系统完成数据拷贝工作，并返回。由于仅仅是内存拷贝的过程，所以这一操作速度相当快。当系统开始进行回写操作时，系统会成批为数据分配磁盘块，这一过程同样需要获取i_data_sem，并且需要加写锁​以保证数据的一致性。由于使用delalloc后，需要分配的磁盘块比nodelalloc情况下多很多（nodelalloc情况下每5秒文件系统会提交日志触发回写；delalloc情况下，系统会在约每30秒左右触发一次回写），因此这一延迟时间较长。如果这时应用程序进行一次Buffer Write，则该操作在尝试获得i_data_sem时会等待上述磁盘块分配完成。由此造成写操作等待很长时间，从而影响应用程序的响应延迟。

在上面的分析中已经提到，delalloc是将多次磁盘块分配的过程合并到一次中来进行，那么是否真如预想的那样，delalloc的平均延迟会小于nodelalloc的情况呢？我们使用fio来做如下测试：设置bs=4k，单线程每秒追加写入5M，程序运行3分钟，我们来看一下最后fio对延迟的统计结果：

delalloc:

lat (usec): min=2 , max=193466 , avg= 5.86, stdev=227.91



nodelalloc:

lat (usec): min=3 , max=16388 , avg= 7.00, stdev=28.92

从上面的统计结果看，写操作的平均延迟：打开delalloc后为5.86us，关闭delalloc后为7.00us；最小延迟delalloc为2us，nodelalloc为3us；但是最大延迟delalloc为193.466ms，nodelalloc下仅为16.388ms。可见delalloc确实将多个写操作请求集中到了一起来进行。因此在提供较低平均延迟的情况下，会造成某次写操作的延迟较大。

通过上面的分析可以看到，目前会受到Ext4的delalloc特性影响的应用必须具备如下条件：

1. Buffer IO
2. 写操作过程中会涉及磁盘块的分配，主要是记录日志这类追加写操作；
3. 每次写操作后没有刷新数据，而是等待系统自动进行回写；
4. 对延迟有较高要求。

 
解决方法：关闭delalloc

1、mount -t ext4 -o remount,nodelalloc /${dev} /${mnt};

2、编辑/etc/fstab中相关mount项，添加nodelalloc挂载参数

分享原文：http://www.cnblogs.com/cobbliu/p/5603472.html  

收起阅读 »

根据IDC全球季度云计算IT基础架构的最新预测，IT基础架构产品(服务器，企业存储和以太网交换机)的总支出用于部署在云环境中的支出，2017年将同比增长15.3%至417亿美元。公有云数据中心占这一支出的大部分，占60.5%，而私有云环境将占支出的14.9%。本地私有云将占私有云IT基础设施支出的62.3%，并将在2017年同比增长13.1%。
2017年公有云基础设施支出超过私有云
云计算IT基础设施投资将在所有地区增加，而大多数地区预计在所有三个技术领域的非云部署支出将会减少。总体而言，全球在传统的非云计算IT基础架构上的支出将在2017年下降5.3%。然而，它仍将占最终用户支出的最大份额，占比57.9%。
在云环境中，以太网交换机将是增长最快的技术部门，2017年同比增长21.8%，而服务器和企业存储上的支出分别增长17.9%和10.7%。在持续采用基于服务器和软件定义的存储解决方案的过程中，外部存储部门的薄弱环节是企业存储支出放缓的一个重要因素。在所有这三个部分中，部署在场外的IT基础设施的支出将比在内部部署环境中的支出增长得快。
长期来看，IDC预计，外部部署云计算IT支出将以5年复合增长率(CAGR)增长11.7%，到2021年达到472亿美元。公有云数据中心将占该数额的80.4%。与内部部署私有云相结合，云计算IT基础设施的总体支出将以年均11%的速度增长，到2020年将超过非云IT基础架构的支出。内部部署私有云IT基础架构的支出将以年均复合增长率10.3%，而在非云IT(内部和外部组合)的支出将在同期缩短3%的年均复合增长率。
 
OTPUB直播活动又双叒叕来喽！
直播主题
Excel的“天上人间”-“出台”到PPT的动态图表
直播时间
2017年4月25日 14:00-15:00
点击参与报名>>> 收起阅读 »

结合现在云计算和DevOps的发展趋势，我觉得一个成熟的自动化运维平台应该包括以下的特性：
一、支持混合云的CMDB​
现在越来越多的服务器都转到了云上，而主流的公有云、私有云平台都拥有比较完备的资源管理的API，这些API也就是构建一个自动化CMDB的基础。

新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。
通过API对资源的操作都应该被作为操作日志记录下来，以备作为后续操作审计的基础数据。

CMDB这个东西听上去是老生常谈，但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦，就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来，就意味着一旦要增加一台服务器，可能要在各个运维工具里面都要同步一下，这个还是非常折腾滴。

二、比较完备的监控+应用性能分析（APM）
能支持对平台的可用性、服务器的性能、各种服务（web服务、应用服务、数据库服务）的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。

现在市面上一般都会将资源性能监控和应用性能监控（APM）混合着讲，这里面的产品确实也有很多都是重叠的，两方面都会涉及到。

开源的性能监控系统主流有的Zabbix、Nagios，国产的开源监控平台有小米OpenFalcon，但这些基本都只是做基本的资源监控（服务器，磁盘、网络等）和简单的服务软件的性能监控（中间件，数据库等）。

而市面上的APM系统更主打的功能是应用性能分析，比如能精确定位到某个应用的URL的访问速度快慢，某些SQL执行速度的快慢，这些对于开发人员和运维人员快速定位问题还是很有帮助的。

APM这方面的商业工具，国外比较主流的有New Reclic、Dynatrace，国内的也就是透视宝、Oneapm、听云等，他们也提供了API进行集成。

APM这方面的开源工具有pinpoint（一个韩国团队开源的），zipkin（twitter开源），cat（大众点评开源）。
 
三、有一个还不错UI的批量运维工具
在业务发展比较快的情况下，从几台服务器，到几十台服务器，再到几百台服务器，批量运维的需求很自然就产生了，老板也希望越少的人干越多的活。

现在也有不少开源的批量运维工具，也都比较成熟了，比如puppet、chef、ansible、saltstack。
puppet和chef都是ruby做的，实话实说，ruby的熟手市面上很少，比python不是难招一点。

我个人比较推荐使用ansible或者saltstack，这两个系统都是python写的，代码质量和社区活跃度都挺不错的。
ansible有官方的web ui——Tower，但实话实说不好用，所以我们也在重新做一套自己用起来更顺手的WEB UI。
 
四、日志集中分析工具
线上系统最常规的问题定位方式，就是日志分析了。
随着服务器的增多，日志的分析定位也成为一个难点和痛点（想象一下，系统出故障之后，要去几十甚至数百个节点去上去查日志，是有多折腾）。

国内有一家叫日志易的公司，是专门做日志分析方面的运维工具的。
另外还有一家log insight，也是做这个领域，但产品好像还处于beta阶段。

日志分析这个领域现在是一个热点，现在的开源方案也比较多了，比如著名的ELKStack，还有Flume+Kafka+Storm的体系。
上面这两个方案相对重一些，部署比较复杂，网上介绍的文章也不少。

比较轻量级的开源日志集中采集方案有python做的Sentry，他是通过改造各种语言的日志采集框架来实现日志的集中采集，各种主流的开发语言的日志框架都支持得很完整了，比如java的log4j和logpack。
 
Sentry的官网在此：Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js.
 
五、持续集成和发布工具
这方面其实比较难有统一的需求，很多公司集成发布的做法都差异挺大的。持续集成方面，一般用jekins的比较多，这方面网上介绍的文章也很多。

而如何把打好的包发布至各台服务器，则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节，包括了版本文件的上传、分发、版本管理、回滚等各种操作。

对于一般不太复杂的项目，我比较推荐的做法是把打包好的文件上传到svn or git上，然后通过脚本在各台服务器上进行发布操作就行了，这样其实是利用了SVN or GIT来完成文件的上传、分发、版本管理、回滚等各种操作。
 
六、安全漏洞扫描工具
现在一个稍微有点知名度的系统，都会遭受各种各样的安全攻击的折磨。

一般的公司不太可能请得起专职的安全工程师，所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。

安全工具方面我了解不多，不太熟这个领域的开源工具。
 
之前乌云网推出过一个SaaS化的漏扫平台——唐朝巡航，有对外提供漏洞扫描的API，不过最近乌云网一直在升级，所以也就暂时无法调用了。个人觉得，如果上述功能都有了，基本上大部分中小规模企业的日常运维工作的高频操作都覆盖到了。

如果是比较大的互联网企业，或者还有一些特殊的业务需求，那就具体问题具体分析了。
作者：刀把五
链接：https://www.zhihu.com/question/23228213/answer/116940889  
来源：知乎 收起阅读 »

一、日志设置

1、修改日志级别

config/log4j.properties中日志的级别设置的是TRACE，在长时间运行过程中产生的日志大小吓人，所以如果没有特殊需求，强烈建议将其更改成INFO级别。具体修改方法如下所示，将config/log4j.properties文件中最后的几行中的TRACE改成INFO，修改前如下所示：

log4j.logger.kafka.network.RequestChannel$=TRACE, requestAppender

log4j.additivity.kafka.network.RequestChannel$=false

#log4j.logger.kafka.network.Processor=TRACE, requestAppender

#log4j.logger.kafka.server.KafkaApis=TRACE, requestAppender

#log4j.additivity.kafka.server.KafkaApis=false

log4j.logger.kafka.request.logger=TRACE, requestAppender

log4j.additivity.kafka.request.logger=false

log4j.logger.kafka.controller=TRACE, controllerAppender

log4j.additivity.kafka.controller=false

log4j.logger.state.change.logger=TRACE, stateChangeAppender

log4j.additivity.state.change.logger=false

修改后如下所示：

log4j.logger.kafka.network.RequestChannel$=INFO, requestAppender

log4j.additivity.kafka.network.RequestChannel$=false

#log4j.logger.kafka.network.Processor=INFO, requestAppender

#log4j.logger.kafka.server.KafkaApis=INFO, requestAppender

#log4j.additivity.kafka.server.KafkaApis=false

log4j.logger.kafka.request.logger=INFO, requestAppender

log4j.additivity.kafka.request.logger=false

log4j.logger.kafka.controller=INFO, controllerAppender

log4j.additivity.kafka.controller=false

log4j.logger.state.change.logger=INFO, stateChangeAppender

log4j.additivity.state.change.logger=false

2、修改日志存放位置

还有就是默认Kafka运行的时候都会通过log4j打印很多日志文件，比如server.log, controller.log, state-change.log等，而都会将其输出到$KAFKA_HOME/logs目录下，这样很不利于线上运维，因为经常容易出现打爆文件系统，一般安装的盘都比较小，而数据和日志会指定打到另一个或多个更大空间的分区盘

具体方法是，打开$KAFKA_HOME/bin/kafka-run-class.sh，找到下面标示的位置，并定义一个变量，指定的值为系统日志输出路径，重启broker即可生效。

二、日志清理和策略

1、利用Kafka日志管理器

Kafka日志管理器允许定制删除策略。目前的策略是删除修改时间在N天之前的日志（按时间删除），也可以使用另外一个策略：保留最后的N GB数据的策略(按大小删除)。为了避免在删除时阻塞读操作，采用了copy-on-write形式的实现，删除操作进行时，读取操作的二分查找功能实际是在一个静态的快照副本上进行的，这类似于Java的CopyOnWriteArrayList。

Kafka消费日志删除思想：Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用

log.cleanup.policy=delete启用删除策略

直接删除，删除后的消息不可恢复。可配置以下两个策略：

清理超过指定时间清理： 

log.retention.hours=16

超过指定大小后，删除旧的消息：

log.retention.bytes=1073741824

2、压缩策略

将数据压缩，只保留每个key最后一个版本的数据。首先在broker的配置中设置log.cleaner.enable=true启用cleaner，这个默认是关闭的。在Topic的配置中设置log.cleanup.policy=compact启用压缩策略。

压缩策略的细节如下：

如上图，在整个数据流中，每个Key都有可能出现多次，压缩时将根据Key将消息聚合，只保留最后一次出现时的数据。这样，无论什么时候消费消息，都能拿到每个Key的最新版本的数据。

压缩后的offset可能是不连续的，比如上图中没有5和7，因为这些offset的消息被merge了，当从这些offset消费消息时，将会拿到比这个offset大的offset对应的消息，比如，当试图获取offset为5的消息时，实际上会拿到offset为6的消息，并从这个位置开始消费。

这种策略只适合特俗场景，比如消息的key是用户ID，消息体是用户的资料，通过这种压缩策略，整个消息集里就保存了所有用户最新的资料。

压缩策略支持删除，当某个Key的最新版本的消息没有内容时，这个Key将被删除，这也符合以上逻辑。

收起阅读 »

随着云计算、虚拟化等技术的飞速发展，数据中心向虚拟化、云存储已成大势，有专家预测，未来90%的大型企业、政府机构等都将使用虚拟化。在这一过程中，数据中心所面临的安全风险也在发生着演进与变化。虚拟化数据中心面临比传统数据中心更大的安全挑战。服务器虚拟化在带来种种好处的基础上也引入了新的安全威胁，如虚拟机之间的互相攻击，随时启动的防护间歇等。企业必须考虑各种潜在的威胁，然后才能迁移到云模型上。下面是几个企业应该注意的云安全问题：

谁有访问权限?
访问控制确实是一个问题。云身份认证是如何管理的?内部人员攻击是一种持续威胁。任何获得云平台访问权限的人都有可能成为潜在的问题。举一个例子：有一名员工可能离职或被辞退，结果他或她是唯一有访问密码的人。或者说，或许这一名员工是唯一一位负责给云提供商支付费用的人。你必须知道谁有访问权限，他或她是如何交接工作的，以及访问权限是如何中止的?
你是否有审计权限?
这个问题并不是小问题，相反是其中一个最重要的云安全问题。云提供商可能同意在书面上遵守一个审计标准；但是，对于审计人员和评估人员而言，想要评估云计算是否符合法规要求，已经被证明是一件越来越难完成和验证的工作。在IT要面对的诸多法规中，几乎没有专门针对云计算的。审计人员和评估人员可能还不熟悉云计算，也不熟悉某个特定的云服务。
云提供商给员工提供了哪一些培训?
这确实是一个非常值得注意的问题，因为人们在安全面前总是弱势群体。了解云服务商提供了哪些培训。大多数攻击都同时包含技术因素和社会因素。云服务商应该采用措施处理各种来源的社会攻击，包括电子邮件、恶意链接、电话及其他方式，它们都应该在出现在培训和认知项目中。
是否使用了加密手段?
加密手段也应该在考虑范围内。原始数据是否允许离开企业，或者它们应该留在内部，才能符合法规要求？数据在静止和或移动过程中，是否加密？此外，你还应该了解其中所使用的加密类型。要保证自己知道是谁在保管密钥，然后再签合约。加密手段一定要出现在云安全问题清单中。
你的数据与其他人的数据是如何分隔的?
数据位于一台共享服务器还是一个专用系统中？如果使用一个专用服务器，则意味着服务器上只有你的信息。如果在一台共享服务器上，则磁盘空间、处理能力、带宽等资源都是有限的，因为还有其他人一起共享这个设备。你需要确定自己是需要私有云还是公有云，以及谁在管理服务器。如果是共享服务器，那么数据就有可能和其他数据混在一起。
提供商的长期可用性体现有什么保障？
云服务商开展这个业务有多长时间了？过往的业务表现如何？如果它在这个业务上出现问题，你的数据会面临什么问题？是否会以原始格式交回给你？
如果出现安全漏洞会有什么应对措施?
如果发生了安全事故，你可以从云服务商获得哪些支持?虽然许多提供商都宣称自己的服务是万无一失的，但是基于云的服务是极其容易受到黑客攻击的。侧向通道、会话劫持、跨站脚本和分布式拒绝服务等攻击都是云数据经常遇到的攻击方式。
根据预测，未来三年有80%以上的数据中心流量将来自云服务。这意味着，即使你现在还没有做好云迁移，那么到2020年前你也会这样做的。所以，要用这一段时间保证自己采用正确的迁移方法。要提前定义合同要求，然后不能只是复制原来用于本地环境的安全策略。相反，要从迁移的角度去改进它。
OTPUB直播活动又双叒叕来喽！
直播主题
Excel的“天上人间”-“出台”到PPT的动态图表
直播时间
2017年4月25日 14:00-15:00
点击参与报名>>> 收起阅读 »

Hadoop环境中管理大数据存储八大技巧
目前大数据行业也越来越火爆，从而导致国内大数据人才也极度缺乏，下面介绍一下关于Hadoop环境中管理大数据存储技巧。

在现如今，随着IT互联网信息技术的飞速发展和进步。目前大数据行业也越来越火爆，从而导致国内大数据人才也极度缺乏，下面介绍一下关于Hadoop环境中管理大数据存储技巧。
1、分布式存储
传统化集中式存储存在已有一段时间。但大数据并非真的适合集中式存储架构。Hadoop设计用于将计算更接近数据节点，同时采用了HDFS文件系统的大规模横向扩展功能。
虽然，通常解决Hadoop管理自身数据低效性的方案是将Hadoop数据存储在SAN上。但这也造成了它自身性能与规模的瓶颈。现在，如果你把所有的数据都通过集中式SAN处理器进行处理，与Hadoop的分布式和并行化特性相悖。你要么针对不同的数据节点管理多个SAN，要么将所有的数据节点都集中到一个SAN。
但Hadoop是一个分布式应用，就应该运行在分布式存储上，这样存储就保留了与Hadoop本身同样的灵活性，不过它也要求拥抱一个软件定义存储方案，并在商用服务器上运行，这相比瓶颈化的Hadoop自然更为高效。
2、超融合VS分布式
注意，不要混淆超融合与分布式。某些超融合方案是分布式存储，但通常这个术语意味着你的应用和存储都保存在同一计算节点上。这是在试图解决数据本地化的问题，但它会造成太多资源争用。这个Hadoop应用和存储平台会争用相同的内存和CPU。Hadoop运行在专有应用层，分布式存储运行在专有存储层这样会更好。之后，利用缓存和分层来解决数据本地化并补偿网络性能损失。
3、避免控制器瓶颈(ControllerChokePoint)
实现目标的一个重要方面就是——避免通过单个点例如一个传统控制器来处理数据。反之，要确保存储平台并行化，性能可以得到显著提升。
此外，这个方案提供了增量扩展性。为数据湖添加功能跟往里面扔x86服务器一样简单。一个分布式存储平台如有需要将自动添加功能并重新调整数据。
4、删重和压缩
掌握大数据的关键是删重和压缩技术。通常大数据集内会有70%到90%的数据简化。以PB容量计，能节约数万美元的磁盘成本。现代平台提供内联(对比后期处理)删重和压缩，大大降低了存储数据所需能力。
5、合并Hadoop发行版
很多大型企业拥有多个Hadoop发行版本。可能是开发者需要或是企业部门已经适应了不同版本。无论如何最终往往要对这些集群的维护与运营。一旦海量数据真正开始影响一家企业时，多个Hadoop发行版存储就会导致低效性。我们可以通过创建一个单一，可删重和压缩的数据湖获取数据效率
6、虚拟化Hadoop
虚拟化已经席卷企业级市场。很多地区超过80%的物理服务器现在是虚拟化的。但也仍有很多企业因为性能和数据本地化问题对虚拟化Hadoop避而不谈。
7、创建弹性数据湖
创建数据湖并不容易，但大数据存储可能会有需求。我们有很多种方法来做这件事，但哪一种是正确的?这个正确的架构应该是一个动态，弹性的数据湖，可以以多种格式(架构化，非结构化，半结构化)存储所有资源的数据。更重要的是，它必须支持应用不在远程资源上而是在本地数据资源上执行。
不幸的是，传统架构和应用(也就是非分布式)并不尽如人意。随着数据集越来越大，将应用迁移到数据不可避免，而因为延迟太长也无法倒置。
理想的数据湖基础架构会实现数据单一副本的存储，而且有应用在单一数据资源上执行，无需迁移数据或制作副本。
8、整合分析
分析并不是一个新功能，它已经在传统RDBMS环境中存在多年。不同的是基于开源应用的出现，以及数据库表单和社交媒体，非结构化数据资源(比如，维基百科)的整合能力。关键在于将多个数据类型和格式整合成一个标准的能力，有利于更轻松和一致地实现可视化与报告制作。合适的工具也对分析/商业智能项目的成功至关重要。
OTPUB直播活动又双叒叕来喽！
直播主题
甲骨文第2代企业级IaaS云技术大会
直播时间
2017年4月13日 9：30-17：30
点击参与报名>>>
 
或者直接进入OTPUB官网
http://www.otpub.com/ 收起阅读 »