TL; DR: L'équipe Bloomberg Storage Engineering a créé un stockage cloud à usage interne qui n'interfère pas avec l'infrastructure et peut résister à la lourde charge de volatilité des échanges pendant la pandémie.
Mattew Leonard, lorsqu'il parle de son travail en tant que responsable technique au sein de l'équipe Bloomberg Storage Engineering, utilise souvent les mots « stimulant » et « amusant ». Les défis proviennent de la vaste gamme de stockage, des dernières baies SAN basées sur NVMe au stockage défini par logiciel open source dans DevOps. C'est là que le « fun » commence (voir mon avatar sur Habré, environ. traducteur).
Leonard et son équipe de 25 collègues supervisent plus de 100 pétaoctets de capacité et un cloud interne pour 6000 XNUMX ingénieurs développant des applications pour Bloomberg Terminal, la technologie qui a fait de Michael Bloomberg un milliardaire. L'équipe conçoit, construit et entretient des systèmes de stockage pour Bloomberg Engineering.
Comme pour le reste de la profession informatique, 2020 a été une année inhabituelle pour les membres de l’équipe Storage Engineering, car la COVID-19 les a contraints à travailler à distance. Leonard a déclaré que la pandémie avait eu un impact social sur son « équipe soudée » puisque les interactions en face à face avaient été éliminées, mais que le personnel s’était adapté très rapidement au travail à domicile sur des ordinateurs portables et à la vidéoconférence.
Étonnamment, je tiens à dire que cela n’a pas aggravé la situation. Il y a eu une courte période d’adaptation – tout le monde n’était pas prêt à travailler à domicile. Au bout d’une semaine ou deux, tout le monde l’a compris. Nous avons pu trouver des moyens de nous occuper, d’acheter et de mettre à niveau des équipements et d’augmenter les coûts pour soutenir l’entreprise pendant ces périodes. Nous avons dû faire preuve de créativité, mais nous n'avons pas été blessés
Le plus grand défi est peut-être antérieur au pic de la COVID-19. Cela était dû à la volatilité des échanges sur le marché en raison des inquiétudes concernant l'impact de la pandémie sur l'économie mondiale. Le volume de données entrant dans les terminaux Bloomberg en provenance des marchés financiers mondiaux a presque doublé, atteignant 240 milliards d'informations certains jours fin mars. Il s'agit d'un test sérieux des systèmes de stockage.
Lorsque vous doublez instantanément vos besoins de stockage en une journée, cela crée des problèmes intéressants. Nous avons pu surmonter ce problème et garantir que les équipes de développement d’applications disposaient de l’espace et des performances dont elles avaient besoin. Cela dépend en grande partie de la manière dont nous envisageons les systèmes de stockage. Aujourd’hui, nous ne créons rien. Nous ne disons pas : « Nous utilisons ABC, nous allons donc construire l'infrastructure pour ABC ». Nous effectuons ce que nous appelons la « budgétisation des données » avec nos équipes pour prévoir l'utilisation, analyser les tendances d'utilisation et de performances, et nous examinons également la sécurité. Ce type de planification, de réflexion et de diligence raisonnable méthodique nous permet de prendre des mesures drastiques face aux surtensions sans transpirer. Bien sûr, j’étais nerveux, mais je me sentais à l’aise d’être à ma place.
Leonard a récemment parlé en détail avec SearchStorage de la gestion du stockage pour les entreprises basées sur les données. Il a expliqué ce qu'il faudrait pour proposer une solution de stockage dans un cloud privé, avec la possibilité de fournir des fonctionnalités AWS à ses utilisateurs tout en conservant toutes les données dans les centres de données Bloomberg.
S’il n’y a plus de pandémie, quelles difficultés rencontrent les ingénieurs de Bloomberg dans la gestion du stockage ?
Nous avons de nombreux besoins, nous sommes simplement tiraillés dans des directions différentes. Nous devons donc proposer de nombreux types de produits différents à différents niveaux de SLA pour aider nos développeurs d'applications à se concentrer sur leurs tâches au lieu de se soucier du stockage lui-même.
Et quelle stratégie suivez-vous pour cela ?
Une partie de ce que nous essayons de faire consiste à améliorer les performances de stockage. Pensez au modèle AWS dans lequel un ingénieur de développement entre, appuie sur un bouton, puis « clique » pour obtenir comme par magie le bon type de stockage pour résoudre son problème.
À quoi ressemble votre infrastructure de stockage ?
Parce que nous avons un écosystème très diversifié et de nombreux développeurs différents, nous ne pouvons pas proposer un seul produit. Nous avons un stockage d'objets, de fichiers et de blocs. Ce sont des produits différents et nous proposons différents types de technologies pour les livrer. Pour le bloc, nous utilisons SAN. Nous avons également SDS, qui offre une autre option de stockage en bloc avec un ensemble différent d'exigences de performances. Pour les fichiers, nous utilisons NFS. SDS est également utilisé pour le stockage d'objets. Les parties bloc et objet forment un cloud privé interne pour le calcul et le stockage.
Vous n’utilisez donc pas de stockage cloud public ?
C'est exact. Certaines équipes de développement sont autorisées à utiliser des cloud publics. Mais en raison de la nature de notre activité, nous préférons avoir plus de contrôle sur ce qui sort de nos murs. Alors oui, nous avons nos propres nuages sous notre contrôle. Il s’agit d’équipements situés dans notre centre de données sous notre gestion.
Dans nos datacenters, nous privilégions une stratégie multi-fournisseurs. Ce sont de gros fournisseurs, mais nous ne dirons pas qui exactement (c'est la politique de Bloomberg de ne soutenir aucun fournisseur, environ. traducteur).
Utilisez-vous une infrastructure hyperconvergée pour créer votre cloud privé ?
Non. Chez Bloomberg, nous choisissons une direction dans laquelle nous n’allons pas vers l’hyperconvergence. Nous essayons de dissocier le calcul du stockage afin de pouvoir les faire évoluer indépendamment. La direction dans laquelle nous avançons, en particulier avec notre cloud, est de pouvoir séparer ces deux entités. Et tout cela parce que certaines choses dans notre pays nécessitent des calculs intensifs, tandis que d'autres nécessitent du stockage. Si vous les adaptez de manière uniforme, vous perdrez des ressources, peu importe l'argent ou l'espace dans les centres de données, ou en achetant de la capacité dont vous n'avez pas besoin. C'est pourquoi nous aimons avoir une interface commune entre les deux entités, mais qu'elles soient des systèmes complètement différents et gérées par des équipes différentes.
Quels obstacles faut-il surmonter pour construire un cloud privé ?
Problème d'échelle. Comme pour la plupart des choses, le diable se cache dans les détails. Quand on réfléchit à la façon dont ces choses fonctionnent, comment les rendre résilientes, comment gérer la charge opérationnelle, comment vous communiquez avec les équipes chargées des actifs physiques, les choses deviennent un peu intéressantes. Le défi est de trouver un moyen de faire de tout un produit évolutif et supportable que nos développeurs d'applications voudraient utiliser, en étant capables d'enrichir l'ensemble des fonctionnalités tout en restant à la pointe de ce que fait le cloud public. Et aussi de rassembler le tout pour que ça continue à fonctionner. C'est notre principal problème : nous travaillons dans tous les domaines de l'entreprise, en essayant de satisfaire tous les besoins, mais sans ignorer les autres.
Pensez-vous avoir besoin des dernières fonctionnalités disponibles dans AWS et d'autres cloud publics ?
Le fait le plus amusant à propos de S3 est que le niveau de vie évolue constamment et que de nouvelles fonctionnalités sont toujours ajoutées. C'est comme un nouveau jouet. Si quelqu’un voit une nouvelle fonctionnalité dans une nouvelle version, il la souhaite. Toutes les fonctionnalités AWS ne sont pas applicables dans notre environnement, il est donc important et intéressant de savoir ce qui aidera les développeurs et comment les obtenir en interne.
Quel matériel de stockage utilisez-vous ?
Nous utilisons les derniers équipements. Notre cloud interne est entièrement basé sur NVMe Flash, ce qui rend ces systèmes très puissants. Cela nous facilite un peu la vie et constitue également une fonctionnalité intéressante pour nos développeurs, car ils n'ont pas à se soucier des performances de stockage.
À quoi sert le stockage objet ?
Nous avons 6000 XNUMX développeurs travaillant sur l’infrastructure, ils ne sont unis par aucun cas d’utilisation unique. Quelle que soit l'option à laquelle vous pouvez penser, nous l'avons probablement dans le stockage d'objets. Certaines équipes l'utilisent pour le stockage d'archives à froid, d'autres pour le transfert de données et d'autres encore pour des applications transactionnelles. Tous ces cas d'utilisation nécessitent différents niveaux de SLA. Comme vous pouvez le constater, nous avons différents types de trafic, toutes sortes de besoins pour les différents utilisateurs de notre infrastructure. Il ne s’agit pas d’un cas d’utilisation homogène s’exécutant sur aucun de nos stockages, ce qui rend évidemment les choses plus complexes.
Quel rôle Kubernetes et les conteneurs jouent-ils pour vous, et quel impact cela a-t-il sur le stockage ?
Nous améliorons la productivité du stockage pour créer une impression de cloud, une impression de quelque chose en tant que service, où il existe un bouton permettant aux développeurs d'accélérer leur travail et de supprimer l'infrastructure en cours de route.
N.b. de l'éditeur: le 15 octobre 2020 sera prêt . Vous apprendrez la technologie de stockage réseau Ceph à utiliser dans vos projets pour améliorer la tolérance aux pannes.
Nous avons trois équipes, la première est l'équipe API de stockage. Ils créent des accès programmatiques, des points de terminaison et des flux de travail prédéfinis pour les clients de développement d'applications chez Bloomberg. Il s'agit d'une équipe de développeurs Web full stack, ils utilisent node.js, python, des technologies open source, comme Apache Airflow, ils étudient donc la conteneurisation et la virtualisation.
Nous disposons également de deux équipes techniques qui déplacent les bits et les octets. Ils sont plus directement liés à l’équipement. Nous disposons de beaucoup d'équipements et ces équipes n'utilisent pas de virtualisation ni de conteneurs.
Nous essayons de suivre ce qui se passe dans l'industrie, en étudiant les pilotes Kubernetes CSI et en travaillant également en étroite collaboration avec l'équipe de mise en œuvre de Kubernetes chez Bloomberg pour évaluer si nous pouvons faire en sorte que le stockage Kubernetes fonctionne de manière cohérente avec les technologies dont nous disposons, et nous avons ça marche. Nous utilisons SDS pour prendre en charge Kubernetes connecté au stockage persistant. Nous avons développé avec succès cette technologie et les discussions se poursuivent entre les deux équipes sur la manière dont nous pouvons la rendre accessible à tous les autres collaborateurs de Bloomberg. Nous avons montré que cela est tout à fait possible.
Quels autres logiciels open source utilisez-vous, notamment pour le stockage ?
Nous utilisons Apache Airflow, HAProxy pour limiter le trafic applicatif. Nous utilisons également Ceph, une plateforme pour SDS. Avec lui, vous pouvez avoir un seul système pour les commandes, mais fournir plusieurs interfaces aux clients. L'une des plates-formes de virtualisation fonctionne sur OpenStack - nous travaillons en étroite collaboration avec cette équipe. Nous disposons d'une plateforme de virtualisation open source qui utilise la plateforme open source SDS pour le stockage. C'est marrant.
Quelles technologies de stockage envisagez-vous pour les deux à trois prochaines années ?
Nous sommes toujours à la recherche d'autres nouveautés intéressantes qui se produisent dans l'industrie du stockage. Cela fait partie de notre travail, ce n’est pas « voici votre SAN, gérez ici, et voici votre NFS, gérez là ». Nous essayons de communiquer avec nos clients, c'est-à-dire par nos développeurs d'applications. Nous travaillons ensemble pour comprendre quels problèmes ils tentent de résoudre et quel impact cela aura sur nos clients externes de Bloomberg - les banques et autres qui utilisent notre logiciel. Et puis nous retournons dans le monde du stockage de données pour trouver des opportunités pour les aider à atteindre leur objectif. Comment pouvons-nous les aider à trouver la technologie de stockage adaptée à leur SLA ou à ce qu'ils tentent de faire ? Parce que nous avons tellement d’ingénieurs qui font des choses sympas, cela ne devient jamais ennuyeux.
Nous étudions actuellement des moyens d'améliorer les performances de SDS qui pourraient potentiellement fonctionner sur des serveurs à usage général. Nous travaillons donc sur NVMe sur TCP, c'est une initiative très intéressante et sympa, une parmi tant d'autres. Nous travaillons également avec des personnes clés de l'industrie et certains des fournisseurs existants pour découvrir ce qu'ils proposent et quelles seront leurs performances réelles, si nous pouvons commencer à l'utiliser dans la production de l'entreprise. Cela ouvre de nouveaux horizons qui n’étaient pas accessibles auparavant.
Un peu d'aide en PS
PS Si vous me le permettez, je voudrais vous rappeler que du 28 au 30 septembre aura lieu , pour ceux qui ne connaissent pas Kubernetes, mais souhaitent se familiariser avec lui et commencer à travailler avec.
Source: habr.com