云计算大数据

云计算大数据

如何管理大数据

大数据/云计算OT学习平台 发表了文章 • 0 个评论 • 23 次浏览 • 3 天前 • 来自相关话题

随着应用BI系统的广泛应用,数据治理的话题也越来越受到企业的关注和讨论,有专家表示,如果想让用户进入真正的商业智能时代,就必须建立一定的数据治理体系;而大数据治理能够在短期内成为业内的焦点,这和企业对大数据质量的理解和密切关注有很大关系。

大数据治理面临的挑战:规模庞大,标准不一

过去几年,企业的IT系统经历了数据量高速膨胀的一个时期,这些海量的,分散在不同服务器的数据提高了数据资源利用的复杂性和管理难度;另外,各个企业内部的业务区分和行政区分也对企业数据的交互造成了一定的断层,而企业与外部业务交互所产生的“体外循环”数据与企业的核心数据体系并不能自然地融合。当这种数据的异构化所导致的应用冲突达到一定临界点时,数据治理便成为了规范企业数据的必要步骤。

大数据治理技术:主题众多,元数据管理先行

数据治理涉及的IT技术主题众多,包括元数据管理、主数据管理、数据质量、数据集成、监控与报告等。在很多国际企业中,元数据管理的重要性在全部技术主题中位列第一。

元数据管理是语义工具,其重要性在于,它能够为数据治理建立一套数据资料库,存储治理范围内的数据定义,负责人,来源,转换关系,目标,质量等级,依赖关系,安全权限等。这些信息对于商业整合,数据质量,可审计性等数据治理目标的实现至关重要。

元数据管理是实施数据治理的核心IT技术,有效的元数据管理将为数据质量、数据集成等技术的实施,以及数据治理目标的最终实现奠定坚实的基础。

大数据治理的意义:发掘数据资产的商业价值

大数据治理是为了将数据作为企业商业资产进行应用和管理的一套数据管理机制,能够通过建立规范的数据应用标准,消除数据的不一致性,来提高数据的质量,并能合理的将数据应用于企业的业务管理和战略决策中,充分的发挥数据的商业价值,良好的数据治理必将为信息化时代的企业带来不可替代的竞争优势。
 
了解更多大数据相关知识请进入OTPUB官网:www.otpub.com 查看全部
随着应用BI系统的广泛应用,数据治理的话题也越来越受到企业的关注和讨论,有专家表示,如果想让用户进入真正的商业智能时代,就必须建立一定的数据治理体系;而大数据治理能够在短期内成为业内的焦点,这和企业对大数据质量的理解和密切关注有很大关系。

大数据治理面临的挑战:规模庞大,标准不一

过去几年,企业的IT系统经历了数据量高速膨胀的一个时期,这些海量的,分散在不同服务器的数据提高了数据资源利用的复杂性和管理难度;另外,各个企业内部的业务区分和行政区分也对企业数据的交互造成了一定的断层,而企业与外部业务交互所产生的“体外循环”数据与企业的核心数据体系并不能自然地融合。当这种数据的异构化所导致的应用冲突达到一定临界点时,数据治理便成为了规范企业数据的必要步骤。

大数据治理技术:主题众多,元数据管理先行

数据治理涉及的IT技术主题众多,包括元数据管理、主数据管理、数据质量、数据集成、监控与报告等。在很多国际企业中,元数据管理的重要性在全部技术主题中位列第一。

元数据管理是语义工具,其重要性在于,它能够为数据治理建立一套数据资料库,存储治理范围内的数据定义,负责人,来源,转换关系,目标,质量等级,依赖关系,安全权限等。这些信息对于商业整合,数据质量,可审计性等数据治理目标的实现至关重要。

元数据管理是实施数据治理的核心IT技术,有效的元数据管理将为数据质量、数据集成等技术的实施,以及数据治理目标的最终实现奠定坚实的基础。

大数据治理的意义:发掘数据资产的商业价值

大数据治理是为了将数据作为企业商业资产进行应用和管理的一套数据管理机制,能够通过建立规范的数据应用标准,消除数据的不一致性,来提高数据的质量,并能合理的将数据应用于企业的业务管理和战略决策中,充分的发挥数据的商业价值,良好的数据治理必将为信息化时代的企业带来不可替代的竞争优势。
 
了解更多大数据相关知识请进入OTPUB官网:www.otpub.com

HDFS删除了文件,但是磁盘空间没有释放,这是怎么回事?

大数据/云计算采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 37 次浏览 • 3 天前 • 来自相关话题

OVM免费虚拟化管理平台

开源项目workingmom 发表了文章 • 2 个评论 • 39 次浏览 • 5 天前 • 来自相关话题

OVM作为完全免费、公益的一款产品,不仅拥有商业软件同样的稳定性、易用性、高性能,而且还拥有开源软件一样的开放性、可扩展性。面向中小型虚拟化环境,打造简单易用的虚拟化管理平台。让零基础的用户在几个小时内可以部署、使用自己的虚拟化系统。

OVM从设计之初就决定要做一款完全符合国人使用习惯和特点的“新国货”Iaas产品。OVM产品架构的设计严格按照商业产品架构的高标准要求,始终把产品的稳定性、易用性、可扩展性,以及产品的高性能放在第一位。OVM采用分布式、松耦合的模块化架构,分布式特点可以规避单点故障,松耦合的模块化特点让产品在扩展性方面不受任何限制。

产品理念

目前市场上一些比较成熟的开源产品,发现这些产品大多是有国外开发者主导的社区产品,既然这些开源产品是国外开发者主导的,那么这些产品里面就肯定没有太多中国元素,国内的企业要想使用这些产品,首页要对其中文化,其二还要花费相当多的时间来苦读英文文档来学习这些产品;另外我们发现目前市场上的这类开源产品更加偏向于拥有大规模数据中心的企业采用,中小企业用起来有些大材小用了。一般中小企业拥有的数据中心规模并不大,运维团队一般也比较小,对于Openstack、Cloudstack这些产品的确不适合这类中小企业使用。另外还有一个严重的问题就是,在使用开源产品过程中,如果遇到Bug或者重大安全隐患,中小企业并不具备解决问题的能力,那么对于他们来说只能等待开源社区推出Bug补丁包。基于以上的原因,我们决定筹备一个团队开发OVM产品,OVM定位为一个企业级的虚拟化管理平台,完全基于国内企业特点开发,更多的关注中小企业用户的产品需求,OVM想要带给用户的是一个稳定、简单、易用、易扩展的企业级Iaas产品。

OVM架构设计

OVM采用分布式、松耦合的模块化插件架构,分布式特点可以使管理平台规避单点故障,达到业务持续高可用,松耦合的模块化特点让产品在后期的扩展性方面不受任何限制,使其向下可以兼容数据中心所有硬件(通过OVM标准的Rest API接口),向上可以实现插件式的工作流引擎、计费引擎、报表引擎、桌面云引擎和自动化运维引擎。

OVM产品目前由三大组件、七大模块组成。其中三大组件分别为OVMUI、OVMAPI和OVM数据中心组件,OVMUI提供WEB自服务界面,OVMAPI负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。下图所示是OVM的总体架构图,体现了OVM三大组件与七大模块之间相辅相成的关系,由于每个模块各司其职,即使单个模块出现了故障也只是影响到该模块功能的使用,而不会影响平台整体使用。

易用性

OVM的易用性首先体现在安装部署方面。传统的开源软件安装部署相信对于运维人员来说不会陌生,他们大多只会提供安装包和简单的安装文档,而这些安装过程大多会涉及到数据库、redis、rabbitmq、ruby等环境的配置,这些环境的配置也要求运维人员必须先去熟悉这些相关软件的安装部署,毕竟一步配置错误就会导致整体的安装部署失败,整个安装部署少则也需要2-3天时间才可搞定,多则需要1-2周,复杂的安装部署过程让运维人员疲惫不堪。

OVM安装部署全部(包括管理平台和计算节点)采用一键式的ISO安装部署,整个安装过程就像是在安装一个Centos操作系统一样的简单,只用花费10-20分钟的过程就可以完成OVM的安装部署,极大的方便了运维人员,为他们省去了很多的宝贵时间。因为我们觉得真正易用的软件不会在安装部署上让运维人员为难,OVM要做的就是即使是一个刚进入运维行业的新人,通过OVM提供的iso镜像也可在1小时内完成整个产品的安装部署。

OVM的易用性其次还体现在升级方面。对于一个产品来说,迭代升级是必然的事情,因为一个产品总是要向前发展的,OVM在设计之初就在考虑如何可以让用户不费吹灰之力就可以升级使用中的版本到最新版本。经过我们OVM团队多次的讨论,最终将升级与UI无缝结合,用户只用点击WEB管理平台中的一键升级按钮就可轻松实现版本的快速升级,整个升级过程用户几乎感知不到,丝毫不会影响到用户业务的运行。

稳定性、可扩展性

OVM从架构设计之初就充分考虑到产品的稳定性,把产品的稳定放在第一位。因为作为一款Iaas虚拟化管理软件,其本身不仅仅是一个软件,而是连接用户数据中心的中枢(包括物理机、存储、网络、防火墙、灾备等)。在架构设计上,OVM分别参考了同行业开源软件、商业软件的产品架构,作为一款Iaas软件首先要保证产品无单点故障,即管理平台高可用;其次支持分布式部署,将不可预估因素造成的损失降到最小。因此OVM架构设计之一就是分布式、插件式,分布式和插件式的特点可以允许用户将不同的模块和服务,既可以部署在同一台Server上面,也可以将其分开部署在多台Server上,大大了提高了部署的灵活性,同时也可将单点故障的风险降到最小。另外OVM也引入了Zookeeper、Pacemaker等软件来为OVM提供高可用,避免单点故障的发生。此外,OVM的每个版本均经过严格的内测——OVM核心测试团队测试——市场公测——正式版发布,每一个环节我们都严把质量关,将稳定性自始至终贯穿到OVM的每个环节。

分布式和插件式的特点也为OVM的扩展提供了无限大的可能。模块化的插件式架构允许用户根据自己的需求来定制自己所需的模块,毕竟不同行业的用户还是存在不少差异的,即使是相同行业不同企业的用户也是会有所差距的,此时每个用户都可能会有自己的不同需求,获益于OVM插件式的架构,用户只需要根据自己的需求增加不同的模块来实现自己所需的功能就可以,可谓是真正的无限扩展,另外OVM完善的API可以助力用户、商业软件生产商集成第三方软件到OVM平台。比如IDC运营商想要的是一个公有云门户对外提供有偿服务,那么就可以根据自己的需要增加一个公有云模块到OVM平台,一般企业用户想要的是一个私有云,那么可以直接使用OVM轻松构建自己的私有云平台,而政府、事业单位、以及大规模企业则想要的是一个混合云环境,因为这类单位既有自己内部的高保密业务,也有对外提供服务的公有云业务,那么此类单位则可以使用OVM的API借口对接阿里云、腾讯云、亚马逊云、Openstack等,实现自己的混合办公需求。

高效

高效是检验一个平台设计是否优秀的关键。大家都希望管理平台能为自己的工作带来高效率,这也是选择使用一个平台的初衷,OVM设计之初就将平台的高效性视为关键,整体采用全异步、无等待、无锁架构来确保平台的每个任务都是独立执行,即使同时有存储任务、网络任务、虚拟机任务等都在执行也互不干扰,从此避免了多任务同时执行带来的阻塞问题。另外OVM全异步架构也可以为一些批量任务的执行带来高效率,比如虚拟机的批量创建、监控数据的采集、节点状态的检测等,这些任务都可以为用户节省大量的时间,全异步架构说简单点就是各干各的事情,极大的提高了完成工作的效率。OVM无锁、无等待架构既保证了高并发,也兼顾了整体的性能。

功能特点

1、一站式自服务门户

OVM提供了一个完整的门户,单一控制台管理全球基础设施,利用OVMAPI,自助创建虚拟企业租户、虚拟数据中心的分租户和虚拟应用程序,完全自定义“快速”的实施,并提供一个简单的服务目录。门户还支持可选的审批工作流,包括完整的电子邮件集成的”一键式”管理。

2、基于角色的多租户权限

基于角色的访问控制提供可定义无限数量的独立用户角色,并指定权限到任意组合,选择从一个全局的范围或局部(虚拟企业、数据中心、虚拟数据中心)的范围,提供了无限的细粒度用户权限控制。集成LDAP,允许企业通过LDAP或Active Directory完全管理OVM用户。

3、云应用商店平台

OVM提供了一个基于Web的最终用户的门户网站,企业可以建立一个服务目录,只需在目录中点击一下按钮,即能以预配置虚拟设备的形式部署和使用多层应用,包括虚拟机、操作系统映像和其他介质,也可以从移动设备如iphone和ipad。可建立公共、共享和私有库,允许建立企业私有标准或预定义镜像库。允许把复杂的多层应用程序融合在一个易用的用户界面,只需从镜像库拖拽单个虚拟机,自定义资源,一键多批VM部署。

4、网络

OVM管理两种网络:

内部网络OVM默认网络。OVM完全可以管理这些网络,用户也可以在自助服务的基础上创建他们自己的私人网络。OVM机架配置定义Vlan可用池,OVM会自动将未使用的 VLAN 分配给一个新的内部网络。内部网络适用于OVM云不提供对外部通信的状况。允许用户VM在同一虚拟数据中心互相沟通。

外部网络外部网络允许基础设施的通信,云管理员必须分配ip地址范围和Vlan,每个外部网络被分配到OVM虚拟企业,可为每个云租客分配VLAN,以连接到外部基础设施。服务提供商可分配每个客户用的VLAN,通过现有的MPLS或VPN无缝连接到云或公司的局域网。

5、存储

OVM支持自动配置多种存储类型,包括NFS,ISCSI,光纤通道等八种存储类型。通过hypervisior,OVM可以提供新的虚拟机到任何存储类型包括光纤通道、iSCSi和NFS。

深度集成的iSCSiOVM现成集成与存储解决方案包括NetApp OnTap、Nexenta和 Linux LVM。集成的iSCSi为用户提供一个完整的自助服务经验,无需管理员便能创建他们自己的卷,并附加到虚拟机或删除这些卷。

存储池及层可以将多个存储设备添加到OVM以分配给存储层中的云用户。存储层能够为多个存储类型提供不同的性能、功能和价格点。允许云用户选择适合他们的要求或其价格点的存储层。iSCSi存储SDK允许第三方创建自己集成的存储插件和额外的存储平台。

6、监控

7×24小时全天候可用性和性能监控,并自动收集一套全面的可用性能指数和利用率的指标,比如CPU,内存,存储,网络I/O,通过高度可定制的的交互式图表,能够快速识别性能趋势,提前布局; 查看全部
OVM作为完全免费、公益的一款产品,不仅拥有商业软件同样的稳定性、易用性、高性能,而且还拥有开源软件一样的开放性、可扩展性。面向中小型虚拟化环境,打造简单易用的虚拟化管理平台。让零基础的用户在几个小时内可以部署、使用自己的虚拟化系统。

OVM从设计之初就决定要做一款完全符合国人使用习惯和特点的“新国货”Iaas产品。OVM产品架构的设计严格按照商业产品架构的高标准要求,始终把产品的稳定性、易用性、可扩展性,以及产品的高性能放在第一位。OVM采用分布式、松耦合的模块化架构,分布式特点可以规避单点故障,松耦合的模块化特点让产品在扩展性方面不受任何限制。

产品理念

目前市场上一些比较成熟的开源产品,发现这些产品大多是有国外开发者主导的社区产品,既然这些开源产品是国外开发者主导的,那么这些产品里面就肯定没有太多中国元素,国内的企业要想使用这些产品,首页要对其中文化,其二还要花费相当多的时间来苦读英文文档来学习这些产品;另外我们发现目前市场上的这类开源产品更加偏向于拥有大规模数据中心的企业采用,中小企业用起来有些大材小用了。一般中小企业拥有的数据中心规模并不大,运维团队一般也比较小,对于Openstack、Cloudstack这些产品的确不适合这类中小企业使用。另外还有一个严重的问题就是,在使用开源产品过程中,如果遇到Bug或者重大安全隐患,中小企业并不具备解决问题的能力,那么对于他们来说只能等待开源社区推出Bug补丁包。基于以上的原因,我们决定筹备一个团队开发OVM产品,OVM定位为一个企业级的虚拟化管理平台,完全基于国内企业特点开发,更多的关注中小企业用户的产品需求,OVM想要带给用户的是一个稳定、简单、易用、易扩展的企业级Iaas产品。

OVM架构设计

OVM采用分布式、松耦合的模块化插件架构,分布式特点可以使管理平台规避单点故障,达到业务持续高可用,松耦合的模块化特点让产品在后期的扩展性方面不受任何限制,使其向下可以兼容数据中心所有硬件(通过OVM标准的Rest API接口),向上可以实现插件式的工作流引擎、计费引擎、报表引擎、桌面云引擎和自动化运维引擎。

OVM产品目前由三大组件、七大模块组成。其中三大组件分别为OVMUI、OVMAPI和OVM数据中心组件,OVMUI提供WEB自服务界面,OVMAPI负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。下图所示是OVM的总体架构图,体现了OVM三大组件与七大模块之间相辅相成的关系,由于每个模块各司其职,即使单个模块出现了故障也只是影响到该模块功能的使用,而不会影响平台整体使用。

易用性

OVM的易用性首先体现在安装部署方面。传统的开源软件安装部署相信对于运维人员来说不会陌生,他们大多只会提供安装包和简单的安装文档,而这些安装过程大多会涉及到数据库、redis、rabbitmq、ruby等环境的配置,这些环境的配置也要求运维人员必须先去熟悉这些相关软件的安装部署,毕竟一步配置错误就会导致整体的安装部署失败,整个安装部署少则也需要2-3天时间才可搞定,多则需要1-2周,复杂的安装部署过程让运维人员疲惫不堪。

OVM安装部署全部(包括管理平台和计算节点)采用一键式的ISO安装部署,整个安装过程就像是在安装一个Centos操作系统一样的简单,只用花费10-20分钟的过程就可以完成OVM的安装部署,极大的方便了运维人员,为他们省去了很多的宝贵时间。因为我们觉得真正易用的软件不会在安装部署上让运维人员为难,OVM要做的就是即使是一个刚进入运维行业的新人,通过OVM提供的iso镜像也可在1小时内完成整个产品的安装部署。

OVM的易用性其次还体现在升级方面。对于一个产品来说,迭代升级是必然的事情,因为一个产品总是要向前发展的,OVM在设计之初就在考虑如何可以让用户不费吹灰之力就可以升级使用中的版本到最新版本。经过我们OVM团队多次的讨论,最终将升级与UI无缝结合,用户只用点击WEB管理平台中的一键升级按钮就可轻松实现版本的快速升级,整个升级过程用户几乎感知不到,丝毫不会影响到用户业务的运行。

稳定性、可扩展性

OVM从架构设计之初就充分考虑到产品的稳定性,把产品的稳定放在第一位。因为作为一款Iaas虚拟化管理软件,其本身不仅仅是一个软件,而是连接用户数据中心的中枢(包括物理机、存储、网络、防火墙、灾备等)。在架构设计上,OVM分别参考了同行业开源软件、商业软件的产品架构,作为一款Iaas软件首先要保证产品无单点故障,即管理平台高可用;其次支持分布式部署,将不可预估因素造成的损失降到最小。因此OVM架构设计之一就是分布式、插件式,分布式和插件式的特点可以允许用户将不同的模块和服务,既可以部署在同一台Server上面,也可以将其分开部署在多台Server上,大大了提高了部署的灵活性,同时也可将单点故障的风险降到最小。另外OVM也引入了Zookeeper、Pacemaker等软件来为OVM提供高可用,避免单点故障的发生。此外,OVM的每个版本均经过严格的内测——OVM核心测试团队测试——市场公测——正式版发布,每一个环节我们都严把质量关,将稳定性自始至终贯穿到OVM的每个环节。

分布式和插件式的特点也为OVM的扩展提供了无限大的可能。模块化的插件式架构允许用户根据自己的需求来定制自己所需的模块,毕竟不同行业的用户还是存在不少差异的,即使是相同行业不同企业的用户也是会有所差距的,此时每个用户都可能会有自己的不同需求,获益于OVM插件式的架构,用户只需要根据自己的需求增加不同的模块来实现自己所需的功能就可以,可谓是真正的无限扩展,另外OVM完善的API可以助力用户、商业软件生产商集成第三方软件到OVM平台。比如IDC运营商想要的是一个公有云门户对外提供有偿服务,那么就可以根据自己的需要增加一个公有云模块到OVM平台,一般企业用户想要的是一个私有云,那么可以直接使用OVM轻松构建自己的私有云平台,而政府、事业单位、以及大规模企业则想要的是一个混合云环境,因为这类单位既有自己内部的高保密业务,也有对外提供服务的公有云业务,那么此类单位则可以使用OVM的API借口对接阿里云、腾讯云、亚马逊云、Openstack等,实现自己的混合办公需求。

高效

高效是检验一个平台设计是否优秀的关键。大家都希望管理平台能为自己的工作带来高效率,这也是选择使用一个平台的初衷,OVM设计之初就将平台的高效性视为关键,整体采用全异步、无等待、无锁架构来确保平台的每个任务都是独立执行,即使同时有存储任务、网络任务、虚拟机任务等都在执行也互不干扰,从此避免了多任务同时执行带来的阻塞问题。另外OVM全异步架构也可以为一些批量任务的执行带来高效率,比如虚拟机的批量创建、监控数据的采集、节点状态的检测等,这些任务都可以为用户节省大量的时间,全异步架构说简单点就是各干各的事情,极大的提高了完成工作的效率。OVM无锁、无等待架构既保证了高并发,也兼顾了整体的性能。

功能特点

1、一站式自服务门户

OVM提供了一个完整的门户,单一控制台管理全球基础设施,利用OVMAPI,自助创建虚拟企业租户、虚拟数据中心的分租户和虚拟应用程序,完全自定义“快速”的实施,并提供一个简单的服务目录。门户还支持可选的审批工作流,包括完整的电子邮件集成的”一键式”管理。

2、基于角色的多租户权限

基于角色的访问控制提供可定义无限数量的独立用户角色,并指定权限到任意组合,选择从一个全局的范围或局部(虚拟企业、数据中心、虚拟数据中心)的范围,提供了无限的细粒度用户权限控制。集成LDAP,允许企业通过LDAP或Active Directory完全管理OVM用户。

3、云应用商店平台

OVM提供了一个基于Web的最终用户的门户网站,企业可以建立一个服务目录,只需在目录中点击一下按钮,即能以预配置虚拟设备的形式部署和使用多层应用,包括虚拟机、操作系统映像和其他介质,也可以从移动设备如iphone和ipad。可建立公共、共享和私有库,允许建立企业私有标准或预定义镜像库。允许把复杂的多层应用程序融合在一个易用的用户界面,只需从镜像库拖拽单个虚拟机,自定义资源,一键多批VM部署。

4、网络

OVM管理两种网络:

内部网络OVM默认网络。OVM完全可以管理这些网络,用户也可以在自助服务的基础上创建他们自己的私人网络。OVM机架配置定义Vlan可用池,OVM会自动将未使用的 VLAN 分配给一个新的内部网络。内部网络适用于OVM云不提供对外部通信的状况。允许用户VM在同一虚拟数据中心互相沟通。

外部网络外部网络允许基础设施的通信,云管理员必须分配ip地址范围和Vlan,每个外部网络被分配到OVM虚拟企业,可为每个云租客分配VLAN,以连接到外部基础设施。服务提供商可分配每个客户用的VLAN,通过现有的MPLS或VPN无缝连接到云或公司的局域网。

5、存储

OVM支持自动配置多种存储类型,包括NFS,ISCSI,光纤通道等八种存储类型。通过hypervisior,OVM可以提供新的虚拟机到任何存储类型包括光纤通道、iSCSi和NFS。

深度集成的iSCSiOVM现成集成与存储解决方案包括NetApp OnTap、Nexenta和 Linux LVM。集成的iSCSi为用户提供一个完整的自助服务经验,无需管理员便能创建他们自己的卷,并附加到虚拟机或删除这些卷。

存储池及层可以将多个存储设备添加到OVM以分配给存储层中的云用户。存储层能够为多个存储类型提供不同的性能、功能和价格点。允许云用户选择适合他们的要求或其价格点的存储层。iSCSi存储SDK允许第三方创建自己集成的存储插件和额外的存储平台。

6、监控

7×24小时全天候可用性和性能监控,并自动收集一套全面的可用性能指数和利用率的指标,比如CPU,内存,存储,网络I/O,通过高度可定制的的交互式图表,能够快速识别性能趋势,提前布局;

es集群节点增加和数据迁移

运维技术mars_yan 回复了问题 • 2 人关注 • 2 个回复 • 117 次浏览 • 2017-07-19 11:40 • 来自相关话题

HDFS常用的一些命令

大数据/云计算being 发表了文章 • 0 个评论 • 95 次浏览 • 2017-07-07 14:52 • 来自相关话题

一、文件操作

