Serveur web : un application compléte (http,base, php etc) par serveur ou factorisation des éléments?

#1

bonjour,

  1. 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) ?

  2. En gros on mutualise (factorise) au maximum ou au contraire on isole chaque appli avec tous ses composants sur le même serveur ?

  3. 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.) ?

1 Like
#2

Tu connais ma réponse :slight_smile:

Avec kubernetes, tu fais un gros cluster :slight_smile: 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.

1 Like
#3

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

1 Like
#4

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.

#5

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.

2 Likes
#6

pour le point des écoles , asso. : une infra même totalement conteneurisé ou virtuelle reste … une infra. et quelque soit sa taille.

pour le point 3 de ta réponse , certes mais même si il n’est pas conseillé de reproduire ce genre d’infra. s’en inspirer me semble important.

pour le point 4 , tout à fait d’accord.

#7

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.:joy::grin:

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 …)

#8

Ne pas oubliez que libre.sh v1 ( compose ) continue

Pendant que la V2 ( k8s) décole.

1 Like
#9

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 :wink:
Bon courage :slight_smile:

1 Like
#10

pfffff, à chaque fois que tu me balances un truc je met 1 semaines pour digérer … et parfois comprendre !
(tu vas trop loin mec ! :rofl::rofl:)
lol.
Laisses moi analyser tout ca. La, à chaud … comment dire, euh …
je saisis pas tout.:crazy_face::crazy_face::crazy_face::crazy_face::crazy_face:

  • 3VM ? sur un autre hardware ?
#11

Elles sont fun les discussions chez indiehost hein :stuck_out_tongue:

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 :slight_smile:

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 :exploding_head: :crazy_face:

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).

1 Like
#12

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 :wink:

(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 :wink: )

On mettra ton schéma sur le site https://libre.sh

#13

on s’ennerve pas c’est une grosse jokkeee ! (je me lâche un peu !)
Docker on m’a dit que ça ressemblait à çà … (j’ai trouvé l’image délire !)

Pierre : j’attaque un schéma d’archi/infra et je vous soumet ca.

1 Like
#14

pas de problème je vous fait le schéma.
Tu me dis quand tu as un créneau, horaire.

1 Like
#15

Kubernetes, cest #selfhealing :rofl: