Redudancia de máquinas virtuales
Como es sabido una de las características clave para implementar una infraestructura virtual es poder mantener más de una copia de una máquina virtual.
El hipervisor (Microsoft Hyper-V, Vmware ESX, KVM, Xen, etc.), es un sistema operativo que corre sobre un server físico, este server físico puede fallar y apagarse, apagando así todas las máquinas virtuales que estén corriendo sobre el hipervisor. Por eso tenemos que tener más de un hipervisor corriendo al mismo tiempo, para poder salvar esta emergencia apropiadamente.
El principio de la idea es que si en un hipervisor A tenemos una máquina virtual llamada "EJEMPLO" corriendo, en otro hipervisor B, deberíamos tener una copia de esa máquina, lista para ser arrancada si fallara el primer hipervisor (por ejemplo, si el server físico donde corre A fallara por completo).
De este modo no se pierde la capacidad de provisión de servicio prestada por la máquina virtual EJEMPLO. Lo ideal es que la copia de la máquina virtual EJEMPLO (que está en el hipervisor B), esté lo más actualizada posible, si es posible, actualizada al minuto o segundo de la última modificación.
Migración en Vivo
Esta necesidad de la infraestructura virtual que acabo de explicar suele ser prestada por las capacidades de - Migración en Vivo - Live Migration de un hipervisor, y está disponible en el 99% de los hipervisores en el mercado.
Con una condición: típicamente lo necesario para poder implementar Live Migration es: dos hipervisores y un storage compartido.
Así por ejemplo:
http://blogs.technet.com/blogfiles/chrad/WindowsLiveWriter/VirtualizationTipMigratingtoSANsafterthe_A55A/image_thumb_1.png
La SAN
La cuestión principal a considerar aquí es la SAN.
1) Una SAN de nivel industrial, la más barata posible de comprar, sale muy cara.
2) Una SAN construída a mano, también va a tener un costo mínimo en hardware, ya que tenemos que proveer un suficiente nivel de redundancia (muchos discos, en RAID, mínimamente), y resiliencia al hardware (un server con dos fuentes al menos, de nivel industrial).
El escenario 2) es ideal cuando tenemos servers muy grandes con mucha capacidad de discos disponible (o fácilmente adquirible), y así se puede convertirlo en una SAN muy buena.
Nos podemos ahorrar una cantidad de dinero muy buena del presupuesto y es un gran modo de "entrar" en el campo de storage administration para el personal que va a tener que administrar SANs eventualmente. Luego de esto se puede migrar las máquinas virtuales - sin problemas mayores - a una nueva SAN de nivel industrial, aunque hay muchas organizaciones que corren servers en SANs "caseras" sin planes de migrar a SANs industriales (al contrario, planean incorporar varias/más SANs "caseras" por el mismo costo que les saldría una sola SAN "básica" de nivel industrial).
Armando SANs caseras
Hay muchas posibilidades en cuanto cómo armar una SAN "casera", el hardware hay que tenerlo/conseguirlo, el software puede ser gratis/freeware o no:
Hardware
Este tutorial tiene información respecto al hardware necesario (el soft usado es Openfiler):
"Build Your Own Fibre Channel SAN For Less Than $1000"
http://www.smallnetbuilder.com/nas/nas-howto/31485-build-your-own-fibre-channel-san-for-less-than-1000-part-1
http://www.smallnetbuilder.com/nas/nas-howto/31500-build-your-own-fibre-channel-san-for-less-than-1000-part-2
Software
Con Windows Server:
"Microsoft iSCSI Software Target 3.3 for Windows Server 2008 R2: iSCSI SAN for the masses"
http://www.techrepublic.com/blog/networking/microsoft-iscsi-software-target-33-for-windows-server-2008-r2-iscsi-san-for-the-masses/3936
"Creando un iSCSI Target en Windows Unified Data Storage Server"
http://www.bujarra.com/creando-un-iscsi-target-en-windows-unified-data-storage-server/
"Uso de StarWind para emular cabinas iSCSI/NAS/SAN"
http://www.bujarra.com/uso-de-starwind-para-emular-cabinas-iscsinassan/
Referencia:
http://www.starwindsoftware.com/starwind-free
Con Linux:
- El clásico: Se configura todo a mano, sobre cualquier distribución, un esquema posible es: usar RAID1 para los discos del sistema operativo, configurar iSCSI y exportar un arreglo RAID5 por software - sobre 5 discos - corriendo volúmenes LVM2.
- OpenmediaVault (basado en Debian)
http://www.openmediavault.org/
- Openfiler
http://www.openfiler.com/
http://www.bujarra.com/ProcedimientoOpenfiler.html
"Using Openfiler to build an iSCSI SAN"
http://blog.ogwatermelon.com/?p=1147
Con FreeBSD:
http://www.freenas.org/
Etc.
(Parece que no es muy complicado conseguir software para armar una SAN casera no?)
El tema de la SAN en detalle
Más allá de que construir una SAN no sea una complicación mayor (todo corre sobre estándares, las máquinas virtuales pueden correr sobre una SAN casera hoy y mañana sobre una SAN de dos millones de pesos, se usa hardware de red disponible hoy de 1 giga, y mañana se compra de 10 gigas, algo similar con los switches, etc. etc.)..
La cuestión es que los servers industriales "grandes" tienen en gral. mucho storage, almacenamiento local, si consideramos la cantidad de espacio estándar de una máquina de escritorio. Pero, no suelen tener tanto espacio como para poder armar una SAN de espacio respetable; yendo a lo práctico, es casi seguro que va a haber que comprar discos. Algo parecido pasa con las placas de red: cuantos servers conocen que se hayan comprado desde el vamos con más de 8 placas de red?
Sin embargo, si corremos un hipervisor en un server mediano, digamos uno con 4 placas de red, y 500 GB de disco, podemos montar una cantidad interesante de máquinas virtuales normalmente (dada una cantidad razonable de RAM, que es relativamente muy barata y fácil de conseguir, incluso comprando para servers de marca).
Podemos instalar y correr el hipervisor con storage local, sin SAN. El problema es la redundancia y la resiliencia, qué hacemos si el storage local se pierde por completo..
* Por ejemplo: se quema la controladora del arreglo RAID por hardware por ejemplo, un componente que no se puede "hacer" redudante en los servers de nivel medio estándar: o sea, tenemos una sola placa RAID, se quema y no importa si tenemos 20 discos en RAID, los perdemos todos, hasta conseguir una nueva placa RAID
* Dado un nivel mínimo de previsión, deberíamos tener OTRA placa controladora RAID, al menos "apagada" (en cold-standby), lista para "levantar" el arreglo cuando se queme la otra.
Algo parecido podemos ir pensando de cada componente que se pueda perder en algun momento, y en algun momento entendemos que un server, nuestro hipervisor, puede fallar, así que tenemos que tener al menos dos (2), en producción y como mínimo. Menos de dos conlleva un nivel de riesgo excesivo y obvio para servicios de misión crítica.
Ahí es donde se empieza a pensar en Live Migration y SANs..o podría ser Live Migration sin SANs?
Live Migration sin SANs
Al momento, varios de los hipervisores en el mercado, libres, freeware y pagos, ofrecen esta capacidad, solo hay que tener el cuidado de usar las últimas versiones porque es una característica que se popularizó hace muy poco.
La idea de correr hipervisores y poder hacer live migrations sin SANs se ve así:
http://www.vmware.com/files/images/vsphere_imgs/vmw-dgrm-vsphr-vmotion-enhancements-101.jpg
Esto lo soporta por ejemplo,
* Vmware vSphere 5.1:
http://www.vmware.com/products/datacenter-virtualization/vsphere/vmotion.html
"..both vMotion and Storage vMotion required shared storage to perform live migrations of virtual machines..."
"vSphere 5.1 enables a virtual machine to change its datastore and host simultaneously, even if the two hosts don't have any shared storage in common. It allows virtual machine migration between clusters in a larger datacenter, which may not have a common set of datastores between them but also allows virtual machine migration in small environments without access to expensive shared storage equipment."
* Microsoft Hyper-V 2012
"Configure and Use Live Migration on Non-clustered Virtual Machines"
http://technet.microsoft.com/en-us/library/jj134199.aspx
"Configuring Live Migration without Shared Storage on Windows Server 2012"
http://terrytlslau.tls1.cc/2012/06/configuring-live-migration-without.html
"Windows 8 Server Hyper-V Live Migration Without Shared Storage"
http://www.jamesbannanit.com/2012/03/windows-8-server-hyper-v-live-migration-without-shared-storage/
"Geek of All Trades: Live Migrations
No SAN? No problem. You can live migrate Hyper-V virtual machines without using shared storage."
http://technet.microsoft.com/en-us/magazine/hh987051.aspx
* KVM Linux
"Linux-KVM Management: Live Migration Without Shared Storage"
http://blog.allanglesit.com/2011/08/linux-kvm-management-live-migration-without-shared-storage/
"Ubuntu 11.04 : KVM : live migration w/o shared storage"
http://lost-and-found-narihiro.blogspot.com.ar/2011/07/ubuntu-1104-kvm-live-migration-wo.html
Etc.
¿Cuanto me cuesta esto?
KVM Linux - cero costo de licencia
Microsoft Hyper-V 2012 - cero costo de licencia (en serio)
Vmware vSphere - hay que comprar vSphere (el hipervisor ESX freeware no incorpora esta característica, al menos hasta donde pude indagar, correcciones bienvenidas).
Claro, incluso con ESX, siempre queda el camino de trabajar la migración "a mano":
"Script for VM migration without Virtual Center"
http://vmetc.com/2008/01/03/script-for-vm-migration-without-virtual-center/
* En realidad, la "migración a mano", es básicamente lo que se hacía - se hace todavía - hasta ahora al no tener SAN, independientemente del hipervisor que se estuviera usando. La sensación es que las empresas se dieron cuenta y proveyeron la capacidad - por fin - desde el mismo software (eliminando mayormente el error humano de la ecuación, siempre factible al ensamblar soluciones manuales).
Conclusión
Si estamos usando un hipervisor en producción, tendríamos que usar dos (2) como mínimo, y hay que usar Live Migration o hacerlo manualmente, ya que como vemos, tanto desde los usuarios de los hipervisores (medianas/grandes infraestructuras/organizaciones), como desde los proveedores del software de hipervisor - sean libres/freeware/comerciales - hay mucha gente preocupada por elevar la resiliencia de la infraestructura virtual, y no en vano.
No hay comentarios:
Publicar un comentario