Thanks for these resources. If I manage to add to this information, I'll
let you know.

Best Regards,

David Montgomery

> -----Original Message-----
> From: ssonic4 [mailto:x00dynzl2xmev3z001@...]
> Sent: Tuesday, January 22, 2002 3:21 AM
> To: ib-support@yahoogroups.com
> Subject: [ib-support] Re: Firebird and Network Attached Storage?
>
>
> <<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
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

_________________________________________________________
Do You Yahoo!?
Get your free @... address at http://mail.yahoo.com