Sysadmins, aidez-nous à trouver les bons serveurs !

Je sais qu'on a plein de sysadmins dans le coin et là, j'ai un boulot en plein dans vos compétences (pour une fois que je vous demande pas du SSO  ).

Notre parc de serveur n'est sans doute pas bien pensé. Je liste ce qu'on a actuellement, et nos besoins. Si vous voyez comment améliorer tout ça, répondez ici !

Nous avons eu un développement au jour le jour, et nous avons pris les trucs en fonction de nos besoins du moment.

- Une VPS chez OVH, pour héberger le site web : 1vcore, 1Go de ram, 10Go de disque dur (non ssd), à 1,99€ HT/mois
- Une seconde VPS, identique (1vcore, 1Go de ram, 10Go de disque dur (non ssd)) , qui sert à tester les outils pour le site web et les mises à jour avant de tout casser (le site web étant notre lieu de travail, il est important qu'il reste toujours disponible et accessible).
- Un serveur de jeu, lirria, chez Behost lvm04 : 3 vCore, 4 Go de ram, 50 Go d'espace disque SSD, 3,99€ HT/mois
- Un second serveur de jeu pour les devs qui ont prévu de tout casser, spofu, chez Behost aussi, lvm03 : 3 vCore, 3 Go de ram, 40 Go d'espace disque non SSD, 2,99€ HT/mois
- Un serveur kimsufi qui héberge le dépôt, les données volumineuses, ainsi qu'un exemplaire des backup des autres serveurs (enfin, vpsweb et lirria) : Atom™ N2800 (2core, 4threads, 1.86 GHz+), 4 Go de ram,    1 To de disque dur (non ssd), 9,99 € HT/mois

Cela nous fait, en tout, 20.95€ HT/mois.

Je suis contente que les serveurs de jeu soient séparés du site web, ce n'est pas géré par les mêmes personnes et ça permet que ça casse d'un côté ou de l'autre sans tout casser à la fois. Les serveurs de jeux gagneraient peut-etre à avoir plus de ram, mais actuellement, vu la population et l'activité, c'est plus que tranquille pour faire nos tests donc pas besoin de redimensionner.

Par contre côté web on héberge nos services et donc... ça prend de la ressource, la vps est trop petite. J'aimerais bien avoir plus de puissance...

Le serveur kimsufi est intéressant pour la place qu'il offre. Dremor va faire un test pour voir s'il peut héberger Gitlab (qui est gourmand).

Nous avons pris une décision au niveau physique : garder le kimsufi en serveur de sauvegarde, et mettre en place un serveur, récupéré par Shepeng, et hebergé par tetaneutral. Cela nous couterait 20€ par an+le prix de la conso électrique, évalué à 20€/mois, mais à ce prix on aura la machine qu'on veut, en gros.

Le reste de la réflexion porte sur l'architecture à mettre en place sur ce serveur. VM, Docker, autres...

La question porte sur le délicat équilibrage entre sécurité, simplicité de maintenance et performances.

Question performances : moins on consomme de ressource sur l'architecture elle-même, plus on en a pour les services hébergés, dont etherpad, gitlab et le shard qui pompent énormément (surtout sur la RAM). Après, si on a notre propre machine, on peut aussi investir pour la booster ; et la ram, c'est pas très cher.

Question simplicité de maintenance : Nous sommes un projet libre, fondé sur la bonne volonté de bénévoles. Cela veut dire qu'un sysadmin expert peut partir du jour au lendemain. Il faut alors que ceux qui restent, même s'ils n'ont aucune connaissances, puissent reprendre le flambeau et permettre au projet de perdurer. Donc, les solutions doivent être simples à maintenir, bien documentées, fondées sur des technologies qui sont faciles à apprendre. Autant que possible, hein, car certains de nos choix amènent de la complexité (comme cette fichue authentification unique). Il faut surtout impérativement documenter au fur et à mesure, afin de permettre à un repreneur de refaire les mêmes pas, même s'il ne comprends pas tout.

Question sécurité : C'est le point le plus complexe pour moi. Il faut savoir où sont nos failles, quels sont les risques, et trouver des solutions adaptées. Par exemple, pour rejoindre le point précédent, une installation trop complexe à maintenir va faire que les utilisateurs ne mettront pas forcément les logiciels à jour, permettant l'exploitation de failles basiques. En même temps, un système trop peu réfléchi ouvre la porte à d'autres attaques (et non, le mot de passe de l'utilisateur "admin" n'est pas "pass". Il ne devrait même pas y avoir d'utilisateur admin ). L'une des questions de sécurité primaire, c'est le fait que beaucoup de gens ont accès aux systèmes. Depuis la création de Khaganat, les accès d'administration à une VM ou une autre ont été donnés à une douzaine de personnes. Cela fait 12 failles potentielles... Que ce soit par volonté malveillante, ou plus simplement par des erreurs basiques et exploitables. Le premier point faible est toujours l'humain... Bon, rassurez-vous, on a régulièrement changé les mots de passe aussi. Mais même comme ça... J'ai personnellement cassé des trucs, rendu certains morceaux inutilisables pendant plusieurs jours, à cause d'une bidouille mal comprise ; il est possible aussi que le serveur web ait été compromis à un moment. Ce n'est pas très grave dans le sens où on a des sauvegardes et où on n'héberge pas de données sensibles (genre les numéros de cartes bleues) ; c'est d'autant moins grave que les services sont compartimentés ; que ceux qui ont accès à la VPS de test web n'ont pas forcément l'accès à la VPS de web en prod, ou au serveur de jeu.

