ES2881606T3

ES2881606T3 - Sistema de ficheros geográficamente distribuido que usa replicación de espacio de nombres coordinada

Info

Publication number: ES2881606T3
Application number: ES15773935T
Authority: ES
Inventors: Konstantin V Shvachko; Yeturu Aahlad; Jagane Sundar; Plamen Jeliazkov Jeliazkov
Original assignee: WANdisco Inc
Current assignee: Cirata Inc
Priority date: 2014-03-31
Filing date: 2015-03-04
Publication date: 2021-11-30
Anticipated expiration: 2035-03-04
Also published as: CA2938768C; EP3127018B1; US10795863B2; EP3127018A1; EP3127018A4; US20170193002A1; AU2015241457B2; WO2015153045A1; CA2938768A1; US20210042266A1; AU2015241457A1; US11853263B2

Abstract

Una agrupación de nodos que comprende dispositivos informáticos configurados para implementar un sistema de ficheros geográficamente distribuido único (802), comprendiendo la agrupación: un primer centro de datos (804), que comprende: una pluralidad de primeros dispositivos informáticos DataNode (824, 826, 828, 830), cada uno configurado para almacenar bloques de datos de ficheros de cliente; una pluralidad de primeros almacenamientos persistentes locales; una pluralidad de primeros dispositivos informáticos NameNode (810, 812, 814), cada uno configurado para almacenar un estado de un espacio de nombres de la agrupación y para actualizar el estado del espacio de nombres de la agrupación, en donde cada NameNode está configurado adicionalmente para almacenar el estado actualizado del espacio de nombres en un primer almacenamiento persistente local de la pluralidad de primeros almacenamientos persistentes locales; un segundo centro de datos (806) que está geográficamente remoto de y acoplado al primer centro de datos mediante una red de área extensa, comprendiendo el segundo centro de datos: una pluralidad de segundos dispositivos informáticos DataNode (832, 834, 836, 838), cada uno configurado para almacenar bloques de datos de ficheros de cliente; una pluralidad de segundos almacenamientos persistentes locales; una pluralidad de segundos dispositivos informáticos NameNode (816, 818, 820), cada uno configurado para almacenar el estado del espacio de nombres de la agrupación y para actualizar el estado del espacio de nombres de la agrupación, en donde cada NameNode está configurado adicionalmente para almacenar el estado actualizado del espacio de nombres en un segundo almacenamiento persistente local de la pluralidad de segundos almacenamientos persistentes locales; en donde el espacio de nombres de la agrupación comprende información de sistema de ficheros y metadatos de todos los bloques de datos almacenados por la pluralidad de primeros y segundos dispositivos informáticos DataNode, y en donde la pluralidad de primeros y segundos dispositivos informáticos NameNode están configurados para actualizar el estado del espacio de nombres de la agrupación en respuesta a que se escriban bloques de datos en la pluralidad de primeros y segundos dispositivos informáticos DataNode; y en donde la primera y la segunda pluralidad de dispositivos informáticos NameNode están configurados para coordinar la actualización del estado del espacio de nombres usando un motor de coordinación distribuido, en donde el motor de coordinación distribuido está configurado para: recibir propuestas de la primera y la segunda pluralidad de dispositivos informáticos NameNode, en respuesta a solicitudes de cliente, en donde las propuestas son solicitudes para actualizar el estado del espacio de nombres, y generar, en respuesta, una secuencia globalmente ordenada de acuerdos que corresponden a las propuestas recibidas, en donde la secuencia globalmente ordenada de acuerdos está ordenada por números de secuencia globales, en donde la secuencia globalmente ordenada de acuerdos especifica un orden con el que han de actualizar la pluralidad de primeros y segundos dispositivos informáticos NameNode su respectivo estado almacenado del espacio de nombres, en donde actualizar el estado del espacio de nombres comprende actualizar información de sistema de ficheros y metadatos de bloques de datos almacenados por la pluralidad de primeros y segundos dispositivos informáticos DataNode y en donde la pluralidad de primeros y segundos dispositivos informáticos NameNode están configurados para retardar actualizaciones en el estado del espacio de nombres hasta que dicha pluralidad de primeros y segundos dispositivos informáticos NameNode hayan recibido la secuencia ordenada de acuerdos desde el motor de coordinación distribuido.

Description

DESCRIPCIÓN

Sistema de ficheros geográficamente distribuido que usa replicación de espacio de nombres coordinada

Referencia cruzada a casos relacionados

La presente solicitud está relacionada con la materia objeto de las solicitudes de patente de Estados Unidos comúnmente asignadas y en trámite con la presente 14/013.948 presentada el 29 de agosto de 2013 y 14/041.894 presentada el 30 de septiembre de 2013. La presente solicitud también está relacionada con la materia objeto de la solicitud de patente de Estados Unidos comúnmente asignada y en trámite con la presente 12/069.986 presentada el 13 de febrero de 2008, que es una división de la solicitud de patente de Estados Unidos 11/329.996 presentada el 11 de enero de 2006, ahora la patente 8.364.633, patente que reivindica el beneficio de la solicitud de patente provisional de Estados Unidos 60/643.257 presentada el 12 de enero de 2005, de la solicitud provisional de Estados Unidos 60/643.258 presentada el 12 de enero de 2005 y de la solicitud de patente provisional de Estados Unidos 60/643.269 presentada el 12 de enero de 2005. Esta solicitud también está relacionada con la materia objeto de la solicitud de patente de Estados Unidos comúnmente asignada y en trámite con la presente 12/835.888 presentada el 15 de marzo de 2013 que reivindica después el beneficio de la solicitud provisional de Estados Unidos 61/746.867 presentada el 28 de diciembre de 2012 y que también está relacionada con la materia objeto de la solicitud de patente de Estados Unidos comúnmente asignada y en trámite con la presente 13/837.366 presentada el 15 de marzo de 2013 que reivindica el beneficio de la solicitud provisional de Estados Unidos 61/746.940 presentada el 28 de diciembre de 2012.

Técnica anterior reconocida: El documento US 2014/059310 A1 (VMWARE, INC.) se refiere a un sistema informático virtualizado para ejecutar una aplicación informática distribuida, tal como Hadoop, que proporciona replicación en un entorno de máquina virtual. El documento CN 103458044 A (UNIVERSIDAD DE BEIHANG) se refiere a la afiliación dinámica y asignación de funciones en un nodo replicado de un sistema informático distribuido basado en acuerdos. El documento US 2012/101991 A1 (SRIVAS, M. eT AL) se refiere a un sistema de ficheros distribuido compatible con mapeo y reducción (mapreduce) en donde se mantienen actualizaciones coherentes basadas en Apache Zookeeper. KONSTANTIN SHVACHKO ET AL: "The Hadoop Distributed File System", MASS STORAGE SYSTEMS AND TECHNOLOGIES (MSST), 2010 IEEE 26TH SYMPOSIUM ON, IEEE, PISCATAWAY, NJ, ESTADOS UNIDOS, 3 de mayo de 2010 (03-05-2010), páginas 1-10, XP031698650, se refiere al sistema de ficheros distribuido Hadoop que enseña cómo se mantienen las consistencias a través de los tres DataNode nominados por el NameNode en comunicación con el cliente en donde la arquitectura está organizada en una base de NameNode único por agrupación. BING LI ET AL: "Distributed metadata management scheme in cloud computing", PERVASIVE Co Mp UTING AND APPLICATIONS (ICPCA), 2011 6TH INTERNATIONAL CONFERENCE ON, IEEE, 26 de octubre de 2011 (26-10 2011), páginas 32-38, XP032076065, se refiere a la replicación de un espacio de nombres a través de los NameNode usando el algoritmo Paxos para la consistencia de replicación. DHRUBA BORTHAKUR ET AL: "Apache hadoop goes realtime at Facebook", PROCEEDINGS OF THE 2011 ACM SIGMOD INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA; 12-16 de junio de 2011; ATENAS, GRECIA, ACM, NUEVA YORK, NY, ESTADOS UNIDOS, 12 de junio de 2011 (12-06-2011), páginas 1071-1080, XP058003207, se refiere a la plataforma Apache Hadoop y HBase, creadas en Hadoop para soportar miles de millones de mensajes por día. La tecnología en el mismo realiza consistencia en un único centro de datos. Sin embargo, también se desvela en el mismo la capacidad para dar servicio a usuarios a través de múltiples centros de datos.

Antecedentes

El campo de las realizaciones desveladas en el presente documento incluye sistemas de ficheros distribuidos. En particular, se extraen realizaciones para un sistema de ficheros distribuido (y la funcionalidad posibilitada de esta manera) que usa NameNode distribuidos geográficamente y nodos de datos a través de una red de área extensa (WAN) que puede incluir, por ejemplo, Internet.

Sumario de la invención

De acuerdo con un primer aspecto de la invención, se proporciona una agrupación de nodos de acuerdo con la reivindicación 1. De acuerdo con un segundo aspecto de la invención, se proporciona un método de acuerdo con la reivindicación 9. Se definen características preferidas de la invención en las reivindicaciones dependientes adjuntas.

Breve descripción de los dibujos

La Figura 1 es un diagrama de una implementación de HDFS convencional.

La Figura 2 es un diagrama de un sistema de ficheros distribuido y aspectos de la actualización de los NameNode de consenso;

La Figura 3 es un diagrama que ilustra aspectos de un método de replicación de bloques y de la generación en un sistema de ficheros distribuido.

La Figura 4 es un diagrama que ilustra aspectos adicionales de replicación de bloques.

La Figura 5 es un diagrama que ilustra más aspectos adicionales de replicación de bloques.

La Figura 6 es un diagrama que ilustra una manera en la que pueden realizarse los identificadores de bloque para que sean únicos a través de los NameNode de consenso.

La Figura 7 es un diagrama de flujo de un método implementado por ordenador de la implementación de un sistema de ficheros distribuido que comprende una pluralidad de DataNode configurados para almacenar bloques de datos de ficheros de cliente, de acuerdo con una realización de la invención.

La Figura 8 es un diagrama de bloques de componentes de un sistema de ficheros distribuido que abarca una WAN, de acuerdo con una realización de la invención.

La Figura 9 es un diagrama de flujo de un método de acuerdo con una realización de la invención.

Descripción detallada

En la siguiente descripción, la arquitectura o arquitecturas descritas con referencia a las Figuras 1 a 6 no están de acuerdo con la invención reivindicada, sino que se presentan para fines de ilustración únicamente.

El espacio de nombres del sistema de ficheros distribuido Hadoop (HDFS) es una jerarquía de ficheros y directorios. Los ficheros y directorios se representan en el NameNode por inodos. Los inodos registran atributos como permisos, tiempos de modificación y acceso, espacio de nombres y cuotas de espacio de disco. El contenido del fichero se divide en bloques de datos grandes (normalmente de 128 MB), y cada bloque de datos del fichero se replica independientemente en múltiples DataNode (normalmente tres). El NameNode es el servicio de metadatos de HDFS, que es responsable de las operaciones del espacio de nombres. El NameNode mantiene el árbol de espacio de nombres y el mapeo de bloques a los DataNode. Es decir, el NameNode rastrea la ubicación de datos dentro de una agrupación de Hadoop y coordina accesos de cliente a la misma. Convencionalmente, cada agrupación tiene un único NameNode. La agrupación puede tener miles de DataNode y decenas de miles de clientes de HDFS por agrupación, ya que cada DataNode puede ejecutar múltiples tareas de aplicación concurrentemente. Los inodos y la lista de bloques de datos que definen los metadatos del sistema de nombres se denominan la imagen. NameNode mantiene toda la imagen del espacio de nombres en RAM. El registro persistente de la imagen se almacena en el sistema de ficheros nativo local del NameNode como un punto de comprobación más un registro diario que representa actualizaciones al espacio de nombres llevado a cabo desde que se realizó el punto de comprobación.

Un sistema distribuido está compuesto de diferentes componentes denominados nodos. Para mantener la consistencia del sistema, puede hacerse necesario coordinar diversos eventos distribuidos entre los nodos. La manera más sencilla para coordinar un evento particular que debe aprenderse de manera coherente por todos los nodos es elegir un único maestro designado y registrar ese evento en el maestro de modo que otros nodos puedan aprender el evento del maestro. Aunque sencillo, este enfoque carece de fiabilidad, ya que un fallo del único maestro detiene el progreso de todo el sistema. En reconocimiento de esto, y como se muestra en la Figura 1, las implementaciones de HDFS convencionales usan un NameNode activo 102 que se accede durante operaciones normales y un respaldo denominado el NameNode en reposo 104 que se usa como una migración tras error en caso de fallo del NameNode activo 102.

Como se muestra en la Figura 1, una agrupación de HDFS convencional opera como sigue. Cuando se solicita una actualización al espacio de nombres, tal como cuando un cliente de HDFS emite una solicitud de procedimiento remoto (RPC) para, por ejemplo, crear un fichero o un directorio, el NameNode activo 102, como se muestra en la Figura 1:

1. recibe la solicitud (por ejemplo, RPC) de un cliente;

2. aplica inmediatamente la actualización a su estado de memoria;

3. escribe la actualización como una transacción de registro diario en almacenamiento persistente compartido 106 (tal como un Almacenamiento Conectado a la Red (NAS) que comprende uno o más discos duros) y devuelve al cliente una notificación de éxito. El NameNode en espera 104 debe ahora actualizar su propio estado para mantener la coherencia con el NameNode activo 102. Con ese fin, el NameNode en espera 104

4. lee la transacción de registro diario desde el registro diario de transacciones 106, y

5. actualiza su propio estado

Sin embargo, se cree que esto es una solución subóptima. Por ejemplo, en este esquema, el registro diario de transacciones 106 mismo se vuelve el único punto de fallo. De hecho, tras la corrupción del registro diario de transacciones 106, el NameNode en espera 104 ya no puede asumir el mismo estado que el NameNode activo 102 y ya no es posible la migración tras error del NameNode activo al NameNode en espera.

Además, en las soluciones de Hadoop que soportan únicamente un NameNode activo por agrupación, los servidores en espera, como se ha indicado anteriormente, se mantienen normalmente en sincronización mediante dispositivos de Almacenamiento Conectado a la Red (NAS). Si el NameNode activo falla y el de en espera tiene que hacerse cargo, existe una posibilidad de pérdida de datos si aún no se ha escrito un cambio escrito en el NameNode activo en el NAS. El error del administrador durante la migración tras error puede conducir a pérdida de datos adicional. Además, si ocurre un fallo de red en el que el servidor activo no puede comunicarse con el servidor en espera, pero puede comunicarse con las otras máquinas en la agrupación, y el servidor en espera asume erróneamente que el servidor activo está muerto y se hace cargo de la función activa, entonces puede ocurrir una condición de red patológica conocida como "cerebro dividido", en la que dos nodos creen que son el NameNode activo, condición que puede conducir a corrupción de datos

Las funciones de los proponentes (procesos que hacen propuestas a los miembros), los aceptadores (procesos que votan sobre si debería acordarse una propuesta por los miembros) y aprendices (procesos en los miembros que aprenden de acuerdos que se han realizado) se definen en, por ejemplo, la implementación del algoritmo Paxos descrito en Lamport, L.: The Part-Time Parliament, ACM Transactions on Computer Systems 16, 2 (mayo de 1998), 133-169. De acuerdo con una realización, pueden configurarse múltiples nodos con cada una de las funciones. Un motor de coordinación (tal como el mostrado en 208 en la Figura 2) puede permitir que múltiples aprendices acuerden el orden de eventos enviados al motor mediante múltiples proponentes con la ayuda de múltiples aceptadores para conseguir una alta disponibilidad. Para conseguir fiabilidad, disponibilidad y escalabilidad, pueden proporcionarse múltiples NameNode simultáneamente activos, de acuerdo con una realización, replicando el estado del espacio de nombres en múltiples nodos con el requisito de que el estado de los nodos en los que se replica el espacio de nombres permanece coherente entre tales nodos.

Esta consistencia entre los NameNode puede garantizarse por el motor de coordinación, que puede configurarse para aceptar las propuestas para actualizar el espacio de nombres, simplificar las propuestas en una secuencia global de actualizaciones y únicamente a continuación permitir que los NameNode aprendan y apliquen las actualizaciones a sus estados individuales en el orden acordado. En el presente documento, "consistencia" significa equivalencia de una copia, como se detalla en Bernstein et al., "Concurrency Control & Recovery in Database Systems", publicado por Addison Wesley, 1987, capítulos 6, 7 y 8. Puesto que los NameNode empiezan desde el mismo estado y aplican las mismas actualizaciones deterministas en el mismo orden determinista, sus respectivos estados están y permanecen coherentes.

Por lo tanto, puede replicarse el espacio de nombres en múltiples NameNode, con la condición de que

a) cada nodo esté permitido a modificar su réplica de espacio de nombres, y

b) actualice una réplica de espacio de nombres que debe propagarse a las réplicas de espacio de nombres en otros nodos de manera que las réplicas de espacio de nombres permanecen coherentes entre sí, a través de los nodos.

I. Sistema de ficheros distribuido en una red de área local (LAN)

Por lo tanto, un ejemplo elimina el único punto de fallo más problemático que impacta en la disponibilidad, el único NameNode. Convencionalmente, si el único NameNode deja de estar disponible, la agrupación de Hadoop está caída y se requieren procedimientos de migración tras error complejos (tales como la conmutación de un NameNode previamente activo a un NameNode en espera) para restaurar el acceso. Para tratar este único punto de fallo potencial, una realización posibilita múltiples servidores de NameNode activos (en el presente documento indicados de manera diversa como nodo de consenso (ConsensusNode) o CNode) para actuar como pares, cada uno sincronizado de manera continua y proporcionando de manera simultánea acceso de cliente, que incluye acceso para aplicaciones por lotes que usan mapeo y reducción y aplicaciones en tiempo real que usan HBase. De acuerdo con una realización, cuando falla un servidor de NameNode o se lleva fuera de línea para su mantenimiento o por cualquier otra razón por un usuario, siempre están disponibles otros servidores de NameNode activos, lo que significa que no hay interrupción en el acceso de lectura y escritura a los metadatos de HDFS. Tan pronto como este servidor vuelve a estar en línea, su NameNode se recupera automáticamente, se le informa de cualquier nuevo cambio al espacio de nombres que puede haber ocurrido en el ínterin y sincroniza su espacio de nombres para que coincida con el espacio de nombres de todos los otros NameNode en la agrupación. Será coherente con las otras réplicas a medida que aprende de los cambios en el mismo orden determinista que los otros nodos aprendieron de los cambios.

La Figura 2 es un diagrama de un sistema de ficheros distribuido y los aspectos de la actualización del nodo de consenso que hallan utilidad particular en el entorno de LAN. En lugar de un único NameNode activo y un NameNode en espera, una agrupación puede comprender una pluralidad (preferentemente impar) de (por ejemplo, 3, 5, 7...) NameNode que están coordinados por un motor de coordinación 208. Como se ha indicado anteriormente, en el presente documento, un NameNode coordinado se denomina un nodo de consenso o, en lo sucesivo, CNode. Como se muestra en la Figura 2, un ejemplo puede comprender tres CNode 202, 204, 206, cada uno acoplado al motor de coordinación 208. El motor de coordinación 208 puede estar configurado como un agente en cada nodo, coordinándose los agentes entre sí a través de una red. Sin embargo, para facilidad de referencia y representación, se muestra el motor de coordinación 208 en las Figuras 2 y 4 como una única entidad separada. Las actualizaciones al espacio de nombres, iniciadas en una instancia del NameNode 202, 204 o 206, se propagan a las otras instancias de una manera coherente por medio del motor de coordinación 208. De esta manera, los clientes acceden a un espacio de nombres coherente a través de todas las instancias del NameNode. Los métodos de replicación desvelados en el presente documento proporcionan un modelo activo-activo de alta disponibilidad para un sistema de ficheros distribuido tal como h DfS, en el que las solicitudes de metadatos (lectura o escritura) pueden estar equilibradas en carga entre múltiples instancias del NameNode.

