Kafka学习记录

Apache Kafka 是一个分布式消息发布和订阅系统,具有以下特点: 被设计为生产者(发布)和消费者(订阅)模式,解耦组件之间的依赖,异步处理消息,增强业务扩展能力。 作为分布式系统,具备高伸缩能力,为发布和订阅提供高吞吐量。 持久化消息到磁盘,直到消息过期,兼备批处理和实时处理消息的能力。 冗余消息数据,具备高可用能力。 本质上是队列,为消息订阅提供顺序保证。 基本概念 Broker(中介) Kafka集群中的每一个server都是一个broker,具备唯一的id,消息的中转和暂存媒介,为消息提供持久化。消息被发布到这里时,首先滞留在内存中,等待异步线程刷入磁盘;订阅消息时首先会从内存取,如果没有则通过映射的index找到消息位置,发生磁盘IO。 Topic(话题) 每条发布到Kafka集群的消息都有一个类别,这个类

Zookeeper学习与实践

ZooKeeper是一个开源的分布式服务框架,它是Apache Hadoop项目的一个子项目,主要用来解决分布式应用场景中存在的一些问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置管理等,它支持Standalone模式和分布式模式(一个Leader,多个Follower),在分布式模式下,能够为分布式应用提供高性能和可靠地协调服务。 ZooKeeper集群中只有一个角色为Leader的节点,其他节点都为Follower。当客户端Client连接到ZooKeeper集群中任何一个节点执行写请求时,这些请求都会被发送到Leader节点上,然后Leader节点上数据变更会同步到集群中其他的Follower节点。 Leader节点在接收到数据变更请求后,首先将变更写入本地磁盘,以作恢复之用。当所有的写请求持久化到磁盘

搭建Nagios core+SNMP监控平台

公司目前的监控预警体系主要靠自己编写Python脚本,读取各种性能指标,并判断是否超过阀值;每一台被监控机器上都部署该脚本;中央监视平台定期访问每个被监控端获取超越阀值的预警信息,如果有预警则发送邮件。在服务器数量少的情况下运维压力不大,而如今服务器数量增长到几十台,分布在阿里云和自有机房,所以需要寻求一种更加可靠的统一的监控预警体系。于是我们将目光落在Nagios上~~ Nagios简介 Nagios core本身是一个开源框架,它可以注册需要监控的主机和服务,周期性调用插件去检测主机和服务的状态,并提供web界面来查看这些状态信息,同时支持email等方式发送预警。与被监控主机间的通信和监控内容则是通过各种插件来实现的。官方提供了一些插件,通过安装Nagios Plugins即可,如果想要使用snmp插件还需要预先安装

Hadoop集群虚拟化扩展(HVE )配置实践

公司的hadoop集群搬家到新机房后的结构大致是这样,每台物理机上安装两个虚拟机,每个虚拟机上装载一个hadoop节点,集群水平扩展。为了提高集群可靠性、最大化发挥物理设备的能力和充分利用资源,决定尝试使用HVE(Hadoop Virtualization Extensions)配置。 以下情况发生时需要考虑启用HVE 每台物理机上装载多个hadoop虚拟机环境。 DataNodes和TaskTrackers存在于不同的虚拟机环境下,为了实现hadoop集群计算组件的更好的伸缩性。 在主机和机架之间存在一个拓扑层(例如机箱chassis),其故障会对非虚拟环境的主机间造成影响。 HVE要做的事情 在同一物理机上的虚拟机(数据节点)受到同一存储控制器或硬件故障的影响。所以会考虑避免跨虚拟机的两个数据副本落在同一物理机上。 在

Pacemaker和Corosync学习记录

前阵子在搭建Postgres-XL集群过程中,为了实现高可用首先尝试了官方推荐的Pacemaker配合Corosync方案,由于官方并未给出具体实践案例,所以只能摸索实现。首先还是要恶补基础知识~~ 什么是Pacemaker Pacemaker是可扩展的高可用集群资源管理器,它利用外部的集群基础构件(如OpenAIS 、heartbeat或corosync)提供的消息和成员管理能力,来探测并从节点或资源级别的故障中恢复,实现集群高可用。它是Heartbeat资源管理器V3版本后独立出来的项目,延续自CRM(Heartbeat V2管理器),但是不再耦合消息通信层(heartbeat)。操作Pacemaker的用户命令或接口主要有crmsh(源自V2)和pcs等。 什么是Corosync Corosync是开放性集群引擎工程

Mongodb实战记录

自加入公司以来,接触过的产品如《糖果萌萌消》、《梦幻蛋糕店》、《冰雪奇缘》等,使用的数据库均是mysql+mongodb,其中mongodb承载了99%以上的数据量和访问量。早期受mongodb版本等历史原因的限制,采用的是在应用程序的数据访问层依据userId进行分表,各分表落在不同的mongodb实例上且无副本,虽然分担了负载但可用性较低,如《梦幻蛋糕店》、《冰雪奇缘》和《糖果萌萌消》的最初阶段都是这样。后来随着《糖果萌萌消》用户量不断增长以及mongodb的发展完善,到目前为止数据库层进行了两次较大改变。 第一次改变:使用mongodb分片集群 起因: 旧的集群是以userId%10的方式,用余数关联数据库ip(mongoClient)和mongodb集合名字(collection)。各个mongod实例彼此独立存在

使用vSphere克隆虚拟机

最近公司的hadoop集群需要增加新节点,为了方便快捷,采用克隆已有节点的方式进行。以下是实施过程记录,思路是先创建虚拟机然后用已有虚拟机文件替换再改吧改吧。 查看新机器物理磁盘,这里可以卸载(分离)、挂载物理磁盘。 修改SSH防火墙和启用SSH 添加第二块网卡 创建新虚拟机,预留内存 克隆虚拟机 关闭源和目的虚机,登录物理机,删除刚创建的虚拟机目录下最大的那个vmdk文件 把源虚机的VMDK文件拷贝到目的虚机,跨物理机机拷贝可能需要 ssh 两个主机 禁用网络后打开目的虚拟机电源并登录root,密码跟源机一样 修改/etc/sysconfig/network-scripts/ifcfg-enoXXXX里的ip,避免和源虚机冲突;注释掉/etc/fstab里源虚拟机挂载的磁盘。 关闭目的虚拟机shutdown now,启用

PGXL集群搭建和实现高可用

公司新游戏《Solitaire Squirrel》要求使用postgreSql数据库,据说优于mongodb(不知道从什么角度看的),于是着手开搞。在搭建数据库集群之前首先恶补基础知识(postgreSql、postgres-xc、postgres-xl)……一周以后,小有心得~~ 基本概念 PostgreSQL是完全支持ACID(原子性-Atomicity、一致性-Consistency、隔离性-Isolation、持久性-Durability)特性的开源数据库;Postgres-XC是开源的,写可扩展的,同步对称的,多租户安全的PostgreSQL集群方案;Postgres-XL出于XC而胜于XC。 PGXL集群架构(摘自这里) PGXL是一系列PostgreSQL数据库的集群,在上层看来就像使

科学上网和学习笔记

最开始只是想用来科学上网,于是在搬瓦工上租了个服务器;后来觉得仅仅这样有点浪费,就顺便又弄了个wordpress,记点笔记。 准备工作 首先在搬瓦工上注册账号,信息尽量真实,比如国家,否则后面可能会被认为欺诈,没收服务器,亲身体验~~ 然后购买适合自己的VPS,购买前最好看看support->Knowledgebase。如果需要运行wordpress最好选择512M以上内存。 购买成功后可以在services->My services里看到,点击KiwiVM Control Panel可以进入控制台。 在控制台里乱搞一通后就熟悉了。 账户安全 重装系统,使用centos7。 新建用户并配置证书ssh登录,保存私钥到本地。 新用户免密码su root,禁用密码登录,禁用root用户ssh登录。 语言环境 修改为U