facultad de ingeniería eléctrica y electrónica - ESCUELA ...

ESCUELA POLITÉCNICA NACIONAL

FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA

ANÁLISIS E IMPLEMENTACIÓN DE UN PROTOTIPO DE SERVIDOR VIRTUALIZADO SOBRE UNA DISTRIBUCIÓN DE

LINUX PARA EL USO EN PyMES

PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN ELECTRÓNICA Y REDES DE INFORMACIÓN

BONILLA SUÁREZ JORGE JAVIER jjbs8@hotmail.com

CARRASCO AGUILAR DANIEL SANTIAGO danielserver86@hotmail.com

DIRECTOR: ING. FERNANDO FLORES. fflore@mailfie.epn.edu.ec

Quito, Febrero 2010

DECLARACIÓN

Nosotros, Jorge Javier Bonilla Suárez y Daniel Santiago Carrasco Aguilar,

declaramos que el trabajo aquí descrito es de nuestra autoría; que no ha sido

previamente presentado para ningún grado o calificación profesional; y, que hemos

consultado las referencias bibliográficas que se incluyen en este documento.

La Escuela Politécnica Nacional, puede hacer uso de los derechos correspondientes

a este trabajo, según lo establecido por la Ley de Propiedad Intelectual, por su

Reglamento y por la normatividad institucional vigente.

Jorge Javier Bonilla Suárez Daniel Santiago Carrasco Aguilar

CERTIFICACIÓN

Certifico que el presente trabajo fue desarrollado por Jorge Javier Bonilla Suárez y

Daniel Santiago Carrasco Aguilar, bajo mi supervisión.

Ing. Williams Fernando Flores Cifuentes

Director del Proyecto

AGRADECIMIENTO

A Dios Todopoderoso, por darme una vida llena de Bendiciones…

A mi madre Tatyana y a mi padre Felipe por haberme dado el más grande regalo: la

A mi abuelita Sonia, ejemplo de amor y trabajo, por ser la persona que me da la

fuerza que me mueve cada día para ser mejor…

A mi abuelito Jorge, quien ha estado siempre presente para darme su cariño,

confianza y apoyo incondicional.

A mi hermana Andrea por ser esa persona que ha estado conmigo todos los días de

mi carrera universitaria dándome sus muy sabios consejos.

A mi tío Lenin por ser quien, con su experiencia y cariño, me ha sabido guiar por el

camino profesional.

A mi mamita Michita, papito Segundo y mami Zoila que desde el cielo estarán

guiándome…

A toda mi gran familia, ejemplo de unidad, tesón, y amor…

Daniel.

A Dios por todas las bendiciones que me ha brindado durante mi vida.

A mi madre María Antonieta por todo el amor, apoyo y amistad que me brinda día a

A mi abuelito Eugenio por los conocimientos y experiencia que comparte conmigo.

A mi tía Imelda por su amabilidad y comprensión.

A toda mi familia: Jorge, Cecilia, Santiago y Verónica, Manuel, María Elena, María

Augusta, Alex y Ximena por todo su cariño y apoyo.

A todos mis amigos por siempre estar conmigo.

Finalmente un agradecimiento muy especial al Ingeniero Fernando Flores, por

brindarnos sus consejos y enseñanzas y de esta forma hacer posible el presente

trabajo.

Jorge.

DEDICATORIA

Para la persona más importante de mi vida: mi Mamy Taty, ejemplo de mujer; a quien

le debo todo y por quién lucharé sin cansancio todos los días de mi vida…

Daniel.

El presente trabajo está dedicado a toda mi familia, en especial a mi Madre; por todo

el amor y dedicación que me brindan en cada momento y por siempre creer en mí.

Jorge.

CONTENIDO

CONTENIDO ............................................................................................................................................... I ÍNDICE DE FIGURAS ............................................................................................................................. VIII ÍNDICE DE TABLAS ................................................................................................................................ XII ÍNDICE DE ESPACIOS DE CÓDIGO ................................................................................................... XIV RESUMEN ............................................................................................................................................... XVI PRESENTACIÓN .................................................................................................................................. XVIII

CAPÍTULO UNO ........................................................................................................................................... 1

1. DESCRIPCIÓN GENERAL DE LA VIRTUALIZACIÓN (ARQUITECTURA SERVIDOR VIRTUALIZADO) Y LAS HERRAMIENTAS TECNOLÓGICAS PARA SU IMPLEMENTACIÓN. .................................................................. 1

1.1. FUNDAMENTOS GENERALES DE LA VIRTUALIZACIÓN .................................................................... 2 1.1.1. ANTECEDENTES .......................................................................................................................... 2 1.1.2. FUNDAMENTACIÓN ................................................................................................................... 3 1.1.3. ANTECEDENTES HISTÓRICOS DE LA VIRTUALIZACIÓN ............................................................... 5

1.1.3.1. Explosión de La Virtualización de 1990´S y 2000`S .................................................. 6 1.1.3.2. Virtualización y el Hardware x86 .............................................................................. 7

1.2. CONCEPTO .................................................................................................................................... 11 1.3. TIPOS DE VIRTUALIZACIÓN ........................................................................................................... 12

1.3.1. VIRTUALIZACIÓN DE RECURSOS .............................................................................................. 13 1.3.1.1. Virtualización de Almacenamiento ........................................................................ 13

1.3.1.1.1. Virtualización basada en el Dispositivo .................................................................. 14 1.3.1.1.2. Virtualización basada en la Red ............................................................................. 14 1.3.1.1.3. Virtualización basada en el Host ............................................................................ 15

1.3.1.2. Virtualización de Redes .......................................................................................... 15 1.3.1.2.1. Virtual LAN (VLAN) ................................................................................................. 15 1.3.1.2.2. Virtual IP (VIP) ........................................................................................................ 16 1.3.1.2.3. Virtual Private Network (VPN) ............................................................................... 16

1.3.2. VIRTUALIZACIÓN DE PLATAFORMA ......................................................................................... 16 1.3.2.1. Virtualización de Aplicaciones ................................................................................ 18 1.3.2.2. Virtualización de Escritorio .................................................................................... 18 1.3.2.3. Virtualización de Equipos y Servidores .................................................................. 19

1.3.2.3.1. Arquitectura general .............................................................................................. 19 1.3.2.3.2. Virtual Machine (VM) o Máquina Virtual ............................................................... 22 1.3.2.3.3. Hypervisor o Virtual Machine Monitor (VMM) ...................................................... 22 1.3.2.3.4. Sistema Operativo Anfitrión (Host OS) ................................................................... 23 1.3.2.3.5. Sistema Operativo Visitante (Guest OS) ................................................................. 23 1.3.2.3.6. Hardware Real o físico ........................................................................................... 23 1.3.2.3.7. Alternativas de Virtualización de Servidores (1) (2) ............................................... 24 1.3.2.3.8. Virtualización de Sistema Operativo ...................................................................... 24 1.3.2.3.9. Virtualización Completa ......................................................................................... 25 1.3.2.3.10. Paravirtualización ................................................................................................... 26 1.3.2.3.11. Virtualización Nativa o Virtualización Híbrida ........................................................ 27

1.4. VIRTUALIZACIÓN DE SERVIDORES: VIRTUALIZACIÓN COMPLETA, PARAVIRTUALIZACIÓN Y

VIRTUALIZACIÓN HÍBRIDA .......................................................................................................................... 28 1.4.1. VIRTUALIZACIÓN COMPLETA ................................................................................................... 28

1.4.1.1. Características ........................................................................................................ 29 1.4.1.1.1. Hypervisor .............................................................................................................. 29 1.4.1.1.2. Kernel de las Máquinas Virtuales ........................................................................... 29 1.4.1.1.3. Simulación Completa de todo el Hardware anfitrión ............................................. 30

1.4.1.2. Arquitectura ........................................................................................................... 30 1.4.2. PARAVIRTUALIZACIÓN ............................................................................................................. 32

1.4.2.1. Características ........................................................................................................ 32 1.4.2.1.1. Modificación del Guest OS ..................................................................................... 33 1.4.2.1.2. Seguridad ............................................................................................................... 33 1.4.2.1.3. Hypervisor .............................................................................................................. 34 1.4.2.1.4. Hypervisors de distintas plataformas ..................................................................... 34

1.4.2.2. Arquitectura ........................................................................................................... 35 1.4.3. VIRTUALIZACIÓN HÍBRIDA ....................................................................................................... 36

1.4.3.1. Características ........................................................................................................ 36 1.4.3.2. Hardware Especializado ......................................................................................... 36 1.4.3.3. Arquitectura ........................................................................................................... 37

1.5. OPCIONES DE SOFTWARE PARA VIRTUALIZACIÓN ....................................................................... 38 1.5.1. SOFTWARE DE VIRTUALIZACIÓN MÁS USADO......................................................................... 38

1.5.1.1. VMware®................................................................................................................ 39 1.5.1.1.1. Virtualización de sistemas x86 ............................................................................... 40 1.5.1.1.2. Arquitectura ........................................................................................................... 41 1.5.1.1.3. Productos ............................................................................................................... 41

1.5.1.2. Microsoft® (4) (5) ................................................................................................... 44 1.5.1.2.1. Características ........................................................................................................ 45 1.5.1.2.2. Arquitectura ........................................................................................................... 46

1.5.1.3. Xen® Hypervisor (6) ................................................................................................ 47 1.5.1.3.1. Características ........................................................................................................ 48 1.5.1.3.2. Arquitectura ........................................................................................................... 49

1.5.2. OTRAS OPCIONES DE SOFTWARE DE VIRTUALIZACIÓN ........................................................... 51 1.5.2.1. KVM®...................................................................................................................... 51 1.5.2.2. Microsoft Virtual PC® ............................................................................................. 52

1.5.2.2.1. Windows Virtual PC................................................................................................ 53 1.5.2.2.2. Sistemas Operativos Soportados ........................................................................... 54 1.5.2.2.3. Sistemas Operativos Linux como Huésped ............................................................ 55

CAPÍTULO DOS .......................................................................................................................................... 56

2. ANÁLISIS DE LOS REQUERIMIENTOS TECNOLÓGICOS DE LAS PYMES Y LA APLICABILIDAD DE LA ARQUITECTURA SERVIDOR VIRTUALIZADO PARA FACILITAR SU OPERACIÓN. .......................................... 56

2.1. FUNDAMENTOS GENERALES DE LAS PYMES ................................................................................. 57 2.2. CONCEPTO (7) (8) (9) .................................................................................................................... 59 2.3. SITUACIÓN ACTUAL DE LAS TIC´S EN LAS PYMES ECUATORIANAS ................................................ 62

2.3.1. ESTADÍSTICAS DE LAS TIC´s EN LAS PyMES ECUATORIANAS .................................................... 64 2.3.2. SOLUCIONES Y REQUERIMIENTOS TECNOLÓGICOS ACTUALES PARA LAS PyMES ECUATORIANAS (10) (11) ....................................................................................................................... 67 2.3.3. ANÁLISIS DE REQUERIMIENTOS DE LAS PyMES PARA LA CONSTITUCIÓN DEL CENTRO DE DATOS 72

2.3.3.1. Internet .................................................................................................................. 75 2.3.2.1.1. Correo electrónico ................................................................................................. 78 2.3.2.1.2. Comercio electrónico ............................................................................................. 80 2.3.2.1.3. Páginas web ........................................................................................................... 81

2.3.3.2. Intranet .................................................................................................................. 83 2.3.2.2.1. DHCP ...................................................................................................................... 84 2.3.2.2.2. DNS ........................................................................................................................ 85 2.3.2.2.3. Proxy ...................................................................................................................... 87 2.3.2.2.4. Directorio ............................................................................................................... 88 2.3.2.2.5. Firewall ................................................................................................................... 89 2.3.2.2.6. Telefonía ip ............................................................................................................ 90

2.3.3.3. Otros Servicios (10) ................................................................................................ 92 2.3.2.3.1. Mensajería instantánea ......................................................................................... 92 2.3.2.3.2. Seguridad Informática ............................................................................................ 92 2.3.2.3.3. Software de Gestión Organizacional ...................................................................... 93

2.4. APLICABILIDAD DE LA ARQUITECTURA SERVIDOR VIRTUALIZADO PARA FACILITAR LA OPERACIÓN

DE LAS PYMES .............................................................................................................................................. 94 2.4.1. IMPACTO DE LA ARQUITECTURA SERVIDOR VIRTUALIZACIÓN EN LAS PyMES ........................ 95

2.4.1.1. Ventajas y aplicaciones brindadas por los servidores virtualizados para las PyMES 95

2.4.1.1.1. Centralización, Descentralización, Consolidación .................................................. 95 2.4.1.1.2. Confiabilidad y Disponibilidad .............................................................................. 101 2.4.1.1.3. Escalabilidad......................................................................................................... 102 2.4.1.1.4. Seguridad ............................................................................................................. 103

2.4.1.2. Desventajas de la virtualización de servidores ..................................................... 104 2.4.1.2.1. Fallos de hardware ............................................................................................... 104 2.4.1.2.2. Congestión en varios dispositivos ........................................................................ 104

2.4.1.3. Comentario sobre la adopción de la arquitectura servidor virtualizado en las PyMES 104

CAPÍTULO TRES ....................................................................................................................................... 106

3. INSTALACIÓN, CONFIGURACIÓN, Y PRUEBAS DE XEN® HYPERVISOR COMO BASE EN LA IMPLEMENTACIÓN DE SERVIDORES VIRTUALES. ..................................................................................... 106

3.1. DISEÑO DE UN PROTOTIPO DE SERVIDOR VIRTUALIZADO PARA PYMES ..................................... 107 3.1.1. DISEÑO DE UN CENTRO DE DATOS PARA PyMES (13) ........................................................... 108

3.1.1.1. Consideraciones de Seguridad, Disponibilidad y Confiabilidad ............................ 109 3.1.1.1.1. Seguridad ............................................................................................................. 109 3.1.1.1.2. Disponibilidad ...................................................................................................... 110 3.1.1.1.3. Confiabilidad ........................................................................................................ 111

3.1.1.2. Prototipo del Centro de Datos para las PyMES .................................................... 111 3.1.2. ELECCIÓN DE LA SOLUCIÓN DE VIRTUALIZACIÓN ADECUADA PARA EL DISEÑO ................... 114 3.1.3. ANÁLISIS DE LOS TIPOS Y HERRAMIENTAS DE VIRTUALIZACIÓN DE SERVIDORES ................. 114 3.1.4. ANÁLISIS COMPARATIVO: VIRTUALIZACIÓN COMPLETA VS. PARAVIRTUALIZACIÓN VS. VIRTUALIZACIÓN HÍBRIDA .................................................................................................................... 115

3.1.4.1. Ventajas y Desventajas de la Virtualización Completa ......................................... 115 3.1.4.2. Ventajas y Desventajas de la Paravirtualización (3) ............................................. 116 3.1.4.3. Ventajas y Desventajas de la Virtualización Híbrida............................................. 117 3.1.4.4. Cuadro comparativo de los tipos principales de virtualización de servidores ..... 120

3.1.5. ANÁLISIS COMPARATIVO ENTRE LAS HERRAMIENTAS DE VIRTUALIZACIÓN ......................... 121 3.1.5.1. Cuadro comparativo de los tipos principales de virtualización de servidores ..... 122

3.1.6. CONCLUSIÓN SOBRE LA ELECCIÓN DE LA SOLUCIÓN DE VIRTUALIZACIÓN ........................... 126 3.2. XEN ............................................................................................................................................. 128

3.2.1. INTRODUCCIÓN ..................................................................................................................... 128 3.2.1.1. Problemas de la Virtualización en x86 ................................................................. 131

3.2.2. ARQUITECTURA ..................................................................................................................... 131 3.2.3. IMPLEMENTACIÓN DE LA ARQUITECTURA SERVIDOR VIRTUALIZADO CON LA HERRAMIENTA XEN 136

3.2.3.1. Instalación ............................................................................................................ 138 3.2.3.1.1. Requerimientos para la instalación ...................................................................... 138 3.2.3.1.2. Instalación ............................................................................................................ 139

3.2.3.2. Configuración del GRUB ....................................................................................... 143 3.2.3.3. Configuración y creación de Máquinas virtuales ................................................. 143

3.2.3.3.1. Archivo de configuración de dominio .................................................................. 144 3.2.3.3.2. Configuración de la Red ....................................................................................... 146 3.2.3.3.3. Configuración utilizada ........................................................................................ 151 3.2.3.3.4. Configuración de Dispositivos de Almacenamiento ............................................. 153 3.2.3.3.5. Comandos de XEN ................................................................................................ 156

3.2.3.4. Migración de Máquinas Virtuales ........................................................................ 158 3.2.3.5. Configuración de VM´s para Unmodified OS ....................................................... 159 3.2.3.6. Pruebas ................................................................................................................ 161

CAPÍTULO CUATRO ................................................................................................................................. 164

4. INSTALACIÓN, CONFIGURACIÓN, Y PRUEBAS DE LOS SERVICIOS NECESARIOS PARA SATISFACER LAS NECESIDADES TECNOLÓGICAS GENÉRICAS DE LAS PYMES. ..................................................................... 164

4.1. CUADRO DE SERVICIOS PARA PYMES .......................................................................................... 165 4.2. ESQUEMA DE SOLUCIÓN DE SERVIDOR VIRTUALIZADO PARA EL DATACENTER ......................... 166

4.2.1. ESQUEMA DE DIRECCIONAMIENTO DEL DATACENTER ......................................................... 168 4.2.2. INSTALACIÓN DEL SERVIDOR VIRTUAL BASE ......................................................................... 172

4.2.2.1. Consideraciones de instalación de la VM ............................................................. 172 4.2.2.2. Asignación de Disco Duro ..................................................................................... 172 4.2.2.3. Instalación sin el uso de herramientas adicionales .............................................. 173 4.2.2.4. Instalación con la herramienta virt-install............................................................ 175

4.3. INSTALACIÓN Y CONFIGURACIÓN DEL DATACENTER DE INFRAESTRUCTURA ............................ 180 4.3.1. SERVIDORES DE RUTEO: ROUTER INTRANET, FIREWALL PROXY Y ROUTER INTERNET ......... 181

4.3.1.1. Software ............................................................................................................... 181 4.3.1.1.1. Alternativas de software ...................................................................................... 182 4.3.1.1.2. Selección alternativa ............................................................................................ 182

4.3.1.2. Instalación ............................................................................................................ 183 4.3.1.2.1. Instalación Máquina Virtual ................................................................................. 183 4.3.1.2.2. Instalación Servicio .............................................................................................. 183

4.3.1.3. Configuración ....................................................................................................... 185 4.3.1.3.1. Router Intranet .................................................................................................... 185 4.3.1.3.2. Firewallproxy ........................................................................................................ 187

4.3.2. SERVIDOR DNS ....................................................................................................................... 189 4.3.2.1. Software ............................................................................................................... 189

4.3.2.1.1. Alternativas de software ...................................................................................... 190 4.3.2.1.2. Selección alternativa ............................................................................................ 190

4.3.2.3. Configuración ....................................................................................................... 191 4.3.2.3.1. Dnsiprimario ........................................................................................................ 192 4.3.2.3.2. Dnsisecundario ..................................................................................................... 196

4.3.3. SERVIDOR DHCP ..................................................................................................................... 198 4.3.3.1. Software ............................................................................................................... 198

4.3.3.2. Instalación ............................................................................................................ 200 4.3.3.2.1. Instalación Máquina Virtual y Servicio ................................................................. 200

4.3.3.3. Configuración ....................................................................................................... 201 4.3.3.3.1. Archivo de configuración dhcpd.conf .................................................................. 201 4.3.3.3.2. Configuración dhcrelay ........................................................................................ 202

4.3.4. SERVIDOR DE CORREO ELECTRÓNICO.................................................................................... 203 4.3.4.1. Software ............................................................................................................... 204

4.3.4.3. Configuración ....................................................................................................... 207 4.3.4.3.1. Mailempresarial ................................................................................................... 207

4.3.5. SERVIDOR DE DIRECTORIO ..................................................................................................... 210 4.3.5.1. Software ............................................................................................................... 211

4.3.5.3. Configuración ....................................................................................................... 213 4.3.5.3.1. Archivo de configuración ..................................................................................... 213

4.4. INSTALACIÓN Y CONFIGURACIÓN DEL DATACENTER DE DATOS................................................. 214 4.4.1. SERVIDOR DE BASE DE DATOS ............................................................................................... 215

4.4.2. SERVIDOR DE ARCHIVOS ........................................................................................................ 219 4.4.2.1. Software ............................................................................................................... 219

4.4.2.1.1. Alternativas de software ...................................................................................... 219

4.4.2.1.2. Selección alternativa ............................................................................................ 220 4.4.2.2. Instalación ............................................................................................................ 220

4.4.2.2.1. Instalación Máquina Virtual ................................................................................. 220 4.4.2.2.2. Instalación Servicio .............................................................................................. 221

4.4.3. SERVIDOR WEB EMPRESARIAL............................................................................................... 225 4.4.3.1. Software ............................................................................................................... 226

4.4.4. SERVIDOR FTP ........................................................................................................................ 231 4.4.4.1. Software ............................................................................................................... 232

4.4.4.3. Configuración ....................................................................................................... 234 4.4.4.3.1. Archivo de configuración vsftpd.conf .................................................................. 234

4.4.5. SERVIDOR DE IMPRESIÓN ...................................................................................................... 236 4.4.5.1. Software ............................................................................................................... 237

4.5. INSTALACIÓN Y CONFIGURACIÓN DE LA DMZ ............................................................................ 240 4.5.1. SERVIDOR WEB INTERNET ..................................................................................................... 241

4.5.1.1. Software ............................................................................................................... 242 4.5.1.2. Configuración ....................................................................................................... 242

4.5.1.2.1. Archivo de configuración ..................................................................................... 243 4.5.2. SERVIDOR DE COMERCIO ELECTRÓNICO ............................................................................... 247

4.5.2.3. Configuración ....................................................................................................... 249 4.5.3. SERVIDOR DE CORREO ELECTRÓNICO (MAIL GATEWAY)....................................................... 256

4.5.3.1. Software ............................................................................................................... 257 4.5.3.2. Configuración ....................................................................................................... 257

4.5.3.2.1. Archivo de configuración ..................................................................................... 257 4.5.4. SERVIDOR DNS (EXTERNO – DMZ) ......................................................................................... 261

4.5.4.3. Configuración ....................................................................................................... 262 4.5.4.3.1. Archivo de configuración ..................................................................................... 262 4.5.4.3.2. Dnseprimario ....................................................................................................... 262 4.5.4.3.3. Dnsesecundario.................................................................................................... 265

4.5.5. SERVIDORES PROXY, FIREWALL ............................................................................................. 266 4.5.5.1. Software ............................................................................................................... 266

4.5.5.3. Configuración ....................................................................................................... 268 4.5.5.3.1. Servidor firewallinternet ...................................................................................... 268

4.6. PRUEBAS DE LOS SERVICIOS ....................................................................................................... 272 4.6.1. ROUTERINTRANET ................................................................................................................. 273 4.6.2. FIREWALLPROXY .................................................................................................................... 274 4.6.3. DNS INTRANET ....................................................................................................................... 275 4.6.4. DHCP ...................................................................................................................................... 276 4.6.5. CORREO ELECTRÓNICO .......................................................................................................... 276 4.6.6. BASE DE DATOS...................................................................................................................... 278 4.6.7. SERVIDOR DE ARCHIVOS ........................................................................................................ 279 4.6.8. SERVIDOR DE DIRECTORIO ..................................................................................................... 281 4.6.9. SERVIDORES WEB .................................................................................................................. 281 4.6.10. FTP .................................................................................................................................... 283 4.6.11. IMPRESIÓN ........................................................................................................................ 284 4.6.12. COMERCIO ELECTRÓNICO ................................................................................................. 285 4.6.13. DNS DMZ ........................................................................................................................... 285 4.6.14. FIREWALL INTERNET ......................................................................................................... 286

CAPÍTULO CINCO..................................................................................................................................... 287

5. ACONDICIONAMIENTO DE LOS SERVIDORES Y REQUERIMIENTOS DE HARDWARE PARA UN ÓPTIMO FUNCIONAMIENTO. ................................................................................................................................ 287

5.1. INTRODUCCIÓN .......................................................................................................................... 288 5.2. DIMENSIONAMIENTO DE LOS SERVIDORES VIRTUALES (15) (16) (17) ........................................ 288

5.2.1. CORREO ELECTRÓNICO .......................................................................................................... 289 5.2.2. BASE DE DATOS...................................................................................................................... 290 5.2.3. SERVIDOR DE ARCHIVOS ........................................................................................................ 291 5.2.4. FTP ......................................................................................................................................... 292 5.2.5. WEB ....................................................................................................................................... 292 5.2.6. COMERCIO ELECTRÓNICO ...................................................................................................... 292 5.2.7. DNS ........................................................................................................................................ 293 5.2.8. DHCP ...................................................................................................................................... 293 5.2.9. SERVIDORES DE ENRUTAMIENTO Y FIREWALL ...................................................................... 294

5.2.9.1. FirewallProxy ........................................................................................................ 294 5.2.9.2. RouterIntranet ..................................................................................................... 295 5.2.9.3. FirewallInternet.................................................................................................... 295

5.2.10. IMPRESIÓN ........................................................................................................................ 296 5.2.11. DIRECTORIO ...................................................................................................................... 297 5.2.12. RESUMEN DE LAS CARACTERÍSTICAS DE LOS SERVIDORES VIRTUALES............................. 298

5.3. DIMENSIONAMIENTO DEL SERVIDOR FÍSICO .............................................................................. 300 5.3.1. PROCESADOR ......................................................................................................................... 300 5.3.2. MEMORIA .............................................................................................................................. 303 5.3.3. DISCO DURO .......................................................................................................................... 305 5.3.4. DISPOSITIVOS DE CONECTIVIDAD .......................................................................................... 307 5.3.5. MAINBOARD .......................................................................................................................... 309 5.3.6. IMÁGENES DEL PROTOTIPO DE SERVIDOR VIRTUALIZADO ARMADO ................................... 313

5.4. CÁLCULO DEL ENLACE AL ISP ...................................................................................................... 318 5.4.1. ACCESO A CORREO ELECTRÓNICO .................................................................................................... 318 5.4.2. DESCARGA DE ARCHIVOS ................................................................................................................. 319 5.4.3. ENLACE VPN ..................................................................................................................................... 320 5.4.4. ENLACE AL ISP ................................................................................................................................... 320

CAPÍTULO SEIS ........................................................................................................................................ 321

6. PRESUPUESTO DE LA IMPLEMENTACIÓN PROPUESTA ................................................................... 321

6.1. PRESENTACIÓN DE COSTOS DEL PROTOTIPO DE VIRTUALIZACIÓN ............................................ 322 6.1.1. COSTO DE HARDWARE FÍSICO ............................................................................................... 323 6.1.2. COSTO DE SOFTWARE ............................................................................................................ 323 6.1.3. PRESUPUESTO TOTAL ............................................................................................................ 324

CAPÍTULO SIETE ...................................................................................................................................... 326

7. CONCLUSIONES Y RECOMENDACIONES ......................................................................................... 326

7.1. CONCLUSIONES .......................................................................................................................... 327 7.2. RECOMENDACIONES .................................................................................................................. 332

CAPÍTULO OCHO ..................................................................................................................................... 334

8. ANEXOS ......................................................................................................................................... 334

ANEXO A.................................................................................................................................................... 335 TECNOLOGÍA DE PROCESADORES INTEL® VT Y AMD®-V ........................................................................... 335 ANEXO B .................................................................................................................................................... 341 ESTADO DE LAS TIC´S EN ECUADOR........................................................................................................... 341 ANEXO C .................................................................................................................................................... 343 FORMULARIO DE ENCUESTA PARA LA DETERMINACIÓN DE LAS TIC´S EN LA EMPRESA ........................... 343 ANEXO D ................................................................................................................................................... 349 ERP DE SOFTWARE LIBRE .......................................................................................................................... 349 ANEXO E .................................................................................................................................................... 353 LA VIRTUALIZACIÓN PASO POR PASO – RECOMENDACIONES DE HEWLETT PACKARD ............................. 353 IDENTIFICACIÓN DE LOS CANDIDATOS PARA VIRTUALIZACIÓN RECOMENDACIONES MICROSOFT Y XEN 355 ANEXO F .................................................................................................................................................... 358 CONFIGURACIÓN TWO WAY ROUTED DEL PROTOTIPO ............................................................................ 358 ANEXO G ................................................................................................................................................... 363 INSTALACIÓN DE MAILSCANNER Y CLAMAV ............................................................................................. 363 ANEXO H ................................................................................................................................................... 366 INSTALACIÓN Y CONFIGURACIÓN DE SQUIRRELMAIL ............................................................................... 366 ANEXO I ..................................................................................................................................................... 370 SERVIDORES ADICIONALES ....................................................................................................................... 370 TELEFONÍA IP – MENSAJERÍA INSTANTÁNEA ............................................................................................ 370

Software .......................................................................................................................................................... 371 Alternativas de software .......................................................................................................................... 371

Instalación....................................................................................................................................................... 372 Instalación Máquina Virtual ..................................................................................................................... 372 Instalación Servicio .................................................................................................................................. 372

Configuración ................................................................................................................................................. 373 Archivo de configuración ......................................................................................................................... 373

Fichero /etc/asterisk/sip.conf. ...................................................................................................................... 373 Fichero /etc/asterisk/extensions.conf. ........................................................................................................ 375

Configuración de cliente Ekiga........................................................................................................ 376 ANEXO J..................................................................................................................................................... 379 COSTOS DE LA IMPLEMENTACIÓN ............................................................................................................ 379 ANEXO K .................................................................................................................................................... 385 CÓDIGO DE IMPLEMENTACIÓN DE LOS SERVICIOS ................................................................................... 385

REFERENCIAS .......................................................................................................................................... 387

9. REFERENCIAS BIBLIOGRÁFICAS ...................................................................................................... 387

ÍNDICE DE FIGURAS

FIGURA 1.1 SERVIDORES DE VARIAS MARCAS DE LA ACTUALIDAD. FUENTE: BOMBAYHARBOR.COM .............. 7 FIGURA 1.2 LÍNEA DE TIEMPO EN EL DESARROLLO DE LA VIRTUALIZACIÓN EN EL HARDWARE X86.

FUENTE: FOCUS CONSULTING ................................................................................................................ 9 FIGURA 1.3 REPRESENTACIÓN DE LA VIRTUALIZACIÓN EN LA QUE SE ENCUENTRAN MUCHAS MÁQUINAS EN

UN SOLO COMPUTADOR. ........................................................................................................................ 11 FIGURA 1.4 ARQUITECTURA DE LA VIRTUALIZACIÓN ...................................................................................... 12 FIGURA 1.5 CONSTITUCIÓN BÁSICA DE UN COMPUTADOR TÍPICO. FUENTE: AUERBACH, ADVANCED SERVER

VIRTUALIZATION. .................................................................................................................................... 20 FIGURA 1.6 ARQUITECTURA 1 DE UNA PLATAFORMA VIRTUALIZADA. FUENTE: AUERBACH. ADVANCED.

SERVER VIRTUALIZATION. ..................................................................................................................... 21 FIGURA 1.7 ARQUITECTURA 2 DE UNA PLATAFORMA VIRTUALIZADA. FUENTE: AUERBACH, ADVANCED

SERVER VIRTUALIZATION. ..................................................................................................................... 21 FIGURA 1.8 ARQUITECTURA DE LA VIRTUALIZACIÓN COMPLETA. ................................................................... 31 FIGURA 1.9 INFRAESTRUCTURA VIRTUAL COMPLETA. ................................................................................... 31 FIGURA 1.10 VIRTUALIZACIÓN COMPLETA CONTRA ARQUITECTURA DE PARAVIRTUALIZACIÓN. EN AMBOS

CASOS, EXISTE UNA CAPA DE SOFTWARE DENOMINADA MONITOR DEL EQUIPO VIRTUAL (VMM), QUE

INCLUYE UN PLANIFICADOR DE EQUIPO VIRTUAL Y OFRECE GESTIÓN GENERAL DE MEMORIA Y

VIRTUALIZACIÓN DE ENTRADA Y SALIDA. EL MODELO DE PARAVIRTUALIZACIÓN INCLUYE INTERFACES

API QUE ASISTEN AL EQUIPO VIRTUAL EN ALGUNOS CASOS. FUENTE: VIRTUALIZACIÓN EN EL CENTRO

DE DATOS, INFORME TÉCNICO, NOVELL INC. ©, PÁG. 4. ..................................................................... 35 FIGURA 1.11 ARQUITECTURA DE LA VIRTUALIZACIÓN HÍBRIDA. .................................................................... 37 FIGURA 1.12 SOFTWARE DE VIRTUALIZACIÓN MÁS USADO............................................................................ 38 FIGURA 1.13 LOGO DE VMWARE. ................................................................................................................... 39 FIGURA 1.14 ARQUITECTURA EMPLEADA POR VMWARE ESX, LA CAPA DE VIRTUALIZACIÓN NO CORRE

SOBRE UN SISTEMA OPERATIVO ............................................................................................................ 43 FIGURA 1.15 LOGOTIPO DE WINDOWS SERVER® 2008 HYPER-V™. FUENTE: WWW.MICROSOFT.COM ..... 44 FIGURA 1.16 ARQUITECTURA DE WINDOWS SERVER® 2008 HYPER-V™. FUENTE: UNDERSTANDING

MICROSOFT VIRTUALIZATION SOLUTION, PÁG. 29. MICROSOFT CORPORATION ©, 2009. ................ 46 FIGURA 1.17 LOGOTIPO DEL HYPERVISOR XEN®. FUENTE: WWW.XEN.ORG ................................................ 47 FIGURA 1.18 ARQUITECTURA BÁSICA DE XEN®. FUENTE: XEN AND THE ART OF VIRTUALIZATION. PAUL

BARHAM, BORIS DRAGOVIC, KEIR FRASER, STEVEN HAND, TIM HARRIS, ALEX HO, ROLF

NEUGEBAUERY, IAN PRATT, ANDREW WARELD, UNIVERSITY OF CAMBRIDGE COMPUTER

LABORATORY. PÁG. 5. ........................................................................................................................... 49 FIGURA 1.19 LOGO DE KVM. ......................................................................................................................... 51 FIGURA 1.20 LOGO DE MICROSOFT VIRTUAL PC. ......................................................................................... 52 FIGURA 2.1 CRITERIOS PARA LA ADOPCIÓN DE LAS TIC`S EN LAS PYMES. FUENTE: E-COMMERCE IN

REGIONAL SMALL TO MEDIUM ENTERPRISES. PÁG. 11 ....................................................................... 63 FIGURA 2.2 PROYECTOS DE SOLUCIÓN DE TIC`S EN LAS PYMES. FUENTE: INFOPYME 2008. ................. 68 FIGURA 2.3 CARICATURA E-COMMERCE. ....................................................................................................... 80 FIGURA 2.4 DIAGRAMA INDICANDO A UN SERVIDOR DHCP BRINDANDO A LOS HOSTS LOS DATOS PARA

CONECTARSE A LA RED. FUENTE: HTTP://ADRIAN15.WORDPRESS.COM/2007/10/07/PROTOCOLO-DHCP/ ..................................................................................................................................................... 85

FIGURA 2.5 FUNCIONAMIENTO TÍPICO DE UNA CONSULTA DE DNS RECURSIVA. FUENTE: HTTP://NIRLOG.COM/2006/03/28/DNS-AMPLIFICATION-ATTACK/ .......................................................... 86

FIGURA 2.6 UBICACIÓN DEL PROXY PARA BRINDAR A LA INTRANET SEGURIDAD Y CONEXIÓN CON EL

INTERNET. FUENTE: HTTP://WWW.COMPUTERREPAIRMAINTENANCE.COM/TAG/ANONYMOUS-WEB-SURFING-WITH-A-PROXY ........................................................................................................................ 87

FIGURA 2.7 REPRESENTACIÓN DE ALGUNAS DE LAS VENTAJAS QUE PUEDE BRINDAR UN SERVICIO DE

DIRECTORIO. FUENTE: HTTP://WWW.QUEST.COM/IDENTITY_MANAGEMENT/IMAGES/IDM_DIAGRAM_WEB.JPG ....................... 89

FIGURA 2.8 REPRESENTACIÓN DEL FIREWALL PARA BRINDAR SEGURIDAD A UNA RED LAN. ....................... 90 FIGURA 2.9 ESTRUCTURA DE UNA ARQUITECTURA BÁSICA DE UN SERVICIO DE TELEFONÍA IP. FUENTE:

HTTP://WWW.E-ADVENTO.COM/SOLUCIONES/TELEFONIAIP.PHP ........................................................... 91

FIGURA 2.10 IMPLEMENTACIÓN DESCENTRALIZADA DE CINCO SERVIDORES. FUENTE: VIRTUALIZATION WITH

XEN, SYNGRESS 2007, PÁG 11. ........................................................................................................... 96 FIGURA 2.11 IMPLEMENTACIÓN VIRTUALIZADA DE CINCO SERVIDORES. FUENTE: VIRTUALIZATION WITH XEN,

SYNGRESS 2007, PÁG 12. .................................................................................................................... 99 FIGURA 2.12 IMPLEMENTACIÓN VIRTUALIZADA DE ALTA CONFIABILIDAD. FUENTE: VIRTUALIZATION WITH

XEN, SYNGRESS 2007, PÁG 319. ....................................................................................................... 102 FIGURA 3.1 EJEMPLO DE UNA ZONA DESMILITARIZADA (DMZ) Y SU UBICACIÓN EN LA RED. ...................... 110 FIGURA 3.2 ARQUITECTURA “DMZ INTRANET SERVER FARM” PRESENTADA POR CISCO. ......................... 112 FIGURA 3.3 PROTOTIPO DE DATACENTER PARA PYMES. .......................................................................... 113 FIGURA 3.4 ANILLOS DE PROTECCIÓN DEL MODO PROTEGIDO DE UN PROCESADOR. ............................... 129 FIGURA 3.5 AROS DE SEGURIDAD ARQUITECTURA NATIVA VS. PARAVIRTUALIZADA. FUENTE: THE

DEFINITIVE GUIDE TO XEN® HYPERVISOR. DAVID CHISNALL, PRENTICE HALL 2007. PÁG. 17. ...... 133 FIGURA 3.6 ARQUITECTURA BÁSICA DE XEN®. FUENTE: THE DEFINITIVE GUIDE TO XEN® HYPERVISOR.

DAVID CHISNALL, PRENTICE HALL 2007. PÁG. 24. ............................................................................ 134 FIGURA 3.7 ARQUITECTURA DE XEN®, SO MODIFICADOS (COLOR VERDE) Y SO NO MODIFICADOS (COLOR

NARANJA). FUENTE: (13). PÁG. 5. ...................................................................................................... 135 FIGURA 3.8 PROTOTIPO DE DATACENTER VIRTUALIZADO PARA PYMES................................................... 137 FIGURA 3.9 DESCARGA DEL PAQUETE DE XEN. ........................................................................................... 139 FIGURA 3.10 DESCOMPRESIÓN DEL PAQUETE DE XEN. ............................................................................... 140 FIGURA 3.11 INSTALACIÓN DEL PAQUETE DE XEN. ...................................................................................... 140 FIGURA 3.12 COMPROBACIÓN DE LA CORRECTA INSTALACIÓN DEL PAQUETE DE XEN. .............................. 141 FIGURA 3.13 BÚSQUEDA E INSTALACIÓN DE LOS PAQUETES REQUERIDOS PARA VIRTUALIZACIÓN EN

CENTOS. ............................................................................................................................................. 141 FIGURA 3.14 BÚSQUEDA DE LOS PAQUETES DE XEN HYPERVISOR. ........................................................... 142 FIGURA 3.15 COMPROBACIÓN DEL APARECIMIENTO DEL KERNEL MODIFICADO DE XEN EN /BOOT/. .......... 142 FIGURA 3.16 DIAGRAMA DE DISPOSITIVOS DE RED DE LOS DOMINIOS VIRTUALES. FUENTE:

WIKI.XENSOURCE.COM/XENWIKI/XENNETWORKING............................................................................ 147 FIGURA 3.17 ILUSTRACIÓN 2 DE BRIDGED NETWORKING. FUENTE:

WIKI.XENSOURCE.COM/XENWIKI/XENNETWORKING............................................................................ 148 FIGURA 3.18 ILUSTRACIÓN DE ROUTED WITH NAT NETWORKING. FUENTE:

WIKI.XENSOURCE.COM/XENWIKI/XENNETWORKING............................................................................ 149 FIGURA 3.19 ILUSTRACIÓN DE ROUTED NETWORKING. FUENTE:

WIKI.XENSOURCE.COM/XENWIKI/XENNETWORKING............................................................................ 150 FIGURA 3.20 BRIDGES CONFIGURADOS SEGÚN DISEÑO. ............................................................................. 152 FIGURA 3.21 VENTANA DE UN ADMINISTRADOR DE MÁQUINAS VIRTUALES QUE MUESTRA A LAS MISMAS

EJECUTÁNDOSE DE MANERA SIMULTÁNEA EN UN ÚNICO SERVIDOR FÍSICO. ....................................... 161 FIGURA 3.22 VENTANA DE LA CONSOLA DE UNA MÁQUINA VIRTUAL QUE MUESTRA SU INICIO. ................... 162 FIGURA 3.23 VENTANA DE LA CONSOLA DE UNA MÁQUINA VIRTUAL QUE MUESTRA SU CONECTIVIDAD CON EL

SERVIDOR FÍSICO. ................................................................................................................................ 162 FIGURA 3.24 VENTANAS DE DOS CONSOLAS DE MÁQUINAS VIRTUALES QUE MUESTRAN SU CONECTIVIDAD

ENTRE ELLAS. ....................................................................................................................................... 163 FIGURA 3.25 VENTANAS DE DETALLE DE UNA MÁQUINA VIRTUAL. ............................................................... 163 FIGURA 4.1 ESQUEMA DE SOLUCIÓN DE SERVIDOR VIRTUALIZADO PARA PYMES. ................................... 168 FIGURA 4.2 SERVIDOR VIRTUALIZADO CON ESQUEMA DE DIRECCIONAMIENTO IP. ..................................... 171 FIGURA 4.3 INSTALACIÓN DEL SERVIDOR VIRTUAL BASE CENTOS 5.2 ....................................................... 175 FIGURA 4.4 SELECCIÓN DEL DISCO PARA EL PARTICIONAMIENTO DEL SERVIDOR BASE. ............................ 176 FIGURA 4.5 ESQUEMA DE PARTICIONAMIENTO SERVIDOR VIRTUAL BASE. .................................................. 176 FIGURA 4.6 CONFIGURACIÓN GENERAL DE LA TARJETA DE RED DEL SERVIDOR BASE. .............................. 177 FIGURA 4.7 SELECCIÓN DE COMPONENTES DE INSTALACIÓN EN MODO SERVER. ...................................... 177 FIGURA 4.8 SELECCIÓN DE SOFTWARE DE SERVIDOR BASE. ....................................................................... 178 FIGURA 4.9 PROGRESO DE INSTALACIÓN DE CENTOS 5.2 ......................................................................... 179 FIGURA 4.10 INSTALACIÓN FINAL DE CENTOS 5.2 ...................................................................................... 179 FIGURA 4.11 DATACENTER DE INFRAESTRUCTURA ..................................................................................... 180 FIGURA 4.12 INSTALACIÓN DE IPTABLES MEDIANTE EL COMANDO YUM INSTALL ......................................... 184 FIGURA 4.13 INSTALACIÓN DE SQUID MEDIANTE EL COMANDO YUM INSTALL. ............................................. 184 FIGURA 4.14 INSTALACIÓN DE BIND MEDIANTE EL COMANDO YUM INSTALL. ............................................... 191 FIGURA 4.15 INSTALACIÓN DEL SERVIDOR DE DHCP CON LA HERRAMIENTA YUM. ................................... 200

FIGURA 4.16 ROUTERINTRANET ACTUANDO COMO DHCRELAY. .................................................................. 203 FIGURA 4.17 INSTALACIÓN DE SENDMAIL Y SUS DEPENDENCIAS CON LA HERRAMIENTA YUM. .................. 206 FIGURA 4.18 INSTALACIÓN DE OPENLDAP MEDIANTE EL COMANDO YUM INSTALL ....................................... 212 FIGURA 4.19 INSTALACIÓN DE OPENLDAP-SERVERS MEDIANTE EL COMANDO YUM INSTALL ...................... 212 FIGURA 4.20 INSTALACIÓN DE OPENLDAP-CLIENTS MEDIANTE EL COMANDO YUM INSTALL ........................ 213 FIGURA 4.21 DATACENTER DE DATOS. ........................................................................................................ 215 FIGURA 4.22 INSTALACIÓN DE MYSQL MEDIANTE EL COMANDO YUM INSTALL ........................................... 217 FIGURA 4.23 CONFIGURACIÓN DE CLAVE PARA MYSQL ............................................................................. 218 FIGURA 4.24 CREACIÓN DE BASES DE DATOS Y ASIGNACIÓN DE PERMISOS ............................................... 219 FIGURA 4.25 RECURSOS COMPARTIDOS DESDE LINUX VISTOS EN WINDOWS XP. .................................... 225 FIGURA 4.26 SITIO WEB.VSERVER.EC – WEBEMPRESARIAL. ....................................................................... 231 FIGURA 4.27 CONFIGURACIÓN DE VSFTPD VÍA WEBMIN. ............................................................................. 235 FIGURA 4.28 INSTALACIÓN DE CUPS MEDIANTE EL COMANDO YUM INSTALL. .............................................. 238 FIGURA 4.29 PANTALLA DE ADMINISTRACIÓN DE CUPS VÍA WEB ................................................................. 239 FIGURA 4.30 DMZ CORPORATIVA. ............................................................................................................... 241 FIGURA 4.31 FICHEROS DE WEBS ALOJADAS. .............................................................................................. 243 FIGURA 4.32 PORTAL WEB WWW.VSERVER.EC ........................................................................................... 245 FIGURA 4.33 PORTAL WEB WWW.AEIE.EC ................................................................................................... 246 FIGURA 4.34 PORTAL WEB VIADMIN.VSERVER.EC ....................................................................................... 246 FIGURA 4.35 PANTALLA DE INICIO DE ZEN CART ......................................................................................... 249 FIGURA 4.36 LICENCIA DE ZEN CART ........................................................................................................... 250 FIGURA 4.37 INSPECCIÓN DEL SISTEMA ....................................................................................................... 250 FIGURA 4.38 COMPROBACIÓN DEL SISTEMA PARA LA INSTALACIÓN DE ZEN CART .................................... 252 FIGURA 4.39 CONFIGURACIÓN DE LA BASE DE DATOS ................................................................................ 253 FIGURA 4.40 CONFIGURACIÓN DEL SISTEMA ............................................................................................... 254 FIGURA 4.41 PETICIÓN DEL DIRECTORIO PHPBB ......................................................................................... 254 FIGURA 4.42 UBICACIÓN DEL DIRECTORIO PHPBB ...................................................................................... 255 FIGURA 4.43 CONFIGURACIÓN DE LA CUENTA DE ADMINISTRACIÓN ........................................................... 255 FIGURA 4.44 ENVÍO Y RECEPCIÓN DE CORREO ENTRE MAILEMPRESARIAL Y MAILGATEWAY. .................. 256 FIGURA 4.45 SQUIRREL MAIL EN EL SERVIDOR WEBEMPRESARIAL. ........................................................... 260 FIGURA 4.46: PRUEBA DE ENRUTAMIENTO DESDE UN EQUIPO DE LA RED INTERNA DE LA EMPRESA HACIA

OTRO DE LA ZONA DE DATOS ............................................................................................................... 273 FIGURA 4.47: PRUEBA DE ENRUTAMIENTO DESDE UN EQUIPO DE LA RED INTERNA DE LA EMPRESA HACIA

OTRO DE LA ZONA DE INFRAESTRUCTURA ........................................................................................... 273 FIGURA 4.48: PRUEBA DE ENRUTAMIENTO DESDE UN EQUIPO DE LA ZONA DE INFRAESTRUCTURA HACIA

OTRO DE LA ZONA DE DATOS ............................................................................................................... 274 FIGURA 4.49: PRUEBA DE ENRUTAMIENTO DESDE UN EQUIPO DE LA ZONA DE INFRAESTRUCTURA HACIA

OTRO DE LA ZONA DESMILITARIZADA ................................................................................................... 275 FIGURA 4.50: PRUEBA DE ENRUTAMIENTO DESDE UN EQUIPO DE LA ZONA DE DATOS HACIA OTRO DE LA

ZONA DESMILITARIZADA ....................................................................................................................... 275 FIGURA 4.51: PRUEBAS DE RESOLUCIÓN DE NOMBRES DE DOMINIO Y DIRECCIONES IP EN LOS SERVIDORES

DNS DE LA INTRANET .......................................................................................................................... 275 FIGURA 4.52 PRUEBAS DEL SERVIDOR DHCP EN UN CLIENTE WINDOWS. ................................................. 276 FIGURA 4.53 PRUEBAS AL PORTAL DE INGRESO AL MAILEMPRESARIAL...................................................... 276 FIGURA 4.54 PRUEBA DE ENVÍO DE CORREO ELECTRÓNICO DESDE D.CARRASCO@VSERVER.EC A

J.BONILLA@VSERVER.EC Y D.CARRASCO@ANDINANET.NET. ............................................................ 277 FIGURA 4.55 PRUEBA DE RECEPCIÓN DEL CORREO ANTERIOR. .................................................................. 277 FIGURA 4.56 RESPUESTA DE CORREO. ........................................................................................................ 277 FIGURA 4.57 RECEPCIÓN DE CORREO DE RESPUESTA. ............................................................................... 278 FIGURA 4.58 PRUEBA DE MAILGATEWAY CON RECEPCIÓN DE CORREO EN EL DOMINIO @ANDINANET.NET.

............................................................................................................................................................. 278 FIGURA 4.59 CREACIÓN DE BASES DE DATOS Y ASIGNACIÓN DE PERMISOS ............................................... 279 FIGURA 4.60 PRUEBA DE FUNCIONAMIENTO DE SAMBA COMO SERVIDOR DE ARCHIVOS. SE OBSERVA LAS

CARPETAS COMPARTIDAS A TRAVÉS DE LA RED VISTAS DESDE UN CLIENTE WINDOWS. ................... 279 FIGURA 4.61 SERVIDOR DE ARCHIVOS SAMBA VISTO DESDE UN CLIENTE EN GNU-LINUX. ....................... 280

FIGURA 4.62 PRUEBA DE UPLOAD DE ARCHIVOS AL SERVIDOR SAMBA. SE MUESTRA TAMBIÉN LOS

ARCHIVOS DISPONIBLES. ..................................................................................................................... 280 FIGURA 4.63 EJEMPLO DE BÚSQUEDA DE UNA ENTRADA EN EL DIRECTORIO .............................................. 281 FIGURA 4.64 PORTAL WEB WWW.VSERVER.EC ........................................................................................... 281 FIGURA 4.65 PORTAL WEB WWW.AEIE.EC ................................................................................................... 282 FIGURA 4.66 PORTAL WEB VIADMIN.VSERVER.EC ....................................................................................... 282 FIGURA 4.67 PRUEBA DE INICIO DE SESIÓN DEL SERVIDOR FTP. ................................................................. 283 FIGURA 4.68 ARCHIVOS DESPLEGADOS EN EL SERVIDOR FTP. ................................................................... 283 FIGURA 4.69 PRUEBAS DE ENVÍO DE ARCHIVOS VÍA LÍNEA DE COMANDOS DESDE UN CLIENTE FTP EN

WINDOWS. ........................................................................................................................................... 284 FIGURA 4.70 PANTALLA DE ADMINISTRACIÓN DE CUPS VÍA WEB ................................................................. 284 FIGURA 4.71 VENTANA DE INSTALACIÓN EXITOSA DE ZEN CART ................................................................ 285 FIGURA 4.72: PRUEBAS DE RESOLUCIÓN DE NOMBRES DE DOMINIO Y DIRECCIONES IP EN LOS SERVIDORES

DNS DE LA ZONA DESMILITARIZADA ................................................................................................... 285 FIGURA 4.73: PRUEBA DE ENRUTAMIENTO DESDE UN EQUIPO DE LA ZONA DESMILITARIZADA HACIA UNA

DIRECCIÓN DE INTERNET ..................................................................................................................... 286 FIGURA 5.1 USO DE MEMORIA Y CPU POR EL SERVICIO BIND. .................................................................... 293 FIGURA 5.2 USO DE MEMORIA Y CPU POR EL SERVICIO CUPSD. ................................................................ 296 FIGURA 5.3 ILUSTRACIÓN DEL PROTOTIPO DE SERVIDOR VIRTUALIZADO PARA PYMES. .......................... 300 FIGURA 5.4 LOGOTIPO PROCESADOR INTEL® CORE™ 2 QUAD. ................................................................ 301 FIGURA 5.5 RENDIMIENTO DE LOS DISTINTOS TIPOS DE MEMORIA RAM. FUENTE:

HTTP://WWW.KINGSTON.COM/BRANDED/PDF_FILES/FINAL_ESX3_MEMORY.PDF .............................. 304 FIGURA 5.6 MEMORIA RAM KINGSTON KVR667D2N5/2 2GB.................................................................. 304 FIGURA 5.7 DISCO DURO SAMSUNG HD103SI DE 1TB DE CAPACIDAD TIPO SATA DE 7200 RPM. ........ 306 FIGURA 5.8 IMAGEN INTERIOR DEL DISCO DURO SAMSUNG HD103SI DE 1TB DE CAPACIDAD TIPO SATA DE

7200 RPM. .......................................................................................................................................... 306 FIGURA 5.9 TARJETA DE RED D-LINK DGE-530T - 1GBPS. FUENTE:

HTTP://WWW.DLINK.COM/PRODUCTS/?PID=284 ................................................................................. 308 FIGURA 5.10 DIAGRAMA INTERNO DEL MAINBOARD UTILIZADO: INTEL® DG33BU .................................... 312 FIGURA 5.11 TARJETA MADRE CON DISPOSITIVOS DE MEMORIA, PROCESADOR, INTERFACES DE RED DEL

PROTOTIPO. ......................................................................................................................................... 313 FIGURA 5.12 MEMORIA RAM INSTALADA. .................................................................................................... 314 FIGURA 5.13 PROCESADOR INSTALADO. ...................................................................................................... 314 FIGURA 5.14 DISPOSITIVOS DE RED INSTALADOS Y PUERTOS DISPONIBLES............................................... 315 FIGURA 5.15 TARJETAS DE RED INSTALADAS (VISTA EXTERNA). ................................................................. 315 FIGURA 5.16 PUERTOS DISPONIBLES DEL PROTOTIPO. ............................................................................... 316 FIGURA 5.17 DISCO DURO INSTALADO. ........................................................................................................ 316 FIGURA 5.18 FUENTE DE PODER INSTALADA................................................................................................ 317 FIGURA 5.19 UNIDAD DE DVD INSTALADA. .................................................................................................. 317 FIGURA 5.20 CASE DEL SERVIDOR. ............................................................................................................. 318 FIGURA 8.1 ARQUITECTURA DE XEN E INTEL® VT. ..................................................................................... 337 FIGURA 8.2 TWO WAY ROUTED NETWORK APLICADO AL DISEÑO. .............................................................. 359

ÍNDICE DE TABLAS

TABLA 2.1 CLASIFICACIÓN DE LAS MIPYMES ECUADOR. FUENTE: ASOCIACIÓN LATINOAMERICANA DE INTEGRACIÓN ALADI. ........................................................... 59

TABLA 2.2 CLASIFICACIÓN DE LAS MIPYMES COLOMBIA. FUENTE: LEY 905 DE 2004

HTTP://WWW.MIPYMES.GOV.CO/MICROEMPRESARIO/NEWSDETAIL.ASP?ID=86&IDCOMPANY=45 ... 60 TABLA 2.3 CLASIFICACIÓN DE LAS PYMES MERCOSUR. FUENTE:

HTTP://WWW.RAU.EDU.UY/MERCOSUR/FAQ/PRE24.MERCO.HTM .................................................... 61 TABLA 2.4 CLASIFICACIÓN DE LAS PYMES UNIÓN EUROPEA. FUENTE:

HTTP://EUROPA.EU/LEGISLATION_SUMMARIES/ENTERPRISE/BUSINESS_ENVIRONMENT/N26026_ES.HT

M ............................................................................................................................................... 62 TABLA 2.5 PARTICIPACIÓN DE LAS PYMES EN EL PIB. FUENTE: CÁMARA DE LA PEQUEÑA INDUSTRIA DE

PICHINCHA, PROYECTO INFOPYME 2008, RESUMEN EJECUTIVO PÁG. 2. ................................... 66 TABLA 2.6 DISTRIBUCIÓN DE LAS EMPRESAS ENCUESTADAS. FUENTE: LAS TECNOLOGÍAS DE LA

INFORMACIÓN Y LAS COMUNICACIONES EN LA COMPETITIVIDAD DE QUITO, SANTA FE ASSOCIATES

INTERNATIONAL. ......................................................................................................................... 69 TABLA 2.7 EMPRESAS CON CARACTERÍSTICAS DE USO AVANZADO DE TIC FUENTE: LAS TECNOLOGÍAS DE

LA INFORMACIÓN Y LAS COMUNICACIONES EN LA COMPETITIVIDAD DE QUITO, SANTA FE ASSOCIATES

INTERNATIONAL. ......................................................................................................................... 70 TABLA 2.8 TIPO DE RED LAN. FUENTE: LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES

EN LA COMPETITIVIDAD DE QUITO, SANTA FE ASSOCIATES INTERNATIONAL. ................................. 71 TABLA 2.9 REQUERIMIENTOS BÁSICOS DE TIC´S EN LAS PYMES. ......................................................... 73 TABLA 2.10 REQUERIMIENTOS TÉCNICOS PARA TIC´S EN LAS PYMES. ................................................. 74 TABLA 2.11 TIPO DE CONEXIÓN A INTERNET POR TAMAÑO DE EMPRESA. FUENTE: LAS TECNOLOGÍAS DE LA

INTERNATIONAL. ......................................................................................................................... 75 TABLA 2.12 VELOCIDAD DE CONEXIÓN A INTERNET. FUENTE: LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS

COMUNICACIONES EN LA COMPETITIVIDAD DE QUITO, SANTA FE ASSOCIATES INTERNATIONAL. ..... 76 TABLA 2.13 USOS DE INTERNET EN LA GERENCIA. FUENTE: LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS

COMUNICACIONES EN LA COMPETITIVIDAD DE QUITO, SANTA FE ASSOCIATES INTERNATIONAL. ..... 76 TABLA 2.14 USOS DE INTERNET POR LA EMPRESA. FUENTE: LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS

COMUNICACIONES EN LA COMPETITIVIDAD DE QUITO, SANTA FE ASSOCIATES INTERNATIONAL. ..... 77 TABLA 2.15 DIAGNÓSTICO Y ESTRATEGIA DE GOBIERNO ELECTRÓNICO. FUENTE CONATEL, MARZO

2005. ........................................................................................................................................ 78 TABLA 2.16 TIPO DE CUENTAS DE CORREO ELECTRÓNICO EN LA EMPRESA. FUENTE: LAS TECNOLOGÍAS DE

INTERNATIONAL. ......................................................................................................................... 79 TABLA 2.17 DISPONIBILIDAD DE SITIO WEB. FUENTE: LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS

COMUNICACIONES EN LA COMPETITIVIDAD DE QUITO, SANTA FE ASSOCIATES INTERNATIONAL. ..... 81 TABLA 2.18 DISPONIBILIDAD DE DOMINIO PROPIO. FUENTE: LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS

COMUNICACIONES EN LA COMPETITIVIDAD DE QUITO, SANTA FE ASSOCIATES INTERNATIONAL. ..... 82 TABLA 2.19 UTILIZACIÓN DEL SITIO WEB EMPRESAS NO EXPORTADORAS. FUENTE: LAS TECNOLOGÍAS DE

INTERNATIONAL. ......................................................................................................................... 82 TABLA 2.20 UTILIZACIÓN DEL SITIO WEB EMPRESAS EXPORTADORAS. FUENTE: LAS TECNOLOGÍAS DE LA

INTERNATIONAL. ......................................................................................................................... 83 TABLA 2.21 DISPONIBILIDAD DE SISTEMAS DE SEGURIDAD INFORMÁTICA. FUENTE: LAS TECNOLOGÍAS DE LA

INTERNATIONAL. ......................................................................................................................... 93 TABLA 2.22 COSTO DE UN EJEMPLO DE IMPLEMENTACIÓN DESCENTRALIZADA DE CINCO SERVIDORES. .... 97 TABLA 2.23 COSTO DE UN EJEMPLO DE IMPLEMENTACIÓN VIRTUALIZADA DE CINCO SERVIDORES. ......... 100 TABLA 2.24 AHORRO EN IMPLEMENTACIÓN VIRTUALIZADA DE CINCO SERVIDORES CON SOFTWARE

LICENCIADO. ............................................................................................................................ 100 TABLA 2.25 AHORRO EN IMPLEMENTACIÓN VIRTUALIZADA DE CINCO SERVIDORES CON SOFTWARE LIBRE.

............................................................................................................................................... 101 TABLA 3.1 CUADRO COMPARATIVO DE LOS PRINCIPALES TIPOS DE VIRTUALIZACIÓN DE SERVIDORES. .... 120

TABLA 3.2 CUADRO COMPARATIVO DE LOS PRINCIPALES TIPOS DE HERRAMIENTAS DE VIRTUALIZACIÓN DE

SERVIDORES. ........................................................................................................................... 123 TABLA 3.3 SELECCIÓN DE LA SOLUCIÓN DE VIRTUALIZACIÓN ............................................................... 126 TABLA 3.4 PARÁMETROS CONFIGURABLES DE XEND. FUENTE:

HTTP://WWW.REDHAT.COM/DOCS/MANUALS/ENTERPRISE/RHEL-5-MANUAL/ES-ES/VIRTUALIZATION/CH-VIRT-TASK-VIRSH-CONFIG-MAX-MEM.HTML ............................................ 157

TABLA 4.1 REQUERIMIENTOS TÉCNICOS PARA TIC´S EN LAS PYMES .................................................. 166 TABLA 4.2 DIRECCIONAMIENTO DEL CENTRO DE DATOS ..................................................................... 170 TABLA 4.3 ALTERNATIVAS DE SOFTWARE PARA DHCP. ........................................................................ 199 TABLA 4.4 ALTERNATIVAS DE SOFTWARE MTA´S. FUENTE:

HTTP://GLUC.UNICAUCA.EDU.CO/WIKI/INDEX.PHP/DOCUMENTACI%C3%B3N_MTAS_Y_TABLA_COMP

ARATIVA ................................................................................................................................... 205 TABLA 4.5 ARCHIVOS DE CONFIGURACIÓN DE SENDMAIL. .................................................................... 207 TABLA 4.6 OPCIONES PARA LA CONFIGURACIÓN DE RECURSOS COMPARTIDOS EN SAMBA. FUENTE:

FUENTE: DISEÑO DE LA INTRANET DE LA EMPRESA MEGAREDES CÍA. LTDA., TESIS DE GRADO ING. TRELLES SEGOVIA, CÉSAR ALFREDO, ING.VALLEJO CIFUENTES, RICARDO PATRICIO. ................. 227

TABLA 4.8 ALTERNATIVA DE SOFTWARE PARA FTP. FUENTE: HTTP://VSFTPD.BEASTS.ORG/#SECURITY Y

HTTP://WWW.INFORMATICABOSCO.COM/PHPNUKE/LINUXAVANZADO/CURSO/BLOQUE04/12.PROFTPD.PDF ......................................................................................................................................... 232

TABLA 5.1 CUADRO RESUMEN DE LAS CARACTERÍSTICAS DE LOS SERVIDORES VIRTUALES .................. 299 TABLA 5.2 ALTERNATIVAS DE PROCESADOR CON CARACTERÍSTICAS INTEL® VIRTUALIZATION

TECHNOLOGY. FUENTE: HTTP://ARK.INTEL.COM/PRODUCTCOLLECTION.ASPX?FAMILYID=28398 . 302 TABLA 5.3 CARACTERÍSTICAS TÉCNICAS MEMORIA RAM ESCOGIDA. FUENTE:

HTTP://WWW.VALUERAM.COM/DATASHEETS/KVR667D2N5_2G.PDF .......................................... 305 TABLA 5.4 CARACTERÍSTICAS TÉCNICAS DEL DISCO DURO SELECCIONADO. FUENTE:

HTTP://WWW.SAMSUNG.COM/GLOBAL/BUSINESS/HDD/PRODUCTMODEL.DO?GROUP=72&TYPE=61&SU

BTYPE=78&MODEL_CD=443&PPMI=1170# ............................................................................... 307 TABLA 5.5 CARACTERÍSTICAS TÉCNICAS TARJETAS DE RED ADICIONALES TIPO PCI. FUENTE:

HTTP://WWW.DLINK.COM/PRODUCTS/?PID=284 .......................................................................... 309 TABLA 5.6 CARACTERÍSTICAS TÉCNICAS DE LAS ALTERNATIVAS DE MAINBOARD PARA EL PROTOTIPO. .. 311 TABLA 6.1 COSTOS DEL HARDWARE PARA LA IMPLEMENTACIÓN DEL PROTOTIPO DE SERVIDOR

VIRTUALIZADO. ........................................................................................................................ 323 TABLA 6.2 SOFTWARE UTILIZADO EN LA IMPLEMENTACIÓN DEL PROTOTIPO DE SERVIDOR VIRTUALIZADO.

............................................................................................................................................... 324 TABLA 6.3 COSTO TOTAL SERVIDOR VIRTUALIZADO. ........................................................................... 325 TABLA 8.1 HTTP://ARK.INTEL.COM/COMPARE.ASPX?IDS=41316,38512,27486,27249,42805, ............. 340 TABLA 8.2 UTILIZACIÓN DE LAS TIC´S EN AMÉRICA LATINA. FUENTE: “LAS TECNOLOGÍAS DE LA

INFORMACIÓN Y LAS COMUNICACIONES EN LA COMPETITIVIDAD DE QUITO” PÁG: 34. ECON. HERNANDO LÓPEZ GUERRERO, ING. HUGO CARRIÓN GORDÓN, © CORPORACIÓN DE PROMOCIÓN

ECONÓMICA CONQUITO, 2007 .............................................................................................. 342 TABLA 8.3 FASES DE LA IMPLEMENTACIÓN DE LA SOLUCIÓN DE SERVIDOR VIRTUALIZADO. FUENTE:

HTTP://WWW.ASAC.AS/WEB/UPLOAD/PONENCIAS/HP-BLADE_VIRTUALIZACI%C3%B3N.PDF ........ 354

ÍNDICE DE ESPACIOS DE CÓDIGO

ESPACIO DE CÓDIGO 3.1 CÓDIGO A INTRODUCIRSE EN EL ARCHIVO MENU.LST PARA PERMITIR EL INICIO DEL

KERNEL DE XEN. .................................................................................................................................. 143 ESPACIO DE CÓDIGO 3.2 ARCHIVO DE CONFIGURACIÓN DEL DOMINIO PARA UN SERVIDOR ....................... 146 ESPACIO DE CÓDIGO 3.3 CÓDIGO PARA CONFIGURACIÓN TIPO BRIDGE. .................................................... 149 ESPACIO DE CÓDIGO 3.4 CÓDIGO PARA CONFIGURACIÓN DE NETWORK NAT. ........................................... 150 ESPACIO DE CÓDIGO 3.5 CÓDIGO PARA CONFIGURACIÓN DE TWO WAY ROUTED ..................................... 151 ESPACIO DE CÓDIGO 3.6 ARCHIVOS DE CONFIGURACIÓN DE BRIDGED NETWORKING ............................... 152 ESPACIO DE CÓDIGO 3.7 SCRIPT SCRIPT-PYMES PARA UNA BRIDGED NETWORKING .............................. 153 ESPACIO DE CÓDIGO 3.8 CONFIGURACIÓN DE UN DISPOSITIVO DE ALMACENAMIENTO PARA VM. ............ 154 ESPACIO DE CÓDIGO 3.9 CÓDIGO PARA AÑADIR EN CALIENTE UN DISPOSITIVO DE ALMACENAMIENTO ..... 155 ESPACIO DE CÓDIGO 3.10 CÓDIGO PARA DESVINCULAR EN CALIENTE UN DISPOSITIVO DE ALMACENAMIENTO

............................................................................................................................................................. 155 ESPACIO DE CÓDIGO 4.1 ARCHIVO DE CONFIGURACIÓN PARA LA CREACIÓN DE UNA MÁQUINA VIRTUAL . 174 ESPACIO DE CÓDIGO 4.2 ARCHIVO DE CONFIGURACIÓN DE UNA MÁQUINA VIRTUAL. ................................ 174 ESPACIO DE CÓDIGO 4.3 INSTALACIÓN DE UNA MÁQUINA VIRTUAL CON LA HERRAMIENTA VIRT-INSTALL . 175 ESPACIO DE CÓDIGO 4.4 RUTAS DEL SERVIDOR ROUTERINTRANET ........................................................... 185 ESPACIO DE CÓDIGO 4.5 EJEMPLO DE REFLAS PARA FILTRADO DE PAQUETES EN EL ROUTERINTRANET.. 187 ESPACIO DE CÓDIGO 4.6 RUTAS DEL SERVIDOR FIREWALLPROXY ............................................................. 187 ESPACIO DE CÓDIGO 4.7 CONFIGURACIONES PARA FILTRADO DE PAQUETES EN EL FIREWALLPROXY ...... 188 ESPACIO DE CÓDIGO 4.8 ARCHIVO DE CONFIGURACIÓN SQUID.CONF ........................................................ 189 ESPACIO DE CÓDIGO 4.9 ARCHIVO DE CONFIGURACIÓN DNS PRIMARIO NAMED.CONF ............................. 193 ESPACIO DE CÓDIGO 4.10 ARCHIVO DE ZONA DE NOMBRES PRIMARIO NAMED.VSERVER.EC .................... 194 ESPACIO DE CÓDIGO 4.11 ARCHIVO DE ZONA IP NAMED.10.0.0 ................................................................ 194 ESPACIO DE CÓDIGO 4.12 ARCHIVO DE ZONA IP PRIMARIO NAMED.10.0.1 ............................................... 195 ESPACIO DE CÓDIGO 4.13 ARCHIVO DE ZONA IP PRIMARIO NAMED.10.0.2 ............................................... 195 ESPACIO DE CÓDIGO 4.14 ARCHIVO DE ZONA IP PRIMARIO NAMED.192.168.0 ......................................... 195 ESPACIO DE CÓDIGO 4.15 ARCHIVO DE ZONA IP PRIMARIO NAMED.192.168.2 ......................................... 196 ESPACIO DE CÓDIGO 4.16 ARCHIVO DE ZONA IP PRIMARIO NAMED.172.16.0 ........................................... 196 ESPACIO DE CÓDIGO 4.17 ARCHIVO DE ZONA LOCAL PRIMARIO NAMED.LOCAL ......................................... 196 ESPACIO DE CÓDIGO 4.18 ARCHIVO DE ZONA LOCAL PRIMARIO LOCALHOST.ZONE ................................... 196 ESPACIO DE CÓDIGO 4.19 ARCHIVO DE CONFIGURACIÓN DNS SECUNDARIO NAMED.CONF ..................... 198 ESPACIO DE CÓDIGO 4.20 ARCHIVO DE ZONA LOCAL SECUNDARIO NAMED.LOCAL .................................... 198 ESPACIO DE CÓDIGO 4.21 ARCHIVO DE ZONA LOCAL PRIMARIO LOCALHOST.ZONE ................................... 198 ESPACIO DE CÓDIGO 4.22 ARCHIVO DE CONFIGURACIÓN DHCPD.CONF ..................................................... 202 ESPACIO DE CÓDIGO 4.23 ARCHIVO DE CONFIGURACIÓN DHCRELAY. ........................................................ 203 ESPACIO DE CÓDIGO 4.24 ARCHIVO DE CONFIGURACIÓN SENDMAIL.MC .................................................... 207 ESPACIO DE CÓDIGO 4.25 ARCHIVO DE CONFIGURACIÓN LOCAL-HOST-NAMES. ........................................ 208 ESPACIO DE CÓDIGO 4.26 ARCHIVO DE CONFIGURACIÓN ACCESS. ............................................................ 208 ESPACIO DE CÓDIGO 4.27 ACTIVACIÓN DEL SERVICIO SMTP AUTENTIFICADO .......................................... 209 ESPACIO DE CÓDIGO 4.28 ARCHIVO DE CONFIGURACIÓN DOVECOT.CONF ................................................ 209 ESPACIO DE CÓDIGO 4.29 ARCHIVO DE CONFIGURACIÓN DE MAILSCANNER............................................. 210 ESPACIO DE CÓDIGO 4.30 CAMBIOS EN EL ARCHIVO DE CONFIGURACIÓN SLAPD.CONF ............................ 214 ESPACIO DE CÓDIGO 4.31 CAMBIOS EN EL ARCHIVO DE MIGRACIÓN MIGRATE_COMMON.PH .................... 214 ESPACIO DE CÓDIGO 4.32 CONFIGURACIÓN DE ARCHIVO LMHOSTS EN SAMBA. ........................................ 222 ESPACIO DE CÓDIGO 4.33 ARCHIVO DE CONFIGURACIÓN SMB.CONF DE SAMBA. ...................................... 225 ESPACIO DE CÓDIGO 4.34 ARCHIVO DE CONFIGURACIÓN HTTPD.CONF (EXTRACTO). ............................... 230 ESPACIO DE CÓDIGO 4.35 AGREGACIÓN DE CNAME PARA WEBEMPRESARIAL.VSERVER.EC .................. 231 ESPACIO DE CÓDIGO 4.36 ARCHIVO DE CONFIGURACIÓN VSFTPD.CONF ................................................... 236 ESPACIO DE CÓDIGO 4.37 CAMBIOS EN EL ARCHIVO DE MIGRACIÓN MIGRATE_COMMON.PH .................... 240 ESPACIO DE CÓDIGO 4.38 ARCHIVO DE CONFIGURACIÓN HTTPD.CONF DE LA WEBINTERNET. .................. 244 ESPACIO DE CÓDIGO 4.39 EXTRACTO DEL ARCHIVO DE CONFIGURACIÓN NAMED.CONF. .......................... 244

ESPACIO DE CÓDIGO 4.40 CONFIGURACIÓN DE CNAME PARA LAS WEB ALOJADAS EN WEBINTERNET DEL

DOMINIO VSERVER.EC. ......................................................................................................................... 244 ESPACIO DE CÓDIGO 4.41 CONFIGURACIÓN DEL DOMINIO WWW.AEIE.EC PARA SER ATENDIDO POR EL

SERVIDOR VIRTUAL WEBINTERNET (10.0.0.2). ................................................................................... 245 ESPACIO DE CÓDIGO 4.42 ARCHIVO DE CONFIGURACIÓN SENDMAIL.MC .................................................... 257 ESPACIO DE CÓDIGO 4.43 ARCHIVO DE CONFIGURACIÓN ACCESS. ............................................................ 258 ESPACIO DE CÓDIGO 4.44 ARCHIVO DE CONFIGURACIÓN MAILERTABLE. ................................................... 258 ESPACIO DE CÓDIGO 4.45 ACTIVACIÓN DEL SERVICIO SMTP AUTENTIFICADO .......................................... 258 ESPACIO DE CÓDIGO 4.46 ARCHIVO DE CONFIGURACIÓN DE MAILSCANNER............................................. 260 ESPACIO DE CÓDIGO 4.47 ARCHIVO DE CONFIGURACIÓN DNS PRIMARIO NAMED.CONF ........................... 263 ESPACIO DE CÓDIGO 4.48 ARCHIVO DE ZONA DE NOMBRES PRIMARIO NAMED.VSERVER.EC .................... 263 ESPACIO DE CÓDIGO 4.49 ARCHIVO DE ZONA IP NAMED.10.0.2 ................................................................ 264 ESPACIO DE CÓDIGO 4.50 ARCHIVO DE ZONA IP PRIMARIO NAMED.172.16.0 ........................................... 264 ESPACIO DE CÓDIGO 4.51 ARCHIVO DE ZONA LOCAL PRIMARIO NAMED.LOCAL ......................................... 264 ESPACIO DE CÓDIGO 4.52 ARCHIVO DE ZONA LOCAL PRIMARIO LOCALHOST.ZONE ................................... 264 ESPACIO DE CÓDIGO 4.53 ARCHIVO DE CONFIGURACIÓN DNS SECUNDARIO NAMED.CONF ..................... 265 ESPACIO DE CÓDIGO 4.54 ARCHIVO DE ZONA LOCAL SECUNDARIO NAMED.LOCAL .................................... 265 ESPACIO DE CÓDIGO 4.55 ARCHIVO DE ZONA LOCAL PRIMARIO LOCALHOST.ZONE ................................... 266 ESPACIO DE CÓDIGO 4.56 RUTAS DEL SERVIDOR FIREWALLINTERNET ...................................................... 268 ESPACIO DE CÓDIGO 4.57 REGLAS DE FILTRADO DE PAQUETES EN EL SERVIDOR FIREWALLINTERNET .... 270 ESPACIO DE CÓDIGO 4.58 GENERACIÓN DEL CERTIFICADO DE AUTORIDAD ............................................... 271 ESPACIO DE CÓDIGO 4.59 ARCHIVO DE CONFIGURACIÓN DEL SERVIDOR .................................................. 272 ESPACIO DE CÓDIGO 4.60 ARCHIVO DE CONFIGURACIÓN DEL CLIENTE ..................................................... 272 ESPACIO DE CÓDIGO 8.1 CUADRO DE CÓDIGO PARA CONFIGURACIÓN PROTOTIPO VIRTUALIZADO DE

PYMES DEL TIPO TWO WAY ROUTED. ............................................................................................... 360 ESPACIO DE CÓDIGO 8.2 CONFIGURACIÓN DE INTERFAZ DE RED VIRTUAL DE UNA VM PARA UN ESQUEMA

ROUTED. ............................................................................................................................................... 361 ESPACIO DE CÓDIGO 8.3 CONFIGURACIÓN DEL DOM0 PARA FORWARDING Y ENMASCARAMIENTO DE LAS

VM ....................................................................................................................................................... 361 ESPACIO DE CÓDIGO 8.4 CREACIÓN DE UNA VM. ....................................................................................... 361

RESUMEN

En el presente proyecto se realiza el diseño, análisis e implementación de un servidor

virtualizado sobre el que se implementa un centro de datos diseñado para las

pequeñas y medianas empresas PyMEs. El diseño presentado constituye una

solución económica para permitir su adquisición por parte de las pequeñas empresas,

brindar la escalabilidad suficiente para permitir el crecimiento y la flexibilidad

requerida por los cambios que pudieran ocurrir en las organizaciones.

El primer capítulo se centra en la descripción de la tecnología de virtualización, una

breve historia de su evolución y desarrollo y los diferentes tipos de virtualización

existentes. Aquí se describirán las características y aplicaciones de los principales

tipos de virtualización y de las principales herramientas que se emplean.

En el segundo capítulo se trata sobre la situación de las pequeñas y medianas

empresas (PYMES) analizando sus requerimientos tecnológicos y la factibilidad de

implementación de un prototipo de servidor virtualizado para facilitar su correcta

operación. Para esto se emplearán datos obtenidos de fuentes como el Ministerio de

Industrias y Competitividad (MIC), la Cámara de la Pequeña Industria de Pichincha

(CAPEIPI) y de la Corporación de Promoción Económica (CONQUITO).

Posteriormente en el capítulo tres, en función del análisis de las alternativas de tipo y

plataforma de virtualización, se procede a seleccionar la solución más conveniente de

acuerdo a los requerimientos de las PYMES; esta solución la constituye el Hypervisor

XEN®. Así de esta manera se procede a detallar dicha herramienta y la

implementación de una arquitectura servidor virtualizado con la misma.

En el capítulo cuatro se presenta el centro de datos para las PYMES diseñado en

base a los servicios requeridos según lo expuesto en el segundo capítulo. En esta

parte del proyecto se detalla el modo en que se realizan las instalaciones y

configuraciones de los diversos servidores virtuales y los servicios a implementarse,

al igual que se mostrarán pruebas generales del correcto funcionamiento de los

mismos.

Una vez que se tiene en claro la forma de instalación y configuración de la

herramienta de virtualización y los servidores virtuales, en el capítulo cinco se

procede a dimensionar cada uno de los servicios a implementarse al igual que el

servidor físico con la selección del hardware requerido para la implementación del

prototipo.

Finalmente, en el capítulo seis, se presenta el presupuesto requerido para la

implementación del prototipo y las principales conclusiones y recomendaciones

obtenidas en la elaboración del proyecto en el capítulo 7.

Se incluye, al final del presente proyecto, anexos correspondientes a datos

adicionales y precisiones para una comprensión integral del trabajo así como un CD-

ROM donde se puede encontrar el código completo de las implementaciones

realizadas.

Los autores.

PRESENTACIÓN

El progreso computacional de los últimos 40 años ha traído consigo de manera

generalizada el aparecimiento de infraestructuras tecnológicas con características de

mayor potencia, rapidez, simplicidad y menor costo que tecnologías precedentes.

Esta evolución computacional de hardware y software ha dado lugar que los centros

de datos de las organizaciones también evolucionen a través de los años. Éste

desarrollo de los centros de datos se ha dado fundamentalmente en relación a tres

paradigmas: centralización, descentralización y el introducido en los últimos años: la

consolidación. Es en esta última infraestructura tecnológica, la consolidación, donde

la virtualización toma un papel protagónico especialmente en la virtualización de

servidores.

El desarrollo de la virtualización constituye un trabajo probado a lo largo ya de 40

años, desde su aparecimiento y aplicación en la era Mainframe por parte de IBM®

hasta sus recientes aplicaciones en el hardware x86 por parte Xen®, VMware® y

Microsoft® entre otros.

Todo este desarrollo tecnológico ha ido de la mano con la evolución, estructura y giro

del negocio de las organizaciones en busca de obtener mayor eficiencia y eficacia en

el desempeño de sus operaciones y con ello la obtención de un mayor rédito en el

ámbito de su competencia.

Esta combinación de factores, a decir, la reducción de costos del hardware

(especialmente del hardware x86), la aplicación de la virtualización de servidores y la

constitución de un centro de datos eficiente, contribuye a dar lugar a que el entorno

de TI de las organizaciones productivas cambie a gran velocidad. El objetivo es

ajustar la tecnología con mayor precisión a las necesidades organizacionales

contribuyendo así a la constitución de un centro de datos más eficiente, manejable,

confiable, seguro, disponible y de menor costo.

Es así que las soluciones tecnológicas de virtualización, antes casi exclusivas para

las grandes empresas, comienzan a ser presentadas en formato pequeño para

empresas de menor tamaño donde se requiere tecnología con la menor inversión de

recursos económicos (debido a su naturaleza) para su mejoramiento organizativo y

productivo.

Es por este motivo que en el presente trabajo de investigación, es donde se pretende

aprovechar esta serie de factores tecnológicos y económicos como la virtualización

de servidores para incluir a las Pequeñas y Medianas Empresas -PyMEs- en un

nuevo ámbito organizativo donde las Tecnologías de Información (TI) constituyen un

factor trascendental en el incremento de su productividad.

Así, los beneficios de la virtualización son grandes; ésta es una tecnología ecológica

que ahorra costos, espacio y recursos, permitiendo que las empresas “…reduzcan su

consumo energético en hasta un 80%, gestionen mejor el crecimiento de los sistemas

y consigan reducciones en el coste total de propiedad de hasta el 72%...”1. Esto se

debe fundamentalmente a que la virtualización de servidores permite múltiples

servidores en un sólo equipo, de forma que un único servidor podría ejecutar varios

sistemas operativos y aplicaciones del negocio.

El hecho de aplicar la Virtualización de Servidores para las PyMES sobre hardware

convencional (x86) y una distribución de Linux, no es más que un factor adicional que

esperamos contribuya a la adopción de infraestructuras tecnológicas que brinden un

centro de datos con altas características de eficiencia y eficacia pero a la vez

accesible económicamente.

Finalmente nuestro objetivo principal con este proyecto de titulación es el poder

contribuir de manera técnica desde nuestro campo de acción –la Electrónica y Redes

de Información- al crecimiento productivo de las pequeñas y medianas empresas

ecuatorianas y con ello al desarrollo productivo del país; ponemos así de esta manera

en práctica el lema que orgullosamente lleva nuestra Escuela Politécnica Nacional:

“El bienestar del hombre proviene de la Ciencia” y al que queremos agregar: “La

ingeniería al servicio de la comunidad, al servicio de todas y todos los ecuatorianos

en pro de un mejor país”.

Los autores

1 Estudios realizados por IBM sobre tecnologías de virtualización. http://www.tecnologiahechapalabra.com/negocios/PyMES/testimonios/articulo.asp?i=3031

CAPÍTULO UNO

1. DESCRIPCIÓN GENERAL DE LA

VIRTUALIZACIÓN (ARQUITECTURA SERVIDOR

VIRTUALIZADO) Y LAS HERRAMIENTAS

TECNOLÓGICAS PARA SU IMPLEMENTACIÓN.

1.1. FUNDAMENTOS GENERALES DE LA VIRTUALIZACIÓN

1.1.1. ANTECEDENTES

El cada vez más potente y de menor costo hardware x86 actual, ha sido adoptado en

los últimos años en un número considerable de implementaciones de servidores y

escritorios x86; el incremento en su utilización generó nuevos desafíos operacionales

y de infraestructura de TI.

Entre estos desafíos se pueden mencionar:

· Sub-aprovechamiento de la infraestructura: Este hardware fue diseñado

para ejecutar un único sistema operativo y en implementaciones estándar de

servidores x86 se tiende a ejecutar una aplicación por servidor. Esta situación

presente de manera general muestra un índice de aprovechamiento promedio

de entre un 10% y un 15% de la capacidad total2. Esta práctica habitual la

realizan las organizaciones para evitar el riesgo de afectar la disponibilidad de

las aplicaciones del servidor producidas por vulnerabilidades de otras

aplicaciones en el mismo servidor.

· Incremento de costos de infraestructura física: El crecimiento de la

infraestructura física debe estar respaldado por costos de funcionamiento que

garanticen suplir la necesidad incurrente de las infraestructuras tecnológicas a

permanecer operativas en todo momento. Dichos costos aumentan

significativamente debido al incremento en gastos de energía, refrigeración e

instalaciones que no varían según los niveles de aprovechamiento de los

servidores.

· Incremento de los costos de administración de TI: Debido al incremento de

complejidad de los entornos informáticos, es necesario que el personal invierta

mayor cantidad de tiempo en tareas manuales relacionadas con el

2 Datos señalados por la empresa de estudios de mercado International Data Corporation (IDC). Fuente: http://www.vmware.com/lasp/overview/history.html

mantenimiento de los servidores. Ante esta situación, cada vez se necesita

más personal capacitado, con experiencia y a un mayor costo.

· Protección y estrategias insuficientes de recuperación ante fallas y

desastres: Cada vez más es necesario contar con una estrategia que permita

a las organizaciones disminuir los riesgos debido a ataques de seguridad y

desastres naturales. La finalidad es aumentar el tiempo de continuidad del

negocio impidiendo la inactividad de las aplicaciones del servidor y con ello la

pérdida de valores económicos derivados por la paralización de actividades de

la organización.

· Escritorios de usuario final que requieren un nivel alto de mantenimiento:

Para el control de un entorno de escritorio distribuido y el cumplimiento con las

políticas de administración, acceso y seguridad, es necesario aplicar muchos

parches y llevar a cabo actualizaciones continuas en el entorno del escritorio.

Esto permitirá eliminar las vulnerabilidades de seguridad sin perjudicar la

capacidad del usuario de trabajar con eficacia. Sin embargo lograr este

escenario es complejo y costoso.

La virtualización aparece como una alternativa de solución ante estos desfíos.

1.1.2. FUNDAMENTACIÓN

De manera general, la idea de funcionamiento de la virtualización se basa en la

abstracción de los recursos físicos (ya sean estos de procesamiento, almacenamiento

o red) y las aplicaciones. Es decir busca añadir una capa de abstracción entre los

recursos para separar al hardware del software que se ejecuta sobre él.

En tal virtud, la virtualización permite que múltiples entornos se consoliden sobre una

única pieza de hardware. Así por ejemplo permite que en lugar de tener algunos

servidores con una aplicación en cada uno y un bajo porcentaje de utilización, utilizar

un único servidor para esas aplicaciones y que su porcentaje de uso sea

notablemente superior y sin impactar en el rendimiento de las aplicaciones.

Como consecuencia la virtualización da lugar a un mejor aprovechamiento de

recursos infrautilizados como servidores, recursos de almacenamiento y dispositivos

de red lo cual hace posible un centro de datos más dinámico. Así la virtualización nos

brinda la posibilidad de poder repartir los recursos en función de las necesidades del

negocio, maximizando el uso y a la vez simplificando las tareas y costos de

administración.

De esta forma, se consigue reducir los costos por equipamiento, espacio y

electricidad (con ello reducir las emisiones de CO2 resultando una tecnología

ecológica), así como una mayor flexibilidad en los sistemas de información y una

mejor utilización de los recursos de TI.

Por todo lo mencionado anteriormente, la idea de la virtualización se resume en algo

simple, y ahí radica su fuerza: hacer más con menos.

El objetivo final es:

· Posibilitar una reducción en costos y complejidad.

· Proporcionar un mejor alineamiento entre los procesos de las Tecnologías de

Información y los logros del negocio.

· Maximizar la utilización de los recursos.

Todo esto acompañado adicionalmente de la posibilidad de:

· Brindar confiabilidad y seguridad mejorada por medio del aislamiento de los

recursos computacionales.

· Optimizar tanto los niveles como la calidad de los servicios.

Actualmente, existen diferentes tipos y herramientas de virtualización que buscan

alcanzar estos objetivos. Así, con mucha frecuencia, encontramos referencias a la

virtualización de almacenamiento, virtualización de aplicaciones, virtualización de los

recursos de red, virtualización de sistemas operativos, etc. aunque sea su aplicación

al Centro de Datos donde ha logrado una mayor importancia en el mercado con la

virtualización de servidores.

En el presente trabajo de investigación se dará mayor énfasis a este último tipo de

virtualización.

1.1.3. ANTECEDENTES HISTÓRICOS DE LA VIRTUALIZACIÓN

La introducción de la virtualización no es una cuestión reciente, su aparecimiento data

de los años 60`s por IBM® en sus implementaciones mainframe.

La idea principal era particionarlos de manera lógica en máquinas virtuales

independientes logrando así un mayor aprovechamiento de la costosa inversión.

Estas particiones permitían a los mainframe la capacidad de realizar múltiples tareas

de forma simultánea y permitir además que un programador escriba el código fuente

de un programa mientras otro programador compilaba algún otro.

Esta técnica de virtualizar los recursos fue mejorándose durante los 60`s y 70`s con

proyectos como: CP/CMS, M44/44X, IBM® System 360 o el IBM® VM 370, logrando

crear varios entornos de máquinas virtuales (o VM por sus siglas en ingles de Virtual

Machine) sobre copias virtuales de hardware, todas manejadas por un monitor de

máquinas virtuales o Virtual Machine Monitor (VMM) que controlaba los recursos de

memoria, I/O y manejo de interrupciones.

El empleo de esta tecnología, sin embargo, no contó con una mayor difusión ni

masificación en el mercado debido en gran parte a la revolución de los ordenadores

personales de los 80´s y 90´s que provocaron que la industria pierda interés en los

sistemas operativos súper optimizados para mainframes. Es así que la virtualización

fue quedando al margen de la mayoría de consumidores.

La posterior reducción de costos en equipos x86 de los 90`s y de la última década así

como la creciente capacidad, velocidad y mejoras adicionales en procesadores,

memoria, dispositivos de almacenamiento, interfaces de red, dispositivos de

conectividad3 entre otros, ha traído consigo el incremento de implementaciones de

servidores y escritorios x86 estableciendo un modelo de informática distribuida. A 3 Al momento de realización del presente proyecto se dispone de Workstation' s con procesadores de cuatro núcleos, memoria RAM de 8GB, disco duro de 1TB, interfaces de red de 1Gbps a partir de 600 U.S.D. Adicionalmente se dispone de emuladores de routers y switches para una configuración económica sin necesidad de hardware adicional.

esto se añade, la adopción generalizada de Windows y el surgimiento de GNU Linux

como sistemas operativos de servidor; esta serie de factores convirtieron a los

servidores x86 en el estándar del sector (organizaciones pequeñas, medianas y

algunas grandes) en los 90´s.

Esta situación histórica, sin embargo, generó desafíos como:

· Incremento de costos de infraestructura física (aumento de servidores por

servicio) frente a la constante expansión de capacidades del hardware dando

la capacidad a realizar múltiples trabajos simultáneos sobre una misma

máquina.

· Esfuerzos para controlar costos y simplificar la administración a través de la

consolidación de servidores.

· La necesidad de controlar grandes instalaciones multiprocesador (granja de

servidores).

· La mejorada seguridad, confiabilidad e independencia de dispositivos posible

en la implementación de arquitecturas virtualizadas (hypervisor).

· La necesidad de correr aplicaciones complejas, dependientes del sistema

operativo en diferentes ambientes de hardware y S.O.

Por tal motivo, la solución de virtualización tuvo su re aparecimiento.

Así, las organizaciones abandonaron el uso compartido y centralizado del modelo de

mainframe para aprovechar posteriormente los bajos costos de los sistemas

distribuidos y luego dar lugar a la tendencia de esquemas consolidados. Éste último

hecho posible gracias a la virtualización.

1.1.3.1. Explosión de La Virtualización de 1990´S y 2000`S

Los mayores fabricantes de servidores en el mundo, incluyendo Sun® Microsystems,

HP®, IBM® y SGI®, han vendido hardware virtualizado desde inicios del 2000. Éstas

ofertas se las ha podido encontrar desde sistemas especializados de alto rango y de

alto costo (millón de dólares) hasta sistemas de rango medio (System-P de IBM®,

CoolThreads T1000, T2000 de Sun®, y T5x00 HP® 9000 Superdome series de HP®)

e inclusive sistemas de alto rendimiento y bajo costo sobre hardware x86 (lo cual es

el tema de tratamiento del presente trabajo de investigación).

Figura 1.1 Servidores de varias marcas de la actualidad. Fuente: bombayharbor.com

Especiales esfuerzos se han dado a proyectos open source para hardware

x86/x86_64 entre los que se tiene a proyectos como Xen® u otros del tipo propietario

como VMware® o Hyper-V™ de Microsoft®.

1.1.3.2. Virtualización y el Hardware x86

Durante los 90´s y la última década, a medida que el hardware x86 reducía en sus

costos, su capacidad y velocidad mejoraban. Es así que se han ido incorporando

cada vez mejoras adicionales en procesadores, memoria, dispositivos de

almacenamiento, interfaces de red, dispositivos de conectividad entre otros. Esta

situación ha traído consigo el incremento de implementaciones de servidores y

escritorios x86. A esto se añade, como ya se mencionó anteriormente, la adopción

generalizada de Windows y GNU Linux como sistemas operativos de servidor,

convirtiendo a los servidores x86 en dispositivos claramente populares, asequibles y

atractivos para las organizaciones en los 90´s y en el nuevo milenio.

Sin embargo, a medida que los usuarios optaban por las PCs y la computación

cliente-servidor, no existía una solución equivalente para la virtualización de la línea

de productos x86 en el mercado.

Esta situación histórica generó desafíos ya antes mencionados despertando el interés

en el altamente rentable sector del mercado para el desarrollo de plataformas de

virtualización para hardware x86.

La arquitectura x86 es particularmente difícil de virtualizar. Así por ejemplo, la

virtualización completa sobre la arquitectura x86 tiene un costo significativo en la

complejidad del hypervisor y en el rendimiento por la simulación total del hardware;

por otro lado la paravirtualización requiere de modificaciones del sistema operativo

anfitrión para dar lugar a su funcionamiento de simulación parcial del hardware

subyacente.

Más recientes introducciones al mercado han añadido asistencia a sus productos con

la finalidad de proveer soporte adicional para resolver aquellos componentes que son

difíciles de virtualizar. Así Intel® introdujo Intel® VT y AMD® introdujo AMD®-V. Estas

tecnologías expanden las posibilidades de virtualización mediante la adicción de 9

instrucciones al CPU que pueden ser utilizadas para administrar las máquinas

virtuales con ayuda directa del CPU.

Una de las primeras implementaciones en el mercado fue VMware®. Es así que en

1999 VMware® lanzó al mercado el primer producto de virtualización para estaciones

de trabajo x86 posteriormente extendida para servidores creando así un nuevo

mercado para la virtualización de servidores. VMware implementó en su software un

entorno 'fully virtualized' o de virtualización completa. Desde el lanzamiento de éste

primer producto, VMware® marcó su hegemonía en el mercado.

Por otro lado, otras ofertas de virtualización fueron desarrolladas; así por ejemplo se

tiene a compañías como SWsoft que lanzaron su producto Virtuozzo® para Linux en

2001; más adelante se fundaron Virtual Iron® (2003) y PlateSpin® Ltd. (2003). En

2005 Parallels®, Inc. Introdujo al mercado Parallels Workstation®, usado

principalmente en PCs y Parallels Desktop® for Mac, para Mac OS X, en 2006.

Sin embargo, dos hechos comenzaron a cambiar el espacio de mercado de la

virtualización de servidores convirtiéndolo en un campo de juego competitivo: El

software open source y Microsoft®.

Así aparece en 2003 un proyecto open source sobre virtualización de servidores

conducido por la Universidad de Cambridge. Este proyecto trajo consigo el

lanzamiento de la solución de virtualización open source: Xen®.

En 2006, el proyecto Xen® dio como resultado un hypervisor robusto, el Xen® 3.0.

Esta distribución fue desarrollada para tomar ventaja del hardware Intel® VT y

AMD®-V mejorados para virtualización (pudiendo usar paravirtualización y

virtualización completa). Con ello, Xen® llegó a posicionarse en el mercado

convirtiéndose en un hypervisor ampliamente usado y disponible gratuitamente. De

esta manera Xen®, captó la atención de los grandes de la industria de servidores

como IBM®, Sun®, HP®, y Novell®.

Figura 1.2 Línea de tiempo en el desarrollo de la virtualización en el hardware x86. Fuente: Focus Consulting

Dado que Xen® está licenciado bajo GPL el código no puede cerrarse, y no es solo

Xensource4 (a través de la Universidad de Cambridge) quien mantiene el código, sino

que varias empresas importantes como IBM®, Sun® (implementado Sun® xVM

Server.), HP®, Intel®, AMD®, Redhat® y Novell® están sumamente involucradas en

el desarrollo asignando programadores al mantenimiento de este software.

Por otra parte Microsoft®, sin quedarse atrás, adquirió en 2003 la compañía

Connectix®, encargada de desarrollar algunos productos de virtualización incluyendo

Virtual PC® para Mac, Virtual PC® para Windows, y un producto de virtualización de

servidores. Así Microsoft® entre 2004 y 2005 lanzó su hypervisor Virtual Server

comenzándolo a distribuir gratuitamente en 2006.

Este hecho anterior, al que se añadía la gratuidad de Xen®, influyó para que

VMware® y otros fabricantes sigan la tendencia de liberar algunos productos de su

línea de virtualización.

En 2008 Microsoft® lanza al mercado el Microsoft® Hyper-V™ Server® 2008, una

versión de su sistema operativo Windows Server 2008 el cual incluye el software de

virtualización Hyper-V™.

La virtualización de servidores ha logrado escalar significativamente en el espacio

empresarial sin embargo su implementación en el hardware x86 presentó grandes

restos y dificultades que cada uno de los mencionados fabricantes tuvieron que

afrontar.

Lograr virtualizar el hardware x86 no fue una tarea fácil y será explicada más

adelante en el presente trabajo de investigación.

4 El proyecto de investigación Xen® fue liderado por Ian Pratt, quien luego formó una empresa -junto con otras personas- para dar servicios de valor agregado como soporte, mantenimiento y capacitación sobre Xen® en Enero de 2005. Esta empresa es Xen source Inc. ahora propiedad de Citrix ®.

1.2. CONCEPTO

Una vez conocidos los elementos que fundamentaron la virtualización a través de su

posicionamiento histórico como una solución tecnológica en pro de la eficacia y

eficiencia, es posible ahora precisar un concepto de ésta:

El término de virtualización, en el campo de la informática, se refiere a la abstracción

de los recursos necesarios de un computador con el propósito de crear una versión

virtual de un dispositivo o recurso. Esta abstracción logra ocultar los detalles técnicos

de la virtualización mediante la encapsulación, para esto se crea un interfaz que

esconda la implementación mediante la combinación de recursos en locaciones

físicas diferentes, o por medio de la simplificación del sistema de control.

En una manera general la virtualización crea una capa de abstracción entre el

hardware de la máquina física y un sistema operativo virtual, esto logra que, aunque

físicamente se trate de un solo equipo, lógicamente se observen varios equipos. La

virtualización permite montar un sistema operativo virtual sobre una máquina física

anfitriona, es posible montar una gran diversidad de sistemas diferentes al mismo

tiempo, siendo el único limitante la capacidad de la máquina física. El sistema

operativo virtual, junto con el hardware que emplea recibe el nombre de máquina

virtual.

Figura 1.3 Representación de la virtualización en la que se encuentran muchas máquinas en un solo computador.

“Una máquina virtual (MV) es un duplicado de una máquina real, eficiente y aislado”5.

Esta definición de máquina virtual dice que: al ser un duplicado de una máquina real,

su comportamiento debe ser exactamente igual a una, considerando los recursos que

tenga asignados; al ser eficiente, su velocidad de ejecución debe de aproximarse a

una máquina física; y al ser aislada, todas las máquinas virtuales serán

independientes unas de otras, permitiéndose la ejecución simultánea. Se debe

destacar que aunque sean independientes todas aprovechan el hardware disponible

en la máquina anfitriona, además, los elementos principales de hardware de los que

necesita son solamente microprocesador, memoria RAM, disco y tarjeta de red.

Figura 1.4 Arquitectura de la virtualización

1.3. TIPOS DE VIRTUALIZACIÓN

En el presente trabajo de investigación se dará un énfasis mayor a la virtualización de

servidores y sus tipos; sin embargo como en la actualidad existen diversas formas de

virtualización, se ha creído pertinente dar un vistazo general a los diferentes tipos

existentes.

5 Gerald J. Popek and Robert P. Goldberg. Formal requirements for virtualizable third generation architectures. CACM, 17(7):413–421, 1974.

Las clases de virtualización pueden clasificarse de acuerdo a como se lleva a cabo su

proceso, es decir, que es lo que se busca simular para lograr el resultado deseado.

En el presente documento, para obtener una clasificación general se dividió a la

virtualización de acuerdo a si ésta se realizará para recursos específicos del sistema

computacional u orientada a la plataforma misma del sistema a través de máquinas

virtuales.

Es en este último tipo de virtualización donde la virtualización de servidores toma

lugar, tal como se verá posteriormente.

1.3.1. VIRTUALIZACIÓN DE RECURSOS

Este tipo de virtualización es aquel en el que el proceso de virtualización se da en

ciertos recursos específicos los que se emplearán para mejorar algunas

características determinadas de un sistema computacional. Así por ejemplo, es muy

común el hablar de la Virtualización de Almacenamiento, la cual es muy usada en las

Redes de Área de Almacenamiento (SAN6).

Este tipo de virtualización permite tanto agrupar diversos dispositivos de manera que

sean vistos por agentes externos como uno solo7, o dividir un recurso específico en

varios recursos del mismo tipo que se puedan considerar independientes8.

De acuerdo a los criterios presentados anteriormente, se puede hablar de diversos

tipos de virtualización de recursos, siendo los más importantes los que se presentan a

continuación.

1.3.1.1. Virtualización de Almacenamiento

La virtualización de almacenamiento es aquella que busca soluciones para brindar un

almacenamiento de alto rendimiento; para dicho fin se realiza una abstracción lógica

6 Storage Area Network.

7 Se generan los denominados clúster o grid, es decir que se combinan diversas computadoras para crear una supercomputadora.

8 Uno de los ejemplos más claros se da en la división del recurso Ancho de Banda.

del almacenamiento físico9. Este tipo de abstracción es altamente usado en las

Redes de Área de Almacenamiento (SAN) como método para distribuir la carga de

sus servidores. En este tipo de redes se extrae el concepto de almacenamiento de las

computadoras para añadirlo a la red en sí.

Para su funcionamiento se combinan discos físicos en las denominadas storage

pools10, el recurso de almacenamiento que contienen estas piscinas puede ser

dividido en volúmenes lógicos que se vendrían a comportar como particiones de

disco.

Con esto se logra que varios dispositivos de almacenamiento independientes

aparenten ante un usuario cliente como un único dispositivo con capacidad de ser

administrado localmente.

Se puede catalogar a la virtualización de almacenamiento en tres grupos, de acuerdo

al lugar exacto en que se realice la virtualización en sí, pudiendo ser: Virtualización

basada en el Dispositivo, Virtualización basada en la Red, y Virtualización basada en

el Host.

1.3.1.1.1. Virtualización basada en el Dispositivo

En este tipo, la virtualización se realiza en arreglos de dispositivos de

almacenamiento. Cada host dispone de un dispositivo virtual, el mismo que se

encuentra relacionado con una ubicación física dentro del arreglo de dispositivos de

almacenamiento.

1.3.1.1.2. Virtualización basada en la Red

En este tipo, la virtualización se realiza en la misma red, en la cual se emplean

switches inteligentes u otros equipos de virtualización. Esta categoría se emplea

9 Se separa el almacenamiento lógico del físico

10 Grupos de discos de almacenamiento a los que los clientes acceden para obtener información

principalmente para permitir la interacción de equipos de almacenamiento de distintas

casas comerciales que no puedan comunicarse entre sí de una manera directa.

1.3.1.1.3. Virtualización basada en el Host

En este tipo, la virtualización se realiza en el host (computador terminal del cliente).

Este computador tiene que disponer de cualquier tipo de software que permita el

virtualizar su almacenamiento tanto a través de la red como a través de los

dispositivos de almacenamiento. Esto brinda independencia de la red y de los

equipos.

1.3.1.2. Virtualización de Redes

La virtualización de redes permite la partición lógica o segmentación de una única red

física para usar los recursos de la red. Este tipo de virtualización trata a todos los

servicios en la red como un único grupo de recursos que pueden ser accedidos sin

considerar sus componentes físicos que la dan lugar.

Se pueden tener varios tipos de virtualización de redes entre los que se puede

mencionar principalmente: VLAN´s, VIP, VPN´s.

1.3.1.2.1. Virtual LAN (VLAN)

Este tipo de virtualización ha sido ratificado por la IEEE en su estándar 802.1Q. Su

funcionamiento consiste en un método para crear redes independientes a nivel lógico

mediante la compartición de la red a nivel físico. Su uso permite segmentar

lógicamente los dominios de broadcast controlando la interacción entre los

dispositivos de diferentes segmentos de red.

Brinda a los administradores de red la posibilidad de conectar múltiples dispositivos al

mismo switch pero posibilitando aislarlos unos de otros a través de la configuración

de segmentos de red mediante VLAN’s. Cada segmento utilizará una parte de los

recursos disponibles del switch (CPU, memoria, ancho de banda, etc.).

1.3.1.2.2. Virtual IP (VIP)

Virtual IP o IP Virtual constituye una dirección IP que no está conectada a un

computador específico o tarjeta de red (NIC) de un dispositivo.

Las VIPs son asignadas a dispositivos de red que se encuentran en el camino a

través del cual atraviesa el tráfico de la red. Todos los paquetes entrantes son

dirigidos a la IP Virtual pero luego redirigidos a la interface de red del dispositivo

receptor. VIP es usado frecuentemente en escenarios para brindar redundancia y

balanceo de carga donde múltiples sistemas están albergando una aplicación común.

Una dirección VIP podrá estar disponible aún si el equipo o NIC falla debido a que un

equipo alterno o NIC alterna responderá a las conexiones.

1.3.1.2.3. Virtual Private Network (VPN)

Una VPN constituye una red de comunicación privada usada para la transmisión de

datos de forma confidencial, íntegra, auténtica y segura sobre una red pública.

El tráfico VPN es a menudo transportado sobre un medio de red altamente inseguro,

como Internet, por lo que se crea un canal seguro para la información confidencial y

sensitiva a ser transmitida de un sitio a otro.

Para el establecimiento de la conexión, usualmente es necesario algún tipo de

software, sin embargo una vez establecida la conexión, la interacción con los

dispositivos del sistema privado es como si se la estuviera realizando

presencialmente sin requerir ninguna clase de modificaciones del sistema operativo

de la red.

1.3.2. VIRTUALIZACIÓN DE PLATAFORMA

Como se ha mencionado anteriormente, la virtualización puede ser clasificada de

acuerdo a si ésta se orienta a los recursos o la plataforma. La virtualización de

recursos como se ha podido explicar permite agrupar varios recursos para que éstos

sean vistos como uno solo, o al revés, dividir un recurso en múltiples recursos

independientes.

Por otra parte la virtualización de plataforma11, se encarga de brindar uno o más

entornos computacionales aproximadamente iguales al de una máquina real (servidor

o PC) con todos sus componentes necesarios: procesador, memoria, dispositivos de

entrada y salida, etc. (de acuerdo a lo que se requiera), y sobre la cual se puede

cargar un software, sistema operativo, aplicaciones, etc.

Así de esta manera, la tecnología de virtualización de plataforma permite a un equipo

computacional funcionar como si éste fuera dos o más plataformas independientes,

cada uno de manera “no física” es decir “virtualizada”. Estos entornos son más

comúnmente conocidos como máquinas virtuales o en inglés Virtual Machines (VM’s).

Para dar lugar al funcionamiento a ésta técnica, las características del hardware físico

deben ser recreadas a través del uso de software. Así cada uno de los entornos

virtuales es provisto de una arquitectura básica, la misma que un computador físico

genérico. Esto es logrado por una capa de software llamada capa de abstracción.

La Abstracción tanto en cuanto hace referencia a la virtualización, es la

representación de un set común de dispositivos hardware los cuales son enteramente

basados en software. Es decir, se trata básicamente de software que luce y actúa

como hardware. Así de esta manera, se permite la instalación de software en

hardware que realmente no existe, hardware que está virtualizado.

La virtualización de plataforma es aplicada en algunas líneas como virtualización de

aplicaciones, escritorio y la que compete en el presente trabajo de investigación: la

virtualización de servidores.

11 Una plataforma es precisamente el principio, en el cual se constituye un hardware, sobre el cual un software puede ejecutarse/desarrollarse.

1.3.2.1. Virtualización de Aplicaciones

La virtualización de aplicaciones es aquella que busca separar el entorno de

aplicación del sistema en sí. Para lograr esto, debe correr aplicaciones de servidor de

manera local, es decir que el equipo cliente empleará un sistema de virtualización

adecuado para ubicar aplicaciones y datos necesarios en lugar de realizar el proceso

de instalación tradicional en cada cliente. Con esto, cada equipo local empleará sus

propios recursos para correr una aplicación que no se encuentra propiamente

instalada en el cliente.

Para su funcionamiento las aplicaciones deben correr en un entorno virtual que actúe

como una capa entre la aplicación y el sistema operativo. Este entorno debe contener

todos los componentes necesarios para ejecutar la aplicación, por ejemplo entradas

de registros, archivos, objetos globales, entre otros.

En este tipo de virtualización las aplicaciones se consideran como servicios bajo

demanda que emplean los recursos del cliente sin estar instalados en el mismo y que

son independientes del sistema operativo en uso.

1.3.2.2. Virtualización de Escritorio

La virtualización de escritorio es aquella que permite la separación del medio de

procesamiento y almacenamiento local del escritorio del usuario y la máquina

personal que hace uso. Este tipo de virtualización da lugar a que el procesamiento y

almacenamiento de los datos del usuario se lo realice en un servidor central que

virtualiza su escritorio.

Mediante esta técnica de virtualización, el usuario utiliza en lugar de su PC de

escritorio, un thinclient12 constituido de monitor, teclado y mouse para su interacción

con el servidor. La experiencia obtenida por el usuario es orientada a que sea

12 Un thinclient es un dispositivo que depende primariamente del servidor central para las tareas de procesamiento, y principalmente se enfoca en transportar la entrada y la salida entre el usuario y el servidor remoto.

prácticamente la misma que si estuviera utilizando su computador personal estándar

pero desde un dispositivo thinclient o similar.

Es muy útil cuando las aplicaciones de usuario involucran tareas de contabilidad,

correo electrónico, procesadores de texto, y web browsers. Así de esta manera la

compañía puede ahorrar recursos en la provisión de computadores personales cada

vez más potentes y cuyo poder sería inutilizado en gran parte.

1.3.2.3. Virtualización de Equipos y Servidores

La virtualización de equipos y servidores es aquella que es capaz de correr una o

varias máquinas virtuales sobre una única pieza de hardware. Es decir que, en

términos generales, posibilita correr diversos equipos o servidores sobre un sistema

anfitrión.

La limitación del número de equipos virtuales que se pueden correr simultáneamente

viene dada por las capacidades de hardware y software del equipo anfitrión, se debe

considerar que cada máquina virtual es lógicamente independiente del resto y debe

acceder a una parte del hardware del equipo anfitrión.

Al ser independientes, estas máquinas virtuales pueden correr sus propios paquetes

de aplicaciones sobre un sistema operativo propio sin correr el riesgo de

incompatibilidades con los paquetes de aplicaciones o el sistema operativo

anfitriones.

Este tipo de virtualización es uno de los más importantes y usados, además de ser el

tipo de virtualización que se desarrollará en la presente tesis, esto es debido a que es

el único tipo de virtualización capaz de correr una máquina virtual completa que

pueda funcionar independientemente.

1.3.2.3.1. Arquitectura general

Para poder presentar la arquitectura de este entorno computacional virtualizado, se

presentará a continuación una comparación general de la organización básica de una

plataforma computacional física con la organización de un sistema computacional

corriendo una plataforma virtualizada.

La constitución de un computador típico hace referencia a un conjunto de hardware

(CPU, memoria, disco, dispositivos de red, etc.) sobre el cual es instalado un sistema

operativo (Windows®, GNU Linux, etc.) y una o más aplicaciones instaladas sobre

dicho sistema.

La figura 1.5 inferior hace referencia a lo mencionado:

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Sistema Operativo

(Linux, Solaris, Windows, etc)

Hardware Físico

(CPU, Memoria, Discos, Red, etc)

Figura 1.5 Constitución básica de un computador típico. Fuente: Auerbach, Advanced Server Virtualization.

Por otro lado, dentro de un servidor o una PC que alberga una plataforma de

virtualización, la constitución del sistema es diferente. Así, en una primera

arquitectura virtualizada, el sistema operativo Host OS (que es instalado

directamente sobre el hardware real), posee una plataforma de virtualización

instalada; dentro de ésta una o más máquinas virtuales son creadas.

Cada máquina virtual actúa como un set separado de hardware y es capaz de tener

un sistema operativo -Guest OS- y aplicaciones instaladas en cada una de éstas de

manera independiente. La figura 1.6 hace referencia a lo mencionado.

Otro arreglo de un sistema computacional virtualizado es aquel en el cual la

plataforma de virtualización es instalada directamente sobre el hardware físico. Esta

forma de virtualización provee una plataforma sobre la cual una o más máquinas

virtuales pueden ser creadas, cada una capaz de tener su propio sistema operativo y

aplicaciones instaladas. Esta arquitectura es mostrada en la figura 1.7.

Máquina Virtual Máquina Virtual

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Sistema Operativo

Hardware Virtual Hardware Virtual

Capa de Virtualización

(Monitor de Máquina Virtual / Hypervisor)

Sistema Operativo

Hardware Físico

Figura 1.6 Arquitectura 1 de una plataforma virtualizada. Fuente: Auerbach. Advanced. Server Virtualization.

Máquina Virtual Máquina Virtual

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Aplicaciones

de Software

Sistema Operativo

Hardware Virtual Hardware Virtual

Capa de Virtualización

(Monitor de Máquina Virtual / Hypervisor)

Hardware Físico

Figura 1.7 Arquitectura 2 de una plataforma virtualizada. Fuente: Auerbach, Advanced Server Virtualization.

1.3.2.3.2. Virtual Machine (VM) o Máquina Virtual

Como se ha podido mencionar anteriormente, una parte constitutiva de la arquitectura

de virtualización de servidores es la llamada máquina virtual.

Una máquina virtual es un entorno lógico creado dentro de un entorno físico (equipo

computacional) provisto de hardware virtualizado -no real- necesario para permitir el

funcionamiento eficiente de software instalado sobre éste tal como lo haría sobre el

hardware real de un equipo físico.

El hardware virtual de una VM puede ser emulado e igual al hardware subyacente o

puede emular a hardware estándar para su funcionamiento. Así, estos entornos

computacionales –VM´s- cuentan con todos sus componentes necesarios

virtualizados: procesador, memoria, dispositivos de entrada y salida, etc. (de acuerdo

a lo que se requiera), y sobre la cual se puede cargar un software, sistema operativo,

aplicaciones, etc.

1.3.2.3.3. Hypervisor o Virtual Machine Monitor (VMM)

Otro componente fundamental de la arquitectura servidor virtualizado es una

plataforma de virtualización sobre la cual se proporciona funcionamiento total a las

máquinas virtuales; de una manera que el usuario pueda crear varias VM´s

presentando a cada una de ellas una interfaz del hardware que sea compatible con el

sistema operativo elegido. Este componente de abstracción es llamado Virtual

Machine Monitor (VMM) o hypervisor.

Existen dos clases de hypervisor; así se tiene: el que corre directamente sobre el

hardware físico de la máquina (figura 1.7) denominado tipo ‘Non hosted’ o de

traducción binaria, y el que corre sobre un sistema operativo anfitrión -Host OS-

(figura 1.6) denominado tipo ‘Hosted’.

Ambos tipos de hypervisor proveen dos funciones básicas. Primero, identifica

´traps´13, maneja, gestiona y distribuye dinámicamente CPU, memoria, red,

13 Instrucciones generadas por la máquina virtual para solicitar recursos del sistema. Ej.: System call, Memory access, Clock interrupt, etc.

almacenamiento y responde a operaciones de CPU protegidas o privilegiadas hechas

por cada máquina virtual. Segundo, maneja el encolamiento, scheduling14, y el

retorno de los resultados a las solicitudes hechas al hardware desde las VM´s. Es

decir, el VMM es la parte de ésta arquitectura de virtualización que se encarga de

manejar los recursos del sistema principal exportándolos a la máquina virtual.

1.3.2.3.4. Sistema Operativo Anfitrión (Host OS)

En la arquitectura de servidor virtualizado se puede encontrar directamente sobre el

hardware real un sistema operativo en el cual se da lugar a la instalación del

hypervisor tipo ‘Hosted’. Este sistema es llamado ‘Host OS‘ o sistema operativo

anfitrión y constituye el sistema operativo principal del servidor.

1.3.2.3.5. Sistema Operativo Visitante (Guest OS)

Otro elemento fundamental en la arquitectura de servidor virtualizado es el sistema

operativo de la máquina virtual. Las máquinas virtuales casi siempre albergarán una

instalación de un sistema operativo (GNU Linux, Windows®, etc.) y sobre éstos

aplicaciones. Estas instalaciones de sistema operativo son conocidas como Guest OS

(sistema operativo visitante).

1.3.2.3.6. Hardware Real o físico

Se tiene diferentes arquitecturas sobre las cuales se puede implementar servidores

virtualizados como por ejemplo arquitecturas x86, x86-64, PowerPC, MIPS, SPARC,

etc. Estas ofertas se las ha podido encontrar algunas variaciones, como soluciones

de sistemas especializados de alto rango, rango medio y de alto, mediano y bajo

costo.

Indudablemente el hardware x86 es el de menor costo, motivo por el cual se ha

tomado ventaja de ésta característica para el desarrollo tanto de hypervisors

14 Scheduling hace referencia a la manera como los procesos son asignados a correr en CPU disponible. Esta asignación es llevada a cabo por un scheduler.

específicos como de hardware especializado que permita dar a lugar a servidores

virtualizados de alto rendimiento y bajo costo sobre hardware x86.

Es así que Intel y AMD han desarrollado extensiones de virtualización para la

arquitectura x86; éstos son los procesadores Intel VT15 o Vanderpool y AMD-V16 o

Pacífica. Los procesadores mencionados permiten dar soporte a virtualización de

sistemas operativos no modificados (necesario en la paravirtualización), lo cual

amplía las soluciones de virtualización asistida por hardware.

El hardware real es fundamental en la determinación del hypervisor adecuado para

su virtualización; existen distintas distribuciones de hypervisor dependiendo de la

plataforma subyacente que se utilice. Así por ejemplo para el caso de la arquitectura

x86 se dispone de hypervisors como VMware (que puede correr sobre Windows®,

Linux, Bare Metal17), Hyper-V™ (que corre sobre Windows®) o Xen (que puede correr

sobre Linux, Bare Metal), etc.

1.3.2.3.7. Alternativas de Virtualización de Servidores (1) (2)

Existen diversas posibles implementaciones de virtualización de servidores,

pudiéndose clasificar en cuatro diferentes categorías claramente identificadas:

Virtualización de Sistema Operativo, Virtualización Nativa o Híbrida, Virtualización

Completa y Paravirtualización. Cada una de ellas con sus ventajas y desventajas

propias por lo que pueden resultar adecuadas o erróneas según la aplicación

requerida.

1.3.2.3.8. Virtualización de Sistema Operativo

Este tipo de virtualización realiza una virtualización completa al nivel del sistema

operativo, creando múltiples instancias del mismo. Cada instancia o entorno virtual

creado dispone de un ambiente propio con sus recursos de: memoria, CPU, ancho de

15 Revisar anexo A.

16 Revisar anexo A.

17 Hace referencia a que puede correr directamente sobre el hardware físico.

banda, entre otros, previamente asignados. Por este motivo las aplicaciones que

corran sobre una máquina virtual la considerarán como un sistema autónomo.

Tiende a ser muy eficiente, llegando a velocidades cercanas a la nativa, además sólo

se requiere de una única instalación de sistema operativo (en la máquina nativa) y es

compatible con todo el hardware que el sistema operativo anfitrión soporte.

Sin embargo el mismo kernel del sistema operativo de la máquina anfitriona es

empleado para cada máquina virtual. Esto quiere decir que el sistema operativo

anfitrión se “comparte” con las máquinas virtuales, cada una de las cuales tendrá su

propia copia del mismo. Por este motivo, la máquina virtual deberá tener el mismo

sistema operativo que la máquina anfitriona.

Este no es el único problema que hace que este tipo de virtualización no sea muy

usada. También se considera que la máquina virtual no queda tan aislada y segura

como en los otros tipos de virtualización, debido a que no se puede identificar

fácilmente las fuentes de cargas en los recursos, y que añade una sobrecarga y

complejidad por cuanto se emplea un sistema operativo completo en cada máquina

virtual en lugar de un micro-kernel18.

Como ejemplos de este tipo de virtualización se puede mencionar a Solaris

Conteiners para entornos Solaris, a Linux-VServer para entornos Linux, y a Virtuozzo

para entornos de Linux y Windows19.

1.3.2.3.9. Virtualización Completa

La virtualización completa es una de las técnicas de virtualización más usadas que se

caracteriza por brindar una simulación completa de todo el hardware disponible en el

equipo anfitrión. De esta forma se consigue que todo paquete de aplicaciones que

18 El término de Micro-kernel se refiere a una versión mínima de un kernel (núcleo) que brinda los mecanismos necesarios para la implementación de un sistema operativo como manejo de espacios de direccionamiento de nivel bajo, administración de hilos y comunicación entre procesos. Se suelen usar como Hypervisors

19 No se pueden correr ambos sistemas operativos, debe ser Linux sobre Linux o Windows sobre Windows

pueda correr en el hardware nativo, también podrá correr en sus máquinas virtuales;

además se logra que los sistemas operativos puedan ser instalados en las máquinas

virtuales sin modificación alguna, por esta razón se considera que posee el más

amplio rango de soporte para los sistemas operativos virtuales.

Este tipo de virtualización puede llegar a tener un rendimiento de CPU y memoria

cercana al del equipo nativo, además cada máquina virtual corre bajo su propio kernel

lo que aísla completamente cada máquina virtual del controlador de las mismas. En el

siguiente tema de este capítulo se tratará más a detalle las características y

arquitectura de la virtualización completa así como de la paravirtualización y

virtualización híbrida.

Como ejemplos de plataformas que dan lugar a este tipo de virtualización se puede

mencionar a VMware Workstation, VMware GSX server, Parallels Desktop, Virtual

Iron, Mac-on-Linux, Win4BSD, entre otros.

1.3.2.3.10. Paravirtualización

La paravirtualización es una técnica de virtualización que provee simulación parcial

del hardware subyacente. La mayoría, pero no todas, de las características son

simuladas.

Es capaz de proveer grandes mejoras en rendimiento referente a la virtualización de

servidores frente a otras soluciones de virtualización; para dar lugar a esta

característica, requiere de la modificación del o los sistemas operativos a correr sobre

el hypervisor.

Este hecho deja de lado al overhead asociado con la emulación requerida por otros

tipos de virtualización basados en hypervisor (como la virtualización completa) lo cual

optimiza su rendimiento.

Como ejemplo de plataformas que emplean paravirtualización tenemos a Xen®

(constituye su modelo principal aunque también emplea virtualización asistida por

hardware), VMware ESX®, VMware ESXi®, entre otros.

1.3.2.3.11. Virtualización Nativa o Virtualización Híbrida

Éste es el más reciente tipo de virtualización orientado a la virtualización de la

arquitectura x86. Es a menudo referido como virtualización ´híbrida´. Constituye una

combinación de la virtualización completa o de la paravirtualización en conjunto con

técnicas de aceleración de I/O y memoria20. Permite sacar ventaja de las últimas

tecnologías de la arquitectura x86, Intel VT y AMD-V diseñadas para virtualización

asistida por hardware.

Su funcionamiento es similar al de la virtualización completa, es así que los sistemas

operativos pueden ser instalados sin una modificación previa. Éste tipo de

virtualización maneja instrucciones ´no virtualizables´ por el uso de ´trap and-

emulate´21 en el hardware versus software.

La virtualización nativa emplea éstas técnicas de aceleración de I/O y memoria de

manera selectiva de acuerdo a la necesidad. Además soporta arquitectura de 64 bits

para ciertos sistemas operativos; tiene el mayor rendimiento de CPU, memoria, y I/O

de todos los tipos de virtualización x86.

Sin embargo requiere de una arquitectura de CPU capaz de soportar aceleración

asistida de hardware (Intel I/OAT). A esto se añade el requerimiento de modificar

algunos sistemas operativos para guest´s paravirtualizados, sin embargo en menor

número que con la paravirtualización pura.

20 Intel® I/O Acceleration Technology (Intel® I/OAT), es un componente de Intel® Virtualization Technology for Connectivity, el cual mejora el tráfico de datos a través de la plataforma para beneficiar el rendimiento del sistema.

21 Es el proceso por medio del cual el CPU es capaz de capturar (‘trap’) las instrucciones que varios sistemas operativos en máquinas virtuales deseen procesar (cada OS por naturaleza fue diseñado para tener control total del sistema), permitiendo al VMM emular (‘emulate’) el efecto que es deseado por el OS pero en forma que no interfiera con otro OS.

1.4. VIRTUALIZACIÓN DE SERVIDORES: VIRTUALIZACIÓN

COMPLETA, PARAVIRTUALIZACIÓN Y VIRTUALIZACIÓN

HÍBRIDA

El centro de datos actual, exige cada vez más la provisión de servidores optimizados

altamente confiables, seguros, disponibles, eficaces y eficientes y además que

permitan el ahorro de recursos como: equipos computacionales, cableado

estructurado, dispositivos de conectividad, equipos de refrigeración, energía, tiempo

de mantenimiento, personal de mantenimiento, etc. Es decir se busca obtener los

mayores resultados positivos con el menor número de recursos empleados lo cual se

traduce en mayores beneficios para las organizaciones.

La virtualización es una de las tecnologías actuales que permiten hacer más con

menos. En este caso en el campo de los servidores, la implementación de servidores

virtualizados en el centro de datos contribuye significativamente a dar lugar la

obtención de las premisas antes mencionadas.

Como se ha podido explicar en los temas anteriores del presente capítulo, la

virtualización de servidores forma parte de la virtualización de plataforma y existen

varias soluciones tecnológicas para su implementación, así tenemos las más usadas:

virtualización completa, paravirtualización y virtualización híbrida.

En el presente tema se enfocará con mayor detalle las características, ventajas y

desventajas de la utilización de cada uno de estos tipos de virtualización referentes a

la virtualización de servidores.

1.4.1. VIRTUALIZACIÓN COMPLETA

Como se mencionó en el capítulo anterior este tipo de virtualización se basa en la

simulación total del hardware del equipo anfitrión para brindarlo a sus máquinas

virtuales.

En la actualidad es uno de los tipos de virtualización más usados, principalmente

debido a que tiene un amplio rango de soporte de sistemas operativos y es la técnica

empleada por la empresa VMware que es la más representativa en los que a

virtualización se refiere.

1.4.1.1. Características

En el caso de la virtualización completa, se puede considerar que posee tres

características principales: el empleo de un Hypervisor, que cada máquina virtual

corre sobre su propio kernel, y que requiere de una simulación completa de todo el

hardware disponible en el sistema anfitrión.

1.4.1.1.1. Hypervisor

Tanto la virtualización completa como la paravirtualización hacen uso de esta

herramienta. Se trata de un monitor de máquina virtual (VMM22) que corre sobre el

hardware de la máquina anfitriona y actúa como capa intermedia entre la misma y las

máquinas virtuales.

Principalmente se define al hypervisor como el encargado de cumplir dos funciones

básicas. La primera consiste en identificar atrapar y responder a cualquier operación

privilegiada o protegida del CPU que sea hecha por alguna máquina virtual. La

segunda consiste en hacerse cargo de los procesos de encolamiento, despacho y

retorno de resultados de peticiones de hardware hechas por una máquina virtual.

Su hypervisor se diferencia del usado en la paravirtualización en que el de la

virtualización completa incluye cierto código para emular el hardware de la máquina

anfitriona en cuanto sea necesario. Esto permite el correr sistemas operativos sin

modificaciones sobre el hypervisor

1.4.1.1.2. Kernel de las Máquinas Virtuales

Al contrario de la virtualización de Sistema Operativo, la virtualización completa

brinda una especie de microkernel a cada una de sus máquinas virtuales. Esta

característica también es compartida por la paravirtualización, y permite brindar un

22 Por sus siglas en inglés: Virtual Machine Monitor

aislamiento total entre las máquinas virtuales y su VMM, es decir que cada máquina

virtual es capaz de correr un distinto sistema operativo, siendo el único limitante la

capacidad del hardware del equipo anfitrión.

1.4.1.1.3. Simulación Completa de todo el Hardware anfitrión

Esta es la característica que brinda la diferenciación con respecto a la

paravirtualización. La virtualización completa simula de una forma total el hardware

que dispone el equipo anfitrión. Esto hace que todo el software que puede correr

sobre el hardware anfitrión, podrá correr sobre las máquinas virtuales.

La unión de estas tres características hace que la virtualización completa sea el tipo

de virtualización con mayor soporte de sistemas operativos a instalarse en máquinas

virtuales y a que provea un rendimiento, tanto de memoria como de CPU, cercano al

de la máquina nativa. Sin embargo, se debe considerar que ciertas llamadas

privilegiadas del sistema operativo no pueden ser atrapadas, por lo que se requiere

de técnicas especiales de atrapado y emulación que pueden afectar el rendimiento

del sistema, además de requerir un balance adecuado entre los elementos de

hardware y software.

1.4.1.2. Arquitectura

En la arquitectura de la virtualización completa, el monitor de máquinas virtuales

(VMM) o hypervisor corre sobre el hardware de la máquina anfitriona, y cada máquina

virtual correrá directamente sobre dicho hypervisor.

Cada máquina virtual se encuentra formada por su sistema operativo propio, y las

aplicaciones que corren sobre este. Además, para la correcta administración de la

infraestructura virtual se añade un sistema operativo de administración que, al igual

que los de las máquinas virtuales, también corre sobre el hypervisor.

La arquitectura de este modelo de virtualización se detalla a continuación en la figura

Figura 1.8 Arquitectura de la virtualización completa.

En la figura 1.9 se detalla un ejemplo del sistema de virtualización completo, en el

que se observa que sobre el hardware, con la ayuda del sistema de administración,

se desarrolla una infraestructura virtual con su sistema de almacenamiento,

servidores, redes, entre otros. Dicha infraestructura se encuentra dividida en las

distintas máquinas virtuales.

Figura 1.9 Infraestructura Virtual Completa.

Hardware

Hypervisor (VMM)

SO Virtual

(Sin Modificaciones)

Aplicaciones

SO Virtual

(Sin Modificaciones)

Aplicaciones

Interfaz de Administraci

1.4.2. PARAVIRTUALIZACIÓN

Como se pudo mencionar en los temas previos, la paravirtualización es un tipo de

virtualización que permite correr múltiples sistemas operativos simultáneamente

sobre el mismo hardware; esta tarea la cumple mediante un uso más eficiente de los

recursos del sistema, tal como procesador y memoria a través de una compartición

efectiva de recursos.

La paravirtualización constituye una alternativa de virtualización de gran rendimiento

debido a que corre un pequeño y ligero Virtual Machine Monitor o hypervisor sobre el

hardware. Éste maneja todos los recursos de bajo nivel destinados para las máquinas

virtuales, y provee una interfaz para que las aplicaciones administrativas de nivel más

alto puedan realizar varias de sus tareas administrativas.

Al contrario de la virtualización completa donde todo el sistema es emulado (BIOS,

disco, procesadores, NIC, etc.), en la paravirtualización solamente parte del hardware

subyacente es emulado. La abstracción creada con la paravirtualización

generalmente se traduce en que los sistemas operativos tendrán un mejor

desempeño que con un modelo de virtualización completa donde todos los elementos

deben ser emulados. Sin embargo, ésta eficiencia se obtiene a costa de flexibilidad y

seguridad.

La característica principal es el espacio de dirección de virtualización que es otorgado

a cada máquina virtual; teniendo su propio y único espacio de dirección.

Su implementación es más simple que con virtualización completa; sus Guest’s

paravirtualizados tienden a ser las máquinas virtuales de mayor rendimiento para red

y I/O de disco.

1.4.2.1.1. Modificación del Guest OS

La flexibilidad se pierde en la paravirtualización, debido a que el sistema operativo

que corre sobre una máquina virtual paravirtualizada requiere haber sido modificado

para poder trabajar con estas máquinas virtuales; esto significa que no todos los

sistemas operativos o distribuciones en particular pueden o no estar listas para ser

implementadas en esta solución.

La modificación del sistema operativo guest permite que éste pueda interactuar con el

hypervisor y así, las operaciones privilegiadas que el sistema operativo realizará en el

aro de protección 023 sean traducidos en ‘hypercalls’24 para el hypervisor.

Los cambios del sistema operativo, requerido para la interacción con el hypervisor, no

modifican la interfaz de aplicación binaria ABI25 (Application Binary Interface), y así

solamente el kernel y el código de nivel de kernel (tal como los drivers de

dispositivos) son los que requieren modificación para paravirtualización. Esto además

significa que las aplicaciones de usuario sobre el sistema operativo Guest no

requieren ser modificadas, lo cual es uno de los aspectos clave de un entorno de

virtualización.

1.4.2.1.2. Seguridad

En el campo de la seguridad, algo de ésta se pierde debido a que el sistema

operativo guest tiene mucho más control cercano del hardware subyacente;

23 Concepto usado en la arquitectura x86 para diferenciar los diferentes niveles de privilegios en cuanto al control de los recursos del sistema. El aro de protección 0 es el modo de ejecución en un procesador x86 en el cual se permite la ejecución de todas las instrucciones incluyendo instrucciones privilegiadas tal como de I/O y operaciones de manejo de memoria. Es en el aro 0 donde normalmente los sistemas operativos corren.

24 Constituyen un tipo especial de llamadas sincrónicas las cuales actúan como llamadas del sistema a pedidos de operaciones privilegiadas en el hypervisor.

25 ABI describe una interfaz de bajo nivel entre las aplicaciones y el sistema operativo. Abarca detalles como tamaño de los tipos de datos, convenciones de llamadas, llamadas de sistema, formato binario de archivos objeto, etc.

ligeramente se incrementa el riesgo de impactarlo y con ello el funcionamiento del

resto de sistemas Guest en el host.

1.4.2.1.3. Hypervisor

Con la paravirtualización se emplea el concepto de hypervisor o Virtual Machine

Monitor (VMM), el cual puede correr ya sea directamente sobre el hardware o sobre

un sistema operativo anfitrión. Sobre el hypervisor correrán las máquinas virtuales por

La característica de la VMM es brindar la capa de abstracción con el hardware y

también un sistema operativo de administración para que las máquinas virtuales

puedan comunicarse con el hypervisor; éste es usado para administrar las diferentes

instancias de VM´s.

El hypervisor es responsable del acceso directo al hardware del host físico anfitrión,

para el manejo de la memoria destinada y usada por cada dominio virtual.

Adicionalmente maneja los discos virtuales y el acceso a la red de todos los dominios

virtuales y del dominio de administración.

Entre las plataformas que emplean paravirtualización tenemos a Xen®, VMware

ESX®, etc.

1.4.2.1.4. Hypervisors de distintas plataformas

El hypervisor usado por VMware ESX® ejecuta el mismo set de instrucciones y

manejo que VMware Workstation (que emplea virtualización completa) pero provee

substancialmente mayor rendimiento debido a que corre a mucho más bajo nivel

cerca al hardware, evitando interactuar con procesos de nivel más alto.

Por otro lado, el hypervisor usado por Xen® es diferente. Éste requiere de la

modificación del sistema operativo guest. Las modificaciones del sistema operativo se

las realiza para impedir a instrucciones ´privilegiadas´ del sistema operativo, el uso de

un modelo de hardware abstracto que difiere del hardware específico que se

encuentra disponible en la máquina física, y las cuales pueden ejecutar con un nivel

inferior de privilegios que el hypervisor.

El hypervisor maneja la administración de memoria, manejadores de excepciones de

CPU, llamadas del sistema, interrupciones de hardware, timers, y todo el flujo de I/O

de los dispositivos.

La arquitectura empleada por la paravirtualización puede ser basada en los dos tipos

de hypervisor conocidos: hosted y non hosted.

A continuación se presenta un ejemplo de arquitectura de paravirtualización en base

al hypervisor non hosted y comparándolo con la arquitectura de virtualización

completa.

La arquitectura mencionada se observa en la figura 1.10:

Figura 1.10 Virtualización completa contra arquitectura de paravirtualización. En ambos casos,

existe una capa de software denominada monitor del equipo virtual (VMM), que incluye un

planificador de equipo virtual y ofrece gestión general de memoria y virtualización de entrada y

salida. El modelo de paravirtualización incluye interfaces API que asisten al equipo virtual en

algunos casos. Fuente: Virtualización en el Centro de Datos, Informe Técnico, Novell Inc. ©, Pág.

En esta arquitectura podemos observar al hypervisor corriendo directamente sobre el

hardware y sobre éste las máquinas virtuales.

Así como en el caso de la virtualización completa, en la paravirtualización se tiene un

sistema de administración de las máquinas virtuales (Dom 0 para Xen®), el cual corre

sobre el hypervisor como otra máquina virtual.

Ésta arquitectura se tratará con mayor detalle en el capítulo 3 del presente trabajo.

1.4.3. VIRTUALIZACIÓN HÍBRIDA

Como se mencionó en el punto 1.3.2.3.11., este tipo de virtualización es también

llamada nativa y se basa en una mezcla entre la virtualización completa y la

paravirtualización, empleando hardware especializado.

Este tipo de virtualización es considerado relativamente nuevo, apareciendo con los

nuevos avances de procesamiento que permiten brindar una aceleración asistida a la

virtualización clásica.

La principal novedad en este tipo de virtualización son los requerimientos de

hardware que posee, es decir que, para lograr su implementación requiere de un

procesador adecuado diseñado específicamente para brindar una virtualización

asistida por hardware.

1.4.3.2. Hardware Especializado

Desde la aparición del primer chip x86, la capacidad de procesamiento para los

computadores ha estado en constante evolución y cada fabricante ha ido añadiendo

sus propias funciones características. Hoy en día tanto Intel como AMD, los más

grandes fabricantes, ya disponen de procesadores que incluyen grupos de

instrucciones para facilitar la virtualización x86. AMD desarrolló su procesador AMD-V

(antes conocido como Pacifica), mientras que Intel desarrolló su Virtualization

Technology (VT).

Con estas nuevas tecnologías se busca extender las instrucciones de la arquitectura

x86 para evitar los problemas de emulación de instrucciones. Para esto, el sistema

operativo virtualizado obtiene la autoridad que requiere para acceder directamente a

la plataforma sin compartir control del hardware, es decir que se añade un modo que

permite al sistema operativo un funcionamiento normal, mientras que las peticiones al

hardware pasarán al mismo directamente. Es decir que el hypervisor podrá atrapar y

emular las operaciones que antes hubieran fallado. Esto permitirá que las máquinas

virtuales tengan mayor capacidad y escalabilidad y dispongan de un soporte x64.

La aparición de estos procesadores permite el diseño de soluciones de virtualización

x86 más simplificadas, ya que la comunicación directa entre los sistemas operativos

virtuales y el hardware hace que las necesidades computacionales sean realizadas

por el hardware. Sin embargo se debe mencionar que este tipo de virtualización

requiere que los sistemas virtuales a instalarse sean modificados, aunque no en un

menor grado que para la paravirtualización

La arquitectura que emplea la virtualización híbrida es la misma que la empleada en

la virtualización completa o en la paravirtualización. También se tiene el elemento del

hypervisor que corre sobre el sistema operativo nativo o directamente sobre el

hardware del equipo y las máquinas virtuales que se encuentran sobre el mismo.

Figura 1.11 Arquitectura de la Virtualización Híbrida.

Hardware

Hypervisor (VMM)

SO Virtual

(Sin Modificacion

Aplicaciones

SO Virtual

(Sin Modificacion

Aplicaciones

SO Virtual

(Sin Modificacion

Aplicaciones

1.5. OPCIONES DE SOFTWARE PARA VIRTUALIZACIÓN

En la actualidad existen diversas casas fabricantes que brindan soluciones de

virtualización, cada una de las mismas disponen de sus paquetes de software

enfocados a un tipo de virtualización específica con sus respectivas ventajas y

desventajas. En este apartado se considerarán algunos de estos paquetes de

software más conocidos.

1.5.1. SOFTWARE DE VIRTUALIZACIÓN MÁS USADO

Se puede considerar que las soluciones de virtualización más usadas provienen de

tres fabricantes específicos: VMware®, Microsoft Hyper – V™ y Xen® (adquirido por

Citrix). De estos tres, tanto VMware como Microsoft emplean una virtualización

completa, mientras que Xen se enfoca en la paravirtualización.

Figura 1.12 Software de Virtualización más usado26

26 Datos tomados del paper “Unlocking Virtualization: Facing IT, Business Realities” de

InformationWeek Analytics, Noviembre de 2008

La figura 1.12 muestra los resultados de una encuesta realizada por InformationWeek

Analytics a varias empresas Norteamericanas. Se puede observar la alta penetración

en el mercado de los tres fabricantes mencionados. Esto se debe al renombre de sus

casas fabricantes y al alto desempeño que presentan los mismos. Se debe mencionar

que las empresas que respondieron son en su mayoría grandes por lo que se

evidencia la gran preferencia de herramientas propietarias27.

1.5.1.1. VMware®

VMware es uno de los mayores referentes en lo que a virtualización se refiere al ser

una de las compañías pioneras en el ofrecimiento de soluciones de virtualización.

Fundada en 1998 y con sede en Palo Alto, California, Estados Unidos, es

actualmente una filial de EMC Corporation que entregó su primer producto, VMware

Workstation para sistemas x86, en el año de 1999.

Figura 1.13 Logo de VMware.

El software de virtualización de VMware puede ser corrido sobre Microsoft Windows,

Linux y Mac OS X; además dispone de soluciones empresariales como VMware ESX

27 Las herramientas propietarias son las que no disponen de código abierto

Server el cual no requiere de ningún sistema operativo como base, ya que corre

directamente sobre el hardware de un servidor.

La empresa ha desarrollado un alto número de productos durante sus años de

operación, siendo algunos de ellos versiones gratuitas, con funcionalidades

limitadas28.

1.5.1.1.1. Virtualización de sistemas x86

Al haberse enfocado en la virtualización de sistemas x86, tratando de transformarlos

en “sistemas para uso general, en infraestructuras de hardware compartido que

ofrecen un aislamiento completo, movilidad y opciones de elección del sistema

operativo de los entornos de aplicación”29, VMware debió superar algunos problemas

a la virtualización x86 que se originan debido a que, a diferencia de los mainframes,

las máquinas x86 no fueron diseñadas para admitir la virtualización completa ofrecida

por VMware.

Para su correcto funcionamiento, los procesadores x86, emplean un conjunto de

instrucciones para cumplir las tareas encomendadas, de este conjunto de

instrucciones existen 17 que presentan problemas con la virtualización completa y

provocan diversos inconvenientes que pueden llegar a un fallo total de la aplicación.

Para solucionar este problema, VMware desarrolló una técnica de virtualización

adaptable que atrapa a estas 17 instrucciones en el momento de generación y las

convierte en otras que no traen problemas, mientras permite al resto de instrucciones

ejecutarse sin intervención.

Aunque esta técnica afecte al rendimiento del sistema, proporciona una máquina

virtual que se adapte al hardware del equipo anfitrión, permita la instalación de una

gran variedad de sistemas operativos y mantenga compatibilidad de software.

28 Ninguno de sus programas es Open Source (Código Abierto)

29 Tomado de: http://www.vmware.com/es/overview/history.html

1.5.1.1.2. Arquitectura

La arquitectura presentada por los diversos tipos de software de VMware

corresponde a la arquitectura de una virtualización completa presentada en el

apartado 1.4.1.2 del presente capítulo.

En el caso de VMware, el monitor de máquinas virtuales (VMM) se inserta en una

capa de software directamente en el hardware del ordenador o en el sistema

operativo host, dependiendo del tipo de producto VMware. Este hypervisor será el

encargado de asignar recursos de hardware, de forma dinámica y transparente, a las

diferentes máquinas virtuales posibilitando la ejecución simultánea de varios sistemas

operativos en un único ordenador físico.

Además de esta virtualización, VMware ofrece un alto grado de escalabilidad al

disponer de una sólida plataforma de virtualización que permite la ampliación de

ordenadores físicos virtualizados interconectados y dispositivos de almacenamiento lo

que permite formar una infraestructura virtual completa.

1.5.1.1.3. Productos

VMware presenta una gran cantidad de diversos productos, estos se suelen clasificar

de acuerdo a si su uso es para escritorio o servidor y según si son gratuitos o

pagados.

Los software de escritorio son soluciones de virtualización personales, aunque

muchas de estas soluciones sean adecuadas para un caso específico, no se han

diseñado para su uso en servidores por lo que no se recomiendan para el presente

caso de estudio enfocado en las PyMES. Los productos de escritorio de VMware son:

· VMware ThinApp (Thinstall), se trata de un producto de pago que se emplea

para la virtualización de aplicaciones.

· VMware ACE (Assured Computing Environment), se trata de un producto de

pago que se emplea para el desarrollo y distribución de escritorios virtuales

seguros a un grupo de clientes.

· VMware Fusion (para equipos Mac), se trata de un producto de pago, que se

encarga de brindar virtualización completa en equipos MAC.

· VMware Player, se trata de un producto gratuito que permite correr máquinas

virtuales generadas por otros productos de VMware.

· VMware View (VMware VDM), se trata de un producto de pago que permite

brindar una virtualización de escritorio.

· VMware Workstation, se trata de un producto de pago que permite realizar

virtualización completa. Es uno de los productos más empleados de VMware.

El software de servidores o productos de datacenter, es específicamente diseñado

para uso en todo tipo de empresas y sus datacenters. Los productos para servidores

de VMware son:

· VMware vSphere 4, es una solución pagada que emplea la virtualización para

transformar los centros de datos en infraestructuras de informática en nube

(cloud computing) extraordinariamente simplificadas.

· VMware Infrastructure 3, es una solución pagada que unifica recursos de

hardware para crear una plataforma dinámica compartida que brinde

disponibilidad, seguridad y escalabilidad a las aplicaciones.

· VMware ESXi (VMware ESX Server ESXi edition), se trata de la versión gratuita

de VMware ESX, brinda soluciones de virtualización completa.

· VMware Server (VMware GSX Server), es una plataforma de virtualización

gratuita que se instala como una aplicación en cualquier tipo de servidor físico y

lo particiona en varias máquinas virtuales.

· VMware vCenter Site Recovery Manager, es una solución pagada para

simplificar el proceso de recuperación de máquinas virtuales.

· VMware vCenter Lab Manager (VMware Lab Manager).

· VMware Capacity Planner, permite la planeación de capacidades de los

servidores para proceder a una virtualización adecuada.

· VMware vCenter Lifecycle Manager, es una solución pagada que permite la

administración y procesamiento automático de los ciclos de vida de las

· VMware vCenter Stage Manager (VMware Stage Manager).

· VMware vCenter Server Heartbeat, es una solución pagada que brinda alta

disponibilidad a VMware vCenter Server.

· VMware vCenter AppSpeed, solución pagada que permite medir el desempeño

antes y después de virtualizar una aplicación.

· VMware vCenter Update Manager (ESX Patch Management), solución de pago

que facilita la administración de VMware Sphere, facilita la búsqueda y

parchado de los host VMware ESX.

· VMware vCenter Server (VMware VirtualCenter), solución de pago que brinda

una plataforma escalable para la administración de la virtualización.

· VMware Data Recovery, brinda una solución de respaldos basados en disco.

· VMware vCenter Orchestrator, automatiza las tareas de VMware Sphere.

· VMware vCenter Converter (VMware Converter), automatiza y simplifica la

conversión de máquinas físicas a máquinas virtuales.

· VMware ESX (VMware ESX Server), se trata de un sistema complejo de

virtualización que forma parte de VMware Infrastructure. No requiere de un

sistema operativo base sobre el cual correr, ya que dispone de un kernel propio

dedicado al manejo y administración de máquinas virtuales.

Para su funcionamiento debe primero iniciar un kernel Linux, el cual se usa para

cargar una variedad de componentes de virtualización especializados incluyendo el

kernel de VMware llamado vmkernel. Entonces el kernel de Linux se convierte en la

primera máquina virtual y no puede ser terminada a menos que se apague el sistema

completo.

Figura 1.14 Arquitectura empleada por VMware ESX, la capa de virtualización no corre sobre un sistema operativo

El software se encuentra enfocado en la centralización y virtualización de servidores

con la cual tiene un gran desempeño, sin embargo no es compatible con ciertos

dispositivos de hardware doméstico. Su administración se realiza de modo remoto

mediante la instalación de un software en una máquina remota, que se conecta por

entorno web.

1.5.1.2. Microsoft® (4) (5)

Otro software que permite dar lugar a la virtualización de servidores es el introducido

por Microsoft® llamado Hyper-V™.

Figura 1.15 Logotipo de Windows Server® 2008 Hyper-V™. Fuente: www.microsoft.com

Hyper-V™ aprovecha los nuevos procesadores de 64 bits de la arquitectura x86

introducidos por Intel® (Intel VT) y AMD® (AMD –V) principalmente.

Su introducción al mercado es relativamente reciente siendo así que su versión

definitiva fue incluida en el nuevo sistema operativo de servidor Windows Server

2008® a fines de junio del 2008. Cabe indicar que existieron programas de

virtualización anteriores a Hyper-V™ como por ejemplo versiones beta de Hyper-V™

y versiones también de Microsoft® Virtual Server.

La forma de distribución del software de virtualización se ha dado principalmente

como una funcionalidad del sistema operativo de la edición x64 de Windows Server

2008 Enterprise, por lo cual su costo está incluido en el paquete.

Adicionalmente existe la posibilidad de descargar dicho software gratuitamente con

cualquier licencia de un producto de instalación de Microsoft® Windows® Server.

1.5.1.2.1. Características

Hyper-V™ de Microsoft así como sus versiones anteriores como Microsoft® Virtual

Server disfrutan de los mismos beneficios de los servidores virtuales asociados con

un ambiente stand-alone ESX.

Incorpora además una arquitectura de hypervisor basada en microkernel con una

mínima superficie de ataque y está disponible en el rol de Servidor Básico.

Posee herramientas de gestión integradas que permiten a los clientes disponer de un

conjunto unificado de herramientas para la gestión tanto de los recursos virtuales

como de los físicos.

Posee las siguientes características:

§ Migración rápida. Permite el traspaso de máquinas virtuales en ejecución desde

un host a otro con mínimas pérdidas de servicio.

§ Alta disponibilidad. Hyper-V™ beta incluye soporte para conectividad host-a-host

y permite organizar en clúster todas las máquinas virtuales que se ejecutan en un

§ Backups en vivo, con VSS. Se incorpora soporte para los Servicios de Copia de

Volumen en Segundo Plano (Volume Shadow Copy Services, VSS) que permiten

realizar backups en vivo de las máquinas virtuales en ejecución por medio de

instantáneas de volumen.

§ Herramientas para VHD. Hyper-V™ incorpora soporte para herramientas para el

manejo de VHD, con las que puede compactar, expandir e inspeccionar el

contenido de HVDs creados con Hyper-V™.

§ Administración de VM. Facilita la importación o exportación de las configuraciones

de máquina virtual para hacer copia de seguridad y poder clonar las

características de las VM’s entre distintas máquinas host.

§ Componentes de integración de Linux. Disponibles para las ediciones x86 y x64

de SUSE Linux Enterprise Server 10 SP1. Estos componentes de integración

permiten aprovechar desde Linux compatible con Xen todas las ventajas de la

arquitectura VSP/VSC y obtener un mejor rendimiento.

§ Mejoras en el rendimiento. Hyper-V™ beta incluye distintas modificaciones para

mejorar su rendimiento.

§ Gestión remota. Permite la gestión remota y ofrece la opción de instalación de

Hyper-V™ basada únicamente en MMC para una gestión independiente de los

nodos.

§ Mejoras del soporte para SCSI Virtual. Soporte para un máximo de cuatro

controladoras SCSI virtuales por máquina virtual, permitiendo un soporte más

amplio de dispositivos de almacenamiento.

§ Soporte para tamaños de memoria mayores. Hyper-V™ beta puede direccionar

hasta 64 GB de memoria por máquina virtual.

§ Reset rápido. Hyper-V™ beta da la opción de reseteo rápido de checkboxes y

eliminación de las credenciales almacenadas que se hayan utilizado para

conectarse a las máquinas virtuales.

Figura 1.16 Arquitectura de Windows Server® 2008 Hyper-V™. Fuente: Understanding

Microsoft Virtualization Solution, Pág. 29. Microsoft Corporation ©, 2009.

Como se puede ver en la figura anterior, Hyper-V™ consiste del componente

Hypervisor de Microsoft® el cual corre directamente sobre el hardware (haciendo uso

de virtualización asistida por hardware). El tipo de hypervisor Hyper-V es non hosted.

Sobre el hypervisor corre una partición30 primaria y una o más particiones hijas.

La partición padre es la encargada de controlar las otras particiones en las cuales

corren los entornos virtualizados. Esta partición inclusive es la dueña de los

dispositivos de hardware y manejo de recursos de las particiones hijas.

Una partición hija es cualquier partición que ha sido creada por la partición padre. Los

sistemas operativos Guest´s y sus respectivas aplicaciones corren en particiones

hijas.

Adicionalmente, sobre la partición padre debe correr una instalación de Windows

Server® 2008 como su sistema operativo.

Cada partición se comunica con el hypervisor mediante el uso de hypercalls, las

cuales como, ya se ha dicho anteriormente, son API´s (Application Programming

Interfaces)31 que los sistemas operativos pueden utilizar para dar lugar a

optimizaciones que provee el hypervisor.

1.5.1.3. Xen® Hypervisor (6)

Figura 1.17 Logotipo del hypervisor Xen®. Fuente: www.xen.org 30 Constituye una unidad aislada entre el hypervisor, direcciones de memoria física y procesos virtuales.

31 Una API constituye una interfaz de comunicación entre componentes de software. Son un grupo de llamadas a bibliotecas que ofrecen acceso a ciertos servicios desde los procesos proporcionando un conjunto de funciones de uso general. Representa un método para conseguir abstracción en la programación generalmente entre los niveles o capas inferiores y los superiores del software. Fuente: http://msdn.microsoft.com/es-es/library/172wfck9(VS.80).aspx

Fruto de un proyecto de investigación de la Universidad de Cambridge nace Xen® el

cual es considerado como el hypervisor estándar para virtualización de la industria

open source.

Xen® permite la ejecución de múltiples sistemas operativos sobre un único equipo

servidor y con altos niveles de rendimiento, cercanos al rendimiento nativo. Su

funcionamiento se basa en la paravirtualización.

1.5.1.3.1. Características

Xen® ofrece un conjunto de características de gran potencia, eficiencia y seguridad

para la virtualización de arquitecturas x86, x86_64, IA64, ARM entre otras.

Trabaja tanto en tecnologías de procesadores optimizados para virtualización (Intel

VT® o AMD-V®) como en aquellos chipsets que no.

Su funcionamiento se basa en la paravirtualización corriendo sistemas operativos

Guest modificados (XVM) así como sistemas operativos no modificados (HVM). Es

así que Xen® soporta un amplio rango de sistemas operativos Guest incluyendo

Windows®, Linux®, Solaris® y varias versiones de BSD, facilitando el cumplimiento

de varias necesidades actuales del nivel empresarial.

Entre sus características principales se incluyen:

§ Aprovisionamiento de máquinas virtuales de rendimiento cercano al hardware

nativo.

§ Migración en vivo (Live Migration) de máquinas virtuales en caliente entre

hosts físicos.

§ Soporte de hasta 32 CPU´s virtuales por máquina virtual Guest, mediante

VCPU hotplug (con IA 64 se soporta hasta 64 CPU´S virtuales por Guest VM).

§ Soporte de plataformas x86/32 con PAE, x86/64, y IA64.

§ Soporte de las tecnologías de virtualización de Intel® y AMD® para sistemas

operativos no modificados (incluyendo Microsoft® Windows®).

§ Excelente soporte de hardware, soportando así casi todos los drivers de Linux.

Entre sus distintas aplicaciones se incluyen la consolidación de servidores, desarrollo

de kernel, soporte de hardware para sistemas operativos tradicionales, independencia

de hardware, clúster computing y múltiples configuraciones de sistemas operativos

con propósitos de pruebas.

Adicionalmente, una característica importante de Xen® es su carácter open source y

de software libre. Su última versión puede ser descargada gratuitamente desde

xen.org. Así también Xen puede ser encontrado en versiones pagadas como

XenEnterprise que incluye varias herramientas de administración gráfica entre otros.

A éstas características se puede añadir el hecho que Xen® viene ya desde hace

algunas versiones como un componente incluido en varias distribuciones de Linux

como CentOS 5.2, Debian, Open SUSE, etc.

Figura 1.18 Arquitectura Básica de Xen®. Fuente: Xen and the Art of Virtualization. Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauery, Ian

Pratt, Andrew Wareld, University of Cambridge Computer Laboratory. Pág. 5.

En la figura anterior se puede observar una arquitectura básica del hypervisor Xen®.

Este sistema tiene varias capas; la capa más baja y de mayores privilegios es la capa

Xen por sí misma.

Sobre la capa Xen (hypervisor) se hospeda la capa de Guest OS los cuales son

ejecutados en una máquina virtual segura. Este entorno de máquina virtual se

denomina ‘domain’ en la terminología de Xen; así de esta manera se tiene que sobre

el hypervisor se ejecutan los domains: un domain 0 Guest que tiene funciones

especiales y uno o más domain U Guest que corresponden a las instalaciones de

Guest OS del sistema virtualizado.

Estos domains son administrados por Xen repartiendo el CPU entre las máquinas

virtuales; lográndose así un uso efectivo del o los CPU´s físicos disponibles. Cada

Guest OS (domain U Guest) maneja sus propias aplicaciones; este manejo incluye la

responsabilidad de planificar cada aplicación en función del tiempo destinado por Xen

a cada máquina virtual.

El primer domain, es el llamado domain 0, el cual es creado automáticamente cuando

el sistema es iniciado. Éste tiene privilegios especiales de administración del sistema

de virtualización. Es así que el domain 0 es el que “permite crear” a los otros

dominios y administra sus dispositivos virtuales. Éste, de igual manera, se encarga de

realizar tareas administrativas tal como la “suspensión”, “reinicialización” y migración

de el resto de máquinas virtuales.

Entre el domain 0, corre un proceso llamado xend, un demonio para administrar el

sistema. Xend es responsable del manejo de las máquinas virtuales así como de

proveer el acceso a sus consolas. Los comandos necesarios para la ejecución de

xend pueden ser enviados tanto a través de la línea de comandos como a través de

una interfaz HTTP.

Este tema se lo podrá encontrar con mayor profundidad en el capítulo 3 del presente

trabajo de investigación.

1.5.2. OTRAS OPCIONES DE SOFTWARE DE VIRTUALIZACIÓN

En adición al software de virtualización anterior se cuenta con otras alternativas

menos difundidas pero que es preciso mencionarlas.

1.5.2.1. KVM®

El software de virtualización Kernel-based Virtual Machine (KVM), brinda una solución

de virtualización completa para las distribuciones de Linux que corren en hardware

x86 con soporte para virtualización32.

Figura 1.19 Logo de KVM.

KVM es un software de código abierto que permite correr versiones sin modificar de

sistemas operativos Linux y Windows. Para su funcionamiento emplea un módulo de

kernel propio llamado kvm.ko, un módulo de procesador específico de acuerdo al

procesador empleado (para los procesadores Intel se emplea el kvm-intel.ko y para

los AMD el kvm-amd.ko) y finalmente un QEMU33 modificado.

En la actualidad KVM se ejecuta como un módulo de kernel, el componente KVM

para el mismo está incluido en Linux desde la versión 2.6.20, sin embargo las futuras

versiones emplearán llamadas al sistema que se integrarán directamente en el kernel.

Se espera mucho de este software de virtualización, siendo sus principales

características el ser de código abierto y el integrarse perfectamente con el kernel de

Linux, por lo que no se necesitan modificaciones en el mismo para correrlo. Sin

32 Los procesadores que soportan virtualización por hardware son las AMD-V o Intel VT los cuales deben tener habilitado la virtualización por hardware.

33 QEMU es un emulador de procesadores basado en la traducción dinámica de binarios

embargo aún existe una falta de soporte y su rendimiento, aunque resulta ser muy

bueno sigue siendo inferior al de otras herramientas como Xen34.

1.5.2.2. Microsoft Virtual PC®

Microsoft Virtual PC es un paquete de virtualización desarrollado para los sistemas

operativos de Microsoft Windows, aunque también dispone de una suite de emulación

para los Mac OS X que corren sobre sistemas basados en PowerPC35. Originalmente

el software fue escrito por Connectix, sin embargo fue adquirido por Microsoft quien

en Julio de 2006 sacó una versión de Windows gratuita y en Agosto del mismo año

anunció que no se desarrollará una versión para Mac con procesador Intel.

Actualmente, para la nueva versión de sistema operativo de Microsoft, Windows 7 se

cambiará el nombre del software a Windows Virtual PC.

Figura 1.20 Logo de Microsoft Virtual PC.

Para su funcionamiento Virtual PC virtualiza una PC estándar y su hardware

asociado, soportando la virtualización de sistemas operativos Windows, es posible

que pueda correr sistemas como Linux, sin embargo los mismos no son soportados

oficialmente. 34 Phoenix Media realizó comparaciones de desempeño entre las herramientas QEMU, KVM y Xen, estas se encuentran en la página http://www.phoronix.com/scan.php?page=article&item=623&num=3 y se observa que la herramienta con mayor desempeño es Xen

35 PowerPC (Power Performance Computing) es una arquitectura RISC creada en 1991 por AIM (Apple, IBM y Motorola)

Virtual PC basa su virtualización en la emulación del hardware, específicamente

emula una placa madre con un chipset Intel 440BX, una tarjeta de video SVGA VESA

Estándar S3 Trío32/64 con 8 MB de memoria VRAM, un chip de BIOS de American

Megatrends, una tarjeta de sonido SoundBlaster 16 y una tarjeta de red DEC 21140.

Además, para la versión de Mac OS emula un procesador Intel Pentium III (32-bit), en

cambio para la versión de Windows no emula el procesador sino que deja que el

mismo ejecute las instrucciones en el entorno emulado.

1.5.2.2.1. Windows Virtual PC

Se ha anunciado que Microsoft Virtual PC cambiará su nombre para el nuevo sistema

operativo Windows 7. El sucesor de Microsoft Virtual PC 2007 llevará por nombre

Windows Virtual PC. Esta nueva versión ya sacó su versión beta para pruebas a

finales de abril del presente año.

Esta versión sólo correrá sobre Windows 7 y necesita soporte a virtualización del

hardware36. La característica principal que tiene esta nueva versión es que permitirá

la ejecución transparente, esto permitirá a Windows 7 correr aplicaciones en modo

Windows XP directamente desde el escritorio, por lo que toda aplicación compatible

con Windows XP también lo será con Windows 7 y el usuario ni siquiera se enterará

de la virtualización de la aplicación.

Además de esta característica Windows Virtual PC tendrá soporte para USB, smart

cards y será multi-hilo, esto permitirá a cada máquina virtual corriendo

simultáneamente tener su propio hilo para dar una mayor estabilidad y rendimiento.

También se brindará una integración con el Explorador de Windows, lo cual permitirá

administrar rodas las máquinas virtuales desde una única carpeta del explorador

(%USER%\Virtual Machines).

36 Los procesadores que soportan virtualización por hardware son las AMD-V o Intel VT los cuales deben tener habilitado la virtualización por hardware.

1.5.2.2.2. Sistemas Operativos Soportados

Oficialmente, Virtual PC solo puede ser instalado en sistemas operativos Windows y,

de la misma forma, los sistemas operativos virtuales que soporta también son

limitados.

Virtual PC 2007 soporta los siguientes sistemas operativos como huésped:

§ Windows Server 2008 (Todas las ediciones de 32-bits)

§ Windows Vista37 (Todas las ediciones de 32-bits)

§ Windows XP (Todas las ediciones de 32-bits)

§ Windows Server 2003 (Todas las ediciones de 32-bits)

§ Windows 2000 (Todas las ediciones)

§ Windows 98 Segunda Edición

§ Windows NT Server 4.0 (Todas las ediciones)

§ IBM OS/2 Warp

Además Virtual PC 2007 es compatible, pero no tiene soporte a los siguientes

sistemas operativos:

§ Windows 98 Versión original

§ Windows 95 (Todas las ediciones)

§ Windows Me

§ Windows NT 4.0 Workstation

§ Windows 3.1

§ MS-DOS 6.22

37 En el caso de correr Windows Vista como sistema operativo huésped en Virtual PC 2007, se deshabilita el tema gráfico aero debido a las limitaciones de la tarjeta emulada de los gráficos S3. Sin embargo, El tema aero puede ser ejecutado mediante una conexión con una máquina física, que soporte el tema, mediante escritorio remoto.

1.5.2.2.3. Sistemas Operativos Linux como Huésped

Aunque oficialmente Virtual PC no soporte a Linux como huésped, es posible realizar

esta instalación, aunque no de una manera transparente. Esto se debe a que

Microsoft Virtual Server soporta aditamentos para Linux, los cuales deberían trabajar

también con Virtual PC.

Sin embargo se debe tomar en cuenta algunos parámetros, por ejemplo que ciertas

distribuciones de Linux con gráficos de 24 bits deben de ser instaladas en modo de

texto debido a que Microsoft Virtual PC sólo emula gráficos de 16 o 32 bits. Entonces,

para correr una interfaz gráfica se debe especificar el uso de colores de 16 bits en el

archivo de configuración xorg.conf del sistema operativo virtual.

Las diferentes distribuciones de Linux pueden tener sus propios inconvenientes para

correr sobre Virtual PC sin embargo existe una gran cantidad de páginas web

dedicadas a brindar soporte para estas instalaciones ya que no existe tal por parte de

Microsoft.

CAPÍTULO DOS

2. ANÁLISIS DE LOS REQUERIMIENTOS

TECNOLÓGICOS DE LAS PyMES Y LA

APLICABILIDAD DE LA ARQUITECTURA

SERVIDOR VIRTUALIZADO PARA FACILITAR SU

OPERACIÓN.

2.1. FUNDAMENTOS GENERALES DE LAS PyMES

Dentro del amplio ámbito productivo empresarial, la clasificación de las empresas que

lo conforman puede hacerse de acuerdo a su tamaño. Esta clasificación vincula a

factores como por ejemplo el número de empleados, la cantidad de ganancias

obtenidas, el volumen de producción, etc. Tomando en cuenta estos parámetros ya

sean en conjunto o de manera individual, las empresas pueden clasificarse en:

grandes, medianas, pequeñas y microempresas.

En este ámbito tratado, surge una especial atención por aquellas empresas con

grandes posibilidades de crecimiento y expansión pero que debido a sus limitaciones

ocupacionales, financieras o ambas requieren de un mayor apoyo económico-

financiero, organizativo, administrativo, de educación y capacitación, y tecnológico,

etc. Estas empresas son las denominadas como PyMES por su acrónimo de

pequeñas y medianas.

El panorama socio económico del Ecuador actual, está caracterizado, entre varios

factores por la tendencia hacia la globalización de mercados, una balanza comercial

en déficit, una economía transitoriamente sostenida por los recursos petroleros y las

remesas de los inmigrantes, y tradicionalmente por el sector agropecuario. En esta

estructura económica, más del 90% de las empresas son pequeñas y medianas

(PyMES) las cuales aportan aproximadamente un 25% de la economía nacional38.

A esta situación se suma el hecho de que en el ámbito internacional los países y las

empresas exitosas son aquellas que basan su ventaja competitiva en factores

innovadores y tecnológicos, que cuentan con un recurso humano capacitado y que

realizan inversiones en investigación y desarrollo con carácter de largo plazo. Estas

condiciones limitan el accionar de las PyMES en Ecuador debido a la carencia de

recursos pero que al mismo tiempo las impulsa a encontrarse en una etapa evolutiva

de desarrollo económico; para ello necesitan alcanzar altos niveles de competitividad

y productividad.

38Fuente: Fomento a las PyMES y al emprendimiento, http://www.conesup.net/propasamblea/MpTOFu_FOMENTO%20A%20LAS%20%20PYMES%20Y%20AL%20%20%20EMPRENDIMIENTO.doc.

Es ahí, en la productividad y competitividad, donde la introducción de las Tecnologías

de Información y Comunicación (TIC´s) cumple un papel decisivo en el cumplimiento

eficiente de la naturaleza del negocio y con ello el objetivo de desarrollo de las

PyMES.

Así, la implementación de canales de información y comunicación tanto internos

como externos dan una ayuda fundamental para el mejoramiento de procesos

administrativos, productivos, comerciales, de extensión y crecimiento, etc.

Lamentablemente y debido a la naturaleza inicial tanto económica como organizativa

y administrativa de las PyMES, el acceso a las TIC´s no es una realidad generalizada

para la mayoría de éstas, situación que se ve acentuada en nuestro país39.

Estos hechos justifican la implantación de una Política de Estado que brinde mayor

apoyo a las PyMES tendientes a alcanzar objetivos de innovación, desarrollo de

tecnología y emprendimiento mediante la masificación del acceso al uso de nuevas

tecnologías, las TIC´s y redes digitales.

En tal virtud es imprescindible vincular fuertemente a las pequeñas y medianas

empresas con un ambiente organizativo en el que el uso de Internet, correo

electrónico, comercio electrónico, etc. sea un hecho cotidiano que aporte a una mejor

gestión de su organización productiva.

Es así que la introducción de una solución económica, de fácil uso y mantenimiento

(pues por añadidura no se cuenta con personal de TI fijo) y por tanto confiable,

segura, y eficaz que permita a las PyMES acceder a las Tecnologías de la

Información y Comunicación, constituye un factor preponderante a ser implementado

en el camino para conseguir su desarrollo y además como estrategia de

supervivencia comercial.

Es aquí donde los servidores virtualizados toman parte en la escena de las PyMES

ofreciendo un entorno de TI ajustado con mayor precisión a las necesidades

organizacionales y contribuyendo así a la constitución de un centro de datos más 39 Referirse al anexo B: Estado de las Tic´s en Ecuador.

eficiente, manejable, confiable, seguro, disponible y de menor costo que facilitará la

operación de estas empresas.

2.2. CONCEPTO (7) (8) (9)

En Ecuador, no hay una definición exacta ni exclusiva de lo que es una PYME, sin

embargo se cuenta con ciertos parámetros que permiten determinarla.

§ Número Personal que labora.

§ Ventas netas anuales e impuestos externos.

Así de acuerdo a su tamaño, las empresas tienen las categorías siguientes:

§ Microempresas: emplean hasta 10 trabajadores, y su capital fijo (descontado

edificios y terrenos) puede ir hasta 20 mil dólares.

§ Talleres artesanales: se caracterizan por tener una labor manual, con no más

de 20 operarios y un capital fijo de 27 mil dólares.

§ Pequeñas empresas: pueden tener hasta 50 trabajadores.

§ Medianas empresas: albergan de 50 a 99 trabajadores, y el capital fijo no debe

sobrepasar de 120 mil dólares.

§ Grandes Empresas: son aquellas que tienen más de 100 trabajadores y 120

mil dólares en activos fijos.

Categoría De Empresas

Valor De Activos No. De Trabajadores

Microempresa Hasta 20 mil dólares Hasta 10 Pequeña Hasta 60 mil dólares Entre 11 y 50 Mediana Hasta 120 mil dólares Entre 50 y 99

Tabla 2.1 Clasificación de las MiPyMES Ecuador. Fuente: Asociación Latinoamericana de Integración ALADI.40

Éste concepto puede ser reforzado con la definición de PyMES en otros países de la

región y del resto del mundo:

40 Fuente: http://www.aladi.org/nsfaladi/reuniones.nsf/dab401eea2e85cea03256ac6004de835/5a4879fcc06d040b03256ac6004e0a11/$FILE/ecuador.doc.

Colombia: “Se entiende por pequeña y mediana empresa (Artículo 2, Ley 905 de

2004), toda unidad de explotación económica, realizada por persona natural o

jurídica, en actividades empresariales, agropecuarias, industriales, comerciales o de

servicios, rural o urbana, que responda a dos (2) de los siguientes parámetros:

§ Mediana empresa: a) Planta de personal entre cincuenta y uno (51) y

doscientos (200) trabajadores, o, b) Activos totales por valor entre cinco mil

uno (5.001) a treinta mil (30.000) salarios mínimos mensuales legales

vigentes.

§ Pequeña empresa: a) Planta de personal entre once (11) y cincuenta (50)

trabajadores, o b) Activos totales por valor entre quinientos uno (501) y menos

de cinco mil (5.000) salarios mínimos mensuales legales vigentes.”41

Categoría De Empresas

Valor De Activos No. De Trabajadores

Microempresa Hasta 500 smlmv42 equivalentes a $204.000.000

Hasta 10

Pequeña Entre 501 y 5000 smlmv equivalentes a $204.408.000 y $2040.000.000

Entre 11 y 50

Mediana Entre 5001 y 30.000 equivalentes a $2040.408.000 y 12.240.000.000

Entre 51 y 200

Tabla 2.2 Clasificación de las MiPyMES Colombia. Fuente: Ley 905 de 2004 http://www.miPyMES.gov.co/microempresario/newsdetail.asp?id=86&idcompany=45

Mercosur: “…se determina la categorización de las PyMES que regirá en Argentina,

Brasil, Paraguay y Uruguay (…) en tal sentido se acordó la determinación de un

coeficiente de tamaño según la siguiente fórmula:

41 Fuente: http://www.miPyMES.gov.co/PyME/newsdetail.asp?id=225&idcompany=43

42 Termino usado en Colombia para referirse a Salarios Mínimos Legales Mensuales Vigentes

Donde:

§ P cantidad de empleados de la empresa.

§ Pref cantidad de empleados de referencia.

§ V ventas de la empresa en dólares estadounidenses.

§ Vref ventas de referencia en dólares estadounidenses.

Este coeficiente, establecido a partir de una definición de los límites máximos de

número de empleados y facturación anual se debe adecuar a la realidad empresarial

de cada uno de los países miembros y a las necesidades del MERCOSUR, tomando

en cuenta los siguientes valores definidos en diciembre de 1992: ”43

Tipo de empresa Pref Vref (en dólares) Coef. de tamaño

Microempresa hasta 20 hasta 400.000 hasta 0,52

Pequeña Empresa hasta 100 hasta 2.000.000 hasta 2,58

Mediana Empresa hasta 300 hasta 10.000.000 hasta 10

Tabla 2.3 Clasificación de las PyMES Mercosur. Fuente: http://www.rau.edu.uy/mercosur/faq/pre24.merco.htm

Unión Europea: Según la Recomendación de la Comisión Europea de la Unión

Europea “(…) se define a una mediana empresa como una empresa que ocupa a

menos de 250 personas y cuyo volumen de negocios anual no excede de 50 millones

de euros o cuyo balance general anual no excede de 43 millones de euros y (…) se

define a una pequeña empresa como una empresa que ocupa a menos de 50

personas y cuyo volumen de negocios anual o cuyo balance general anual no supera

los 10 millones de euros”44

43 Fuente: http://www.rau.edu.uy/mercosur/faq/pre24.merco.htm

44 Fuente:http://europa.eu/legislation_summaries/enterprise/business_environment/n26026_es.htm

Tipo de empresa Empleados Facturación (Millones de €)

Total de Balance (Millones de €)

Microempresa < 10 y ≤ 2 o ≤ 2

Pequeña empresa < 50 y ≤ 10 o ≤ 10

Media empresa < 250 y ≤ 50 o ≤ 43

Tabla 2.4 Clasificación de las PyMES Unión Europea. Fuente: http://europa.eu/legislation_summaries/enterprise/business_environment/n26026_es.htm

Es así que se puede inferir el siguiente concepto que se hará uso en el presente

trabajo de investigación:

Son pequeñas y medianas empresas (PyMES) aquellas unidades productivas con un

número de trabajadores comprendido de 11 a 50 y de 51 a 300 respectivamente y

cuyo capital fijo no sobrepase los 120 mil dólares.45

2.3. SITUACIÓN ACTUAL DE LAS TIC´S EN LAS PyMES

ECUATORIANAS

Como ya se ha podido mencionar, la adopción de las Tecnologías de Información y

Comunicación (TIC´s46) constituye una parte fundamental como factor de progreso

para las PyMES. Este hecho constituye una realidad que ha sido respaldada por

varios estudios internacionales.

45 Para esta definición se ha precisado el número máximo de trabajadores a fin de satisfacer el caso crítico de aplicación.

46 Se define como TIC´s o tecnologías de la información y comunicación al conjunto de técnicas, desarrollos y dispositivos avanzados que integran funcionalidades de almacenamiento, procesamiento y transmisión de datos. Tienen como fin la mejora de la calidad de vida de las personas dentro de un entorno, y que se integran a un sistema de información interconectado y complementario. Algunas finalidades concretas son por ejemplo: formación educativa, organización y gestión empresarial, toma de decisiones, etc. Fuente: Las Tic y sus aportaciones a la sociedad: http://www.pangea.org/peremarques/tic.htm.

Así por ejemplo en un esfuerzo combinado por Dinamarca, Irlanda y Grecia47 se

condujo un estudio sobre las razones por los cuales las TIC deben ser adoptadas en

las PyMES (Small and Medium Enterpises SME en inglés) concluyéndose que éstas

son48:

§ Incremento de la productividad (Increased productivity).

§ Modernización y orden de los procedimientos de trabajo (Streamlining work

procedures).

§ Mejorada atención y servicio al cliente (Better client service).

§ Mejor mantenimiento de la información (Record keeping).

Estos factores se ven complementados en otro estudio49 donde se añade que la

adopción de las TIC´s en las PyMES permiten: “hacer lo correcto”, “hacerlo correcto”

y “mejorar los aspectos fundamentales de la empresa” (“doing the right thing,” “doing

things right,” and “improving the bottom line”.)56

Figura 2.1 Criterios para la adopción de las TIC`s en las PyMES. Fuente: E-commerce in Regional Small to Medium Enterprises. Pág. 11

Considerando estos factores que demuestran la importancia de la adopción de las

tecnologías de información y comunicación en las PyMES, la situación actual

ecuatoriana no muestra una adopción mayoritaria de las TIC´s.

Estos hechos se muestran con una serie de datos presentados a continuación gracias

al apoyo de la CAPEIPI, MIPRO, CORPEI, CONQUITO, entre otros entes del sector

productivo.

47 Estudio conducido por Neergaard a inicios de los 90´s.

48 Fuente: MacGregor & Vrazal c, E-commerce in Regional Small to Medium Enterprises Pág 11.

49 Estudio conducido por Fink y Tjarka et al. (1994).

2.3.1. ESTADÍSTICAS DE LAS TIC´s EN LAS PyMES ECUATORIANAS

Según datos recogidos por el estudio de investigación INFOPYME50, las estadísticas

de las TIC´s en las PyMES son las siguientes:

§ Número promedio de computadoras en las PyMES: 2 a 15.

§ Uso del computador en las empresas: 80%.

§ Presupuesto aproximado de cada empresa para uso de TIC´s: 10%.

§ Presupuesto para investigación de TIC´s en las PyMES: 0.5%.

§ Número de Server´s51 en las PyMES: 15.

§ Conexión a Internet en las PyMES: 40%.

§ Software de seguridad en las PyMES: 20%.

§ Licenciamiento en las PyMES: 2%.

§ Hardware de última generación: 50%.

§ Portales Web: 20%.

§ ERP52: 0.5%.

§ CRM53: 0.5%.

§ Correo electrónico propio: 25%.

§ Uso de las TIC´s en procesos de producción: 5% - 10% empírico.

Así mismo un estudio realizado por la Corporación de Promoción de las

Exportaciones y la Inversión (CORPEI) y la Consultora RGX a 530 empresas de

Ecuador, Argentina, Chile, Colombia, Costa Rica, México, Perú, Paraguay, Panamá y

Venezuela concluye que “(…) las PyMES dependen de las TIC para fortalecer sus

50 Estudio realizado por la Cámara de la Pequeña Industria de Pichincha (CAPEIPI) a 3000 PyMES por el Ing. Christian Villarroel, M.Sc (2008).

51 Número total de servidores de entre el todo de las 3000 empresas estudiadas.

52 ERP, Enterprise Resource Planning, son sistemas de gestión de información que integran y

automatizan muchas de las prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa: Fuente: es.wikipedia.org/wiki/Planificaci%C3%B3n_de_recursos_empresariales

53 CRM, es parte de una estrategia de negocio centrada en el cliente; su idea es recopilar la mayor cantidad de información posible sobre los clientes, para poder dar valor a la oferta: Fuente: http://es.wikipedia.org/wiki/Customer_relationship_management

exportaciones (…)”. Sin embargo, el estudio muestra que, en el Ecuador, solo el 30%

de las Pequeñas y Medianas Empresas (PyMES) utiliza las ventajas tecnológicas de

información y comunicación (TIC), cifra muy baja en relación al 50% registrado en

otros países de América Latina.

Incluso, de acuerdo a los datos obtenidos del estudio, el 100% de las PyMES

ecuatorianas encuestadas, que utilizan las TIC, afirman que estas tuvieron un

impacto positivo en su crecimiento empresarial. Por otra parte “las 530 PyMES

exportadoras en Iberoamérica que no realizaron este proceso en los dos últimos

años, tienen resultados nefastos, pero la aplicación de las TIC les está ayudando a

progresar”54.

A todo esto se suma el hecho que Ecuador ocupa el puesto 116 de entre 134 países

analizados por el uso e introducción de las Tecnologías de Información y

Comunicación (TIC). Así lo confirma el Networked Readiness Index 2008–2009,55

indicador que mide la adopción tecnológica de las economías a escala mundial.

Estos datos muestran una gran deficiencia en la adopción de TIC´s en las PyMES

ecuatorianas, impidiendo alcanzar los beneficios mencionados en el apartado 2.3 del

presente proyecto. Esta situación ha influido indudablemente en los índices de

competitividad, productividad, innovación, desarrollo de tecnología y

emprendimiento de las PyMES, hecho que se refleja en una participación en el PIB

insignificante siendo el promedio de ésta en 9,28%56.

En el cuadro posterior se observa la participación por cada año del sector industrial

de la economía ecuatoriana demostrando la fragilidad y poca planificación de las

empresas.

54 Fuente: José Manuel Parceiro, director del proyecto RGX-CORPEI “La innovación como motor para el desarrollo competitivo exportador de las PyMES”.

55 Fuente: www.hoy.com.ec. Publicado el 08/Abril/2009

56 Fuente: Proyecto INFOPYME 2008, Cámara de la Pequeña Industria de Pichincha (CAPEIPI), Ing. Christian Villarroel, M.Sc (2008) Pág. 2.

Actividad

2002 2003 2004 2005 2006 2007 2008

INDUSTRIAS 2593049 2734904 2881168 3295962 3725253 4062621 4445226

PIB 24899481 28635909 32642225 37186942 41401844 44489915 48507688

% PARTICIP. 10,41% 9,55% 8,83% 8,86% 9,00% 9,13% 9,16%

Tabla 2.5 Participación de las PyMES en el PIB. Fuente: Cámara de la Pequeña Industria de Pichincha, Proyecto INFOPYME 2008, Resumen Ejecutivo Pág. 2.

De los datos obtenidos se puede concluir lo siguiente:

§ El acceso a las tecnologías de información (TIC´s) en las PyMES de

Ecuador es en un porcentaje del 30%, inferior al resto de países de la

región (50%), hecho que se ve reflejado en la balanza comercial negativa.

§ La relación de las PyMES con la innovación e investigación y las

universidades es insuficiente por lo que sus procesos administrativos,

productivos, logísticos, etc. permanecen sin mayor cambio que les

posibilite su desarrollo.

§ Las fuentes de financiamiento para el acceso a las TIC´s es un factor que

influye en la adopción de éstas.

§ No existe suficiente personal capacitado en las PyMES para el manejo y

administración de las TIC´s.

§ El licenciamiento (software) en las PyMES es sumamente reducido,

mayormente por sus limitaciones económicas.

§ Se desconoce las ventajas que aportan las TIC´s como Internet, correo

electrónico, comercio electrónico, portales Web, herramientas de ERP y

CRM en los procesos administrativos, comerciales, logísticos y por ende

productivos de las PyMES.

§ Las exportaciones de las PyMES se ven limitadas por su baja adopción de

las TIC´s, las cuales las relaciona con un mundo comercial globalizado.

Esta serie de estadísticas presentadas permiten plantear un inminente acceso de las

PyMES a las TIC´s; la mayor penetración de las tecnologías de la información y

comunicación permitirá fomentar su desarrollo comercial.

Para tal efecto es necesaria la introducción de una solución tecnológica que permita

satisfacer las necesidades de información y comunicación de las PyMES, de manera

económica, eficiente, segura, simple, de fácil mantenimiento, entre otras

características.

Es así que en el presente proyecto se plantea a los servidores virtuales como medios

de introducción de las TIC´s en las PyMES y al que se suman los factores adicionales

característicos de la virtualización como ventajas adicionales en su camino para la

adopción en las pequeñas y medianas empresas.

2.3.2. SOLUCIONES Y REQUERIMIENTOS TECNOLÓGICOS

ACTUALES PARA LAS PyMES ECUATORIANAS (10) (11)

Estos hechos presentados en el apartado anterior muestran un claro grado inferior de

adopción de las TIC´s en Ecuador por parte de las PyMES. Los motivos son varios

entre los que se puede recalcar entre otros:

§ Retraso tecnológico.

§ Falta de formación e información de nuevas tecnologías.

§ Falta de difusión de los beneficios de las TIC´s para las PyMES.

§ Falta de asesoramiento tecnológico.

§ Costo de las soluciones tecnológicas para TIC´s, etc.

Ante esta situación, diferentes organismos ecuatorianos como la Cámara de la

Pequeña Industria de Pichincha (CAPEIPI) en su Plan 2010, se ha trazado una serie

de lineamientos y estrategias para incrementar el grado de adopción de las TIC´s en

las PyMES ecuatorianas en los siguientes parámetros57.

57 Datos proporcionados por el Ing. Christian Villarroel, proyecto INFOPYME 2008, CAPEIPI.

§ Al final del periodo de ejecución del Plan (2010), el porcentaje de empresas

con conexión a Internet deberá alcanzar el 99% para empresas con más de 10

empleados y 79% para las microempresas y autónomos con menos de 10

empleados. Además, un 98% de las de más de 10 empleados y un 68% de las

de menos de 10 dispondrán de banda ancha.

§ Estos lineamientos además apuntan al aumento del negocio electrónico, esto

es, a la incorporación de las TIC´s en los procesos de negocio de las

empresas: relación con proveedores y cliente, organización interna y

compraventa a través de la red (comercio electrónico). El objetivo para 2010

es que el 87% de las PyMES dispongan de sitio Web y que el 55% realicen

actividades de comercio electrónico.

§ Se añade a todo esto el impulsar la implantación de la factura electrónica,

como uno de los resortes más eficaces para promover el uso eficiente de las

TIC´s en las PyMES, facilitando el desarrollo del comercio electrónico.

E-Learning

CRM ERP

Software Libre

Innovación

Investigación

ware Libre

Figura 2.2 Proyectos de solución de TIC`s en las PyMES. Fuente: InfoPyME 2008.

A estos requerimientos se suman los resultados obtenidos del estudio “Las

tecnologías de la información y las comunicaciones en la competitividad de Quito”

realizado por Santa Fe Associates International y la Corporación de Promoción

Económica (CONQUITO) con los consultores Econ. Hernando López Guerrero e Ing.

Hugo Carrión Gordón.

En este trabajo se realizó un proceso de encuesta58 sobre el uso de las TIC en

empresas industriales Pequeñas, Medianas y Grandes del Distrito Metropolitano de

Quito que luego de ser depuradas terminaron en 202 encuestas efectivas.

Tabla 2.6 Distribución de las empresas encuestadas. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates International.

Con este estudio se evidencia que el uso de la computadora y la conexión a Internet

es una situación generalizada para la mayoría de las empresas para diversos

propósitos; esto es particularmente evidente en las empresas grandes mas no así en

el denominador común de las PyMES.

Además, se recalca en el estudio que, “(…) aunque no se puede afirmar que el

sistema de información es el centro nervioso de gestión de las empresas, poco a

poco, las empresas grandes y medianas van transitando hacia mejores prácticas de

gestión que tienen encarnadas la gestión de conocimiento, es decir la transformación

de la información en conocimiento para mejorar el negocio”59.

58 Cuestionario puede ser revisado en el anexo C.

59 Tomado de Las Tecnologías de la Información y las Comunicaciones en la Competitividad de

Quito, Santa Fe Associates International. Pág. 120.

Finalmente el estudio evidenció que de las 202 empresas consultadas, sólo 44 de

ellas se encuentran dentro de características básicas de requerimientos de TIC´s, de

las cuales 30 fueron grandes empresas.

Al respecto se puede observar la siguiente tabla:

Tabla 2.7 Empresas con características de uso avanzado de TIC Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates

International.

Se concluye que como características clásicas para toda empresa que hace uso de

las TIC´s como elemento en el incremento de su productividad son:

§ Disponer de Internet, su uso como una herramienta básica para la gestión.

§ Poseer de sitio web.

§ Poseer correo empresarial.

§ Disponer de servicio de mensajería. (Chat empresarial)

§ Utilización de servicios bancarios electrónicos.

El estudio finalmente añade que las empresas deben caminar hacia negocios

electrónicos haciendo uso de herramientas disponibles para vender por Internet. No

basta con un sitio informativo con una dirección electrónica de contacto sino que es

necesario proveer de sitios Web que se constituyan como elementos fundamentales

en el sistema nervioso del negocio.

En cuanto a conectividad, el 11% de las empresas no cuentan con conectividad local.

El 57% de las empresas tienen red de área local con cableado. Es difícil encontrar

una red exclusivamente inalámbrica.

Si se tiene una red alámbrica y además se tiene un router sencillo, las computadoras

se pueden beneficiar de los dos tipos de conexión: alámbrica e inalámbrica. Lo

normal es la utilización de ambas, sobre todo si se cuenta con computadoras

portátiles.

Tabla 2.8 Tipo de red LAN. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates International.

En conjunto con estos datos presentados tanto por la CAPEIPI como por CONQUITO

y Santa Fe Associates International, se establecen los requerimientos tecnológicos

básicos para facilitar la operación de las PyMES a continuación.

2.3.3. ANÁLISIS DE REQUERIMIENTOS DE LAS PyMES PARA LA

CONSTITUCIÓN DEL CENTRO DE DATOS

En base al trabajo realizado por la Cámara de la Pequeña Industria de Pichincha

(CAPEIPI) (11) con encuestas a más de 3000 empresas y a lo que se suma un

estudio realizado por CONQUITO y Santa Fe Associates (10) con encuestas

realizadas 206 empresas, se puede determinar de manera general los requerimientos

básicos sobre TIC´s en las PyMES.

En tal virtud, se presenta a continuación, producto del análisis de los datos anteriores

del presente capítulo, los requerimientos de las PyMES en la implantación de las

TIC´s como medio de incremento de su productividad y como facilitador de su

operación productiva.

REQUERIMIENTOS

BÁSICOS DE TIC´s

EN LAS PyMES

Fundamentales Deseables Valor

Agregado

Extranet / Internet § Conexión a

Internet de

banda ancha.

§ Dominio

propio.

§ Portal Web

público.

§ Correo

electrónico

propio (para

contacto

clientes).

§ Comercio

electrónico.

§ Portal web

seguro.

§ Webmail.

§ Servicios

bancarios

electrónicos /

Declaración

impuestos vía

Internet.

§ Factura

electrónica.

§ Telefonía.

§ Conexión

segura con

sucursales.

§ Acceso

remoto.

Intranet § Correo

electrónico

empresarial.

§ Mensajería

instantánea.

§ Base de

datos.

§ Control de

usuarios.

§ Portal Web

empresarial

(interno).

§ Transferencia

de archivos.

§ E-Learning.

§ Telefonía.

Otros § Seguridad

informática

extranet /

intranet

§ ERP.

§ CRM.

§ Control de

producción,

ventas, etc.

Tabla 2.9 Requerimientos básicos de TIC´s en las PyMES.

Para poder dar lugar a la satisfacción de los requerimientos antes mencionados, se

analizan los requerimientos técnicos necesarios y se propone a continuación la

implementación de los siguientes servicios:

Servicios Relación con Requerimientos PyMES

§ Stack de protocolos TCP/IP. § Conexión a Internet, Todos los

requerimientos Intranet /Extranet.

§ Servicio de DHCP. § Intranet, configuración dinámica de

equipos.

§ Servicio DNS: Intranet,

Extranet.

§ Portales web (Internos, Externos),

Correo electrónico, Acceso otras

sucursales, manejo de dominio, etc.

§ Servidor de páginas Web § Portales Web (Internos, Externos),

Comercio electrónico, Webmail.

§ Servidor de correo

electrónico.

§ Correo Electrónico (Contacto clientes

y Empresarial), Webmail.

§ Servidor de Mensajería

Instantánea.

§ Mensajería instantánea.

§ Servidor de Base de Datos. § Comercio electrónico, control de

producción, ventas, etc.

§ Servicio de directorio. § Control de usuarios, Seguridad

informática

§ Proxy / Firewall. § Seguridad extranet / intranet,

Conexión a Internet.

§ Establecimiento de DMZ.

§ Seguridad extranet / intranet.

§ Detección de virus y spam

con scanner de mails.

§ Acceso remoto con SSH.

§ Conexión segura con otras

sucursales, Acceso remoto.

§ Servidor FTP.

§ Transferencia de archivos.

§ Establecimiento de VPN. § Conexión segura con otras

§ Aplicaciones de servicio de

Voz sobre IP.

§ Telefonía.

Tabla 2.10 Requerimientos técnicos para TIC´s en las PyMES.

A continuación se presenta una descripción más detallada de los servicios a

implementarse para las PyMES.

2.3.3.1. Internet

Como se ha podido mencionar en los estudios preliminares, el acceso a Internet

constituye un aspecto fundamental en el desarrollo de las PyMES.

El Internet es una “Red de Redes Global”, la cual mediante el uso del stack de

protocolos TCP/IP, permite la unificación de redes físicas heterogéneas para el

intercambio de información.

Sobre ésta red global circulan diversos tipos de protocolos de aplicación; uno de ellos

y posiblemente el más popular es el conjunto de protocolos World Wide Web (WWW)

el cual hace posible el despliegue de contenido Web mediante el uso de navegadores

de Internet.

Sin embargo, no solamente contenido Web puede viajar sobre Internet, sino que

también lo hacen protocolos de transmisión de Correo Electrónico (SMTP),

Transferencia de Archivos (FTP, P2P), Mensajería Instantánea, Acceso remoto,

Telefonía IP, Juegos en línea, etc.

Según los datos presentados en el estudio realizado por Santa Fe Associates y

CONQUITO, en las empresas grandes y medianas una conexión de Internet es

general; en cambio el 11,5% de las microempresas encuestadas no tienen conexión a

Internet.

Tabla 2.11 Tipo de Conexión a Internet por tamaño de empresa. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates

International.

Adicionalmente, se presentan los siguientes datos referentes a la velocidad de

conexión. Así se puede observar que el 10% de las empresas utiliza conexión de

Internet mayor a 512 Kbps. El 61% utiliza conexión de 256 Kbps o menores.

Tabla 2.12 Velocidad de conexión a Internet. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates International.

Con un acceso a Internet de 256 Kbps permite a las PyMES enviar y recibir correo,

chatear e incluso para establecer conexión de voz por Internet. Este valor deberá ser

planificado en función del número de usuarios a utilizar la red. Así por ejemplo la

gerencia de las empresas en un 88% utiliza Internet para enviar y recibir correos

electrónicos; el 69% para revisar información de negocios; y el 50% para ver

información de mercados.

Tabla 2.13 Usos de Internet en la gerencia. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates International.

Una de las manifestaciones sobre el uso de las TIC, por parte de la empresa, es el

grado de aprovechamiento de las posibilidades de interacción con sitios Web de su

interés, en especial en el ámbito de los negocios. Al respecto, la encuesta evidenció

que el 90% de las empresas utiliza el sitio Web para hacer consultas con los bancos y

el 52% para observar el mercado.

Tabla 2.14 Usos de Internet por la empresa. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates International.

Otra de las necesidades inminentes para las PyMES es el acceso al Portal de

Compras Públicas de Ecuador definido como el Sistema Informático Oficial de

Contratación Pública del Estado Ecuatoriano.

Éste constituye una iniciativa del Sistema Nacional de Contratación Pública y su

funcionamiento se da en base a una aplicación Web

(http://www.compraspublicas.gov.ec) para la adquisición de bienes y servicios a

través de subastas inversas electrónicas en las cuales los proveedores de bienes y

servicios equivalentes pujan el precio ofertado, hacia la baja. Para ello el acceso a

Internet cumple un papel imprescindible.

Entre otras iniciativas para las PyMES en Internet se pueden mencionar:

Diagnóstico y Estrategia de Gobierno Electrónico. Fuente CONATEL, marzo 2005.

Tabla 2.15 Diagnóstico y Estrategia de Gobierno Electrónico. Fuente CONATEL, marzo 2005.

A continuación se presentan de manera general otros requerimientos tecnológicos de

las PyMES.

2.3.2.1.1. Correo electrónico

El correo electrónico es un servicio de red que permite a sus clientes el envío y

recepción de mensajes. Para lograr este acometido, cada cliente debe disponer de

una dirección de correo única conformada por un nombre de usuario y un dominio

separados por el signo de arroba (@). Los clientes proporcionan su usuario y

contraseña para asociarse a su respectivo buzón de correo en un servidor, este

buzón se encarga de almacenar, enviar y recibir todos los mensajes del respectivo

usuario.

Para enviar un mensaje electrónico, el cliente debe enviar el correo hacia el servidor

de correo de su dominio mediante el protocolo SMTP, este a su vez traslada el

mensaje hacia otro servidor de correo empleando el mismo protocolo, el mensaje

puede pasar por varios servidores hasta que finalmente llegue al servidor del dominio

correspondiente a la dirección de correo del destinatario. Entonces en el momento en

que el destinatario se asocie a su cuenta obtendrá el mensaje mediante el protocolo

POP3 o IMAP.

El correo electrónico se ha convertido en un servicio de red de gran importancia

debido a que ha desplazado en gran medida a otros medios de comunicación

tradicionales por su mayor velocidad, eficiencia, conveniencia y bajo costo.

Para el caso de las empresas el correo electrónico se ha vuelto un servicio

fundamental, al permitir no solo la comunicación entre sus miembros, sino también

con distintos clientes y posibles socios de negocios.

En el siguiente cuadro proporcionado en el estudio de Santa Fe Associates y

CONQUITO, se observa que en general el 68% de las empresas tienen correo

empresarial. En la pequeña empresa los correos electrónicos se distribuyen entre

correo empresarial y correo asociado a un proveedor de Internet casi en partes

iguales. Un 39% de las microempresas tienen correos gratuitos. El 19% de los

microempresarios no posee correo electrónico.

Tabla 2.16 Tipo de cuentas de correo electrónico en la empresa. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates

International.

Otro factor que hace deseable el implementar el servicio de correo electrónico es el

ecológico, en la actualidad coda vez son más las empresas que buscan reducir el uso

de papeles instaurando incluso políticas “cero papeles” bajo este concepto todas las

instrucciones y comunicaciones entre empleados se puede realizar mediante el uso

del correo electrónico sin necesidad de imprimir los tradicionales memos e informes.

2.3.2.1.2. Comercio electrónico

Figura 2.3 Caricatura e-Commerce.

El comercio electrónico se refiere a la compra y venta de productos y servicios a

través de un medio electrónico. Principalmente se realiza utilizando como medio el

Internet, en este caso los clientes acceden al portal web de la empresa y tienen la

posibilidad de adquirir sus productos y servicios que son generalmente cancelados

mediante una transferencia de fondos electrónica.

Para establecer un comercio electrónico lo único que se necesita es el disponer de

una página web segura en la cual un cliente pueda crear una cuenta, autenticarse,

buscar el producto o servicio requerido y realizar las transacciones de transferencia

de dinero.

Las ventajas ofrecidas por el negocio electrónico dependen en gran medida de las

que ofrece trabajar con Internet. La Red está disponible en cualquier parte del mundo,

veinticuatro horas al día y siete días por semana; es fácil de utilizar; hacer llegar las

transacciones al usuario final no requiere una gran inversión. Los costes de conectar

con el cliente son bajos en comparación con los relativos a canales de distribución

convencionales; es sumamente fácil integrar procesos, productos y servicios una vez

que estos hayan sido informatizados.60

60 Fuente: Internet en las PyMES, Luis Arroyo Galán (2005). Pág 59, 60, 61.

2.3.2.1.3. Páginas web

Las páginas web son documentos de hipertexto que pueden ser visualizados a través

de navegadores web o web browsers. En éstas se puede incluir contenido estático

(informativo, contacto, etc.) como contenido dinámico (consultas a bases de datos,

aplicaciones web, streaming de audio y video, etc.)

Las páginas web constituyen la interfaz que da la cara al usuario; detrás de éstas

puede existir una serie de aplicaciones trabajando y cuyos resultados son

presentados en un browser.

En el caso de las PyMES, las páginas web permiten brindar el acceso, a clientes

potenciales alrededor del mundo, a conocer la organización, realizar pedidos en línea,

contactarse con representantes, etc. Es decir que una página web es la “cara” que da

al mundo nuestra organización.

Adicionalmente las páginas web son utilizadas al interno de la organización,

prestando soluciones de webmail, bibliotecas de información, aplicaciones web

empresariales, etc.

Para dar funcionamiento a las páginas web, se hace uso del protocolo de capa

aplicación HTTP (Hypertext Transfer Protocol) que mediante el uso de un servidor

Web, permite el despliegue de la información en los clientes a través de sus

navegadores.

En este sentido en el estudio de Santa Fe Associates y CONQUITO, el 57% de las

empresas manifiestan no tener un sitio Web. Si tomamos sólo las empresas que

exportan, el 74% de ellas no lo tiene.

Tabla 2.17 Disponibilidad de Sitio Web. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates International.

Las páginas web se encuentran asociadas a un dominio de Internet, y en el caso de

las PyMES éste les da la posibilidad de posicionarse como una marca global. Sin

embargo, las empresas que tienen un dominio no necesariamente implica que tengan

un sitio Web. Algunas de las empresas no tienen el sitio corporativo como tal y están

usando el dominio para Webmail. Otras empresas están en proceso de creación del

sitio.

En una revisión de los sitios web de las PyMES61, se encontró que por lo menos el

20% de ellos no funciona correctamente y/o tienen problemas de usabilidad. Algunos

de estos sitios no son manejados directamente por la empresa, o no están a nombre

de la misma, sino a nombre del proveedor de servicios tecnológicos.

Tabla 2.18 Disponibilidad de dominio propio. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates International.

El uso que se le da a los sitios Web es el siguiente:

Tabla 2.19 Utilización del sitio Web empresas no exportadoras. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates

International.

61 Estudio adicional realizado por Santa Fe Associates y CONQUITO que sin embargo no formó parte de su estudio principal.

Tabla 2.20 Utilización del sitio Web empresas exportadoras. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates

International.

Los datos presentados muestran que el sitio está destinado mayormente para brindar

información de productos y de contacto. El estudio también presentó que aquellos

sitios de comercio electrónico adolecen de las características necesarias de

mecanismos electrónicos de pago.

2.3.3.2. Intranet

Como se ha podido identificar en los enunciados anteriores, los impactos de Internet

en las PyMES se producen en dos niveles, uno interno y el otro externo. Por un lado,

Internet permite obtener una mayor productividad al interior de la organización con un

menor tiempo de respuesta a clientes, reducción de costos, mayor rentabilidad, etc.;

por otro lado, exteriormente, Internet permite mejores relaciones con los clientes,

proveedores, mercado y administración de varias tareas.

Sin embargo, todos estos beneficios que produce Internet de nada sirven si al interior

de la empresa no se manejan canales de comunicación internos que permitan

coordinar las tareas institucionales, la planificación y la toma de decisiones en base a

los datos proporcionados por cada una de las áreas de la organización.

Es así de esta manera que Internet en las PyMES se ve complementado con una

Intranet corporativa.

Mediante el establecimiento de una intranet con el empleo del stack de protocolos

TCP/ IP, las empresas pueden poner en funcionamiento redes internas para el uso

exclusivo de sus empleados convirtiendo a la red interna en el sistema nervioso de la

empresa.

Así los atributos de una intranet podrían condensarse en los siguientes (12):

§ Red propia: a precio bajo.

§ Ahorro de tiempo: Proporciona herramientas para agilizar el trabajo diario.

§ Cultura corporativa: Potencia la identidad corporativa.

§ Fidelización: Herramienta para implicar al empleado con la empresa.

§ Reducción de costes: Ahorrar en costes derivados de la comunicación

(papelería, distribución, telefonía, etc.), mayor rendimiento de los

empleados y una mejora en la productividad.

§ Inmediatez: Es un canal de comunicación rápido y directo.

§ Accesibilidad: Desde cualquier parte del mundo.

§ Feedback: Comunicación interactiva con el entorno.

§ Integridad: Coordina el trabajo a distancia y une a los empleados.

§ Operatividad: Sirve para integrar una red de comerciales.

Para dar lugar a una intranet corporativa en las PyMES son necesarios algunos

servicios, los cuales permitirán tanto el funcionamiento de Internet en la organización

como de la intranet misma.

A continuación se mencionarán los servicios requeridos por las PyMES.

2.3.2.2.1. DHCP

El Protocolo de Configuración Dinámica de Hosts, DHCP (Dynamic Host

Configuration Protocol) es un protocolo de red que permite la asignación dinámica y

automática de todos los parámetros de configuración de una red IP, es decir,

dirección IP, máscara, ruta de enlace predeterminada, dirección del DNS, entre otros.

Figura 2.4 Diagrama indicando a un servidor DHCP brindando a los hosts los datos para conectarse a la red. Fuente: http://adrian15.wordpress.com/2007/10/07/protocolo-dhcp/

Para brindar este servicio se debe configurar un servidor de DHCP que contenga una

lista de direcciones IP y todos los parámetros requeridos para acceder a la red.

Cuando un cliente se conecta al servidor se le asigna una de las direcciones

disponibles por un tiempo determinado.

Este servicio facilita enormemente el proceso de configuración y administración de

una red, ya que evita la necesidad de asignar direcciones IP a cada una de las

máquinas que conforman una red, además que permite un control centralizado de las

mismas.

En el caso de las redes empresariales de las PyMES en que se enfoca el presente

proyecto, se puede considerar que estas tienden a un crecimiento tecnológico por lo

que es recomendable la implementación de este protocolo desde el inicio de la

implementación de la red.

2.3.2.2.2. DNS

El Sistema de Nombres de Dominio, DNS (Domain Name System) es un sistema

jerárquico de nomenclatura para todo tipo de recurso conectado a una red. Su función

se basa en la traducción de los nombres de dominio de dichos recursos en su

correspondiente dirección IP y viceversa. La creación de este servicio se dio debido a

que resulta complicado recordar muchas direcciones IP, mientras que se facilita el

proceso si lo que se tiene que recordar es un nombre relacionado con el recurso

buscado.

Además de brindar información de direcciones IP y nombres de dominio, un servidor

DNS también almacena otro tipo de información, como una lista de los servidores que

aceptan correos electrónicos para un determinado dominio.

El servicio de DNS es un componente esencial para el funcionamiento de Internet y

de una Intranet, por lo que es necesaria su existencia para cualquier equipo que

requiera conexión a Internet (en este caso el Proveedor de Servicios de Internet es

quien se encarga de proporcionar el DNS). En el caso de una red corporativa es

necesaria la existencia de un servidor DNS propio para poder direccionar todas las

consultas internas como para que se pueda acceder a los recursos desde una red

externa.

Figura 2.5 Funcionamiento típico de una consulta de DNS recursiva. Fuente: http://nirlog.com/2006/03/28/dns-amplification-attack/

2.3.2.2.3. Proxy

Un Proxy es un servidor intermediario que permite a otros equipos conectarse a una

red a través de él, es decir, de una forma indirecta. Para lograr esto, cuando un

equipo trata de acceder a un recurso, pasa primero por el proxy quien se encarga de

establecer la comunicación aparentando ser el equipo que necesitaba el recurso

primeramente.

Figura 2.6 Ubicación del proxy para brindar a la intranet seguridad y conexión con el Internet.

Fuente: http://www.computerrepairmaintenance.com/tag/anonymous-web-surfing-with-a-proxy

Este tipo de servicio brinda algunos tipos de funcionalidades distintas, pero sobretodo

se emplea para permitir el acceso a internet a todos los miembros de una red

mediante el empleo de solo una dirección IP pública.

Además de esto, el proxy permite el almacenamiento en caché en el servidor, es

decir que, cuando un usuario accede a una página web esta puede ser almacenada

en el servidor de manera que las futuras consultas de todos los usuarios hacia esa

página serán respondidos por el proxy sin la necesidad de que la consulta pase a

Internet.

Finalmente, otra de las características más usadas del proxy es para filtrar

contenidos. El proxy representa un equipo centralizado de acceso a redes, por lo que

todo contenido que entre o salga de la red debe pasar por él, es decir que al añadir

filtros en el proxy se puede bloquear ciertas peticiones prohibidas.

El proxy es un servicio altamente valorado en todo tipo de organizaciones y

empresas, debido a que permite reforzar las políticas de uso de la red y brindar una

mayor seguridad a la misma.

Mediante el uso adecuado de un proxy con reglas de filtrado claramente definidas, es

posible controlar que los empleados no accedan a páginas con contenidos peligrosos

o no relacionadas con su ámbito laboral. Esto reduce el tráfico en la red e incrementa

significativamente la seguridad de la misma.

2.3.2.2.4. Directorio

Un servicio de directorio se refiere a una base de datos especializada que se

encuentra optimizada para búsquedas y permite almacenar información organizada

acerca de los recursos de una red (usuarios, impresoras, computadores, entre otros).

Esto permite el centralizar la administración de los mismos, facilitando el control del

nivel de acceso que tengan los usuarios a ciertos recursos compartidos además de

permitir a los mismos el cambiar de equipo de trabajo por otro en el mismo dominio y

mantener sus permisos en la red sin la necesidad de realizar ninguna configuración.

El servicio de directorio brinda un sinnúmero de beneficios para las organizaciones,

así: permite la administración de los accesos a los recursos de una forma

centralizada y segura, además permite almacenar información de cada recurso

disponible como por ejemplo las cuentas de correo y las listas de distribución.

Además puede ser accedido por distintas aplicaciones para la obtención de

información.

Cada recurso del que se dispone corresponde a un objeto en la base de datos, que

se halla plenamente identificado por un espacio de nombres. El diseño de este

espacio de nombres de directorio sigue reglas para asegurar que cada nombre sea

único e inequívoco.

2.3.2.2.5. Firewall

Un firewall o cortafuegos es un equipo o programa de seguridad que se coloca entre

varias redes y que se encarga de filtrar el tráfico que intente pasar a través de él,

bloqueando todos los accesos que no cumplan con los criterios de seguridad

configurados. Su principal función es la de brindar seguridad a una intranet evitando

que usuarios no autorizados puedan entrar.

Cada mensaje que quiera salir o entrar de la red deberá pasar por el firewall el cual lo

analizará de acuerdo a las políticas de acceso que tenga configuradas, y de acuerdo

a estas puede dejar pasar, bloquear o desechar al mensaje.

Para el ámbito empresarial, se puede considerar que la información almacenada en la

intranet es altamente sensible y privada, por lo que resulta fundamental la inclusión

de un sistema de seguridad perimetral como el firewall.

Figura 2.7 Representación de algunas de las ventajas que puede brindar un servicio de directorio. Fuente: http://www.quest.com/identity_management/images/idm_diagram_web.jpg

Figura 2.8 Representación del firewall para brindar seguridad a una red LAN.

Otra aplicación muy útil del firewall es la creación de zonas desmilitarizadas DMZ ().

Estas zonas se crean cuando se conecta una red adicional al firewall en la que se

encuentren los equipos y datos a los que se requiera tener acceso por todas las

redes involucradas. Con esto se logra que estos recursos se compartan entre las

redes pero ninguna red accederá directamente a otra sino que se encontrarán en una

zona intermedia DMZ.

2.3.2.2.6. Telefonía ip

El servicio de telefonía IP es aquel que brinda una comunicación telefónica en la cual

se transmite la voz sobre IP (VoIP), esto quiere decir que, para poder establecer una

comunicación, la señal auditiva debe ser previamente digitalizada en paquetes. Con

esto se elimina la intervención de una compañía telefónica convencional para realizar

llamadas internas en una misma red, esta línea telefónica externa sólo se emplea la

PSTN (Public Switched Telephone Network)62 cuando se requiere realizar llamadas

externas a la misma con lo que se abaratan los costos de comunicación.

62 PSTN es la red telefónica pública conmutada

Para poder establecer un servicio de telefonía IP, el estándar VoIP define una

estructura basada en tres elementos fundamentales: Terminales, Gatekeepers y

Gateways. Un terminal se refiere al equipo telefónico que se empleará en la telefonía

IP, no son los equipos tradicionales sino que funcionan en base a los protocolos de

VoIP, se pueden implementar tanto en software como en hardware. Los Gatekeepers

son los equipos en que se centra la organización de VoIP, estos vienen a reemplazar

a las centrales telefónicas, por lo general se tratan de aplicaciones de software por

las que pasan todas las comunicaciones. Finalmente los Gateways son las puertas de

acceso por las que se enlaza la red telefónica convencional con la red de telefonía IP

Figura 2.9 Estructura de una arquitectura básica de un servicio de telefonía IP. Fuente: http://www.e-advento.com/soluciones/telefoniaip.php

Los protocolos típicos empleados para VoIP son H.323 y SIP, pero también se

disponen de protocolos propietarios como Skinny Client Control Protocol de Cisco,

MiNet de Mitel, CorNet-IP de Siemens, Skype que es un protocolo peer-to-peer de la

aplicación del mismo nombre e IAX que es el protocolo para la comunicación entre

las PBXs de Asterisk, una de las soluciones más empleadas en lo que se refiere a

telefonía IP y un estándar para los demás sistemas de comunicaciones de datos.

Para todo tipo de empresa, el empleo de telefonía IP trae grandes ventajas, siendo la

principal la gratuidad de todas las comunicaciones internas, además de la posibilidad

de disponer tantas de estas líneas telefónicas como sea necesario sin perder las

comunicaciones con la red telefónica tradicional. También se debe considerar que el

desarrollo de codecs (Codificadores/Decodificadores) para VoIP ha permitido que la

voz se codifique en paquetes de datos de pequeño tamaño, por lo que las

comunicaciones de voz sobre IP requieren anchos de banda muy reducidos por lo

que no afecta de manera significativa el rendimiento de la red.

2.3.3.3. Otros Servicios (10)

2.3.2.3.1. Mensajería instantánea

La mensajería instantánea (IM) constituye una forma de comunicación en tiempo real

entre dos o más personas basada en texto. El texto es enviado a través de

dispositivos conectados a una red, pudiendo funcionar tanto en la Intranet corporativa

como en Internet.

La mensajería instantánea requiere el uso de un cliente de mensajería instantánea

que realiza el servicio. Éste permite satisfacer necesidades de comunicación

inmediata entre diferentes áreas de la organización, ya sea con clientes así como

dentro de la organización.

2.3.2.3.2. Seguridad Informática

Una de las preocupaciones centrales, y que a veces es un obstáculo para el

desarrollo del comercio electrónico, está relacionada con los problemas de seguridad

de la empresa.

Para ello es necesaria la implementación de medidas anti-hacking, firewall, proxy,

antivirus, transmisión segura y backups de datos, en conjunto de una política general

de seguridad, etc.

Por ello se muestra que el 94% de las empresas tienen protección antivirus y un 59%,

algún mecanismo de respaldo de la información.

Tabla 2.21 Disponibilidad de sistemas de seguridad informática. Fuente: Las Tecnologías de la Información y las Comunicaciones en la Competitividad de Quito, Santa Fe Associates

International.

2.3.2.3.3. Software de Gestión Organizacional

Según los datos de Santa Fe Associates y CONQUITO, el 85% de las empresas

posee un sistema de contabilidad. A esto le siguen los sistemas de inventarios y de

recursos humanos. Por otra parte los microempresarios tienen tercerizado el sistema

de contabilidad; sin embargo su contador tercerizado hace uso de software de

contabilidad.

Se destaca también el alto porcentaje de utilización de sistemas de información como

ERPs63 como por ejemplo SAP.

63 Para alternativas de software libre de ERP y CRM referirse al anexo D.

2.4. APLICABILIDAD DE LA ARQUITECTURA SERVIDOR

VIRTUALIZADO PARA FACILITAR LA OPERACIÓN DE

LAS PyMES

En base a los requerimientos analizados en el tema anterior, es imprescindible el

posibilitar una solución tecnológica que brinde todos estos servicios para las PyMES

y a la vez que esté acorde a su situación económica, técnica, de recursos humanos,

entre otros.

Como se ha podido ver en el capítulo 1, la virtualización de servidores permite la

implementación de aplicaciones y servicios a través de varias máquinas virtuales

sobre un mismo hardware; sobre cada una de las cuales corre un sistema operativo

que posibilita su funcionamiento

Cabe indicar además que de acuerdo a los datos proporcionados en la tabla 2.7, las

empresas que emplean de manera avanzada las TIC´s constituyen un porcentaje

limitado (8 PyMES de entre 206 empresas entre Grandes, Medianas, Pequeñas y

Micro); es por este motivo que es imprescindible el proporcionar una solución

prototipo para ser adoptada por las PyMES y así mejorar su rendimiento productivo.

Es así de esta manera que los servidores virtualizados pueden constituirse en

plataformas para la implementación de los requerimientos de TIC´s en las PyMES a

través de los servicios necesarios para su operación.

A continuación se establecerán las razones del porqué la virtualización de servidores

beneficia a las pequeñas y medianas empresas en la satisfacción de sus

requerimientos de TIC´s, dando lugar así a la aplicabilidad de esta tecnología.

2.4.1. IMPACTO DE LA ARQUITECTURA SERVIDOR

VIRTUALIZACIÓN EN LAS PyMES

2.4.1.1. Ventajas y aplicaciones brindadas por los servidores

virtualizados para las PyMES

A continuación se presentan las ventajas de la aplicación de la virtualización de

servidores en las PyMES. Cabe indicar que en el capítulo 1, puede encontrarse otras

ventajas de la virtualización de servidores las cuales son aplicables no solo a las

PyMES, sino a diferentes tipos de organizaciones.

2.4.1.1.1. Centralización, Descentralización, Consolidación

La adopción del tipo de infraestructura tecnológica para la implementación de los

servicios en las organizaciones puede hacerse en función de tres paradigmas:

centralización, descentralización y consolidación.

De manera general, la centralización, típicamente basada en la era Mainframe, brinda

altos índices de rendimiento computacional, sin embargo necesita de grandes

requerimientos de equipamiento así como de sistemas de refrigeración, consumo de

energía, etc., por lo cual constituye una solución de muy alto costo.

Por otra parte, con la reducción de costos del hardware x86, se da paso a la

descentralización. Con un sistema descentralizado, se permite la implementación de

servicios en varios servidores físicos lográndose obtener beneficios de estabilidad de

los mismos, así como aislamiento de aplicaciones entre cada servidor y seguridad del

sistema por consecuencia de su aislamiento, entre otros beneficios.

Sin embargo, producto de la necesidad de varios servidores físicos, los costos de

equipamiento continúan siendo elevados (se requiere de mayor cableado, equipos de

conectividad, equipos de refrigeración, etc.). A esto se suma el incremento en el

consumo de energía por cada servidor, reducción del espacio físico, mayor

complejidad de administración y aumento en gastos de mantenimiento anual por cada

equipo.

Adicionalmente, a medida que las características del hardware x86 mejoraban, la

implementación de una aplicación o servicio por servidor mostraban cada vez una

reducción de la eficiencia de cada máquina. Así cada servidor pasa a un estado de

subutilización del 85 al 90 por ciento del tiempo, siendo el uso de procesamiento en

un promedio del 15%.64

Así un ejemplo simple de una configuración descentralizada compuesta de cinco

servidores x86 de doble núcleo, con licencia por cada uno y equipamiento de

conectividad sería el siguiente:

Figura 2.10 Implementación descentralizada de cinco servidores. Fuente: Virtualization with Xen, Syngress 2007, pág 11.

64 Datos obtenidos de: (13), pág. 9.

En cuanto a los costos de un ambiente descentralizado, éstos se ven multiplicados

por el número de servidores requeridos; estos factores son producto del crecimiento

horizontal del centro de datos, así en base al ejemplo anterior se tiene:

Componente Costo Unitario en Dólares (C.U.)

Costo Total en Dólares (C.U. x5)

Hardware65 $670.00 $3350.00 Software*66 $2000.00 $10000.00

Energía por año67 $116.00 $580.00 Refrigeración por año77 $150.00 $750.00

Total * (excluyendo licencias) $936.00 $4680.00 Total $2936.00 $14680.00

Tabla 2.22 Costo de un ejemplo de implementación descentralizada de cinco servidores.

Por otro lado, se tiene a la consolidación la cual es introducida con la virtualización de

servidores.

El logro de la consolidación es la unificación y combinación de los sistemas. Así en el

caso de la virtualización, las cargas de trabajo son unificadas en menor número de

plataformas físicas capaces de obtener su demanda de recursos computacionales

como CPU, memoria, y I/O de un mismo hardware. Así también, la consolidación

permite la combinación de varias instancias de servidores y con ello posibilitando

combinar sistemas operativos y sus cargas en una forma estratégicamente

localizadas en un hardware con características adecuadas. Con esto se logra una

mejor utilización del hardware mediante una disminución del desperdicio de recursos

por servicios que no requieren del 100% de utilización del hardware.

Adicionalmente, la consolidación favorece al mantenimiento de aplicaciones críticas

del negocio que tienen un nexo vinculante a un sistema operativo o hardware

específico. Con esto se elimina una atadura a un determinado fabricante de

hardware.

65 Revisar anexo I, costo del hardware implementado.

66 Datos obtenidos en (13), pág. 11.

67 Dato calculado en base a un consumo de 0.1 kW mensuales o 74.4 kWh mensuales a 13 centavos de dólar por kWh. Fuente: http://www.conelec.gov.ec/calculokw.php?menu=41&submenu1=42&nummes=31&ind=8

Se añade que la virtualización sobre el hardware x86, admite diversos sistemas

operativos, entre ellos Windows, Linux, Unix, convivir en un mismo hardware

reduciendo así costos de adquisición y mantenimiento.

Así, con la consolidación se permite participar de los beneficios de cada uno de los

tipos de paradigmas de descentralización y centralización:

§ Sobre un mismo hardware x86 (, se implementan varias máquinas virtuales

o servidores virtuales en un ambiente descentralizado.

§ Cada servidor virtual conserva las propiedades de la descentralización:

cada servidor conserva su aislamiento entre sí, brindándole seguridad,

estabilidad, rendimiento y facilidad de administración del software.

§ Se obtiene una administración centralizada de los servicios en un solo

servidor, lo cual la hace más simple y de menor costo.

§ El crecimiento horizontal del sistema se lo realiza de manera lógica con la

implementación de servidores virtuales, lo cual ahorra significativamente

los costos de equipos, sistemas de refrigeración, consumo de energía, etc.

§ Se obtiene un mejor rendimiento de los servidores, aprovechando las

potencialidades de CPU, memoria, virtualización del hardware x86 actual.

§ Los costos de mantenimiento anuales se reducen significativamente a

solamente el número de servidores virtuales aprovisionados.

A todo esto se añade:

§ Mejor retorno de la inversión y menor costo total de propiedad (TCO)

§ Ahorro de dispositivos de conectividad (puertos de switches, routers, hubs,

etc.), infraestructura de soporte incluyendo cableado, tarjetas de red, cada

uno por máquina virtual etc.

§ Creación de un ambiente de pruebas.

§ Rápida recuperación frente a fallas de software (debido a la rápida carga

de backups de máquinas virtuales).

§ Reducción en la emisión de emisiones de CO2 (producto del menor

consumo de energía).

§ Rendimiento de cada máquina virtual se acerca al rendimiento nativo, a

una fracción del costo de todo el hardware.

§ Una sola licencia requerida por servidor virtual.68

Tomando el mismo ejemplo tratado anteriormente, y aplicando un esquema

consolidado, se tiene:

Figura 2.11 Implementación virtualizada de cinco servidores. Fuente: Virtualization with Xen, Syngress 2007, pág 12.

En la imagen anterior se puede observar que el porcentaje de utilización del servidor

virtualizado sube al 75% frente a un 15% de una implementación eminentemente

descentralizada69, así como menor número de uso de puertos y dispositivos de

conectividad.

68 Dependiendo de la plataforma de virtualización y el sistema operativo Host – Guest.

69 Datos obtenidos de: (13), pág. 13.

Un cálculo simple sobre la implementación de un esquema de virtualización de

servidores muestra los siguientes resultados.

Componente Costo Unitario (C.U.) Costo Total (C.U.x1) Hardware70 $670.00 $670.00 Software*71 $2000.00 $2000.00

Energía por año72 $116.00 $116.00 Refrigeración por año74 $150.00 $150.00

Total * (excluyendo licencias) $936.00 $936.00 Total $2936.00 $2936.00

Tabla 2.23 Costo de un ejemplo de implementación virtualizada de cinco servidores.

Como se ha podido observar en los resultados anteriores y a lo largo del presente

tema, la implementación de una solución virtualizada para las PyMES, permitirá no

solamente satisfacer sus necesidades tecnológicas básicas antes mencionadas, sino

también sus económicas pues está acorde a su situación económica característica,

ahorrándole una cantidad considerable de recursos, impulsando así la adopción de

las TIC´s.

A continuación presentamos una breve comparación entre las diferentes

implementaciones a lo que se suma un factor adicional como es el ahorro en

licenciamiento del software (componente que encarece la implementación).

Implementación Costo Unitario Costo Total

Virtualizada $2936.00 $2936.00 Descentralizada $2936.00 $14680.00

Ahorro Implementación Virtualizada (Software Licenciado)

- $11744.00

Tabla 2.24 Ahorro en implementación virtualizada de cinco servidores con software licenciado.

70 Revisar anexo I, costo del hardware implementado.

71 Datos obtenidos en (13), pág. 11.

72 Dato calculado en base a un consumo de 0.1 kW mensuales o 74.4 kWh mensuales a 13 centavos de dólar por kWh. Fuente: http://www.conelec.gov.ec/calculokw.php?menu=41&submenu1=42&nummes=31&ind=8

Implementación Costo Unitario Costo Total

Virtualizada $936.00 $936.00 Descentralizada $936.00 $4680.00

Ahorro Implementación Virtualizada (Software Libre)

- $3744.00

Tabla 2.25 Ahorro en implementación virtualizada de cinco servidores con software libre.

2.4.1.1.2. Confiabilidad y Disponibilidad

La virtualización dispone de confiabilidad a través de tres áreas: contención ante

fallas, simple recovery, y capacidades built-in en las diferentes herramientas de

virtualización.

En el aspecto de la contención ante fallas, la virtualización de servidores permite a las

PyMES asegurar la continuidad de sus operaciones. Esto se produce aprovechando

la capacidad de aislamiento de cada máquina virtual. Así ante cualquier fallo

producido en una VM, el funcionamiento de las otras máquinas virtuales no se ve

afectado gracias a la abstracción del hardware subyacente.

Adicionalmente hay que indicar que cada máquina virtual dispone

independientemente de la misma confiabilidad del hardware sobre el que se ejecuta.

Por otra parte, la disponibilidad de una arquitectura servidor virtualizado es

consecuencia de un entorno computacional confiable. Con esto se logra ahorrar

costos en equipamiento de servidores de failover para mantener la disponibilidad del

sistema durante los periodos planeados o no de para.

Figura 2.12 Implementación virtualizada de alta confiabilidad. Fuente: Virtualization with Xen, Syngress 2007, pág 319.

Para dar lugar a un entorno de disponibilidad también es requerido el

acompañamiento de equipamiento adicional de conectividad, almacenamiento, etc.,

como se puede observar en la figura anterior.

La virtualización satisface esta característica mediante la provisión “just-in-time” o por

demanda de particiones virtuales adicionales. Así las capacidades de bulit-in de las

herramientas de virtualización así como el simple recovery, permiten disponer de

máquinas virtuales de back-up que se pueden activar cuando se produce el fallo de

una o varias máquinas virtuales de producción. Así de ésta manera se asegura

mediante un repositorio de máquinas virtuales previamente configuradas disponer de

su actividad en cuestión de minutos.

2.4.1.1.3. Escalabilidad

La escalabilidad es otro beneficio producido por la virtualización de servidores. Ésta

permite la utilización del servidor virtual de acuerdo a las necesidades de la

organización; diferentes máquinas virtuales pueden funcionar en un mismo servidor

de acuerdo a parámetros, permitiendo el funcionamiento de varios servicios de

acuerdo a las necesidades incurrentes. Así, un servidor virtual puede aumentar o

disminuir sus capacidades de servicio de acuerdo a lo requerido.

La escalabilidad permite también aumentar la eficiencia del sistema dando lugar a

una mejor utilización de los recursos y con ello disminuir el procesamiento

desperdiciado.

Por ejemplo es posible con la virtualización de servidores, dar lugar a una aplicación

para clientes en un determinado tiempo y en determinados días de una semana

laboral, y ocupar el potencial desocupado del servidor en otras aplicaciones durante

la noche o fines de semana.

La virtualización de servidores provee de seguridad a cada una de las máquinas

virtuales, haciendo uso de su propiedad de aislamiento entre VM´s. Así, en caso de

verse afectada una máquina virtual mediante la intrusión de un visitante desconocido,

éste no sabrá de la existencia de las otras máquinas virtuales.

Así, en caso de infecciones de virus, ataques de hackers, crackers, spyware,

malware, troyanos, etc. la afección se verá dirigida exclusivamente a una máquina

determinada, aislando al resto de la infraestructura virtual; esto posibilita la restitución

en poco tiempo del sistema mediante la aislación de la máquina, carga de una nueva

máquina virtual de back-up (limpia de ataques) y de aplicaciones o parches de

seguridad, etc.

Adicionalmente, con la virtualización, las configuraciones de seguridad pueden ser

aplicadas exclusivamente a una o varias máquinas virtuales en lugar del resto de

VM´s que pueden necesitar de una configuración de seguridad diferente. Esto permite

diferenciar en un mismo hardware de permisos de seguridad, credenciales, y acceso

de diferentes usuarios.

2.4.1.2. Desventajas de la virtualización de servidores

2.4.1.2.1. Fallos de hardware

Con la virtualización se diseña en su mayoría un completo centro de datos sobre un

mismo hardware. Así, un mismo servidor virtual puede contener servidores virtuales

de base de datos, correo electrónico, DNS, dhcp, páginas web, etc.

En caso de un daño general del hardware sobre el cual corren las máquinas virtuales,

la afectación sería sobre todos los servidores virtuales que corren sobre éste.

Entre los daños pueden indicarse: fuentes de alimentación, placa madre, disco duro,

memoria RAM, etc.

Para remediar este posible escenario, es recomendable tener un servidor virtual de

back-up, lo cual incrementaría el costo de una implementación virtualizada.

2.4.1.2.2. Congestión en varios dispositivos

Como las máquinas virtuales hacen uso de los dispositivos de red (tarjetas de red)

reales, dependiendo del número de VM´s, se puede llegar a una pérdida de eficiencia

en la velocidad de respuesta de las mismas.

Es por ello que la configuración de un equipo real sobre el cual correrán servidores

virtuales, debe ser planificada en función del número de VM´s a implementarse, los

servicios a dar, entre otros parámetros.

Este problema es solucionado con un adecuado dimensionamiento del servidor real.

2.4.1.3. Comentario sobre la adopción de la arquitectura servidor

virtualizado en las PyMES

Como se ha podido mostrar a lo largo del capítulo, los beneficios y aplicaciones de la

virtualización de servidores son motivantes de peso para dar lugar a su aplicación,

tanto por costos como por características técnicas que permiten a las organizaciones

satisfacer algunas de sus necesidades de comunicación. Por otro lado, las

desventajas encontradas pueden ser solucionadas con una adecuada planificación

del centro de datos virtual y como se pudo observar, éstas son considerablemente

menores frente a los beneficios obtenidos.

Así, la aplicación de una arquitectura servidor virtualizado permitirá a las PyMES

facilitar sus operaciones haciendo uso de las Tecnologías de Información y

Comunicación lo cual como ha sido visto en los temas anteriores da lugar al

incremento de su productividad.

CAPÍTULO TRES

3. INSTALACIÓN, CONFIGURACIÓN, Y PRUEBAS

DE XEN® HYPERVISOR COMO BASE EN LA

IMPLEMENTACIÓN DE SERVIDORES

VIRTUALES.

3.1. DISEÑO DE UN PROTOTIPO DE SERVIDOR

VIRTUALIZADO PARA PyMES

A lo largo del capítulo 2, se pudo conocer la definición, situación, soluciones y

requerimientos de las pequeñas y medianas empresas (PyMES) en Ecuador. Así

también, se prestó especial interés acerca de la introducción de las tecnologías de la

información TIC´s como elementos clave en el incremento de su productividad.

En base al trabajo realizado por la Cámara de la Pequeña Industria de Pichincha

(CAPEIPI) (11) con encuestas a más de 3000 empresas y a lo que se suma un

estudio realizado por CONQUITO y Santa Fe Associates (10) con encuestas

realizadas 206 empresas, se pudo determinar de manera general los requerimientos

básicos sobre TIC´s en las PyMES.

Finalmente en base a estas premisas se presentó a la virtualización como alternativa

para la implementación de un prototipo de servidor virtualizado que brinde todas las

características deseadas referentes a sus requerimientos y esté acorde a la situación

típica de las pequeñas y medianas empresas.

En este capítulo se procederá a la selección del tipo de virtualización a usarse y con

ello la herramienta tecnológica a utilizarse en base a lo conocido en el capítulo 1.

Para dar lugar a este objetivo, sin embargo, es necesario presentar una primera

propuesta de diseño de Centro de Datos para las PyMES, el cual luego será

implementado en base a la arquitectura servidor virtualizado haciendo uso de la

herramienta y tipo de virtualización seleccionados.

En primer lugar se toma en cuenta un diseño sin virtualización y posteriormente se

presentará el prototipo para el caso expuesto en este proyecto en el que todos los

servidores se hallan virtualizados dentro de un solo equipo físico, esto viene a

constituir la arquitectura servidor virtualizado.

Cada uno de los servidores virtuales tiene exactamente el mismo comportamiento

que un servidor físico, por lo que el diseño del prototipo de servidor virtual para

PyMES se debe realizar de una forma similar a como se realizaría el diseño de la

granja de servidores de la empresa.

3.1.1. DISEÑO DE UN CENTRO DE DATOS PARA PyMES (13)

Una vez que se tienen en claro los requerimientos de las PyMES, expuestos en

temas anteriores, se puede a proceder al diseño de su centro de datos, para este

diseño se debe considerar que una vez que se implemente la red, esta debe cumplir

con ciertos parámetros que se detallan a continuación:

· Debe facilitar y agilizar el trabajo de los usuarios, de esta manera se logra

incrementar la productividad de los mismos.

· Se debe mantener un costo asequible para la empresa, tanto en el proceso de

implementación como en el mantenimiento de la red.

· Debe tener un buen rendimiento de manera que pueda realizar sus

operaciones de manera rápida y segura

· Debe brindar confiabilidad, es decir que los errores no deben ser frecuentes y

en caso que se presente alguno en un componente del sistema, no debería

afectar al resto (tolerancia a errores).

· Debe brindar disponibilidad, es decir que los servicios que brinde la red deben

poder ser accedidos por cualquier usuario autorizado en el momento que lo

requiera.

Considerando estos detalles se puede proceder a escoger la topología de red

adecuada para los servicios a implementarse.

Primeramente se considerarán los servicios básicos necesarios para la intranet

empresarial de la tabla 3.2: Servidor DHCP, Servidor DNS, Servidor HTTP que

permita la implementación de comercio electrónico, Servidor de Correo Electrónico

con detección de virus y correo SPAM, Servidor de Mensajería Instantánea, Servidor

de Base de Datos, Servidor FTP, Proxy y Firewall, Servicio de Directorio que permita

un control de usuarios y Servicio de Telefonía sobre IP. Para todos estos servicios se

requiere de una topología multiacceso en la que se permita la comunicación entre

varios nodos a través de un mismo medio físico73.

3.1.1.1. Consideraciones de Seguridad, Disponibilidad y Confiabilidad

En todo tipo de red pueden presentarse ataques de personas mal intencionadas o

fallas debido a errores humanos o sobrecarga del sistema, para minimizar la

interferencia de estos con el buen funcionamiento de la red, se deben implementar

ciertos mecanismos para brindar una mayor seguridad, disponibilidad y confiabilidad.

El principal mecanismo de seguridad es la implementación de un firewall, este equipo

de seguridad perimetral deberá permitir solo las conexiones que las políticas de la

empresa consideren seguras. De esta manera se evita que cualquier persona pueda

ingresar a la red interna de la empresa.

Otro mecanismo de seguridad es el proxy, este permite el bloqueo de contenidos

inadecuados en el uso de protocolos como HTTP, FTP o SSL. Además ayuda a un

mejor control de los empleados al permitir la creación de restricciones de acceso web

por usuario o hacia páginas web específicas.

Finalmente una de las consideraciones más importantes en lo que se refiere a

seguridad de redes es la creación de zonas desmilitarizadas (DMZ). Una zona

desmilitarizada es una red perimetral local que se ubica entre la intranet de la

organización y una red externa como Internet. La DMZ permite que se realicen ciertas

conexiones desde las redes interna y externa a la DMZ, pero restringe el acceso de la

DMZ a la red interna. Con esto se logra que los usuarios de la red externa puedan

acceder a los servicios ubicados en la DMZ de una organización, pero no puedan

ingresar a su intranet.

73 Consideraciones de diseño del Servidor Virtualizado en función de las recomendaciones de HP, Microsoft y Xen. Ver anexo E.

Intranet

Internet

Figura 3.1 Ejemplo de una zona desmilitarizada (DMZ) y su ubicación en la red.

En el caso en estudio, los servidores que se ubicarán en la DMZ serán los de Correo,

Web, y DNS, que son los que habitualmente se encuentran en ella ya que es

necesario que sean accedidos desde fuera de la red.

3.1.1.1.2. Disponibilidad

El método más común para implementar una alta disponibilidad consiste en brindar

una redundancia de servicios, así por ejemplo, en el caso en estudio, todos los

servicios que se encuentran en la DMZ también se hallarán replicados en la intranet,

de esta forma aunque falle el servicio para la red externa la intranet podrá seguir

funcionando.

Se debe recalcar que una de las grandes ventajas que brinda la virtualización es la

facilidad de replicar los equipos y por lo tanto aumentar su disponibilidad, es decir que

con la virtualización se podrían generar copias exactas de los servidores que entrarán

en funcionamiento en el momento en que los principales fallen.

3.1.1.1.3. Confiabilidad

Para lograr tener un buen nivel de confiabilidad se deben de seguir buenas prácticas

para el diseño de las redes, brindando tolerancia a errores y evitando que los mismos

s (2) se presenten.

La tolerancia a errores se puede lograr al hacer cada servicio independiente de los

otros, de esta manera si uno de ellos falla no afectará al resto. En cambio, para evitar

que los errores se presenten se pueden emplear un sinnúmero de consideraciones,

de las que cabe mencionar el configurar cuidadosamente cada servicio, crear réplicas

de los equipos para que reemplacen a los servidores en caso de fallo y el empleo de

mecanismos de control como el firewall y proxy para restringir el acceso a contenidos

inadecuados.

3.1.1.2. Prototipo del Centro de Datos para las PyMES

En virtud de lo presentado, se muestra a continuación una primera propuesta del

Centro de Datos prototipo para PyMES. Para dicho prototipo se consideró que todos

los servidores, tanto de la intranet como de la DMZ, deben estar interconectados

entre sí en un mismo equipo de core y que se emplearán dos equipos de firewall para

brindar protección, un firewall para separar la intranet de la DMZ y otro para separarla

de la extranet74. El diseño seleccionado se basó en el diseño especificado por Cisco

como “DMZ Intranet Server Farm” en el libro Data Center Fundamentals75

74 Las consideraciones para la configuración de estos equipos se detallará en el Capítulo 4 del presente trabajo

75 Un resumen de los tipos de granjas de servidores se encuentran en la página web http://www.ciscopress.com/articles/article.asp?p=102268

Figura 3.2 Arquitectura “DMZ Intranet Server Farm” presentada por Cisco.

Este diseño muestra a los servidores en una Intranet conectándose a varios equipos

de core para brindar redundancia, además de detallar la existencia de una zona

desmilitarizada, una red para los usuarios internos y una red WAN privada que

permitiría la comunicación con otras sucursales mediante métodos como VPNs.

Este diseño parece ser el que más se ajusta a las necesidades de una Intranet

mediana o pequeña, en la que la mayoría de los servidores se encuentran dentro de

la misma y sólo pueden ser accedidos por sus usuarios, por otro lado dispone de

servidores en una zona desmilitarizada que pueden ser accedidos tanto por la

intranet como por la extranet.

En base a estas consideraciones se presenta a continuación una primera propuesta

del Centro de Datos prototipo para PyMES. Posteriormente en este capítulo en el

punto 3.3.4 se presentará la propuesta final haciendo uso de una solución

virtualizada.

Prototipo de DataCenter para PyMES.

3.1.2. ELECCIÓN DE LA SOLUCIÓN DE VIRTUALIZACIÓN

ADECUADA PARA EL DISEÑO

En base al Centro de Datos (DataCenter) propuesto anteriormente, se procede al

diseño de una solución virtualizada que posibilite proveer los distintos tipos de

servicios requeridos por las PyMES de manera eficiente, flexible, escalable y

económica. Para dicho fin es necesario elegir el tipo y herramienta de virtualización

adecuado de acuerdo a lo visto en el Capítulo 1.

3.1.3. ANÁLISIS DE LOS TIPOS Y HERRAMIENTAS DE

VIRTUALIZACIÓN DE SERVIDORES

Entre los tipos de virtualización considerados para la virtualización de servidores se

tiene:

§ Virtualización Completa.

§ Paravirtualización.

§ Virtualización Híbrida.

Estas alternativas para la virtualización de servidores (vistos con mayor detalle en el

capítulo 1) muestran pros y contras en cuanto a rendimiento, flexibilidad, seguridad,

costo, etc.

La correcta adopción del hypervisor de virtualización deberá estar en función de las

ventajas y desventajas que éste preste a la solución de la implementación a realizar.

Es así que, con la finalidad de elegir el tipo de virtualización más adecuado se

presenta a continuación un análisis comparativo de ventajas y desventajas entre

éstos.

3.1.4. ANÁLISIS COMPARATIVO: VIRTUALIZACIÓN COMPLETA VS.

PARAVIRTUALIZACIÓN VS. VIRTUALIZACIÓN HÍBRIDA

A continuación se presenta de manera general dichas ventajas y desventajas

encontradas tanto en la Virtualización Completa como en la Paravirtualización y en la

recientemente introducida Virtualización híbrida.

3.1.4.1. Ventajas y Desventajas de la Virtualización Completa

Tanto la virtualización completa como la paravirtualización, al ser ambas basadas en

hypervisor, disponen de ventajas similares, sin embargo disponen de ciertas

características específicas que hacen que se justifique su clasificación en dos

categorías distintas.

Ambos tipos de virtualización brindan un aislamiento total entre las máquinas virtuales

y el monitor de las mismas (VMM) permitiendo correr distintos sistemas operativos en

las máquinas virtuales de manera independiente, de la misma forma, ambas tienen

un excelente rendimiento, sin embargo el de la virtualización completa puede verse

afectado por ciertas instrucciones que requiere emular.

La principal ventaja presentada por la virtualización completa es que posee el más

amplio soporte en lo que se refiere a los sistemas operativos. Al simular todo el

hardware del equipo anfitrión proporciona una abstracción total del sistema físico

subyacente y crea un nuevo sistema virtual en el cual se soporta la instalación de casi

todos los sistemas operativos sin modificación alguna, siendo la única restricción que

los sistemas operativos virtuales soporten la arquitectura de hardware utilizada.

Las principales desventajas de la virtualización completa se dan sobre todo en lo

relacionado con los sistemas x86, así por ejemplo, pese a que emplea técnicas

avanzadas para atrapar y emular instrucciones propias de las arquitecturas x86 en el

runtime, vía parchado binario76, esto afecta el rendimiento del sistema, como se

76 Un parche es una sección de código que se aplica a un programa para actualizarlo solucionando problemas o agregar funciones. El parchado puede ser binario o de código fuente, siendo el binario el que se aplica en los archivos ejecutables.

mencionó en párrafos anteriores, al requerir un mayor procesamiento. El rendimiento

puede caer hasta en un 50 por ciento77.

Adicionalmente, en la arquitectura x86, con la virtualización completa no se es capaz

de atrapar ciertas llamadas privilegiadas por lo que se requiere un balance adecuado

entre el hardware y el software. Todo esto dificulta su correcta implementación y uso.

Esto se ve agravado si se considera también que la virtualización completa no

permite la compartición de recursos entre varios equipos virtuales corriendo

simultáneamente y que el sistema operativo anfitrión puede convertirse en un punto

de fallas.

3.1.4.2. Ventajas y Desventajas de la Paravirtualización (3)

Una desventaja principal constituye que las instancias paravirtualizadas de los

sistemas operativos de los equipos virtuales deben ser modificadas para que

reconozcan la capa de virtualización. Ésta necesidad quita flexibilidad a los sistemas

operativos que puedan instalarse sobre el hypervisor; es por esta razón que no

cualquier sistema operativo puede estar listo para ser paravirtualizado.

Este hecho sin embargo trae consigo una de las ventajas más importantes de la

paravirtualización. Puesto que la modificación del sistema operativo Guest ayuda al

hypervisor a evitar las instrucciones difíciles de virtualizar de los procesadores, así el

resultado es un mejor desempeño que el de los equipos virtuales de virtualización

completa. Dichas instrucciones difíciles de virtualizar son reemplazadas con una

llamada de procedimiento que proporciona esa funcionalidad.

La paravirtualización es una tendencia emergente porque logra un mejor rendimiento

de chips existentes; así en el caso de ser implementado sobre hardware anterior a él

presentado por Intel® y AMD® como Intel VT® y AMD-V®, la paravirtualización

proporciona Guest´s que tienden a ser los de mayor rendimiento en cuanto a red y

I/O de disco.

77 Según documento de Novell: “Virtualización en el centro de datos” que se encuentra en

http://passthrough.fw-notify.net/download/035043/http://www.eaktio.com/downloads/FolletoXEN.pdf

Hypervisors que proporcionan entornos paravirtualizados como Xen® a la vez que

aprovechan los chips existentes, así también ofrecen potentes ventajas con la

próxima generación de chips x86 que admiten virtualización (los mencionados Intel

VT® y AMD-V®) proporcionando un entorno de virtualización híbrida.

Adicionalmente se puede mencionar que la implementación de paravirtualización es

más fácil que una implementación de virtualización completa; permite compartir

memoria en forma cooperativa entre equipos sin la necesidad de modificar el sistema

operativo host y también mantiene la promesa de ofrecer equipos virtuales

optimizados a la perfección con el sistema operativo host Linux.

A todo esto se suma el hecho que el hypervisor líder en cuanto a paravirtualización es

Xen®, el cual constituye una plataforma de código abierto y software libre78 frente a

desventajas de licenciamiento y costo de soluciones de virtualización completa como

VMware79.

3.1.4.3. Ventajas y Desventajas de la Virtualización Híbrida

La virtualización híbrida, o también llamada nativa, es la técnica de virtualización más

nueva basada en la arquitectura x86. Como ventaja principal se puede mencionar que

constituye una combinación de paravirtualización o virtualización completa con

técnicas de aceleración de I/O.

Otra de las ventajas constituye el hecho que los sistemas operativos Guest no

requieren ser modificados (como sí en la paravirtualización) para poder funcionar en

un este entorno de máquina virtual.

78 Xen® viene incluido gratuitamente en numerosas distribuciones de Linux como CentOS, Debian, Open Suse, etc. Además puede ser descargado en http://www.xen.org/products/xen_source.html.

79 Una distribución empresarial de VMware como VMware ESX puede llegar a costar hasta 3495 U.S.D. :http://www.vmware.com/products/vsphere/buy/overview.html

Esta técnica de virtualización saca provecho de las nuevas tecnologías de CPU para

x86 como los ya mencionados Intel VT y AMD –V; a esto se suma el hecho que Xen®

soporta éste tipo de virtualización asistida por hardware.

Permite desestimar las desventajas encontradas en la virtualización completa (en

cuanto a diecisiete instrucciones no virtualizables de la arquitectura x86) mediante el

empleo de trap-and-emulate directamente en el hardware en lugar de realizarlo en

software como lo hacen algunas plataformas de virtualización completa80; éste hecho

permite incrementar su rendimiento.

Por otra parte en combinación con la paravirtualización, la virtualización híbrida saca

el mayor provecho de Hypervisors como Xen®. Así se puede desestimar la

desventaja principal de la paravirtualización en cuanto a la falta de flexibilidad al

momento de elegir el sistema operativo Guest; así es que sistemas operativos

modificados como una distribución de Linux como por ejemplo CentOS® pueden

correr sobre el hypervisor de paravirtualización de Xen® al mismo tiempo que se

puede correr un sistema operativo no modificado como por ejemplo Windows® XP en

un ambiente híbrido con el mismo hypervisor, todo esto mediante el empleo de la

tecnología Intel® VT o AMD- V®.

Este hecho al que se suman las ventajas antes mencionadas de la paravirtualización

convierten a Xen® en un fuerte candidato para la virtualización de servidores.81

Entre otras ventajas adicionales se tiene que con esta técnica de virtualización se

tiene la capacidad de emplear técnicas de aceleración para operaciones de I/O;

además soporta virtualización de sistemas operativos de 64 bits y tiene el mayor

rendimiento en cuanto a CPU, memoria e I/O de entre las máquinas virtuales x86.

80 Es el hecho que en la virtualización “completa” implementada por plataformas como VMware

existen 17 instrucciones no virtualizables que son tratadas mediante procedimientos especiales. Este hecho reduce significativamente el rendimiento de la máquina virtual.

81 Se retomará este tema en el siguiente capítulo.

Sin embargo todos estos beneficios se encuentran siempre alrededor de un factor:

requiere de la tecnología de procesador Intel VT® o AMD-V® y además deberán

soportar aceleración asistida de hardware.

Este hecho implica que equipos servidores anteriores a esta tecnología no podrán

emplear la virtualización híbrida. Por este motivo la técnica en cuestión es aplicable

desde algunas últimas versiones de Intel® Pentium 4 en adelante (Para mayor detalle

se puede revisar el anexo A) restringiendo la reutilización de chipset antiguo.

Sin embargo de lo mencionado, el costo de estos últimos procesadores ha reducido

considerablemente, hecho por el cual es muy factible su utilización82.

Para revisar los costos de las diferentes alternativas remitirse al anexo A.

3.1.5. ANÁLISIS COMPARATIVO ENTRE LAS HERRAMIENTAS DE

VIRTUALIZACIÓN

La elección del tipo de virtualización a utilizar debe estar en acuerdo con la

herramienta que permita darla lugar. Esta situación se ve acentuada en mayor forma

debido a la naturaleza de las herramientas de virtualización, es decir debido a sus

características tanto técnicas como económicas, de soporte y mantenimiento, etc.

que se ajusten en mejor medida a la situación clásica de las PyMES.

De acuerdo a las herramientas de virtualización estudiadas en el primer capítulo, se

ha escogido las más representativas en función de la trayectoria en el mercado, el

porcentaje de utilización por las organizaciones y el respaldo de la casa fabricante.

Estos hechos se ven reflejados en casos de éxito en la aplicación de las mismas y

muestra de buenas características generales de desempeño.

Estas herramientas de virtualización son:

§ VMware®.

§ Microsoft Hyper-V™.

§ Xen®.

A continuación se presenta un cuadro comparativo con las principales características

que nos permitirán la elección de la herramienta adecuada:

íbrid

9 (inc

De las herramientas de virtualización antes vistas se puede observar en el cuadro

una gran mayoría de características comunes; sin embargo en las diferencias

encontradas se marca la decisión para la adopción de una de éstas tres

herramientas.

Así, entre los principales aspectos que difieren estas herramientas son:

§ Tipo de virtualización

§ Soporte de sistemas operativos Host OS

§ Soporte de sistemas operativos Guest OS

§ Velocidad relativa o desempeño

§ Tipo de licenciamiento

§ Costos

Entre las características concluyentes se puede destacar lo siguiente:

Hyper-V™ de Microsoft ofrece una solución de virtualización que aprovecha las

características de los nuevos procesadores Intel-VT y AMD-V; por tal motivo su

modelo se basa en la virtualización híbrida asistida por hardware.

Éste hecho, sin embargo, limita la aplicación de la infraestructura únicamente a

equipos servidores nuevos que empleen las nuevas tecnologías introducidas por Intel

y AMD, dejando de lado así a servidores funcionales y de rendimiento óptimo pero

que no poseen este hardware en cuestión.

Si por otro lado el datacenter a implementar es nuevo, los precios de adquisición de

equipos Intel® y AMD® con soporte para virtualización es cada vez más asequible.

Así con este requerimiento fundamental, Hyper-V de Microsoft proporciona

funcionalidades muy interesantes como migración rápida, alta disponibilidad o

backups en vivo, etc. las cuales junto con las herramientas de administración

incluidas, le dan una ventaja competitiva.

Todo este hecho, por otra parte, va de la mano con la característica de software

licenciado como lo es Windows Server® 2008 (que debe ser instalado en un parent

partition de Hyper-V™), cuyos costos de licenciamiento lo hacen menos atractivo

frente a otras ofertas de virtualización.

Adicionalmente es muy importante tomar en cuenta que esta nueva oferta de

Microsoft® se encuentra dando sus primeros pasos, que aunque ya ha pasado por

versiones beta y otras versiones anteriores, sin embargo tiene aproximadamente 3 o

más años de retraso en investigación y soporte frente a proyectos como Xen® o

VMware® de rendimiento probado.

A todo esto se añade el hecho que son limitadas las distribuciones de Linux que

pueden correr sobre Hyper-V™, hecho que quita flexibilidad a la implementación y

tiende a elevar costos (por el hecho de orientarse a virtualización de Guest Oses

propietarios como Windows) por cada licencia del sistema operativo Guest. En una

implementación básica los costos pueden llegar a sobrepasar los 50000 dólares92 con

herramientas de licencia Retail.

Por otra parte, VMware presenta una amplia gama de productos de gran desempeño

(gratuitos y no gratuitos), destacándose VMware ESX que no requiere de un sistema

operativo base, sin embargo, los productos gratuitos son solo útiles para uso personal

y los que presentan las mejores funcionalidades para las empresas tienen un costo

relativamente alto el cual es un factor muy importante a considerar.

VMware presenta una solución muy atractiva, inclusive proporcionando virtualización

completa, híbrida y paravirtualización. Sin embargo el desempeño no es el mismo

comparado a con otras herramientas de uso de paravirtualización; la

paravirtualización utilizada es la llamada “paravirtualización transparente”, la cual es

diferente a la paravirtualización “tradicional” (usada por Xen) la cual se encuentra

todavía en desarrollo. Además el performance obtenido aún no llega a ser semejante

al de un entorno paravirtualizado.

92 Tal como se puede demostrar en http://www.microsoft.com/windowsserver2008/en/us/server-calculator/default.aspx, con una arquitectura básica de virtualización con cuatro máquinas virtuales de sistema operativo propietario Windows.

VMware es una excelente opción para grandes empresas93 pero resulta poco

accesible e inconveniente para las pequeñas y medianas, si se considera el alto costo

que representa su licenciamiento.

Finalmente se tiene a Xen® hypervisor, el cual constituye una solución muy

interesante para la implementación de servidores virtuales. Sus características de

licenciamiento, soporte de Guest OS, costos, sistema operativo anfitrión Linux y

rendimiento convierten a Xen en un candidato perfecto para las PyMES como se

podrá mostrar a continuación.

3.1.6. CONCLUSIÓN SOBRE LA ELECCIÓN DE LA SOLUCIÓN DE

VIRTUALIZACIÓN

Por los datos proporcionados en los temas precedentes se procede a la selección de

la siguiente solución de virtualización:

Implementación Servidor Virtualizado para PyMES

Tipo de Virtualización Paravirtualización Virtualización Híbrida

Herramienta de Virtualización Xen® Sistema operativo anfitrión

(Host OS) GNU - Linux

Tabla 3.3 Selección de la solución de virtualización

Es así que el prototipo de servidor virtualizado se implementará en basa a la

paravirtualización y virtualización híbrida sobre una distribución de GNU-Linux a

través del hypervisor que permite dichas características: Xen®, por los siguientes

motivos:

§ Permite obtener los beneficios característicos de rendimiento de la

paravirtualización y el aprovechamiento de la virtualización híbrida propio de

las nuevas tecnologías de procesadores con soporte para virtualización. Es

93 “Las soluciones de VMware se utilizan en más de 150.000 organizaciones de TI de todo el mundo, incluidas todas las empresas de la lista Fortune 100” Tomado de:

http://www.vmware.com/es/overview/why.html

así que se implementa una solución de compatibilidad con Intel-VT, AMD-V,

así como con tecnologías precedentes;

§ Se brinda soporte de sistemas operativos modificados para entornos

paravirtualizados de alto rendimiento así como también de sistemas operativos

no modificados dando así la posibilidad de correr eficientemente Linux y

Windows® en un mismo equipo;

§ Se proporciona una solución de naturaleza open source y de software libre

que permite abaratar costos sin estar acosta de altas características técnicas

de rendimiento y estabilidad permitiéndose incluso obtener las últimas

versiones y actualizaciones totalmente gratis o inclusive pre instalado en

varias distribuciones de Linux;

§ La solución de virtualización corre sobre un sistema operativo Host de

características de software libre y open source, hecho que también abarata los

costos para una implementación en las PyMES y brinda altas características

de estabilidad;

§ Posee herramientas de administración de las máquinas virtuales o incluso se

abre la posibilidad de poder generales (por el hecho open source); A esto se

añade características de alta disponibilidad como Live Migration de VM´s;

§ Se brinda soporte a varias arquitecturas tanto como x86, x86_64 IA64, entre

otras;

§ El soporte técnico está respaldado por la cada vez creciente comunidad de

software libre y open source alrededor del mundo, así como de empresas

(Citrix, Novell) que han adoptado a Xen® como su principal herramienta de

virtualización.

§ Finalmente, la paravirtualización en conjunto con la virtualización híbrida,

Xen® y Linux® permiten la creación de un sistema de alta estabilidad que

permite alcanza las características objetivas del presente proyecto como son:

ü Eficiencia a través de un entorno de virtualización al que se suman las

características de ser paravirtualizado y de virtualización híbrida.

ü Flexibilidad a través de la virtualización Híbrida y Xen® que permiten

correr sistemas operativos Guest ya sean modificados o no modificados

ajustándose de acuerdo a los requerimientos de la organización.

ü Escalabilidad a través de la naturaleza de la virtualización y de Xen®

que permite en tiempo real disponer de Máquinas Virtuales según el

crecimiento o las necesidades de carga requeridas por la organización

ü Solución Económica94 a través del uso de herramientas de software

libre y open source y de altas características técnicas como son Xen® y

GNU-Linux.

Por los motivos anteriores la solución presentada brinda una plataforma de

virtualización con muy buenas características tanto técnicas como económicas para

su implementación en organizaciones, abriendo así una gran puerta de solución para

las pequeñas y medianas empresas PyMES.

3.2. XEN

3.2.1. INTRODUCCIÓN

Como se mencionó en el capítulo 1, Xen es una solución de virtualización de código

abierto para procesadores de 32 y 64 bits, desarrollada en la Universidad de

Cambridge que basa su funcionamiento en la paravirtualización y en la virtualización

híbrida.

El objetivo del proyecto fue el desarrollar una infraestructura poderosa y flexible para

la computación distribuida, una parte clave de esto fue el permitir a las máquinas

correr múltiples y diferentes instancias de sistemas operativos con sus respectivas

aplicaciones de manera independiente una de otra. Una vez que se consideró que

dichos objetivos se estaban cumpliendo, se liberó al público la primera versión del

VMM de Xen en el año de 2003 por parte de la compañía XenSource que continuó

94 Para mayor información referirse al Capítulo 2: Aplicabilidad de la arquitectura servidor virtualizado para facilitar la operación de las PyMES.

desarrollando el sistema hasta el año 2007 en el que el proyecto fue vendido a Citrix

Systems que continúa con el mismo.

Para su funcionamiento, un sistema Xen dispone de múltiples capas, siendo la más

baja y con más privilegios Xen, para comprender como obtiene sus privilegios, se

explicará brevemente los modos de acceso de los procesadores:

Los procesadores suelen correr en diferentes modos de protección para restringir el

acceso al procesador físico y los recursos de dispositivos, en la arquitectura x86

existen tres modos de acceso principales para acceder a los recursos: Real mode,

System Management Mode (SMM) y Protected Mode; este último presenta múltiples

niveles de acceso que se conocen como Anillos (Rings) numerados desde el 0 hasta

el 3 en los procesadores actuales.

Figura 3.4 Anillos de protección del Modo Protegido de un Procesador.

En los sistemas operativos, el kernel corre sobre el anillo 0 o modo supervisor que

tiene acceso ilimitado, esto le permite controlar todo el hardware y la memoria del

equipo. Por otro lado las aplicaciones y procesos corren en el anillo 3 denominado

modo de usuario.

Xen corre su hypervisor en el anillo 0, esto le permite mediar el acceso al hardware

por parte de las máquinas virtuales. Por otro lado los kernels parchados corren en

anillos menos privilegiados. Es decir que Xen administra los accesos a los recursos

de memoria y hardware mediante la combinación de su hypervisor y un kernel

modificado Xen con privilegios, este kernel viene a recibir el nombre de domain0

(dom0).

Un dominio es una instancia de una máquina virtual de Xen corriendo sobre un

hardware específico, y su función es la de hacer un uso efectivo de los recursos

disponibles. El dominio 0 es el primer dominio que se crea automáticamente cuando

se inicia el sistema y es el encargado de la creación de otros dominios llamados

huéspedes (domainU - domU) y sus dispositivos virtuales, al igual que de ciertas

tareas administrativas como las migraciones de máquinas virtuales. El dom0 es capaz

de crear, modificar, conectar o terminar a un domU; para lograr esto emplea ciertos

archivos de configuración que brindan información detallada del dominio huésped.

Dentro del dom0 es donde corre el proceso de Xen, llamado xend (/usr/sbin/xend),

este es el responsable de la administración de las máquinas virtuales y del acceso a

sus consolas. Además de esto Xen brinda una aplicación administrativa vía línea de

comandos para la realización de distintos tipos de configuraciones, esta recibe el

nombre de Xen Managment (xm).

En la mayoría de los casos Xen emplea la paravirtualización como su método de

virtualización, como se vio anteriormente, esto quiere decir que emplea un sistema

operativo huésped modificado para lograr obtener un rendimiento muy similar al

nativo y excelentes capacidades administrativas. Sin embargo también es capaz de

emplear una virtualización híbrida, esto quiere decir que puede correr un sistema

operativo sin modificaciones. Para lograr esto se requiere el empleo de procesadores

especiales por lo que se le denomina virtualización asistida por hardware (Intel VT o

AMD-V). Estos procesadores disponen de nuevas instrucciones para permitir

llamadas directas de un huésped paravirtualizado.

3.2.1.1. Problemas de la Virtualización en x86

Uno de los más serios problemas de la virtualización es la dificultad de hacerlo en las

arquitecturas x86, como se mencionó en el capítulo 1, esto es debido a que este tipo

de arquitectura no está enfocada para la virtualización, específicamente la

virtualización completa, debido a que no es capaz de atrapar ciertas llamadas cuando

son ejecutadas con privilegios insuficientes entre los sistemas operativos huéspedes

y el hardware.

En la mayoría de soluciones de virtualización lo que se hace para solucionar este

problema es el monitoreo constante de las instrucciones que envía la máquina virtual,

sin embargo esto presenta un impacto en el rendimiento. Xen, por otro lado, ataca el

problema empleando la paravirtualización, es decir que emplea un pequeño VMM que

corre directamente en el hardware y se encarga de las complejidades de nivel bajo,

dejando lo de nivel superior al sistema operativo huésped.

Cuando el hardware no brinda soporte para virtualización, el VMM de Xen requiere

que sus máquinas virtuales usen una versión modificada del sistema operativo para

evitar instrucciones privilegiadas. Aunque se debe modificar el kernel del sistema

operativo para soportar Xen, este es el único cambio requerido, es decir que no se

deben modificar las aplicaciones y librerías.

3.2.2. ARQUITECTURA

La arquitectura de Xen® es la de una infraestructura paravirtualizada a la que se

agregan elementos específicos para el funcionamiento de éste hypervisor.

Así, ésta se encuentra formada por:

§ Hypervisor

§ Guest OS

§ Aplicaciones

La estructura de una infraestructura de paravirtualización se la realiza en base al

manejo de los aros de seguridad o ring´s de una arquitectura computacional.

Así, como se mencionó anteriormente, en una arquitectura x86 se cuenta con varios

aros de seguridad numerados de 0 a 3 dependiendo del grado de privilegios que

éstos tengan. Éstos aros permiten la asignación de privilegios a las diferentes capas

de un sistema (SO, aplicaciones, procesos) para su acceso a recursos del sistema. El

aro 0 es el de mayor privilegio y el aro 3 es el de menor privilegio. Comúnmente los

aros más usados son el 0 y 3, quedando libres los aros 1 y 2.

En una implementación tradicional donde el Sistema Operativo corre directamente

sobre el hardware, éste se encuentra ejecutándose en el aro de mayor privilegios (aro

0) y las aplicaciones se encuentran ejecutándose en el aro de seguridad 3. Así de

esta manera se brinda al SO el control de los recursos de hardware y a las

aplicaciones acceso restringido por cuestiones de seguridad.

Para que un ambiente virtualizado funcione, sin embargo, es necesario ubicar a los

varios SO Guest en otro aro de seguridad (a fin de que no todos éstos corran sobre el

aro de mayor privilegio causando conflictos entre sí por la ejecución directa de

instrucciones privilegiadas y perdiendo aislamiento mutuo) y así corran sobre el

hypervisor ubicado en un aro con el mayor grado de privilegios y permitir

virtualizarlos.

La solución implementada en la paravirtualización y por Xen® es el ubicar al SO

Guest en el aro de seguridad 1 y al hypervisor en el aro 0. Las aplicaciones se

mantienen en el aro 3; como se muestra en la figura 3.4.

Así el resultado es una arquitectura formado por 3 capas:

§ ARO 0: Hypervisor

§ ARO 1: Guest OS

§ ARO3: Aplicaciones

Cabe indicar que Xen® puede ir embebido en un sistema operativo anfitrión

modificado95 (Host OS), en cuyo caso en el aro 0 se encuentra el SO Host (dom0);

esta implementación constituye un tipo de hypervisor Non Hosted.

Figura 3.5 Aros de seguridad Arquitectura Nativa vs. Paravirtualizada. Fuente: The Definitive Guide to Xen® Hypervisor. David Chisnall, Prentice Hall 2007. Pág. 17.

Ésta organización de la paravirtualización se ve complementada con los

componentes que Xen® implementa para el manejo de la infraestructura virtualizada.

Estos componentes básicos son:

§ Virtual CPU

§ Virtual Memory

§ Virtual Block Devices (Disco)

§ Virtual Device I/O

La función de los componentes anteriores es la de proporcionar una máquina virtual a

cada instancia de SO creada a fin de emular el hardware real sobre el que se debe

95 Por ejemplo CentOS 5.3 incluye un kernel modificado en el que se incluye una versión de Xen ®Hypervisor.

ejecutar. Cabe recordar que no todo el hardware es emulado en un ambiente de

paravirtualización lo cual le brinda un mejor rendimiento.

Los componentes mencionados anteriormente: Virtual CPU, Virtual Memory son

manejados por el hypervisor y los dispositivos virtuales Virtual Device I/O por un

dominio especial llamado Dom0. Estas consideraciones se explicarán más adelante.

La arquitectura de Xen® se ve complementada con el dominio de administración y

control de las máquinas virtuales Dom0. Éste control permite la creación y

terminación de dominios, control de parámetros de scheduling, creación y eliminación

de dispositivos de red y almacenamiento, muestra de estadísticas básicas de

rendimiento de las VM´s entre otros aspectos.

Cada una de las máquinas virtuales VM´s que yacen sobre el hypervisor son

llamadas dominios (DomU). Así es posible tener Dom1, Dom2, Dom3, etc. todas bajo

la administración y control del Dom0.

Así una primera arquitectura de Xen® es la vista en la figura 3.5:

Figura 3.6 Arquitectura básica de Xen®. Fuente: The Definitive Guide to Xen® Hypervisor. David Chisnall, Prentice Hall 2007. Pág. 24.

Sin embargo para que un sistema operativo Guest pueda funcionar sobre un

ambiente de paravirtualización (en función que no se implementa una emulación

completa del hardware subyacente), éste debe ser modificado a fin de poder manejar

correctamente elementos de Memoria, CPU y Dispositivos de I/O limitándose así la

utilización de sistemas operativos no modificados.

Xen® permite trabajar con las nuevas tecnologías de procesadores como Intel VT® o

AMD – V® que prestan la introducción de la virtualización asistida por hardware o

como se ha conocido en el presente trabajo de investigación como virtualización

Híbrida.

En este caso la solución de Xen® es el combinar la técnica de paravirtualización con

la asistencia del hardware para virtualización. Así de esta manera se permite la

inclusión de virtualización de sistemas operativos no modificados (HVM Guest´s, o

Hardware Virtual Machine Guest´s) ofreciendo una capa común de abstracción.

Así de lo visto, la arquitectura de Xen® se sintetiza en la siguiente figura:

Figura 3.7 Arquitectura de Xen®, SO modificados (color verde) y SO no modificados (color naranja). Fuente: (13). Pág. 5.

3.2.3. IMPLEMENTACIÓN DE LA ARQUITECTURA SERVIDOR

VIRTUALIZADO CON LA HERRAMIENTA XEN

En base al diseño principal del prototipo de centro de datos para PyMES (figura 3.3),

se presenta a continuación una solución de prototipo virtualizado haciendo uso de la

herramienta elegida en el punto 3.1.6.

Recalcando lo visto a lo largo de los capítulos 1, 2 y 3, en esta implementación de la

arquitectura servidor virtualizado se busca consolidar los servidores necesarios sobre

una única pieza de hardware a fin de obtener los beneficios de la virtualización de

servidores: escalabilidad, seguridad, confiabilidad, disponibilidad, ahorro de recursos,

mejor utilización de la infraestructura. Las características técnicas que el hardware

real debe tener serán analizadas en el capítulo 5.

Prototipo de DataCenter Virtualizado para PyMES.

13777777777777777777777777777777777777777777777777777777777777777777777

3.2.3.1. Instalación

La distribución de Xen tiene tres componentes principales: Xen, puertos de Linux y

NetBSD para correr en Xen y las herramientas de usuario para administrar un

sistema basado en Xen.

3.2.3.1.1. Requerimientos para la instalación

Los requerimientos de hardware para correr el dom0 de Xen son:

· CPU: Pentium - 4 (o mejor) de 1.5 GHz o mejor. Actualmente Xen soporta

sistemas de hasta 32 procesadores. Se debe recalcar que para correr

sistemas Hardware Virtual Machine (HVM) se requiere un procesador con

soporte de virtualización vía hardware como Intel VT o AMD-V.

· Motherboard: Si el procesador tiene soporte de virtualización vía hardware,

también debe activarse el mismo en el BIOS del motherboard.

· Memory: 1GB o más es sugerido, se recomienda 2GB o más. El valor depende

del número de máquinas virtuales a correr simultáneamente y su cantidad de

memoria.

· Disco Duro: Depende del tamaño de las máquinas virtuales existentes.

· Tarjeta de Red: 100 Mbps o mejor.

También se requieren de paquetes de software para correr Xen:

· Bridge utilities: Permite configurar las interfaces de red virtuales y hacer

puentes entre la tarjeta física u la virtual.

· GRUB: GRUB (GRand Unified Bootloader) es el cargador de inicio para los

sistemas Linux.

· SSL cryptographic libraries

· iproute: brinda utilidades para administrar a IP y las opciones de ruteo, esto se

usa para configurar las comunicaciones entre sistemas dom0 y domU y otras

redes.

· Python: Lenguaje de Programación Orientado a Objetos en que se han escrito

varias herramientas de Xen.

· zlib: librería de compresión Open Source usada por Xen.

Para tener acceso gráfico a las consolas domU se necesita el sistema de ventanas X

y uno de los siguientes paquetes:

· libvncserver: Librería para hacer visible la consola gráfica de una máquina

virtual en aplicaciones que usan el protocolo VNC (Virtual Network Computing)

· libsdl: La Simple DirectMedia Layer (SDL) es una librería para indicar

directamente la consola gráfica en un sistema de ventanas X sin requerir

conexión remota como con VNC.

3.2.3.1.2. Instalación

Una vez comprobados que se cumplan todos los requisitos se puede proceder a la

instalación de Xen. Lo primero que se requiere son los paquetes de instalación de

Xen, esto se puede conseguir desde la página

http://www.xen.org/products/xen_source.html, vale la pena mencionar que al ser una

aplicación de virtualización tan popular el paquete suele venir embebido en la

mayoría de las distribuciones de Linux más populares.

Figura 3.9 Descarga del paquete de Xen.

Los paquetes de instalación de Xen pueden conseguirse en formato de paquete RPM

o una distribución de la fuente en un archivo tar. Para realizar una instalación de un

paquete descargado vía consola de comandos, en el caso de disponer del archivo tar,

se procede a descomprimir e instalar:

# tar zxvf xen-x.x-install.tgz

# cd xen-x.x-install

# sh ./install.sh

Figura 3.10 Descompresión del paquete de Xen.

Figura 3.11 Instalación del paquete de Xen.

En el caso de disponer de los RPMs, se emplea el comando rpm:

# rpm -iv rpmname

Una vez instalado el paquete se debe comprobar la creación del kernel modificado y

la correcta instalación de Xen.

Figura 3.12 Comprobación de la correcta instalación del paquete de Xen.

A continuación se muestra la instalación de Xen empleando la interfaz gráfica del

Administrador de Paquetes que dispone CentOS. Se tiene dos formas de localizar los

paquetes necesarios, se puede buscar la categoría de Virtualización y seleccionarla:

Figura 3.13 Búsqueda e instalación de los paquetes requeridos para virtualización en CentOS.

También se puede buscar a Xen Hypervisor, una vez que se seleccione el paquete de

Xen automáticamente se seleccionarán todos los paquetes requeridos.

Figura 3.14 Búsqueda de los paquetes de Xen Hypervisor.

Una vez concluida la instalación se puede comprobar la ubicación del kernel

modificado para Xen.

Figura 3.15 Comprobación del aparecimiento del kernel modificado de Xen en /boot/.

3.2.3.2. Configuración del GRUB

Una vez instalado Xen, es necesario el añadir una entrada al GRUB para permitir la

carga del kernel modificado de Linux que permite la ejecución de Xen. Esta entrada

debe añadirse en el archivo /boot/grub/menu.lst (también puede ser /boot/ grub.conf

en ciertas distribuciones).

La entrada que debe añadirse es una similar a:

En esta entrada, la palabra title precede al título que se mostrará en el menú de

elección del sistema operativo, root indica el disco a emplearse, kernel dice al GRUB

el lugar donde encontrará a Xen y los parámetros de arranque, module indica la

ubicación del kernel modificado a cargarse junto con sus respectivos parámetros.

Una vez añadida esta entrada, cada vez que se encienda el equipo aparecerá en el

menú la opción de cargar esta versión de Linux con el kernel modificado para su uso

con Xen.

3.2.3.3. Configuración y creación de Máquinas virtuales

Al arrancar el sistema con Xen, automáticamente arranca el dominio de

administración dom0, a través del cual se pueden crear y cargar otros dominios. Para

la creación de un nuevo dominio es necesario realizar tres acciones: inicializar el

demonio de Xen (xend start), preparar un archivo de sistema o partición a actuar

como disco duro de la nueva máquina virtual (se puede emplear un archivo de

imagen, una partición completa de Linux, un LVM, entre otros), y finalmente se debe

crear un archivo de configuración con los parámetros de la máquina virtual.

title CentOS (2.6.18-164.el5xen) root (hd0,0) kernel /xen.gz-2.6.18-164.el5 module /vmlinuz-2.6.18-164.el5xen ro root=LABEL=/ pci=nommconf rhgb quiet module /initrd-2.6.18-164.el5xen.img

Espacio de Código 3.1 Código a introducirse en el archivo menu.lst para permitir el inicio del kernel de Xen.

3.2.3.3.1. Archivo de configuración de dominio

El archivo de configuración del dominio es aquel que contiene los parámetros para

brindar a la máquina virtual los recursos requeridos y configurar sus parámetros. Al

instalar Xen se incluyen archivos de configuración de ejemplo que pueden resultar

muy útiles.

Los archivos de configuración tienen un formato del tipo variable = valor en el que

cada línea corresponde a un parámetro de configuración. Los parámetros de

configuración son:

· kernel: El path a la imagen del kernel.

· ramdisk: El path a la imagen del ramdisk.

· memory: Tamaño de la memoria en megabytes.

· vcpus: El número de CPUs virtuales.

· console: Puerto para exportar la consola del dominio (por default es 9600 + el

ID del dominio).

· vif: Configuración de la interfaz de red. Aquí se puede configurar la dirección

IP, MAC, el tipo de puente, el nombre, entre otros. Cada cadena de caracteres

representa a una interfaz y si no se especifican los parámetros Xen pondrá

valores por default inteligentes. Ej.

vif = [ 'mac=00:16:3E:00:00:11, bridge=xen-br0', 'bridge=xen-br1' ]

· disk: Lista de los dispositivos de bloque a exportar al dominio. Ej.

disk = [ 'phy:hda1,sda1,r' ]

En este caso se dice que el medio físico de dom0 llamado /dev/hda1

(phy:hda1) se exportará al domU con el nombre de /dev/sda1 (sda1) y

tendrá derechos de lectura y escritura (r). Se puede emplear

tap:aio:/path/al/archivo para emplear el driver blktap en lugar del de

loopback en los file-backed VBD esto permite entrada y salida

asincrónica (aio - asynchronous I/O). Al usar esto se debe exportar al

domU con el nombre xvda.

· dhcp: Establece DHCP.

· netmask: Configura una máscara de red de manera manual.

· gateway: Configura una ruta de enlace predeterminada de manera manual.

· name: Configura un nombre de host para la máquina virtual.

· root: Identifica el dispositivo root en el kernel del domU y especifica los

argumentos para el montaje inicial.

· nfs: Dirección IP del servidor NFS.

· nfs root: Path hacia el archivo de sistema root del servidor NFS.

· extra: Cadena de caracteres extra para añadir a la línea de comandos del

kernel.

· pci: Se necesita añadir este parámetro si se está escondiendo dispositivos de

hardware del dom0 pero se desea usarlos en el domU. Ej.

pci= [ ‘00:09:0’ ]

Esto quiere decir que el dispositivo PCI con la identificación 00.09.0 se

usará en el domU

· on_poweroff, on_reboot, on_crash: Especifican el comportamiento que

debe tener el dominio en caso de apagado, reiniciado, o caída

respectivamente. El dominio puede destruirse (destroy) o reiniciarce (restart).

A continuación se muestra el archivo de configuración de una de las máquinas

virtuales creadas para el presente proyecto. La máquina corresponde a un servidor

# # Archivo de configuracion para la instancia de Xen # vhttp_lc_256_10.img creado por JJBS y DSCA el # Thu Aug 6 19:36:31 ECT 2009. # # # Kernel + tamaño de memoria # kernel = '/boot/vmlinuz-2.6.18-92.1.22.el5xen' memory = '256' bootloader = "/usr/bin/pygrub" # # Dispositivo(s) de disco. # disk = [ "tap:aio:/vm/servidores/vhttp/vhttp_lc_256_10.img,xvda,w" ] # # Hostname # name = 'vhttp'

# # Networking # dhcp = 'dhcp' vif = [ 'ip=192.168.0.204,mac=00:16:3e:3b:c0:cf,bridge=xenbr0' ] # # Comportamiento # on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' # # Visualización # vnc = 1 sdl = 0

3.2.3.3.2. Configuración de la Red

Las comunicaciones de la red de las máquinas virtuales son manejadas a través del

Dom0. El Dom0 permite la asociación de las interfaces reales con las interfaces

virtuales. Este proceso se da mediante la utilización de drivers de backend

correspondientes a los drivers del hardware real en el Dom0 y dirvers front-end en los

DomU correspondientes a dispositivos genéricos. Este hecho permite la

independencia del hardware real, en cuanto a dispositivos de red, de los emulados en

la VM.

Cada máquina virtual denomina a sus interfaces de red como eth#. Así por ejemplo

una VM con dos interfaces de red las denominará por defecto eth0 y eth1.

Estas interfaces son asociadas a interfaces virtuales creadas en el Dom0 denomindas

vif´s o virtual interfaces.

Cada dominio posee su interfaz asociada a su Dom#Id (identificador creado al

momento de la inicialización de una VM). Así el Dom0 posee las interfaces vif0.x, el

Dom1 las interfaces asociadas a vif1.x, etc. El valor correspondiente a la x es definido

por el número de interfaces creadas en los dominios virtuales; así por ejemplo si en

un dominio Dom#ID crea dos interfaces de red (eth0 y eth1), las interfaces asociadas

Espacio de Código 3.2 Archivo de configuración del dominio para un servidor

en el Dom0 serán vif#ID.0 y vif#ID.1, y así para un Dom3 con dos interfaces tendrá

las interfaces virtuales vif3.0 y vif3.1.

Cuando un DomU es apagado las interfaces de red virtuales creadas son eliminadas,

pudiendo ser usadas por otro dominio que posea el mismo identificador.

Las interfaces del Dom0 (vif0.x) son asociadas a las interfaces reales y usadas de

acuerdo a lo que se requiera en la configuración de la red. Estas interfaces son

llamadas veth o eth.

Esta descripción se puede observar en la figura siguiente:

Figura 3.16 Diagrama de dispositivos de red de los Dominios virtuales. Fuente: wiki.xensource.com/xenwiki/XenNetworking

Las direcciones MAC de las tarjetas Ethernet creadas pueden ser especificadas en el

archivo de configuración de las VM; la configuración en el archivo de creación de las

VM´s deberá especificarse por ejemplo así: vif = ['mac=aa:00:00:00:00:11'] o bien no

incluir en cuyo caso será configurado dinámicamente por Xen.

En base a estas configuraciones iniciales es posible realizar tres tipos de

configuraciones de red las cuales son:

§ Bridged Networking

§ Routed with Nat Networking

§ Two way Routed Network

La configuración del tipo de configuración se lo hace a través de scripts localizados

en: /etc/xen/xend-config.sxp

§ Bridged Networking

Esta configuración permite conectar múltiples redes correspondientes a las VM´s

directamente a un dispositivo de red físico a través de la asociación a una tarjeta de

red real del hardware subyacente.

La noción de Bridged Networking es la de un switch virtual a la que se conectan las

VM´s configuradas a pertenecer a éste. El nombre que Xen asigna por defecto a esta

configuración es la de xenbr.

El funcionamiento se da mediante la asociación de las tarjetas de red de las VM´s

(DomU) a las interfaces virtuales vif`s del Dom0 y éstas a una abstracción de la

tarjeta real denominada eth o veth. Un diagrama general de la presente configuración

es la siguiente:

Figura 3.17 Ilustración 2 de Bridged Networking. Fuente: wiki.xensource.com/xenwiki/XenNetworking

Como se puede observar, todas las máquinas (virtuales y no virtuales) se encuentran

configuradas dentro del mismo rango de direcciones IP. El Dom0 actúa como un hub

virtual haciendo un forwarding del tráfico.

La configuración se la realiza agregando las siguientes líneas al archivo

/etc/xen/xend-config.sxp, las cuales llaman a los scripts network-bridge y vif-bridge.

§ Routed with Nat Networking

Esta configuración permite que los equipos virtuales servidores provean de sus

servicios mediante un Nateo realizado a través del Dom0.

La noción de Nat Networking es la de un switch virtual a la que se conectan las VM´s

configuradas a pertenecer a éste.

Un diagrama general de la presente configuración es la siguiente:

Figura 3.18 Ilustración de Routed with Nat Networking. Fuente: wiki.xensource.com/xenwiki/XenNetworking

(network-script network-bridge)

(vif-script vif-bridge)

Espacio de Código 3.3 Código para configuración tipo bridge.

En el diagrama anterior se puede observar que las VMs están en una difieren red

privada LAN. Para alcanzar el tráfico de las otras redes las VM´s deben ser nateadas

desde el Dom0.

Esta configuración permite a las VM´s pertenecer a redes privadas independientes y

que los servicios sean entregados a nombre de la IP configurada en el Dom0; así de

esta manera se impide a los host´s de la red ver directamente a los servidores. Esta

situación agrega más seguridad a la configuración.

/etc/xen/xend-config.sxp, las cuales llaman a los scripts network-nat y vif-nat.

§ Two Way Routed Network

Esta configuración brinda las mismas características de independencia de la red

privada de los servidores tal como la configuración anterior. La diferencia es que los

servidores pueden ser alcanzados directamente por los host´s mediante el uso de

rutas configuradas en Dom0 que permitan interconectar redes diferentes.

Figura 3.19 Ilustración de Routed Networking. Fuente: wiki.xensource.com/xenwiki/XenNetworking

(network-script network-nat)

(vif-script vif-nat)

Espacio de Código 3.4 Código para configuración de Network Nat.

En el diagrama se observan a los DomU´s en una red diferente a la de la red

corporativa. El tráfico de cada DomU necesita ser ruteado para ser enviado fuera de

su red.

/etc/xen/xend-config.sxp que llaman a los scripts network-route y vif-route.

3.2.3.3.3. Configuración utilizada

De los tipos de configuración analizados, se ha escogido para el presente diseño del

prototipo el tipo Bridged al que se le añade un router virtual. Esta configuración nos

permitirá obtener los siguientes beneficios:

§ Facilidad de configuración de los dispositivos de red de las VM´s para dar

lugar a la agrupación de los servidores virtuales en redes diferentes.

§ Se reduce el efecto de broadcasts por la segmentación de la red a través

del router virtual.

§ Se agrega mayor seguridad tanto a la red interna como a la red externa y

mediante la aplicación de reglas especiales de control de tráfico entre los

diferentes dominios y los hosts de la red mediante el router virtual

§ Posibilidad de balanceo de carga de las interfaces de red mediante la

especialización de las mismas a cada necesidad de las VM´s.

Con esto se logra cumplir con los siguientes puntos del diseño como se ven a

continuación:

(network-script network-route)

(vif-script vif-route)

Espacio de Código 3.5 Código para configuración de Two Way Routed

Figura 3.20 Bridges configurados según diseño.

La configuración de Bridged Networking por defecto permite utilizar una sola NIC y un

Bridge. En la presente implementación se usarán dos NIC´s (eth0 y eth1) asociadas a

dos Bridge (xenbr0 y xenbr1). Estos cambios se lo hacen a través de Scripts

localizados en la máquina anfitriona en: /etc/xen/xend-config.sxp, en la cual se

reemplaza el script network/bridge por el creado denominado script-PyMES. Éste

último se localiza en: /etc/xen/Scripts/script-pymes como se muestra a continuación:

Espacio de Código 3.6 Archivos de configuración de Bridged Networking

Espacio de Código 3.7 Script script-PyMES para una Bridged Networking

En este script se especifican los dispositivos de red físicos eth0 y eth1 del equipo real

asociados a los bridges xenbr0 y xenbr1. Éstos permitirán la configuración de las

VM´s respectivas en los bridges de acuerdo a su archivo de configuración.

Es posible realizar la configuración de tipo Two Way Routed la cual puede ser vista

en el anexo F.

3.2.3.3.4. Configuración de Dispositivos de Almacenamiento

La configuración de los dispositivos de almacenamiento puede hacérsela ya sea en

tiempo de configuración inicial de la VM o en caliente.

Así, al momento de la configuración inicial de la VM se especifica en su archivo de

configuración el disco principal con el cual funcionará dicha instancia de máquina

virtual. En este primer caso lo que se hace es exportar un dispositivo físico o “physical

block device” como un disco duro, una partición o un archivo de imagen96 desde el

Dom0 directamente al DomU. Este nuevo dispositivo añadido a la máquina virtual es

conocido como virtual block device (VBD) o file-backed VBD para el caso de

imágenes.

96 Un archivo de imagen corresponde a un espacio de memoria creado para la utilización de una máquina virtual en el cual típicamente se instala el sistema operativo guest con su correspondiente espacio de disco para archivos y carpetas de los usuarios. Su utilización permite la rápida copia de VM´s en base a la imagen creada.

disk = [ 'phy:dom0,domU,mode' ]

xm block-attach <Domain Id> <Backend Device> <Frontend Device> <Mode>

El Domain0 permite el acceso a los DomU mediante el parámetro 'disk' (del archivo

de configuración de las VM´s):

donde:

§ dom0: es el path del dispositivo del Domain0.

§ domU: representa como el dominio U reconocerá al dispositivo.

§ Mode: 'r' para read-only, 'w' para read-write.

Esto se muestra en la siguiente línea:

En este caso se está añadiendo el archivo de imagen vhttp_lc_256_10.img localizado

en el Dom0 el cual es exportado en el modo de “read-write” al nuevo dominio como

/dev/xvda.

Por otra parte, es posible agregar un dispositivo de almacenamiento una vez

encendida la máquina. Esto se conoce como agregación en caliente.

Para dar lugar a este procedimiento es necesario que el dispositivo a ser añadido

deba estar montado en el Dom0 y no ser utilizado al mismo tiempo por varios

dominios.

Se hace uso de la herramienta xm con su opción block-attach.

La sintaxis para añadir un dispositivo de almacenamiento es la siguiente:

disk = [ "tap:aio:/vm/servidores/vhttp/vhttp_lc_256_10.img,xvda,w" ]

Espacio de Código 3.8 Configuración de un dispositivo de almacenamiento para VM.

donde:

§ <Domain Id> es el ID del DomU

§ <Backend Device> Representa el dispositivo del Dom0; por ejemplo:

/dev/sr0

§ <Frontend Device> es el nombre del dispositivo para el DomU. Debe

poseer el prefijo xvd, por ejemplo: /dev/xvda2

§ <Mode> Corresponde a si es read/write. Las opciones son r para read-only,

w para read/write y w! para read/write compartido.

Esto se muestra en la siguiente línea:

En este caso se añade en caliente al Dom3 el dispositivo del Dom0 /dev/sr0 (que

puede ser cualquier dispositivo de almacenamiento inclusive una unidad de DVD) y

accesible en /dev/xvda2 del DomU con permisos de solamente lectura.

Una vez añadido el dispositivo debe ser montado en el DomU:

Una vez finalizado su uso deberá ser desmontado:

Luego de lo cual debe ser desañadido del domU con el ID utilizado y el dispositivo

respectivo:

xm block-attach 3 phy:/dev/sr0 /dev/xvda2 r

mkdir /tmp/mnt

mount /dev/xvda2 /tmp/mnt

umount /tmp/mnt

xm block-detach 3 /dev/xvda2

Espacio de Código 3.9 Código para añadir en caliente un dispositivo de almacenamiento

Espacio de Código 3.10 Código para desvincular en caliente un dispositivo de almacenamiento

Finalmente, Xen soporta protocolos estándar de almacenamiento en red com NBD,

iSCSI, NFS, etc., los cuales pueden ser usados para proveer almacenamiento a las

máquinas virtuales; sin embargo en la configuración del presente prototipo no se han

usado este tipo de configuraciones.

3.2.3.3.5. Comandos de XEN

§ Xend

Xend es el demonio de control de nodos y ejecuta ciertas funciones de administración

de sistemas relacionadas con las máquinas virtuales. Este constituye un punto

central de control de los recursos virtualizados y debe ser ejecutado para dar lugar al

inicio y manejo de las máquinas virtuales.

Los parámetros de operación de xend pueden ser configurados editando el archivo de

configuración de xend, xend-config.sxp, ubicado en el directorio /etc/xen.

A continuación se presentan los parámetros editables en el archivo de configuración

xend-config.sxp:

Ítem Descripción console-limit Determina el límite del buffer de memoria del servidor de consola y

asigna valores para cada sistema

min-mem Determina el número mínimo de megabytes reservados para domain0 (el valor no cambia si se introduce 0)

dom0 cpus Determina el número de CPU que domain0 usa (al menos una CPU se asigna por defecto)

enable-dump Determina que un error ha ocurrido y activa el volcado (0 es el valor predeterminado)

external-migration-tool

Determina el script o la aplicación que controla la migración de dispositivos externos (los script deben estar en etc/xen/scripts/external-device-migrate)

logfile Determina la ubicación del archivo del registro (por defecto está en /var/log/xend.log)

loglevel Filtra los valores para los modos de registro: DEBUG, INFO, WARNING, ERROR o CRITICAL (por defecto es DEBUG)

network-script Determina el script que activa el entorno de red (los script deben estar en el directorio etc/xen/scripts )

xend-http-server

Activa el servidor de administración de paquetes de flujo http (el valor predeterminado es no)

xend-unix-server

Activa el servidor de socket de dominio unix (un servidor de socket es un punto de comunicación que maneja conexiones de red de bajo nivel y acepta o rechaza conexiones entrantes)

xend-relocation-server

Activa el servidor de ubicación para las migraciones entre máquinas (el valor por defecto es no)

xend-unix-path

Determina la ubicación a donde el comando xend-unix-server envía mensajes de salida (el valor por defecto es var/lib/xend/xend-socket)

xend-port Determina el puerto que el servidor de administración http utiliza (el valor predeterminado es 8000)

xend-relocation-port

Determina el puerto que el servidor de ubicación utiliza (el valor predeterminado es 8002)

xend-relocation-address

Determina las direcciones de la máquinas virtuales a las cuales se les permite la migración de sistemas

xend-address Determina la dirección a la cual el servidor de socket del dominio está vinculado.

Tabla 3.4 Parámetros configurables de xend. Fuente: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/es-ES/Virtualization/ch-virt-task-

virsh-config-max-mem.html

Una vez iniciado el demonio xend, puede administrarse la arquitectura virtual

mediante la herramienta xm.

La aplicación xm es una herramienta de administración robusta que permite la

administración del entorno de virtualización. Antes de utilizar xm es necesario que el

demonio xend este siendo ejecutado en el sistema.

El formato general de utilización es el siguiente:

# xm comando [switches] [argumentos] [variables]

Los switches y argumentos dependen del comando elegido.

3.2.3.4. Migración de Máquinas Virtuales

Una de las ventajas que brinda la virtualización es la facilidad de migración de las

máquinas virtuales. La migración es el transferir un dominio entre equipos físicos.

Existen varios métodos para realizar este procedimiento, que puede ir desde la

simple copia del archivo imagen del disco duro y archivo de configuración (migración

regular) hasta una migración en vivo.

Una de las formas de migración es mediante la grabación y restauración del dominio.

Es posible emplear el comando xm save para suspender el estado de una máquina

virtual y grabarlo en un archivo. Así por ejemplo:

# xm save VM1 VM1.chk

Este comando suspende la máquina virtual VM1 y graba su estado de en el archivo

VM1.chk.

Una vez terminada la migración, se puede emplear el comando xm restore para

restaurar la máquina virtual. Así por ejemplo:

# xm restore VM1.chk

Este comando restaura la máquina virtual cuyo estado estaba grabado en el archivo

VM1.chk. Otra forma de realizar la migración es simplemente emplear el comando xm

migrate el cual pausa la máquina virtual, la copia y reanuda la misma.

Por otro lado la migración en vivo corresponde a la copia del dominio pero sin la

necesidad de suspender la máquina virtual, de hecho para dicho equipo la migración

debe parecer imperceptible.

Para poder realizar una migración en vivo, ambos hosts deben estar corriendo xend y

el destino debe de tener los suficientes recursos, además, debido que al mover una

máquina virtual también se moverá sus direcciones MAC e IP, actualmente se

requiere que ambas máquinas se encuentren en la misma subred. El comando para

realizar la migración es xm mígrate y para que sea en vivo se añade el parámetro –

live. Así por ejemplo:

# xm migrate --live VM destino.red.com

3.2.3.5. Configuración de VM´s para Unmodified OS

Además de brindar una solución de paravirtualización Xen también puede ser

empleado para virtualizar sistemas operativos sin modificaciones, para esto requiere

de la asistencia de procesadores especializados (Intel VT y AMD-V) por lo que la

virtualización recibe el nombre de virtualización asistida por hardware y a la

tecnología se denomina Hardware Virtual Machine (HVM).

Además de requerir procesadores especializados, el soporte HVM de Xen requiere

disponer de unos paquetes adicionales que no vienen incluidos en ciertas

distribuciones de Linux. Estos paquetes son:

dev86: Se trata de un ensamblador para instrucciones x86 de modo real. Este

paquete es el que permite armar el código de BIOS que corre en el modo real (virtual)

SDL-devel: Brinda otra forma de virtualizar consolas huéspedes no modificadas.

Brinda una ventana X para la misma.

La instalación de Xen trae consigo un ejemplo de archivo de configuración para HVM,

el archivo es /etc/xen/xmexample.hvm. Este archivo de configuración, además de

aceptar las opciones comunes especificadas en el punto 3.3.4.3.1., puede aceptar

otras opciones características solo para este tipo de virtualización. Así, las opciones

más importantes son:

· kernel: En el caso de HVM esta opción especifica el cargador de firmware

HVM, /usr/lib/xen/boot/hvmloader

· builder: Es el creador del dominio, en el caso de HVM se emplea el creador

· acpi: Habilita ACPI de huéspedes HVM, el valor por default es 1 (habilitado)

· apic: Habilita APIC de huéspedes HVM, el valor por default es 1 (habilitado)

· pae: Habilita PAE de huéspedes HVM, el valor por default es 1 (habilitado)

· hap: Habilita el paginado asistido por hardware existente tanto en Intel VT

como en AMD-V.

· vif: En el caso de HVM se puede definir en esta opción el valor de

type=ioemu, esto quiere decir que para virtualizar la tarjeta de red HVM se

empleara ioemu, si no se especifica se emplea vbd que es el default para la

paravirtualización.

· disk: Al igual que en la paravirtualización define los dispositivos de disco a

emplearse y el nombre con el que podrán ser accedidos. En el caso de HVM

cada entrada de disco debe tener la forma:

phy:UNAME,ioemu:DEV,MODE,

Siendo ‘UNAME’ el archivo de dispositivo anfitrión, ‘DEV’ es el nombre

de dispositivo visto por domU, y ‘MODE’ puede ser ‘r’ para solo lectura,

y ‘w’ para lectura y escritura. ‘ioemu’ significa que el disco empleará

‘ioemu’ para virtualizar el disco HVM. Si se usa un archivo de imagen se

debe intercambiar ‘phy’ por ‘file’

Es posible emular dispositivos ópticos añadiendo el cdrom al dispositivo de

tipo ',hdc:cdrom,r'

· boot: Dispositivos de arranque. Arranca desde disco floppy (a), disco duro (c)

o CD-ROM (d). Por ejemplo para intentar arrancar primero desde el CD-ROM

y luego desde el disco duro:

boot='dc'

· vnc: Habilita librerías VNC para la interfaz gráfica. El default = 0 significa

deshabilitada.

· sdl: Habilita librerías SDL para la interfaz gráfica. El default = 0 significa

deshabilitada.

· vncconsole Permite generar vncviewer (sólo es válido cuando vnc=1), default

= 0 (deshabilitado).

· usb: Permite el soporte USB sin definir un dispositivo USB específico.

· usbdevice: Permite el soporte USB y habilita el soporte para el dispositivo

dado. Se pueden especificar: mouse, tablet y host:id1:id2 (un dispositivo USB

físico en la máquina anfitriona cuyos ids son id1 e id2). La opción tablet tiene

la ventaja de que en sistemas huéspedes Windows reconocerá y soportará el

dispositivo automáticamente

· localtime: Configura la hora local.

· soundhw: Habilita el soporte a la tarjeta de sonido y especifica el hardware a

emular. Acepta valores de: sb16, es1370, all y none (default).

· full-screen: Inicia en pantalla completa.

Una vez creado el archivo de configuración se puede crear y destruir el dominio HVM

de la misma manera que se hace con los dominios paravirtualizados.

3.2.3.6. Pruebas

Para el propósito del presente proyecto se ha utilizado archivos de configuración

similares al presentado como ejemplo en el punto 3.2.3.3.1., para virtualizar cada

unos de los servidores propuestos en el diseño de la granja de servidores del centro

de datos presentado en el punto 3.2.3. del presente capítulo. Cabe recalcar que aún

no se han configurado los servicios requeridos, sólo se ha procedido a la creación de

los dominios requeridos (La configuración de los servicios puede observarse en el

siguiente capítulo).

En la Figura 3.21 se muestra una ventana de la interfaz gráfica del administrador de

máquinas virtuales incluido con Xen en la distribución CentOS de GNU/Linux. Se

pueden observar varias máquinas virtuales corriendo de manera simultánea.

Figura 3.21 Ventana de un administrador de máquinas virtuales que muestra a las mismas

ejecutándose de manera simultánea en un único servidor físico.

En la figura 3.22 se muestra la consola del servidor virtual vhttp arrancando:

Figura 3.22 Ventana de la consola de una máquina virtual que muestra su inicio.

En la figura 3.23 se muestran las pruebas de conectividad de la máquina virtual con el

servidor físico de dirección 192.168.15.10.

Figura 3.23 Ventana de la consola de una máquina virtual que muestra su conectividad con el servidor físico.

En la figura 3.24 se muestran dos ventanas de consola correspondientes a dos

servidores virtuales probando la conectividad entre los mismos. Por el momento, al no

estar configurados los servicios, las únicas pruebas que se pueden realizar son las de

conectividad y el comprobar el inicio sin problemas de las máquinas.

Figura 3.24 Ventanas de dos consolas de máquinas virtuales que muestran su conectividad entre ellas.

Finalmente, en la figura 3.25 se muestran ciertos detalles de la carga de la máquina

virtual mientras esta se encuentra corriendo.

Figura 3.25 Ventanas de detalle de una máquina virtual.

CAPÍTULO CUATRO

4. INSTALACIÓN, CONFIGURACIÓN, Y PRUEBAS

DE LOS SERVICIOS NECESARIOS PARA

SATISFACER LAS NECESIDADES

TECNOLÓGICAS GENÉRICAS DE LAS PyMES.

En base a los requerimientos analizados en el capítulo 2 y en base al esquema de

diseño de servidor virtualizado presentado en el capítulo 3, en el presente capítulo se

presenta la instalación, configuración y pruebas de los servicios requeridos por las

PYMES.

Con la finalidad de referenciar los servidores a crearse, a continuación se retoman los

servicios requeridos para las PYMES.

4.1. CUADRO DE SERVICIOS PARA PYMES

Servicios Relación con Requerimientos PyMES

§ Stack de protocolos

TCP/IP.

§ Conexión a Internet, Todos los

requerimientos Intranet /Extranet.

§ Servicio de DHCP. § Intranet, configuración dinámica de

equipos.

§ Servicio DNS: Intranet,

Extranet.

§ Portales web (Internos, Externos),

Correo electrónico, Acceso otras

sucursales, manejo de dominio, etc.

§ Servidor de páginas Web § Portales Web (Internos, Externos),

Comercio electrónico, Webmail.

§ Servidor de correo

electrónico.

§ Correo Electrónico (Contacto clientes

y Empresarial), Webmail.

§ Servidor de Mensajería

Instantánea.

§ Mensajería instantánea.

§ Servidor de Base de Datos. § Comercio electrónico, control de

producción, ventas, etc.

§ Servicio de directorio. § Control de usuarios, Seguridad

informática

§ Proxy / Firewall. § Seguridad extranet / intranet,

Conexión a Internet.

§ Establecimiento de DMZ.

§ Detección de virus y spam § Seguridad extranet / intranet.

con scanner de mails.

§ Acceso remoto con SSH.

§ Conexión segura con otras

§ Servidor FTP.

§ Transferencia de archivos.

§ Establecimiento de VPN. § Conexión segura con otras

§ Aplicaciones de servicio de

Voz sobre IP.

§ Telefonía.

Tabla 4.1 Requerimientos técnicos para TIC´s en las PyMES

4.2. ESQUEMA DE SOLUCIÓN DE SERVIDOR VIRTUALIZADO

PARA EL DATACENTER

Tal como lo presentado en el capítulo 3, el diseño del servidor virtualizado para el

cetro de datos de las PyMEs se conforma por tres subsistemas identificables:

§ Datacenter de datos

§ Datacenter de Infraestructura

§ Datacenter dmz

El Datacenter de datos agrupa los servidores correspondientes al manejo,

almacenamiento y distribución de la información necesaria para el desenvolvimiento

de las actividades de la organización productiva. Estos son los servidores de Base de

datos, FTP, Servidor de archivos, Web empresarial, Impresión.

Este módulo del datacenter hace parte de una red independiente del resto, la cual

puede configurarse su acceso de acuerdo a las necesidades de la organización

mediante el router de la intranet.

El Datacenter de infraestructura agrupa los servidores correspondientes a la

habilitación de la operabilidad de la red. Estos servidores brindan las características

básicas de conectividad para usuarios así como comunicación entre ellos. Está

conformado por los servidores de DNS primario y su correspondiente Backup,

Directorio, Mail empresarial, DHCP y el Router de la Intranet.

De igual forma el datacenter de infraestructura forma parte de una red independiente

en el servidor virtualizado.

El datacenter de la dmz agrupa y separa los servidores que serán expuestos a

Internet de los servidores antes descritos en infraestructura y datos. Agrupa los

servidores que realizaran funciones de Gateway y dan la cara a los clientes de la

organización. Aquí se encuentran los servidores de Mail Gateway, DNS primario y

secundario exclusivamente para la dmz y como relay para servidores de mayor

autoridad, servidores de Comercio electrónico y web para Internet.

La finalidad de estos tres subsistemas es la de garantizar el mejor desempeño

posible del servidor virtualizado de acuerdo a su uso ya sea por los usuarios de la

Intranet como por los usuarios de Internet. A la vez se proporciona un ambiente

seguro mediante la implantación de la dmz la cual permite determinar la separación

de los servidores críticos de la organización con los servidores que van a tener

acceso desde Internet.

En el lado de la Intranet se busca obtener la separación de los servidores que

requieren de alta disponibilidad y se les da alto uso como son los servidores de DNS,

DHCP y correo electrónico de los servidores no tan críticos como son los servidores

de archivos, impresión, web interna, ftp, etc.

Finalmente se proporciona mayor seguridad al sistema mediante la implementación

servidores de firewall, proxy, NAT, y routing tanto para la intranet como par internet. A

esto se suma la implantación de la dmz ya mencionada.

Del lado del usuario, la configuración del servidor router de la intranet permitirá la

separación de los servicios y accesos entre los diferentes departamentos

administrativo-productivos de la PyME mediante un proceso de separación por redes

o dominios de broadcast. Este hecho permite obviar el impedimento de insuficiencia

de interfaces disponibles en routeadores para la creación de redes mediante la

creación de tantas interfaces virtuales como redes de la organización. Con ello no

será indispensable la configuración de vlans para garantizar seguridad, reducción de

dominios de broadcast, y especialización de departamentos.

Con lo mencionado se presenta el diagrama correspondiente al prototipo de Servidor

Virtualizado para PyMEs.

Figura 4.1 Esquema de solución de Servidor Virtualizado para PyMES.

4.2.1. ESQUEMA DE DIRECCIONAMIENTO DEL DATACENTER

Como se mencionó en el punto anterior el centro de datos dispone se compone de

tres niveles, el de datos, infraestructura y la zona desmilitarizada. Cada una de estas

zonas dispondrá de su propia subred, de la misma forma, el rango de direcciones de

la red de la empresa es independiente de las redes del servidor. Esta independencia

de redes de cada zona se puede lograr debido a que, para el enrutamiento, se

emplearán routers virtuales por lo que no se requiere la compra de equipos

especiales, además de esta manera el servidor virtualizado se vuelve más abierto al

poder emplearse en cualquier red empresarial independientemente de su sistema de

direccionamiento, únicamente se debe configurar esta red en el router de ingreso al

servidor.

Como se puede ver en el diagrama del centro de datos, cada una de estas redes

requiere de siete direcciones IP ya que cada una cuenta con cinco servidores con una

interfaz de red cada uno y además se conecta a dos servidores de ruteo.

Para el direccionamiento se decidió emplear la red 10.0.0.0/24 para la zona de datos,

la 10.0.1.0/24 para la zona de infraestructura y la red 10.0.2.0/24 para la zona

desmilitarizada. Con estas redes se podrían conectar hasta 254 dispositivos en cada

una, sin embargo se debe mencionar que el limitante en este caso sería la capacidad

del servidor físico y del software de virtualización Xen. Pese a la cantidad de

direcciones que quedarían sin utilizar, se decidió emplear dicho direccionamiento ya

que brinda gran facilidad y al ser independiente de la red interna de la empresa no

genera problema de desperdicio de direcciones.

El direccionamiento final para el centro de datos es el que se muestra a continuación:

Zona Dirección IP Servidor

Datos 10.0.0.1/24 firewallproxy

10.0.0.2/24 basededatos

10.0.0.3/24 webempresarial

10.0.0.4/24 impresion

10.0.0.5/24 servidordearchivos

10.0.0.6/24 ftp

10.0.0.254/24 routerintranet

Infraestructura 10.0.1.1/24 firewallproxy

10.0.1.2/24 dnsiprimario

10.0.1.3/24 dnsisecundario

10.0.1.4/24 directorio

10.0.1.5/24 mailempresarial

10.0.1.6/24 dhcp

10.0.1.254/24 routerintranet

DMZ 10.0.2.1/24 firewallproxy

10.0.2.2/24 comercioelectronico

10.0.2.3/24 mailgateway

10.0.2.4/24 webinternet

10.0.2.5/24 dnseprimario

10.0.2.6/24 dnsesecundario

10.0.2.254/24 firewallinternet

Internet Dirección IP en la red del

modem de salida a Internet

firewallinternet

Red Interna Dirección IP en la red

interna de la empresa

routerintranet

Tabla 4.2 Direccionamiento del Centro de Datos

Servidor Virtualizado con esquema de direccionamiento IP

4.2.2. INSTALACIÓN DEL SERVIDOR VIRTUAL BASE

Para la implementación de los servidores virtualizados con sus servicios respectivos,

se utilizará como base una máquina virtual de instalación de sistema operativo GNU-

Linux CentOS 5.2 sobre el Hypervisor Xen 3.1 en función de las características

analizadas en el capítulo 3. Ésta base de servidor virtual permitirá acoplarse de

manera general eficientemente y con flexibilidad para los requerimientos específicos

de la instalación de cada servicio a implementarse.

Se presenta en tal virtud, a continuación la instalación de la máquina virtual que

servirá de plantilla para el resto de servidores a configurar. Consideraciones

adicionales y más específicas sobre el dimensionamiento de los recursos de cada

servidor, serán analizados en el capítulo 5 de la presente investigación.

4.2.2.1. Consideraciones de instalación de la VM

Para la instalación de una máquina virtual, el primer paso es la asignación de los

recursos de hardware necesarios para el funcionamiento de la máquina virtual.

Principalmente se debe asignar un espacio de disco duro, una cantidad de memoria y

una o más tarjetas de red.

Aunque existen herramientas para realizar la instalación de una máquina virtual

mediante un entorno gráfico, es probable que no sea posible acceder a este entorno

en el servidor por lo que en este punto se analizará la instalación de la máquina

virtual desde un medio de consola. Principalmente esto se puede hacer usando las

herramientas básicas de Xen y realizando modificaciones en archivos de

configuración o se puede emplear la herramienta virt-install.

4.2.2.2. Asignación de Disco Duro

En cualquiera de las opciones para instalar una máquina virtual, lo primero que debe

hacerse es seleccionar un espacio en el disco duro para asignar a la misma. Una de

las formas más sencillas es el asignar como disco duro de la máquina virtual a una

partición cualquiera existente en el disco, siendo lo más recomendable emplear

particiones lógicas LVM al ser estas las más sencillas de manipular. La otra forma

para asignar un espacio de disco duro es mediante la creación y formateo de un

archivo imagen, esto se logra empleando los siguientes comandos:

# dd if=/dev/zero of=discoMV1.img bs=1k seek=10240k count=0

# mkfs -t ext3 discoMV1.img

4.2.2.3. Instalación sin el uso de herramientas adicionales

En este caso, lo primero que se debe hacer es bajarse una copia de la imagen del

sistema operativo a instalarse, así por ejemplo:

wget http://mirror.centos.org/centos/5.2/os/i386/images/xen/vmlinuz -O /tmp/

wget http://mirror.centos.org/centos/5.2/os/i386/images/xen/initrd.img -O /tmp/

Entonces se procede a crear el archivo de configuración de la máquina virtual.

# # Archivo de configuracion para la instancia de Xen # vdns_lc_256_10.img creado por JJBS y DSCA el Thu Aug 6 19:20:56 # ECT 2009. # # # Kernel + tamano de memoria # kernel = '/tmp/vmlinuz' ramdisk = '/tmp/initrd.img' memory = '256' # # Dispositivo(s) de disco. # disk = [ "tap:aio:/vm/servidores/vdns/vdns_lc_256_10.img,xvda,w" ] # # Hostname # name = 'vdns' # # Networking # dhcp = 'dhcp' vif = [ 'mac=00:16:3e:0a:34:f1,bridge=xenbr0' ] #

# Behaviour # on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' vnc = 1 sdl = 0

Espacio de Código 4.1 Archivo de configuración para la creación de una Máquina Virtual

Finalmente se procede a la creación de la máquina virtual mediante el comando:

xm create -c configuration.cfg

Y se prepara el archivo de configuración para el boot reemplazando las dos primeras

líneas, en que se define kernel y ramdisk como se indica en el siguiente espacio de

código.

# Archivo de configuracion para la instancia de Xen # vdns_lc_256_10.img creado por JJBS y DSCA el Thu Aug 6 19:20:56 # ECT 2009. # Kernel + tamano de memoria kernel = '/boot/vmlinuz-2.6.18-92.1.22.el5xen' memory = '256' bootloader = "/usr/bin/pygrub" # # Dispositivo(s) de disco. # disk = [ "tap:aio:/vm/servidores/vdns/vdns_lc_256_10.img,xvda,w" ] # # Hostname # name = 'vdns' # # Networking # dhcp = 'dhcp' vif = [ 'mac=00:16:3e:0a:34:f1,bridge=xenbr0' ] # # Behaviour # on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' vnc = 1 sdl = 0

Espacio de Código 4.2 Archivo de configuración de una Máquina Virtual.

4.2.2.4. Instalación con la herramienta virt-install

La herramienta virt-install suele venir por defecto en las distribuciones de CentOS, sin

embargo se la puede instalar con el paquete python-virtinst o también viene incluido

con las herramientas de administración y desarrollo de xen: xen-devel y virt-manager.

Una vez que se tiene instalada la herramienta se puede emplear el comando virt-

install.

# virt-install What is the name of your virtual machine? ejemploCentOS How much RAM should be allocated (in megabytes)? 256 What would you like to use as the disk (file path)? /vm/ejemploCentOS.img How large would you like the disk (/home/virtual/test01.img) to be (in gigabytes)? 10 Would you like to enable graphics support? (yes or no) no What is the install location? ftp://ftp.vserver.ec/pub/centos/5.2/os/i386/ Starting install...

Espacio de Código 4.3 Instalación de una Máquina Virtual con la herramienta virt-install

Entonces iniciará la descarga e instalación de la imagen de la distribución del Sistema

Operativo.

Figura 4.3 Instalación del servidor virtual base CentOS 5.2

Figura 4.4 Selección del disco para el particionamiento del servidor Base.

Figura 4.5 Esquema de particionamiento servidor virtual base.

Figura 4.6 Configuración general de la tarjeta de red del servidor base.

Figura 4.7 Selección de componentes de instalación en modo Server.

Figura 4.8 Selección de software de servidor base.

Para optimizar el rendimiento de las VM, se desactivarán los servicios innecesarios

como por ejemplo:

§ acpid

§ anacron

§ apmd

§ autofs

§ bluetooth

§ cups

§ firstboot

§ gpm

§ haldaemon

§ messagebus

§ mdmonitor

§ hidd

§ ip6tables

§ kudzu

§ lvm2-monitor

§ netfs

§ nfslock

§ pcscd

§ portmap

§ rpcgssd

§ rpcidmapd

§ smartd

§ yum-updatesd

Dependiendo del servidor virtual que se implemente, se deberá activar ciertos

servicios, esto se aplica de igual modo para configuraciones especiales de tamaño de

disco, memoria ram asignada, tarjetas de red, entre otras.

Finalmente se verifica el proceso de instalación:

Figura 4.9 Progreso de instalación de CentOS 5.2

Figura 4.10 Instalación final de CentOS 5.2

4.3. INSTALACIÓN Y CONFIGURACIÓN DEL DATACENTER DE

INFRAESTRUCTURA

La red de infraestructura se creó para albergar controladores de dominio donde se

ejecuta Linux CentOS 5.2, el servicio de directorio LDAP, DNS y DHCP. Según el

diseño del servidor virtualizado, la red de infraestructura también puede usarse para

contener servidores en los que se ejecuten componentes y objetos del negocio, en

este caso contiene al servidor de correo electrónico interno. Los servidores

correspondientes al datacenter de Infraestructura son:

§ Servidores de ruteo y proxy

§ DNS primario y secundario

§ DHCP

§ Directorio

§ Controlador de dominio

§ Correo electrónico (interno)

Figura 4.11 Datacenter de infraestructura

4.3.1. SERVIDORES DE RUTEO: ROUTER INTRANET, FIREWALL

PROXY Y ROUTER INTERNET

De acuerdo al esquema de la solución empleada, se requieren de tres servidores de

ruteo en el centro de datos. El primer servidor, denominado ROUTERINTRANET, es

el encargado de brindar el acceso a los servidores por parte de los usuarios en la

intranet de la empresa, además de brindar un nivel de seguridad básico mediante

ciertas políticas de firewall.

El otro servidor de ruteo es el denominado FIREWALLPROXY, a este servidor se

conectaran las tres zonas del centro de datos (datos, infraestructura y

desmilitarizada), este será el encargado del enrutamiento entre estas zonas,

cumpliendo las funciones de firewall y de proxy y brindando el aislamiento necesario

a la zona desmilitarizada.

Finalmente, el último servidor de ruteo es el denominado FIREWALLINTERNET el

cual será el encargado de brindar la protección de borde del centro de datos y

realizando las funciones de NAT (Network Address Translation) para permitir que el

tráfico que se dirija al exterior de la intranet de la empresa salga con una sola

dirección IP.

4.3.1.1. Software

Para los servidores de ruteo que se instalarán en el servidor virtualizado, se

necesitarán paquetes de software que brinden los servicios de: firewall, enrutamiento,

NAT, proxy y VPN.

El ROUTER INTRANET necesita un paquete de firewall y enrutamiento, el

FIREWALL PROXY necesita paquetes que cumplan las funciones de firewall,

enrutamiento y proxy, finalmente el FIREWALL INTERNET necesita firewall,

enrutamiento, NAT y VPN. Como en el presente punto se está analizando la zona de

infraestructura, no se tratará a mayor profundidad el FIREWALL INTERNET, el cual

se detallará en el punto 4.5., que trata de la zona desmilitarizada, por este motivo en

los siguientes puntos no se considerará las conexiones VPN.

4.3.1.1.1. Alternativas de software

· Firewall:

Para el caso del firewall, la opción por defecto que viene incluida en las distribuciones

de Linux es el paquete iptables, el cual se emplea para todos los requerimientos de

filtrado de paquetes a nivel del kernel y NAT.

No existen otras opciones destacadas para la configuración de firewalls, pero existen

paquetes adicionales que se pueden emplear como frontends de iptables, estos

frontends se ubican entre el usuario e iptables y buscan simplificar la configuración de

los firewalls, entre estos paquetes se encuentran: FWBuilder, Guarddog, Kmyfirewall,

Knetfilter, Firestarter, Shorewall, entre otros. Además de estos paquetes existen

scripts ya desarrollados para la configuración del firewall como es el caso de arno-

iptables-firewall.

· Proxy:

Para el caso del servicio de proxy, la opción más ampliamente usada en las

diferentes distribuciones de Linux es el paquete squid. Este paquete permite realizar

un gran número de configuraciones, todo mediante la modificación de un único

archivo de configuración, funciona como proxy HTTP/FTP y tiene soporte para ICP

(Internet Cache Protocol)

Otra solución disponible para un servidor proxy es untangle, que es un sistema

completo que brinda soluciones de firewall, proxy, DHCP y antivirus, sin embargo

este sistema no permite la instalación de aplicaciones adicionales y su

documentación no se encuentra tan ampliamente difundida como en el caso de squid.

También es factible emplear como proxy a Apache, el servidor web más utilizado, que

soporta el servicio de proxy para HTTP y FTP en un módulo separado.

4.3.1.1.2. Selección alternativa

· Firewall:

En el caso del firewall, la opción que se empleará es el paquete iptables debido a que

es la solución más ampliamente usada y documentada para los entornos GNU/Linux.

Además se debe recalcar que esta solución incluye la traducción de direcciones NAT

y al realizar el filtrado de paquetes a nivel del kernel tiene un excelente rendimiento.

También se decidió evitar el uso de frontends, debido a que no son paquetes

necesarios para el servicio por lo que solo vendrían a consumir los recursos del

sistema.

· Proxy:

En el caso del servicio de proxy, la opción que se empleará es el paquete squid,

debido a que es una solución exclusiva para proxy ampliamente documentada y

probada. El uso de soluciones como untangle y Apache resulta inadecuado debido a

que no son soluciones exclusivas para el servicio de proxy por lo que su instalación

significaría el instalar opciones innecesarias para estos tipos de servidores.

4.3.1.2.1. Instalación Máquina Virtual

El presente servidor virtual se basa en la plantilla de instalación de la VM basada en

GNU-Linux CentOS 5.2, en el que se incluyen los componentes necesarios como

Iptables, Networking y software de Routing y Proxy (Squid). El hostname configurado

es: routerintranet y firewallproxy respectivamente pertenecientes al FQDN97

routerintranet.vserver.ec y firewallproxy.vserver.ec.

4.3.1.2.2. Instalación Servicio

El servicio de iptables suele venir incluido en todas las distribuciones de Windows,

caso contrario para instalar basta ubicar el paquete correspondiente a iptables en el

administrador de paquetes o el emplear el comando yum install iptables, también se

puede descargar una copia del paquete de la página oficial del proyecto

http://www.netfilter.org/projects/iptables/index.html.

97 Fully Qualified Domain Name: nombre que incluye el nombre de la computadora y el nombre de dominio asociado a ese equipo.

Figura 4.12 Instalación de iptables mediante el comando yum install

De la misma forma, para instalar el paquete squid basta con ubicarlo en el

administrador de paquetes, emplear el comando yum install squid o descargarlo de la

página del proyecto http://www.squid-cache.org/.

Figura 4.13 Instalación de squid mediante el comando yum install.

4.3.1.3. Configuración

En este punto se detallarán la configuración de los dos servidores de enrutamiento

que se pueden considerar en la zona de infraestructura: routerintranet y firewallproxy.

En los dos servidores se deben configurar las características de firewall, pero solo en

el firewallproxy se configurará el servidor proxy.

4.3.1.3.1. Router Intranet

En el servidor routerintranet solo es necesario establecer las rutas que permitan el

enrutamiento de las direcciones y configurar un firewall que brinde seguridad.

Primeramente se configurarán las rutas, se necesita la creación de una ruta que

permita la llegada a la DMZ (red 10.0.2.0), es decir que se dirija al servidor

firewallproxy (10.0.1.1) y una ruta por defecto para las direcciones no conocidas, que

permitirá la llegada a internet. Con estos parámetros se procedió a configurar las

rutas que se muestran a continuación:

echo 1 >/proc/sys/net/ipv4/ip_forward route add -net 10.0.2.0 netmask 255.255.255.0 gw 10.0.1.1 route add -net default gw 10.0.1.1

Espacio de Código 4.4 Rutas del Servidor routerintranet

Para la configuración del firewall se procedieron a configurar las siguientes reglas de

filtrado de paquetes:

# Script de configuración de Iptables – DSCA, JJBS – vserver 2009. # Limpiar reglas del firewall iptables -X iptables -F # Establecer política DROP por default iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # Permitir tráfico en interfaz loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Permitir tráfico interno

iptables -A INPUT -i eth2 -j ACCEPT iptables -A OUTPUT -o eth2 -j ACCEPT # Permitir acceso de ciertos mensajes ICMP iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -d 10.0.0.254 --icmp-type 8 -j ACCEPT iptables -A OUTPUT -o eth0 -p icmp -s 10.0.0.254 -d 0.0.0.0/0 --icmp-type 0 -j ACCEPT iptables -A OUTPUT -o eth0 -p icmp -s 10.0.0.254 -d 0.0.0.0/0 --icmp-type 8 -j ACCEPT iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -d 10.0.0.254 --icmp-type 0 -j ACCEPT iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -d 10.0.0.254 --icmp-type 3 -j ACCEPT iptables -A OUTPUT -o eth0 -p icmp -s 10.0.0.254 -d 0.0.0.0/0 --icmp-type 3 -j ACCEPT iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -d 10.0.0.254 --icmp-type 4 -j ACCEPT iptables -A OUTPUT -o eth0 -p icmp -s 10.0.0.254 -d 0.0.0.0/0 --icmp-type 4 -j ACCEPT iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -d 10.0.0.254 --icmp-type 11 -j ACCEPT iptables -A OUTPUT -o eth0 -p icmp -s 10.0.0.254 -d 0.0.0.0/0 --icmp-type 11 -j ACCEPT iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -d 10.0.0.254 --icmp-type 12 -j ACCEPT iptables -A OUTPUT -o eth0 -p icmp -s 10.0.0.254 -d 0.0.0.0/0 --icmp-type 12 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 10.0.1.254 --icmp-type 8 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 10.0.1.254 -d 0.0.0.0/0 --icmp-type 0 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 10.0.1.254 -d 0.0.0.0/0 --icmp-type 8 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 10.0.1.254 --icmp-type 0 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 10.0.1.254 --icmp-type 3 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 10.0.1.254 -d 0.0.0.0/0 --icmp-type 3 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 10.0.1.254 --icmp-type 4 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 10.0.1.254 -d 0.0.0.0/0 --icmp-type 4 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 10.0.1.254 --icmp-type 11 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 10.0.1.254 -d 0.0.0.0/0 --icmp-type 11 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 10.0.1.254 --icmp-type 12 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 10.0.1.254 -d 0.0.0.0/0 --icmp-type 12 -j ACCEPT

# Permitir conexiones TCP y UDP válidas iptables -A OUTPUT -o eth0 -p tcp -s 10.0.0.254 --sport 1024: -d any/0 --dport :1023 -j ACCEPT iptables -A INPUT -i eth0 -p tcp -s any/0 --sport :1023 -d 10.0.0.254 --dport 1024: -j ACCEPT iptables -A OUTPUT -o eth0 -p udp -s 10.0.0.254 --sport 1024: -d any/0 --dport :1023 -j ACCEPT iptables -A INPUT -i eth0 -p udp -s any/0 --sport :1023 -d 10.0.0.254 --dport 1024: -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 10.0.1.254 --sport 1024: -d any/0 --dport :1023 -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 --sport :1023 -d 10.0.1.254 --dport 1024: -j ACCEPT iptables -A OUTPUT -o eth1 -p udp -s 10.0.1.254 --sport 1024: -d any/0 --dport :1023 -j ACCEPT iptables -A INPUT -i eth1 -p udp -s any/0 --sport :1023 -d 10.0.1.254 --dport 1024: -j ACCEPT # Rechazo protocolo IDENTD iptables -A INPUT -i eth0 -p tcp -s 0.0.0.0/0 -d 10.0.0.254 --dport 113 -j REJECT iptables -A INPUT -i eth1 -p tcp -s 0.0.0.0/0 -d 10.0.1.254 --dport 113 -j REJECT # Reglas de Forward TCP, UDP e ICMP iptables -A FORWARD -i eth2 -o eth0 -p tcp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p tcp -s ! 192.168.0.0/24 --sport :1023 -d 192.168.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth2 -o eth0 -p udp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p udp -s ! 192.168.0.0/24 --sport :1023 -d 192.168.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth2 -o eth0 -p icmp -s 192.168.0.0/24 -d ! 192.168.0.0/24 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p icmp -s ! 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p tcp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p tcp -s ! 192.168.0.0/24 --sport :1023 -d 192.168.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p udp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --

dport :1023 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p udp -s ! 192.168.0.0/24 --sport :1023 -d 192.168.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p icmp -s 192.168.0.0/24 -d ! 192.168.0.0/24 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p icmp -s ! 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT #Reglas para abrir algunos puertos iptables -A INPUT -i eth0 -p tcp -s any/0 --sport 1024: -d 10.0.0.254 --dport 22 -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp -s 10.0.0.254 --sport 22 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth0 -p tcp -s any/0 --sport 1024: -d 10.0.0.254 --dport 53 -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp -s 10.0.0.254 --sport 53 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth0 -p udp -s any/0 --sport 1024: -d 10.0.0.254 --dport 53 -j ACCEPT iptables -A OUTPUT -o eth0 -p udp -s 10.0.0.254 --sport 53 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth0 -p tcp -s any/0 -d 10.0.0.254 --dport 25 -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp -s 10.0.0.254 --sport 25 -d any/0 -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 --sport 1024: -d 10.0.1.254 --dport 22 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 10.0.1.254 --sport 22 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 --sport 1024: -d 10.0.1.254 --dport 53 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 10.0.1.254 --sport 53 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p udp -s any/0 --sport 1024: -d 10.0.1.254 --dport 53 -j ACCEPT iptables -A OUTPUT -o eth1 -p udp -s 10.0.1.254 --sport 53 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 -d 10.0.1.254 --dport 25 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 10.0.1.254 --sport 25 -d any/0 -j ACCEPT

Espacio de Código 4.5 Ejemplo de reflas para filtrado de paquetes en el routerintranet

4.3.1.3.2. Firewallproxy

En el servidor firewallproxy se debe configurar tanto las rutas necesarias como el

firewall con NAT y el servidor de proxy squid. Primeramente se presentarán las rutas

necesarias:

echo 1 >/proc/sys/net/ipv4/ip_forward route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.1.254 route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.1.254 route add -net 192.168.2.0 netmask 255.255.255.0 gw 10.0.1.254 route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.0.1.254 route add -net default gw 10.0.2.254

Espacio de Código 4.6 Rutas del Servidor firewallproxy

Para la configuración del firewall con la traducción NAT se procede a configurar las

siguientes reglas de filtrado de paquetes:

# Script de configuración de Iptables Nat – DSCA, JJBS – vserver 2009. iptables -t nat -A POSTROUTING -o eth1 -p tcp -s 10.0.1.0/24 --sport 1024: -d ! 10.0.1.0/24 --dport :1023 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth1 -p udp -s 10.0.1.0/24 --sport 1024: -d ! 10.0.1.0/24 --dport :1023 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth1 -p icmp -s 10.0.1.0/24 -d ! 10.0.1.0/24 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth1 -p tcp -s 192.168.0.0/24 --sport 1024: -d !

192.168.0.0/24 --dport :1023 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth1 -p udp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --dport :1023 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth1 -p icmp -s 192.168.0.0/24 -d ! 192.168.0.0/24 -j MASQUERADE # Reglas de Forward TCP, UDP e ICMP iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 10.0.0.0/24 --sport 1024: -d ! 10.0.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p tcp -s ! 10.0.0.0/24 --sport :1023 -d 10.0.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p tcp -s ! 192.168.0.0/24 --sport :1023 -d 192.168.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p udp -s 10.0.0.0/24 --sport 1024: -d ! 10.0.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p udp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p udp -s ! 10.0.0.0/24 --sport :1023 -d 10.0.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p udp -s ! 192.168.0.0/24 --sport :1023 -d 192.168.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p icmp -s 10.0.0.0/24 -d ! 10.0.0.0/24 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p icmp -s 192.168.0.0/24 -d ! 192.168.0.0/24 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p icmp -s ! 10.0.0.0/24 -d 10.0.0.0/24 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p icmp -s ! 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p tcp -s 10.0.1.0/24 --sport 1024: -d ! 10.0.1.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p tcp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p tcp -s ! 10.0.1.0/24 --sport :1023 -d 10.0.1.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p tcp -s ! 192.168.0.0/24 --sport :1023 -d 192.168.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p udp -s 10.0.1.0/24 --sport 1024: -d ! 10.0.1.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p udp -s 192.168.0.0/24 --sport 1024: -d ! 192.168.0.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p udp -s ! 10.0.1.0/24 --sport :1023 -d 10.0.1.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p udp -s ! 192.168.0.0/24 --sport :1023 -d 192.168.0.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p icmp -s 10.0.1.0/24 -d ! 10.0.1.0/24 -j ACCEPT iptables -A FORWARD -i eth2 -o eth1 -p icmp -s 192.168.0.0/24 -d ! 192.168.0.0/24 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p icmp -s ! 10.0.1.0/24 -d 10.0.1.0/24 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p icmp -s ! 192.168.0.0/24 -d 192.168.0.0/24 -j ACCEPT #Reglas para abrir puertos necesarios iptables -A INPUT -i eth1 -p tcp -s any/0 --sport 1024: -d 10.0.2.1 --dport 22 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 10.0.2.1 --sport 22 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 --sport 1024: -d 10.0.2.1 --dport 53 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 10.0.2.1 --sport 53 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p udp -s any/0 --sport 1024: -d 10.0.2.1 --dport 53 -j ACCEPT iptables -A OUTPUT -o eth1 -p udp -s 10.0.2.1 --sport 53 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 -d 10.0.2.1 --dport 25 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 10.0.2.1 --sport 25 -d any/0 -j ACCEPT

Espacio de Código 4.7 Configuraciones para filtrado de paquetes en el firewallproxy

Finalmente, para la configuración del proxy se debe modificar el archivo

/etc/squid/squid.conf, especificando el servidor proxy, el puerto en que se ejecutará,

las direcciones que pueden acceder a Internet, entre otros parámetros. Un archivo de

configuración común es similar al que se muestra a continuación:

# Ubicación del Proxy http_port 10.0.0.1:8080 icp_port 0 # Características de Caché cache_mem 32 MB cache_dir ufs /var/spool/squid 6000 16 256 cache_access_log /var/log/squid/access.log cache_log /var/log/squid/cache.log pid_filename /var/run/squid.pid # Creación de listas de control de acceso (ACL) acl all src 0.0.0.0/0.0.0.0 acl allowed_hosts src 192.168.0.0/255.255.255.0 #Permisos dados a las ACL http_access allow allowed_hosts http_access deny all icp_access deny all miss_access allow all cache_effective_user squid cache_effective_group squid snmp_port 0

Espacio de Código 4.8 Archivo de configuración squid.conf

En el espacio de código se puede apreciar que squid primeramente bloquea todo el

tráfico (deny all) y en las líneas superiores sólo da el permiso de acceder a las IP de

la lista allowed_hosts (192.268.0.0/24), este es un archivo de configuración genérico,

de acuerdo a las necesidades específicas de la empresa en la que se vaya a

implementar el servidor virtualizado se pueden añadir listas de control de acceso con

sus respectivos permisos.

4.3.2. SERVIDOR DNS

Según el esquema de solución planteado, el centro de datos dispondrá de cuatro

servidores DNS, un servidor primario y uno secundario se ubican en la zona de

infraestructura y otros servidores primario y secundario se ubican en la zona

desmilitarizada.

4.3.2.1. Software

Como tanto los servidores primarios y secundarios se deben de configurar con el

mismo paquete de software, al igual que los servidores de la zona de infraestructura y

la desmilitarizada, solo se necesita seleccionar un paquete de software que se

instalará en los cuatro servidores, requiriéndose solamente cambios mínimos en la

configuración de los mismos.

La principal alternativa para configurar un servidor de nombres de dominio es

mediante el paquete bind, el cual es indiscutiblemente el más usado en los servidores

de dominio, del que más documentación se puede obtener y un estándar de-facto en

los sistemas Unix.

Pese a la gran aceptación de bind, existen otras alternativas al paquete, como por

ejemplo PowerDNS y Unbound, soluciones gratuitas que no están tan ampliamente

difundidas. PowerDNS es una buena opción para servidores autoritativos, es decir

para responder consultas del dominio que le corresponde, sin embargo las funciones

de servidor recursivo, para consultas de otros dominios, se deben instalar por

separado. Por otro lado Unbound no realiza funciones de servidor autoritativo, sino

que solo realiza consultas recursivas y actúa como servidor de caché.

La opción que se empleará para todos los servidores DNS del centro de datos será el

paquete bind. La razón para esta elección es que es la solución más ampliamente

probada y sobre la que existe mayor documentación, realizando tanto funciones de

servidor autoritativo como de recursivo.

Para la instalación de la VM correspondiente se toma como base la instalación del

servidor virtual indicado en el punto 4.2.1.5, en el que se incluyen los componentes

del servidor DNS Bind sobre un servidor GNU-Linux CentOS 5.2. El hostname

configurado es: dnsiprimario (DNS principal) y dnsisecundario (DNS de backup)

pertenecientes al FQDN dnsiprimario.vserver.ec y dnsisecundario.vserver.ec

respectivamente.

La instalación del servicio Bind se puede realizar añadiendo el paquete en la

administrador de paquetes, empleando el comando yum install bind o simplemente

mediante la descarga del paquete de la página del proyecto en

https://www.isc.org/downloadables/11.

Figura 4.14 Instalación de bind mediante el comando yum install.

En la zona de infraestructura se disponen de dos servidores DNS que actuaran como

servidor DNS primario y secundario. En cada servidor DNS se debe configurar el

archivo named.conf que es el archivo de configuración y sus correspondientes

archivos de zona de nombres, zonas de IP y zonas locales a los que hace referencia

named.conf.

Para dar mayor seguridad a los servidores de dominio, se decidió también instalar el

paquete bind-chroot, este paquete permite que el demonio named se ejecute en un

ambiente enjaulado, lo que hace que los archivos de configuración de bind ya no se

encuentren en su ubicación original de /etc/named, sino en /var/named/chroot/.

4.3.2.3.1. Dnsiprimario

Como su nombre lo indica el servidor dnsiprimario corresponde al servidor de

nombres primario de la intranet, es decir de la zona de infraestructura. El archivo de

configuración principal es /var/named/chroot/etc/named.conf y su configuración se

muestra a continuación:

# Archivo de configuración named.conf. – DSCA , JJBS – vserver.ec 2009. options { directory "/var/named"; forward only; forwarders { 10.0.2.5; 10.0.2.6; } ; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "vserver.ec" IN { type master; file "named.vserver.ec"; allow-update { none; }; allow-query { any; }; allow-transfer { 10.0.1.3; }; }; zone "1.0.10.in-addr.arpa" IN { type master; file "named.10.0.1"; allow-update { none; }; allow-query { any; }; allow-transfer { any; }; }; zone "0.0.10.in-addr.arpa" IN { type master; file "named.10.0.0"; allow-update { none; }; allow-query { any; }; allow-transfer { any; }; }; zone "2.0.10.in-addr.arpa" IN { type master; file "named.10.0.2"; allow-update { none; };

allow-query { any; }; allow-transfer { any; }; }; zone "0.168.192.in-addr.arpa" IN { type master; file "named.192.168.0"; allow-update { none; }; allow-query { any; }; allow-transfer { any; }; }; zone "2.168.192.in-addr.arpa" IN { type master; file "named.192.168.2"; allow-update { none; }; allow-query { any; }; allow-transfer { any; }; }; zone "0.16.172.in-addr.arpa" IN { type master; file "named.172.16.0"; allow-update { none; }; allow-query { any; }; allow-transfer { any; }; }; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; allow-query { any; }; allow-transfer { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; allow-update { none; }; allow-query { any; }; allow-transfer { none; }; }; include "/etc/rndc.key";

Espacio de Código 4.9 Archivo de configuración DNS primario named.conf

A continuación se muestran los archivos de zonas

/var/named/chroot/var/named.vserver.ec:

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102412 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum

IN NS dnsiprimario.vserver.ec. IN MX 10 mailempresarial.vserver.ec. firewallproxy-datos IN A 10.0.0.1 basededatos IN A 10.0.0.2 webempresarial IN A 10.0.0.3 impresion IN A 10.0.0.4 servidordearchivos IN A 10.0.0.5 ftp IN A 10.0.0.6 routerintranet-datos IN A 10.0.0.254 firewallproxy IN A 10.0.1.1 dnsiprimario IN A 10.0.1.2 dnsisecundario IN A 10.0.1.3 directorio IN A 10.0.1.4 mailempresarial IN A 10.0.1.5 dhcp IN A 10.0.1.6 routerintranet-infraestructura IN A 10.0.1.254 firewallproxy-dmz IN A 10.0.2.1 webinternet IN A 10.0.2.2 mailgateway IN A 10.0.2.3 comercioelectronico IN A 10.0.2.4 dnseprimario IN A 10.0.2.5 dnsesecundario IN A 10.0.2.6 firewallinternet-dmz IN A 10.0.2.254 routerintranet-0 IN A 192.168.0.1 routerintranet-2 IN A 192.168.2.1 mainserver IN A 192.168.0.99 danielserver-lan IN A 192.168.0.98 danielserver-wlan IN A 192.168.2.102 routerinternet IN A 172.16.0.2 firewallinternet IN A 172.16.0.1

Espacio de Código 4.10 Archivo de zona de nombres primario named.vserver.ec

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102402 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. 1 IN PTR firewallproxy-datos.vsever.ec. 2 IN PTR basededatos.vserver.ec. 3 IN PTR webempresarial.vserver.ec. 4 IN PTR impresion.vserver.ec. 5 IN PTR servidordearchivos.vserver.ec. 6 IN PTR ftp.vserver.ec. 254 IN PTR routerintranet-datos.vserver.ec.

Espacio de Código 4.11 Archivo de zona IP named.10.0.0

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102402 ; Serial 28800 ; Refresh

14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. 1 IN PTR firewallproxy.vsever.ec. 2 IN PTR dnsiprimario.vserver.ec. 3 IN PTR dnsisecundario.vserver.ec. 4 IN PTR directorio.vserver.ec. 5 IN PTR mailempresarial.vserver.ec. 6 IN PTR dhcp.vserver.ec. 254 IN PTR routerintranet-infraestructura.vserver.ec.

Espacio de Código 4.12 Archivo de zona IP primario named.10.0.1

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102401 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. 1 IN PTR firewallproxy-dmz.vsever.ec. 2 IN PTR webinternet.vserver.ec. 3 IN PTR mailgateway.vserver.ec. 4 IN PTR comercioelectronico.vserver.ec. 5 IN PTR dnseprimario.vserver.ec. 6 IN PTR dnsesecundario.vserver.ec. 254 IN PTR firewallinternet-dmz.vserver.ec.

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102406 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. 1 IN PTR routerintranet-0.vserver.ec. 98 IN PTR danielserver-lan.vserver.ec. 99 IN PTR mainserver.vserver.ec.

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102408 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. 1 IN PTR routerintranet-2.vserver.ec.

102 IN PTR danielserver-wlan.vserver.ec.

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102403 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. 1 IN PTR firewallinternet.vserver.ec. 2 IN PTR routerinternet.vserver.ec.

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102401 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. 1 IN PTR localhost.

Espacio de Código 4.17 Archivo de zona local primario named.local

$TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102401 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. localhost. IN A 127.0.0.1

Espacio de Código 4.18 Archivo de zona local primario localhost.zone

4.3.2.3.2. Dnsisecundario

Como su nombre lo indica el servidor dnsisecundario corresponde al servidor de

nombres secundario de la intranet, es decir de la zona de infraestructura. El archivo

de configuración principal es /var/named/chroot/etc/named.conf y su configuración se

muestra a continuación:

# Archivo de configuración named.con dnsisecundario, - DSCA , JJBS – vserver.ec 2009. options { directory "/var/named"; forward only; forwarders { 10.0.2.5; } ; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "vserver.ec" IN { type slave; file "named.vserver.ec.bck"; masters { 10.0.1.2; }; }; zone "1.0.10.in-addr.arpa" IN { type slave; file "named.10.0.1.bck"; masters { 10.0.1.2; }; }; zone "0.0.10.in-addr.arpa" IN { type slave; file "named.10.0.0.bck"; masters { 10.0.1.2; }; }; zone "2.0.10.in-addr.arpa" IN { type slave; file "named.10.0.2.bck"; masters { 10.0.1.2; }; }; zone "0.168.192.in-addr.arpa" IN { type slave; file "named.192.168.0.bck"; masters { 10.0.1.2; }; };

zone "0.16.172.in-addr.arpa" IN { type slave; file "named.172.16.0.bck"; masters { 10.0.1.2; }; }; zone "localhost" IN { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" IN {

type master; file "named.local"; }; include "/etc/rndc.key";

Espacio de Código 4.19 Archivo de configuración DNS secundario named.conf

$TTL 86400 @ IN SOA dnsisecundario.vserver.ec. root.dnsisecundario.vserver.ec. ( 2009102401 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsisecundario.vserver.ec. 1 IN PTR localhost.

Espacio de Código 4.20 Archivo de zona local secundario named.local

$TTL 86400 @ IN SOA dnsisecundario.vserver.ec. root.dnsisecundario.vserver.ec. ( 2009102401 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsisecundario.vserver.ec. localhost. IN A 127.0.0.1

4.3.3. SERVIDOR DHCP

El servidor DHCP permitirá la configuración automática de los parámetros de

dirección IP, máscara de red, dirección de broadcast, gateway, las direcciones de

DNS, entre otros. El servicio DHCP acelerará y facilitará la configuración de muchos

ordenadores en la red de usuarios de la PyME, evitando en gran medida los posibles

errores humanos.

4.3.3.1. Software

Para le implementación del servidor de DHCP, se requieren opciones de software que

permitan configurar parámetros como los siguientes:

§ Configuración de servicio para múltiples redes.

§ Soporte de Dhcp relay.

§ Asignación de direcciones por dirección MAC.

§ Configuración de nombres de dominio.

§ Trabajo con DNS para agregación dinámica de hosts en registros dns.

A continuación se presentan tres alternativas de software para configuración del

servidor dhcp. Las opciones escogidas se realizaron en función de su difusión y

soporte.

Característica Tiny DHCP Server

DHCP Server ISC

Dual DHCP DNS Server

Sistema Operativo Windows 95

o superior GNU – Linux GNU - Linux

Gratuito Ö Ö Configuración de servicio para múltiples redes

Ö Ö Ö

Soporte Dhcp relay Ö Ö Ö Asignación de direcciones por dirección MAC

Configuración de nombres de dominio Ö Ö Ö Trabajo con DNS para agregación dinámica de hosts en registros dns.

Tabla 4.3 Alternativas de software para dhcp.

De las alternativas antes mencionadas, dos de ellas se ajustan a los requerimientos

establecidos para las PyMEs tanto desde el punto de vista económico como desde le

punto de vista técnico. Estas alternativas son DHCP Server ISC y Dual DHCP DNS

Server.

Se ha escogido la opción de DHCP Server ISC por cuanto constituye la versión más

usada en servidores Linux y cuenta con la mayor cantidad de documentación de

soporte para configuración, mantenimiento y resolución de conflictos. Además su

larga trayectoria de uso muestra ser una alternativa robusta y de fácil configuración.

4.3.3.2.1. Instalación Máquina Virtual y Servicio

La instalación del servidor virtual basa su funcionamiento en la distribución CentOS

5.2 siguiendo el proceso ya visto en los servidores anteriores.

La instancia de VM tiene su archivo de configuración localizado en el archivo

dhcp.conf (/etc/xen/dhcp.conf).

Ésta distribución de Linux nos permite incluir en su proceso de instalación al servidor

DHCP Server ISC. Utilizando la herramienta de instalación yum, este procedimiento

también puede ser realizado como se muestra a continuación:

Figura 4.15 Instalación del Servidor de DHCP con la herramienta yum.

La instalación incluye el agente dhcrelay que nos permitirá la configuración del

servicio para múltiples redes. Este agente se instalará en el servidor de routerintranet

que da la cara a la red interna de la PyME. El hostname configurado es: dhcp

perteneciente al FQDN dhcp.vserver.ec.

4.3.3.3.1. Archivo de configuración dhcpd.conf

El servidor DHCP usar el archivo de configuración dhcpd.conf

(/etc/sysconfig/dhcpd.conf). En el archivo de configuración se especifican los

parámetros de rango de direcciones IP, gateways, direcciones DNS, etc. En el

archivo se especifica además la asignación de direcciones fijas de acuerdo a la

dirección MAC de las máquina indicadas por la organización de acuerdo a sus

requerimientos.

En el prototipo se configura la asignación de direcciones de las redes: 192.168.0.x,

192.168.2.x, 192.168.4.x para uso de las diferentes áreas administrativas de las

PyMEs.

Estos parámetros pueden ser fácilmente modificados de acuerdo a características

específicas de la organización.

A continuación se muestra el archivo de configuración:

# # DHCP Server Configuration file. # see /usr/share/doc/dhcp*/dhcpd.conf.sample max-lease-time 3600; default-lease-time 600; ddns-update-style none; ddns-updates off; option domain-name "vserver.ec"; option domain-name-servers 10.0.1.2, 10.0.1.3; # Gerencia subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.1; option subnet-mask 255.255.255.0; range 192.168.0.100 192.168.0.199;

# Subgerente host host subgerente { hardware ethernet 00:21:91:79:6b:2c; fixed-address 192.168.0.99; }

# Gerente host host gerente { hardware ethernet 00:23:8b:90:dc:cf; fixed-address 192.168.0.98; } } # Ventas subnet 192.168.2.0 netmask 255.255.255.0 { option routers 192.168.2.1; option subnet-mask 255.255.255.0; range 192.168.2.100 192.168.2.199; # Vendedor host host vendedor { hardware ethernet 00:24:2c:05:d1:65; fixed-address 192.168.2.102; } } # Contabilidad subnet 192.168.4.0 netmask 255.255.255.0 { option routers 192.168.4.1; option subnet-mask 255.255.255.0; range 192.168.4.100 192.168.4.199; # Contador host host contador { hardware ethernet 00:1c:c0:22:60:63; fixed-address 192.168.4.99; } } subnet 10.0.1.0 netmask 255.255.255.0 { }

Espacio de Código 4.22 Archivo de configuración dhcpd.conf

4.3.3.3.2. Configuración dhcrelay

La opción de dhcrelay, permite la asignación de rangos de direcciones IP a múltiples

redes en donde el servidor dhcp no se encuentre directamente conectado. El proceso

de broadcast característico de un cliente dhcp, enviará su solicitud hasta el

routerintranet en donde se encuentra instalado el dhcrelay. Este servicio permitirá re

direccionar la solicitud hacia el servidor dhcp (10.0.0.6) posibilitando asignar

direcciones de las redes 192.168.0.x, 192.168.2.x y 192.168.4.x

Figura 4.16 Routerintranet actuando como dhcrelay.

El archivo de configuración es /etc/sysconfig/dhcrelay. En éste configuramos la

dirección del servidor dhcp (10.0.1.6) y las interfaces del servidor routerintranet por

las que escuchará: eth2, eth3, eth4, correspondientes a la red corporativa.

# Archivo de configuración dhcrelay # Interfaces por las que escucha las peticiones dhcp INTERFACES="eth2 eth3 eth4" # Direccion ip del servidor dhcp DHCPSERVERS="10.0.1.6"

Espacio de Código 4.23 Archivo de configuración dhcrelay.

4.3.4. SERVIDOR DE CORREO ELECTRÓNICO

El servidor de correo electrónico permitirá a la PyME el contacto electrónico entre los

diferentes actores involucrados en su actividad organizativa y comercial. El servicio

proporcionado debe estar implementado de tal manera que garantice el objetivo que

es la comunicación escrita por correo a la vez que se brinde la protección de Correo

Basura (Spam), virus, y demás amenazas electrónicas.

4.3.4.1. Software

Entre las alternativas de software se debe distinguir entre software para el envío de

correo MTA´s98 y de recepción.

Entre las alternativas de MTA´s se tiene las siguientes:

MTA´s Características

Configuración automática para cada máquina. Control de Relay (retransmisión): acaba con los reenvíos o retransmisiones que usuarios externos sin autorización hacen gracias a nuestra máquina. Reconocimiento automático de direcciones IP locales. Tratamiento instantáneo de los mensajes que se agregan a la cola. Encolamiento automático seguro (no se pierde correo en caso de que el sistema falle). Filtrado condicional.

Sendmail

Ha mejorado enormemente seguridad y funcionamiento a partir del 2000, y ha adquirido nuevas características. Es instalado por defecto en la mayoría de los sistemas operativos del Unix comercial. Trabaja con poco o nada de modificación con las configuraciones por defecto. Es un nombre conocido de MTA, dado su trayectoria Entrega inmediata de mensajes. Cambio de direccionamiento inmediato. Interacción con el DNS a través de registros MX. Las máquinas pueden ser renombradas o movidas y la entrega de mensajes es procesada normalmente. Es el servidor de mail más popular de todo el mundo UNIX. Permite el uso de "alias" entre los usuarios del sistema; lo posibilita (entre otras funciones) crear y mantener listas de correo entre grupos. Ejecución como agente de usuario (MUA). Uso de la plataforma de mensajería unificada confiable ( TrUMP - Trusted Unified Messaging Platform) Soporte para autenticación. Soporte para ipv6. Tipo de licenciamiento.

Postfix

Diseño modular (no es un único programa monolítico). La seguridad ha sido un condicionante desde el comienzo de su diseño. El rendimiento (se diseñó pensando que algún día habría sitios necesitaran procesar gran cantidad de mensajes al día).

98 Mail Transfer Agent: Agente de transferencia (agente de transferencia de correo)

Soporte para las tecnologías más usadas hoy día: LDAP, Bases de datos (MySQL), autentificación mediante SASL, LMTP, etc. Estricto cumplimiento de los estándares de correo-e Soporte muy bueno para dominios virtuales. Facilidad de configuración. Compatibilidad hacia/desde fuera con Sendmail (.forward, aliases, suplanta mailq, newaliases, /usr/lib/sendmail con versiones equivalentes). Abundante documentación, y de calidad. Fácil integración con antivirus. Uso sencillo de listas negras. Soporta direccionamiento con IPv6 Filtrado de cabeceras y cuerpos de mensajes por expresiones regulares.

Tabla 4.4 Alternativas de software MTA´s. Fuente: http://gluc.unicauca.edu.co/wiki/index.php/Documentaci%C3%B3n_MTAs_y_Tabla_comparativa

Entre las alternativas de software para la recepción de correo se tienen algunas

distribuciones entre las que se puede destacar qpop y dovecot; sin embargo la más

difundida en el software libre es dovecot y entre las características principales que

brinda éste son el soporte de los protocolos pop3, pop3s, imap e imaps de fácil

configuración.

Para el prototipo de servidor virtualizado para PyMEs se ha optado por la alternativa

Sendmail – Dovecot. Si bien Postfix es una alternativa muy sólida y de muy buenas

características, el trabajo con Sendmail es suficiente para las PyMEs – considerando

el flujo de información analizado en el capítulo 2, y al instalarlo en conjunto con Sasl,

MailScanner y Clamav constituye una alternativa estable y segura con control de

correo basura spam, virus y autentificación SMTP.

El servidor virtual de correo electrónico brinda el servicio intranet corporativa a través

del servidor Mailempresarial y su servicio se extiende para su envío a otros dominios

a través del Gateway de correos Mailgateway.

La máquina virtual incluye el servicio de Sendmail y Dovecot sobre una distribución

de Linux CentOS 5.2 en base a la plantilla de VM.

El hostname configurado para el servidor de correo corporativo es: mailempresarial

perteneciente al FQDN mailempresarial.vserver.ec.

El servicio Sendmail puede ser instalado fácilmente incluyéndolo como servidor

dentro del programa de instalación de CentOS 5.2. De igual manera puede ser

instalado con la herramienta yum mediante el comando yum install, así

yum -y install sendmail sendmail-cf dovecot m4

Figura 4.17 Instalación de Sendmail y sus dependencias con la herramienta yum.

Con ello se instala sendmail, sendmail-cf, dovecot y el procesador de macros m4

necesario para la configuración de Sendmail junto a dependencias específicas.

Sendmail utiliza los siguientes archivos de configuración:

Filename Función /etc/mail/access Base de datos de accesos de sendmail /etc/mail/aliases Carpeta de alias /etc/mail/local-host-names

Listados de máquinas para las que sendmail acepta correo

/etc/mail/mailer.conf Configuración del programa de correo /etc/mail/mailertable Tabla de entregas de correo /etc/mail/sendmail.cf Archivo de configuración principal de sendmail /etc/mail/virtusertable Usuarios virtuales y tablas de dominio

Tabla 4.5 Archivos de configuración de Sendmail.

4.3.4.3.1. Mailempresarial

Para la configuración del servidor de correo empresarial, se editará el archivo de

configuración de Sendmail correspondiente a /etc/mail/sendmail.mc; en este archivo

se editan las siguientes líneas de la siguiente manera, presentándose a continuación

un extracto99:

dnl # Archivo de configuración Sendmail – DSCA, JJBS – vserver.ec 2009 dnl # CONFIGURACIÓN COMO SMART HOST A mailgateway.vserver.ec define(`SMART_HOST', `mailgateway.vserver.ec')dnl dnl # LíNEA COMENTADA PARA PERMITIR ACEPTAR EMAIL DESDE INTERNET Y LA INTRANET dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl dnl # CORREOS ENVIADOS CON OTRO NOMBRE DE DOMINIO SERÁN ENMASCARADOS MASQUERADE_DOMAIN (vserver.ec)dnl

Espacio de Código 4.24 Archivo de configuración sendmail.mc

La finalidad de configurar a mailgateway como Smart Host es para cumplir su función

como agente MTA para el envío de correo electrónico hacia Internet.

99 Código completo puede encontrarse en anexo J.

Finalmente es necesario ejecutar el editor de macros m4 para la creación del archivo

sendmail.cf.

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Para la configuración del acceso de envío de correos se modifica el archivo

/etc/mail/access y /etc/mail/local-host-names, donde se agregan las direcciones IP de

las personas que van a poder entregar correo al exterior (a hotmail, yahoo, etc...) o a

su vez el dominio en este caso vserver.ec:

# Archivo /etc/mail/local-host-names # Dominios locales de los cuales se acepta el envío de correo vserver.ec

Espacio de Código 4.25 Archivo de configuración local-host-names.

# Se permite el envío de correos para las máquinas del dominio vserver.ec # Check the /usr/share/doc/sendmail/README.cf file for a description # of the format of this file. (search for access_db in that file) # The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc # package. # # by default we allow relaying from localhost... Connect:localhost.localdomain RELAY Connect:localhost RELAY Connect:127.0.0.1 RELAY vserver.ec RELAY

Espacio de Código 4.26 Archivo de configuración access.

Cabe indicar que se debe configurar en el servidor dns los registros correspondientes

de las máquinas de la red interna con el dominio vserver.ec garantizando así su envío

y seguridad del Relay.

Cuando se actualiza este fichero se debe ejecutar make dentro de /etc/mail/ para que

se actualice la base de datos.

Para el manejo de SMTP autentificado se inicia el servicio saslauthd y se descomenta

la siguiente línea en el archivo sendmail.mc

dnl # Activar servicio SMTP autentificado TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

Espacio de Código 4.27 Activación del servicio SMTP autentificado

El servicio SMTP autentificado agrega una capa más de seguridad para evitar el uso

de nuestro MTA como generador de correo no autorizado.

En cuanto a la configuración de Dovecot, se debe editar el archivo de configuración

/etc/dovecot.conf, y en la línea "Protocols" especificar los protocolos (pop3, pop3s,

imap).

# Archivo de configuración /etc/dovecot.conf – DSCA, JJBS – vserver 2009 # Configuración de los protocolos para recpeción de correo protocols = pop3 pop3s imap

Espacio de Código 4.28 Archivo de configuración dovecot.conf

Con esto se permite el uso de los protocolos pop3 e imap.

Para la configuración e instalación de los complementos de sendmail: Mail Scanner y

Clamav el proceso es el siguiente:

Para la instalación de clamav, se descarga el archivo binario de la web:

http://sourceforge.net/projects/clamav/files/clamav/0.95.3/clamav-

0.95.3.tar.gz/download con la versión clamav-0.95.3

Es necesaria la agregación del usuario y grupo clamav. Para mantener actualizada la

base de virus se realiza un cron diario que haga referencia al archivo freshclam.

Para la instalación de Spamassassin se lo descarga de los repositorios por defecto

del sistema mediante:

rpm –ihv spamassassin*

Para la instalación del MailScanner se descarga el archivo rpm de la web

http://www.mailscanner.info/downloads.html

Para la configuración, el archivo correspondiente es

/etc/MailScanner/MailScanner.conf

Y se editan los parámetros más importantes como son:

# Configuración de MailScanner – DSCA, JJBS – vserver 2009 %org-name% = vserver %org-long-name% = Virtualserver %web-site% = www.vserver.ec %etc-dir% = /etc/MailScanner %report-dir% = /etc/MailScanner/reports/es # Se indica el software antivirus con el que se trabajará Virus Scanners = clamav # Se indicant las listas de spam a tomar en cuenta Spam List = SBL + XBL + SORBS + spamhaus-ZEN # Correo spam será enviado a la cuenta spam Spam Actions = forward spam@vserver.ec # Valor mínimo para ser considerado spam Required SpamAssassin Score = 5.5 # Valor máximo para no ser eliminado el mensaje spam High SpamAssassin Score = 10

Espacio de Código 4.29 Archivo de configuración de MailScanner

Con ello el servicio a administrar será MailScanner, el cual levanta y baja el servicio

Sendmail.

4.3.5. SERVIDOR DE DIRECTORIO

El servicio de directorio se empleará para mantener un registro de la información

sobre los usuarios de la red de ordenadores de la empresa, al igual que sobre los

recursos de red, de esta manera se logra facilitar a los administradores la gestión de

acceso de usuarios a los recursos de la red. En el centro de datos diseñado, este

servicio se ubicará en la red de infraestructura

4.3.5.1. Software

Existen diversas soluciones de software que permiten brindar un servicio de directorio

centralizado, en el caso de una red para pequeñas y medianas empresas lo más

importante es el mantener una lista actualizada de los usuarios que tiene la red y sus

respectivos permisos para brindar un alto grado de escalabilidad, permitiendo el

crecimiento de la empresa de una manera sencilla y controlada sin la necesidad de

configurar cada equipo por separado.

Existen diversas alternativas para la implementación de este tipo de servicio, estando

basadas la mayoría de implementaciones en el estándar X.500. La solución más

empleada para los sistemas Windows es Active Directory, mientras que para entornos

UNIX se suele usar el paquete OpenLDAP. También se disponen de otras soluciones

menos empleadas como Lotus Domino o Red Hat Directory Server.

Todas las soluciones presentadas se basan en el protocolo LDAP por lo que

presentan un funcionamiento similar, disponiendo de buenas características en su

desempeño. Es importante señalar que los paquetes de Active Directory y OpenLDAP

son de los que más documentación hay disponible y que los paquetes Active

Directory y Lotus Domino son directorios propietarios que requieren la compra de la

solución.

Para la implementación del servicio de directorio se empleará el paquete OpenLDAP,

esto debido a su amplia documentación y a sus características de código abierto, lo

que permite un costo muy inferior al de las otras soluciones disponibles.

El servidor de directorio se basa en una instalación de GNU-Linux CentOS 5.2 con el

software OpenLDAP instalado. Su FQDN es: directorio.vserver.ec.

Para el funcionamiento de OpenLDAP se deben de instalar los paquetes de

openldap, openldap-servers y openldap-clients. Dicha instalación se puede realizar

añadiendo los paquetes en la administrador de paquetes, empleando el comando

yum install o descargando los paquetes de la página http://www.openldap.org/.

Figura 4.18 Instalación de openldap mediante el comando yum install

Figura 4.19 Instalación de openldap-servers mediante el comando yum install

Figura 4.20 Instalación de openldap-clients mediante el comando yum install

Para la configuración del servicio de directorio se emplearán los paquetes OpenLDAP

y gq como cliente gráfico de LDAP. Primeramente para la configuración del servidor

se debe ubicar su archivo de configuración llamado /etc/openldap/slapd.conf.

4.3.5.3.1. Archivo de configuración

Lo primero que se debe hacer para la configuración del equipo es acceder al archivo

/etc/openldap/slapd.conf y verificar que solamente se encuentren incluidos los

esquemas necesarios (core, cosine, inetorgperson, nis y misc), una vez que se han

incluido estos esquemas se deben agregar líneas de autenticación y cambiar los

parámetros suffix, rootdn y rootpwcomo como se muestra a continuación:

# Lista de esquemas incluidos include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema # Líneas de autenticación access to attrs=userPassword by self write

by anonymous auth by dn.base="uid=root,ou=People,dc=vserver,dc=ec" write by * none access to attrs=gecos by self write by dn.base="uid=root,ou=People,dc= vserver,dc=com" write by * read access to attrs=loginShell by self write by dn.base="uid=root,ou=People,dc= vserver,dc=com" write by * read access to * by dn.base="uid=root,ou=People,dc= vserver,dc=com" write by * read #Cambios adicionales suffix "dc= vserver,dc=com" rootdn "uid=root,ou=People,dc= vserver,dc=com" rootpw secret

Espacio de Código 4.30 Cambios en el archivo de configuración slapd.conf

Una vez realizados estos cambios se debe cambiar el archivo

/usr/share/openldap/migration/migrate_common.ph para asegurar que el dominio de

correo sea el indicado (vserver.ec) al igual que el sufijo base.

$DEFAULT_MAIL_DOMAIN = "example.com"; $DEFAULT_BASE = "dc=example,dc=com";

Espacio de Código 4.31 Cambios en el archivo de migración migrate_common.ph

4.4. INSTALACIÓN Y CONFIGURACIÓN DEL DATACENTER DE

La red de datos se creó para albergar los servidores que proporcionan la información

del negocio. Los sistemas de servicios de fondo contienen el almacenamiento de los

datos de las aplicaciones o bien proporcionan la conectividad con otros sistemas que

mantienen los recursos de datos. La base para los servidores virtuales es una

distribución de GNU-Linux CentOS 5.2.

Figura 4.21 Datacenter de datos.

Los servidores que forman parte del datacenter de datos son:

§ Base de datos

§ Web empresarial

§ Impresión

§ Servidor de archivos

§ Ftp

4.4.1. SERVIDOR DE BASE DE DATOS

La base de datos es uno de los principales servicios de la empresa ya que

almacenará todo tipo de información concerniente a la misma. Este servidor se

encuentra protegido por el firewall en el servidor routerintranet de conexiones

indeseadas provenientes de la red interna y por el firewall del servidor firewallproxy

de conexiones indeseadas provenientes de la zona desmilitarizada.

4.4.1.1. Software

Para la implementación de un servidor de base de datos se requiere de un sistema

administrador de base de datos (DBMS, por sus siglas en inglés), estos sistemas son

una interfaz entre el usuario y las bases de datos que maneja.

Existen muchas opciones para la administración de bases de datos, siendo algunas

soluciones libres como: MySQL, PostgreSQL, entre otros; y algunos propietarios o

privados como: Oracle, Microsoft SQL Server, FoxPro, entre otros.

MySQL es uno de los gestores más usados siendo un sistema de gestión de base de

datos relacional, multihilo y multiusuario. Las bases de datos MySQL son muy rápidas

en la lectura y consumen muy pocos recursos del sistema, y además presentan una

gran facilidad de instalación y configuración.

Por otro lado PostgreSQL es un sistema que presenta gran escalabilidad mucho

mayor que la de MySQL, pero de la misma forma genera una gran carga para los

recursos del sistema.

La opción elegida para el servicio de base de datos es MySQL, esto es debido a que

se ha considerado que el gestor PostgreSQL consume gran cantidad de recursos lo

que le puede llevar a ser de dos a tres veces más lento que MySQL100, además pese

a que MySQL no posee la gran escalabilidad de PostgreSQL, es capaz de soportar

inmensas bases de datos como las de Facebook101 y Wikipedia102, siendo mucho más

que suficiente para una pequeña o mediana empresas.

100 Datos tomados del artículo PostgreSQL vs. MySQL de Daniel Pecos que se puede encontrar en la página web http://www.netpecos.org/docs/mysql_postgres/x108.html.

101 Según los artículos en las páginas web: http://blog.facebook.com/blog.php?post=7899307130 y http://gigaom.com/2008/04/25/facebooks-insatiable-hunger-for-hardware/

El servidor de base de datos se basa en la instalación base de GNU-Linux CentOS

5.2 sobre la cual se han instalado los componentes de MySQL necesarios. Su FQDN

es: basededatos.vserver.ec.

La instalación del servicio MySQL se puede realizar añadiendo el paquete en la

administrador de paquetes, empleando el comando yum install mysql o simplemente

mediante la descarga del paquete de la página del proyecto en

http://www.mysql.com/?bydis_dis_index=1.

Figura 4.22 Instalación de MySQL mediante el comando yum install

102 Según artículo en la página web http://meta.wikimedia.org/wiki/Wikimedia_servers#Overall_system_architecture

El primer paso para configurar una base de datos es el asignar una clave al usuario

root, para esto se emplea el comando:

mysqladmin -u root password nueva-clave-de-acceso

A partir de este momento ya no basta con escribir mysql para acceder al sistema sino

que se requiere poner:

mysql -u root –p

para que se pida la clave de acceso.

Figura 4.23 Configuración de clave para MySQL

Para crear una base de datos se emplea el comando create database mientras que

para eliminarla se emplea drop. Cuando se genera una base de datos conviene

determinar con que usuario y desde que equipo en la red local, se podrá tener

acceso, así como los privilegios para modificar esta, para esto se emplea el comando

GRANT.

Figura 4.24 Creación de bases de datos y asignación de permisos

4.4.2. SERVIDOR DE ARCHIVOS

La implementación del servidor de archivos permitirá compartir a través de la red

tanto los recursos físicos de disco como también de dispositivos de almacenamiento

como disqueteras, CD-ROM, etc. Esto puede reducir la inversión en dichos

dispositivos y mejorar el aprovechamiento del hardware existente en la PyME.

4.4.2.1. Software

Entre las alternativas disponibles se tienen entre otros a Samba y NFS.

SAMBA es un conjunto de programas, bajo la Licencia Publica General GNU, y que

implementan en sistemas basados sobre UNIX® el protocolo SMB mediante el cual

se pueden realizar entre otras funciones las de compartir archivos e impresoras (entre

otras cosas) entre nodos de una red. Es utilizado principalmente en ordenadores con

Microsoft Windows.

Por otra parte, NFS está basado en RPC (Remote Procedure Call) y en la

arquitectura cliente/servidor. Fue creado por Sun como una alternativa para compartir

transparentemente fichero entre máquinas Unix, sin necesidad de utilizar ftp o ssh.

Ambas alternativas cumplen la función de servidor de archivos, sin embargo la

utilización de NFS se ve limitada para su uso entre computadores de sistema

operativo Linux, mientras que Samba permite dar servicio tanto a computadores

cliente Linux como Windows.

En base a los datos obtenidos en el capítulo 2, en las PyMEs en las que ya se cuenta

con algún tipo de servicio de TI, el sistema operativo que es acogido por la mayoría

de los equipos cliente es Windows. Ante esta situación es Samba la mejor alternativa

la cual además de poder también brindar servicio a eventuales clientes que utilicen

Linux (a través del protocolo SMB), permitirá entre otras opciones la convivencia de

sistemas Linux y Windows en el mismo dominio a través de:

§ Compartición de Carpetas, Archivos y dispositivos de almacenamiento.

§ Compartición de Impresoras.

§ Controlador de dominio.

§ Integración con LDAP para DC103 con capacidad de trabajo para

autenticación de clientes Windows y Linux.

La distribución de Samba con la que se trabaja corre sobre cualquier distribución de

GNU-Linux. En tal virtud se hará uso de la plantilla de servidor virtual basada en un

sistema operativo GNU-Linux CentOS 5.2 en la cual se instalarán los componentes

necesarios para el funcionamiento adecuado.

103 Domain Controller o Controlador de Dominio.

El hostname configurado es: servidordearchivos perteneciente al FQDN

servidordearchivos.vserver.ec y al que se le ha agregado un CNAME para facilidad

de uso como: samba.vserver.ec.

Para la instalación del servidor de archivos se requieren los siguientes elementos de

software:

§ samba: Servidor SMB.

§ samba-client: Diversos clientes para el protocolo SMB.

§ samba-common: Ficheros necesarios para cliente y servidor.

Con la distribución 5.2 de CentOS, bastará con utilizar yum para la instalación de los

paquetes requeridos, así:

yum -y install samba samba-client samba-common

Los archivos de configuración correspondientes al servicio son principalmente:

/etc/samba/smb.conf, /etc/samba/lmhosts.

Para la creación de usuarios que podrán compartir los recursos disponibles, son

agregados como típicamente se lo hace en Linux y a los que se les asigna su clave

smb correspondiente.

Cabe indicar que con fines de sincronización se deberá configurar tantos usuarios en

el servidor como usuarios a los que solo se les permita acceder (tanto en Windows o

Linux).

useradd -s /sbin/nologin centaurus

smbpasswd -a centaurus

Es necesario empezar resolviendo localmente los nombres NetBIOS asociándolos

con direcciones IP correspondientes. Esto se lo hace en el archivo lmhosts.

#Archivo de configuración /etc/samba/lmhosts 127.0.0.1 localhost 10.0.0.5 servidor de archivos

Espacio de Código 4.32 Configuración de archivo lmhosts en Samba.

La configuración de los grupos de trabajo, carpetas o recursos a compartir, usuarios

permitidos entre otras cuestiones de seguridad se los configura a partir del archivo

smb.conf

El grupo de trabajo se lo edita cambiando el valor del parámetro workgroup

asignando un grupo de trabajo deseado:

workgroup = Samba server

El parámetro server string es de carácter descriptivo.

server string = Servidor Samba

El parámetro hosts allow sirve para determinar el acceso a las diferentes máquinas

de la red, en este caso de la red interna.

hosts allow = 192.168.0. 192.168.2. 192.168.4. 10. 127.

Entre las opciones disponibles para configuración de las carpetas a compartir se

tienen las siguientes:

path = /cualquier/ruta/que/desee/compartir

El volumen puede utilizar cualquiera de las siguientes opciones:

Opción Descripción guest ok Define si se permitirá el acceso como usuario

invitado. El valor puede ser Yes o No. public Es un equivalente del parámetro guest ok, es

decir define si ser permitirá el acceso como usuario invitado. El valor puede ser Yes o No.

browseable Define si se permitirá mostrar este recurso en las listas de recursos compartidos. El valor puede ser Yes o No.

writable Define si se permitirá la escritura. Es el parámetro contrario de read only. El valor puede ser Yes o No. Ejemplos: «writable = Yes» es lo mismo que «read only = No». Obviamente «writable = No» es lo mismo que «read only = Yes»

valid users Define que usuarios o grupos pueden acceder al recurso compartido. Los valores pueden ser nombres de usuarios separados por comas o bien nombres de grupo antecedidos por una @. Ejemplo: danielserver, @administradores

write list Define que usuarios o grupos pueden acceder con permiso de escritura. Los valores pueden ser nombres de usuarios separados por comas o bien nombres de grupo antecedidos por una @. Ejemplo: danielserver, @administradores

admin users Define que usuarios o grupos pueden acceder con permisos administrativos para el recurso. Es decir, podrán acceder hacia el recurso realizando todas las operaciones como super-usuarios. Los valores pueden ser nombres de usuarios separados por comas o bien nombres de grupo antecedidos por una @. Ejemplo: danielserver, @administradores

directory mask Es lo mismo que directory mode. Define que permiso en el sistema tendrán los subdirectorios creados dentro del recurso. Ejemplos: 1777

create mask Define que permiso en el sistema tendrán los nuevos ficheros creados dentro del recurso. Ejemplo: 0644

Así el archivo de configuración del servidor de archivos con Samba es el siguiente:

# Archivo de configuración /etc/samba/smb.conf - DSCA, JJBS - vserver.ec 2009. #======================= Global Settings ===================================== [global] #Se define el grupo de trabajo y el string de descripciÃ³n workgroup = sambagroup server string = samba server %L #Se permite el acceso de las redes del datacenter y red corporativa hosts allow = 127. 192.168.0. 192.168.2. 192.168.4. 10. #Se indica la base de información a utilizar passdb backend = tdbsam # --------------------------- Printing Options ----------------------------- cups options = raw username map = /etc/samba/smbusers #============================ Share Definitions ============================== #Archivos y recursos compartidos [homes] comment = Home Directories browseable = no writeable = yes [printers] comment = Impresoras de vserver.ec path = /var/spool/samba browseable = no writeable = no printable = yes public = yes print command = lpr -P %p -o raw %s -r lpq command = lpstat -o %p lprm command = cancel %p-%j [compartido] comment = Carpeta de prueba path = /home/compartido/ public = yes writeable = yes browseable = yes [ftp] comment = Directorio del servidor FTP path = /var/ftp/pub guest ok = Yes read only = Yes #Se permite el permiso de escirtura únicamente al usuario centaurus con los parámetros 755 para directorio y 644 para ficheros write list = centaurus directory mask = 0755 create mask = 0644 #Se agrega la unidad de cdrom montada en /mnt como recurso compartido de la red [cd] comment = Unidad de cdrom path = /mnt

guest ok = Yes read only = Yes public = yes browseable = yes

Espacio de Código 4.33 Archivo de configuración smb.conf de Samba.

Una vez en Windows (equipos de los usuarios de la PyME) se puede observar los

resultados de la compartición de los recursos mediante Mis Sitios de Red o vía

Browser

Figura 4.25 Recursos compartidos desde Linux vistos en Windows XP.

4.4.3. SERVIDOR WEB EMPRESARIAL

El servidor web empresarial, es el encargado de brindar a la PyME un portal para la

intranet corporativa y la cual podrán acceder los distintos departamentos de la

organización.

La función de la web empresarial es la de brindar mediante el protocolo HTTP y

browsers, información interna de la organización ya sea de carácter administrativo,

financiero, gerencial, gestión documental, entre otros; además de abrir la posibilidad

para la implementación de aplicaciones web propias al negocio de cada PyMEs, lo

cual facilita su operación por su característica de adaptabilidad a los usuarios finales.

En el presente prototipo se proporciona la infraestructura adecuada para que la PyME

pueda implementar el sitio web correspondiente a sus necesidades internas en base

a las distintas posibilidades comentadas previamente.

4.4.3.1. Software

En cuanto a servidores web, en el mercado se encuentran algunas alternativas entre

las que se pueden destacar Apache como representante del software libre y gratuito e

Internet Information Services IIS como representante del software licenciado.

Sofware Características

Apache

Apache es el servidor Web por excelencia, con algo más de un 60% de los servidores de Internet utilizándolo a nivel mundial. Entre sus principales características podemos mencionar: rapidez, potente, eficaz, fiable, gratuito y extenso. Existen una gran variedad de módulos, que permiten generar contenido dinámico con PHP, Java, Perl, Pyton, etc., monitorizar el rendimiento del servidor, atender peticiones encriptadas por SSL, módulos que permiten crear servidores virtuales por IP o por nombre y limitar el ancho de banda para cada uno de ellos. Dichos módulos incluso pueden ser creados por cualquier persona con conocimientos de programación. Permite trabajo conjunto con MySql y php. Producto distribuido bajo Licencia GPL.

Internet Information

Services (IIS)

Es una serie de servicios para las computadoras que utilizan Windows como sistema operativo. Entre los servicios más comúnmente utilizados tenemos: FTP, SMTP, NNTP y HTTP/HTTPS. La computadora que tiene este servicio instalado se puede utilizar para publicar páginas Web tanto local (dentro de la red interna de la empresa) como remotamente (servidor Web, acceso desde cualquier lugar en Internet). El servidor Web se basa en varios módulos que le dan capacidad para procesar distintos tipos de páginas, por ejemplo Microsoft incluye los de Active Server Pages (ASP) y ASP.NET, pero también pueden ser incluidos otros módulos de otros fabricantes, como PHP o Perl. En definitiva Internet Information Server (IIS) es el componente de Windows que facilita la publicación de información y la ejecución de aplicaciones en el Web, con el objetivo de brindar mayor

seguridad, fiabilidad y rendimiento, se instala completamente bloqueado por defecto. Producto bajo Licencia incluido en las distribuciones de Windows Server.

Tabla 4.7 Características principales de alternativas de software servidor web. Fuente: Fuente: Diseño de la intranet de la empresa MEGAREDES Cía. Ltda., Tesis de Grado Ing. Trelles Segovia,

César Alfredo, Ing.Vallejo Cifuentes, Ricardo Patricio.

Apache es el servidor web más extendido y se ha convertido en estándar de los

sistemas Unix y Linux con gran cantidad de documentación de soporte disponible en

la web.

Se selecciona la alternativa del servidor Apache debido a que a demás de lo

mencionado anteriormente, cumple con las características técnicas necesarias para

dar soporte a las actuales páginas web basadas tanto en contenido estático como en

contenido dinámico adaptándose completamente con PHP, CGI, Perl y además

MySQL (constituyendo un servidor LAMP), todo esto en base a un proceso de

configuración simple.

Además su carácter de licenciamiento GPL beneficia de sobre manera la idea de

reducción de costos que tienen las PyMEs ofreciendo un servidor potente, rápido,

eficaz, flexible y escalable.

Apache corre sobre cualquier distribución de Linux y viene incluido por defecto en

varias versiones entre las que se encuentra CentOS 5.2. En tal virtud se hará uso de

la plantilla de servidor virtual basado en la distribución de GNU-Linux CentOS 5.2.

El hostname configurado es: webempresarial perteneciente al FQDN

webempresarial.vserver.ec y al CNAME web.vserver.ec.

Cuando el servicio no viene instalado por defecto, se puede instalarlo mediante la

herramienta yum. Para dar soporte adecuado para PHP/MySQL, Perl, Python y

SSL/TLS, solo bastará ejecutar:

yum -y install httpd php php-mysql mod_perl mod_python mod_ssl

La configuración del servicio se lo realiza en base al archivo httpd.conf localizado en

/etc/httpd/conf/httpd.conf. En este archivo se encuentran las configuraciones por

defecto, las cuales por sí funcionan bastante bien, por lo cual no será necesario

modificar parámetros. En caso que se desee utilizar funciones adicionales del

servidor apache, en este archivo se encuentra comentado las modificaciones que se

pueden realizar como por ejemplo configuración de Servidores web virtuales para

poder dar servicio con la misma IP a varias webs, modificación del puerto en el que

se escucha por defecto, modificación de las carpetas en donde se leerá por defecto,

lenguajes, tipo de codificación, usuario y grupo de acceso, entre otros.

Para el presente prototipo se ha diseñado una página web informativa, la cual deberá

ser ubicada en el directorio /var/www/html/ en donde se deberá incluir el archivo de

referencia inicial de la web: index.html. En el archivo httpd.conf pueden modificarse

parámetros adicionales como para la lectura de archivos index.htm, default.html, etc.

A continuación se presenta un extracto del archivo de configuración principal del

servidor web:

# Archivo de configuración httpd.conf - DSCA , JJBS - vserver.ec 2009. # This is the main Apache server configuration file. It contains the # configuration directives that give the server its instructions. # See <URL:http://httpd.apache.org/docs/2.2/> for detailed information. # In particular, see # <URL:http://httpd.apache.org/docs/2.2/mod/directives.html> # for a discussion of each configuration directive. # # Don't give away too much information about all the subcomponents

# we are running. Comment out this line if you don't mind remote sites # finding out what major optional modules you are running ServerTokens OS ServerRoot "/etc/httpd" PidFile run/httpd.pid Timeout 120 KeepAlive Off MaxKeepAliveRequests 100 KeepAliveTimeout 15 ## ## Server-Pool Size Regulation (MPM specific) ## # prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # ServerLimit: maximum value for MaxClients for the lifetime of the server # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves <IfModule prefork.c> StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 </IfModule> # worker MPM # StartServers: initial number of server processes to start # MaxClients: maximum number of simultaneous client connections # MinSpareThreads: minimum number of worker threads which are kept spare # MaxSpareThreads: maximum number of worker threads which are kept spare # ThreadsPerChild: constant number of worker threads in each server process # MaxRequestsPerChild: maximum number of requests a server process serves <IfModule worker.c> StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 </IfModule> # # Listen: Allows you to bind Apache to specific IP addresses and/or # ports, in addition to the default. See also the <VirtualHost> # directive. # # Change this to Listen on specific IP addresses as shown below to # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) # #Listen 12.34.56.78:80 Listen 80 # # Load config files from the config directory "/etc/httpd/conf.d".

# Include conf.d/*.conf User apache Group apache ServerAdmin root@vserver.ec # # ServerName gives the name and port that the server uses to identify itself. # This can often be determined automatically, but we recommend you specify # it explicitly to prevent problems during startup. ServerName web.vserver.ec:80 UseCanonicalName Off DocumentRoot "/var/www/html" # # Each directory to which Apache has access can be configured with respect # to which services and features are allowed and/or disabled in that # directory (and its subdirectories). # # First, we configure the "default" to be a very restrictive set of # features. # <Directory /> Options FollowSymLinks AllowOverride None ... </Directory> # # This should be changed to whatever you set DocumentRoot to. # <Directory "/var/www/html"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> ...

Espacio de Código 4.34 Archivo de configuración httpd.conf (extracto).

Como se ha podido indicar previamente, el hostname del servidor web interno es:

webempresarial, siendo el path para uso interno en un software browser:

webempresarial.vserver.ec. Por tal motivo (y como es evidente) se cambiará el

nombre a uno más amigable como: web.vserver.ec, info.vserver.ec y

intranet.vserver.ec; para tal efecto se agregará como entrada DNS CNAME al archivo

named.vserver.ec del servidor dnsiprimario de la intranet, así (extracto):

# Archivo de configuración named.vserver.ec

. . . webempresarial IN A 10.0.0.3 web IN CNAME webempresarial intranet IN CNAME webempresarial info IN CNAME webempresarial . . .

Espacio de Código 4.35 Agregación de CNAME para webempresarial.vserver.ec

Una vez hecho este cambio se presenta a continuación el despliegue de la

webempresarial: web.vserver.ec

Figura 4.26 Sitio web.vserver.ec – webempresarial.

4.4.4. SERVIDOR FTP

El servidor FTP actúa como un medio para el intercambio y distribución de archivos

entre los usuarios de la red empresarial. Su implementación es un complemento y

respaldo al servicio dado por el servidor de archivos y está orientado para archivos

comunes típicamente de corto tamaño (a diferencia del servidor de archivos en donde

es posible hacer uso extensivo de gran cantidad de disco e incluso montar el recurso

compartido) y de interés general

El servicio permite a la empresa considerar publicar en este servicio por ejemplo:

listas de materiales de un proyecto, hojas de cálculo, documentos, presentaciones

electrónicas, archivos en formato PDF, entre otros. Adicionalmente y en conjunto con

el servidor web puede ser de gran utilidad para la actualización de la web

empresarial.

El acceso a la información mediante el servicio de FTP debe estar protegido mediante

el uso de usuarios y passwords tomando en cuenta la disponibilidad de la información

en función de los usuarios del servicio.

4.4.4.1. Software

Existen varias alternativas bajo licencia GPL y gratuitas, entre las que tenemos se

destacan VsFTPD y ProFTPD.

Software Características

ProFTPD

Un solo fichero de configuración. Posibilidad de configurar múltiples servidores virtuales. Puede ejecutarse en los modos standalone o inetd. No requiere estructuras especiales de directorios para el directorio raíz anónimo. El servidor no ejecuta ningún programa externo. Oculta directorios y ficheros basándose en los permisos y propietarios de Unix. No necesita permisos de root para ejecutarse. Soporte de contraseñas shadow.

VSFTPD

Configuración de direcciones IP Virtuales. Usuarios Virtuales. Operación por medio de inetd o Standalone. Poderosa configuración por usuario. Control de ancho de banda. Limite de conexiones IP por usuario. Encripción por medio de SSL Asigna permisos mínimos. Utiliza entorno chroot Seguridad, estabilidad y performance

Tabla 4.8 Alternativa de software para FTP. Fuente: http://vsftpd.beasts.org/#security y http://www.informaticabosco.com/phpnuke/linuxavanzado/curso/bloque04/12.ProFTPD.pdf

Las alternativas presentadas poseen características similares, sin embargo el factor

decisivo para la elección de uno u otro es la seguridad. El servidor ProFTPD tiene un

hueco de seguridad el cual puede ser explotado y perjudicar la integridad del servidor

en sí; por otra parte Vsftpd o Very Secure FTPD no ha presentado hasta la fecha

fallas de seguridad y es usado por grandes empresas que confían en su diseño como

Red Hat, Suse, Debian, FreeBSD.

Es así que la alternativa vsftpd posee características importantes como simplicidad de

configuración y seguridad. Sus características técnicas referentes al control de

acceso a los recursos en base a usuarios anónimos y locales así como

características de seguridad adicionales como por ejemplo enjaular la carpeta de

acceso de cada usuario, manejo de user y password, especificación de recursos de

acceso común, entre otros hacen de ésta una muy buena alternativa.

A todo lo mencionado se suma su carácter gratuito bajo su licencia GPL ubicándolo

acorde con la línea seguida para las PyMEs.

El servidor virtual sobre el cual corre el servicio ftp está basado en la plantilla de

instalación de GNU-Linux en su distribución CentOS 5.2 con el hostname

ftp.vserver.ec.

Para la instalación del servicio se hace uso de la herramienta yum, de la siguiente

manera:

yum –y vsftpd

Creándose el usuario ftp dentro del grupo nogroup. Directorio /home/ftp propiedad de

root en donde se alojarán los archivos para usuarios anónimos.

4.4.4.3.1. Archivo de configuración vsftpd.conf

El archivo de configuración se localiza en /etc/vsftpd/vsftpd.conf. La configuración

puede realizarse de igual forma mediante la herramienta Webmin, en la cual se le

agrega el módulo de configuración del servidor vsftpd.

Los parámetros configurables más importantes son los siguientes:

Proceso independiente (standalone): listen=YES

Para la gestión de usuarios se tienen parámetros para usuarios anónimos y locales:

Anónimos: anonymous_enable=YES

Usuarios locales: local_enable=YES

Descarga de archivos:

El usuario anónimo está recluido al home del usuario ftp.

Los usuarios locales se conectan como usuarios del sistema, pero confinados a su

directorio home:

chroot_local_user=YES

Para que no todos los usuarios queden recluidos en su directorio home se incluyen

sus nombres en un archivo con esta directiva:

chroot_list_file=/etc/vsftpd.chroot_lista

Carga de archivos para usuarios locales:

Permite subir archivos: write_enable=YES

Permisos del archivo subido: local_umask=022

Carga de archivos para usuarios anónimos:

Desactivada por defecto: anon_upload_enable=YES

Para permitir modificar archivos y creación de direcciones:

anon_other_write_enable=YES

anon_mkdir_write_enable=YES

Estos parámetros configurables pueden ser modificados, como se ha mencionado

anteriormente, mediante el uso de Webmin.

Figura 4.27 Configuración de vsftpd vía Webmin.

El archivo de configuración básico es el que se presenta a continuación; en éste se

ha configurado acceso únicamente para usuarios registrados en el sistema en modo

chroot, impidiendo así el uso de usuarios anónimos:

# Archivo de configuración FTP – DSCA , JJBS – vserver.ec 2009. ftp_username=ftp

# Allow anonymous FTP? (Beware - allowed by default if you comment this out). anonymous_enable=NO local_enable=YES # # Uncomment this to enable any form of FTP write command. write_enable=YES # # Default umask for local users is 077. You may wish to change this to 022, # if your users expect that (022 is used by most other ftpd's) local_umask=022 # # Uncomment this to allow the anonymous FTP user to upload files. This only # has an effect if the above global write enable is activated. Also, you will # obviously need to create a directory writable by the FTP user. anon_upload_enable=NO # # Uncomment this if you want the anonymous FTP user to be able to create # new directories. anon_mkdir_write_enable=NO # # Activate directory messages - messages given to remote users when they # go into a certain directory. dirmessage_enable=YES # # The target log file can be vsftpd_log_file or xferlog_file. # This depends on setting xferlog_std_format parameter xferlog_enable=YES # # Make sure PORT transfer connections originate from port 20 (ftp-data). connect_from_port_20=YES # Switches between logging into vsftpd_log_file and xferlog_file files. xferlog_file=/var/log/vsftpd.log xferlog_std_format=YES # # You may change the default value for timing out an idle session. idle_session_timeout=600 # # You may change the default value for timing out a data connection. data_connection_timeout=120 # # You may fully customise the login banner string: ftpd_banner=Bienvenidos, servidor FTP de vserver.ec, -JJBS , DSCA - 2009 # # You may specify an explicit list of local users to chroot() to their home chroot_local_user=YES # When "listen" directive is enabled, vsftpd runs in standalone mode and # listens on IPv4 sockets. This directive cannot be used in conjunction # with the listen_ipv6 directive. listen=YES pam_service_name=vsftpd userlist_enable=YES tcp_wrappers=YES

Espacio de Código 4.36 Archivo de configuración vsftpd.conf

4.4.5. SERVIDOR DE IMPRESIÓN

El servidor de impresión es el dispositivo que permitirá la conexión de una o varias

impresoras en la intranet empresarial. Es decir que cualquier dispositivo autorizado

que pueda acceder a la red interna de la empresa podrá conectarse a la impresora

para la impresión de trabajos.

4.4.5.1. Software

Para la implementación del servidor de impresión, únicamente se requiere de

software que permita la acceder a las impresoras, ya sean conectadas en la red o

localmente al servidor, desde cualquier otro dispositivo de red independientemente de

su sistema operativo, es decir que se deben emplear protocolos comunes.

La alternativa de software empleada para los sistemas operativos de tipo Unix es el

paquete cups (Common Unix Printing System). Se trata del sistema de impresión

modular por defecto en Linux que permite al computador actuar como un servidor de

impresión, aceptando o rechazando las tareas de impresión desde otros clientes en la

red y dirigiendo las peticiones a la impresora adecuada.

Adicionalmente a este paquete, existen herramientas adicionales para interfaz de

usuario. De esta forma se puede controlar y monitorear el servicio mediante una

interfaz web en el puerto 631, mediante GNOME CUPS Manager o mediante

KDEPrint.

La alternativa a emplearse para el servidor de impresión es cups junto con la interfaz

web de usuario. Esto se debe no solo a que cups es la alternativa por defecto en los

sistemas Unix, sino que permite dos cosas importantes: primero, el trabajar con el

Protocolo de Impresiones de Internet IPP (Internet Printing Protocol) lo que asegura

compatibilidad; y segundo, que los clientes se conecten a las impresoras de manera

Plug & Play y sin la necesidad de configuraciones complicadas.

El servidor de impresión se basa en el servidor virtual base instalado sobre el cual se

activa el servicio CUPS. El hostname correspondiente al servidor es: impresion

perteneciente al FQDN impresion.vserver.ec.

La instalación del servicio cups se puede realizar añadiendo el paquete en la

administrador de paquetes, empleando el comando yum install cups o simplemente

mediante la descarga del paquete de la página del proyecto en http://www.cups.org/.

Figura 4.28 Instalación de cups mediante el comando yum install.

La configuración de cups se suele realizar mediante una interfaz gráfica empleando

un navegador web pero también es posible su configuración mediante el archivo

cupsd.conf.

Para acceder al modo web se debe emplear el puerto 631. Desde esta interfaz se

puede seleccionar en Administrar Impresoras, aquí se puede seleccionar Añadir

Impresora, esto se realiza indicando el nombre, ubicación o descripción. Finalmente

se debe especificar el tipo de impresora y el fabricante y el modelo. Con esto

aparecerá un vínculo con el nombre de la impresora en el que se puede configurarla.

Figura 4.29 Pantalla de administración de cups vía web

El archivo de configuración de cups es /etc/cups/cupsd.conf, y para su configuración

se emplean directivas de permisos que permiten definir que direcciones tienen

acceso a que parte de CUPS. Cada parte se corresponde a una sección de la interfaz

web de administración. Un ejemplo de directiva se muestra a continuación:

Order Deny,Allow

Deny From All

Allow From 192.168.0.*

</Location>

Espacio de Código 4.37 Cambios en el archivo de migración migrate_common.ph

Location define la configuración para un directorio y sus hijos. La localización / da

permiso a todo el directorio raíz y todos sus hijos, es decir brinda acceso a todo cups.

/printers da acceso a las impresoras, /admin a la interfaz de administración y /job a la

gestión de trabajos.

Order define el tipo de permiso de acceso, así Allow,Deny permite el acceso a todas

las IP excepto aquellas listadas en las directivas Deny, y Deny,Allow solo permite el

acceso a las IP listadas en directivas Allow

En el ejemplo indicado sólo los equipos con una dirección IP de la red interna

(192.168.0.0/24) tienen acceso a las impresoras.

4.5. INSTALACIÓN Y CONFIGURACIÓN DE LA DMZ

Con la finalidad de brindar mayor seguridad a los servidores virtualizados del

Datacenter de Datos e Infraestrcutrua, que tienen información vital de la organización,

y para el funcionamiento de la infraestructura interna, los servidores virtuales que

serán publicados en Internet son agrupados en una Zona Desmilitarizada o DMZ. De

esta manera se busca aislar los servidores críticos para el negocio y que dan servicio

a la Intranet y a usuarios conocidos de los servidores que pueden ser accedidos a

través de Internet.

La DMZ está delimitada por dos servidores de ruteo, firewall y NAT que son:

firewallproxy el cual da la cara a la Intranet y el servidor firewallinternet que es a

través del cual viajan los datos hacia el mundo de Internet.

Adicionalmente a esto, se ha considerado la creación de una VPN con la finalidad de

brindar a la PyME la posibilidad de conexión para usuarios de la organización en

otras sucursales; la VPN permitirá el acceso a través de Internet a la Intranet

corporativa mediante un túnel seguro.

Figura 4.30 DMZ corporativa.

Los servidores que forman parte de la DMZ son:

§ Firewall-proxy

§ Firewall-internet

§ Dns (externo) primario

§ Dns (externo) secundario

§ Mail Gateway

§ Web

§ Comercio electrónico

§ VPN

4.5.1. SERVIDOR WEB INTERNET

El servidor Web Internet permitirá a la PyME mostrarse al mundo a través de un sitio

web que permita a los clientes conocer la empresa, sus productos, su filosofía, así

como también poder contactarse e incluso posibilitar realizar compras en línea. Para

ello es fundamental la adquisición de un dominio el cual identificará a la PyME y será

el nombre con el cual se de a conocer. Hoy en día el poseer una página Web es

fundamental para poder crecer en un ambiente competitivo.

4.5.1.1. Software

El software utilizado corresponde a la alternativa Apache tal como lo visto en el tema

4.4.3.1 sobre el servidor web empresarial.

La página web principal correspondiente a la organización se aloja en el servidor

webinternet.vserver.ec. Se configurará a continuación el CNAME para webinternet

como www, de tal manera que el despliegue de la web a través de Internet sea

mediante la dirección www.vserver.ec; esto se lo hace en el servidor DNS de la DMZ.

Adicionalmente, se brinda la posibilidad a la PyME a ofrecer uno o varios productos

adicionales con dominios propios para cada uno y webs independientes

correspondientemente; esto se logra mediante la configuración de servidores virtuales

a través de apache. Así se tiene webs independientes para buy.vserver.ec, via-

net.vserver.ec y viadmin.vserver.ec (el cual servirá como portal de administración).

En adición es posible albergar webs de dominios diferentes posibilitando brindar el

servicio a varias PyMEs mediante un único servidor configurado, así se configurará la

web para el dominio www.aeie.ec como otra PyME alojada en el servidor web.

Para cada dominio configurado se crean ficheros correspondientes en

/var/www/html/nombre_del_dominio, y se configura en el servidor Web la lectura del

archivo index de los ficheros correspondientes.

Figura 4.31 Ficheros de webs alojadas.

A continuación se presenta la configuración de los servidores virtuales en el archivo

/etc/httpd/conf/httpd.conf. Por extensión del archivo a continuación se presenta un

extracto.

# Archivo de configuración httpd.conf – DSCA , JJBS – vserver.ec 2009. . . . # Configuracion de webs virtuales en base al mismo servidor web webinternet.vserver.ec # Apache mostrara por defecto la webinternet.vserver.ec ServerName webinternet.vserver.ec NameVirtualHost 10.0.2.2 DocumentRoot /var/www/html/www.vserver.ec/ # Se configura el virtual host www.aeie.ec correspondiente a la segunda alternativa de web que la PyME puede ofrecer con el mismo servidor <VirtualHost 10.0.2.2> ServerName www.aeie.ec DocumentRoot /var/www/html/www.aeie.ec/ DirectoryIndex index.html index.htm index.php </VirtualHost> # Se configura el virtual host www.vserver.ec que corresponde al CNAME de webinternet.vserver.ec <VirtualHost 10.0.2.2> ServerName www.vserver.ec DocumentRoot /var/www/html/www.vserver.ec/ DirectoryIndex index.html index.htm index.php </VirtualHost> # Se configura el portal de comercio electronico buy.vserver.ec <VirtualHost 10.0.2.2> ServerName buy.vserver.ec ServerAlias e-commerce.vserver.ec

DocumentRoot /var/www/html/buy.vserver.ec/ DirectoryIndex index.html index.htm index.php </VirtualHost> # Se configura el portal de via-net.vserver.ec como producto secundario de la PyME <VirtualHost 10.0.2.2> ServerName via-net.vserver.ec DocumentRoot /var/www/html/via-net.vserver.ec/ DirectoryIndex index.html index.htm index.php </VirtualHost> # Se configura el portal de viadmin.vserver.ec como portal de administracion <VirtualHost 10.0.2.2> ServerName viadmin.vserver.ec DocumentRoot /var/www/html/viadmin.vserver.ec/ DirectoryIndex index.html index.htm index.php </VirtualHost>

Espacio de Código 4.38 Archivo de configuración httpd.conf de la webinternet.

La configuración de los CNAME se los realiza en el archivo named.vserver.ec, a la

vez que se crean los registros adicionales para el dominio aeie.ec como se muestra a

continuación:

# Archivo de configuración named.conf … zone "vserver.ec" IN { type master; file "named.vserver.ec"; allow-update { none; }; allow-query { any; }; allow-transfer { 10.0.2.6; }; }; zone "aeie.ec" IN { type master; file "named.aeie.ec"; allow-update { none; }; allow-query { any; }; allow-transfer { 10.0.2.6; }; };

Espacio de Código 4.39 Extracto del archivo de configuración named.conf.

# Archivo de configuración named.vserver.ec … webinternet IN A 10.0.2.2 www IN CNAME webinternet buy IN CNAME webinternet via-net IN CNAME webinternet viadmin IN CNAME webinternet Espacio de Código 4.40 Configuración de CNAME para las web alojadas en webinternet del

dominio vserver.ec.

# Archivo de configuración named.aeie.ec … $TTL 86400 @ IN SOA dnsiprimario.vserver.ec. root.dnsiprimario.vserver.ec. ( 2009102416 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsiprimario.vserver.ec. www IN A 10.0.2.2

Espacio de Código 4.41 Configuración del dominio www.aeie.ec para ser atendido por el servidor virtual webinternet (10.0.0.2).

A continuación se muestra el despliegue de los portales configurados:

Figura 4.32 Portal Web www.vserver.ec

Figura 4.33 Portal Web www.aeie.ec

Figura 4.34 Portal Web viadmin.vserver.ec

4.5.2. SERVIDOR DE COMERCIO ELECTRÓNICO

El servidor de comercio electrónico es un servidor web seguro al que los clientes de

una empresa pueden acceder para realizar sus transacciones comerciales con la

misma. Para su funcionamiento necesita de un motor de base de datos, la base de

datos de los productos y servicios y de los clientes con sus pedidos, un sistema de

pedidos y un sistema de pago.

4.5.2.1. Software

Como se mencionó en el punto anterior, un servidor de comercio electrónico está

prácticamente formado por un servidor web seguro y una base de datos. Pese a esto

existen soluciones específicas para la creación de servidores de correo electrónico

que se emplean para facilitar la labor de creación del sitio de comercio.

Existen varias alternativas para lograr obtener un servidor de comercio electrónico

que van desde la configuración de un servidor web común hasta el empleo de

paquetes de software especializados para el comercio electrónico. Para brindar una

mayor facilidad y seguridad, en el presente proyecto se ha decidido emplear los

paquetes especializados. Entre estos se tiene a: Zen Cart, PrestaShop, osCommerce,

entre otros. Todas estas soluciones representan a aplicaciones gratuitas para el

comercio electrónico desde Linux.

Zen Cart es una aplicación que permite la creación de una tienda en línea fácil de

configurar y manejar. Esta aplicación está desarrollada en base al código de

osCommerce y permite una fácil administración y manejo de los productos por parte

tanto de los responsables de la empresa como de los clientes que accedan a la

página web.

osCommerce es otra gran aplicación para la administración de tiendas en línea. Esta

solución permite una fácil configuración del servidor en pocos minutos e incluye

funcionalidades listas para usarse desde el momento de la instalación.

Finalmente PrestaShop es una aplicación web de comercio electrónico profesional.

Esta plataforma brinda a los clientes una tienda personalizada a la que se puede

añadir un gran número de funciones.

Para el servidor de comercio electrónico del presente proyecto se ha seleccionado la

opción presentada por Zen Cart, esto se debe a que esta aplicación brinda un fácil

manejo a los administradores del servidor y presenta características similares a

osCommerce (está basado en su código) pero incluye características adicionales. Por

otro lado la solución presentada por PrestaShop, al ser una aplicación muy

profesional, presenta ciertas dificultades en la administración de la página por lo que

no resulta conveniente para pequeñas y medianas empresas.

Por las características de la solución de e-commerce a implementarse, el presente

servidor se basa en la instalación de GNU-Linux CentOS 5.2 tomada como base para

los servidores virtuales de éste prototipo.

El hostname correspondiente al servidor es: comerioelectronico perteneciente al

FQDN comercioelectronico.vserver.ec y al que se ha configurado como CNAME

buy.vserver.ec y e-commerce.vserver.ec

La instalación del servicio de comercio electrónico de Zen Cart se puede realizar

descargando el paquete necesario de la página oficial del proyecto en el vínculo

http://sourceforge.net/projects/zencart/files/CURRENT_%20Zen%20Cart%201.3.x%2

0Series/Zen%20Cart%20v1.3.8%20-%20Full%20Release/zen-cart-v1.3.8a-full-fileset-

12112007.zip/download.

Además de este paquete es necesario tener instalado tanto un servidor web como

Apache y un servidor de base de datos como MySQL, la instalación de estos

servidores se detalla en sus respectivos puntos.

El paquete que se descarga de la página de Zen Cart corresponde a código PHP que

se debe colocar en la carpeta apropiada del servidor http (/var/www/), y configurar el

servidor web para que cargue esta página como se muestra en el punto 4.4.3.3., una

vez terminada esta configuración se puede acceder a la página creada, es decir que

en un navegador web se accede a la página en la que se configurará el servidor, en

el caso de el presente proyecto se empleará la página http://tienda.vserver.ec en la

que se muestra la siguiente pantalla.

Figura 4.35 Pantalla de inicio de Zen Cart

Una vez que se puede accede a Zen Cart vía web, se procede a elegir el punto

número 1 de la pantalla de la figura 4.35., que corresponde a la primera vez que se

accede a la página. Entonces se muestra una pantalla informativa del programa en la

que se debe seleccionar continuar para acceder a la lectura de la licencia.

Figura 4.36 Licencia de Zen Cart

Es muy probable que en estos momentos aparezca una pantalla que muestre errores

como la que aparece a continuación:

Figura 4.37 Inspección del sistema

Esto se debe a que ciertos archivos no tienen permisos de escritura por lo que se

debe emplear el comando chmod +w en los archivos: cache, images,

includes/languages/english/html_includes, pub, /admin/backups y en

/admin/images/graphs.

El otro problema mencionado se debe a la inexistencia del archivo configure.php, esto

se soluciona cambiando los nombres de los archivos dist-configure.php en

/var/www/com/tienda/admin/includes y /var/www/com/tienda//includes por

configure.php y dándoles los permisos requeridos. Entonces al refrescar la pantalla

aparecerá lo siguiente:

Figura 4.38 Comprobación del sistema para la Instalación de Zen Cart

Una vez terminada esta instalación se procede a la configuración de la base de datos

Figura 4.39 Configuración de la Base de Datos

La base de datos que se empleará en el presente proyecto es la creada en el servidor

de base de datos. Una vez que ZenCart se asocia correctamente a la base de datos

configurada con el password proporcionado se procede a la configuración del servidor

Figura 4.40 Configuración del sistema

Una vez terminado esto, Zen Cart solicitará la ubicación de phpBB que corresponde a

un paquete de foros en internet que empleará el servidor.

Figura 4.41 Petición del directorio phpBB

Este paquete se puede descargar de la página http://www.phpbb.com/. Al igual que

en el caso de Zen Cart solo debe ser descomprimido y ubicado en la carpeta

correspondiente del servidor web.

Figura 4.42 Ubicación del directorio phpBB

Finalmente se configuran las propiedades de la tienda virtual como su nombre,

contactos, moneda, idioma, entre otros y se procede a configurar la cuenta de

administrador que permita realizar los cambios necesarios como la sustitución de los

productos de ejemplo por los que se quiera vender.

Figura 4.43 Configuración de la cuenta de Administración

4.5.3. SERVIDOR DE CORREO ELECTRÓNICO (MAIL GATEWAY)

Como se vio en los temas anteriores, en el Datacenter de Infraestructura se

implementó el servidor de correo Mailempresarial cuya función es la de brindar el

servicio entre los usuarios de la organización en su dominio vserver.ec. Sin embargo

el correo con destino de otro dominio necesita de un servidor que se encuentre dando

la cara a Internet.

Es así que en la DMZ se configura al servidor Mail Gateway; éste es el encargado de

la distribución de correo saliente desde el dominio vserver.ec hacia los dominios de

Internet y así de igual manera entregar los correos enviados desde otros dominios

hacia el dominio vserver.ec.

El servidor Mailgateway es un servidor de relay para el servidor de correo

Mailempresarial y en tal efecto debe permitir únicamente al dominio vserver.ec

retransmitir correos.

Figura 4.44 Envío y recepción de correo entre MailEmpresarial y MailGateway.

4.5.3.1. Software

El software utilizado para la configuración del servidor Mailgateway corresponde al

mismo software elegido en el tema 4.3.4.1 correspondiente a la implementación del

Mailempresarial.

Para la configuración del servidor de correo mailgateway, se editará el archivo de

configuración de Sendmail correspondiente a /etc/mail/sendmail.mc; en este archivo

se editan las siguientes líneas de la siguiente manera, presentándose a continuación

un extracto104:

dnl # Archivo de configuración Sendmail – DSCA, JJBS – vserver.ec 2009 dnl # LíNEA COMENTADA PARA PERMITIR ACEPTAR EMAIL DESDE INTERNET Y LA INTRANET dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

Espacio de Código 4.42 Archivo de configuración sendmail.mc

Finalmente es necesario ejecutar el editor de macros m4 para la creación del archivo

sendmail.cf.

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Para la configuración del acceso de envío de correos se modifica el archivo

/etc/mail/access donde se agregan las IPs de las personas que van a poder entregar

correo al exterior (a hotmail, yahoo, etc...) o a su vez el dominio en este caso

vserver.ec:

104 Código completo puede encontrarse en anexo J.

# Se permite el envío de correos para las máquinas del dominio vserver.ec # Check the /usr/share/doc/sendmail/README.cf file for a description # of the format of this file. (search for access_db in that file) # The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc # package. # # by default we allow relaying from localhost... Connect:localhost.localdomain RELAY Connect:localhost RELAY Connect:127.0.0.1 RELAY vserver.ec RELAY

Espacio de Código 4.43 Archivo de configuración access.

Para indicar el servidor de correo mailempresarial como receptor de los correos

entrantes se identifica el archivo /etc/mail/mailertable especificándolo así:

# Se indica la dirección del servidor que distribuirá los correos entrantes a los clientes vserver.ec smtp:10.0.1.5

Espacio de Código 4.44 Archivo de configuración mailertable.

Cabe indicar que se debe configurar en el servidor dns los registros correspondientes

de las máquinas de la red interna con el dominio vserver.ec garantizando así su envío

y seguridad del Relay.

Cuando se actualiza este fichero se debe ejecutar make dentro de /etc/mail/ para que

se actualice la base de datos.

Para el manejo de SMTP autentificado se inicia el servicio saslauthd y se descomenta

la siguiente línea en el archivo sendmail.mc

dnl # Activar servicio SMTP autentificado TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

Espacio de Código 4.45 Activación del servicio SMTP autentificado

El servicio SMTP autentificado agrega una capa más de seguridad para evitar el uso

de nuestro MTA como generador de correo no autorizado.

Para la configuración e instalación de los complementos de sendmail: Mail Scanner y

Clamav el proceso es el siguiente:

Para la instalación de clamav, se descarga el archivo binario de la web:

http://sourceforge.net/projects/clamav/files/clamav/0.95.3/clamav-

0.95.3.tar.gz/download con la versión clamav-0.95.3

Es necesaria la agregación del usuario y grupo clamav. Para mantener actualizada la

base de virus se realiza un cron diario que haga referencia al archivo freshclam.

Para la instalación de spamassassin se lo descarga de los repositorios por defecto

del sistema mediante:

rpm –ihv spamassassin*

Para la instalación del MailScanner se descarga el archivo rpm de la web

http://www.mailscanner.info/downloads.html

Para la configuración, el archivo correspondiente es

/etc/MailScanner/MailScanner.conf

Y se editan los parámetros más importantes como son:

# Configuración de MailScanner – DSCA, JJBS – vserver 2009 %org-name% = vserver %org-long-name% = Virtualserver %web-site% = www.vserver.ec %etc-dir% = /etc/MailScanner %report-dir% = /etc/MailScanner/reports/es # Se indica el software antivirus con el que se trabajará

Virus Scanners = clamav # Se indicant las listas de spam a tomar en cuenta Spam List = SBL + XBL + SORBS + spamhaus-ZEN # Correo spam será enviado a la cuenta spam Spam Actions = forward spam@vserver.ec # Valor mínimo para ser considerado spam Required SpamAssassin Score = 5.5 # Valor máximo para no ser eliminado el mensaje spam High SpamAssassin Score = 10

Espacio de Código 4.46 Archivo de configuración de MailScanner

Con ello el servicio a administrar será MailScanner, el cual levanta y baja el servicio

Sendmail.

Con fines de uso del servicio, es posible instalar el software Squirrel mail el cual

permite el envío y recepción de correos a través del portal web. En el presente

prototipo se ha instalado105 dicho software siendo la dirección para uso:

webempresarial.vserver.ec/webmail, de esta manera los usuarios de la PyME podrán

revisar sus correos de manera simple en cualquier parte del mundo.

Figura 4.45 Squirrel Mail en el servidor Webempresarial.

105 Para referirse a la instalación remitirse al anexo H.

4.5.4. SERVIDOR DNS (EXTERNO – DMZ)

Estos servidores DNS son los servidores primario y secundario que se encargan de

brindar el servicio de resolución de nombres a los clientes de la zona desmilitarizada

que no podrían acceder a los servidores DNS de la intranet.

4.5.4.1. Software

Como se mencionó en el punto 4.3.2.1.1., el paquete bind se ha convertido en un

estándar de-facto para este tipo de servidores, y aunque otras alternativas para el

mismo, estas aún no se han vuelto tan populares.

El paquete de software que se empleará en los servidores DNS de la zona

desmilitarizada debe ser el mismo que se emplea en los servidores DNS de la zona

interna de la red para evitar complicaciones de compatibilidad y configuración, por lo

que se debe emplear el paquete bind.

Para el presente servidor se utilizará el mismo tipo de servidor virtual instalado en el

capítulo 4.3.2., siendo en este caso los hostnames: dnseprimario (primario) y

dnsesecundario (backup).

La instalación del servicio bind se realiza de la misma manera como se instalaron los

servidores de nombres de la zona de infraestructura, que se detalla en el punto

4.3.2.2. del presente capítulo.

Al igual que en la zona de infraestructura, en la DMZ también se disponen de dos

servidores DNS que actuaran como servidor DNS primario y secundario, por lo que

de la misma forma que en dicha configuración se deben de crear los archivos

named.conf junto con sus zonas de nombres, IP y locales. También teniendo en

cuenta que debido a la existencia de bind-chroot, los archivos de configuración se

encuentran en /var/named/chroot/.

4.5.4.3.2. Dnseprimario

Como su nombre lo indica el servidor dnseprimario corresponde al servidor de

nombres primario de la zona desmilitarizada. El archivo de configuración principal es

/var/named/chroot/etc/named.conf y su configuración se muestra a continuación:

options { directory "/var/named"; forward only; forwarders { 172.16.0.2; } ; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "." IN { type hint; file "named.ca"; }; zone "vserver.ec" IN { type master; file "named.vserver.ec"; allow-update { none; }; allow-query { any; }; allow-transfer { 10.0.2.6; }; }; zone "2.0.10.in-addr.arpa" IN { type master; file "named.10.0.2"; allow-update { none; }; allow-query { any; }; allow-transfer { any; }; }; zone "0.16.172.in-addr.arpa" IN { type master;

file "named.172.16.0"; allow-update { none; }; allow-query { any; }; allow-transfer { any; }; }; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; allow-query { any; }; allow-transfer { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; allow-update{ none; }; allow-query { any; }; allow-transfer { none; }; }; include "/etc/rndc.key";

Espacio de Código 4.47 Archivo de configuración DNS primario named.conf

A continuación se muestran los archivos de zonas

/var/named/chroot/var/named.vserver.ec:

$TTL 86400 @ IN SOA dnseprimario.vserver.ec. root.vserver.ec. ( 2009102405 ; serial 28800 14400 3600000 86400 ) IN NS dnseprimario.vserver.ec. IN MX 10 mailgateway.vserver.ec. firewallproxy-dmz IN A 10.0.2.1 webinternet IN A 10.0.2.2 mailgateway IN A 10.0.2.3 comercioelectronico IN A 10.0.2.4 dnseprimario IN A 10.0.2.5 dnsesecundario IN A 10.0.2.6 firewallinternet-dmz IN A 10.0.2.254 firewallinternet IN A 172.16.0.1 routerinternet IN A 172.16.0.2

Espacio de Código 4.48 Archivo de zona de nombres primario named.vserver.ec

$TTL 86400 @ IN SOA dnseprimario.vserver.ec. root.vserver.ec. ( 2009102403 ; serial 28800 14400

3600000 86400 ) IN NS dnseprimario.vserver.ec. 1 IN PTR firewallproxy-dmz.vserver.ec. 2 IN PTR webinternet.vserver.ec. 3 IN PTR mailgateway.vserver.ec. 4 IN PTR comercioelectronico.vserver.ec. 5 IN PTR dnseprimario.vserver.ec. 6 IN PTR dnsesecundario.vserver.ec. 254 IN PTR firewallinternet.vserver.ec.

Espacio de Código 4.49 Archivo de zona IP named.10.0.2

$TTL 86400 @ IN SOA dnseprimario.vserver.ec. root.vserver.ec. ( 2009102401 ; serial 28800 14400 3600000 86400 ) IN NS dnseprimario.vserver.ec. 1 IN PTR firewallinternet.vserver.ec. 2 IN PTR routerinternet.vserver.ec.

$TTL 86400 @ IN SOA dnseprimario.vserver.ec. root.vserver.ec. ( 2009102401 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnseprimario.vserver.ec. 1 IN PTR localhost.

Espacio de Código 4.51 Archivo de zona local primario named.local

$TTL 86400 @ IN SOA dnseprimario.vserver.ec. root.vserver.ec. ( 2009102401 ; serial 28800 ; refresh 14400 ; retry 3600000 ; expiry 86400 ) ; minimum IN NS dnseprimario.vserver.ec. localhost. IN A 127.0.0.1

4.5.4.3.3. Dnsesecundario

Este servidor es el DNS secundario de la zona desmilitarizada. Su archivo de

configuración, /var/named/chroot/etc/named.conf, se muestra a continuación:

options { directory "/var/named"; forward only; forwarders { 172.16.0.2; } ; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; zone "vserver.ec" IN { type slave; file "named.vserver.ec.bck"; masters { 10.0.2.5; }; }; zone "2.0.10.in-addr.arpa" IN { type slave; file "named.10.0.2.bck"; masters { 10.0.2.5; }; }; zone "0.16.172.in-addr.arpa" IN { type slave; file "named.172.16.0.bck"; masters { 10.0.2.5; }; }; zone "localhost" IN { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; }; include "/etc/rndc.key";

Espacio de Código 4.53 Archivo de configuración DNS secundario named.conf

$TTL 86400 @ IN SOA dnsesecundario.vserver.ec. root.dnsesecundario.vserver.ec. ( 2009102401 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsesecundario.vserver.ec. 1 IN PTR localhost.

Espacio de Código 4.54 Archivo de zona local secundario named.local

$TTL 86400 @ IN SOA dnsesecundario.vserver.ec. root.dnsesecundario.vserver.ec. ( 2009102401 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dnsesecundario.vserver.ec. localhost. IN A 127.0.0.1

4.5.5. SERVIDORES PROXY, FIREWALL

Como ya se indicaba en el punto 4.3.1., este servidor es el encargado de conectar a

la red de la empresa con el mundo exterior, es decir que será el encargado de

permitir el acceso a Internet y, en caso de ser requerido, establecer conexiones vía

Para realizar sus funciones correctamente debe brindar la seguridad del filtrado de

tráfico de un firewall y debe realizar funciones de NAT para permitir la salida de todos

los usuarios al Internet mediante una sola dirección IP pública.

4.5.5.1. Software

Para este servidor de enrutamiento específico, se requiere la instalación de paquetes

de software que brinden los servicios de filtrado de paquetes (firewall), traducción de

direcciones (NAT) y finalmente la creación de redes virtuales privadas (VPN).

Para el caso del firewall y NAT, ya se analizaron las alternativas de software en el

punto 4.3.1.1.1., quedando en claro que el paquete iptables era la mejor opción para

realizar el filtrado de paquetes y la traducción de direcciones.

Por otro lado para la creación de enlaces VPN se disponen de paquetes como

OpenVPN, Openswan, PoPToP. Cada uno de estos, se basa en diferentes

soluciones, así OpenVPN se basa en SSL, OpenSwan es una VPN IPSec, y

finalmente PoPToP se basa en PPTP.

OpenVPN tiene la ventaja de que usa SSL (Secure Sockets Layer), el cual es un

protocolo muy maduro que brinda buena seguridad, además de esto, sólo requiere de

un puerto TCP o UDP para implementar un túnel por el que circulará el tráfico con lo

que se evita inconvenientes en la configuración de los firewalls por los que deba

cruzar. Este paquete no requiere modificaciones en el kernel, tiene una configuración

muy flexible y se encuentra disponible para una gran variedad de sistemas

operativos, por estas razones es una de las soluciones más empleadas.

Openswan representa la solución IPSec, IPSec es uno de los más antiguos

estándares para VPN, siendo muy seguro y útil cuando se encuentra correctamente

configurado. Esta solución, originalmente llamada FreeS/WAN, requiere de su propio

kernel, pero es ampliamente soportada por casi cualquier dispositivo que soporte

conexiones VPN, ya sea routers, teléfonos, sistemas operativos, entre otros. Sin

embargo su configuración puede volverse demasiado complicada y no puede trabajar

atrás de ciertos tipos de NAT.

Finalmente PoPToP emplea el protocolo PPTP el cual era originalmente respaldado

por Microsoft, pero tiene serios problemas de seguridad. Para su funcionamiento,

básicamente encapsula en un túnel una conexión PPP. Pese a su sencilla

configuración en Windows, sus problemas de seguridad y de conexiones detrás de

ciertos firewalls y NAT hacen que no sea una solución ampliamente usada.

La solución a emplearse será el paquete iptables para filtrado de paquetes y

traducción de direcciones y, para la creación de VPN, la opción que se empleará es

OpenVPN, esto es debido a que dicha solución brinda un alto grado de seguridad con

una configuración no demasiado complicada, además es una solución altamente

flexible y no requiere modificaciones en el kernel del sistema operativo.

El presente servidor virtual se basa en la plantilla de instalación de la VM basada en

GNU-Linux CentOS 5.2, en el que se incluyen los componentes necesarios como

Iptables, Networking y software de Routing y VPN (OpenVPN). El hostname

configurado es: firewallinternet respectivamente pertenecientes al FQDN

firewallinternet.vserver.ec.

La instalación de iptables viene por defecto en las distribuciones de Linux, caso

contrario se puede realizar de la misma manera que se detalla en el punto 4.3.1.2. De

la misma forma, el servicio openVPN se puede instalar añadiendo el paquete en la

administrador de paquetes, empleando el comando yum install openvpn o

simplemente mediante la descarga del paquete de la página del proyecto en

http://openvpn.net/.

Considerando que ya se explicó la configuración del servidor firewallproxy en la zona

de infraestructura, en este punto sólo se detallará la configuración del servidor

firewallinternet.

4.5.5.3.1. Servidor firewallinternet

En este servidor se debe configurar tanto las rutas necesarias como el firewall con

NAT y el servidor de VPN. Primeramente se presentarán las rutas necesarias:

echo 1 >/proc/sys/net/ipv4/ip_forward route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.2.1 route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.0.2.1 route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.2.1 route add -net 192.168.2.0 netmask 255.255.255.0 gw 10.0.2.1 route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.0.2.1 route add -net default gw 172.16.0.2

Espacio de Código 4.56 Rutas del Servidor firewallinternet

Para la configuración del firewall con la traducción NAT se procedieron a configurar

las siguientes reglas de filtrado de paquetes:

# Limpiar reglas del firewall iptables -X iptables -F # Establecer política DROP por default iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # Permitir tráfico en interfaz loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Permitir tráfico interno iptables -A INPUT -i eth0 -j ACCEPT iptables -A OUTPUT -o eth0 -j ACCEPT # Permitir acceso de ciertos mensajes ICMP iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 172.16.0.1 --icmp-type 8 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 172.16.0.1 -d 0.0.0.0/0 --icmp-type 0 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 172.16.0.1 -d 0.0.0.0/0 --icmp-type 8 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 172.16.0.1 --icmp-type 0 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 172.16.0.1 --icmp-type 3 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 172.16.0.1 -d 0.0.0.0/0 --icmp-type 3 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 172.16.0.1 --icmp-type 4 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 172.16.0.1 -d 0.0.0.0/0 --icmp-type 4 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 172.16.0.1 -d 0.0.0.0/0 --icmp-type 11 -j ACCEPT

iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 172.16.0.1 --icmp-type 11 -j ACCEPT iptables -A INPUT -i eth1 -p icmp -s 0.0.0.0/0 -d 172.16.0.1 --icmp-type 12 -j ACCEPT iptables -A OUTPUT -o eth1 -p icmp -s 172.16.0.1 -d 0.0.0.0/0 --icmp-type 12 -j ACCEPT # Permitir conexiones TCP y UDP válidas iptables -A OUTPUT -o eth1 -p tcp -s 172.16.0.1 --sport 1024: -d any/0 --dport :1023 -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 --sport :1023 -d 172.16.0.1 --dport 1024: -j ACCEPT iptables -A OUTPUT -o eth1 -p udp -s 172.16.0.1 --sport 1024: -d any/0 --dport :1023 -j ACCEPT iptables -A INPUT -i eth1 -p udp -s any/0 --sport :1023 -d 172.16.0.1 --dport 1024: -j ACCEPT # Rechazo protocolo IDENTD iptables -A INPUT -i eth1 -p tcp -s 0.0.0.0/0 -d 172.16.0.1 --dport 113 -j REJECT # Enmascaramiento TCP, UDP e ICMP iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 22223 -j DNAT --to 10.0.2.2:22 iptables -t nat -A POSTROUTING -o eth1 -p tcp -s 10.0.2.0/24 --sport 1024: -d ! 10.0.2.0/24 --dport :1023 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth1 -p udp -s 10.0.2.0/24 --sport 1024: -d ! 10.0.2.0/24 --dport :1023 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth1 -p icmp -s 10.0.2.0/24 -d ! 10.0.2.0/24 -j MASQUERADE # Reglas de Forward TCP, UDP e ICMP iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 10.0.2.0/24 --sport 1024: -d ! 10.0.2.0/24 --dport :1023 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p tcp -s ! 10.0.2.0/24 --sport :1023 -d 10.0.2.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p udp -s 10.0.2.0/24 --sport 1024: -d ! 10.0.2.0/24 --dport

:1023 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p udp -s ! 10.0.2.0/24 --sport :1023 -d 10.0.2.0/24 --dport 1024: -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p icmp -s 10.0.2.0/24 -d ! 10.0.2.0/24 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -p icmp -s ! 10.0.2.0/24 -d 10.0.2.0/24 -j ACCEPT #Reglas para abrir algunos puertos iptables -A INPUT -i eth1 -p tcp -s any/0 --sport 1024: -d 172.16.0.1 --dport 22 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 172.16.0.1 --sport 22 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 --sport 1024: -d 172.16.0.1 --dport 53 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 172.16.0.1 --sport 53 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p udp -s any/0 --sport 1024: -d 172.16.0.1 --dport 53 -j ACCEPT iptables -A OUTPUT -o eth1 -p udp -s 172.16.0.1 --sport 53 -d any/0 --dport 1024: -j ACCEPT iptables -A INPUT -i eth1 -p tcp -s any/0 -d 172.16.0.1 --dport 25 -j ACCEPT iptables -A OUTPUT -o eth1 -p tcp -s 172.16.0.1 --sport 25 -d any/0 -j ACCEPT #Reglas para la VPN iptables -A INPUT -i tun0 -j ACCEPT iptables -A INPUT -p udp --dport 1194 -j ACCEPT iptables -A OUTPUT -o tun0 -j ACCEPT iptables -A OUTPUT -p udp --sport 1194 -j ACCEPT iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

Espacio de Código 4.57 Reglas de filtrado de paquetes en el servidor firewallinternet

Finalmente, para la configuración de las VPN se debe primeramente copiar el

directorio easy-rsa que se genera durante la instalación de openvpn dentro del

directorio /etc/openvpn. Se trabajará con este directorio para generar certificados y

llaves necesarios para implementar la VPN.

Para generar el certificado de autoridad del servidor se debe ejecutar los scripts vars,

clean-all y build-ca que se encuentran en /etc/openvpn/easy-rsa. En este punto se

deben responder ciertas preguntas concernientes a la empresa en la que se

empleará el servidor previo a la generación del certificado.

Generating a 1024 bit RSA private key............................................................................................................................++++++.....................++++++writing new private key to 'ca.key'-----You are about to be asked to enter information that will be incorporatedi`ntoyour certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value,Ifyou enter '.', the field will be left blank. ----- Country Name (2 letter code) [KG]:EC State or Province Name (full name) [NA]:Pichincha Locality Name (eg, city) [BISHKEK]:Quito Organization Name (eg, company) [OpenVPNTEST]:vserver Organizational Unit Name (eg, section) []:IT

Common Name (eg, your name or your server's hostname) []:firewallinternet Email Address [me@myhost.mydomain]:administrador@vserver.ec

Espacio de Código 4.58 Generación del certificado de autoridad

Entonces se debe generar el certificado y la clave de encripción para el servidor con

el script build-key-server. Una vez más se pide información parecida a la

anteriormente solicitada. De la misma forma se debe generar certificados para los

equipos que funcionarán como clientes de la VPN.

Una vez generados los certificados se debe generar el parámetro de Diffie Hellman,

ejecutando el script build-dh. Todo lo que se ha generado hasta este momento se

almacena en /etc/openvpn/easy-rsa/keys, una vez terminado este paso se debe

almacenar en la carpeta /etc/openvpn del servidor los archivos de la autoridad (ca.*),

los del servidor (server.*) y Diffie Hellman (dh1024.pem), mientras que en los clientes

se debe copiar los archivos ca.crt y la llave y certificado del cliente.

Entonces se procede a configurar el archivo de configuración del servidor

/etc/openvpn/server.conf:

#Puerto para OpenVPN port1194 #Protocolo que se empleará proto udp #Dispositivo de túnel devtun #Certificado de autoridad ca.crt #Certificado del servidor server.crt #Clave de cifrado del servidor llave.key dh1024.pem #Direcciones que se asignaran a los clientes, el server es .1 server 192.168.2.0 255.255.255.0 #Ruta para que los clientes alcancen la red local del server (56.0/24) push "route 172.16.0.0 255.255.255.0" #Directorio para configuraciones especiales según cliente client-config-dirccd #Ruta para que el servidor alcance los clientes route 10.0.2.0 255.255.255.0 client-to-client push "route 10.0.2.0 255.255.255.0" keepalive 10 120 comp-lzo user nobody

group nobody persist-key persist-tun status openvpn-status.log verb4

Espacio de Código 4.59 Archivo de Configuración del servidor

Finalmente se debe crear un archivo en /etc/openvpn/ccd con el nombre de cada

cliente incluyendo una ruta estática hacia su intranet:

route 192.168.1.0 255.255.255.0

Para el funcionamiento de la VPN también se debe configurar en el lado del cliente el

archivo /etc/openvpn/cliente.conf:

client #Dispositivo de túnel devtun protoudp #Dirección _IP:puerto_servidor_VPN remote190.10.1.25 1194 resolv-retryinfinite nobind# El dispositivo actúa solo como cliente #Las dos siguientes opciones no van en clientes Windows user nobody group nobody persist-key persist-tun ca ca.crt certclient1.crt key client1.key comp-lzo verb 4

Espacio de Código 4.60 Archivo de Configuración del cliente

4.6. PRUEBAS DE LOS SERVICIOS

A continuación se muestran las distintas pruebas realizadas a los servicios

implementados:

4.6.1. ROUTERINTRANET

Figura 4.46: Prueba de enrutamiento desde un equipo de la red interna de la empresa hacia otro de la zona de datos

Figura 4.47: Prueba de enrutamiento desde un equipo de la red interna de la empresa hacia otro de la zona de infraestructura

Figura 4.48: Prueba de enrutamiento desde un equipo de la zona de infraestructura hacia otro de la zona de datos

4.6.2. FIREWALLPROXY

Figura 4.49: Prueba de enrutamiento desde un equipo de la zona de infraestructura hacia otro de la zona desmilitarizada

Figura 4.50: Prueba de enrutamiento desde un equipo de la zona de datos hacia otro de la zona desmilitarizada

4.6.3. DNS INTRANET

Figura 4.51: Pruebas de resolución de nombres de dominio y direcciones IP en los servidores DNS de la Intranet

4.6.4. DHCP

Figura 4.52 Pruebas del servidor DHCP en un cliente Windows.

4.6.5. CORREO ELECTRÓNICO

Figura 4.53 Pruebas al portal de ingreso al Mailempresarial.

Figura 4.54 Prueba de envío de correo electrónico desde d.carrasco@vserver.ec a j.bonilla@vserver.ec y d.carrasco@andinanet.net.

Figura 4.55 Prueba de recepción del correo anterior.

Figura 4.56 Respuesta de correo.

Figura 4.57 Recepción de correo de respuesta.

Figura 4.58 Prueba de Mailgateway con recepción de correo en el dominio @andinanet.net.

4.6.6. BASE DE DATOS

Para crear una base de datos se emplea el comando create database mientras que

para eliminarla se emplea drop. Cuando se genera una base de datos conviene

determinar con que usuario y desde que equipo en la red local, se podrá tener

acceso, así como los privilegios para modificar esta, para esto se emplea el comando

GRANT.

Figura 4.59 Creación de bases de datos y asignación de permisos

Figura 4.60 Prueba de funcionamiento de Samba como servidor de archivos. Se observa las carpetas compartidas a través de la red vistas desde un cliente Windows.

Figura 4.61 Servidor de archivos Samba visto desde un cliente en GNU-Linux.

Figura 4.62 Prueba de upload de archivos al servidor Samba. Se muestra también los archivos disponibles.

4.6.8. SERVIDOR DE DIRECTORIO

Figura 4.63 Ejemplo de búsqueda de una entrada en el directorio

4.6.9. SERVIDORES WEB

Figura 4.64 Portal Web www.vserver.ec

Figura 4.65 Portal Web www.aeie.ec

Figura 4.66 Portal Web viadmin.vserver.ec

4.6.10. FTP

Figura 4.67 Prueba de inicio de sesión del servidor ftp.

Figura 4.68 Archivos desplegados en el servidor ftp.

Figura 4.69 Pruebas de envío de archivos vía línea de comandos desde un cliente ftp en Windows.

4.6.11. IMPRESIÓN

Figura 4.70 Pantalla de administración de cups vía web

4.6.12. COMERCIO ELECTRÓNICO

Figura 4.71 Ventana de Instalación exitosa de Zen Cart

4.6.13. DNS DMZ

Figura 4.72: Pruebas de resolución de nombres de dominio y direcciones IP en los servidores DNS de la Zona Desmilitarizada

4.6.14. FIREWALL INTERNET

Figura 4.73: Prueba de enrutamiento desde un equipo de la zona desmilitarizada hacia una dirección de Internet

CAPÍTULO CINCO

5. ACONDICIONAMIENTO DE LOS SERVIDORES Y

REQUERIMIENTOS DE HARDWARE PARA UN

ÓPTIMO FUNCIONAMIENTO.

5.1. INTRODUCCIÓN

Una vez que se ha analizado el concepto de virtualización, los requerimientos que

tienen las pequeñas y medianas empresas, se ha elegido la herramienta de

virtualización Xen y se ha tratado acerca de la instalación y configuración de los

servicios básicos requeridos, se debe considerar cuales son los requerimientos bajo

los cuales se debe instalar cada servidor virtual y finalmente decidir también cual

vendría a ser el hardware apropiado para alojar a los mismos.

Un correcto dimensionamiento de los requerimientos de los servicios permitirá un

mejor aprovechamiento del hardware disponible, evitando los desperdicios de

capacidad que se dan con servidores no virtualizados, los cuales tienen un promedio

de utilización de entre 10 y 30 por ciento de su capacidad total106

Para lograr el correcto dimensionamiento del servidor, se analizará cada uno de los

servicios a implementarse en sus servidores virtuales poniendo énfasis en los

requerimientos de procesador, memoria, disco y dispositivos de E/S. Con esto se

buscará obtener una configuración de hardware con las características adecuadas

para brindar una solución flexible, escalable y económica.

5.2. DIMENSIONAMIENTO DE LOS SERVIDORES VIRTUALES

(15) (16) (17)

Antes de iniciar con el dimensionamiento de las máquinas virtuales, es muy

importante señalar que, aunque se trata de establecer máquinas virtuales genéricas

106 Según estudios realizados por distintas empresas:

Forrester Research

Software de virtualización para Linux l Xen: www.novell.com/es-es/linux/virtualization

En 2009 la virtualización estará presente en dos de cada tres empresas – Computerworld Investigación de Forrester Research: www.idg.es/computerworld/en-2009-la-virtualizacion-estara-presente-en-dos-d/seccion-ges/noticia-63463

¿Por qué Virtualizar?: www2.hp.com/eNewsletter/download/Por%20que%20virtualizar_pag%2 06.pdf

que funcionen en cualquier PyME, cada empresa tiene sus características y

requerimientos especiales que hacen que los valores con los que se trabajará en el

presente diseño sean susceptibles de ser modificados de acuerdo a los

requerimientos de cada empresa. Esto hará uso de una de las grandes ventajas de la

virtualización con XEN que permite modificar de manera sencilla y rápida los recursos

de hardware asignados a cada máquina virtual.

Finalmente se debe detallar que los principales parámetros en el dimensionamiento

de las máquinas virtuales serán el tamaño del disco duro y la cantidad de memoria

asignada. Esto es debido a que, en el caso del procesador, sus características serán

las mismas que las del procesador físico el cual debe dimensionarse en la máquina

física ya que es la que más capacidad necesita; mientras que, en el caso de los

dispositivos de conectividad, solamente se debe mencionar que todos los servidores

requieren de una tarjeta de red exceptuando el caso de los servidores que cumplan

funciones de ruteo.

5.2.1. CORREO ELECTRÓNICO

El servidor de correo electrónico debe brindar la suficiente capacidad de espacio en el

disco duro como para albergar las cuentas de todos los usuarios de correo, al igual

que la suficiente velocidad y confianza en el acceso a las mismas.

En el caso del disco duro se debe considerar que una PyME en el Ecuador tiene

menos de 100 empleados, además de que se asignará a cada usuario una cuenta de

hasta 1 GB. Es decir que se requiere de un disco duro de por los menos 100 GB.

Como la memoria no se relaciona directamente con la cantidad de usuarios

concurrentes sino con el contenido no se puede calcular un uso por usuario, pero se

puede considerar un uso de 10 KB por conexión107, si se considera que los 100

107 Datos tomados del Anexo L de la tesis: CHÁVEZ BECERRA, DENNYS ROBERTO; MENA VÁSQUEZ, CHRISTIAM MAURICIO; Reingeniería De La Infraestructura De Red Del Data Center De La Empresa Conectividad Global Cía. Ltda. Que Provee Servicios De Intranet A Las Instituciones Del Proyectoquitoeduca.Net, 2009.

usuarios acceden de manera simultánea y que acceden a 5 servicios (correo, revisión

de spam, antivirus, etc.) y que cada usuario realiza 10 peticiones, se tiene:

Se debe mencionar que las características del procesador y memoria que se

recomiendan para un servidor de correo electrónico son un procesador Pentium III o

mejor y con 128 MB de memoria RAM o más108.

5.2.2. BASE DE DATOS

Para brindar un servicio de base de datos se deben de tener en cuenta algunas

características que se desea disponga la base de datos, así por ejemplo, es

importante conocer la cantidad de información a almacenarse y el tipo de información,

al igual que la velocidad y facilidad de acceso a los datos. Todas estas

consideraciones dependen del tipo de base de datos que se vaya a crear y del tipo de

empresa que la requiera.

Esto quiere decir que si la empresa en la que se implementará el servicio es más

grande, requerirá de una mayor base de datos con mayores requerimientos de

capacidad. En el caso del presente proyecto, lo que se busca es crear una solución

flexible que se pueda implementar en un gran número de PyMES distintas, por lo que

se considerará que, pese a que el dimensionamiento de una base de datos es muy

relativo a su uso, es muy factible el correr este servicio en cualquier computador

Pentium con alrededor de 128 MB de memoria RAM y 10 GB de espacio libre.

En cualquier caso el parámetro más importante para obtener un buen rendimiento en

la base de datos de MySQL es la memoria. Con una suficiente cantidad de memoria

RAM se pueden realizar las consultas a una alta velocidad, sobre todo si se considera

que MySQL es un administrador de base de datos especializado para la lectura de

datos.

108 Datos tomados de las páginas http://www.linuxcentro.net/linux/staticpages/index.php?page =ServidorCorreo y http://www.linuxparatodos.net/portal/staticpages/index.php?page=servidor-correo

Para el diseño del centro de datos con el que se trabaja se consideró una base de

datos para 1000 tablas distintas considerando que cada tabla puede llegar a ocupar

hasta 10 MB por lo que se decidió emplear una máquina virtual que disponga de 20

GB de espacio en el disco.

Para la memoria RAM se decidió emplear 512 MB109, debido a que con esta base de

datos trabajará la página web de comercio electrónico por lo que se prevee un alto

número de accesos. Cabe recalcar que de acuerdo a los requerimientos de la

empresa es posible variar estos valores de una manera sencilla mediante el archivo

de configuración de la máquina virtual.

Para el servidor de archivos, al mantener un directorio centralizado de los archivos a

los que acceden los usuarios de la intranet, debe de disponer de un espacio de

almacenamiento relativamente grande, consistente con las necesidades de archivos

centralizados de la empresa, y debe de disponer de una buena velocidad de acceso a

los mismos.

En el caso del diseño presentado en este proyecto se considerará que a cada usuario

coo máximo empleará 1 GB de espacio de almacenamiento por lo que como mínimo

se requiere de un disco duro con capacidad de 100 GB y 256 MB de memoria

RAM110, siendo posible modificar dichos valores en base a las necesidades de la

empresa.

109 Datos tomados en base a la página http://www.linuxparatodos.net/portal/staticpages/index.php ?page=servidor-base

110 Datos tomados en base a la página http://www.linuxparatodos.net/portal/staticpages/index.php ?page=servidor-nfs

5.2.4. FTP

Al igual que en el caso del servidor de archivos, este tipo de servidor requiere de una

buena velocidad de acceso a las archivos que almacena y de una considerable

cantidad de espacio en el disco para almacenar los mismos.

Para el presente diseño se empleará un disco duro de 20 GB y 256 MB111 para la

memoria RAM ya que el servidor FTP se planea usar como un espacio de

almacenamiento adicional en que se colocarán archivos centralizados.

5.2.5. WEB

Un servidor web no tiene demasiados requerimientos de capacidad en lo referente al

hardware, ya que no se necesita de demasiado espacio de almacenamiento ni

memoria para permitir el correcto acceso de los usuarios a los portales web.

Si se considera que la página web tendrá un máximo de 10000 accesos simultáneos

se tiene:

Además se debe considerar que se puede montar un servidor web en cualquier

computador Pentium III con 128 MB de memoria y 8 GB de disco duro. Para el caso

del presente diseño se emplearán 256 MB de memoria y 10 GB de disco duro112.

5.2.6. COMERCIO ELECTRÓNICO

En el caso del servidor de comercio electrónico los requerimientos del servidor son

similares a los de un servidor web, ya que, en la práctica un servidor de comercio

111 Datos tomados en base a la página http://www.linuxparatodos.net/portal/staticpages/index.php ?page=servidor-ftp

112 Datos tomados en base a las páginas http://www.linuxcentro.net/linux/staticpages/index.php ?page=ServidorWebFTP y http://www.linuxparatodos.net/portal/staticpages/index.php?page= servidor-web

electrónico viene a ser un servidor web seguro con un alto número de accesos a una

base de datos.

En el caso del presente proyecto se asignará al servidor 10 GB de capacidad en el

disco duro y 256 MB de memoria RAM. Con esto se logra un excelente rendimiento

del servidor, ya que sólamente requiere un poco más de recursos que un servidor

web común (128 MB de memoria y 8 GB de disco duro, como se observó en el punto

anterior).

5.2.7. DNS

El servicio de resolución de nombres de dominio es uno de los servicios que emplean

pocos recursos de hardware, el acceso a este servidor sólo se da para contestar

peticiones de nombres de dominio o direcciones IP y para retransmitir estas

peticiones a otro servidor en caso de no poder resolverlas.

Como se puede apreciar en el siguiente gráfico, en el que se muestra la utilización de

memoria y CPU del proceso named en un equipo virtual con 256 MB de memoria

RAM y 10 GB de disco duro, la utilización de dichos recursos es mínima y no influye

en el desempeño del equipo.

Figura 5.1 Uso de memoria y CPU por el servicio bind.

5.2.8. DHCP

El servidor DHCP no requiere de grandes espacios de almacenamiento adicionales a

los del sistema operativo, ya que para su funcionamiento solamente emplea un

archivo de configuración. Es decir que puede trabajar con un disco duro de 6 u 8 GB

que es el mínimo recomendado para los sistemas GNU/Linux.

De igual manera el servidor no requiere de demasiadas características de

procesamiento y memoria ya que sólo es accedido en el momento en que los

usuarios se conectan a la red para el envío de los datos necesarios para su conexión.

Se empleará un disco duro de 10 GB con 256 MB de memoria113.

5.2.9. SERVIDORES DE ENRUTAMIENTO Y FIREWALL

En el diseño del centro de datos presentado, se puede apreciar la existencia de tres

firewalls, cada uno de estos cumple funciones de enrutamiento básicas y filtrado de

paquetes. Además de esto el firewallproxy realiza funciones de servidor proxy y NAT

y el firewallinternet realiza funciones de servidor de VPN y NAT.

5.2.9.1. FirewallProxy

Este servidor firewall requiere, además de los servicios de enrutamiento y filtrado de

paquetes básicos, un servicio de proxy. Debido a que el proxy almacena de manera

temporal las páginas web a las que acceden los usuarios, para acelerar la

navegación de los mismos, esto genera que se requiera un espacio de

almacenamiento mayor en comparación con otros servidores como DHCP y DNS. Por

otro lado, en base a valores empleados en otros servidores del mismo tipo114, se ha

concluido que un servidor de este tipo puede funcionar con 256 MB de memoria. Para

el servidor prototipo del presente proyecto se empleará un disco de 100 GB y 512 MB

de memoria.

También es importante señalar que al contrario de los otros servidores, este requiere

conectarse y enrutar a las tres redes existentes en el centro de datos: infraestructura,

113 Datos tomados en base a la página http://www.linuxparatodos.net/portal/staticpages/index.php ?page=servidor-dhcp

114 Cantidad elegida de acuerdo a las consideraciones propuestas en las páginas http://www.linuxparatodos.net/portal/staticpages/index.php?page=servidor-firewall, http://www.linuxparatodos.net/portal/staticpages/index.php?page=servidor-proxy, http://www.linuxcentro.net/linux/staticpages/index.php?page=ServidorPROXY y al foro de http://www.ecualug.org/2007/12/03/forums/requerimientos_de_particiones_y_paquetes_para_un_servidor#comment-27334.

datos y zona desmilitarizada, por lo que es necesario que disponga de tres interfaces

de red.

5.2.9.2. RouterIntranet

Este es el servidor de firewall que menos recursos requiere al implementar solamente

funciones de filtrado de paquetes y enrutamiento básicas. En este caso, se decidió

emplear 10 GB de espacio en el disco y 256 MB de memoria. Para esto se consideró

que este servidor no necesita el almacenamiento que requiere el proxy ni tiene su

carga.

De la misma forma que en el caso del servidor firewallproxy, este equipo también

requiere de varias interfaces de red ya que es el que interconecta las redes de

infraestructura, datos y la red interna de la empresa. Se ha considerado que la red

interna de la empresa tendrá tres subredes distintas para distintas áreas y otra de

administración, por lo que se requerirán seis interfaces

5.2.9.3. FirewallInternet

Finalmente, el servidor de firewallinternet se encarga de brindar los servicios de

filtrado de paquetes, conexiones VPN y el enrutamiento y traducción de direcciones.

Se puede considerar que este equipo brinda varios servicios que no tienen

requerimientos de capacidad demasiado grandes. Este servidor es similar al de

firewallproxy, pero al no brindar el servicio de proxy sino el de VPN no tiene

demasiada demanda de espacio en el disco duro. De hecho, el punto más crítico para

este servidor es el disponer de conexiones de red de calidad ya que por este servidor

accederán a Internet todos los usuarios y por este entrarán todos los clientes y

diferentes sucursales.

Debido a estas características, se decidió brindar a este servidor un disco duro de 10

GB, 512 MB de memoria RAM y dos tarjetas de red, una para la red interna y otra

para la externa. También es importante mencionar que, al ser este el servidor de

enlace con el mundo exterior se le brindará características de balanceo de carga, alta

disponibilidad y tolerancia a fallos mediante la creación de una máquina réplica de

iguales características que entrará en funcionamiento en el momento que el equipo

principal caiga. También se instalará en uno de estos servidores el software de

monitoreo nagios con el que se pretende se facilite la administración de la red.

Para brindar la redundancia del servidor se emplearán paquetes de software

preparados para esto y se requerirá la creación de interfaces de red virtuales en cada

tarjeta de red física del equipo por lo que en total el equipo dispondrá de cuatro

direcciones IP.

5.2.10. IMPRESIÓN

El servidor de impresión cups cumple la función de compartir cualquier impresora que

se tenga configurada en el mismo y que se encuentre a su alcance, ya sea mediante

una conexión directa por un puerto paralelo o USB o una computadora de red.

Esto quiere decir que el servidor debe de soportar la carga que corresponde tanto a la

administración de las impresoras que se estén empleando como al manejo de las

colas de impresión. Sin embargo, se debe considerar que el peso y utilización de

memoria de los drivers de una impresora son mínimos, e incluso si se administra un

número de impresoras muy elevado para una PyME esta carga no representa una

gran cantidad. Es suficiente con emplear 128 MB de memoria RAM y 6 GB de disco

duro para tener en funcionamiento un servidor de impresión para una PyME con un

excelente rendimiento.

Figura 5.2 Uso de memoria y CPU por el servicio cupsd.

5.2.11. DIRECTORIO

Tal como ocurre en servidores como el de base de datos, el dimensionamiento de

este servidor es sumamente relativo al uso que se le dará, siendo lo más importante

la experiencia que se obtenga de pruebas realizadas previamente.

Lo que se recomienda para un servidor de directorio es el trabajar con un sistema

multiprocesador con una capacidad de disco y memoria acorde al número de

entradas y atributos que se quiera almacenar, pudiendo llegar, en el caso de los

directorios de grandes empresas a requerir hasta 2 GB o más de memoria.

Para el caso de un servicio de directorio genérico para una PyME, lo más importante

es el mantener un registro de los empleados con sus respectivas cuentas de correo y

claves. Además, si se considera los datos presentados en la tabla 2.1., en el Ecuador

las PyMES disponen de menos de 100 empleados por lo que el servicio de directorio

no requerirá de demasiados recursos.

Inicialmente se podría iniciar con 20 GB de disco duro y 512 MB de memoria RAM115

y en caso de requerirlo se debería poder ampliar hasta 1 GB sacando provecho de la

facilidad con que se puede añadir memoria a una máquina virtual.

115 Datos tomados en base a la página http://www.linuxparatodos.net/portal/staticpages/index.php ?page=servidor-ldap

5.3. DIMENSIONAMIENTO DEL SERVIDOR FÍSICO

Figura 5.3 Ilustración del Prototipo de Servidor Virtualizado para PyMES.

En teoría el dimensionamiento del servidor físico se debe realizar sumando todos los

requerimientos de los servidores virtuales que dispone, sin embargo, es importante

notar que el dimensionamiento presentado en el punto 5.2. es un dimensionamiento

básico y que aunque esté diseñado para brindar un excelente desempeño a cada uno

de los servicios, se espera el crecimiento de las empresas, por lo que se debe

considerar el dejar considerables reservas de recursos físicos y aprovechar la

facilidad con que se pueden incrementar los recursos asignados a las máquinas

virtuales.

Para el dimensionamiento del servidor físico se tendrá en cuenta los parámetros de:

Mainboard, procesador, memoria RAM, disco duro, dispositivos de conectividad y la

capacidad del enlace de Internet requerido.

5.3.1. PROCESADOR

Considerando que la función del servidor físico es el permitir correr un gran número

de máquinas virtualizadas de manera simultánea, se tiene que seleccionar un

procesador que cumpla con ciertas características para brindar un desempeño

adecuado en el entorno de uso.

Figura 5.4 Logotipo procesador Intel® Core™ 2 Quad.

Las dos principales características que se debe buscar son el ser un procesador de

varios núcleos y el soportar la virtualización por hardware (es decir que debe ser un

procesador Intel VT o AMD-V).

Para el caso del presente proyecto se seleccionó un procesador Intel de cuatro

núcleos (Quad Core) que disponga de la tecnología Intel VT.

Entre las alternativas que cumplen con estos requerimientos se seleccionó a los

procesadores de la familia Intel tanto por su costo en el mercado como por el soporte

técnico, repuestos y disponibilidad de productos que tiene en Ecuador.

Entre los procesadores que cumplen con las características antes descritas se tiene:

Procesador

Máx. Consumo

de Potencia.

Intel® Virtualization Technology

(VT-x)

Precio Estimado Unitario

Intel® Core™2 Quad Processor Q9650 (12M Cache, 3.00 GHz, 1333 MHz FSB)

95 Watts Yes $316.00

Intel® Core™2 Quad Processor Q9505S (6M Cache, 2.83 GHz, 1333 MHz FSB)

65 Watts No $213.00

95 Watts No $163.00

105 Watts Yes $266.00

105 Watts Yes $183.00

Tabla 5.2 Alternativas de procesador con características Intel® Virtualization Technology. Fuente: http://ark.intel.com/ProductCollection.aspx?familyID=28398

Tomando en cuenta el objetivo principal de este proyecto, esto es: implementar un

prototipo de servidor virtualizado que posibilite proveer distintos tipos de servicios de

manera eficiente, flexible, escalable y económica, se selecciona la alternativa de

procesador Intel® Core™2 Quad Q8400 por brindar el soporte necesario de

Virtualization Technology para la virtualización del servidor en base a cuatro núcleos

que pueden actuar independientemente para las distintas máquinas virtuales

implementadas de acuerdo a su requerimiento, brindándole flexibilidad y a la vez que,

gracias a las altas prestaciones de procesamiento permitirá proporcionar un servicio

eficiente y escalable para los ingentes requerimientos futuros de las PyMES. A todo

esto se suma el bus de datos de 1333MHz proporcionado que corresponde al más

alto disponible y que beneficiará en las operaciones realizadas por el procesador. El

Q8400 constituye la alternativa de menor costo entre las seleccionadas

proporcionando una solución lo suficientemente económica.

Finalmente el producto cuenta con 3 años de garantía y además cuenta con el

respaldo técnico de distribuidores de Intel® a nivel nacional lo cual, en caso de

requerimientos urgentes, pueden ser sustituidas partes o elementos necesarios de la

implementación.

5.3.2. MEMORIA

El cálculo de la cantidad de memoria de la que requerirá el servidor físico se puede

calcular sumando las memorias asignadas a cada máquina virtual que correrá de

manera simultánea.

Según el diseño presentado, se disponen de 19 máquinas virtuales que brindan sus

servicios de manera simultánea. Tomando en cuenta las consideraciones de la Tabla

5.1 se obtiene que en total las máquinas virtuales requieren de 6144 MB, es decir que

solamente para el funcionamiento de las máquinas virtuales se requiere de 6 GB.

Además de estos valores se debe considerar la memoria que requerirá el servidor

físico para su correcto funcionamiento y una cantidad de reserva para posibles

incrementos de la misma en determinadas máquinas virtuales que así lo requieran.

Por este motivo se ha considerado la utilización de 8 GB de memoria.

En cuanto a la elección de la memoria RAM, se seleccionará en función de su costo,

garantía, disponibilidad en el mercado y compatibilidad con el respectivo Mainboard.

La disponibilidad en el mercado es de módulos de RAM de 2GB, donde el tipo de

memoria RAM DDR2 es generalizado y sobre el cual se puede encontrar fácilmente

repuestos en caso de ser necesario.

Figura 5.5 Rendimiento de los distintos tipos de memoria RAM. Fuente: http://www.kingston.com/branded/pdf_files/Final_esx3_memory.pdf

Cabe indicar que tecnologías de memoria tipo DDR3, sus costos son todavía

superiores a las existentes DDR2.

Figura 5.6 Memoria RAM Kingston KVR667D2N5/2 2GB

Es así que entre las alternativas de memoria RAM que cumplen con los parámetros

establecidos, se escoge la alternativa RAM DDR2 de 667 MHz o superior, marca

Kingston cuyo costo es razonable y sus prestaciones técnicas se ajustan a los

requerimientos de la implementación. Las características técnicas de la RAM

escogida son:

Kingston KVR667D2N5/2G 2GB 256M x 64-Bit DDR2-667

Clock Cycle Time (tCK) CL=5 3ns (min.) / 8ns (max.) Row Cycle Time (tRC) 54ns (min.)

Refresh to Active/Refresh Command Time (tRFC) 127.5ns

Row Active Time (tRAS) 39ns (min.) / 70,000ns (max.) Single Power Supply of +1.8V (+/- .1V)

Power 2.225 W (operating) UL Rating 94 V - 0

Tabla 5.3 Características Técnicas memoria RAM escogida. Fuente: http://www.valueram.com/datasheets/KVR667D2N5_2G.pdf

5.3.3. DISCO DURO

En el diseño del centro de datos empleados se dispone de 19 máquinas virtuales a

las cuales se decidió asignar distintas capacidades de espacio del disco duro,

requeriendo en total 580 GB. También es importante tomar en cuenta la probabilidad

de que algunos servidores requieran a futuro una mayor cantidad de espacio, por lo

que se puede dejar unos 100 GB adicionales.

También se debe considerar que debido a la forma en que se instalaron los

servidores, empleando máquinas virtuales genéricas, estas también requieren de

espacio en el disco, para estas se ha considerado un espacio adicional de 100 GB.

Finalmente se debe tomar en cuenta el espacio requerido para las instalaciones del

sistema operativo y los paquetes necesarios en el servidor físico al igual que para

posibles futuros servidores que podrían implementarse. Para el software del servidor

físico se recomendaría dejar 10 GB y para las futuras implementaciones 100 GB.

En total, sumando todos los requerimientos se obtendría:

580 GB + 100 GB + 100 GB + 10 GB + 100 GB = 890 GB

Con esto se concluye que se requiere un disco duro de al menos 890 GB de espacio.

La velocidad de escritura de igual manera es un parámetro a considerar, por lo cual

se busca de 7200 RPM para satisfacer la demanda de escritura en los diferentes

servicios implementados.

Figura 5.7 Disco duro Samsung HD103SI de 1TB de capacidad tipo SATA de 7200 RPM.

La alternativa de disco duro que cumple con los requerimientos señalados

anteriormente y que ha sido considerada para el prototipo es la siguiente:

Figura 5.8 Imagen interior del disco duro Samsung HD103SI de 1TB de capacidad tipo SATA de

7200 RPM.

Configuración del disco

Capacity * 1 TB

Interface Serial ATA 3.0 Gbps

Buffer DRAM Size 16 MB

Byte per Sector 512 bytes

Rotational Speed 7200 RPM

Especificaciones de Rendimiento

Average Seek

time(typical)

8.9 ms

Average Latency 5.52 ms

Data Transfer Rate /

Media to/from

Buffer(Max.)

166 MB/sec

Data Transfer Rate /

Buffer to/from

Host(Max.)

300 MB/sec

Drive Ready

Time(typical)

12 sec

Tabla 5.4 Características técnicas del Disco duro seleccionado. Fuente: http://www.samsung.com/global/business/hdd/productmodel.do?group=72&type=61&subtype=78&

model_cd=443&ppmi=1170#

En función de los costos manejados y pensando en el crecimiento de las PyMES en

base al manejo futuro de datos de gran tamaño, se selecciona la alternativa de disco

marca Samsung HD103SI de 1TB de capacidad tipo SATA de 7200 RPM.

5.3.4. DISPOSITIVOS DE CONECTIVIDAD

Los únicos dispositivos de conectividad que se requieren son las tarjetas de red con

los que el servidor se conectará tanto a la red empresarial interna como al Internet.

Debido a la existencia de varias máquinas virtuales, que actúan de manera

independiente, dentro del servidor físico, es importante brindar la mayor velocidad

posible, por lo que se busca el mantener estas dos interfaces (hacia la red interna y

hacia el Internet) separadas y con tarjetas de red de alta capacidad.

En base al diseño del servidor virtualizado presentado en el punto 3.2.1.2, se han

considerado de tres interfaces de red, entre las cuales se reparte la carga en función

del tipo de servicio brindado.

Figura 5.9 Tarjeta de red D-Link DGE-530T - 1Gbps. Fuente: http://www.dlink.com/products/?pid=284

Se seleccionan interfaces de red de 1Gbps en base al soporte que se estará

brindando a un número importante de máquinas virtuales que requieren de constante

salida y entrada de datos tanto con el medio de la Intranet (máximo 100 usuarios ver

punto 2.2) como de Internet (ver cálculo del enlace, punto 5.3.1) a una velocidad 10

veces más rápida que dispositivos Fast Ethernet 10/100; a la vez su precio en el

mercado es cada vez más reducido.

Las interfaces de red seleccionadas son D-Link DGE-530T de 1Gbps:

Especificaciones Técnicas

Standards • IEEE 802.3 10Base-T Ethernet

• IEEE 802.3u 100Base-TX Fast Ethernet

• IEEE 802.3ab 1000Base-T Gigabit Ethernet

• IEEE 802.3x Flow Control

• ANSI/IEEE 802.3 Nway Auto-Negotiation

• IEEE 802.1p Priority Tagging

• IEEE 802.1q VLANs

Features • PCI Local Bus Master 2.1/2.2 Support

• Plug-and-Play Installation

• Supports PCI 2.1/2.2 ACPI Power Management Wake-On-LAN

• Compliant to PC 99 Standard (Magic Packet, LinkChg and Microsoft wake-up frame)

• Independent 2Kb Receive and Transmit FIFOs

• Advanced Cable Diagnostics (Windows Utility)

• Jumbo Frame Support

Network Data Transfer Rate

• Ethernet: 10Mbps (Half-duplex)

• Ethernet: 20Mbps (Full-duplex)

• Fast Ethernet: 100Mbps (Half-duplex)

• Fast Ethernet: 200Mbps (Full-duplex)

• Gigabit Ethernet: 1000Mbps (Half-duplex)

• Gigabit Ethernet: 2000Mbps (Full-duplex)

Drivers Supported

• Windows Server 2003

• Novell Netware 5.x, 6.x ODI driver

• Windows XP

• FTP PC/TCP

• Linux Kernal 2.6.5

• MAC OS 10.2x

Protocol • CSMA/CD

Network Media • Ethernet: UTP Cat3, 4, 5 EIA/TIA-568 100-ohm screened twisted-pair (STP)

• Fast Ethernet: UTP Cat5, EIA/TIA-568 100-ohm screened twisted-pair (STP)

Network Management

• SNMPv1

Tabla 5.5 Características técnicas tarjetas de red adicionales tipo PCI. Fuente: http://www.dlink.com/products/?pid=284

Cabe indicar que, como se verá a continuación, el Mainboard seleccionado posee

incorporado en su estructura una interfaz de red de similares características a las

requeridas; por tal motivo, de las tarjetas de red presentadas antes, 2 serán

adicionadas y 1 será incluida por defecto en la tarjeta madre.

5.3.5. MAINBOARD

Para el dimensionamiento de la tarjeta madre o mainboard, lo más importante es que

cumpla con los requerimientos de compatibilidad con los otros dispositivos de

hardware, es decir que tiene que disponer de todos los slots adecuados para la

conexión con los otros dispositivos.

Debe permitir la conexión con el procesador Intel® Core™ 2 Quad, debe soportar el

trabajar con un mínimo de 8 GB de memoria RAM, debe traer los slots adecuados

para permitir la conexión de dos tarjetas de red y debe trabajar con un disco duro de

al menos 500 GB.

Entre las alternativas que cumplen con estos parámetros se tiene:

MAINBOARD Intel® Desktop Board

DG41RQ

Intel® Desktop Board

DQ43AP

DG33FB

DG33BU

Bus Type FSB FSB FSB FSB

System Bus 1333 MHz

Form Factor MicroATX uATX MicroATX MicroATX

Socket LGA775 LGA775 LGA775 LGA775

Embedded No No No No

Especificaciones de memoria

Memory Types DDR2 DDR2 800/667

DDR2 DDR2

# of DIMMs 2 2 4 4

ECC Memory Supported No No No No

Especificaciones de Gráficos

Integrated Graphics Yes Yes Yes Yes

Graphics Output VGA DVI & VGA VGA VGA

Opciones de Expansión

PCI Support 2 2 3 2

PCI Express Revision 1.1 2.0 2.0 2.0

PCI Express Configurations x16 x16 x16

PCIe x1 Gen 2.x 0 1 3 1

PCIe x4 Gen 2.x 0 0 0 0

PCIe x8 Gen 2.x 0 0 0 0

PCIe x16 Gen 2.x 1 0 1 1

I/O Specifications

USB 2.0 Configuration (Back + Internal)

4+4 4+4 6+6 6+6

# of SATA Ports 4 3 4 4

# of eSATA Ports 0 1 0 0

RAID Configuration 0

# of PATA Ports 1 0 1 1

# of Parallel Ports 1 1 0 0

# of Serial Ports 1 1 1 1

Audio (back channel + front channel)

6-ch 5.1 6-ch 6-ch

Integrated LAN GbE GbE GbE GbE

Firewire N/A N/A IEEE 1394a

IEEE 1394a

Tabla 5.6 Características técnicas de las alternativas de Mainboard para el Prototipo.

De los datos proporcionados en la tabla anterior, se elige a la alternativa Intel®

Desktop Board DG33BU debido a que proporciona fundamentalmente soporte para el

procesador Q8400 seleccionado con el tipo de socket LGA775 a más de tener

soporte adecuado para 4 slots de memoria RAM DDR2 de mínimo 667MHz, así como

también de 2 Puertos PCI para las tarjetas de red adicionales y 1 Puerto PCI-X que

servirá de reserva para expansión de la capacidad del servidor en cuanto a

dispositivos adicionales. Cuenta además con una interfaz de red Gigabit Ethernet,

estando así acorde con los requerimientos señalados anteriormente.

A estas características se suma su bus del datos de 1333MHz así como 4 puertos

SATA que se ajustan perfectamente al Disco Duro seleccionado en los puntos

anteriores.

Mainboard del prototipo: Intel® Desktop Board DG33BU

Finalmente el soporte de Intel® brinda una garantía de 3 años y asistencia técnica en

el país en caso de algún fallo inesperado con elementos sustitutos que se ajusten a

las necesidades del caso.

5.3.6. IMÁGENES DEL PROTOTIPO DE SERVIDOR VIRTUALIZADO

ARMADO

A continuación se presenta imágenes del prototipo armado:

Figura 5.11 Tarjeta Madre con dispositivos de Memoria, Procesador, Interfaces de Red del prototipo.

4 Tarjetas RAM 2GB c/u

Procesador Intel® Q8400

Tarjeta de red incluida Intel® 1Gbps

Tarjetas de red D-Link Adicionales 1 Gbps

4 puertos SATA (HD y DVD ROM

Mainboard Intel® Desktop Board G33BU

Figura 5.12 Memoria RAM instalada.

Figura 5.13 Procesador instalado.

4 módulos de memoria RAM Kinigston KVR667D2N5/2G

Exterior (se observa ventilador) procesador

Intel® Core™ 2 Quad Q8400

Figura 5.14 Dispositivos de red instalados y puertos disponibles.

Figura 5.15 Tarjetas de red instaladas (vista externa).

Tarjetas de red D-Link® DGE-530T - 1Gbps

Puertos PCI

Puertos PCI – EXPRESS

(expansión futura)

Tarjeta de red Intel® integrada - 1Gbps

Tarjetas de red D-Link® integrada - 1Gbps

Figura 5.16 Puertos disponibles del prototipo.

Figura 5.17 Disco duro instalado.

Disco Duro Samsung HD103SI – 1 TB -

Figura 5.18 Fuente de poder instalada.

Figura 5.19 Unidad de DVD instalada.

Figura 5.20 Case del Servidor.

5.4. CÁLCULO DEL ENLACE AL ISP

El cálculo del enlace al proveedor de servicios de Internet corresponde a los

requerimientos de ancho de banda que se tendría para garantizar un ancho de banda

adecuado para la conexión hacia el Internet por parte de toda la empresa.

Par realizar dicho cálculo es necesario considerar todos los servicios que requieren

conexión con una red externa a la intranet de la empresa. Estos servicios son correo

electrónico, acceso a páginas web, descarga de archivos y acceso desde la VPN.

Tomando siempre en cuenta que los valores presentados son de referencia, ya que

los mismos dependen de las necesidades de la empresa en la que se presente la

solución.

5.4.1. ACCESO A CORREO ELECTRÓNICO

Para el cálculo de los requerimientos de ancho de banda para el acceso al correo

electrónico se considerará que en promedio el tamaño de un correo electrónico es de

64 KB y que un tiempo de descarga considerado adecuado para un correo electrónico

es de 30 segundos116.

Entonces se tiene:

5.4.2. DESCARGA DE ARCHIVOS

Para el cálculo de los requerimientos de ancho de banda para la descarga de

archivos se considerará que en promedio las descargas de documentación y archivos

relacionados al ámbito de las empresas tienen alrededor de 2 MB y que estos

archivos son accedidos aproximadamente por dos usuarios simultáneamente, de la

misma forma se considera que el tiempo adecuado para una descarga es

considerado de hasta 4 minutos117.

Entonces se tiene:

Para el cálculo de los requerimientos de ancho de banda para el acceso web se

considerará que en promedio las páginas web tienen un tamaño de 64 KB, son

accedidas por dos usuarios simultáneamente y un tiempo de espera aceptable para la

carga de las mismas es de 30 segundos118.

116 En base a datos tomados de otros proyectos de titulación como el de “Diseño de la Intranet de la empresa MEGAREDES Cía. Ltda.” realizado por los Ing. César Trelles y Ricardo Vallejo.

Entonces se tiene:

5.4.3. ENLACE VPN

Para los cálculos del enlace VPN se considerará que el mismo suele emplearse solo

para la compartición de cierta información puntual o para realizar configuraciones

remotas por lo que se podría considerar su utilización, en los peores casos, similar a

la de la descarga de archivos pero con un uso más espaciado dependiendo de la

empresa en que se lo aplique.

5.4.4. ENLACE AL ISP

El enlace al ISP se obtiene al sumar todas las capacidades requeridas para obtener

un acceso al Internet confiable:

Esto quiere decir que se requiere una conexión a Internet de por lo menos 342 Kbps,

siendo considerado preferible una de 512 Kbps.

CAPÍTULO SEIS

6. PRESUPUESTO DE LA IMPLEMENTACIÓN

PROPUESTA

6.1. PRESENTACIÓN DE COSTOS DEL PROTOTIPO DE

VIRTUALIZACIÓN

En base al estudio realizado en los capítulos anteriores, los requerimientos básicos

para la implementación del Prototipo de Servidor Virtualizado sobre una distribución

del Sistema Operativo Linux para uso en PyMES son:

§ Hardware Físico – Servidor

Éste incluye los elementos hardware que constituyen el Computador de altas

prestaciones basado en la arquitectura x86; esto es:

§ Tarjeta Madre (Mainboard)

§ Procesador

§ Memoria Ram

§ Dispositivos de almacenamiento

§ Tarjetas de red

§ Lectores de DVD, CDROM

§ Case (Incluyendo fuente de energía, ventiladores, teclado,

mouse)

§ Software

Éste elemento incluye los programas necesarios para la implementación del prototipo;

esto es:

§ Sistema Operativo (Costo - Licencias)

§ Software de Virtualización (Costo -Licencias)

§ Software de Servicios (Para la implementación de los servicios

analizados en el capítulo 4)

§ Software de Control (Para la administración del servidor,

antivirus, antispam, etc.)

6.1.1. COSTO DE HARDWARE FÍSICO

En función de los datos obtenidos en el capítulo 5 en el punto 5.3 acerca del

dimensionamiento del hardware físico, a continuación se presentan los costos119 de

los requerimientos para la implementación:

Hardware Descripción Cantidad

Precio

Unitario

Precio

Tarjeta Madre

(Mainboard)

DG33BU 1 118.00 118.00

Procesador Intel® Core™ Quad

Q8400 1 215.00 215.00

Memoria Ram Kingston®

KVR667D2N5/2G 4 28.00 112.00

Disco Duro Samsung HD103SI 1 90.00 90.00

Tarjetas de red D-Link DGE-530T 2 20.45 40.90

Lectores de DVD,

CDROM LG - GH22NP20 1 25.00 25.00

(Inc. fuente de

energía,

ventiladores, teclado,

mouse)

Case Combo Ares 1 39.00 39.00

Tabla 6.1 Costos del Hardware para la implementación del prototipo de Servidor Virtualizado.

6.1.2. COSTO DE SOFTWARE

La finalidad del presente proyecto fue el implementar un Servidor Virtualizado sobre

una distribución de Linux, justamente para salvaguardar los escasos recursos

económicos de las PyMES en cuanto a la adquisición de software licenciado. Esta

119 Costos obtenidos en función de proformas de varios distribuidores. Ver Anexo I.

situación se vio acompañada a lo largo de las configuraciones realizadas de los

servicios, con alternativas de software altamente confiable, de funcionamiento

probado, con soporte en línea y que además sea OpenSource, libre y gratuito (Bajo

licencia GPL). Es así, que los costos incurridos en Software son prácticamente cero,

permitiendo así un ahorro considerable de costos para las PyMES del Ecuador;

siendo así se presenta a continuación el software utilizado en el presente proyecto:

Software Descripción Cantidad Licencia

Sistema

Operativo

Host OS: GNU-Linux CentOS 5.2 1 GPL

Guest OS: GNU-Linux CentOS 5.2 18 GPL

Software de

Virtualización Xen® Hypervisor 3.1 1 GPL

Software de

Servicios

Bind, Dhcp, Sendmail, Squirrelmail,

Squid, OpenLDAP, Samba, CUPS,

Apache, VSFTP, Zen Cart, IPTABLES,

entre otros.

12 GPL

Software de

Control

MailScanner, ClamAV, Webmin,

VNCviewer, Putty (para Windows®),

entre otros.

Tabla 6.2 Software utilizado en la implementación del prototipo de Servidor Virtualizado.

6.1.3. PRESUPUESTO TOTAL

De acuerdo a los puntos anteriores vistos en el presente capítulo, a continuación se

presentan los costos totales de la implementación de Servidor Virtualizado realizada:

Componente Descripción Valor Total

Hardware

Mainboard

Intel® Desktop Board DG33BU

Procesador

Intel® Core™ Quad Q8400

Memoria Ram

Kingston® KVR667D2N5/2G

639,40

Disco Duro

Samsung HD103SI

Tarjetas de red (2)

D-Link DGE-530T

Lector de DVD, CDROM

LG - GH22NP20

Case Combo Ares

Sistema Operativo Host OS: GNU-Linux CentOS 5.2 -

Guest OS: GNU-Linux CentOS 5.2 -

Software de

Virtualización Xen® Hypervisor 3.1 -

Software de

Servicios

Bind, Dhcp, Sendmail, Squirrelmail,

Squid, OpenLDAP, Samba, CUPS,

Apache, VSFTP, Zen Cart, IPTABLES,

entre otros.

Software de Control

MailScanner, ClamAV, Webmin,

VNCviewer, Putty (para Windows®), entre

otros.

TOTAL120 639,40

Tabla 6.3 Costo total Servidor Virtualizado.

En el anexo I del presente proyecto puede encontrarse con mayor detalle los costos

incurridos en la implementación del prototipo de Servidor Virtualizado para PyMES.

120 El costo total referenciado no incluye impuestos.

CAPÍTULO SIETE

7. CONCLUSIONES Y RECOMENDACIONES

7.1. CONCLUSIONES

§ Dentro del ámbito productivo empresarial, el grupo de las Pequeñas y

Medianas Empresas (PyMES) proyectan una especial atención para el

desarrollo económico del país debido a que constituyen aquellas empresas

con grandes posibilidades de crecimiento y expansión pero que debido a sus

limitaciones ocupacionales, financieras o ambas requieren de un mayor apoyo

económico, organizativo, administrativo, de educación, y así también

tecnológico.

§ El panorama socio económico del Ecuador muestra una estructura económica

donde más del 90% de las empresas son pequeñas y medianas (PyMES) las

cuales aportan aproximadamente un 25% de la economía nacional. Tan sólo

en Pichincha se cuentan con aproximadamente 3000 PyMES con grandes

deficiencias en cuanto al acceso a las nuevas Tecnologías de la Información;

esta situación frente al hecho que en el ámbito internacional los países y las

empresas exitosas son aquellas que basan su ventaja competitiva en factores

innovadores y tecnológicos. Estas condiciones limitan el accionar de las

PyMES en Ecuador, necesitando alcanzar altos niveles de competitividad y

productividad a través de varias soluciones económicas que les permita

disponer de la tecnología necesaria para su desarrollo.

§ La productividad y competitividad de las PyMES se ve beneficiada

indudablemente por la introducción de las Tecnologías de Información y

Comunicación (TIC´s) donde cumplen un papel decisivo en el desarrollo

eficiente de la naturaleza del negocio y con ello el objetivo específico de

desarrollo de cada PyMES.

§ Es así que es imperiosa la implementación de canales de información y

comunicación tanto internos como externos para que las PyMES obtengan

una ayuda fundamental en el mejoramiento y automatización de procesos

administrativos, productivos, comerciales, de extensión y crecimiento, etc. y se

posibilite así la apertura de sus mercados ante clientes alrededor del país y el

mundo.

§ Lamentablemente y debido a la naturaleza inicial tanto económica como

organizativa, administrativa y de cultura tecnológica de las PyMES, el acceso a

las TIC´s no es una realidad generalizada. Estos hechos justifican la

implantación de una Política de Estado que brinde mayor apoyo a las PyMES

tendientes a alcanzar objetivos de innovación, desarrollo de tecnología y

emprendimiento mediante la masificación del acceso al uso de nuevas

tecnologías, las TIC´s.

§ En tal virtud es imprescindible vincular fuertemente a las pequeñas y

medianas empresas con un ambiente organizativo en el que el uso de

soluciones tecnológicas de bajo costo y alto rendimiento productivo como el

acceso Internet, correo electrónico, comercio electrónico, etc. sea un hecho

cotidiano que aporte a una mejor gestión de su organización productiva.

§ Por ello, la introducción de una solución económica, de fácil uso y

mantenimiento (pues por añadidura no se cuenta con personal de TI fijo) y por

tanto confiable, segura, y eficaz que permita a las PyMES acceder a las

Tecnologías de la Información y Comunicación, constituye un factor

preponderante a ser implementado en el camino para conseguir su desarrollo

y además como estrategia de supervivencia comercial.

§ Las varias iniciativas del Estado por la introducción del Software Libre, Open

Source y Gratuito así como la mejora sustancial de precio y características del

hardware de uso tradicional, permiten que implementaciones de bajo costo y

alto rendimiento aporten significativamente con la satisfacción de gran parte

de las necesidades y requerimientos tecnológicas de las pequeñas y

medianas empresas (PyMES).

§ La evolución computacional de hardware y software ha dado lugar que los

centros de datos de las organizaciones también evolucionen a través de los

años exigiendo invariablemente la expansión de la infraestructura de TI

mediante un modelo consolidado, evitando la proliferación de servidores

infrautilizados con mayores costes de gestión de la red y menor agilidad y

fiabilidad. Es así que la virtualización toma un papel protagónico

especialmente en la virtualización de servidores reduciendo la proliferación de

éstos, simplificando su gestión y mejorando significativamente su utilización,

así como la agilidad, fiabilidad de la red y la eficacia de la infraestructura de TI.

§ Las soluciones tecnológicas de virtualización, antes casi exclusivas para las

grandes empresas, comienzan a ser presentadas en formato pequeño para

empresas de menor tamaño donde se requiere tecnología con la menor

inversión de recursos económicos (debido a su naturaleza) para su

mejoramiento organizativo y productivo.

§ Es aquí donde los servidores virtualizados toman parte en la escena de las

PyMES ofreciendo un entorno de TI ajustado con mucha mayor precisión a las

necesidades organizacionales y contribuyendo así a la constitución de un

centro de datos más eficiente, manejable, confiable, seguro, disponible y de

menor costo que facilita la operación de estas empresas, acorde con su

estructura y giro del negocio, logrando obtener con ello mayor rédito en el

ámbito de su competencia.

§ Así, los beneficios de la virtualización son grandes; ésta es una tecnología

ecológica que ahorra costos, espacio y recursos, ya que se requiere

únicamente de la implementación de un servidor físico consolidado con lo que

no solamente se genera un ahorro de compra de hardware, sino también de

software, de la mano con el Open Source y Software Libre y gratuito.

§ La implementación de Servidor Virtual, permite que las empresas reduzcan su

consumo energético, gestionen mejor el crecimiento de los sistemas y

consigan reducciones en el coste total de propiedad. Esto se debe

fundamentalmente a que la virtualización de servidores permite múltiples

servidores en un sólo equipo, de forma que un único servidor ejecuta varios

sistemas operativos y aplicaciones del negocio. A todo esto se añade ahorros

en costos de ventilación, mantenimiento, y se suman características

tecnológicas de flexibilidad, escalabilidad, alta disponibilidad, redundancia,

tolerancia a fallas y reducido tiempo de recuperación ante desastres.

§ Existe una gran variedad de tipos de virtualización, cada uno de los cuales

tienen sus propias ventajas y desventajas, y algunos son específicos para

determinadas aplicaciones; la elección del tipo de virtualización y herramienta

a utilizarse depende en gran parte del uso que se le dará. En el caso del

presente proyecto la mejor opción fue la Paravirtualización y Virtualización

Híbrida provista por la herramienta Xen.

§ Con la virtualización se consigue un mayor aprovechamiento físico de los

equipos a través de la implementación de varias máquinas virtuales por un

solo equipo real, sin que con ello signifique una reducción de su rendimiento

con una adecuada planificación.

§ Los recursos de hardware virtual que necesariamente requieren las VM´s son:

procesador, memoria, disco duro y un dispositivo para conexión, es decir una

tarjeta de red. En la configuración de servidor realizada, el resto de

dispositivos de hardware existentes no son requeridos y se realiza una

configuración mínima que favorece a un mejor rendimiento del sistema.

§ Aunque la mayoría de servidores no requieren de una interfaz gráfica, es decir

se pueden instalar y configurar mediante línea de comandos con una conexión

segura, existen servidores como por ejemplo el de Comercio Electrónico que

están diseñados para ser instalados y configurados mediante una GUI.

§ Cada empresa tiene distintos requerimientos tecnológicos por lo que cada

caso se debe analizar por separado, debiendo considerarse qué servicios son

realmente necesarios y cuáles no son requeridos, de esta forma es posible

que se requiera un mayor o menor número de servidores.

§ Es de suma importancia el brindar un alto grado de seguridad no solo a los

servidores virtuales sino sobre todo al servidor físico, ya que si un atacante

consigue acceso a este servidor podría manipular los archivos de

configuración de todos los servidores virtuales además de ser capaz de

encenderlos o apagarlos, además, cualquier daño que se haga al servidor

afectaría a todos los equipos.

§ Aunque un atacante consiga acceso al servidor físico, eso no significa que

podrán acceder a cada máquina virtual individualmente ya que cada equipo

tiene sus propias protecciones.

§ Aunque todos los equipos virtuales se encuentren dentro de un mismo equipo

físico, cada unos de ellos es lógicamente independiente y puede ser

considerado como un equipo completamente diferente.

§ Un servidor proxy ayuda a las empresas a controlar los contenidos a los que

pueden acceder sus empleados para evitar el desperdicio de recursos y

aumentar la productividad. Además, el almacenamiento en caché de las

paginas previamente accedidas permite a los usuarios una percepción de

mayor velocidad de navegación.

§ Aunque la implementación inicial de un prototipo de servidor virtualizado

pueda resultar complicada por la cantidad de instalaciones de servidores a

realizar y la cantidad de servicios a configurar, una vez concluida la

implementación del prototipo, este puede emplearse como base para la

creación de un sinnúmero de servidores virtualizados que solo requerirán

pequeñas modificaciones para su comercialización.

§ El hecho de aplicar la Virtualización de Servidores para las PyMES sobre

hardware convencional (x86) y una distribución de Linux, no es más que un

factor adicional que esperamos contribuya a la adopción de infraestructuras

tecnológicas que brinden un centro de datos con altas características de

eficiencia y eficacia pero a la vez accesible económicamente.

§ Es muy factible, para un proyecto posterior, la implementación de una interfaz

gráfica de administración unificada de los servidores virtuales y sus

respectivos servicios, a fin de que el producto final pueda ser todavía más

amigable para el usuario final y la distribución de la plataforma de

virtualización sea cada vez más acogida por las PyMES que no cuentan con

personal fijo de Sistemas. Las herramientas de administración a utilizarse

pueden ser: Webmin, Virtualmin, Putty (SSH), VNC.

§ Es así que en el presente trabajo de investigación se realizó el análisis, diseño

e implementación de una solución de Servidor Virtualizado con software Open

Source, Libre y Gratuito para así aprovechar esta serie de factores

tecnológicos, económicos, entre otros, y de esta manera incluir a las

Pequeñas y Medianas Empresas -PyMEs- en un nuevo ámbito organizativo

donde las Tecnologías de Información (TI) constituyen un factor trascendental

en el incremento de su productividad.

§ Finalmente con este proyecto de titulación se pudo contribuir de manera

técnica desde nuestro campo de acción – la Electrónica y Redes de la

Información - al crecimiento productivo de las pequeñas y medianas empresas

ecuatorianas y con ello al desarrollo productivo del país.

7.2. RECOMENDACIONES

§ Para la implementación de cualquier tipo de servidor, es importante

primeramente establecer los requerimientos de los posibles usuarios del

mismo, elegir la herramienta adecuada para su implementación y probarla,

entonces se puede proceder a dimensionar el servicio e implementarlo en el

sistema final.

§ Es recomendable el uso de procesadores que soporten virtualización por

hardware, es decir procesadores Intel VT o AMD-V, ya que aunque no sea

necesaria esta característica para la paravirtualización, es una característica

requerida para la virtualización de sistemas operativos no modificados, lo que

es necesario para poder instalar sistemas operativos propietarios como

Windows.

§ Es recomendable el mantener el servidor en un sitio seguro, sólo accesible por

personal autorizado, ya que aunque se dispongan de firewalls para proteger al

equipo de accesos indeseados a través de la red, si un atacante puede

acceder al equipo físicamente, la protección se ve seriamente reducida.

§ Es una buena práctica el mantener un respaldo completo y actualizado de

todas las máquinas virtuales con las que se trabaja, de esta forma, en el caso

de que alguna presente problemas, se puede migrar el servidor virtual rápida y

eficazmente. El uso de RAID es recomendable para un proyecto futuro y

mantener la información respaldada en espejo en varios discos duros (aunque

se encarece la implementación del servidor pero se respalda la información).

§ Se debería de disponer de un método de acceso al servidor via WEB segura,

para permitir a un administrador de equipo realizar configuraciones de manera

remota, sin embargo este acceso debe estar altamente protegido y no permitir

conexiones en puertos típicos.

§ Al momento de seleccionar herramientas de código abierto es importante el

buscar herramientas que dispongan de mucha documentación ya que no

siempre se puede obtener soporte técnico rápido por parte de las empresas

que las distribuyen.

§ En la configuración de un servidor de correo es importante el considerar que la

mayoría de los servidores de correo como Hotmail o Gmail tienen grandes

protecciones para evitar la llegada de correo SPAM por lo que es posible que

dichos servidores no reciban correos de dominios recientemente

implementados hasta que el dominio del nuevo servidor entre en listas blancas

y deje de ser considerado correo no deseado.

§ Es recomendable el disponer de un equipo físico de respaldo con los

servidores virtuales listos para usarse, este equipo puede tener prestaciones

menores que el servidor principal ya que, en caso de que se llegue a usar, su

uso será temporal.

CAPÍTULO OCHO

8. ANEXOS

ANEXO A

TECNOLOGÍA DE PROCESADORES INTEL® VT Y AMD®-V

ANEXO A TECNOLOGÍA DE PROCESADORES INTEL® VT Y AMD®-V

Fuente: Intel Technology Journal, Volume 10, Issue 3, 2006.

Intel® Virtualization Technology: Extending Xen* with Intel® Virtualization

Technology, Intel® Virtualization Technology: Hardware Support for Efficient

Processor Virtualization

http://www.amd.com/us/products/technologies/virtualization/Pages/virtualization.aspx

VT INTEL (IVT)

INTEL VIRTUALIZATION TECHNOLOGY

La tecnología de virtualización de Intel® permite a un CPU actuar como si fueran

varios procesadores trabajando en paralelo, permitiendo así que varios sistemas

operativos se ejecuten al mismo tiempo en un mismo equipo.

Intel VT es una colección de tecnologías para procesadores que permiten la

ejecución de Sistemas Operativos huéspedes (Guest) no modificados en los Intel VT-

enhanced VMMs.

VT-x incrementa la arquitectura IA-32 con dos nuevas formas de operación del CPU:

VMX root-operation y VMX non-root operation. VMX root-operation está destinado a

ser usado por un VMM, y su comportamiento es muy similar al de la IA-32.

Sin VT-x. VMX non-root operation proporciona la alternativa de entorno IA-32

controlado por un VMM y diseñado para soportar una máquina virtual. Ambas formas

de operación soportan los cuatro niveles de privilegio (0-3), permitiendo que el

software del huésped funcione al nivel de privilegios previstos, y proporciona un

VMM con la flexibilidad de utilizar varios niveles de privilegio.

Es así que VT-x permite que el software huésped se ejecute en el nivel de privilegio

para el que fue diseñado.

AMPLIANDO XEN CON INTEL VT

La arquitectura Xen 3.0 tiene un kernel de hypervisor pequeño que se ocupa de la

virtualización del CPU, la memoria y los recursos de E/S críticos, como el controlador

de interrupciones.

Dom0 es un Linux paravirtualizado que tiene acceso privilegiado a todos los

dispositivos E/S en la plataforma y es una parte integral de cualquier sistema basado

en Xen.

Cuando Intel VT se utiliza, dominios totalmente virtualizados pueden ser creados para

ejecutar sistemas operativos huéspedes sin modificaciones. A estos dominios

completamente virtualizados se les da el nombre de HVMs (hardware-based virtual

machines). Xen presenta a cada HVM huésped, una plataforma virtualizada que se

asemeja a una plataforma clásica PC/server con un teclado, ratón, visualización de

gráficos, discos, disquetes, CD-ROM, etc

Esta plataforma virtual de apoyo es proporcionada por el módulo virtual de

dispositivos de E/S.

Figura 8.1 Arquitectura de Xen e Intel® VT.

La Tecnología de virtualización de Intel está disponible para todos los procesadores

Pentium 4 6x2, Pentium D 9x0, Xeon 3xxx/5xxx/7xx, Intel Core e Intel Core 2, Intel

Core 2 Quad y superiores.

La Tecnología de Virtualización Intel® (Intel® VT) exigen un sistema de computador

con un procesador, chipset, BIOS, habilitando el software y/o el sistema operacional,

los controladores de dispositivos y aplicaciones, creados para esos recursos. El

desempeño varía, dependiendo de su configuración.

VIRTUALIZACIÓN AMD (AMD-V)

AMD – V es la tecnología para la arquitectura de 64 bits x86 de virtualization y se la

referencia por el nombre en clave "Pacífica".

Los procesadores AMD que usan Socket AM2, Socket S1 y Socket F incluyen AMD-

En conjunto con la arquitectura de Conexión Directa proporciona un enfoque

equilibrado para contribuir a mejorar el rendimiento de virtualización, permitiendo así

que funcionen más máquinas virtuales por servidor. AMD-V™ reduce los gastos

operativos al interceptar de manera selectiva instrucciones destinadas a entornos

huésped.

La Arquitectura de Conexión Directa ayuda a los sistemas huésped a funcionar casi a

velocidad nativa. Además el controlador de memoria integrado compatible con

virtualización proporciona un aislamiento eficaz de la memoria de la máquina virtual

Los procesadores que disponen de ésta tecnología son: AMD Athlon ™, AMD

Phenom ™, AMD Phenom II, AMD Athlon ™ y AMD Opteron ™.

Entre las diferentes alternativas de la familia Intel® que proporcionan asistencia de

virtualización se referencian las siguientes con mayor detalle.

Intel® Core™ i7-

860 Processor (8M Cache, 2.80 GHz)

Intel® Core™2

Quad Processor Q8400 (4M Cache, 2.66 GHz, 1333 MHz FSB)

Intel® Core™2 Duo

Processor E6400 (2M

Cache, 2.13 GHz, 1066 MHz FSB)

Intel® Pentium® Processor E6500 (2M

Cache, 2.93 GHz, 1066

Intel® Pentium® 4

Processor 662 supporting HT

Technology (2M Cache,

3.60 GHz, 800 MHz FSB)

Processor Number i7-860 Q8400 E6400 E6500 662

# of Cores 4 4 2 2 1

# of Threads 8 4 2 2 2

Processor Base

Frequency 2.8 GHz 2.66 GHz 2.13 GHz 2.93 GHz 3.6 GHz

Max Turbo Frequency 3.46 GHz

Cache 8 MB Intel®

Smart Cache

4 MB L2 Cache

2 MB L2 Cache

Bus/Core Ratio 21

8 11 18

Bus Type DMI FSB FSB FSB FSB

System Bus 2.5 GT/s 1333 MHz 1066 MHz 1066 MHz 800 MHz

FSB Parity

Instruction Set 64-bit 64-bit 64-bit

64-bit

Instruction Set Extensions SSE4.2

Embedded No No Yes Yes No

Supplemental SKU No No No No No

Processing Die Lithography 45 nm 45 nm 65 nm 45 nm 90 nm

Max TDP 95 W 95 W 65 W 65 W 115 W

VID Voltage Range

0.8500V - 1.3625V

0.850v - 1.3625v

0.85V – 1.3625V

1.2V-1.4V

# of Processing Die

Transistors 774 million 456 million 167 million 228 million 169 million

Sockets Supported LGA1156 LGA775

LGA775, PLGA775

LGA775 PLGA775

Halogen Free Options

Available Yes Yes No Yes No

Intel® Virtualization Technology

(VT-x)

Yes Yes Yes Yes Yes

Intel® Virtualization

Technology for Directed I/O

(VT-d)

1ku Bulk Budgetary

Price $284.00 $163.00 $183.00 $84.00 $80.00

Tabla 8.1 http://ark.intel.com/Compare.aspx?ids=41316,38512,27486,27249,42805,

ANEXO B

ESTADO DE LAS TIC´S EN ECUADOR

ANEXO B ESTADO DE LAS TIC´S EN ECUADOR

Fuente: “LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES

EN LA COMPETITIVIDAD DE QUITO” Pág: 34

Elaborado por: Santa Fe Associates International

Consultores: Econ. Hernando López Guerrero

Ing. Hugo Carrión Gordón

Desde el año 2000 la Economist Intelligence Unit ha venido elaborando e “e-

Readiness Rankings”, que es un indicador del ambiente propicio para hacer uso y

beneficiarse de las TIC, el mismo que se lo construye a partir de criterios cuantitativos

organizados en seis categorías que miden los diferentes componentes del desarrollo

económico, político, social y el tecnológico de cada país. El criterio de la conectividad

es el que tiene el mayor peso (25%); los restantes van desde el 20% al 5% en el

indicador.

En la siguiente tabla se presenta los indicadores para varios países de Latinoamérica

y su posición, para los años 2005 y 2006:

Tabla 8.2 Utilización de las TIC´s en América Latina. Fuente: “Las Tecnologías de la Información

y las Comunicaciones en la competitividad de Quito” Pág: 34. Econ. Hernando López Guerrero,

ANEXO C

FORMULARIO DE ENCUESTA PARA LA DETERMINACIÓN DE LAS TIC´S

EN LA EMPRESA

ANEXO C FORMULARIO DE ENCUESTA PARA LA DETERMINACIÓN DE

LAS TIC´S EN LA EMPRESA

Fuente: “LAS TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES

EN LA COMPETITIVIDAD DE QUITO”

Elaborado por: Santa Fe Associates International

Consultores: Econ. Hernando López Guerrero

Ing. Hugo Carrión Gordón

Rama de actividad

1. ¿A qué rama de actividad se dedica su empresa?

• Textiles y confecciones

• Madera

• Alimentos y Bebidas

• Metalmecánica

• Gráfico

• Químico

• Cuero y Calzado

• Otro______________________

2. Tamaño

¿Cuántos empleados tiene?

________________________

3. ¿Exporta?

• Si

• No

4. Si exporta, ¿hacia qué mercados lo hace?

• Estados Unidos

• Unión Europea

• Asia

• Colombia

• Perú

• Otros países de América Latina

Infraestructura

5. ¿Cuántas PC tiene en su empresa?

_______________

6. ¿Qué sistema operativo utiliza mayoritariamente en su empresa?

• Windows

• Linux

• Macintosh

• Otro_____________________

7. La empresa dispone de red LAN:

• Alámbrica

• Inalámbrica

• Ninguna

• Ambas

8. ¿Tiene un departamento de sistemas?

• Si

• No

9. ¿Cuántas personas conforman el área de sistemas?

___________

Conectividad

10. ¿Su empresa tiene Internet?

• Si

• No

11. ¿Qué tipo de conexión tiene contratada

Dial-up?

• Dial-up (por teléfono)

• Dedicada ADSL

• Dedicada por Cable

• Dedicada Satelital

• Otra__________________

12. ¿Si tiene conexión dedicada, de que velocidad dispone?

• 64 Kbps

• 128 Kbps

• 256 Kbps

• 528 Kbps y más

Sitios web

13) ¿Tiene sitio web institucional?

• Si

• No

14) Si dispone de sitio web, ¿cuál es su dominio?

________________________

15) ¿Para qué utiliza el sitio web?

• Para dar información general

• Promocionar el catálogo

• Vender por internet (comercio electrónico)

• Otros_______________

TIC y la gerencia

16) ¿Cuánto conoce la gerencia acerca de las TIC

• Poco

• Algo

• Mucho

17) Cuál es su dirección de correo electrónico?

___________________

18) ¿Con qué frecuencia accede al Internet?

• Diariamente

• Semanalmente

• Mensualmente

• No lo utiliza

19) ¿Considera a Internet una herramienta básica de gestión?

• Sí

• No

20) ¿Para que utiliza Internet?

• Leer noticias (nacionales e internacionales)

• Buscar información de negocios

• Buscar nuevos mercados

• Enviar y recibir mensajes

• Otros usos

Uso de TIC en la empresa

21) ¿Con qué tipo de sistemas de información cuenta la empresa?

• Contabilidad

• Inventarios

• Recursos Humanos

• Manufactura

• Sistemas de Información Gerencial

• Otros______________________

22) ¿Utiliza software especializado para diseño de productos?

• Sí

• No

23) ¿La empresa para qué usa el internet?

• Servicios bancarios y financieros

• Formación y aprendizaje

• Observar comportamiento mercado

• Recibir productos digitales

• Observar el comportamiento del mercado y la competencia

• Servicio de postventa

• No usa

24) ¿Con qué servicios de seguridad cuentan?

• Software de protección (antivirus)

• Backup de datos

• Mecanismo de autenticación

• Sistemas de encriptación

• No tiene

ANEXO D

ERP DE SOFTWARE LIBRE

ANEXO D

ERP DE SOFTWARE LIBRE

Fuente: “PLANIFICACIÓN DE RECURSOS EMPRESARIALES”

http://es.wikipedia.org/wiki/Planificaci%C3%B3n_de_recursos_empresariales#ERP_d

e_software_libre_.28orden_alfab.C3.A9tico.29

· Adempiere es un proyecto guiado por la comunidad que desarrolla y soporta

una solución de código abierto para negocios del mismo nombre. Ofrece las

funcionalidades de planificación de recursos empresariales (ERP),

administración de la relación con los clientes (CRM) y administración de la

cadena de suministro SCM. Basado originalmente en Compiere, es totalmente

libre de tecnologías propietarias, integrando iText para la generación de

ficheros PDF y soportando la base de datos PostgreSQL. Se encuentra en

fase plenamente funcional. Adempiere está licenciado bajo GPLv2 y cuenta

con soporte comunitario y comercial.

· AbanQ es un ERP modular disponible para Linux, MAC OS X y Windows

2000/NT. Incluye su propia plataforma de desarrollo rápido para adaptar la

aplicación. Actualmente existen en continuo desarrollo módulos integrados

para facturación, almacén, gestión de tesorería, contabilidad financiera,

talleres de automoción, formación, tpv, control de producción (MRP) y además

soporte completo para códigos de barras. AbanQ (ex FacturaLUX1 ) es

software libre, aunque no gratuita, dado que se vende con licencia GPL. Existe

una versión lite, la cual no incluye algunos módulos.

· CK-ERP es un ERP que incluye administración de la relación con los clientes

(CRM). De código abierto, consta de veinte módulos o aplicaciones que

incluyen facilidades para la gestión de la contabilidad de la empresa, pagos,

ingresos, pedidos u órdenes de compra, gestión de ventas, cotizaciones

recibidas, gestión del punto de venta, gestión de recursos humanos o

personal, gestión de nóminas, gestión de contactos, entre otros. Su interfaz

online, es bastante simple pero es fácilmente adaptable a las necesidades de

cualquier empresa. El sistema debe estar instalado en algún sistema operativo

que no sea Microsoft Windows, como Linux, Solaris, FreeBSD, OpenBSD, PC-

BSD, NetBSD, etc. Pero los clientes pueden estar en cualquier sistema

operativo.

· Compiere es un ERP de software libre realizado para el mercado anglosajón,

por lo que encaja en muchas de las necesidades legislativas europeas e

hispanoamericanas. Necesita tecnología propietaria para funcionar,

concretamente ciertas librerías de generación de ficheros PDF usadas

internamente; y la máquina virtual y bibliotecas de Sun Microsystems. Se

encuentra en fase plenamente funcional. Compiere está desarrollado bajo la

licencia pública Compiere (CPL), que permite el paso a privativo de dicho

software transcurridos dos años desde su fecha de lanzamiento. Es una

solución 100% Java sobre base de datos Oracle, con servidor de aplicaciones

JBoss.

· GNUe. Es un conjunto de aplicaciones al estilo de FacturaLux, también con

licencia GPL, que intentan suplir las necesidades de un ERP. Por estructura y

diseño puede ser considerada un ERP al uso, ya que persigue la integración,

modularidad y adaptabilidad. Cada proyecto se desarrolla completamente por

separado y se enlaza posteriormente al resto, manteniendo una estructura

común central.

· Openbravo es un ERP desarrollado como software libre y basado

íntegramente en web. Está basado en una versión antigua de Compiere con

quien no mantiene compatibilidad actualmente. Dispone de soporte para

bases de datos PostgreSQL y Oracle. Se encuentra disponible en español y

actualmente se preparan localizaciones en varios otros idiomas. No dispone

de clientes de utilización que no sean a través de navegador web.

· OpenERP. Es un ERP, basado íntegramente en la licencia pública GPL y

libremente descargable. Aunque desarrollado inicialmente en Bélgica, existe

traducción al español. OpenERP está orientado al uso en las PYME, aunque

dispone de módulos como gestión de proyectos o estadísticas, más habituales

de empresas de mayor tamaño. OpenERP se encuentra en estado funcional

sobre Linux y Windows, con más de 350 módulos en desarrollo. OpenERP

internamente usa un modelo de flujos de trabajo (workflow), con arquitectura

en tres capas. Está desarrollado en Python, PyGTK y sobre PostgreSQL, y

también tiene clientes en librería qt y un frontend web basado en TurboGears.

GestiCAM es una versión localizada en español de este ERP, promocionada

bajo Molinux, una distribución regional de Linux española .

· openXpertya es un ERP de código abierto en español, bajo el patrocinio del

Principado de Asturias y por tanto, especialmente adaptado para la legislación

y el mercado español e hispanoamericano. Incluye solución de CRM y

comercio electrónico a tres niveles (B2B, B2C, EDI) así como de todos los

módulos necesarios para su consideración como un ERP, incluyendo gestión

de proyectos, gestión de campañas, marketing, puntos de venta remotos y

descentralizados, utilización por todos los niveles de una franquicia, etc.

openXpertya se encuentra en fase plenamente funcional. Todo el código de

openXpertya está desarrollado en J2EE por lo que es multiplataforma

(independiente del sistema operativo a nivel de servidor y de cliente) y está

desarrollado en tres capas. La capa de la base de datos es independiente

desde la versión 2.0, anteriormente estaba limitada a trabajar sobre Oracle.

Todo el código de openXpertya es libremente descargable y está basado en la

licencia propia LPO, traducción legal de la CDDL (original de SUN) al español,

y con posibilidades de re licenciamiento bajo virtualmente cualquier otra

licencia de software libre y expresamente bajo LGPL.

· Xendra es un ERP de código abierto, licenciado bajo GPL y adaptado a la

legislación y el mercado peruanos. Ofrece funcionalidades de planificación de

recursos empresariales (ERP), administración de la relación con los clientes

(CRM) y administración de la cadena de suministro (SCM). Basado

originalmente en Adempiere, pero enfocándose a JBoss como servidor de

aplicaciones y PostgreSQL como base de datos. Tiene soporte comunitario y

comercial.

ANEXO E

LA VIRTUALIZACIÓN PASO POR PASO – RECOMENDACIONES DE

HEWLETT PACKARD

ANEXO E LA VIRTUALIZACIÓN PASO POR PASO – RECOMENDACIONES DE HEWLETT PACKARD

Fuente: Soluciones de virtualización con servidores HP ProLiant

http://www.asac.as/web/upload/ponencias/HP-Blade_Virtualizaci%C3%B3n.pdf

A continuación se presentan las recomendaciones de HP para la virtualización de

servidores seguida en el presente proyecto. Cabe indicar que se han adoptado las

recomendaciones aplicables al proyecto, es decir considerando la implementación del

servidor virtualizado en un ambiente donde no se cuenta previamente con solución de

Fase I Estudio Fase II Instalación y

migración Fase III Operaciones

ü Identificar candidatos

para la virtualización.

ü Recopilar los datos de

rendimiento del entorno

actual.

ü Determinar la plataforma

hardware apropiada:

Tipo de servidor

Almacenamiento

Redes.

ü Determinar las

aplicaciones que son

susceptibles de funcionar

en una máquina virtual.

ü Preparar sus racks

(servidores, redes,

almacenamiento).

ü Instalar el sistema

operativo y/o la

tecnología de

virtualización sobre cada

servidor físico.

ü Instalar las nuevas

aplicaciones en las

ü Reutilizar o reciclar los

sistemas retirados.

ü Utilizar una herramienta

que pueda monitorizar

ambas máquinas, físicas

y virtuales.

ü Implementar una solución

que controle las posibles

vulnerabilidades y

gestione

automáticamente las

tareas críticas de

seguridad.

ü Auditar la satisfacción del

usuario final y los efectos

del cambio a través de

una herramienta de

gestión del nivel de

servicio.

Tabla 8.3 Fases de la implementación de la solución de Servidor Virtualizado. Fuente: http://www.asac.as/web/upload/ponencias/HP-Blade_Virtualizaci%C3%B3n.pdf

Para identificar a los equipos que son buenos candidatos para la virtualización se

tienen las siguientes recomendaciones proporcionadas por Microsoft y el libro

Professional Xen® Virtualization:

IDENTIFICACIÓN DE LOS CANDIDATOS PARA VIRTUALIZACIÓN RECOMENDACIONES MICROSOFT Y XEN

Fuente: Professional Xen® Virtualization: Overview of Virtualization Pág.: 24

Wiley Publishing, Inc.

Conversión de máquinas físicas a máquinas virtuales en VMM.

http://technet.microsoft.com/es-es/library/cc764232.aspx

El informe Candidatos para virtualización sirve para identificar servidores poco

usados y mostrar valores medios para un conjunto de contadores de rendimiento

solicitados habitualmente para CPU, memoria y uso del disco, configuraciones de

hardware, como la velocidad del procesador, el número de procesadores y la

memoria RAM total.

Establecimiento de prioridades en los candidatos para virtualización:

§ Equipos poco usados no fundamentales para la empresa. Los servidores web

son buenos candidatos.

§ Equipos con hardware obsoleto o incompatible que es necesario sustituir.

§ Equipos poco usados que hospedan aplicaciones internas no críticas.

§ Equipos de mayor uso que hospedan aplicaciones internas no críticas.

§ El resto de equipos de poco uso.

El objetivo de los esfuerzos de la virtualización es la consolidación de múltiples

servidores físicos en una plataforma de hardware específico.

Para abordar la cuestión de por dónde empezar por identificar específicas

máquinas físicas a virtualizar, un mejor punto de partida es considerar el software de

que necesita de apoyo. La identificación de hardware antiguo, periféricos

sistemas de almacenamiento, y así sucesivamente es un segundo paso excelente en

el proceso de planificación, proporcionando un excelente mecanismo de control de

los equipos físicos cuyo software va a pasar a las máquinas virtuales.

Sin embargo, generalmente es más eficaz comenzar el proceso de planificación de la

virtualización mediante la identificación del software que se necesita y sus requisitos,

incluyendo los requisitos de hardware, sistema operativo, etc.

La siguiente lista muestra la información que se sugiere recoger para cada una de las

aplicaciones que se está pensando en mudarse a una máquina virtual.

§ La aplicación y la versión - el nombre y número de versión específica de la

aplicación. Cada versión de una aplicación puede tener específicos requisitos

del sistema operativo, el uso de hardware específico, y así sucesivamente.

§ Sistema operativo y la versión actual - El sistema operativo bajo el cual la

aplicación está actualmente en ejecución.

§ Los parches del sistema operativo o Service Pack - Cualquier parches

específicos que se han aplicado al sistema operativo.

§ Otros sistemas operativos compatibles - Otros sistemas operativos y la versión

asociada de versión en que la aplicación se supone que se ejecutan.

§ Privilegios necesarios y / o usuarios – Todos los privilegios necesarios para la

instalación y ejecución, incluyendo cualquier usuario específico y / o grupo

para que el software pueda ejecutarse.

§ Hardware asociado y controladores - El hardware que está especialmente

asociado con la versión de la aplicación, como una tarjeta de vídeo en

concreto, la tarjeta de sonido, tarjeta de interfaz de red, o dispositivo de

almacenamiento. Si esto requiere controladores de hardware especiales del

fabricante de hardware. También se debe tener en cuenta

los requisitos de la resolución de vídeo.

§ Resolución de vídeo actual - La resolución de vídeo en el que la aplicación se

está ejecutando actualmente.

§ Requisitos de memoria - Todos los requisitos de memoria específicos que se

asocian con la aplicación. Esto debería incluir límites a la cantidad máxima de

información que el servidor o aplicación puede utilizar.

§ Cantidad de memoria en el sistema host actual - La cantidad de memoria que

está disponible en el sistema para que la aplicación se esté ejecutando

actualmente. Se puede utilizar esta información para dimensionar la memoria

de la máquina virtual si la aplicación no tiene cantidad de memoria explícita

§ Rendimiento de la aplicación actual - La percepción de los usuarios de lo bien

que la aplicación se ejecuta. Aunque es una medición empírica, se puede

utilizar esta información para ayudar a evaluar los requisitos de memoria y el

procesador de cualquier máquina virtual a la que se considerará trasladar la

aplicación.

§ Licenciamiento - Si la aplicación requiere una licencia y, de ser así, el tipo de

licencia: por - copia, flotante, Locked (bloqueado a un sistema específico

basado en un identificador de red IP, o dirección MAC), y así sucesivamente.

§ Licencias de virtualización - Si la aplicación se puede utilizar en una máquina

virtual ya que puede ser el caso que la licencia de software prohíbe el uso de

la aplicación o el sistema operativo que se requiere en una máquina virtual.

Esto debería también incluir información sobre si el uso de la aplicación en

una máquina virtual requiere los cambios de licencias, la adquisición de

licencias adicionales, y así sucesivamente.

ANEXO F

CONFIGURACIÓN TWO WAY ROUTED DEL PROTOTIPO

ANEXO F

CONFIGURACIÓN TWO WAY ROUTED DEL PROTOTIPO

De los tipos de configuración el tipo Two Way Routed Network se ve a continuación:

Figura 8.2 Two Way Routed Network aplicado al diseño.

La configuración general realizada es la siguiente:

En primer lugar se da la configuración de xend-config.sxp; el presente script debe

incluir las siguientes líneas que llaman a los scripts de network-route.

Archivo: /etc/xen/xend-config.sxp

La función de estos scripts es la siguiente:

Con el script network-route se activa IP forwarding en el Dom0:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Luego configura el domain0 para manejar (proxy) ARP requests desde los guest

domainU:

# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

Luego de levantar las interfaces de los DomU se corre el script vif-route; éste copia la

IP de la tarjeta de red del sistema (Gateway de los servidores virtuales) a la interface

vifDomID y la levanta.

Finalmente añade una ruta estática para los domainU ’ s desde vifDomID.

Luego se configuran las interfaces virtuales de cada VM en el archivo de

configuración correspondiente. Así por ejemplo:

Archivo de configuración del servidor http: /etc/xen/auto/vhttpsrvr.cfg

(network-script network-route)

# (network-script network-nat)

#(network-script network-bridge)

(vif-script vif-route)

#(vif-script vif-nat)

#(vif-script vif-bridge)

vif = [ 'ip=10.0.0.1' ]

Espacio de Código 8.1 Cuadro de código para configuración prototipo virtualizado de PyMEs del tipo Two Way Routed.

Luego procedemos a la configuración de las interfaces de red de las VM´s.

Archivo de vhttpsrvr: /etc/sysconfig/network-scripts/ifcfg-ethx

Se procede a configurar el dom0 para Forwarding

Luego creamos la VM (desde Dom0):

Finalmente en Dom0 se deberán configurar las reglas de firewall. A continuación se

presenta un extracto:

auto eth0

iface eth0 inet static

address 10.0.0.1

gateway 10.0.0.254

netmask 255.255.255.0

xm create /etc/xen/vhttpsrvr.cfg

echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp

iptables -t nat -A POSTROUTING -s 10.0.0.0 -j MASQUERADE

Espacio de Código 8.2 Configuración de interfaz de red virtual de una VM para un esquema routed.

Espacio de Código 8.3 Configuración del Dom0 para forwarding y enmascaramiento de las VM

Espacio de Código 8.4 Creación de una VM.

[root@mainserver network-scripts]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.1 * 255.255.255.255 UH 0 0 0 vif1.0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 ···························································································· ····························· [root@mainserver network-scripts]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT 0 -- 10.0.0.1 anywhere PHYSDEV match --physdev-in vif1.0 ACCEPT udp -- anywhere anywhere PHYSDEV match --physdev-in vif1.0 udp spt:bootpc dpt:bootps Chain OUTPUT (policy ACCEPT) target prot opt source destination ··························································································································· [root@mainserver network-scripts]# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE 0 -- 10.0.0.0 anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination

ANEXO G

INSTALACIÓN DE MAILSCANNER Y CLAMAV

ANEXO G

INSTALACIÓN DE MAILSCANNER Y CLAMAV

Fuente: “Instalación de MailScanner y Clamav” Ing. Pablo Pérez – Puntonet S.A.

1.- Instalacion Antivirus ClamAV

groupadd clamav

useradd -g clamav -s /bin/false -c "Clam AntiVirus" clamav

tar -xvzf clamavxx.xx

cd clamavxxx

./configure --sysconfdir=/etc

su -c 'make install'

2.- Instalacion de MailScanner

tar -xvzf MailScanner.xxx

cd MailScanner-4.32.5-1

./install.sh

Cerciorarse que la línea dentro de /etc/MAilScanner/MailScanner.conf se encuentre

Virus Scanners = clamav

Sign Clean Messages = yes

Language = es (español) en(ingles)

freshclam (Ver si esta actualizado el antivirus)

service sendmail stop

chkconfig sendmail off

chkconfig --level 2345 MailScanner on

service MailScanner start

3. Instalar Módulo MAilScanner

Full path to MailScanner program = /usr/lib/MailScanner/

Full path and filename of MailScanner config file = /etc/MailScanner/MailScanner.conf

Full path to the MailScanner bin directory = /usr/sbin

Full path and filename for the MailScanner pid file = /var/run/MailScanner.pid

The following change should be made:

"Command to start MailScanner" add "/etc/rc.d/init.d/MailScanner start" (without the

quotes) instead of just run server.

"Command to stop MailScanner" add "/etc/rc.d/init.d/MailScanner stop" (without the

quotes).

4. En webmin/servers/mailscanner

Option Report and responses

Se elimina la publicidad de los que tengan la fila es la ultima (MailScanner thanks

transtec Computers for their support)

En la línea: Inline HTML Signature hay que quitar las dos ultimas líneas

En la línea: Inline Text Signature hay que quitar la ultima línea

5. Cambio en Mail Scanner

Crear una cuenta de correo llamada spam

a) Dentro de What to do with spam

Spam Actions forward spam@dominio

High Scoring Spam Actions forward spam@dominio

b) Spam detection and spam lists (DNS blocklists)

Spam List (al final de la línea poner spamcop.net)

Spam Lists To Reach High Score (3.5)

Spam List Timeout (10)

Max Spam List Timeouts (7)

c) SpamAssassin

Use SpamAssassin (yes)

Max SpamAssassin Size (30000)

Required SpamAssassin Score (5.5)

High SpamAssassin Score (10)

Problemas con el Zlib Fedora core 2

./configure --sysconfdir=/etc --disable-zlib-vcheck

wget http://belnet.dl.sourceforge.net/sourceforge/clamav/clamav-0.83.tar.gz

ANEXO H

INSTALACIÓN Y CONFIGURACIÓN DE

SQUIRRELMAIL

ANEXO H

INSTALACIÓN Y CONFIGURACIÓN DE SQUIRRELMAIL

Como se mencionó brevemente en el capítulo 4, Squirrelmail es una aplicación

escrita en PHP4 que, mediante el uso de Web Browsers, permite la visualización,

envío, recepción, eliminación, y demás opciones referentes a Correo Electrónico; de

esta manera permitirá a los usuarios de las PyMES revisar su correo electrónico sin

necesidad de software como Microsoft® Outlook, Outlook Express®, Thunderbird,

etc. sino con un navegador web.

A continuación se presentan los procedimientos para la instalación del software en

mención.

Instalación del software requerido.

Se instala mediante la herramienta yum los componentes squirrelmail y el servidor

web Apache (httpd).

yum -y install squirrelmail httpd

Configuración de SquirrelMail.

Para la configuración se debe ejecutar el script conf.pl localizado en:

/usr/share/squirrelmail/config/.

Se muestra una interfaz de texto para configuración:

SquirrelMail Configuration : Read: config.php (1.4.3) --------------------------------------------------------- Main Menu -- 1. Organization Preferences 2. Server Settings 3. Folder Defaults 4. General Options 5. Themes 6. Address Books (LDAP) 7. Message of the Day (MOTD) 8. Plugins 9. Database

D. Set pre-defined settings for specific IMAP servers C. Turn color on S Save data Q Quit Command >>

Se procede a modificar las preferencias de la organización como se muestra a

continuación:

SquirrelMail Configuration : Read: config.php (1.4.3) --------------------------------------------------------- Organization Preferences 1. Organization Name : VirtualServer 2. Organization Logo : /home/user1/images/vserver_logo.png 3. Org. Logo Width/Height : (308/111) 4. Organization Title : Bienvenido al Webmail de VirtualServer. 5. Signout Page : 6. Default Language : es_ES 7. Top Frame : _top 8. Provider link : http://www.vserver.ec/ 9. Provider name : vserver.ec R Return to Main Menu C. Turn color on S Save data Q Quit Command >>

En las opciones de servidores se define el dominio vserver.ec. Si el servidor de

correo va a coexistir en el mismo sistema con el servidor HTTP (httpd instalado en

mailgateway y mailempresarial), no hace falta modificar más en esta sección o a su

vez puede ser configurado especificando otro servidor SMTP e IMAP localizados en

mailgateway.vserver.ec y como servidor httpd www.vserver.ec.

SquirrelMail Configuration : Read: config.php (1.4.3) --------------------------------------------------------- Server Settings General ------- 1. Domain : mailgateway.vserver.ec 2. Invert Time : false 3. Sendmail or SMTP : Sendmail A. Update IMAP Settings : localhost:143 (uw) B. Change Sendmail Config : /usr/sbin/sendmail R Return to Main Menu C. Turn color on S Save data

Q Quit Command >>

En las opciones de las carpetas se puede personalizar los nombres de Trash, Sent y

Drafts de acuerdo a las preferencias que se seleccionen.

SquirrelMail Configuration : Read: config.php (1.4.3) --------------------------------------------------------- Folder Defaults 1. Default Folder Prefix : mail/ 2. Show Folder Prefix Option : true 3. Trash Folder : Papelera 4. Sent Folder : Enviados 5. Drafts Folder : Borradores 6. By default, move to trash : true 7. By default, move to sent : true 8. By default, save as draft : true 9. List Special Folders First : true 10. Show Special Folders Color : true 11. Auto Expunge : true 12. Default Sub. of INBOX : true 13. Show 'Contain Sub.' Option : false 14. Default Unseen Notify : 2 15. Default Unseen Type : 1 16. Auto Create Special Folders : true 17. Folder Delete Bypasses Trash : false 18. Enable /NoSelect folder fix : false R Return to Main Menu C. Turn color on S Save data Q Quit Command >>

Finalmente se debe editar el fichero /etc/dovecot.conf y asegurarse que el servicio

imap se encuentre habilitado:

protocols = imap pop3

ANEXO I

SERVIDORES ADICIONALES

TELEFONÍA IP – MENSAJERÍA INSTANTÁNEA

ANEXO I SERVIDORES ADICIONALES

TELEFONÍA IP – MENSAJERÍA INSTANTÁNEA

Actualmente existen soluciones gratuitas que hacen uso de Internet tal como Skype

para permitir brindar soluciones de Voz sobre IP y mensajería, sin embargo siempre

será mejor la configuración personalizada de acuerdo a la organización de su propia

telefonía IP interna y que podrá ser utilizada entre sus sucursales. Estos servidores

pueden ser incluidos o no dentro del Centro de Datos para PyMES dependiendo de si

sus recursos económicos les permitirán la adquisición de teléfonos IP. Es por este

motivo que se presenta la configuración de estos servidores de manera separada de

los servidores vistos anteriormente.

Software

Alternativas de software

Se presenta como alternativa principal de software de telefonía IP a ASTERISK, el

cual es una implementación de código abierto para central telefónica (PBX, Private

Branch eXchange o Private Business eXchange). Cuenta con un doble

licenciamiento, GNU/GPL y licencia propietaria. Esta última es con el objeto de poder

incluir soporte para el protocolo G.729, el cual está sujeto a las limitaciones de una

patente, aunque el codificador correspondiente funciona indistintamente con una u

otra versión.

Asterisk está diseñado para servir como PBX. Como cualquier PBX, se puede

conectar un número determinado de teléfonos para hacer llamadas entre sí, e incluso

conectar a un proveedor de VoIP o bien a una PSTN.

La versión libre de Asterisk incluye todas las funcionalidades de las más costosas

alternativas de código cerrado, como son correo de voz, llamada en conferencia,

respuesta interactiva de voz (a través de menús del teléfono) y distribución

automática de llamadas.121

Instalación

Instalación Máquina Virtual

Por las características de la solución de Telefonía IP a implementarse, para el

presente servidor se utilizará una distribución de CentOS 5.4 con 512 MB en RAM y

10 GB de disco duro en base a las recomendaciones del fabricante de la plataforma

de telefonía.

Instalación Servicio

La instalación del servicio de telefonía se lo realiza de la siguiente manera:

El código fuente de Asterisk está disponible en www.asterisk.org en su versión más

reciente. Se instalará la versión 1.4.

wget http://downloads.digium.com/pub/asterisk/asterisk-14-current.tar.gz

Para ello se realizan los siguientes pasos:

Se descomprime el paquete en el directorio /usr/src

tar xvfz asterisk-1.4-current.tar.gz

se ingresa al directorio antes mencionado y se ejecuta

make clean

./configure

Esto limpia la carpeta seleccionada de instalaciones anteriores y verifica la existencia

de todos los paquetes requeridos para la correcta instalación.

A continuación se compila el código fuente de Asterisk:

make 121 Fuente: http://www.alcancelibre.org/staticpages/index.php/como-ekiga-asterisk

Y se instala

make install

Se crean los scritps de inicio y se activa Asterisk

make config

chkconfig asterisk on.

Finalmente se inicia Asterisk.

Service asterisk start

Los paquetes instalados son: asterisk-1.4.1, asterisk-addons-1.4.0, asterisk-sounds-

es, gsm-1.0.12 , libidn-0.6.9, libpri-1.4.0, spandsp-0.0.3-7_pre28 , speex-1.2 y

zaptel-1.4.0.

Configuración

Archivo de configuración

Los principales archivos de configuración de Asterisk con sip.conf y extensions.conf

localizados en /etc/asterisk.

A continuación se muestra la configuración de los mencionados archivos:

Fichero /etc/asterisk/sip.conf.

El siguiente código corresponde a la configuración de tres cuentas SIP (101

GERENCIA, 102 CONTABILIDAD y 103 VENTAS) como templates para la

configuración más detallada de acuerdo a los requerimientos específicos de cada

PyME. El contenido se agrega, o bien modifica opciones, al fichero

/etc/asterisk/sip.conf.

;Configuración de sip.conf

[general]

context=default

srvlookup=yes

videosupport=yes ; Asterisk puede también gestionar las conferencias

de vídeo

disallow=all ; Desactivar todos los codificadores

allow=alaw ; Permitir codificadores en orden de preferencia

allow=ilbc

allow=gsm

allow=h261

;Se define español como idioma para los mensajes.

language=es

; Realizar registro en vserver.ec con un usuario y clave de acceso

válidos y

; encaminar las llamadas hacia la extensión 101

register => usuario:clave-de-acceso@telip.vserver.ec/101

; Hacer acceder a Asterisk hacia una cuenta en telip.vserver.ec para

permitir

; realizar llamadas

[telip]

type=friend

username=usuario

secret=clave-de-acceso

host=ekiga.net

canreinvite=no

qualify=300

; Si se utiliza asterisk 1.4.x:

insecure=port,invite

; Si se utiliza asterisk 1.2.x:

; insecure=very

; Extensión 101 Ejemplo de Gerencia

type=friend

secret=secreto1

qualify=yes ; El par correspondiente está no más allá de 2000 mS.

nat=no ; No hay NAT.

host=dynamic ; Dispositivo se registrará con servidor.

canreinvite=no ; Asterisk tratará de redireccionar de forma

predeterminada.

context=home ; Contexto predefinido (ver → extensions.conf)

;port=5061 ; Descomentar si Ekiga o Linphone y Asterisk están en el

mismo sistema.

; Extensión 102 Ejemplo de Contabilidad

type=friend

secret=secreto2

qualify=yes

nat=no

host=dynamic

canreinvite=no

context=home

;port=5061

; Extensión 103 Ejemplo de ventas

type=friend

secret=secreto3

qualify=yes

nat=no

host=dynamic

canreinvite=no

context=home

;port=5061

Fichero /etc/asterisk/extensions.conf.

El siguiente ejemplo corresponde a la configuración de tres extensiones (101, 102 y

103). El contenido se agrega al fichero /etc/asterisk/extensions.conf.

[home]

; Extensión 101

exten => 101,1,Dial(SIP/101,60)

; Extensión 102

exten => 102,1,Dial(SIP/102,60)

; Extensión 103

exten => 103,1,Dial(SIP/103,60)

; Prueba de Eco

exten => 600,1,Answer()

exten => 600,2,Playback(demo-echotest)

exten => 600,3,Echo()

exten => 600,4,Playback(demo-echodone)

exten => 600,5,Hangup()

Al terminar, solo bastará reiniciar el servicio asterisk para que surtan efecto los

cambios.

service asterisk restart

PRUEBAS

Para las pruebas se usaran en lugar de Teléfonos IP, Softphones como EKIGA que

viene instalado por defecto en cualquier distribución de CentOS en sus versiones 5.

Configuración de cliente Ekiga.

Ekiga, además de ajustar los niveles de audio del sistema para permitir el

funcionamiento del micrófono (captura), requiere y desactivar cualquier método de

NAT que esté especificado (por lo general, STUN).

Al terminar y aplicar los cambios, se debe acceder al menú de la aplicación Editar →

Cuentas y añadir una nueva cuenta tipo SIP, especificando un nombre para identificar

la cuenta, la IP del servidor Asterisk, el usuario a utilizar y la correspondiente clave de

acceso.

Al terminar, solo se necesitará hacer clic en la casilla para activar la cuenta y

registrarse en el servidor.

Para si uno marca 600, deberá contestar el servidor Asterisk con un mensaje de

prueba de eco. Si se conectan los clientes al servidor Asterisk, podrán comunicarse

entre si marcando solo el número de extensión, o bien como sip:extension@servidor.

Ejemplo: sip:103@192.168.10.1.

Para enviar y recibir mensajes de texto basta con señalar la pestaña de chat que

Ekiga trae y usa la misma plataforma ya configurada.

ANEXO J

COSTOS DE LA IMPLEMENTACIÓN

ANEXO J COSTOS DE LA IMPLEMENTACIÓN

A continuación se presentan los detalles correspondientes a los costos de Hardware

de la implementación realizada con diferentes proformas obtenidas.

A continuación se presentan los detalles de los componentes presentados en las

proformas anteriores:

Otros proveedores:

ANEXO K

CÓDIGO DE IMPLEMENTACIÓN DE LOS SERVICIOS

ANEXO K

CÓDIGO DE IMPLEMENTACIÓN DE LOS SERVICIOS

El código referente a las diversas implementaciones realizadas, puede encontrarse

en el CD anexado al presente proyecto.

REFERENCIAS

9. REFERENCIAS BIBLIOGRÁFICAS

· LIBROS

1. VON HAGEN, William. Types of Virtual Machines Supported by Xen. Professional

Xen® Virtualization. 1ra. Edición. Estados Unidos de América : Wiley Publishing, Inc.,

2008, pág. 36.

2. WILLIAMS, David y GARCÍA, David. Types of Virtualization. Virtualization with

Xen™: Including XenEnterprise™, XenServer™, and XenExpress™. 1ra Edición.

Estados Unidos de América : Syngress Publishing Inc., 2007, pág. 26.

3. TULLOCH, Mitch y Micosoft Corporation®. Understanding Microsoft Virtualization

Solution. Estados Unidos de América : MS Press., 2009, págs. 29, 30.

4. BARRERA, Marco y CAPEIPI, Cámara de la Pequeña Industria de Pichincha.

“Situación y Desempeño de las PYMES de Ecuador en el Mercado Internacional”.

s.l. : CAPEIPI, 2002.

5. CARRIÓN, Gordón Hugo Ing., LÓPEZ, Guerrero Hernando ECON., Santa Fe

Corporación de Promoción Económica CONQuito, 2007.

6. VILLARROEL, Christian y CAPEIPI. INFOPYME. Quito : Cámara de la Pequeña

Industria de Pichincha, 2008.

7. GALÁN, Luis. Internet en las PYMES. s.l. : Anetcom, 2005.

8. NORRIS Mark, PRETTY Steve. Designing the Total Area Network: Intranets,

VPN’S and Enterprise Networks Explained. Chicheste : John Wiley & Sons Ltd., 2000.

0-471-85195-7.

9. ARREGOCES Mauricio, PORTOLANI Maurizio. Data Center Fundamentals. s.l. :

Cisco Press, 2004. ISBN-10: 1-58705-023-4.

10. Virtualización en el Centro de Datos. Novell, Inc. Estados Unidos y otros países. :

Novell, Inc., 2007.

11. CHÁVEZ, Dennys y MENA, Christiam. Reingeniería De La Infraestructura De Red

Del Data Center De La Empresa Conectividad Global Cía. Ltda. Que Provee Servicios

De Intranet A Las Instituciones Del Proyecto Quitoeduca.Net. Quito : s.n., 2009.

12. WILLIAMS, David y GARCÍA, Juan. Virtualization with XEN™. Estados Unidos de

América : Syngress Publishing, Inc., 2007.

septiembre de 2009.]

http://www.microsoft.com/spain/windowsserver2008/virtualization/hyperv_caract.mspx

2. Citrix Systems Inc. Xen.org. [En línea] 2009. [Citado el: 9 de Septiembre de 2009.]

http://bits.xensource.com/Xen/docs/user.pdf.

3. Un-trade-environment. un-trade-environment.org. [En línea] http://www.un-trade-

environment.org/meetings/Latin/2007-03-26/documents/equipo_ecuador.pdf.

Portal empresarial Colombiano. [En línea] 2006. [Citado el: 14 de Septiembre de

2009.] http://www.mipymes.gov.co/pyme/newsdetail.asp?id=225&idcompany=43.

5. LinuxCentro.net. [En línea] 2007.

http://www.linuxcentro.net/linux/staticpages/index.php?page=ServidoresLINUX.

6. Linux Para Todos. [En línea] 2008.

http://www.linuxparatodos.net/portal/index.php?topic=empresarial#.

facultad de ingeniería eléctrica y electrónica - ESCUELA ...

Documents

Transcript of facultad de ingeniería eléctrica y electrónica - ESCUELA ...

CONEXIÓN ELÉCTRICA BRC

REVISTA ELECTRÓNICA DE ESTUDIOS FILOLÓGICOS

PROBLEMAS DE ELECTRÓNICA DIGITALtodos

facultad de ingeniería eléctrica y electrónica - ESCUELA ...

Catalogo_indice_ariston 12.pdf - Ariston Electrónica

facultad de ingeniería eléctrica y electrónica - CCTVCAD

Maquetación 1 - Saber Electrónica

INTRODUCCIÓN ELECTRÓNICA ANALOGICA

conductividad eléctrica - dspace.espol.edu.ec

escuela superior de ingeniería mecanica y eléctrica

IPN ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD CULHUACAN

Estatica-1.pdf - Facultad de Ingeniería Mecánica y Eléctrica

Taller de materiales I - Facultad de Ingeniería Mecánica y Eléctrica

DVR3104 - Electrónica Embajadores

Ingenierías eléctrica y electrónica Sistemas de aprendizaje y ...

Tedi 4000 HD - Fagor Electrónica

Apuntes de Electrónica - Vytautas Gabriunas

AplicAción electrónicA pArA el Ahorro de energíA eléctricA ...

G233N UNIDAD ELECTRÓNICA ELECTRONIC MONITOR ...

TÉCNICO EN ELECTRÓNICA