带外平台调整和配置的制作方法

文档序号:14186918阅读:228来源:国知局

优先权要求

本专利申请要求于2015年9月25日提交的序列号为14/866,567的美国专利申请的优先权的权益,其全部内容通过引用并入本文。

本文所描述的实施例总体上涉及运营商网络中资源的管理。一些实施例涉及联网资源的动态分配以及资源分配的调整和监测。



背景技术:

当前的云数据中心已经经历了针对i/o设备的大规模的纵向扩展和横向扩展,并且这带来了针对数据中心的可管理性、可靠性和性能的新的挑战。遥测技术可以协助数据中心软件进行工作负载的放置和映射,但是提供这样的遥测技术可能会对数据中心资源造成进一步流失。

附图说明

在不一定是按比例绘制的附图中,相似的附图标记可以在不同的视图中描述相似的部件。具有不同的字母后缀的相似的附图标记可以表示相似部件的不同实例。附图通过示例而非限制的方式一般地示出了本文档中所论述的各个实施例。

图1示出了根据一些实施例的用于提供带外遥测的平台的组件。

图2示出了根据一些实施例的包括用于提供带外遥测的遥测收集逻辑的设备。

图3是根据一些实施例的网络接口卡(nic)亲和算法的初始化和基准测试阶段的流程图。

图4是根据一些实施例的nic亲和算法的操作阶段的流程图。

图5示出了根据一些实施例的网络功能虚拟化(nfv)系统架构和数据流。

图6是根据一些实施例的用于带外平台配置参数可配置性的系统的框图。

图7示出了高速缓存敏感的工作负载的性能对高速缓存占用。

图8示出了不向高速缓存资源展示敏感度的受计算限制的工作负载的性能与高速缓存敏感度。

图9是根据一些实施例的用于实现性能监测和聚集算法的示例硬件实现的方法的流程图。

图10示出了根据一些实施例的可以被分析以用于进行配置决策的高速缓存敏感的工作负载的高速缓存敏感度数据。

具体实施方式

近来,数据中心运营商在针对诸如以太网10/40/100gbps/++设备、infiniband设备、rsa光结构/互连、交换机等之类的i/o设备提供大规模可管理性、可靠性和性能方面遇到了挑战。此外,随着运营商纵向扩展/横向扩展,保证单个网络流或业务类型的性能变得越来越困难,特别是在诸如欧洲电信标准协会(etsi)网络功能虚拟化(nfv)和软件定义的网络(sdn)云之类的网络云实现方式中。更进一步,网络运营商和服务提供商要求网络云系统具有高水平的恢复性。使情况更为复杂的是,随着客户将更新的机器添加到其部署的机器队列中,而不必引退更旧的机器,部署的服务器系统之间的特征、能力以及性能的范围也随之增加,并且异构性也随之增加。

可以通过依赖于从平台i/o设备(例如,网络接口卡(nic)、交换机等)到外部自动编排逻辑的可靠和连续的遥测输送的机制在云数据中心中实现i/o横向扩展/纵向扩展并且整体上进行更好的管理,以用于更灵活的和软件定义的基础架构。然而,提供这样的遥测会对运营商系统带来进一步的阻力,使得遵守服务等级协议(sla)变得越来越困难。

实施例提供了一种编排控制器,在检测到过载条件或其他不利条件时,该编排控制器通过将工作负载指派到特定平台并在平台之间迁移来主动和被动地处理连续的遥测流,以管理以网络为中心的工作负载。根据各种实施例,通过维护上下文并协助工作负载放置和映射到特定平台,运营商可以在时间和仪器方面花费更少的资源,直接管理复杂异构服务器队列上的工作负载放置。因此,实施例提供了针对与可靠性和性能的大规模纵向扩展/横向扩展管理相关联的问题的解决方案。实施例还可以向以计算为中心的平台提供益处。

另外,根据各种实施例的方法和系统提供跨机架内的服务器、跨数据中心以及跨跨越了多个地理位置的多个数据中心的改进的同步和准确的遥测。这样的同步是数据中心操作中的问题,重要的是用户始终观察数据的最新的副本。

同步问题不仅应用于时间,还应用于配置状态。配置状态可以包括许多不同的参数,包括电源管理积极性、系统功能状态(如可靠性、可用性和可服务性(ras)功能动态配置)以及用于资源调配技术(rdt)或平台qos或pqos)的共享资源监测/分配配置。这些技术中的任何或所有都能够对共享平台资源(如最后一级高速缓存空间、存储器带宽以及将来的i/o带宽)进行监测和控制。

一些数据中心运营商使用带内方法来维持时间和配置状态同步,其中来自在系统上运行的操作系统(os)或虚拟机管理器(vmm)的参与被提供来接受和应用更新的参数,诸如时间值或配置设置。通过中断os/vmm的正常操作并消耗计算周期,来自os或vmm的这样的参与引入开销和延迟。根据各种实施例,通过将这些任务卸载到带外(oob)系统,可以在不使用架构(ia)核心或实现os或vmm的其他核心的情况下执行数据的收集、聚合和分析。

尽管一些实施例使用管理引擎(me)或创新引擎(ie),但是在使用能够从外部源接收参数并且应用它们以更新当前的系统配置的固件以及能够oob的微控制器的其他组合的各种其他实施例中,其他实例化是可能的。

尽管使用me和支持软件来执行oob管理和同步任务是可能的,但是也可以向数据中心运营商提供用于ie的打开示例代码以完成oob平台调整和优化,从而允许调整参数以及甚至调整算法由数据中心运营商根据自己的需求进行修改。

针对运营商网络的平台遥测驱动网络功能部署

如本文早前简要提及的,i/o横向扩展/纵向扩展可以通过依赖于从平台i/o设备(例如,网络接口卡(nic)、交换机等)到外部自动编排逻辑的可靠且连续的遥测输送的机制在云数据中心中实现。然而,提供这样的遥测技术会对运营商系统造成进一步的阻力,使得遵守服务等级协议(sla)变得越来越困难。

