TFG Ruben Arguelles Dominguez

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y
SISTEMAS DE TELECOMUNICACIÓN
PROYECTO FIN DE GRADO
TÍTULO: Diseño e implementación de un sistema de seguridad en alta

disponibilidad
AUTOR: Rubén Argüelles Domínguez
TITULACIÓN: Sistemas de Telecomunicaciones
DIRECTOR: Álvaro Arribas Del Val
TUTOR: Francisco Javier Ortega González
DEPARTAMENTO: Teoría de la Señal y Comunicaciones (TSC)
VºBº
Miembros del Tribunal Calificador:
PRESIDENTE: Salvador Sánchez Hernández
TUTOR: Francisco Javier Ortega González
SECRETARIO: José Manuel Pardo
Fecha de lectura:
Calificación:
El Secretario,
ETSIST de Telecomunicación Campus Sur UPM
RESUMEN
El presente trabajo se basa en el estudio, diseño e implementación de un sistema de seguridad

en alta disponibilidad. Para poder llevar a cabo el proyecto se realizará un estudio de la
composición de los sistemas de seguridad y del estado de las tecnologías actuales, con el fin
de encontrar la mejor solución para la realización de un sistema de seguridad práctico, actual
e innovador.
Para este proyecto se ha diseñado una infraestructura virtual, en la cual varios hosts físicos
proporcionarán los recursos necesarios para ejecutar las máquinas virtuales, que se
gestionarán dentro de un almacenamiento compartido.
Para la implementación se hará uso de la herramienta VMWare vSphere Client, a través de la

cual se van a gestionar las diez máquinas virtuales con diferentes sistemas operativos
(Windows y Linux) que formarán una arquitectura segura ofreciendo al cliente cuatro
servicios.
El objetivo del proyecto es garantizar alta disponibilidad en todos los servicios ofrecidos, y
para ello, se ha demostrado a través de cuatro vías diferentes, una para cada servicio:
- Servicio de almacenamiento de datos Utilizando un “failover cluster” de SQL

- Servicio de vídeo en vivoA través de un clúster de Windows
- Servicio de telefoníaMediante la solución “Keepalived” ofrecida por Linux
- Servicio de peticiones web Configurando un balanceador de carga software
HAProxy
Todo el sistema y los servicios ofrecidos estarán garantizados bajo un servidor de dominio.
Este servidor, que también estará redundando para garantizar alta disponibilidad,
proporcionará un servicio único introduciendo todas las máquinas virtuales y sus servicios
bajo un mismo dominio (tfg.local), en el que sólo los usuarios que sean de interés por parte
del cliente tendrán permiso para acceder a cada servicio.
Tras el diseño y la implementación, se realizarán pruebas en las que se pondrá a prueba el

sistema diseñado y todos sus servicios, demostrándose que ante cualquier posible fallo, el
sistema garantiza alta disponibilidad.
1
ABSTRACT
The present project is based on the study, design and implementation of a high availability
security system. In order to carry out the work, a study of the composition of the security
systems and the state of the current technologies will be performed, with the purpose of
finding the best solution to build a practical, current and innovative security system.
The architecture of the project has been designed based on a virtual infrastructure, in which
several physical hosts will provide the necessary resources to run virtual machines. In turn,
these virtual machines will be managed within a shared storage
As for the implementation, it will use VMware vSphere Client, there will be ten virtual
machines with different operating systems (Windows and Linux) managed by this tool, which
will form a secure architecture offering four services to the Client.
The final purpose of the project is assure high availability of all the offered services, and so in
consequence, it has been tested and proved through four different ways, one per each service:
- Data storage service Using a SQL failover cluster

- Live video serviceWith a Windows cluster
- Telephony serviceWith the "Keepalived" solution offered by Linux
- Web requests serviceConfiguring a software load balancer HAProxy
The entire system and its services will be guaranteed under a domain server. This server will
be in redundancy in order to assure high availability. It will provide an unique service to get
in all the virtual machines and their services under a same domain (tfg.local) in which only
the users that are of interest on the part of the client will have permission to access each
service.
Finally, after the design and implementation, the whole system and its services will be tested,
proving again that the system offers high availability in case of any failure.
2
ÍNDICE GENERAL
1 INTRODUCCIÓN .......................................................................................................... 12
1.1 Descripción del proyecto ............................................................................................ 12
1.2 Entorno y contextualización ....................................................................................... 12
1.3 Objetivos..................................................................................................................... 13
2 MARCO TECNOLÓGICO DEL PROYECTO .......................................................... 15

2.1 Historia y evolución de los sistemas de seguridad .................................................. 15
2.2 Alta disponibilidad.................................................................................................... 16

2.2.1 Definición de alta disponibilidad .................................................................... 16
2.2.2 Características de un modelo de alta disponibilidad ....................................... 17
2.2.3 Failover ........................................................................................................... 18
2.2.4 Soluciones de alta disponibilidad ................................................................... 19
 Redundancia de dispositivos hardware ..................................................... 19
 Redundancia en la gestión de información .............................................. 20
 Sistemas RAID. NAS y SAN. ...............................................................
 Redundancia en las comunicaciones: balanceo de carga ......................... 25
 Redundancia y distribución en el procesado - Sistemas de clustering ..... 27
 Centros de respaldo: redundancia local y redundancia geográfica ........... 28
3 Redes y servicios ............................................................................................................. 29

3.1.1 Virtualización ................................................................................................. 29
3.1.2 Directorio activo ............................................................................................. 30
3.1.3 Servidores Proxy ............................................................................................. 31
3.1.4 Protocolos ...................................................................................................... 32
3.1.5 DMZ................................................................................................................ 34
3.2 Ciberseguridad........................................................................................................ 35
3.2.1 Riesgos y vulnerabilidades ............................................................................. 35
3.2.2 Test de penetración ......................................................................................... 36
3.2.3 Criptografía ..................................................................................................... 37
3.2.4 Certificados ..................................................................................................... 39
3.3 Tecnología hardware y software ........................................................................... 40

3.3.1 Sistemas operativos ......................................................................................... 40
3.3.2 Servidores y bases de datos............................................................................. 41
3.3.3 Sistemas CCTV............................................................................................... 43
3.3.4 Telefonía ......................................................................................................... 44
3.3.5 Sensores .......................................................................................................... 46
3
4 DISEÑO Y DESCRIPCIÓN DEL PROYECTO ......................................................... 49

4.1 Descripción de la solución ....................................................................................... 49
4.2 Proceso de desarrollo del proyecto .......................................................................... 50
5 IMPLEMENTACIÓN DEL PROYECTO ................................................................... 52

5.1 Despliegue de máquinas virtuales ........................................................................... 52
5.2 Directorio Activo ...................................................................................................... 53
5.3 Clúster de bases de datos ......................................................................................... 57
5.4 Vídeo en vivo ............................................................................................................ 79
5.5 Telefonía ................................................................................................................... 83
5.6 Balanceador de carga ................................................................................................ 89
6 PRUEBAS, CONCLUSIONES Y POSIBLES MEJORAS ....................................... 96

6.1 Bases de datos .......................................................................................................... 96
6.2 Vídeo en vivo .......................................................................................................... 103
6.3 Telefonía ................................................................................................................ 106
6.4 Balanceador de carga .............................................................................................. 111
6.5 Conclusiones generales y posibles mejoras ............................................................ 118
7 GUÍA DE USUARIO PARA LOS PROGRAMAS UTILIZADOS ........................ 121

7.1 SQL Server Management Studio 2017 ................................................................... 121
7.2 Postman ................................................................................................................. 123
7.3 Putty ........................................................................................................................ 125
7.4 Zoiper ..................................................................................................................... 125
7.5 VLC media player................................................................................................... 127
8 PRESUPUESTO Y MATERIALES (HW Y SW) .................................................... 128

9 BIBLIOGRAFÍA ......................................................................................................... 130
10 ANEXO-1 ...................................................................................................................... 132
11 ANEXO-2 ...................................................................................................................... 136
4
ÍNDICE DE FIGURAS
Figura 1: Redundancia de dispostivos hardware ....................................................... 19

Figura 2: Representación de RAID 0 ......................................................................... 21
Figura 5: Representación de RAID 0+1..................................................................... 22
Figura 6: Escenario típico de una red NAS ............................................................... 23
Figura 7: Escenario típico de una red SAN ............................................................... 23
Figura 8: Escenario típico de un balanceador de carga ............................................ 26
Figura 9: Escenario típico de un servidor proxy ........................................................ 32
Figura 10: Modelos OSI y TCP/IP ............................................................................. 33
Figura 11: Escenario típico de una red DMZ ............................................................. 34
Figura 12: Cuantificación de riesgos ......................................................................... 35
Figura 13: Herramientas para localizar vulnerabilidades en las arquitecturas .......... 36
Figura 14: Escenario típico de un cifrado simétrico ................................................... 37
Figura 15: Escenario típico de un cifrado asimétrico ................................................. 38
Figura 16: Tipos de sistemas operativos ................................................................... 41
Figura 17: Cámara analógica .................................................................................... 43
Figura 18: Cámara IP ................................................................................................ 44
Figura 19: Arquitectura del proyecto ......................................................................... 49
Figura 20: Máquinas virtuales desplegadas. Directorio activo .................................. 53
Figura 21: Asignación de IP en el directorio activo .................................................... 54
Figura 22: Configuración del directorio activo en el proyecto .................................... 54
Figura 23: Instalación del rol “Active directory domain service”................................. 55
Figura 24: Instalación del rol “Active directory domain service” (II) ........................... 55
Figura 25: Instalación del rol “Active directory domain service” (III) .......................... 56
Figura 26: Instalación del rol “Active directory domain service” (IV) .......................... 56
Figura 27: Microsoft management console ............................................................... 57
Figura 28: Configuración de red en las máquinas virtuales de SQL .......................... 58
Figura 29: Configuración de red en las máquinas virtuales de SQL (II) .................... 59
Figura 30: Configuración de red en las máquinas virtuales de SQL(III) .................... 59
Figura 31: Configuración de red en las máquinas virtuales de SQL (IV) ................... 60
Figura 32: Acceso a los recursos compartidos .......................................................... 61
Figura 33: Configuracion de los recursos compartidos ............................................. 61
Figura 34: Configuracion de los recursos compartidos (II) ........................................ 62
Figura 35: Configuracion de los recursos compartidos (III) ....................................... 62
Figura 36: Configuracion de los recursos compartidos (IV) ....................................... 63
Figura 37: Configuracion de los recursos compartidos (V) ........................................ 63
Figura 38: Configuracion de los recursos compartidos (VI) ....................................... 64
Figura 39: Configuracion de los recursos compartidos (VII) ...................................... 64
Figura 40: Configuracion de los recursos compartidos (VIII) ..................................... 65
Figura 41: Creación de cuentas en el directorio activo .............................................. 65
Figura 42: Creación de cuentas en el directorio activo (II) ........................................ 66
Figura 43: Instalación del rol “Failover clustering“ ..................................................... 66
Figura 44: Instalación del rol “Failover clustering“ (II) ................................................ 67
Figura 45: Instalación del rol “Failover clustering“ (III) ............................................... 67
Figura 46: Instalación del rol “Failover clustering“ (III) ............................................... 67
Figura 47: Asignación de permisos de administrador local ....................................... 68
5
Figura 48: Configuración del clúster .......................................................................... 68

Figura 49: Configuración del clúster (II) .................................................................... 69
Figura 50: Configuración del clúster (III) ................................................................... 69
Figura 51: Configuración del clúster (IV) ................................................................... 69
Figura 52: Configuración del clúster (V) .................................................................... 70
Figura 53: Configuración del clúster (VI) ................................................................... 70
Figura 54: Comprobación de la instalación y configuración del cluster de Windows . 71
Figura 55: Instalación del rol DTC ............................................................................. 71
Figura 56: Instalación del rol DTC (II) ........................................................................ 71
Figura 57: Instalación del rol DTC (III) ....................................................................... 72
Figura 58: Comprobación de la instalación y configuración del rol DTC ................... 72
Figura 59: Instalación y configuración del failover cluster de SQL. Nodo-1 ............. 72
Figura 60: Instalación y configuración del failover cluster de SQL. Nodo-1 (II) ........ 73
Figura 61: Instalación y configuración del failover cluster de SQL. Nodo-1 (III) ....... 73
Figura 62: Instalación y configuración del failover cluster de SQL. Nodo-1 (IV) ....... 74
Figura 63: Instalación y configuración del failover cluster de SQL. Nodo-1 (V) ........ 74
Figura 64: Instalación y configuración del failover cluster de SQL. Nodo-1 (VI) ....... 75
Figura 65: Instalación y configuración del failover cluster de SQL. Nodo-1 (VII) ...... 75
Figura 66: Instalación y configuración del failover cluster de SQL. Nodo-1 (VIII) ..... 75
Figura 67: Instalación y configuración del failover cluster de SQL. Nodo-1 (IX) ....... 76
Figura 68: Instalación y configuración del failover cluster de SQL. Nodo-1 (X) ........ 76
Figura 69: Instalación y configuración del failover cluster de SQL. Nodo-1 (XI) ....... 77
Figura 70: Comprobación del rol MSSQLSERVER ................................................... 77
Figura 71: Instalación y configuración del failover cluster de SQL. Nodo-2 ............. 78
Figura 72: Comprobación y funcionamiento. Failover cluster de SQL ....................... 78
Figura 73: Comprobación y funcionamiento. Failover cluster de SQL (II) ................. 78
Figura 74: Despliegue de las máquinas virtuales. Wowza ........................................ 79
Figura 75: Icono de instalación de Wowza ................................................................ 80
Figura 76: Estado de los nodos del clúster................................................................ 80
Figura 77: Comprobación del rol TFG_WOWZA_SERVICE ..................................... 80
Figura 78: Servicios de Windows. Wowza ................................................................ 81
Figura 79: Configuración y usabilidad. Servidor Wowza ........................................... 81
Figura 80: Configuración y usabilidad. Servidor Wowza (II) ...................................... 82
Figura 81: Configuración y usabilidad. Servidor Wowza (III) ..................................... 82
Figura 82: Configuración y usabilidad. Servidor Wowza (IV)..................................... 82
Figura 83: Arquitectura de telefonía con la solución keepalived................................ 83
Figura 84: Plantilla de centOs 7 ................................................................................ 84
Figura 85: Despliegue de las máquinas virtuales. Asterisk ....................................... 84
Figura 86: Configuración de red. Asterisk ................................................................. 84
Figura 87: Configuración de red. Asterisk (II) ............................................................ 85
Figura 88: Configuración de red. Asterisk (III) ........................................................... 85
Figura 89: Configuración de red. Asterisk (IV)........................................................... 85
Figura 90: Configuración de red. Asterisk (V)............................................................ 86
Figura 91: Servicio de Asterisk .................................................................................. 88
Figura 92: Arquitectura propuesta para el balanceador de carga.............................. 89
Figura 93: Instalación y configuración del HAProxy .................................................. 90
Figura 94: Instalación y configuración del HAProxy (II) ............................................. 91
Figura 95: Instalación y configuración del HAProxy (III) ............................................ 91
Figura 96: Instalación y configuración del HAProxy (IV) ........................................... 92
Figura 97: Servicio de HAProxy ................................................................................ 93
6
Figura 98: Instalación y configuración. IIS ................................................................. 94

Figura 99: Instalación y configuración. IIS (II) ........................................................... 94
Figura 100: Instalación y configuración. IIS (III) ........................................................ 95
Figura 101: Estadísticas de balanceo. HAProxy ....................................................... 95
Figura 102: Seguridad en la arquitectura. Directorio activo ....................................... 96
Figura 103: Control de acceso a las máquinas de SQL ............................................ 97
Figura 104: Estado del clúster de SQL ...................................................................... 97
Figura 105: Estado del clúster de SQL (II) ................................................................ 97
Figura 106: Acceso a SQL Server Management Studio ............................................ 98
Figura 107: Pruebas de SQL. SQL Server Management Studio ............................... 98
Figura 108: Pruebas de SQL. SQL Server Management Studio (II) .......................... 98
Figura 109: Pruebas de SQL. SQL Server Management Studio (III) ......................... 99
Figura 110: Pruebas de SQL. SQL Server Management Studio (IV) ........................ 99
Figura 111: Pruebas de SQL. SQL Server Management Studio (V) ......................... 99
Figura 112: Pruebas de SQL ................................................................................... 100
Figura 113: Pruebas de SQL (II) ............................................................................. 100
Figura 114: Pruebas de SQL (III) ............................................................................ 100
Figura 115: Comprobaciones y resultados. SQL ..................................................... 101
Figura 116: Comprobaciones y resultados. SQL (II) ............................................... 101
Figura 117: Comprobaciones y resultados. SQL (III) .............................................. 102
Figura 118: Comprobaciones y resultados. SQL (IV) .............................................. 102
Figura 119: Comprobaciones y resultados. SQL (V) ............................................... 102
Figura 120: Pruebas de vídeo ................................................................................. 103
Figura 121: Pruebas de vídeo (II) ............................................................................ 104
Figura 122: Pruebas de vídeo (III) ........................................................................... 104
Figura 123: Figura 124: Pruebas de vídeo (IV) ....................................................... 105
Figura 125: Figura 126: Pruebas de vídeo (V) ........................................................ 105
Figura 127: Flujo de video en transmisión unicast-multicast ................................... 106
Figura 128: Pruebas de telefonía ............................................................................ 107
Figura 129: Pruebas de telefonía (II) ....................................................................... 107
Figura 130: Pruebas de telefonía (IV) ..................................................................... 107
Figura 131: Pruebas de telefonía (VI) ..................................................................... 108
Figura 132: Pruebas de telefonía (V) ...................................................................... 108
Figura 133: Pruebas de telefonía (VII) .................................................................... 109
Figura 134: Pruebas de telefonía. (VII) ................................................................... 109
Figura 135: Pruebas de telefonía. Establecimiento de llamada (VIII) ...................... 110
Figura 136: Pruebas de telefonía (IX) ..................................................................... 110
Figura 137: Pruebas de telefonía (X) ...................................................................... 111
Figura 138: Pruebas del balanceador de carga....................................................... 112
Figura 139: Pruebas del balanceador de carga (II) ................................................. 112
Figura 140: Pruebas del balanceador de carga (III) ................................................ 113
Figura 141: Pruebas del balanceador de carga (IV) ................................................ 113
Figura 142: Pruebas del balanceador de carga (IV) ................................................ 114
Figura 143: Pruebas del balanceador de carga (V) ................................................. 114
Figura 144: Pruebas del balanceador de carga (VI) ................................................ 114
Figura 145: Pruebas del balanceador de carga (VII) ............................................... 115
Figura 146: Pruebas del balanceador de carga (VIII) .............................................. 115
Figura 147: Pruebas del balanceador de carga (IX) ................................................ 115
Figura 148: Pruebas del balanceador de carga (X) ................................................. 116
Figura 149: Pruebas del balanceador de carga (XII) ............................................... 116
7
Figura 150: Pruebas del balanceador de carga (XII) ............................................... 117

Figura 151: Pruebas del balanceador de carga (XIII) .............................................. 117
Figura 152. Centro de respaldo ............................................................................... 118
Figura 153: Icono de aplicación. Microsoft SQL Management Studio 17 ................ 118
Figura 154: Manual de usuario. Microsoft SQL Server Management Studio 17 ...... 118
Figura 155: Figura 156: Manual de usuario. Microsoft SQL Server Management
Studio 17 (II) ............................................................................................................ 118
Figura 157: Manual de usuario. Microsoft SQL Server Management Studio 17 (III) 118
Figura 158: Logo de la marca Postman. ................................................................. 118
Figura 159: Manual de usuario. Postman ................................................................ 118
Figura 160: Manual de usuario. Postman (II) .......................................................... 118
Figura 161: Manual de usuario. Putty ...................................................................... 118
Figura 162: Manual de usuario. Zoiper .................................................................... 118
Figura 163: Manual de usuario. Zoiper (II) .............................................................. 118
Figura 164: Manual de usuario. Zoiper (III) ............................................................. 118
Figura 165: Manual de usuario. VLC ....................................................................... 118
8
ÍNDICE DE TABLAS
Tabla 1: Diferencias NAS y SAN ...................................................................... 24

Tabla 2: Máquinas virtuales de la arquitectura ................................................. 52
Tabla 3: Configuración de red. Bases de datos. ............................................... 61
9
LISTA DE ACRÓNIMOS
Acrónimo Significado
ACID Atomicity, Consistency, Isolation, Durability
ARP Address Resolution Protocol
CCTV Closed Circuit Television
COTS Commercial Off The Shelf
CPU Central Processing Unit
DDL Data definition language
DHCP Dynamic Host Configuration Protocol
DML Data manipulation language
DMZ Demilitarised Zone
DNS Domain Name System
DVR Digital Video Recorder
FTP File Transfer Protocol
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICMP Internet Control Message Protocol
IIS Internet Information Services
IP Internet Protocol
iSCSI Internet Small Computer System Interface
IT Information Technologies
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LUN Logical Unit Number
MDA Mirrored Disk Array
MMC Microsoft Management Console
MTTF Mean time to Failure
MTTR Mean Time To Repair
MSDTC Microsoft Distributed Transaction Coordinator
NAS Network Attached Storage
NAT Network Address Translation
N/A Non Applicable
NDVR Network Digital Video Recorder
NTP Network Time Protocol
10
NVR Network Video Recorder

