PROJET AUTOBLOG


Zythom

Site original : Zythom
⇐ retour index

25 ans dans une startup - billet n.35

jeudi 11 octobre 2018 à 05:00
Introduction - billet n.34

La climatisation avait été oubliée. Elle était restée branchée sur le courant normal.

"C'est qu'on ne met pas aussi facilement une clim sur un onduleur", me dit l'installateur. C'est bien la peine d'avoir une salle serveurs qui tourne à plein régime, si c'est pour cramer les composants des machines en montant à 60°...

Après moultes devis tout aussi élevés les uns que les autres, j'ai fini par choisir de mettre deux climatisations : l'une directement branchée sur le groupe électrogène, et capable de redémarrer toute seule en cas de coupure (il faut 3s pour que le groupe électrogène atteigne sa puissance électrique nominale), et l'autre sur le courant standard.

Chaque clim est capable de maintenir la salle serveurs à une température acceptable. Et pour éviter qu'elles ne fonctionnent en même temps (pour économiser l'énergie et faire durer plus longtemps chaque clim), elles sont réglées sur une température qui diffère d'un degré. Et à chaque contrôle de maintenance des clims, on inverse la différence. Une seule clim fonctionne, et si elle s'arrête (panne mécanique par exemple), l'autre prendra le relais après une élévation de température d'un degré.

Si une panne générale électrique survient, les deux clims s'arrêtent, et celle branchée sur le groupe électrogène redémarrera.

Comme bien sur, en tant que responsable de tous les ennuis techniques et informatiques possibles et imaginables, je suis d'astreinte 24/7 toute l'année, j'ai mis en place un serveur Nagios (maintenant remplacé par un serveur Centreon), et je reçois un email associé à un SMS (envoyé gratuitement par Google via un script GMail) en cas d'alerte.

Une sonde Centreon surveille la température de la salle, et si elle monte trop haut (panne des deux clims par exemple) un processus d'arrêt en douceur des 70 serveurs virtuels, et des machines physiques hôtes, se déclenche. Je peux partir en vacances l'esprit tranquille.

Jusqu'au jour où je reçois un coup de téléphone affolé du gardien. Un truc imprévu nous tombait sur la tête. Et cette fois, c'est grave. Très grave.

Billet n.36

--------------

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Un truc imprévu (allégorie)
Cliquez pour agrandir l'image
Source : Golem

Source : https://zythom.blogspot.com/feeds/1538600911061127896/comments/default


25 ans dans une startup - billet n.34

mardi 9 octobre 2018 à 05:00
Introduction - billet n.33

On ne plaisante pas avec l'électricité. Toute la salle serveurs est alimentée en courant secouru, c'est-à-dire issu d'onduleurs. Le problème est que de temps en temps, en fait à chaque intervention de maintenance sur les onduleurs, tout saute, et on se retrouve sans aucun serveur, alors que le courant "normal" continue de fonctionner sur tous les postes de la startup.

Évidemment, c'est sur le service informatique que tout le mécontentement se déverse...

Je réfléchis donc à essayer d'améliorer la situation, et me plonge dans les différents types d'onduleurs, les capacités des batteries, les différents contrats de maintenance, etc. Puis, je me souviens qu'il y a une sorte de groupe électrogène vaguement utilisé dans un coin de la startup. Je mène ma petite enquête et je comprends que ce groupe sert uniquement en cas d'incendie : il alimente les moteurs des trappes d'évacuation des fumées. Comme il ne sert jamais, il a un peu été oublié dans son coin.