实施例通过在云系统上提供sla服务、故障管理、警报和高可用性的交付来解决这些和其他问题。根据各种实施例的遥测遵循使用作为非限制性示例的软件防护扩展(sgx)、可信平台模块(tpm)或安全可信执行环境(tee)的租户实施的遥测的安全接收和输送。在nfv开放平台(opnfv)和etsinfv中正在进行的行业努力旨在针对这些用途定义正式的要求。

实施例针对e、oobcore、me或其他部署、平台和软件提供重新配置或访问物理或虚拟nic的能力。实施例提供对nic的oob或侧通道访问,而不会干扰从运行nic驱动的intel架构核心进行的带内访问。

与一些遥测供应系统相反,根据各种实施例的遥测代理除了本文描述的其它数据之外还从nic收集数据。实施例根据etsinfv标准组规定的sla要求的规定提供服务质量度量,etsinfv标准组规定了对详细nic、i/o和平台遥测的需求。根据各种实施例描述的消息传递、oob遥测、度量和定期性可以用于满足对基于ia的nfv平台(诸如开源opnfv和sunrisetrail平台)的运营商etsinfv要求。这样的遥测的一些类别可以包括虚拟机(vm)操作或虚拟网络功能(vnf)操作(例如,延迟、vm时钟错误、到达vm死亡等)、虚拟网络操作(例如,分组延迟、延迟变化、网络中断、端口状态、策略完整性等)。各种实施例的遥测代理处理来自以下的数据:处理器核心、芯片组、存储器、平台、nic、存储装置、虚拟交换机(vswitch)、加速单元(例如,加密、压缩等)。

根据各种实施例的设备可以计算或生成sla度量。例如,某些设备将检查sla是否在可接受的限值内,或通过向编排器或其他运营商报告违规来强制sla违规。设备还可以提供审计能力,在oob环境下,移除向应用软件通知不利条件、sla违规、变更等的需要。

各种实施例的oob方法可以增强或改进性能调试,因为oob方法不会将自检开销添加到已经运行在峰值容量附近的系统。因此,实施例可以避免性能结果的偏差。根据各种实施例,对nic的oob或侧通道访问避免干扰从运行nic驱动器的ia核心的带内访问。相应地,实施例可以减少开销并且中断重新配置的速率。

可用的以太网i/o仅显露有限的遥测集合,并且实施例指定由i/o适配器(包括类似于vswitch的虚拟i/o适配器)显露的附加遥测,其可以通过按照各种实施例的带外技术来访问。

在一些以网络负载为中心的运营商部署中,i/o设备被直接指派给以网络为中心的工作负载(通常称为虚拟网络功能-vnf),并且几乎没有或者没有来自管理程序/vmm的干预。在这样的部署中,cpu核心或线程被指派给这些vnf,并且不能用于遥测和编排,因为vm的延迟要求非常严格,以至于vm业务不能被暂停。相应地,各种实施例的oob机制可以是合乎需要的,这是因为这样的oob机制可以与vm同时且异步地运行,而不占用或竞争vm所依赖的平台资源以满足其延迟/带宽目标。另外,这些机制能够通过例如管理端口(聚合、分解)并且允许/限制业务来匹配已建立的sla来实施sla。

在另一个实施例中,多个vnf可以在平台上运行,并且每个vnf可以被指派给一个或多个物理或虚拟i/o设备。因此,oob机制成为用于跨所有工作负载和平台上所有设备的遥测和编排的综合机制。

图1示出了根据一些实施例的用于提供oob遥测的平台100的组件。平台100包括收集来自cpu/soc的信息的遥测收集引擎110。虽然实施例不限于在pch中实现,遥测收集引擎110可以位于南方综合体中的平台控制器(pch)中,从其它应用的套接字视角看,该平台控制器单独运行。

平台环境控制接口(peci)120将cpu遥测传递到设备150以进行协调。尽管实施例不限于此,但是设备150可以包括或被包括在ie中。peci是用于收集本文描述的数据的协议,但是实施例不限于使用peci。

pqos130收集qos信息并将qos信息发送到设备150以进行协调。qos信息可以包括(但不限于)高速缓存使用度量、存储器带宽度量、io度量等。

网络适配器硅硬件140收集或包括统计计数器、健康状态、故障、业务模式、端口状态等,并将该信息或其他信息发送到设备150。

设备150包括遥测收集器逻辑,并将启发式应用于收集的遥测和统计。设备150因此用作sla、故障管理和高可用性中介的本地平台检测和实施点。关于各种实施例描述的启发式可以涉及过滤。例如,遥测可以被过滤以专注于特定的vm来做出关于该特定vm的操作的决策。

设备150可以重新计算改进的或适宜的配置,并向vm160的全部或一些发送重新配置命令。设备150或其他系统可以向管理程序170通知重新配置已经发生。重新配置可以包括重新平衡。例如,pqos130可以收集qos数据,使得设备150可以返回ia核心以通知ia核心特定的vm160正在使用大量的资源,使得vm160可以被指派为运行在不同的核心上。

实施例可以提供关于nic的睡眠状态和统计收集。可以意识到的是,nic上的每个端口具有多达1000个可以与处理元件相关联的队列,并且队列可以与应用相关联。如果队列中的一个或多个运行时分组不足,可以做出决策,例如,将相对应的nic或一组nic设置为休眠一段时间,直到队列填满,之后又会有另外一个nic被唤醒继续处理。实施例消除了从ia核心获得这样的nic统计的负担。

分析还可以是时间定向的,使得运营商可以检查工作负载和配置以随着时间的推移进行优化。中央控制器,例如在数据中心级别,可以执行这样的过滤和基于时间的分析来检测错误和不寻常的趋势。

因此,图1描绘了多个平台元件以及闭环系统,其用于监测硬件和软件度量并且为了达到改进的或适宜的平台100状态而做出vm160中的每个的决策和重新配置。

图2示出了根据一些实施例的包括用于提供带外遥测的遥测收集逻辑的设备150。

