drbd + heartbeat - configurar para que levante una eth espesifica!

Imagen de al-serv

Forums: 

Buenas!

He configurado mi heartbeat en centos 5.5 y me esta funcionando pero levanta una ip virtual que internamente me parece bien pero externamente tengo una ip publica contratada y un dominio que apunta hacia esa ip la cual mi centos marca una conexión pppoe para que le asigne a esa tarjeta eth0 mi ip publica.

Mi intención es que los 2 servidores puedan tener esa ip, cuando uno esta activo el otro no pero cuando cae automáticamente marque la conexión DSL para que le asigne la ip al segundo servidor... como seria la forma correcta para que heartbeat haga eso??

Luego no consigo que drbd me monte automáticamente el /dev/drbd0 . Si lo hago manualmente se monta y desmonta y se replica al segundo servidor pero cuando reinicio ya no se monta, siempre tengo que hacerlo manualmente... no es que me sirva de mucho si eso no es automatizado ( he utilizado esta web http://wiki.centos.org/es/HowTos/Ha-Drbd ) alguien tiene un manual o alguna sugerencia para hacer que se monte automaticamente. Cada vez que reinicio siempre se queda como Secondary/Secondary y tengo que utilizar el drbadmin para que me lo ponga como primary/secondary .... alguna idea o manual???

gracias!

P.D:

ip publica 86.45.x.x que es la que tendrían que tener el servidor que en ese momento este activo para dar servicio desde internet ( correo, httpd, etc.... )
ip virtual 192.168.122.200

ip server1 192.168.122.11
ip server2 192.168.122.12

Lo de la IP virtual no me

Lo de la IP virtual no me queda claro, ¿en ambos servidores tienes 2 interfaces de red, una para la interna y otra para la pública y quieres que la IP virtual sea la pública?

Con respecto al DRBD, lo normal es que el dispositivo drbd lo monte el heartbeat. Eso está especificado en el mismo link que mencionas: http://wiki.centos.org/es/HowTos/Ha-Drbd

Saludos,

----
Edwin Boza
about.me/edwinboza

Re

Imagen de al-serv

jejeje lo de la IP no me hagas caso! actualmente utilizo el marcador DSL para que mi servidor trabaje con IP publica que me da mi proveedor pero nada esto olvidate porque con un router en multipuesto apuntando el DMZ hacia esa IP virtual ya me funciona lo que queria así que esto lo doy por cerrado!

lo del drbd he seguido ese manual pero no hay manera

monto el drbd0 en la primera maquina, le digo con el drbdadmin que lo haga primario/secundario y monto el drbd0 y todo ok, lo paso al secundario y me salen los archivos pero al reiniciar el servidor como hago para que ese drbd0 se monte automáticamente en el primero y cuando cae salga en el segundo???

También me interesaría que se pudiera montar en los dos servidores a la vez, activo/activo no como ahora que es activo/passivo .. me interesaría que siempre estuviera en los dos servidores ya que le quiero poner el /home y configuraciones varias para que los dos servidores sean igual y si uno no va el otro continué dando el servicio de correo, httpd, mysql, etc... entiendes!?? entonces en el drbd0 le pongo el /home /etc/mail y así siempre tengo funcionando en igualdad de configuraciones y no sufro por si uno u otro servidor esta activo! lo que viene siendo un faild disk . Se que en ext3 no permite montar el mismo pundo en 2 ubicaciones diferentes... como lo podría hacer???

"... como hago para que ese

"... como hago para que ese drbd0 se monte automáticamente en el primero y cuando cae salga en el segundo??? ..."

De nuevo, eso lo hace el heartbeat, las instrucciones están en el link que pasaste, al principio es un poco confuso el archivo de configuración (a mi me gustaba más el esquema anterior con el archivo "haresources" aunque era algo limitado), pero debes leer y practicar para que domines el tema. Administrar clusters puede ser un tema crítico, puesto que una "mala maniobra" puede hacer que pierdas datos cuando tienes replicación, por eso es que debes empaparte lo más posible y practicar bastante.

Con respecto al esquema Activo/Activo del DRBD, no lo he utilizado así que no podría ayudarte con eso. Supongo que tendrías que usar algo como GFS (Global File System) y tener en cuenta el tipo de información que vayas a replicar, pero la verdad no tengo experiencia práctica con ello.

Saludos,

- Edwin

----
Edwin Boza
about.me/edwinboza

Re

Imagen de al-serv

Ufff se me esta haciendo una montaña todo esto pero necesito que me funcione!

pondre claramente mi esquema para ver si es que no me se expresar bien!

empezamos de 0 :)

tengo un router en monopuesto que levanta una conexión ppp0 ya que mi proveedor así lo exige si quiero tener en monopuesto y me da una ip 86.45.123.25 con interfice ppp0 ok??

tengo creado en la eth1 del servidor la ip 192.168.122.11
tengo creado en la eth2 del servidor la ip 192.168.122.12
y heartbeat me crea la ip 192.168.122.200

Si mi router esta en monopuesto como hago para que mi servidor http al picar a www.midominio.com ( 86.45.123.25 ) pueda llegar a la ip virtual!? acualmente tengo mi servidor funcionando así, todas las DNS y servicios internos apuntan a la ip 86.45.123.25.

