ddc8: zsh
authorJulien Moutinho <julm@sourcephile.fr>
Tue, 7 Jan 2020 19:12:48 +0000 (20:12 +0100)
committerJulien Moutinho <julm@sourcephile.fr>
Tue, 7 Jan 2020 19:12:48 +0000 (20:12 +0100)
ddc/ddc8-logiciellerie-une_infra.md

index e6841565c73378a6ba05678c767c66f35907f4c8..697e0415abdcbc0d96ac7fe6741c08e84b34b9eb 100644 (file)
@@ -38,9 +38,9 @@
 
 ## Motivations
 ### S'émanciper d'autogeree.net
-Les logiciels que j'écris sont actuellement hébergés sur `chomsky.autogeree.net`, une machine virtuelle (VM) relativement modeste que me fournie Grésille depuis 2011 (en contre-partie d'un Dell R210 surnommé « chomsky » et acquis dans l'enthousiasme naïf de l'essaimage de FDN, puis resurnommé « rouf » par Grenode). Cette VM m'a longtemps servi de bac à sable pour jouer à l'adminsys, qui sert encore à un copain et moi-même pour avoir du mél et de l'IRC.
+Les logiciels que j'écris sont actuellement hébergés sur `chomsky.autogeree.net`, une machine virtuelle (VM) relativement modeste que me fournie Grésille depuis 2011 (en contre-partie d'un Dell R210 surnommé « chomsky » et acquis dans l'enthousiasme naïf de l'essaimage de FDN, puis resurnommé « rouf » par Grenode). Cette VM m'a longtemps servi de bac à sable pour jouer à l'adminsys, et sert encore à un copain et moi-même pour avoir du mél et de l'IRC.
 
-`chomsky` est une Debian dans une machine virtuelle Xen (1 CPU, 750Mo de RAM, 50Go de stockage **probablement** HDD), dans une machine hébergée professionnellement en datacenter à Grenoble. Cette machine est actuellement reliée à l'Internet par une autre infrastructure de Grenode à Lyon (au Netcenter via l'association Rézopole).
+`chomsky` est une Debian dans une machine virtuelle Xen (1 CPU, 750Mo de RAM, 50Go de stockage HDD), dans une machine hébergée professionnellement en datacenter à Grenoble. Cette machine est actuellement reliée à l'Internet par une autre infrastructure de Grenode à Lyon (au Netcenter via l'association Rézopole).
 `chomsky` n’a pas vraiment les ressources d’une machine de développement (nixpkgs c’est déjà 10Go de stockage, stack 5Go, et le REPL de GHC ou de PureScript c’est minimum 0.5Go de RAM).
 
 autogeree.net ne peut donc plus assurer mes besoins, et je n’arrive pas à convaincre qui que ce soit de porter avec moi une énième tentative d’association, nommée « Sourcephile », mais il me faut assurer la continuation du développement des logiciels libres qui me tiennent à cœur, et par conséquent je choisis d’entreprendre unilatéralement ce qu’il faut pour cela : `mermet.sourcephile.fr`, nommée d’après feu Laurent Mermet.
@@ -51,10 +51,6 @@ Pour approfondir ces raisons techniques, on peut voir par exemple les tutoriels
 
 Cependant, il est **peu probable** que je puisse passer `chomsky` sous NixOS, car mon copain n’envisage pas de se mettre à NixOS, et puis c'est une opération risquée demandant une intervention délicate sur une machine hébergeant actuellement des services en production (essentiellement nos méls persos en MX n°1).
 
-- https://www.fsf.org/resources/hw
-- https://wiki.debian.org/FreedomBox/Hardware
-- https://nixos.wiki/wiki/NixOS_on_ARM
-
 ## Objectif
 L’objectif principal est de continuer d’habiter sur Internet, en assurant ce qu’autogeree.net ne peut plus assurer ou n’a jamais véritablement assuré.
 
@@ -140,7 +136,7 @@ Ressources :
 - https://pcengines.ch/howto.htm
 - https://openwrt.org/toh/pcengines/apu2
 - https://www.cs.cmu.edu/~davide/howto/apu4c4.html