设备150包括到遥测收集系统的至少一个遥测接口210。例如,至少一个遥测接口210可以与遥测收集引擎110进行接合,以用于收集如前所述的统计。至少一个遥测接口210可以实现peci120或另一协议。设备150还可以包括到平台度量收集系统的至少一个平台接口(也被并入元件210中)。如前所述,处理电路可以通过至少一个平台接口210收集pqos度量,并且使用pqos度量作为对启发式算法的输入。处理电路200可以基于启发式算法来确定是否已经满足sla标准,并且如果根据本文早前描述的决策或算法sla标准尚未被满足,则向数据中心管理软件报告sla违反。设备150可以包括到网络适配器硬件206的至少一个网络接口204。

设备150包括处理电路200,处理电路200被配置为从遥测收集系统接收平台遥测度量以及通过至少一个网络接口204接收网络适配器硅硬件统计,以采集收集的统计。在实施例中,平台遥测度量包括从包括以下的分组中选择的至少两个度量类型中的度量:处理核心数据、芯片组数据、存储器元件性能数据、从加密单元接收的数据、从压缩单元接收的数据、存储数据、虚拟交换机(vswitch)数据以及通过网络接口卡(nic)连接接收的数据。然而,可以向处理电路200提供或由处理电路200使用本文早前描述的或由etsinfv或其他联网标准或数据中心标准指定的任何度量。

处理电路200可以使用收集的统计信息来应用早前所述的启发式算法,以确定由通信地耦合到设备150的多个vm160的操作所生成的处理核心工作负载。

响应于检测到至少一个处理核心上的过载状态,基于处理核心工作负载,处理电路200可以提供如本文早前所述的重新配置消息,以指示至少一个vm160将操作切换到不同的处理核心。在一些实施例中,处理电路200被配置为将请求内的重新配置消息提供给管理程序170。

图3是根据一些实施例的nic亲和算法的初始化和基准测试阶段300的流程图。图4是根据一些实施例的nic亲和算法的操作阶段400的流程图。处理电路200(图2)可以执行图3和图4中所示的操作中的任一个或全部操作,但是平台100(图1)的其他元件也可以执行这些操作中的一些或全部。在一些实施例中,设备150或处理电路200可以指示平台100的其他元件执行参照图3和图4描述的任何或全部操作。

参考图3,在操作304中,处理电路200可以选择要执行的核心(例如ia核心)和基准测试操作的类型。基准测试操作可以包括对核心到高速缓存带宽、核心到i/o带宽、核心到存储器带宽或者在确定nic配置、vm配置等中感兴趣的其他基准的基准测试或其他评估。为了执行基准测试,处理电路200将指示一组至少两个处理核心(例如,将被基准测试的处理核心)按照顺序进入离线状态。在该组至少两个处理核心中的相应一个处理核心进入离线状态之后,处理电路200将提供用于对该组的至少两个处理核心中的每一个执行测试的指令。在操作306中,处理电路200将基于基准测试操作期间的性能来对该组至少两个处理核心进行排序。在执行测试之后,处理电路200将生成排序的一组处理核心。排序和测试的结果可以被存储在数据库或其他存储装置中、在远程或本地数据中心中心位置或其他位置、或设备150本地、或其一些组合。方法300以操作310结束,但是可以在操作308中在任何时间处重复。

参考图4,在操作402处,可以在平台100的nic处接收业务。在操作404处,如果传入流是高优先级,则在操作406处可以将相关联的nic中断引导至高性能核心(如根据早前所述生成和存储的排序所确定的)。否则,如果传入流不是高优先级的,则相关联的nic中断可以发送到低性能核心。

实现方法300和400或其他类似方法的实施例可以提供共享平台资源中的动态检测不均匀性(例如,在一些平台实施例中,某些核心可以具有较高的可用存储器带宽,而其他核心可以具有较高的i/o带宽)。nic驱动可以将它们仿射到最高性能的核心和/或最高存储器/高速缓存/io带宽核心,以提高或改进性能。通过确定哪些核心最适合运行用于某些硬件设备的nic驱动,实施例提供(在节点内)更好的纵向扩展、更好的整合和工作负载密度,以及可能改进的系统级或工作负载级度量,例如更高的吞吐量、减少抖动或减少延迟。

处理电路200还可以用于执行下面关于图5-图10所描述的其他功能。

图5示出了根据一些实施例的nfv系统架构500和数据流。如图5所示,设备150安全地收集i/o502、交换机504、以及虚拟/物理功能506遥测。遥测经由oob网络508被传送到nfv云os代理(例如,诸如ceilometer之类的遥测代理)510。遥测被传送到vnf管理器(例如,用于ciscopdn网关或juniperids/ips的管理控制台系统)512,它根据vnf(例如ciscopdn网关或juniperids/ips)的要求来确定底层的nfv基础架构(nfvi)的健康。

如果nfvi遥测被认为是有问题的(例如,如果错误太多、丢包、基于网络的威胁正在进行、拒绝服务(dos)攻击、每流/每租户/临时业务量差异等),或者如果vnf基础架构(vnfi)不符合根据etsinfv系列标准中的标准或类似标准定义的etsinfv定义的服务质量度量,则可以向例如编排器514或其他系统报告这样的情况。

除了遥测之外,设备150还将使能审计、警报和控制,作为用于提供sla以及遵守已建立的sla的合法证明的机制。设备150(例如,oob或me)将向管理程序170、os或云os传送由本规范中的运营商定义的各种服务质量度量要求,包括失误、故障、警报和操作错误配置等。服务质量度量包括但不限于:先进先出(fifo)深度、流量控制事件、丢失分组计数、主机缓冲区或描述符利用、传输控制协议(tcp)拥塞窗口更改、内联互联网协议安全性(ipsec)或安全套接字层(ssl)处理度量和安全策略,例如利用安全策略、密钥生命周期检查、oob密钥管理等检查业务模式。度量还可以包括sla、带宽、延迟、抖动等的性能。度量可以包括平台级度量,每个vm、应用或线程的,例如当前高速缓存占用、存储器带宽使用、i/o使用等。

任何上述系统中的任何的多个实例516、518可以提供或接收数据流,如图5所示。实施例不限于图5中所示的确切组件或组件数量。

在实施例中,nfv管理器可以并入在编排器514中,并且如果vnf或nfvi没有如服务质量所要求的执行,则编排器514可以对所接收的遥测(服务质量度量)采取补救动作。在这样的情况下,vnf管理器512可以与编排器514通信以采取补救动作。编排器514可以指示vim工作负载vnf生命周期管理代理(例如,增强的openstacknova)520来针对vnf找到合适的平台。vnf生命周期管理代理520可以执行补救动作(例如,从现有平台pi到新的平台p2的vnf实时迁移,其可以满足vnf和vnf管理器的期望)。新平台p2的选择可以通过vnf生命周期管理代理520基于从vnf管理器512接收的一组参数(例如,vnf描述符)以及潜在平台上的可用资源来执行。

作为非限制性示例,oob遥测可以包括:nic的数量、每个nic的供应商和型号、每个nic的快速外围组件互连(pcie)设备的类型、每个nic的通道或端口的数量、每秒分组、分组大小和其他分组参数、每个nic的每个端口的pci设备id、每个端口的类型和大小等。关于vm,遥测可以包括每个nic是否有资格由每个vm使用,每个nic是否将在vm当中专用或共享等。如果要共享nic,则遥测可以包括nic是否与单根i/o虚拟化(sr-iov)共享或通过vswitch共享。如果通过sr-iov共享,则oob遥测可以包括配置的虚拟功能的数量、每个vf的pci设备id、每个vf的带宽或者步调等。如果通过vswitch共享,oob遥测可以包括相对应的vswitch是在桥接模式还是网络地址转换(nat)模式中、虚拟接口的数量等。oob遥测可以包括支持的和禁用的功能的配置、nic或交换机功能的卸载方面、每个租户、每个流、每个sl所有者等的卸载或硬件加速策略、卸载错误、警报、审计等。oob遥测可以包括非一致性存储器访问(numa)节点之间的带宽,包括总带宽和使用的带宽。然而,本文列出的oob遥测示例不被视为对任何特定的oob遥测的限制性实施例。

oob平台调整、配置和优化

如本文早前简要提及的,实施例还提供跨机架内的服务器、跨数据中心以及跨横跨多个地理位置的多个数据中心的改进的同步和准确的遥测。这样的同步是数据中心操作中的问题,它阻碍了云服务的同步交付,确保用户始终观察数据的最新的副本。实施例提供改进的平台和工作负载的性能调整,以及随时间推移的行为跟踪,并共享资源重新分配以满足sla目标。

一些同步方法使用带内方法,其需要在涉及的每个系统上的os/vmm参与。实施例提供了本文描述的oob方法。

图6是根据一些实施例的用于oob平台配置参数可配置性的系统600的框图。

如图6所示,独立硬件/固件代理602与管理和策略服务器604通信以发送/接收包括配置输入606和性能反馈608的信息。该硬件/固件代理602可以通过标准网络链路或通过具有较低拥塞的专用网络与管理和策略服务器604进行通信来降低延迟。

硬件/固件代理602可以经由其他接口或协议与平台610的其余部分(共享资源、os/vmm、应用软件等)进行通信,其他接口或协议可以包括共享存储器区域(邮箱式方法)或中断。

尽管实施例不限于此,硬件/固件代理602可以在ie(客户可定制的)或me(封闭的源)中实现。设备150(图1)的组件也可以被包括在硬件/固件代理602中。

由于硬件/固件代理602独立于平台600的其余部分而操作,所以硬件/固件代理602可以异步地接收来自数据中心中的管理和策略服务器604(其继而已经接收来自地理上不同地区的另一数据中心的策略更新)的配置输入。因此,硬件/固件代理602可以在处理之后将这些更新应用于平台600,其中处理包括配置检查、合并、适用性过滤、参数修改等。硬件/固件代理602还可以与许多其他平台元件610(如os/vmm软件、单个应用、性能监测计数器或共享资源(例如,l3高速缓存和存储器))进行通信来在每应用基础上测量这样的共享资源的共享。然后可以将这些度量提供回管理和策略服务器604,以便引导高级资源感知调度决策、满足sla或其他平均性能目标、或者向数据中心管理员提供度量以测量在每平台上聚合或报告的诸如高速缓存和存储器争用和带宽利用之类的度量。

除了配置改变之外,实施例还可以基于正在运行的工作负载实时地提供平台优化,例如调整预取器,以便提供更高的性能。取决于数据中心目标以及所需的记录和可视性级别,这样的细粒度的调整算法可以在管理和策略服务器604处或在硬件/固件代理602处运行。

异步硬件/固件代理602及其到管理和策略服务器604以及平台600的其余部分(包括硬件和软件)的接口提供如本文所述的一组oob能力。硬件/固件代理602可以包括由多个核心中的一个、存储器资源、遥测和其他数据、可以在应用于系统早前本地修改的从管理和策略服务器604传递下来的配置状态、以及从平台600回读的性能数据组成的计算资源。在硬件/固件代理602或其中的核心中运行的算法可以对性能反馈数据和节点/工作负载映射和策略(其可以包括性能目标)进行动作以确定性能目标是否满足。这些算法可以包括使单个变量(例如系统吞吐量或者特定工作负载的性能)最大化或者更复杂(例如涉及多个平台输入和多变量参数最大化或者优化方案或者用于将多个工作负载的性能与单个性能目标进行比较的复杂算法)的简单策略。这些算法可以对输入性能数据进行动作以做出重新配置决策以提供给平台600的其余部分。这些重新配置改变可以改变平台600的行为,由此修改报告回硬件/固件代理602的性能度量,由此形成由硬件/固件代理602、管理和策略服务器604、性能反馈以及平台的其余部分组成的闭环控制系统。在各种实施例中,管理和策略服务器604可以是集中式或分布式的。

