Análisis profundo: cómo Pure Fusion planea implementar clases de almacenamiento

Pure Storage, pionero del almacenamiento flash, anunció recientemente que actualizará su plano de control Fusion para que la capacidad de almacenamiento en sus arreglos esté disponible a través de clases de almacenamiento que permitan aprovisionarlo fácilmente para cualquier aplicación que lo necesite.

Esto potencialmente aporta muchas ventajas, ya que hace que el almacenamiento sea más simple y más fácilmente utilizable por múltiples aplicaciones en numerosos hosts y en diversos entornos.

Kubernetes ha utilizado durante mucho tiempo el concepto de clases de almacenamiento para proporcionar almacenamiento persistente con perfiles definidos a las aplicaciones. Pero eso ocurre en entornos en contenedores que Kubernetes controla de arriba a abajo.

Entonces, ¿cómo funcionarán las clases de almacenamiento para el plano de control Fusion de Pure en entornos de centros de datos heterogéneos?

En el evento Pure’s Accelerate en Las Vegas a mediados de junio, nos reunimos con el fundador y director visionario de Pure Storage, John “Coz” Colgrove, para preguntarle.

¿Cómo resumirías la nueva funcionalidad anunciada para Fusion?

John “Coz” Colgrove: El objetivo de Fusion es permitirle ejecutar su flota de arreglos como una oferta de servicio, permitirle definir una pequeña cantidad de clases de almacenamiento y así obtener una coherencia mucho mayor en su entorno.

Un cliente típico compra algunos arreglos. El año que viene, compran más matrices y luego más el año siguiente. Quizás el año que viene desmantelen algunos de los anteriores y compren algunos más.

Tienen esta flota que han comprado en muchos momentos diferentes. Tienen diferentes clases de matrices, tal vez diferentes generaciones de la misma clase. Entonces, tienen esta flota que es heterogénea y tienen problemas para gestionarla para lograr una utilización uniforme.

Porque, por supuesto, los niveles de rendimiento y capacidades de estas cosas son diferentes. Éste tiene tres características que este otro no tiene. Éste tiene dos características diferentes. Y entonces tienes este desorden de 27 tipos diferentes de almacenamiento en tu centro de datos.

Ahora estás intentando hacer un cambio. Por ejemplo, si quiero implementar esta nueva característica de seguridad, planificarla y ejecutarla es mucho más difícil porque todos esos diferentes tipos de almacenamiento significan que tienes que descubrir cómo aplicarla.

Lo que Fusion debería permitirle hacer es tener una pequeña cantidad de personas que definan clases de almacenamiento con atributos. Luego, puede hacer que sus usuarios lo hagan a través del aprovisionamiento de API, o aún puede hacer que los administradores de TI lo hagan cuando el usuario abre un ticket que dice: “Necesito 10 TB” y ellos lo resuelven.

En lugar de tener que ir a todos estos arreglos y descubrir cuál tiene capacidad, cuál tiene suficiente rendimiento, cuál tiene el tipo correcto de ajuste, Fusion resolverá todo eso y los clasificará, así que: aquí está mi almacenamiento de clase A. , aquí está mi almacenamiento de clase B, aquí está mi almacenamiento de clase C.

Y yo le diría a todas las organizaciones que no deberían tener más de tres o tal vez cuatro clases. De esa manera, podrá razonar y mover los servicios de su centro de datos de manera consistente. Todo eso debería permitir a las personas aprovechar mucho más su entorno.

Porque otro problema que tienes es que compras estos arreglos y, por ejemplo, el departamento de finanzas posee un arreglo y tiene sus aplicaciones en él. Y si no lo llenan, no quieren a nadie más, ¿verdad? Tienes que deshacerte de eso. La nube no hace eso. No tiene sentido.

Vemos a todos estos clientes que tienen 20, 30, 50, 100 arreglos y están utilizados en un 40%, 50%, 30%. Quiero empezar por conseguir que lleguen al 70% o al 80%, y eso es lo que Fusion quiere hacer.

Cuando comenzamos el proyecto Fusion, buscamos implementaciones totalmente nuevas. Era lo más fácil de hacer y no tener que preocuparse por los entornos heredados. Eso fue un error. Lo que hace el nuevo Fusion es ir tras los despliegues abandonados. Las personas que ya tienen flotas ahora pueden implementar Fusion y, en esencia, absorber su configuración actual y comenzar a implementar cosas nuevas usando Fusion.

La siguiente fase permitirá que Fusion reequilibre todos esos arreglos sin problemas. Fusion comenzará a recomendar elementos de equilibrio de carga.

Viste algo de eso en [Pure’s AI] Copiloto. Es una vista previa tecnológica en este momento este verano, pero cuando se lance, irá con Fusion. Le ayudará a obtener esta información sobre la flota. Ayudará a los usuarios no expertos a obtener información detallada sobre la flota y a tomar decisiones mucho más estratégicas.

¿Qué obstáculos de ingeniería ha tenido que superar Pure para que Fusion funcione en entornos abandonados?

porque: Lo más importante fue que es fácil decir que cada volumen allí, cada objeto ha sido configurado con Fusion, por lo que Fusion lo sabe todo.

La base de datos central de Fusion puede tener todo este conocimiento y decir que todo se ajusta a una de estas clases de almacenamiento definidas. La parte difícil con brownfield fue decir que tomaríamos todas las configuraciones existentes, las tomaríamos y las convertiríamos en una configuración Fusion.