-- https://blog.linuxserver.io/2016/12/17/review-pcengines-apu2-c4-prebuilt-by-linitx/#vpnperformance
+ https://blog.linuxserver.io/2016/12/17/review-pcengines-apu2-c4-prebuilt-by-linitx/#vpnperformance
 - https://teklager.se/en/knowledge-base/
 
 ##### Caractéristiques
@@ -215,8 +211,14 @@ La RMT-CASE-S1 de Clemanis (pour APU2 ou APU3 seulement !) est 15€ plus chère
 Bien que rendant le Gio plus cher à l'achat, utiliser du disque à état solide (SSD) est plus fiable, plus rapide et consomme moins que du disque mécanique : https://arstechnica.com/gadgets/2014/06/consumer-grade-ssds-actually-last-a-hell-of-a-long-time/
 Tellement fiable qu'il ne semble pas raisonnable de répliquer en temps réel le disque mais juste de sauvegarder régulièrement ailleurs (zfs send) le disque. La réplication apporterait tout de même une tranquilité d'esprit importante. Surtout que les SSD pour particuliers n’ont généralement pas de condensateur interne contre les coupures de courant : https://insights.samsung.com/2016/03/22/power-loss-protection-how-ssds-are-protecting-data-integrity-white-paper/
 
+Les SSD sont plus performant que les HDD en terme d'IOPS (Input/Output Per Second).
+
+##### Capacité
+Les SSD sont moins performant que les HDD en terme d'octet par euro.
+
 ##### Vitesse
-Les petits SSD ont une vitesse d'écriture plus lente, dans la mesure où il y a plus de puces pour paralléliser les écritures (mais cela ne marche que pour des opérations parallélisables, cela ne s'applique à priori pas quand on a un seul processus) : https://www.tweaktown.com/reviews/5993/samsung-840-evo-128gb-msata-ssd-review/index.html
+Les SSD sont plus performant que les HDD en terme d'IOPS (Input/Output Per Second) par euro, non seulement sur des accès séquentiels mais surtout sur des accès aléatoires.
+Les petits SSD ont une vitesse d'écriture plus lente que les gros SSD, dans la mesure où il y a plus de puces pour paralléliser les écritures (mais cela ne marche que pour des opérations parallélisables, cela ne s'applique à priori pas quand on a un seul processus) : https://www.tweaktown.com/reviews/5993/samsung-840-evo-128gb-msata-ssd-review/index.html
 Ainsi un 128Go écrira séquentiellement à 320Mo/s (Kingston) ou 410Mo/s (Samsung). Mais un 250Go écrira séquentiellement à 500Mo/s (Kingston) ou 520Go/s (Samsung).
 En outre, côté ordinateur tous les connecteurs SATA ne sont pas créés égaux, le concepteur de la carte-mère peut mettre des connecteurs bons marchés mais peu performants, auquel cas pouvoir rajouter une carte SATA peut améliorer la situation.
 
@@ -254,26 +256,27 @@ La taille physique des secteurs est donnée par fdisk -l ou /sys/block/sd*/queue
 Bien que je n’ai aucune expérience avec (ZFS n’est pas exotique, mais n’est pas non plus le défaut sous Debian), je choisis d’utiliser ZFS plutôt que le stack RAID+LUKS+LVM+ext4+rsync que je connais bien, car il me semble que l'approche intégrée de ZFS permet une configuration moins complexe, plus granulaire, plus évolutive, tout aussi mature, plus fiable contre la corruption des disques, et plus sécurisée du point de vue des sauvegardes.
 ZFS est mature mais requiert de l’attention et de l’expertise, dans le cas contraire cela peut amener à de mauvaises performances, voire à de la perte de données.
 ZFS a une multitude de fonctionnalités qui questionne de premier abord par rapport à la philosophie Unix de faire une seule chose mais de le faire bien. Il y a surement de très bonnes raisons de gérer ces fonctionnalités de manière intégrée, en tout cas la granularité et flexibilité que cela permet sont très appréciables quand on ne sait pas trop comment nos besoins vont évoluer.
