Outside live migration
Abstract
Global remappable addresses can be published from multiple points across the Internet or other public networks. The global address can be determined by the provider using a static or dynamic process based on one of several factors when the traffic is received to the network location. It can be mapped to one or more internal addresses to the provider so that it can be determined whether it should be processed at the current network location or at a different network location. If the traffic is destined for a different network location, the traffic can be remapped and forwarded to that network location. Once the traffic is at the determined destination network location, the traffic can be remapped and delivered to the final destination. The remapping and destination network location can be adjusted at any time based on any of several factors without the significant risk of dropping traffic.

Term
5.5 yearsto projected expiry
Projected expiry 9 March 2032, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
16 claims: 3 independent, 13 dependent
- 1ネットワークトラフィックを方向付けるコンピュータ実装方法であって、 実行可能な命令とともに構成される1つ以上のコンピュータシステムの制御下で、 サービスプロバイダネットワークへのネットワークトラフィックを受信することであって、前記ネットワークトラフィックは、前記サービスプロバイダネットワークの少なくとも1つのポイントから公示される、グローバルな再マッピング可能なアドレスへ受信され、各ポイントは、異なるネットワーク場所に存在すること、および前記サービスプロバイダネットワークの標的送信先へマッピングされることが可能である、受信することと、 前記標的送信先の標的ネットワーク場所が、前記ネットワークトラフィックが受信される、受信ネットワーク場所と同じである時、前記ネットワークトラフィックを再マッピングし、前記ネットワークトラフィックを前記標的送信先へ配信することと、 前記送信先ネットワーク場所が、前記受信ネットワーク場所とは異なる時、 前記ネットワークトラフィックを、前記送信先ネットワーク場所に対する前記サービスプロバイダネットワークの中間アドレスへ再マッピングすることと、 前記ネットワークトラフィックを、前記送信先ネットワーク場所における前記中間アドレスへ送信することと、 前記ネットワークトラフィックが前記送信先ネットワーク場所で受信される時、前記ネットワークトラフィックを再マッピングし、前記ネットワークトラフィックを前記標的送信先へ配信することと、を含む、方法。
- 2前記グローバルな再マッピング可能なアドレスは、前記サービスプロバイダネットワークの少なくとも2つのポイントから公示される、請求項1に記載のコンピュータ実装方法。
- 3前記再マッピング可能なグローバルアドレスは、グローバルな再マッピング可能なインターネットプロトコル(IP)アドレスであり、 前記サービスプロバイダは、ドメイン名システム(DNS)またはボーダゲートウェイプロトコル(border gateway protocol:BGP)ルーティングのうちの少なくとも1つを使用して、前記ネットワークトラフィックのグローバルなルーティングを可能にする、請求項1に記載のコンピュータ実装方法。
- 4前記異なるネットワーク場所は、地理的に分散した領域、または異なるプロバイダによって運用されるネットワークのうちの少なくとも1つに対応する、請求項1に記載のコンピュータ実装方法。
- 5標的送信先を判断するための方針は、特定の時刻に、前記ネットワークトラフィックを方向付けるべきネットワーク場所を指定する、請求項1に記載のコンピュータ実装方法。
- 6少なくとも1つの方針は、標的送信先を判断するために利用され、前記少なくとも1つの方針は、前記ネットワークトラフィックの発信場所、前記ネットワークトラフィックに対応する顧客のタイプ、または前記ネットワークトラフィックと関連付けられる財務的考慮の量のうちの少なくとも1つに基づいて、前記標的送信先を判断する、請求項1に記載のコンピュータ実装方法。
- 7前記標的送信先は、前記ネットワークトラフィックが受信されるネットワーク場所に少なくとも部分的に基づいて、前記トラフィックをルーティングすべきネットワーク場所を示す、静的構成情報を使用して、判断される、請求項1に記載のコンピュータ実装方法。
- 8前記標的送信先は、あるネットワーク場所の現在の負荷、およびあるネットワーク場所のネットワーク近接性のうちの少なくとも1つを含む要因に基づいて、動的に判断される、請求項1に記載のコンピュータ実装方法。
- 9前記標的送信先は、種々のネットワーク場所をランク付けするリスト、および前記グローバルに再マッピング可能なアドレスがアクティブである、ネットワーク場所のリストを使用して判断される、請求項1に記載のコンピュータ実装方法。
- 10前記グローバルな再マッピング可能なアドレス、中間アドレス、および送信先アドレス間の前記マッピングのうちの少なくとも一部は、一方向である、請求項1に記載のコンピュータ実装方法。
- 11前記ネットワークトラフィックは、エニーキャスト手法を使用して方向付けられる、請求項1に記載のコンピュータ実装方法。
- 12顧客は、重み付けされたトラフィックの均衡化を指定することができ、前記受信されたトラフィックのおおよその量は、少なくとも1つのネットワーク場所へ方向付けられる、請求項1に記載のコンピュータ実装方法。
- 13アドレスは、新たな仮想機械へグローバルに再マッピング可能であり、既存の取引は、先の仮想機械を使用して処理することが可能である一方、新たな取引は、処理のために、新たな仮想機械へ方向付けられる、請求項1に記載のコンピュータ実装方法。
- 14ネットワークトラフィックを管理するためのシステムであって、 プロセッサと、 前記プロセッサによって実行される時、前記プロセッサに、 サービスプロバイダネットワークへのネットワークトラフィックを受信することであって、前記ネットワークトラフィックは、前記サービスプロバイダネットワークの少なくとも1つのポイントから公示される、グローバルな再マッピング可能なアドレスへ受信され、各ポイントは、異なるネットワーク場所に存在すること、および前記サービスプロバイダネットワークの標的送信先へマッピングされることが可能である、受信することと、 前記標的送信先の標的ネットワーク場所が、前記ネットワークトラフィックが受信される、受信ネットワーク場所と同じである時、前記ネットワークトラフィックを再マッピングし、前記ネットワークトラフィックを前記標的送信先へ配信することと、 前記送信先ネットワーク場所が、前記受信ネットワーク場所とは異なる時、 前記ネットワークトラフィックを、前記送信先ネットワーク場所に対する前記サービスプロバイダネットワークの中間アドレスへ再マッピングすることと、 前記ネットワークトラフィックを、前記送信先ネットワーク場所における前記中間アドレスへ送信し、それにより、前記ネットワークトラフィックが前記送信先ネットワーク場所で受信される時、前記ネットワークトラフィックを、前記標的送信先へ再マッピングおよび配信することができることと、を行わせる、命令を含む、メモリデバイスと、を備える、システム。
- 15前記標的送信先は、方針、ランキングリスト、ネットワーク負荷、または静的構成のうちの少なくとも1つに従って判断される、請求項14に記載のシステム。
- 16前記ネットワークトラフィックは、公的または私的ネットワークを使用して、前記中間アドレスへ送信されることが可能である、請求項14に記載のシステム。
Independent claims16
100 paragraphs, as filed
[Background technology]
As more and more applications and services become available on networks such as the Internet, more and more content, applications, and / or service providers are transforming into technologies such as multi-tenant resources and cloud computing. These technologies can be dynamically scaled so that the hardware and / or software used to provide these resources can meet the needs of multiple customers at any given time. Allows customers to access and / or utilize various types of electronic resources, whether physical or virtual. Customers typically rent, lease, or otherwise pay to access these resources, and therefore hardware and / or software to obtain the functionality provided by these resources. No need to buy and maintain.
Using traditional techniques, the customer can launch an instance wherever the appropriate resource is located that the customer has access to. However, if a static address is associated with that instance, traffic destined for that static address can be dropped in the event of a network failure or other such occurrence. In some techniques, the customer can remap an existing name (eg, a DNS name) to the public address of a new instance, but such a technique allows the address to propagate through the Internet. In addition, it can take several hours, so new instances may not receive traffic while terminated or unavailable instances continue to receive requests. Moreover, even when remapping addresses, customers may be confined to a particular area, which can be a problem in the event of a regional network outage or other such event.
Various embodiments according to the present disclosure will be described with reference to the drawings.<figref num="1">An environment in which various embodiments can be implemented will be illustrated.</figref><figref num="2">Illustrative separation of control planes and data planes that can be used according to various embodiments is illustrated.</figref><figref num="3">Illustrate an exemplary distribution of customer network locations that can be used according to various embodiments.</figref><figref num="4">Illustrate an exemplary ranking list for a customer network location that can be used according to various embodiments.</figref><figref num="5(a)">Illustrate the depiction of point mapping in conventional methods and according to various embodiments.</figref><figref num="5(b)">Illustrate the depiction of point mapping in conventional methods and according to various embodiments.</figref><figref num="6">Illustrate an exemplary process for directing traffic that can be used according to various embodiments.</figref>
Systems and methods according to the various embodiments of the present disclosure can overcome one or more of the aforementioned and other deficiencies experienced in conventional approaches to managing traffic in electronic environments. In particular, methods that follow various embodiments provide the use of re-mapping addresses that are globally repositionable. These remapable global addresses allow customers to publish addresses from multiple points and / or network locations (eg, geographically separated areas, or different network stacks operated by different providers). While allowing traffic received at those network locations to be directed to the appropriate instance or other destination at any given time. Such an approach enables dynamic traffic management without the significant risk of dropping traffic.
In at least some embodiments, a request received to a location where a global address is published is as quick as possible without requiring the use of the provider's own network to direct traffic. It can be indirectly remapped and sent back on the Internet. In one embodiment, a customer who initiates a message in the first area, heading for a location in the second area, causes the message to be sent to the Internet in the first area and then to the second area on the Internet. The Internet component is responsible for determining how to bring the request to an address in the second area. Such an approach prevents the provider from transporting its traffic to a second area across the provider's own network, but in at least some embodiments, the provider uses a private network under certain circumstances. You can decide what to do. Such an approach allows for inter-regional instance migration for any suitable purpose at any suitable time. If the message is first received in the destination area, the message can be remapped directly to the appropriate instance and delivered to that instance for processing.
In some such embodiments, a particular remapable global address is only part of the address space, but points of various points of It can be used as published at present: POP) or other interface points. Some of them can be published in some or all POPs, and in some cases different sections of the address space can be published from different POP groups. In some embodiments, the size of the address block can be chosen to be large enough so that the provider can selectively choose the area in which at least a portion of the space should be advertised. With the understanding that large amounts of traffic may need to be carried over the provider network, some embodiments use blocks of pre-assigned addresses that can be advertised in some or all areas. can do. Large customers can potentially leverage some remapping addresses from globally advertised blocks to help determine how to direct traffic on a smaller scale. In some embodiments, the address is published from more network locations than can handle the received traffic. In at least some embodiments, a network location is not authorized to handle certain types of traffic, such as traffic to a customer. In some cases, a network area may advertise some other area that cannot direct a particular type of traffic.
In some cases, the provider monitors status information and automatically addresses when necessary so that customers do not need to detect outages and / or address any related issues. Can be remapped to. In at least some embodiments, the customer can identify one or more policies for identifying how addresses should be remapped and the circumstances or criteria for remapping those addresses. In some cases, the customer may specify a policy such that certain mappings occur at a given time in an automated fashion that the customer pre-determines. In other cases, the customer can identify that a remapping should occur in response to the occurrence of a type of event (eg, a domain failure). Other policies may also be used so that they can be provided or identified by any suitable entity. For example, a provider may use one or more policies to route customer traffic, where routing is associated with the location or address of the traffic, the type of customer corresponding to the traffic, or the traffic. Judgment is based, at least in part, on the amount of financial consideration given.
In at least some embodiments, the customer may have the ability to identify and / or update static configuration information, eg, to adjust the ranking of destination areas. For example, a customer may want to identify directing traffic to a location within the area associated with Minnesota. Customers can submit API calls to identify updated configuration information, which can then be propagated as needed to update the required configuration list (s). it can. In at least some embodiments, the customer can identify different configuration information or policies for different areas and / or different times. In at least some embodiments, the judgment is the status of at least one area, such as whether the location is alive and available, and the distance from the current area to that area, and the current. It can be done with respect to other information, such as the load between the area and the potential target area.
Various policies may also be implemented by the provider. For example, a provider may implement a policy that may route traffic to different areas throughout the day. Such a policy can also implement global autoscale, allowing different regions to receive, process, and / or send different amounts of traffic based on time or other such factors.
In one embodiment, a Domain Name System (DNS) based approach can be used and the DNS entry for the host is modified or updated to be within the published range in the new area, the corresponding Internet Protocol. Has an (IP) address. Different IP address ranges can be published in different regions, and when it is desired to direct traffic to a new (or different) region, the appropriate host will include values within that new region. You can have a DNS entry that is updated as such. In other embodiments, data can be controlled for a protocol, for example by managing border gateway patrol (BGP) information.
Various embodiments provide separate control environments or control planes that can be used to allow the user to identify and manage different aspects of the data environment or data plane. This "self-service" functionality can be provided via a set of web services, allowing the user and control plane to act together as a virtual database administrator (DBA). A user or customer can submit a request to the control plane, for example, through one of several externally visible application programming interfaces (APIs). Various APIs can be used to perform specific functions with respect to various resources in the data environment. Requests received by one of the APIs are used to determine the desired action (including multiple) to be performed in the data plane, such as the action to launch a customer instance, as well as to launch the instance. Can be analyzed to determine any configuration parameters used in. Components such as resource management components can determine the appropriate task for an action, ensure that the appropriate launch configuration is selected, and execute the tasks in the appropriate order. At least one of these tasks is typically performed in a data environment, for example, to launch or adjust a resource instance of an aspect.
Various other functions and advantages are described and proposed below so that they can be provided according to different embodiments.
FIG. 1 illustrates an example of the environment 100 for implementing aspects according to various embodiments. As will be appreciated, a web-based environment will be used for explanatory purposes, but different environments may be used appropriately to implement the various embodiments. Environment 100 can include any suitable device capable of transmitting and receiving requests, messages, or information over the appropriate network 104 and communicating the information to the user of the device, an electronic client device. Includes 102. Examples of such client devices include personal computers, mobile phones, handheld messaging devices, laptop computers, set-top boxes, personal data aids, e-book readers and the like. The network can include any suitable network, including an intranet, the Internet, a cellular network, a local area network, or any other such network, or a combination thereof. The components used for such a system may at least partially depend on the type of network and / or environment selected. Protocols and components for communicating over such networks are known and are not described in detail herein. Communication over the network can be made possible by wire or wireless connections, and combinations thereof. In this embodiment, the network includes the Internet because the environment includes a web server 106 for receiving requests and serving content in response, but as will be apparent to those skilled in the art, others. For networks of, alternative devices can be used that serve similar purposes.
An exemplary environment includes at least one application server 108 and a datastore 110. Some application server, tier, or other element, process, or component that can be configured in a chain or other way that can interact to perform tasks such as getting data from the appropriate data store. It should be understood that can exist. As used herein, the term "datastore" may include any combination and number of data servers, databases, data storage devices, and data storage media in any standard, distributed, or clustered environment. Refers to any device or device combination capable of storing, accessing, and retrieving data. The application server can optionally include any suitable hardware and software to integrate with the data store to perform one or more application aspects to the client device, and the majority for the application. Address data access and business logic. The application server can work with the data store to provide access control services and generate content such as text, graphics, audio, and / or video that should be transferred to the user, which is the embodiment. In HTML, XML, or in the form of another suitable structured language, it may be served to the user by a web server. All requests and responses between the client device 102 and the application server 108, as well as content delivery, can be handled by the web server. Web and application servers are not required, but exemplary, as the structured code described herein can run on any suitable device or host machine described anywhere in the specification. It should be understood that it is only a component.
The data store 110 can include several separate data tables, databases, or other data storage mechanisms and media for storing data relating to a particular embodiment. For example, the illustrated data store includes a mechanism for storing production data 112 and user information 116 that can be used to serve content. The data store is also indicated to include a mechanism for storing log data 114 that can be used for purposes such as reporting and analysis. Appropriately in any of the mechanisms listed above, or in an additional mechanism of the datastore 110, can be stored in the datastore, eg, for page image information and access right information. It should be understood that there may be many other aspects that may be needed. The datastore 110 can operate through the logic associated with it to receive instructions from application server 108 and to retrieve, update, or otherwise process data in response. In one embodiment, the user may submit a search request for a type of item. In this case, the data store may access the user information to match the user's identity and can access the catalog details to get information about that type of item. The information can then be returned to the user, for example, in a result list on a web page that the user can view via a browser on the user device 102. Information about a particular item of interest can be viewed on a dedicated page or window in the browser.
Each server typically includes an operating system that provides executable program instructions for general management and operation of the server, and typically when executed by the server's processor, the server is intended. Includes a computer-readable medium that stores instructions that allow it to perform its functions. Suitable implementations for the server operating system and general functionality are known or commercially available and are readily implemented by those skilled in the art, especially in light of the present disclosure herein. ..
The environment in one embodiment is a distributed computing environment that utilizes several computer systems and components that are interconnected via communication links using one or more computer networks, or direct connections. is there. However, it will be appreciated by those skilled in the art that such systems can operate equally well in systems with fewer or more components than those illustrated in FIG. For this reason, the drawing of System 100 in FIG. 1 is, in fact, exemplary and should be taken as not limiting the scope of the present disclosure.
An environment, such as the one illustrated in Figure 1, allows multiple hosts to serve content, authenticate users, perform payment transactions, or perform any of several other such tasks. It may be useful for providers such as the electronic market, which may be used to perform tasks such as performing. Some of these hosts may be configured to provide the same functionality, while other servers may be configured to perform at least some different functionality. The electronic environment in such cases may include additional components and / or other arrangements, such as those illustrated in configuration 200 of FIG. 2, detailed below.
Techniques that follow various embodiments allow developers, customers, or other authorized users to perform relational tasks such as storing, processing, and querying relational datasets in the cloud. It can be used with systems that can provide relational database services (RDS) that allow you to retrieve and configure databases and other such data sources. Although this embodiment is described with respect to the Internet, web services, and Internet-based technologies, aspects of various embodiments are any suitable service available or provided on the network in an electronic environment. It should be understood that it can be used with. Further, the service is referred to herein as a "relational database service", which may be used with any suitable type of data repository or data storage device in an electronic environment. Should be understood. The RDS in this example allows the user or customer to worry about the administrative complexity of such aspects of deployment, update, patch management, backup, replication, failover, capacity management, scaling, and data management. Includes at least one web service that allows you to easily manage resources and relational datasets. This gives developers the freedom to develop sophisticated cloud applications without worrying about the complexity of managing their database infrastructure.
The RDS in one embodiment provides a separate "control plane" that includes components (eg, hardware and software) that are useful for managing aspects of the data storage device. In one embodiment, a set of data management application programming interfaces (APIs) or other that allows a user or customer to make calls to the RDS to perform certain tasks related to data storage. Such an interface is provided. However, users can still use direct interfaces or APIs to communicate with data repositories, and only when necessary to manage data storage or perform similar tasks. You can use RDS-specific APIs.
FIG. 2 illustrates an example of RDS implementation 200 that can be used according to one embodiment. In this embodiment, the computing device 202 for the end user is shown to be able to make calls to the control plane 208 over the network 206 to perform tasks such as provisioning a data repository for the data plane 210. The user or application 204 can access the provisioned repository directly through the interface of the data plane 210. End-user computing devices and applications are used for explanatory purposes, but any suitable user, application, service, device, component, or resource, as appropriate in various embodiments, controls plane and / or. It should be understood that the data plane's interfaces (including multiple) can be accessed. In addition, the components are separated into control and data "planes", which are of at least some resources (eg, hardware and / or software) used to provide their respective functionality. It should be understood that it can refer to real or virtual separation.
The control plane 208 in this embodiment is essentially a virtual layer of hardware and software components that addresses control and management actions such as provisioning, scaling, replication, and so on. The control plane in this embodiment includes a web service layer 212 or tier, which may include, for example, at least one web server, along with computer-executable software, application servers, or other such components. The web service layer can also include a set of API 232 (or other such interface) for receiving web service calls or requests from within network 206. Each API may be provided to receive a request for at least one particular action to be taken with respect to the data environment, for example to provision, scale, clone, or hibernate an instance of a relational database. it can. Upon receiving a request to one of the APIs, the web service layer must parse or otherwise analyze the request to determine the steps or actions required to act on or process the call. Can be analyzed. For example, a web service call may be received that contains a request to create a data repository. In this embodiment, the web service layer makes a request to determine the type of data repository to be created, the required storage volume, the required type of hardware (if any), or other such aspects. Can be analyzed. Information about the request can be written to the administrative (Admin) datastore 222, or any other suitable storage location or job queue for further processing.
The web service layer in one embodiment includes a scaleable set of customer-facing servers that can provide various control plane APIs and can return appropriate responses based on the API specifications. The web service layer may also include, in one embodiment , at least one API service layer consisting of stateless replication servers that handle externally-enabled customer APIs . The web services layer authenticates customers based on credentials, authorizes customers, suppresses customer requests to API servers, enables user input, and marshalls or unmarshalls requests and responses. It can be responsible for the front-end characteristics of web services, such as doing. The API layer can also be responsible for reading and writing database configuration data from / to the management data store in response to API calls. In many embodiments, the web service layer and / or the API service layer is the only externally visible component or is visible to the control service customer and is accessible only to the control service customer. It is the only component. Web service tier servers are stateless and can be scaled horizontally, as is known in the art. API servers, as well as persistent data stores, are scattered across multiple data centers in a geographic area or in the vicinity of a geographic location, for example, so that the servers are resilient to a single data center failure. can do.
The control plane in this embodiment includes what is referred to herein as the "sweeper" component 214. The sweeper component can operate to poll the various components of the control plane, or to determine any task to be performed in response to otherwise unprocessed requests. It can be an appropriate component. In this embodiment, the web service layer may place instructions or information for the "create database" request in the admin datastore 222, or similar job queue, and the sweeper admin for outstanding jobs. You can check the data store periodically. Various other techniques can be used by the web service layer, such as sending a notification to the sweeper that a job exists, as will be apparent to those skilled in the art. The sweeper component can behave to pick up a "create database" request and use the information for the request to instantiate a request, call, or other such command into at least one workflow for the request. It can be sent to workflow component 216. The workflow in one embodiment is generated and maintained using workflow services, as described elsewhere herein. A workflow is generally a set of tasks that should be performed to perform a particular job. Workflow is a work abstraction that controls the flow of information and the execution of work, although it is not the actual work. A workflow can also be thought of as a state machine that can manage and return the state of a process at any time during execution. Workflow components (or systems of components) in one embodiment are repository creation, modification, and deletion; recovery and backup; security group creation, deletion, and modification; user authentication information management; It can also act to manage and / or perform workflow hosting and execution for tasks such as key rotation and credential management. Such workflows can be implemented in addition to workflow services, as described elsewhere herein. Workflow components can also manage differences between workflow steps used for different database engines, such as MySQL, because the underlying workflow service does not necessarily change.
In this embodiment, the workflow can be instantiated using a workflow template for creating a database and applying the information extracted from the original request. For example, if the request is for a MySQL® relational database management system (RDBMS) instance, as opposed to Oracle® RDBMS or other such instances, then a particular task is directed to the MySQL instance. Added to the workflow. Workflow components can also select specific tasks for the amount of storage required, any specific hardware requirements, or other such tasks. These tasks can be added to the workflow in order of execution that is useful for the entire job. Some tasks can be performed in parallel, while others depend on the task to be completed first. A workflow component or service can include this information in a workflow, perform tasks, and pass information as needed.
An exemplary "create database" workflow for a customer utilizes a set of launch configuration parameters to ensure that the appropriate set of launch configuration parameters is identified for the request. Provisioning a datastore instance, allocating an off-instance persistent storage volume, attaching a persistent storage volume to a datastore instance, and then a DNS address, or for a customer to access the data instance, or otherwise. It may include tasks such as assigning and attaching other addresses, ports, interfaces, or identifiers that can be used to connect to it. In this embodiment, the user is provided with a DNS address and a port address used to access the instance. Workflow components can manage the execution of these and any related tasks, or any other appropriate combination of such tasks, and actually correspond to the datastore instances in the data plane 210, "Database". In response to a "create" request, a response to a request indicating the creation of a "database" can be generated and the DNS address used to access the instance can be provided. The user can then access the datastore instance directly using the DNS address and port without having to access or pass through the control plane 208. Various other workflow templates can be used to perform similar jobs, such as deleting, creating, or modifying one of more datastore instances, such as to increase storage. .. In some embodiments, workflow information is written to storage and at least one separate execution component (not shown) elicits or otherwise elicits a task to be performed based on the workflow information. If you access it, Receives it. For example, there may be a dedicated provisioning component that performs a provisioning task, and this component may not be called by the workflow component, but the task queue can be monitored or is obvious. You can receive information for a provisioning task in any of several related ways, such as it should be.
The control plane 208 in this embodiment also includes at least one monitoring component 218. When a data instance is created in the data plane, information for the instance can be written to a data store in the control plane, such as the monitoring data store 220. The monitoring datastore can be a separate datastore, or part of another datastore, such as a distinctly different set of tables in the Admin datastore 222, or any other suitable repository. Should be understood. The monitoring component can access the information in the monitoring data store to determine the active instance 234 in the data plane 210. As mentioned elsewhere herein, these instances can reside in different regions that can be distributed to any selected suitable location around the world. Monitoring components also collect log and / or event information from multiple components of the control plane and / or data plane, such as web service layers, workflow components, sweeper components, and various host managers. Other tasks can be performed. Using such event information, the monitoring component can project a customer-visible event for purposes such as implementing a customer-facing API. The monitoring component constantly monitors the health of all running repositories and / or instances for the control plane, detects failures in any of these instances, and has an appropriate recovery process (including multiple). ) Can be started.
Each instance 234 in the data plane can contain at least one datastore 226 and a host manager component 228 for the machine that provides access to the datastore. The host manager in one embodiment is programmed to manage tasks such as software development and datastore operations, runs on an instance and / or application server such as a Tomcat or Java® application server, and the datastore and / Or an application or software agent that monitors the status of each instance. The host manager in one embodiment listens on a port that can only be reached from internal system components and is not available to customers or other external entities. In some embodiments, the host manager cannot initiate any call to the control plane layer. The host manager manages and / / manages tasks such as setting up instances for new repositories, installing database binaries and seeds, and starting or stopping repositories, including setting up logical volumes and file systems. Or can be responsible for carrying out. The host manager can monitor the health of the datastore as well as monitor the datastore for error conditions such as I / O or data storage errors and restart the datastore if necessary. .. The host manager also performs and / or manages the installation of software patches and upgrades for datastores and / or operating systems. The host manager can also collect relevant metrics such as those that may be related to CPU, memory, and I / O usage.
The monitoring component determines the status of each host, for example, by sending a specific request or by monitoring the heartbeat from the host manager, for each host manager for the monitored instance 234. It can communicate with 228 periodically. In one embodiment, the monitoring component is, for example, a set of event processors (or monitoring servers) configured to issue commands to each host manager to obtain the status of a particular host and / or instance. Including. If no response is received after the specified number of retries, the monitoring component can determine that there is a problem, for example, matching the problem and reprovisioning the instance if necessary. Information can be stored in the Admin datastore 222 or another such job queue to perform the action. The sweeper can access this information and initiate a recovery workflow for the instance to attempt to recover automatically from the failure. Host Manager 228 can act as a proxy for control plane monitoring and other components, performing tasks for instances on behalf of control plane components. Sometimes the problem arises with one of the instances, such as a crash, restart, restart, etc. of the corresponding host, instance, or volume, which cannot be resolved automatically. In one embodiment, there are logging components (not shown) capable of logging these and other customer visibility events. The logging component is an API or other API or other that allows a customer to call the appropriate "event" or similar API to obtain information about the event if the instance is unavailable for a period of time. Such an interface can be included. In some cases, the request can be put on hold when the instance fails. The control plane in this embodiment , Because separated from the data plane, the control plane never receives the data request and therefore cannot queue the request for subsequent submissions (although in some embodiments). , This information can be transferred to the control plane). Therefore, since the control plane in the present embodiment provides information to the user regarding the failure, the user can deal with the request as needed.
As mentioned, once an instance is provisioned and the user is provided with a DNS address or other address or location, the user can interact directly with that instance 234 in the Java Database. Requests can be sent "directly" to the data plane 210 over the network using Connectivity (JDBC) or other such clients. In one embodiment, the data plane is a set of web services and resources that provide data storage and access across a computing cloud environment or a "cloud" or dynamic network of hardware and / or software components. (Or at least include or be part of it). For example, an instance or availability failure can be masked by programmatically remapping the DNS address to any suitable replacement instance for use, so the DNS address is such a dynamic cloud environment. It is beneficial in. For example, a request received from user 202 or application 204 can direct the request to the actual instance 234 or the host corresponding to the request's DNS, network address translation (NAT) router 224, or other suitable component. Can be turned to. As stated, such a technique dynamically moves, updates, and replicates an instance without requiring the user or application to change the DNS or other address used to access the instance. Make things possible. As mentioned, each instance 234 can include a host manager 228 and a datastore 226 and can have at least one backup instance or copy within persistent storage 230. Using this technique, once an instance is configured through the control plane, a user, application, service, or component does not need to access the control plane 232, but through a request to the data plane. You can interact directly with the instance. For example, a user can use a DNS address in an instance. You can issue structured query language (SQL) or other such commands for your data directly. If the user wants to perform a task such as increasing the storage capacity of the instance, the user will only need access to the control plane. In at least one embodiment, the functionality of control plane 208 may or may not be associated with the provider of data plane 210 and may be provided as at least one service by the provider, but merely. A third party that can be used to provision and manage data instances in a data plane, and can also monitor and ensure the availability of those instances in a separate data plane 210. It may be a service.
As stated, one advantage of providing control plane functionality as a web service or other such service is that the control plane can act as a virtual system administrator or virtual database administrator (DBA). For example, avoiding the need for experienced human administrators to perform tasks such as launch configuration matching and data provisioning. Many traditional techniques require such a human administrator to receive the required configuration information, determine if the configuration is valid, optimize and tune the instance, and perform other such tasks. , This requires a considerable amount of time and effort. Moreover, such techniques provide many opportunities for errors. However, the user's ability to specify these parameters causes the user to launch an instance or otherwise access resources in a way that is not optimal for the current network or system environment. obtain. As described herein, by specifying a particular launch configuration when submitting a request to a control plane or service, the user or customer may be optimally (or at least appropriate, or at least appropriate) for resource access. You can get (accepted) performance. The control plane can perform the necessary tasks to create, launch, delete, modify, scale, and / or otherwise manage resources or resource instances in response to requests. The control plane can also consistently support several different types of resources without the need for specialists for each type of resource.
In a conventional embodiment, the customer may launch an instance (such as that described with reference to FIG. 2) somewhere in the world where at least the appropriate resources are located and the customer has access to those resources. You may be able to do it. However, if an address, such as a static address, is associated with a particular instance according to many traditional techniques, traffic directed to that static address may be lost in the event of a failure or other such occurrence. .. In some techniques, an instance may be assigned two addresses: a private address at startup and a public address that maps to a private address through Network Address Translation (NAT). For example, with respect to IP addresses, such techniques allow customers to use dynamic DNS to remap existing DNS names to the public IP addresses of new instances. However, such a technique can take up to 24 hours for an IP address to propagate through the Internet, so that new instances do not receive traffic while terminated instances continue to receive requests. There is.
In some circumstances, the customer may instead associate what is referred to herein as a "remaptable" address. An example of a remapable address is the "Elastic IP Address" provided by Amazon.com, Inc. in Seattle, Washington. The customer can associate the remapping address with the customer's account, for example, instead of a particular instance. However, unlike traditional static IP addresses, remapping addresses allow customers to remap publicly exposed IP addresses to any instance in their account.
However, even when utilizing remapable addresses, customers are typically limited to a single area. For example, a customer with a mechanical failure in Virginia may be able to launch a new instance and remap a remapping address to that new instance in Virginia or the surrounding area. Traffic coming from the network (eg, the Internet) destined for that remapable address will be routed towards that instance. Customers can reroute traffic to other data centers (including multiple) in that area if one data center experiences power loss, for example, in several different data centers in Virginia. In some cases, multiple locations within the area may be used.
However, using traditional techniques, customers cannot remap their remapable addresses across multiple regions or to different regions. For example, a customer may not be able to remap to a data center outside the United States in the event of a catastrophe or other outbreak that renders the network in the United States inoperable. In addition, traffic originates primarily from different parts of the world at different times, and customers can map to the data center closest to the latest traffic source point on the network at any given time. Addresses cannot be remapped to reduce the amount of traffic. The customer must assign a new remappable address and use DNS or another similar mechanism to notify the customer of the new endpoint (s), which is a number of different situations. May be undesirable in.
An option available to customers using traditional techniques is to "publicize" all of the public addresses in each of the desired areas. In Example 300, illustrated in FIG. 3, the provider may utilize resources within at least four different areas, each of which is an associated area, here the West Coast of the United States (Area A). , US East Coast (Region B), Ireland (Region C), and Asia (Region D). In this embodiment, the public address space within Virginia can be published by Virginia, and the public address space within Ireland can be published by Ireland. Here, "publication" generally means that a node in a network, such as the Internet, is located at an address (eg, an IP address) so that traffic directed to those addresses can be properly routed to that location. Be aware, it means that notifications will be provided. Customers typically prefer to use the shortest possible path for traffic, and they also utilize other people's networks (eg, on Level 3 with other providers, etc.). To favor, such techniques are such that traffic initiated in a given area (eg, Europe) is directed across a non-customer-owned network (eg, the Internet), and in Europe (eg, in this example). (Ireland) allows you to be directed to a publicly announced location. Similarly, traffic sent from within the United States can be directed to a publicly announced location in Virginia on the Internet, where it can first hit the customer's network. However, the potential drawback to such an approach is that if the Irish address space becomes unavailable, traffic originating in Europe can be dropped because that area is unaware of the address space in other areas. It means that there is sex.
In some cases, addresses can generally be remapped using traditional techniques. In such cases, the public address space can be published anywhere so that traffic can be received at any of those locations and then directed appropriately. Such an approach typically involves an entity that publishes its address space so that traffic received in Ireland, which may have been received more beneficially in Asia, can be sent to Asia, etc. It can be undesirable for many reasons, including the fact that a huge amount of traffic will have to be backhauled between them. For example, a company operating a website on the west coast may need to receive traffic at a data center in Virginia and then be transported across the company's network to a server on the west coast, east coast. May have many customers in, which means that the host or provider of the data center will have to carry the data across their own network at their own expense. Such techniques may also provide scaling issues, as the address space must be scaled globally to accommodate traffic everywhere, even if the areas can be of significantly different sizes. Other such problems may also result from such techniques.
Systems and methods that follow various embodiments can allow customers to take advantage of remapping addresses that are globally reassignable and / or indirectly remapping. In at least some embodiments, through one or more application programming interfaces (APIs), customers using web services can utilize and manage globally reassignable remapable IP addresses. Such an approach allows the network to take advantage of "hot potato" techniques for routing traffic, thereby allowing the traffic to be directed without the need to utilize the provider's own network. Requests received to one of the published locations can be indirectly remapped and sent back over the Internet as quickly as possible. In one embodiment, a customer who initiates a message in Virginia, directed to a location in Ireland, can send the message to the Internet in Virginia and, on the Internet, to Ireland, an Internet component. Is responsible for deciding how to bring the request to an address in Ireland. Such an approach prevents the data center provider from directing its traffic across the provider's own network to Ireland and then hitting only the Internet within Ireland. Providers typically pay for Internet bandwidth anyway, so they use that bandwidth instead of transporting data across the Atlantic over dedicated fibers or other such private connections. May be preferable.
Such a technique is an inter-regional instance for any suitable purpose, such as to position the instance closer to the majority of users at any particular time (eg, "tracking the sun" around the world). Allows migration. Using traditional internet-based techniques, such migrations can be difficult or even impossible to achieve when the instance is communicating with an internet host. Customers generally want such a transition to be carried out relatively seamlessly, which presents a problem in properly routing traffic throughout the Internet. In one embodiment, a Domain Name System (DNS) based approach can be used, which is the corresponding IP address in which the DNS entry for the host is modified or updated to the extent published in the new area. Can have. In such a technique, when different IP address ranges are published in different domains and it is desired to direct traffic to a new (or different) domain, the appropriate host will set values within that new domain. It can have DNS entries that are updated to include.
Another approach is based on controlling data for a protocol, such as border gateway patrol (BGP) information. BGP maintains a table of IP prefixes that are typically used in Internet routing decisions. In certain embodiments, the BGP announcement can be modified to start advertising in a particular address space in a new area and stop advertising in that space in a previous area. Using such a technique, the customer can keep the same IP address while the traffic goes directly to the new area. In some embodiments, some mechanism can be provided to forward and / or tunnel traffic between regions for a period of time while information for a DNS or BGP-based approach changes.
In some embodiments, only a portion of the address space can use a particular remapable global address, as published at various POPs or other interface points. That part can be published in some or all POPs, and in some cases different sections of the address space can be published from different POP groups. Using traditional Internet techniques, a single IP address cannot simply be published globally. However, some entities may request a block of remapable addresses and want those addresses to be accessible in more than one area, such as the eastern United States and the western United States. In such cases, all (or the majority) of the customers may be in the United States, but the entity may want the ability to failover and shift traffic to other locations if there is a problem. In some cases, an entity may simply want to direct traffic according to the location of the majority of customers at any given time. For example, if a company has customers all over the world and those customers tend to hit the network during business hours in the customer region of the world, the company needs it at any given time. You may want to adjust their addresses to different regions throughout the day in an attempt to minimize the majority of the data paths that are made. In one embodiment, the customer can be given a "/ 24" that can be published to global BGP. The "/24" is typically summarized in the routing table as a dotted decimal address, followed by a forward slash ("/") and a two-digit decimal number that gives the number of first bits in the subnet mask. Refers to a block of Internet addresses. The / 24 can then be published from the desired region at any given time. Optimal request routing is then performed on that subset of traffic.
In one embodiment, the size of the address block can be chosen to be large enough for the customer so that the provider can selectively choose the area in which at least a portion of the space should be advertised. In another embodiment, a block of pre-assigned addresses that can be advertised in some or all areas, with the understanding that large amounts of traffic will need to be carried over the provider network. Can be used. Large customers could potentially take advantage of some remapable addresses from globally advertised blocks, and providers should address decisions on how to direct traffic on a smaller scale. Can be done.
In at least some of these embodiments, the customer can still receive many desirable disability-related features. In traditional systems, using remapable addresses, customers with some remapable addresses in Virginia will have those addresses at least temporarily if there is a transit outage in Virginia. It is unavailable and the request will drop as soon as it hits the network backbone, so you will experience problems. However, if customers rent a set of global remapable addresses, those addresses may be mapped to Virginia, but when Virginia leaves the Internet, these addresses will still remain. Other points of existence on the Internet It can be published at many points around the world, as it is published at all of presence: POP). This allows the customer to launch an instance in another area, and one or more of the global remapable addresses is that instance so that the service can be made available quickly and again. Can be mapped to. The advantage of such a process is that the entire operation can be contained entirely within the provider network so that there is no lag time or delay waiting for Internet BGP or DNS to propagate. Customers do not have to interact with their internet service provider, but instead one or one to the provider so that, for example, the DNS name and IP address can be made available again fairly quickly. You can make two API calls.
In some cases, the provider can monitor the status and, if necessary, automatically remap the address so that the customer does not need to detect the outage, and / Or any related issue needs to be addressed. In at least some embodiments, the customer can specify one or more policies for specifying how addresses should be remapped and the circumstances or criteria for remapping those addresses. .. In some cases, the customer may specify a policy such that certain mappings occur at a given time in a customer-predetermined automatic fashion. In other cases, the customer can specify that a remapping should occur in response to the occurrence of a type of event (eg, a domain failure).
In at least some embodiments, each domain knows about each other's domains where the customer has an address space with the provider. For example, in one or more tunnels, there may be communication established between those areas. You can maintain a list of mappings that show which address, or what section of the address space is currently outside the area. Therefore, when traffic enters the first region for a global remappable address that is currently mapped to the second region, the provider will determine the destination region so that it determines the destination region. Address translation and destination lookup can be performed on incoming traffic. The first region may be able to determine any information other than the identity of the second region, but can direct traffic along the tunnel to the second region. Once in the second area, traffic is local at that point, so proper routing protocol lookups can be performed.
In this embodiment, areas such as Los Angeles and Virginia can always advertise a given IP address on the Internet. When users are sitting in stores in Virginia, local ISPs generally prefer to use hot potato routing techniques to quickly get rid of that traffic. For this reason, ISPs generally direct traffic to the Virginia territory. However, in the event of a transit outage in Virginia, the backbone ISP will still receive a notice from LA so that the backbone can carry information into the LA area.
In some embodiments, the address can be published from more areas than is actually used to process the request. For example, global remappable addresses can be published from each of five different regions around the world. The address itself may be mapped to two of those areas, such as the examples in Virginia and Ireland. The mapping can be configured such that traffic arriving in Virginia is served in Virginia and traffic arriving in Ireland is served in Ireland. The mapping can also be configured such that traffic arriving in the US West Coast region is directed to Virginia, traffic arriving in Asia is directed to Ireland, and so on. For this reason, addresses are published in five different locations, but are directed to and served by only two of those locations. In at least some embodiments, routing is determined by configuration and is therefore non-intelligent. In at least some embodiments, there may be built-in intelligence or policies that direct the traffic to be routed to different locations based on various factors such as current load, time of day, and so on.
In some embodiments, there is no status detection or flow hashing, but anycast techniques can be used in which traffic is directed to a particular area based on factors such as the current time zone. As used herein, anycast generally refers to a technique known in the art for routing traffic to members of a potential recipient group, all associated with the same destination address. In at least some embodiments, it is possible to provide static configuration information that can include a particular area in which the traffic should be directed at any time or at any time, depending on where the traffic is received. it can. In other embodiments, the static configuration information can include the order or ranking of various regions that can direct traffic. For example, other areas can be ranked based on network proximity. This allows us to make decisions about where the global remappable address is active when traffic comes in for a particular address, and examines the list to determine the order of the various regions. be able to. In at least one embodiment, traffic is directed to the region where the address is active, which is the highest in the ranking list. In one example, a ranking list 400, such as that illustrated in Figure 4, may list LA, Virginia, and Ireland (in descending order), and global addresses for traffic are active in Ireland and Virginia. May be. In this case, traffic will be directed to Virginia because it is the highest ranked area where the address is active.
In at least some embodiments, the customer may have the ability to identify and / or update static configuration information, eg, at various or specific times, to adjust rankings. For example, a customer may want to specify that the traffic should be directed to a location within the area associated with Minnesota. Using a system such as the one described with reference to Figure 2, the customer can submit an API call to identify the updated configuration information, which is then the required configuration list (s). Can be propagated as needed to update (including). In at least some embodiments, the customer can identify different configuration information or policies for different areas and / or at different times. Various other types of information may also be included or utilized, as will be apparent in light of this disclosure.
In at least some embodiments, the determination of the appropriate area can be more dynamic. For example, the status of at least one area, such as whether the location is alive and available, as well as the distance from the current area to that area, and the current area and potential target areas. Judgments can be made regarding other information, such as the load between. In one embodiment, traffic may be received in LA, which may be directed to Virginia under normal conditions. If there is a large network event on the East Coast that currently renders Virginia unavailable, traffic will instead be routed to the next available area, which in this case could be located in Asia. can do. When Virginia returns online, Virginia may once again be a better option, so subsequent traffic may be routed to Virginia. Various other factors can also be included in the dynamic decision. For example, the majority of customers may be on the west coast and a relatively small number elsewhere. Therefore, a customer may want to require weighted traffic balancing, where the majority of customer traffic goes to a designated area and a smaller amount goes to the other area. Any of several other such policies can also be implemented within the scope of various embodiments.
Various policies may also be implemented by the provider. For example, a provider may base traffic on the basis of where the highest load is in the world based on time, where the load shifts around the world based on relative differences between daytime and nighttime periods, and so on. As mentioned above, we may implement a "sun-tracking" type of policy in which traffic is routed to different areas throughout the day, so as to reduce the average path length by routing. Such a policy can also implement global autoscale, allowing different regions to receive, process, and / or send different amounts of traffic based on time or other such factors. In some embodiments, the customer may move sites or applications "around the world" every 24 hours to accommodate the majority of traffic to a location that is relatively local to the current area. it can.
It should be understood that the various traditional methods provide some level of global demand routing solution. For example, Cambridge, Akamai from Massachusetts Technologies provides an edge solution that enables applications to run at the edge of the network, along with a global DNS director that has the ability to dynamically direct loads based on capacity. The global DNS director can act as a load balancer, not running on the data plane, but only dealing with balancing at the DNS level. If there are two data centers in different time zones, the DNS director can get information from the load balancer (or other component) from each time zone that indicates the amount of current capacity. The director can weight DNS responses based on their capacity, at least in part. For example, if there is a change in load or group members (ie, some additional servers come online), the DNS director can make the appropriate decisions. Such techniques are relatively limited in their capabilities and are not strongly consistent. In addition, there is some time lag with respect to the techniques described herein. Traditional techniques do not utilize global remappable IP addresses, especially at the service provider level, and thus cannot provide the various advantages or implementations in this disclosure.
Techniques that can be used to illustrate at least some of the differences in various embodiments with respect to a conventional system can be described with respect to FIGS. 5 (a) and 5 (b). In FIG. 5 (a), three level depictions 500 are illustrated, including the Internet 502 as the upper layer, the service provider 504 as the middle layer, and the lower protocol layer 506 (eg, the routing protocol infrastructure). The protocol layer is well connected, fully mapped, and everyone participates within the same area of the protocol layer. In the traditional approach of Figure 5 (a), there are many different points 508 where the Internet "touches" the service provider. Strictly one of those points will publish a specific IP address for the purpose of routing traffic. However, in the approach of FIG. 5 (b), two or more of those points where the service provider 514 touches the Internet 512 can publish the same global remappable IP address. Then, at the site where the IP address is published locally, the traffic coming into that IP is encapsulated with protocol-specific information so that the protocol layer 516 can interconnect various locations 518. can do.
In various embodiments, interconnects can be provided using other techniques in the absence of a routing protocol infrastructure, such as regular IP for NAT translation. For example, traffic can come from the Internet and go to a particular global IP address that can be translated into a region-specific, relatively slow-moving address. The traffic can then move forward towards that area, and when in that area it translates the address into the address of the actual host and receives the traffic, which may include mappings that move much faster. it can. In one embodiment, two NAT translation devices have more than one IP address if the source area is encoded into a destination IP address, and at least one of those addresses is a global re-address. It can be used when it is a mappable IP address. It can receive traffic destined for global IP addresses, which can be effectively remapped to region-specific remapable IP addresses. Response traffic can be remapped in a similar fashion.
Such techniques effectively utilize one-way mapping instead of (or in addition to) traditional two-way mapping. Consider the situation with the following IP addresses. A = Global remaptable IP address B = LA-specific IP address C = Internal provider IP address (eg host / instance address) In an embodiment where D = LA-specific IP address traffic arrives at an LA with a destination corresponding to global address A, the traffic should be mapped directly to internal address C, which should be delivered to the appropriate instance or the like. Can be done. This is similar to the way routing works, using traditional techniques. Instead, if traffic arrives at another area, such as Virginia, which is directed to global address A, Virginia can map traffic from the Internet to address B in LA. Can have a one-way mapping to B. Since the provider can be aware that the entire address block of which B is a member is in the LA, the provider is one from B to C so that the traffic can reach the intended instance. Traffic can be sent to LAs with directional mappings over the Internet, down the provider's backbone. Any return traffic can then go from C to A, following a direct remapping, so that the traffic can go directly to the Internet without having to bring it back to Virginia.
In at least some embodiments, the source area can also be encoded in such a manner. For example, Ireland may have an A D mapping instead of A B, but both B and D are located in LA. Traffic directed to A received in Ireland can undergo a NAT process to change the destination address to D, which allows the traffic to be sent to LA over the backbone or WAN. , The same D C mapping can be performed as in the previous embodiment. However, in this case, the system can differentiate between traffic entering Virginia and traffic entering Ireland. Such a technique allows the LA to determine where traffic has entered (but not necessarily an instance). Such a technique can allow traffic between regions to be pushed back to the Internet instead of being backhauled on the provider network if the intermediate IP is publicly routable. In at least some embodiments, the decision whether to backhaul or push onto the Internet can be made based on several factors, such as the current load and transit price.
FIG. 6 illustrates an exemplary process 600 for routing traffic using global addresses, which can be used according to various embodiments. In this embodiment, the global remappable address is selected 602 for at least one customer instance. As mentioned, the address can also point to various other types of destinations. Global addresses can also be mapped to any suitable internal or intermediate address, such as intermediate region addresses or individual instance addresses. The global address can then be published 606 from one or more areas, which can be any suitable location as described herein. Also, as mentioned, the area where global addresses are published can change at various times. At 608, when traffic is subsequently received to one of the areas directed to a global remappable address, the destination area can be determined 610. As stated, this can be a static decision that is at least partially based on configuration information, or based on factors such as current load, current availability, distance to area, ranking information, etc. It can also be a dynamic decision.
If the determined destination area is determined to be the same area where the traffic was received 612, then the traffic can be remapped to an internal address for the appropriate instance 614 and the traffic to that instance. Can deliver 616. If the area where the traffic is received is not the destination area as determined, the traffic can be remapped to the destination area 618 and forwarded to the destination area 620. As stated, this transfer can be made over a private provider network or a public network, depending on the various factors mentioned herein. When the traffic reaches its destination, it can be remapped and delivered to the instance as appropriate.
In various embodiments, similar mappings and translations can also be performed at the DNS level. For example, if the provider controls DNS for a given host, the DNS response can be modified so that the translation is between the DNS name and the IP address rather than between the IP addresses. Such techniques can be used, for example, in place of NAT translation or other protocol-specific encapsulation.
In addition, certain embodiments can address traffic received before and after the change in different ways. For example, a host with a global IP and DNS name may want to route that DNS name to a new area. In some embodiments, all traffic received in the old area may be dropped. However, in at least some embodiments, the system can direct traffic to new areas even when the final destination is not yet known or may not be available. In yet other embodiments where state information is maintained, the transaction can continue to be a service that was live in the previous area. Existing transactions can be processed in the old area and new traffic will be sent to the new area during the transition period to avoid dropping traffic.
Various other techniques can also utilize at least some of the functionality described above. For example, a system that utilizes Internet Protocol version 6 (IPv6) can utilize such a method even if IPv6 does not use it in NAT that follows the conventional method. However, intermediate IP addresses can still be used so that the various address translation techniques described herein can be utilized. In other methods, traffic arriving in a region with a primary translation from a global IP to a region-specific IP can be translated back and delivered to a globally unique IP address as usual. .. In at least some embodiments, address publication can be extended to a cloud front location (POP). Such techniques can be used to quickly move traffic over the provider's network so that any desired adjustment can be made more quickly.
Various embodiments can be described with the following sections in mind.
Section 1. A computer implementation method that directs network traffic, with multiple global remapable Internet Protocol (IP) addresses under the control of one or more computer systems that consist of executable instructions. To map to at least one virtual instance located in at least one of your network locations, and to publish a global remappable IP address from at least two of those network locations. Receiving network traffic to inbound network locations in at least two network locations where global remappable IP addresses are published, and determining the destination network location for network traffic. When the destination network location is the inbound network location, remapping the network traffic and delivering the network traffic to the target instance of at least one virtual instance, and when the destination network location is different from the inbound network location Remapping network traffic to an intermediate IP address to the destination network location, sending network traffic to an intermediate IP address at the destination network location, and when network traffic is received at the destination network location Methods, including remapping network traffic and delivering network traffic to the target instance.
Section 2. Further including determining whether to send network traffic to an intermediate IP address at the destination network location, on the private network of the service provider receiving the network traffic, or on the Internet, first. The computer implementation method described in the section.
3. The computer according to claim 2, wherein determining whether to send network traffic to an intermediate IP address over a private network or the Internet is at least partially based on the current load of the private network. Implementation method.
Section 4. A computer implementation method that directs network traffic, receiving network traffic to a service provider network under the control of one or more computer systems composed of executable instructions. Network traffic is received from at least one point in the service provider network to a globally remappable address, where each point resides in a different network location and maps to a target destination in the service provider network. Can be received, and when the target network location of the target destination is the same as the receiving network location where the network traffic is received, remap the network traffic and target the network traffic to the target destination When delivering to and when the destination network location is different from the receiving network location, Remapping network traffic to the intermediate address of the service provider network for the destination network location, sending network traffic to the intermediate address at the destination network location, and receiving network traffic at the destination network location When, including remapping network traffic and delivering network traffic to target destinations, methods.
Section 5. The computer implementation method described in Section 4, where global remappable addresses are published from at least two points in the service provider network.
Section 6. A remapping global address is a global remapping Internet Protocol (IP) address, and the service provider can use Domain Name System (DNS) or border gateway protocol (BGP) routing. The computer implementation method described in Section 4, which allows global routing of network traffic using at least one of them.
Item 7. The computer implementation method according to Item 4, wherein the target destination corresponds to at least one virtual machine in a multi-tenant resource environment.
Section 8. The computer implementation method described in Section 4, which allows the customer corresponding to the target destination to submit at least one policy that is useful in determining the target destination.
Section 9. The computer implementation method described in Section 7, where the customer may submit an updated policy through at least one application programming interface (API).
Section 10. The computer implementation method described in Section 8, where the customer may submit at least one policy per network location.
Section 11. The computer implementation method described in Section 4, wherein different network locations correspond to geographically dispersed areas or at least one of the networks operated by different providers.
Section 12. The computer implementation method described in Section 4, where the policy for determining the target destination is to specify the network location where network traffic should be directed at a particular time.
Section 13. At least one policy is used to determine the target destination, and at least one policy is where the network traffic originates, the type of customer that corresponds to the network traffic, or the financial associated with the network traffic. The computer implementation method described in Section 4, which determines the target destination based on at least one of the amounts of consideration.
Section 14. Target destinations are determined using static configuration information, which indicates the network location to which the traffic should be routed, at least in part based on the network location where the network traffic is received. The computer implementation method described in the section.
Section 15. Target destinations are dynamically determined based on factors, including the current load at a network location and at least one of the network proximity of a network location, as described in Section 4. Computer implementation method.
Section 16. Target destinations are determined using a list that ranks various network locations and a list of network locations where globally remapable addresses are active, as described in Section 4. Computer implementation method.
17. The computer implementation method described in Section 4, wherein global remappable addresses can be published from network locations in at least one of different countries and different continents.
18. The computer implementation method described in Section 4, wherein network traffic can be sent to intermediate addresses using public or private networks.
19. The computer implementation method described in Section 4, wherein at least some of the mappings between global remapable addresses, intermediate addresses, and destination addresses are unidirectional.
Section 20. Global remapping addresses can be mapped to fewer network locations than some network locations where global remapping addresses are published, as described in Section 4. Computer implementation method.
Section 21. At least one network location where a global remappable address is published is a local resource for which at least some type of traffic can be carried or approved for processing. The computer implementation method described in Section 17, which does not have.
Section 22. The computer implementation method described in Section 4, where network traffic is directed using anycast techniques.
Section 23. The computer implementation method described in Section 4, wherein the customer can specify weighted traffic balancing and the approximate amount of received traffic is directed to at least one network location. ..
Section 24. Addresses can be globally remapped to a new virtual machine, existing transactions can be processed using the previous virtual machine, while new transactions are for processing. In addition, the computer implementation method described in Section 4, which is directed to a new virtual machine.
Section 25. A system for managing network traffic, which is the processor and, when executed by the processor, the processor receiving network traffic to the service provider network, which is the service provider. Received from at least one point in the network to a global remappable address, each point can reside in a different network location and be mapped to a target destination in the service provider network. Remapping network traffic and delivering network traffic to the target destination when there is, receiving, and the target network location of the target destination is the same as the receiving network location where the network traffic is received. When the destination network location is different from the receiving network location, Remapping network traffic to the intermediate address of the service provider network for the destination network location and sending network traffic to the intermediate address at the destination network location, thereby receiving network traffic at the destination network location. A system that includes a memory device, including instructions, that can remap and deliver network traffic to a target destination.
Section 26. The system according to Section 25, wherein the target destination is determined according to at least one of policy, ranking list, network load, or static configuration.
27. The system according to paragraph 25, wherein network traffic can be sent to intermediate addresses using public or private networks.
Section 28. A non-transitory computer-readable storage medium that stores instructions for managing network traffic, which, when executed by the processor, causes the processor to network to the service provider network. To receive traffic, network traffic is received from at least one point in the service provider network to a globally remappable address, where each point resides in a different network location, and Re-network traffic when receiving and targeting the target network location is the same as the receiving network location where the network traffic is received, which can be mapped to the target destination of the service provider network. When mapping and delivering network traffic to a target destination and when the destination network location is different from the receiving network location Remapping network traffic to the intermediate address of the service provider network for the destination network location and sending network traffic to the intermediate address at the destination network location, thereby receiving network traffic at the destination network location. A non-transitory computer-readable storage medium that allows network traffic to be remapped and delivered to target destinations.
Section 29. At least some of the mapping between global remapping addresses, intermediate addresses, and destination addresses is unidirectional and is readable by the non-transitory computer described in Section 28. Storage medium.
As mentioned above, various embodiments may, in some cases, be used to operate any of several applications, one or more user computers, computing devices, and the like. Alternatively, it can be implemented in a wide variety of operating environments, which can include processing devices. The user or client device can run some general purpose personal computers, such as desktop or laptop computers running standard operating systems, as well as mobile software and support several networking and messaging protocols. It can include any of the following, wireless, and handheld devices. Such systems can also include several workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. These devices can also include other electronic devices such as dummy terminals, thin clients, gaming systems, and other devices capable of communicating over the network.
The various aspects can also be implemented as part of at least one service or web service so that they can be part of a service-oriented architecture. Services such as web services communicate using any suitable type of messaging, for example by using extended markup language (XML) -style messages, and SOAP (Simple Object Access Protocol (Simple). It can be exchanged using an appropriate protocol (derived from Object Access Protocol)). The processes provided or executed by such services can be written in any suitable language, such as the Web Services Description Language (WSDL). The use of languages such as WSDL enables functionality such as automatic generation of client-side code in various SOAP frameworks.
Most embodiments are skilled in the art to support communication using any of a variety of commercially available protocols such as TCP / IP, OSI, FTP, UPnP, NFS, CIFS, and AppleTalk. Utilize at least one network, which will be well known to. The network can be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public exchange telephone network, an infrared network, a wireless network, or any combination thereof.
In embodiments that utilize a web server, the web server can run either a variety of servers or mid-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. included. The server (s) are also written in any programming language, such as Java®, C, C #, or C ++, or any scripting language, such as Perl, Python, or TCL, and combinations thereof. It may be possible to execute a program or script in response request from a user device by executing one or more web applications, which may be implemented as one or more scripts or programs. Servers (including multiple) are also databases, including, without limitation, commercially available from Oracle®, Microsoft®, Sybase®, and IBM®. It may include a server.
The environment can include a variety of data stores and other memory and storage media as described above. They may reside locally (and / or reside within) one or more of the computers, or across networks, in various locations, such as on a remote storage medium from any or all of the computers. Can be done. In certain sets of embodiments, the information may reside in a storage area network (SAN) well known to those of skill in the art. Similarly, any necessary file to perform a function originating from a computer, server, or other network device may be stored locally and / or remotely, as appropriate. If the system includes computerized devices, each such device may include a hardware element that may be electrically coupled via a bus, which may include, for example, at least one central processing unit. (CPU), at least one input device (eg, mouse, keyboard, controller, touch screen, or keypad), and at least one output device (eg, display device, printer, or speaker). Such systems also include disk drives, optical storage devices, and solid state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash cards, and the like. , May include one or more storage devices.
Such devices also include computer-readable storage media readers, communication devices (eg, modems, network cards (wireless or wired), infrared communication devices, etc.), and working memory, as described above. Can be done. A computer-readable storage medium A reader can be configured to connect to or accept a computer-readable storage medium, temporarily and / or more permanently, computer-readable information. Represents a remote, local, fixed, and / or removable storage device, and storage medium for containing, storing, transmitting, and retrieving. The system and various devices also typically include some software application, module, service, or other element located within at least one working memory device, such as an operating system and an application such as a client application or web browser. Contains the program. It should be understood that alternative embodiments may have a number of modifications from those described above. For example, customized hardware may also be used, and / or certain elements may be implemented in hardware, software (including portable software such as applets), or both. .. In addition, connections to other computing devices such as network input / output devices may be employed.
The code, or storage medium and computer readable medium for containing a portion of the code, can include any suitable medium known in the art, including storage media and communication media, which can be read by the computer. Volatile and non-volatile removable and non-removable, implemented in any method or technique for the storage and / or transmission of information such as possible instructions, data structures, program modules, or other data. RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage device, but not limited to It also includes other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by the system device. Based on this disclosure and the teachings provided herein, one of ordinary skill in the art will understand other ways and / or methods for implementing various embodiments.
Accordingly, the specification and drawings shall be viewed in an exemplary sense rather than in a restrictive sense. However, it will be clear that various modifications and modifications may be made to it without departing from the broad spirit and scope of the invention as set forth in the claims.
8 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| JP2021530916A | Cited by | Japan | Search report |
| JP2000132524A | Cites | Japan | Search report |
| JP2003508996A | Cites | Japan | Search report |
| US2008040306A1 | Cites | United States of America | Search report |
| US2011261828A1 | Cites | United States of America | Search report |
16 members in 9 offices
Priority claims7
| Document | Office | Kind | Date |
|---|---|---|---|
| 13044494 | United States of America | – | |
| 201113044494 | United States of America | A | |
| 2012028480 | United States of America | W | |
| 2011044494 | – | – | – |
| 2012028480 | – | – | – |
| US201113044494 | – | – | – |
| WO2012US28480 | – | – | – |
Members16
| Document | Office | Kind | |
|---|---|---|---|
| CA2824598A1 | Canada | A1 | |
| US2012233329A1 | United States of America | A1 | |
| WO2012122474A2 | World Intellectual Property Organization (WIPO) | A2 | |
| SG191948A1 | Singapore | A1 | |
| WO2012122474A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP2684065A2 | European Patent Office (EPO) | A2 | |
| CN103620597A | China | A | |
| JP2014512739AThis record | Japan | A | |
| AU2012225301B2 | Australia | B2 | |
| EP2684065A4 | European Patent Office (EPO) | A4 | |
| JP5727053B2 | Japan | B2 | |
| CA2824598C | Canada | C | |
| BR112013021997A2 | Brazil | A2 | |
| US10009315B2 | United States of America | B2 | |
| CN103620597B | China | B | |
| BR112013021997B1 | Brazil | B1 |
18 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 | |
| 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 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 |
Numbers
- Publication
- 2014512739
- Publication, DOCDB
- 2014512739
- Publication, EPODOC
- JP2014512739
- Application
- 2013557899
- Application, DOCDB
- 2013557899
- Application, EPODOC
- JP20130557899
Titles2
- Japanese
- 外部ライブ移行
- English
- External live migration
Classification
- CPC, 9
- H04L61/2514
- H04L61/4511
- H04L61/5084
- H04L43/0817
- H04L61/5076
- H04L67/563
- H04L67/52
- H04L61/2521
- H04L67/1001
- IPC, 4
- H04L45 741
- H04M11 00
- H04L12 721
- H04L12 749
Designated states5
- Regional, 4
- Zimbabwe
- Turkmenistan
- Türkiye
- Togo
- National, 1
- Viet Nam