Using AMPS with a Proxy

Accessing AMPS Through a Proxy

For some installations, it is important to be able to configure access to an AMPS instance through a proxy server.

AMPS client connections and AMPS replication connections are TCP connections that use a custom protocol to communicate. Any proxy that does not alter the content of packets will work as expected for both client connections and replication connections.

Using a proxy with AMPS is most straightforward when there is a one-to-one relationship between a port on the proxy and a port on the AMPS instance. In many cases, though, it is useful to have a single port on the proxy and then to route to a different backend instance of AMPS.

Websocket Connections

Current versions of the AMPS javascript client support the ability to insert arbitrary paths between the hostname and port and the protocol and message type components of the AMPS connection URI.

For example, a URI of ws://proxyhost:8080/amps-prod-system/amps/json could be used by the proxy to route to the system designated amps-prod-system.

Galvanometer Connections

The Galvanometer relies on the path provided to determine which resource to return. If it's necessary to proxy multiple systems behind a single port, it is typically most useful to have the proxy rewrite the URI when forwarding the request. For example, the proxy could rewrite a request for http://proxyhost:8085/prod-system/ to http://amps-prod-system:8085/.

For example, an NGINX proxy configuration could be implemented along the lines of:

server {
    listen 8085 default;
    listen [::]:8085;

  server_name AMPS;

  # server context
  location /amps-prod-system/ {
      proxy_set_header X-Forwarded-Host $host;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://amps-prod-system:8085/; #hostname and port of AMPS host for first AMPS instance
  }
  location /amps-dev-system/ {
      proxy_set_header X-Forwarded-Host $host;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://amps-dev-system:8085/; #hostname and port of AMPS host for second AMPS instance
  }
}

The Admin configuration item allows an instance to advertise a publicly-accessible address for the admin server. This is useful when the internet address used for replication between servers is a private address, for example, in a hosting situation where replication connections between two instances use a private network, while Galvanometer connections use a proxy or public network. In this case, use the ExternalInetAddroption in the configuration to specify an address where the admin server can be reached.

The ExternalInetAddr option does not override the InetAddr parameter or change the network addresses that the admin server uses. Instead, it's intended to provide an externally visible address that will reach the InetAddr.

Galvanometer relies on the hostnames provided by the AMPS configuration to locate replicated instances and retrieve information from their admin interfaces. If Galvanometer does not have access to the replicated instances at the hostname or IP provided in the AMPS configuration file, it will not be able to display information about replicated instances. This does not indicate an issue with replication on those instances, it just means that the Galvanometer view (which is constructed by Galvanometer in the browser) cannot provide the information. The ExternalInetAddr parameter is used to provide that information to Galvanometer.

Load-Balancing Considerations

Some proxy systems are also intended to implement load-balancing. The approach that a given installation uses to determine how to distribute connections depends on the resource that the load-balancing system is managing, and the needs of the application. For example, an application where all subscribers produce roughly the same amount of traffic could use a simple round-robin load balancing system to distribute network load. On the other hand, a proxy for an application where subscribers execute complex aggregated subscriptions might monitor CPU load or memory consumption on a set of servers that host AMPS and attempt to route a new connection to the server with the lowest current load.

Regardless of the approach used, it is important to keep in mind that, for a publisher or queue consumer, the same considerations for the proxy apply as would apply for specifying failover equivalents to a client application directly. In particular, a publisher or a subscriber that processes a queue should not fail over across a replication connection that uses asynchronous acknowledgment (or a connection that has been downgraded to be asynchronous). If this happens, there is a possibility of message loss and/or inconsistent transaction log contents. See the discussion of synchronous and asynchronous acknowledgment (Sync vs Async Acknowledgment) in the Configuring Replication section for more details.