Examen VMware vSphere VCP410 - aprobado GARANTIZADO
Powered by MaxBlogPress 

Archivo | vSphere

Creando un administrador en vSphere vCenter Server

Creando un administrador en vSphere vCenter Server

El role “Administrator” es el role con mas privilegios en vCenter Server. Este role permiete al usuario ejecutar cualquier accion disponible en vCenter Server y por consiguiente deberías otorgar este role al menor número posible de usuarios.

Por defecto, el grupo local “Administrators” de Windows, es añadido al role “Administrator” del servidor de vCenter.

Para limitar el alcance de acceso, es una buena practica evitar el uso de la cuenta de usuario Administrator de Windows para ejecutar vCenter Server. En su lugar, asigna el role Administrator a una cuenta o grupo normal sin privilegios administrativos.

En este episodio te enseñare como crear en el servicor vCenter un usuario mas restringido – en cuanto a privilegios – para sustituir así el grupo “administrators” del role Administrator:

Posted in ESX, ESXi, VMware, Videos YouTube, vSphere0 Comentarios

¿Que me aporta Cisco Nexus 1000V si dispongo de vNetwork Distributed Switch?

¿Que me aporta Cisco Nexus 1000V si dispongo de vNetwork Distributed Switch?

La licencia Enterprise Plus de vSphere incluye un nuevo tipo de switch, el Distributed Switch que aporta mejoras en calidad de servicio, seguridad, escalabilidad y explotación respecto al clásico Standard Switch de siempre.

Sin embargo esta licencia permite, también, utilizar (comprándolo adicionalmente) el primer switch virtual de Cisco, el Cisco Nexus 1000V, pero ¿Que ventajas aporta este switch respecto al Distributed Switch para que merezca la pena pagar un dinero extra?.

Como todo en la vida, para algunos será necesario y para otros no, pero hablemos brevemente de algunas de las características que lo diferencian del vDS :

En VI3 v3.5 se incorporaba NetFlow en modo experimental (y funcionaba muy bien), pero en vSphere ha desaparecido, si queremos registrar los flujos de información que pasan por nuestros switches virtuales, fundamental para análisis de comportamiento de las aplicaciones y para detectar flujos sospechosos, hemos de utilizar Cisco Nexus1000V.

Si necesitas enviar los logs de los switches virtuales para correlacionarlos con los del resto de los switches físicos, Cisco Nexus 1000V te lo proporciona.

Cisco Nexus 1000V soporta ACLs utilizando direcciones MAC o IP y se aplican a nivel de puerto, dicho de forma rápida tenemos un firewall en cada puerto y se mueve con la VM al cambiar de ESX, es una buena ayuda en lo que a seguridad se refiere.

Otras medidas de seguridad son DHCP snooping y IP Source Guard que mitigan ataques man-in-the-middle o Dynamic ARP Inspection que nos protege de ataques ARP spoofing.

Además puede trabajar en combinación con VMware vShield Zones, blindando nuestra infraestructura y facilitando la administración de la seguridad con herramientas gráficas.

Nos aporta diversos mecanismos de QoS : Mecanismos de clasificación de tráfico por diversos criterios, técnicas de marcado de tráfico y políticas de QoS. Todo ello utilizando los comandos Cisco IOS y llegando a garantizar un ancho de banda a un tráficos determinado !!!!

Y los entusiastas de Cisco están de suerte, se configura mediante Cisco CLI y con los comandos que ya conoce y muchos mas.

Como vemos la seguridad, las redes y los sistemas, ya no son especialidades diferentes, están naciendo los especialistas en DataCenter … ¿te apuntas?

Posted in Estandars, Estrategia, Integración, VMware, reviews, vSphere5 Comentarios

Configurando Jumbo Frames en Máquinas Virtuales

Configurando Jumbo Frames en Máquinas Virtuales

La semana pasada te mostre como activar y configurar Jumbo Frames en un switch virtual.

En este otro episodio te mostrare a configurar Jumbo Frames en una máquina virtual Windows 2003 con el driver virtual vmxnet para una tarjeta a un Gigabit.

De esta forma tendrás Jumbo Frames configurado en todos los compoenens de tu entorno Virtual. No olvides de asegurarte que el switch físico en el que conectamos la tarjeta de red física de tu red iSCSI tiene también activado el soporte Jumbo Frames.

En caso de que tu switch físico no tenga soporte Jumbo Frames, es aconsejable no configurar Jumbo Frames en nuestro servidor VMware ni máquina virtual por razones obvias.

Posted in ESX, ESXi, Estrategia, Integración, VMware, vSphere2 Comentarios

VMware tips & tricks número 29: El Servicio de Web Access

VMware tips & tricks número 29: El Servicio de Web Access

