consolidación de infraestructura de servidores hacia entorno...
TRANSCRIPT
FACULTAD DE INGENIERÍA
Carrera de Ingeniería Empresarial y de Sistemas
CONSOLIDACIÓN DE INFRAESTRUCTURA DE SERVIDORES HACIA ENTORNO VIRTUAL EN LA
MUNICIPALIDAD METROPOLITANA DE LIMA
Tesis para optar por el Título Profesional de Ingeniero Empresarial
y de Sistemas
JOSÉ ANTONIO MONTERO KHANG
Asesor:
Ing. José Guevara Julca
Lima - Perú
2016
1
Resumen
El propósito de esta investigación ha sido desarrollar el estudio de capacidades
computacionales necesarias para la realización de la consolidación de servidores a
través de la virtualización en la Municipalidad Metropolitana de Lima (MML), entidad
que busca proveer la plataforma de información, comunicación y análisis disponible
para todas las unidades orgánicas de la corporación municipal.
Además, cuenta con diseño de arquitectura de infraestructura computacional que
contiene un inventario de los componentes que la conforman, así como sus
especificaciones y muestra una guía que describe de manera colectiva el planeamiento
de la infraestructura computacional que se piensa implementar en la entidad edil.
Este estudio incorpora las mejores prácticas utilizadas en el desarrollo de proyecto de
virtualización y tiene como objetivo servir de referencia al área de Tecnologías de
Información de la entidad edil, la cual tiene como tarea administrar el ambiente físico y
virtual que se encuentra ahora implementado.
Palabras claves: Estudio de capacidades, virtualización, infraestructura computacional.
2
INDICE GENERAL
CAPÍTULO 1. JUSTIFICACIÓN ................................................................................. 8
CAPÍTULO 2. DEFINICIÓN DEL PROBLEMA ..................................................... 10
CAPÍTULO 3. OBJETIVOS ....................................................................................... 11
3.1. OBJETIVO GENERAL ................................................................................................................ 11
3.2. OBJETIVOS ESPECÍFICOS ......................................................................................................... 11
CAPÍTULO 4. CONTRIBUCIÓN DEL BACHILLER CON EL TRABAJO ........ 12
CAPÍTULO 5. ALCANCE Y LIMITACIONES DEL TRABAJO .......................... 13
5.1. ALCANCES ................................................................................................................................ 13
5.2. LIMITACIONES ......................................................................................................................... 13
CAPÍTULO 6. FASES DE DESARROLLO DEL TRABAJO ................................. 15
CAPÍTULO 7. MARCO CONTEXTUAL.................................................................. 17
7.1. VISIÓN DE LA MUNICIPALIDAD METROPOLITANA DE LIMA .................................................. 17
7.2. MISIÓN DE LA MUNICIPALIDAD METROPOLITANA DE LIMA ................................................. 17
CAPÍTULO 8. MARCO CONCEPTUAL .................................................................. 20
8.1. MARCO TEÓRICO ..................................................................................................................... 20
8.2. COMPETITIVIDAD .................................................................................................................... 20
8.3. DIAGNÓSTICO DE LA MUNICIPALIDAD METROPOLITANA DE LIMA ...................................... 21
8.4. INFRAESTRUCTURA CONVERGENTE ........................................................................................ 22
8.5. STORAGE AREA NETWORK ..................................................................................................... 23
8.6. DISEÑO DE CENTRO DE CÓMPUTO ........................................................................................... 24
8.6.1. DISPONIBILIDAD DE CENTRO DE CÓMPUTO ........................................................................ 24
8.7. TECNOLOGÍA DE VIRTUALIZACIÓN ......................................................................................... 26
8.7.1. IMPORTANCIA DE LA VIRTUALIZACIÓN .............................................................................. 27
8.7.2. RAZONES PARA LA VIRTUALIZACIÓN ................................................................................. 28
CAPÍTULO 9. MARCO METODOLÓGICO ........................................................... 30
9.1. ANÁLISIS DE MICROSOFT ASSESSMENT AND PLANNING TOOL ............................................. 31
9.1.1. USO ACTUAL DE CAPACIDADES ........................................................................................... 31
9.1.1.1. ANÁLISIS DE CAPACIDADES DE CPU................................................................................... 31
9.1.1.2. ANÁLISIS DE CAPACIDADES DE MEMORIA. ......................................................................... 32
9.1.1.3. ANÁLISIS DE CAPACIDADES DE DISCO ................................................................................. 33
9.1.2. DETALLE DE LOS SERVIDORES TOMADOS PARA EL ANÁLISIS. ........................................... 33
9.1.3. CAPACIDADES DE HOSTS RECOMENDADOS. ........................................................................ 35
9.1.3.1. ANÁLISIS DE CPU. ............................................................................................................... 35
3
9.1.3.2. CAPACIDAD DE HOSTS POR MEMORIA. ............................................................................... 36
9.1.4. DISEÑO DE HOSTS ............................................................................................................... 38
9.1.5. CAPACIDAD DE ALMACENAMIENTO. ................................................................................... 40
9.1.5.1. DETERMINANDO STORAGE PERFORMANCE REQUERIDO. ................................................. 40
9.1.5.2. CALCULANDO CAPACIDAD DE ALMACENAMIENTO REQUERIDO. ....................................... 41
9.2. DISEÑO DE LA INFRAESTRUCTURA VIRTUAL .......................................................................... 43
9.2.1. INVENTARIO DE COMPONENTES VMWARE ........................................................................ 43
9.2.2. ESPECIFICACIONES PARA SERVER HOSTS .......................................................................... 44
9.2.3. ESPECIFICACIONES DE SERVIDOR VCENTER ..................................................................... 45
9.2.4. CONFIGURACIÓN DE NETWORKING ................................................................................... 46
9.2.5. ESPECIFICACIONES DE STORAGE ....................................................................................... 46
9.2.5.1. REDUNDANCIA DE STORAGE ............................................................................................... 48
9.3. ARQUITECTURA DATACENTER EN VCENTER ......................................................................... 48
9.3.1. GRÁFICO DE INFRAESTRUCTURA VIRTUAL ........................................................................ 50
9.4. MONITOREO DE ARQUITECTURA VI ....................................................................................... 51
9.5. DISEÑO DEL CENTRO DE CÓMPUTO ......................................................................................... 52
CAPÍTULO 10. EVALUACIÓN FINANCIERA ...................................................... 56
CAPÍTULO 11. DESARROLLO DEL PROYECTO DE CONSOLIDACIÓN ..... 61
11.1. ACTIVIDADES DEL PROYECTO ................................................................................................. 61
11.2. ENTREGABLES ......................................................................................................................... 64
11.3. CRONOGRAMA DE ACTIVIDADES ............................................................................................. 64
CAPÍTULO 12. CONCLUSIONES ............................................................................ 66
CAPÍTULO 13. BIBLIOGRAFÍA .............................................................................. 71
CAPÍTULO 14. ANEXOS .............................................................................................. 0
4
ÍNDICE DE TABLAS
Tabla 1: Fases del desarrollo del trabajo 16
Tabla 2: Análisis CPU 35
Tabla 3: Análisis memoria 37
Tabla 4: Análisis de memoria por host 38
Tabla 5: Análisis de almacenamiento 40
Tabla 6: Cálculo de almacenamiento requerido 41
Tabla 7: Arreglo de discos 42
Tabla 8: Componentes de infraestructura virtual 43
Tabla 9: Especificaciones técnicas de hosts 44
Tabla 10: Especificaciones técnicas de VCenter 45
Tabla 11: Especificaciones técnicas de hosts 46
Tabla 12: Especificaciones de storage 46
Tabla 13: Distribución de storage 47
Tabla 14: Nomenclatura de storage 48
Tabla 15: Redundancia en storage 48
Tabla 16: Costo de sistema convergente 56
Tabla 17: Costo personal MML 57
Tabla 18: Costo del proyecto 57
Tabla 19: Consumos eléctricos estimados 57
Tabla 20: Modelos de servidores físicos a virtualizar 59
Tabla 21: Cronograma de actividades 64
Tabla 22: Flujo de caja 73
5
ÍNDICE DE FIGURAS
Figura 1 Marcas líderes en Sistemas Convergentes 23
Figura 2 Características de los niveles Tier 25
Figura 3 Marcas líderes en sistemas de virtualización 27
Figura 4 Análisis de capacidades de CPU 31
Figura 5 Análisis de capacidades de memoria 32
Figura 6 Análisis de capacidades de disco 33
Figura 7 Lista de servidores analizados y considerados para la virtualización 34
Figura 8 Diseño de Hosts propuestos 39
Figura 9 Infraestructura virtual propuesta luego de análisis y especificaciones 50
Figura 10 Solución de respaldo en la actualidad en MML 51
Figura 11 Consola de administración centralizada del sistema convergente de
Virtualización
52
Figura 12 Mapa de centro de cómputo en MML previo a la consolidación de
Servidores
53
Figura 13 Mapa de centro de cómputo en MML posterior a la consolidación de
Servidores
54
Figura 14 Ubicación del sistema convergente en gabinetes de la MML 55
Figura 15 Consumo estimado en componente de storage 58
Figura 16 Consumo estimado en componente de servidores 59
Figura 17 Actuales consumos eléctricos en servidores Dell 60
Figura 18 Gantt de la ejecución del proyecto de consolidación en la MML 65
6
ÍNDICE DE ABREVIATURAS
MML Municipalidad Metropolitana de Lima
GMD Graña y Montero Digital
TIC Tecnologías de la información y la comunicación
MAP Microsoft assessment and planning tool
PMI Project Management Institute
ROI Return on investment
TCO Total cost of ownership
SAN Storage area network
LAN Local area network
CPU Central processing unit
GHZ Gigahertz
MB Megabyte
GB Gigabyte
TB Terabyte
RAM Random access memory
IOPS Input output per second
I/O Input output
RAID Redundant array of independent disk
7
LUN Logical unit number
VMFS Virtual machine file system
VI Virtual infrastructure
HBA Host bus adapter
UCS Unified computing system
8
Capítulo 1. Justificación
La Municipalidad Metropolitana de Lima (MML), de forma permanente y sostenida
realiza las actividades necesarias para el mantenimiento y desarrollo integral de la
ciudad de Lima en el ámbito metropolitano. Para ello basa sus procesos en Sistemas
Integrados de Gestión, Sistemas Catastrales, Sistemas de Información Geográfica,
Sistemas de Sección Vial, Sistemas de aplicaciones propias, Sistemas de Archivos, así
como en Bases de Datos necesarias.
De manera recurrente se presentan disrupciones de servicios de estos sistemas
debido a que se ejecutan sobre la infraestructura actual de servidores de cómputo. Los
actuales servicios brindados por la Municipalidad Metropolitana de Lima (MML) hacia
sus clientes internos y externos a través de estos sistemas, están soportados sobre una
plataforma de servidores que no cuentan con las características necesarias que se
encuentran en centros de datos como lo son: la alta disponibilidad que garantice la
continuidad de los procesos, la gestión unificada de la infraestructura informática que
brinde un mayor control y flexibilidad, la tolerancia a fallos en los componentes de los
actuales servidores, procesos de recuperación ante desastres y por último, la actual
fuerza computacional no soporta nuevas y mejores herramientas que contengan
funcionalidades de disponibilidad y escalabilidad. A su vez, el hacinamiento de estos
equipos dentro del Centro de Cómputo, genera elevados costos operativos debido a la
relación 1:1 que existe, es decir un equipo servidor para cada Sistema de la entidad.
Este contexto condiciona a la MML a contar con desventajas competitivas, por falta
de un adecuado diseño en su plataforma tecnológica de servidores, además de no poder
actualizar sus sistemas debido a que estos equipos no cumplen con los requisitos
mínimos necesarios para la mejora.
9
La necesidad de fortalecer las capacidades técnica, administrativa y de gestión
institucional de la entidad a través del adecuado uso de las tecnologías de información,
acceder a soluciones que incorporen mejoras y el acceso a la información en tiempo y
forma de manera eficiente y transparente son metas indispensables que la MML quiere
lograr con el fin de facilitar la toma de decisiones más efectiva y aumentar el nivel de
transparencia, automatizar y optimizar procesos, permitiendo tomar acciones e
iniciativas sobre los recursos disponibles.
Implementar herramientas de competitividad de la mano de la tecnología, es el pilar
fundamental en este estudio para que, la entidad pueda hacer frente a posibles
situaciones de falta de información oportuna, integra y confiable.
10
Capítulo 2. Definición del problema
El problema radica en que la actual plataforma de cómputo presenta recurrentes
incidentes de fallas registradas que deriva en que los sistemas se encuentren fuera de
servicio hasta 5% del tiempo anualizado en horas. Estas fallas originadas, en su mayoría
por la escasez de recursos para el procesamiento de datos, generan sobrecostos a la
entidad para sobreponerse a estos incidentes y no permiten brindar el modelo de
servicio informático necesario que apoye en la toma de decisiones en cumplimiento de
los objetivos del plan estratégico 2015 – 2018 de la MML, generando ausencia de
acciones correctivas y de oportunidades; provocando que no se mejoren los servicios
prioritarios, evitando que se tenga un alimentador estratégico para las tomas de
decisiones, acciones e iniciativas sobre los recursos disponibles.
11
Capítulo 3. Objetivos
3.1. Objetivo general
Proponer una plataforma de cómputo escalable y flexible que permita asegurar el
acceso oportuno a la información, que optimice la capacidad de almacenamiento
y procesamiento de datos, además que brinde el soporte informático a las
estrategias de negocio, gobernabilidad y trasparencia en la MML.
3.2. Objetivos específicos
1. Elaborar un estudio de capacidades necesarias según las exigencias y
demandas de procesamiento de datos de la MML proyectadas a 3 años.
2. Diseñar la plataforma de cómputo de acuerdo al resultado del estudio de
capacidades considerando la aplicación de buenas prácticas y de acuerdo al
presupuesto con que cuenta la MML
3. Proponer un sistema de gestión para la plataforma de centro de cómputo
diseñada que permita la administración centralizada por cada componente del
sistema.
12
Capítulo 4. Contribución del bachiller con el trabajo
En GMD mantengo el rol de Ingeniero Senior de Soporte y el papel que llevo en el
proyecto de consolidación de servidores en la MML es el de implementador y líder
técnico. Participé en el diseño original de implementación de la infraestructura
adquirida para el proyecto, así como en el propio despliegue y ahora estamos en la etapa
de la consolidación y virtualización de servidores. Coordino con el Jefe de Proyecto de
GMD asignado al presente proyecto, el apoyo de los distintos recursos técnicos de
GMD involucrados.
Realizo la documentación de los procesos ejecutados en el presente estudio de
manera que permita brindar una metodología de implementación de ambiente virtual
basado en buenas prácticas, para que a su vez sea una fuente de consulta para iniciativas
similares.
13
Capítulo 5. Alcance y limitaciones del trabajo
5.1. Alcances
1. La tecnología de la solución propuesta a la Municipalidad Metropolitana de Lima
es nueva y de última generación.
2. La versión del software Hipervisor utilizado para la virtualización de los
servidores, así como del administrador de la infraestructura virtual, será la última
versión liberada por el fabricante del software de acuerdo a la publicación en su
página web.
3. Alcance comprende el estudio de capacidades, diseño, implementación y pruebas.
4. Instalación y puesta en marcha de todos los componentes de la infraestructura que
es parte de la solución brindada.
5. Creación de usuarios en cuanto a la solución brindada.
6. Documentación detallada en cuanto a la solución final implementada.
5.2. Limitaciones
1. Reinstalación o desinstalación de aplicaciones de otros proveedores no
explicitadas en el alcance del servicio.
2. Reinstalación de componentes de la solución por temas de responsabilidad del
cliente.
3. Disposición por parte del personal de TIC de la MML en brindar información o
disposición de tiempo por parte de ellos por sus ocupaciones laborales.
14
4. La versión del software hipervisor en compatibilidad de versión en común para
todos los componentes con los que interactúa.
5. Disponibilidad de acceso y operación en la solución a implementar.
6. Destino de los servidores físicos al retiro por efectos de la consolidación a través
de la virtualización.
7. Asignación de funciones y/o roles para las que no son necesarias contar para la
implementación de la solución.
8. Gestión y/o control de tareas innecesarias para la implementación de la solución.
15
Capítulo 6. Fases de desarrollo del trabajo
El desarrollo del trabajo inicia con el estudio de capacidades requeridas y necesarias
para la propuesta de una plataforma de cómputo escalable y flexible. Para este fin se ha
tomado en cuenta las capacidades inventariadas y el análisis de performance tomada por
varios días desde la herramienta MAP (Microsoft Assessment and Planning Tool),
cruzando esta información con el inventario entregado por el personal técnico de la
MML. Brindará como resultado la estimación y el análisis de las necesidades de
equipamiento para el proyecto de virtualización, lo que se llama habitualmente
consolidación, en función a las exigencias y demandas de procesamiento de datos de la
MML.
Posteriormente al análisis de capacidades y de acuerdo a los requisitos de
disponibilidad de los sistemas y el tiempo de productividad, es que se determina el nivel
para evaluar de manera efectiva la infraestructura durante la fase de diseño. La solución
propuesta contiene componentes cuyas especificaciones técnicas son indicadas en esta
fase.
Durante el desarrollo del plan del proyecto, se adopta la metodología del PMI
(Project Management Institute) para la gestión de proyectos. Se aplican las mejores
prácticas en la instalación de la infraestructura parte de la solución de acuerdo a los
fabricantes implicados en la solución propuesta. Durante la ejecución de los procesos de
consolidación se hace necesaria la interpretación del proyecto hacia los técnicos
ejecutores. En la fase de control, y a través del ciclo de vida del proyecto, los técnicos
realizan una labor de seguimiento, ya que es posible la solución a diferentes problemas
que puedan surgir y además están disponibles para atender consultas en cuanto a la
solución propuesta. Durante el ciclo de vida del proyecto, se ejecutarán las siguientes
actividades (Tabla 1):
16
Tabla 1: Fases del desarrollo del trabajo
Reuniones Entregables Implementación
Kick off Plan de proyecto Coordinación con el área
usuaria a fin de minimizar
riesgos.
Reunión de seguimiento
semanal
Actas de reunión Validación de entregables.
Reuniones de
coordinación.
Actas de aceptación de
entregables.
Documento Pre delivery
Documento de diseño
Documento de solución
final implementada
Fuente: Fuente propia
17
Capítulo 7. Marco contextual
7.1. Visión de la Municipalidad Metropolitana de Lima
“La MML será reconocida como una institución transparente, eficiente, organizada
para el logro de resultados, que concerta con la ciudadanía y los diferentes niveles
de gobierno, y que ha incorporado las nuevas funciones regionales articulándolas
con las funciones municipales, liderando el desarrollo integral de los habitantes de
la provincia o del cercado en particular. Ha contribuido a mejorar la calidad de
vida, dando prioridad a la población en situación de vulnerabilidad, especialmente
los niños, niñas y adolescentes.” (Plan Estratégico Institucional 2011-2014,
Municipalidad Metropolitana de Lima, p.63)
7.2. Misión de la Municipalidad Metropolitana de Lima
“Consolidar el gobierno de Régimen Especial de Lima Metropolitana,
implementando un nuevo estilo de gestión, basado en la transparencia,
concertación, autoridad democrática y liderazgo, planeamiento y excelencia. Para
ello ejerce las competencias regionales con recursos adecuados y de forma
planificada; fortalece la gestión articulada y participativa del Cercado de Lima y
los mecanismos de participación ciudadana y de coordinación interdistrital e
interregional; y potencia las capacidades humanas y técnicas para la gestión
institucional.” (Plan Estratégico Institucional 2011-2014, Municipalidad
Metropolitana de Lima, p.64)
Mediante un proceso gradual, continuo y de largo alcance; la Municipalidad
Metropolitana de Lima, bajo su visión y misión, busca ser una institución al servicio
del ciudadano, que tiene como objetivo lograr un gobierno metropolitano ágil,
eficaz, eficiente, transparente, austero, descentralizado e incluyente, presente en
18
todas las zonas de Lima Metropolitana y en todos los sectores sociales, que sea
capaz de responder con celeridad a los pedidos y a las exigencias y necesidades
sociales.
Dentro de la entidad edil, la Gerencia de Planificación es la que, mediante sus
unidades orgánicas, como la Sub Gerencia de Informática, logra conducir con
eficiencia y eficacia, los procesos de desarrollo organizacional, aprobación y
evaluación de los planes de acción, así como los planes operativos y viabilidad de
proyectos.
Para esto, el Plan Estratégico Institucional de la Municipalidad Metropolitana de
Lima permite diseñar estrategias de mediano y largo plazo, así como la medición de
los objetivos institucionales trazados.
El objetivo de la Gerencia de Planificación es proveer la plataforma de
información, comunicación y análisis necesaria a todas las unidades orgánicas de la
corporación municipal a fin de gestionar la institución acorde con las metas. Realiza
las siguientes acciones estratégicas:
Gestionar el gobierno metropolitano de Lima basado en los principios de buen
gobierno.
Fortalecer las capacidades de gestión institucional de la Municipalidad
Metropolitana de Lima para mejorar la atención a la ciudadanía.
Diseñar e implementar acciones integrales y una política de modernización de la
gestión pública de la Municipalidad Metropolitana de Lima que oriente la
organización, personas y procesos al servicio del ciudadano.
19
Formular e implementar acciones integrales en materia de gobierno abierto a
efecto de implementar las TIC como catalizador para la construcción de una
agenda digital para Lima.
Fortalecer la plataforma tecnológica e implementar sistemas de información que
soporten los procesos de planeamiento, monitoreo y evaluación, así como el uso
de información geo referenciada.
20
Capítulo 8. Marco conceptual
8.1. Marco teórico
El proceso de modernización en la Municipalidad Metropolitana de Lima busca
mejorar la gestión de sus recursos promoviendo la eco eficiencia como uno de los
pilares del desarrollo sostenible de este organismo. Es así que dentro de los
lineamientos técnicos del Plan Operativo Informático, la gestión de las tecnologías
de la información y comunicación (TIC) en la Municipalidad Metropolitana de
Lima, busca optimizar el rendimiento, disponibilidad, tolerancia a fallos y
escalabilidad de los servidores de misión crítica de su centro de datos, para que sean
eficientes, dinámicos, de mayor poder computacional y que representen ahorros
significativos de funcionamiento y de administración para la actual gestión
municipal. Con el fin de otorgar Valor a la institución, estos procesos de cambio
deben ser sostenibles en el tiempo.
Después de una exhaustiva investigación, el objetivo de esta sección es brindar la
información acerca del contexto de las tecnologías de la información en nuestro país
y cómo el Estado define políticas a fin de que estas sean utilizadas para beneficio de
la sociedad peruana en el ámbito de los gobiernos locales y regionales poniendo
especial énfasis en la Municipalidad Metropolitana de Lima.
8.2. Competitividad
El Estado peruano, en su esfuerzo de incrementar beneficios para la población,
produce bienes y servicios de mayor calidad intentando reducir sus costos de
operación resultando en un enfoque competitivo con capacidad de impactar
positivamente en la economía.
21
De acuerdo con el Informe de Competitividad Global (The Global
Competitiveness Report 2013-2014, World Ecomomic Forum, p20) define la
competitividad como “conjunto de instituciones, políticas y factores que determinan
el nivel de productividad de un país.” En la década de los noventa aparece el
concepto de “competitividad sistémica” (Esser, Hillebrand, Messner y Meyer-Stamer,
Berlín, 1994) que surge de la interacción del Estado y la sociedad civil para crear
condiciones para un desarrollo exitoso, a partir de intervenciones en distintos
niveles: i) micro, relacionado con las empresas y sus redes; ii) macro, vinculado a
las condiciones económicas e instituciones generales; iii) meso, a través del
desarrollo de políticas e instituciones específicas, y iv) meta, vinculado a la
formación de capital social.
De lo anterior se desprende que todos los enfoques de competitividad recogen,
como un aspecto sustancial, la institucionalidad y las reglas de juego que conforman
el clima de negocios en el que la actividad empresarial se desarrolla. Un país tiene
un buen clima de negocios en la medida que la regulación en torno a la empresa
beneficia su formación y crecimiento.
8.3. Diagnóstico de la Municipalidad Metropolitana de Lima
El diagnostico encontrado en la Municipalidad Metropolitana de Lima hace
referencia a tres áreas claves, siguiendo los lineamientos de gobierno electrónico y
obedeciendo a la agenda digital, la Municipalidad Metropolitana de Lima desarrolla
su Plan Operativo Informático dirigiendo sus esfuerzos y recursos necesarios en
estas tres áreas:
22
La modernización de la infraestructura que es uno de los pilares fundamentales
en este aspecto, dado a que la institución aún cuenta con sistemas (ya sea
hardware o software) antiguos. Como alternativa de solución se considera la
adquisición de sistemas de ingeniería ya integrados que puedan brindar mejores
prestaciones.
La eficiencia y transparencia como medidas indispensables para la
automatización de procesos debido a que muchos procesos aún son manuales y
es necesario acceder a soluciones que incorporen mejoras en el proceso de
trámite documentario y eviten la falta de acceso a la información incluso por
parte de los funcionarios públicos.
El servicio al ciudadano como tercera área fundamental para concretar un
gobierno electrónico. El ciudadano de hoy en día espera acceder a un portal web
que funcione como un verdadero canal de comunicación con el Gobierno para
así ser escuchado y asimismo quiere que su interacción con el Gobierno pueda
ser electrónica, rápida, trazable y traiga un resultado rápido.
8.4. Infraestructura convergente
Gracias al incremento de la capacidad computacional de los actuales servidores,
equipos de almacenamiento y sistemas de comunicación, así como a las tecnologías
de virtualización; los centros de cómputo están siendo consolidados trayendo
consigo significantes beneficios para las empresas como son el retorno de la
inversión (ROI) y el bajo costo total de propiedad (TCO).
23
Figura 1 –Marcas líderes en Sistemas Convergentes. Fuente: Gartner Inc.
Esta consolidación de los centros de cómputo que reúne capacidades de
almacenamiento de dato, redes y capacidad de cómputo desde un solo sitio de
recursos compartidos y bajo un solo punto de administración, es lo que se llama
Infraestructura Convergente. Marcas líderes como Cisco-NetApp (Figura 1)
desarrollan sistemas convergentes que pueden poner en producción nuevos y
mejores servicios en solo cuestión de horas o días.
8.5. Storage Area Network
Una Storage Area Network conocida por su acrónimo SAN, es una
infraestructura inteligente que interconecta servidores heterogéneos con sistemas de
24
almacenamiento compartidos y también heterogéneos de forma altamente disponible
y escalable y su rendimiento crece a medida que crece el número de dispositivos
conectados. Es una red dedicada, diseñada específicamente para conectar sistemas
de almacenamiento, dispositivos de respaldo de información y servidores.
8.6. Diseño de centro de cómputo
Los nuevos sistemas de servidores, almacenamiento y comunicaciones demandan
diversos requerimientos que son considerados en el diseño de un centro de cómputo
bajo estándares que dictan instituciones especializadas en esta clase de diseño.
Factores como espacio disponible en el centro de cómputo, cargas eléctricas
estimadas para el funcionamiento de los equipos, así como cargas térmicas, peso,
ubicación y nivel de disponibilidad requerido; son considerados para diseñar un
centro de cómputo de acuerdo a las necesidades y requerimientos de los clientes
8.6.1. Disponibilidad de centro de cómputo
Uptime Institute creó el standard de sistema de clasificación Tier para la
evaluación sistemática de diversas instalaciones de centros de cómputo en
términos del tiempo de actividad, es decir disponibilidad.
Los Tiers son divididos del I al IV (Uptime Institute, Data Center Site
Infrastructure Tier Standard: Operational Sustainability, p.4), son progresivos y
cada nivel incorpora los requisitos de todos los niveles inferiores (Figura 2). Tier
I y Tier II son soluciones tácticas, y normalmente están más impulsadas por el
costo inicial y el tiempo de comercialización que por el costo del ciclo de vida y
los requisitos de desempeño (tiempo de productividad). Generalmente, las
25
organizaciones que seleccionan las soluciones Tier I y Tier II no dependen de la
entrega o prestación en tiempo real de productos y servicios como su principal
fuente de ingresos. En general, estas organizaciones están protegidas bajo
contrato de los daños causados por la falta de disponibilidad de sistemas.
Normalmente, los requisitos estrictos de tiempo de productividad y viabilidad a
largo plazo son las razones para seleccionar las soluciones estratégicas para la
infraestructura de un sitio de Tier III y Tier IV. Las soluciones para
infraestructura del sitio de Tier III y Tier IV también tienen una vida efectiva
fuera de los requisitos de TI, y generalmente son utilizadas por las
organizaciones que conocen el costo de una alteración, en términos monetarios,
y el impacto en la cuota de mercado y los imperativos constantes de su misión.
Figura 2. Características de los niveles Tier. Fuente: Uptime Institute
26
8.7. Tecnología de virtualización
En 1998, la compañía VMware (Figura 3) descubrió una tecnología que fue
considerada hasta entonces algo imposible de lograr, virtualizar la plataforma de
arquitectura de computadores X86. Esta solución fue una combinación de
traducción binaria (binary translation) y ejecución directa (direct execution) en el
procesador, lo que permitió que múltiples sistemas operativos se pudiesen ejecutar a
la vez en el mismo hardware físico, totalmente aislados unos de otros y con una
sobrecarga en la capa de virtualización relativamente pequeña.
“En un entorno físico tradicional, el sistema operativo y el software asociado se
están ejecutando en un único servidor físico. Este modelo de una aplicación por
servidor puede llegar a ser, y de hecho lo es en muchos casos, inflexible e
ineficiente. Esta relación 1:1 precisamente es la que hace que los servidores de
muchos centros de datos se encuentren subutilizados, alcanzando el uso entre un
5% y un 10% de los recursos físicos de dichos servidores.
Asimismo, el despliegue de servidores físicos en un centro de datos es un proceso
costoso en cuanto al tiempo necesario que demanda aprovisionar un servidor físico.
En un entorno no virtualizado se le dedica más tiempo a la compra de nuevo
hardware e instalar el sistema operativo y las aplicaciones sin considerar el
acondicionamiento y la puesta en marcha de estos servidores físicos.” (Gonzalez,
La virtualización de servidores con Vmware vSphere)
Con el software de virtualización de servidores es posible transformar hardware
en software. De esta manera, podemos ejecutar diferentes sistemas operativos, como
por ejemplo Windows, Linux, Solaris, incluso MS-DOS, simultáneamente y en el
mismo servidor físico. Así, cada contenedor, dotado de su sistema operativo, es
27
llamado virtual machine (máquina virtual en inglés) o VM como acrónimo. Pero la
virtualización no es un software de simulación o emulación sino más bien es un
software de ejecución.
Figura 3 Marcas líderes en sistemas de virtualización. Fuente: Gartner Inc.
8.7.1. Importancia de la virtualización
La importancia de la tecnología de virtualización de optimizar el uso del
hardware del servidor mediante el despliegue de nuevos servidores en máquinas
virtuales, evita añadir más servidores físicos infrautilizados al centro de
cómputo.
28
Por otro lado, reduce drásticamente el tiempo de aprovisionamiento de
nuevos servidores en máquinas virtuales, pasando a minutos en lugar de días o
semanas necesarias para aprovisionar un servidor físico.
Asimismo, como la capacidad de procesamiento de los servidores ha
aumentado de manera constante en los últimos años, y no cabe duda que seguirá
aumentando, la virtualización ha demostrado ser una tecnología muy potente
para simplificar el despliegue de software y servicios, dotando al centro de datos
de mucha más agilidad, flexibilidad y, lo que quizás haya pasado desapercibido
pero no por ello es menos importante, la reducción significativa de los costos
energéticos y el impacto medio ambiental.
El ahorro que decenas de miles de empresas han obtenido con el despliegue
de esta tecnología, está impulsando, de una forma pronunciada y rápida, la
adopción de la tecnología de virtualización desde el centro de datos hasta el
escritorio.
Resolver el problema de la proliferación de servidores, la falta de espacio, el
consumo de energía y la refrigeración en las salas de servidores mediante la
sustitución de servidores de aplicaciones individuales por máquinas virtuales
consolidadas en un número mucho menor de equipos físicos, son solo algunos
de los principales beneficios de la virtualización de servidores.
8.7.2. Razones para la virtualización
1. Consolidación de servidores. Detiene la proliferación de servidores físicos
consolidándolos en máquinas virtuales contenida en un número inferior de
servidores muy potentes.
29
2. Obtención de recursos necesarios con los medios existentes. Pone
rápidamente en marcha aplicaciones y balancea cargas de trabajo entre los
recursos existentes reduciendo en lo posible los sobredimensionamientos.
3. Tolerancia ante desastres. Utiliza la infraestructura virtual para replicar su
centro de datos principal. Replica en máquinas virtuales los servidores críticos.
4. Alarga la vida de los entornos antiguos. Ejecuta antiguas aplicaciones
(legacy) que aún hacen falta en su sistema operativo original sobre modernos
servidores de alto rendimiento.
5. Entornos de prueba y desarrollo. Aprovecha las ventajas de la
infraestructura virtual independiente del hardware para probar gran número de
entornos sobre un pequeño número de sistemas físicos.
6. Virtualización de los puestos de trabajo. Utiliza todas las ventajas de la
virtualización de servidores aplicadas al mundo de las PC.
30
Capítulo 9. Marco metodológico
El contexto actual de la Municipalidad Metropolitana de Lima, en cuanto a la
manera en que son manejados los servicios que brinda la Sub Gerencia de
Informática denota falta de mejoras que no han sido tomadas en cuenta a fin de
eliminar carencias y puntos de falla. De este contexto surge la necesidad previa de
analizar la situación como punto de partida.
El relevamiento de la información como primer paso, recoge el conocimiento de
cómo y dónde, los servicios que la Subgerencia de Informática brinda, se ejecutan.
La mejora de los procesos que brindan servicios, parten de un análisis que es
realizado al resultado que la herramienta del fabricante de virtualización arroja. La
cual sirve para una mejor toma de decisiones con conocimiento de causa.
La herramienta MAP (Microsoft Assessment and Planning Tool) tiene como
objetivo proponer el diseño para la virtualización y consolidación de todos los
servicios en la Municipalidad Metropolitana de Lima. Está basado en las buenas
prácticas de diseño de análisis de capacidades de servidores y equipos de
almacenamiento respecto a entornos virtuales. Las capacidades tomadas se
encuentran acorde al inventario recogido durante el relevamiento de la información
de la infraestructura actual. Esta etapa de diseño es aprobada por el cliente MML y
luego, de acuerdo a ello, se procede con la siguiente etapa de despliegue de
infraestructura para luego iniciar la consolidación de servidores.
31
9.1. Análisis de Microsoft Assessment and Planning Tool
9.1.1. Uso actual de capacidades
Se procede a mostrar el detalle por cada uno de los principales recursos de
computo (cpu, memoria y uso de disco) de las capacidades tomadas en los
servidores actuales de MML.
9.1.1.1. Análisis de capacidades de CPU.
Figura 4 Análisis de capacidades de CPU. Fuente: Microsoft Assessment and Planning Tool.
Como se puede apreciar de la lista del total de servidores existen
servidores que tienen máximo 24 procesadores lógicos asignados (Figura 4),
sin embargo el promedio de uso de procesamiento entre todos los servidores
es de 68% es decir en términos de procesadores lógicos serian 16
procesadores lógicos, así mismo hemos tomado también como métrica que
entre todos los servidores el promedio de asignación de procesadores lógicos
Queda (Varios elementos)
Servicio (Todas)
Cuenta de Computer NameMáx. de Logical
Processor Count
Promedio de Logical
Processor Count
Promedio de Velocidad
CPU (GHZ)
Máx. de Velocidad
CPU (GHZ)
Promedio de Average
CPU Utilization (%)
Promedio de 95th Percentile
CPU Utilization (%)
51 24 3.12 2.45 3.3 68.65 69.58
51
24
3.12 2.45 3.3
68.65 69.58
0
10
20
30
40
50
60
70
80
Total
Cuenta de Computer Name
Máx. de Logical Processor Count
Promedio de Logical Processor Count
Promedio de Velocidad CPU (GHZ)
Máx. de Velocidad CPU (GHZ)
Promedio de Average CPU Utilization(%)
Valores
Cuenta de ... Máx. de Logic... Promedio de Log... Promedio de V... Máx. de Velo... Promedio de Avera... Promedio de 95th Per...
Queda Servicio
32
es de 3.12, así mismo otro dato importante que se ha podido calcular es que
el promedio de velocidad de CPU en GHZ es de 2.45 y la máxima velocidad
es de 3.3 GHZ.
9.1.1.2. Análisis de capacidades de memoria.
Figura 5 Análisis de capacidades de memoria. Fuente: Microsoft Assessment and Planning Tool.
Por otro lado, de los 31 servidores analizados la suma total de memoria
RAM asignada en los servidores actuales es de 370 GB, sin embargo, al
análisis de performance tomado en un escenario en que los servidores usan
el 95% de su memoria, el total es de 308 GB de RAM (Figura 5), también
podemos visualizar que el promedio de máximo de memoria utilizada es de
6.59 GB.
Queda (Varios elementos)
Servicio (Todas)
Cuenta de Computer
Name
Máx. de System
Memory (GB)
Promedio de System
Memory (GB)
Suma de System
Memory (GB)
Promedio de
Average
Memory
Utilization (GB)
Suma de 95th
Percentile
Memory
Utilization (GB)
Promedio de
Maximum
Memory
Utilization (GB)
51 32 7.27 370.52 5.75 308.78 6.59
5132
7.27
370.52
5.75
308.78
6.59
0
50
100
150
200
250
300
350
400
Total
Cuenta de Computer Name
Máx. de System Memory (GB)
Promedio de System Memory (GB)
Suma de System Memory (GB)
Promedio de Average MemoryUtilization (GB)
Suma de 95th Percentile MemoryUtilization (GB)
Valores
Cuenta d... Máx. de Sy... Promedio de ... Suma de Sy... Promedio de Avera... Suma de 95th Perce... Promedio de Maxim...
Queda Servicio
33
9.1.1.3. Análisis de capacidades de disco
Figura 6 Análisis de capacidades de disco. Fuente: Microsoft Assessment and Planning Tool
Como se puede apreciar del total de los servidores inventariados, la
capacidad asignada es de 22 TB aproximadamente (Figura 6), sin embargo,
en un escenario del 95% de uso de recursos, el espacio de disco utilizado es
de 8.3 TB es de decir un 33% aproximadamente, otro dato importante que
podemos utilizar es el promedio de uso de disco de 164.69 GB.
9.1.2. Detalle de los servidores tomados para el análisis.
Los datos indicados en el punto anterior han sido tomados de la siguiente lista
de servidores (Figura 7) y recursos usados por los mismos.
34
Figura 7 Lista de servidores analizados y considerados para la virtualización.
Fuente: Microsoft Assessment and Planning Tool
35
9.1.3. Capacidades de hosts recomendados.
Para determinar el número de hosts en consideraremos los dos recursos
principales de procesamiento CPU y Memoria.
9.1.3.1. Análisis de CPU.
El número de CPU de máquinas virtuales (vCpu) asignados en comparación
con el número de físicos CPU core disponible es la relación vCPU-to-core.
Una relación típica vCPU-to-core para servidor con cargas de trabajo
promedio es de aproximadamente 4: 1, cuatro vCPU asignadas para cada
core físico disponible.
Para nuestro caso de acuerdo al análisis realizado hemos determinado lo
siguiente, tomando en consideración que el promedio de uso de CPU de 68%
aprox. tal como se indica en el punto anterior:
Tabla 2: Análisis CPU
Fuente: Microsoft Assessment and Planning Tool
Como podemos apreciar en base al número actual de servidores y un
crecimiento de 25% a futuro, es necesario un total de 3 hosts (Tabla 2)
considerado adecuado para una carga de trabajo promedio del 68%
36
9.1.3.2. Capacidad de Hosts por memoria.
Hay varios factores que deben ser considerados en el cálculo de los
requisitos de memoria; estos factores incluyen:
1. La cantidad de memoria necesaria para las cargas de trabajo actuales. Para
nuestro caso hemos tomado los resultados del análisis informado en el punto
anterior.
2. La cantidad de memoria necesaria para el crecimiento futuro, este es un
factor variable de acuerdo a los objetivos empresariales de cada negocio, sin
embargo, de manera promedio usaremos un 25%
3. La cantidad de memoria necesaria para sobrecarga de la memoria de la
máquina virtual, la sobrecarga de la memoria de una máquina virtual también
debe tenerse en cuenta en el cálculo requisitos de memoria. La cantidad de
memoria requerida para una sobrecarga depende de la configuración de la
máquina virtual. El número de CPU virtuales asignados a la máquina virtual,
la cantidad de memoria asignada a la máquina virtual, y el hardware virtual
configurado para la máquina virtual, tendrá un impacto en la cantidad de
memoria necesaria para los gastos generales. Típicamente, la sobrecarga de
memoria requerida para una máquina virtual es entre 20 MB y 150 MB.
Esto puede parecer una pequeña cantidad de memoria, pero a lo largo de
decenas o incluso cientos de máquinas virtuales, pueden tener un impacto
significativo en la cantidad de memoria total requerida.
4. El umbral máximo de utilización de la memoria, debe ser determinada
para los recursos de memoria. Este umbral define lo que es el porcentaje
37
máximo del total de recursos de memoria que se consumirá. Si el umbral
máximo de utilización es 75%, un adicional de 25% necesario de los recursos
de memoria será añadido con el fin de calcular el total los recursos de
memoria necesarios
De acuerdo a los conceptos indicados para el caso de las capacidades de
MML tenemos lo siguiente:
Tabla 3: Análisis memoria
Fuente: Microsoft Assessment and Planning Tool
De acuerdo a lo calculado en base a las cargas de trabajo actual, a un
crecimiento futuro del 25%, se requiere un total de 564GB de RAM (Tabla 3).
Los hosts son de mayores capacidades para satisfacer las necesidades de
recursos. Más máquinas virtuales se ejecutan en un solo host; La desventaja es
que más máquinas virtuales podrían ser afectadas por un fallo del Host.
En este escenario se consideran 3 hosts de 512 GB de RAM es adecuadamente
suficiente para cubrir la demanda requerida en base a los recursos de memoria.
Number of Workloads 51
Current Memory Required
Promedio de Memoria Uti l i zado según anal is is
rea l izado.
6.59
Total Current Memory Required 335.87
Promedio de Logical Processor Count 3
Memory Overhead (MB) 60.67
Total Memory Overhead (GB) 3.02
Current Memory Required (inc. Overhead) 338.89
Future Growth 25%
Current Memory Required (inc. Growth) 423.61
Maximum Threshold (%) 75%
Total Memory Resources Required (GB) 564.82
38
Tabla 4: Análisis de memoria por host
Fuente: Microsoft Assessment and Planning Tool
Como se muestra al soportar la solución en 3 hosts, el uso de las capacidades de
memoria al estar activos todos los hosts, su uso sería del 39% (Tabla 4) mientras
que en estado de contingencia seria de 57% el cual soportaría adecuadamente lo
requerido para un escenario de alta disponibilidad (N+1).
9.1.4. Diseño de Hosts
De acuerdo a los recursos tanto de CPU y memoria requerida se puede
implementar el cluster de MML con 3 Hosts de 2 procesadores de 10 core de
2.40GHZ con 512 GB de RAM, requeridos para poder soportar la infraestructura
virtual de MML en un escenario agresivo (Figura 8).
Con estas capacidades se soportaría un escenario de N+1 en alta disponibilidad y
adecuada redistribución de recursos.
39
Figura 8 Diseño de Hosts propuestos. Fuente: Microsoft Assessment and Planning Tool
Ventajas
Menor costo pues se requiere adquisición adicional de memoria en menos
Hosts y menos costes en licenciamiento por hosts.
A nivel de memoria soporta un escenario N+1 óptimamente.
Mayor capacidad de recursos para crecimiento futuro en lo que respecta a
memoria.
Desventajas
Mayor riesgo a nivel de cluster al tener menos Hosts, aumenta los puntos de
falla en número de máquinas virtuales en caso un incidente de algún Host.
40
9.1.5. Capacidad de almacenamiento.
9.1.5.1. Determinando Storage Performance requerido.
El rendimiento del disco se mide en I/O por segundo (IOPS). Una solicitud
de lectura en disco o una solicitud de escritura en disco es igual a un I/O.
Los IOPS necesario para apoyar una solicitud se calcula basándose en el
porcentaje de lectura de I/O, el porcentaje de escritura de I/O, y la penalidad
de escritura del nivel de RAID en la carga de trabajo será alojado.
La penalidad de escritura se basa en el número de operaciones de I/O de una
configuración RAID específica requerida para una sola solicitud de escritura.
La escritura de datos en varios discos en un mirror o los cálculos de paridad
en una configuración RAID 5 o RAID 6 añade las operaciones de I/O a la
solicitud de escritura. La petición de escritura no se completa hasta que los
datos y la paridad se escriben en los discos.
Tabla 5: Análisis de almacenamiento
Fuente: Microsoft Assessment and Planning Tool
Current workloads 51
future workloads 25%
Total workloads 64
Average Disk IOPS 13.02
%Reads 60%
%Writes 40%
Workload IOPS * %Read 7.81
Workload IOPS * %Writes 5.21
Write Penalty (RAID 5) 4
Functional Application IOPS 28.64
Total de IOPS 1,825.53
Drive Speed ~ IOPS Nro De Discos
Discos de 15K SAS/FC 175 10.43
Discos de 10K SAS/FC 125 14.60
Discos 7200 NL-SAS/SATA 75 24.34
41
Como se puede apreciar en este análisis de acuerdo a la cantidad de IOPS
(Tabla 5) requerido de las estadísticas tomadas se requiere un mínimo de 10
discos de 15K en RAID 5 ó 15 discos de 10K en RAID 5.
9.1.5.2. Calculando capacidad de almacenamiento requerido.
La capacidad se mide en Gigabytes (GB) o Terabytes (TB). La capacidad
debe incluir el espacio total que se necesita para apoyar el actual, el espacio
necesario para apoyar el crecimiento, el espacio necesario para swapfiles de
máquinas virtuales, y el espacio de holgura adicional para los snapshots y
otros datos de la máquina virtual.
Para el caso de MML de acuerdo a la información analizada tenemos se ha
determinado lo siguiente requerido:
Tabla 6: Cálculo de almacenamiento requerido
Fuente: Microsoft Assessment and Planning Tool
Current workloads 51
Growth Capacity 25%
Total workloads 64
Average Disk Use (GB) 164.69
Current Capacity + Growth Capacity (GB) 10,499.16
Slack space 20%
Slack space (GB) 2,099.83
Capacity required (GB) 12,599.00
Capacity required (TB) 12.30
vSwap Capacity
Current Memory Required
Promedio de Memoria Uti l i zado según
anal is is rea l izado.
4.27
vSwap Capacity (GB) 272.29
Capacity required (GB) 12,871.28
Capacity required (TB) 12.57
42
Como se puede apreciar es necesario un promedio de 12TB de capacidad
(Tabla 6) para soportar la actual demanda de espacio, adicionando un 25% de
capacidad de crecimiento, holgura del 20% que Vmware recomienda para
diferentes tareas administrativas y la capacidad de almacenamiento usado por
la memoria vSwap por cada máquina virtual alojada.
Esta capacidad no cubre el 100% de las capacidades asignadas en los recursos
actuales, la capacidad calculada requerida es superior (35%) a la máxima
capacidad de almacenamiento usada actualmente lo cual está acorde a la
realidad actual.
De acuerdo a las buenas prácticas de fabricantes de equipos de
almacenamiento, en un arreglo de discos RAID 5 el máximo número de discos
son 8 + disco de paridad, de acuerdo esto se propone los siguientes escenarios
de distribución de disco en RAID 5 en diferentes capacidades de 900GB y
600GB.
Tabla 7: Arreglo de discos
Fuente: fuente propia
De acuerdo a esto, se propone la creación de 2 conjuntos de RAID 5 (Tabla 7),
uno de 9 discos (8 data +1 Paridad), y el otro de 7 Discos (6 data + 1 Paridad).
Este escenario de acuerdo al análisis de performance estaría acorde a lo
requerido en IOPS con discos de 15K.
Tipos de Discos GB Nro. Discos Nro De Raid Discos ParidadTotal Disco
po Raid
Discos de 900 GB 900.00 14.30 8 1 9
6 1 7
16 Total Discos
2
43
9.2. Diseño de la infraestructura virtual
9.2.1. Inventario de componentes VMware
La siguiente es una lista (Tabla 8) de hardware y software que compone la
arquitectura de la infraestructura virtual, se detallan las especificaciones y
configuraciones para cada ítem.
Tabla 8: Componentes de infraestructura virtual
Item Nombre / Descripción
Server Host 1 VSphere Nombre por definir. munlima.local
Servidor (Host) número 1, el cual es
componente de un Cluster.
Server Host 2 VSphere Nombre por definir. munlima.local
Servidor (Host) número 2, el cual es
componente de un Cluster.
Server Host 3 VSphere Nombre por definir. munlima.local
Servidor (Host) número 3, el cual es
componente de un Cluster.
Cluster: HA Nombre de cluster por definir
Cluster compuesto por 3 Hosts y ofrece
funcionalidades de HA a las maquinas
virtuales creadas dentro del mismo.
VCenter Server Nombre por definir. munlima.local
Servidor donde será instalada la herramienta
de administración del VSphere 5.
Shared Storage NetApp FAS3210A de 12TB
Licencias utilizadas VSphere Enterprise para 6 procesadores: (2
por cada Server Host)
VCenter Server Standard: 1
Fuente: fuente propia
44
9.2.2. Especificaciones para Server Hosts
Esta sección proporciona detalles acerca de componentes para cada Server Host
(Tabla 9) previamente definido en el inventario de componentes. La plataforma
se definió en base a los requerimientos y preferencias por parte del cliente. Las
especificaciones para esta plataforma son descritas a continuación:
Tabla 9: Especificaciones técnicas de Hosts
Atributos Especificaciones
Número de Hosts requeridos 3 (Tres)
Hostnames
Nombre host 1 por definir. munlima.local
Nombre host 2 por definir. munlima.local
Nombre host 3 por definir. munlima.local
Dirección IP Parámetros de direccionamiento IP por definir
Fabricante Cisco
Modelo UCS B200 M2
Número de procesadores:
Tipo de procesador
2
Intel® Xeon® Processor E5649
(12M Cache, 2.53 GHz, 5.86 GT/s Intel® QPI)
2.53 GHz
Memoria 48 GB
Número de Mezanine NIC
Fabricante de NIC mezanine
Modelo de NIC mezanine
Velocidad de NIC
1 por server host
Cisco
UCS-VIC-M82-8P
10 Gigabit
Número de discos locales
RAID Level
Total de capacidad
2 por server host
1
300 GB
VSphere Server Version 5.0 Upd 1
Fuente: fuente propia
45
9.2.3. Especificaciones de Servidor VCenter
Esta sección proporciona detalles de cada componente del servidor VCenter
(Tabla 10) previamente identificado en la lista de materiales. Posteriormente se
instalará también sobre este servidor, la solución de respaldo adquirida
conviviendo de manera óptima con el VCenter. A continuación, indicamos los
requerimientos del servidor VCenter, basado en preferencias de la plataforma
que maneja el cliente.
Tabla 10: Especificaciones técnicas de VCenter
Atributos Especificaciones
Número de servidores requeridos 1 (uno)
Hostname y dirección IP Por definir
Dominio munlima.local
Físico o Virtual Físico
Fabricante HP
Modelo Proliant DL360p Gen8
Numero de Procesadores
Tipo de Procesador
1
Intel® Xeon® Processor E5-2640
(15M Cache, 2.50 GHz, 7.20 GT/s Intel®
QPI)
Memoria 16GB
Número de puertos de red 4
Número de Discos Locales
Nivel de Raid
Capacidad total
2
1
146GB
Sistema Operativo Windows 2008 R2 Standard 64 bits
Versión Virtual Center 5.0 Upd 1a
Fuente: fuente propia
46
9.2.4. Configuración de Networking
Esta sección proporciona detalles de la configuración de Networking para los
Servers Host (Tabla 11). En la implementación de infraestructura virtual se usa
los tipos de conexión de red: red de máquinas virtuales (Virtual Machine Port
Group) y red de administración (VMkernel Port). Todas las máquinas virtuales y
VMkernel (para VMotion) se conectarán a switches virtuales, en los cuales están
creados los portgroups.
Tabla 11: Especificaciones técnicas de hosts
vSwitch Adaptador Físico Tipo de
Conexión
Network Segment:
VLAN
vSwitch0 vmnic0, 1000 Full VMKernel Red de administración
(IP de server host)
vSwitch1 Vmnic1, 1000 Full Virtual Machine
IP de LAN
Vmnic2, 1000 Full
vSwitch2 Vmnic3, 1000 Full VMotion IP interna
Fuente: fuente propia
Esta configuración asegura el manejo del tráfico para temas de alta
disponibilidad para todas las redes. Todos los switch físicos conectados a los
NICS de los servidores Server Host son los que permitirán conectar las
máquinas virtuales a la red LAN de la empresa.
9.2.5. Especificaciones de Storage
La siguiente sección proporciona detalles referidos a la configuración del
Storage (Tabla 12):
Tabla 12: Especificaciones de storage
Elemento Especificación
Fabricante de SAN NetApp
47
Modelo de SAN
FAS 3210A
Numero de Storage
1 (uno)
LUN size
500GB (data) (12 LUN)
1TB (data) (6 LUN)
Fuente: Fuente propia
Cada servidor Server Host cuenta con discos locales sobre los cuales se definirá
una partición VMFS para VMware y donde se instalará el sistema operativo
VSphere 5. (Tabla 13).
Los requerimientos de SAN Storage para VMware, generalmente son para
ambientes con alta carga en acceso a LUNs (Tabla 14), de manera que se
administra performance y requerimientos de disponibilidad, en la siguiente tabla
se provee la configuración a nivel de storage.
Tabla 13: Distribución de storage
Item Status Motivo
Tamaño
de LUN
146GB
(Local)
Se aprovecha disponibilidad de
espacio en disco local en cada
Server Host para que sea utilizado
por VMware.
Tamaño
de LUN
500GB (data) (12 LUN)
1TB (data) 61 LUN)
Se definió 18 LUNs del Storage
NetApp para que sea utilizado por
VMware.
LUN RAID
1 (Local)
Basado en el arreglo de disco
local dispuesto para cada Host.
5 (SAN)
Basado en un alto ratio de
lectura/escritura, se determinó que
RAID 5 sea el tipo de arreglo de
storage asegurando la alta
disponibilidad.
Fuente: fuente propia
48
La nomenclatura de los nombres para los LUNs (Tabla 14) está definida de la siguiente
manera:
Tabla 14: Nomenclatura de storage
Nombre de
Storage
RAID5 Capacidad Tipo de Data
storage1
RAID1
146 GB
Estará contenido
sistema operativo y
Templates de VMs.
DS_SANn
RAID5
500GB ó 1TB
Estará contenido
particiones de
sistema operativo
de las VMs
Corresponde a la
LUNn.
Fuente: fuente propia
9.2.5.1. Redundancia de Storage
Para reducir potenciales puntos de falla y asegurar la redundancia la
arquitectura presenta lo siguiente (Tabla 15) para disponibilidad del storage:
Tabla 15: Redundancia en storage
Punto de Falla Redundancia
Server Host interfaz VIC M82 por host
SAN Fibre Channel Switch 2 switches de fibra físicos
Arreglo de Storage 2 storage processors (controladoras) del
storage NetApp FAS 3210A
Fuente: fuente propia
9.3. Arquitectura Datacenter en vCenter
Esta sección proporciona detalles sobre la arquitectura del Datacenter en VCenter.
49
Nombre Datacenter
VCenter organiza a los Host VMware ESXi en Datacenters, que incluye todos los
ambientes y recursos compartidos. Aquí se presenta la nomenclatura:
<Nombre_datacenter>
Se debe definir nombre para Datacenter. Ejemplo: MML-DC.
Todos los Hosts se encontrarán dentro de ese datacenter y será el ambiente de
producción. Este datacenter estará conectado a LUNs formateados como volúmenes
VMFS. Estarán compartidas a todos los Server Host de manera que la
infraestructura virtual soporte características de VMotion, y VMware HA.
Nombre Cluster
Todos los Server Hosts que pertenecen al Datacenter pertenecerán a un solo Cluster
VMware. Los Server Hosts estarán agrupados y proveerán de los servicios VMware
HA a las máquinas virtuales.
<Nombre VMware Cluster>
Se debe definir nombre para Cluster. Ejemplo: MML.
Todos los Server Hosts estarán incluidos dentro de este cluster, así como las
máquinas virtuales de la organización.
50
9.3.1. Gráfico de infraestructura virtual
El siguiente gráfico (Figura 9) muestra la configuración de infraestructura virtual
desarrollada para la Municipalidad Metropolitana de Lima.
Figura 9: Infraestructura virtual propuesta luego de análisis y especificaciones. Fuente: fuente propia
Además, la actual solución de respaldo de información, se integra de manera
nativa (Figura 10) con el sistema de virtualización considerando únicamente las
licencias necesarias para ello.
51
Figura 10: Solución de respaldo en la actualidad en MML. Fuente-. Fuente propia
9.4. Monitoreo de arquitectura VI
Las opciones de monitoreo se encuentran disponibles desde el Servidor Server
Host, desde el Servidor vCenter y desde alguna estación con el software VI Client
instalado y acceso a los Server Host.
La gestión efectiva de toda la infraestructura VMware reside en el vCenter
(Figura 11), consola que centraliza la administración de todos los componentes del
Datacenter Virtual que incluye: Server Host, Cluster, virtual machine, virtual
network, datastore, grupos y usuarios, entre otros.
La interface VI Client deberá ser instalada en las estaciones de trabajo de los
administradores de red o personal a cargo de la administración de la Infraestructura
Virtual.
52
Figura 11: Consola de administración centralizada del sistema convergente de virtualización. Fuente: Herramienta de gestión de sistema instalado en la MML.
9.5. Diseño del centro de cómputo
Dentro del actual centro de cómputo de la MML se encuentran elementos
como energía para la operación de los equipos de cómputo, así como aire
acondicionado necesario para mantener a los equipos de cómputo en condiciones
óptimas de operación. Ambos elementos soportan las nuevas cargas estimadas
que se añaden con el sistema de virtualización. De acuerdo al actual mapa del
centro de cómputo (Figura 12), el factor espacio es una limitante a agregar un
nuevo rack de servidores.
53
Figura 12: Mapa de centro de cómputo en MML previo a la consolidación de servidores. Fuente: Levantamiento de información registrada en estudios previos a la consolidación. Fuente propia.
Considerando todos los servidores a ser virtualizados (Tabla 20) y que son
tema del actual estudio, el diseño cambiará, de acuerdo al mapa (Figura 13),
gracias a la tecnología de virtualización trayendo beneficios para la MML como
son menores costos operativos, administración centralizada, flexibilidad que
permitirá atender necesidades futuras, robustez por el uso de tecnologías
confiables.
54
Figura 13: Mapa de centro de cómputo en MML posterior a la consolidación de servidores. Fuente: Levantamiento de información para el registro de la solución. Fuente propia.
La infraestructura convergente (Figura 14) con componentes de alta densidad,
soportará el sistema que finalmente consolide los servidores físicos de la MML.
Fabricantes de sistemas convergentes como Cisco y NetApp, integran en una
sola plataforma los recursos de cómputo, almacenamiento, redes, virtualización
y administración con el centro de cómputo de forma unificada.
55
0a 0b
LNK LNK
0c
0d e0b
e0a
c0b
c0a
1
2
TOP
iLO
UID
4 1
42
41
40
39
38
37
36
35
34
33
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
42
41
40
39
38
37
36
35
34
33
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
42
41
40
39
38
37
36
35
34
33
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
42
41
40
39
38
37
36
35
34
33
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1U01
U02
U03
U04
U05
U06
U07
U08
U09
U10
U11
U12
U13
U14
U15
U16
U17
U18
U19
U20
U21
U22
U23
U24
U25
U26
U27
U28
U29
U30
U31
U32
U33
U34
U35
U36
U37
U38
U39
U40
U41
U42
Vista Frontal Vista Posterior
FAS3210FAS3210
SLOT
1
SLOT
5
SLOT
3
SLOT
7
SLOT
2
SLOT
6
SLOT
4
SLOT
8
!
UCS 5108
OK FAIL OK FAIL OK FAIL OK FAIL
FAN STATUS
FAN STATUS
FAN STATUS
FAN STATUS
FAN STATUS
FAN STATUS
FAN STATUS
FAN STATUS
CHS A56
FAN 1 FAN 5 FAN 2 FAN 6 FAN 3 FAN 7 FAN 4 FAN 8
!
8
7
6
5
UCS 2208XP
4
3
2
1
8
7
6
5
UCS 2208XP
4
3
2
1! ResetConsole
! !
UCS B200 M1
! ResetConsole
! !
UCS B200 M1
! ResetConsole
! !
UCS B200 M1
! ResetConsole
! !
UCS B200 M1
ProLiant
DL360p
Gen8
UIDSID
3
4
1
2
5
6 7 8
1200W
PLC B
94%
SAS
2 p
ort
15k
14
6 G
BSA
S
2 p
ort
15k
14
6 G
B
HP
StorageWorks
MSL2024
Tape
LibraryReady Clean Attention Error Cancel
NextPrevious
Enter
1
2
3
4
5
6
7
89
10
11
12
13
14
15
16
100-240V~, 0.5A, 50/60 Hz
T 2A, 250 VAC CAUTION: For continued protection against risk of fire, replace only with the same type and rating of fuse.
L AN
DS4243
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
CAUTION
3
1
4
2
CAUTION
3
1
4
2
CAUTION
3
1
4
2
CAUTION
3
1
4
2
Disconnect allsupply power forcomplete isolation.
Disconnect allsupply power forcomplete isolation.
Disconnect allsupply power forcomplete isolation.
Disconnect allsupply power forcomplete isolation.
IOM3
IOM3
LIN
K
LIN
K
IOM3
IOM3
LIN
K
LIN
K
O I
DS-C48-300AC
100 – 240VAC
4 – 2 A
50 – 60 Hz
INPUT
OK
OUPUT
OK
O I
DS-C48-300AC
100 – 240VAC
4 – 2 A
50 – 60 Hz
INPUT
OK
OUPUT
OK
DS-C9148-K9
P/S
FAN
STATUS
CO
NS
OL
EM
GM
T 1
0/10
0
LINK ACT
MDS 9148 Multilayer Fabric Switch11 129 107 85 63 41 2 23 2421 2219 2017 1815 1613 14 35 3633 3431 3229 3027 2825 26 47 4845 4643 4441 4239 4037 38
PS
1P
S2
FAN
STAT
FAN
STATFAN1
FAN2
FAIL
OK
FAIL
OKID
STAT
MGMTOL1
L2 CONSOLE
CISCO UCS 6248UP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
STAT
ID
PS
1P
S2
FAN
STAT
FAN
STATFAN1
FAN2
FAIL
OK
FAIL
OKID
STAT
MGMTOL1
L2 CONSOLE
O I
DS-C48-300AC
100 – 240VAC
4 – 2 A
50 – 60 Hz
INPUT
OK
OUPUT
OK
O I
DS-C48-300AC
100 – 240VAC
4 – 2 A
50 – 60 Hz
INPUT
OK
OUPUT
OK
DS-C9148-K9
P/S
FAN
STATUS
CO
NS
OL
EM
GM
T 1
0/10
0
LINK ACT
MDS 9148 Multilayer Fabric Switch11 129 107 85 63 41 2 23 2421 2219 2017 1815 1613 14 35 3633 3431 3229 3027 2825 26 47 4845 4643 4441 4239 4037 38
CISCO UCS 6248UP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
STAT
ID
0a 0b
LNK LNK
0c
0d e0b
e0a
c0b
c0a
1
2
AJ7
64A
PO
RT
1
10G
bES
FP
PO
RT
2L
A
L
A
T X R X T X R X
NC
552S
FP
LTO 5
Switch MDS 9148
Tape Library MSL 2024Proliant DL360p G8
TFT 7600
Chasis UCS Blade
DS4243
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
600GB
CAUTION
3
1
4
2
CAUTION
3
1
4
2
CAUTION
3
1
4
2
CAUTION
3
1
4
2
Disconnect allsupply power forcomplete isolation.
Disconnect allsupply power forcomplete isolation.
Disconnect allsupply power forcomplete isolation.
Disconnect allsupply power forcomplete isolation.
IOM3
IOM3
LIN
K
LIN
K
IOM3
IOM3
LIN
K
LIN
K
Controladora de discos
FAS 3210HA
Gabinete de discos DS4243
Fabric Interconect
Figura 14: Ubicación del sistema convergente en gabinetes de la MML. Fuente: Levantamiento de información para el registro de la solución. Fuente propia.
56
Capítulo 10. Evaluación financiera
El análisis de la evaluación financiera parte del precio aceptado en la propuesta
económica que define la infraestructura que sirve de base para la virtualización de
servidores.
Tabla 16: Costo de sistema convergente
Item Descripción Técnica Cant. P. Total S/.
Servidores Cisco UCS
Servidores Cisco B200 M3
2 procesadores de 8-cores E5-2665 2.4Ghz
512 GB RAM
Discos Duros: 2 x 146Gb 10K
4 ports 10G FoE
02 Licencias de VMware vSphere Enterprise 5 por servidor
GarantíaHardware: Soporte 24 x7 con tiempo de respuesta
de 4 horas por (3) tres años
Garantía Software: Soporte telefonico 24 x7 por (3) tres años.
Incluye chasis para blades y rack
Instalación de hardware incluida
Storage NetApp FAS3210A
Discos: 24x600GB SAS 15K RPM 6Gbps
12 TB efectivos
Garantía: SupportEdge Premium. 3 años, 24x7.
4 horas tiempo de cambio de partes
Instalación de hardware incluida
S/. 485,000.00
1 4
2 1
Total Propuesta Economica (incluye IGV) S/.
Fuente: fuente propia
Los recursos humanos asignados por la Municipalidad Metropolitana de
Lima para el proyecto de virtualización de servidores son calculados a través de
la calculadora salarial y representa para la entidad, el costo real por empleado.
57
Tabla 17: Costo personal MML
7,000 9,718 1 JSI 10% 971.80 10% 971.80 5% 485.90 10% 971.80 3,401.30
5,000 6,741 1 ADM 25% 1,685.28 50% 3,370.55 25% 1,685.28 15% 1,011.17 7,752.27
4,000 5,303 1 ANA 0% - 0% - 25% 1,325.75 50% 2,651.50 3,977.25
2,657.08 4,342.35 3,496.93 4,634.47 15,130.82
NOTA: Todos los montos están expresados en nuevos soles
JSI JEFE DE SISTEMAS
ADM ADMINISTRADOR DE RED
ANA ANALISTA
TOTALES
TOTALmes-1 mes-2 mes-3 mes-4
CONSOLIDACIÓN Y CONFIGURACIÓN PRUEBAS Y ENTREGASUELDOC.EMPRESACantidad Cargos
INICIO
Fuente: estimaciones realizadas con Calculadora Salarial.
El costo total del proyecto (Tabla 18) de virtualización incluyendo al personal de
la MML asignado al proyecto es:
Tabla 18: Costo del proyecto
Costo de implantación de solución S/. 485,000.00
Gastos asignados S/. 15,130.82
Costo Total S/. 500,130.82
Fuente: fuente propia
La nueva infraestructura tanto de almacenamiento como de servidores,
representaran un consumo eléctrico estimado de:
Tabla 19: Consumos eléctricos estimados
Equipo Consumo Kw/Hr
Almacenamiento NetApp 1.196
Servidores Cisco UCS 1.009
Estimado 2.205
Fuente: fuente propia
58
Las herramientas de los fabricantes NetApp (Figura 15) y Cisco (Figura 16)
en cuanto al consumo estimado por los equipos a implantar son exactas y sus
resultados están en base a configuraciones entrantes de cantidad y modelo de
equipo a instalar.
Figura 15. Consumo estimado en componente de storage. Fuente: Especificaciones técnicas de storage NetApp.
De acuerdo al consumo actual y al estimado, cuando la nueva infraestructura
se encuentre instalada y operando representará un ahorro del 38.36% en costos
operativos.
59
Figura 16. Consumo estimado en componente de servidores. Fuente: Especificaciones técnicas de servidores Cisco.
Este porcentaje de ahorro representa el reemplazo de la actual infraestructura
de servidores Dell (Tabla 20) de formato rack por los nuevos servidores Cisco
UCS, así como el sistema de almacenamiento NetApp.
Tabla 20: Modelos de servidores físicos a virtualizar
Rack 1
Rack 2 Rack 3
Proliant DL320 G5p
Power Vault MD1000 Power Edge R510
Power Edge SC 1425
Power Vault MD3000i Power Edge R710
Power Edge SC 1435
Power Edge R710 Power Edge R710 Power Edge SC 1425
Power Edge R510 Power Edge R510
Power Edge SC 1425
Power Edge R710 Power Edge R510
Power Edge SC 1425
Power Edge R710 Power Edge R610
Power Edge SC 1425
Power Edge R510 Power Edge R510
Power Edge 2900
Power Edge R510 Power Edge R710
Power Edge 2900
Power Edge R610 Power Edge R710
Power Edge 2900
Power Edge R610
Power Edge 2900
Power Edge R610
Power Edge SC 1435
Power Edge R610
Power Vault MD3000i
Power Edge 2950
Power Vault MD3000i
Power Edge 2900
Power Edge = Modelo de servidores Dell Power Vault = Modelo de storage Dell
Fuente: Información registrada en MML.
60
Considerando los actuales consumos eléctricos de los servidores Dell (Figura
17), los nuevos sistemas informáticos demandarán solo el 30% de su capacidad
para reemplazar la actual infraestructura, es decir permitirá que la Municipalidad
Metropolitana de Lima ofrezca nuevos y mejores servicios para brindar ya que
cuentan con aproximadamente 70% de disponibilidad para crecimiento.
Figura 17. Actuales consumos eléctricos en servidores Dell. Fuente: Cálculo de acuerdo a especificaciones del fabricante.
Este análisis de flujo de caja (Tabla 20. Anexo 1) solo considera que con los
consumos eléctricos estudiados, tanto de la infraestructura anterior como la
solución nueva implementada, la recuperación de la inversión (ROI) llegaría en
el mes 14. No se considera que con la nueva infraestructura, la MML cuenta con
beneficios como continuidad del negocio versus problemas de disrupciones de
servicios registrados anteriormente y que son complejos de cuantificarlos,
reducción en gastos operativos, administración centralizada y sencilla de la
nueva plataforma.
Se considera que los beneficios son aún mayores, pero no son listados ya que,
solo considerando la energía eléctrica, este proyecto presenta retornos dentro de
su periodo de vigencia contractual.
61
Capítulo 11. Desarrollo del proyecto de consolidación
La siguiente es la lista de actividades consideradas durante la ejecución del proyecto,
así como el cuadro Gantt (Figura 18) que detalla las actividades en la línea de tiempo de
4 meses de ejecución.
11.1. Actividades del proyecto
1. Inicio
1.1. Reunión de kick off
1.2. Lista de documentos requeridos (seguros, certificaciones y
antecedentes)
1.3. Adquisición de equipos y software
1.4. Ejecución de estudio de capacidades
1.5. Análisis de estudio de capacidades
2. Diseño y plan de virtualización de la solución
2.1. Diseño de hardware a implementar
2.1.1. Informe Pre Delivery
2.1.2. Documento de diseño de hardware a implementar
2.1.3. Aprobación del documento de diseño de hardware
2.2. Diseño de la arquitectura de Vmware
2.2.1. Diseño de la configuración LAN y SAN
62
2.2.2. Diseño de la configuración Vmware de los hosts y la granja
de virtualización
2.2.3. Diseño de la capacidad, layout de discos y datastores para
la solución de virtualización
2.2.4. Aprobación del documento de diseño de arquitectura
Vmware
2.3. Plan de virtualización y migración de servidores
2.3.1. Definición de requisitos para la virtualización de servidores
2.3.2. Planificación de la ruta de virtualización (Físico a Virtual)
2.3.3. Planificación de la ruta de virtualización (Virtual a Virtual)
2.3.4. Planificación de la ruta de reasignación de storage a
servidores físicos
2.3.5. Elaboración del plan de virtualización y migración de
servidores
2.3.6. Validación y aprobación del plan
3. Ejecución
3.1. Implementación de la arquitectura de servidores
3.1.1. Montaje y ensamblaje de equipos
3.1.2. Cableado de servidores y storage
3.1.3. Actualización de firmware de servidores y storage
63
3.1.4. Pruebas funcionales de la nueva plataforma virtual
3.1.5. Pruebas funcionales de la nueva plataforma virtual
3.1.6. Documento de implementación
3.2. Virtualización de servidores físicos a virtual
3.2.1. Respaldo de servidores a virtualizar
3.2.2. Preparación de servidores a migrar
3.2.3. Virtualización de servidores
3.2.4. Estabilización de servidores
3.2.5. Verificación y prueba de servicios
3.2.6. Resolución de casos y/o problemas post-virtualización
3.2.7. Informe de migración de servidores
4. Control y seguimiento
4.1. Comité semanal Nro. 1
5. Cierre
5.1. Reunión de cierre
5.2. Acta de conformidad
64
11.2. Entregables
1. Informe técnico con estudio de capacidades
2. Informe pre delivery
3. Documento de diseño de la solución
4. Plan de implementación. Cronograma de actividades
5. Documento de implementación final de la solución
6. Niveles de escalamiento de soporte
7. Transferencia de conocimientos
8. Acta de conformidad
11.3. Cronograma de actividades
Tabla 21: Cronograma de actividades
2015
Fase Actividad Octubre Noviembre Diciembre Enero
I Inicio 19 días
II Planificación 19 días
III Ejecución
IV Cierre 4 días
Duración del proyecto
2014
91 días
114 días
Fuente: fuente propia
65
Figura 18. Gantt de la ejecución del proyecto de consolidación en la MML. Fuente: fuente propia
66
Capítulo 12. Conclusiones
La Municipalidad Metropolitana de Lima cuenta ahora con una solución
informática sostenible que permite establecer mejores procesos para lograr una
mayor eficacia y efectividad en sus diversos sistemas como los Sistemas Integrados
de Gestión, Sistemas Catastrales, Sistemas de Información Geográfica, Sistemas de
Sección Vial, Sistemas de aplicaciones propias, Sistemas de Archivos, así como en
Bases de Datos. Esto facilita la toma de decisiones más efectiva, aumenta el nivel de
transparencia, automatiza y optimiza procesos, reduce los costos financieros y los
plazos en las transacciones y permite tomar acciones e iniciativas sobre los recursos
disponibles.
Fue necesario, para ello, el uso de los recursos de Tecnologías de la Información
y Comunicación aplicados a las necesidades y problemas en los sectores productivos
dentro de la administración de la Municipalidad.
De acuerdo a lo expuesto en el presente documento, las entidades públicas y en
particular la Municipalidad Metropolitana de Lima, cuenta ahora con una serie de
potencialidades técnicas que explotar y que con la adecuada dirección pueden
encaminarse hacia la Sociedad de la Información.
Por otro lado, para la Comisión Económica para América Latina y el Caribe
(CEPAL), el Gobierno Electrónico, desde el punto de vista tecnológico, consiste en
“El mejoramiento de la gestión gubernamental utilizando las Tecnologías de la
Información y las Comunicaciones con el objetivo de desplegar servicios
electrónicos para los ciudadanos y empresas, modernizando el Estado y obteniendo
como resultado un mejor control, transparente y efectivo de la administración
pública.”
67
Acorde con desarrollar el Gobierno Electrónico es necesario, además, la
adecuación normativa y de procedimientos de la Municipalidad Metropolitana de
Lima para que acepte e incentive los procedimientos electrónicos en su operación
diaria. Para ello debe desarrollar los siguientes puntos:
1. Institucionalizar el liderazgo necesario para facilitar el despliegue efectivo de
las TIC dentro de la Municipalidad.
2. Incentivar la producción, el despliegue y el mantenimiento de contenidos y
servicios electrónicos.
3. Incentivar el despliegue y uso de las TIC, así como de las soluciones y los
servicios electrónicos desarrollados por la administración pública.
4. Fortalecer sus unidades informáticas, estandarizando su jerarquía, potenciando
su operación e impulsando su integración electrónica, dotándolas de los recursos
necesarios para administrar los servicios informáticos, potenciando sus sistemas
y recursos de red, y otorgándoles los medios requeridos para simplificar y
mecanizar sus procesos internos.
Es importante garantizar los recursos económicos y otros que permitan sustentar
en el tiempo el desarrollo del presente proyecto de virtualización. En tal sentido, la
Municipalidad Metropolitana de Lima deberá considerar, en sus respectivos
presupuestos y planes operativos, los medios y acciones pertinentes destinados a
desarrollar futuros proyectos y en forma coordinada, evitando duplicidad de gastos
en recursos estatales.
68
En lo técnico podemos concluir que, en términos generales, el estado de la
plataforma virtual puede ser explicado bajo los siguientes criterios: estabilidad,
rendimiento, escalabilidad y crecimiento.
En el rubro de estabilidad, se concluye que representa una mejora del 100% y es
la característica más relevante en función a la situación original de la plataforma
computacional en La MML, previa al proyecto de virtualización, en donde se
presentaban excesivos cortes de servicio.
Los hosts ESXi, VMs y el cluster virtual, en general, están operando con
normalidad y sin alertas que reporten fallas puntuales. Sin embargo, la arquitectura
de la solución virtual tiene elementos redundantes que la hacen potencialmente
robusta ante caídas de operación. Se detallan los más importantes, en orden de
prioridad:
El más crítico de ellos es la conectividad de red. Actualmente los cuatro puertos
de red con los que dispone cada host ESXi, representan los uplinks de los virtual
switch creados en el ambiente virtual otorgándoles redundancia a todos los
portgroups existentes, incluyendo la red de los servidores virtuales. Esta situación
sumada a la conectividad externa (plataforma física – networking) hacen de la red
un elemento potente ante alguna caída de servicio externa.
La conectividad de I/O de SAN es redundante tanto a nivel físico y virtual lo que
convierte a la solución en una plataforma estable frente a alguna eventualidad de
falla en los storage NetApp. El servidor vCenter tiene redundancia, es importante
mencionar esto pues es el principal gestor de la plataforma virtual.
El cluster virtual tiene un nivel de redundancia N + 1, que asegura alta
disponibilidad a los hosts. Las configuraciones están regidas por las buenas
69
prácticas aplicadas en otros casos de éxito de implementación de infraestructura
virtual Vmware.
En lo relacionado a rendimiento, el procesamiento, memoria, distribución de
carga de I/O de SAN y carga de red se encuentran en óptimas condiciones lo cual
puede tomarse como referencia de línea base para análisis y benchmarks.
Los niveles de uso de procesamiento están por debajo del máximo recomendado,
y las observaciones realizadas en los hosts no reflejan problemas en este rubro. En el
subsistema de memoria RAM, el promedio de uso no sobrepasa los umbrales
recomendados.
En cuanto al balance de I/O de datos (SAN), los hosts tienen HBA de doble
puerto que se reparten la carga de I/O entre sí hacia los respectivos controladores del
storage NetApp no representando esto un problema y evitando así un impacto
negativo en la VMs alojadas en sus respectivos datastore. Esta configuración
permite entregar servicios informáticos más rápidos y seguros a través de las
aplicaciones montadas en dichas VMs.
En términos de escalabilidad, la plataforma es completamente escalable al
encontrarse implementada sobre plataforma Cisco UCS, Storage NetApp,
conectividad Cisco e hypervisor VSphere. Los hosts ESXi podrían necesitar
renovación tecnológica dentro de tres años, como periodo aproximado considerando
que son blades Cisco de última generación. El poder contar ahora con una
plataforma escalable, permite a la MML desplegar y concretar iniciativas de brindar
nuevos servicios a usuarios internos y externos.
Luego de las mejoras tecnológicas que representa contar con una plataforma
computacional estable, performante y escalable; los beneficios obtenidos son
70
también mayores. Representa ahorrar hasta 40% en los costos operativos (gestión,
mantenimiento, operación) de la nueva plataforma computacional versus la anterior.
La Subgerencia de Informática de la MML se ve mejorada su imagen como un ente
importante dentro de la organización de la entidad por poder brindar servicios e
información disponible. Existen sin embargo beneficios que son difíciles
cuantificarlos y calcularlos pero que se perciben como mejora de los servicios
informáticos dentro de la entidad.
71
Capítulo 13. Bibliografía
Plan Estratégico Institucional 2011-2014. Municipalidad Metropolitana de Lima.
Disponible en: https://www.munlima.gob.pe/images/descargas/gobierno-
abierto/transparencia/mml/planeamiento-y-organizacion/planeamiento-
organizacion/PEI-1722.pdf. Recuperado el 25 de enero del 2015.
Informe de Competitividad Global 2013–2014. World Economic Forum. Disponible en:
http://www3.weforum.org/docs/WEF_GlobalCompetitivenessReport_2013-14.pdf.
Recuperado el 10 de enero del 2015.
Competitividad sistémica. Competitividad internacional de las empresas y políticas
requeridas. Instituto Alemán de Desarrollo. Disponible en: http://www.meyer-
stamer.de/1994/systemsp.htm. Recuperado el 10 de enero del 2015.
Sistema de clasificación de Tier. Disponible en: https://es.uptimeinstitute.com/tiers.
Recuperado el 2 de febrero del 2015.
PROJECT MANAGEMENT INSTITUTE, INC. Guía de los Fundamentos para la
dirección de Proyectos (Guía del PMBOK). 4a ed., 2008.
La virtualización de servidores con VMware vSphere. Disponible en:
https://www.josemariagonzalez.es/2014/08/29/virtualizacion-servidores-vmware-
vsphere.html. Recuperado el 2 de febrero del 2015.
72
GONZÁLEZ, J.M., Descubre y domina VMware vSphere 5. 1a ed. Lulu.com, 2012.
241p.
Calculadora Salarial. Disponible en:
http://www.elempleo.com.pe/clientes/calculadora/calculadoraClientesPe.aspx .
Recuperado el 15 de abril del 2015.
¿Cómo se calculan las tarifas eléctricas?. Disponible en:
http://www.osinergmin.gob.pe/newweb/uploads/facebook/tarifaselectricas.pdf
Recuperado el 20 de abril del 2015.
0
Capítulo 14. Anexos
Anexo 1
Tabla 22: Flujo de caja
Fuente: fuente propia
Las consideraciones son que la MML cancela de acuerdo al costo total (Tabla 18) de la siguiente manera: mes 1 (19,92%), mes 2 (0.8%),
mes 3 (20%) y mes 4 (60%).