TeDomum issueshttps://git.tedomum.net/groups/tedomum/-/issues2024-01-20T12:01:48Zhttps://git.tedomum.net/tedomum/kity/-/issues/19Migration vers hepto v22024-01-20T12:01:48Zkaiyoupierre@jaury.euMigration vers hepto v2Cette issue a pour but de préarer, suivre, et documenter la migration de notre cluster vers hepto v2 le samedi 9 décembre à partir de 13h. On prévois une à quatre heure de travail.
## Décisions dimensionnantes
Sur la réinstallation des...Cette issue a pour but de préarer, suivre, et documenter la migration de notre cluster vers hepto v2 le samedi 9 décembre à partir de 13h. On prévois une à quatre heure de travail.
## Décisions dimensionnantes
Sur la réinstallation des OS, actuellement les noeuds Kity tournent sous Debian 11. Il serait sage soit de les dist-upgrade, soit de les réinstaller. Comme toutes les données sont sur une partition à côté, je serais assez favorable à les réinstaller sous Debian 12 histoire de faire les choses bien.
Sur l'état du cluster, je propose de redéployer from scratch plutôt que de migrer les objets k8s. Vu le nombre de majeures c'est plus sage.
Sur les données, plutôt que de les recopier, je propose de les conserver in place. Ainsi, la partition de données peut être conservée telle quelle. Les seules données essentielles sont celles de Garage. Nous avons également les données statistiques sur Prometheus et les dashboard Grafana, faciles à conserver in place bien qu'on voudra plus tard les déplacer sur un stockage distribué.
Sur le noeud public, je propose de le déployer sur aegir cette fois, plutôt que sur une machine dédiée. Il y a de grandes chances que ça fonctionne, et ça libérera un serveur, et les sous qui vont avec.
## Déroulé de la migration
### Préparation (au plus tard vendredi 22h, sinon on reporte)
- [x] Annoncer la coupure du cluster et des services associés le samedi 9 décembre de 13h à 18h.
- [x] S'assurer de la disponibilité de tout le monde nécessaire sur le créneau.
- [ ] #21 Documenter la liste des machines du cluster avec plus de détails, dont le schéma de partitionnement, le chiffrement de disque, etc.
- [x] Tester et retester le déploiement d'un cluster avec la collection Ansible, y compris quand on ne déploie qu'un noeud avec le playbook.
- [x] Tester le helm chart hepto pour déployer la base et un Flux, y-compris sur le Flux TeDomum
- [x] #21 Mettre à jour Garage en 0.9
- [x] Ajouter tous les admins du cluster dans la bonne team Vault et y partager le password de déploiement Ansible
- [x] Clôner les dépôts nécessaires chez tout le monde
- [x] Déployer le master `mainecoon` du nouveau cluster et partager l'anchor dans la config Ansible
- [x] Déployer le noeud public `angora` sur aegir
- [x] Déployer un noeud temporaire `chartreux` chez kaiyou sur une machine en Debian 12
- [x] Configurer une branche du flux TeDomum en désactivant toutes les kustomizations pour commencer
- [x] Bootstrap le cluster sur la branche de flux mentionnée
- [x] Déployer traefik, cert-manager, un ingress pour l'apiserver sur une adresse temporaire, et un podinfo de test
- [x] Fournir des tokens de connexion à tout le monde
### Le jour J
- [x] Le matin annoncer à nouveau la coupure générale
- [x] 12h Dernière annonce de coupure, confirmation des disponibilités des acteurs
- [x] 13h Briefing et dernières vérifications
- [x] 13h15 Extinction de Kity et réinstallation de l'OS sur tous les noeuds
- [x] 13h30 Déploiement des 3 noeuds supplémentaires
- [x] 13h45 Déploiement et tests de Garage
- [x] 14h Annonce du retour de la majorité des services
- [ ] 14h Déploiement progressif des services manquants sur Kity en réactivant les kustomization (priorité à crypt0n, chat, ntfy, et collabora, le reste est plus délicat mais peut attendre)
### Après les faits
- [ ] Communiquer sur la migration et sur l'emploi de Hepto v2
- [ ] Merge la branche du dépôt Flux dans la main et basculer Flux dessushttps://git.tedomum.net/tedomum/documentation/-/issues/173Migrer les assets Gitlab vers garage2024-01-20T12:01:45Zkaiyoupierre@jaury.euMigrer les assets Gitlab vers garagehttps://git.tedomum.net/tedomum/kity/-/issues/20Mise à jour Garage en 0.92023-12-05T22:11:10Zkaiyoupierre@jaury.euMise à jour Garage en 0.9HalfaHalfahttps://git.tedomum.net/tedomum/garage/-/issues/3Lenteurs et timeouts sur le cluster Garage2023-11-21T20:13:14Zkaiyoupierre@jaury.euLenteurs et timeouts sur le cluster GarageDepuis près de deux semaines, nous avons constaté (par remontée utilisateur principalement) des lenteurs et des défauts (erreurs 503 dues à des timeouts) sur le HTTP et sur le S3 de garage (à la fois en récupération et en upload d'image ...Depuis près de deux semaines, nous avons constaté (par remontée utilisateur principalement) des lenteurs et des défauts (erreurs 503 dues à des timeouts) sur le HTTP et sur le S3 de garage (à la fois en récupération et en upload d'image sur Mastodon notamment).
## Perte du noeud bambino
Le premier niveau d'étude du problème a montré que seuls deux noeuds étaient disponibles sur le cluster. Pour cause : le serveur derrière bambino était éteint depuis le 23/06, probablement pour cause de capteur de température (refroidissement passif sur la machine, 34-35°c ambiant).
kubernetes avait pris le relais sur les services, et garage fonctionnait plutôt bien sur 2 noeuds. La machine a été redémarrée le 30/06 à 18h30 CEST, sans problème particulier. Le tranquility garage a été abaissé pour favoriser le resync, qui s'est achevé le 2/07 à 5h30 CEST environ.
## Americancurl en pointillés
La supervision americancurl montre des points de mesure éparses pour Garage mais pas pour le node exporter. Ceci semble indiquer un souci lié au cluster garage, quelle qu'en soit l'origine.
![image](/uploads/8681c6826bbae4b985cbf726cd8f2db4/image.png)
Le noeud montre un fort niveau d'iotime :
![image](/uploads/2b7e0595995bbbdaec9495e5aea38f79/image.png)
Sur des prises de mesure en volume io, pour autant il y a raisonnablement peu de lecture ou écriture, ici sur 5 minutes en accumulé :
![image](/uploads/8948be2311d801e8d8ad1370e50565d8/image.png)
On constate par périodes (toutes les quelques dizaines de secondes) que l'API garage, le S3 et le Web sont incapables de répondre aux requêtes immédiatement depuis ce noeud précisément. Ce qui explique les trous dans les métriques, ainsi que les erreurs continues malgré le retour du cluster à 3 noeuds.
Dans ces cas, les endpoints finissent par répondre, mais avec un délai notable :
```
curl -v > /dev/null 0.16s user 0.05s system 0% cpu 2:03.98 total
curl -v localhost:3903/metrics 0.00s user 0.02s system 0% cpu 1:00.80 total
```
Constaté plusieurs fois avec exactement 2 minutes, ou exactement 1 minute.
Les logs de garage sur le noeud sont évocateurs également : pas d'activité pendant l'attente, puis de nombreuses requêtes loggées immédiatement. Souvent, après l'attente, un warning particulier est loggé :
```
garage 2023-07-02T11:30:44.711211Z WARN garage_api::generic_server: Response: error 500 Internal Server Error, Internal error (Hyper error): error reading a body from connection: Connection reset by peer (os error 104)
```
Après la reprise le trafic est normal quelques dizaines de secondes, et le noeud lance plusieurs resyncs de blocs, avant de planter à nouveau.https://git.tedomum.net/tedomum/synapse/-/issues/117Stockage des media Matrix sur Minio2023-11-21T20:13:10Zkaiyoupierre@jaury.euStockage des media Matrix sur MinioAujourd'hui nous devons migrer en urgence `cyprus`, ce qui n'était initialement prévu que le 12 avec intervention pour la migration aujourd'hui et demain. Il a donc été drain hier soir sans préavis.
En conséquence, le Minio hébergé dess...Aujourd'hui nous devons migrer en urgence `cyprus`, ce qui n'était initialement prévu que le 12 avec intervention pour la migration aujourd'hui et demain. Il a donc été drain hier soir sans préavis.
En conséquence, le Minio hébergé dessus est arrêté, et il hébergeait les Media Matrix, parmi les derniers binaires que nous ne stockons pas sur notre cluster Garage. En conséquence, l'upload et la réception de pièce-jointe par Matrix est interrompue depuis hier soir également.
Nous allons d'abord basculer le stockage des nouvelles pièces-jointes vers Garage, rétablissant l'upload et l'affichage des nouvelles, mais les pièces-jointes existantes ne seront pas accessibles. Puis dans les jours prochains nous synchroniserons l'historique des pièces-jointes.kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/kity/-/issues/18Déménagement de cyprus2023-11-21T20:13:06Zkaiyoupierre@jaury.euDéménagement de cyprusUn déménagement de cyprus était prévu initialement ce samedin. Il a eu lieu en précipitation aujourd'hui.
Hier soir @halfa a drain le noeud, et ce matin j'ai débranché à environ 9h40.
Problèmes :
- Le noeud hébergeait le Minio, ce qu'...Un déménagement de cyprus était prévu initialement ce samedin. Il a eu lieu en précipitation aujourd'hui.
Hier soir @halfa a drain le noeud, et ce matin j'ai débranché à environ 9h40.
Problèmes :
- Le noeud hébergeait le Minio, ce qu'on avait mal anticipé, et cause l'issue https://forge.tedomum.net/tedomum/synapse/-/issues/117
- La machine physique hébergeait toujours `mainecoon`, qui était prêt pour migrer sur la même machine que `bambino` mais la bascule n'avait pas été lancée encore.
A ce stade, `mainecoon` (le master) est arrêté, le transfert des données est en cours pour le relancer à côté de `bambino`.
A priori, `cyprus` sera rétabli le 22/08 ou le 23/08. Une fois le sujet Minio et `mainecoon` déplacé, tous les autres services devraient fonctionner sans problème sur les noeuds restant.kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/kity/-/issues/17Intégration de stockage flash sur le cluster2023-11-21T20:13:03Zkaiyoupierre@jaury.euIntégration de stockage flash sur le clusterLes événements des dix derniers jours et le début de résolution aujourd'hui l'ont montré de manière assez franche. On posait la question d'acheter maintenant ou pas du flash pour le cluster (on en aura de toute façon besoin plus tard pou...Les événements des dix derniers jours et le début de résolution aujourd'hui l'ont montré de manière assez franche. On posait la question d'acheter maintenant ou pas du flash pour le cluster (on en aura de toute façon besoin plus tard pour le stockage des BDD). Au final, je suis convaincu que même si l'emploi n'est pas nominal dès aujourd'hui, cela reste essentiel pour soutenir les solutions qu'on emploie, en stockage particulièrement, puisqu'on n'en maîtrise pas finement le comportement IO et qu'il faudra de temps en temps absorber la charge le temps d'optimiser.
Bref : il nous faut du flash, il en faut au moins sur chaque noeud qui héberge aujourd'hui du garage et sur chaque noeud qui hébergera demain des BDD. La question c'est combien et comment ? Je propose de poser ce qui est requis d'abord, en intégrant un schema qui offre de la souplesse.
# Volumétries et répartition
On a besoin de deux types de stockage sur les noeuds : du rapide (plutôt basse latence en random que bon débit, même si ça ne fait pas de mal), et du standard (sur lequel on fait peu de random et on peut patienter quelques ms par accès). Résumé autrment : du SSD/NVMe et du rotatif. L'orientation est à placer sur du rapide les conteneurs, possiblement l'OS s'il n'est pas distinct, et les "métadonnées" (les tables de différentes bases, qu'il s'agisse de relationnel, des meta garage, etc.) ; et sur du standard les données objet, les blobs non structurés.
J'ai fait un bilan des volumétries actuelles et de ce qu'on peut raisonnablement projeter par noeud à 3-5 ans (hautement spéculatif, j'ai fait une grosse loi de Moore à 3 ans, soit peu ou prou x3). Pour le stockage distribué ou répliqué, je prends l'hypothèse de 1 standby sur postgres et 3 réplicas sur garage. Tout est projeté sur un cluster à 5 noeuds (on est à 3, 4 prévu, on aura probablement un 5è dans l'intervalle).
Le stockage objet mesuré est la somme des usages actuels qu'on imagine basculer brutalement sur du stockage objet (images 15Go, mastodon 500Go, matrix 600Go, owncloud 100Go, video 250Go, pixelfed 3Go, artifacts 125Go), c'est à dire 1.6To
| Usage | Volumétrie actuelle | Volumétrie projetée | Brut par noeud, rapide | Brut par noeud, standard |
|-------|---------------------|---------------------|------------------------|--------------------------|
| Objets | 1.6To | 5To | 100Go | 3To |
| Bases relationnelles | 650Go | 2To | 800Go | 10Go (wal attendant archive) |
| Dépôts Git | 10Go | 30Go | 1Go | 30Go (aucune idée de comment on répliquera) |
| Mails | 100Go | 300Go | 1Go | 300Go (idem) |
| OS | 20Go | 60Go | 60Go | |
| Hepto | 80Go | 240Go | 240Go | |
| **Total** | | 6To | 1To | 3.5To |
Cela prèche pour disposer au minimum d'un flash de 1To et un rotatif de 4To par noeud qu'on gérerait maintenant dans le cluster. Tout le monde ne sera pas à ce niveau-là immédiatement mais ce n'est pas un problème. Je propose qu'on fixe comme orientation court-moyen terme : mini 4To de stockage dont 500Go de flash, visant 1To de flash par noeud. Le plus simple pour l'implémenter reste de faire 1To SSD + 4To HDD. Lorsqu'on a plus sans effort on peut. Lorsque le packaging oblige à faire un seul support, on peut faire 4To SSD.
# Intégration dans hepto
Un des enjeux reste que le stockage doit être accessible à hepto de manière gérable dans le temps. Jusqu'ici on montait le HDD (seule support dispo) dans `/hdd` dans hepto.
Avec le recul c'est assez mal informé. Le déplacement des metadata garage vers SSD en témoigne. kubernetes supporte assez mal les points de montage non homogènes dans un cluster, surtout quand on fait du `hostPath` dans un `DaemonSet`. En vérité c'est classique de beaucoup de technos donc il faut uniformiser ça. Pour monter les metadata garage, pour le moment on a surchargé le `/hdd/garage/meta`, puisque tout était monté dans `/hdd` initialement.
Il me semble qu'il faut distinguer le besoin de l'implémentation pour avoir un petit peu de souplesse. Ma proposition à ce stade :
- on stocke tout dans `/mnt` dans hepto, `/mnt/data` pour les données non structurées/indexées, et `/mnt/meta` pour les metadonnées indexées qui ont besoin de stockage rapide ;
- on laisse soin à l'hôte d'exposer des points de montage corrects et unifiés (avec LVM ou autre) et de les monter dans hepto
- en cas de HDD + SSD par exemple, on monte le HDD dans `/mnt/data` et le SSD dans `/mnt/meta`
- en cas de gros HDD mais pas encore de SSD, ou de gros SSD qui couvre tout, on le monde dans `/mnt`https://git.tedomum.net/tedomum/synapse/-/issues/114Migrer les assets Matrix vers garage2023-11-21T20:12:46Zkaiyoupierre@jaury.euMigrer les assets Matrix vers garageA attendre quelques jours qu'on ait bien stabilisé le synapse.A attendre quelques jours qu'on ait bien stabilisé le synapse.kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/kity/-/issues/15Préparer un noeud chez kaiyou-bis2023-11-21T20:12:29Zkaiyoupierre@jaury.euPréparer un noeud chez kaiyou-bis- [x] Trouver une machine
- [x] Acheter ou trouver du stockage
- [x] Confirmer la disponibilité de la fibre
- [x] Confirmer la disponibilité IPv6
- [x] Déployer le noeud- [x] Trouver une machine
- [x] Acheter ou trouver du stockage
- [x] Confirmer la disponibilité de la fibre
- [x] Confirmer la disponibilité IPv6
- [x] Déployer le noeudkaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/kity/-/issues/13Runner Gitlab sur Kity2023-11-21T20:12:27Zkaiyoupierre@jaury.euRunner Gitlab sur KityJae Lo PrestiJae Lo Prestihttps://git.tedomum.net/tedomum/kity/-/issues/12Nouvelle version d'element ne run pas2023-11-21T20:12:18ZayinihoNouvelle version d'element ne run pasDepuis la v1.11.3, kity ne parvient pas à faire tourner nos nouvelles version d'element. Nous n'avons rien changé sur notre dépôt, ni rien côté config helm/kity.
Je joins les logs kubectl logs et describe.
[kubectl_logs.txt](/uploads/739...Depuis la v1.11.3, kity ne parvient pas à faire tourner nos nouvelles version d'element. Nous n'avons rien changé sur notre dépôt, ni rien côté config helm/kity.
Je joins les logs kubectl logs et describe.
[kubectl_logs.txt](/uploads/73992c54de328c69fcbd1855bac2b6c7/kubectl_logs.txt)
[kubectl_describe.txt](/uploads/1b730210c39819a54c365ed6ff258f37/kubectl_describe.txt)kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/www/-/issues/33Ajouter une synthèse des commandes de garage dans kubectl2023-11-11T08:19:55ZMickGeAjouter une synthèse des commandes de garage dans kubectl# Synthèse des commandes de `garage` dans `kubectl`
```shell
alias garage='kubectl -n storage-object exec svc/garage -- ./garage'
```
## Actions sur les buckets
### Obtenir de l'aide
```shell
garage bucket --help
```
### Créer un bu...# Synthèse des commandes de `garage` dans `kubectl`
```shell
alias garage='kubectl -n storage-object exec svc/garage -- ./garage'
```
## Actions sur les buckets
### Obtenir de l'aide
```shell
garage bucket --help
```
### Créer un bucket
```shell
garage bucket create <bucket_name>
```
### Lister les buckets
```shell
garage bucket list
```
### Infos d'un bucket
```shell
garage bucket info <bucket_name>
```
### Supprimer un bucket
```shell
garage bucket delete <bucket_name> --yes
```
## Actions sur les clés
### Obtenir de l'aide
```shell
garage key --help
```
### Créer une clé
```shell
garage key new --name <key_name>
```
### Donner les droits de lecture et écriture à la clé
```shell
garage bucket allow <bucket_name> --read --write --key <key_name>
```
### Lister les clés
```shell
garage key list
```
### Supprimer une clé
```shell
garage key delete <key_name> --yes
```https://git.tedomum.net/tedomum/kity/-/issues/6Intégrer Blackcat2023-02-02T19:07:08Zkaiyoupierre@jaury.euIntégrer BlackcatAnge dispose d'un noeud que nous devons encore intégrer dans le cluster :)Ange dispose d'un noeud que nous devons encore intégrer dans le cluster :)AngedestenebresAngedestenebreshttps://git.tedomum.net/tedomum/garage/-/issues/1Monter un POC Garage2022-12-08T19:05:54Zkaiyoupierre@jaury.euMonter un POC GarageCela fait quelques mois (1 an ?) que nous promettons de déployer un POC de Garage d'abord en baremetal puis directement dans un cluster hepto. On pourrait tout à fait imaginer déployer ça dans le cluster de lab ACIDES pour commencer !
L...Cela fait quelques mois (1 an ?) que nous promettons de déployer un POC de Garage d'abord en baremetal puis directement dans un cluster hepto. On pourrait tout à fait imaginer déployer ça dans le cluster de lab ACIDES pour commencer !
La documentation Garage : https://garagehq.deuxfleurs.fr/
En cas de besoin, on peut commencer par pinger Quentin et Halfa, sinon il y a le salon de suivi Garage sur Matrix : https://matrix.to/#/%23garage:deuxfleurs.frhttps://git.tedomum.net/tedomum/peertube/-/issues/49Stockage vers S32022-12-07T19:26:45ZJae Lo PrestiStockage vers S3Basculer le stockage des vidéos vers un serveur MinIO décrit dans https://forge.tedomum.net/tedomum/kity/-/issues/8.Basculer le stockage des vidéos vers un serveur MinIO décrit dans https://forge.tedomum.net/tedomum/kity/-/issues/8.https://git.tedomum.net/tedomum/documentation/-/issues/162Basculer tedomum.in tech.tedomum.net2022-08-18T11:31:16Zkaiyoupierre@jaury.euBasculer tedomum.in tech.tedomum.netkaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/documentation/-/issues/136Optimiser l'usage RAM de Postgresql2022-07-03T18:40:53Zkaiyoupierre@jaury.euOptimiser l'usage RAM de PostgresqlL'instance mutualisée de PostgreSQL consomme quelques 6Go de RAM pour clairement assez peu d'index chauds utilisés, et pas vraiment de requêtes lourdes inflight en permanence, on doit donc pouvoir largement diminuer cet usage RAM sans pe...L'instance mutualisée de PostgreSQL consomme quelques 6Go de RAM pour clairement assez peu d'index chauds utilisés, et pas vraiment de requêtes lourdes inflight en permanence, on doit donc pouvoir largement diminuer cet usage RAM sans perdre franchement en performances.
Premier objectif réunir de la documentation sur le sujet, puis creuser et tester de configurations. On peut redémarrer le serveur un nombre raisonnable de fois sans trop casser de services.
J'affect @ayiniho mais travail à deux.ayinihoayinihohttps://git.tedomum.net/tedomum/documentation/-/issues/91Documenter les séquences de reboot2022-07-03T18:40:34Zkaiyoupierre@jaury.euDocumenter les séquences de rebootIl est devenu crucial de documenter les séquences de reboot
- [x] écrire la documentation
- [ ] relire
- [ ] vérifier que les admins ont tous tous les élémentsIl est devenu crucial de documenter les séquences de reboot
- [x] écrire la documentation
- [ ] relire
- [ ] vérifier que les admins ont tous tous les élémentskaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/kity/-/issues/3Tester un VPN entre Kity et aegir2021-11-05T08:42:01Zkaiyoupierre@jaury.euTester un VPN entre Kity et aegirPour faciliter la migration de services stateful en attendant d'avoir du stockage relationnel sur Kity, Halfa suggère qu'on teste un VPN entre Kity et aegir.
Techniquement Kity repose sur un mesh wireguard, il suffirait probablement de ...Pour faciliter la migration de services stateful en attendant d'avoir du stockage relationnel sur Kity, Halfa suggère qu'on teste un VPN entre Kity et aegir.
Techniquement Kity repose sur un mesh wireguard, il suffirait probablement de configurer un noeud wesher avec une anchor sur aegir pour que ça fonctionne, et un service k8s pour pointer vers le postgres de aegir.https://git.tedomum.net/tedomum/kity/-/issues/8Serveur MinIO2021-10-09T09:12:51ZJae Lo PrestiServeur MinIOLancer un serveur MinIO sur Kity (cyprus?) afin d’héberger des données superflues de Aegir.Lancer un serveur MinIO sur Kity (cyprus?) afin d’héberger des données superflues de Aegir.kaiyoupierre@jaury.eukaiyoupierre@jaury.eu