El motor de coordinación 208 puede estar configurado para determinar el orden global de actualizaciones del espacio de nombres. Como todas las instancias del espacio de nombres comienzan en el mismo estado y como todos los nodos se hace que apliquen actualizaciones en el mismo orden determinista (pero no necesariamente al mismo tiempo), el estado de las múltiples instancias del espacio de nombres permanecerá coherente (o se llevará a consistencia) a través de los nodos.

Como se muestra en la Figura 2, las actualizaciones coherentes de las múltiples réplicas de CNode 202, 204, 206 pueden llevarse a cabo como sigue. Como se muestra en (1), uno de los CNode (en este caso, el CNode 202) recibe una solicitud para actualizar el espacio de nombres de un cliente. Una actualización de espacio de nombres de este tipo puede comprender un RPC, identificado en la Figura 2 como el RPC 3. De manera similar, en este ejemplo, el CNode 204 recibe el RPC 1 y el CNode 206 recibe el RPC 2. Los RPC pueden comprender una solicitud para añadir bloques de datos a un fichero, crear un fichero o crear un directorio, por ejemplo. En lugar de actualizar inmediatamente el CNode 202 su estado con el evento (por ejemplo, leer, escribir, borrar, etc.) encapsulado en el RPC 3, actualizar inmediatamente el CNode 204 su estado con el evento encapsulado dentro del RPC 1 recibido y actualizar inmediatamente el CNode 206 su estado con el evento encapsulado dentro del RPC 2 recibido, y a continuación propagar los espacios de nombres actualizados a los otros de los CNode 202, 204, 206, estas actualizaciones separadas a las réplicas de espacio de nombres en los CNode se pasan en su lugar como propuestas al motor de coordinación 208, que a continuación emite correspondientes acuerdos a los CNode 202, 204, 206. De hecho, el mecanismo mediante el cual las réplicas de espacio de nombres almacenadas por los CNode 202, 204, 206 se mantienen coherentes es emitiendo propuestas a y recibiendo acuerdos del motor de coordinación 208. Es decir, como se muestra en la Figura 2, en respuesta a la recepción del RPC 3, el CNode 202 puede emitir una propuesta Prop3 al motor de coordinación 208 como se muestra en (2). De manera similar, en respuesta a la recepción de RPC 1, el CNode 204 puede emitir una propuesta Prop1 al motor de coordinación 208 como se muestra en (2) y en respuesta a la recepción de RPC 2, el CNode 206 puede emitir una propuesta Prop2 al motor de coordinación 208 como se muestra en (2). El motor de coordinación 208 a continuación ordena las propuestas que recibe como se muestra en (3) y alimenta los acuerdos ordenados (en este caso, ordenados como AGR3, AGR1 y AGR2) de vuelta a los CNode 202, 204, 206, como se muestra en (4). Los CNode 202, 204 y 206, tras la recepción de la secuencia ordenada de acuerdos AGR3, AGR1 y AGR2, aplican estos acuerdos a sus respectivos estados de memoria en ese orden determinista, de modo que las réplicas de espacio de nombres pueden mantenerse coherentes a través de los CNode 202, 204, 206. De esta manera, el estado de los CNode 202, 204, 206 puede actualizarse de manera asíncrona, como se muestra en (5) sin pérdida de consistencia. Estas actualizaciones pueden a continuación guardarse (pero no necesariamente) como transacciones de registro diario en respectivo almacenamiento persistente local 210, 212, 214 que puede acoplarse (pero no necesariamente, como se indica por las líneas discontinuas en 210, 212 y 214) o ser accesible a los CNode 202, 204, 206. A continuación, pueden devolverse las notificaciones a los clientes del CNode 202, 204, 206, que informan a los clientes del éxito de la actualización.

Por lo tanto, los CNode 202, 204, 206 no aplican directamente solicitudes de cliente a sus respectivos estados, sino que, en su lugar, las redirigen como propuestas al motor de coordinación 208 para su ordenación. Las actualizaciones a los CNode a continuación se emiten desde el motor de coordinación 208 como un conjunto ordenado de acuerdos. Esto garantiza que cada CNode 202, 204, 206 se actualiza cuando el cliente solicita cambios desde uno de ellos, y que las actualizaciones se aplicarán de manera transparente y coherente a todos los CNode en la agrupación.

Por ejemplo, si un cliente crea un directorio mediante el CNode 202, y a continuación intenta listar el directorio recién creado mediante el CNode 204, el CNode 204 puede devolver una excepción de "fichero no encontrado". De manera similar, un cliente puede leer diferente número de bytes del último bloque de datos de un fichero que está bajo construcción puesto que las réplicas del mismo bloque en diferentes DataNode tienen diferentes longitudes mientras que los datos están en transición desde un DataNode a otro, como se detalla a continuación con relación a la Figura 3. Esto es conocido como un problema de "lectura obsoleta".

Por lo tanto, una función significativa del motor de coordinación 208 es procesar las propuestas de modificación del estado del espacio de nombres desde todos los CNode y transformarlas en la secuencia global ordenada de acuerdos. Los CNode pueden a continuación aplicar los acuerdos desde esa secuencia ordenada como actualizaciones a su estado. Los acuerdos pueden ordenarse de acuerdo con un número de secuencia global (GSN), que puede configurarse como un número creciente monótonamente único. El GSN puede configurarse de otra manera, como reconocerán los expertos en esta materia. El GSN puede usarse a continuación para comparar el progreso de diferentes CNode al actualizar el estado del espacio de nombres y manteniendo ese estado de espacio de nombres coherente a través de los CNode. Por ejemplo, si el CNode 202 acaba de procesar un acuerdo numerado GSN1, que es menor que el GSN2 recién procesado por el CNode 204, entonces el CNode 202 tiene un estado de espacio de nombres más anterior que el CNode 204.

Con cada operación, los clientes aprenden acerca del último GSN procesado en el CNode al que está conectado actualmente el cliente. Posteriormente, si el cliente conmuta a otro CNode debería esperar en primer lugar (si fuera necesario) hasta que el nuevo CNode capture el último GSN acerca del que el cliente conoce (es decir, el GSN que el cliente recibió desde el CNode previamente accedido) antes de emitir un RPC que comprende un comando de acceso de datos. Esto evitará el problema de lectura obsoleta.

Únicamente necesitan coordinarse las operaciones que actualizan el estado del espacio de nombres por el motor de coordinación 208. Es decir, la mayoría (sino todas) las solicitudes de lectura pueden ser servidas directamente por cualquiera de los CNode a los que está conectado el cliente, ya que las solicitudes de lectura no modifican el estado del espacio de nombres. Se ha de observar que, el motor de coordinación 208 no garantiza que todos los CNode 202, 204, 206 tengan el mismo estado en cualquier momento dado. En su lugar, el motor de coordinación 208 garantiza que cada CNode 202, 204, 206 aprenderá de manera coherente acerca de cada actualización en el mismo orden que todos los demás CNode, y que los clientes podrán observar esta información. De esta manera, el motor de coordinación 208 está configurado para generar una secuencia de eventos globalmente ordenada que se suministra de manera idéntica a todos los CNode 202, 204, 206.

Pueden llevarse a cabo actualizaciones de registro diario al almacenamiento persistente local 210, 212, 214. Sin embargo, la consistencia de los CNode 202, 204, 206 no depende de tales actualizaciones de registro diario y cada uno de los almacenamientos persistentes (si están presentes) es local a un CNode y no se comparte a través de los CNode. De manera similar, mantener la consistencia del estado de espacio de nombres a través de los CNode 202, 204, 206 no se basa en compartir otros recursos, tales como recursos de memoria o de procesador.

No hay CNode preferido (maestro o distinguido de otra manera). De hecho, si fallara uno o más servidores de CNode, o se pusieran fuera de línea para mantenimiento (o por cualquier otra razón), otros servidores de CNode activos siempre están disponibles para dar servicio a clientes sin interrupción alguna en el acceso. Tan pronto como el servidor vuelve a estar en línea, resincroniza con los otros servidores de CNode automáticamente, como se describe a continuación. Tal sincronización puede comprender el aprendizaje de todos los acuerdos que se emitieron por el motor de coordinación 208 desde que se cayó o se llevó fuera de línea el CNode. Se elimina tanto la condición de cerebro dividido como de la pérdida de datos, ya que todos los CNode están activos y siempre mantenidos en o llevados a sincronismo, proporcionando de esta manera respaldo en caliente continuo por defecto. Tanto la migración tras error como la recuperación son inmediatas y automáticas, lo que elimina adicionalmente la necesidad de la intervención manual y el riesgo del error del administrador. Además, ninguno de los CNode 202, 204, 206 está configurado como un NameNode en reposo pasivo. De hecho, todos los servidores de CNode en la agrupación están configurados para soportar solicitudes de cliente simultáneas. En consecuencia, esto posibilita que se escale la agrupación para soportar servidores de CNode adicionales, sin sacrificar el rendimiento a medida que aumenta la carga de trabajo. No hay servidores en espera pasivos y se eliminan completamente las vulnerabilidades y el cuello de botella de un único servidor de NameNode activo. Además, distribuir solicitudes de cliente a través de múltiples CNode 202, 204, 206 distribuye inherentemente la carga de procesamiento y el tráfico a través de todos los CNode disponibles. También puede llevarse a cabo un equilibrio de carga activo a través de los CNode 202, 204, 206, en comparación con el paradigma de NameNode activo/en reposo, en el que todas las solicitudes de cliente son servidas por un único NameNode.

La Figura 3 es un diagrama que ilustra aspectos de un método de replicación de bloques y de la generación en un sistema de ficheros distribuido. En 350, la Figura 3 muestra un fichero que va a almacenarse en HDFS. La unidad de almacenamiento puede denominarse un bloque y el tamaño de bloque puede ser bastante grande. Por ejemplo, el tamaño de bloque puede ser de 128 MB de almacenamiento físico. Pueden implementarse fácilmente otros tamaños de bloque. Se muestra el fichero 350 en la Figura 3 como que comprende una pluralidad de bloques de datos de 128 MB. El tamaño de bloque no necesita ser de 128 MB. Puede recopilarse cada bloque de datos de un fichero (es decir, almacenarse idénticamente) en una pluralidad de DataNode. Se muestran tales DataNode en 302, 304 y 306 y están configurados para acoplarse a uno o más CNode, tal como el CNode 202. Cada DataNode puede estar configurado para comunicarse con cada uno de los CNode en la agrupación. Pueden almacenarse bloques de datos de ficheros en un mayor número de DataNode, tal como en 5 o 7 DataNode. Almacenar cada bloque de datos en múltiples DataNode proporciona fiabilidad de datos a través de la redundancia.

Como se muestra en la Figura 2, un cliente envía un mensaje (por ejemplo, un RPC) al CNode 202, que indica la intención del cliente para crear un fichero y escribir un bloque de datos en el fichero. El CNode 202 puede a continuación seleccionar múltiples DataNode (tres en esta implementación ilustrativa) 302, 304 y 306, a los que replicará el bloque de datos de este fichero recién creado, y, así, informa al cliente. El cliente puede a continuación enviar por flujo continuo (o enviar de otra manera) datos a uno seleccionado de los tres DataNode 302, 304 y 306. Tal envío por flujo continuo puede llevarse a cabo enviando en al DataNode seleccionado (el DataNode 302, por ejemplo) segmentos pequeños de cada bloque de datos. Por ejemplo, el cliente puede enviar al DataNode 302 un flujo en serie de 64 KB segmentos del primer bloque de datos del fichero, hasta que se haya transmitido satisfactoriamente el primer bloque de datos del fichero al DataNode 302. La toma de contacto entre el cliente y el DataNode seleccionado 302 puede garantizar que cada bloque de datos se recibe y almacena satisfactoriamente por el DataNode seleccionado 302. Los segmentos de datos enviados al primer DataNode 302 pueden comprender también una indicación del segundo DataNode 304 al que han de enviarse los bloques de datos del fichero del cliente. En lugar de que envíe el cliente los bloques de datos del fichero directamente a los tres (o más) DataNode seleccionados por el CNode 202 para recibir réplicas de los bloques de datos del fichero, el primer DataNode 302, que acaba de recibir un segmento de datos del bloque, puede a continuación por sí mismo enviar el segmento de datos recibido al siguiente (por ejemplo, el DataNode 304) de los tres DataNode para recibir los bloques de datos del fichero. De manera similar, después de que el DataNode 304 ha recibido satisfactoriamente el segmento de datos enviado a él por el DataNode 302, puede a continuación enviar el segmento de datos al último de los tres DataNode seleccionados por el CNode 202 para recibir réplicas de los bloques de datos constituyentes del fichero del cliente. De esta manera, se crea una canalización de segmentos de datos, en la que un primer DataNode seleccionado por el CNode reenvía segmentos de datos al segundo DataNode seleccionado por el CNode y en la que el segundo DataNode reenvía segmentos de datos que ha recibido al tercer DataNode seleccionado por el CNode para recibir réplicas del bloque de datos del fichero (y así sucesivamente, si más de tres DataNode van a recibir el bloque del fichero).

El CNode no asume que los DataNode que ha seleccionado como receptores de los bloques de datos constituyentes del fichero del cliente han recibido, de hecho, satisfactoriamente y almacenado los bloques de datos. En su lugar, una vez en posesión de uno o más bloques de datos del fichero del cliente, los DataNode 302, 304, 306 pueden informar de vuelta al CNode 202 que ahora almacenan una réplica del bloque de datos que se les ha enviado por el cliente directamente o por otros DataNode, como se muestra en la Figura 3. Al menos alguno (y posiblemente cada uno) de los DataNode puede emitir periódicamente un mensaje de "indicación de funcionamiento" a los CNode, mensaje de indicación de funcionamiento que puede estar configurado para informar a los CNode que el DataNode emisor está aún activo y en buen estado (es decir, puede dar servicio a solicitudes de acceso de datos de clientes). Los DataNode pueden informar la recepción satisfactoria y el almacenamiento de uno o más bloques de datos del fichero del cliente como otro mensaje al CNode. En la situación ilustrativa representada en la Figura 3, los DataNode 302, 304, 306 pueden informar al CNode 202 que han recibido satisfactoriamente y almacenado uno o más de los bloques de datos del fichero del cliente al CNode 202.

Los DataNode pueden fallar. Si ese fallo se provoca por una interrupción en el canal de comunicación entre el DataNode y el CNode, el fallo de un servidor de ficheros o el fallo del almacenamiento físico subyacente (o cualquier otro fallo), tal fallo significa que los bloques de datos pueden no estar disponibles, al menos desde el DataNode fallido. En el ejemplo mostrado en la Figura 4, el DataNode 306 ha fallado. Los CNode 202, 204, 206 pueden no ser informados inmediatamente de este estado cambiado del DataNode 306. En su lugar, el mecanismo de mensaje de indicación de funcionamiento anteriormente descrito puede usarse para un buen aprovechamiento para mantener a los CNode informados del estado casi actual (como del último indicador de funcionamiento) de cada uno de los DataNode. Es decir, se interpreta el fallo de los CNode para recibir un mensaje de indicación de funcionamiento dentro de un periodo de tiempo predeterminado, por los CNode, como un fallo del DataNode que no envía un indicador de funcionamiento. Ese periodo de tiempo predeterminado puede establecerse, por ejemplo, a un periodo de tiempo que es mayor que el intervalo esperado entre mensajes de indicación de funcionamiento de cualquier DataNode único.

En el ejemplo de la Figura 4, el DataNode 306 ha fallado al enviar un mensaje de indicación de funcionamiento ("HB" en la Figura 3) dentro del intervalo de tiempo predeterminado desde su último indicador de funcionamiento y, puede considerarse, por lo tanto, que ha fallado y que sus bloques de datos almacenados son inaccesibles, al menos por el momento. A su vez, esto significa que únicamente los DataNode 302 y 304 almacenan los bloques de datos de diferentes ficheros. Los CNode pueden mantener una lista de DataNode que están actualmente activos y listos para aceptar nuevos bloques de datos y/o dar servicio a solicitudes de acceso de datos. Una lista de este tipo puede denominarse una lista "activa". Tras el fallo al recibir un mensaje de actividad esperado de un DataNode, tal como el DataNode 306 en la Figura 4, el DataNode puede considerarse que ha fallado y los CNode pueden eliminar el DataNode fallido de la lista activa. La lista activa puede ser esa lista a partir de la cual el CNode, que ha recibido una solicitud de un cliente para crear un bloque, puede seleccionar (por ejemplo) los tres DataNode en los que se almacenará el bloque de datos del fichero que va a crearse. Como el DataNode 306 ha fallado, el DataNode 306 puede eliminarse de la lista activa, haciendo que el DataNode, para todos los propósitos, no exista de manera efectiva y no esté disponible, al menos desde el punto de vista de los CNode.

Como los bloques de datos del fichero del cliente están infra-replicados (por ejemplo, almacenados en menos del número predeterminado de DataNode) debido al fallo del DataNode 306, el CNode 202 puede ahora seleccionar un nuevo DataNode al que pueden replicarse los bloques de datos del fichero del cliente, para garantizar que un complemento completo de tres DataNode almacenan réplicas de los bloques de datos constituyentes del fichero. El CNode 202 puede consultar la lista activa y seleccionar, de la lista, un nuevo DataNode al que se replicarán los bloques de datos del fichero del cliente, para proporcionar el complemento de los DataNode que almacenan réplicas de los bloques de datos del fichero del cliente hasta tres (o cuatro, cinco, etc., dependiendo del factor de replicación asignado al fichero). En el ejemplo mostrado en la Figura 4, el CNode 202 ha seleccionado el DataNode 402 como el del DataNode en el que se almacenarán también las réplicas del bloque de datos, para curar la infra-replicación del bloque de datos. El CNode 202 puede seleccionar también el DataNode 304 que enviará la réplica en su posesión al DataNode seleccionado 402. Como se muestra en 406 en la Figura 4, el DataNode seleccionado 304 puede a continuación comenzar a enviar por flujo continuo segmentos de datos de la réplica del bloque o enviar de otra manera la réplica del bloque al DataNode recién seleccionado 402. A media que el DataNode recién seleccionado 402 recibe la réplica de bloque y llega el momento de que el DataNode 406 informe a los CNode, puede informar que ahora almacena réplicas de los bloques recién recibidos. Los CNode pueden cambiar el espacio de nombres para reflejar este cambio. El DataNode de recepción puede seleccionarse por el CNode 202 aleatoriamente. Tal selección puede hacerse de acuerdo con un criterio de selección predeterminado.

Cada uno de los CNode 202, 204, 206 tiene "conocimiento" de cada uno de los DataNode 302, 304, 306, 402 y todos los otros (potencialmente miles) DataNode cuyos indicadores de funcionamiento reciben periódicamente. Tras el fallo de un DataNode, más de un CNode podría decidir seleccionar un DataNode como un DataNode de envío y otro DataNode como el receptor de las réplicas de bloque, para garantizar a continuación que los bloques no están infrareplicados. Esto podría dar como resultado que múltiples CNode seleccionen múltiples DataNode de remplazo para almacenar los bloques de datos previamente almacenados por un DataNode fallido. A su vez, tales acciones paralelas pueden dar como resultado bloques que estén sobre-replicados (por ejemplo, replicados más de las 3, 4, 5... instancias de los mismos pretendidas). Tal sobre-replicación puede ocurrir también cuando, como se muestra en la Figura 5, un DataNode previamente fallido o inaccesible de otra manera vuelva a estar en línea. En la Figura 5, se supone que el DataNode 306 previamente fallido o inaccesible ahora está de nuevo operativo y accesible para los CNode 202, 204, 206. En este estado, los bloques del fichero del cliente se presentan ahora en cuatro DataNode; en concreto, los nodos originales 302, 304, el DataNode recién añadido 402 y el DataNode no operacional y accesible 306. Por lo tanto, los bloques de datos del fichero del cliente están sobre-replicados. Como el estado de vuelta en línea del DataNode 3 es conocido ahora para todos los CNode 202, 204, 206 (puesto que cada uno recibió un indicador de funcionamiento del DataNode revivido 306), es concebible que más de un CNode 202, 204, 206 pueda seleccionar independientemente un DataNode a partir del que borrar réplicas de bloque del fichero del cliente. Esta selección independiente puede hacer que las réplicas de bloque del fichero del cliente vayan desde un estado sobre-replicado a un estado infrareplicado o, en el peor caso, incluso se borren de todos los DataNode.

