飞行车，陈阿福

我在Mail.ru Cloud Solutons担任建筑师和开发人员，包括我的云。 众所周知，分布式云基础架构需要高效的块存储，PaaS服务和使用它们构建的解决方案的运行依赖于此。

最初，在部署此类基础架构时，我们仅使用Ceph，但逐渐发展了块存储。 我们希望我们的数据库 ，文件存储和各种服务以最高性能运行，因此我们添加了本地化存储并设置了高级Ceph监视。

我会告诉您的情况如何-也许这个故事，我们遇到的问题以及我们的解决方案对于也使用Ceph的人很有用。 顺便说一下， 这是此报告的视频版本。

从DevOps流程到您自己的云

DevOps实践旨在尽快推出产品：

• 过程自动化-整个生命周期：组装，测试，交付测试和生产。 从小步骤开始，逐步使流程自动化。
  
• 当基础结构配置过程类似于软件编程过程时，基础结构即代码就是模型。 首先，他们测试产品，产品对基础架构有特定要求，并且基础架构需要进行测试。 在这个阶段，希望她出现，我想“调整”基础结构-首先在测试环境中，然后在杂货店中。 在第一阶段，可以手动完成此操作，但随后他们将转向自动化-“基础架构即代码”模型。
  
• 虚拟化和容器-当您明确需要将流程置于工业轨道上，以最少的人工干预更快地推出新功能时，就会出现在公司中。
  

所有虚拟环境的体系结构都是相似的：具有容器的访客计算机，应用程序，公共和专用网络，存储。

逐渐地，越来越多的服务部署在DevOps流程及其周围建立的虚拟基础架构中，虚拟环境不仅成为一种测试（用于开发和测试），而且变得富有成效。

通常，在初始阶段，它们会被最简单的基本自动化工具所绕过。 但是随着新工具的吸引，迟早需要部署一个成熟的云平台，以便使用Terraform等最先进的工具。

在此阶段，由“管理程序，网络和存储”构成的虚拟基础架构将变成功能完善的云基础架构，其中包含用于流程编排的已开发工具和组件。 然后出现了他们自己的云，其中进行了对现有服务的测试和自动交付更新以及新服务的部署的过程。

通往您自己的云的第二种方法是无需依赖外部资源和外部服务提供商，即为您自己的服务提供某种技术独立性。

第一个云看起来几乎像一个虚拟基础架构-一个管理程序（一个或多个），带有容器的虚拟机，共享存储：如果您不在专有解决方案上构建云，则通常是Ceph或DRBD。

私有云的弹性和性能

云正在发展，业务越来越依赖于云，公司开始要求更高的可靠性。

在这里，将分布式性添加到私有云中，出现了分布式云基础结构：设备所在的其他点。 云管理着两个，三个或更多为提供容错解决方案而构建的安装。

同时，所有站点都需要数据，这是一个问题：在一个站点内，数据传输没有大的延迟，但是在站点之间，数据的传输速度较慢。

安装站点和公用存储。 红色矩形是网络级别的瓶颈。

从管理网络或公共网络的角度来看，基础结构的外部部分并不那么忙，但是在内部网络上，传输的数据量要大得多。 在分布式系统中，问题开始了，服务时间较长。 如果客户端访问一组存储节点，则必须立即将数据复制到第二组存储节点，以使更改不会丢失。

对于某些流程，数据复制延迟是可以接受的，但是在诸如事务处理之类的情况下，事务不会丢失。 如果使用异步复制，则在存储系统（数据存储系统）的“尾部”之一发生故障时，会出现时滞，这可能导致部分数据丢失。 如果使用同步复制，则服务时间会增加。

同样自然的是，当存储的处理时间（延迟）增加时，数据库开始变慢，并且必须消除负面影响。

在我们的云中，我们寻求平衡的解决方案来维持可靠性和性能。 最简单的技术是对数据进行本地化-然后我们添加了其他本地化的Ceph集群。

绿色表示其他本地化的Ceph群集。

这种复杂的体系结构的优势在于，那些需要快速数据输入/输出的用户可以使用本地化存储。 在两个站点内，对于完全可用性至关重要的数据位于分布式群集中。 它的工作速度较慢-但是其中的数据已复制到两个站点。 如果其性能还不够，则可以使用本地化的Ceph集群。

当根据需求将负载部署在不同类型的存储（不同类型的磁盘）上时，大多数公共云和私有云最终会达到大致相同的工作模式。

Ceph诊断：如何建立监控

当我们部署并启动基础架构时，是时候确保其功能正常，最大程度地减少故障时间和故障次数。 因此，基础设施开发的下一步是诊断和监视的构建。

始终考虑监视任务-我们在虚拟云环境中拥有大量应用程序：应用程序，来宾操作系统，块设备，虚拟机管理程序上该块设备的驱动程序，存储网络以及实际的存储系统（存储系统）。 监控尚未涵盖所有这些内容。

