After split brain has been detected, one node will always have the resource in a StandAlone connection state. The other might either also be in the StandAlone state (if both nodes detected the split brain simultaneously), or in WFConnection (if the peer tore down the connection before the other node had a chance to detect split brain).

At this point, unless you configured DRBD to automatically recover from split brain, you must manually intervene by selecting one node whose modifications will be discarded (this node is referred to as the split brain victim). This intervention is made with the following commands:

# drbdadm secondary resource 
# drbdadm disconnect resource
# drbdadm -- --discard-my-data connect resource

On the other node (the split brain survivor), if its connection state is also StandAlone, you would enter:

# drbdadm connect resource

You may omit this step if the node is already in the WFConnection state; it will then reconnect automatically.

If all else fails and the machines are still in a split-brain condition then on the secondary (backup) machine issue:

drbdadm invalidate resource

// declare some simple procedures 
proc display(cArg)
    echo "display=" + cArg
endproc

proc show(cArg)
    echo "show=" + cArg
endproc

// create an object based on an anonymous class
myobj = new object()

// add some properties
myobj["name"] = "barry"
myobj["company"] = "recital"

// now declare an anonymous method
myobj["mymethod"] = display

// call the method
myobj.mymethod("hello world")    // displays "display=hello world"

// redeclare the method
myobj["mymethod"] = show

// call the method
myobj.mymethod("hello world")    // displays "show=hello world"

proc processdata(oArg)
    oArg.mymethod(oArg.name)    
endproc

proc show(cArg)
    echo "show=" + cArg
endproc

myobj = new object()
myobj["name"] = "barry"
myobj["mymethod"] = show
processdata(myobj)        // displays "show=barry"

When you start the loadbalancer.org appliance you will see the following:

Default login:
Username: root
Password: loadbalancer

Access to webclient from an external client is:
http://192.168.1.129:9080
http://192.168.1.129:9443

You can access the web administrator using the IP and ports described onscreen.

For the sri lanka porject we are looking for performance and the network diagram indicates we are happy to have the cluster on the same subnet as the rest of the network.

Direct routing is the fasted performance possible, it has the advantage over NAT that the Loadbalancer does not become a bottleneck for incoming and outgoing packets. With DR the loadbalancer simply examines incoming packets and the servers to route the packets directly back to the requesting user.

The web interfaceis the only way to fully configure the loadbalancer vm. The console tool lbwizard will get it initiallised and any further configurations can then be done via the webinterface.

Using lbwizard for the Sri lanka configuration follow these steps.

On the first Loadbalancer:

//Start

Is this unit part for a HA Pair?
YES

Have you already setup the Slave?
NO

Is this a one-armed configuration?
YES

Enter the IP Address for the interface eth0?
Enter IP address you wish to be assigned to the SLAVE loadbalancer.

Enter the netmask for interface eth0?
Enter netmask for the subnet.

Enter the Floating IP adrress?
Enter the IP address that will be IP assosiacted the the HA-pair of loadbalancers.

//Finish

On the 2nd loadbalancer VM, run the lbwizard.

//Start

Is this unit part of an HA-Pair?
YES

Have you already set up the Slave?
YES

What is the slave units UP address?
Enter the IP which you entered when configuring the other loadbalancer VM.

Is this a one-armed configuration?
YES

Enter the IP Address for the interface eth0?
Enter the IP that will be assigned to the MASTER loadbalancer

Enter the netmask for interface eth0?
Enter the subnet netmask.

Enter the Floating IP address?
Enter the IP address that will be IP assosiacted the the HA-pair of loadbalancers.

Enter the address of the default gateway?
Enter the deafult gateway for the subnet.

Enter the IP of the nameserver?
Enter the dns server.

Enter the port for the first Virtual server?
Enter 22 for ssh

Enter the IP address of the first real server?
Enter the real IP of the first appserver

//Finish

Now this is complete we need to go to the web admin interface to configure the 2nd Real Server. As the lbwizard program will only allow you to configure 1 real server.

Now login to the web admin using the default password:

username: loadbalancer
password: loadbalancer

Note: Connect to the IP you have now set for your master loadbalancer

Goto the edit configuration tab

Now click add a real server:

Enter a label
IP address of the server plus the port of the service i.e. 192.168.1.125:22


Edit Configuration -> Virtual Servers

persistancte -> NO

Scheduler-> LC
LC - Least-Connection: assign more jobs to real servers with
fewer active jobs.

Service to check -> custom1

Check port -> 22

Forwarding Method -> DR

Feedback Method -> Agent

Arp Problem when using DR

Every real server must be configured to respond to the VIP address as well as the RIP
address.

You can use iptables (netfilter) on the real server to re-direct incoming packets destined for the virtual
server IP address.

This is a simple case of adding the following command to your start up script (rc.local):

//replace 10.0.0.21 with the Virtual Server IP
iptables -t nat -A PREROUTING -p tcp -d 10.0.0.21 -j REDIRECT

chkconfig iptables on

In this article Barry Mavin, CEO and Chief Software Architect for Recital provides details on how the Recital Database Server can be used to provide a solution for Universal Data Integration.

Overview

