免费虚拟化OVM-V1.6版发布,新增虚拟机裸设备映射!

回复

maoliang 发起了问题 • 1 人关注 • 0 个回复 • 468 次浏览 • 2017-05-04 14:26 • 来自相关话题

甲骨文发布云端仓库管理系统软件V8

OT学习平台 发表了文章 • 0 个评论 • 336 次浏览 • 2017-05-02 14:27 • 来自相关话题

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

直播主题

Salesforce爱因斯坦Einstein人工智能解决方案

直播时间

2017年5月11日 14:00-15:00
点击报名>>>
 甲骨文近日发布了新版本的仓库管理系统(WMS)软件,甲骨文表示可以帮助企业处理全渠道实现问题的挑战。
据悉,Oracle仓库管理云产品版本8中的增强功能,有助于提升从供应商到配送中心(DC)到商店货架库存的完整库存管理。
甲骨文在2016年收购了LogFire,与Manhattan Associates和JDA Software Group等专注在物流管理的企业展开竞争。通过收购LogFire,Oracle通过仓库管理系统进一步提升其在ERP市场的地位,从而扩全渠道供应链市场的能力。
据调查显示,物流软件市场将从从2015年的12亿美元增长到2024年的41亿美元。甲骨文表示,将通过继续投资物流软件,不断提升其在云端WMS市场的份额。
甲骨文指出,最新版本使用100%的基于云的架构,以及提供与Oracle供应链管理(SCM)云中的其他软件产品的连接。
甲骨文的CSM产品战略集团副总裁Jon Chorley表示:“LogFire已经证明了其基于云的WMS的可行性,Oracle WMS Cloud是满足用户全生命周期的解决方案,它可以让企业在当今动态互联的全方位实体经济获得价值。” 查看全部
OTPUB直播活动又双叒叕来喽!

直播主题

Salesforce爱因斯坦Einstein人工智能解决方案

直播时间

2017年5月11日 14:00-15:00
点击报名>>>
 甲骨文近日发布了新版本的仓库管理系统(WMS)软件,甲骨文表示可以帮助企业处理全渠道实现问题的挑战。
据悉,Oracle仓库管理云产品版本8中的增强功能,有助于提升从供应商到配送中心(DC)到商店货架库存的完整库存管理。
甲骨文在2016年收购了LogFire,与Manhattan Associates和JDA Software Group等专注在物流管理的企业展开竞争。通过收购LogFire,Oracle通过仓库管理系统进一步提升其在ERP市场的地位,从而扩全渠道供应链市场的能力。
据调查显示,物流软件市场将从从2015年的12亿美元增长到2024年的41亿美元。甲骨文表示,将通过继续投资物流软件,不断提升其在云端WMS市场的份额。
甲骨文指出,最新版本使用100%的基于云的架构,以及提供与Oracle供应链管理(SCM)云中的其他软件产品的连接。
甲骨文的CSM产品战略集团副总裁Jon Chorley表示:“LogFire已经证明了其基于云的WMS的可行性,Oracle WMS Cloud是满足用户全生命周期的解决方案,它可以让企业在当今动态互联的全方位实体经济获得价值。”

企业级管理及项目管理软件的发展趋势

OT学习平台 发表了文章 • 0 个评论 • 328 次浏览 • 2017-04-24 15:35 • 来自相关话题

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

直播主题

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

直播时间

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


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

直播主题

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

直播时间

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


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

​部署SaaS向云计算转型 网络安全需先行

OT学习平台 发表了文章 • 0 个评论 • 408 次浏览 • 2017-04-20 16:18 • 来自相关话题

