Network Model ​

This document covers the concept of network models and goes in depth into the different types that we offer and how they work / can be configured.

The overall purpose of the network model is to know how many servers there are in the grid and how those servers will be interconnected. However, it is important to know that no matter what network model you actually use, the actual configuration file for the network model should have no mention of the actual TSF instances and where they lie in the network model. It only serves to show the structure of the Network Model, which gets filled only as your TSF instances come up and add themselves during the grid initialization process. In other words, the parameter "numOfInstances" (which each network model type has), is the number of instances that the grid will need to start up the grid. It is essentially the target number of instances needed before actually starting up the TSF grid.

We offer 3 types of Network Models, a Ring Network Model, an Enterprise Ring Network Model, and a Custom Network Model. Every Network Model has a parameter that tells the TSF how many servers (TSF Instances) there are in the grid. Depending on the specific network model, there could be additional parameters.

Ring Network Model ​

An example of what a Ring Network Model configuration would look like is the following:

{
  "numOfInstances": 60,
  "numInstancesPerRing": 5
 }

Below are the parameters that the Ring Network Model can be configured with:

numOfInstances ​

Number of instances needed to start up the grid initially.

numInstancesPerRing ​

Number of servers in a single "Ring" (where every server in a Ring is connected directly to all other servers in that "Ring" as well as to 2 or 3 servers in other "Rings")

Enterprise Ring Network Model ​

The Enterprise Ring Network Model is a special type of Ring Network Model -- it is a more sophisticated version that can be used to minimize costs when servers in your grid are in more than one Data Center or more than one Region. If all TSF servers in the grid are in the same Region and Data Center, this model is essentially reduces to a RingNetworkModel. An example of what an Enterprise Ring Network Model configuration would look like is the following:

{
  "numOfInstances": 60,
  "numInstancesPerRing": 5,
  "regions": [
    {
      "name": "Northeast_USA",
      "latitudeDeg": 41.0,
      "longitudeDeg": -74.0,
      "dataCenters": [
        {
          "name": "NYC"
        },
        {
          "name": "Philadelphia"
        },
        {
          "name": "Newark"
        }
      ]
    },
    {
      "name": "Ohio",
      "latitudeDeg": 40.0,
      "longitudeDeg": -82.0,
      "dataCenters": [
        {
          "name": "Ohio_1"
        },
        {
          "name": "Ohio_2"
        },
        {
          "name": "Ohio_3"
        }
      ]
    },
    {
      "name": "England",
      "latitudeDeg": 51.0,
      "longitudeDeg": 0.0,
      "dataCenters": [
        {
          "name": "London_1"
        },
        {
          "name": "London_2"
        },
        {
          "name": "Manchester"
        }
      ]
    }
  ],
  "regionToRegionOverrides": [
    {
      "region1": "Ohio",
      "region2": "England",
      "override": {
        "overrideType": "ADDITIVE",
        "override": 100
      }
    }
  ],
  "instanceToInstanceOverrides": [
    {
      "instance1": 10,
      "instance2": 20,
      "override": {
        "overrideType": "FULL",
        "override": 60
      }
    }
  ]
 }

Below are the parameters that the Enterprise Ring Network Model can be configured with:

numOfInstances ​

Number of instances needed to start up the grid initially.

numInstancesPerRing ​

Number of servers in a single "Ring" (where every server in a Ring is connected directly to all other servers in that "Ring" as well as to 2 or 3 servers in other "Rings")

regions ​

Defines the regions that will be in the EnterpriseRingNetworkModel. Notice how in the configuration for each region (in the example above, there are 3 -- Northeast_USA, Ohio, England), there is NO mention of what instances are in what regions. As shown below, when each TSF instance starts, it will provide what region and data center it is in. This parameter is essentially a list of regions, where each region provides its name, latitude and longitutde coordinates, and a list of data centers that are a part of that region. Each data center just has a field for its name (since this configuration file is just a skeleton of where instances will be in the network model).

override ​

Before going into the last 2 parameters, there is a concept of override that is important to talk about that both parameters use. It has the following sub-properties:

overrideType

The type of override to apply. The options and their descriptions are the following:

• ADDITIVE
  • Adds the value provided in override to the weight of the connections.
• MULTIPLICATIVE
  • Multiplies the value provided in override to the weight of connections.
