products: SelfReliant > faqs

Answers about Cluster Management, Fault Tolerance, and other Frequently Asked Questions

The following Frequently Asked Questions (FAQ) answers those queries most asked of our sales and technical team. The FAQ is organized using the following sections:

• Availability and Fault Management
  • How does SelfReliant provide application redundancy?
    SelfReliant allows users to establish hardware or software resource redundancy through the use of service groups. A service group consists of a set of resources that provide the same service. Users add resources to a service group and select the availability policy for that group either programmatically or via the SelfReliant Console.
  • Once established, the service group policy notifies the applications of their role so they appropriately initiate the checkpointing of state information. For example, upon receiving notification of the active role, the application activates and begins to checkpoint state data to the standby; the standby receives its role and begins to receive and maintain state information from the active. Service group policy is responsible for activating the standby application upon failure of the active.
  • Service groups can span a single or multiple nodes and many service groups can exist per SelfReliant cluster. Service groups are represented as managed objects within SelfReliant’s system model and as a result, other managed resources can depend on the health of a service group (health can be determined by the number of active resources within the group)
  • How Does SelfReliant support the online upgrading of applications?
    Managed resources actively providing service can be taken out of service via the SelfReliant Console or a user developed application, such as an upgrade manager. The Availability Manager will automatically initiate switchovers to the appropriate backup resources, allowing the offline resources to be upgraded. The SelfReliant system model and its support for dependency and ‘follow-the-leader’ relationships simplifies this process allowing operations on a single object in the cluster to appropriately affect the state of related resources. Once upgrading is complete, the resources can be brought back online and the user or upgrading application can continue this process on all resources/nodes until the upgrade is complete. Application’s using SelfReliant’s checkpointing services allow this process to occur with minimal to no disruption in service.
  • How do you measure application failover time?
    Application failover time consists of three components: The time to detect failure, the time to identify and activate the standby resource, and the time for the standby application to go active.
  • Failure detection can range from a few milliseconds, where failure is detected through loss of the application connection, to a few hundred milliseconds depending on how frequently heartbeats are configured. The time for the application to activate upon notification is application dependent. The typical requirement from customers is application failover time less than 50ms, which is achievable using SelfReliant’s availability services, assuming the managed application can go active within this amount of time.
• Cluster Management
  • What defines a cluster (cluster per chassis?, cluster per LAN?, etc.) - how is this defined?
    A SelfReliant cluster is a collection of systems (nodes) that are running the SelfReliant Process. A cluster is not limited to a particular hardware topology and can span a set of redundant servers, a single chassis, or multiple chassis. In order to join a group of nodes, each node must be associated with the same cluster. This is a parameter set statically in a SelfReliant configuration file or set dynamically using the SelfReliant console or an API. Typically clusters exist within the same network subnet; however, SelfReliant’s bridged IP functionality includes nodes outside the subnet.
  • How does SelfReliant protect against split-brain conditions?
    The primary defense against a split-brain condition is SelfReliant's support for both redundant network interfaces and redundant networks. Through cluster heartbeating, SelfReliant detects interface or network failure and quickly responds by failing over to the standby interface/network. SelfReliant's Availability Manager also periodically verifies that there are no other managers in the cluster.
  • How does SelfReliant support redundant network interfaces? What scheme is used and is there any requirement needed at the network interface/switch level to support this?
    There are no requirements SelfReliant imposes on the network interfaces or switch except that the active and standby interfaces should be configured as separate physical network segments. SelfReliant's Cluster Management Service identifies network interfaces based on IP subnet information set in the SelfReliant configuration file. The Cluster Manager performs node heartbeating across both network interfaces so it's able to detect the difference between a node/NIC/SWITCH failure. The Standby Manager heartbeats the Active Manager on both interfaces.
  • Does SelfReliant’s messaging service provide a load balancing mechanism?
    SelfReliant's Distributed Messaging Service provides a server pooling mechanism. The server pool is an abstraction that handles client application requests and distributes them among individual member application in the server pool. This can reduce the amount of workload that each application (server) must handle, much like load balancing. SelfReliant supports server pool sizes of up to 64 servers per pool.
  • Client applications have two ways of interacting with a server pool, they can send individual messages into a pool, or they can request a direct connection with a pool server. In either case the client application references the pool by name and the SelfReliant Process makes a policy decision to determine which pool member receives the message or request. The default policy is a simple round-robin scheme but users can provide their own routing policies.
  • Is SelfReliant's inter-node communication based on TCP/IP?
    Yes, SelfReliant's Distributed Messaging Service uses the node’s TCP/IP stack for all inter-node communication. A TCP/IP stack is required for any SelfReliant Development Seat or run-time license.
  • How does SelfReliant provide IP failover?
    SelfReliant's management service provides API functions and settings to manage virtual IP addresses (VIP). The cluster management service includes a default manager virtual IP address policy that instantiates a manager VIP when a node becomes manager, at cluster formation or on switchover/failover. This provides a consistent IP address for management of SelfReliant via the web-based console.
  • The management service also provides cross-platform SelfReliant API functions to add and remove virtual IP addresses from a node. These functions are used by applications to implement custom VIP policies based on custom-defined events.
  • Can a cluster node be added/removed without bringing down the cluster?
    Yes, the SelfReliant Console allows a user to instruct a node to leave and rejoin the current cluster or leave and rejoin a different cluster. Performing this operation on the Manager node will initiate a stateful failover of the Availability
    Management Service.
