Node Identities
Node Instance Identity
Each physically deployed Node instance has its own individual Node Instance Id.
A Node instance is a physical deployment of a Node application connected to the logical Node registered in the Repository. Multiple physical deployments (multiple physical Node instances) can be connected to (or associated with) the same logical Node in the Repository, which provides Sentinet with capabilities to deploy a cluster of load-balanced Sentinet Nodes (see Load-balanced Sentinet Nodes chapter for more details).
The diagram above shows the example of two Sentinet Node instances, each deployed on its own physical server, where both instances are configured as connected to the same logical Node registered in the Repository. This connection is created when, during Node Configuration, the logical Node from the Repository is associated to the currently configured physical Node instance. When virtual services are configured to be hosted on a logical Node in the Repository, all Node's physical instances automatically and independently retrieve the same services virtualization configuration making all Node instances identical members of a Node "cluster".
Node Instance Id is used to independently monitor the status of each member of the Node cluster. Real-time and historical transactions sent through the Node cluster can also be monitored, reported on, and filtered by a specific member of the cluster. The run-time distinction of Node instances helps analyze performance and other run-time metrics of each cluster member individually.
For single Node instance deployment scenarios, Instance Id is of less practical value, even though it can also help identify and manage a physical instance's redeployment to a new server.
By default, Node Instance Id is auto-generated as a globally unique identifier (GUID) specific to the instance of the currently installed Windows Operating System (OS). This means that all Nodes installed in the same Windows OS will have the same default Instance Id, but the combination of Node Id and Node Instance Id will always be unique. Default Node Instance Id also handles cases where clustered Nodes are auto-deployed in those cloud environments (for example Microsoft Azure cloud) that allow auto-launch of identical Virtual Machines. In this case Node Instance Id is not typically assigned by Sentinet administrators but is rather used with its default value specific to the virtual machine OS instance. The Node Instance Id field can also be left blank in the Node Configuration Wizard, in which case it will also be auto-generated with the same GUID unique to Windows OS instance.
Each physical Node instance reports it status and physical deployment details to the Sentinet Repository, and these can be viewed from the Sentinet Administrative Console.
A Sentinet Node instances have their own individual operational Statuses (see Node State and Node Instance Statuses chapter for more details). Usually Sentinet has no knowledge on whether the Node instance goes into Idle or Error state by intent or by erroneous conditions, therefore it keeps all registered Node instances listed in its Console until Sentinet user removes these Node instances from the Node Instances list (see [x] -- remove button to the right of each Node instance on the screen above). Removed Node instances will reappear in this list if they are still "live" instances that continue to (or resumed) heartbeat and report their Normal state. A Node instance removed from the Administrative Console does not affect the physical instance, it is only removed from the list of monitored instances.
Node Certificate Identity
Every Sentinet Node always has up to two implicit identities---an X.509 certificate and a Windows identity.
An X.509 certificate is assigned to a Sentinet Node when it is configured using the Node Configuration Wizard. The certificate is used to secure communication with the Sentinet Web Services Management application. It is also used as a service certificate for virtual services that require a message-level service-side X.509 certificate. Note that the Node's certificate identity and Node's SSL certificate in general can be different, even though it is typical (and recommended) to use the same certificate for both SSL and message-level security. Also, the Node certificate is used by default as a client certificate when the virtual service needs to communicate with a physical service using a client-side certificate. Each virtual service's outbound endpoint can be assigned its own individual X.509 certificate as a client-side certificate (see the Outbound Endpoints chapter for more details).
Node Windows Identity
A Sentinet Node always runs under a specific Windows account. This is a Windows Account of the IIS Server application pool configured with a Sentinet Node's IIS Server virtual directory. A Sentinet Node Windows Identity is configured as either a Service Principal Name (SPN) or a User Principal Name (UPN), depending on the specific Windows account that the IIS Server application pool is configured with. Administrators can create custom SPN or UPN accounts in the Windows Active Directory and change the Sentinet Node's Windows identity to reflect these Active Directory assignments. As an option, a Sentinet Node can be configured with None for its Windows Principal Name identity, in which case it is expected that the Sentinet Node will not host virtual services requiring Windows Integrated security.