• PCT_SCALING_FACTOR
  • Same as MULTIPLICATIVE but allows for factoring the weight by a factor of less than 1, since the override sub-parameter is always a positive integer. Eg. Doing this kind of override with the value 40 means multiplying the weight of the connections by 40 percent.
• FULL
  • Completely overrides the weight of connections with the value provided in override.

override

• The actual factor of how much to scale the weight of the connections.

Ex.

{
  "overrideType": "MULTIPLICATIVE",
  "override": 3
}

regionToRegionOverrides ​

This parameter configures manipulating the weight of connections across two different regions. You just supply both regions along with the override (explained above), and any connections between those two regions will have this override in effect.

instanceToInstanceOverrides ​

This parameter is similar to regionToRegionOverrides, except that it is between 2 instances instead of regions. The connection between those two instances will have this override in effect.

Custom Network Model ​

If the concept of "Rings" does not suite the needs of your TSF grid, we provide a Custom Network Model, which offers complete control of which servers are connected to each other in the TSF grid.

An example of what a Custom Network Model configuration would look like is the following:

CustomNetworkModel.json

{
 "numOfInstances": 5
}

For the CustomNetworkModel, the only thing provided is the number of TSF instances that will be in the grid, since the actual connections are all configured by each instance individually and will be sent in by each TSF instance when they start up.

Configuring TSF Instances in a Network Model ​

A common question at this point may be how each TSF instance is actually configured in the grid, since we mentioned that the above configurations do not have any information regarding the actual instances and how / where they are actually configured. For each of the types of network models, the configuration file is just a skeleton that describes the overall structure of where TSF instances are to be added and how many instances are expected -- so where does this information come from? It is provided by each TSF instance when they add themselves at runtime. More about how this looks like within the TSF Server configuration file is described in the below section. For full details on the TSF Server configuration not limited to Network Models, click here.

Adding TSF Instance to Ring Network Model ​

When adding a TSF instance to the Ring Network Model, there is nothing extra that is needed to be provided in the TSF Server configuration file. In the Ring Network Model, the only thing configurable is the number of instances and the number of instances per ring -- Since there is no special meaning of certain TSF instances being in certain rings, this is not configurable, meaning nothing needs to be passed in from each instance. When each TSF instance starts, it will be added to the Ring Network Model in the next available ring (or start a new one if full).

Adding TSF Instance to Enterprise Ring Network Model ​

When adding a TSF instance to the Enterprise Ring Network Model, the parameters that must be provided in the TSF Server configuration file are region and dataCenter. In this case, where certain TSF instances are does have special meaning unlike the Ring Network Model, so the region and data center in which that particular TSF instance is to be added is important. The region and data center provided by the TSF instance must be a valid region and data center that is present in the Enterprise Ring Network Model configuration file (if not, that TSF instance will be rejected from the grid when it starts up). If you wish to add a TSF instance in a new data center and/or region that is not in the current network model, the data center / region should be added by the user through the Management Console first, before adding the TSF instance.

In the example below, TSF instance 10 may be configured to use the default parameters, and is externally passed this override configuration file that gives its specific details, like what region and data center it will be in the network model, something that is not shared among all TSF instances in the grid.

{
  "region": "Northeast_USA",
  "dataCenter": "NYC"
 }

Getting these from all of the TSF instances in the grid when they start up is how we know what instances are running within each region and data center in the Network Model.

Adding TSF Instance to Custom Network Model ​

When adding a TSF instance to the Custom Network Model, the parameter that must be provided is edges. This parameter lists out all of the connections that this particular TSF instance has with other TSF instances in the grid along with their weight. This allows complete control in laying out how your servers are interconnected in the TSF as well as which connections should be favored over others to minimize costs for your specific needs -- since it will choose the path with the cheapest cost, even if it means more hops between TSF instances.

In the example below, we list out all of the connections that instance 10 has in the grid. Let's say that a request came to instance 10 and it needed to send it to instance 60. Even though instance 10 and instance 60 are directly connected, the connection has a large weight of 1000, meaning that this connection will be much less favorable. Our algorithm will try and find the cheapest possible path using its other cheaper direct connections, and only use the direct connection from 10 to 60 if no other alternative paths exist.

{
   "edges": [
      {
        "connection": 4,
        "weight": 1
      },
      {
        "connection": 15,
        "weight": 5
      },
      {
        "connection": 60,
        "weight": 1000
      },
      {
        "connection": 23,
        "weight": 1
      },
   ]
  }

<-Go back