Forum

Unified Communications System

Help us to improve VitalPBX

Processing ...
USD
VitalPBX High Avail...
 

VitalPBX High Availability - modprobe: FATAL: Module drbd not found  

  RSS

Tuxheader
(@tuxheader)
Member Moderator
Joined: 1 year ago
Posts: 81
02/01/2019 7:05 pm  

Estimado José.

 

Gusto de saludarlo, entre los proyectos para el 2019, tenemos dos posibles clientes que están muy interesados en la versión HA, así que nos pusimos a homologar el nuevo servicio de alta disponibilidad y en el paso "4.7.- Configuring DRBD", nos aparece este error:

 

[root@voiptech1 ~]# modprobe drbd
modprobe: FATAL: Module drbd not found.
[root@voiptech1 ~]#

 

Estos fueron los paquetes que se instalaron al ejecutar el script: [root@ vitalpbx1-2 ~]# yum -y install drbd90-utils kmod-drbd90 corosync pacemaker pcs

Dependencies Resolved

======================================================================================================================================================
Package Arch Version Repository Size
======================================================================================================================================================
installing:
corosync x86_64 2.4.3-4.el7 base 220 k
drbd90-utils x86_64 9.3.1-1.el7.elrepo vpbx 680 k
kmod-drbd90 x86_64 9.0.14-1.el7_5.elrepo vpbx 266 k
pacemaker x86_64 1.1.19-8.el7_6.2 updates 461 k
pcs x86_64 0.9.165-6.el7.centos base 5.9 M

Transaction Summary
======================================================================================================================================================

 

Según lo que hemos visto en muchos foros, este es un problema común, por temas de incompatibilidad con la versión de Kernel que está corriendo en el servidor, te dejo varios datos, y de paso solicitarte tu ayuda y de esta forma actualizar el manual y compartirlo con ustedes.

Datos:

Kernel:

[root@voiptech1 ~]# uname -r
3.10.0-957.1.3.el7.x86_64
[root@voiptech1 ~]#

[root@voiptech1 ~]# cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core)
[root@voiptech1 ~]#

 

Versión, DRBD:

 

[root@voiptech1 ~]# rpm -qa | grep drbd
kmod-drbd90-9.0.14-1.el7_5.elrepo.x86_64
drbd90-utils-9.3.1-1.el7.elrepo.x86_64
[root@voiptech1 ~]#

 

Quedamos atentos a sus comentarios.

 

Saludos cordiales!

 


Quote
admin
(@dwiqu1m0)
Member Admin
Joined: 2 years ago
Posts: 73
02/01/2019 9:30 pm  

Hola,

Por lo que veo es una versión reciente de Linux Centos 7.

Nosotros actualmente la homologamos con el ultimo ISO de VitalPBX que contiene la siguiente información:

[root@vitalpbx1 ~]# uname -r
3.10.0-862.14.4.el7.x86_64
[root@vitalpbx1 ~]# cat /etc/centos-release
CentOS Linux release 7.5.1804 (Core)
[root@vitalpbx1 ~]# rpm -qa | grep drbd
drbd90-utils-9.3.1-1.el7.elrepo.x86_64
kmod-drbd90-9.0.14-1.el7_5.elrepo.x86_64
[root@vitalpbx1 ~]#

En el próximo ISO de VitalPBX vamos a actualizar la versión de Linux, estará disponible a finales de este mes.

 

Saludes,

 

Rodrigo


ReplyQuote
Tuxheader
(@tuxheader)
Member Moderator
Joined: 1 year ago
Posts: 81
02/01/2019 9:45 pm  

Don Rodrigo.

 

Gusto de saludarlo, primero Feliz Año, Muchas gracias por responder tan pronto, le comento que ya lo resolvimos, el problema radica en la versión del drbd90, en específico en el repositorio, el cual ignoro el motivo porque CentOS 7.X no lo tiene actualizado. Lo que hicimos fue lo siguiente:

 

Instalamos un repo llamado, ELrepo: http://elrepo.org/tiki/tiki-index.php , realizamos el procedimiento de instalación de llave, y actualizamos, este detectó que efectivamente la versión del módulo DRBD90 estaba desactualizado y lo migró de 7.0, a 7.5 y a 7.6, le paso el detalle de todo el proceso:

 

