NetApp Tech OnTap
     

Acelerar el acceso a los datos compartidos en los
clústeres de computación


Acceder a los datos compartidos es esencial para el rendimiento de los clústeres de computación actuales que ejecutan una amplia variedad de aplicaciones de negocio, científicas y de ingeniería. El protocolo más utilizado en el acceso a los datos compartidos, NFS, puede convertirse en un cuello de botella para los clústeres de computación más grandes, y a su vez puede sobrecargar los servidores de ficheros, los cuales representan el único punto de acceso de todos los ficheros en un sistema compartido.

Figura 1) Los servidores de ficheros NFS pueden convertirse en un cuello de botella a medida que crece el tamaño del clúster de computación. La latencia (L) aumenta hasta niveles inaceptables a medida que la tasa de transferencia (T) se aproxima a los límites del servidor.

Por desgracia, la mayoría de las soluciones disponibles para aumentar el rendimiento del acceso a datos compartidos son marcas registradas y no han obtenido el tipo de apoyo heterogéneo y la adopción generalizada que han logrado los protocolos estándar como NFS.

NFS paralelo es un nuevo protocolo (dentro de la especificación NFS versión 4.1) que resuelve el problema del cuello de botella en un único servidor, y se trata de la solución ideal para el acceso a los datos en paralelo. En este artículo, describiremos el funcionamiento de pNFS y el estado actual en el que se encuentra el protocolo.


Descripción de pNFS


El protocolo pNFS otorga a los clientes acceso directo a los ficheros segmentados a través de dos o más servidores de datos. Accediendo a varios servidores de datos en paralelo, los clientes obtienen una aceleración de I/O significativa. El protocolo pNFS ha sido diseñado para ofrecer un rendimiento superior que se adapte tanto al tipo de cliente como de fichero sin sacrificar la compatibilidad con el protocolo estándar NFS; los clientes sin la extensión pNFS aún pueden acceder a los datos.

La arquitectura de pNFS y los protocolos principales

La arquitectura de pNFS consta de tres componentes principales:
  • El servidor de metadatos (MDS) que controla el tráfico que no sea de datos. El servidor de metadatos es responsable de controlar los metadatos que describen dónde y cómo se almacena cada fichero.
  • Los servidores de datos, que almacenan los datos de los ficheros y responden directamente a las peticiones de lectura y escritura del cliente. Los datos de los ficheros pueden segmentarse entre varios servidores de datos.
  • Uno o más clientes pueden acceder a los servidores de datos directamente basándose en la información de los metadatos recibida del servidor de metadatos.
Existen tres tipos de protocolos entre los clientes, el servidor de metadatos y los servidores de datos:
  • Se utiliza un protocolo de control entre el servidor de metadatos y los servidores de datos para proporcionar sincronización.
  • Se utiliza un protocolo pNFS entre los clientes y el servidor de metadatos. Se trata básicamente de un NFSv4 con algunas extensiones específicas de pNFS. Se emplea para recuperar y manipular los layouts de disposición. Estos layouts contienen los metadatos que describen la ubicación y el protocolo de acceso de almacenamiento necesario para acceder a los datos almacenados en varios servidores de datos.
  • Una serie de protocolos de acceso al almacenamiento empleado por los clientes para acceder directamente a los servidores de datos. La especificación pNFS dispone actualmente de tres categorías de protocolos de almacenamiento: los basados en ficheros, los basados en bloques y los basados en objetos. Esto permite al pNFS adaptarse a los diferentes layouts de disposición a fin de ser compatible con las diferentes clases de infraestructura de almacenamiento.

Tipos de layout

