¿Mejores prácticas para virtualizar servidores en la SAN?

¿Mejores prácticas para virtualizar servidores en la SAN?

Muy bien, quiero comenzar a aprovechar mi SAN un poco más de lo que lo he hecho hasta ahora y, al mismo tiempo, aprovechar ESXi.

Actualmente, tengo una matriz de blades Dell PowerEdge 1955 conectados a una matriz de almacenamiento EMC AX4-5 FC de gabinete único. Básicamente estoy usando SAN como DAS. Tengo LUN en la SAN que apuntan a máquinas físicas específicas, y esas máquinas utilizan los LUN para lo que sea (principalmente bases de datos y recursos compartidos Samba/NFS, según el servidor de destino).

Tengo varios servidores de archivos físicos y cada uno tiene una configuración de Samba para servir a los recursos compartidos apropiados. Como nunca logré que RHCS funcionara, solo uno de los servidores de archivos tiene los LUN montados a la vez. En el caso de que un servidor de archivos falle, lo cerco manualmente (ya sea desmontando y quitando la presentación de la unidad, usando la utilidad navisphere o cortando la energía a través de DRAC) y luego uso la utilidad navisphere para mostrar los LUN presentados en el siguiente contendiente ( después de lo cual, inicie Apache y los otros demonios). Todo a mano, ahora mismo.

Me siento como Ferris Bueller tocando el clarinete. ¡Nunca tuve una lección!

De todos modos, estoy intentando mejorar. Lo que quiero hacer es instalar ESXi en los hosts físicos, luego crear LUN para contener dos imágenes del servidor de archivos (en caso de que una se corrompa/fubar), una de las cuales será la activa y la otra será la en espera. Al menos de esta manera, no mejoro la automatización (aunque pronto escribiré un script para cambiar el servidor "activo"), pero siento que estoy agregando flexibilidad, además puedo usar los hosts ESXi albergarán otras máquinas virtuales y el hardware no se desperdiciará, como ocurre ahora.

Mis preguntas son:

1) ¿Qué tan estúpido es mi plan?

2) Cuando se trata de la implementación real, ¿debería crear una imagen vmdk normal en el LUN o debería darle una partición "sin formato" (si eso es posible con ESXi?)

3) ¿Existe una "buena" forma de utilizar servidores de archivos no agrupados?

Respuesta1

Tu plan no es una locura. Como de costumbre, hay más de unas pocas formas de atacar esto según lo que intentas lograr y cómo proteger tus datos.

En primer lugar, puede presentar un LUN sin formato a una VM mediante una "Asignación de dispositivo sin formato". Para hacer esto:

  • Presente el LUN al host ESXi (o grupo de hosts, si va a utilizar clustering/HA)
  • Agregue un disco a su VM, seleccione Raw Device Mapping, apunte al LUN
  • Vuelva a escanear el bus SCSI dentro de la VM
  • fdisk, monte y agregue a fstab, como un disco normal.

Ventajas: rápido de configurar, rápido de usar, fácil, puede representar el disco en un host físico si necesita V2P en el futuro

Desventaja: puede perder algunas opciones de instantánea/reversión basadas en VMware, dependiendo de si usa el modo de compatibilidad física o virtual

Una opción alternativa es crear VMFS en el LUN para crear un almacén de datos y luego agregar un disco VMDK a la VM que se encuentra en ese almacén de datos.

  • Lo bueno: es compatible con Storage vMotion si alguna vez compras una licencia para usarlo. Esto permite la migración en caliente de discos VMDK entre LUN e incluso SAN.

En ambos casos, usted se encuentra en una posición de riesgo similar si VMware o su VM consumen el sistema de archivos durante una falla; uno no es drásticamente mejor que el otro, aunque las opciones de recuperación disponibles serán bastante diferentes.

No implemento RDM a menos que sea necesario; Descubrí que no me dan mucha flexibilidad como VMDK (y me han mordidoinsectoseso los hizo poco prácticos al realizar otras operaciones de almacenamiento (ya que se corrigió; consulte la sección RDM en ese enlace))


En cuanto a su VM, su mejor apuesta por la flexibilidad es almacenar el disco de inicio de su servidor de archivos como un VMDK en la SAN para que pueda hacer que otros hosts lo inicien en caso de una falla del host. Al utilizar la funcionalidad HA de VMware, el arranque de su VM en otro host es automático (la VM arrancará en el segundo host como si se hubiera cortado la energía; espere realizar los fsck habituales y la magia para activarlo como en el caso de un servidor normal). ). Tenga en cuenta que HA es una función con licencia.

Para mitigar una falla de la VM, puede crear un clon liviano de su servidor de archivos, que contenga el mínimo necesario para iniciar y hacer que SAMBA se inicie en un estado configurado y lo almacene en el disco local de cada host, en espera de que agregue la unidad de datos desde el VM fallida y enciéndala.

Esto puede brindarle o no opciones adicionales en caso de una falla de SAN; En el mejor de los casos, su almacenamiento de datos requerirá un fsck u otra reparación, pero al menos no tendrá que reparar, reconstruir o configurar la VM en la parte superior. En el peor de los casos, ha perdido los datos y necesita volver a la cinta... pero de todos modos ya estaba en ese estado.

Respuesta2