1、列出HDFS下的文件
/usr/local/hadoop/bin/hadoop dfs -ls2、列出HDFS文件下名为in的文档中的文件
/usr/local/hadoop/bin/hadoop dfs -ls in3、上传文件
将hadoop目录下的test1文件上传到HDFS上并重命名为test
/usr/local/hadoop/bin/hadoop dfs -put test1 test4、文件被复制到本地系统中
将HDFS中的in文件复制到本地系统并命名为getin:
/usr/local/hadoop/bin/hadoop dfs -get in getin5、删除文档
删除HDFS下名为out的文档:
/usr/local/hadoop/bin/hadoop dfs -rmr out6、查看文件
查看HDFS下in文件中的内容:
/usr/local/hadoop/bin/hadoop dfs -cat in/*7、建立目录
/usr/local/hadoop/bin/hadoop dfs -mkdir /user/hadoop/examples(目录/目录名)只能一级一级的建目录。

8、复制文件
/usr/local/hadoop/bin/hadoop dfs -copyFromLocal 源路径 路径9、通过Hadoop命令把两个文件的内容合并起来
hdfs dfs -getmerge 位于hdfs中的原文件(里面有多个文件) 合并后的文件名
例如:
hdfs dfs -getmerge hdfs://Master:9000/data/SogouResult.txt CombinedResult 注:合并后的文件位于当前目录,不在hdfs中,是本地文件.
 

二、管理与更新
 

1、执行基本信息
查看HDFS的基本统计信息:
/usr/local/hadoop/bin/hadoop dfsadmin -report2、退出安全模式
NameNode在启动时会自动进入安全模式。安全模式是NameNode的一种状态,在这个阶段,文件系统不允许有任何修改。

系统显示Name node in safe mode,说明系统正处于安全模式,这时只需要等待十几秒即可,也可通过下面的命令退出安全模式:
/usr/local/hadoop/bin/hadoop dfsadmin -safemode leave3、进入安全模式
在必要情况下,可以通过以下命令把HDFS置于安全模式:
/usr/local/hadoop/bin/hadoop dfsadmin -safemode enter4、节点添加
添加一个新的DataNode节点,先在新加节点上安装好Hadoop,要和NameNode使用相同的配置(可以直接从NameNode复制),修改$HADOOP_HOME/conf/master文件,加入NameNode主机名。然后在NameNode节点上修改$HADOOP_HOME/conf/slaves文件,加入新节点名,再建立新加节点无密码的SSH连接,运行启动命令为:
/usr/local/hadoop/bin/start-all.sh5、负载均衡
HDFS的数据在各个DataNode中的分布可能很不均匀,尤其是在DataNode节点出现故障或新增DataNode节点时。新增数据块时NameNode对DataNode节点的选择策略也有可能导致数据块分布不均匀。用户可以使用命令重新平衡DataNode上的数据块的分布:
/usr/local/hadoop/bin/start-balancer.sh 查看全部


一、文件操作


1、列出HDFS下的文件
/usr/local/hadoop/bin/hadoop dfs -ls
2、列出HDFS文件下名为in的文档中的文件
/usr/local/hadoop/bin/hadoop dfs -ls in
3、上传文件
将hadoop目录下的test1文件上传到HDFS上并重命名为test
/usr/local/hadoop/bin/hadoop dfs -put test1 test
4、文件被复制到本地系统中
将HDFS中的in文件复制到本地系统并命名为getin:
/usr/local/hadoop/bin/hadoop dfs -get in getin
5、删除文档
删除HDFS下名为out的文档:
/usr/local/hadoop/bin/hadoop dfs -rmr out
6、查看文件
查看HDFS下in文件中的内容:
/usr/local/hadoop/bin/hadoop dfs -cat in/*
7、建立目录
/usr/local/hadoop/bin/hadoop dfs -mkdir /user/hadoop/examples(目录/目录名)
只能一级一级的建目录。

8、复制文件
/usr/local/hadoop/bin/hadoop dfs -copyFromLocal 源路径 路径
9、通过Hadoop命令把两个文件的内容合并起来
hdfs dfs -getmerge 位于hdfs中的原文件(里面有多个文件) 合并后的文件名
例如:
hdfs dfs -getmerge hdfs://Master:9000/data/SogouResult.txt CombinedResult
 注:合并后的文件位于当前目录,不在hdfs中,是本地文件.
 


二、管理与更新
 


1、执行基本信息
查看HDFS的基本统计信息:
/usr/local/hadoop/bin/hadoop dfsadmin -report
2、退出安全模式
NameNode在启动时会自动进入安全模式。安全模式是NameNode的一种状态,在这个阶段,文件系统不允许有任何修改。

系统显示Name node in safe mode,说明系统正处于安全模式,这时只需要等待十几秒即可,也可通过下面的命令退出安全模式:
/usr/local/hadoop/bin/hadoop dfsadmin -safemode leave
3、进入安全模式
在必要情况下,可以通过以下命令把HDFS置于安全模式:
/usr/local/hadoop/bin/hadoop dfsadmin -safemode enter
4、节点添加
添加一个新的DataNode节点,先在新加节点上安装好Hadoop,要和NameNode使用相同的配置(可以直接从NameNode复制),修改$HADOOP_HOME/conf/master文件,加入NameNode主机名。然后在NameNode节点上修改$HADOOP_HOME/conf/slaves文件,加入新节点名,再建立新加节点无密码的SSH连接,运行启动命令为:
/usr/local/hadoop/bin/start-all.sh
5、负载均衡
HDFS的数据在各个DataNode中的分布可能很不均匀,尤其是在DataNode节点出现故障或新增DataNode节点时。新增数据块时NameNode对DataNode节点的选择策略也有可能导致数据块分布不均匀。用户可以使用命令重新平衡DataNode上的数据块的分布:
/usr/local/hadoop/bin/start-balancer.sh

org.apache.hadoop.hbase.NotServingRegionException: Region

运维技术采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 154 次浏览 • 2017-06-27 17:44 • 来自相关话题

腾讯发布云实验室、开源开发工具,助力开发者连接AI未来

大数据/云计算图灵之歌 发表了文章 • 0 个评论 • 98 次浏览 • 2017-06-26 12:16 • 来自相关话题

当人工智能不再遥不可及,用户像“插上电”一样“接入云”,开发者再次迎来新一波的机遇。在云+未来峰会上,腾讯云正式推出“智能云”。而在6月22日的开发者专场上,腾讯发布面向开发者的云实验室,让未来AI技术唾手可得。

同时预告,针对AI领域,即将开源Angel、NCNN等项目,并表示支撑3000多家企业的腾讯高效开发工具TAPD将在腾讯云开放,以及明年初开放支持移动APP开发的持续集成云平台。
 
现场,腾讯云揭秘内测中的CDN边缘计算,可一次部署全球执行,应用在多个场景。同时腾讯云欢迎开发者参与到Serverless的优化中。以上分享进一步满足人工智能、云计算下开发者的需求(即希望使用更敏捷的开发、更敏捷的基础服务等),降低AI使用门槛,加速AI的落地。
 
著名Angular框架推广者大漠穷秋做了开场演讲,分享互联网的四波浪潮,即桌面互联网、移动互联网时代、云计算时代和人工智能时代。并表示,在桌面互联网时代,开发者或者初创企业想去做一件事情很困难,人工智能时代则不一样,开发者依然有发挥空间,这不只是巨头的红利时代,市场需求背后隐藏的未知领域需要各行业共同开拓。


陈子舜:腾讯云实验室发布,未来技术唾手可得

 

腾讯云技术总监陈子舜分享,“我的一个朋友和我分享他的见闻,‘一个优秀云计算工程师有5家企业在争抢,他们的平均薪资比传统IT人员高出40%’。”他表示,这是一个很好的时代,腾讯云希望将自身拥有的大数据、AI等前沿技术,向开发者开放,让未来技术变得唾手可得。

为此,腾讯云正式发布实验室,为开发者提供从学习工具、实验内容到经验分享的闭环服务,开发者可以获得一站式的沉浸式学习环境,使用微信扫码即可免费领取实验机器,直接采用真实的环境作为实验基础。同时,腾讯云还引入社区+实验室的服务模式,让开发者在技术社区提问或分享经验教程,帮助更多开发者解决问题。

按照腾讯云在开发者社区的计划,不仅为开发者提供开发者实验室,还会提供开源技术、开发工具和文档、线下活动、培训和认证等各类服务。


许勇:腾讯开源在路上,工程师热情参与

 

腾讯研发管理部总监许勇揭秘了腾讯开源之路,从腾讯人的角度,解读腾讯开源的技术。目前,腾讯已经开源的项目有RapidJSON、Tinker、WEUI、Mars、MSEC、Libco、GT、Tars、WCDB等,针对AI领域,腾讯还即将开源AI框架Angel、NCNN等项目,以满足高性能机器学习、天天P图及其他不同应用场景的需求。许勇表示,相比于国外成熟的开源社区,腾讯还在追赶阶段,不过,腾讯正被开源的力量唤醒,和开发者一起把中国的开源做得更好。

许勇致力于腾讯内部开源社区建设及外部开源项目管理,他分享到,腾讯内部开源社区提供了从轻量到重度参与开源的各种形式,可以简简单单的分享片段,也可以分享自己的开源项目,以实现更大的技术价值,建立自己的技术影响力。截止2016年,腾讯内部的开源组件达到了1600个以上,目前的日活跃用户数量在3000以上。

同时腾讯云作为腾讯开源的一支重要力量,积极参与开源社区,最近2个月加入3个开源组织,首先在5月加入CNCF基金会和Linux基金会,在容器服务和KVM虚拟化方面贡献自己的力量,同时于6月加入MariaDB基金会。去年腾讯也加入了Alloyteam基金会,腾讯同时也在运营独立开源社区OpenDaylight,在外界有不错的口碑,并汇聚了一群热心的开发者。腾讯也在积极贡献一些开源项目,包括docker,维护Hadoop、patch的提交等等,越来越多的腾讯工程师热情参与到开源中来。


陆莹:开放腾讯2万多人使用的敏捷研发平台TAPD 

 

面对复杂多变、快速迭代的开发环境,腾讯拥有2万多人的研发团队,同时进行3000多个项目,孕育400多个产品的背景下,如何进行高效合作?

腾讯产品专家陆莹的答案是腾讯敏捷研发平台TAPD,20个模块可以灵活应用,可以自由搭配适合自己研发过程的流程,赋予了团队更多的可能。去年6月份TAPD开始提供给腾讯投资的一些公司和腾讯云部分用户使用,到2017年5月,TAPD已经全面开放注册,目前成功支撑3000多家企业进行敏捷研发协作。 

她表示,将和腾讯云一起将TAPD开放给更多致力敏捷研发的伙伴们,“我们将会分享腾讯近十年的研发协作案例和经验,让腾讯云生态上的小伙伴们都能进行敏捷研发,让协作更敏捷。”


魏文强:腾讯将提供持续集成云平台,开放游戏经验



腾讯互娱持续集成平台负责人魏文强从Why、How两个角度带来了持续集成云平台上的一些思考。他表示,现在竞争越来越激烈,特别是游戏行业,经常是你问产品下一步要做什么事情,可能只有一个大概的方向,但具体做什么不知道,所以要求开发迭代越来越快,周期越来越短。

这样会导致什么问题?软件开发不是在最后产品部署阶段才有云上需求,而是贯穿整个生命周期,从软件开发初始阶段就要考虑云怎么部署。在云上提供集成平台服务,是必做的环节。此外,代码托管、持续集成、项目管理、工具链等云平台逐步发展,带来了持续集成平台的需求。

关于如何做,魏文强从突出自己特色、安全和稳定、构建速度以及最佳实践和灵活替换四个角度作了总结。他表示,在2018年初计划提供优先支持移动APP开发,特别是针对手游做特定优化的持续集成云平台,2018年年中对docker和windows进行支持。
 

余子军:揭秘腾讯云CDN边缘计算,解决多个关键问题

 

腾讯CDN技术总监余子军揭秘内测中的腾讯云CDN边缘计算,这是适应大数据、AI时代对网络加速需求而诞生的服务。余子军现场举例说到,腾讯的用户到腾讯的CDN平均距离是170多公里,如果采用光缆,成本非常昂贵的,而采用CDN可以很好地解决这个问题。

腾讯云CDN边缘计算可以在离用户更近的地方进行计算,一次部署全球执行,更快速更安全。还可以应用在多个场景,灵活敏捷低成本地解决关键问题:
•    图片自适应的场景:根据终端类型、网络状态和请求字段等决策编码方案,支持图片缩放、裁剪、水印等。
•    防盗链和权限控制的场景:可灵活控制全部禁止、部分禁止、限速的结果;还可以用在灰度测试中,新版本发布的时候。
•    控制发布进度的场景:灵活决策新版本的用户范围、设置Cookie标记用户和上报访问日志。


周军:腾讯云CAM应用,如何灵活保障用户信息的安全


 
腾讯云产品总监周军从腾讯云CAM应用案例,分享腾讯如何通过对用户认知、权限验证以及日志审计等各个环节的把控,为用户保障信息的安全、无泄漏。

“简单来说,在用户认证访问时,我们通常先问你是谁,问你想干什么。这些东西验证下来就让账户体系变得很复杂,这就是我们常说的鱼和熊掌不可兼得,安全与便捷也是一样的。”周军说,“如果没有安全问题,很多的服务成本可以去掉,不考虑黑客问题,不考虑别人盗用数据问题,安全是负成本的问题,但是要安全就很可能不便捷。”

为了让账户既安全又便捷,腾讯做了几件事情,第一个事情是账户关联,所有账户体系都支持。第二是认证体系里二次验证变得非常灵活,用户可以采用任何一种方式来验证。周军还提到,腾讯云、企业邮箱、企业微信都做到了账户互通,用户可以用一个企业微信账户体系来授权和管理腾讯云的所有东西。


黄文俊: Serverless让开发者抽离繁重运维

 

腾讯云技术专家黄文俊打了一个比方,一个基因数据公司,利用基因数据进行相应的数据分析,需要面对有各种各样的分析函数,不同的执行流程。为了解决这个问题,首先要准备相应的服务器,让用户提交数据,上传数据;每次提交来做相应执行,再用另外一个服务器接受这些任务,处理这些数据;真正处理数据的程序还要进行开发部署,完成了开发部署还要去规划,究竟要用多大的服务器,多少台服务器来准备,后期服务器的运维又将多么复杂,这是每一个开发者需要烦恼的问题。

“我们能否有一个更好的解决方法?把我们从繁重的运维上抽离出来?”黄文俊说,无服务器计算可以很好地解决这个问题,“这是一个很新的概念,无服务器是不是就没有服务器了?是不是真的Serverless了?不,Serverless不是说没有服务器,而是开发人员和运维人员不需要再考虑服务器,不需要再放太多的精力在上面,而是交给云。”

用户只需要上传代码即可以最便捷的方式使用腾讯云高效稳定的全球基础设施,并可实现毫秒级的弹性伸缩,服务成本低廉,代码按需运行,空闲时不收费。经测试,按调用次数和运行时间付费,在每个月请求不足百万时,使用无服务器云函数比使用多台云主机搭建集群的成本减少约70%,适用于云计算和AI时代下需要低门槛进入技术,以及体验佳的要求。

他提到,这里面有两个核心,一个是Function as a Service,以函数的形式委托到云上来,由云来做顶层管理。还有一个就是Backend as a Service,比如说对象存储、数据库、消息队列或者云的缓存。其中Function as a Service的核心就是腾讯云最新推出的产品——Serverless Cloud Function。目前腾讯云的Serverless架构在内测阶段,非常欢迎开发者积极参与到Serverless无服务器的优化当中,共筑最佳运维环境。

英特尔刘斌:FPGA异构计算的价值在计算力、灵活性、未来可扩展性

 

英特尔可编程解决方案事业部亚太区计算业务总经理刘斌带来FPGA异构计算前沿的分享,“我们看到一个问题,今天谈人工智能,特别是谈更多智能化事物的时候,可能会遇到需要解决感知的问题,需要解决决策的问题,需要解决执行的问题。异构的好处就是,在需要解决多种问题的时候,在计算力、效率灵活性、未来可扩展性上是它的价值所在。”

分享中,刘斌还讲述了异构计算出现的三个推动力,一是强计算、高性能计算的需求;二是数据的存取、访问、缓存的需求;三是成本的需求。他表示,异构计算是为解决问题复杂度而催生出的新技术。

异构的计算是解决现在所出现问题的主要结构,可以提供不同的价值,如何构建异构计算系统并提升开发者的生产力是目前的主要挑战,异构的结构下面是不是还存在其他的东西,是需要发展的方向。未来,异构性是长期存在的,怎么样在高阶上实现开发系统的融合,是短期内需要思考的问题。
  查看全部
当人工智能不再遥不可及,用户像“插上电”一样“接入云”,开发者再次迎来新一波的机遇。在云+未来峰会上,腾讯云正式推出“智能云”。而在6月22日的开发者专场上,腾讯发布面向开发者的云实验室,让未来AI技术唾手可得。

同时预告,针对AI领域,即将开源Angel、NCNN等项目,并表示支撑3000多家企业的腾讯高效开发工具TAPD将在腾讯云开放,以及明年初开放支持移动APP开发的持续集成云平台。
 
现场,腾讯云揭秘内测中的CDN边缘计算,可一次部署全球执行,应用在多个场景。同时腾讯云欢迎开发者参与到Serverless的优化中。以上分享进一步满足人工智能、云计算下开发者的需求(即希望使用更敏捷的开发、更敏捷的基础服务等),降低AI使用门槛,加速AI的落地。
 
著名Angular框架推广者大漠穷秋做了开场演讲,分享互联网的四波浪潮,即桌面互联网、移动互联网时代、云计算时代和人工智能时代。并表示,在桌面互联网时代,开发者或者初创企业想去做一件事情很困难,人工智能时代则不一样,开发者依然有发挥空间,这不只是巨头的红利时代,市场需求背后隐藏的未知领域需要各行业共同开拓。


陈子舜:腾讯云实验室发布,未来技术唾手可得

 

腾讯云技术总监陈子舜分享,“我的一个朋友和我分享他的见闻,‘一个优秀云计算工程师有5家企业在争抢,他们的平均薪资比传统IT人员高出40%’。”他表示,这是一个很好的时代,腾讯云希望将自身拥有的大数据、AI等前沿技术,向开发者开放,让未来技术变得唾手可得。

为此,腾讯云正式发布实验室,为开发者提供从学习工具、实验内容到经验分享的闭环服务,开发者可以获得一站式的沉浸式学习环境,使用微信扫码即可免费领取实验机器,直接采用真实的环境作为实验基础。同时,腾讯云还引入社区+实验室的服务模式,让开发者在技术社区提问或分享经验教程,帮助更多开发者解决问题。

按照腾讯云在开发者社区的计划,不仅为开发者提供开发者实验室,还会提供开源技术、开发工具和文档、线下活动、培训和认证等各类服务。


许勇:腾讯开源在路上,工程师热情参与

 

腾讯研发管理部总监许勇揭秘了腾讯开源之路,从腾讯人的角度,解读腾讯开源的技术。目前,腾讯已经开源的项目有RapidJSON、Tinker、WEUI、Mars、MSEC、Libco、GT、Tars、WCDB等,针对AI领域,腾讯还即将开源AI框架Angel、NCNN等项目,以满足高性能机器学习、天天P图及其他不同应用场景的需求。许勇表示,相比于国外成熟的开源社区,腾讯还在追赶阶段,不过,腾讯正被开源的力量唤醒,和开发者一起把中国的开源做得更好。

许勇致力于腾讯内部开源社区建设及外部开源项目管理,他分享到,腾讯内部开源社区提供了从轻量到重度参与开源的各种形式,可以简简单单的分享片段,也可以分享自己的开源项目,以实现更大的技术价值,建立自己的技术影响力。截止2016年,腾讯内部的开源组件达到了1600个以上,目前的日活跃用户数量在3000以上。

同时腾讯云作为腾讯开源的一支重要力量,积极参与开源社区,最近2个月加入3个开源组织,首先在5月加入CNCF基金会和Linux基金会,在容器服务和KVM虚拟化方面贡献自己的力量,同时于6月加入MariaDB基金会。去年腾讯也加入了Alloyteam基金会,腾讯同时也在运营独立开源社区OpenDaylight,在外界有不错的口碑,并汇聚了一群热心的开发者。腾讯也在积极贡献一些开源项目,包括docker,维护Hadoop、patch的提交等等,越来越多的腾讯工程师热情参与到开源中来。


陆莹:开放腾讯2万多人使用的敏捷研发平台TAPD 

 

面对复杂多变、快速迭代的开发环境,腾讯拥有2万多人的研发团队,同时进行3000多个项目,孕育400多个产品的背景下,如何进行高效合作?

腾讯产品专家陆莹的答案是腾讯敏捷研发平台TAPD,20个模块可以灵活应用,可以自由搭配适合自己研发过程的流程,赋予了团队更多的可能。去年6月份TAPD开始提供给腾讯投资的一些公司和腾讯云部分用户使用,到2017年5月,TAPD已经全面开放注册,目前成功支撑3000多家企业进行敏捷研发协作。 

她表示,将和腾讯云一起将TAPD开放给更多致力敏捷研发的伙伴们,“我们将会分享腾讯近十年的研发协作案例和经验,让腾讯云生态上的小伙伴们都能进行敏捷研发,让协作更敏捷。”


魏文强:腾讯将提供持续集成云平台,开放游戏经验



腾讯互娱持续集成平台负责人魏文强从Why、How两个角度带来了持续集成云平台上的一些思考。他表示,现在竞争越来越激烈,特别是游戏行业,经常是你问产品下一步要做什么事情,可能只有一个大概的方向,但具体做什么不知道,所以要求开发迭代越来越快,周期越来越短。

这样会导致什么问题?软件开发不是在最后产品部署阶段才有云上需求,而是贯穿整个生命周期,从软件开发初始阶段就要考虑云怎么部署。在云上提供集成平台服务,是必做的环节。此外,代码托管、持续集成、项目管理、工具链等云平台逐步发展,带来了持续集成平台的需求。

关于如何做,魏文强从突出自己特色、安全和稳定、构建速度以及最佳实践和灵活替换四个角度作了总结。他表示,在2018年初计划提供优先支持移动APP开发,特别是针对手游做特定优化的持续集成云平台,2018年年中对docker和windows进行支持。
 

余子军:揭秘腾讯云CDN边缘计算,解决多个关键问题

 

腾讯CDN技术总监余子军揭秘内测中的腾讯云CDN边缘计算,这是适应大数据、AI时代对网络加速需求而诞生的服务。余子军现场举例说到,腾讯的用户到腾讯的CDN平均距离是170多公里,如果采用光缆,成本非常昂贵的,而采用CDN可以很好地解决这个问题。

腾讯云CDN边缘计算可以在离用户更近的地方进行计算,一次部署全球执行,更快速更安全。还可以应用在多个场景,灵活敏捷低成本地解决关键问题:
•    图片自适应的场景:根据终端类型、网络状态和请求字段等决策编码方案,支持图片缩放、裁剪、水印等。
•    防盗链和权限控制的场景:可灵活控制全部禁止、部分禁止、限速的结果;还可以用在灰度测试中,新版本发布的时候。
•    控制发布进度的场景:灵活决策新版本的用户范围、设置Cookie标记用户和上报访问日志。


周军:腾讯云CAM应用,如何灵活保障用户信息的安全


 
腾讯云产品总监周军从腾讯云CAM应用案例,分享腾讯如何通过对用户认知、权限验证以及日志审计等各个环节的把控,为用户保障信息的安全、无泄漏。

“简单来说,在用户认证访问时,我们通常先问你是谁,问你想干什么。这些东西验证下来就让账户体系变得很复杂,这就是我们常说的鱼和熊掌不可兼得,安全与便捷也是一样的。”周军说,“如果没有安全问题,很多的服务成本可以去掉,不考虑黑客问题,不考虑别人盗用数据问题,安全是负成本的问题,但是要安全就很可能不便捷。”

为了让账户既安全又便捷,腾讯做了几件事情,第一个事情是账户关联,所有账户体系都支持。第二是认证体系里二次验证变得非常灵活,用户可以采用任何一种方式来验证。周军还提到,腾讯云、企业邮箱、企业微信都做到了账户互通,用户可以用一个企业微信账户体系来授权和管理腾讯云的所有东西。


黄文俊: Serverless让开发者抽离繁重运维

 

腾讯云技术专家黄文俊打了一个比方,一个基因数据公司,利用基因数据进行相应的数据分析,需要面对有各种各样的分析函数,不同的执行流程。为了解决这个问题,首先要准备相应的服务器,让用户提交数据,上传数据;每次提交来做相应执行,再用另外一个服务器接受这些任务,处理这些数据;真正处理数据的程序还要进行开发部署,完成了开发部署还要去规划,究竟要用多大的服务器,多少台服务器来准备,后期服务器的运维又将多么复杂,这是每一个开发者需要烦恼的问题。

“我们能否有一个更好的解决方法?把我们从繁重的运维上抽离出来?”黄文俊说,无服务器计算可以很好地解决这个问题,“这是一个很新的概念,无服务器是不是就没有服务器了?是不是真的Serverless了?不,Serverless不是说没有服务器,而是开发人员和运维人员不需要再考虑服务器,不需要再放太多的精力在上面,而是交给云。”

用户只需要上传代码即可以最便捷的方式使用腾讯云高效稳定的全球基础设施,并可实现毫秒级的弹性伸缩,服务成本低廉,代码按需运行,空闲时不收费。经测试,按调用次数和运行时间付费,在每个月请求不足百万时,使用无服务器云函数比使用多台云主机搭建集群的成本减少约70%,适用于云计算和AI时代下需要低门槛进入技术,以及体验佳的要求。

他提到,这里面有两个核心,一个是Function as a Service,以函数的形式委托到云上来,由云来做顶层管理。还有一个就是Backend as a Service,比如说对象存储、数据库、消息队列或者云的缓存。其中Function as a Service的核心就是腾讯云最新推出的产品——Serverless Cloud Function。目前腾讯云的Serverless架构在内测阶段,非常欢迎开发者积极参与到Serverless无服务器的优化当中,共筑最佳运维环境。

英特尔刘斌:FPGA异构计算的价值在计算力、灵活性、未来可扩展性

 

英特尔可编程解决方案事业部亚太区计算业务总经理刘斌带来FPGA异构计算前沿的分享,“我们看到一个问题,今天谈人工智能,特别是谈更多智能化事物的时候,可能会遇到需要解决感知的问题,需要解决决策的问题,需要解决执行的问题。异构的好处就是,在需要解决多种问题的时候,在计算力、效率灵活性、未来可扩展性上是它的价值所在。”

分享中,刘斌还讲述了异构计算出现的三个推动力,一是强计算、高性能计算的需求;二是数据的存取、访问、缓存的需求;三是成本的需求。他表示,异构计算是为解决问题复杂度而催生出的新技术。

异构的计算是解决现在所出现问题的主要结构,可以提供不同的价值,如何构建异构计算系统并提升开发者的生产力是目前的主要挑战,异构的结构下面是不是还存在其他的东西,是需要发展的方向。未来,异构性是长期存在的,怎么样在高阶上实现开发系统的融合,是短期内需要思考的问题。
 

​大数据与商业智能BI的关系密不可分

大数据/云计算OT学习平台 发表了文章 • 0 个评论 • 103 次浏览 • 2017-06-20 16:33 • 来自相关话题

大数据应用的数据来源,主要是包括非机构化的数据、各种系统数据、数据库数据等。而BI大数据应用则是在数据集成方面的技术更加成熟,对于数据的提取和挖掘方面的要求来说,数据集成平台会帮助企业实现数据的流通和交互使用,而企业内部部署BI应用就是为了更好的分享和使用数据。






大数据对于传统BI,既有继承,也有发展;BI与大数据区别在于前者更倾向于决策,对事实描述更多是基于群体共性,帮助决策者掌握宏观统计趋势,适合经营运营指标支撑类问题,大数据则内涵更广,倾向于刻画个体,更多的在于个性化的决策。
BI的发展要从传统的商务智能模式开始转换,对于企业来说,BI不仅仅是一个IT项目,更是一种管理和思维的方式,从技术的部署到业务的流程规划,BI迎来新的发展。对于大数据来说,现阶段更多的大数据关注在非结构化数据,不同的数据分析工具的出现和行内的应用范围不断的加大,对于大数据应用来说,怎么与应用的行业进行一个深层次的结合才是最重要的。

更多关于大数据的知识请关注OTPUB《大数据论坛》
OTpub,专业的IT学习直播平台:www.otpub.com
  查看全部
大数据应用的数据来源,主要是包括非机构化的数据、各种系统数据、数据库数据等。而BI大数据应用则是在数据集成方面的技术更加成熟,对于数据的提取和挖掘方面的要求来说,数据集成平台会帮助企业实现数据的流通和交互使用,而企业内部部署BI应用就是为了更好的分享和使用数据。

大数据与商业智能BI的关系密不可分.jpg


大数据对于传统BI,既有继承,也有发展;BI与大数据区别在于前者更倾向于决策,对事实描述更多是基于群体共性,帮助决策者掌握宏观统计趋势,适合经营运营指标支撑类问题,大数据则内涵更广,倾向于刻画个体,更多的在于个性化的决策。
BI的发展要从传统的商务智能模式开始转换,对于企业来说,BI不仅仅是一个IT项目,更是一种管理和思维的方式,从技术的部署到业务的流程规划,BI迎来新的发展。对于大数据来说,现阶段更多的大数据关注在非结构化数据,不同的数据分析工具的出现和行内的应用范围不断的加大,对于大数据应用来说,怎么与应用的行业进行一个深层次的结合才是最重要的。

更多关于大数据的知识请关注OTPUB《大数据论坛
OTpub,专业的IT学习直播平台:www.otpub.com
 

腾讯云正式成为MariaDB基金会白金会员

数据库图灵之歌 发表了文章 • 0 个评论 • 139 次浏览 • 2017-06-16 16:35 • 来自相关话题

6月16日,全球开源组织MariaDB基金会宣布,腾讯云正式成为MariaDB基金会白金会员,这是基金会最高级别会员。这也是腾讯云继上个月加入CNCF基金会和Linux基金会后,在开源界的又一项新动作,意味腾讯云在开源领域的步伐正在不断深入,从IaaS的开源进入到PaaS的开源。
 


腾讯云将输出腾讯在MariaDB数据库上的经验和技术。腾讯云专家工程师程彬加入基金会成员组,成为全球仅有的7位官方成员之一。程彬负责腾讯云数据库CDB以及内核TXSQL的研发,专注于数据库和分布式存储领域相关技术和产品。他将代表腾讯云的数据库团队参加基金会每周的技术会议,提供MariaDB数据库的意见和建议,并在内部推动腾讯云MariaDB的开源进程,推动MariaDB在中国的开源工作。  
 
MariaDB基金会主席高度评价腾讯云
 
MariaDB基金会主席 Otto Kekäläinen表示:“MariaDB是未来的IT基础设施的一个基本组成部分,腾讯云在这个领域不断的思考和布局,具备锐意开创未来的主宰领导力。”他同时指出,强大的开源文化生长在中国以及亚洲,基金会的目标是将来在亚洲发起更多的活动。我们下一个MariaDB 开发者大会将在中国深圳举行。
 
MariaDB基金会官方同时评价,腾讯云的加入为基金会的发展提供强有力的资源支持,保障MariaDB开源生态的良好运转,为不断成长的用户和开发者提供服务。
 
MariaDB是由MySQL之父Michael Widenius于2009年开创的一个MySQL分支,在MySQL被商业企业收购后,为保证行业仍有开源可用的兼容MySQL的分支可用,Michael Widenius在创立了 MariaDB的同时,还成立了非赢利组织 MariaDB 基金会为MariaDB 项目、用户和开发者社区提供基础架构支持。目前MariaDB是发展最快的MySQL分支版本,新版本发布速度已经超过了商用的MySQL版本,在开源数据库领域拥有较强的技术影响力。
 
腾讯云将重点开源MariaDB内核积累
 
在腾讯内部,一直有一个数据库内核团队,在MySQL和MariaDB基础上之上做出改进优化,重点排出一些平时难以触发的bug,并在此基础上打造出了腾讯云的数据库产品。
 
在参与MySQL和MariaDB优化的过程中,腾讯云完成了主备节点锁拆分、动态调整各种级别复制参数,以及binlog写优化等;发现并解决了刷脏死锁引起的 innodb 600S crash 问题、memory barrier 引起的 hang 问题以及字符串问题等影响数据库稳定的问题。
 
未来,腾讯云还将投入更多精力到内核研发上,并会合并之前的一些内部稳定使用功能发布开源版本,尤其是适合云环境的功能的开源版本,为开源组织贡献自己的一份力量。
 
腾讯云深度拥抱全球开源生态圈
 
近年来,腾讯云大力拥抱开源事业。今年5月,腾讯云以金牌会员的身份正式加入CNCF基金会,为CNCF开源社区开放自身的Kubernetes相关特性,释放自身在容器服务、KVM虚拟化等方面的优势积累。同时基于腾讯云在Linux领域的积极贡献,腾讯云获CNCF基金会邀请加入Linux基金会。
 
此次腾讯云加入MariaDB基金会,将在数据库内核研发和功能开发方面开放助力开源,与国际的数据库专家团体建立更密切的联系,推动开放更多的技术开源。
 
未来腾讯云继续加大在开源领域的步伐,深度拥抱全球开源生态圈,从产品出发,基于大量用户在产品使用的感受和腾讯云的服务实践,将有价值的特性反馈给社区,与社区一起完善相关特性,同时从社区获得广泛的用户反馈,再次回到产品,提升腾讯云的产品体验。
 
 
延伸阅读:
腾讯云加入MariaDB基金会的官方消息:
https://mariadb.org/tencent-cloud-becomes-platinum-sponsor-mariadb-foundation/ 查看全部
6月16日,全球开源组织MariaDB基金会宣布,腾讯云正式成为MariaDB基金会白金会员,这是基金会最高级别会员。这也是腾讯云继上个月加入CNCF基金会和Linux基金会后,在开源界的又一项新动作,意味腾讯云在开源领域的步伐正在不断深入,从IaaS的开源进入到PaaS的开源。
 


腾讯云将输出腾讯在MariaDB数据库上的经验和技术。腾讯云专家工程师程彬加入基金会成员组,成为全球仅有的7位官方成员之一。程彬负责腾讯云数据库CDB以及内核TXSQL的研发,专注于数据库和分布式存储领域相关技术和产品。他将代表腾讯云的数据库团队参加基金会每周的技术会议,提供MariaDB数据库的意见和建议,并在内部推动腾讯云MariaDB的开源进程,推动MariaDB在中国的开源工作。  
 
MariaDB基金会主席高度评价腾讯云
 
MariaDB基金会主席 Otto Kekäläinen表示:“MariaDB是未来的IT基础设施的一个基本组成部分,腾讯云在这个领域不断的思考和布局,具备锐意开创未来的主宰领导力。”他同时指出,强大的开源文化生长在中国以及亚洲,基金会的目标是将来在亚洲发起更多的活动。我们下一个MariaDB 开发者大会将在中国深圳举行。
 
MariaDB基金会官方同时评价,腾讯云的加入为基金会的发展提供强有力的资源支持,保障MariaDB开源生态的良好运转,为不断成长的用户和开发者提供服务。
 
MariaDB是由MySQL之父Michael Widenius于2009年开创的一个MySQL分支,在MySQL被商业企业收购后,为保证行业仍有开源可用的兼容MySQL的分支可用,Michael Widenius在创立了 MariaDB的同时,还成立了非赢利组织 MariaDB 基金会为MariaDB 项目、用户和开发者社区提供基础架构支持。目前MariaDB是发展最快的MySQL分支版本,新版本发布速度已经超过了商用的MySQL版本,在开源数据库领域拥有较强的技术影响力。
 
腾讯云将重点开源MariaDB内核积累
 
在腾讯内部,一直有一个数据库内核团队,在MySQL和MariaDB基础上之上做出改进优化,重点排出一些平时难以触发的bug,并在此基础上打造出了腾讯云的数据库产品。
 
在参与MySQL和MariaDB优化的过程中,腾讯云完成了主备节点锁拆分、动态调整各种级别复制参数,以及binlog写优化等;发现并解决了刷脏死锁引起的 innodb 600S crash 问题、memory barrier 引起的 hang 问题以及字符串问题等影响数据库稳定的问题。
 
未来,腾讯云还将投入更多精力到内核研发上,并会合并之前的一些内部稳定使用功能发布开源版本,尤其是适合云环境的功能的开源版本,为开源组织贡献自己的一份力量。
 
腾讯云深度拥抱全球开源生态圈
 
近年来,腾讯云大力拥抱开源事业。今年5月,腾讯云以金牌会员的身份正式加入CNCF基金会,为CNCF开源社区开放自身的Kubernetes相关特性,释放自身在容器服务、KVM虚拟化等方面的优势积累。同时基于腾讯云在Linux领域的积极贡献,腾讯云获CNCF基金会邀请加入Linux基金会。
 
此次腾讯云加入MariaDB基金会,将在数据库内核研发和功能开发方面开放助力开源,与国际的数据库专家团体建立更密切的联系,推动开放更多的技术开源。
 
未来腾讯云继续加大在开源领域的步伐,深度拥抱全球开源生态圈,从产品出发,基于大量用户在产品使用的感受和腾讯云的服务实践,将有价值的特性反馈给社区,与社区一起完善相关特性,同时从社区获得广泛的用户反馈,再次回到产品,提升腾讯云的产品体验。
 
 
延伸阅读:
腾讯云加入MariaDB基金会的官方消息:
https://mariadb.org/tencent-cloud-becomes-platinum-sponsor-mariadb-foundation/

【直播预告】告别平庸,数据时代就要不一样!

大数据/云计算OT学习平台 发表了文章 • 0 个评论 • 117 次浏览 • 2017-06-05 15:44 • 来自相关话题

大数据时代,数据分析对于业务决策的帮助越来越大,它帮助企业中的业务人员在保证数据时效性的前提下,通过自助式数据分析,帮助企业从上到下实现数据化运营。
那么,我们的数据来源于何处呢?流程数据、机器生成数据,当然还有我们产生的数据,因此,无论是从市场环境还是评测机构报告来看,大数据时代已经启动,数据分析也更为重要。

传统报表
无交互、格式固定、实施缓慢






蜕变后的报表
可交互、生成快、可分享






让数据生动起来,左右逢源?Tableau都能帮您实现!

Tableau 整合了您的数据架构,让您用能理解的方式从视觉上分析您的数据。

 Tableau Server
可提供基于浏览器和移动分析的商业智能应用程序。无需编程,即可创建报告和仪表板。






 Tableau Desktop
实时可视化分析实现随心所欲的数据探索,交互式仪表板帮助用户即时发现隐藏的见解。






想深入了解Tableau
机会来了
6月6日14 : 00
“人人都是数据分析师”
直播活动即将开启
技术大神亲授数据分析大法

讲师介绍
林旭
从事Tableau售前工作
通过Tableau银牌和QA等级认证


活动日程
14 : 00-14 : 10 讲师介绍
14 : 10-14 : 30 Tableau如何让数据生动起来
14 : 30-15 : 40 Tableau功能展示及使用技巧
15 : 40-16 : 00 互动答疑
 
点击此处报名观看直播>>> 查看全部
大数据时代,数据分析对于业务决策的帮助越来越大,它帮助企业中的业务人员在保证数据时效性的前提下,通过自助式数据分析,帮助企业从上到下实现数据化运营。
那么,我们的数据来源于何处呢?流程数据、机器生成数据,当然还有我们产生的数据,因此,无论是从市场环境还是评测机构报告来看,大数据时代已经启动,数据分析也更为重要。

传统报表
无交互、格式固定、实施缓慢

【直播预告】告别平庸,数据时代就要不一样!.webp_.jpg


蜕变后的报表
可交互、生成快、可分享

【直播预告】告别平庸,数据时代就要不一样!2.webp_.jpg


让数据生动起来,左右逢源?Tableau都能帮您实现!

Tableau 整合了您的数据架构,让您用能理解的方式从视觉上分析您的数据。

 Tableau Server
可提供基于浏览器和移动分析的商业智能应用程序。无需编程,即可创建报告和仪表板。

【直播预告】告别平庸,数据时代就要不一样!3.webp_.jpg


 Tableau Desktop
实时可视化分析实现随心所欲的数据探索,交互式仪表板帮助用户即时发现隐藏的见解。

【直播预告】告别平庸,数据时代就要不一样!4.webp_.jpg


想深入了解Tableau
机会来了
6月6日14 : 00
“人人都是数据分析师”
直播活动即将开启
技术大神亲授数据分析大法


讲师介绍
林旭
从事Tableau售前工作
通过Tableau银牌和QA等级认证


活动日程
14 : 00-14 : 10 讲师介绍
14 : 10-14 : 30 Tableau如何让数据生动起来
14 : 30-15 : 40 Tableau功能展示及使用技巧
15 : 40-16 : 00 互动答疑
 
点击此处报名观看直播>>>
条新动态, 点击查看
采菊篱下

采菊篱下 回答了问题 • 2015-10-18 20:19 • 2 个回复 不感兴趣

Hadoop可以运行单机模式吗?

赞同来自:

可以的,hadoop可以运行如下三种模式:

单机模式
伪分布式模式
全分布式模式
可以的,hadoop可以运行如下三种模式:

单机模式
伪分布式模式
全分布式模式

CDH Hadoop + HBase HA 部署详解

大数据/云计算采菊篱下 发表了文章 • 0 个评论 • 915 次浏览 • 2016-11-07 21:07 • 来自相关话题

CDH 的部署和 Apache Hadoop 的部署是没有任何区别的。这里着重的是 HA的部署,需要特殊说明的是NameNode HA 需要依赖 Zookeeper
 

准备

Hosts文件配置:
cat > /etc/hosts << _HOSTS_
127.0.0.1 localhost
10.0.2.59 cdh-m1
10.0.2.60 cdh-m2
10.0.2.61 cdh-s1
_HOSTS_各个节点服务情况
cdh-m1 Zookeeper JournalNode NameNode DFSZKFailoverController HMaster
cdh-m2 Zookeeper JournalNode NameNode DFSZKFailoverController HMaster
cdh-s1 Zookeeper JournalNode DataNode HRegionServer对几个新服务说明下: 
JournalNode 用于同步 NameNode 元数据,和 Zookeeper 一样需要 2N+1个节点存活集群才可用。DFSZKFailoverController(ZKFC) 用于主备切换,类似 Keepalived 所扮演的角色。
 
NTP 服务
设置时区
rm -f /etc/localtime
ln -s /usr/share/zoneinfo/UTC /etc/localtime配置NTP Server
yum install -y ntp
cat > /etc/ntp.conf << _NTP_
driftfile /var/lib/ntp/drift

restrict default nomodify
restrict -6 default nomodify

server cn.ntp.org.cn prefer
server news.neu.edu.cn iburst
server dns.sjtu.edu.cn iburst
server 127.127.1.1 iburst

tinker dispersion 100
tinker step 1800
tinker stepout 3600
includefile /etc/ntp/crypto/pw

keys /etc/ntp/keys
_NTP_

# NTP启动时立即同步
cat >> /etc/ntp/step-tickers << _NTP_
server cn.ntp.org.cn prefer
server news.neu.edu.cn iburst
server dns.sjtu.edu.cn iburst
_NTP_

# 同步硬件时钟
cat >> /etc/sysconfig/ntpd << _NTPHW_
SYNC_HWCLOCK=yes
_NTPHW_启动并设置开机自启动
/etc/init.d/ntpd start
chkconfig ntpd on配置 NTP Client
yum install -y ntp
# 注意修改内网NTP Server地址
cat > /etc/ntp.conf << _NTP_
driftfile /var/lib/ntp/drift

restrict default nomodify
restrict -6 default nomodify

restrict 127.0.0.1
restrict -6 ::1

server 10.0.2.59 prefer

tinker dispersion 100
tinker step 1800
tinker stepout 3600
includefile /etc/ntp/crypto/pw

keys /etc/ntp/keys
_NTP_

# NTP启动时立即同步
cat >> /etc/ntp/step-tickers << _NTP_
server 10.0.2.59 prefer
_NTP_

# 同步硬件时钟
cat >> /etc/sysconfig/ntpd << _NTPHW_
SYNC_HWCLOCK=yes
_NTPHW_启动并设置开机自启动
/etc/init.d/ntpd start
chkconfig ntpd on检查 NTP 同步
ntpq -p

# 结果
remote refid st t when poll reach delay offset jitter
==============================================================================
*time7.aliyun.co 10.137.38.86 2 u 17 64 3 44.995 5.178 0.177
news.neu.edu.cn .INIT. 16 u - 64 0 0.000 0.000 0.000
202.120.2.90 .INIT. 16 u - 64 0 0.000 0.000 0.000JDK
创建目录
mkdir -p /data/{install,app,logs,pid,appData}
mkdir /data/appData/tmpcd /data/install
wget -c http://oracle.com/jdk-7u51-linux-x64.gz
tar xf jdk-7u51-linux-x64.gz -C /data/app
cd /data/app
ln -s jdk1.7.0_51 jdk1.7
cat >> /etc/profile << _PATH_
export JAVA_HOME=/data/app/jdk1.7
export CLASSPATH=.:\$JAVA_HOME/lib/dt.jar:\$JAVA_HOME/lib/tools.jar
export PATH=\$JAVA_HOME/bin:\$PATH
_PATH_
source /etc/profile
创建运行账户
useradd -u 600 run安装包
http://archive.cloudera.com/cdh5/cdh/5/
cd /data/install
wget -c http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.4.5.tar.gz
wget -c http://archive.apache.org/dist/zookeeper/zookeeper-3.4.5/zookeeper-3.4.5.tar.gz
wget -c http://archive.cloudera.com/cdh5/cdh/5/hbase-1.0.0-cdh5.4.5.tar.gz

安装 Zookeeper

cd /data/install
tar xf zookeeper-3.4.5.tar.gz -C /data/app
cd /data/app
ln -s zookeeper-3.4.5 zookeeper设置环境变量
sed -i '/^export PATH=/i\export ZOOKEEPER_HOME=/data/app/zookeeper' /etc/profile
sed -i 's#export PATH=#&\$ZOOKEEPER_HOME/bin:#' /etc/profile
source /etc/profile删除无用文件
cd $ZOOKEEPER_HOME
rm -rf *xml *txt zookeeper-3.4.5.jar.* src recipes docs dist-maven contrib
rm -f $ZOOKEEPER_HOME/bin/*.cmd $ZOOKEEPER_HOME/bin/*.txt
rm -f $ZOOKEEPER_HOME/conf/zoo_sample.cfg创建数据目录
mkdir -p /data/appData/zookeeper/{data,logs}配置
cat > $ZOOKEEPER_HOME/conf/zoo.cfg << _ZOO_
tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
dataDir=/data/appData/zookeeper/data
dataLogDir=/data/appData/zookeeper/logs
server.1=cdh-m1:2888:3888
server.2=cdh-m2:2888:3888
server.3=cdh-s1:2888:3888
_ZOO_修改Zookeeper的日志打印方式,与日志路径设置
编辑
$ZOOKEEPER_HOME/bin/zkEnv.sh在27行后加入两个变量
ZOO_LOG_DIR=/data/logs/zookeeper
ZOO_LOG4J_PROP="INFO,ROLLINGFILE"创建 myid文件
# 注意myid与配置文件保持一致
echo 1 >/data/appData/zookeeper/data/myid设置目录权限
chown -R run.run /data/{app,appData,logs}启动、停止
# 启动
runuser - run -c 'zkServer.sh start'
# 停止
runuser - run -c 'zkServer.sh stop'

安装 Hadoop

tar xf hadoop-2.6.0-cdh5.4.5.tar.gz -C /data/app
cd /data/app
ln -s hadoop-2.6.0-cdh5.4.5 hadoop设置环境变量
sed -i '/^export PATH=/i\export HADOOP_HOME=/data/app/hadoop' /etc/profile
sed -i 's#export PATH=#&\$HADOOP_HOME/bin:\$HADOOP_HOME/sbin:#' /etc/profile
source /etc/profile删除无用文件
cd $HADOOP_HOME
rm -rf *txt share/doc src examples* include bin-mapreduce1 cloudera
find . -name "*.cmd"|xargs rm -f新建数据目录
mkdir -p /data/appData/hdfs/{name,edits,data,jn,tmp}配置
切换到配置文件目录
cd $HADOOP_HOME/etc/hadoop编辑 core-site.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<!-- HDFS 集群名称,可指定端口 -->
<property>
<name>fs.defaultFS</name>
<value>hdfs://hdfs-cdh</value>
</property>

<!-- 临时文件目录 -->
<property>
<name>hadoop.tmp.dir</name>
<value>/data/appData/hdfs/tmp</value>
</property>

<!-- 回收站设置,0不启用回收站,1440 表示1440分钟后删除 -->
<property>
<name>fs.trash.interval</name>
<value>1440</value>
</property>

<!-- SequenceFiles在读写中可以使用的缓存大小,单位 bytes 默认 4096 -->
<property>
<name>io.file.buffer.size</name>
<value>131072</value>
</property>

<!-- 可用压缩算法,启用在hdfs-site.xml中,需要编译动态链接库才能用 -->
<property>
<name>io.compression.codecs</name>
<value>org.apache.hadoop.io.compress.SnappyCodec</value>
</property>
</configuration>编辑 hdfs-site.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<!-- 指定hdfs 集群名称,需要和core-site.xml中的保持一致 -->
<property>
<name>dfs.nameservices</name>
<value>hdfs-cdh</value>
</property>

<!-- 指定 Zookeeper 用于NameNode HA,默认官方配置在core-site.xml中,为了查看清晰配置到hdfs-site.xml也是可用的 -->
<property>
<name>ha.zookeeper.quorum</name>
<value>cdh-m1:2181,cdh-m2:2181,cdh-s1:2181</value>
</property>

<!-- hdfs-cdh 下有两个NameNode,分别为 nn1,nn2 -->
<property>
<name>dfs.ha.namenodes.hdfs-cdh</name>
<value>nn1,nn2</value>
</property>

<!-- nn1 RPC通信地址 -->
<property>
<name>dfs.namenode.rpc-address.hdfs-cdh.nn1</name>
<value>cdh-m1:9000</value>
</property>

<!-- nn1 HTTP通信地址 -->
<property>
<name>dfs.namenode.http-address.hdfs-cdh.nn1</name>
<value>cdh-m1:50070</value>
</property>

<!-- nn2 RPC通信地址 -->
<property>
<name>dfs.namenode.rpc-address.hdfs-cdh.nn2</name>
<value>cdh-m2:9000</value>
</property>

<!-- nn2 HTTP通信地址 -->
<property>
<name>dfs.namenode.http-address.hdfs-cdh.nn2</name>
<value>cdh-m2:50070</value>
</property>

<!-- 指定NameNode元数据在JournalNode上的存储路径 -->
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://cdh-m1:8485;cdh-m2:8485;cdh-s1:8485;/hdfs-cdh</value>
</property>

<!-- 开启NameNode失败自动切换 -->
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>

<!-- 配置主备切换实现方式 -->
<property>
<name>dfs.client.failover.proxy.provider.hdfs-cdh</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

<!-- 配置主备切换方法,每个方法一行-->
<property>
<name>dfs.ha.fencing.methods</name>
<value>
sshfence
shell(/bin/true)
</value>
</property>

<!-- 指定运行用户的秘钥,需要NameNode双向免密码登录,用于主备自动切换 -->
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/run/.ssh/id_rsa</value>
</property>

<!-- 配置sshfence 超时时间 -->
<property>
<name>dfs.ha.fencing.ssh.connect-timeout</name>
<value>50000</value>
</property>

<!-- NameNode 数据本地存储路径 -->
<property>
<name>dfs.namenode.name.dir</name>
<value>/data/appData/hdfs/name</value>
</property>

<!-- DataNode 数据本地存储路径 -->
<property>
<name>dfs.datanode.data.dir</name>
<value>/data/appData/hdfs/data</value>
</property>

<!-- JournalNode 数据本地存储路径 -->
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/data/appData/hdfs/jn</value>
</property>

<!-- 修改文件存储到edits,定期同步到DataNode -->
<property>
<name>dfs.namenode.edits.noeditlogchannelflush</name>
<value>true</value>
</property>

<!-- edits 数据本地存储路径 -->
<property>
<name>dfs.namenode.edits.dir</name>
<value>/data/appData/hdfs/edits</value>
</property>

<!-- 开启Block Location metadata允许impala知道数据块在哪块磁盘上 默认关闭 -->
<property>
<name>dfs.datanode.hdfs-blocks-metadata.enabled</name>
<value>true</value>
</property>

<!-- 权限检查 默认开启 -->
<property>
<name>dfs.permissions.enabled</name>
<value>false</value>
</property>

<!-- block 大小设置 -->
<property>
<name>dfs.blocksize</name>
<value>64m</value>
</property>
</configuration>小于5个DataNode建议添加如下配置
<!-- 数据副本数量,不能超过DataNode数量,大集群建议使用默认值 默认 3 -->
<property>
<name>dfs.replication</name>
<value>2</value>
</property>

<!-- 当副本写入失败时不分配新节点,小集群适用 -->
<property>
<name>dfs.client.block.write.replace-datanode-on-failure.policy</name>
<value>NEVER</value>
</property>在 hadoop-env.sh 中添加如下变量
export JAVA_HOME=/data/app/jdk1.7
export HADOOP_LOG_DIR=/data/logs/hadoop
export HADOOP_PID_DIR=/data/pid
# SSH端口 可选
export HADOOP_SSH_OPTS="-p 36000"Heap 设置,单位 MB
export HADOOP_HEAPSIZE=1024权限设置
chown -R run.run /data/{app,appData,logs}
chmod 777 /data/pid格式化
格式化只需要执行一次,格式化之前启动Zookeeper
 
切换用户
su - run启动所有 JournalNode
hadoop-daemon.sh start journalnode格式化 Zookeeper(为 ZKFC 创建znode)
hdfs zkfc -formatZKNameNode 主节点格式化并启动
hdfs namenode -format
hadoop-daemon.sh start namenodeNameNode 备节点同步数据并启动
hdfs namenode -bootstrapStandby
hadoop-daemon.sh start namenode启动 ZKFC
hadoop-daemon.sh start zkfc启动 DataNode
hadoop-daemon.sh start datanode启动与停止
切换用户
su - run集群批量启动
需要配置运行用户ssh-key免密码登录,与$HADOOP_HOME/etc/hadoop/slaves
# 启动
start-dfs.sh
# 停止
stop-dfs.sh单服务启动停止
启动HDFS
hadoop-daemon.sh start journalnode
hadoop-daemon.sh start namenode
hadoop-daemon.sh start zkfc
hadoop-daemon.sh start datanode停止HDFS
hadoop-daemon.sh stop datanode
hadoop-daemon.sh stop namenode
hadoop-daemon.sh stop journalnode
hadoop-daemon.sh stop zkfc
测试
HDFS HA 测试
打开 NameNode 状态页:
http://cdh-m1:50010
http://cdh-m2:50010 

在 Overview 后面能看见 active 或 standby,active 为当前 Master,停止 active 上的 NameNode,检查 standby是否为 active。
 
HDFS 测试
hadoop fs -mkdir /test
hadoop fs -put /etc/hosts /test
hadoop fs -ls /test结果:
-rw-r--r-- 2 java supergroup 89 2016-06-15 10:30 /test/hosts
# 其中权限后面的列(这里的2)代表文件总数,即副本数量。HDFS 管理命令
# 动态加载 hdfs-site.xml
hadoop dfsadmin -refreshNodes

HBase安装配置

cd /data/install
tar xf hbase-1.0.0-cdh5.4.5.tar.gz -C /data/app
cd /data/app
ln -s hbase-1.0.0-cdh5.4.5 hbase设置环境变量
sed -i '/^export PATH=/i\export HBASE_HOME=/data/app/hbase' /etc/profile
sed -i 's#export PATH=#&\$HBASE_HOME/bin:#' /etc/profile
source /etc/profile删除无用文件
cd $HBASE_HOME
rm -rf *.txt pom.xml src docs cloudera dev-support hbase-annotations hbase-assembly hbase-checkstyle hbase-client hbase-common hbase-examples hbase-hadoop2-compat hbase-hadoop-compat hbase-it hbase-prefix-tree hbase-protocol hbase-rest hbase-server hbase-shell hbase-testing-util hbase-thrift
find . -name "*.cmd"|xargs rm -f配置
进入配置文件目录
cd $HBASE_HOME/conf编辑 hbase-site.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<!-- HBase 数据存储路径 -->
<property>
<name>hbase.rootdir</name>
<value>hdfs://hdfs-cdh/hbase</value>
</property>

<!-- 完全分布式模式 -->
<property>
<name>hbase.cluster.distributed</name>
<value>true</value>
</property>

<!-- HMaster 节点 -->
<property>
<name>hbase.master</name>
<value>cdh-m1:60000,cdh-m2:60000</value>
</property>

<!-- Zookeeper 节点 -->
<property>
<name>hbase.zookeeper.quorum</name>
<value>cdh-m1:2181,cdh-m2:2181,cdh-s1:2181</value>
</property>

<!-- znode 路径,Zookeeper集群中有多个HBase集群需要设置不同znode -->
<property>
<name>zookeeper.znode.parent</name>
<value>/hbase</value>
</property>

<!-- HBase 协处理器 -->
<property>
<name>hbase.coprocessor.user.region.classes</name>
<value>org.apache.hadoop.hbase.coprocessor.AggregateImplementation</value>
</property>
</configuration>在 hbase-env.sh 中添加如下变量
export JAVA_HOME=/data/app/jdk1.7
export HBASE_LOG_DIR=/data/logs/hbase
export HBASE_PID_DIR=/data/pid
export HBASE_MANAGES_ZK=false
# SSH 默认端口 可选
export HBASE_SSH_OPTS="-o ConnectTimeout=1 -p 36000"Heap 设置,单位 MB
export HBASE_HEAPSIZE=1024可选设置 regionservers 中添加所有RegionServer主机名,用于集群批量启动、停止
 
启动与停止
切换用户
su - run集群批量启动
需要配置运行用户ssh-key免密码登录,与$HBASE_HOME/conf/regionservers
# 启动
start-hbase.sh
# 停止
stop-hbase.sh单服务启动停止
HMaster
# 启动
hbase-daemon.sh start master
# 停止
hbase-daemon.sh stop masterHRegionServer
# 启动
hbase-daemon.sh start regionserver
# 停止
hbase-daemon.sh stop regionserver
测试
HBase HA 测试
浏览器打开两个HMaster状态页:
http://cdh-m1:60010
http://cdh-m2:60010 

可以在Master后面看见其中一个主机名,Backup Masters中看见另一个。
停止当前Master,刷新另一个HMaster状态页会发现Master后面已经切换,HA成功。
 
HBase 测试
进入hbase shell 执行:
create 'users','user_id','address','info'
list
put 'users','anton','info:age','24'
get 'users','anton'

# 最终结果
COLUMN CELL
info:age timestamp=1465972035945, value=24
1 row(s) in 0.0170 seconds清除测试数据:
disable 'users'
drop 'users'到这里安装就全部完成,不懂的地方可以留言交流! 查看全部
hadoop.jpg

CDH 的部署和 Apache Hadoop 的部署是没有任何区别的。这里着重的是 HA的部署,需要特殊说明的是NameNode HA 需要依赖 Zookeeper
 


准备


Hosts文件配置:
cat > /etc/hosts << _HOSTS_
127.0.0.1 localhost
10.0.2.59 cdh-m1
10.0.2.60 cdh-m2
10.0.2.61 cdh-s1
_HOSTS_
各个节点服务情况
cdh-m1 Zookeeper JournalNode NameNode DFSZKFailoverController HMaster
cdh-m2 Zookeeper JournalNode NameNode DFSZKFailoverController HMaster
cdh-s1 Zookeeper JournalNode DataNode HRegionServer
对几个新服务说明下: 
  • JournalNode 用于同步 NameNode 元数据,和 Zookeeper 一样需要 2N+1个节点存活集群才可用。
  • DFSZKFailoverController(ZKFC) 用于主备切换,类似 Keepalived 所扮演的角色。

 
NTP 服务
设置时区
rm -f /etc/localtime
ln -s /usr/share/zoneinfo/UTC /etc/localtime
配置NTP Server
yum install -y ntp
cat > /etc/ntp.conf << _NTP_
driftfile /var/lib/ntp/drift

restrict default nomodify
restrict -6 default nomodify

server cn.ntp.org.cn prefer
server news.neu.edu.cn iburst
server dns.sjtu.edu.cn iburst
server 127.127.1.1 iburst

tinker dispersion 100
tinker step 1800
tinker stepout 3600
includefile /etc/ntp/crypto/pw

keys /etc/ntp/keys
_NTP_

# NTP启动时立即同步
cat >> /etc/ntp/step-tickers << _NTP_
server cn.ntp.org.cn prefer
server news.neu.edu.cn iburst
server dns.sjtu.edu.cn iburst
_NTP_

# 同步硬件时钟
cat >> /etc/sysconfig/ntpd << _NTPHW_
SYNC_HWCLOCK=yes
_NTPHW_
启动并设置开机自启动
/etc/init.d/ntpd start
chkconfig ntpd on
配置 NTP Client
yum install -y ntp
# 注意修改内网NTP Server地址
cat > /etc/ntp.conf << _NTP_
driftfile /var/lib/ntp/drift

restrict default nomodify
restrict -6 default nomodify

restrict 127.0.0.1
restrict -6 ::1

server 10.0.2.59 prefer

tinker dispersion 100
tinker step 1800
tinker stepout 3600
includefile /etc/ntp/crypto/pw

keys /etc/ntp/keys
_NTP_

# NTP启动时立即同步
cat >> /etc/ntp/step-tickers << _NTP_
server 10.0.2.59 prefer
_NTP_

# 同步硬件时钟
cat >> /etc/sysconfig/ntpd << _NTPHW_
SYNC_HWCLOCK=yes
_NTPHW_
启动并设置开机自启动
/etc/init.d/ntpd start
chkconfig ntpd on
检查 NTP 同步
ntpq -p

# 结果
remote refid st t when poll reach delay offset jitter
==============================================================================
*time7.aliyun.co 10.137.38.86 2 u 17 64 3 44.995 5.178 0.177
news.neu.edu.cn .INIT. 16 u - 64 0 0.000 0.000 0.000
202.120.2.90 .INIT. 16 u - 64 0 0.000 0.000 0.000
JDK
创建目录
mkdir -p /data/{install,app,logs,pid,appData}
mkdir /data/appData/tmp
cd /data/install
wget -c http://oracle.com/jdk-7u51-linux-x64.gz
tar xf jdk-7u51-linux-x64.gz -C /data/app
cd /data/app
ln -s jdk1.7.0_51 jdk1.7
cat >> /etc/profile << _PATH_
export JAVA_HOME=/data/app/jdk1.7
export CLASSPATH=.:\$JAVA_HOME/lib/dt.jar:\$JAVA_HOME/lib/tools.jar
export PATH=\$JAVA_HOME/bin:\$PATH
_PATH_
source /etc/profile

创建运行账户
useradd -u 600 run
安装包
http://archive.cloudera.com/cdh5/cdh/5/
cd /data/install
wget -c http://archive.cloudera.com/cdh5/cdh/5/hadoop-2.6.0-cdh5.4.5.tar.gz
wget -c http://archive.apache.org/dist/zookeeper/zookeeper-3.4.5/zookeeper-3.4.5.tar.gz
wget -c http://archive.cloudera.com/cdh5/cdh/5/hbase-1.0.0-cdh5.4.5.tar.gz


安装 Zookeeper


cd /data/install
tar xf zookeeper-3.4.5.tar.gz -C /data/app
cd /data/app
ln -s zookeeper-3.4.5 zookeeper
设置环境变量
sed -i '/^export PATH=/i\export ZOOKEEPER_HOME=/data/app/zookeeper' /etc/profile
sed -i 's#export PATH=#&\$ZOOKEEPER_HOME/bin:#' /etc/profile
source /etc/profile
删除无用文件
cd $ZOOKEEPER_HOME
rm -rf *xml *txt zookeeper-3.4.5.jar.* src recipes docs dist-maven contrib
rm -f $ZOOKEEPER_HOME/bin/*.cmd $ZOOKEEPER_HOME/bin/*.txt
rm -f $ZOOKEEPER_HOME/conf/zoo_sample.cfg
创建数据目录
mkdir -p /data/appData/zookeeper/{data,logs}
配置
cat > $ZOOKEEPER_HOME/conf/zoo.cfg << _ZOO_
tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
dataDir=/data/appData/zookeeper/data
dataLogDir=/data/appData/zookeeper/logs
server.1=cdh-m1:2888:3888
server.2=cdh-m2:2888:3888
server.3=cdh-s1:2888:3888
_ZOO_
修改Zookeeper的日志打印方式,与日志路径设置
编辑
$ZOOKEEPER_HOME/bin/zkEnv.sh
在27行后加入两个变量
ZOO_LOG_DIR=/data/logs/zookeeper
ZOO_LOG4J_PROP="INFO,ROLLINGFILE"
创建 myid文件
# 注意myid与配置文件保持一致
echo 1 >/data/appData/zookeeper/data/myid
设置目录权限
chown -R run.run /data/{app,appData,logs}
启动、停止
# 启动
runuser - run -c 'zkServer.sh start'
# 停止
runuser - run -c 'zkServer.sh stop'


安装 Hadoop


tar xf hadoop-2.6.0-cdh5.4.5.tar.gz -C /data/app
cd /data/app
ln -s hadoop-2.6.0-cdh5.4.5 hadoop
设置环境变量
sed -i '/^export PATH=/i\export HADOOP_HOME=/data/app/hadoop' /etc/profile
sed -i 's#export PATH=#&\$HADOOP_HOME/bin:\$HADOOP_HOME/sbin:#' /etc/profile
source /etc/profile
删除无用文件
cd $HADOOP_HOME
rm -rf *txt share/doc src examples* include bin-mapreduce1 cloudera
find . -name "*.cmd"|xargs rm -f
新建数据目录
mkdir -p /data/appData/hdfs/{name,edits,data,jn,tmp}
配置
切换到配置文件目录
cd $HADOOP_HOME/etc/hadoop
编辑 core-site.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<!-- HDFS 集群名称,可指定端口 -->
<property>
<name>fs.defaultFS</name>
<value>hdfs://hdfs-cdh</value>
</property>

<!-- 临时文件目录 -->
<property>
<name>hadoop.tmp.dir</name>
<value>/data/appData/hdfs/tmp</value>
</property>

<!-- 回收站设置,0不启用回收站,1440 表示1440分钟后删除 -->
<property>
<name>fs.trash.interval</name>
<value>1440</value>
</property>

<!-- SequenceFiles在读写中可以使用的缓存大小,单位 bytes 默认 4096 -->
<property>
<name>io.file.buffer.size</name>
<value>131072</value>
</property>

<!-- 可用压缩算法,启用在hdfs-site.xml中,需要编译动态链接库才能用 -->
<property>
<name>io.compression.codecs</name>
<value>org.apache.hadoop.io.compress.SnappyCodec</value>
</property>
</configuration>
编辑 hdfs-site.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<!-- 指定hdfs 集群名称,需要和core-site.xml中的保持一致 -->
<property>
<name>dfs.nameservices</name>
<value>hdfs-cdh</value>
</property>

<!-- 指定 Zookeeper 用于NameNode HA,默认官方配置在core-site.xml中,为了查看清晰配置到hdfs-site.xml也是可用的 -->
<property>
<name>ha.zookeeper.quorum</name>
<value>cdh-m1:2181,cdh-m2:2181,cdh-s1:2181</value>
</property>

<!-- hdfs-cdh 下有两个NameNode,分别为 nn1,nn2 -->
<property>
<name>dfs.ha.namenodes.hdfs-cdh</name>
<value>nn1,nn2</value>
</property>

<!-- nn1 RPC通信地址 -->
<property>
<name>dfs.namenode.rpc-address.hdfs-cdh.nn1</name>
<value>cdh-m1:9000</value>
</property>

<!-- nn1 HTTP通信地址 -->
<property>
<name>dfs.namenode.http-address.hdfs-cdh.nn1</name>
<value>cdh-m1:50070</value>
</property>

<!-- nn2 RPC通信地址 -->
<property>
<name>dfs.namenode.rpc-address.hdfs-cdh.nn2</name>
<value>cdh-m2:9000</value>
</property>

<!-- nn2 HTTP通信地址 -->
<property>
<name>dfs.namenode.http-address.hdfs-cdh.nn2</name>
<value>cdh-m2:50070</value>
</property>

<!-- 指定NameNode元数据在JournalNode上的存储路径 -->
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://cdh-m1:8485;cdh-m2:8485;cdh-s1:8485;/hdfs-cdh</value>
</property>

<!-- 开启NameNode失败自动切换 -->
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>

<!-- 配置主备切换实现方式 -->
<property>
<name>dfs.client.failover.proxy.provider.hdfs-cdh</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

<!-- 配置主备切换方法,每个方法一行-->
<property>
<name>dfs.ha.fencing.methods</name>
<value>
sshfence
shell(/bin/true)
</value>
</property>

<!-- 指定运行用户的秘钥,需要NameNode双向免密码登录,用于主备自动切换 -->
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/home/run/.ssh/id_rsa</value>
</property>

<!-- 配置sshfence 超时时间 -->
<property>
<name>dfs.ha.fencing.ssh.connect-timeout</name>
<value>50000</value>
</property>

<!-- NameNode 数据本地存储路径 -->
<property>
<name>dfs.namenode.name.dir</name>
<value>/data/appData/hdfs/name</value>
</property>

<!-- DataNode 数据本地存储路径 -->
<property>
<name>dfs.datanode.data.dir</name>
<value>/data/appData/hdfs/data</value>
</property>

<!-- JournalNode 数据本地存储路径 -->
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/data/appData/hdfs/jn</value>
</property>

<!-- 修改文件存储到edits,定期同步到DataNode -->
<property>
<name>dfs.namenode.edits.noeditlogchannelflush</name>
<value>true</value>
</property>

<!-- edits 数据本地存储路径 -->
<property>
<name>dfs.namenode.edits.dir</name>
<value>/data/appData/hdfs/edits</value>
</property>

<!-- 开启Block Location metadata允许impala知道数据块在哪块磁盘上 默认关闭 -->
<property>
<name>dfs.datanode.hdfs-blocks-metadata.enabled</name>
<value>true</value>
</property>

<!-- 权限检查 默认开启 -->
<property>
<name>dfs.permissions.enabled</name>
<value>false</value>
</property>

<!-- block 大小设置 -->
<property>
<name>dfs.blocksize</name>
<value>64m</value>
</property>
</configuration>
小于5个DataNode建议添加如下配置
<!-- 数据副本数量,不能超过DataNode数量,大集群建议使用默认值 默认 3 -->
<property>
<name>dfs.replication</name>
<value>2</value>
</property>

<!-- 当副本写入失败时不分配新节点,小集群适用 -->
<property>
<name>dfs.client.block.write.replace-datanode-on-failure.policy</name>
<value>NEVER</value>
</property>
在 hadoop-env.sh 中添加如下变量
export JAVA_HOME=/data/app/jdk1.7
export HADOOP_LOG_DIR=/data/logs/hadoop
export HADOOP_PID_DIR=/data/pid
# SSH端口 可选
export HADOOP_SSH_OPTS="-p 36000"
Heap 设置,单位 MB
export HADOOP_HEAPSIZE=1024
权限设置
chown -R run.run /data/{app,appData,logs}
chmod 777 /data/pid
格式化
格式化只需要执行一次,格式化之前启动Zookeeper
 
切换用户
su - run
启动所有 JournalNode
hadoop-daemon.sh start journalnode
格式化 Zookeeper(为 ZKFC 创建znode)
hdfs zkfc -formatZK
NameNode 主节点格式化并启动
hdfs namenode -format
hadoop-daemon.sh start namenode
NameNode 备节点同步数据并启动
hdfs namenode -bootstrapStandby
hadoop-daemon.sh start namenode
启动 ZKFC
hadoop-daemon.sh start zkfc
启动 DataNode
hadoop-daemon.sh start datanode
启动与停止
切换用户
su - run
集群批量启动
需要配置运行用户ssh-key免密码登录,与$HADOOP_HOME/etc/hadoop/slaves
# 启动
start-dfs.sh
# 停止
stop-dfs.sh
单服务启动停止
启动HDFS
hadoop-daemon.sh start journalnode
hadoop-daemon.sh start namenode
hadoop-daemon.sh start zkfc
hadoop-daemon.sh start datanode
停止HDFS
hadoop-daemon.sh stop datanode
hadoop-daemon.sh stop namenode
hadoop-daemon.sh stop journalnode
hadoop-daemon.sh stop zkfc

测试
HDFS HA 测试
打开 NameNode 状态页:
http://cdh-m1:50010
http://cdh-m2:50010 

在 Overview 后面能看见 active 或 standby,active 为当前 Master,停止 active 上的 NameNode,检查 standby是否为 active。
 
HDFS 测试
hadoop fs -mkdir /test
hadoop fs -put /etc/hosts /test
hadoop fs -ls /test
结果:
-rw-r--r--   2 java supergroup         89 2016-06-15 10:30 /test/hosts
# 其中权限后面的列(这里的2)代表文件总数,即副本数量。
HDFS 管理命令
# 动态加载 hdfs-site.xml
hadoop dfsadmin -refreshNodes


HBase安装配置


cd /data/install
tar xf hbase-1.0.0-cdh5.4.5.tar.gz -C /data/app
cd /data/app
ln -s hbase-1.0.0-cdh5.4.5 hbase
设置环境变量
sed -i '/^export PATH=/i\export HBASE_HOME=/data/app/hbase' /etc/profile
sed -i 's#export PATH=#&\$HBASE_HOME/bin:#' /etc/profile
source /etc/profile
删除无用文件
cd $HBASE_HOME
rm -rf *.txt pom.xml src docs cloudera dev-support hbase-annotations hbase-assembly hbase-checkstyle hbase-client hbase-common hbase-examples hbase-hadoop2-compat hbase-hadoop-compat hbase-it hbase-prefix-tree hbase-protocol hbase-rest hbase-server hbase-shell hbase-testing-util hbase-thrift
find . -name "*.cmd"|xargs rm -f
配置
进入配置文件目录
cd $HBASE_HOME/conf
编辑 hbase-site.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<!-- HBase 数据存储路径 -->
<property>
<name>hbase.rootdir</name>
<value>hdfs://hdfs-cdh/hbase</value>
</property>

<!-- 完全分布式模式 -->
<property>
<name>hbase.cluster.distributed</name>
<value>true</value>
</property>

<!-- HMaster 节点 -->
<property>
<name>hbase.master</name>
<value>cdh-m1:60000,cdh-m2:60000</value>
</property>

<!-- Zookeeper 节点 -->
<property>
<name>hbase.zookeeper.quorum</name>
<value>cdh-m1:2181,cdh-m2:2181,cdh-s1:2181</value>
</property>

<!-- znode 路径,Zookeeper集群中有多个HBase集群需要设置不同znode -->
<property>
<name>zookeeper.znode.parent</name>
<value>/hbase</value>
</property>

<!-- HBase 协处理器 -->
<property>
<name>hbase.coprocessor.user.region.classes</name>
<value>org.apache.hadoop.hbase.coprocessor.AggregateImplementation</value>
</property>
</configuration>
在 hbase-env.sh 中添加如下变量
export JAVA_HOME=/data/app/jdk1.7
export HBASE_LOG_DIR=/data/logs/hbase
export HBASE_PID_DIR=/data/pid
export HBASE_MANAGES_ZK=false
# SSH 默认端口 可选
export HBASE_SSH_OPTS="-o ConnectTimeout=1 -p 36000"
Heap 设置,单位 MB
export HBASE_HEAPSIZE=1024
可选设置 regionservers 中添加所有RegionServer主机名,用于集群批量启动、停止
 
启动与停止
切换用户
su - run
集群批量启动
需要配置运行用户ssh-key免密码登录,与$HBASE_HOME/conf/regionservers
# 启动
start-hbase.sh
# 停止
stop-hbase.sh
单服务启动停止
HMaster
# 启动
hbase-daemon.sh start master
# 停止
hbase-daemon.sh stop master
HRegionServer
# 启动
hbase-daemon.sh start regionserver
# 停止
hbase-daemon.sh stop regionserver

测试
HBase HA 测试
浏览器打开两个HMaster状态页:
http://cdh-m1:60010
http://cdh-m2:60010 

可以在Master后面看见其中一个主机名,Backup Masters中看见另一个。
停止当前Master,刷新另一个HMaster状态页会发现Master后面已经切换,HA成功。
 
HBase 测试
进入hbase shell 执行:
create 'users','user_id','address','info'
list
put 'users','anton','info:age','24'
get 'users','anton'

# 最终结果
COLUMN CELL
info:age timestamp=1465972035945, value=24
1 row(s) in 0.0170 seconds
清除测试数据:
disable 'users'
drop 'users'
到这里安装就全部完成,不懂的地方可以留言交流!

Elasticsearch Recovery详解

大数据/云计算OpenSkill 发表了文章 • 0 个评论 • 824 次浏览 • 2016-09-08 23:56 • 来自相关话题

基础知识点

在Eleasticsearch中recovery指的就是一个索引的分片分配到另外一个节点的过程;一般在快照恢复、索引副本数变更、节点故障、节点重启时发生。由于master保存整个集群的状态信息,因此可以判断出哪些shard需要做再分配,以及分配到哪个结点,例如:
如果某个shard主分片在,副分片所在结点挂了,那么选择另外一个可用结点,将副分片分配(allocate)上去,然后进行主从分片的复制。如果某个shard的主分片所在结点挂了,副分片还在,那么将副分片升级为主分片,然后做主从分片复制。如果某个shard的主副分片所在结点都挂了,则暂时无法恢复,等待持有相关数据的结点重新加入集群后,从该结点上恢复主分片,再选择另外的结点复制副分片。
 
正常情况下,我们可以通过ES的health的API接口,查看整个集群的健康状态和整个集群数据的完整性:




状态及含义如下:
green: 所有的shard主副分片都是正常的;yellow: 所有shard的主分片都完好,部分副分片没有或者不完整,数据完整性依然完好;red: 某些shard的主副分片都没有了,对应的索引数据不完整。
 
recovery过程要消耗额外的资源,CPU、内存、结点之间的网络带宽等等。 这些额外的资源消耗,有可能会导致集群的服务性能下降,或者一部分功能暂时不可用。了解一些recovery的过程和相关的配置参数,对于减小recovery带来的资源消耗,加快集群恢复过程都是很有帮助的。
 

减少集群Full Restart造成的数据来回拷贝

ES集群可能会有整体重启的情况,比如需要升级硬件、升级操作系统或者升级ES大版本。重启所有结点可能带来的一个问题: 某些结点可能先于其他结点加入集群, 先加入集群的结点可能已经可以选举好master,并立即启动了recovery的过程,由于这个时候整个集群数据还不完整,master会指示一些结点之间相互开始复制数据。 那些晚到的结点,一旦发现本地的数据已经被复制到其他结点,则直接删除掉本地“失效”的数据。 当整个集群恢复完毕后,数据分布不均衡,显然是不均衡的,master会触发rebalance过程,将数据在节点之间挪动。整个过程无谓消耗了大量的网络流量;合理设置recovery相关参数则可以防范这种问题的发生。gateway.expected_nodes
gateway.expected_master_nodes
gateway.expected_data_nodes以上三个参数是说集群里一旦有多少个节点就立即开始recovery过程。 不同之处在于,第一个参数指的是master或者data都算在内,而后面两个参数则分指master和data node。
 
在期待的节点数条件满足之前, recovery过程会等待gateway.recover_after_time (默认5分钟) 这么长时间,一旦等待超时,则会根据以下条件判断是否启动:gateway.recover_after_nodes
gateway.recover_after_master_nodes
gateway.recover_after_data_nodes
 
举例来说,对于一个有10个data node的集群,如果有以下的设置:gateway.expected_data_nodes: 10
gateway.recover_after_time: 5m
gateway.recover_after_data_nodes: 8那么集群5分钟以内10个data node都加入了,或者5分钟以后8个以上的data node加入了,都会立即启动recovery过程。
 

减少主副本之间的数据复制

如果不是full restart,而是重启单个data node,仍然会造成数据在不同结点之间来回复制。为避免这个问题,可以在重启之前,先关闭集群的shard allocation:




然后在节点重启完成加入集群后,再重新打开:




这样在节点重启完成后,尽量多的从本地直接恢复数据。

但是在ES1.6版本之前,即使做了以上措施,仍然会发现有大量主副本之间的数据拷贝。从表面去看,这点很让人不能理解。 主副本数据完全一致,ES应该直接从副本本地恢复数据就好了,为什么要重新从主片再复制一遍呢? 原因在于recovery是简单对比主副本的segment file来判断哪些数据一致可以本地恢复,哪些不一致需要远端拷贝的。而不同节点的segment merge是完全独立运行的,可能导致主副本merge的深度不完全一样,从而造成即使文档集完全一样,产生的segment file却不完全一样。
 
为了解决这个问题,ES1.6版本以后加入了synced flush的新特性。 对于5分钟没有更新过的shard,会自动synced flush一下,实质是为对应的shard加了一个synced flush ID。这样当重启节点的时候,先对比一下shard的synced flush ID,就可以知道两个shard是否完全相同,避免了不必要的segment file拷贝,极大加快了冷索引的恢复速度。
 
需要注意的是synced flush只对冷索引有效,对于热索引(5分钟内有更新的索引)没有作用。 如果重启的结点包含有热索引,那么还是免不了大量的文件拷贝。因此在重启一个结点之前,最好按照以下步骤执行,recovery几乎可以瞬间完成:
暂停数据写入程序关闭集群shard allocation手动执行POST /_flush/synced重启节点重新开启集群shard allocation 等待recovery完成,集群health status变成green重新开启数据写入程序
 

特大热索引为何恢复慢

对于冷索引,由于数据不再更新,利用synced flush特性,可以快速直接从本地恢复数据。 而对于热索引,特别是shard很大的热索引,除了synced flush派不上用场需要大量跨节点拷贝segment file以外,translog recovery是导致慢的更重要的原因。
 
从主片恢复数据到副片需要经历3个阶段:
对主片上的segment file做一个快照,然后拷贝到复制片分配到的结点。数据拷贝期间,不会阻塞索引请求,新增索引操作记录到translog里。对translog做一个快照,此快照包含第一阶段新增的索引请求,然后重放快照里的索引操作。此阶段仍然不阻塞索引请求,新增索引操作记录到translog里。为了能达到主副片完全同步,阻塞掉新索引请求,然后重放阶段二新增的translog操作。
 
可见,在recovery完成之前,translog是不能够被清除掉的(禁用掉正常运作期间后台的flush操作)。如果shard比较大,第一阶段耗时很长,会导致此阶段产生的translog很大。重放translog比起简单的文件拷贝耗时要长得多,因此第二阶段的translog耗时也会显著增加。等到第三阶段,需要重放的translog可能会比第二阶段还要多。 而第三阶段是会阻塞新索引写入的,在对写入实时性要求很高的场合,就会非常影响用户体验。 因此,要加快大的热索引恢复速度,最好的方式是遵从上一节提到的方法: 暂停新数据写入,手动sync flush,等待数据恢复完成后,重新开启数据写入,这样可以将数据延迟影响可以降到最低。
 
万一遇到Recovery慢,想知道进度怎么办呢? CAT Recovery API可以显示详细的recovery各个阶段的状态。 这个API怎么用就不在这里赘述了,参考: CAT Recovery。
 

其他Recovery相关的专家级设置

还有其他一些专家级的设置(参见: recovery)可以影响recovery的速度,但提升速度的代价是更多的资源消耗,因此在生产集群上调整这些参数需要结合实际情况谨慎调整,一旦影响应用要立即调整回来。 对于搜索并发量要求高,延迟要求低的场合,默认设置一般就不要去动了。 对于日志实时分析类对于搜索延迟要求不高,但对于数据写入延迟期望比较低的场合,可以适当调大indices.recovery.max_bytes_per_sec,提升recovery速度,减少数据写入被阻塞的时长。
 
最后要说的一点是ES的版本迭代很快,对于Recovery的机制也在不断的优化中。 其中有一些版本甚至引入了一些bug,比如在ES1.4.x有严重的translog recovery bug,导致大的索引trans log recovery几乎无法完成 (issue #9226)  。因此实际使用中如果遇到问题,最好在Github的issue list里搜索一下,看是否使用的版本有其他人反映同样的问题。
分享阅读原文:http://elasticsearch.cn/article/38 查看全部


基础知识点


在Eleasticsearch中recovery指的就是一个索引的分片分配到另外一个节点的过程;一般在快照恢复、索引副本数变更、节点故障、节点重启时发生。由于master保存整个集群的状态信息,因此可以判断出哪些shard需要做再分配,以及分配到哪个结点,例如:
  1. 如果某个shard主分片在,副分片所在结点挂了,那么选择另外一个可用结点,将副分片分配(allocate)上去,然后进行主从分片的复制。
  2. 如果某个shard的主分片所在结点挂了,副分片还在,那么将副分片升级为主分片,然后做主从分片复制。
  3. 如果某个shard的主副分片所在结点都挂了,则暂时无法恢复,等待持有相关数据的结点重新加入集群后,从该结点上恢复主分片,再选择另外的结点复制副分片。

 
正常情况下,我们可以通过ES的health的API接口,查看整个集群的健康状态和整个集群数据的完整性:
EsHealth.png

状态及含义如下:
  • green: 所有的shard主副分片都是正常的;
  • yellow: 所有shard的主分片都完好,部分副分片没有或者不完整,数据完整性依然完好;
  • red: 某些shard的主副分片都没有了,对应的索引数据不完整。

 
recovery过程要消耗额外的资源,CPU、内存、结点之间的网络带宽等等。 这些额外的资源消耗,有可能会导致集群的服务性能下降,或者一部分功能暂时不可用。了解一些recovery的过程和相关的配置参数,对于减小recovery带来的资源消耗,加快集群恢复过程都是很有帮助的。
 


减少集群Full Restart造成的数据来回拷贝


ES集群可能会有整体重启的情况,比如需要升级硬件、升级操作系统或者升级ES大版本。重启所有结点可能带来的一个问题: 某些结点可能先于其他结点加入集群, 先加入集群的结点可能已经可以选举好master,并立即启动了recovery的过程,由于这个时候整个集群数据还不完整,master会指示一些结点之间相互开始复制数据。 那些晚到的结点,一旦发现本地的数据已经被复制到其他结点,则直接删除掉本地“失效”的数据。 当整个集群恢复完毕后,数据分布不均衡,显然是不均衡的,master会触发rebalance过程,将数据在节点之间挪动。整个过程无谓消耗了大量的网络流量;合理设置recovery相关参数则可以防范这种问题的发生。
gateway.expected_nodes
gateway.expected_master_nodes
gateway.expected_data_nodes
以上三个参数是说集群里一旦有多少个节点就立即开始recovery过程。 不同之处在于,第一个参数指的是master或者data都算在内,而后面两个参数则分指master和data node。
 
在期待的节点数条件满足之前, recovery过程会等待gateway.recover_after_time (默认5分钟) 这么长时间,一旦等待超时,则会根据以下条件判断是否启动:
gateway.recover_after_nodes
gateway.recover_after_master_nodes
gateway.recover_after_data_nodes
 
举例来说,对于一个有10个data node的集群,如果有以下的设置:
gateway.expected_data_nodes: 10
gateway.recover_after_time: 5m
gateway.recover_after_data_nodes: 8
那么集群5分钟以内10个data node都加入了,或者5分钟以后8个以上的data node加入了,都会立即启动recovery过程。
 


减少主副本之间的数据复制


如果不是full restart,而是重启单个data node,仍然会造成数据在不同结点之间来回复制。为避免这个问题,可以在重启之前,先关闭集群的shard allocation:
EsNone.png

然后在节点重启完成加入集群后,再重新打开:
EsAll.png

这样在节点重启完成后,尽量多的从本地直接恢复数据。

但是在ES1.6版本之前,即使做了以上措施,仍然会发现有大量主副本之间的数据拷贝。从表面去看,这点很让人不能理解。 主副本数据完全一致,ES应该直接从副本本地恢复数据就好了,为什么要重新从主片再复制一遍呢? 原因在于recovery是简单对比主副本的segment file来判断哪些数据一致可以本地恢复,哪些不一致需要远端拷贝的。而不同节点的segment merge是完全独立运行的,可能导致主副本merge的深度不完全一样,从而造成即使文档集完全一样,产生的segment file却不完全一样。
 
为了解决这个问题,ES1.6版本以后加入了synced flush的新特性。 对于5分钟没有更新过的shard,会自动synced flush一下,实质是为对应的shard加了一个synced flush ID。这样当重启节点的时候,先对比一下shard的synced flush ID,就可以知道两个shard是否完全相同,避免了不必要的segment file拷贝,极大加快了冷索引的恢复速度。
 
需要注意的是synced flush只对冷索引有效,对于热索引(5分钟内有更新的索引)没有作用。 如果重启的结点包含有热索引,那么还是免不了大量的文件拷贝。因此在重启一个结点之前,最好按照以下步骤执行,recovery几乎可以瞬间完成:
  1. 暂停数据写入程序
  2. 关闭集群shard allocation
  3. 手动执行POST /_flush/synced
  4. 重启节点
  5. 重新开启集群shard allocation 
  6. 等待recovery完成,集群health status变成green
  7. 重新开启数据写入程序

 


特大热索引为何恢复慢


对于冷索引,由于数据不再更新,利用synced flush特性,可以快速直接从本地恢复数据。 而对于热索引,特别是shard很大的热索引,除了synced flush派不上用场需要大量跨节点拷贝segment file以外,translog recovery是导致慢的更重要的原因。
 
从主片恢复数据到副片需要经历3个阶段:
  1. 对主片上的segment file做一个快照,然后拷贝到复制片分配到的结点。数据拷贝期间,不会阻塞索引请求,新增索引操作记录到translog里。
  2. 对translog做一个快照,此快照包含第一阶段新增的索引请求,然后重放快照里的索引操作。此阶段仍然不阻塞索引请求,新增索引操作记录到translog里。
  3. 为了能达到主副片完全同步,阻塞掉新索引请求,然后重放阶段二新增的translog操作。

 
可见,在recovery完成之前,translog是不能够被清除掉的(禁用掉正常运作期间后台的flush操作)。如果shard比较大,第一阶段耗时很长,会导致此阶段产生的translog很大。重放translog比起简单的文件拷贝耗时要长得多,因此第二阶段的translog耗时也会显著增加。等到第三阶段,需要重放的translog可能会比第二阶段还要多。 而第三阶段是会阻塞新索引写入的,在对写入实时性要求很高的场合,就会非常影响用户体验。 因此,要加快大的热索引恢复速度,最好的方式是遵从上一节提到的方法: 暂停新数据写入,手动sync flush,等待数据恢复完成后,重新开启数据写入,这样可以将数据延迟影响可以降到最低。
 
万一遇到Recovery慢,想知道进度怎么办呢? CAT Recovery API可以显示详细的recovery各个阶段的状态。 这个API怎么用就不在这里赘述了,参考: CAT Recovery
 


其他Recovery相关的专家级设置


还有其他一些专家级的设置(参见: recovery)可以影响recovery的速度,但提升速度的代价是更多的资源消耗,因此在生产集群上调整这些参数需要结合实际情况谨慎调整,一旦影响应用要立即调整回来。 对于搜索并发量要求高,延迟要求低的场合,默认设置一般就不要去动了。 对于日志实时分析类对于搜索延迟要求不高,但对于数据写入延迟期望比较低的场合,可以适当调大indices.recovery.max_bytes_per_sec,提升recovery速度,减少数据写入被阻塞的时长。
 
最后要说的一点是ES的版本迭代很快,对于Recovery的机制也在不断的优化中。 其中有一些版本甚至引入了一些bug,比如在ES1.4.x有严重的translog recovery bug,导致大的索引trans log recovery几乎无法完成 (issue #9226)  。因此实际使用中如果遇到问题,最好在Github的issue list里搜索一下,看是否使用的版本有其他人反映同样的问题。
分享阅读原文:http://elasticsearch.cn/article/38

强制清除Elasticsearch中已删除的文件

大数据/云计算采菊篱下 发表了文章 • 0 个评论 • 1235 次浏览 • 2016-06-05 01:14 • 来自相关话题

 Elasticsearch是建立在Apache Lucene 基础上的实时分布式搜索引擎,Lucene为了提高搜索的实时性,采用不可再修改(immutable)方式将文档存储在一个个segment中。也就是说,一个segment在写入到存储系统之后,将不可以再修改。那么Lucene是如何从一个segment中删除一个被索引的文档呢?简单的讲,当用户发出命令删除一个被索引的文档#ABC时,该文档并不会被马上从相应的存储它的segment中删除掉,而是通过一个特殊的文件来标记该文档已被删除。当用户再次搜索到#ABC时,Elasticsearch在segment中仍能找到#ABC,但由于#ABC文档已经被标记为删除,所以Lucene会从发回给用户的搜索结果中剔除#ABC,所以给用户感觉的是#ABC已经被删除了。
 
 Elasticseach会有后台线程根据Lucene的合并规则定期进行segment merging 合并操作,一般不需要用户担心或者采取任何行动。被删除的文档在segment合并时,才会被真正删除掉。在此之前,它仍然会占用着JVM heap和操作系统的文件cache等资源。在某些情况下,我们需要强制Elasticsearch进行segment merging,已释放其占用的大量系统资源。
                       POST /{index}/_optimize?only_expunge_deletes=true&wait_for_completion=true
_optimize命令可强制进行segment合并,并删除所有标记为删除的文档。Segment merging要消耗CPU,以及大量的I/O资源,所以一定要在你的ElasticSearch集群处于维护窗口期间,并且有足够的I/O空间的(如:SSD)的条件下进行;否则很可能造成集群崩溃和数据丢失。
 
下图展示了我们在进行强制expunge时,所观察到的CPU和磁盘I/O的使用情况。该集群运行在微软的Azure云平台IaaS虚拟机上,所有的数据节点都采用 D13 虚拟机,数据存储在本地的SSD磁盘中。该集群是一个备份集群,为了保证合并顺利进行,在此期间暂停了所有对其进行的写操作,仅有少量的读操作。这里需要注意: expunge操作是一种不得已而为之的操作,即在Elasticsearch不能有效自动清除删除文件的情况下才执行该操作。同时建议在此操作期间,最好停止对集群的所有读/写操作,并暂停止shard的自动分配 (cluster.routing.allocation.enable= none),以防有节点被踢出后shard自动分配造成的数据丢失。








下面两个设置可以用于控制清除时的处理速度,其中给出值是默认值,可以根据需求进行调整,具体请参见Merge。此外, 还可以临时将所有索引的replica设置为0,这样只用针对Primary进行expunge,以减小I/O压力。
PUT /{index}/_settings
{
"settings": {
"index.merge.policy.expunge_deletes_allowed": "10",
"index.merge.policy.max_merge_at_once_explicit" : "30"
}
}参考资料:Lucene‘s Handling of Deleted Documents.
分享阅读:http://blog.csdn.net/quicknet/article/details/46421505 查看全部
 Elasticsearch是建立在Apache Lucene 基础上的实时分布式搜索引擎,Lucene为了提高搜索的实时性,采用不可再修改(immutable)方式将文档存储在一个个segment中。也就是说,一个segment在写入到存储系统之后,将不可以再修改。那么Lucene是如何从一个segment中删除一个被索引的文档呢?简单的讲,当用户发出命令删除一个被索引的文档#ABC时,该文档并不会被马上从相应的存储它的segment中删除掉,而是通过一个特殊的文件来标记该文档已被删除。当用户再次搜索到#ABC时,Elasticsearch在segment中仍能找到#ABC,但由于#ABC文档已经被标记为删除,所以Lucene会从发回给用户的搜索结果中剔除#ABC,所以给用户感觉的是#ABC已经被删除了。
 
 Elasticseach会有后台线程根据Lucene的合并规则定期进行segment merging 合并操作,一般不需要用户担心或者采取任何行动。被删除的文档在segment合并时,才会被真正删除掉。在此之前,它仍然会占用着JVM heap和操作系统的文件cache等资源。在某些情况下,我们需要强制Elasticsearch进行segment merging,已释放其占用的大量系统资源。
                       POST /{index}/_optimize?only_expunge_deletes=true&wait_for_completion=true
_optimize命令可强制进行segment合并,并删除所有标记为删除的文档。Segment merging要消耗CPU,以及大量的I/O资源,所以一定要在你的ElasticSearch集群处于维护窗口期间,并且有足够的I/O空间的(如:SSD)的条件下进行;否则很可能造成集群崩溃和数据丢失。
 
下图展示了我们在进行强制expunge时,所观察到的CPU和磁盘I/O的使用情况。该集群运行在微软的Azure云平台IaaS虚拟机上,所有的数据节点都采用 D13 虚拟机,数据存储在本地的SSD磁盘中。该集群是一个备份集群,为了保证合并顺利进行,在此期间暂停了所有对其进行的写操作,仅有少量的读操作。这里需要注意: expunge操作是一种不得已而为之的操作,即在Elasticsearch不能有效自动清除删除文件的情况下才执行该操作。同时建议在此操作期间,最好停止对集群的所有读/写操作,并暂停止shard的自动分配 (cluster.routing.allocation.enable= none),以防有节点被踢出后shard自动分配造成的数据丢失。
Cpu.png

sec.png

下面两个设置可以用于控制清除时的处理速度,其中给出值是默认值,可以根据需求进行调整,具体请参见Merge。此外, 还可以临时将所有索引的replica设置为0,这样只用针对Primary进行expunge,以减小I/O压力。
PUT /{index}/_settings
{
"settings": {
"index.merge.policy.expunge_deletes_allowed": "10",
"index.merge.policy.max_merge_at_once_explicit" : "30"
}
}
参考资料:Lucene‘s Handling of Deleted Documents.
分享阅读:http://blog.csdn.net/quicknet/article/details/46421505

怎么彻底删除kafka的topic,然后重建?

大数据/云计算chris 回复了问题 • 3 人关注 • 2 个回复 • 5713 次浏览 • 2016-01-03 19:25 • 来自相关话题

怎么查看kafka的版本号

大数据/云计算OpenSkill 回复了问题 • 2 人关注 • 1 个回复 • 3685 次浏览 • 2016-10-26 21:37 • 来自相关话题

Hbase/Hdfs删除节点

大数据/云计算采菊篱下 发表了文章 • 0 个评论 • 3083 次浏览 • 2015-11-30 00:16 • 来自相关话题

线上有台服务器随时可能会挂掉,所以需要把在这个服务器上hbase的regionserver和hdfs的datanode节点移除。然后重新拿台新服务器部署接管。
 
之前在文章 http://openskill.cn/article/178 中讲到怎么新增一个hdfs的datanode,所以我先讲一下怎么添加一个hbase的regionserver,然后再讲怎么删除! 

添加hbase regionserver节点

添加步骤如下:
1、在hbase  master上修改regionservers文件# cd hbase_install_dir/conf
# echo "new_hbase_node_hostname" >> ./regionservers2、如果你hbase集群使用自身zk集群的话,还需要修改hbase-site.xml文件,反之不用操作!# cd hbase_install_dir/conf
# vim hbase-site.xml
找到hbase.zookeeper.quorum属性 -->加入新节点3、同步以上修改的文件到hbase的各个节点上
4、在新节点上启动hbase regionserver# cd hbase_install_dir/bin/
# ./hbase-daemon.sh start regionserver5、在hbasemaster启动hbase shell用status命令确认一下集群情况hbase新增一个 regionserver节点补充完成了,下面介绍删除hbase和hdfs节点!
 
集群上既部署有Hadoop,又部署有HBase,因为HBase存储是基于Hadoop HDFS的,所以先要移除HBase节点,之后再移除Hadoop节点。添加则反之。

移除hbase regionserver节点

1、在0.90.2之前,我们只能通过在要卸载的节点上执行;我的hbase版本(0.98.7)# cd hbase_install_dir
# ./bin/hbase-daemon.sh stop regionserver来实现。这条语句执行后,该RegionServer首先关闭其负载的所有Region而后关闭自己。在关闭时,RegionServer在ZooKeeper中的"Ephemeral Node"会失效。此时,Master检测到RegionServer挂掉并把它作为一个宕机节点,并将该RegionServer上的Region重新分配到其他RegionServer。
 
注意:使用此方法前,一定要关闭HBase Load Balancer。关闭方法:hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3290 seconds总结:这种方法很大的一个缺点是该节点上的Region会离线很长时间。因为假如该RegionServer上有大量Region的话,因为Region的关闭是顺序执行的,第一个关闭的Region得等到和最后一个Region关闭并Assigned后一起上线。这是一个相当漫长的时间。以我这次的实验为例,现在一台RegionServer平均有1000个Region,每个Region Assigned需要4s,也就是说光Assigned就至少需要1个小时。2、自0.90.2之后,HBase添加了一个新的方法,即"graceful_stop",在你移除的服务器执行:# cd hbase_install_dir
# ./bin/graceful_stop.sh hostname该命令会自动关闭Load Balancer,然后Assigned Region,之后会将该节点关闭。除此之外,你还可以查看remove的过程,已经assigned了多少个Region,还剩多少个Region,每个Region 的Assigned耗时。
 
补充graceful stop的一些其他命令参数:# ./bin/graceful_stop.sh
Usage: graceful_stop.sh [--config &conf-dir>] [--restart] [--reload] [--thrift] [--rest] &hostname>
thrift If we should stop/start thrift before/after the hbase stop/start
rest If we should stop/start rest before/after the hbase stop/start
restart If we should restart after graceful stop
reload Move offloaded regions back on to the stopped server
debug Move offloaded regions back on to the stopped server
hostname Hostname of server we are to stop最终都需要我们手动打开load balancer:hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3590 seconds然后再开启:hbase(main):001:0> balance_switch true
false
0 row(s) in 0.3290 seconds对比两种方法,建议使用"graceful_stop"来移除hbase RegionServer节点。
官网说明:http://hbase.apache.org/0.94/book/node.management.html​  http://hbase.apache.org/book.html#decommission​  

移除hdfs datanode节点

1、在core-site.xml文件下新增如下内容<property>
<name>dfs.hosts.exclude</name>
<value>/hdfs_install_dir/conf/excludes</value>
</property>2、创建exclude文件,把需要删除节点的主机名写入# cd hdfs_install_dir/conf
# vim excludes
添加需要删除的节点主机名,比如 hdnode1 保存退出3、 然后在namenode节点执行如下命令,强制让namenode重新读取配置文件,不需要重启集群。# cd hdfs_install_dir/bin/
# ./hadoop dfsadmin -refreshNodes它会在后台进行Block块的移动
 4、 查看状态
等待第三步的操作结束后,需要下架的机器就可以安全的关闭了。# ./hadoop dfsadmin -report可以查看到现在集群上连接的节点 正在执行Decommission,会显示:
Decommission Status : Decommission in progress

执行完毕后,会显示:
Decommission Status : Decommissioned如下:Name: 10.0.180.6:50010
Decommission Status : Decommission in progress
Configured Capacity: 917033340928 (10.83 TB)
DFS Used: 7693401063424 (7 TB)
Non DFS Used: 118121652224 (110.00 GB)
DFS Remaining: 4105510625280(3.63 TB)
DFS Used%: 64.56%
DFS Remaining%: 34.45%
Last contact: Mon Nov 29 23:53:52 CST 2015也可以直接通过Hadoop 浏览器查看:
LIVE的节点可以查看到:http://master_ip:50070/dfsnodelist.jsp?whatNodes=LIVE
查看看到卸载的节点状态是:Decommission in progress
等待节点完成移除后,浏览:http://master_ip:50070/dfsnodelist.jsp?whatNodes=DEAD 结果如下:




完成后,删除的节点显示在dead nodes中。且其上的服务停止。Live Nodes中仅剩had2,had3
以上即为从Hadoop集群中Remove Node的过程,但是,有一点一定要注意:
hdfs-site.xml配置文件中dfs.replication值必须小于或者等于踢除节点后正常datanode的数量,即:dfs.replication <= 集群所剩节点数修改备份系数可以参考:http://heylinux.com/archives/2047.html

重载入删除的datanode节点 

1、修改namenode的core-site.xml文件,把我们刚刚加入的内容删除或者注释掉,我这里选择注释掉。<!--

<property>
<name>dfs.hosts.exclude</name>
<value>/root/hadoop/conf/excludes</value>
</property>

-->2、 再执行重载namenode的配置文件# ./bin/hadoop dfsadmin -refreshNodes3、最后去启动datanode上的datanode# ./bin/hadoop-daemon.sh start datanode
starting datanode, logging to /usr/local/hadoop/bin/../logs/hadoop-root-datanode-had1.out4、查看启动情况# jps
18653 Jps
19687 DataNode ---->启动正常重新载入HBase RegionServer节点
只需要重启regionserver进程即可。
参考:http://www.edureka.co/blog/commissioning-and-decommissioning-nodes-in-a-hadoop-cluster/
           https://pravinchavan.wordpress.com/2013/06/03/removing-node-from-hadoop-cluster/ 查看全部
线上有台服务器随时可能会挂掉,所以需要把在这个服务器上hbase的regionserver和hdfs的datanode节点移除。然后重新拿台新服务器部署接管。
 
之前在文章 http://openskill.cn/article/178 中讲到怎么新增一个hdfs的datanode,所以我先讲一下怎么添加一个hbase的regionserver,然后再讲怎么删除! 


添加hbase regionserver节点


添加步骤如下:
1、在hbase  master上修改regionservers文件
# cd hbase_install_dir/conf
# echo "new_hbase_node_hostname" >> ./regionservers
2、如果你hbase集群使用自身zk集群的话,还需要修改hbase-site.xml文件,反之不用操作!
# cd hbase_install_dir/conf
# vim hbase-site.xml
找到hbase.zookeeper.quorum属性 -->加入新节点
3、同步以上修改的文件到hbase的各个节点上
4、在新节点上启动hbase regionserver
# cd hbase_install_dir/bin/
# ./hbase-daemon.sh start regionserver
5、在hbasemaster启动hbase shell
用status命令确认一下集群情况
hbase新增一个 regionserver节点补充完成了,下面介绍删除hbase和hdfs节点!
 
集群上既部署有Hadoop,又部署有HBase,因为HBase存储是基于Hadoop HDFS的,所以先要移除HBase节点,之后再移除Hadoop节点。添加则反之。


移除hbase regionserver节点


1、在0.90.2之前,我们只能通过在要卸载的节点上执行;我的hbase版本(0.98.7)
# cd hbase_install_dir
# ./bin/hbase-daemon.sh stop regionserver
来实现。这条语句执行后,该RegionServer首先关闭其负载的所有Region而后关闭自己。在关闭时,RegionServer在ZooKeeper中的"Ephemeral Node"会失效。此时,Master检测到RegionServer挂掉并把它作为一个宕机节点,并将该RegionServer上的Region重新分配到其他RegionServer。
 
注意:使用此方法前,一定要关闭HBase Load Balancer。关闭方法:
hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3290 seconds
总结:
这种方法很大的一个缺点是该节点上的Region会离线很长时间。因为假如该RegionServer上有大量Region的话,因为Region的关闭是顺序执行的,第一个关闭的Region得等到和最后一个Region关闭并Assigned后一起上线。这是一个相当漫长的时间。以我这次的实验为例,现在一台RegionServer平均有1000个Region,每个Region Assigned需要4s,也就是说光Assigned就至少需要1个小时。
2、自0.90.2之后,HBase添加了一个新的方法,即"graceful_stop",在你移除的服务器执行:
# cd hbase_install_dir
# ./bin/graceful_stop.sh hostname
该命令会自动关闭Load Balancer,然后Assigned Region,之后会将该节点关闭。除此之外,你还可以查看remove的过程,已经assigned了多少个Region,还剩多少个Region,每个Region 的Assigned耗时。
 
补充graceful stop的一些其他命令参数:
# ./bin/graceful_stop.sh
Usage: graceful_stop.sh [--config &conf-dir>] [--restart] [--reload] [--thrift] [--rest] &hostname>
thrift If we should stop/start thrift before/after the hbase stop/start
rest If we should stop/start rest before/after the hbase stop/start
restart If we should restart after graceful stop
reload Move offloaded regions back on to the stopped server
debug Move offloaded regions back on to the stopped server
hostname Hostname of server we are to stop
最终都需要我们手动打开load balancer:
hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3590 seconds
然后再开启:
hbase(main):001:0> balance_switch true
false
0 row(s) in 0.3290 seconds
对比两种方法,建议使用"graceful_stop"来移除hbase RegionServer节点。
官网说明:http://hbase.apache.org/0.94/book/node.management.html​  http://hbase.apache.org/book.html#decommission​  


移除hdfs datanode节点


1、在core-site.xml文件下新增如下内容
<property>
<name>dfs.hosts.exclude</name>
<value>/hdfs_install_dir/conf/excludes</value>
</property>
2、创建exclude文件,把需要删除节点的主机名写入
# cd hdfs_install_dir/conf
# vim excludes
添加需要删除的节点主机名,比如 hdnode1 保存退出
3、 然后在namenode节点执行如下命令,强制让namenode重新读取配置文件,不需要重启集群。
# cd hdfs_install_dir/bin/
# ./hadoop dfsadmin -refreshNodes
它会在后台进行Block块的移动
 4、 查看状态
等待第三步的操作结束后,需要下架的机器就可以安全的关闭了。
# ./hadoop dfsadmin -report
可以查看到现在集群上连接的节点 
正在执行Decommission,会显示: 
Decommission Status : Decommission in progress

执行完毕后,会显示:
Decommission Status : Decommissioned
如下:
Name: 10.0.180.6:50010
Decommission Status : Decommission in progress
Configured Capacity: 917033340928 (10.83 TB)
DFS Used: 7693401063424 (7 TB)
Non DFS Used: 118121652224 (110.00 GB)
DFS Remaining: 4105510625280(3.63 TB)
DFS Used%: 64.56%
DFS Remaining%: 34.45%
Last contact: Mon Nov 29 23:53:52 CST 2015
也可以直接通过Hadoop 浏览器查看:
LIVE的节点可以查看到:http://master_ip:50070/dfsnodelist.jsp?whatNodes=LIVE
查看看到卸载的节点状态是:Decommission in progress
等待节点完成移除后,浏览:http://master_ip:50070/dfsnodelist.jsp?whatNodes=DEAD 结果如下:
hdead.png

完成后,删除的节点显示在dead nodes中。且其上的服务停止。Live Nodes中仅剩had2,had3
以上即为从Hadoop集群中Remove Node的过程,但是,有一点一定要注意:
hdfs-site.xml配置文件中dfs.replication值必须小于或者等于踢除节点后正常datanode的数量,即:
dfs.replication <= 集群所剩节点数
修改备份系数可以参考:http://heylinux.com/archives/2047.html


重载入删除的datanode节点 


1、修改namenode的core-site.xml文件,把我们刚刚加入的内容删除或者注释掉,我这里选择注释掉。
<!--

<property>
<name>dfs.hosts.exclude</name>
<value>/root/hadoop/conf/excludes</value>
</property>

-->
2、 再执行重载namenode的配置文件
# ./bin/hadoop dfsadmin -refreshNodes
3、最后去启动datanode上的datanode
# ./bin/hadoop-daemon.sh start datanode
starting datanode, logging to /usr/local/hadoop/bin/../logs/hadoop-root-datanode-had1.out
4、查看启动情况
# jps
18653 Jps
19687 DataNode ---->启动正常
重新载入HBase RegionServer节点
只需要重启regionserver进程即可。
参考:http://www.edureka.co/blog/commissioning-and-decommissioning-nodes-in-a-hadoop-cluster/
           https://pravinchavan.wordpress.com/2013/06/03/removing-node-from-hadoop-cluster/

控制Elasticsearch分片和副本的分配

大数据/云计算OpenSkill 发表了文章 • 1 个评论 • 10903 次浏览 • 2015-09-15 00:04 • 来自相关话题

    ES集群中索引可能由多个分片构成,并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片,我们可以处理不能在一个单一的服务器上面运行的大型索引,简单的说就是索引的大小过大,导致效率问题。不能运行的原因可能是内存也可能是存储。由于每个分片可以有多个副本,通过将副本分配到多个服务器,可以提高查询的负载能力。
 
    为了进行分片和副本的操作,ES需要确定将这些分片和副本放到集群节点的哪个位置,就是需要确定把每个分片和副本分配到哪台服务器/节点上。
 

一、显式控制分配

生产情景:比如生产环境有三个索引分别为 man、woman、katoey
希望达到的效果:
man索引放置在一些集群节点上
woman索引又单独放置到集群的另外一些集群节点上
katoey索引希望放置在所有放置man索引和woman索引的集群节点上

这么做是因为katoey索引比其他两个索引小很多,因此我们可以将它和其他两个索引一起分配。
但是基于ES默认算法的处理方法,我们不能确定分片和副本的存放位置,但是ES允许我们对其做相应的控制!
1、指定节点的参数



    如上图所示,我们将ES集群划分为两个"空间"。当然你也可以叫做区域,随便命名。我们将左边的三台ES节点服务器放置到zone_one的空间上面,将右边的三台ES节点服务器放到zone_two的空间上。
 
配置
    为了做到我们需要的效果,我们需要将如下属性配置到左边三台ES集群节点服务器的elasticsearch.yml配置文件中node.zone: zone_one    将如下属性配置到右边的三台ES集群节点服务器elasticsearch.yml配置文件中node.zone: zone_two 
索引创建
    当所有节点配置文件属性配置完成后,我们就可以根据空间名称,我们就可以创建索引放到指定的空间。
    首先我们运行如下命令,来创建man索引:# curl -XPOST "http://ESnode:9200/man'
# curl -XPUT "http://ESnode:9200/man/_settings' -d '{
"index.routing.allocation.include.zone" : "zone_one"
}'    第一条命令是创建man索引;第二条命令是发送到_settings REST端点,用来指定这个索引的其他配置信息。我们将index.routing.allocation.include.zone属性设置为zone_one值,就是我们所希望的把man索引放置到node.zone属性值为zone_one的ES集群节点服务器上。
 
    同样对woman索引我们做类似操作:# curl -XPOST "http://ESnode:9200/woman'
# curl -XPUT "http://ESnode:9200/woman/_settings' -d '{
"index.routing.allocation.include.zone" : "zone_two"
}'    不同的是,这次指定woman索引放置在node.zone属性值为zone_two的ES集群节点服务器上
 
    最后我们需要将katoey索引放置到上面所有的ES集群节点上面,配置设置命令如下:# curl -XPOST "http://ESnode:9200/katoey"
# curl -XPUT "http://ESnode:9200/katoey/_settings" -d '{
"index.routing.allocation.include.zone" : "zone_one,zone_two"
}'
 2、分配时排除节点
    跟我们上面操作为索引指定放置节点位置一样,我们也可以在索引分配的时候排除某些节点。参照之前的例子,我们新建一个people索引,但是不希望people索引放置到zone_one的ES集群节点服务器上,我们可以运行如下命令操作:# curl -XPOST "http://EScode:9200/people"
# curl -XPUT "http://EScode:9200/people/_settings" -d '{
"index.routing.allocation.exclude.zone" : "zone_one"
}'    请注意,在这里我们使用的是index.routing.allocation.exclude.zone属性而不是index.routing.allocation.include.zone属性。
 
使用IP地址进行分配配置
    除了在节点的配置中添加一些特殊的属性参数外,我们还可以使用IP地址来指定你将分片和副本分配或者不分配到哪些节点上面。为了做到这点,我们应该使用_ip属性,把zone换成_ip就好了。例如我们希望lucky索引分配到IP地址为10.0.1.110和10.0.1.119的节点上,我们可以运行如下命令设置:# curl -XPOST "http://ESnode:9200/lucky"
# curl -XPUT "http://ESnode:9200/lucky/_settings" -d '{
"index.routing.allocation.include._ip" "10.0.1.110,10.0.1.119"
}'

二、集群范围内分配

    除了索引层面指定分配活着排除分配之外(上面我们所做的都是这两种情况),我们还可以指定集群中所有索引的分配。例如,我们希望将所有的新索引分配到IP地址为10.0.1.112和10.0.1.114的节点上,我们可以运行如下命令设置:# curl -XPUT "http://ESnode:9200/_cluster/settings" -d '{
"transient" : {
"cluster.routing.allocation.include._ip" "10.0.1.112,10.0.1.114"
}
}'    集群级别的控制后续还会分享transient和persistent属性介绍
 

三、每个节点上分片和副本数量的控制

    除了指定分片和副本的分配,我们还可以对一个索引指定每个节点上的最大分片数量。例如我们希望ops索引在每个节点上只有一个分片,我们可以运行如下命令:# curl -XPUT "http://ESnode:9200/ops/_settings" -d '{
"index.routing.allocation.total_shards_per_node" : 1
}'    这个属性也可以直接配置到elasticsearch.ym配置文件中,或者使用上面命令在活动索引上更新。如果配置不当,导致主分片无法分配的话,集群就会处于red状态。
 

四、手动移动分片和副本

    接下来我们介绍一下节点间手动移动分片和副本。可以使用ElasticSearch提供的_cluster/reroute REST端点进行控制,能够进行下面操作:
[]将一个分片从一个节点移动到另外一个节点[/][]取消对分片的分配[/][]强制对分片进行分配[/]
 
移动分片
    假设我们有两个节点:es_node_one和es_node_two,ElasticSearch在es_node_one节点上分配了ops索引的两个分片,我们现在希望将第二个分片移动到es_node_two节点上。可以如下操作实现:# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [ {
"move" : {
"index" : "ops",
"shard" : 1,
"from_node" : "es_node_one",
"to_node" : "es_node_two"
}
}]
}'    我们通过move命令的index属性指定移动哪个索引,通过shard属性指定移动哪个分片,最终通过from_node属性指定我们从哪个节点上移动分片,通过to_node属性指定我们希望将分片移动到哪个节点。
 
取消分配
    如果希望取消一个正在进行的分配过程,我们通过运行cancel命令来指定我们希望取消分配的索引、节点以及分片,如下所示:# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [ {
"cancel" : {
"index" : "ops",
"shard" : 0,
"node" : "es_node_one"
}
} ]
}'    运行上面的命令将会取消es_node_one节上ops索引的第0个分片的分配
 
分配分片
    除了取消和移动分片和副本之外,我们还可以将一个未分配的分片分配到一个指定的节点上。假设ops索引上有一个编号为0的分片尚未分配,并且我们希望ElasticSearch将其分配到es_node_two上,可以运行如下命令操作:# curl -XPOST "http://ESnode:9200/_cluster/reroute' -d '{
"commands" : [ {
"allocate" : {
"index" : "ops",
"shard" : 0,
"node" : "es_node_two"
}
} ]
}'一次HTTP请求包含多个命令
    我们可以在一次HTTP请求中包含多个命令,例如:# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [
{"move" : {"index" : "ops", "shard" : 1, "from_node" : "es_node_one", "to_node" : "es_node_two"}},
{"cancel" : {"index" : "ops", "shard" : 0, "node" : "es_node_one"}}
]
}' 查看全部
    ES集群中索引可能由多个分片构成,并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片,我们可以处理不能在一个单一的服务器上面运行的大型索引,简单的说就是索引的大小过大,导致效率问题。不能运行的原因可能是内存也可能是存储。由于每个分片可以有多个副本,通过将副本分配到多个服务器,可以提高查询的负载能力。
 
    为了进行分片和副本的操作,ES需要确定将这些分片和副本放到集群节点的哪个位置,就是需要确定把每个分片和副本分配到哪台服务器/节点上。
 


一、显式控制分配


生产情景:
比如生产环境有三个索引分别为 man、woman、katoey
希望达到的效果:
man索引放置在一些集群节点上
woman索引又单独放置到集群的另外一些集群节点上
katoey索引希望放置在所有放置man索引和woman索引的集群节点上

这么做是因为katoey索引比其他两个索引小很多,因此我们可以将它和其他两个索引一起分配。
但是基于ES默认算法的处理方法,我们不能确定分片和副本的存放位置,但是ES允许我们对其做相应的控制!

1、指定节点的参数
epei1.png

    如上图所示,我们将ES集群划分为两个"空间"。当然你也可以叫做区域,随便命名。我们将左边的三台ES节点服务器放置到zone_one的空间上面,将右边的三台ES节点服务器放到zone_two的空间上。
 
配置
    为了做到我们需要的效果,我们需要将如下属性配置到左边三台ES集群节点服务器的elasticsearch.yml配置文件中
node.zone: zone_one
    将如下属性配置到右边的三台ES集群节点服务器elasticsearch.yml配置文件中
node.zone: zone_two
 
索引创建
    当所有节点配置文件属性配置完成后,我们就可以根据空间名称,我们就可以创建索引放到指定的空间。
    首先我们运行如下命令,来创建man索引:
# curl -XPOST "http://ESnode:9200/man'
# curl -XPUT "http://ESnode:9200/man/_settings' -d '{
"index.routing.allocation.include.zone" : "zone_one"
}'
    第一条命令是创建man索引;第二条命令是发送到_settings REST端点,用来指定这个索引的其他配置信息。我们将index.routing.allocation.include.zone属性设置为zone_one值,就是我们所希望的把man索引放置到node.zone属性值为zone_one的ES集群节点服务器上。
 
    同样对woman索引我们做类似操作:
# curl -XPOST "http://ESnode:9200/woman'
# curl -XPUT "http://ESnode:9200/woman/_settings' -d '{
"index.routing.allocation.include.zone" : "zone_two"
}'
    不同的是,这次指定woman索引放置在node.zone属性值为zone_two的ES集群节点服务器上
 
    最后我们需要将katoey索引放置到上面所有的ES集群节点上面,配置设置命令如下:
# curl -XPOST "http://ESnode:9200/katoey"
# curl -XPUT "http://ESnode:9200/katoey/_settings" -d '{
"index.routing.allocation.include.zone" : "zone_one,zone_two"
}'

 2、分配时排除节点
    跟我们上面操作为索引指定放置节点位置一样,我们也可以在索引分配的时候排除某些节点。参照之前的例子,我们新建一个people索引,但是不希望people索引放置到zone_one的ES集群节点服务器上,我们可以运行如下命令操作:
# curl -XPOST "http://EScode:9200/people"
# curl -XPUT "http://EScode:9200/people/_settings" -d '{
"index.routing.allocation.exclude.zone" : "zone_one"
}'
    请注意,在这里我们使用的是index.routing.allocation.exclude.zone属性而不是index.routing.allocation.include.zone属性。
 
使用IP地址进行分配配置
    除了在节点的配置中添加一些特殊的属性参数外,我们还可以使用IP地址来指定你将分片和副本分配或者不分配到哪些节点上面。为了做到这点,我们应该使用_ip属性,把zone换成_ip就好了。例如我们希望lucky索引分配到IP地址为10.0.1.110和10.0.1.119的节点上,我们可以运行如下命令设置:
# curl -XPOST "http://ESnode:9200/lucky"
# curl -XPUT "http://ESnode:9200/lucky/_settings" -d '{
"index.routing.allocation.include._ip" "10.0.1.110,10.0.1.119"
}'


二、集群范围内分配


    除了索引层面指定分配活着排除分配之外(上面我们所做的都是这两种情况),我们还可以指定集群中所有索引的分配。例如,我们希望将所有的新索引分配到IP地址为10.0.1.112和10.0.1.114的节点上,我们可以运行如下命令设置:
# curl -XPUT "http://ESnode:9200/_cluster/settings" -d '{
"transient" : {
"cluster.routing.allocation.include._ip" "10.0.1.112,10.0.1.114"
}
}'
    集群级别的控制后续还会分享transient和persistent属性介绍
 


三、每个节点上分片和副本数量的控制


    除了指定分片和副本的分配,我们还可以对一个索引指定每个节点上的最大分片数量。例如我们希望ops索引在每个节点上只有一个分片,我们可以运行如下命令:
# curl -XPUT "http://ESnode:9200/ops/_settings" -d '{
"index.routing.allocation.total_shards_per_node" : 1
}'
    这个属性也可以直接配置到elasticsearch.ym配置文件中,或者使用上面命令在活动索引上更新。如果配置不当,导致主分片无法分配的话,集群就会处于red状态。
 


四、手动移动分片和副本


    接下来我们介绍一下节点间手动移动分片和副本。可以使用ElasticSearch提供的_cluster/reroute REST端点进行控制,能够进行下面操作:
    []将一个分片从一个节点移动到另外一个节点[/][]取消对分片的分配[/][]强制对分片进行分配[/]

 
移动分片
    假设我们有两个节点:es_node_one和es_node_two,ElasticSearch在es_node_one节点上分配了ops索引的两个分片,我们现在希望将第二个分片移动到es_node_two节点上。可以如下操作实现:
# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d  '{
"commands" : [ {
"move" : {
"index" : "ops",
"shard" : 1,
"from_node" : "es_node_one",
"to_node" : "es_node_two"
}
}]
}'
    我们通过move命令的index属性指定移动哪个索引,通过shard属性指定移动哪个分片,最终通过from_node属性指定我们从哪个节点上移动分片,通过to_node属性指定我们希望将分片移动到哪个节点。
 
取消分配
    如果希望取消一个正在进行的分配过程,我们通过运行cancel命令来指定我们希望取消分配的索引、节点以及分片,如下所示:
# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [ {
"cancel" : {
"index" : "ops",
"shard" : 0,
"node" : "es_node_one"
}
} ]
}'
    运行上面的命令将会取消es_node_one节上ops索引的第0个分片的分配
 
分配分片
    除了取消和移动分片和副本之外,我们还可以将一个未分配的分片分配到一个指定的节点上。假设ops索引上有一个编号为0的分片尚未分配,并且我们希望ElasticSearch将其分配到es_node_two上,可以运行如下命令操作:
# curl -XPOST "http://ESnode:9200/_cluster/reroute' -d '{
"commands" : [ {
"allocate" : {
"index" : "ops",
"shard" : 0,
"node" : "es_node_two"
}
} ]
}'
一次HTTP请求包含多个命令
    我们可以在一次HTTP请求中包含多个命令,例如:
# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{
"commands" : [
{"move" : {"index" : "ops", "shard" : 1, "from_node" : "es_node_one", "to_node" : "es_node_two"}},
{"cancel" : {"index" : "ops", "shard" : 0, "node" : "es_node_one"}}
]
}'

Elasticsearch 分片交互过程详解

大数据/云计算Ansible 发表了文章 • 0 个评论 • 2111 次浏览 • 2015-06-18 01:40 • 来自相关话题

一、Elasticseach如何将数据存储到分片中
二、主分片与复制分片如何交互
1、索引与删除一个文档
2、更新一个文档
3、检索文档

一、Elasticseach如何将数据存储到分片中

问题:当我们要在ES中存储数据的时候,数据应该存储在主分片和复制分片中的哪一个中去;当我们在ES中检索数据的时候,又是怎么判断要查询的数据是属于哪一个分片。 

数据存储到分片的过程是一定规则的,并不是随机发生的。

规则:shard = hash(routing) % number_of_primary_shards

Routing值可以是一个任意的字符串,默认情况下,它的值为存数数据对应文档 _id 值,也可以是用户自定义的值。Routing这个字符串通过一个hash的函数处理,并返回一个数值,然后再除以索引中主分片的数目,所得的余数作为主分片的编号,取值一般在0到number_of_primary_shards - 1的这个范围中。通过这种方法计算出该数据是存储到哪个分片中。

正是这种路由机制,导致了主分片的个数为什么在索引建立之后不能修改。对已有索引主分片数目的修改直接会导致路由规则出现严重问题,部分数据将无法被检索。
 
二、主分片与复制分片如何交互
为了说明这个问题,我用一个例子来说明。





在上面这个例子中,有三个ES的node,其中每一个index中包含两个primary shard,每个primary shard拥有一个replica shard。下面从几种常见的数据操作来说明二者之间的交互情况。
 
1、索引与删除一个文档





这两种过程均可以分为三个过程来描述:
阶段1:客户端发送了一个索引或者删除的请求给node 1。

阶段2:node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3在shard 0 的primary shard上执行请求。如果请求执行成功,它node 3将并行地将该请求发给shard 0的其余所有replica shard上,也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求,那么将会向node 3回复一个成功确认,当node 3收到了所有replica shard的确认信息后,则最后向用户返回一个Success的消息。
 
2、更新一个文档





该过程可以分为四个阶段来描述:
阶段1:客户端向node 1发送一个文档更新的请求。

阶段2:同样的node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3从文档所在的primary shard中获取到它的JSON文件,并修改其中的_source中的内容,之后再重新索引该文档到其primary shard中。

阶段4:如果node 3成功地更新了文档,node 3将会把文档新的版本并行地发给其余所有的replica shard所在node中。这些node也同样重新索引新版本的文档,执行后则向node 3确认成功,当node 3接收到所有的成功确认之后,再向客户端发送一个更新成功的信息。
 
3、检索文档
CRUD这些操作的过程中一般都是结合一些唯一的标记例如:_index,_type,以及routing的值,这就意味在执行操作的时候都是确切的知道文档在集群中的哪个node中,哪个shard中。

而检索过程往往需要更多的执行模式,因为我们并不清楚所要检索的文档具体位置所在, 它们可能存在于ES集群中个任何位置。因此,一般情况下,检索的执行不得不去询问index中的每一个shard。

但是,找到所有匹配检索的文档仅仅只是检索过程的一半,在向客户端返回一个结果列表之前,必须将各个shard发回的小片的检索结果,拼接成一个大的已排好序的汇总结果列表。正因为这个原因,检索的过程将分为查询阶段与获取阶段(Query Phase and Fetch Phase)。

Query Phase
在最初的查询过程中,查询请求会广播到index中的每一个primary shard和replica shard中,每一个shard会在本地执行检索,并建立一个优先级队列(priority queue)。这个优先级队列是一个根据文档匹配度这个指标所排序列表,列表的长度由分页参数from和size两个参数所决定。例如:






下面从一个例子中说明这个过程:





Query Phase阶段可以再细分成3个小的子阶段:

子阶段1:客户端发送一个检索的请求给node 3,此时node 3会创建一个空的优先级队列并且配置好分页参数from与size。

子阶段2:node 3将检索请求发送给该index中个每一个shard(这里的每一个意思是无论它是primary还是replica,它们的组合可以构成一个完整的index数据)。每个shard在本地执行检索,并将结果添加到本地优先级队列中。

子阶段3:每个shard返回本地优先级序列中所记录的_id与sort值,并发送node 3。Node 3将这些值合并到自己的本地的优先级队列中,并做全局的排序。
 
Fetch Phase
Query Phase主要定位了所要检索数据的具体位置,但是我们还必须取回它们才能完成整个检索过程。而Fetch Phase阶段的任务就是将这些定位好的数据内容取回并返回给客户端。
 
同样也用一个例子来说明这个过程:





Fetch Phase过程可以分为三个子过程来描述:

子阶段1:node 3获取了所有待检索数据的定位之后,发送一个mget的请求给与数据相关的shard。

子阶段2:每个收到node 3的get请求的shard将读取相关文档_source中的内容,并将它们返回给node 3。

子阶段3:当node 3获取到了所有shard返回的文档后,node 3将它们合并成一条汇总的结果,返回给客户端。 查看全部


一、Elasticseach如何将数据存储到分片中
二、主分片与复制分片如何交互
1、索引与删除一个文档
2、更新一个文档
3、检索文档


一、Elasticseach如何将数据存储到分片中

问题:当我们要在ES中存储数据的时候,数据应该存储在主分片和复制分片中的哪一个中去;当我们在ES中检索数据的时候,又是怎么判断要查询的数据是属于哪一个分片。 

数据存储到分片的过程是一定规则的,并不是随机发生的。

规则:shard = hash(routing) % number_of_primary_shards

Routing值可以是一个任意的字符串,默认情况下,它的值为存数数据对应文档 _id 值,也可以是用户自定义的值。Routing这个字符串通过一个hash的函数处理,并返回一个数值,然后再除以索引中主分片的数目,所得的余数作为主分片的编号,取值一般在0到number_of_primary_shards - 1的这个范围中。通过这种方法计算出该数据是存储到哪个分片中。

正是这种路由机制,导致了主分片的个数为什么在索引建立之后不能修改。对已有索引主分片数目的修改直接会导致路由规则出现严重问题,部分数据将无法被检索。
 
二、主分片与复制分片如何交互
为了说明这个问题,我用一个例子来说明。

a.png

在上面这个例子中,有三个ES的node,其中每一个index中包含两个primary shard,每个primary shard拥有一个replica shard。下面从几种常见的数据操作来说明二者之间的交互情况。
 
1、索引与删除一个文档

b.png

这两种过程均可以分为三个过程来描述:
阶段1:客户端发送了一个索引或者删除的请求给node 1。

阶段2:node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3在shard 0 的primary shard上执行请求。如果请求执行成功,它node 3将并行地将该请求发给shard 0的其余所有replica shard上,也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求,那么将会向node 3回复一个成功确认,当node 3收到了所有replica shard的确认信息后,则最后向用户返回一个Success的消息。
 
2、更新一个文档

c.png

该过程可以分为四个阶段来描述:
阶段1
:客户端向node 1发送一个文档更新的请求。

阶段2:同样的node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中,并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3:node 3从文档所在的primary shard中获取到它的JSON文件,并修改其中的_source中的内容,之后再重新索引该文档到其primary shard中。

阶段4:如果node 3成功地更新了文档,node 3将会把文档新的版本并行地发给其余所有的replica shard所在node中。这些node也同样重新索引新版本的文档,执行后则向node 3确认成功,当node 3接收到所有的成功确认之后,再向客户端发送一个更新成功的信息。
 
3、检索文档
CRUD这些操作的过程中一般都是结合一些唯一的标记例如:_index,_type,以及routing的值,这就意味在执行操作的时候都是确切的知道文档在集群中的哪个node中,哪个shard中。

而检索过程往往需要更多的执行模式,因为我们并不清楚所要检索的文档具体位置所在, 它们可能存在于ES集群中个任何位置。因此,一般情况下,检索的执行不得不去询问index中的每一个shard。

但是,找到所有匹配检索的文档仅仅只是检索过程的一半,在向客户端返回一个结果列表之前,必须将各个shard发回的小片的检索结果,拼接成一个大的已排好序的汇总结果列表。正因为这个原因,检索的过程将分为查询阶段与获取阶段(Query Phase and Fetch Phase)。

Query Phase
在最初的查询过程中,查询请求会广播到index中的每一个primary shard和replica shard中,每一个shard会在本地执行检索,并建立一个优先级队列(priority queue)。这个优先级队列是一个根据文档匹配度这个指标所排序列表,列表的长度由分页参数from和size两个参数所决定。例如:

d.png


下面从一个例子中说明这个过程:

e.png

Query Phase阶段可以再细分成3个小的子阶段:

子阶段1:客户端发送一个检索的请求给node 3,此时node 3会创建一个空的优先级队列并且配置好分页参数from与size。

子阶段2:node 3将检索请求发送给该index中个每一个shard(这里的每一个意思是无论它是primary还是replica,它们的组合可以构成一个完整的index数据)。每个shard在本地执行检索,并将结果添加到本地优先级队列中。

子阶段3:每个shard返回本地优先级序列中所记录的_id与sort值,并发送node 3。Node 3将这些值合并到自己的本地的优先级队列中,并做全局的排序。
 
Fetch Phase
Query Phase主要定位了所要检索数据的具体位置,但是我们还必须取回它们才能完成整个检索过程。而Fetch Phase阶段的任务就是将这些定位好的数据内容取回并返回给客户端。
 
同样也用一个例子来说明这个过程:

f.png

Fetch Phase过程可以分为三个子过程来描述:

子阶段1:node 3获取了所有待检索数据的定位之后,发送一个mget的请求给与数据相关的shard。

子阶段2:每个收到node 3的get请求的shard将读取相关文档_source中的内容,并将它们返回给node 3。

子阶段3:当node 3获取到了所有shard返回的文档后,node 3将它们合并成一条汇总的结果,返回给客户端。

Hadoop可以运行单机模式吗?

回复

大数据/云计算采菊篱下 回复了问题 • 2 人关注 • 2 个回复 • 867 次浏览 • 2015-10-18 22:18 • 来自相关话题

启动hadoop时,log中出现:java.io.IOException: NameNode is not formatted.

回复

大数据/云计算OpenSkill 回复了问题 • 2 人关注 • 1 个回复 • 1352 次浏览 • 2015-06-29 01:36 • 来自相关话题

OVM混合虚拟化设计目标及设计思路

大数据/云计算maoliang 发表了文章 • 0 个评论 • 480 次浏览 • 2016-09-29 09:42 • 来自相关话题

1、OVM虚拟化的目标:

OVM是要实现混合虚拟化,做一个大一统的资源管理和交付平台,纵观虚拟化市场,现在当属开源的KVM和Docker最火,我们工作过去有vmware,现在大量使用kvm,未来一定会考虑docker,但现有市场上的产品要么架构太大,开发难度高,易用性不够强,要么就是单纯的虚拟化,类似vmware等。

新形式下,我们需要的产品要同时具备如下目标:

跨平台,支持KVM、Esxi和Docker容器

因为我们单位过去采用虚拟化技术混杂,上面又遗留很多虚拟机,这就要求我们新开发产品能够兼容不同hypervior,同时还能识别并管理原有hypervior上的虚拟机,能够识别并导入原数据库技术并不难,难的是导入后还能纳入新平台管理,这部分我们又研发了自动捕获技术,而不同混合虚拟化管理技术可以摆脱对底层Hypervisor的依赖,专心于资源的统一管理。

单独的用户自助服务门户

过去采用传统虚拟化时,解决了安装部署的麻烦,但资源的申请和扩容、准备资源和切割资源仍然没有变,还是要让我们做,占据了日常运维工作的大部分工作量,每天确实烦人,所以我们想而这部分工作是可以放给相关的部门Leader或者专员,来减少运维的工作量,所以我们希望新设计的OVM允许用户通过一个单独的Web门户来直接访问自己的资源(云主机、云硬盘、网络等),而且对自己的资源进行管理,而不需要知道资源的具体位置,同时用户的所有云主机都建立在高可用环境之上,也不必担心实际物理硬件故障引起服务瘫痪。

Opscode Chef自动化运维集成

实行自助服务后,有一个问题,就是软件不同版本部署不兼容,这就需要设计能够把操作系统、中间件、数据库、web能统一打包部署,减少自助用户哭天喊地甚至骂我们,我们通过对chef的集成,可以一键更新所有的虚拟机,在指定的虚拟机上安装指定的软件。有了chef工具,为虚拟机打补丁、安装软件,只需要几个简单的命令即可搞定。

可持续性

做运维不要故障处理办法是不行,而且还要自动化的,同时我们有vmware和kvm,就需要新平台能在esxi上(不要vcenter,要付钱的)和kvm同时实现ha功能

可运维性
一个平台再强大,技术再厉害,如果不可运维,那结果可想而知。因此我们希望OVM可以给用户带来一个稳定、可控、安全的生产环境

弹性伸缩
自助服务部门拿到资源后,通过对各项目资源的限额,以及对各虚拟机和容器性能指标的实时监控,可以实现弹性的资源伸缩,达到合理分配利用资源。

资源池化
将数据中心的计算、存储、网络资源全部池化,然后通过OVM虚拟化平台统一对外提供IaaS服务。

2、OVM设计思路

OVM架构选型一

我们觉得架构就是一个产品的灵魂所在,决定着产品日后的发展。

我们团队在产品选型初期,分别调研了目前比较热门的openstack,以及前几年的明星产品convirt、ovirt,这几个产品可谓是典型的代表。

Openstack偏重于公有云,架构设计的很不错,其分布式、插件式的模块化架构,可以有效避免单点故障的发生,从发布之初便备受推崇,但是其存在的问题也同样令人头疼目前使用Openstack的大多是一些有实力的IDC、大型的互联网公司在用。而对于一般的企业来说,没有强大的开发和维护团队,并不敢大规模的采用openstack,初期使用一段时间后我们放弃了OS。

而前几年的convirt,在当时也掀起了一股使用热潮,其简单化的使用体验,足以满足小企业的虚拟化需求,但是他的问题是架构采用了集中式的架构,而且对于上了规模之后,也会带来性能方面的瓶颈,除非是把数据库等一些组件松藕合,解决起来也比较麻烦,所以到了后期也是不温不火,官方也停止了社区的更新和维护。

OVM架构选型二

      通过对以上产品的优劣势分析,我们决定采用用分布式、松耦合的模块化插件架构,分布式使其可以规避单点故障,达到业务持续高可用,松耦合的模块化特点让产品在后期的扩展性方面不受任何限制,使其向下可以兼容数据中心所有硬件(通过OVM标准的Rest API接口),向上可以实现插件式的我们即将需要的工作流引擎、计费引擎、报表引擎、桌面云引擎和自动化运维引擎。

而目前阶段我们则专心于实现虚拟化的全部功能,发掘内部对虚拟化的需求,打造一款真正简单、易用、稳定、可运维的一款虚拟化管理软件,并预留向上、向下的接口留作后期发展。(架构图大家可以查看刚才上面发的图片)

虚拟化技术选择

    Docker当下很火,其轻量级、灵活、高密度部署是优点,但是大规模使用还未成熟。许多场景还是需要依赖传统的虚拟化技术。所以我们选择传统虚拟化技术KVM+Docker,确保线上业务稳定性、连续性的同时,开发、测试环境又可以利用到Docker的轻量级、高密度和灵活。

     另外很多用户的生产环境存在不止一种虚拟化技术,例如KVM+Esxi组合、KVM+XenServer组合、KVM+Hyper-V组合,而目前的虚拟化管理平台,大多都是只支持一种Hypervisor的管理,用户想要维护不同的虚拟化技术的虚拟机,就要反复的在不同环境之间切换。

    基于此考虑,我和团队内部和外部一些同行选择兼容(兼容KVM、Esxi,Docker),并自主打造新一代虚拟化管理平台——混合虚拟化。

网络  

 网络方面,我们对所有Hypervisor的虚拟机使用统一的网络管理(包括Docker容器),这样做的一个好处就是可以减少运维工作量,降低网络复杂性。初期我们只实现2层的虚拟网络管理,为虚拟机和容器提供Vlan隔离、DHCP分配网络,当然也可以手工为虚拟机挑选一个网络,这个可以满足一般的虚拟化需求,后期我们会在此基础上增加虚拟网络防火墙、负载均衡。

存储

存储上面我们采用本地存储+NFS两种方式,对于一般中小企业来说,不希望购买高昂的商业存储,直接使用本地存储虚拟机的性能是最好的,而且我们也提供了存储快照、存储热迁移、虚拟机的无共享热迁移来提升业务安全。此外NFS作为辅助,可以为一些高风险业务提供HA。后期存储方面我们会考虑集成Ceph和GlusterFS存储来提升存储管理。

镜像中心

顾名思义,镜像中心就是用来存放镜像的。传统虚拟化我们使用NFS来作为镜像中心,所有宿主机共享一个镜像中心,这样可以更方便的来统一管理镜像,而针对Docker容器则保留了使用Docker自己的私有仓库,但是我们在WEB UI的镜像中心增加了从Docker私有仓库下载模板这么一个功能,实现了在同一个镜像中心的管理,后期我们会着重打造传统虚拟化镜像与Docker镜像的相互转换,实现两者内容的统一。

HA

OVM 主机HA依然坚持全兼容策略,支持对可管理的所有Hypervisor的HA。

在启用HA的资源池,当检测到一个Hypervisor故障,创建和运行在该Hypervisor共享存储上的虚拟机将在相同资源池下的另外一个主机上重启。

具体工作流程为:

第一次检测到故障会将该故障主机标记;

第二次检测依然故障将启动迁移任务;

迁移任务启动后将在该故障主机所在的资源池寻找合适的主机;

确定合适主机后,会将故障主机上所有的虚拟机自动迁移到合适的主机上面并重新启动;

 

VM分配策略

负载均衡

PERFORMANCE(性能): 这条策略分配虚拟机到不同的主机上。它挑选一组中可用资源最多的主机来部署虚拟机。如果有多个主机都有相同的资源可用,它使用一个循环算法,每个虚拟机分配到一个不同的主机上。

PROGRESSIVE(逐行扫描): 这条策略意味着,所有虚拟机将被分配在同一个主机上,直到它的资源被用尽。此项策略将一个主机资源使用完,然后再切换到另一个主机。

负载均衡级别

所有资源池: 如果选定此选项,则负载均衡级别策略将适用于所选定数据中心的所有资源池中的主机。

所有主机: 该策略将适用于所选数据中心单个资源池的所有主机。

特定主机: 该策略仅适用于所选的特定主机。

 

VM设计一

VM是整个虚拟化平台的核心,我们开发了一个单独的模块来负责虚拟机的相关操作。其采用异步通信和独立的并行操作,提升了虚拟机性能、稳定性和扩展性。

可扩展性:独立、并发

可追溯性:错误信息和log、监控控制台、性能

非阻塞操作:稳定性、改进重新配置、改进回滚、标准、统一的hypervisor通信、自动化测试

 

VM设计二

我们设计基于vApp来部署虚拟机,一个vApp可包含N个虚拟机:

N 个虚拟机配置

N个开机请求

我们希望并行运行N个配置(要求资源允许),并在配置后每个虚拟机请求一个开机。这些操作都是并发和独立的。

 

平台设计

OVM产品目前由三大组件、七大模块组成。其中三大组件分别为OVM UI、OVM API和OVM数据中心组件。

OVM UI提供WEB自服务界面,OVM API负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。

VDC资源限额

管理员可以为每个VDC设置资源限额,防止资源的过度浪费。

账户管理

OVM提供存储SDK、备份SDK,以及虚拟防火墙SDK,轻松与第三方实现集成

获得帮助

下载请访问OVM社区官网:51ovm.com

使用过程中遇到什么问题及获得下载密码,加入OVM社区qq官方交流群:22265939

“ 实践是检验真理唯一标准“,OVM社区视您为社区的发展动力,此刻,诚邀您参与我们的调查,共同做出一款真正解决问题、放心的产品,一起推动国内虚拟化的进步和发展。

填写调查问卷!只需1分钟喔!
https://www.wenjuan.com/s/iiEVZv 查看全部
1、OVM虚拟化的目标:

OVM是要实现混合虚拟化,做一个大一统的资源管理和交付平台,纵观虚拟化市场,现在当属开源的KVM和Docker最火,我们工作过去有vmware,现在大量使用kvm,未来一定会考虑docker,但现有市场上的产品要么架构太大,开发难度高,易用性不够强,要么就是单纯的虚拟化,类似vmware等。

新形式下,我们需要的产品要同时具备如下目标:

跨平台,支持KVM、Esxi和Docker容器

因为我们单位过去采用虚拟化技术混杂,上面又遗留很多虚拟机,这就要求我们新开发产品能够兼容不同hypervior,同时还能识别并管理原有hypervior上的虚拟机,能够识别并导入原数据库技术并不难,难的是导入后还能纳入新平台管理,这部分我们又研发了自动捕获技术,而不同混合虚拟化管理技术可以摆脱对底层Hypervisor的依赖,专心于资源的统一管理。

单独的用户自助服务门户

过去采用传统虚拟化时,解决了安装部署的麻烦,但资源的申请和扩容、准备资源和切割资源仍然没有变,还是要让我们做,占据了日常运维工作的大部分工作量,每天确实烦人,所以我们想而这部分工作是可以放给相关的部门Leader或者专员,来减少运维的工作量,所以我们希望新设计的OVM允许用户通过一个单独的Web门户来直接访问自己的资源(云主机、云硬盘、网络等),而且对自己的资源进行管理,而不需要知道资源的具体位置,同时用户的所有云主机都建立在高可用环境之上,也不必担心实际物理硬件故障引起服务瘫痪。

Opscode Chef自动化运维集成

实行自助服务后,有一个问题,就是软件不同版本部署不兼容,这就需要设计能够把操作系统、中间件、数据库、web能统一打包部署,减少自助用户哭天喊地甚至骂我们,我们通过对chef的集成,可以一键更新所有的虚拟机,在指定的虚拟机上安装指定的软件。有了chef工具,为虚拟机打补丁、安装软件,只需要几个简单的命令即可搞定。

可持续性

做运维不要故障处理办法是不行,而且还要自动化的,同时我们有vmware和kvm,就需要新平台能在esxi上(不要vcenter,要付钱的)和kvm同时实现ha功能

可运维性
一个平台再强大,技术再厉害,如果不可运维,那结果可想而知。因此我们希望OVM可以给用户带来一个稳定、可控、安全的生产环境

弹性伸缩
自助服务部门拿到资源后,通过对各项目资源的限额,以及对各虚拟机和容器性能指标的实时监控,可以实现弹性的资源伸缩,达到合理分配利用资源。

资源池化
将数据中心的计算、存储、网络资源全部池化,然后通过OVM虚拟化平台统一对外提供IaaS服务。

2、OVM设计思路

OVM架构选型一

我们觉得架构就是一个产品的灵魂所在,决定着产品日后的发展。

我们团队在产品选型初期,分别调研了目前比较热门的openstack,以及前几年的明星产品convirt、ovirt,这几个产品可谓是典型的代表。

Openstack偏重于公有云,架构设计的很不错,其分布式、插件式的模块化架构,可以有效避免单点故障的发生,从发布之初便备受推崇,但是其存在的问题也同样令人头疼目前使用Openstack的大多是一些有实力的IDC、大型的互联网公司在用。而对于一般的企业来说,没有强大的开发和维护团队,并不敢大规模的采用openstack,初期使用一段时间后我们放弃了OS。

而前几年的convirt,在当时也掀起了一股使用热潮,其简单化的使用体验,足以满足小企业的虚拟化需求,但是他的问题是架构采用了集中式的架构,而且对于上了规模之后,也会带来性能方面的瓶颈,除非是把数据库等一些组件松藕合,解决起来也比较麻烦,所以到了后期也是不温不火,官方也停止了社区的更新和维护。

OVM架构选型二

      通过对以上产品的优劣势分析,我们决定采用用分布式、松耦合的模块化插件架构,分布式使其可以规避单点故障,达到业务持续高可用,松耦合的模块化特点让产品在后期的扩展性方面不受任何限制,使其向下可以兼容数据中心所有硬件(通过OVM标准的Rest API接口),向上可以实现插件式的我们即将需要的工作流引擎、计费引擎、报表引擎、桌面云引擎和自动化运维引擎。

而目前阶段我们则专心于实现虚拟化的全部功能,发掘内部对虚拟化的需求,打造一款真正简单、易用、稳定、可运维的一款虚拟化管理软件,并预留向上、向下的接口留作后期发展。(架构图大家可以查看刚才上面发的图片)

虚拟化技术选择

    Docker当下很火,其轻量级、灵活、高密度部署是优点,但是大规模使用还未成熟。许多场景还是需要依赖传统的虚拟化技术。所以我们选择传统虚拟化技术KVM+Docker,确保线上业务稳定性、连续性的同时,开发、测试环境又可以利用到Docker的轻量级、高密度和灵活。

     另外很多用户的生产环境存在不止一种虚拟化技术,例如KVM+Esxi组合、KVM+XenServer组合、KVM+Hyper-V组合,而目前的虚拟化管理平台,大多都是只支持一种Hypervisor的管理,用户想要维护不同的虚拟化技术的虚拟机,就要反复的在不同环境之间切换。

    基于此考虑,我和团队内部和外部一些同行选择兼容(兼容KVM、Esxi,Docker),并自主打造新一代虚拟化管理平台——混合虚拟化。

网络  

 网络方面,我们对所有Hypervisor的虚拟机使用统一的网络管理(包括Docker容器),这样做的一个好处就是可以减少运维工作量,降低网络复杂性。初期我们只实现2层的虚拟网络管理,为虚拟机和容器提供Vlan隔离、DHCP分配网络,当然也可以手工为虚拟机挑选一个网络,这个可以满足一般的虚拟化需求,后期我们会在此基础上增加虚拟网络防火墙、负载均衡。

存储

存储上面我们采用本地存储+NFS两种方式,对于一般中小企业来说,不希望购买高昂的商业存储,直接使用本地存储虚拟机的性能是最好的,而且我们也提供了存储快照、存储热迁移、虚拟机的无共享热迁移来提升业务安全。此外NFS作为辅助,可以为一些高风险业务提供HA。后期存储方面我们会考虑集成Ceph和GlusterFS存储来提升存储管理。

镜像中心

顾名思义,镜像中心就是用来存放镜像的。传统虚拟化我们使用NFS来作为镜像中心,所有宿主机共享一个镜像中心,这样可以更方便的来统一管理镜像,而针对Docker容器则保留了使用Docker自己的私有仓库,但是我们在WEB UI的镜像中心增加了从Docker私有仓库下载模板这么一个功能,实现了在同一个镜像中心的管理,后期我们会着重打造传统虚拟化镜像与Docker镜像的相互转换,实现两者内容的统一。

HA

OVM 主机HA依然坚持全兼容策略,支持对可管理的所有Hypervisor的HA。

在启用HA的资源池,当检测到一个Hypervisor故障,创建和运行在该Hypervisor共享存储上的虚拟机将在相同资源池下的另外一个主机上重启。

具体工作流程为:

第一次检测到故障会将该故障主机标记;

第二次检测依然故障将启动迁移任务;

迁移任务启动后将在该故障主机所在的资源池寻找合适的主机;

确定合适主机后,会将故障主机上所有的虚拟机自动迁移到合适的主机上面并重新启动;

 

VM分配策略

负载均衡

PERFORMANCE(性能): 这条策略分配虚拟机到不同的主机上。它挑选一组中可用资源最多的主机来部署虚拟机。如果有多个主机都有相同的资源可用,它使用一个循环算法,每个虚拟机分配到一个不同的主机上。

PROGRESSIVE(逐行扫描): 这条策略意味着,所有虚拟机将被分配在同一个主机上,直到它的资源被用尽。此项策略将一个主机资源使用完,然后再切换到另一个主机。

负载均衡级别

所有资源池: 如果选定此选项,则负载均衡级别策略将适用于所选定数据中心的所有资源池中的主机。

所有主机: 该策略将适用于所选数据中心单个资源池的所有主机。

特定主机: 该策略仅适用于所选的特定主机。

 

VM设计一

VM是整个虚拟化平台的核心,我们开发了一个单独的模块来负责虚拟机的相关操作。其采用异步通信和独立的并行操作,提升了虚拟机性能、稳定性和扩展性。

可扩展性:独立、并发

可追溯性:错误信息和log、监控控制台、性能

非阻塞操作:稳定性、改进重新配置、改进回滚、标准、统一的hypervisor通信、自动化测试

 

VM设计二

我们设计基于vApp来部署虚拟机,一个vApp可包含N个虚拟机:

N 个虚拟机配置

N个开机请求

我们希望并行运行N个配置(要求资源允许),并在配置后每个虚拟机请求一个开机。这些操作都是并发和独立的。

 

平台设计

OVM产品目前由三大组件、七大模块组成。其中三大组件分别为OVM UI、OVM API和OVM数据中心组件。

OVM UI提供WEB自服务界面,OVM API负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。

VDC资源限额

管理员可以为每个VDC设置资源限额,防止资源的过度浪费。

账户管理

OVM提供存储SDK、备份SDK,以及虚拟防火墙SDK,轻松与第三方实现集成

获得帮助

下载请访问OVM社区官网:51ovm.com

使用过程中遇到什么问题及获得下载密码,加入OVM社区qq官方交流群:22265939

“ 实践是检验真理唯一标准“,OVM社区视您为社区的发展动力,此刻,诚邀您参与我们的调查,共同做出一款真正解决问题、放心的产品,一起推动国内虚拟化的进步和发展。

填写调查问卷!只需1分钟喔!
https://www.wenjuan.com/s/iiEVZv

Hbase/Hdfs删除节点

大数据/云计算采菊篱下 发表了文章 • 0 个评论 • 3083 次浏览 • 2015-11-30 00:16 • 来自相关话题

线上有台服务器随时可能会挂掉,所以需要把在这个服务器上hbase的regionserver和hdfs的datanode节点移除。然后重新拿台新服务器部署接管。
 
之前在文章 http://openskill.cn/article/178 中讲到怎么新增一个hdfs的datanode,所以我先讲一下怎么添加一个hbase的regionserver,然后再讲怎么删除! 

添加hbase regionserver节点

添加步骤如下:
1、在hbase  master上修改regionservers文件# cd hbase_install_dir/conf
# echo "new_hbase_node_hostname" >> ./regionservers2、如果你hbase集群使用自身zk集群的话,还需要修改hbase-site.xml文件,反之不用操作!# cd hbase_install_dir/conf
# vim hbase-site.xml
找到hbase.zookeeper.quorum属性 -->加入新节点3、同步以上修改的文件到hbase的各个节点上
4、在新节点上启动hbase regionserver# cd hbase_install_dir/bin/
# ./hbase-daemon.sh start regionserver5、在hbasemaster启动hbase shell用status命令确认一下集群情况hbase新增一个 regionserver节点补充完成了,下面介绍删除hbase和hdfs节点!
 
集群上既部署有Hadoop,又部署有HBase,因为HBase存储是基于Hadoop HDFS的,所以先要移除HBase节点,之后再移除Hadoop节点。添加则反之。

移除hbase regionserver节点

1、在0.90.2之前,我们只能通过在要卸载的节点上执行;我的hbase版本(0.98.7)# cd hbase_install_dir
# ./bin/hbase-daemon.sh stop regionserver来实现。这条语句执行后,该RegionServer首先关闭其负载的所有Region而后关闭自己。在关闭时,RegionServer在ZooKeeper中的"Ephemeral Node"会失效。此时,Master检测到RegionServer挂掉并把它作为一个宕机节点,并将该RegionServer上的Region重新分配到其他RegionServer。
 
注意:使用此方法前,一定要关闭HBase Load Balancer。关闭方法:hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3290 seconds总结:这种方法很大的一个缺点是该节点上的Region会离线很长时间。因为假如该RegionServer上有大量Region的话,因为Region的关闭是顺序执行的,第一个关闭的Region得等到和最后一个Region关闭并Assigned后一起上线。这是一个相当漫长的时间。以我这次的实验为例,现在一台RegionServer平均有1000个Region,每个Region Assigned需要4s,也就是说光Assigned就至少需要1个小时。2、自0.90.2之后,HBase添加了一个新的方法,即"graceful_stop",在你移除的服务器执行:# cd hbase_install_dir
# ./bin/graceful_stop.sh hostname该命令会自动关闭Load Balancer,然后Assigned Region,之后会将该节点关闭。除此之外,你还可以查看remove的过程,已经assigned了多少个Region,还剩多少个Region,每个Region 的Assigned耗时。
 
补充graceful stop的一些其他命令参数:# ./bin/graceful_stop.sh
Usage: graceful_stop.sh [--config &conf-dir>] [--restart] [--reload] [--thrift] [--rest] &hostname>
thrift If we should stop/start thrift before/after the hbase stop/start
rest If we should stop/start rest before/after the hbase stop/start
restart If we should restart after graceful stop
reload Move offloaded regions back on to the stopped server
debug Move offloaded regions back on to the stopped server
hostname Hostname of server we are to stop最终都需要我们手动打开load balancer:hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3590 seconds然后再开启:hbase(main):001:0> balance_switch true
false
0 row(s) in 0.3290 seconds对比两种方法,建议使用"graceful_stop"来移除hbase RegionServer节点。
官网说明:http://hbase.apache.org/0.94/book/node.management.html​  http://hbase.apache.org/book.html#decommission​  

移除hdfs datanode节点

1、在core-site.xml文件下新增如下内容<property>
<name>dfs.hosts.exclude</name>
<value>/hdfs_install_dir/conf/excludes</value>
</property>2、创建exclude文件,把需要删除节点的主机名写入# cd hdfs_install_dir/conf
# vim excludes
添加需要删除的节点主机名,比如 hdnode1 保存退出3、 然后在namenode节点执行如下命令,强制让namenode重新读取配置文件,不需要重启集群。# cd hdfs_install_dir/bin/
# ./hadoop dfsadmin -refreshNodes它会在后台进行Block块的移动
 4、 查看状态
等待第三步的操作结束后,需要下架的机器就可以安全的关闭了。# ./hadoop dfsadmin -report可以查看到现在集群上连接的节点 正在执行Decommission,会显示:
Decommission Status : Decommission in progress

执行完毕后,会显示:
Decommission Status : Decommissioned如下:Name: 10.0.180.6:50010
Decommission Status : Decommission in progress
Configured Capacity: 917033340928 (10.83 TB)
DFS Used: 7693401063424 (7 TB)
Non DFS Used: 118121652224 (110.00 GB)
DFS Remaining: 4105510625280(3.63 TB)
DFS Used%: 64.56%
DFS Remaining%: 34.45%
Last contact: Mon Nov 29 23:53:52 CST 2015也可以直接通过Hadoop 浏览器查看:
LIVE的节点可以查看到:http://master_ip:50070/dfsnodelist.jsp?whatNodes=LIVE
查看看到卸载的节点状态是:Decommission in progress
等待节点完成移除后,浏览:http://master_ip:50070/dfsnodelist.jsp?whatNodes=DEAD 结果如下:




完成后,删除的节点显示在dead nodes中。且其上的服务停止。Live Nodes中仅剩had2,had3
以上即为从Hadoop集群中Remove Node的过程,但是,有一点一定要注意:
hdfs-site.xml配置文件中dfs.replication值必须小于或者等于踢除节点后正常datanode的数量,即:dfs.replication <= 集群所剩节点数修改备份系数可以参考:http://heylinux.com/archives/2047.html

重载入删除的datanode节点 

1、修改namenode的core-site.xml文件,把我们刚刚加入的内容删除或者注释掉,我这里选择注释掉。<!--

<property>
<name>dfs.hosts.exclude</name>
<value>/root/hadoop/conf/excludes</value>
</property>

-->2、 再执行重载namenode的配置文件# ./bin/hadoop dfsadmin -refreshNodes3、最后去启动datanode上的datanode# ./bin/hadoop-daemon.sh start datanode
starting datanode, logging to /usr/local/hadoop/bin/../logs/hadoop-root-datanode-had1.out4、查看启动情况# jps
18653 Jps
19687 DataNode ---->启动正常重新载入HBase RegionServer节点
只需要重启regionserver进程即可。
参考:http://www.edureka.co/blog/commissioning-and-decommissioning-nodes-in-a-hadoop-cluster/
           https://pravinchavan.wordpress.com/2013/06/03/removing-node-from-hadoop-cluster/ 查看全部
线上有台服务器随时可能会挂掉,所以需要把在这个服务器上hbase的regionserver和hdfs的datanode节点移除。然后重新拿台新服务器部署接管。
 
之前在文章 http://openskill.cn/article/178 中讲到怎么新增一个hdfs的datanode,所以我先讲一下怎么添加一个hbase的regionserver,然后再讲怎么删除! 


添加hbase regionserver节点


添加步骤如下:
1、在hbase  master上修改regionservers文件
# cd hbase_install_dir/conf
# echo "new_hbase_node_hostname" >> ./regionservers
2、如果你hbase集群使用自身zk集群的话,还需要修改hbase-site.xml文件,反之不用操作!
# cd hbase_install_dir/conf
# vim hbase-site.xml
找到hbase.zookeeper.quorum属性 -->加入新节点
3、同步以上修改的文件到hbase的各个节点上
4、在新节点上启动hbase regionserver
# cd hbase_install_dir/bin/
# ./hbase-daemon.sh start regionserver
5、在hbasemaster启动hbase shell
用status命令确认一下集群情况
hbase新增一个 regionserver节点补充完成了,下面介绍删除hbase和hdfs节点!
 
集群上既部署有Hadoop,又部署有HBase,因为HBase存储是基于Hadoop HDFS的,所以先要移除HBase节点,之后再移除Hadoop节点。添加则反之。


移除hbase regionserver节点


1、在0.90.2之前,我们只能通过在要卸载的节点上执行;我的hbase版本(0.98.7)
# cd hbase_install_dir
# ./bin/hbase-daemon.sh stop regionserver
来实现。这条语句执行后,该RegionServer首先关闭其负载的所有Region而后关闭自己。在关闭时,RegionServer在ZooKeeper中的"Ephemeral Node"会失效。此时,Master检测到RegionServer挂掉并把它作为一个宕机节点,并将该RegionServer上的Region重新分配到其他RegionServer。
 
注意:使用此方法前,一定要关闭HBase Load Balancer。关闭方法:
hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3290 seconds
总结:
这种方法很大的一个缺点是该节点上的Region会离线很长时间。因为假如该RegionServer上有大量Region的话,因为Region的关闭是顺序执行的,第一个关闭的Region得等到和最后一个Region关闭并Assigned后一起上线。这是一个相当漫长的时间。以我这次的实验为例,现在一台RegionServer平均有1000个Region,每个Region Assigned需要4s,也就是说光Assigned就至少需要1个小时。
2、自0.90.2之后,HBase添加了一个新的方法,即"graceful_stop",在你移除的服务器执行:
# cd hbase_install_dir
# ./bin/graceful_stop.sh hostname
该命令会自动关闭Load Balancer,然后Assigned Region,之后会将该节点关闭。除此之外,你还可以查看remove的过程,已经assigned了多少个Region,还剩多少个Region,每个Region 的Assigned耗时。
 
补充graceful stop的一些其他命令参数:
# ./bin/graceful_stop.sh
Usage: graceful_stop.sh [--config &conf-dir>] [--restart] [--reload] [--thrift] [--rest] &hostname>
thrift If we should stop/start thrift before/after the hbase stop/start
rest If we should stop/start rest before/after the hbase stop/start
restart If we should restart after graceful stop
reload Move offloaded regions back on to the stopped server
debug Move offloaded regions back on to the stopped server
hostname Hostname of server we are to stop
最终都需要我们手动打开load balancer:
hbase(main):001:0> balance_switch false
true
0 row(s) in 0.3590 seconds
然后再开启:
hbase(main):001:0> balance_switch true
false
0 row(s) in 0.3290 seconds
对比两种方法,建议使用"graceful_stop"来移除hbase RegionServer节点。
官网说明:http://hbase.apache.org/0.94/book/node.management.html​  http://hbase.apache.org/book.html#decommission​  


移除hdfs datanode节点


1、在core-site.xml文件下新增如下内容
<property>
<name>dfs.hosts.exclude</name>
<value>/hdfs_install_dir/conf/excludes</value>
</property>
2、创建exclude文件,把需要删除节点的主机名写入
# cd hdfs_install_dir/conf
# vim excludes
添加需要删除的节点主机名,比如 hdnode1 保存退出
3、 然后在namenode节点执行如下命令,强制让namenode重新读取配置文件,不需要重启集群。
# cd hdfs_install_dir/bin/
# ./hadoop dfsadmin -refreshNodes
它会在后台进行Block块的移动
 4、 查看状态
等待第三步的操作结束后,需要下架的机器就可以安全的关闭了。
# ./hadoop dfsadmin -report
可以查看到现在集群上连接的节点 
正在执行Decommission,会显示: 
Decommission Status : Decommission in progress

执行完毕后,会显示:
Decommission Status : Decommissioned
如下:
Name: 10.0.180.6:50010
Decommission Status : Decommission in progress
Configured Capacity: 917033340928 (10.83 TB)
DFS Used: 7693401063424 (7 TB)
Non DFS Used: 118121652224 (110.00 GB)
DFS Remaining: 4105510625280(3.63 TB)
DFS Used%: 64.56%
DFS Remaining%: 34.45%
Last contact: Mon Nov 29 23:53:52 CST 2015
也可以直接通过Hadoop 浏览器查看:
LIVE的节点可以查看到:http://master_ip:50070/dfsnodelist.jsp?whatNodes=LIVE
查看看到卸载的节点状态是:Decommission in progress
等待节点完成移除后,浏览:http://master_ip:50070/dfsnodelist.jsp?whatNodes=DEAD 结果如下:
hdead.png

完成后,删除的节点显示在dead nodes中。且其上的服务停止。Live Nodes中仅剩had2,had3
以上即为从Hadoop集群中Remove Node的过程,但是,有一点一定要注意:
hdfs-site.xml配置文件中dfs.replication值必须小于或者等于踢除节点后正常datanode的数量,即:
dfs.replication <= 集群所剩节点数
修改备份系数可以参考:http://heylinux.com/archives/2047.html


重载入删除的datanode节点 


1、修改namenode的core-site.xml文件,把我们刚刚加入的内容删除或者注释掉,我这里选择注释掉。
<!--

<property>
<name>dfs.hosts.exclude</name>
<value>/root/hadoop/conf/excludes</value>
</property>

-->
2、 再执行重载namenode的配置文件
# ./bin/hadoop dfsadmin -refreshNodes
3、最后去启动datanode上的datanode
# ./bin/hadoop-daemon.sh start datanode
starting datanode, logging to /usr/local/hadoop/bin/../logs/hadoop-root-datanode-had1.out
4、查看启动情况
# jps
18653 Jps
19687 DataNode ---->启动正常
重新载入HBase RegionServer节点
只需要重启regionserver进程即可。
参考:http://www.edureka.co/blog/commissioning-and-decommissioning-nodes-in-a-hadoop-cluster/
           https://pravinchavan.wordpress.com/2013/06/03/removing-node-from-hadoop-cluster/

新增一个hdfs的DataNode节点

大数据/云计算采菊篱下 发表了文章 • 1 个评论 • 2674 次浏览 • 2015-11-11 01:51 • 来自相关话题

场景

在hadoop中的分布式文件系统hdfs中,当存储节点磁盘使用达到预警值是,我们需要新增一个数据存储节点,来存储数据!我这里hdfs的版本是2.2.0!新增方法:
[]静态添加[/][]动态添加[/]

静态添加

静态新增的方式,就是相当于我们起初部署hdfs集群规划一样,停止NameNode,新增一个DateNode数据节点,这种方法不适用于线上提供服务的场景,具体操作如下:

1、停止NameNode节点
# cd hdfs_install_dir/sbin/
# ./hadoop-deamon.sh stop namenode

2、修改配置文件slaves文件,并修改/etc/hosts记录把新增的节点对应的ip和hostname追加到各节点
# cd hdfs_install_dir/etc/hadoop/
# echo "new_datanode_hostname" >> ./slaves
# echo "new_datanode_ip new_datanode_hostname" >> /etc/hosts
然后再利用rsync 同步配置文件和hosts文件,到各节点

3、确保Hadoop/HDFS集群的NameNode可以对新节点进行SSH免密码登录。

4、重新启动NameNode节点

5、如果你希望各数据节点磁盘使用量达到一个相对平衡的状态,就是百分比,你还需要执行hadoop balance命令,后面会具体讲到!


动态添加

动态添加,不需要停止启动NameNode节点,具体步骤如下:

1、修改所有hdfs集群机器的配置文件slaves文件,并修改/etc/hosts记录把新增的节点对应的ip和hostname追加到各节点
# cd hdfs_install_dir/etc/hadoop/
# echo "new_datanode_hostname" >> ./slaves
# echo "new_datanode_ip new_datanode_hostname" >> /etc/hosts

如果你使用ansible管理的话,hdfs集群的集群做一个叫hdfs的分组,两条命令搞定:
# ansible hdfs -m shell -a 'echo "new_datanode_hostname" >> hdfs_install_dir/etc/hadoop/slaves'
# ansible hdfs -m shell -a 'echo "new_datanode_ip new_datanode_hostname" >> /etc/hosts'
这样所有的节点slaves文件和host文件都更新了!

2、启动新增的datanode节点
# cd hdfs_install_dir/sbin
# ./hadoop-daemon.sh start datanode

3、查看是否正常加入到集群
web查看方式:http://NameNode_ip:50070/dfsnodelist.jsp?whatNodes=LIVE
命令查看方式:cd hdfs_install_dir/bin/ && ./hadoop dfsadmin -report

4、数据再平衡
添加新节点时,HDFS不会自动重新平衡。然而,HDFS提供了一个手动调用的重新平衡(reblancer)工具。这个工具将整个集群中的数据块分布调整到一个可人工配置的百分比阈值。如果在其他现有的节点上有空间存储问题,再平衡就会根据阀值,然后平衡分布数据。

执行再平衡命令,可选参数-threshold指定了磁盘容量的余量百分比,用来判定一个节点的磁盘利用率是过低还是过高。一个利用不足的数据节点其利用率低于平均利用率−阈值。过度利用的数据节点其利用率高于平均利用率+阈值。该参数设置的越小,整个集群越平衡,但会花费更多的时间进行再平衡操作。默认阈值为10%。平衡执行命令如下:
# cd hdfs_install_dir/sbin/
# ./start-balancer.sh -threshold 5

-threshold参数就是是指定平衡的阈值。
-threshold的默认是10,即每个datanode节点的实际hdfs存储使用量/集群hdfs存储量

具体解释例子如下:
datanode hdfs使用量1000G;
集群总hdfs存储量10T即10000G;
则t值为1000/10000 = 0.1 = 10%
当执行balance的-t参数小于0.1时,集群进行balance;
命令为:start-balancer.sh -threshold 10 ;Expecting a number in the range of [1.0, 100.0]: 5%sh $HADOOP_HOME/bin/start-balancer.sh –t 10%
这个命令中-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果机器与机器之间磁盘使用率偏差小于10%,那么我们就认为HDFS集群已经达到了平衡的状态。


标注知识点

1、 balance命令可以在namenode或者datanode上启动,也可以随时利用stop-balance.sh脚本停止平衡!

2、balance的默认带宽是1M/s。 如果你希望修改平衡数据的带宽大小可以用./hdfs dfsadmin -setBalancerBandwidth 124288000命令指定

3、slave文件是用于重启时使用。集群的start和stop需要读取slave文件。启用datanode时只要在hdfs-site中配置了namenode位置,就可以将信息push给namenode。 这就是为什么slaves文件很重要的原因。 查看全部


场景


在hadoop中的分布式文件系统hdfs中,当存储节点磁盘使用达到预警值是,我们需要新增一个数据存储节点,来存储数据!我这里hdfs的版本是2.2.0!
新增方法:
    []静态添加[/][]动态添加[/]


静态添加


静态新增的方式,就是相当于我们起初部署hdfs集群规划一样,停止NameNode,新增一个DateNode数据节点,这种方法不适用于线上提供服务的场景,具体操作如下:

1、停止NameNode节点
# cd hdfs_install_dir/sbin/
# ./hadoop-deamon.sh stop namenode

2、修改配置文件slaves文件,并修改/etc/hosts记录把新增的节点对应的ip和hostname追加到各节点
# cd hdfs_install_dir/etc/hadoop/
# echo "new_datanode_hostname" >> ./slaves
# echo "new_datanode_ip new_datanode_hostname" >> /etc/hosts
然后再利用rsync 同步配置文件和hosts文件,到各节点

3、确保Hadoop/HDFS集群的NameNode可以对新节点进行SSH免密码登录。

4、重新启动NameNode节点

5、如果你希望各数据节点磁盘使用量达到一个相对平衡的状态,就是百分比,你还需要执行hadoop balance命令,后面会具体讲到!


动态添加


动态添加,不需要停止启动NameNode节点,具体步骤如下:

1、修改所有hdfs集群机器的配置文件slaves文件,并修改/etc/hosts记录把新增的节点对应的ip和hostname追加到各节点
# cd hdfs_install_dir/etc/hadoop/
# echo "new_datanode_hostname" >> ./slaves
# echo "new_datanode_ip new_datanode_hostname" >> /etc/hosts

如果你使用ansible管理的话,hdfs集群的集群做一个叫hdfs的分组,两条命令搞定:
# ansible hdfs -m shell -a 'echo "new_datanode_hostname" >> hdfs_install_dir/etc/hadoop/slaves'
# ansible hdfs -m shell -a 'echo "new_datanode_ip new_datanode_hostname" >> /etc/hosts'
这样所有的节点slaves文件和host文件都更新了!

2、启动新增的datanode节点
# cd hdfs_install_dir/sbin
# ./hadoop-daemon.sh start datanode

3、查看是否正常加入到集群
web查看方式:http://NameNode_ip:50070/dfsnodelist.jsp?whatNodes=LIVE
命令查看方式:cd hdfs_install_dir/bin/ && ./hadoop dfsadmin -report

4、数据再平衡
添加新节点时,HDFS不会自动重新平衡。然而,HDFS提供了一个手动调用的重新平衡(reblancer)工具。这个工具将整个集群中的数据块分布调整到一个可人工配置的百分比阈值。如果在其他现有的节点上有空间存储问题,再平衡就会根据阀值,然后平衡分布数据。

执行再平衡命令,可选参数-threshold指定了磁盘容量的余量百分比,用来判定一个节点的磁盘利用率是过低还是过高。一个利用不足的数据节点其利用率低于平均利用率−阈值。过度利用的数据节点其利用率高于平均利用率+阈值。该参数设置的越小,整个集群越平衡,但会花费更多的时间进行再平衡操作。默认阈值为10%。平衡执行命令如下:
# cd hdfs_install_dir/sbin/
# ./start-balancer.sh -threshold 5

-threshold参数就是是指定平衡的阈值。
-threshold的默认是10,即每个datanode节点的实际hdfs存储使用量/集群hdfs存储量

具体解释例子如下:
datanode hdfs使用量1000G;
集群总hdfs存储量10T即10000G;
则t值为1000/10000 = 0.1 = 10%
当执行balance的-t参数小于0.1时,集群进行balance;
命令为:start-balancer.sh -threshold 10 ;
Expecting a number in the range of [1.0, 100.0]: 5%
sh $HADOOP_HOME/bin/start-balancer.sh –t 10%
这个命令中-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果机器与机器之间磁盘使用率偏差小于10%,那么我们就认为HDFS集群已经达到了平衡的状态。


标注知识点


1、 balance命令可以在namenode或者datanode上启动,也可以随时利用stop-balance.sh脚本停止平衡! 

2、balance的默认带宽是1M/s。 如果你希望修改平衡数据的带宽大小可以用./hdfs dfsadmin -setBalancerBandwidth 124288000命令指定

3、slave文件是用于重启时使用。集群的start和stop需要读取slave文件。启用datanode时只要在hdfs-site中配置了namenode位置,就可以将信息push给namenode。 这就是为什么slaves文件很重要的原因。
云技术、大数据处理