El protocolo de acceso a almacenamiento que se emplea depende del tipo de almacenamiento en los servidores de datos subyacentes. El layout que el servidor de metadatos envía a un cliente proporciona a dicho cliente la información necesaria para determinar dónde se almacenan los segmentos de un fichero, cómo acceder a él y con qué protocolo.

  • Cuando se utiliza el layout de ficheros, pNFS emplea varios servidores de ficheros NFSv4.1 como sus servidores de datos. El propio NFSv4 actúa como protocolo de acceso a los ficheros.
  • Cuando se utiliza el layout de bloques, los LUN del disco se alojan en una SAN. Se utiliza o bien el protocolo iSCSI o el Fibre Channel para acceder a los dispositivos SAN con la serie de comandos de bloque SCSI.
  • Con los layout de objetos, los datos se guardan en dispositivos de almacenamiento basados en objetos (OSD), y se accede a ellos a través del protocolo estandarizado de los dispositivos de almacenamiento basados en objetos T-10.
Ejemplo de acceso a los ficheros

Figura 2) Elementos de pNFS. Los clientes solicitan el layout al servidor de metadatos (1, protocolo pNFS) y luego acceden a los servidores de datos directamente (2, protocolo de acceso al almacenamiento).

Independientemente del tipo de layout, si un cliente quiere acceder a un fichero debe contactar con el servidor de metadatos a fin de abrir el fichero y solicitar cual es el layout empleado. Una vez que el cliente recibe el layout de ficheros, utiliza esa información para acceder directamente a los servidores de datos en paralelo, empleando el protocolo de acceso de almacenamiento apropiado sin involucrar al servidor de metadatos. Cuando el cliente finaliza el acceso, envía los metadatos modificados al servidor de metadatos y cierra el fichero.

La elección de un tipo de layout

He aquí algunos criterios que debe considerar cuando decida elegir un layout para pNFS:

Punto de inicio

  • Si empieza desde un entorno NAS, un layout de ficheros es la elección más lógica. Puede utilizar sus sistemas y redes NAS existentes.
  • Si posee una SAN de Fibre Channel, debería elegir un layout basado en bloques.
  • Si comienza desde cero, siga leyendo.

Infraestructura de red

  • Con un layout basado en ficheros, puede utilizar su almacenamiento NAS y su infraestructura de Ethernet actual. No tiene por qué añadir más ancho de banda.
  • Con un layout basado en objetos o bloques, lo más probable es que disponga de una red de área de almacenamiento (SAN) de Fibre Channel. Todos los clientes tendrán que conectarse a la SAN de FC para acceder a los servidores de datos directamente. El iSCSI puede ser una alternativa más barata.

Seguridad

  • Con un servidor basado en ficheros, cada servidor de datos se encarga de la seguridad con los mismos métodos que un servidor NFS estándar, como autenticación Kerberos y ACL, entre otros. De ese modo, los usuarios ya están familiarizados con la seguridad.
  • Gracias al pNFS con un servidor basado en objetos o bloques, buena parte de la carga de seguridad recae en la implementación del pNFS en los clientes. Y ya que el cliente forma parte del sistema operativo cliente, tal vez no tenga mucho control en la seguridad que proporciona (o no proporciona). En otras palabras, puede que no tenga mucha elección a la hora de elegir las implementaciones clientes, así que tal vez prefiera escoger un layout en el que los servidores de datos sean responsables de la seguridad.

Gestión y acceso con varios clientes

  • Con un layout basado en ficheros, dos clientes pNFS distintos pueden acceder a la misma región lógica del mismo fichero para propósitos de lectura o escritura.
  • Con el layout basado en objetos o bloques, solo un cliente pNFS a la vez puede mantener un layout de escritura en una zona de un fichero.

Disponibilidad de los bloques de construcción

  • Las fuentes disponibles para el almacenamiento en los servidores basados en objetos podrían ser limitadas.

Estado actual del pNFS


El protocolo pNFS

La norma NFSv4.1, de la que el protocolo pNFS forma parte, es un proyecto de base amplia del Organismo de Trabajo en Ingeniería de Internet (IETF). El grupo de trabajo cuenta con miembros de una extensa gama de investigadores y vendedores de sistemas y almacenamientos como NetApp, EMC, IBM, la Universidad de Michigan y Sun Microsystems. Los protocolos NFSv4.1 y pNFS están casi completos, y el IETF espera finalizar las especificaciones antes de finales de 2008.

