http://www.ox-holdings.com

故障节点和影响范围本次故障仅发生在中国节点,域名受到混合型 DDoS 攻击

摘要即时通讯云 LeanCloud 3月29日因少量大用户量应用的高在线量而发生了连锁服务故障,这个问题相信不是第1次发生,也不会是最后一次。对于即时通讯云服务商来说,要想在成本和服务质量上达成平衡,暂期内只能是个梦。2016 年 3 月 29 日晚间,LeanCloud 平台上的多个应用进行了推广活动,激增的访问量给我们的数据存储和实时通信服务带来了较大压力。从 20:50 至 22:15 有多次流量高峰出现,我们多台 Web 服务器的网络吞吐包超过虚拟机的能力极限,内外网通信中断,从而导致 HTTP 服务多次出现间歇性故障(数据存储 API 以及依赖于它的服务也都间歇性不可用)。具体情况汇报如下:故障时间20:53 - 21:03(持续约 10 分钟)数据存储 API 服务约 50% 的请求超时。21:17 - 21:40(持续约 23 分钟)数据存储 API 服务约 50% 的请求超时。22:00 - 22:15(持续约 15 分钟)数据存储 API 服务约 12.5% 的请求超时。故障总共持续约 48 分钟。影响范围本次故障只影响中国节点,美国节点的所有服务均工作正常。在故障期间凡是向 LeanCloud 平台发送过请求,并使用了数据存储服务的活跃应用都受到了影响;我们的统计服务也在短时间内无法正常接收来自应用的事件上报。事故过程20:52:内部监控系统报警,显示多个 Web 服务器节点出现故障。我们立刻上线进行紧急处理,在排除后端服务问题之后,开始追查前端资源和带宽配额。21:03:由于部分应用流量回落,同时也由于我们临时大幅增加了出口带宽,服务暂时恢复正常。21:05:我们开始扩容前端机集群,以应对接下来可能再次出现的流量高峰。21:17:前端机扩容时碰到了虚拟机 OS 故障以及网络环境问题,未能及时完成。此时恰好部分应用又迎来一次流量高峰,前端机再次吃紧。21:30:修复过程将近半小时,于是我们启动了公告和通知流程,在微博和用户群里发出通告。21:40:流量自然回落,前端机再次恢复正常,我们的平台开始正常处理 API 请求。22:00:线上部分前端机出现物理故障,我们又开始对它们进行紧急处理,期间有大约 1/8 的 API 请求丢失。22:15:新的前端机节点经过手动处理后终于达到可用状态,并加入集群,完成了扩容,至此全部服务彻底被恢复。后续改进措施增加新的监控措施,对前端机网络入包量进行监控,防止网络转发量超过 VM 能力限制。调整前端机 VM 配置,使用高包量机型,增大前端机的处理能力。改进前端机扩容方式,使用 docker 镜像来加快新节点部署上线的进度。公告流程中增加短信通知渠道,确保信息及时通知到开发者。

摘要即时通讯云 LeanCloud 4月5日因DDoS攻击致即时通讯服务全面瘫痪,混合型 DDoS 攻击从2016 年 4 月 5 日 20:19 开始,历时约一小时。此次服务中断给大量应用造成了严重影响。2016 年 4 月 5 日 20:19 开始,即时通讯云服务商 LeanCloud 的api.leancloud.cn 域名受到混合型 DDoS 攻击,致使用户无法从外网访问中国节点 API 服务,造成数据存储、统计、推送、短信等服务全部访问中断,历时约一小时。此次服务中断给大量应用造成了严重影响。故障时间20:19 ~ 21:25(持续约 66 分钟)影响范围中国节点的数据存储、统计、推送、短信等服务不可访问。美国节点的所有服务未受影响。事故过程20:19:针对 api.leancloud.cn 的攻击开始出现,监控系统告警。20:22:api.leancloud.cn 对应的外网 IP 逐一被攻击,数据存储 API 基本不可访问。20:40:我们在上游服务商的协助下开始接入高防,对流量进行清洗。21:19:攻击流量明显减少,服务开始恢复。因为 DNS 缓存更新会有几分钟的滞后,终端用户的访问恢复可能也会经历这个时间差。21:25:从LeanCloud统计数据来看,API 请求量回到正常水平,服务完全恢复。LeanCloud承诺的改进措施本次攻击的目标是LeanCloud的 API 主域名,并且发生在傍晚的流量高峰时段,致使大量应用受到影响。为了避免此类问题再次发生,LeanCloud决定进行如下改进:完善应对 DDoS 攻击的策略和措施,进一步减少受攻击时域名恢复需要的时间;API 服务对外增加多路备选域名,且让应用之间的访问能够隔离,避免一个域名受攻击而影响所有应用,保证 SDK 请求不会中断;拆分 LeanCloud 主站与 api.leancloud.cn 对应的外网 IP,保证故障时主站依然能够打开并展示相关提示信息。

