MySQL en Debian 13.4 — Clúster de Alta Disponibilidad con DRBD y Replicación Nativa
Objetivos del Laboratorio Objetivo general: Implementar un clúster de alta disponibilidad de MySQL 8.0 en Debian 13.4 utilizando DRBD para replicación de almacenamiento a nivel de bloque y configurando simultáneamente la replicación nativa de MySQL (Primary‑Replica). El entorno final constará de dos nodos (nodo‑a y nodo‑b) capaces de garantizar continuidad del servicio de base de datos, replicación síncrona de almacenamiento y sincronización a nivel de transacciones SQL. Objetivos específicos: # Objetivo Alcance 1 Comprender qué es MySQL Definición, características clave, modelo relacional 2 Identificar la estructura de archivos de MySQL datadir, InnoDB, logs, socket, configuración 3 Instalar MySQL 8.0 en Debian 13.4 Repositorio oficial Oracle, configuración segura 4 Integrar MySQL en clúster HA DRBD + Pacemaker/Corosync, datadir sobre volumen replicado 5 Configurar replicación nativa MySQL Primary‑Replica, usuario de replicación, binlog, verificación 6 Validar y documentar pruebas Failover, integridad de datos, problemas comunes Nota sobre las referencias del laboratorio previo: Las prácticas publicadas en dsantana.uas.edu.mx —sobre implementación de clúster HA, DRBD en Debian 13.4 y clúster de alta disponibilidad en Debian 13— no pudieron consultarse directamente durante la investigación. La presente guía se construye sobre documentación oficial de MySQL (Oracle), guías técnicas verificadas de instalación en Debian, y referencias de configuración de Pacemaker/Corosync/DRBD, alineándose con los principios y arquitectura descritos en dichas prácticas previas. 1. ¿Qué es MySQL? MySQL es un sistema de gestión de bases de datos relacionales (RDBMS) de código abierto que se utiliza para almacenar y gestionar datos. Su fiabilidad, rendimiento, escalabilidad y facilidad de uso lo han convertido en una opción popular para desarrolladores en aplicaciones de alto tráfico como Facebook, Netflix, Uber, Airbnb, Shopify y Booking.com. En 2024, MySQL se clasifica como la segunda base de datos más popular en general, solo superada por Oracle Database según DB‑Engines, y es el RDBMS de código abierto más popular del mundo. MySQL utiliza el lenguaje SQL (Structured Query Language) para recuperar, actualizar, suprimir y manipular datos en bases de datos relacionales. Se pronuncia oficialmente «My es‑kiu‑el». Como base de datos relacional, almacena datos en tablas de filas y columnas organizadas en esquemas, donde un esquema define cómo se organizan y almacenan los datos y describe la relación entre varias tablas. Recientemente, Oracle ha añadido soporte para el tipo de datos JSON y vectores, ampliando su versatilidad. Características fundamentales: 2. Estructura del Sistema de Archivos y Componentes de MySQL 2.1 Directorio de datos (datadir) El datadir es la carpeta principal donde el servidor MySQL almacena todos los archivos relacionados con las bases de datos. En instalaciones desde repositorios (apt, yum) en Linux, la ubicación más común es /var/lib/mysql/. Este valor está definido por la variable del sistema data_dir, cuyo valor por defecto es /var/lib/mysql. Para consultar el datadir activo, puede ejecutarse dentro de MySQL la sentencia SHOW VARIABLES LIKE ‘datadir’;. Dentro del datadir se encuentra: 2.2 Motor de almacenamiento InnoDB InnoDB es el motor de almacenamiento predeterminado en MySQL 8.0 y actúa como la capa intermedia entre el almacenamiento y el servidor MySQL, almacenando los datos en las unidades de disco. Su funcionamiento de E/S se clasifica en dos tipos: I/O de archivo aleatorio (archivos de datos) y E/S de archivo secuencial (registros de recuperación y binarios). Componentes clave de InnoDB en el datadir: Componente Descripción Espacio de tablas compartido (ibdata1) Contiene metadatos de InnoDB y datos de tablas que no usan file‑per‑table. Con innodb_file_per_table activado (predeterminado en MySQL 8), cada tabla se almacena en archivos .ibd independientes. Logs de recuperación (redo logs) Registros transaccionales escritos secuencialmente para garantizar la recuperación tras fallos. Buffer de doble escritura InnoDB escribe páginas primero en un buffer y luego en sus posiciones correctas en los archivos de datos, evitando la corrupción de páginas si se produce un fallo de alimentación durante la escritura. Buffer de inserción Reduce operaciones de E/S aleatorias fusionando escrituras en índices secundarios no únicos. Segmentos de deshacer (undo) Registran imágenes anteriores de los datos para la concurrencia multiversión (MVCC). 2.3 Archivos de registro (logs) MySQL dispone de cuatro tipos principales de archivos de log: Tipo de log Descripción Ruta típica (Debian) Activado por defecto Registro de errores Registra problemas al iniciar, ejecutar o parar mysqld /var/log/mysql/error.log Sí Registro de consultas generales Registra todas las conexiones y sentencias ejecutadas datadir/<hostname>.log No Registro binario (binlog) Registra todas las sentencias que cambian datos; utilizado en la replicación datadir/mysql-bin.* (si se activa log_bin) No Registro de consultas lentas Registra sentencias que exceden el tiempo definido por long_query_time (predeterminado: 10 segundos) datadir/<hostname>-slow.log No Por defecto, todos los archivos de log se crean en el directorio de datos, aunque distribuciones Debian/Ubuntu suelen redirigir el log de errores a /var/log/mysql/error.log mediante la variable log_error. El registro binario merece atención especial para este laboratorio: es la base de la replicación nativa de MySQL. Debe habilitarse configurando log_bin en el archivo de configuración. Cada archivo binlog se escribe secuencialmente y contiene las operaciones de escritura (INSERT, UPDATE, DELETE). Los binlogs cumplen tres funciones principales: restauración punto en el tiempo, replicación entre servidores, y auditoría de seguridad. 2.4 Archivo de socket Unix El archivo mysqld.sock es un punto final de comunicación que permite que el servidor MySQL y las aplicaciones cliente en la misma máquina se comuniquen de manera local sin pasar por la red TCP/IP. En sistemas Debian/Ubuntu, este socket se encuentra normalmente en /var/run/mysqld/mysqld.sock. Se configura mediante la directiva socket en el archivo my.cnf. 2.5 Archivo PID y archivo de configuración 2.6 Parámetros de configuración relevantes Los parámetros de MySQL se dividen en dinámicos (modificables en tiempo de ejecución con SET) y estáticos (requieren reinicio del servicio). Algunos parámetros clave: Parámetro Tipo Descripción innodb_buffer_pool_size Estático Tamaño del buffer de datos/índices InnoDB en memoria log_bin Estático Activa registro binario para replicación server_id Estático Identificador único del servidor en topología de replicación bind-address Estático Dirección IP en la que MySQL escucha conexiones sync_binlog Dinámico Frecuencia de sincronización del binlog al disco; 1 = máxima seguridad 2.7 Permisos y AppArmor MySQL ejecuta bajo el usuario del sistema mysql. Todos los archivos del datadir deben pertenecer a mysql:mysql. En
Práctica: Clúster de Alta Disponibilidad en Debian 13
Descripción general: En esta práctica crearemos un clúster de alta disponibilidad (HA) de dos nodos en modo activo/pasivo usando Pacemaker (gestor de recursos de clúster) y Corosync (servicio de comunicación entre nodos) sobre Debian 13. El objetivo es que un recurso (una dirección IP virtual) esté siempre disponible: si el Nodo A falla, el Nodo B tomará automáticamente el control, minimizando la interrupción del servicio (failover). Configuraremos la IP virtual 192.168.1.100 que «flotará» entre los nodos, de modo que los clientes se conecten siempre a esa dirección sin importar qué servidor físico la esté atendiendo. Se trata de configurar un clúster de alta disponibilidad activo/pasivo en el que uno de los dos equipos pueda responder siempre a la dirección IP que se pretende mantener en alta disponibilidad. Escenario del laboratorio: Elemento Nodo A Nodo B Hostname nodo-a nodo-b IP fija 192.168.1.10 192.168.1.11 IP virtual (VIP) 192.168.1.100 (la asume cuando A falla) SO Debian 13 mínimo Debian 13 mínimo Conceptos clave: Antes de empezar, repasemos los términos esenciales que se usan a lo largo de la práctica: A continuación se detalla paso a paso la configuración, explicando qué hace cada comando, por qué es necesario y qué ocurre internamente en el clúster. Cada paso incluye verificaciones, posibles errores comunes y cómo identificarlos. Al final se proponen preguntas de análisis y criterios de evaluación. Paso 1: Preparación de los Nodos (hostname, /etc/hosts, actualización) Qué se hace: En cada servidor asignamos nombres de host descriptivos, aseguramos la resolución de nombres entre ellos y actualizamos el sistema operativo. 1.1 Cambiar el hostname En Nodo A: hostnamectl set-hostname nodo-a En Nodo B: hostnamectl set-hostname nodo-b Esto define el nombre de máquina a nivel del sistema (reflejado en uname -n y hostname). Los nombres de host deben coincidir exactamente con los que usaremos en la configuración del clúster. Pacemaker y Corosync no usan el prompt de la terminal ni apodos; identifican los nodos por su hostname real del SO. Si hay discrepancia (por ejemplo, el hostname del sistema es debian-01 pero en la configuración del clúster se escribe nodo-a), el clúster no reconocerá correctamente a los nodos, provocando errores de autenticación y conectividad. En un entorno de clúster, para cambiar el nombre de una máquina se puede ejecutar hostnamectl set-hostname nombre_nuevo. [blogsaverr…dalucia.es] 1.2 Editar /etc/hosts En ambos nodos, abrir /etc/hosts: nano /etc/hosts Y añadir las siguientes entradas: De esta manera, cada nodo puede resolver el nombre del otro por IP. Esto es fundamental porque pcs y Corosync utilizarán los nombres (nodo-a, nodo-b) para establecer la comunicación. Sin resolución correcta, los comandos de autenticación o arranque de clúster fallarán al no poder encontrar el host destino. El blog de maquinasvirtuales.eu muestra un ejemplo de /etc/hosts configurado para un clúster Pacemaker, donde cada nodo tiene su IP y nombre mapeados correctamente. 1.3 Actualizar el sistema En ambos nodos: apt update && apt upgrade -y Mantener Debian actualizado garantiza versiones compatibles de Pacemaker, Corosync y PCS. Tras una actualización que incluya kernel nuevo, es recomendable reiniciar los nodos antes de continuar. Verificación: Errores comunes: Problema Síntoma / Mensaje Solución Hostname no cambiado pcs indica «no configuration for host X» o el nombre no aparece en pcs status. Verificar con uname -n. Si no coincide, reejecutar hostnamectl set-hostname y reiniciar la sesión. Resolución de nombres fallida pcs host auth se cuelga o muestra error de conexión/refused hacia nodo-b. Verificar las entradas en /etc/hosts de ambos nodos. Probar ping nodo-b desde nodo-a. Firewall bloquea puertos de clúster Un nodo aparece OFFLINE en pcs status tras configurar el clúster. Asegurar que el firewall permite tráfico UDP 5404/5405 (puertos estándar de Corosync). En laboratorio, ufw disable o abrir reglas específicas. Paso 2: Instalación del Stack de Clúster (Pacemaker, Corosync, PCS) Qué se hace: Se instalan en ambos nodos los tres componentes del stack de HA: apt install -y pacemaker corosync pcs Este comando instala: [linuxmind.dev] Tras la instalación, habilitamos y arrancamos PCSD en cada nodo: systemctl enable pcsd systemctl start pcsd pcsd escucha en cada nodo y permite que, al autenticarse, podamos ejecutar comandos de configuración del clúster en todos los nodos desde uno solo. Por qué se hace: Pacemaker y Corosync forman el motor del clúster HA. Sin Pacemaker no habría orquestación de recursos; sin Corosync no habría detección de fallos entre nodos. La herramienta pcs simplifica enormemente la configuración, evitando la edición manual de archivos XML o configuración de Corosync; además, distribuye automáticamente las claves de autenticación a todos los nodos. Habilitar pcsd lo hace persistente tras reinicios. Internamente: Componentes internos de Pacemaker que conviene conocer: Verificación: Errores comunes: Problema Síntoma / Mensaje Solución Repositorios faltantes apt no encuentra paquetes pacemaker o pcs. Asegurarse de tener los repositorios de Debian 13 correctos en /etc/apt/sources.list. Permisos insuficientes Error de permisos al instalar. Ejecutar como root o con sudo. pcsd no habilitado Al intentar autenticación, pcs responde «Error: unable to connect to node…». Verificar que pcsd está activo en ambos nodos (systemctl status pcsd). Iniciar/habilitar si es necesario. Versiones distintas entre nodos Errores de protocolo o incompatibilidad durante la autenticación. Usar la misma versión de paquetes en ambos nodos (mismo SO y actualizaciones). Paso 3: Autenticación del Clúster (usuario hacluster y pcs host auth) Qué se hace: Para que pcs pueda controlar ambos nodos de forma remota, se usa un usuario dedicado llamado hacluster (creado automáticamente al instalar pcs). Se realizan dos tareas: 3.1 Asignar contraseña al usuario hacluster En cada nodo (ambos): passwd hacluster Elegir una contraseña (se recomienda la misma en ambos para simplificar el proceso de autenticación). Este usuario es el que pcs utiliza internamente para autenticarse contra los nodos del clúster. 3.2 Autenticación entre nodos Desde nodo-a: pcs host auth nodo-a nodo-b Este comando establece la confianza mutua entre nodo-a y nodo-b. pcs solicita las credenciales del usuario hacluster y las usa para crear una relación de confianza segura entre ambos nodos. Si pide confirmación de huella digital (fingerprint), aceptar con «yes». Por qué se hace: Sin autenticación, pcs solo puede administrar el nodo local. Este paso habilita
Práctica DRBD en Debian 13.4: Replicación de Volumen Paso a Paso
Contexto: Esta práctica configura DRBD (Distributed Replicated Block Device) en dos nodos (denominados nodo-a y nodo-b) con Debian 13.4, para replicar un volumen de datos entre ambos en tiempo real. Cada nodo cuenta con una partición adicional (p.ej. /dev/sdb1) de tamaño idéntico destinada a DRBD. El objetivo es lograr un «RAID-1 de red»: cualquier cambio en el nodo Primario se replicará al Secundario de forma continua, manteniendo ambas copias sincronizadas. DRBD es un módulo del kernel de Linux que se ubica entre el planificador de I/O (parte inferior) y el sistema de archivos (parte superior), actuando como controlador de un dispositivo de bloque virtual. Esto significa que las aplicaciones leen y escriben datos sin saber que, en la capa de bloques, esos datos están siendo duplicados por red en otro servidor — la replicación es transparente para ellas. A continuación se explica cada paso en detalle, indicando qué se hace, por qué se hace y qué ocurre internamente en la pila de I/O de Linux (aplicación → sistema de archivos → dispositivo DRBD → disco → red), junto con verificaciones, advertencias y errores comunes. Paso 1: Instalación de DRBD en ambos nodos Qué se hace: Se instala el paquete de utilidades de DRBD en los dos servidores. En Debian, el paquete se denomina drbd-utils y contiene las herramientas de espacio de usuario (drbdadm, drbdsetup, drbdmeta) necesarias para configurar y manejar DRBD. En Debian, la porción de módulo de DRBD se distribuye con los kernels de Debian, por lo que instalar drbd-utils generalmente es suficiente sin compilar nada adicional. El comando es: Esto se ejecuta en nodo-a y nodo-b. La opción -y auto-confirma la instalación. Se instalan las herramientas de administración que se comunican con el módulo del kernel para configurar y administrar los recursos DRBD. Por qué se hace: DRBD tiene dos componentes: un módulo en el kernel (el driver de bloque replicado, con número mayor de dispositivo 147) y herramientas en user-space para su administración. Sin instalar drbd-utils, no tendríamos los comandos necesarios para crear metadatos, levantar recursos ni monitorear el estado de la replicación. Internamente (capa afectada): Aquí solo añadimos software; aún no cambia nada en la pila de I/O. Tras la instalación, el módulo kernel estará disponible para cargarse al usarlo más adelante, y las herramientas de administración quedarán listas. Verificación: Errores comunes: Problema Síntoma Solución Repositorios o red apt falla al descargar paquetes Verificar conexión a internet y que /etc/apt/sources.list tenga repositorios válidos Permisos insuficientes Error de permisos al instalar Ejecutar como root o con sudo Módulo kernel ausente (entorno virtual) modprobe drbd falla con «Module not found» En kernels virtuales, instalar linux-modules-extra-$(uname -r) Versiones distintas entre nodos Error de protocolo al conectar nodos Asegurar que ambos nodos tengan la misma versión de drbd-utils Paso 2: Preparación del disco o partición en cada nodo Qué se hace: Se designa un dispositivo de bloque dedicado en cada servidor para la replicación. En producción se suele usar un disco entero; en laboratorio, una partición (p.ej. /dev/sdb1). Es fundamental que esta partición: (a) tenga el mismo tamaño en ambos nodos, y (b)no esté montada ni en /etc/fstab. La verificación se realiza con: Este comando lista los dispositivos de bloque. Debe confirmarse que /dev/sdb1 existe en ambos nodos, que no tenga punto de montaje asignado y que su tamaño sea idéntico. Por qué se hace: DRBD replica bloques de datos crudos. Necesitamos almacenamiento dedicado que DRBD controlará exclusivamente. Ambas particiones deben ser de tamaño idéntico para que la réplica funcione correctamente. DRBD soporta cualquier dispositivo de bloque soportado por Linux: partición o disco duro completo, RAID por software, LVM o EVMS. Internamente (capa afectada): Solo preparamos la capa de almacenamiento físico (el nivel más bajo de la pila I/O). No hemos configurado DRBD ni hay tráfico de red aún. Verificación: Errores comunes: Problema Síntoma Solución Partición montada drbdadm create-md falla al bloquear dispositivo Desmontar con umount y verificar que ningún proceso la use (lsof /dev/sdb1) Tamaño inconsistente DRBD ajusta al menor, dejando espacio desperdiciado Reparticionar al mismo tamaño antes de continuar Confundir disco y partición Apuntar a /dev/sdb cuando debe ser /dev/sdb1 Verificar con lsblk y usar exactamente la ruta que aparece en la configuración Datos previos en la partición Advertencia de destrucción de datos al inicializar Si los datos no son necesarios, confirmar; si lo son, respaldarlos primero Paso 3: Configuración básica del recurso DRBD (/etc/drbd.d/web.res) Qué se hace: Se crea un archivo de configuración que define el recurso DRBD (el nombre lógico de la pareja de discos replicados). El archivo /etc/drbd.d/web.res debe ser idéntico en ambos nodosy contiene: Explicación línea por línea Comparativa rápida de protocolos: Protocolo Tipo Confirmación de escritura Riesgo ante fallo del Primary A (Asíncrono) Tras disco local + paquete en buffer TCP Posible pérdida de las actualizaciones más recientes B (Semisíncrono) Tras disco local + recepción en memoria remota Datos normalmente seguros; riesgo si ambos nodos fallan simultáneamente C (Síncrono) ✅ Tras disco local + disco remoto Cero pérdida de datos Por qué se hace: Esta configuración define cómo se conectará y comportará el recurso replicado: qué disco local usar, a qué compañero conectarse por red, con qué garantías de sincronización y dónde guardar los metadatos internos. Internamente (capa afectada): Solo se modifica la capa de configuración (espacio de usuario). Todavía no se han creado dispositivos ni comunicaciones de red. Estamos preparando la «hoja de ruta» que DRBD seguirá. Verificación: Errores comunes / Advertencias: Problema Síntoma Solución Error de sintaxis en .res drbdadm indica número de línea con error Revisar corchetes, puntos y coma, y ortografía Nombre de host incorrecto «No valid configuration found for this host» uname -n debe coincidir con la sección on <nombre> en el archivo Archivo no copiado al segundo nodo Segundo nodo queda en StandAlone, no reconoce recurso Copiar con scp el archivo .res al otro nodo Puerto bloqueado por firewall Los nodos no conectan (cs:Timeout) Abrir el puerto TCP configurado en ambos nodos Paso 4: Inicializar el recurso DRBD en ambos nodos (metadatos y arranque) Se ejecutan
Implementación de un Clúster de Alta Disponibilidad con Replicación de Datos en Tiempo Real
DRBD (Dispositivo de Bloque Replicado Distribuido): Arquitectura y Funcionamiento Técnico DRBD (Distributed Replicated Block Device) es una solución de almacenamiento replicado basada en software, de tipo shared-nothing, que refleja el contenido de dispositivos de bloque (discos duros, particiones, volúmenes lógicos, etc.) entre hosts. Funciona como un RAID-1 por red: replica datos en tiempo real de forma continua mientras las aplicaciones los modifican, de manera transparente (las aplicaciones no necesitan saber que los datos están en múltiples hosts), y de forma síncrona o asíncrona según la configuración elegida. Es una tecnología ampliamente utilizada para implementar alta disponibilidad (HA) en Linux: si un servidor falla, el otro posee una réplica actualizada de los datos para continuar operando. DRBD es software de código abierto, disponible en la plataforma Linux. Dado que la imagen de referencia mencionada no está disponible para su análisis directo, la siguiente explicación describe la arquitectura típica que aparece en diagramas estándares de DRBD, explicitando las suposiciones realizadas. 1. Arquitectura por Capas de DRBD (Pila de I/O Linux) DRBD es un módulo del kernel de Linux que se ubica entre el planificador de I/O (capa inferior) y el sistema de archivos (capa superior). Específicamente, constituye un controlador para un dispositivo de bloque virtual, posicionándose cerca de la parte inferior de la pila de I/O del sistema. La guía oficial de DRBD 9 hace referencia a esta disposición en su «Figura 1: Posición de DRBD dentro de la pila de I/O de Linux». [linuxparty.es][linbit.com] La pila, de arriba hacia abajo, se organiza así: DRBD es, por definición y por mandato de la arquitectura del kernel de Linux, agnóstico de las capas superiores. No puede agregar mágicamente funcionalidades que las capas superiores no posean; por ejemplo, no puede auto-detectar corrupción del sistema de archivos ni agregar capacidad de clúster activo-activo a sistemas de archivos como ext3 o XFS que no la soportan nativamente. Metadatos de DRBD: DRBD almacena metadatos internos en cada nodo. Cuando se usa la opción meta-disk internal (lo más habitual), estos metadatos se reservan en la parte final del dispositivo de bloque subyacente. Por ejemplo, si el dispositivo crudo tiene 1024 MB, el dispositivo DRBD dispondrá de solo 1023 MB para datos del usuario, con aproximadamente 70 KB reservados para metadatos. Es fundamental que toda manipulación de datos se haga sobre /dev/drbdX y no sobre el dispositivo crudo, ya que acceder al dispositivo directamente causará inconsistencias. Herramientas de administración en espacio de usuario: DRBD incluye tres herramientas que se comunican con el módulo del kernel para configurar y administrar los recursos, de mayor a menor nivel: Herramienta Nivel Función drbdadm Alto Herramienta principal. Obtiene parámetros de /etc/drbd.conf y actúa como front-end para drbdsetup y drbdmeta. Soporta modo dry-run con la opción -d. drbdsetup Bajo Configura directamente el módulo DRBD cargado en el kernel. Todos los parámetros se pasan por línea de comandos. Rara vez se usa directamente. drbdmeta Bajo Permite crear, volcar, restaurar y modificar estructuras de metadatos DRBD. También de uso infrecuente para la mayoría de los usuarios. 2. Topología Típica: Dos Nodos con Replicación por Red Los despliegues estándares de DRBD constan de dos servidores (Nodo A y Nodo B) conectados por red. Un diagrama de referencia típico (como la «Ilustración técnica y educativa» presente en los materiales de clase) muestra un clúster activo/pasivo en Linux con dos servidores: el Nodo A (activo) ejecutando Apache con una IP virtual (VIP) visible a los clientes, y el Nodo B (pasivo) en espera. Ambos nodos aparecen conectados por enlaces que representan Pacemaker, Corosync y DRBD, mostrando replicación en tiempo real del directorio /var/www/html. El diagrama ilustra además un evento de failover donde la IP virtual y el servicio Apache se mueven automáticamente del Nodo A al Nodo B cuando el Nodo A falla. En esta disposición shared-nothing: Tráfico de red no cifrado: La documentación oficial de SUSE advierte que el tráfico de datos entre espejos DRBD no está cifrado. Para un intercambio seguro de datos, se recomienda implementar una VPN sobre la conexión de replicación. DRBD permite usar cualquier dispositivo de bloque soportado por Linux como almacenamiento subyacente: partición o disco duro completo, RAID por software, LVM o EVMS. 3. Flujo de I/O: Escrituras y Lecturas Flujo de escritura (modo single-primary) Flujo de lectura Toda la I/O de lectura se ejecuta localmente en el nodo primario, accediendo directamente al disco local sin añadir latencia de red, a menos que se configure balanceo de lectura (read-balancing), una opción avanzada donde el primario podría leer también desde el secundario vía red para distribuir carga. Esta opción no es habitual en configuraciones estándar. El nodo secundario no atiende lecturas porque no tiene aplicaciones activas ni un sistema de archivos montado. Flujo en modo dual-primary En configuración activo-activo, ambos nodos pueden originar escrituras; cada escritura local en un nodo se replica al otro. Las lecturas son atendidas localmente por cada nodo para sus propias aplicaciones. Un sistema de archivos de disco compartido (GFS2, OCFS2) junto con un gestor de bloqueos distribuido coordina la coherencia de acceso concurrente. Este modo de operación requiere latencias de red muy bajas y coordinación precisa. 4. Modos de Replicación: Protocolo A, B y C DRBD soporta tres protocolos de replicación que representan tres grados distintos de sincronía. La elección influye en dos factores del despliegue: protección (de datos ante fallo) y latencia (percibida por la aplicación). El rendimiento (throughput), por el contrario, es en gran medida independiente del protocolo seleccionado. Protocolo A — Replicación asíncrona Las operaciones de escritura locales en el nodo primario se consideran completadas tan pronto como la escritura en disco local ha terminado y el paquete de replicación ha sido colocado en el buffer TCP de envío local. En caso de un failover forzado, puede ocurrir pérdida de datos: los datos en el nodo en espera son consistentes después del failover, pero las actualizaciones más recientes realizadas antes del failover podrían perderse. El Protocolo A se usa con mayor frecuencia en escenarios de replicación a larga distancia. Protocolo B — Replicación semisíncrona («síncrono
🌐 Configuración de un Servidor NTPSEC en Debian 13
🌐 Configuración de un Servidor NTPSEC en Debian 13 🔒 NETSEC – Sincronización Horaria Profesional 👨🏫 Docente: José David Santana Alaniz 📍 Zona horaria: America/Mazatlan 📖 OBJETIVO DE LA PRÁCTICA Configurar un servidor NTPSEC seguro y funcional para proporcionar sincronización de tiempo a la red NETSEC, cumpliendo estándares profesionales de administración de sistemas. 🧠 MARCO TEÓRICO 🛠️ PROCEDIMIENTO COMPLETO 1️⃣ Actualización del sistema 2️⃣ Instalación de NTPSEC 3️⃣ Configuración de la zona horaria 4️⃣ Edición del archivo /etc/ntpsec/ntp.conf 5️⃣ Activación del servicio 6️⃣ Verificación 🧪 RESULTADOS ✔️ CONCLUSIONES La sincronización horaria es esencial para mantener coherencia en sistemas distribuidos. NTPSEC, al ser más seguro que NTP tradicional, garantiza una operación confiable y robusta en entornos educativos y profesionales.
🧰 Herramientas Físicas de Red: ¿Qué Son y Para Qué Sirven?
En el ámbito de las telecomunicaciones y redes informáticas, las herramientas físicas son esenciales para la instalación, mantenimiento y diagnóstico de redes cableadas. A continuación, se describen las herramientas más utilizadas por técnicos y profesionales de redes: 🔧 1. Crimpadora (Ponchadora de Red) 🧪 2. Tester de Cables (Cable Tester) ✂️ 3. Pelacables 🔌 4. Conectores RJ45 🌐 5. Cable Ethernet 📚 Referencias
🧭 Acceso y Uso de Zenmap para Visualización Gráfica
🎯 ¿Qué es Zenmap? Zenmap es la interfaz gráfica oficial de Nmap, diseñada para facilitar el uso de esta herramienta de escaneo de redes. Permite a los usuarios visualizar gráficamente los resultados de los escaneos, incluyendo mapas de topología, puertos abiertos, servicios detectados y más. 🛠️ Instalación de Zenmap en Windows 🚀 Primeros pasos con Zenmap 1. Abrir Zenmap 2. Interfaz principal Elemento Función Target Dirección IP, rango o subred a escanear. Profile Tipo de escaneo (ej. Intense scan, Ping scan, etc.). Command Comando Nmap generado automáticamente (editable). Nmap Output Resultados en texto plano. Ports/Hosts Lista de puertos abiertos y hosts detectados. Topology Mapa gráfico de la red escaneada. Host Details Información detallada del host seleccionado. 🧪 Ejemplo práctico Escaneo de red local: Resultado: 🧠 Consejos para aprovechar Zenmap 📸 Visualización gráfica 🖼️ Aquí tienes una imagen ilustrativa de Zenmap en acción 📚 Recursos adicionales
🧭 Exploración de Redes con Nmap en Windows
🎯 Objetivo General Capacitar a los participantes en el uso de Nmap en entornos Windows para realizar análisis de red, detección de servicios y evaluación de seguridad, aplicando buenas prácticas éticas y técnicas. 🧱 Estructura del Taller Módulo Tema Duración Modalidad 1 Introducción a Nmap 30 min Teórica 2 Instalación y configuración en Windows 20 min Práctica 3 Escaneos básicos y avanzados 60 min Práctica guiada 4 Uso de scripts NSE 30 min Práctica 5 Análisis de resultados y medidas defensivas 30 min Discusión 6 Evaluación y cierre 30 min Individual y grupal 🧰 Recursos necesarios 🧪 Actividades mejoradas 🔎 Actividad 1: Mapeo de la red local 🧠 Actividad 2: Análisis de servicios 🛡️ Actividad 3: Evaluación de vulnerabilidades 🤝 Actividad 4: Simulación de roles 📊 Evaluación ✅ Individual ✅ Grupal 📎 Material complementario 📚 Referencias
🧭 Manual de Comandos Nmap
1. Introducción Nmap (Network Mapper) es una herramienta de código abierto para escaneo de redes y auditoría de seguridad. Permite descubrir hosts, servicios, sistemas operativos y vulnerabilidades en una red. 2. Comandos Básicos 3. Comandos Avanzados 4. Uso de Scripts NSE 5. Escaneo de Firewall/IDS 6. Técnicas de Evasión 7. Formatos de Salida 8. Integración con otras herramientas 9. Enlaces útiles 10. Tabla Resumen Comando Descripción nmap -sS Escaneo SYN (sigiloso) nmap -O Detección de sistema operativo nmap -sV Detección de versiones de servicios nmap -A Escaneo agresivo nmap –script vuln Detección de vulnerabilidades
🧭 Guía Completa de Comandos de la Consola de Windows: Funciones, Usos y Clasificación por Categorías
📁 Gestión de archivos y directorios Comando Importancia Escenario recomendado cd Navegar entre carpetas Acceder a una carpeta específica para trabajar con sus archivos dir Ver contenido de una carpeta Confirmar qué archivos o subcarpetas existen mkdir Crear nuevas carpetas Organizar archivos por proyecto o tipo rmdir Eliminar carpetas vacías Limpiar directorios que ya no se usan del Eliminar archivos Borrar archivos innecesarios o temporales copy Copiar archivos Crear respaldos simples xcopy Copiar carpetas completas Migrar estructuras de carpetas entre discos move Mover archivos o carpetas Reorganizar archivos en diferentes ubicaciones rename Renombrar archivos o carpetas Cambiar nombres por claridad o convención attrib Cambiar atributos (oculto, solo lectura) Proteger archivos o hacerlos invisibles robocopy Copia robusta con tolerancia a fallos Respaldos grandes o sincronización de carpetas cipher Cifrar/descifrar archivos Proteger información confidencial 🖥️ Visualización y control del entorno Comando Importancia Escenario recomendado type Ver contenido de archivos de texto Leer logs o configuraciones sin abrir editores echo Mostrar mensajes o controlar scripts Depurar scripts o mostrar información al usuario cls Limpiar la consola Mejorar la visibilidad al trabajar exit Cerrar la consola Finalizar una sesión de comandos 🧠 Administración del sistema Comando Importancia Escenario recomendado tasklist Ver procesos activos Diagnóstico de rendimiento o procesos sospechosos taskkill Finalizar procesos Cerrar programas congelados o no deseados shutdown Apagar o reiniciar el sistema Automatizar reinicios o apagados programados systeminfo Ver detalles del sistema Obtener información de hardware y software sfc Reparar archivos del sistema Solucionar errores del sistema operativo chkdsk Verificar disco duro Corregir errores físicos o lógicos del disco format Formatear unidades Preparar discos para uso o limpieza total diskpart Gestionar particiones Crear, eliminar o modificar particiones regedit Editar el registro de Windows Configuraciones avanzadas (con precaución) bcdedit Modificar configuración de arranque Activar modo seguro o cambiar opciones de inicio bcdboot Reparar el arranque de Windows Restaurar el sistema tras errores de arranque sc Controlar servicios del sistema Iniciar, detener o configurar servicios wmic Consultar información del sistema Obtener datos de hardware, software o procesos powercfg Configurar energía Diagnóstico de batería o ahorro de energía 🌐 Red y conectividad Comando Importancia Escenario recomendado ipconfig Ver configuración IP Diagnóstico de red o renovación de IP ping Verificar conectividad Comprobar si un host está accesible netstat Ver conexiones activas Detectar conexiones sospechosas o puertos abiertos netsh Configurar red avanzada Ver redes Wi-Fi, cambiar IP, configurar firewall net Gestionar recursos de red Conectar a carpetas compartidas, iniciar servicios net user Administrar usuarios Crear, modificar o eliminar cuentas net localgroup Administrar grupos Asignar usuarios a grupos como «Administradores» net share Compartir carpetas Habilitar carpetas para acceso en red local 🛡️ Políticas y seguridad Comando Importancia Escenario recomendado gpupdate Aplicar políticas de grupo Forzar la actualización sin reiniciar gpresult Ver políticas aplicadas Diagnóstico de políticas activas por usuario o equipo