Servicios Virtualización y Cloud Computing

Sobre el autor

Jose Maria Gonzalez

Es CEO y fundador de JMG Virtual Consulting, S.L., una consultora IT especializada en soluciones de virtualización de sistemas & cloud computing y formación oficial VMware vSphere, OpenStack y Docker.

Artículos Relativos

25 Comentarios

  1. 1

    Santi Fernández

    Respecto al tema de la latencia de acceso a disco, simplemente añadir un pequeño apunte fruto de la experiencia personal.

    En el caso de los HP ProLiant que cuenten con una tarjeta SmartArray P410/P410i, es imperativo el uso del componente de caché interno de la controladora. Este componente lo señalan como “opcional”, pero os puedo asegurar que de opcional tiene bastante poco, estamos hablando de una mejora de rendimiento de como mínimo el 300% hasta un 1000%, medidos y comprobados con IOMeter.

    En mi caso, las estadísticas de las que habla Jose María en este post fueron las que me dieron la pista de los problemas de acceso a disco y las que me llevaron a más investigaciones.

    Para más información podeis acudir a las notas de referencia del producto: http://www.vmware.com/support/vsphere4/doc/vsp_esxi40_u2_rel_notes.html

    Responder
    1. 1.1

      Jose Maria Gonzalez

      Hola Santi,

      Gracias por tu comentario. Esta muy claro Santi, si no tienes la cache activa en tu cabina el rendimiento es notoriamente inferior.

      rgds,
      J.

      Responder
  2. 2

    Aurelio Llorente

    Se te oye muy bajito en los vídeos. Hay que subir mucho el volumen para entenderte y al terminar, la musiquilla te pega el susto padre.

    Responder
  3. 3

    José Luis Gömez

    Hola José María,

    Gracias por los aportes que haces en tu blog que siempre resultan de gran interés y de mucha ayuda. Nada más leer éste artículo me he dirigido a comprobar los valores en un entorno ESX 3.5 que disponemos en producción y comprobar dichos valores. A nivel de latencia kernel los valores se adaptan a los que comentas, sin embargo al nivel físico se puede comprobar picos máximos que llegan a superar los 100ms, de todos modos la media total de las LUN’s disponibles se encuentran entre 20 y 30 ms.

    ¿Qué opinas respecto esos valores?

    Algo que si me gustaría comentarte es una cierta “lentitud” que comprobamos en nuestro servidor DFS de Microsoft, no sé si es que no está capacitado dicho servicio para ser virtualizado o es que la configuración usando vmdk en vez de rdm pudiera ser el problema. Lo que ocurre que disponemos de 4 servidores DFS en diferentes ubicaciones, el principal es el virtualizado y el resto físicos. Pues en este virtualizado su memoria RAM siempre está al máximo, consumida por el servicio dfsr.exe, el cual se encarga de la replicación, pero resulta que el resto de servidores DFS tienen la misma programación pero están como tu dices TONTOS, tienen bastantes recursos de sobra…. ¿qué opinas?

    Saludos y enhorabuena.

    P.D. Tal vez nos crucemos en Julio, ya que vamos a Madrid a realizar la formación VCP en Magirus.

    Responder
    1. 3.1

      Jose Maria Gonzalez

      Hola Jose Luis,

      Los picos que comentas, no los tendría muy en cuenta, aunque los vigilaría de cerca.

      Con respecto a RDM .vs VMFS, pufff!!! vaya pregunta: Resumiendo. No elijas RDM .vs VMFS por rendimiento pues no lo “hay” – solo en contadas situaciones.

      Con respecto al curso, sera un placer tenerte. Por cierto, si no recuerdo mal es un troubleshooting? Prepárate!!! ;)

      rgds,
      J.

      Responder
      1. 3.1.1

        José Luis Gómez

        Hola José María,

        Gracias por la información, es que haciendo el VTSP hablaba que en RDM o VMDirectPath I/O se conseguía aumentar la velocidad en los accesos al almacenamiento. Es que resulta muy curioso que nuestro servidor DFS realiza una instantánea para poder utilizar la recuperación en versiones anteriores y se queda “FRITO” el acceso al resto de recursos compartido durante el tiempo que dura la creación de la instantánea… Entonces nos tiene un poco mosca y estamos pensando pasar el DFS a físico… teniendo en cuenta que disponemos de ESX 3.5 no sé si en 4.0 mejoraría el rendimiento.

        Respeco al troubleshooting espero que nos exprimas al máximo, y placer para nosotros poder compartir 101010111000 contigo… pero eso si, luego has de recomendarnos algún sitio donde despejarnos un poco :)

        Saludos.

        Responder
  4. 4

    Oscar Ocampo

    Hola jose maria muchas gracias de antemano por tus videos.

    Respecto a querer medir la latencia de los discos en mi Vmware ESXI y seguir los pasos desde mi VMware vSphere Client no pude encontrar la opcion de advanced en la pestaña de performance.

    Podrías explicarme como hacerlo o si no lo puedo hacer por mi version free.

    Gracias

    Responder
  5. 5

    Angel

    Un artículo muy interesante José María.

    Me hubiera sido muy util para detectar un problema que tuvimos con una cabina de discos. Lo comento por si a alguien le ocurre algo parecido:

    Se trata de una cabina DS4300 de IBM. Recibimos una alerta de que una de las baterias que hay en cada controladora estaba averiada. El funcionamiento parecia corecto por lo que no dimos el aviso a soporte inmediatamente. Durante los días posteriores comprobamos una bajada de rendimiento brutal en algunas lunes por cualquiera de las dos controladoras. El problema era debido a que, por defecto, existe un parámetro que desactiva automáticamente la caché de la cabina (en ambas controladoras) cuando falla una bateria. De todas formas, comentar que el parámetro es modificable por LUN.

    Saludos.

    Responder
    1. 5.1

      José Luis Gómez

      Hola Ángel,

      Nosotros tenemos DS4300 con dos expansiones. El otro día nos cambiaron las baterías, lo que si nos suele ocurrir son problemas de Path Preferred. ¿Tienes extesiones?… Sería para ver el conexionado de tus cabinas ya que pensamos que las nuestras no se encuentran bien conectadas y tenemos problemas en el Path Preferred en VMware con la opción elegida de Most Recently Used.

      Saludos.

      Responder
      1. 5.1.1

        Angel

        José Luis,
        tenemos DS4300, DS4700 y DS4800 y todas tienen expansiones. La instalación se hizo siguiendo los redbooks por parte de un técnico de IBM. Incluso el conexionado de las 4800 fue certificado por el laboratorio de IBM. Y te puedo decir que nosotros también tenemos el problema de Path Preferred en todas ellas. En mi opinión el problema está en que no hay una comunicación correcta entre el Storage Manager y el módulo de Storage del VMware. A nosotros nos suele ocurrir cuando se reinicia un ESX o cuando se reescanea un ESX en el que se ha creado o eliminado una LUN que es compartida por el resto.

        Responder
      2. 5.1.2

        Jose Maria Gonzalez

        Hoola Jose Luis y Angel,

        El protocolo de mulitpathing de i/o en VMware es muy simple. Me explico: Si la cabina es Activa/Activa VMware elige el Fixed (path preferred dicho de otro modo). Si la cabina es Activa/Pasiva, VMware elige MRU (Most Recent Used). Si queremos hacer balanceo de carga,podemos seleccionar en una cabina activa/activa el RR (Round Robin).

        Rgds,
        J.

        Responder
        1. 5.1.2.1

          José Luis Gömez

          Hola José María,

          Mi pregunta es la siguiente… Si mi cabina tiene para una LUN configurado el Path B y en VMware realizo un rescan en la que está involucrada esa LUN, imagino que VMware comenzará por el Path A y luego el Path B, si deteca la LUN por el Path A, ¿él cambia el camino del B al A y en la cabina aparece como advertencia que el Path Preferred ha sido cambiado?

          Es que tal vez sea un funcionamiento común que cuando se realiza un rescan en VMware, todo lo que no coincida en la cabina como Path Preferred por donde empieza VMware a escanear, VMware fuerce a funcionar por el primer camino donde ve el almacenamiento.

          ¿Qué opinas?

          Saludos.

          Responder
          1. 5.1.2.1.1

            Ángel

            Hola José Luis,
            creo que el problema está en que tanto el VMware como el Storage Manager controlan la cabina pero no se sincronizan o no hay ninguno que lleve el control como primario. Me explico: cuando creamos una lun con el Storage Manager se le asigna un path preferred. Luego reescaneamos el ESX para que la detecte y éste la encuentra por un path diferente al preferred y da la alerta en el Storage manager.
            Mi opinión es que cuando el ESX busca las lunes no sabe cual es (o no utiliza) el path preferred determinado en el Storage Manager. Por tanto, por eso da la alerta.

            Las preguntas serían: ¿como hace el reescaneo de las lunes el ESX? ¿Sigue algún algoritmo o simplemente empieza por el primer camino que encuentra? ¿Cómo actua el MRU cuando es la primera vez que detecta la lun?

            Por favor José María ilumínanos.

            Saludos.

          2. Jose Maria Gonzalez

            HOla Angel,

            Tu cabina soporta ALUA?

            rgds,
            J.

    2. 5.2

      Jose Maria Gonzalez

      Hola Angel,

      Este comportamiento es normal, es decir, en las Clariion de EMC no puedes activar ni la cache hasta que las baterías están cargadas completamente. Y es que te imaginas si la cache esta activa y no hay bateria para esa cache lo que puede pasar?

      rgds,
      J.

      Responder
      1. 5.2.1

        Ángel

        Muy buenas José María,
        el comentario lo hacía más que nada por que aunque la batería de una de las controladoras estaba bien también desactivó la caché en esa controladora. No se si ese es un comportamiento normal en otras cabinas, pero por lógica si tenemos una batería por cada controladora se debería desactivar la caché en la controladora que falla y no en ambas.

        Saludos.

        Responder
        1. 5.2.1.1

          Jose Maria Gonzalez

          No necesariamente Angel, En cabinas Activas/Activas las dos baterías de las dos SP tienen que estar cargadas para poder activar la cache.

          rgds,
          J.

          Responder
          1. 5.2.1.1.1

            Ángel

            Lo desconocía.
            Las nuestras está como activa/pasiva, no se si en este caso también deben estar las dos baterías cargadas para poder activar la caché.

            Un saludo.

  6. 6

    José Luis Gómez

    Ángel,

    Nosotros disponemos de DS4300 + EXP700 + EXP100. La instalación se hizo por parte de una empresa y posteriormente se presentó un técnico de IBM el cual lo dejó funcionando. Lo que ocurre que en su momento únicamente era DS4300 + EXP700 y unos años después se conecto la EXP1000, a partir de ese momento pensamos que la conexión ya no es la correcta, es decir, seguimos el redbook con las diferentes opciones de conexión y no nos concuerdan los LOOPS que realizan el cierre para disponer de redundancia.

    Nosotros con el Path Preferred nos ocurre también como comentas a la hora de reescanear LUN, reiniciar ESX o te digo más aún… cuando un disco es introducido nuevo para expandir esto genera también perdida de Path. Sin embargo equipos físicos con Windows montados en Cluster que atacan directamente a la Lun, nunca dan dichos problemas de Path, sólo con ESX.. como bien dices parece que no interactuan bien… no sé si será alguna actualización de firmwares pero es que miras la Web de IBM y te pones enfermo con tantas actualiazciones disponibles.

    Por cierto, tienes blades de IBM como HS40 o HS20… es que nosotros también encontramos ciertos problemas en las NIC a la hora de hacer teaming, ya que puedes elegir beacon state o link status (supuestamente informa del estado de enlace)… pero no va tampoco muy fino.

    Saludos.

    Responder
    1. 6.1

      Ángel

      José Luis,
      no se si será problema del firmware, pero te puedo decir que con ESX 4 Update 1 sobre las cabinas DS4800 con el último nivel de firmware (al que tuvimos de actualizar debido a problemas con réplicas remotas) sigo teniendo los problemas de Path Preferred.

      Tenemos varios Blade Center con HS22 y HS21 XM pero, de momento, con solo 2 tarjetas ethernet y no hemos necesitado hacer teaming ya que el tráfico de las MV van por una tarjeta y la consola y el VMotion por otra.

      Saludos.

      Responder
      1. 6.1.1

        José Luis Gómez

        Ángel,

        Pues algo que ya nos sacas de la duda, nosotros disponemos de ESX 3.5

        Las réplicas remotas, ¿las haces con la utilidad de la cabina que vale una pasta?

        Nosotros ahora mismo con 3.5 y sin poder a 4.0 ya que como son servidores 32 bits, no soporta Intel-VT ni na de na.

        Saludos y gracias por la información.

        Responder
  7. 7

    Alvaro

    Que tal Jose María..

    En un post más arriba dices lo siguiente:

    “El protocolo de mulitpathing de i/o en VMware es muy simple. Me explico: Si la cabina es Activa/Activa VMware elige el Fixed (path preferred dicho de otro modo). Si la cabina es Activa/Pasiva, VMware elige MRU (Most Recent Used). Si queremos hacer balanceo de carga,podemos seleccionar en una cabina activa/activa el RR (Round Robin)”

    Está información aparece en algun documento o la experiencia trabajando en proyectos te lo dice?

    Saludos

    Responder
    1. 7.1

      Jose Maria Gonzalez

      Si, aparece en la guía de arquitectura SAN de vmware. Aparte de ser una mejor practica y de no tocar pues VMware detecta que tipo de cabina tienes y selecciona MRU o Fixed.

      Rgds,
      j.

      Responder
      1. 7.1.1

        miguelangelalonso

        Una muy buena solución es descargarte la solución gratuita de vKERNEL (Storage), la cual os va a decir todo lo que neceitais saber de vuestra CABINA. La versión de pago además te ayuda a asolucionarlo, pero con esta versión free ya sabes los problemas que tienes en tus discos, que no es poco.

        Responder

Deja un Comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Una Web de JMG Virtual Consulting, especialistas en Soluciones de Virtualización y Formación Oficial VMware y OpenStack | Copyrights © 2017