The Recital Database Server handles universal cross-platform data access to a wide range of data sources. The database server natively handles full remote SQL data access to Recital, Visual FoxPro, FoxPro, FoxBASE, Clipper and older dBase data. Using Bridges, it handles full remote SQL data access to C-ISAM and OpenVMS RMS. Using gateway connections, it handles full remote SQL data access to Oracle, MySQL, PostgreSQL, SQL Server, server-side ODBC, server-side JDBC and server-side OLE DB data sources. With its ability to access data using server-side ODBC, JDBC and OLE DB drivers from clients on all supported operating systems (Windows, Linux, Unix, OpenVMS), the Recital Database Server is an ideal Data Integration Solution for applications of all sizes and complexity.

Universal Data Integration Solutions

There are several ways in which data may be accessed by the Database Server.

Table 1:

Client Universal Data Access solutions for accessing local or remote data.

Table 2:

Windows Server Universal Data Access solutions accessible from any remote client running on Windows, Linux, Unix or OpenVMS:

Table 3:

Linux and Unix Server Universal Data Access solutions accessible from any remote client running on Windows, Linux, Unix or OpenVMS:

Table 4:

OpenVMS Server Universal Data Access solutions accessible from any remote client running on Windows, Linux, Unix or OpenVMS:

Supported Data Sources

Native Data Access

The Recital Database Server has native built-in support for the following data sources:

• Recital
• Visual FoxPro
• FoxPro
• FoxBASE
• Clipper
• dBase

You can setup tables to work with using the Database Administration Tool in Recital Enterprise Studio.

Bridges

Using Bridges, you can access the following data sources as if they were standard Recital/FoxPro tables:

• CISAM
• OpenVMS RMS

You can setup bridges using the Database Administration Tool in Recital Enterprise Studio.

Gateways/Connections

Using Gateways, you can transparently access the following local or remote data sources:

• Recital
• Oracle
• ODBC (Server-side ODBC data sources)
• JDBC (Server-side JDBC data sources)
• OLEDB Use this to connect to SQL Server and other Windows OLE DB data sources)
• MySQL
• PostgreSQL

Remote Data Object functions

Recital 10 includes a complete and robust set of data source independent functions for accession MySQL, Oracle, DB2 and Postgres. This article explains how to use them.

Client Data Access drivers

Included with the Recital Database Server are three Client drivers. These Client drivers can access any data sources supported by the Recital Database Server. They are not restricted to accessing only Recital data. They can be used to access server-side ODBC, JDBC and OLE DB data sources also.

Recital Universal .NET Data Provider

Use this client driver when building .NET applications with Visual Studio .NET. A data provider in the .NET Framework serves as a bridge between an application and a data source. A data provider is used to retrieve data from a data source and to reconcile changes to that data back to the data source.

Key features of the Recital Universal .NET Data Provider:

• Fully Internet enabled
  The Recital Universal .NET Data Provider works across the internet providing access to a wide range of data sources located on remote servers running Windows, Linux, Unix and OpenVMS.
• SQL Server compatible
  The Recital Universal .NET Data Provider is plug compatible with the .NET Framework SQL Server Data Provider.
• Cross-platform Data Integration
  Using the Recital Universal .NET Data Provider, you can connect to remote Windows, Linux, Unix or OpenVMS servers and access any data source supported by the Recital Database Server.
• Managed code
  The Recital Universal .NET Data Adaptor written in C# is 100% .NET Framework managed code.
• Runs on Windows Mobile
  The Recital Universal .NET Data Adaptor runs under the .NET Compact Framework on Windows Mobile.

Recital Universal JDBC Driver

The JDBC API is the industry standard for database-independent connectivity between the Java programming language and a wide range of databases. The JDBC API provides a call-level API for SQL-based database access. JDBC technology allows you to use the Java programming language to exploit "Write Once, Run Anywhere" capabilities for applications that require access to enterprise data.

Key features of the Recital Universal JDBC Driver:

• Fully Internet enabled
  The Recital Universal JDBC driver works across the internet providing access to a wide range of data sources located on remote servers running Windows, Linux, Unix and OpenVMS.
• JDBC 3.0 API
  The Recital Universal JDBC driver supports the JDBC 3.0 API.
• Pure Java Type 3 Driver
  The Recital Universal JDBC driver is a 100% pure Java Type 3 driver.
• Full Access to Metadata
  The JDBC API provides metadata access that enables the development of sophisticated applications that need to understand the underlying facilities and capabilities of a specific database connection.
• Cross-platform Data Integration
  Using the Recital Universal JDBC driver, you can connect to remote Windows, Linux, Unix or OpenVMS servers and access any data source supported by the Recital Database Server.
• No Installation
  A pure JDBC technology-based driver does not require special installation; it is automatically downloaded as part of the applet that makes the JDBC calls. The Recital Universal JDBC Driver is 100% java.

Recital Universal ODBC Driver

Connect to remote data from Microsoft Office or other applications that support ODBC data access. The Recital Universal ODBC Driver is also available for Linux and Unix.

Key features of the Recital Universal ODBC Driver:

• Fully Internet enabled
  The Recital Universal ODBC driver works across the internet providing access to a wide range of data sources located on remote servers running Windows, Linux, Unix and OpenVMS.
• Works with Crystal Reports
  The Recital Universal ODBC driver supports the SQL syntax generated by Crystal Reports.
• Works with Microsoft Office
  The Recital Universal ODBC driver works with Microsoft Office products.
• Works with PHP on Linux
  The Recital Universal ODBC driver is available for Linux and works with PHP.