-ZFS a été premièrement pensé pour protéger les données de corruptions.
+ZFS a été premièrement pensé pour protéger les données de corruptions, en considérant que les disques conspirent  pour perdre les données.
 ZFS bénéficierait du travail d’environ 77 personnes par an, ce qui donne l’impression d’un développement aussi éclaté qu’actif : https://www.percona.com/blog/2017/11/15/zfs-from-a-mysql-perspective/
 ZFS aurait une taille de son code source équivalente à 10 fois celle d’EXT4, mais ZFS remplace aussi MD, LVM, dm-crypt, …
 ZFS ne peut légalement pas être intégré directement au noyau Linux mais cela est bien géré par NixOS.
 
 Quelques fonctionnalités / concepts de ZFS :
-- CoW (copy-on-write) : consiste à ne pas écraser un enregistrement lorsqu'il y q besoin de le modifier, mais d'écrire un nouvel enregistrement, de changer des pointeurs et de laisser le ramasse-miette (garbage-collector) de ZFS libérer l’ancien si il n’est plus référencé. Cela permet de garantir la cohérence des données.
+- CoW (copy-on-write) : consiste à ne pas écraser un enregistrement lorsqu'il y q besoin de le modifier, mais d'écrire un nouvel enregistrement, de changer des pointeurs et de laisser le ramasse-miette (garbage-collector) de ZFS libérer l’ancien si il n’est plus référencé. Cela permet de garantir la cohérence des données sur les disques, tout en supprimant le besoin d'un journal ou de faire des fsck.
 - Pool storage (hot add disks) : pas besoin de décider à l'avanc de la taille de partitions ou de les redimensionner.
-- ZIL (ZFS Intent Log) : Utile si il y a beaucoup d’écriture synchrones ou servir des fichiers qui changent fréquemment.
-- SLOG (Separate Intent Log) : ZIL sur disque (de préférence répliqué par RAID avec write-back, car le perdre perdrait serait dramatique), généralement de quelques Gio, rapide pour les écriture séquentielles et les fsync().
-- ARC (Adjustable Replacement Cache)/ : cache de ZFS sur la RAM. Utile pour servir des fichiers qui changent fréquemment. Cache ce qui a été le plus récemment utilisé et le plus fréquemment utilisé.
-- L2ARC (Level 2 ARC) : cache ZFS optionnel sur disque, de préférence SSD, qui stocke les données balayées de l’ARC. Un système avec moins de 8Gio de RAM n’a pas besoin de L2ARC, qui ne ferait que réduire les performances en imposant une pression sur l’ARC. jgreco : « Do not add L2ARC to an 8GB system. Period. Probably not to 16 either. Maybe at 24 or 32GB, but you have to remember that L2ARC stresses out the ARC and that you shouldn't exceed maybe a 4:1 ratio of L2ARC:ARC. »
+- ZIL (ZFS Intent Log) : cache d'écriture. Utile lorsqu'il y a beaucoup d’écriture synchrones ou pour servir des fichiers qui changent fréquemment.
+- SLOG (Separate Intent Log) : ZIL séparé sur un autre disque (de préférence répliqué par RAID avec write-back, car le perdre serait dramatique), généralement de quelques Gio, rapide pour les écriture séquentielles et les fsync().
+- ARC (Adjustable Replacement Cache)/ : cache MRU/LRU et MFU/LFU de ZFS sur la RAM. Utile pour servir des fichiers qui changent fréquemment. Cache ce qui a été le plus récemment utilisé (MRU) et le plus fréquemment utilisé (MFU).
+- L2ARC (Level 2 ARC) : cache de lecture ZFS optionnel sur disque, de préférence SSD, qui stocke les données balayées de l’ARC. Un système avec moins de 8Gio de RAM n’a pas besoin de L2ARC, qui ne ferait que réduire les performances en imposant une pression sur l’ARC. jgreco : « Do not add L2ARC to an 8GB system. Period. Probably not to 16 either. Maybe at 24 or 32GB, but you have to remember that L2ARC stresses out the ARC and that you shouldn't exceed maybe a 4:1 ratio of L2ARC:ARC. »
 - Quotas.
 - Héritage des propriétés entre les datasets.
