12 KiB
Objectif
Avoir une infrastructure informatique ou les services, comme NAV, ne soient plus affectés par une défaillance matériel.
Méthode
Pour permettre à un service de passer d'un hôte à l'autre la méthode la plus flexible est d'exectuer les service dans des instances virtualisées ou des conteneurs. Pour diminuer ou même éliminer l'impacte d'un hôte défaillant sur la disponibilité du service, un système d'orquestration automatique doit gérer l'attribution des instances virtuelle ou des conteneurs sur les hôtes matériels. De plus, les données utilisées par le service doivent être aussi disponbile sur plusieurs hôtes pour que les données soient toujours disponible lors de la défaillance d'un hôte. Finalement, la communication entre les hôtes doivent être dupliqués en cas de la défaillance d'un commutateur réseau.
Specifications
Noeud de controle
- 1 ou 3 noeuds
- 1 CPU 4 core / 8 thread
- 4-8 GB RAM
- 128 GB SSD NVMe
- Gigabyte Ethernet
Noeud de calcule
- 2 ou 3 noeuds ou plus
- 1 CPU 8 core / 16 thread (Intel Xeon E-2246G)
- 32 ou 64 GB RAM
- 1 TB SSD NVMe
- 10 Gigabyte Ethernet
Noeud de storage
- 2 ou 3 noeuds ou plus
- 1 CPU 6 core / 12 thread (Intel Xeon E-2246G)
- 32 GB RAM
- 4 TB SSD NVME
- 6 HDD 12 TB
- 10 Gigabyte Ethernet
Dorsale réseau
- 2 Commutateurs Ethernet 10 Gigabit 8, 12 ou 24 ports
Hardware
Noeud de controle
| Pièce | Nombre | Prix unitaire | Totale |
|---|---|---|---|
| Base | 1 | 599,99 | 599,99 |
| Mémoire (16 GB) | 1 | 92,09 | 92,09 |
| SSD (480 GB) | 1 | 119,99 | 119,99 |
| Frais postale | 46,94 | ||
| Totale | 859,01 |
Noeud de storage
| Pièce | Nombre | Prix unitaire | Totale |
|---|---|---|---|
| Carte Mère | 1 | 850,99 | 850,99 |
| Dissipateur thermique | 1 | ||
| CPU | 1 | 659,99 | 659,99 |
| Mémoire (16 GB) | 2 | 94,16 | 188,32 |
| SSD M.2 (4 TB) | 1 | 410,00 | 410,00 |
| Chassis | 1 | 239,99 | 239,99 |
| Power supply | 1 | 169,99 | 169,99 |
| HDD (12 TB) | 6 | 304,99 | 1829,94 |
| Frais postale | 44,76 | ||
| Totale | 4393,98 |
Noeud de calcule
| Pièce | Nombre | Prix unitaire | Totale |
|---|---|---|---|
| Carte Mère | 1 | 747,99 | 747,99 |
| Chassis | 1 | ||
| Dissipateur thermique | 1 | ||
| CPU | 1 | 480,55 | 480,55 |
| Mémoire (16 GB) | 4 | 94,16 | 376,64 |
| Réseau (10Gb/s) | 1 | 213,45 | 213,45 |
| SSD M.2 (1 TB) | 1 | 159,99 | 159,99 |
| Frais postale | 10,99 | ||
| Totale | 1989,61 |
Dorsale réseau
| Pièce | Nombre | Prix unitaire | Totale |
|---|---|---|---|
| commutateur | 2 | 1650,99 | 3301,98 |
| Totale | 3301,98 |
Discussion
Un minimum de deux (2) noeuds de storage et de calcule est requis pour permettre la redondance du matériel et permettre le balancement des services en cas de panne. Trois (3) noeuds permetteraient d'avoir encore un noeud de redondance après la défaillance d'un noeud, ce qui permet de remplacer le noeud défaillant sans urgences.
Les noeuds de storage on besoin de 5 GB de RAM et un core du CPU pour chaque disques. Il est possible d'utiliser les noeuds de storage pour executer des services comme le font les noeuds de calcule. Ce n'est pas recommandé, car ceci peut impacter la vitesse des accès au données.
Variations
Scripts et applications
Infrastructure
Kubernetes (k8s)
Un orcestrateur, il permet le balancement de pods (microservices) entre les divers nodes (serveurs) sous sa gérance (cluster)
Terraform
Language de définition "statefull" pour l'infrastructure. Il permet de documenter (via les scripts) comment l'infrastructure sera construite. Utilisé pour les nodes physique et les services dans les pods.
Helm
La méthode pour déployé des services dans k8s. En plus de terraform qui détermine la nature de l'infrastructure, helm défini la configuration des pods et des services dans le cluster k8s.
Flatcar linux
Une districution de linux particulièrement optimisé pour executer une seule tâche sur un serveur. Utilisé pour héberger le service K8s. Fait intéressant, flatcar est maintenu par Microsoft. Source du noyau linux pour l'ensemble du cluster k8s.
Containerd
Solution parallèle à Docker pour la création et gestion de containers, un composant d'un pod dans k8s. La solution est considéré comme le standard d'industrie pour la contenérisation d'hébergement. Docker est plus populaire dans le domain du développment sur les postes de travail.
Alpine linux
Une distribution de linux optimisée pour être de petite taille, mais versatille contrairement à flatcar linux. Sans charge, l'image sans noyau prendre un peu moins que 8MB. Utilisé pour la construction des pods qui supporteront les service hébergés dans le cloud interne k8s.
Services
Typhon
Une distribution de kubernete, elle permet de déployer un cluster kubernete avec des configuration et les pods les plus utilisé.
Matchbox
Un serice de déploiement pour les nodes physiques via le réseau (iPXE). Install les images généré par la configuration de terraform sur les nodes physique du cluster.
DNSmasq
Serveur DNS recusif et serveur DHCP excessivement simple a déployer qui offre les fonctionnalités IP et DNS pour le foncitonnement d'un réseau interne. Essentiel pour le fonctionnement de matchbox. k8s utilise ses propres service DNS interne.
ipmitool
Programme codé en C permettant de communiquer avec la plateform IPMI (Intelligent Platform Management Interface). Cette commande sera utilisé dans les scritp CI de wookpecker pour redémarrer les nodes physiques du cluster et initier leur déploiement.
Gitea
Un répo git semblable à github et gitlab. Offre l'authentification LDAP (aka AD lightweight Directory) sans coût supplémentaire. Permet d'entreposer les fichiers de configuraiton terraform, donc la documentation de l'infrastructure.
Woodpecker CI
Un outil d'intégration en continue "Continous integration - CI" permettant d'executer les script terraform quand les fichiers de configuration terraform change. Ceci permet de forcer les gestionnaires de l'infrastructure de changer la documentation terraform dans le répertoire git de gitea quand ils désirent effectuer une modification.
Openstack
Orchestrateur pour la virtualisation. Un équivalence de k8s pour les machines virutelles. k8s contient plus d'outils, offre des meilleurs performances en fonction du matériel, mais openstack offre la possibilité d'executer des windows sur linux, ce que k8s ne permet pas. Il est possible d'executer Openstack sur k8s. Il sera utilisé pour executer les logiciels monolitique, ceux qui est impossible de migrer vers les microservices. Ceci inclue les logiciels exclusivement executable sur windows comme Microsoft NAV. Openstack est plutot complex, il se pourrait qu'une solution plus simple soit offerte si elle peut être déployé par terraform.
mssql docker
L'image docker pour mssql, malheureusement en ubuntu, ce qui rend l'image un peu plus lourde, mais fonctionnel. Après un peu de lecture, il sera impossible de permettre plusieurs microservices avec un load balancer frontal, mais un pod seul (legacy service) avec un service frontal devrait nous donner 5 à 10 secondes de downtime quand la node hébergeant le pod meurt, tout de même acceptable.
OpenLDAP
Application d'annulaire suivant le standard LDAP pour l'entreposage, entre autres, des informations d'utilisateurs et d'ordinateur. Effectue le même rôle qu'Active directory, mais AD dévie en quelques point du standard LDAP.
Keberos (krb5)
Protocole d'autentification réseau. Cette méthode permet à un utilisateur d'ouvrir une session sur un oridnateur (ou d'autre service) à partir d'un jeu d'authentification centralisé. Active directory utilise une version modifié de kerberos pour à cet effect.
Samba
Couche d'interoperabilité permettant à windows et linux de s'authentifier dans la même infrastructure LDAP/Kerberos. Mis en d'autre mots, samba peut être utilisé pour créer un controlleur de domain AD sur linux. Il permet aussi d'utiliser le protocole de partage windows, SMB sur linux.
Rook
Décrit comme un opération de storage. Dans le cloud k8s interne, rook sera utilisé comme méthode de distribution de cehp. Il permet d'utiliser les outils et méthodes résiliante de k8s pour déployer ceph sur les nodes de storage.
Ceph
Un système de storage d'information distribué. Ceph permet essentiellement de construire un NAS/SAN résilient distribué sur le réseau. La manière qu'il fonctionne est analogue à comment fonctionne un RAID5 pour un jeux de disques sur un poste local.
NGINX Ingress Controller
Un reverse proxy servant de point de sortie unique par node pour plusieurs service interne du cluster. En combinaison avec MetalLB, ceci permet d'attribuer dynamiquement un IP à un service en fonction de la node que celui-ci est exectuer dessus. Il est aussi possible d'attribuer l'IP le même IP a plusieurs node tant que celui est associé avec le même jeux de pods ingress.
Cert Manager
En travail constant avec Ingress, cert manager permet de générer, certifier et renouveller un certificat. Ceux-ci sont traditionnellement utilisé pour l'encryption de site web (https), malgré que de nombreuse autres utilité sont possible. Ce serait avec un certificat de cert manager que l'encryption de NAV se ferait par le réseau. Il est important d'utiliser un nom de domaine qui résoud à l'externe pour permettre au fournisseur de certificat; let's encrypt de communiquer avec cert manager.
Knot DNS
Knot DNS est un serveur DNS de production hébergant une zone DNS. Celui-ci sera utilisé pour héberger la zone DNS du réseau local et sera mise-à-jour via externalDNS et par extension défini dans terraform. Knot DNS est différent de DNSMasq, car celui-ci sert a héberger une zone et non d'être un qui effectue une résolution pour les clients, aka recursif.
ExternalDNS
Permet de dynamiquement généré une entrée DNS dans knot DNS en fonction d'une configuration d'un service dans k8s.
MetalLB
Permet l'attribution automatique d'un IP à un service que l'on désire exposé à l'exterieur du cluster k8s, soit dans le réseau interne.
Prometheus
Permet d'accumuler les métriques des divers nodes et service du cluster k8s. Il est aussi utilisé pour générer des alertes quand les métriques atteindre un niveau défini.
Grafana
Visualistaion de métrique. Grafana sera utilisé pour créer des tableau de métrique pour vérifier l'état de santé du cluster k8s et des services qu'il supporte.
Calico
Une solution de résautage pour la communication entre les pods inter-node géré par le même cluster k8s
CoreDNS
Service DNS interne pour automatiser la communication entre les pods et les services du cluster k8s.
etcd
Dépôt de configuration "flat" semblable a Redis utilisé par les nodes de gestions de k8s pour enmagasier les configurations de cluster.