• Database
  • Is SelfReliant's data store proprietary?
    Yes, GoAhead created an in-memory data store that is fast, robust, and efficient for storing arbitrarily structured management and configuration data. The local data store management provides a variety of application programming interfaces (APIs) to create, write, read, and modify in-memory data stores and their constituent tables, rows, columns and fields.
  • What is the typical usage for SelfReliant's database?
    GoAhead's database is optimized for fast access times and is primarily used for storage of management and configuration data, rather than large amounts of application state data. In developing SelfReliant's database, GoAhead has focused on high performance, resulting in database read times as low as 3 microseconds for retrieval of a 56byte record and 8 microseconds for a 2,064 byte record. In order to adhere to strict performance requirements and avoid unnecessary overhead, GoAhead has not added features common to many other standard database offerings, such as ODBC or
    SQL compliance.
  • How is SelfReliant’s database different than an application state database?
    Typically, application state databases are feature rich, fully relational, and provide support for standard interfaces such as ODBC and JDBC. The GoAhead database has less functionality but is performance optimized for fast read time for access by multiple applications. If the design objective is to aggregate management data from throughout the system to a single management node, an application state database may be the preferred choice. If the design objective is to provide SNMP or web-based access/control to management data for each system node, or to provide local, automated fault management for that node, then GoAhead’s database may be the preferred choice. GoAhead supports either design choice.
• Error Logging
  • What kinds of logging/reporting mechanisms are offered with SelfReliant?
    SelfReliant provides a variety of trace mechanisms to assist in developing and deploying SelfReliant-based solutions. These include: standard trace output, providing visibility into actions taken by components in a SelfReliant system; error output, which records error messages to a specified error file as well as the trace output file; and an OS log, allowing the user to write to the native operating system event log.
  • SelfReliant also provides APIs for outbound reporting mechanisms, including sending a page, email, or SNMP trap in response to custom-defined events.
• Integrating SelfReliant
  • What is the development effort to integrate SelfReliant?
    The development effort can vary depending on the utilization of SelfReliant functionality as well as the desired level of availability. Project teams of 2-3 developers have integrated SelfReliant to provide stateful application failover on their systems in just a few weeks, including training and ramp-up time. More in-depth implementations involving a fully modeled hardware system and stateful failover of applications can take longer, typically on the order of 6-8 months.
  • Can SelfReliant products be phased in?
    SelfReliant provides a flexible framework enabling developers to take advantage of all SelfReliant services or just a subset of the functionality. Often for the first release or demo platform, project teams want to quickly implement basic HA functionality, such as clustering, messaging, and stateless application failover. Later, functionality is added, including more detailed modeling of system dependencies, integration with a network management solution and high-speed stateful failover. Users have the ability to adopt and integrate functionality as needed. SelfReliant’s modular framework enables this approach, allowing users to start simply and expand into a more robust, fault tolerant solution.
  • Does SelfReliant require that application code be modified in order to manage applications?
    No, SelfReliant provides support for management/monitoring of both modified (the SelfReliant library is linked into the application) and unmodified applications. The managed object can be configured with appropriate actions or scripts to react to various managed object state change notifications (such as initialize, go active, switchover, go standby, disable, etc.). SelfReliant provides a variety of mechanisms for monitoring unmodified applications, including the following:
    • Process Existence - This type of health monitoring simply checks the operating system process table for the existence of a process having the command line that was configured for the managed object. If the process is currently executing, the resource is considered healthy. If the process is not executing the process is
      considered failed.
    • Command Line - SelfReliant calls a configured script or application on every heartbeat interval. A non-zero return from the spawned process will indicate failure, and 0 a healthy resource.
    • HTTP GET Request - SelfReliant will send an HTTP GET request to the configured URL. An OK response must be received within the configured timeout period.
    • Port Request - On each heartbeat interval, SelfReliant opens a socket to the target machine and sends a challenge. It then waits for the response and verifies that it matches the configured response, at which point it continues with the second challenge. This method of heartbeating supports up to 10 challenge-response pairs.
  • How does SelfReliant integrate with hardware?
    GoAhead provides the SelfReliant Platform Resource Management Service (PRMS) as part of the SelfReliant Advanced Suite. This service provides the ability to integrate SelfReliant with a hardware platform interface (HPI) that is compliant with the Service Availability Forum (HPI version 1.0 A and B). The PRMS solution enables automatic enumeration of HPI hardware resources, control through standard SelfReliant APIs, and the elimination of platform specific code.
  • PRMS offers the following benefits:
    • Custom Alarm Management - The ability to detect platform sensor or hot swap events and perform application-specific tasks as a result
    • Custom Hot Swap Management - The ability to execute custom tasks associated with adding or removing
      a resource
    • Incorrect Configuration Notification - Immediate notification when hardware resources discovered in the system do not match those provisioned
    • Customization of Resource Management - Simplified customization of certain resource behaviors
    • Standard Hardware Control - Hardware resources controlled through standard SelfReliant APIs
    • Redundant Hardware Control - In the event of a system failure, steps have already been taken to access the vital hardware to complete a task
  • For non-HPI compliant hardware platforms, SelfReliant allows users to configure or programmatically create managed objects to represent hardware resources. This allows the user to configure each resource with appropriate actions or scripts to run in response to the various state changes that a managed object is subject to (such as initialize, go active, switchover, check health, etc.). To do this programmatically, SelfReliant provides a set of Availability Management APIs allowing a user process to create and configure a managed object on behalf of a hardware resource communicating with that process.
  • How does SelfReliant integrate with existing middleware?
    SelfReliant provides resource monitoring services to improve the availability of other middleware components. For enhanced integration, SelfReliant provides a flexible C interface allowing the middleware to make use of additional SelfReliant services, such as the Distributed Messaging Service, In-Memory Database Service, etc.
  • Which hardware platforms are already integrated with SelfReliant?
    Support for the Service Availability Forum HPI specification allows for SelfReliant integration with any HPI v1.0 (A and B specification) compliant hardware platform. GoAhead jointly validated HPI integration with a variety of hardware platform vendors. The program included both CPCI chassis and rack mounted server products from Intel, HP, IBM, Radisys, Performance Technologies and Kontron.
  • Many of GoAhead’s current customers have also integrated SelfReliant with their own proprietary hardware systems, providing similar functionality as well as integration with their applications.
• System Requirements
  • What are SelfReliant's run time memory/disk requirements?
    The run-time license of SelfReliant typically uses 3-4MB of memory and requires about 4MB of disk space. These numbers can vary depending on the amount of additional custom content.
• Performance
  • What is the overhead of running SelfReliant?
    SelfReliant is a compact management middleware designed to provide high performance availability services. GoAhead's goal is to minimize CPU usage of the SelfReliant process as CPU cycles should be reserved for application processing. To ensure this is the case, GoAhead has performed extensive performance testing of the SelfReliant product. In testing, GoAhead has a target not to exceed 5% CPU usage, while actual results are typically measured at less than 0.1%. GoAhead also focuses on minimizing the in-memory foot print of the SelfReliant process. The SelfReliant Advanced Suite currently consumes 4.1MB of memory at run-time. This value will vary depending on the addition of user functionality and data such as in-memory database schema and content.
• Pricing
  • What is SelfReliant's pricing model?
    Licensing of each SelfReliant product is separated into three components: 1) a subscription license to the software including Software Development Kits (SDKs) and different levels of technical support and training, 2) royalties and 3) consulting. During development, the SDKs are used to create a tailored run-time version of SelfReliant for a customer’s platform. GoAhead provides package options to accommodate all types of projects from small teams that require quick development and implementation to large teams working on long-lead, complex systems. The second component, applicable during the Commercial Deployment Phase, is a royalty fee per run-time license shipped by the customer with each platform. For specific pricing information on any of GoAhead’s products, please contact us.

If you have additional questions, please contact us. Or call +1 425 453 1900.