le but est de savoir si pour un chatons il est plus judicieux de n’avoir qu’un seul GROS serveur (cluster même) de base de données (par exemple) ou bien avoir chaque application qui embarque sa propre base de donnée (etc) ?
En gros on mutualise (factorise) au maximum ou au contraire on isole chaque appli avec tous ses composants sur le même serveur ?
Dans le cas d’un mutualisation n’est on pas coincer pour les montées de version qui impacte donc forcément une multitude d’application ? (auquel cas la mutualisation serait une source de problème pour une grosse prod.) ?
Avec kubernetes, tu fais un gros cluster grâce aux containers, chaque appli peut avoir une version de php différente.
Pour linstant, on a une instance de bdd par app, mais on va aller dans un entre 2, avec une bdd par nom de domaine.
Le résultat est aussi plus ecolo, on doit être autour de 60% d’utilisation des resources (cpu ou memoire) chiffre à prendre avec des pincett, cest de mémoire.
A mon avis il n’y a pas de réponse unique, ça dépend de pas mal de facteurs:
Objectif de fréquentation des services
Public visés
Compétences de l’équipe
Fréquence de turn over et stratégie de montée en compétences des nouvelles personnes venues
Type de structure (particulier, asso, entreprise)
Moyen financiers pour démarrer
Niveau de sécurité nécessaire
Le problème c’est que pour un groupe de bénévoles motivés mais sans beaucoup de compétences techniques faire ces choix c’est pas simple car les personnes n’ont pas tout ça en tête.
Je me rend compte d’ailleurs que la page wiki à propos de monter son CHATONS avec YunoHost est vraiment pas à jour… https://wiki.chatons.org/doku.php/yunohost
Je met un bandeau pour le signaler
on parle pour un chatons, donc un hébergeur.
je n’ai pas vu un seul chatons héberger plus de 100.000 utilisateurs (si on veut voir grand) , et ça dépends des types d’utilisateur en plus.
Pour moi quelques soit nos tailles il y a une logique d’architecture orientée hébergeur.
De plus il n’y a pas 50 architectures sécurisées possibles … il suffit de regarder les white papers de AWS, google etc …
Donc si on pouvait proposer un schéma réseau , orienté hébergeur, de base pour les arrivants se serait bien.
l’excuses des moyens n’est pas valable avec la virtualisation on peut monter une archi. proche d’un ovh , ( bien sure les sites en moins etc) … demander au chatons 42l : j’ai vu leur schéma docker, donc archi. réseau : ils ont monter un infra complète dans docker , et elle est vachement bien foutu.
donc à nous d’avoir une grosse partie de la problématique hébergeur niveau architecture, et la coucher sur le papier.
sur la section du forum j’ai déjà posé la mienne, elle n’est pas au top, c’est pour ça que je suis en train de la revoir avec l’ajout d’un cluster bcp plus performant.
J’estime pour ma part qu’entre un objectif de 100, 1000 et 10000 ce n’est pas la même chose. Et je crois bien que Framasoft héberge plus que 100 000 usagers. Zaclys en est quand même à 25 000 et plutôt sur du mail/cloud…
42l ou picasoft ne sont pas représentatif, car ils sont dans un contexte très spécifique (asso proche d’école d’informatique). Et même là je pense que le défi de la passation n’est pas gagné, puisque ce sont des assos avec un turn over important.
Je suis sceptique sur l’idée qu’il faut copier l’esprit des infras de google ou AWS. A mon sens on ferait mieux de répertorier nos différentes façons de faire au sein du collectif, et d’en critiquer les avantages et inconvénients, ça aiderait probablement plus les nouveaux CHATONS.
Par contre je te rejoins sur l’idée que si on pouvait proposer une recette pour monter une base d’infrastructure, qui soit adaptée à l’équipe et au projet qui se présente, ce serait vraiment bien.
rassures moi : un cluster haute dispo kubernetes avec 3 serveurs physique (allez …5) , c’est juste pas possible ?
je lis du kubernetes depuis une semaine …
et je pense que bien qu’alléchant (des avantages y’en a un paquet, gros paquet !) , mais … il faut à mini 5 serveurs bien costauds ( 2 master, 3 noeuds) et , je ne compte pas le cluster ceph pour le stockage (minimum 3 serveurs …)
c’est ce que je compte : donc au moins 8 serveurs bien costauds.
je vous aurais bien suivi (libre.sh : super projet) me je vais me contenter de Proxmox , ceph et faire du docker gentillement.
j’ai lu la doc libre.sh, mon avis : kubernetes c’est bien, mais faut beaucoup de matériel pour que ça tourne.
Et pour moi la plus grosse faille dans les conteneurs : le kernel. (et ca vaut aussi pour promox hein)
on est obligé de se fader le même kernel pour tout, c’est très très contraignant.
je n’avais pas testé centos 8 dans un conteneur proxmox, je comprends maintenant pourquoi proxmox se base sur debian et surtout il est préférable de prendre des conteneurs identiques à l’hôte … (firewalld, fuse, sshfs etc …)
Alors, avec 3 HW plus 3 VM, oui.
Er limite, les VMs peuvent être sur le HW aussi pour commencer.
Deja, les master avec etcd, ne consomment pas tant que ça au départ. Leur consommation dépend de la charge, et surtout des opération, si tu déploie 100 fois par jour, cest pas pareil que si tu déploie 1 fois. Et gérer 1000 pods, cest pas pareil que gérer 100 pods.
Pour ceph c’est un peu pareil, tu peux faire tourner tes workers kubernetes avec tes OSDs. C’est ça quon a fait, et seulement 2 ans après, on commence à atteindre les limites pour vouloir les séparer.
Donc à la.limit, 3HW avec 1 VM management dans chaque, ça passe.
Dans la VM management, tu mets le master k8s, etcd, et les mon ceph. 1cpu et 4GB de ram devraient suffire pour commencer. Mais il va falloir se tenir prêt à rajouter 3 HW.
Une chose importante est d’avoir les mon un peu séparés. Donc quand tu rajoute du hw, tu sépares les mon d’abord.
Ensuite, tu peux pinner les osd pour leur garantir un core chacun. Mets du nvme pour le cache aussi ou au moins du ssd.
Si tu as des gros disk, 10GB de net pour le backbone ceph pour un recover
Bon courage
pfffff, à chaque fois que tu me balances un truc je met 1 semaines pour digérer … et parfois comprendre !
(tu vas trop loin mec ! )
lol.
Laisses moi analyser tout ca. La, à chaud … comment dire, euh …
je saisis pas tout.
Elles sont fun les discussions chez indiehost hein
Alors en gros un cluster idéal ca serait:
3 machines dédiées pour ceph avec network 10GBs et mix 1 HDD / 1 NVME
3 VMs pour les masters de kubernetes
3 VMs pour les ingress (avec floating IP et keepalived)
3 VMs pour les mons/mgr ceph
Des VMs ou machines dédiées pour tes workers kubernetes
Ca c’est l’idéal
Nous on a eu 2 ans en prod un cluster avec:
1 VM master
3 VMs ingress & mon ceph (on aurait aussi pu les mettre sur les 3 machines kube/ceph)
3 machines dédiées ceph et kubernetes
Et ce que disait @pierre c’est que les VMs peuvent être sur les machines dédiées. Tu pourrais même déployer un kubernetes pour déployer des VMS sur lesquels tu déploies kubernetes et… ceph dans kubernetes tant qu’à faire
Le plus sensible et le plus gourmand ca sera ceph, il te faut un réseau qui dépote, pour chaque OSD tu veux un disque NVMe/SSD pour bluestore et t’auras aussi besoin de pools de disques NVMe/SSD pour le s3.
Il est fortement conseillé de déployer les mons et osds sur des machines différentes.
Par contre
ca ne marche pas. Il te faut un nombre impair de master pour qu’il y ait consensus (pour etcd et pareil pour les mons ceph).
Là ce que l’on est en train de mettre en place, c’est un clusters de machines dédiées ceph que l’on va utiliser que pour l’object store s3, pas de block storage.
Jusque là on déployait une base de données par application avec des volumes ceph rbd. Là on part sur une base de données par domaine avec les volumes montés directement sur les disques NVMe (on aurait donc une réplication minimum de 2 pour chaque base de données).
Si tu fais le schémas de notre infra, on passe une heure au tel ou on réponds à toute tes questions, plus tu viens sur notre chat et on discute quand tu veux
(C’est pas que je veux pas le faire le schémas, mais j’ai jamais fait, pas les outils, et c’est dans ma tete, donc… Mais je comprends la partie Transparence, pas de soucis )
