Our configuration with clustered services is to put the configuration rules
on each host (so that each host can separately respond to an external Amanda
request) and the IP alias controls to which node the Amanda server tries to
connect. In other words, the host that does not have the IP alias never
sees the Amanda request for backup of shared storage. The only issue comes
in if the active host (the one with the alias) does not respond with the
alias IP address in any Amanda packets. Usually, that is a configurable
option in your network services (unless the default is to always respond
with the alias address).
Another issue is that you must discard any backup if the shared storage
moves from one host to the other during backup (should be obvious, but I
want to make sure everyone understands the implications of a failover during
backup).
This should work as well for non-shared storage on the clustered systems,
since each host will see the Amanda requests addressed directly to itself
for its local file systems. Using the example below:
# hosta -> backs up all local file systems on hosta
hosta / normal
hosta /usr normal
...
# hostb -> backs up all local file systems on hostb
hosta / normal
hosta /usr normal
...
# cluster -> backs up shared storage through active member
cluster /shared_data normal
Hope that helps.
Donald L. (Don) Ritchey
E-mail: Donald.Ritchey AT exeloncorp DOT com
-----Original Message-----
From: Paolo Supino [mailto:paolo AT telmap DOT com]
Sent: Monday, May 19, 2003 12:52 PM
To: 'donald.ritchey AT exeloncorp DOT com'; amanda-users AT amanda DOT org
Subject: RE: failover environment
Hi Donald
That should do the trick. There is one problem though with this
solution: I have to put inetd under the cluster's control and I
really want to avoid it as much as possible. Can you think of any
sort of wrapper that I can put in amanda or as a shell to amanda
that will help instead of putting inetd in the cluster?
Paolo
-----Original Message-----
From: donald.ritchey AT exeloncorp DOT com
[mailto:donald.ritchey AT exeloncorp DOT com]
Sent: Monday, May 19, 2003 6:30 PM
To: paolo AT telmap DOT com; amanda-users AT amanda DOT org
Subject: RE: failover environment
In most failover environments, the access from the outside of the clustered
systems is via an IP alias. Can you configure Amanda to backup the shared
storage via the clustered system's IP alias. If you don't have such an
alias, then set up an alias to be active on the system that is controlling
the shared storage (change your failover scripts to have the machine that
currently owns the storage to assert the IP alias and the machine
relinquishing the storage must remove its alias) and have backups directed
to that alias.
If your configuration looks something like:
hosta 1.2.3.4
hostb 1.2.3.5
cluster 1.2.3.6
Your shared storage is:
/shared_data
Your DLE would look like:
cluster /shared_data normal
See if that works for you. It is pretty much what I have done in the past
with HP/Compaq Tru64 UNIX, which provides that sort of clustering as an
add-on service to their flavor of UNIX. Another advantage is that there is
a consistent view through the indexes that doesn't care which machine
controlled the storage at the time of the backup.
Don
Donald L. (Don) Ritchey
E-mail: Donald.Ritchey AT exeloncorp DOT com
-----Original Message-----
From: Paolo Supino [mailto:paolo AT telmap DOT com]
Sent: Monday, May 19, 2003 8:13 AM
To: 'amanda-users AT amanda DOT org'
Subject: failover environment
Hi
I have 1 environment where a certain path (nfs mounted, that needs
to be backed up) switches between 2 machines. Because this certain
mount is only active on 1 machine at a time amanda complains that it
can't find the path on the non active machine. Is there a way to make
amanda check and backup only the specific path only on the machine
that is active and that the path is actually mounted?
Paolo
************************************************************************
This e-mail and any of its attachments may contain Exelon Corporation
proprietary information, which is privileged, confidential, or subject
to copyright belonging to the Exelon Corporation family of Companies.
This e-mail is intended solely for the use of the individual or entity
to which it is addressed. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and attachments
to this e-mail is strictly prohibited and may be unlawful. If you have
received this e-mail in error, please notify the sender immediately and
permanently delete the original and any copy of this e-mail and any
printout. Thank You.
************************************************************************
************************************************************************
This e-mail and any of its attachments may contain Exelon Corporation
proprietary information, which is privileged, confidential, or subject
to copyright belonging to the Exelon Corporation family of Companies.
This e-mail is intended solely for the use of the individual or entity
to which it is addressed. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and attachments
to this e-mail is strictly prohibited and may be unlawful. If you have
received this e-mail in error, please notify the sender immediately and
permanently delete the original and any copy of this e-mail and any
printout. Thank You.
************************************************************************
|