摘要针对近期的服务稳定性问题,即时通讯云服务端LeanCloud进行相关优化,并在接下来的服务过程中启用改进和即时通讯云计费方式。以下为来自即时通讯云 LeanCloud官方的消息:LeanCloud 近期经历了比以往更频繁的稳定性方面的事故,其中有的是因为容量规划上的不足导致服务收到异常流量影响,有的是对上游服务商的域名攻击,有的是针对 LeanCloud 的 DDoS 攻击。LeanCloud 一直将服务的稳定性视为生命线,每次事故之后,都会严肃地总结并明确改进方案。我们也会把事故报告发布到博客上,确保用户们知晓事故原因和过程,以及后续我们要执行的改进措施。为让用户了解我们为此所做出的努力,我们想向大家通报一下在改进措施方面的进展。已经完成的改进措施有:为应对将来可能出现的上游服务商域名被攻击的情况,实现更灵活的域名动态切换,以便在必要时及时切换至其他域名,保证云服务对外服务的可用。完善应对 DDoS 攻击的策略和措施,把受攻击后恢复服务的时间缩短到分钟级。事故公告流程增加了短信通知渠道,确保开发者及时收到信息。(我们在最近的 DDoS 攻击的几十分钟内一共给所有用户发送了三次短信及时更新进展)。正在进行的措施有:增加新的监控措施,对前端网络入包量进行监控,防止网络转发量超过 VM 能力限制。调整前端 VM 配置,使用高包量机型,增大处理能力。改进前端服务器扩容方式,使用 docker 镜像来加快新节点部署上线的进度。API 服务对外增加多路备选域名,降低针对域名的攻击造成的影响。除了技术上的改进外,我们也对计费方式中的不合理之处进行了重新思考。过去我们的存储和即时通讯实时消息服务都是按照一个月的总使用量来计费的,这样造成了一些问题。比如如果一个应用在一个月里发生了 10 亿次 API 调用,我们并不区分这些调用是平均分布在整个月,还是集中在少数几天。而这两种情况对容量规划的要求是非常不同的,如果不做区分,就容易造成资源上的分配不及时,给运维工作造成风险和压力。另外由于存储和即时通讯实时消息是按月后付费,LeanEngine、LeanCache、短信是实时扣费,不同的计费周期和方式给很多用户造成了财务流程上的困扰。所以我们将把所有服务调整为一致的实时扣费的模式,并且存储和即时通讯实时消息服务将调整为按每天用户设定的容量上限收费,其中数据存储的计费依据将是并发请求数的上限,即时通讯实时消息服务的计费依据将是当日使用服务的用户数上限。这样用户可以自己调整预留的资源,确保满足需求。由于计费周期缩短到天,也能满足只在特定日期有超高流量的应用兼顾较低的预算和充足的资源。具体的方案和数字我们还在制定,会在第一时间与用户沟通。同时我们也会确保老用户有平滑的过渡体验。LeanCloud官方地址:

摘要4月22日即时通讯云 LeanCloud 发生了因存储集群故障而致服务瘫痪,从事故原因中可以想够用的出目前LeanCloud这类即时通讯云厂商所面临的各种挑战。前言4月22日即时通讯云 LeanCloud 发生了因存储集群故障而致服务瘫痪,从事故原因中可以想象的出目前LeanCloud这类即时通讯云厂商所面临的各种挑战:当用户量持续增大,所面临的各种因大并发、高服务需求问题,时常导致整体服务品质的下降,这也侧面反映出,要做出可靠的云即时通讯服务,在没有现成方案可用的情况下,各厂商要走的路显然还很长。以下是官方事故通报情况2016 年 4 月 22 日 13:04 开始,LeanCloud 中国节点的后端存储集群出现问题,导致该节点上所有应用都出现了存储 API 访问故障,将近半小时后得到恢复。故障的详细经过通报如下。故障时间13:09-13:28 所有应用的数据存储服务都出现访问异常(持续 19 分钟)13:28-13:40 大部分应用已经恢复,但还有 20% 的应用依然无法正常访问(持续 12 分钟)影响范围中国节点上所有应用的存储服务都受到影响,同时依赖于数据存储的实时通信、云引擎服务也可能出现内部错误。美国节点不受影响,所有服务均工作正常。事故经过13:04 我们监控系统陆续发出报警,后端存储集群访问超时慢慢增多,工程师介入调查,并向用户发出了短信和邮件通知。13:10 整个集群的存储 API Server 不再响应外部请求。调查后确认是后端存储系统在做大量耗时的关系数据写入操作,导致系统失去响应。于是我们马上重启集群,并分批开放流量。13:28 部分存储分片(shard)得到恢复,80% 的应用访问恢复正常;发送第二次故障进度通知。13:40 所有应用恢复正常;发送故障解决通知。后续改进措施这一次故障的根本原因在于 AVRelation 模型的底层实现存在缺陷,某些特殊条件下会导致后端存储系统因忙于处理而失去响应。我们已完成替代方案的开发,正在测试中,下周会发布更合理的解决方案。(4 月 27 日周三完成)改进并发限制的算法,以便在异常条件下更好地限制故障的影响范围。(4 月 25 日周一完成)排查所有危险/耗时操作,在上层进行写入控制,避免对后端存储系统造成太大影响。(4 月 25 日周一完成)LeanCloud官网访问以下地址即可:leancloud.cn

摘要2016年11月22日,即时通讯云服务商LeanCloud中国节点所有服务瘫痪约 50 分钟。以下消息来自LeanCloud官网:11 月 22 日中午 12:55,我们收到来自内部监控系统的报警,发现 LeanCloud 中国节点的各项服务出现异常,经过近 50 分钟的抢修,最终在 13:45 将全部服务恢复。在此时段受到影响的应用较多,这令我们感到十分愧疚,所以在此诚恳地向用户们道歉,同时我们也将免掉中国节点用户账户在 2016 年 11 月 22 日所产生的除短信外的全部费用。以下为本次故障的详细情况和改进措施,请大家监督和反馈。故障节点和影响范围本次故障仅发生在中国节点,存储服务和依托于存储的聊天、云引擎等各项服务都无法正常响应。故障时间线12:55:内部监控系统发出报警,大量存储 API 节点失去响应,随后也有开发者反馈 API 响应异常。13:11:第一次重启了所有 API 节点,系统有所好转但很快又出现了恶化。13:36:定位到故障原因,是后台服务对部分特殊请求存在漏洞,系统资源被逐渐耗尽,致使各模块都无法正常提供服务。立即实施热修复,阻断流量,再次重启所有 API 节点。13:45:所有 API 节点运行正常,开放流量,各服务恢复正常。后续措施加大 API 节点的资源配置,以期类似不可预知的事件发生时,可以延缓状态恶化的过程,争取更长的处理时间。(11 月 24 日前完成)本次故障原因比较复杂,内部定位花费了较长时间,因此需要进一步完善对网络延迟、缓存节点等内部各环节的监控与状态展示,缩短故障排查时间。(11 月 29 日前完成)详细排查所有资源消耗的潜在问题点,对自定义的结构化数据实现更严格的限制和检查。(12 月 8 日前完成)详情请见:

郑重声明:本文版权归新匍京a奥门-最全网站手机版app官方下载所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。