<<remove our IB box as a potential "single point of
failure" out of our network equation.>>

I've wondered the same, and at the end of my post is a dump of my
lurker notes on this topic. One solution I started investigating
was Double-Take, (http://www.nsisoftware.com/), "a real-time data
replication and failover software product." Further quotes: "uses
patented technologies to monitor changes continuously to open
files as they occur. Only these byte-level changes are replicated
to one or more servers over standard network connections." Too
good to be true? Well, depending on your configuration, it
appears to cost about $2500/machine.

Note that I wrote "started investigating", as I never tried it,
but wrote a *very simple* replication program and am testing that
instead.

Notes from previous messages/searches/other newsgroups, etc.:

>> 28-Sep-01 Firebird with SAN storage solutions

Mike Nordell tamlin@...
<<sleyne@... ("Leyne, Sean") I am in the process
of working up a equipment configuration proposal for a client.
The configuration calls for three 'classes' of servers --database
(1 server), application (1 Server) and reporting (multiple
possible). One of the key elements of the solution is redundancy
and failover. To that end, we'd like to work up a solution which
allows for the servers to be interchangeable --i.e. if the
database server dies we can move it's functionality to another
server, etc. This level of interchangability would require that
the server be nearly identical and each support a swappable
storage solution. This means that each box could be expensive.
One of the options we are reviewing is a SAN (Storage Area
Network) solution. The hope is that the servers could be high-
performance CPU with a modest amount of RAM but without an
expensive disk/RAID controller.

First, can a SAN be used as disk storage for a Firebird db? i.e.
Does the SAN storage look like local storage to the server?

Second, any comments about the viability/use of a SAN solution?

Third, has anybody used a SAN solution? Was it used as disk
storage for a Firebird db?>>

I'd probably decide on *nix and do it something like this: One
RAID stack. Two NFS servers (computers), let's call'em NFS1 and
NFS2, with one extra network card each, _only_ connected to each
other. This is where heartbeat messages gets passed. NFS1 is the
main NFS server. If that one dies, NFS2 notices this and takes
over the IP-address from NFS1 and continues to serve. The RAID
system is connected by one SCSI bus (or SCSI over FibreChannel or
whatever bandwidth is needed) to both NFS1 and NFS2, but during
normal conditions NFS1 is the only one initiating transfers on
the SCSI bus. When NFS1 "dies" it stops sending the heartbeat to
NFS2, and NFS2 takes over the role as NFS server (and of course
sends off some serious SNMP alarms and such :-) ). A reasonably
secure and also reasonably cheap solution. Provided all machines
are within a reasonable radius.

>> 20-Nov-01 SAN info

Thanatos (dgahan@...)

Books:
The Holy Grail of Data Storage Manage Management, by John Toigo
Building Storage Networks, by Marc Farley

You'll find lots of good (and some misleading) white papers on
many vendors' sites. The leaders in block I/O SAN technology
(SCSI-FCP as the data access protocol, using raw disk arrays as
the storage element) would probably be:
StorageTek (best block indirection technology, in SVA product)
Hitachi Data Systems
EMC
IBM
Compaq
Hewlett Packard
Xiotech
Eurologic
Dell (rebadged Eurologic)

The leaders in file I/O SAN technolgy (NFS or CIFS as the data
access protocol, using high performance NAS as the storage
element on a dedicated Gigabit storage network) are:

Network Appliance (best filesystem and RAID technology on the
planet)
EMC (use lots of expensive cache RAM to try to catch up to NetApp)
Auspex
BlueArc (moved the server bottlenecks into hardware, unfortunately
still use lousy fs and RAID)
Procom
Sun N8200 (not as fast as any of the above, still uses UFS)
NEC (new product, looks good)

File I/O SAN's are generally slower at streaming I/O applications
(video, backup etc) but faster at random I/O applications (most
applications) and more scalable than block I/O SAN's. Note that
only a handful of NAS products (NetApp, EMC Celerra and IP4700,
Auspex) can currently provide the necessary write commit/data
integrity guarantees to make them suitable for database storage.
The benefit to this approach to databases is dramatically higher
scalability in the midrange/open systems environment (I fully
expect to be flamed on this but I'm more than ready to back it
up).

>> 24-Apr-01 Shadowing w/ IB 6 <rschieck@...>

You have to put the main database and the shadow on the same
physical box. The only protection it provides it for a hard disk
failure. Personally, I would put a raid controller in the box
instead and forget about shadowing.

>> 24-Oct-00 24x7 InterBase Dalton Calford

<dcalford@...>
First, If I were in your situation, I would make the raid a
external device. This is what I mean. If you buy a RAID CHASIS
with a inteligent raid controller built in (you are looking at
around 3k USD for the hardware before drives - maybe less, it has
been a few years...) then, you treat the entire RAID as a single
drive. Most boxes like that have multiple external channels as
well as multiple internal channels. You set up two external
channels to talk to two separite computers, and 3 channels to
hold your drives internal to the raid case. You make sure the
path to the database is the same for both machines, and voila,
even if one machine fails, the second machine can access the data
immediately.

>> 30-Oct-00 Clustered IB6 Holger Klemt <hklemt@...>

You can use the shadow on the other machine, but not on nt/w2k,
because there it is not possible because of ms filesystem. On
Linux, it should work over multiple machines. But this way is
simply a backup from one machine to one or more other machine. It
does not help for load balancing.

When you are forced to use nt/w2k, you can work with a replicated
database. I showed to a customer on the cebit how to setup a
simple replication between 4 InterBase Server on nt. Every change
was transmitted to a simple replication daemon, who looked in the
triggers, that filled the transaction log. The replication daemon
program was written in delphi (around 500 lines of code) and it
was creating all needed triggers and objects also. there was also
a replication for blobs. I also did a replication workshop with
some customers from germany and suisse. If you are interested, i
can send you the main parts of the sourcecode as an example.

Die Deutsche InterBase User Group --- http://www.dibug.de
IBExpert - The most Expert for InterBase --- http://www.ibexpert.com
======================================================
HK Software - Holger Klemt - Lange Straße 59 - D-26122 Oldenburg
Telefon +49 441 2184770 - Telefax +49 441 2184779
Schulungen - Projektunterstützung - Delphi - InterBase - AS/400