En bas, nous avons le matériel, au-dessus se trouve un niveau de virtualisation, puis le système d'exploitation, l'environnement d'exécution, etc. Et si tout devient clair à partir du niveau du système d'exploitation, ce qui se passe en dessous est souvent enveloppé de mystère. En général, les serveurs, le stockage, les réseaux - ce n'est pas quelque chose de nouveau, mais comment tout cela se transforme en machines virtuelles ensemble est une grande question.

Discutons ensemble de la façon dont cela peut fonctionner. Je ne suis pas un grand spécialiste des problèmes de virtualisation, donc tout ce qui est en dessous est purement mes suppositions.

Donc. Disons que nous avons un grand serveur. Il peut être composé de plusieurs "unités de calcul" contenant de nombreux processeurs et beaucoup de mémoire. Les disques durs, par exemple, sont installés dans une "unité de stockage" séparée et partagés d'une manière ou d'une autre entre les unités de calcul. De plus, il devrait y avoir plus de "unités réseau" pour le réseau. Et bien sûr, un bloc avec un GPU. De plus, tout cela doit être alimenté, mais laissez les blocs d'alimentation être intégrés aux blocs fonctionnels. Cela semble être l'ensemble minimum requis pour que le serveur fonctionne.

En fait, cette division en unités est purement logique. Physiquement, tout cela peut être soit une seule carte dans un boîtier (similaire à la façon dont un ordinateur de bureau ou un ordinateur portable est disposé) soit beaucoup de cartes combinant des éléments logiques de l'une ou l'autre manière. Et habituellement, tout cela est physiquement placé dans une baie de serveur. Eh bien, il peut y avoir beaucoup de telles baies. Donc, cela pourrait ressembler à ça

ou comme ceci

Ressentez-vous la beauté de cela ? :)

Donc, le schéma de la partie matérielle devrait ressembler à ceci:

En résultat, nous avons un ordinateur très puissant qui doit avoir un système d'exploitation installé dessus, ce qui nous permettrait d'utiliser toutes nos ressources matérielles. En général, le type de système d'exploitation n'est pas si important ici car essentiellement, il agira comme une couche entre nos ressources matérielles et le logiciel spécial qui permettrait le fonctionnement des machines virtuelles. Cependant, personnellement, je choisirais d'installer Linux :)

Appelons ce logiciel - un système de virtualisation. Il existe plusieurs de ces systèmes, mais à mon avis, les plus connus sont VMWare, Hyper-V et KVM. Si vous êtes intéressé, vous pouvez en apprendre davantage sur eux (il y a un grand monde de technologies extrêmement intéressantes sur le fonctionnement de la virtualisation avec les ressources matérielles), mais je vais me concentrer sur le fait que ces systèmes peuvent faire la chose la plus importante pour nous - créer des machines virtuelles, en utilisant les ressources matérielles du serveur sur lequel ils fonctionnent. Et pas seulement les créer, mais le faire de manière à ce que les machines virtuelles ne se connaissent pas et ne puissent pas "intruder" dans les ressources de chacune, même si elles seront effectivement exécutées sur les mêmes CPU et partagent la même RAM. C'est le principal "pilier" sur lequel reposent tous les clouds. En réalité, bien sûr, tout est plus compliqué, et il y aura beaucoup plus de choses en cours d'exécution dans le système d'exploitation du serveur, mais nous nous concentrerons sur les aspects les plus importants.

Dans Azure, avec son échelle, une combinaison de systèmes de virtualisation est très probablement utilisée. Il serait étrange que Microsoft elle-même n'utilise pas Hyper-V, mais il serait également étrange d'ignorer les avantages de KVM :)

Donc, les systèmes de virtualisation sont capables de créer, modifier et détruire des machines virtuelles. Mais qui et comment leur diront quand et quelle machine virtuelle créer et sur quel serveur ? C'est là que les principaux composants du cloud entrent en jeu : les orchestrators de calcul, de réseau et de stockage. Pourquoi spécifiquement ceux-ci ? Parce qu'ils sont les trois composants les plus importants de la couche IaaS. (Même les GPU ici ressemblent à une petite option :)

• L'orchestrateur de calcul gère les machines virtuelles sur lesquelles littéralement tout fonctionne dans le cloud.
• L'orchestrateur réseau gère les routeurs qui fournissent une connectivité réseau physique entre les serveurs, les racks, les centres de données, etc. Cet orchestrateur gère également l'équilibrage de charge et les problèmes de routage du trafic.
• L'orchestrateur de stockage gère les matrices de stockage, allouant des ressources pour les machines virtuelles et les services de niveau supérieur (comme le stockage Azure).

Un orchestrateur est déjà quelque chose comme des services "cloud" au sein d'un service "cloud". Il doit avoir un point de terminaison interne, un système d'authentification et une API REST afin qu'il puisse être sollicité pour exécuter une commande particulière. Mais où l'orchestrateur stockera-t-il la configuration actuelle des ressources ? Bien sûr, elle pourrait être stockée dans un blob quelque part dans la matrice de stockage, mais je choisirais une base de données très fiable capable de s'étendre au niveau de l'ensemble du cloud. Supposons qu'il s'agisse d'une installation interne de Cosmos DB.

Mais maintenant, nous avons une autre question. Où tout cela fonctionne-t-il ? C'est là que le terme "Dogfooding" entre en jeu. L'idée est qu'à l'intérieur de votre système, vous devriez utiliser des composants du système lui-même. En d'autres termes, si nous permettons à nos utilisateurs de travailler avec des machines virtuelles, pourquoi ne pas utiliser les mêmes machines virtuelles pour nos propres besoins ? Par conséquent, supposons que tous les services internes (orchestrateurs et stockage de métadonnées) fonctionnent sur des machines virtuelles ordinaires créées par le système de virtualisation qu'ils sont conçus pour gérer.

Ainsi, notre schéma est maintenant légèrement compliqué:

Il semble que cela soit déjà possible de travailler avec tout cela. Nous avons des services auxquels nous pouvons demander de créer des machines virtuelles, de configurer un réseau et d'allouer de l'espace pour stocker des données. Mais comment déterminons-nous qui a le droit de donner des ordres et qui ne l'a pas ? Exactement, nous avons besoin d'un service qui serait responsable de la gestion de l'identité et de l'accès. Dans Azure, toute une combinaison d'entités fonctionne ici - Azure Active Directory, RBAC, différents types d'identité, etc., mais pour simplifier, nous les regrouperons tous en un seul. Et nous ajouterons également un service pour collecter des informations de surveillance (sinon, comment pouvons-nous comprendre ce qui se passe à l'intérieur de notre cloud et comment évaluer qui a dépensé combien de ressources), ainsi qu'un service qui calculera combien d'argent nos clients doivent nous payer.

De plus, personnellement, j'ajouterais un autre service qui gère de manière centralisée l'accès à l'API REST pour les services internes et externes de notre cloud conformément aux règles établies par notre service de gestion de l'identité et de l'accès.

Maintenant, notre structure est encore plus complexe.

J'ai peut-être omis quelque chose, mais il semble qu'en général, cela soit suffisant pour nous permettre d'ajouter de nombreux services "externes" pour les utilisateurs (par exemple, des bases de données PaaS, divers types de stockage, sans serveur, IoT, etc.).

Voyons si nous répondons à tous les critères du cloud public de la définition du NIST:

On-demand self-service. Un consommateur peut provisionner unilatéralement des capacités informatiques, telles que le temps de serveur et le stockage réseau, selon les besoins, automatiquement et sans interaction humaine avec chaque fournisseur de service.
Oui. Grâce au service API, tout utilisateur peut gérer de manière centralisée et indépendante nos ressources.

Broad network access. Les capacités sont disponibles via le réseau et sont accessibles via des mécanismes standard qui favorisent l'utilisation par des plates-formes clientes minces ou épaisses hétérogènes (par exemple, téléphones mobiles, tablettes, ordinateurs portables et postes de travail).
Oui, notre orchestrateur réseau assure la connectivité multiplateforme de toutes les ressources chez l'utilisateur.

Resource pooling. Les ressources informatiques du fournisseur sont mutualisées pour servir plusieurs consommateurs selon un modèle multi-locataire, avec différentes ressources physiques et virtuelles attribuées et réattribuées dynamiquement en fonction de la demande du consommateur.
Oui, nos orchestrateurs de calcul et de stockage veillent à ce qu'une seule couche matérielle soit partagée par tous les utilisateurs.

Rapid elasticity. Les capacités peuvent être provisionnées et libérées de manière élastique, parfois automatiquement, pour se développer et se contracter rapidement en fonction de la demande. Pour le consommateur, les capacités disponibles pour la provision apparaissent souvent comme illimitées et peuvent être appropriées en toute quantité à tout moment.

Oui, grâce à nos orchestrateurs et à notre système de virtualisation, nous pouvons modifier la configuration à la volée.

Measured service. Les systèmes cloud contrôlent et optimisent automatiquement l'utilisation des ressources en tirant parti d'une capacité de mesure à un certain niveau d'abstraction approprié au type de service (par exemple, stockage, traitement, bande passante et comptes utilisateur actifs). L'utilisation des ressources peut être surveillée, contrôlée et rapportée, offrant ainsi une transparence à la fois pour le fournisseur et le consommateur du service utilisé.

Oui, les systèmes de journalisation, de surveillance et de facturation nous permettent de mettre en œuvre le modèle Pay As You Go pour nos utilisateurs.

Ainsi, voilà. Nous avons créé un véritable cloud dans nos esprits. Bien sûr, c'est beaucoup plus compliqué à l'intérieur et nous n'avons même pas touché à la manière dont fonctionnent les services PaaS, par exemple, mais j'espère que les principales approches utilisées dans les clouds sont maintenant plus claires pour vous.

Pour l'instant, c'est tout. Dans le prochain article, nous creuserons un peu plus dans le fonctionnement des services PaaS.