Tanto en la versión anterior de VMware, VMware ESX 3.x, como en la ultima versión, VMware vSphere ESX 4.x, el servidor web Access está apagado por defecto.

El servidor vCenter y VMware vSphere ESX 4.x incluyen un servidor Web (Web Access) – en concreto es una versión “rebajada” de servidor web Apache Tomcat. Sin embargo, la versión thin del hypervisor de VMware, VMware ESXi, no incluye esta funcionalidad.

Si recibes el error “503 Service Unavailable” cuando intentas conectarte al servidor Web, tanto del servidor vCenter como del servidor VMware ESX, es porque el servicio Web Access no está arrancado (por defecto).

Web Access Error

Tip: Para arrancar el servicio Web Access en el servidor VMware vSphere ESX 4.x, bájate al Service Console y ejecuta el siguiente comando: service vmware-webAccess start.

Para arrancar el servicio Web Access en el servidor de vCenter, arranca el servicio correspondiente en la pestaña services de tu servidor Windows.

Posted in ESX, Trucos, VMware, vSphere0 Comentarios

Nuevos videos de Formación VMware vSphere online

Nuevos videos de Formación VMware vSphere online

Es un placer para mi presentaros mis nuevos videos de formación VMware vSphere online sobre la tecnología de Virtualización con VMware vSphere. Después de recibir “toneladas” de emails con feedback de muchos de mis lectores pidiéndome que creara mas videos tutoriales sobre VMware vSphere, no me ha quedado mas remedio que hacerles caso.

En la actualidad ya tengo “liberados” online y gratuitamente, más de 10 episodios sobre la tecnología de virtualización de VMware vSphere.

Para ver los videos tutoriales de VMware vSphere, puedes acceder a la página general donde están todos los videos disponibles haciendo clic en el menú Videos Tutoriales y seleccionando “Videos vSphere“. También puedes acceder a los videos tutoriales de VMware vSphere haciendo clic en este enlace directo.

http://www.josemariagonzalez.es/video-tutoriales/videos-formacion-vsphere

Como me pediste en tu feedback, cada Lunes liberaré un episodio que tratara sobre un tema en concreto en VMware vSphere. Espero que durante los próximos meses te diviertas viendo y siguiendo este curso de formación VMware vSphere online de la misma forma que yo me estoy divirtiendo creándolo para ti.

Estos son algunos de los videos tutoriales de VMware vSphere que ya están a disposición del público en general y que ya han visto más de 2.300 usuarios hasta la fecha.

Episodio #1: Como configurar Cisco Discovery Protocol en vSphere.

Episodio #2: Cisco Nexus 1000v Virtual Switch y Cisco Discovery Protocol.

Episodio #3: Configurando el Firewall del Service Console en vSphere.

Episodio #4: Calculando el tamaño de la base de datos en vSphere.

Episodio #5: Integrando VMware vSphere ESX 4.0 con Microsoft AD.

Episodio #6: Desmontando un DataStore NFS en vSphere 4.0.

Episodio #7: Creando un Host Profle en VMware vsphere 4.0.

Episodio #8: Creciendo un Datastore VMFS online.

Episodio #9: Configurando VMware vSphere ESXi directamente desde la consola.

Episodio #10: El backup de la configuración de VMware ESXi.

Episodio #11: Cambiando la configuración de la memoria del Service Console en VMware vSphere.

Episodio #12: Configurando Jumbo Frames en VMware vSphere.

Posted in Publicaciones, Trucos, Videos YouTube, josemariagonzalez.es, vSphere6 Comentarios

Configurando Jumbo Frames en VMware vSphere

Configurando Jumbo Frames en VMware vSphere

Por defecto, Jumbo Frames esta desactivado en VMware vSphere. La otra mala noticia es que tienes que “bajarte” de nivel (al Service Console) para poder activar Jumbo Frames en VMware vSphere.

Si recuerdas, hace una par de semanas, te mostré como activar Jumbo Frames en los nuevos vswtiches distribuidos en VMware vSphere. Para los vswitch distribuidos – solo incluidos en la versión Enterprise Plus de VMware vSphere -, activar Jumbo Frames es una tarea de un solo clic ya que existe la opción de activar Jumbo Frames desde la GUI – vCenter Client.

Desafortunadamente o afortunadamente, si te gusta bajarte de nivel y “trastear” en el Service Console, tendrás que saber cuál es el comando para activar Jumbo Frames en tu entorno VMware vSphere.

En este video te mostrare como activar la opción de Jumbo Frames en un vswitch virtual estandar:

Posted in ESX, ESXi, VMware, Videos YouTube, vSphere5 Comentarios

iSCSI multipathing con la consola ESXCLI

iSCSI multipathing con la consola ESXCLI

Hola de nuevo, soy Miguel Angel Alonso y aquí estoy afortunadamente una vez más con vosotros para mostraros un nuevo artículo que espero que os guste y os pueda ayudar en vuestras inquietudes diarias de nuestro mundo de la virtualización.

Hoy le ha tocado el turno a cómo crear Multipathing desde la consola ESXCLI.

En el artículo de Chad Sakac y otros como(Netapp, EMC, Dell, HP, VMware) podremos tener acceso al nuevo método de Multipathing iSCSI para la nueva versión de ESX(vSphere).

Por fin en esta versión el iniciador ISCSI estará habilitado para múltiples conexiones  ISCSI. (Multipathing mediante múltiples conexiones TCP)Panel Configuracion vSwitch

Estoy encantado realmente con dicha función y lo fácil de configurarala que es. Necesitarás varias pautas a seguir para su correcto funcionamiento. Necesitaremos asignar 2 NICs a un VMkernel (o más) y sólo una NIC áctiva. Las demás NICs las moveremos hacia abajo (DOWN) en la sección “Unused Adapters”.

Después de haber creado tus VMkernels y unirlos (Bound) a una NIC específica, necesitarás añadirlos a tu Software iniciador ISCSI:

  1. esxcli swiscsi nic add -n vmk0 -d vmhba35
  2. esxcli swiscsi nic add -n vmk1 -d vmhba35
  3. esxcli swiscsi nic list -d vmhba35

Si chequeas tu cliente vSphere te darás cuenta que habremos conseguido 2 PATHS en tu ISCSI Target, aquí os dejo un ejemplo:

iSCSI target 300x164 iSCSI multipathing con la consola ESXCLI

Y en el ESXTOP, puedes ver los 2 VMKernel Ports con su tráfico:

VMware ESXTOP

Esta es una de las muchas cosas que se pueden conseguir mediante la consola de comandos ESXCLI.

Por supuesto en el Screenshot de arriba podemos ver que nuestra opción de Multipathing está en FIXED, pero como ya sabemos podremos elegir también entre MOST RECENT USED (MRU) o ROUND ROBIN (RR).

Bueno por fin un artículo un poquito más corto de lo que es habitual en mí pero creo que no por ello menos interesante. Aprovecho de nuevo para saludaros y daros siempre las gracias por estar ahí y como no, una y cuantas veces hagan falta a Jose María Gonzalez y todos mis compañeros del Blog que son increíbles.

Hasta la próxima semana.

Posted in ESX, ESXi, VMware, vSphere9 Comentarios

Exportando los logs del sistema en VMware vSphere

Exportando los logs del sistema en VMware vSphere

Exportar los logs del sistema de una plataforma vSphere es una tarea de dos minutos. El motivo fundamental por la que tienes que exportar los logs del sistema es para reportar un error en tu entorno.

Este es uno de los pasos necesarios previos al abrir un “ticket” de soporte con VMware.

En este video te mostrare como generar el fichero log usando la utilidad del Service Console vm-support. Esta es otra de las opciones para generar los ficheros log del servidor ESX y es la única forma de poder generar dichos ficheros en caso de que nuestro servidor vCenter y vCenter Client no estén disponibles:

Posted in ESX, VMware, vSphere0 Comentarios

VMware tips & tricks número 27: Resource Pools heredados

VMware tips & tricks número 27: Resource Pools heredados

Es posible definir resource pools a nivel de servidor VMware ESX/ESXi o a nivel de clúster VMware DRS. Sin embargo, si a la hora de crear un clúster no seleccionas la opción Enable VMware DRS, la opción de New Resource Pool estará deshabilitada.

Para poder crear un New Resource Pool en un Clúster VMware DRS, asegúrate de habilitar la opción Enable VMware DRS durante la creación de tu clúster VMware o, en su defecto, puedes habilitar dicha opción después de la creación del clúster, seleccionando el clúster con el botón derecho del ratón y seleccionando Edit Settings. Después, haz clic en Enable VMware DRS.

Los resource pools creados a nivel VMware ESX/ESXi pueden ser heredados ( grafted ) e incluidos en un clúster vSphere VMware DRS, cuando incluyes un servidor ESX/ESXi con resource pools ya creados a nivel de host, a un clúster VMware DRS.

Sin embargo, la opción por defecto cuando añades un servidor ESX/ESXi a un cluster DRS es “Put all of this host´s virtual machines in the cluster´s root resource pool. Resource pools currently present on the host will be deleted”.

Para heredar los resources de tu servidor host ESX/ESXi a tu clúster DRS, asegúrate de seleccionar “Create a new resource pool for this host’s virtual machines and resource pools. This preserves the host’s current resource pool hierarchy”.

Los resource pools heredaros serán nombrados Grafted from + nombre del servidor VMware ESX/ESXi. Si posteriormente eliminas el servidor host ESX/ESXi de tu cluster DRS, los resource pools serán “retenidos”.