Para evitar tales ocurrencias, pueden reservarse las tareas de replicación de bloques para un único CNode seleccionado o elegido en cualquier momento dado, el CNode replicador de bloques. Tales tareas de replicación de bloques pueden comprender la coordinación de replicación de bloques (es decir, dar instrucción a bloques para que se copien entre los DataNode) y borrados de bloque. La funcionalidad de la generación de bloques no plantea tales riesgos inherentes de pérdida de datos o sobre-replicación y, por lo tanto, puede pertenecer a cada CNode de la agrupación. Por lo tanto, todos los CNode pueden configurarse para llevar a cabo labores de gestión de bloque. Sin embargo, tales labores de gestión de bloque pueden dividirse en labores de replicación y borrado de bloque que se reservan para un único CNode seleccionado, y labores de generación de bloque, que pueden pertenecer a cada uno de los CNode de una agrupación. Esto se muestra en la Figura 5, en la que se ha seleccionado el CNode 202 como el único CNode configurado con una función de replicador de bloques 410, para posibilitar que únicamente un CNode 202 haga que se copien y/o borren bloques de datos de los DataNode. En contraste, y como se muestra en la Figura 5, cada uno de los CNode 202, 204, 206 puede configurarse para llevar a cabo funciones del generador de bloques 408, 412 y 414, respectivamente, posibilitando que cualquiera de los CNode 202, 204 y 206 genere bloques o posibilite que se almacenen nuevos bloques de datos en los DataNode seleccionados que le informan.

Cada DataNode puede configurarse para enviar todas las comunicaciones a todos los CNode en la agrupación. Es decir, cada DataNode que funciona activo puede configurarse para enviar indicadores de funcionamiento, informes de bloque y mensajes acerca de réplicas recibidas o borradas, etc., independientemente a cada CNode de la agrupación.

En la implementación actual de HDFS, los DataNode únicamente reconocen un único NameNode activo. A su vez, esto significa que los DataNode ignorarán cualquier comando de DataNode que provenga de un NameNode no activo. Convencionalmente, si un NameNode no activo reivindica que ahora es el NameNode activo, y confirma tal estado con un txId superior, el DataNode realizará un procedimiento de migración tras error, conmutando a un nuevo NameNode activo y aceptando únicamente comandos de DataNode del nuevo NameNode activo.

Para adaptar este método de operación en las agrupaciones de CNode, únicamente el CNode que tiene labores de replicador de bloques (es decir, el replicador de bloques actual) informa su estado como que está activo a los DataNode. Esto garantiza que únicamente el replicador de bloques tiene la capacidad para ordenar que los DataNode repliquen o borren réplicas de bloque.

Las aplicaciones acceden a HDFS mediante clientes de HDFS. Convencionalmente, un cliente de HDFS entraría en contacto con el único NameNode activo para metadatos de fichero y, a continuación, accedería a datos directamente desde los DataNode. De hecho, en la implementación actual de HDFS, el cliente siempre habla al único NameNode activo. Si se posibilita Alta Disponibilidad (HA), el NameNode activo puede migrar tras error a un nodo en espera. Cuando eso ocurre, el cliente de HDFS se comunica con el NameNode recién activo (previamente, el nodo en espera) hasta que tenga lugar otra migración tras error. La migración tras error se maneja mediante una interfaz conectable (por ejemplo, proveedor de intermediario de migración tras error), que puede tener diferentes implementaciones.

Sin embargo, los CNode están todos activos en todo momento y pueden usarse igualmente para dar servicio de información de espacio de nombres a los clientes. Los clientes de HDFS pueden configurarse para comunicarse con los CNode mediante una interfaz de intermediario denominada, por ejemplo, intermediario de CNode. El intermediario de CNode puede configurarse para seleccionar aleatoriamente un CNode y para abrir un conector de comunicación para enviar las solicitudes de RPC del cliente a este CNode seleccionado aleatoriamente. El cliente a continuación envía únicamente solicitudes de RPC a este CNode hasta que tiene lugar un agotamiento de tiempo de espera de comunicación o un fallo. El agotamiento de tiempo de espera de comunicación puede ser configurable. Cuando se agota el tiempo de espera de comunicación, el cliente puede conmutar a otro CNode (por ejemplo, seleccionado aleatoriamente por el intermediario de CNode), abrir un conector de comunicación a este nuevo CNode y enviar las solicitudes de RPC del cliente únicamente a este nuevo CNode seleccionado aleatoriamente. Para propósitos de equilibrio de carga, por ejemplo, este agotamiento de tiempo de espera de comunicación puede establecerse a un valor bajo. De hecho, si el CNode al que el cliente envía sus solicitudes de RPC está ocupado, el retardo al responder puede ser mayor que el valor bajo del tiempo de espera de la comunicación, desencadenando de esta manera que el cliente conmute, mediante el intermediario de CNode, el CNode con el que se comunicará.

De hecho, la selección aleatoria de un CNode por clientes de HDFS posibilita el equilibrio de carga de múltiples clientes que se comunican con los CNode replicados. Una vez que el intermediario de CNode ha seleccionado aleatoriamente el CNode con el que se comunicará el cliente, ese cliente puede "adherirse" a ese CNode hasta que se agote el tiempo o falle el CNode seleccionado aleatoriamente. Esta "adherencia" al mismo CNode reduce la posibilidad de lecturas obsoletas, anteriormente analizadas, únicamente en el caso de migración tras error. El intermediario del intermediario de CNode puede configurarse para no seleccionar CNode que están en modo seguro, tal como puede ocurrir cuando se está reiniciando el CNode y no está completamente listo para dar servicio aún (por ejemplo, está aprendiendo los acuerdos que puede haber perdido durante su tiempo de inactividad).

El problema de la lectura obsoleta, anteriormente analizado, puede ilustrarse adicionalmente a través de un ejemplo. Por ejemplo, si un cliente crea un directorio mediante el CNodel y a continuación el mismo u otro cliente intenta listar el directorio recién creado mediante el CNode2, el CNode2 puede estar detrás en su proceso de aprendizaje y puede devolver una excepción de fichero no encontrado puesto que no ha recibido o procesado aún el acuerdo para crear el directorio. De manera similar, un cliente puede leer diferente número de bytes del último bloque de un fichero que está bajo construcción puesto que las réplicas del mismo bloque en diferentes DataNode pueden tener diferentes longitudes mientas los datos están en transición.

El problema de la lectura obsoleta puede manifestarse en sí mismo en dos casos:

1. Un mismo cliente conmuta a (debido a fallo, interrupción intencionada o para propósitos de equilibrio de carga, por ejemplo) un nuevo CNode, que tiene un estado de espacio de nombres más antiguo, y

2. Un cliente modifica el espacio de nombres, que necesita ser observado por otros clientes.

El primer caso puede evitarse, haciendo que la interfaz de intermediario del intermediario de CNode tenga conocimiento del GSN del CNode al que está conectado. Con cada operación, el cliente de HDFS aprende acerca del GSN en el CNode. Cuando el cliente conmuta a otro CNode (por ejemplo, debido a fallo del CNode, tiempo de espera agotado o un apagado deliberado de ese CNode por cualquier razón, el cliente, a través del intermediario de CNode, debe elegir un CNode con el GSN, que no es menor de lo que ya había observado, o esperar hasta que el nuevo CNode capture el último GSN que recibió el cliente desde el CNode anterior.

El segundo caso surge cuando se inicia un trabajo de mapeo y reducción. En este caso, un cliente de mapeo y reducción pone los ficheros de configuración de trabajo, tal como job.xml en HDFS, que, a continuación, se leen por todas las tareas ejecutadas en la agrupación. Si alguna tarea conecta a un CNode que no ha aprendido acerca de los ficheros de configuración de trabajo, la tarea fallará. Convencionalmente, tal restricción requiere coordinación externa entre los clientes. Sin embargo, la coordinación entre clientes se sustituye por lecturas coordinadas.

Una lectura coordinada puede realizarse de la misma manera que las operaciones de modificación. Es decir, un CNode envía una propuesta para leer el fichero, y realmente lo lee cuando se recibe de vuelta el correspondiente acuerdo desde el motor de coordinación 208. Por lo tanto, los acuerdos de lectura pueden ejecutarse en la misma secuencia global que los acuerdos de modificación de espacio de nombres, garantizando de esta manera que las lecturas coordinadas nunca quedarán obsoletas. Las lecturas coordinadas no necesitan usarse para todas las lecturas, ya que hacer eso puede aumentar innecesariamente la carga computacional en el motor de coordinación 208 y puede ralentizar el rendimiento de lectura de la agrupación. Por consiguiente, únicamente los ficheros seleccionados, tal como job.xml, pueden exponerse a lecturas coordinadas. Por lo tanto, puede definirse un conjunto de patrones de nombre de fichero, por ejemplo, como un parámetro de configuración. Tales patrones pueden reconocerse por los CNode de una agrupación. Cuando se definen tales patrones de nombre de fichero, el CNode hace coincidir nombres de fichero para que se lean contra los patrones de nombre de fichero, y si la coincidencia es positiva, el CNode realiza una lectura coordinada para ese fichero.

Si se ha accedido a un objeto una vez por un cliente de un CNode particular, no necesita ser accedido a través de lecturas coordinadas para clientes posteriores. Puede identificarse un fichero como que ha sido accedido a través de solicitudes de RPC específicas. De esta manera, si un CNode que ejecuta una solicitud de este tipo observa que el fichero no se ha identificado de esta manera, ese CNode puede enviar una propuesta al motor de coordinación 208 y esperar que se reciba el correspondiente acuerdo para realizar una lectura coordinada. Este acuerdo de lectura alcanza todos los CNode, que pueden identificar sus réplicas de fichero como que se han accedido así. Todas las solicitudes de cliente posteriores para acceder al fichero identificado no necesitan estar coordinadas en lectura. Por lo tanto, en el peor caso con tres CNode en la agrupación, puede haber no más de tres lecturas coordinadas por fichero, manteniendo de esta manera un rendimiento de lectura alto.

Los CNode pueden también fallar o apagarse intencionadamente para mantenimiento. Si un CNode fallido también es el único CNode que se ha investido con labores de replicador de bloques (es decir, se ha elegido como el replicador de bloques), a continuación, la agrupación puede dejarse sin la capacidad de replicar o borrar bloques de datos. Por lo tanto, el CNode que tiene la función de replicador de bloques como se muestra en 410 puede configurarse para enviar también indicadores de funcionamiento de replicador de bloques periódicos (BR HB), como se muestra en 416, al motor de coordinación 208. Siempre que el motor de coordinación 208 recibe BRHB periódicos 416 desde el CNode seleccionado ya que incluye labores de replicador de bloques 410, ese CNode puede continuar llevando a cabo tales labores de replicación de bloques. Sin embargo, tras el fallo del motor de coordinación 208 al recibir oportunamente uno o más BR HB desde el CNode seleccionado como el replicador de bloques 410, las labores de replicación de bloques se asignarán a otro de los CNode dentro de la agrupación. A su vez, el CNode así seleccionado puede a continuación enviar BR HB periódicos (que se distinguen de los HB de indicación de funcionamiento emitidos por los DataNode) al motor de coordinación 208 y puede continuar en esa función hasta que el motor de coordinación 208 falle al recibir uno o más BR HB, tras lo cual puede repetirse el proceso de selección del CNode.

Para garantizar la unicidad del replicador de bloques 410 en la agrupación, el CNode que comprende el replicador de bloques 410 puede configurarse para enviar periódicamente una propuesta de replicador de bloques al motor de coordinación 208. A su vez, el motor de coordinación 208, tras la recepción de la propuesta del replicador de bloques, puede confirmar ese CNode como que ha sido seleccionado o elegido para llevar a cabo labores de replicación de bloques, que confirma su misión de replicador de bloques a todos los CNode en la agrupación. Si un BR HB no ha sido escuchado por los CNode durante un periodo de tiempo configurable, otros CNode, por medio del motor de coordinación 208, pueden comenzar un proceso de elección de un nuevo CNode de replicador de bloques.

De hecho, una propuesta de replicador de bloques es una manera para que el CNode que tiene labores de replicación de bloques confirme su misión como replicador de bloques a otros CNode mediante BR HB periódicos y como una manera para realizar una elección de un nuevo replicador de bloques cuando caducan los BR HB. Una propuesta de replicador de bloques puede comprender un:

• brId - el id del CNode considerado que es el replicador de bloques

• brAge - el GSN del CNode proponente

Cada CNode puede almacenar el último acuerdo de replicador de bloques que ha recibido y el tiempo en el que se recibió ese acuerdo: <lastBRA, lastRecieved>.

Por ejemplo, supóngase que hay tres CNode cn1, cn2, cn3, y cn1 es el CNode de replicador de bloques actual. El CNode cn1 propone periódicamente una propuesta de replicador de bloques como un BR HB. Esta propuesta consiste en su propio id de nodo cn1 y la nueva antigüedad del replicador de bloques, que es igual al último GSN observado por cn1 en el momento de la propuesta. El motor de coordinación 208 recibe la propuesta de replicador de bloques, genera un correspondiente acuerdo y entrega el acuerdo a todos los CNode cn1, cn2 y cn3. El nodo cn1, que es el replicador del bloque actual, aprende el acuerdo y empieza el trabajo de la replicación de bloques. Los CNode cn2 y cn3 no son replicadores de bloques actuales, ya que únicamente recuerdan <lastBRA, lastReceived> y continúan operaciones normales (no de replicación). Cuando lastReceived supera un umbral configurado, cn2 y/o cn3 pueden empezar la elección del nuevo replicador de bloques proponiéndose a sí mismos como el candidato.

El proceso de elección puede iniciarse por cualquier CNode (o por varios de ellos simultáneamente) una vez que el CNode detecta que ha caducado el BR HB de indicador de funcionamiento del replicador de bloques. El CNode de iniciación puede empezar el proceso de elección proponiéndose a sí mismo como un nuevo replicador de bloques. La propuesta puede incluir el Id de nodo y el último GSN que hubo observado el CNode de inicio en ese tiempo. La propuesta puede enviarse al motor de coordinación 208 y cuando el correspondiente acuerdo alcanza los otros CNode, actualiza su misión con respecto a una labor de replicador de bloques en consecuencia. Eso es cómo el CNode que inició el proceso de elección puede volverse el nuevo replicador de bloques. En el caso en el que varios CNode inicien la elección simultáneamente, el CNode que propuso el acuerdo con el GSN más alto se vuelve el replicador de bloques. Por lo tanto, el CNode que tiene labores de replicador de bloques puede cambiar varias veces durante el proceso de elección, pero al final habrá únicamente un CNode de replicador de bloques y todos los CNode acordarán que ese CNode tiene las labores de replicador de bloques. Se garantiza que un CNode fallido nunca hará ninguna decisión de replicación o borrado de bloque incluso si vuelve en línea después de un fallo aun suponiendo que sea el replicador de bloques. Esto es debido a que la decisión de replicar o borrar bloques se hace únicamente como el resultado de procesar un BR HB. Es decir, después de volver a dar servicio, el CNode esperará al siguiente BR HB de indicador de funcionamiento del replicador de bloques para tomar una decisión de replicación, pero el acuerdo del indicador de funcionamiento contendrá información acerca de la nueva asignación del replicador de bloques, tras la recepción del cual el CNode recién activo conocerá que ya no tiene más labores de replicación de bloques.

El hecho de que cualquier CNode esté posibilitado para generar o posibilitar la generación de bloques requiere que cada bloque de datos almacenado en los DataNode sea identificable de manera inequívoca, a través de toda la agrupación. Generar aleatoriamente identificadores (ID) de bloque de datos largos y a continuación comprobar si tales ID de bloque de datos generados son verdaderamente únicos es el método actual de la generación de ID de bloque en HDFS. Este enfoque es problemático para los CNode replicados puesto que el nuevo ID de bloque debe generarse antes de la propuesta para crear el bloque enviado al motor de coordinación, pero cuando el correspondiente acuerdo alcanza los CNode, el ID ya podría haber sido asignado a otro bloque incluso aunque ese ID estuviera libre en el momento en el que se generó. Coordinar tales colisiones en el tiempo de acuerdo, aunque es posible, añade complejidad innecesaria, tráfico y tiempo de retraso al proceso, y retarda el acuse de recibo eventual de la generación satisfactoria del bloque de datos para el cliente. En su lugar, y como se muestra en la Figura 6, puede definirse un intervalo grande, que varía de un número de ID de bloque mínimo (MINLONG) hasta un número de ID de bloque máximo (MAXLONG). Este intervalo grande puede ser tan grande como se requiera para garantizar que cada número de ID de bloque de datos sea único a través de toda la agrupación y pasado el tiempo de vida previsto del mismo. Por ejemplo, el intervalo desde MINLONG a MAXLONG puede ser, por ejemplo, un número que comprende 1024 bits o mayor. Posteriormente, para garantizar que cada CNode genere números de ID de bloque de datos, el intervalo desde MINLONG hasta MAXLONG puede dividirse lógicamente en tres intervalos de ID de bloque de CNode, mostrados en la Figura 6 en los intervalos 602, 604 y 606. Por ejemplo, el intervalo de ID de bloque de datos 602 puede abarcar desde MINLONG hasta MINLONG X bits, el intervalo de ID de bloque 604 puede abarcar desde MINlOn G X hasta MINLONG 2X, y el intervalo de ID de bloque 606 puede abarcar desde MINLONG 2X hasta MAXLONG.

Generador de Id de bloque secuencial

La generación de ID de bloque puede ser secuencial. En este caso, el CNode que origina la asignación de bloque, no necesita generar un ID de bloque con antelación antes de que se envíe la propuesta al motor de coordinación. En su lugar, los CNode pueden incrementar independientemente sus contadores de ID de bloque, cuando llega el acuerdo de asignación de bloque. Este proceso es determinista, puesto que todos los CNode empiezan desde el mismo valor del contador y aplican todos los acuerdos en el mismo orden, lo que garantiza que en cualquier GSN dado, el siguiente contador de ID de bloque será el mismo en todos los CNode.

El algoritmo addBlock() para asignar un nuevo bloque es como sigue:

1. ChooseTargets() selecciona ubicaciones potenciales para las réplicas de bloque entre DataNode vivos disponibles de acuerdo con la política de replicación en curso.

2. El bloque (ubicaciones) recién asignado con un ID de bloque aún no definido y la indicación de generación se envía como una propuesta al motor de coordinación. Cuando se alcanza el acuerdo, cada CNode asigna el siguiente ID de bloque y la siguiente indicación de generación al bloque y, a continuación, lo confirma en el espacio de nombres.

Las ubicaciones deben aún elegirse con antelación, ya que diferentes CNode no pueden elegir de manera determinista los mismos objetivos cuando procesan independientemente el acuerdo.

La Figura 7 es un diagrama de flujo de un método implementado por ordenador de implementación de un sistema de ficheros distribuido que comprende una pluralidad de DataNode configurados para almacenar bloques de datos de ficheros. Como se muestra en el bloque B71, el método puede comprender una etapa de acoplar al menos tres NameNode (o algún otro número impar mayor) a una pluralidad de DataNode. Cada uno de los NameNode puede configurarse para almacenar un estado del espacio de nombres de la agrupación. Como se muestra en el bloque B72, a continuación, puede llevarse a cabo una etapa (el motor de coordinación 208, por ejemplo) de recibir propuestas desde los NameNode (tal como se muestra en 202, 204, 206 en la Figura 2) para cambiar el estado del espacio de nombres creando o borrando ficheros y directorios y añadiendo los bloques de datos almacenados en uno o más de la pluralidad de DataNode (tal como se muestra en 302, 304 y 306 en la Figura 3). Dentro de la presente divulgación, "cambiar", cuando sea apropiado, abarca añadir nuevos bloques de datos, replicar bloques de datos o borrar bloques de datos de un fichero del cliente. Como se muestra en B73, el método implementado por ordenador puede comprender adicionalmente generar, en respuesta a recibir las propuestas, un conjunto ordenado de acuerdos que especifica la secuencia en la que los NameNode han de cambiar el estado del espacio de nombres. Por lo tanto, los NameNode retardan hacer cambios (solicitados por clientes, por ejemplo) en el estado del espacio de nombres hasta que los NameNode reciban el conjunto ordenado de acuerdos (desde el motor de coordinación 208, por ejemplo).

Cuando un nuevo CNode se ha puesto en línea (tal como puede ser el caso en el que un CNode existente ha fallado o está de otra manera apagado), el nuevo CNode puede iniciarse en modo seguro, como se ha indicado anteriormente. El nuevo CNode en modo seguro puede a continuación comenzar a recibir registros e informes de bloque de datos iniciales desde los DataNode, que identifican los bloques de datos almacenados en cada uno de los DataNode a los que está acoplado el nuevo CNode. Cuando un CNode está en modo seguro, no acepta solicitudes de clientes para modificar el estado del espacio de nombres. Es decir, antes de enviar una propuesta, el nuevo CNode comprueba si está en modo seguro y lanza la excepción de modo seguro si el nuevo CNode determina que está actualmente operando en modo seguro. Cuando se recibe un número suficiente de informes de bloque, el nuevo CNode puede dejar el modo seguro y empezar a aceptar solicitudes de modificación de datos desde los clientes. Al arrancar los CNode automáticamente entran en modo seguro y, a continuación, también dejan de manera automática y asíncrona el modo seguro una vez que han recibido un número suficiente de informes de réplicas de bloques. La salida del modo seguro automática no está coordinada a través del motor de coordinación 208, puesto que los CNode (tales como los CNode 202, 204 y 206 en la Figura 2) pueden procesar informes de bloque a diferentes velocidades y, por lo tanto, pueden alcanzar el umbral en el que pueden salir del modo seguro en diferentes tiempos. En contraste, cuando un administrador de la agrupación emite un comando para entrar en modo seguro, todos los CNode deben obedecer. Por esta razón, los comandos de modo seguro emitidos por el administrador pueden coordinarse a través del motor de coordinación 208.

Como se ha indicado anteriormente, los CNode pueden fallar o apagarse intencionadamente para mantenimiento. Los CNode replicados restantes continuarán operando siempre que formen un quórum suficiente para que el motor de coordinación 208 genere acuerdos. Si se pierde el quórum, la agrupación se congelará y dejará de procesar solicitudes de cambios al espacio de nombres hasta que se restaure el quórum.

Cuando un CNode previamente fallido o un CNode que se haya puesto deliberadamente fuera de línea vuelva a estar en línea, capturará automáticamente los otros CNode en su estado. El motor de coordinación 208 puede suministrar el CNode que vuelve a estar en línea con todos los acuerdos que perdió mientras estaba fuera de línea. Durante este periodo de tiempo, el CNode que vuelve a estar en línea no tiene su servidor de RPC iniciado. Por lo tanto, los clientes y los DataNode no pueden conectarse con él (puesto que el RPC es el modo mediante el que pueden comunicarse), lo que evita que el CNode vuelva a funcionar y no proporcione datos potencialmente obsoletos a los clientes solicitantes. Este proceso ocurre antes de que los DataNode se conecten al CNode que vuelve a estar en línea. Los registros de DataNode y los informes de bloque inicial deben retardarse ya que los informes pueden contener bloques que el CNode no ha aprendido aún y que se habrían descartado si se hubieran informado.

Si el CNode estaba fuera de línea durante un tiempo largo y perdió un número significativo de acuerdos (que puede ser un umbral configurable), puede ser poco práctico o no factible esperar que el CNode reciba los acuerdos que perdió mientras estaba fuera de línea y reproduzca el historial total de acuerdos perdidos. En este caso, puede ser más eficaz hacer que el CNode descargue un punto de comprobación desde uno de los CNode activos, lo cargue como el estado de espacio de nombres inicial y, a continuación, reciba acuerdos desde el motor de coordinación 208 empezando desde ese punto de comprobación y, a continuación, reproduzca el historial de los acuerdos proporcionados desde cuando se realizó el punto de comprobación. Para hacer eso, el CNode que vuelve a estar en línea puede elegir uno de los nodos activos (denominados el "ayudante") como un origen para recuperar el punto de comprobación y envía una solicitud de RPC (por ejemplo, startCheckpoint()) al CNode ayudante elegido. El CNode ayudante a continuación emite una propuesta de iniciar punto de comprobación al motor de coordinación 208, para garantizar que todos los otros CNode sincronizan sus puntos de comprobación local al mismo GSN. Cuando llega el acuerdo de iniciar punto de comprobación, el CNode ayudante recordará el GSN de ese acuerdo como un punto de comprobación específicamente identificado que actualmente está encendido a un GSN específico (por ejemplo, el GSN de punto de comprobación). Este GSN de punto de comprobación a continuación determina el acuerdo después del cual el CNode emergente empezará el proceso de aprendizaje una vez que consume el punto de comprobación.

El consumo del punto de comprobación por el CNode que vuelve a estar en línea puede realizarse actualizando la imagen y los ficheros de registro diario, ya que es una norma para HDFS. Después de la captura, el CNode puede a continuación empezar a recibir informes de bloque desde los DataNode. Una vez que está desactivado el modo seguro, el CNode que ha vuelto recientemente en línea puede unirse completamente a la agrupación y reanudar sus labores normales.

El arranque de un nuevo CNode o un reinicio de un CNode existente puede comprender las siguientes etapas principales.

1. El CNode que se vuelve a estar en línea se arranca y se une a la agrupación como un proponente, pero con las capacidades de aprendiz silenciadas hasta la etapa 3.

a. Examina su estado en el historial global con relación a otros nodos.

2. Si su estado está sustancialmente detrás de otros nodos, determinado por un umbral configurable, a continuación, descargará un punto de comprobación más reciente desde uno seleccionado de los nodos ayudantes activos. El nodo ayudante seleccionado también proporciona el GSN de punto de comprobación, que corresponde al estado en el historial como el de la creación del punto de comprobación.

3. Cuando se descarga el punto de comprobación (si fuera necesario) el CNode que vuelve a estar en línea envía su primera propuesta al motor de coordinación 208, denominada propuesta de recuperación de acuerdos (ARP) y asume la función del aprendiz.

a. El CNode que vuelve a estar en línea puede empezar a aprender los acuerdos que perdió cuando estaba fuera de línea, empezando desde el GSN de punto de comprobación 1.

4. Cuando el CNode que vuelve a estar en línea alcanza su propio primer acuerdo de ARP, el proceso de captura se considera completo. El CNode recién puesto en línea puede asumir ahora la función de aceptor y volverse un participante completamente funcional de la agrupación y recibir acuerdos adicionales desde y enviar propuestas al motor de coordinación 208.

5. Para hacer eso, el CNode recién puesto en línea puede inicializar su servidor de RPC y hacerse a sí mismo disponible para los DataNode para registros e informes de bloque. Después de procesar los informes y dejar el modo seguro, el CNode puede empezar a aceptar solicitudes de cliente en una base igual con los otros CNode de la agrupación.

Como se ha indicado anteriormente, cada CNode, puede almacenar una imagen del espacio de nombres y actualizar en la misma el almacenamiento persistente local (no volátil) que se acopla al CNode. Se ha de observar que, el almacenamiento local (si está presente) puede configurarse de manera que no se comparta entre los CNode. Cada CNode puede mantener, en su almacenamiento persistente local, su propio fichero de imagen local que contiene un último punto de comprobación de imagen de espacio de nombres y fichero de ediciones local, fichero de ediciones que constituye un registro diario de transacciones aplicadas al espacio de nombres desde el último punto de comprobación. Apagar una agrupación puede reducir los CNode en diferentes momentos de la evolución del espacio de nombres. Es decir, algunos CNode pueden ya haber aplicado toda la transacción especificada por los acuerdos recibidos desde el motor de coordinación 208, pero algunos CNode con retraso pueden no haber aplicado aún todas tales transacciones. Por lo tanto, después de un apagado, los ficheros de ediciones en diferentes CNode pueden no ser equivalentes. Por lo tanto, cuando se reinicia la agrupación, el CNode con retraso puede empezar en un estado más antiguo que lo que está el estado actual. Sin embargo, el motor de coordinación 208 puede configurarse para forzar al CNode con retraso hasta el estado actual alimentándole eventos perdidos desde la secuencia global.

Se ha de observar que, esto no es diferente de la operación de agrupación nominal cuando algunos CNode pueden caer detrás de otros al actualizar el estado del espacio de nombres a través del procesamiento de acuerdos recibidos desde el motor de coordinación 208. Tales CNode con retraso pueden aún aceptar solicitudes de modificación de espacio de nombres de clientes, y hacer propuestas al motor de coordinación 208. Las propuestas resultantes se ordenarán, se colocarán en la secuencia global después de los eventos que el CNode tiene que procesar aún y se aplicarán para actualizar el estado del espacio de nombres en el orden debido. De esta manera, un CNode con retraso puede "volver a la velocidad" (es decir, hasta el GSN más actual), antes de que se procesen nuevas solicitudes, manteniendo de esta manera la consistencia en el estado del espacio de nombres a través de los CNode de la agrupación. Pueden evitarse las discrepancias en el estado persistente de los CNode durante el arranque realizando un procedimiento de apagado "limpio".

Puede proporcionarse un procedimiento de apagado limpio para forzar a todos los CNode a un estado común antes de que se apague una agrupación. Como el resultado de llevar a cabo un apagado limpio, todas las imágenes locales del espacio de nombres almacenadas en la memoria local persistente acoplada a cada uno de los CNode serán idénticas, y las actualizaciones a las mismas pueden representarse por una secuencia vacía de transacciones. Para apagar de manera limpia y forzar a que todas las imágenes locales del espacio de nombres sean idénticas, puede ordenarse a cada CNode que entre en el modo seguro de la operación, durante el tiempo en el que el CNode deja de procesar solicitudes de cliente para modificar el espacio de nombres, mientras que los acuerdos restantes que se le envían por el motor de coordinación 208 todavía se están procesando. Posteriormente, puede llevarse a cabo una operación para guardar el espacio de nombres, creando de esta manera un punto de comprobación local del espacio de nombres y vaciando el registro diario. Antes de matar los procesos del CNode, puede garantizarse que todos los CNode han completado su guardado del espacio de nombres (ahora idéntico, a través de los CNode) y han creado su respectivo punto de comprobación local del espacio de nombres, para hacer de esta manera que todos los CNode reinicien con el mismo espacio de nombres. Posteriormente, pueden matarse los procesos del CNode. Después de un apagado limpio, cualquier proceso de arranque posterior continuará más rápido que lo que sería el caso de otra manera si los CNode no se hubieran apagado de manera limpia, ya que ninguno de los CNode necesita aplicar ediciones ni actualizaciones perdidas desde el motor de coordinación 208 (ya que se pusieron en un estado idéntico antes del apagado).

II Sistema de ficheros distribuido en una red de área extensa (WAN)

La Figura 8 es un diagrama de un sistema de ficheros distribuido que halla utilidad particular en el entorno de WAN. La Figura 8 también ilustra aspectos de los métodos de replicación, aplicables a través de una WAN, para un sistema de ficheros basado en NameNode distribuido (tal como, por ejemplo, HDFS) basándose en un modelo de máquina de estado replicada. Los NameNode están ubicados en diferentes centros de datos geográficamente distribuidos. Tales centros de datos pueden ubicarse, por ejemplo, en diferentes continentes. En el presente documento, a continuación, tales NameNode se denominan GeoNode, para distinguirles de los nodos de consenso (o CNode) en el caso en el que los NameNode estén acoplados entre sí mediante una LAN.

Los GeoNode también puede considerarse que son un caso especial de los CNode que se ha descrito en detalle anteriormente. De hecho, los GeoNode pueden incorporar alguna o todas las características, conceptos, métodos y algoritmos descritos en el presente documento con relación a los CNode que están configurados para realizar acciones a través de una LAN, tal como puede ser el caso en el que los CNode operan dentro de un único centro de datos. Se describen a continuación realizaciones que son aplicables a un sistema de ficheros distribuido que abarca una agrupación de HDFS a través de una WAN que incluye, por ejemplo, Internet y/o una WAN privada o propietaria.

Vista general de la arquitectura

La Figura 8 es un diagrama de bloques de componentes de una agrupación y un sistema de ficheros distribuido que abarca una WAN. Como se muestra en el mismo, la agrupación (por ejemplo, única) que ejecuta un sistema de ficheros distribuido 802 comprende dos o más centros de datos; en concreto, el centro de datos A (DCA) 804 y el centro de datos B (DCB) 806. El DCA 804 y el DCB 806 están geográficamente remotos entre sí. Por ejemplo, el DCA 804 y el DCB 806 pueden estar ubicados en diferentes partes de un único país, pueden estar distribuidos en diferentes continentes, diferentes zonas horarias y pueden utilizar redes eléctricas totalmente diferentes. El DCA 804 y el DCB 806 están acoplados libremente entre sí mediante una WAN 808 que puede incluir, por ejemplo, Internet y/u otras redes privadas y/o propietarias. El DCA 804 y el DCB 806 pueden también estar acoplados entre sí mediante conexiones de alta velocidad especializadas. Aunque se muestran únicamente dos centros de datos 804, 806 en la Figura 8, se ha de entender que las realizaciones pueden incluir un mayor número de centros de datos y que el sistema de ficheros distribuido 802 se extiende a través de todos tales centros de datos.

Como se muestra, el DCA 804 puede comprender una pluralidad de NameNode activos (a diferencia de, por ejemplo, en espera o de migración tras error) que, en el presente contexto, se indican como el GeoNode y se referencian en las figuras como "GN". De esta manera, el DCA 804 puede comprender GeoNode indicados por los números de referencia 810, 812 y 814, y el DCB 806 puede comprender GeoNode indicados por los números de referencia 816, 818 y 820. Cada uno de los GeoNode 810, 812, 814, 816, 818 y 820 está configurado para almacenar el estado del espacio de nombres del sistema de ficheros distribuido y para mantener ese espacio de nombres único de una manera coherente a través de los GeoNode y los centros de datos. Los aspectos de la coordinación entre los GeoNode y el mantenimiento del único espacio de nombres a través de los GeoNode se proporcionan por el proceso de motor de coordinación (CE) distribuido 822. En la Figura 8, el proceso de CE 822 se muestra de una manera que sugiere que es una entidad lógica separada que abarca el DCA 804, el DCB 806 y la WAN 808. Sin embargo, la funcionalidad del CE 822, anteriormente descrita y a continuación, puede descargarse por cada uno de los GeoNode 810, 812, 814, 816, 818 y 820. Es decir, cada uno de los GeoNode 810, 812, 814, 816, 818 y 820 puede configurarse, entre sus otras funciones, para llevar a cabo las labores del CE 822.

El DCA 802 puede comprender una pluralidad de DataNode 824, 826, 828, 830, denominados como "DN" en la Figura 8. De manera similar, el DCB 804 puede comprender también una pluralidad de DataNode 832, 834, 836, 838, también denominados como "DN" en la Figura 8. Como se muestra, cada uno de los DataNode 824, 826, 828, 830 está acoplado y configurado para comunicarse con cada uno de los GeoNode 810, 812 y 814 de DCA 802. Como también se muestra, cada uno de los DataNode 832, 834, 836, 838 está acoplado y configurado para comunicarse con cada uno de los GeoNode 810, 812 y 814 de DCB 806. Los GeoNode no se comunican directamente con los DataNode. De hecho, los DataNode están configurados para enviar solicitudes a los GeoNode, tras lo cual los GeoNode emiten comandos a los DataNode en respuesta a las solicitudes recibidas. Por lo tanto, aunque puede decirse que los GeoNode controlan los DataNode, los DataNode deben enviar unas solicitudes a los GeoNode para recibir un comando a partir de los mismos. Se muestran cuatro DataNode 824, 826, 828, 830 en el DCA 804. De manera similar, se muestran los DataNode 832, 834, 836 y 838 en el DCB 806. Sin embargo, ha de entenderse que los centros de datos 804 y 806 puede cada uno comprender muchos más (por ejemplo, miles) de nodos de datos de los que se muestran en la Figura 8.

Aunque se muestran tres GeoNode 810, 812, 814 como que se proporcionan dentro del DCA 802, puede proporcionarse un número mayor de los GeoNode dentro del DCA 802. De manera similar, aunque se muestran tres GeoNode 816, 818, 820 como que se proporcionan dentro del DCB 806, puede proporcionarse un número mayor de los GeoNode dentro del DCB 806. El número de GeoNode dentro de un centro de datos puede seleccionarse para que sea un número impar.

La Figura 8 muestra una agrupación que ejecuta un sistema de ficheros distribuido único que abarca diferentes centros de datos geográficamente separados. La coordinación de espacio de nombres entre los GeoNode dentro del mismo centro de datos puede realizarse usando las estructuras, métodos y procedimientos como se ha descrito anteriormente con relación al caso de uso de la LAN. Por ejemplo, cada uno de los DataNode puede configurarse para comunicarse (a través del protocolo de RPC de DataNode a NameNode) únicamente con los GeoNode dentro de su propio centro de datos. A la inversa, los GeoNode de un centro de datos pueden configurarse para controlar únicamente los DataNode dentro de su propio centro de datos. Es decir, los DataNode del centro de datos 804 pueden comunicarse únicamente con los GeoNode de su propio centro de datos 804 y los nodos de datos del centro de datos 806 pueden comunicarse únicamente con los GeoNode de su propio centro de datos 806. Los GeoNode de ambos centros de datos 802, 804 se coordinan entre sí para mantener el estado del espacio de nombres coherente a través del proceso de motor de coordinación 822. Como se describe a continuación, los nodos de datos de un centro de datos pueden comunicarse con los nodos de datos de otro centro de datos o centros de datos.

El proceso de CE 822 está configurado para garantizar las mismas actualizaciones deterministas para el estado del espacio de nombres que se aplican en el mismo orden determinista en todos los GeoNode. El orden se define por un número de secuencia global (GSN). Por lo tanto, una función significativa del proceso de CE 822, es procesar las propuestas para modificar o actualizar de otra manera el estado del espacio de nombres desde todos los GeoNode y transformarlos en una secuencia ordenada global de acuerdos. Los GeoNode a continuación aplican los acuerdos desde esa secuencia ordenada como actualizaciones a su estado almacenado. El GSN puede configurarse como un número creciente monótonamente único. Sin embargo, el GSN puede configurarse de otra manera, como pueden reconocer los expertos en la materia. El GSN a continuación ha de usarse para comparar el progreso de diferentes GeoNode al actualizar el estado del espacio de nombres y mantener ese estado de espacio de nombres coherente a través de los GeoNode (o proporcionar el estado del espacio de nombres almacenado en cada uno de los GeoNode en consistencia a través del tiempo a través de la aplicación secuencial de la secuencia ordenada de acuerdos). Por ejemplo, si el GeoNode 810 acaba de procesar un acuerdo numerado GSN1, que es menor que el GSN2 recién procesado por el GeoNode 812, entonces el GeoNode 810 tiene un estado de espacio de nombres anterior al del GeoNode 812. El estado del espacio de nombres almacenado por el GeoNode 810 coincidirá con el almacenado por el GeoNode 812 tan pronto como el GeoNode 810 procese GSN2, con la condición de que el GeoNode 812 no haya procesado un acuerdo con número superior en el ínterin. De esta manera y a través de la ejecución secuencial del conjunto ordenado de acuerdos generado por el proceso de CE 822, el estado del espacio de nombres almacenado en cada uno de los GeoNode en cada uno de los centros de datos se lleva o se mantiene en consistencia.

Con cada operación, los clientes aprenden acerca del último GSN procesado en el GeoNode al que está conectado actualmente el cliente. Posteriormente, si el cliente conmuta a otro GeoNode debería esperar en primer lugar (si fuera necesario) hasta que el nuevo GeoNode capture el último GSN sobre el que el cliente conoce (es decir, el GSN que el cliente recibió desde el GeoNode previamente accedido) antes de emitir un RPC que comprende un comando de acceso de datos tal como una escritura. Esto evitará el problema de lectura obsoleta. Como los GeoNode empiezan desde el mismo estado, esta aplicación ordenada de actualizaciones implica consistencia de las réplicas, ya que las instantáneas de las mismas tomadas en diferentes nodos que han procesado los acuerdos en el mismo GSN son idénticas, tanto dentro como a través de los centros de datos. Todos los metadatos entre los GeoNode 810, 812, 814, 816, 818, 820 pueden coordinarse instantáneamente siempre que el proceso de CE 822 entregue los acuerdos. Análogamente, todos los datos del sistema de ficheros también se replican automáticamente a través de los múltiples centros de datos (se muestran dos en la Figura 8) de la agrupación.

En el presente documento, el término "externo" se usa preferentemente para indicar GeoNode, DataNode, réplicas de bloque, clientes, etc., de un centro de datos diferente. Las entidades del mismo centro de datos se denominan "nativas". Por ejemplo, cuando un cliente accede al DCA 804, el DCA 804 puede considerarse que es el centro de datos local o nativo, mientras que el DCB 806 puede indicarse como el centro de datos externo. A la inversa, si un cliente accediera al DCB 806, ese centro de datos 806 es el centro de datos local o nativo, mientras que el DCA 804 se indica el centro de datos externo.

Cuando un cliente crea un nuevo fichero, el proceso de CE 822 garantiza que todos los GeoNode 810, 812, 814, 816, 818, 820 conozcan acerca del nuevo fichero y eviten que se cree otro fichero del mismo nombre, incluso antes de que tengan acceso a los datos (por ejemplo, los bloques de datos) del nuevo fichero. Se replican bloques de datos dentro del centro de datos nativo y también se replican entre centros de datos de una manera asíncrona en segundo plano. De esta manera, los GeoNode aprenden acerca de un nuevo fichero y sus bloques de datos antes de poder proporcionar réplicas locales (con relación al centro de datos) de ese bloque para clientes nativos. Es decir, un cliente de DCA 804 puede crear un nuevo fichero, que forma la base de una nueva propuesta ordenada emitida al proceso de CE 822. Se genera un acuerdo ordenado y se actualiza el estado de todos los GeoNode, tanto dentro del DCA nativo 804 como dentro del DCB externo 806. Posteriormente, como se detalla a continuación, se transfieren bloques de datos a un DataNode designado dentro del DCA 804, y posteriormente se canalizan (en serie, desde un DataNode a otro DataNode) mediante el DataNode designado al otro (por ejemplo, otros dos) DataNode de GeoNode designado dentro del DCA 804 hasta que se alcance un estado de replicación completa. Puede alcanzarse un estado de replicación completa cuando, por ejemplo, se almacenan réplicas de un bloque de datos en tres DataNode de un centro de datos dado. El estado de replicación completa puede definirse de otra manera, como pueden reconocer los expertos en la materia. Como se describe a continuación, tras alcanzar un estado de replicación completa, pueden transferirse los bloques de datos de manera asíncrona y en segundo plano a los DataNode de uno o más centros de datos remotos.

Los DataNode 824, 826, 828 y 830 de DCA 804 y los DataNode 832, 834, 836 y 838 de DCB 806 pueden configurarse para almacenar réplicas de bloques de datos de ficheros de cliente. Las réplicas de cualquier bloque de datos único pueden almacenarse en los DataNode de uno (por ejemplo, el DCA 804), dos (por ejemplo, el DCA 804 y el DCB 806) o en los DataNode de un número mayor de centros de datos. Puesto que las comunicaciones a través de la WAN 808 son intensivas en recursos y costosas, son propensas a latencias variables, interrupciones y estrangulamiento del ancho de banda, una realización puede configurarse de manera que los DataNode de un centro de datos no se comuniquen con los GeoNode de otros (geográficamente remotos, externos) centros de datos. Es decir, como se presagió anteriormente, los DataNode 824, 826, 828 y 830 se comunican únicamente con (por ejemplo, emiten solicitudes a) los GeoNode 810, 812, 814 y no con los GeoNode 816, 818, 820 del DCB 806. A la inversa, los DataNode 832, 834, 836 y 838 se comunican únicamente con los GeoNode 816, 818 y 820 de su propio centro de datos y no con los GeoNode 810, 812 y 814 del DCA 804. Esto implica que los GeoNode de un centro de datos no reciban informes de bloque o indicadores de funcionamiento directamente desde los DataNode de centros de datos externos y no envíen comandos a los DataNode de centros de datos externos.

Sin embargo, los DataNode de un centro de datos, es decir, el DCA 804, pueden configurarse para copiar réplicas de bloques de datos a través de la WAN 808 a uno o más centros de datos externos, es decir, el DCB 806, para proporcionar servicios de replicación de bloque externo. El tráfico de red a través de la WAN 808 puede minimizarse enviando únicamente una réplica de cualquier bloque de datos particular a través de la WAN 808 y configurando cualquier replicación adicional para que tenga lugar en el DC externo de manera nativa. Por ejemplo, cuando un bloque de datos está completamente replicado en el DCA 804, puede enviarse una réplica de tal bloque de datos a través de la WAN 808 al DCB 806. Cualquier replicación adicional que pueda requerirse para replicar completamente ese bloque de datos en el DCB 806 tendría entonces lugar completamente dentro del DCB 806.

Los clientes del sistema de ficheros distribuido tales como, por ejemplo, las tareas de mapeo y reducción de HDFS pueden configurarse para compartir el entorno informático con los DataNode del centro de datos del cual son un cliente. Por lo tanto, un cliente puede configurarse para ejecutarse en uno de los centros de datos disponibles. Por lo tanto, las tareas de los clientes pueden optimizarse con GeoNode que son nativos al centro de datos y pueden configurarse para acceder a los DataNode nativos. Sin embargo, los clientes pueden configurarse también para alcanzar a través de la WAN 808 para acceder a datos de otro centro de datos.

No hay GeoNode preferidos, en que cada uno se mantiene coherente y el sistema es tolerante al fallo de uno cualquiera o más GeoNode o, de hecho, del fallo de uno o más centros de datos. A la inversa, de acuerdo con las realizaciones, no hay migración tras error, GeoNode inactivos o en espera, en los que cada NameNode en el sistema esté activo en todo momento y mantenga un estado coherente del espacio de nombres. Además, los sistemas desvelados en el presente documento están configurados para aparecer, actuar y ser operados como una única agrupación de ficheros distribuido (por ejemplo, HDFS), a diferencia de una arquitectura de múltiples agrupaciones en la que las agrupaciones se ejecutan independientemente en cada centro de datos mientras se comparte alguno o todos los datos (en espejo) entre ellos. Partes similares de la agrupación de la WAN que pertenecen a diferentes centros de datos pueden configurarse para tener funciones iguales. De esta manera, pueden ingerirse los datos por, o ser accedidos a través de cualquiera de los centros de datos del sistema de ficheros distribuido. Los procesos de creación y acceso de datos pueden configurarse para ejecutarse a velocidades sustancialmente de LAN (es decir, en general más rápidas que las velocidades de WAN en muchos casos). Por ejemplo, si se ejecuta un trabajo en uno de los centros de datos, ese trabajo debe completarse aproximadamente en el mismo periodo de tiempo que habría tenido si no hubiera otros centros de datos.

La estructura de los sistemas de ficheros distribuidos la hace ser altamente tolerante a fallos y a desastres. De hecho, cualquier GeoNode puede fallar, los GeoNode pueden fallar simultáneamente en dos o más centros de datos, un centro de datos entero puede fallar debido a, por ejemplo, particionamiento de WAN, los DataNode pueden fallar (por ejemplo, un fallo simultáneo de dos DataNode y/o un fallo de un bastidor entero), mientras mantienen todos la funcionalidad de la agrupación y acceso libre a los datos.

Flujo de trabajo para crear y leer ficheros

Crear un fichero

De manera convencional en HDFS, cuando un cliente desea crear un fichero, solicita al NameNode en primer lugar con una solicitud de creación seguida por añadir bloque o un comando de funcionalidad similar. La solicitud de creación crea una entrada en el espacio de nombres que corresponde al nuevo fichero con los atributos especificados. La solicitud añadir bloque asigna un nuevo bloque vacío para el fichero y asigna posibles ubicaciones de DataNode para sus réplicas de acuerdo con la política de replicación de bloques. El cliente a continuación forma una canalización desde un DataNode de NameNode designado al siguiente DataNode de NameNode designado y escribe datos en el mismo. Posteriormente, los DataNode informan las nuevas réplicas de bloque al NameNode tras la recepción.

Sin embargo, cuando el espacio de nombres se replica en múltiples GeoNode (en el caso de la WAN) o CNode (en el caso de la LAN), la solicitud del cliente (número de referencia 840 en la Figura 8) se envía y recibe por uno de los múltiples GeoNode o CNode. En el caso de la WAN, el cliente puede seleccionar (pero no lo necesita) un GeoNode nativo. El GeoNode que ha recibido la solicitud de cliente, que actúa en este caso como un proponente, a continuación, forma una propuesta que corresponde a la solicitud del cliente y envía la propuesta al proceso de CE 822. Una vez que se consigue el acuerdo sobre esta propuesta, el proceso de CE 822 entrega el acuerdo a todos (es decir, a todos los GeoNode del DCA 804, del DCB 806 y de todos los GeoNode de cualquier otro centro de datos en la agrupación de ficheros distribuida (por ejemplo, HDFS). El acuerdo puede a continuación aplicarse a las instancias de espacio de nombres locales de los GeoNode, creando de esta manera el mismo fichero o el mismo bloque de manera coherente en todos los GeoNode. El GeoNode proponente responde al cliente después de que procesa el acuerdo.

Cuando se crea un bloque, los GeoNode eligen DataNode nativos como posibles ubicaciones para el bloque. Por ejemplo, cuando el cliente 840 crea un fichero, se crea una entrada en el espacio de nombres, y a través del proceso de propuesta/acuerdo, se actualiza el estado de todos los GeoNode, tanto nativos como externos. De esta manera, no puede crearse ningún otro fichero de ese nombre en cualquiera de los centros de datos. Un GeoNode, tal como el GeoNode 810, a continuación, designa posibles DataNode para almacenar el bloque de datos y todas las réplicas del mismo. El cliente 840, posteriormente, se comunica con únicamente los DataNode y ya no con los GeoNode. El cliente 840 puede a continuación escribir bloques de datos en un primer posible DataNode de GeoNode designado (tal como 824, por ejemplo) y crea una canalización 825 de réplicas desde un DataNode nativo al siguiente posible DataNode nativo en la canalización, hasta que se consigue la replicación completa (sin embargo, se define la replicación "completa") en el centro de datos nativo. Esta canalización puede rellenarse a velocidades de LAN, puesto que ninguna de las réplicas de bloques de datos se transfiere a través de la WAN 808. La replicación completa, de acuerdo con una implementación, puede conseguirse cuando las réplicas de un bloque de datos se almacenan en tres DataNode nativos separados tales como, por ejemplo, los DataNode 824, 826 y 828 del DCA 804. Para informar a todos los GeoNode (tanto nativos como externos) de las ubicaciones de bloques de datos, uno de los GeoNode nativo envía una propuesta de informe de réplica externa mediante la funcionalidad de propuesta/acuerdo de CE, después de que los DataNode informan la recepción segura de las réplicas a ese GeoNode.

Cuando el GeoNode recibe información acerca de todas las réplicas de bloque nativas, tal como cuando los bloques están completamente replicados, el GeoNode genera una propuesta de informe de réplica externa al CE 822. Después de que se alcanza el acuerdo sobre esta propuesta, el informe de réplica externa actúa para informar a todos los GeoNode (tanto nativos como externos) de la existencia y ubicación de las nuevas réplicas. En esta etapa, tanto los GeoNode nativos como los externos "conocen" de la existencia del fichero recién creado, y de las ubicaciones de las réplicas en el bloque del mismo. Sin embargo, únicamente los DataNode nativos de GeoNode designado realmente almacenan réplicas en bloque del mismo. El espacio de nombres, por lo tanto, permanece actualizado y coherente a través de los centros de datos, incluso si (en este punto en el tiempo) únicamente los DataNode nativos de GeoNode designado almacenan las réplicas que han dado lugar a la actualización en el espacio de nombres.

Posteriormente, se planifica una transferencia de réplica desde uno de los nuevos DataNode nativos de almacenamiento de réplica a un DataNode externo, a través de la norma para el protocolo de transferencia de datos de HDFS. Por ejemplo, el nuevo DataNode nativo de almacenamiento de réplica 828 puede planificarse para transferir una réplica de bloque a través de la WAN 808 a un posible DataNode de GeoNode designado externo, tal como 832. Se ha de observar que, esta transferencia puede llevarse a cabo después de que se haya replicado completamente la réplica objeto (es decir, replicada en 3, 4 o 5 (por ejemplo) DataNode nativos). Desde el punto de vista del cliente, la escritura de bloques de datos a los posibles DataNode nativos de GeoNode designado se ha llevado a cabo a velocidades de LAN, que pueden ser comparativamente más rápidas que las velocidades de WAN en muchos casos. En esta etapa, por lo tanto, las réplicas se almacenan de manera redundante en centro de datos nativo, pero, en este momento, no se almacenan también en uno o más centros de datos geográficamente remotos (y por lo tanto tolerantes a desastres). Después de que los nuevos DataNode nativos de almacenamiento de réplica transfieren una réplica de bloque al posible DataNode de GeoNode designado externo, se ha creado de manera asíncrona una copia del bloque en un centro de datos externo. Esta transferencia tiene lugar necesariamente a velocidades de WAN, pero tiene lugar en segundo plano, sin retardar la finalización y acuse de recibo eventual de la escritura del cliente. La réplica recién recibida puede replicarse a continuación de manera nativa en el centro de datos externo de acuerdo con su política de replicación interna, mediante un protocolo de replicación (por ejemplo, HDFS). Por ejemplo, el DataNode externo del GeoNode designado externo 832 que acaba de recibirse en 829, a través de la WAN, la copia del bloque desde un DataNode nativo tal como 828 puede a continuación hacer que se replique el bloque de datos, en forma de canalización (mostrada en 833 en la Figura 8), a otros DataNode externos de GeoNode designado externo tales como 834 y 836 hasta la replicación completa para que se consiga entonces el bloque en el centro de datos externo y se informe a los GeoNode externos 816, 818, 820 mediante las solicitudes de RPC desde los DataNode. Los GeoNode externos pueden a continuación actualizar, de nuevo mediante el proceso de propuesta/acuerdo a través del CE 822, los GeoNode nativos al menos de las ubicaciones, dentro de los DataNode externos, de las réplicas en el DCB externo 806.

Lectura de fichero

Cuando un cliente de un sistema de ficheros distribuido, tal como el HDFS, necesita leer un fichero, envía una solicitud obtener ubicaciones de bloque (o funcionalmente similar) al NameNode. El NameNode devuelve una lista de DataNode que almacena las réplicas de los bloques de datos solicitados. El cliente a continuación lee datos desde uno de los DataNode más cerca del cliente, con respecto a la topología de red.

En una agrupación de WAN tal como se muestra en la Figura 8, el cliente 840 de DCA 804 envía la solicitud de obtener ubicaciones de bloque (o una funcionalidad similar) a uno de los GeoNode nativos del DCA 804. El GeoNode nativo al que el cliente ha enviado las solicitudes de obtener ubicaciones de bloque recibe esa solicitud y devuelve al cliente 840 una lista de ubicaciones en los DataNode nativos que almacenan réplicas de los bloques identificados en la solicitud. Una lista de este tipo puede contener únicamente DataNode nativos, tanto DataNode nativos como externos o únicamente DataNode externos. Las réplicas pueden almacenarse únicamente en DataNode externos en el caso en el que los bloques se estén escribiendo aún, se estén replicando aún de manera nativa o se estén replicando completamente en su centro de datos nativo, pero no se hayan transferido aún al centro de datos externo (nativo para el cliente que emite el comando de lectura), como se ha detallado anteriormente. Si se almacenan las réplicas de bloque en los DataNode que son nativas al centro de datos a partir de las que se hizo la solicitud de obtener ubicaciones de bloque, el cliente 840 puede leer la réplica de bloques desde uno de los DataNode nativos. De otra manera, el cliente 840 puede leer las réplicas externas a través de la WAN 808. Sin embargo, las lecturas a través de la WAN 808 son costosas en recursos. Por lo tanto, por razones de rendimiento, un ejemplo posibilita dejar de permitir lecturas de réplica externas. En ese caso, puede hacerse que el cliente 840 espere hasta que las réplicas de los bloques de datos solicitados aparezcan en su centro de datos nativo y, a continuación, continuar con la lectura de las réplicas ahora nativas. La opción para permitir/dejar de permitir lecturas externas puede ponerse a disposición como un parámetro de configuración.

Gestión de bloques externos

Un gestor de bloques mantiene información acerca de las ubicaciones de bloques de ficheros nativos y los DataNode nativos. Puede proporcionarse un gestor de bloques externos para mantener información acerca de ubicaciones de bloque de fichero externo y los DataNode externos. La descripción a continuación detalla la manera en la que los ejemplos mantienen bloques externos y DataNode externos.

Replicación de bloques externos

Como se ha descrito anteriormente, los bloques nuevos de un fichero pueden asignarse mediante una solicitud de añadir bloque o funcionalidad similar y pueden coordinarse a través de los GeoNode. Cuando un GeoNode recibe una solicitud de añadir bloque desde un cliente, la solicitud de añadir bloque-el GeoNode de recepción puede elegir el número requerido de réplicas nativas (3 por defecto) requeridas para la replicación completa y puede enviar una correspondiente propuesta de añadir bloque al proceso de CE 822. Cuando el correspondiente acuerdo llega desde el CE 822, el GeoNode puede asignar de manera determinista un ID de bloque o identificador similar y una indicación de generación al bloque y puede a continuación devolver el bloque ubicado o la comunicación de funcionalidad similar al cliente. Los objetivos iniciales para los bloques nuevos del fichero del cliente pueden elegirse únicamente desde los DataNode que son nativos al centro de datos al que el cliente emitió la solicitud de añadir bloque. Esto permite la optimización del rendimiento de escritura, en que los clientes reciben acuses de recibo de escritura del centro de datos a los que están escribiendo sin esperar hasta que se completen las transferencias a través de la WAN. De esta manera, los clientes evitan el procesamiento de error (tal como actualizar la canalización, por ejemplo), ya que los errores son más probables debido al enlace de WAN más lento o menos fiable 808.

Por lo tanto, las réplicas se almacenan en primer lugar en los DataNode que son nativos para el centro de datos de origen mediante un procedimiento de canalización de datos. Cuando la transferencia tiene éxito, el cliente pude asumir de manera segura que los datos se almacenan en el sistema de ficheros y puede a continuación continuar con el siguiente bloque u otras operaciones. Otros centros de datos (es decir, externos), en esta coyuntura, no poseen réplicas nativas del bloque, aunque sus GeoNode han tenido conocimiento de la existencia del fichero y pueden ya haber conocido la ubicación de las réplicas del bloque almacenado en centros de datos externos (para ellos).

El GeoNode a continuación espera hasta que los DataNode en la canalización informen sus réplicas. Cuando el número de réplicas informadas alcanza la replicación completa (3 por defecto) el GeoNode emite una propuesta de informe de réplica externa (FRR) y planifica una transferencia de una réplica a un centro de datos externo.

Informe de réplica externa

Un informe de réplica externa (FRR) puede configurarse para incluir todas las réplicas nativas del bloque informadas al GeoNode y el nombre del centro de datos al que pertenecen las réplicas o el nombre del centro de datos de información. Los FRR constituyen un mecanismo posible mediante el cual las réplicas de bloques existentes en un centro de datos pueden informarse a los GeoNode en otros centros de datos. Las propuestas/acuerdos de FRR pueden emitirse en los siguientes dos casos:

1. Cuando el recuento de réplicas de bloques nativos alcanza la replicación completa para el centro de datos, o

2. Cuando el recuento de réplicas de bloques nativos se reduce a 0 tal como puede ocurrir, por ejemplo, cuando todos (tres, o, sin embargo, muchos) de los DataNode que almacenan las réplicas mueren o no están disponibles de otra manera para dar servicio a solicitudes de acceso de datos.

Tras la recepción de un acuerdo de informe de réplica externo, un GeoNode puede determinar en primer lugar si las réplicas externas se están informando en el FRR. Si no, a continuación, el f Rr está informando el almacenamiento de las réplicas en el DataNode nativo (del cual el GeoNode ya tiene conocimiento) y el GeoNode puede ignorar de manera segura el FRR. Sin embargo, si las réplicas que son el objeto del FRR son de hecho externas, el GeoNode puede sustituir su lista actual de réplicas externas para el centro de datos de generación de información con la lista recién informada. Por lo tanto, el mecanismo de FRR puede operar para añadir y/o eliminar réplicas del bloque externas.

Cada centro de datos puede proporcionarse con un replicador de bloques (en un ejemplo, único). Se muestra un único replicador de bloques en 410 en la Figura 4, en la implementación de LAN. El replicador de bloques hace decisiones sobre la replicación y borrado de réplicas de bloques para la agrupación total en el centro de datos. Tales decisiones deben realizarse unilateralmente, para que no se creen demasiadas réplicas o, lo que es, pero, algunos bloques puedan perder todas las réplicas.

En un centro de datos, el único GeoNode que asume la funcionalidad de replicador de bloques es el GeoNode que emite el FRR. Como el propósito del FRR es informar ubicaciones de réplica dentro de su propio centro de datos a otros centros de datos externos, pueden configurarse los informes de FRR para informar únicamente en las ubicaciones de las réplicas de bloque nativas.

Por razones de rendimiento, puede emitirse el FRR por el GeoNode del replicador de bloques, cuando un bloque alcanza la replicación nativa completa. En una implementación, puede emitirse una propuesta de FRR cuando el DataNode nativo informa el almacenamiento satisfactorio de tres réplicas, aunque pueden concebirse otras definiciones de "replicación nativa completa". Puede no concebirse un FRR hasta que se reduzca el número de réplicas a 0, puesto que siempre que el centro de datos tenga al menos una réplica del bloque, ese centro de datos puede manejar la replicación de manera nativa. Sin embargo, cuando el centro de datos ya no tiene ninguna réplica nativa de ningún bloque o bloques de datos particular, el GeoNode del replicador de bloques del centro de datos puede emitir un FRR para el bloque o bloques que indica que otros centros de datos deben transferir una réplica o réplicas al mismo a través de la WAN 808.

Si se pierde una o varias (pero no todas) las réplicas de un bloque de datos en el DCA 804, otros centros de datos no sabrán sobre el estado de replicación inferior al completo de esa réplica hasta que se restaure la replicación completa del bloque en el DCA 804. En este punto (replicación completa conseguida), el GeoNode del replicador de bloques del DCA 804 enviará un FRR, y otros centros de datos actualizarán en correspondencia sus listas de réplicas externas al valor real como se informa por el DCA que emite el FRR 804. En el periodo de tiempo intermedio, algunas lecturas externas pueden fallar al leerse desde la ubicación o ubicaciones perdidas, pero conmutarse a otra réplica de una manera sin interrupciones.

El factor de replicación (que cuantifica el número de réplicas que deben almacenarse en un centro de datos dado para que el bloque se considere completamente replicado) de un bloque dado puede ser diferente a través de los centros de datos. Por ejemplo, un ejemplo permite que la agrupación almacene tres réplicas en el DCA 804 y únicamente una réplica del bloque en el d Cb 806, sin embargo, considerándose el bloque que está completamente replicado en el DCA 804 y en el DCB 806. Por lo tanto, la noción de replicación completa puede ser específica para un centro de datos particular. Esto puede ser útil, por ejemplo, para datos menos críticos en los que es suficiente una única réplica geográficamente remota.

Transferencia de réplica externa

Un GeoNode designado como el replicador de bloques en un centro de datos puede encargarse con la responsabilidad adicional de explorar bloques y detectar aquellos que tienen réplicas nativas, pero no tienen las externas. Esta funcionalidad puede asignarse al monitor de bloque, que además de la monitorización periódica de réplicas nativas, también analiza la replicación externa.

Cuando se detecta un bloque con réplicas nativas, pero no réplicas externas por el GeoNode designado como el replicador de bloques, el GeoNode selecciona uno de los DataNode nativos que almacena la réplica de interés y la dirige para transferir su réplica a un DataNode en otro centro de datos. El comando para transferir la réplica a través de la WAN puede emitirse mediante una comunicación de indicación de funcionamiento entre los DataNode y los GeoNode nativos. Una vez que se recibe el comando, el DataNode seleccionado transfiere su réplica al DataNode externo designado en el centro de datos externo.

Los DataNode pueden configurarse para aceptar comandos de DataNode únicamente desde el GeoNode designado como que tiene la funcionalidad de replicador de bloques, que es otra razón por la que cada centro de datos puede configurarse para comprender un GeoNode de replicador de bloques designado único.

Replicadores de bloques nativos

En el contexto de LAN, cada agrupación de CNode tiene un único CNode que está designado como el replicador de bloques que solamente está encargado con la responsabilidad de replicar de manera selectiva y borrar réplicas de bloques para toda la agrupación. De manera similar a los CNode, los GeoNode eligen un único GeoNode replicador de bloques que es único para el centro de datos. Cada GeoNode replicador de bloques envía un indicador de funcionamiento de replicador de bloques (BR HB). Los GeoNode pueden configurarse para ignorar los BR HB de los GeoNode replicadores de bloques externos, como tales, están configurados para usarse únicamente internamente, dentro de cada centro de datos local. Como se ha descrito anteriormente con relación a los CNode replicadores de bloques de LAN, si el BR HB desde el GeoNode de replicador de bloques nativo actual falla al emitirse dentro del periodo de tiempo permitido para lo mismo, los otros GeoNode dentro del centro de datos pueden elegir un nuevo GeoNode replicador de bloques de manera que puede ser similar al método utilizado para elegir un nuevo CNode replicador de bloques.

Puesto que los BR HB para diferentes centros de datos son independientes entre sí, su coordinación puede manejarse con una única máquina de estado en la que se ignoran BR h B externos o con múltiples máquinas de estado, una máquina de estado independiente para cada centro de datos. En el último caso, las máquinas de estado pueden estar caracterizadas por miembros disjuntos, incluyendo cada uno los GeoNode de un único centro de datos.

Los GeoNode, de una manera similar a los NameNode y CNode, pueden configurarse para mantener una lista de DataNode de la agrupación junto con su respectivo estado (vivo, muerto, desmantelado), así como su utilización de recursos tal como, por ejemplo, el número de transferencias de datos en progreso y uso de discos local.

Registros de DataNode de coordinación

En una agrupación de WAN de acuerdo con la Figura 8, los DataNode pueden configurarse para comunicarse (por ejemplo, emitir una solicitud) únicamente con GeoNode nativos. Particularmente, los nuevos DataNode que se registran en el sistema de ficheros distribuido no están configurados para enviar su información de registro directamente a los GeoNode en los centros de datos externos. Puede proporcionarse un proceso de registro de DataNode coordinado, mediante el que cuando un DataNode se registra con un GeoNode nativo, ese GeoNode nativo envía la propuesta de registro de DataNode al motor de coordinación 822 y procesa el registro después de que se alcance el correspondiente acuerdo.

Cuando un GeoNode recibe este correspondiente acuerdo de registro de DataNode, puede invocar un procedimiento de registro que puede ser similar al procedimiento realizado por un NameNode o un CNode. Si el DataNode de registro es nativo, entonces no es necesaria una acción adicional. Para acuerdos de registro de DataNode con respecto a un DataNode externo recién registrado, los GeoNode establecen adicionalmente el estado del DataNode externo recién registrado como desmantelado y lo marcan como externo, ya que el GeoNode no se comunica directamente con los DataNode externos. De hecho, los DataNode externos pueden siempre observarse por los GeoNode como "desmantelados", ya que los GeoNode no pueden comunicar, controlar o recopilar de otra manera información directamente desde los DataNode externos. En particular, los DataNode externos no se usan como objetivos de canalización para los bloques. Esta restricción mantiene velocidades similares a LAN para operaciones de acceso de datos de cliente, ya que los bloques se consideran que están completamente replicados tan pronto como un componente completo (por ejemplo, 3) de réplicas está confirmado en los DataNode del centro de datos local. De manera similar, los DataNode externos no pueden declararse que están muertos basándose en los GeoNode locales que caen para recibir sus indicadores de funcionamiento dentro del intervalo de caducidad del indicador de funcionamiento puesto que los DataNode únicamente se comunican con sus GeoNode locales y no emiten indicadores de funcionamiento a los GeoNode externos. Este comportamiento es consisten con el de los DataNode desmantelados en, por ejemplo, una agrupación de HDFS.

Descriptor de DataNode externo

Un DataNode registrado, ya sea externo o nativo, puede representarse dentro de un GeoNode por descriptores de DataNode. Un descriptor de DataNode externo es una extensión del descriptor de DataNode (regular, local), con los siguientes campos adicionales:

• Un marcador de DataNode externo para distinguirlo de los nodos nativos;

• El estado del DataNode, como es conocido dentro de su propio (nativo para él) centro de datos, puede estar caracterizado por vivo, muerto o desmantelado. El estado del DataNode es importante para que el GeoNode conozca cuándo selecciona un DataNode objetivo externo para replicación de bloque externa (no para canalizar réplicas), como muerto, desmantelado o nodos desmantelados que no deben usarse como objetivos de réplica. Obsérvese que esto es diferente del estado "desmantelado" de un DataNode externo recién registrado con respecto a un GeoNode nativo.

• Los DataNode externos se establecen con intervalo de caducidad de indicador de funcionamiento infinito, ya que los DataNode externos no se espera o no están configurados para comunicarse con (por ejemplo, emitir solicitudes a) directamente con los GeoNode fuera de sus propios centros de datos.

Un GeoNode no puede conocer si los DataNode externos están vivos o muertos ya que únicamente los GeoNode nativos pueden detectar cuándo un DataNode deja de enviar sus indicaciones de funcionamiento. En un registro de agrupación de WAN, los eventos de caducidad de indicador de funcionamiento y de desmantelamiento están coordinados, de modo que todos los GeoNode, tanto externos como nativos, pueden rastrear el estado actualizado de todos los DataNode.

Informes de bloque externo

Se envían informes de bloque por los DataNode para informar al NameNode de las réplicas de bloque en su posesión. Por ejemplo, cuando arranca una agrupación inicialmente, los GeoNode locales no conocen dónde se almacena ninguna de las réplicas. Son los informes de bloque los que informan los GeoNode locales de la ubicación, en los DataNode locales, de cada réplica en la agrupación. En el contexto de LAN, los DataNode informan sus bloques a todos los CNode.

Sin embargo, en el contexto de WAN puede ser inaceptablemente costoso e intensivo en recursos que los DataNode externos envíen informes de bloque enteros a través de la WAN 808 a los GeoNode de otros centros de datos. Sin embargo, los GeoNode necesitan conocer las ubicaciones de las réplicas almacenadas en los DataNode externos. Por lo tanto, un ejemplo proporciona que los GeoNode escriban informes de bloque en el sistema de ficheros distribuido (por ejemplo, HDFS) mismo como un fichero en un directorio de sistema, disponible para todos los GeoNode a través de los centros de datos. Una implementación solicita que se forme la ruta de fichero de informe de bloque de acuerdo con la siguiente convención de nomenclatura:

/consensus/blockReports/<blockPoolId>/<dc-Name>/<storageID>/br_<hash-report>

donde <hash-report> comprende una función de troceo (MD5, por ejemplo) del informe de bloque.

Únicamente los GeoNode de no replicadores de bloques están configurados para escribir informes de bloque externos en el sistema de ficheros. Por lo tanto, múltiples GeoNode no replicadores de bloques pueden estar así configurados y pueden intentar escribir el mismo informe de bloque. Sin embargo, únicamente un GeoNode no replicador de bloques de este tipo debería tener éxito. Añadir una función de troceo (por ejemplo, MD5) del informe al nombre de ruta hace posible que los GeoNode reconozcan que algún otro GeoNode local ya está escribiendo el informe de bloque y puede por lo tanto evitar conflictos de escritura. El escritor con éxito a continuación borrará cualquier fichero de informe de bloque previo del directorio.

Los ficheros de informe de bloque se replican a través de los centros de datos usando una técnica de replicación de bloque externa. Los GeoNode pueden configurarse para interrogar periódicamente el directorio de sistema para nuevos informes de bloque. Una vez que el fichero está disponible para lectura, los GeoNode de otros centros de datos lo leen y procesan el informe de bloque externo. Durante la operación regular, los informes de bloque externos periódicos proporcionan a los GeoNode con una vista actualizada de dónde están ubicadas las réplicas de bloque en otros centros de datos en la agrupación, de una manera similar a la manera en la que los DataNode emiten informes de bloques para actualizar los CNode en el contexto de LAN.

Cuando está arrancando la agrupación de WAN completa, los DataNode de cada centro de datos que están generando y enviando informes de bloque a sus GeoNode nativos y los GeoNode empiezan a recibir sus informes de bloque nativos. Como se ha indicado anteriormente, una vez que un bloque de datos alcanza la replicación completa en un centro de datos dado, un GeoNode no replicador de bloques puede emitir una propuesta de FRR para posibilitar de esta manera que los GeoNode externos obtengan información acerca de las réplicas de bloque externas (para ellos).

En caso de que únicamente un GeoNode se reinicie en una agrupación de WAN en ejecución, los FRR de otro centro de datos no se envían ya que el recuento de réplica de bloques no está cambiando. Por lo tanto, los ficheros de informe de bloque externos pueden constituir el único mecanismo mediante el que un GeoNode de reinicio puede aprender de las ubicaciones en las que están almacenadas las réplicas externas. Se observa que mientras que el GeoNode está aprendiendo las ubicaciones de réplicas externas usando el proceso de FRR anteriormente detallado, las solicitudes de cliente GetBlockLocations() pueden fallar. De acuerdo con una realización, se realizan provisiones para tales solicitudes de cliente para migración tras error a los GeoNode en otros centros de datos cuando aún son desconocidas ubicaciones externas para los GeoNode del centro de datos al que se envió la solicitud de cliente.

Arranque de GeoNode

La secuencia de arranque de GeoNode puede rastrear la del CNode en el contexto de LAN, pero durante unos pocos números aleatorios utilizados una sola vez. Para convertir una única agrupación de NameNode a una agrupación de WAN, el directorio de almacenamiento del NameNode puede distribuirse a todos los nodos (por ejemplo, los centros de datos) aprovisionados para ejecutar los GeoNode, y a continuación iniciar la agrupación. Como alternativa, puede iniciarse un único GeoNode cuando el NameNode estaba en ejecución. Pueden añadirse a continuación los GeoNode adicionales en un estado vacío de manera que forman una agrupación de LAN local, y pueden añadirse los GeoNode adicionales en uno o más otros centros de datos. Cada GeoNode que se une a la agrupación puede a continuación descargar una imagen del espacio de nombres desde uno de los nodos existentes y empezar a aprender acuerdos, empezando desde el GSN del punto de comprobación descargado hasta que alcance el GSN más actual, como se ha detallado anteriormente con relación a CNode. Si un GeoNode que reinicia necesita descargar la imagen del espacio de nombres, un ejemplo solicita que el GeoNode que reinicia seleccione preferentemente uno de los otros GeoNode nativos como un ayudante, si estuviera disponible, lo que evita transferencias menos eficientes a través de la WAN 808.

Restauración de estado externo

En comparación con los CNode, los GeoNode en arranque pueden configurarse para realizar una etapa adicional de relleno de su estado externo. Una etapa adicional de este tipo puede comprender añadir una etapa final de adición (aprender acerca de) DataNode externos y réplicas de bloque externas.

Los DataNode, como se detalla en el presente documento, pueden configurarse para registrarse con un GeoNode nativo, tras lo cual ese GeoNode nativo envía una propuesta de registro de DataNode al proceso de motor de coordinación 822 (que abarca lógicamente toda la agrupación a través de los centros de datos) y procesa el registro después de que se alcance el correspondiente acuerdo. Por lo tanto, cuando está iniciándose toda la agrupación, todos los GeoNode aprenden acerca de los DataNode externos y las réplicas de bloque externas a través de acuerdos de registro de DataNode y de informe de réplica externa, respectivamente.

Cuando una agrupación está activa y un único GeoNode en la misma se está reiniciándose, los registros externos y los informes de réplica externos pueden no estar inmediatamente disponibles. Como se ha desvelado en detalle anteriormente, las ubicaciones de réplicas externas anteriores pueden restaurarse de ficheros de informe de bloque externos, que pueden almacenarse de manera persistente en el sistema de ficheros distribuido (por ejemplo, HDFS). Sin embargo, antes de que estos ficheros de informe de bloque puedan leerse, el GeoNode necesita aprender acerca de los DataNode externos donde se almacenan estas réplicas.

Cuando se reinicia un GeoNode y/o se une nuevamente a la agrupación, el GeoNode puede emitir una propuesta de recuperación de acuerdos antes de que empiece a aprender acuerdos perdidos. Esto permite que el GeoNode marque el GSN en el que el GeoNode puede considerarse a sí mismo actualizado. De hecho, el CE 822 emite un acuerdo que corresponde a la propuesta emitida, acuerdo que se incorpora en la secuencia ordenada global. De esta manera, cuando el GeoNode aprende sobre su propio acuerdo de recuperación de acuerdos junto con todos los acuerdos ordenados antes de su propio acuerdo de recuperación de acuerdos, puede considerarse que la "captura" está completa y puede considerarse que el estado del espacio de nombres almacenado es actual y coherente. En este momento, el espacio de nombres almacenado en el GeoNode puede permanecer posteriormente actual a través del GeoNode que consume los acuerdos a medida que se emiten por el CE 822. Cuando los GeoNode reciben un acuerdo de recuperación de acuerdos desde un GeoNode externo, pueden marcar adicionalmente todos sus DataNode nativos para registro, lo que significa que se solicitará a los DataNode nativos que se vuelvan a registrar en el siguiente indicador de funcionamiento. Esto posibilita que el nuevo GeoNode aprenda acerca de DataNode externos mediante acuerdos de registro de DataNode (que se reciben por todos los GeoNode, a través de los centros de datos), que el nuevo GeoNode recibirá después de su propio acuerdo de recuperación de acuerdos, cuando el espacio de nombres está actualizado.

Recuperación de cesión

Gestión de cesión

Un sistema de ficheros distribuido (tal como, por ejemplo, HDFS) puede configurarse para permitir únicamente un cliente como el escritor en un fichero particular. Para hacer aplicar la semántica de escritor único (y para evitar de esta manera que dos clientes diferentes abran el mismo fichero y comiencen a escribir en él), se introduce el concepto de cesión. Puede crearse una cesión cuando se crea o abre un fichero para su anexión. La cesión identifica el fichero y el cliente (único) que actualmente escribe en el fichero. La cesión puede destruirse o marcarse de otra manera como caducada cuando el fichero está cerrado. Una cesión no caducada puede operar para no permitir a otros clientes que tengan acceso de escritura al fichero durante la duración de la misma.

Un proceso de gestor de cesión puede configurarse para mantener cesiones para un NameNode. Si el cliente al que se asigna la cesión muere antes de cerrar el fichero asociado con la cesión, la cesión puede recopilarse y descartarse por el mismo sistema de ficheros. Antes de descartar la cesión, el sistema de ficheros puede verificar si el fichero está en un estado coherente y, si no, puede realizar una recuperación de los bloques de fichero.

Un proceso de recuperación de cesión puede desencadenarse por un NameNode, cuando caduca cualquiera de un límite definitivo en la cesión de fichero (tal como cuando el titular de la cesión original queda silenciado y nadie cierra el fichero durante un periodo de tiempo predeterminado), o cuando caduca un límite flexible (por ejemplo, 10 minutos) y otro cliente solicita derechos de acceso de escritura en el fichero. El proceso de recuperación de cesión puede comprender dos etapas. De hecho, para iniciar la recuperación de cesión, el NameNode puede solicitar InternalReleaseLease(), que puede planificar la recuperación de réplica de bloque posterior según sea necesario. Posteriormente, para llevar a cabo la recuperación de réplica de bloque, el NameNode puede generar una indicación de nueva generación para el último bloque del fichero, y puede seleccionar un DataNode primario para sincronizar los metadatos de bloque con otras réplicas usando la indicación de nueva generación como el ID de recuperación. El DataNode primario puede a continuación comunicarse con los otros DataNode para coordinar la longitud correcta del bloque. Por ejemplo, la longitud correcta del bloque puede seleccionarse como la longitud más pequeña que es común a todos los DataNode que almacenan el bloque o porción del bloque en cuestión. Una vez que tal coordinación está completa, el DataNode primario puede confirmar los resultados de la recuperación al GeoNode usando una solicitud CommitBIockSynchronizationO. La solicitud CommitBlockSynchronizationQ puede configurarse para actualizar el último bloque del fichero con la indicación de nueva generación, la nueva longitud y las nuevas ubicaciones de réplica. El fichero puede a continuación cerrarse. El último bloque puede eliminarse si no se han escrito datos en el mismo por el cliente antes de que muriera.

Cesiones de LAN y CNode

En el contexto de LAN, uno cualquiera de los múltiples CNode puede desencadenar una recuperación de cesión cuando su gestor de cesiones detecta que ha caducado una cesión. Sin embargo, cualquier cambio al fichero que era el objeto de la cesión o a sus bloques de datos debe coordinarse para proporcionar replicación coherente en todos los CNode.

El estado del fichero puede analizarse en InternalReleaseLease(), pero el CNode no modifica el fichero, a diferencia del NameNode, en esa etapa. Si el fichero analizado ya está cerrado, el CNode simplemente vuelve. Sin embargo, si el fichero no está ya cerrado, el proceso InternalReleaseLease() emite una de dos propuestas, dependiendo del estado del último bloque del fichero:

1) Puede emitirse una propuesta completa si todos los bloques del fichero analizado están completos, posibilitando de esta manera que los CNode simplemente cierren el fichero de una manera coordinada;

2) Puede emitirse una propuesta de recuperación de bloque si los bloques del fichero analizado no están completos y es necesaria una recuperación de réplica de bloque.

