Virtualización de Escritorios: De vuelta al mainframe pero mejor!

1,267 views
1,157 views

Published on

Curiosamente el avance tecnológico en IT ha sido un proceso circular, o mejor descrito aún, en espiral. El ejemplo más tangible corresponde a como después de 40 años hemos pasado de las terminales brutas conectadas a un mainframe a los Escritorios Virtuales conectados a un datacenter.

En esta charla se discutirá que es la virtualización de escritorios y cómo pueden los gerentes de IT "deshacerse" del dolor de cabeza más grande en una empresa.. dar soporte a los computadores de los usuarios.


- Historia de la virtualización
- Evolución de la estación de trabajo
- Arquitectura de VDI
- Errores comunes de VDI
- Licenciamiento VDI
- Casos de uso y Mejores prácticas
- Demo Real (limitado a disponibilidad de tiempo)

Published in: Technology
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
1,267
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • And I also want to emphasize that not only do we support Windows guest operating systems, but Microsoft supports RHEV as well. In February 2009 we signed a commitment with Microsoft for support of Windows operating systems and many of their application servers under the SVVP (Server Virtualization Validation Program) We also have WHQL signed drivers for XP and Windows 7 for both server and desktop operating systems, and support Windows desktop operating systems on RHEV for Desktops.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • That's the power of the open source community, where we leverage all the development of virtualization technologies in the broader community. That's also the power of Red Hat, where we bring together not just the community but the large hardware and software vendors to create an enterprise-ready ecosystem for our partners. And the RHEV KVM hypervisor leverages all the work in the broader Linux kernel community, giving RHEV incredible velocity in features and scalability.
  • Red Hat Enterprise Virtualization from 2.1 has had the enterprise virtualization features such as HA, live migration (vMotion), power management and load balancing. There's a couple of new features: > OVF import and export of virtual machines. OVF is a flat file that allows you to do disaster recovery and move your virtual machines images from one datacenter to another > Hand-in-hand with OVF is our V2V conversion tools, that allow you to take VMware or RHEL Xen/KVM virtual machines and import them into RHEV > Finally, RHEV 2.2 is based on RHEL 5.5, so we get all the hardware enablement for the newest Intel and AMD servers, and we've also expanded our largest VMs to 16 virtual CPUs and 256GB RAM RHEV 2.2 is also the first release of the RHEV for Desktops product, which adds a connection broker, desktop deployment tools, and our open source SPICE remote rendering protocol, which gives you high definition video, bi-directional audio and video for video conferencing, USB support, multiple monitors and more.
  • Here's an example of a technology built into Red Hat Enterprise Linux which we are able to take advantage of in RHEV for hosting virtual machines. KSM or Kernel Same-Page Merging is a technology that allows multiple applications in Linux to use more memory than is physically installed by merging or deduplicating redundant memory pages. The RHEV hypervisor with KVM allows us to use the same technology to overcommit memory in virtual machines. Here we are running multiple instances of a Windows 2003 server VM with 3GB RAM running an intensive Java benchmark. On the horizontal we are increasing the number of Vms on a single physical server with 24 GB of physical RAM, and on the horizontal we are measuring IO. You can see that from 1 VM to about 16 VM we get near linear scaling of performance. That's 200% overcommit. After that, we can get up to 400% overcommit and the workloads still run, although with diminishing returns. This is a feature we inherit from Linux, that we don't need to code from scratch. And as the performance of this feature evolves in Linux, so it does in RHEV. That's the power of KVM.
  • RHEV Manager is also the administration tool for your virtual desktop infrastructure. It allows you to centrally manage pools of virtual desktops, assign rights to those desktops based on active directory membership, and gives you access to the SPICE protocol for remote rendering of those desktop machines.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • SPICE is remote desktop rendering technology Red Hat open sourced in December 2009. SPICE provides a user experience identical to a real desktop to users. It can do this based on its unique architecture. SPICE has three components: SPICE driver in the VM, the SPICE engine in the hypervisor host, and the SPICE client on the thin client or PC used to access the VM. Based on the video workload and network conditions, SPICE will adaptively choose to render either in the datacenter on the hypervisor host, or on the client by sending graphics primitives to directly to the client. Think about any laptop or desktop, even a 3-5 year old repurposed PC has more graphics processing power than can be emulated in the datacenter. In this case, SPICE will render on the client, which provides a better user experience and offloads more processing out of your datacenter.
  • Virtualización de Escritorios: De vuelta al mainframe pero mejor!

    1. 1. VIRTUALIZACIÓN ESCRITORIOS Virtualización de EscritoriosDe vuelta al Mainframe pero mejor!!!
    2. 2. VIRTUALIZACIÓN ESCRITORIOSConferencista:Ing. Andrés Mauricio Mujica Zalameaandres.mujica@seaq.com.coRHCE/RHCSA/RHCVA/DCAPGERENTE SEAQ SERVICIOS CIA LTDA
    3. 3. VIRTUALIZACIÓN ESCRITORIOSTome el control de laInformación en suEmpresahttp://www.seaq.com.co
    4. 4. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Historia de la virtualización■ Evolución de la estación de trabajo■ Arquitectura de VDI■ Errores comunes de VDI
    5. 5. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Licenciamiento VDI■ Casos de uso y Mejores prácticas■ Beneficios VDI■ Demo Real (limitado a disponibilidad de tiempo)
    6. 6. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Historia de la virtualización■ Evolución de la estación de trabajo■ Arquitectura de VDI■ Errores comunes de VDI
    7. 7. HISTORIA DE LA VIRTUALIZACIÓNThe Real Deal■ Otoño de 1964■ GE le gana a IBM el contrato MULTICS■ TSS: Time Sharing System■ CP-40 Project Robert Creasy
    8. 8. HISTORIA DE LA VIRTUALIZACIÓNThe Real Deal■ CP/40 : Definio la arquitectura VM■ Proyecto CP-67 parte de CP/CMS para el IBM/System360-67■ CP-370-CMS base para el VM/370■ CP/CMS era OPEN SOURCE !!!
    9. 9. HISTORIA DE LA VIRTUALIZACIÓNThe Real Deal■ IBM System-370 > VM/370
    10. 10. HISTORIA DE LA VIRTUALIZACIÓNS/360-67 – 1966■ Virtual Memory■ Microcode■ Hardware asistido■ Direccionamiento 24/32 bits■ Full Virtualization (oops)
    11. 11. HISTORIA DE LA VIRTUALIZACIÓNVM/370 – 1972■ Primer VM Platform■ Soporta múltiples OS  CMS  DOS/VS  OS/MFT/MVT/VS1  SVS Teddy Bear – 1983  MVS Mascota Oficial IBM VMs  VM/370  Algunas versiones de IBM/AIX
    12. 12. HISTORIA DE LA VIRTUALIZACIÓNCP/CMS■ Control Program : Implementación de VM simulando un S/360 (hypervisor)■ Cambridge Monitor System : Sistema operativo mono-usuario
    13. 13. HISTORIA DE LA VIRTUALIZACIÓNCP/CMS■ Aislamiento de usuarios entre sí. (reliabilidad y seguridad)■ Simulación de un computador completo permitiendo correr cualquier SW S/360 en un TSS. (sin rediseñar aplicaciones para TSS)■ Un CMS ligero como interfaz principal permite un buen desempeño para el usuario
    14. 14. HISTORIA DE LA VIRTUALIZACIÓN ■ Nació por accidente ■ Con el S360/CP-67 se creo el VM/370 ■ VM/370: Muchos colores surgen de un solo haz de luz
    15. 15. HISTORIA DE LA VIRTUALIZACIÓNDARK AGES■ La burocracia interna de IBM ignoró la VM durante mas de un lustro ( 73 al 79)■ La comunidad de usuarios e IBMers se autosoporto y apoyo mutuamente ➔ VMSHARE ➔ VNET■ Antecedentes del "Open Source”
    16. 16. HISTORIA DE LA VIRTUALIZACIÓNDARK AGES■ 1972: Lanzamiento del VM/370■ 1974: Computerworld blast. IBM has no further plans for VM  IBM tenía una proyección de máximo 500 clientes para VM■ 1976: 300 clientes de VM■ 1978: 1000 clientes con VM
    17. 17. HISTORIA DE LA VIRTUALIZACIÓNDARK AGES■ 1980: IBM.. compromiso con VM■ 1980: IBM VM/SP1 (buggy as hell)■ 1981: IBM VM/SP1 (por fin estable!)■ 1982: IBM declara la tecnología VM estratégica■ 1983: IBM inicia política OCO (acabo con el "open source")
    18. 18. HISTORIA DE LA VIRTUALIZACIÓNDARK AGES■ 1983: 10.000 instalaciones de VM■ 1985: "We hope that IBM will decide not to kill the goose that lays the golden eggs”■ 1987: Usuarios, desarrolladores e IBMers insatisfechos con la migración a OCO ➔ Lentitud en bugfixes ➔ Demora en nuevas funcionalidades■ 1987: Merge/386 primera aproximación en x86
    19. 19. HISTORIA DE LA VIRTUALIZACIÓNGOLDEN (?) AGES■ 1987: SoftPC Primer emulador de software■ 1989: IBM 20.000 instalaciones de VM (a pesar de!?)■ 1990: Lanzamiento de IBM System/390■ 1991: Aparece la primera versión del Linux Kernel■ 1997: Virtual PC de Connectix para Mac
    20. 20. HISTORIA DE LA VIRTUALIZACIÓNGOLDEN (?) AGES■ 1998: Vmware en modo stealth■ 1998: Vmware patenta sus técnicas de virtualization U.S. Patent 6,397,242■ 1999: Vmware sale a la luz pública en la DEMO Conference■ 1999: IBM implementa hypervisores en plataforma POWER
    21. 21. HISTORIA DE LA VIRTUALIZACIÓNGOLDEN (?) AGES■ 1999: Vmware lanza su producto Vmware Workstation■ 2000: IBM lanza Z/VM■ 2001: Vmware lanza su primer producto para servidores■ 2003: Primer hypervisor Open Source Xen
    22. 22. HISTORIA DE LA VIRTUALIZACIÓNGOLDEN (?) AGES■ 2003: Primer emulador Open Source QEMU■ 2005: OpenVZ es liberado por Virtuozzo■ 2006: Microsoft inicia el desarrollo de Hyper-V basado en tecnología XEN
    23. 23. HISTORIA DE LA VIRTUALIZACIÓNGOLDEN (?) AGES■ 2007: Citrix compra XEN■ 2007: KVM se incorpora al kernel de Linux■ 2007: Innotek lanza VirtualBox■ 2008: Red Hat compra Qumranet (KVM)■ 2009: Oracle compra SUN (heredando 3 tecnologías de virtualización)
    24. 24. HISTORIA DE LA VIRTUALIZACIÓNNOW THE FUTURE■ 2009: Gartner: 18% de las workloads corporativas sobre x86 corren virtualizadas. ➔ Para el 2012 se estima(ba) tener el 50% (58M)■ 2009: Gartner: El mercado de HVD se acelerará hasta llegar en el 2013 a 49M de unidades desde las 500K del 2009. ➔ Participación del 40% en el PC corporativo
    25. 25. HISTORIA DE LA VIRTUALIZACIÓN 2009 2012 Gartner, Virtual Machines and Market Share Through 2012, Gartner ID#G00170437.
    26. 26. HISTORIA DE LA VIRTUALIZACIÓN
    27. 27. HISTORIA DE LA VIRTUALIZACIÓN
    28. 28. HISTORIA DE LA VIRTUALIZACIÓN
    29. 29. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Historia de la virtualización■ Evolución de la estación de trabajo■ Arquitectura de VDI■ Errores comunes de VDI
    30. 30. EVOLUCIÓN WORKSTATIONPunch Card Inicio como un tabulador para los Censos en 1880 pero se utilizo como mecanismo de interacción humana con los “computadores” hasta 1970 aproximadamente
    31. 31. EVOLUCIÓN WORKSTATIONTeleTypeWriter (aka TTY) Inicialmente usadas para telegrafía y luego como terminales de impresión. En l970 la Industría cayo en cuenta que podían reemplazar al Punch Card
    32. 32. EVOLUCIÓN WORKSTATIONMAINFRAME
    33. 33. EVOLUCIÓN WORKSTATIONOPERACIÓN TERMINAL DE TEXTO
    34. 34. EVOLUCIÓN WORKSTATIONTERMINALES BRUTAS- Acceso directo al aplicativo- Único aplicativo !!- Control centralizado- Mono tarea- Requiere red
    35. 35. EVOLUCIÓN WORKSTATIONPERSONAL COMPUTER 1980 2010
    36. 36. EVOLUCIÓN WORKSTATIONPERSONAL COMPUTER
    37. 37. EVOLUCIÓN WORKSTATIONPERSONAL COMPUTER- Acceso local al (los) aplicativo(s)- Múltiples aplicativos !!- Control Local- Multi tarea
    38. 38. EVOLUCIÓN WORKSTATIONCOMPUTADORES EN RED
    39. 39. EVOLUCIÓN WORKSTATIONCOMPUTADORES EN RED
    40. 40. EVOLUCIÓN WORKSTATIONSOPORTE NIGHTMARE !
    41. 41. EVOLUCIÓN WORKSTATIONCONTROLANDO LA INFRAESTRUCTURA- Acceso por red al (los) aplicativo(s)- Información distribuida- Múltiples aplicativos- Administrador locales- Multi tarea, Multi usuario
    42. 42. EVOLUCIÓN WORKSTATIONLA VIDA ERA MÁS FÁCIL CON LOS MAINFRAMES- Al tener todo centralizado y monoaplicación no se requería un soporte por n combinaciones de n factores juntos.
    43. 43. EVOLUCIÓN WORKSTATIONPARADIGMA DEL CONTROL- Autenticación centralizada- Políticas centralizadas- Despliegue fácil de aplicaciones- Sistemas homogeneizados
    44. 44. EVOLUCIÓN WORKSTATIONSOLUCIONES- La más "aceptada”, accesible y popular es el Active Directory.
    45. 45. EVOLUCIÓN WORKSTATIONSOLUCIONES
    46. 46. EVOLUCIÓN WORKSTATIONSOLUCIONES
    47. 47. EVOLUCIÓN WORKSTATIONALTERNATIVAS- Network Booting (Eliminar los discos duros)- Microsoft Terminal Services (Clientes Delgados)- Linux Terminal Server Project (Clientes Delgados)- Citrix Metaframe (Despliegue de aplicaciones)
    48. 48. EVOLUCIÓN WORKSTATIONNETWORK BOOTING
    49. 49. EVOLUCIÓN WORKSTATIONNETWORK BOOTING
    50. 50. EVOLUCIÓN WORKSTATIONTERMINAL SERVICES
    51. 51. EVOLUCIÓN WORKSTATIONACCESO TERMINAL
    52. 52. EVOLUCIÓN WORKSTATIONLINUX TERMINAL SERVICES PROJECT
    53. 53. EVOLUCIÓN WORKSTATIONLINUX TERMINAL SERVICES PROJECT
    54. 54. EVOLUCIÓN WORKSTATIONLINUX TERMINAL SERVICES PROJECT
    55. 55. EVOLUCIÓN WORKSTATIONCITRIX METAFRAME
    56. 56. EVOLUCIÓN WORKSTATIONCITRIX METAFRAME
    57. 57. EVOLUCIÓN WORKSTATIONCITRIX METAFRAME
    58. 58. EVOLUCIÓN WORKSTATIONCONCLUSIONES HASTA EL MOMENTO- Iniciamos en un ambiente controlado monoaplicativo y llegamos a un ambiente multiusuario/aplicativo/endpoint.- Dificultad de manejo, mantenimiento y aseguramiento.- Despliegue de aplicaciones, parcheo del sistema operativo, backups, soporte.
    59. 59. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Historia de la virtualización■ Evolución de la estación de trabajo■ Arquitectura de VDI■ Errores comunes de VDI
    60. 60. ARQUITECTURA VDIRETOS DE LA COMPUTACION DE ESCRITORIO- Despliegue de Software y manejo de parches.- Recuperación de datos- Continuidad de negocio- Soporte al usuario- Protección a la IP
    61. 61. ARQUITECTURA VDIRETOS DE LA COMPUTACION DE ESCRITORIOGARTNER 2005USD882 es el costoadicional de desplegarSW por cada PC conlos modelos normales
    62. 62. ARQUITECTURA VDIRETOS DE LA COMPUTACION DE ESCRITORIOGARTNER 2005Cada computador deEscritorio tiene 20Horas al año fueraDe servicio
    63. 63. ARQUITECTURA VDIRETOS DE LA COMPUTACION DE ESCRITORIO- Personalizable- Rápido (?)- Administración?- Aseguramiento?
    64. 64. ARQUITECTURA VDIPROBLEMAS SERVICIOS DE TERMINAL- Consolida- Personalización limitada- Depende del aplicativo- Ambiente compartido
    65. 65. ARQUITECTURA VDI■ Virtualización  La posibilidad de correr múltiples computadores dentro de un solo computador físico - Consumo de energía - Espacio - Subutilización de recursos - Administración
    66. 66. ARQUITECTURA VDI■ Para que usarla?  Ambientes de pruebas y/o producción  Reducción de costos  Consolidación  VDI
    67. 67. ARQUITECTURA VDI■ Emulation■ OS-Level virtualization■ Para-virtualization■ Full/Native virtualization
    68. 68. ARQUITECTURA VDIVDI/HVD
    69. 69. ARQUITECTURA VDIVDI/HVD■ VDI: Virtual Desktop Infrastructure Modelo basado en el servidor que entrega una VM al usuario final■ HVD: Hosted Virtual Desktop VDI provista por un tercero
    70. 70. ARQUITECTURA VDI
    71. 71. ARQUITECTURA VDIVDI/HVD
    72. 72. ARQUITECTURA VDIBROKER
    73. 73. ARQUITECTURA VDI
    74. 74. ARQUITECTURA VDI
    75. 75. ARQUITECTURA VDIPALABRAS CLAVE- VDI- HVD- BROKER- APPLICATION VIRTUALIZATION- USER VIRTUALIZATION- DESKTOP VIRTUALIZATION- DESKTOP POOLS
    76. 76. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Historia de la virtualización■ Evolución de la estación de trabajo■ Arquitectura de VDI■ Errores comunes de VDI
    77. 77. ERRORES COMUNES VDIERRORES TÍPICOS■ Costo. El costo inicial NO es menor a las alternativas tradicionales por los requerimientos de infraestructura y licenciamiento. El ROI puede estar a 4 – 5 años - Costo estimado a 2013 US1340 - Costo estimado a 2012 US2600
    78. 78. ERRORES COMUNES VDIERRORES TÍPICOS■ STORAGE. Soportar el login storm a las 7-8AM es fuerte para los IOPS de una SAN.
    79. 79. ERRORES COMUNES VDIERRORES TÍPICOS■ RED. Dependentes de la LATENCIA y se debe pensar en la red para soportar la infraestructura.■ MULTIMEDIA. Los protocolos de VDI más usados no tienen buen soporte para multimedia. (A excepción de SPICE con Red Hat)
    80. 80. ERRORES COMUNES VDIERRORES TÍPICOS■ USER EXPERIENCE. Se debe analizar los casos de uso, normalmente el 40% de usuarios de una organización son candidatos ideales para esto, pero se debe analizar los escenarios y explicarles porque es bueno usarlo (p.e. Se va la luz y el desktop se recupera tal cual quedo)
    81. 81. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Licenciamiento VDI■ Casos de uso y Mejores prácticas■ Beneficios VDI■ Demo Real (limitado a disponibilidad de tiempo)
    82. 82. LICENCIAMIENTO VDITCO de VDI (The Microsoft Way)
    83. 83. LICENCIAMIENTO VDITCO de VDI (The Microsoft Way)Estudio Microsoft Mayo 2010:VDI TCO Analysis for Office Worker Environments
    84. 84. LICENCIAMIENTO VDIRAZONAMIENTO■ Toda la tecnología utilizada para control y manejo del escritorio local, toda la industria generada alrededor de esto sería relegada por un modelo VDI $$$$
    85. 85. VDA LICENSINGSA vigente por cada dispositivo que acceda al VDILicencia VDA por cada dispositivo que NO soporte SAEl resto de licenciamiento aplica
    86. 86. ARQUITECTURA VDIVDA LICENSING
    87. 87. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Licenciamiento VDI■ Casos de uso y Mejores prácticas■ Beneficios VDI■ Demo Real (limitado a disponibilidad de tiempo)
    88. 88. CASOS DE USO / BCP
    89. 89. CASOS DE USO / BCPTASK WORKER - Juego típico de aplicaciones (Office, Browser, PDF, ZIP) - Una aplicación simultánea - Pocas aplicaciones durante el día - Interacción esporádica con el computador - Bajo I/O a discoCall Centers, Web Users, Manufactura, SaludPRODUCTIVITY WORKER - Múltiples aplicaciones simultáneas y durante el día - Interacción frecuente con el computador - I/O más continuo en el disco - Actividades periódicas en CPU en I/OSalud, Administradores, Business support, Data entry ops
    90. 90. CASOS DE USO / BCPKNOWLEDGE WORKER - Múltiples aplicaciones simultáneas - Amplio rango de aplicaciones en uso - Pocas aplicaciones durante el día - Interacción permanente con el computador - I/O permanente en disco - Aplicaciones con uso intensivo de CPUFinanciero (no traders), Mercadeo, IngenierosDEVELOPER/POWER WORKER - No hay datos suficientes para catalogarlos - Estimación de 32-40 usuarios de este tipo en CPUs de 8-12 cores
    91. 91. CASOS DE USO / BCP
    92. 92. CASOS DE USO / BCPUse case - Shared access model implica I/O loginstorms permanentesImage - Imagen base para múltiples vDI con serviciosprogramadosAplicaciones - Análisis de cada aplicación para determinarsu efecto neto
    93. 93. CASOS DE USO / BCPStorage - Entre mayor centralización del storage mayorcontención por I/OComportamiento del Usuario -Análisis de los patrones de utilizaciónOptimización de memoria - Incremento de la densidad de usuario
    94. 94. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Licenciamiento VDI■ Casos de uso y Mejores prácticas■ Beneficios VDI■ RHEV-D
    95. 95. BENEFICIOS VDI
    96. 96. BENEFICIOS VDICONSOLIDACIONAHORRO DE ENERGIADISASTER RECOVERY
    97. 97. BENEFICIOS VDI
    98. 98. VIRTUALIZACIÓN ESCRITORIOSPLAN DE TRABAJO■ Licenciamiento VDI■ Casos de uso y Mejores prácticas■ Beneficios VDI■ RHEV-D
    99. 99. PRUEBAS DESEMPEÑOEstudio realizado por SPECvirt
    100. 100. PRUEBAS DESEMPEÑOEstudio realizado por SPECvirt
    101. 101. SERVER AND DESKTOP VIRTUALIZATIONSERVER VIRTUALIZATION DESKTOP VIRTUALIZATIONHigh Availability SPICE remote rendering NEWLive Migration - HD quality videoSystem Scheduler - bi-directional audio/videoPower Saver - USB supportImage management/ provisioning - Multiple monitorsOVF Import/Export Connection Broker NEW NEWVMware and RHEL/Xen Desktop poolsVM image converter NEW NEWEnhanced scalability(16 vCPU, 256 GB RAMGuest operating systems) NEW
    102. 102. KVM HYPERVISOR – ADVANCED FEATURESKernel Same-Page Merging (KSM)Enterprise Java workload benchmark - Intel Xeon Processor X5550 with 24GB RAM -Running multiple 3GB Windows 2003 VMs - Scaling up to 200% over-commit
    103. 103. VDI TOTALMENTE INTEGRADOManejo centralizado, seguridad y políticasEscritorios Virtuales con experiencia total de equipo físicoMonitores MultipleCalida de video HDaudio-video Bi-directional para VoIP o video-conferenciassoporte USBLiderazgo a nivel industrial en densidad de servidores y escritorios virtuales
    104. 104. SPICE: PARA ESCRITORIOS VIRTUALESSPICE incluye 3 componentes> SPICE driver en el cliente> SPICE virtual graphics adapter en elhost> SPICE client en el cliente delgado oequipo de accesoProtocolo Adaptativo – identifica puntoóptmo de procesamiento de las gráficas> En el host> O en el clienteNo requiere tarjetas o hardware especialAlta densidad, experiencia óptima para elusuario
    105. 105. RHEV-D ARCHITECTURE
    106. 106. POWER USER PORTAL
    107. 107. USER PORTAL
    108. 108. COMUNIDAD DE PARTNERS
    109. 109. SPICE: FOR VIRTUAL DESKTOPS
    110. 110. SPICE: FOR VIRTUAL DESKTOPS
    111. 111. Q&A
    112. 112. ALIANZAS
    113. 113. INFORMACION DE CONTACTO MUCHAS GRACIAS POR SU ATENCIÓN.Información de ContactoDirección: Carrera 15 # 79 – 37 Oficina 201ABogotá, ColombiaTeléfono: +57 – 1 655 98 00USA Tel: +1 – 937 697 1769Fax: +57 – 1 655 98 02Internet: www.seaq.com.coContacto: ventas@seaq.com.co
    114. 114. VIRTUALIZACIÓN DE ESCRITORIOSTome el control de laInformación en suEmpresahttp://www.seaq.com.co
    115. 115. OTRAS CONFERENCIAS1.- Virtualización de Escritorios, de vuelta almainframe. Pero mejor!!!2.- Implementando Cloud Privados. De lapropaganda a la acción.3.- Por qué el Open Source es la alternativaideal para el desarrollo tecnológico deColombia y Latinoamerica4.- Hacking y asegurando Asterisk

    ×