Si pusiera mi router en multipuesto y como puerta de enlace pusiera la 192.168.122.99 si que podria hacer que todo el DMZ vaya a la 192.168.122.200, eso me queda claro pero necesito trabajar con mi ip publica ya que mi servidor es un servidor DNS que resuelve la ip de mi dominio y que no puedo utilizar ip's privadas ya que es un servidor DNS publico que las ip's que tiene que resolves son publicas! no puedo hacer que www.midominio.com al hacer un ping externo resuelva una 192.168.122.99 . Tengo montado un servidor hosting que doy servicio a mis clientes y a mi mismo por eso trabajo con esa ip publica.

entienden??

"... Si pusiera mi router en

"... Si pusiera mi router en multipuesto y como puerta de enlace pusiera la 192.168.122.99 si que podria hacer que todo el DMZ vaya a la 192.168.122.200, eso me queda claro pero necesito trabajar con mi ip publica ya que mi servidor es un servidor DNS que resuelve la ip de mi dominio.."

No veo cual es el problema con esta configuración. Se supone que al "...hacer que todo el DMZ vaya a la 192.168.122.200...", significa que todos los requerimientos a tu IP pública van hacia la IP 192.168.122.200 (que es la IP virtual de tu cluster).

Saludos,

----
Edwin Boza
about.me/edwinboza

Re: ya esta funcionando heartbead

Imagen de al-serv

mi problema era que al configurar mi router en multipuesto, mi red interna cuando marcaba mi ip publica le respondia el router solicitando user y pass para acceder... al final he adquirido un linksys que al activar el DMZ ya me sale mi servidor y he puesto en marxa el heartbeat y ahora si que va bien. Solo el heartbeat ya que no me funciona aún el drbd que me monte los drbd0 activo/activo...

solo una pregunta para terminar con este post

tengo la eth2 que es la que utilizo para que heartbeat funcione y se comunique a trabes de un cabñle cruzado entre servidores para no pasar por el switch y generar trafico. tengo la eth1 que es la que hace de gateway para mi lan interna y la eth0 que es la que va al router

en la eth0 he creado la ip virtual que es la que esta desviada el DMZ
puedo crear una ip virtual de la eth1 para que la gateway de mis equipos de la lan la puedan utilizar y no tener que cambiar la puerta de enlace si el servidor primario cae... entiendes??? que tendria que hacer

ahora tengo

server1 192.168.122.99 httpd

esta es la que me funciona para el dmz

que añadiria??

server1 192.168.122.99 httpd
server1 10.135.0.99

para que creara la gateway de mi lan que actualmente utiliza la ip 10.135.0.1 y 10.135.0.2 en caso de que el primer servidor o el segundo este funcionando con heartbeat

Gracias por tu paciencia!

Que bueno que ya se vaya

Que bueno que ya se vaya solucionando. Con respecto a la otra Ip virtual, por la información que enviaste supongo que estás usando el archivo "haresources", si es así, debes poner la segunda IP en la misma línea.

De todas maneras yo te recomiendo que no utilices únicamente la IP sino que especifiques más datos del recurso, para las IPs virtuales el formato es así:

IPAddr::192.168.122.199/24/eth0

Así mismo para lo del DRBD deberías agregar algo como:

drbddisk Filesystem::/dev/drbd0::/punto_de_montaje::ext3

En definitiva tu archivo haresources quedaría algo así:

server1 IPAddr::192.168.122.199/24/eth0 IPAddr::10.135.0.99/24/eth1 drbddisk Filesystem::/dev/drbd0::/punto_de_montaje::ext3 httpd

Saludos,

----
Edwin Boza
about.me/edwinboza

Re

Imagen de al-serv

Bueno ya lo he puesto como me has comentado y todo bien! la única duda que me surge entonces es que en el archivo ha.cf hay:
bcast eth2

para que sirve entonces? no aria falta poner eso si ya lo especifico en el otro archivo o eso sirve para indicar por que tarjeta esta el cable cruzado entre servidores y al cual en el hosts he indicado la ip para que se comuniquen a trabes de este cable?

Con crm_yes me daba muchos problemas y prefiero no utilizar los xml ya que lo veo más sencillo así no crees? lo que, como le especificas que el server1 siempre que este activo el server2 tiene que dejarle paso ya que ahora mismo si yo en el server2 reinicio el servicio y pasa a ser el que funciona, por mucho que el otro servidor server1 este activo si no reinicio el servicio siempre va el server2 cosa que tendría que hacer automáticamente no?

Efectivamente el archivo

Efectivamente el archivo "ha.cf" es donde se pone la configuración del cluster en si, es decir: información de los nodos, interface por la que se envían los paquetes de keep alive, etc. En el "hareosurces" se especifican los "recursos" del nodo, los servicios/ip/discos que van a estar disponibles en el nodo activo.

Con respecto a la otra pregunta, en el archivo "ha.cf" había una opción de "auto_failback" aunque no estoy seguro de que siga funcionando, sin embargo, si usas DRBD no es recomendable usar el failback, porque el heartbeat no puede estar seguro de que la partición esté syncronizada antes de devolverle el control al nodo principal. Por ejemplo, imagina que tienes el nodo1 como principal y el nodo2 como backup. Por X razón se apaga el nodo1 y el nodo2 comienza a trabajar como "activo", en ese momento la data pierde la sincronización. Una vez que arregles el nodo1 y lo vuelvas a encender, deberás asegurarte de que se sincronice la información de la partición DRBD antes de poder ponerlo como activo nuevamente. Eso requiere intervención humana y por ese motivo no es recomendable el auto_failback.

Saludos,

----
Edwin Boza
about.me/edwinboza