Re: Dudas sendmail
El Miércoles, 19 de Octubre de 2005 21:53, DK escribió:
|| Hola lista:
||
|| Estoy buscando como poner un sendmail en alta disponibilidad y con
|| redundancia a fallos (2 maquinas).
||
|| Mi idea es hacerlo de la manera mas simple posible, que supongo que sera
|| que las 2 maquinas sean iguales (configuracion y buzones) y que solo
|| funcione una y al caer esta, que empiece a trabajar la otra.
|| Otra solucion seria poner las dos trabajando en paralelo y que se
|| balanceara el trafico, pero me da que seria mas dioficil por el tema de
|| los buzones locales y las modificaciones de los ficheros de configuracion.
|| Tambien he pensado que lo ideal seria que las 2 maquinas trabajaran contra
|| una tercera donde estarian los fichers de configuracion y los buzones. Y
|| hacer un balanceo por dns. Pero esta opcion me han dicho que no puede ser
|| asike la deshecho :-)
||
|| Mi problwema es que no se como puedo hacer para que a los usuarios les sea
|| trasparente. La configuracion del "cluster" se debe hacer a nivel de SO o
|| del sendmail?
|| Agradeceria un poco de informacion para poder empezar. Se que en google
|| habra informacion, pero creerme, esta vez no doy con ella:-(
||
|| Un saludo y gracias de antemano.
Para alta disponibilidad sirve "heartbeat", funciona muy bien.
Básicamente la idea es instalarlo en las dos máquinas y con la misma
configuración. La idea es que se configuran "recursos" siendo la IP un
recurso. Por ejemplo:
Quieres tener un servidor Samba en alta disponibilidad:
- Configuras un servidor Samba en ambos equipos de IGUAL forma (exactamente
igual, claro).
- Instalas en ambos heartbeat.
- En el archivo ha.cf configuras los nodos (dices qué equipos conforman la
alta disponibilidad, configuras cómo se ven, puede ser por IP con una tarjeta
de red exclusiva que les comunica, por IP compartida con el resto de la red,
por puerto serie...).
- En el archivo haresources especificas los servicios que compartes, en este
caso Samba, pero ¡¡¡LA IP TAMBIEN!!!
- Imaginemos que tenemos alfa y beta en alta disponibilidad:
Alfa: 192.168.0.10
Beta: 192.168.0.20
pues nosotros diremos que usen OTRA IP: 192.168.0.100.
Es decir, si se cae una máquina la otra toma el control, y toma la IP de
servicio (para el resto de máquinas conectadas a la red será completamente
transparente, no necesitan especificar otra IP distinta).
De hecho, si haces un ifconfig mientras funciona heartbeat verás que se ha
creado un Alias de eth0 (o la que sea).
Un ejemplo que tengo por ahí de ha.cf:
********************************
serial /dev/ttyS0 (alfa y beta unidos por cable serial).
keepalive 2
deadtime 10
node alfa
node beta
ping 192.168.0.131
ping_group group1 192.168.0.131
auto_failback on #Sólo en alfa, le dice que retome el control si cae y
vuelve a levantarse.
respawn hacluster /usr/lib/heartbeat/ipfail
Un ejemplo de haresources compartiendo Samba (y la IP, claro):
************************************
alfa 192.168.0.100 samba #en beta pone "beta".
Luego por supuesto falta el tema de la sincronización de ficheros:
Se hace una tarea de cron en ambos sistemas para que cada X minutos
sincronicen el contenido de las comparticiones Samba a la otra máquina (en
ambos ordenadores, claro). Esto mediante rsync.
NOTA: para evitar desastres, NUNCA programar las tareas de rsync
simultáneamente de un ordenador a otro, salvo que pretendas reventar los dos
discos duros en menos de 2 horas. Si un equipo hace rsync y copia cosas al
otro y el otro hace lo mismo simultáneamente al final acaban copiándose entre
ellos archivos temporales a los que cada uno añade una extensión en el nombre
por lo que parecen archivos nuevos y se vuelven a copiar, etc... y en menos
de 2 horas se llenó el disco duro (un truco es decir a rsyn que NO copie
archivos ocultos).
Un consejo, que una máquina haga el rsync a las horas en punto y la otra a las
horas y media.
Otro detalle, para hacer la copia de un ordenador al otro necesitan ingresar
el uno en el otro para lo que requieren autenticación. Lo más fácil es
generar en cada uno claves públicas con ssh y exportarlas al otro equipo para
que no haga falta meter password. Te copio cómo se hace al final del fichero:
Por supuesto, hay que leer mucho antes de hacer nada de esto, así pues, ya
saber, a tirar de manuales y a empollar el heartbeat.
PD: Uso de claves privada/pública en ssh para no tener que introducir el
password al acceder a un servidor:
1) ssh-keygen -t dsa
(genera las claves en el cliente, cuando pida frase de paso dar al enter).
2) Se ha generado en la $HOME/.ssh id_dsa.pub (clave publica) e id_dsa
(clave privada). Ahora hay que copiar id_dsa.pub al servidor:
scp $HOME/.ssh/id_dsa.pub serverusername@serverIP:./id_dsa.pub
3) Vas al servidor y modificas la clave copiada tal que:
username@server:~$ cd .ssh
serverusername@server:~$ touch authorized_keys2
serverusername@server:~$ chmod 600 authorized_keys2
serverusername@server:~$ cat ../id_dsa.pub >> authorized_keys2
serverusername@server:~$ rm ../id_dsa.pub
4) A partir de ahora al acceder con tu usuario a ese usuario remoto mediante
ssh el servidor no pedirá password.
5) esto habría que hacerlo en cada equipo.
--
que a mí ni me va ni me viene... pero por comentar...
Reply to: