YBoy360 a écrit 673 commentaires

Je fourni généreusement un lien pour l'installation des Type 1 :

video-installation-type1

Voilà, ces "Type 1" sont fabriqués en France en plus, entre Roubaix et Strasbourg, à Reims.

Bon chance à eux!

Il s'agit du site de Roubaix, pas celui de Strasbourg.

Pour moi le rapport est édifiant : pas de parafoudre type 1 sur les tableaux basses tensions, en plus du paratonnerre avec le câble de masse qui se balade à l'intérieur des locaux, sans parler des batteries (qui ne respectent pas les conditions minimales), qui se trouvent de plus non isolées (le document n'est pas très clair à ce sujet).

Faut bien comprendre qu'en France et en Europe, la réglementation est très précise concernant les installations électriques : par exemple il est interdit d'avoir des prises électriques de recharge de voiture en étage. Ça doit être en sous-sol. Exit les parkings en étages, tous les parkings respectent scrupuleusement ces directives. Ici on apprend qu'avoir des locaux de batteries en étage, non dans des locaux séparés, sans accès pour les pompiers, c'est : "oh, allez, mise en conformité mineur", correction en 2022 … C'est bon, ils ont fait un bassin de rétention d'eau.

OVH n'est pas low cost. Ce qui est low cost, c'est de mettre des Kimsufi dans le même emplacement que ses propres serveurs dédiés haut de gamme (dans le même emplacement que les onduleurs…).

On lâchait plus de 1 000 EUR par mois chez OVH, avec des engagements sur 2 ans sur des machines dédiées (5), ça ne me posait pas de problème. Mais la communication d'OVH suite à l’incident, à coup de "Ah, maintenant c'est le PRA qu'il faut mettre en place les rigolos", ou "C'est de la faute du client si il perd des données", ou "C'est l'intervenant extérieur" … ça m'énerve. J'aurais bien aimé avoir une communication axée sur des faits : savoir ce qu'il s'est réellement passé, ce qui a défailli… Ok pour faire des datacenters économiques, qui se refroidisse par convection naturelle, peut-être plus écologique, ils ont certainement plein d'arguments, c'est ça que j'aurais aimé entendre de leur part.

Si on veut rester en France, je suis persuadé qu'il y a d'autres fournisseurs proposant un service plus respectueux de leurs clients, avec une qualité équivalente.

tu peux utiliser SWT (c'est pas exactement ce que tu demandes, c'est agnostique au toolkit de la plateforme), tu as même un binding LWJGL-SWT (Vulkan, OpenGL, CUDA, OpenCL …).

Au passage, pour tout ce qui est graphique, orienté jeux vidéos en Java, LWJGL est pas mal. C'est aussi un outils pour faire des bindings.

Pourquoi ne pas utiliser directement un DSL en Kotlin pour remplacer Glade ? à la TornadoFx par exemple ? Je suis accro aux DSL, mais avec Groovy.

Peut-être que j'ai mal compris ton second point et que c'est ton objectif..

Bravo en tout cas.

Mince, on est les premiers en "parafoudre datacenter" sur un certain moteur de recherche … Bon, on a rien à voir avec les UPS d'OVH, nos protections seront intégrées dans les futures UPS, avec une nouvelle norme concernant la fin de vie (autrement dit, coupure) (il y a beaucoup à dire sur le sujet, mais ce n'est pas l'objet de ce site)…