[root@voiptech1 ~]#
[root@voiptech1 ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
[root@voiptech1 ~]# rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
Retrieving https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
Preparing... ################################# [100%]
Updating / installing...
1:elrepo-release-7.0-3.el7.elrepo ################################# [100%]
[root@voiptech1 ~]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirrors.ucr.ac.cr
* elrepo: reflector.westga.edu
* epel: reflector.westga.edu
* extras: mirrors.ucr.ac.cr
* updates: mirrors.ucr.ac.cr
elrepo | 2.9 kB 00:00:02
elrepo/primary_db | 630 kB 00:01:14
Resolving Dependencies
--> Running transaction check
---> Package drbd90-utils.x86_64 0:9.3.1-1.el7.elrepo will be updated
---> Package drbd90-utils.x86_64 0:9.6.0-1.el7.elrepo will be an update
---> Package kmod-drbd90.x86_64 0:9.0.14-1.el7_5.elrepo will be updated
---> Package kmod-drbd90.x86_64 0:9.0.16-1.el7_6.elrepo will be an update
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================================
Package Arch Version Repository Size
======================================================================================================================================================
Updating:
drbd90-utils x86_64 9.6.0-1.el7.elrepo elrepo 692 k
kmod-drbd90 x86_64 9.0.16-1.el7_6.elrepo elrepo 271 k

Transaction Summary
======================================================================================================================================================
Upgrade 2 Packages

Total download size: 963 k
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
(1/2): kmod-drbd90-9.0.16-1.el7_6.elrepo.x86_64.rpm | 271 kB 00:00:25
(2/2): drbd90-utils-9.6.0-1.el7.elrepo.x86_64.rpm | 692 kB 00:01:16
------------------------------------------------------------------------------------------------------------------------------------------------------
Total 13 kB/s | 963 kB 00:01:16
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.
Updating : drbd90-utils-9.6.0-1.el7.elrepo.x86_64 1/4
Updating : kmod-drbd90-9.0.16-1.el7_6.elrepo.x86_64 2/4
Working. This may take some time ...
Done.
Cleanup : kmod-drbd90-9.0.14-1.el7_5.elrepo.x86_64 3/4
Working. This may take some time ...
Done.
Cleanup : drbd90-utils-9.3.1-1.el7.elrepo.x86_64 4/4
Verifying : kmod-drbd90-9.0.16-1.el7_6.elrepo.x86_64 1/4
Verifying : drbd90-utils-9.6.0-1.el7.elrepo.x86_64 2/4
Verifying : kmod-drbd90-9.0.14-1.el7_5.elrepo.x86_64 3/4
Verifying : drbd90-utils-9.3.1-1.el7.elrepo.x86_64 4/4

Updated:
drbd90-utils.x86_64 0:9.6.0-1.el7.elrepo kmod-drbd90.x86_64 0:9.0.16-1.el7_6.elrepo

Complete!
[root@voiptech1 ~]#

 

A continuación ejecutamos:

 

[root@voiptech1 ~]# depmod -a && modprobe drbd
[root@voiptech1 ~]# modprobe drbd
[root@voiptech1 ~]# systemctl enable drbd.service

 

En este momento estamos asignando la "IP Flotante", o bien para los familiarizados con los sistemas CS1000E de Nortel, el famoso NODO IP. Por ende en el paso 4.8, página 11.

 

Le cuento como nos fue.

 

Muchísimas gracias por el apoyo.

 

Saludos cordiales!!!!


ReplyQuote
Tuxheader
(@tuxheader)
Member Moderator
Joined: 1 year ago
Posts: 81
02/01/2019 9:45 pm  

Don Rodrigo.

 

Gusto de saludarlo, primero Feliz Año, Muchas gracias por responder tan pronto, le comento que ya lo resolvimos, el problema radica en la versión del drbd90, en específico en el repositorio, el cual ignoro el motivo porque CentOS 7.X no lo tiene actualizado. Lo que hicimos fue lo siguiente:

 

Instalamos un repo llamado, ELrepo: http://elrepo.org/tiki/tiki-index.php , realizamos el procedimiento de instalación de llave, y actualizamos, este detectó que efectivamente la versión del módulo DRBD90 estaba desactualizado y lo migró de 7.0, a 7.5 y a 7.6, le paso el detalle de todo el proceso:

 

[root@voiptech1 ~]#
[root@voiptech1 ~]# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
[root@voiptech1 ~]# rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
Retrieving https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
Preparing... ################################# [100%]
Updating / installing...
1:elrepo-release-7.0-3.el7.elrepo ################################# [100%]
[root@voiptech1 ~]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirrors.ucr.ac.cr
* elrepo: reflector.westga.edu
* epel: reflector.westga.edu
* extras: mirrors.ucr.ac.cr
* updates: mirrors.ucr.ac.cr
elrepo | 2.9 kB 00:00:02
elrepo/primary_db | 630 kB 00:01:14
Resolving Dependencies
--> Running transaction check
---> Package drbd90-utils.x86_64 0:9.3.1-1.el7.elrepo will be updated
---> Package drbd90-utils.x86_64 0:9.6.0-1.el7.elrepo will be an update
---> Package kmod-drbd90.x86_64 0:9.0.14-1.el7_5.elrepo will be updated
---> Package kmod-drbd90.x86_64 0:9.0.16-1.el7_6.elrepo will be an update
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================================
Package Arch Version Repository Size
======================================================================================================================================================
Updating:
drbd90-utils x86_64 9.6.0-1.el7.elrepo elrepo 692 k
kmod-drbd90 x86_64 9.0.16-1.el7_6.elrepo elrepo 271 k

Transaction Summary
======================================================================================================================================================
Upgrade 2 Packages

Total download size: 963 k
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
(1/2): kmod-drbd90-9.0.16-1.el7_6.elrepo.x86_64.rpm | 271 kB 00:00:25
(2/2): drbd90-utils-9.6.0-1.el7.elrepo.x86_64.rpm | 692 kB 00:01:16
------------------------------------------------------------------------------------------------------------------------------------------------------
Total 13 kB/s | 963 kB 00:01:16
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.
Updating : drbd90-utils-9.6.0-1.el7.elrepo.x86_64 1/4
Updating : kmod-drbd90-9.0.16-1.el7_6.elrepo.x86_64 2/4
Working. This may take some time ...
Done.
Cleanup : kmod-drbd90-9.0.14-1.el7_5.elrepo.x86_64 3/4
Working. This may take some time ...
Done.
Cleanup : drbd90-utils-9.3.1-1.el7.elrepo.x86_64 4/4
Verifying : kmod-drbd90-9.0.16-1.el7_6.elrepo.x86_64 1/4
Verifying : drbd90-utils-9.6.0-1.el7.elrepo.x86_64 2/4
Verifying : kmod-drbd90-9.0.14-1.el7_5.elrepo.x86_64 3/4
Verifying : drbd90-utils-9.3.1-1.el7.elrepo.x86_64 4/4

Updated:
drbd90-utils.x86_64 0:9.6.0-1.el7.elrepo kmod-drbd90.x86_64 0:9.0.16-1.el7_6.elrepo

Complete!
[root@voiptech1 ~]#

 

A continuación ejecutamos:

 

[root@voiptech1 ~]# depmod -a && modprobe drbd
[root@voiptech1 ~]# modprobe drbd
[root@voiptech1 ~]# systemctl enable drbd.service

 

En este momento estamos asignando la "IP Flotante", o bien para los familiarizados con los sistemas CS1000E de Nortel, el famoso NODO IP. Por ende en el paso 4.8, página 11.

 

Le cuento como nos fue.

 

Muchísimas gracias por el apoyo.

 

Saludos cordiales!!!!


ReplyQuote
Tuxheader
(@tuxheader)
Member Moderator
Joined: 1 year ago
Posts: 81
02/01/2019 11:01 pm  

Don Rodrigo, Don José.

 

 

Nos pegamos de nuevo en el punto:  Create FILESYSTEM resource for the automated mount point

 

[root@voiptech1 ~]# pcs -f fs_cfg constraint colocation add DrbdFS with DrbdDataClone INFINITY with-rsc-role=Master
Error: Resource 'DrbdDataClone' does not exist

 

A pesar que el anterior parámetro que se ejecutó no dio errores:

 

pcs -f fs_cfg resource create DrbdFS Filesystem device="/dev/drbd0" directory="/mnt" fstype="xfs"

 

Revisamos si el cluster está activo y sincronizado:

[root@voiptech1 ~]# pcs cluster status
Cluster Status:
Stack: corosync
Current DC: voiptech2.local (version 1.1.19-8.el7_6.2-c3c624ea3d) - partition with quorum
Last updated: Wed Jan 2 23:29:03 2019
Last change: Wed Jan 2 22:57:01 2019 by root via cibadmin on voiptech1.local
2 nodes configured
3 resources configured

PCSD Status:
voiptech1.local: Online
voiptech2.local: Online
[root@voiptech1 ~]#

 

Vamos a reconstruir los procesos para tratar de ver si se replica el error, o bien esperaremos sus comentarios.

 

 

Saludos cordiales!


ReplyQuote
admin
(@dwiqu1m0)
Member Admin
Joined: 2 years ago
Posts: 73
03/01/2019 7:01 am  

Hola, están seguros que crearon la partición al inicio de la instalación en forma correcta?

Están utilizando el manual paso a paso o el script?


ReplyQuote
Tuxheader
(@tuxheader)
Member Moderator
Joined: 1 year ago
Posts: 81
03/01/2019 4:58 pm  

Don Rodrigo.

 

Gusto de saludarlo, efectivamente estamos utilizando el manual que ustedes tienen en su página web. Como le comenté al final de mi último post, íbamos a reiniciar los procesos, borramos el lab y lo volvimos a realizar desde cero, tuvimos mucho cuidado de no cometer errores y tratamos de respetar al pie de la letra el manual de ustedes, sobre este tema y para estar seguro de que íbamos bien, existe un comando distinto para verificar que el cluster esté trabajando bien, en la versión de drbd90 cambia el mismo, ojo:

 

CPU 1:

[root@voiptech1 ~]#
[root@voiptech1 ~]# drbdadm status
drbd0 role:Primary
disk:UpToDate
voiptech2.local role:Secondary
peer-disk:UpToDate

[root@voiptech1 ~]#
[root@voiptech1 ~]#

 

CPU 2:

 

[root@voiptech2 ~]# drbdadm status
drbd0 role:Secondary
disk:UpToDate
voiptech1.local role:Primary
peer-disk:UpToDate

[root@voiptech2 ~]#
[root@voiptech2 ~]#

 

Continuamos los pasos del manual y de nuevo nos encontramos el mismo error anterior:

 

Manual: página #11, Apartado 4.8 - Create FILESYSTEM resource for the automated mount point

[root@voiptech1 ~]# pcs -f fs_cfg resource create DrbdFS Filesystem device="/dev/drbd0" directory="/mnt" fstype="xfs"
Assumed agent name 'ocf:heartbeat:Filesystem' (deduced from 'Filesystem')
Warning: Replacing the whole CIB instead of applying a diff, a race condition may happen if the CIB is pushed more than once simultaneously. To fix this, upgrade pacemaker to get crm_feature_set at least 3.0.9, current is 0.0.0.
[root@voiptech1 ~]#

El segundo paso falla:

[root@voiptech1 ~]# pcs -f fs_cfg constraint colocation add DrbdFS with DrbdDataClone INFINITY with-rsc-role=Master
Error: Resource 'DrbdDataClone' does not exist
[root@voiptech1 ~]#

 

En su último post usted menciona un script, donde lo bajamos para probarlo?

 

Saludos ccordiales!


ReplyQuote
admin
(@dwiqu1m0)
Member Admin
Joined: 2 years ago
Posts: 73
03/01/2019 5:00 pm  

Te recomiendo el siguiente link

https://github.com/VitalPBX/vitalpbx_ha

es  mas sencillo y rapido.

Seguilo paso a paso


ReplyQuote
Tuxheader
(@tuxheader)
Member Moderator
Joined: 1 year ago
Posts: 81
03/01/2019 10:29 pm  

Don Rodrigo.

 

Listo! Works!!! Pero un tema, hay que esperar a que los discos sincronicen, y con el parámetro: #drbdadm status   podrás conocer el estatus de la sincronización de la partición, ahorá para darse cuenta que aún esta no acaba, cada vez que ingreses a la terminal vía SSH notarás que la versión del Core de Asterisk no aparece, es el mismo síntoma cuando realizas un RAID.

 

[root@voiptech2 ~]# drbdadm status
drbd0 role:Secondary
disk:UpToDate
voiptech1.local role:Primary
peer-disk:UpToDate

[root@voiptech2 ~]#

 

Pero tengo unas preguntas que me intrigan:

 

1-El servicio HA podría correr en servidores que tiene arreglos de discos, tales cómo RAID 0, RAID 1 disco espejo o superior?

2-Cual es la partición más importante en un HA, la primera de 20GB de la instalación inicial, o la SDA4 la cual es la partición que uno crea después de la instalación inicial y asumo es la del CLUSTER?

3-Presumo también que la instalación inicial he individual que uno ejecuta en cada servidor inicialmente, el sistema de Cluster toma todo lo referente a la instalación y la traslada o bien clona todo lo que existe en la partición pequeña de 20GB a la partición  SDA4?

4-Cuál sería la recomendación si tengo discos de 2TB, siempre realizaré en la instalación inicial una partición pequeña de 20GB y 1980GB para la SDA4, o bien el mayor espacio disponible siempre será para la SDA4?

5-Si el Primary Server sale de servicio, cuanto tiempo le toma al Slave entrar en operación?

6-Si el servidor que había salido de servicio vitalpbx1.local reingresa en producción, que pasa con el vitalpbx2.local que antes era esclavo y ahora esta cómo Master, hay que manualmente degradarlo de nuevo a esclavo invocando el parámetro "bascul", o el se degrada de forma automática a slave?

7-Si la respuesta es MANUAL, se podría crear un script y correrlo con el servicio de CRON para que todos los días a media noche verifique quien está de Master y quien está de Slave, o bien crear un script llamado Midnight Routine realice el cambio o bien realice un switch entre ambos servers?

8-Existe un tiempo máximo permitido para que un servidor salga de servicio y vuelva a estar en operación, existe algún limitante o restricción que exiga un tiempo mínimo y máximo?

9-Existe algún parámetro para forzar la sincronización de "discos"?

 

Creo que no tengo más preguntas, perdone el abuso pero lo que son las casualidades, mañana tengo la primera reunión para un HA y se que el cliente me va a bombardear de preguntas.

 

Bueno para finalizar, el PDF tiene sus detalles, pero el script está perfectamente creado por ustedes dos, impresionante, los felicito!!!

 

Muchísimas gracias por todo el apoyo, Saludos cordiales!!!!


ReplyQuote
admin
(@dwiqu1m0)
Member Admin
Joined: 2 years ago
Posts: 73
04/01/2019 8:53 am  

Que bueno que te funciono, en estos momento estamos haciendo una interfaz gráfica para supervisar la alta disponibilidad y poder bascular entre servidores, es un modulo comercial.

Atendiendo tus preguntas:

1-El servicio HA podría correr en servidores que tiene arreglos de discos, tales cómo RAID 0, RAID 1 disco espejo o superior?

R/ La alta disponibilidad corre perfecto en servidores con arreglo, aquí el tema es cuanto espacio de disco duro deseas dejar para la data variable, es importante dejar la mayor cantidad posible.

2-Cual es la partición más importante en un HA, la primera de 20GB de la instalación inicial, o la SDA4 la cual es la partición que uno crea después de la instalación inicial y asumo es la del CLUSTER?

R/ La partición de 20GB es para el sistema operativo y las aplicaciones que instales en tu server, puede ser menor ya que linux ocupa como 2 GB, la partición que llamas SDA4 es muy importante ya que allí esta la data variable que es la única que se replica, allí están las grabaciones, los archivos de configuración de Asterisk, las bases de datos de MariaDB, los log, y todo lo que es data  variable.

3-Presumo también que la instalación inicial he individual que uno ejecuta en cada servidor inicialmente, el sistema de Cluster toma todo lo referente a la instalación y la traslada o bien clona todo lo que existe en la partición pequeña de 20GB a la partición  SDA4?

R/ En la partición pequeña de 20GB están instalado los OS y programas como VitalPBX, MariaDB, Fail2Ban, etc., los cuales se instalaron con el ISO de VitalPBX, en la grande SDA4 todo lo que es dinámico, data variable se clone en tiempo real. Solo se clona la data variable. Si instalas un nuevo modulo lo tenes que hacer en ambos server, si actualizas lo tenes que hacer en ambos server.

4-Cuál sería la recomendación si tengo discos de 2TB, siempre realizaré en la instalación inicial una partición pequeña de 20GB y 1980GB para la SDA4, o bien el mayor espacio disponible siempre será para la SDA4?

R/ Asi es, intenta dejar la mayor cantidad posible para SDA4, sin embargo si tenes 2TB, deja 100GB para la principal y el resto para SDA4.

5-Si el Primary Server sale de servicio, cuanto tiempo le toma al Slave entrar en operación?

R/ Esto depende de la capacidad en memoria y procesador de los servidores, en promedio 20 segundos.

6-Si el servidor que había salido de servicio vitalpbx1.local reingresa en producción, que pasa con el vitalpbx2.local que antes era esclavo y ahora esta cómo Master, hay que manualmente degradarlo de nuevo a esclavo invocando el parámetro "bascul", o el se degrada de forma automática a slave?

R/ No se degrada de forma automática al menos que apagues el vitalpbx2.local. El comando bascul es para eso regresar al Master original y para dar mantenimiento e instalar nuevos software en ambos server. A como te dije muy pronto saldrá la interfaz web para hacer esa acción desde la GUI

7-Si la respuesta es MANUAL, se podría crear un script y correrlo con el servicio de CRON para que todos los días a media noche verifique quien está de Master y quien está de Slave, o bien crear un script llamado Midnight Routine realice el cambio o bien realice un switch entre ambos servers?

R/ Claro que se puede crear un Scrip, es muy sencillo, solo hay que ejecutar el siguiente comando

> pcs cluster unstandby vitalpbx2.local

 un minuto después

> pcs cluster standby vitalpbx2.local

Y así te aseguras que vitalpbx1.local sea siempre el Master.

8-Existe un tiempo máximo permitido para que un servidor salga de servicio y vuelva a estar en operación, existe algún limitante o restricción que exiga un tiempo mínimo y máximo?

R/ No, si al aster sale por unos 3 segundos el bascula-miento es inmediato.

9-Existe algún parámetro para forzar la sincronización de "discos"?

R/ Si la instalación fue exitosa, la sincronizacion es automática, podes utilizar el comando drbdadm status para ver el proceso. 

Hay un blog que te muestra como forzar la sincronizacion:

https://mike.mcmurray.co.nz/2012/04/28/drbd-forcing-a-full-re-sync-in-a-split-brain-situation/


ReplyQuote
Tuxheader
(@tuxheader)
Member Moderator
Joined: 1 year ago
Posts: 81
04/01/2019 12:00 pm  

Muchísimas gracias Don Rodrigo, como siempre ustedes son los mejores!!!

 

Un fuerte Abrazo, Saludos cordiales!!!!

This post was modified 3 months ago by admin

ReplyQuote
cyberzork
(@cyberzork)
New Member
Joined: 2 weeks ago
Posts: 1
14/03/2019 2:33 pm  

Hola buenas tardes, estoy realizando la configuración de 2 servidores en HA, mediante script, dichos servidores los he tenido que instalar primero el Sistema Operativo y posteriormente el sistema VitalPBX desde script, ha quedado bien la instalación de inicio, posteriormente realicé la instalación de HA mediante script, me encontré con el error de de modprobe drbd no existe, lo instalé manual, continué con la ejecución del script y aparentemente no tuvo más error, la cuestión es que no me permitió levantar el servicio.

[root@pbxcloud01 /]# drbdadm status
drbd0 role:Primary
disk:UpToDate
pbxcloud02.sitti.mx role:Secondary
replication:SyncSource peer-disk:Inconsistent done:0.00

 


ReplyQuote
mrivera
(@ing-joserivera26)
Developer Admin
Joined: 1 year ago
Posts: 1047
14/03/2019 2:45 pm  

Ya seguistes todos los pasos expuestos en el siguiente link: https://github.com/VitalPBX/vitalpbx_ha


ReplyQuote
Share:
  
Working

Please Login or Register