CN108292235B - 使用选择性资源迁移的网络附连存储器 - Google Patents
使用选择性资源迁移的网络附连存储器 Download PDFInfo
- Publication number
- CN108292235B CN108292235B CN201680069485.7A CN201680069485A CN108292235B CN 108292235 B CN108292235 B CN 108292235B CN 201680069485 A CN201680069485 A CN 201680069485A CN 108292235 B CN108292235 B CN 108292235B
- Authority
- CN
- China
- Prior art keywords
- memory
- node
- page
- copy
- network attached
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/2885—Hierarchically arranged intermediate devices, e.g. for hierarchical caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45583—Memory management, e.g. access or allocation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
公开了在存在网络附连存储器的情况下维护高速缓存一致性。一种计算机系统包括多个物理节点。操作系统跨越所述多个物理节点共同地运行。所述物理节点被配置成与网络附连存储器进行通信。至少部分地基于要对包括在所述多个物理节点中的第一物理节点上的页面执行的操作,所述网络附连存储器被配置成接收消息。所述网络附连存储器被配置成至少部分地基于所接收到的消息执行动作。
Description
其他申请的交叉引用
本申请要求2015年10月1日提交的标题为NETWORK ATTACHED MEMORY USINGSELECTIVE RESOURCE MIGRATION的美国临时专利申请No. 62/236,076的优先权,其通过引用并入在本文中以用于所有目的。
背景技术
使用闪速存储器的一个典型方式是为了模拟服务器中的磁盘。以附加方式使用闪速存储器将是有利的。遗憾的是,用于服务器的现有系统软件解决方案除了作为磁盘储存器以外未提供用于使用闪速存储器的机制。
附图说明
在以下详细描述和附图中公开了本发明的各种实施例。
图1图示了计算机系统的实施例。
图2将计算机系统的物理结构图示为层次结构。
图3A描绘了其中多个虚拟机(具有相应的多个客户操作系统)在单个物理机器上运行的虚拟化计算环境。
图3B描绘了其中多个物理机器共同地运行单个虚拟操作系统的虚拟化计算环境。
图4A描绘了软件栈的示例。
图4B描绘了软件栈的示例。
图5描绘了示例系统上的硬件的操作系统的视图的示例。
图6A描绘了单个节点上的硬件的超线程的视图的示例。
图6B描绘了示例系统上的硬件的超内核的视图的示例。
图7描绘了企业超级计算机系统的示例上的硬件的操作系统的视图的示例。
图8图示了用于选择性地迁移资源的过程的实施例。
图9图示了用于执行分层动态调度的过程的实施例。
图10图示了初始存储器指派和处理器指派的示例。
图11图示了存储器指派的更新视图和处理器指派的无变化视图。
图12图示了存储器指派和处理器指派的更新视图。
图13A图示了其中在选择性资源迁移中使用网络附连存储器的系统的示例实施例。
图13B图示了其中在选择性资源迁移中使用网络附连存储器的系统的示例实施例。
图14图示了网络附连存储器设备的示例实施例。
图15是图示了分配页面的实施例的图。
图16图示了根据高速缓存一致性协议的节点间通信的示例实施例。
图17是图示了用于在存在网络附连存储器的情况下维护高速缓存一致性的过程的实施例的流程图。
图18是图示了用于使页面归零的过程的实施例的流程图。
具体实施方式
本发明可被以许多方式实现,包括作为过程;装置;系统;物质的成分;具体化在计算机可读存储介质上的计算机程序产品;和/或处理器,诸如被配置成执行存储在耦合到处理器的存储器上和/或由耦合到处理器的存储器提供的指令的处理器。在本说明书中,这些实施方式或本发明可以采取的任何其他形式可以被称为技术。一般而言,可以在本发明的范围内更改公开的过程的步骤的顺序。除非另外说明,否则被描述为被配置成执行任务的诸如处理器或存储器之类的组件可以作为被暂时地配置成在给定时间执行该任务的通用组件或被制造成执行该任务的特定组件被实现。如本文中所使用的,术语“处理器”指代被配置成处理数据(诸如计算机程序指令)的一个或多个设备、电路和/或处理核心。
在下面同图示本发明的原理的附图一起提供本发明的一个或多个实施例的详细描述。结合此类实施例对本发明进行描述,但是本发明不限于任何实施例。本发明的范围仅由权利要求限定,并且本发明包含许多替代方案、修改和等同物。在以下描述中阐述许多具体细节以便提供对本发明的透彻理解。这些细节是为了示例而提供的并且可以根据权利要求来实践本发明,而无需这些具体细节中的一些或全部。出于清楚的目的,尚未详细地描述与本发明有关的技术领域中已知的技术材料,使得不会不必要地使本发明混淆。
图1图示了计算机系统的实施例。系统100在本文中也被称为“企业超级计算机”和“大型机”。在所示出的示例中,系统100包括极为接近地定位(例如,位于同一机架内)的多个节点(例如,节点102-108)。在其他实施例中,可在系统中使用节点的多个机架(例如,位于同一设施内)。进一步地,也可与分布式系统相结合地使用本文中所描述的技术。
节点用诸如10吉比特以太网、直接PCI到PCI和/或无限带宽技术(InfiniBand)之类的高速互连(110)互连。每个节点包括商品服务器类硬件组件(例如,机架中带其附连或包含的外围设备的刀片)。在图1中所示的示例中,每个节点包括多个物理处理器芯片。每个物理处理器芯片(也称为“插口”)包括多个核心,并且每个核心具有多个超线程。
如图2中所图示,系统100的物理结构形成超线程(230)、核心(210-224)、物理处理器芯片(202-208)和节点(102-108(其中节点104、106等被从图中省略并表示为椭圆))的层次结构(从底部起)。图2中所描绘的树具有通过硬件配置定义的固定大小。
如将在下面更详细地描述的,每个企业超级计算机(例如,系统100)运行操作系统的单个实例。操作系统和任何应用都可以是标准商业上可买到的标准软件并且可在系统100上运行。在本文中所描述的示例中,操作系统是Linux,然而也可以使用其他操作系统,诸如Microsoft Windows、Mac OS X或FreeBSD。
在传统的虚拟化计算环境中,多个虚拟机可以在单个物理机器上运行。在图3A中描绘了这种场景。特别地,三个虚拟机(302-306)正在单个物理机器(308)上运行三个客户操作系统,所述单个物理机器(308)具有它自己的主机操作系统。相比之下,使用本文中所描述的技术,多个物理机器(354-358)共同地运行单个虚拟操作系统(352),如图3B中所描绘的。
在图4A中描绘了软件栈的一个示例。这种栈通常可以被用在传统的计算环境中。在图4A中所示出的栈中,应用(402)位于数据库引擎(404)之上,所述数据库引擎(404)又位于操作系统(406)上,硬件(408)位于所述操作系统(406)之下。图4B描绘了在一些实施例中使用的软件栈。与图4A中所示出的栈一样,应用(452)位于数据库引擎(454)之上,所述数据库引擎(454)又位于操作系统(456)上。然而,在操作系统之下且在硬件之上是软件层(在本文中称为超内核),所述软件层观察实时地运行的系统并且优化系统资源以与系统在它操作时的需要匹配。超内核概念上统一一组商品服务器的RAM、处理器和I/O (输入输出资源,例如储存器、联网资源),并且将该统一集呈现给操作系统。由于这个抽象,操作系统将具有包含处理器、存储器和I/O的聚合集的单个大型计算机的视图。如将在下面更详细地描述的,超内核优化资源的使用。超内核也可以帮助优化诸如网络和储存器之类的其他I/O系统资源。在一些实施例中,基于运行软件的观察结果和概况,关于系统的动态性能的性能指标(提示)被提供给上层(例如,数据库管理系统),这可进一步改进总体系统性能。
超内核可被移植到所有主要的微处理器、存储器、互连、持久储存器和联网架构。进一步地,随着硬件技术演进(例如,利用新处理器、新存储器技术、新互连等),可按需修改超内核以利用行业演进。
如图4B中所示,操作系统456正在共同地跨越一系列节点(458-462)运行,每个节点都具有在服务器硬件上运行的超内核。具体地,操作系统正在通过超内核的合集来定义的虚拟环境中运行。如将在下面更详细地描述的,用于操作系统456的视图是它正在包括单独的节点458-462的所有硬件资源的单个硬件平台上运行。因此,如果每个节点包括1 TB的RAM,则操作系统将具有它正在包括3 TB RAM的硬件平台上运行的视图。其他资源(诸如处理能力)和I/O资源可类似地被操作系统的视图共同地利用。
图5描绘了示例系统上的硬件的操作系统的视图的示例。具体地,操作系统(502)在处理器504-508和物理共享存储器510之上运行。如上面所说明的,操作系统可在传统的计算系统上或者在诸如图1中所示出的企业超级计算机上运行。在任何情况下,操作系统的视图将是它能够访问处理器504-508和物理共享存储器510。
图6A描绘了单个节点上的硬件的超线程的视图的示例。在这个示例中,节点具有被表示为H1 (602)至H4 (608)的四个超线程。每个超线程可访问物理共享存储器612的所有部分。物理共享存储器612是线性的,标记为位置0至最大量“max”。该节点也包括三级高速缓存(610)。
图6B描绘了示例系统上的硬件的超内核的视图的示例。在这个示例中,三个节点(652-656)被包括在企业超级计算机中。三个节点中的每一个均具有四个超线程、物理共享存储器和高速缓存(即,每个节点是图6A中示出的节点600的实施例)。给定节点(例如,节点652)上的超线程具有与如图6A中所示的视图相同的视图。然而,超内核知道所有节点上的所有资源(即,超内核看到十二个超线程以及所有的物理共享存储器)。在图6B中示出的示例中,给定超线程(例如,超线程658、“H1-4”)被标记有其节点编号(例如,“1”),后面是超线程编号(例如,“4”)。
图7描绘了企业超级计算机系统的示例上的硬件的操作系统的视图的示例。操作系统将图7中表示的多个“虚拟化处理器”视为P1至Pmax (702)。虚拟化处理器对应于跨越包括在企业超级计算机中的所有节点的超线程的总数。因此,使用图6B的示例,如果跨越三个节点存在总共十二个超线程,则总共十二个虚拟化处理器将对在企业超级计算机上运行的操作系统可见。操作系统也看到“虚拟化物理存储器”(704),所述“虚拟化物理存储器”(704)似乎是大小等于跨越所有节点的物理存储器的总量的大型物理线性存储器。
如将在下面更详细地描述的,超内核基于其对系统在它正在运行时的观察结果动态地优化高速缓存存储器和虚拟处理器布局的使用。“虚拟处理器”是为其客户操作系统所知的计算引擎,即,具有一些操作系统上下文或状态的计算引擎。如将在下面更详细地描述的,“影子处理器”是匿名虚拟处理器,即,曾经为虚拟处理器但是现在已经放弃其操作系统上下文并且具有仅为超内核所知的上下文的虚拟处理器。
资源虚拟化
存储器虚拟化
如上面所说明的,在物理配置中,每个节点具有表示存储器中的位置的存储器地址的阵列。因此,在具有三个节点的物理配置中(例如,如图6B中所描绘的),存在三个存储器位置,其中的每一个均具有地址0x123456。相比之下,在虚拟配置中,所有存储器地址是唯一的并且表示包含在那三个节点中的所有存储器的总和。在虚拟配置中,所有存储器被共享,并且所有存储器高速缓存是一致的。在一些实施例中,存储器被进一步细分成具有单调递增的存储器地址的一系列连续块。在本文中所描述的示例中,每个页面具有4K字节的存储器,然而,也可酌情使用其他细分。术语“块”在本文中用于描述存储器位置的连续阵列。在一些实施例中,“块”是“页面”。
处理器虚拟化
如由操作系统所看到的虚拟处理器(例如,图7的虚拟处理器706)被按照物理配置实现在超线程上,但可以是位置无关的。因此,虽然操作系统认为它有在单个物理服务器上运行的500个处理器,但是实际上它可能具有每个100个处理器的5个节点。(或者,如图6B中所示,操作系统将认为它具有在单个物理服务器上运行的十二个处理器)。在虚拟处理器上运行的计算通过关于当计算正在运行时的超线程的物理配置来描述,或者当虚拟处理器不在运行(即,中断或停滞计算的状态)时被描述为在“继续部分”中。
如本文中所使用的,“继续部分”表示虚拟处理器的状态。每个继续部分:
• 具有处理器状态(即,保存的寄存器等)。
• 具有按关于如何将继续部分智能地指派给叶节点以供执行的信息而指导调度器对象的一组性能指标。
• 具有指示操作系统认为是这个继续部分被指派给的物理处理器的处理器的虚拟处理器标识符。
• 具有这个继续部分正在等待的事件(可能为空的)。
• 具有包括“等待事件”或“就绪”的状态。
I/O虚拟化
I/O系统观察处理器和存储器的类似范例。设备具有物理配置中的物理地址和虚拟配置中的虚拟地址。当迁移计算(在下面更详细地描述)时,如果例如存在与I/O操作相关联的存储器缓冲器,则所使用的I/O设备在它们和与之相关联的存储器位于一处的情况下将很可能执行得更好,并且可被相应地移动。
资源图
资源图用于在虚拟配置与物理配置之间转化。下列的是在各种实施例中由企业超级计算机使用的三种类型的资源图。
“物理资源图”是描述在每个节点上可用的物理资源的表。它包含例如每个节点上的处理器的数量和类型、设备、可用存储器及其物理地址的范围等。在一些实施例中,这个表是只读的并且在引导时间是固定的。
“初始虚拟资源图”在操作系统的引导之前是固定的并且描述从操作系统的角度看可用的虚拟资源。配置可由操作系统读取。在一些情况下,可能期望配置与底层硬件资源不一对一匹配的系统(从操作系统的角度看)。作为一个示例,可能期望操作系统具有更多的存储器和更少的核心。这可通过改变存储器与核心的比例即通过修改初始虚拟资源图来实现。
“当前资源图”由每个超内核实例来创建和维护。这个图从每个节点的角度来描述虚拟资源图与物理资源图之间的当前映射。对于虚拟资源图中的每个条目,维护当前指派给虚拟资源的物理资源的定义。最初(例如,在引导时间),当前资源图是初始虚拟资源图的副本。超内核随着时间的推移在它观察到资源负载的特性时修改当前资源图并且动态地改变物理资源到虚拟资源的映射(并且反之亦然)。例如,虚拟机中的以太网控制器eth27的位置的定义可以在不同的时间指代不同的硬件控制器。当前资源图被超内核用来视需要而定动态地修改虚拟硬件资源图,诸如虚拟存储器子系统。
资源迁移概要
使用本文中所描述的技术,可在物理位置之间迁移虚拟化资源。如上面所说明的,操作系统被提供有关于虚拟化系统的信息,但是该信息不必与物理系统一致。
在以下示例中,假设企业超级计算机持有大于可装配到单个节点中的大型存储器内数据库。数据库的一部分在第一节点“节点1”中。假设不同节点“节点2”上的核心中的一个正在设法访问由节点1拥有并且不在本地驻留在节点2上的高速缓存中的数据。节点2上的核心将接收到存储器访问违反,因为它正在设法访问它认为它应该能够访问(但不能访问)的数据。如将在下面更详细地描述的,异常在超内核中被处理。
可解决该情形的一个方式是通过将存储器的所需区域移动到节点2,然后将控制返回给操作系统(其又将它返回给数据库系统)。软件然后可按预期继续进行(即,如同从未发生过访问违反一样)。
在许多情况下,在也正在设法访问如上面由节点2所需要的存储器的相同区域块的其他节点(例如,“节点3”)中可以存在一个或多个其他核心。节点3可能在试图访问相同数据,或者它可能在访问被移动的包含在存储器中的不同数据(也称为“假共享”)。数据能被移动到节点3,但是如果节点2上的核心第二次请求数据,则将需要将数据移回到节点2(即,可能反复地来回移动数据),这可能是缓慢的且浪费的。避免在核心之间来回移动数据的一个方式是识别核心和数据的关联块应该位于一处。使用本文中所描述的技术,可迁移存储器和计算,使它们驻留在相同节点上。这样做将导致对数据的更快访问的更高可能性,以及共享存储在本地高速缓存中的数据的更高概率。
当发生访问违反时,超内核响应于的事件被触发(以系统相关方式)。这样的事件可被如何处理的一个示例是通过应急(panic)例行程序的调用。也可酌情使用其他方法。如将在下面更详细地描述的,超内核检查事件的原因并且确定用于处理事件的适当的策略(例如,低级事务)。如上面所说明的,处理事件的一个方式是为了超内核虚拟化存储器的一个或多个块被从一个节点的存储器转移到另一节点的存储器。转移然后将被发起并且所对应的资源图将被更新。继续部分将被建立准备好被放置于共享存储器中被称作事件表(在下面讨论)的本地表中,使得继续部分在它被恢复时做的下一件事情将是在转移完成之后将控制返回给操作系统。也能做出将虚拟处理器移动到包含被请求的存储器的节点或者将虚拟化存储器(及其虚拟化存储器地址)从一个节点移动到另一节点的决定。在各种实施例中,超内核在处理事件时做出三个决定:哪些(虚拟)资源应该移动、何时移动它们以及它们应该移动到哪里(在物理位置方面)。
TITALTREE
图2中描绘的物理分层结构具有包括一组“调度器对象”(即,数据结构)的类似的软件层次结构,该组“调度器对象”中的每一个具有在下面所描述的一组特性。调度器对象形成“TitalTree(Tital树)”,其是其中树的每个节点为调度器对象的存储器内树数据结构。每个调度器对象对应于超级计算机的物理结构的元素(但是不一定反之亦然),所以存在用于整个机器的一个节点(例如,如图2中所示的节点100)、用于系统的每个物理节点的一个节点(例如,如图2中所示的节点102)、用于包括整个机器的物理节点上的每个多核心插口的一个节点(例如,如图2中所示的节点202)、用于每个插口的每个核心的一个节点(例如,如图2中所示的节点210)以及用于该核心上的每个超线程的一个节点(例如,如图2中所示的节点232)。
每个调度器对象s:
• 与物理组件(例如,机架、刀片、插口、核心、超线程)相关联。
• 除树的根之外,还具有部分地负责引导其操作(如在下面更详细地说明的)的父调度器对象。
• 具有每个为调度器对象的一组孩子。这对于叶(例如,超线程)节点来说为空集。如在下面更详细地说明的,调度器对象s的责任是管理并将工作指派(或者重新指派)给其孩子,并且间接地指派给其孙子等(即,s管理根在s处的子树中的所有节点)。
• 具有工作队列,其是一组继续部分(如早先所描述的)。
• 具有(可能为空的)一组I/O设备,它也具有管理和指派(或者重新指派)工作的责任。
每个节点可潜在地与某种形式的高速缓存存储器的层相关联。高速缓存层次结构在调度器对象越高、计算通常将高效地利用层次结构的对应级处的高速缓存越慢的意义上遵循树的层次结构。与物理节点相对应的调度器对象的高速缓存可以是与该节点相对应的存储器的高速缓存。物理节点上的存储器可被认为是虚拟机存储器的高速缓存。
资源迁移-附加信息
超内核模拟虚拟配置驻留在其上的虚拟硬件的一部分。它是事件驱动架构,不仅涉及转化的物理硬件事件,而且涉及软事件,诸如通过在其他节点上运行的超内核代码产生的节点间超内核消息的接收。
如上面所说明的,当发生对超内核有意义的中断事件时,超内核做出如何对该中断做出响应的决定。在控制被返回给操作系统之前,识别任何更高优先级中断并且采取适当的动作。另外如上面所说明的,超内核可做出三个单独的决定:(1)在某些事件时要迁移哪些资源,(2)何时迁移它们,以及(3)那些资源应该移动到哪里。
在以下示例中,假设虚拟机中的调度器对象“s”处于稳定状态。与物理节点相对应的每个调度器对象具有指派给它的一组物理处理器插口。这些插口中的超线程可以或者可以不是忙的。物理节点也具有一些固定量的主存储器和一组I/O设备,包括一些网络设备。调度器对象s在对应于节点时,也负责管理指派给根在s处的子树中的节点的网络和其他I/O设备。下列的是资源如何可在同步事件或异步事件时迁移的描述。
通过同步事件触发的迁移
在以下示例中,假设存在叶节点调度器对象s和指派给s的虚拟处理器p。叶节点调度器对象s被假定为代表应用执行应用或操作系统代码。假定叶节点不在无限循环中,p由于某种原因(例如,等待I/O操作完成、页面错误等)将最终停止工作(即,停止)。不是允许p实际地停止,而是超内核决定是否将有关已停止的计算的信息移动到某个其他节点,从而使该其他节点的处理器中的一个“负责”已停止的继续部分,或者在节点上保持“负责”已停止的计算并且替代地将相关资源移动到当前节点。
停止因此被以两个方式中的任何一个处理:要么计算被移动到当前具有资源的物理节点,要么否则资源被移动到已请求资源的物理节点。用于处理停止的示例伪代码在下面(作为“OnStall”例行程序)被提供在下面的“示例例行程序”部分中。
诸如如何处理停止的决定可依赖于很多事情,诸如事件的到达次序、在虚拟机上运行的计算的状态、高速缓存的状态、系统或节点上的负载和许多其他事情。决定是动态地即基于在任何给定时间点可用的最佳信息做出的。
记录停止的计算
停止的计算被记录在称为“继续部分”的数据结构中。继续部分具有可以是例如“等待事件”或“就绪”的状态。停止的计算得以记录为具有状态“等待事件”的重新创建的继续部分。一旦满足停止的原因(例如,由于检测到事件),所对应的继续部分的状态就被改变为“就绪”。具有状态“就绪”的每个继续部分被存储在调度器对象的“等待队列”中,使得最终它得以调度以供执行。相比之下,具有状态“等待事件”的任何继续部分将不被存储在任何调度器对象的等待队列中。替代地,它被存储在预期发生停止了对应计算的硬件事件(诸如遗漏资源的接收)的物理节点的本地共享存储器中。
附加地,重新创建的继续部分与导致了其创建的停止事件相关联。(停止)事件与等待这些事件的继续部分之间的这种映射允许异步事件的快速调度(参见在下面所描述的“处理事件”)。继续部分与事件之间的映射被存储在被称作“事件表”的表中并且被保持在对应物理节点的共享存储器中。每个物理节点具有它自己的事件表,并且物理节点的事件表可由该物理节点上的每一内核直接地寻址。记录在物理节点事件表中的所有预期事件对应于在该物理节点上可能发生的硬件事件。映射到物理节点n的调度器对象s表示n,并且n的事件表与s相关联。在一些情况下,若干继续部分可能在等待相同事件,并且所以当事件被触发时可能需要某种消歧。
继续部分使用“InitContinuation”例行程序来构建。如果做出了要移动计算的决定,则持有资源的远程物理节点将构建对应于已停止的计算的继续部分,并且会将它存储在远程物理节点的事件表中。当该继续部分恢复时,资源将是可用的。实际上,超内核已将虚拟处理器转移到不同节点。
在其中做出了要移动资源的决定的情况下,已经历停止的节点请求转移资源并使用InitContinuation来构建继续部分并且将它存储在本地事件表中。在接收到资源时,继续部分被附连到TitalTree中的适当的节点,并且当该继续部分被恢复时,资源将通常是可用的且可见的。实际上,虚拟资源已被转移到请求了它的节点。
注意的是,通过将继续部分放置在事件表中,保证了接收到事件的处理器将在其本地事件表中快速地找到相关继续部分。计算停止的原因将得到满足。
在处理停止后,虚拟处理器p实际上将被挂起。在处理停止与查找要恢复的新继续部分之间,p变成“匿名影子处理器”,即,没有为操作系统所知的身份的处理器。这个影子处理器然后寻找要恢复的新继续部分。这样的示例在下面“assignProcessor”例行程序中被示出,该例行程序在下面被更详细地描述。
表示法
假设e为停止了虚拟处理器p的事件。假定e由某个物理节点n的本地硬件触发。特别地,假定r是使停止事件发生的资源。资源r可以是存储器的块或I/O操作或网络操作。假定p被指派给调度器对象s,所述调度器对象s属于根在表示物理节点n的调度器对象处的子树。
On-Stall
在下面在“示例例行程序”部分中提供了用于示例on-stall例行程序的伪代码。当且仅当节点n中的处理器p决定资源不应该移动即计算应该移动时,迁移继续部分函数才返回真。这可通过许多因数来确定,所述因数诸如节点之间的r的移动的历史和频率、r的类型、移动的成本、在n的本地事件表中等待r的事件的数量、系统负载等。例如,如果在n的本地事件表中存储有正在等待资源的继续部分,则可能不期望移动资源。
存在将受益于迁移的事件的各种模式。描述事件(例如访问违反)的这些模式的一个方法是采用形式语言理论。可通过有限状态自动机来识别正规(即,乔姆斯基3型)语言。此外,使用紧凑且灵活的表示法,可使被观察到的事件的描述成为正规语言中的句子(或乔姆斯基序列),并且识别建模为所对应的有限状态自动机中的状态转变。当看到事件的完整乔姆斯基序列时,迁移继续部分得以相应地评估:如果有限状态自动机接受乔姆斯基序列,则满足条件,否则不满足条件。最小化的有限状态机的长度定义需要被保持的历史的量。
在各种实施例中,所有事件在本地发生,并且接收事件的物理节点上的超内核必须处理它—确实地同步事件未被假定为在物理节点之间发生。为了协调节点之间的迁移策略,“消息”被使用。消息“发送”从节点的角度看是同步的,但是消息“接收”是异步的,因为处理器或影子处理器一般而言不等待消息的接收。当消息到达时,它们被超内核会作为虚拟中断处理。在一个实施例中,当存在等待被处理的消息时,超内核将不允许处理器恢复继续部分。因此,在控制被转移回到操作系统之前,队列被检查,并且任何消息在控制转移回到操作系统之前被处理。
对于调度器对象s和继续部分c,可使用成本函数cost(s,c)来指导向上搜索树。如果p的多个祖先有非空队列,则p可能不想停止其在发现有非空等待队列的第一祖先处的搜索。取决于优化策略中使用的度量,p的选择可能不仅取决于p与其选择的祖先之间的距离,而且取决于诸如等待队列的长度之类的其他参数。
可使用函数find-best-within(s)来在调度器对象的(非空)等待队列中返回“最佳适合”继续部分。可考虑的参数的示例包括:
1. 队列中的位置
2. p与记录在继续部分中的最后位置之间的关系(那些位置越靠近,它对于重用高速缓存条目来说越好)。
3. 记录在队列中的继续部分中的性能指标。
可在给定系统内酌情定制cost和find-best-within函数。
通过异步事件触发的迁移
异步事件的示例包括:分组的接收、I/O转移的完成、资源的接收、请求资源的消息的接收等。一般地,接收到与由操作系统管理的硬件设备相对应的事件的超内核需要将与该事件相关联的继续部分递送给调度器对象s。通过这样做,s将使这个继续部分对于适当的调度器对象可用,然后最终对于由通过该继续部分表示的操作系统所管理的计算可用。另一方面,如果事件是从另一物理节点上的超内核接收到消息,则超内核可直接地处理它。
为了简化说明,在本文中所描述的示例中,做出了仅存在与事件相关联的一个继续部分的假定。可按需针对其中多个继续部分与相同事件相关联的情况来概括本文中所描述的过程。
在一些实施例中,针对要在上面放置继续部分的调度器对象的搜索在构建该继续部分的树的叶处开始,然后向上继续进行(如果先前在此节点上执行了计算)。通过这样做,重用高速缓存条目的可能性增加了。
处理事件
在下面在“示例例行程序”部分中提供了用于示例处理事件例行程序的伪代码。成本函数cost(s,c)是帮助确定将c指派给调度对象s的适合性的函数。成本函数可取决于各种参数,诸如等待队列的大小、s与用于c的原始调度节点之间的节点遍历距离(以增加高速缓存条目将被重用的概率)以及虚拟处理器、物理处理器和继续部分的历史。如果靠近s的调度器对象的等待队列已经包含太多继续部分,则在任何重新添加的继续部分被调度以供执行之前可能花费相对较长的时间。在下面描述了有助于cost(s,c)的示例条件,并且可酌情定制这些条件。
成本
成本函数用于在选择继续部分和调度对象时评估选项。可将成本函数表达为加权因数的和的求和:
其中wi指示对应因数的重要性并且xi指示指数。
因数fi的示例是针对下面的每个成本而列举的。可以各种方式(诸如凭经验和通过模拟)确定权重wi和指数xi。初始权重和指数可被调谐到各种应用需要,并且可由管理员调整以提高性能。可在系统活动的同时调整权重,并且改变权重不改变超内核的语义,仅改变操作性能特性。
可考虑的因数的示例包括:
• 自最后处理器撤出这个调度器对象以来的时间的长度。
• TitalTree中的调度器对象的高度。
• 工作队列的长度。
• 保留状态(即,情况可能是某个应用由于特定原因而已保留此资源)。
• 节点规范(即,节点它本身可能已被停用或者是有问题的,在某种程度上具有专门功能等)。
• 队列中的继续部分的年龄。
• 要运行这个继续部分的最后物理处理器。
• 要运行这个继续部分的最后虚拟处理器。
• 这个继续部分最后执行的节点。
• 高速缓存的“温度”。(高速缓存在它具有很可能被重用的条目时是“暖的”。高速缓存在它不可能具有可重用的缓存条目时是“冷的”。)
• 继续部分的组成员关系(即,继续部分可以是计算组的一部分,其中的每个元素对于该组的其他成员来说具有某种亲和力)。
• 性能指标(提示)和特殊要求。
示例
“OnStall”和“assignProcessor”
图8图示了用于选择性地迁移资源的过程的实施例。在一些实施例中,过程800由超内核诸如结合OnStall例行程序执行。当接收到核心(或包括在核心中的超线程,取决于处理器芯片是否支持超线程)被阻塞的指示时过程在802处开始。作为一个示例,假设超线程直接地或间接地接收到对超线程不能够访问的资源(例如,位于与保持超线程的节点不同节点上的RAM)的请求。当超线程未能访问资源(即,发生访问违反)时,发生在802处由超内核拦截、捕获或者以其他方式接收的中断。特别地,超内核在802处接收超线程被阻塞(因为它不能访问已被指示提供的资源)的指示。除了报告其阻塞状态之外,超线程还提供诸如它被指示访问的存储器地址以及什么类型的访问被尝试(例如,读取、写入或修改)之类的信息。
在804处,超内核确定所需存储器是否应该被移动(例如,到阻塞超线程所位于的节点),或者请求进程是否应该被重新映射(即,虚拟处理器应该被转移到不同节点)。决定可基于各种因数,诸如所需存储器位于在的地方、高速缓存的温度、保持超线程的节点上的工作负载以及保持所需存储器的节点上的工作负载(例如,工作过度或工作不足)。在一些实施例中,节点的工作负载是至少部分地基于TitalTree中的平均队列长度来确定的。
如果超内核确定存储器应该被移动,则超内核使用其当前资源图来确定哪一个节点很可能保持所需存储器并且向该节点发送消息,从而请求资源。超内核也创建继续部分并将它放置在其事件表中。在802处被阻塞的超线程因此被释放以承担其他工作,并且可使用assignProcessor例行程序被指派分配给另一虚拟处理器。
超内核在高优先级基础上检查其消息队列。当超内核从它联系的节点(即,“第一联系节点”)接收消息时,在一些实施例中,将接收两个响应中的一个。响应可能指示第一联系节点具有所需资源(并提供资源)。可替代地,消息可能指示联系节点不再具有资源(例如,因为节点将资源提供给了不同节点)。在后者情形下,第一联系节点将提供它将资源发送到的节点(即,“第二节点”)的身份,并且超内核可发送请求资源的第二消息—这次到第二节点。在各种实施例中,如果第二节点向超内核报告它不再具有资源(例如,已将它提供给第三节点),则超内核可以选择将继续部分发送到第三节点,而不是继续请求资源。可在确定是发送继续部分还是继续资源(例如,四次尝试)时使用其他阈值。进一步,可在确定是请求资源还是发送继续部分(例如,依照成本函数)时使用各种准则。
如果超内核确定应该转移继续部分(即,应该将计算发送到另一节点而不是在本地接收资源),则超内核给远程节点(即,具有所需资源的远程节点)提供该远程节点可使用来在它自己的物理地址空间中构建继续部分的信息。如果远程节点(即,接收继续部分的远程节点)具有它需要的所有资源(即,拥有导致初始访问违反的资源),则继续部分将不必被放置到远程节点的事件表中,而是可替代地被放置在其TitalTree中。如果远程节点需要附加资源来处理继续部分,则所接收到的继续部分被放置在远程节点的事件表中。
图9图示了用于执行分层动态调度的过程的实施例。在一些实施例中,过程900由超内核诸如结合assignProcessor例行程序执行。当接收到应该指派超线程的指示时过程在902处开始。可以多种方式调用过程900。作为一个示例,当超线程可用(即,无当前工作要做)时可调用过程900。例如,当超内核确定(例如,在804处)应该做出继续部分时可发生这个。先前阻塞的超线程将变得可用,因为它不再负责处理它在上面阻塞的计算(即,超线程变成“匿名影子处理器”)。作为第二示例,当(例如,由超内核)接收到先前不可用的资源现在可用的消息时可调用过程900。超内核将需要定位超线程以恢复需要资源的计算。注意,最初因缺乏资源而被阻塞的超线程不必是一旦接收到资源就恢复计算的超线程。
在904处,为了准备好运行的继续部分而搜索TitalTree,并且为了超线程恢复而选择一个。在各种实施例中,从叶级向上搜索TitalTree,并且使用成本函数来确定要将哪一个继续部分指派给超线程。作为一个示例,当超线程变得可用时,能指派已被排队达最长时间量的继续部分。如果没有继续部分在叶级等待,或者在由成本函数指定的阈值之外,则将向TidalTree上(例如,核心级,然后插口级,然后节点级)执行搜索以得到适当的继续部分以指派给超线程。如果未找到适当的继续部分以用于超线程在节点级恢复,则该节点的超内核将联系根。在节点级未找到继续部分的一个典型原因是没有用于该节点被充分地利用的足够工作。在一些实施例中,节点或节点的子集可进入节能状态。
时间序列
出于说明目的,在该示例中,使用“交换”操作来转移继续部分和存储器,但是实际上在所有实施例中这不是必需的。
图10图示了初始存储器指派和处理器指派的示例。具体地,图10的区域1002描绘了存储器的物理块(在左侧)与存储器的当前所有者(中心列)之间的超内核的映射。右列示出了存储器的先前所有者。当这个是初始存储器指派时,当前和最后所有者列保持相同的值。图10的区域1004描绘了系统虚拟处理器(在左侧)与物理节点(中心列)/核心编号(右列)之间的超内核的映射。
假设虚拟处理器P00做出读取位置8FFFF并且超核心决定将包含8FFFF的一个或多个存储器块移动到与P00相同的节点(即,节点0)的存储器请求。块8FFFF位于节点2上。因此,包含8FFFF的块被转移到节点0,并且另一块被换出(如果需要撤出并且块有效的话),如图11中所示。
接下来,假设虚拟处理器P06做出读取位置81FFF的存储器请求。这个块的内容已被移动(如图11中所示)到节点0。超内核可以确定,不是再次移动存储器,而是应该移动计算。因此,虚拟处理器P06被移动到节点0,并且可以与虚拟处理器P01交换,如图12中所示。
性能信息
锁和其他同步器
在各种实施例中,像锁一样的同步机制的使用是最小的。锁例如用于插入队列和移除调度器对象上的队列继续部分并且用于维护事件表。
代码路径长度
在一些实施例中,所有代码路径的(最大)长度是通过静态代码分析来确定的,从而导致在超内核它本身中花费可估计且有界的时间量。所有数据结构可例如作为索引阵列被预分配。TidalTree的节点在引导时间被确定并且是不变的,其遍历中的步数也是不变的。一个可变长度计算必须处理工作队列的长度,但是即使那样也可以是有界的,并且计算最坏情况估计。在其他实施例中,使用其他可变长度计算。
静态储存器
在各种实施例中,在超内核中需要的所有数据结构是静态的,并且在引导时间被确定,所以不需要动态存储器分配或垃圾收集。
物理存储器
由超内核使用的所有存储器是物理存储器,所以其内部操作不需要页面表或虚拟存储器(除了例如管理它正在管理的虚拟资源),从而进一步帮助超内核与操作系统共存。
共享数据并维护一致性
在一些情况下,例如,为了保存被呈现给操作系统的虚拟机的概念完整性,一个节点的数据结构中的变化与不同节点中的对应数据结构协调。本文中所描述的许多数据结构是“节点本地的”,并且将不需要移动,或者是恒定的和复制的。节点本地的数据结构对节点上的所有超线程可见并且可由节点上的所有超线程寻址。非节点本地的(并且因此需要协调)的数据结构的示例包括当前资源图(或其部分)、TidalTree的根和迁移继续部分(即,可能必须从一个节点逻辑上移动到另一节点的继续部分)。
可使用各种技术来维护足够程度的一致性。一些技术是同步的并且假定所有变化同时对所有节点可见(即,“立即一致性”)。其他技术允许更轻松的解决方案并且争取“最终一致性”。如上面所提及的,企业超级计算机的物理节点经由一个或多个高速互连连接。超内核的多个实例互连以在物理节点之间来回传递消息和资源。
更新当前资源图
每个物理节点n从物理资源图、初始虚拟资源图和当前资源图的相同副本开始(例如,在引导时间)。每个节点维护它自己的当前资源图的副本。
在一些实施例中,当前资源图中的资源r的每个条目具有下列的:
1. 本地锁,使得物理节点上的多个超线程不能同时修改r。
2. 指定当前拥有资源的节点的节点编号。
3. 自从上一次拥有r之后,已经请求r的次数n的计数k。
4. 当置位时表示此节点n想要r的布尔值。
5. 当置位时表示此节点具有r但是在转移它的过程中的布尔值,在此情况下节点编号指定新的所有者。
在一些实施例中,计数k用于处理对资源的无界追逐。如果k超过阈值,则做出最好是移动重新构建的继续部分而不是围绕系统追逐资源的确定。
下列的是用于发起资源的迁移并且接收资源的机制的示例。关键事务包括下列的:
1. 节点n向n’发送对资源r的请求。
2. 节点n’从n接收对资源r的请求。
3. 节点n’可以在某些情况下向n发送“拒绝”消息,否则它可“接受”并且将发送资源r。
4. 如果资源r不能由n’在此时间点发送,则节点n将从n’接收到“拒绝”消息。这可能是因为n’需要r,或者这可能是因为r在请求到达时正在向某处转移。如果请求被拒绝,则它可发送它正在转移资源的节点的“转发”地址。这可能是因为转发地址是n’它本身,这相当于“稍后再试”。当节点n接收到拒绝消息时,它可将请求重新发送到由n’建议的节点,常常是资源的新所有者。为了避免n围绕系统追逐资源,它可跟踪取得资源的尝试次数,并且在尝试次数超过阈值时转换策略。
5. 如果n’可发送资源则节点n将接收资源r。在这种情况下,n需要调度正在等待r的继续部分c,使得可恢复c。
TidalTree根
在一些实施例中,系统中的节点的集合的一个物理节点被标明为“主节点”。此节点具有在引导时间用于构建初始虚拟资源图和其他数据结构、将它们复制到其他节点并且引导操作系统(例如,Linux)的责任。只有一个例外,在系统被引导之后,主节点可以像任何其他节点一样。至少有一个物理节点需要存储TidalTree的根。主节点是可放置根的地方的一个示例。对TidalTree根调度对象的事件队列的更新是在每个节点中通过向主节点发送消息以执行更新来处理的。
随着时间的推移,如果操作系统和应用的资源访问模式许可,则超内核将适配并且地点将不断地改进。
继续部分
如上面所说明的,跨越所有节点的物理存储器地址是不唯一的。在一些实施例中,可通过使用分区整数索引来标明超内核中的重要数据结构来避免在继续部分中包括物理存储器地址。如果需要将地址放入继续部分,则在移动中当心,因为地址是源的物理地址,并且与目的地中的物理地址没有关系。移动继续部分意指像上面所讨论的那样将其内容复制到目的地节点,并且将任何物理地址从源重新映射到目标。
时间戳
在一些实施例中,对自由运行计数器的访问对所有节点可见。在不存在这个的情况下,也可使用每个节点上的自由运行计数器。继续部分中的计数器被映射在源与目的地之间。
磁盘和持久闪存的处理
在所需资源在磁盘(或持久闪存)上的情况下,在一些实施例中,此类资源被视为具有比诸如RAM的资源更重的重力场。因此,磁盘/闪存资源将往往不经常迁移。替代地,在需求基础上,继续部分将更频繁地迁移到包含所需持久储存器的物理节点,或者迁移到与持久储存器相关联的缓冲器。
操作系统配置
存在配置操作系统的多种方式。对于服务器,可做出其操作系统被配置成仅需要来自由超内核实现的虚拟机的一小组资源类型的假定:包括线性块阵列的储存器、网络、处理器、存储器和节点间互连。结果,可降低操作系统安装的复杂性。
示例数据结构和函数
以下部分提供了在各种实施例中使用的数据结构和函数的示例的列表。
init-continuation:当计算被停止时初始化继续部分。
assignProcessor:将新的继续部分指派给影子处理器(若可能的话)的例行程序。
on-stall(r):资源r发生停止事件。
migrate-computation(computation-state,r,n):用于请求将计算状态迁移到你希望具有资源r的另一节点n的消息。
on-interrupt(i):发生软件中断i。
handle-event(e):当超内核被调用来处理异步事件时执行的例行程序。
request-resource(r,n):请求从节点n转移资源r。
initiate-send-resource(r,n):开始向节点n发送资源r。
on-request-transfer-response(r,n,b):所请求的从n转移r被接受或者拒绝。如果被拒绝则b为真。
on-transfer-requested(r,m):接收来自m对资源r的请求。
on-resource-transferred(r,n):已经从n接收到资源r的确认(Ack)。
on-receive-resource(r,n):已经从n接收到资源r。
migration-continuation(r):当且仅当迁移继续部分比移动资源更好时才为真。
parent(s):返回调度器对象s的父调度器对象。
cost(s,c):用于评估继续部分c在调度器对象s的等待队列中的布局。
find-best-within(s):返回存储在调度器对象s的等待队列中的继续部分的成本函数。
conserve-energy:进入低功率模式。
resume-continuation(c):在那时执行此函数的处理器中恢复通过c表示的计算。
valid(i):当且仅当中断i仍然有效时才返回真的布尔函数。
initialize(best-guess):初始化成本可变最佳猜测。
insert-queue(s,c):将继续部分c插入到调度器对象s的等待队列中。
return-from-virtual-interrupt:恢复由于中断而暂时暂停的执行。
r.owner:返回资源r所位于的节点。
r.e:资源r正在等待这个事件。
e.r:这个事件是针对资源r的。
e.continuation:当发生这个事件时,需要恢复继续部分。
get-state():返回处理器的状态。
scheduler-object(p):返回当前与处理器p相关联的调度器对象。
on-request-transfer-response(r,m,response):对从节点m转移资源r的请求做出响应。响应在“拒绝”的情况下可以为真,或者在“接受”的情况下为假。
示例例行程序
下列的是在各种实施例中使用的例行程序的伪代码示例。在下文中,以“on-”开始的函数是异步事件或消息进入。
==========================
init-continuation(computational-state)
==========================
/* 通过处理器p按提示h等待资源r进行InitContinuation */
c = 分配继续部分
c.state = computational-state
c.last = scheduler-object(p)
c.state = waiting-for-event
c.hints = h
e = 分配事件表中的事件
e.resource = r
e.continuation = c
return c
end InitContinuation
==========================
assignProcessor
==========================
/* 一旦物理节点n中的处理器p变成影子处理器,它就放弃其O/S身份并且开始寻找要恢复执行所需的继续部分。P将在等待队列中寻找这种继续部分如下:*/
s = scheduler-object(p)
initialize(best-guess)
best-s = nil
/* 向上遍历,追踪最佳候选 */
/* 假定存在根的在本地缓存的副本 */
repeat
guss = cost(s)
if guess > best-guess
then
best-guess = guess
best-s = s
s = parent(s)
until s = nil
if best-s <> nil
then
c = find-best-within(best-s)
resume-continuation(c)
else conserve-energy
end assignProcessor
==========================
On-stall(r)
==========================
/* 当硬件检测到虚拟配置与物理配置之间的不一致时调用OnStall。更具体地,节点n请求硬件不能在节点n上找到的资源r。*/
if migration-continuation(r)
then
/* 将计算发送到节点n */
nn = owner(r)
/* 节点n认为资源可能在节点nn处 */
migrate-computation(r,nn)
else
/* 请求资源r */
c = init-continuation(get-state())
/* 在这里插入代码以将c插入到本地事件表中 */
request-resource(r, owner(r))
assignProcessor /* 这时,p是匿名影子处理器 */
/* p需要找到要做的某个工作 */
end OnStall
==========================
on-migrate-computation(computational-state,r,n)
==========================
/* 远程节点从n得到消息以接收继续部分。注意:c在这种情况下是继续部分的内容,而不是继续部分它本身。*/
c = InitContinuation /* 具有请求中的信息 */
c.state = computational-state
e = 将c插入到本地事件表中
handle-event(e)
end on-migrate-computation
==========================
on-interrupt(i)
==========================
/* 当处理器p(在物理节点n的子树中)被i (使用特定于特定硬件设计的非常低级机制)中断时,p做下列的:*/
while valid(i)
e = event-table(i) /* 找到与i相对应的事件 */
handle-event(e)
i = 下一个排队中断
end while
/* 恢复在先的执行 */
从虚拟中断返回
end on-interrupt
==========================
handle-event(e)
==========================
/* 发生了事件。将它从事件表移动到最佳调度器对象。*/
c = e.continuation /* 找到事件e的继续部分 */
event-table(i).clear = true /* 从表中移除事件 */
e.complete = true /* 将e标记为完成 */
c.state = ready
/* 现在找出要放置c的最佳地方 */
s = c.last
initialize(best-guess)
/* 寻找最佳选择 */
/* 假定存在根的在本地缓存的副本 */
repeat
guess = cost(s,c)
if guess > best-guess
then
best-guess = guess
best-s = s
s = parent(s)
until s = nil
insert-queue(best-s,c) /* 使c向上排队在best-s的等待队列中 */
end handle-event
==========================
request-resource(r,n)
==========================
/* 当节点n需要节点n’拥有的资源r时该资源被请求,但是可能不满足该请求,因为某人可能已击败你请求它或者n’当前正在使用它。*/
current-resource-map(r).wanted = true
request-transfer(owner(r),r) /* 向r的所有者发送请求 */
/* 请求r的转移 */
return
==========================
on-request-transfer-response(r, m, is-rejected)
==========================
/* 现在,考虑你是一个节点,从节点对资源r的前一个请求获取响应。当对这个请求的响应进入时,它可被接受或者拒绝。*/
if 被拒绝
then /* 资源已被转移到m */
递增k
if k > 阈值
then
/* 你不想永远追逐 */
/* 设法得到资源。放弃 */
migrate-computation(r,m)
return
else
request-transfer(r,m) /* 再次尝试 */
return
else
/* 请求未被拒绝并且r是资源 */
r.k = 0
r.wanted = false /* 资源已被移动 */
r.owner = me /* 将所有者设置为n (即,“me”) */
if 资源是存储器,
用新的存储器更新硬件存储器图
return
==========================
on-transfer-requested(r,n)
==========================
/* 当对r的资源请求来自节点n时,如果正在转移到owner(r),则拒绝请求 */
if r.being-transferred
then
send-request-response(r, owner(r), true)
else
/* 资源的转移被接受 */
r.transferring = true
initiate-send-resource(r)
if type(r) = 存储器
then 更新本地存储器图
send-request-response(r, owner(r), false)
return
==========================
on-resource-transferred(r,n)
==========================
/* 当转移完成的确认进入时 */
r.owner = n
r.transferring = false
return
==========================
on-receive-resource(r,n)
==========================
/* 现在我们从n随着所请求的资源r接收消息 */
r.k = 0
r.wanted = false /* 清除宣称这是想要的比特 */
r.owner = me /* 将所有者设置为n (即,“me”) */
if 资源是存储器,
用新的存储器更新存储器图
send-resource-transferred(r,n)
handle-event(r.e) /*我们一直在等待的事件已经发生 */
return。
使用选择性资源迁移的网络附连存储器
上面描述的是一系列紧耦合的服务器集群(在本文中也称为“TidalPod”)共享一组聚合资源的硬件和软件架构的示例实施例。这些资源包括若干类型,诸如处理器、动态存储器、储存器和网络。在这种系统中通过超内核对这些资源的聚合允许构建横跨节点集并且对于操作系统而言和对于应用而言似乎为单个大型服务器的虚拟机。
本文中所描述的是用于通过超内核来扩展资源的聚合以包括诸如闪速存储器、PCM (相变存储器)、3D-XPoint、硬盘驱动器等之类的存储器技术的技术。虽然在下面描述了涉及闪速存储器的示例实施例,然而本文中所描述的技术可酌情不同地被适配成适应任何类型的存储器技术。
在一个示例实施例中,闪速存储器被组织为字节的物理阵列。这个阵列的每个字节对应于通过在集群的每个服务器(在本文中也称为“节点”)上运行的超内核的集合所创建的虚拟机中的物理存储器地址。
通常,以两种主要方式使用闪速存储器:作为固态磁盘(SSD)或作为诸如移动电话和平板之类的便携式电子设备中的持久存储器。服务器中的闪存的一个示例主用法是为了模拟磁盘。本文中所描述的是提供使用闪存的附加方式的技术,例如,作为持久备份存储器以(a)通过扩展由客户操作系统感知的存储器的大小超出集群的可用动态存储器的总数的大小来使大存储器可供由应用和数据库使用并且(b)作为使系统在存在错误的情况下变得更有弹性的方式。
遗憾的是,用于服务器的大多数系统软件通常没有用于将闪存有效地处理为存储器层次结构的第一类元素的机制,并且结果,这个软件诉诸于以它很好地理解的方式使用它,即磁盘存储。
示例用例
下列的是通过本文中所描述的技术支持的若干示例用例:
1. 考虑例如具有5 TB的主存储器的软件定义服务器,并且考虑10TB的闪速存储器阵列。在一个示例实施例中,服务器被配置成具有10 TB的主存储器,并且将5 TB的主存储器配置为10 TB的闪速存储器的新高速缓存。这种高速缓存的使用使系统加速。
2. 在替代实施例中,可以使用闪速存储器阵列好像它对于总共15 TB的主存储器来说为附加主存储器。
3. 在另一示例实施例中,闪速存储器可用于实现持久参考存储器。例如,如果系统检测到即将发生的故障,则闪速存储器的内容可以用它尚不拥有的主存储器的最近页面来更新。以这种方式,当系统重新启动时,可使用持久存储器来帮助使系统恢复到先前保存的状态(例如,类似于当膝上型电脑挂起/恢复时所做的事情)。因此,可将主存储器备份到持久储存器,使得可在崩溃、错误或其他故障的情况下容易地重新启动系统。
例如,通常,在故障(例如,检测到电源故障或系统崩溃)的情况下,为易失性的(例如,当电源被移除时易失性存储器的内容丢失)诸如DRAM(动态随机存取存储器)之类的动态存储器的快照被取得并被写入到磁盘。这可使用本文中所描述的技术来避免,因为参考副本可被存储或者刷新到包括诸如闪速存储器之类的持久(例如,静态、非易失性)存储器的网络附连存储器。将在下面更详细地描述有关网络附连存储器的细节。
4. 在另一示例实施例中,本文中所描述的技术可以用于保存节点的状态并用不同节点替换它。由于各种原因可以做这个,所述原因诸如节点的升级、替换故障节点等。
存储器层次结构
在上面所呈现的示例架构中,大“物理”地址空间被呈现给客户操作系统。从集群中的每个节点的角度看,存在如由其客户物理地址被该节点上的处理器直接地寻址的操作系统所看到的“客户物理”地址空间中的地址。在一些实施例中,如果由处理器请求的客户物理地址不存在于该节点上,则通过硬件产生存储器访问故障,并且(a)包含该地址的存储器被移动或者复制到处理器所位于的节点,或者(b)客户处理器正在执行的计算(即,表示客户处理器的虚拟处理器)被移动到客户物理存储器所位于的节点。在上面描述了使用超内核的资源迁移机制和技术的示例。这两种策略中的任何一种一旦完成,就使得计算能够可用于被调度,并且一旦被调度,就最终开始再次运行,好像存储器访问故障从未发生过一样。
在一些实施例中,在这个模型中,在任何给定时间,“客户物理”存储器由系统中的至多一个节点拥有。其他节点可以具有这个存储器的副本,但是在一些实施例中,为了维护强高速缓存一致性,当客户处理器修改页面时,所有其他副本必须被标记为无效的,或者以其他方式遗忘。
在一些实施例中,系统中的动态存储器的每个页面可以是某个其他存储器(即供替换的闪速存储器或网络附连闪速存储器)的本地副本。这个闪速存储器可以集中地位于对集群中的所有节点可访问的闪存设备中,或者它可以分布在遍及集群的各部分中,在一个或多个节点上(例如,在包括一个或多个节点上的闪速存储器的PCI卡上)。
在不失一般性的情况下,闪速存储器的这种阵列在本文中被称为“网络附连存储器”。网络附连存储器(在本文中也称为“NAM”)本身可以由分布在集群的节点之中的一个以上存储器组组成。在各种实施例中,可使用诸如如上所述的PCM、3D-XPoint、硬盘驱动器等之类的存储器技术来实现网络附连存储器,同时酌情不同地适配本文中所描述的技术。在下面更详细地描述网络附连存储器的示例。
网络附连存储器可被用作TidalPod中的存储器的附加层。在一个示例实施例中,可将网络附连存储器认为是系统(例如,TidalPod)中的所有存储器的“真实”家。当以这种方式考虑或者使用或者配置网络附连存储器时,那么网络附连存储器的各部分可以暂时驻留在每个节点上,例如,在节点的动态存储器中。当以这种方式考虑时,在一些实施例中,每个节点中的存储器可被用作网络附连存储器的高速缓存。
在下面结合图14更详细地描述网络附连存储器设备的示例。
在各种实施例中,正常存储器层次结构因此被从仅在每个节点上仅具有高速缓存级扩展到跨越紧耦合的节点具有高速缓存级。
例如,由于集群的总动态存储器与被呈现给操作系统的虚拟机1:1对应(不一定是每个节点上的所有物理主存储器的总数)的示例要求,本文中所描述的技术在利用网络附连存储器时的一个示例结果是网络附连储存器的存储器可大大地扩展集群的可用动态存储器。
强高速缓存一致性
在一些实施例中,为让操作系统和应用适当地起作用,整个存储器层次结构必须是强高速缓存一致的。在典型的硬件中,处理器使用一级或多级硬件高速缓存来维护强高速缓存一致性。当在节点上存在多于一个处理器时,使用现有硬件,高速缓存一致性是经由诸如AMD的Hypertransport™或Intel的QuickPath Interconnect™之类的板上互连维护的。
然而,那些方案不会超出单个节点(即,具有处理器和存储器的节点)。本文中所描述的是使用上述的机制来实现类似效果的强一致性协议的软件版本。
在一些实施例中,当在操作系统的指导下运行的处理器向其本地存储器中的位置写入时,如果该存储器的副本被存储在该节点上的处理器的硬件高速缓存中,则处理器必须协作以维护本地高速缓存的强一致性。
使用上述的技术(例如,上述的超内核),可采取类似动作。例如,当在客户操作系统的指导下运行的客户虚拟处理器向它认为是其本地存储器的位置写入时,如果该存储器在节点的动态存储器中,则必须当心以确保具有该存储器的本地副本的任何其他节点使其本地副本无效,使得在客户虚拟机中一个真实副本被维护在仅一个地方中。当存储器被扩展到网络附连存储器时,相同的写入应该具有相同的效果。
到和来自网络附连存储器的迁移
本文中所描述的是如何在存在网络附连存储器的情况下维护强高速缓存一致性的概要。在下面对附加细节进行描述。
在一些实施例中,当节点上的计算试图从在另一节点上存储和拥有的位置读取时,诸如上述的那些资源迁移算法之类的资源迁移算法被执行以通过移动计算或者移动存储器来确保计算和存储器共同驻留在相同节点上。
在下面描述用于扩展资源迁移以并入网络附连存储器闪存设备的技术。
在一些实施例中,包含存储器的TidalPod中的节点集被扩展以包括闪存设备。闪存设备被视为系统中的另一不同的资源类型。除了在一些实施例中,闪存设备不具有可对计算进行调度的任何虚拟处理器,它可被认为与其他节点类似。在一些实施例中,网络附连存储器设备不从任何虚拟处理器开始,并且从不接受来自TidalPod中的其他节点的任何虚拟处理器。
图13A图示了在选择性资源迁移中使用网络附连存储器的系统的示例实施例。在所示的示例中,TidalPod 1302的节点1304 (节点458-462的示例)与持久存储器阵列1306(网络附连存储器的示例)进行通信。在一些实施例中,节点和NAM一起形成TidalPod (其中NAM是TidalPod中的专用节点)。在一些实施例中,TidalPod的节点和NAM通过互连彼此通信(1308)。
在一个示例实施例中,如上所述,节点1304中的每一个包括主板(1310),其中该主板可以具有许多处理器,其中每个处理器可以具有许多核心,并且每个核心可以具有许多超线程。在一些实施例中,在TidalPod上运行的客户操作系统将每个超线程视为处理器。
在一些实施例中,网络附连存储器1306是存储器的阵列(1312) (例如,闪速存储器的字节)。如本文中所描述的,NAM也包括被配置成实现高速缓存一致性协议的处理器(1314)。多个NAM可以被用于冗余和/或弹性。在这个示例中,网络附连存储器设备1306集中地位于对集群中的所有节点可访问的闪存设备中。在其他实施例中,网络附连存储器可以分布在遍及集群的各部分中,在一个或多个节点上(其中跨越节点1304分布的NAM的各部分的示例被示出在1316-1322处)。
如上所述(例如,当执行存储器迁移时),使用本文中所描述的技术,可以将存储器的页面放置在NAM中,就像存储器的页面可被放置在系统中的任何节点上一样。在一些实施例中,网络附连存储器设备使用高速缓存一致性协议来通过互连与TidalPod中的其他节点进行通信,将在下面对所述高速缓存一致性协议进行更详细的描述。
图13B图示了在选择性资源迁移中使用网络附连存储器的系统的示例实施例。在这个示例中,节点1352和1354是节点1304和458-462的示例。如这个示例中所示,每个节点具有超内核。另外示出的是每个节点上的存储器或高速缓存层次结构的示例实施例,其包括L1、L2和L3高速缓存。每个节点也包括被用作L4高速缓存的DRAM。
如这个示例中所示,节点1352和1354彼此通信(例如,通过互连),例如,在彼此之间迁移资源。在这个示例中,节点也被配置成与持久存储器阵列1356进行通信,所述持久存储器阵列1356是网络附连存储器的示例。TidalPod的NAM和节点使用在本文中更详细地描述的高速缓存一致性协议来通信。
图14图示了网络附连存储器设备的示例实施例。NAM的一个示例实施方式如下。NAM (1402)包括在板上按照2D (二维)阵列布置的许多闪速存储器芯片(例如,存储器芯片1404)。在这个示例中,存储器芯片被按照存储体和行布置。存储器芯片连接在存储器总线(1406)上。存储器总线允许处理器(1408)向存储器控制器1410 (例如,指定存储体X、芯片Y、页面Z的地址)放出地址,所述存储器控制器1410然后被配置成从存储体/芯片的指定组合返回适当的页面。例如,存储器控制器取得芯片的总数,将它除以芯片上的页数,被除以行数等,以返回适当的页面。
在这个示例中,包括在NAM中的处理器是例如作为被配置或者编程为与TidalPod中的其他节点进行通信(例如,作为高速缓存一致性协议的一部分接收消息并提供响应)的特殊受限处理器、网络处理器或协议处理器而实现的协调器,将在下面对所述高速缓存一致性协议进行更详细的描述。在一些实施例中,消息包括在TidalPod的节点之间传送的确认、重试等。消息的一个示例是将节点n上的vcpu迁移到节点m的消息。在下面提供了用于这种消息的示例伪代码:
将这个VCPU “V”迁移到节点M。
快照V的状态(通常是存储器的少量页面(例如,〜6400个字节))。
发送具有包含状态V至M的适当数量的字节(例如,6400个字节)的“迁移”命令。
等待确认。
将在下面更详细地描述消息和示例消息结构的附加示例。在一些实施例中,包括在NAM中的处理器对客户操作系统不可见。
在这个示例中,NAM也包括元数据1412。在一些实施例中,元数据包括用于跟踪哪些页面处于什么状态的页面状态数据。在一些实施例中,页面状态数据指示页面的类型(例如,次级的)。在一些实施例中,NAM包括指示遍及TidalPod的各个节点上的页面的状态的元数据。例如,NAM上的页面的副本的状态通常是次级的。其他节点上的页面的副本可以是次级的、最初的(prime)或独占的(exclusive)。例如,当在故障转移场景中执行恢复时,可以使用这个信息来恢复TidalPod的状态(例如,以指示TidalPod中的第一节点上的页面的副本应该被标记为初级的(在本文中也称为“最初的”),而第二节点上的页面的另一副本应该被标记为次级的)。
在一些实施例中,NAM的所有页面最初是无效的(例如,在TidalPod启动时)。当页面被写入节点时,页面的副本根据在下面更详细地描述的页面/高速缓存一致性协议被发送到NAM。因此,随着时间的推移,当在TidalPod上创建和写入页面时,NAM维护被创建和写入的所有那些页面的最近副本(例如,动态存储器的副本)。
在一些实施例中,当大型存储器系统(例如,大型存储器Linux或FreeBSD系统)被启动时,通常执行页面的归零。对于大型存储器系统来说这个过程可能花费很长时间。在一些实施例中,使用本文中所描述的技术,可更快速地且更高效地执行页面的归零。例如,可并行地并且以“懒惰”方式执行归零。在一些实施例中,在系统中尚未被归零的页面被指示为“休眠”页面。在一些实施例中,这些休眠页面在它们第一次被使用(例如,被分配并且写入或者创建)之前不归零。可通过使用这种“并行懒惰归零”技术来快速地启动TidalPod系统。
在一些实施例中当TidalPod系统开始时,在休眠页面的第二级页面表(在下面更详细地描述)中没有条目,因为它们尚未被创建,并且因此尚不存在(即,休眠页面在它们被分配之前不具有任何物理表示)。在一些实施例中,当休眠页面被分配时,它被归零。条目然后被放置在第二级页面表中,这使页面变得有效且不休眠。
图15是图示了分配页面的实施例的图。该图可变地适用于动态存储器和网络附连存储器。在该示例中示出的是休眠页面(1502和1504)。当休眠页面被分配时,它被清零(例如,如1506处所示)。如上所述,条目然后被放置在第二级页面表中。当做出条目时,页面的物理地址被送入。在一些实施例中,也为页面送入模式比特。模式比特可指示页面是有效的、页面是可写的还是只读的等。
在一些实施例中,当诸如TidalPod之类的系统启动时,所有页面是空的(例如,休眠)。客户操作系统然后开始分配页面。例如,当页面被分配时,页面编号(例如,4567)被分配。在分配时,页面被清零,并且然后其地址被放入第二级页面表中(页面直到在它已被清零之后才可见)。现在,如果试图对作为4567为超内核所知的一些页面进行寻址,则将看到零的页面。
在一些实施例中,在分配之前,页面不存在。当具有许多节点和处理器的TidalPod被启动时,大多数页面在启动时间是休眠的。当页面被使用时,它们变得有效。这适用于动态存储器中以及NAM中的页面。
在一些实施例中,NAM中的页面的数量与客户操作系统观察到的页面的数量一致。页面的其他页面副本(例如,影子副本)可以存在(例如,在页面高速缓存中),但是,在一些实施例中,不会使它们对客户操作系统可见。在(一个或多个)超内核与NAM之间不需要一对一对应。然而,在一些实施例中,存在如由客户操作系统所看到的一对一对应。
在典型的操作系统中,操作系统在裸机上运行。如上所述,使用本文中所描述的技术,裸机被用分布式超内核替换,这给操作系统带来它正在裸机硬件上运行的印象。这通过二级页面表来支持,所述二级页面表存在于TidalPod中的节点上的处理器中。如果在存储器的页面的第二级页面表中没有条目,则当执行硬件地址转化时将发生故障。如上所述,例如基于成本函数,虚拟处理器可被移动到具有存储器的页面,或者存储器可被移动到虚拟处理器驻留在的地方。在一些实施例中,当存储器被移动时,不仅存储器的内容被复制,而且目的地(节点)处的第二级页面表也被更新。因此,当节点上的进程试图访问页面时,将不发生另一故障。这为客户操作系统提供单个大地址空间的表象,所述单个大地址空间不存在于硬件中,而是使用本文中所描述的技术来用软件加以定义和支持。如果对页面的请求被拒绝(例如,基于进入成本函数中的消息),则处理器移动到页面的位置(或者虚拟进程和页面两者被移动到另一节点—即,后置条件,他们共同驻留)。
在一些实施例中,当页面被请求时,该页面是从其主要位置请求的。该页面然后被标记为次级的,而发送到请求节点的页面在请求节点上被标记为独占的或最初的。
考虑以下示例。假设出于说明性目的TidalPod包括集中式网络附连存储器以及两个节点:节点1和节点2。在一些实施例中,当做出要使节点1请求转移其最新副本在节点2上的存储器(即,存储器的页面)的战略决定时,节点2首先将该存储器的无效连同节点1最可能是可找到最新副本的地方或位置的指示一起发送到网络附连存储器,然后通过将该存储器的副本发送到节点1来满足节点1的请求。在一些实施例中,现在在节点1上的存储器像通过驻留在节点1上的各种计算所规定的那样被更新,并且然后当节点1必须向别处转移该存储器时,节点1也可以将网络附连存储器更新到可以找到该存储器的当前版本的地方。在一些实施例中,无论是否对NAM进行更新,系统(TidalPod)都继续工作或者起作用,因为系统的知识可能不完美。在一些情况下,由于异步性,可能需要“找出”并搜索存储器页面,因为它们可能不在它们预期所在的位置中(例如,根据资源图)。例如,在一个时间点,页面可能一直在给定位置处,但是当进行页面搜索时可能不再在那里。
如果另一节点需要该存储器(页面)的副本,则副本被发送到请求节点,并且该存储器的副本也被发送到网络附连存储器。
在一些实施例中,当在节点上修改存储器时,存储器变成为该节点所独占。在一些实施例中,所有其他副本必须变得无效,包括网络附连存储器上的任何副本。
在一些实施例中,在周期性基础上,网络附连存储器可以请求每一存储器页面的次要副本。在计划或非计划关闭时,如果有足够的时间,则在客户虚拟处理器被停止之后,网络附连存储器可以请求所有页面的独占所有权。
以这种方式,网络附连存储器总是包含足够近的副本以保存强一致性的语义。
状态转变和高速缓存一致性协议的描述
如上所述,网络附连存储器(“NAM”)可以是TidalScale Pod中的另一节点(集中式节点或者跨越pod中的其他节点分布),除了虚拟处理器(在本文中也称为“vcpu”)不可在它上启动,并且没有任何vcpu可以迁移到该节点。
在这个示例中,如果在NAM上不存在vcpu,则NAM在性质上是事务性的。在一些实施例中,除通过客户软件的执行定义的明确定义的同步点外(例如,“我需要这个页面以便进行计算并且在我得到它之前我不能进行计算”),不要求或者需要实时地使NAM的内容保持最新。因此,可以“懒惰”方式执行对NAM的读取和写入。只要按顺序满足对页面的请求和更新页面的请求,就可维护或者保存一致的冯诺依曼语义,而不必实时地执行。情况也可能是一些处理器系列具有必须满足的附加约束,例如,英特尔的“存储器存储顺序”约束。
在一些实施例中,用于请求页面、更新页面、迁移处理器、使页面的只读副本无效等的逻辑由vcpu的或内务处理线程处理。因为NAM没有那些,所以NAM不必担心这些操作。
现在描述事务结构的示例实施例。
任何节点上的页面可以是有效的或无效的。页面的有效性/无效性指代在节点上的某个页面表中是否存在该页面的条目。如果它们是有效的,则它们对应于客户操作系统认为是物理地址的地址,但是当由超内核查看时实际上是客户虚拟地址。
驻留在节点n上的有效的页面p可以处于若干状态中的一种:最初的(或初级的)或独占的或次级的。
1. 如果p被标记为最初的,则它是“只读的”并且n被说成“拥有”p。
2. 除n以外的节点可以具有被标记或者称作次级页面的p的副本。在一些实施例中,如果存在次级的页面,则可有效地假定在TidalPod中别处存在最初页面。类似地,如果节点具有最初页面,则可以假定在TidalPod中别处存在页面的次级页面。在一些实施例中,次级页面的数量被最大化,使得当做出读取那些页面的尝试时,页面数据已经驻留在请求节点上,从而使访问页面数据花费的时间最小化。
可能期望其中次级页面的一个示例是当处理保持操作系统(例如,客户操作系统)的代码的一组页面时。因为用于操作系统的代码是恒定的并且不改变,所以如果运行操作系统的处理器将为操作系统预取页面将是效率低的(因为这在处理器正在等待所请求的页面的同时可以导致停止)。替代地,为了提高效率并减少停止,可使用次级页面,其中操作系统的许多页面被尽可能复制。通过减少停止,系统的开销也减少,从而导致系统效率提高。
对于其他种类的程序(诸如具有只读数据的那些程序(其中只读数据的页面被作为次级页面复制到只读节点))可执行类似的优化和效率。在一些实施例中,在操作系统或应用的作为存储器的只读页面的代码页面之间不做区分。
作为另一示例,可使用具有不经常改变的大量数据的次级页面。如果存储器可用于这样做,则可尽可能复制尽量多的只读数据以提高效率并减少停止。
3. 如果p被标记为在n上独占,则该页面仅可存在于n上,不能存在其他副本上,并且可读取和写入该页面(“读写”)。在这种情况下,对于p来说不存在次级页面。
在一些实施例中,在使页面成为独占的之前,无效操作被执行来使页面的所有其他现有副本无效。这可用于在现有架构中保证评估顺序。可通过向所有其他节点发送请求它们使其页面的副本无效的消息来执行无效操作。当接收到对那些请求的响应(例如,确认)时,所有那些响应的接收指示不存在该页面存在于的其他位置。客户操作系统然后可再次启动并写入到页面。当写入完成时,其他页面可能想要具有页面的副本,并且在一些实施例中,可拍摄并使用页面的快照来为该页面创建具有更新信息的新次级页面。因此,通过使用次级页面,对客户操作系统而言将似乎是这些页面是本地的。
当节点m (m≠n)上的vcpu请求从n访问p时,如果该页面是最初的或独占的,则当前在n上的页面p被标记为无效,并且该页面的副本然后被发送到将p标记为最初的m。在一些实施例中,作为优化,如果节点m上的vcpu知道那是所需要的,则节点m上的vcpu可以将页面p标记为独占的。
在一些实施例中,如果节点具有为最初的或独占的页面,则当它接收到向该页面发送最初的或独占的写入的请求时,它在该节点上被转换为次级页面。写入该页面的权限然后被转移到正在请求页面的节点。这是可以基于除非节点即将写入到页面否则节点将不在请求页面的假定来执行的优化。这节约协议中必须被执行的事务,从而提高效率。
在一些实施例中,如果节点m请求从n访问p,则节点n将其p的副本标记为次级的。页面p然后被发送到节点m。如果节点m将其p的副本标记为独占的或最初的,则页面p的节点n的副本无效。
在一些实施例中,如果节点n上的页面p是最初的并且将被写入,则必须使所有次级副本变得无效,并且仅在接收到这个已完成的确认之后,n将p标记为独占的。例如,在一些实施例中,在知道节点n是唯一写入者之前页面不能被写入—也就是说,在页面处于独占状态之前页面不能被写入,其中在已经接收到指示不存在其他次级页面(即,所有次级页面已无效)的所有确认之前页面不能处于独占状态。在一些示例实施方式中,可对这个进行优化。例如,对此页面来说为初级的节点可发起无效。在一些实施例中,无效包括应该将确认发送到请求者(谁将变成初级页面)而不是到当前初级页面的指令。在一些实施例中,请求者在页面可被访问之前必须收集所有确认。以这种方式,无效可安全地与页面的转移并行地进行。总之,在这个示例优化中,初级页面发起无效,但是请求者完成无效过程。
下列的是有关无效的附加细节。在一些实施例中,TidalPod包括第一级页面表,其执行从用户空间(例如,在用户空间中运行的客户程序)到客户操作系统认为是其物理空间的内容的硬件转化(即,第一级页面表映射将虚拟地址转化成客户OS认为是物理地址的内容)。如上所述,客户OS认为是物理地址的内容是由超内核管理的客户物理地址(例如,超内核主机地址),其然后通过硬件中(例如,经由第二级页面表)的另一级页面地址转化,其中客户物理地址被转换或者转化成页面的真实物理地址。在一些实施例中,页面通过从第二级页面表中擦除它而无效。然后可运行垃圾收集,或者存储器可被返回到空闲池等,因为节点不再能访问存储器的无效的页面。
此后,对标记为独占的页面的所有写入操作将不产生任何停止,因为它们在节点上可在本地被读取和写入,并且不存在其他副本(例如,通过从第二级页面表中擦除它们而无效的页面,如上所述)。
在一些实施例中,NAM遵守上述的相同协议。与TidalPod中的任何其他节点一样,NAM也具有有效的和无效的页面。例如:
1. NAM中的所有页面开始为无效的。在一些实施例中,如果页面变得有效,则它被标记为次级的,因为NAM上的页面不能被写入(只读)。
2. 在节点n上的vcpu v写入到页面之前它必须使P在别处的所有副本(包括NAM)无效。因此,如果NAM具有p的次级页面,则必须在NAM上使p变得无效,并且发送它在p可被更新之前已变得无效的确认,就像具有p的副本的任何其他节点必须做的那样。
3. 如果节点n对来自节点m (m≠n)的读取请求做出响应,则对于页面p,其中p被标记为初级的或独占的,n将p标记为次级的,并且将页面p发送到m,而且在(大致)相同的时间,n也将它发送到NAM,其将它标记为有效的和次级的。因此,在一些实施例中,如果节点将页面标记为独占的或初级的,则页面的副本被发送到网络附连存储器(并且标记为次级的),使得网络附连存储器具有该页面的有效副本(即,如果节点具有页面的最初副本(例如,在写入到页面之后),则NAM将具有在写入之后有效的次级副本)。在页面被m接收之后,m将页面标记为初级的。如之前一样,如果页面像将针对远程写入请求的情况的那样从初级的转换为独占的,则必须使NAM上的次级副本变得无效。如果提前知道页面将被标记为独占的,则可跳过将页面发送到NAM的步骤(因为它无论如何最终将被无效)。
以这种方式,NAM随着时间的推移变成TidalPod中的所有有效的页面的副本的合集。在一些实施例中,每当页面被更新时,对网络附连存储器进行更新。因此,随着时间的推移,在一段静止之后,网络附连存储器将具有TidalPod中的每一页面的有效副本。因此,即使系统断电,存储器的映像也将驻留在NAM中。作为另一示例,当引导时,如果未执行干净的关闭,则可以使用存储器的快照来帮助恢复系统在关闭之前的先前状态。
最后,对TidalPod中的NAM的数量没有限制。例如,在系统中可以存在多个NAM (例如,用于弹性和/或冗余)。在一些实施例中,可在不同的TidalPods之间共享若干网络附连存储器。作为一个示例,可为了弹性和/或冗余拔掉并复制NAM设备。
例如,当数据被从储存器中拉出(例如,从文件中提取)时,它可以被变换成可由将对数据进行操作的应用或数据库使用的本地表示。在一个示例用例中,一旦数据已被变换并且被复制到NAM,该NAM就可被拔掉并移动到另一TidalPod。因此,经变换的数据可立即被其他TidalPod使用,从而节约首先变换原始数据的昂贵成本。例如,数据的初始加载(例如,从数据库、通过互联网流式传输、从磁盘读取等)尤其对非常大的文件来说可能是昂贵的,因为所述数据然后必须被变换为可由在TidalPod上运行的需要该数据的应用使用。可使用上述的步骤来跳过这个初始加载/变换(例如,仅需要被执行一次,其中可通过移动NAM来将经变换的数据复制或者移动到其他系统)。
示例状态转换
下列的是示例状态转换的表:
表1。
在表1的上述示例中,当接收到对独占页面的读取请求时,该页面被发送到请求者并且页面(在接收到读取请求的节点上)的状态被转换为无效。在一些实施例中,到无效的转换考虑如上所述的优化,其中假定了已被请求的页面将被写入,并且接收到请求的节点上的页面无论如何将最终需要被无效。在其他实施例中,响应于接收到读取请求,接收到该读取请求的节点将页面的状态从独占的转变为次级的。
在一些实施例中,TidalPod的所有节点(包括NAM)遵守本文中所描述的高速缓存一致性协议的上述示例状态转换图。在不执行计算(例如,在其保持的页面上写入)的NAM的情况下,NAM遵守与被动操作相关联的转换的子集。
示例消息
下列的是在上述的节点间高速缓存一致性协议中使用的消息的示例:
在一些实施例中,每个子系统具有它自己的消息类型。下列的是TidalPod中的子系统(例如,调度器子系统、I/O子系统、迁移子系统等)的示例:
TS_NET_SCHEDULER,
TS_NET_MEMORY,
TS_NET_IO,
TS_NET_MIGRATION,
TS_NET_REMOTE,
TS_NET_REMOTE_INIT,
TS_NET_IOAPIC,
TS_NET_CONTROL,
TS_NET_BENCHMARK,
TS_PAGE_BENCHMARK,
TS_SYNC_CLOCK,
TS_NET_MMIO,
在一些实施例中,TS_NET_MEMORY子系统具有以下示例消息类型:
VMEM_UNKNOWN = 0,
VMEM_BUILD_GCPP = 1,// 节点要构建其cpp (一致性页面协议)的消息。
VMEM_BUILD_COMPLETE = 2,// 构建完成的消息
VMEM_MOVE_OWNER = 3,// 将页面从所有者承载到所有者的消息
VMEM_COMPLETE_PAGE = 4,// 用于发信号通知页面状态改变完成的消息
VMEM_OK2SEND = 5,// 用于广播页面的可用空间的消息
VMEM_COLLECT_PAGE_BCST = 6,// 在隔离协议(收集消息被广播的路径)中使用的消息。
GTHREAD_COLLECT_BCST = 7,// 用于收集客户线程元数据的消息
GTHREAD_COLLECT_BCST_ACK = 8,// 用于对客户线程收集消息做出响应的消息。
示例场景
图16图示了根据诸如上述的高速缓存一致性协议之类的高速缓存一致性协议(例如,根据以上表1中的状态转换)的节点间通信的示例实施例。
在这个示例中,假设TidalPod包括节点N0 (1602)、N1 (1604)和N2 (1606)以及NAM1608。
在初始状态1610中,节点N2具有页面p的初级版本(用“P”指示)。节点N1包括页面p的次级副本(用“S”指示)。节点N0不具有页面p的副本(例如,无效的,如通过“X”指示)。NAM1608可以包括页面p的次级副本(例如,系统已在使用中并且NAM具有页面p的参考副本),或者页面在NAM上(例如,在启动时)可以是无效的。
在下一个步骤1612中,节点N0希望执行页面p的本地读取。因为它不具有页面p的有效副本,所以它从具有页面p的初级副本的节点(在这种情况下,节点N2)执行对页面的远程读取请求(例如,基于资源图)。
响应于远程读取请求,节点N2将其页面p的副本标记为次级的(从初级的转换为次级的),并且将页面p发送到节点N0。节点N2也将页面p发送到NAM,所述NAM将其接收到的页面p的副本(例如,快照)标记为有效的和次级的。在节点N0接收到页面p之后,节点N0将其页面p的副本标记为初级的。
在一些实施例中,节点N0接收被标记为次级的页面p的副本。在其他实施例中,并且如这个示例中所示,为了使事务(例如,正在节点之间传送的消息)的数量最小化,在节点N0正在按写入页面的意图而请求它的假定下,节点N0将其p的副本直接地标记为初级的。节点N2上的页面p然后被标记为次级的。如果页面p在NAM上是无效的,则页面p也被发送到NAM,在那里它被标记为次级的。如果页面存在于NAM上,则它仍然是次级的。节点N1上的页面p的副本仍然是次级的。
在下一个步骤1614中,节点N0执行到其页面p的初级副本中的本地写入。在节点N0可写入或者更新其页面p的副本之前,页面p的所有次级副本都变得无效。例如,无效消息被发送到N1、N2和NAM (即,在TidalPod中具有p的次级页面的其他节点被请求使其页面p的副本无效)。在节点N0接收到来自N1、N2和NAM的指示它们已使其p的副本无效(即,在TidalPod中不存在p的其他副本)的确认之后,其中那些节点上的无效通过符号“X”来指示,节点N0然后可将其页面p的副本标记为独占的(例如,从初级的转换为独占的)并且写入其页面p的副本。
在以上示例中,节点N0首先在1612处执行远程读取请求,然后在1614处随后执行本地写入。如果提前知道节点N0上的页面将被标记为独占的(例如,与远程写入请求类似),则可以跳过在1612中从节点N2将页面p发送到NAM的步骤。
现在假设在1616处N1试图执行页面p的本地读取。然而,其页面p的副本是无效的。节点N1然后从节点N0请求页面p。响应于远程读取请求,节点N0将其页面p的副本转换为次级的(或者在一些实施例中,如果预期请求者写入p则使其页面p的独占副本无效),并且将页面p发送到节点N1。节点N1将其接收到的页面p的副本标记为初级的。节点N0也将页面p的副本发送到NAM,所述NAM将其页面p的副本标记为有效的和次级的。
如以上示例中所示,页面可以在TidalPod的不同的节点上处于不同的状态。在一些实施例中,并行数据结构用于维护关于TidalPod中的各个节点上的页面的状态的元数据。在一些实施例中,该结构被维护为使得不必执行跨越TidalPod中的节点的页面的状态的重新计算。
在这个示例实施例中,NAM是被动的,并且未被配置成请求页面并写入它们。NAM随着时间的推移而建立一组次级页面。如果节点试图写入页面,则NAM上的副本变得无效。
在一些实施例中,使用高速缓存一致性协议来向NAM通知从初级的或独占的到次级的任何转换(即,NAM在那些转换上被复制)。因此,NAM在页面从为独占的或最初的转换为次级的任何时间被更新。如果节点N上的页面p变成次级的,则NAM上的页面也必须被更新以变成次级页面。因此,NAM保存它认为是有效的一组页面的状态,并且在一些实施例中,NAM具有TidalPod的官方存储器的“最终”参考副本(或近似)。
在一些实施例中,如果检测到TidalPod正发生故障或者崩溃,则NAM对在NAM上将被标记为次级的、NAM尚不具有的TidalPod中的所有初级页面的副本做出读取请求。给定足够的时间,这将导致NAM具有TidalPod中的节点上的页面的所有次级副本(并且变成例如“最终参考副本”)。作为一个示例,假设检测到故障或错误。NAM搜遍其所有页面以确定哪些页面是无效的。NAM试图通过对来自TidalPod中的其他节点的那些页面的副本做出读取请求来使它们变得有效。如果副本是从其他节点获得的,则NAM用所获得的页面的副本来更新其无效的页面,其然后在NAM上变成有效的和次级的。
在一些实施例中,NAM包括后备系统,诸如在主板上允许NAM例如在系统关闭或断电期间继续起作用的电池。这给NAM提供了请求TidalPod中的其他节点上的页面的次级副本(从无效的页面转换为有效的次级页面)的时间。这允许NAM在故障情形下使它本身完整。
图17是图示了用于在存在网络附连存储器的情况下维护高速缓存一致性的过程的实施例的流程图。在一些实施例中,过程1700由诸如网络附连存储器设备1306之类的网络附连存储器执行。在一些实施例中,根据诸如上述的高速缓存一致性协议之类的高速缓存一致性协议来执行过程1700。当在网络附连存储器处接收到消息时,过程在1702处开始。基于要对节点(例如,TidalPod)上的页面执行的操作接收消息。在一些实施例中,节点被包括在网络附连存储器与之进行通信的多个节点中。在一些实施例中,通过在TidalPod中的每个节点上运行的一组超内核来创建虚拟机。然后可以在多个物理节点上共同地运行操作系统。在一些实施例中,(客户)操作系统被透明地运行。例如,如上所述,通过使用超内核,操作系统被给予这样的印象,即它正在裸机硬件上运行(当像在TidalPod中一样在多个物理节点上共同地运行时),其中不必对操作系统做出修改。
如上所述,在一些实施例中,网络附连存储器被组织为字节的物理阵列。在一些实施例中,阵列的每个字节对应于虚拟机中的物理存储器地址。
在一些实施例中,网络附连存储器是集中式设备。在其他实施例中,网络附连存储器跨越TidalPod中的节点分布。在1704处,由网络附连存储器基于所接收到的消息执行动作。
如上所述,在各种实施例中,可对节点上的存储器的页面执行的操作包括读取和写入(其可以是本地的或远程的)。基于要执行的操作的类型,可发出不同类型的消息。
例如,如果操作是写入页面的请求,则无效请求(1702处的消息的示例)被发送到其他节点以及网络附连存储器并且由它们接收以使其要写入的页面的副本无效。网络附连存储器被配置成然后使其页面的副本无效。网络附连存储器也被配置成返回指示其页面的副本现在无效的确认。写入操作然后可在接收到对无效请求的确认之后继续进行。
如果操作例如是来自节点的读取页面的远程请求,则该页面(例如,该页面的副本或快照,其中1702处的消息包括该页面的副本)被发送到请求节点以及网络附连存储器。网络附连存储器然后用页面的副本来更新(例如,网络附连存储器在1704处存储页面的副本)。
在上面结合表1描述了操作、动作和页面状态转换的其他示例。
图18是图示用于使页面归零的过程的实施例的流程图。在各种实施例中,过程1800由包括在TidalPod中的节点和/或网络附连存储器执行。当接收到分配休眠页面的指示时过程在1802处开始。在一些实施例中,休眠页面是仍然尚未被归零的存储器的页面。在各种实施例中,存储器的页面包括DRAM (例如,在TidalPod中的节点上)中的页面、闪速存储器(例如,网络附连存储器中的非易失性存储器)中的页面或存储器的任何其他适当的页面。在1804处,分配休眠页面。在1806处,所分配的休眠页面然后被归零。在一些实施例中,休眠页面的归零与休眠页面的分配并行地执行。然后可以将条目放置在第二级页面表中,其中页面变得有效且非休眠。如上所述,通过使用休眠页面(其中页面可被标记为休眠),在分配之后(或者在分配时/与分配并行地)执行归零提高系统的启动速度,因为归零不是在启动时完成的,而是在页面被使用时以“懒惰”方式完成的。
上面所描述的是用于将网络附连存储器(例如,闪存设备)附连到紧耦合的节点集群的技术,其中集群的总存储器表示支持强存储器一致性的虚拟机的存储器。在一些实施例中,如上所述,集群内的网络附连存储器是虚拟机的参考存储器。
尽管已经出于理解的清楚的目的详细地描述了前面的实施例,然而本发明不限于所提供的细节。存在实现本发明的许多替代方式。所公开的实施例是说明性的而非限制性的。
Claims (9)
1.一种计算机系统,包括:
多个物理互连的计算节点,其中客户操作系统运行在虚拟环境上,所述虚拟环境由运行在至少一部分物理互连的计算节点上的一组超内核定义;
网络附连存储器,包括集中式设备,所述集中式设备包括物理存储器阵列,其中所述网络附连存储器根据一致性协议通过网络与物理互连的计算节点中的至少一些进行通信;
其中,响应于由第一计算节点向具有存储器的页面的初级副本的第二计算节点做出的远程读取请求,第二计算节点根据一致性协议:
将第二计算节点上的存储器的页面的副本从指定为初级副本转换为指定为次级副本;
执行将存储器的页面的副本到第一计算节点的第一传输,其中第一计算节点上的存储器的页面的副本被标记为初级的,并且其中随后至少部分基于被标记为初级的第一计算节点上的存储器的页面的副本从第一计算节点请求存储器的页面;以及
执行将存储器的页面的副本到集中式网络附连存储器的第二传输,其中网络附连存储器上的存储器的页面的副本被标记为有效的和次级的。
2.根据权利要求1所述的计算机系统,其中所述网络附连存储器中的物理存储器的各部分对应于虚拟环境中的客户物理地址,所述虚拟环境由在所述物理互连的计算节点的至少一部分上运行的一组超内核定义。
3.根据权利要求1所述的计算机系统,其中至少部分地基于对故障的检测,所述网络附连存储器从所述多个物理互连的计算节点中的计算节点请求一个或多个页面的副本。
4.根据权利要求3所述的计算机系统,其中请求副本的所述一个或多个页面包括被确定为在所述网络附连存储器上无效的页面。
5.根据权利要求4所述的计算机系统,其中所述网络附连存储器用请求的页面的对应获得的副本来更新无效的页面。
6.根据权利要求1所述的计算机系统,其中所述网络附连存储器包括闪速存储器、相变存储器和3D-Xpoint存储器中的至少一种。
7.根据权利要求1所述的计算机系统,其中所述网络附连存储器存储所述页面的只读副本。
8.一种方法,包括:
根据一致性协议,响应于由多个物理互连的计算节点中的第一计算节点向具有存储器的页面的初级副本的第二计算节点做出的远程读取请求:
由所述第二计算节点将第二计算节点上的存储器的页面的副本从指定为初级副本转换为指定为次级副本;
执行将存储器的页面的副本从第二计算节点到第一计算节点的第一传输,其中第一计算节点上的存储器的页面的副本被标记为初级的,并且其中随后至少部分基于被标记为初级的第一计算节点上的存储器的页面的副本从第一计算节点请求存储器的页面;以及
执行将存储器的页面的副本从第二计算节点到包括集中式设备的集中式网络附连存储器的第二传输,所述集中式设备包括物理存储器阵列,其中网络附连存储器上的存储器的页面的副本被标记为有效的和次级的;以及
其中客户操作系统运行在虚拟环境上,所述虚拟环境由运行在至少一部分物理互连的计算节点上的一组超内核定义,并且其中所述网络附连存储器根据一致性协议通过网络与物理互连的计算节点中的至少一些进行通信。
9.一种非暂时性计算机可读存储介质,存储计算机程序,所述计算机程序可由处理器执行以实现以下步骤:
根据一致性协议,响应于由多个物理互连的计算节点中的第一计算节点向具有存储器的页面的初级副本的第二计算节点做出的远程读取请求:
由所述第二计算节点将第二计算节点上的存储器的页面的副本从指定为初级副本转换为指定为次级副本;
执行将存储器的页面的副本从第二计算节点到第一计算节点的第一传输,其中第一计算节点上的存储器的页面的副本被标记为初级的,并且其中随后至少部分基于被标记为初级的第一计算节点上的存储器的页面的副本从第一计算节点请求存储器的页面;以及
执行将存储器的页面的副本从第二计算节点到包括集中式设备的集中式网络附连存储器的第二传输,所述集中式设备包括物理存储器阵列,其中网络附连存储器上的存储器的页面的副本被标记为有效的和次级的;以及
其中客户操作系统运行在虚拟环境上,所述虚拟环境由运行在至少一部分物理互连的计算节点上的一组超内核定义,并且其中所述网络附连存储器根据一致性协议通过网络与物理互连的计算节点中的至少一些进行通信。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562236076P | 2015-10-01 | 2015-10-01 | |
US62/236076 | 2015-10-01 | ||
US15/279,187 US11240334B2 (en) | 2015-10-01 | 2016-09-28 | Network attached memory using selective resource migration |
US15/279187 | 2016-09-28 | ||
PCT/US2016/054414 WO2017059054A1 (en) | 2015-10-01 | 2016-09-29 | Network attached memory using selective resource migration |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108292235A CN108292235A (zh) | 2018-07-17 |
CN108292235B true CN108292235B (zh) | 2021-11-16 |
Family
ID=58424292
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201680069485.7A Active CN108292235B (zh) | 2015-10-01 | 2016-09-29 | 使用选择性资源迁移的网络附连存储器 |
Country Status (6)
Country | Link |
---|---|
US (2) | US11240334B2 (zh) |
EP (1) | EP3356936B1 (zh) |
JP (1) | JP6652646B2 (zh) |
KR (1) | KR102051282B1 (zh) |
CN (1) | CN108292235B (zh) |
WO (1) | WO2017059054A1 (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11240334B2 (en) | 2015-10-01 | 2022-02-01 | TidalScale, Inc. | Network attached memory using selective resource migration |
JP6696252B2 (ja) * | 2016-03-24 | 2020-05-20 | 富士ゼロックス株式会社 | 通信プログラム、通信装置及び情報処理装置 |
US11023135B2 (en) | 2017-06-27 | 2021-06-01 | TidalScale, Inc. | Handling frequently accessed pages |
US10817347B2 (en) * | 2017-08-31 | 2020-10-27 | TidalScale, Inc. | Entanglement of pages and guest threads |
US10268630B1 (en) | 2017-10-24 | 2019-04-23 | Hewlett Packard Enterprise Development Lp | Noncoherent interprocessor communication remapping node controller |
US11175927B2 (en) | 2017-11-14 | 2021-11-16 | TidalScale, Inc. | Fast boot |
US11275600B2 (en) * | 2017-11-14 | 2022-03-15 | TidalScale, Inc. | Virtualized I/O |
US11263122B2 (en) * | 2019-04-09 | 2022-03-01 | Vmware, Inc. | Implementing fine grain data coherency of a shared memory region |
US20200356485A1 (en) * | 2019-05-09 | 2020-11-12 | International Business Machines Corporation | Executing multiple data requests of multiple-core processors |
US20210132979A1 (en) * | 2019-10-30 | 2021-05-06 | TidalScale, Inc. | Goal-directed software-defined numa working set management |
CN114610232A (zh) * | 2020-04-28 | 2022-06-10 | 华为技术有限公司 | 一种存储系统、内存管理方法和管理节点 |
KR102650571B1 (ko) * | 2020-11-12 | 2024-03-26 | 한국전자통신연구원 | 역가상화 환경용 혼성 메모리 관리 장치 및 방법 |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5247673A (en) * | 1989-12-04 | 1993-09-21 | Bull Hn Information Systems Italia S.P.A. | Multiprocessor system having distributed shared resources and dynamic global data replication |
EP0322117B1 (en) * | 1987-12-22 | 2001-01-10 | Sun Microsystems, Inc. | Multiprocessor digital data processing system |
US6804766B1 (en) * | 1997-11-12 | 2004-10-12 | Hewlett-Packard Development Company, L.P. | Method for managing pages of a designated memory object according to selected memory management policies |
CN1577294A (zh) * | 2003-06-25 | 2005-02-09 | 国际商业机器公司 | 具有多个一致性区域的多处理器计算机系统及其方法 |
US20050039180A1 (en) * | 2003-08-11 | 2005-02-17 | Scalemp Inc. | Cluster-based operating system-agnostic virtual computing system |
US20070094310A1 (en) * | 2005-10-21 | 2007-04-26 | Passey Aaron J | Systems and methods for accessing and updating distributed data |
US20070186054A1 (en) * | 2006-02-06 | 2007-08-09 | Kruckemyer David A | Distributed Cache Coherence at Scalable Requestor Filter Pipes that Accumulate Invalidation Acknowledgements from other Requestor Filter Pipes Using Ordering Messages from Central Snoop Tag |
US20100161908A1 (en) * | 2008-12-18 | 2010-06-24 | Lsi Corporation | Efficient Memory Allocation Across Multiple Accessing Systems |
US20100241785A1 (en) * | 2006-04-27 | 2010-09-23 | Vmware, Inc. | Management of host physical memory allocation to virtual machines with a balloon application |
US20110179229A1 (en) * | 2010-01-15 | 2011-07-21 | International Business Machines Corporation | Store-operate-coherence-on-value |
US20140244891A1 (en) * | 2013-02-26 | 2014-08-28 | Red Hat Israel, Ltd. | Providing Dynamic Topology Information in Virtualized Computing Environments |
Family Cites Families (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5109486A (en) | 1989-01-06 | 1992-04-28 | Motorola, Inc. | Distributed computer system with network and resource status monitoring |
US5991893A (en) | 1997-08-29 | 1999-11-23 | Hewlett-Packard Company | Virtually reliable shared memory |
US6799202B1 (en) | 1999-12-16 | 2004-09-28 | Hachiro Kawaii | Federated operating system for a server |
US20020129128A1 (en) | 2001-03-07 | 2002-09-12 | Stephen Gold | Aggregation of multiple headless computer entities into a single computer entity group |
US6675264B2 (en) * | 2001-05-07 | 2004-01-06 | International Business Machines Corporation | Method and apparatus for improving write performance in a cluster-based file system |
US7003631B2 (en) * | 2002-05-15 | 2006-02-21 | Broadcom Corporation | System having address-based intranode coherency and data-based internode coherency |
US7043623B2 (en) | 2003-01-22 | 2006-05-09 | Intelitrac, Inc. | Distributed memory computing environment and implementation thereof |
US20040249947A1 (en) | 2003-05-22 | 2004-12-09 | Hewlett-Packard Development Company, L.P. | Concurrent cluster environment |
JP3808058B2 (ja) | 2003-05-27 | 2006-08-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 複数のホストが圧縮データを記憶するメモリ・セクタの集合を共用できるようにするための装置 |
US20050044301A1 (en) | 2003-08-20 | 2005-02-24 | Vasilevsky Alexander David | Method and apparatus for providing virtual computing services |
US8776050B2 (en) | 2003-08-20 | 2014-07-08 | Oracle International Corporation | Distributed virtual machine monitor for managing multiple virtual resources across multiple physical nodes |
US8090914B2 (en) * | 2004-01-20 | 2012-01-03 | Hewlett-Packard Development Company, L.P. | System and method for creating ordering points |
US8621458B2 (en) | 2004-12-21 | 2013-12-31 | Microsoft Corporation | Systems and methods for exposing processor topology for virtual machines |
US9753754B2 (en) | 2004-12-22 | 2017-09-05 | Microsoft Technology Licensing, Llc | Enforcing deterministic execution of threads of guest operating systems running in a virtual machine hosted on a multiprocessor machine |
US8010485B1 (en) | 2005-10-20 | 2011-08-30 | American Megatrends, Inc. | Background movement of data between nodes in a storage cluster |
US7596654B1 (en) | 2006-01-26 | 2009-09-29 | Symantec Operating Corporation | Virtual machine spanning multiple computers |
US7802073B1 (en) | 2006-03-29 | 2010-09-21 | Oracle America, Inc. | Virtual core management |
US7783788B1 (en) | 2006-04-28 | 2010-08-24 | Huawei Technologies Co., Ltd. | Virtual input/output server |
US7613882B1 (en) | 2007-01-29 | 2009-11-03 | 3 Leaf Systems | Fast invalidation for cache coherency in distributed shared memory system |
US7715400B1 (en) | 2007-04-26 | 2010-05-11 | 3 Leaf Networks | Node identification for distributed shared memory system |
US20110004732A1 (en) | 2007-06-06 | 2011-01-06 | 3Leaf Networks, Inc. | DMA in Distributed Shared Memory System |
US7782869B1 (en) | 2007-11-29 | 2010-08-24 | Huawei Technologies Co., Ltd. | Network traffic control for virtual device interfaces |
US7711789B1 (en) | 2007-12-07 | 2010-05-04 | 3 Leaf Systems, Inc. | Quality of service in virtual computing environments |
US20110004729A1 (en) | 2007-12-19 | 2011-01-06 | 3Leaf Systems, Inc. | Block Caching for Cache-Coherent Distributed Shared Memory |
US9003006B2 (en) | 2011-03-14 | 2015-04-07 | Mash5 Technologies, Inc. | Intercloud application virtualization |
US8966172B2 (en) | 2011-11-15 | 2015-02-24 | Pavilion Data Systems, Inc. | Processor agnostic data storage in a PCIE based shared storage enviroment |
US10187452B2 (en) | 2012-08-23 | 2019-01-22 | TidalScale, Inc. | Hierarchical dynamic scheduling |
US8769105B2 (en) | 2012-09-14 | 2014-07-01 | Peaxy, Inc. | Software-defined network attachable storage system and method |
US9760596B2 (en) | 2013-05-13 | 2017-09-12 | Amazon Technologies, Inc. | Transaction ordering |
US9774401B1 (en) | 2013-07-15 | 2017-09-26 | Paul Borrill | Entangled links, transactions and trees for distributed computing systems |
US11016820B2 (en) | 2013-08-26 | 2021-05-25 | Vmware, Inc. | Load balancing of resources |
EP3042305A4 (en) | 2013-09-05 | 2017-04-05 | Tidalscale Inc. | Selective resource migration |
EP3042282A4 (en) | 2013-09-05 | 2017-04-26 | Tidalscale Inc. | Hierarchical dynamic scheduling |
US9489389B2 (en) | 2013-12-09 | 2016-11-08 | PernixData, Inc. | System and method for maintaining cache coherency |
US9372752B2 (en) | 2013-12-27 | 2016-06-21 | Intel Corporation | Assisted coherent shared memory |
US20150356125A1 (en) | 2014-06-06 | 2015-12-10 | Plexistor Ltd. | Method for data placement based on a file level operation |
US9565269B2 (en) | 2014-11-04 | 2017-02-07 | Pavilion Data Systems, Inc. | Non-volatile memory express over ethernet |
US9552233B1 (en) | 2015-09-10 | 2017-01-24 | Red Hat Israel, Ltd. | Virtual machine migration using free page hinting |
US11240334B2 (en) | 2015-10-01 | 2022-02-01 | TidalScale, Inc. | Network attached memory using selective resource migration |
-
2016
- 2016-09-28 US US15/279,187 patent/US11240334B2/en active Active
- 2016-09-29 CN CN201680069485.7A patent/CN108292235B/zh active Active
- 2016-09-29 WO PCT/US2016/054414 patent/WO2017059054A1/en active Application Filing
- 2016-09-29 EP EP16852582.2A patent/EP3356936B1/en active Active
- 2016-09-29 JP JP2018536697A patent/JP6652646B2/ja active Active
- 2016-09-29 KR KR1020187009083A patent/KR102051282B1/ko active IP Right Grant
-
2021
- 2021-12-08 US US17/545,730 patent/US20220174130A1/en active Pending
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0322117B1 (en) * | 1987-12-22 | 2001-01-10 | Sun Microsystems, Inc. | Multiprocessor digital data processing system |
US5247673A (en) * | 1989-12-04 | 1993-09-21 | Bull Hn Information Systems Italia S.P.A. | Multiprocessor system having distributed shared resources and dynamic global data replication |
US6804766B1 (en) * | 1997-11-12 | 2004-10-12 | Hewlett-Packard Development Company, L.P. | Method for managing pages of a designated memory object according to selected memory management policies |
CN1577294A (zh) * | 2003-06-25 | 2005-02-09 | 国际商业机器公司 | 具有多个一致性区域的多处理器计算机系统及其方法 |
US20050039180A1 (en) * | 2003-08-11 | 2005-02-17 | Scalemp Inc. | Cluster-based operating system-agnostic virtual computing system |
US20070094310A1 (en) * | 2005-10-21 | 2007-04-26 | Passey Aaron J | Systems and methods for accessing and updating distributed data |
US20070186054A1 (en) * | 2006-02-06 | 2007-08-09 | Kruckemyer David A | Distributed Cache Coherence at Scalable Requestor Filter Pipes that Accumulate Invalidation Acknowledgements from other Requestor Filter Pipes Using Ordering Messages from Central Snoop Tag |
US20100241785A1 (en) * | 2006-04-27 | 2010-09-23 | Vmware, Inc. | Management of host physical memory allocation to virtual machines with a balloon application |
US20100161908A1 (en) * | 2008-12-18 | 2010-06-24 | Lsi Corporation | Efficient Memory Allocation Across Multiple Accessing Systems |
US20110179229A1 (en) * | 2010-01-15 | 2011-07-21 | International Business Machines Corporation | Store-operate-coherence-on-value |
US20140244891A1 (en) * | 2013-02-26 | 2014-08-28 | Red Hat Israel, Ltd. | Providing Dynamic Topology Information in Virtualized Computing Environments |
Also Published As
Publication number | Publication date |
---|---|
JP2019500705A (ja) | 2019-01-10 |
KR20180057639A (ko) | 2018-05-30 |
EP3356936A4 (en) | 2019-06-05 |
WO2017059054A1 (en) | 2017-04-06 |
EP3356936A1 (en) | 2018-08-08 |
EP3356936B1 (en) | 2020-05-27 |
KR102051282B1 (ko) | 2019-12-03 |
US20170149921A1 (en) | 2017-05-25 |
CN108292235A (zh) | 2018-07-17 |
JP6652646B2 (ja) | 2020-02-26 |
US20220174130A1 (en) | 2022-06-02 |
US11240334B2 (en) | 2022-02-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108292235B (zh) | 使用选择性资源迁移的网络附连存储器 | |
US11513836B2 (en) | Scheduling resuming of ready to run virtual processors in a distributed system | |
US11803306B2 (en) | Handling frequently accessed pages | |
US11656878B2 (en) | Fast boot | |
US11159605B2 (en) | Hierarchical dynamic scheduling | |
US10747673B2 (en) | System and method for facilitating cluster-level cache and memory space | |
US20220229688A1 (en) | Virtualized i/o |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20230327 Address after: Texas, USA Patentee after: HEWLETT PACKARD ENTERPRISE DEVELOPMENT L.P. Address before: California, USA Patentee before: Hongchao Co. |