监视未涵盖的元素。

监控分几个阶段实施，我们从磁盘开始。 我们获得读/写操作的数量，在某种程度上，还有服务时间（每秒兆字节），队列深度，其他特征，我们还收集了有关磁盘状态的SMART。

第一阶段：我们介绍了监视磁盘。

磁盘监视不足以全面了解系统中正在发生的情况。 因此，我们继续监视基础结构的关键元素-存储系统的网络。 实际上，它们有两个-内部集群和客户端，它们将存储集群与虚拟机管理程序连接起来。 在这里，我们得到数据包的传输速率（每秒兆字节，每秒包），网络队列，缓冲区的大小以及可能的数据路径。

第二阶段：网络监控。

他们通常会在此停下来，但是这无法完成，因为大多数基础结构尚未通过监视关闭。

公有云和私有云中使用的所有分布式存储都是软件定义的SDS存储。 它们可以在特定供应商的解决方案，开源解决方案上实施，您可以使用一堆熟悉的技术自己做些事情。 但是它始终是SDS，并且必须监视这些软件部件的工作。

第三步：监视存储守护进程。

大多数Ceph操作员都使用从Ceph监视和控制守护程序（监视和管理器，也称为mgr）收集的数据。 最初，我们以相同的方式进行操作，但是很快意识到该信息还不够-有关挂起请求的警告出现得较晚：请求挂起30秒，然后我们才看到它。 只要涉及监视，在监视发出警报的同时，至少要经过三分钟。 在最佳情况下，这意味着部分存储和应用程序将空闲三分钟。

自然，我们决定扩展监视范围，并深入到Ceph的主要元素-OSD守护程序。 通过监视对象存储守护程序，我们可以获得OSD看到的大概操作时间，以及有关挂起请求的统计信息-谁，何时，在哪个PG中运行了多长时间。

为什么仅Ceph还不够，该怎么办

出于多种原因，仅使用Ceph是不够的。 例如，我们有一个带有数据库配置文件的客户端。 他将所有数据库都部署在全闪存集群中，在那里发布的操作延迟很适合他，但是，有人抱怨停机。

监视系统不允许您查看虚拟环境客户端内部发生的情况。 结果，为了确定问题，我们使用了高级分析，该分析是使用他的虚拟机中的blktrace实用程序进行的。

扩展分析的结果。

分析结果包含标记为W和WS的操作。 W标志是一条记录，WS标志是同步记录，等待设备完成操作。 当我们使用数据库时，几乎所有的SQL数据库都有一个瓶颈-WAL（预写日志）。

数据库始终首先将数据写入日志，使用刷新缓冲区从磁盘接收确认，然后将数据写入数据库本身。 如果她尚未收到缓冲区重置的确认，则认为电源重置可以擦除客户端确认的交易。 这对于数据库是不可接受的，因此它显示“ write SYNC / FLUSH”，然后写入数据。 当日志已满时，将进行切换，并且强行刷新进入页面缓存的所有内容。 补充：图片本身没有重置-即使用预冲洗标志进行的操作。 它们看起来像FWS-预冲洗+写+同步或FWSF-预冲洗+写+同步+ FUA

当一个客户端有许多小事务时，几乎所有的I / O都变成一个顺序链：写-刷新-写-刷新。 由于您无法对数据库执行任何操作，因此我们开始使用存储系统。 目前，我们了解到Ceph的功能还不够。

在我们这个阶段，最好的解决方案是添加小型快速的本地存储库，这些存储库不是使用Ceph工具实现的（我们基本上用尽了其功能）。 而且，我们将云存储变成的不仅仅是Ceph。 在我们的案例中，我们添加了许多本地案例（就数据中心而言，本地化，而不是虚拟机管理程序）。

其他本地存储库目标A和B。

此类本地存储的服务时间约为每个流0.3毫秒。 如果它位于另一个数据中心，则工作速度会更慢-性能约为0.7毫秒。 与Ceph相比，这是一个显着的增长，后者产生了1.2 ms的时间，并分布在数据中心-2 ms。 我们拥有十几家这样的小型工厂的性能，每个模块约10万，每条记录IOPS 10万。

在基础架构发生这种变化之后，我们的云为所有客户压缩了低于一百万的IOPS进行写入，或者总共减少了两到三百万的IOPS：



重要的是要注意，这种类型的存储不是主要的扩展方法，我们将主要赌注放在Ceph上，快速存储的存在仅对需要磁盘响应时间的服务很重要。

新的迭代：代码和基础架构的改进

我们所有的故事都是共享资源。 这样的基础架构要求我们实施服务级别策略 ：我们必须提供一定级别的服务，并且不允许一个客户端因意外或有意通过禁用存储来干扰另一个客户端。

为此，我们必须进行最终确定和非平凡的部署-迭代交付到生产环境。

