La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Mario González Díez Jefe de la Unidad de Explotación

Presentaciones similares


Presentación del tema: "Mario González Díez Jefe de la Unidad de Explotación"— Transcripción de la presentación:

1 Organización y gestión de proyectos de virtualización: Entornos físicos VS entornos virtuales
Mario González Díez Jefe de la Unidad de Explotación Instituto Tecnológico Agrario de Castilla y León

2 ÍNDICE Introducción al ITACyL Evolución de los sistemas en el ITACyL
Cómo organizar un proyecto de virtualización Entornos físicos VS entornos virtuales El futuro de la virtualización en el ITACyL 1

3 Introducción al ITACyL
Objetivo: Potenciar la actividad del sector agroalimentario y sus industrias de transformación Funciones Investigación aplicada y desarrollo tecnológico en el sector agrario. Investigación orientada hacia la seguridad de las materias primas alimentarias. Infraestructuras y actuaciones sobre el territorio, de interés general agrario. Certificación de calidad agroalimentaria y promoción de productos. Área de Tecnologías de la Información: Desarrollo de aplicaciones (ámbito interno y externo) tanto de gestión como GIS. Gestión de infraestructura de informática y telecomunicaciones. Gestión de recursos para servicios centrales y de puesto de usuario. El ITACyL es un ente de la Junta de Castilla y León que nace en noviembre de 2002 con el objetivo marcado de potenciar la actividad del sector agroalimentario en Castilla y León, y sus industrias de transformación, mejorando su competitividad. Para cumplir este objetivo, desarrolla una serie de funciones, muy ligadas a los diferentes ámbitos de trabajo del Instituto: Investigación aplicada y desarrollo tecnológico del sector agrario: mejora de procesos productivos, automatización y tecnificación. Investigación orientada hacia la seguridad de las materias primas alimentarias: genética de variedades, estudio de plagas, resistencia de alimentos. Infraestructuras y actuaciones sobre el territorio, de interés general agrario: estaciones de riego, estudios de impacto ambiental. Certificación de calidad agroalimentaria y promoción de productos: análisis (microbiológicos, físicos, sensoriales), figuras de calidad alimentaria. Dentro del Instituto, el Área de Tecnologías de la Información es la encargada de todas las funciones TIC, existiendo dos grupos diferenciados: Desarrollo: encargado de realizar aplicaciones tanto para usuarios internos como para el exterior (ciudadanía en general o sector agroalimentario de forma específica), tanto aplicaciones de gestión como GIS, empleando para ello las últimas tecnologías en entorno J2EE (JSF, Struts, Hibernate). Explotación: gestión de infraestructura de informática y telecomunicaciones: CPDs, servidores, red, electricidad. Gestión de recursos para servicios centrales y de usuario. 2

4 Evolución de sistemas en el ITACyL
Inicio: Puesta en marcha de servicios básicos: Servidores de directorio, ficheros y correo. Servidores de base de datos, de aplicaciones y web. Servidores de streaming, FTPs, impresión. En esta fase, distintos servicios implican distintos servidores. ¿Por qué? Distintas arquitecturas / versiones SO Necesidad de aislar posibles fallos en unos servicios de otros (fallos SW, actualizaciones S.O., ataques) Necesidad de aislar diferentes entornos de seguridad (LAN, DMZ, Internet) La evolución de sistemas en el ITACyL ha seguido un proceso gradual hasta la situación actual. Dicho proceso comienza en 2004, donde el Instituto empieza su andadura real de forma independiente a la Junta, empezando a implantar sistemas propios para ofrecer los servicios básicos: Directorio activo, ficheros y correo electrónico Servidores web, de bases de datos, de aplicaciones Java. Servidores de streaming de video, FTPs, de impresión. En esta fase, distintos servicios implican distintos servidores, como ocurría en general en otras organizaciones. Entre los motivos que encontramos para explicar esto se encuentran: Más de una plataforma hardware. En este punto encontramos tanto diferentes sistemas operativos (Windows, Unix, Linux) como arquitecturas (x86, ia64, sparc). Necesidad de aislamiento de fallos, es decir, cuando se dispone de muchos servicios, son muchos también los problemas potenciales que pueden presentarse. Así, la necesidad de realizar una actualización en el SO, que puede dar problemas, si se realiza sobre una máquina que dispone de varios servicios, todos esos servicios pasarán a estar comprometidos. El mismo efecto se presenta cuando hablamos de seguridad lógica, siendo más problemático el ataque a una máquina que albergue múltiples servicios que a una que tenga menos. Enlazado con lo anterior, en general las organizaciones tienen diferentes segmentos de red, cada uno con un nivel de seguridad. Las máquinas que pertenecen a un segmento son totalmente independientes de las de otro, lo que obliga a disponer de más hardware para albergar servicios ubicados en diferentes zonas de seguridad. 3

