dtic-DIIAA/docs/ambito/dtic-DASUTEN/_hist/P2601.legacy_lecciones_aprendidas.md

P2601 Legacy — Lecciones Aprendidas del Enfoque con Domain Controller

Documento de aprendizaje institucional
Fecha de creación: 2026-04-15
Estado: ✅ Completado (caso de estudio histórico)

---

📌 Resumen Ejecutivo

Este documento recopila las lecciones aprendidas durante el enfoque inicial con Domain Controller (AD DS) que fue descartado en favor del enfoque Workgroup (P2601.09) debido a limitaciones de recursos y complejidad operativa.

Período cubierto: 23/02/2026 — 27/03/2026 (enfoque DC)
Fecha de pivot: 27/03/2026 (decisión de abandonar DC)
Enfoque actual: Workgroup sin DC (P2601.09) — ✅ Operativo desde 15/04/2026

---

🎯 Objetivo de este Documento

Preservar el conocimiento técnico adquirido durante la fase con DC para:

1. Evitar repetir errores en futuros proyectos
2. Documentar señales de alerta tempranas de problemas de recursos
3. Proveer contexto histórico para entender por qué se adoptó el enfoque Workgroup
4. Servir como caso de estudio para ingeniería de sistemas y toma de decisiones técnicas

---

🏗️ Arquitectura Original (Descartada)

Topología de Red Privada (10.0.100.0/24)

Internet
   │
Router ISP (192.168.1.1)
   │
   └── srv-dasu (Proxmox VE) — 10.0.10.205 / Tailscale 100.116.210.36
        │
        └── vmbr1 (NAT 10.0.100.x)
             ├── VM 100: dc-dasuten (10.0.100.10) — Domain Controller AD DS + DNS
             ├── VM 101: sql-dasuten (10.0.100.11) — SQL Server 2019 Core
             └── VM 102: pcv-dasu0 (10.0.100.12) — Windows 10 LTSC (cliente pruebas)

Componentes Requeridos (Enfoque DC)

Componente	VM ID	Rol	Recursos	Estado Actual
Domain Controller	100	dc-dasuten	AD DS + DNS + GPO	🛑 Apagada (preservada)
SQL Server	101	sql-dasuten	SQL 2019 Enterprise	🛑 Apagada (preservada)
PC Virtual	102	pcv-dasu0	Win 10 LTSC	🛑 Apagada (preservada)
Hipervisor	—	srv-dasu	Proxmox VE 9.1	✅ Operativo (solo SQL4 + PCV)

---

⚠️ Causas del Fracaso

1. Recursos Escasos en srv-dasu

Problema principal: El servidor físico srv-dasu tenía recursos insuficientes para sostener 3 VMs simultáneas con rendimiento aceptable.

Recurso	Disponible	Requerido (3 VMs)	Déficit
RAM	15 GB total	~20 GB (4+4+4 + host)	-5 GB
vCPU	6 núcleos	8+ (2+2+2 + host)	-2 vCPU
Disco	94 GB thin	~180 GB (50+60+50 + host)	-86 GB

Señales de alerta temprana (bitácoras 23-28/02/2026):

• 23/02: "Decisión de despliegue Server Core para optimizar recursos"
• 24/02: "Asignación técnica de recursos aprobada (2C/2GB/50GB)" — ya limitado
• 26/02: "Resguardo Integral Offline (Fallo parcial VM 101)" — sin espacio para backups
• 05/03: Tailscale configurado como subnet router para 10.0.100.0/24 — complejidad añadida

2. Complejidad de Red con NAT

Problema: La red privada 10.0.100.0/24 requería:

• NAT en Proxmox (vmbr1)
• Tunneling LPF hacia red académica 10.0.10.0/24
• Subnet router Tailscale para acceso remoto
• Reglas de firewall complejas para SQL (1433) y SSH (7022)

Bitácora 24/02/2026:

"Decisión de subred privada segregada (10.0.100.x)" — se optó por aislamiento

Bitácora 26/02/2026:

"Estrategia de Tunneling LPF hacia red 10.0.100.x" — complejidad creciente

3. Dependencia del Dominio para Autenticación

Problema: El sistema DASUTEN (Visual FoxPro) fue diseñado asumiendo AD DS:

• Campo UID vacío en Kermet.ini → autenticación Windows Integrated (SSPI)
• Sin dominio → sin Kerberos → sin autenticación
• GPOs requeridas para mapeos y restricciones

Bitácora 05/03/2026 (validación con usuaria):

"P02 - Login Exitoso: Prueba de ingreso al sistema con credenciales de aalmiron"

Hallazgo clave (ingeniería inversa 11/04/2026):

El sistema no tiene dependencia real del AD si se configura explícitamente UID=sa en Kermet.ini