Un autre lien concernant le principe de fonctionnement (je ne peux pas éditer mes précédents messages pour les corriger, je n'aime pas spammer…) : Les éclateurs à gaz.

Nos produits ne sont pas utilisés pour les onduleurs de datacenter (à priori), mais dans les onduleurs de fermes photovoltaïques (je ne mets pas de lien). Il est plus compliqué de protéger des installations en courant continu qu'en courant alternatif. La coupure est bien plus complexe à obtenir : le composant sert à rediriger l'excès d'énergie vers la masse, il doit ne pas devenir conducteur, mais se déconnecter automatiquement en deçà d'un certain seuil, sinon tout crame.

Les composants en question sont des éclateurs à gaz.

Merci pour cette réponse passionnante.

Concernant notre problème, sur le plan physique, il faut calculer l'évolution des flux de plasma, dans une enceinte close. Il n'y a pas de flux au départ, puis un plasma est créée suite à un phénomène transitoire (comme une surtension dans un circuit électrique), puis il se déplace.

Le but de nos recherches, c'est de connaitre comment évolue le plasma pour connaitre les caractéristiques électrique au cours du temps du composant électronique.

On est en plein dans l'actualité, ces composants sont utilisés aussi bien dans les UPS des datacenter que dans votre box internet.

Sur le plan de l'analyse numérique, on utilise COMSOL depuis 5 ans, avec le module PLASMA. C'est donc relativement récent pour nous. Mais nous faisons beaucoup de recherche expérimentale depuis bien plus longtemps.

à ta connaissance, si nous voulions travailler avec des universités/écoles sur ces problème, vers où nous orienter ?

Merci encore!

Tu m'étonnes, et ceux qui ont des backups à restaurer, des PRA à déterrer …

plan de reprise

Les centres de données d'OVHCloud à Strasbourg ne sont pas dotés de réseaux d'extinction. Ils ne sont pas équipés de gicleurs d'eau comme c'est le cas dans les datacenters d'OVHCloud à Beauharnois au Canada, ni de brumisateurs haute pression permettant de résorber les flammes tout en protégeant les machines contre l'eau, ni de gaz inerte, à l'instart de la plupart des datacenters du marché.

Personnellement j'ai du mal à y croire.

1 - où est l'expertise dans le commentaire ? la titre à le malheur de résumer le lien cité plus haut.

2 - ça n'est pas sur ce journal, tu as pris ce commentaire dans la section "liens", qu'apparemment tu n'as pas lu ;

3 - ça ne parle pas de l'incendie, le sujet est "OVH et la protection incendie"… ça datait de 2013. à aucun moment Strasbourg n'est abordé…

Donner des leçons te va très bien, mais essaie juste d'être dans le sujet, à minima.

Cet argumentaire est basé sur une photo et délivré par on ne sait pas qui et sans références précises.

Cet argumentaire est basé sur les photos du lien, celles de Roubaix 4, qui sont vraiment explicites.

Celle-ci en particulier :

Puisqu'on en est à donner son expertise personnelle, dans le bâtiment d'où est extrait le lien :

• L'ossature est en métal, non isolé.

• Le bois est utilisé pour les sols (on ne sait pas si il est ignifugé). Ce bâtiment semble être construit comme un préfabriqué.

D'après le thread de discussion, on utilise très rarement de sprinkler dans les datacenters depuis pas mal de temps. Si mes souvenir sont bons, le bâtiment dispose d'une alimentation de 240 kW. Alors oui, il doit y avoir un automate qui coupe l'alimentation AVANT de bousiller les serveurs avec l'eau sortant des sprinkler (ce n'est pas une simple douche, normalement, si il n'y a pas de feu dû à une surtension, c'est imparable pour le feu).

D'après les photos, les conduits sur lesquels sont fixés les sprinkler sont en PVC renforcé … Normalement ça brûle et c'est toxique.

P.S. couper une alimentation de 240 kW est quelque chose de compliqué, plus compliqué que de me dire si mon serveur est en carafe ou pas.

Ok, bien reçu, bien que n'étant pas expert j'ai encore le droit d'émettre une opinion? Désolé si mon agacement après avoir vu ces photos m'a précipité sur mon clavier…

Je ne peux que constater comme l'indique l'interface d'OVH, que mon serveur localisé dans le bâtiment SBG2 fonctionne parfaitement… Me voila rassuré, les experts me disent que mon serveur est hors de danger.

Cela dit, Claude François, qui n'est pas un expert, il est vrai, serait d'accord avec moi concernant l'eau et l'électricité.

Bonne journée.

Je ne sais pas si c'est dans leur contrat utilisateur final cette façon de faire de la protection incendie. On accuse souvent les utilisateurs de ne pas les lire, pour bien les comprendre, il faudrait donner ces phtotos (là, c'est sûr, tu backups ailleurs).

J'espère que ceux qui ont des backups à ressortir pourront les exploiter dans de bonnes conditions.

J'aurais dû mettre un :s …

Bien entendu, c'est pas parce que l'on achète une Dacia qu'elle doit prendre feu aux feux rouges.

J'aime beaucoup Scaleway : 1er à faire de l'ARM, système de facturation, interface d'utilisation … J'ai aussi constaté que le réseau n'était pas très bon et j'ai eu pas mal de petits problèmes chez eux, notamment avec Gitlab sur ARM, comme toi je leur ai pardonné. Pas à cause du coût, mais parce qu'ils étaient bien sympa.

Par contre je ne trouve pas OVH particulièrement "low-cost", du moins pour ses serveurs dédiés. Un low-cost, c'est Kimsufi. Pour moi OVH, ce sont des grossistes "à la Leclerc" : Ils sont agressifs au niveau de certains tarifs, mais tu payes ton engagement sur 2 ans pour l'obtenir… Les prix d'appels sont intéressants, mais tu payes bien plus les grosses machines correspondant à tes besoins. Côté services, soit je ne comprends pas leur interface, soit y a rien. En plus c'est le Far-West leur interface. Ils se dispersent dans tous les sens.

Maintenant je n'ai pas de comparatifs précis pour le coût des serveurs. Pour la BP, on va dire comme tu dis qu'on paye pour ce que l'on a.

Pour les incendies, excusons-les, ils ont des prix d'appels bas.

Mouai, on backup tous nos serveurs (sauf un, il a cramé ce matin) très facilement sans avoir besoin de consommer de l'énergie/occuper un serveur pour rien.

Nous avons été impacté, nous avons perdu notre Gitea (c'est un peu la merde), sans backup récent. C'est la faute à pas de temps et au fait qu'il faille penser au backup AVANT d'installer ce soft (impossible de faire un rsync via ssh sur le répertoire où est l'application automatiquement, impossible d'avoir un snapshot de la partition chez OVH, backup très volumineux …). Je dis pas qu'on a pas une petite part de responsabilité (nous n'utilisons que git, donc on s'en fout presque, mais une autre équipe met tout l'historique de ses projets dessus)…

Bref, je trouve l'opinion bien indulgente envers OVH. Ça sert sans doute à rien de les critiquer en ce moment, mais depuis quelques temps, j'ai vraiment envie de les fuirent. Il y a qu'a voir l'absence de communication, l'interface web confuse, les performances réseaux à certaines heures, l'engagement qu'ils imposent à leurs clients …

Le côté artisan "béret-baguette" c'est sympa, mais on a l'impression qu'ils n'ont pas misé sur leur croissance organique.

Super, merci, envoyé !

Merci pour ce conseil. En effet, ça semble bien correspondre à nos besoins. J'aurais bien aimé avoir un tel outils en 98..

J'essaierai de faire un retour d'expérience si nous l'utilisons.

Merci pour cette rédaction, en effet, pour avoir un peu joué avec ParaView, on aimerait faire ça toute la journée…

Récemment, j'ai pu voir quelques évolutions intéressantes dans SALOME, notamment le nouveau modeleur paramétrique Shaper. Il remplace avantageusement le module Geometry, il semble rivaliser avec FreeCAD… Il y a tellement à dire qu'il faudrait sacrifier 1 mois de temps d'un physicien/informaticien/mécanicien pour faire un journal de la qualité de celui-ci sur ce logiciel (SALOME).

Je profite de ce commentaire pour demander un avis :

Actuellement nous utilisons COMSOL multiphysics pour simuler le comportement d'un plasma froid (et des effets de celui-ci sur son conteneur, aux électrodes et sur l'enveloppe) lorsqu'il est soumis à un champs électrique variable. C'est pas mal, mais c'est une solution coûteuse, surtout si l'on veut distribuer le calcul sur plusieurs machines.