OSI Open Systems Interconnection
PBX Private Branch Exchange
PSTN Public Switched Telephone Network
RAID Redundant Array of Independent Disks
RTP Real-time Transport Protocol
SAI Sistema de Alimentación Ininterrumpida
SAN Storage Area Network
SIP Session Initiation Protocol
SSH Secure SHell
SQL Structured Query Language
TCP Transmission Control Protocol
UDP User Datagram Protocol
UTP Unshielded Twisted Pair
VoIP Voice over Internet Protocol
VRRP Virtual Router Redundancy Protocol
VTR Video Tape Recorder
11
1 INTRODUCCIÓN
1.1 Descripción del proyecto
Atendiendo al afán de crear nuevas soluciones tecnológicas en el sector de la

seguridad, se ha decidido desarrollar un nuevo producto y servicio de seguridad integrada
que ofrece a los operadores de centros de control un novedoso sistema de seguridad
incluyendo telefonía y vídeo vigilancia.
Muchos de los sistemas de seguridad llevan años instalados, con infraestructuras obsoletas
y tecnología analógica. Lo que pretende este proyecto es diseñar e implantar un sistema de
seguridad con tecnologías actuales compuesto por diferentes servicios integrados: CCTV
(Closed Circuit Television), telefonía y un sistema de almacenamiento, todos ellos
ofreciendo alta disponibilidad y con eficiencia en el uso de los recursos para maximizar su
potencial.
Este enfoque integrado reduce la carga de trabajo del operador, consiguiendo un sistema en
alta disponibilidad que no deja de ofrecer sus servicios en ningún momento,
proporcionando un mayor nivel de confort y seguridad a las personas.
En definitiva, este proyecto se basa en el desarrollo de un nuevo producto revolucionario

dentro de los sistemas de seguridad existentes hasta la fecha en el sector del transporte y la
seguridad, unificando diferentes módulos existentes hasta el momento mediante el
desarrollo de una innovadora arquitectura de seguridad integrada.
El sistema realizado proporciona las siguientes ventajas clave:
- Uso eficiente de los recursos: A través de arquitecturas robustas y modelos

garantizados.
- Modelo de operaciones flexible: Mediante la consolidación de todas las funciones de
seguridad en una arquitectura de alta disponibilidad (telefonía, vídeo en vivo,
almacenamiento de información...), los operadores pueden optar por operar su centro
de control.
- Diseño pensado para estar siempre disponible: Diferentes sistemas de redundancia
y otras opciones estudiadas harán de forma precisa que ningún servicio deje
proporcionarse.
1.2 Entorno y contextualización
Actualmente, tanto durante el transporte de personas, de bienes, o en lugares con

eventos importantes y mucho tránsito de personas (estadios de fútbol, aeropuertos…), las
empresas de seguridad desean a toda costa proteger a sus clientes y pretenden asegurar que
los servicios ofrecidos sean de la mejor calidad.
La seguridad y la ciberseguridad son una de las principales preocupaciones de la sociedad

actual. Los expertos coordinan acciones preventivas contra los altos riesgos de crimen,
fraude, asalto y terrorismo que amenazan las sociedades, con desarrollo tecnológico. Por
12
esto, se hace uso de las tecnologías más avanzadas desarrollando las mejores medidas de
lucha contra este tipo de ataques.
Los datos relacionados con el riesgo asociado a trenes, estaciones, pasillos de tránsito y
centros de control son normalmente recolectados de forma individual y transformados en
información útil para conseguir gestionar la seguridad y las operaciones sin afectar al flujo
de personas. Asimismo, la infraestructura en la gestión de transporte de mercancías y
pasajeros (trenes, barcos, aviones y camiones) comprende un tema crucial para el desarrollo
de cualquier sociedad, permitiendo el libre movimiento de personas y bienes. El diseño de
esta red de transportes es de vital importancia debido a que la seguridad y fiabilidad puede
verse fácilmente comprometida, exponiendo al sistema a eventos maliciosos e inesperados
que interrumpan su normal funcionamiento.
Actualmente se aspira a fusionar los distintos sistemas de recolección de información

relativa a seguridad para crear un sistema reticular de control mucho más fiable y seguro, en
el que una única plataforma de control administre todos los eventos de seguridad, además
del resto de necesidades de operarios y pasajeros.
A partir del análisis previo, se observa como el proyecto está alineado a solventar la
problemática asociada a la seguridad de las personas en el mundo del transporte y en
grandes eventos, por lo que el proyecto supone una novedad subjetiva al perseguir
monitorizar en un único centro de control los distintos sistemas de seguridad, creando así un
sistema reticular de control más fiable y seguro que los ya existentes, en donde una única
plataforma de control sea capaz de administrar todos las necesidades del operario, pasajeros
y ciudadanos de a pie.
1.3 Objetivos
El objetivo principal del presente proyecto es diseñar un novedoso sistema e

infraestructura de seguridad integrada que ofrecerá a los operadores de seguridad una única
solución, incluyendo telefonía, videovigilancia y almacenamiento de información. De esta
manera, se pretende reducir la carga de trabajo del operador al tener una mejor
disponibilidad de los recursos y una eficiencia de uso de los mismos, así como el tiempo de
reacción en el caso de una emergencia, además de proporcionar un mayor nivel de confort y
seguridad a las personas.
Para ello, se quiere diseñar e implementar una arquitectura “on premises” cliente-servidor
en alta disponibilidad y en la que los servicios deben estar operativos en todo momento,
proporcionando una facilidad al operario a la hora de gestionar cualquier tipo de incidente
con un sistema seguro y fiable, gestionando los datos a nivel local.
El cliente debe tener acceso a diferentes servicios, por lo que se deberá diseñar una
arquitectura accesible para el cliente, con un estudio detallado del estado del arte, así como
la implementación y configuración de la arquitectura, materiales necesarios para el
desarrollo del proyecto y un apartado de pruebas y conclusiones de sistema.
13
Los servicios del sistema deben funcionar en alta disponibilidad, soportados en

arquitecturas capaces de hacer frente a los posibles fallos que se puedan dar y
resolviéndolos en un tiempo razonable. El sistema deberá administrar los usuarios que
tendrán acceso a los servicios y la otorgación de permisos específicos para usuarios
seleccionados.
14
2 MARCO TECNOLÓGICO DEL PROYECTO
2.1 Historia y evolución de los sistemas de seguridad.
La seguridad y la salud ocupacional son dos términos que llevan acompañando al ser
humano desde los inicios de la historia. Su comienzo se remonta hace miles de años cuando el
ser humano ponía en riesgo su vida continuamente y era el estado de supervivencia el que nos
permitía proteger la integridad física.
Desde ese momento el ser humano ha ido creando mecanismos de protección que han
evolucionado según las necesidades de la sociedad hasta nuestros días.
A día de hoy el Estado y las empresas son los responsables de proporcionar la seguridad de la
ciudadanía. El Estado debe de garantizar que todo ciudadano esté protegido, se sienta seguro
y no indefenso. Por otro lado, las empresas ofrecen servicios eficientes para garantizar la
sensación de seguridad mediante productos y servicios enfocados a esta meta.
En el año 1942 la empresa Siemens AG desarrolló un primer sistema de vigilancia: un circuito

cerrado de televisión para el ejército alemán con el fin de llevar un seguimiento del
lanzamiento de misiles. El ejército de los Estados Unidos desarrolló un sistema similar. El
problema es que este tipo de sistemas fueron utilizados solo por los gobiernos y sus ejércitos y
pasaron muchos años hasta que estos sistemas se comercializaron en beneficio de los
ciudadanos.
Fue entonces en 1949 cuando la empresa Vericon comercializó el primer sistema CCTV,
aunque con una nueva tecnología con carencias. Por ejemplo, no disponía de sistema de
grabación. Este problema se solucionó en 1951 cuando se comercializó una nueva versión
que permitía grabar y almacenar las imágenes en una cinta de video, a lo que se le llamó VTR
(Video Tape Recorder) [1]. A partir de este momento, al ser comercializados, los sistemas
empezaron a ser utilizados por entidades públicas, militares y empresas privadas. Comenzaron
a usarse para monitorizar el tráfico y las manifestaciones, y su éxito los llevó a emplearlos en
otros ámbitos que requerían control.
Los primeros sistemas de vigilancia electrónica funcionaban de manera análoga por medio de
un cable coaxial (cobre) y emitían una señal sinusoidal entre + 0,5 y -0,5 voltios. A través de
este cable las cámaras enviaban una señal al monitor de control. El principal problema de este
sistema era que el cable creaba mucha interferencia y provocaba que las imágenes llegaran
distorsionadas y con mala calidad.
En 1996 se desarrolló la primera cámara IP (Internet Protocol), la Neyete 200, gracias a la

empresa Axis. Aquí comenzó la introducción de la era informática que produjo el cambio de
lo analógico a lo digital, así como la virtualización.
La virtualización es una tecnología que permite crear servicios de IT (Information

Technologies) útiles, con recursos que están unidos tradicionalmente al hardware [2]. Permite
utilizar toda la capacidad de una máquina virtual, porque distribuye sus capacidades en varios
usuarios o entornos.
Su inicio se remonta a la década de los sesenta, pero no es hasta principios del año 2000
cuando se comienza a adoptar más ampliamente. La virtualización solucionó varios
15
problemas: las empresas podían dividir los servidores y ejecutar aplicaciones heredadas en
varios tipos y versiones de sistemas operativos. Los servidores se empezaron a utilizar más
eficientemente y, en consecuencia, se redujeron los costes relacionados con las compras, la
instalación, la refrigeración y el mantenimiento.
El desarrollo de las tecnologías que posibilitan la virtualización ha permitido que muchos

usuarios accedieran simultáneamente a computadoras que realizaban procesamiento por lotes.
El procesamiento por lotes era un tipo de informática popular en el sector comercial que
ejecutaba tareas rutinarias miles de veces y muy rápidamente.
El software encargado de la virtualización separa los recursos físicos de los entornos virtuales
y se pueden instalar directamente en el hardware (como un servidor), que es la forma más
utilizada para virtualizar en las empresas.
Desde entonces, gracias a la virtualización, los sistemas digitales han ido incrementando su
presencia e implantándose en las empresas. Siguen evolucionando y sustituyendo a los
sistemas analógicos, aunque muchas empresas todavía permanecen con sistemas obsoletos y
sin actualizarse a estas nuevas tecnologías, que permiten una mayor optimización de los
recursos y un incremento de seguridad para todas las personas.
2.2 Alta disponibilidad
2.2.1 Definición de alta disponibilidad
La tecnología avanza, las empresas crecen y el número de datos que hay que
manejar aumenta cuantitativamente. Las bases de datos y el auge de Internet han
permitido la colaboración y el intercambio de información desde cualquier parte del
mundo, ampliando el alcance de bases de datos en todas las organizaciones y
comunidades. Toda la información que se maneja conlleva que la seguridad esté
presente para tener la confianza necesaria en los servicios que se ofrecen por las
empresas.
La alta disponibilidad describe la capacidad de un sistema para seguir funcionando y

proporcionando recursos a sus usuarios cuando se produce uno o varios errores en
algún componente del sistema [3]. Dependiendo del tipo de servicio ofrecido, se
requerirá un grado u otro de disponibilidad. Sin embargo, es de alta relevancia que el
concepto sea aplicado en toda empresa que le dé importancia a su información.
El nivel de disponibilidad se expresa como medida del porcentaje de tiempo que un

sistema está operativo de manera continuada para ofrecer sus servicios al cliente. Es
decir, el período de tiempo que el sistema está realmente disponible durante el tiempo
que debería estar disponible, se puede expresar mediante la fórmula :
𝑀𝑇𝑇𝐹
𝐷𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑖𝑙𝑖𝑑𝑎𝑑:
(𝑀𝑇𝑇𝐹 + 𝑀𝑇𝑇𝑅)
16
Donde MTTF el tiempo transcurrido para fallar y MTTR es el tiempo promedio

de resolución de falla.
Observando:
1. Si el MTTR se acerca a cero y el sistema resuelve las fallas
inmediatamente, la disponibilidad se acercará al 100%.
2. Si el MTTF aumenta, y los fallos en el sistema tardan más en producirse, la
influencia del MTTR se verá disminuida.
Se suele representar como un porcentaje tiempo/año que lleva prestando servicio

ininterrumpidamente. Normalmente, este tiempo se expresa según el número de
nueves. Lo más común es:
• 99,9% (tres nueves) => 8,76 horas/año inactivo.

• 99,99 % (cuatro nueves) => 52,6 minutos/año inactivo.
• 99,999% (cinco nueves) => 5,26 minutos/año inactivo
2.2.2 Características de un modelo de alta disponibilidad
Para determinar si la alta disponibilidad es imprescindible en el sistema, debe

considerarse el impacto que causa un fallo en los diferentes servicios ofrecidos.
Las principales características de un modelo de alta disponibilidad son:
- Fiabilidad: Se trata del aspecto más crítico. Los componentes deben

estar estudiados de tal forma que aguanten la alta disponibilidad.
Merece la pena invertir en un sistema que tanto a nivel de hardware
como a nivel de software toleren la carga de trabajo sin fallar
precariamente.
- Recuperación ante fallos: Estos sistemas tienen varias opciones de

recuperación ante fallos. Estos fallos deben estar establecidos, así como
los procedimientos de resolución.
- Detección de errores: Una vez se produzca un fallo, la rápida

detección del tipo daño producido, así como comprobar el estado de los
servicios de una manera eficaz es imprescindible.
- Mantenimiento: Los componentes deben estar lo suficientemente

estudiados para realizar los mantenimientos oportunos en plazos
concretos. Estos mantenimientos deben realizarse de forma transparente
al cliente sin provocar pausas en los servicios ofrecidos.
En el sistema que se va a proponer, hablamos de una arquitectura basada en servicios

que ofrecen distintas funciones como guardar información, realizar llamadas
telefónicas, ver un vídeo en vivo, y un servicio específico de rendimiento efectivo
17
gracias al reparto de trabajo entre los servidores mediante un clúster de balanceadores

de carga.
El visionamiento de cámaras en vivo, comunicación telefónica, grabación de
imágenes…son servicios que no pueden dejar de funcionar y datos que no se pueden
perder, por lo que debemos tener una disponibilidad del 99,99%.
La alta disponibilidad se puede configurar para manejar tanto anomalías de hardware

como de software. Las anomalías software son la causa más común de tiempo de
inactividad.
El hecho de tener un sistema altamente disponible conlleva un sistema que no sea muy
complejo, ya que los sistemas complejos tienen inherentemente más puntos de fallos
potenciales y son más difíciles de implementar correctamente.
2.2.3 Failover
Para implementar un sistema de alta disponibilidad, hay que tener en cuenta los
diferentes modelos existentes, así como el comportamiento de ambos nodos cuando se
produce un failover [4]:
- Modelo de equilibrio de carga (activo-activo): Tanto nodo primario

como el nodo secundario son activos y procesan las solicitudes del
sistema en paralelo. Los datos se replican de forma bidireccional en
función de los servicios del sistema. Este modo de funcionamiento
produce que el tiempo de migración tras un error sea de cero.
- Modelo de espera caliente: Ambos nodos tienen el componente

software instalado y disponible, incluso el servidor secundario está
activo y en ejecución, pero no procesa datos hasta que falla el nodo
primario. Los datos se replican y ambos sistemas contienen datos
idénticos. El tiempo de migración tras un error en este tipo de modelos
es de unos pocos segundos.
- Modelo de espera templada: En este modelo, al igual que el modelo

de espera caliente, los dos nodos tienen el software instalado y
disponible, pero en el segundo nodo no está ejecutándose. Cuando se
produce un fallo en el nodo primario, y gracias a un gestor de clúster, el
nodo secundario inicia los componentes del software. Los datos se
replican de forma regular en el sistema secundario o se almacenan en
algún disco compartido. Este modelo otorga un tiempo de migración
tras error de unos pocos minutos.
- Modelo de espera en frío: El nodo secundario se encuentra

configurado igual que el nodo primario pero apagado. Sólo se enciende
y entra en acción cuando se produce un fallo en el primer nodo hasta
que sea reparado. Los datos pueden ser copiados en un sistema de
almacenamiento y restaurarlos si es necesario en el nodo secundario. Es
el modelo más lento y puede tardar en recuperarse algunas horas.
18
2.2.4 Soluciones de alta disponibilidad
Las soluciones de alta disponibilidad deben tener una tolerancia a errores muy
alta pesar de que cualquiera de sus componentes falle. Para ello se duplican los
recursos críticos, evitando que no haya puntos simples de fallo que puedan estropear
los servicios de nuestro sistema.
Redundancia de dispositivos hardware
Si en nuestro sistema hay un apagón de luz, y nos quedamos sin suministro

eléctrico, debemos poder seguir garantizando la continuidad del servicio. Se deben
duplicar todos los dispositivos hardware críticos en el sistema, como pueden ser las
fuentes de alimentación, los servidores, bases de datos físicas…y aparte de la propia
redundancia, debe haber un centro de respaldo, que, a pesar de reducir el rendimiento
en un momento determinado, minimiza el tiempo de actividad en caso de un fallo muy
grave.
Antes de activar el centro de respaldo, es importante tener claro que los elementos
hardware redundantes deben ser intercambiables en caliente [5]. Esto quiere decir que,
como primera opción, si por ejemplo se nos estropea un servidor, debe ser tener otro
en el almacén y ser capaces de cambiarlo mientras actúa el servicio redundante, sin
que el cliente perciba ningún percance en su servicio.
Servidor-1 Servidor-2
Cliente
Figura 1: Redundancia de
dispostivos hardware
Para que el hardware del sistema no deje de funcionar, debemos disponer de un SAI
(Sistema de Alimentación Ininterrumpida). Estos sistemas, en el caso de un fallo
eléctrico, proporciona energía a todos los dispositivos que tenga conectados a través
de baterías eléctricas. Según el tipo de alimentación que proporcionan, se pueden
distinguir entre tres tipos de SAI:
- Off-line: la alimentación se proporciona de la red eléctrica. Cuando

ocurre un fallo eléctrico, el sistema está un pequeño intervalo de tiempo
sin suministro eléctrico hasta que el SAI empieza a generar su propia
alimentación. No está indicado para dispositivos delicados a la forma
19
de onda de su alimentación ya que proporcionan una forma de onda

que no es sinusoidal.
- In-line: Es muy similar al off-line, pero dispone de filtros que

estabilizan la tensión de entrada, por lo que habilita su uso a pequeños
dispositivos sensibles como cámaras, ordenadores, servidores, etc.
También existe un intervalo de conmutación en el cual no hay
suministro eléctrico.
- On-line: Generan una onda perfectamente sinusoidal y limpia a partir

de sus baterías. No deja de suministrar los dispositivos protegidos ya
que carga las baterías a la vez que genera la alimentación, evitando el
tiempo de conmutación de los dos tipos anteriores. La única
problemática que ofrecen es el mantenimiento de las baterías debido a
su continuo funcionamiento. Es el más indicado para proteger los
dispositivos más delicados y valiosos de las empresas como pueden ser
dispositivos de monitorización, videograbadores, servidores físicos de
bases de datos…etc.
Redundancia en la gestión de información
Es muy importante que el cliente pueda recuperar la información deseada en el

momento que lo necesite. Para ello, necesitamos redundar los dispositivos que nos
permiten gestionar la información para no perder el servicio de almacenamiento en
ningún momento. Actualmente disponemos de varias opciones, entre las que destacan:
- Sistemas RAID (Redundant Array of Independent Disks) [6]: Son un conjunto

redundante de discos independientes que hace referencia a un sistema de
almacenamiento que utiliza diferentes discos duros entre los que se organizan y
replican los datos.
En función de la configuración se pueden encontrar multitud de beneficios

respecto al uso de un único disco duro:
- Incremento del rendimiento
- Mayor capacidad de almacenamiento
- Mayor integridad del conjunto
- Mayor tolerancia a fallos
La distribución de las unidades de disco conectadas entre sí se puede hacer a

través de hardware, software o combinación de ambos. De esta forma, cuando
una unidad física de disco falle, se podrá reconstruir mientras sigue
funcionando su paridad. Según su distribución, tenemos diferentes tipos de
RAID. Los más utilizados son los siguientes:
20
RAID 0
En esta distribución se reparten los datos

de forma equitativa entre dos más discos sin
información de paridad que proporcione
redundancia, tampoco hay corrección de errores.
Su mayor característica es la mejora del
rendimiento ya que se emplea toda la capacidad
del disco, pero no existe seguridad de la
información, y si alguno de los volúmenes se
rompiese, perderíamos parte de la información.
Figura 2: Representación de RAID 0
RAID 1
También se le denomina MDA (Mirrored

Disk Array). Crea una copia exacta, como si de
un espejo se tratase, del conjunto de datos en
dos o más discos. Es un volumen tolerante a
fallos que utiliza un espacio de almacenamiento
del mismo tamaño que el original, consiguiendo
redundancia.
Figura 3: Representación de RAID 1
Al tener la información duplicada y sincronizada sobre los dos discos físicos, se

consigue duplexación. En este caso, si uno de los discos fallase se podría utilizar la
información que estaría duplicada en el otro disco.
Las ventajas de este tipo de distribución es la recuperación de errores en caso de

fallo, siendo la arquitectura más rápida tolerante a fallos. Como inconveniente, se
necesitan dos discos por cada bloque de información, lo que incrementa el gasto
con grandes sistemas que usen este tipo de distribución.
21
RAID 5
Se utilizan como mínimo tres

discos físicos y se trata de un
volumen tolerante a fallos. Funciona
realizando una división de datos a
nivel de bloques y distribuyendo la
información de paridad entre todos
los discos pertenecientes al conjunto,
lo que servirá como código de
Figura 4: Representación de RAID 5 detección de errores.
La información de paridad y los datos se distribuyen de forma alterna entre las

