etcd 2.1发布,可不宕机滚动升级

本文讲的是etcd 2.1发布,可不宕机滚动升级,【编者的话】etcd是一个用于配置共享和服务发现的高性能的键值存储系统。在2.0版本发布半年之后,etcd终于发布了新的2.1版本,2.1修复了2.0中的众多BUG,并引入了很多新功能,如在线不中断更新与新的鉴权API等众多改进与新功能。

经过数月的艰苦工作,etcd 2.1终于发布了。自从1月份2.0版本发布以来,整个研发团队收集了很多非常有价值的反馈,而且这些反馈都来自于真实生产环境。在这些反馈的基础上,我们发布了新的2.1版本,新功能包括:鉴定/授权API、新的监控API、提升了传输的稳定性、改进了etcd服务器集群之间传输数据的性能、增强了集群的运行稳定性。

快速回顾下,我们发现etcd是一个开源的、分布式的、基于持续键值对存储的服务器集群共享配置、服务发现以及服务节点调度解决方案。使用etcd,即使面对单个服务器失效,应用依然可以继续运行。同时etcd也是CoreOS的核心组件,它为CoreOS带来了安全的自动更新、主机调度的协调工作以及容器的覆盖网络(overlay)等功能。

如果你觉得看简介比较繁琐,你可以在GitHub上下载我们最新的二进制文件。同时,etcd 2.1.1已经包含在了CoreOS 725.1.0中了(现在在alpha通道中),所以你可以自己下载去玩。

从2.0版不宕机滚动升级

从2.0版升级到2.1版是一个零宕机滚动升级过程。你可以根据向导提示,将集群一步步从2.0升级到2.1。详细信息可以参考升级文档。如果你当前运行的版本低于0.4.x,那么你必须先升级到2.0,然后从2.0版升级到2.1。

同时,随着版本的发布,etcd 2.1是目前最稳定的etcd版本,所以所有的bug修改都会以2.1.x版本为基础,不再针对之前的2.0.x版本发布修改。

发布鉴权API

这个版本的一个重要特性是/v2/auth端,为etcd的键值对API加入了鉴权功能。这个API允许为用户和角色加key前缀,并且允许用户使用HTTP基本认证功能,这样可以使团队合作更加可控。这个功能包含在etcd的HTTP Server、etcdctl命令行客户端以及etcd/client的Go开发包中。你可以在etcd权限管理文档中找到更多的细节。但是还是要注意,这是个实验性的功能,而且会随着用户的反馈而不断改进。我想我们的方向是正确的,但是对于API的细节可能会发生调整。

提升传输稳定性

很多使用etcd的用户所在的网络环境不是很好,包括高延迟、网络数据不一致等问题比较多。我们虽然不能保证etcd可以应付所有复杂的网络环境,但是我们在这一版中对etcd在使用网络方面做了很多优化,使得etcd在复杂网络环境情况下能够更好的工作。

首先,我们减少了建立连接的开销,同时使得一致性协议(raft)的通信更加高效与稳定,现在etcd的节点之间通过长连接来进行通信。其次,减少raft命令的提交延迟,现在每个raft附加消息(append massage)都附属在一个提交索引(commit index)之下。在轻负荷(<100写操作/秒)情况下提交延迟由100ms减少到1ms。最后,etcd的raft实现能提供更好的内部数据流转控制,显著的减少了raft消息丢包的情况同时还改进了CPU与内存的使用效率。

对etcd进行功能性测试

我们在发布2.1之前的4个月里,在自建的故障注入(fault-injecting)型功能测试框架里运行etcd,来对etcd做严格测试。我们的目标是让etcd在重度使用的情况下仍能够保持功能上的容错性;在这几个月的测试中,我们发现etcd能够在很多极其严苛与各种功能失效的情况下保持服务的鲁棒性。而且我们会在2.1发布之后持续对etcd进行测试。

改进了日志功能

现在支持分级日志了。用户根据业务需要设置日志级别。同时对于DEBUG级别的日志我们会重复啰嗦的记录几遍,所以etcd的默认日志的可读性会提高很多。你可以通过设置flag来控制日志的级别,参考这里

新的监控API

etcd 2.1发布了新的监控API,并可以用于排错(debug)与实时(real-time)的监控。它提供了对客户端使用情况与资源利用方面的统计功能。向之前的鉴权API一样,这个也是实验性的功能,可能会根据反馈进行调整、改进。

开始使用吧

我们会一如既往的把etcd打造成一个Google风格的底层的基础工具,用户可以开箱即用、信任它并且依赖它提供的服务。开始使用etcd吧,持续为我们提供您的反馈,甚至可以直接贡献代码

--------------------------------------------------
原文链接:Introducing etcd 2.1 (翻译:肖劲 审校:魏小红)

原文发布时间为:2015-07-29

本文作者:amwtke

本文来自合作伙伴DockerOne,了解相关信息可以关注DockerOne。

原文标题:etcd 2.1发布,可不宕机滚动升级

时间: 2024-11-01 04:34:07

etcd 2.1发布,可不宕机滚动升级的相关文章

艾默生网络能源发布《2016年数据中心宕机成本》

--数据中心故障每分钟为企业带来损失近9000美元 最新研究报告发现,数据中心宕机成本持续攀升:5年内平均宕机成本增加38% 近日,艾默生网络能源与Ponemon研究院合作,发布了<2016年数据中心宕机成本>报告,对数据中心意外宕机所带来的成本进行了评估.这是艾默生网络能源与Ponemon研究院,在对美国过去12个月当中发生过宕机的63个数据中心进行调查后所做出的研究结论. 艾默生网络能源与Ponemon研究院曾在2010年首次联合发布了数据中心宕机成本研究--一项对数据中心宕机的成本与成因