Fusion tiene una noción de cosas como un sitio. Muy similar a algunos de los conceptos de la nube. No existe información del sitio en la configuración existente.

Tenías que tomar decisiones como: “Vamos a importar todo lo que hay en la configuración existente y lo colocaremos en este espacio de trabajo predeterminado”.

Otro concepto que tiene Fusion es la idea de que usted podría tener un espacio de trabajo que esté controlando con sus clases de almacenamiento, y yo podría tener uno que esté controlando con el mío. Entonces, tuvo que tomar toda la configuración existente, incorporarla y crear valores predeterminados para todo esto. Todos los conceptos que antes no existían.

En Kubernetes, tiene volúmenes persistentes y clases de almacenamiento, y las aplicaciones tienen derechos sobre las clases de almacenamiento y los volúmenes persistentes. Es fácil ver cómo funciona eso en Kubernetes, porque Kubernetes es el intermediario que maneja esas relaciones. ¿Cuál es el análogo de eso en Fusion, o hay un análogo? ¿Como funciona?

porque: No, hay una analogía, y de eso estaba hablando, de los sitios y los espacios de trabajo y cosas así.

Mientras que la nube, incluso antes de Kubernetes, introdujo este concepto de sitio o región, supongo que se llamaría, una zona de disponibilidad dentro de una región, este tipo de conceptos se incorporan a la forma en que operan las personas. Y Kubernetes tiene un conjunto similar de conceptos, y tienen algunas pequeñas diferencias, pero hemos adoptado las mismas cosas en Fusion; sitios, zonas de disponibilidad y ese tipo de cosas.

Porque lo que estamos tratando de hacer es crear una oferta de servicio similar a la nube que pueda ejecutar localmente o, de hecho, que pueda ejecutar localmente y extender a su Pure Cloud Block Store y a sus recursos en la nube.

¿Fusion proporciona el equivalente a un reclamo de volumen persistente en la aplicación de manera similar?

porque: El reclamo de volumen persistente es más una cuestión de contenedor, por lo que sería más Portworx. Pero la analogía normalmente es que cuando tienes un sistema de archivos o un volumen, lo exportas bajo un conjunto de reglas de exportación, en el caso de un sistema de archivos o conectado a un host, Fibre Channel, iSCSI, NVMe, etc. , pero tienes esta conexión de host.

Se puede argumentar que la conexión de host es el equivalente a una reserva persistente o una relación persistente. Porque cada vez que apaga su centro de datos y lo reinicia, vuelve.

Si se tiene en cuenta lo que sucede con Kubernetes, si se tiene un entorno complejo con muchas aplicaciones heredadas, ¿cómo reclaman esas aplicaciones las clases de almacenamiento?

porque: Yo diría que todavía usa Portworx o algo parecido para administrar sus aplicaciones basadas en contenedores.

¿Y las aplicaciones no basadas en contenedores?

porque: Las aplicaciones no basadas en contenedores tienen, por ejemplo, una base de datos que consta de cinco volúmenes. Habría una configuración de conexión persistente en la configuración del arreglo para conectar estos volúmenes a este host.

Una de las cosas que Fusion tiende a hacer y que sería diferente (volviendo a lo que decía sobre el equilibrio de las cosas) sería obtener el mejor uso de la flota; no se debe tomar una aplicación de alto rendimiento y ponerla en funcionamiento. todo en una sola matriz.

Debería tener esa aplicación de alto rendimiento distribuida en un grupo de arreglos, y debería tener aplicaciones de menor rendimiento también distribuidas en esos arreglos, de modo que obtenga un uso uniforme desde una perspectiva de actividad y un uso uniforme desde una perspectiva de capacidad.

En los viejos tiempos, antes de Fusion, si querías crear una nueva base de datos, esto era lo que hacías. Usted diría: “Necesito un volumen de registro, un volumen reutilizable y tres volúmenes de datos”, por ejemplo, y normalmente encontraría un arreglo que tuviera capacidad y rendimiento disponibles, crearía esos cinco volúmenes en el arreglo, y tal vez no crearía todos ellos perfectamente consistentes con todas las demás instancias de esa aplicación, y luego configurar una conexión desde esa matriz a los hosts que vamos a ejecutar en esta base de datos.

En el mundo Fusion, dirás: “Quiero estos cinco volúmenes para esta aplicación”. Puede tener una plantilla para la aplicación. O dirás: “Quiero estos cinco volúmenes y quiero que estos cuatro sean de clase A, y este volumen borrador quiero que sea de clase C porque no me importa hacer una copia de seguridad de la misma manera. “

Fusion irá y potencialmente los colocará en cinco matrices diferentes, porque Fusion buscará el espacio en su flota y luego creará una instancia del volumen y creará una instancia de la conexión. Y, por lo tanto, le permitirá hacerlo de una manera que obtenga una utilización mucho mejor de su flota y le brinde una consistencia mucho mayor. Creo que esos son los dos mayores beneficios.

Vuelvo a cuando quieres hacer un cambio y dices: “Necesito mejorar la protección contra el ransomware” o “Necesito mejorar mi copia de seguridad”. Cuando puedas razonar sobre tu entorno porque es más simple, tomarás una mejor decisión.

Y luego, por supuesto, cuando pueda implementarlo simplemente diciendo: “Quiero cambiar la definición de almacenamiento de clase A para que se realice una copia de seguridad cada cuatro horas en lugar de cada ocho horas y hacerlo en toda la flota”. Ése es un poder que la gente no tiene hoy.

Exit mobile version