{"id":38966,"date":"2019-10-31T22:27:03","date_gmt":"2019-10-31T19:27:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/admin-bez-ruk-giperkonvergentsiya\/"},"modified":"2019-10-31T22:27:03","modified_gmt":"2019-10-31T19:27:03","slug":"admin-bez-ruk-giperkonvergentsiya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"\u00bfAdmin sin manos = hiperconvergencia?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00bfAdmin
\n\"\u00bfAdmin
\n
\nEste es un mito bastante com\u00fan en el \u00e1mbito del hardware de servidores. Sin embargo, en la pr\u00e1ctica, las soluciones hiperconvergentes (todo en uno) son necesarias por muchas razones. Hist\u00f3ricamente, las primeras arquitecturas fueron desarrolladas por Amazon y Google para sus propios servicios. La idea era crear un granja de computaci\u00f3n a partir de nodos id\u00e9nticos, cada uno con sus propios discos. Todo esto se integraba con un software de sistematizaci\u00f3n (hipervisor) y se divid\u00eda en m\u00e1quinas virtuales. La principal tarea era minimizar los esfuerzos en el mantenimiento de un nodo y minimizar los problemas durante la escalabilidad: simplemente se adquir\u00edan mil o dos de esos servidores y se conectaban al lado. En la pr\u00e1ctica, esto es raro, y con mucho mayor frecuencia se habla de un menor n\u00famero de nodos y una arquitectura un poco diferente. <\/p>\n

Pero la ventaja sigue siendo la misma: una incre\u00edble simplicidad en la escalabilidad y gesti\u00f3n. La desventaja es que diferentes tareas consumen recursos de manera diferente, y en algunos casos habr\u00e1 muchos discos locales, en otros habr\u00e1 poca RAM, y as\u00ed sucesivamente, lo que significa que con diferentes tipos de tareas, la utilizaci\u00f3n de recursos disminuir\u00e1. <\/p>\n

Resulta que pagas un 10\u201315% m\u00e1s por la facilidad de configuraci\u00f3n. Este es el mito detr\u00e1s del encabezado. Buscamos durante mucho tiempo d\u00f3nde se aplicar\u00eda la tecnolog\u00eda de manera \u00f3ptima y lo encontramos. La cuesti\u00f3n es que Cisco no ten\u00eda sus propios sistemas de almacenamiento, pero quer\u00edan abarcar el mercado de servidores completo. Y crearon Cisco Hyperflex, una soluci\u00f3n con almacenamiento local en los nodos. <\/p>\n

Y de esto inesperadamente surgi\u00f3 una muy buena soluci\u00f3n para centros de datos de respaldo (Recuperaci\u00f3n ante Desastres). Por qu\u00e9 y c\u00f3mo, ahora les contar\u00e9. Y mostrar\u00e9 las pruebas del cl\u00faster. <\/a><\/noindex><\/p>\n

D\u00f3nde se necesita<\/h3>\n