管理和策略服务器604可以包括跟踪工作负载的每节点状态,策略,高速缓存敏感度、带宽敏感度和其他相关的工作负载敏感度数据和性能度量的状态表或类似的跟踪系统。

硬件/固件代理602向管理和策略服务器604提供性能监测数据。性能监测数据可以从各种来源采样,包括应用反馈、os反馈或硬件源,诸如性能监测计数器和资源监测计数器。性能监测数据可以提供关于l3高速缓存利用、存储器带宽利用、i/o带宽利用等的详细信息。这些信息的源可以在发送到管理和策略服务器604之前被清理并且可选地被平均和/或压缩,管理和策略服务器604通过将节点和工作负载映射到参数中的每个以及在这些数据之上运行算法来维护该信息从而确定最佳的配置设置。管理和策略服务器604可以维护映射工作负载、节点和性能特性的表或数据库,以帮助跨越时间进行应用特性的决策和跟踪。

管理和策略服务器604可以将定时数据或配置状态的改变推送给每个服务器或其他数据中心。示例可以包括使用这些oob机制以用于时间同步,或者在低负载时间期间推送配置改变以切换到针对一些服务器更高功率效率的操作模式。这些更新可以通过标准或专用网络接口推送到每个平台(取决于数据中心网络拓扑)。

一旦硬件/固件代理602从管理和策略服务器604接收配置更新请求,硬件/固件代理602就可以执行基本检查(例如,检查所请求的值是否在安全范围内,所请求的配置参数在本平台上是否受支持等)。硬件/固件代理602或者可以缓冲改变以在预设时间应用(预设时间可以利用消息指定),或者硬件/固件代理可以立即或者在给定网络条件等技术上可行的情况下立即应用该请求。

硬件/固件代理602可以更新参数,诸如,预取器设置、数据指向的i/o(ddio)、rdt分配设置、pqos、c状态设置、p状态设置(例如,speedstep)、os配置设置、应用配置设置或由管理和策略服务器604请求的其他配置参数。

硬件/固件代理602还可以独立运行算法以调整系统状态,调制先前列出的参数或其他。性能聚合算法以及其有效性的评估在下面关于图7-图8提供。图7示出了高速缓存敏感工作负载的性能与高速缓存占用。图8示出了不向高速缓存资源展示敏感度的受计算量限制的工作负载的性能与高速缓存敏感度。

类似于图7所示的绘图可以通过在平台600(图6)或类似平台上存在许多其他应用(包括高速缓存密集型、计算密集型和存储器密集型应用)的情况下运行高速缓存敏感应用来生成。图7示出了性能与高速缓存占用(例如,高速缓存敏感度)的详细和准确的视图。实施例可以构建这样的敏感度曲线以使得能够针对服务器上的单个工作负载以及数据中心中的所有工作负载进行调度。

图8示出了可以通过在平台600(图6)或正如典型的数据中心所见的类似的平台上存在许多其他应用(包括高速缓存密集型、计算密集型和存储器密集型应用)的情况下运行计算敏感的工作负载来生成的另一示例绘图。可以意识到的是,计算敏感的工作负载不向诸如最后一级高速缓存之类的共享资源示出敏感度。实施例可以在动态数据中心中以细粒度级别检测和跟踪这样的工作负载。

图9是根据一些实施例的用于实现性能监测和聚合算法的示例硬件实现的方法900的流程图。设备150(图1)、硬件/固件代理602或另一设备或装置可以执行示例硬件实现的方法900的一个或多个操作。相应地,硬件/固件代理602可以执行各种实施例中的性能监测聚合算法来剖析应用,作为多面剖析算法集合的一部分。

示例方法900以操作902开始,其中硬件/固件代理602向应用的每个线程指派资源监测标识符(rmid)。在操作902中,硬件/固件代理602可以使用诸如intel高速缓存监测技术(cmt)或intel存储器带宽监测(mbm)之类的技术,但是实施例不限于此。

示例方法900继续到操作904,其中硬件/固件代理602将rmid与硬件线程相关联。在一些实施例中,硬件/固件代理602可以对上下文交换到核上执行操作904。因此,在操作904中,软件指示硬件监测线程,相对于软件线程监测来说,这可以在计算上更有效率。软件可以稍后取回诸如每周期指令等之类的度量。

示例方法900继续到操作906,硬件/固件代理602定期地对针对高速缓存占用和存储器带宽的性能监测事件代码进行采样(例如经由ia32_qm_evtsel和ia32_qm_ctrmsr接口),并且对应用的性能进行采样(经由每周期指令(ipc)、应用报告的性能,如每秒事务处理,等)。

示例方法900继续操作908,创建性能预测。在执行操作908中,硬件/固件代理602可以存储在存储器中取回的值以随着时间建立历史。在从几秒到几天的一段时间之后,硬件/固件代理602可以通过“桶装”为高速缓存占用的类别(例如,0-1mb、1-2mb、2-3mb等等,作为用于缓存占用的桶)来处理数据并且对每个“桶”的性能值进行平均。硬件/固件代理602可以将曲线拟合到给定的点,从而创建针对存储器带宽或高速缓存占用与性能的拟合。

硬件/固件代理602或其他系统可以检查相关系数以确认相关系数足够高以提供针对高速缓存占用或存储器带宽输入的可用且准确的性能预测。这些系数可以保存在早前参考图6所述的表格或其他存储器中。

硬件/固件代理602可以取曲线的导数来创建对性能敏感度与高速缓存占用或性能带宽进行建模的曲线。平台600(图6)的硬件/固件代理602或其他组件可以使用这些模型来做出关于应用实际需要多少高速缓存或存储器带宽的基于阈值的决策。

例如,参照图10,应用的适宜高速缓存操作点可以定义为a,在该点处应用性能通过提供l3高速缓存的附加的1mb而提高小于2%(或某个其他阈值量或百分比)。图10示出了根据一些实施例的可以被分析以用于进行配置决策的高速缓存敏感的工作负载的高速缓存敏感度数据。图10是通过对拟合到原始数据的曲线取导数而针对高速缓存敏感的工作负载形成的。在实施例中,本文描述的平台600的一个或多个组件或其他组件或计算系统可以包括用于显示图10的曲线、或者在提供高速缓存敏感度、高速缓存操作点等分析的过程中产生的任何其它曲线的显示,等等。