NetApp ha sido uno de los impulsores principales tanto de NFSv4.1 como de pNFS, y ha apoyado en todo momento los esfuerzos del grupo de trabajo. Además, ha redactado y revisado buena parte de las especificaciones NFSv4.1. Es parte de nuestro compromiso de afrontar los problemas de almacenamiento empleando normas industriales.

Si desea más información sobre las especificaciones del IETF para NFSv4.1 y pNFS, visite la página Web del grupo de trabajo NFS v4 del IETF.

Pruebas de NFSv4.1/pNFS

Obviamente, la interoperatividad es un componente esencial para la adopción de pNFS, ya que lo era para NFS. Disponer de implementaciones de servidores y clientes que puedan funcionar juntas de forma transparente acelerarán la adopción. Se han estado ejecutando pruebas de interoperatividad de varias implementaciones pNFS desde marzo de 2005. NFSv4.1 y pNFS fueron probados en el Connectathon anual, un foro neutral de proveedores para realizar pruebas de interoperatividad de hardware y software.

Además, Bake-a-thons se celebra varias veces al año. La edición más reciente de Bake-a-thon tuvo lugar en septiembre de 2008. Se probaron seis implementaciones de servidores pNFS y dos en clientes. No se encontraron problemas ni en las especificaciones de NFSv4.1 ni en las de pNFS, por lo que, al parecer, los protocolos están evolucionando favorablemente. Puede revisar el estado actual de las pruebas de pNFS en el blog de NFS de Mike.

Desarrollo de servidores y clientes Linux

Debido al predominio de Linux® en los clústeres de computación empleados por muchas aplicaciones, tanto científicas como de ingeniería, que se benefician de pNFS, es importante disponer de un cliente pNFS comprobado y bien diseñado para Linux que satisfaga las necesidades de rendimiento de estas aplicaciones. NetApp y otras empresas han reconocido esta necesidad y están invirtiendo en la creación de un cliente pNFS de Linux fiable. A medida que evolucione este cliente, la implementación formará parte del núcleo principal de Linux. Esto permitirá que pueda utilizarse pNFS en un sistema Linux sin la necesidad de instalar software adicional.

NetApp está contribuyendo profundamente al desarrollo del controlador del layout de ficheros y del cliente pNFS, además de desarrollar un servidor para Linux. Disponer de un servidor pNFS simple junto con el cliente proporcionará a los usuarios que adopten pNFS una plataforma de experimentación, pruebas de concepto y familiarización.

Conclusión

A punto de convertirse en un protocolo reconocido, gozando del apoyo de la amplia mayoría de los proveedores y con la capacidad de aprovecharse de la infraestructura de almacenamiento existente, pNFS tiene visos de convertirse en una norma de adopción mundial para la I/O paralela de alto rendimiento, capaz de satisfacer las necesidades de las aplicaciones que precisen de un mayor rendimiento de I/O del que pueda proporcionar un solo servidor de ficheros.

¿Qué opina sobre pNFS?

Haga preguntas, intercambie ideas y comparta sus opiniones en las comunidades online de NetApp.
Mike Eisler

Mike Eisler
Director técnico senior
NetApp

Mike es el jefe del departamento de desarrollo de NetApp para el protocolo NFS. Es el autor de las especificaciones NFSv4 y varias otras relacionadas con NFS y la seguridad. El primer contacto de Mike con NFS y NIS fue mientras trabajaba en Lachman Associates, Inc., donde era el encargado de modificar NFS y NIS para adoptarlos a las plataformas System V. Se unió a NetApp después de marcharse de Sun, donde era responsable de varios proyectos relacionados con NFS y la seguridad.

Joshua Konkle

Joshua Konkle
Divulgador técnico de aplicaciones NAS y de ingeniería
NetApp

Joshua defiende las tecnologías y soluciones que ayudan a los clientes a ser más productivos. Su historial incluye experiencia con UNIX® y Windows®, concretamente en materia de seguridad. Ha pronunciado discursos sobre temas relacionados con el almacenamiento y la seguridad en varias convenciones técnicas y mercantiles.

Investigue más