{"id":87005,"date":"2020-07-02T07:42:17","date_gmt":"2020-07-02T05:42:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/podvodnye-kamni-pri-perehode-na-vdi-chto-testirovat-zaranee-chtoby-ne-bylo-muchitelno-bolno"},"modified":"2020-07-02T07:42:17","modified_gmt":"2020-07-02T05:42:17","slug":"podvodnye-kamni-pri-perehode-na-vdi-chto-testirovat-zaranee-chtoby-ne-bylo-muchitelno-bolno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/podvodnye-kamni-pri-perehode-na-vdi-chto-testirovat-zaranee-chtoby-ne-bylo-muchitelno-bolno","title":{"rendered":"Piedras angulares al migrar a VDI: qu\u00e9 probar de antemano para evitar dolores de cabeza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Piedras
\n\u00bfAlguna vez te has preguntado qu\u00e9 hace un esc\u00e1ner con una estaci\u00f3n VDI? Al principio, todo parece bien: se conecta como un dispositivo USB com\u00fan y es 'transparente' desde la m\u00e1quina virtual. Luego, el usuario da la orden de escanear y todo se desmorona. En el mejor de los casos, el controlador del esc\u00e1ner, en el peor, el software del esc\u00e1ner se cae despu\u00e9s de un par de minutos y puede afectar a otros usuarios del cl\u00faster. \u00bfPor qu\u00e9? Porque para obtener una imagen comprimida de cinco megabytes, se deben enviar a trav\u00e9s de USB 2.0 de dos a tres \u00f3rdenes de magnitud m\u00e1s datos. La capacidad de la l\u00ednea es de 480 Mbit\/s. <\/p>\n

As\u00ed que es necesario probar tres cosas: UX, perif\u00e9ricos y seguridad, sin falta. Hay diferencias en c\u00f3mo probar. Se pueden instalar agentes localmente en cada estaci\u00f3n de trabajo virtual. Es relativamente econ\u00f3mico, pero no muestra la carga en el canal y no calcula correctamente la carga en el procesador. La segunda opci\u00f3n es desplegar el n\u00famero necesario de robots-emuladores en otro lugar y comenzar a conectarlos a los lugares de trabajo reales como si fueran usuarios reales. Esto a\u00f1adir\u00e1 carga del protocolo de transmisi\u00f3n de video (m\u00e1s espec\u00edficamente, de los p\u00edxeles cambiados), el an\u00e1lisis y env\u00edo de paquetes de red, y se entender\u00e1 mejor la carga del canal. En general, el canal raramente se prueba.
\n<\/a><\/noindex>
\nUX es la velocidad con la que el usuario final realiza diferentes acciones. Existen paquetes de pruebas que cargan la instalaci\u00f3n con cientos de usuarios y llevan a cabo las acciones t\u00edpicas: inician paquetes de oficina, leen archivos PDF, navegan, rara vez ven porno durante el horario laboral, etc. <\/p>\n

Un ejemplo bastante claro de por qu\u00e9 esas pruebas son importantes de antemano se dio en la \u00faltima instalaci\u00f3n. All\u00ed, mil usuarios est\u00e1n migrando a VDI, tienen oficina, navegador y SAP. El departamento de TI de la empresa est\u00e1 bien desarrollado, por lo que existe una cultura de pruebas de carga antes de las implementaciones. Seg\u00fan mi experiencia, generalmente hay que convencer al cliente para hacer esto, porque los costos son altos y el beneficio no siempre es evidente. \u00bfHay c\u00e1lculos donde se puede cometer un error? En realidad, esas pruebas revelan \u00e1reas donde se pens\u00f3, pero no se pudo verificar.<\/p>\n

Instalaci\u00f3n<\/h3>\n

\nSeis servidores, la configuraci\u00f3n es la siguiente:<\/p>\n

\"Piedras
\n
\nNo tuvimos acceso al almacenamiento del cliente, se proporcionaba ya en forma de espacio como servicio, de hecho. Pero sabemos que es todo flash. No sabemos exactamente qu\u00e9 tipo de flash es, pero las secciones son de 10 TB. VDI es VMware a elecci\u00f3n del cliente, ya que el equipo de TI est\u00e1 familiarizado con la pila y todo se complementa bastante bien para formar una infraestructura coherente. VMware realmente engancha a sus usuarios en su ecosistema, pero si hay suficiente presupuesto para la compra, se pueden evitar problemas durante a\u00f1os. Pero a menudo es un gran \"si\". Tenemos un buen descuento y el cliente lo sabe. <\/p>\n

Comenzamos las pruebas porque el equipo de TI no permite lanzar casi nada a producci\u00f3n sin pruebas. VDI no es algo que se pueda iniciar y luego aceptar. Los usuarios se integran gradualmente y es posible que se enfrenten a problemas despu\u00e9s de seis meses. Algo que, por supuesto, nadie quiere. <\/p>\n

450 \"usuarios\" en la prueba, generamos la carga localmente. Los usuarios de prueba realizan diferentes acciones simult\u00e1neamente, medimos el tiempo de cada operaci\u00f3n durante varias horas de trabajo:<\/p>\n

\"Piedras
\n
\n\"Piedras
\n
\n\"Piedras
\n
\nObservamos c\u00f3mo se comportan los servidores y el almacenamiento. Si VDI puede crear la cantidad necesaria de puestos de trabajo virtuales, etc. Dado que el cliente no opt\u00f3 por la hipercodificaci\u00f3n y decidi\u00f3 por el almacenamiento flash, tambi\u00e9n era necesario comprobar la correcci\u00f3n del dimensionamiento. <\/p>\n

\"Piedras
\n
\n\"Piedras
\n
\n\"Piedras
\n
\n\"Piedras
\n
\n\"Piedras
\n
\n\"Piedras
\n
\nSi algo est\u00e1 retrasando, es necesario ajustar la configuraci\u00f3n de la granja VDI, en particular, la distribuci\u00f3n de recursos entre los usuarios de diferentes categor\u00edas. <\/p>\n

Perif\u00e9rica<\/h3>\n

\nNormalmente hay tres situaciones con la perif\u00e9rica:<\/p>\n