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.
- How can we reduce the delay to a minimum?
- Is there any good practice to achieve this High-Availability functionality?