Tromos : a software development kit for virtual storage systems Fotios Nikolaidis To cite this version: Fotios Nikolaidis. Tromos : a software development kit for virtual storage systems. Other [cs.OH]. Université Paris-Saclay, 2019. English. NNT : 2019SACLV033. tel-02443225 HAL Id: tel-02443225 https://tel.archives-ouvertes.fr/tel-02443225 Submitted on 17 Jan 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Tromos: A Software Development Kit for virtual storage systems Thèse de doctorat de l’Université Paris-Saclay préparée à Université de Versailles-Saint-Quentin-en-Yvelines Ecole doctorale n◦580 Sciences et technologies de l’information et de la NNT : 2019SACLV033 communication (STIC) Spécialité de doctorat: Informatique Thèse présentée et soutenue à Versailles, le 22/May/2019, par M. FOTIOS NIKOLAIDIS Composition du Jury : Mickael Krajecki Professeur, Université de Reims Présidente, Rapporteur William Jalby Professeur, Université de Versailles Directeur de thèse Soraya Zertal MCF/HDR, Université de Versailles co-encadrant de thèse Philippe Deniel CEA/DAM, Bruyere le chatel co-encadrant de thèse Maria Perez Professeur, Université de Madrid Rapporteur Jacques Jorda MCF/HDR, Université de Toulouse Examinateur Denis Barthou Professeur, Université de Bordeaux Examinateur Gael Thomas Professeur, Telecom Sud Paris Examinateur 1 2 Titre: Tromos: un cadre pour la construction de systèmes de stockage distribués Mots clés: Blob storage, Stockage distribué, Stockage sur le nuage, Storage containers Résumé: Parmi la mise à l’échelé, la portabil- application. Une telle conception aide à re- ité, la distribution du charge de travail, et autres porter les décisions d’I/O jusqu’à la phase de dé- raisons, les applications vont bénéficier la plate- ploiement, qui est la clé de la Transférabilité ; forme du stockage des données qui present le de la sécurité de l’autorité la moins élevée ; de code le plus efficace. Cela, cependant, n’est pas la fédération des fournisseurs de stockage non- trivial. Chaque plateforme aboutie aux accom- collaboratif; de l’échelle d’application de deux- plissements diversifiés and, par conséquent, elle ième ordre indépendante au stockage de don- requiert le rôle d’une application pour achever nées ; et la distribution de données des règles plusieurs chemins de codage. L’implémentation avec des critères comme la résilience, le ren- des tels chemins n’est pas évidente. Elle re- dement, l’efficacité du stockage et le coût. Le quiert une grand effort, des hautes compé- fait qu’un tel logiciel intermédiaire soit « per- tences de programmation et suivant elle con- sonnalisé » à l’application, signifie également tient un fort risque des erreurs. Les problèmes que chaque application doit mettre en œuvre sa se présentent quand les applications doivent de "saveur". Pour ce faire, nous introduisons un supporter plusieurs stockages des données en SDK, appelé Tromos, pour les développeurs, afin parallèle. Dans cette dissertation, on introduit de synthétiser des systèmes de stockage dis- le terme "storage containers" comme une évo- tribués personnalisés sans programmation des lution naturelle du stockage des donées. Les systèmes. Tout ce qu’il faut aux développeurs "storage containers" sont des application inter- est de modéliser l’environnement souhaité dans médiaires de gestion des données qui sépare un fichier de définition. Le SDK va gérer le reste la logique d’I/O de la logique d’affaires et la du processus. Il est distribué avec une large logique de computations d’une application. Dans gamme de plugins intégrés pour le traitement des cette thèse, nous introduisons le terme « ré- I/O, le traitement des requêtes, les algorithmes cipients de stockage » comme la prochaine de sélection, les méthodes de reconstruction de logique dans l’évolution du stockage. Il s’agit données, le traitement de cohérence, et la vi- d’un logiciel intermédiaire de gestion des don- sualisation. Pour faire une analogie, "storage nées qui sépare la logique d’I/O de la logique containers" découplent la gestion des données métier et de calcul d’une application. Autrement de la plateforme de stockage physique de la dit, ils séparent les changements apportés au même manière que les containers Docker décou- code des applications par les utilisateurs scien- plent l’environnement d’application des serveurs tifiques des changements apportés aux actions physiques. En guise de démonstration de fais- d’I/O par les développeurs ou les administra- abilité, nous utilisons Tromos pour prototyper des teurs. Contrairement aux systèmes « à usage environnements de stockage personnalisés que général » existants, dont l’objectif est d’effectuer nous comparons à Gluster, un système à us- « décemment » pour le plus grand nombre pos- age général appartenant à RedHat. Les résultats sible d’applications, les systèmes « application- ont montré que les environnements auto-produits tailored » conservent la connaissance et ne fonc- surpassent Gluster simplement en enlevant toute tionnent de façon optimale que pour une seule fonctionnalité inutile de la ligne de stockage. 3 Title: Tromos: A Software Development Kit for virtual storage systems Keywords: Blob storage, Distributed storage, Cloud Storage, Storage containers Abstract: application codes by science users from changes Modern applications tend to diverge both in the made to I/O actions by developers or administra- I/O profile and storage requirements. Match- tors. ing a scientific or commercial application with To facilitate the development and deployment of a general-purpose system will most likely yield a “storage container" we introduce a framework suboptimal performance. Even in the presence called Tromos. Through its lens, all that it takes of “purpose-specific” systems, applications with for an application architect to spin-up a custom multiple classes of workloads are still in need storage solution is to model the target environ- to disseminate the workload to the right system. ment into a definition file and let the framework This strategy, however, is not trivial as differ- handles the rest. Tromos comes with a repos- ent platforms aim at diversified goals and there- itory of plugins which the architect can choose fore require the application to incorporate multi- as to optimize the container for the application at ple codepaths. Implementing such codepaths is hand. Available options include data transforma- non-trivial, requires a lot of effort and program- tions, data placement policies, data reconstruc- ming skills, and is error-prone. The hurdles are tion methods, namespace management, and on- getting worse when applications need to lever- demand consistency handling. age multiple data-stores in parallel. In this disser- As a proof-of-concept we use Tromos to proto- tation, we introduce “storage containers" as the type customized storage environments which we next logical in the storage evolution. A “storage compare against Gluster; a “general-purpose” container" is virtual infrastructure that decouples system owned by RedHat. The results showed the application from the underlying data-stores in that the auto-produced environments outperform the same way Docker decouples the application the more mature Gluster by merely removing the runtime from the physical servers. In other words, unnecessary overhead of unused features. it is middleware that separate changes made to Université Paris-Saclay Espace Technologique / Immeuble Discovery Route de l’Orme aux Merisiers RD 128 / 91190 Saint-Aubin, France One picture, a thousand thanks !!!! This dissertation is dedicate to our friend Dimitris Ganosis 4 Contents 1 One picture, a thousand thanks !!!! 4 1 Introduction 2 1.1 Block Devices . .2 1.2 Filesystems . .3 1.2.1 VFS . .4 1.2.2 POSIX limitations . .5 1.3 Object-based Storage . .9 1.4 Data stores . 11 1.4.1 Cluster . 12 1.4.2 Grid . 13 1.4.3 Cloud . 13 1.5 Designing scalable data-stores . 14 1.5.1 CAP theorem . 15 1.5.2 BASE model . 15 2 Application-tailored storage 18 2.1 Application-tailored storage system . 20 2.1.1 Portability . 21 2.1.2 Federated Storage Toolkit . 21 2.1.3 Second-order management . 23 2.2 SDK for distributed storage systems . 24 5 CONTENTS 6 2.2.1 Components . 26 2.2.2 Virtual Storage Infrastructure . 27 3 Programmable Devices 29 3.1 Objectives . 29 3.1.1 Portability . 29 3.1.2 Differentiated Content access . 30 3.2 Device Driver Synthesis . 31 3.2.1 Modeling Language . 31 3.3 Device Runtime . 35 3.3.1 Channels . 35 3.3.2 Streams . 37 3.3.3 I/O Phase . 39 3.4 Summary . 41 3.4.1 Related Work . 41 4 Programmable I/O Processors 43 4.1 Objectives . 43 4.1.1 In-transit processing . 43 4.1.2 Data Distribution . 44 4.1.3 Bidirectional streams . 44 4.2 Driver Synthesis . 44 4.2.1 Processing kernels . 46 4.2.2 Graph . 51 4.3 Driver Runtime . 54 4.3.1 Network Ports . 54 4.3.2 Federated Network Discovery . 55 4.4 Summary . 56 4.4.1 Related Work . 57 5 Programmable Coordinators 59 5.1 Objectives . 59 CONTENTS 7 5.1.1 Metadata Catalog . 59 5.1.2 Distributed Synchronization . 60 5.2 Driver Synthesis . 60 5.2.1 Modeling Language . 61 5.3 Driver Runtime . 63 5.3.1 Update Transaction . 64 5.3.2 Ordering . 65 5.3.3 Leases over locks . 65 5.3.4 Heartbeat . 65 5.3.5 View Transactions . 67 5.3.6 Update Record Masking . 67 5.4 Summary . 69 5.4.1 Related Work .