Hardware for integration of servers into a management network

An interposer card and a virtualization offloading card are provided for installation in a third-party server to integrate the third-party server into a cloud service provider network. The interposer card includes a baseboard management controller that interfaces with a management console of the cloud service provider network. This allows the third-party server to be converted into a server controlled by the cloud service provider network. Additionally, the baseboard management controller of the interposer card acts as a firewall between the third-party server and a management control network of the cloud service provider network. The interposer card and the virtualization offloading card are installed in a chassis of the third-party server via an expansion slot without requiring modification of the hardware or firmware of the third-party server.

BACKGROUND

A cloud provider network (sometimes referred to simply as a “cloud”) refers to a large pool of network-accessible computing resources (such as compute, storage, and networking resources, as well as applications, and services), which may be virtualized or bare-metal. The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to user commands. These resources can be dynamically provisioned and reconfigured to adjust to variable load.

Some cloud providers that operate a cloud provider network may design and/or build their own computing resources, such as servers. For example, cloud provider designed computing resources, such as servers, may be designed in a way that the servers include hardware and/or firmware for integration with a data center management network of the cloud provider.

Also, third party server designers or manufacturers may provide a wide variety of server configurations that are specifically designed to meet a wide variety of specific uses cases. In some cases, a variety of available server designs provided by third party manufacturers may exceed a variety of server designs internally designed by a cloud provider.

Due to the differences in varieties of designs, in some circumstances, it may be more economical and/or efficient for a cloud provider to use a server that has been specially designed for a particular use case by a third-party instead of the cloud provider creating their own server design for the particular use case. In such circumstances, the cloud provider may desire to integrate the third-party server into the cloud provider's data center management network without requiring significant design changes to the hardware and/or firmware of the third-party server.

DETAILED DESCRIPTION

The present disclosure relates to systems, methods, and an apparatus for integrating a third party computing resource, such as a server, into a cloud service provider management network, wherein the third-party computing resource was not originally designed for integration into the cloud service provider network and lacks hardware, software, and/or firmware used by the cloud service provider network to manage computing resources included in the cloud service provider network. For ease of illustration, a third-party computing resource is described herein as an original equipment manufacturer server or OEM server, wherein the original equipment manufacturer is a third-party to a cloud service provider that is integrating the OEM server into the cloud service provider management network. However, in some embodiments, servers from various other sources may be transformed, as described herein, in order to be integrate the servers into a cloud service provider management network. For example, servers that may be modified, as described herein, for integration into a cloud service provider management network may include any servers that have a design that deviates from server designs typically used by the cloud service provider. For example, the different designs could result from the use of an OEM design, wherein a server is manufactured by an after-market manufacturer using an OEM design, or even could result from the integration of a previous server model designed or built by the cloud service provider network that lacks design characteristics of other server designs used by the cloud service provider network.

In some embodiments, a cloud service provider network may utilize virtualization offloading components (e.g., cards) (as further described in more detail below) to perform certain virtualization management and security tasks for computing instances implemented on physical computing resources, such as servers. The virtualization offloading component may be implemented on a separate piece of hardware, such as an expansion card, that is separate from the processors and memory that are being virtualized to provide computing instances to clients. In this way, the virtualization management control functions performed by the virtualization offloading component may be trusted as they are implemented on separate hardware and cannot be interfered with by client instances. For example, a first client using a virtualized computing resource is not able to alter virtualization management in a way that would impact a later client that used the same computing resources to provide a virtualized computing resource to the second client.

In some situations, a cloud service provider may design their own servers and include a proprietary virtualization offloading component in the cloud service provider designed servers. However, in some circumstances particular users of a cloud service provider may desire computing resources with particular attributes that deviate from attributes provided by cloud service provider designed servers. For example, a particular user may desire a computing instance with particular processor, memory, GPU, ASIC, FPGA, etc. attributes. Depending on user demand for such particular configurations, in some situations it may be inefficient and/or un-economical for a cloud service provider to custom design and build such servers having particular user desired/requested configurations. In such circumstances, it may be more efficient and/or economical for the cloud service provider to utilize third-party OEM server designs to provide the user with computing instances having the requested particular processor, memory, GPU, ASIC, FPGA, etc. attributes. However, the cloud service provider may, nevertheless, desire to protect the cloud service provider's management network from firmware and/or software that may be installed on the OEM server. Additionally, the cloud service provider may desire to integrate management (including virtualization management) for the OEM server into a management network of the cloud service provider using similar systems that are used for cloud service provider designed servers, such as virtualization management offloading. Thus, apparatus, systems, and methods are disclosed herein for integrating a third-party OEM server into a cloud service provider network using an interposer card and a virtualization offloading card, or alternatively using an aggregated interposer and virtualization offloading card. The interposer card, virtualization offloading card, or the aggregated card are configured to be installed in a chassis of a pre-built OEM server without requiring hardware or firmware changes to the OEM server (other than the addition of the interposer card, virtualization offloading card, or aggregated card).

In some embodiments, a non-OEM interposer card (e.g., an interposer card not originally included in the OEM server) may be configured to couple in an expansion slot of the OEM server, such as a standard PCIe slot included in a circuit board of the OEM server. Additionally, the non-OEM interposer card may include slots configured to couple with a virtualization offloading card. For example, in some embodiments, a non-OEM interposer card may include a plurality of slots (which in some embodiments may include two cool edge slots with 16 data lanes each, though various other slot configurations may be used). In some embodiments, a non-OEM interposer card may include a PCIe connector on a first side that is configured to be inserted into a PCIe slot of an OEM server, and may include, on an opposite side, a set of one or more connectors, such as 2×16 cool edge slots, configured to couple a virtualization offloading card to the non-OEM interposer card.

In some embodiments, the non-OEM interposer card (also referred to herein simply as the interposer card) may further include a baseboard management controller (BMC) configured to act as a management firewall between a BMC of the OEM server, the virtualization offloading card and/or a cloud service provider network management controller connected to either the non-OEM interposer card or the virtualization offloading card. For example, in some embodiments, the non-OEM interposer card may further include additional connectors, such as RJ45 connectors, configured to couple the non-OEM interposer card to a cloud service provider management console switch. Also, in some embodiments, the additional connectors (e.g., RJ45 connectors) may be configured to couple the non-OEM interposer card to other non-OEM interposer cards included in other OEM servers mounted in a rack with the given OEM server in which the non-OEM interposer card is installed. Additionally, in some embodiments, at least one of the connected non-OEM interposer cards may be connected via one of the additional connectors (e.g., RJ45 connectors) to a rack management controller. In some embodiments, the rack-management controller may be provided by the OEM that provided the servers installed in the rack and perform local rack management functions.

In some embodiments, a BMC of a non-OEM interposer card may receive telemetry information from a BMC of the OEM server and/or the OEM rack management controller and may further pass telemetry information (or some part thereof) to the cloud service provider management network. Additionally, the BMC of the non-OEM interposer card may receive control commands from the cloud service provider management network and/or the attached virtualization offloading card and may serve as a proxy that causes these commands to be implemented at the OEM server via the BMC of the OEM server. In some embodiments, a BMC of the non-OEM interposer card may function as a management overlay that monitors the management devices within the OEM server (e.g., third-party server from the perspective of the cloud service provider).

In some embodiments, a non-OEM interposer card may be configured to be installed in a standard slot (e.g., PCIe slot) of various different third party (e.g., OEM) servers that have various attributes (e.g., combinations of processors, memory, specialized processors, etc.).

In some embodiments, a cloud service provider network may offer virtual compute instances with varying computational and/or memory resources. In one embodiment, each of the virtual compute instances may correspond to one of several instance types. According to the present disclosure, one or more instance types of the cloud service provider network may be instantiated on third-party hardware, such as an OEM server. In some embodiments, a common hypervisor system may manage both compute instances instantiated on the third-party hardware, as well as compute instances instantiated on various other types of hardware that were designed by the cloud service provider. Additionally, the same remote management controls may be employed to control both the third-party and in-house hardware.