云计算解决方案可让企业快速部署服务以及降低总体拥有成本,这也是为什么首席信息官(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 查看全部

云计算解决方案可让企业快速部署服务以及降低总体拥有成本,这也是为什么首席信息官(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

2017年公有云基础设施支出将会超过私有云

OT学习平台 发表了文章 • 0 个评论 • 259 次浏览 • 2017-04-17 16:57 • 来自相关话题

根据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
点击参与报名>>> 查看全部

根据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
点击参与报名>>>

Kafka日志设置和清除策略

push 发表了文章 • 0 个评论 • 1470 次浏览 • 2017-04-15 16:00 • 来自相关话题

一、日志设置

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将被删除,这也符合以上逻辑。 查看全部
一、日志设置


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即可生效。
kafkalog.png

 
二、日志清理和策略


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启用压缩策略。

压缩策略的细节如下:
kafkays.png

如上图,在整个数据流中,每个Key都有可能出现多次,压缩时将根据Key将消息聚合,只保留最后一次出现时的数据。这样,无论什么时候消费消息,都能拿到每个Key的最新版本的数据。
 
压缩后的offset可能是不连续的,比如上图中没有5和7,因为这些offset的消息被merge了,当从这些offset消费消息时,将会拿到比这个offset大的offset对应的消息,比如,当试图获取offset为5的消息时,实际上会拿到offset为6的消息,并从这个位置开始消费。
 
这种策略只适合特俗场景,比如消息的key是用户ID,消息体是用户的资料,通过这种压缩策略,整个消息集里就保存了所有用户最新的资料。
 
压缩策略支持删除,当某个Key的最新版本的消息没有内容时,这个Key将被删除,这也符合以上逻辑。

云安全事故频发,如何应对

OT学习平台 发表了文章 • 0 个评论 • 311 次浏览 • 2017-04-14 14:44 • 来自相关话题

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

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

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

Hadoop环境中管理大数据存储技巧

OT学习平台 发表了文章 • 0 个评论 • 407 次浏览 • 2017-04-12 15:03 • 来自相关话题

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/ 查看全部
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/

Zookeeper日志设置和清理

push 发表了文章 • 0 个评论 • 739 次浏览 • 2017-04-11 15:38 • 来自相关话题

最近搭建zookeeper和kafka集群,遇到了Zookeeper日志问题输出路径的问题, 发现zookeeper设置log4j.properties不能解决日志路径问题, 发现解决方案如下。

一、日志设置
第一步:修改log4j.properties, 这个应该是大家都会去改改, 加粗处是我修改的, 但是只改这个文件后来发现还是不生效

# Define some default values that can be overridden by system properties
zookeeper.root.logger=INFO,ROLLINGFILE 
zookeeper.console.threshold=INFO
zookeeper.log.dir=.
zookeeper.log.file=zookeeper.log
zookeeper.log.threshold=DEBUG
zookeeper.tracelog.dir=.
zookeeper.tracelog.file=zookeeper_trace.log

#
# ZooKeeper Logging Configuration
#

# Format is "<default threshold> (, <appender>)+

# DEFAULT: console appender only
log4j.rootLogger=${zookeeper.root.logger}

# Example with rolling log file
#log4j.rootLogger=DEBUG, CONSOLE, ROLLINGFILE

# Example with rolling log file and tracing
#log4j.rootLogger=TRACE, CONSOLE, ROLLINGFILE, TRACEFILE

#
# Log INFO level and above messages to the console
#
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=${zookeeper.console.threshold}
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n

#
# Add ROLLINGFILE to rootLogger to get log file output
#    Log DEBUG level and above messages to a log file
log4j.appender.ROLLINGFILE=org.apache.log4j.DailyRollingFileAppender  //按天日记轮转
log4j.appender.ROLLINGFILE.Threshold=${zookeeper.log.threshold}
log4j.appender.ROLLINGFILE.File=${zookeeper.log.dir}/${zookeeper.log.file}

# Max log file size of 10MB
#log4j.appender.ROLLINGFILE.MaxFileSize=10MB
# uncomment the next line to limit number of backup files
#log4j.appender.ROLLINGFILE.MaxBackupIndex=10

log4j.appender.ROLLINGFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLINGFILE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n


#
# Add TRACEFILE to rootLogger to get log file output
#    Log DEBUG level and above messages to a log file
log4j.appender.TRACEFILE=org.apache.log4j.FileAppender
log4j.appender.TRACEFILE.Threshold=TRACE
log4j.appender.TRACEFILE.File=${zookeeper.tracelog.dir}/${zookeeper.tracelog.file}

log4j.appender.TRACEFILE.layout=org.apache.log4j.PatternLayout
### Notice we are including log4j's NDC here (%x)
log4j.appender.TRACEFILE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L][%x] - %m%n

第二步:还需要改${zkhome}/bin/zkEnv.sh, 注意加粗处, 这时日志已经可以成功按照你设置的目录进行输出了

#!/usr/bin/env bash

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# This script should be sourced into other zookeeper
# scripts to setup the env variables

# We use ZOOCFGDIR if defined,
# otherwise we use /etc/zookeeper
# or the conf directory that is
# a sibling of this script's directory

ZOOBINDIR="${ZOOBINDIR:-/usr/bin}"
ZOOKEEPER_PREFIX="${ZOOBINDIR}/.."

if [ "x$ZOOCFGDIR" = "x" ]
then
  if [ -e "${ZOOKEEPER_PREFIX}/conf" ]; then
    ZOOCFGDIR="$ZOOBINDIR/../conf"
  else
    ZOOCFGDIR="$ZOOBINDIR/../etc/zookeeper"
  fi
fi

if [ -f "${ZOOCFGDIR}/zookeeper-env.sh" ]; then
  . "${ZOOCFGDIR}/zookeeper-env.sh"
fi

if [ "x$ZOOCFG" = "x" ]
then
    ZOOCFG="zoo.cfg"
fi

ZOOCFG="$ZOOCFGDIR/$ZOOCFG"

if [ -f "$ZOOCFGDIR/java.env" ]
then
    . "$ZOOCFGDIR/java.env"
fi

if [ "x${ZOO_LOG_DIR}" = "x" ]
then
    ZOO_LOG_DIR="/data/zookeeper/outlogs/"
fi

if [ "x${ZOO_LOG4J_PROP}" = "x" ]
then
    ZOO_LOG4J_PROP="INFO,ROLLINGFILE"    
fi

if [ "$JAVA_HOME" != "" ]; then
  JAVA="$JAVA_HOME/bin/java"
else
  JAVA=java
fi

#add the zoocfg dir to classpath
CLASSPATH="$ZOOCFGDIR:$CLASSPATH"

for i in "$ZOOBINDIR"/../src/java/lib/*.jar
do
    CLASSPATH="$i:$CLASSPATH"
done

#make it work in the binary package
#(use array for LIBPATH to account for spaces within wildcard expansion)
if [ -e "${ZOOKEEPER_PREFIX}"/share/zookeeper/zookeeper-*.jar ]; then
  LIBPATH=("${ZOOKEEPER_PREFIX}"/share/zookeeper/*.jar)
else
  #release tarball format
  for i in "$ZOOBINDIR"/../zookeeper-*.jar
  do
    CLASSPATH="$i:$CLASSPATH"
  done
  LIBPATH=("${ZOOBINDIR}"/../lib/*.jar)
fi

for i in "${LIBPATH[@]}"
do
    CLASSPATH="$i:$CLASSPATH"
done

#make it work for developers
for d in "$ZOOBINDIR"/../build/lib/*.jar
do
   CLASSPATH="$d:$CLASSPATH"
done

#make it work for developers
CLASSPATH="$ZOOBINDIR/../build/classes:$CLASSPATH"

case "`uname`" in
    CYGWIN*) cygwin=true ;;
    *) cygwin=false ;;
esac

if $cygwin
then
    CLASSPATH=`cygpath -wp "$CLASSPATH"`
fi

#echo "CLASSPATH=$CLASSPATH" 

第三步:设置zookeeper.out
zookeeper.out由nohup的输出,也就是zookeeper的stdout和stdeer输出,修改bin/zkServer.sh 文件:

_ZOO_DAEMON_OUT="$ZOO_LOG_DIR/zookeeper.out"

case $1 in
start)
    echo  -n "Starting zookeeper ... "
    if [ -f $ZOOPIDFILE ]; then
      if kill -0 `cat $ZOOPIDFILE` > /dev/null 2>&1; then
         echo $command already running as process `cat $ZOOPIDFILE`.
         exit 0
      fi
    fi
    nohup $JAVA "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
    -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null &

第四步:快照事物日志
在使用zookeeper过程中,我们知道,会有dataDir和dataLogDir两个目录,分别用于snapshot和事务日志的输出(默认情况下只有dataDir目录,snapshot和事务日志都保存在这个目录中),通过zoo.cfg配置文件可配置:#snapshot file dir
dataDir=/data/zookeeper/data
#tran log dir
dataLogDir=/data/zookeeper/log
二、日志清理
正常运行过程中,ZK会不断地把快照数据和事务日志输出到这两个目录,并且如果没有人为操作的话,ZK自己是不会清理这些文件的,需要管理员来清理,这里介绍4种清理日志的方法。在这4种方法中,推荐使用第一种方法,对于运维人员来说,将日志清理工作独立出来,便于统一管理也更可控。毕竟zk自带的一些工具并不怎么给力,这里是社区反映的两个问题:
https://issues.apache.org/jira/browse/ZOOKEEPER-957  
http://zookeeper-user.578899.n2.nabble.com/PurgeTxnLog-td6304244.html  
 
第一种,也是运维人员最常用的,写一个删除日志脚本,每天定时执行即可:#!/bin/bash

#snapshot file dir
dataDir=/data/zookeeper/data/version-2
#tran log dir
dataLogDir=/data/zookeeper/log/version-2
#zk log dir
logDir=/data/zookeeper/outlog/
#Leave 60 files
count=60
count=$[$count+1]
ls -t $dataLogDir/log.* | tail -n +$count | xargs rm -f
ls -t $dataDir/snapshot.* | tail -n +$count | xargs rm -f
ls -t $logDir/zookeeper.log.* | tail -n +$count | xargs rm -f以上这个脚本定义了删除对应三个目录中的文件,保留最新的60个文件,可以将他写到crontab中,设置为每天凌晨2点执行一次就可以了。
 
第二种,使用ZK的工具类PurgeTxnLog,它的实现了一种简单的历史文件清理策略,可以在这里看一下他的使用方法:http://zookeeper.apache.org/doc/r3.4.3/api/index.html ,可以指定要清理的目录和需要保留的文件数目,简单使用如下:java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir><snapDir> -n <count>第三种,对于上面这个Java类的执行,ZK自己已经写好了脚本,在bin/zkCleanup.sh中,所以直接使用这个脚本也是可以执行清理工作的。
 
第四种,从3.4.0开始,zookeeper提供了自动清理snapshot和事务日志的功能,通过配置 autopurge.snapRetainCount 和 autopurge.purgeInterval 这两个参数能够实现定时清理了。这两个参数都是在zoo.cfg中配置的:autopurge.purgeInterval: 24*2
autopurge.snapRetainCount: 2 autopurge.purgeInterval  这个参数指定了清理频率,单位是小时,需要填写一个1或更大的整数,默认是0,表示不开启自己清理功能。
autopurge.snapRetainCount 这个参数和上面的参数搭配使用,这个参数指定了需要保留的文件数目。默认是保留3个。
参考:http://nileader.blog.51cto.com/1381108/932156  查看全部
最近搭建zookeeper和kafka集群,遇到了Zookeeper日志问题输出路径的问题, 发现zookeeper设置log4j.properties不能解决日志路径问题, 发现解决方案如下。

一、日志设置
第一步:修改log4j.properties, 这个应该是大家都会去改改, 加粗处是我修改的, 但是只改这个文件后来发现还是不生效


# Define some default values that can be overridden by system properties
zookeeper.root.logger=INFO,ROLLINGFILE 
zookeeper.console.threshold=INFO
zookeeper.log.dir=.
zookeeper.log.file=zookeeper.log
zookeeper.log.threshold=DEBUG
zookeeper.tracelog.dir=.
zookeeper.tracelog.file=zookeeper_trace.log

#
# ZooKeeper Logging Configuration
#

# Format is "<default threshold> (, <appender>)+

# DEFAULT: console appender only
log4j.rootLogger=${zookeeper.root.logger}

# Example with rolling log file
#log4j.rootLogger=DEBUG, CONSOLE, ROLLINGFILE

# Example with rolling log file and tracing
#log4j.rootLogger=TRACE, CONSOLE, ROLLINGFILE, TRACEFILE

#
# Log INFO level and above messages to the console
#
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=${zookeeper.console.threshold}
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n

#
# Add ROLLINGFILE to rootLogger to get log file output
#    Log DEBUG level and above messages to a log file
log4j.appender.ROLLINGFILE=org.apache.log4j.DailyRollingFileAppender  //按天日记轮转
log4j.appender.ROLLINGFILE.Threshold=${zookeeper.log.threshold}
log4j.appender.ROLLINGFILE.File=${zookeeper.log.dir}/${zookeeper.log.file}

# Max log file size of 10MB
#log4j.appender.ROLLINGFILE.MaxFileSize=10MB
# uncomment the next line to limit number of backup files
#log4j.appender.ROLLINGFILE.MaxBackupIndex=10

log4j.appender.ROLLINGFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLINGFILE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n


#
# Add TRACEFILE to rootLogger to get log file output
#    Log DEBUG level and above messages to a log file
log4j.appender.TRACEFILE=org.apache.log4j.FileAppender
log4j.appender.TRACEFILE.Threshold=TRACE
log4j.appender.TRACEFILE.File=${zookeeper.tracelog.dir}/${zookeeper.tracelog.file}

log4j.appender.TRACEFILE.layout=org.apache.log4j.PatternLayout
### Notice we are including log4j's NDC here (%x)
log4j.appender.TRACEFILE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L][%x] - %m%n


第二步:还需要改${zkhome}/bin/zkEnv.sh, 注意加粗处, 这时日志已经可以成功按照你设置的目录进行输出了


#!/usr/bin/env bash

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# This script should be sourced into other zookeeper
# scripts to setup the env variables

# We use ZOOCFGDIR if defined,
# otherwise we use /etc/zookeeper
# or the conf directory that is
# a sibling of this script's directory

ZOOBINDIR="${ZOOBINDIR:-/usr/bin}"
ZOOKEEPER_PREFIX="${ZOOBINDIR}/.."

if [ "x$ZOOCFGDIR" = "x" ]
then
  if [ -e "${ZOOKEEPER_PREFIX}/conf" ]; then
    ZOOCFGDIR="$ZOOBINDIR/../conf"
  else
    ZOOCFGDIR="$ZOOBINDIR/../etc/zookeeper"
  fi
fi

if [ -f "${ZOOCFGDIR}/zookeeper-env.sh" ]; then
  . "${ZOOCFGDIR}/zookeeper-env.sh"
fi

if [ "x$ZOOCFG" = "x" ]
then
    ZOOCFG="zoo.cfg"
fi

ZOOCFG="$ZOOCFGDIR/$ZOOCFG"

if [ -f "$ZOOCFGDIR/java.env" ]
then
    . "$ZOOCFGDIR/java.env"
fi

if [ "x${ZOO_LOG_DIR}" = "x" ]
then
    ZOO_LOG_DIR="/data/zookeeper/outlogs/"
fi

if [ "x${ZOO_LOG4J_PROP}" = "x" ]
then
    ZOO_LOG4J_PROP="INFO,ROLLINGFILE"    
fi

if [ "$JAVA_HOME" != "" ]; then
  JAVA="$JAVA_HOME/bin/java"
else
  JAVA=java
fi

#add the zoocfg dir to classpath
CLASSPATH="$ZOOCFGDIR:$CLASSPATH"

for i in "$ZOOBINDIR"/../src/java/lib/*.jar
do
    CLASSPATH="$i:$CLASSPATH"
done

#make it work in the binary package
#(use array for LIBPATH to account for spaces within wildcard expansion)
if [ -e "${ZOOKEEPER_PREFIX}"/share/zookeeper/zookeeper-*.jar ]; then
  LIBPATH=("${ZOOKEEPER_PREFIX}"/share/zookeeper/*.jar)
else
  #release tarball format
  for i in "$ZOOBINDIR"/../zookeeper-*.jar
  do
    CLASSPATH="$i:$CLASSPATH"
  done
  LIBPATH=("${ZOOBINDIR}"/../lib/*.jar)
fi

for i in "${LIBPATH[@]}"
do
    CLASSPATH="$i:$CLASSPATH"
done

#make it work for developers
for d in "$ZOOBINDIR"/../build/lib/*.jar
do
   CLASSPATH="$d:$CLASSPATH"
done

#make it work for developers
CLASSPATH="$ZOOBINDIR/../build/classes:$CLASSPATH"

case "`uname`" in
    CYGWIN*) cygwin=true ;;
    *) cygwin=false ;;
esac

if $cygwin
then
    CLASSPATH=`cygpath -wp "$CLASSPATH"`
fi

#echo "CLASSPATH=$CLASSPATH" 


第三步:设置zookeeper.out
zookeeper.out由nohup的输出,也就是zookeeper的stdout和stdeer输出,修改bin/zkServer.sh 文件:


_ZOO_DAEMON_OUT="$ZOO_LOG_DIR/zookeeper.out"

case $1 in
start)
    echo  -n "Starting zookeeper ... "
    if [ -f $ZOOPIDFILE ]; then
      if kill -0 `cat $ZOOPIDFILE` > /dev/null 2>&1; then
         echo $command already running as process `cat $ZOOPIDFILE`.
         exit 0
      fi
    fi
    nohup $JAVA "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
    -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null &


第四步:快照事物日志
在使用zookeeper过程中,我们知道,会有dataDir和dataLogDir两个目录,分别用于snapshot和事务日志的输出(默认情况下只有dataDir目录,snapshot和事务日志都保存在这个目录中),通过zoo.cfg配置文件可配置:
#snapshot file dir
dataDir=/data/zookeeper/data
#tran log dir
dataLogDir=/data/zookeeper/log

二、日志清理
正常运行过程中,ZK会不断地把快照数据和事务日志输出到这两个目录,并且如果没有人为操作的话,ZK自己是不会清理这些文件的,需要管理员来清理,这里介绍4种清理日志的方法。在这4种方法中,推荐使用第一种方法,对于运维人员来说,将日志清理工作独立出来,便于统一管理也更可控。毕竟zk自带的一些工具并不怎么给力,这里是社区反映的两个问题:
https://issues.apache.org/jira/browse/ZOOKEEPER-957  
http://zookeeper-user.578899.n2.nabble.com/PurgeTxnLog-td6304244.html  
 
第一种,也是运维人员最常用的,写一个删除日志脚本,每天定时执行即可:
#!/bin/bash

#snapshot file dir
dataDir=/data/zookeeper/data/version-2
#tran log dir
dataLogDir=/data/zookeeper/log/version-2
#zk log dir
logDir=/data/zookeeper/outlog/
#Leave 60 files
count=60
count=$[$count+1]
ls -t $dataLogDir/log.* | tail -n +$count | xargs rm -f
ls -t $dataDir/snapshot.* | tail -n +$count | xargs rm -f
ls -t $logDir/zookeeper.log.* | tail -n +$count | xargs rm -f
以上这个脚本定义了删除对应三个目录中的文件,保留最新的60个文件,可以将他写到crontab中,设置为每天凌晨2点执行一次就可以了。
 
第二种,使用ZK的工具类PurgeTxnLog,它的实现了一种简单的历史文件清理策略,可以在这里看一下他的使用方法:http://zookeeper.apache.org/doc/r3.4.3/api/index.html ,可以指定要清理的目录和需要保留的文件数目,简单使用如下:
java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir><snapDir> -n <count>
第三种,对于上面这个Java类的执行,ZK自己已经写好了脚本,在bin/zkCleanup.sh中,所以直接使用这个脚本也是可以执行清理工作的。
 
第四种,从3.4.0开始,zookeeper提供了自动清理snapshot和事务日志的功能,通过配置 autopurge.snapRetainCount 和 autopurge.purgeInterval 这两个参数能够实现定时清理了。这两个参数都是在zoo.cfg中配置的:
autopurge.purgeInterval: 24*2 
autopurge.snapRetainCount: 2
autopurge.purgeInterval  这个参数指定了清理频率,单位是小时,需要填写一个1或更大的整数,默认是0,表示不开启自己清理功能。
autopurge.snapRetainCount 这个参数和上面的参数搭配使用,这个参数指定了需要保留的文件数目。默认是保留3个。
参考:http://nileader.blog.51cto.com/1381108/932156 

​云计算,你看好哪个时代?

OT学习平台 发表了文章 • 0 个评论 • 267 次浏览 • 2017-04-11 15:17 • 来自相关话题

云计算的每条技术路线都代表着一个时代
高效、便捷、安全
传统路线 虚拟机云


这是已经被广泛应用的技术路线,从AWS到国内的阿里云,使用者得到的最小单位是虚拟机,需要追加和扩展的资源实际上是整个虚拟机的资源。但每一个虚拟机资源都受到物理机最大资源的限制。例如物理机总共有128G内存,那么任何一台虚拟机的最大内存都不会超过128G。


这种路线特别适合从物理机刚转到云的技术人员,因为所有的操作、配置、管理几乎与物理机一致。

轻量级路线 容器云


随着Docker的出现,容器云开始出现。容器云是以应用为单位进行资源分割的。无论在物理机年代还是虚拟机云上,一个虚拟机/物理机上可以运行多个应用,一个应用可以简单理解为一个或一组程序。在容器云上以应用为最基本单位进行资源(CPU、内存、硬盘)的分配,相对于虚拟机云,容器云资源分割粒度进一步精细化。
 
虚拟机云是以硬件为基础实施的,例如在阿里云上买一台4核的虚拟机,实际上是独占了物理机上CPU中4核的资源,这部分CPU资源就不能再被其他物理机使用。

 

在容器云上,可以指定CPU资源,但不能再像虚拟机那样让某一个应用独占CPU资源。使用者只能指定使用哪个CPU,使用的优先级以及CPU资源分配周期。

而出于安全性的考虑,产生了第三条路线:

中间路线 容器+mini kernel路线


这条路线就是容器之间不再共享内核,而是为每一个容器提供一个独立的内核。Intel推出的clear linux项目,就是这种路线的代表。中间路线是前面两条路线的融合,未来容器云路线极有可能向此条路线发展。

 

三条技术路线,代表着三个时代,虚拟机路线是最早出现且成熟的,因为它符合了技术人员的使用习惯,方便过渡。容器云是目前发展最快的路线,因为它把资源分割粒度做到最小,且使传统的运维工作提升效率。未来有可能是容器+mini kernel路线的天下,更高校、更便捷、更安全,永远是追求的目标。
OTPUB直播活动又双叒叕来喽!
直播主题
甲骨文第2代企业级IaaS云技术大会
直播时间
2017年4月13日 9:30-17:30
点击报名参与>>>
  查看全部

云计算的每条技术路线都代表着一个时代
高效、便捷、安全
传统路线 虚拟机云


这是已经被广泛应用的技术路线,从AWS到国内的阿里云,使用者得到的最小单位是虚拟机,需要追加和扩展的资源实际上是整个虚拟机的资源。但每一个虚拟机资源都受到物理机最大资源的限制。例如物理机总共有128G内存,那么任何一台虚拟机的最大内存都不会超过128G。


这种路线特别适合从物理机刚转到云的技术人员,因为所有的操作、配置、管理几乎与物理机一致。

轻量级路线 容器云


随着Docker的出现,容器云开始出现。容器云是以应用为单位进行资源分割的。无论在物理机年代还是虚拟机云上,一个虚拟机/物理机上可以运行多个应用,一个应用可以简单理解为一个或一组程序。在容器云上以应用为最基本单位进行资源(CPU、内存、硬盘)的分配,相对于虚拟机云,容器云资源分割粒度进一步精细化。
 
虚拟机云是以硬件为基础实施的,例如在阿里云上买一台4核的虚拟机,实际上是独占了物理机上CPU中4核的资源,这部分CPU资源就不能再被其他物理机使用。

 

在容器云上,可以指定CPU资源,但不能再像虚拟机那样让某一个应用独占CPU资源。使用者只能指定使用哪个CPU,使用的优先级以及CPU资源分配周期。

而出于安全性的考虑,产生了第三条路线:

中间路线 容器+mini kernel路线


这条路线就是容器之间不再共享内核,而是为每一个容器提供一个独立的内核。Intel推出的clear linux项目,就是这种路线的代表。中间路线是前面两条路线的融合,未来容器云路线极有可能向此条路线发展。

 

三条技术路线,代表着三个时代,虚拟机路线是最早出现且成熟的,因为它符合了技术人员的使用习惯,方便过渡。容器云是目前发展最快的路线,因为它把资源分割粒度做到最小,且使传统的运维工作提升效率。未来有可能是容器+mini kernel路线的天下,更高校、更便捷、更安全,永远是追求的目标。
OTPUB直播活动又双叒叕来喽!
直播主题
甲骨文第2代企业级IaaS云技术大会
直播时间
2017年4月13日 9:30-17:30

点击报名参与>>>