Skip to main content Skip to search
Carl Levine
Posted by
Carl Levine on
November 15, 2016

Testing New Infrastructure Using the Filter Chain

Whether your aim is to replace an existing server or to bolster your infrastructure with additional resources, this article explains how using NS1’s Filter Chain can make that transition as seamless as possible.

Testing A New Endpoint In Production

In this example, the Filter Chain will be used to begin running a new address in an endpoint. To ensure that the new address won’t have a significant impact should something go wrong, we want the existing address to serve 99% of the time.

Please note that these instructions are the bare minimum needed to achieve the desired result - your use case may require additional filters if you’re doing any sort of uptime monitoring or advanced logic.
  1. Edit the Metadata field for the existing address. Select “Answer weight” and enter 99 for the static value
  2. Add the new address to an existing record in the NS1 Portal or via the API. Edit the Metadata field for the new address. Select “Answer Weight” and enter 1 for the static value.
  3. Add Filter Chain. To randomly select certain requests to go to the new infrastructure and send the rest to the existing, use WEIGHTED_SHUFFLE.
  4. Add the SELECT_FIRST_N filter, and set the static value to 1 - that way one answer is returned, instead of all of the eligible answers.
  5. Save Changes

Now, 99% of incoming requests for the endpoint are being sent to the existing server, and 1% are going to the new one. As confidence in the new address is gained through any manner of experiential testing, you can adjust the weight of the addresses appropriately.

If you’re replacing the existing address, eventually you may choose to eliminate the Filter Chain altogether and just run the single new address. However, in this age of increased redundancy, it may behoove you to run multiples.

Adjust the metadata field as you see fit to achieve the desired results.

What If I Want Users To Stick With The Same Server?

If your application has sessions that would be disrupted if your users were shunted to another server, the aforementioned procedure typically would not work so well from an experience standpoint. The good news is that we offer another kind of filter called WEIGHTED_STICKY. What this does is actually looks at the entire DNS transaction, understands IP address that the request is coming from and retains the same answer. WEIGHTED_STICKY combines the best parts of our WEIGHTED_SHUFFLE and STICKY filters to ensure that a consistent end-user experience is maintained.

For a list and description of all available Filter Chain types, see this page.