diferentes partes. Esta arquitectura presenta como ventaja un algo rendimiento en
aplicaciones con demanda de velocidad, redundancia y recuperación de datos.
Como desventajas, no toda la capacidad de los discos está disponible para

almacenar la información debido a la información de paridad que se presenta en
todos los discos. También, presenta menor rendimiento cuando se presentan
escrituras, ya que el proceso de escritura es muy lento.
Otros niveles RAID menos empleados son RAID 2,3,4 Y 6.
Por otro lado, existen también los niveles RAID anidados, donde se unen
diferentes arquitecturas de las nombradas para obtener una mejora de la
redundancia de datos o simplemente por un mayor rendimiento en nuestro sistema
de almacenamiento.
Lo más normal en este tipo de niveles es combinar un nivel RAID que

proporcione redundancia con un nivel RAID 0 que aumenta el rendimiento, como
por ejemplo el RAID 0+1:
Figura 5: Representación de RAID 0+1.
22
- SAN (Storage Area Network) y NAS (Network Attached Storage): Son

soluciones de almacenamiento en red. En términos generales, un SAN
proporciona el acceso al almacenamiento a nivel de bloque, operando en una
red de alta velocidad, lo que conlleva una mejora de la disponibilidad y del
rendimiento de las aplicaciones al separar el tráfico de almacenamiento del
resto de la red. En cambio, NAS opera sobre los archivos de datos,
compartiendo la capacidad de almacenamiento de un ordenador con
ordenadores personales o servidores clientes a través de una red.
NAS tiene un hardware dedicado que suele ser la parte principal que se conecta
a una red LAN (Local Area Network). Esta conexión la realiza habitualmente a
través de Ethernet y TCP /IP.
Figura 6: Escenario típico de una red NAS
SAN se encarga de compartir datos entre diferentes dispositivos de

almacenamiento a bajo nivel, usando mayormente conexiones de fibra óptica,
lo que encarece la solución.
Figura 7: Escenario típico de una red SAN
23
Las principales características que nos permiten obtener las diferencias más
significativas entre estos dos dispositivos de almacenamiento son [7]:
Tabla 1: Diferencias entre redes NAS y SAN
NAS SAN
Datos a nivel de
TIPO DE DATOS Archivos compartidos
bloque
CABLEADO Cable de fibra
Ethernet LAN
UTILIZADO dedicado
CLIENTES Servidores de
Usuarios finales
PRINCIPALES aplicaciones
A través del
ACCESO A DISCO Acceso directo
dispositivo NAS
- El nivel de trabajo, NAS trabaja a nivel de ficheros mientras SAN

trabaja a nivel de bloque.
- Tipo de conexión, SAN utiliza red de alta velocidad a través de fibra
óptica mientras NAS trabaja en la propia red local.
- Los SAN proporcionan mayor rendimiento que los NAS, indicados
principalmente para almacenar bases de datos y virtualización de
sistemas.
- Más facilidad de ampliación de almacenamiento en dispositivos
SAN.
- Los NAS son mucho más económicos que los SAN.
24
Redundancia en las comunicaciones: Balanceo de carga
A la hora de abordar un sistema de seguridad, una posible situación que se

puede dar es la congestión de información a través un cúmulo de peticiones a nuestros
servicios.
Uno de los dispositivos que solucionan esta problemática es el balanceador de

carga, que como su propio nombre indica, se encargar de repartir esas peticiones del
cliente a los servidores. Un balanceador de carga puede ser tanto un dispositivo
hardware como una aplicación software. El modo de reparto se configura en el
balanceador a través de varios algoritmos disponibles, y esto hace una mejora
significativa en la velocidad de acceso al servidor, la tolerancia a fallos y la fiabilidad
del sistema.
Dentro de los algoritmos, podemos hablar del reparto de peticiones entre los
diferentes servidores a través del método Round Robin, en el cual se reparte la carga
equitativamente entre todos los servidores, o incluso métodos mucho más ideales que
analizan la actividad de cada servidor, la memoria disponible, y otras características en
tiempo real que permiten enviar las peticiones a los servidores que se encuentren en
menor carga operativa en ese momento.
El algoritmo ideal para sistemas con una gran carga de peticiones continuadas será
aquel que sea capaz de analizar:
- Las características de los servidores que dispone
- El tiempo de respuesta de cada uno de ellos, obteniendo un análisis del
retraso en las respuestas y en consecuencia servidores que estén más lentos
o cargados en ese momento.
- La utilización de la CPU
- El uso de memoria
- El número de conexiones abiertas en un mismo servidor
Si no se analizan estos parámetros, se pueden dar casos de peticiones con mucha carga
que se repartan a los servidores menos potentes, y haya un bloqueo de ciertos
servidores.
25
Figura 8: Escenario típico de un balanceador de carga
Controlar las peticiones a los servidores a través de balanceadores de carga nos aporta
una clara mejora en [5]:
- Escalabilidad: El balanceador distribuye las peticiones de los usuarios

entre varios servidores, haciendo que el sistema en su conjunto funcione
mucho mejor.
- Disponibilidad: El balanceador monitoriza el estado de los servidores y las

aplicaciones. En el caso de que se encuentre que uno de los servidores ha
fallado, será capaz de excluirle y no enviarle peticiones.
- Mantenimiento: El administrador puede apagar un servidor y el resto del

conjunto seguirá proporcionando el servicio.
- Seguridad: Realiza de primera capa entre cualquier referencia exterior y

nuestro sistema. Controla tanto las peticiones que entran como las que
salen, lo que dificulta la ruptura del sistema añadiendo una capa más de
seguridad
- Calidad de servicio: Mejora las respuestas de nuestros servidores, es un

servicio más seguro. Tener una mejor distribución de la carga de nuestros
servidores puede permitir ofrecer más servicios que los que podría soportar
un sistema sin balanceador de carga.
Por último, cabe destacar que en sistemas que requieran alta disponibilidad, la
posibilidad de que falle el balanceador de carga debe estar contemplada, y por lo tanto,
debe redundarse también para ofrecer continuidad en el servicio ofrecido.
26
Redundancia y distribución en el procesado - Sistemas de clustering
La tecnología clúster o clustering se basa en la unión de uno o varios servidores

que trabajan en una red de alta velocidad como si fuesen uno, compartiendo servicios
y monitorizándose entre sí.
En función de las necesidades, se pueden tener diferentes tipos de clusters:
- Clúster de hardware: unión de dos servidores físicos
- Clúster de software: unión de dos servidores virtuales
- Clúster de bases de datos: pueden ser bases de datos en un servidor físico
o virtual
La fortaleza de unir dos o más servidores para ofrecer servicios nos proporciona
diferentes funcionalidades que según las demandas del cliente se implementarán para
tener:
- Alta disponibilidad
- Alto rendimiento
- Escalabilidad
- Equilibrio de carga
Para formar un clúster, aparte de elegir las máquinas (nodos) que vayan a formar el
clúster, hay que definir los siguientes puntos:
- Sistemas operativos a utilizar en los servidores
- Conexiones de red
- Protocolos de comunicación y servicio
- Middleware para relacionar el usuario con el sistema operativo
- Aplicaciones o subsistemas a utilizar
Por último, en función de la disponibilidad del clúster hay diferentes topologías

disponibles [4]:
- Topología N+1: En este tipo de topología sólo hay un nodo a la espera

para adoptar el rol del nodo activo en caso de fallo. Con una configuración
estándar, el nodo secundario o debe ser capaz de asumir cualquier rol del
nodo primario. Si únicamente se usa un servicio, se puede usar una
configuración activo-pasivo simple.
- Topología N+M: Cuando el clúster provee varios servicios, en caso de

fallo un único nodo puede no ser suficiente para proporcionar una
redundancia eficaz. Por ello, esta topología ofrece más nodos en modo de
espera disponibles. Es una solución más cara tanto para la implementación
como para el mantenimiento.
- Topología N-to-1: En caso de falla del nodo primario, el nodo secundario

pasa a ser un reemplazo temporal activo hasta que se restaure el primario.
Los servicios deben reactivarse para restaurar la alta disponibilidad.
- Topología N-to-N: Los servicios del nodo fallado se distribuyen entre los
diferentes nodos activos. No hay nodos en espera, pero todos deben estar
27
capacitados para asumir cualquier servicio. Esta topología combina un

clúster activo-activo con una configuración N+M
Centros de respaldo: redundancia local y redundancia geográfica
Por muchas medidas de seguridad que se tomen y por mucho que se redunde
cada parte del sistema, siempre está la posibilidad de que ocurra alguna catástrofe
natural, un atentado o cualquier situación totalmente imprevisible. Las empresas que
manejen información muy importante, sea del nivel que sea, pero mucho más de
seguridad, deben tener la garantía de que todos sus datos y servicios tienen una vía de
escape en estas situaciones. Para ello, se diseñan centros o salas de respaldo que
absorban las operaciones del centro principal en caso de emergencia.
Para diseñar este centro de respaldo se tienen que tener en cuenta los siguientes
aspectos:
- Localización: La localización debe situarse mínimo a 20 kilómetros del

centro principal, para que no se vea afectado por la misma contingencia.
- Equipamiento hardware electrónico e informático: Debe ser compatible

con todo lo que se use en el centro principal. No es necesario que sea igual,
pero debe soportar los procesos más importantes del mismo. En función del
equipamiento, se puede hablar de una sala blanca, la cual contiene el
mismo equipamiento que el centro principal, o de una sala de back-up, la
cual contiene equipamiento parecido, pero no exactamente el mismo.
- Equipamiento software: Es necesario que esté actualizado con el que hay

en el centro principal, ya que en caso de no tener el mismo software no se
puede garantizar una alta disponibilidad en el sistema.
- Almacenamiento de datos: Se deben realizar copias de los datos en el

centro de respaldo. En función del tipo de negocio, si es más importante la
continuidad del servicio, la información u otros requisitos, se puede realizar
la copia de forma síncrona, asegurando que todos los datos que hay el
centro principal se guardan en el centro de respaldo simultáneamente. O
bien una copia asíncrona, que no asegura el almacenamiento de datos de
forma inmediata y puede haber un desfase temporal que incluye desde
horas hasta días.
Aparte del centro de respaldo, se deben tener medidas de seguridad y planes de

actuación en caso de emergencia. No deben faltar centros de control protegidos de
inundaciones, incendios, terremotos…unidos a un buen sistema eléctrico que soporte
la carga esperada, con distintos proveedores de electricidad, así como planes escritos
de respaldo, de emergencia y de recuperación, para que la empresa sea capaz de ser
previsora, actuadora y competente.
28
2.3 Redes y servicios
2.3.1 Virtualización
La virtualización es la tecnología que permite crear uno o varios entornos

informáticos simulados a partir de un único hardware físico con un sistema operativo
determinado. Permite crear una capa entre el hardware de la máquina física y el
sistema operativo de la máquina virtual. Esta capa es capaz de controlar los cuatro
recursos principales de un ordenador (CPU, Central Processing Unit;
almacenamiento, red y memoria).
Los tipos más importantes de virtualización son:
- Virtualización de servidores: se ejecuta más de un servidor en un mismo

servidor físico.
- Virtualización de sistemas operativos: para poder ejecutar más de un

sistema operativo en el mismo dispositivo.
- Virtualización de almacenamiento: para tener diferentes espacios de

almacenamiento en lo que se percibe como un único dispositivo.
- Virtualización de red, combinando diferentes conexiones de red en una

única red visible para poder dividirla en otras a nivel local.
A la máquina física original se le llama “host”, y se le equipa con un software

llamado “hipervisor” que se conecta directamente con el hardware y permite dividir un
sistema en diferentes entornos, a los que llamamos “máquinas virtuales”.
Estas máquinas virtuales son las que utilizarán los cuatro recursos del hardware
nombrados anteriormente, asignados y modificados según las necesidades por un
usuario. Para optimizar el uso de máquinas virtuales, lo mejor es que se administren
desde una sola consola de administración de virtualización.
De este modo, se puede tener varias máquinas virtuales, con diferentes sistemas
operativos, ejecutándose sobre el mismo ordenador físico.
Existen muchos softwares para virtualizar varios sistemas operativos en un servidor,

entre los que destacan VMWare, Citrix, Microsoft, VirtualBox y KVM.
La virtualización de recursos permite no tener que realizar una instalación

física, usando el hardware como producto de consumo. Para una instalación, bastaría
con migrar las máquinas virtuales al hardware deseado y realizar la configuración
adaptada. Así, se produce un mayor aprovechamiento de espacio físico, una capacidad
para actualizarte a nivel de aplicación en mucho menor tiempo y una gran mejora en el
tiempo de recuperación cuando hay paradas imprevistas.
29
2.3.2 Directorio activo
Un directorio activo es el término utilizado por Microsoft para referirse a un

servicio de directorio. Un servicio de directorio se encarga, por un lado, de
proporcionar un directorio donde guardar toda la información sobre los usuarios y
recursos de la red, y por otro, de garantizar un servicio que te permita acceder y
manipular estos recursos. Cualquier objeto que se pueda definir, desde un ordenador,
un dominio o una política de seguridad, es capaz de ser administrado mediante un
directorio activo.
El directorio activo utiliza la tecnología DNS porque es el protocolo más estándar en

Internet y LDAP porque casi todos los fabricantes lo soportan [9]. Mediante DNS y
LDAP los clientes pueden localizar y acceder a cualquier tipo de recurso disponible en
la red. Estos protocolos, al ser de plataforma independiente, permiten a otras
distribuciones como Linux tener acceso a los recursos de la misma forma que los
clientes de Windows.
Para gestionar el directorio activo se dispone de una herramienta llamada MMC

(Microsoft Management Console), que permite al usuario:
- Acceder a los recursos del dominio a través de una única identificación a la
red.
- La administración centralizada de usuarios y recursos.
La estructura del directorio activo se organiza de forma jerárquica, como se puede ver
en la imagen:
- Recursos, como por ejemplo impresoras.
- Servicios, como correo, Web, FTP, etc.
- Usuarios, los cuales incluyen cuentas para conectarse, grupos de trabajo,
etc.
El dominio trabaja por niveles. En la parte más superior se encuentra el bosque, que se
define como la colección de todos los objetos, atributos y reglas del directorio activo.
Los dominios se identifican por su nombre de estructura DNS( Domain Name System)
y únicamente puede haber un nombre DNS asignado a un dominio.
El dominio ofrece muchas opciones de organización para todos los objetos que
cuelgan de contenedores llamados unidades organizativas, otorgando una capacidad
única al dominio de jerarquía y proporcionando una imagen de la compañía en
términos organizativos y geográficos.
Estas unidades organizativas se pueden agrupar, así como crear usuarios
personalizados con permisos de administrador para cada uno de los contenedores.
30
2.3.3 Servidores proxy
Un servidor proxy es un equipo informático que realiza funciones de

intermediario entre un cliente de Internet y otro servidor. Gracias al servidor proxy
puedes no conectarte directamente al servidor que contiene la información y realizar la
solicitud a dicho proxy, el cual redirige la petición.
Las funciones de un proxy son funciones básicamente de seguridad, y destacan:
- Control de acceso a Internet, con capacidad de limitar los derechos de los

usuarios y proporcionar los permisos oportunos.
- Registro de tráfico, guardando el rastro de los movimientos de los

usuarios y teniendo un control de las páginas a las que acceden.
- Filtro de información bidireccional, restringiendo las solicitudes

recibidas que el proxy considere como peligrosas, y a su vez, filtrando la
información que sale, pudiendo así evitar situaciones de robo.
- Identidad de los clientes, al ser un intermediario, permite que el servidor

no conozca quien está realizando la petición, incrementando la seguridad.
- Rendimiento, se produce un incremento del rendimiento debido a la

memoria caché que integra el servidor proxy. Las solicitudes que se
realizan por primera vez se guardan en la memoria caché. Como todas las
solicitudes son comprobadas, aquellas que son repetidas las responde
directamente desde su caché.
Los tipos básicos de servidores proxy, según el modo de uso y actuación, son los
siguientes [10]:
- Proxy web: Proporciona acceso a la web a través de protocolos HTTP

(Hypertext Transfer Protocol) y HTTPS (Hypertext Transfer Protocol
Secure). Mejora el tráfico, la velocidad de uso, y la seguridad, garantizando
el anonimato del cliente.
- Proxy NAT (Network Address Translation): Para un correcto modo de

trabajo en función de las demandas, se encarga de traducir las direcciones
privadas de los usuarios en una única dirección pública.
- Proxy inverso: Su principal funcionalidad es la de controlar el tráfico. Para

ello, se sitúa en uno o más servidores web según el interés.
- Proxy abierto: Es el menos restrictivo y acepta todas las peticiones que se
hacen desde los ordenadores que estén o no en su red.
- Proxy transparente: Los usuarios desconocen su existencia y se aplica en

aquellas empresas que desean controlar el uso de Internet que hacen sus
empleados, así como restringir el acceso a determinados sitios web.
31
Como conclusión, los servidores proxy son una opción muy buena en sistemas que
vayan a realizarse con acceso a Internet. Son servidores configurables que nos
proporcionan un buen rendimiento, seguridad de Internet controlando el tráfico,
anonimato en los clientes y un gran filtrado tanto de información como de acceso a los
usuarios.
Sin embargo, cuando la carga de peticiones es muy alta pueden no rendir con la misma
efectividad. Para que siga siendo igual de efectivo es importante que el servidor proxy
esté actualizado adecuadamente. Por último, controlar la intromisión de un hacker en
una petición entre el ordenador y el proxy también es difícil.
Servidor
Cliente Internet
Proxy
Figura 9: Escenario típico de un servidor proxy
2.3.4 Protocolos
En 1984 la Organización Internacional para la Estandarización (ISO) se

encargó de redactar el documento que sería la referencia para los protocolos de
Interconexión de Sistemas Abiertos (Open System Interconnection-OSI).
Más adelante, surgiría el modelo TCP/IP que es más sencillo, dividido en 4 capas,
cada una con su correspondencia en el modelo OSI [11].
Los protocolos son métodos estándar que permiten la comunicación entre procesos. Se
basan en reglas y procedimientos que deben respetarse para el envío y recepción de
datos a través de una red. El hecho de que haya muchos protocolos se basa en que es
imposible tolerar todas las comunicaciones existentes y sus características con un
único protocolo. Por ello, en función del número de participantes en la comunicación,
del modo de transmisión de datos, de la jerarquía de los participantes, de la
sincronización de la comunicación y del tipo de conexión, tendremos diferentes
protocolos.
Con una idea general de los protocolos, más adelante se detallarán aquellos que se
vayan a usar en el sistema de seguridad propuesto. En las siguientes imágenes se
pueden observar ambos modelos:
32
Modelo OSI Modelo TCP/IP
Aplicación
Presentación Aplicación
Sesión
----------------------------------------------------------------------------------------------------------------------------------------------------------
Transporte Transporte
----------------------------------------------------------------------------------------------------------------------------------------------------------
Red Internet
----------------------------------------------------------------------------------------------------------------------------------------------------------
Enlace de datos
Acceso a la red
Física
Figura 10: Modelos OSI y TCP/IP
Los protocolos más importantes, en el modelo TCP/IP, con sus correspondencias en el

modelo OSI, son:
- Capa de aplicación: HTTP/S, SSH, NTP y DNS son los más utilizados
- Capa de transporte: Según la orientación a la conexión UDP y TCP
son los más utilizados.
- Capa internet: Destacan IP e ICMP
- Capa de acceso a la red: Los más comunes son los protocolos ARP y
Ethernet
33
2.3.5 DMZ
Una zona desmilitarizada o red perimetral es un área local que se ubica entre la
red interna de una organización y una red externa que suele ser internet.
El objetivo de una red DMZ (Demilitarised Zone) es que toda la información que
quiera acceder a nuestra red interna pueda ser analizada y rechazada por ella. Para ello,
se permite el acceso a la red DMZ tanto desde la red interna como la externa, pero la
red DMZ sólo tiene acceso a la red externa. De esta manera, al no poderse conectar los
equipos de la red DMZ a la red interna, realiza una doble función de proteger a la red
interna y dar servicios a la red externa.
Como conclusión, cualquier amenaza que intente llegar a la red interna debe pasar por
la red DMZ, que al no tener acceso a la red interna se convierte en un callejón sin
salida para las amenazas.
En las redes DMZ se suelen colocar servidores que necesitan acceso exterior, como
servidores Web o servidores de dominio.
Un ejemplo básico de una red DMZ es el siguiente:
Firewall externo
Gestor DMZ
Firewall interno
. .. .
Cliente-1 Cliente-2 . .. . Cliente-n
Figura 11: Escenario típico de una red DMZ
34
2.4 Ciberseguridad
Con la transformación digital y la cantidad de dispositivos conectados a internet,

almacenar datos en cualquier dispositivo con conexión a internet es un riesgo y muchos
hackers se encargan de intentar acceder a ellos. Las empresas que manejan grandes cantidades
de datos tanto a nivel interno como a nivel personal de sus clientes, necesitan proteger toda su
infraestructura informática, para garantizar seguridad y confianza tanto a los propios
trabajadores, como a sus clientes, y de eso se encarga la ciberseguridad.
2.4.1 Riesgos y vulnerabilidades
La ciberseguridad se encarga de asegurar el producto, así como de determinar

