Mon infrastructure

Dans l'ère du cloud public, pourquoi se donner la peine d'héberger sa propre infrastructure ? En ce qui me concerne, je suis un fervent partisan des solutions cloud, que je mets souvent en avant dans ma profession. Cependant, je garde toujours à l'esprit que le cloud public est l'une des options possibles, mais pas la seule solution.

Pour mes besoins personnels (et par pur plaisir), j'ai tendance à conserver chez moi les ressources nécessaires pour l'hébergement. Je trouve que c'est un excellent moyen d'apprendre, même si je suis prêt à rechercher des solutions plus performantes ou plus efficaces par la suite. Néanmoins, je m'efforce toujours d'appliquer les bonnes pratiques du cloud et de garder à l'esprit la possibilité de déplacer mes actifs sans avoir à repenser entièrement ma configuration (c'est pourquoi j'apprécie particulièrement Kubernetes).

Si je prends un moment pour décrire ce que j'utilise, c'est parce que la plupart des tutoriels que je réalise et dont je rédige des articles sont basés sur cette infrastructure. Voici donc à quoi elle ressemble et pourquoi je l'ai conçue de cette manière. Il est important de noter qu'elle reste sujette à évoluer, en particulier en fonction de l'évolution du marché et des avancées technologiques."

La base

Mon laboratoire repose principalement sur une architecture VMware. L'idée est de regrouper plusieurs serveurs ESXi au sein d'un cluster géré par une instance vCenter. Suite à l'acquisition de VMware par Broadcom, comme de nombreux professionnels, je suis préoccupé par l'avenir de cet écosystème. Je m'essaie à d'autres solutions, notamment XCP-ng. Cependant, compte tenu de mon expérience avec cette plateforme, je reste pour le moment attaché à cette approche. Malgré les évolutions en cours, VMware demeure largement utilisé en entreprise et repose sur une base solide qui a fait ses preuves.

Le hardware

Les serveurs

Au fil du temps, VMware a progressivement restreint l'exécution de son hyperviseur ESXi sur du matériel non conventionnel. Cela s'est particulièrement fait ressentir avec la version 7.0, où l'injection de pilotes non officiels dans l'ISO d'installation n'est plus possible. Pour contourner cette limitation, j'ai dû trouver des solutions, car il m'était impossible d'installer des serveurs en rack dans mon appartement, et économiquement, l'achat de matériel professionnel n'était pas envisageable. Mon infrastructure repose donc sur deux types de serveurs :

• Le premier est basé sur la plateforme Intel X99, datant de 2014. Cette plateforme offre l'avantage de proposer de nombreux composants à des prix abordables sur le marché de l'occasion. Il est possible d'utiliser des cartes mères grand public avec des processeurs de type XEON, couramment disponibles sur des sites chinois. Il est à noter que de nombreux équipements en fin de vie ont été récupérés par des revendeurs de l’empire du Milieu pour être réutilisés sous d'autres marques. Il n'est pas rare de trouver des puces de chipset issues d'équipementiers bien connus, réintégrées sur des composants de marques moins connues. Mon serveur le plus puissant tourne sur une carte mère chinoise HUANANZHI X99-F8, et fonctionne 24 heures sur 24 depuis plus de 2 ans sans incident. J’y ai déployé la dernière version de ESXi, bien que je sois averti que la version 8 sera la dernière à prendre en charge cette architecture de processeur.


Cliquez sur l'image pour l'agrandir.

• Le second type de serveur est basé sur les mini-stations de travail ThinkCentre de Lenovo, datant de 2018. Ces modèles d'occasion sont facilement disponibles sur le marché. Ils ont l'avantage de prendre très peu de place et de consommer peu d'énergie (de 30 à 65 watts). Cependant, ils sont peu extensibles et n'ont qu'une seule interface, ce qui peut être limitant. Heureusement, Lenovo a prévu un port PCI interne avec la possibilité d'ajouter une carte d'extension. Au lieu d'opter pour des cartes réseau Realtek, qui ne sont plus prises en charge au-delà de vSphere 6.0, j'ai trouvé des kits d'adaptation sur AliExpress pour exploiter le port disponible à l'intérieur des boîtiers, que j'ai combinés à des cartes réseau double port avec chipset Brodcom BCM5720. Cela permet, pour environ 40€, d'avoir suffisamment d'interfaces pour mon lab. D'autres solutions sont envisageables, notamment via des ports USB, mais j'ai préféré conserver une intégration interne pour limiter les extensions visibles de l’extérieur (tout cela est dans mon salon…)


Cliquez sur l'image pour l'agrandir.

Le storage