In some embodiments, a cloud computing service may also be referred to herein as a virtualized computing service. In some embodiments, a cloud computing service may comprise a virtualized computing service that implements virtualized compute instances and the cloud computing service may also implement at least some bare-metal compute instances. An OEM computer system may be retrofitted to include a non-OEM interposer card comprising a baseboard management controller (BMC) for remotely controlling the OEM computer system and a virtualization offloading component for managing virtualization operations for instances to be launched on the OEM computer system, wherein the BMC of the non-OEM interposer card and the virtualization offloading component are included in a same server chassis of the OEM computer system.

The virtualization offloading component may manage, at least in part, communications between compute instances instantiated on the OEM computer system and other computing instances of the cloud computing service. Additionally, or alternatively, the virtualization offloading component may manage communications between compute instances instantiated on the OEM computer system and one or more other services of a provider network that includes the cloud computing service or devices external to the provider network. For ease of description, a virtualized offloading component is referred to herein. However, it should be noted that in some embodiments, a similar component as a virtualization offloading component may perform similar functions for bare-metal instances.

In some embodiments, the virtualization offloading component may provide a compute instance instantiated on the OEM computer system access to a client selected machine image stored in a block-based storage service of the provider network for use in booting the compute instance (e.g., virtual machine) on the OEM computer system. Also, in some embodiments, the virtualization offloading component may manage network traffic between a compute instance instantiated on the OEM computer system and other instances or services of the provider network. For example, the virtualization offloading component may route packets to or from the compute instance over a substrate network of the cloud computing service and may perform encapsulation or address re-direction of the packets. In some embodiments, a cloud services offloading component may perform similar network traffic management functions for bare-metal instances included in a cloud service provider network. Additionally, the virtualization offloading component and/or cloud services offloading component may manage security for a compute instance instantiated on the OEM computer system. For example, the virtualization offloading component or cloud services offloading component may encrypt and decrypt incoming and outgoing traffic and may manage security keys for the compute instance instantiated on the OEM computer system. Additionally, the virtualization offloading component may manage traffic such that a given compute instance instantiated on an OEM computer system is included in an isolated virtual network, e.g., a virtual private cloud, and may manage address translation between private and/or public addresses for the compute instance. In some embodiments, these virtualization tasks may be performed on processors or cores of the virtualization offloading component that are separate from hardware of the OEM computer system, but that are included in the same server chassis with the OEM computer system.

The baseboard management controller (BMC) of the non-OEM interposer card, may, in conjunction with the virtualization offloading component, enable remote control of the OEM computer system. For example, the BMC of the non-OEM interposer card may be connected to the OEM computer system and may emulate devices that the non-OEM system expects to see attached to the OEM computer system. For example, the BMC of the non-OEM interposer card may emulate a monitor, a keyboard, a mouse, etc. In some embodiments, such emulation may be performed in conjunction with the BMC of the OEM server.

In some embodiments, a virtual computing service may remotely operate an OEM third-party computer system via a virtualization offloading component and/or BMC of a non-OEM interposer card. In some embodiments, a BMC of a non-OEM interposer card may include a remote virtualization offloading controller that is in communication with a virtualization offloading component coupled to the non-OEM interposer card BMC. In some embodiments, the virtualization offloading component may include a root of trust component and may permit or prohibit actions from being taken by the BMC of the non-OEM interposer card based on whether or not a root of trust can be verified. Additionally, the OEM computer system may include a separate root of trust used to boot the OEM computer system and the root of trust of the virtualization offloading component may be an additional layer of trust in addition to that of the OEM computer system.

In some embodiments, a virtualized computing service and/or cloud computing service may be one of among a plurality of network-accessible services (e.g., including storage services, database services, etc.) implemented at a provider network or in a cloud computing environment. The OEM servers comprising third party computer systems may be located at data centers of such a provider network, at co-location facilities (e.g., a location such as a building or room in which computing-related resources of more than one organization may be hosted), and/or at client-owned premises connected to the provider network via a network connection.

The OEM computer system and the non-OEM interposer card as described herein may be connectable using industry-standard components, such as cables and/or connectors. For example, for OEM third-party computer system that adheres to widely used industry standards for peripheral connectivity (such as Peripheral Component Interconnect-Express (PCIe) or Universal Serial Bus (USB)), the functionality incorporated within the virtualization offloading component and/or non-OEM interposer card BMC may allow compute instances launched at the OEM third party computer system to obtain all the benefits (e.g., manageability, security, connectivity to other network-accessible services, and the like) provided to compute instances set up on a fleet of cloud service provider designed servers selected or designed by the operator of the virtualized computing service or cloud computing service.

The virtualization offloading component may initiate one or more configuration operations of a compute instance on behalf of the client in various embodiments, including for example launching the compute instance, changing networking or other configuration settings, terminating the instance, and so on. In at least one embodiment, a bare metal compute instance may be instantiated on a third-party OEM computer system on behalf of a user via a virtualization offloading component included in a server chassis with the third-party OEM computer system, enabling un-virtualized access to at least some of the third-party OEM computer system's hardware devices/components. In various embodiments, a compute instance implemented on a third-party OEM computer system may be configured within an isolated virtual network of the provider network based at least in part on operations performed using the one or more networking managers running at a virtualization offloading component included in a server chassis with the third-party OEM computer system. Such networking managers may, for example, store an indication of a network address (within a range of private network addresses of an isolated virtual network established at the virtualized computing service or cloud computing service) which has been assigned to a compute instance configured at the third-party OEM computer system, and/or may assign such an address to a virtual network interface programmatically attached to such a compute instance.

In some embodiments, a compute instance of a third-party OEM computer system may be provided access to a root volume (and/or other logical storage devices, file systems, and the like) based at least in part on operations performed by the one or more storage managers running at the virtualization offloading component included in the server chassis with the third-party OEM computer system. For example, in some embodiments the storage managers may set up, modify, or otherwise configure the root volume using a block-storage service of the provider network, and/or other logical storage devices, file systems and the like. In some embodiments, the virtualization offloading component may comprise one or more persistent storage devices (e.g., devices accessible via an NVME (non-volatile memory express) interface) at which the contents of the root volume and/or other storage objects accessed from the compute instances of the third-party OEM computer system may be stored. Additionally, or alternatively, the virtualization offloading component may be connected, for example, via a SATA cable connection, to one or more solid-state drives included in the OEM server chassis at which the contents of the root volume and/or other storage objects accessed from the compute instances of the third-party OEM computer system may be stored.

According to at least one embodiment, the networking managers of the virtualization offloading component may include a network interface card (NIC) emulator and/or an IVN connectivity manager. Encapsulation/de-capsulation operations of the encapsulation protocol of the virtualized computing service or cloud computing service may be implemented at the networking managers in some embodiments. In at least one embodiment, the networking managers of the virtualization offloading component may be configured to log various types of network traffic directed to and/or from the compute instance(s), e.g., including Domain Name Service traffic directed to DNS servers in or outside the provider network, and provide such logs via programmatic interfaces to the client on whose behalf the compute instance is configured.

A number of programmatic interfaces (e.g., web-based consoles, command-line tools, graphical user interfaces, application programming interfaces (APIs) and the like) may be implemented by the cloud computing service (which may include a virtualized computing service) to enable clients to submit requests pertaining to compute instances in various embodiments and receive corresponding responses. For example, a client may submit a programmatic request to instantiate a compute instance on a third-party OEM computer system. In some embodiments, a cloud computing service may dynamically increase or decrease provisioned compute instances. For example, a client may request more or fewer instances via a command-line tool or graphical user interface and the cloud computing service may dynamically add or remove compute instances from the client's pool of allocated resources. Also, a client may dynamically add or remove compute instances to or from isolated virtual networks or VPCs allocated to the client.

