隆重推出 NGINX Plus R9

9 years ago

NGINX, Inc. is proud to announce the availability of NGINX Plus Release 9 (R9), the latest release of our application delivery platform. This update provides two significant new features: the ability to dynamically load rich extensions to NGINX Plus without the need for custom binaries, and commercially supported UDP load balancing alongside our existing TCP and HTTP load balancing capabilities.

In addition to the exciting new functionality in NGINX Plus R9, we are debuting new pricing and support options. NGINX Plus is now available through an “all you can eat” pricing model that allows you unlimited use everywhere in your application or enterprise for one fixed price. NGINX Plus can now also be purchased with three different support levels: Basic 9×5 support for non‑production applications, Professional 24×7 support via phone or email, and Enterprise 24×7 support with responses guaranteed within 30 minutes.

Editor – For more details about key new features in NGINX Plus R9, see these related resources.

The key new features in NGINX Plus R9 are:

Dynamic modules – NGINX Plus can now be extended at runtime with dynamically loadable modules. That means you can select just the extensions you want and install them directly from the NGINX Plus repository, accessible via standard apt and yum commands. Over time we’ll be distributing an ever‑growing set of tested and fully certified extensions for our software.

The most popular NGINX‑authored and third‑party modules, such as support for the Lua programming language, have already been converted to the new dynamically loadable format. We have also published instructions for third‑party module owners to convert their modules to the new format, which is required before the modules can be added to our repository.
UDP load balancing – With the addition of UDP load balancing to its existing TCP and HTTP load‑balancing capabilities, NGINX Plus can now load balance almost any application. We added UDP load balancing in NGINX Open Source last month, and with this release we are extending support to NGINX Plus with additional advanced features. NGINX Plus monitors UDP services with active health checks, gives critical visibility with a wealth of stats, and allows you to add and remove servers dynamically.

UDP is commonly used for lightweight protocols that are not transactional in nature, such as DNS (resolving domain names to addresses), syslog (lightweight logging), and RADIUS (an authentication protocol). UDP is also emerging as one of the protocols of choice for IoT applications due to its low bandwidth requirements. NGINX Plus can deliver and load balance these existing and new applications with ease.
Service Discovery using DNS SRV records – Microservice‑based applications are dynamic – services can be scaled up, scaled down, and moved on demand. A good way to stay on top of the current state of your services is to use service discovery. Many service discovery platforms, such as Consul and etcd (SkyDNS), offer a DNS interface for clients (such as NGINX Plus) to request information about discovered services.

The port number used by services is often dynamically assigned. As a result, service discovery platforms make use of DNS SRV records which include port number information. NGINX Plus now supports DNS SRV records and can use DNS requests to query the service registry for the locations of your services, including dynamically assigned port information.
NGINX Plus App Pricing – To ensure maximum performance and uptime during high growth, seasonality, or elastic traffic, many applications require dynamic infrastructure. These apps also typically make use of microservices or distributed architectures, and utilize containers or virtual machines for runtime. Paying per instance or machine hour for software doesn’t deliver the flexibility or cost effectiveness that these modern apps require. For these use cases, we’re introducing NGINX Plus App Pricing.

NGINX Plus App Pricing provides unlimited, “all you can eat” usage of NGINX Plus’ extended capabilities and commercially supported binaries for one flat‑rate price per application per year. No matter how many VMs, containers, nodes, concurrent connections, or users, you pay one low rate for the entire year. Deploy NGINX Plus whenever, wherever, and however you need within your application infrastructure, and across development, testing, staging, disaster recovery, and production environments – no need to worry about unpredictable consumption‑based bills and no need to wait to obtain license keys when you need to burst capacity suddenly.

NGINX Plus R9 Features in Detail

This section provides a detailed overview of all the new features and functionality in NGINX Plus R9.

Dynamic Modules

NGINX and NGINX Plus both have a modular architecture. Their core functionality can be extended by modules written both by third‑party developers and by the core NGINX engineering team. These modules add key functionality, such as embedding Lua scripting and geolocating users based on IP address. There are over 100 third‑party modules and over 60 official NGINX modules available. We include 56 of these in the base nginx‑plus package and an additional 10 in the nginx‑plus‑extras package (the full list is available at NGINX Plus Technical Specifications).

Features can be plugged into NGINX Plus on demand

With this release, the additional modules in the nginx‑plus‑extras package (both third‑party and official NGINX) can also be loaded dynamically into the base NGINX Plus package, nginx‑plus. This allows you to load only the additional modules you actually need.

These modules are available in the NGINX Plus repository, and we plan to add modules to the repository in the coming months. We encourage anyone currently using the nginx‑plus‑extras package to migrate to the core nginx‑plus package because we will deprecate the nginx‑plus‑extras package in a later release.