\nLa hiperconvergencia es: <\/p>\n

    \n
  1. La transferencia de discos a los nodos de computaci\u00f3n.<\/li>\n
  2. La integraci\u00f3n completa del subsistema de almacenamiento de datos con el subsistema de virtualizaci\u00f3n.<\/li>\n
  3. La transferencia \/ integraci\u00f3n con el subsistema de red.<\/li>\n<\/ol>\n

    \nTal conexi\u00f3n permite implementar muchas caracter\u00edsticas de almacenamiento de datos a nivel de virtualizaci\u00f3n y todo desde una \u00fanica ventana de gesti\u00f3n.<\/p>\n

    En nuestra empresa, hay una gran demanda de proyectos de dise\u00f1o de centros de datos de respaldo, y a menudo se elige una soluci\u00f3n hiperconvergente debido a la amplia variedad de opciones de replicaci\u00f3n (incluso hasta un metrocl\u00faster) disponibles de manera est\u00e1ndar. <\/p>\n

    En el caso de los centros de datos de respaldo, generalmente se trata de un objeto remoto ubicado en el otro extremo de la ciudad o incluso en otra ciudad. Permite recuperar sistemas cr\u00edticos en caso de una falla parcial o total del centro de datos principal. Los datos se replican continuamente desde la producci\u00f3n, y esta replicaci\u00f3n puede realizarse a nivel de aplicaci\u00f3n o a nivel de dispositivo de almacenamiento (SAN).<\/p>\n

    Por lo tanto, ahora hablar\u00e9 sobre la estructura del sistema y las pruebas, y luego sobre un par de escenarios de aplicaci\u00f3n real con datos sobre el ahorro. <\/p>\n

    Pruebas<\/h3>\n

    \nNuestro ejemplar consta de cuatro servidores, cada uno con 10 discos SSD de 960 GB. Hay un disco dedicado para el almacenamiento en cach\u00e9 de operaciones de escritura y para la m\u00e1quina virtual de servicio. La soluci\u00f3n es la cuarta versi\u00f3n. La primera era claramente mediocre (seg\u00fan los comentarios), la segunda ten\u00eda problemas, la tercera ya era bastante estable, y esta se puede considerar un lanzamiento tras finalizar la beta p\u00fablica. Durante el tiempo de prueba, no vi problemas, todo funciona a la perfecci\u00f3n.<\/p>\n

    Cambios en v4<\/b>Se han corregido un mont\u00f3n de errores. <\/p>\n

    Inicialmente, la plataforma solo pod\u00eda funcionar con el hipervisor VMware ESXi y admit\u00eda un n\u00famero limitado de nodos. Adem\u00e1s, el proceso de implementaci\u00f3n no siempre finalizaba con \u00e9xito, era necesario reiniciar algunos pasos, hab\u00eda problemas con la actualizaci\u00f3n desde versiones anteriores, y los datos en la GUI no siempre se mostraban correctamente (aunque a\u00fan no estoy encantado con la visualizaci\u00f3n de los gr\u00e1ficos de rendimiento), a veces surg\u00edan problemas en la integraci\u00f3n con la virtualizaci\u00f3n.<\/p>\n

    Ahora todos los problemas iniciales han sido solucionados, HyperFlex es compatible tanto con ESXi como con Hyper-V, adem\u00e1s de esto es posible:<\/p>\n

      \n
    1. Crear un cl\u00faster expandido. <\/li>\n
    2. Crear un cl\u00faster para oficinas sin usar Fabric Interconnect, de dos a cuatro nodos (solo compramos servidores).<\/li>\n
    3. Posibilidad de trabajar con SAN externas.<\/li>\n
    4. Soporte para contenedores y Kubernetes.<\/li>\n
    5. Crear zonas de disponibilidad.<\/li>\n
    6. Integraci\u00f3n con VMware SRM, si la funcionalidad incorporada no satisface las necesidades.<\/li>\n<\/ol>\n

      La arquitectura no difiere mucho de las soluciones de los principales competidores, no se ha reinventado la rueda. Todo esto funciona en la plataforma de virtualizaci\u00f3n VMware o Hyper-V. Se aloja f\u00edsicamente en servidores de desarrollo propio de Cisco UCS. Hay quienes odian la plataforma por su relativa complejidad en la configuraci\u00f3n inicial, el mont\u00f3n de botones, un sistema de plantillas y dependencias no trivial, pero tambi\u00e9n hay quienes han encontrado el zen, se han empapado de la idea y ya no quieren trabajar con otros servidores. <\/p>\n

      Nos enfocaremos en la soluci\u00f3n para VMware, ya que se cre\u00f3 inicialmente para esta y tiene m\u00e1s funcionalidad; Hyper-V fue mejorado sobre la marcha para no quedarse atr\u00e1s de los competidores y cumplir con las expectativas del mercado.<\/p>\n

      Hay un cl\u00faster de servidores equipados con discos. Hay discos para almacenamiento de datos (SSD o HDD, seg\u00fan su gusto y necesidades), y hay un SSD para caching. Al escribir datos en el datastore, se realiza la preservaci\u00f3n de datos en la capa de cach\u00e9 (disco SSD dedicado y RAM de la VM de servicio). Al mismo tiempo, un bloque de datos se env\u00eda a los nodos en el cl\u00faster (el n\u00famero de nodos depende del factor de replicaci\u00f3n del cl\u00faster). Despu\u00e9s de la confirmaci\u00f3n de todos los nodos sobre la escritura exitosa, la confirmaci\u00f3n se env\u00eda al hipervisor y luego a la VM. Los datos escritos se desduplican, comprimen y almacenan en discos en segundo plano. A su vez, siempre se escribe un gran bloque en los discos de almacenamiento de manera secuencial, lo que reduce la carga en ellos.<\/p>\n

      La desduplicaci\u00f3n y compresi\u00f3n est\u00e1n siempre activadas y no se pueden desactivar. La lectura de datos se realiza directamente desde los discos de almacenamiento o desde la cach\u00e9 RAM. Si se utiliza una configuraci\u00f3n h\u00edbrida, la lectura tambi\u00e9n se almacena en un disco SSD.<\/p>\n

      Los datos no est\u00e1n vinculados a la ubicaci\u00f3n actual de la m\u00e1quina virtual y se distribuyen uniformemente entre los nodos. Este enfoque permite cargar de manera equitativa todos los discos y las interfaces de red. Surge un claro inconveniente: no podemos reducir al m\u00ednimo la latencia de lectura, ya que no hay garant\u00eda de que los datos est\u00e9n localmente disponibles. Pero considero que este es un sacrificio menor en comparaci\u00f3n con las ventajas obtenidas. Especialmente porque las latencias de red han alcanzado niveles en los que pr\u00e1cticamente no afectan el resultado general.<\/p>\n

      Toda la l\u00f3gica de funcionamiento del subsistema de discos es gestionada por una VM de servicio especial, el controlador Cisco HyperFlex Data Platform, que se crea en cada nodo de almacenamiento. En nuestra configuraci\u00f3n, se asignaron ocho vCPU y 72 GB de RAM a la VM de servicio, lo cual no es poco. Cabe recordar que el host tiene disponibles 28 n\u00facleos f\u00edsicos y 512 GB de RAM.<\/p>\n

      La VM de servicio tiene acceso directo a los discos f\u00edsicos a trav\u00e9s de la conexi\u00f3n del controlador SAS en la VM. La comunicaci\u00f3n con el hipervisor se realiza a trav\u00e9s de un m\u00f3dulo especial llamado IOVisor, que intercepta las operaciones de entrada y salida, y mediante un agente que permite enviar comandos a la API del hipervisor. El agente se encarga de trabajar con los snapshots y clones de HyperFlex.<\/p>\n

      En el hipervisor, los recursos de disco se montan como NFS o SMB (dependiendo del tipo de hipervisor, adivinen cu\u00e1l es cu\u00e1l). Pero bajo el cap\u00f3, se trata de un sistema de archivos distribuido que permite a\u00f1adir caracter\u00edsticas de sistemas de almacenamiento completo: asignaci\u00f3n de vol\u00famenes delgada, compresi\u00f3n y deduplicaci\u00f3n, snapshots mediante la tecnolog\u00eda Redirect-on-Write, replicaci\u00f3n sincr\u00f3nica\/asincr\u00f3nica.<\/p>\n

      La VM de servicio proporciona acceso a la interfaz web de gesti\u00f3n del subsistema HyperFlex. Hay integraci\u00f3n con vCenter, y gran parte de las tareas diarias se pueden realizar desde all\u00ed, pero las datastores, por ejemplo, es m\u00e1s conveniente configurarlas desde una web separada, si ya ha pasado a la interfaz r\u00e1pida de HTML5, o utilizar el cliente Flash completo con integraci\u00f3n total. En la web de servicio se puede ver el rendimiento y el estado detallado del sistema.<\/p>\n

      \"\u00bfAdmin
      \n
      \nTambi\u00e9n existe otro tipo de nodos en el cl\u00faster: los nodos de computaci\u00f3n. Estos pueden ser servidores en rack o blade sin discos incorporados. En estos servidores se pueden ejecutar VMs cuyas datos se almacenan en servidores con discos. Desde el punto de vista del acceso a los datos, no hay diferencia entre los tipos de nodos, ya que la arquitectura permite abstraerse de la ubicaci\u00f3n f\u00edsica de los datos. La relaci\u00f3n m\u00e1xima de nodos de computaci\u00f3n a nodos de almacenamiento es de 2:1.<\/p>\n

      El uso de nodos de computaci\u00f3n aumenta la flexibilidad al escalar los recursos del cl\u00faster: no es necesario adquirir nodos con discos si solo necesitamos CPU\/RAM. Adem\u00e1s, podemos agregar un blade chassis y obtener ahorros en el espacio para servidores en el rack.<\/p>\n

      En resumen, tenemos una plataforma hiperconvergente con las siguientes caracter\u00edsticas:<\/p>\n