According to some embodiments, as mentioned earlier, the provider network of the cloud computing service may implement one or more other services, such as a database service or an object storage service, which can be accessed from at least some compute instances of the cloud computing service executing on a third-party OEM computing resources using credentials assigned to the compute instances by an instance metadata service (IMDS) of the cloud computing service. Such an IMDS may also provide other metadata elements to compute instances executing on third-party OEM computing resources, including a unique identifier assigned by the cloud computing service to the compute instance, an identifier of a machine image used for the compute instance (if any), block device mappings information of the instance, and so on. In some embodiments, the metadata may be accessed from the compute instance executing on the third-party OEM computing resource via a link-local HTTP (HyperText Transfer Protocol) address accessible only from within the instance itself. In at least one embodiment, an agent of the IMDS may be run at a virtualization offloading component, and such metadata (including the credentials usable to access other provider network services from the compute instance) may be provided by the agent.

In some embodiments, a virtualization offloading component used to manage compute instances on a third-party OEM computer system may provide the same elasticity, scalability, reliability, and security that is offered to clients using default fleet compute instances. Also, a virtualization offloading component used to manage compute instances on a third-party OEM computer system may provide seamless access to other services of a service provider network of the cloud computing service, such as a virtual private cloud service (VPC or IVN), an elastic-block storage service (EBS), a load balancing service (LBS), etc.

FIG.1Aillustrates an OEM server comprising a circuit board with memory, processors, and at least one expansion slot, according to some embodiments.

In some embodiments, an OEM server102includes a baseboard management controller (BMC)104, a circuit board106, fans120, storage devices124, which may be solid state drives, hard drives, etc., and a power supply122. In some embodiments, various other components (not shown) may be included in an OEM server. In some embodiments, the circuit board106may include various memory and/or processors. For example, a selection of memory devices and processor devices in an OEM server may provide a particular capacity or server attribute requested or desired by a user of a virtualized computing service. As an example, circuit board106includes processors (CPUs)110, graphics processors (GPUs)112, field programmable gate array (FPGA)114, and application specific integrated circuit (ASIC)116. Note that various combinations of processors and memory devices may be arranged in various configurations in an OEM server, such as OEM server102, in order to provide one or more particular types of functionality. Circuit board106also includes slot118, which may be a standard slot, such as PCIe slot configured to accept an expansion card. Note that in some embodiments, storage devices124may further include a SATA connector126configured to couple with a cable connecting the storage devices124to a virtualization offloading card170.

FIG.1Billustrates the OEM server, with a non-OEM interposer card coupled in the expansion slot, wherein the non-OEM interposer card comprises slots configured to couple with a network virtualization offloading card, wherein the network virtualization offloading card provides functionality that integrates the OEM server into a cloud service provider network and enables the OEM server to be used as an additional computing resource of the cloud service provider network, according to some embodiments.

In some embodiments, non-OEM interposer card150may couple into slot118and may include on an opposite side of the non-OEM interposer card150slots152that are configured to couple with a virtualization offloading card, such as virtualization offloading card170. In some embodiments, slots152may include two 16 lane cool edge slots, though, in some embodiments, other connector types may be used. In some embodiments, the slots152may be provide a connection interface that is not available directly on circuit board106. For example, circuit board106may lack connectors and/or space for directly connecting virtualization offloading card170to circuit board106. Thus, the non-OEM interposer card150may act as an adapter between the two types of connectors (e.g., a type of connector included in the OEM server and a type of connector required by the virtualization offloading card). Also, as described above, the non-OEM interposer card may include its own BMC that acts as a firewall between a BMC104of the OEM server102and a management network of a cloud service provider network in which the OEM server102is being installed.