We test each dynamic module by loading it into the NGINX Plus core before running our broad range of release tests, so we can be confident that (when unconfigured) the module does not interfere with the correct operation of NGINX Plus. We’ll track module updates and issue new builds at each release, and if a critical security problem is reported between releases.

Having dynamic modules enables us to distribute a single NGINX Plus binary with the functionality everyone uses. Administrators can then pick and choose the additional modules they want to use.

How to Load Dynamic Modules in NGINX Plus

To install and dynamically load modules, perform the following steps. They assume that you have configured your package management tool to retrieve files from NGINX, Inc. rather than the OS vendor’s distribution.

Use your operating system’s standard package management tool (apt or yum, for example) to install the base nginx‑plus image and the modules you want to load dynamically (repeat the installation command for each module). The following commands are appropriate for Debian‑based systems.
```
# apt-get update
# apt-get install nginx-plus
# apt-get install module-name
```
The names you can substitute for module‑name in this release are:
The /etc/nginx/modules directory is created automatically with symbolic links to the installed locations of the .so files for the selected modules.

Notes:
- If you are using the nginx‑plus‑extras package for an earlier release of NGINX Plus, you must remove it before installing the R9 nginx‑plus package. For Debian‑based systems, the appropriate set of commands is:
```
# apt-get update
# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name
```
- Some modules are not available for certain OS versions because of OS limitations. For details as well as descriptions of the modules, see the NGINX Plus Technical Specifications.
In the main (top‑level) context in /etc/nginx/nginx.conf, add a load_module directive for each dynamically loadable module:
```
load_module modules/module-name.so;
```
Check the new configuration for syntactic validity and reload NGINX Plus.
```
# nginx -t && nginx -s reload
```
The modules listed in nginx.conf are dynamically loaded into NGINX Plus.

UDP Load Balancing

Last month we released UDP load balancing in NGINX Open Source, and NGINX Plus R9 extends that capability with health checks, extended status monitoring, and on‑the‑fly reconfiguration.

As for TCP load balancing, the configuration for UDP load balancing goes in the stream context. And like both HTTP and TCP load balancing, UDP load balancing uses an upstream group to define the set of origin servers that provide the UDP‑based service and the algorithm to use when load balancing traffic across the servers.

The configuration also defines a virtual server for each UDP port, with a proxy_pass directive naming the upstream group that provides the associated service:

stream {
    upstream dns_upstreams {
        least_time;
        server dns-server-1-ip:53;
        server dns-server-2-ip:53;
    }
 
    server {
        listen 53 udp;
        listen 53; #tcp
        proxy_pass dns_upstreams;
        proxy_timeout 1s;
        proxy_responses 1;
        error_log logs/dns.log;
    }
}

This configuration example is for load balancing DNS services. In the upstream block, we’re configuring the Least Time algorithm, so NGINX Plus sends each request to the server that currently has the fewest “connections” and is responding fastest. In the server block, we listen for both UDP and TCP traffic, because DNS can run over both protocols. The proxy_responses directive controls how many responses NGINX Plus receives from the upstream server before releasing the resources associated with the UDP “connection”. Because DNS is a simple request‑reply protocol, one response is normally sufficient.

NGINX Open Source includes basic health checks for UDP. If an upstream UDP server fails to respond to a request within a defined timeout period, or returns an ICMP error, NGINX and NGINX Plus stop sending traffic to it for a defined amount of time.

NGINX Plus R9 adds active health checks for UDP services, similar to those for HTTP and TCP traffic. You can configure NGINX Plus to send special UDP requests to upstream servers and define the type of response the servers must return to be considered healthy. Because UDP does not have the mechanisms for reliable delivery that TCP provides for HTTP, active health checks are even more critical for UDP applications than for TCP and HTTP applications.

With NGINX Plus you can also add or remove upstream servers on the fly. This makes it easy to (for instance) take servers offline for maintenance, and then reinsert them into the load‑balanced pool. New UDP‑related statistics in the NGINX Plus Status module and live activity monitoring dashboard give you critical visibility into how well your servers are performing.

NGINX Plus R9 load balances the most commonly used simple UDP‑based applications: DNS, RADIUS, syslog, and NTP. Long‑lived UDP protocols such as Voice over IP and other SIP‑based applications are not supported at this time.

Service Discovery using DNS `SRV` Records

Modern web applications are composed of multiple small application components – web servers, application servers, databases, and so on. A frontend load balancer such as NGINX Plus inspects incoming traffic, and then routes and load balances requests across the application components.

When application components are deployed on virtual or container‑based platforms, they can have unpredictable IP addresses and ports. Service discovery is the process by which a local client (such as the frontend NGINX Plus load balancer) locates these components so it can send traffic to them. Service discovery is generally facilitated by a “service database” such as Consul, etcd, or ZooKeeper.