Si se desencadena la recuperación por una caducidad de límite flexible de la cesión mientras se procesa un acuerdo (tal como anexar, abrir o recuperar cesión), el CNode que ejecuta un acuerdo de este tipo puede a continuación desencadenar la recuperación de bloque. Si caduca el límite definitivo para la cesión, a continuación, únicamente el replicador de bloques propondrá que está completo o la recuperación de bloque. De esta manera, se minimiza la posibilidad de que múltiples CNode inicien la recuperación de cesión del mismo fichero. Puede definirse un procedimiento ShouldReleaseLease() si el CNode puede emitir las propuestas.

Cuando el acuerdo completo (todos los DataNode pertinentes almacenan ahora los mismos bloques del fichero) alcanza un CNode, el CNode puede cerrar el fichero que era el objeto de la caducidad de cesión, completando de esta manera la recuperación de cesión de manera ordenada. En el caso que se proponga la propuesta completa por múltiples CNode, entonces el primer acuerdo completo a tiempo puede cerrar el fichero y los posteriores no necesitan hacer nada adicional.

El acuerdo de recuperación de bloque, en respuesta a la propuesta de recuperar bloque, puede realizar InitializeBlockRecovery(), que

1) genera un nuevo GSN, que es el ID de recuperación de bloque único;

