If you require a large footprint, you typically use multiple unique hostnames to serve your content to distribute access. Unfortunately, this scenario doesn't work well with Edge IP Binding. To help with this, we offer Hash Serial and Forward for Edge IP Binding.

🚧
This feature is only available for zero-rated billing environments.

The problem

Typically in a large footprint scenario, your multiple unique hostnames are targeting different serials in a specific edge region—your hostnames map to different edge hostnames, and then to different serials on the edge. This offers much better cache efficiency because the content can be distributed evenly across the region. However, if you want to use Edge IP Binding, you have to create this same number of Anycast hostnames (or that many unique sets of IP addresses). The systems in the Edge IP Binding network use the serial stated in a specific Anycast configuration file to forward the request to the edge. So, an Edge IP Binding network IP address is actually a scarce resource.

The solution

To help with the lack of Edge IP Binding network IP addresses, Akamai you can incorporate Hash Serial and Forward, which lets you use in-region load balancing. The edge server hashes a serial number from the incoming request URL and uses it to forward the request to a peer in the same region, using back-end connections. This can help to:

Reduce traffic to the origin server.
Avoid duplication of content that is large and infrequently requested.

Get Hash Serial and Forward for Edge IP Binding

To get it you to do the following:

You need to have Edge IP Binding enabled in your environment.
You need to work with your Akamai account representative. Hash Serial and Forward for Edge IP Binding is added as a behavior to the Property Manager property you're using to distribute your content. This behavior can only be added and configured internally by your account representative.

Implementation

Set up of Hash Serial and Forward varies, based on whether or not you "shard" your hostnames. Sharding partitions a database to separate very large ones into smaller, faster, more easily managed parts called data "shards." When working with your account representative to set up Hash Serial and Forward, you need to communicate whether or not you shard your database of hostnames used to access your content.

Sharding is used

If you already have a property configured that shards your hostnames, and you have a large footprint, the process to add and configure Hash Serial and Forward follows a specific workflow:

You work with your Akamai account representative to add an "Advanced" behavior to your Property Manager property. This behavior extracts the serials to be used, into a variable value.
Your account representative adds the HSAF for Edge IP Binding behavior to the same property and applies the required settings.

The settings

Once your account rep has configured Hash Serial and Forward, the behavior is shown in your property in Property Manager similar to what's shown above. The behavior is locked and can't be edited. (Notice the icon.) Along with setting Enable HSAF to On to enable it, the options in this behavior are as follows:

Custom Extracted Serial. This is set to Yes to indicate that the serials are to be pulled from the variable value set in the "Advanced" behavior that your account rep added to your property.
HSAF Tier. This is set to one of two options:
- Edge. With this setting, Hash Serial and Forward is applied at edge regions only. The content is bucketed into approximately 200 serials by Hash Serial and Forward and the whole region is used for caching the "long tail" portion of the distribution, regardless of which machine receives the request. An edge server that has cache misses as Hash Serial and Forward targets goes forward on the newly calculated serial, spreading content in cache parent regions.
- Parent. This is a more complex setup and only applies to selected environments. On one tier, the Akamai edge uses Hash Serial and Forward to bucket the content into about 200 buckets. On a second tier, the incoming request has another Hash Serial and Forward applied, spreading into another set of 200 serials that don’t overlap the initial set. This divides content into 40,000 buckets that provide a much greater chance of going to a machine that has the object in cache. Usually, this is combined with two-tier cacheh. Maps are made that have two main regions, plus one overflow region. When making the first cacheh hop, mapping returns addresses in the first region, and then in the second region in a second hop. The edge randomly decides tier order when making the first hop, so that traffic is divided evenly between the two regions. This has the benefit of allowing maintenance on a full region, or moving regions in and out of the maps. Without this, a new region receives 100% of the traffic and initially, it would be all misses and could overload the origin. This way, only half the traffic goes to the first region, and content is pulled from the other region before going to the origin.

Sharding isn't used

This typically applies if you're a new customer, and you have a large footprint that can be assisted by implementing Hash Serial and Forward.

You work with your account representative to finalize the range of serial values to be used for Hash Serial and Forward. For best results, the total number of serials should be a prime number.
Your account representative adds the HSAF for Edge IP Binding behavior to an existing or new Property Manager property and applies the necessary settings.

The settings

Custom Extracted Serial. Your account rep sets this to No because you need a specific range of serials.
HSAF Hash Min Value and HSAF Hash Max Value. This is the range of serials you worked with your account rep to determine. In the example above, the range set results in the recommended prime number total of serials (100 - 499 account for 400, and 500 adds one, for a total of 401).
HSAF Tier. This is set to one of two options:
- Edge. With this setting, Hash Serial and Forward is applied at edge regions only. The content is bucketed into approximately 200 serials by Hash Serial and Forward and the whole region is used for caching the "long tail" portion of the distribution, regardless of which machine receives the request. An edge server that has cache misses as Hash Serial and Forward targets go forward on the newly calculated serial, spreading content in cache parent regions.
- Parent. This is a more complex setup and only applies to selected environments. On one tier, the edge uses Hash Serial and Forward to bucket the content into about 200 buckets. On a second tier, the incoming request has another Hash Serial and Forward applied, spreading into another set of 200 serials that don’t overlap the initial set. This divides content into 40,000 buckets that provide a much greater chance of going to a machine that has the object in cache. Usually, this is combined with two-tier cacheh. Maps are made that have two main regions, plus one overflow region. When making the first cacheh hop, mapping returns addresses in the first region, and then in the second region in a second hop. The edge randomly decides tier order when making the first hop, so that traffic is divided evenly between the two regions. This has the benefit of allowing maintenance on a full region, or moving regions in and out of the maps. Without this, a new region receives 100% of the traffic and initially, it would be all misses and could overload the origin. This way, only half the traffic goes to the first region, and content is pulled from the other region before going to the origin.