No obstante, si decides desactivar la opción DRS de tu cluster, perderás todos los resource pools de dicho cluster, previo aviso eso si, y tendrias que re-crearlos de nuevo.

Esto ha sido todo, hasta la próxima semana con un nuevo tip.

Posted in ESX, ESXi, Trucos, VMware, vSphere0 Comentarios

VCDX: VMware Design Exam, el más difícil todavía – mi feedback

VCDX: VMware Design Exam, el más difícil todavía – mi feedback

Después de 11 años haciendo exámenes de certificación en VMWare y más de 19 años en la industria de IT, hoy puedo confirmar con total rotundidez, que este es el examen más difícil que jamás he hecho.

Es tan difícil que, los 11 años de experiencia con productos VMware, cientos de proyectos de virtualización a mis espaldas – algunos de los proyectos en los que estuve involucrado hasta la “ceja” son dos de las granjas de VMWare mas grandes en EMEA ( Dell y BP ) , y todos los cursos oficiales de VMware Fast Track y VMware ICM que imparto y los ciento de estudiantes que formo mensualmente, no han sido suficientes para superar el examen.

Ciertamente estuve muy cerca, con un scoring de 268 – necesitas mínimo un score de 300 – de aprobar el examen pero el cansancio – mas de 2 horas y media de examen – y el que el día anterior no pude dormir mas que dos horas – el avión que me trajo desde Dublín a Madrid salió con mas de 5 horas de retraso -, hicieron mella en las mas que ya agotadas baterías humanas, aparte de que este examen no lo ha aprobado mucha gente.

Este es el primer examen oficial de VMware que suspendo, ciertamente me alegra saber que ha sido con el VMware Desing Exam VCP310 para conseguir la certificación VCDX.

El examen, en tres palabras: no me gusto. La primera parte, tuve que responder a 51 preguntas – algunas muy largas y con conceptos enrevesados y envenenados – y en otras el enunciado estaba mal – se nota que este examen esta aun en beta!.

En algunas de las preguntas tipo drag & drop, las respuestas podían ser arrastradas en múltiples casillas – según el enunciado – pero cuando arrastrabas un mismo icono dos veces en diferentes casillas no funcionaba, está seguro que la falle – como esperan que uno acierte semejante sinvergonzonería?

Con la segunda parte del examen, la cual es dibujar un diseño – nada del otro mundo -, tuve mas problemas intentando averiguar como funcionaba la GUI que con el diseño propio.

Moraleja, no me extraña que solo 20 personas en el mundo tenga esta certificación y que, según mis últimas informaciones, todos menos uno trabajan para VMWare. Creo que sería necesario saber las mejores prácticas internas de VMware si quieres tener, al menos, una remota posibilidad de aprobar este examen. Yo lo volveré a intentar próximamente……

Posted in ESX, ESXi, VMware, josemariagonzalez.es, vSphere10 Comentarios

Como crear un Cluster SAN con Openfiler – Parte II

Como crear un Cluster SAN con Openfiler – Parte II

En la primera parte, te explique brevemente como instalar y montar el motor DRDB.

En esta segunda parte, te explicare como configurar el Hearbeat y a finalizar la instalación y configuración de OpenFiler en una configuración en Cluster de alta disponibilidad.

Heartbeat

Para configurar heartbeat nos hará falta crear dos ficheros, authkeys y ha.cf. En authkeys definimos el método de autenticación entre nodos del cluster. Podéis poner sencillamente esto:

auth 2
2 crc

Lo copiáis al nodo 2 y atención, aseguraos que los permisos sobre este fichero en ambos nodos es 600, ya que de lo contrario heartbeat no arrancará. Ahora el ha.cf:

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
udpport 694
bcast eth0
keepalive 5
warntime 10
deadtime 120
initdead 120
auto_failback off
node batman
node robin

Importante: Aseguraos que la eth sobre la que vais a comprobar el heartbeat es la correcta (en mi caso solo tengo una eth en cada servidor así que no hay mucha probabilidad de error). Ah y cambiad los nombre de los nodos (lineas “node”) con el nombre de vuestros nodos. Cuando acabéis, copiadlo al nodo 2 y añadid heartbeat al inicio del sistema.

chkconfig –level 2345 heartbeat on

Ahora es cuando tenemos que empezar a mover ficheros de configuración a la partición que hemos creado para el cluster y linkarlos, de manera que cuando hagamos el failover el nodo secundario monte dicha partición (que está replicada con drbd) y pueda arrancar los servicios correctamente:

