云就像一个神奇的盒子——你问你需要什么，资源就会凭空出现。 虚拟机、数据库、网络——这一切都只属于你。 还有其他云租户，但在您的宇宙中您是唯一的统治者。 您确信您将始终收到所需的资源，您不考虑任何人，并且您独立确定网络是什么样的。 这种让云能够弹性分配资源并让租户之间完全隔离的魔力是如何发挥作用的呢？
AWS 云是一个超级复杂的系统，自 2006 年以来一直在不断演进。 这一发展的一部分发生了 瓦西里·潘秋欣 - 亚马逊网络服务架构师。 作为一名架构师，他不仅可以深入了解最终结果，还可以了解 AWS 克服的挑战。 对系统如何工作的了解越多，信任就越大。 因此，Vasily 将分享 AWS 云服务的秘密。 以下是物理 AWS 服务器的设计、弹性数据库可扩展性、自定义 Amazon 数据库以及提高虚拟机性能同时降低价格的方法。 了解 Amazon 的架构方法将帮助您更有效地使用 AWS 服务，并可能为您提供构建自己的解决方案的新想法。
关于演讲者：瓦西里·潘秋欣（Vasily Pantyukhin）（）最初在 .ru 公司担任 Unix 管理员，在大型 Sun Microsystem 硬件上工作了 6 年，并在 EMC 宣扬以数据为中心的世界 11 年。 它自然地演变成私有云，并于 2017 年转移到公共云。 现在，他提供技术建议来帮助在 AWS 云中生活和开发。
免责声明：以下所有内容均为 Vasily 的个人观点，可能与 Amazon Web Services 的立场不一致。 本文所依据的报告可在我们的 YouTube 频道上找到。
我为什么要谈论亚马逊设备？
我的第一辆车有手动变速箱。 感觉很棒，因为我可以驾驶汽车并完全控制它。 我还喜欢我至少大致了解了它的操作原理。 当然，我想象盒子的结构非常原始——就像自行车上的变速箱一样。
一切都很好，除了一件事——堵车。 看起来你坐着什么都不做，但你不断地换档、踩离合、油门、刹车——这真的让你很累。 当家里有了一辆自动挡汽车后，交通拥堵问题得到了部分解决。 开车时，我有时间思考一些事情并听有声读物。
我的生活中出现了另一个谜团，因为我完全不了解我的车是如何工作的。 现代汽车是一种复杂的设备。 该车同时适应数十种不同的参数：踩油门、刹车、驾驶风格、道路质量。 我不明白它是如何工作的了。
当我开始在亚马逊云上工作时，这对我来说也是一个谜。 只是这个谜团更大了一个数量级，因为车里只有一个司机，而在 AWS 中有数百万个司机。 所有用户同时转向、踩油门和制动。 令人惊奇的是他们可以去他们想去的地方 - 这对我来说是一个奇迹！ 该系统会自动适应、扩展和弹性调整每个用户，让他觉得自己在这个宇宙中是孤独的。
当我后来在亚马逊担任架构师时，这种魔力逐渐减弱。 我看到了我们面临的问题、我们如何解决这些问题以及我们如何开发服务。 随着对系统工作原理的了解不断加深，人们对服务的信心也随之增强。 所以我想分享一下 AWS 云的幕后故事。
我们应该谈什么
我选择了多元化的方式——我选择了4个值得谈论的有趣服务。
服务器优化。 具有物理体现的短暂云：物理数据中心，其中的物理服务器会嗡嗡作响、发热并闪烁灯光。
无服务器功能 (Lambda) 可能是云中最具可扩展性的服务。
数据库扩展。 我将告诉您我们如何构建自己的可扩展数据库。
网络扩展。 最后一部分我将打开我们网络的设备。 这是一件美妙的事情——每个云用户都相信自己在云中是孤独的，根本看不到其他租户。
笔记。 本文将讨论服务器优化和数据库扩展。 我们将在下一篇文章中考虑网络扩展。 无服务器功能在哪里？ 关于他们的单独记录被发表“” 它讨论了几种不同的扩展方法，并详细讨论了 Firecracker 解决方案 - 虚拟机和容器最佳品质的共生。
伺服器
云是短暂的。 但这种短暂性仍然有一个物理体现——服务器。 最初，他们的建筑是古典的。 标准 x86 芯片组、网卡、Linux、运行虚拟机的 Xen 虚拟机管理程序。
2012年，这个架构很好地应对了它的任务。 Xen 是一款出色的虚拟机管理程序，但它有一个主要缺点。 他已经受够了 设备模拟的高开销。 随着新的、更快的网卡或 SSD 驱动器的出现，这种开销变得过高。 如何处理这个问题呢？ 我们决定同时在两个方面开展工作 - 优化硬件和管理程序。 任务十分艰巨。
优化硬件和管理程序
一次性把所有事情都做完并把它做好是不行的。 最初也不清楚什么是“好”。
我们决定采取一种渐进的方法 - 我们改变架构的一个重要元素并将其投入生产。
我们踩每一把耙子，倾听投诉和建议。 然后我们改变另一个组件。 因此，我们会根据用户和支持的反馈，以小幅增量从根本上改变整个架构。
这场转型始于 2013 年最复杂的事物——网络。 在 S3 例如，在标准网卡上添加了特殊的网络加速卡。 它实际上是通过前面板上的短环回电缆连接的。 它不漂亮，但在云中不可见。 但与硬件的直接交互从根本上改善了抖动和网络吞吐量。
接下来我们决定改进对块数据存储 EBS（弹性块存储）的访问。 它是网络和存储的结合。 困难在于，虽然市场上存在网络加速卡，但无法选择简单地购买存储加速器硬件。 所以我们转向一家初创公司 安纳普尔纳实验室，他为我们开发了特殊的 ASIC 芯片。 它们允许将远程 EBS 卷安装为 NVMe 设备。
在实例中 C4 我们解决了两个问题。 首先，我们为未来有前途但当时是新技术的 NVMe 技术奠定了基础。 其次，我们通过将 EBS 请求的处理转移到新卡上，显着减轻了中央处理器的负担。 结果很好，所以现在安纳布尔纳实验室成为亚马逊的一部分。
到 2017 年 XNUMX 月，我们意识到是时候改变虚拟机管理程序本身了。
新的虚拟机管理程序是基于修改后的 KVM 内核模块开发的。
它可以从根本上减少设备仿真的开销并直接与新的 ASIC 配合使用。 实例 S5 是第一批在后台运行新虚拟机管理程序的虚拟机。 我们给他起了个名字 硝基.
时间轴上实例的演变。
自 2017 年 XNUMX 月以来出现的所有新型虚拟机都在该虚拟机管理程序上运行。 裸机实例没有虚拟机管理程序，但它们也被称为 Nitro，因为它们使用专门的 Nitro 卡。
在接下来的两年里，Nitro 实例的类型数量超过了几十种：A1、C5、M5、T3 等。
实例类型。
现代硝基机器的工作原理
它们具有三个主要组件：Nitro 管理程序（如上所述）、安全芯片和 Nitro 卡。
安全芯片 直接集成到主板中。 它控制许多重要的功能，例如控制主机操作系统的加载。
硝基卡 - 它们有四种类型。 它们均由 Annapurna Labs 开发，基于通用 ASIC。 他们的一些固件也是通用的。
四种类型的硝基卡。
其中一张卡的设计目的是与 网络VPC。 这就是虚拟机中可见的网卡 ENA - 弹性网络适配器。 它还在通过物理网络传输流量时封装流量（我们将在本文的第二部分讨论这一点），控制安全组防火墙，并负责路由和其他网络事务。
选择与块存储配合使用的卡 EBS 以及服务器内置的磁盘。 它们在来宾虚拟机中显示为 NVMe 适配器。 他们还负责数据加密和磁盘监控。
Nitro 卡、管理程序和安全芯片的系统集成到 SDN 网络中或 软件定义网络。 负责管理该网络（控制平面） 控制卡.
当然，我们会继续开发新的 ASIC。 例如，他们在 2018 年底发布了 Inferentia 芯片，它可以让您更有效地处理机器学习任务。
Inferentia 机器学习处理器芯片。
可扩展的数据库
传统的数据库具有分层结构。 为了大大简化，区分了以下级别。
- SQL — 客户端和请求调度员正在处理它。
- 规定 交易 - 这里一切都很清楚，ACID 等等。
- 缓存，由缓冲池提供。
- 记录 — 提供重做日志的工作。 在 MySQL 中，它们称为 Bin Logs，在 PosgreSQL 中称为 Write Ahead Logs (WAL)。
- 存储 – 直接录制到磁盘。
分层数据库结构。
扩展数据库有多种方法：分片、无共享架构、共享磁盘。
然而，所有这些方法都维护相同的整体数据库结构。 这极大地限制了扩展。 为了解决这个问题，我们开发了自己的数据库 - 亚马逊极光。 它与 MySQL 和 PostgreSQL 兼容。
亚马逊极光
主要架构思想是将存储和日志级别与主数据库分离。
展望未来，我会说我们还使缓存级别变得独立。 该架构不再是一个整体，我们在扩展各个块方面获得了额外的自由度。
日志记录和存储级别与数据库是分开的。
传统的DBMS以块的形式将数据写入存储系统。 在 Amazon Aurora，我们创建了会说话的智能存储 重做日志。 在内部，存储将日志转换为数据块，监控其完整性并自动备份。
这种方法允许您实现一些有趣的事情，例如 克隆。 由于它不需要创建所有数据的完整副本，因此从根本上来说它的工作速度更快、更经济。
存储层实现为分布式系统。 它由大量的物理服务器组成。 每个重做日志同时处理和保存 六节。 这确保了数据保护和负载平衡。
可以使用适当的副本来实现读取扩展。 分布式存储消除了我们写入数据的主数据库实例与其余副本之间的同步需求。 保证所有副本都可以使用最新数据。
唯一的问题是在只读副本上缓存旧数据。 但这个问题正在解决 传输所有重做日志 通过内部网络复制。 如果日志在缓存中，则会被标记为不正确并被覆盖。 如果它不在缓存中，则将其简单地丢弃。
我们整理了存储。
如何扩展 DBMS 层
在这里，水平缩放要困难得多。 那么让我们沿着老路走吧 经典的垂直缩放.
假设我们有一个通过主节点与 DBMS 通信的应用程序。
当垂直扩展时，我们分配一个具有更多处理器和内存的新节点。
接下来，我们将应用程序从旧的主节点切换到新的主节点。 问题就出现了。
- 这将需要大量的应用程序停机时间。
- 新的主节点将具有冷缓存。 只有在缓存预热后，数据库性能才会达到最大。
如何改善这种状况？ 在应用程序和主节点之间设置代理。
这会给我们带来什么？ 现在所有应用程序都不需要手动重定向到新节点。 切换可以在代理下完成，并且速度更快。
看来问题已经解决了。 但不，我们仍然需要预热缓存。 此外，还出现了一个新问题——现在代理是一个潜在的故障点。
使用 Amazon Aurora 无服务器的最终解决方案
我们是如何解决这些问题的？
留下代理。 这不是一个单独的实例，而是一个完整的分布式代理队列，应用程序通过它们连接到数据库。 如果发生故障，任何节点几乎可以立即更换。
添加了各种大小的暖节点池。 因此，如果需要分配一个更大或更小的新节点，它立即可用。 无需等待它加载。
整个缩放过程由特殊的监控系统控制。 监控不断监控当前主节点的状态。 例如，如果它检测到处理器负载已达到临界值，它会通知热实例池需要分配新节点。
分布式代理、热实例和监控。
具有所需功率的节点可用。 缓冲池被复制到其中，系统开始等待安全时刻进行切换。
通常，切换的时刻来得很快。 然后代理与旧主节点之间的通信暂停，所有会话都切换到新节点。
继续使用数据库。
从图中可以看出，暂停时间确实很短。 蓝色图显示负载，红色步骤显示缩放力矩。 蓝色图表中的短期下降正是这种短暂的延迟。
顺便说一句，Amazon Aurora 可以让您完全省钱，并在不使用时（例如周末）关闭数据库。 停止负载后，DB逐渐降低功率并关闭一段时间。 当负载恢复时，又会平稳上升。
在有关亚马逊设备的故事的下一部分中，我们将讨论网络扩展。 订阅 请继续关注，这样您就不会错过这篇文章。
上 瓦西里·潘秋欣将作报告“” 亚马逊开发者使用什么分布式系统的设计模式，服务失败的原因是什么，什么是基于Cell的架构，Constant Work，Shuffle Sharding——这会很有趣。 距离大会召开还有不到一个月的时间—— 。 24月XNUMX日最终涨价。
来源： habr.com