Ces problématiques sont à garder en tête lors du choix de l'architecture. Si un admin du serveur de jeu veut tout casser, comment éviter qu'il casse aussi le serveur web ? et vice-versa ? Et d'autant plus si le souci vient du fait qu'un noob dans mon genre est aux commandes et copie-colle un truc sans trop savoir ce qui va se passer ?

Nous avons refait le point avec Shepeng.

Côté architecture, nous allons partitionner l'espace disque avec LVM, puis faire des VM avec Xen. Docker ne nous semble pas forcément pertinent dans notre utilisation ; les VM de ce genre permettent une certaine résilience (chaque VM se gère comme un serveur à part ou presque, il y a de la doc pour ça, et puis ça empêche pas d'utiliser docker à l'intérieur) allié à de la sécurité (certains auront accès à la VM1, d'autres à la VM2 ; ainsi on peut confier les clés, pleins pouvoirs roots sur une VM, à un néophyte ou une personne qu'on connait encore peu, sans mettre en péril l'ensemble de l'architecture). Je ne crois pas que Docker permette de gérer les permissions aussi finement et le but reste de déléguer les pouvoirs chaque fois que possible.

Côté machine physique, les serveurs que Shepeng avait trouvé ont des soucis. Comme les offres kimsufi sont peu coûteuses, on va peut-etre aller au plus simple... sauf si vous avez un super serveur à nous proposer ! Actuellement, il y a deux offres intéressantes, à voir ce qu'on choisit ; le prix est ok :
Modèle    CPU                  Ind *    Cores /Threads  Freq.    RAM    Disq.    Réseau    IPv6    Prix /mois    
KS-5    Xeon 2 x E5504    4997    8c / 8t    2 GHz+    16 Go ECC    2 To    100 Mbps    /128    24,99 € HT   
KS-4A    Core™ i7-920    5003    4c / 8t    2.66 GHz+    16 Go    2 To    100 Mbps    /128    21,99 € HT

Le fréquençage du KS-4A est plus élevé, le KS-5 a 8 coeurs au lieu de 4... entre les deux mon cœur balance, sachant que ça va surtout être utile lors de la compilation, je laisserais les pros décider de ce qu'ils préfèrent À 3€ près, ce n'est pas le prix qui va décider.

Pas de SSD donc on ne gagnera pas en perfomance de ce côté, m'enfin pas grave... et la RAM est suffisante pour nos besoins. L'ECC est un plus, mais qui ne me semble pas essentiel non plus à ce stade du projet.

Les kimsufi ne sont pas des serveurs "fiables", dans le sens où, s'ils ne sont pas chers, c'est pas pour rien : support très limité, machines ayant déjà vécu et déclassées. Il est donc possible d'avoir des soucis, comme sur le premier que nous avions pris (avec des clusters corrompus si je me souviens bien) ; mais ce n'est pas mieux sur des serveurs d'occases comme ceux de Shepeng, où on devra assurer le support nous-même (mais où on aura un accès à la machine, moyennant quelques heures de route). Le jour où Khaganat ramènera des foules, on payera un serveur pro

Nous prendrons ce serveur en août, probablement ; j'ai pas mal de travail actuellement et je ne lancerais ce chantier que quand j'aurais du temps à y consacrer, idem pour Shepeng (qui lui, sera moins dispo en septembre).

Je souhaite aussi prendre le temps de bien préparer le projet en amont. Réfléchir soigneusement aux choix à faire, et documenter au fur et à mesure.

Architecture

Nous aurons donc 2 serveurs physiques : celui de sauvegarde (actuellement serveur de dépôt), qu'on rebaptisera nuxru à cette occasion ("retour à la sécurité" en lojban), et le serveur général, qu'on appellera groska eu égard à sa taille et sa polyvalence. C'est de Groska qu'on va parler, l'autre on s'en moque un peu...

Sur Groska, comment on va séparer les choses, quelle taille sur le DD, quelle quantité de RAM on va allouer à chaque morceau ?


