Active-Active Configuration

Introduction

                When you deploy a project in active-active HA mode, two instances of the same project run in the cluster, preferably on separate machines. One version of the project is designated the primary instance, and the other is designated the secondary instance. All connections from outside the cluster (adapters, clients, Studio) are directed to the primary project server. If the primary instance fails, a hot failover occurs and all connections are automatically directed to the secondary instance. Data between primary and secondary instances is continuously synchronized. The primary instance receives each message first. To maintain redundancy, the secondary instance must acknowledge receipt of the message before the primary instance begins processing.

     Setting up the Active-Active project configuration does require you to manually edit the project configuration (“.ccr”) file. While most project configuration tasks can be completed from within the SAP HANA Streaming Development perspective in HANA Studio, this is one case where additional manual steps are required.

Active-Active project configuration is covered in this section of the documentation: Active-Active Deployments – Configuration and Administration Guide – SAP Library

The purpose of this blog post is to provide an example of the required edits to the project configuration file. These edits will include:

  1. Turning on high availability
  2. Defining the Active-Active nodes
  3. Assigning the node affinities to force the 2 project instances to run on separate streaming nodes within the HANA system.

Prerequisites

  • You should have created a HANA Streaming project in HANA Studio
  • The HANA “System” connected to must have at least two SDS nodes already installed

Manual Configuration via CCR file

  1. On your development machine (ie: where you are running HANA Studio), navigate to the workspace directory in which your streaming project was created.
  2. Open the .ccr file with a text editor. The project folder should contain files similar to those shown in the example below.

/wp-content/uploads/2015/06/ccr_730301.png

     3. With the .ccr file open in a text editor, navigate near the bottom to the <Deployment> tag. You should see a structure similar to that shown below.

<Deployment>

<Project ha=”false“>

</Project>

</Deployment>

     4. Change the value of “ha” in the “Project” tag to “true” as shown below.

<Deployment>

<Project ha=”true“>

</Project>

</Deployment>

     5. Now, within the “Deployment” tag, configure two instances as shown below.

<Instances>

<Instance name=”primary”>

<Failover enable=”false”/>

</Instance>

<Instance name=”secondary”>

<Failover enable=”false”/>

</Instance>

</Instances>

                With two instances defined, the active-active configuration is complete. However, without any affinities defined, the two project instances will start on the same node. Affinities make it possible to define which node(s) a project will run on.

Setting Project Affinities

Controller and instance affinities can be set in the CCR file to determine which nodes a project can run on. Affinities limit where a project does or does not run in a cluster. There are two types of affinities:

  • Controller – for active-active and non-active-active configurations. Controller affinities let you establish rules and preferences as to which nodes your project can run on. A project can have affinities for more than one node, but it can have a strong positive affinity for only one node.
  • Instance – only for active-active configurations. The two instances of an active-active project can have affinities for each other. For example, if you want such instances never to run on the same node, set strong negative instance affinities. If you want them to avoid running on the same node if possible, set weak negative instance affinities.

Table 1. Affinity Parameters (source)

Field

Description

Name

The name of the object of the affinity, which is the controller name or instance name that the affinity is set for. For instance affinities, the affinity for one instance must refer to the other instance.

Strength

The strength of the affinity. Valid values are strong or weak. Strong requires the project to run on a specific controller. If you have strong positive affinity set for a node, and the node fails, the failover process tries to restart the project on that node. If the node has not recovered, the project restart fails, and you must restart manually. Weak requires the project to start on the preferred controller if possible, but if that controller is unavailable it may start on another available controller.

Charge

The charge of the affinity. Valid values are positive or negative. If positive, the project runs (for a strong affinity) or prefers to run (for a weak affinity) on the named controller. If negative, the project does not run (or prefers not to run) on the named controller

When failover is enabled for a project, affinities can affect restarts. For example, your project has a strong positive affinity for node A—that is, the project can run only on node A. Node A crashes while your project is running. When your project tries to restart, node A is still unavailable. A project cannot attempt multiple restarts if an appropriate node for the project to run on is unavailable. Due to its strong positive affinity for node A, there is only one appropriate node available, so your project can try to restart only once. You must restart the project manually when node A returns to service or reconfigure the affinities.

Active-Active Example

This example shows the Deployment section of the CCR file for a high availability deployment with failover enabled and affinities configured on both instances of an active-active project:

<Deployment>

  <Project ha=”true“>

  <Options>

        <Option name=”time-granularity” value=”60″/>

        <Option name=”debug-level” value=”6″/>

   </Options>

<Instances>

        <Instance name=”primary”>

          <Failover enable=”false”/>

          <Affinities>

<Affinity type=”controller” charge=”positive” strength=”strong” value=”node1″/>

<Affinity type=”instance” charge=”negative” strength=”strong” value=”secondary”/>

</Affinities>

        </Instance>

        <Instance name=”secondary”>

          <Failover enable=”false”/>

          <Affinities>

<Affinity type=”controller” charge=”positive” strength=”weak” value=”node2″/>

<Affinity type=”instance” charge=”negative” strength=”strong” value=”primary”/>

</Affinities>

        </Instance>

      </Instances>

</Project>

</Deployment>

                You will notice that the controller affinities in each instance differ in strength. As explained in Table 1, a strong positive controller will be designated as the primary node while the weak positive node2 controller remains the secondary node. The strong, negative instances in each affinity ensure that the instances never run on the same node.

Note: the value attribute (“node1” in the first affinity, “node2” in the second) should be the controller name of a node in your cluster. To find this, first navigate to your streaming home directory (cd $STREAMING_HOME). Then, issue the following command:

./bin/streamingclusteradmin –uri=esps://<host>:<port> –get_projects –username=<host-username> –password=<host-password>

Note: the <host-username> and <host-password> should correspond to the SYSTEM user.

You should then be able to view various “Controller Name” rows containing the name of the controllers in your cluster similar to what is shown below.



Workspace:                    default

Project:                      dmm165_sds

Instance Count:               2

    ———– Instance Details ———–

    Instance Name:                primary

Controller Name: dewdflhana2429_emea_global_corp_sap

    Current Status:               started-running

    Requested Status:             started-running

    Failure Interval:             0

    Failures Per Interval:        0

        ————– Affinities ————–

        Affinity Type:                CONTROLLER

        Affinity Charge:              POSITIVE

        Affinity Strength:            STRONG

        Affinity Subject: dewdflhana2429_emea_global_corp_sap

        Affinity Type:                INSTANCE

        Affinity Charge:              NEGATIVE

        Affinity Strength:            STRONG

        Affinity Subject:             1

        Affinity Type:                CONTROLLER

        Affinity Charge:              NEGATIVE

        Affinity Strength:            WEAK

        Affinity Subject: dewdflhana2666_emea_global_corp_sap

    ———– Instance Details ———–

    Instance Name:                secondary

    Controller Name: dewdflhana2666_emea_global_corp_sap

    Current Status:               started-running

    Requested Status:             started-running

    Failure Interval:             0

    Failures Per Interval:        0

        ————– Affinities ————–

        Affinity Type:                CONTROLLER

        Affinity Charge:              POSITIVE

        Affinity Strength:            WEAK

        Affinity Subject: dewdflhana2666_emea_global_corp_sap

        Affinity Type:                INSTANCE

        Affinity Charge:              NEGATIVE

        Affinity Strength:            STRONG

        Affinity Subject:             0

        Affinity Type:                CONTROLLER

        Affinity Charge:              NEGATIVE

        Affinity Strength:            STRONG

        Affinity Subject: dewdflhana2429_emea_global_corp_sap

An example of an affinity using the information above:

<Affinities>

             <Affinity type=”controller” charge=”positive” strength=”strong” value=”dewdflhana2429_emea_global_corp_sap“/>

             <Affinity type=”instance” charge=”negative” strength=”strong” value=”secondary”/>

</Affinities>

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply