在当今数字化世界中,期望无间断访问数据不再是奢侈品,而是一种必需品,无论您是驱动关键应用程序、向全球受众提供多媒体内容,还是简单地备份个人文件,云存储的可靠性都会直接影响从生产力到信任。 对于大多数云提供商来说,可靠性是以工作时间百分比来量化的: 99.9%, 99.99%,甚至 然而,这些保质服务水平协议(SLAs)背后有一个严峻的现实:真 能够随时随地访问您的数据,而不会出现意外的延迟或中断,即使是最强大的集中云也容易受到他们试图减轻的事情的影响:失败。 five nines continuous performance 可靠性不是你希望的东西,它是你设计的东西。 从区域性中断到配置错误的网络路线,我们一再看到,无论集中基础设施有多强化,都无法逃避其自身的结构限制。 从区域性中断到配置错误的网络路线,我们一再看到,无论集中基础设施有多强化,都无法逃避其自身的结构限制。 本博客探讨了为什么Sia的去中心化架构能够独特地克服这些局限性。 在接下来的部分中,我们将将这种设计与传统的存储模型进行比较,分解现实世界的失败场景,并展示分散不仅更安全,而且更可靠。 性能通过弹性 因为在云存储的未来,可靠性不是你希望的东西,它是你设计的东西。 集中式云的脆弱基础 尽管传统的云存储平台承诺“五九”的可用性,但在面临环境极端、人为错误或内部错误的情况下,集中式基础设施的脆弱性已经一再证明了。 也许最具戏剧性的云脆弱性例子是数据中心火灾 - 事件可以立即关闭整个区域的云服务. 在2022年8月,谷歌的Council Bluffs数据中心的电气爆炸伤害了三名员工,扰乱了搜索和地图等核心服务。 一年后,在巴黎,谷歌云的欧洲西9区的多集群故障始于水侵入 - 它本身是冷却系统故障的结果,该故障淹没了电池房间并点燃了火灾。 这些事件回应了2021年斯特拉斯堡臭名昭著的OVHcloud火灾,该火灾完全摧毁了SBG2数据中心,并部分损坏了同一校园的其他人。 Many customers had no disaster recovery plans in place, and entire websites were lost without backups. 除了火灾之外,热浪已被证明是一个意想不到的但日益增长的威胁。2022年7月,伦敦创纪录高于40°C(104°F)的温度使谷歌和奥拉克尔的数据中心因冷却系统故障离线。 然而,并非所有的中断都来自于物理灾难,有些是等待发生的数字灾难。2024年2月,谷歌云遭受了另一个中断,当时一个区域性元数据存储故障将其西部地区关闭了近三个小时。 这些失败暴露了云服务依赖的危险巩固。当一个内容交付网络(CDN)如Fastly在2021年经历错误配置时,它引起了全球性干扰,在几秒钟内影响了Reddit,Spotify和主要新闻媒体。 连续性能通过设计 在集中式云提供商建立越来越大的堡垒以防失败的情况下,Sia完全通过拒绝堡垒模型来解决这个问题,而不是在单个区域或设施的韧性上投注,Sia在全球范围内分布您的数据,在数十个独立运营的节点中使用数学(而不是营销)来保证可靠性。 交付的解雇 解雇通常被视为一种安全措施 - 防止失败的一种方式,但在Sia中,这远不止于此。 默认情况下,Sia使用删除编码将每个文件分为30个加密片段,仅需要10个片段才能完全重建该文件,这意味着网络不仅可以容忍中断,而且可以容忍个别主机的变动性能,同时保持无缝访问。 解雇不是一个落后之路,它是持续表现的基础。 相比之下,传统的云计算依赖于几个区域的完整文件复制,如果一个区域失败,访问会减慢或停止,而额外的存储空间并不意味着更好的速度。 Sia的模型在实时适应,回收路径根据主机可用性和网络条件动态变化 - 没有故障,没有瓶颈,没有停机窗口。 虽然集中式云也可能在内部使用删除编码,但它们的整个基础设施仍然由一个提供商运营,一个错误的配置可能会影响整个网络。 相比之下,Sia的主机是独立操作的 - 通常由不同的个人或企业使用Sia就像默认情况下将数据分割到30个不同的云中一样。 无中断的抵抗力 在大多数云环境中,当某些东西发生故障时,性能也会受到影响,即使存在故障系统,故障往往会导致速度下降,访问障碍或基础设施难以恢复的全部停机时间。 Sia的架构运作不同。 当主机存储部分数据时,无论是由于故障、维护或不稳定性,您的文件仍然可以完全访问。没有加载旋转,没有同步延迟,没有警报。 与此同时,在背景下,租户软件开始通过将新片段上传到健康的主机来自动恢复完整的缺失,这种自我治愈过程不仅保护了未来的失败,而且确保了性能的持续运行。 Sia不仅从失败中恢复 - 它通过它工作。 在发生失败后,Sia不会对失败做出反应,而是将churn视为预期的行为 - 网络被构建以优雅的方式处理。 没有单一的失败点 集中式云平台容易发生分散式故障,因为它们依赖于集中控制,错误配置的路由器、错误的软件部署或单个设施中的电源问题可能会跨区域蔓延 - 拖累数百万用户依赖的服务。 Sia 的架构通过设计消除了这种风险. 没有主节点. 没有中央区域. 没有特权机构可以无意间将系统脱机。 如果一个主机失败,系统将继续运行;如果十个主机失败,它将继续运行;没有必要“失败”,因为没有单一的路径开始。 没有区域,没有主节点,没有瓶颈,只有不可阻挡的接入。 这种缺乏中心依赖不仅增强了错误容忍 - 它 您不是在等待一个区域重返网络,您不是被过载的网关或人为管理员恢复服务阻塞,您正在从最快的地方提取数据 - 不断地。 prevents performance blackouts 设计可靠性,而不仅仅是希望它 当我们谈到“云可靠性”时,我们经常被卖出一个承诺 - 一个由财务处罚,闪亮的运行时间百分比和品牌声誉支持的SLA,但正如我们所看到的那样,即使是最大的云提供商也无法逃脱集中化带来的脆弱性。 Sia采取了一个根本不同的方法,而不是假设基础设施会阻止并在不发生灾难时做好准备,Sia假设失败是不可避免的 - 并构建一个无论如何继续运作的系统。 没有特权服务器,没有区域依赖,没有供应商锁定,只有自我修复的去中心化基础设施,使您的数据可访问,因为没有一个单一的参与者有权使其无法访问。 连续性能 这不仅仅是技术优势,它改变了我们对数字弹性的看法,而不是建立更高的墙壁和更深的墙壁,Sia分散了它的防御系统,分散了信任,并通过这样做,重新定义了可靠的云存储在一个不再可以接受停机时间的世界中看起来是什么样子。 随着组织面临不断增加的中断,成本的增加和更严格的合规要求,分散化已经变得更加可行 - 它是优越的。 即使事情发生错误,现在是时候停止围绕信任设计,开始围绕确定性设计了。 只是工作 有了Sia,持续的性能不是目标,而是保证。 来源 数据中心知识 (2022年8月9日) 数据中心火灾 — 谷歌遭受“电力事故”,3人受伤。数据中心知识. https://www.datacenterknowledge.com/hyperscalers/data-center-fire-google-suffers-electric-incident-3-受伤 Claburn, T. (2023, 4月26日)。谷歌云在水泄漏,火灾中滑过欧洲。 https://www.theregister.com/2023/04/26/google_cloud_outage/ 2021年3月9日,斯德尔德里克(Sverdlik,Y. 2021年3月9日)。火灾摧毁了欧威斯特拉斯堡数据中心(SBG2).数据中心知识 https://www.datacenterknowledge.com/uptime/fire-has-destroyed-ovh-s-strasbourg-datacenter-sbg2 布隆伯格新闻. (2022年7月20日)。谷歌,奥拉克尔数据中心被伦敦热击中。 数据中心知识. https://www.datacenterknowledge.com/cooling/google-oracle-data-centers-knocked-offline-by-london-heat 2024 年 12 月 5 日(2024 年 12 月 5 日) 米尔沃德(Millward, W. 2024 年 12 月 5 日)。 2024 年最大的 10 个云中断。 CRN. https://www.crn.com/news/cloud/2024/the-10-biggest-cloud-outages-of-2024 巴雷特,B. (2021,6月8日)。 如何一个模糊的公司把互联网的大片。 WIRED. https://www.wired.com/story/fastly-cdn-internet-outages-2021/