[A04.P005] DASUTEN: Pipeline refactorizado + Documentación + Informes
Refactorización del pipeline de backups DASUTEN: 1. Flujo simplificado (un solo destino): - Backup directo a X:\ (share srv-ns8) - Eliminado paso intermedio E:\BK_SQL\sysdasuten\ - Reducido de 3 ubicaciones a 2 (X: → /var/tmp/) 2. Módulo común DasuExecutor (lib/dasu_executor.rb): - Centraliza ejecución PowerShell en dasu-sql4 - Centraliza verificación de archivos en fenix - Elimina código repetido en 6 drones (-52% líneas) 3. Drones refactorizados: - dasuten_exportar_srvv-fenix.rb (FULL → X:) - dasuten_exportar_diferencial_srvv-fenix.rb (DIF → X:) - dasuten_transferir_srvv-fenix-srv-ns8.rb (simplificado) - dasuten_restaurar_dasu-sql4.rb (usa DasuExecutor) - dasuten_restaurar_diferencial_dasu-sql4.rb (usa DasuExecutor) - dasuten_download_drive-dasu-sql4.rb (usa DasuExecutor) - dasuten_verificar-integridad_dasu-sql4.rb (usa DasuExecutor) 4. Integración BKPs mantenida: - T8-T15: Tareas individuales - C7: dasuten_full (pipeline semanal) - C8: dasuten_diferencial (pipeline diario) 5. Documentación actualizada: - A04.P006_Backups-DASUTEN.md: flujo simplificado + módulo común - Lecciones aprendidas agregadas 6. Nuevos archivos: - Informes técnicos DASUTEN (docs/informes/2026-04_DASUTEN-migracion/) - A01.P011/P012: Documentación de drones y pipeline - proc_linux.rb, ops.rb: Utilitarios del ecosistema 7. Scripts legacy (para referencia): - orquestador_pipeline.rb, orquestador_pipeline_diferencial.rb - dasuten_upload_srv-ns8-drive.rb
This commit is contained in:
Ricardo Monla
@@ -0,0 +1,136 @@
|
||||
# INFORME DE AVANCE
|
||||
## Migración del Sistema DASUTEN a Infraestructura Autónoma
|
||||
|
||||
> **Área responsable:** Departamento de Tecnología de la Información y Comunicaciones (DTIC)
|
||||
> **Facultad Regional La Rioja — Universidad Tecnológica Nacional**
|
||||
> **Fecha:** 13 de abril de 2026
|
||||
> **Elaborado por:** Ricardo Monla — DTIC, UTN-FRLR
|
||||
> **Destinatarios:** [Completar]
|
||||
> **Versión:** 0.1 (Borrador inicial)
|
||||
|
||||
---
|
||||
|
||||
## 1. Contexto y Punto de Partida
|
||||
|
||||
El sistema de gestión administrativa de **DASUTEN** (Departamento de Acción Social Universitaria Tecnológica Nacional) en la Facultad Regional La Rioja funcionaba desde hace años sobre la infraestructura informática compartida de la Facultad: servidores, red interna y servicios de dominio que atienden a toda la institución.
|
||||
|
||||
Si bien esta configuración fue funcional durante un tiempo, con el correr de los años fue manifestando limitaciones concretas:
|
||||
|
||||
- **Fragilidad operativa:** Cualquier incidencia en la red o los servidores de la Facultad —incluso ajena a DASUTEN— impactaba directamente en el funcionamiento del sistema.
|
||||
- **Complejidad desproporcionada:** La arquitectura heredada requería múltiples servidores virtuales y un controlador de dominio, componentes pensados para entornos de gran escala que resultaban sobredimensionados para las necesidades reales de una sola oficina.
|
||||
- **Dificultad de mantenimiento:** Las tareas de mantenimiento, los respaldos de datos y las actualizaciones periódicas que envía Rectorado requerían coordinación con la infraestructura general de la Facultad, generando demoras y dependencias cruzadas.
|
||||
- **Limitación de autonomía:** DASUTEN, si bien opera dentro de las instalaciones de la Facultad, responde funcionalmente a **Rectorado (Buenos Aires)**. La dependencia de la infraestructura local dificultaba una eventual gestión directa desde la sede central.
|
||||
|
||||
---
|
||||
|
||||
## 2. Objetivo del Proyecto
|
||||
|
||||
El objetivo fue diseñar e implementar una solución que permita al sistema DASUTEN operar de forma **completamente autónoma** respecto de la infraestructura de la Facultad, teniendo en cuenta las siguientes restricciones y premisas:
|
||||
|
||||
- **Recursos limitados:** Se parte de los equipos ya existentes en la oficina DASUTEN — un único equipo de escritorio de prestaciones modestas y un servidor compacto reutilizado. **No se requirió adquisición de hardware nuevo.**
|
||||
- **No interferir con la operación diaria:** La solución debía permitir al equipo de DTIC realizar respaldos, aplicar actualizaciones de Rectorado y resolver problemas técnicos **de forma remota**, sin interrumpir ni afectar las tareas cotidianas de la oficina.
|
||||
- **Administrabilidad a distancia:** Dado que la oficina DASUTEN se encuentra en una ubicación externa a la Facultad, todo el sistema debía ser gestionable remotamente por DTIC.
|
||||
- **Simplicidad y sostenibilidad:** Con un solo equipo de modestas prestaciones como base, la arquitectura debía ser lo más simple posible para que resulte administrable y confiable en el tiempo.
|
||||
|
||||
---
|
||||
|
||||
## 3. Qué se hizo y cómo se llegó
|
||||
|
||||
### 3.1 La simplificación
|
||||
|
||||
El trabajo principal consistió en **desmontar la complejidad innecesaria** de la arquitectura anterior y reemplazarla por un esquema directo y simple:
|
||||
|
||||
| Aspecto | Antes | Ahora |
|
||||
|:---|:---:|:---:|
|
||||
| Servidores virtuales necesarios | 3 | 1 |
|
||||
| Dependencia de red de Facultad | Sí | No |
|
||||
| Puntos de falla | Múltiples | Mínimos |
|
||||
| Requiere presencia física para soporte | Frecuentemente | No |
|
||||
| Hardware nuevo adquirido | — | Ninguno |
|
||||
|
||||
En la práctica, se pasó de una arquitectura de tres servidores virtuales más un controlador de dominio compartido, a **un solo servidor virtual** que contiene la base de datos, conectado directamente a la PC de escritorio de la oficina. Todo opera dentro de la red propia de la oficina DASUTEN, sin depender del cableado ni de los servicios de la Facultad.
|
||||
|
||||
### 3.2 El proceso: de testeo a producción
|
||||
|
||||
Si bien el proyecto llevó más tiempo del inicialmente estimado, esto responde a una decisión deliberada: se planificó desde el inicio una **etapa de testeo exhaustivo** antes de llevar el sistema a producción. Cada paso fue validado primero en un entorno virtual de pruebas antes de aplicarse al entorno real, minimizando los riesgos para la operación de la oficina.
|
||||
|
||||
Este enfoque gradual permitió:
|
||||
|
||||
- Detectar y resolver problemas en un entorno controlado, sin afectar a la usuaria.
|
||||
- Validar que el sistema funciona correctamente **sin la infraestructura de dominio** de la Facultad — algo que no estaba documentado y que requirió trabajo de ingeniería inversa sobre el software provisto por Rectorado.
|
||||
- Migrar la base de datos de producción con verificación completa de integridad.
|
||||
|
||||
**A la fecha, el sistema se encuentra a un paso de estar implementado al 100%**, restando únicamente un ajuste de compatibilidad en la impresión de documentos, para el cual ya se dispone de una solución provisoria que permite continuar operando.
|
||||
|
||||
### 3.3 Valor agregado: herramientas y metodología
|
||||
|
||||
Un aspecto destacable del proceso es que, más allá del objetivo técnico central, el trabajo realizado durante estos meses **generó herramientas y metodologías de valor** que exceden al proyecto DASUTEN y benefician a la gestión de DTIC en su conjunto:
|
||||
|
||||
- **Dashboard web de seguimiento:** Se desarrolló un sitio web interno que muestra en tiempo real el avance del proyecto con sus hitos, permitiendo visibilidad y trazabilidad del progreso.
|
||||
|
||||
- **Sistema de bitácoras:** Se implementó un sistema de registro detallado de cada intervención técnica, creando un historial completo y auditable de los movimientos realizados sobre la infraestructura.
|
||||
|
||||
- **Herramientas de automatización (Ecosistema ADN):** Se construyó un conjunto de scripts y herramientas internas que optimizan las tareas de administración — desde la orquestación de respaldos automatizados hasta la gestión remota de los equipos, permitiendo que operaciones que antes requerían horas de trabajo manual se ejecuten de forma desatendida.
|
||||
|
||||
- **Metodología de trabajo con IA generativa:** Se incorporó la inteligencia artificial como herramienta de desarrollo operativo, tanto para la planificación y documentación del proyecto como para la creación de las herramientas mencionadas. Esta metodología de trabajo colaborativo entre el técnico y la IA demostró ser altamente productiva y replicable en futuros proyectos del área.
|
||||
|
||||
Estas herramientas fueron posibles gracias al aprendizaje acumulado durante el proceso de migración, y representan un activo que queda disponible para la gestión de otros proyectos de DTIC.
|
||||
|
||||
---
|
||||
|
||||
## 4. Estado Actual
|
||||
|
||||
| Aspecto | Estado |
|
||||
|:---|:---:|
|
||||
| Sistema DASUTEN operativo en oficina | ✅ |
|
||||
| Base de datos migrada y verificada | ✅ |
|
||||
| Acceso y consulta de datos | ✅ |
|
||||
| Administración remota por DTIC | ✅ |
|
||||
| Respaldos automatizados | ✅ |
|
||||
| Impresión de documentos | ⚠️ En ajuste |
|
||||
|
||||
**El sistema se encuentra operativo.** La usuaria de la oficina DASUTEN puede acceder al sistema, consultar datos y realizar sus tareas habituales. El equipo de DTIC puede administrar, respaldar y actualizar el sistema de forma remota sin interferir con la operación de la oficina.
|
||||
|
||||
El único punto pendiente es un ajuste en la función de impresión, vinculado a la compatibilidad de unas plantillas de Office. Se dispuso una solución provisoria que permite a la usuaria continuar imprimiendo mientras se resuelve definitivamente.
|
||||
|
||||
---
|
||||
|
||||
## 5. Beneficios Alcanzados
|
||||
|
||||
### Autonomía operativa
|
||||
DASUTEN opera ahora sobre infraestructura propia en su oficina, desvinculada de la Facultad. Esto facilita también una eventual gestión directa desde Rectorado.
|
||||
|
||||
### Optimización de recursos
|
||||
Se logró la implementación completa **sin inversión en hardware nuevo**, aprovechando equipos existentes de prestaciones modestas. Un solo equipo compacto cumple ahora la función que antes requerían tres servidores virtuales.
|
||||
|
||||
### Soporte remoto transparente
|
||||
DTIC puede realizar respaldos, actualizaciones y resolución de problemas **sin interrumpir el trabajo de la oficina** y sin necesidad de desplazarse físicamente.
|
||||
|
||||
### Mayor estabilidad
|
||||
Al eliminar las dependencias cruzadas con la infraestructura de la Facultad, se reducen significativamente las fallas inesperadas.
|
||||
|
||||
### Herramientas reutilizables
|
||||
El proceso generó herramientas de automatización, seguimiento y documentación que quedan disponibles para futuros proyectos de DTIC.
|
||||
|
||||
---
|
||||
|
||||
## 6. Próximos Pasos
|
||||
|
||||
1. **Completar el ajuste de impresión** para alcanzar el 100% de funcionalidad.
|
||||
2. **Estabilizar la configuración de red** del servidor para garantizar continuidad a largo plazo.
|
||||
3. **Formalizar los procedimientos de respaldo** automatizado para la operación de rutina.
|
||||
4. **Evaluar el retiro definitivo** de la infraestructura anterior, una vez confirmada la estabilidad completa del nuevo entorno.
|
||||
|
||||
---
|
||||
|
||||
## 7. Conclusión
|
||||
|
||||
La migración del sistema DASUTEN a una infraestructura autónoma demuestra que es posible **lograr una mejora sustancial en estabilidad, autonomía y capacidad de gestión** partiendo de recursos limitados y sin inversión adicional en equipamiento.
|
||||
|
||||
El proyecto se encuentra en su tramo final, con el sistema operativo y la base de datos verificada. El proceso, aunque más extenso de lo inicialmente previsto, fue planificado como una transición gradual de testeo a producción que permitió minimizar riesgos y, como valor agregado, generar herramientas y metodologías que benefician al área en su conjunto.
|
||||
|
||||
DASUTEN opera hoy de forma independiente en su propia oficina, administrable remotamente por DTIC y preparada para una gestión más ágil, ya sea desde la Facultad Regional o desde Rectorado.
|
||||
|
||||
---
|
||||
|
||||
*Fin del informe.*
|
||||
@@ -0,0 +1,132 @@
|
||||
# INFORME DE AVANCE
|
||||
## Migración del Sistema DASUTEN a Infraestructura Autónoma
|
||||
|
||||
> **Área responsable:** Departamento de Tecnología de la Información y Comunicaciones (DTIC)
|
||||
> **Facultad Regional La Rioja — Universidad Tecnológica Nacional**
|
||||
> **Fecha:** 13 de abril de 2026
|
||||
> **Elaborado por:** Ricardo Monla — DTIC, UTN-FRLR
|
||||
> **Destinatarios:** [Completar]
|
||||
> **Versión:** 0.2 (Borrador)
|
||||
|
||||
### Historial de versiones
|
||||
|
||||
| Versión | Fecha | Cambios |
|
||||
|:---:|:---:|:---|
|
||||
| 0.1 | 13/04/2026 | Borrador inicial |
|
||||
| 0.2 | 13/04/2026 | Se amplía contexto de situación inicial y esquema de trabajo previo |
|
||||
|
||||
---
|
||||
|
||||
## 1. Contexto y Punto de Partida
|
||||
|
||||
El sistema de gestión administrativa de **DASUTEN** (Departamento de Acción Social Universitaria Tecnológica Nacional) en la Facultad Regional La Rioja funcionaba desde hace años sobre la infraestructura informática compartida de la Facultad.
|
||||
|
||||
Cuando la oficina de DASUTEN fue reubicada en un espacio propio, alejado de los servidores de la Facultad, se sumó un problema de conectividad: la señal de red debía recorrer múltiples puntos intermedios dentro del edificio, y la caída de cualquiera de ellos dejaba a la oficina sin acceso al sistema.
|
||||
|
||||
### Solución provisoria que se venía aplicando
|
||||
|
||||
Para resolver esta situación, se gestionó internamente la baja de una **línea de internet propia** para la oficina DASUTEN, eliminando la dependencia del cableado interno de la Facultad. Sin embargo, esto no era suficiente por sí solo: el sistema seguía requiriendo acceso a los servidores internos de la Facultad para funcionar.
|
||||
|
||||
Se implementó entonces un esquema de trabajo remoto donde las usuarias — Andrea Almirón y Romina Molina — accedían desde la PC física de la oficina, a través de un software de escritorio remoto (AnyDesk), a una **PC virtual** alojada en los servidores. Recién desde esa PC virtual podían operar el sistema.
|
||||
|
||||
Este esquema, si bien permitió dar continuidad al servicio y brindó la posibilidad de asistencia técnica 24/7 por parte de DTIC, implicaba:
|
||||
|
||||
- Una experiencia de trabajo **indirecta** para las usuarias (PC física → escritorio remoto → PC virtual → sistema).
|
||||
- La necesidad de mantener operativos **cuatro componentes** simultáneamente: un servidor de dominio, un servidor de base de datos, una PC virtual y la PC física con el software de acceso remoto.
|
||||
- Múltiples puntos de falla que dificultaban el soporte.
|
||||
|
||||
---
|
||||
|
||||
## 2. Objetivo del Proyecto
|
||||
|
||||
Partiendo de esa situación, el objetivo fue diseñar una solución que permita al sistema DASUTEN operar de forma **directa y autónoma** en la propia oficina, con las siguientes premisas:
|
||||
|
||||
- **Recursos limitados:** Aprovechar los equipos ya existentes — un equipo de escritorio de prestaciones modestas y un servidor compacto reutilizado. **Sin adquisición de hardware nuevo.**
|
||||
- **Trabajo directo:** Que las usuarias puedan operar el sistema directamente desde la PC de la oficina, sin depender de conexiones remotas intermedias.
|
||||
- **No interferir con la oficina:** Que DTIC pueda realizar respaldos, aplicar actualizaciones de Rectorado y resolver problemas **de forma remota y transparente**.
|
||||
- **Simplicidad:** Una arquitectura lo más simple posible, administrable y confiable en el tiempo.
|
||||
|
||||
---
|
||||
|
||||
## 3. Qué se logró
|
||||
|
||||
### 3.1 La simplificación
|
||||
|
||||
Se reemplazó la arquitectura compleja por un esquema directo y simple:
|
||||
|
||||
| Aspecto | Antes | Ahora |
|
||||
|:---|:---:|:---:|
|
||||
| Componentes necesarios | 4 (dominio + BD + PC virtual + PC física) | 2 (servidor BD + PC física) |
|
||||
| Forma de trabajo | Indirecta (vía escritorio remoto) | Directa (sistema en la PC) |
|
||||
| Dependencia de red de Facultad | Sí | No |
|
||||
| Puntos de falla | Múltiples | Mínimos |
|
||||
| Requiere presencia física para soporte | Frecuentemente | No |
|
||||
| Hardware nuevo adquirido | — | Ninguno |
|
||||
|
||||
Las usuarias ahora operan el sistema **directamente desde la PC de la oficina**, sin necesidad de conexiones remotas intermedias. El servidor de base de datos funciona dentro de la misma oficina, en la red propia de DASUTEN.
|
||||
|
||||
### 3.2 El proceso: de testeo a producción
|
||||
|
||||
Si bien el proyecto llevó más tiempo del inicialmente estimado, esto responde a una decisión deliberada: se planificó una **etapa de testeo exhaustivo** antes de llevar el sistema a producción. Cada paso fue validado primero en un entorno virtual de pruebas antes de aplicarse al entorno real, minimizando los riesgos para la operación de la oficina.
|
||||
|
||||
**A la fecha, el sistema se encuentra a un paso del 100%**, restando únicamente un ajuste de compatibilidad en la impresión de documentos, para el cual ya se dispone de una solución provisoria.
|
||||
|
||||
### 3.3 Valor agregado: herramientas y metodología
|
||||
|
||||
Un aspecto destacable es que, más allá del objetivo central, el trabajo realizado **generó herramientas y metodologías de valor** que benefician a la gestión de DTIC en su conjunto:
|
||||
|
||||
- **Dashboard web de seguimiento** del proyecto, con visibilidad en tiempo real del progreso.
|
||||
- **Sistema de bitácoras** con registro detallado de cada intervención técnica.
|
||||
- **Herramientas de automatización** (Ecosistema ADN) para respaldos, gestión remota y tareas repetitivas.
|
||||
- **Metodología de trabajo con IA generativa**, que demostró ser altamente productiva y replicable en futuros proyectos.
|
||||
|
||||
---
|
||||
|
||||
## 4. Estado Actual
|
||||
|
||||
| Aspecto | Estado |
|
||||
|:---|:---:|
|
||||
| Sistema operativo en oficina | ✅ |
|
||||
| Base de datos migrada y verificada | ✅ |
|
||||
| Trabajo directo (sin escritorio remoto) | ✅ |
|
||||
| Administración remota por DTIC | ✅ |
|
||||
| Respaldos automatizados | ✅ |
|
||||
| Impresión de documentos | ⚠️ En ajuste |
|
||||
|
||||
El sistema se encuentra **operativo**. La usuaria de la oficina puede acceder directamente al sistema, consultar datos y realizar sus tareas habituales. DTIC administra, respalda y actualiza el sistema de forma remota sin interferir con la oficina.
|
||||
|
||||
Resta un ajuste en la impresión, con solución provisoria funcional mientras se resuelve.
|
||||
|
||||
---
|
||||
|
||||
## 5. Beneficios Alcanzados
|
||||
|
||||
- **Trabajo directo:** Las usuarias operan el sistema sin intermediarios, mejorando la experiencia y la productividad.
|
||||
- **Autonomía operativa:** DASUTEN funciona sobre infraestructura propia, desvinculada de la Facultad y preparada para gestión directa desde Rectorado.
|
||||
- **Optimización de recursos:** Implementación completa sin inversión en hardware nuevo.
|
||||
- **Soporte transparente:** DTIC gestiona remotamente sin afectar la operación diaria.
|
||||
- **Mayor estabilidad:** Al reducir de 4 componentes a 2, se minimizan las fallas.
|
||||
- **Herramientas reutilizables:** El proceso generó activos aprovechables para otros proyectos de DTIC.
|
||||
|
||||
---
|
||||
|
||||
## 6. Próximos Pasos
|
||||
|
||||
1. Completar el ajuste de impresión para alcanzar el 100% de funcionalidad.
|
||||
2. Estabilizar la configuración de red del servidor.
|
||||
3. Formalizar los procedimientos de respaldo automatizado.
|
||||
4. Evaluar el retiro definitivo de la infraestructura anterior.
|
||||
|
||||
---
|
||||
|
||||
## 7. Conclusión
|
||||
|
||||
La migración del sistema DASUTEN demuestra que es posible **lograr una mejora sustancial en estabilidad, autonomía y experiencia de trabajo** partiendo de recursos limitados y sin inversión adicional.
|
||||
|
||||
Se pasó de un esquema indirecto — donde las usuarias dependían de conexiones remotas a través de múltiples componentes para poder trabajar — a un esquema directo y simple donde el sistema funciona en la propia oficina.
|
||||
|
||||
El proyecto se encuentra en su tramo final, con el sistema operativo y la base de datos verificada. El proceso generó además herramientas y metodologías que quedan como activo del área para futuros proyectos.
|
||||
|
||||
---
|
||||
|
||||
*Fin del informe.*
|
||||
@@ -0,0 +1,130 @@
|
||||
# INFORME DE AVANCE
|
||||
## Migración del Sistema DASUTEN a Infraestructura Autónoma
|
||||
|
||||
> **Área responsable:** Departamento de Tecnología de la Información y Comunicaciones (DTIC)
|
||||
> **Facultad Regional La Rioja — Universidad Tecnológica Nacional**
|
||||
> **Fecha:** 13 de abril de 2026
|
||||
> **Elaborado por:** Ricardo Monla — DTIC, UTN-FRLR
|
||||
> **Destinatarios:** [Completar]
|
||||
> **Versión:** 0.3 (Borrador)
|
||||
>
|
||||
> *Este documento es de carácter ejecutivo y narrativo. El detalle técnico completo se encuentra en el documento complementario [02_informe_tecnico_DASUTEN.md](02_informe_tecnico_DASUTEN.md).*
|
||||
|
||||
---
|
||||
|
||||
## 1. Contexto y Punto de Partida
|
||||
|
||||
El sistema de gestión administrativa de **DASUTEN** (Departamento de Acción Social Universitaria Tecnológica Nacional) en la Facultad Regional La Rioja funcionaba desde hace años sobre la infraestructura informática compartida de la Facultad: servidores, red interna y servicios de dominio que atienden a toda la institución.
|
||||
|
||||
Si bien esta configuración fue funcional durante un tiempo, con el correr de los años fue manifestando limitaciones concretas:
|
||||
|
||||
- **Fragilidad operativa:** Cualquier incidencia en la red o los servidores de la Facultad —incluso ajena a DASUTEN— impactaba directamente en el funcionamiento del sistema.
|
||||
- **Complejidad desproporcionada:** La arquitectura heredada requería múltiples servidores virtuales y un controlador de dominio, componentes pensados para entornos de mayor escala que resultaban sobredimensionados para las necesidades de una sola oficina.
|
||||
- **Dificultad de mantenimiento:** Los respaldos de datos y las actualizaciones periódicas que envía Rectorado requerían coordinación con la infraestructura general de la Facultad, generando demoras y dependencias cruzadas.
|
||||
- **Limitación de autonomía:** DASUTEN, si bien opera dentro de las instalaciones de la Facultad, responde funcionalmente a **Rectorado (Buenos Aires)**. La dependencia de la infraestructura local dificultaba una eventual gestión directa desde la sede central.
|
||||
|
||||
A esta situación se sumó que, al reubicarse la oficina en un espacio propio alejado de los servidores, las fallas de conectividad se agravaron por la cantidad de puntos intermedios en la red. Para dar continuidad al servicio, se gestionó una línea de internet propia y se implementó un esquema de trabajo indirecto donde las usuarias — Andrea Almirón y Romina Molina — accedían mediante escritorio remoto a una PC virtual para poder operar el sistema. Esto implicaba mantener cuatro componentes simultáneamente (servidor de dominio, servidor de base de datos, PC virtual y PC física), multiplicando los puntos de falla.
|
||||
|
||||
---
|
||||
|
||||
## 2. Objetivo del Proyecto
|
||||
|
||||
Diseñar e implementar una solución que permita al sistema DASUTEN operar de forma **completamente autónoma**, teniendo en cuenta:
|
||||
|
||||
- **Recursos limitados:** Aprovechar equipos ya existentes — un equipo de escritorio de prestaciones modestas y un servidor compacto reutilizado. **Sin adquisición de hardware nuevo.**
|
||||
- **No interferir con la oficina:** Que DTIC pueda realizar respaldos, actualizaciones de Rectorado y soporte técnico **de forma remota y transparente**, sin afectar las tareas cotidianas.
|
||||
- **Trabajo directo:** Que las usuarias operen el sistema directamente desde la PC de la oficina, sin depender de conexiones remotas intermedias.
|
||||
- **Simplicidad:** Una arquitectura lo más simple posible, administrable y confiable en el tiempo.
|
||||
|
||||
---
|
||||
|
||||
## 3. Qué se logró
|
||||
|
||||
### 3.1 La simplificación
|
||||
|
||||
Se reemplazó la arquitectura compleja por un esquema directo y simple:
|
||||
|
||||
| Aspecto | Antes | Ahora |
|
||||
|:---|:---:|:---:|
|
||||
| Componentes necesarios | 4 | 2 |
|
||||
| Forma de trabajo | Indirecta (vía escritorio remoto) | Directa (sistema en la PC) |
|
||||
| Dependencia de red de Facultad | Sí | No |
|
||||
| Puntos de falla | Múltiples | Mínimos |
|
||||
| Requiere presencia física para soporte | Frecuentemente | No |
|
||||
| Hardware nuevo adquirido | — | Ninguno |
|
||||
|
||||
Las usuarias ahora operan el sistema **directamente desde la PC de la oficina**. El servidor de base de datos funciona dentro de la misma oficina, en la red propia de DASUTEN, sin intermediarios.
|
||||
|
||||
### 3.2 El proceso: de testeo a producción
|
||||
|
||||
Si bien el proyecto llevó más tiempo del inicialmente estimado, esto responde a una decisión deliberada: se planificó una **etapa de testeo exhaustivo** antes de llevar el sistema a producción. Cada paso fue validado primero en un entorno de pruebas antes de aplicarse al entorno real, minimizando riesgos para la operación de la oficina.
|
||||
|
||||
**A la fecha, el sistema se encuentra a un paso del 100%**, restando únicamente un ajuste de compatibilidad en la impresión de documentos, para el cual ya se dispone de una solución provisoria.
|
||||
|
||||
### 3.3 Valor agregado: herramientas y metodología
|
||||
|
||||
Más allá del objetivo central, el trabajo realizado **generó herramientas y metodologías de valor** que benefician a la gestión de DTIC en su conjunto:
|
||||
|
||||
- **Dashboard web de seguimiento** del proyecto, con visibilidad en tiempo real del progreso.
|
||||
- **Sistema de bitácoras** con registro detallado y auditable de cada intervención técnica.
|
||||
- **Herramientas de automatización** (Ecosistema ADN) para respaldos, gestión remota y tareas repetitivas.
|
||||
- **Metodología de trabajo con IA generativa**, altamente productiva y replicable en futuros proyectos.
|
||||
|
||||
---
|
||||
|
||||
## 4. Estado Actual
|
||||
|
||||
| Aspecto | Estado |
|
||||
|:---|:---:|
|
||||
| Sistema operativo en oficina | ✅ |
|
||||
| Base de datos migrada y verificada | ✅ |
|
||||
| Trabajo directo (sin escritorio remoto) | ✅ |
|
||||
| Administración remota por DTIC | ✅ |
|
||||
| Respaldos automatizados | ✅ |
|
||||
| Impresión de documentos | ⚠️ En ajuste |
|
||||
|
||||
El sistema se encuentra **operativo**. La usuaria accede directamente al sistema desde la PC de la oficina. DTIC administra y respalda de forma remota sin interferir con la operación diaria.
|
||||
|
||||
Resta un ajuste en la impresión, con solución provisoria funcional.
|
||||
|
||||
---
|
||||
|
||||
## 5. Beneficios Alcanzados
|
||||
|
||||
- **Trabajo directo:** Las usuarias operan el sistema sin intermediarios.
|
||||
- **Autonomía operativa:** Infraestructura propia, desvinculada de la Facultad, preparada para gestión desde Rectorado.
|
||||
- **Optimización de recursos:** Sin inversión en hardware nuevo.
|
||||
- **Soporte transparente:** DTIC gestiona remotamente sin afectar la oficina.
|
||||
- **Mayor estabilidad:** De 4 componentes a 2, menos fallas posibles.
|
||||
- **Herramientas reutilizables:** Activos aprovechables para otros proyectos de DTIC.
|
||||
|
||||
---
|
||||
|
||||
## 6. Próximos Pasos
|
||||
|
||||
1. Completar el ajuste de impresión para alcanzar el 100% de funcionalidad.
|
||||
2. Estabilizar la configuración de red del servidor.
|
||||
3. Formalizar los procedimientos de respaldo automatizado.
|
||||
4. Evaluar el retiro definitivo de la infraestructura anterior.
|
||||
|
||||
---
|
||||
|
||||
## 7. Conclusión
|
||||
|
||||
La migración del sistema DASUTEN demuestra que es posible **lograr una mejora sustancial en estabilidad, autonomía y experiencia de trabajo** partiendo de recursos limitados y sin inversión adicional.
|
||||
|
||||
Se pasó de un esquema indirecto y complejo a uno directo y simple, donde el sistema funciona en la propia oficina. El proceso generó además herramientas y metodologías que quedan como activo del área para futuros proyectos.
|
||||
|
||||
DASUTEN opera hoy de forma independiente, administrable remotamente por DTIC y preparada para una gestión más ágil desde la Facultad Regional o desde Rectorado.
|
||||
|
||||
---
|
||||
|
||||
### Historial de versiones
|
||||
|
||||
| Versión | Fecha | Cambios |
|
||||
|:---:|:---:|:---|
|
||||
| 0.1 | 13/04/2026 | Borrador inicial |
|
||||
| 0.2 | 13/04/2026 | Se amplía contexto de situación inicial |
|
||||
| 0.3 | 13/04/2026 | Se retoma enfoque narrativo, se integra contexto como complemento, se agrega referencia al documento técnico |
|
||||
|
||||
*Fin del informe.*
|
||||
@@ -0,0 +1,407 @@
|
||||
# INFORME TÉCNICO — Migración del Sistema DASUTEN a Nuevo Servidor
|
||||
|
||||
> **Área:** Departamento de Tecnología de la Información y Comunicaciones (DTIC)
|
||||
> **Proyecto:** Migración de infraestructura DASUTEN — Modo Workgroup sin Domain Controller
|
||||
> **Código interno:** A04.P005
|
||||
> **Fecha del informe:** 13 de abril de 2026
|
||||
> **Elaborado por:** Ricardo Monla — Área DTIC, UTN-FRLR
|
||||
|
||||
---
|
||||
|
||||
## 1. Resumen Ejecutivo
|
||||
|
||||
Se informa el avance de la migración del sistema de gestión administrativa **DASUTEN** (Departamento de Acción Social Universitaria Tecnológica Nacional) desde la infraestructura compartida de la Facultad hacia un entorno independiente, autónomo y simplificado.
|
||||
|
||||
**Estado general del proyecto: 95% completado.**
|
||||
|
||||
El sistema DASUTEN se encuentra **operativo** en la nueva infraestructura desde el día 13 de abril de 2026, habiendo superado exitosamente las pruebas funcionales de acceso a datos. Resta únicamente resolver un problema de compatibilidad de impresión vinculado a las plantillas de Office utilizadas por el sistema.
|
||||
|
||||
### Logros principales
|
||||
|
||||
- ✅ Servidor de base de datos **completamente migrado** a infraestructura nueva.
|
||||
- ✅ Base de datos de producción **restaurada y verificada** sin errores de integridad.
|
||||
- ✅ Sistema DASUTEN **desplegado y operativo** en la PC física de la usuaria.
|
||||
- ✅ Eliminación exitosa de la dependencia del **Active Directory (Domain Controller)**.
|
||||
- ✅ Simplificación de la arquitectura de red — de 3 servidores virtuales a 1.
|
||||
- ⚠️ Pendiente: resolución de problema de impresión por compatibilidad de plantillas Office.
|
||||
|
||||
---
|
||||
|
||||
## 2. Antecedentes y Motivación
|
||||
|
||||
### 2.1 Situación previa
|
||||
|
||||
El sistema DASUTEN operaba sobre infraestructura compartida con la Facultad Regional La Rioja, dependiendo de:
|
||||
|
||||
- Un servidor SQL Server alojado en la red interna de la Facultad (`srvv-fenix`).
|
||||
- Un Domain Controller Active Directory para la autenticación de usuarios.
|
||||
- Conectividad de red interna de la Facultad con routing complejo.
|
||||
|
||||
Esta configuración generaba **múltiples puntos de falla**:
|
||||
- Dependencia del dominio institucional para la autenticación.
|
||||
- Complejidad de red con subnetting privado, NAT y gateway interno.
|
||||
- Cualquier cambio en la infraestructura de la Facultad impactaba directamente en DASUTEN.
|
||||
|
||||
### 2.2 Objetivo del proyecto
|
||||
|
||||
**Migrar el sistema DASUTEN a una infraestructura independiente y simplificada**, eliminando la dependencia del Domain Controller (Active Directory) y utilizando un esquema de red **Workgroup** directo, con el fin de:
|
||||
|
||||
1. Reducir la complejidad operativa.
|
||||
2. Minimizar los puntos de falla.
|
||||
3. Garantizar la autonomía operativa de DASUTEN respecto de la infraestructura de la Facultad.
|
||||
4. Facilitar la eventual gestión desde Rectorado (Buenos Aires) si fuera necesario.
|
||||
|
||||
---
|
||||
|
||||
## 3. Infraestructura Implementada
|
||||
|
||||
### 3.1 Arquitectura de red
|
||||
|
||||
Se implementó una topología de **red plana simplificada**, donde todos los equipos obtienen direccionamiento IP directamente del router del ISP, eliminando subnetting privado y routing interno:
|
||||
|
||||
```
|
||||
Internet
|
||||
│
|
||||
Router ISP (192.168.1.1 — Gateway)
|
||||
│
|
||||
├── srv-dasu (Proxmox VE) → 192.168.1.13
|
||||
│ └── dasu-sql4 (VM 106) → 192.168.1.11 [SQL Server 2019]
|
||||
│
|
||||
└── dasu-pc (PC Física) → DHCP ISP [Estación de trabajo]
|
||||
```
|
||||
|
||||
### 3.2 Componentes del nuevo entorno
|
||||
|
||||
| Componente | Descripción | Estado |
|
||||
|:---|:---|:---:|
|
||||
| **srv-dasu** | Servidor Proxmox VE 9.1 (Hipervisor) — CPU Intel, 15 GB RAM, 94 GB disco | ✅ Operativo |
|
||||
| **dasu-sql4** (VM 106) | Windows Server 2022 — SQL Server 2019 Enterprise — 4 GB RAM, 2 vCPU, discos 60+120 GB | ✅ Operativo |
|
||||
| **dasu-pc** | PC Física — Windows 10 Pro — AMD Ryzen 5, 8 GB RAM — Oficina DASUTEN | ✅ Operativo |
|
||||
|
||||
### 3.3 Comparativa: Antes vs. Después
|
||||
|
||||
| Aspecto | Enfoque Anterior (con DC) | Enfoque Actual (Workgroup) |
|
||||
|:---|:---|:---|
|
||||
| **Red** | Privada 10.0.100.x (gateway interno) | DHCP del ISP (red plana) |
|
||||
| **Autenticación SQL** | Windows Integrated (Kerberos) | SQL Auth (mixta) |
|
||||
| **Usuarios** | Active Directory | Usuarios locales Windows |
|
||||
| **DNS** | AD DNS (10.0.100.10) | DNS del ISP (automático) |
|
||||
| **Complejidad de red** | Alta (DC + DNS + dominio + routing) | Mínima (red plana ISP) |
|
||||
| **Puntos de falla** | DC, SQL, red dominio, routing | Solo SQL |
|
||||
| **VMs necesarias** | 3 (DC + SQL + PC) | 1 (solo SQL) |
|
||||
|
||||
---
|
||||
|
||||
## 4. Fases Ejecutadas y Progreso
|
||||
|
||||
### Resumen de progreso por fase
|
||||
|
||||
| Fase | Descripción | Estado | Progreso |
|
||||
|:---:|:---|:---:|:---:|
|
||||
| 1 | Preparación del entorno (srv-dasu) | ✅ Completada | 100% |
|
||||
| 2 | Creación de VM SQL Server de prueba | ✅ Completada | 100% |
|
||||
| 3 | Creación de VM PC Cliente de prueba | ✅ Completada | 100% |
|
||||
| 4 | VM definitiva dasu-sql4 | ✅ Completada | 100% |
|
||||
| 5 | Migración de base de datos | ✅ Completada | 100% |
|
||||
| 5b | Hardening y persistencia de servicios | ✅ Completada | 100% |
|
||||
| 6 | Validación con PC cliente virtual | ✅ Completada | 100% |
|
||||
| 7 | Despliegue en PC física (producción) | 🚧 En curso | 75% |
|
||||
| 8 | Refresco final de base de datos | ✅ Completada | 100% |
|
||||
|
||||
### 4.1 Fase 1-3: Preparación y pruebas de concepto (27-28 marzo)
|
||||
|
||||
Se preparó el hipervisor Proxmox, se reconfiguró el bridge de red para usar DHCP directo del ISP, y se crearon VMs de prueba para validar la viabilidad del enfoque sin Domain Controller.
|
||||
|
||||
**Hallazgo crítico:** Se detectó y resolvió que el bridge de red estaba configurado con la IP de una red privada anterior, lo cual habría impedido la conectividad de las nuevas VMs.
|
||||
|
||||
### 4.2 Fase 4: Servidor SQL definitivo (9-10 abril)
|
||||
|
||||
Se creó la VM definitiva `dasu-sql4` (VM 106) con una arquitectura optimizada:
|
||||
|
||||
- **Discos separados:** 60 GB para SO + 120 GB exclusivo para datos SQL (buena práctica).
|
||||
- **SQL Server 2019 Enterprise** instalado con autenticación mixta.
|
||||
- **Gestión remota** asegurada vía OpenSSH Server (puerto 7022) y Tailscale VPN.
|
||||
|
||||
### 4.3 Fase 5: Migración de Base de Datos (11 abril)
|
||||
|
||||
Se ejecutó la migración completa de la base de datos de producción:
|
||||
|
||||
1. **Exportación:** Backup comprimido (~1.33 GB) generado desde el servidor origen (`srvv-fenix`).
|
||||
2. **Transferencia:** Archivo movido a través de la VPN institucional (Tailscale) en múltiples tramos seguros.
|
||||
3. **Restauración:** Base restaurada exitosamente en 26 segundos (354 MB/s).
|
||||
4. **Verificación:** `DBCC CHECKDB` ejecutado sin errores — integridad de datos confirmada al 100%.
|
||||
|
||||
### 4.4 Fase 5b: Hardening (11 abril)
|
||||
|
||||
Se validó que todos los servicios críticos (SSH, SQL Server) sobreviven reinicios del servidor sin intervención manual:
|
||||
|
||||
- OpenSSH Server: arranque automático ✅
|
||||
- SQL Server: arranque automático ✅
|
||||
- IP de red: mantenida tras reinicio ✅
|
||||
|
||||
### 4.5 Fase 6: Validación funcional en entorno virtual (11 abril)
|
||||
|
||||
Se restauró una VM cliente desde backup para simular el entorno real de la oficina DASUTEN:
|
||||
|
||||
- Se desvinculó la PC del dominio anterior y se unió al Workgroup `DASUTEN`.
|
||||
- Se reconfiguró el archivo de conexión del sistema (`Kermet.ini`) para apuntar al nuevo servidor SQL.
|
||||
- **Resultado:** El sistema DASUTEN conectó exitosamente, actualizó estructuras y descargó novedades.
|
||||
|
||||
**Conclusión técnica clave:** Se determinó mediante ingeniería inversa que el sistema DASUTEN (desarrollado en Visual FoxPro) **no tiene dependencia real del Active Directory** si se configura explícitamente la autenticación SQL en su archivo de configuración.
|
||||
|
||||
### 4.6 Fase 7: Despliegue en PC física de producción (13 abril — EN CURSO)
|
||||
|
||||
Se desplegó el sistema en la PC física de la oficina DASUTEN (`dasu-pc`):
|
||||
|
||||
- **Directorio del sistema** (`C:\SysDasuten`) transferido desde la VM de pruebas.
|
||||
- **Configuración de conexión** apuntada al nuevo servidor `dasu-sql4`.
|
||||
- **Acceso directo** creado en el escritorio de la usuaria (`aalmiron`).
|
||||
- **Pruebas funcionales:**
|
||||
- Inicio del sistema: ✅ OK
|
||||
- Acceso a datos (ventana de bonos): ✅ OK
|
||||
- **Impresión: ❌ FALLO** — Error al imprimir, posiblemente por incompatibilidad de las plantillas de Office (el sistema usa automatización OLE con Word/Excel).
|
||||
|
||||
### 4.7 Fase 8: Refresco final de base de datos (13 abril)
|
||||
|
||||
Se ejecutó un refresco automatizado de la base de datos para asegurar que el sistema arranca con los datos más actualizados del servidor de origen:
|
||||
|
||||
- Backup generado automáticamente desde el origen (44.8 segundos).
|
||||
- Transferido de manera segura (SMB + SCP por VPN).
|
||||
- Restaurado con `RESTORE DATABASE ... WITH REPLACE`.
|
||||
- Integridad verificada con `DBCC CHECKDB` — sin errores.
|
||||
|
||||
---
|
||||
|
||||
## 5. Estado Actual
|
||||
|
||||
### 5.1 Funcionalidades operativas
|
||||
|
||||
| Funcionalidad | Estado |
|
||||
|:---|:---:|
|
||||
| Acceso al sistema DASUTEN | ✅ Operativo |
|
||||
| Consulta de datos (bonos, registros) | ✅ Operativo |
|
||||
| Conexión a base de datos SQL Server | ✅ Operativo |
|
||||
| Acceso remoto para soporte (Tailscale/SSH) | ✅ Operativo |
|
||||
| Impresión desde el sistema | ❌ Pendiente |
|
||||
|
||||
### 5.2 Problema pendiente: Impresión
|
||||
|
||||
**Descripción:** Al intentar imprimir desde el sistema DASUTEN en la PC física, se produce un error. El diagnóstico preliminar indica que la causa es una incompatibilidad entre las **plantillas de Office** requeridas por el sistema (diseñadas para Office 2003/2007) y la versión de Office actualmente instalada en la PC.
|
||||
|
||||
**Impacto:** La usuaria no puede generar documentos impresos desde el nuevo sistema.
|
||||
|
||||
**Workaround temporal:** Se habilitó acceso remoto (TeamViewer) desde la PC física hacia la VM de pruebas (`dasu-pcv`), donde la impresión funciona correctamente. La usuaria puede continuar operando mientras se resuelve el problema.
|
||||
|
||||
**Plan de resolución:** Verificar y ajustar la versión/configuración de Office en `dasu-pc` para compatibilizarla con las plantillas del sistema.
|
||||
|
||||
---
|
||||
|
||||
## 6. Beneficios Obtenidos
|
||||
|
||||
1. **Independencia operativa:** DASUTEN ya no depende de la infraestructura de red ni de los servidores de la Facultad.
|
||||
2. **Simplificación:** Se pasó de 3 VMs + Domain Controller a solo 1 VM (SQL Server), reduciendo significativamente la complejidad.
|
||||
3. **Reducción de puntos de falla:** De múltiples (DC, DNS institucional, routing complejo) a uno solo (SQL Server).
|
||||
4. **Acceso remoto robusto:** Gestión técnica asegurada vía VPN (Tailscale) y SSH, sin necesidad de presencia física.
|
||||
5. **Autonomía:** La infraestructura puede ser gestionada independientemente, facilitando una eventual transferencia a Rectorado.
|
||||
6. **Preservación del entorno anterior:** Las VMs del enfoque con DC fueron apagadas y preservadas como respaldo, permitiendo un rollback si fuera necesario.
|
||||
|
||||
---
|
||||
|
||||
## 7. Cronograma Resumen
|
||||
|
||||
| Fecha | Hito |
|
||||
|:---|:---|
|
||||
| 27/03/2026 | Inicio — Preparación del entorno e inicio de pruebas de concepto |
|
||||
| 28/03/2026 | VM SQL Server de prueba operativa |
|
||||
| 09-10/04/2026 | Servidor SQL definitivo (dasu-sql4) desplegado y operativo |
|
||||
| 11/04/2026 | Base de datos migrada, verificada y hardening completado |
|
||||
| 11/04/2026 | Validación funcional exitosa en entorno virtual |
|
||||
| 13/04/2026 | Despliegue en PC física de producción — sistema operativo con observación de impresión |
|
||||
|
||||
---
|
||||
|
||||
## 8. Próximos Pasos
|
||||
|
||||
| Prioridad | Acción | Plazo estimado |
|
||||
|:---:|:---|:---|
|
||||
| 🔴 Alta | Resolver problema de impresión (compatibilidad Office/plantillas) | 1-3 días hábiles |
|
||||
| 🟡 Media | Reservar IPs fijas en router ISP (prevenir cambios por DHCP) | 1 semana |
|
||||
| 🟢 Baja | Evaluar apagado definitivo de VMs legacy (DC, SQL antiguo) | Tras validación completa |
|
||||
| 🟢 Baja | Documentar procedimiento de respaldo automatizado de la nueva BD | 2 semanas |
|
||||
|
||||
---
|
||||
|
||||
## 9. Conclusión
|
||||
|
||||
La migración del sistema DASUTEN a la nueva infraestructura se encuentra **prácticamente completada**, con el sistema operativo y los datos verificados. El enfoque sin Domain Controller demostró ser completamente viable, logrando una **reducción significativa de la complejidad** y de los puntos de falla.
|
||||
|
||||
El único aspecto pendiente es la resolución del problema de impresión, para el cual ya se dispone de un workaround funcional que permite a la usuaria continuar operando sin interrupción.
|
||||
|
||||
Se estima que el proyecto quedará **100% finalizado** dentro de los próximos días hábiles, una vez resuelta la compatibilidad de plantillas de Office.
|
||||
|
||||
---
|
||||
|
||||
# ANEXO TÉCNICO
|
||||
|
||||
## A. Inventario de Nodos
|
||||
|
||||
### A.1 Servidor Hipervisor: srv-dasu
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Hipervisor Proxmox VE 9.1 |
|
||||
| **IP LAN** | 192.168.1.13 (DHCP ISP) |
|
||||
| **IP VPN** | 100.112.46.104 (Tailscale) |
|
||||
| **Bridge** | vmbr0 sobre enp33s0 |
|
||||
| **RAM** | 15 GB total / ~4 GB libre post-VMs |
|
||||
| **Disco** | 94 GB (68% uso, thin provisioned) |
|
||||
| **Acceso remoto** | Tailscale + SSH |
|
||||
|
||||
### A.2 Servidor SQL: dasu-sql4 (VM 106)
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | SQL Server 2019 Enterprise |
|
||||
| **SO** | Windows Server 2022 (Español) |
|
||||
| **IP LAN** | 192.168.1.11 (DHCP ISP) |
|
||||
| **IP VPN** | 100.107.15.82 (Tailscale — inestable) |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **RAM** | 4 GB |
|
||||
| **vCPU** | 2 |
|
||||
| **Disco 1 (sata0)** | 60 GB — Sistema Operativo |
|
||||
| **Disco 2 (sata1)** | 120 GB — Datos SQL (GPT/NTFS "SQLData") |
|
||||
| **Estructura SQL** | F:\DATA, F:\LOG, F:\BACKUP, F:\TEMPDB |
|
||||
| **Autenticación** | Mixta (SQL Auth + Windows) |
|
||||
| **Puerto SQL** | TCP 1433 |
|
||||
| **SSH** | Puerto 7022 (OpenSSH Server, arranque automático) |
|
||||
| **Servicios auto-start** | MSSQLSERVER, sshd |
|
||||
|
||||
### A.3 PC Física Cliente: dasu-pc
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Estación de trabajo DASUTEN |
|
||||
| **Patrimonio** | 32120 |
|
||||
| **Ubicación** | Oficina DASUTEN (externa a Facultad) |
|
||||
| **SO** | Windows 10 Pro |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **IP VPN** | 100.119.233.11 (Tailscale) |
|
||||
| **SSH** | UTNLR@100.119.233.11:7022 |
|
||||
| **CPU** | AMD Ryzen 5 4600G @ 4.30GHz (6 núcleos) |
|
||||
| **RAM** | 8 GB DDR4-3200 |
|
||||
| **Placa Base** | Asus Prime A320M-K |
|
||||
| **Usuaria principal** | Andrea Almirón (`aalmiron`) |
|
||||
| **Directorio DASUTEN** | C:\SysDasuten |
|
||||
| **Config conexión** | C:\SysDasuten\Sistema\Kermet.ini |
|
||||
|
||||
### A.4 VM Cliente de Pruebas: dasu-pcv (VM 107) — Test-Bed
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Entorno de pruebas / fallback temporal |
|
||||
| **SO** | Windows 10 |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **SSH** | Puerto 7022 |
|
||||
| **Estado** | Operativa (usada como fallback vía TeamViewer) |
|
||||
|
||||
---
|
||||
|
||||
## B. Configuración del Sistema DASUTEN
|
||||
|
||||
### B.1 Archivo de conexión: Kermet.ini
|
||||
|
||||
Parámetros clave configurados para la operación sin Domain Controller:
|
||||
|
||||
```ini
|
||||
SERVER=dasu-sql4
|
||||
DATABASE=sysdasuten
|
||||
UID=sa
|
||||
PWD=[credencial almacenada en bóveda]
|
||||
```
|
||||
|
||||
> **Nota técnica:** El campo `UID` debe estar explícitamente configurado con `sa` (u otra cuenta SQL Auth). Si se deja vacío, el sistema DASUTEN (Visual FoxPro) asume autenticación Windows integrada (SSPI/Kerberos), lo cual falla en entorno Workgroup sin Domain Controller.
|
||||
|
||||
### B.2 Directorio del sistema
|
||||
|
||||
```
|
||||
C:\SysDasuten\
|
||||
├── Sistema\ → Ejecutables VFP + Kermet.ini
|
||||
├── Plantillas\ → Templates Word/Excel para impresión
|
||||
└── [otros directorios de la aplicación]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## C. Base de Datos: sysdasuten
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Nombre** | sysdasuten |
|
||||
| **Motor** | SQL Server 2019 Enterprise |
|
||||
| **Tamaño backup comprimido** | ~1.33 GB |
|
||||
| **Nivel de compatibilidad** | 100 |
|
||||
| **Recovery model** | FULL |
|
||||
| **Integridad (DBCC CHECKDB)** | ✅ Sin errores |
|
||||
| **Tiempo de restauración** | 26 segundos (354 MB/s) |
|
||||
| **Origen de datos** | srvv-fenix (servidor legacy de Facultad) |
|
||||
| **Último refresco** | 13/04/2026 |
|
||||
|
||||
### C.1 Ruta de transferencia del backup
|
||||
|
||||
```
|
||||
srvv-fenix (Origen)
|
||||
│ [BACKUP DATABASE ... WITH COMPRESSION]
|
||||
│ → E:\BK_SQL\sysdasuten_compressed_ADN.bak (~1.33 GB)
|
||||
↓
|
||||
srv-ns8 (Tránsito)
|
||||
│ [SMB/smbget vía dominio]
|
||||
│ → /var/tmp/
|
||||
↓
|
||||
srv-dasu (Tránsito)
|
||||
│ [SCP vía Tailscale]
|
||||
↓
|
||||
dasu-sql4 (Destino)
|
||||
│ [RESTORE DATABASE ... WITH REPLACE]
|
||||
└ → F:\BACKUP\ → F:\DATA\ + F:\LOG\
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## D. VMs Legacy Preservadas (Apagadas)
|
||||
|
||||
| VM ID | Nombre | Rol anterior | Estado |
|
||||
|:---:|:---|:---|:---:|
|
||||
| 100 | dasu-srvv-dc | Domain Controller AD DS | 🛑 Apagada |
|
||||
| 101 | dasu-srvv-sql | SQL Server (dominio) | 🛑 Apagada |
|
||||
| 102 | dasu-pcv | PC cliente (dominio) | 🛑 Apagada |
|
||||
| 103 | dasu-sql2 | SQL Server prueba v1 | 🛑 Descartada |
|
||||
| 104 | dasu-pcv2 | PC prueba v1 | 🛑 Descartada |
|
||||
|
||||
> Las VMs legacy (100-102) se mantienen apagadas como respaldo. Pueden reactivarse en caso de necesitar un rollback al enfoque con Domain Controller.
|
||||
|
||||
---
|
||||
|
||||
## E. Accesos Remotos Configurados
|
||||
|
||||
| Nodo | Método | Detalle |
|
||||
|:---|:---|:---|
|
||||
| srv-dasu | Tailscale SSH | 100.112.46.104 |
|
||||
| dasu-sql4 | SSH (LAN) | 192.168.1.11:7022 |
|
||||
| dasu-sql4 | Tailscale | 100.107.15.82 (inestable) |
|
||||
| dasu-pc | Tailscale SSH | 100.119.233.11:7022 |
|
||||
| dasu-pc | AnyDesk | Instalado (GUI) |
|
||||
| dasu-pcv | TeamViewer | Activo (workaround temporal) |
|
||||
|
||||
---
|
||||
|
||||
## F. Cuenta de Gestión VPN
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Proveedor** | Tailscale |
|
||||
| **Cuenta** | pcdasu0@frlr.utn.edu.ar |
|
||||
| **Nodos vinculados** | srv-dasu, dasu-sql4, dasu-pc, dasu-pcv |
|
||||
|
||||
---
|
||||
|
||||
*Fin del informe técnico.*
|
||||
@@ -0,0 +1,407 @@
|
||||
# INFORME TÉCNICO — Migración del Sistema DASUTEN a Nuevo Servidor
|
||||
|
||||
> **Área:** Departamento de Tecnología de la Información y Comunicaciones (DTIC)
|
||||
> **Proyecto:** Migración de infraestructura DASUTEN — Modo Workgroup sin Domain Controller
|
||||
> **Código interno:** A04.P005
|
||||
> **Fecha del informe:** 13 de abril de 2026
|
||||
> **Elaborado por:** Ricardo Monla — Área DTIC, UTN-FRLR
|
||||
|
||||
---
|
||||
|
||||
## 1. Resumen Ejecutivo
|
||||
|
||||
Se informa el avance de la migración del sistema de gestión administrativa **DASUTEN** (Departamento de Acción Social Universitaria Tecnológica Nacional) desde la infraestructura compartida de la Facultad hacia un entorno independiente, autónomo y simplificado.
|
||||
|
||||
**Estado general del proyecto: 95% completado.**
|
||||
|
||||
El sistema DASUTEN se encuentra **operativo** en la nueva infraestructura desde el día 13 de abril de 2026, habiendo superado exitosamente las pruebas funcionales de acceso a datos. Resta únicamente resolver un problema de compatibilidad de impresión vinculado a las plantillas de Office utilizadas por el sistema.
|
||||
|
||||
### Logros principales
|
||||
|
||||
- ✅ Servidor de base de datos **completamente migrado** a infraestructura nueva.
|
||||
- ✅ Base de datos de producción **restaurada y verificada** sin errores de integridad.
|
||||
- ✅ Sistema DASUTEN **desplegado y operativo** en la PC física de la usuaria.
|
||||
- ✅ Eliminación exitosa de la dependencia del **Active Directory (Domain Controller)**.
|
||||
- ✅ Simplificación de la arquitectura de red — de 3 servidores virtuales a 1.
|
||||
- ⚠️ Pendiente: resolución de problema de impresión por compatibilidad de plantillas Office.
|
||||
|
||||
---
|
||||
|
||||
## 2. Antecedentes y Motivación
|
||||
|
||||
### 2.1 Situación previa
|
||||
|
||||
El sistema DASUTEN operaba sobre infraestructura compartida con la Facultad Regional La Rioja, dependiendo de:
|
||||
|
||||
- Un servidor SQL Server alojado en la red interna de la Facultad (`srvv-fenix`).
|
||||
- Un Domain Controller Active Directory para la autenticación de usuarios.
|
||||
- Conectividad de red interna de la Facultad con routing complejo.
|
||||
|
||||
Esta configuración generaba **múltiples puntos de falla**:
|
||||
- Dependencia del dominio institucional para la autenticación.
|
||||
- Complejidad de red con subnetting privado, NAT y gateway interno.
|
||||
- Cualquier cambio en la infraestructura de la Facultad impactaba directamente en DASUTEN.
|
||||
|
||||
### 2.2 Objetivo del proyecto
|
||||
|
||||
**Migrar el sistema DASUTEN a una infraestructura independiente y simplificada**, eliminando la dependencia del Domain Controller (Active Directory) y utilizando un esquema de red **Workgroup** directo, con el fin de:
|
||||
|
||||
1. Reducir la complejidad operativa.
|
||||
2. Minimizar los puntos de falla.
|
||||
3. Garantizar la autonomía operativa de DASUTEN respecto de la infraestructura de la Facultad.
|
||||
4. Facilitar la eventual gestión desde Rectorado (Buenos Aires) si fuera necesario.
|
||||
|
||||
---
|
||||
|
||||
## 3. Infraestructura Implementada
|
||||
|
||||
### 3.1 Arquitectura de red
|
||||
|
||||
Se implementó una topología de **red plana simplificada**, donde todos los equipos obtienen direccionamiento IP directamente del router del ISP, eliminando subnetting privado y routing interno:
|
||||
|
||||
```
|
||||
Internet
|
||||
│
|
||||
Router ISP (192.168.1.1 — Gateway)
|
||||
│
|
||||
├── srv-dasu (Proxmox VE) → 192.168.1.13
|
||||
│ └── dasu-sql4 (VM 106) → 192.168.1.11 [SQL Server 2019]
|
||||
│
|
||||
└── dasu-pc (PC Física) → DHCP ISP [Estación de trabajo]
|
||||
```
|
||||
|
||||
### 3.2 Componentes del nuevo entorno
|
||||
|
||||
| Componente | Descripción | Estado |
|
||||
|:---|:---|:---:|
|
||||
| **srv-dasu** | Servidor Proxmox VE 9.1 (Hipervisor) — CPU Intel, 15 GB RAM, 94 GB disco | ✅ Operativo |
|
||||
| **dasu-sql4** (VM 106) | Windows Server 2022 — SQL Server 2019 Enterprise — 4 GB RAM, 2 vCPU, discos 60+120 GB | ✅ Operativo |
|
||||
| **dasu-pc** | PC Física — Windows 10 Pro — AMD Ryzen 5, 8 GB RAM — Oficina DASUTEN | ✅ Operativo |
|
||||
|
||||
### 3.3 Comparativa: Antes vs. Después
|
||||
|
||||
| Aspecto | Enfoque Anterior (con DC) | Enfoque Actual (Workgroup) |
|
||||
|:---|:---|:---|
|
||||
| **Red** | Privada 10.0.100.x (gateway interno) | DHCP del ISP (red plana) |
|
||||
| **Autenticación SQL** | Windows Integrated (Kerberos) | SQL Auth (mixta) |
|
||||
| **Usuarios** | Active Directory | Usuarios locales Windows |
|
||||
| **DNS** | AD DNS (10.0.100.10) | DNS del ISP (automático) |
|
||||
| **Complejidad de red** | Alta (DC + DNS + dominio + routing) | Mínima (red plana ISP) |
|
||||
| **Puntos de falla** | DC, SQL, red dominio, routing | Solo SQL |
|
||||
| **VMs necesarias** | 3 (DC + SQL + PC) | 1 (solo SQL) |
|
||||
|
||||
---
|
||||
|
||||
## 4. Fases Ejecutadas y Progreso
|
||||
|
||||
### Resumen de progreso por fase
|
||||
|
||||
| Fase | Descripción | Estado | Progreso |
|
||||
|:---:|:---|:---:|:---:|
|
||||
| 1 | Preparación del entorno (srv-dasu) | ✅ Completada | 100% |
|
||||
| 2 | Creación de VM SQL Server de prueba | ✅ Completada | 100% |
|
||||
| 3 | Creación de VM PC Cliente de prueba | ✅ Completada | 100% |
|
||||
| 4 | VM definitiva dasu-sql4 | ✅ Completada | 100% |
|
||||
| 5 | Migración de base de datos | ✅ Completada | 100% |
|
||||
| 5b | Hardening y persistencia de servicios | ✅ Completada | 100% |
|
||||
| 6 | Validación con PC cliente virtual | ✅ Completada | 100% |
|
||||
| 7 | Despliegue en PC física (producción) | 🚧 En curso | 75% |
|
||||
| 8 | Refresco final de base de datos | ✅ Completada | 100% |
|
||||
|
||||
### 4.1 Fase 1-3: Preparación y pruebas de concepto (27-28 marzo)
|
||||
|
||||
Se preparó el hipervisor Proxmox, se reconfiguró el bridge de red para usar DHCP directo del ISP, y se crearon VMs de prueba para validar la viabilidad del enfoque sin Domain Controller.
|
||||
|
||||
**Hallazgo crítico:** Se detectó y resolvió que el bridge de red estaba configurado con la IP de una red privada anterior, lo cual habría impedido la conectividad de las nuevas VMs.
|
||||
|
||||
### 4.2 Fase 4: Servidor SQL definitivo (9-10 abril)
|
||||
|
||||
Se creó la VM definitiva `dasu-sql4` (VM 106) con una arquitectura optimizada:
|
||||
|
||||
- **Discos separados:** 60 GB para SO + 120 GB exclusivo para datos SQL (buena práctica).
|
||||
- **SQL Server 2019 Enterprise** instalado con autenticación mixta.
|
||||
- **Gestión remota** asegurada vía OpenSSH Server (puerto 7022) y Tailscale VPN.
|
||||
|
||||
### 4.3 Fase 5: Migración de Base de Datos (11 abril)
|
||||
|
||||
Se ejecutó la migración completa de la base de datos de producción:
|
||||
|
||||
1. **Exportación:** Backup comprimido (~1.33 GB) generado desde el servidor origen (`srvv-fenix`).
|
||||
2. **Transferencia:** Archivo movido a través de la VPN institucional (Tailscale) en múltiples tramos seguros.
|
||||
3. **Restauración:** Base restaurada exitosamente en 26 segundos (354 MB/s).
|
||||
4. **Verificación:** `DBCC CHECKDB` ejecutado sin errores — integridad de datos confirmada al 100%.
|
||||
|
||||
### 4.4 Fase 5b: Hardening (11 abril)
|
||||
|
||||
Se validó que todos los servicios críticos (SSH, SQL Server) sobreviven reinicios del servidor sin intervención manual:
|
||||
|
||||
- OpenSSH Server: arranque automático ✅
|
||||
- SQL Server: arranque automático ✅
|
||||
- IP de red: mantenida tras reinicio ✅
|
||||
|
||||
### 4.5 Fase 6: Validación funcional en entorno virtual (11 abril)
|
||||
|
||||
Se restauró una VM cliente desde backup para simular el entorno real de la oficina DASUTEN:
|
||||
|
||||
- Se desvinculó la PC del dominio anterior y se unió al Workgroup `DASUTEN`.
|
||||
- Se reconfiguró el archivo de conexión del sistema (`Kermet.ini`) para apuntar al nuevo servidor SQL.
|
||||
- **Resultado:** El sistema DASUTEN conectó exitosamente, actualizó estructuras y descargó novedades.
|
||||
|
||||
**Conclusión técnica clave:** Se determinó mediante ingeniería inversa que el sistema DASUTEN (desarrollado en Visual FoxPro) **no tiene dependencia real del Active Directory** si se configura explícitamente la autenticación SQL en su archivo de configuración.
|
||||
|
||||
### 4.6 Fase 7: Despliegue en PC física de producción (13 abril — EN CURSO)
|
||||
|
||||
Se desplegó el sistema en la PC física de la oficina DASUTEN (`dasu-pc`):
|
||||
|
||||
- **Directorio del sistema** (`C:\SysDasuten`) transferido desde la VM de pruebas.
|
||||
- **Configuración de conexión** apuntada al nuevo servidor `dasu-sql4`.
|
||||
- **Acceso directo** creado en el escritorio de la usuaria (`aalmiron`).
|
||||
- **Pruebas funcionales:**
|
||||
- Inicio del sistema: ✅ OK
|
||||
- Acceso a datos (ventana de bonos): ✅ OK
|
||||
- **Impresión: ❌ FALLO** — Error al imprimir, posiblemente por incompatibilidad de las plantillas de Office (el sistema usa automatización OLE con Word/Excel).
|
||||
|
||||
### 4.7 Fase 8: Refresco final de base de datos (13 abril)
|
||||
|
||||
Se ejecutó un refresco automatizado de la base de datos para asegurar que el sistema arranca con los datos más actualizados del servidor de origen:
|
||||
|
||||
- Backup generado automáticamente desde el origen (44.8 segundos).
|
||||
- Transferido de manera segura (SMB + SCP por VPN).
|
||||
- Restaurado con `RESTORE DATABASE ... WITH REPLACE`.
|
||||
- Integridad verificada con `DBCC CHECKDB` — sin errores.
|
||||
|
||||
---
|
||||
|
||||
## 5. Estado Actual
|
||||
|
||||
### 5.1 Funcionalidades operativas
|
||||
|
||||
| Funcionalidad | Estado |
|
||||
|:---|:---:|
|
||||
| Acceso al sistema DASUTEN | ✅ Operativo |
|
||||
| Consulta de datos (bonos, registros) | ✅ Operativo |
|
||||
| Conexión a base de datos SQL Server | ✅ Operativo |
|
||||
| Acceso remoto para soporte (Tailscale/SSH) | ✅ Operativo |
|
||||
| Impresión desde el sistema | ❌ Pendiente |
|
||||
|
||||
### 5.2 Problema pendiente: Impresión
|
||||
|
||||
**Descripción:** Al intentar imprimir desde el sistema DASUTEN en la PC física, se produce un error. El diagnóstico preliminar indica que la causa es una incompatibilidad entre las **plantillas de Office** requeridas por el sistema (diseñadas para Office 2003/2007) y la versión de Office actualmente instalada en la PC.
|
||||
|
||||
**Impacto:** La usuaria no puede generar documentos impresos desde el nuevo sistema.
|
||||
|
||||
**Workaround temporal:** Se habilitó acceso remoto (TeamViewer) desde la PC física hacia la VM de pruebas (`dasu-pcv`), donde la impresión funciona correctamente. La usuaria puede continuar operando mientras se resuelve el problema.
|
||||
|
||||
**Plan de resolución:** Verificar y ajustar la versión/configuración de Office en `dasu-pc` para compatibilizarla con las plantillas del sistema.
|
||||
|
||||
---
|
||||
|
||||
## 6. Beneficios Obtenidos
|
||||
|
||||
1. **Independencia operativa:** DASUTEN ya no depende de la infraestructura de red ni de los servidores de la Facultad.
|
||||
2. **Simplificación:** Se pasó de 3 VMs + Domain Controller a solo 1 VM (SQL Server), reduciendo significativamente la complejidad.
|
||||
3. **Reducción de puntos de falla:** De múltiples (DC, DNS institucional, routing complejo) a uno solo (SQL Server).
|
||||
4. **Acceso remoto robusto:** Gestión técnica asegurada vía VPN (Tailscale) y SSH, sin necesidad de presencia física.
|
||||
5. **Autonomía:** La infraestructura puede ser gestionada independientemente, facilitando una eventual transferencia a Rectorado.
|
||||
6. **Preservación del entorno anterior:** Las VMs del enfoque con DC fueron apagadas y preservadas como respaldo, permitiendo un rollback si fuera necesario.
|
||||
|
||||
---
|
||||
|
||||
## 7. Cronograma Resumen
|
||||
|
||||
| Fecha | Hito |
|
||||
|:---|:---|
|
||||
| 27/03/2026 | Inicio — Preparación del entorno e inicio de pruebas de concepto |
|
||||
| 28/03/2026 | VM SQL Server de prueba operativa |
|
||||
| 09-10/04/2026 | Servidor SQL definitivo (dasu-sql4) desplegado y operativo |
|
||||
| 11/04/2026 | Base de datos migrada, verificada y hardening completado |
|
||||
| 11/04/2026 | Validación funcional exitosa en entorno virtual |
|
||||
| 13/04/2026 | Despliegue en PC física de producción — sistema operativo con observación de impresión |
|
||||
|
||||
---
|
||||
|
||||
## 8. Próximos Pasos
|
||||
|
||||
| Prioridad | Acción | Plazo estimado |
|
||||
|:---:|:---|:---|
|
||||
| 🔴 Alta | Resolver problema de impresión (compatibilidad Office/plantillas) | 1-3 días hábiles |
|
||||
| 🟡 Media | Reservar IPs fijas en router ISP (prevenir cambios por DHCP) | 1 semana |
|
||||
| 🟢 Baja | Evaluar apagado definitivo de VMs legacy (DC, SQL antiguo) | Tras validación completa |
|
||||
| 🟢 Baja | Documentar procedimiento de respaldo automatizado de la nueva BD | 2 semanas |
|
||||
|
||||
---
|
||||
|
||||
## 9. Conclusión
|
||||
|
||||
La migración del sistema DASUTEN a la nueva infraestructura se encuentra **prácticamente completada**, con el sistema operativo y los datos verificados. El enfoque sin Domain Controller demostró ser completamente viable, logrando una **reducción significativa de la complejidad** y de los puntos de falla.
|
||||
|
||||
El único aspecto pendiente es la resolución del problema de impresión, para el cual ya se dispone de un workaround funcional que permite a la usuaria continuar operando sin interrupción.
|
||||
|
||||
Se estima que el proyecto quedará **100% finalizado** dentro de los próximos días hábiles, una vez resuelta la compatibilidad de plantillas de Office.
|
||||
|
||||
---
|
||||
|
||||
# ANEXO TÉCNICO
|
||||
|
||||
## A. Inventario de Nodos
|
||||
|
||||
### A.1 Servidor Hipervisor: srv-dasu
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Hipervisor Proxmox VE 9.1 |
|
||||
| **IP LAN** | 192.168.1.13 (DHCP ISP) |
|
||||
| **IP VPN** | 100.112.46.104 (Tailscale) |
|
||||
| **Bridge** | vmbr0 sobre enp33s0 |
|
||||
| **RAM** | 15 GB total / ~4 GB libre post-VMs |
|
||||
| **Disco** | 94 GB (68% uso, thin provisioned) |
|
||||
| **Acceso remoto** | Tailscale + SSH |
|
||||
|
||||
### A.2 Servidor SQL: dasu-sql4 (VM 106)
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | SQL Server 2019 Enterprise |
|
||||
| **SO** | Windows Server 2022 (Español) |
|
||||
| **IP LAN** | 192.168.1.11 (DHCP ISP) |
|
||||
| **IP VPN** | 100.107.15.82 (Tailscale — inestable) |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **RAM** | 4 GB |
|
||||
| **vCPU** | 2 |
|
||||
| **Disco 1 (sata0)** | 60 GB — Sistema Operativo |
|
||||
| **Disco 2 (sata1)** | 120 GB — Datos SQL (GPT/NTFS "SQLData") |
|
||||
| **Estructura SQL** | F:\DATA, F:\LOG, F:\BACKUP, F:\TEMPDB |
|
||||
| **Autenticación** | Mixta (SQL Auth + Windows) |
|
||||
| **Puerto SQL** | TCP 1433 |
|
||||
| **SSH** | Puerto 7022 (OpenSSH Server, arranque automático) |
|
||||
| **Servicios auto-start** | MSSQLSERVER, sshd |
|
||||
|
||||
### A.3 PC Física Cliente: dasu-pc
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Estación de trabajo DASUTEN |
|
||||
| **Patrimonio** | 32120 |
|
||||
| **Ubicación** | Oficina DASUTEN (externa a Facultad) |
|
||||
| **SO** | Windows 10 Pro |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **IP VPN** | 100.119.233.11 (Tailscale) |
|
||||
| **SSH** | UTNLR@100.119.233.11:7022 |
|
||||
| **CPU** | AMD Ryzen 5 4600G @ 4.30GHz (6 núcleos) |
|
||||
| **RAM** | 8 GB DDR4-3200 |
|
||||
| **Placa Base** | Asus Prime A320M-K |
|
||||
| **Usuaria principal** | Andrea Almirón (`aalmiron`) |
|
||||
| **Directorio DASUTEN** | C:\SysDasuten |
|
||||
| **Config conexión** | C:\SysDasuten\Sistema\Kermet.ini |
|
||||
|
||||
### A.4 VM Cliente de Pruebas: dasu-pcv (VM 107) — Test-Bed
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Entorno de pruebas / fallback temporal |
|
||||
| **SO** | Windows 10 |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **SSH** | Puerto 7022 |
|
||||
| **Estado** | Operativa (usada como fallback vía TeamViewer) |
|
||||
|
||||
---
|
||||
|
||||
## B. Configuración del Sistema DASUTEN
|
||||
|
||||
### B.1 Archivo de conexión: Kermet.ini
|
||||
|
||||
Parámetros clave configurados para la operación sin Domain Controller:
|
||||
|
||||
```ini
|
||||
SERVER=dasu-sql4
|
||||
DATABASE=sysdasuten
|
||||
UID=sa
|
||||
PWD=[credencial almacenada en bóveda]
|
||||
```
|
||||
|
||||
> **Nota técnica:** El campo `UID` debe estar explícitamente configurado con `sa` (u otra cuenta SQL Auth). Si se deja vacío, el sistema DASUTEN (Visual FoxPro) asume autenticación Windows integrada (SSPI/Kerberos), lo cual falla en entorno Workgroup sin Domain Controller.
|
||||
|
||||
### B.2 Directorio del sistema
|
||||
|
||||
```
|
||||
C:\SysDasuten\
|
||||
├── Sistema\ → Ejecutables VFP + Kermet.ini
|
||||
├── Plantillas\ → Templates Word/Excel para impresión
|
||||
└── [otros directorios de la aplicación]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## C. Base de Datos: sysdasuten
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Nombre** | sysdasuten |
|
||||
| **Motor** | SQL Server 2019 Enterprise |
|
||||
| **Tamaño backup comprimido** | ~1.33 GB |
|
||||
| **Nivel de compatibilidad** | 100 |
|
||||
| **Recovery model** | FULL |
|
||||
| **Integridad (DBCC CHECKDB)** | ✅ Sin errores |
|
||||
| **Tiempo de restauración** | 26 segundos (354 MB/s) |
|
||||
| **Origen de datos** | srvv-fenix (servidor legacy de Facultad) |
|
||||
| **Último refresco** | 13/04/2026 |
|
||||
|
||||
### C.1 Ruta de transferencia del backup
|
||||
|
||||
```
|
||||
srvv-fenix (Origen)
|
||||
│ [BACKUP DATABASE ... WITH COMPRESSION]
|
||||
│ → E:\BK_SQL\sysdasuten_compressed_ADN.bak (~1.33 GB)
|
||||
↓
|
||||
srv-ns8 (Tránsito)
|
||||
│ [SMB/smbget vía dominio]
|
||||
│ → /var/tmp/
|
||||
↓
|
||||
srv-dasu (Tránsito)
|
||||
│ [SCP vía Tailscale]
|
||||
↓
|
||||
dasu-sql4 (Destino)
|
||||
│ [RESTORE DATABASE ... WITH REPLACE]
|
||||
└ → F:\BACKUP\ → F:\DATA\ + F:\LOG\
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## D. VMs Legacy Preservadas (Apagadas)
|
||||
|
||||
| VM ID | Nombre | Rol anterior | Estado |
|
||||
|:---:|:---|:---|:---:|
|
||||
| 100 | dasu-srvv-dc | Domain Controller AD DS | 🛑 Apagada |
|
||||
| 101 | dasu-srvv-sql | SQL Server (dominio) | 🛑 Apagada |
|
||||
| 102 | dasu-pcv | PC cliente (dominio) | 🛑 Apagada |
|
||||
| 103 | dasu-sql2 | SQL Server prueba v1 | 🛑 Descartada |
|
||||
| 104 | dasu-pcv2 | PC prueba v1 | 🛑 Descartada |
|
||||
|
||||
> Las VMs legacy (100-102) se mantienen apagadas como respaldo. Pueden reactivarse en caso de necesitar un rollback al enfoque con Domain Controller.
|
||||
|
||||
---
|
||||
|
||||
## E. Accesos Remotos Configurados
|
||||
|
||||
| Nodo | Método | Detalle |
|
||||
|:---|:---|:---|
|
||||
| srv-dasu | Tailscale SSH | 100.112.46.104 |
|
||||
| dasu-sql4 | SSH (LAN) | 192.168.1.11:7022 |
|
||||
| dasu-sql4 | Tailscale | 100.107.15.82 (inestable) |
|
||||
| dasu-pc | Tailscale SSH | 100.119.233.11:7022 |
|
||||
| dasu-pc | AnyDesk | Instalado (GUI) |
|
||||
| dasu-pcv | TeamViewer | Activo (workaround temporal) |
|
||||
|
||||
---
|
||||
|
||||
## F. Cuenta de Gestión VPN
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Proveedor** | Tailscale |
|
||||
| **Cuenta** | pcdasu0@frlr.utn.edu.ar |
|
||||
| **Nodos vinculados** | srv-dasu, dasu-sql4, dasu-pc, dasu-pcv |
|
||||
|
||||
---
|
||||
|
||||
*Fin del informe técnico.*
|
||||
@@ -0,0 +1,446 @@
|
||||
# INFORME TÉCNICO — Migración del Sistema DASUTEN a Nuevo Servidor
|
||||
|
||||
> **Área:** Departamento de Tecnología de la Información y Comunicaciones (DTIC)
|
||||
> **Proyecto:** Migración de infraestructura DASUTEN — Modo Workgroup sin Domain Controller
|
||||
> **Código interno:** A04.P005
|
||||
> **Fecha del informe:** 13 de abril de 2026
|
||||
> **Elaborado por:** Ricardo Monla — Área DTIC, UTN-FRLR
|
||||
> **Versión:** 0.2
|
||||
>
|
||||
> *Este documento contiene el detalle técnico completo de la migración. Para la síntesis ejecutiva, ver [01_informe_ejecutivo_DASUTEN.md](01_informe_ejecutivo_DASUTEN.md).*
|
||||
|
||||
---
|
||||
|
||||
## 1. Resumen Ejecutivo
|
||||
|
||||
Se informa el avance de la migración del sistema de gestión administrativa **DASUTEN** (Departamento de Acción Social Universitaria Tecnológica Nacional) desde la infraestructura compartida de la Facultad hacia un entorno independiente, autónomo y simplificado.
|
||||
|
||||
**Estado general del proyecto: 95% completado.**
|
||||
|
||||
El sistema DASUTEN se encuentra **operativo** en la nueva infraestructura desde el día 13 de abril de 2026, habiendo superado exitosamente las pruebas funcionales de acceso a datos. Resta únicamente resolver un problema de compatibilidad de impresión vinculado a las plantillas de Office utilizadas por el sistema.
|
||||
|
||||
### Logros principales
|
||||
|
||||
- ✅ Servidor de base de datos **completamente migrado** a infraestructura nueva.
|
||||
- ✅ Base de datos de producción **restaurada y verificada** sin errores de integridad.
|
||||
- ✅ Sistema DASUTEN **desplegado y operativo** en la PC física de la usuaria.
|
||||
- ✅ Eliminación exitosa de la dependencia del **Active Directory (Domain Controller)**.
|
||||
- ✅ Simplificación de la arquitectura de red — de 3 servidores virtuales a 1.
|
||||
- ⚠️ Pendiente: resolución de problema de impresión por compatibilidad de plantillas Office.
|
||||
|
||||
---
|
||||
|
||||
## 2. Antecedentes y Motivación
|
||||
|
||||
### 2.1 Infraestructura original (en red de Facultad)
|
||||
|
||||
El sistema DASUTEN operaba sobre infraestructura compartida con la Facultad Regional La Rioja, dependiendo de:
|
||||
|
||||
- Un servidor SQL Server alojado en la red interna de la Facultad (`srvv-fenix`).
|
||||
- Un Domain Controller Active Directory para la autenticación de usuarios.
|
||||
- Conectividad de red interna de la Facultad con routing complejo.
|
||||
|
||||
Esta configuración generaba **múltiples puntos de falla**:
|
||||
- Dependencia del dominio institucional para la autenticación.
|
||||
- Complejidad de red con subnetting privado, NAT y gateway interno.
|
||||
- Cualquier cambio en la infraestructura de la Facultad impactaba directamente en DASUTEN.
|
||||
|
||||
### 2.2 Esquema de trabajo provisorio (AnyDesk + PC Virtual)
|
||||
|
||||
Al reubicarse la oficina DASUTEN en un espacio propio alejado de los servidores, se agravaron las fallas de conectividad: la señal de red recorría múltiples puntos intermedios dentro del edificio, y la caída de cualquiera de ellos dejaba a la oficina sin sistema.
|
||||
|
||||
Para dar continuidad al servicio, se gestionó una **línea de internet propia** para la oficina y se implementó el siguiente esquema de trabajo:
|
||||
|
||||
```
|
||||
PC Física (dasu-pc) Servidor srv-dasu (Proxmox VE)
|
||||
Usuarias: Almirón / Molina ├── VM 100: dasu-srvv-dc (Domain Controller AD DS)
|
||||
Acceso: AnyDesk ──────────────────► ├── VM 101: dasu-srvv-sql (SQL Server + BD sysdasuten)
|
||||
(escritorio remoto) └── VM 102: dasu-pcv (PC Virtual ← trabajo aquí)
|
||||
```
|
||||
|
||||
**Componentes requeridos:** 4 (servidor dominio + servidor BD + PC virtual + PC física con AnyDesk).
|
||||
|
||||
**Flujo de trabajo de las usuarias:** PC física → AnyDesk (escritorio remoto) → PC virtual → sistema DASUTEN.
|
||||
|
||||
Este esquema permitió:
|
||||
- Dar continuidad al servicio independientemente de la red interna de la Facultad.
|
||||
- Brindar asistencia técnica 24/7 por parte de DTIC vía acceso remoto.
|
||||
|
||||
Pero implicaba:
|
||||
- Experiencia de trabajo **indirecta** para las usuarias (doble salto).
|
||||
- Cuatro componentes simultáneos que debían estar operativos.
|
||||
- Múltiples puntos de falla que dificultaban el soporte.
|
||||
|
||||
### 2.3 Objetivo del proyecto
|
||||
|
||||
**Migrar el sistema DASUTEN a una infraestructura independiente y simplificada**, eliminando la dependencia del Domain Controller (Active Directory), el esquema de escritorio remoto, y utilizando un esquema de red **Workgroup** directo, con el fin de:
|
||||
|
||||
1. Reducir la complejidad operativa (de 4 componentes a 2).
|
||||
2. Permitir trabajo directo (sin AnyDesk intermedio).
|
||||
3. Minimizar los puntos de falla.
|
||||
4. Garantizar la autonomía operativa de DASUTEN respecto de la infraestructura de la Facultad.
|
||||
5. Facilitar la eventual gestión desde Rectorado (Buenos Aires) si fuera necesario.
|
||||
|
||||
---
|
||||
|
||||
## 3. Infraestructura Implementada
|
||||
|
||||
### 3.1 Arquitectura de red
|
||||
|
||||
Se implementó una topología de **red plana simplificada**, donde todos los equipos obtienen direccionamiento IP directamente del router del ISP, eliminando subnetting privado y routing interno:
|
||||
|
||||
```
|
||||
Internet
|
||||
│
|
||||
Router ISP (192.168.1.1 — Gateway)
|
||||
│
|
||||
├── srv-dasu (Proxmox VE) → 192.168.1.13
|
||||
│ └── dasu-sql4 (VM 106) → 192.168.1.11 [SQL Server 2019]
|
||||
│
|
||||
└── dasu-pc (PC Física) → DHCP ISP [Estación de trabajo]
|
||||
```
|
||||
|
||||
### 3.2 Componentes del nuevo entorno
|
||||
|
||||
| Componente | Descripción | Estado |
|
||||
|:---|:---|:---:|
|
||||
| **srv-dasu** | Servidor Proxmox VE 9.1 (Hipervisor) — CPU Intel, 15 GB RAM, 94 GB disco | ✅ Operativo |
|
||||
| **dasu-sql4** (VM 106) | Windows Server 2022 — SQL Server 2019 Enterprise — 4 GB RAM, 2 vCPU, discos 60+120 GB | ✅ Operativo |
|
||||
| **dasu-pc** | PC Física — Windows 10 Pro — AMD Ryzen 5, 8 GB RAM — Oficina DASUTEN | ✅ Operativo |
|
||||
|
||||
### 3.3 Comparativa: Antes vs. Después
|
||||
|
||||
| Aspecto | Enfoque Anterior (con DC + AnyDesk) | Enfoque Actual (Workgroup) |
|
||||
|:---|:---|:---|
|
||||
| **Componentes** | 4 (DC + SQL + PC virtual + PC física) | 2 (SQL + PC física) |
|
||||
| **Forma de trabajo** | Indirecta (AnyDesk → PC virtual) | Directa (sistema en PC) |
|
||||
| **Red** | Privada 10.0.100.x (gateway interno) | DHCP del ISP (red plana) |
|
||||
| **Autenticación SQL** | Windows Integrated (Kerberos) | SQL Auth (mixta) |
|
||||
| **Usuarios** | Active Directory | Usuarios locales Windows |
|
||||
| **DNS** | AD DNS (10.0.100.10) | DNS del ISP (automático) |
|
||||
| **Complejidad de red** | Alta (DC + DNS + dominio + routing) | Mínima (red plana ISP) |
|
||||
| **Puntos de falla** | DC, SQL, red dominio, routing, AnyDesk | Solo SQL |
|
||||
| **VMs necesarias** | 3 (DC + SQL + PC virtual) | 1 (solo SQL) |
|
||||
|
||||
---
|
||||
|
||||
## 4. Fases Ejecutadas y Progreso
|
||||
|
||||
### Resumen de progreso por fase
|
||||
|
||||
| Fase | Descripción | Estado | Progreso |
|
||||
|:---:|:---|:---:|:---:|
|
||||
| 1 | Preparación del entorno (srv-dasu) | ✅ Completada | 100% |
|
||||
| 2 | Creación de VM SQL Server de prueba | ✅ Completada | 100% |
|
||||
| 3 | Creación de VM PC Cliente de prueba | ✅ Completada | 100% |
|
||||
| 4 | VM definitiva dasu-sql4 | ✅ Completada | 100% |
|
||||
| 5 | Migración de base de datos | ✅ Completada | 100% |
|
||||
| 5b | Hardening y persistencia de servicios | ✅ Completada | 100% |
|
||||
| 6 | Validación con PC cliente virtual | ✅ Completada | 100% |
|
||||
| 7 | Despliegue en PC física (producción) | 🚧 En curso | 75% |
|
||||
| 8 | Refresco final de base de datos | ✅ Completada | 100% |
|
||||
|
||||
### 4.1 Fase 1-3: Preparación y pruebas de concepto (27-28 marzo)
|
||||
|
||||
Se preparó el hipervisor Proxmox, se reconfiguró el bridge de red para usar DHCP directo del ISP, y se crearon VMs de prueba para validar la viabilidad del enfoque sin Domain Controller.
|
||||
|
||||
**Hallazgo crítico:** Se detectó y resolvió que el bridge de red estaba configurado con la IP de una red privada anterior, lo cual habría impedido la conectividad de las nuevas VMs.
|
||||
|
||||
### 4.2 Fase 4: Servidor SQL definitivo (9-10 abril)
|
||||
|
||||
Se creó la VM definitiva `dasu-sql4` (VM 106) con una arquitectura optimizada:
|
||||
|
||||
- **Discos separados:** 60 GB para SO + 120 GB exclusivo para datos SQL (buena práctica).
|
||||
- **SQL Server 2019 Enterprise** instalado con autenticación mixta.
|
||||
- **Gestión remota** asegurada vía OpenSSH Server (puerto 7022) y Tailscale VPN.
|
||||
|
||||
### 4.3 Fase 5: Migración de Base de Datos (11 abril)
|
||||
|
||||
Se ejecutó la migración completa de la base de datos de producción:
|
||||
|
||||
1. **Exportación:** Backup comprimido (~1.33 GB) generado desde el servidor origen (`srvv-fenix`).
|
||||
2. **Transferencia:** Archivo movido a través de la VPN institucional (Tailscale) en múltiples tramos seguros.
|
||||
3. **Restauración:** Base restaurada exitosamente en 26 segundos (354 MB/s).
|
||||
4. **Verificación:** `DBCC CHECKDB` ejecutado sin errores — integridad de datos confirmada al 100%.
|
||||
|
||||
### 4.4 Fase 5b: Hardening (11 abril)
|
||||
|
||||
Se validó que todos los servicios críticos (SSH, SQL Server) sobreviven reinicios del servidor sin intervención manual:
|
||||
|
||||
- OpenSSH Server: arranque automático ✅
|
||||
- SQL Server: arranque automático ✅
|
||||
- IP de red: mantenida tras reinicio ✅
|
||||
|
||||
### 4.5 Fase 6: Validación funcional en entorno virtual (11 abril)
|
||||
|
||||
Se restauró una VM cliente desde backup para simular el entorno real de la oficina DASUTEN:
|
||||
|
||||
- Se desvinculó la PC del dominio anterior y se unió al Workgroup `DASUTEN`.
|
||||
- Se reconfiguró el archivo de conexión del sistema (`Kermet.ini`) para apuntar al nuevo servidor SQL.
|
||||
- **Resultado:** El sistema DASUTEN conectó exitosamente, actualizó estructuras y descargó novedades.
|
||||
|
||||
**Conclusión técnica clave:** Se determinó mediante ingeniería inversa que el sistema DASUTEN (desarrollado en Visual FoxPro) **no tiene dependencia real del Active Directory** si se configura explícitamente la autenticación SQL en su archivo de configuración.
|
||||
|
||||
### 4.6 Fase 7: Despliegue en PC física de producción (13 abril — EN CURSO)
|
||||
|
||||
Se desplegó el sistema en la PC física de la oficina DASUTEN (`dasu-pc`):
|
||||
|
||||
- **Directorio del sistema** (`C:\SysDasuten`) transferido desde la VM de pruebas.
|
||||
- **Configuración de conexión** apuntada al nuevo servidor `dasu-sql4`.
|
||||
- **Acceso directo** creado en el escritorio de la usuaria (`aalmiron`).
|
||||
- **Pruebas funcionales:**
|
||||
- Inicio del sistema: ✅ OK
|
||||
- Acceso a datos (ventana de bonos): ✅ OK
|
||||
- **Impresión: ❌ FALLO** — Error al imprimir, posiblemente por incompatibilidad de las plantillas de Office (el sistema usa automatización OLE con Word/Excel).
|
||||
|
||||
### 4.7 Fase 8: Refresco final de base de datos (13 abril)
|
||||
|
||||
Se ejecutó un refresco automatizado de la base de datos para asegurar que el sistema arranca con los datos más actualizados del servidor de origen:
|
||||
|
||||
- Backup generado automáticamente desde el origen (44.8 segundos).
|
||||
- Transferido de manera segura (SMB + SCP por VPN).
|
||||
- Restaurado con `RESTORE DATABASE ... WITH REPLACE`.
|
||||
- Integridad verificada con `DBCC CHECKDB` — sin errores.
|
||||
|
||||
---
|
||||
|
||||
## 5. Estado Actual
|
||||
|
||||
### 5.1 Funcionalidades operativas
|
||||
|
||||
| Funcionalidad | Estado |
|
||||
|:---|:---:|
|
||||
| Acceso al sistema DASUTEN | ✅ Operativo |
|
||||
| Consulta de datos (bonos, registros) | ✅ Operativo |
|
||||
| Conexión a base de datos SQL Server | ✅ Operativo |
|
||||
| Acceso remoto para soporte (Tailscale/SSH) | ✅ Operativo |
|
||||
| Impresión desde el sistema | ❌ Pendiente |
|
||||
|
||||
### 5.2 Problema pendiente: Impresión
|
||||
|
||||
**Descripción:** Al intentar imprimir desde el sistema DASUTEN en la PC física, se produce un error. El diagnóstico preliminar indica que la causa es una incompatibilidad entre las **plantillas de Office** requeridas por el sistema (diseñadas para Office 2003/2007) y la versión de Office actualmente instalada en la PC.
|
||||
|
||||
**Impacto:** La usuaria no puede generar documentos impresos desde el nuevo sistema.
|
||||
|
||||
**Workaround temporal:** Se habilitó acceso remoto (TeamViewer) desde la PC física hacia la VM de pruebas (`dasu-pcv`), donde la impresión funciona correctamente. La usuaria puede continuar operando mientras se resuelve el problema.
|
||||
|
||||
**Plan de resolución:** Verificar y ajustar la versión/configuración de Office en `dasu-pc` para compatibilizarla con las plantillas del sistema.
|
||||
|
||||
---
|
||||
|
||||
## 6. Beneficios Obtenidos
|
||||
|
||||
1. **Independencia operativa:** DASUTEN ya no depende de la infraestructura de red ni de los servidores de la Facultad.
|
||||
2. **Simplificación:** Se pasó de 3 VMs + Domain Controller a solo 1 VM (SQL Server), reduciendo significativamente la complejidad.
|
||||
3. **Reducción de puntos de falla:** De múltiples (DC, DNS institucional, routing complejo) a uno solo (SQL Server).
|
||||
4. **Acceso remoto robusto:** Gestión técnica asegurada vía VPN (Tailscale) y SSH, sin necesidad de presencia física.
|
||||
5. **Autonomía:** La infraestructura puede ser gestionada independientemente, facilitando una eventual transferencia a Rectorado.
|
||||
6. **Preservación del entorno anterior:** Las VMs del enfoque con DC fueron apagadas y preservadas como respaldo, permitiendo un rollback si fuera necesario.
|
||||
|
||||
---
|
||||
|
||||
## 7. Cronograma Resumen
|
||||
|
||||
| Fecha | Hito |
|
||||
|:---|:---|
|
||||
| 27/03/2026 | Inicio — Preparación del entorno e inicio de pruebas de concepto |
|
||||
| 28/03/2026 | VM SQL Server de prueba operativa |
|
||||
| 09-10/04/2026 | Servidor SQL definitivo (dasu-sql4) desplegado y operativo |
|
||||
| 11/04/2026 | Base de datos migrada, verificada y hardening completado |
|
||||
| 11/04/2026 | Validación funcional exitosa en entorno virtual |
|
||||
| 13/04/2026 | Despliegue en PC física de producción — sistema operativo con observación de impresión |
|
||||
|
||||
---
|
||||
|
||||
## 8. Próximos Pasos
|
||||
|
||||
| Prioridad | Acción | Plazo estimado |
|
||||
|:---:|:---|:---|
|
||||
| 🔴 Alta | Resolver problema de impresión (compatibilidad Office/plantillas) | 1-3 días hábiles |
|
||||
| 🟡 Media | Reservar IPs fijas en router ISP (prevenir cambios por DHCP) | 1 semana |
|
||||
| 🟢 Baja | Evaluar apagado definitivo de VMs legacy (DC, SQL antiguo) | Tras validación completa |
|
||||
| 🟢 Baja | Documentar procedimiento de respaldo automatizado de la nueva BD | 2 semanas |
|
||||
|
||||
---
|
||||
|
||||
## 9. Conclusión
|
||||
|
||||
La migración del sistema DASUTEN a la nueva infraestructura se encuentra **prácticamente completada**, con el sistema operativo y los datos verificados. El enfoque sin Domain Controller demostró ser completamente viable, logrando una **reducción significativa de la complejidad** y de los puntos de falla.
|
||||
|
||||
El único aspecto pendiente es la resolución del problema de impresión, para el cual ya se dispone de un workaround funcional que permite a la usuaria continuar operando sin interrupción.
|
||||
|
||||
Se estima que el proyecto quedará **100% finalizado** dentro de los próximos días hábiles, una vez resuelta la compatibilidad de plantillas de Office.
|
||||
|
||||
---
|
||||
|
||||
# ANEXO TÉCNICO
|
||||
|
||||
## A. Inventario de Nodos
|
||||
|
||||
### A.1 Servidor Hipervisor: srv-dasu
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Hipervisor Proxmox VE 9.1 |
|
||||
| **IP LAN** | 192.168.1.13 (DHCP ISP) |
|
||||
| **IP VPN** | 100.112.46.104 (Tailscale) |
|
||||
| **Bridge** | vmbr0 sobre enp33s0 |
|
||||
| **RAM** | 15 GB total / ~4 GB libre post-VMs |
|
||||
| **Disco** | 94 GB (68% uso, thin provisioned) |
|
||||
| **Acceso remoto** | Tailscale + SSH |
|
||||
|
||||
### A.2 Servidor SQL: dasu-sql4 (VM 106)
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | SQL Server 2019 Enterprise |
|
||||
| **SO** | Windows Server 2022 (Español) |
|
||||
| **IP LAN** | 192.168.1.11 (DHCP ISP) |
|
||||
| **IP VPN** | 100.107.15.82 (Tailscale — inestable) |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **RAM** | 4 GB |
|
||||
| **vCPU** | 2 |
|
||||
| **Disco 1 (sata0)** | 60 GB — Sistema Operativo |
|
||||
| **Disco 2 (sata1)** | 120 GB — Datos SQL (GPT/NTFS "SQLData") |
|
||||
| **Estructura SQL** | F:\DATA, F:\LOG, F:\BACKUP, F:\TEMPDB |
|
||||
| **Autenticación** | Mixta (SQL Auth + Windows) |
|
||||
| **Puerto SQL** | TCP 1433 |
|
||||
| **SSH** | Puerto 7022 (OpenSSH Server, arranque automático) |
|
||||
| **Servicios auto-start** | MSSQLSERVER, sshd |
|
||||
|
||||
### A.3 PC Física Cliente: dasu-pc
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Estación de trabajo DASUTEN |
|
||||
| **Patrimonio** | 32120 |
|
||||
| **Ubicación** | Oficina DASUTEN (externa a Facultad) |
|
||||
| **SO** | Windows 10 Pro |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **IP VPN** | 100.119.233.11 (Tailscale) |
|
||||
| **SSH** | UTNLR@100.119.233.11:7022 |
|
||||
| **CPU** | AMD Ryzen 5 4600G @ 4.30GHz (6 núcleos) |
|
||||
| **RAM** | 8 GB DDR4-3200 |
|
||||
| **Placa Base** | Asus Prime A320M-K |
|
||||
| **Usuaria principal** | Andrea Almirón (`aalmiron`) |
|
||||
| **Directorio DASUTEN** | C:\SysDasuten |
|
||||
| **Config conexión** | C:\SysDasuten\Sistema\Kermet.ini |
|
||||
|
||||
### A.4 VM Cliente de Pruebas: dasu-pcv (VM 107) — Test-Bed
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Rol** | Entorno de pruebas / fallback temporal |
|
||||
| **SO** | Windows 10 |
|
||||
| **Workgroup** | DASUTEN |
|
||||
| **SSH** | Puerto 7022 |
|
||||
| **Estado** | Operativa (usada como fallback vía TeamViewer) |
|
||||
|
||||
---
|
||||
|
||||
## B. Configuración del Sistema DASUTEN
|
||||
|
||||
### B.1 Archivo de conexión: Kermet.ini
|
||||
|
||||
Parámetros clave configurados para la operación sin Domain Controller:
|
||||
|
||||
```ini
|
||||
SERVER=dasu-sql4
|
||||
DATABASE=sysdasuten
|
||||
UID=sa
|
||||
PWD=[credencial almacenada en bóveda]
|
||||
```
|
||||
|
||||
> **Nota técnica:** El campo `UID` debe estar explícitamente configurado con `sa` (u otra cuenta SQL Auth). Si se deja vacío, el sistema DASUTEN (Visual FoxPro) asume autenticación Windows integrada (SSPI/Kerberos), lo cual falla en entorno Workgroup sin Domain Controller.
|
||||
|
||||
### B.2 Directorio del sistema
|
||||
|
||||
```
|
||||
C:\SysDasuten\
|
||||
├── Sistema\ → Ejecutables VFP + Kermet.ini
|
||||
├── Plantillas\ → Templates Word/Excel para impresión
|
||||
└── [otros directorios de la aplicación]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## C. Base de Datos: sysdasuten
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Nombre** | sysdasuten |
|
||||
| **Motor** | SQL Server 2019 Enterprise |
|
||||
| **Tamaño backup comprimido** | ~1.33 GB |
|
||||
| **Nivel de compatibilidad** | 100 |
|
||||
| **Recovery model** | FULL |
|
||||
| **Integridad (DBCC CHECKDB)** | ✅ Sin errores |
|
||||
| **Tiempo de restauración** | 26 segundos (354 MB/s) |
|
||||
| **Origen de datos** | srvv-fenix (servidor legacy de Facultad) |
|
||||
| **Último refresco** | 13/04/2026 |
|
||||
|
||||
### C.1 Ruta de transferencia del backup
|
||||
|
||||
```
|
||||
srvv-fenix (Origen)
|
||||
│ [BACKUP DATABASE ... WITH COMPRESSION]
|
||||
│ → E:\BK_SQL\sysdasuten_compressed_ADN.bak (~1.33 GB)
|
||||
↓
|
||||
srv-ns8 (Tránsito)
|
||||
│ [SMB/smbget vía dominio]
|
||||
│ → /var/tmp/
|
||||
↓
|
||||
srv-dasu (Tránsito)
|
||||
│ [SCP vía Tailscale]
|
||||
↓
|
||||
dasu-sql4 (Destino)
|
||||
│ [RESTORE DATABASE ... WITH REPLACE]
|
||||
└ → F:\BACKUP\ → F:\DATA\ + F:\LOG\
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## D. VMs Legacy Preservadas (Apagadas)
|
||||
|
||||
| VM ID | Nombre | Rol anterior | Estado |
|
||||
|:---:|:---|:---|:---:|
|
||||
| 100 | dasu-srvv-dc | Domain Controller AD DS | 🛑 Apagada |
|
||||
| 101 | dasu-srvv-sql | SQL Server (dominio) | 🛑 Apagada |
|
||||
| 102 | dasu-pcv | PC cliente (dominio) | 🛑 Apagada |
|
||||
| 103 | dasu-sql2 | SQL Server prueba v1 | 🛑 Descartada |
|
||||
| 104 | dasu-pcv2 | PC prueba v1 | 🛑 Descartada |
|
||||
|
||||
> Las VMs legacy (100-102) se mantienen apagadas como respaldo. Pueden reactivarse en caso de necesitar un rollback al enfoque con Domain Controller.
|
||||
|
||||
---
|
||||
|
||||
## E. Accesos Remotos Configurados
|
||||
|
||||
| Nodo | Método | Detalle |
|
||||
|:---|:---|:---|
|
||||
| srv-dasu | Tailscale SSH | 100.112.46.104 |
|
||||
| dasu-sql4 | SSH (LAN) | 192.168.1.11:7022 |
|
||||
| dasu-sql4 | Tailscale | 100.107.15.82 (inestable) |
|
||||
| dasu-pc | Tailscale SSH | 100.119.233.11:7022 |
|
||||
| dasu-pc | AnyDesk | Instalado (GUI) |
|
||||
| dasu-pcv | TeamViewer | Activo (workaround temporal) |
|
||||
|
||||
---
|
||||
|
||||
## F. Cuenta de Gestión VPN
|
||||
|
||||
| Campo | Valor |
|
||||
|:---|:---|
|
||||
| **Proveedor** | Tailscale |
|
||||
| **Cuenta** | pcdasu0@frlr.utn.edu.ar |
|
||||
| **Nodos vinculados** | srv-dasu, dasu-sql4, dasu-pc, dasu-pcv |
|
||||
|
||||
---
|
||||
|
||||
### Historial de versiones
|
||||
|
||||
| Versión | Fecha | Cambios |
|
||||
|:---:|:---:|:---|
|
||||
| 0.1 | 13/04/2026 | Versión inicial (fusión de informe de avance + anexo técnico) |
|
||||
| 0.2 | 13/04/2026 | Se agrega contexto de infraestructura anterior (esquema AnyDesk), versionado, referencia a doc ejecutivo |
|
||||
|
||||
*Fin del informe técnico.*
|
||||
Reference in New Issue
Block a user