la seguridad e integridad de todo el sistema, sus infraestructuras y sus contenidos. Por
ello, aparte de tener las tecnologías más avanzadas y los sistemas más robustos, el
simple hecho de que un administrador del sistema deje el usuario y la contraseña a la
vista de alguien, deja en evidencia todo este trabajo. Por ello la ciberseguridad incluye
elementos tales como la educación de los usuarios y el hábito de uso de las
aplicaciones, ya que son la primera amenaza en un sistema de seguridad.
Por ello se debe asegurar que el producto está libre de vulnerabilidades. Una
vulnerabilidad es una debilidad que puede ser explotada por una tercera persona. Para
localizar vulnerabilidades, hay que tener en cuenta las especificaciones de tu producto,
un seguimiento del desarrollo del mismo y realizar diferentes test de seguridad que
pongan a prueba el sistema.
Los riesgos se cuantifican por el impacto que tienen y su probabilidad:
Figura 12: Cuantificación de riesgos
Los riesgos en la zona verde no serían un problema, los riesgos en la zona amarilla
serían problemáticos en el sistema y los riesgos en la zona roja serían riesgos críticos,
que tendrían mucho impacto y serían altamente probables.
35
La evaluación de las vulnerabilidades se define como el proceso de identificación,

cuantificación y priorización de las vulnerabilidades en un sistema.
El proceso manual se lleva a cabo mediante la revisión de la arquitectura en busca de

fallas de seguridad y la búsqueda de vulnerabilidades públicas en COTS, protocolos o
software utilizado en el sistema. Existen herramientas para facilitar este tipo de
trabajos de forma automática, como pueden ser Nessus, OpenVas y Tripwire
Figura 13: Herramientas para localizar vulnerabilidades en las arquitecturas
2.4.2 Test de penetración
El testing es un conjunto de pruebas de diferentes tipos que nos permiten poner

a prueba nuestro sistema, consiguiendo así obtener vulnerabilidades y posibles
mejoras en el sistema.
Los test más utilizados para probar este tipo de sistemas son los siguientes:
- Test de robustez  Verifican que la validación de la entrada que le das al

sistema se haga correctamente. Para estos test se una utiliza una técnica que
se llama “fuzzing”. Fuzzing consiste en proporcionar datos no válidos,
como datos aleatorios en lugar de certificados, fechas muy antiguas, fechas
negativas, saturar al sistema con muchos datos…etc.
- Test de penetración -> Estos test consisten en darle tu sistema completo a

una compañía o empresa dedicada a este tipo de test para que intenten
piratearte el sistema y así sacar vulnerabilidades. Existen tres tipos de test
de penetración:
- Caja negra: El tester no sabe nada del sistema, y tiene que

intentar abordarlo desde cero.
- Caja blanca: El tester tiene toda la información sobre el
sistema, desde documentos de arquitectura, descripciones de
protocolos…etc
- Caja gris: El tester dispondrá sólo de cierta información, pero
no toda.
36
Una vez se encuentren vulnerabilidades, se deben abordar mediante cambios en el

sistema. El riesgo puede ser minimizado por la arquitectura de seguridad y por las
pautas de seguridad.
Todas las vulnerabilidades que no se traten se deben incluir en una lista e incluirse en
una evaluación de riesgos.
2.4.3 Criptografía
Uno de los aspectos que se debe tener en cuenta a la hora de abordar un sistema
de seguridad es la criptografía. La criptografía es el arte y técnica que permite proteger
información mediante técnicas de cifrado y descifrado. Con estas técnicas los
mensajes podrán ser vistos sólo por personas elegidas a nuestro interés y que
dispondrán de los medios para descifrar nuestros mensajes.
La criptografía permite diferentes tipos de algoritmos de cifrado, entre los que

destacan los siguientes grupos [5]:
- Cifrado simétrico o de clave privada: se usa una única clave tanto el

proceso de cifrado como el de descifrado. El hecho de tener únicamente
una clave obliga a las dos partes de la comunicación a ponerse de acuerdo
sobre la clave a utilizar. El remitente cifrará con la clave acordada y el
destinatario descifrará el mensaje con la misma.
Uno de los problemas de este tipo de cifrado se produce al establecerse la

comunicación. Para un hacker, es más fácil intentar conseguir la clave que
probar todas las posibles combinaciones de la clave. Por otro lado, cuando
se quiere enviar el mensaje a varios destinatarios, se necesitará más de una
clave, lo que dificulta mucho la seguridad en la comunicación.
Figura 14: Escenario típico de un cifrado simétrico
37
- Cifrado asimétrico o de clave pública: Se denomina de clave pública ya

que una de las dos claves en este tipo de cifrados es pública. Se usa una
clave para cifrar los mensajes. una clave diferente para descifrarlo y ambas
son complementarias.
La clave pública debe generarse a través de la privada. De esta forma, la

persona interesada en recibir mensajes de diferentes personas deberá
mandar una clave pública asociada a su clave privada y así los destinatarios
podrán contestar de forma confidencial cifrando los mensajes con esa clave
pública. De esa forma los archivos sólo podrán ser descifrados por la
persona cuya clave pública está asociada a su clave privada.
La mayor desventaja en este tipo de cifrado es el tiempo de procesamiento.

El hecho de manejar dos claves en vez de una ralentiza el proceso
considerablemente.
Para encontrar un punto medio entre la menor seguridad del cifrado

simétrico y el mayor tiempo de cifrado en los cifrados asimétricos, están
los cifrados asimétricos.
Un ejemplo de protección de la información con este tipo de cifrado son las

firmas de digitales, gracias a las cuales el receptor de la información puede
verificar la autenticidad del emisor, así como la integridad del mensaje
durante el proceso de comunicación. Gracias a la utilización de una clave
privada en vez de pública, se evitan los problemas de lentitud que existen en
el cifrado asimétrico.
Figura 15: Escenario típico de un cifrado asimétrico
38
- Cifrado híbrido: Se utiliza un algoritmo de clave pública empleando

únicamente una pequeña cantidad de información. El emisor cifrará un
archivo de forma simétrica. La clave utilizada para cifrar el archivo la
cifrará con la clave pública del receptor. El emisor enviará el archivo
cifrado de forma simétrica y la clave del archivo cifrada de forma
asimétrica y que únicamente podrá ver el receptor.
-
2.4.4 Certificados
La criptografía y los diferentes tipos de cifrado van a ser muy importantes a la hora de
usar certificados en nuestro sistema de seguridad. Un certificado es un medio que
proporcionará la garantía de identidad sobre una persona que envía un mensaje o
petición a un servicio.
La entidad que certifica se denomica autoridad de certificación, y proporciona a la
persona interesada una clave pública para poder realizar procesos de firma y cifrado.
Todos los certificados tienen un número de serie único y un periodo de validez
incluido en el certificado. Los tipos de certificados actuales son:
- Certificado de persona física: identifica a una persona individual.

- Certificado de representante de persona jurídica: se envía a las personas
físicas como representantes de las personas jurídicas.
- Certificado de representante entidad sin personalidad jurídica: se remite a
las personas físicas como representantes de las entidades sin personalidad
jurídica en el ámbito tributario.
- Certificados de Administración Pública.
- Atendiendo al soporte del certificado, se habla de:
- Certificado software: es aquel que consiste en un fichero software, que no
tiene soporte físico alguno más que el propio ordenador o servidor donde se
instala.
- Certificado de tarjeta: es aquel que se encuentra alojado en una tarjeta.
39
2.5 Tecnología hardware y software
2.5.1 Sistemas operativos
El sistema operativo es la parte software más importante de un ordenador. Se

compone de un conjunto de programas que son capaces de gestionar todos los recursos
del ordenador, desde la memoria, hasta los procesos que se puedan ejecutar en él.
El usuario es capaz de comunicarse con el ordenador gracias al sistema operativo, sin

tener la necesidad de aprender el lenguaje del mismo o un conocimiento de
informática avanzado. Es decir, el sistema operativo actúa como intermediario entre el
hardware y las diferentes aplicaciones del ordenador.
Como principales funciones, el sistema operativo [12]:

- Proporciona la interfaz de usuario
- Controla y gestiona el uso del hardware del ordenador
- Controla la instalación, desinstalación y la ejecución de programas de
aplicaciones
- Organiza la información en archivos y carpetas
- Se encarga del mantenimiento del sistema, para un correcto funcionamiento
del sistema avisando de posibles errores
Los sistemas operativos han avanzado mucho y actualmente hay que distinguir entre
sistemas operativos cliente y sistemas operativos servidor.
Un sistema operativo cliente se usa para ordenadores de sobremesa, móviles y

portátiles que se conectan a los servidores en internet a través de un software de
telecomunicaciones. Pueden incluir Windows, Linux, Mac o Android.
Los sistemas operativos servidor son para arquitecturas más complejas y sirven datos a
sus clientes. Este tipo de servidores ofrecerá aplicaciones a los clientes que puedan
acceder a él y podrá comunicarse con otros servidores para atender solicitudes
específicas. Un ejemplo de sistema operativo servidor es Windows Server o
GNU/Linux.
Los diferentes sistemas operativos que nos podemos encontrar tanto a nivel de cliente
como a nivel de servidor son los siguientes:
- Windows. Es el más usado en el mundo y entre sus últimas versiones se

encuentran Windows XP, Windows Vista, Windows 7, Windows 8, y su
última versión Windows 10.
- Linux: Se puede instalar en casi cualquier plataforma. Un gran número de

personas usan esta distribución por la solidez, confiabilidad y seguridad
que ofrece a los usuarios, unido a su gratuidad. Es la base de muchos
sistemas operativos y la distribución más popular es Ubuntu (Ubuntu
18.04).
40
- MacOS: El sistema operativo de Apple. Su última versión es MacOS High

Sierra. Es muy fácil de usar y es derivado de Unix.
- BSD: Distribución que se deriva de Unix, con mucha seguridad y

confiabilidad. Es la base del MacOS, a partir de la versión 10.
- Windows Server. Destacan por su facilidad de uso junto a su alta difusión

y disponibilidad. Requieren licencia con su coste correspondiente y son
desarrollados por Microsoft. Sus últimas versiones son Windows Server
2012, Windows Server 2012 R2 y Windows Server 2016.
- Linux. Destaca por los trabajos multitarea y multiusuario. Son muy

configurables y adaptables a diferentes entornos de trabajo. Los más
destacados son Ubuntu Server, Debian, Red Hat Enterprise Linux y
CentOS.
Figura 16: Tipos de sistemas operativos
2.5.2 Servidores y bases de datos
Un servidor es una unidad hardware con muchas capacidades y aplicaciones.

Disponen en general de una alta capacidad de procesamiento, de almacenar
información y de atender las peticiones de los usuarios clientes. Los servidores pueden
también pueden estar virtualizados.
Los servidores en grandes sistemas se deben montar en gabinetes denominados racks,

pudiendo colocar varios servidores con un ahorro de espacio y más seguridad.
Hay muchos servidores diferentes con diferentes capacidades. Atendiendo al servicio

ofrecido y a su configuración, los servidores más comunes para el tema abarcado son
los siguientes [13]:
41
- Servidor DHCP (Dinamic Host Control Protocol): Se encarga de

administrar las direcciones IP en las redes. Esto conlleva a no tener que
realizar cambios manuales sobre las direcciones de red ahorrando tiempo y
esfuerzo al cliente.
- Servidor de dominio: Administra usuarios, grupos de usuario y se encarga

de la autenticación y accesibilidad de los dispositivos conectados en la red.
Permite relacionar nombres de dominio con direcciones IP, facilitando la
accesibilidad al cliente sin tener que estar manejando numerosas
direcciones IP.
- Servidores web: Permite la interacción del usuario con el contenido de las

páginas web, como Microsoft IIS (Internet Information Server).
- Servidor PBX (Private Branch Exchange): Central telefónica que permite

la interacción del usuario con la red telefónica pública a través de enlaces
digitales, ofreciendo la capacidad de gestionar llamadas entrantes, internas
y salientes. El software más común de estas características es Asterisk, con
distribución operativa Linux.
- Servidor FTP (File Transfer Protocol): Facilita la carga y descarga de

archivos entre los dispositivos conectados a la red proporcionando a su vez
capacidad de almacenamiento.
Hoy en día se manejan grandes cantidades de datos en todo el mundo. Si hablamos

de sistemas de seguridad, en los cuales un vídeo grabado o una conversación
telefónica deben poder ser consultados de una forma rápida, necesitamos un sistema
de almacenamiento fiable, actual y accesible.
Una base de datos es una recolección organizada de registros o datos que se

almacena en un sistema informático [14]. La clave del funcionamiento de las bases
de datos, aparte de la organización de los datos, es una fácil accesibilidad a
actualizarlos y consultarlos.
Para que la base de datos tenga un buen funcionamiento en el sistema, debe disponer
de un gestor de bases de datos que sirva de interfaz entre el usuario y la base de
datos. Aparte de esto, se debe disponer de una redundancia que le haga recuperar los
datos en caso de falla. Los gestores de bases de datos más importantes son MySQL,
Microsoft SQL Server, Oracle, Microsoft Acces y Postgre SQL.
También hay servidores que ofrecen servicio de bases de datos:
- Servidor de bases de datos: Ordenador que dispondrá de una o varias

bases de datos y que se encarga de almacenar grandes cantidades de
información, gestionando la accesibilidad entre el cliente y los datos de su
red. La aplicación más usada en estos servidores es Microsoft SQL Server.
42
2.5.3 Sistemas CCTV
Hoy en día los sistemas de videovigilancia y seguridad se hacen visibles a

diario. Hogares, pequeñas tiendas, grandes empresas, aeropuertos, campos de
fútbol…en todos ellos podremos ver alguna cámara que nos enfoca y graba todos
nuestros movimientos.
A estos sistemas de seguridad se les denomina sistemas CCTV y su primera aparición

fue en Estados Unidos e Inglaterra entre los años 1960 y 1970. Desde que se
instauraron hace casi unos sesenta años, con cámaras de baja resolución en blanco y
negro y conectadas mediante un cable coaxial, y necesitando un monitor por cámara,
la evolución de las cámaras y monitores, así como su configuración, ha sido
exponencial.
En sus orígenes, la funcionalidad de estos sistemas era muy básica, tenían poco
rendimiento y eran muy caros. Actualmente, las cámaras vienen con muchísimas
mejoras, desde una alta resolución, opción de zoom…incluso con suplementos como
visión nocturna gracias a la tecnología de rayos infrarrojos. Gracias a este gran avance
de los sistemas CCTV y al avance tecnológico de la sociedad, donde Internet es un
pilar básico y gran información se guarda en él, implantar un buen sistema que permita
controlar y ver un perímetro es totalmente básico a cualquier nivel.
Para diseñar un sistema CCTV, se deben tener en cuenta sus componentes:
- Cámaras de seguridad: hay muchos tipos con diferentes características en

función de las necesidades del cliente. Para un sistema de seguridad, se
puede diferenciar entre cámaras analógicas y cámaras IP.
- Cámaras analógicas.
Son las primeras cámaras que fueron
utilizadas para sistemas CCTV y aún se
siguen utilizando. La imagen de la cámara
sale de forma analógica utilizando una
señal de corriente alterna y con amplitud
variable.
Normalmente este tipo de cámaras se

conectan a un DVR (Digital Video
Recorder) y tienen una impedancia de
salida de 75 ohmios, por ello se requiere
Figura 17: Cámara
el uso de un cable coaxial o UTP
analógica (Unshielded Twisted Pair) con
adaptadores de impedancia.
43
- Cámaras IP:
Se visualizan por internet o a través de
una red local. Tienen un puerto ethernet
con terminal Rj45 y se conectan al router
a través de un cable UTP.
También hay cámaras IP inalámbricas,

que se conectan a la red WiFi, pero
pierden potencia a nivel de seguridad
debido a su escasa calidad y al tipo de
conexión que utilizan.
Figura 18: Cámara IP
- Videograbador: Necesario para visualizar imágenes en directo, así como

poder grabar y reproducir imágenes. También se deberán incluir
codificadores y decodificadores de vídeo.
Son tres los diferentes tipos de grabadores que se utilizan actualmente y se
diferencia en el tipo de cámaras que se conectan:
- DVR: Es el más económico y se conecta a cámaras analógicas que

le envían una señal de vídeo que digitaliza.
- NVR (Network Video Recorder): Se aplican en sistemas IP y las

imágenes llegan ya procesadas al grabador. Es más caro, pero aparte
de más calidad ofrece mejor rendimiento, con mayor calidad y
resolución.
- NDVR (Network Digital Video Recorder): Es un videograbador

híbrido que combina las dos tecnologías, utilizando instalaciones
analógicas con tecnología IP.
- Sistema de almacenamiento, para guardar toda la información grabada, o

la seleccionada por el cliente. Se podrán utilizar discos duros o bases de
datos, dependiendo de la disponibilidad requerida por los clientes.
- Alimentación del sistema con todo su cableado.
2.5.4 Teléfonía
La telefonía es uno de los servicios básicos en la sociedad actual, y por ello es

un elemento clave en los sistemas de seguridad. Para un operario, tener un sistema de
comunicación robusto, altamente disponible y con capacidad de maniobra, es algo
fundamental. Poder realizar una llamada de auxilio, o simplemente de comunicación a
un compañero, así como realizar la escucha pasiva en uno de los interfonos
disponibles, son aspectos básicos para garantizar la seguridad de nuestro cliente.
44
El servicio de telefonía más actual es la telefonía IP [15], en el cual la transmisión de

llamadas telefónicas se realiza a través de internet. Es uno de los desarrollos
tecnológicos al cual muchas empresas se están adaptando. Destaca por su fácil y
rápida integración, lo que conlleva una migración eficaz y un ahorro significativo en
costos. Una de las ventajas de este tipo de telefonía, es el prevalecimiento del estándar
SIP (Session Initiation Protocol). El protocolo SIP negocia las modalidades de
conexión en las llamadas. De esta manera, los proveedores VoIP (Voice Over Internet
Protocol) se aseguran de que sus dispositivos y servicios van a seguir funcionando en
diferentes escenarios.
Los componentes principales de la telefonía IP son:
- Dispositivos, ya sean teléfonos tradicionales u ordenadores.
- Gateways VoIP: cuando participa un teléfono hardware en la

comunicación siempre es necesario.
- Proxy VoIP/SIP: El proxy o servidor administrará las llamadas, y se utiliza

generalmente en empresas o entornos cerrados.
Los teléfonos SIP son aquellos teléfonos que funcionan utilizando SIP y RTP (Real-
time Transport) como protocolos de transporte. Es importante diferenciar entre
teléfonos SIP físicos y teléfonos SIP virtuales:
- HarPhones: la funcionalidad es la misma que la de un teléfono normal,

pero el hardware está construido utilizando componentes de red. Es decir,
el teléfono se conectará mediante red IP mediante un cable Ethernet o
incluso a través de red inalámbrica.
- SoftPhones: es un programa de software que proporciona un teléfono

virtual con las mismas funcionalidades que un teléfono físico. Utiliza los
mismos protocolos SIP y RTP para configurar llamadas y transmitir la voz.
Mientras haya una conexión IP a un proveedor VoIP o servidor SIP, en
cualquier dispositivo (como un ordenador de escritorio o un Smartphone)
con un sistema operativo actual pueden ejecutarse este tipo de softphones.
Las ventajas que ofrece tener un softPhone a nivel de limitaciones es que

no va más allá de un desarrollo software.
Como requisito, es necesario un servidor que gestione las llamadas en la red, y de eso
se encargan los servidores SIP. Un servidor SIP es el componente principal de una
centralidad IP o PBX IP (Private Branch Exchange), y, aunque no se encarga de la
transmisión de la llamada, sí que tiene funciones importantes, como administrar
privilegios a los usuarios, transferencia de llamadas, registro de llamadas…
Por otro lado, una PBX es una red telefónica privada. Al principio, las PBX
tradicionales se basaban en una red de telefonía privada que funcionaba a través de
diferentes cableados, utilizando una centralita a la que se conectaban las diferentes
extensiones disponibles [16]. Actualmente, esas PBX se encuentran prácticamente
45
obsoletas y se utilizan PBX virtuales y que funcionan a través de Internet. Su

funcionamiento es sencillo, y utiliza un número fijo virtual como cabecera, sin usar
cables y desviando las llamadas recibidas a otras líneas, que pueden ser líneas fijas,
móviles o IP. Entre muchas de las ventajas que tiene, destaca por no tener limitación
de extensiones, tener un gran rendimiento procesando operaciones con llamadas y una
clara eficiencia a la hora de instalar la PBX, ya que se realiza a través de software.
Existen cuatro claros escenarios en un proceso de llamada, que se producen

entre un dispositivo PSTN (Public Switched Telephone Network) o un ordenador [17]:
1. De ordenador a ordenador: proceso que se realiza utilizando únicamente

software, a través de un softPhone en cada ordenador.
2. De ordenador a teléfono: es necesario un Gateway VoIP para que el

ordenador pueda convertir la llamada de Internet en una llamada telefónica.
3. De teléfono a teléfono: proceso más tradicional y en el cual no se utilizan

ordenadores en la comunicación. Ideal para usuarios que quieran
beneficiarse de los ahorros económicos que ofrece le telefonía VoIP, como
en el caso de los teléfonos móviles. En estos casos la llamada debe pasar
dos gateways, uno del dispositivo a Internet y otro de Internet al
dispositivo.
4. De teléfono a ordenador: es el caso inverso al escenario dos, donde un

teléfono puede convertir una llamada telefónica en una llamada de Internet
a través de un gateway VoIP.
2.5.5 Sensores
Son pequeños dispositivos encargados de detectar personas u otros elementos

extraños con un campo de actuación variable. La información es recogida y enviada
mediante módulos repetidores a una unidad de control la cual desencadenará una
respuesta.
Según si se quiere activar o inactivar la alarma el sensor actuará como puente del
circuito, abriéndolo o cerrándolo, de modo que, si el sensor está activo, el circuito
quedará cerrado y se desencadenará la respuesta. En el caso de varios sensores, estos
deberán instalarse en serie para mantener este efecto.
La instalación puede ser mediante cableado, lo cual requiere alimentación paralela, o