Y a t-il une solution OpenSource qui puisse se comparer à COMSOL pour ce cas d'usage?

J'ai testé Elmer FEM et à l'époque, un peu SALOME, il faudrait tester FreeFEM, j'en ai conclu que je n'ai plus (j'ai failli faire un PhD sur les plasmas, comme un con j'ai dit non) le niveau, et de loin.

Merci d'avance à celui qui se lance sur la rédaction d'un journal /ou d'un avis sur SALOME/Shaper autres.

Merci, pour miner je pensais qu'il fallait trouver les nombres premiers dans un intervalle toujours grandissant …

ça permettrait pas de miner plus rapidement les coins ces méthodes ?

Moi j'aime beaucoup sa démarche. Et je me pose la même question concernant sudo et le mot de passe root…

En plus j'ai travaillé 6 ans chez Sun, pour migrer des très gros (très très gros) logiciels de Solaris 2.6 à Solaris 10, SunStudio, certifier les plateformes, faire de l'optimisation CPU/GPU, corriger les Heisenbugs des compilateurs, me faire taper dessus jusqu'à plus soif…

C'était génial, mes clients c'était Airbus, Boeing, Volkswagen, Renault, Ford. Puis Billou est arrivé avec son chéquier, et d'autres erreurs de management de Sun et je me suis cassé.

Bref, ce journal m'évoque plein de choses à conter, comme l'auteur, je déteste Ubuntu pour plein de vrais raisons… Que d'émotion!

C'est un problème lié à la façon dont PHP gère son évolution (non compatible de manière ascendante au niveau du langage) ça.

Si tu veux du Python 2.7, 3.7, 3.8, du PHP 7.4 et 8.0 ou plusieurs version de la libc, ainsi de suite, reste sur une vielle version ou utilise une Debian (qui a plus de mainteneurs). Je préfère que les mainteneurs se focalisent sur l'intégration de nouveautés plutôt que de maintenir plusieurs versions de la même chose (quitte à perdre certaines applications pendant un temps).

Il faut juste 2 fois plus d'énergie pour gérer 2 versions différentes de PHP, sans compter la configuration / disposition des fichiers qui doit tenir compte des multiples version possiblement installée en parallèle. En plus de maintenir toutes les dépendances sur 2 versions…

$ urpmq -ay php | wc
    468     468    8849