0

Our meteor deployment contains two meteor nodes, behind a network load balancer (Google cloud NLB which simply passes on requests to a target pool of 2 Ubuntu 14.04 meteor instances).

Each node has a Nginx installed terminating SSL and proxy passing requests to the application on port 3000.

Nginx configuration:

server_tokens off; # for security-by-obscurity: stop displaying nginx version

# this section is needed to proxy web-socket connections
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;

# HTTPS server
server {
    listen 443 ssl spdy; # we enable SPDY here
    server_name meteor.cg-platform.com; # this domain must match Common Name (CN) in the SSL certificate

    root html; # irrelevant
    index index.html; # irrelevant

    ssl_certificate /etc/nginx/ssl/server.crt; # full path to SSL certificate and CA certificate concatenated together
    ssl_certificate_key /etc/nginx/ssl/server.key; # full path to SSL key

    # performance enhancement for SSL
    ssl_stapling on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 5m;

    # safety enhancement to SSL: make sure we actually use a safe cipher
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES$

    # config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
    # to avoid ssl stripping https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
    # add_header Strict-Transport-Security "max-age=31536000;";

    # If your application is not compatible with IE <= 10, this will redirect visitors to a page advising a browser update
    # This works because IE 11 does not present itself as MSIE anymore
    if ($http_user_agent ~ "MSIE" ) {
        return 303 https://browser-update.org/update.html;
    }

    # pass all requests to Meteor
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade; # allow websockets
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr; # preserve client IP

        # this setting allows the browser to cache the application in a way compatible with Meteor
        # on every applicaiton update the name of CSS and JS file is different, so they can be cache infinitely (here: 30           days)
        # the root path (/) MUST NOT be cached
        if ($uri != '/') {
            expires 30d;
        }
    }
}

We have deployed the simple-todos application from the meteor example repository user mup.

We're testing the failover of one node to the the other by shutting down the app on one node and see if the browser re-establishes the connection with the other node. This actually works, but with a delay that can be quiet big - between 1 second and up to 20 seconds(!).

On the browser console we are getting some 502-BAD_GATEWAY errors until the websocket re establishes the connection to the other working node.

  1. How can we reduce the delay to a minimum?
  2. Is there any good practice to achieve this High-Availability functionality?
3
  • Please add more details about your load balancer configuration. Once you do that, the question will be flagged for re-opening.
    – EEAA
    Nov 30, 2015 at 13:00
  • Added some more info and the proxy config.
    – Danny Z
    Nov 30, 2015 at 13:19
  • Please add the config here, in a proper code blok. In general, make it as easy as you can for people to help you. That means proving as many relevant details as you can, and providing them here so people don't need to go chasing all over the place for information.
    – EEAA
    Nov 30, 2015 at 13:25

0

You must log in to answer this question.

Browse other questions tagged .