Un lot de VM perpétuelles (qu'on n'éteins pas) :
- Une première VM contiendra le reverse proxy, peut-être aussi LDAP ? pour dispatcher ensuite vers les diverses VM. Je pense qu'on pourrait aussi mettre dessus le Zabbix principal, pour monitorer. Cette VM s'occuperait finalement des fonctions d'aiguillage, donc je propose qu'elle s'appelle kuckla (carrefour). Je ne sais pas de combien Zabbix a besoin... Au pif, je lui donnerait 1Go de ram, 10Go d'espace disque
- liria, pour le serveur de jeu tant qu'on est dans la période des Brumes et du tâtonnement. 4Go de ram, 50Go d'espace physique.
- jukni ("machin à huit pattes", qui loge sur une toile ) pour les services web de base : dokuwiki, forum, pastebin, log irc, galerie d'images, et j'ajouterais bien owncloud dessus, dont on a un usage limité. 1Go de RAM, 100Go d'espace physique (si owncloud).
- etherpad : oui, on va lui mettre une VM à lui tout seul, mais vu comme ce service peut pomper, ça devrait améliorer les choses. Et éviter qu'il fasse tout planter. 1Go de RAM rien que pour lui !  10Go d'espace disque (c'est large mais c'est un luxe qu'on peut se permettre).
- depots, qui hébergera le gitlab, et va donc aussi servir à compiler. 4Go de RAM minimum, et pas mal d'espace disque (1To ?).


Cela fait 10Go de RAM, 170Go d'espace disque (plus depots).

Il y a ensuite des VM temporaires, qu'on allumera suivant les besoins :
- spofu, le serveur de jeu pour les crash test, clone de liria : 4Go de ram, 50Go d'espace physique. À noter qu'on pourra faire un snapshot avant de mettre des tests, et donc revenir rapidement à un état antérieur.
- rirni, clone de jukni, qui servira lorsqu'on voudra tester des trucs web :  1Go de RAM, 30Go d'espace physique.

Si tout est allumé, ça fera 15Go de ram utilisé, plus 1Go pour le système hôte. Je pense que spofu sera souvent en route par moment Il restera de l'espace disque en rab, qu'on allouera suivant les besoins.

Si les VM temporaires sont éteintes, il est peut-être possible via xen d'allouer temporairement plus de RAM à certaines VM, type dépots, qui peut consommer pas mal en cas de compilation.

ok , de toute manière faudra tester  mais sa devrait le faire voir déléguer un service a l'autre server   

Spofu , pour l'instant il y aura peu de besoin , il y a git pour tester les modif code et la je peux modifier en local

Je commence à regarder la différence en Xéon et i7.

Déjà, il semblerait que pour le premier, ce soit un "bi-xéon", autrement dit, 2 processeurs. Les comparatifs comparent avec un seul processeur :
http://www.cpu-world.com/Compare/71/Intel_Core_i7_i7-920_vs_Intel_Xeon_E5504.html
http://cpuboss.com/cpus/Intel-Xeon-E5504-vs-Intel-Core-i7-920

Sur un seul processeur, l'i7 me parait mieux, de peu (ils sont très similaires quand même). Mais face à 2 xéon ?

En lisant des discussions tel que celle-ci, il semblerait que deux xéon soient utiles pour une grosse puissance de calcul. Lors des compilations, je pense que ce sera exploitée.

Nous n'avons pas vraiment de programmes qui savent utiliser plusieurs cœurs tel quel ; je serais surprise que le serveur de jeu sache le faire, et de toute façon ses demandes ne sont pas énormes de ce côté. Par contre, avec le système d'hyperviseur, nous allons pouvoir dédier des coeurs pour chaque VM (si j'ai bien compris), donc finalement, plus il y en a, plus ce sera facile à gérer.

Pour notre usage, il me semble donc qu'on pourra tirer parti de l'architecture des xéons. Leur utilité se fera vraiment sentir lors des compilations, pour le reste ça sera sans doute moins visible.

Pour ma part, je serait tenté par le bi-xeon. Même s'il ne sont pas aussi puissants que l'i7-920 (pourtant vieux de presque 8 ans), il a plus de threads, ce qui veut dire que plus de process pourront être actif en même temps. Vu que l'on veut tout rassembler nos service sur ce serveur, ce serait très intéressant.

De plus, j'en profite pour suggérer de faire passer une partie de nos services sur des containers Docker, pour augmenter sécurité et souplesse, tout en profitant d'un environnement serveur reproductible à souhait. (placement de produit  )

Ouf, ta réflexion rejoint la mienne, j'ai pris un bi-xéon !

Quand à Docker, je vais vers une solution "mixte" pour avancer. Dans un premier temps, parce que je maîtrise mieux le principe, j'ai installé avec l'aide de Shepeng un système avec l'hyperviseur Xen et donc des VM (à noter que Xen met en place des "VM" un peu particulières, ce n'est pas virtualbox).  Comme ça, on aura rapidement un système fonctionnel sur un serveur plus puissant (enfin, rapidement, tout dépend du temps que je peux y consacrer ; mais je n'ai pas grand chose à apprendre donc ça fait du temps gagné). J'ai découpé l'espace en laissant du disque dur de libre ;  donc, dans un second temps, si tu es disponible et motivé, je verrais avec toi comment marche Docker, sur quelles parties il est pertinent, comment ça marche niveau sécurité. Certains sysadmin m'ont déjà traité de parano côté sécu... c'est un sujet qui me tiens à coeur et sur lequel, justement, je trouve qu'on est encore trop léger parce que je ne maitrise pas assez les subtilités. J'adore me former sur le sujet, heureusement (contrairement aux langages de programmation qui me lassent vite...).