Apache Ignite.NET Documentation

The Apache Ignite .NET Developer Hub

Welcome to the Apache Ignite .NET developer hub. You'll find comprehensive guides and documentation to help you start working with Apache Ignite.NET as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Service Grid

Cluster-enable any service or data structure.

Overview

Service Grid allows for deployments of arbitrary user-defined services on the cluster. You can implement and deploy any service, such as custom counters, ID generators, hierarchical maps, etc.

Ignite allows you to control how many instances of your service should be deployed on each cluster node and will automatically ensure proper deployment and fault tolerance of all the services .

Features

  • Continuous availability of deployed services regardless of topology changes or crashes.
  • Automatically deploy any number of distributed service instances in the cluster.
  • Automatically deploy singletons, including cluster-singleton, node-singleton, or key-affinity-singleton.
  • Automatically deploy distributed services on node start-up by specifying them in the configuration.
  • Get information about service deployment topology within the cluster.
  • Create service proxy for accessing remotely deployed distributed services.

Please refer to Service Example for information on service deployment and accessing service API.

IServices

All service grid functionality is available via IServices interface.

Ignite ignite = Ignition.Start();

// Get services instance spanning all nodes in the cluster.
IServices svcs = ignite.GetServices();

You can also limit the scope of service deployment to a Cluster Group. In this case, services will only span the nodes within the cluster group.

Ignite ignite = Ignition.Start();

// Limit service deployment only to remote nodes (exclude the local node).
IServices services = ignite.GetCluster().ForRemotes().GetServices();

Load Balancing

In all cases, other than singleton service deployment, Ignite will automatically make sure that about an equal number of services are deployed on each node within the cluster. Whenever cluster topology changes, Ignite will re-evaluate service deployments and may re-deploy an already deployed service on another node for better load balancing.

Fault Tolerance

Ignite always guarantees that services are continuously available, and are deployed according to the specified configuration, regardless of any topology changes or node crashes.

Deployment Management

By default, an Ignite Service will be deployed on a random node (or nodes) depending on the cluster workload as it's described in the load balancing section above.

In addition to this default approach, Ignite provides an API that allows limiting an Ignite Service deployment to a specific set of nodes. There are several approaches to do that and all of them are covered below.

Node Filter Based Deployment

This approach is based on a filtering predicate that gets called on every node at the time Ignite Service engine determines a set of possible candidates for the Ignite Service deployment. If the predicate returns true then a node will be included in the set or it will be excluded otherwise.

A node filter has to implement IClusterNodeFilter interface (see below) which will instruct the Service Grid engine to deploy an Ignite Service on non client nodes that have west.coast.attribute in their local attributes map.

public class ServiceFilter : IClusterNodeFilter 
{
  public bool Invoke(IClusterNode node)
  {
  	// The service will be deployed on non client nodes
    // that have the attribute 'west.coast.node'.
    return !node.IsClient && node.GetAttributes().ContainsKey("west.coast.node");
  }
}

After the filter is ready you can pass it to ServiceConfiguration.NodeFilter property and start the service using this configuration.

// Initiating cache configuration. 
var cfg = new ServiceConfiguration
{
  Service = service,
  Name = "serviceName",
  NodeFilter = new ServiceFilter()
};

// Getting instance of Ignite Service Grid.
var services = ignite.GetServices();
        
// Deploying the service.
services.Deploy(cfg);

Make sure that a node filter's assembly is loaded on every Ignite node regardless of the fact whether an Ignite Service is going to be deployed there or not.

On the other hand, service implementation assembly should be present only on nodes where the service is going to be deployed.

Cluster Group Based Deployment

One more approach is based on the definition of a specific IClusterGroup. Once a reference to Ignite Service Grid is obtained for a specific cluster group the deployment of a new Ignite Service will happen on one or a number of the nodes from that group only.

// A service will be deployed on the remote nodes only.
IServices services = ignite.GetCluster().ForRemotes().GetServices()

// Deploying the service.
services.deploy(serviceCfg);            

Affinity Key Based Deployment

Affinity approach allows co-locating the service with data based on a cache key. The service's configuration has to contain a value for the affinity key as well as a cache name to which this key belongs and during the service startup Ignite Service Grid will deploy the service on a node that is primary for the given key. If the primary node changes throughout the time then the service will be re-deployed automatically as well.

// Initiating cache configuration.
var cfg = new ServiceConfiguration()
{
  Service = service,
  Name = "serviceName",
  CacheName = "orgCache",
  AffinityKey = 123
};

// Getting instance of Ignite Service Grid.
var services = ignite.GetServices();
        
// Deploying the service.
services.Deploy(cfg);

After the service is deployed using the configuration from the example above, Ignite will make sure to deploy the service on a node that is primary for key 123 stored in cache named orgCache.

Service Grid


Cluster-enable any service or data structure.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.