Me quedaría con las imágenes de vmdk, en caso de que empieces a usar vmotion en el futuro, nunca sabes si obtendrás un presupuesto para ello.

Si sus máquinas no están agrupadas, en lo que a mí respecta, la mejor manera de administrarlas es intentar distribuir la carga lo más uniformemente posible. Tengo 3 2950 no agrupados donde la carga de las máquinas virtuales más críticas es, en la medida de lo posible, 1/3 en cada una. La teoría es que es poco probable que pierda más de una caja a la vez, por lo que al menos 2/3 podrán seguir funcionando sin verse afectados.

Desde el punto de vista energético, probablemente sería más eficiente cargar las máquinas lo más cerca posible del 100% y tener otras máquinas apagadas, pero a mí me parece como poner todos los huevos en una sola canasta.

No me consideraría un experto en esto, es simplemente lo que hago.

Respuesta3

Hola Matt. Hay muchas formas de dividir una solución cuando se utiliza una solución de virtualización. En primer lugar, ha habido muchos puntos de referencia que muestran el rendimiento de Raw LUN (RDM) frente a VMDK y la diferencia suele ser insignificante. Algunas cosas que se deben tener en cuenta con los RDM: Sólo determinadas situaciones de agrupación requieren el uso de RDM (agrupación en clústeres de MS). Los RDM tienen un límite de 2 TB, pero se puede utilizar LVM para solucionar este límite. Es "más difícil" realizar un seguimiento de los RDM que darle un LUN a ESXi para que lo use en VMFS y colocarle vmdk. Los VMDK (como se mencionó) tienen algunos beneficios interesantes: svMotion, instantáneas (no se pueden tomar instantáneas de un pRDM).

Si ejecuta Free ESXi, así es como podría solucionar su situación. En primer lugar, todos los datos están en archivos vmdk en VMFS LUNS. Configure 2 máquinas virtuales y use Heartbeat para la conmutación por error de IP y servicios. Heartbeat cambiará la IP del servicio y puede manejar secuencias de comandos para desmontar/montar el LUN de datos cuando corresponda. Incluso podría crear una secuencia de comandos de alguna CLI remota de VMware para garantizar que la máquina virtual "inactiva" se apague para protegerla. Dado que los latidos del corazón se coordinan directamente entre los sistemas, el riesgo de que ambos accedan al LUN de datos o ejecuten los mismos servicios debería ser extremadamente bajo. La clave aquí es asegurarse de que el montaje/desmontaje del LUN de datos y el inicio/apagado de los servicios sean manejados por Heartbeat, no por los mecanismos de inicio normales.

Se podría lograr una conmutación por error alternativa a través del sistema de monitoreo. Cuando detecta el host inactivo, podría usar VMware Remote CLI para apagar (para estar seguro) y luego encender la máquina virtual de respaldo. En esta situación, la recuperación es bastante manual.

En mi entorno "pequeño" no he visto que ningún VMDK se corrompa. De lo que también me he dado cuenta es que si tienes más de 2 hosts ESX(i) o una docena de máquinas virtuales, querrás tener vCenter para ayudarte a realizar un seguimiento de todo. Algunos de los paquetes Essential/Plus no son demasiado costosos considerando los beneficios.

Respuesta4

Creo que deberías preguntarte "¿Alguna vez planeo volver a los servidores físicos?"

Si la respuesta es tal vez, entonces quizás deberías seguir con RDM. ESXi con RDM (creo) requeriría que usted compre algo para que su fibra funcione (nuevamente, no estoy 100% seguro en esxi).

Teníamos varias máquinas que moví rápidamente de servidores físicos a ESX (4.0) usando RDM. Tenía una combinación de máquinas Linux y Windows (muy fácil para ambas plataformas). Todavía tenemos algunos FreeBSD antiguos en ejecución (6.0 y anteriores) en servidores físicos para los que no podemos usar RDM porque el antiguo kernel FBSD no lo admite. Fue rápido y no requirió que hiciera nada más que apuntar mi LUN y luego instalar las herramientas VMWare. Muerte cerebral fácil... sin convertidor, sin problemas...

Otra cosa que deberías preguntarte es "¿Qué funciones de VMWare quiero usar?"

Dependiendo de su respuesta, es posible que no tenga otra opción que VMDK. Si usa su SAN para instantáneas y no le importa usar vmware para eso, por ejemplo...

Compartiré algunas notas con ustedes sobre lo que nos encontramos hasta ahora. Vmotion funciona igualmente bien con RDM y VMDK, Storage Vmotion, por otro lado, solo funciona correctamente con sistemas que no son RDM, y tratar de usar el almacenamiento Vmotion para pasar de RDM a VMDK apesta. simplemente use el convertidor. La mayoría de las distribuciones de Linux tienen un paquete de herramientas vmware de código abierto que hace que la instalación de herramientas no sea un problema. La aplicación de respaldo funciona muy bien y no requiere vmware, pero no hace tantas cosas como nos gustaría. Recomiendo ampliamente tomar una clase de vmware. El que tomé fue de una semana y valió cada centavo. El soporte de VMWare es increíble. Si obtienes un contrato de soporte y tienes que llamar, son de primera. Me frustra encontrar a alguien que pueda ayudarme (en muchos menús). ), pero una vez que los recibo, SIEMPRE vienen con un soporte rápido y confiable.

información relacionada