por receptores de radio.
Dentro de la gran variedad de sensores existentes, los de intrusión, que serían más
útiles en relación al proyecto, son los siguientes [18]:
46
1. Perimetrales: Encargados de vigilar el perímetro de la instalación a

proteger. Por ser sensores de exterior deben ser capaces de soportar y no
responder a incidencias atmosféricas.
1.1. Sensor sísmico o de vibración: Sobre superficie. Dedicados a

detectar vibraciones o golpes. Al producirse un golpe o vibración
dentro del sensor se produce la separación de dos masas, lo que
origina la interrupción del envío de una señal eléctrica.
1.2. Sensor por contactos magnéticos: Sobre superficie. Dedicados

generalmente a detectar la apertura de puertas, ventanas…
1.3. Detectores de doble tecnología: detector de inflarojos y por

microondas. Deben activarse ambos para desencadenarse la
respuesta.
2. Sensores volumétricos: Detectan movimiento dentro de un volumen

determinado. Tienen un alcance limitado y son muy sensibles, sin poder
ubicarlos en el exterior.
2.1. Sensor por radar o microondas: Un emisor emite las ondas

electromagnéticas que se reflejan por los objetos que son
registradas por un receptor.
2.2. Sensores por infrarrojos: No pueden ser expuestos a rayos solares

ni a altas temperaturas…Detectan el calor humano emitido en
forma de radiación infrarroja, proporcional a su temperatura.
3. Sensores lineales: Detectan la rotura de una barrera. Compuestos por

elemento emisor y otro detector.
3.1. Sensores de barreras infrarrojos: Pueden ubicarse en el interior o

exterior. Hay dos emisores y un receptor. La alarma se activa
cuando son atravesados los dos haces paralelos.
3.2. Sensor de barrera por microondas: Enterrados en exterior. El

emisor y receptor están conectados por un cable. El emisor emite
impulsos de alta frecuencia que producen una onda de superficie a
lo largo del cable y el receptor lo recibe como “condiciones
normales”. Si algún elemento en superficie produce una variación
en la onda, el receptor lo recibe y activa la alarma.
4. Sensores especiales:
4.1. Sensor G.P.S: Enterrados en exterior. Al encontrarse enterrados
se activan al recibir presión.
47
4.2. Las vallas sensorizadas: Sensores de vibración sobre una valla.

Cuando el detector registra movimiento activa la alarma.
4.3. Sensores de humo/incendio: Dedicados a detectar la presencia de

un incendio en el interior de edificio un. Pueden ser analógicos
(cuantitativos) o digitales (únicamente presencia o ausencia)
48
3 DISEÑO Y DESCRIPCIÓN DEL PROYECTO
3.1 Descripción del proyecto
En este proyecto se pretende configurar, probar y mostrar un sistema de seguridad “on

premises” de alta disponibilidad (99,99%). Este sistema dispondrá de la integración de
diferentes COTS que proporcionarán servicios de telefonía, vídeo en vivo, bases de datos para
guardar información y balanceo de peticiones web. Los servicios ofrecidos deben garantizarse
con una alta disponibilidad a través de una arquitectura sólida y segura.
El sistema diseñado sigue el siguiente esquema:
Figura 19: Arquitectura del proyecto
La arquitectura, después del estudio y el marco tecnológico propuesto, ofrece cuatro servicios
diferentes al cliente. El sistema trabajará “on premises”, es decir, a nivel local y las máquinas
virtuales estarán gestionadas por un servidor de dominio que proporcionará a los usuarios
deseados los permisos para acceder a los servicios.
Por otro lado, para garantizar alta disponibilidad, cada servicio dispone de una arquitectura
que lo soporta diferente a las demás (lo cual caracteriza al sistema), y que le hace estar
altamente disponible y trabajando de una forma eficaz durante el tiempo de ejecución de sus
servicios. La elección de los diferentes sistemas, que se detallarán más adelante en la
implementación, se resume a continuación:
- Servicio de telefonía: Se dispondrá de dos servidores de telefonía que

trabajarán con el software de la marca Asterisk. Estos dos servidores
correrán sobre un sistema operativo Linux, y trabajarán en alta
49
disponibilidad mediante una solución que ofrece Linux denominada

Keepalived.
- Servicio de vídeo en vivo: El usuario podrá ver vídeos en vivo. Este

servicio se proporcionará al cliente a través de dos servidores de vídeo de la
marca Wowza que trabajarán sobre la distribución Windows Server. La
gestión del tráfico de peticiones y la alta disponibilidad se gestionará través
de un clúster que gestionará Windows Server y que tendrá el rol del
servidor de vídeo. El usuario también podrá reproducir un flujo unicast-
multicast, reproduciendo el mismo streaming de vídeo en varias
aplicaciones a la vez.
- Servicio de bases de datos: El cliente podrá realizar peticiones a bases de

datos. Se dispondrá de dos servidores de bases de datos SQL que
dependerán de una SAN para guardar esta información. Los dos servidores
SQL trabajarán en alta disponibilidad a través de un failover cluster de SQL
sobre un clúster de Windows Server.
- Servicio de peticiones a servidores: Dos servidores web gestionados por

un balanceador de carga software de la marca “HAProxy” proporcionarán
alta disponibilidad a peticiones web del cliente.
- Servicio adicional de seguridad. Directorio activo: Se implementarán

dos directorios activos que irán sincronizados para aumentar la seguridad
de nuestro sistema.
La arquitectura se va a desarrollar sobre un entorno virtualizado. Para ello será necesario un

servidor de máquinas virtuales. Este servidor irá colocado en un rack y conectado a la red
interna. El software utilizado para gestionar las máquinas virtuales será VMware.
3.2 Proceso del proyecto
La arquitectura propuesta de forma detallada, así como el proceso que se va a seguir

para implementarla, es el siguiente:
1. Preparación del entorno de trabajo:

- Servidor de máquinas virtuales.
- Entorno de trabajado en VMware.
50
2. Directorio activo:
- Sobre distribución Windows Server: Windows Server 2016.
- Creación de un dominio propio: tfg.local.
- Implementación y configuración.
3. Servicio de bases de datos:

- Configuración para realizar el cluster de bases de datos: Red,
almacenamiento compartido, conexión e integración.
- Instalación de un clúster en Windows Server.
- Instalación del failover cluster en SQL Server 2017.
- Configuración e integración.
- Aplicación para probar el servicio: SQL management studio.
- Pruebas y conclusiones.
4. Balanceador de carga:
- Sobre sistema operativo Linux: CentOs 7.
- Instalación software HAProxy.
- Configuración: Puertos, servidores a balancear, así como el algoritmo de
balanceo.
- Aplicación para probar el servicio: Postman.
- Interfaz configurabe HAProxy.
5. Servicio de telefonía:
- Sobre sistema operativo Linux: CentOs 7.
- Instalación del software Asterisk.
- Instalación del servicio Keepalived.
- Aplicación para probar el servicio: Zoiper.
6. Servicio de vídeo en vivo:

- Instalación del software Wowza versión 4.7.5.
- Instalación del failover cluster manager.
- Aplicación para probar el servicio: VLC versión.
7. Conclusiones generales, así como mejoras futuras:

- Conclusiones de todas las pruebas.
- Problemas surgidos durante la realización de la arquitectura.
- Cumplimiento de objetivos propuestos.
- Posibles mejoras a la arquitectura.
51
4 IMPLEMENTACIÓN DEL PROYECTO
4.1 Despliege de máquinas virtuales.
Como se ha comentado en la descripción de la solución propuesta, el entorno del

sistema a implementar será totalmente virtualizado. Para ello, la herramienta a utilizar va a ser
Vmware [19], software que servirá para gestionar todas las máquinas virtuales sobre las que
va a trabajar el sistema. Este software tirará de un servidor de máquinas virtuales que estará
montado en un rack de servidores y conectado a la red interna.
Una vez descargado VMware, se van a desplegar 10 máquinas virtuales, a partir de tres
templates de diferentes sistemas operativos. Las templates han sido descargadas de un
repositorio interno de Alstom, pero bastaría con acceder a templates ofrecidas por el
proveedor oficial.
El entorno de trabajo se llamará “Rubén environment” y las máquinas de las que va a

disponer van a ser las siguientes:
Tabla 2: Máquinas virtuales de la arquitectura
Nombre de la Sistema
Breve descripción de la máquina
máquina virtual operativo
Windows Server
TFG-AD-1 Directorio active-1
2016
Windows Server
TFG-AD-2 Directorio active-2
2016
Windows Server
TFG-SQL-1 Base de datos-1
2016
Windows Server
TFG-SQL-2 Base de datos-2
2016
TFG-NLB-1 Linux- Centos 7 Balanceador de carga-1
TFG-NLB-2 Linux- Centos 7 Balanceador de carga-2
TFG-AST-1 Linux- Centos 7 Asterisk para telefonía-1
TFG-AST-2 Linux- Centos 7 Asterisk para telefonía-2
Windows Server Wowza para video en vivo-1.
TFG-WOWZA-1
2012 R También actuará como seb Server-1
Windows Server Wowza para video en vivo-2.
TFG-WOWZA-2
2012 R También actuará como seb Server-2
El proceso a seguir para desplegar las máquinas es el siguiente:
1. Seleccionar la template, y seleccionar desplegar una nueva máquina virtual de esta

template.
2. Seleccionar las características de la máquina virtual, así como el entorno donde se
desea desplegar la máquina.
52
En este sistema se va a utilizar la red ISM_VAL, una red interna de Alstom y

que ocupa el rango de IPs desde la 172.31.130.0 a la 172.31.130.299.
3. Una vez completadas las características de la máquina virtual, darle a aceptar. Al

cabo de un tiempo, que se puede seguir en la parte inferior de la aplicación, la
máquina virtual estará disponible para utilizarse.
4.2 Directorio Activo
Con el fin de proporcionar un sistema más seguro, así como de facilitar la gestión del
entorno y un sistema de autenticación y autorización robusto, se va a implementar un
directorio activo. Este servicio lo ofrece Windows Server y para ello se van a desplegar dos
máquinas virtuales de este sistema operativo, en concreto Windows Server 2016.
Figura 20: Máquinas virtuales

desplegadas. Directorio activo
Lo primero que se va a realizar con cada una de las máquinas es asignarles una IP
fija en la red. Para ello, acudir a Open Network and sharing
center/Ethernet/Properties/Internet Protocol Version 4, y ponerla IP deseada dentro del
rango disponible. El gateway que se puede observar es un gateway utilizado a nivel interno
para poder acceder remotamente a las máquinas virtuales y tener un puente entre las
diferentes redes de la empresa.
53
Figura 21: Asignación de IP en el

directorio activo
La dirección 127.0.0.1 es una dirección de red para referirse a la propia máquina en la que
se está ejecutando el comando.
Lo segundo es cambiar el nombre de las máquinas virtuales, que se puede realizar

en This PC/Properties/Advanced system settings/Computer name. Las dos máquinas que
proporcionarán el directorio activo se nombrarán TFG-AD-1 y TFG-AD-2.
El objetivo de tener dos máquinas virtuales para gestionar el directorio activo y no una, es
el de proporcionar alta disponibilidad. De esta manera, ambas máquinas estarán
sincronizadas, y todo lo que se guarde en una máquina virtual estará disponible
simultáneamente en la otra:
TFG-AD-1 TFG-AD-2
Replicación
síncrona
172.31.130.16
172.31.130.15
Red
Figura 22: Configuración del directorio activo en el proyecto
54
Con las IPs fijas y el nombre que se va a usar a lo largo del proyecto, para la instalación del
directorio activo se deben seguir los siguientes pasos:
1. En la máquina principal (TFG-AD-1), en Server Manager, instalar rol: Active

directory domain service.
Figura 23: Instalación del rol “Active directory domain service”
2. En la instalación, como nombre del nuevo dominio se va a utilizar tfg.local.

Siguiendo los pasos de la instalación, se añadirá el servidor de dominio y se
establecerá una contraseña:
Figura 24: Instalación del rol “Active directory domain service” (II)
55
3. Seguir los pasos y seleccionar la opción “no crear delegación”, hasta el final de la
instalación:
Figura 25: Instalación del rol “Active directory domain service” (III)
4. Una vez instalado en TFG-AD-1, reiniciar la máquina y proceder a realizar la

instalación en TFG-AD-2. Se realiza de la misma manera, pero añadiendo la
máquina a un dominio ya creado, e introduciendo la contraseña creada en la
instalación en TFG-AD-1:
Figura 26: Instalación del rol “Active directory domain service” (IV)
56
5. Una vez finalizada la instalación en TFG-AD-2, reiniciar la máquina. Con el rol

instalado en ambas máquinas y después de haberlas reiniciado, se ha introducido
las IPs de ambas máquinas en el apartado de servidores de dominio en
asignaciones de IP:
- Preferred DNS Server: 172.31.130.15

- Alternate DNS Server: 172.0.0.1
6. Finalmente, el directorio activo está instalado con el dominio tfg.local. Para

gestionar el directorio activo, se utiliza la herramienta “Management console”,
desde donde se van a gestionar las máquinas que forman el sistema (todas estarán
en el dominio), así como los usuarios que podrán acceder a cada una de ellas.
Figura 27: Microsoft management console
4.3 Cluster de bases de datos
Con el servicio de bases de datos se va a proporcionar al cliente una plataforma segura

en la cual pueda operar, guardar datos, y solicitar información. Para ello, se van a desplegar
dos máquinas virtuales con sistema operativo Windows Server 2016.
En el despliegue, se han añadido tres interfaces de red aparte de la red local para la conexión
de las máquinas con los recursos compartidos de una red SAN que formarán parte de la
arquitectura. (SAN_SPA, SAN_SPB e INTRA):
57
Figura 28: Configuración de red en las máquinas

virtuales de SQL
Para garantizar máxima disponibilidad, se va a implementar un failover cluster de

bases de datos sobre un clúster (activo-pasivo) de Windows. Para ello, se configurarán las
máquinas virtuales, después el sistema de almacenamiento compartido a través de una SAN
con el cual se instalará el clúster de Windows, y finalmente, el cluster de bases de datos.
Como prerrequisitos se deben tener:
- Ambos servidores deben estar introducidos en el dominio, y con un nombre

correspondiente al entorno de trabajo
- Configuración de la red para poder disponer de los recursos compartidos a
través de la SAN
- La memoria debe estar configurada para tener tres espacios de
almacenamiento (E:\ y F:\ y G:\)
- MS Windows Server 2016 (64-bit) English R2 Enterprise y SQL Server
2017 instalado en los dos servidores de bases de datos. Windows cluster
debe estar configurado previamente a la instalación de SQL Server
- El usuario que utilice el sistema de bases de datos debe tener permisos de
administrador
El primer paso a realizar en todas las máquinas es asignarles una IP fija en el rango de red,
como se realizó en la instalación del dominio activo. En la misma ventana, introducir las IPs
de los servidores de dominio.
Las IPs asignadas son:

- TFG-SQL-1: 172.31.130.18
- TFG-SQL-2: 172.31.130.19
Por ejemplo, en la máquina virtual TFG-SQL-2:
58
Figura 29: Configuración de red en las

máquinas virtuales de SQL (II)
Una vez configurada la IP, cambiar el nombre a la máquina en Equipo → Propiedades, y

añadir el dominio “tfg.local”. Una vez introducido, reiniciar la máquina para que se
guarden las propiedades, así como la introducción de la máquina en el dominio.
Figura 30: Configuración de red en las

máquinas virtuales de SQL(III)
59
Con las dos máquinas preparadas, hay que configurar los recursos compartidos (SAN) que
van a utilizar ambos nodos del cluster en los que se apoyarán nuestras bases de datos. Los
recursos compartidos deben proporcionar los siguientes volúmenes LUN (Logical Unit
Number):
- QOURUM: debe tener 1 GB de tamaño. El quorum es el encargado de que los
nodos del clúster trabajen de una forma controlada, sin interrupciones entre ellos y
comportamientos anómalos en la gestión de los servicios ofrecidos.
- MSDTC (Microsoft Distributed Transaction Coordinator): debe tener 2 GB de
tamaño. MSDTC se va a encargar de todas las transaciones establecidas con los
recursos del clúster.
- DATA: Almacenamiento de los datos, en función del proyecto, pero 2 GB como
mínimo.
La conexión con los recursos compartidos se va a realizar a través del siguiente esquema:
Figura 31: Configuración de red en las máquinas virtuales

de SQL (IV)
La configuración de red IPs que deben tener las máquinas virtuales para acceder a los
recursos compartidos son:
- ISM_VAL: la IP de la propia máquina, configurada previamente. Rango local:

172.31.130.0/24
- SAN_SPA: conexión a la red SAN. A través de esta red se conectará a los
recursos compartidos. Rango:192.168.14.0/24
- SAN_SPB: conexión a la red SAN. A través de esta red también se conectará a los
recursos compartidos. Rango:192.168.15.0/24
- INTRA: la que el usuario quiera, se utilizará para la sincronización de las
máquinas. Es una conexión privada de ambos nodos del cluster para saber el
estado del otro.
Las IPs configuradas han sido las siguientes:
60
Tabla 3: Configuración de red. Bases de datos
TFG-SQL-1 TFG-SQL-2
ISM_VAL 172.31.130.18 172.31.130.19
SAN_SPA 192.168.14.8 192.168.14.9
SAN_SPB 192.168.15.8 192.168.15.9
INTRA 192.168.9.18 192.168.9.19
Una vez que las máquinas virtuales están preparadas para acceder a los recursos
compartidos, se van a crear y configurar los mismos a través de la plataforma de HP
“Storage Manament Utility”, que es una herramienta ofrecida por HP al comprarle el
servidor NAS.
Figura 32: Acceso a los recursos compartidos
Figura 33: Configuracion de los recursos compartidos
Los
pasos seguidos para crear y configurar los volúmenes son:
61
1. Dar de alta a los host (TFG-SQL-1 y TFG-SQL-2)
Figura 34: Configuracion de los recursos compartidos (II)
El campo host ID se encuentra, en la máquina virtual, en Server Manager iSCSI

Initiator Properties:
Figura 35: Configuracion de los recursos compartidos (III)
2. Crear los volúmenes Quorum, MSDTC y DATA (decididos 30 GB de capacidad

para el proyecto), en una de las dos SAN, asignando una LUN a cada uno:
62
Figura 36: Configuracion de los recursos compartidos (IV)
Los volúmenes creados:
3. Dar permisos a los hosts, a través de la opción “explicit mappings” en cada uno de
los volúmenes creados.
Figura 37: Configuracion de los recursos compartidos (V)
63
4. Conectar con los volúmenes. Ya en la máquina virtual (TFG-SQL-1), acudir de

nuevo, en Server manager, a iSCSI Initiator Properties → Volumes and Devices.
Aquí aparecerán los volúmenes creados, poniendo la dirección IP de la SAN

utilizada para crear los volúmenes, y dando a Auto-configure:
Figura 38: Configuracion de los recursos compartidos (VI)
5. Inicializar los volúmenes. En Server Manager → Computer Management,

aparecerán los discos. Para ello, hacer click derecho en cada disco y:
 NODO 1 – Poner online, inicializar y formatear volumen
 NODO 2 – Sólo poner Online el volumen
 Marcar la opción GPT en la inicialización de cada disco, seguir los pasos
hasta el final
Figura 39: Configuracion de los recursos compartidos (VII)
64
6. Una vez realizado el proceso, en Computer Management, aparecerán todos los

discos, y cambiándoles el nombre, se visualizan de la siguiente manera:
Figura 40: Configuracion de los recursos compartidos (VIII)
Ahora las máquinas virtuales están configuradas y tienen acceso a los recursos
compartidos (SAN). El siguiente paso es crear en el directorio activo un usuario de acceso
a las bases de datos, un usuario de servicio y un grupo en el que se organicen ambas
cuentas:
- SQL_ADMIN: con permisos de administrador en las dos máquinas.
- SQL_SERVICE: cuenta de servicio
Para crear las cuentas de usuario, acceder al directorio activo → tfg.local → crear usuario.
Después, en la cuenta Administrator, añadir SQL ADMIN (va a ser la única cuenta que
trabajará como administrador)
Para crear la cuenta de servicio, acceder al directorio activotfg.localY añadir un

objeto de tipo grupo. Marcar las opciones “Global”, y “Security”:
Figura 41: Creación de cuentas en el directorio activo
Abrir el grupo y añadir las dos cuentas de usuario creadas:
65
Figura 42: Creación de cuentas en el

directorio activo (II)
Con las dos cuentas y el grupo creado, las máquinas virtuales están configuradas y con la
seguridad que ofrece el dominio y sus usuarios para instalar el cluster de Windows. Los pasos
seguidos para la instalación del cluster de Windows son:
1. En las dos máquinas virtuales, ir a Server manager → Manage → Add Roles and
Features → Next:
Figura 43: Instalación del rol “Failover clustering“
2. Avanzar hasta “Features”, seleccionar la opción “Failover Clustering” e instalar:
66
Figura 44: Instalación del rol “Failover clustering“ (II)
Figura 45: Instalación del rol “Failover clustering“ (III)
Figura 46: Instalación del rol “Failover clustering“ (III)
67
3. En las dos máquinas virtuales, en el panel de control, dar permisos de

administrador local a la cuenta SQL_ADMIN creada en el directorio activo:
Figura 47: Asignación de permisos de administrador local
4. A partir de este momento, se puede usar la cuenta TFG\SQL_ADMIN para acceder