当所有过程（组装，测试，代码推出，重新启动服务）（如有必要）时，只需单击一下按钮，便一切正常，此推出与通常的DevOps做法不同。 如果将DevOps实践推广到基础架构，它将持续到出现第一个错误为止。

这就是为什么“全自动”没有特别扎根于基础架构团队的原因。 当然，有一种测试和交付自动化的方法-但是它总是受控的，交付是由云团队的SRE工程师发起的。

我们在以下服务中推出了更改：Cinder后端，Cinder前端（Cinder客户端）和Nova服务。 更改应用了几次迭代-一次迭代一次。 第三次迭代后，相应的更改已应用于客户端的客户机：有人迁移了，有人亲自重启了VM（硬重启）或计划了迁移以服务于虚拟机监控程序。

出现的下一个问题是写入速度的跳跃 。 当我们使用网络附加存储时，默认的管理程序会认为网络速度很慢，因此会缓存所有数据。 他快速写入（高达几十兆字节），然后开始刷新缓存。 由于这样的跳跃，有很多不愉快的时刻。

我们发现，如果打开缓存，SSD的性能下降15％，如果关闭缓存，HDD的性能下降35％。 当为每种类型的磁盘显式分配了缓存时，又进行了另一项开发，推出了托管缓存管理。 这使我们能够在没有缓存的情况下驱动SSD，在没有缓存的情况下驱动HDD-因此，我们不再损失性能。

向产品交付开发的做法是相似的-迭代。 我们推出了代码，重新启动了守护程序，然后根据需要重新启动或迁移来宾虚拟机，应对其进行更改。 客户端VM从HDD迁移，其缓存打开-一切正常，或者相反，客户端从SSD迁移，其缓存关闭-一切正常。

第三个问题是从GOLD映像部署到HDD的虚拟机的错误操作 。

这样的客户端有很多，这种情况的特殊之处在于VM的工作是自己调整的：保证在部署过程中会发生问题，但是在客户端获得技术支持时才得以解决。 最初，我们要求客户等待半个小时，直到VM稳定下来，然后我们才开始着手提高服务质量。

在研究过程中，我们意识到监控基础架构的功能仍然不够。

监控关闭了蓝色部分，问题出在基础架构的顶部，而监控并未解决。

我们开始处理监视未涵盖的基础架构部分中正在发生的事情。 为此，我们使用了高级Ceph诊断程序（或者更确切地说，是Ceph客户端的其中一种-librbd）。 使用自动化工具，我们对Ceph客户端配置进行了更改，以通过Unix域套接字访问内部数据结构，并开始从虚拟机管理程序上的Ceph客户端获取统计信息。

我们看到了什么？ 我们没有看到Ceph群集/ OSD /群集上的统计信息，但是看到了其磁盘位于Ceph中的客户端虚拟机的每个磁盘上的统计信息，即与设备关联的统计信息。

高级监控统计结果。

正是经过扩展的统计数据清楚地表明，该问题仅发生在从其他磁盘克隆的磁盘上。

接下来，我们查看了有关操作的统计信息，尤其是读写操作。 事实证明，高级别图像上的负载相对较小，而克隆所来自的初始图像上的负载虽然很大，但却不平衡：大量读取而根本没有记录。

问题是本地化的，现在需要解决方案-代码还是基础架构？

Ceph代码无法完成任何工作；这是“困难的”。 此外，客户数据的安全性取决于此。 但是有一个问题，必须解决，我们更改了存储库的体系结构。 HDD群集变成了混合群集-在HDD中添加了一定数量的SSD，然后更改了OSD守护程序的优先级，以便SSD始终处于优先级，并成为放置组（PG）中的主要OSD。

现在，当客户端从克隆的磁盘部署虚拟机时，其读取操作将进入SSD。 结果，从磁盘的恢复变得很快，并且只有原始映像以外的客户端数据才被写入HDD。 几乎免费（相对于基础架构的初始成本），我们的生产力提高了三倍。

为什么基础设施监控很重要

1. 从虚拟机开始到磁盘结束，整个堆栈中必须包含最大数量的监视基础结构。 确实，当使用私有或公共云的客户端访问其基础架构并提供必要的信息时，问题将改变或转移到另一个地方。
   
2. 监视整个虚拟机管理程序，虚拟机或容器“完全”几乎没有结果。 我们试图从网络流量中了解Ceph所发生的情况-它是无用的，数据高速传输（每秒500兆字节），选择必要的数据极其困难。 存储此类统计信息将花费大量磁盘，并且需要大量时间进行分析。
   
3. , - . : , , — , .
   
4. — . , . — , . , . — , , .
   
5. Cloud MCS Cloud Solutions是一个基础架构，其演进决策主要基于监控所收集的数据。我们改善监控并使用其数据来提高对客户的服务水平。