|
| 1 | +--- |
| 2 | +# Copyright Vespa.ai. All rights reserved. |
| 3 | +title: "Routing and endpoints" |
| 4 | +category: cloud |
| 5 | +--- |
| 6 | + |
| 7 | +<p> |
| 8 | + Vespa Cloud supports multiple methods of routing requests to an application. |
| 9 | + This guide describes how these routing methods work, failover, and how to configure them. |
| 10 | +</p> |
| 11 | +<p> |
| 12 | + By default, each deployment of a Vespa Cloud application will have a zone endpoint. |
| 13 | + In addition to the default zone endpoint, one can configure global endpoints. |
| 14 | +</p> |
| 15 | +<p> |
| 16 | + All endpoints for an application are available under the |
| 17 | + <em>endpoints</em> tab of each deployment in the console. |
| 18 | +</p> |
| 19 | + |
| 20 | + |
| 21 | + |
| 22 | +<h2>Endpoint format</h2> |
| 23 | +<p>Vespa Cloud endpoints are on the format: <code>{random}.{random}.{scope}.vespa-app.cloud</code>.</p> |
| 24 | + |
| 25 | + |
| 26 | + |
| 27 | +<h2>Endpoint scopes</h2> |
| 28 | + |
| 29 | + |
| 30 | +<h3 id="zone-endpoint">Zone endpoint</h3> |
| 31 | +<p> |
| 32 | + This is the default endpoint for a deployment. |
| 33 | + Requests through a zone endpoint are sent directly to the zone. |
| 34 | +</p> |
| 35 | +<p> |
| 36 | + Zone endpoints are created implicitly, one per container cluster declared |
| 37 | + in <a href="/en/reference/services-container.html">services.xml</a>. |
| 38 | + Zone endpoints are not configurable. |
| 39 | +</p> |
| 40 | +<p>Zone endpoints have the suffix <code>z.vespa-app.cloud</code></p> |
| 41 | + |
| 42 | + |
| 43 | +<h3 id="global-endpoint">Global endpoint</h3> |
| 44 | +<p> |
| 45 | + A global endpoint is an endpoint that can route requests to multiple zones. |
| 46 | + It can be configured in <a href="/en/reference/deployment.html#endpoints-global">deployment.xml</a>. |
| 47 | + Similar to how a <a href="https://en.wikipedia.org/wiki/Content_delivery_network">CDN</a> works, |
| 48 | + requests through this endpoint will be routed to the nearest zone based on geo proximity, |
| 49 | + i.e. the zone that is nearest to the client. |
| 50 | +</p> |
| 51 | +<p>Global endpoints have the suffix <code>g.vespa-app.cloud</code></p> |
| 52 | +{% include important.html content='Global endpoints do not support feeding. |
| 53 | +Feeding must be done through zone endpoints.' %} |
| 54 | + |
| 55 | + |
| 56 | + |
| 57 | +<h2 id="routing-control">Routing control</h2> |
| 58 | +<p>Vespa Cloud has two mechanisms for manually controlling routing of requests to a zone:</p> |
| 59 | +<ul> |
| 60 | + <li> |
| 61 | + Removing the <code><region></code> element from |
| 62 | + the relevant <code><endpoint></code> elements in |
| 63 | + <a href="/en/reference/deployment">deployment.xml</a> and deploying a new version of your application. |
| 64 | + </li> |
| 65 | + <li>Changing the status through the console.</li> |
| 66 | +</ul> |
| 67 | +<p> |
| 68 | + This section describes the latter mechanism. |
| 69 | + Navigate to the relevant deployment of your application in the console. |
| 70 | + Hovering over the <em>GLOBAL ROUTING</em> badge will display the current status and when it was last changed. |
| 71 | +</p> |
| 72 | + |
| 73 | + |
| 74 | +<h3>Change status</h3> |
| 75 | +<p> |
| 76 | +In case of a production emergency, |
| 77 | +a zone can be manually set out to prevent it from receiving requests: |
| 78 | +</p> |
| 79 | +<ol> |
| 80 | + <li> |
| 81 | + Hover over the <em>GLOBAL ROUTING</em> badge for the problematic deployment and click <em>Deactivate</em>. |
| 82 | + </li> |
| 83 | + <li> |
| 84 | + Inspection of the status will now show the status set to <em>OUT</em>. |
| 85 | + To set the zone back in and have it continue receiving requests: |
| 86 | + Hover over the <em>GLOBAL ROUTING</em> badge again and click <em>Activate</em>. |
| 87 | + </li> |
| 88 | +</ol> |
| 89 | + |
| 90 | + |
| 91 | + |
| 92 | +<h3>Behaviour</h3> |
| 93 | +<p> |
| 94 | + Changing the routing status is independent of the endpoint scope used. |
| 95 | + You're technically overriding the routing status the deployment reports to the Vespa |
| 96 | + Cloud routing infrastructure. This means that a change to routing status |
| 97 | + affects both <em>zonal endpoints</em> and <em>global endpoints</em>. |
| 98 | +</p> |
| 99 | +<p> |
| 100 | + Deactivating a deployment disables routing of requests to that deployment |
| 101 | + through global endpoints until the deployment is activated again. |
| 102 | + As routing through these endpoints is DNS-based, |
| 103 | + it may take up between 5 and 15 minutes for all traffic to shift to other deployments. |
| 104 | +</p> |
| 105 | +<p> |
| 106 | + If all deployments of an endpoint are deactivated, requests are distributed as if all deployments were active. |
| 107 | + This is because attempting to route traffic according to the original configuration is preferable |
| 108 | + to discarding all requests. |
| 109 | +</p> |
| 110 | + |
| 111 | + |
| 112 | + |
| 113 | +<h2 id="aws-clients">AWS clients</h2> |
| 114 | +<p> |
| 115 | + While Vespa Cloud is hosted in AWS, clients that talk to Vespa Cloud |
| 116 | + from AWS nodes will be treated as any other client from the Internet. |
| 117 | + This means clients in AWS will generate regular Internet egress traffic |
| 118 | + even though they are talking to a service in AWS in the same zone. |
| 119 | +</p> |
0 commit comments