a las máquinas virtuales de bases de datos.
5. En “Server Manager”, entrar en “Failover Cluster Manager”, y seleccionar

“Validate Configuration”:
Figura 48: Configuración del clúster
68
6. Añadir ambos nodos al cluster:
Figura 49: Configuración del clúster (II)
7. Seleccionar que se hagan todos los test, y que se complete sin errores graves:
Figura 50: Configuración del clúster (III)
8. Con ambos nodos validados, en “Failover Cluster Manager”, seleccionar la opción

“Create Cluster” y añadir ambos nodos:
Figura 51: Configuración del clúster (IV)
69
9. Seleccionar un nombre y dirección IP para el cluster:
Nombre: TFG-SQLCLUSTER
IP: 172.31.130.17
Figura 52: Configuración del clúster (V)
10. Confirmación de los datos del cluster creado:
Figura 53: Configuración del clúster (VI)
70
11. Acceder al cluster creado, y ver que los discos compartidos están funcionando
correctamente:
Figura 54: Comprobación de la instalación y configuración del cluster de Windows
12. En el cluster, crear el rol DTC (acorde al recurso MSDTC) que sirve para
coordinar los cambios de nodo en el cluster así como informarse de los estados de
ambos nodos. Al rol se le debe asignar una IP del rango, así como el recurso de
almacenamiento en el que procesar la información (MSDTC):
Figura 55: Instalación del rol DTC
Figura 56: Instalación del rol DTC (II)
71
13. Como resultado, se puede ver el rol funcionando en el clúster, así como la
finalización de la la instalación y configuración del clúster de Windows:
Figura 57: Instalación del rol DTC (III)
Figura 58: Comprobación de la instalación y configuración del rol DTC
Por último, para terminar este servicio, hace falta instalar el SQL Server 2017. Los pasos a
seguir son los siguientes:
1. Ejectuar el instalable SQL Server 2017, y pulsar en “New SQL Server failover
cluster installation”:
Figura 59: Instalación y configuración del failover cluster

de SQL. Nodo-1
72
2. Introducir la licencia y avanzar en los pasos hasta la opción “Feature Selection”.

En ella, se han seleccionado las opciones “Database Engine Services”:
Figura 60: Instalación y configuración del failover cluster de SQL. Nodo-1 (II)
3. En el siguiente paso, se han seleccionado el nombre de la red y la instancia por

defecto “MSSQLSERVER”.
Nombre de la red: TFG-SQL
Figura 61: Instalación y configuración del failover cluster de SQL.

Nodo-1 (III)
73
4. Se ha escogido el nombre de los recursos (por defecto), y el disco donde se van a

guardar los datos (DATA_TFG, creado anteriormente):
Figura 62: Instalación y configuración del failover cluster de

SQL. Nodo-1 (IV)

Nodo-1 (V)
74
5. Avanzando en la instalación, se ha escogido la IP: 172.31.130.25 para el failover

cluster, así como las cuentas que van a gestionar los servicios de las bases de datos
(SQL_SERVICE, creada anteriormente):
Figura 64: Instalación y configuración del failover cluster de SQL. Nodo-1 (VI)
Figura 65: Instalación y configuración del failover cluster de SQL. Nodo-1 (VII)
Figura 66: Instalación y configuración del failover cluster de SQL. Nodo-1 (VIII)
75
6. Como método de autenticación, se ha seleccionado el método mixto. Por otro lado,

se han añadido los usuarios que pueden ser administradores del clúster
(SQL_ADMIN, creado anteriomente, y el administrador local)

SQL. Nodo-1 (IX)

SQL. Nodo-1 (X)
76
7. La instalación se completa correctamente y en “Failover Cluster Manager” aparece

el servicio de SQL:

Nodo-1 (XI)
Figura 70: Comprobación del rol MSSQLSERVER
8. En el nodo 2, realizar la instalación de la misma forma, pero seleccionando la

opción “Add node to a SQL Server failover cluster”
77
9. Ya en la ventana de instalación, en el apartado “Cluster Node Configuration”, se

ha seleccionado la instancia creada:

Nodo-2
10. La instalación finaliza correctamente y, para comprobar su funcionamiento, se ha

movido el rol del cluster al nodo 2, observando que no hay ningún problema:
Figura 72: Comprobación y funcionamiento. Failover cluster de SQL
Figura 73: Comprobación y funcionamiento. Failover cluster de SQL (II)
78
El proceso de preparación de este servicio es el más largo, pero también es el más

importante. Guardar la información y tener la certeza de que no la vas a perder, es crucial.
Más adelante, en el apartado de pruebas, se realizarán pruebas para probar esta parte de la
arquitectura.
4.4 Vídeo en vivo
Con el servicio de vídeo en vivo el cliente tendrá acceso a diferentes cámaras en directo.
Aparte, se podrá reproducir un flujo de vídeo unicast-multicast observando el mismo streaming de
vídeo en diferentes aplicaciones. Para ello, se van a desplegar dos máquinas virtuales con sistema
operativo Windows Server 2016. En ambas máquinas se instalará y configurará el software Wowza
Streaming Engine 4.7.5, que proporciona servicios de vídeo en vivo, entre otros. El servicio estará
en alta disponibilidad, gracias a la instalación y configuración de un failover cluster (Activo-pasivo)
de Windows en el cual se instalará el rol ofrecido por Wowza.
Primero, se han desplegado las dos máquinas en el entorno virtualizado de VMWare:
Figura 74: Despliegue de las máquinas

virtuales. Wowza
El siguiente paso ha sido introducir las máquinas en dominio y asignarles una IP fija, como
se realizó en apartados anteriores. Las IPs asignadas han sido:
- TFG-WOWZA-1: 172.31.130.5
- TFG-WOWZA-2: 172.31.130.6
Una vez que ambas máquinas están metidas en dominio y configuradas a nivel de red, se
debe instalar el failover cluster manager de la misma forma que se realizó en el apartado de
bases de datos. El nombre del failover cluster así como la IP asignada han sido los
siguientes:
- TFG_WOWZA_CLUSTER: 172.31.130.30
Para poder usar Wowza, se debe disponer de cámaras para visualizar vídeo. Se han
seleccionado dos cámaras IP de la marca “Axis”, que estarán conectadas a la red.
79
Por último, el proceso para descargar e instalar el software de Wowza así como para tener
el servicio en funcionamiento en caso de failover, es el siguiente:
1 En cada uno de los nodos del clúster, instalar WowzaStreamingEngine-

4.7.5-windows-installer.exe, instalable que se podrá descargar en la página
oficial de Wowza, y seguir los pasos de instalación. Es importante recordar
el nombre de usuario y la contraseña asignados a la aplicación. Cuando se
solicite, desmarque la opción para iniciar el motor Wowza Streaming
automáticamente.
Figura 75: Icono de instalación de Wowza
Durante este proceso, el instalador solicitará una licencia(se puede solicitar

una licencia gratuita de un mes). La misma licencia se puede usar para
ambos nodos del clúster.
2 Abrir la aplicación “failover cluster” de Windows instalada anteriormente.

Configurar rol de tipo Servicio genérico para crear el rol de Wowza.
Seleccione Wowza Streaming Engine 4.7.5, asignando una dirección IP
virtual:
- Rol: TFG_WOWZA_SERVICE
- IP: 172.31.130.29
3 Seleccionar el rol en el Administrador del failover cluster y haga clic en

Agregar recurso / Servicio genérico y seleccionar el servicio Wowza
Streaming engine Manager 4.7.5. Terminar el proceso y observar como
ambos nodos están añadidos al clúster y el rol está activo:
Figura 76: Estado de los nodos del clúster
Figura 77: Comprobación del rol TFG_WOWZA_SERVICE
80
4 Ejecutar el rol creado en uno de los nodos y asegúrese de que ambos

servicios se estén ejecutando.
Figura 78: Servicios de Windows. Wowza
5 Abrir un navegador web y buscar la dirección (lo mismo que ejecutando la

aplicación): http: // [WOWZASERVERIP]:8088/enginemanager
Ejecutar los pasos de la introducción e iniciar sesión con las credenciales de

usuario contraseña utilizadas durante la instalación.
Figura 79: Configuración y usabilidad. Servidor Wowza
6 En “Aplications”, hacer clic en "live"
7 En “Sources” se ha seleccionado la opción “Axis”, ya que es la marca de

las cámaras que se van a usar en esta parte de la arquitectura.
8 Introducir nombre del stream así como las IP de las cámaras:
Ambas cámaras se encuentran ya instaladas en Alstom y conectadas a una

de las redes internas de Alstom:
- Nombre del stream 1:STR1.stream
- IP de la cámara 1:172.31.145.3
- Nombre del stream 2: STR2.stream
- IP de la cámara 2: 172.31.145.133
81
Figura 80: Configuración y usabilidad. Servidor Wowza (II)
9 En "Stream Files", aparecerán los dos streams creados:
Figura 81: Configuración y usabilidad. Servidor Wowza (III)
10 Por último, conectarse a ambos streams y luego ir al apartado “incoming

streams”, donde se puede apreciar que los streamings están activos y con
una URL disponible para acceder a ellas:
Figura 82: Configuración y usabilidad. Servidor Wowza (IV)
82
4.5 Telefonía
Con el servicio de telefonía se va a proporcionar al cliente una arquitectura robusta y

en alta disponibilidad con la cual podrá realizar llamadas entre los diferentes teléfonos de su
sistema. Para ello, se van a desplegar dos máquinas virtuales con sistema operativo Linux y
con distribución CentOs 7. En ambas máquinas se instalará y configurará el software
Asterisk, que proporciona servicios de central telefónica. Por último, se instalará la solución
“keepalived” que ofrece Linux en ambos nodos para garantizar alta disponibilidad en el
servicio de Asterisk, siguiendo el siguiente esquema:
Figura 83: Arquitectura de telefonía con la solución keepalived
83
El primer paso realizado ha sido el despliegue de dos máquinas virtuales a partir de dos
plantillas de CentOs 7:
Figura 84: Plantilla de centOs 7
Las dos máquinas virtuales, acorde a la nomenclatura y el dominio creado, dispondrán

de los siguientes nombres:
 TFG-AST-1
 TFG-AST-2
Figura 85: Despliegue de las

máquinas virtuales. Asterisk
Una vez que se tienen las dos máquinas desplegadas, el primer paso es meter en
dominio ambas máquinas. Para ello, al usar el sistema operativo Linux, se debe usar la
ventana de comandos. Para introducir una máquina Linux en dominio:
1 Asignarle una IP en la red, y cambiar el nombre del ordenador, para ello,

editar el fichero de hosts en: /etc/hosts
Figura 86: Configuración de red. Asterisk
Las dos IPs seleccionadas han sido:

- Para TFG-AST-1: 172.31.130.3
- Para TFG-AST-2: 172.31.130.4
2 Usando el comando “nmtui”, introducir la IP de la máquina, los servidores

de dominio, así como el nombre del mismo:
84
Figura 87: Configuración de red. Asterisk (II)
3 El “hostname” se puede cambiar usando el comando nmtui, o bien

aplicando el siguiente comando e introduciendo el dominio de la siguiente
forma:
Figura 88: Configuración de red. Asterisk (III)

4 E
ditar el fichero /etc/samba/smb.conf:
Figura 89: Configuración de red. Asterisk

(IV)
5 Reiniciar la máquina, y una vez reiniciada, introducir en el dominio a través

del comando “net ads join –U Administrator”:
85
Figura 90: Configuración de red. Asterisk (V)
Una vez que ambas máquinas están configuradas e introducidas en dominio, se

procede a instalar Asterisk. Para ello:
1 Instalación de los paquetes necesarios: Comando:

#sudo yum install -y epel-release dmidecode gcc-c++ ncurses-devel
libxml2-devel make wget openssl-devel newt-devel kernel-devel sqlite-
devel libuuid-devel gtk2-devel jansson-devel binutils-devel
2 Creación de un directorio temporal en root:

#cd /root/
# mkdir -p downloads/extract
3 Descargar el paquete de asterisk (en la página de Asterisk están todas las

versiones disponibles), se usará la versión 13.19.2:
4 Descomprimir el archivo descargado:
# tar -zxvf asterisk-13.19.2.tar.gz -C extract
5 Ir al directorio del archivo descomprimido y compilarlo y configurarlo:

# cd extract/asterisk-13.19.2
# ./configure && make clean && make && make install && make
samples && make config
Con Asterisk instalado, en /etc se encuentra una carpeta llamada “Asterisk” con los
archivos de configuración, los cuales habrá que modificar para nuestro sistema. Los
comandos más importantes a utilizar para la gestión de Asterisk son los siguientes:
- service asterisk start Comenzar el servicio de Asterisk

- service asterisk stop Parar el servicio de Asterisk
- service asterisk restart Reiniciar el servicio de Asterisk
- service asterisk status Ver el estado del servicio de Asterisk
- asterisk –rvvvv Acceder a la consola propia de Asterisk
- sip show peers Dentro de la consola de Asterisk, para ver los usuarios
registrados
Para poder establecer llamadas, en la carpeta de Asterisk, se han modificado los

archivos sip.conf y extensions.conf. En el sip.conf se han configurado las extensiones,
con un usuario y una contraseña, así como el contexto. Por ejemplo, para registrar la
86
extension 3001(el apartado general es común a todos los sip.conf), y así se haría con
las demás, añadiéndolas debajo:
[general]
udpbindaddr=0.0.0.0:5060
context=default
srvlookup=yes
allowguest=no
alwaysauthreject=yes
[3001]
type=friend
host=dynamic
username=3001
secret=1234
callerid="Iván" <3001>
context=extensiones-internas
canreinvite=no
En el archivo extensions.conf, se configura como va a ser el flujo de llamadas

(llamada entrante, establecimiento de llamada y colgar la llamada):
[general]
static=yes
writeprotect=yes
autofallthrough=yes
clearglobalvars=no
priorityjumping=no
[default]
; Recibe lo que no tiene un contexto propio definido.
; Rechaza todo por seguridad.
exten => _X.,1,Hangup(21)
exten => s,1,Hangup(21)
[extensiones-internas]
; Extensiones internas SIP
exten => _3XXX,1,NoOp(Llamada a terminal interno)
exten => _3XXX,2,Dial(SIP/${EXTEN})
exten => _3XXX,3,Hangup(16)
87
Una vez realizada la modificación de estos archivos, se ha reiniciado el servicio de

asterisk comprobando que se activa correctamente:
Figura 91: Servicio de Asterisk
La configuración de los archivos debe ser la misma en ambas máquinas. Para

garantizar alta disponibilidad, se va a instalar y configurar la solución de keepalived.
Keepalived es un framework de Linux que permite alta disponibilidad de servicios. Su
configuración es sencilla y trabaja utilizando el protocolo VRRP (Virtual Router
Redundancy Protocol). La instalación y configuración de la solución es la siguiente:
1. #yum install keepalived
2. Añadir la siguiente línea en /etc/sysctl.conf, permitiendo que los servicios

se unan a la IP virtual incluso cuando este servidor sea la máquina pasiva:
- net.ipv4.ip_nonlocal_bind = 1
3. Habilitar la línea añadida:

#sysctl –p
4. En /etc, estará añadida la carpeta /keepalived con su archivo de

configuración keepalived.conf. En este archivo se configura el servicio, y
las características más importantes a configurar son:
 Estado del nodo: Master o backup
 Interfaz de red
 Prioridad del nodo
 IP virtual que controlará el nodo activo
 Relación con diferentes scripts
La configuración realizada mantendrá los dos nodos en constante comunicación

mediante una relación master-backup. La IP virtual que tendrá el nodo activo es
172.31.130.2. Mediante dos scripts creados en el lenguaje bash (check_asterisk.sh y
status.sh), los dos nodos consultarán el estado del asterisk en los nodos y se
encargarán de iniciar el servicio cuando haya una transición, proporcionando que
88
Asterisk sólo este activo en el nodo que está trabajando con la IP virtual. (Archivos de
configuración en ANEXO 1)
4.6 Balanceador de carga
La utilidad de estos dispositivos radica en poder repartir la carga y excluir aquellas

conexiones de destino que se encuentren caídas en un momento determinado. De esta manera,
un cliente cuya dirección IP de su servidor DNS se encuentre caída, el balanceador de carga
detectará que esa dirección IP se encuentra inactiva (el servidor no escucha las peticiones ya
sea por fallo en hardware o en software del servidor) y las peticiones cuyo destino se dirigen
al servidor caído se redireccionarán a otro servidor DNS que haya conectado al dispositivo
encargado del balanceo de carga.
Los balanceadores de carga se utilizan en aquellos sistemas en los que la cantidad de

peticiones a los servidores es elevada, el rendimiento y la confiabilidad del sistema pueden
verse influenciados bien por la excesiva carga en uno de los servidores del sistema o bien por
el estado erróneo de uno de los servidores.
Para ello, el balanceador de carga permite incrementar la capacidad de procesamiento y la

confiabilidad, asegurando la disponibilidad, monitorizando el estado de las aplicaciones y
enviado las peticiones a los servidores que puedan responder.
Para configurar un balanceador de carga, se han desplegado dos máquinas virtuales con
sistema operativo Linux y distribución CentOs 7. En ellas, se va a proceder a la instalación de
un software llamado HAProxy. HAProxy actúa ofreciendo alta disponibilidad, balanceo de
carga y proxy para comunicaciones TCP y HTTP. Para garantizar alta disponibilidad en la
arquitectura, se configurarán ambos balanceadores en cluster activo/pasivo, de tal forma que,
si el balanceador de carga principal fallase, el segundo balanceador entraría en acción,
manteniendo los servicios disponibles.
Figura 92: Arquitectura propuesta para el balanceador de carga
89
Lo primero que se ha realizado en ambas máquinas virtuales es el cambio de nombre de

máquina e introducirlas en el dominio tfg.local con la misma metodología utilizada con el
servicio de telefonía (TFG-AST-1 y TFG-AST-2).
Los nombres asignados a ambas máquinas, así como las direcciones de red son las siguientes:
- Nombre: TFG-NLB-1 IP: 172.31.130.26
- Nombre: TFG-NLB-2 IP: 172.31.130.27
Una vez introducidas ambas máquinas en dominio, se procede a la instalación y

configuración del software HAProxy. Para ello, los pasos seguidos han sido los siguientes:
En ambos nodos:
1. Instalación de los paquetes necesarios:

# yum install pacemaker corosync haproxy pcs fence-agents-all ntp
2. Configución del servicio ntp con el directorio activo para que ambas
máquinas virtuales tengan la misma fecha y estén sincronizadas:
# vi/etc/ntp.conf
Añadidas al archivo las direcciones del directorio activo:

- server 172.31.130.15 iburst
- server 172.31.130.16 iburst
Figura 93: Instalación y configuración del HAProxy
3. Habilitación y activación del servicio ntp:
- # systemctl enable ntpd.service

- # systemctl start ntpd.service
Una vez hecho esto, se debe reiniciar la máquina, y después seguir los siguiente pasos:
90
1. Habilitación de firewall y deshabilitación de SELinux:

- # firewall-cmd --permanent --add-service=high-availability
- # firewall-cmd --zone=public --permanent --add-service=http
- #setenforce 0
- #setsebool -P haproxy_connect_any=1
2. Habilitación de puertos 8080 y 8320:

- # firewall-cmd --zone=public --permanent --add-port=8080/tcp
- # firewall-cmd --zone=public --permanent --add-port=8320/http
3. Ejecución de comandos para la creación y configuración del cluster:

- # passwd hacluster
- # systemctl enable pcsd.service pacemaker.service corosync.service
haproxy.service
- # systemctl start pcsd.service
- # pcs cluster auth tfg-nlb-1 tfg-nlb-2
- # pcs cluster setup --start --name http-cluster tfg-nlb-1 tfg-nlb-2
- # pcs cluster enable –all
4. Comprobación de la configuración:
- # corosync-cfgtool –s
- # corosync-cmapctl | grep members
Figura 94: Instalación y configuración del HAProxy (II)
- # pcs status corosync
Figura 95: Instalación y configuración del HAProxy (III) 91

5. Propiedades, verificación y recursos:

- # pcs property set stonith-enabled=false
- # pcs property set no-quorum-policy=ignore
- # crm_verify -L –V
6. Creación del recurso para la IP virtual (172.31.130.28) que gestionará el

cluster:
- # pcs resource create ClusterIP ocf:heartbeat:IPaddr2
ip=172.31.130.28 cidr_netmask=24 op monitor interval=5s
- # pcs resource create HAproxy systemd:haproxy op monitor
interval=5s
- # pcs constraint colocation add HAproxy HAproxyIPs INFINITY
- # pcs constraint order HAproxyIPs then HAproxy
7. Edición del fichero de configuración, en /etc/haproxy/haproxy.cfg.

(ANEXO-2)
Una vez terminada la instalación y configuración, se puede ver el estado del clúster, así como
la página de estadísticas del balanceador(configurada en el fichero haproxy.conf), que en el
apartado de pruebas servirá para analizar el funcionamiento y el reparto de peticiones entre
los servidores según el algoritmo configurado:
Estado del cluster: Comando #pcs status
Figura 96: Instalación y configuración del HAProxy (IV)
92
En el nodo activo: #service haproxy status:
Figura 97: Servicio de HAProxy
Para probar el balanceador de carga, se ha decidido utilizar los dos servidores de vídeo
Wowza instalados ya configurados. El objetivo de esta decisión es el de balancear peticiones
HTTP, no el balanceo de flujos de vídeo. Con el uso de estos dos servidores (que soportan
ambas servicios), se va a producir un ahorro de almacenamiento y un aprovechamiento de las
arquitecturas ya montadas. Es decir, los servidores de Wowza van a tener dos servicios
independientes:
1. Vídeo en vivo (ya implementado)

