ES2969620T3 - Métodos, dispositivos y sistemas para mantener la consistencia de metadatos y datos en todos los centros de datos - Google Patents
Métodos, dispositivos y sistemas para mantener la consistencia de metadatos y datos en todos los centros de datos Download PDFInfo
- Publication number
- ES2969620T3 ES2969620T3 ES18767539T ES18767539T ES2969620T3 ES 2969620 T3 ES2969620 T3 ES 2969620T3 ES 18767539 T ES18767539 T ES 18767539T ES 18767539 T ES18767539 T ES 18767539T ES 2969620 T3 ES2969620 T3 ES 2969620T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- cache
- file
- data center
- metadata
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 230000004044 response Effects 0.000 claims abstract description 12
- 230000010076 replication Effects 0.000 claims description 113
- 238000013507 mapping Methods 0.000 claims description 51
- 238000003860 storage Methods 0.000 claims description 44
- 230000008859 change Effects 0.000 claims description 17
- 230000015654 memory Effects 0.000 claims description 15
- 238000004891 communication Methods 0.000 claims description 3
- 230000014759 maintenance of location Effects 0.000 claims 1
- 230000001360 synchronised effect Effects 0.000 abstract description 8
- 230000008569 process Effects 0.000 description 17
- 238000010586 diagram Methods 0.000 description 12
- 239000008186 active pharmaceutical agent Substances 0.000 description 9
- 238000013075 data extraction Methods 0.000 description 8
- 238000000125 metastable de-excitation spectroscopy Methods 0.000 description 7
- 238000013500 data storage Methods 0.000 description 5
- 239000000284 extract Substances 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 230000008439 repair process Effects 0.000 description 5
- 238000013461 design Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 239000000370 acceptor Substances 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 230000003362 replicative effect Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 210000004556 brain Anatomy 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000011010 flushing procedure Methods 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000001575 pathological effect Effects 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 230000000284 resting effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/178—Techniques for file synchronisation in file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/148—File search processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/172—Caching, prefetching or hoarding of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
- G06F16/184—Distributed file systems implemented as replicated file system
- G06F16/1844—Management specifically adapted to replicated file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Library & Information Science (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Un método implementado por computadora puede comprender proporcionar un primer caché de acuerdo ejecutado en un primer centro de datos y un segundo caché de acuerdo ejecutado en un segundo centro de datos; recibir acuerdos sobre propuestas para crear o realizar cambios en archivos almacenados en el primer y segundo centro de datos; almacenar metadatos de los archivos a los que se refieren los acuerdos recibidos en las cachés del primer y/o segundo acuerdo ejecutado; mantener las cachés del primer y segundo acuerdo ejecutado sincrónicas entre sí antes de que se creen o cambien los archivos a los que hacen referencia los acuerdos recibidos; crear o realizar cambios en el archivo al que hacen referencia los acuerdos recibidos solo después de que se hayan sincronizado las cachés de los acuerdos ejecutados primero y segundo; y buscar metadatos actualizados en las cachés de acuerdos ejecutados primero y/o segundo cada vez que se reciben solicitudes de datos de archivos almacenados en el primer o segundo centro de datos en el primer o segundo centro de datos y, en respuesta a las solicitudes recibidas, proporcionar datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Métodos, dispositivos y sistemas para mantener la consistencia de metadatos y datos en todos los centros de datos
Antecedentes
El campo de las realizaciones desveladas en el presente documento incluye sistemas de archivos distribuidos. En particular, las realizaciones se refieren a métodos, dispositivos y sistemas para mantener la consistencia de las carpetas de archivos replicadas en un sistema de archivos distribuido a través de una red de área extensa (WAN) que puede incluir, por ejemplo, Internet.
Técnica anterior citada
Los antecedentes de la presente invención se pueden encontrar en el artículo de ALEXANDER THOMSON/GOOGLE AGT@GOOGLE COM DANIEL J ABADI YALE UNIVERSITY DNA@CS YALE EDU, titled "CalvinFS: Consistent WAN Replication and Scalable Metadata Management for Distributed File Systems", (20150216), páginas 8 - 21, USENIX, USENIX, THE ADVANCED COMPUTING SYSTEMS ASSOCIATION, URL: https://www.usenix.org/sites/default/files/fast15_full_proceedings_interior.pdf, (20150216), XP061024680 [X] 1-3,6 * secciones 2-7 * [I] 4,5,7-15
El documento US9020987 se refiere a un método para gestionar la actualización de metadatos de sistemas de archivos. Los cambios en los metadatos de un archivo de un sistema de archivos se almacenan en un registro diario tras recibir una solicitud de E/S para el archivo del sistema de archivos. La solicitud de E/S da como resultado la actualización de los metadatos del archivo del sistema de archivos. El diario incluye transacciones de metadatos en el sistema de archivos. Los cambios en los metadatos del archivo se almacenan en una memoria volátil de un sistema de almacenamiento de datos tras recibir solicitudes de E/S posteriores, lo que da como resultado la actualización de los metadatos del archivo del sistema de archivos. Los metadatos del archivo del sistema de archivos se actualizan con información derivada de los cambios de metadatos almacenados en el registro diario.
El documento WO2015153045 describe una agrupación de nodos que implementa un único sistema de archivos distribuido. El sistema comprende al menos un primer y un segundo centro de datos y un proceso de motor de coordinación. El primer centro de datos puede comprender primeros nodos de datos (DataNodes) configurados para almacenar bloques de datos de archivos de cliente y primeros nodos de nombre (NameNodes) configurados para actualizar un estado de un espacio de nombres de la agrupación. El segundo centro de datos, geográficamente remoto y acoplado al primer centro de datos mediante una red de área extensa, puede comprender segundos nodos de datos configurados para almacenar bloques de datos de archivos de clientes y segundos nodos de nombre configurados para actualizar el estado del espacio de nombres. El primer y segundo nodos de nombre están configurados para actualizar el estado del espacio de nombres en respuesta a los bloques de datos que se escriben en los nodos de datos. El proceso de motor de coordinación abarca el primer y segundo nodos de nombre y coordina las actualizaciones del espacio de nombres almacenado de manera que su estado se mantenga consistente a través del primer y segundo centro de datos.
El documento US 2015/067002 es otro sistema de archivos distribuido que tiene una agrupación de nodos. El sistema incluye al menos dos nodos de nombres, cada uno de los cuales está acoplado a una pluralidad de nodos de datos y cada uno está configurado para almacenar un estado de un espacio de nombres de la agrupación y cada uno está configurado para responder a una solicitud de un cliente mientras que otro u otros de los nodos de nombres están respondiendo a otras solicitudes de otros clientes. Un motor de coordinación está acoplado a cada uno de los nodos de nombre. El motor de coordinación está configurado para recibir propuestas de los nodos de nombres para cambiar el estado del espacio de nombres replicando, eliminando y/o añadiendo bloques de datos almacenados en los nodos de datos y para generar, en respuesta, un conjunto ordenado de acuerdos que especifica un orden en el que han de cambiar los nodos de nombre el estado del espacio de nombres. Los nodos de nombre están configurados para retardar la realización de cambios a los mismos hasta que se reciba el conjunto ordenado de acuerdos del motor de coordinación.
Sumario de la invención
En un primer aspecto de la invención se proporciona, de acuerdo con la reivindicación 1, un método implementado por ordenador para mantener la consistencia de una carpeta replicada en un sistema de archivos distribuido que abarca, a través de una red informática (302), al menos un primer centro de datos (214) y un segundo centro de datos (216).
En otro aspecto de la invención, se proporciona un sistema implementado por ordenador de acuerdo con la reivindicación 12.
Breve descripción de los dibujos
La Figura 1 es un diagrama de una implementación de sistema de archivos distribuido adecuado para la implementación de métodos, dispositivos y sistemas de acuerdo con las realizaciones.
La Figura 2 es un diagrama de un centro de datos local y remoto acoplado a una red informática.
La Figura 3 es un diagrama que muestra centros de datos acoplados a una red informática y aspectos de sistemas y métodos implementados por ordenador, de acuerdo con las realizaciones.
La Figura 4 es un diagrama que muestra centros de datos acoplados a una red informática y aspectos de sistemas y métodos implementados por ordenador, de acuerdo con las realizaciones.
La Figura 5 es un diagrama que muestra centros de datos acoplados a una red informática y aspectos de sistemas y métodos implementados por ordenador, de acuerdo con las realizaciones.
La Figura 6 es un diagrama de flujo de un método implementado por ordenador de acuerdo con una realización.
La Figura 7 es un diagrama de flujo de un método implementado por ordenador de acuerdo con una realización.
La Figura 8 es un diagrama de flujo de un método implementado por ordenador de acuerdo con una realización.
La Figura 9 es un diagrama de bloques de un dispositivo informático de hardware con el que se pueden poner en práctica aspectos de una realización.
Descripción detallada
El espacio de nombres del sistema de archivos compatible con Hadoop (HCFS) es una jerarquía de archivos y directorios. Hadoop es una estructura de programación basada en Java de código abierto que soporta el procesamiento y almacenamiento de conjuntos de datos extremadamente grandes en un entorno informático distribuido. Es parte del proyecto Apache patrocinado por la Apache Software Foundation. Los archivos y directorios se representan en el nodo de nombre por inodos. Los inodos registran atributos tales como permisos, tiempos de modificación y acceso, espacio de nombres y cuotas de espacio de disco. El contenido del archivo se divide en bloques de datos grandes (típicamente de 128 MB), y cada bloque de datos del archivo se replica independientemente en múltiples nodos de datos (típicamente tres). Una implementación de HCFS es el sistema de archivos distribuido Hadoop (HDFS). El nodo de nombre es el servicio de metadatos de HDFS, que es responsable de las operaciones del espacio de nombres. El nodo de nombre mantiene el árbol de espacio de nombres y el mapeo de bloques a los nodos de datos. Es decir, el nodo de nombre 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 nodo de nombre. La agrupación puede tener miles de nodos de datos y decenas de miles de clientes de HDFS por agrupación, ya que cada nodo de datos 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. El nodo de nombre mantiene toda la imagen del espacio de nombres en la memoria de acceso aleatorio (RAM).
Para mantener la consistencia del sistema entre los nodos de un sistema de archivos distribuido, puede resultar necesario coordinar diversos eventos distribuidos entre los nodos. La manera más sencilla para coordinar un evento particular que debe aprenderse de manera consistente 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, las implementaciones de HDFS convencionales usan un nodo de nombre activo que se accede durante operaciones normales y un respaldo denominado el nodo de nombre en reposo que se usa como una migración tras error en caso de fallo del nodo de nombre activo.
Sin embargo, se cree que esto es una solución subóptima. Por ejemplo, en este esquema, el registro o registros diarios de transacciones mismos se vuelven el único punto de fallo. De hecho, tras la corrupción del registro o registros diarios de transacciones, el nodo de nombre en espera ya no puede asumir el mismo estado que el nodo de nombre activo y ya no es posible la migración tras error del nodo de nombre activo al de en espera.
Además, en las soluciones de Hadoop que soportan únicamente un nodo de nombre activo por agrupación, los servidores en espera, como se ha indicado anteriormente, se mantienen típicamente en sincronización mediante dispositivos de Almacenamiento Conectado a la Red (NAS). Si el nodo de nombre activo falla y el de en espera debe hacerse cargo, existe una posibilidad de pérdida de datos si aún no se ha escrito un cambio escrito en el nodo de nombre 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á apagado y se hace cargo de la función activa, a continuación, puede ocurrir una condición de red patológica conocida como "cerebro dividido", en la que dos nodos creen que son el nodo de nombre activo, condición que puede conducir a corrupción de datos.
Las funciones de los proponentes (procesos que hacen propuestas para cambiar el estado del espacio de nombres a los miembros), los aceptadores (procesos que votan sobre si debería acordarse una propuesta para cambiar el estado del espacio de nombres 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 para llevar a cabo cada una de las funciones. Un motor de coordinación puede permitir que múltiples aprendices acuerden el orden de los eventos enviados al motor por múltiples proponentes con la ayuda de múltiples aceptantes para lograr una alta disponibilidad. Para conseguir fiabilidad, disponibilidad y escalabilidad, pueden proporcionarse múltiples nodos de nombre simultáneamente activos (que pueden considerarse, genéricamente, servidores de metadatos) 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 consistente entre tales nodos.
Esta consistencia entre los nodos de nombre 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 nodos de nombre 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 Bernsteinet al.,"Concurrency Control & Recovery in Database Systems", publicado por Addison Wesley, 1987, capítulos 6, 7 y 8. Puesto que los nodos de nombre empiezan desde el mismo estado y aplican las mismas actualizaciones deterministas en el mismo orden determinista, sus respectivos estados están y permanecen consistentes.
Por lo tanto, de acuerdo con una realización, el espacio de nombres se puede replicar en múltiples nodos de nombre (o, más generalmente, servidores de metadatos) siempre 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 consistentes entre sí, a través de los nodos.
La Figura 1 es un diagrama de un sistema de archivos distribuido de acuerdo con una realización que halla utilidad particular en el entorno de WAN. La Figura 1 también ilustra aspectos de los métodos de replicación, aplicables a través de una WAN, para un HCFS distribuido (tal como, por ejemplo, HDFS) basándose en un modelo de máquina de estado replicada. De acuerdo con una realización, los nodos de nombre están ubicados en diferentes centros de datos distribuidos geográficamente. Tales centros de datos pueden ubicarse, por ejemplo, en diferentes continentes. Se describen en el presente documento realizaciones que son aplicables a un sistema de archivos distribuido que abarca, por ejemplo, una agrupación de HCFS a través de una w An que incluye, por ejemplo, Internet y/o una WAN privada o propietaria.
Vista general de la arquitectura
La Figura 1 es un diagrama de bloques de los componentes de una agrupación y un sistema de archivos distribuido que abarca una WAN, de acuerdo con una realización. Como se muestra en la misma, la agrupación (por ejemplo, única) que ejecuta un sistema de archivos distribuido 102, de acuerdo con una realización, puede comprender dos o más centros de datos; en concreto, el centro de datos A (DCA) 104 y el centro de datos B (DCB) 106. El DCA 104 y el DCB 106 pueden estar geográficamente alejados entre sí. Por ejemplo, el DCA 104 y el DCB 106 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 104 y el DCB 106 pueden estar acoplados libremente entre sí mediante una WAN 108 que puede incluir, por ejemplo, Internet y/u otras redes privadas y/o propietarias. El DCA 104 y el DCB 106 pueden también estar acoplados entre sí mediante conexiones de alta velocidad especializadas. Aunque se muestran únicamente dos centros de datos 104, 106 en la Figura 1, se ha de entender que las realizaciones pueden incluir un mayor número de centros de datos y que el sistema de archivos distribuido 102 se extiende a través de todos tales centros de datos.
Como se muestra, el DCA 104 puede comprender una pluralidad de servidores de metadatos activos (a diferencia de, por ejemplo, en espera o de migración tras error) (de los cuales un nodo de nombre Hadoop es sólo una posible implementación) denominados figuras como "MDS". De esta manera, el DCA 104 puede comprender MDS indicados por los números de referencia 110, 112 y 114, y el DCB 106 puede comprender MDS indicados por los números de referencia 116, 118 y 120. Cada uno de los MDS 110, 112, 114, 116, 118 y 120 puede estar configurado para almacenar el estado del espacio de nombres del sistema de archivos distribuido y para mantener ese espacio de nombres único de una manera consistente a través de los MDS y los centros de datos. Los aspectos de la coordinación entre los MDS y el mantenimiento del único espacio de nombres a través de los MDS puede proporcionarse por el proceso de motor de coordinación (CE) distribuido 122. En la Figura 1, el proceso de CE 122 se muestra de una manera que sugiere que es una entidad lógica separada que abarca el DCA 104, el DCB 106 y la WAN 108. Sin embargo, de acuerdo con una realización, la funcionalidad del CE 122, descrito anteriormente y a continuación, puede descargarse por cada uno de los MDS 110, 112, 114, 116, 118 y 120. Es decir, cada uno de los MDS 110, 112, 114, 116, 118 y 120 puede configurarse, entre sus otras funciones, para llevar a cabo algunas o todas las labores del CE 122.
El DCA 102 puede comprender una pluralidad de nodos de datos 124, 126, 128, 130, denominados como "DN" en la Figura 1. De manera similar, el DCB 104 puede comprender también una pluralidad de nodos de datos 132, 134, 136, 138, también denominados como "DN" en la Figura 1. Como se muestra, cada uno de los nodos de datos 124, 126, 128, 130 está acoplado y configurado para comunicarse con cada uno de los MDS 110, 112 y 114 de DCA 102. Como también se muestra, cada uno de los nodos de datos 132, 134, 136, 138 puede estar acoplado y configurado para comunicarse con cada uno de los MDS 116, 118 y 120 de DCB 106. De acuerdo con una realización, los MDS no pueden comunicarse directamente con los nodos de datos. De hecho, de acuerdo con una realización, los nodos de datos pueden configurarse para enviar solicitudes a los MDS, después de lo cual los MDS emiten comandos a los nodos de datos en respuesta a las solicitudes recibidas. Por lo tanto, aunque se puede decir que los MDS controlan los nodos de datos, los nodos de datos pueden configurarse, de acuerdo con una realización, para enviar solicitudes a los MDS para recibir un comando de los mismos. Se muestran cuatro nodos de datos 124, 126, 128, 130 en el DCA 104. De manera similar, se muestran cuatro nodos de datos 132, 134, 136 y 138 en el DCB 106. Sin embargo, ha de entenderse que los centros de datos 104 y 106 puede cada uno comprender muchos más (por ejemplo, miles) de nodos de datos de los que se muestran en la Figura 1.
Aunque se muestran tres MDS 110, 112, 114 como que se proporcionan dentro del DCA 102, puede proporcionarse un número mayor de los MDS dentro del DCA 102. De manera similar, aunque se muestran tres MDS 116, 118, 120 como que se proporcionan dentro del DCB 106, puede proporcionarse un número mayor de los MDS dentro del DCB 106. De acuerdo con una realización, el número de MDS dentro de un centro de datos puede seleccionarse para que sea un número impar.
De acuerdo con una realización, la Figura 1 muestra una agrupación que ejecuta un único sistema de archivos distribuido que abarca diferentes centros de datos separados geográficamente. El sistema de archivos distribuido puede incorporar, por ejemplo, aspectos de HDFS. Cada uno de los nodos de datos puede configurarse para comunicarse (a través del protocolo de llamada de procedimiento remoto (RPC) de nodo de datos a nodo de nombre) únicamente con MDS dentro de su propio centro de datos. A la inversa, los MDS de un centro de datos pueden configurarse para controlar únicamente los nodos de datos dentro de su propio centro de datos. Es decir, los nodos de datos del centro de datos 104 únicamente pueden comunicarse, de acuerdo con una realización, con los MDS de su propio centro de datos 104 y los nodos de datos del centro de datos 106 únicamente pueden comunicarse con los MDS de su propio centro de datos 106. Los MDS de ambos centros de datos 102, 104 se coordinan entre sí para mantener el estado del espacio de nombres consistente a través del motor de coordinación 122. Los nodos de datos de un centro de datos pueden comunicarse con los nodos de datos del otro centro o centros de datos.
De acuerdo con una realización, el proceso de CE 122 puede configurarse para garantizar que las mismas actualizaciones deterministas del estado del espacio de nombres se apliquen en el mismo orden determinista en todos los MDS. De acuerdo con una realización, ese orden determinista está definido por el Número de Secuencia Global (GSN). Por lo tanto, una función significativa del proceso de CE 122, de acuerdo con una realización, es procesar las propuestas para modificar o actualizar de otra manera el estado del espacio de nombres desde todos los MDS y transformarlos en una secuencia de acuerdos globalmente ordenada. Los MDS pueden a continuación aplicar secuencialmente los acuerdos desde esa secuencia ordenada como actualizaciones a su estado almacenado. De acuerdo con una realización, el GSN está configurado como un número único monótonamente creciente. Sin embargo, el GSN puede configurarse de otra manera, como pueden reconocer los expertos en la materia. El GSN a continuación puede usarse para comparar el progreso de diferentes MDS al actualizar el estado del espacio de nombres y mantener ese estado de espacio de nombres consistente a través de los MDS (o proporcionar el estado del espacio de nombres almacenado en cada uno de los MDS en consistencia a través del tiempo a través de la aplicación secuencial de la secuencia de acuerdos globalmente ordenada). Por ejemplo, si el MDS 110 acaba de procesar un acuerdo numerado GSN1, que es menor que el GSN2 recién procesado por el MDS 112, a continuación, el MDS 110 tiene un estado de espacio de nombres anterior al del MDS 112. El estado del espacio de nombres almacenado por el MDS 110 coincidirá con el almacenado por el MDS 112 tan pronto como el MDS 110 procese GSN2, con la condición de que el MDS 112 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 (a través del mecanismo de GSN) de acuerdos generado por el proceso de CE 122, el estado del espacio de nombres almacenado en cada uno de los MDS en cada uno de los centros de datos se lleva o se mantiene en consistencia.
De acuerdo con una realización, con cada operación, los clientes aprenden acerca del último GSN procesado en el MDS al que está conectado actualmente el cliente. Posteriormente, si el cliente conmuta a otro MDS, de acuerdo con una realización, debería esperar en primer lugar (si fuera necesario) hasta que el nuevo MDS capture el último GSN sobre el que el cliente conoce (es decir, el GSN que el cliente recibió desde el MDS 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 MDS 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.
Una realización coordina todos los metadatos entre los MDS 110, 112, 114, 116, 118, 120 instantáneamente (o casi, teniendo en cuenta el ancho de banda y las latencias inherentes a la red), a medida que el proceso de CE 122 entrega los acuerdos. Análogamente, todos los datos del sistema de archivos también se replican automáticamente en los múltiples centros de datos de la agrupación. Una realización proporciona replicación de datos continua y consistente entre sistemas de archivos en (por ejemplo, pero sin limitación, Hadoop) agrupaciones. Las aplicaciones de cliente se pueden configurar para interactuar con un sistema de archivos virtual que integra el almacenamiento subyacente a través de múltiples agrupaciones. Cuando se realizan cambios en los archivos de una agrupación, esos cambios se replican de forma coherente en las otras agrupaciones distribuidas. Una realización puede comprender una aplicación de software que permite que los despliegues de Hadoop repliquen datos de HCFS entre agrupaciones (por ejemplo, Hadoop) que ejecutan versiones diferentes, incluso incompatibles, de Hadoop tales como, por ejemplo, CDH, HDP, EMC Isilon, Amazon S3/EMRFS y MapR. También es posible, de acuerdo con una implementación, replicar entre diferentes distribuciones de proveedores y versiones de Hadoop.
Ventajosamente, las realizaciones proporcionan un sistema de archivos virtual para Hadoop, compatible con todas las aplicaciones de Hadoop, un único espacio de nombres virtual que integra almacenamiento de diferentes tipos de Hadoop, un mecanismo de almacenamiento globalmente distribuido y replicación de WAN usando tecnología de replicación activo-activo, entregando unos datos de HDFS consistentes de una única copia, replicados entre centros de datos remotos.
De acuerdo con una realización, parte o toda la funcionalidad descrita en el presente documento se puede llevar a cabo dentro de un servidor o servidores adyacentes a la agrupación de Hadoop lejos de, por ejemplo, los MDS activos y el motor de coordinación, en un nivel superior en la pila de Hadoop. De esta manera, en lugar de trabajar profundamente en el nivel del nodo de nombre, se puede configurar una realización para operar como una aplicación proxy para el sistema de archivos de Hadoop.
Se pueden configurar realizaciones para aumentar la potencia de procesamiento en la nube transfiriendo datos a servicios remotos en la nube tales como, por ejemplo, Amazon Web Services (AWS), una plataforma que ofrece potencia de procesamiento bajo demanda, almacenamiento de bases de datos, entrega de contenido y otra funcionalidad, para obtener potencia de procesamiento adicional cuando se requiera.
Además, las realizaciones permiten la sincronización a través de diferentes distribuciones de Hadoop, tal como la capacidad de replicar, por ejemplo, entre dos agrupaciones de Hortonworks, entre Hortonworks y Cloudera y los sistemas de almacenamiento Isilon de EMC, por nombrar solo algunas de las posibilidades. También se puede dar cabida a la sincronización con servidores HBase. Hbase es una base de datos distribuida, no relacional y de código abierto, modelada a partir de BigTable de Google y escrita en Java. Hbase se desarrolló como parte del proyecto Apache Hadoop de Apache Software Foundation y se ejecuta en la parte superior de HDFS, proporcionando capacidades similares a BigTable para Hadoop.
Una realización replica operaciones de metadatos (por ejemplo, crear archivo) de forma síncrona usando un acuerdo de Paxos que se acuerda, a través de una red informática 202, por un quórum mayoritario de servidores de replicación de datos 204, 206, 208, como se muestra en la Figura 2. Como se muestra, la red informática 202 puede abarcar múltiples ubicaciones en todo el mundo conectadas mediante enlaces de WAN (red de área extensa). Las operaciones de datos (por ejemplo, escribir datos de archivos) que pueden estar asociadas con la operación de metadatos se replican de forma asíncrona sin coordinación, a menudo después de las operaciones de metadatos. Es decir, las escrituras en los almacenamientos de sistemas de archivos distribuidos 210, 212 y 218 asociados con una operación de creación de metadatos de archivos se pueden llevar a cabo de forma asíncrona, sin coordinación entre la pluralidad de servidores de replicación de datos 204, 206, 208. Esto es para garantizar que el rendimiento del almacenamiento en el centro de datos de origen (DCO) 214 no se vea afectado negativamente mientras el centro de datos remoto (RDC) replica los datos escritos en el almacenamiento del sistema de archivos distribuido 210 en el DCO 214 al almacenamiento de archivos distribuido 212 en el RDC 216. Sin embargo, estas operaciones de escritura de datos no coordinadas abren una ventana durante la que operaciones de metadatos posteriores en el mismo objeto de archivo pueden provocar que tales operaciones de copia de datos no coordinadas fallen. Por ejemplo, el nombre del archivo o la ruta podrían cambiarse mientras se realizaba una de las operaciones de escritura de datos no coordinadas, lo que provocaría un fallo en la operación de escritura de datos.
Un ejemplo ilustrativo de tal problema es el caso en el que un cliente de un DCO 214 crea un archivo, es decir, "foo.tmp", escribe 200 MB de datos en el archivo, lo cierra y, posteriormente, cambia el nombre del archivo "foo.tmp". a "foo". El servidor o servidores de replicación de datos en los RDC 216 observarán los metadatos para la operación de creación de archivos para "foo.tmp", pero mientras copian los 200 MB de datos, el servidor de replicación de datos en el DCO puede ejecutar el acuerdo "cambiar el nombre de foo.tmp a foo", lo que provoca por lo tanto que falle la replicación de los datos "foo.tmp" al RDC, ya que está extrayendo los 200 MB de datos de un archivo "foo.tmp" que ya no existe desde donde lo está extrayendo.
Una implementación reinicia la extracción de datos desde el DCO 214 al RDC 216 cuando se cambia el nombre de un archivo mientras los datos del archivo se extraen de forma asíncrona. De hecho, la extracción de datos, que se inició al cerrar el archivo, falla debido a la operación de cambio de nombre del archivo intermedio. Para superar esto, la operación de cambio de nombre comprueba si el archivo es inconsistente y, si es inconsistente, reinicia la extracción con el destino del cambio de nombre como el origen de DCO de los datos para la extracción.
Otra realización, más ventajosa, rastrea los cambios de metadatos en los centros de datos para evitar fallos en la replicación de datos después de una operación tal como un cambio de nombre de archivo o un cambio en la ruta al archivo cuyos datos se van a replicar. La presente divulgación describe realizaciones de un sistema de replicación de datos asíncronos y metadatos síncronos de este tipo.
Principios de diseño
En relación con su despliegue en una plataforma de replicación de grandes cantidades de datos, se puede configurar una realización para incorporar los siguientes tres principios de diseño:
1. No han de almacenarse ni se almacenarán datos en caché en ninguno de los componentes informáticos descritos a continuación, incluyendo, pero sin limitación, los clientes, los servidores de replicación de datos o los servidores puente de versión. De hecho, se puede implementar una realización almacenando en caché las operaciones de metadatos de las propuestas acordadas, y no los datos asociados con tales operaciones.
2. Los clientes del centro de datos remoto (los clientes del centro de datos del RDC 216 donde han de replicarse los datos, a diferencia de los clientes del centro de datos del DCO 214 donde se escribieron los datos originalmente) observarán una vista de los metadatos que es consistente en el punto de tiempo del almacenamiento subyacente, usando el mecanismo del GSN. Es decir, el espacio de nombres entre las agrupaciones y el estado de una carpeta replicada serán idénticos en el mismo GSN, a través de los centros de datos. Sin embargo, los datos pueden estar incompletos. En otras palabras, los clientes remotos pueden observar la existencia de un archivo (ya que los metadatos del mismo se habrán almacenado en caché de forma síncrona), pero puede que los datos subyacentes del mismo aún no se hayan escrito por completo. Este comportamiento imita el comportamiento de escritores lentos con lectores ansiosos en una única instancia de centro de datos del sistema de almacenamiento de grandes cantidades de datos.
3. Los clientes de RDC nunca observarán datos que no pertenezcan al punto de tiempo de ese sistema de archivos, ni observarán una mezcla de datos de diferentes puntos en el tiempo del archivo, como se desarrolla más adelante.
Verificación de la corrección de las realizaciones divulgadas
La forma más sencilla de demostrar que la corrección es abortar cualquier extracción de datos (es decir, extraer datos del DCO al RDC) si se realiza un cambio en la misma ruta en una operación de metadatos posterior. El archivo se marca como inconsistente y se realiza la reparación para corregir la inconsistencia. Esta comprobación se puede realizar con un conocimiento mínimo del servicio de replicación, es decir, conocimiento de la semántica del sistema de archivos del almacén subyacente. También se puede implementar con un almacenamiento en caché mínimo de los acuerdos ejecutados.
Diseño
Una implementación ingenua que satisficiera sólo los criterios de corrección enumerados de manera inmediata anteriormente daría como resultado muchas operaciones de aborto y reparación, lo que haría que la carpeta replicada fuera inconsistente y degradaría la eficiencia del sistema distribuido. Por lo tanto, las realizaciones descritas en el presente documento proporcionan optimizaciones que se basan en la semántica del sistema de archivos del sistema de almacenamiento subyacente.
De acuerdo con una realización, el fallo de una operación de extracción de datos en el DCO 214 o el RDC 216 puede dar como resultado que la operación se reinicie usando un servicio de mapeo de nombre. De hecho, una operación de extracción de datos desde el DCO 214 al RDC 216 requiere tanto una operación de lectura en el DCO 214 como una operación de escritura en el RDC 216. Si cualquiera de los dos falla, las operaciones se reintentan usando una interfaz de programa de aplicación (API) del servicio de mapeo de nombre, también denominada en el presente documento MapFilename. Estas optimizaciones y el despliegue del servicio de mapeo de nombre, de acuerdo con una realización, requieren que se almacene información más detallada acerca de las operaciones del sistema de archivos realizadas en cada acuerdo.
De acuerdo con una realización, las mejoras pueden comprender tres aspectos:
1. Mejoras al servidor de replicación de datos 206, 208 (Figura 2), 308, 310 (Figura 3) para almacenar en caché los acuerdos ejecutados en una caché de acuerdos ejecutados 309, 311, y para implementar la API MapFilename usando esta caché de acuerdos ejecutados 309, 311;
2. El despliegue de un servidor de puente de versión 312 para llamar al servicio de mapeo de nombre MapFilename en el nombre de archivo de origen en el DCO 214; y
3. Mejora del servidor de replicación de datos 310 para llamar al servicio de mapeo de nombre en el nombre de archivo de destino en el RDC 216 y el despliegue correspondiente de un servidor de puente de versión 314 para llamar al servicio de mapeo de nombre en el nombre de archivo de origen en el RDC 216.
La Figura 3 es un diagrama de bloques que ilustra aspectos de métodos y sistemas implementados por ordenador, de acuerdo con una realización. Como se muestra, el número de referencia 214 indica el DCO y el número 216 indica el RDC, aunque las nomenclaturas podrían intercambiarse. El DCO 214 y el RDC 216 pueden estar acoplados libremente a través de una o más redes informáticas 302 y pueden estar separados geográficamente, según se sugiere por los globos 301. En el DCO 214, una aplicación de cliente 304 puede utilizar una biblioteca de cliente para emitir comandos de acceso a datos a un servidor de replicación de datos 308. De manera similar, en el RDC 216, una aplicación de cliente 306 puede utilizar una biblioteca de cliente para emitir comandos de acceso a datos a un servidor de replicación de datos 310. El servidor de replicación de datos 308, de acuerdo con una realización, almacena en caché los metadatos de los acuerdos para cambiar el estado de la carpeta replicada y los GNS asociados de los acuerdos en una caché 309 (mostrada en la Figura 3 como la caché de acuerdos ejecutados 309) y el servidor de replicación de datos 310 almacena en caché también los metadatos de los acuerdos y los GSN asociados en una caché 311. Las cachés 309, 311 se mantienen consistentes entre sí, como se describe a continuación. Una realización proporciona un servidor de puente de versión 312 en el DCO 214 y un servidor de puente de versión 314 en el RDC 216. Finalmente, cada uno del DCO 214 y el RDC 216 incluye almacenamiento, como se muestra en 316, 318, cuyos almacenamientos están configurados para almacenar persistentemente los datos correspondientes a los metadatos almacenados en caché en las cachés de acuerdos ejecutados 309, 311.
Crear GSN
Un archivo a replicar, de acuerdo con una realización, puede identificarse por un crear GSN único. El crear GSN es el GSN único que se asigna y asocia simultáneamente con el acuerdo para la creación del archivo. Casualmente, esto garantiza que las realizaciones sean perfectamente interoperables con sistemas de almacenamiento tales como S3, que no tienen la característica HFlush.
Los cachés de acuerdos ejecutados
El servidor de replicación de datos 308 puede configurarse, de acuerdo con una realización, para almacenar en caché los acuerdos ejecutados en una caché de acuerdos ejecutados 309 y el servidor de replicación de datos 310 puede configurarse, de acuerdo con una realización, para almacenar en caché los acuerdos ejecutados en una caché de acuerdos ejecutados 311. De acuerdo con una realización, los servidores de replicación de datos 308, 310 pueden configurarse para implementar la API MapFilename de servicio de mapeo de nombre en entradas en la caché de acuerdos ejecutados 309, 311, respectivamente. Dado que los acuerdos pueden ejecutarse fuera de orden, los servidores de replicación de datos 308, 310 pueden configurarse con la capacidad de iterar y buscar a través de todos los GSN superiores a un GSN especificado.
Con referencia continuada a la Figura 3, la aplicación de cliente 304 puede emitir una propuesta de crear archivo, a la que el motor de coordinación puede emitir un acuerdo correspondiente. A continuación, la aplicación de cliente 304 puede emitir una operación de crear archivo al servidor de replicación de datos 308, como se muestra en (1). Proporcionar una solución comprensiva que funcione no únicamente cuando no hay cambios en el nombre de archivo, la ruta o los datos desde la creación, escritura, inicio de la operación de extracción hasta el final de la escritura de datos en el centro de datos remoto, sino también cuando se produce un cambio intermedio intervención, se puede realizar el siguiente método. Significativamente y de acuerdo con una realización, los metadatos asociados con la operación de creación de archivos pueden almacenarse en caché en la caché de acuerdos ejecutados 308 en el DCO 214 y sincronizarse inmediatamente (por ejemplo, rápidamente) a través de la red 302 con el servidor de replicación de datos 310 en el RDC 216, para actualizar la caché de acuerdos ejecutados 311 del servidor de replicación de datos, como se muestra en (2). Esto hace que la operación de creación de archivos sea visible para el RDC 216, manteniendo una vista única de la carpeta replicada a través de todos los centros de datos 214, 216. De acuerdo con una realización, puede haber una caché de acuerdos ejecutados para cada carpeta replicada. Son posibles otras implementaciones y una única caché física puede subdividirse lógicamente para dar cabida a los metadatos de varias carpetas replicadas. Como los metadatos consisten en una cantidad relativamente pequeña de datos, enviarlos a través del cable desde la caché de acuerdos ejecutados 309 en el DCO 214 a la caché de acuerdos ejecutados 311 en el RDC 216 es una operación rápida, al menos en comparación con el tiempo requerido para replicar los datos de archivo correspondientes desde el almacenamiento 316 en el DCO214 al almacenamiento 318 en el RDC 216. El objetivo es coordinar rápidamente las operaciones de escritura de archivos usando GSN generados a través de las cachés de acuerdos ejecutados 309, 311 (y otras, si están presentes) y posteriormente permitir que los datos subyacentes se repliquen de forma asíncrona (y a menudo comparativamente más lenta), sin coordinación. De esta manera, el escritor de los datos (en el ejemplo que se desarrolla en el presente documento, la aplicación de cliente 304) no incurre en ninguna penalización significativa (en términos de latencia o de limitaciones de ancho de banda de la red, por ejemplo), ya que crea un archivo y escribe en el almacenamiento local subyacente 316.
Como se muestra en (3), después de la replicación coordinada de los metadatos de la operación de creación de archivo, el servidor de replicación de datos 308 puede crear el archivo en el almacenamiento 316 en nombre de la aplicación de cliente, en una ruta completamente cualificada y nombre de archivo especificados. A continuación, esa información puede pasarse de vuelta a la aplicación de cliente 304, que, a continuación, puede escribir datos en ese nombre de archivo (puede ser a velocidades de red de área local (LAN) relativamente más altas) como se muestra en (4). La aplicación de cliente 304 puede a continuación, cuando termine de escribir los datos, cerrar el archivo como se muestra en (5).
Debido a que el servidor de replicación de datos 310 en el RDC 216 ahora "conoce" el archivo creado (porque ahora almacena los metadatos del mismo en su caché de acuerdos ejecutados 311), consulta la versión del servidor de puente 312 del DCO 214. El servidor de replicación de datos 310 puede proporcionar al servidor de puente de versión 312 el crear GSN asociado con el archivo creado, cuyo crear GSN forma parte de los metadatos obtenidos del servidor de replicación de datos 308 del DCO en (2). A continuación, el servidor de puente de versión 312 puede hacer que el servidor de replicación de datos 308 del DCO 214 ejecute el servicio de mapeo de nombre en las entradas en la caché de acuerdos ejecutados 309, que, a continuación, puede pasar a través de GSN posteriores (posteriores al crear GSN) en la caché de acuerdos ejecutados 309, para determinar si se ha producido algún cambio en el nombre de archivo, ruta y/o datos del archivo desde (es decir, en GSN superiores a) el crear GSN proporcionado por el servidor de replicación de datos del RDC 310. Obsérvese que, esos cambios en el nombre de archivo, la ruta y/o los datos del archivo se habrían propuesto, acordado y los metadatos de los mismos se habrían almacenado en la caché de acuerdos ejecutados 309 en el DCO 214 y se habrían replicado, bajo coordinación, en la caché de acuerdos ejecutados 311 del servidor de replicación de datos 310 en el interím.
A continuación, el servidor de puente de versión 312 del DCO 214 puede proporcionar cualquier nombre de archivo, ruta y datos actualizados al servidor de replicación de datos 310 en el RDC 216. A continuación, el servidor de replicación de datos 310 puede escribir los datos así obtenidos en la ruta de nombre de archivo apropiada en el almacenamiento 318. Por supuesto, una aplicación de cliente en el RDC 216 puede haber llevado a cabo alguna operación de alteración de estado en el archivo antes, durante o después de la replicación de datos. Cada una de estas eventualidades se cubren en el presente documento a continuación.
De acuerdo con una implementación, se puede almacenar en caché la siguiente información para cada acuerdo ejecutado por los servidores de replicación de datos 308, 310:
1. Acuerdo ejecutado cacheEntry.Operation. Esta es una identificación de la operación del archivo, tal como cambiar el nombre, eliminar, truncar, anexar o reparar;
2. Acuerdo ejecutado cacheEntry.Path1, con las siguientes restricciones:
a. La ruta debe ser una ruta completamente cualificada (a diferencia de una ruta relativa) de un directorio o archivo; y
b. No se permiten comodines (*, $, etc.);
c. En caso de una operación de cambio de nombre, este acuerdo ejecutado cacheEntry.Path1 es la ruta de origen;
3. Acuerdo ejecutado cacheEntry.Path2, con las siguientes restricciones:
a. Ruta de destino completamente cualificada de un directorio o archivo;
b. No se permiten comodines; y
c. Presente únicamente en el caso de cambio de nombre;
4. Acuerdo ejecutado cacheEntry.FileLength. Esta es la longitud del archivo. En este punto,
a. En el caso de una operación de truncado de archivo, esta es la longitud hasta la cual se truncó el archivo; b. Para anexos, esta es la longitud del archivo antes de que comience el anexo;
Almacenar en caché tal información de metadatos en la caché de acuerdos ejecutados y propagar esa información de metadatos a cachés de acuerdos ejecutados remotas de manera síncrona permite que los datos subyacentes se escriban relativamente más lento, manteniendo al mismo tiempo el estado de la carpeta replicada consistente, en cada GSN, a través de todos los centros de datos. Es decir, el estado de una carpeta replicada en el DCO 214 en el GSN 122 será el mismo que el estado de la carpeta replicada en el GSN 122 en el RDC 216, incluso si el servidor de replicación de datos 310 en el RDC 216 ha ejecutado desde entonces el acuerdo asociado con el GSN 127 en la carpeta de datos replicados y el servidor de replicación de datos 308 en el DCO 214 aún no ha alcanzado el GSN 127 en esa carpeta replicada.
Recolección de basura de la caché de acuerdos ejecutados
La recolección de basura de la caché de acuerdos ejecutados 309, 311 es un aspecto importante de las consideraciones operativas para este sistema. Esto elimina las cachés de acuerdos ejecutados de metadatos que probablemente ya no sean necesarios para ninguno de los nodos del sistema de archivos distribuido. Esto permite que el tamaño de las cachés de acuerdos ejecutados se mantenga en un tamaño razonable y, además, permite que las cachés de acuerdos ejecutados se mantengan y se reconstruyan de manera eficiente si se necesita tal acción. Por lo tanto, una realización puede configurarse para recolectar basura de la caché o cachés de acuerdos ejecutados. Una implementación de tal funcionalidad de recolección de basura puede incluir que cada servidor de replicación de datos rastree el GSN más bajo para el que cualquier solicitud de datos (por ejemplo, una solicitud de extracción de datos) está activa. A continuación, esta información puede distribuirse a todos los servidores de replicación de datos en el quórum, cuyo quórum puede incluir el grupo de servidores de replicación de datos que rastrean los GSN de una carpeta replicada particular o de carpetas replicadas seleccionadas. Posteriormente, las entradas en la caché de acuerdos ejecutados que estén por debajo del GSN más bajo de cualquier extracción activa en el quórum, a continuación, pueden recopilarse como basura, por lo que ya no son necesarias. De acuerdo con una realización, se puede imponer un límite configurable en el número de entradas en la caché de acuerdos ejecutados, tal como, por ejemplo, 10.000, estando asociada cada entrada con un GSN. Las cachés de acuerdos ejecutados 309, 311 pueden configurarse para almacenar un número mayor o menor de acuerdos. La API MapFilename del servicio de mapeo de nombre puede devolver un código de error, tal como ErrorExecutedAgreementCacheGarbageCollected, si el mapa solicita un GSN que ha sido recopilado como basura. En otra realización, los servidores de replicación de datos 308, 310 pueden configurarse para rastrear el GSN de extracción de datos activo más bajo, y pueden distribuir este GSN de extracción de datos activo más bajo a todos los servidores de replicación de datos a través de los centros de datos (de nuevo, en una base por carpeta replicada), permitiendo realizar la recogida de basura de forma continuada.
Como se indicó anteriormente, la caché de acuerdos ejecutados puede configurarse como una estructura de datos de carpeta replicada, de modo que cada uno de los servidores de replicación de datos 308, 310 pueda acceder y mantener una pluralidad de cachés, una para cada estructura de datos de carpeta replicada.
De acuerdo con una realización, los comandos operativos o de gestión asociados con una estructura de datos replicada, tales como cambios en expresiones regulares de replicación selectiva, deberían dar como resultado el vaciado de la caché de acuerdos ejecutados correspondiente, que, a continuación, puede reconstruirse desde cero. Tal reconstrucción puede ocurrir a medida que se aprueben e implementen propuestas para operaciones de cambio de espacio de nombres.
Servicio de mapeo de nombre
Como se indicó anteriormente, la llamada de API MapFilename del servicio de mapeo de nombre puede implementarse por los servidores de replicación de datos 308, 310. Los usos de esta API pueden incluir:
1. En el DCO 214, el servidor de puente de versión 312 puede configurarse para llamar a este método cuando recibe una solicitud para transferir un archivo. A continuación, el servicio de mapeo de nombre llamado mapeará el nombre del archivo tal como se conocía en crear GSN, que es el GSN asociado con la creación del archivo. Durante la lectura del archivo, si la lectura falla, el servidor de puente de versión 312 llamará nuevamente al servicio de mapeo de nombre para determinar si el nombre del archivo cambió mientras estaba leyendo los datos del archivo.
2. En el RDC 216, el servidor de replicación de datos llamará al servicio de mapeo de nombre para mapear el nombre del archivo antes de comenzar a escribir, y también cuando falla la escritura de los datos extraídos en el archivo local.
De acuerdo con una realización, dado que el servidor de puente de versión 312 está fuera de proceso en el primer uso enumerado anteriormente y está en proceso en el segundo uso anterior, el servidor de mapeo de nombre puede configurarse para que esté disponible tanto como API de solicitud como un método local dentro de la misma máquina virtual Java (JVM). Otras implementaciones son posibles.
Parámetros de entrada y salida del servicio de mapeo de nombre MapFilename
Los parámetros de entrada del servicio de mapeo de nombre pueden incluir, de acuerdo con una implementación:
1. Crear GSN
a. Este es el GSN en el que se creó el archivo u objeto;
2. Ruta de entrada
a. La ruta de entrada es la ruta completamente cualificada de un archivo para el que el centro de datos remoto solicita datos;
b. La ruta de entrada no puede ser un directorio;
Los parámetros de salida del servicio de mapeo de nombre pueden incluir, de acuerdo con una realización:
1. Valor de retorno
a. El valor de retorno puede ser 'FileExistsUnchanged', lo que significa que el archivo no ha cambiado desde su crear GSN;
b. El valor de retorno puede ser 'FileExistsChanged', lo que significa que el archivo ha cambiado desde que fue escrito (desde su crear GSN);
c. El valor de retorno puede ser "FileDeleted", lo que significa que el archivo ya no existe;
d. Un valor de retorno 'ErrorExecuted Agreement cacheGarbageCollected' indica que el archivo está asociado con un crear GSN que desde entonces ha sido recopilado como basura; y
e. Un valor de retorno de 'AbortPullRepairComingUp' indica que se debe abortar la extracción de datos para este archivo, ya que se ha planificado una operación de reparación.
2. Nueva ruta
Si el valor de retorno es 'FileExistsUnchanged', a continuación, el valor de retorno 'NewPath' es la ruta del archivo tal como existe actualmente en el sistema de archivos subyacente y no ha cambiado desde el crear GSN del archivo. Este parámetro de salida rastrea los cambios en la ruta de entrada desde el crear GSN hasta el GSN actual del almacenamiento subyacente. Tanto los cambios en el nombre del archivo como los cambios en cualquier componente de directorio principal se rastrean e informan de esta manera.
3. Longitud de los datos que son válidos para el archivo
a. Este parámetro de salida tiene en cuenta cualquier posible operación de truncamiento que pueda haber eliminado datos al final del archivo
Operación de servicio de mapeo de nombre
De acuerdo con una realización, cuando se llama al servicio de mapeo de nombre, se pueden llevar a cabo una o más de las funciones y operaciones que se detallan a continuación.
Tras ser llamado, el servicio de mapeo de nombre puede comprobar si el crear GSN asociado con el archivo en el que se llama a la API es menor que el GSN más bajo almacenado en la caché de acuerdos ejecutados. Si es así, devuelve 'ErrorExecuted Agreement cacheGarbageCollected', ya que el servidor de replicación de datos no podrá comprobar si hay cambios en la caché de acuerdos ejecutados.
Recorrer cada entrada de caché de acuerdos ejecutados identificada por un GSN que es mayor que el crear GSN asociado con el archivo contra el que se llamó al servicio de mapeo de nombre hasta que se alcance el GSN más grande (el más alto, en una realización) almacenado en la caché de acuerdos ejecutados. Para cada una de tales entradas, se puede realizar lo siguiente.
Si ExecutedAgreementCacheEntry.Pathl (la ruta del archivo en una entrada en la caché de acuerdos ejecutados) coincide exactamente con el parámetro de ruta de entrada, las etapas a realizar dependen de la operación de archivo subyacente. Si se cambia de nombre de la operación de archivo, a continuación, remplazar la ruta de entrada con la nueva ruta 'ExecutedAgreementCacheEntry.Path2' en la caché de acuerdos ejecutados y continuar iterando a través de las entradas restantes en la caché de acuerdos ejecutados. Si la operación es anexar o truncar, guardar ExecutedAgreementCacheEntry.FileLength para volver al llamante y continuar iterando a través de las entradas restantes en las entradas de caché de acuerdos ejecutados. Si la operación es eliminar, a continuación, devolver FileDeleted inmediatamente y si la operación es reparar, devolver AbortPullRepairComingUp inmediatamente.
Si ExecutedAgreementCacheEntry.Pathl no coincide con la ruta de entrada, extraer el directorio padre de la ruta de entrada. Por ejemplo, si la ruta de entrada es /user/jagane/hive-tables/weblogs/fileABC, a continuación, el directorio padre de la ruta de entrada es /user/jagane/hive-tables/weblogs. Si el acuerdo ejecutado cacheEntry.Pathl es más largo que el directorio padre de la ruta de entrada, a continuación, el servidor de replicación de datos debe continuar iterando a través de las entradas restantes (que tienen un GSN mayor que el crear GSN del archivo contra el cual se llamó el servicio de mapeo de nombre) en la caché de acuerdos ejecutados.
Lo siguiente se realiza cuando ExecutedAgreementCacheEntry. Se determina que la ruta 1 es más corta o igual que la ruta de entrada al directorio padre. Si el acuerdo ejecutado cacheEntry.Pathl es igual a alguna subcadena de prefijo del directorio padre de ruta de entrada, esto indica que se operó en uno de los componentes del directorio padre de la ruta de entrada. Obsérvese que ExecutedAgreementCacheEntry.Pathl debe ser un directorio y no puede ser un archivo en este punto. Si se cambia el nombre de la operación, a continuación, el prefijo en el directorio padre de la ruta de entrada se reemplaza por ExecutedAgreement CacheEntry.Path2 y se recompone la ruta de entrada. Siguiendo con el ejemplo desarrollado anteriormente, si ExecutedAgreementCacheEntry. La ruta 1 es /user/jagane/hive-tables y si ExecutedAgreement CacheEntry.Path2 es /user/jagane/archived-hive-tables, a continuación, remplazar la ruta de entrada con /user/jagane/archived-hive-tables/weblogs/fileABC. A continuación, continuar iterando por el resto de las entradas de caché de acuerdos ejecutados. Si la operación es eliminar, a continuación, se eliminó todo el subdirectorio y FileDeleted ha de devolverse inmediatamente. Si la operación es reparar, a continuación, devolver AbortPullRepairComingUp. Obsérvese que, anexar y truncar son operaciones no válidas en este punto ya que ExecutedAgreementCacheEntry.Path1 debe ser un directorio.
Si el acuerdo ejecutado cacheEntry.Path1 no es igual a ninguna subcadena de prefijo del directorio padre de la ruta de entrada (excepto el directorio raíz), a continuación, continuar iterando por el resto de las entradas de caché acuerdos ejecutados. Si, al final del bucle anterior, no se encontraron coincidencias para la ruta de entrada, devolver FileExistsUnchanged. Si, al final del bucle anterior, se han encontrado algunos cambios, ya sea en la ruta de entrada o en la longitud, a continuación, devolver FileExistsChanged con la nueva ruta y la nueva longitud como valores de retorno
Mejoras para llamar al servicio de mapeo de nombre en el nombre de archivo de origen en el DCO
El servidor de replicación de datos 308 puede configurarse, como se muestra y describe en el presente documento, para mantener una caché de acuerdos ejecutados 309 que está configurada para almacenar en caché los detalles de la operación del sistema de archivos realizada en GSN específicos. Esta caché de acuerdos ejecutados 309, de acuerdo con una realización, puede configurarse para proporcionar un servicio de mapeo de nombre para que el servidor de puente de versión 312 solicite una mapeo de nombre de archivo en un GSN específico en el pasado al estado actual del sistema de archivos subyacente (hasta el GSN más alto en la caché de acuerdos ejecutados).
Obsérvese que, el servidor de replicación de datos 308 puede ejecutar un acuerdo de cambio de nombre/eliminación antes, durante o después de que la solicitud de extracción del servidor de replicación de datos 310 en el DCO llegue al servidor de puente de versión 312 en el DCO 214. Cada una de estas eventualidades se analiza a continuación por separado.
Cambiar nombre/eliminar acuerdo ejecutado por el servidor de replicación de datos antes de la solicitud de extracción
La Figura 4 es un diagrama de bloques que ilustra el caso en el que se cambia el nombre/elimina el archivo de origen o la ruta padre antes de recibir la solicitud de extracción desde el RDC. Como se muestra, (1) indica una solicitud de extracción emitida por el servidor de replicación de datos 310 en el RDC 216 y dirigida al servidor de puente de versión 312 en el DCO. Por ejemplo, el servidor de replicación de datos 310, consciente de la posibilidad de que el nombre de archivo o el directorio padre del archivo cuyos datos ha solicitado pueda haber cambiado desde su escritura inicial, puede solicitar un cambio de nombre del archivo MapFilename /jagane/hive/ foo.tmp, en crear GSN 21. Como se muestra en (2), el servidor de puente de versión 312, después de haber recibido esta solicitud de extracción, llama al servicio de mapeo de nombre, que se ejecuta por el servidor de replicación de datos 308 contra los acuerdos ejecutados en la caché de acuerdos ejecutados 309, donde está el GSN más grande ahora 50 (en este ejemplo). En respuesta a lo mismo, el servicio de mapeo de nombre iterará a través de los GSN 21 a 50, buscando posibles cambios en /jagane/hive/foo.tmp en el tiempo intermedio entre GSN 21 y GSN 50. El servicio de mapeo de nombre, en este ejemplo, encuentra que /jagane/hive/foo.tmp de hecho ha cambiado a /Jagane/hive/foo, en algún GSN entre GSN 21 y GSN 50. Esta información a continuación se devuelve al servidor de puente de versión 312, que a continuación lee /Jagane/hive/foo desde el sistema de archivos distribuido 316 (en lugar de leer /jagane/hive/foo.tmp) y devuelve el nuevo nombre de archivo y los datos almacenados en el mismo al servidor de replicación de datos 310 en el RDC, para su replicación asíncrona al almacenamiento remoto 318.
Cambio de nombre/eliminación de acuerdo ejecutado por el servidor de replicación de datos mientras el servidor de puente de versión da servicio a la solicitud de extracción
La Figura 5 es un diagrama de bloques que ilustra el caso en el que se cambia de nombre/elimina un archivo de origen o una ruta padre mientras el servidor de puente de versión da servicio a la solicitud de extracción remota. En cualquier tiempo mientras el servidor de puente de versión 312 está leyendo un archivo del almacenamiento subyacente 316 para satisfacer una solicitud de extracción remota, el servidor de replicación de datos puede ejecutar otro acuerdo que cambia de nombre/elimina el archivo que es el objeto de la solicitud de extracción o el archivo padre del archivo que es el objeto de la solicitud de extracción. En este caso, la extracción del archivo fallará mientras esté en progreso porque se cambió el nombre del archivo, se eliminó o porque se ha cambiado la ruta. De acuerdo con una realización, el servidor de puente de versión 312 llama de nuevo al servicio de mapeo de nombre para mapear el nombre/ruta del archivo de origen. El valor de retorno del servicio de mapeo de nombre indicará si el archivo existe con otro nombre o si se eliminó.
Como se muestra en la Figura 5, el servidor de replicación de datos 310 del RDC 216 puede enviar, y el servidor de puente de versión 312 del DCO 214 puede recibir, una solicitud de extracción para un archivo específico, como se muestra en (1). En este ejemplo, la solicitud de extracción es para el archivo Jagane/hive/foo.tmp, en crear GSN 21. Como se muestra en (2), el servidor de puente de versión 312 en el DCO 214 a continuación llama al servidor de replicación de datos 308 para ejecutar el servicio de mapeo de nombre en las entradas almacenadas en caché que comprenden los metadatos de los acuerdos ejecutados en la caché de acuerdos ejecutados 309, que actualmente almacena acuerdos ejecutados hasta GSN 32. El servicio de mapeo de nombre devuelve un valor de /Jagane/hive/foo.tmp, lo que indica que foo.tmp no ha cambiado (es decir, no se ha cambiado de nombre ni eliminado) desde GSN 21. Como se muestra en (3), el servidor de puente de versión 312 en el DCO 214 comienza a dar servicio a la solicitud de extracción leyendo el nombre de archivo mapeado que, en este momento, sigue siendo el mismo /Jagane/hive/foo.tmp.
Como se muestra en (4), mientras se da servicio a la solicitud de extracción, el servidor de replicación de datos 308 ejecuta un acuerdo que cambia el nombre de /Jagane/hive/foo.tmp a /Jagane/hive/foo. Esto hace que la solicitud de extracción falle, ya que el servidor de puente de versión 312 ya no puede continuar leyendo /Jagane/hive/foo.tmp, ya que este archivo ha cambiado de nombre y /Jagane/hive/foo.tmp ya no existe. En respuesta a esto, el servidor de puente de versión 312, que había estado dando servicio a la solicitud para extraer /Jagane/hive/foo.tmp, ahora llama al servidor de replicación de datos 308 para volver a ejecutar el servicio de mapeo de nombre en /Jagane/hive/foo. tmp, GSN 21 en los metadatos almacenados en caché en la caché de acuerdos ejecutados 309, que ahora almacena acuerdos hasta GSN 50 (habiendo ocurrido presumiblemente el cambio de nombre de 'foo.tmp' a 'foo' en algún lugar entre GSN 32 y GSN50). El servicio de mapeo de nombre retorna con la información mapeada /jagane/hive/foo. El servidor de puente de versión 312 ahora puede continuar dando servicio a la solicitud de extracción leyendo el archivo mapeado /Jagane/hive/foo y proporcionando el mismo al servidor de replicación de datos 310 en el RDC 216, que actualizará su propia caché de acuerdos ejecutados 311 con los metadatos mapeados y escribirá los datos extraídos en el almacenamiento 318 en el RDC 216.
El archivo de origen o la ruta padre cambia de nombre/elimina después de una solicitud de extracción desde un sitio remoto
Si la solicitud de extracción se ha completado y únicamente después se cambia el nombre o se elimina el archivo o la ruta padre, no es necesario realizar ninguna acción, ya que los cachés de acuerdos ejecutados tanto en el DCO 214 como en el RDC 216 se actualizarán adecuadamente sin interferir con ninguna solicitud de extracción continua. Todos los centros de datos se enterarán del cambio de nombre/eliminación a través de sus respectivas cachés de acuerdos ejecutados a medida que se sincronicen.
Servidor de replicación de datos en el centro de datos remoto para llamar al servicio de mapeo de nombre en el nombre de archivo de destino
Los servidores de replicación de datos, de acuerdo con una realización, están configurados para extraer datos y escribir los datos extraídos en un archivo local de forma asíncrona. Este proceso puede verse interrumpido por un fallo si se cambia el nombre o se elimina el archivo local en el que escribe el servidor de replicación de datos. Esto se debe a que las operaciones de metadatos, es decir, los acuerdos, continúan ejecutándose mientras se extraen y escriben los datos. De acuerdo con una realización, para abordar esta eventualidad, se usa el servicio de mapeo de nombre del servidor de replicación de datos para mapear el archivo de destino al archivo recién cambiado de nombre. Cuando el servidor de replicación de datos remoto 310 ejecuta un acuerdo que da como resultado una extracción de datos, de acuerdo con una realización, se crea un objeto de copia de replicación de datos, cuyo objeto de copia de replicación de datos está asociado con un GSN. Este GSN se utiliza para dos propósitos:
1. El GSN se pasa desde el servidor de replicación de eliminación de datos al servidor de puente de versión 309 del DCCO 214 mientras se extraen datos;
2. El GSN se usa como un parámetro para el servicio de mapeo de nombre cuando falla la escritura en el archivo local.
Obsérvese que, el acuerdo de cambio de nombre/eliminación puede ejecutarse de forma asíncrona por otro hilo en el servidor de replicación de datos antes, durante o después del hilo que realiza la copia de datos:
Caso 1: El archivo de destino o la ruta padre se cambia de nombre y/o se elimina antes de que el hilo de copia de datos pueda comenzar a escribir los datos extraídos;
Caso 2: El archivo de destino o la ruta principal cambia de nombre y/o se elimina mientras el hilo de copia de datos escribe los datos extraídos; y
Caso 3: El archivo de destino o la ruta padre cambia de nombre y/o se elimina después de que el hilo de copia de datos haya terminado de escribir los datos extraídos. Esto no es motivo de preocupación, ya que los metadatos en la caché de acuerdos ejecutados se actualizarán de manera síncrona y se propagarán de forma remota.
Como se indició anteriormente, el objeto de copia de replicación de datos, de acuerdo con una realización, es el mecanismo mediante el que se implementa la copia asíncrona de los datos en el RDC 216. El objeto de copia de replicación de datos tiene su propio hilo de ejecución, lo que le proporciona la capacidad de ejecutarse independientemente de las modificaciones de los metadatos. Por lo tanto, las implementaciones del objeto de copia de replicación de datos permiten operaciones de metadatos síncronas y operaciones de datos asíncronas.
De acuerdo con una realización, cuando se crea el objeto de copia de replicación de datos, se le proporciona el nombre del archivo para el que se extraen los datos, así como el número de GSN en el que se nombró así al archivo. Esto permite que el objeto de copia de replicación de datos haga dos cosas:
1. Cuando solicita los datos del DCO 214, el servidor de puente de versión del RDC 216 proporciona tanto el nombre del archivo del que van a extraerse los datos, así como el GSN en el que se llamó el archivo.
2. Cuando el servidor de replicación de datos del RDC 216 escribe los datos extraídos del sistema de archivos distribuido del DCO 214 al sistema de archivos distribuido del RDC 216, de acuerdo con una realización, el servicio de mapeo de nombre se llama con estos dos parámetros: GSN y nombre de archivo, para determinar si el nombre del archivo cambió o no. Es decir, es posible que una aplicación de cliente 306 en el RDC 216 haya realizado cambios en los datos antes de que se hayan escrito los datos extraídos o mientras se escriben los datos del archivo extraído. Si el nombre del archivo ha cambiado entre el GSN y el estado actual del sistema de archivos subyacente, el servidor de replicación de datos 310 escribirá en el archivo tal como se nombra en el estado actual del sistema de archivos subyacente, usando los metadatos de la caché de acuerdos ejecutados 311 en el RDC 216. Esto sirve como una comprobación final para garantizar que los datos que se están escribiendo están actualizados, a partir del GSN más actual almacenado en la caché de acuerdos ejecutados 311.
Como las cachés de acuerdos ejecutados en cada centro de datos pueden implementarse en una memoria de acceso aleatorio volátil (memoria de acceso aleatorio dinámica (DRAM), por ejemplo), es susceptible de perder sus datos ante un fallo de energía o ante un fallo del servidor de replicación de datos al que está acoplado. En una implementación de este tipo, si falla el servidor de replicación de datos, el escritor recién elegido comenzará con una caché de acuerdos ejecutados vacía y puede devolver un número anormalmente alto de ErrorExecutedAgreementCacheGarbageCollected. Sin embargo, de acuerdo con una realización, la caché de acuerdos ejecutados puede mantener en un almacenamiento no volátil, lo que permite recuperarla al menos parcialmente (a partir de la última vez que la caché de acuerdos ejecutados persistió en la memoria no volátil) según sea necesario, tal como, en el caso, por ejemplo, del fallo/reelección de un escritor. El almacenamiento no volátil es parte del almacenamiento 316 y/o 318, o en su propia memoria no volátil especializada.
De acuerdo con una realización, cuando un nombre de archivo y/o ruta cambia y se vuelve inconsistente, toda la carpeta replicada puede marcarse como inconsistente y no confiable. De acuerdo con otra realización, el archivo/carpeta que se volvió inconsistente puede mantener en la memoria no volátil, permitiendo que únicamente los subdirectorios específicos que son inconsistentes se reparen como se detalla en el presente documento.
De acuerdo con otra realización, el centro de datos remoto que extrae los datos no necesita necesariamente extraer los datos del centro de datos de origen. Dada la naturaleza de equivalencia de una copia de los datos en el sistema de archivos distribuido, el RDC 216 puede alcanzar otro centro de datos (es decir, distinto del DCO 214) y solicitar (extraer) los mismos datos de ese otro centro de datos. Esto se puede hacer por una diversidad de razones, que incluyen el equilibrio de carga, la gestión de ancho de banda, la recuperación frente a desastres, la puesta en línea de un nuevo centro de datos y similares.
La Figura 6 es un diagrama de flujo de un método implementado por ordenador para mantener la consistencia de una carpeta replicada en un sistema de archivos distribuido, de acuerdo con una realización. El sistema de archivos distribuido que abarca, a través de una red informática, (al menos) un primer centro de datos y un segundo centro de datos. El método comprende, como se muestra en el bloque B61, recibir, en el primer centro de datos y en nombre de un cliente de aplicación en el primer centro de datos, una propuesta acordada para crear un archivo en la carpeta replicada y un GSN asociado con la propuesta acordada. El bloque B62 pide almacenamiento, en una primera caché de acuerdos ejecutados (mostrada en 309 en la Figura 3, por ejemplo) acoplada a un primer servidor de replicación de datos (mostrado en 308 en la Figura 3, por ejemplo) en el primer centro de datos (214 en la Figura 3), metadatos del archivo a crear y el GSN asociado con la propuesta acordada. Posteriormente, como se muestra en B63, los metadatos y el GSN asociado pueden almacenarse de manera síncrona en una segunda caché de acuerdos ejecutados (311 en la Figura 3) acoplada a un segundo servidor de replicación de datos (310 en la Figura 3) en el segundo centro de datos (mostrado con el número de referencia 216 en la Figura 3). A continuación, el archivo se crea en el almacenamiento (por ejemplo, en el almacenamiento 316 en la Figura 3) por el primer servidor de replicación de datos en el primer centro de datos en nombre del cliente de aplicación (304 en la Figura 3), como se muestra en B64. A continuación, la aplicación de cliente escribe datos en el archivo creado en el almacenamiento del primer centro de datos, como se observa en el bloque B65.
El método implementado por ordenador puede comprender, además, como se muestra en el bloque B66, mantener sincronizadas y actualizadas las cachés de acuerdos ejecutados a medida que se acuerdan propuestas de cambios en el archivo. De hecho, los metadatos actualizados y el GSN asociado correspondientes a cualquier propuesta acordada, recibidos en el primer centro de datos, para cambiar el nombre del archivo, la ruta o los datos del archivo pueden almacenarse en la primera caché de acuerdos ejecutados y los metadatos actualizados y el GSN asociado en la segunda caché de acuerdos ejecutados también pueden almacenarse de manera síncrona en el segundo centro de datos. Asimismo, los metadatos actualizados y el GSN asociado correspondientes a cualquier propuesta acordada, recibidos en el segundo centro de datos, para cambiar un nombre de archivo, ruta o datos del archivo pueden almacenarse en la segunda caché de acuerdos ejecutados y los metadatos actualizados y el GSN asociado pueden almacenarse de manera síncrona en la primera caché acuerdos ejecutados.
En la Figura 7, el bloque B71 pide recibir una solicitud desde el segundo centro de datos para los datos del archivo (también denominado en el presente documento solicitud de extracción de datos), comprendiendo la solicitud al menos un crear GSN asociado con un acuerdo para un creación del archivo cuyos datos se solicitan. El bloque B72 pide, en respuesta a la recepción de la solicitud, buscar entradas en la primera caché de acuerdos ejecutados para obtener metadatos actualizados del archivo asociado con un GSN que es mayor (por ejemplo, representativo de una propuesta acordada más recientemente) que el crear GSN del archivo cuyos datos se solicitan. Esto capturará cualquier cambio realizado en el archivo desde que se inició la solicitud de extracción. Después de buscar las entradas de la primera caché de acuerdos ejecutados, el bloque B73 especifica la lectura de datos correspondientes a los metadatos recibidos en la solicitud si la búsqueda no encontró metadatos actualizados y la lectura de datos correspondientes a los metadatos actualizados si la búsqueda encontró metadatos actualizados. Los datos leídos pueden proporcionarse a continuación en respuesta a la solicitud recibida desde el segundo centro de datos para los datos del archivo, como se muestra en B74.
En la Figura 8, se pueden buscar entradas en la segunda caché de acuerdos ejecutados, como se muestra en B81, para metadatos del archivo que está asociado con un GSN que es mayor que el GSN asociado con los metadatos actualizados. Después de buscar las entradas de la segunda caché de acuerdos ejecutados, como se muestra en B82, los datos proporcionados se pueden escribir en el almacenamiento en el segundo centro de datos si al buscar en la segunda caché de acuerdos ejecutados no se encontraron metadatos actualizados como se muestra en B83 (sin cambios intermedios en el archivo donde se crearon) y leer los datos correspondientes a los metadatos encontrados en la segunda caché de acuerdos ejecutados y escribir los datos leídos en el almacenamiento en el segundo centro de datos si al buscar en la segunda caché de acuerdos ejecutados se encontraron metadatos actualizados, como se muestra en B84 (se realizan cambios intermedios en el archivo, como lo demuestra el hallazgo de metadatos actualizados en la segunda caché de acuerdos ejecutados.
De acuerdo con una realización, la búsqueda se puede llevar a cabo ejecutando una API de servicio de mapeo de nombre. Al menos una porción de la primera y segunda cachés de acuerdos ejecutados se puede registrar (es decir, mantener) en memorias no volátiles en el primer y segundo centros de datos, respectivamente. Si es necesario reconstruir las cachés de acuerdos ejecutados, se puede recuperar la versión de las mismas en la memoria no volátil, recopilar basura según sea necesario y actualizarla al GSN del acuerdo actual. De acuerdo con otra realización, las cachés de acuerdos ejecutados no se registran diariamente en una memoria volátil y simplemente se reconstruyen desde cero según sea necesario.
Otra realización de un método implementado por ordenador puede comprender proporcionar una primera caché de acuerdos ejecutados en un primer centro de datos y proporcionar una segunda caché de acuerdos ejecutados en un segundo centro de datos; recibir acuerdos sobre propuestas para crear o realizar cambios en archivos almacenados en el primer y segundo centros de datos; almacenar metadatos de los archivos a los que se refieren los acuerdos recibidos en una de la primera y segunda cachés de acuerdos ejecutados; mantener la primera y segunda cachés de acuerdos ejecutados entre sí antes de que se creen o cambien los archivos a los que hacen referencia los acuerdos recibidos; crear o realizar cambios en el archivo al que hacen referencia los acuerdos recibidos únicamente después de que se hayan sincronizado la primera y segunda cachés de acuerdos ejecutados; y comprobar al menos una de la primera y segunda cachés de acuerdos ejecutados para detectar metadatos actualizados siempre que se reciban solicitudes de datos de archivos almacenados en el primer o segundo centros de datos en cualquiera del primer o segundo centro de datos y, en respuesta a las solicitudes recibidas, proporcionar datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados.
Se asocia un GSN con cada acuerdo y el GSN de cada acuerdo se almacena junto con los metadatos en la primera y segunda cachés de acuerdos ejecutados. La comprobación o búsqueda de metadatos actualizados se lleva a cabo buscando entradas en la primera y/o segunda cachés de acuerdos ejecutados metadatos actualizados del archivo usando el GSN asociado con los metadatos actualizados. La comprobación o búsqueda se puede realizar en el primer centro de datos mediante un primer servidor de replicación de datos llamando a un servicio de mapeo de nombre en las entradas en la primera caché de acuerdos ejecutados y la comprobación o búsqueda se puede realizar en el segundo centro de datos mediante un segundo servidor de replicación de datos llamando un servicio de mapeo de nombre en las entradas en la segunda caché de acuerdos ejecutados.
Las solicitudes de datos pueden recibirse en el primer centro de datos en un primer servidor de puente de versión que está configurado para hacer que el primer servidor de replicación de datos llame al servicio de mapeo de nombre para comprobar la primera caché de acuerdos ejecutados en busca de metadatos actualizados correspondientes a los datos solicitados. De manera similar, las solicitudes de datos pueden recibirse en el segundo centro de datos en un segundo servidor de puente de versión que está configurado para hacer que el segundo servidor de replicación de datos llame al servicio de mapeo de nombre para comprobar la segunda caché de acuerdos ejecutados en busca de metadatos actualizados correspondientes a los datos solicitados. Dar servicio a las solicitudes de datos puede llevarse a cabo mediante el primer servidor de puente de versión, que recupera y proporciona datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados en la primera caché de acuerdos ejecutados. Análogamente, dar servicio a las solicitudes de datos puede llevarse a cabo mediante el segundo servidor de puente de versión, que recupera y proporciona datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados en la segunda caché de acuerdos ejecutados. De esta manera, todas las solicitudes emitidas por el primer servidor de replicación de datos en el primer centro de datos para datos almacenados en el segundo centro de datos pueden ser servidas por el segundo servidor de puente de versión en el segundo centro de datos y en donde todas las solicitudes emitidas por el segundo servidor de replicación de datos en el segundo centro de datos para los datos almacenados en el primer centro de datos puede ser servidas por el primer servidor de puente de versión en el primer centro de datos.
La Figura 9 ilustra un diagrama de bloques de un dispositivo informático 900 con el que pueden implementarse las realizaciones. El sistema informático 900 puede incluir un bus 901 u otro mecanismo de comunicación para comunicar información, y uno o más procesadores 902 acoplados con el bus 901 para procesar información. El sistema informático 900 comprende además una memoria de acceso aleatorio (RAM) u otro dispositivo de almacenamiento dinámico 904 (denominado como memoria principal), acoplado al bus 901 para almacenar información e instrucciones a ejecutarse por el procesador o procesadores 902. La memoria principal 904 también puede usarse para almacenar variables temporales u otra información intermedia durante la ejecución de instrucciones por el procesador 902. El dispositivo informático 900 puede incluir también una memoria de solo lectura (ROM) y/u otro dispositivo de almacenamiento estático 906 acoplado al bus 901 para almacenar información estática e instrucciones para el procesador 902. Un dispositivo de almacenamiento de datos tangible no transitorio 907 tal como, por ejemplo, un disco magnético o almacenamiento Flash, puede acoplarse al bus 901 para almacenar información e instrucciones. El dispositivo de almacenamiento de datos tangible no transitorio puede configurarse para almacenar instrucciones legibles por ordenador que, cuando son ejecutadas por el procesador 902, hacen que el sistema informático lleve a cabo una o más de las realizaciones descritas y mostradas en el presente documento. El dispositivo informático 900 puede también estar acoplado mediante el bus 901 a un dispositivo de visualización 910 para visualizar información a un usuario informático. Un dispositivo de entrada alfanumérico 922, que incluye teclas alfanuméricas y otras, puede estar acoplado al bus 901 para comunicar información y selecciones de comando al procesador o procesadores 902. Otro tipo de dispositivo de entrada de usuario es el control de cursor 923, tal como un ratón, una bola de mando o teclas de dirección de cursor para comunicar información de dirección y ordenar selecciones al procesador 902 y para controlar movimiento de cursor en la pantalla 921. El dispositivo informático 900 puede estar acoplado, mediante un dispositivo de comunicación (por ejemplo, modem, NIC) a una red 926 y a uno o más nodos de un sistema informático distribuido.
Las realizaciones están relacionadas con el uso de un dispositivo informático y/o de una pluralidad de tales dispositivos informáticos para mantener la consistencia de metadatos y datos a través de centros de datos a través de una red informática. De acuerdo con una realización, los métodos y sistemas descritos en el presente documento pueden proporcionarse por uno o más dispositivos informáticos 900 en respuesta al procesador o procesadores 902 que ejecutan secuencias de instrucciones contenidas en la memoria 904. Tales instrucciones pueden leerse en memoria 904 de otro medio legible por ordenador, tal como un dispositivo de almacenamiento de datos 907. La ejecución de la secuencias de instrucciones contenidas en memoria 904 hace que el procesador o procesadores 902 realicen las etapas y tengan la funcionalidad descrita en el presente documento. En realizaciones alternativas, puede usarse circuitería de cableado permanente en lugar de, o en combinación, con instrucciones de software para implementar la presente invención. Por lo tanto, la presente invención no está limitada a combinación específica alguna de circuitería de hardware y software. De hecho, debería entenderse por los expertos en la materia que cualquier dispositivo informático adecuado puede implementar la funcionalidad descrita en el presente documento. El dispositivo informático puede incluir uno o una pluralidad de microprocesadores que funcionan para realizar las funciones deseadas. En una realización, las instrucciones ejecutadas por el microprocesador o microprocesadores son operativas para provocar que el microprocesador o microprocesadores realicen las etapas descritas en el presente documento. Las instrucciones pueden almacenarse en cualquier medio legible por ordenador. En una realización, pueden almacenarse en una memoria de semiconductores no volátil externa al microprocesador, o integrarse con el microprocesador. En otra realización, las instrucciones pueden almacenarse en un disco y leerse en una memoria de semiconductores volátil antes de su ejecución por el microprocesador.
Las diversas características y procesos anteriormente descritos pueden usarse de manera independiente unos de otros, o pueden combinarse de diversas maneras. Aunque se han descrito ciertas realizaciones ilustrativas, estas realizaciones se han presentado a modo de ejemplo únicamente, y no se pretende que limiten el alcance de las invenciones desveladas en el presente documento. Por lo tanto, nada en la descripción anterior pretende implicar que cualquier rasgo, característica, etapa, módulo o bloque particular sea necesario o indispensable. El alcance de la invención se define por las reivindicaciones adjuntas.
Claims (15)
1. Un método implementado por ordenador para mantener la consistencia de una carpeta replicada en un sistema de archivos distribuido que abarca, a través de una red informática (302), al menos un primer centro de datos (214) y un segundo centro de datos (216), comprendiendo el método:
recibir en el primer centro de datos (214), en nombre de un cliente de aplicación (304) en comunicación con el primer centro de datos (214), una propuesta acordada para crear o realizar cambios en un archivo en la carpeta replicada y un número de secuencia global "GSN" que está asociado con y es único para la propuesta acordada (B61);
almacenar, en una primera caché de acuerdos ejecutados (309) acoplada a un primer servidor de replicación de datos (308) en el primer centro de datos (214), metadatos del archivo a crear y el GSN único asociado con la propuesta acordada (B62, B63) y actualizar una segunda caché de acuerdos ejecutados (311) acoplada a un segundo servidor de replicación de datos (310) en el segundo centro de datos (216) con los metadatos y el GSN único asociado;
después de que los metadatos del archivo a crear se hayan almacenado en la primera caché de acuerdos ejecutados (309) y en la segunda caché de acuerdos ejecutados (311), crear el archivo en el almacenamiento en el primer centro de datos (214) en nombre del cliente de aplicación (B64); y permitir que el cliente de aplicación (304) escriba datos en el archivo creado en el almacenamiento en el primer centro de datos (214, B65).
2. El método implementado por ordenador de la reivindicación 1, que comprende, además:
almacenar metadatos actualizados y GSN único asociado correspondiente a cualquier propuesta acordada, recibida en el primer centro de datos (214), para cambiar un nombre de archivo, ruta o datos del archivo en la primera caché de acuerdos ejecutados (309) y almacenar los metadatos actualizados y GSN único asociado en la segunda caché de acuerdos ejecutados (311) en el segundo centro de datos (216, B66).
3. El método implementado por ordenador de la reivindicación 1, que comprende, además:
almacenar metadatos actualizados y GSN único asociado correspondiente a cualquier propuesta acordada, recibida en el segundo centro de datos (216), para cambiar un nombre de archivo, ruta o datos del archivo en la segunda caché de acuerdos ejecutados (311) y almacenar los metadatos actualizados y GSN único asociado en la primera caché de acuerdos ejecutados (309).
4. El método implementado por ordenador de la reivindicación 1, que comprende, además:
recibir una solicitud desde el segundo centro de datos (216) para los datos del archivo, comprendiendo la solicitud al menos un crear GSN asociado con un acuerdo para la creación del archivo cuyos datos se solicitan (B71); en respuesta a la recepción de la solicitud, buscar entradas en la primera caché de acuerdos ejecutados (309) para metadatos actualizados del archivo que está asociado con un GSN único que es mayor que el crear GSN del archivo cuyos datos se solicitan (B72);
después de buscar las entradas de la primera caché de acuerdos ejecutados (309), leer datos correspondientes a los metadatos recibidos en la solicitud si la búsqueda no encontró metadatos actualizados y la lectura de datos correspondientes a los metadatos actualizados si la búsqueda encontró metadatos actualizados (B73); y proporcionar los datos leídos en respuesta a la solicitud recibida desde el segundo centro de datos para los datos del archivo (B74), en donde el método preferentemente comprende, además: buscar entradas en la segunda caché de acuerdos ejecutados para metadatos del archivo que está asociado con un GSN único que es mayor que el GSN único asociado con los metadatos actualizados (B81); y
después de buscar las entradas de la segunda caché de acuerdos ejecutados (B82):
escribir los datos proporcionados en el almacenamiento en el segundo centro de datos (216) si al buscar en la segunda caché de acuerdos ejecutados (311) no se encontraron metadatos actualizados (B83); y leer datos correspondientes a los metadatos encontrados en la segunda caché de acuerdos ejecutados (311) y escribir los datos leídos en el almacenamiento en el segundo centro de datos (216) si al buscar en la segunda caché de acuerdos ejecutados se encontraron metadatos actualizados (B84), y, además
en donde la búsqueda se lleva a cabo ejecutando una interfaz de programa de aplicación (API) de servicio de mapeo de nombre.
5. El método implementado por ordenador de la reivindicación 1, que comprende además la solicitud desde el segundo centro de datos (216) para que los datos del archivo sean recibidos por un primer servidor de puente de versión en el primer centro de datos (214), estando separado el primer servidor de puente de versión y siendo distinto del primer servidor de replicación de datos (308).
6. El método implementado por ordenador de la reivindicación 1, que comprende, además:
mantener periódicamente al menos una porción de la primera caché de acuerdos ejecutados (308) en la memoria no volátil en el primer centro de datos (214); y
mantener periódicamente al menos una porción de la segunda caché de acuerdos ejecutados (311) en la memoria no volátil en el segundo centro de datos (216).
7. El método implementado por ordenador de la reivindicación 1, que comprende, además:
buscar en al menos una de la primera y segunda cachés de acuerdos ejecutados (309, 311) metadatos actualizados siempre que se reciban solicitudes de datos de archivos almacenados en el primer o segundo centros de datos (214, 216) en el primer o segundo centro de datos (214, 216) y, en respuesta a las solicitudes recibidas, proporcionar datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados.
8. El método implementado por ordenador de la reivindicación 7, que comprende además que la búsqueda de metadatos actualizados se lleva a cabo buscando entradas en la al menos una de la primera y segunda cachés de acuerdos ejecutados (309, 311) para metadatos actualizados del archivo, usando el GSN único asociado con los metadatos actualizados.
9. El método implementado por ordenador de la reivindicación 7, en donde la búsqueda se realiza en el primer centro de datos (214) mediante un primer servidor de replicación de datos (308) que llama a un servicio de mapeo de nombre en las entradas en la primera caché de acuerdos ejecutados (309) y en donde la búsqueda se realiza en el segundo centro de datos (216) mediante un segundo servidor de replicación de datos (310) que llama a un servicio de mapeo de nombre en las entradas en la segunda caché de acuerdos ejecutados (311), en donde el método comprende, además:
recibir las solicitudes de datos en el primer centro de datos (214) en un primer servidor de puente de versión (312) que está configurado para hacer que el primer servidor de replicación de datos (308) llame al servicio de mapeo de nombre para comprobar la primera caché de acuerdos ejecutados (309) para metadatos actualizados correspondientes a los datos solicitados; y
recibir las solicitudes de datos en el segundo centro de datos (216) en un segundo servidor de puente de versión (314) que está configurado para hacer que el segundo servidor de replicación de datos (310) llame al servicio de mapeo de nombre para comprobar la segunda caché de acuerdos ejecutados (311) para metadatos actualizados correspondientes a los datos solicitados.
10. El método implementado por ordenador de la reivindicación 9, que comprende, además:
dar servicio a las solicitudes de datos mediante el primer servidor de puente de versión, que recupera y proporciona datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados en la primera caché de acuerdos ejecutados (309); y
dar servicio a las solicitudes de datos mediante el segundo servidor de puente de versión, que recupera y proporciona datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados en la segunda caché de acuerdos ejecutados (311).
11. El método implementado por ordenador de la reivindicación 9, en donde todas las solicitudes emitidas por el primer servidor de replicación de datos en el primer centro de datos (214) para datos almacenados en el segundo centro de datos (216) son servidas por el segundo servidor de puente de versión (314) en el segundo centro de datos (216) y en donde todas las solicitudes emitidas por el segundo servidor de replicación de datos (310) en el segundo centro de datos (216) para los datos almacenados en el primer centro de datos (214) son servidas por el primer servidor de puente de versión (312) en el primer centro de datos (214).
12. Un sistema implementado por ordenador que abarca el primer y segundo centros de datos (214, 216) acoplado a una red informática (302), comprendiendo el sistema:
en el primer centro de datos (214): un primer almacenamiento (316); un primer servidor de replicación de datos (308); una primera caché configurada para almacenar metadatos (309) de propuestas acordadas para crear o realizar cambios en archivos y los respectivos números de secuencia globales "GSN" asociados con y únicos de las propuestas acordadas (B61); y un primer servidor de puente de versión (312); y
en el segundo centro de datos (216): un segundo almacenamiento (318); un segundo servidor de replicación de datos (310); una segunda caché (311) configurada para almacenar metadatos de propuestas acordadas para crear o realizar cambios en archivos y los respectivos números de secuencia globales (GSN) asociados con y únicos de las propuestas acordadas (B61); y un segundo servidor de puente de versión (314);
en donde la primera y segunda cachés (309, 311) están configuradas para almacenar los metadatos y los GSN en el primer y segundo almacenamientos (316, 318) y para que sean consistentes entre sí antes de que se almacene algún dato asociados con los metadatos y los GSN en el primer y segundo almacenamientos (316, 318), en donde las solicitudes de datos almacenados en el primer almacenamiento (316) emitidas desde el segundo centro de datos (216) son servidas por el primer servidor de puente de versión (312), que está configurado para hacer que el primer servidor de replicación (308) busque en la primera caché (309) metadatos actualizados de los datos solicitados, estando configurado además el primer servidor de puente de versión (312) para proporcionar al segundo centro de datos (216) datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados en la primera caché (309); y
en donde la solicitud de datos almacenados en el segundo almacenamiento (318) emitida desde el primer centro de datos (214) es servida por el segundo servidor de puente de versión (314), que está configurado para hacer que el segundo servidor de replicación (310) busque en la segunda caché (311) metadatos actualizados, estando configurado además el segundo servidor de puente de versión (314) para proporcionar al primer centro de datos (214) datos correspondientes a los metadatos actualizados cuando se encuentran metadatos actualizados en la segunda caché (311).
13. El sistema implementado por ordenador de la reivindicación 12, en donde cada uno del primer y segundo servidores de replicación de datos (308, 310) está configurado para buscar en la primera y segunda cachés (309, 311), respectivamente, metadatos actualizados de los datos solicitados usando el GSN único.
14. El sistema implementado por ordenador de la reivindicación 12, en donde el primer y segundo servidores de replicación de datos (308, 310) están configurados para buscar en la primera y segunda cachés (309, 311), respectivamente, ejecutando cada uno un servicio de mapeo de nombre en las entradas en la primera y segunda cachés (309, 311), respectivamente.
15. El método implementado por ordenador de la reivindicación 9, en donde todas las solicitudes emitidas por el primer servidor de replicación de datos (308) en el primer centro de datos (214) para datos almacenados en el segundo centro de datos (216) son servidas por el segundo servidor de puente de versión (314) en el segundo centro de datos (216) y en donde todas las solicitudes emitidas por el segundo servidor de replicación de datos (310) en el segundo centro de datos (216) para los datos almacenados en el primer centro de datos (214) son servidas por el primer servidor de puente de versión (312) en el primer centro de datos (214).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/457,837 US11360942B2 (en) | 2017-03-13 | 2017-03-13 | Methods, devices and systems for maintaining consistency of metadata and data across data centers |
| PCT/US2018/022062 WO2018169886A1 (en) | 2017-03-13 | 2018-03-12 | Methods, devices and systems for maintaining consistency of metadata and data across data centers |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2969620T3 true ES2969620T3 (es) | 2024-05-21 |
Family
ID=63446449
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18767539T Active ES2969620T3 (es) | 2017-03-13 | 2018-03-12 | Métodos, dispositivos y sistemas para mantener la consistencia de metadatos y datos en todos los centros de datos |
Country Status (8)
| Country | Link |
|---|---|
| US (2) | US11360942B2 (es) |
| EP (1) | EP3596619B8 (es) |
| JP (1) | JP7009488B2 (es) |
| CN (1) | CN110447021B (es) |
| AU (1) | AU2018236167B2 (es) |
| CA (1) | CA3055301A1 (es) |
| ES (1) | ES2969620T3 (es) |
| WO (1) | WO2018169886A1 (es) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10789217B2 (en) * | 2018-06-22 | 2020-09-29 | Microsoft Technology Licensing, Llc | Hierarchical namespace with strong consistency and horizontal scalability |
| US11100086B2 (en) * | 2018-09-25 | 2021-08-24 | Wandisco, Inc. | Methods, devices and systems for real-time checking of data consistency in a distributed heterogenous storage system |
| US10944850B2 (en) * | 2018-10-29 | 2021-03-09 | Wandisco, Inc. | Methods, devices and systems for non-disruptive upgrades to a distributed coordination engine in a distributed computing environment |
| US11573927B1 (en) | 2018-10-31 | 2023-02-07 | Anaplan, Inc. | Method and system for implementing hidden subscriptions in a distributed computation system |
| US11481378B1 (en) * | 2018-10-31 | 2022-10-25 | Anaplan, Inc. | Method and system for servicing query requests using document-based metadata |
| US11475003B1 (en) * | 2018-10-31 | 2022-10-18 | Anaplan, Inc. | Method and system for servicing query requests using dataspaces |
| US11354324B1 (en) | 2018-10-31 | 2022-06-07 | Anaplan, Inc. | Method and system for servicing query requests using revisions maps |
| US11281683B1 (en) | 2018-10-31 | 2022-03-22 | Anaplan, Inc. | Distributed computation system for servicing queries using revisions maps |
| US11580105B2 (en) | 2018-10-31 | 2023-02-14 | Anaplan, Inc. | Method and system for implementing subscription barriers in a distributed computation system |
| CN109960687A (zh) * | 2019-03-28 | 2019-07-02 | 北京百分点信息科技有限公司 | 一种文件处理系统及方法 |
| EP3901964A1 (en) * | 2020-04-22 | 2021-10-27 | Siemens Healthcare GmbH | Intelligent scan recommendation for magnetic resonance imaging |
| CN111309719B (zh) * | 2020-05-13 | 2020-08-21 | 深圳市赢时胜信息技术股份有限公司 | 一种对应HBase数据库的数据规范方法及系统 |
| CN112597249B (zh) * | 2020-12-26 | 2023-06-20 | 湖南快乐阳光互动娱乐传媒有限公司 | 一种业务数据的同步分发存储方法及系统 |
| CA3213054A1 (en) * | 2021-03-30 | 2022-10-06 | Vernon L. Weitzman | Hub and spoke architecture for cloud-based synchronization |
| CN113032338B (zh) * | 2021-05-31 | 2021-09-07 | 智者四海（北京）技术有限公司 | 一种跨数据中心的数据存储和查询方法与系统 |
| CN113778764B (zh) * | 2021-08-24 | 2023-10-27 | 百融至信(北京)科技有限公司 | 一种hbase数据双活系统及方法 |
| CN113722401B (zh) * | 2021-11-04 | 2022-02-01 | 树根互联股份有限公司 | 数据缓存方法、装置、计算机设备及可读存储介质 |
| US11954073B2 (en) * | 2022-03-16 | 2024-04-09 | International Business Machines Corporation | Multi-protocol multi-site replication |
| CN115657956B (zh) * | 2022-11-02 | 2023-08-22 | 中国科学院空间应用工程与技术中心 | 一种应对缓存数据丢失的元数据一致性写入方法和系统 |
Family Cites Families (90)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5261085A (en) | 1989-06-23 | 1993-11-09 | Digital Equipment Corporation | Fault-tolerant system and method for implementing a distributed state machine |
| DE4497149B4 (de) | 1993-09-24 | 2005-02-10 | Oracle Corp., Redwood City | Computerbezogenes Verfahren zur Datenreplikation in Peer-to-Peer-Umgebung |
| US5699515A (en) | 1995-01-23 | 1997-12-16 | Hewlett-Packard Company | Backoff scheme for access collision on a local area network |
| US5862346A (en) | 1996-06-28 | 1999-01-19 | Metadigm | Distributed group activity data network system and corresponding method |
| US6006034A (en) | 1996-09-05 | 1999-12-21 | Open Software Associates, Ltd. | Systems and methods for automatic application version upgrading and maintenance |
| US5781910A (en) | 1996-09-13 | 1998-07-14 | Stratus Computer, Inc. | Preforming concurrent transactions in a replicated database environment |
| US6247059B1 (en) | 1997-09-30 | 2001-06-12 | Compaq Computer Company | Transaction state broadcast method using a two-stage multicast in a multiple processor cluster |
| US6014669A (en) | 1997-10-01 | 2000-01-11 | Sun Microsystems, Inc. | Highly-available distributed cluster configuration database |
| US6202067B1 (en) | 1998-04-07 | 2001-03-13 | Lucent Technologies, Inc. | Method and apparatus for correct and complete transactions in a fault tolerant distributed database system |
| US6261085B1 (en) | 1998-06-22 | 2001-07-17 | Reena Corporation | Tandem injection molding apparatus and press therefor |
| US6401120B1 (en) | 1999-03-26 | 2002-06-04 | Microsoft Corporation | Method and system for consistent cluster operational data in a server cluster using a quorum of replicas |
| US6513084B1 (en) | 1999-06-29 | 2003-01-28 | Microsoft Corporation | Arbitration of state changes |
| US7013465B1 (en) | 1999-08-17 | 2006-03-14 | Emc Corporation | System, device and method for interprocessor communication in a computer system |
| US7069320B1 (en) | 1999-10-04 | 2006-06-27 | International Business Machines Corporation | Reconfiguring a network by utilizing a predetermined length quiescent state |
| US20140164262A1 (en) | 2012-12-11 | 2014-06-12 | John D. Graham | System and method for management of intangible assets |
| US8332740B2 (en) | 2000-01-19 | 2012-12-11 | Graham John D | Systems and method for management of intangible assets |
| US6898642B2 (en) | 2000-04-17 | 2005-05-24 | International Business Machines Corporation | Synchronous collaboration based on peer-to-peer communication |
| US7185076B1 (en) | 2000-05-31 | 2007-02-27 | International Business Machines Corporation | Method, system and program products for managing a clustered computing environment |
| US7155524B1 (en) | 2000-12-04 | 2006-12-26 | Lucent Technologies Inc. | Backoff protocols and methods for distributed mutual exclusion and ordering |
| US6931431B2 (en) | 2001-01-13 | 2005-08-16 | International Business Machines Corporation | Agreement and atomic broadcast in asynchronous networks |
| EP1449093A4 (en) | 2001-10-18 | 2005-06-08 | Univ Nebraska | ERROR TOLERANT FIREWALL LAYER STRUCTURES |
| US7024429B2 (en) | 2002-01-31 | 2006-04-04 | Nextpage,Inc. | Data replication based upon a non-destructive data model |
| US7305585B2 (en) | 2002-05-23 | 2007-12-04 | Exludus Technologies Inc. | Asynchronous and autonomous data replication |
| US7558883B1 (en) | 2002-06-28 | 2009-07-07 | Microsoft Corporation | Fast transaction commit |
| MXPA05004409A (es) | 2002-10-25 | 2005-07-26 | S & C Electric Co | Metodo y aparato para el control de un sistema de energia electrica en respuesta a anormalidades de circuito. |
| US8315975B2 (en) | 2002-12-09 | 2012-11-20 | Hewlett-Packard Development Company, L.P. | Symbiotic wide-area file system and method |
| US8311980B2 (en) | 2002-12-09 | 2012-11-13 | Hewlett-Packard Development Company, L.P. | Namespace consistency for a wide-area file system |
| US7197632B2 (en) | 2003-04-29 | 2007-03-27 | International Business Machines Corporation | Storage system and cluster maintenance |
| US20050086384A1 (en) | 2003-09-04 | 2005-04-21 | Johannes Ernst | System and method for replicating, integrating and synchronizing distributed information |
| US20050198493A1 (en) | 2003-09-17 | 2005-09-08 | Bartas John A. | Distribution methods and apparatus for promoting distributed digital content on a local network |
| US8161438B2 (en) | 2003-10-21 | 2012-04-17 | Mentor Graphics Corporation | Determining mutual inductance between intentional inductors |
| EP1591858B1 (en) | 2004-04-26 | 2016-04-13 | Micron Technology, Inc. | Trimming functional parameters in integrated circuits |
| US7334154B2 (en) | 2004-06-18 | 2008-02-19 | Microsoft Corporation | Efficient changing of replica sets in distributed fault-tolerant computing system |
| US7467078B2 (en) | 2004-07-16 | 2008-12-16 | Agilent Technologies Inc. | Portable distributed application framework |
| US9753754B2 (en) | 2004-12-22 | 2017-09-05 | Microsoft Technology Licensing, Llc | Enforcing deterministic execution of threads of guest operating systems running in a virtual machine hosted on a multiprocessor machine |
| US20060143517A1 (en) | 2004-12-22 | 2006-06-29 | Microsoft Corporation | Replicated virtual machine |
| US8103644B2 (en) | 2005-01-12 | 2012-01-24 | Microsoft Corporation | Data access layer class generator |
| US9361311B2 (en) | 2005-01-12 | 2016-06-07 | Wandisco, Inc. | Distributed file system using consensus nodes |
| US9424272B2 (en) * | 2005-01-12 | 2016-08-23 | Wandisco, Inc. | Distributed file system using consensus nodes |
| US8364633B2 (en) | 2005-01-12 | 2013-01-29 | Wandisco, Inc. | Distributed computing systems and system components thereof |
| US7224938B2 (en) | 2005-03-11 | 2007-05-29 | Freescale Semiconductor Inc. | Method of communicating with a network device |
| US7765186B1 (en) | 2005-04-13 | 2010-07-27 | Progress Software Corporation | Update-anywhere replication of distributed systems |
| US7426653B2 (en) | 2005-04-13 | 2008-09-16 | Progress Software Corporation | Fault tolerant distributed lock management |
| US7814322B2 (en) | 2005-05-03 | 2010-10-12 | Sri International | Discovery and authentication scheme for wireless mesh networks |
| US7400596B1 (en) | 2005-08-17 | 2008-07-15 | Rockwell Collins, Inc. | Dynamic, multicast routing using a quality of service manager |
| US20100070982A1 (en) * | 2005-09-09 | 2010-03-18 | Pitts William M | Distributed File System Consistency Mechanism Extension For Accelerating Communications Between Distributed Applications |
| US20070204078A1 (en) | 2006-02-09 | 2007-08-30 | Intertrust Technologies Corporation | Digital rights management engine systems and methods |
| US7598751B2 (en) | 2006-08-14 | 2009-10-06 | Clemson University Research Foundation | Impedance-based arc fault determination device (IADD) and method |
| JP4606404B2 (ja) | 2006-12-01 | 2011-01-05 | 富士通株式会社 | 計算資源管理プログラムおよび計算資源管理装置 |
| US9390396B2 (en) | 2006-12-04 | 2016-07-12 | Excalibur Ip, Llc | Bootstrapping social networks using augmented peer to peer distributions of social networking services |
| US7788522B1 (en) | 2007-05-31 | 2010-08-31 | Oracle America, Inc. | Autonomous cluster organization, collision detection, and resolutions |
| US8180747B2 (en) | 2007-11-12 | 2012-05-15 | F5 Networks, Inc. | Load sharing cluster file systems |
| US7849223B2 (en) | 2007-12-07 | 2010-12-07 | Microsoft Corporation | Virtually synchronous Paxos |
| US8214788B2 (en) | 2008-03-08 | 2012-07-03 | Mentor Graphics Corporation | High-frequency VLSI interconnect and intentional inductor impedance extraction in the presence of a multi-layer conductive substrate |
| US20100018014A1 (en) | 2008-07-23 | 2010-01-28 | Brian Boisclair | Messenger clamp |
| KR100966566B1 (ko) | 2009-01-29 | 2010-06-29 | 엘지전자 주식회사 | 효율적인 공용 ｅ-ｄｃｈ 관리를 위한 신호 전송 기법 |
| US8336080B2 (en) | 2009-06-26 | 2012-12-18 | Symbol Technologies, Inc. | Methods and apparatus for rating device security and automatically assessing security compliance |
| US8489654B2 (en) | 2009-08-28 | 2013-07-16 | Beijing Innovation Works Technology Company Limited | Method and system for forming a virtual file system at a computing device |
| US9141449B2 (en) | 2009-10-30 | 2015-09-22 | Symantec Corporation | Managing remote procedure calls when a server is unavailable |
| US8868508B2 (en) | 2010-02-09 | 2014-10-21 | Google Inc. | Storage of data in a distributed storage system |
| US8996611B2 (en) | 2011-01-31 | 2015-03-31 | Microsoft Technology Licensing, Llc | Parallel serialization of request processing |
| US8135987B2 (en) | 2010-06-03 | 2012-03-13 | Microsoft Corporation | Collection ordering for replicated state machines |
| US20110314163A1 (en) | 2010-06-16 | 2011-12-22 | Mmb Research Inc. | Wireless communication network for smart appliances |
| US9323775B2 (en) | 2010-06-19 | 2016-04-26 | Mapr Technologies, Inc. | Map-reduce ready distributed file system |
| US8666939B2 (en) * | 2010-06-28 | 2014-03-04 | Sandisk Enterprise Ip Llc | Approaches for the replication of write sets |
| EP2421225A1 (en) | 2010-08-20 | 2012-02-22 | Alcatel Lucent | Processing method, proxy processing agent, system and method for filling a routing table of a DHT client node, router and dht client node |
| US8549142B2 (en) | 2011-03-28 | 2013-10-01 | Siemens Corporation | Replicated state machine utilizing view change protocol resilient to performance attacks |
| US9652469B2 (en) | 2011-06-04 | 2017-05-16 | Microsoft Technology Licensing, Llc | Clustered file service |
| US9020987B1 (en) | 2011-06-29 | 2015-04-28 | Emc Corporation | Managing updating of metadata of file systems |
| US8818951B1 (en) | 2011-12-29 | 2014-08-26 | Emc Corporation | Distributed file system having separate data and metadata and providing a consistent snapshot thereof |
| US9158843B1 (en) | 2012-03-30 | 2015-10-13 | Emc Corporation | Addressing mechanism for data at world wide scale |
| US9904689B2 (en) | 2012-07-13 | 2018-02-27 | Facebook, Inc. | Processing a file system operation in a distributed file system |
| US9369520B2 (en) * | 2012-08-19 | 2016-06-14 | Box, Inc. | Enhancement of upload and/or download performance based on client and/or server feedback information |
| US9582221B2 (en) | 2012-08-24 | 2017-02-28 | Vmware, Inc. | Virtualization-aware data locality in distributed data processing |
| US8943178B2 (en) | 2012-08-29 | 2015-01-27 | International Business Machines Corporation | Continuous operation during reconfiguration periods |
| US8769105B2 (en) | 2012-09-14 | 2014-07-01 | Peaxy, Inc. | Software-defined network attachable storage system and method |
| US20140344453A1 (en) * | 2012-12-13 | 2014-11-20 | Level 3 Communications, Llc | Automated learning of peering policies for popularity driven replication in content delivery framework |
| CN102999633A (zh) | 2012-12-18 | 2013-03-27 | 北京师范大学珠海分校 | 网络信息的云聚类提取方法 |
| US8977594B2 (en) * | 2012-12-21 | 2015-03-10 | Zetta Inc. | Systems and methods for state consistent replication |
| US9444899B2 (en) | 2012-12-26 | 2016-09-13 | Microsoft Technology Licensing, Llc | Use of internet information services logging to collect user information in an asynchronous manner |
| US9130943B1 (en) | 2013-03-11 | 2015-09-08 | Ca, Inc. | Managing communications between client applications and application resources of on-premises and cloud computing nodes |
| US9009215B2 (en) | 2013-03-15 | 2015-04-14 | Wandisco, Inc. | Methods, devices and systems for dynamically managing memberships in replicated state machines within a distributed computing environment |
| US20140344323A1 (en) | 2013-03-15 | 2014-11-20 | Reactor8 Inc. | State-based configuration management for distributed systems |
| CN103150394B (zh) * | 2013-03-25 | 2014-07-23 | 中国人民解放军国防科学技术大学 | 面向高性能计算的分布式文件系统元数据管理方法 |
| US9158472B2 (en) | 2013-06-25 | 2015-10-13 | Google Inc. | Hierarchical chunking of objects in a distributed storage system |
| CN103458044B (zh) | 2013-09-12 | 2017-01-04 | 北京航空航天大学 | 一种面向广域网环境下多存储集群的元数据共享管理方法 |
| CA2938768C (en) | 2014-03-31 | 2020-03-24 | Wandisco, Inc. | Geographically-distributed file system using coordinated namespace replication |
| US10585627B2 (en) * | 2016-03-24 | 2020-03-10 | Microsoft Technology Licensing, Llc | Distributed metadata management in a distributed storage system |
| US10503427B2 (en) * | 2017-03-10 | 2019-12-10 | Pure Storage, Inc. | Synchronously replicating datasets and other managed objects to cloud-based storage systems |
| US11216315B2 (en) * | 2018-02-21 | 2022-01-04 | Rubrik, Inc. | Distributed semaphore with a different keys to reduce contention for dynamic reservation of disk space |
-
2017
- 2017-03-13 US US15/457,837 patent/US11360942B2/en active Active
-
2018
- 2018-03-12 EP EP18767539.2A patent/EP3596619B8/en active Active
- 2018-03-12 ES ES18767539T patent/ES2969620T3/es active Active
- 2018-03-12 CN CN201880016079.3A patent/CN110447021B/zh active Active
- 2018-03-12 AU AU2018236167A patent/AU2018236167B2/en active Active
- 2018-03-12 JP JP2019545967A patent/JP7009488B2/ja active Active
- 2018-03-12 CA CA3055301A patent/CA3055301A1/en active Pending
- 2018-03-12 WO PCT/US2018/022062 patent/WO2018169886A1/en unknown
-
2022
- 2022-04-28 US US17/732,300 patent/US11704290B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20230012697A1 (en) | 2023-01-19 |
| US20180260409A1 (en) | 2018-09-13 |
| CN110447021B (zh) | 2024-03-01 |
| EP3596619A4 (en) | 2020-09-16 |
| EP3596619B8 (en) | 2023-12-27 |
| CA3055301A1 (en) | 2018-09-20 |
| JP7009488B2 (ja) | 2022-01-25 |
| CN110447021A (zh) | 2019-11-12 |
| EP3596619B1 (en) | 2023-11-22 |
| AU2018236167A1 (en) | 2019-08-15 |
| EP3596619A1 (en) | 2020-01-22 |
| JP2020514885A (ja) | 2020-05-21 |
| US11360942B2 (en) | 2022-06-14 |
| WO2018169886A1 (en) | 2018-09-20 |
| US11704290B2 (en) | 2023-07-18 |
| AU2018236167B2 (en) | 2022-03-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2969620T3 (es) | Métodos, dispositivos y sistemas para mantener la consistencia de metadatos y datos en todos los centros de datos | |
| US20230273904A1 (en) | Map-Reduce Ready Distributed File System | |
| US20190272254A1 (en) | Key-value store for map reduce system | |
| CN104281506B (zh) | 一种文件系统的数据维护方法及系统 | |
| US10248356B2 (en) | Using scratch extents to facilitate copying operations in an append-only storage system | |
| US9235479B1 (en) | Distributed file system having separate data and metadata and providing a consistent snapshot thereof | |
| US9213717B1 (en) | Managing concurrent I/OS in file systems | |
| US9460177B1 (en) | Managing updating of metadata of file systems | |
| CN110062925A (zh) | 用于云集成的快照元数据布置 | |
| EP3803619A1 (en) | Cloud storage distributed file system | |
| US10852996B2 (en) | System and method for provisioning slave storage including copying a master reference to slave storage and updating a slave reference | |
| US20160092491A1 (en) | Synchronizing copies of an extent in an append-only storage system | |
| EP3803618A1 (en) | Distributed transactions in cloud storage with hierarchical namespace | |
| US9720607B2 (en) | Append-only storage system supporting open and closed extents | |
| US9619322B2 (en) | Erasure-coding extents in an append-only storage system | |
| US20190132415A1 (en) | Active data management by flexible routing system and methods of an accelerated application-oriented middleware layer | |
| US10552371B1 (en) | Data storage system with transparent presentation of file attributes during file system migration | |
| Sinnamohideen et al. | A {Transparently-Scalable} Metadata Service for the Ursa Minor Storage System | |
| Cheon et al. | Exploiting multi-block atomic write in SQLite transaction | |
| US9967310B2 (en) | Using an RPC framework to facilitate out-of-band data transfers | |
| Suralkar et al. | Review of distributed file systems: Case studies | |
| Hatzieleftheriou et al. | Client-side journaling for durable shared storage | |
| Wang | Design and Implementation of a Distributed Snapshot File System. | |
| Mangal et al. | Erlang Distributed File System (eDFS) |