Chaque serveur est équipé d'au moins un disque SSD , qui joue le rôle de datastore et héberge des machines virtuelles. Malgré le conseil contraire de VMware, j'ai choisi d'installer l'hyperviseur lui-même sur une clé USB (ce n'est pas le cas pour XCP-ng). Pour disposer de datastores partagés, j'utilise également un NAS Terramaster F4-424 à 4 baies. J'expose ainsi des volumes NFS.

Le Network

Pour mon infrastructure, j'utilise plusieurs commutateurs réseau, dont deux principaux de la marque ZYXEL, modèle XGS1210-12.

Ces deux commutateurs sont interconnectés par une liaison 10G et disposent chacun d'une liaison 10G supplémentaire, ainsi que de deux ports 2.5G en plus de leurs ports 1G. Pour des raisons pratiques, j'ai également trois commutateurs Netgear à 8 ports, répartis dans différents endroits de mon appartement afin d'étendre le réseau. En ce qui concerne ma connexion web, j'ai conservé uniquement le boîtier ONT Fibre fournie par mon fournisseur d'accès, sans la box. Je relie directement l'arrivée Internet à un routeur GL.Inet GL-AP1300. Bien que cette référence ne soit peut-être pas très connue, c'est un produit très intéressant, car il permet d'utiliser un firmware Open Source OpenWRT en plus de fournir un emplacement SIM. Cela me donne une redondance de ma connexion Internet. En cas de coupure de la fibre, j'ai un accès 4G qui empêche mon infrastructure de perdre la connectivité, même si les performances sont réduites dans cette situation.

Architecture

Réseau et virtualisation

Chaque serveur est équipé de trois interfaces réseau, ce qui me permet de suivre un modèle de déploiement classique en trois tiers. Je peux provisionner des machines virtuelles dans trois zones réseau distinctes:

• DMZ_FIRST : Il s'agit du réseau situé directement derrière mon routeur Internet.
• VLAN_WEB : Ce réseau intermédiaire me permet d'héberger certains services, notamment mes sites web.
• LAN : Réseau interne disposant d’un VLAN par défaut, ainsi qu'un VLAN dédié à VMOTION, permettant le déplacement des machines virtuelles d'un serveur à un autre.

Sécurité

Chacune de ces zones est sécurisée par un pare-feu, le premier étant intégré à mon routeur Internet. Les deux autres firewalls sont des machines virtuelles utilisant OPNsense. Grâce à ces dernières, je peux effectuer un filtrage précis des flux réseau et mettre en place des fonctions de détection et de prévention des intrusions (IPS/IDS) pour renforcer davantage la sécurité de mes accès.

Conteneur

À mesure que le temps passe, ma préférence tend de plus en plus vers l'utilisation de conteneurs plutôt que de machines virtuelles, bien que je considère que les deux ont leur place. Pour exécuter mes conteneurs, j'ai logiquement opté pour Kubernetes, devenu un standard incontournable pour ce type de besoin et en constante expansion. Mes nœuds Kubernetes sont déployés sur des machines virtuelles exécutant un système d'exploitation minimaliste (PhotonOS). L'objectif est d'avoir au moins trois control plane pour garantir une haute disponibilité du service, ainsi qu'un certain nombre de workers dans ma zone LAN et d'autres dans ma zone WEB. Étant donné que mes ressources ne sont pas infinies, le déploiement d'un unique cluster Kubernetes me permet d'optimiser mon infrastructure tout en tirant parti des capacités de K8S pour isoler mes applications dans des Namespaces. Si ces termes ne vous sont pas familiers, ne vous inquiétez pas, ce site est là pour expliquer tout cela en détail, et vous trouverez de nombreuses explications dans les autres articles.

Windows/Linux

Durant toute ma carrière dans le domaine de l'informatique (et encore maintenant), j'ai été témoin de la rivalité entre Windows et Linux. Des MVP Microsoft convaincus de la suprématie de leur éditeur de logiciels préféré aux fervents défenseurs de l'open source qui dénigrent sans réserve les compétences des administrateurs Microsoft, j'ai rapidement compris une chose essentielle : les mauvais systèmes d'exploitation sont rares, et ce qui importe le plus, c'est le contexte d'utilisation et les compétences des gens qui les utilisent.

Avec le temps, les frontières entre Windows et Linux se sont estompées, les deux s'inspirant parfois mutuellement pour évoluer. Pour ma part, j'apprécie les deux écosystèmes, et dans mon lab, j'ai des machines virtuelles Windows Server pour gérer des services tels qu'Active Directory, DNS et DHCP, ainsi que des machines virtuelles Linux, notamment sous Ubuntu Server, pour la supervision et la domotique. Je suis convaincu qu'il est essentiel de choisir l'outil adapté en fonction des besoins spécifiques et des compétences des équipes internes.