5 Evolución de sistemas en el ITACyL
Ejemplo: algunos de los servicios / servidores del ITACyL en la fase inicial Como ejemplo de lo anteriormente descrito, vemos en el esquema un ejemplo de algunos de los servicios de los que dispone el ITACyL, durante la primera fase. Se aprecian los distintos segmentos de red: red interna (segura), DMZ (menos segura) e internet. En cada uno de los segmentos, encontramos diferentes servidores y servicios en cada uno de ellos, donde tenemos diferentes arquitecturas y sistemas operativos, en este caso Windows y Linux. Entre los servicios Windows encontramos: Gestor de actualizaciones y antivirus: encargado de la gestión centralizada de políticas de actualización de equipos windows y control central de los sistemas antivirus Servidor de impresión: encargado de albergar las impresoras y gestionar las colas de impresión Servidor de streaming; ubicado en la DMZ, sirve los diferentes videos en modo streaming que tiene publicados el ITACyL Entre los linux: Servidores FTP, tanto en la zona interna como en la DMZ BD preexplotación, para contener la BD de las aplics previas al paso a producción Servidor NFS, para la compartición de ficheros entre sistemas Linux En el esquema vemos la problemática descrita anteriormente. 4

6 Evolución de sistemas en el ITACyL
Desde 2006  orientación a virtualización. Al introducir la virtualización, el esquema tradicional cambia. Ahora: Servicios  recursos HW necesarios. Un servidor físico puede contener: Diferentes SO y arquitecturas: W98, NT, XP, 2003, Linux (…). Diferentes redes independientes unas de otras (virtual switches). El fallo o ataque de una máquina virtual no compromete ni la máquina física ni las otras virtuales. Resumen: entornos totalmente aislados entre sí. A partir de 2006, se produce un cambio, motivado principalmente por la escasez de espacio en CPD y el elevado consumo eléctrico, ligado a un bajo aprovechamiento de los servidores. Cuando se hace el cambio de mentalidad, con las ideas puestas en virtualización, hay que pensar de otra forma. Ya no debemos pensar en qué requisitos debe tener un servidor, sino que debemos pensar que cantidad de recursos necesita cierto servicio para cumplir su cometido de forma correcta, sin exagerar ni aumentando innecesariamente los requisitos. Con la virtualización, los servidores pasan a ser simples agrupaciones de recursos HW a disposición de los servicios, con lo que: Cada servidor puede albegar diferentes SO y arquitecturas, desde sistemas actuales (Red Hat Enterprise Linux, Windows 2003) a sistemas a anticuados (Windows 98 o NT, por ejemplo) Pertenecer a diferentes redes, independientes totalmente unas de otras, lo que se suele conocer como virtual switches, equivalente a la situación física de disponer de dos servidores conectados cada uno a un equipo de red diferente, cada uno en una zona de seguridad. Obviamente, para que haya un aislamiento real total, cada tarjeta de red del equipo debería estar físicamente conectada a un segmento de red, y las máquinas virtuales solo deben tener acceso a la tarjeta de red que corresponda a su segmento. En línea con lo anterior, el fallo o ataque de una de las máquinas virtuales existentes en un servidor no compromete ni al propio servidor, ni al resto de las máquinas virtuales que estén en ejecución. Esto quiere decir que ni es posible acceder por medio de una máquina virtual a la máquina física ni a las otras, y los fallos lógicos tampoco afectan. Resumiendo las ideas, realmente cumplen el mismo cometido que teniendo máquinas físicas diferenciadas, que consiste en el completo aislamiento físico y lógico entre sí. 5

