http://www.ox-holdings.com

此次故障影响到中国节点上,所有应用的数据存储服务都出现访问异常(持续 19 分钟)13

摘要即时通讯云服务商LeanCloud 2016年7月13日因由于突发硬件故障,导致雪崩致使即时通讯服务瘫痪48分钟之久!以下消息来自LeanCloud官方:7 月 13 日早上 9 点左右,我们内部在使用中国节点的应用控制台时遇到报错,于是很快便定位到某一集群由于突发硬件故障而引起存储服务中断,经过抢修问题得以解决。大约一小时后正当我们在继续对该集群进行加固处理时,突然遇到流量高峰,该集群的性能逐渐下降并再次发生了故障。此次故障影响到中国节点上 20% 的应用无法使用存储及其依赖服务,如实时通信、云引擎等。美国节点不受影响。故障时间及范围08:49

摘要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

摘要即时通讯云服务商LeanCloud 2016年8月5日因由于缓存集群超负载崩溃,导致即时通讯服务瘫痪30分钟之久!以下消息来自LeanCloud官方:8 月 5 日晚上 7 点 10 分开始,LeanCloud 中国节点上的某一缓存集群因为流量过大,CPU 资源被占满而停止了服务,从而导致数据存储及依赖它的服务(云引擎、推送、实时聊天)出现约半小时的中断,在此期间有部分应用可能会遇到请求无法完成的情况。详细报告如下。故障节点和影响范围只有中国节点出现了问题,受影响的服务与时间段列举如下,其他服务未受到影响。服务名区域受影响时段范围数据存储中国19:10 – 19:41全部不可用云引擎中国19:10 – 19:41全部不可用实时通信中国19:10 – 19:41部分不可用(消息 hook 功能不可用、离线推送延迟)消息推送中国19:10 – 20:02推送大面积延迟统计服务中国19:10 – 20:23全部不可用(数据收集接口关闭)故障时间线19:10:内部监控报警,确认 redis 异常(CPU 资源占满,失去响应)。19:13:redis 机器无法直接重启,开始尝试逐步关停其他服务(依次是推送、聊天推送、云引擎、统计),以降低请求压力。19:41:redis 集群恢复可用,同时数据存储、云引擎和实时通信三个服务开始恢复。20:02:消息推送服务开始恢复,redis 集群运行正常。20:23:成功为统计服务单独搭建 redis 集群,统计服务的数据收集接口开放,新老 redis 集群运行正常。至此所有服务全部恢复。后续措施将该 redis 集群从业务层面进行拆分,小集群化。将 redis 集群进行高可用架构升级,避免单点故障。对集群加强容灾演练,确保异常条件下服务稳定。对于本次故障,我们诚恳地向您道歉。我们将免掉您账户中全部应用在 8 月 5 日当天的所有费用,以表诚意。

摘要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 日前完成)详情请见:

摘要2016 月 2 月 19 下午 3 点左右,即时通讯云 LeanCloud 因技术故障致所有服务中断半小时以上。2016 月 2 月 19 下午 3 点左右,即时通讯云 LeanCloud 因技术故障致所有服务中断半小时以上。以下是LeanCloud官方关于此次故障的说明:故障时间15:17 至 15:50(持续约 33 分钟)影响范围除了单纯的静态网站托管服务未受影响之外,其他所有服务,包括结构化数据存储、文件存储、云引擎、聊天、短信、推送、统计等功能都暂时无法使用。故障处理时间线15:17:我们在部署新服务时无意触发了一项误操作,但并未意识到由此会导致上述服务停止。15:17:我们在同一时间接到系统监控报警,经检查发现 LeanCloud 网站无法登录,API 服务日志也已中断,同时有部分用户也向我们反馈,确认了服务已不可用。15:19:我们随即启动回滚操作,所有服务陆续开始重启。15:25:API 等服务逐步启动,但是流量还没对外开放。15:30:开放 API 流量, 数据存储服务以及依赖于它的云引擎服务开始逐步恢复。继而聊天、统计、推送服务也逐步恢复。15:50:所有服务恢复正常。后续改进措施贯彻执行故障通报流程:由于本次故障事发突然,影响面广,我们一直专注在恢复服务上,却疏忽了与用户及时沟通问题和进展这一已有流程。我们深知在故障期间这一流程对用户来说至关重要,所以我们今后会切实执行这一流程,明确故障通报的负责人和替补人、通报时机、通报内容、通报渠道(如邮件或短信)等。对部署服务进行权限和功能上的细分:限制其操作的影响范围,杜绝一条指令导致所有服务停止运转的情况。完善后台管理系统:确保管理系统的所有操作都增加了确认环节,确保操作者知道操作的后果,并手动进行确认。这次由于我们的工作失误而引发了大范围的服务中断,我们在此向大家深切地道歉。同时为了表达我们的歉意,我们会免掉所有应用在 2 月 19 日除短信服务之外产生的全部费用。我们将在后续几日进行退费操作,退费完成时,您将收到账户余额变动的邮件通知,请耐心等待。具体金额届时也可以通过控制台 > 交易历史 > 充值历史查询。

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