http://www.ox-holdings.com

就需要扩展.,数据存储服务以及依赖于它的云引擎服务开始逐步恢复

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

二、集群技术

    ( 一)、集群技术的问题。

          1、集群中各个服务器之间的连接和应用。

          2、解决各个服务器之间性能的差异,合理使用服务器性能。

          3、现在浏览器都是多并发,一个客户端访问的一个页面有可能是多个服务器提供的页面,这样会更快。

摘要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 日除短信服务之外产生的全部费用。我们将在后续几日进行退费操作,退费完成时,您将收到账户余额变动的邮件通知,请耐心等待。具体金额届时也可以通过控制台 > 交易历史 > 充值历史查询。

UFile存储路由算法设计

UFile存储集群采用无中心设计,数据存储采用固定的路由算法进行存储,因为存储集群的规模是固定的,因此路由表也是固定,这就保证了存储系统的简单性及稳定性。下面详细介绍UFile数据存储层的路由算法设计。

在存储集群上线时,每个集群的OsdMaster将该集群的磁盘信息进行组织,生成一个存储路由表,该路由表的每个项目对应3块分布在不同机架及存储机器上的磁盘,对象数据将按照该路由表指定的位置进行存储。

每个存储在UFile上的对象数据将被切分成若干个4MB的数据块,称为分片。UFile为每个对象分配一个单集群内部唯一的对象ID,通过对象ID和分片编号拼接获得分片ID,通过字符串哈希算法获得哈希值,并在路由表中找到该分片存储的3块磁盘位置,由UFile接入模块将该分片数据提交到3块磁盘上。

当单块磁盘出现异常时,OsdMaster会发现该情况并将该磁盘标记为异常状态,接入层写入该数据时,将只写入两份数据,磁盘修复后,将从这两份数据中拷贝一份数据到已修复磁盘,恢复数据的多份高可靠存储。当出现一个哈希表项中有2块磁盘不可使用的情况下,为保证数据安全性,该存储集群将不允许写入操作,写入操作将被切换到其他集群提供服务,从而保证UFile读写的高可用性。

高性能计算集群

  高性能计算(High Perfermance Computing)集群,简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。

  类型:  

        (一)向量机 :基本不会用到

            (二)并行处理集群:如:hadoop

图片 1

所用机制:                    

     1、 分布式文件系统。

            2、 将大任务切割成小任务,分别进行处理机制。                  

引言

Alphago打破围棋神话、无人驾驶、机器人送餐,人工智能已备受全球瞩目,现在资本的热潮也正转向AI市场,智能化大潮已势不可挡。当下人工智能和云业务紧密关联,未来将变得更加智能,但在这个智能化的背后,是对海量数据存储的刚性需求,据悉,单是一辆无人驾驶汽车每秒产生的数据容量就在1G左右,相当于每秒发送20万封纯文本电子邮件,或上传100张高清数码照片。没有大容量、超稳定的存储系统,这一切都是无稽之谈。

无存储,不智能,那么云存储技术是如何实现的?今天将由UCloud存储研发部经理李希源给我们带来云存储-—对象存储(UFile)技术深度解析。

高可用集群

       “高可用性”(High Availability)通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。

       可用性:在线时间/(在线时间+故障处理时间)

 机制:     

   1、检查心跳机制

            利用hearbeat中心跳数来确定服务器是否还在,通过发送并收到回应来确定服务器是否挂掉。发送是每分钟都会发送,按响应来确定服务器是否挂掉。

      2、数据崩溃

                使用隔离:节点级别

                              资源级别

           图片 2

      3、高可用采用奇数个节点

         采用奇数个节点的好处在于可以利用多个节点来控制单个节点或利用单个节点把自己隔离出这个集群。利用3个节点更容易判别那个节点出现问题。

    图片 3        

对象存储 UFile

对象存储(UFile)是为互联网应用提供非结构化文件存储的服务;相对于传统硬盘存储,UFile具有存储无上限、支持高并发访问、成本更低等优势;解决业务架构的文件存储问题,有效降低海量文件的存储成本,支持热点数据的高并发访问,提升终端用户访问体验。

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