7 ¿Cómo organizar un proyecto de virtualización?
Estudio de Viabilidad ¿Necesito virtualizar? Listado de servidores / servicios: SO, arquitectura, usuarios. Monitorización de rendimiento de servidores: CPU, memoria, disco ¿Puedo virtualizar? SO y arquitecturas soportados Recursos HW y económicos ¿Qué características busco? Tolerancia a fallos Balanceo Conversión físico  virtual Selección de plataforma de virtualización Como primer paso en un proyecto de virtualización, podemos hablar de los siguientes pasos: En primer lugar, realizar el estudio de viabilidad del proyecto, que debe servir para contestar las siguientes preguntas: 1.- necesito virtualizar?? Para ello, debe generarse un listado de servidores y servicios, que incluya al menos los siguientes datos: SO, arquitectura, y número de usuarios. A mayores, durante un periodo de tiempo que se considere significativo para cada servicio, debe monitorizarse el rendimiento de los servidores, en lo que a CPU, memoria, disco y red se refiere. Si a raiz de este estudio vemos que hay servidores claramente infrautilizados, son candidatos claros a incluir como virtuales. 2.- puedo virtualizar?? Basándonos en el punto anterior, cruzando los datos de servidores candidatos a virtualizar con los datos de SO y arquitectura, tenemos que ver si están soportados en las diferentes plataformas de virtualización. Por ejemplo, puede que una máquina Tru64, aunque sea candidata a virtualizar, no haya plataforma que permita su virtualización, por lo que no sería posible su virtualización. A mayores, tenemos que ver en caso de que la plataforma sí esté soportada, si disponemos de HW para realizar el montaje, o si podemos reutilizar alguno de los existentes. Si no tenemos los recursos, habrá que plantearse si los queremos adquirir o no. 3.- caraceterísticas buscadas: define mucho la solución elegida. Queremos tolerancia a fallos, balanceo de carga, herramientas de conversión virtual / físico?? Una buena forma de operar puede ser evaluar, de entre las plataformas que cumplan los primeros requisitos, qué características a mayores presenta cada una, el coste asociado, y, con todos los datos encima de la mesa, tomar la decisión de qué plataforma escoger. 6

8 ¿Cómo organizar un proyecto de virtualización?
Diseño Especificación de requisitos de cada máquina virtual Recursos mínimos y máximos. Horario de carga SO y arquitectura Zona de seguridad de red (LAN, DMZ) Nivel de criticidad Organización inicial de máquinas virtuales en físicas Implantación Una vez decidida la plataforma llega el momento de pasar al diseño de la solución. En primer lugar, debemos definir los requisitos que debe tener cada máquina virtual, esto es, recursos mínimos y máximos, SO y arquitectura, zona de seguridad de la red, y nivel de criticidad, así como un horario en el cual dichas máquinas tengan la mayor parte de la carga de trabajo. Con dichos datos, podemos confeccionar un primer mapeo de máquinas virtuales en físicas. Buscaremos en la medida de lo posible agrupar las máquinas de forma que los horarios de carga no coincidan, con la idea comentada anteriormente de aprovechar al máximo los recursos. Según la plataforma elegida y sus capacidades, esta organización inicial puede modificarse de forma estática o dinámica a posteriori. Llega por fin el proceso de implantación, que consiste en la creación como tal de las máquinas virtuales, bien partiendo desde cero, bien empleando herramientas de migración desde las máquinas físicas (según disponibilidad de la plataforma). Una vez creadas las máquinas, llega el momento de realizar las diferentes pruebas: tanto de funcionamiento normal, como de rendimiento y de fallo. Se requiere también monitorizar las máquinas virtuales implantadas, para comprobar si la organización inicial realizada responde a las necesidades o es necesario algún cambio. Creación de máquinas virtuales y/o migración de máquinas físicas Pruebas: funcionamiento, rendimiento, fallo Monitorización  realimentación en organización inicial 7