HBase原理-RegionServer宕机数据恢复

HBase采用类LSM的架构体系,数据写入并没有直接写入数据文件,而是会先写入缓存(Memstore),在满足一定条件下缓存数据再会异步刷新到硬盘.为了防止数据写入缓存之后不会因为RegionServer进程发生异常导致数据丢失,在写入缓存之前会首先将数据顺序写入HLog中.如果不幸一旦发生RegionServer宕机或者其他异常,这种设计可以从HLog中进行日志回放进行数据补救,保证数据不丢失.HBase故障恢复的最大看点就在于如何通过HLog回放补救丢失数据. HLog简介 为了更好的理解H

Twitter 没有在美国总统竞选期间宕机

周二晚上,在美国2012年总统大选揭晓的时刻,微博网站Twitter遭遇了有史以来最大的访问冲击,服务的负载量陡增,但却没让用户感到丝毫的反应迟钝--一些Twitter的开发人员把这归功于公司把后端软件从Ruby迁移到Java的正确决策. 根据Twitter公司负责架构的副总工程师Mazen Rawashdeh在 博客上透露的信息,周二在太平洋时间的晚上8:11分到9:11分期间,Twitter用户平均每秒钟发布9965条信息. Rawashdeh写到,在8:20分里的有一个一秒里,Twitte

Gmail宕机 备份问题成云计算新题

本文讲的是Gmail宕机 备份问题成云计算新题,[IT168 资讯]周二的Gmail宕机事件不仅给用户带来了不便,还再次引发了用户对于云计算可行性的担忧.一种比较流行的说法是,今后的电脑无需大容量硬盘,因为所有的应用和个人数据(包括图片.视频.文档和电子邮件)都将被存储于远程服务器中,这也就是所谓的"云计算". 但是当文件的访问超出了自己的控制时,这种乌托邦式的计算方式究竟有多少可行性呢? Gmail周二的宕机事件导致许多用户近2个小时无法访问电子邮件.故障排除后,谷歌通过官方博客表示

暗影追踪:是谁入侵了近百万台路由器,让德国电信全网宕机

本文讲的是暗影追踪:是谁入侵了近百万台路由器,让德国电信全网宕机, 2017年2月,英国国家犯罪局(NCA)在伦敦机场逮捕一名29岁的英国嫌疑人, 涉嫌攻击2016年11月底德国的90万个路由器.根据披露的信息,本次攻击疑似为Mirai变种导致,分析人员在相关感染的样本中发现了与Mirai相同的代码.但与Mirai不同的特征在于,Mirai在进行感染传播的过程中,会对目标的23和2323端口进行扫描,而这次的样本是针对目标的7547端口进行扫描.我们捕获到了与此次攻击类似的样本并对其进行详细分析

MySQL集群节点宕机,数据库脑裂!如何排障?

作者介绍 王晶,中国移动DBA,负责"移动云"业务系统的数据库集成架构设计.运维.优化等工作:擅长技术领域MySQL,获Oracle颁发的"MySQL DBA"官方认证,熟悉MySQL复制结构.MHA.cluster等多种架构及运维优化.   发现故障的时间正值大年初二,在各种铺天盖地的拜年信息和微信红包之中,我发现了手机上的这条告警通知:   PROBLEM:Disaster: Galera cluster has node down.我生产环境的Galera集群

谁之过?盘点2015年上半年IT宕机事件

在互联网已经成功"挟持"我们的现在,假如未来某天早晨起床后发现,网络瘫痪,服务器宕机,我们早已习惯了的"秩序"轰然倒塌,那会是何种场景?   人始终有种不满足的心态,希望身边的一切都是完美的,但现实却总不能如愿.就像服务器,谁也不敢说能够达到100%的可靠性.然后人们就去追求99.9999%,追求99.999%,要求每年的宕机时间要少于在5.26分钟. 2015已过半,在这半年内,全球共发生了多少起宕机事件,已无法统计,但是,我们仍然希望举出我们所熟知的例子,来&q

打错一个字母瘫痪半个互联网!亚马逊 S3 宕机事件缘由

2月28号,号称「亚马逊AWS最稳定」的云存储服务S3出现"超高错误率"的宕机事件. 接着,半个互联网都跟着瘫痪了. 一个字母造成的血案 AWS在昨天给出了确切的解释:一名程序员在调试系统的时候,运行了一条原本打算删除少量服务器的脚本,结果输错了一个字母,导致大量服务器被删.为了修复这个错误,亚马逊不得不重启整个系统(在此之前已经几年都没有重启过了),最终导致了震惊全球的Amazon S3宕机4个小时事件. 我想这名程序猿当时的表情应该是这样的 曾经有人计算过,AWS每宕机一分钟,对亚

【深度分析】不安全的IOT设备是如何导致Twitter、PayPal等网站宕机的?

日前,一场大规模的互联网瘫痪席卷了美国,2016年10月21日 11:10 UTC(北京时间19:10左右)恶意软件Mirai控制的僵尸网络对美国域名服务器管理服务供应商Dyn发起DDOS攻击,从而导致许多网站在美国东海岸地区宕机.以下是来自青莲云对感染IOT设备的恶意软件Mirai的分析. 本文您将看到: 1.攻击事件回顾 2.恶意软件Mirai是什么 3.Mirai如何感染IOT设备的 4.Mirai如何控制IOT设备发起攻击 5.Mirai的另一种攻击思路 6.如何防止智能设备被恶意利用