Tromos：虚拟存储系统的软件开发工具包

Tromos：虚拟存储系统的软件开发工具包福蒂奥斯·尼古拉引用此版本：Fotios Nikola. Tromos：虚拟存储系统的软件开发工具包。其他[cs.OH]。巴黎萨克雷大学（COmUE），2019年。英语NNT：2019SACLV033。电话：02443225HAL Id：tel-02443225https://theses.hal.science/tel-024432252020年1月17日提交HAL是一个多学科的开放获取档案馆，用于存放和传播科学研究文件，无论它们是否已这些文件可能来自法国或国外的教学和研究机构，或来自公共或私人研究中心。L’archive ouverte pluridisciplinaireTromos：一个软件开发工具包，虚拟存储系统巴黎萨克雷大学博士学位论文Ecole doctorale n19580 Sciences et technologies de通信（STIC）Spécialité de doctorat：InformatiqueThèse présentée et soutenue à Versailles，le 22/May/2019，parM.FOTIOS NIKOLAIDIS评审团组成：米克尔·克拉耶茨基兰斯大学校长，特别报告员William Jalby凡尔赛大学校长Soraya ZertalMCF/人类发展报告，凡尔赛大学共同主持人Philippe DenielCEA/DAM，Bruyere le chatelco-encadrant de thèse Maria Perez马德里大学讲师特别报告员Jacques JordaMCF/HDR，图卢兹Gael Thomas，波尔多大学讲师巴黎南部电信公司审查员1编号：2019SACLV0332标题：Tromos：un cadre pour la construction de systèmes de stockage distribuésMots clés：Blob storage，Stockage distribué，Stockage sur le nuage，Storage containers简 历 ： Parmi la techelé ， la portabil- ité ， ladistribution du charge de travail ， et autresraisons ， les applications vont bénéficier laplate-formdustorkagedesdonnéeswhipresent le code le plus efficace. 这 Chaqueplatformeraboutieauxaccom-plissementsdiversifiés and，par conséquent，elle requiertle rôle这些车的安装并不方便。她需要一个伟大的努力，高级编程能力，随之而来的是错误的风险。这些问题是在支持者平行储存多个données的应用中出现的。在这篇论文中，介绍了“储存容器 ” 这 一 术 语 ， 就 像 一 种 自 然 的 储 存 容 器 。Les“storagecontainers”sontdesapplicationinter-médiaires de gestion des données quiséprofit la logique在此基础上，我们引入了“仓储资源”这一术语，就像仓储发展过程中的逻辑一样 。 Il s'agit d'un logiciel intermediaire degestion des don- nées qui séprofit la logiqued'I/O de la logique métier et de calcul d'uneapplication. Autrement dit ， ils séparent leschangementsapportésaucodedesapplications par les utilisa-scien- tifiques deschangements apportés aux actions d'I/O par lesdécépereursoulesadministra-faint.Contrairementauxsystèmes“àusagegénéral”existants，dont« décement » pour le plus grand nombrepossible应用程序.一个概念有助于在开发阶段重新考虑I/O的决策，这是关于运输、管理、非合作仓储四人联合会、在donnes仓储中适用两个独立命令以及分发donnes的规则，包括仓储的合理性、需求、有效性和成本如果一个中间逻辑在应用上是“per-sonnalisé”，则意味着应用在“saveur”中的方法是“保存”。Pour ce faire，nous introduisonsunSDK，appeléTromos，pourlesdécepeurs，afin de Quarteritiser des systèmesdestockagedistribuéspersonnaliséssansprogrammation des systèmes.但这一点必须在定义的虚构中加以修正。SDK将生成剩余的进程。 Il est distribué avec une large gamme deplugins intégrés pour le traitement des I/O，letraitement des requêtes ， les algorithmes deselection ， les methodes de reconstruction dedonnées ， le traitement de cohérence ， et lavisualisation.Pour faire une analogie，“storagecontainers”découplent la gestion des donnéesde la platform de stockage physiques de lamêmemanièrequelescontainersDockerdécou- plent为了展示我们的能力，我们使用Tromos来制作个性化库存的原型，这是我们与Gluster的比较，这是一个与RedHat类似的美国通用系统。研究结果表明，Gluster自动化生产的产品在仓储线上的所有功能都是不可用的。3Tromos：虚拟存储系统的软件开发工具包关键词：Blob存储，分布式存储，云存储，存储容器摘要：现代应用程序在I/O配置文件和存储要求方面往往存在差异。 将科学或商业应用与通用系统将很可能产生次优性能。即使存在“特定用途”的系统，仍然需要具有多类工作负载的应用程序将工作量分配给正确的系统。然而，这种策略并不简单，因为不同的平台针对不同的目标，因此需要应用程序包含多个代码路径。实现这样的代码路径是不平凡的，需要大量的努力和编程技能，并且容易出错。当应用程序需要并行地利用多个数据存储时在本论文中，我们将“存储“换句话说，正是中间件将科学用户对应用程序代码的修改来自于开发人员或管理员对I/O操作的修改为了方便“存储容器”的开发和部署，通过它的镜头，应用程序架构师启动自定义存储解决方案所需的一切就是将目标环境建模到定义文件中，并让框架处理其余部分。Tromos附带了一个插件库，架构师可以选择这些插件来优化手头应用程序的容器可用的选项包括数据转换、数据放置策略、数据恢复方法、名称空间管理和按需一致性处理。作为一个概念验证，我们使用Tromos来原型定制 存 储 环 境 ， 我 们 将 其 与 Gluster 进 行 比 较 ;Gluster是RedHat拥有的结果表明，自动生成的环境仅通过删除未使用功能的不必要开销就优于更成熟的Gluster巴黎-萨克雷大学Espace Technologique/Immeuble DiscoveryRoute de一张照片，一千个感谢！本论文是献给我们的朋友迪米特里斯Ganosis4内容1一张照片，一千个感谢！41引言21.1块设备。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.2文件系统。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.1 VFS。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41.2.2 POSIX限制。. . . . . . . . . . . . . . . . . . . . . . .51.3基于对象的存储. . . . . . . . . . . . . . . . . . . . . . . .91.4数据存储。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111.4.1集群。. . . . . . . . . . . . . . . . . . . . . . . . . . . .121.4.2网格。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131.4.3云。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .131.5设计可扩展的数据存储。. . . . . . . . . . . . . . . . . . .141.5.1 CAP定理。. . . . . . . . . . . . . . . . . . . . . . . . .151.5.2基础模型。. . . . . . . . . . . . . . . . . . . . . . . . .152应用程序定制存储182.1应用程序定制的存储系统。. . . . . . . . . . . . . . . . .202.1.1可移植性。. . . . . . . . . . . . . . . . . . . . . . . . . . .212.1.2联合存储工具包。. . . . . . . . . . . . . . . . . .212.1.3二级管理。. . . . . . . . . . . . . . . . .232.2用于分布式存储系统。. . . . . . . . . . . . . . . .245内容62.2.1部件262.2.2虚拟存储基础架构273可编程器件293.1目标293.1.1便携性293.1.2差异化内容访问303.2设备驱动程序合成313.2.1建模语言313.3设备型号353.3.1通道353.3.2溪流373.3.3I/O阶段393.4摘要413.4.1相关工作414可编程I/O处理器434.1目标434.1.1过境处理4.1.2数据分布444.1.3双向流444.2驱动程序合成444.2.1处理内核464.2.2图表514.3驱动程序4544.3.1网络端口544.3.2联合网络发现554.4摘要564.4.1相关工作57内容75可编程协调器595.1目标595.1.1元数据目录595.1.2分布式同步605.2驱动程序合成605.2.1建模语言615.3驱动程序635.3.1更新交易645.3.2订购655.3.3锁的租赁5.3.4心跳655.3.5查看交易675.3.6更新记录屏蔽675.4摘要695.4.1相关工作706虚拟存储基础架构716.1综合报告716.1.1清单736.1.2综合空间736.1.3设备管理746.1.4设备选择策略746.2部署器766.2.1多功能拓扑结构766.3存储API776.3.1原子作家776.3.2读者816.4网关816.4.1相关工作82内容87评价847.1方法、工具和设置847.1.1建筑857.1.2787年7.2同步同步897.2.1分布式卷907.2.2卷927.2.3复制卷947.2.4分散体积967.3异步E987.3.1图形可视化1007.3.2突发缓冲区1037.3.3分布式卷1047.3.4剥离volule1067.3.5复制卷1077.3.6分散体积1087.4并行暂存器存储1087.4.1计算节点109上的Sockchpad7.4.2存储节点112上的Sockchpad8结论1168.1未来方向117参考书目118表的列表3.1由转换器和连接器实现的可堆叠API。Remove（）、Info（）和其他调用是为了缩写而发出的。.........................................................................................414.1处理器API的简化版本。为了方便读者，我们省略了一些参数................. 565.1协调器API。每个键将逻辑文件描述为意图日志和更新日志的元组。为了开始写入逻辑文件，客户端必须获取更新事务。本质上，每个更新事务都包含逻辑文件的新版本;作为版本控制系统上的版本。BeginView（）向后遍历更新日志，直到找到一个界标. 地标是一个关于如何答复的696.1更新信息（处理程序的更新记录，ev的增量处理程序中的每个写入请求809图目录1.1Linux I/O栈. . . . . . . . . . . . . . . . . . . . . . . . . .61.2Linux内核I/O堆栈的架构（源代码[85]）。. . . . . . . .1.3Amdahl定律. . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.4文件系统、块设备和对象存储之间的组织差异（来源[24]）101.5命名空间管理的三种方法：分层、平面（无）、特定于应用程序111.6对象类型121.7CAP定理162.1储存容器203.1设备驱动程序综合服务343.2设备运行时的概述363.3书写过程的说明404.1处理器驱动程序综合服务454.2处理器管理环境525.1协调员司机综合服务635.2协调器68的同步堆栈的操作6.1Tromos客户端中间件726.2Tromos架构：客户端引擎使用服务原语构建虚拟存储基础架构796.3原子多资源事务协议8010图目录116.4特罗莫斯终端83(a)Tromos控制台83(b)每一步都给出了关于期望什么参数的提示83(c)用户可以将定制的数据存储挂载为任何其他文件系统。..................837.1[以代码方式部署]以代码方式部署：开发人员对目标环境建模，Tromos自动部署877.2分布式卷上的同步顺序I/O917.3通过剥离卷937.4复制卷上的同步顺序I/O957.5分散卷上的同步顺序I/O977.6流式写入器仅用于附加：它们不支持随机I/O987.7配置1027.8写验证事务103的描述7.9网关中的瓶颈1037.10 分布式卷上的异步随机I/O1057.11 通过剥离卷106的异步随机I/O7.12 复制卷上的异步随机I/O1077.13 分散卷上的异步随机I/O1087.14 并行顺序工作负载1107.15 并行随机工作负载1117.16 并行顺序工作负载-分离的节点1137.17 并行随机工作负载-分离节点1147.18 特罗莫斯作家115图目录1‘第1介绍在本章中，我们将介绍目前广泛使用的各种持久存储接口的演变。在这个历史的递归中，我们将向读者介绍这些接口试图实现的目的，它们是如何根据当时的技术设计的，以及这些决定如何影响今天1.1块设备在计算的黎明，用于辅助存储的主要介质是磁带驱动器和硬盘驱动器。两者都是旋转设备，使用电磁头从涂有磁性材料的表面存储和检索数据。可替代地称为外部存储器、辅助存储器和辅助存储装置，辅助存储装置是比主存储装置便宜大约两个数量级的非易失性装置。设备控制器使用逻辑块寻址（LBA）的思想来抽象硬件几何结构的直接寻址（例如，盘片、柱面和磁道）分割成大小均匀的原始数据块。物理块大小-通常为512字节-对应于磁盘扇区，这是磁盘控制器在单个操作中可以读取或写入的最小数据单元。在I/O操作期间，物理介质不断旋转。但是，数据写入或读取到驱动器的速率并不确定;它取决于主机提供或请求数据的速率。如果主机速率高于设备速率，则设备将成为瓶颈，并可能开始拒绝数据。如果主机速率低于设备速率，设备将旋转，浪费能量并阻止其他客户端使用它。应对这种差异的电梯算法（也称为扫描）是一种磁盘调度算法，它以最小化磁盘臂和磁头运动的方式重新排序请求;从而使访问更请记住，对于固态硬盘（SSD）和较新的非易失性存储器（NVM）等非旋转磁盘，数据的位置不会影响性能。通常，块设备读取和/或写入完整的块;如果写入操作未填满一个完整的块，用户需要从文件的当前内容中读取剩余部分2第1章介绍3合并它们，计算更新的块，最后，将更新的块推回设备。UNIX内核使用逻辑块或物理块的群集在设备之间传输数据默认情况下，逻辑块大小设置为系统的页面大小-4k字节。页是虚拟内存操作系统中内存管理的最小数据单位，它表示虚拟内存的固定长度连续块，由单个条目描述逻辑块大小强加了时间-空间权衡。旋转磁盘中的大部分延迟是由于将读/写磁头正确定位在磁盘盘片上方所花费的较大的数据块将更多数据打包在连续空间中，并且比几个较小的传输产生更高的顺序吞吐量。更小的数据块允许更多的每秒I/O操作（IOPS）。对于术语“物理卷”，我们统称为物理驱动器，或称为分区的几乎不提供的部分。逻辑卷是可以跨越多个物理卷（例如，独立冗余阵列）。因此，逻辑卷可由“块层”组成 视频或音频设备）。存储区域网络存储区域网络（SAN）是一个专用的高速互联存储服务器网络，以共享设备池的形式存在。通常，SAN将存储服务器组合在主/从高可用性配置中，其中从服务器需要准备好接管主服务器。客户端通过向SAN发送SCSI命令来请求访问设备。光纤通道（FC）SAN是一种成本昂贵的本地网络，可提供低延迟和高吞吐量。iSCSI通过将SCSI命令封装到不需要FC连接的IP数据包中来解决成本和位置问题。SAN已成功运行Oracle、SAP、Microsoft Exchange和Microsoft SharePoint等任务关键型应用程序SAN通常不会扩展到64或128个节点以上。1.2文件系统逻辑块寻址无疑是几何寻址的一个进步。然而，块设备缺乏组织。他们只是接收命令来存储该块，或者加载另一个块，而不理解内容。这取决于程序员去问正确的块。文件系统的出现意味着将数据组织到文件和文件层次结构中。原则上，文件系统处理两个不同的方面：i）如何向最终用户呈现组织结构; 2）如何将逻辑文件映射到物理设备。它通过使用驻留在内存和磁盘上的结构来实现这一点。超级块结构向操作系统提供用于安装文件系统的高级信息，例如，总块数、空闲块数、根索引节点数。文件系统使用inode（索引节点的缩写）来维护关于文件、目录或符号链接的元数据信息。文件级和目录级系统调用直接映射到inode，例如，open（），read（），第1章介绍4write（）、flush（）用于文件，create（）、lookup（）、link（）、mkdir（）用于目录。表示文件的索引节点还维护一个指向写入块的表和固定大小页面的虚拟地址空间。页相当于块设备上的块的内存。Dentry跟踪文件系统中一个条目与其他条目的关系以及物理数据（如文件名）。一个文件系统有一个没有父项的根dentry，而所有其他dentry都有父项，有些有子项。dentry是由磁盘上的inode构造的内存结构。当用户创建或扩展文件时，内核以完整的逻辑块或称为片段的逻辑块段（例如，4KB块; 1 KB片段）。当文件需要额外的磁盘空间时，内核首先分配完整的块，然后为数据分配块的一个或多对于每个打开的文件，操作系统都维护一个用于保存文件状态的处理程序。它们充当将内存页转换为存储块的中间人。当一个进程修改一个页面（文件中的偏移量）时，处理程序将该页面标记为脏。脏意味着数据存在于页面缓存中，但尚未持久化在存储设备上这就给了操作系统时间将数据聚合到连续的块中，以减少块中未使用的漏洞导致的磁盘空间碎片。1.2.1VFS电气和电子工程师协会（IEEE）在20世纪80年代规定了可移植操作系统接口（POSIX）应用程序编程接口（API），用于跨System V和BSD Unix操作系统的可互操作应用程序。 虚拟文件系统交换机（VFS）是一个POSIX内核抽象，用于将几种类型的文件系统安装到同一个树结构中，同时为用户保留一种统一的方式来导航文件系统层次结构。它包含程序员熟悉的大多数系统调用，例如，open（）、close（）、read（）、write（）和lseek（）。VFS应用一般的文件系统操作，并将请求引导到正确的文件系统以进行进一步处理。文件系统可以将数据存储在本地设备、远程设备甚至用户空间中的“虚拟”进程中（图1.1）。通用块层VFS通过通用块层（GBL）抽象访问块设备。它忽略了具体的设备实现。GBL抽象物理设备（例如，HDD、SSD）或“虚拟”设备作为用户空间进程（例如，Linux中的网络块设备）。图1.2展示了GBL如何与VFS和块设备驱动程序连接。第1章介绍5在用户空间驻留在内核上的文件系统以管理员权限运行，如果它们遇到错误，可能会使整个机器崩溃。一些程序使用其自定义VFS实现（例如，GnomeVFS for Gnome desktop）以避免内核负担。特别是在高性能计算（HPC）环境中，通常将用户空间文件系统实现为预加载库。缺点是这样的文件系统不能被第三方进程访问;进程不能在GnomeVFS树中执行FUSE是一个内核协议，它将VFS与用户空间文件系统连接起来。这种分离使得编写具有大量外部依赖项的文件系统更加明智。通过网络集群文件系统是通过同时安装在多个服务器上来共享的文件系统。集群文件系统可以提供独立于位置的寻址和冗余等功能，这些功能可以提高可靠性或降低集群其他部分的复杂性。VFS层对集群节点上的客户端程序隐藏网络通信。客户端可以像访问任何其他本地文件系统一样访问该文件系统。共享磁盘是一种集群文件系统，允许多个客户端在NAS上获得磁盘级别。它采用隔离机制进行并发控制，允许节点发生故障而不会意外丢失数据，也不会影响其他节点的访问。这种类型的最 突 出 的 文 件 系 统 包 括 Oracle Cluster File System （ OCFS ） 、 IBM General Parallel FileSystem（GPFS）、Quantum的StorNext、 Symantec的Veritas和VMware/EMC Corporation的VMFS分布式文件系统不共享对同一存储的块级访问，而是使用文件级协议。网络文件系统（NFS）协议是Linux中事实上的分布式文件系统，它建立在开放网络计算远程过程调用（ONCRPC）系统之上。远程过程调用（RPC）是一种协议，一个程序可以使用它从位于网络上另一台计算机上的程序请求服务1.2.2POSIX限制像青铜时代的大多数设计一样，POSIX的设计倾向于精确性和正确性。它依赖于有状态的处理程序和强事件排序。不幸的是，POSIX的设计没有反映出当今精确性和正确性不再是一个大问题;没有人会在数据变得可访问之前等待Google搜索加载所有可能的结果接下来，我们将给出一个广泛的但并不详尽的事实列表，这些事实使得POSIX编程不符合当今第1章介绍6图1.1不推荐的APIPOSIX是为单个主机设计的，具有单个CPU核心，用于将数据存储到旋转设备。当时的并行进程不是物理的，而是“预定的”。操作系统通过偶尔将CPU执行从一个任务切换到另一个任务来实现伪并行。这需要有状态的任务（或处理程序），以便稍后恢复到它们被切换的点（例如，写入偏移）。大多数开发人员至少已经遇到过一次seek（）函数。其最初的目的是在数据传输之前定位磁头具有状态处理程序的系统此外，大多数现代数据是不需要太多随机I/O的“单元”（例如，图像、音乐、视频）。旋转设备的另一个特点是，它们一次只能执行一项任务;它们是单通道的。因此，所有的I/O请求都通过内核，内核决定如何以及何时将数据刷新到设备。考虑到当时的瓶颈是从内核到设备的I/O，执行系统调用和将数据用户空间复制到内核空间的开销可以忽略不计。 它们都不再有效。诸如基于NAND闪存的固态驱动器（SSD）和非易失性存储器（NVM）之类的现代存储设备展现出高吞吐量、随机I/O上的低延迟以及高度并行性。随着零拷贝和RDMA等内存访问技术的出现，瓶颈已经从设备转移因此，延长和模糊的I/O堆栈，具有单点拥塞第1章介绍7图1.2(e.g.、VFS）和不支持新技术的存储环境，并不适合当今POSIX将文件组织为单个名称空间中的目录。对于文件系统实现，这意味着i）即使对于不同目录下的文件也需要协调，因为它们属于同一名称空间。ii）它必须在名称空间之上实施访问控制的机制。访问控制并不是隔离的同义词，它通常会在HPC计算中强制执行不必要的开销。例如，MPI-IO标准不向最终用户公开文件层次结构或权限。因此，利用这些库的应用程序既不需要也不期望这些功能。对于许多应用来说，将组织保持在数据库上），并且只使用文件系统来转储数据内容。第1章介绍8强语义POSIX强制对共享文件的更改立即对所有进程可见;强制执行强一致性语义。例如，write（）将阻止应用程序执行，直到系统可以保证任何其他read（）调用将看到最新写入的数据。对于具有单个CPU核心的主机，由于所有进程都在同一个核心上运行，因此可以然而，这在今天的多核架构上是不可能的，因为进程可能在不同的内核上运行。同步需要通信，而光速限制了通信。因此，细粒度的锁是不切实际的。需要更粗的锁，这会增加锁定区域，从而阻碍潜在的并行化收益。根据Amdahl定律，并行任务执行的性能增益与顺序执行的部分成比例地受限。公式1.1给出了在资源得到改善的系统的固定工作负载下执行任务的延迟该指标给出了“可伸缩性因素”。如果每增加一个CPU，系统的处理能力就会降低5%，那么可伸缩性系数为0.9意味着只有90%的资源可用。加速比=（s+p）/s+p/N（1.1）本地I/O栈在应用程序和存储设备之间可以有多个中间处理层这样的层可以递归地刷新，直到请求到达设备，或者缓冲数据并立即确认I/O完成。驻留在缓冲区中的数据在后台（异步）任务中迁移到下一层，要么显式地向用户迁移（通过调用sync（）），要么由系统定期迁移只要请求遍历相同的I/O堆栈，系统就很容易直接从缓冲或缓存的数据中提供next read（）。不需要去设备。第一个相关的风险是，在崩溃的情况下，数据消失了POSIX通过首先修改元数据，然后修改数据来部分地即使有效负载被破坏，文件系统结构也将保持一致。如果文件缩小，未修改的数据将仍然存在于磁盘上，但不能从文件系统访问。如果文件增长，后续请求将看到正确的元数据，但数据已损坏。(Note 1：又一个POSIX过度设计API的注2：日志不是POSIX的组成部分，但使用它的调用）。第二个缺陷是现代存储需求远远超出了单个节点的能力相反，网络中的许多节点贡献其资源以形成分布式系统。因此，不同节点上的客户端遍历不同的I/O堆栈。解决方案是使用分布式锁定机制（DLM）应用粗粒度锁，这会强制执行高同步开销。