2. Servidores web balanceados por el HAProxy.
Para configurar ambos servidores como servidores web, el proceso es sencillo. En ambos
nodos:
1. En server manager, instalar el rol “Web Server (IIS)”

2. Una vez instalado, en “tools”, hacer click en la opción “Internet
Information Services(IIS) Manager”
93
Figura 98: Instalación y configuración. IIS
3. En esta interfaz, se puede observar el servidor web por defecto creado. En

el proyecto, se ha renombrado como “WebSite”
Figura 99: Instalación y configuración. IIS (II)
Por último, debemos habilitar el servidor para que escuche por el puerto configurado en el
balanceador de carga (Puerto 8320).
94
1. Para ello, en el margen derecho, haciendo click en “Bindings..”, editar y

establecer el puerto deseado:
Figura 100: Instalación y configuración. IIS (III)
Finalmente, se puede ver en la página de estadísticas,la configuración del balanceador con los
dos servidores Wowza. URL de la página de estaísticas:
http://172.31.130.28:8320/haproxy?stats
Figura 101: Estadísticas de balanceo. HAProxy
95
5. PRUEBAS, CONCLUSIONES Y POSIBLES MEJORAS
Después de la implementación de todas las arquitecturas que van a ofrecer los

diferentes servicios del sistema, se puede observar como en el directorio activo se
encuentran todas las máquinas, así como los roles y usuarios:
Figura 102: Seguridad en la arquitectura. Directorio activo
Con todo esto, aparte de unificar el sistema y aumentar la seguridad, se pueden crear
usuarios (como se realizó para las bases de datos) y darles permisos exclusivos.
Para probar el sistema, se hará uso de los cuatro servicios ofrecidos:
5.1. Bases de datos
Para probar el funcionamiento de las bases de datos, así como probar que el
servicio ofrece alta disponibilidad con la configuración realizada, se va a hacer uso de
la aplicación SQL Server Management Studio 2017. Los pasos para probar la
arquitectura son:
96
1. Ver estado del clúster y comprobar el nodo activo (nodo-1)
Figura 103: Control de acceso a las

máquinas de SQL
Accediendo remotamente a la máquina TFG-SQL-1 con el usuario de dominio

creado para las bases de datos, se puede ver el estado del clúster:
Figura 104: Estado del clúster de SQL
Figura 105: Estado del clúster de SQL (II)
El nodo-1 tiene los servicios activos y ambos nodos están activos en el sistema
2. En el nodo-1, abrir SQL Server Management Studio, entrar a la instancia

creada del clúster de SQL (TFG-SQL), y crear una base de datos.
97
Figura 106: Acceso a SQL Server Management Studio
Para crear una base de datos, crear una consulta sobre la instancia, y ejecutar el
siguiente comando:
Figura 107: Pruebas de SQL. SQL Server

Management Studio
Figura 108: Pruebas de SQL. SQL Server Management Studio

(II)
98
3. Crear una tabla en esa base de datos, y añadir información.

Para ello, se ha seleccionado la base de datos creada en la lista desplegable y se
ha creado una tabla (dbo.Clientes) con los campos de nombre, localización y
email:
Figura 109: Pruebas de SQL. SQL Server Management Studio (III)
Con la tabla ya creada, añadir información y consultar que se han añadido

correctamente:
Figura 110: Pruebas de SQL. SQL Server Management Studio (IV)
Figura 111: Pruebas de SQL. SQL Server Management Studio (V)
99
4. Una vez añadida, apagar la máquina activa, y acceder al nodo-2 (TFG-SQL-2

con IP:172.31.130.19):
5. Ver como se produce el failover y los roles cambian de nodo, así como la
notificación de que el nodo que estaba activo se ha caído
Figura 112: Pruebas de SQL
Figura 113: Pruebas de SQL (II)
1. El nodo que estaba descansando asume los roles.
Figura 114: Pruebas de SQL (III)
6. Abrir SQL Server Management Studio y entrar a la instancia del clúster de SQL.
100
7. Consultar que aparece la base de datos, así como la tabla creada y su

información en el nodo que ahora está apagado y ver como a pesar de
producirse una caída en el sistema, la información se ha guardado
correctamente
Figura 115: Comprobaciones y resultados. SQL
8. Volver a añadir información a la tabla, apagar el nodo 2, y encender de nuevo

el nodo 1, apreciando que el failover se vuelve a producir correctamente y no
se pierde información.
Figura 116: Comprobaciones y resultados. SQL (II)
101
Apagando nodo-2, y encendiendo nodo-1, se puede ver como se recuperan los

servicios en el nodo-1 y la base de datos, así como la tabla creada y
modificada, está accesible con los datos actualizados:
Figura 117: Comprobaciones y resultados. SQL (III)
Figura 118: Comprobaciones y resultados. SQL (IV)
Figura 119: Comprobaciones y resultados. SQL (V)
102
5.2.Vídeo en vivo
Para probar esta parte del sistema, se va a hacer uso de la aplicación VLC,
con la cual se accederá a las dos cámaras configuradas a través de la red usando la IP
virtual. La IP virtual estará conectada a uno de los dos servidores Wowza
configurados, y en el momento en el que el servidor que esté funcionando sufra un
bajón (bien por un apagón, o por un error inesperado), la IP virtual será cogida por el
nodo que estaba en modo de espera, gracias al clúster configurado. En el nuevo nodo
se iniciarán los servicios, y será ese el único tiempo que haya que esperar para poder
volver a ver las cámaras.
Los pasos para probar la arquitectura son:
1. En el nodo activo del cluster, ver el estado tanto de los nodos como de los
servicios de Wowza funcionando:
En TFG-WOWZA-1, con IP: 172.31.130.5, se puede ver como ambos

nodos están activos así como el servicio funcionando correctamente:
Figura 120: Pruebas de vídeo
2. Abrir VLC dos veces en una máquina de la red, y en medio/abrir ubicación

de red/, y abrir las cámaras usando las siguientes secuencias:
En el propio servidor de Wowza, las opciones vienen definidas en la página

principal:
103
Figura 121: Pruebas de vídeo (II)
Protocolo://[IP-CLUSTER]:[PUERTO]:[Aplicación-
Wowza]/NombreStream.stream
Para la cámara 1:
rtmp://172.31.130.30:1935/live/STR1.stream
Para la cámara 2:
rtmp://172.31.130.30:1935/live/STR2.stream
Figura 122: Pruebas de vídeo (III)
Se puede observar como a través de la IP virtual gestionada por el clúster

configurado actualmente nos proporciona los servicios de las cámaras
utilizando el nodo 1 (TFG-WOWZA-1). Para probar la arquitectura, se
apagará la máquina, y se verá cómo se produce el failover, así como la
recuperación del servicio.
104
3. Apagar la máquina TFG-WOWZA-1, acceder a la máquina TFG-

WOWZA-2(IP:172.31.130.6), y ver el estado del clúster:
Figura 123: Figura 124: Pruebas de vídeo (IV)
El nodo-1 está caído y el servicio ha sido asumido por el nodo-2. El

servicio de Wowza ha tardado en iniciarse en el nuevo nodo
aproximádamente dos minutos, momento en el cual, a través de la IP
virtual, pueden volver a verse las cámaras:
Figura 125: Figura 126: Pruebas de vídeo (V)
105
4. Por último, se puede observar como a través de una única cámara puedo ver
el vídeo en varias pantallas (flujo unicast-multicast):
Figura 127: Flujo de video en transmisión unicast-multicast
Es importante comentar, que aunque el tiempo de espera para que el nodo

secundario actúe cuando hay una caída sea de dos minutos, la alta
disponibilidad está garantizada. El clúster de Windows proporcionado por
Microsoft, garantiza alta disponibilidad [20].
5.3. Telefonía
Con la finalidad de probar la arquitectura propuesta para el servicio de

telefonía, se va a hacer uso de la aplicación Zoiper. Zoiper es un softphone gratuito
que permitirá registrar extensiones y realizar llamadas a través de las dos PBX
configuradas (TFG-AST-1 y TFG-AST-2).
Con Zoiper, y haciendo uso de la consola de Asterisk, se podrá analizar el estado de

los servicios (asterisk y keepalived, las extensiones registradas y el flujo de llamadas),
cuando se produzca una caída en el servicio de Asterisk.
106
Para probar la arquitectura:
1. En ambos nodos, ver que la IP virtual (172.31.130.2) se encuentra en el

nodo configurado como nodo máster, con el comando #ifconfig:
Figura 128: Pruebas de telefonía
2. Ver que el servicio de keepalived se encuentra activo en ambas máquinas:
Figura 129: Pruebas de telefonía (II)
3. Registro en dos aplicaciones Zoiper usando dos máquinas virtuales

diferentes de las cinco extensiones introducidas en sip.conf, usando la IP
virtual:
Figura 130: Pruebas de telefonía (IV)
107
Figura 132: Pruebas de telefonía (V)
Figura 131: Pruebas de telefonía (VI)
108
4. Comprobar que en Asterisk las extensiones han sido registradas. Para ello:
Figura 133: Pruebas de telefonía (VII)
5. Realizar una llamada y observar que se ejecuta correctamente, viendo el

flujo de la llamada en la consola de Asterisk:
Figura 134: Pruebas de telefonía. (VII)
109
Figura 135: Pruebas de telefonía. Establecimiento de llamada (VIII)
6. Parar el servicio de Asterisk en la máquina activa (TFG-AST-1). Se puede

apreciar como el nodo que estaba en espera adquiere la IP virtual al cabo de
un pequeño intervalo de tiempo (10-20 segundos) y enciende el servicio de
Asterisk, pudiendo volver a ejecutar llamadas:
Figura 136: Pruebas de telefonía (IX)
110
7. Es el mismo caso del paso 6, pero parando el servicio de keepalived. Se

puede apreciar como el nodo que estaba en espera adquiere la IP virtual
inmediatamente y enciende el servicio de Asterisk, pudiendo volver a
ejecutar llamadas:
Figura 137: Pruebas de telefonía (X)
Como conclusión, se ha podido apreciar como ante cualquier caída, ya sea del servicio
de asterisk como del servicio keepalived, la arquitectura es capaz de actuar en
consecuencia, y en un breve periodo de tiempo, apenas apreciable, volver a tener
disponible las llamadas entre los clientes
5.4. Balanceador de carga
Para probar el funcionamiento del balanceador de carga, así como su máxima

disponibilidad, se van a realizar peticiones HTTP a los servidores a través del
balanceador de carga. Para realizar las peticiones, se va a hacer uso de la aplicación
Postman, desde la cual se mandarán peticiones HTTP. En la página de estadísticas del
HAProxy, así como en los archivos de rastro de los servidores, se podrán ver esas
peticiones así como su distribución.
Se van a probar tres casos básicos de uso:
- Caso 1. Lanzamiento de peticiones, y observación de cómo el balanceador

distribuye las peticiones acorde al algoritmo configurado en el HAProxy
(Round Robin)
- Caso 2. Apagón del balanceador principal con la finalidad de observar el nodo
secundario coge las riendas del cluster y mantiene el mismo funcionamiento.
- Caso 3. Apagón de uno de los dos servidores para observar que todas las
peticiones son enviadas al nodo activo.
Para los tres casos, se va a trabajar enviando las peticiones a la IP virtual de los
balanceadores de carga (172.31.130.28). Es decir, ni se accederá a los servidores
directamente ni se accederá a un balanceador de carga en concreto.
111
El estado inicial de las peticiones entre los servidores se encuentra a 0, observando la

página de estadísticas configurada en el HAProxy:
Figura 138: Pruebas del balanceador de carga
CASO 1.
Con la aplicación Postman, se van a enviar siete peticiones HTTP del tipo POST al
balanceador de carga. Para ello , se ha configurado la aplicación utilizando la siguiente
dirección (protocolo, IP virtual, puerto, y servidor web) :
POST http://172.31.130.28:8320/WebSite
Una vez enviadas las siete peticiones, se puede observar en la página de estadísticas
del HAProxy, como el balanceador ha mandado cuatro peticiones al servidor 1, y tres
peticiones al servidor 2, balanceando las peticiones acorde al algoritmo que se había
programado:
Observar en Tfg_heartbeatSessions—>Total
Figura 139: Pruebas del balanceador de carga (II)
Para ver las peticiones enviadas en los servidores, hay que ir al archivo de “logs”, que se
encuentra en : C:\inetpub\logs\LogFiles\W3SVC1
112
En TFG-WOWZA-1, se pueden observar las cuatro peticiones POST recibidas por el

balanceador de carga:
Figura 140: Pruebas del balanceador de carga (III)
En TFG-WOWZA-2, se pueden observar las tres restantes:
Figura 141: Pruebas del balanceador de carga (IV)
Como detalle, observando las horas exactas, se puede ver como el balanceador ha repartido
una petición a cada servidor en orden de llegada.
CASO 2.
Una vez apagado el balanceador que estaba activo, se puede observar como el balanceador
que estaba como back up ha cogido la IP virtual del cluster y ha encendido su servicio
haproxy:
113
Figura 142: Pruebas del balanceador de carga (IV)
Figura 143: Pruebas del balanceador de carga (V)
Ahora, la página de estadísticas, al iniciarse de nuevo el servicio, ha vuelto a 0, y se pueden

volver a mandar las peticiones:
114
Figura 144: Pruebas del balanceador de carga (VI)
Se procede a mandar 5 peticiones HTTP a través de postman, observando como se comporta

de la misma forma que en el caso 1:
Figura 145: Pruebas del balanceador de carga (VII)
En TFG-WOWZA-1, se pueden observar las tres peticiones POST recibidas por el

balanceador de carga en las últimas peticiones enviadas. Están incluidas las peticiones del
caso 1, pero observando las horas de las peticiones, se pueden destacar con claridad las tres
peticiones de este caso:
Figura 146: Pruebas del balanceador de carga (VIII)
En TFG-WOWZA-2, el mismo caso, pero con 2 peticiones:
Figura 147: Pruebas del balanceador de carga (IX)
115
Por último, el CASO 3:
Al apagar el servidor TFG-WOWZA-2, se puede apreciar en la página de estadísticas del

HAProxy que ese servidor no está disponible:
Figura 148: Pruebas del balanceador de carga (X)
Figura 149: Pruebas del balanceador de carga (XII)
116
Por lo tanto, y para acabar el último caso, se procede a enviar cuatro peticiones al balanceador
de carga. Las cuatro peticiones, han sido enviadas por el balanceador al único servidor activo,
como se puede comprobar tanto en la página de estadísticas del HAProxy, como en el los
archivos “log” del servidor TFG-WOWZA-1:
Figura 150: Pruebas del balanceador de carga (XII)
Figura 151: Pruebas del balanceador de carga (XIII)
En los tres casos, el cluster de balanceadores HAProxy ha funcionado correctamente,

balanceando las peticiones a los servidores según el algoritmo configurado, y estando
disponible a pesar de falla en el balanceador activo.
Cuando uno de los servidores no ha estado disponible, el balanceador ha funcionado de una

manera correcta percatándose de ello y actuando en consecuencia, mandando las peticiones al
único servidor activo. Por lo tanto, como conclusión, la arquitectura diseñada con los
balanceadores de carga en cluster cumple con los objetivosde máxima disponibilidad en la
arquitectura propuesta
117
5.5. Conclusiones del sistema y posibles mejoras
El sistema se ha diseñado para ofrecer cuatro servicios con cuatro soluciones

distintas de alta disponibilidad: servicio de bases de datos, servicio de vídeo en vivo,
servicio de telefonía y balanceo de carga entre servidores web.
Como se ha podido comprobar, la información introducida en las base de datos,

gracias a la implementación de un clúster de Windows activo-pasivo con acceso a una
SAN que también se encuentra en redundancia a través de un failover clúster de SQL,
cuando se produce una caída y recuperación en uno de los nodos del clúster de
diferentes maneras, la información introducida no se pierde y se mantiene disponible.
Usando esta arquitectura, se asegura y se amplia la capacidad de la base de datos para
cumplir con los parámetros que componen ACID (Atomicity, Consistency, Isolation,
Durability), a través de los cuales se consigue:
- Tener transacciones completas

- Mantener la integridad de la base de datos
- Procesos independientes sobre distintas operaciones, evitando interferencias.
- El sistema será persistente en las operaciones, las cuales no se podrán deshacer
ante un fallo en el sistema, protegiendo la información.
Respecto al balanceo de carga, a través de la implementación de un balanceador de

carga software HAProxy en clúster, se ha apreciado como las peticiones que llegan al
balanceador de carga las re-direcciona a los diferentes servidores configurados
trabajando con el algoritmo implementado (Round Robin). Cuando el balanceador
activo sufre una caída, el balanceador que se encuentra en espera pasa a gestionar las
peticiones automáticamente, manteniendo la funcionalidad de la arquitectura y la
disponibilidad del sistema.
Para el servicio de telefonía, a través de un servicio de monitorización y alta

disponibilidad que ofrece Linux (Keepalived), se ha demostrado que siempre va a
haber un servidor de Asterisk funcionando, se caiga un nodo u otro, proporcionando la
capacidad necesaria en todo momento para poder realizar llamadas. Esto se ha
demostrado en los dos casos posibles:
- Se cae el servicio de Asterisk: Como keepalived se encuentra

monitorizando el servicio de asterisk cada un cierto tiempo configurabe (10
segundos en el proyecto, configurables en keepalived.conf), en cuanto se
da cuenta (monitorizando el servicio de asterisk como caído dos veces
seguidas) se comunica con el nodo configurado como backup y arranca el
servicio de asterisk. El máximo tiempo que puede tardar en dar esta orden
sería de 20 segundos, si el servicio de Asterisk dejase de funcionar justo
después de que keepalived haya cumplido una de sus infinitas rondas de
monitorización.
118
- Se cae el servicio de keepalived: En este caso, como keepalived mantiene

la comunicación entre nodos a través de la IP virtual, el otro nodo se da
cuenta automáticamente, adquiriendo la IP virtual y arrancando su servicio
de asterisk. Este failover es gestionado por la arquitectura de forma
inmediata.
Respecto al servicio de vídeo en vivo, tras la configuración de dos servidores de vídeo

de la marca Wowza, así como la integración de ellos con dos cámaras Axis y la
implementación de un cluster de Windows activo-pasivo, se ha podido comprobar que
el flujo de vídeo se ofrece a través de una IP virtual conectada a uno de los dos
servidores de vídeo. En el momento en el que ese servidor deje de funcionar, el cluster
actúa y en poco tiempo (apenas dos minutos), los servicios son iniciados en el nodo
que estaba en espera y se vuelve a tener disponible las imágenes de vídeo. Aunque
haya que esperar dos minutos cuando se produce un failover, el clúster de Windows
garantiza alta disponibilidad, por lo que el requisito está cumplido. Por último, se ha
podido reproducir un flujo de vídeo en varias pantallas a la vez, añadiendo la
capacidad al sistema de reproducir flujos de vídeo en transmisión unicast-multicast.
Se ha analizado cómo los servicios por separado cumplen los requisitos indispensables
para garantizar alta disponibilidad, pero como sistema, y para garantizar el objetivo del
proyecto, se ha podido apreciar como opciones de redundancia sin clúster serían
difícilmente viables tanto a nivel de trabajo como de mantenimiento.
La arquitectura ofrece un amplio abanico de servicios y una vía para garantizar la

disponibilidad propuesta en cada uno de ellos. Considero que esta arquitectura es
escalable, pudiendo agregar nuevos servicios al sistema y pudiendo actualizar la
arquitectura según vaya avanzando la tecnología. Aparte, es un sistema
multiplataforma, pudiendo acceder a los servicios a través de otros sistemas operativos
como por ejemplo Linux .(Zoiper, VLC..son programas que admiten su ejecución
desde otros sistemas operativos). Por otro lado, la virtualización de la infraestructura
facilita mucho la implementación el sistema. Ahora mismo, podría borrar todo mi
entorno virtual, y después de todo el estudio y el trabajo dedicado, sabiendo como se
instalan y configuran todas las máquinas, así como los servicios, no tardaría apenas
una semana en volver a tener todo el proyecto disponible.
Como posibles mejoras, los tiempos de failover son mejorables en ciertas técnicas,
como en el clúster de Windows a pesar de que Microsoft te garantice alta
disponibilidad. Aunque dos minutos sea poco tiempo, en un sistema de seguridad dos
minutos sin ver una cámara puede significar mucho. Por otro lado, se podría crear una
aplicación que gestionase todos estos servicios, con una interfaz de usuario en la que
hubiese un mapa del lugar, los dispositivos estuviesen geolocalizados (cámaras,
teléfonos…etc), y el usuario pudiese seleccionar y hacer acciones con ellos, algo
mucho más profesional. Finalmente, duplicar la arquitectura en un centro de respaldo
en otro punto de la ciudad sería totalmente obligatorio si se hiciese un sistema de este
nivel.
119
CENTRO CENTRO
PRINCIPAL BACKUP CLIENTE-1 CLIENTE-2 CLIENTE-3 CLIENTE-4
CLIENTE-1 CLIENTE-2 CLIENTE-3 CLIENTE-4
DIRECTORIO DIRECTORIO
ACTIVO 1 ACTIVO3
BALANCEADOR DE BALANCEADOR DE
CARGA CARGA
DIRECTORIO DIRECTORIO
ACTIVO 2 ACTIVO 4
NODO_1 NODO_2 NODO_3 NODO_4
SAN SAN
Memoria compartida Memoria compartida
DB DB
RED
REPLICACIÓN
ASÍNCRONA
REPLICACIÓN
SÍNCRONA
Figura 152. Centro de respaldo
Este proyecto de fin de carrera abarca mucha temática y muy variada, y se puede
seguir la línea de investigación por muchísimos caminos. Como opinión personal,
considero que lo más importante de la arquitectura es el diseño, y se ha comprobado
que los cuatro servicios ofrecidos, a través de cuatro métodos diferentes, toleran los
todos los posibles fallos y mantienen el servicio con tiempos de recuperación muy
pequeños. Además, todas las arquitecturas que forman el sistema se encuentran
integradas a través de un directorio activo que regula el acceso y los permisos a los
usuarios, a gusto del cliente.
120
6. MANUAL DE USUARIO PARA LOS PROGRAMAS UTILIZADOS.
6.1. SQL Server Management Studio 2017
Es un entorno integrado que permite todo tipo de acciones con las bases de datos,
desde la administración hasta la configuración y desarrollo de todos sus componentes. Es
una herramienta única que combina herramientas gráficas accesibles para el usuario con
funciones de scripting.
En este proyecto se ha utilizado la última versión disponible (Microsoft SQL Server

Management Studio 2017) y el uso dado ha sido simple y práctico: la inserción de una
tabla en base de datos para comprobar la alta disponibilidad de la arquitectura en este
parte del sistema.
Figura 153: Icono de aplicación. Microsoft SQL

