Linux Guía Básica para armar tu propio Clúster Linux

K3rnelpanic · 4 Agosto 2016

Bueno, lo prometido es deuda dicen :zippy

, y aprovechando que estoy esperando datos de otra área :zippyte

Bueno, el tema del Clusterizado de servicios es muy útil en ambientes en donde se requiere alta disponibilidad, o balanceo de carga para estos. En esta guía se tratará algo básico como mantener un servidor activo y otro pasivo para mantener un servicio básico arriba. [strike] como una base de datos[/strike]

Partamos.

Requisitos
- Centos 7 (pueden obtener desde Aqui ).
- Máquinas Virtuales conectadas con 2 tarjetas cada una.
- Paciencia :zippy

Tutoriales de instalación hay varios, así que nos saltaremos esa parte.

La idea de tener 2 tarjetas de red es para mantener 1 de ellas en conexión directa con el segundo nodo del clúster (es lo mínimo que se recomienda para que mantengan comunicación los nodos de un clúster - de hecho se recomienda un bonding para hacerlo más tolerante a fallos, pero acá lo haremos simple :zippyu

)

La otra tarjeta de red irá conectada al switch que intercomunica la red con el resto de las cosas :zippy

.

Objetivos:
- Tener un servicio Apache operando en las 2 máquinas
- Una IP virtualizada, que el servicio de clúster se encargue mantener activa en uno de los nodos, para que en caso de falla de este, redirija el servicio transparentemente al segundo nodo.
- Un lindo laboratorio para hacer pruebas y descubrir las bondades de pcs.

Asumamos entonces lo siguiente:
Server1

Código:

hostname lab1.local
ip interna 10.0.0.10 255.255.255.0
ip externa 192.168.0.101 255.255.255.0

Server2

Código:

hostname lab2.local
ip interna 10.0.0.20 255.255.255.0
ip externa 192.168.0.102 255.255.255.0

Asumamos que ya configuraron las interfaces de red y hacen ping a las 2 IPs :zippy

