用于解聚的组件的软件覆盖的制作方法
【专利说明】用于解聚的组件的软件覆盖
[0001 ] 相关申请的交叉参考
[0002]本申请涉及与其同一日期提交的题为“CONTENT FABRIC FOR A DISTRIBUTEDFILESYSTEM”(EMC案卷号:EMC-14-0278)的美国专利申请序列号14/320，001、题为“DYNAMICALLY COMPOSED COMPUTE NODES COMPRISING DISAGGREGATED COMPONENTS”(EMC案卷号:EMC-14-0279)的美国专利申请序列号14/320，069、题为“APPLICAT1N ANDINFORMAT1N MOVEMENT IN A CLOUD ENVIRONMENT”(EMC案卷号:EMC-14_0264)的美国专利申请序列号14/318，805、题为“CL0UDB00K”(EMC案卷号:EMC-14-0265)的美国专利申请序列号 14/318 ,831、以及题为 “MIGRATING PRIVATE INFRASTRUCTURE SERVICES TO A CLOUD”(EMC案卷号:EMC-14-0281)的美国专利申请申请序列号14/319,773，这些申请的全部内容在此通过引用并入本文。
技术领域
[0003]本发明总体上涉及计算机平台，并且更具体地涉及用于根据解聚的硬件组件创建动态组成的计算节点的系统和方法。
【背景技术】
[0004]信息技术基础设施逐步形成。早期基础设施包括与大型机通信的瘦客户端。大型机包括由基础设施中的所有客户端共享的硬件资源。这些基础设施可以被称为“第一平口 ο
[0005]大型机最终相对于通用个人计算机和/或服务器失去流行性。这些计算机包括一起捆绑成单个薄金属盒的硬件组件，并且通常用作用于更复杂系统的构造块。这些基础设施可以被称为“第二平台”。
[0006]目前存在远离大型机、个人计算机和服务器朝向新的第三平台基础设施的趋势。第三平台基础设施可以由至少五个趋势来总结:移动性、社交性、大数据、云和信任。
[0007]因此，需要用于向第三平台基础设施分配硬件资源的改进方法、制品和装置。
【附图说明】
[0008]通过以下结合附图的详细描述将容易地理解本发明，其中相似的参考标号表示相似的结构元件，其中:
[0009]图1描绘了根据本公开内容的实施例的传统的基础设施。
[0010]图2描绘了根据本公开内容的实施例的解聚的基础设施。
[0011]图3描绘了根据本公开内容的实施例的逻辑资源池。
[0012]图4描绘了根据本公开内容的实施例的用于创建动态组成的计算节点的过程。
[0013]图5描绘了根据本公开内容的实施例的用于嵌套视图的流程图。
[0014]图6描绘了根据本公开内容的实施例的在解聚的硬件组件上安装软件的架构。
[0015]图7描绘了根据本公开内容的实施例的在解聚的组件上安装软件的过程。
[0016]图8描绘了根据本公开内容的实施例的用于确定资源需求的过程。
[0017]图9描绘了根据本公开内容的实施例的用于迀移软件的过程。
[0018]图10描绘了根据本公开内容的实施例的用于在两个软件解决方案之间建立通信的过程。
【具体实施方式】
[0019]以下结合示出本发明原理的附图提供了本发明的一个或多个实施例的详细描述。虽然结合这样的实施例描述了本发明，但应该理解，本发明不限于任何一个实施例。相反，本发明的范围仅由权利要求限定，并且本发明包含多种备选、修改和等效。为了示例的目的，以下描述中阐述了多个特定细节以便提供本发明的完全理解。为了示例的目的提供这些细节，并且在没有这些特定细节中的一些或所有细节的情况下，可以根据权利要求来实践本发明。为了清楚的目的，与本发明有关的技术领域已知的技术材料没有被详细描述，以便本发明不会被不必要地模糊。
[0020]应该理解，可以以包括如过程、装置、系统、设备、方法或计算机可读介质(诸如计算机可读存储介质或计算机指令在光学或电通信链路上被发送的计算机网络)的多种方式来实施本发明。应用可以采取在通用计算机上执行的软件或者被硬连线或被硬编码在硬件中的形式。在本说明书中，这些实施方式或者本发明可以采取的任何其他形式可以被称为技术。通常，所公开处理的步骤的顺序可以在本发明的范围内进行改变。
[0021]本文描述的方法、过程和系统使得分散硬件资源和/或组件组合成动态组成的计算节点(本文也称为“DCCN”或“计算节点”)。传统的基础设施包括在外壳(enclosure)的内部预装配的硬件组件。这些基础架构通常基于外壳向外扩展，并且通常在存储服务器与计算/存储服务器之间被划分。然而，传统的基础设施在云环境中扩展得不是很好。它们由环境中的服务器的数量和服务器能力所限制。为了增加环境的资源，必须物理添加新的组件或外壳，消耗了时间并增加了成本。本文讨论的方法、系统和过程通过提供用于将解聚的硬件组件组合到DCCN中的机制来缓和了这些问题。
[0022]图1示出了根据本公开内容的实施例的传统基础设施。不同于参照图2及后续附图讨论的系统，图1中所示系统可以针对给定的实用程序或应用而特制。该系统可以包括在网络104上互相通信的服务器100和存储服务器102。在实施例中，网络104可以包括通过光纤通道交换机106连接的光纤通道。
[0023]服务器100可以包括计算和/存储器资源108，其经由网络接口控制器(“NIC”)112与机架顶部(“TOR”)交换机110通信。计算/存储资源108可以通过主机总线适配器(“HBA” )114与网络104对接。在实施例中，计算机服务器100主要包括处理资源(诸如计算机存储器或处理器)，并且包含有限的存储资源。
[0024]存储服务器102可包括由互连结构(fabric)118连接的存储资源116。在实施例中，存储服务器102可以是存储区域网(“SAN”)的一部分。存储资源116例如可以为磁带或旋转型磁盘资源。存储服务器102可以进一步包括与互连118通信的存储处理器WOt3HBAWO可以与允许从/向服务器100接收/传输数据的网络104对接。
[0025]图1的传统基础设施存在许多挑战。首先，组成的硬件组件通常根据类型捆绑到外壳(诸如服务器机架)内。例如，服务器100可以包括捆绑到单个机器内的计算/存储资源108以及TOR交换机110。类似地，存储服务器102可以包括一起捆绑到机器内的存储资源116。因此，添加附加资源可能要求物理地添加新的外壳或组件，导致系统停机时间和/或损失。
[0026]第二，传统基础设施中的通信流可以表征为北-南(“N-S”)，这意味着I/O主要通过网络104从服务器100向南流到存储服务器102。服务器100可以以这种N-S方式接合至存储服务器102，创建贮藏的(siloed)环境。结果，完全利用的服务器组不能够溢出并消耗来自分离的未充分使用的贮藏的环境的资源。类似地，诸如抽点复制、灾难复原和/或备份的数据服务不能够在贮藏的环境之间进行共享。相反，每个贮藏的环境必须包括这些高可用性/恢复力模型的自身实例。
[0027]N-S数据流还存在延迟和通信问题。例如，基础设施内的通信可能要求沿着N-S数据路径的多跳和拦截。这些跳可源于硬件组件之间的通信所要求的不同层和协议。例如，数据可以由计算/存储资源108处理，数据可以使用HBA 114和光纤通道交换机106在网络104上被传输，数据可以由存储处理器120接收并经由互连118传送到存储116。这些通信中的每个通信可以使用不同的协议，从而增加了系统开销、管理复杂度和检修复杂度。延迟问题可进一步由于脱架(out of rack)请求而被恶化，这是因为TOR连接性与计算-存储连接性分离。
[0028]持久数据服务(诸如突然折断(snap)、不被复制或复制)也在传统的基础设施内被限制。这些数据服务可限于存储服务器102并且在服务器100处不可用。因此，希望在服务器100处存储持久数据的应用对这些服务不知情，潜在地导致数据丢失或破坏。可选地，数据服务可以独立地存在于存储服务器102和服务器100上，但是具有不同的实施方式。
[0029]图2和图3描绘的解聚的基础设施解决了传统基础设施的限制。在图2和图3中，硬件组件可以从它们的外壳解聚并且一起组合到资源的逻辑池中。来自这些池的不同的组件可以专用于特定的应用和/或实用程序以形成动态组成的计算节点，并且可以根据需要从该计算节点动态地添加或移除。这不同于通常为了特定的应用而