FIG.1Cillustrates the OEM server with the non-OEM interposer card and the network virtualization offloading card installed in a chassis of the OEM server without requiring hardware changes or firmware changes to the OEM server, according to some embodiments.

As shown inFIG.1C, virtualization offloading card170may couple to the slots152of non-OEM interposer card150and be connected to circuit board106via non-OEM interposer card150. As described in more detail with regard toFIG.3, in some embodiments, virtualization offloading card170may provide various virtualization management functions for computing instances implemented using processors110, GPUs112, FPGAs114and ASIC116of OEM server102.

FIG.1Dillustrates an exploded side view of the non-OEM interposer card and the network virtualization offloading card that couple with the circuit board of the OEM server, according to some embodiments.

As can be seen inFIG.1D, non-OEM interposer card150may couple with PCIe expansion slot118of circuit board106. Also, virtualization offloading card170may couple with slots152of non-OEM interposer card150. Both the non-OEM interposer card150and the virtualization offloading card170may fit within chassis180of OEM server102. In some embodiments, chassis180may have a 1U height, though in some embodiments other heights of OEM servers may be used.

FIG.2illustrates an example non-OEM interposer card and example components that may be included in the non-OEM interposer card, according to some embodiments.

In some embodiments, non-OEM interposer card150illustrated inFIG.1may have similar components as interposer card202illustrated inFIG.2. In some embodiments, interposer card202includes connector212configured to couple with a printed circuit board (PCB) slot connector of an OEM server, such as slot118of OEM server106. Also, interposer card202includes slots214and216configured to couple with a virtualization offloading card, such as virtualization offloading card170. Additionally, in some embodiments, interposer card202includes its own power connection204that is outside of power received via slot connector212. For example, in some embodiments, interposer card202may be separately connected to a power source, such as a 3.3 volt power source. In some embodiments, interposer card202also includes its own BMC206that is separate and independent of a BMC104of OEM server102. Additionally, in some embodiments, interposer card202includes connectors208and210, which may be RJ45 connectors configured to accept connections to an OEM rack management controller, such as OEM rack management controller614, and accept connections to a cloud service provider management network, such as management network604(both shown inFIG.6).

FIG.3illustrates an example virtualization offloading card and example processes running on processors of the virtualization offloading card to provide cloud service provider instance management for instances instantiated on a non-OEM server, according to some embodiments.

In some embodiments, the BMC206on interposer card202in combination with the virtualization offloading card302may function as a bridge between the OEM server102and a cloud computing service. For example, visualization offloading card302may be connected to a substrate network of a cloud computing service. Also, the virtualization offloading card302may provide control interfaces between the cloud computing service and a virtualization host (e.g., OEM server102). The virtualization offloading card302may present non-volatile memory express (NVMe) and elastic network adaptors (ENA).

Virtualization offloading card302includes connectors304and306that connect virtualization offloading card302to interposer card202. In some embodiments, connectors304and306may include connectors for power and multi-pin connectors that extend PCIe communications to the virtualization offloading card302from the BMC206of interposer card202, which is in turn connected to BMC104of OEM server102. In some embodiments, other types of connectors may be used. For example, in some embodiments, connectors304and306may include a power connector. In addition, virtualization offloading card302includes external Ethernet (RJ45) connector308and small form-factor port (SFP) and circuitry310. Additionally, as discussed above, virtualization offloading card302includes a SATA connector312to connect the virtualization offloading card302to SSDs124of OEM server102. Additionally, virtualization offloading card302includes root of trust component314, hardware microcontroller316and systems on a chip (SoCs)318and320. While, not shown, in some embodiments, virtualization offloading card302may include a separate power connection from the power connection provided to the interposer card202. For example, in some embodiments, virtualization offloading card302may be provided a 12 volt power connection. In some embodiments, power supplied to both interposer card202and virtualization offloading card302may be provided from a power connector that receives power from power supply122and/or an intermediate power supply within chassis180.

