3.3.2. Architecture
de Swift :
Swift abstrait complètement l'organisation logique des
données -précédemment présentée- de
l'organisation physique [39]. Nous commençons par examiner
l'organisation physique des données, puis la façon dont Swift
assure la circulation des données.
3.3.2.1. L'organisationphysique du service Swift :
Swift classe l'emplacement physique dans une
hiérarchie, en effet la région et au sommet suivi des zones puis
des serveurs de stockage ensuite des disques, comme illustré dans la
figure suivante :
Serveur
Région
Figure 20 : Organisation
physique du service Swift[39]
- La région : Au niveau le plus
élevé, Swift stocke les données dans des régions
géographiquement séparées et qui souffrent donc d'un lien
à latence élevée. Un utilisateur ne peut utiliser qu'une
seule région, par exemple, si le cluster n'utilise qu'un seul centre de
données[39].
- La zone : au sein des régions,
il existe des zones. Les zones sont un ensemble de noeuds de stockage qui
partagent différentes caractéristiques de disponibilité.
La disponibilité peut être définie comme différents
bâtiments physiques, sources d'alimentation ou connexions réseau.
Cela signifie qu'une zone peut être un serveur de stockage unique, un
rack ou un centre de données complet en fonction de vos besoins. Les
zones doivent être connectées entre elles via des liens à
faible latence. Rackspace recommande d'avoir au moins cinq zones par
région[39].
- Les serveurs de stockage : Une zone
est constituée d'un ensemble de serveurs de stockage allant d'un seul
à plusieurs racks[39].
- Les disques (ou périphériques)
: les lecteurs de disque font partie d'un serveur de stockage. Ceux-ci
peuvent être à l'intérieur du serveur ou connectés
via un JBOD[39].
3.3.2.2. Architecture logique du service Swift:
Swift est un système de stockage deux-tiers
composé d'un niveau proxy, qui gère toutes les demandes
entrantes, et d'un niveau de stockage d'objets où les données
réelles sont stockées. Swift utilise une structure de
données appelée « anneau » pour acheminer
l'URL d'un objet vers un emplacement particulier dans le cluster où
l'objet est stocké. La figure suivante montre Les composants de
Swift.
Figure 21 : Architecture
logique du service Swift [40]
- Le serveur :
o Swift-Proxy : accepte les requêtes
entrantes via soit l'API d'objets OpenStack, ou simplement le HTTP brut. Il
accepte les téléchargements de fichiers, des modifications de
métadonnées ou la création de conteneurs. De plus, il sert
également des fichiers ou des listes de conteneurs au navigateur Web. Le
serveur proxy peut également s'appuyer sur éventuellement sur le
cache, qui est généralement déployé avec Memcached
qui améliore les performances.
o Swift-account : gère le compte qui
est défini avec l'objet service de stockage. Il décrit son propre
descriptif (métadonnées) et la liste des conteneurs du compte.
o Swift-container : gère un mappage
des conteneurs dans le compte serveur. Un conteneur fait
référence à la zone de stockage définie par
l'utilisateur dans un compte serveur, il définit une liste d'objets
stockés dans le conteneur. Un conteneur peut être conceptuellement
similaire à un exemple de dossier dans un système de fichiers
traditionnel.
o Swift-object : gère un objet
réel au sein d'un conteneur, stocke les données des objets et
leurs métadonnées. L'objet doit appartenir à un
conteneur[34].
- Les backends
o Base de données
« Account » : Stocke les informations des
comptes.
o Base de données
« Container » : Stocke les informations des
conteneurs.
o Base de données
« Object » : Stocke les informations des
objets.
| 