Management Studio 17
La interfaz de usuario, una vez abierta la aplicación, es la siguiente:
Figura 154: Manual de usuario. Microsoft SQL Server Management Studio 17
En esta pantalla introductoria se procede a la conexión con el servidor de bases de datos

conocido con un usuario y una contraseña creados. Una vez conectado al sevidor de bases
de datos, la interfaz es la siguiente:
121
Figura 155: Figura 156: Manual de usuario. Microsoft SQL Server Management Studio 17 (II)
En esta interfaz, podrás realizar muchas operaciones, algunas de ellas son:

- Crear bases de datos
- Políticas de seguridad
- Creación de plantillas personalizadas
- Control de código fuente integrado para proyectos de script
El uso de esta interfaz es muy amplio, y para el proyecto se ha utilizado la creación de

una base de datos, de una tabla, y la inserción de datos en ella. SQL tiene sus propias
sentencias a la hora de ejecutar comandos, un propio lenguaje, y se divide en dos
categorías:
 Lenguaje de definición de datos (DDL)-> Se utilizan para la creación y

modificación estructuras de tablas así como diferentes objetos de las bases de
datos. Los comandos más habituales son : “Create”, “alter”, “drop” y
“truncate”.
 Lenguaje de manipulación de datos (DML)-> Sirve para modificar datos, y
los comandos más habituales son: “select”, “insert”, “update” y “delete”.
Para la creación de bases de datos, tablas y modificación de ellas, se deberá realiza una
solicitud en el apartado de la interfaz “New Query” y escribir el código deseado:
122
Una vez escrito el código, pulsar la opción “Execute”, tras lo cual los comandos
escritos serán ejecutado
Figura 157: Manual de usuario. Microsoft SQL Server Management Studio 17 (III)
6.2.Postman
Postman es una aplicación multiplaforma (tiene aplicación para diferentes

sistemas operativos: Windows, Linux…) que permite realizar peticiones HTTP (GET,
POST, DELETE, UPDATE…) a una dirección de interés. Se pueden modificar
diferentes parámetros de la petición y es una aplicación de interés para testear los
desarrollos de los programadores y para interactuar con aplicaciones web.
Figura 158: Logo de la marca Postman.
123
Una vez abierta la aplicación la interfaz de usuario es la siguiente:
Figura 159: Manual de usuario. Postman
En el margen izquierdo, la aplicación proporciona muchas peticiones ya

configuradas para únicamente establecer los valores de la petición (IP del servidor,
nombre de la aplicación Web…etc). Si el usuario lo desea, puede configurar su propia
petición personalizada.
Para usar la aplicación, utizar un tipo de petición, y rellenar los campos deseados
(autorización si fuese requerida, cabecera, cuerpo del mensaje, prerrequisitos y test).
Por ejemplo, para una petición POST:
La nomenclatura utilizada ha sido http://[IP-SERVIDOR]:[PUERTO]:[Servicio Web].

Una vez escrita la petición, únicamente hay que darle al botón “send”. En caso de
algún error, la aplicación le informará de ello. Los campos a rellenar variarán
dependiendo del tipo de petición.
6.3.P
u
t
t
y
Figura 160: Manual de usuario. Postman (II)
124
6.3.Putty
Putty es un software gratuito y de cógido abierto que permite la conexión como cliente
SSH (Secure Shell) a los diferentes servidores. Dispone de más funcionaliddes no
relevantes para el uso dado en el proyecto. En resumen, con Putty se consigue la
apertura de una sesión de línea de comandos en el servidor remoto.
Tras ejecutar Putty se muestra el apartado de sesión con las opciones básicas:
Figura 161: Manual de usuario. Putty
Una vez en la sesión, introducir la IP o hostname del servidor a conectar, el

puerto (normalmente a través de SSH es 22 por defecto) y seleccionar como tipo de
conexión a través de SSH. Una vez completados los datos, darle click a “Open”. y se
conectará por remoto al servidor.
6.4.Zoiper
Zoiper es un softphone multiplataforma (funciona para ordenadores con

Windows, Linux o MAC OS…), y diseñado para trabajar con sistemas de
comunicación IP. Su uso es muy sencillo y tiene una versión gratuita, en la que se
dispone de las siguientes funciones:
- Hacer o recibir hasta 2 llamadas simultáneas
- Poner llamadas en espera
- Transferencias de llamadas.
Una vez instalado, para registrar un teléfono, se debe seleccionar la opción “créate
account”, y seleccionar protocolo SIP:
125
Figura 162: Manual de usuario. Zoiper
Después, escribir la extensión que se desea registrar, seguido de @IPSERVIDOR, así

como de la contraseña establecida en los archivos de configuración de Asterisk:
Figura 163: Manual de usuario. Zoiper (II)
La extensión aparecerá registrada haciendo click en “next”. Para realizar una llamada, escribir
la extensión a la que se desea llamar desde el menú principal, y hacer click en “call”.
126
Figura 164: Manual de usuario. Zoiper (III)
6.5.VLC media player
VLC media player es un reproductor multimedia, libre y de código abierto.

Opera en multiplataforma pudiendo hacer uso de él en sistemas operativos tales como
Windows, GNU/Linux o Mac OS X, entre otros. Una de las características principales
que otorga VLC es la transmisión de vídeo o audio a través de internet,
proporcionándonos un canal propio.
Ese ha sido el principal uso en este proyecto, y para ello, una vez instalado:
Figura 165: Manual de usuario. VLC
Su uso es simple: para abrir el vídeo en streaming, en medio-abrir ubicación de red, se

debe escribir la dirección de red del streaming de vídeo (por ejemplo, en el proyecto:
rtmp://172.31.130.5:1935/live/STR1.stream). Hacer click en reproducir, y el streaming
del vídeo, aparecerá al instante.
127
7. PRESUPUESTO Y MATERIALES (HW Y SW)
PRESUPUESTO
NUME PRECIO POR
MANU RO UNIDAD
PRECIO
FACTU MODELO PROVEEDOR
TOTAL
RA UNIDA
D
HP Proliant
10.400,00 €
Servidor HP DL380p G9 2 5.200,00 € HP Direct
MS Windows
Server 2016
Licencia Microsoft STANDARD 2 Avnet 1300 €
64bits 650,00 €
SQL Server
Standard 1.300,00 € 2600,00 €
Licencia Microsoft 2 Avnet
SERVIDOR
Edition 2017
VMWare
Licencia VSphere 5.5 1 939,50 € VMWare 939,50 €
Client
Wowza
Licencia gratuita
Licencia Streamin 4.7.5 1 Wowza N/A
de prueba (1
g Engine
mes)
Asterisk Licencia gratuita

Licencia Asterisk 1 Asterisk N/A
13.19.2
SERVIDOR NAS
Servidor
HP HP MSA 2040 44.580,00 €
NAS 1 44.580€ HP
BALANCEADOR DE
Balancea HAProxy
CARGA
HAProxy
dor de 1.5.18 2 Licenca gratuita HAProxy N/A
carga
128
Microsoft
Microsoft Windows 10 Microsoft 135,00 €
Licencia 1
Pro 64Bits 135€
PC Notebook
Portátil de HP EliteBook
HP 1 HP 1024,00 €
escritorio 745 G4 1024,00 €
ESTACIÓN DE TRABAJO
Pantalla Dell P2213 1 118,40 € Dell 118,40 €
Teclado y Premier-
Dell 1 Dell 46,62 €
ratón KM717 46,62 €
Cable de RJ45 de 3
Bechtle 4 5,85 € Bechtle 23,40 €
red metros
Cámarad
AXIS M3114-R 2 185,00 € Amazon 370,00 €
e vídeo
PRECIO
61536, 92€
TOTAL
129
8. BIBLIOGRAFÍA
[1] CAT COLOMBIA SOLUTIONS. La evolución de los sistemas de seguridad electronica.

[Online]. Disponible en: http://catcolombiasolutions.com/index.php/actualidad/76-la-
evolucion-de-los-sistemas-de-seguridad-electronica
[2] REDHAT. ¿Qué es la virtualización? [Online]. Disponible en:

https://www.redhat.com/es/topics/virtualization/what-is-virtualization
[3] IBM. Disponibilidad: Visión general de la alta disponibilidad. IBM i Versión 7 Release 3,
2016
[4] IBM. Disponibilidad: Implementación de la alta disponibilidad. IBM i Versión 7 Release

3, 2016
[5] SANTOS, Jesús Costas. Seguridad y alta disponibilidad. RA-MA Editorial, 2014.
[6] LISTA, Jose Luis. (2017, July 18). Sistemas RAID. [Online]. Disponible en:
https://cibergizmoinformatica.com/2017/07/17/sistemas-raid/
[7] LAVILA, Jordi Ferrando (2016, December 1). Comparativa SAN vs. NAS. [Online].
Dispone en: http://www.infordisa.com/es/comparativa-san-vs-nas/
[8] HUIDOBRO, José Manuel. Telecomunicaciones: tecnologías, redes y servicios. RA-MA

Editorial, 2014.
[9] ORDENADOR Y PORTÁTILES. ¿Qué es el directorio activo de Windows? [Online].

Disponible en:: http://www.ordenadores-y-portatiles.com/directorio-activo.html
[10] VARLOTOP. (2017, November 15). ¿Qué es un proxy o servidor proxy? [Online].
Disponible en: http://www.valortop.com/blog/servidor-proxy
[11] TOLOSA, G. (2014) Protocolos y Modelo OSI. Disponible en http://www.tyr.unlu.edu.

ar/TYR-publica/02-Protocolosy-OSI
[12] YANZA, Willian (2017, October 27). Sistemas operativos. [Online]. Disponible en:
https://issuu.com/willianyanza/docs/1.5_sistemas_operativos_actuales
[13] ESPINOZA, Andry. (2017, July 20). Sobre el lenguaje y funcionamiento de los
servidores. [Online]. Disponible en: http://info.netcommerce.mx/blog/lenguaje-
funcionamiento-los-servidores/
[14] CCM. Introducción a las bases de datos [Online]. Disponible en:
https://es.ccm.net/contents/66-introduccion-a-las-bases-de-datos
130
[15] ALCÁNTARA, Martín. (2017, September 201). Lo que toda empresa necesita saber
sobre la Telefonía IP.[Online]. Disponible en: https://www.3cx.es/blog/informacion-sobre-
telefonia-ip/
[16] 3CX. ¿Qué es un Central Telefónica PBX? [Online]. Disponible en:

https://www.3cx.es/voip-sip/central-telefonica-pbx/
[17] LÓPEZ, Ana. (2018, January 30) Como funciona una centralita telefónica. [Online].
Disponible en: https://www.fonvirtual.com/blog/como-funciona-una-centralita-telefonica/
[18] PROSEGUR (2017, August 22). ¿Cuántos tipos de detectores de alarma existen?
[Online]. Disponible en: https://blog.prosegur.es/tipos-detectores-de-alarma/
[19] LOWE, Scott. MARSHALL, Nick. Mastering VMware vSphere 5.5. John Wiley & Sons.
[20] MICROSOFT (2018, May 5) Failover Clustering in Windows Server. [Online].

Disponible en: https://docs.microsoft.com/en-us/windows-server/failover-clustering/failover-
clustering-overview
131
9. ANEXO-1
Keepalived.conf en TFG-AST-1
global_defs {
! notification_email {
! voip@example.com
! failover@example.com
! sysadmin@example.com
! }
! notification_email_from server.asterisk@example.com
! smtp_server xxx.yyy.zzz.aaa
! smtp_connect_timeout 30
! router_id LVS_DEVEL
}
vrrp_script check_asterisk {
script "/etc/keepalived/check_asterisk.sh"
interval 10
fall 2 # number of fails before consider is failure
rise 1 # number of ok before consider is ok
timeout 5
}
vrrp_instance VI_TFG {
state MASTER
! state BACKUP
interface ens32
virtual_router_id 51
nopreempt
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123
}
virtual_ipaddress {
172.31.130.2/24 dev ens32 label ens32:1
}
track_script {
check_asterisk
}
132
notify_master "/etc/keepalived/status.sh MASTER"

notify_backup "/etc/keepalived/status.sh BACKUP"
notify_fault "/etc/keepalived/status.sh FAULT"
}
Keepalived.conf en TFG-AST-2
global_defs {
! notification_email {
! voip@example.com
! failover@example.com
! sysadmin@example.com
! }
! notification_email_from server.asterisk@example.com
! smtp_server xxx.yyy.zzz.aaa
! smtp_connect_timeout 30
! router_id LVS_DEVEL
}
vrrp_script check_asterisk {
script "/etc/keepalived/check_asterisk.sh"
interval 10
fall 2 # number of fails before consider is failure
rise 1 # number of ok before consider is ok
timeout 5
}
vrrp_instance VI_TFG {
! state MASTER
state BACKUP
interface ens32
virtual_router_id 51
nopreempt
priority 50
advert_int 1
authentication {
auth_type PASS
auth_pass 123
}
virtual_ipaddress {
172.31.130.2/24 dev ens32 label ens32:1
}
133
track_script {
check_asterisk
}
notify_master "/etc/keepalived/status.sh MASTER"

notify_backup "/etc/keepalived/status.sh BACKUP"
notify_fault "/etc/keepalived/status.sh FAULT"
}
Script check_asterisk.sh
#!/bin/bash
CHECKFILE="/tmp/ASTERISK_STATUS"
echo "check asterisk" >> $CHECKFILE
if [ -e /tmp/MASTER ]
then
# check asterisk is up
service asterisk status | grep running > /dev/NULL
if [ $? -eq 0 ]; then
echo "asterisk running" > $CHECKFILE

exit 0
else
echo "asterisk stopped" > $CHECKFILE
exit 1
fi
else
echo "not master" > $CHECKFILE
exit 0
fi
Script status.sh
#!/bin/bash
STATE=$1
NOW=$(date +"%D %T")

KEEPALIVED="/tmp"
case $STATE in
"MASTER")
rm $KEEPALIVED/BACKUP
rm $KEEPALIVED/FAULT
touch $KEEPALIVED/MASTER
134
service asterisk start || service asterisk restart

exit 0
;;
"BACKUP")
rm $KEEPALIVED/MASTER
rm $KEEPALIVED/FAULT
touch $KEEPALIVED/BACKUP
service asterisk stop
exit 0
;;
"FAULT")
rm $KEEPALIVED/MASTER
rm $KEEPALIVED/BACKUP
touch $KEEPALIVED/FAULT
service asterisk stop
exit 0
;;
Esac
135
10. ANEXO 2- Haproxy.cfg
#---------------------------------------------------------------------
# Example configuration for a possible web application. See the
# full configuration options online.
#
# http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
#
#---------------------------------------------------------------------
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
# to have these messages end up in /var/log/haproxy.log you will
# need to:
#
# 1) configure syslog to accept network log events. This is done
# by adding the '-r' option to the SYSLOGD_OPTIONS in
# /etc/sysconfig/syslog
#
# 2) configure local2 events to go to the /var/log/haproxy.log
# file. A line like the following can be added to
# /etc/sysconfig/syslog
#
# local2.* /var/log/haproxy.log
#
log 127.0.0.1 local2
#log 10.0.1.70:514 local0
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 2048
tune.ssl.default-dh-param 2048
user haproxy
group haproxy
daemon
# turn on stats unix socket

stats socket /var/lib/haproxy/stats
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
136
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
stats enable
stats uri /haproxy?stats
stats realm Haproxy\ Statistics
stats auth admin:admin
#---------------------------------------------------------------------
# main frontend
#---------------------------------------------------------------------
frontend tfg_front_heartbeat
bind 172.31.130.28:8320
reqadd X-Forwarded-Proto:\ http
default_backend tfg_heartbeat
#---------------------------------------------------------------------
# least connection balancing between the various backends
#---------------------------------------------------------------------
backend tfg_heartbeat
balance roundrobin
server tfg-wowza-1 172.31.130.5:8320 weight 1 check port 8320 inter 2000 rise 2 fall
5
server tfg-wowza-2 172.31.130.6:8320 weight 1 check port 8320 inter 2000 rise 2 fall
5
137

TFG Ruben Arguelles Dominguez

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Ruben Arguelles Dominguez

Cargado por

Copyright:

Formatos disponibles

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y

PROYECTO FIN DE GRADO

TÍTULO: Diseño e implementación de un sistema de seguridad en alta

AUTOR: Rubén Argüelles Domínguez

TITULACIÓN: Sistemas de Telecomunicaciones

DIRECTOR: Álvaro Arribas Del Val

TUTOR: Francisco Javier Ortega González

DEPARTAMENTO: Teoría de la Señal y Comunicaciones (TSC)

Miembros del Tribunal Calificador:

PRESIDENTE: Salvador Sánchez Hernández

TUTOR: Francisco Javier Ortega González

SECRETARIO: José Manuel Pardo

El presente trabajo se basa en el estudio, diseño e implementación de un sistema de seguridad

Para la implementación se hará uso de la herramienta VMWare vSphere Client, a través de la

- Servicio de almacenamiento de datos Utilizando un “failover cluster” de SQL

Tras el diseño y la implementación, se realizarán pruebas en las que se pondrá a prueba el

- Data storage service Using a SQL failover cluster

2 MARCO TECNOLÓGICO DEL PROYECTO .......................................................... 15

2.2 Alta disponibilidad.................................................................................................... 16

3 Redes y servicios ............................................................................................................. 29

3.3 Tecnología hardware y software ........................................................................... 40

4 DISEÑO Y DESCRIPCIÓN DEL PROYECTO ......................................................... 49

5 IMPLEMENTACIÓN DEL PROYECTO ................................................................... 52

6 PRUEBAS, CONCLUSIONES Y POSIBLES MEJORAS ....................................... 96

7 GUÍA DE USUARIO PARA LOS PROGRAMAS UTILIZADOS ........................ 121

8 PRESUPUESTO Y MATERIALES (HW Y SW) .................................................... 128

Figura 1: Redundancia de dispostivos hardware ....................................................... 19

Figura 48: Configuración del clúster .......................................................................... 68

Figura 98: Instalación y configuración. IIS ................................................................. 94

Figura 150: Pruebas del balanceador de carga (XII) ............................................... 117

Tabla 1: Diferencias NAS y SAN ...................................................................... 24

NVR Network Video Recorder

1.1 Descripción del proyecto

Atendiendo al afán de crear nuevas soluciones tecnológicas en el sector de la

En definitiva, este proyecto se basa en el desarrollo de un nuevo producto revolucionario

El sistema realizado proporciona las siguientes ventajas clave:

- Uso eficiente de los recursos: A través de arquitecturas robustas y modelos

1.2 Entorno y contextualización

Actualmente, tanto durante el transporte de personas, de bienes, o en lugares con

La seguridad y la ciberseguridad son una de las principales preocupaciones de la sociedad

Actualmente se aspira a fusionar los distintos sistemas de recolección de información

El objetivo principal del presente proyecto es diseñar un novedoso sistema e

Los servicios del sistema deben funcionar en alta disponibilidad, soportados en

2 MARCO TECNOLÓGICO DEL PROYECTO

2.1 Historia y evolución de los sistemas de seguridad.

En el año 1942 la empresa Siemens AG desarrolló un primer sistema de vigilancia: un circuito

En 1996 se desarrolló la primera cámara IP (Internet Protocol), la Neyete 200, gracias a la

La virtualización es una tecnología que permite crear servicios de IT (Information

El desarrollo de las tecnologías que posibilitan la virtualización ha permitido que muchos

2.2 Alta disponibilidad

2.2.1 Definición de alta disponibilidad

La alta disponibilidad describe la capacidad de un sistema para seguir funcionando y

El nivel de disponibilidad se expresa como medida del porcentaje de tiempo que un

Donde MTTF el tiempo transcurrido para fallar y MTTR es el tiempo promedio

Se suele representar como un porcentaje tiempo/año que lleva prestando servicio

• 99,9% (tres nueves) => 8,76 horas/año inactivo.

2.2.2 Características de un modelo de alta disponibilidad

Para determinar si la alta disponibilidad es imprescindible en el sistema, debe

Las principales características de un modelo de alta disponibilidad son:

- Fiabilidad: Se trata del aspecto más crítico. Los componentes deben

- Recuperación ante fallos: Estos sistemas tienen varias opciones de

- Detección de errores: Una vez se produzca un fallo, la rápida

- Mantenimiento: Los componentes deben estar lo suficientemente