2) escribe un registro de registro diario acerca de la reasignación de cesión;

3) cambia el último estado de bloque a un estado BAJO_RECUPERACIÓN, y

3) añade el bloque a una cola a recuperarse.

Incluso aunque todos los CNode puedan planificar la recuperación de réplica de bloques para el último bloque, únicamente el CNode designado como el único replicador de bloques solicitará realmente al DataNode primario para realizar la recuperación, puesto que únicamente el CNode del replicador de bloques puede responder a los DataNode con comandos de DataNode.

El CNode designado como el replicador de bloques puede a continuación planificar la recuperación de bloque con el DataNode primario. En la etapa final de la recuperación, el DataNode primario puede confirmar los resultados de recuperación al CNode replicador de bloques con una solicitud CommitBlockSynchronization(). CommitBlockSynchronization() también está coordinada, ya que es efectiva para actualizar o eliminar el último bloque y/o cerrar el fichero, lo que puede incluir realizar un registro diario para mantener un registro persistente. El CNode replicador de bloques puede a continuación enviar una propuesta de sincronización de confirmación de bloque y responder al DataNode primario cuando se alcanza y ejecuta el correspondiente acuerdo. La ejecución del acuerdo realiza la acción CommitBlockSynchronization() del NameNode regular.

GeoNode: cesiones de WAN

