JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Cluster Data Services Developer's Guide     Oracle Solaris Cluster
search filter icon
search icon

Document Information

Preface

1.  Overview of Resource Management

2.  Developing a Data Service

3.  Resource Management API Reference

4.  Modifying a Resource Type

5.  Sample Data Service

6.  Data Service Development Library

7.  Designing Resource Types

8.  Sample DSDL Resource Type Implementation

9.  Solaris Cluster Agent Builder

10.  Generic Data Service

11.  DSDL API Functions

12.  Cluster Reconfiguration Notification Protocol

A.  Sample Data Service Code Listings

B.  DSDL Sample Resource Type Code Listings

C.  Requirements for Non-Cluster Aware Applications

Multihosted Data

Using Symbolic Links for Multihosted Data Placement

Host Names

Multihomed Hosts

Binding to INADDR_ANY as Opposed to Binding to Specific IP Addresses

Client Retry

D.  Document Type Definitions for the CRNP

E.  CrnpClient.java Application

Index

Binding to INADDR_ANY as Opposed to Binding to Specific IP Addresses

Even when non-multihomed hosts are used, the Oracle Solaris Cluster logical network address concept enables the machine to have more than one IP address. The machine has one IP address for its own physical host, and additional IP addresses for each network address (logical host name or shared address) resource that it currently masters. When a machine becomes the master of a network address resource, it dynamically acquires additional IP addresses. When it gives up mastery of a network address resource, it dynamically relinquishes IP addresses.

Some data services cannot work correctly in an Oracle Solaris Cluster environment if they bind to INADDR_ANY. For example, if an application needs to use the logical address as the source for outbound traffic, the deprecated flag set by the network address resource will prevent this if the application calls bind(3SOCKET) with INADDR_ANY as the address. For such an application to work properly in a clustered environment, it must be able to be configured to explicitly bind(3SOCKET) to the logical address, which overrides the deprecated flag when the source address for outbound traffic is selected. The application must implement this feature, because the cluster framework cannot alter application behavior.

When the application resource and the network address resource reside in different resource groups, the Resource_dependencies property lets you ensure a specific set of network address resources are available when the application resource eventually calls bind(3SOCKET). When the application resource declares a dependency upon the network address resource, Oracle Solaris Cluster starts the network address before starting the application, so that the application that is binding to the network address will not fail to find it. The resource dependency also ensures that when the resource group is going offline, the application is stopped before stopping the network address.

Without a resource dependency declared, the order in which the application and network address resources are started or stopped is non-deterministic.

Network address resource types include SUNW.LogicalHostname and SUNW.SharedAddress.

To force the application resource group and the network address resource group to always start on the same node, declare a strong positive affinity with delegated failover (a +++ affinity) of the application resource group upon the network address resource group. For more information, see the RG_affinities section in the rg_properties(5) man page.

If the application resource and the network address resource are configured in the same resource group, then it is usually not necessary to declare an explicit resource dependency. By default there will be an implicit resource dependency of the application upon the network address. For more information, see the Implicit_network_dependencies section in the rg_properties(5) man page.