In some embodiments, an OEM computer system, such as OEM server102, shown inFIG.1may include its own root of trust that acts as an additional layer of trust in addition to the root of trust component314of virtualization offloading card302. In some embodiments, the root of trust component314may guarantee the virtualization offloading card302and the BMC206of interposer card202are booted from trusted firmware. In some embodiments, a root of trust component314may ensure that the SoCs318and320are booted using trusted firmware. Additionally, in some embodiments, root of trust component314may store keys or other encryption-related data used to ensure secure communications between components of virtualization offloading card302and BMC206of interposer card202. Because virtualization offloading card302is implemented on a separate physical piece of hardware from OEM server102, the operator of the cloud computing service may have greater control over security features of the virtualized offloading card302and may better restrict access to service management components implemented via the virtualization offloading card302.

The virtualization offloading card302may include one or more processors/cores318/320as well as one or more memories (not shown). The term “virtualization offloading” may be used to describe a virtualization offloading card302because much of the work required to configure and manage compute instances running at OEM server102may be offloaded to a virtualization offloading card302, enabling a larger fraction of the computing and other resources of the OEM server102to be utilized for the compute instances and client applications running at the compute instances. In the embodiment depicted inFIG.3, code and data of a number of virtualization management component programs (e.g., software and/or firmware) may be stored locally on memory of the virtualization offloading card302or at SSDs124connected via SATA connector312. In some embodiments, virtualization offloading card302may additionally, or alternatively, include a SATA device312. The code and data may be run using the processors/cores318/320. In at least some embodiments, individual ones of the virtualization management components may be executed using respective subsets of the available cores/processors—e.g., one of the cores may be used for an embedded operating system, another for a network interface card emulator, and so on. For example,FIG.3illustrates SoC318running offload card OS322, micro controller emulator324, and two instances of block storage controller326and328. Also,FIG.3illustrates SoC320running elastic network adaptor emulator330, isolated virtual network/virtual private cloud controller332, instance metadata manager334, and hypervisor interface336.

At least a portion of the code resident in the memories of the virtualization offloading card302and SSDs124may be used to manage various aspects of networking and storage for compute instances launched at OEM server102, and may therefore be referred to as a combination of a networking manager and a storage manager. Note that at least in some embodiments, at least a portion of the code and/or data may be dynamically updated or modified, e.g., after one or more compute instances have been launched at the OEM server102using the code and data.

External Ethernet port308of virtualization offloading card302may connect RJ45 circuitry of virtualization offloading card302to a system management processor (e.g., a baseboard management controller of BMC206of interposer card202). The system management processor, may be responsible for tasks such as monitoring the physical state of the OEM server102, providing results of such monitoring, rebooting/restarting of the OEM server102when needed, and so on. Small form-factor circuitry310, linked to one or more SFP ports, may be used to access a substrate network of a cloud computing service in at least some embodiments.

One or more types of local persistent storage devices may be incorporated within the virtualized offloading component302and/or BMC206of interposer card202in some embodiments, such as NVME (non-volatile memory express) device(s), other (non-NVME) solid state drives (SSDs)124accessible from SATA (Serial Advanced Technology Attachment) circuitry of the virtualization offloading card(s)302, and so on. In at least some embodiments, storage manager code running at the virtualization offloading card302may use the local persistent storage devices124to configure root volumes and/or other logical storage devices for compute instances instantiated at the OEM server102. In some embodiments, the storage manager code may implement block-level device interfaces locally (in effect implementing a subset of the functionality of a block storage service). In other embodiments, the storage manager may access a block storage service (and/or other network-accessible storage services) of the provider network to configure at least some storage devices.

FIG.4illustrates an example aggregated virtualization offloading card, wherein components of the interposer card ofFIG.2and the virtualization offloading card ofFIG.3are aggregated into a single card configured to couple in an expansion slot of a circuit board of an OEM server, according to some embodiments.