Recuerde que los GeoNode no puede recuperar réplicas externas, ya que los DataNode informan únicamente a los GeoNode nativos. Los bloques se crean inicialmente en el centro de datos donde se origina la creación de fichero. Las réplicas de los bloques completados del fichero que se está escribiendo se transfieren a otros centros de datos únicamente tras alcanzar la replicación completa en el centro de datos original.

En el contexto de WAN, supóngase que se creó un fichero por un cliente en un centro de datos A (DCA) y el cliente murió antes de cerrar el fichero. En el centro de datos B (DCB), los GeoNode tendrán la información acerca del fichero y sus bloques. El DCB puede contener también réplicas de bloque nativas de bloques completados del fichero (bloques que están completamente replicados en el DCA). Sin embargo, el DCB no debe contener ninguna réplica de bloques que están bajo construcción.

ShouldReleaseLease() para WAN actuará de la misma manera que para LAN, en ambos de los casos de caducidad de límite flexible y definitivo. Es decir, puede desencadenarse la recuperación de cesión por cualquier GeoNode en cualquiera de los centros de datos. De manera similar, el acuerdo completo puede configurarse para funcionar en el caso de WAN como lo hace en el caso de LAN y el GeoNode puede cerrar el fichero.

Mientras se ejecuta el acuerdo de recuperación de bloque, cada GeoNode comprueba ubicaciones esperadas externas y nativas del último bloque del fichero. Posteriormente, las acciones adicionales dependen del estado de los bloques del fichero que es el objeto de la cesión:

1. Si un bloque del fichero tiene únicamente ubicaciones externas, entonces el GeoNode no inicializa la recuperación de inicialización de bloque;

2. Si el bloque tiene únicamente ubicaciones nativas, entonces el GeoNode debe realizar la recuperación de inicialización de bloque para garantizar que se realiza la recuperación en el centro de datos que contiene las réplicas;

3. Si el bloque tiene tanto ubicaciones externas como nativas, entonces el GeoNode en el DC que envió la propuesta de recuperación de bloque debe realizar la recuperación de inicialización de bloque;

4. Si el bloque no tiene réplicas, entonces puede planificarse la recuperación de inicialización de bloque para un DataNode vivo aleatorio. Esto se realiza en el GeoNode que pertenece al DC, que envió la propuesta de recuperación de bloque.

Por lo tanto, únicamente un GeoNode de replicador de bloque en uno de los DC inicializará la recuperación de bloque. El comando para recuperar réplicas se enviará al DataNode nativo primario, pero con todas las ubicaciones esperadas, externas y nativas. El DataNode primario determina la longitud correcta del bloque hablando a todos los DataNode que contienen las réplicas. Esto puede provocar la comunicación entre los DataNode en diferentes DC. Después de la recuperación, el DataNode primario puede enviar una solicitud de sincronización de confirmación de bloque al GeoNode del replicador de bloques, que puede a continuación enviar una propuesta de sincronización de conformación de bloque.

Un correspondiente acuerdo de sincronización de confirmación de bloque puede contener ubicaciones externas y nativas como nuevos objetivos para las réplicas. Las ubicaciones externas se tratan por el GeoNode actual como un informe de réplica externo. Es decir, almacena las ubicaciones recién informadas como las externas, completa a la fuerza el último bloque y completa el fichero si se solicita.

Replicación asimétrica de bloques

La replicación de bloques no necesita ser igual a través de todos los centros de datos en la agrupación. De hecho, puede proporcionarse un factor de replicación seleccionable por fichero, factor de réplica que puede establecerse por fichero cuando se crea el fichero. El factor de replicación puede resetearse en un tiempo posterior usando una propuesta SetReplication(). Pueden crearse ficheros con un factor de replicación por defecto. Por ejemplo, puede establecerse una replicación por defecto de 3. Como alternativa, pueden establecerse otros factores de replicación tales como, por ejemplo, 2 o 5. En una agrupación de WAN, tales semánticas significarían de manera ordinaria que los ficheros tendrían el mismo factor de replicación en diferentes centros de datos, siendo el factor de replicación igual al valor especificado por el creador del fichero.

Sin embargo, puede ser deseable permitir una replicación reducida o aumentada en diferentes centros de datos. Por ejemplo, cuando un centro de datos se considera el primario y se considera otro centro de datos que es el secundario, puede desearse mantener menos réplicas en el centro de datos secundario debido a, por ejemplo, restricciones de coste de hardware o de la calidad de servicio deseada.

De hecho, puede modificarse una solicitud de creación de fichero para permitir factores de replicación por defecto por centro de datos. En este caso, puede establecerse un comportamiento por defecto razonable al factor de replicación al valor por defecto del centro de datos actual. Por ejemplo, supóngase que el DCA tiene replicación por defecto rA y el DCB tiene su ajuste por defecto a rB. Supóngase ahora que un cliente ubicado en el d Ca crea un fichero con el factor de replicación r. A continuación, el DCA establecerá su replicación para el fichero a r, mientras que el DCB establecerá su factor de replicación a su replicación por defecto rB. Por lo tanto, un único parámetro de factor de replicación en una solicitud de creación de fichero puede tratarse como el valor de replicación para el fichero en el DC de origen, mientras que otros DC usan sus factores de replicación por defecto para establecer la replicación del fichero.

El factor de replicación puede modificarse por una solicitud SetReplication(), que puede configurarse para permitir un único valor de replicación como un parámetro. En una agrupación de WAN, este parámetro puede tratarse como el nuevo factor de replicación del fichero en el centro de datos donde se ejecutó la solicitud del cliente. Otros centros de datos pueden simplemente ignorar el correspondiente acuerdo, establecer replicación, si se propuso por un GeoNode externo. Usando un mecanismo de este tipo, el factor de replicación puede establecerse a voluntad en diferentes centros de datos. El factor de replicación puede volverse un atributo de fichero específico de centro de datos y puede excluirse, por lo tanto, de una replicación de metadatos de uno a uno.

Replicación de datos selectiva

La replicación de datos selectiva posibilita que datos seleccionados sean únicamente visibles desde un centro de datos o centros de datos designados y no estén permitidos a replicarse o a ser accedidos desde otros centros de datos. Puede implementarse una o más de las siguientes alternativas:

- se replica un directorio para y es accesible desde todos los centros de datos

- se replica un directorio para y es legible desde todos los centros de datos, pero es escribible únicamente en un sitio dado;

- se replica un directorio en algunos centros de datos, pero nunca se replica en otro centro de datos;

- se replica un directorio en y es visible únicamente en un único centro de datos.

Recuerde que, en la presente arquitectura replicada, se supone que se mantiene el mismo único espacio de nombres en múltiples nodos. El proceso de motor de coordinación 822, además, garantiza que la replicación de metadatos y los datos de sistema de ficheros entre los GeoNode y a través de los centros de datos es coherente. Por lo tanto, la expresión "replicación de datos selectiva" es aplicable a los datos almacenados en la agrupación geográficamente distribuida, en lugar de en el espacio de nombres.

En la replicación asimétrica de bloques introducida anteriormente, se introdujo un atributo de fichero específico de centro de datos; en concreto, la replicación. En este contexto, el valor de caso especial de 0 desempeña una función significativa en la replicación de datos selectiva. De hecho, si el atributo de factor de replicación de un fichero se establece a 0 para el centro de datos (DCB), entonces los bloques de ese fichero nunca se replican en el DCB. De manera ordinaria, las agrupaciones de HDFS actuales no permiten crear ficheros con replicación 0. Sin embargo, los ejemplos amplían SetReplication() para permitir un valor de 0. La solicitud SetReplication() cambia el atributo de factor de replicación del fichero únicamente para el centro de datos actual. Por lo tanto, el valor de 0 no permitirá la replicación de bloques del fichero asociado con un valor de replicación de cero en ese centro de datos.

SetReplication() puede ampliarse para aplicarse a directorios también. Si se establece un atributo de factor de replicación en un directorio, entonces todos los ficheros que pertenecen al subárbol heredan ese atributo de factor de replicación, a menos que el atributo de factor de replicación se resetee explícitamente a otro valor para un subdirectorio particular o un fichero particular. Establecer unos atributos de factor de replicación en los directorios puede pensarse como una extensión del parámetro de replicación por defecto, en el que un atributo de factor de replicación puede establecerse en el directorio raíz. Si no se establece explícitamente, el atributo de factor de replicación de un fichero puede determinarse por el atributo de factor de replicación del padre más cercano que tenía su replicación establecida.

La visibilidad selectiva de ficheros y directorios en diferentes centros de datos puede controlarse por permisos, que pueden definirse como otro atributo específico de centro de datos. Las solicitudes SetPermissions() y SetOwner() no propagan sus valores de entrada a otros centros de datos, de manera similar a SetReplication(). De acuerdo con una implementación, establecer permiso a 000 a un directorio a un fichero prohíbe el acceso a los respectivos objetos en ese centro de datos, haciendo de manera eficaz a tales ficheros "invisibles" en el centro de datos. Puede proporcionarse al usuario raíz (que representa el administrador de la agrupación) con la autoridad completa para cambiar propietarios y permisos.

Funciones, tolerancia a desastres en una agrupación de WAN

Como se ha indicado anteriormente, los CNode en un sistema coordinado distribuido pueden asumir tres funciones principales: proponente, aprendiz y aceptador, donde cada nodo puede asumir más de una función de este tipo. A menudo en una agrupación de LAN, todos los CNode asumen todas las tres funciones. De hecho, para mantener su estado en sincronización con los CNode de la LAN, cada CNode debe ser un aprendiz. Para procesar solicitudes de cliente, cada CNode debe ser también un proponente. La función del aceptador puede asignarse a tantos CNode como sea posible para maximizar la fiabilidad del sistema, es decir, resiliencia a fallos de nodo simultáneos. En una implementación de este tipo, uno o más CNode pueden fallar sin impactar de manera sustancial el servicio proporcionado, siempre que la mayoría de los CNode estén aún activos y en ejecución.

Una agrupación de WAN que comprende dos o más centros de datos debe proporcionar también tolerancia a fallos de GeoNode individuales. Además, se desea mantener el servicio activo si uno de los centros de datos falla o por cualquier razón queda aislado de (es decir, inaccesible para) el otro o los otros centros de datos. Esto puede ocurrir cuando, por ejemplo, el canal de WAN está roto entre los centros de datos. Debe quedar claro que, si dos centros de datos quedan aislados entre sí, entonces ambos de ellos no deben operar de manera independiente, puesto que podrían hacer cambios inconsistentes en sus respectivas instancias del espacio de nombres. Sin embargo, uno de ellos debe permanecer operativo, mientras que al otro debe proporcionársele la capacidad para capturar cuando se restauren las comunicaciones con el centro de datos operativo. Esto puede conseguirse ejecutando un número impar de los GeoNode, lo que significa que un centro de datos tendrá más GeoNode que el otro.

Puede usarse un enfoque diferente cuando los centros de datos están configurados simétricamente. Por ejemplo, puede asumirse que el DCA y el DCB ejecutan 3 GeoNode cada uno. Los GeoNode del DCA son aceptores, estando designado uno de los GeoNode del DCA como un desempatador, lo que significa que tres GeoNode forman un quórum si incluyen el GeoNode desempatador designado. En esta configuración, el DCA puede continuar la operación incluso en el caso de que ningún GeoNode desde el DCB esté disponible. En esta configuración, el DCB, que está aislado del DCA, perderá el quórum y se detendrá (es decir, no procesa ningún acuerdo adicional que conduzca a cambios en su instancia del espacio de nombres) hasta que se restaure la comunicación con al menos el DCA.

Una configuración de este tipo puede ser particularmente útil si los centros de datos experimentan cambios periódicos en las cargas de trabajo. Por ejemplo, supóngase que el DCA tiene una carga de procesamiento superior durante horas diurnas y que el DCB tiene una carga de procesamiento comparativamente superior durante las horas nocturnas. El quórum puede rotarse asignando funciones de aceptador a los GeoNode del DCA durante el día y, en correspondencia, asignando funciones de aceptador a los GeoNode del DCB durante las horas nocturnas.