9 Entornos físicos VS entornos virtuales
Parámetro Virtual Físico Espacio en datacenter X Consumo energético Coste: pocos servidores Coste: muchos servidores Comparamos a continuación una serie de parámetros para comparar entre entornos físicos y virtuales: Espacio ocupado en datacenter: los entornos virtuales reducen la ocupación del datacenter en la misma medida que el factor de virtualizaciónmejor virtualizado Consumo energético: de la misma forma que el parámetro anterior, dado que tenemos más de una máquina virtual en una sola máquina física, se reduce el consumo energético Coste económico: aquí existe un umbral, por debajo de ese umbral no compensa de modo global introducir virtualización. El umbral, eso sí, puede variar mucho según varios factores: plataforma de virtualización, tiempo de recuperación ante desastres, posibilidad de reutilizar HW, balanceo de carga. Será cada organización la que en función de dichos factores fije su umbral, y por tanto vea si está o no por encima del mismo, y por tanto si compensa o no virtualizar. 8

10 Entornos físicos VS entornos virtuales
Parámetro Virtual Físico Administración:pocos sistemas X Administración:muchos sistemas Arquitecturas no x86 Alto rendimiento y máxima optimización Igual que en el caso anterior, la complejidad (y que por tanto podemos traducir en coste) de administración, depende de un umbral, a partir del cual, la complejidad asociada a la introducción de la plataforma de virtualización se ve compensada por la reducción de tiempo de administración de muchos sistemas, frente a la administración individualizada de los servidores por separado. Cuando hablamos de arquitecturas que no son x86 (en general, sistemas de 32 bits, bajo plataforma Windows o Linux), no es una opción virtualizar, al menos a día de hoy. Entornos como Solaris, HP-UX, Linux sobre Itanium IA-64, no son virtualizables a día de hoy, por lo tanto no es una opción virtualizar. Por último, si queremos obtener el máximo rendimiento y llevar la optimización de HW al máximo nivel, la virtualización no es buena idea. En este caso, de hecho, esta situación chocaría contra lo que ofrece la virtualización, que entre otras cosas, es aprovechar más el HW que no se usa, pero si buscamos el máximo rendimiento, esto es claramente opuesto a la infrautilización de HW. 9

11 El futuro de la virtualización en el ITACyL
Continuación en el proceso de virtualización de servidores implantados (standby  active ) Reevaluación de las principales plataformas de virtualización: Xen Vmware Thin clients y Virtual Desktops De cara al futuro, cómo se plantea la virtualización en el ITACyL?? En principio se mantendrá la tendencia actual, es decir, seguir virtualizando los servicios que sea posible, creando inicialmente copias standby en caso de problemas con el servidor inicial, llegando a ser operativas en producción sustituyendo a las físicas de forma progresiva. Esta tendencia se completará creando un standby datacenter, que albergue los servicios necesarios para continuar con el funcionamiento normal de operaciones del Instituto aún en caso de desastre. Por otra parte, aunque actualmente la herramienta empleada es VMWare, se reevaluarán los cambios y evoluciones tanto en dicha herramienta como en Xen, recientemente adquirida por Citrix, para conocer qué ofrece cada una, y ver la tendencia de los mercados, ya que en su momento solo Vmware cumplía con los requisitos necesarios, pero en el futuro relativamente cercano esto puede cambiar. Por último, está en proceso un piloto basado en una nueva tendencia que está apareciendo, consistente en combinar clientes ligeros y virtualización, para montar lo que se denomina Virtual Desktop. Dicho piloto consiste en combinar la infraestructura de virtualización existente, con máquinas virtuales para clientes, con clientes muy ligeros que permitan la conexión a la infraestructura de virtualización. El piloto se está preparando para un aula de formación, de forma que para dar un curso, simplemente se prepara una máquina virtual con los programas necesarios, y los clientes ligeros se conectarán a dicha máquina, con lo que el tiempo de preparación se reduce, así como el coste del aula en sí. 10

12 Organización y gestión de proyectos de virtualización: Entornos físicos VS entornos virtuales
Gracias por su atención


Descargar ppt "Mario González Díez Jefe de la Unidad de Explotación"

Presentaciones similares


Anuncios Google