再次参考图9,可以定期地重复示例方法900的操作中的任何或所有,以在每应用/线程/vm的基础上重建或增强性能预测曲线。如上所述的分析可以允许实时做出高级工作负载放置决策。例如,如果发现某个工作负载是高速缓存敏感的,并且由数据中心管理员指定为高优先级,则可以将该工作负载移至具有低高速缓存利用的服务器,以获得更好的性能。可选地,使用根据各种实施例的系统和装置,中央控制器/数据中心管理器可以将更新推送到服务器,以使系统重新配置高速缓存,以针对高速缓存敏感工作负载预留高速缓存的较大部分。实时地这些类型的更新是可能的,而不需要数据中心管理员干预,这是由于各种实施例中提供的闭环软件控制。

尽管上述示例实施例是基于可运行裸金属或虚拟化工作负载的数据中心环境的,但是根据各种实施例的oob平台监测和配置可适用于多个场景,包括通信工作负载和nfv/sdn场景,例如,某些流的优先级实时地利用低延迟更新。

示例方法900可以包括以上关于图1-图8描述的设备150、硬件/固件代理602或其使用模型的任何其他操作或功能。操作可以以任何顺序、在适当的时候并行执行。方法900可以通过硬件、固件、软件或其任何组合来执行。

例如,在一些实施例中,示例方法900可以包括处理电路200(图2)或其他元件从管理和策略服务器604接收配置状态,其中配置状态包括至少一个处理核心标识符和针对相应的至少一个处理核心标识符的工作负载、策略、高速缓存敏感度和带宽敏感度中的至少一个;向所述管理和策略服务器提供针对由所述至少一个处理核心标识符识别的至少一个处理核心的性能反馈;并且从所述管理和策略服务器接收用于基于所述性能反馈来提供重新配置消息的推荐。在接收与感兴趣的参数相对应的性能监测事件代码时,处理电路200或其他组件可以检测应用性能以生成将应用性能与感兴趣的参数相关的性能曲线;根据性能曲线来生成敏感度曲线,以确定应用性能对感兴趣的参数的敏感度;并提供敏感度曲线作为对生成重新配置决策的算法的输入。感兴趣的参数可以包括缓存占用和存储器带宽中的一个。

如本文所述,示例可以包括逻辑或者多个组件、模块或机构,或者可以对其进行操作。模块是能够执行指定操作的有形实体(例如,硬件),并且可以以某种方式被配置或布置。在示例中,电路可以以指定的方式被布置(例如,在内部或者相对于诸如其他电路之类的外部实体)作为模块。在一个示例中,设备150或硬件/固件代理602的一个或多个计算机系统(例如,独立的、客户端或服务器计算机系统)或一个或多个处理器的至少一部分可以由固件或软件(例如,指令202(图2)、应用部分或应用)配置作为操作以执行指定操作的模块。在示例中,软件可以驻留在至少一个机器可读介质上。在示例中,软件当由模块的底层硬件(例如,设备150或硬件/固件代理602)执行时可以包括用于使硬件执行指定的操作的指令202(图2)。

例如,指令202可以使得硬件在一持续时间内定期地接收与计算平台的存储器带宽和高速缓存占用中的至少一个相关的性能监测事件代码。指令202可以响应于定期地接收性能监测事件代码而定期地检测在计算平台上执行的应用的应用性能,以使得生成将应用性能与计算平台的存储器带宽和高速缓存占用中的至少一个相关的至少一个曲线。

在各种实施例中,指令202可以使硬件基于至少一个曲线的一阶导数来确定应用性能对存储器带宽和高速缓存占用中的至少一个的敏感度。指令202可以使得硬件基于应用性能对存储器带宽和高速缓存占用中的至少一个的敏感度来生成针对计算平台的配置决策。

在一些实施例中,指令202可以使得硬件向应用的每个线程指派资源监测标识符(rmtd),并基于相应的rmid来分析每周期的指令和应用线程的每秒事务中的一个。

术语“模块”被理解为包括有形实体,可以是物理构造的、专门配置的(例如硬连线的)、或临时的(例如,暂时的)配置(例如编程)以在指定的方式下操作或执行本文所述的任何操作的至少一部分的实体。考虑到模块是临时配置的示例,模块不需要在任何时刻实例化。例如,在模块包括使用软件配置的通用硬件处理器的情况下;通用硬件处理器可以在不同时间被配置为相应的不同的模块。软件可以相应地配置硬件处理器,例如在一个时刻构成特定的模块,并且在不同的时刻构成不同的模块。术语“应用”或其变形在本文中被广泛地使用以包括例程、程序模块、程序、组件等,并且可以在各种系统配置上实现,包括单处理器或多处理器系统、基于微处理器的电子器件、单核或多核系统、其组合等。因此,术语“应用”可以用来指代软件的实施例或者被布置为执行本文描述的任何操作的至少一部分的硬件。

尽管机器可读介质可以包括单个介质,但术语“机器可读介质”可以包括单个介质或多个介质(例如,集中式或分布式数据库,和/或相关联的高速缓存和服务器)。

术语“机器可读介质”可以包括能够存储、编码或携带以用于由机器(例如,设备150或任何其它模块)执行并且使机器执行本公开的技术中的任意一种或多种的指令202或能够存储、编码或携带由这些指令使用或与这些指令相关联的数据结构的任何介质。换句话说,处理电路200(图2)可以包括指令,并且因此可以在各种实施例的上下文中被称为机器可读介质。其他非限制性的机器可读介质示例可以包括固态存储器以及光学和磁性介质。机器可读介质的具体示例可以包括:非易失性存储器,诸如半导体存储器设备(例如,电可编程只读存储器(eprom)、电可擦除可编程只读存储器(eeprom))以及闪存设备;磁盘,如内部硬盘和可移动磁盘;磁光盘;以及cd-rom和dvd-rom盘。

