Virtual Data Center: 10 errores que todos cometen
Virtual Data Center: 10 errores que todos cometen
Virtual Data Center: 10 errores que todos cometen
Aunque a menudo discutimos la Virtual Data Center como algo nuevo, la necesidad de la tecnología es casi tan antigua como la informática en sí, que se remonta a la década de 1960 .
Hacer que un sistema funcione en otro sistema siempre será un requisito en nuestra industria.
En el Virtual Data Center se usa en PC, servidores y nubes cliente. Así como en tecnologías aparentemente no relacionadas, como la emulación de juegos, que es, en esencia, solo otra forma de Virtual Data Center.
Por un lado, Virtual Data Center te hace la vida más fácil.
Sin embargo, el principio de la muñeca Matryoshka de tener algo sentado dentro de otra cosa (y tal vez sentarse dentro de otra cosa, como con el Virtual Data Center anidado) hace que algunas tareas informáticas sean más complejas.
La complejidad siempre significa un mayor potencial de errores, tanto en términos prácticos como errores a nivel conceptual. Identifiquemos los errores comunes y cómo evitarlos. (Mis ejemplos usan principalmente Windows pero son igualmente aplicables a la Virtual Data Center en Linux).
No. 1. Sobreaprovisionamiento de Virtual Data Center
Acaba de desempaquetar alegremente su nuevo y brillante rack de servidores de 32 núcleos equipado con cantidades casi infinitas de RAM.
Incluso cuando el servidor está diseñado únicamente para fines de Virtual Data Center, puede que no sea necesario dar a cada VM más empuje de lo que realmente necesita, específicamente cuando se trata de recursos de CPU.
Por ejemplo, puede bendecir a cada VM con dos núcleos de vCPU debido a actitudes vagas como “Hey, la multitarea es importante” o “Bueno, el rendimiento seguramente será horrible con un solo núcleo, ¡ya no es 2003!”
Déjame detenerte allí mismo. En primer lugar, al proporcionar a cada VM una gran cantidad de Virtual Data Center, limita la cantidad de VM que puede admitir el servidor físico.
Segundo, mira lo que realmente necesitas que haga esta VM. Instale y pruebe la aplicación o servicio que desea ejecutar Virtual Data Center en hardware “real”.
Luego pregúntese: “¿Esta aplicación realmente necesita dos núcleos? ¿Realmente usa la potencia de la CPU todo el tiempo? ”Si la respuesta es no, entonces no le dé más de lo que necesita.
En tercer lugar, está el temido aspecto del tiempo de CPU Ready: mientras más vCPUs asignes, más probable es que tu VM esté en el estado “CPU ready”, esperando que tu CPU real procese toda esta carga de trabajo. Aquí hay un buen explicativo si quieres profundizar un poco más.
No. 2. Dándole a la VM más RAM (Virtual Data Center) de la que necesita
¡El mismo principio se aplica a la memoria! Puede pensar que dar a sus máquinas Virtual Data Center unos pocos gigabytes de memoria adicionales significa que nunca se quedarán sin recursos. Crees que no puedes ser demasiado rico, demasiado delgado o tener demasiada RAM.
En realidad, no deberías darle a una VM más RAM de la que realmente necesita. En su lugar, intente calcular cuánta memoria requiere el usuario o el entorno de la aplicación.
Por ejemplo, si está aprovisionando máquinas Virtual Data Center para admitir un pequeño equipo de empleados que usan solo Windows 7, Microsoft Office y tal vez una línea extraña de aplicaciones comerciales, estarán bien con 2 a 4 GB de memoria, siempre que los usuarios no realizan muchas tareas múltiples ni trabajan con archivos más grandes.
Compare el rendimiento y el uso del sistema a lo largo del tiempo mirando los monitores de rendimiento, los archivos de registro de la aplicación y la utilización de recursos (el Administrador de tareas puede ayudar).
Tal vez pueda darle a la VM 200 a 500 MB adicionales sobre el promedio por si acaso. Pero asegúrese de que la diferencia entre la utilización de la memoria activa real de la máquina de Virtual Data Center y la memoria total asignada sea muy pequeña.
No. 3. Hacer malas elecciones de almacenamiento: hilado vs. sólido
Sí, las unidades de estado sólido (SSD) son un sueño para las cargas de trabajo de Virtual Data Center debido a su alta velocidad y latencias ultrabajas. Sin embargo, el almacenamiento más rápido no siempre está dentro de su presupuesto. Si el presupuesto de TI no le permite utilizar SSD completo, entonces quédese con unidades de disco duro (HDD) por completo.
Pero toma una decisión. No mezcles los dos. He visto a los administradores colocar el sistema operativo host en un SSD más pequeño (y por lo tanto asequible) y el sistema operativo invitado en HDD giratorios viejos y buenos.
El proceso de pensamiento inicial es sólido: el host debe ser súper rápido, ya que es responsable de toda la carga de trabajo; Los discos duros son grandes y pueden alojar muchos invitados.
Pero en realidad, el SSD rápido del host era prácticamente inútil, ya que tenía que esperar a que los HDD 10 veces más lentos mezclaran los datos de un lado a otro. Solo esperó más rápido.
El resultado final es que el beneficio de rendimiento de SSD fue prácticamente inútil. No cometas el mismo error. Comprométase con SSD o quédese con HDD hasta que el presupuesto le permita comprar el hardware óptimo.
No. 4. Desechando el sistema host
Haga de su servidor de Virtual Data Center una máquina dedicada y no lo toque. En mi experiencia, un servidor de Virtual Data Center debe ejecutar una cosa y solo un: Virtual Data Center . Período.
No tiene ningún valor tratar de hacer que un sistema cumpla una doble función. Sí, entiendo la motivación: pagaste una suma de cinco o incluso seis dígitos por el hardware, y quieres que funcione lo más posible. Pero es un error.
No intente convertir una fuente tan poderosa en (también) su estación de trabajo personal, un servidor de correo electrónico o una máquina de renderizado, ni siquiera si adquirió un poderoso servidor de 32 núcleos con 128 GB de RAM para admitir solo un puñado de máquinas Virtual Data Center.
Una vez me di por vencido con esta tentación y terminé con ocho máquinas Virtual Data Center que se bloquearon y funcionaron muy lentamente. Resultó que mi sistema operativo host tenía un proceso renegado que sufría una fuga de identificador de Windows aleatorio y extremadamente difícil de identificar .
Un proceso con decenas de miles de identificadores abiertos matará su rendimiento y confiabilidad, y es difícil de detectar, ya que Windows no le da ninguna señal de advertencia. Claro, si lo desea, instale un puñado de herramientas de administración de servidores livianas y su solución de seguridad preferida, pero eso es todo.
No. 5. Olvidarse de las licencias.
No desea despertarse con una llamada del departamento de cumplimiento corporativo o descubrir que recibió una multa desagradable de la última auditoría cuando alguien descubre que usted excedió las licencias de VM disponibles. No quieres decir: “Oh, ¿pero ya no pagué por esto?”
Por el contrario, asegúrese de que la persona a cargo de su infraestructura (tal vez sea usted) sepa acerca de las licencias para los sistemas operativos invitados y host, así como para todas las aplicaciones instaladas.
Lea la letra pequeña! El hecho de que su sistema operativo invitado acepte una clave de licencia para el estándar Windows Server 2016 no significa que pueda usar esa clave en un número infinito de máquinas Virtual Data Center. Recuerde, una licencia generalmente está vinculada al hardware.
Si ese hardware se mueve o cambia (lo que sucede en las máquinas Virtual Data Center con cierta regularidad), tiene un problema legal que resolver.
Entonces, haz una investigación adecuada. Hable con su distribuidor o su socio de TI para determinar qué licencias necesita. Por ejemplo, si necesita ejecutar docenas de máquinas Virtual Data Center en Windows, vaya con una licencia de Windows Server Datacenter. (Consulte también esta calculadora de costos del centro de datos HPE ) .
No. 6. Usando Virtual Data Center cuando no deberías
A veces, el error es construir un entorno de Virtual Data Center en primer lugar. No todas las tareas están destinadas a Virtual Data Center, y no solo por razones de compatibilidad.
En algunos casos, necesita las características o el rendimiento de una máquina “real”. No importa cuánto haya avanzado la Virtual Data Center y el hardware del servidor a lo largo de los años, las aplicaciones o servicios con gran cantidad de GPU que requieren dongles de hardware específicos generalmente no funcionan muy bien en un entorno Virtual Data Center.
Luego está el problema recurrente de la complejidad. Como dije anteriormente, un entorno Virtual Data Center es más difícil de solucionar, así que si no lo necesita, no lo haga.
Para un ejemplo específico: instalé un sistema de comercio de criptomonedas en vivo en un sistema operativo de Virtual Data Center para aislarlo del sistema operativo real por varias razones (por ejemplo, seguridad y privacidad). Quería que esta uno OS Virtual Data Center para manejar una sola cosa: el comercio y nada más!
Sin embargo, no me di cuenta de que el reloj interno del sistema operativo invitado difería muy ligeramente (aquí estamos hablando de milisegundos) y la diferencia creció con el tiempo.
Llegó a un punto en el que la diferencia horaria realmente hizo que el software dejara de operar y luego se bloqueara.
No. 7. Virtual Data Center en hardware antiguo
Cada revisión importante de la generación del procesador trae mejoras para la Virtual Data Center. Ya sea más rendimiento o soporte para nuevas características de Virtual Data Center, como el VT-x de Intel para Virtual Data Center anidada.
Si bien puede hacer que las computadoras más antiguas entren en servicio para algunas tareas, no se abarate y se adhiera a su servidor de 10 a 15 años si desea Virtual Data Center una docena de clientes de Windows 10 para cargas de trabajo masivas. Planifique con anticipación y asegúrese de que su hardware esté a la altura.
No. 8. Configuración y olvido
Trate su máquina virtual de la misma manera que trataría una máquina física. No aprovisione un entorno ajustado y piense que puede tomar un año sabático.
Sí, su sistema operativo invitado no es real, pero eso no significa que no necesite ningún tipo de mantenimiento. Verifique su monitoreo de rendimiento, verifique los registros, actualice las aplicaciones instaladas y asegúrese de que todos los servicios de seguridad de sus clientes se estén ejecutando. La lista continúa, pero en resumen, trate las máquinas virtuales como si estuvieran físicamente allí con usted, al menos en el lado del software.
No. 9. Fallar en el benchmark regularmente
Idealmente, el rendimiento de ejecutar una tarea específica en un entorno virtual debe ser lo más cercano posible al rendimiento de la máquina nativa. Para probar si lo logró, ejecute puntos de referencia que se parezcan mucho a lo que está tratando de hacer.
Si está en su presupuesto, use SPECv para medir el rendimiento de extremo a extremo de su entorno virtualizado en una variedad de escenarios del mundo real.
En escenarios de máquinas virtuales de menor escala, también puede usar herramientas de evaluación comparativa probadas y verdaderas para comparar el rendimiento, como Netperf, PassMark, Cinebench y PCMark Vantage.
Asegúrese de que el invitado y el sistema operativo host estén configurados de la forma más idéntica posible. Entonces, por ejemplo, en un escenario de evaluación comparativa, debe restringir los recursos de RAM y CPU de sus máquinas host (a través de BIOS / UEFI o varias utilidades de configuración) para que coincidan con las de la máquina huésped que planea implementar.
Repita las pruebas de tres a cinco veces para eliminar picos de rendimiento o interferencias accidentales.
No. 10. Crear máquinas virtuales zombie
No hay razón para inventar “The Walking Dead” en el trabajo. Implemente un sistema de desaprovisionamiento adecuado cuando ya no necesite una máquina de Virtual Data Center. Los entornos virtuales son absolutamente fantásticos para probar software o servicios. Como una línea específica de aplicación comercial, durante una semana o un mes para ver si es factible implementarlo en toda la empresa.
Y la evaluación está bien, por supuesto, excepto que los administradores a veces olvidan estas máquinas. No apagan los sistemas ni los dejan funcionando para siempre.
Esto sucede con frecuencia en organizaciones más grandes donde los recursos son abundantes y baratos. Y la comunicación departamental falla (por lo que siempre es responsabilidad de otra persona hacer un seguimiento).
No olvide: cualquier máquina virtual, incluso cuando no se está ejecutando, consume recursos. Deshágase de él en el momento en que esté seguro de que ya no necesitará usarlo para ninguna prueba. No dejes que tus máquinas virtuales muten en zombis digitales.