FR2884632A1 - Systemes distribues de calcul bases sur des informations d'etat distribuees et procedes et protocoles correspondants - Google Patents
Systemes distribues de calcul bases sur des informations d'etat distribuees et procedes et protocoles correspondants Download PDFInfo
- Publication number
- FR2884632A1 FR2884632A1 FR0602880A FR0602880A FR2884632A1 FR 2884632 A1 FR2884632 A1 FR 2884632A1 FR 0602880 A FR0602880 A FR 0602880A FR 0602880 A FR0602880 A FR 0602880A FR 2884632 A1 FR2884632 A1 FR 2884632A1
- Authority
- FR
- France
- Prior art keywords
- distributed
- state information
- locally
- data storage
- cached
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 190
- 238000004364 calculation method Methods 0.000 title claims description 7
- 238000013500 data storage Methods 0.000 claims abstract description 250
- 238000004891 communication Methods 0.000 claims abstract description 27
- 238000012545 processing Methods 0.000 claims description 108
- 238000005192 partition Methods 0.000 claims description 28
- 230000015654 memory Effects 0.000 claims description 23
- 230000001427 coherent effect Effects 0.000 claims description 8
- 230000003111 delayed effect Effects 0.000 claims description 5
- 230000000694 effects Effects 0.000 claims description 3
- 238000000638 solvent extraction Methods 0.000 abstract description 9
- 230000008569 process Effects 0.000 description 114
- 230000004044 response Effects 0.000 description 21
- 238000012986 modification Methods 0.000 description 10
- 230000004048 modification Effects 0.000 description 10
- 230000008859 change Effects 0.000 description 9
- 238000007726 management method Methods 0.000 description 9
- 230000008520 organization Effects 0.000 description 7
- 230000002085 persistent effect Effects 0.000 description 7
- 238000011084 recovery Methods 0.000 description 7
- 238000013461 design Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 230000001934 delay Effects 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 239000013307 optical fiber Substances 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000000875 corresponding effect Effects 0.000 description 1
- 238000013075 data extraction Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000004886 head movement Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 229910000207 majorite Inorganic materials 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000003908 quality control method Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 238000009827 uniform distribution Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
- G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
- G06F3/0637—Permissions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0653—Monitoring storage devices or systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
L'invention concerne des systèmes distribués de stockage de données (318) qui fournissent des interfaces à des ordinateurs hôtes qui accèdent aux systèmes distribués de stockage de données faisant généralement appel à des informations d'état utilisées pour l'exécution de commandes, par des systèmes composants de stockage de données. Elle concerne également des procédés destinés à partitionner des informations d'état à l'intérieur d'un système distribué de stockage de données ainsi que des protocoles et procédés de communication, destinés à gérer des informations d'état partagées parmi les systèmes composants de stockage de données à l'intérieur d'un système distribué de stockage de données.
Description
commandes que les ordinateurs hôtes distants peuvent émettre vers des
systèmes de stockage de données pour exécution. Ces commandes permettent à des ordinateurs hôtes de lire des données stockées à l'intérieur de systèmes de
stockage de données, d'écrire des données dans des systèmes de stockage de données, d'enquêter sur les capacités et les configurations de systèmes de stockage de données, et de configurer des systèmes de stockage de données. De la même façon, les dispositifs individuels de stockage 116 à 119 fournissent une interface stockage de données pour permettre au composant de traitement 112 d'un système de stockage de données de lire des données depuis, d'écrire des données dans, d'enquêter sur le contenu et la configuration de, et de configurer, des dispositifs individuels de stockage.
Dans un grand nombre de systèmes de calcul distribués actuellement disponibles, l'interface pour petits systèmes informatiques (SCSI selon les initiales du terme anglo-saxon Small Computer Systems Interface) est employée et en tant qu'interface stockage de données fournie à des ordinateurs hôtes distants par des systèmes de stockage de données, et en tant qu'interface stockage de données fournie par des dispositifs individuels de stockage au composant de traitement d'un système de stockage de données. Dans certains de ces systèmes, des commandes SCSI sont incorporées dans un protocole de réseau de plus haut niveau, tel que le canal fibre optique, pour l'échange de commandes et de réponses entre ordinateurs hôtes et systèmes de stockage de données, par l'intermédiaire d'un réseau de largeur de bande élevée. Des commandes et des réponses SCSI sont échangées entre le composant de traitement d'un dispositif de stockage de données et des dispositifs individuels de stockage de données, par l'intermédiaire de bus internes, tels que le bus SCSI 114, qui interconnectent les dispositifs individuels de stockage au composant de traitement. En général, bien que des ordinateurs hôtes distants multiples puissent accéder de manière concourante à un système particulier de stockage de données, tel que le système 106 de stockage de données à la figure 1, des commandes provenant de sources distantes multiples sont canalisées à travers un seul composant de traitement, tel que le composant de traitement 112, ce qui simplifie considérablement le traitement du grand nombre de différents problèmes d'accès concourant qui peuvent se présenter.
Des systèmes autonomes de stockage de données, complexes, à processeurs multiples, tels que des grappes de disques haut de gamme, sont récemment devenus disponibles commercialement. La figure 2 est un schéma fonctionnel d'un système de stockage de données complexe, à processeurs multiples, fourni à titre d'exemple. Le système 202 de stockage de données inclut deux différents contrôleurs de réseau 204, 205, interconnectés aux deux différents moyens de transmission 206, 207 à largeur de bande élevée, deux différents processeurs 208, 209, les deux interconnectés aux deux contrôleurs de réseau 204 et 205, et deux différentes mémoires 210 et 211, au moins l'une desquelles, 211, est partagée par les deux processeurs 208 et 209. Les deux processeurs 208 et 209 sont interconnectés à travers des bus internes multiples à un certain nombre de systèmes internes de stockage de données 214 à 219, chacun étant équivalent aux systèmes autonomes de stockage de données discutés ci-dessus en référence à la figure 1. Au système complexe de stockage de données, à processeurs multiples, montré à la figure 2, il peut être fait accès de manière concourante, par l'intermédiaire de moyens multiples de communication à largeur de bande élevée, par de nombreux ordinateurs hôtes distants. Dans ce système complexe de stockage de données, il existe un nombre considérablement plus grand de problèmes de concourance et de distribution de données que dans les systèmes de stockage de données plus simples, discutés ci- dessus en référence à la figure 1. Par exemple, à Ila différence du cas des systèmes plus simples de stockage de données, les systèmes plus complexes de stockage de données, montrés à la figure 2, peuvent coordonner un traitement concourant et simultané de commandes par les deux différents processeurs. Cependant, des techniques développées pour des systèmes d'ordinateurs à traitement parallèle peuvent être utilisées pour coordonner des activités de processeurs multiples, et pour partager et coordonner l'accès à des informations d'état communes, employées par les processeurs multiples, afin d'exécuter des commandes reçues depuis des ordinateurs hôtes distants. Par exemple, des informations d'état partagées et des files d'attente partagées de commandes peuvent être stockées dans la mémoire partagée 211, l'accès par les processeurs multiples aux informations d'état partagées et aux files d'attente partagées de commandes étant coordonné par des sémaphores matériels et différentes techniques de contrôle d'accès basées sur des sémaphores, des techniques de verrouillage et d'autres techniques développées pour traiter des problèmes survenant de conflits pour des ressources partagées par des entités de traitement multiples. Ainsi, même dans le cas du dispositif complexe de stockage de données à processeurs multiples de la figure 2, une mémoire partagée en commun ou d'autres composants partagés peuvent servir d'une espèce d'entonnoir à travers lequel une exécution concourante et simultanée de commandes peut être canalisée, fournissant un moyen destiné à simplifier des problèmes survenant de conflits pour des informations d'état, et d'un partage d'informations d'état, et pour synchroniser une exécution simultanée de tâches.
Comme les besoins pour des capacités de stockage toujours plus grandes, des largeurs de bande plus élevées et une tolérance aux pannes augmentée continuent à croître, poussés par des capacités de processeur et de mise en réseau toujours croissantes et par les capacités croissantes de, et les exigences croissantes sur des applications informatiques, de nouvelles stratégies destinées à concevoir, à construire et à gérer des systèmes de stockage de données complexes, distribués, hautement parallèles, sont apparus. Une stratégie et une conception particulièrement attrayantes pour des systèmes de stockage de données haut de gamme comprennent la distribution d'un système de stockage de données sur un grand nombre de systèmes, ou de noeuds, séparés, intercommunicants de stockage de données. La figure 3 illustre un exemple d'un système distribué de stockage de données. A la figure 3, trois différents systèmes de stockage de données 302 à 304, tels que les systèmes de stockage de données discutés ci-dessus en référence à la figure 2, sont interconnectés l'un à l'autre par une ou plusieurs interconnexions à deux différents moyens d'interconnexion à largeur de bande élevée 306 et 308. Les systèmes supplémentaires de stockage de données 310 à 313 sont interconnectés à deux des systèmes de stockage de données 302 et 304 mentionnés précédemment par trois moyens d'interconnexion 314 à 316 supplémentaires. Les systèmes de stockage de données 310 et 311 sont interconnectés l'un à l'autre, et au système de stockage de données 302, à travers un seul moyen d'interconnexion 314, tandis que le système de stockage de données 302 est interconnecté directement aux systèmes de stockage de données 310 à 313, à travers les moyens multiples d'interconnexion 314 et 315, et est interconnecté aux systèmes de stockage de données 303 et 304 à travers l'un ou les deux des moyens d'interconnexion à largeur de bande élevée 306 et 308. Tous les sept systèmes de stockage de données 302 à 304 et 310 à 313 forment ensemble un seul système distribué de stockage de données 318 qui fournit une interface stockage de données basée sur des commandes, adressable par le réseau, uniforrne, cohésive et se comportant bien, à un certain nombre d'ordinateurs hôtes distants qui communiquent entre eux et avec le système distribué de stockage de données 318 par l'intermédiaire de l'un des réseaux, ou des deux réseaux, d'intercommunication 306 et 308 haut de gamme.
Dans un grand nombre de cas, l'interface stockage de données fournie par un système distribué de stockage de données, tel que le système distribué de stockage de données 318 à la figure 3, doit apparaître et se comporter identiquement à une interface stockage de données fournie par des systèmes de stockage de données classiques, non distribués, tels que ceux décrits en référence aux figures 1 et 2, afin d'éviter des changements à des applications et à des systèmes d'exploitation d'ordinateurs hôtes distants qui accèdent au système distribué de stockage de données. Dans le cas d'un système distribué de stockage de données, un grand nombre de problèmes profonds par rapport au traitement concourant et simultané de commandes par les systèmes composants de stockage de données séparés, qui constituent ensemble le système distribué de stockage de données, sont généralement rencontrés. Par exemple, il peut être fait accès aux informations d'état qui décrivent l'état actuel du système distribué de stockage de données, par l'ensemble, ou une grande partie, des systèmes composants de stockage de données. Cependant, les informations d'état peuvent également être mises à jour pendant un traitement de commande, chaque mise à jour étant généralement effectuée par l'un des systèmes composants de stockage de données.
Si seulement une copie unique, centrale des informations d'état est maintenue à l'intérieur du système distribué de stockage de données, alors tous les systèmes composants de stockage de données sauf un emploient des communications de réseau afin d'accéder aux informations d'état. Puisqu'il peut être fait accès à une certaine portion des informations d'état pour l'ensemble, ou un grand sous-ensemble, des différents types de commandes exécutées par les systèmes de stockage de données, une copie unique, centrale des informations d'état peuvent conduire à des surdébits de communication extrêmement élevés et un temps d'attente inacceptable dans l'exécution de commandes, ainsi qu'à des défaillances en un point unique sérieuses qui peuvent défaire le fonctionnement à haute disponibilité du système distribué de stockage de données. Si, par contraste, les informations d'état sont répliquées et distribuées parmi les systèmes composants de stockage de données, il est alors nécessaire de prendre un grand soin pour mettre à jour toutes les copies répliquées des informations d'état, lorsqu'une seule copie quelconque dans les informations d'état est mise à jour par le traitement local d'une commande sur l'un des systèmes composants de stockage de données. La propagation de mises à jour est non triviale et peut conduire à des surdébits de communication élevés et à des temps d'attente importants dans le traitement de commandes. Un grand nombre d'autres problèmes abondent dans des systèmes de calcul complexes, distribués, tels que les systèmes distribués de stockage de données. Pour cette raison, les concepteurs, les fabricants, les détaillants, et les utilisateurs de systèmes distribués de stockage de données, et d'autres systèmes de calcul distribués, ont reconnu le besoin pour des systèmes distribués de calcul et des conceptions de systèmes distribués de calcul qui abordent les problèmes d'informations d'état distribuées sans y introduire des surdébits et une dégradation de la performance inacceptables.
RESUME DE L'INVENTION Différents modes de réalisation de la présente invention concernent des systèmes distribués de stockage de données qui fournissent des interfaces, ressemblant à des dispositifs non distribués de stockage de données, à des ordinateurs hôtes qui accèdent aux systèmes distribués de stockage de données. Les systèmes distribués de stockage de données font généralement appel à des informations d'état utilisées pour l'exécution de commandes, reçues depuis des ordinateurs hôtes, par des systèmes composants de stockage de données.
Des systèmes composants de stockage de données exécutant des commandes peuvent accéder à, et modifier, des informations d'état partagées parmi un grand nombre de systèmes, ou l'ensemble des systèmes, composants de stockage de données. Des procédés de modes de réalisation de la présente invention fournissent des procédés destinés à partitionner des informations d'état à l'intérieur d'un système distribué de stockage de données ainsi que des protocoles et procédés de communication destinés à gérer des informations d'état partagées parmi les systèmes composants de stockage de données à l'intérieur d'un système distribué de stockage de données. Dans certains modes de réalisation de la présente invention, des informations d'état sont partitionnées en un ou plusieurs éléments du groupe composé : (1) d'informations d'état locales lesquelles sont gérées, auxquelles il est fait accès, et lesquelles sont modifiées, séparément par chaque système composant de stockage de données; (2) d'informations d'état partagées qui sont mises en mémoire cache localement sur des systèmes composants de stockage de données pour un accès en lecture immédiat, c'est-à-dire rafraîchies périodiquement, mais qui sont maintenues globalement cohérentes parmi des systèmes composants de stockage de données en distribuant des opérations modificatrices d'état; et (3) d'informations d'état cohérentes en continu, partagées.
BREVE DESCRIPTION DES DESSINS
La figure 1 illustre un type d'environnement de calcul distribué, dans lequel des systèmes autonomes de stockage de données fournissent un stockage de données et une extraction de données à des ordinateurs hôtes distants.
La figure 2 est un schéma fonctionnel d'un système, fourni à titre d'exemple, de stockage de données complexe, à processeurs multiples.
La figure 3 illustre un exemple d'un système distribué de 35 stockage de données.
Les figures 4A à 4C illustrent des caractéristiques générales d'interfaces stockage de données classiques qui sont avantageusement incorporées dans des interfaces stockage de données, fournies par des systèmes distribués de stockage de données.
La figure 5 illustre une organisation possible de systèmes composants de stockage de données à l'intérieur d'un système distribué de stockage de données.
Les figures 6A à 6D illustrent des différences dans des fréquences d'accès d'informations d'état partagées qui peuvent être utilisées en tant que base pour partitionner des informations partagées à l'intérieur d'un système distribué de calcul dans différents modes de réalisation de la présente invention.
La figure 7 illustre une étape initiale, dans la gestion d'informations d'état partagées à l'intérieur d'environnements de calcul distribués, qui représente un mode de réalisation de la présente invention.
Les figures 8 à 14 illustrent le fonctionnement fondamental d'un registre distribué de stockage, utilisé pour mettre en oeuvre différents modes de réalisation de la présente invention.
La figure 15 montre les composants utilisés par un processus ou une entité de traitement P; qui met en oeuvre, ensemble avec un certain nombre d'autres processus et/ou entités de traitement Pi ;, un registre distribué de stockage, employé dans différents modes de réalisation de la présente invention.
La figure 16 illustre la détermination de la valeur actuelle d'un registre distribué de stockage au moyen d'un quorum, utilisé dans différents modes de réalisation de la présente invention.
La figure 17 montre des mises en oeuvre en pseudocode pour les gestionnaires de routines et les routines opérationnelles montrées schématiquement à la figure 18 et utilisées dans différents modes de réalisation de la présente invention.
La figure 18 montre un protocole de verrou distribué, basé sur un registre distribué de stockage, qui représente un mode de réalisation de la présente invention.
La figure 19 montre un protocole simple de verrou distribué mis en oeuvre par une routine Bail Ressource , utilisée dans différents modes de réalisation de la présente invention.
Les figures 20 à 27 illustrent un registre de stockage distribué mais mis en mémoire cache localement, de la même manière que le registre distribué de stockage, tel qu'illustré aux figures 8 à 14, employé dans différents modes de réalisation de la présente invention.
La figure 28 montre les procédures et les gestionnaires utilisés pour mettre en oeuvre un registre de stockage distribué, mais mis localement en mémoire cache, utilisé dans différents modes de réalisation de la présente invention, utilisant les conventions d'illustration employées précédemment à la figure 17.
La figure 29 montre des mises en oeuvre en pseudocode des procédures qui peuvent être ajoutées aux procédures et aux gestionnaires de registre distribué de stockage afin de mettre en oeuvre un registre de stockage distribué, mais mis en mémoire cache localement, utilisé dans différents modes de réalisation de la présente invention.
La figure 30 montre des mises en oeuvre en pseudocode des gestionnaires qui peuvent être ajoutés aux procédures et aux gestionnaires de registre distribué de stockage afin de mettre en oeuvre un registre de stockage distribué, mais mis en mémoire cache localement, utilisé dans différents modes de réalisation de la présente invention.
Les figures 31 et 32 illustrent, en utilisant des diagrammes de flux de commande, un procédé global qui représente un mode de réalisation de la présente invention.
DESCRIPTION DETAILLEE DE L'INVENTION
Des modes de réalisation de la présente invention concernent différents types de systèmes distribués, incluant des systèmes de stockage de données, qui présentent des interfaces basées sur commandes à différentes entités de calcul distantes, telles que des ordinateurs hôtes. Un défi dans la conception et la mise en oeuvre de tels systèmes distribués est de fournir une maintenance distribuée, un accès distribué et une modification distribuée d'informations d'état utilisées par des dispositifs et systèmes composants à l'intérieur des systèmes distribués qui exécutent des commandes reçues depuis des ordinateurs hôtes et d'autres entités de calcul. Des modes de réalisation de la présente invention incluent des procédés destinés à gérer, à accéder à, et à modifier, des informations d'état pour des systèmes distribués, ainsi que des systèmes distribués qui emploient ces procédés pour fournir de la maintenance, de l'accès et des modifications d'informations d'état de systèmes distribués.
Les figures 4A à 4C illustrent des caractéristiques générales d'interfaces stockage de données classiques qui sont avantageusement incorporées dans des interfaces stockage de données, fournies par des systèmes distribués de stockage de données. Comme le montre la figure 4A, un grand nombre de dispositifs et de systèmes de stockage de données, tels que des dispositifs de stockage de données qui fournissent une interface SCSI, sont visualisés de manière abstraite à travers l'interface comme une cible adressable 402 associée à une ou plusieurs unités logiques, telles que l'unité logique 0, 404, illustrée à la figure 4A. La cible 402 est associée à une ou à plusieurs adresse(s) de moyen de communication, permettant à un ordinateur hôte distant d'envoyer des commandes vers, et de recevoir des réponses depuis, le dispositif de stockage de données, par l'intermédiaire d'un ou de plusieurs moyens de communication, tels que le moyen de communication 406 à la figure 4A. Par exemple, un dispositif de stockage de données à grappe de disques peut avoir une ou plusieurs adresses de canal fibre optique vers laquelle (lesquelles) un ordinateur distant peut envoyer des commandes SCSI incorporées dans des trames de canal fibre optique et depuis laquelle (lesquelles) l'ordinateur distant peut recevoir des réponses, également incorporées à l'intérieur de trames de canal fibre optique. Des données stockées à l'intérieur d'un dispositif de stockage de données sont généralement stockées dans un ou plusieurs blocs adressés séquentiellement d'une ou de plusieurs unités logiques. Chaque unité logique est associée à un numéro d'unité logique ( LUN selon les initiales du terme anglo-saxon Logical Unit Number) ou à un autre type d'adresse ou de référence par laquelle l'unité logique peut être identifiée.
Une unité logique, telle que l'unité logique 408 à la figure 4A, peut être visualisée à travers l'interface stockage de données comme une séquence de blocs de données, chaque bloc de données à la figure 4A étant représenté comme un rectangle délinéé par des lignes tiretées, tel que le bloc de données 410.
Les blocs de données sont normalement encore divisés en mots machine et/ou octets de longueur de bits fixe.
Tandis que l'abstraction cible/unité logique fournie par des interfaces ordinaires pour stockage de données est généralement simple et logiquement organisée, la mise en oeuvre physique réelle peut être tout à fait complexe. Des unités logiques peuvent couvrir de multiples dispositifs physiques de stockage de données, ou peuvent ne couvrir que de petites portions d'un dispositif de stockage unique de données. La mise en ordre physique de blocs de données, et de mots machine et d'octets à l'intérieur de blocs de données, sur des supports physiques de dispositif de stockage de données peut ne pas être séquentielle, mais est organisée de façons complexes pour tirer avantage de différents types de rendements connexes à la configuration et à la conception de dispositifs physiques. Par exemple, dans des lecteurs de disques magnétiques à plateaux multiples, des blocs de données d'une unité logique unique peuvent être dispersés sur des plateaux multiples et sur des pistes multiples à l'intérieur de chacun des plateaux multiples, afin de minimiser les temps d'attente associés à des mouvements de tête et à la rotation des plateaux.
Les commandes fournies par une interface stockage de données peuvent être, dans une certaine mesure, partitionnées logiquement en deux ensembles. Le premier ensemble de commandes, illustré à la figure 4B, peut être considéré comme étant adressé à un dispositif de stockage de données en général et exécutable au niveau de cible à l'intérieur du dispositif de stockage de données. Un format partiel, fourni à titre d'exemple, pour une commande provenant de ce premier ensemble de commandes 402 est montré dans le coin en bas à droite de la figure 4B. Ce type de commande requiert au minimum un champ 404 d'adresse cible qui dirige la commande vers un dispositif cible particulier, et un champ 406 d'identifiant de commande qui contient un identifiant numérique pour la commande. La commande contiendra de manière optionnelle, mais générale, un ou plusieurs champs de données 408 supplémentaires. Une commande de ce premier ensemble de commandes peut être complètement exécutée à l'intérieur du composant de traitement d'un dispositif de stockage de données, en référence à des informations d'état stockées en mémoire, sur un dispositif composant de stockage, ou et à l'intérieur de la mémoire, et sur un dispositif composant de stockage. Des exemples de commandes dans ce premier ensemble de commandes incluent des commandes qui sollicitent des informations globales concernant un système de stockage de données, sollicitent des informations concernant des paramètres actuels de configuration, qui modifient des paramètres de configuration actuels et qui dirigent différentes opérations globales, telles qu'une remise à l'état initial. Une interface stockage de données peut spécifier que certaines de ces commandes soient exécutables, que le dispositif de stockage de données soit prêt ou non à exécuter des commandes d'extraction de données ou de stockage de données.
Le deuxième ensemble de commandes est illustré à la figure 4C. Un format 420, fourni à titre d'exemple, pour des commandes du deuxième ensemble est montré dans le coin en bas à droite de la figure 4C. En plus des champs décrits pour le format de commande montré à la figure 4B, des commandes du deuxième ensemble incluent généralement un champ LUN 422, ou un champ équivalent, qui spécifie l'unité logique du système de stockage de données vers laquelle la commande est dirigée. Des commandes, fournies à titre d'exemple, provenant du deuxième ensemble de commandes incluent les commandes LECTURE et ECRITURE destinées à accéder à, et à stocker, des données. Comme le montre la figure 4C, les commandes de ce deuxième ensemble de commandes sont généralement exécutées par le composant de traitement du système de stockage de données, faisant appel à des informations d'état, ainsi que par un ou plusieurs dispositifs composants de stockage de données sur lesquels réside physiquement l'unité logique à laquelle la commande est adressée. Dans des systèmes modernes de stockage de données, le traitement d'une commande du deuxième type de commandes peut souvent être effectué par le composant de traitement du système de stockage de données, en référence à des données d'unité logique mises en cache dans la mémoire, sans accès physique des données d'unité logique sur le ou les dispositif(s) physique(s) de stockage de données qui contien(nen)t une unité logique. Néanmoins, des commandes du deuxième ensemble de commandes sont exécutées en utilisant et des informations d'état globales et des informations spécifiques, spécifiques à une unité logique. Tout ensemble de commandes particulier de toute interface stockage de données particulière peut inclure des types supplémentaires de commandes, ou des commandes non facilement classifiées selon le schéma discuté ci-dessus en référence aux figures 4A à 4C, mais le schéma simple de classification de commandes est utile et applicable, en général, pour concevoir des 5 systèmes distribués et des protocoles de communication pour des systèmes distribués.
La figure 5 illustre une organisation possible de systèmes composants de stockage de données à l'intérieur d'un système distribué de stockage de données. Comme discuté ci-dessous, cette organisation n'est pas conçue avec l'intention qu'elle reflète des organisations typiques basées sur le protocole SCSI, ou un autre protocole particulier ou une autre interface particulière pour stockage de données. Dans cette organisation, des commandes peuvent être dirigées vers le système distribué de stockage de données à travers l'un quelconque des quatre systèmes composants de stockage de données 502 à 505 qui constituent ensemble la portion cible distribuée 506 du système distribué de stockage de données. Chacun des systèmes composants cibles de stockage de données 502 à 505 peut localement prendre en charge une ou plusieurs unités logiques fournies par le système distribué de stockage de données à travers une interface stockage de données. Le système composant de stockage de données 502 est de surcroît directement interconnecté à deux systèmes composants de stockage de données 508 et 510, chacun desquels met en oeuvre une ou plusieurs unités logiques différentes. Le système composant de stockage de données 504 est directement interconnecté aux systèmes composants de stockage de données 512 et 514 qui ensemble mettent en oeuvre une souscible qui s'interface à quatre systèmes de stockage de données 516 à 519supplémentaires et qui met chacun en oeuvre une ou plusieurs unités logiques. Dans l'organisation montrée à la figure 5, chaque unité logique fournie par le système distribué de stockage de données est complètement contenue à l'intérieur d'un système composant de stockage de données unique. Dans ce système distribué de stockage de données, il serait raisonnable de s'attendre à ce que les systèmes composants de stockage de données 502 à 505, qui constituent ensemble le composant cible 506 du système distribué de stockage de données, partagent les informations d'état 522 à 525 couvrant l'ensemble de la cible, partagées, pour permettre à chacun des systèmes composants cibles de stockage de données de recevoir et d'exécuter des commandes adressées au système distribué de stockage de données. De surcroît, chacun des systèmes composants cibles de stockage de données 502 à 505 peut également maintenir des informations d'état 526 à 529 locales séparées, discrètes, concernant les unités logiques particulières mises en oeuvre localement par les systèmes composants de stockage de données, ainsi que d'autres informations d'état locales. De la même façon, les systèmes composants de stockage de données 512 à 514 qui constituent ensemble une sous-cible à l'intérieur du système distribué de stockage de données peuvent chacun maintenir des informations d'état sous-cible 530 et 531 partagées ainsi que des informations d'état locales 532 et 534, particulières à chacun des dispositifs composants de stockage de données. D'un autre côté, les systèmes composants de stockage de données 508, 510 et 516 à 519 peuvent utiliser uniquement des informations d'état locales, parce que ces systèmes composants de stockage de données ne reçoivent pas des commandes directement depuis des ordinateurs hôtes distants, uniquement des requêtes internes envoyées depuis des systèmes composants distribués, de cible ou de sous-cible, pour des données stockées dans des unités logiques mises en oeuvre localement par les systèmes composants de stockage de données. Le système composant de stockage de données 504 peut en outre utiliser les informations d'état 536 de sous-cible, une portion desquelles peut être partagée avec les systèmes composants de stockage de données 512 et 514. Ainsi, dans un système distribué donné de stockage de données, tel que le système distribué de stockage de données montré en schéma à la figure 5, chaque système composant de stockage de données peut maintenir certaines informations d'état locales particulières à ce système composant de stockage de données, ainsi qu'un ou plusieurs types d'informations d'état partagées, utilisées par différents sous-ensembles des dispositifs composants de stockage de données.
Dans un système distribué de stockage de données proposé, plus simple, chaque système composant de stockage de données est un pair équivalent par rapport à tous les autres systèmes composants de stockage de données, et par conséquent, chaque système composant de stockage de données peut maintenir et des informations d'état locales, et des informations d'état partagées globalement. II est à noter que l'organisation décrite en référence à la figure 5 est hypothétique et n'est pas conçue avec l'intention qu'elle reflète une organisation qui pourrait typiquement être adoptée lorsque l'un quelconque du grand nombre de protocoles particuliers de stockage de données est employé. Par exemple, dans des systèmes distribués typiques basé sur le SCSI, le volume d'informations d'état modifiables, et locales et partagées, est contenu au niveau des unités logiques, peu d'informations d'état étant contenus au niveau de cible et de sous-cible.
Une autre manière de partitionner des informations d'état à l'intérieur d'un système distribué de stockage de données, ou d'un autre système de calcul distribué, est de le faire par la fréquence d'accès et/ou de modification. Ce type de partitionnement est pertinent à toutes informations d'état partagées ou partagées globalement, maintenues à l'intérieur du système distribué de calcul. Les figures 6A à 6D illustrent des différences dans des fréquences d'accès d'informations d'état partagées qui peuvent être utilisées en tant que base pour partitionner des informations partagées à l'intérieur d'un système de calcul distribué dans différents modes de réalisation de la présente invention. A la figure 6A, des composants, représentés de manière abstraite, d'un système composant de stockage de données à l'intérieur d'un système distribué de stockage de données, sont montrés. Le système composant de stockage de données 602 inclut une file d'attente 604 de commandes sur laquelle des commandes reçues sont mises en file d'attente et à partir de laquelle des commandes sont sorties de la file d'attente et exécutées. Le système composant de stockage de données inclut en outre les composants logiques 606 à 608, chacun étant dédié au traitement d'un type de commande, et chacun étant associé aux informations d'état 610 à 612 particulières à l'exécution de la commande. Le système composant de stockage de données inclut en outre un composant logique 614 dédié au traitement frontal de l'une quelconque des types de commandes exécutées par les composants 607 et 608 de logique de commande, ainsi que les informations d'état 616 associées à ce dernier composant logique 614. Pour terminer, le système composant de stockage de données inclut des informations d'état 618 générales auxquelles il peut être fait référence pour l'exécution de tous, ou presque tous, les différents types de commande. En général, les informations d'état sont stockées en mémoire à accès aléatoire, sur un support de stockage en masse non volatile, ou avec une combinaison de mémoire à accès aléatoire et de stockage en masse. Les composants logiques sont généralement des routines logicielles exécutées par un composant de traitement mais peuvent également être complètement ou partiellement mis en oeuvre dans un microprogramme ou dans des circuits logiques. Une file d'attente de commandes est généralement stockée à l'intérieur d'une mémoire à accès aléatoire et maintenue par un composant de traitement, et il y est fait accès par un composant de traitement sous contrôle de programmes logiciels. Cependant, les composants logiques et physiques détaillés d'un système composant de stockage de données ne sont pas pertinents au partitionnement d'informations d'état par la fréquence d'accès, actuellement discuté en référence aux figures 6A à 6C.
Certains types de commandes, telles que des commandes qui sollicitent des informations générales concernant un système distribué de stockage de données, peuvent être exécutées par une logique générale d'exécution de commande ou par un programme n'utilisant que des informations d'état générales 618. La figure 6B illustre le traitement de telles commandes. Ces commandes d'informations générales ou de configuration au niveau de la cible peuvent être mises en file d'attente 620 et par la suite sorties de la file d'attente 622 et traitées par des routines générales de traitement de commande, utilisant 624 uniquement les informations d'état 618 générales, partagées parmi tous les systèmes composants de stockage de données qui reçoivent directement des commandes depuis des ordinateurs hôtes distants et qui font par conséquent partie d'une cible distribuée à l'intérieur du système distribué de stockage de données. L'exécution d'autres types de commandes peut comprendre une référence et aux informations d'état général, et aux informations d'état particulières à la commande. La figure 6C illustre le traitement d'une commande comprenant l'accès à des informations d'état spécifiques à une commande. La commande est mise en file d'attente 626 et par la suite sortie de la file d'attente et traitée partiellement en référence 628 aux informations d'état générales 618, ensuite traitée par la logique 606, spécifique à une commande, en référence aux informations d'état 610 spécifiques à une commande, de manière à renvoyer une réponse 630 vers l'ordinateur hôte qui avait initialement envoyé la commande. Pour terminer, comme le montre la figure 6D, le traitement d'un type supplémentaire de commande peut comprendre l'accès à des informations d'état générales, aux informations d'état 616 associées à un ensemble de commandes auxquelles la commande appartient, et aux informations d'état 612 associées à la commande particulière. En supposant une distribution relativement uniforme de types de commande dans les commandes reçues par un dispositif composant de stockage de données, il serait raisonnable de s'attendre à ce qu'il soit, de loin, fait accès le plus fréquemment aux informations d'état 618 générales, et qu'il soit fait accès le moins fréquemment à des informations spécifiques à une commande, et qu'il soit fait accès avec une fréquence intermédiaire aux informations d'état de niveau intermédiaire associées à des commandes multiples, telles que les informations d'état 616 à la figure 6A.
Une base supplémentaire pour la sélection de politiques de gestion concernant les informations d'état partagées est la fréquence à laquelle des informations d'état particulières sont modifiées pendant le fonctionnement d'un système de calcul distribué. Par exemple, le traitement de la commande discutée ci-dessus en référence à la figure 6B peut comprendre simplement l'accès à des informations d'état générales, sans modification des informations d'état, ou d'un autre côté, il peut comprendre et l'accès aux informations d'état générales, et leur modification. Les informations d'états partagées qui ne sont jamais modifiées, ou peu fréquemment modifiées, peuvent être mises en mémoire cache localement avec plus d'efficacité que les informations d'état partagées qui sont fréquemment modifiées, nécessitant des mises à jour distribuées fréquentes.
Dans les systèmes non distribués, la maintenance d'informations d'état partagées est gérée de manière relativement simple en employant une mémoire physique, partagée et des techniques bien connues, destinées à résoudre des questions de conflits qui proviennent d'un accès concourant à des informations d'état partagées. Cependant, dans un système distribué, le stockage central d'informations d'état partagées introduit des goulots d'étranglement de communication sévères et des défaillances en un point unique dangereuses. Au lieu de cela, des informations partagées sont généralement distribuées parmi des systèmes composants discrets de stockage de données. Mais la distribution d'informations d'état partagées introduit des problèmes de cohérence. Lorsqu'un système composant de stockage de données reçoit une commande qui dirige une modification d'informations d'état partagées, la modification est propagée vers tous les systèmes composants de stockage de données qui maintiennent des copies des informations d'état partagées.
En même temps, l'interface stockage de données présentée par un système distribué de stockage de données peut spécifier que le système distribué de stockage de données présente, à des ordinateurs hôtes distants faisant accès, un état de système qui est cohérent et ordonné temporellement de manière prévisible. Un grand nombre d'interfaces stockage de données spécifient que deux ordinateurs hôtes distants différents faisant accès de manière concourante ne doivent jamais observer un état incohérent d'un système distribué de stockage de données à un moment quelconque. Par conséquent, si une commande est exécutée sur un premier système composant de stockage de données qui a pour résultat une modification d'informations d'état partagées, le traitement de commandes qui accèdent à, ou modifient, ces dernières informations d'état partagées est retardé sur tous les autres systèmes composants de stockage de données jusqu'à ce que la modification effectuée par le premier système composant de stockage de données soit propagée à tous les autres systèmes composants de stockage de données. Ainsi, la mise à jour d'informations d'état distribuées, partagées, peut comprendre des surdébits de communication considérables ainsi que des temps d'attente d'exécution de commande augmentés de manière remarquable.
Les problèmes d'informations d'état partagées, distribuées, à l'intérieur de systèmes distribués de stockage de données, et d'autres systèmes de calcul distribués, se présentent dans un très grand nombre de différentes manières dans des programmes de contrôle pour des systèmes composants de stockage de données, incluant dans la mise en séquence et la synchronisation d'exécution de commande, la communication entre composants et la conception d'interfaces stockage de données. Des stratégies de gestion pour des informations d'état partagées, distribuées peuvent potentiellement avoir une influence sur les vitesses de traitement du système global, les largeurs de bande d'exécution de commande, l'intégrité, et la capacité de stockage de données. Différentes solutions ont été proposées pour gérer le problème d'informations d'état partagées à l'intérieur de systèmes distribués de calcul, la plupart des solutions comprenant soit des techniques complexes et potentiellement fragiles basées sur des rnessages de battements de coeur périodiques, des protocoles de verrouillage et d'autres dispositifs de tel genre, soit comprenant des surdébits de communication et de traitement élevés qui peuvent avoir une influence sévère sur la performance globale de systèmes distribués de stockage de données. Des concepteurs, des fabricants, des vendeurs de composants et des utilisateurs de systèmes distribués de stockage de données ont tous reconnu le besoin pour des techniques meilleures, générales pour gérer des informations d'état partagées, distribuées, à l'intérieur de systèmes distribués de stockage de données, et d'autres systèmes distribués de calcul.
La figure 7 illustre une étape initiale, dans la gestion d'informations d'état partagées à l'intérieur d'environnements de calcul distribués, qui représente un mode de réalisation de la présente invention. Dans cette étape initiale, les informations d'état pour le système distribué de stockage de données, ou un autre système distribué de calcul, sont partitionnées en trois types d'informations d'état: (1) des informations d'état 702 locales qui sont particulières à, et qui peuvent être complètement gérées par, un système composant unique de stockage de données; (2) des informations d'état 704 distribuées et partagées, mais mises en mémoire cache localement, par la suite appelée des informations d'état partagées, mises en mémoire cache , qui sont partagées entre des dispositifs composants multiples de stockage de données mais qui peuvent être mises en mémoire cache localement dans des systèmes composants individuels de stockage de données pour un accès en lecture immédiat, qui sont mises à jour à une fréquence de rafraîchissement sélectionnée, et qui sont cohérentes globalement parmi des systèmes composants de stockage de données en raison d'un accès en écriture complètement distribué ; et (3) des informations d'état 706 distribuées, partagées, par la suite appelées simplement des informations d'état partagées , qui sont maintenues cohérentes en continu parmi les systèmes composants de stockage de données qui partagent les informations d'état. En général, des informations d'état partagées, mises en mémoire cache, sont le plus utiles pour des informations d'état qui sont lues fréquemment mais modifiées peu fréquemment. Dans le cas de systèmes distribués de stockage de données complexes ayant des hiérarchies internes d'informations d'état distribuées, partagées, il peut exister des paires supplémentaires de partitions d'informations d'état et d'informations d'état partagées et mises en mémoire cache, comme l'indique la figure 7 par les partitions 708 supplémentaires, optionnelles. Cependant, à des fins de description de modes de réalisation de la présente invention, la discussion suivante suppose que les informations d'état à l'intérieur d'un environnement de calcul distribué soient partitionnées en informations d'état partagées 706, informations d'état 704 partagées, mises en mémoire cache, et informations d'état locales 702, aucune attention spécifique n'état prêtée aux partitions multiples d'un type particulier quelconque, parce que les procédés de gestion pour chaque type sont appliqués de manière équivalente à une ou à plusieurs partitions de ce dernier type, les différences se situant uniquement dans les valeurs de paramètres constants, tels que la fréquence de rafraîchissement, et dans le nombre et l'identité de systèmes composants de stockage de données qui partagent une partition particulière.
Ayant partitionné les informations d'état contenues dans un système distribué de stockage de données en trois partitions, ou catégories, générales discutées ci-dessus par rapport à la figure 7, une tâche suivante consiste à affecter chaque unité d'informations d'état, que ce soit un octet, un mot, un champ de mots, une structure de données complexe, ou une unité d'information plus grande, à l'une des trois partitions. Des informations d'état qui ne sont utilisées que par un système composant de stockage de données d'un système distribué de stockage de données, et qui sont gérées uniquement par ce dernier système composant de stockage de données, peuvent être affectées de manière simple à la partition 702 d'informations d'état locales pour ce dernier système composant de stockage de données. II existe peu, s'il en existe du tout, de questions de distribution et de partage concernant de telles informations, et par conséquent, les informations d'état locales peuvent être gérées par un procédé quelconque d'un grand nombre de différents procédés alternatifs, bien connus, afin de maintenir les informations d'état locales dans un état cohérent, en conformité avec les exigences imposées par une interface stockage de données fournie par le système distribué de stockage de données et les besoins du programme de contrôle de système composant de stockage de données: en affectant autant d'informations d'état que possible à la partition d'informations d'état locales de différents systèmes composants de stockage de données, les surdébits inévitables associés aux informations d'état distribuées, partagées, dans un système distribué de stockage de données peuvent être diminués de façon significative.
Les informations d'état restantes, suivant l'affectation des informations d'état locales aux partitions d'informations d'état locales des systèmes composants de stockage de données, se situent dans la classe générale d'informations d'état distribuées, partagées. Les informations d'état distribuées, partagées sont ensuite partitionnées parmi la partition 706 d'informations d'état partagées et la partition 704 d'informations d'état partagées, mises en mémoire cache. Ce partitionnement d'informations d'état distribuées, partagées, peut varier d'un système à l'autre et d'une interface système à l'autre, en fonction des capacités de, et les exigences imposées sur, les composants physiques logiques d'un système distribué de stockage de données. En général, des économies en surdébits dues à la gestion d'informations d'état distribuées, partagées sont obtenues lorsque des informations d'état auxquelles il est fréquemment fait accès, mais lesquelles sont peu fréquemment modifiées, sont affectées à la partition 704 d'informations d'état partagées, mises en mémoire cache. Un accès fréquent à une mémoire cache locale est de loin plus efficace qu'un accès fréquent à des données distribuées à travers un moyen de communication.
Lorsque des informations mises en mémoire cache localement sont modifiées fréquemment, des procédures de mise à jour d'informations d'état distribuées sont invoquées fréquemment, augmentant potentiellement les surdébits associés à des informations état partagées, mises en mémoire cache, au-delà de ce qui est le cas pour des informations d'état partagées qui sont stockées et gérées de manière cohérente en continu. Des informations partagées, fréquemment modifiées et/ou auxquelles il est fait accès peu fréquemment, peuvent par conséquent être affectées à la partition 706 d'informations d'état partagées. Dans certains cas, toutes les informations d'état partagées peuvent être affectées à la partition 704 d'informations d'état partagées, mises en mémoire cache, ou de façon moins ordinaire, à la partition 706 d'informations d'état partagées. Par exemple, si les capacités de communication et de traitement d'un système distribué de stockage de données sont étendues, les surdébits associés à la gestion cohérente en continu et distribuée des informations d'état partagées peuvent ne pas iinfluencer de manière significative la performance globale de système, et par conséquent, la gestion distribuée d'informations d'état distribuées, partagées, par un procédé unique peut devenir attrayant du point de vue de la conception et du contrôle de qualité. A titre d'un autre exemple, l'interface stockage de données particulière pour laquelle un système distribué de stockage de données est conçu peut ne pas employer une grande quantité d'informations d'état partagées qui sont fréquemment modifiées et qui sont cohérente en continu, et par conséquent, toutes les informations d'état partagées peuvent être raisonnablement affectées à la partition d'informations d'état partagées, mises en mémoire cache, sans influence significative sur la performance globale du système distribué de stockage de données. Dans le cas général, dans lequel des informations d'état partagées sont affectées aux partitions et d'informations d'état partagées et d'informations d'état partagées, mises en mémoire cache, les rapports entre les quantités d'informations d'état stockées dans les différentes partitions peut varier considérablement d'un système distribué de stockage de données à l'autre, et même à différents moments pendant le fonctionnement d'un système distribué donné de stockage de données. Le rapport peut être déterminé de façon empirique par une analyse de la performance, ou déterminé analytiquement par une considération des fréquences de mises à jour, des surdébits de communication attendue, et d'autres facteurs de tel genre.
Ayant partitionné les informations d'état d'un système distribué de stockage de données entre les trois partitions générales discutées cidessus, en référence à la figure 7, des procédés destinés à gérer chacune des deux différentes partitions, auxquelles les informations d'état partagées sont affectées, sont employés. Des modes de réalisation de la présente invention emploient un premier procédé et un premier protocole, décrits par la suite, destinés à gérer des informations d'état partagées affectées à la partition d'informations d'état partagées, et emploient un deuxième procédé et un deuxième protocole, destinés à gérer des informations d'état affectées à la partition d'informations d'état partagées, mises en mémoire cache, décrits par la suite comme une amélioration et une élaboration du premier procédé et du premier protocole.
Un procédé destiné à gérer des informations d'état partagées qui sont maintenues dans un état cohérent en continu, et un protocole sur lequel le procédé est basé, est décrit ci-dessous en termes d'un registre distribué de stockage. Un registre de stockage distribué peut être considéré, à des fins de la description de la présente invention, comme étant une unité d'informations d'état partagées. Chaque unité d'informations d'état partagées peut être gérée de manière indépendante par le procédé et le produit décrits ci-dessous, peut être gérée en utilisant différents types de structures de contrôle stockées dans des registres distribués de stockage destinés à gérer des collections d'unités d'informations d'état partagées, ou peut être géré dans des collections plus grandes d'unités d'informations d'état partagées.
Les figures 8 à 14 illustrent le fonctionnement fondamental d'un registre distribué de stockage utilisé pour mettre en oeuvre différents modes de réalisation de la présente invention. Comme le montre la figure 8, le registre distribué de stockage 802 est de préférence un registre abstrait, ou virtuel, plutôt qu'un registre physique mis en oeuvre dans le matériel d'un dispositif électronique particulier. Chaque processus s'exécutant sur un processeur ou système d'ordinateur 804 à 808 emploie un petit nombre de valeurs stockées en mémoire dynamique, et optionnellement sauvegardées en mémoire non volatile, ensemble avec un petit nombre de routines connexes au registre distribué de stockage, pour mettre en oeuvre collectivement le registre distribué de stockage 802. A tout le moins, un ensemble de valeurs et de routines stockées est associé à chaque entité de traitement qui accède au registre de stockage distribué. Dans certaines mises en oeuvre, chaque processus s'exécutant sur un processeur physique ou un système physique à processeurs multiples peut gérer ses propres valeurs et routines stockées et, dans d'autres mises en oeuvre, des processus s'exécutant sur un processeur particulier ou un système à processeurs multiples particulier peuvent partager les valeurs et routines stockées, pourvu que le partage soit coordonné localement afin d'empêcher des problèmes d'accès concourant par des processus multiples s'exécutant sur le processeur.
A la figure 8, chaque système d'ordinateur maintient une valeur locale 810 à 804 pour le registre distribué de stockage. En général, les valeurs locales stockées par Iles différents systèmes d'ordinateur sans normalement identiques, et égales à la valeur du registre distribué de stockage 802. Cependant, les valeurs locales peuvent occasionnellement ne pas être identiques, comme dans l'exemple montré à la figure 8, dans quel cas, si une majorité des systèmes d'ordinateur maintiennent actuelle une valeur unique stockée localement, la valeur du registre de stockage distribué est alors la valeur détenue par la majorité.
Un registre de stockage distribué fournit deux fonctions fondamentales de haut niveau à un certain nombre de processus intercommunicants qui mettent collectivement en oeuvre le registre distribué de stockage. Comme le montre la figure 9, un processus peut diriger une requête LECTURE 902 vers le registre distribué de stockage 902. Si le registre distribué de stockage détient actuellement une valeur valide, comme le montre la figure 10 par la valeur B à l'intérieur du registre distribué de stockage 802, la valeur actuelle, valide est renvoyée 1002 ou processus de requête. Cependant, comme le montre la figure Il, si le registre distribué de stockage 802 ne contient pas actuellement une valeur valide, alors la valeur NUL 1102 est renvoyée au processus de requête. La valeur NUL est une valeur qui ne peut pas être une valeur valide stockée à l'intérieur du registre de stockage distribué.
Un processus peut également écrire une valeur dans le registre distribué de stockage. A la figure 12, un processus dirige un message ECRITURE 1202 vers le registre distribué de stockage 802, le message ECRITURE 1202 incluant une nouvelle valeur X à écrire dans le registre distribué de stockage 802. Si la valeur transmise vers le registre de stockagedistribué écrase avec succès une valeur quelconque actuellement stockée dans le registre de stockage distribué, comme le montre la figure 13, alors une valeur booléenne VRAI est renvoyée 1302 vers le processus qui avait dirigé la requête ECRITURE vers le registre distribué de stockage. Autrement, comme le montre la figure 14, la requête ECRITURE échoue, et une valeur booléenne FAUX est renvoyée 1402 vers le processus qui avait dirigé la requête ECRITURE vers le registre distribué de stockage, la valeur stockée dans le registre distribué de stockage étant inchangée par la requête ECRITURE. Dans certaines mises en oeuvre, le registre de stockage distribué renvoie les valeurs binaires OK et NOK , équivalentes aux valeurs booléennes VRAI et FAUX .
La figure 15 montre les composants utilisés par un processus ou une entité de traitement P; qui met en oeuvre, ensemble avec un certain nombre d'autres processus et/ou entités de traitement P1 ;, un registre distribué de stockage, employé dans différents modes de réalisation de la présente invention. Un processeur ou une entité de traitement utilisé trois primitives de bas niveau: un mécanisme de temporisateur 1502, un identifiant unique 1504, et une horloge 1506. Le processeur ou l'entité de traitement P; utilise un mécanisme 1502 de temporisateur local qui permet à P; de régler un temporisateur pour une période de temps spécifiée, et ensuite d'attendre que ce dernier temporisateur expire, P; étant notifié à l'expiration du temporisateur afin de continuer une certaine opération. Un processus peut régler un temporisateur et continuer l'exécution, vérifiant ou interrogeant le temporisateur concernant l'expiration, ou un processus peut régler un temporisateur, suspendre l'exécution, et être réveillé lorsque le temporisateur expire. Dans un cas ou l'autre, le temporisateur permet au processus de suspendre logiquement une opération, et de reprendre ultérieurement l'opération après une période de temps spécifiée, ou d'effectuer une opération pour une période de temps spécifiée, jusqu'à ce que le temporisateur expire. Le processus ou l'entité de traitement P; a également un identifiant de processus local ( PID selon les initiales du terme anglo-saxon Process ID) 1 504 stocké de manière fiable et extractible de manière fiable. Chaque processeur ou entité de traitement a un PID local qui est unique par rapport à tous les autres processus et/ou à toutes les autres entités de traitement qui ensemble mettent en oeuvre le registre distribué de stockage. Pour terminer, une entité de traitement de processeur P; a une horloge 1506 de temps réel qui est approximativement coordonné avec un certain temps absolu. Les horloges de temps réel de tous les processus, et/ou de toutes les entités de traitement, qui mettent collectivement en oeuvre un registre distribué de stockage n'ont pas besoin d'être exactement synchronisées, mais devraient refléter raisonnablement une certaine conception partagée de temps absolu. La plupart des ordinateurs, incluant les ordinateurs personnels, incluent une horloge système alimentée par batterie, qui reflète une valeur de temps actuel, universel. A toutes fins pratiques, incluant la mise en oeuvre d'un registre distribué de stockage, ces horloges de systèmes n'ont pas besoin d'être exactement synchronisées mais doivent seulement refléter approximativement un certain temps universel, actuel.
Chaque processeur ou entité de traitement P; inclut une mémoire volatile 1508 et, dans certains modes de réalisation, une mémoire non volatile 1510. La mémoire volatile 1508 est utilisée pour stocker des instructions pour exécution et les valeurs locales d'un certain nombre de variables utilisées pour le protocole de registre distribué de stockage. La mémoire non volatile 1510 est utilisée pour stocker de manière persistante le certain nombre de variables utilisées, dans certains modes de réalisation, pour le protocole de registre distribué de stockage. Un stockage persistant de valeurs de variable fournit une reprise relativement simple de la participation d'un processus dans la mise en oeuvre collective d'un registre distribué de stockage à la suite d'un écrasement ou d'une interruption de communication. Cependant, un stockage persistant n'est pas requis. Au lieu de cela, tant que les valeurs de variable stockées en mémoire dynamique, dans des modes de réalisation de stockage non persistant, sont perdues toutes ensemble, si perdues, et pourvu que les variables soient réinitialisées correctement, le protocole de registre distribué de stockage fonctionne correctement, et la progression des processus et des entités de traitement utilisant le registre distribué de stockage est maintenue.
Chaque processus P; stocke trois variables: (1) val 1534, qui détient la valeur actuelle, locale pour le registre distribué de stockage; (2) valts 1536, qui indique la valeur d'estampille temporelle associée à la valeur locale actuelle pour le registre distribué de stockage; et (3) ordts 1538, qui indique l'estampille temporelle la plus récente associée à une opération ECRITURE. La variable val est initialisée, particulièrement dans des modes de réalisation de stockage non persistant, à une valeur NUL qui est différente de toute valeur écrite dans le registre distribué de stockage par des processus ou des entités de traitement, et qui peut, par conséquent, être distinguée de toutes les autres valeurs de registre distribué de stockage. De la même façon, les valeurs des variables val-ts et ord-ts sont initialisées à la valeur initialTS (selon les initiales du terme anglo-saxon Time Stamp), une valeur inférieure à toute valeur d'estampille temporelle renvoyée par une routine Nouvelle TS utilisée pour générer des valeurs d'estampille temporelle. Pourvu que val, val-ts et ord-ts soient réinitialisés ensemble à ces valeurs, le registre distribué de stockage, mis en oeuvre collectivement, tolère des interruptions de communication et des écrasements de processus et d'entités de traitement, pourvu qu'au moins une majorité des processus et des entités de traitement récupèrent et reprennent un fonctionnement de correction.
Chaque processeur ou entité de traitement P; peut être interconnecté aux autres processus et entités de traitement Pi#; par l'intermédiaire d'un réseau basé sur des messages afin de recevoir 1512 et pour envoyer 1514 des messages vers les autres processus et entités de traitement Pi ;. Chaque processeur ou entité de traitement P; inclut une routine Nouvelle TS 1516 qui renvoie une estampille temporelle TS; lorsqu'elle est appelée, l'estampille temporelle TS; étant supérieure à une valeur initiale initialTS . A chaque fois que la routine Nouvelle TS est appelée, elle renvoie une estampille temporelle TS; supérieure à toute autre estampille temporelle renvoyée précédemment. Egalement, toute estampille temporelle TS; renvoyée par la Nouvelle TS appelée par un processeur ou une entité de traitement P; doit être différente de toute estampille temporelle TSF renvoyée par Nouvelle TS appelée par tout autre processeur ou entité de traitement Pi. Un procédé pratique destiné à mettre en oeuvre Nouvelle TS consiste à faire en sorte que Nouvelle TS renvoie une estampille temporelle TS comprenant la concaténation du PID local 1504 avec l'heure actuelle rapportée par l'horloge système 1506. Chaque processeur ou entité de traitement P; qui met en oeuvre le registre distribué de stockage inclut quatre routines de gestionnaire différentes: (1) un gestionnaire LECTURE 1518; (2) un gestionnaire MISE EN ORDRE 1520; (3) un gestionnaire ECRITURE 1522; et (4) un gestionnaire MISE EN ORDRE & LECTURE 1524. Il est important de noter que des routines de gestionnaire doivent être mises en oeuvre en tant que sections critiques, ou réalisées sous la forme d'un seul brin d'exécution (single-threaded) par des verrous afin d'empêcher des conditions de course dans les tests et les réglages de valeurs de variable locale. Chaque processeur ou entité de traitement P; a également quatre routines opérationnelles: (1) LECTURE 1526; (2) ECRITURE 1528; (3) RECUPERATION 1530; et (4) MAJORITE 1532. Et les quatre routines de gestionnaire et les quatre routines opérationnelles sont discutées en détail ci-dessous.
Un fonctionnement correct d'un registre distribué de stockage, et le caractère vivant (liveness), ou la progression, de processus et d'entités de traitement utilisant un registre distribué de stockage dépend d'un certain nombre de suppositions. Chaque processus ou entité de traitement P; est censé ne pas se comporter de manière malicieuse. Autrement dit, chaque processeur ou entité de traitement P; adhère fidèlement au protocole de registre distribué de stockage. Une autre supposition est qu'une majorité des processus et/ou des entités de traitement P; qui mettent collectivement en oeuvre un registre distribué de stockage soit ne s'écrasent jamais, soit arrêtent de s'écraser et s'exécutent de manière fiable en fin du compte. Comme discuté ci-dessus, une mise en oeuvre de registre distribué de stockage est tolérante à des messages perdus, à des interruptions de communication et à des écrasements de processus et d'entités de traitement qui influencent, à tout moment donné, sur une minorité des processus et des entités de traitement. Comme rnentionné ci-dessus, tous les processus et/ou toutes les entités de traitement sont complètement interconnectés pair un réseau basé sur des messages. Le réseau basé sur des messages est asynchrone, n'ayant aucune limite sur les temps de transmission de messages. Cependant, il est supposé une propriété de pertes équitables pour le réseau, qui garantit essentiellement que si P; reçoit un message m depuis alors Pi a envoyé le message m, et garantit également essentiellement que si P; transmet de manière répétée le message m vers P, recevra le message m en fin de compte, si Pi est un processus correct ou une entité de traitement correcte. Encore une fois, comme discuté ci-dessus, il est supposé que les horloges de système pour tous les processus ou toutes les entités de traitement reflètent raisonnablement un certain étalon partagé de temps mais n'ont pas besoin d'être exactement synchronisées.
Ces suppositions sont utiles pour prouver que le protocole de registre distribué de stockage est correct et garantit la progression. Cependant, dans des mises en oeuvre pratiques, l'une ou plusieurs des suppositions peuvent être violées et un registre distribué de stockage raisonnablement correct et utile est obtenu. De surcroît, des sauvegardes supplémentaires peuvent être incorporées dans les routines de gestionnaire et les routines opérationnelles afin de surmonter des insuffisances particulières dans les plates-formes matérielles et les entités de traitement.
Le fonctionnement du registre distribué de stockage est basé sur le concept d'un quorum. La figure 16 illustre la détermination de la valeur actuelle d'un registre distribué de stockage au moyen d'un quorum. La figure 16 utilise des conventions d'illustration semblables à celles utilisées aux figures 8 à 14. A la figure 16, chacun des processus ou des entités de traitement 1602 à 1606 maintient la variable locale val-ts, telle que la variable locale 1607 maintenue par le processus ou l'entité de traitement 1602, qui détient une valeur locale d'estampille temporelle pour le registre distribué de stockage. Si, comme à la figure 16, une rnajorité des valeurs locales maintenues par les différents processus et/ou les entités de traitement qui mettent collectivement en oeuvre le registre distribué de stockage sont actuellement d'accord sur une valeur val-ts d'estampille temporelle, associée au registre distribué de stockage, alors la valeur actuelle du registre distribué de stockage 1608 est considérée comme étant la valeur de la variable val détenue par la majorité des processus et des entités de traitement. Si une majorité des processus et des entités de traitement ne peuvent pas se mettre d'accord sur une valeur val-ts d'estampille temporelle, ou qu'il n'existe aucune valeur unique détenue par la majorité, alors le contenu du registre distribué de stockage est non défini. Cependant, une valeur détenue par une minorité peut alors être sélectionnée, et il peut être trouvé un accord sur la valeur, par une majorité des processus et/ou des entités de traitement, afin de récupérer le registre distribué de stockage.
La figure 17 montre des mises en oeuvre en pseudocode pour les gestionnaires de routines et les routines opérationnelles montrées schématiquement à la figure 15. Il doit être noté que ces mises en oeuvre en pseudocode omettent un traitement détaillé des erreurs et des détails spécifiques concernant des primitives de communication de bas niveau, le verrouillage local et d'autres détails qui sont bien entendu mis en oeuvre de manière simple par l'homme du métier dans le domaine de la programmation informatique. La routine Majorité 1702 émet un message, à la ligne 2, provenant d'un processus ou d'une entité de traitement P;, à soi-même et à tous les autres processus ou à toutes les autres entités de traitement P;#; qui, ensemble avec P;, mettent collectivement en oeuvre un registre distribué de stockage. Le message est réémis périodiquement, jusqu'à ce qu'un nombre suffisant de réponses soient reçues, et dans un grand nombre de mises en oeuvre, un temporisateur est réglé pour placer une limite finie de temps et d'exécution sur cette étape.
Ensuite, aux lignes 3 et 4, la routine Majorité attend la réception de réponses au message, et renvoie ensuite les réponses reçues, à la ligne 5. La supposition qu'une majorité de processus soient corrects, discutée ci-dessus, garantit essentiellement que la routine Majorité retournera en fin de compte, qu'un temporisateur soit utilisé ou non. Dans des mises en oeuvre pratiques, un temporisateur facilite le traitement d'événements d'erreurs en temps utile. Il est à noter que chaque message est identifié de manière unique, généralement au moyen d'une estampille temporelle ou d'un autre numéro unique, de manière que des réponses reçues par le processus P; puissent être corrélées à un message émis précédemment.
La routine Lecture 1704 lit une valeur depuis le registre distribué de stockage. A la ligne 2, la routine Lecture appelle la routine Majorité pour qu'elle émette un message LECTURE à soi-même et à chacun des autres processus ou entités de traitement Pi ;. Le message LECTURE inclut une indication que le message est un message LECTURE ainsi que la valeur d'estampille temporelle associée à la valeur locale, actuelle de registre distribué de stockage détenue par le processus P;, val-ts. Si la routine Majorité renvoie un ensemble de réponses, toutes contenant la valeur booléenne VRAI , comme déterminé à la ligne 3, alors la routine Lecture renvoie la valeur locale actuelle de registre distribué de stockage, val. Sinon, à la ligne 4, la routine Lecture appelle la routine Récupération .
La routine Récupération 1706 cherche à déterminer une valeur actuelle du registre distribué de stockage par une technique de quorum. D'abord, à la ligne 2, une nouvelle estampille temporelle ts est obtenue en appelant la routine Nouvelle TS . Ensuite, à la ligne 3, la routine Majorité est appelée pour émettre des messages MISE EN ORDRE & LECTURE vers tous les processus et/ou les entités de traitement. Si un état quelconque dans les réponses renvoyées par la routine Majorité est FAUX , alors Récupération renvoie la valeur NUL, à la ligne 4. Sinon, à la ligne 5, la valeur locale actuelle du registre distribué de stockage, val, est réglée à la valeur associé à l'estampille temporelle de valeur la plus élevée dans l'ensemble de réponses renvoyées par la routine Majorité . Ensuite, à la ligne 6, la routine Majorité est de nouveau appelée pour émettre un message ECRITURE qui inclut la nouvelle estampille temporaire ts obtenue à la ligne 2, et la nouvelle valeur locale actuelle du registre distribué de stockage, val. Si l'état dans toutes les réponses a la valeur booléenne VRAI , alors l'opération ECRITURE a réussi, et une majorité des processus et/ou des entités de traitement coïncident maintenant avec cette dernière valeur nouvelle, stockée dans la copie local val à la ligne 5. Sinon, la routine récupération renvoie la valeur NUL.
La routine Ecriture 1708 écrit une nouvelle valeur dans le registre distribué de stockage. Une nouvelle estampille temporelle ts est obtenue à la ligne 2. La routine Majorité est appelée, à la ligne 3, pour émettre un message MISE EN ORDRE, incluant la nouvelle estampille temporelle, vers tous les processus et/ou toutes les entités de traitement. Si l'une quelconque des valeurs d'état renvoyées dans les messages de réponse renvoyés par la routine Majorité est FAUX , alors la valeur NOK est renvoyée par la routine Ecriture à la ligne 4. Sinon, la valeur val est écrite vers les autres processus et/ou entités de traitement, à la ligne 5, en émettant un message ECRITURE par l'intermédiaire de la routine Majorité . Si toutes les valeurs d'état dans des réponses renvoyées par la routine Majorité sont VRAI , comme déterminé à la ligne 6, alors la routine Ecriture renvoie la valeur OK . Sinon, à la ligne 7, la routine Ecriture renvoie la valeur NOK . Il est à noter que, dans les cas et de la routine Récupération 1706 et de la routine Ecriture , la copie locale de la valeur val de registre distribué de stockage et la copie locale de l'estampille temporelle val-ts sont toutes les deux mises à jour par les routines locales de gestionnaire, discutées ci-dessous.
Ensuite, les routines de gestionnaire sont discutées. II doit d'emblée être noté que les valeurs de gestionnaire comparent des valeurs reçues à des valeurs de variable locale, et règlent ensuite les valeurs de variable locale selon le résultat des comparaisons. Ces types d'opérations doivent être strictement sérialisés et protégés contre des conditions de course à l'intérieur de chaque processus et/ou de chaque entité de traitement. Une sérialisation locale est facilement réalisée en utilisant des sections critiques ou des verrous locaux sur la base d'instructions de test et de réglage atomiques. La routine de gestionnaire LECTURE 1710 reçoit un message LECTURE et répond au message LECTURE par une valeur état qui indique si la copie locale de l'estampille temporelle val-ts dans le processus de réception est égale ou non à l'estampille temporelle reçue dans le message LECTURE et si l'estampille temporelle ts reçue dans le message LECTURE est supérieure ou égale, ou non, à la valeur actuelle d'une variable locale ord-ts. La routine de gestionnaire ECRITURE 1712 reçoit un message ECRITURE qui détermine une valeur pour une variable locale état, à la ligne 2, qui indique si la copie locale de l'estampille temporelle val-ts dans le processus ou l'entité de réception est supérieure ou non à l'estampille temporelle reçue dans le message ECRITURE et si l'estampille temporelle ts reçue dans le message ECRITURE est supérieure ou égale, ou non, à la valeur actuelle d'une variable locale ord-ts. Si la valeur de la variable locale état est VRAI , déterminée à la ligne 3, alors la routine de gestionnaire ECRITURE met à jour la valeur et l'estampille temporelle stockées localement, val et val-ts, aux lignes 4 et 5, et en mémoire dynamique et en mémoire persistante, par la valeur et l'estampille temporelle reçues dans le message ECRITURE. Pour terminer, à la ligne 6, la valeur détenue dans la variable locale état est renvoyée vers le processus ou l'entité de traitement qui avait émis le message ECRITURE géré par la routine de gestionnaire ECRITURE 1712.
Le gestionnaire MISE EN ORDRE & LECTURE 1714 calcule une valeur pour la variable locale état à la ligne 2 et renvoie cette dernière valeur vers le processus ou l'entité de traitement depuis lequel (laquelle) un message MISE EN ORDRE & LECTURE avait été reçu. La valeur calculée de état est une valeur booléenne indiquant si l'estampille temporelle reçue dans le message MISE EN ORDRE & LECTURE est supérieure ou non aux deux valeurs stockées dans les variables locales val-ts et ord-ts. Si la valeur calculée de état est VRAI , alors l'estampille temporelle reçue ts est stockée et en mémoire dynamique et en mémoire persistante dans la variable ord-ts.
De la même façon, le gestionnaire MISE EN ORDRE 1716 calcule une valeur pour une variable locale état à la ligne 2 et renvoie ce dernier état vers le processus ou l'entité de traitement depuis lequel (laquelle) un message MISE EN ORDRE avait été reçu. L'état reflète si l'estampille temporelle reçue est supérieure ou non aux valeurs détenues dans les variables locales val-ts et ord-ts. Si la valeur calculée de état est VRAI , alors l'estampille temporelle ts est stockée et en mémoire dynamique, et en mémoire persistante dans la variable ord-ts.
En utilisant le procédé et le protocole de registre distribué de stockage, discuté ci-dessus, des informations d'état partagées, qui sont en continu maintenues de façon cohérente dans un système distribué de stockage de données, peuvent être stockées dans un ensemble de registres de stockage distribués, une unité d'informations d'état partagées par registre. La taille d'un registre peut varier de manière à prendre en compte différentes tailles naturelles d'unités d'informations d'état partagées. La granularité d'unités d'informations d'état peut être déterminée par une surveillance de la performance, ou par une analyse du taux attendu d'échange d'unités d'informations d'état à l'intérieur d'un système distribué particulier. Des unités plus grandes encourent moins de surdébits pour des variables de protocole et d'autres données maintenues pour un registre distribué de stockage mais peuvent avoir pour résultat des surdébits de communication augmentés, s'il est fait accès à différentes portions des unités à des temps différents. Il doit également être noté que, tandis que le pseudocode et les illustrations ci- dessus concernent la mise en oeuvre d'un seul registre distribué de stockage, ces routines en pseudocode peuvent être généralisées en ajoutant des paramètres identifiant un registre particulier de stockage distribué, d'unité d'informations d'état, vers lequel des opérations sont dirigées, et en maintenant des matrices de variables telles que val-ts, val et ordts, indexées par les paramètres identifiants.
Ayant un registre distribué de stockage, mis en oeuvre par les valeurs stockées, les routines de gestionnaire et les routines opérationnelles discutées ci-dessus, un ensemble de processus et/ou d'entités de traitement peuvent associer un registre distribué de stockage à une ou plusieurs ressources pour laquelle (lesquelles) l'accès doit être sérialisé, afin de permettre un partage concourant de la ou des plusieurs ressource(s) récente(s) par les processus et/ou les entités de traitement qui mettent collectivement en oeuvre le registre associé de stockage distribué. La figure 18 montre un protocole de verrou distribué, basé sur un registre distribué de stockage qui représente un mode de réalisation de la présente invention. Comme le montre la figure 18, le registre distribué de stockage 1804 détient les valeurs enchaînées d'un PID pour un processus détenant le verrou distribué, et un temps d'expiration pour le verrou. Lorsque le registre distribué de stockage détient une valeur de PID / temps d'expiration, alors la ressource ou les ressources associée(s) au registre distribué de stockage est/sont considérée(s) comme étant verrouillée(s) 1806 par le processus ou l'entité de traitement ayant le PID. Lorsque aucun processus ou entité de traitement ne détient le verrou, alors la ressource ou les ressources associée(s) au registre distribué de stockage est/sont considérée(s) comme n'étant pas verrouillée(s). Une valeur spéciale AUCUN ou AUCUN PROCESSUS peut être utilisée afin d'indiquer qu'aucun processus ne détient actuellement le verrou distribué. Le verrou distribué permet ainsi à un processus donné ou à une entité de traitement donnée quelconque de louer la ressource ou les ressources associé(e)s au registre distribué de stockage pour une période de temps spécifiée.
Il doit être noté qu'un certain nombre de différentes sémantiques de verrous peuvent être associées à un verrou distribué. Le verrou distribué peut être un verrou uniquement par rapport à certains types d'opérations, telles que des opérations ECRITURE dirigées vers une ressource, ou peut verrouiller une ressource à toutes les opérations dirigées vers la ressource par des processus et/ou des entités de traitement qui ne détiennent pas le verrou. De surcroît, le verrou peut permettre à un nombre maximal spécifié de processus d'accéder de manière concourante à la ressource ou aux ressources associée(s) au verrou. Comme discuté cidessus, les ressources peuvent être des dispositifs, des données, des régions de mémoire, des structures de données, des entités logiques, incluant des volumes, et tout autre dispositif ou toute autre ressource de calcul pour lequel (laquelle) des processus ou entités de traitement multiples peuvent être en conflit de manière concourante, simultanée, ou et concourante et simultanée.
Différents protocoles de verrou distribué peuvent être mis en oeuvre afin de créer le verrou distribué, sur la base d'un registre distribué de stockage, illustré à la figure 18. Encore une fois, comme dans le cas du protocole de registre distribué de stockage, discuté ci-dessus, des processus et/ou des entités de traitement qui partagent de manière coopérative une ressource en utilisant le verrou distribué sont supposés ne pas se comporter de manière malicieuse, et adhérer fidèlement au protocole de verrou distribué.
La figure 19 montre un protocole simple de verrou distribué mis en oeuvre par une routine Bail Ressource . La routine Bail Ressource est appelée par un processus ou une entité de traitement afin de verrouiller une ressource ou un ensemble de ressources associée(s) à un registre distribué de stockage pour une période de temps spécifiée. A l'étape 1902, la routine Bail Ressource reçoit un identifiant R qui identifie la ressource particulière ou les ressources particulières pour laquelle (lesquelles) un verrou est souhaité, et un temps de bail t pour lequel le verrou est souhaité. II est à noter qu'un processus ou une entité de traitement peut accéder de manière concourante à un certain nombre de différentes ressources ou à différents ensembles de ressources, chacun(e) étant associé(e) à un verrou distribué séparé, en verrouillant les différentes ressources à travers des appels séparés à Bail Ressource . A l'étape 1904, la routine Bail Ressource lit le contenu du registre distribué de stockage associé à la ressource ou aux ressources R utilisant le protocole, décrit ci-dessus, de registre distribué de stockage. Si l'opération LECTURE à l'étape 1904 renvoie la valeur NUL, comme déterminé à l'étape 1906, alors la routine Bail Ressource renvoie la valeur FAUX à l'étape 1908. Sinon, si l'heure d'expiration lue depuis le registre distribué de stockage est inférieure à l'heure actuelle obtenue depuis l'horloge système locale, ou que le PID lu depuis le registre distribué de stockage a la valeur AUCUN ou AUCUN PROCESSUS , comme déterminé à l'étape 1910, alors, à l'étape 1912, la routine Bail Ressource écrit le PID local du processus ou de l'entité de traitementappelant la routine Bail Ressource et une valeur temporelle égale à t + heure_système_actuelle + 13 dans le registre distribué de stockage associé à la ressource ou aux ressources R. Si l'opération ECRITURE, effectuée à l'étape 1912, renvoie la valeur booléenne VRAI , comme déterminé à l'étape 1914, alors la routine Bail Ressource renvoie une valeur VRAI à l'étape 1916. Sinon, la routine Bail Ressource renvoie la valeur booléenne FAUX , à l'étape 1908. II est à noter, à l'étape 1910, que la comparaison de l'heure d'expiration à l'heure actuelle est suffisante pour garantir que le bail a expiré, parce que la valeur R ajoutée au calcul de l'heure d'expiration, à l'étape 1912, complète par adjonction l'heure d'expiration afin de rendre compte du manque de synchronisation exacte entre les horloges système des différents processus et des différentes entités. II est également à noter qu'un processus ou une entité de traitement ne doit pas tenter d'accéder à la ressource ou à l'ensemble de ressources à la suite de l'expiration d'un bail, sans appeler de nouveau la routine Bail Ressource . La valeur f3 peut dépendre des supports et des systèmes de communication et peut se situer dans la plage de millisecondes, de secondes, de minutes, de dizaines de minutes, ou d'intervalles de temps plus longs. Un processus peut garantir qu'il adhère au protocole de verrou distribué en réglant un temporisateur suite à la prise d'un bail, et vérifiant la présence d'une expiration de temporisateur, entre autres procédés, avant d'accéder à la ressource louée ou à l'ensemble de ressources louées; il est également à noter que, lorsqu'un grand nombre de processus ou d'entités de traitement sont en conflit pour la ressource ou l'ensemble de ressources sur une période de temps, l'accès à la ressource ou aux ressources n'est pas garanti à l'intérieur d'un intervalle de temps particulier pour un processus ou une entité de traitement individuel quelconque par la mise en oeuvre de la routine Bail Ressource montrée à la figure 19.
Un procédé et un protocole finaux gèrent des informations d'état partagées, mises en mémoire cache. Il s'avère que la gestion d'informations d'état partagées, mises en mémoire cache, peut être effectuée de manière efficace dans un environnement distribué de calcul en utilisant un procédé et un protocole représentant une amélioration du procédé et du protocole pour des registres distribués de stockage, discutés ci-dessus. Une amélioration supplémentaire fournit une opération de lecture et de modification atomique pour des informations d'état partagées, mais mises en mémoire cache localement.
Les figures 20 à 27 illustrent un registre de stockage, distribué mais mis en mémoire cache localement, de la même manière que le registre distribué de stockage est illustré aux figures 8 à 14. Ces illustrations montrent cinq noeuds, ou systèmes composants 2002 à 2006 de stockage de données, qui partagent et maintiennent ensemble un registre de stockage 2008 distribué, mais mis en mémoire cache localement. Chaque noeud maintient une copie locale, ou une mémoire cache locale, correspondant au registre de stockage distribué, mais mis en mémoire cache localement, telle que la copie locale 2010 dans le noeud 2002. Chaque noeud a sa propre horloge locale, telle que l'horloge locale 2012 dans le noeud 2002 (ou l'horloge système 1506 à la figure 15), qui reflète un certain étalon de temps absolu, mais non forcément exactement synchronisé avec les horloges dans les autres noeuds. Chaque noeud inclut également deux variables stockées localement, associées au registre 2008 distribué, mais mis en mémoire cache localement: (1) une valeur d'expiration de bail actuel, telle que la valeur 2013 d'expiration de bail actuel dans le noeud 2002; et (2) une valeur de retard de traitement, telle que la valeur 2014 de retard de traitement dans le noeud 2002. La valeur 2013 d'expiration de bail actuel indique une heure à laquelle un bail actuel pour le registre de stockage distribué, mais mis en mémoire cache localement, expire pour un noeud donné. Pendant que le bail actuel est valide, ou autrement dit, non expirée, et que le noeud n'est pas actuellement soumis à un retard de traitement dû à une modification échouée de la copie locale du registre de stockage distribué, mais mis en mémoire cache localement, le noeud peut lire librement le contenu du registre de stockage distribué, mais mis en mémoire cache localement, en accédant à la copie stockée localement, telle que la copie locale 2010 dans le noeud 2002, comme indiqué par les flèches courbées 2016 et 2018 à la figure 20. Le fait d'accéder à une copie stockée localement élimine les surdébits de communication encourus en accédant à un registre distribué de stockage par l'intermédiaire d'un protocole de stockage distribué, basé sur un quorum.
Comme le montre la figure 21, lorsque la valeur 2013 d'expiration de bail actuel est inférieure ou égale à l'heure système 2012 au niveau d'un noeud particulier 2002, le bail local pour le registre de stockage distribué, mais mis à mémoire cache localement, a expiré, et le noeud rafraîchit sa copie locale 2010 du registre de stockage 2008 distribué, mais mis à mémoire cache localement, en utilisant l'opération Lecture 2102 de registre distribué de stockage. Lorsque la copie locale a été rafraîchie, la valeur 2013 d'expiration de bail actuel est mise à jour afin de fournir un bail suivant pour le noeud 2002, durant le temps de validité duquel le noeud peut librement accéder à la copie locale du registre de stockage distribué, mais mis en mémoire cache localement, pour lire le contenu du registre de stockage distribué, mais mis à mémoire cache localement.
La modification ou l'écriture du contenu d'un registre de stockage distribué, mais mis en mémoire cache localement, est une opération quelque peu plus complexe que l'écriture d'une valeur dans un registre distribué de stockage. Comme le montre la figure 22, un noeud particulier, tel que le noeud 2002, peut émettre une opération ECRITURE 2102 vers un registre de stockage distribué, mais mis en mémoire cache localement, ayant pour résultat qu'un message ECRITURE ETAT est émis, 2104 à 2108, vers tous les noeuds qui mettent ensemble en oeuvre le registre de stockage distribué, mais mis en mémoire cache localement. Suite à la réception du message ECRITURE ETAT, comme le montre la figure 23, chaque noeud met à jour sa copie locale du registre de stockage distribué, mais mis en mémoire cache localement, par une nouvelle valeur d'état, 2302 à 2306, et initialise la valeur de retard de traitement à une valeur de temps prédéterminée, 2308 à 2312. Si tous les noeuds mettent à jour avec succès leurs copies locales du registre stockage distribué, mais mis en mémoire cache localement, comme le montre la figure 24, alors la valeur de retard de traitement est annulé 2402 à 2406, et le registre de stockage 2008 distribué, mais mis à mémoire cache localement, est considéré comme ayant été modifié avec succès, et contient par conséquent la nouvelle valeur modifiée.
Cependant, comme le montre la figure 25, si même un seul noeud 2004 manque de recevoir le message ECRITURE ETAT et de mettre à jour sa copie locale du registre de stockage 2008 distribué, mais mis en mémoire cache localement, alors, comme le montre la figure 26, les noeuds restants qui avaient reçu le message ECRITURE ETAT et mis à jour leurs copies locales 2002, 2003, 2005, 2006, cessent le traitement jusqu'à ce que l'heure actuelle dépasse la valeur de retard de traitement stockée dans chaque noeud. Ceci assure que la valeur nouvellement modifiée du registre de stockage distribué, mais mis en mémoire cache localement, ne sera utilisée que lorsque le bail pour le registre stockage distribué, mais mis à mémoire cache localement, détenu par le noeud 2004 expire et que le noeud 2004 obtient la valeur modifiée du registre de stockage distribué, mis en mémoire cache localement, à travers une opération de lecture de registre distribué de stockage, comme le montre la figure 27. Une fois que les noeuds restants ont retardé le traitement jusqu'à ce que leur heure système dépasse leurs valeurs de retard de traitement stockées localement, ils peuvent alors reprendre le traitement et accéder au registre distribué de stockage, mais mis à mémoire cache localement. II est à noter que le processus d'écriture est résistant à des écrasements de noeud pour les mêmes raisons que les procédés de registre distribué de stockage sont résistants à des écrasements de noeud, et que les avertissements et suppositions discutés par rapport aux procédés de registre distribué de stockage s'appliquent également aux procédés de registre de stockage distribué mais mis en mémoire cache localement.
Ensuite, les procédures et les gestionnaires qui sont ajoutés aux procédures et gestionnaires de registre distribué de stockage afin de mettre en oeuvre un registre stockage distribué, mais mis en mémoire cache localement, sont discutés. La figure 28 montre les procédures et les gestionnaires utilisés pour mettre en oeuvre un registre de stockage distribué mais mis en mémoire cache localement, utilisant les conventions d'illustration employées précédemment à la figure 17. Deux gestionnaires supplémentaires utilisées pour mettre en oeuvre un registre de stockage distribué, mais mis en mémoire cache localement, inclut un gestionnaire ECRITURE ETAT 2802 et un gestionnaire ANNULATION RETARD 2804. Des procédures supplémentaires utilisées afin de mettre en oeuvre un registre de stockage distribué, mais mis en mémoire cache localement, inclut les procédures Totalité 2806, Rafraîchissement cache 2808, Lecture cache cohérente 2810, Mise à jour état 2812, Accès 2814, Modification 2816 et Mise à jour état atomique 2818. Les trois dernières procédures fournissent une opération de lecture et de modification atomique pour des registres de stockage distribués, mais mis en mémoire cache localement.
La figure 29 montre des mises en oeuvre en pseudocode des procédures qui peuvent être ajoutées aux procédures et aux gestionnaires de registre distribué de stockage afin de mettre en oeuvre un registre de stockage distribué, mais mis en mémoire cache localement. La figure 30 montre des mises en oeuvre en pseudocode des gestionnaires qui peuvent être ajoutés aux procédures et aux gestionnaires de registre distribué de stockage afin de mettre en oeuvre un registre de stockage distribué, mais mis en mémoire cache localement. II doit être noté que ces procédures et gestionnaires sont mis en oeuvre dans le contexte d'un traitement de comrnande par un système distribué de stockage de données dans lequel, au cours de l'exécution de commandes, il est possible d'accéder à, ou modifier, un registre de stockage distribué, mais mis en mémoire cache localement, contenant des informations d'état partagées. Par exemple, les retards de traitement décrits ci-dessus qui se produisent lorsqu'un ou plusieurs noeuds manquent de se mettre à jour pendant une modification de registre de stockage distribué, mais mis en mémoire cache localement, sont essentiellement des retards dans le traitement de commande par des systèmes composants de stockage de données pour des commandes qui comprennent l'accès et/ou la modification des informations d'état contenues dans le registre de stockage distribué, mais mis en mémoire cache localement. L'intention d'utiliser des registres de stockage distribué, mais mis en mémoire cache localement, est d'assurer une valeur cohérente pour des informations d'état partagées, mises en mémoire cache, partout dans les dispositifs composants de stockage de données d'un système distribué de stockage de données. Des informations d'état partagées, mises en mémoire cache, qui sont maintenues dans un système distribué de stockage de données, peuvent être stockées dans un ensemble de registres de stockage distribués, mais mis en mémoire cache localement, une unité d'informations d'état partagées par registre. La taille d'un registre peut varier de manière à prendre en compte différentes tailles naturelles d'unités d'informations d'état partagées. La granularité d'unités d'informations d'état peut être déterminée par une surveillance de la performance, ou par une analyse des taux attendus d'échange d'unités d'informations d'état à l'intérieur d'un système distribué particulier. Des unités plus grandes encourent moins de surdébits pour des variables de protocole et d'autres données maintenues pour un registre distribué de stockage mais peuvent avoir pour résultat des surdébits de communication augmentés, si différentes portions des unités sont modifiées à des temps différents. II doit également être noté que, tandis que le pseudocode et les illustrations ci-dessus concernent la mise en oeuvre d'un seul registre de stockage distribué, ces routines en pseudocode peuvent être généralisées en ajoutant des paramètres identifiant un registre distribué de stockage particulier, d'unité d'informations d'état, vers lequel des opérations sont dirigées, et en maintenant des matrices de variables, indexées par les paramètres identifiants. II est à noter qu'un registre de stockage distribué, mais mis en mémoire cache localement, est associé aux variables val-ts et ordts, juste comme un registre distribué de stockage.
La procédure Totalité est équivalente à la routine Majorité décrite ci-dessus, à l'exception que Totalité tente d'obtenir des réponses depuis tous les noeuds, plutôt que depuis une majorité des noeuds. La procédure Totalité est utilisée afin d'assurer que toutes les valeurs locales maintenues au niveau de noeuds pour un registre de stockage distribué, mais mis en mémoire cache localement, sont identiques. Sinon, des noeuds ayant une modification plus récente s'abstiennent de traiter des commandes connexes au registre de stockage distribué, mais mis en mémoire cache localement, jusqu'à ce que les valeurs locales maintenues au niveau de noeuds pour un registre de stockage distribué, mais mis en mémoire cache localement, soient de nouveau toutes identiques, ou jusqu'à ce que leurs baux aient expiré.
La procédure Rafraîchissement cache (2902 à la figure 29) est appelée généralement antérieurement à l'expiration d'un bail pour un registre de stockage distribué, mais mis en mémoire cache localement, ou avec moins d'efficacité pour le fonctionnement d'un système distribué de stockage de données, suite à l'expiration du bail. D'abord, à la ligne 2, une valeur d'expiration de bail temporaire, expiration_bail temp, est initialisée à l'heure système actuelle plus un certain temps de bail prédéterminé pour le registre de stockage distribué, mais mis en mémoire cache localement. Ensuite, à la ligne 3, le contenu du registre de stockage distribué, mais mis en mémoire cache localement, est lu par l'intermédiaire d'un registre Lecture de stockage distribué, basé sur un quorum. Si Lecture réussit, la valeur actuelle d'expiration de bail est mise à jour aux lignes 5 et 6, un retard de message et une allocation de dérive étant pris en compte pour assurer que le bail expire antérieurement à l'accès à une valeur modifiée du registre de stockage distribué, mais mis en mémoire cache localement, par un noeud ayant une valeur locale plus ancienne pendant des défaillances du type discuté en référence aux figures 25 et 26.
La procédure Lecture cache cohérente (2904 à la figure 29) est représentative de procédures de traitement de commande, exécutées sur un système composant de stockage de données d'un système distribué de stockage de données. A la ligne 2, si la commande est un type de commande qui requiert un traitement immédiat par l'interface de dispositif de stockage de données, indépendamment de l'état de préparation du dispositif composant pour le traitement de commande d'accès aux données, alors la commande est traitée et une réponse renvoyée. Sinon, si le noeud est actuellement dans un état de retard de traitement de commande, dû à une modification échouée d'un stockage distribué, mais mis en mémoire cache localement, utilisé afin de traiter la commande, comme déterminé à la ligne 3, alors le traitement de la commande est retardé à la ligne 4. En général, des commandes qui impliquent le registre de stockage distribué, mais mis en mémoire cache localement, reçu pendant un retard de traitement de commande, continuent à être mises en file d'attente pour une exécution ultérieure. Si, comme déterminé à la ligne 5, le bail a expiré pour un registre de stockage distribué, mais mis en mémoire cache localement, auquel il est fait accès ou lequel est modifié pendant le traitement de commande, alors un état NON PRET, ou échec, doit être renvoyé par le système composant de stockage de données, parce qu'il n'est actuellement pas possible d'accéder au registre de stockage distribué, mais mis en mémoire cache localement. Pour terminer, à la ligne 9, s'il n'existe aucun retard ou échec par rapport aux registres de stockage distribués, mais mis en mémoire cache localement, utilisés pour le traitement de la commande reçue, la commande est traitée en utilisant et des informations d'état locales et des informations d'état partagées, en fonction du besoin.
La procédure Mise à jour état (2906 à la figure 29) est utilisée pour modifier le contenu d'un registre de stockage distribué, mais mis en mémoire cache localement. D'abord, à la ligne 2, une nouvelle estampille temporelle est acquise, et placée dans la variable ts. Ensuite, à la ligne 3, la procédure Majorité est appelée pour émettre un message MISE EN ORDRE vers tous les noeuds. Si une réponse quelconque au message MISE EN ORDRE est fausse, ou que Majorité échoue, comme déterminé à la ligne 4, alors la mise à jour échoue. Sinon, à la ligne 6, la procédure Totalité est appelée pour émettre un message ECRITURE ETAT vers tous les noeuds. Si un noeud quelconque répond par un message d'échec, ou qu'une majorité des noeuds manquent de répondre, alors la mise à jour échoue, comme déterminé à la ligne 7. Si tous les noeuds répondent, sans aucun échec, alors, à la ligne 9, des messages ANNULATION RETARD sont émis vers tous les noeuds pour leur permettre de continuer le traitement de commande en utilisant le registre de stockage distribué, mais mis en mémoire cache localement, mis à jour, la procédure Quelconque émettant des messages ANNULATION RETARD, mais n'attendant pas des réponses. Sinon, des messages ANNULATION RETARD ne sont pas émis, de manière que ces noeuds qui avaient modifié avec succès le registre de stockage distribué, mais mis en mémoire cache localement, retardent l'accès au registre de stockage distribué, mais mis en mémoire cache localement, jusqu'à ce que les baux des noeuds qui avaient manqué de mettre à jour leurs valeurs locales expirent, ou jusqu'à ce qu'une modification réussie des valeurs locales de tous les noeuds soit atteinte.
La procédure Accès (2908 à la figure 29) est utilisée en tant que première partie d'une opération optimiste de lecture et de modification atomique sur un registre de stockage distribué, mais mis en mémoire cache localement. L'opération optimiste de lecture et de modification est un verrou plus faible que le protocole de verrouillage distribué décrit cidessus en référence aux figures 18 et 19, appropriée à des opérations idempotentes qui peuvent échouer, suivant l'acquisition d'un droit d'accès, mais avant que le droit d'accès acquis ne soit exercé, et qui peuvent par la suite être répétées sans conséquences nuisibles. La procédure Majorité est appelée, à la ligne 2, pour émettre un message MISE EN ORDRE & LECTURE vers tous les noeuds. L'état renvoyé par la procédure Majorité est la valeur locale du registre de stockage mis en mémoire cache localement, stockée dans la variable val depuis le noeud ayant la value d'estampille temporelle val-ts la plus élevée est renvoyée par la procédure Accès . La procédure Modification (2910 à la figure 29) est utilisée en tant que deuxième partie d'une opération de lecture et de modification atomique sur un registre de stockage distribué, mais mis en mémoire cache localement. La procédure Totalité est appelée, à la ligne 2, afin d'émettre un message ECRITURE ETAT vers tous les noeuds. Si un noeud quelconque renvoie une réponse fausse, la procédure Modification échoue, comme détecté à la ligne 3. Sinon, un message ANNULATION RETARD est émis vers tous les noeuds à la ligne 5. La routine Quelconque émet le message ANNULATION RETARD, sans attendre les réponses des noeuds vers lesquels le message ANNULATION RETARD avait été émis. Un message ANNULATION RETARD reçu permet à un noeud de reprendre le traitement de commande plus tôt mais n'influence pas sur la cohérence ou l'exactitude. Une opération de lecture et de modification atomique pour un registre de stockage distribué mais mis en mémoire cache localement, la procédure Mise à jour état atomique (2912 à la figure 29), peut être utilisée afin de lire et de mettre à jour de façon atomique le contenu d'un registre de stockage distribué, mais mis en mémoire cache localement. A la ligne 2, une nouvelle estampille temporelle est générée. A la ligne 3, la procédure Accès est appelée. Si l'état renvoyé par la procédure Accès indique un échec, comme déterminé à la ligne 4, alors Mise à jour état atomique échoue. Sinon, à la ligne 5, une nouvelle valeur pour le registre de stockage distribué, mais mis en mémoire cache localement, est obtenue. Pour terminer, à la ligne 6, la procédure Modification est utilisée pour mettre à jour le contenu du registre de stockage distribué, mais mis en mémoire cache localement. L'état renvoyé par la procédure Modification détermine si Mise à jour état atomique réussit ou échoue, comme rapporté aux lignes 7 et 8. Une opération de lecture et de modification atomique peut être utilisée pour la mise en oeuvre de routines de traitement de commande, lorsque la force complète d'un verrou distribué n'est pas requise et qu'un verrou optimiste peut être utilisée au lieu de cela.
Le gestionnaire ECRITURE ETAT (3002 à la figure 30) gère des messages Ecriture Etat reçus. D'abord, à la ligne 2, l'estampille temporelle reçue dans le message ECRITURE ETAT qui avait invoqué le gestionnaire ECRITURE ETAT est comparée aux variables locales val-ts et ord-ts. Si l'estampille temporelle reçue est valide, comme déterminé à la ligne 3, alors la valeur retard expiration de retard de traitement est réglée, la copie locale pour le registre de stockage distribué, mais mis en mémoire cache localement, est mis à jour, et la variable locale val-ts est mise à jour aux lignes 4 à 6. A la ligne 7, des effets secondaires quelconques de la modification du contenu du registre de stockage distribué, mais mis en mémoire cache localement, sont effectués. Pour terminer, à la ligne 8, une réponse au message ECRITURE ETAT est émise vers le noeud depuis lequel il avait été reçu.
Dans un mode de réalisation alternatif, retard expiration peut être réglée à une valeur infinie ou très longue, à la ligne 4, et ensuite remise à la valeur à laquelle elle est réglée à la ligne 2 du premier mode de réalisation suivant une mise à jour de val ts, à la ligne 7. Dans ce cas, des échecs de processus requerraient que des noeuds dans un retard infini soient détectés, et que les retards infinis soient annulés. Le mode de réalisation alternatif peut être utilisé dans le cas où une mise à jour réussie avant l'expiration de retard de traitement ne peut pas être garantie.
Le gestionnaire ANNULATION RETARD (3004 à la figure 30) gère des messages ANNULATION RETARD reçus. D'abord, à la ligne 2, l'estampille temporelle reçue dans le message d'annulation de retard est comparée aux valeurs des variables locales val-ts et ord-ts. Si l'estampille temporelle reçue est valide, comme déterminé à la ligne 3, alors la valeur retard expiration de retard de traitement est annulée et le traitement de commandes pour des commandes qui dépendent du registre de stockage distribué, mais mis en mémoire cache localement, reprend.
Les figures 31 et 32 illustrent, en utilisant des diagrammes de flux de commande, un procédé global qui représente un mode de réalisation de la présente invention. La figure 31 montre un procédé destiné à démarrer le fonctionnement d'un système composant de stockage de données d'un système distribué de stockage de données. D'abord, à l'étape 3102, des informations d'état sont partitionnées entre les trois partitions: informations d'état locales; informations d'état partagées, mises en mémoire cache; et des informations d'état partagées. Ensuite, à l'étape 3104, les différents types d'informations d'état, d'horloges système, de temporisateurs et d'autres composants des protocoles de registre distribué de stockage et de registre de stockage distribué, mais mis en mémoire cache localement, sont initialisés. Pour terminer, à l'étape 3106, un gestionnaire d'événements est lancé pour recevoir et gérer des messages et des commandes.
La figure 32 est un diagramme de flux de commande du gestionnaire d'événements lancé à l'étape 3106 de la figure 31. A l'étape 3202, le gestionnaire d'événements se réveille pour gérer un événement détecté. Une fois que le gestionnaire d'événements a géré l'événement, et tout autre événement en instance, le gestionnaire d'événements attend, à l'étape 3204. Les étapes 3202 et 3204 de réveil et d'attente peuvent être mises en oeuvre par un bouclage continu ou par un type de suspension et de signalisation de processus ou de brin d'exécution, en fonction de la mise en oeuvre choisie pour le programme de contrôle de système de stockage de données. Si l'événement détecté est une commande de remise à l'état initial ou un autre événement qui indique un besoin de terminer le gestionnaire d'événements, comme déterminé à l'étape 3206, alors le gestionnaire d'événements retourne.
Sinon, si l'événement est associé à une commande reçue, comme déterminé à l'étape 3208, alors une procédure de traitement de commande pour la commande est appelée à l'étape 3210. Alternativement, une seule routine de traitement de commande peut se ramifier de façon interne pour gérer des types de commandes spécifiques. Le traitement de commande peut comprendre un accès à des informations d'état de tous les types, incluant des informations d'état partagées, mises en mémoire cache, auxquelles il est fait accès par des appels aux routines Lecture cache cohérente et Mise à jour état , peut comprendre des appels aux procédures de registre distribué de stockage discutées en référence à la figure 17, et peut comprendre des appels à des routines pour le verrouillage distribué et le verrouillage distribué optimiste. Ainsi, l'étape 3210 représente le point auquel il est fait accès à des informations d'état par des opérations LECTURE et ECRITURE. Sinon, si l'événement est une expiration d'une mémoire cache locale, ou d'une copie locale, comme déterminé à l'étape 3212, alors la procédure Rafraîchissement cache est appelée, à l'étape 3214, normalement avant l'expiration du bail réel, comme mentionné ci-dessus. Si l'événement est associé à un message reçu, comme déterminé à l'étape 3216, alors le gestionnaire approprié pour le message est appelé dans l'une des étapes 3218 à 3223. S'il existe un autre événement en instance à gérer, comme déterminé à l'étape 3224, alors le contrôlerepasse à l'étape 3206. Sinon, le contrôle passe à l'étape d'attente 3204.
Bien que la présente invention ait été décrite en termes de modes de réalisation particuliers, l'intention n'est pas que l'invention soit limitée à ce mode de réalisation. Des modifications conformes à l'esprit de l'invention découleront, pour l'homme du métier, de manière évidente. Par exemple, un grand nombre de différentes mises en correspondance d'informations d'état à des ensembles de registres distribués de stockage et à des registres de stockage distribués mais mis en mémoire cache localement sont possibles. Un grand nombre de différents réglages des différents paramètres utilisés dans les routines et les gestionnaires décrits ci-dessus peuvent être appropriés à différents systèmes distribués de stockage de données, et à différents moments pendant le fonctionnement d'un système particulier de stockage de données. De tels paramètres, et un tel partitionnement d'informations d'état, peuvent être accordés par une surveillance de la performance pendant le fonctionnement du système distribué de stockage de données.
La description précitée a utilisé, à des fins d'explication, une nomenclature spécifique pour fournir une compréhension approfondie de l'invention. Cependant, il découlera de manière évidente, pour l'homme du métier, que les détails spécifiques ne sont pas requis afin de mettre l'invention en pratique. Les descriptions précitées de modes de réalisation spécifiques de la présente invention sont présentées à des fins d'illustration et de description. Elles n'ont pas été rédigées avec l'intention qu'elles soient exhaustives ou qu'elles limitent l'invention aux formes précises divulguées. De toute évidence, un grand nombre de modifications et de variations sont possibles en vue des enseignements cidessus. Les modes de réalisation sont montrés et décrits dans l'ordre afin de mieux expliquer les principes de l'invention et ses applications pratiques, afin de permettre ainsi à d'autres hommes du métier d'utiliser au mieux l'invention et ses différents modes de réalisation comprenant différentes modifications lesquelles sont appropriées à l'usage particulier envisagé. L'intention est que la portée de l'invention soit définie par les revendications suivantes et leurs équivalents.
Claims (10)
1. Procédé destiné à gérer des informations d'état dans un système distribué de calcul (318) composé de systèmes composants de calcul (302 à 304), le procédé comprenant les étapes consistant: pour chaque système composant de calcul, à affecter (3102) chaque unité d'informations d'état à l'une des trois partitions incluant É des informations d'état locales (702), É des informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement (704), et É des informations d'état distribuées, partagées (706) ; et pendant le fonctionnement du système distribué de 15 calcul, É lorsque des unités d'information d'état sont affectées à la partition d'informations d'état locales, à gérer indépendamment, sur chaque système composant de calcul, des informations d'état locales, É lorsque des unités d'information d'état sont affectées à la partition d'informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement, à gérer chaque unité d'informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement, parmi deux systèmes composants de calcul ou plus en utilisant un protocole de registre de stockage distribué mais mis en mémoire.cache localement (2902, 2904, 2906, 2908, 2910, 3002, 3004), et É lorsque des unités d'information d'état sont affectées à la partition d'informations d'état distribuées, partagées, à gérer chaque unité d'informations d'état distribuées, partagées en utilisant un protocole de registre distribué de stockage.
2. Procédé selon la revendication 1, dans lequel le protocole de registre distribué de stockage fournit des opérations LECTURE et ECRITURE basées sur un quorum, dirigées vers un registre distribué de stockage (802) comprenant des valeurs (810 à 814) de registre distribué de stockage stockées localement sur chaque système composant de calcul; et dans lequel le protocole de registre de stockage distribué, mais mis en mémoire cache localement, fournit des opérations dirigées vers un registre de stockage (2008) distribué, mais mis en mémoire cache localement, incluant, en plus des opérations fournies par le protocole de registre distribué de stockage, une opération LECTURE locale et une opération ECRITURE ETAT.
3. Procédé selon la revendication 2, dans lequel l'opération LECTURE locale renvoie une valeur stockée localement (2010) pour le registre de stockage (2008) distribué, mais mis en mémoire cache localement, plutôt qu'une valeur basée sur un quorum, pourvu qu'un bail local pour le registre de stockage distribué, mais mis en mémoire cache localement, soit valide et que le traitement ne soit pas retardé ; dans lequel l'opération ECRITURE ETAT réussit lorsque tous les systèmes composants de calcul (2002 à 2006) mettent à jour leurs valeurs stockées localement pour le registre de stockage (2008) distribué, mais mis en mémoire cache localement, mais lorsque l'un, ou une minorité, des systèmes composants de calcul manquent de mettre à jour leurs valeurs stockées localement pour le registre de stockage distribué, mais mis en mémoire cache localement, les systèmes composants de calcul restants retardent l'utilisation de leurs valeurs mises à jour, stockées localement, pour le registre de stockage distribué, mais mis en mémoire cache localement, jusqu'à ce que les baux de l'un, ou d'une minorité, des systèmes composants de calcul pour le registre de stockage distribué, mais mis en mémoire cache localement, puissent être supposés avoir expiré ; dans lequel une valeur stockée localement (2010) pour le registre de stockage distribué, mais mis en mémoire cache localement, sur chaque système composant de calcul, est rafraîchie périodiquement par une opération LECTURE basée sur un quorum; et dans lequel le protocole de registre de stockage distribué mais mis en mémoire cache localement fournit une opération supplémentaire MISE A JOUR ETAT ATOMIQUE (2912) qui permet à un registre de stockage distribué, mais mis en mémoire cache localement, d'être lu et ensuite modifié par un système composant de calcul sans accès intervenant par un autre système composant de calcul quelconque.
4. Procédé selon la revendication 1, dans lequel une unité d'informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement (2008), ou d'informations d'état distribuées, partagées (802) peut comprendre un élément du groupe composé de: un octet; un mot machine un champ comprenant un certain nombre de mots machine; un enregistrement comprenant un certain nombre de 25 mots machine; une structure de données comprenant un certain nombre de mots machine; et un contrôle d'accès comprenant un ou plusieurs octets qui contrôle l'accès à des informations d'état supplémentaires.
5. Instructions machine codées sur un support lisible par ordinateur, destinées à, dans un système distribué de calcul (318) composé de systèmes composants de calcul (302 à 304), système distribué dans lequel des unités d'information d'état sont affectées comme des informations d'état locales, des informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement ou des informations d'état distribuées partagées: - gérer indépendamment, sur chaque système composant de calcul (2002 à 2006), les informations d'état locales (702) ; - gérer chaque unité d'informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement (704), parmi deux systèmes composants de calcul ou plus, en utilisant un protocole de registre de stockage distribué mais mis en mémoire cache localement (2902, 2904, 2906, 2908, 2910, 3002, 3004) ; et - gérer chaque unité d'informations d'état distribuées, partagées (706) en utilisant un protocole de registre distribué de stockage.
6. Système distribué de stockage de données, comprenant: un ou plusieurs moyens de communication (306, 308) ; un certain nombre de systèmes de stockage de données (302 à 304) interconnectés par le ou les plusieurs moyens de communication; une interface stockage de données cohérente, fournie par le certain nombre de systèmes de stockage de données, utilisant des informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement (704) et des informations d'état distribuées, partagées (706) ; un protocole de registre de stockage distribué mais mis en mémoire cache localement (2902, 2904, 2906, 2908, 2910, 3002, 3004), destiné à gérer des informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement; et un protocole de registre distribué de stockage, destiné à gérer des informations d'état distribuées, partagées.
7. Système distribué de stockage de données selon la revendication 6, dans lequel chaque unité d'informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement, est stockée dans un registre de stockage (2008) distribué, mais mis en mémoire cache localement, et chaque unité d'informations d'état distribuées, partagées est stockée dans un registre distribué de stockage (802) ; et dans lequel le protocole de registre distribué de stockage fournit des opérations LECTURE et ECRITURE basées sur un quorum, dirigées vers un registre distribué de stockage (802) comprenant des valeurs (810 à 814) de registre distribué de stockage, stockées localement sur chaque système composant de calcul.
8. Système distribué de stockage de données selon la revendication 7, dans lequel le protocole de registre de stockage distribué, mais mis en mémoire cache localement, fournit des opérations dirigées vers un registre de stockage (2008) distribué, mais mis en mémoire cache localement, incluant, en plus des opérations fournies par le protocole de registre distribué de stockage, une opération LECTURE locale et une opération ECRITURE ETAT; dans lequel l'opération LECTURE locale renvoie une valeur stockée localement (2010) pour le registre de stockage distribué, mais mis en mémoire cache localement, plutôt qu'une valeur basée sur un quorum, pourvu qu'un bail local (2013) pour le registre de stockage distribué, mais mis en mémoire cache localement, soit valide et que le traitement ne soit pas retardé ; dans lequel l'opération ECRITURE ETAT réussit lorsque tous les systèmes composants de calcul (2002 à 2006) mettent à jour leurs valeurs stockées localement pour le registre de stockage (2008) distribué, mais mis en mémoire cache localement, mais lorsque l'un, ou une minorité, des systèmes composants de calcul manquent de mettre à jour leurs valeurs stockées localement pour le registre de stockage distribué, mais mis en mémoire cache localement, les systèmes composants de calcul restants retardent l'utilisation de leurs valeurs mises à jour, stockées localement, pour le registre de stockage distribué, mais mis en mémoire cache localement, jusqu'à ce que les baux de l'un, ou d'une minorité, des systèmes composants de calcul pour le registre de stockage distribué, mais mis en mémoire cache localement, puissent être supposés avoir expiré ; dans lequel une valeur stockée localement (2010) pour le registre de stockage distribué, mais mis en mémoire cache localement, sur chaque système composant de calcul, est rafraîchie périodiquement par une opération LECTURE basée sur un quorum; et dans lequel le protocole de registre de stockage distribué, mais mis en mémoire cache localement, fournit une opération supplémentaire MISE A JOUR ETAT ATOMIQUE (2912) qui permet à un registre de stockage distribué, mais mis en mémoire cache localement, d'être lu et ensuite modifié par un système composant de calcul sans accès intervenant par un autre système composant de calcul quelconque.
9. Système distribué de stockage de données selon la revendication 6, dans lequel une unité d'informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement (704), ou d'informations d'état distribuées, partagées (706), peut comprendre un élément du groupe composé de: un octet; un mot machine; un champ comprenant un certain nombre de mots 30 machine un enregistrement comprenant un certain nombre de mots machine; une structure de données comprenant un certain nombre de mots machine; et un contrôle d'accès comprenant un ou plusieurs octets qui contrôle l'accès à des informations d'état supplémentaires.
10. Système distribué de stockage de données selon la revendication 6, dans lequel l'interface stockage de données cohérente, fournie par le certain nombre de systèmes de stockage de données, utilisant des informations d'état distribuées, partagées, mises en mémoire cache localement, mais cohérentes globalement (704) et des informations d'état distribuées, partagées (706), assure que les effets de commandes émises par des ordinateurs hôtes vers le système distribué de stockage de données sont sérialisés, de manière qu'une commande exécutée ultérieurement n'accède pas à des informations d'état dépassées, modifiées par la suite par une commande exécutée antérieurement.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/099,017 US8392668B2 (en) | 2005-04-04 | 2005-04-04 | Distributed-state-information-based distributed computing systems and methods and protocols for managing distributed state information |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2884632A1 true FR2884632A1 (fr) | 2006-10-20 |
Family
ID=36425095
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0602880A Pending FR2884632A1 (fr) | 2005-04-04 | 2006-04-03 | Systemes distribues de calcul bases sur des informations d'etat distribuees et procedes et protocoles correspondants |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US8392668B2 (fr) |
| FR (1) | FR2884632A1 (fr) |
| GB (1) | GB2424974B (fr) |
Families Citing this family (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7376034B2 (en) * | 2005-12-15 | 2008-05-20 | Stec, Inc. | Parallel data storage system |
| US7774490B2 (en) * | 2007-09-20 | 2010-08-10 | Microsoft Corporation | Crisscross cancellation protocol |
| US8706959B1 (en) * | 2009-06-30 | 2014-04-22 | Emc Corporation | Virtual storage machine |
| US8195909B2 (en) * | 2009-10-05 | 2012-06-05 | Seagate Technology Llc | Data management in a data storage system |
| US8713096B2 (en) | 2011-05-10 | 2014-04-29 | Microsoft Corporation | State control of remote hosts for management of distributed applications |
| US8909816B2 (en) * | 2012-03-19 | 2014-12-09 | Kaminario Technologies Ltd. | Implementing a logical unit reset command in a distributed storage system |
| US10191959B1 (en) * | 2012-06-20 | 2019-01-29 | Amazon Technologies, Inc. | Versioned read-only snapshots of shared state in distributed computing environments |
| US9152458B1 (en) * | 2012-08-30 | 2015-10-06 | Google Inc. | Mirrored stateful workers |
| US20140351151A1 (en) * | 2013-05-23 | 2014-11-27 | International Business Machines Corporation | Providing a lease period determination |
| US9559870B2 (en) | 2013-07-08 | 2017-01-31 | Nicira, Inc. | Managing forwarding of logical network traffic between physical domains |
| US10243848B2 (en) | 2015-06-27 | 2019-03-26 | Nicira, Inc. | Provisioning logical entities in a multi-datacenter environment |
| CN106412045B (zh) * | 2016-09-22 | 2019-08-16 | 中国联合网络通信集团有限公司 | 一种身份信息存储方法及系统 |
| CN110858124B (zh) * | 2018-08-24 | 2021-06-01 | 华为技术有限公司 | 数据迁移方法及装置 |
| US11012511B1 (en) * | 2020-01-14 | 2021-05-18 | Facebook, Inc. | Smart network interface controller for caching distributed data |
| US11088902B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Synchronization of logical network state between global and local managers |
| US11777793B2 (en) | 2020-04-06 | 2023-10-03 | Vmware, Inc. | Location criteria for security groups |
| US11088919B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Data structure for defining multi-site logical network |
| US11394634B2 (en) | 2020-04-06 | 2022-07-19 | Vmware, Inc. | Architecture for stretching logical switches between multiple datacenters |
| US11381456B2 (en) | 2020-04-06 | 2022-07-05 | Vmware, Inc. | Replication of logical network data between global managers |
| US11343227B2 (en) | 2020-09-28 | 2022-05-24 | Vmware, Inc. | Application deployment in multi-site virtualization infrastructure |
| KR20220073998A (ko) * | 2020-11-27 | 2022-06-03 | 에스케이하이닉스 주식회사 | 메모리 시스템 및 메모리 시스템의 동작 방법 |
| US11556441B2 (en) * | 2021-04-16 | 2023-01-17 | EMC IP Holding Company LLC | Data storage cluster with quorum service protection |
| US11874767B2 (en) | 2021-12-15 | 2024-01-16 | Hewlett Packard Enterprise Development Lp | Memory partitions for processing entities |
| US11768772B2 (en) | 2021-12-15 | 2023-09-26 | Hewlett Packard Enterprise Development Lp | Accumulators corresponding to bins in memory |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0447736A1 (fr) * | 1990-03-19 | 1991-09-25 | BULL HN INFORMATION SYSTEMS ITALIA S.p.A. | Système multiprocesseur avec des ressources distribuées et partagées et avec duplication dynamique et sélective de données globales et son procédé |
| US5255369A (en) * | 1984-03-10 | 1993-10-19 | Encore Computer U.S., Inc. | Multiprocessor system with reflective memory data transfer device |
| EP0603801A2 (fr) * | 1992-12-23 | 1994-06-29 | Bull HN Information Systems Inc. | Mémoire partagée géneralisée dans une architecture en grappes pour un système d'ordinateur |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6347361B1 (en) * | 1998-02-17 | 2002-02-12 | International Business Machines Corporation | Cache coherency protocols with posted operations |
| US6330643B1 (en) * | 1998-02-17 | 2001-12-11 | International Business Machines Corporation | Cache coherency protocols with global and local posted operations |
| US6772231B2 (en) * | 2000-06-02 | 2004-08-03 | Hewlett-Packard Development Company, L.P. | Structure and process for distributing SCSI LUN semantics across parallel distributed components |
| US6738868B2 (en) * | 2000-06-10 | 2004-05-18 | Hewlett-Packard Development Company, L.P. | System for minimizing directory information in scalable multiprocessor systems with logically independent input/output nodes |
| US6675265B2 (en) * | 2000-06-10 | 2004-01-06 | Hewlett-Packard Development Company, L.P. | Multiprocessor cache coherence system and method in which processor nodes and input/output nodes are equal participants |
| US8949471B2 (en) * | 2000-11-02 | 2015-02-03 | Oracle America, Inc. | TCP/UDP acceleration |
| US6763436B2 (en) * | 2002-01-29 | 2004-07-13 | Lucent Technologies Inc. | Redundant data storage and data recovery system |
-
2005
- 2005-04-04 US US11/099,017 patent/US8392668B2/en active Active
-
2006
- 2006-04-03 GB GB0606614A patent/GB2424974B/en active Active
- 2006-04-03 FR FR0602880A patent/FR2884632A1/fr active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5255369A (en) * | 1984-03-10 | 1993-10-19 | Encore Computer U.S., Inc. | Multiprocessor system with reflective memory data transfer device |
| EP0447736A1 (fr) * | 1990-03-19 | 1991-09-25 | BULL HN INFORMATION SYSTEMS ITALIA S.p.A. | Système multiprocesseur avec des ressources distribuées et partagées et avec duplication dynamique et sélective de données globales et son procédé |
| EP0603801A2 (fr) * | 1992-12-23 | 1994-06-29 | Bull HN Information Systems Inc. | Mémoire partagée géneralisée dans une architecture en grappes pour un système d'ordinateur |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2424974A (en) | 2006-10-11 |
| US20060221720A1 (en) | 2006-10-05 |
| GB0606614D0 (en) | 2006-05-10 |
| US8392668B2 (en) | 2013-03-05 |
| GB2424974B (en) | 2009-07-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2884632A1 (fr) | Systemes distribues de calcul bases sur des informations d'etat distribuees et procedes et protocoles correspondants | |
| US9690679B2 (en) | Transaction commitment and replication in a storage system | |
| US11086555B1 (en) | Synchronously replicating datasets | |
| US11716385B2 (en) | Utilizing cloud-based storage systems to support synchronous replication of a dataset | |
| US11677687B2 (en) | Switching between fault response models in a storage system | |
| US11539793B1 (en) | Responding to membership changes to a set of storage systems that are synchronously replicating a dataset | |
| US9172750B2 (en) | Cluster-node load balancing in a distributed database system | |
| US10848464B2 (en) | System for managing communication ports between servers | |
| US10373247B2 (en) | Lifecycle transitions in log-coordinated data stores | |
| US20160085772A1 (en) | Automated configuration of log-coordinated storage groups | |
| US20180004777A1 (en) | Data distribution across nodes of a distributed database base system | |
| GB2421101A (en) | Distributed lock and protocol | |
| US7072912B1 (en) | Identifying a common point in time across multiple logs | |
| FR2991074A1 (fr) | Procede, dispositif et programme d'ordinateur de controle dynamique de distances d'acces memoire dans un systeme de type numa | |
| Estrada et al. | The broker: Apache kafka | |
| US11853177B2 (en) | Global entity distribution | |
| US20230353635A1 (en) | Replication Utilizing Cloud-Based Storage Systems | |
| US11003684B1 (en) | Cooperative log application | |
| FR3050845A1 (fr) | Gestion de l'acces a des donnees dans un systeme de stockage | |
| Martella et al. | Giraph architecture | |
| Almeida | Geo-replication in large scale cloud computing applications | |
| Konstantinov | Automated Web Application Monitoring | |
| Watkins et al. | Ceph: An Open-Source Software-Defined Storage Stack |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 11 |
|
| TP | Transmission of property |
Owner name: HEWLETT PACKARD ENTREPRISE DEVELOPMENT LP, US Effective date: 20160819 |