指令202还可以利用使用多个传输协议(例如,帧中继、因特网协议(ip)、tcp、用户数据报协议(udp)、超文本传输协议(http)等)中的任何一个的传输介质在通信网络上发送或接收。示例性通信网络可以包括局域网(lan)、广域网(wan)、分组数据网络(例如因特网)、移动电话网络((例如,包括码分多址(cdma)、时分多址(tdma)、频分多址(fdma)和正交频分多址(ofdma)的通道访问方法,以及蜂窝网络,诸如全球移动通信系统(gsm)、通用移动电信系统(umts)、cdma20001x*标准和长期演进(lte)等)、普通老式电话(pots)网络和无线数据网络(例如电气和电子工程师协会(ieee)802系列标准,包括ieee802.11标准(wifi)、ieee802.16标准以及其它)、对等(p2p)网络或现在已知或以后开发的其他协议。

术语“传输介质”应被理解为包括能够存储、编码或携带用于由硬件处理电路执行的指令,并且包括数字或模拟通信信号或促进这样的软件的通信的其它无形介质的任何无形介质。

其他注意事项和示例:

示例1包括主题(诸如控制设备、面间控制设备、控制面处理器、计算机设备和/或任何其它电气装置、设备或处理器)包括:到遥测收集系统的至少一个遥测接口;到网络适配器硬件的至少一个网络接口;以及处理电路,其被配置为从所述遥测收集系统接收平台遥测度量,以及通过所述至少一个网络接口接收网络适配器硅硬件统计来采集收集的统计,使用所述收集的统计来应用启发式算法以确定由通信地耦合到所述设备的多个软件系统的操作生成的处理核心工作负载,以及响应于检测到至少一个处理核心上的过载状态,基于所述处理核心工作负载提供重新配置消息以指示至少一个软件系统将操作切换到不同的处理核心。

在示例2中,示例1所述的主题可以可选地包括,其中,所述多个软件系统包括至少一个虚拟机(vm)。

在示例3中,示例1-2中的任何示例所述的主题可以可选地包括,其中,所述处理电路被配置为将请求内的所述重新配置消息提供给管理程序。

在示例4中,示例1-3中的任何示例的主题可以可选地包括,其中,所述平台遥测度量包括从包括以下的分组中选择的至少两个度量类型中的度量:处理核心数据、芯片组数据、存储器元件性能数据、从加密单元接收的数据、从压缩单元接收的数据、存储数据、虚拟交换机(vswitch)数据、以及通过网络接口卡(nic)连接接收的数据,其中,通过所述nic接收的数据包括nic遥测,其中nic遥测包括在nic处接收的每秒分组的指示和在nic处接收的平均分组大小中的至少一个。

在示例5中,示例1-4中的任何示例的主题可以可选地包括到平台度量收集系统的至少一个平台接口,并且其中,所述处理电路还被配置为通过所述至少一个平台接口来采集平台服务质量(pqos)度量,并且使用所述pqos度量作为对启发式算法的输入。

在示例6中,示例1-5中的任何示例的主题可以可选地包括,其中,所述处理电路还被配置为指示一组至少两个处理核心按顺序进入离线状态;提供用于在所述一组至少两个处理核心中的相应的一个处理核心已进入所述离线状态之后对所述一组至少两个处理核心中的每一个处理核心执行测试的指令;以及在执行测试之后,基于在所述测试期间的性能对所述一组至少两个处理核心进行排序以生成排序的一组处理核心。

在示例7中,示例6的主题可以可选地包括,其中,所述测试包括对以下中的至少一个的评估:核心到高速缓存带宽、核心到存储器带宽、以及核心到i/o带宽。

在示例8中,示例6-7中的任何示例的主题可以可选地包括,其中,所述处理电路还被配置为提供用于基于传入nic业务的优先级将所述传入nic业务引导至所述排序的一组处理核心中的处理核心的指令。

在示例9中,示例1-8中的任何示例的主题可以可选地在本文中包括,所述处理电路还被布置为基于所述启发式算法来确定服务级别协议(sla)标准是否满足;以及如果sla标准没有被满足,则将sla违规报告给数据中心管理软件。

在示例10中,示例1-9中的任何示例的主题可以可选地包括,其中,所述处理电路还被配置为从管理和策略服务器接收配置状态,所述配置状态包括至少一个处理核心标识符以及针对相应的至少一个处理核心标识符的工作负载、策略、高速缓存敏感度和带宽敏感度中的至少一个;针对由所述至少一个处理核心标识符识别的至少一个处理核心,将性能反馈提供给所述管理和策略服务器;以及从所述管理和策略服务器接收用于基于所述性能反馈来提供所述重新配置消息的推荐。

在示例11中,示例10的主题可以可选地包括,其中,所述处理电路还被布置为在接收与感兴趣的参数相对应的性能监测事件代码时,检测应用性能以生成将应用性能与所述感兴趣的参数相关的性能曲线;根据所述性能曲线来生成敏感度曲线,以确定应用性能对所述感兴趣的参数的敏感度;以及提供所述敏感度曲线作为对用于生成重新配置决策的算法的输入。

在示例12中,示例11的主题可以可选地包括,其中感兴趣的参数包括高速缓存占用和存储器带宽中的一个,并且其中高速缓存占用与存储器带宽无关。

示例13包括诸如包括指令的机器可读介质之类的主题,所述指令在机器(诸如控制设备、面间控制设备、创新引擎、管理引擎、控制面处理器、计算设备、nic卡等)上执行时使所述机器在一持续时间定期地接收与计算平台的存储器带宽和高速缓存占用中的至少一个相关的性能监测事件代码;响应于定期地接收所述性能监测事件代码,定期地检测在所述计算平台上执行的应用的应用性能,以生成将应用性能与所述计算平台的存储器带宽和高速缓存占用中的至少一个相关的至少一个曲线;基于所述至少一个曲线的一阶导数来确定应用性能对存储器带宽和高速缓存占用中的至少一个的敏感度;以及基于应用性能对存储器带宽和高速缓存占用中的至少一个的敏感度来生成针对所述计算平台的配置决策。

在示例14中,示例13的主题可以可选地包括进一步的指令,其用于使机器将资源监测标识符(rmid)指派给所述应用的每个线程;以及基于相应的rmid来对每周期指令和应用线程的每秒事务中的一个进行分析。

在示例15中,示例14的主题可以可选地包括进一步的指令,其用于使机器通过基于应用敏感度曲线来确定如下点从而生成针对所述应用的高速缓存操作点,在所述点处应用性能提高了小于用于高速缓存的附加单位测量的阈值量,以及提供配置决策以指定如果所述高速缓存操作点指示所述应用具有高级别的高速缓存敏感度,则所述应用应该在具有低高速缓存利用的处理核心上执行。

在示例16中,示例15的主题可以可选地包括进一步的指令,其用于使机器提供将应用性能与存储器带宽和高速缓存占用中的至少一个相关的所述至少一个曲线以用于在中央管理引擎上显示。

示例17包括主题,所述主题包括一种方法,所述方法包括从遥测收集系统接收平台遥测度量,以及通过至少一个网络接口接收网络适配器硅硬件统计,来采集收集的统计,使用所述收集的统计来应用启发式算法以确定由通信地耦合到所述设备的多个虚拟机(vm)的操作生成的处理核心工作负载,以及响应于检测到至少一个处理核心上的过载状态,基于所述处理核心工作负载来将重新配置消息提供给管理程序以指示与所述管理程序相关联的至少一个vm将操作切换到不同的处理核心。

在示例18中,示例17的主题可以可选地包括,其中,所述平台遥测度量包括从包括以下的分组中选择的至少两个度量类型中的度量:处理核心数据、芯片组数据、存储器元件性能数据、从加密单元接收的数据、从压缩单元接收的数据、存储数据、虚拟交换机(vswitch)数据、以及通过网络接口卡(nic)连接接收的数据。

在示例19中,示例17-18中的任何示例的主题可以可选地包括指示一组至少两个处理核心按顺序进入离线状态;提供指令以用于在所述一组至少两个处理核心中的相应一个处理核心已经进入所述离线状态之后对所述一组至少两个处理核心中的每一个处理核心执行测试;在执行测试之后,基于所述测试期间的性能来对所述一组至少两个处理核心进行排序以生成排序的一组处理核心;以及提供指令以用于基于传入网络接口卡(nic)业务的优先级来将所述传入nic业务引导到所述排序的一组处理核心中的处理核心。

在示例20中,示例19的主题可以可选地在本文中包括所述测试包括对以下中的至少一个的评估:核心到高速缓存带宽、核心到存储器带宽、以及核心到输入/输出的带宽。

在示例21中,示例17-20中的任何示例的主题可以可选地包括在一持续时间定期地接收与包括所述处理核心的计算平台的存储器带宽和高速缓存占用中的至少一个相关的性能监测事件代码;响应于定期地接收所述性能监测事件代码,定期地检测在所述计算平台上执行的应用的应用性能,以生成将应用性能与所述计算平台的存储器带宽和高速缓存占用中的至少一个相关的至少一个曲线;基于所述至少一个曲线的一阶导数来确定应用性能对存储器带宽和高速缓存占用中的至少一个的敏感度;以及基于应用性能对存储器带宽和高速缓存占用中的至少一个的敏感度来生成针对所述计算平台的配置决策。

上文的详述包括对附图的参考,附图形成详述的部分。附图通过示出的方式图示了可实施的具体的实施例。这些实施例在本文还称为“示例”。这些示例可以包括除了所图示和所描述的之外的元件。然而,还构思包括所图示或所描述的元件的示例。而且,还构思使用所图示或所描述的那些元件(或其一个或多个方面)的任意组合或置换的示例,或者针对特定的示例(或其一个或多个方面)或者针对所图示或所描述的其它示例(或其一个或多个方面)。

在该文档中提及的出版物、专利和专利文献的全文通过引用的方式被并入到本文中,正如单独地通过引用被并入一样。在本文档与如此通过引用被并入的那些文档之间有不一致的用法的情况下,在并入的引用中的用法是本文档中的用法的补充;对于无法协调的不一致,以本文档中的用法为准。

在本文档中,使用了如在专利文献中常用的术语“一(a)”或“一个(an)”,来包括一个或多于一个,独立于“至少一个”或“一个或多个”的任何其它实例或用法。在本文档中,术语“或者”用来指代非排他或者,使得“a或b”包括“a而不是b”、“b而不是a”和“a和b”,除非另作说明。在随附的权利要求中,术语“包括”和“在其中”用作相应的术语“包含”和“其中”的通俗英语等价词。而且,在以上权利要求中,术语“包括”和“包含”是开放式的,即,包括除了在权利要求中该术语之后所列的那些元件之外的元件的系统、设备、物品或过程仍认为落入该权利要求的范围内。此外,在以上权利要求中,术语“第一”、“第二”和“第三”等仅用作标签,并且不旨在暗示用于其对象的数字顺序。

上面的说明旨在示例性的,而非限制性的。例如,上述的示例(或其一个或多个方面)可与其它示例组合使用。例如,本领域普通技术人员在阅览上述说明时可使用其它实施例。摘要允许读者快速地确定技术公开的本质,并且应当理解,摘要不被认为用于解释或限制权利要求的范围或含义。而且,在上面的具体实施方式中,可以将各种特征组合在一起以使得公开内容流畅。然而,权利要求可以不阐述本文公开的特征,这是因为实施例可以包括所述特征的子集。此外,实施例可以包括比在特定示例中公开的那些更少的特征。因此,以上权利要求特此被并入具体实施方式中,权利要求本身独立地作为单独的实施例。本文公开的实施例的范围应参照随附的权利要求以及这些权利要求赋予权利的等同内容的整个范围来确定。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1