In NGINX Plus R8, we announced a persistent version of our on‑the‑fly reconfiguration API, and shared demo solutions for Consul, etcd, and ZooKeeper that check the service database and push configuration changes into NGINX Plus. In NGINX Plus R9, we’re pleased to announce support for an alternative method that uses DNS SRV queries. DNS SRV queries return the IP address, port, priority, and weight of application servers of a particular type.

Consul and SkyDNS for etcd both provide DNS interfaces that clients can use to retrieve SRV records. NGINX Plus obtains the load‑balancing configuration by querying a service’s DNS interface directly. NGINX Plus regularly re‑checks the service, so any changes are quickly and automatically propagated.

The following example configures NGINX Plus to get the list of upstream servers for my_service via DNS. The service=http parameter to the server directive enables support for DNS SRV records. The application instances backing my_service are now automatically discovered by NGINX Plus.

http { 
    resolver dns-server-ip;
 
    upstream my_service {
        zone backend 64k;
        server hostname-for-my_service service=http resolve;
    }
 
    server {
        # ...
 
        location /my_service {
            # ...
            proxy_pass http://my_service;
        }
    }
}

NGINX Plus App Pricing

Per‑instance pricing is a great way to get started with NGINX Plus, and it provides a very cost‑effective alternative to hardware load balancers, but the potential uses for NGINX Plus go far beyond simple hardware replacement. Its lightweight software architecture makes NGINX Plus ideal for dedicated load balancing of each application, and because NGINX Plus is built on NGINX Open Source, it can replace the web and application servers in your application too. These use cases drive more and more deployments of NGINX Plus for which per‑instance pricing isn’t cost effective or flexible enough.

With NGINX Plus R9 we are introducing a new “all you can eat” App Pricing model that allows you to run as many instances of NGINX Plus as you want for a specific application. Deploy NGINX Plus whenever, wherever, and however you need within your application infrastructure, and across development, testing, staging, disaster recovery, and production environments. No matter how many VMs, containers, or nodes, you pay one fixed rate for the entire year.

Every subscription includes the full features of the NGINX Plus software and our award‑winning support and configuration assistance. In addition, opting for the App Pricing model entitles you to:

Your choice of installation and/or tuning support from NGINX Professional Services
Training for your team in NGINX fundamentals, advanced topics, or both

Use is unlimited on a per‑application basis. An application is defined as the software components and team that support a single web application or individually named desktop or mobile application. Microservices‑based and other distributed architectures are anticipated and embraced within the model.

A Site License subscription is also available, providing unlimited use of NGINX Plus across an entire organization.

Additional Features

NGINX Plus R9 introduces a number of additional improvements, including:

Cache performance improvements – Last year, we introduced a thread‑pool model to improve cache read operations and prevent them from potentially blocking the NGINX core. This delivered a potential 9x performance improvement for certain cache workloads. In this release, NGINX Plus can also offload disk writes for the cache to threads.
DNS lookups over TCP – By default, NGINX Plus uses UDP for DNS lookups. However, when DNS responses are large – when a name resolves to a large number of servers, for example – the complete response might not fit in a single UDP datagram (limited to 512 bytes). An incomplete response is flagged as truncated, and NGINX Plus now immediately retries the request using TCP. This enables NGINX Plus to better support very large, dynamic deployments of servers.
Retrying of non‑idempotent requests – When an HTTP request fails because of an error or timeout, by default NGINX Plus automatically retries it with another server in the upstream group. You can use the proxy_next_upstream directive to define the types of errors for which NGINX Plus repeats requests, including specific 4xx or 5xx response codes.

By convention POST requests are generally not retried because the body data is streamed to the server and cannot be replayed if the server fails. However, under certain failure circumstances earlier versions of NGINX Plus would retry POST requests, inconsistent with the assumption that they are not retried because they are non‑idempotent.

NGINX Plus no longer automatically retries failed non‑idempotent HTTP requests (POST, LOCK, and PATCH). To restore the previous behavior and allow NGINX Plus to retry failed non‑idempotent requests where possible, include the new non_idempotent parameter to the proxy_next_upstream directive.

Upgrade or Try NGINX Plus

If you’re running NGINX Plus, we strongly encourage you to upgrade to Release 9 as soon as possible. You’ll pick up a number of fixes and improvements, and it will help us help you if you need to raise a support ticket.

If you haven’t tried NGINX Plus, we encourage you to check it out for web acceleration, load balancing, and application delivery, or as a fully supported web server with an API for enhanced monitoring and dynamic reconfiguration. Get started today with a free 30‑day trial and see for yourself how NGINX Plus can help you deliver and scale out your applications.