Sí. Te lo preparo como un bloque completo de prácticas, pensado específicamente para aprovechar el MikroTik RB951Ui-2nD con RouterOS 6.47.4, junto con máquinas virtuales Ubuntu.
La idea es que cada práctica sea sencilla por separado y que, al terminar, se pueda montar una pequeña infraestructura de alta disponibilidad, redundancia, monitorización, virtualización y pruebas de carga.
Prácticas de alta disponibilidad con MikroTik y máquinas virtuales
Infraestructura utilizada
Se utilizará el MikroTik como elemento de red y varias máquinas virtuales Ubuntu como servidores.
INTERNET
│
▼
┌──────────────┐
│ Router │
│ 192.168.1.1 │
└──────┬───────┘
│
ether1
│
┌────────▼─────────┐
│ MikroTik │
│ 192.168.88.1 │
└────────┬─────────┘
│
192.168.88.0/24
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Ubuntu 1 Ubuntu 2 Cliente
192.168.88.10 192.168.88.11
WEB 1 WEB 2
Las máquinas virtuales pueden ejecutarse en el ordenador utilizando VirtualBox, VMware, UTM u otra plataforma de virtualización.
Práctica 1. Identificación de un punto único de fallo
Objetivo
Comprender qué problema existe cuando un servicio depende de un único servidor.
Inicialmente solamente tendremos:
Cliente
│
▼
MikroTik
│
▼
Ubuntu 1
192.168.88.10
│
▼
Servidor webSi Ubuntu 1 deja de funcionar, el servicio desaparece.
1. Crear la máquina virtual
Crear una máquina virtual Ubuntu Server.
Configuración de red:
IP: 192.168.88.10
Máscara: 255.255.255.0
Gateway: 192.168.88.1
DNS: 192.168.88.1Comprobar:
ip addrip routeProbar el MikroTik:
ping 192.168.88.12. Instalar Apache
sudo apt update
sudo apt install apache2Comprobar:
sudo systemctl status apache2Desde otro ordenador:
http://192.168.88.10Debería aparecer la página de Apache.
3. Personalizar la página
Editar:
sudo nano /var/www/html/index.htmlPoner:
<h1>Servidor WEB 1</h1>
<p>Servidor principal de la práctica de alta disponibilidad.</p>4. Simular un fallo
Apagar el servidor:
sudo shutdown nowIntentar acceder de nuevo:
http://192.168.88.10El servicio ya no estará disponible.
Resultado
El alumno debe identificar:
Servidor único
↓
Punto único de fallo
↓
Servidor detenido
↓
Servicio no disponiblePráctica 2. Dos servidores web redundantes
Ahora añadiremos un segundo servidor.
La infraestructura será:
MikroTik
│
┌──────┴──────┐
│ │
▼ ▼
WEB 1 WEB 2
192.168.88.10 192.168.88.11
Objetivo
Crear dos servidores que proporcionen el mismo servicio.
1. Crear Ubuntu 2
Crear una segunda máquina virtual.
Configurar:
IP: 192.168.88.11
Máscara: 255.255.255.0
Gateway: 192.168.88.1
DNS: 192.168.88.1Comprobar:
ip addr2. Instalar Apache
sudo apt update
sudo apt install apache2Comprobar:
sudo systemctl status apache23. Crear una página diferente
sudo nano /var/www/html/index.htmlIntroducir:
<h1>Servidor WEB 2</h1>
<p>Segundo servidor de la práctica de alta disponibilidad.</p>4. Comprobar los dos servidores
Desde un cliente:
curl http://192.168.88.10Resultado:
Servidor WEB 1Después:
curl http://192.168.88.11Resultado:
Servidor WEB 2Ya tenemos dos servidores independientes.
Práctica 3. Balanceo sencillo con MikroTik
Ahora vamos a utilizar el MikroTik para distribuir conexiones entre los dos servidores.
La topología será:
Cliente
│
▼
192.168.88.100
│
▼
MikroTik
/ \
/ \
▼ ▼
WEB 1 WEB 2
.88.10 .88.11
El cliente solamente utilizará:
http://192.168.88.100El MikroTik decidirá a qué servidor enviar la conexión.
1. Añadir la IP virtual
En el MikroTik:
/ip address add address=192.168.88.100/24 interface=bridgeLocal comment="IP virtual balanceador"Comprobar:
/ip address printAhora el MikroTik tendrá:
192.168.88.1
192.168.88.1002. Crear marcas de conexión
Utilizaremos PCC para distribuir las conexiones.
Primero:
/ip firewall mangle
add chain=prerouting dst-address=192.168.88.100 protocol=tcp dst-port=80 \
per-connection-classifier=both-addresses-and-ports:2/0 \
action=mark-connection new-connection-mark=WEB1 passthrough=yes \
comment="Balance WEB1"Y:
/ip firewall mangle
add chain=prerouting dst-address=192.168.88.100 protocol=tcp dst-port=80 \
per-connection-classifier=both-addresses-and-ports:2/1 \
action=mark-connection new-connection-mark=WEB2 passthrough=yes \
comment="Balance WEB2"3. Crear las reglas NAT
Para WEB1:
/ip firewall nat
add chain=dstnat dst-address=192.168.88.100 protocol=tcp dst-port=80 \
connection-mark=WEB1 action=dst-nat \
to-addresses=192.168.88.10 to-ports=80 \
comment="NAT hacia WEB1"Para WEB2:
/ip firewall nat
add chain=dstnat dst-address=192.168.88.100 protocol=tcp dst-port=80 \
connection-mark=WEB2 action=dst-nat \
to-addresses=192.168.88.11 to-ports=80 \
comment="NAT hacia WEB2"4. Probar
Desde el cliente:
curl http://192.168.88.100Abrir varias conexiones:
for i in {1..10}; do curl -s http://192.168.88.100; donePodremos observar respuestas procedentes de:
WEB 1
WEB 2Consultar las conexiones:
/ip firewall connection printY las reglas:
/ip firewall nat print5. Ver las estadísticas
/ip firewall nat print statsTambién:
/ip firewall mangle print statsEsto permite comprobar cuántas conexiones han pasado por cada regla.
Práctica 4. Detección de servidores disponibles
Aquí introduciremos el concepto de health check.
El MikroTik comprobará periódicamente si los servidores están disponibles.
MikroTik
/ \
▼ ▼
WEB 1 WEB 2
│ │
¿OK? ¿OK?
1. Comprobar manualmente
Desde MikroTik:
/ping 192.168.88.10 count=3Y:
/ping 192.168.88.11 count=3Si el servidor responde:
3 packets transmitted, 3 packets receivedestá disponible.
2. Crear un script
Crear:
/system script
add name=check-web1 source={
:local result [/ping 192.168.88.10 count=3]
:if ($result = 0) do={
:log warning "WEB1 NO DISPONIBLE"
} else={
:log info "WEB1 DISPONIBLE"
}
}Ejecutar:
/system script run check-web1Consultar:
/log print3. Crear comprobación para WEB2
/system script
add name=check-web2 source={
:local result [/ping 192.168.88.11 count=3]
:if ($result = 0) do={
:log warning "WEB2 NO DISPONIBLE"
} else={
:log info "WEB2 DISPONIBLE"
}
}Ejecutar:
/system script run check-web24. Automatizar la comprobación
Crear un scheduler:
/system scheduler
add name=monitor-web1 interval=1m on-event=check-web1Y:
/system scheduler
add name=monitor-web2 interval=1m on-event=check-web2Consultar:
/system scheduler print5. Simular un fallo
En WEB1:
sudo systemctl stop apache2Aquí hay una consideración importante: el servidor seguirá respondiendo a ping, aunque Apache esté parado.
Por tanto, para una práctica de disponibilidad del servicio web, es mejor comprobar el puerto 80.
Podemos comprobarlo desde Ubuntu o utilizar una prueba TCP desde el propio MikroTik si está disponible en esa versión.
Una opción sencilla es utilizar un script externo desde una máquina Ubuntu:
nc -zv 192.168.88.10 80Si Apache está funcionando:
succeededSi está parado:
failedPráctica 5. Failover
Esta práctica es especialmente interesante.
Tendremos:
MikroTik
│
┌──────┴──────┐
│ │
WEB 1 WEB 2
PRINCIPAL RESERVA
Mientras WEB1 funcione:
Cliente → WEB1Si WEB1 falla:
Cliente → WEB21. Preparar los servidores
WEB1:
192.168.88.10WEB2:
192.168.88.11Ambos deben tener Apache.
2. Detener WEB1
sudo systemctl stop apache2Comprobar:
sudo systemctl status apache23. Comprobar desde el cliente
curl http://192.168.88.10Ya no debería responder.
WEB2:
curl http://192.168.88.11Debe seguir funcionando.
4. Recuperar WEB1
sudo systemctl start apache2Comprobar:
sudo systemctl status apache25. Automatización del failover
Para una primera práctica, recomiendo que el alumno no intente automatizar todo el balanceador desde el principio.
Primero debe entender:
Servidor activo
↓
Fallo
↓
Detección
↓
Servidor alternativo
↓
RecuperaciónDespués se puede añadir un script que habilite/deshabilite reglas NAT.
Por ejemplo, podemos identificar las reglas:
/ip firewall nat printy posteriormente modificar su estado:
/ip firewall nat disable [find comment="NAT hacia WEB1"]Activarla:
/ip firewall nat enable [find comment="NAT hacia WEB1"]WEB2:
/ip firewall nat disable [find comment="NAT hacia WEB2"]/ip firewall nat enable [find comment="NAT hacia WEB2"]Esto permite realizar una práctica sencilla de failover manual antes de automatizarlo.
Práctica 6. Virtualización de servidores
Esta práctica no necesita una configuración especial del MikroTik.
El objetivo es utilizar máquinas virtuales para simular varios servidores físicos.
La infraestructura:
ORDENADOR
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
VM 1 VM 2 VM 3
WEB 1 WEB 2 CLIENTE
.10 .11
│ │
└──────┬──────┘
│
MikroTik
VM1
Ubuntu Server
192.168.88.10
ApacheVM2
Ubuntu Server
192.168.88.11
ApacheVM3
Ubuntu Desktop
DHCPConfiguración de red de las VM
En VirtualBox, por ejemplo, podemos utilizar:
Adaptador de red:
Adaptador puenteDe esta forma las máquinas virtuales estarán directamente en:
192.168.88.0/24y podrán comunicarse con el MikroTik.
Otra posibilidad es utilizar una red interna, pero para empezar recomiendo adaptador puente, porque es mucho más fácil de entender.
Práctica 7. Almacenamiento compartido con NFS
Esta práctica permite introducir:
- Almacenamiento compartido.
- Sistemas de archivos.
- Servidores redundantes.
Topología:
MikroTik
│
│
┌──────┴──────┐
│ │
WEB1 WEB2
│ │
└──────┬──────┘
│
▼
NFS SERVER
192.168.88.30
1. Crear servidor NFS
Ubuntu:
192.168.88.30Instalar:
sudo apt update
sudo apt install nfs-kernel-serverCrear directorio:
sudo mkdir -p /srv/webdataCrear archivo:
sudo nano /srv/webdata/index.htmlContenido:
<h1>Contenido almacenado en NFS</h1>
<p>Servidor de almacenamiento compartido.</p>2. Configurar NFS
Editar:
sudo nano /etc/exportsAñadir:
/srv/webdata 192.168.88.0/24(rw,sync,no_subtree_check)Aplicar:
sudo exportfs -aReiniciar:
sudo systemctl restart nfs-serverComprobar:
sudo exportfs -v3. Montar desde WEB1
En WEB1:
sudo apt install nfs-commonCrear directorio:
sudo mkdir -p /var/www/htmlMontar:
sudo mount 192.168.88.30:/srv/webdata /var/www/htmlComprobar:
df -h4. Montar desde WEB2
En WEB2:
sudo apt install nfs-commonMontar:
sudo mount 192.168.88.30:/srv/webdata /var/www/htmlAhora:
WEB1 ───────┐
│
▼
NFS SERVER
▲
│
WEB2 ───────┘Ambos servidores utilizan el mismo contenido.
5. Comprobar el almacenamiento compartido
Modificar desde NFS:
sudo nano /srv/webdata/index.htmlPor ejemplo:
<h1>Servidor web de alta disponibilidad</h1>
<p>Contenido almacenado en NFS.</p>Actualizar el navegador.
El contenido será accesible desde ambos servidores.
Práctica 8. Integridad y recuperación de datos
Ahora podemos simular un problema en el servidor de almacenamiento.
Primero comprobar:
ls -l /srv/webdataDespués:
sudo systemctl stop nfs-serverIntentar acceder desde WEB1 y WEB2.
Después recuperar:
sudo systemctl start nfs-serverComprobar:
sudo systemctl status nfs-serverPráctica 9. Pruebas de carga
Esta práctica encaja perfectamente con el apartado de cargas sintéticas.
Utilizaremos Apache Benchmark.
En un Ubuntu cliente:
sudo apt update
sudo apt install apache2-utils1. Primera prueba
Probar WEB1:
ab -n 1000 -c 10 http://192.168.88.10/Tenemos:
1000 peticiones
10 conexiones simultáneas2. Aumentar la carga
ab -n 5000 -c 50 http://192.168.88.10/Después:
ab -n 10000 -c 100 http://192.168.88.10/3. Analizar los resultados
Apache Benchmark proporciona información como:
Time taken for tests
Requests per second
Time per request
Transfer rate
Failed requestsLos alumnos deberán registrar los resultados.
Práctica 10. Comparar un servidor frente a dos servidores
Ahora podemos aprovechar el balanceador.
Tenemos:
CLIENTE
│
▼
192.168.88.100
│
MikroTik
/ \
/ \
▼ ▼
WEB1 WEB2
.10 .11
Realizar:
ab -n 5000 -c 50 http://192.168.88.100/Después:
ab -n 10000 -c 100 http://192.168.88.100/Consultar en MikroTik:
/ip firewall mangle print statsY:
/ip firewall nat print statsPráctica 11. Simular la caída de un servidor
Esta será la práctica final.
Estado inicial:
MikroTik
│
192.168.88.100
│
┌──────┴──────┐
│ │
WEB1 WEB2
.10 .11
│ │
ACTIVO ACTIVO
Realizar:
curl http://192.168.88.100Varias veces.
Después detener WEB1:
sudo systemctl stop apache2Comprobar:
sudo systemctl status apache2Realizar de nuevo:
curl http://192.168.88.100Analizar qué sucede.
Después recuperar:
sudo systemctl start apache2Comandos completos del MikroTik
Esta sería la parte que puedes entregar como chuleta de comandos.
Consultar interfaces
/interface printConsultar IP
/ip address printConsultar rutas
/ip route printConsultar DHCP
/ip dhcp-server lease printIP virtual para el balanceador
/ip address add address=192.168.88.100/24 interface=bridgeLocal comment="IP virtual balanceador"PCC
/ip firewall mangle
add chain=prerouting dst-address=192.168.88.100 protocol=tcp dst-port=80 \
per-connection-classifier=both-addresses-and-ports:2/0 \
action=mark-connection new-connection-mark=WEB1 passthrough=yes \
comment="Balance WEB1"/ip firewall mangle
add chain=prerouting dst-address=192.168.88.100 protocol=tcp dst-port=80 \
per-connection-classifier=both-addresses-and-ports:2/1 \
action=mark-connection new-connection-mark=WEB2 passthrough=yes \
comment="Balance WEB2"NAT hacia WEB1
/ip firewall nat
add chain=dstnat dst-address=192.168.88.100 protocol=tcp dst-port=80 \
connection-mark=WEB1 action=dst-nat \
to-addresses=192.168.88.10 to-ports=80 \
comment="NAT hacia WEB1"NAT hacia WEB2
/ip firewall nat
add chain=dstnat dst-address=192.168.88.100 protocol=tcp dst-port=80 \
connection-mark=WEB2 action=dst-nat \
to-addresses=192.168.88.11 to-ports=80 \
comment="NAT hacia WEB2"Ver las reglas
/ip firewall mangle print/ip firewall nat printVer estadísticas
/ip firewall mangle print stats/ip firewall nat print statsVer conexiones
/ip firewall connection printComprobar servidores
/ping 192.168.88.10/ping 192.168.88.11Crear script de comprobación
/system script
add name=check-web1 source={
:local result [/ping 192.168.88.10 count=3]
:if ($result = 0) do={
:log warning "WEB1 NO DISPONIBLE"
} else={
:log info "WEB1 DISPONIBLE"
}
}Ejecutar:
/system script run check-web1Programar comprobación
/system scheduler
add name=monitor-web1 interval=1m on-event=check-web1Consultar:
/system scheduler printConsultar logs
/log printComandos de Ubuntu
Instalar Apache
sudo apt update
sudo apt install apache2Estado de Apache
sudo systemctl status apache2Parar Apache
sudo systemctl stop apache2Iniciar Apache
sudo systemctl start apache2Reiniciar Apache
sudo systemctl restart apache2Comprobar el puerto 80
sudo ss -lntp | grep :80Probar WEB1
curl http://192.168.88.10Probar WEB2
curl http://192.168.88.11Probar balanceador
curl http://192.168.88.100Comandos para pruebas de carga
Instalar:
sudo apt install apache2-utilsPrueba pequeña:
ab -n 1000 -c 10 http://192.168.88.100/Prueba media:
ab -n 5000 -c 50 http://192.168.88.100/Prueba alta:
ab -n 10000 -c 100 http://192.168.88.100/Comandos para NFS
Servidor
sudo apt install nfs-kernel-serversudo mkdir -p /srv/webdataEditar:
sudo nano /etc/exportsAñadir:
/srv/webdata 192.168.88.0/24(rw,sync,no_subtree_check)Aplicar:
sudo exportfs -aReiniciar:
sudo systemctl restart nfs-serverComprobar:
sudo exportfs -vClientes
sudo apt install nfs-commonsudo mkdir -p /var/www/htmlsudo mount 192.168.88.30:/srv/webdata /var/www/htmlComprobar:
df -hOrden recomendado para realizar las prácticas
No las haría todas de golpe. La progresión sería:
01
Punto único de fallo
↓
02
Dos servidores web
↓
03
Balanceo con MikroTik
↓
04
Monitorización
↓
05
Failover
↓
06
Virtualización
↓
07
Almacenamiento NFS
↓
08
Recuperación de datos
↓
09
Pruebas de carga
↓
10
Balanceo + carga
↓
11
Simulación de falloCon este planteamiento se cubren prácticamente todos los apartados del bloque: alta disponibilidad, funcionamiento ininterrumpido, balanceadores, servidores redundantes, almacenamiento compartido, recuperación de servicio, virtualización, simulación de servicios y pruebas de carga.
Una precisión importante: el balanceo PCC del MikroTik es una práctica didáctica de distribución de conexiones, no sustituye a un balanceador HTTP dedicado como HAProxy o Nginx. Para una práctica introductoria está muy bien porque permite ver físicamente cómo el MikroTik distribuye las conexiones entre dos servidores; posteriormente se puede hacer una segunda versión con HAProxy en Ubuntu, que sería más apropiada para estudiar alta disponibilidad de servicios web de forma profesional.