Today (July 24th) marks the completion of our last three months’ development and the release of NGINX Plus Release 4 (R4).
NGINX Plus R4 brings together the features recently released in our open source branch with a number of commercial‑only features into a fully tested and supported release.
Certificate validation and SNI support for upstreams improves the security of API calls and load‑balanced traffic in untrusted environments. An external passphrase store improves the security of your valuable SSL private keys.
End‑to‑end security is a key concern, particularly if you’re building an application that spans more than one location. If your internal traffic goes across the open Internet (or even within a public cloud), basic SSL alone is not sufficient to protect against trivial man‑in‑the‑middle (MITM) attacks. This release (with thanks to CloudFlare) adds certificate verification for upstream servers, so you can be confident that NGINX Plus is talking to the server it’s intending to. It also adds SNI support for upstreams to help scale out complex upstream services securely.
Internal security is just as important. Lots of sites store their NGINX Plus configuration centrally, but that raises concerns about keeping the SSL private key private. Passphrases to decrypt the private key are the right solution, but until now they have been very inconvenient.
NGINX Plus allows you to use an external passphrase store, local to each server and separate from the configuration. This ensures that keys are protected when the configuration is stored or in flight, and only authorized servers can decrypt them.
Improved Load Balancing and Caching
Release 4 adds a new load balancing algorithm – Hash – to the existing algorithms (Round Robin, IP Hash, and Least Connections). Hash‑based load balancing enables you to distribute traffic evenly across an upstream group based on a hash function of any combination of request parameters: source IP address and port, URL, and so on.
The Hash method becomes very useful if you enable the optional
consistent parameter to the
hash directive. This enables consistent hash load balancing (using the ketama load‑balancing method for interoperability with memcached), which is a huge bonus when load balancing cache servers and other applications that accumulate state.
With consistent hashing requests are shared evenly among the target servers based on the hash value of the user‑specified key. If a server is added or removed (because it fails, for example), the minimum possible hash space is redistributed to minimize any cache misses. For even distribution, NGINX Plus’s ketama‑based implementation uses 160 points per server in the hash space (the illustration above shows only 8 points).
Release 4 also adds a new session affinity mechanism – sticky learn – to the existing mechanisms (sticky route and sticky cookie). The learn mechanism is hugely flexible: NGINX Plus dynamically learns which sessions are initiated by each server and knows how to identify the session signature in client requests. There’s lots of scope to use this feature if you need fine‑grained control of how requests are routed within upstream groups.
Finally, caching is now even more effective at minimizing the load on your upstream servers. Cache revalidation can use
ETags as well as
Last-Modified timestamp to check that content has not changed.
Easier Monitoring – Drill Down into the Data You Need
Focus on the information you need with techniques to filter and drill down on logging and monitoring data.
NGINX Plus generates a wealth of data, through the access_log and its unique live activity monitoring feature. Sometimes the sheer volume of data can be overwhelming – the cost of collecting, storing, and analyzing it may just be too great, particularly for busy sites with large numbers of services and users.
Conditional logging to the access log allows you to define the interesting requests that are logged, and disregard the less interesting ones. It’s really useful for run‑time decisions; perhaps you just want to log requests that generate 5xx server errors? Or disregard requests from the local network? Maybe you want to strip out useless data being generated by an external health monitor? Whatever your requirements, if you want to filter and limit log entries at runtime, then conditional logging is the answer.
In previous releases of NGINX Plus, requests for the live activity monitoring data generated by the extended status module returned a massive amount of internal data describing current activity and state. However, if all you want to do is to monitor one counter (for example, request counts) or you just want to get the health status of the nodes in your upstreams, then it’s inefficient to grab the entire set of status data. With Release 4, you can use a RESTful API to drill down and retrieve subsets of the data, or just a single value, making monitoring more efficient and lightweight.
Other New Features in NGINX Plus R4
NGINX Plus R4 inherits other recent updates, fixes, and new features from the NGINX 1.7.3 release, and the third‑party modules included in the nginx-plus-lua and nginx-plus-extras packages have been updated to use Lua version 0.9.10 and Passenger Open Source version 4.0.45.
In line with our policy of supporting the versions of operating system distributions that are supported by their vendors, we have added support for CentOS/RHEL 7 and terminated support for Ubuntu 12.10, 13.04, and 13.10.
For a complete list of new features and changes in Release 4, see the NGINX Plus Releases page.
If you’re running NGINX Plus, we strongly encourage you to update to Release 4 as soon as possible. You’ll pick up a number of fixes and improvements, and it will help us to help you if you need to raise a support ticket. Installation and upgrade instructions can be found at the NGINX Plus customer portal.
If you’ve not tried NGINX Plus, please start your 30‑day free trial and learn how NGINX Plus can help you scale out and deliver your applications.