Podemos emplearlo para comprobar cualquier directiva de seguridad/auditoría.
Get-ADUser -LDAPFilter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))"
Espero que os sirva.
Mostrando entradas con la etiqueta Powershell. Mostrar todas las entradas
Mostrando entradas con la etiqueta Powershell. Mostrar todas las entradas
lunes, 19 de mayo de 2014
TIPS & TRICKS: Listar usuarios con permiso de marcado a redes (vpn) con PowerShell
Considero muy útil este comando a la hora de realizar nuestras auditorías de seguridad para comprobar, en el caso de existir una vpn con servidores Windows, los usuarios que tienen permiso para la conexión.
Podemos emplearlo para comprobar cualquier directiva de seguridad/auditoría.
Podemos emplearlo para comprobar cualquier directiva de seguridad/auditoría.
lunes, 16 de diciembre de 2013
Tips & Tricks: Gestión del historial de comandos con Powershell.
En el post de hoy os voy a comentar un par de trucos para el manejo de Powerhsell.
Todos sabéis que podemos recuperar el historial de comandos introducidos en la interface de Powershell mediante las teclas arriba-abajo del cursor. Para hacerlo más cómodo podemos pulsar F7 y nos aparece una ventana emergente para seleccionar el comando (Solo nos recupera los últimos 49 registros).
Por defecto los nuevos 2012 traen un buffer o historial de 4096 comandos. Me parece mucha información disponible, e intentando minimizar siempre los vectores de ataque o de recopilación de información, creo conveniente hacer un $MaximumHistoryCount = 10 o un valor bajo. Lo necesario si estás trabajando con algún comando. Es curioso que si entramos con F7, seguimos teniendo los últimos 49 registros... Bug?
Para poder recuperar solo unos determinados registros del historial, podemos hacer algo así Get-History 32 -count 32 me tomará 32 registros a partir del 33.
Este comando Powershell no se puede ejecutar contra equipos remotos, por lo que solo es posible con acceso a la consola del servidor.
Seguro que todo esto es menos necesario si usas el ISE (Integrated Scripting Environment) para facilitarte un poco la programación de scripts bajo PowerShell. ( Usar el buscador de Windows) Instalado por defecto desde Windows 7 /2008r2.
Espero que os guste el truco, gracias por leerme.
Todos sabéis que podemos recuperar el historial de comandos introducidos en la interface de Powershell mediante las teclas arriba-abajo del cursor. Para hacerlo más cómodo podemos pulsar F7 y nos aparece una ventana emergente para seleccionar el comando (Solo nos recupera los últimos 49 registros).
Por defecto los nuevos 2012 traen un buffer o historial de 4096 comandos. Me parece mucha información disponible, e intentando minimizar siempre los vectores de ataque o de recopilación de información, creo conveniente hacer un $MaximumHistoryCount = 10 o un valor bajo. Lo necesario si estás trabajando con algún comando. Es curioso que si entramos con F7, seguimos teniendo los últimos 49 registros... Bug?
Para poder recuperar solo unos determinados registros del historial, podemos hacer algo así Get-History 32 -count 32 me tomará 32 registros a partir del 33.
Este comando Powershell no se puede ejecutar contra equipos remotos, por lo que solo es posible con acceso a la consola del servidor.
Seguro que todo esto es menos necesario si usas el ISE (Integrated Scripting Environment) para facilitarte un poco la programación de scripts bajo PowerShell. ( Usar el buscador de Windows) Instalado por defecto desde Windows 7 /2008r2.
Espero que os guste el truco, gracias por leerme.
viernes, 13 de diciembre de 2013
Honeypot, Firewall, IPS HomeMade con Powershell.
En el artículo de hoy vamos a trabajar con algunos conceptos básicos de Powershell.
El Script que os presento se basa en el registro del firewall de un equipo Windows 7 o superior.
Como vimos en esta entrada, es necesario configurar el detalle del log del servicio de firewall.
La idea del script es trabajar un poco con Powershell, y ya de paso, proporcionar un servicio a nuestra infraestructura.
Pido perdón de antemano a los expertos en Powershell o programación en general ya que soy de sistemas, y la programación para mi es un mundo desconocido.
El script nos pregunta por pantalla por un número de puerto. Con el número introducido levantamos un socket a la escucha para ese puerto. Esto actuaria como Honeypot, ya que es un puerto para un servicio que realmente no estamos ofreciendo. La idea es que en un ambiente de red local, dejar ese puerto a la escucha, por ejemplo un servidor SSH en el puerto 22, siempre y claro que no lo usemos legítimamente. Mediante el log del firewall de Windows voy a detectar intentos de conexión, que voy a permitir. Cada cierto tiempo incluiré una regla en el firewall denegando todas las conexiones entrantes para la ip que se ha intentado conectar al puerto emulado. Si publicamos ese honeypot hacia internet tendríamos protección ( ip baneada) solo para ese servidor. En el caso de tener varios servidores Windows ofreciendo servicios públicos, deberíamos añadir la capacidad de replicar esta regla al resto de servidores. También se me ocurre que mediante orquestación y automatización mediante SYSTEM CENTER 2012 Orchestrator podríamos lanzar un comando ssh hacia nuestro Firewall perimetral no-windows ( o cualquier sistema de comunicación que nos ofrezca el firewall) para banear la ip en todos los servicios expuestos, sean Windows o cualquier otro.
Este es el script primera versión, que aunque operativo, tiene mucho que mejorar.
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$objForm = New-Object System.Windows.Forms.Form
$objForm.Text = "Baneador IP.kinomakino"
$objForm.Size = New-Object System.Drawing.Size(300,200)
$objForm.StartPosition = "CenterScreen"
$objForm.KeyPreview = $True
$objForm.Add_KeyDown({if ($_.KeyCode -eq "Banear")
{$x=$objTextBox.Text;$objForm.Close()}})
$objForm.Add_KeyDown({if ($_.KeyCode -eq "Cancelar")
{$objForm.Close()}})
$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Size(75,120)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = "OK"
$OKButton.Add_Click({$x=$objTextBox.Text;$objForm.Close()})
$objForm.Controls.Add($OKButton)
$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Size(150,120)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = "Cancela"
$CancelButton.Add_Click({$objForm.Close()})
$objForm.Controls.Add($CancelButton)
$objLabel = New-Object System.Windows.Forms.Label
$objLabel.Location = New-Object System.Drawing.Size(10,20)
$objLabel.Size = New-Object System.Drawing.Size(280,20)
$objLabel.Text = "Introduce el puerto que quieres monitorizar:"
$objForm.Controls.Add($objLabel)
$objTextBox = New-Object System.Windows.Forms.TextBox
$objTextBox.Location = New-Object System.Drawing.Size(10,40)
$objTextBox.Size = New-Object System.Drawing.Size(260,20)
$objForm.Controls.Add($objTextBox)
$objForm.Topmost = $True
$objForm.Add_Shown({$objForm.Activate()})
[void] $objForm.ShowDialog()
$x = $objTextBox.Text
#Toda la parte de arriba es para mostrar el textbox y almacenarlo en $x
$Honeypot = [System.Net.Sockets.TcpListener][int]$x;
$Honeypot.Start();
#Abre el socket con el puerto indicado en el Textbox
while($true)
{
sleep -s 300
#comprueba cada 5minutos si ha habido intento de conexión mediante el log del Firewall.
$logPath="C:\Windows\System32\LogFiles\Firewall\pfirewall.log"
$blackListPath= "C:\Windows\System32\LogFiles\Firewall\blacklist.txt"
$blacklist = Get-Content $blackListPath
$header=(Select-String -Path $logPath -Pattern "^#Fields").Line.Split(" ") | select -Skip 1
$ips=Get-Content $logPath | select -Skip 4 |
ConvertFrom-Csv -Delimiter " " -Header $header |
where {$_."dst-port" -eq $x -and $_.path -eq "RECEIVE" -and $blacklist -notcontains $_."src-ip"} |
select -ExpandProperty "src-ip"
$ips
$ips | Add-Content $blacklistPath
foreach ($ip in $ips){
New-NetFirewallRule -DisplayName "Ip Bloqueada $ip" -Direction Inbound -Action Block -RemoteAddress $ip
#si encuentra algún registro contra el puerto indicado, envia un correo.
$smtpserver = “smtp.gmail.com”
$msg = new-object Net.Mail.MailMessage
$smtp = new-object Net.Mail.SmtpClient($smtpServer )
$smtp.EnableSsl = $True
$smtp.Credentials = New-Object System.Net.NetworkCredential(“nick gmail sin @gmail, “clavegmail”);
$msg.From = “correo origen”
$msg.To.Add(”correo destino”)
$msg.Subject = “Ip baneada”
$msg.Body = “La ip $ip ha sido baneada por intento de conexión al honeypot”
$smtp.Send($msg)
}
}
Para poder utilizarlo debes activar el detalle en el firewall de Windows así. En el mismo directorio debes crear un fichero vacio llamado blacklist.txt. Cambia los datos del correo y listo.
Una vez ejecutado comprobamos que el puerto introducido está a la escucha: netstat -ano
Ahora desde un equipo realizo un intento de conexión al puerto indicado, en este caso un scan completo.
Si todo ha ido bien, y esperando 5 minutos al menos, volvemos a realizar el scan y vemos que estamos baneados por el firewall.
En las reglas del Firewall de Windows compruebo que se ha creado la regla.
En unos segundos el sonido del correo en el móvil me indica que esto también ha ido bien.
En el fichero Blacklist almacenaremos las IP baneadas, que podemos usar como fuente de información en el supuesto de tener un firewall perimetral, por ejemplo pasándolo por ssh en un array de IP Baneadas.
Parsear el log para detectar el scan de puertos hubiera sido factible, pero si solo tengo publicado un servicio ( puerto) de este server no tendría ninguna manera, por eso lo del honeypot.
El lenguaje es bastante sencillo, y es muy fácil empezar a programar en Powershell. Este script lo he hecho mirando por la world wide web y con la ayuda de Dirk74 (technet forum).
Espero poder trabajar mas en esta idea, y añadir alguna mejora y capacidades nuevas, en próximas entregas de Inseguros lo intentaré.
Como siempre, espero que os guste, y gracias por leerme !!!
El Script que os presento se basa en el registro del firewall de un equipo Windows 7 o superior.
Como vimos en esta entrada, es necesario configurar el detalle del log del servicio de firewall.
La idea del script es trabajar un poco con Powershell, y ya de paso, proporcionar un servicio a nuestra infraestructura.
Pido perdón de antemano a los expertos en Powershell o programación en general ya que soy de sistemas, y la programación para mi es un mundo desconocido.
El script nos pregunta por pantalla por un número de puerto. Con el número introducido levantamos un socket a la escucha para ese puerto. Esto actuaria como Honeypot, ya que es un puerto para un servicio que realmente no estamos ofreciendo. La idea es que en un ambiente de red local, dejar ese puerto a la escucha, por ejemplo un servidor SSH en el puerto 22, siempre y claro que no lo usemos legítimamente. Mediante el log del firewall de Windows voy a detectar intentos de conexión, que voy a permitir. Cada cierto tiempo incluiré una regla en el firewall denegando todas las conexiones entrantes para la ip que se ha intentado conectar al puerto emulado. Si publicamos ese honeypot hacia internet tendríamos protección ( ip baneada) solo para ese servidor. En el caso de tener varios servidores Windows ofreciendo servicios públicos, deberíamos añadir la capacidad de replicar esta regla al resto de servidores. También se me ocurre que mediante orquestación y automatización mediante SYSTEM CENTER 2012 Orchestrator podríamos lanzar un comando ssh hacia nuestro Firewall perimetral no-windows ( o cualquier sistema de comunicación que nos ofrezca el firewall) para banear la ip en todos los servicios expuestos, sean Windows o cualquier otro.
Este es el script primera versión, que aunque operativo, tiene mucho que mejorar.
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$objForm = New-Object System.Windows.Forms.Form
$objForm.Text = "Baneador IP.kinomakino"
$objForm.Size = New-Object System.Drawing.Size(300,200)
$objForm.StartPosition = "CenterScreen"
$objForm.KeyPreview = $True
$objForm.Add_KeyDown({if ($_.KeyCode -eq "Banear")
{$x=$objTextBox.Text;$objForm.Close()}})
$objForm.Add_KeyDown({if ($_.KeyCode -eq "Cancelar")
{$objForm.Close()}})
$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Size(75,120)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = "OK"
$OKButton.Add_Click({$x=$objTextBox.Text;$objForm.Close()})
$objForm.Controls.Add($OKButton)
$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Size(150,120)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = "Cancela"
$CancelButton.Add_Click({$objForm.Close()})
$objForm.Controls.Add($CancelButton)
$objLabel = New-Object System.Windows.Forms.Label
$objLabel.Location = New-Object System.Drawing.Size(10,20)
$objLabel.Size = New-Object System.Drawing.Size(280,20)
$objLabel.Text = "Introduce el puerto que quieres monitorizar:"
$objForm.Controls.Add($objLabel)
$objTextBox = New-Object System.Windows.Forms.TextBox
$objTextBox.Location = New-Object System.Drawing.Size(10,40)
$objTextBox.Size = New-Object System.Drawing.Size(260,20)
$objForm.Controls.Add($objTextBox)
$objForm.Topmost = $True
$objForm.Add_Shown({$objForm.Activate()})
[void] $objForm.ShowDialog()
$x = $objTextBox.Text
#Toda la parte de arriba es para mostrar el textbox y almacenarlo en $x
$Honeypot = [System.Net.Sockets.TcpListener][int]$x;
$Honeypot.Start();
#Abre el socket con el puerto indicado en el Textbox
while($true)
{
sleep -s 300
#comprueba cada 5minutos si ha habido intento de conexión mediante el log del Firewall.
$logPath="C:\Windows\System32\LogFiles\Firewall\pfirewall.log"
$blackListPath= "C:\Windows\System32\LogFiles\Firewall\blacklist.txt"
$blacklist = Get-Content $blackListPath
$header=(Select-String -Path $logPath -Pattern "^#Fields").Line.Split(" ") | select -Skip 1
$ips=Get-Content $logPath | select -Skip 4 |
ConvertFrom-Csv -Delimiter " " -Header $header |
where {$_."dst-port" -eq $x -and $_.path -eq "RECEIVE" -and $blacklist -notcontains $_."src-ip"} |
select -ExpandProperty "src-ip"
$ips
$ips | Add-Content $blacklistPath
foreach ($ip in $ips){
New-NetFirewallRule -DisplayName "Ip Bloqueada $ip" -Direction Inbound -Action Block -RemoteAddress $ip
#si encuentra algún registro contra el puerto indicado, envia un correo.
$smtpserver = “smtp.gmail.com”
$msg = new-object Net.Mail.MailMessage
$smtp = new-object Net.Mail.SmtpClient($smtpServer )
$smtp.EnableSsl = $True
$smtp.Credentials = New-Object System.Net.NetworkCredential(“
$msg.From = “
$msg.To.Add(”
$msg.Subject = “Ip baneada”
$msg.Body = “La ip $ip ha sido baneada por intento de conexión al honeypot”
$smtp.Send($msg)
}
}
Para poder utilizarlo debes activar el detalle en el firewall de Windows así. En el mismo directorio debes crear un fichero vacio llamado blacklist.txt. Cambia los datos del correo y listo.
Una vez ejecutado comprobamos que el puerto introducido está a la escucha: netstat -ano
Ahora desde un equipo realizo un intento de conexión al puerto indicado, en este caso un scan completo.
Si todo ha ido bien, y esperando 5 minutos al menos, volvemos a realizar el scan y vemos que estamos baneados por el firewall.
En las reglas del Firewall de Windows compruebo que se ha creado la regla.
En unos segundos el sonido del correo en el móvil me indica que esto también ha ido bien.
En el fichero Blacklist almacenaremos las IP baneadas, que podemos usar como fuente de información en el supuesto de tener un firewall perimetral, por ejemplo pasándolo por ssh en un array de IP Baneadas.
Parsear el log para detectar el scan de puertos hubiera sido factible, pero si solo tengo publicado un servicio ( puerto) de este server no tendría ninguna manera, por eso lo del honeypot.
El lenguaje es bastante sencillo, y es muy fácil empezar a programar en Powershell. Este script lo he hecho mirando por la world wide web y con la ayuda de Dirk74 (technet forum).
Espero poder trabajar mas en esta idea, y añadir alguna mejora y capacidades nuevas, en próximas entregas de Inseguros lo intentaré.
Como siempre, espero que os guste, y gracias por leerme !!!
martes, 3 de diciembre de 2013
Windows Firewall Activación y Scripting.
Uno de los aspectos de la seguridad que suelo comentar con los colegas de profesión es la necesidad de saber que está pasando en nuestros sistemas. A menudo los administradores piensan que no hay ningún problema de seguridad, por una simple razón, no monitorizan nada. Esta técnica tiene la misma funcionalidad que tenía mi técnica cuando era joven con las reparaciones del coche. Si escuchaba algún ruido en el motor subía la radio...
Cuando hablamos de sistemas Microsoft tenemos un firewall integrado, que en las nuevas versiones, me permite bastante modularidad al más puro estilo Iptables. Podemos filtrar tráfico entrante y SALIENTE. A lo largo de mi carrera profesional he visto muy pocas veces el firewall de Windows bien configurado, por no decir que siempre lo suelo ver deshabilitado.
En el mejor de los casos, si eres un administrador de sistemas concienciado, intentarás trabajar con el firewall On. Bien, y ahora? Generalmente en las empresas nos pagan por trabajar, y parte de nuestro trabajo es monitorizar ese firewall instalado en los equipos.
Como todos sabéis, la mayoría de eventos del sistema se pueden revisar desde el cómodo Visor de Eventos. Tenemos registros de auditoría para inicios de sesión, registros de aplicaciones, incluso una rama para firewall. Bien, esta opción solo monitoriza los cambios en el firewall, cuando creamos reglas, cuando deshabilitamos pero no muestra el registro completo de peticiones aprobadas o denegadas.
En este episodio de Inseguros vamos a habilitar el registro completo del log del Firewall del un servidor Windows 2012.
Lo primero que haremos será habilitar el firewall y bloquear un puerto, en mi caso voy a bloquear el puerto 80 del servidor IIS. Comprobamos que no tenemos activada la opción de registrar paquetes descartados y correctos. Habilitamos este comportamiento para nuestro perfil de Firewall, ubicación del fichero, tamaño y listo !!.
Ya podemos ir al fichero de Logs y ver realmente qué esta pasando con nuestra regla de filtrado para el firewall.
Lo interesante de esto reside en poder automatizar la gestión de este log, enviando el fichero periódicamente a nuestro syslog o herramienta SIEM. Vamos a lanzar un comando que nos lea el fichero y nos muestre las ocurrencias que encuentre con la sentencia DROP TCP.
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "drop tcp "
Podemos añadir una condición basada en regular expressión para filtrar los intentos a un determinado puerto.
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -pattern '(DROP TCP.*80)'
Sin duda recomiendo establecer alguna estrategia de supervisión del fichero de logs del firewall, incluido el tamaño y la política de conservación del fichero.
Como siempre, espero que os guste y gracias por leerme !!!.
sábado, 2 de noviembre de 2013
Introducción a la virtualización. VMotion high availability
Tras el artículo de como instalar VCenter sobre alguno de los HOSTS que hemos preparado para nuestra Introducción a la virtualización, con almacenamiento bajo FreeNas, hoy vamos a configurar valor añadido a nuestra infraestructura con todo tipo de tecnologías para mover nuestras máquinas virtuales.
Nos quedamos configurando una máquina virtual que emplee almacenamiento en red. Ahora tenemos que parar la máquina virtual. Editamos su configuración y comprobamos que no "depende" de ningún fichero ISO almacenado en un Datastore Local. Para ello ponemos Client Device y listo.
En la pestaña opciones, avanzadas/general pichamos en Configuration Parameters y buscamos replay.supported con valor TRUE. Añadimos:
replay.allowFT valor TRUE
replay.allowBTonly valor TRUE
Comprobamos en la pestaña Summary del Host ESXi que no tenemos configurada ninguna de las tecnologías que necesitamos.
Ahora debemos configurar VMotion, la tecnología de VmWare para mover máquinas en caliente.
Accedemos a VCenter, Hosts And Clusters, Configuration, Networking:
Realizamos este mismo proceso en el segundo HOSTS ESXi.
Debemos tener en cuenta que estas tecnologías, aparte de necesitar un puerto especial VMKernel para gestión interna, los Switches virtuales deben tener conectada al menos una tarjeta de red dedica para el transporte de máquinas/almacenamiento. En entornos de producción deberíamos tener al menos dos tarjetas de 1 Gb mínimo para proporcionar redundancia. Para estos laboratorios puedes usar una sola tarjeta en un único VSwitch, pero no es lo recomendable.
Ahora es el turno de crear un cluster bajo nuestro Datacenter.
Y ahora movemos los dos HOSTS ESXi bajo el cluster.
Después de que se instale el agente para HA en cada HOSTS, podemos proceder a migrar una máquina entre HOSTS.
Si todo ha ido bien, vuestra máquina virtual migrará de equipo HOSTS sin ningún problema.
Prueba ahora a apagar el HOST que alberga la máquina virtual, que ocurre? :-)
Espero que os gusten esta seria de artículos sobre VMWare. Gracias por leerme.
Nos quedamos configurando una máquina virtual que emplee almacenamiento en red. Ahora tenemos que parar la máquina virtual. Editamos su configuración y comprobamos que no "depende" de ningún fichero ISO almacenado en un Datastore Local. Para ello ponemos Client Device y listo.
En la pestaña opciones, avanzadas/general pichamos en Configuration Parameters y buscamos replay.supported con valor TRUE. Añadimos:
replay.allowFT valor TRUE
replay.allowBTonly valor TRUE
Comprobamos en la pestaña Summary del Host ESXi que no tenemos configurada ninguna de las tecnologías que necesitamos.
Ahora debemos configurar VMotion, la tecnología de VmWare para mover máquinas en caliente.
Accedemos a VCenter, Hosts And Clusters, Configuration, Networking:
Realizamos este mismo proceso en el segundo HOSTS ESXi.
Debemos tener en cuenta que estas tecnologías, aparte de necesitar un puerto especial VMKernel para gestión interna, los Switches virtuales deben tener conectada al menos una tarjeta de red dedica para el transporte de máquinas/almacenamiento. En entornos de producción deberíamos tener al menos dos tarjetas de 1 Gb mínimo para proporcionar redundancia. Para estos laboratorios puedes usar una sola tarjeta en un único VSwitch, pero no es lo recomendable.
Ahora es el turno de crear un cluster bajo nuestro Datacenter.
Y ahora movemos los dos HOSTS ESXi bajo el cluster.
Después de que se instale el agente para HA en cada HOSTS, podemos proceder a migrar una máquina entre HOSTS.
Si todo ha ido bien, vuestra máquina virtual migrará de equipo HOSTS sin ningún problema.
Prueba ahora a apagar el HOST que alberga la máquina virtual, que ocurre? :-)
Espero que os gusten esta seria de artículos sobre VMWare. Gracias por leerme.
jueves, 31 de octubre de 2013
Introducción a la virtualización. VCenter.
En el último episodio de Inseguros configuramos un entorno con dos Host ESXi 5.5 compartiendo almacenamiento proporcionado por una SAN virtual gestionada por FREENAS.
Hoy vamos a continuar con esta seria de artículos de introducción a la virtualización, instalando VCenter.
VCenter es una aplicación, o conjunto de ellas que nos permite acceder a las funcionalidades avanzadas que trae el producto ESXi. En un entorno Microsoft estaríamos hablando del componente Virtual Machine Manager de System Center 2012.
Como aplicación podemos instalarla de varias maneras. Como un fichero OVF ( Open Virtualization Format) desplegada como un appliance (como una máquina virtual) que podemos descargar desde la web. También podemos instalarla bajo un servidor Windows, virtual o físico. Si elegimos la primera opción, es tan sencillo como descargar el fichero, copiarlo hacia nuestro DataStore del host Esxi que queremos usar para albergar la máquina, e importarlo. Automágicamente se crearán los discos duros y los ficheros de configuración de la máquina virtual. Internamente VCenter usa un motor de base de datos Postgresql. En cada versión las especificaciones cambian, pero a la fecha de hoy podremos gestionar tan solo 5 Host ESXi con este tipo de base de datos. Como base de datos externa podemos usar SOLO ORACLE. Money Money Money. Si instalamos VCenter bajo un sistema Windows podrá emplear tanto SQL Express (gratuita) como SQL Server. Si nos decidimos por esta opción, tenemos que tener en cuenta que debemos gestionar todo el sistema operativo Windows que hay por debajo de VCenter. Si usamos el appliance virtual, estaremos usando una versión especial de Suse Linux, por lo que a priori el mantenimiento es mínimo.
Una de las cosas que más me llamó la atención sobre VCenter es que no se instala bajo tecnologías de Fault Tolerance. Un elemento tan crítico debería implementarlo. Sin embargo desde VMware indican que no es necesario ya que VCenter almacena toda la información en la base de datos, y es esta la que debe ser asegurada, ya que el despliegue de VCenter en un nuevo servidor, como veremos aquí, es cuestión de unos pocos minutos. Yo me quedo con VMM de Ms como pudimos ver aquí, instalar fault tolerance es cuestión de unos pocos minutos, y garantizas el servicio...
**queda claro con esto que solo vamos a instalar VSphere en uno de los dos HOST ESXi...***
Otra de las cosas que no me agradan mucho es el consumo de recursos. VCenter se va a gastar 6Gb de RAM para el solito. Hablando con expertos en la materia consiguen "tunning" hasta unos 4 Gb de RAM, pero me parece muchísimo si lo comparamos con los modestos 2-4Gb que puede consumir Virtual Machine Manager de System Center.
Pensar que con la virtualización queremos conseguir abstracción de la capa Hardware mediante Software, para poder realizar "tareas". Estas tareas pueden ser recuperación ante desastres. En un entorno bien configurado, si necesitamos XX Gb de RAM para un servidor/servicio, debemos reservar otros tantos en un segundo nodo, para hacer nuestra plataforma tolerante a fallos, o al menos alta disponibilidad... Es un handicap que mucha gente pasa por alto, y en el momento de caídas de elementos físicos, se encuentran con que no tienen capacidad para albergar estas Máquinas virtuales que hemos ido creando a golpe de click.
Vamos a al menú File, y deploy OVF. Seleccionamos el fichero OVA que hemos descargado y en unos cuantos clicks tenemos appliance desplegado, que no configurado.
Arrancamos la máquina virtual que se ha creado con VSphere y seguimos el proceso de configuración por defecto que nos propone el instalador, salvo el direccionamiento IP. El usuario es root y la password es Vmware. Como buen experto en seguridad que eres, no cambies esta clave nada más empezar el proceso. A lo largo de varias instalaciones he tenido problemas con esto. Te recomiendo que no cambies esta clave al menos hasta 30 minutos desde que se instaló. Quizás algún experto pueda aclararnos el por qué !!!
Debemos configurar el servidor de tiempo, el mismo que hemos usado en toda nuestra infraestructura. Esto es algo básico a la par que importante.
Ahora configuramos los datos del direccionamiento IP.
Ya tenemos configurado VCenter. Podemos acceder con el mismo cliente que usamos para acceder al ESXi, el VSphere Client, esta vez indicando la IP del appliance Vcenter, no la del Host ESXi. Hasta VmWare recomienda solo usar VCenter para manejar los hosts, para evitar incoherencias si configuramos aspectos de las dos maneras.
Como podéis ver, es muy similar a cuando entramos en ESXi. Lo primero que vamos a hacer es crear un DataCenter que albergará todos los equipos que tenemos a nuestra disposición. Se recomienda agrupar los DataCenter con un criterio más o menos parecido al de Site de Active Directory, es decir, grupo de recursos unidos por enlaces de alta velocidad. No tiene sentido tener una delegación en Madrid y otra en Barcelona bajo un mismo Datacenter, si físicamente están ubicados en distintos emplazamientos.
Añadimos los dos hosts ESXi que vamos a manejar.
Ya debes ver los dos equipos ESXi bajo el datacenter.
Ahora vamos a pasar directamente a trabajar con Fault Tolerance. Antes de nada vamos a definir unos conceptos.
VMotion es la solución de Vmware para mover máquinas entre distintos HOST. Sería el equivalente a Live Migrations de Microsoft. Ambos en caliente.
Storage VMotion sería la solución de Vmware para mover máquinas virtuales, con su almacenamiento.
HA en VmWare es alta disponibilidad. Esto implica caída del servicio desde que se cae un servidor, hasta que se inicia la máquina virtual en otro servidor ESXi.
Faul Tolerance es tolerancia a fallos cero, en el que caídas de servidores ESXi no interrumpirían el servicio de la máquina virtual.
Esta de moda el término SLA (Services Level Agreement) en el que establecemos distintos parámetros de calidad de servicio. El término 99.9% SLA suele referirse al tiempo que permanece activo un servicio, por ejemplo, la aplicación de la empresa. Cuanto es 99.9% ? es mucho tiempo de caídas de servicio? poco?
365 días x 24 horas= 8760 horas al año.
99.9% de 8760 son 98 horas, 4 días de caída de servicio al año.
99.99% de 8760 es 1 hora.
En que SLA consideras que se mueven tus aplicaciones críticas? Cuanto crees que es tolerable para tus usuarios?
Nos ponemos con ello. Debemos tener al menos una máquina virtual configurado en el almacenamiento compartido, y dependiente de uno de los hosts ESXi.
El proceso de creación de una máquina virtual en ESXi esta muy documentado, por lo que os sugiero que uséis cualquier documento disponible, pero teniendo en cuenta configurar el almacenamiento de la máquina virtual en el DataStore usado bajo FreeNas ( no usar datastore local).
http://www.josemariagonzalez.es/2011/10/03/como-crear-maquinas-virtuales-vsphere-esxi-5.html
Espero que os guste el artículo, y mientras que creáis la máquina virtual, nos vemos en el próximo artículo.
Gracias por leerme.
Hoy vamos a continuar con esta seria de artículos de introducción a la virtualización, instalando VCenter.
VCenter es una aplicación, o conjunto de ellas que nos permite acceder a las funcionalidades avanzadas que trae el producto ESXi. En un entorno Microsoft estaríamos hablando del componente Virtual Machine Manager de System Center 2012.
Como aplicación podemos instalarla de varias maneras. Como un fichero OVF ( Open Virtualization Format) desplegada como un appliance (como una máquina virtual) que podemos descargar desde la web. También podemos instalarla bajo un servidor Windows, virtual o físico. Si elegimos la primera opción, es tan sencillo como descargar el fichero, copiarlo hacia nuestro DataStore del host Esxi que queremos usar para albergar la máquina, e importarlo. Automágicamente se crearán los discos duros y los ficheros de configuración de la máquina virtual. Internamente VCenter usa un motor de base de datos Postgresql. En cada versión las especificaciones cambian, pero a la fecha de hoy podremos gestionar tan solo 5 Host ESXi con este tipo de base de datos. Como base de datos externa podemos usar SOLO ORACLE. Money Money Money. Si instalamos VCenter bajo un sistema Windows podrá emplear tanto SQL Express (gratuita) como SQL Server. Si nos decidimos por esta opción, tenemos que tener en cuenta que debemos gestionar todo el sistema operativo Windows que hay por debajo de VCenter. Si usamos el appliance virtual, estaremos usando una versión especial de Suse Linux, por lo que a priori el mantenimiento es mínimo.
Una de las cosas que más me llamó la atención sobre VCenter es que no se instala bajo tecnologías de Fault Tolerance. Un elemento tan crítico debería implementarlo. Sin embargo desde VMware indican que no es necesario ya que VCenter almacena toda la información en la base de datos, y es esta la que debe ser asegurada, ya que el despliegue de VCenter en un nuevo servidor, como veremos aquí, es cuestión de unos pocos minutos. Yo me quedo con VMM de Ms como pudimos ver aquí, instalar fault tolerance es cuestión de unos pocos minutos, y garantizas el servicio...
**queda claro con esto que solo vamos a instalar VSphere en uno de los dos HOST ESXi...***
Otra de las cosas que no me agradan mucho es el consumo de recursos. VCenter se va a gastar 6Gb de RAM para el solito. Hablando con expertos en la materia consiguen "tunning" hasta unos 4 Gb de RAM, pero me parece muchísimo si lo comparamos con los modestos 2-4Gb que puede consumir Virtual Machine Manager de System Center.
Pensar que con la virtualización queremos conseguir abstracción de la capa Hardware mediante Software, para poder realizar "tareas". Estas tareas pueden ser recuperación ante desastres. En un entorno bien configurado, si necesitamos XX Gb de RAM para un servidor/servicio, debemos reservar otros tantos en un segundo nodo, para hacer nuestra plataforma tolerante a fallos, o al menos alta disponibilidad... Es un handicap que mucha gente pasa por alto, y en el momento de caídas de elementos físicos, se encuentran con que no tienen capacidad para albergar estas Máquinas virtuales que hemos ido creando a golpe de click.
Vamos a al menú File, y deploy OVF. Seleccionamos el fichero OVA que hemos descargado y en unos cuantos clicks tenemos appliance desplegado, que no configurado.
Arrancamos la máquina virtual que se ha creado con VSphere y seguimos el proceso de configuración por defecto que nos propone el instalador, salvo el direccionamiento IP. El usuario es root y la password es Vmware. Como buen experto en seguridad que eres, no cambies esta clave nada más empezar el proceso. A lo largo de varias instalaciones he tenido problemas con esto. Te recomiendo que no cambies esta clave al menos hasta 30 minutos desde que se instaló. Quizás algún experto pueda aclararnos el por qué !!!
Debemos configurar el servidor de tiempo, el mismo que hemos usado en toda nuestra infraestructura. Esto es algo básico a la par que importante.
Ahora configuramos los datos del direccionamiento IP.
Ya tenemos configurado VCenter. Podemos acceder con el mismo cliente que usamos para acceder al ESXi, el VSphere Client, esta vez indicando la IP del appliance Vcenter, no la del Host ESXi. Hasta VmWare recomienda solo usar VCenter para manejar los hosts, para evitar incoherencias si configuramos aspectos de las dos maneras.
Como podéis ver, es muy similar a cuando entramos en ESXi. Lo primero que vamos a hacer es crear un DataCenter que albergará todos los equipos que tenemos a nuestra disposición. Se recomienda agrupar los DataCenter con un criterio más o menos parecido al de Site de Active Directory, es decir, grupo de recursos unidos por enlaces de alta velocidad. No tiene sentido tener una delegación en Madrid y otra en Barcelona bajo un mismo Datacenter, si físicamente están ubicados en distintos emplazamientos.
Añadimos los dos hosts ESXi que vamos a manejar.
Ya debes ver los dos equipos ESXi bajo el datacenter.
Ahora vamos a pasar directamente a trabajar con Fault Tolerance. Antes de nada vamos a definir unos conceptos.
VMotion es la solución de Vmware para mover máquinas entre distintos HOST. Sería el equivalente a Live Migrations de Microsoft. Ambos en caliente.
Storage VMotion sería la solución de Vmware para mover máquinas virtuales, con su almacenamiento.
HA en VmWare es alta disponibilidad. Esto implica caída del servicio desde que se cae un servidor, hasta que se inicia la máquina virtual en otro servidor ESXi.
Faul Tolerance es tolerancia a fallos cero, en el que caídas de servidores ESXi no interrumpirían el servicio de la máquina virtual.
Esta de moda el término SLA (Services Level Agreement) en el que establecemos distintos parámetros de calidad de servicio. El término 99.9% SLA suele referirse al tiempo que permanece activo un servicio, por ejemplo, la aplicación de la empresa. Cuanto es 99.9% ? es mucho tiempo de caídas de servicio? poco?
365 días x 24 horas= 8760 horas al año.
99.9% de 8760 son 98 horas, 4 días de caída de servicio al año.
99.99% de 8760 es 1 hora.
En que SLA consideras que se mueven tus aplicaciones críticas? Cuanto crees que es tolerable para tus usuarios?
Nos ponemos con ello. Debemos tener al menos una máquina virtual configurado en el almacenamiento compartido, y dependiente de uno de los hosts ESXi.
El proceso de creación de una máquina virtual en ESXi esta muy documentado, por lo que os sugiero que uséis cualquier documento disponible, pero teniendo en cuenta configurar el almacenamiento de la máquina virtual en el DataStore usado bajo FreeNas ( no usar datastore local).
http://www.josemariagonzalez.es/2011/10/03/como-crear-maquinas-virtuales-vsphere-esxi-5.html
Espero que os guste el artículo, y mientras que creáis la máquina virtual, nos vemos en el próximo artículo.
Gracias por leerme.
miércoles, 30 de octubre de 2013
Introducción a la virtualización. Install ESXi 5.5 y almacenamiento SAN.
En el post de hoy vamos a iniciar el proceso para crear dos servidores HOST ESXi desde cero. Configuraremos un almacenamiento compartido mediante ISCSi con un servidor virtual FREENAS.
Para realizar esta práctica necesitas haber instalado y configurado el sistema FREENAS de este artículo. Si prefieres usar un almacenamiento bajo Windows, debes tener configurada la parte de ISCSi de este artículo. Perdón, eso en el caso de que no tengas una cabina de discos física disponible para las pruebas.
Para instalar los dos HOST ESXi necesitamos dos ordenadores. Si no tienes dos pc disponibles, puedes usar cualquier Hypervisor tipo 2 ( Vmware Workstatio, player, Parallels, VirtualBox etc). En el artículo no haremos referencia a que estos equipos estén físicos o virtuales. Yo por ejemplo voy a usar un HOST ESXi físico que ya tengo instalado, y usaré uno virtual sobre mi portátil mediante VMware Player.
Lo primero que vamos a hacer es descargar la versión gratuita de Vmware Vsphere ESXI 5.5. Una vez tengamos la imagen ISO descargada, la grabamos a un cd y arrancamos el equipo para instalarlo. Si estás en un laboratorio con VirtualBox, deberás crear una máquina virtual desde cero, y añadirle la ISO al CD-ROM. Debéis configurar 2 CPU virtuales y 4Gb Ram para poder iniciar la instalación. Podéis seguir este manual, gracias al amigo de 1GB de Información.
El proceso de instalación de un HOST ESXi es tan sencillo como esto:
Ahora ya tenemos instalado el sistema operativo que hará de hypervisor tipo 1 ESXi. Recuerdo un día que le explique un poco el asunto a un amigo, y se cabreo cuando instalo el ESXi sobre su equipo físico para sus pruebas, y me dice: Kino esto que es, no puedo hacer nada. En efecto. Hemos instalado el sistema operativo, ahora debemos instalar un cliente, al cual nos conectaremos por red para trabajar con VmWare ESXi. Hablamos de un Kernel de unos 30 MB, no querrás que también tenga interface gráfico...
Accedemos a la URL y descargamos/ejecutamos el cliente.
Seguimos con la consola del ESXi y pulsamos F2 para acceder a las pocas tareas que podemos administrar localmente.
Básicamente vamos a configurar una dirección IP estática, para poder acceder desde el cliente VSphere que hemos instalado en nuestro equipo.
Como podéis leer en la advertencia, desde hace unos versiones hay opciones que no están disponibles mediante el cliente VSphere que hemos instalado, y solo se pueden acceder mediante la consola web de administración. De momento vamos a trabajar con el Client. ya que en la mayoría de sitios se hace referencia a este cliente, y no al WEBClient que de momento, deja bastante que desear.
Este es nuestro HOST ESXi listo para virtualizar.
Lo primero que vamos a hacer es configurar la sincronización con la hora mediante un servidor NTP. Es básico si no quieres tener problemas entre los HOSTS. Para ello, accedemos a Configuration, Time Configuration.
Repetimos esta operación con el segundo Hosts ESXi para tener dos equipos listos para realizar Fault Tolerance.
Ya tenemos preparado Out of a Box el ESXi. Antes de comenzar a instalar máquinas virtuales, vamos a trabajar con los conceptos que comentamos en el post de Almacenamiento y FreeNas para añadir un DataStore en red, que usaremos en ambos equipos ESXi para compartir almacenamiento.
Cuando instalamos un ESXi por defecto crea un vSwitch con dos tipos de puertos, VM y Kernel. Los primeros digamos que serían como bocas de un switch físico que sirven para comunicar las máquinas virtuales entre sí, y contra el mundo físico. Los puertos de tipo Kernel son unos puertos específicos para las tareas internas del equipo.
Para conectar un almacenamiento ISCSi externo por IP, debemos conectar un puerto tipo Kernel ( ya que realmente será el ESXi el que controle el almacenamiento, no las máquinas virtuales).
Entramos en properties del Vswitch0 y añadimos un puerto tipo Kernel, tal y como muestro:
Ahora tenemos a nivel de Networking, todo preparado para añadir un almacenamiento ISCSi. Ahora desde Configuration, Storage Adapters configuramos la "tarjeta" que conectará con el almacenamiento.
Ahora vinculamos el puerto tipo Kernel del Switch para que sea usado por el iniciador ISCSi. y configuramos la dirección del servidor FREENAS.
Bien. Hasta ahora, solo hemos configurado digamos "el cable" que conecta el equipo al almacenamiento. Como vimos en el anterior post, vamos a configurar un DATASTORE para que ESXi almacene sus máquinas virtuales en ese disco en red.
Hasta este punto, en Hyper-V sería tan sencillo como la segunda parte de este post. Configurar desde el panel de control el destino ISCS mediante una IP.
Este procedimiento lo debemos hacer en el segundo HOST ESXi que estamos configurando.
Ahora desde Configuration, Storage, añadimos un nuevo Datastore que use el disco.
Hasta aquí todo bien. Quizás no !!! Existe un Bug en la versión actual de FREENAS 9.1.1 por el que si usamos un disco para ISCSi y lo particionamos, no se puede volver a particionar. Esto es un bug de FREENAS. Si has usado la práctica anterior con FREENAS y has creado una partición NTFS para poder montar esta LUN en un Windows, cuando agregues este almacenamiento a ESXi e intente formatearlo como VMFS vas a tener un error. La solución es crear un Extend en Freenas con otro disco.
Si todo ha ido bien, tendrás dos DataStores disponibles en tu ESXi.
Hasta aquí, en un entorno Hyper-V solo tendríamos que ir al administrador de discos, y particionar el nuevo disco.
Ahora es el turno de realizar este último paso en el segundo HOST hasta el paso del DataStore. Es decir, una vez que conectemos el disco mediante ISCSi, en la sección de DataStores tendremos disponible el disco ya particionado.
Ahora tenemos dos equipos en cierta alta disponibilidad. Si el equipo que ejecuta la máquina virtual se detuviese, podríamos manualmente ir al segundo HOST, importar la máquina virtual al ESXi( solo la configuración, el disco duro virtual no ya que usamos almacenamiento compartido !!!) y arrancarla. Esto conlleva ventana de caída de servicio, mínimo el tiempo de enterarte e iniciar la máquina.
Para hacer uso de las tecnologías de alta disponibilidad automáticas, tolerancia a fallos ( cero downtime) y demás, debemos hacer uso de Vpshere. En sistemas Hyper-V usaríamos el complemento Virtual Machine Manager de System Center.
Vpshere es de pago, aunque podemos probarlo alegremente durante 60 días. Esta es la clave del licenciamiento en la virtualización. El fabricante te ofrece algo básico gratuitamente, y todos los featuring que queremos, los pagamos. Hay algo bueno, y es que Microsoft está ofreciendo todos los servicios relativos a virtualización y cloud en un producto, SYSTEM CENTER 2012 bastante asequible. Los amigos de OpenStack y KVM aquí darían un golpe en la mesa, argumentando que en esos sistemas no hay que pagar. En efecto, pero el coste de configurar Fault Tolerance entre dos host KVM puede que sea bastante superior que pagar la licencia en un sistema propietario y configurarlo en unos minutos... cada uno...
Creo que se ha extendido demasiado este artículo. En el próximo instalaremos Vsphere, el software que va a hacer posible todas las funciones extras para ESXi, y en concreto la "conexión" o "trabajo en grupo" de varios host ESXi.
Gracias por leerme.
Para realizar esta práctica necesitas haber instalado y configurado el sistema FREENAS de este artículo. Si prefieres usar un almacenamiento bajo Windows, debes tener configurada la parte de ISCSi de este artículo. Perdón, eso en el caso de que no tengas una cabina de discos física disponible para las pruebas.
Para instalar los dos HOST ESXi necesitamos dos ordenadores. Si no tienes dos pc disponibles, puedes usar cualquier Hypervisor tipo 2 ( Vmware Workstatio, player, Parallels, VirtualBox etc). En el artículo no haremos referencia a que estos equipos estén físicos o virtuales. Yo por ejemplo voy a usar un HOST ESXi físico que ya tengo instalado, y usaré uno virtual sobre mi portátil mediante VMware Player.
Lo primero que vamos a hacer es descargar la versión gratuita de Vmware Vsphere ESXI 5.5. Una vez tengamos la imagen ISO descargada, la grabamos a un cd y arrancamos el equipo para instalarlo. Si estás en un laboratorio con VirtualBox, deberás crear una máquina virtual desde cero, y añadirle la ISO al CD-ROM. Debéis configurar 2 CPU virtuales y 4Gb Ram para poder iniciar la instalación. Podéis seguir este manual, gracias al amigo de 1GB de Información.
El proceso de instalación de un HOST ESXi es tan sencillo como esto:
Ahora ya tenemos instalado el sistema operativo que hará de hypervisor tipo 1 ESXi. Recuerdo un día que le explique un poco el asunto a un amigo, y se cabreo cuando instalo el ESXi sobre su equipo físico para sus pruebas, y me dice: Kino esto que es, no puedo hacer nada. En efecto. Hemos instalado el sistema operativo, ahora debemos instalar un cliente, al cual nos conectaremos por red para trabajar con VmWare ESXi. Hablamos de un Kernel de unos 30 MB, no querrás que también tenga interface gráfico...
Accedemos a la URL y descargamos/ejecutamos el cliente.
Seguimos con la consola del ESXi y pulsamos F2 para acceder a las pocas tareas que podemos administrar localmente.
Básicamente vamos a configurar una dirección IP estática, para poder acceder desde el cliente VSphere que hemos instalado en nuestro equipo.
Como podéis leer en la advertencia, desde hace unos versiones hay opciones que no están disponibles mediante el cliente VSphere que hemos instalado, y solo se pueden acceder mediante la consola web de administración. De momento vamos a trabajar con el Client. ya que en la mayoría de sitios se hace referencia a este cliente, y no al WEBClient que de momento, deja bastante que desear.
Este es nuestro HOST ESXi listo para virtualizar.
Lo primero que vamos a hacer es configurar la sincronización con la hora mediante un servidor NTP. Es básico si no quieres tener problemas entre los HOSTS. Para ello, accedemos a Configuration, Time Configuration.
Repetimos esta operación con el segundo Hosts ESXi para tener dos equipos listos para realizar Fault Tolerance.
Ya tenemos preparado Out of a Box el ESXi. Antes de comenzar a instalar máquinas virtuales, vamos a trabajar con los conceptos que comentamos en el post de Almacenamiento y FreeNas para añadir un DataStore en red, que usaremos en ambos equipos ESXi para compartir almacenamiento.
Cuando instalamos un ESXi por defecto crea un vSwitch con dos tipos de puertos, VM y Kernel. Los primeros digamos que serían como bocas de un switch físico que sirven para comunicar las máquinas virtuales entre sí, y contra el mundo físico. Los puertos de tipo Kernel son unos puertos específicos para las tareas internas del equipo.
Para conectar un almacenamiento ISCSi externo por IP, debemos conectar un puerto tipo Kernel ( ya que realmente será el ESXi el que controle el almacenamiento, no las máquinas virtuales).
Entramos en properties del Vswitch0 y añadimos un puerto tipo Kernel, tal y como muestro:
Ahora tenemos a nivel de Networking, todo preparado para añadir un almacenamiento ISCSi. Ahora desde Configuration, Storage Adapters configuramos la "tarjeta" que conectará con el almacenamiento.
Ahora vinculamos el puerto tipo Kernel del Switch para que sea usado por el iniciador ISCSi. y configuramos la dirección del servidor FREENAS.
Bien. Hasta ahora, solo hemos configurado digamos "el cable" que conecta el equipo al almacenamiento. Como vimos en el anterior post, vamos a configurar un DATASTORE para que ESXi almacene sus máquinas virtuales en ese disco en red.
Hasta este punto, en Hyper-V sería tan sencillo como la segunda parte de este post. Configurar desde el panel de control el destino ISCS mediante una IP.
Este procedimiento lo debemos hacer en el segundo HOST ESXi que estamos configurando.
Ahora desde Configuration, Storage, añadimos un nuevo Datastore que use el disco.
Hasta aquí todo bien. Quizás no !!! Existe un Bug en la versión actual de FREENAS 9.1.1 por el que si usamos un disco para ISCSi y lo particionamos, no se puede volver a particionar. Esto es un bug de FREENAS. Si has usado la práctica anterior con FREENAS y has creado una partición NTFS para poder montar esta LUN en un Windows, cuando agregues este almacenamiento a ESXi e intente formatearlo como VMFS vas a tener un error. La solución es crear un Extend en Freenas con otro disco.
Si todo ha ido bien, tendrás dos DataStores disponibles en tu ESXi.
Hasta aquí, en un entorno Hyper-V solo tendríamos que ir al administrador de discos, y particionar el nuevo disco.
Ahora es el turno de realizar este último paso en el segundo HOST hasta el paso del DataStore. Es decir, una vez que conectemos el disco mediante ISCSi, en la sección de DataStores tendremos disponible el disco ya particionado.
Ahora tenemos dos equipos en cierta alta disponibilidad. Si el equipo que ejecuta la máquina virtual se detuviese, podríamos manualmente ir al segundo HOST, importar la máquina virtual al ESXi( solo la configuración, el disco duro virtual no ya que usamos almacenamiento compartido !!!) y arrancarla. Esto conlleva ventana de caída de servicio, mínimo el tiempo de enterarte e iniciar la máquina.
Para hacer uso de las tecnologías de alta disponibilidad automáticas, tolerancia a fallos ( cero downtime) y demás, debemos hacer uso de Vpshere. En sistemas Hyper-V usaríamos el complemento Virtual Machine Manager de System Center.
Vpshere es de pago, aunque podemos probarlo alegremente durante 60 días. Esta es la clave del licenciamiento en la virtualización. El fabricante te ofrece algo básico gratuitamente, y todos los featuring que queremos, los pagamos. Hay algo bueno, y es que Microsoft está ofreciendo todos los servicios relativos a virtualización y cloud en un producto, SYSTEM CENTER 2012 bastante asequible. Los amigos de OpenStack y KVM aquí darían un golpe en la mesa, argumentando que en esos sistemas no hay que pagar. En efecto, pero el coste de configurar Fault Tolerance entre dos host KVM puede que sea bastante superior que pagar la licencia en un sistema propietario y configurarlo en unos minutos... cada uno...
Creo que se ha extendido demasiado este artículo. En el próximo instalaremos Vsphere, el software que va a hacer posible todas las funciones extras para ESXi, y en concreto la "conexión" o "trabajo en grupo" de varios host ESXi.
Gracias por leerme.
Suscribirse a:
Entradas (Atom)