Virtual network interface objects
15 claims: 10 independent, 5 dependent
- 1複数の資源インスタンスと、ネットワークインタフェース仮想化コーディネータと、永続的リポジトリを備えたシステムにおける仮想ネットワークオブジェクトを管理する方法であって、 前記ネットワークインタフェース仮想化コーディネータが、 インタフェースレコード作成要求に応答して、 第1の IPアドレスおよび前記第1のIPアドレスを含む第1のサブネットのサブネット識別子を含むインタフェースレコードを生成すること、および前記インタフェースレコードを 前記 永続的リポジトリに格納するこ と、 前記インタフェースレコードを 前記 複数の資源インスタンスのうちの第1の資源インスタンスにアタッチするための第1のアタッチ要求に応答して、前記第1の資源インスタンスが、前記第1のIPアドレスを対象としたトラフィックを受信することを可能にするこ と、 前記インタフェースレコードを前記第1の資源インスタンスからデタッチするためのデタッチ要求に応答して、前記第1の資源インスタンスが、前記第1のIPアドレスを対象としたトラフィックを受信するのを防ぐこと、および前記インタフェースレコードを前記永続的リポジトリ内に保持すること 、 を含 む方 法。
- 2前記ネットワークインタフェース仮想化コーディネータが、 第2のインタフェースレコード作成要求に応答して、第2のIPアドレスを含む第2のインタフェースレコードを生成するこ と、 前記第2のインタフェースレコードを前記第1の資源インスタンスにアタッチするための第2のアタッチ要求に応答して、前記第1の資源インスタンスが、前記第2のIPアドレスを対象としたトラフィックを受信することを可能にすること 、 をさらに含む、請求項1に記載の方法。
- 3前記第2のIPアドレスが、第2のサブネットの部分であり、かつ、前記第2のインタフェースレコードが前記第2のサブネットのサブネット識別子を含 む請 求項2に記載の方法。
- 4前記第1の資源インスタンス が 、ネットワークパケットを送信元IPアドレスから受信することであって、 前記送信元IPアドレスが、前記第1の資源インスタンスから前記第1のサブネットを介して到達可能であり、かつ 、前 記第1の資源インスタンスから前記第2のサブネットを介して到達可能な宛先IPアドレスを有する、 前記 ネットワークパケットを送信元IPアドレスから受信するこ と、 前記ネットワークパケットを前記第2のサブネットを介して前記宛先IPアドレスにルーティングすること 、 をさらに含 む請 求項3に記載の方法。
- 5前記ネットワークインタフェース仮想化コーディネータが、 新しいIPアドレスを含むIPアドレス修正要求に応答して、 前記インタフェースレコードを前記新しいIPアドレスを含むように修正するこ と、 前記インタフェースレコードがアタッチされる前記複数の資源インスタンスのうちの現在アタッチされている資源インスタンスを識別するこ と、 前記現在アタッチされている資源インスタンスが、前記新しいIPアドレスを対象としたトラフィックを受信することを可能にすること 、 をさらに含 む請 求項3に記載の方法。
- 6前記第1のサブネットが、第1の共通インターネットドメインルーティング(CIDR)アドレスプレフィックスをもつネットワークの第1の論理パーティションの部分であり、かつ、前記第2のサブネットが、第2のCIDRアドレスプレフィックスをもつ前記ネットワークの第2の論理パーティションの部分であ る請 求項3に記載の方法。
- 7前記インタフェースレコードが、アタッチ要求を投入することを認可された1つまたは複数の実体を識別する第1の認可エントリを含む1組のセキュリティ特性を含 む請 求項1に記載の方法。
- 8前記1組のセキュリティ特性が、前記第1の認可エントリを修正することを認可された1つまたは複数の実体を識別する第2の認可エントリを含む、請求項7に記載の方法。
- 9複数の資源インスタンスと、ネットワークインタフェース仮想化コーディネータと、永続的リポジトリを備えたシステムにおける仮想ネットワークオブジェクトを管理する方法を実行するための プログラム命令を格納す るコ ンピュータアクセス可能 な 記憶媒 体で あって 、 ネットワークインタフェース仮想化コーディネータに、 インタフェースレコード作成要求に応答して、 第1の IPアドレスおよび前記第1のIPアドレスを含む第1のサブネットのサブネット識別子を含むインタフェースレコードを生成すること、および前記インタフェースレコードを 前記 永続的リポジトリに格納するこ と、 前記インタフェースレコードを 前記 複数の資源インスタンスのうちの第1の資源インスタンスにアタッチするための第1のアタッチ要求に応答して 、前 記第1のIPアドレスを対象としたトラフィックが前記第1の資源インスタンスで受信されることを可能にすること 、 を実行させるプログラムを記録したコンピュータアクセス可能な記憶媒体 。
- 10前記プログラム命令が、 前記ネットワークインタフェース仮想化コーディネータに、 第2のインタフェースレコード作成要求に応答して、第2のIPアドレスを含む第2のインタフェースレコードを生成するこ と、 前記第2のインタフェースレコードを前記第1の資源インスタンスにアタッチするための第2のアタッチ要求に応答して、前記第1の資源インスタンスが、前記第2のIPアドレスを対象としたトラフィックを受信することを可能にすること 、 を 実行させる 請求項9に記載の コンピュータアクセス可能な記憶媒体 。
- 11前記プログラム命令が、 前記第1の資源インスタンス に 、ネットワークパケットを送信元IPアドレスから受信することであって、前記送信元IPアドレスが、前記第1の資源インスタンスから前記第1のサブネットを介してアクセス可能であり、かつ 、前 記第1の資源インスタンスから前記第2のIPアドレスに関連付けられた第2のサブネットを介してアクセス可能な宛先IPアドレスを有する、 前記 ネットワークパケットを送信元IPアドレスから受信するこ と、 前記ネットワークパケットを前記第2のサブネットを介して前記宛先IPアドレスにルーティングすること 、 を 実行させる 請求項10に記載の コンピュータアクセス可能な記憶媒体 。
- 12前記インタフェースレコードが、前記 第1又は第2の IPアドレスを修正することを認可された1つまたは複数の実体を識別する認可エントリを含む1組のセキュリティ特性を含 む請 求項9に記載の コンピュータアクセス可能な記憶媒体 。
- 13前記インタフェースレコードが:入トラフィックに対するポート制約、入トラフィックに対するプロトコル制約、出トラフィックに対するプロトコル制約、または出トラフィックに対するプロトコル制約のうちの少なくとも1つを識別する認可エントリを含む1組のセキュリティ特性を含 む請 求項9に記載の コンピュータアクセス可能な記憶媒体 。
- 14前記第2のIPアドレスが、第2のサブネットの部分であり、かつ、前記第1のサブネットがクライアントアプリケーションデータの伝送用に指定されたデータサブネットであり、前記第2のサブネットがネットワーク管理データの伝送用に指定された管理サブネットであ る請 求項10に記載の コンピュータアクセス可能な記憶媒体 。
- 15前記第1のIPアドレスが、第1の顧客の代わりに保持された第1のネットワーク論理パーティションの部分であり、かつ、前記第2のIPアドレスが、第2の顧客の代わりに保持された第2のネットワーク論理パーティションの部分であ る請 求項10に記載の コンピュータアクセス可能な記憶媒体 。
Independent claims15
64 paragraphs, as filed
0001Many businesses and other organizations are co-located (as part of a local network) or, instead, in multiple separate geographic locations (eg, one or more private or public intermediate networks). Operate a computer network that interconnects a large number of computing systems to support their business, such as by using the computing systems that are deployed (via). For example, private data centers operated by a single organization and on behalf of a single organization, and public data centers operated by entities as businesses to provide computing resources to customers. Data centers that house a number of interconnected computing systems have become commonplace. Some public data center operators provide network access, power, and secure installation facilities for hardware owned by various customers, while other public data center operators provide. Provides a "full service" facility, including hardware resources made available to their customers. However, as the size and scope of typical data centers has grown, the task of provisioning, operating, and managing physical computing resources has become increasingly complex.
0002The advent of virtualization technology for commodity hardware has benefited the management of large-scale computing resources for a large number of customers with diverse needs, and various computing resources are shared efficiently and safely by multiple customers. Allows you to For example, virtualization technology allows a single physical computing machine to provide each user with one or more virtual machines hosted by that single physical computing machine among multiple users. Each such virtual machine can allow to be shared, giving the user the illusion that they are the only operators and administrators of a given hardware computing resource, and at the same time among the various virtual machines. A software simulation that acts as a separate logical computing system that also provides application isolation and security. Moreover, some virtualization technologies can provide virtual resources across two or more physical resources, such as a single virtual machine with multiple virtual processors across multiple separate physical computing systems. is there. As another example, virtualization technology allows data storage hardware to be shared among multiple users by providing each user with a virtualized data store that can be distributed across multiple data storage devices. Each such virtualized datastore can act as a separate logical datastore, giving the user the illusion that they are the only operators and administrators of data storage resources.
0003Data center operators offering different types of virtualization computing, storage, and / or other services typically use commodity network hardware such as different types of network interface cards (NICs) to serve their customers. Relies on standard networking protocols to receive requests and send responses to such requests. Despite recent advances in virtualization technology, many networking-related characteristics of virtual servers are still typically managed at the level of individual physical network interface cards. As the complexity of different types of dynamic networking configuration changes required by virtualization service customers increases, network management at the physical NIC level can become increasingly cumbersome.
0004<figref num="1">An example system environment is shown according to at least some embodiments.</figref><figref num="2">An example of a component of an interface record according to at least some embodiments is shown.</figref><figref num="3">An operation in which an interface record is attached to a resource instance is shown according to some embodiments.</figref><figref num="4">According to some embodiments, an operation in which an interface record is detached from a resource instance is shown.</figref><figref num="5">According to some embodiments, an interface record indicates an operation in which the record is attached to a different resource instance than previously attached.</figref><figref num="6">The operation in which the second interface record is attached to the resource instance is shown according to some embodiments.</figref><figref num="7">According to some embodiments, a resource instance with an attached interface record is moved from one service platform to another.</figref><figref num="8a-8d">According to some embodiments, some network configuration examples achievable by attaching interface records to resource instances are provided.</figref><figref num="9">FIG. 5 is a diagram of some of the exemplary web-based interfaces that can be provided by a network interface virtualization coordinator according to at least some embodiments.</figref><figref num="10">It is a flow chart of the method for providing an interface record service according to at least some embodiments.</figref><figref num="11">It is a block diagram which shows the example of the computer system which can be used in some embodiments.</figref>
0005Embodiments are described herein as examples for some embodiments and exemplary diagrams, but those skilled in the art will appreciate that the embodiments are not limited to the embodiments or figures described. Let's do it. The figures and detailed description to this specification are not intended to limit embodiments to the particular form disclosed, and the intent is included in spirit and scope as defined by the appended claims. It should be understood that all modifications, equivalents and alternatives are included. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or claims. Throughout this application, the term "may" does not mean obligatory (ie, meaning must), but authoritative (ie, has the potential to). To be used in). Similarly, "include," "including," and "includes" mean inclusion, not restriction.
0006Various embodiments of methods and devices for managing virtual network interface objects are described. Providing one or more services (such as various types of cloud-based computing or storage) accessible over the Internet by entities such as enterprises or public sector organizations to a distributed set of clients. The network configured for this may be referred to herein as the provider network. Such a provider network contains a large amount of data that houses various resource pools, such as physical and virtual computer servers, storage devices, networking devices, and a collection of similar things needed to implement and distribute the services provided by the provider. May include center.
0007Several different reasons, for example, to greatly increase the flexibility in which different sets of resources can be accessed without the need for cumbersome security configuration changes, reconfiguration and / or physical movement of network interface cards. So, in some embodiments, the operator of the provider network may set up a set of virtual services for the network interface. Such services are responsible for maintaining a set of interface records to manage networking behaviors that require access to various resources of the provider network, and implementing various operations related to them. Network Interface Virtualization Coordinator It may be made possible by (also referred to in this document using the abbreviation "NIVC"). In some embodiments, different parts of NIVC functionality include hypervisor or operating system software modules running on various hardware platforms in the provider network, router software on edge devices, and the like. It can be incorporated into several different collaborative software components and / or devices.
0008In one embodiment, the provider network may provide the customer with a large number of instances of virtualized computational resources and / or storage resources, each of which is network addressed to allow the customer to interact with it. Ability may be needed. The NIVC in such an embodiment may allow the customer to require that a modifiable and transferable interface record be created, which the customer sets and then needs with various resource instances over time. Includes various types of elements of networking configuration information (eg, security policy, addressing and routing information, etc.) that you want to associate and disassociate accordingly. In some embodiments, the interface record may include one or more Internet Protocol (IP) addresses and a subnet identifier for the IP address or subnet to which the addresses belong. In addition, various security-related settings can be contained within the interface record, for example, which entity or user is allowed to perform the "attach" and "detach" operations further detailed below. Identify. NIVC may create the requested interface record and, in some embodiments, store it in a persistent repository or database of interface records.
0009The customer may, in some embodiments, require NIVC to "attach" an interface record to a resource instance, such as a virtualization compute server or storage server, thereby causing the resource instance to be the IP address of the interface record. Allows inbound traffic to be received for the resource instance to indicate that outbound traffic from the resource instance originated at that IP address. Network traffic can flow across one or more physical network interface cards (NICs) that happen to be installed on the physical platform on which the virtualized resource instance can now be instantiated, but the characteristics of the interface record are arbitrary. It is independent of a particular NIC or multiple NICs and can be considered independent of any particular resource instance. At a given point in time, for example, an interface record may or may not be associated with (ie, "attached" to) a resource instance. An interface record can exist in the NIVC repository of interface records in inactive or hibernate mode and retains its characteristics while it is not associated with any resource instance.
0010In response to a request to "detach" an interface record from the resource instance to which it is currently attached, NIVC, in some embodiments, traffic to the IP address or multiple addresses of the interface record. Can ensure that the resource instance no longer reaches. The customer may also require NIVC to now attach the interface record to a different resource instance (a different virtualization compute server) than the instance it was previously attached to. This new attach operation can then result in IP traffic targeting the IP address contained in the interface record reaching the newly attached resource instance, using the appropriate one for any pair of physical NICs. Thus, it allows customers to easily transfer network configuration settings and associated security settings across resource instances without having to deal directly with the physical NIC. Various other operations, such as modifying the IP address associated with a given interface record, modifying security settings, billing-related operations and the like, may be supported by the virtual network interface coordinator in various embodiments.
0011System environment example FIG. 1 shows an example system environment according to at least some embodiments. System 100 is configured to provide clients 148 with various types of services, such as multiple resource instances 120, such as cloud computing services or cloud storage services, with instances 120A, 120B, 120C of the provider network and May include 120D. As a result, client 148 may implement various services on instance 120, such as a website associated with a backend database, and expose them to their own customers. Resource instance 120 implements a virtualization service, such as a virtual computing system or virtual storage system, residing on one or more physical platforms, such as the service platforms 150A, 150B, and 150C in Figure 1. Can be. The service platform 150 for the resource instance 120 that provides the virtual computing system is, for example, a hardware server with one or more CPUs (and associated memory, storage and networking hardware) and virtualization of the computing system. May include software (such as hypervisor and / or operating system elements) that implements. Similarly, a service platform 150 that provides a virtual storage system may include, for example, parts or all of one or more hardware storage devices (disk arrays or storage devices), as well as associated processing elements and software.
0012In some embodiments, the resource instance 120 may be transferable from one platform 150 to another, for example, a virtual computing system is initially launched on one physical server and later as needed. Can be moved to another physical server. In addition, multiple resource instances may reside on one service platform 150, for example resource instances 120B and 120C are shown resident on service platform 150B. The physical resources (eg, CPU and network card) of service platform 150B with a plurality of resident resource instances 120 can be distributed using different methods in different embodiments. In one embodiment, some of the resources can be exclusively allocated to the resource instance, for example, if the service platform 150B has four CPUs, two CPUs can be allocated to the resource instance 120B, while others. Two can be assigned to resource instance 120C. In another embodiment, physical resources can be shared using time slices, for example, how all four CPUs have CPU cycles within a given time slice, depending on their computing demands. Can be made available by any resource instance using a scheduling mechanism configured to determine if it is distributed among the instances. In the embodiment shown in FIG. 1, each service platform 150 has one or more physical network interface cards (NICs) -the service platform 150A has a NIC 110A and the service platform 150B has a NIC 110B. , Service platform 150C has NICs 110C and 110D. Network traffic that happens to flow in and out of resource instances 120 that happen to reside on a given service platform 150 is the NIC of the service platform. Flow through one or more of 110. In some embodiments, a single resource instance 120 can be extended to multiple hardware service platforms 150, in which case any of the NIC 110s available on any of the multiple service platforms 150 will be used. obtain. In one embodiment, the resource instance 120 may include a non-virtualized server, i.e., the resource instance uses a traditional operating system running on a bare hardware service platform 150 instead of using a hypervisor. Can be implemented.
0013System 100 may include a network interface virtualization coordinator (NIVC) 180 that is capable of operating to provide a set of virtualization services for a network interface in the illustrated embodiment. Client 148 requests various types of requests, including requests to create interface records 170, attach them to resource instance 120, detach them, modify them, query them, and so on. Each of these types of operations is described in more detail below. In response to a given request 153, NIVC 180 affects resource instance 120 on interface record 170 and service platform 150, as indicated by the arrows labeled 157A, 157B, 157C and 157D. You can perform various operations to get. For example, NIVC The 180, such as 170A and 170B, each of which may contain a set of networking-related characteristics that can be associated and disassociated with various resource instances 120 upon request in response to a create request from client 148. Can generate interface records for. Interface records 170 can be generated with a set of in-memory data structures and, in some embodiments, can be stored in repository 185, such as a database on persistent storage. Interface records for networks using the TCP / IP protocol are, for example, one or more IP addresses, one or more subnet identifiers for that IP address or subnet containing multiple addresses, and more details below 1 It may include a set of security characteristics. In some embodiments, the interface record 170 identifies one or more other fields, such as various state fields, source and destination address check settings, billing-related information, and currently associated resource instance 120. It may also include the medium access control (MAC) address of the physical network interface card 110 currently associated with the interface record, and the like. Interface records for networks that employ network protocols other than TCP / IP may contain network address-related information appropriate for the protocol used.
0014In some embodiments, NIVC 180 performs an "attach" operation to dynamically associate interface record 170 with resource instance 120, thereby following traffic according to the networking and security characteristics specified in interface record 170. Can be configured to allow flow in and out of resource instance 120. In response to an attach request 153 received from client 148, for example, in one embodiment, NIVC 180 may perform some or all of the following operations: (a) specified interface records 170 and / or others. Verify that the client is authorized to request the attachment of the interface record to the specified resource instance 120, based on the security information stored in the location of; (b) Networking information of the interface record (b) Verify that the IP address or multiple addresses, subnet identifier, etc. are appropriate for activating network traffic to and from the specified resource instance 120 (for example, NIVC). 180 can check if the IP address is already in use for another instance and therefore not available); (c) Physical NIC Ensure that 110 is operational and resource instance 120 is available for use by resource instance 120 on the currently resident service platform 150; (d) Initiate or execute the required configuration changes. A particular resource instance 120 is then specified in the interface record, for example, on the service platform 150, and within the hypervisor or operating system software running on the appropriate routers, gateways and other network devices in the provider network. Allows you to start sending traffic from and / or receiving traffic at that IP address or multiple addresses; and (e) making changes to interface records 170 and / or repository 185 and performed. Reflect the attach operation. As part of the configuration change, in some embodiments, new or modified routing information, such as routing table entries, can be propagated to a set of routers, gateways, and the like. In one embodiment, NIVC 180 may ensure that each resource instance 120 has at least one interface record 170 attached to that resource instance whenever that resource instance is activated or started.
0015NIVC 180 may also, in some embodiments, be able to act to "detach" or disassociate interface record 170 from the resource instance 120 to which it is currently attached. In response to detach request 153 from client 148, NIVC 180 targeted or, in such an embodiment, the IP address or multiple addresses specified in interface record 170, or traffic from it further resource. It can be prohibited to flow in and out of the instance. NIVC to do that 180 may perform some or all of the following operations: (a) Based on the specified interface record 170 and / or security information stored elsewhere, the client may specify the interface record. Verify that you are authorized to request detach from resource instance 120; (b) Initiate or make the necessary configuration changes, eg, on service platform 150, and the appropriate routers, gateways and other Prevents network traffic associated with the IP address (s) of interface record 170 from flowing in and out of the specified resource instance 120 within the hypervisor or operating system software running on the network device; c) Make changes to interface record 170 and / or repository 185 to reflect the detach operation performed.
0016Interface records 170 that were previously attached to a particular resource instance 120 and then detached from that resource instance 120 are, in some embodiments, later at the request of the client, by NIVC 180, any desired resource instance ( It can be attached to either a different resource instance, or the same resource instance to which it was previously attached). In each embodiment, the same IP address first sends and receives traffic on one resource instance 120A through a particular NIC 110A during one "attachment period", followed by a subsequent "attachment period". It can be used to send and receive traffic on different resource instances 120B, potentially through different NICs 110B and / or on different service platforms 150. In addition to allowing clients to map a given IP address to different resource instances 120 at different times, NIVC The 180 may also allow the client to reuse some or all of the security settings associated with the interface record 170, thus the effort and complexity required to make networking configuration changes. Is substantially reduced. In many embodiments, multiple interface records 170 may be attached to a single resource instance 120, thus allowing multiple IP addresses to be used for the same resource instance. In some embodiments, a single interface record 170 can be attached to multiple resource instances 120 at the same time: for example, NIVC 180 is traffic destined for a single IP address specified in interface record 170. Can be distributed or load-distributed across two or more resource instances 120. Using these features of NIVC 180, highly flexible mapping of IP addresses, subnets, and network security settings to resource instance 120 can be implemented in various embodiments.
0017Interface record component example FIG. 2 shows an example of the components of interface record 170 according to at least some embodiments. Only a subset or fields of the elements shown in Figure 2 can be implemented in some embodiments, and not all implemented fields need to be populated (ie, some of the fields are left blank or empty). Can be). If interface record 170 is created, a new interface identifier 201 may be created for it. In some embodiments, the description field 202 may be filled in, for example, "Interface 1 for a news website" by the client 148 requesting the creation of an interface record. The provider network in which the interface record is used may include, in some embodiments, multiple logical partitions, the interface record 170, in which case the logical partition identifier 203. For example, a provider network operator may use a logical partition for a particular customer for the exclusive use of a set of service platforms 150, a set of network address ranges, other equipment or resources, and network management capabilities by that customer. By ensuring, it can be established to its own isolated and dedicated equipment, even if the equipment used by the customer can actually reside in a facility shared by other customers. Efficiently provide a data center or multiple centers. Logical partitions, in some embodiments, may include geographically dispersed resources, thereby providing customers with the benefit of access to a virtual private "cloud" of resources. In some cases, the interface record 170 may include an area identifier 204, which indicates, for example, a set of geographic regions or data centers in which the service platform 150 may be available for attachment to the interface record 170. ..
0018Any of the several types of network address related fields may be included in interface record 170 in different embodiments. One or more private IP addresses 205 may be specified for interface records in some embodiments; these IP addresses may be used internally for routing within the provider network and of the provider network. Not directly accessible from the outside. One or more public IP addresses 215 may also be included in some embodiments; these IP addresses are outside the provider network, eg, for various routers on the public Internet or peer networks of the provider network. , Can be visible. Any desired device or component, including, for example, a component of NIVC 180, to translate between public IP address 215 and private IP address 205, as required, in different embodiments. Network address translation technology or multiple technologies may be implemented. One or more subnet identifiers 225 may be included in the interface record.
0019The term subnet is a logically visible subdivision of a network, as is widely used herein. For IP networks, a set of logical or physical devices belonging to a subnet may be addressed in a common, identical, most significant bit group within their IP address. This results in a logical split of the IP address into two fields: the network or routing prefix and the "remaining" field. The remaining fields can serve as specific identifiers for logical or physical devices. The routing prefix can be represented in Classless Inter-Domain Routing (CIDR) notation, which can be written as the first address of the network, followed by the bit length of the prefix separated by a slash (/). For example, 10.1.1.0/24 is an Internet Protocol version 4 network prefix starting at address 10.1.1.0, with 24 bits assigned to the network prefix and the remaining 8 bits reserved for the device identifier. .. In IPv4, the routing prefix can also be specified in the form of a subnet mask, which is an address-like, four dot-separated decimal representation. For example, 255.255.255.0 is 10.1.1. The network mask for the 0/24 prefix. Slightly different notations can be used for IP version 6 networks and for networks that use protocols other than the TCP / IP suite. Subnets are generally hierarchically structured for easier management of logical partition resources (such as virtual private clouds) for a variety of reasons (eg, to provide logical isolation between different sets of network addressable devices). To place in, etc.), can be used. The subnet identifier 225 contained within the interface record 170 may, in some embodiments, include or encode a CIDR representation for the subnet as a result of a stringeg, subnet-df543fda-10.1.1.0. / 24 "can be included. In one embodiment, a domain name server (DNS) may also be included in interface record 170.
0020In some embodiments, interface record 170 may include security-related property 235. Some provider networks have rules that allow users, for example, firewall-related rules for the types of ingress and / or outbound traffic that interface record 170 is allowed on resource instance 120 to which it can be attached. It can be possible to specify; Such a rule may be referred to as a "security group" and may be identified in security group (s) field 245. Various port and protocol constraints can be enforced using such rules, and multiple rules can be associated with each interface record. For example, to ensure that only HTTP and HTTPs inbound or ingress traffic is allowed, the user limits the set of TCP or UDP (User Datagram Protocol) ports that traffic is allowed to. Security groups can be used, such as to filter inbound and outbound traffic according to various policies. In some embodiments, an attacher list 247 can be specified to indicate which user or entity is allowed to request attachment of interface record 170 to resource instance 120. In some cases a separate detacher list can be used to specify which entity can detach interface record 170, while in other cases a single detacher such as attacher list 247. The list can be used to identify authorized attachers and detachers. A set of users or entities that are allowed to set or modify the IP address of interface record 170 (eg, public IP address 215 and / or private IP address 205) is provided in IP address setter list 249. In some embodiments, the set of users or entities that own the interface record 170 (or its various other fields can be modified) can be specified in the owner / modifier field 253. For example, the owner / modifier identified in field 253 may be allowed to modify the attacher list 247 or the IP address setter list in some embodiments, thus attaching the interface record. Or detach , Or change the set of entities that are allowed to modify their IP address (s). The term "list" is used for fields 247, 249, and 253, but in various embodiments, non-list logical data structures (such as arrays, hashtables, pairs and the like) It can be used to represent a group of entities given various security privileges, roles and / or functions.
0021In some embodiments, the user may be allowed to "terminate" the resource instance 120. For example, client 148 configures a virtual compute server resource instance 120, attaches interface record 170 to that instance, performs the desired set of computations on that instance, and then performs that instance when the desired computation is complete. Can issue a request to terminate (thus indicating that resource instance 120 is no longer requested). In such an embodiment, the "delete on exit" setting 251 is used to specify what happens to the attached interface record 170 at the end of the resource instance 120. If delete on exit is set to "true" for the interface record 170 attached to the terminated resource instance 120, NIVC 180 may delete the interface record 170 (eg, the record is from repository 185). Can be removed). NIVC if delete is set to "false" on exit 180 may hold interface record 170 so that it can be reattached to, for example, some other resource instance. In one embodiment, when the interface record 170 is attached to the resource instance 120, an attach record separate from the interface record can be created to represent the relationship, and the delete characteristic at the end of the association with the interface record. Alternatively or in addition, it can be associated with an attached record. In such an embodiment, the interface record 170 may include an attach record or a reference or pointer to each attach that the interface record is currently involved in, with different values for "delete on exit" for each attach record. Can be set. In such an environment, an instance record 170 that happens to be unattached to any resource instance 120 does not have the "delete on exit" property associated with it, as long as it remains unattached. By persisting the interface record independently of the resource instance in this way, the overhead of setting various security-related and other characteristics can be reduced for the client 248 each time a new instance is activated. ..
0022In one embodiment, the interface record 170 is an indicator of whether source and / or destination checking is performed on network packets transmitted to the resource instance 120 to which the interface record 170 is attached, such as 265. May include routing related information. If the source / destination check setting is set to "false" or "off", routing decisions can be made based on the source and destination IP addresses of the packet, for example, the packet is separate from one subnet. Can be transferred to the subnet of; if the setting is set to "true" or "on", in some embodiments the resource instance does not perform routing. Thus, the source / destination field 265, in some embodiments, determines whether or which the resource instance to which the interface record is attached performs a routing or gateway function on a packet to which it is not the final destination. It can be used to control whether packets are ignored. In other embodiments, other types of routing-related information, such as routing table entries, may also be included in interface record 170, or instead. Billing-related information 267 may be included in some embodiments, for example, identifying an entity or user to be charged for network traffic associated with interface record 170. In some embodiments, customers may be billed based on at least a portion of the number of instance records 170 they create, regardless of how many instance records are attached to the resource instance; in other embodiments. Billing may include both recurring charges (eg, based on the number of instance records and / or number of attached instance records) and non-regular charges (eg, based on traffic flow measurements).
0023The interface state field 268 can be used to indicate the current state of interface record 170-for example, whether the interface record is "available," "invalid," or "in-repair." Similarly, the attach state field 269 is used in some embodiments to indicate whether the interface record 170 is currently attached, detached, or in the process of being attached or detached. obtain. In one embodiment, as described above, a record of attachment (apart from interface record 170) can be created when the corresponding attach operation is performed, and the current attach identifier or plurality of interface record 170. The identifier can be stored in the attached id field 271. The identifier of the resource instance or multiple instances 120 to which the interface record 170 is currently attached may be stored in the attached instance field 273, and in some embodiments the user or entity requesting the attachment attaches. Can be identified in owner field 275. In one embodiment, a list of identifiers of NICs or NICs 110 currently available for / from the IP address of interface record 170 is, for example, in MAC address (s) field 277. In the form, it can be retained. In some embodiments, monitoring information 279, such as statistics about the amount of traffic flowing to or from the IP address of the interface record, may also be retained in the interface record. In various embodiments, other fields not shown in FIG. 2 may be included in interface record 170. In some embodiments, the client uses the VLAN standard (802.) to implement network isolation. Tags can be associated with interface record 170, such as virtual local area network (VLAN) tags formatted according to the 1Q standard). In such embodiments, such tags may also be stored in or referenced from interface record 170.
0024In one embodiment, some of the fields shown in FIG. 2 may be replaced with references or pointers to other objects. For example, security information for interface record 170 may be stored in a separate security object, and interface record 170 may store a reference to that security object. Similarly, each attachment of resource instance 120 to interface record 170 can be represented by an attach object, and in some embodiments, the interface record can be a pointer or reference to the appropriate attach object.
0025Attach, detach, and instance move operations 3-7 show some types of operational examples supported by the NIVC 180 in various embodiments. FIG. 3 shows an operation in which the interface record 170 is attached to the resource instance 120 according to some embodiments. Attach request 301 can be sent by client 148 to NIVC 180 to identify interface record 170A and resource instance 120A to which that interface record is attached. In FIG. 3, the notation "++" for request 301 (as in "170A ++ 120A") indicates that the request is an attach request. Upon receiving the request, NIVC 180 can verify that the requesting client is authorized to request the attach, and that the addressing and other information in the interface record is valid, and then specified in interface record 170A. According to the details, the necessary configuration changes can be initiated to allow traffic to flow in and out of resource instance 120A. The operation performed by NIVC 180 in response to attach request 301 is indicated by the arrow labeled 311 and the attach indicator 321 in FIG. As mentioned earlier, some configuration changes have been made, for example, on the hypervisor or operating system on platform 150A where the resource instance 120A resides, and on various networking devices such as routers and gateways in the provider network used. , Can need to be done and / or propagated. In some embodiments, the interface record 170A itself is, for example, interface state 268, attach state 269, attach ID. It can be modified by changing the values of various components such as 271, attached instance 273, attach owner 275, and / or MAC address field 277. In the illustrated example, the MAC address field 277 of the interface record can be set to the MAC address of NIC 110, which is available by resource instance 120A, as indicated by the dashed line surrounding the NIC.
0026Interface record 170 may, in one embodiment, be attached to resource instance 120 at many different stages of resource instance lifetime. For example, resource instance 120 may be in a running state following boot when a particular interface record is attached to it (and to a request received at the IP address of another interface record to which it is already attached. It may already be in service). In some embodiments, NIVC 180 is that interface record 170 is attached to resource instance 120, even if resource instance 120 is not currently on or running-for example, if resource instance is stopped or suspended, or in the process of being activated. Can be allowed to run. In such cases, network interface records can be attached to the resource instance, for example, before the resource instance is activated or booted, and even before the service platform 150 on which it is launched is selected. If insufficient information is available when an attach operation is requested-for example, if the MAC address of the NIC used or multiple NICs is not yet known-NIVC 180 will continue until the value is actually available. , Some fields in interface record 170A can be left blank or empty. In some embodiments, NIVC 180 can generate and / or store records or data structures for each attach-for example, an object with an associated attach identifier can be stored in repository 185 or some other database and the attach operation Identifies resource instance 120A, interface record 170A, and other information about attachments, such as when started or completed. In some embodiments, a given client 148 may have a set or pool of interface records 170 available for the client's resource instance 120, for the client to attach to the specified resource instance 120. Can simply require NIVC 180 to select an available interface record 170 from a pool of interface records.
0027The IP address used for the resource instance 120 attached to the interface record 170 may, in some embodiments, be modifiable after the attach operation is complete. For example, a user or entity identified as authorized to change an IP address, such as public IP address 215 or private IP address 205, makes an IP address correction request to NIVC. Upon sending to 180, NIVC may make the necessary configuration changes required for the requested changes to take effect. For example, upon receiving an IP address modification request for interface record 170, NIVC first determines which resource instance 120 (if any) is currently attached to interface record 170, and then targets the modified IP address. The traffic can make the necessary changes to the interface record 170 itself, allowing the traffic to reach those resource instances (s). In one embodiment, one or more of the IP addresses associated with interface record 170, such as either public IP address 215 or private IP address 205, is assigned to that client by NIVC 180 on behalf of the client. It can be selected from a set of IP addresses.
0028FIG. 4 shows an operation in which the interface record 170 is detached from the resource instance 120 according to some embodiments. Detach request 401 can be sent by client 148 to NIVC 180 to identify interface record 170A and resource instance 120A from which the interface record is detached. In FIG. 3, the notation "-" (as in "170A--120A") for request 401 indicates that the request is a detach request. Upon receiving the request, NIVC 180 may, in some embodiments, first verify that the specified interface record 170A is actually currently attached to resource instance 120A. NIVC if interface record 170A is not attached to resource instance 120A 180 can either send the error message back to the requesting client 148, or, in some embodiments, simply write the request to the log and / or ignore it. If interface record 170A is attached to resource instance 120A, NIVC 180 may check that the requesting client is authorized to request detach, and then the details specified in interface record 170A. Therefore, the necessary configuration changes can be initiated to stop traffic from flowing in and out of resource instance 120A. The operation performed by the NI VC 180 in response to the detach request 301 is indicated by an arrow labeled 411 and an "X" on the attach indicator 321 in FIG. The detach configuration change can actually simply undo the aforementioned attach configuration change. The interface record 170A itself, in some embodiments, is, for example, interface state 268, attach state 269, attach ID. It can be modified by changing the values of various components such as 271, attached instance 273, attach owner 275, and / or MAC address field 277. In the illustrated example, the MAC address field 277 of the interface record can be set to an empty string when detached.
0029In some embodiments, the detach request 401 may not explicitly specify the interface record 170A to be deleted-instead, the requesting client simply specifies any attached interface record 170A. It can indicate that it should be detached from the resource instance 120 that was created. In such cases, NIVC The 180 can act to first discover which interface record 170 should be detached from the specified resource instance 120, for example by retrieving information in repository 185, and then initiate the detach operation. Can be. Such a request (to detach all attached interface records 170) can be generated, for example, if the resource instance is shut down, disabled, terminated, or destroyed. .. In some embodiments, the interface record itself may be deleted from repository 185 if the Delete on Exit field is set to True for interface record 170 and the attached resource instance 120 is terminated. Otherwise, if Delete on Exit is set to False, the interface record may be kept in the repository along with its properties for possible subsequent reuse. As mentioned above, in some embodiments, the "delete on exit" property can be associated with an attach record that the interface record can refer to, instead of being associated with the interface record itself. In some embodiments, detach request 401 does not necessarily indicate resource instance 120A, and the specified interface record 170A should be detached from any resource interface 120 (if any) that happens to be attached. Can only show.
0030FIG. 5 shows an operation in which interface record 170A, previously attached to one resource instance 120A and then detached, is attached to a different resource instance 120C, according to some embodiments. Attachment request 501 may be sent by client 148 to NIVC 180 to identify interface record 170A and resource instance 120C to which that interface record is attached. In FIG. 5, as in FIG. 3, the notation "++" (as in "170A ++ 120C") indicates that the request is an attach request. Upon receiving the request, the NIVC 180 may perform a function similar to that described above in connection with the description in Figure 3, this time with interface record 170C as a different service platform than the previously attached instance 120A. Attach to resource instance 120C residing on (150B) and use a different NIC (NIC 110B, as indicated by the dashed line in Figure 5). NIVC in response to Attach Request 501 The operation performed by 180 is indicated in FIG. 5 by an arrow labeled 511 and an attach indicator 521. The use of interface record 170, which can be dynamically attached to different resource instances 120 (and dynamically change the NIC 110 used), is NIVC, as described in the use case section below. The 180 enables clients 148 to provide significant flexibility in the network architecture used for their applications and the opportunity to work across business boundaries. For example, in one environment, resource instance 120 may be configured to handle web service requests for a particular application from a customer. In such an environment, as shown in FIG. 4, the interface record 170A is simply detached from one resource instance 120A, and then the interface record is different, while keeping the IP address (s) of the interface record 170A unchanged. By attaching to resource instance 120C, the workload of incoming web service requests that was previously processed by resource instance 120A can now be processed by resource instance 120C. This means that client 148 has enhanced availability if, for example, resource instance 120A experiences an outage or failure, or enhanced version of the web service application if resource instance 120C has an enhanced version. It may be possible to provide an easy-to-use mechanism for deployment.
0031In some embodiments, NIVC 180 may allow multiple interface records 170 to be attached to the same resource instance 120. FIG. 6 illustrates one such embodiment, where the second interface record 170B is attached to the resource instance 120C to which the interface record 170A is already attached. In response to attach request 601 the NIVC 180 may perform a function similar to that described for attach request 301 in Figure 3, thereby according to the characteristics of both interface records 170A and 170B, the resource instance. Network traffic to and from 120C will eventually flow. The operation performed by NIVC 180 in response to attach request 601 is indicated by an arrow labeled 611 and an additional attach indicator 621 in Figure 6. In the example shown in Figure 6, a single NIC 110B is used to handle traffic for both attached interface records 170A and 170B. In some embodiments, the mapping between interface record 170 and physical NIC 110 can be flexible: that is, traffic flowing through a given NIC 110 can accommodate any number of interface records 170. , Traffic for a given interface record 170 can flow through multiple physical NICs 110.
0032In some embodiments, the resource instance 120 may be transferable across service platforms 150 while retaining at least some of their attached interface records 170 and corresponding networking related characteristics. Figure 7 shows the operation of moving a resource instance 120A with attached interface record 170A (previously as shown in Figure 3) from one service platform 150A to resource instance 150C, according to at least some embodiments. Shown. In Figure 7, client 148 sends an "instance move" request 701 to instance manager 780 on system 100, where resource instance 120A, which was previously resident on service platform 150A, is now on service platform 150C. Indicates that it should be resident. The notation "" for request 701 (as in "120A 150C") indicates that the request is a move request. Upon receiving the request, Instance Manager 780 receives the NIVC. With 180, it may perform the tasks required to implement the requested move. For example, move request 701 can be validated to ensure that the requester has the correct permissions, and resource instance 120A is then either suspended or the incoming request is temporarily queued. Can be in a state of being. Resource instance 120A can then be launched or enabled on service platform 150C and traffic destined for the attached interface 170A IP address (s) will be on the appropriate NIC or on service platform 150C. The configuration changes required to allow flow through multiple NICs 110 can then be initiated. In the example shown in Figure 7, traffic entering and exiting resource instance 120A is NIC after the instance has moved. Routed through 110C (in some embodiments, the MAC address field of interface record 170A may be modified to reflect this). In this way, the networking characteristics of the resource instance (ie, the networking characteristics of its attached interface record) can be made substantially independent of the actual networking hardware used. Although a separate instance manager 780 is shown in Figure 8, the ability to move resource instances can, in some embodiments, be managed with the interface virtualization feature, i.e. the same software and / or hardware entity. It also supports resource instance management operations and interface record management operations.
0033Use case example The ability to dynamically attach and detach one or more interface records 170 with a specified IP address and subnet to a resource instance 120 is enabled by the features described above, allowing customers to have several different Allows easy setup of useful types of network configurations. 8a-8d provide diagrams of some such network configuration examples that can be achieved according to some embodiments.
0034The networking configurations shown in Figures 8a-8d show three different configurations or hierarchy levels for a provider network that may contain resource instance 120: logical partition level, subnet level, and interface record level. The operator of such a provider network is one that a given customer, such as a company or organization that wants to take advantage of virtual computing and / or virtual storage services supported by the provider network, is dedicated to its use by that customer. You may be allowed to set up one or more logical partitions. Logical partitions can be used, for example, for a relatively large set of service platforms 150 and various resource instances 120 that can be launched on those service platforms, as required by the customer. IP address may be included and the customer may be provided with network management functions for the set of resources. In some embodiments, for example, a set of IP addresses for a logical partition can be specified as a "/16" block, such as "10.1.0.0/16" in CIDR notation, which can be up to 65, Indicates that 536 IP addresses may be available for that logical partition. A logical partition can be referred to as a "virtual private cloud" in some embodiments. A logical partition may, in some embodiments, have one or more gateways set up for it, such as an internet gateway or a virtual private network (VPN) gateway. In addition, in some embodiments, a default DNS server may be set up for each logical partition, and one or more subnets and routing table entries may also be set up when the logical partition is set up. For example, in one embodiment, when a customer requests that a logical partition with a "/16" block be set up, the customer also has a CIDR specification for at least one "/24" subnet set up within the logical partition. You may be required to specify. The "/24" subnet (eg, "10.1.1.0/24") contains 256 IP addresses. Customers who set up logical partitions instead, in some embodiments, perform a wide variety of network management tasks, such as setting up subnets of various sizes, and creating, attaching, and detaching interface records 170 as needed. You may be allowed to do it as needed. Different logical partitions and subnets can be set up to achieve different levels of logical isolation: For example, a customer may want to isolate software development build-related network traffic from corporate email network traffic, and to do so, may set up an appropriate hierarchical structure of logical partitions and subnets. In one embodiment, the CIDR specification may refer to a private IP address for interface record 170 (eg, stored in field 205, shown in FIG. 2), while a public IP address (stored in field 215). Can be selected according to other policies. Identifiers for subnets (field 225 in FIG. 2) and logical partitions (field 203) may be stored in interface records in some embodiments. In some embodiments, some or all of the interface record addressing information (logical partition identifier, subnet identifier, private and / or public IP address) can be dynamically modified after the interface record 170 is created. obtain.
0035Use Case Scenario 1: Multiple IP Addresses in a Single Subnet Figure 8a shows a simple networking configuration in which two interface records 170A and 170B are associated with a single resource instance 120A within subnet 811A, according to one embodiment. Interface record 170A is shown with IP address example xxx9, and interface record 170B is shown with IP address example xxx10 (the common notation "xxx" for the two addresses is in this case the first three of the two IPV4 addresses. It means that the elements separated by dots are the same, for example, the two addresses can be 11.2.3.9 and 11.2.3.10.). As shown, by attaching multiple interface records 170, as many different IP addresses as needed can be associated with the same resource instance in some embodiments. This can be useful, for example, to separate traffic to different applications or application instances by IP address. In one environment, for example, several different websites can be set up on a single resource instance 120, each with its own IP address. In another embodiment, the customer may have multiple web servers serving the same underlying content set up on a single resource instance 120 and wants to associate each web server with a different IP address. obtain.
0036Use Case Scenario 2: Attaching to Multiple Subnets in a Single Logical Partition FIG. 8b shows a configuration in which two interface records 170A and 170C from different subnets are associated with a single resource instance 120A according to one embodiment. Interface record 170A is shown with IP address example xx0.9 in subnet 811A, and interface record 170C is shown with IP address xx1.10 in different subnet 811B. This type of configuration can be useful, for example, in an environment where network management traffic flows through one subnet 811A, while application data traffic flows through another subnet 811B, where each subnet has different security characteristics. .. In one such case, subnet 811A for network management traffic may have stricter security rules and access controls than subnet 811B used for application data. In another example, resource instances 120 attached to multiple subnets 811 can also be configured to perform various network security functions. For example, if traffic from the first subnet 811A needs to be routed through the resource instance 120 to the second subnet 811B, the resource instance implements a firewall to act as an antivirus gateway. Intrusion detection and / or other types of network traffic analysis, filtering, or monitoring can be performed.
0037A configuration similar to that shown in Figure 8b can also be used in some embodiments to dynamically and efficiently move resource instance 120 from one subnet to another. For example, a customer can set up an application server instance on resource instance 120A attached to interface record 170A in subnet 811A dedicated to the software development environment and deploy an updated version of the application on that application server instance. obtain. If the customer wants to start a quality assurance (QA) inspection for the updated version and the QA inspection environment is in subnet 811B, which is separate from development subnet 811A, the following steps can be taken. First, a second interface record 170C from subnet 811B can be attached to resource instance 120A. Interface record 170A can then be detached from resource instance 120A, thus allowing inspection to be performed only within the desired QA subnet without having to deploy updated versions on different resource instances. To. Similarly, applications can be easily moved through other development lifecycle phase transitions, such as from a QA environment to a manufacturing environment.
0038In one environment, a customer may store confidential data on a pair of front-end web servers or other resources accessible from an external network (ie, a device outside the provider network that contains resource instance 120), etc. You may want to separate it from a set of back-end servers in this way to prevent direct network access to the back-end servers from external networks. In such cases, the resource instance 120A of FIG. 8b may use subnet 811A for front-end traffic and subnet 811B for back-end traffic in some embodiments. Thus, requests for web services can be received via subnet 811A on a web server running on resource instance 120A, and the corresponding backend requests required to fulfill those requests are within subnet 811B. Can be sent to the backend server of. Responses from the backend server can be received from subnet 811B and sent back to the requester via subnet 811A.
0039In some embodiments, instance 120 attached to multiple interface records 170 in different subnets can also be used as a router. For example, a packet received on a resource instance has a source IP address that is reachable from the resource instance through one subnet and a destination IP address that is reachable through another subnet, and is required. If properly configured (for example, if the routing table entry is properly set up), the instance can route the packet through the second subnet to the destination address.
0040Use Case Scenario 3: Attaching to Multiple Logical Partitions for the Same Customer Figure 8c shows a configuration in which two interface records 170A and 170D from different logical partitions 801A and 801B set up for the same customer (customer A) are associated with a single resource instance 120A according to one embodiment. Shown. Interface record 170A is shown with IP address example 10.0.0.9 in subnet 811A of logical partition 801A, and interface record 170D is shown with IP address 172.16.1.10 in subnet 811B of different logical partition 801B. This type of configuration can be useful for several purposes. The two logical partitions 801A and 801B, on behalf of Customer A, for any of a variety of reasons-for example, a demilitarized zone where Customer A's private intranet traffic is exposed by Customer A to their own customers. (DMZ) May have been set up to isolate traffic targeted to the network. In such an environment, the resource instance 120A of FIG. 8c may be configured to perform interpartition routing, for example. In some embodiments, the customer may want the service to be provided by a resource instance 120A accessible from the devices in the two logical partitions, which uses a configuration similar to that of Figure 8c. Can also be made possible.
0041Needless to say, some of the other features supported by NIVC 180 described in use cases 1 and 2 above can also be extended across logical partition boundaries using the type of configuration shown in Figure 8c. For example, in various embodiments, multiple IP addresses may be provided for a given resource instance 120 within two different CIDR / 16 address ranges, the resource instance may be moved across logical partitions, and so on. .. Resource instance 120A may, in some embodiments, also provide a proxy service across logical partition 801 or be used to implement a management network that is in a logical partition separate from the data network.
0042Use Case Scenario 4: Attaching to a different customer's logical partition NIVC 180 may, in some embodiments, be able to provide several bridging services across logical partitions set up for different customers. Figure 8d shows that two interface records 170A and 170E from different logical partitions 801A and 801B (partition 801A for customer A and partition 801B for customer B) set up for each customer according to one embodiment are single. Shows the configuration associated with resource instance 120A in.
0043The features shown in Figure 8d can enable several different collaborative scenarios. In one example, customer A and customer B may be working together on a project. Customer A may have a content server application deployed on resource instance 120A in their logical partition 801A. Customer B may want access to its content server application, but neither company may want to expose this server to the public Internet. Alternatively, customer B may create an interface record 170E in their own logical partition 801B and set permissions on that interface record 170E to allow customer A to attach to it. Customer A may attach interface record 170E to resource instance 120A running the content server within customer A's logical partition 801A. In this way, both customers can securely access the content server without having to make major changes. In addition, Customer A may, in some embodiments, use the security characteristics of Interface Record 170E to ensure that only HTTP and HTTPS ports are available to Customer B, or as required. In other ways, access from customer B's logical partition can be restricted.
0044In the second scenario where peering between customers can be enabled, customer A and customer B may be working together on several projects and may want to have private access to each other's logical partitions. is there. In one such embodiment, customer A may launch a gateway application (such as a firewall or router) on resource instance 120A, and customer B may create interface record 170E. Customer A, the gateway application owner, may attach interface record 170E to resource instance 120A so that both logical partitions are connected through dual homed resource instance 120A running the gateway application. This scenario can impose some constraints on the IP address range of two customers' logical partitions-for example, in some embodiments, if they have overlapping IP addresses, some form of network address translation will occur. May be needed. In some environments, the resource instance 120A may be hosted on a dedicated network device (eg, a router device or firewall device).
0045Cross-partition The attachment) feature can also be used in some embodiments to provide technical support. In one such scenario, customer A may be using an application from vendor X on resource instance 120A, where vendor X is also a customer of the operator of system 100. Customer A may have encountered an application-related issue and may want to receive hands-on support from Vendor X. Customer A may contact Vendor X, who may create interface record 170E in their own logical partition and grant Customer A permission to attach it. Customer A can attach their resource instance 120A to Vendor X's interface record 170E, so for example, Vendor X can use Secure Shell (SSH) or Remote Desktop Protocol (RDP) to address the issue. You can access an application and perform troubleshooting as needed. Such support may be supported without using an internet gateway or virtual private network gateway to access customer A's logical partition. In addition, customer A, in some embodiments, uses the security characteristics of the egress policy (eg, interface record 170E) to prevent any traffic being carried from resource instance 120A to vendor X's logical partition 801B. ) Can be modified. This can prevent Vendor X from inadvertently or intentionally accessing other resources within Customer A's logical partition 801A.
0046A managed service provider (MSP) may also be able to take advantage of the interpartition attach feature in some embodiments. MSP (Customer A) may host an application within its own logical partition (eg, 801A) and attach to interface record 170 within their customer's logical partition (eg, MSP Customer B's Partition 801B). In this way, it provides MSP customers with endpoints within their own partition to access MSP applications. MSPs may retain control of the resource instance (eg 120A) that runs their application, while MSP customers can access MSP applications via IP addresses in the MSP customer's network space. possible. MSP applications can include any variety of different types of services, such as customer relationship management (CRM), content management, collaboration, databases and the like.
0047In addition to the examples shown in FIGS. 8a-8d, the features of NIVC 180 may enable other types of services in various embodiments. For example, if the first resource instance 120 attached to interface record 170 fails or goes down, a kind of high availability (HA) makes interface record 170 similar to the first resource instance. It can be implemented by attaching to a second resource instance that can provide the service. In embodiments where System 100 supports a variety of services, such as relational database services, map reduce or other distributed or parallel computing services, deployment services or load distribution services, resources attached to the logical partitions of multiple customers. Instance 120 can be used to implement management and control services for various services. Such management services may be referred to as "control plane" features and are used to carry unmanaged application data or user data. It is distinguished from "plane)".
0048Web interface example In some embodiments, the NIVC 180 may be capable of operating to implement one or more interfaces that define and support some or all of the services associated with the interface records described above. For example, one or more application programming interfaces (APIs) may be implemented, or different types of graphical user interfaces (GUIs) or command line interfaces may be provided in different embodiments. FIG. 9 is a partial diagram of an exemplary web-based interface that can be provided by NIVC 180 according to at least some embodiments.
0049Web page 900 of FIG. 9 contains several form fields that client 148 can fill out to provide details of the interface record creation request. Area 903 of web page 900 may provide friendly greetings and summary messages. Form field 904 may allow the client to specify a name and description for the interface record. In an embodiment where a logical partition is implemented, form field 905 may be provided to allow the client to specify the logical partition for the requested interface record 170. In some embodiments, a set of logical partition identifiers, for which the client 148 is authorized to choose one from it, may be automatically made available, for example, via a drop-down menu. , And / or field 905 may be prefilled with a default logical partition identifier that the client can modify. Form field 909 can be used to specify a subnet identifier for an interface record. One or more IP addresses (including private and / or public IP addresses) can be specified using form field 917. Form field 921 can be used to specify various security characteristics, such as security groups, lists of entities that are allowed to attach to interface records, and the like. Field 925 can optionally be used to identify the resource instance 120 to which the interface record is attached. As in the case of field 905, some other fields on web page 900 can also be pre-filled with default values and / or allowed selections, but in some embodiments, drop. It may be provided via a down menu or a similar mechanism. Input button 931 submits an interface record creation request.
0050NIVC 180 may, in one embodiment, generate values for some or all fields that may be left unfilled by the requesting client 148. In some embodiments that employ a web-based interface, several different web pages may be adopted during the process of creating an interface record. When a client fills out one form entry, NIVC 180 may allow to customize or narrow the set of choices available for subsequent form entries. In some embodiments, submitting form data via an interface such as web page 900 can result in invoking one or more API calls that can be supported by NIVC 180.
0051An interface similar to that shown in FIG. 9 for creating interface record 170 is provided by NIVC 180 in various embodiments, such as attach, detach, delete, IP address change, and the like. It may also be provided for other types of operations that are supported. In some embodiments, client 148 determines the state of interface record 170, identifies interface record 170 attached to a given resource instance 120, and is set up by client 148 within a given subnet or logical partition. Can be allowed to submit queries to make a list of all the interface records etc.
0052Method for interface record manipulation FIG. 10 is a flow diagram of a method for providing an interface record operation according to at least some embodiments. Interface virtualization services can be implemented, for example, in the form of NIVC 180, as shown in element 1800 in the flow diagram. In some embodiments, the service is a software and / or hardware component, for example, via a component of hypervisor software, operating system software, or routing software that runs on various devices in the provider network. Can be implemented by a combination of. As shown in element 1805, one element of service may be configured to wait for an interface virtualization request, which may be received, for example, through a web-based interface similar to that shown in FIG.
0053Depending on the particular type of request received, the appropriate set of actions may be taken in response. For example, when a request to create a new interface record is received (element 1810 in Figure 10), such record 170 can be instantiated and optionally stored in the repository (element 1815). When a request to attach an existing interface record is received (element 1820), the flow of traffic to and from the IP address or multiple addresses specified for that interface record is requested to attach to it. Can be enabled on resource instance 120 (element 1825). When a detach request is received (element 1830), traffic to and from the IP address (s) of the interface record can be invalidated on the resource instance to which the interface record is attached (element 1835). When a request to delete an interface record is received (element 1840), the record can be deleted, for example, from repository 185 (element 1845).
0054When a request to modify an interface record (eg, change the IP address) is received (element 1850), the record can be modified as requested and any necessary configuration changes can be initiated (element). 1855). Upon receiving an interface record query (eg, to determine the state of an interface record or multiple records) (element 1860), a response to the query can be generated and provided (element 1865). In each case, appropriate authorization and security checks may be performed before performing the requested or multiple actions. In some embodiments, some type of interface record operation may be implemented as an idempotent operation, eg, a first request to change the IP address to ABCD is received and the same change. If the second request continues, the second request has no effect. In some embodiments, an error message may be generated when an unexpected, unsupported, unlicensed, or otherwise invalid request is received. After responding to a given request, the service then waits for the next interface virtualization request. In some embodiments, the functional parts shown in FIG. 10 can be implemented in parallel, eg, two or more requests can be processed simultaneously. In some embodiments, several requirements may be combined-for example, a single requirement for both creating and attaching instance records may be supported.
0055Examples of embodiments can be described with the following additional notes in mind: Addendum 1. Multiple resource instances, including a first resource instance and a second resource instance, With network interface virtualization coordinator It is a system equipped with Network Interface Virtualization Coordinator: In response to an interface record creation request, generate an interface record containing the first Internet Protocol (IP) address, the subnet identifier of the first subnet containing the first IP address, and the first set of security characteristics. Storing interface records in a subnet and In response to the first attach request to attach the interface record to the first resource instance, the first resource instance sends traffic for the first IP address according to the security characteristics of the first set. To be able to receive through the first network interface card, Preventing the first resource instance from receiving traffic destined for the first IP address in response to a detach request to detach the interface record from the first resource instance. In response to a second attach request to attach an interface record to a second resource instance, the second resource instance sends traffic destined for the first IP address according to the security characteristics of the first set. To be able to receive through a second network interface card A system that can operate to do. Appendix 2. Network Interface Virtualization Coordinator: In response to the second interface record creation request, a second interface record containing the second IP address is generated, and the second interface record is stored in the repository. Allowing the first resource instance to receive traffic destined for the second IP address in response to a new attach request to attach the second interface record to the first resource instance. When The system according to Appendix 1, which is further operable to do so. Appendix 3. The system according to Appendix 2, wherein the second IP address is part of the second subnet and the second interface record contains the subnet identifier of the second subnet. Appendix 4. Network Interface Virtualization Coordinator: The first resource instance receives a network packet from the source IP address, the source IP address is reachable from the first resource instance via the first subnet, and the network packet. To receive a network packet from a source IP address that has a destination IP address reachable from the first resource instance via the second subnet. To route network packets through a second subnet to a destination IP address The system according to Appendix 3, which is further operable to do so. Appendix 5. The Network Interface Virtualization Coordinator, where the interface record contains one or more additional IP addresses and in response to the first attach request to attach the interface record to the first resource instance. However, the system according to Appendix 1, wherein the first resource instance can be further operated to allow it to receive traffic destined for one or more additional IP addresses. Appendix 6. Network Interface Virtualization Coordinator: In response to an IP address correction request containing a new IP address, Modifying the interface record to include the new IP address, Identifying the currently attached resource instance among the multiple resource instances to which the interface record is attached, To allow the currently attached resource instance to receive traffic for the new IP address The system according to Appendix 1, which is further operable to do so. Appendix 7. In response to an interface record creation request, generate an interface record containing the IP address and the subnet identifier of the first subnet containing the first IP address, and store the interface record in a persistent repository. When, The first resource instance receives traffic for the first IP address in response to the first attach request to attach the interface record to the first resource instance of the plurality of resource instances. To be able to do and Preventing the first resource instance from receiving traffic destined for the first IP address in response to a detach request to detach the interface record from the first resource instance, and persisting the interface record To keep it in the target repository Including methods. Appendix 8. In response to the second interface record creation request, generate a second interface record containing the second IP address, and Allows the first resource instance to receive traffic destined for the second IP address in response to a second attach request to attach the second interface record to the first resource instance. To do The method according to Appendix 7, further comprising. Addendum 9. The method of Addendum 8, wherein the second IP address is part of the second subnet and the second interface record contains the subnet identifier of the second subnet. Appendix 10. In the first resource instance, receiving a network packet from the source IP address, the source IP address is reachable from the first resource instance via the first subnet. And that the network packet receives a network packet from the source IP address that has a destination IP address that can be reached from the first resource instance via the second subnet. To route network packets through a second subnet to a destination IP address The method according to Appendix 9, further comprising. Appendix 11. In response to an IP address correction request containing a new IP address, Modifying the interface record to include the new IP address, Identifying the currently attached resource instance among the multiple resource instances to which the interface record is attached, To allow the currently attached resource instance to receive traffic for the new IP address The method according to Appendix 9, further comprising. Appendix 12. The first subnet is part of the first logical partition of the network with the first Common Internet Domain Routing (CIDR) address prefix, and the second subnet is the second CIDR address prefix. 9. The method of Appendix 9, which is part of the second logical partition of a network with. Addendum 13. The method of Addendum 7, wherein the interface record contains a set of security characteristics that include a first authorization entry that identifies one or more entities authorized to submit an attach request. Appendix 14. The method of Appendix 13, wherein the set of security characteristics includes a second authorization entry that identifies one or more entities authorized to modify the first authorization entry. Appendix 15. In response to an interface record creation request, generate an interface record containing the IP address and the subnet identifier of the first subnet containing the first IP address, and store the interface record in a persistent repository. That and Responding to the first attach request to attach an interface record to the first resource instance of multiple resource instances, the first resource instance is in the running state following its bootup, and the first Allowing traffic for your IP address to be received by the first resource instance To implement A persistent computer-accessible storage medium that stores computer-executable program instructions. Appendix 16. The program instruction is To generate a second interface record containing a second IP address in response to a request to create a second interface record, Allows the first resource instance to receive traffic destined for the second IP address in response to a second attach request to attach the second interface record to the first resource instance. To do Computer executable to implement, Sustainable computer-accessible storage medium according to Appendix 15. Appendix 17. Persistent computer-accessible storage according to Appendix 16, wherein the second IP address is part of the second subnet and the second interface record contains the subnet identifier of the second subnet. Medium. Appendix 18. The program instruction is The first resource instance receives a network packet from the source IP address, the source IP address is accessible from the first resource instance via the first subnet, and the network packet. To receive a network packet from a source IP address that has a destination IP address accessible from the first resource instance over the second subnet, To route network packets through a second subnet to a destination IP address Computer executable to implement, Sustainable computer-accessible storage medium according to Appendix 17. Appendix 19. Persistent computer access as described in Appendix 15, where the interface record contains a set of security characteristics that include an authorization entry that identifies one or more entities authorized to modify the IP address. Storage medium. Appendix 20. Interface record: A set of security characteristics that contains an authorization entry that identifies at least one of a port constraint on ingress traffic, a protocol constraint on ingress traffic, a protocol constraint on outbound traffic, or a protocol constraint on outbound traffic. Sustainable computer-accessible storage medium according to Appendix 15, including. Appendix 21. The program instruction is In response to an IP address correction request containing a new IP address, Modifying the interface record to include the new IP address, Identifying the currently attached resource instance among the multiple resource instances to which the interface record is attached, To allow the currently attached resource instance to receive traffic for the new IP address Computer executable to implement, Sustainable computer-accessible storage medium according to Appendix 15. Appendix 22. In Appendix 17, the first subnet is the data subnet designated for the transmission of client application data, and the second subnet is the management subnet designated for the transmission of network management data. The described persistent computer-accessible storage medium. Appendix 23. The first IP address is part of the first network logical partition held on behalf of the first customer, and the second IP address is held on behalf of the second customer. The persistent computer-accessible storage medium according to Appendix 16, which is part of the network logical partition of 2.
0056Illustrative computer system In at least some embodiments, a server that implements some or all of one or more of the techniques described herein, including techniques for providing various services and operations associated with interface record 170. , Computer system 2000, shown in FIG. 11, and may include general purpose computer systems that include or are configured to access one or more computer accessible media. In the illustrated embodiment, computer system 2000 includes one or more processors 2010 coupled to system memory 2020 via input / output (I / O) interface 2030. Computer system 2000 further includes network interface 2040 coupled to input / output interface 2030.
0057In various embodiments, the computer system 2000 is a single processor system that includes one processor 2010, or a multiprocessor system that includes several processors 2010 (eg, 2, 4, 8, or another suitable number). possible. Processor 2010 can be any suitable processor capable of executing instructions. For example, in various embodiments, the processor 2010 is general purpose or built-in that implements any of various instruction set architectures (ISA), such as x86, PowerPC, SPARC, or MIPS ISA, or any other suitable ISA. It can be a processor. In a multiprocessor system, each of the processors 2010 may generally, but not necessarily, implement the same ISA.
0058System memory 2020 may be configured to store instructions and data accessible by the processor (s) 2010. In various embodiments, the system memory 2020 is any suitable memory, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. Can be implemented using technology. In the illustrated embodiment, program instructions and data that implement one or more desired functions, such as methods, techniques, and data as described above, are stored in system memory 2020 as code 2025 and data 2026. Is shown.
0059In one embodiment, I / O interface 2030 is configured to coordinate I / O traffic between processor 2010, system memory 2020, and any peripheral in the device, including network interface 2040 or other peripheral interfaces. obtain. In some embodiments, the input / output interface 2030 transforms a data signal from one component (eg, system memory 2020) into a format suitable for use by another component (eg, processor 2010). It can perform any required protocol, timing or data conversion. In some embodiments, the input / output interface 2030 is, for example, a Peripheral Component. It may include support for devices attached through various types of peripheral bus, such as variants of the Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. In some embodiments, the functionality of the I / O interface 2030 can be divided into two or more separate components, such as the north bridge and south bridge. Also, in some embodiments, some or all of the functionality of the I / O interface 2030, such as the interface to system memory 2020, may be incorporated directly into the processor 2010.
0060The network interface 2040 provides data between the computer system 2000 and another device 2060 (eg, another computer system or device as shown in FIGS. 1-10) to which the data is attached to the network or multiple networks 2050. , Can be configured to allow it to be replaced. In various embodiments, the network interface 2040 may support communication over any suitable wired or wireless general data network, such as, for example, the type of Ethernet network. In addition, network interface 2040 is a network over a telecommunications / telephone network, such as an analog voice network or a digital fiber communication network, via a storage area network, such as a fiber channel SAN, or any other suitable type of network. Can support communication via and / or protocols.
0061In some embodiments, the system memory 2020 is configured to store program instructions and data as described above for FIGS. 1-10 for implementing methods and device embodiments for virtual network interface records. It can be an embodiment of a computer-accessible medium. However, in other embodiments, program instructions and / or data may be received, transmitted or stored on different types of computer accessible media. Generally speaking, computer-accessible media may include persistent storage or memory media such as magnetic or optical media, such as disks or DVDs / CDs coupled to computer system 2000 via input / output interface 2030. .. Persistent computer-accessible storage media can be included as system memory 2020 or other types of memory in some embodiments of computer system 2000, RAM (eg SDRAM, DDR). Any volatile or non-volatile medium such as SDRAM, RDRAM, SRAM, etc.), ROM, etc. may also be included. In addition, computer-accessible media include electrical, electromagnetic, or other digital signals transmitted over communication media such as network and / or wireless links, such as those that can be implemented via network interface 2040. Can include transmission media or signals. Some or all of a plurality of computer systems, such as those shown in FIG. 11, can be used to implement the functionality described in various embodiments; for example, running on a variety of different devices and servers. Software components can work together to provide functionality.
0062Conclusion Various embodiments may further include receiving, transmitting or storing instructions and / or data as described above for computer accessible media. Generally speaking, a computer-accessible medium is a storage or memory medium such as magnetic or optical, such as a disk or DVD / CD-ROM, a volatile or non-volatile medium (RAM (eg, SDRAM, DDR, RDRAM, etc.). It may include transmission media or signals such as electrical, electromagnetic, or other digital signals transmitted via communication media such as networks and / or wireless links), ROMs, etc.), ROMs, etc.).
0063The various methods shown in the figures and described herein provide exemplary embodiments of the methods. The method may be implemented in software, hardware, or a combination thereof. The order of the methods can be changed, and various elements can be added, sorted, combined, omitted, and so on.
0064Various modifications and changes may be made, as will be apparent to those skilled in the art who have the benefit of this disclosure. It is intended to include all such modifications and changes, and accordingly, the above description be considered in an exemplary sense rather than a restrictive sense.
14 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2005218111A | Cites | Japan |
| US20080008197A1 | Cites | United States of America |
| 松原秀治,Amazon EC2/S3の基本から社内クラウド運用設計まで クラウド活用プログラミング入門,SoftwareDesign 発刊240号,(株)技術評論社,2010年10月18日,第240号,pp.26-33 | Non-patent | – |
44 members in 10 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 61561675 | United States of America | – | |
| 201161561675 | United States of America | P | |
| 13339985 | United States of America | – | |
| 201113339985 | United States of America | A | |
| 2012065429 | United States of America | W |
Members44
| Document | Office | Kind | |
|---|---|---|---|
| CA2856086A1 | Canada | A1 | |
| US2013132545A1 | United States of America | A1 | |
| WO2013074873A1 | World Intellectual Property Organization (WIPO) | A1 | |
| SG2014013601A | Singapore | A | |
| AU2012340331A1 | Australia | A1 | |
| CN103946834A | China | A | |
| EP2780818A1 | European Patent Office (EPO) | A1 | |
| US8868710B2 | United States of America | B2 | |
| US2015039771A1 | United States of America | A1 | |
| JP2015506123A | Japan | A | |
| EP2780818A4 | European Patent Office (EPO) | A4 | |
| RU2014120221A | Russian Federation | A | |
| AU2012340331B2 | Australia | B2 | |
| JP5890532B2This record | Japan | B2 | |
| US9369403B2 | United States of America | B2 | |
| JP2016136740A | Japan | A | |
| RU2595517C2 | Russian Federation | C2 | |
| US2016285782A1 | United States of America | A1 | |
| CN103946834B | China | B | |
| BR112014011892A2 | Brazil | A2 | |
| CN106850324A | China | A | |
| JP6162838B2 | Japan | B2 | |
| CA2856086C | Canada | C | |
| JP2017169238A | Japan | A | |
| RU2646343C1 | Russian Federation | C1 | |
| JP6423047B2 | Japan | B2 | |
| EP2780818B1 | European Patent Office (EPO) | B1 | |
| JP2019041395A | Japan | A | |
| EP3493476A1 | European Patent Office (EPO) | A1 | |
| US10367753B2 | United States of America | B2 | |
| US2020021534A1 | United States of America | A1 | |
| JP6677782B2 | Japan | B2 | |
| JP2020129800A | Japan | A | |
| EP3493476B1 | European Patent Office (EPO) | B1 | |
| US10848431B2 | United States of America | B2 | |
| CN106850324B | China | B | |
| EP3783838A1 | European Patent Office (EPO) | A1 | |
| US2021152487A1 | United States of America | A1 | |
| BR112014011892B1 | Brazil | B1 | |
| US11218420B2 | United States of America | B2 | |
| JP7060636B2 | Japan | B2 | |
| US2022200926A1 | United States of America | A1 | |
| EP3783838B1 | European Patent Office (EPO) | B1 | |
| US12355637B2 | United States of America | B2 |
15 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 |
Numbers
- Publication
- 5890532
- Application
- 2014542477
Titles2
- Japanese
- 仮想ネットワークオブジェクトを管理する方法、および仮想ネットワークオブジェクトを管理する方法を実行するためのプログラム命令を格納するコンピュータアクセス可能な記憶媒体
- English
- A computer-accessible storage medium that stores program instructions for managing virtual network objects and for executing methods for managing virtual network objects.
Classification
- CPC, 14
- H04L41/00
- H04L41/40
- G06F15/16
- H04L63/20
- H04L2101/33
- H04L61/5007
- H04L2101/668
- H04L47/70
- H04L41/5045
- H04L41/5051
- G06F15/173
- H04L41/50
- G06F9/5077
- H04L63/10
- IPC, 3
- H04L12 70
- G06F9 46
- G06F13 00