En nuestro nodo primario:
• mkdir /cluster_metadata
• mount /dev/drbd0 /cluster_metadata
• mv /opt/openfiler/ /opt/openfiler.local
• mkdir /cluster_metadata/opt
• cp -a /opt/openfiler.local /cluster_metadata/opt/openfiler
• ln -s /cluster_metadata/opt/openfiler /opt/openfiler
• rm /cluster_metadata/opt/openfiler/sbin/openfiler
• ln -s /usr/sbin/httpd /cluster_metadata/opt/openfiler/sbin/openfiler
• rm /cluster_metadata/opt/openfiler/etc/rsync.xml
• ln -s /opt/openfiler.local/etc/rsync.xml /cluster_metadata/opt/openfiler/etc/
• mkdir -p /cluster_metadata/etc/httpd/conf.d

y editamos el fichero /opt/openfiler.local/etc/rsync.xml para que parezca algo así:

<?xml version=”1.0″ ?>
<rsync>
<remote hostname=”10.188.188.2″/> ## IP address of peer node.
<item path=”/etc/ha.d/haresources”/>
<item path=”/etc/ha.d/ha.cf”/>
<item path=”/etc/ldap.conf”/>
<item path=”/etc/openldap/ldap.conf”/>
<item path=”/etc/ldap.secret”/>
<item path=”/etc/nsswitch.conf”/>
<item path=”/etc/krb5.conf”/>
</rsync>

Tened en cuenta en “hostname” poner la IP del nodo 2. En el nodo 2 nos basta con:
• mkdir /cluster_metadata
• mv /opt/openfiler/ /opt/openfiler.local
• ln -s /cluster_metadata/opt/openfiler /opt/openfiler

El link simbolico está “roto”, pero se arregla al hacer el failover, ya que se montará la partición en el directorio /cluster_metadata. Hacemos lo mismo con el fichero /opt/openfiler.local/etc/rsync.xml, pero en el nodo 2 tenemos que poner la IP del nodo 1.

Ahora la configuración del heartbeat que trae openfiler. Esto sólo hay que hacerlo en el nodo 1. Editamos /cluster_metadata/opt/openfiler/etc/cluster.xml y lo dejamos tal que así:

<?xml version=”1.0″ ?>

<cluster>

<clustering state=”on” />

<nodename value=”batman” />

<resource value=”MailTo::it@company.com::ClusterFailover”/>

<resource value=”IPaddr::192.168.1.10/24″ />

<resource value=”drbddisk::”>

<resource value=”LVM::vg0drbd”>

<resource value=”Filesystem::/dev/drbd0::/cluster_metadata::ext3::defaults,noatime”>

<resource value=”MakeMounts”/>

</cluster>

Con esto lo que hacemos es definir a Batman (nodo 1) como el nodo primario. A su vez le decimos que añada un recurso al cluster como una IP virtual (la ip del cluster) y que monte la partición de los ficheros de configuración del cluster.

Ahora, hay que hacer lo mismo que con los ficheros de configuración del openfiler, pero con los de los diferentes servicios. Por partes.

iSCSI

- en el nodo 1:
• mv /etc/ietd.conf /cluster_metadata/etc/
• ln -s /cluster_metadata/etc/ietd.conf /etc/ietd.conf
• mv /etc/initiators.allow /cluster_metadata/etc/
• ln -s /cluster_metadata/etc/initiators.allow /etc/initiators.allow
• mv /etc/initiators.deny /cluster_metadata/etc/
• ln -s /cluster_metadata/etc/initiators.deny /etc/initiators.deny

- en el nodo 2:
• rm /etc/ietd.conf
• ln -s /cluster_metadata/etc/ietd.conf /etc/ietd.conf
• rm /etc/initiators.allow
• ln -s /cluster_metadata/etc/initiators.allow /etc/initiators.allow
• rm /etc/initiators.deny
• ln -s /cluster_metadata/etc/initiators.deny /etc/initiators.deny

FTP

- En el nodo 1:
• mv /etc/proftpd /cluster_metadata/etc/
• ln -s /cluster_metadata/etc/proftpd/ /etc/proftpd

- En el nodo 2:
• rm -rf /etc/proftpd
• ln -s /cluster_metadata/etc/proftpd/ /etc/proftpd

SAMBA Y NFS.

Aquí tuve un pequeño problemita con el tuto de how to forge. Esto es lo que dice:

Nodo 1;
• mkdir /cluster_metadata/etc
• mv /etc/samba/ /cluster_metadata/etc/
• ln -s /cluster_metadata/etc/samba/ /etc/samba
• mkdir -p /cluster_metadata/var/spool
• mv /var/spool/samba/ /cluster_metadata/var/spool/
• ln -s /cluster_metadata/var/spool/samba/ /var/spool/samba
• mkdir -p /cluster_metadata/var/lib
• mv /var/lib/nfs/ /cluster_metadata/var/lib/
• ln -s /cluster_metadata/var/lib/nfs/ /var/lib/nfs
• mv /etc/exports /cluster_metadata/etc/
• ln -s /cluster_metadata/etc/exports /etc/exports