In some embodiments, instead of being implemented as two separate cards, interposer card202and virtualization offloading card302may be combined into a single aggregated virtualization offloading card402, as shown inFIG.4. In some embodiments the aggregated virtualization offloading card402may include slot connector212configured to couple with slot118of OEM server102.

FIG.5is a logical block diagram illustrating how a baseboard management controller (BMC) on an interposer card/aggregated virtualization offloading card provides a firewall between a BMC of an OEM server and a management control network of a cloud service provider, according to some embodiments.

In some embodiments, a BMC of an interposer card (or aggregated virtualization offloading card), such as BMC506of interposer card504, may function as a firewall508between management network502of a cloud service provider network and an OEM server, such as OEM server512. In this way, only data and commands authorized to be passed on by BMC506may be provided to management network502. Thus, BMC506provides a buffer (e.g., firewall) between the management network502of the cloud service provider network and the hardware and firmware of the OEM server512, such as BMC510.

FIG.6illustrates example connections between non-OEM interposer cards, an OEM rack management controller, and a management control network of a cloud service provider, according to some embodiments.

In some embodiments, non-OEM interposer cards are included in a plurality of OEM servers mounted in a rack may be connected to form a local network fabric. For example, rack600includes OEM servers608,610, and612mounted in the rack600. Interposer cards616,618, and620of the OEM servers608,610, and612are connected via cables636coupled to RJ45 connectors624,626,628, and630. Additionally, RJ45 connector622of interposer card612is connected to OEM rack management controller614and RJ45 connector632of interposer card616is connected to management network604of cloud service provider602via top of rack switch606. As described inFIGS.7A and7B, such connections may allow control signals and telemetry to be communicated to management network604and received from OEM rack management controller614.

FIG.7Ais a flowchart illustrating a process of communicating control commands between a baseboard management controller (BMC) of an OEM server and a management control network of a cloud service provider via a non-OEM interposer card BMC that provides a firewall between the management control network of the cloud service provider and the BMC of the OEM server, according to some embodiments.

At block702, management control signals are received at an interposer card from a service provider management console switch, such as may connect an interposer card to a management network, such as management network604. At block704, the control signals are routed to a BMC of the interposer card, such as BMC206of interposer card202. Then, at block706, the control signals are provided to the OEM server BMC, such as BMC104of OEM server102, for execution of the control commands.

FIG.7Bis a flowchart illustrating a process of communicating telemetry and rack management control information between a baseboard management controller (BMC) of an OEM server, a rack management controller, and a management control network of a cloud service provider via a non-OEM interposer card BMC that provides a firewall between the management control network of the cloud service provider and the BMC of the OEM server and the rack management controller, according to some embodiments.

At block752, telemetry data is received at an interposer card202from an OEM server BMC, such as BMC104of OEM server102. Also, at block754, OEM rack management controller data is optionally received at the interposer card202from a rack management controller, such as OEM rack management controller614. At block756, the telemetry data and/or rack management data is routed to the BMC206of the interposer card202. Then, at block758, the telemetry data and/or rack management data that has been confirmed to be non-malicious is provided to the cloud service provider management network, such as management network604.

FIG.8is a flowchart illustrating a process of installing a non-OEM interposer card and a virtualization offloading card in an OEM server, according to some embodiments.

At block802, a pre-built third-party OEM server is received. At block804, an interposer card, such as interposer card202, is installed in an expansion slot of a circuit board of the OEM server. At block806, a virtualization offloading card is coupled to the interposer card. Note in some embodiments the virtualization offloading card and the interposer card may be coupled together first and then coupled with the circuit board of the OEM server. At block808, the interposer card may optionally be coupled with other interposer cards of other OEM servers mounted in a rack with the OEM server and/or a rack management controller and/or a management network of the cloud service provider network. In some embodiments, the interposer cards may connect to a common switch in the rack, wherein the switch is further connected to a console switch for the management network of the cloud service provider network.

CONCLUSION