miércoles, 26 de enero de 2011

¿Cuales son las ventajas técnicas de una infraestructura virtual en la práctica? (zero sales engineer jargon, please)

Ultimamente estoy retomando el campo de cloud computing, muy focalizado en cómo montar private clouds.

En la red pueden encontrar buen material descriptivo de qué es una nube privada, incluso hay diversas discusiones sobre si es buena o no, advierto: muy marcadas por los intereses comerciales de quienes opinan. Si tienes tu propia infraestructura a cargo, y ya conoces algo de clouds, de seguro ya habrás visto los beneficios.

Por cierto, exageradamente muchos con respecto a la infraestructura normal, principalmente un cuantioso ahorro económico a mediano plazo, muy por encima de los más salvajes ahorros que pueda mencionar un sales engineer de infraestructura tradicional.

Como algunos de uds. sabrán, hace un año presenté un proyecto completo para montar una private cloud en la infraestructura de un cliente. El proyecto no llegó a implementarse, bah, "todavía", las clouds privadas son tan inevitables como Gigabit ethernet. La frase es "Gigabit Ethernet es el nuevo Fast Ethernet", solamente pregunten cuantos están certificando cableado CAT6...


Bien, el proyecto servía (sirve), para tomar una infraestructura de servidores con almacenamiento fijo trabajando en el modo tradicional (desperdiciando cuantiosos y costosos recursos mientras que se aproximaban velozmente a diversos puntos de out-of-support y obsolescencia tecnológica), y convertirla en una infraestructura basada en SAN, iSCSI a 1 giga, escalable eventualmente a 10 gigas (invirtiendo en la infraestructura de networking de 10 gigas para la SAN), con una infraestructura de virtualización con administración de recursos (manejador de hypervisores), manejando muchos nodos (antigüamente conocidos como "servidores"), corriendo sobre ellos máquinas virtuales y dentro de las máquinas virtuales, los tradicionales sistemas operativos y aplicaciones.

Por el lado no tradicional, la infraestructura de storage y virtualización introducía un conjunto completamente nuevo de capacidades y características, solo mencionando algunas:
  • Snapshots de máquinas virtuales,
  • Imágenes pre-armadas de máquinas virtuales para rápidos deployments,
  • Backups ultrarápidos y con cero tiempo de ventana necesario (basados en snapshots combinados con software de backup tradicional o no, a preferencia del usuario),
  • Backups ultrarápidos a cualquier hora, incluído el primetime, permitiendo backupear la base de datos más importante de la empresa a las 11 de la mañana de un miércoles por ejemplo sin necesidad de "bajarla". (gracias a los snapshots de vuelta),
  • Migración automática - o no - de máquinas virtuales a cualquier nodo (recuerda "o servidor"), según la necesidad o no de capacidades de procesamiento/memoria (que obviamente están restringidos a la capacidad particular del nodo donde esté corriendo la máquina virtual...todavía :-), más sobre eso en otro artículo),
  • La posibilidad de migrar transparentemente de hardware en los nodos, con cero reinstalación de sistemas operativos (fast howto: simplemente se mueve a la máquina virtual a un nodo disponible, se apaga el nodo-server a reeemplazar, se monta el nuevo hardware, se instala el software de hypervisor, se lo integra al manejador de hypervisores y luego se vuelve a mover la máquina virtual al nuevo nodo, con cero modificaciones en el sistema operativo y en las aplicaciones ejecutando en él..de hecho no hace falta apagar la máquina virtual para realizar la migración de hardware),
  • La posibilidad de ir simplemente agregando capacidad a la/s SAN, es decir, ir agregando discos, que gracias a la capacidad de una capa de manejadores de volúmenes lógicos (LVM, Veritas Volume Manager, Solaris Volume Manager, etc), por debajo de los sistemas operativos (Windows Server, Linux, Unix), y la posibilidad de aumentar el tamaño de las particiones tradicionales con muy bajo riesgo (recordar aquí: antes tomar un snapshot -opciones: de la máquina virtual, del volumen lógico, de la partición, etc. - justo antes de hacer el resize de filesystem para lograr un tiempo cero de disaster recovery).
  • Mejoras radicales en el networking, utilizando networking virtual entre máquinas virtuales (switches virtuales, appliances virtuales - firewalls, UTMs, proxies, mails proxies, etc. ), es decir, el intercambio de tráfico de red se realiza en la memoria del nodo (server), cerca de la velocidad que tiene la memoria RAM, muy por encima de la velocidad disponible en hardware de networking.
  • La pregunta-consecuencia "¿esta mejora podría extenderse a los backups tradicionales si tuvierámos appliances virtuales?", exacto (ver aquí), se extiende y no para de extenderse (¿quien dijo Antivirus por ahí?), solo hay que ver los partners de appliances virtuales disponibles para cada producto, por ejemplo aquí.
  • La capa de virtualización (hypervisores y manejador de hypervisores), es realmente y casi por completo independiente del hardware. Se puede implementar sobre Vmware, Xen, KVM, Microsoft Hyper-V, perdiendo y ganando ventajas según el producto elegido.
  • La capa de SAN, cuando se progresa hacia hardware no commodity, es decir soluciones SAN propietarias, suele incluir también cada vez más numerosas capacidades de tunning de performance y características de zero-downtime a nivel de filesystems, por ejemplo: la posibilidad de armar RAIDs virtuales con volúmenes creados dentro de la SAN (lo que agrega una capa adicional de resilience, no confundir esto con los volúmenes lógicos de los sistemas operativos).
  • De hecho, con SANs propietarias, los RAIDs mencionados y cualquier volumen creado en el storage heredan capacidades del hardware de storage, incluyendo snapshots, movilidad y backups de volúmenes, etc. (de vuelta, esto es totalmente independiente de los volúmenes de los sistemas operativos y de cualquier capacidad en la capa de virtualización)
  • Es un largo etc. recursivo luego de este punto, hay muchas más funcionalidades.

Interesante no?

Bueno, eso fue un fast-track insight a infraestructura virtual, y ni hablé de la capa de software que efectivamente permite hablar de "cloud" (ver opennebula, ubuntu cloud, etc.).

En fin, acabo de encontrar un artículo de lonesysadmin al respecto, con el que veo hoy, comparto el punto de vista de una migración paulatina hacia una infraestructura virtualizada, sino una tercerización especializada; ambas con el objetivo a mediano plazo de tener al personal IT inhouse totalmente capacitado para hacerse cargo de las tareas.

Menciona casos reales y problemas simples que uno pensaría que no va a encontrar un team IT implementando virtualización, pero que en tecnologías nuevas suele darse, incluso la gente de IT especializada en infraestructuras pero aún no en virtualización puede cometer esos errores "clásicos", así que hay que poner atención a los problemas (muy) simples también.

3 comentarios:

Leandro Ariel Leonhardt dijo...

Buen aporte yaco, un saludo!

Unknown dijo...

Gracias Leo, un abrazo desde Cba.

ramon dijo...

Muy buen post!