Aunque esto, me dio error en el paso “mv /var/lib/nfs/ /cluster_metadata/var/lib/”. El caso es que hay un demonio por ahí que tiene algo que ver con rpc que bloquea el directorio. Para solucionarlo hice esto:

Reemplazar todas las ocurrencias de /var/lib/nfs/rpc_pipefs por /var/lib/rpc_pipefs en los ficheros /etc/modprobe.conf.dist y /etc/idmapd.conf. Lo podeis hacer a manija o con este mini-script en perl:

perl -i.orig -pe ‘
if (m,^[^#], and m,/var/lib/nfs/rpc_pipefs,)
{print “#”, $_; s,,/var/lib/rpc_pipefs,;}
‘ \
/etc/modprobe.conf.dist \
/etc/idmapd.conf
service nfslock stop
service nfs stop
service rpcidmapd stop
/bin/umount -a -t rpc_pipefs
mv /var/lib/nfs/rpc_pipefs /var/lib/
/bin/mount -t rpc_pipefs sunrpc /var/lib/rpc_pipefs
service rpcidmapd start

Con esto movéis el directorio rpc_pipefs fuera de la carpeta /var/lib/nfs asi que os dejara moverla. Luego, podéis deshacer el proceso (cambiad las expresiones en el script) para que los locks de nfs se guarden en la partición compartida de configuración del cluster, de manera que cuando se haga el failover, se conserven.

Nodo 2:
• rm -rf /etc/samba/
• ln -s /cluster_metadata/etc/samba/ /etc/samba
• rm -rf /var/spool/samba/
• ln -s /cluster_metadata/var/spool/samba/ /var/spool/samba
• rm -rf /var/lib/nfs/
• ln -s /cluster_metadata/var/lib/nfs/ /var/lib/nfs
• rm -rf /etc/exports
• ln -s /cluster_metadata/etc/exports /etc/exports

Hecho esto, creamos el primer volume group en el nodo 1:
• vgcreate vg0drbd /dev/drbd1
• lvcreate -L 400M -n lv001 vg0drbd

Tened siempre como mínimo un volume group con un logical volumen dentro porque si no el heartbeat no arrancara. Luego lo podréis borrar con la interfaz de openfiler y hacerlo al gusto, pero este es para que no de error al arrancar.

Luego en el nodo 1:
• rm /opt/openfiler/etc/httpd/modules
• ln -s /usr/lib64/httpd/modules /opt/openfiler/etc/httpd/modules
(si tenéis la arquitectura x86, como yo, le quitáis el “64” al “lib64” y listo)

Ahora reiniciamos openfiler,

service openfiler restart

Y tendremos que activar o desactivar algún servicio mediante la interfaz para que escriba el fichero /etc/ha.d/haresources. Cuando lo tengamos, lo copiamos al nodo 2.

Y ahora solo queda aplicar el 2º axioma de la informática, reiniciar. Reiniciamos los dos nodos, y al arrancar deberíamos tener el cluster activo. Ahora podéis entrar a la interfaz de administración a través de la IP del cluster (la que hayáis definido previamente) y probar.

Si tenéis algún problema, mirad en los ficheros de log del heartbeat (/var/log/ha-log y /var/log/ha-debug) de los dos nodos, y probad a parar y arrancar el openfiler en los dos nodos, para ver que errores genera.

Ahora podemos exportar con iSCSI, de manera que con los ESXi podemos adjuntar el storage en dos o más servidores. Esto nos sirve para que si uno de los dos “muere”, podamos arrancar la máquina virtual directamente en el otro, tal y como estaba cuando se paró.

Bueno aquí os dejo este Post esta semana y espero poder volver a estar con vosotros la próxima semana para contaros algo nuevo siempre y cuando desde mi humilde opinión.

Un saludo

Posted in Publicaciones, Software, reviews, vSphere10 Comentarios

Cambiando la configuración de la memoria del Service Console en VMware vSphere

Cambiando la configuración de la memoria del Service Console en VMware vSphere

En un servidor VMware vSphere ESX 4, si así lo estimas necesario, puedes cambiar el tamaño de la memoria destinada al Service Console.

Este cambio necesita un reinicio del servidor vSphere ESX 4 para que los cambios surjan efecto.

El cambio del tamaño de la memoria del Service Console afectara al fichero swap del Service Console. VMware recomienda asignar el doble del tamaño de la configuración de memoria del Servico Console para su partición swap.

El tamaño máximo del Service Console es de 800MB, por consiguiente la partición máxima para el swap del Service Console no pueden ser mayor de 1.600MB.

En este vídeo te enseñare como cambiar la configuración de memoria del Service Console y porque a veces es necesario hacer dicho cambio:

Posted in ESX, VMware, Videos YouTube, vSphere0 Comentarios

VMware tips & tricks número 26: Algunos requerimientos de VMware VMotion

VMware tips & tricks número 26: Algunos requerimientos de VMware VMotion

El wizard de la migración en caliente, VMware VMotion, valida los requerimientos del servidor origen y servidor destino así como los requerimientos de la maquina virtual que quieres migrar.

Una máquina virtual no puede ser migrada en caliente cuando:

  • La MV tiene una conexión activa a un virtual switch de uso interno.
  • La MV tiene una conexión activa a un CD o disquete.
  • La MV tiene configurada una afinidad a una CPU.
  • La MV forma parte de un clúster Microsoft.

El wizard de migración en caliente, VMware VMotion, produce un warning cuando:

  • La MV tiene una conexión a un virtual switch de uso interno pero no está conectado.
  • La MV tiene una conexión a un CD o disquete pero no está conectado.
  • La MV tiene uno o más snapshots.
  • El servidor VMware vSphere ESX/ESXi no ha recibido un guest OS heartbeat (probablemente las VMware tools no han sido instaladas o configuradas adecuadamente).

El wizard de migración en caliente, VMware VMotion, muestra un mensaje de error si la máquina virtual no puede ser migrada desde el servidor origen al servidor destino. Sin embargo, con un mensaje de error de tipo warning, la máquina virtual puede ser migrada con VMotion sin problemas.

Asimismo, los servidores involucrados en la migración, servidor origen y servidor destino, deben cumplir los siguientes requerimientos:

  • Visibilidad de todas las LUNs (FC, iSCSI, NAS) usadas por la MV.
  • Una red Gigabyte Ethernet dedicada al tráfico VMotion. (En una red 10/100 también funciona pero va muchoooo mas lento. No ostante, VMware solo soporta una red Gigabyte para el trafico VMotion.
  • Acceso a la misma red Ethernet física.
  • El nombre de los virtual switch debe ser igual en ambos Servidores ESX (incluyendo mayúsculas y minúsculas). En VMware vSphere ESX/ESXi versión 4 update1, si los virtual switches no son nombrados iguales, el wizard de migración en caliente VMotion produce un warning pero la migración puede continuar.
  • CPUs compatibles o similares (misma familia CPU). VMotion también funciona, si el servidor origen tiene Hyperthreading activado pero no el servidor destino

Seguro que se me escapan algunos requerimientos de VMotion, con lo que si no ves aquí todos, o crees que falta alguno, por favor déjame tu comentario.

Posted in ESX, ESXi, Hardware, Trucos, VMware, vSphere2 Comentarios

Como crear un Cluster SAN con Openfiler – Parte I

Como crear un Cluster SAN con Openfiler – Parte I

¿Hola que tal de nuevo?. Pido mis disculpas a José María y todos nuestros lectores por el retraso en mis POSTS ya que he tenido un ligero contratiempo a lo largo de este mes que me ha hecho ir más lento con vosotros de lo que yo quisiera.

Una vez explicado esto, quería haceros llegar algo que ya he probado y que me ha sorprendido por su funcionamiento con un programa de almacenamiento SAN como es Openfiler (Código Abierto). Como realizar un Cluster entre SAN con Openfiler para la redundancia de nuestras VMs?.

Mirando en varios Blogs y otros donde ponían como realizarlo (HOW to) os transmito paso a paso como realizarlo. Aunque cabe reseñar antes de empezar, que todo se basa en el protocolo DRDB, el cual es básicamente una replicación continua vía TCP/IP mediante nuestra red Ethernet.

Lo primero es descargar e instalar openfiler en las dos máquinas. Hay una imagen para x86 o para x86_64 según las máquinas de que dispongáis. Durante la instalación, haced las particiones idénticas en los dos servidores, y cuando reiniciéis, os tendréis que asegurar que no se montan las particiones que se van a replicar entre los dos servidores. En mi caso, hice el siguiente particionado:

• /dev/hda1 — /boot – 150MB
• /dev/hda2 — / — 10GB
• /dev/hda3 – swap – 1024MB
• /dev/hda5 – 512MB – Será donde guardemos los ficheros de config para el cluster.
• /dev/hda6 – 12,9 GB – Haremos un share SMB
• /dev/hda7 – 12,9 GB – La usaremos como target iSCSI para VMWare

Para que nos quede un poco mas claro, las particiones que replicaremos serán las de datos y la de configuración del cluster. Las de sistema no será necesario replicarlas ya que el sistema está instalado en ambos nodos. Aseguraos también de que los dos nodos resuelven correctamente el nombre del otro y opcionalmente, montad la autentificación por claves de ssh, para no tener que escribir el password cada vez que hagáis un scp.

DRBD

Montar drbd es bastante sencillo. Lo primero que tenéis que hacer es aseguraros de que las particiones estén vacías, ya que es muy probable que durante la instalación hayáis creado un sistema de ficheros sobre ellas. Si fuese así:

dd if=/dev/zero of=/dev/hdaX bs=1M count=1

Con esto borráis las particiones y las dejáis impolutas para que podáis empezar a replicar. Lo siguiente, editamos el fichero /etc/drbd.conf en el nodo 1. Ahí tendremos que especificar un par de opciones generales y los arrays que váis a crear:

Ejemplo del fichero de configuración.

Luego lo copiamos al nodo 2. Una vez tenemos el fichero de configuración podemos crear los arrays (esto hay que hacerlo en ambos nodos):

• drbdadm create-md cluster_metadata
• drbdadm create-md vg0drbd
• drbdadm create-md vg1drbd

Y arrancamos el servicio drbd en los dos nodos. Si miráis el fichero /proc/drbd, veréis que el estado de los discos es inconsistente y que ambos nodos estan como secundarios. Así que en el nodo 1 hacéis:

• drbdsetup /dev/drbd0 primary -o
• drbdsetup /dev/drbd1 primary -o
• drbdsetup /dev/drbd2 primary –o

Con esto hemos puesto al nodo 1 como primario en todas las particiones que gestiona drbd. Ahora si miráis el /proc/drbd, veréis como está replicando los datos. Ahora hay que añadir drbd al inicio del sistema y ya de paso, creamos el sistema de ficheros en la partición que nos guardará los ficheros de configuración del cluster.

• chkconfig –level 2345 drbd on (en ambos nodos)
• mkfs.ext3 /dev/drbd0 (en el nodo 1)

En este punto, con los arrays creados, nos referiremos siempre al los dispositivos drbd para I/O para cualquier operación con discos.
Siguiente, editamos el fichero /etc/lvm/lvm.conf y cambiamos el filtro de esto:

• filter = [ "a/.*/" ]

a esto:

• filter = [ "r|/dev/hda*|" ]

y procedemos a crear el physical volume sobre drbd1 (el otro sera sobre drbd2, ya que el 0 no será gestionado por lvm).

• pvcreate /dev/drbd1

En la siguiente parte, te contare la parte del heartbeat y de como terminar la configuración de drdb.

Hasta la próxima semana.

Posted in ESX, ESXi, Estrategia, Publicaciones, Software, VMware, vSphere10 Comentarios

Soluciones de gestión P2V & V2V para Hyper-V y VMware

Soluciones de gestión P2V & V2V para Hyper-V y VMware

Irene Kalmykova, Sales Director de 5nine.com, se ha puesto en contacto con el blog de virtualizacion en Español para dar a conocer sus últimos productos P2V & V2V para Hyper-V y VMware vSphere.

5nine P2V Planner, crea migraciones P2V automatizadas y personalizadas para Microsoft Hyper-V y VMware vSphere. Este software P2V no solo realiza la conversión de físico a virtual con un gran porcentaje de éxito sino que además te proporciona una comparación tipo TCO/ROI sobre cuál es la solución mas adecuada, VMware vSphere o Microsoft Hyper-V.

Estoy deseando probar esta nueva funcionalidad en mis conversiones de físico a virtual.

Otra de sus soluciones, 5nine Virtual firewall para Hyper-V, monitoriza y controla el tráfico entre máquinas virtuales de Microsoft Hyper-V y la red externa (y viceversa).

La buena noticia es que la versión actual es gratuita y está disponible para su descarga en su web.

La mala noticia es que la próxima versión, que será lanzada a fines de enero, será un producto de pago, con lo que yo que tú me daría prisa en bajarme la versión gratuita para poder jugar con ella.

Posted in Estrategia, Hyper-V, Integración, Microsoft, Software, VMware, vSphere0 Comentarios

Page 1 of 6123456

Sigue el blog Virtualización en Español

Blog Sponsors

101 Secretos de VMware vSphere

Descubre todos los secretos de VMware vSphere 4 y aprueba el examen de certificación oficial VMware VCP-410 GARANTIZADO. Regístrate y recibe un capitulo del libro totalmente gratuito

 

Consigue una copia gratis de mi eBook



VMware Site Recovery Manager 1.1 download gratis 

Nombre:
Email:


Mi Empresa

Servicios de Consultoria autorizados de Virtualizacion

 

Anuncios

Info

 

Jose Maria Gonzalez en Linked

 

Subcríbete al blog

Introduce tu email::

Delivered by FeedBurner

 

Soporta el Blog

Soporta el Blog

 

Sígueme en Twitter

Sígueme en twitter