Ou alors j'ai mal compris , ou alors tu extrapoles largement, mais c'est pas du tout ce qui est dit.
Déjà de base le texte est de mauvaise foie (je pense que c'est assez évident). Il s'en trouvera toujours pour penser que j'ai 14 ans et que je parle de systemd pour passer ma période pré-ado (bonjour Misc _o/ ), mais dans le fond, même si je n'utiliserais pas systemd avant qu'il y ait eu de gros changements (c'est à dire probablement jamais, parti comme c'est) je n'ai pas de ressentiment particulier vis à vis du logiciel.
Pour être clair je considère que systemd est comme internet explorer 5.0, ca rend service à pleins de gens, en surface c'est facile à mettre en oeuvre et à utiliser et ça juste marche pour 90% à 95% des cas. Maintenant c'est aussi un nid à bugs et à trous de sécu, et les 5% de cas ou systemd ne marchera jamais font qu'il est bon à mettre à la poubelle d'après moi. En tout cas pour l'utilisation que j'ai de l'outil informatique au niveau professionnel, non seulement il ne me sert à rien, mais en plus il est fondamentalement incompatible avec mon métier. (Par exemple il est hors de questions que mes sondes actives ou que mes watchdogs choppent les droits root. Donc soit je ne monitore pas, soit je n'utilise pas systemd - le choix est très vite fait.)
Revenons en à la question qui nous interresse
On a cette phrase là (je prend la traduction pour aller vite)
Pour les configurations dans les nuages avec un nombre important de machines virtuelles ou de conteneurs, le cout d’un démarrage lent est multiplié par le nombre d’instances. Passer plusieurs minutes de temps CPU et d’entrées/sorties sur des démarrages très lents de milliers de machines virtuelles ou de conteneurs réduit la densité de votre système de façon importante, cela vous coute même plus d’énergie. Un démarrage lent peut vous couter beaucoup d’argent, alors qu’un démarrage rapide permet d’implémenter une logique d’activation de conteneurs par socket pour augmenter la densité de votre système dans les nuages.
En substance ce qui est expliqué ici (très lentement, parce que les admins à qui ont confie des datacenters contenant plusieurs milliers de conteneurs sont rarement très malins) c'est le principe de la loi d'Erlang du temps d'attente - à savoir que de façon générale (à adapter en fonction des situations bien sur) un système servant plusieurs clients n'a pas besoin de disposer d'assez de ressources pour servir tous les clients en simultané. Typiquement si vous avez 50 employés et que vous n'êtes pas un call-center, dix canaux téléphoniques c'est suffisant.
Pour les VMs c'est pareil, pour peu que l'on arrive à mettre à disposition une VM assez rapidement, pas besoin de faire tourner toutes les VMs (ou conteneur) tout le temps, il suffit de lancer la VM au moment ou elle est demandé. Donc moins de charge CPU, moins de courant électrique, un datacenter plus dense etc.
Sauf que ça ne marche pas tout à fait comme ça.
Il existe (grosso-modo) trois grand types de VMs/Conteneurs dans le cloud.
- Les VMs pour faire du calcul
- Les VMs pour faire du traitement de données
- Les VMs pour faire du stockage de données
Plus un type hybride des trois : les serveurs dédiés virtuels.
Les VMs pour faire du calcul démarrent généralement en un temps record. Il s'agit le plus souvent d'OS ultra-dépouillés dont le seul rôle est de répondre le plus vite possible à un serveur maitre, donc avec un temps de boot minuscule. C'est généralement mis en place sur des très très grosses machines avec des quantités de ram délirante (le petit octo-déca coeur avec 2TO de mémoire vive est assez populaire). Elles vont être louées par paquets de 200/300 tranches pour plusieurs jours, voire semaines. Généralement la personne qui gère ce type de machine est prévenu plusieurs semaines à l'avance. (Que ce soit l'industrie du cinéma ou celui de la recherche, entre le moment ou le contrat est signé et celui ou l'argent est arrivé et ou les comptes sont ouverts il s'écoule un moment.) De toute les façon que ce soit coté client ou coté exploitant tout le monde se fout royalement de la demi-seconde gagné par une VM à booter sur systemd.
Les VMs pour faire du traitement de données sont principalement orienté de façon à minimiser les I/Os. Généralement ce sont des machines avec une grosse quantité de mémoire (pour pouvoir stoquer les index) et des I/Os disque ultra optimisés. Le but étant bien sur de pouvoir processer un flux d'information assez conséquent à toute allure. Sur ce genre de VM, le temps de boot est très négligeable comparé au temps de rapatriement des données/mise en place du flux et au temps de calcul des index. Donc toujours pas d’intérêt majeur à utiliser systemd (et totu ca sans même parler du temps nécessaire pour faire le sharding des données ou le fencing des machines si l'application le nécessite)
Les VMs pour faire du stockage de données sont généralement en fait des partitions de serveurs de fichier. C'est à dire qu'un service central (Mongo, Hadoop, Riak etc. ) sert plusieurs dizaines voire centaines de client finaux. La question de le démarrer à la demande ne se pose pas vraiment. Et une fois de plus il s'agit de serveurs très simple avec des OS très spécifiques qui vont avoir tendance à avoir des temps de boot très rapide. Ce temps de boot sera systématiquement très inférieur au temps mis par les services pour faire le mapping des données et les rendre accessibles.
Reste les serveurs dédiés virtuels, c'est à dire les produits type EC2, VPS OVH par VMWare, machines Gandi et autre google Cloud. Là éventuellement les principes de l'Erlang peuvent s'appliquer. On est sur une grande diversité de clients, avec des demandes ponctuelles et irrégulières dans le temps. Systemd possède donc un avantage ici, même si il est minime (attribution des ressources + mise en place monitoring/facturation + montages des données + initialisation de la VM et des instances fallback éventuelles >> temps gagné avec systemd). Mais le temps gagné par systemd sera très difficile à exploiter en vrai, tout d'abord parceque le temps de mise en attente toléré est très inférieur au temps de boot, même avec systemd (un serveur qui met plusieurs secondes à répondre sous pretexte qu'il n'y a pas eu de demandes depuis une heure, ca la fout mal) et ensuite parce que le temps d'usage est lui très très supérieur au temps de boot.
Généralement on va avoir un temps de mise en attente toléré de l'ordre de quelques millisecondes (entre 10 et 100), un temps de boot de plusieurs secondes (entre une et 10) et un temps d'utilisation de plusieurs heures (de 12h typiquement pour un service pro principalement utilisé pendant les heures de bureau)
Chercher à grapiller quelque chose là dedans ca va être l'horreur.
Deuxième soucis, le système va gagner quelques secondes au boot - à condition que les ressources soit prêtes. Ca c'est bien entendu le boulot de l'hyperviseur d'avoir des ressources disponibles au cas ou une demande arriverait, mais si les ressources sont disponibles on est déjà en consommation électrique "iddle" sur ces ressources.
Par exemple si mon hyperviseur est configuré pour avoir 15% de ressources préallouées par rapport au volume consommé, il aura exactement la même densité et la même consommation que ce soit en mode systemd ou init classique. Et comme je n'ai pas le temps de faire toute l'allocation à la demande (pour des raisons de temps de réponse du hardware - ouvrir une LUN sur un SAN par exemple ca ne sera jamais instantané, idem pour le temps de création d'un sous réseau virtuel avec les VLANs qui vont bien) - et bien au final ma consommation électrique et ma densité salle blanche ne bougeront pas d'un iota.
Donc dans tous les cas possibles parmis les plus fréquents, du minicloud entre potes au EC2 Amazon systemd n'apporte rien au niveau densité, consommation électrique ou vitesse de mise à disposition. Les facteurs limitants se trouvent systématiquement hors de portée des problèmes qu'un init peut résoudre.
Après l'exemple débile que j'ai donné n'a pas d'autres but que celui d'être humoristique. On se place dans un univers ou presque tout fonctionne comme Lennart Poettering le décrit (c'est à dire que tout ce que "controle" systemd, du temps de boot, au réseau, à la nécessité d'aller le plus vite possible au point que trois secondes sont salvatrices) et on regarde ce qu'il se passe juste après, et paf le SAN.
Bien sur que dans la vraie vie ca va bloquer à pleins d'endroits - le systèmes ne débloquera pas les 250 comptes simultanément, les 250 sous réseaux virtuels ne seront pas créés dans la même milliseconde, l'hyperviseur ne traitera pas toutes les demandes assez vite (si tant est qu'il en ait l'intention au début) etc.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Ou alors j'ai mal compris , ou alors tu extrapoles largement, mais c'est pas du tout ce qui est dit.
Déjà de base le texte est de mauvaise foie (je pense que c'est assez évident). Il s'en trouvera toujours pour penser que j'ai 14 ans et que je parle de systemd pour passer ma période pré-ado (bonjour Misc _o/ ), mais dans le fond, même si je n'utiliserais pas systemd avant qu'il y ait eu de gros changements (c'est à dire probablement jamais, parti comme c'est) je n'ai pas de ressentiment particulier vis à vis du logiciel.
Pour être clair je considère que systemd est comme internet explorer 5.0, ca rend service à pleins de gens, en surface c'est facile à mettre en oeuvre et à utiliser et ça juste marche pour 90% à 95% des cas. Maintenant c'est aussi un nid à bugs et à trous de sécu, et les 5% de cas ou systemd ne marchera jamais font qu'il est bon à mettre à la poubelle d'après moi. En tout cas pour l'utilisation que j'ai de l'outil informatique au niveau professionnel, non seulement il ne me sert à rien, mais en plus il est fondamentalement incompatible avec mon métier. (Par exemple il est hors de questions que mes sondes actives ou que mes watchdogs choppent les droits root. Donc soit je ne monitore pas, soit je n'utilise pas systemd - le choix est très vite fait.)
Revenons en à la question qui nous interresse
On a cette phrase là (je prend la traduction pour aller vite)
En substance ce qui est expliqué ici (très lentement, parce que les admins à qui ont confie des datacenters contenant plusieurs milliers de conteneurs sont rarement très malins) c'est le principe de la loi d'Erlang du temps d'attente - à savoir que de façon générale (à adapter en fonction des situations bien sur) un système servant plusieurs clients n'a pas besoin de disposer d'assez de ressources pour servir tous les clients en simultané. Typiquement si vous avez 50 employés et que vous n'êtes pas un call-center, dix canaux téléphoniques c'est suffisant.
Pour les VMs c'est pareil, pour peu que l'on arrive à mettre à disposition une VM assez rapidement, pas besoin de faire tourner toutes les VMs (ou conteneur) tout le temps, il suffit de lancer la VM au moment ou elle est demandé. Donc moins de charge CPU, moins de courant électrique, un datacenter plus dense etc.
Sauf que ça ne marche pas tout à fait comme ça.
Il existe (grosso-modo) trois grand types de VMs/Conteneurs dans le cloud.
- Les VMs pour faire du calcul
- Les VMs pour faire du traitement de données
- Les VMs pour faire du stockage de données
Plus un type hybride des trois : les serveurs dédiés virtuels.
Les VMs pour faire du calcul démarrent généralement en un temps record. Il s'agit le plus souvent d'OS ultra-dépouillés dont le seul rôle est de répondre le plus vite possible à un serveur maitre, donc avec un temps de boot minuscule. C'est généralement mis en place sur des très très grosses machines avec des quantités de ram délirante (le petit octo-déca coeur avec 2TO de mémoire vive est assez populaire). Elles vont être louées par paquets de 200/300 tranches pour plusieurs jours, voire semaines. Généralement la personne qui gère ce type de machine est prévenu plusieurs semaines à l'avance. (Que ce soit l'industrie du cinéma ou celui de la recherche, entre le moment ou le contrat est signé et celui ou l'argent est arrivé et ou les comptes sont ouverts il s'écoule un moment.) De toute les façon que ce soit coté client ou coté exploitant tout le monde se fout royalement de la demi-seconde gagné par une VM à booter sur systemd.
Les VMs pour faire du traitement de données sont principalement orienté de façon à minimiser les I/Os. Généralement ce sont des machines avec une grosse quantité de mémoire (pour pouvoir stoquer les index) et des I/Os disque ultra optimisés. Le but étant bien sur de pouvoir processer un flux d'information assez conséquent à toute allure. Sur ce genre de VM, le temps de boot est très négligeable comparé au temps de rapatriement des données/mise en place du flux et au temps de calcul des index. Donc toujours pas d’intérêt majeur à utiliser systemd (et totu ca sans même parler du temps nécessaire pour faire le sharding des données ou le fencing des machines si l'application le nécessite)
Les VMs pour faire du stockage de données sont généralement en fait des partitions de serveurs de fichier. C'est à dire qu'un service central (Mongo, Hadoop, Riak etc. ) sert plusieurs dizaines voire centaines de client finaux. La question de le démarrer à la demande ne se pose pas vraiment. Et une fois de plus il s'agit de serveurs très simple avec des OS très spécifiques qui vont avoir tendance à avoir des temps de boot très rapide. Ce temps de boot sera systématiquement très inférieur au temps mis par les services pour faire le mapping des données et les rendre accessibles.
Reste les serveurs dédiés virtuels, c'est à dire les produits type EC2, VPS OVH par VMWare, machines Gandi et autre google Cloud. Là éventuellement les principes de l'Erlang peuvent s'appliquer. On est sur une grande diversité de clients, avec des demandes ponctuelles et irrégulières dans le temps. Systemd possède donc un avantage ici, même si il est minime (attribution des ressources + mise en place monitoring/facturation + montages des données + initialisation de la VM et des instances fallback éventuelles >> temps gagné avec systemd). Mais le temps gagné par systemd sera très difficile à exploiter en vrai, tout d'abord parceque le temps de mise en attente toléré est très inférieur au temps de boot, même avec systemd (un serveur qui met plusieurs secondes à répondre sous pretexte qu'il n'y a pas eu de demandes depuis une heure, ca la fout mal) et ensuite parce que le temps d'usage est lui très très supérieur au temps de boot.
Généralement on va avoir un temps de mise en attente toléré de l'ordre de quelques millisecondes (entre 10 et 100), un temps de boot de plusieurs secondes (entre une et 10) et un temps d'utilisation de plusieurs heures (de 12h typiquement pour un service pro principalement utilisé pendant les heures de bureau)
Chercher à grapiller quelque chose là dedans ca va être l'horreur.
Deuxième soucis, le système va gagner quelques secondes au boot - à condition que les ressources soit prêtes. Ca c'est bien entendu le boulot de l'hyperviseur d'avoir des ressources disponibles au cas ou une demande arriverait, mais si les ressources sont disponibles on est déjà en consommation électrique "iddle" sur ces ressources.
Par exemple si mon hyperviseur est configuré pour avoir 15% de ressources préallouées par rapport au volume consommé, il aura exactement la même densité et la même consommation que ce soit en mode systemd ou init classique. Et comme je n'ai pas le temps de faire toute l'allocation à la demande (pour des raisons de temps de réponse du hardware - ouvrir une LUN sur un SAN par exemple ca ne sera jamais instantané, idem pour le temps de création d'un sous réseau virtuel avec les VLANs qui vont bien) - et bien au final ma consommation électrique et ma densité salle blanche ne bougeront pas d'un iota.
Donc dans tous les cas possibles parmis les plus fréquents, du minicloud entre potes au EC2 Amazon systemd n'apporte rien au niveau densité, consommation électrique ou vitesse de mise à disposition. Les facteurs limitants se trouvent systématiquement hors de portée des problèmes qu'un init peut résoudre.
Après l'exemple débile que j'ai donné n'a pas d'autres but que celui d'être humoristique. On se place dans un univers ou presque tout fonctionne comme Lennart Poettering le décrit (c'est à dire que tout ce que "controle" systemd, du temps de boot, au réseau, à la nécessité d'aller le plus vite possible au point que trois secondes sont salvatrices) et on regarde ce qu'il se passe juste après, et paf le SAN.
Bien sur que dans la vraie vie ca va bloquer à pleins d'endroits - le systèmes ne débloquera pas les 250 comptes simultanément, les 250 sous réseaux virtuels ne seront pas créés dans la même milliseconde, l'hyperviseur ne traitera pas toutes les demandes assez vite (si tant est qu'il en ait l'intention au début) etc.