-- Délégation des droits d'administration à des utilisateurs (zfs allow).
-- Scrubing (self-healing) : Si plus d’une copie (copies= strictement supérieur à 1) est disponible et qu’une des copie est détectée comme corrompue, ZFS retournera seulement la copie valide et réparera les enregistrement endommagés. Cela peut être déclenché manuellement avec la commande scrub.
+- Délégation fine des droits d'administration à des utilisateurs (zfs allow).
+- Checksum : ZFS utilise des sommes de contrôle tout au long de l'arborescence des blocks de données à des endroits séparés des données (parent-block), et pas au niveau et à côté des données, ce qui permet non seulement de détecter les bits défectueux (bit-rot), mais également d'autres erreurs possibles : phantom writes, misdirected reads and writes, DMA parity errors, driver bugs, acccidental overwrites.
+- Scrubing (self-healing) : si plus d’une copie (copies= strictement supérieur à 1) est disponible et qu’une des copie est détectée comme corrompue, ZFS retournera seulement la copie valide et réparera les enregistrement endommagés. Cela peut être déclenché manuellement avec la commande scrub.
 - Send/Receive : ZFS permet d’envoyer et de recevoir entièrement ou incrémentalement des captures instantannées (snapshots) vers d’autres machines.
-- Réplication : mirror, raidz-1, raidz-2, …, équivalents de RAID1, RAID5, RAID6, …. L’équivalent de la reconstruction du RAID s’appelle ici « resilvering ».
+- Réplication : mirror, raidz-1, raidz-2, raidz-3, raidz-N où N est le nombre de disques qui peuvent cesser de fonctionner sans que cela n'impacte le système, c'est équivalent aux RAID1, RAID5, RAID6, …. L’équivalent de la reconstruction du RAID s’appelle ici « resilvering », mais celle-ci ne s'applique que sur l'espace utilisé du disque et non sur tout le disque, ce qui permet un temps de reconstruction proportionnel à l'usage et non à la capacité, ce qui stresse moins les disques, et les admins.
 - Déduplication : ZFS peut découvrir que des fichiers ou enregistrements sont similaires et éviter leur duplication, mais cela demande beaucoup de RAM.
-- Instantanés : ZFS permet de prendre à très peu de frais des snapshots, tout comme Git permet de faire des branches. Ces snapshots sont plus rapide en activant le prefetch scan.
+- Instantanés/Clones : ZFS permet de prendre à très peu de frais des snapshots, tout comme Git permet de faire des branches. Ces snapshots sont plus rapide en activant le prefetch scan. Un clone permet de faire un dataset modifiable à partir d'un snapshot.
 - Compression : ZFS permet de compresser les données selon divers algorithmes (LZ4 usuel, GZIP recommandé parfois par exemple sur les données séquentielles comme des logs, ou certaines bases de données), cette compression est généralement considérée comme un gain de performances et d’espace, surtout quand le temps que cette (dé)compression prend au CPU est moindre que le temps d’accès au disque.
 - Chiffrement : ZFS permet (en version officielle depuis seulement mai 2019) de chiffrer et authentifier les données, ce qui permet notamment :
   - la compression (contrairement à ecryptfs).
@@ -321,6 +324,14 @@ Le chiffrement par ecryptfs ne permet ni compression, ni déduplication et rajou
 
 
 # Actions
+
+## Machine
+L'APU2 est la machine x86_64 (donc bien supportée par NixOS et GHC) basse conso, la plus ouverte (ce qui est bien dans l'esprit de Sourcephile), et elle devrait permettre d'assurer le plus important dans un premier temps.
+
+- https://www.fsf.org/resources/hw
+- https://wiki.debian.org/FreedomBox/Hardware
+- https://nixos.wiki/wiki/NixOS_on_ARM
+
 ## Réseau
 Un essai d’hébergement est expérimenté chez PTT, qui est à côté de chez julm.