La Figura 9 es un diagrama de flujo de un método implementado por ordenador. Como se muestra, el bloque B91 solicita el establecimiento de una única agrupación de sistema de ficheros distribuido (dispositivo informático) que abraca, a través de una red de área extensa, un primer centro de datos y un segundo centro de datos geográficamente remoto. Además, pueden incluirse centros de datos adicionales (no mostrados) y administrarse por el mismo sistema de ficheros distribuido. Como se muestra en la Figura 8, el primer centro de datos 804 puede comprender una pluralidad de primeros NameNode (también denominados GeoNode en el presente documento) 810, 812 y 814 (otros de los primeros NameNode no mostrados en la Figura 8) y una pluralidad de primeros DataNode (también denominados DataNode en el presente documento) que cada uno está configurado para almacenar bloques de datos de ficheros de cliente, como se muestra en 824, 826, 828 y 830 (otros de los primeros DataNode no mostrados en la Figura 8). El segundo centro de datos, como se muestra en la Figura 8 en 806, puede comprender una pluralidad de segundos NameNode 816, 818 y 820 (otros de los segundos NameNode no mostrados en la Figura 8) y una pluralidad de segundos DataNode 832, 834, 836 y 838 (otros de los segundos DataNode no mostrados en la Figura 8) que cada uno está configurado para almacenar bloques de datos de ficheros de cliente. El bloque B92 solicita almacenar, en cada uno de la pluralidad de primeros NameNode en cada uno de la pluralidad de segundos NameNode, el estado del espacio de nombres de la agrupación 802. Como se muestra en B93, el estado del espacio de nombres almacenado en los primeros NameNode puede actualizarse en respuesta a los bloques de datos que se escriben en uno o más primeros DataNode seleccionados. De manera similar, B94 solicita el estado del espacio de nombres almacenado en los segundos NameNode que puede actualizarse en respuesta a bloques de datos que se escriben en uno más segundos DataNode seleccionados. Finalmente, como se muestra en B95, las actualizaciones en el estado del espacio de nombres almacenado en los primeros NameNode (810, 812, 814...) y las actualizaciones en el estado del espacio de nombres almacenado en los segundos NameNode (816, 818, 820...) pueden coordinarse (por ejemplo, mediante el proceso de motor de coordinación 822) para mantener el estado del espacio de nombres coherente a través del primer y segundo centros de datos 804, 806 de la única agrupación de sistema de ficheros distribuido. Tal actualización puede llevarse a cabo de acuerdo con el conjunto ordenado de acuerdos desvelado en el presente documento. Es decir, mientras que el estado del espacio de nombres almacenado en un NameNode (ya sea un CNode o GeoNode) puede ser diferente del estado del espacio de nombres almacenado en otro NameNode en cualquier tiempo dado, la secuencia globalmente ordenada de acuerdos desvelada en el presente documento, según se administra por el proceso de motor de coordinación 822 (que puede configurarse para ejecutarse en cada una de la primera y segunda pluralidad de NameNode), garantiza que cada uno de los NameNode, independientemente del centro de datos dentro del que está ubicado, proporcionará eventualmente su estado actualizado del espacio de nombres en acuerdo con el estado del espacio de nombres almacenado en otros NameNode a través de la ejecución secuencial del conjunto ordenado de acuerdos.

Como cada uno de los primeros NameNode 810, 812, 814 está en un NameNode "activo" (a diferencia de, por ejemplo, un NameNode de "repliegue", "inactivo" o "en espera"), uno o más de los otros primeros NameNode 810, 812, 814 pueden estar actualizando el estado del espacio de nombres en el primer centro de datos 804 mientras que uno o más de los segundos NameNode 816, 818, 820 puede también estar actualizando el estado del espacio de nombres en el segundo centro de datos 806.

Cada uno de la pluralidad de primeros NameNode puede estar configurado para actualizar el estado del espacio de nombres mientras que uno o más de los otros de los primeros NameNode en el primer centro de datos también está actualizando el estado del espacio de nombres. Cada uno de la pluralidad de segundos NameNode puede estar configurado para actualizar el estado del espacio de nombres mientras que uno o más de los otros de los segundos NameNode en el segundo centro de datos también está actualizando el estado del espacio de nombres. Cada uno de la pluralidad de primeros NameNode en el primer centro de datos puede también estar configurado para actualizar el estado del espacio de nombres mientras que cualquiera de la pluralidad de segundos NameNode en el segundo centro de datos también está actualizando el estado del espacio de nombres.

Cada uno de los primeros DataNode puede estar configurado para comunicarse únicamente con la pluralidad de primeros NameNode en el primer centro de datos. De manera similar, cada uno de los segundos DataNode puede estar configurado para comunicarse únicamente con la pluralidad de segundos NameNode en el segundo centro de datos. El proceso de motor de coordinación puede estar configurado para recibir propuestas desde la primera y segunda pluralidad de NameNode para actualizar el estado del espacio de nombres y para generar, en respuesta, un conjunto ordenado de acuerdos que especifica el orden en el que la pluralidad de la primera y la segunda pluralidades de NameNode han de actualizar el estado del espacio de nombres. De hecho, la pluralidad de primeros NameNode y la pluralidad de segundos NameNode pueden configurarse para retardar actualizaciones en el estado del espacio de nombres hasta que se reciba el conjunto ordenado de acuerdos desde el proceso de motor de coordinación. Además, el proceso de motor de coordinación (822 en la Figura 8) puede estar configurado para mantener el estado del espacio de nombres coherente tras un fallo de uno o más del primer y segundo NameNode y/o un fallo de uno o más del primer y segundo DataNode.

Por ejemplo, el sistema de ficheros (único, geográficamente distribuido) puede ser o comprender una versión del sistema de ficheros distribuido Hadoop (HDFS). Pueden idearse o adaptarse otros sistemas de ficheros distribuidos, como pueden reconocer los expertos en la materia. Las réplicas de al menos algunos de los bloques de datos de un fichero de un cliente del primer centro de datos pueden almacenarse en unos seleccionados de la pluralidad de segundos DataNode en el segundo centro de datos y las réplicas de al menos alguno de los bloques de datos de un fichero de un cliente del segundo centro de datos puede almacenarse en unos seleccionados de la pluralidad de primeros DataNode en el primer centro de datos.

Cada uno de los primeros DataNode del primer centro de datos puede configurase para enviar de manera asíncrona bloques de datos seleccionados a uno seleccionado de la pluralidad de segundos DataNode del segundo centro de datos a través de la WAN. Los bloques de datos seleccionados pueden enviarse desde el primer centro de datos al segundo centro de datos después de un número predeterminado de réplicas (por ejemplo, 3) de los bloques de datos seleccionados que se almacenan en unos seleccionados de la pluralidad de primeros DataNode en el primer centro de datos.

Al menos alguno de la pluralidad de primeros NameNode (todos menos el NameNode con responsabilidades de replicador de bloques asignadas) puede estar configurado para generar un informe de bloque externo que incluye una lista de todos los bloques de datos almacenados en la pluralidad de primeros nodos de datos para su consumo por la pluralidad de segundos NameNode. De manera similar, al menos alguno de la pluralidad de segundos NameNode (todos menos el NameNode con responsabilidades de replicador de bloques asignadas) puede estar configurado para generar un informe de bloque externo que incluye una lista de todos los bloques de datos almacenados en la pluralidad de segundos DataNode, para su consumo por la pluralidad de primeros NameNode. El informe de bloque externo generado puede escribirse como un fichero de informe de bloque en el sistema de ficheros, y cada uno del primer y segundo NameNode en el primer y segundo centros de datos puede leer periódicamente posteriormente el fichero de informe de bloque desde el sistema de ficheros y actualizar en correspondencia su respectivo estado almacenado del espacio de nombres.

La pluralidad de primeros NameNode y la pluralidad de primeros DataNode pueden configurarse para completar la escritura de los bloques de datos de un fichero de cliente del primer centro de datos antes de que se envíe cualquiera de los bloques de datos del fichero de cliente al segundo centro de datos a través de la red de área extensa. De esta manera, las escrituras de cliente se completan a velocidades de LAN, mientras que pueden enviarse las réplicas de estos bloques de datos asíncronamente a otros centros de datos a velocidades de WAN. Los primeros NameNode y los primeros DataNode pueden configurarse para hacer que los bloques de datos de un fichero de cliente se repliquen un primer número predeterminado y seleccionable de veces en el primer centro de datos. De manera similar, los segundos NameNode y la pluralidad de segundos DataNode pueden estar configurados para hacer que los bloques de datos del fichero de cliente se repliquen un segundo número predeterminado y seleccionable de veces en el segundo centro de datos. El primer número predeterminado y seleccionable de veces puede ser el mismo o diferente del segundo número predeterminado y seleccionable de veces.

Aunque se han descrito ciertos ejemplos de la divulgación, estos ejemplos se han presentado por medio de ilustración únicamente y no se pretende que limiten el alcance de la divulgación. De hecho, los métodos implementados por ordenador novedosos, dispositivos y sistemas descritos en el presente documento pueden realizarse en otras diversas formas. Por ejemplo, un aspecto comprende un medio legible por máquina no transitorio tangible que tiene datos almacenados en el mismo que representan secuencias de instrucciones que, cuando se ejecutan por dispositivos informáticos, hacen que los dispositivos informáticos implementen un sistema de ficheros distribuido a través de una red de área extensa como se describe y muestra en el presente documento. Las secuencias de instrucciones pueden descargarse y a continuación almacenarse en un dispositivo de memoria (tal como se muestra en 702 en la Figura 7, por ejemplo), almacenamiento (dispositivo de medios fijo o de rotación u otro soporte de datos, por ejemplo). Los expertos en la materia apreciarán que, en diversas ilustraciones, las estructuras físicas y lógicas reales pueden diferir de aquellas mostradas en las figuras. Dependiendo de la divulgación, pueden eliminarse ciertas etapas descritas en los ejemplos anteriores, otras pueden añadirse. También, las características y atributos de las divulgaciones específicas anteriores pueden combinarse en diferentes maneras para formar ejemplos adicionales. El alcance de la presente divulgación se pretende que esté definido únicamente por referencia a las reivindicaciones adjuntas.

Claims

REIVINDICACIONES

1. Una agrupación de nodos que comprende dispositivos informáticos configurados para implementar un sistema de ficheros geográficamente distribuido único (802), comprendiendo la agrupación:

un primer centro de datos (804), que comprende:

una pluralidad de primeros dispositivos informáticos DataNode (824, 826, 828, 830), cada uno configurado para almacenar bloques de datos de ficheros de cliente;

una pluralidad de primeros almacenamientos persistentes locales;

una pluralidad de primeros dispositivos informáticos NameNode (810, 812, 814), cada uno configurado para almacenar un estado de un espacio de nombres de la agrupación y para actualizar el estado del espacio de nombres de la agrupación, en donde cada NameNode está configurado adicionalmente para almacenar el estado actualizado del espacio de nombres en un primer almacenamiento persistente local de la pluralidad de primeros almacenamientos persistentes locales;

un segundo centro de datos (806) que está geográficamente remoto de y acoplado al primer centro de datos mediante una red de área extensa, comprendiendo el segundo centro de datos:

una pluralidad de segundos dispositivos informáticos DataNode (832, 834, 836, 838), cada uno configurado para almacenar bloques de datos de ficheros de cliente;

una pluralidad de segundos almacenamientos persistentes locales;

una pluralidad de segundos dispositivos informáticos NameNode (816, 818, 820), cada uno configurado para almacenar el estado del espacio de nombres de la agrupación y para actualizar el estado del espacio de nombres de la agrupación, en donde cada NameNode está configurado adicionalmente para almacenar el estado actualizado del espacio de nombres en un segundo almacenamiento persistente local de la pluralidad de segundos almacenamientos persistentes locales;

en donde el espacio de nombres de la agrupación comprende información de sistema de ficheros y metadatos de todos los bloques de datos almacenados por la pluralidad de primeros y segundos dispositivos informáticos DataNode, y en donde la pluralidad de primeros y segundos dispositivos informáticos NameNode están configurados para actualizar el estado del espacio de nombres de la agrupación en respuesta a que se escriban bloques de datos en la pluralidad de primeros y segundos dispositivos informáticos DataNode; y

en donde la primera y la segunda pluralidad de dispositivos informáticos NameNode están configurados para coordinar la actualización del estado del espacio de nombres usando un motor de coordinación distribuido, en donde el motor de coordinación distribuido está configurado para:

recibir propuestas de la primera y la segunda pluralidad de dispositivos informáticos NameNode, en respuesta a solicitudes de cliente, en donde las propuestas son solicitudes para actualizar el estado del espacio de nombres, y generar, en respuesta, una secuencia globalmente ordenada de acuerdos que corresponden a las propuestas recibidas, en donde la secuencia globalmente ordenada de acuerdos está ordenada por números de secuencia globales, en donde la secuencia globalmente ordenada de acuerdos especifica un orden con el que han de actualizar la pluralidad de primeros y segundos dispositivos informáticos NameNode su respectivo estado almacenado del espacio de nombres,

en donde actualizar el estado del espacio de nombres comprende actualizar información de sistema de ficheros y metadatos de bloques de datos almacenados por la pluralidad de primeros y segundos dispositivos informáticos DataNode y en donde la pluralidad de primeros y segundos dispositivos informáticos NameNode están configurados para retardar actualizaciones en el estado del espacio de nombres hasta que dicha pluralidad de primeros y segundos dispositivos informáticos NameNode hayan recibido la secuencia ordenada de acuerdos desde el motor de coordinación distribuido.

2. La agrupación de la reivindicación 1, en donde cada uno de la pluralidad de primeros dispositivos informáticos NameNode (810, 812, 814) está configurado para actualizar el estado del espacio de nombres mientras que uno o más otros de los primeros dispositivos informáticos NameNode (810, 812, 814) en el primer centro de datos (804) o mientras que cualquiera de la pluralidad de segundos dispositivos informáticos NameNode (816, 818, 820) en el segundo centro de datos (806) también están actualizando el estado del espacio de nombres.

3. La agrupación de las reivindicaciones 1 o 2, en donde el motor de coordinación está configurado para mantener el estado del espacio de nombres coherente tras un fallo de uno o más del primer y segundo dispositivos informáticos NameNode, un fallo de uno o más de los primeros y segundos dispositivos informáticos DataNode o tras fallo del primer o el segundo centro de datos.

4. La agrupación de cualquier reivindicación anterior, en donde el sistema de ficheros geográficamente distribuido único comprende una versión del sistema de ficheros distribuido Hadoop (HDFS).

5. La agrupación de cualquier reivindicación anterior, en donde las réplicas de al menos alguno de los bloques de datos de un fichero escrito por un cliente del primer centro de datos se almacenan en unos seleccionados de la pluralidad de segundos dispositivos informáticos DataNode en el segundo centro de datos y en donde las réplicas de al menos alguno de los bloques de datos de un fichero de un cliente escritos por el segundo centro de datos se almacenan en unos seleccionados de la pluralidad de primeros dispositivos informáticos DataNode en el primer centro de datos.

6. La agrupación de cualquier reivindicación anterior, en donde cada uno de la pluralidad de primeros dispositivos informáticos DataNode del primer centro de datos (804) está configurado para enviar de manera asíncrona bloques de datos seleccionados a uno seleccionado de la pluralidad de segundos dispositivos informáticos DataNode del segundo centro de datos (806) a través de la red de área extensa (808).

7. La agrupación de cualquier reivindicación anterior, en donde al menos alguno de la pluralidad de primeros dispositivos informáticos NameNode están configurados para generar un informe de bloque que incluye una lista de todos los bloques de datos almacenados en la pluralidad de primeros dispositivos informáticos DataNode para su consumo por la pluralidad de segundos dispositivos informáticos NameNode en donde al menos alguno de la pluralidad de segundos dispositivos informáticos NameNode están configurados para generar un informe de bloque que incluye una lista de todos los bloques de datos almacenados en la pluralidad de segundos dispositivos informáticos DataNode para su consumo por la pluralidad de primeros dispositivos informáticos NameNode.

8. La agrupación de cualquier reivindicación anterior, en donde el motor de coordinación está configurado para ejecutarse en cada uno de la pluralidad de primeros y segundos dispositivos informáticos NameNode.

9. Un método implementado por ordenador, que comprende:

proporcionar una agrupación de nodos que comprende dispositivos informáticos configurados para implementar un sistema de ficheros geográficamente distribuido único (802), comprendiendo la agrupación de nodos un primer centro de datos (804), que comprende:

una pluralidad de primeros almacenamientos persistentes locales;

una pluralidad de segundos almacenamientos persistentes locales;

en donde el espacio de nombres de la agrupación comprende información de sistema de ficheros y metadatos de todos los bloques de datos almacenados por la pluralidad de primeros y segundos dispositivos informáticos DataNode, y en donde la pluralidad de primeros y segundos dispositivos informáticos NameNode están configurados para actualizar el estado del espacio de nombres de la agrupación en respuesta a que se escriban bloques de datos en la pluralidad de primeros y segundos dispositivos informáticos DataNode;

coordinar, por un motor de coordinación distribuido, la actualización del estado del espacio de nombres, en donde la coordinación comprende

recibir propuestas desde la pluralidad de primeros y segundos dispositivos informáticos NameNode, en respuesta a solicitudes de cliente, en donde las propuestas son solicitudes para actualizar el estado del espacio de nombres y generar, en respuesta, una secuencia ordenada de acuerdos que corresponden a las propuestas recibidas, en donde la secuencia ordenada de acuerdos está ordenada por números de secuencia globales, en donde la secuencia globalmente ordenada de acuerdos especifica un orden con el que han de actualizar la pluralidad de primeros y segundos dispositivos informáticos NameNode su respectivo estado almacenado del espacio de nombres y proporcionar la secuencia ordenada de acuerdos idénticamente a cada dispositivo informático NameNode; y

retardar, por la pluralidad de primeros y segundos dispositivos informáticos NameNode, haciendo actualizaciones al estado del espacio de nombres hasta que dicha pluralidad de primeros y segundos dispositivos informáticos NameNode hayan recibido la secuencia ordenada de acuerdos desde el motor de coordinación distribuido; en donde actualizar el estado del espacio de nombres comprende actualizar información de sistema de ficheros y metadatos de bloques de datos almacenados por la pluralidad de primeros y segundos dispositivos informáticos DataNode.

10. El método implementado por ordenador de la reivindicación 10, en donde actualizar el estado del espacio de nombres almacenado en la pluralidad de primeros dispositivos informáticos NameNode se lleva a cabo con cada uno de la pluralidad de primeros dispositivos informáticos NameNode que está configurado para actualizar el estado del espacio de nombres mientras que uno o más otros de los primeros dispositivos informáticos NameNode en el primer centro de datos también están actualizando el estado del espacio de nombres.

11. El método implementado por ordenador de las reivindicaciones 10 u 11, en donde actualizar el estado del espacio de nombres almacenado en la pluralidad de primeros dispositivos informáticos NameNode se lleva a cabo mientras se actualiza el estado del espacio de nombres almacenado en la pluralidad de segundos dispositivos informáticos NameNode.

12. El método implementado por ordenador de cualquiera de las reivindicaciones 10 a 12, que comprende adicionalmente mantener el estado del espacio de nombres coherente tras un fallo de uno o más de la pluralidad de la primera y segunda pluralidades de dispositivos informáticos NameNode, un fallo de uno o más de la pluralidad de la primera y segunda pluralidades de dispositivos informáticos DataNode o tras un fallo del primer o el segundo centro de datos.

13. El método implementado por ordenador de cualquiera de las reivindicaciones 10 a 13, en donde el sistema de ficheros distribuido comprende una versión del sistema de ficheros distribuido Hadoop (HDFS).

14. El método implementado por ordenador de cualquiera de las reivindicaciones 10 a 14, que comprende adicionalmente enviar, por cada uno de la pluralidad de primeros dispositivos informáticos DataNode del primer centro de datos, bloques de datos seleccionados a uno seleccionado de la pluralidad de segundos dispositivos informáticos DataNode del segundo centro de datos a través de la red de área extensa.

15. El método implementado por ordenador de cualquiera de las reivindicaciones 10 a 15, que comprende adicionalmente:

generar, por al menos alguno de la pluralidad de primeros dispositivos informáticos NameNode, un informe de bloque que incluye una lista de todos los bloques de datos almacenados en la pluralidad de primeros dispositivos informáticos DataNode, para su consumo por la pluralidad de segundos dispositivos informáticos NameNode; y generar, por al menos alguno de la pluralidad de segundos dispositivos informáticos NameNode, un informe de bloque que incluye una lista de todos los bloques de datos almacenados en la pluralidad de segundos dispositivos informáticos DataNode, para su consumo por la pluralidad de primeros dispositivos informáticos NameNode.

16. El método implementado por ordenador de cualquiera de las reivindicaciones 10 a 16, en donde la coordinación se realiza en cada uno de la pluralidad de primeros y segundos dispositivos informáticos NameNode.