Una buena practica es siempre dejar un repositorio local utilizando el DVD de instalación como fuente (en caso de que los servidores no vayan a estar conectados a Internet.
Imaginemos que tienen montado su DVD en /mnt/repodata, con lo siguiente se copian las 2 carpetas necesarias para generar el repositorio local (Packages y repodata)

Código:

#mkdir /repolocal
#cp -Rv /mnt/repodata /repolocal/ && cp -Rv /mnt/Packages /repolocal/
#cat <<END>/etc/yum.repos.d/local.repo
[CentOS_local]
name=CentOS 7.2 Local
baseurl=file:///repolocal/
gpgcheck=0
enabled=1
END

Para no tener problemas adicionales, y dado que es a modo de laboratorio, pondremos a SELINUX en modo permisivo.

Código:

mv /etc/selinux/config /etc/selinux/config.bkp
cat <<END>/etc/selinux/config
SELINUX=permissive
SELINUXTYPE=targeted
END

En CentOS 7 tenemos a firewalld (que es bien amigable en su configuración, pero en este minuto no es necesario), así que procederemos a deshabilitarlo para dejar nuestro servidor de patas abiertas. Si confían en su firewall/solución de seguridad, go ahead.

Código:

systemctl stop firewalld
systemctl disable firewalld

Algo importante es que ambos servers deben conocer su propia IP y la IP de su contraparte, por lo que agregaremos eso al archivo hosts de cada máquina. Validen que esto haya quedado bien hecho haciendo ping al nombre de host de cada maquina.

Código:

echo "192.168.0.101 lab1.local lab1" >> /etc/hosts
echo "10.0.0.10 lab1-int.local lab1-int" >> /etc/hosts
echo "192.168.0.102 lab2.local lab2" >> /etc/hosts
echo "10.0.0.20 lab2-int.local lab2-int" >> /etc/hosts

PREPARACION DEL CLUSTER
Hasta aquí sólo hemos hecho configuraciones básicas y de conectividad para que nuestros 2 servidores independientes tengan conexión entre sí. Ahora procederemos a levantar servicios y configurar el servicio de cluster como tal.

En ambos nodos instalar agentes de cluster

Código:

yum install pacemaker pcs corosync resource-agents

Esto crea los servicios necesarios para el cluster y el usuario hacluster, que se encarga de generar las tareas de comunicacion entre nodos. A este usuario le tenemos que asignar un password.

En ambos nodos

Código:

echo demo | passwd --stdin hacluster
Changing password for user hacluster.
passwd: all authentication tokens updated successfully.

También debemos habilitar el servicio para que se inicie con el sistema y posteriormente iniciarlo. En en ambos nodos

Código:

[root@lab1 ~]# systemctl enable pcsd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/pcsd.service to /usr/lib/systemd/system/pcsd.service.
[root@lab1 ~]# systemctl start pcsd.service

Ahora tenemos el usuario hacluster ya tiene password, debemos indicarle a PCS la autenticación de los nodos
Ejecuta esto solo en nodo 1

Código:

[root@lab1 ~]# pcs cluster auth lab1-int lab2-int -u hacluster
Password: **** --- ingresas tu password super segura aqui
lab1-int: Authorized
lab2-int: Authorized
[root@lab1 ~]#

Una vez realizado esto, se inicializa el cluster

Código:

[root@lab1 ~]# pcs cluster setup --start --name DEMOCLUSTER lab1-int,lab1 lab2-int,lab2
Shutting down pacemaker/corosync services...
Redirecting to /bin/systemctl stop  pacemaker.service
Redirecting to /bin/systemctl stop  corosync.service
Killing any remaining services...
Removing all cluster configuration files...
lab1-int: Succeeded
lab2-int: Succeeded
Starting cluster on nodes: lab1-int, lab2-int...
lab2-int: Starting Cluster...
lab1-int: Starting Cluster...
Synchronizing pcsd certificates on nodes lab1-int, lab2-int...
lab1-int: Success
lab2-int: Success

Restaring pcsd on the nodes in order to reload the certificates...
lab1-int: Success
lab2-int: Success
[root@lab1 ~]#

Ahora se habilitan todos los nodos desde lab1

Código:

[root@lab1 ~]# pcs cluster enable --all
lab1-int: Cluster Enabled
lab2-int: Cluster Enabled
[root@lab1 ~]#

Con esto ya tenemos los nodos del cluster comunicandose entre sí y lo podemos averiguar utilizando

Código:

pcs cluster status
pcs status

Código:

[root@lab1 ~]# pcs cluster status
Cluster Status:
Last updated: Thu Aug  4 18:30:27 2016  Last change: Thu Aug  4 18:30:06 2016 by hacluster via crmd on lab1-int
Stack: corosync
Current DC: lab1-int (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 0 resources configured
Online: [ lab1-int lab2-int ]

PCSD Status:
  lab1-int: Online
  lab2-int: Online
[root@lab1 ~]# pcs status
Cluster name: DEMOCLUSTER
WARNING: no stonith devices and stonith-enabled is not false
Last updated: Thu Aug  4 18:30:36 2016  Last change: Thu Aug  4 18:30:06 2016 by hacluster via crmd on lab1-int
Stack: corosync
Current DC: lab1-int (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 0 resources configured

Online: [ lab1-int lab2-int ]

Full list of resources:


PCSD Status:
  lab1-int: Online
  lab2-int: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled
[root@lab1 ~]#

Este WARNING gigante que aparece ahí tiene que ver con el Fencing. El Fencing es una característica de todo Cluster que tiene un storage en común, y es que en el supuesto caso de una pérdida de conectividad entre los nodos, ambos no figuren como activos, y por lo tanto, generando cambios independientes en el filesystem. Por lo tanto lo que se hace es fencing de un nodo, o inhabilitarlo de acceder al recurso compartido.

En un Clúster Linux esto se logra a través de STONITH (Shoot The Other Node In The Head - bien explícito :risas

). Acá vemos que nos alerta que no tenemos dispositivos stonith ni el stonith-enabled=false activado. Como este laboratorio no va a contar (de momento) con un Filesystem compartido, vamos a deshabilitar el stonith.

Código:

pcs property set stonith-enabled=false

Ahora estamos en condiciones de agregar resources. Pero antes, una pequeña reseña:
Como hemos visto hasta ahora, el modo de manejar un clúster Linux ha cambiado bastante desde Red Hat 6. En RHEL/CentOS 7 PCS es la herramienta centralizada de configuración. Tiene muchos menús y opciones para habilitar, visualizar, deshabilitar, etc. Todas las aristas en la configuración de un Clúster.

Código:

[root@lab1 ~]# pcs help

Usage: pcs [-f file] [-h] [commands]...
Control and configure pacemaker and corosync.

Options:
  -h, --help  Display usage and exit
  -f file  Perform actions on file instead of active CIB
  --debug  Print all network traffic and external commands run
  --version  Print pcs version information

Commands:
  cluster  Configure cluster options and nodes
  resource  Manage cluster resources
  stonith  Configure fence devices
  constraint  Set resource constraints
  property  Set pacemaker properties
  acl  Set pacemaker access control lists
  status  View cluster status
  config  View and manage cluster configuration
  pcsd  Manage pcs daemon

Ahora vamos a habilitar un resource, para comenzar. Una IP Virtual.

Código:

pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.50 cidr_netmask=24 op monitor interval=30s

Probamos haciendo ping

Código:

[vittokox@thinkpad ~]$ ping 192.168.0.50 -c 5
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.
64 bytes from 192.168.0.50: icmp_seq=1 ttl=64 time=0.488 ms
64 bytes from 192.168.0.50: icmp_seq=2 ttl=64 time=0.386 ms
64 bytes from 192.168.0.50: icmp_seq=3 ttl=64 time=0.428 ms
64 bytes from 192.168.0.50: icmp_seq=4 ttl=64 time=0.366 ms
64 bytes from 192.168.0.50: icmp_seq=5 ttl=64 time=0.418 ms

--- 192.168.0.50 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.366/0.417/0.488/0.043 ms

Ejalé!

Ahora instalaremos el servicio de Apache, en ambos nodos pero SIN INICIAR EL SERVICIO. Esto es crítico, porque ahora los servicios se gestionan como resources.

Código:

yum install httpd -y

Copiamos un molde

Código:

cp /usr/share/doc/HTML/index.html /var/www/html/ -v

Código:

cat <<END>/etc/httpd/conf.d/status.conf
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
END

Y volvemos a crear un resource, esta vez para el Apache.

Código:

pcs resource create WWW ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" op monitor interval=1min

Ahora podemos ver el servicio Apache arriba, pero levantado en el otro nodo :naster

, eso claramente no nos sirve si buscamos un esquema activo/pasivo

Código:

[root@lab1 conf.d]# pcs status
Cluster name: DEMOCLUSTER
Last updated: Thu Aug  4 19:20:38 2016  Last change: Thu Aug  4 19:20:33 2016 by root via cibadmin on lab1-int
Stack: corosync
Current DC: lab1-int (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 2 resources configured

Online: [ lab1-int lab2-int ]

Full list of resources:

VirtualIP  (ocf::heartbeat:IPaddr2):  Started lab1-int
WWW  (ocf::heartbeat:apache): Started lab2-int

PCSD Status:
  lab1-int: Online
  lab2-int: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Esto se logra utilizando la opción constraint. Con ella le decimos al cluster que queremos que X servicio siempre se ejecute donde Y servicio esté corriendo.

Código:

[root@lab1 conf.d]# pcs constraint colocation add WWW with VirtualIP INFINITY
[root@lab1 conf.d]# pcs resource show
VirtualIP  (ocf::heartbeat:IPaddr2):  Started lab1-int
WWW  (ocf::heartbeat:apache):  [/b]Started lab1-int[/b]

Puede llegar el caso en donde tengamos que reiniciar el Cluster (posiblemente por requerimiento del hefe :risas

), así que es necesario establecer QUE servicio inicia primero. No nos sirve levantar un Apache si aún no está arriba la IP Virtualizada.
Para esto, tambien se usa constraint pero con la opción order

Código:

[root@lab1 conf.d]# pcs constraint order VirtualIP then WWW
Adding VirtualIP WWW (kind: Mandatory) (Options: first-action=start then-action=start)
[root@lab1 conf.d]# pcs constraint
Location Constraints:
Ordering Constraints:
  start VirtualIP then start WWW (kind:Mandatory)
Colocation Constraints:
  WWW with VirtualIP (score:INFINITY)
[root@lab1 conf.d]#

Con esto ya está listo nuestro Cluster. Ahora pueden probar (si virtualizaron el entuerto) a desconectar de la red a uno de los nodos completamnete, mientras le hacen ping a la IP virtualizada, y acceden a la URL en la misma IP :zippyte

En un segundo capítulo, le agregaremos un GFS2 o una unidad replicada con DRBD para mantener los datos sincronizados. Aunque de momento, pueden mantener todo alineado con un cochino rsync que haga updates incrementales en ambos /var/www/html/ :lezippy

Lo más importante de este lab es que nos permite soltarle la mano a la configuración de un Cluster básico, y si se tiene tiempo, poder agregar resources y ver su forma de operar.

Quedo listo y dispuesto a recibir sus críticas, y por qué no, alguna sugerencia que gustoso aceptaré para implementar.
Yakko, no tires mucha caca :yao

yakko · 4 Agosto 2016

suscrito...

K3rnelpanic · 4 Agosto 2016

Ya csm, ahora tírenme tomates :risas

Dettlaff · 4 Agosto 2016

VittokoX dijo:
Ya csm, ahora tírenme tomates

EITSAEB · 4 Agosto 2016

me perdí en la parte que dice "Requisitos" :daleoh

pd: Se puede hacer en Virtualbox? ¿Que tipo de configuracion de tarjetas de red tendría que utilizar(nat, red interna,red nat, etc)?

K3rnelpanic · 5 Agosto 2016

EITSAEB dijo:
me perdí en la parte que dice "Requisitos"

pd: Se puede hacer en Virtualbox? ¿Que tipo de configuracion de tarjetas de red tendría que utilizar(nat, red interna,red nat, etc)?

Yo lo hice en VMware.
La idea es tener una red independiente para que se comuniquen los nodos entre sí (vmnet1) y otra en donde muestren el servicio hacia afuera (vmnet2).
No se si VirtualBox permite tener redes independientes y asignarles tarjetas de red, y que además te inserte una tarjeta virtual dentro de la red. Yo deje una en vmnet2, para visualizar el servicio como si accediera desde fuera :zippy

.

En la bolsa monté algo parecido, pero usando DRBD para replicar un disco con una BD de PostgreSQL :zippyu

Enviado desde mi MotoE2 mediante Tapatalk

Zuljin · 5 Agosto 2016

Por lo que lei al principio de la guía, es una solución activo-pasiva, no?
¿Qué usos prácticos tiene el cluster de Linux, según su experiencia?
¿Tiene sentido configurar un cluster de Linux teniendo alta disponibilidad en máquinas virtuales?

Gracias

unreal4u · 5 Agosto 2016

EITSAEB dijo:
pd: Se puede hacer en Virtualbox? ¿Que tipo de configuracion de tarjetas de red tendría que utilizar(nat, red interna,red nat, etc)?

Se puede, pero VirtualBox no es muy estable y me da la impresión de que es harto lenteja comparado con VMWare.

La manera de hacerlo es configurar un adaptador como Bridged Adapter (pública) y la otra configurada como Host-Only (segmento privado).

Está buena la guía, gracias! Me va a servir como base para expandir mis conocimientos en este tema

Una duda que siempre he tenido, suponiendo el siguiente escenario:

a) 2 webservers
b) 1 de los enlaces (el master) se cae
Cómo sabe el DNS que tiene que ir a la máquina secundaria?

Saludos.

K3rnelpanic · 5 Agosto 2016

Zuljin dijo:
Por lo que lei al principio de la guía, es una solución activo-pasiva, no?
¿Qué usos prácticos tiene el cluster de Linux, según su experiencia?
¿Tiene sentido configurar un cluster de Linux teniendo alta disponibilidad en máquinas virtuales?

Gracias

Claro, es un activo pasivo. :gaylord
En casos especializados es una buena herramienta, no sólo porque permite mantener unificados los servicios sino que adicionalmente el poder utilizar otros tipos de funcionamiento. Por ejemplo, para un software que necesite de alta disponibilidad y balanceo de carga, se puede armar un cluster de varias máquinas y utilizarlas para balancear la carga.

Tiene sentido si se tiene VMware?, claro que si, si necesitas redundancia de Servicios y se tienen 2 sites.
Por ejemplo, la empresa utiliza un sistema de dte, ese sistema estaba completamente stand alone. Una sola máquina, en un side (dijo un forero xd).
Entonces, la buena práctica es un server para las bd, otro para el aplicativo.

Al final del día todo va a depender de:

- necesidades del área (necesito alta disponibilidad o tolerancia en caso de fallo del server para este sistema?)
- recursos (puedo invertir en otro servidor para el sistema que tengo actualmente stand alone?)

Enviado desde mi MotoE2 mediante Tapatalk

Zuljin · 5 Agosto 2016

VittokoX dijo:
Claro, es un activo pasivo. :gaylord
En casos especializados es una buena herramienta, no sólo porque permite mantener unificados los servicios sino que adicionalmente el poder utilizar otros tipos de funcionamiento. Por ejemplo, para un software que necesite de alta disponibilidad y balanceo de carga, se puede armar un cluster de varias máquinas y utilizarlas para balancear la carga.

Pero si es una solución activo-pasivo entonces no sirve como balanceo de carga.

Porfa, que no se crea que estoy aportillando la guía. Nada de eso, la aplaudo y ya la publiqué en linkedin. Hago estas consultas porque me interesa aprender en dónde esta solución puede ser útil en un escenario real.

Por ejemplo, no me parece que pueda ser de utilidad en una solución HA de VMware, porque si se rompe un servidor de VMware, ese CentOS 7 se levanta en otro servidor de VMware que es parte del cluster Vmware.

Tampoco me suena como una opción para otorgarle activo/pasivo las bases de datos, ya que las mismas bases de datos cuentan con mecanismos propios de replicación y de activo/pasivo.

Lo que si creo que podría servir es para un fileserver en un servidor físico. Acá no se necesita balanceo de carga (porque la carga de un fileserver va en el acceso a disco), pero si en la disponibilidad del servicio. Lo mismo para un servidor de correo, en la situación de que el software de correo no cuente con herramientas propias de replicación o de HA.

Bueno, eso. Adelante estudios.

EITSAEB · 5 Agosto 2016

VittokoX dijo:
Yo lo hice en VMware.
La idea es tener una red independiente para que se comuniquen los nodos entre sí (vmnet1) y otra en donde muestren el servicio hacia afuera (vmnet2).
No se si VirtualBox permite tener redes independientes y asignarles tarjetas de red, y que además te inserte una tarjeta virtual dentro de la red. Yo deje una en vmnet2, para visualizar el servicio como si accediera desde fuera .

En la bolsa monté algo parecido, pero usando DRBD para replicar un disco con una BD de PostgreSQL

Enviado desde mi MotoE2 mediante Tapatalk

No entendi nada :zippynana

Voy a bajar VMWARE para ver KEONYI

K3rnelpanic · 5 Agosto 2016

Zuljin dijo:
Pero si es una solución activo-pasivo entonces no sirve como balanceo de carga.

Porfa, que no se crea que estoy aportillando la guía. Nada de eso, la aplaudo y ya la publiqué en linkedin. Hago estas consultas porque me interesa aprender en dónde esta solución puede ser útil en un escenario real.

Por ejemplo, no me parece que pueda ser de utilidad en una solución HA de VMware, porque si se rompe un servidor de VMware, ese CentOS 7 se levanta en otro servidor de VMware que es parte del cluster Vmware.

Tampoco me suena como una opción para otorgarle activo/pasivo las bases de datos, ya que las mismas bases de datos cuentan con mecanismos propios de replicación y de activo/pasivo.

Lo que si creo que podría servir es para un fileserver en un servidor físico. Acá no se necesita balanceo de carga (porque la carga de un fileserver va en el acceso a disco), pero si en la disponibilidad del servicio. Lo mismo para un servidor de correo, en la situación de que el software de correo no cuente con herramientas propias de replicación o de HA.

Bueno, eso. Adelante estudios.

Me expliqué como el pico. :risas

Puto tapatalk.

El esquema que mostré es un esquema de alta disponibilidad de servicio (activo y pasivo). El ejemplo lo expliqué con un webserver, del que necesitas esté arriba (ya sea entregando la intranet de la empresa o cualquier tontera interna), o algo más crítico como el sistema para gestionar los proyectos :zippy

.
Si bien la solución de VmWare ya trae el vmotion y la tolerancia a fallos es tremenda, eso no implica que adicionar un sistema adicional de protección sea innecesario.

Como bien tu indicas, para un fileserver viene de perilla. Acá en el trabajo me pidieron montar algo de alta disponibilidad para el sistema de facturación que usan las corredoras. Tomé este bicho, pero lo dejé con PostgreSQL en activo pasivo y utilizando DRBD para replicar la unidad de disco que se monta en /var/lib/pgsql, también en modo Activo / Pasivo. Todo esto en máquinas virtuales que corren en 2 sites distintos a través de VMware.
Cuál es la gracia de esto?, que si por alguna razón dinamitan uno de los sites, o en las pruebas regulares de energía que realizan, mantenciones, cambios de equipamiento de comunicaciones que salen mal :risas

, es el servicio pcs el que se encarga de realizar el Failover automático de la instancia SQL en el *SIDE A al *SIDE B, el servicio completo, con su filesystem se cambia de roles automáticamente.

(por eso es una mierda tapatalk, escribí cualquier tontera :risas

)
Ahora, si hablamos de balanceo de Carga, también se puede hacer, pero ese terreno ya es más complicado.
https://access.redhat.com/documenta...ancer_Administration/ch-lvs-overview-VSA.html

:zippyu

Soujiro · 5 Agosto 2016

¿Como diablos te dejo drbd montar un cluster con 2 servidores?, a mi el clvm necesario para montar los filesystem en pacemaker me dice que necesito al menos 3

K3rnelpanic · 5 Agosto 2016

Soujiro dijo:
¿Como diablos te dejo drbd montar un cluster con 2 servidores?, a mi el clvm necesario para montar los filesystem en pacemaker me dice que necesito al menos 3

Con paciencia y saliva :zippy

y mucho RTFM.
https://www.drbd.org/en/doc/users-guide-84/about

yakko · 5 Agosto 2016

Soujiro dijo:
¿Como diablos te dejo drbd montar un cluster con 2 servidores?, a mi el clvm necesario para montar los filesystem en pacemaker me dice que necesito al menos 3

se necesitan sólo 2.

yakko · 5 Agosto 2016

la verdad es que DRBD + HB era mi manera favorita de corromper datos y dejar la zorra.

no es una idea muy buena la verdad, no es muy confiable, los problemas de split brain son comunes en drbd, generalmente sobrevive la data de uno de los nodos, pero cuando cagan ambos, uff flor de cacho. Sin mencionar los problemas de performance.
Este tipo de cluster normalmente se hace para servicios donde la data es prácticamente estática y es mejor sincronizar la data con rsync que usar drbd, mejora el performance y evita errores de corrupción de datos.

Efectivamente como dice zuljin, con la entrada de las plataformas de virtualización con DRS este tipo de cluster activo-pasivo prácticamente ya no se usa.
ojo que digo este "TIPO" de cluster porque hay varios tipos de cluster y su configuración es totalmente distinta.

de todas maneras en lugares donde no hay lukas para una plataforma virtualizada, es más barato hacer este tipo de cluster.

Soujiro · 5 Agosto 2016

@yakko Recuerdo que en el curso linux que dictabas mencionabas un drbd activo/activo para un cluster de VM con Xen Server, como "opción" cuando no había lucas para un SAN, ¿esa opción sigue siendo valida o es mejor 2 maquinas con Xen server + un Openfiller como "SAN" barato?

yakko · 5 Agosto 2016

Soujiro dijo:
@yakko Recuerdo que en el curso linux que dictabas mencionabas un drbd activo/activo para un cluster de VM con Xen Server, como "opción" cuando no había lucas para un SAN, ¿esa opción sigue siendo valida o es mejor 2 maquinas con Xen server + un Openfiller como "SAN" barato?

nop, ya no se usa, el problema de performance y fiabilidad es pal forro en esa esquema.

ahora compras un storageworks (cuestan una mierda) y aplicas iscsi

chertsey · 6 Agosto 2016

Como fence device, en vmware puedes utilizar vmware_fence. Es requisito utilizar algún dispositivo de cercado o testigo, para evitar o disminuir los brainsplit.

https://access.redhat.com/solutions/68064

De todas formas, este tipo de soluciones ya practicamente no se utiliza.

slds

Koji Nanjo · 31 Agosto 2016

suscrito, algún día la necesitaré :zippynana

Linux Guía Básica para armar tu propio Clúster Linux

non serviam

pingüino mal genio

non serviam

El primero con su Nick

Team Peacemaker Hater

non serviam

Fundador

I solve problems.

non serviam

Fundador

Team Peacemaker Hater

non serviam

Fanático

non serviam

pingüino mal genio

pingüino mal genio

Fanático

pingüino mal genio

Pro

Sushiman