RESULTADOS

The IBM Informix Dynamic Server High Availability Data Replication (HDR), Remote Standalone Secondary (RSS), Shared Disk Secondary (SDS), and Continuous Log Restore (CLR) solutions work in a homogeneous environment. That means each of the computers that are running the database server in a replication environment must be from the identical vendor, and have the identical architecture and operating system. In addition, in a high availability cluster, database servers are usually in different geographical locations, so the system must support networking in order to replicate the database changes.

Unlike HDR, Enterprise Replication (ER) works in both homogeneous and heterogeneous environments. That means each of the computers running Enterprise Replication servers can be on same or different hardware architectures and operating systems. In addition, when using ER, you can replicate the data between different versions of IDS. For example, you could replicate the data from IDS 11 (32-bit) on Linux® to IDS 10 on Solaris™ (64-bit), and vice versa.

2.1.1 Data storage

HDR Secondary, RSS, and CLR servers maintain a complete copy of the databases on their own physical disks. Maintaining the complete copy of the databases increases the data availability, and provides hot backup in case of unplanned outages and disaster recovery scenarios.

The amount of disk space allocated to dbspaces for the primary and secondary database servers must be equal. In addition to having the identical disk space requirements, the path to the dbspaces should also be identical on the primary and secondary servers. The type of disk space is irrelevant; you can use any mixture of raw or cooked spaces on the two database servers.

Figure 2-1 on page 25 shows an example of the primary, RSS, HDR secondary, and CLR backup servers. Each of the servers maintain their own physical disks. In the case of Enterprise Replication (ER), each of the participating database servers is an independent IDS instance. ER is not an instance-wide replication, so it does not require the disk space or path to be identical across the

participating database servers. The disk space requirement for each of the IDS instances will depend on that database server usage and other business needs.

Figure 2-1 Local physical disks

Unlike HDR Secondary and RSS, the SDS server does not maintain a copy of the physical database; rather, it shares the disks with the primary server. So, the requirement for the SDS server is to have reliable shared disks.

SDS servers provide increased availability and scalability without the need to maintain multiple copies of the database, which can lower the data storage costs. Except for the disk requirements, the hardware and software requirements for the SDS server are same as for the HDR secondary server. In addition, the primary server disks must be shared across the computers that are hosting the SDS servers. This means that the path to the dbspace from the SDS server is the same dbspace path as the primary server.

Once shared disk file system is configured, verify that computers participating in the high availability cluster can read from and write to the same disks.

Primary

Continuous Log Restore HDR Secondary

Figure 2-2 shows an example of a Shared Disk subsystem with a single primary and two SDS servers.

Figure 2-2 Shared disks

There are several shared disk file systems availablein the market, which guarantee the concurrent use by different systems in a high availability cluster. For example, the IBM General Parallel File System™ (GPFS™) is a high performance shared disk file system that can provide fast, reliable data access from all servers on AIX® and Linux clusters.

For more details on the IBM General Parallel File System (GPFS), refer to:

http://www-03.ibm.com/systems/clusters/software/gpfs.html

Similarly, other shared disk technologies such as Veritas Storage Foundation Cluster File System, Redundant Array of Independent Disks (RAID) and Storage Area Network (SAN), can also be used to set up an SDS cluster.

2.1.2 Network communication

The database servers involved in high availability and Enterprise Replication solutions are usually deployed in different geographical locations. ER and HDR are both log based replication technologies in which database updates are logged in logical logs, also called the redo logs, and are transferred from the

Note: The use of a mounted Network File System (NFS) is not recommended

for the Shared Disk Secondary servers for performance reasons.

Primary

SDS

SDS

primary to the secondary servers. Both types of servers must be connected by some form of network.

To use the network protocol, set the nettype field of the database server in the sqlhosts file or registry, as shown in Example 2-1. Update the NETTYPE configuration parameter to a network protocol such as

ontlitcp, onsoctcp

ontlispx,

communicate with each other. Applications connecting to database servers can either use network or non-network protocols, such as shared memory

(onipcshm), or named pipes.

Example 2-1 Sample sqlhost file

dbserver1_tcp ontlitcp host1-name service1-name dbserver2_tcp ontlitcp host2-name service2-name dbserver1_shm onipcshm host1-name place-holder

In a network, latency, a synonym for delay, is measured by sending a packet, that is then returned to the sender. The round-trip time is considered the latency. Network latency between the database servers plays an important role in establishing a robust high availability and enterprise-wide replication solution. A quick check of network latency can be performed by the simple ping command. For example, when the ping command was issues from a SunOS™ system located in Lenexa, KS to various locations in other parts of the world, the network latency differed greatly. This is depicted in Example 2-2.

Example 2-2 Network latency $ ping -s <hostname> 56 10 #Same building

----hp-mach1 PING Statistics----

10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/0

#Menlo Park, California ----menlo PING Statistics----

10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 62/62/65

10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 124/125/131

#Bangalore, India

----bangalore PING Statistics----

10 packets transmitted, 10 packets received, 0% packet loss round-trip (ms) min/avg/max = 343/344/346

Availability of such statistics can help database administrators design their high availability and replication solutions. For example, if a DBA is not sure whether or not to use HDR Secondary or Remote Standalone Secondary (RSS), then looking at the network latency data can help make the determination of which type of secondary server to use. Network latency is not the only criteria that needs to be considered, but it is one of the important criteria in building robust high availability solutions, and it aids in the decision making process. Since RSS uses a fully duplexed communication protocol, and communication between primary and RSS is completely asynchronous, it would be alright to use RSS over the high latency network. And, where network latency is lower, choosing HDR Secondary should be the better option because HDR uses half duplex communication protocol to perform synchronous database updates.

In the case of the SDS servers, the primary requirement is the availability of a shared disk subsystem. The network requirement will vary depending on how far the systems hosting the SDS servers can be placed in an shared disk

environment. Usually, systems involved in a shared disk environment are geographically closer, and network latency between those systems will then be quite lower.

In addition, the network usage in an SDS cluster is less because the primary database server sends only the Log Sequence Number (LSN) information. This consists of the current logical log file number and the log position to the SDS server, and not the complete log pages as in the case of HDR Secondary and RSS servers.

In the case of continuous log restore, network dependency is very minimal to none. CLR is useful when the backup database server is required to be fairly current, but the two systems need to be completely independent of each other for reasons such as security or network availability. CLR can also be useful when the cost of maintaining a persistent network connection is high. With CLR, log files are manually transferred to a backup database server where they are restored.