4. Puntos de Falla Múltiples

Punto de Falla	Impacto	Frecuencia
DC caído	Sin autenticación → sin sistema	Alto (recursos escasos)
SQL caído	Sin base de datos	Medio
NAT/Red	Sin conectividad entre VMs	Medio-Alto
Tailscale	Sin acceso remoto DTIC	Bajo
AnyDesk	Sin fallback de acceso	Bajo

---

📅 Timeline de Eventos Críticos

Fecha	Hito	Estado	Observaciones
23/02/26	Inicio: Instalación Proxmox en srv-dasu	✅	Hardware recibido y acondicionado
23/02/26	Decisión: Server Core para DC	⚠️	Optimización prematura por recursos
24/02/26	VM 100 creada (dc-dasuten)	✅	2 vCPU / 2 GB RAM / 50 GB disco
24/02/26	Dashboard P2601 desplegado	✅	Métricas operativas en ns8
25/02/26	VM 101 creada (sql-dasuten)	✅	2 vCPU / 4 GB RAM / 60+100 GB
25/02/26	SQL Server 2019 instalado	✅	Autenticación mixta habilitada
26/02/26	OpenSSH en VMs Windows	✅	Puerto 7022 configurado
26/02/26	Backup vzdump (falla VM 101)	⚠️	Sin espacio en disco
27/02/26	VM 102 creada (pcv-dasu0)	✅	Win 10 LTSC + SSH
05/03/26	Validación usuaria (Andrea Almirón)	✅	Login exitoso, sistema operativo
05/03/26	Tailscale subnet router	⏳	10.0.100.0/24 expuesta
11/03/26	Problemas de rendimiento reportados	⚠️	VMs lentas, recursos insuficientes
15/03/26	Caídas intermitentes de DC	🔴	Autenticación falla
20/03/26	Decisión de pivot	⏳	Evaluar sin DC
27/03/26	Pivot oficial: Workgroup sin DC	✅	P2601.09 iniciado
15/04/26	Validación final (Workgroup)	✅	Sistema 100% operativo

---

🔬 Análisis de Señales de Alerta

Señales Tempranas (23-28/02)

Señal	Interpretación	Acción No Tomada
"Server Core para optimizar"	Recursos insuficientes desde inicio	Reducir scope o upgrade hardware
"2C/2GB/50GB"	DC sub-dimensionado	Asignar más RAM al DC
"Fallo parcial VM 101"	Disco lleno	Limpiar o expandir storage
"Tunneling LPF"	Complejidad de red creciente	Simplificar a red plana

Señales Tardías (01-15/03)

Señal	Interpretación	Consecuencia
Caídas de DC	RAM insuficiente	Sin autenticación
Lentitud general	CPU/RAM sobre-comprometida	Experiencia de usuario pobre
AnyDesk requerido	Red inestable	Dependencia de terceros

---

💡 Lecciones Aprendidas

1. "Menos es Más" (Principio ADN)

Lección: La complejidad debe justificarse con beneficios tangibles.

Caso DC: El Domain Controller añadía:

• 1 VM adicional (4 GB RAM, 2 vCPU)
• Complejidad de red (DNS, GPO, dominio)
• Punto de falla crítico

Beneficio: Ninguno tangible para el caso de uso (2 usuarias, 1 PC).

Principio aplicado (Workgroup):

• 2 VMs en vez de 3
• Red plana en vez de NAT
• SQL Auth en vez de Kerberos

2. Validar Recursos Antes de Comprometerse

Lección: Los números no mienten. Si 15 GB < 20 GB requeridos, el proyecto está en riesgo.

Señales ignoradas:

• RAM: 15 GB disponibles vs 20 GB requeridos
• Disco: 94 GB vs 180 GB requeridos
• vCPU: 6 núcleos vs 8+ requeridos

Acción correctiva (Workgroup):

• 1 VM SQL (4 GB) + 1 VM PCV (4 GB) = 8 GB
• Host: 4 GB → 12 GB total, dentro de límites

3. La Complejidad de Red es un Multiplicador de Fallas

Lección: Cada capa de abstracción de red (NAT, tunneling, subnet routing) es un punto de falla potencial.

Enfoque DC:

PC → AnyDesk → VM → NAT → DC (auth) → SQL

Enfoque Workgroup:

PC → SQL (red plana)

Resultado: 4 componentes → 2 componentes

4. Ingeniería Inversa Antes de Asumir Dependencias

Lección: No asumir que el software requiere AD DS sin verificar.

Suposición inicial: "DASUTEN requiere dominio porque usa Windows Auth"

Verificación (11/04/26):

• Kermet.ini con UID=sa → SQL Auth clásica
• Sin dependencia de Kerberos
• Sin dependencia de GPOs