J'étudie la documentation, et les textes réglementaires. Rien ne s'oppose à ce que j'exploite un peu plus les capacités de cet énorme groupe électrogène. D'abord, je le fais réparer (il doit être chauffé en permanence par une résistance électrique pour le maintenir en température, et éviter une rupture en cas de démarrage et d'exploitation immédiate à pleine charge), puis je trouve une entreprise capable d'en assurer la maintenance. Ensuite, avec une entreprise électrique qualifiée, je fais mettre en place une dérivation pour alimenter tous les onduleurs de la startup. Enfin, je fais valider tout cela par la commission de sécurité qui passe tous les trois ans.

J'ai donc un groupe électrogène qui démarre en cas de coupure de courant, et met environ 3 secondes à fournir un courant de charge pour les onduleurs. Ceux-ci auront immédiatement pris le relais de la coupure, sans micro-coupure, et continueront de tenir leur rôle tant qu'il y aura du carburant dans le groupe électrogène. Au pire, si un jour la demande de courant est trop importante, la capacité des onduleurs de faire fonctionner la salle serveurs aura été passée d'un quart d'heure à plusieurs jours.

Bien sur, j'ai vérifié que les serveurs, les systèmes de stockage et les commutateurs avaient tous au moins deux alimentations, l'une sur le secouru et l'autre sur le courant standard.

A la première panne électrique de secteur, je suis allé voir si tout allait bien en salle serveurs. Tout fonctionnait parfaitement... sauf un détail. Un petit détail qui risquait de ruiner la salle serveurs.

Billet n.35

--------------

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.


Source : https://zythom.blogspot.com/feeds/6020356366126364411/comments/default


25 ans dans une startup - billet n.33

jeudi 4 octobre 2018 à 05:00
Introduction - billet n.32

Cette même année 2009, je commence à jouer avec un logiciel quasi magique pour moi : ESXi de VMware. Il s'agit d'un hyperviseur, c'est-à-dire d'une plate-forme de virtualisation qui permet à plusieurs systèmes d'exploitation de fonctionner sur une même machine physique en même temps. 

Lors d'un salon informatique, j'ai assisté à une démonstration VMware où le technico-commercial a montré la migration à chaud d'une machine virtuelle en fonctionnement, d'un serveur à un autre, tout en "pingant" la machine, sans perte d'un seul paquet. Cela me paraissait incroyable.

A cette époque, ESXi était devenu gratuit (c'est une version simplifiée de la version ESX commerciale, dépouillée de sa console graphique qui posait beaucoup de problèmes de sécurité). Pour tester le concept et ne pas mourir idiot, j'ai installé ESXi sur un vieux serveur. Je découvre alors, émerveillé, les concepts de machines virtuelles, de switchs virtuels, de cohabitation de plusieurs serveurs virtuels sur une seule machine physique.

C'est un choc !
(on ne se moque pas, c'est aujourd'hui banal, ça ne l'était pas pour moi en 2009)

Je monte un POC en salle serveurs, avec trois vieilles machines gonflées pour l'occasion (mémoires, disques durs, cartes réseaux), pour étudier la faisabilité de cette idée un peu folle de remplacer 15 serveurs physiques par des machines virtuelles regroupées sur 4 serveurs physiques.

Après quelques mois de tests en salle serveurs, je contacte les principaux constructeurs de matériels informatiques (à l'époque : NEC, HP, Dell et EMC), pour étudier une configuration de production adaptée à mes besoins. Je me fais prêter une config sur laquelle je mesure les I/O des disques et nous basculons tous nos serveurs vers un cluster de 4 hôtes Dell reliés à deux SAN md3000i remplis de disques durs. Je découvre vMotion, la réplique de machines virtuelles, le partage des ressources matérielles, la baisse de la consommation électrique de la salle serveurs.

De 15 serveurs physiques, nous passons à 4 sur lesquels nous installons 15 machines virtuelles, puis 20, puis 30, puis 50 et aujourd'hui 70... Tout est administré à travers une appliance vCenter. L'administration informatique prend chez nous une dimension industrielle. Nous sommes pourtant toujours 3 dans le service informatique... La pression des utilisateurs continue d'augmenter (leur nombre aussi).

Mais le géant nouvellement installé dans la salle serveurs garde un talon d’Achille : l'alimentation électrique.

Billet n.34
--------------

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Administration de machines virtuelles (allégorie)

Source : https://zythom.blogspot.com/feeds/3041830985533289073/comments/default


25 ans dans une startup - billet n.32

mardi 2 octobre 2018 à 05:00
Introduction - billet n.31

Quelques DSI d'écoles de commerces ou d'écoles d'ingénieurs (privées) commençaient à envisager l'externalisation de leurs outils de travail de groupe (on parlait beaucoup de "groupware" à l'époque), dont leurs messageries. Les offres étaient peu nombreuses, mais existaient et toutes avec des fonctionnalités et des coûts différents. Aucun n'avait encore fait le saut.

Je cherchais une solution qui puisse proposer un espace de stockage en phase avec les besoins toujours croissants des utilisateurs, et facile à installer sur tous les types d'appareils que les utilisateurs amenaient sur place : téléphones de toutes marques, de toutes versions de système d'exploitation, tablettes, ordinateurs portables, ordinateurs fixes, etc. Les modes d'emploi d'installation et de configuration devaient être toujours à jour, surtout lors de la sortie d'un nouveau type d'équipement. Les import/export des contacts devaient être simples et pratiques.

J'ai donc contacté les entreprises qui proposaient des offres en phase avec mon cahier des charges. A l'époque, deux sociétés sortaient du lot : Microsoft et son offre BPOS naissante bientôt renommée en Live@Edu (aujourd'hui Office 365), et Google avec son offre Google Apps for Education (aujourd'hui G Suite). Google est alors une société dynamique en pleine ascension, mais jeune (à peine 11 ans) et le choix est risqué. Microsoft est en train d'opérer son virage vers Internet et peine à convaincre malgré sa base installée.

Les deux offres sont gratuites pour les établissements d'enseignement supérieur, ce qui était très très intéressant, sans que cela n'éveille chez moi la méfiance que j'aurais du ressentir... Je mène une enquête  (sur le principe d'externalisation vers les outils Google ou Microsoft) auprès d'un panel d'utilisateurs internes et leur retour est enthousiaste, avec une nette préférence pour les outils Google.

En étudiant bien les fonctionnalités proposées, y compris les paramétrages possibles dans les outils d'administration, et avec la bonne réputation que Google avait à l'époque, j'ai choisi de migrer mes 2000 comptes de messagerie vers GMail et son quota de 5 Go par personne (énorme pour l'époque). Les utilisateurs sont ravis, la bande passante aussi. La lutte contre le SPAM est externalisée et répartie sur les utilisateurs du monde entier. Pour les utilisateurs concernés, le chiffrement des emails est assuré par GPG et Thunderbird.

C'est la décision dont je suis le moins fier aujourd'hui : la pression économique, le manque de clairvoyance, l'envie de satisfaire au mieux les besoins des utilisateurs, m'ont fait franchir le Rubicon.

Mais j'ai l'habitude d'essayer de prendre mes décisions de manière réfléchie, en analysant au mieux les cartes que j'ai en main au moment où je dois prendre la décision. Quand je regarde en arrière, et que je me rends compte que j'ai pris une mauvaise décision, je ne jette pas la pierre à mon moi d'avant. Nous sommes quatre ans avant le lancement d'alerte d'Edward Snowden. Depuis, de nouvelles cartes sont apparues, entraînant une vision différente. Il m'arrive comme tout le monde de prendre de mauvaises décisions, de le reconnaître et d'essayer de les corriger ensuite. Mais dans ce cas, une fois la décision prise et les gigaoctets transférés, ces derniers sont devenus des téraoctets et aujourd'hui des centaines de téraoctets (G Suite for Education propose un quota illimité pour chaque utilisateur, gratuitement). Je n'ai jamais pu revenir en arrière. Les serveurs de stockage ont retrouvé des espaces libres, vite remplis par les utilisateurs qui, c'est bien connus, ont horreur du vide...

La seule consolation que j'ai aujourd'hui, c'est de voir que presque tous les DSI des écoles de commerce et des écoles d'ingénieurs privées ont fait le même choix d'externalisation dans le Cloud. Sauf que la plupart sont chez Microsoft avec son offre gratuite Office 365. Le diable sait tout faire, afin que le DSI devienne sa proie.

L'œil était dans la tombe, et regardait Zythom...

Malgré cette charge en moins, ma salle serveurs vieillissait et son remplacement commençait à devenir d'actualité. C'est à cette époque qu'un logiciel quasi magique est apparu sur mes radars de veille.

Billet n.33
--------------

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

La Conscience, Maison de Victor Hugo [Public domain], via Wikimedia Commons

Source : https://zythom.blogspot.com/feeds/907604816743897399/comments/default


25 ans dans une startup - billet n.31

jeudi 27 septembre 2018 à 05:00
Introduction - billet n.30

En 2009, la téléphonie mobile commence à bien s'implanter dans les usages. De plus en plus de personnes disposent d'un téléphone portable et celui-ci évolue rapidement d'un simple appareil proposant uniquement la fonction téléphonique à un téléphone intelligent ressemblant de plus en plus à un ordinateur.

En quelques années, notre système de messagerie électronique basé sur un serveur web Apache et un magnifique SquirrelMail développé en PHP allait devenir un point de crispation des utilisateurs... Le nombre de messages, le volume des pièces jointes, le besoin de partage des contacts et l'accès facile via les smartphones allaient avoir raison de la solution que nous avions mis en place.

Parallèlement à cela, notre accès internet commençait à être saturé de messages, de SPAM, de transferts de fichiers... Les utilisateurs souhaitaient pouvoir stocker de plus en plus de données, et celles-ci devenaient de plus en plus volumineuses. Ils souhaitaient pouvoir les partager facilement et travailler de manière collaborative dessus.

Tout le monde voulait une solution simple et pouvoir l'utiliser depuis un ordinateur portable, une tablette ou son téléphone.

Depuis quelques années, nous avions abandonné notre fidèle sendmail pour lui préférer le plus simple Postfix. Nous déployions des trésors d'ingéniosité pour protéger nos utilisateurs contre les SPAM, avec du greylisting (PostGrey), du filtrage de contenu avec SpamAssassin, du filtrage bayésien, du filtrage par mots clefs, du filtrage heuristique... Nous blacklistions les serveurs via des bases de données RBL, nous surveillions les envois de nos serveurs pour ne pas être nous mêmes blacklistés...

Le système informatique que j'avais mis en place vieillissait, et il m'apparaissait comme de plus en plus évident que j'arriverais difficilement à pouvoir proposer le service réclamé par mes utilisateurs, avec les moyens à ma disposition. Entre les utilisateurs mécontents et le service rendu de mauvaise qualité, cela craquait de toutes parts, il fallait trouver une solution, et vite...

Vous n'allez pas aimer la solution que j'ai choisie...

Billet n.32

--------------

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Par Sam Johnston [CC BY-SA 3.0], via Wikimedia Commons

Source : https://zythom.blogspot.com/feeds/8081819519723050138/comments/default