1 # Une première infrastructure informatique pour Sourcephile
2 - Demande de Critiques: 8
3 - De: Julien Moutinho (julm)
6 - Révision: 4 (2020-01-22)
7 - Licence: Creative Commons BY-SA
9 - DDC8: Une infrastructure de développement pour Sourcephile
19 ## Analyses des préoccupations
20 ### [G] Pour l’indépendance
21 #### [G] Concernant les charges
22 - [G] julm: on est sur une dépense de ~300€ de matériel (~100€ de plus s’il n’y avait pas le réemploi d’un SSD) pour une espérance de fonctionnement et d’usage >5ans, et un récurrent de ~60€/an pour l’hébergement. C’est un prix très correct pour ce que c’est.
23 #### [T] Concernant l’autonomie
24 - [T] julm: on a la main sur le matériel, le logiciel, mais par tellement sur l’hébergement (toutefois 15km, ça reste à portée de vélo).
25 #### [C] Concernant les produits
26 - [C] julm: aucun service non-lié à la production n’est proposé aux membres.
27 ### [T] Pour la science
28 - [T] julm: on peut mettre du NixOS, mais ce n’est pas une machine avec beaucoup de CPU et de RAM, mais ça devrait largement suffire et me dépanner tant que je n’ai pas d’élec @home.
29 ### [T] Pour la production
30 - [T] julm: la machine peut suffire pour commencer, l’hébergement aussi mais peut rapidement être limitant (ce n’est qu’une VDSL2+). Côté sécurité on est en open-source, mais que partiellement en matériel ouvert. Mutualiser pleins de services sur une seule machine n’est pas l'idéal mais un cloisonnement `systemd-nspawn` (sans virtualisation) devrait suffire puisque tous les services seront sous GNU/Linux et contrôlés par nous. L’hébergement est semi-professionnel, sécurité raisonnable vue les enjeux. Côté maintenance on peut mettre du NixOS ce qui me simplifiera la tâche. L’hébergeur n’offre pas (encore) de seconde connexion via le port série et n'est que semi-professionnel, par contre il est proche.
31 ### [A] Pour l’essaimage
32 - [A] julm: on est en logiciel libre, mais que partiellement en matériel ouvert. Deux raisons bloquantes à cela : le manque de support de NixOS (quid de Guix ?) et plus gravement de Haskell pour les architectures ARM qui sont davantage ouvertes.
33 ### [A] Pour la coopération
34 - [A] julm: les machines sont fabriquées à l'autre bout de la planète dans des conditions sociales probablement déplorables.
35 ### [A] Pour l’environnement
36 - [A] julm: c’est une machine très basse consommation, dans un pays où l'électricité essentiellement nucléaire est très bas carbone, mais c’est quand même une consommation pour sa fabrication, ce n'est pas un achat d'occasion.
41 ### S'émanciper d'autogeree.net
42 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.
44 `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).
45 `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).
47 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.
49 ### S'émanciper de Debian
50 Depuis que je me suis mis à NixOS, je ne suis plus enthousiasmé par Debian. En tant que dev il est bien plus facile de faire et de partager de manière reproductible et récente des paquets NixOS que des paquets Debian (dans le cas de paquets Haskell tout du moins). Et en tant qu'adminsys il est bien plus facile de maîtriser ce qu'il se passe sur une NixOS que sur une Debian. Le seul avantage de Debian en ce qui me concerne c'est sa plus grande portabilité sur des architectures basse conso ou OSHW comme certaines ARM ou MIPS (en fait non, mon Yeeloong de Lemote a été volontairement rendu inutilisable par Debian). Mais ce n'est **certainement** qu'un avantage temporaire.
51 Pour approfondir ces raisons techniques, on peut voir par exemple les tutoriels francophones de Nokomprendo : https://nokomprendo.gitlab.io/
53 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).
56 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é : aider des personnes à construire le Logiciel Libre et l'Internet.
58 ### Objectif minimal : infra de publication
59 Cet objectif adresse en priorité les besoins de diffusion au public du travail des membres contributeurs : dépôts des sources, dépôts des binaires, pages Web d'informations. Le public n'y a que des accès en lecture seule.
61 - Noms de domaine (nsd4 | unbound | knot)
62 - Shell distant SSH (openssh)
63 - Pare-feu (shorewall)
64 - Forge logicielle (gitolite, gitweb, nginx)
65 - Dépôts binaires (cachix, apt)
66 - Site Web de rendu des journaux de bord (nginx)
67 - Site Web de rendu des demandes de critiques (nginx)
68 - Site Web de rendu des documentations (nginx)
69 - Certificats X.509 pour du HTTPS (certbot, nginx)
70 - Clés de signature et d'authentification dédiées OpenPGP (gnupg, openpgp2ssh)
71 - Authentifications secondaires dédiées (nitrokey | yubikey | solokey)
72 - Monitoring (monit | prometheus | icinga2)
74 ### Objectif modeste : infra d'équipement interne
75 Cet objectif adresse en priorité les besoins d'équipement des membres contributeurs : stockages sécurisés et connexions sécurisées. Le public n'y a aucun accès d'usage, mais peut avoir des accès en écriture ou lecture selon des interfaces restreintes et contrôlées.
77 - Adresses méls (postfix, dovecot2, rspamd)
78 - Listes méls internes (aliases postfix)
79 - Écriture collaborative en ligne en temps réel (gobby | etherpad-lite | prose)
80 - Messagerie instantanée (prosody | matrix)
81 - Chiffrement du stockage (ZFS, dm-crypt, dropbear)
82 - Gestion des accès (unix | openldap | intégré aux applications)
83 - Partages volumineux en ligne (nextcloud)
84 - Partages textuels jetables (pastebin)
85 - (optionnel) Calendriers en ligne (davical | nextcloud)
86 - (optionnel) VPN DNS (iodined)
87 - (optionnel) VPN (wireguard)
88 - (optionnel) Audioconf (mumble)
89 - (optionnel) Visioconf (jitsi)
90 - (optionnel) Partages binaires jetables (coquelicot)
92 ### Objectif honorable : infra de contribution publique
93 Cet objectif adresse en priorité les besoins de communication en ligne entre les membres contributeurs et le public : sites Web de présentation et réseaux sociaux en ligne.
94 - Rapports de bugs (gitlab | gitea)
95 - Messagerie instantanée (salon IRC type #sourcephile@irc.geeknode.net | prosody externe)
97 - Site Web des (futures) démonstrations (judgmentphile, docphile, ledgerphile, relotophile)
98 - Listes méls publiques (discourse | public-inbox | sympa)
99 - Forums publics (discourse)
101 ### Objectif ambitieux : infra de mise en commun
102 Cette objectif adresse en priorité les besoins de la mise en commun en ligne.
104 - (optionnel) Microblogging (mastodon | serveur externe)
106 ### Objectif maximal : infra de services
112 PTT est une association qui tient un (tiers-)lieu à Tarnac en Corrèze.
113 Il est possible d’y héberger de petites machines à basse consommation pour 2€/mois (plus 3€/IPv4) (plus une cotisation de 10€ + prix-libre), dans une salle dédiée aux serveurs.
114 Tarnac est au milieu du plateau de Millevaches, autrement dit en périphérie d’Internet.
115 Le réseau est une VDSL2 fournie par Ilico/Grenode/Ielo-Liazo/Orange, soit environ 40Mbps descendant et 12Mpbs montant (mais pour l'ensemble de l'hébergement !).
118 Tetaneutral est une association à but non-lucratif basée à Toulouse.
119 Tetaneutral est bien établie et active dans le portage de la cause de l’Internet libre.
120 Il est possible d’y héberger de petites machines à basse consommation pour 5€ à 10€ par mois, dans une salle du squat artistique Mix'art Myrys :
121 http://tetaneutral.net/adherer/
122 Le réseau est une fibre optique directement reliée à centre de données Cogent voisin :
123 https://tetaneutral.net/historique/
126 Il faudrait voir avec fremo ce qui est possible.
129 #### APU2 de PCengines
130 L’APU2 est un routeur conçu par une entreprise suisse (PCengines) et fabriqué à Taïwan. Le CPU est un AMD, dont l'architecture « x86_64 » est officiellement supportée par GHC, NixOS et ses caches binaires. Ce n'est pas complètement en matériel ouvert car certains composants clés comme le CPU ne le sont pas, mais PCengines publie ce qu'elle fait elle pour sa part (schémas et code source des modifications à Coreboot).
132 PCengines a une renommée et une maturité certaine dans la conception de machines (ce n'est pas leur première), il ne s'agit donc pas de produits issus d'une random startup d'amateur.rices, ou autres personnes davantage préoccupées par le time-to-market plutôt que par le long-time-support. L’APU2 est explicitement vanté, et ses composants choisis, pour assurer sa disponibilité sur le « long-terme ».
134 L’APU2 est généralement utilisé comme routeur, mais peut aussi servir de petit (en terme de services peu gourmands côté serveur) serveur, voire de petit (en taille de stockage) « NAS » (Network Attached Storage), voire de petite (en puissance de calculs) machine de développement pour dépanner.
136 L’APU a plusieurs versions : APU2, APU3 et APU4. L'APU2 est annoncé comme celui consommant le moins : de 4W (idle) à 10W max contre 12W max pour l’APU3 et l’APU4, et la version 4Go de RAM de l'APU2 a une NIC i210AT légèrement meilleure que la i211AT des autres. L’APU3 est optimisé pour faire de la 3G/LTE. Et l’APU4 a un quatrième port Ethernet, mais ne rentre pas dans l’enclosure RMT-CASE-S1 permettant de mettre des disques supplémentaires. Après vérification de première main, l’APU2E4 avec un seul SSD 2.5" monte a 12W en ondemand et `stress --cpu 4` d'après `sensors fam15h_power-pci-00c4` (il faudrait tout de même vérifier avec un instrument de mesure externe).
139 - https://pcengines.ch/howto.htm
140 - https://openwrt.org/toh/pcengines/apu2
141 - https://www.cs.cmu.edu/~davide/howto/apu4c4.html
142 - https://blog.linuxserver.io/2016/12/17/review-pcengines-apu2-c4-prebuilt-by-linitx/#vpnperformance
143 - https://teklager.se/en/knowledge-base/
145 ##### Caractéristiques
146 - Processeur : AMD G series GX-412TC (Turbo Core), 4x 1GHz Jaguar core with 64 bit support
148 - http://www.cpu-world.com/CPUs/Puma/AMD-G-Series%20GX-412TC.html
149 - http://support.amd.com/TechDocs/52740_16h_Models_30h-3Fh_BKDG.pdf
150 - 170€HT, http://store.clemanis.com (PCE-APU2E4)
151 - 148€HT, https://teklager.se/en/products/router-components/pc-engines-apu2d4
152 - 128€HT, https://www.wispmax.com/pc-engines-apu2b4-system-board.html
153 - Coprocesseur : AMD CCP avec AES-NI
154 - https://openwrt.org/toh/pcengines/apu2#cryptographic_hardware
155 - Cache L1 : 32K data cache + 32K instruction cache per core
156 - Cache L2 : 2MB shared
157 - Mémoire : 1x 4Go DDR3-DRAM 1333Mhz ECC (soudée !)
158 - Stockage : Boot from SD card (built-in adapter, connected through USB), USB or m-SATA SSD. 1 SATA data + power connector
159 - Électricité : 12V DC. About 6 to 10W depending on CPU load. Recommend for at least 1.5A to provide margin for peripherals
160 - Extensions : 2 miniPCI express (one with SIM socket for 3G modem), LPC bus, GPIO header, optional I2C bus, COM2 (3.3V RXD/TXD)
161 - Réseau : 3x Gigabit Ethernet (Intel i210AT), 1 DB9 serial port (console)
162 - https://www.intel.com/content/dam/www/public/us/en/documents/faqs/ethernet-controller-i210-i211-faq.pdf
163 - the i210AT is better, as it has 4 transmit and 4 receive queues, where the i211AT only has 2/2
164 - Firmware : CoreBoot (build 20170228) open source system BIOS with support for iPXE and USB boot
166 - 35€HT, 245mm x 157mm x 39mm, espace pour 3 disques 2.5" (2 dedans, 1 dehors), http://store.clemanis.com (RMT-CASE-S1)
167 - 12€HT, 152,4mm x 152,4mm, aucun espace pour le moindre disque 2.5", https://teklager.se/en/products/router-components/pc-engines-apu-enclosure
168 - Refroidissement : conductive cooling from the CPU to the enclosure
169 - Conception : Suisse
170 - Fabrication : Taïwan
173 4GB de RAM ce n’est pas énorme, c'est trop peu pour une machine de dév (surtout si elle n'est pas dédiée) ou de build, mais pour un serveur hébergeant des services de base c'est pas mal. D’un point de vue sécurité, il me semble d'ailleurs préférable d'avoir plusieurs petites machines physiques distinctes qu’une grosse machine blindée hébergeant des machines virtuelles. Machines blindées qu'on ne trouvera d'ailleurs **probablement** pas de si tôt en matériel ouvert.
174 La RAM a de l’ECC (Error Correcton Code), supportée depuis peu dans le firmware de l’APU2.
175 La RAM est soudée donc il faudra malheureusement changer toute la carte mère si elle vient à avoir des défaillances (testables en 2 heures avec Memtest86++).
177 Le micrologiciel d’usine permet de faire un Memtest86+. Au préalable il faut installer deux dissipateurs de chaleur et la carte-mère dans le chassis, pour refroidir comme il faut le CPU. Dans une salle à vivre, la température affichée par Memtest86+ ne dépasse pas 52°C.
179 ZFS serait lent avec 2GiB de RAM, 4GiB sont recommandés pour des performances normales pour des tâches courantes : https://github.com/zfsonlinux/zfs/wiki/Debian-Buster-Root-on-ZFS
181 4Go de RAM permet de rester en 32 bits, mais ZFS recommande 64 bits : https://github.com/zfsonlinux/zfs/wiki/FAQ#32-bit-vs-64-bit-systems
182 Il faudra faire attention à bien configurer ZFS pour qu'il ne consomme qu'une part contrôlée de la RAM. Il est fort probable qu'activer de la déduplication ZFS soit trop gourmande en RAM : https://wiki.freebsd.org/ZFSTuningGuide#Deduplication
184 La mise-à-jour du micrologiciel peut se faire à distance avec quelque chose du genre :
185 > git clone https://github.com/3mdeb/3mdeb-secpack
186 > gpg --import 3mdeb-secpack/**/*.asc
187 > gpg --verify canaries/pcengines/canary-002-2019.txt{.sig.piotr-krol,}
188 > gpg --verify canaries/pcengines/canary-002-2019.txt{.sig.miczyg,}
189 > wget -c https://3mdeb.com/open-source-firmware/pcengines/apu2/apu2_v4.11.0.2{.rom,.SHA256{,.sig}}
190 > gpg --recv-keys 0x3B710228A4774C4FCB315876233D0487B3A7A83C
191 > gpg --verify apu2_v4.11.0.2.SHA256{.sig,}
192 > sha256sum --check apu2_v4.11.0.2.SHA256
193 > flashrom -w apu2_v4.11.0.2.rom -p internal
194 > setpci -s 18.0 6c.L=10:10 # Force cold reboot
198 Il est possible de mettre facilement deux disques SSD avec un APU2 dans la RMT-CASE-S1 : un sur le port mSATA et un sur le port SATA. Les vis tenant les disques sont pénibles à mettre et peuvent tordre le chassis si trop serrés. Le port d'alimentation à 2 broches est un peu atypique et peut poser des problèmes (mauvaise connexion sur un modèle reçu par Franciliens). Globalement, le format de port mSATA est entrain d'être remplacé par le port M.2, ce qui pose la question de pouvoir trouver de bons SSD mSATA dans un futur proche, mais Clemanis vend un adaptateur mSATA-SATA laissant toujours la possibilité de n’utiliser que des disques SATA. Il est aussi possible de mettre une extension PCIe pour rajouter 4 ports SATA : https://pcengines.ch/howto.htm#add_on_cards
199 Il est également possible de mettre une carte SD, mais les cartes SD tendent à mourrir plus vite et sont plus lentes.
203 > The throughput depends very much on the OS, Linux based distributions perform much better than BSD based. Under Linux forwarding packets without filtering etc. a throughput of about 900-950Mbps can be achieved. Under BSD based OS, like pfSense, OPNSense, etc the max. throughput is about 600-650Mbps.
205 Quelques commentaires signalent que l’APU2 sature à 45Mpbs avec OpenVPN en AES, OpenVPN ne pouvant utiliser qu'un seul coeur de CPU (single thread). L'APU2 aurait une horloge CPU trop lente et un cache L2 trop petit. Mais ici le VPN n'est pas un objectif.
206 - https://www.reddit.com/r/PFSENSE/comments/4nmuu4/my_pc_engines_apu2c4_experience/
209 La présence d’un port série permet un accès de maintenance plus simple et plus sécurisé que de l’IPMI (qui est un second OS en parallèle).
210 Mais il faut que l’hébergement propose un accès secondaire via un port série, ce qui n’est plus usuel.
214 - 17€HT, https://www.ldlc.com/fiche/PB00026389.html
215 - 11€HT, https://teklager.se/en/products/router-components/serial-to-usb-cable
216 - 20€HT, http://store.clemanis.com/en/cables/566-kit-usb-to-serial-db9-female-for-alix-apu-3700667301720.html
217 - null-modem "DB9" serial cable, 5€HT, https://www.ldlc.com/fiche/PB00170050.html
220 > picocom -b 115200 -f h /dev/ttyUSB0
223 Il existe de nombreuses enclosures, mais essentiellement deux modèles.
224 Les noires dissipent mieux la chaleur : https://openwrt.org/toh/pcengines/apu2
225 La RMT-CASE-S1 de Clemanis (pour APU2 ou APU3 seulement !) est 15€ plus chère que d’autres enclosures plus petites, mais permet de stocker deux disques 2.5" dans l'enclosure et un sur le dessus pour un total de 4 disques avec le mSATA, ou de mettre une extension : http://store.clemanis.com/en/cases/324-pc-engines-alix-2d22d32d13-apu1apu2-case-with-hdd-wifi-black-3700667301379.html
228 #### SSD (Solid State Disk)
230 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/
231 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/
234 Les SSD sont moins performant que les HDD en terme d'octet par euro.
237 Les SSD sont bien plus rapide que les HDD.
238 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.
239 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
240 Ainsi un 128Go écrira séquentiellement à 320Mo/s (Kingston) ou 410Mo/s (Samsung). Mais un 250Go écrira séquentiellement à 500Mo/s (Kingston) ou 520Mo/s (Samsung).
241 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.
242 Avec du SSD, de surcroît avec ZFS qui a son propre ordonnanceur, il est recommandé de mettre queue/scheduler=none.
245 > dd if=/dev/zero of=/path/to/disk/tempfile bs=1M count=1024 conv=fdatasync,notrunc status=progress
246 > fio --name fio.tmp --rw=write --direct=1 --iodepth=32 --ioengine=libaio --bs=1M --numjobs=4 --size=1G --group_reporting
249 Les SSD meurent bien plus rapidement que les HDD. Ils sont donc encore moins adaptés au stockage de long-terme.
250 Les fabricants de SSD annonce une espérance de vie en Terabytes Written (TBW) ou Drive Writes Per Day (DWPD).
251 Les disques fournissent des attributs SMART :
252 > smartctl -a /dev/sda
254 Il est important d'activer le TRIM du système de fichier pour que l'effacement ne consomme pas les ressources du SSD. ZFS supporte cela depuis peu.
256 Après plus de 5 ans d’usage laptop relativement intensif, mon SSD Samsung 128G affiche encore 75% de santé.
259 Réserver une partie du SSD pour le swap est utile, notamment pour faire des tmpfs.
260 Mettre le swap dans ZFS semble le plus propre mais il existe encore un bug connu sévère qui le déconseille : https://github.com/zfsonlinux/zfs/issues/7734
261 Il ne servirait à rien de mettre le swap dans le RAID, il suffit juste de mettre le swap dans un LUKS dédié pour le chiffer (avec une nouvelle clé éphémère à chaque boot) et d’ajouter les devices déchiffrés à la liste des swaps gérés par le noyau Linux.
264 > stress --vm 10 --vm-keep --vm-bytes 512M
266 Configuration du noyau Linux :
270 Si un SSD 4KB est utilisé pour le boot, un coreboot supportant UEFI devra être installé car GRUB ne supportera pas BIOS pour les disques 4KB : http://savannah.gnu.org/bugs/?46700
271 La taille physique des secteurs est donnée par fdisk -l ou /sys/block/sd*/queue/physical_block_size
274 - https://www.fnac.com/mp37714266/Transcend-ts128gmsa230s-ssd-interne-msata-iii-128-go-sata-iii-6-gbps-3d-tlc/w-4
275 - https://www.ldlc.com/fiche/PB00253086.html
278 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.
279 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.
280 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.
281 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.
282 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/
283 ZFS aurait une taille de son code source équivalente à 10 fois celle d’EXT4, mais ZFS remplace aussi MD, LVM, dm-crypt, …
284 ZFS ne peut légalement pas être intégré directement au noyau Linux mais cela est bien géré par NixOS.
286 Quelques fonctionnalités / concepts de ZFS (mais voir surtout les man zfs(8) et zpool(8))
287 - CoW (copy-on-write) : consiste à ne pas écraser un enregistrement lorsqu'il y a 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.
288 - Pool storage (hot add disks) : pas besoin de décider à l'avance de la taille de partitions ou de les redimensionner.
289 - ZIL (ZFS Intent Log) : cache des écritures synchrones. Utile lorsqu'il y a beaucoup d’écriture synchrones ou pour servir des fichiers qui changent fréquemment. Peut être suivi avec `dstat --zfs-zil`.
290 - 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().
291 - ARC (Adjustable Replacement Cache)/ : cache en RAM auto-ajusté entre MRU/LRU et MFU/LFU. Cache ce qui a été le plus récemment utilisé (MRU) et le plus fréquemment utilisé (MFU). ˋarc_summaryˋ permet d'afficher l'état de l'ARC. Peut être suivi avec `dstat --zfs-arc`.
292 - L2ARC (Level 2 ARC) : cache de lecture optionnel sur disque (SSD, pour être utile) qui stocke les données balayées de l’ARC. Le contenu du L2ARC est référencé dans l’ARC et occupe donc de la RAM (~25MB d’ARC par GB de L2ARC). Par conséquent utiliser un L2ARC dans un système qui n’a pas une quantité de RAM suffisante nuit aux performances en imposant une pression sur l’ARC : les données qui auraient pu être servies depuis la RAM de l’ARC devront maintenant être servies depuis le SSD du L2ARC. Un système avec moins de 8Gio de RAM n’a pas besoin de L2ARC. 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 ». Peut être suivi avec `dstat --zfs-l2arc`.
293 - Quotas et réservations.
294 - Héritage des propriétés entre les datasets.
295 - Délégation fine des droits d'administration à des utilisateurs (ˋzfs allowˋ).
296 - 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. Si plus d’une copie (copies= strictement supérieur à 1) est disponible et qu’une des copies est détectée comme corrompue, ZFS retournera seulement la copie valide et réparera les enregistrement endommagés. Si une erreur mais pas de copie pour réparer, ZFS signalera l'erreur au lieu de la passer sous silence.
297 - Scrubing (self-healing) : ˋzpool scrubˋ permet de faire une lecture réparatrice de tout ce qu'il y a dans un pool. Aussi lent que le pool contient de données. Il est important de la faire régulièrement automatiquement, cela ne devrait pas interférer avec les autres applications car le scrubing utilise les ressources avec une faible priorité.
298 - Send/Receive : ˋzfs sendˋ et ˋzfs receiveˋ permettent d’envoyer et de recevoir entièrement ou incrémentalement des captures instantanées (snapshots) vers d’autres machines. Ce transfert peut être effectué sans décompresser/déchiffrer puis compresser/chiffrer (avec `zfs send --raw`). Très utile pour faire des sauvegardes à distance à travers nc, ssh, ou mbuffer pour aller plus vite.
299 - 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. Cependant cela peut tout de même prendre un temps à ne pas négliger, donc à tester pour ne pas avoir la surprise lors d'une crise, et pouvoir agir en conséquence avant, par exemple en mettant plus de disques de mirroir ou de parité, ou en utilisant du declustering raidz pour faire du load-balancing sur les disques et donc accélérer le resilvering.
300 - Déduplication : ZFS peut découvrir que des fichiers ou enregistrements sont similaires et éviter leur duplication, mais cela demande beaucoup de RAM.
301 - Snapshots/Clones/Rollback : ˋzfs snapshotˋ permet de prendre des instantanés au niveau d'un dataset en temps quasi-constant, tout comme Git permet de faire des branches. Directement lisibles en lecture-seule dans [dataset]/.zfs/snapshots/. La prise automatisée et régulière de snapshots est très utile pour toutes sortes d'applications et protections (erreurs de manipulations, ransomware). Plus rapide en activant le prefetch scan. ˋzfs cloneˋ permet de faire un dataset modifiable à partir d'un snapshot. ˋzfs rollbackˋ permet de réinitialiser un dataset à un ancien snapshot.
302 - 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.
303 - Chiffrement : ZFS permet (en version officielle depuis seulement mai 2019) de chiffrer et authentifier les données, ce qui permet notamment :
304 - la compression (contrairement à ecryptfs).
305 - de faire des sauvegardes de dossiers spécifiques sans déchiffrer les données.
306 - de faire du chiffrement de bout en bout (end-to-end) avec (zfs send).
307 D’après man zfs, sont chiffrées : zvol data, file attributes, ACLs, permission bits, directory listings, FUID mappings, and userused / groupused data.
308 Ne sont pas chiffrées : metadata related to the pool structure, including dataset and snapshot names, dataset hierarchy, properties, file size, file holes, and deduplication tables.
309 Le fait que tout ne soit pas chiffré peut être inquiétant mais permet d'effectuer des opérations de maintenance sur les données sans nécessiter de pouvoir les déchiffrer.
310 Le chiffrement peut être activé en cours de route, mais ne concernera que les données qui seront écrite par la suite.
311 Il est important d’avoir un support des instruction AES-NI, qui en plus d’améliorer le SSH, le VPN, le HTTPS, améliore le chiffrement du stockage lorsque de l'AES est utilisé.
314 - https://wiki.debian.org/ZFS
315 - https://github.com/zfsonlinux/zfs/wiki/Debian-Buster-Root-on-ZFS
316 - https://wiki.archlinux.org/index.php/ZFS
317 - https://nixos.wiki/wiki/NixOS_on_ZFS
318 - https://wiki.freebsd.org/ZFSTuningGuide
319 - https://www.unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html
321 #### RAID (Redundant Array of Inexpensive Disks)
322 La réplication entre deux disques ou plus permet de se prémunir contre la défaillance matérielle d'un des deux disques. Le coût à payer est d’acheter un deuxième disque (pas forcément d'emblée) et de supporter un temps de lecture qui peut aller jusqu'à la somme de celui de chaque disque, et un temps d'écriture qui égal à celui du disque le plus lent.
323 RAID est une solution de réplication matérielle ou logicielle bien établie.
324 RAID permet d’appliquer la réplication en dessous du chiffrement LUKS, alors que la réplication ZFS intervient en dessus du chiffrement LUKS, causant un chiffrement par disque de toute écriture. Toutefois, l’APU2 ayant un coprocesseur pour les AES-NI, en utilisant --cipher aes-xts-plain64 pour LUKS ces chiffrements supplémentaires n’auraient probablement pas d’un impact significatif sur les performances justifiant d’abandonner la flexibilité de ZFS.
326 Le RAID logiciel peut être contrôlé par mdadm ou LVM (--type=raid), le backend mdraid est le même mais ce n'est pas compatible, mdadm est plus établi et abouti que LVM.
328 Si cette pénalité devient trop importante, un RAID5 (ou raidz) pourra être envisagé : https://serverfault.com/questions/830708/raid-1-to-raid-5-using-mdadm .
329 Voire plutôt RAID6 qui n'a pas qu'un seul disque de parité, car le remplacement d'un disque est un facteur de défaillance des autres disques.
330 RAID (surtout RAID-5) a un problème fondamental lors de l’écriture appelé write-hole, que n'a pas ZFS : les écritures de données et de parités ne sont pas atomiques, par conséquent une coupure de courant au mauvais moment peut produire un état où les données sont écrites mais pas les parités : http://www.raid-recovery-guide.com/raid5-write-hole.aspx .
331 Cela semble toutefois corrigé désormais : https://lwn.net/Articles/665299/ .
333 #### LUKS (Linux Unified Key Setup)
334 dm-crypt avec entêtes LUKS permet un chiffrement au niveau des block devices, et non uniquement au niveau du contenu ou des métadonnées des fichiers comme ZFS ou ecryptfs.
336 LUKS sera utile pour chiffrer le swap (qui ne peut pas encore être mis dans ZFS de manière fiable), et éventuellement le chiffrement complet du disque (c’est-à-dire de l’initrd et du kernel, mais pas du firmware ou du bootloader), auquel cas il faudra utiliser un LUKS1 (et pas LUKS2) tant qu’une version stable de GRUB ne supportera pas LUKS2.
337 GRUB2 supporte désormais LUKS2: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755
339 Pour benchmarker LUKS : https://unix.stackexchange.com/questions/254017/how-to-interpret-cryptsetup-benchmark-results
340 > cryptsetup benchmark
342 Pour de l’AES-128 cela donne :
343 > cryptsetup luksFormat --iter-time 2s --hash sha256 --cipher aes-xts-plain64 --keysize 256 /dev/sdX
344 XTS est recommandé pour chiffrer des block devices, à noter toutefois qu’XTS sépare la clé en deux, ce qui nécessite de doubler --keysize.
347 Le chiffrement par ecryptfs ne permet ni compression, ni déduplication (pas très grave) et rajoute des métadonnées en entête, ce qui prend (un peu) de place.
349 #### LVM (Linux Volume Manager)
351 ### LDAP (Lightweight Directory Access Protocol)
352 LDAP est une base de donnée adaptée au lectures très fréquentes et aux écritures infréquentes, contrairement à un MySQL ou PostgreSQL. Il vient surtout avec un ensemble de schémas pour gérer des comptes d'utilisateur.rices, et un bon support dans Postfix et Dovecot, qui peuvent lui déléguer totalement l'authentification.
355 - https://www.zytrax.com/books/ldap/ch2/index.html#history
360 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.
362 - https://www.fsf.org/resources/hw
363 - https://wiki.debian.org/FreedomBox/Hardware
364 - https://nixos.wiki/wiki/NixOS_on_ARM
367 Un essai d’hébergement est expérimenté chez PTT, qui est à côté de chez julm.
370 Le stockage assure ici :
371 - du cache (LUKS+swap)
372 - du chiffrement (ZFS encryption)
373 - de la réversibilité (ZFS snapshots)
374 - de la sauvegarde (ZFS snapshots et `zfs send`)
375 - et de la base de données (ZFS customisé).
377 Le stockage n’assure pas ici :
378 - de la réplication (ZFS mirror/raidz) : tant que les services applicatifs pourront supporter une coupure de quelques jours, il n’y a pas de réplication en temps-réel, mais il faudra avoir un SSD de dépannage et réformer celui en production lorsqu’il sera descendu à 70% de santé. Mais une surveillance accrue de l’usure des disques et des sauvegardes régulières doit donc être menée.
381 Réemploi d’un Samsung 840 EVO (mieux que QVO) de 250GB, sans condensateur interne, que je possède mais n’ai que très peu utilisé jusque là (janvier 2020) :
382 > % smartctl-tbw /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R
383 > /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R Power_On_Hours 1437 hours / 59 days / 0.16 years
384 > /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R Wear_Leveling_Count 99 (% health)
385 > /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R Airflow_Temperature_Cel 24
386 > /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R Total_LBAs_Written 685441898 / 334688 mb / 326.8 gb / 0.319 tb
387 > /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R mean writes per hour: 232.91
389 > % fdisk -l /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R
390 > Disk /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R: 232.9 GiB, 250059350016 bytes, 488397168 sectors
392 > Units: sectors of 1 * 512 = 512 bytes
393 > Sector size (logical/physical): 512 bytes / 512 bytes
394 > I/O size (minimum/optimal): 512 bytes / 33553920 bytes
395 > Disklabel type: gpt
396 > Disk identifier: E42083E9-58B2-4CD0-B716-2B923C6B8007
399 Un amorçage BIOS est utilisé (`boot.grub.devices = [ "/dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSAF340110R" ]`), mais pas la partition EFI (`boot.grub.efiSupport = false`) qui est tout de même allouée si besoin un jour.
401 La table de partition est au format GPT, qui se retrouve de plus en plus dans les tutos que MSDOS, tout en étant bien supporté par les outils.
402 Les UUID sont randomisées (avec ˋsgdisk -Gˋ) et distincts d'un disque à l'autre.
404 Il ne semble pas nécessaire de faire une partition de secours (rescue), une clé USB, un accès par port série ou un busybox sur /boot devrait suffire.
405 La partition /tmp sera un tmpfs utilisant la RAM et les 4 à 8G de swap.
406 Les logs sont sur un dataset séparé pour garantir fortement qu'elle ne remplira pas celle des données, pour faciliter la sauvegarde et pour que déchiffrer les logs,n'implique pas de déchiffrer les données.
409 > Disque /dev/sda : 232,9 GiB, 250059350016 octets, 488397168 secteurs
410 > Modèle de disque : Samsung SSD 840
411 > Unités : secteur de 1 × 512 = 512 octets
412 > Taille de secteur (logique / physique) : 512 octets / 512 octets
413 > taille d'E/S (minimale / optimale) : 512 octets / 512 octets
414 > Type d'étiquette de disque : gpt
415 > Identifiant de disque : 161F060D-FF6C-4FDA-8A2D-483F4155D35E
417 > Périphérique Début Fin Secteurs Taille Type
418 > /dev/sda1 48 2047 2000 1000K Amorçage BIOS
419 > /dev/sda2 2048 1050623 1048576 512M Système EFI
420 > /dev/sda3 1050624 3147775 2097152 1G Système de fichiers Linux
421 > /dev/sda4 3147776 11536383 8388608 4G Système de fichiers Linux
422 > /dev/sda5 11536384 488397134 476860751 227,4G /usr Solaris et ZFS Apple
425 > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
426 > sda 8:0 0 232,9G 0 disk
427 > ├─sda1 8:1 0 1000K 0 part
428 > ├─sda2 8:2 0 512M 0 part /boot/efi
429 > ├─sda3 8:3 0 1G 0 part /boot
430 > ├─sda4 8:4 0 4G 0 part
431 > └─sda5 8:5 0 227,4G 0 part
434 > /dev/sda1: PARTLABEL="bios" PARTUUID="e8f0f747-41e3-47a9-a813-a7b422aeb62c"
435 > /dev/sda2: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="62E6-E65F" TYPE="vfat" PARTLABEL="uefi" PARTUUID="76ee8adb-d5c3-4b23-a895-2ad23519b73d"
436 > /dev/sda3: UUID="dc3c5387-17d2-43b3-bfa2-bf73afacca07" TYPE="ext2" PARTLABEL="boot" PARTUUID="82f5139d-19ba-4746-a6a5-70f8901530d5"
437 > /dev/sda4: PARTLABEL="swap" PARTUUID="6b1eaa35-776b-4e60-b21e-7bcee535dd8b"
438 > /dev/sda5: LABEL="rpool" UUID="4051860347751825829" UUID_SUB="15749116107064223960" TYPE="zfs_member" PARTLABEL="rpool" PARTUUID="3d462265-6c51-42c0-8bd8-d585eb076677"
441 > NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
442 > rpool 226G 1,08G 225G - - 0% 0% 1.00x ONLINE -
445 > NAME USED AVAIL REFER MOUNTPOINT
446 > rpool 1,08G 218G 96K /
447 > rpool/home 96K 218G 96K legacy
448 > rpool/nix 1,08G 218G 1,07G legacy
449 > rpool/root 312K 218G 312K legacy
450 > rpool/var 1,18M 218G 236K legacy
451 > rpool/var/cache 96K 218G 96K legacy
452 > rpool/var/log 552K 218G 552K legacy
453 > rpool/var/mail 96K 218G 96K legacy
454 > rpool/var/tmp 136K 218G 136K legacy
455 > rpool/var/www 96K 218G 96K legacy
458 AES-128 est ici considéré comme suffisamment sécurisant vu le niveau de menace et de sécurité physique.
459 https://xkcd.com/538/
461 L’aes-xts en deux clés de 128 bits est choisi pour le swap. NixOS ne passe pas par /etc/crypttab, mais a `randomEncryption`.
462 Important d’utiliser device = /dev/disk/by-partuuid/… et pas /dev/disk/by-uuid/… or /dev/disk/by-label/… qui seront changées à chaque reboot, mais pas /etc/fstab du coup.
463 Important également d’utiliser /dev/urandom (le défaut) et pas /dev/random qui n’apporte aucune sécurité supplémentaire mais peut ralentir le boot significativement en épuisant l’entropie disponible.
466 > [ { device = "/dev/disk/by-partuuid/6b1eaa35-776b-4e60-b21e-7bcee535dd8b";
467 > randomEncryption = {
469 > cipher = "aes-xts-plain64";
470 > source = "/dev/urandom";
475 > cryptsetup benchmark
476 > # Tests approximatifs en utilisant uniquement la mémoire (pas de stockage E/S).
477 > PBKDF2-sha1 140334 itérations par seconde pour une clé de 256 bits
478 > PBKDF2-sha256 182044 itérations par seconde pour une clé de 256 bits
479 > PBKDF2-sha512 124830 itérations par seconde pour une clé de 256 bits
480 > PBKDF2-ripemd160 105025 itérations par seconde pour une clé de 256 bits
481 > PBKDF2-whirlpool 59795 itérations par seconde pour une clé de 256 bits
482 > argon2i 4 itérations, 174847 mémoire, 4 threads parallèles (CPUs) pour une clé de 256 bits (temps de 2000 ms demandé)
483 > argon2id 4 itérations, 179163 mémoire, 4 threads parallèles (CPUs) pour une clé de 256 bits (temps de 2000 ms demandé)
484 > # Algorithme | Clé | Chiffrement | Déchiffrement
485 > aes-cbc 128b 145,3 MiB/s 339,0 MiB/s
486 > serpent-cbc 128b 13,1 MiB/s 35,4 MiB/s
487 > twofish-cbc 128b 31,7 MiB/s 37,8 MiB/s
488 > aes-cbc 256b 116,0 MiB/s 276,3 MiB/s
489 > serpent-cbc 256b 14,5 MiB/s 35,4 MiB/s
490 > twofish-cbc 256b 34,5 MiB/s 38,2 MiB/s
491 > aes-xts 256b 227,7 MiB/s 225,6 MiB/s
492 > serpent-xts 256b 34,6 MiB/s 34,7 MiB/s
493 > twofish-xts 256b 36,4 MiB/s 37,4 MiB/s
494 > aes-xts 512b 201,9 MiB/s 201,8 MiB/s
495 > serpent-xts 512b 34,8 MiB/s 34,9 MiB/s
496 > twofish-xts 512b 36,8 MiB/s 37,3 MiB/s
501 > zfs send --raw sourcename@snapname | pv -rtab | time zfs receive -svF destination/dataset
502 Entre le disque SSD monté sur le port SATA, et un disque SSD externe (Samsung 860 EVO 1T) monté en USB3, le transfert va à ~110Mio/s (trois fois moins sans `--raw`), soit 15min pour transférer 100Gio.
503 `--raw` est ce qui permet de transférer sans {dé,re}compresser et {dé,re}chiffrer.
505 Entre deux pools mais à travers le réseau cette fois :
506 > [root@desthost] nc -l 8000 | mbuffer -q -s 128k -m 1G | pv -rtab | time zfs receive -svF destpool/destfs
507 > [root@srchost] zfs send --raw -I srcpool/srcfs@oldsnap sourcename@newsnap | mbuffer -q -s 128k -m 1G | pv -b | nc desthost 8000
509 En cas de coupure, il suffit de donner au send le receive_resume_token du receive pour reprendre où ça en était :
510 > [root@desthost] zfs get -H -o value receive_resume_token destpool/destfs
511 > [root@desthost] nc -l 8000 | mbuffer -q -s 128k -m 1G | pv -rtab | time zfs receive -svF destpool/destfs
512 > [root@srchost] zfs send -t $receive_resume_token | mbuffer -q -s 128k -m 1G | pv -b | nc desthost 8000
514 Il est possible d'utiliser `syncoid` pour simplifier :
515 > syncoid --sendoptions raw root@mermet.sourcephile.fr:rpool/var/redis losurdo_nvme/backup/mermet/var/redis
519 > [root@mermet:~]# sensors
521 > Adapter: PCI adapter
522 > temp1: +48.6°C (high = +70.0°C) (crit = +105.0°C, hyst = +104.0°C)
524 > fam15h_power-pci-00c4
525 > Adapter: PCI adapter
526 > power1: 4.23 W (interval = 0.01 s, crit = 6.00 W)
529 - `nsd4` prend minimum 100Mio de RAM.
530 - `unbound` pouvant également être serveur DNS faisant autorité, pour le peu de zones à annoncer, mélanger les deux pourrait suffire.
531 - `knot` est finalement choisi car il gère mieux le DNSSEC et le DNS dynamique (utile pour avoir un certificat wildcard Let's Encrypt), tout en ne consommant quasiment pas de RAM (~20Mio pour deux zones).
534 - https://www.bortzmeyer.org/separer-resolveur-autorite.html
535 - https://www.redpill-linpro.com/techblog/2019/08/27/evaluating-local-dnssec-validators.html
538 ### Machine d'orchestration
539 ### Machine de sauvegardes
540 Il est important de bien mettre en place une sauvegarde automatique, d’autant plus qu’il n’y a pas de réplication en temps-réelle mise en place sur un second disque.
541 ZFS (zfs send) devrait faciliter cette sauvegarde, en produisant notamment des sauvegardes directement lisibles/vérifiables, sans avoir besoin de restaurer la dernière version, juste de la déchiffrer.
543 D’autres outils sont pour l’instant écartés :
544 - duplicity : sauvegardes incrémentales requérant un snapshot complet et une liste de différences jusque là.
545 - BorgBackup : déduplication.
547 ### Machine de compilations
548 Il faut préalablement voir les performances que permet cette première machine, qui même si elles ne sont pas remarquables, peuvent suffire dans un premier temps.
550 - http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm
551 > The intel Core as found in the Core i5 is performing very well, but hyperthreading brings little benefit here (13%). Thus a CPU should be chosen with real cores
553 > In this test, the AMD was the fastest of all systems, and the ARM was the fastest fanless system and also the one delivering the highest throughput per cubic centimeter.
555 > Some tests run with the ramlat utility showed that the build time almost solely depends on the L1 cache speed, then a little bit on the L2 cache speed and then finally on the DRAM speed. It does not exactly depend on the memory bandwidth but rather latency.
557 Faire tourner `haskell-ide-engine` s'avère péniblement lent.
561 ### Vulnérabilités Metldown et Spectre
562 Problème : l’AMD GX-412TC de l’APU2 est vulnérable à Meltdown et Spectre. L’atténuation n’est que partielle : https://blog.3mdeb.com/2019/2019-05-29-spectre-and-meltdown-on-apu2/
564 Réponse : tous les CPU Intel ou AMD sont plus ou moins affectés par ces vulnérabilités.
565 Il semble que tout soit néanmoins atténué :
566 > git clone https://github.com/speed47/spectre-meltdown-checker.git
567 > spectre-meltdown-checker/spectre-meltdown-checker.sh
568 > Spectre and Meltdown mitigation detection tool v0.43-3-ga1a35c9
570 > Checking for vulnerabilities on current system
571 > Kernel is Linux 4.19.81 #1-NixOS SMP Tue Oct 29 08:20:09 UTC 2019 x86_64
572 > CPU is AMD GX-412TC SOC
574 > * CPU microcode is the latest known available version: NO (latest version is 0x7030106 dated 2018/02/09 according to builtin firmwares DB v130.20191104+i20191027)
576 > SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK
577 > Need more detailed information about mitigation options? Use --explain
578 > A false sense of security is worse than no security at all, see --disclaimer
580 ### L'APU2 n'a pas une alimentation redondée
581 Problème : l'alimentation est l'un des composants les plus susceptibles de ne plus fonctionner.
583 Réponse : entreposer une seconde alimentation à côté du serveur, de sorte à minimiser le temps de hors-service et que cela puisse éventuellement être fait par l'hébergeur.
585 ### L'APU2 n'est pas adapté à la virtualisation
586 Problème : pour faire de la virtualisation il est préférable d'avoir des CPU avec des instructions adaptées (VT), de la RAM en quantité (~512Mio/VM) et de l'IOMMU (pas encore stable dans l'APU2).
588 Réponse : la virtualisation est surtout adaptée lorsque ce ne sont pas les mêmes personnes qui gèrent les services, ou lorsqu'il faut faire tourner des OS différents. Mais dans le cas présent ce n'est pas le cas, donc des containers type LXC devraient suffire du point de vue d'une compartimentation sécuritaire.
590 ### L'APU2 n'a que 4GB de RAM
591 Problème : 4GB de RAM c'est peu.
593 Réponse : il est possible d'utiliser un swap en zram comme premier niveau de swap rapide, laissant le reste de la RAM pour autre chose (buffer/cache/...),
594 Avec l'algorithme de compression zstd, cela pourrait même prendre moins de CPU que du swap sur disque
595 où il faut changer de contexte, passer sur un thread qui fait l'I/O, qui se met à attendre, se refait réveiller plus tard, etc.
597 ### PTT ne propose pas d’accès secondaire par port série
598 Problème : l’APU2 n’a pas d’IPMI, seulement un port série, cependant PTT n'a pas de switch de ports série ou USB pour le moment, et ne sait pas trop comment gérer les accès d’un tel switch. Cet accès secondaire est important pour se prémunir contre un nouveau noyau qui ne démarre pas. Cependant le port-série ne permet pas de reboot électrique, pour un redémarrage aussi complet que possible (cold-boot).
600 Réponse : il faudrait probablement étudier et proposer nous même un switch permettant cela. Pour le cold-boot, utile surtout lors d'une mise-à-jour de coreboot, on peut désormais `setpci -s 18.0 6c.L=10:10` avant le reboot.
602 ### nsd4 et iodined nécessitent tous deux le port 53
603 Problème : normalement un serveur DNS faisant autorité (comme nsd4) et iodined sont incompatibles sur une seule et même IPv4 (à 3€/mois ici), car ils requièrent tous deux l’écoute sur le port 53 du DNS.
605 Réponse : ce n’est pas très propre, mais il est possible de mutualiser ce port avec une règle iptables du genre : `-A nat -p udp --dport 53 -m string --algo kmp --from 40 --hex-string |01|i|0b|sourcephile|02|fr|00| -j DNAT --to-destination :5353` où iodined écoute maintenant sur le port 5353.
607 ### ZFS n’est pas (trivialement) adapté aux bases de données
608 Problème : les bases de données ont des performances amoindries sous un ZFS qui n’est pas customisé pour. Le copy-on-write de ZFS peut avoir un impact négatif très significatif sur les applications dont le cœur de métier est de modifier des fichiers en place, comme MySQL ou PostgreSQL : https://wiki.freebsd.org/ZFSTuningGuide#Application_Issues
610 Réponse : on utilise actuellement du SSD pour tout (donc pour le ZIL qui gère les écritures synchrones, eg. O_SYNC) donc ça devrait aller sans L2ARC pour lequel l'APU2E4 n'a de toute façon pas assez de RAM. Il y a des atténuations possible à tester (sync=always, recordsize inférieur à 128k, …), il semble raisonnable à ce stade de ne pas chercher une optimisation prématurée en allouant une partition EXT4 de taille arbitraire et en s’imposant tout ce que ça implique de configuration de RAID/LUKS/LVM alors que ZFS nous permet justement de nous en passer. Il restera toujours possible de rajouter un SSD avec LUKS+EXT4 dédié aux bases de données si c’est vraiment trop problématique.
613 - https://www.percona.com/blog/2018/02/16/why-zfs-affects-mysql-performance/
614 - https://www.percona.com/resources/webinars/zfs-mysql
615 - https://www.percona.com/blog/2018/05/15/about-zfs-performance/
618 ZFS utilise la plus petite taille de bloc contenant les données et inférieure à recordsize.
619 Ainsi, avec recordsize=128K (le défaut), si on a un fichier de 500 octets de données, alors ZFS utilisera un bloc de 512 octets. Si on rajoute 20 octets de données, alors ZFS utilisera un seul block de 1024 octets. Et ainsi de suite jusqu’à atteindre le recordsize de 128Ko, de sorte qu’un fichier de 1Mo ZFS utilisera 8 blocs.
621 Mettre la page size de SQLite3 à la valeur du recordsize de ZFS peut aider.
622 Mais il n’y a pas moyen d’attacher un recordsize spécifique à un seul fichier.
624 ### Le chiffrement de ZFS limite le nombre de copies à 2
625 Problème : même sans activer une réplication (mirror ou raidz), ZFS permet de garder plusieurs copies de chaque fichier, mais lorsque ces fichiers sont chiffrés ce nombre est actuellement limité à 2.
627 Réponse : c’est déjà pas mal.
629 ### ZFS requiert de l’espace de stockage libre
630 Problème : ZFS fonctionne par copy-on-write ce qui implique qu’écrire demande beaucoup plus d’espace libre que pour d’autres systèmes de fichiers. Même pour écraser un fichier il faut de l’espace libre ! En outre, comme pour tous les systèmes de fichiers, l’espace disponible annoncé avant son utilisation est généralement supérieur à l’espace utilisable mesuré fichier à fichier, ce qui peut quand même représenter quelques Gio de moins sur 100Gio.
632 Réponse : ZFS nécessite de veiller à la RAM et au stockage libre, il faut veiller à ce que ZFS ait toujours au moins 20% d’espace libre pour ne pas avoir de pertes de performances et éviter de taper toujours sur les mêmes secteurs du SSD, ce qui diminuerait sensiblement son espérance de vie. Concernant le calibrage de l’espace, il vaut toujours mieux utiliser `du` (ou `ncdu`) que `df`.
634 ## Question non-résolues
638 ### RAID+LUKS+LVM+ext4 au lieu de ZFS
639 La réplication peut être assurée par RAID (RAID1) au lieu de ZFS (mirror ou raidz).
641 Le chiffrement par dm-crypt+LUKS au-dessous de ZFS a pour désavantages d'impliquer que les copies/réplications de ZFS sont chiffrées plusieurs fois, et que les clés doivent toujours être en mémoire. Il est par contre pertinent de l’utiliser pour le swap compte tenu que ZFS a encore un bug ouvert concernant le swap dans ZFS : https://github.com/zfsonlinux/zfs/issues/7734
643 ### BtrFS au lieu de ZFS
646 - Processeur : Intel i3 | i5 | i7
647 - i7 : https://teklager.se/en/products/routers/tlsense-i7-4lan
649 - Réseau : 4x Gigabit Ethernet
654 - Infos : https://kobol.io/helios4/
656 Open hardware mais ARM pas x86, et plus en vente pour le moment.
658 ### HPE ProLiant MicroServer
659 - Processeur : AMD Opteron X3416 (2x 1.6–3.0GHz) | X3421 (4x 2.1–3.4GHz)
660 - Mémoire : 1x 8Go (max 2x 16Go) DDR4-SDRAM (X3416: 1600Mhz | X3421: 2400MHz) Unbuffered ECC (non-soudées)
661 - Cache L2 : X3416: 1Mo | X3421: 12Mo
662 - Réseau : 2x Gigabit Ethernet
663 - Électricité : 12-35W
664 - Stockage : 4x SATA 3.5"
665 - Extensions : 2x PCIe 3.0
667 - X3416 : 328€HT https://www.senetic.fr/product/873830-421
668 - X3421 : 415€HT https://www.senetic.fr/product/P04923-421
sourcephile / git / sourcephile-txt.git / blob