Acción: Modificar 1 archivo .ini en vez de mantener 3 VMs.

5. El Usuario Final es el Validador Definitivo

Lección: La validación técnica no alcanza; el usuario valida la experiencia real.

Validación 05/03 (DC): ✅ "Login exitoso" — pero sistema lento

Validación 15/04 (Workgroup): ✅ "Datos actualizados, sistema rápido"

Diferencia: Menos capas = más rendimiento percibido.

---

📊 Comparativa: DC vs Workgroup

Métrica	DC (23/02-27/03)	Workgroup (27/03-presente)
VMs	3 (DC + SQL + PCV)	2 (SQL + PCV)
RAM total	~20 GB requeridos	~12 GB requeridos
vCPU	8+	6
Disco	~180 GB	~140 GB
Red	NAT 10.0.100.x + tunneling	DHCP plano 192.168.1.x
Autenticación	AD DS (Kerberos)	SQL Auth
Puntos de falla	5+	2
Validación usuaria	✅ Lento/intermitente	✅ Rápido/estable

---

🧭 Línea de Tiempo de la Decisión

Fase 1: Optimismo Inicial (23-28/02)

"Vamos a replicar la arquitectura enterprise en el servidor nuevo"

• Instalación de Proxmox
• Creación de VMs con recursos "mínimos viables"
• Configuración de red privada compleja

Fase 2: Primeras Grietas (01-15/03)

"Las VMs están lentas, el DC se cae seguido"

• Backups fallan por espacio
• DC requiere reinicios frecuentes
• AnyDesk se vuelve necesario para trabajar

Fase 3: Evaluación (15-20/03)

"¿Realmente necesitamos el DC?"

• Análisis de costos/beneficios
• Ingeniería inversa del sistema DASUTEN
• Descubrimiento: no hay dependencia real de AD

Fase 4: Pivot (27/03)

"Menos es más: eliminamos el DC"

• VMs legacy apagadas y preservadas
• Nueva VM dasu-sql4 con enfoque Workgroup
• Red plana DHCP del ISP

Fase 5: Validación (15/04)

"Funciona. Rápido y simple."

• Sistema 100% operativo
• Usuaria confirma datos actualizados
• Pipeline de backups automatizado

---

🔗 Referencias a Bitácoras Originales

Fecha	URL	Extracto
23/02/26	/bitacoras/2026-02-23	"Decisión de despliegue Server Core para optimizar recursos"
24/02/26	/bitacoras/2026-02-24	"Subred privada segregada (10.0.100.x)"
26/02/26	/bitacoras/2026-02-26	"Resguardo Integral Offline (Fallo parcial VM 101)"
05/03/26	/bitacoras/2026-03-05	"Validación Presencial por Usuario — EXITOSO"
27/03/26	/bitacoras/2026-03-27	"Pivot: Enfoque Workgroup sin DC"

---

📝 Recomendaciones para Futuros Proyectos

1. Checklist de Recursos (Pre-Proyecto)

• Calcular RAM requerida + 20% margen
• Calcular vCPU requeridos + 1 núcleo margen
• Calcular disco requerido + 30% margen
• Validar que el hardware físico cumple todos los requisitos

2. Principio de Complejidad Progresiva

• Empezar con la arquitectura más simple posible
• Añadir complejidad solo cuando se justifique con beneficios medibles
• Documentar cada capa de complejidad añadida

3. Validación de Dependencias de Software

• No asumir dependencias (AD, DNS, GPO) sin verificar
• Hacer ingeniería inversa del software antes de diseñar infraestructura
• Preguntar: "¿Qué pasa si sacamos esta capa?"

4. Señales de Alerta Temprana

Señal	Acción Correctiva
Backups fallan por espacio	Expandir storage o reducir scope
VMs lentas desde el inicio	Reducir cantidad o upgrade hardware
Múltiples capas de red	Simplificar a red plana
Caídas intermitentes	Investigar recursos (RAM/CPU)

---

🎓 Conclusión

El enfoque con Domain Controller no fue un fracaso, fue un proceso de aprendizaje necesario que permitió:

1. Entender los límites del hardware disponible
2. Descubrir que la complejidad no era necesaria para el caso de uso
3. Validar que el usuario final prioriza rendimiento sobre arquitectura "enterprise"
4. Documentar señales de alerta para futuros proyectos

Principio rector: "La arquitectura más simple que funciona es mejor que la arquitectura 'correcta' que apenas se sostiene."

---

Documento creado: 2026-04-15
Autor: Sistema ADN (recopilación de bitácoras 23/02/26 — 27/03/26)
Estado: ✅ Completado — Caso de estudio disponible para consulta