Journal OVH - Le nuage part en fumée ?

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
36
10
mar.
2021

Pas de bol pour OVH, qui a souffert d'un incendie dans ses locaux de Strasbourg.

Après, c'est exactement le genre de catastrophes auxquelles un bon admin réseau se prépare, c'est donc un bon test (quoique probablement coûteux). Tous mes services chez OVH semblent fonctionner comme d'habitude, on peut espérer que leurs sauvegardes et autres plans de reprise d'activité ont fonctionné.

  • # Toujours down à Strasbourg

    Posté par  (site Web personnel) . Évalué à 8 (+6/-0). Dernière modification le 10/03/21 à 09:47.

    Ils ont beaucoup de datacenter. Celui de Strasbourg n'est toujours pas rétabli (ils migrent vers Gravelines si j'ai bien compris). J'ai un dédié à Roubaix (bien accessible) mais mon VPS de Strasbourg est bien mort pour le moment.

    En plus depuis hier je me disais qu'il était temps qu'un jour je fasse une copie de mes sauvegardes à la maison (mes laptops et mon NAS) sur un VPS ou un serveur de stockage car je me suis dit que je ne suis pas à l'abri d'un incendie ou cambriolage à la maison…

    Comble du sort, bien que je fasse des backups de mon dédié, j'ai jamais encore pris la peine de faire un backup de mon VPS (car c'est juste un petit blog et un shell permanent). Mais bon là je peux m'en prendre qu'à moi même.

    l'azerty est aux dispositions ce que subversion est aux SCMs

    • [^] # Re: Toujours down à Strasbourg

      Posté par  (site Web personnel) . Évalué à 6 (+6/-2).

      Du coup, je suis en train de faire des sauvegardes de mes sites :-) lesquels ne sont pas chez OVH.

      Designeuse de masques pour sphéniscidés.

    • [^] # Re: Toujours down à Strasbourg

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 11/03/21 à 08:36.

      Moi, j'ai commandé mon VPS lundi pour faire un backup de mon Kimsufi.

      Bon, ben le backup est mort :D

      Le seul truc embêtant, c'est que j'ai viré le système de rsync entre mon Kimsufi et mon laptop donc là j'ai plus du tout de backup de mon serveur pour quelques jours :/

      • [^] # Re: Toujours down à Strasbourg

        Posté par  . Évalué à 9 (+7/-0).

        j'ai viré le système de rsync entre mon Kimsufi et mon laptop

        Perso je pense que c'est pas une grande idée : mettre tous ses oeufs chez le même fournisseur c'est s'exposer par exemple au classique "nous avons détecté une utilisation frauduleuse de votre compte, alors nous avons coupé tous les accès", ou au moyen de paiement périmé ou…

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Toujours down à Strasbourg

        Posté par  . Évalué à 6 (+5/-1).

        un vps, c'est acheté et installé en 1h chez n'importe qui d'autre. Je ne vois pas pourquoi il te faudrait plusieurs jours ?

        Même si tu bosses, 1ère pause café pour commander le serveur le matin, deuxième pause à midi pour se connecter créer un user, copier ta clé publique et lancer un premier script de backup de test. Pause café de l'après midi pour vérifier et foutre le cron.

        Cela-dit un rsync ce n'est pas un backup si tu ne fais pas des snapshots et de la rotation derrière.

  • # Tocard & esbroufe ?

    Posté par  . Évalué à -10 (+8/-24). Dernière modification le 10/03/21 à 10:39.

    OVH semble coutumier du fait.
    Strasbourg avait été victime d'une grosse panne électrique il y a quelques années. Le datacenter était alimenté par des groupes mobiles provisoires et sans redondance…
    Et l'impact avait débordé sur le reste.
    Klaba avait alors juré le coeur sur la main que l'amateurisme était terminé.
    Et là, paf, SBG2 qui part en fumée avec SBG1. Et SBG2 n'a pas eu besoin des 7 sites Seveso voisins pour s'incendier.

    Mais déjà, mettre un DC à côté de sites Seveso laisse songeur.

    Le champion européen il paraît…
    Et qui veut s'introduire en bourse.

  • # test grandeur nature :-/

    Posté par  (site Web personnel) . Évalué à 6 (+6/-1).

    Un peu risqué comme test, en effet ^^U

    Bon, ça me permettra de voir si ils avaient la présence de mettre les sauvegardent sur un autre site ^^U

    Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote

    • [^] # Re: test grandeur nature :-/

      Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

      ils louent des machines nues, c'est aux admin qui louent ces machines de faire le nécessaire.
      Mon ancien serveur était dans SBG2 l'actuel est à Roublaix la je respire.

      Mais ça me laisse songeur, Toute les nuits je synchronise les snapshots zfs sur une machine (un hp microserv sous debian) qui est dans ma cave (ça marche bien) et j'ai une autre machine (un synology) qui backup le contenu de mes container dans ma cave et qui pousse ça sur un espace de sauvegarde chez infomaniak à Genève.
      Donc si mon serveur part en fumée je vais pas perdre grand chose mais la question est comment rétablir rapidement les services ?

      • Reprendre un autre dédié chez ovh et migré les ip failovers ? Je pense qu'ils doivent être en rupture de stock actuellement
      • Remonter les containers chez un autre hébergeur ou sur une machine dans ma cave (heureusement ma connexion est à la hauteur) ? Il va falloir revoir les enregistrements dns.
      • Prévoir une machine jumelle dans un autre datacenter ? Et répartir les containers sur les deux serveurs avec synchro zfs entre les deux ? Mais ça va doubler le prix
      • [^] # Re: test grandeur nature :-/

        Posté par  (site Web personnel) . Évalué à 10 (+14/-4).

        Il n'y a rien de nouveau, et c'est à penser avant de se lancer ;-)
        prix au jour le jour (serveur + ton admin) contre coût quand un serveur tombe.
        Si primordial : 2 serveurs synchronisés, sur 2 sites physique voir 2 hébergeurs différents (classique… Pour qui s’intéresse à la dispo et pas juste une IP failover qui ne a pas régler le problème si le site physique tombe car l'IP y est liée, seulement si un matos tombe)
        Si non primordial : 1 serveur backupé et tu commandes un serveur ailleurs et change ton DNS qui se MAJ partout (quelques heures en général) le temps que tu remontes ta machine.

        Bref, du classique calcul de coût total avec les statistiques de disparition d'un site physique :).

        • [^] # Re: test grandeur nature :-/

          Posté par  . Évalué à 10 (+8/-0). Dernière modification le 10/03/21 à 13:27.

          Avoir 2 serveurs chez 2 hébergeurs différents, c'est pas suffisant. Car les hébergeurs parfois partagent eux-même des datacenter et tu peux avoir 2 hébergeurs utilisant des datacenter à km l'un de l'autre qui souffrent du même tremblement de terre. Donc il faut avoir ses serveurs dans des villes/pays différents. Heureuement en général ils te laissent choisir et t'informent de cette location.

          Et ça ne remplace pas des backups.

          Et en parlant des backups il faut aussi se renseigner où les données se trouvent réellement si vous ne le faites pas à la popogne. Imagine que tu souscris à une offre de backup mais que tu ne connais rien des détails. Le service te dis que tes données sont dans un datacenter hyper sécurisé. Tu crois que t'es sain et sauf. Ben si la société qui vend ce service de backup a décidé d'utiliser les services d'OVH, était trop conne pour faire de la distribution et de la replication de données sur n sites et utilisait le même datacenter que toi tu l'as dans le ….

          Oui ça fait beaucoup de si mais bon un datacenter, normalement c'est aussi conçu pour que ça ne crame pas aussi facilement. En tout cas pas assez pour cramer plus de quelques racks dans une salle. En général quand la fumée est détectée, que l'alerte sonne et le gyrophare s'allume t'as 30s pour quitter la salle avant que l'azote (ou autre gaz inerte) n'ait remplacé toute l'oxygène. Donc des si, on en a déjà utilisé beaucoup.

          • [^] # Re: test grandeur nature :-/

            Posté par  (site Web personnel) . Évalué à 4 (+4/-2).

            Car les hébergeurs parfois partagent eux-même des datacenter

            Je voulais bien sûr dire dans deux datacenters pour un même hébergeur (gestionnaire) voire chez deux hébergeurs ayant leur propre datacenters distant de mini plusieurs dizaines (voire centaines, pour ne pas avoir les mêmes accès électricité ou fibres) de km, je ne pensais pas aux "intermédiaires" qui s'affichent hébergeur mais sous-traite soit le site physique soit le site physique et les machines physiques.
            Etre chez X et Y qui commandent en réalité tous le deux chez OVH à SBG c'est du placebo :).

            En tout cas pas assez pour cramer plus de quelques racks dans une salle.

            C'est la que ça risque de craquer, OVH faisait de la pub de son idée de container ("trop bien ce truc!") mais la presse rapporte que les pompiers ont souffert car électricité pas coupable + impossibilité en pratique de rentrer dans les "salles" (des containers…) pour attaquer à la source. Les containers auraient été acceptable si…

            En général quand la fumée est détectée, que l'alerte sonne et le gyrophare s'allume t'as 30s pour quitter la salle avant que l'azote (ou autre gaz inerte) n'ait remplacé toute l'oxygène

            Si on apprend qu'ils n'ont pas ça, ou même pas de l'eau pour du "pas cher", ça va clasher… OK low cost, mais cramer le DC en entier…
            Après, vu le prix peut-être que ce sera compris (après les premiers "où sont mes données?") et que ça ne leur fera pas si mal.


            Mais au moins ça fait une (grosse) piqûre de rappel qu'il faut éviter de mettre tous ses oeufs dans le même panier, on avait un peu perdu l'habitude vu les DC assez stables à l'heure actuelle (moins de cas d’inondations etc)…

          • [^] # Re: test grandeur nature :-/

            Posté par  . Évalué à 3 (+2/-0).

            En général quand la fumée est détectée, que l'alerte sonne et le gyrophare s'allume t'as 30s pour quitter la salle avant que l'azote (ou autre gaz inerte) n'ait remplacé toute l'oxygène.

            C'est toujours autorisé le halon ?!

            • [^] # Re: test grandeur nature :-/

              Posté par  (site Web personnel) . Évalué à 10 (+37/-0). Dernière modification le 10/03/21 à 20:25.

              Non, le halon n'est plus autorisé (et heureusement !).

              Je voudrais tuer une légende, parce que je l'ai lu dans les deux fils concernant l'incident d'OVH :

              Les systèmes au gaz (azote) n'évacuent pas, ni ne 'consomment', l'oxygène de l'air. Ils diminuent seulement sa concentration (de 21 à ~18/16%) dans l'air, diminuant la part oxydant du triangle du feu.

              Ils ont aussi l'avantage de faire baisser la température (expansion liquide -> gaz), diminuant la part énergie du triangle du feu.

              L'effet recherché est l'étouffement du feu, sans altérer le matériel électrique (donc informatique).

              Pour avoir testé, on se retrouve au sommet de l'himalaya en deux minutes. Ça file un bon mal de crâne, mais ça ne tue pas. Si les buses de diffusion sont "subsoniques", le matos informatique est sauvable, sinon, on dit adieu à ses disques mécaniques et à ses axes de ventilo (et à ses tympans si on est resté dans la salle).

              Il existent aussi des systèmes d'extinction à la mousse (humide) ou micro-brouillard. Dans ce cas, il faut que l'alimentation électrique IT ait été coupée. Ça coûte un peu plus cher et les tests sont… pénibles.

              mes 2c.

          • [^] # Re: test grandeur nature :-/

            Posté par  (site Web personnel) . Évalué à 10 (+13/-0). Dernière modification le 10/03/21 à 18:19.

            En fait, gérer un service en ligne, c'est un métier.

            On dirait que beaucoup de gens le découvrent aujourd'hui (serveurs sans aucun backup ou backup dans le même datacenter, solutions non redondées, etc).

            Si toute ton activité repose sur un serveur virtuel payé 10€ HT/mois, faut pas s'étonner d'être dans la panade le jour où il y a un incendie.

            J'espère que ça va faire du bien à la profession (administrateur système et réseaux, exploitation, etc)

            Je pense en particulier à toutes les startups gérées par des équipes de dév qui font du déploiement en continu mais qui ne connaissent pas / comprennent pas / prennent pas en compte ces problématiques en compte. D'ailleurs, c'est souvent les décideurs (ou clients) qui veulent économiser.

            Note : je ne te vise pas, hein, c'est ton message qui me fait penser à ça.

        • [^] # Re: test grandeur nature :-/

          Posté par  . Évalué à 2 (+3/-2).

          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.

          • [^] # Re: test grandeur nature :-/

            Posté par  . Évalué à 10 (+11/-0).

            Je dirais que la responsabilité des uns n'annule pas celle des autres.

          • [^] # Re: test grandeur nature :-/

            Posté par  (site Web personnel) . Évalué à 10 (+11/-3). Dernière modification le 10/03/21 à 14:27.

            l'opinion bien indulgente

            Ben… Tu payes low-cost, tu as low-cost, possibilité de disparition d'un datacenter compris.
            A l'inverse, c'est lourd les gens qui insultent OVH qui n'aurait pas backupé tout sur un autre site alors que pas dans le contrat.
            L'indulgence ne viendrait-elle pas de la connaissance de ce qu'on a pour ce qu'on paye?

            J'ai par exemple eu une Dedibox qui est morte à un reboot, Scaleway me faisait de plates excuses car la machine était juste morte sans pouvoir récupérer les données, j'ai juste répondu que vu le prix c'est normal et je me suis fais livrer une nouvelle machine (vierge), 100% normal (je n'ai pas payé pour un dédié avec disques hot-swap ou récupérables…)

            A noter que je mets la non sécurité d'un datacenter entier face à des flammes pas forcément dans l'excusable par rapport à un minimum de sécurité, une indulgence générale (et ne pas blâmer la perte de données) ne dit pas indulgence sur tout.

            mais on a l'impression qu'ils n'ont pas misé sur leur croissance organique.

            Ils ont misé sur le low-cost, te laissant faire la redondance, mais les gens ont eu tendance à voir que le prix et pas regardé que derrière c'est à eux de compenser les options pas incluses (redondance, backup, etc).

            les performances réseaux à certaines heures,

            Quel contrat as-tu? Bande passante garantie ou pas? si pas garantie, ben… C'est normal, tu as ce pour quoi tu as payé.
            Une des choses qui me plait pas mal chez OVH est un réseau pas mal, par exemple chez Scaleway chez 100x plus de lenteurs dès que tu sors de France (ça s'effondre parfois à moins de 1 Mbps…)

            • [^] # Re: test grandeur nature :-/

              Posté par  . Évalué à 4 (+4/-1). Dernière modification le 10/03/21 à 15:14.

              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.

              • [^] # Re: test grandeur nature :-/

                Posté par  . Évalué à 10 (+15/-1).

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

                Je ne suis pas pour déresponsabiliser les gens qui ont perdu des données mais eux là non je ne peux pas être d'accord.

                Bon il n'y a pas de résultat d'enquête mais face aux incendies l'excuse du low cost n'existe pas. OVH a non seulement une responsabilité envers ses clients, mais aussi envers la société. C'est pas parce que tu es assuré que tu peux te permettre de faire de la merde et que c'est acceptable de risquer la vie de tes employés, des personnels de secours et d'avoir un incendie qui se propage chez tes voisins.

                • [^] # Re: test grandeur nature :-/

                  Posté par  . Évalué à 6 (+6/-1).

                  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.

                • [^] # Re: test grandeur nature :-/

                  Posté par  (site Web personnel) . Évalué à 1 (+5/-6).

                  En même temps, on ne connaît pas les causes de l'incendie… Pas plus qu'on sait exactement comment ce bâtiment a été construit, etc. C'est facile de jouer les experts dans ce cas-là.

                  Designeuse de masques pour sphéniscidés.

                  • [^] # Re: test grandeur nature :-/

                    Posté par  (site Web personnel) . Évalué à 2 (+9/-9).

                    On s'en fout complet des causes comme de comment ce bâtiment a été construit, ce n'est pas le sujet.
                    Le sujet est que ça ne doit pas brûler en entier (à la limite une salle, et encore), sauf grandes exceptions genre un avion qui se crashe pile sur le datacenter qui reporterait la responsabilité ailleurs (spoiler : tout porte à croire que ce n'est pas le cas).

                    Ce n'est pas une question de jouer les experts, ce qui est arrivé ne doit pas arriver, OVH comme n'importe quelle autre entreprise a une responsabilité envers la société dans son ensemble (les gens qui ont perdu des données sont un dommage qui les concernent eux seulement car pour eux ce n'est pas pire que la perte de quelques disques ayant lâché, pas la société dans son ensemble).

                    • [^] # Re: test grandeur nature :-/

                      Posté par  (site Web personnel) . Évalué à 2 (+8/-8).

                      Ce n'est pas une question de jouer les experts

                      C'est très exactement ce que vous faites.

                      Designeuse de masques pour sphéniscidés.

                      • [^] # Re: test grandeur nature :-/

                        Posté par  . Évalué à 5 (+4/-1). Dernière modification le 11/03/21 à 11:02.

                        Pas vraiment.

                        Nous on dit qu'il y a forcément une ou plusieurs erreurs de faites, car un datacenter est normalement conçu pour ne pas que ça arrive.

                        L'expert c'est celui qui pourra dire après enquête quelles erreurs exactement ont été faites.

                        Et dans tous les cas la responsabilité incombe à OVH et à ses sous-traitants (mais le choix des sous-traitants et les éventuelles décisions malgré d'éventuelles alertes est aussi de leur responsabilité).

                        • [^] # Re: test grandeur nature :-/

                          Posté par  (site Web personnel) . Évalué à 8 (+6/-1).

                          Nous on dit qu'il y a forcément une ou plusieurs erreurs de faites, car un datacenter est normalement conçu pour ne pas que ça arrive.

                          Le risque zéro n'existe nul part.

                          Peut être que OVH ou un de ses sous traitants a merdé, mais peut être pas. Avec aussi peu d'infos à ce stade pointer du doigt leur responsabilité d'entrée de jeu n'a pas grand intérêt.

                    • [^] # Re: test grandeur nature :-/

                      Posté par  . Évalué à 4 (+4/-2).

                      ce qui est arrivé ne doit pas arriver

                      « Nobody expects the Spanish Inquisition »

              • [^] # Re: test grandeur nature :-/

                Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

                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.

                Kimsufi appartient à OVH, il me semble.

      • [^] # Re: test grandeur nature :-/

        Posté par  (site Web personnel) . Évalué à 1 (+1/-2).

        Mon ancien serveur était dans SBG2 l'actuel est à Roublaix la je respire.

        Tous leurs DC sont fait sur le même modèle, y a pas de raison de penser que ce qui c’est passé à Strasbourg n’aurait pas pu arriver à Roubaix ou à Graveline.

        • [^] # Re: test grandeur nature :-/

          Posté par  (site Web personnel) . Évalué à 7 (+6/-1).

          A ma connaissance le modèle container n'est que sur SBG (et même qu'il devait disparaitre, tu as des infos/photos des autres sites sur ce modèle?

          Moi je trouve par exemple OVH Graveline pas en containers.

          • [^] # Re: test grandeur nature :-/

            Posté par  (site Web personnel) . Évalué à 3 (+5/-4).

            Je pensais pas au modèle en container quand je parlais de modèle. Je veux dire que les techno (élec, water cooling, baies horizontales faites maison) sont globalement les mêmes, que les équipes sont gérés de la même manière, que bien faire les choses passe après gagner du fric, etc.

          • [^] # Re: test grandeur nature :-/

            Posté par  (site Web personnel) . Évalué à 3 (+2/-1). Dernière modification le 15/03/21 à 15:37.

            Comment tu es arrivé à la conclusion que c'est le modèle container qui est en cause ? De ce que je comprend le feu s'est déclaré et a détruit SGB2 qui était une structure en dur. SGB1 (container) était juste a côté et a été touché aussi mais ça n'est vraisemblablement de là qu'est parti le feu.

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: test grandeur nature :-/

          Posté par  . Évalué à 10 (+14/-3).

          Je propose d'ailleurs aux clients d'OVH de se rendre à l'intérieurs des datacenters pour y allumer des cierges en priant pour qu'un ncendie ne se déclare pas sur les autres sites.

          • [^] # Re: test grandeur nature :-/

            Posté par  . Évalué à 3 (+5/-2).

            Bon, je précise quand même que je plaisante … (il y a des gens qui pourraient me prendre au sérieux. Si c'est le cas, n'y allez pas, de toute façon vous vous ferez jeter par la sécurité).

            • [^] # Re: test grandeur nature :-/

              Posté par  . Évalué à 10 (+14/-3). Dernière modification le 11/03/21 à 22:22.

              A une époque j'aurais parlé d' "humour noir" mais certains, tout feu tout flammes, y auraient vu une connotation raciste … Du coup j'ai préféré éviter les querelles fumeuses ou les discussions enflammées. La moindre étincelle pourrait mettre le feu au poudre et certain en profiteraient pour ajouter de l'huile sur le feu.

  • # Le nuage part en fumée ?

    Posté par  . Évalué à 6 (+6/-2).

    Le nuage part en fumée ?

    C'est justement l'inverse. C'est plus un problème d'hébergeur traditionnel que de cloud. Les pratiques du cloud sont faites pour permettre d'être multi-DC ou de migrer très rapidement.

    • [^] # Re: Le nuage part en fumée ?

      Posté par  . Évalué à 2 (+3/-2).

      moi le titre, je l'ai trouvé très bon et sinon ils sont où tes serveurs de cloud ? dans la nature ? non dans un datacenter comme les autres donc il peuvent aussi cramer comme le reste !

      • [^] # Re: Le nuage part en fumée ?

        Posté par  (site Web personnel) . Évalué à 10 (+12/-4). Dernière modification le 10/03/21 à 19:15.

        donc il peuvent aussi cramer comme le reste

        L'auteur ne dit pas du tout le contraire, tu as juste loupé son point.

        Pour être plus explicite : le "cloud", c'est géré par quelqu'un qui te fournit un service. C'est cher, plus cher que des serveurs pas cher dont des admins du dimanche pleurent la perte (je précise : j'en ai perdu un cette nuit; je ne pleure pas car je sais que je payais un service précis, soit la possibilité à 0.1% de perdre cette machine; RIP ma machine et je passe à autre chose, elle est juste sortie du pool), justement parce que la redondance est incluse (par exemple Amazon S3 promet 99.999999999% contre 99.9% pour OVH, la différence vient du fait qu'Amazon réplique sur 3 DC d'une zone, et en option tu peux même répliquer sur une autre zone pour au cas d'une guerre nucléaire sur la zone entière). Le cloud, c'est la couche au dessus de ce qui a cramé la.

        Bref, il peut y avoir un incendie qui détruit un DC, le cloud fait que toi utilisateur du service tu ne le verras pas, d'où le titre qui pourrait être très bon si pas HS.

        de cloud ? dans la nature ? non dans un datacenter

        Si un, ce n'est pas vraiment un cloud, c'est plutôt un serveur (virtuel ou pas).
        Ici, tout service dans le cloud bien fait n'a pas du tout été impacté car un autre serveur a pris automatiquement le relai et absolument rien n'a été vu par les clients.

        Note : je ne blâme pas les sites HS, le cloud ça coûte du pognon et certains n'en n'ont pas besoin. Par contre le admisn du dimanches qui se plaignent d'avoir perdu trop de thune à cause de leur choix de pas acheter du cloud mais plutôt un serveur, ben le problème n'est pas OVH (qui a une responsabilité sur un incendie inacceptable, mais pas sur la perte de données, cf le contrat).

        • [^] # Re: Le nuage part en fumée ?

          Posté par  . Évalué à 0 (+3/-4).

          merci pour ta réponse zenitram mais moi dans le message auquel je réponds, je ne vois aucune des choses dont tu parles … ou alors ça veut dire que l'auteur répondait à un commentaire et qu'il s'est loupé en créant un nouveau commentaire au lieu de répondre à un commentaire existant, ce qui est tout à fait possible.

          sinon merci pour l'explication du cloud :D mais tu peux faire du cloud dans un seul Datacenter comme entre plusieurs … ça dépend de ce que tu construis et utilises et le problème vient juste du fait que nos chers "décideurs" n'ont qu'une notion très partielle de ce qui se passe et pensent que par ce que c'est dans un cloud public c'est bien et que ça fonctionne toujours.

          Moi ce Datacenter qui a cramé, je trouve ça très bien car ça remet l'église au milieu du village et ça montre à certains que PCA/PRA et réplication entre datacenter c'est la base de la sécurité en terme de SI et de services ce que beaucoup ont tendance à oublier un peu trop rapidement notamment dans certains ministères sur la mise en place de projets de datacenters régionaux.

          • [^] # Re: Le nuage part en fumée ?

            Posté par  . Évalué à 5 (+4/-1). Dernière modification le 10/03/21 à 23:03.

            sinon merci pour l'explication du cloud :D mais tu peux faire du cloud dans un seul Datacenter comme entre plusieurs …

            OSEF si tu achète un service cloud tu achète une sécurité. Si ton prestataire est en mesure de faire du 99,9999999% sur une seule machine c'est son problème pas le tiens. Les gros cloud présentent souvent des zones géographiques pour différentes raisons (pour des questions de performance, pour des questions légales (tu peux ne pas vouloir sortir les données d'une zone géographique),…).

            Quand tu te paie un service de base de données managée le ou les racks dans les quels sont tes données n'est plus ton problème. On te vend un service avec un taux de disponibilité (possiblement un SLA avec contrepartie), des points d'accès et une zone géographique.

            C'est la définition du cloud : tu soustraite toutes la partie hébergement pour que ça ne soit plus qu'un service que l'on te vend. Tu n'achète plus des machines, mais un service.

            Moi ce Datacenter qui a cramé, je trouve ça très bien car ça remet l'église au milieu du village et ça montre à certains que PCA/PRA et réplication entre datacenter c'est la base de la sécurité en terme de SI et de services ce que beaucoup ont tendance à oublier un peu trop rapidement notamment dans certains ministères sur la mise en place de projets de datacenters régionaux.

            Les sérieux font volontairement tomber des DC tous les quelques mois.

            • [^] # Re: Le nuage part en fumée ?

              Posté par  . Évalué à 5 (+7/-4). Dernière modification le 12/03/21 à 09:53.

              C'est la définition du cloud : tu soustraite toutes la partie hébergement pour que ça ne soit plus qu'un service que l'on te vend. Tu n'achète plus des machines, mais un service.

              Le problème c'est qu'il y a des sociétés à mon avis un peu malhonnêtes dans leur communication dont une commence par O et finit par H qui mettent le mot cloud sur des trucs qui ne le sont pas : des dédiés, des vps sur des datacenters précis. Le cloud à l'origine déjà c'est pas un serveur mais un ensemble d'éléments qui constituent une infrastructure en ligne et ça implique une certaine abstraction. Tu peux faire du cloud à base de dédiés et de vps, mais un seul de ces serveur n'est pas un service cloud en soi. Mais bon à force de mettre le mot cloud partout les prestataires informatiques "traditionnels" qui étaient à la ramasse face aux 3 géants et quelques plus petites sociétés innovantes ont galvaudé et fait évoluer la définition vers si c'est en ligne, c'est du cloud.

              Et voilà où on en est maintenant, tout le monde parle de cloud quand il s'agit d'un pauvre petit élément en réseau et les clients naïfs se font avoir quand l'hébergeur a un problème.

              • [^] # Re: Le nuage part en fumée ?

                Posté par  . Évalué à 5 (+3/-0).

                Je ne blâmerais pas plus OVH que n'importe quel autre. On met derrière le mot cloud différents *aaS qui n'ont pas grand rapport entre eux. Après OVH n'est pas très bon en cloud, mais si j'ai bien compris le renommage en ovhcloud est justement pour indiquer une volonté de s'améliorer.

                • [^] # Re: Le nuage part en fumée ?

                  Posté par  . Évalué à 2 (+1/-1).

                  C'est pour ça que j'ai dis "des sociétés". Il sont loin d'être les seuls, à peu près toute l'industrie en fait car peu sont capables d'offir du vrai "cloud".

                  Et c'est la même du côté des logiciels libres, owncloud et nextcloud n'ont de cloud que le nom. Ce sont des serveurs de fichiers avec web/webdav et quelques fonctionnalités ajoutées mais ça n'a rien à voir avec du cloud en soi même si ça sert de remplacement à certains pour des services "cloud".

              • [^] # Re: Le nuage part en fumée ?

                Posté par  . Évalué à 7 (+5/-0).

                Oui, enfin cela fait des années que l'on explique que « cloud » c'est juste un terme marketing qui peut recouvrir des réalités très différentes.

  • # MX Plan H.S.

    Posté par  . Évalué à 2 (+0/-0).

    J’ai pris un MX plan il y a quelques années, et depuis hier soir, plus aucun mail n’arrive… j’espère que c’est lié.

  • # Vous avez rien compris !

    Posté par  . Évalué à 7 (+9/-4).

    C'est le dernier concert numérique de Johnny !

    Emacs le fait depuis 30 ans.

  • # Henryyyyy!!!!!

    Posté par  (site Web personnel) . Évalué à 8 (+9/-3).

    Ça imprimait pas, alors on a bidouillé les câbles.

    Je me demande si Henry a pas collé un virus d'internet dans l'ordinateur…

    La gelée de coings est une chose à ne pas avaler de travers.

  • # Limite indécent

    Posté par  . Évalué à 10 (+16/-0). Dernière modification le 10/03/21 à 16:41.

    Courbe de température du CPU

    https://twitter.com/_Skunnyk_/status/1369638092810895366

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # J'avais un petit VPS avec LibreOffice

    Posté par  . Évalué à 10 (+16/-1).

    Je peux vous dire que le parefeu de LibreOffice, il est pas à la hauteur de celui d'OpenOffice …

  • # Froid dans le dos

    Posté par  . Évalué à 10 (+16/-0). Dernière modification le 10/03/21 à 18:46.

    Malheureusement, ces choses la peuvent arriver. Je le jette pas la pierre à OVH ou à d'autres. Si on prévoit des backups et des PRA (dont on ne sait pas s'ils marchent tant qu'on n'en n'a pas eu besoin), c'est bien pour se prémunir de ces éventualités.

    Depuis tout à l'heure, je lis les tweets en réponses de la communication d'OVH. Et là, on voit que l'informatique, c'est un métier…
    Entre les gens qui se demandent où est le plan de reprise d'activité dans leur espace client, ceux qui demandent s'ils retrouveront les données de leurs serveurs qui sont dans le datacenter 2, ceux qui demandent si OVH ont des backups… Mais la palme, c'est un "founder and CTO" d'une boite qui demande si "OVH ne peut pas switcher d'un datacenter à l'autre". C'est effarant !

    Et je ne parle pas de ceux qui disent d'aller vers un "vrai fournisseur de cloud" (aws par exemple), mais sans dire que bien sur, le backup sera une option payante à part, et que si le gars fait la même connerie, il pourra se retrouver le bec dans l'eau d'une manière ou d'une autre…

    • [^] # Re: Froid dans le dos

      Posté par  (site Web personnel) . Évalué à 4 (+2/-1). Dernière modification le 10/03/21 à 23:51.

      Quand on fait de l'hébergement amateur, on peut à la fois avoir ses propres backups (chez moi l'important est sous git à trois endroits: chez ouam, sur un serveur, sur github) et se demander ce qu'OVH a prévu en cas de souci.

      Moi j'ai un VPS il ne réponds plus, mais je ne sais pas s'il est vraiment mort ou pas, je n'ai pas encore eu de mail votre serveur est cramé, désolé :(

      Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: Froid dans le dos

        Posté par  (site Web personnel) . Évalué à 1 (+6/-7).

        et se demander ce qu'OVH a prévu en cas de souci.

        Euh… Mais c'est écrit dans le contrat : tu seras remboursé des jours d'indispo.
        Le problème ici est qu'une tonne d'admin du dimanche ont pensé qu'OVH avait un engagement de répliquer les données ailleurs dans leur offre de machines (virtuelles ou pas) et qu'ils demandent à OVH leur données. Bref, qu'ils demandent un service qu'il n'ont pas commandé.

        La perte de données, ça arrive tous les jours, d'hab c'est comme des gens en voiture (3000 morts par an en moyenne en France) et donc le peuple s'en fou, hier ça a été comme des gens en avion (30 morts par an en moyenne en France, oui il faut étendre sur plusieurs années vu la rareté des gros crash) et le peuple voit plus gros la perte que ce que c'est en réalité. On a absolument rien à faire de la perte de données, c'était statistiquement prévu et ça devait être géré par tous les admins qui ont perdu une machine.

        Note : ça n’empêche pas de critiquer OVH sur la stupidité et le danger d'un tel incendie (il ne faut pas que ça se reproduise, c'est une question de sécurité des employés et voisins), mais c'est complètement indépendant des admins du dimanche qui pleurent leurs données perdues (les gens ont le service qu'ils ont payé).

        Moi j'ai un VPS il ne réponds plus, mais je ne sais pas s'il est vraiment mort ou pas

        Un VPS, au moins pour les de base (les plus avancés peuvent avoir des snapshots disque ou RAM, mais alors tu le sais déjà vu son prix), n'est pas redondé, il est hébergé sur une unique machine physique (avec un stockage peut-être commun à d'autres, mais ça ne change pas le sujet), la machine physique étant morte je te laisse conclure.

        je n'ai pas encore eu de mail votre serveur est cramé, désolé :(

        Ils ont peut-être d'autres choses à faire que ça, tu as une machine, ça veut dire que tu n'es pas un utilisateur lambda (qu'il faut informer plus, ça je comprend complètement, ils sont utilisateurs, et c'est le rôle de celui qui a la machine si celle-ci n'est pas redondée) mais quelqu'un qui connaît, donc tu es forcément au courant vu le tapage que ta machine est dans un DC qui a merdé. Je ne doute pas qu'ils enverront, quand ils auront réparé ce qui est récupérable (plus urgent qu'un mail d'info), en plus des infos financières (remboursement au prorata, comme stipulé dans le contrat, ceux qui pensent qu'ils vont payer les pertes d'exploitation sont juste des incompétents qui doivent assumer leur conneries devant leur responsable).

        • [^] # Re: Froid dans le dos

          Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

          Le problème ici est qu'une tonne d'admin du dimanche ont pensé qu'OVH avait un engagement de répliquer les données ailleurs dans leur offre de machines (virtuelles ou pas) et qu'ils demandent à OVH leur données. Bref, qu'ils demandent un service qu'il n'ont pas commandé.

          Il faut se méfier aussi d'une chose, c'est que les offres ont évolué. Je l'ai appris à mes dépends avec cet incident. A une époque pas si lointaine (merci Webarchive !), les VPS étaient sauvegardées hebdomadairement par OVH. Attention, il s'agissait de sauvegarde à usage interne à OVH, pas des solutions de backup style snapshot que l'on trouve aujourd'hui.

          Il semblerait que cette sauvegarde hebdomadaire ne soit plus d'actualité (en tout cas, je n'en trouve nulle trace sur leur site aujourd'hui).

          Bon, perso, cela ne m'impacte que peu, car pour un service critique, je prévois des sauvegardes. Mais pour des services non critiques (en l'occurrence, un site vitrine), si j'ai une sauvegarde des données, j'ai la flemme de tout remonter. J'avais pris en compte le backup d'OVH dans mon PRA. Ca peut attendre quelques jours. Donc j'attends ^

          L'enseignement que j'en tire en tout cas, c'est de revoir mon PRA au sujet des VPS !

        • [^] # Re: Froid dans le dos

          Posté par  (site Web personnel) . Évalué à 10 (+8/-1).

          Euh… Mais c'est écrit dans le contrat : tu seras remboursé des jours d'indispo.

          J'ai bossé pour une boite qui avait son propre nuage: le service juridique ne nous a jamais interdit de faire en sorte que ça marche mieux que strictement prévu par Loi et les contrats :-)

          Incubez l'excellence sur https://linuxfr.org/board/

          • [^] # Re: Froid dans le dos

            Posté par  . Évalué à 3 (+4/-0).

            J'ai bossé pour une boite qui avait son propre nuage: le service juridique ne nous a jamais interdit de faire en sorte que ça marche mieux que strictement prévu par Loi et les contrats :-)

            Anéfé, souvent ce sont les services commerciaux et financiers qui t'en empêchent.

        • [^] # Re: Froid dans le dos

          Posté par  . Évalué à 9 (+7/-0).

          Le problème ici est qu'une tonne d'admin du dimanche ont pensé qu'OVH avait un engagement de répliquer les données ailleurs dans leur offre de machines (virtuelles ou pas) et qu'ils demandent à OVH leur données. Bref, qu'ils demandent un service qu'il n'ont pas commandé.

          Strasbourg n'héberge pas que du serveur dédié ou virtuel. C'est aussi leur produit «Dedicated Cloud», et là… c'est pas forcément ce qui est écrit dans le contrat, mais sur la plaquette le discours est très fragile et difficile à défendre.
          Je cite https://www.ovhcloud.com/fr/enterprise/products/hosted-private-cloud/datastores-nfs/ :

          «Snapshots automatiques
          Toutes les heures, un snapshot de votre plateforme est pris automatiquement. Il s'agit d'images instantanées des informations présentes sur votre partition. À tout moment, vous pouvez accéder à ces snapshots et récupérer vos données à un moment précis. À noter que leur volume n'est pas comptabilisé dans votre capacité de stockage utile.»

          «Sauvegardes automatiques
          Afin de vous assurer une continuité de service et éviter la perte de données, nous réalisons des sauvegardes de votre partition sur des supports externes à votre infrastructure. Les informations des 24 dernières heures sont ainsi préservées. Pour pouvoir restaurer une sauvegarde plus ancienne, il est nécessaire d’ouvrir un ticket incident (cette opération vous sera facturée).»

          Avec cette description, il est logique que des entreprises aient fait confiance et n'aient pas d'autre plan de secours. Et selon la façon dont cela se traduit dans les contrats, la situation pourrait être très tendue, pour OVH, leurs clients ou les deux…

          • [^] # Re: Froid dans le dos

            Posté par  (site Web personnel) . Évalué à 7 (+7/-2). Dernière modification le 11/03/21 à 12:56.

            C'est aussi leur produit «Dedicated Cloud»,

            Il y a-t-il des gens qui pleurent la dessus?
            J'ai l'impression de voir que des gens qui pleurent qui ont des dédiés, justement des gens qui n'ont pas payé pour qu'OVH gère la réplication.

            des supports externes à votre infrastructure.

            La, ça peut être limite (si le DC flambe, c'est compris?) mais ce serait clairement plus légitime, j'ose espérer qu'OVH a cet "externe" ailleurs que sur n'importe quel DC SBG.

            Note : à noter que la page que tu cites est claire sur la fonctionnement au quotidien : "situés dans deux baies informatiques différentes", donc à toi de gérer le risque d'indispo (temporaire, cf les sauvegardes que tu cites) en cas de DC qui meure.

            n'aient pas d'autre plan de secours.

            N'empèche, je suis perso impressionné par la quantité d'entreprises qui font confiance à un prestataire unique, j'ai l'impression d'être seul à vouloir 2+ hébergeurs très différents + des backups "froids" encore ailleurs, et ce pour du largement moins critique que les autres qui pluerent. Je paye certes plus cher (les machines un peu, mais surtout l'admin), mais ça me parait normal de sécuriser… suis-je si anormal de considérer mes données comme très importantes à mon business?

            • [^] # Re: Froid dans le dos

              Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

              Il y a-t-il des gens qui pleurent la dessus?

              PCC c’est quand même orienté moyennes et grandes entreprise, ça m’étonne que ces gens râle sur Twitter.

              J'ai l'impression de voir que des gens qui pleurent qui ont des dédiés, justement des gens qui n'ont pas payé pour qu'OVH gère la réplication.

              Quand je travaillais chez mutu c’était pareil, les clients qu’on voyait le plus gueuler c’est ceux qui payaient rien (soit vraiment rien, soit une dizaine d’euro par an).

            • [^] # Re: Froid dans le dos

              Posté par  . Évalué à 7 (+5/-0).

              N'empèche, je suis perso impressionné par la quantité d'entreprises qui font confiance à un prestataire unique, j'ai l'impression d'être seul à vouloir 2+ hébergeurs très différents + des backups "froids" encore ailleurs, et ce pour du largement moins critique que les autres qui pluerent. Je paye certes plus cher (les machines un peu, mais surtout l'admin), mais ça me parait normal de sécuriser… suis-je si anormal de considérer mes données comme très importantes à mon business?

              Tu es anormal, oui. La norme c'est des dirigeants qui ne comprennent pas, et/ou qui préfèrent payer moins mais risquer plus… et la majeure partie du temps, ça passe.

              J'ai été salarié dans 3 boites, la première n'avait même pas de solution de repli fiable en cas de crash d'un serveur de base de données primaire (les réplicats étaient connus pour être corrompus, les sauvegardes étaient une fois par jour et jamais testées), la seconde était réglo (deux hébergeurs, bascule tous les deux ou trois mois…), la troisième dépend d'un unique hébergeur, une unique baie quasiment, avec des sauvegardes à froid ailleurs (et si la baie crame, c'est on ne sait pas combien d'heures pour remonter toute l'infra ailleurs).

          • [^] # Re: Froid dans le dos

            Posté par  . Évalué à 1 (+0/-1).

            Mais est-ce que les gens ayant des datastore nfs ont perdu accès aux backups de ces datastore ?

            • [^] # Re: Froid dans le dos

              Posté par  . Évalué à 2 (+0/-0).

              Mais est-ce que les gens ayant des datastore nfs ont perdu accès aux backups de ces datastore ?

              Le client impacté dont j'ai eu connaissance n'a pas eu de réponse quand il a demandé où étaient ces sauvegardes, indisponibles actuellement…

              • [^] # Re: Froid dans le dos

                Posté par  (site Web personnel) . Évalué à -2 (+0/-4).

                Ils sont en train de faire l'inventaire si j'ai bien compris, ça prend du temps aussi étonnant que cela puisse paraître.

                Designeuse de masques pour sphéniscidés.

        • [^] # Re: Froid dans le dos

          Posté par  . Évalué à 3 (+1/-0).

          Un VPS, au moins pour les de base (les plus avancés peuvent avoir des snapshots disque ou RAM, mais alors tu le sais déjà vu son prix), n'est pas redondé

          J'ai déjà vu des gens stocker les sauvegardes d'une VM sur une autre VM… sur la même machine physique ! :)

          • [^] # Re: Froid dans le dos

            Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

            En sécurité, les mesures que tu prends dépendent de ton modèle de menace, pour les backups c’est pareil, tout dépend de ce dont tu cherches à te protéger.

  • # Réflexions personnelles

    Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

    Je ne suis pas affecté. Mon VPS est hébergé ailleurs, fonctionne toujours très bien et est bien accessible.

    Si j’avais été affecté, j’aurais pu remonter un serveur ailleurs et y restaurer mes sauvegardes en l’espace de quinze minutes. Je le sais, parce que je teste régulièrement mes scripts Ansible de restauration sur une machine virtuelle locale, et c’est grosso modo le temps que ça prend. (Bon, en conditions réelles, ça serait probablement un peu plus long, compte tenu de la nécessité de télécharger les sauvegardes vers la nouvelle machine à travers ma connexion domestique. Mais quand même.)

    En revanche, cet incident m’incite à reconsidérer mon choix (effectué il y a des années) de privilégier un VPS plutôt qu’un serveur dédié. La raison derrière ce choix était que je voulais me décharger autant que possible de tous les problèmes matériels (typiquement une panne de disque dur), mais est-ce réellement important finalement ?

    Si je suis capable de remonter un nouveau serveur from scratch en quinze minutes en cas de force majeure (genre le data center qui part en fumée), ben ça veut dire que je pourrais aussi le faire en cas de problème mineur (genre le disque dur qui rend l’âme), donc quel est l’intérêt d’un VPS pour moi en fin de compte ? Sachant que je n’ai nul besoin de haute disponibilité ou de scalability ?

    Sachant de plus que, chez OVH comme chez quasiment tous les fournisseurs à ma connaissance, pour le prix d’un VPS on a un dédié avec beaucoup plus d’espace disque, et que je commence à me sentir à l’étroit dans les 25 Gio de mon VPS, je me demande sérieusement si le choix du VPS n’a pas été une erreur depuis le début et si je ne vais pas migrer vers un bon vieux serveur physique…

    • [^] # Re: Réflexions personnelles

      Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

      donc quel est l’intérêt d’un VPS pour moi en fin de compte ?

      C'est largement bien plus dispo qu'un dédié (disque, mort au reboot…), c'est moins cher aussi (un dédié avec du SSD à 5 €, vraiment?).
      Par contre le VPS ne survit quand même pas à un incendie…

      Un VPS est un choix qui peut avoir du sens, ça dépend de ce dont tu as besoin et tes priorités.

      • [^] # Re: Réflexions personnelles

        Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

        (un dédié avec du SSD à 5 €, vraiment?)

        Je ne pense pas avoir besoin de stockage SSD. On parle d’un petit serveur pour des besoins perso, là. :) Un petit site web qui doit recevoir trois visites par jour (dont probablement un visiteur qui s’est trompé d’adresse), un petit serveur mail qui reçoit dix mails par jour (dont 9 spams)…

        En terme de dimensionnement, un Kimsufi ou assimilé à 5 ou 7 € me suffirait déjà, et à ce prix j’ai 1 Tio de stockage (non-SSD, certes) contre 25 Gio sur un VPS…

        Pas avec la même disponibilité, on est d’accord. :)

        Un VPS est un choix qui peut avoir du sens, ça dépend de ce dont tu as besoin et tes priorités.

        Justement je ne suis plus sûr que ça corresponde toujours à mes besoins et priorités (peut-être que oui, peut-être que non)… Faut que je réfléchisse un peu plus à ça.

        (Ça tombe bien j’ai le temps de réfléchir, mon VPS est payé jusqu’à l’année prochaine…)

        • [^] # Re: Réflexions personnelles

          Posté par  (site Web personnel) . Évalué à 5 (+4/-1).

          un Kimsufi ou assimilé à 5 ou 7 € me suffirait déjà, et à ce prix j’ai 1 Tio de stockage (non-SSD, certes) contre 25 Gio sur un VPS…

          A même prix
          Tu as du petit rapide (SSD) contre gros lent (HDD)
          Tu as du petit réseau (100 Mbps) contre gros réseau (250 Mbps voire 1 Gbps en pointe)
          Tu as du fiable (99.9%) contre moins fiable (99%)

          Ca confirme mon premier commentaire : ça dépend de tes prios.
          J'ai du VPS en pro (besoin de rapidité stockage et de dispo) et du petit dédié en perso (besoin de place), bref les 2 se valent, c'est juste différent.

          PS : 100 Mbps, c'est moins que beaucoup de clients (fibre…)

  • # Dans mon lycée d’Île de France

    Posté par  (site Web personnel) . Évalué à 10 (+10/-0). Dernière modification le 11/03/21 à 14:35.

    Pour info, notre ENT fourni par la Région était hors d'atteinte toute la journée d'hier. La messagerie a été rétablie en fin d'après-midi et d'autres services sont encore en attente.
    Du coup, malgré cette triste nouvelle, j’étais content d'apprendre que la Région avait placé ses données chez OVH plutôt qu'en dehors de la France !

  • # Octave Klaba explique et s'excuse dans une vidéo

    Posté par  (site Web personnel) . Évalué à -5 (+6/-13).

    Peut-on lui reprocher de ne pas communiquer ? On remarquera qu'il n'a pas pris le temps de lire tous les commentaires de la kyrielle d'experts qui se sont exprimés ici et là en se basant sur des photos non documentées (une source plus sûre qu'un dossier d'architecte, on en conviendra).

    https://www.ovh.com/fr/images/sbg/Octave-Klaba-speaking-fr.mp4

    Designeuse de masques pour sphéniscidés.

    • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

      Posté par  (site Web personnel) . Évalué à 5 (+4/-1).

      On remarquera aussi qu’ils commencent déjà à accuser un prestataire externe.

    • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

      Posté par  (site Web personnel) . Évalué à 9 (+9/-1).

      Tu sais qu'un forum de discussion, c'est fait pour discuter et donner son avis ? Perso, je n'ai vu ici plutôt que des avis argumentés et souvent en disant que ça pouvait aussi être la faute à vraiment pas de bol. De beaucoup de gens qui ont travaillé dans ce métier et qui ont pratiqué les datacenters.

      Et même lui a l'air d'accord pour dire que ce n'est pas tout à fait normal que tout prenne feu comme ça.

      Ta condescendance est un tout petit peu gênante à mon goût. Pas que je me sente spécialement visé.

      • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

        Posté par  (site Web personnel) . Évalué à -6 (+3/-11). Dernière modification le 11/03/21 à 19:29.

        Moi j'ai lu ce genre de commentaires.

        Bref.

        Et donc je revendique aussi le droit de donner mon point de vue (ou bien, ne l'aurais-je pas ?) et d'ironiser sur le réveil des experts.

        Accessoirement, je n'ai pas écrit que c'était normal ce feu. Mais, n'étant pas experte dans le domaine et n'ayant pas d'éléments d'information, je ne peux rien dire de plus.

        Designeuse de masques pour sphéniscidés.

        • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

          Posté par  . Évalué à 7 (+10/-4).

          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.

          • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

            Posté par  . Évalué à 3 (+3/-2).

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

            Heu, ce post, "OVH et la protection incendie" date du lendemain de l'incendie de Strasbourg. C'est quand même être de mauvaise fois que de reprocher au gens de faire le rapprochement !

    • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

      Posté par  . Évalué à 6 (+6/-1). Dernière modification le 11/03/21 à 20:14.

      La vidéo et surtout le son sont aussi cheap que le DC…
      Mais contrairement à Mission Impossible, la vidéo ne s'enflammera pas à la fin.

    • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

      Posté par  (site Web personnel) . Évalué à 4 (+4/-2).

      J'ai craqué au bout d'une minute tellement le son est horrible.
      Même moi en mode urgence je sais faire mieux (appelle-moi "expert en carton" si tu as envie de te cacher la réalité, c'est juste que de nos jours même des gens sans aucune compétence technique font mieux, et l'hébergent à un endroit qui permet d'adapter la qualité vidéo/audio au débit de la connexion du client, pas un pauvre MP4 statique).
      Ca ne va pas aider OVH en réalité, car on voit qu'ils n'ont vraiment aucun plan de gestion de crise pour une structure de cette taille. Low cost, mais quand même (bon, OK, ça ne va pas m’empêcher de continuer chez eux…).

      Aurais-tu la pitié, pour les oreilles de tous les autres, de faire un résumé, toi qui semble connaître le contenu?

      • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

        Posté par  . Évalué à 6 (+4/-0).

        Ce que j'ai retenu :
        - il a l'air de ne pas avoir beaucoup dormi depuis 48 heures ;
        - le caractère improvisé et à l'arrache de la vidéo me donne le sentiment que ce n'est pas de la langue de bois ;
        - les pompiers ont observé le feu avec une caméra thermique et ont vu 2 points plus chauds : 2 onduleurs dont un avait subi une intervention le matin même.

        • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

          Posté par  (site Web personnel) . Évalué à -1 (+2/-5).

          Pareil ! Et vu ce qu'il dit, vu qui il est, ce n'est pas de la pure com' et il ne doit pas être le seul à bosser d'arrache-pied en ce moment.

          Designeuse de masques pour sphéniscidés.

          • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

            Posté par  . Évalué à 4 (+5/-2).

            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.

            • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

              Posté par  . Évalué à 5 (+4/-0).

              La phrase du journal est tellement confuse… J'ai aussi l'intime conviction que parfois, les gens utilisent «à l'instar de» pour dire «contrairement à» alors que ce n'est pas du tout le sens de la locution (le fait qu'elle soit mal orthographiée me appui encore plus cette hypothèse).

              Parce que moi, je comprend que «Au canada, il y a des gicleurs d'eau.À Strasbourg, comme dans la plupart des datacenters du marché, il n'y avait ni gicleurs, ni brumisateur, ni gaz inerte». Ca sous entend que l'abscence de protection incendie, c'est la norme ?

        • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

          Posté par  (site Web personnel) . Évalué à 3 (+5/-4).

          Ca explique la source, mais ça n'explique pas pourquoi le DC a brûlé en entier ("expert en carton", mais je sais que les départs de feu font partie de la vie d'un DC et que dans ce cas la on est sensé perdre au pire le DC pendant quelques jours le temps de remplacer ce qui a commencé à crame mais pas le DC entier à vie)…

          La, on a l'explication "Fukushima s'est prix un gros raz de marée et bam" (merci mais on s'en doutait), mais pas pourquoi le raz de marée a fait que Fukushima a explosé (qui a designé le truc sans prévoir la chose?).

          Bref, on reste sur sa faim donc (et la langue de bois est la : il n'explique pas comment un petit truc a pu devenir si grand).

          • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

            Posté par  (site Web personnel) . Évalué à -6 (+5/-13).

            Je crois qu'à ce stade personne ne peut vraiment savoir (sauf les experts de salon évidemment).

            Designeuse de masques pour sphéniscidés.

          • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

            Posté par  . Évalué à 4 (+3/-1).

            Bref, on reste sur sa faim donc (et la langue de bois est la : il n'explique pas comment un petit truc a pu devenir si grand).

            Je pense qu'il est encore plus impatient que toi de le savoir.

            • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

              Posté par  (site Web personnel) . Évalué à 4 (+7/-5).

              Je suis expert de salon qui imagine qu'il doit bien avoir sa petite idée genre "je n'ai pas voulu signer l'achat du matos qu'on me disait que j'avais besoin en cas d'incendie; faut pas déconner, ça ralenti le déploiement et ça coûte une blinde la sécurité incendie pour si peu d'usage"… Oui, je suis mauvaise langue (aussi mauvaise que sur ceux qui se plaignent d'avoir perdu leur site ou leurs données à cause de ça alors que la faute est plus proche d'eux qu'ils ne veulent l'imaginer :) ).

              • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                Posté par  . Évalué à 10 (+12/-2).

                Tu es mauvaise langue. Si ça se treouve, il a honte de dire que la sécurité a laissé entrer un employé avec son cable firewire.

              • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                Posté par  . Évalué à 5 (+8/-3).

                Je suis expert de salon qui imagine qu'il doit bien avoir sa petite idée genre "je n'ai pas voulu signer l'achat du matos qu'on me disait que j'avais besoin en cas d'incendie; faut pas déconner, ça ralenti le déploiement et ça coûte une blinde la sécurité incendie pour si peu d'usage"…

                Je suis sûr que tu en mettrais ta main au feu …

              • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                Posté par  . Évalué à 3 (+6/-3). Dernière modification le 11/03/21 à 23:46.

                Oui, je suis mauvaise langue (aussi mauvaise que sur ceux qui se plaignent d'avoir perdu leur site ou leurs données à cause de ça alors que la faute est plus proche d'eux qu'ils ne veulent l'imaginer :) ).

                C'est ce qui se passe quand on joue les têtes brûlées (oui, je suis chaud ce soir …).

              • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                Posté par  . Évalué à 8 (+6/-0). Dernière modification le 12/03/21 à 08:53.

                Mon expertise à base de cellulose me dit que sans système incendie aux normes il n'a pas d'assurance. Aurait-il également fait l'impasse sur une assurance ?

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                  Posté par  . Évalué à 5 (+3/-0). Dernière modification le 12/03/21 à 09:26.

                  Tout a fait.

                  Et il me semble que les pompiers aiment bien visiter sur leur temps libre ce genre de bâtiments pour savoir ce qu'ils pourraient y trouver. Et ils donnent leur avis sur les système incendie.

                  Mais bon je suis ni expert en salon ni en cellulose.

                  • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                    Posté par  (site Web personnel) . Évalué à 5 (+7/-4).

                    C'est surtout que, les règles de l'urbanisme imposent que les pompiers donnent leur avis sur ce genre de bâtiment avant la délivrance du permis de construire et ils peuvent exiger des modifications conséquentes sine qua non. J'ai vu ça quand j'ai été commissaire enquêteur, ça fait partie des deux-trois choses que j'ai appris en faisant des enquêtes publiques.

                    Ce bâtiment n'aurait pas eu de permis de construire sans l'aval des pompiers (sauf si les règle sont bien changées depuis). Et effectivement, après, il y a des inspections.

                    Designeuse de masques pour sphéniscidés.

            • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

              Posté par  . Évalué à 4 (+7/-3).

              Je diraios qu'il brûle d'envie de le savoir …

          • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

            Posté par  . Évalué à 9 (+9/-0).

            Pour ma part, à sa place je ne serais pas très fier de moi non plus …

            Ca explique la source, mais ça n'explique pas pourquoi le DC a brûlé en entier

            On ne le saura pas de suite. Je pense qu'à sa place je ne m'avancerais pas trop non plus sans avoir suffisamment d'éléments (surtout aujourd'hui avec les sur-réactions que l'on voit/entend de partout sur les réseaux sociaux). La transparence peut se retourner contre toi.

            "expert en carton", mais je sais que les départs de feu font partie de la vie d'un DC et que dans ce cas la on est sensé perdre au pire le DC pendant quelques jours le temps de remplacer ce qui a commencé à crame mais pas le DC entier à vie)…

            C'est normalement ce qui est fait lorsqu'on, travaille dans "les règles de l'art". La il semble que côté OVH, ils ont voulu se la jouer à la Elon Musk en tentant de révolutionner les datacenters en changeant un certain nombre de choses. Pas de bol, ils ont perdu, et tout un datacenter est cramé. Mais d'un autre côté, personne ne peut dire qu'il ne savait pas (cf le fil https://lafibre.info/ovh-datacenter/ovh-et-la-protection-incendie/ ). Et dans l'échange, j'invite celles et ceux qui se plaignent ici des experts "en carton" d'aller le lire en entier. On y apprend pas mal de choses sur les règles élémentaires de sécurité dans un datacenter. Ces choses sont expliquées par de vrais experts, qui travaillent dans ce domaine, et qui ont dès le début mis en doute la possibilité d'éteindre un feu avant qu'il ne se propage dans tout un DC (Ca se fait, et quand c'est bien fait au pire du pire, tu perds une salle, pas un DC complet). Et pas besoin d'être un expert pour comprendre que là il y a clairement eu une négligence de la part d'OVH sur la prévention des risques et éviter que l'incendie ne se propage. Il suffit d'avoir bossé un peu dans ceux-ci (ce qui est le cas de beaucoup de monde ici) ou d'en avoir visité un avec une personne dont c'est le métier de gérer un datacenter, pour vite comprendre qu'il y a un truc qui va pas dans les datacenters OVH. Pour ma part, je ne suis pas un expert (dans le sens ou ce n'est pas mon métier), mais j'ai assisté/participé à des constructions et déménagements de datacenter, et j'ai passé des nuits parfois à l'interieur de ceux-ci. Et bien souvent quand tu bosses dans ce genre de lieux, on t'explique bien ce qui se passe, les risques incendie, les risques électriques, on te dit surtout que si un incendie se déclare dans une salle il ne faut SURTOUT PAS essayer de l'éteindre, mais il faut sortir de la salle et appeler les pompiers. A l'époque ou je bossais en datacenter, rester dedans en cas d'incendie pouvait être mortel car il y avait du gaz qui se propageait pour tenter de limiter la propagation du feu …

            Après il semble que cette stratégie ait été assumée des le début (cf le tweet ou il dit "s'il y a incendie, tout est mort avant l'eau"). Par contre le fait que personne ne soit blessé montre que les plans d'évacuation étaient bien faits …

            • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

              Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

              "s'il y a incendie, tout est mort avant l'eau"

              Je le lis pas comme ça. C’est Octave et son français un peu cryptique.

              Ce que je comprends c’est : l’eau dans un DC ça fait peut à tout le monde mais c’est psychologique, en vrai, l’incendie détruira tout avant l’eau, donc vaut mieux avoir des sprinkler que rien du tout.

            • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

              Posté par  . Évalué à 0 (+2/-2).

              Par contre le fait que personne ne soit blessé montre que les plans d'évacuation étaient bien faits …

              Ça peut aussi montrer qu'il n'y avait personne sur place ;)

              En regardant un peu l'historique des tickets OVH incident ce soir là, on voit bien que plusieurs dizaines de minutes avant le "big one" il y a eu une multiplication de petits incidents, cause indéterminée, qui avec le recul (je précise parce que surement impossible de voir ça sur le moment) pouvaient laisser présager qu'un truc anormal se passait.

              • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                Posté par  . Évalué à 5 (+5/-0).

                Ça peut aussi montrer qu'il n'y avait personne sur place ;)

                Arrf dommage, il parle justement dans son allocution des personnes qui etaient présentes sur place au moment du départ de feu…

                • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                  Posté par  . Évalué à -1 (+2/-3).

                  Il y a "sur place" (dans le bâtiment / la salle) et "sur place" (sur le site).

                  Dans ce genre de situation les blessés se trouvent surtout parmis les pompiers (la prise de risque est toujours soigneusement calculée, mais ça arrive régulièrement)… tant mieux si aucun n'est à déplorer.

                  • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

                    Posté par  . Évalué à 6 (+6/-0).

                    Il y a "sur place" (dans le bâtiment / la salle) et "sur place" (sur le site).

                    Aaarf dommage, il dit justement dans son allocution que les techniciens sur place etaient dans la salle en quelques secondes après le déclenchement de la première alarme…
                    J'aurais peut etre du retranscrire la vidéo en entier, mea culpa…

            • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

              Posté par  . Évalué à 4 (+4/-1). Dernière modification le 12/03/21 à 17:10.

              "La transparence peut se retourner contre toi."
              Effectivement, c'est un coup à se prendre un retour de flamme … (désolé, je ne sors pas, il n'y a pas le feu)

  • # N'allez pas chez OVH

    Posté par  (site Web personnel) . Évalué à -2 (+7/-10).

    Sans insulter le personnel d'OVH (c.f. plus haut), cela ne m'étonne pas. J'ai déjà eu l'occasion de constater l'amateurisme de certaines pratiques, associées à la condescendance du service client (i.e. « On vous emmerde »).

    Au risque de froisser les patriotes, qui décideraient de supporter une entreprise parce qu'elle est Française, n'hébergez tout simplement pas vos données chez OVH, n'utilisez pas leurs services. Ou alors, juste pour rire un peu.

    Je leur ai confié mes données une fois, elles ont été perdues. Le disque été chiffré avec LUKS, et le technicien qui est intervenu (sans mon aval) pensant qu'il ne contenait pas de données 🤦‍♀️. Cela soulève également le problème d'un technicien ayant accès à mes données, sans consultation.

    Je pense que la compagnie n'est pas sérieuse, qu'il y a un problème d'embauche de personnel qualifié en quantité suffisante. Comme on dit chez nous - et ailleurs - si vous pensez qu'un bon développeur (ou sysadmin) coûte cher, prenez-en un mauvais…

    Juste un conseil, cherchez ailleurs, vous aurez moins cher, et mieux. Je ne connais pas les compagnies Françaises en ce moment, mais il y a des fournisseurs avec des data centres à Paris ou en France. Par exemple Vultr, Linode, etc… En espérant qu'ils n'utilisent pas OVH, bien sûr.

    • [^] # Re: N'allez pas chez OVH

      Posté par  . Évalué à 2 (+0/-0). Dernière modification le 12/03/21 à 08:56.

      cherchez ailleurs, vous aurez moins cher, et mieux

      Ah moi ça m'intéresse ! Tu aurais un exemple ?

      EDIT : ah pardon, j'ai lu trop vite. je vais regarder ça :)

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: N'allez pas chez OVH

      Posté par  (site Web personnel) . Évalué à 10 (+11/-3). Dernière modification le 12/03/21 à 10:10.

      n'hébergez tout simplement pas vos données chez OVH, n'utilisez pas leurs services. Ou alors, juste pour rire un peu.

      Tu caricatures.
      J'ai plusieurs machines chez OVH et globalement ça tourne pas mal (et ça ne lâche pas si souvent). Il faut juste savoir ce qu'on fait et redonder (qu'il faudrait normalement faire dans tous les cas, et quand on le fait finalement qu'un site lâche de temps en temps est un bon motivant pour avoir de bonnes procédures).

      associées à la condescendance du service client (i.e. « On vous emmerde »).

      Des fois les clients sont pas moins condescendants, cf les tweets rageurs "rendez-moi mes données même si je n'ai pas payé pour la redondance".
      On a ce qu'on paye, donc c'est du jetable. Et ce n'est pas horrible, on a le prix qui va avec et on gère.

      Juste un conseil, cherchez ailleurs, vous aurez moins cher, et mieux.

      Pas en France mais pas loin (ping…), mais dans la même gamme de prix je n'ai trouvé que Hetzner en équivalent (=même genre de support, hein, faut pas non plus demander du haut de gamme vu le prix).

      Par exemple Vultr, Linode, etc…

      Pour Linode, ils ont leur propres DC à ma connaissance.
      Mais… C'est du VPS seulement, l'offre reste limitée (même si ils ont bien évolué dernièrement) et chère si tu veux monter en gamme (contre dédié chez OVH).
      C'est seulement une partie de OVH.

      • [^] # Re: N'allez pas chez OVH

        Posté par  (site Web personnel) . Évalué à 0 (+4/-5).

        Tu caricatures.

        Bon, j'avoue que je ne m'étais pas connecté depuis plus d'un an. Il semble qu'ils aient abandonné leur interface web 1.0 en frenglish. Peut être qu'il ont embauché des professionnels, comme il se doit et peut être même qu'ils ont embauché des administrateurs système en quantité suffisante. Même l'authentification en deux facteurs fonctionne du premier coup (c.f. plus loin)

        J'ai plusieurs machines chez OVH et globalement ça tourne pas mal (et ça ne lâche pas si souvent).

        Moi aussi, tout se passait bien de façon générale. Ce n'est que quand il y a un problème qu'on voit si l'entreprise tiens la route.

        La condescendance n'était pas sur le prix ou la redondance des données, mais plutôt un mépris incroyable conte tenu de la boulette qui avait été faite. Je détaille le modus operandi:

        1. Je venais d'activer leur nouvelle authentification à deux facteurs, toute fraîche. À l'époque, c'était du SMS, mais bon, mieux que rien. (tiens, pas de codes de secours)
        2. L'envoi de SMS a fonctionné pendant environ quelques mois, sans souci. Je me connectais tous les mois pour payer l'abonnement, je ne mettais pas mon moyen de paiement bancaire sur leur site. À l'époque, l'interface utilisateur était en pleine migration, assez bancale. De toute façon, je cherchais un autre hébergeur.
        3. 2016, ça commence à se gâter: des coupure intempestives à répétition, un service client injoignable au téléphone et des emails très longs.
        4. Au moment de payer mon abonnement, l'interface de connexion deux facteurs retourne "Erreur 500". Le service client est injoignable, ou on me dit que le problème est en cours de résolution.
        5. Je commence à recevoir des emails, vous n'avez pas payé votre serveur. Ça dure un deux semaines, puis on m'envoie un avis que mon serveur est arrêté.
        6. Quelques jours après, j'arrive finalement à me connecter, mais cette fois un nouveau bug: on ne peut renouveler que pour un an.
        7. Après des échanges avec un centre d'appel à l'autre bout du monde, le bug est corrigé au bout d'environ une semaine et j'arrive enfin à payer mon abonnement pour un mois
        8. Mon serveur n'est plus là. Après moult appels, mon serveur est restauré, mais pas le deuxième disque, chiffré en LUKS, contenant toutes mes données. Je reçois un email m'expliquant qu'un administrateur l'a reprovisionné pour un client différent (huh?). On m'en remet un autre, de même capacité.
        9. Je restaure le backup que j'avais sur AWS, désactive l'authentification en deux facteurs, et commence à lorgner sérieusement sur la concurrence et préparer une migration.
        10. En même temps, je contacte le service client, en envoyant les échanges avec le service technique, courtois. Pas de geste commercial du service client, ni d'excuses, pour deux mois de stress et des données perdues (le backup journalier datait d'une semaine, puisque mon serveur avait été arrêté pendant sept jours.

        Bref, un service médiocre et le mépris total du service client. Je suis parti dès que j'ai pu. Maintenant, je m'autohéberge chez moi avec une adresse IP fixe, et je n'ai plus aucun souci.

        • [^] # Re: N'allez pas chez OVH

          Posté par  (site Web personnel) . Évalué à 5 (+9/-6).

          Maintenant, je m'autohéberge chez moi avec une adresse IP fixe, et je n'ai plus aucun souci.

          C'est bien connu, la dispo chez soit est mieux qu'un DC… Enfin, tant que ça marche, et statistiquement… Vaut mieux pas que la ligne coupe pendant qu'on est en vacances à l'autre bout du monde…

          Cette phrase élimine tout discours critique sur OVH de la personne qui l'écrit.

          • [^] # Re: N'allez pas chez OVH

            Posté par  (site Web personnel) . Évalué à 3 (+4/-2).

            Trois minutes pour lire ma réponse, pas mal.

            J'utilise OpnSense, avec une interface 3G de secours (carte SIM free), et point d'accès VPN.

            Ça marche très bien, je m'en suis déjà servi.

            En cas de coupure, les mails sont re-routes vers un autre serveur SMTP.

            Cette phrase élimine tout discours critique sur OVH de la personne qui l'écrit.

            Je te propose de participer, si ça t'intéresse, au lieu de critiquer ;-) https://github.com/progmaticltd/homebox. On bosse sur la version Bullseye.

            • [^] # Re: N'allez pas chez OVH

              Posté par  . Évalué à 4 (+2/-0).

              En cas d'incendie ?

              • [^] # Re: N'allez pas chez OVH

                Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

                Bonne question.

                J'ai un backup journalier sur AWS S3, avec borgbackup. Je reçois un email et un message par xmpp, journalier. Voici mon message d'aujourd'hui, sur XMPP:

                Backup creation finished successfully for 'local' (duration: 0:02:51)
                

                Et par email:

                Creation status:
                Creating archive at "/mnt/backup/s3/homebox::homebox-{now}"
                ------------------------------------------------------------------------------
                Archive name: homebox-2021-03-15T06:25:03
                Archive fingerprint: 9c9a6e4ace6bcc3814d8306b561d38eb3452867baf39df443d72c0fe2e9624a8
                Time (start): Mon, 2021-03-15 06:25:07
                Time (end):   Mon, 2021-03-15 06:27:25
                Duration: 2 minutes 18.08 seconds
                Number of files: 216417
                Utilization of max. archive size: 0%
                ------------------------------------------------------------------------------
                                       Original size      Compressed size    Deduplicated size
                This archive:               20.11 GB             16.48 GB              8.98 MB
                All archives:              544.95 GB            421.95 GB             17.66 GB
                
                                       Unique chunks         Total chunks
                Chunk index:                  222056              7013940
                ------------------------------------------------------------------------------
                terminating with success status, rc 0
                
                Prune status:
                Keeping archive: homebox-2021-03-15T06:25:03          Mon, 2021-03-15 06:25:07 [9c9a6e4ace6bcc3814d8306b561d38eb3452867baf39df443d72c0fe2e9624a8]
                Keeping archive: homebox-2021-03-14T06:25:03          Sun, 2021-03-14 06:25:09 
                […]
                Keeping archive: homebox-2020-06-30T06:25:03          Tue, 2020-06-30 06:25:09 [d13cb4629204cdbc0fd305458433fba4747cf646c5a582a553a02ba0a66af201]
                Keeping archive: homebox-2020-05-31T06:25:04          Sun, 2020-05-31 06:25:10 [8e4b3fae2085deac8be9565c292f51210ffa5643fb7b88a4823481a5a017d282]
                Keeping archive: homebox-2020-04-30T06:25:04          Thu, 2020-04-30 06:25:11 [0fa0523fcb3e4862e9ff470abeb18831ca1f9eb9a0922617b184102229d6ced8]
                Keeping archive: homebox-2020-03-29T06:25:04          Sun, 2020-03-29 06:25:11 [e6c696859a2d2f8379886a57de37333e5ba56878764d16b10954fd809c01fea5]
                ------------------------------------------------------------------------------
                                       Original size      Compressed size    Deduplicated size
                Deleted data:              -20.07 GB            -16.45 GB             -7.52 MB
                All archives:              524.88 GB            405.50 GB             17.65 GB
                
                                       Unique chunks         Total chunks
                Chunk index:                  221994              6793439
                ------------------------------------------------------------------------------
                terminating with success status, rc 0
                

                Chaque jour, le backup éxécute backup+déduplication. D'où la somme 2 minutes 51 seconds plus haut.

                Le script de déploiement de HomeBox contient un flag, qui restaure automatiquement les données du backup en cas de redéploiement.

                Les fichiers pour redéployer HomeBox sont stockés sur une clé USB (chiffrée avec LUKS).

                Plus d'info ici: https://homebox.readthedocs.io/en/latest/backup-restore/

                En même temps, j'espère que cela n'arrivera pas.

          • [^] # Re: N'allez pas chez OVH

            Posté par  . Évalué à 3 (+2/-0). Dernière modification le 14/03/21 à 18:52.

            Cette phrase élimine tout discours critique sur OVH de la personne qui l'écrit.

            Encore des préjugés …. Tu ne connais pas le besoin et tu te permets de critiquer ? Il y a des cas ou l'auto-hébegement peut suffire (tout comme il y a des cas ou une offre bas de gamme comme OVH peut suffire également). A une certaine poque j'avais des besoins qui pouvaient être couverts par un auto-hébergement + sauvegarde sur autre site. Je ne gérais pas mes mails, et c'était plus des besoins perso (pas forcément besoin de dispo 24/7, et si coupure il y avait lorsque j'étais en vacances - ce qui est arrivé une fois sute à une coupure EDF - je pouvis appeler une persone de confiance qui avait les clés pour remettre en marche l'ensemble du bouzin).

            Maintenant pour un besoin pro, je reverrais certainement ma façon de faire. Mais tout le monde n'a pas des besoins "pro".

            • [^] # Re: N'allez pas chez OVH

              Posté par  (site Web personnel) . Évalué à 4 (+4/-1).

              Il y a des cas ou l'auto-hébegement peut suffire

              Exactement.

              Pour les coupures d'électricité, mon mini serveur est configuré pour démarrer automatiquement. Ce qui est d'ailleurs amusant, parce que le SSD est chiffré avec LUKS, mais un serveur SSH permet de rentrer la phrase de passe à distance. Les paquets Debian qui permettent cette merveille, c'est dropbear-initramfs et cryptsetup-initramfs.

              J'utilise un fournisseur anglais du nom de Pondesk, par exemple ce mini serveur, mais sinon, un vieux portable fait généralement l'affaire, surtout pour les coupures de courant, dont je n'ai pas encore eu l'occasion de souffrir. En regardant de nouveau le fournisseur, je réalise qu'il y a une option mini UPS. Je ne sais ce que ça vaut, mais ça peut être pas mal.

              Quand au fournisseur d'accès, j'utilise Zen, un fournisseur extrêmement stable, sans fioriture, avec adresses IP4 et IP6 fixes. Je suis au Royaume Uni.

              Tu ne connais pas le besoin et tu te permets de critiquer ?

              Il lui aura fallu trois minutes pour lire ma réponse, l'analyser et écrire la sienne. Pour ma part, une telle intelligence et vivacité d'esprit, je suis très impressionné…

              • [^] # Re: N'allez pas chez OVH

                Posté par  . Évalué à 4 (+3/-1).

                Je ne ferai pas confiance à un laptop pour faire tourner des trucs dans mon appartement quand je ne suis pas là. C'est le genre d'appareil hyper intégré et pas testé pour fonctionner 24h/24 qui pourrait te provoquer un incendie.

                Ça peu paraitre parano mais quand je quitte la maison plus de 5 minutes, mon laptop est au minimum en veille et j'évite de le laisser branché sur son chargeur.

                • [^] # Re: N'allez pas chez OVH

                  Posté par  (site Web personnel) . Évalué à 1 (+0/-0). Dernière modification le 15/03/21 à 12:55.

                  C'est vrai que les laptops de maintenant sont plutôt orienté performance. J'avais un laptop Toshiba il y a quelques années, qui a tourné dix ans sans problème.

                  Mais encore une fois, si le micro-pc vu plus haut viens avec un mini-ups, ça peut être pas mal.

                  Bien sûr, j'utilise une prise anti-foudre / anti-surtension, avec une LED qui indique si les fusibles sont encore réactifs.

    • [^] # Re: N'allez pas chez OVH

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

      Ok tu as eu des problèmes avec eux. Ce n'est pas parce que TU as eu des problèmes que les autres en auront.

      Sans indiscrétion, tu avais choisi quoi comme offre ? et comme support ? Parce que bon, vu les tarifs de certaines de leurs offres, faut pas s'attendre à ce qu'ils te déroulent le tapis rouge.

      Je ne veux pas défendre entièrement OVH, parce que c'est vrai, OVH est loin d'être parfait.

      Mais globalement pour nous, dans ma boite, ça fait le job. Plus de 30 serveurs dédiés chez eux (et pas du haut de gamme) et peu de soucis au final. Des fois un disque, une alim ou un une carte qui lâche. C'est réparé en général dans les 2 heures, voire 4h max, sans même souvent qu'on ait à intervenir (et pourtant jusqu'à il y a quelques semaines, depuis 8 ans qu'on est chez eux, on n'avait jamais pris d'option support). Quand on intervient, c'est parce qu'il s'agit d'un disque, et qu'ils nous demandent quand ils peuvent éteindre la machine (elles ont toutes du RAID).

      En 8 ans, ce genre de problème technique est arrivé une dizaine de fois peut être.

      Alors c'est vrai aussi qu'on n'utilise peu de services managés par eux. On fait tout nous même, de la config des OS aux backups en passant par le monitoring. Donc au final on n'est pas confronté à leurs offres "cloud" ou autre, qui ont peut être des soucis.

      Et même expérience satisfaisante pour des bare metals ou VPS, perso, associatifs ou pro chez kimsufi, soyoustart, OVH..

      • [^] # Re: N'allez pas chez OVH

        Posté par  (site Web personnel) . Évalué à 2 (+1/-0).

        Ok tu as eu des problèmes avec eux. Ce n'est pas parce que TU as eu des problèmes que les autres en auront.

        C'est vrai, mais ce n'est pas le problème. Les pratiques d'une société transparaissent en temps de crise, et c'est là le souci. Dans ma description du scénario ci-dessus, plusieurs problèmes - majeurs - sont visibles:

        • Un système de sécurité crucial (authentification à deux facteurs) déployé, mais non stable ou non suffisamment testé.
        • Le manque de personnel disponible pour gérer les problèmes techniques.
        • Des ressources allouées à des nouveaux services alors que ceux déjà en place ne sont pas stables. Si vous avez déjà travaillé dans ce genre de société, vous savez comment ça se passe et vous savez d'où viennent les pressions pour sortir un produit de qualité discutable.
        • Le fait qu'un technicien ait pu regarder le contenu de mon disque sans mon aval. (il y a des normes ou des procédures pour empêcher ça)
        • La négation totale du service client sur la gravité des problèmes survenus.

        Ensuite, je reconnais que c'était en 2016, donc peut être que leurs pratiques on changé. Pour ma part, je préfère donner une chance à d'autres fournisseurs, plus petits, quitte à payer un peu plus.

        Sans indiscrétion, tu avais choisi quoi comme offre ? et comme support ? Parce que bon, vu les tarifs de certaines de leurs offres, faut pas s'attendre à ce qu'ils te déroulent le tapis rouge.

        C'était plusieurs VPS. J'ai essayé un serveur dédié, mais il était sous-utilisé. Je comprends votre avais, même si je ne le partage pas totalement. Je ne suis pas intéressé par un tapis rouge ni des performances époustouflantes. Par contre, j'attends une stabilité certaine, une interface de connexion qui fonctionne correctement et pas de bug dans le moyen de paiement. J'ai eu, pour le même prix, une expérience bien meilleure avec des fournisseurs comme DigitalOcean, Vultr ou Linode.

        Enfin, j'ai toujours été surpris par l'amabilité des services clients, lorsqu'un souci apparaissait ou lorsque j'avais une question.

        Mais globalement pour nous, dans ma boite, ça fait le job

        Là encore, on ne voit la qualité d'une société qu'en cas de crise. Mais globalement, je suis sûr que « ça fait le job».

        La page de certification affiche le logo SOC2-Type2, mais sans aucun détail sur le ou les data centre(s) qui sont certifiés. Est-ce que le datacentre de Strasbourg était certifié ?

        Et même expérience satisfaisante pour des bare metals ou VPS, perso, associatifs ou pro chez kimsufi, soyoustart, OVH..

        Je pense que leur services de ce côté sont sans doute meilleurs.

        Merci du commentaire,

  • # Quelques mails

    Posté par  (site Web personnel) . Évalué à 3 (+2/-1). Dernière modification le 13/03/21 à 06:43.

    Ayant un VPS chez OVH, situé justement à Strasbourg, j'attendais d'en avoir des nouvelles de leur part.

    Hier soir est arrivé un premier mail, dont voici un extrait :

    Si votre VPS est situé dans le datacenter SBG2 (correspondant aux localisations VPS SBG1, SBG2 et SBG4), celui-ci ne pourra pas être remis en service.

    Du coup, la manière dont est organisé leur datacenter à Strasbourg à l'air différente de ce que laissait supposer leurs annonces ici :

    État du datacenter de Strasbourg
    SBG1 : Salle Network est OK - 4 salles détruites - 8 salles OK
    SBG2 : détruite
    SBG3 : PSU éteint - contrôle des serveurs en cours
    SBG4 : Pas d'impact physique

    et plus loin :

    • L’incendie a détruit principalement le datacentre SBG2 et a partiellement endommagé le datacentre SBG1 (4 salles détruites sur 12). Les deux autres datacentres OVHcloud de Strasbourg n’ont pas été touchés par le feu ; les serveurs SBG3 et SBG4 sont pour l’instant éteints mais n’ont pas été impactés.

    et encore plus loin :

    • SBG1 a été partiellement endommagé (4 salles sur 12):
    o Salle réseau – contrôlée hier - ETA du redémarrage : début de semaine prochaine.
    o Réseau électrique - ETA provisoire pour remise en route : lundi 15 mars.
    o Les serveurs seront audités et réactivés un par un.

    • SBG 4 : n’est pas impacté.
    o Un plan de mise en service sera défini pour la fin de cette semaine

    Si on se réfère au mail, contrairement à ce que laissaient entendre leurs annonces ci-dessus, il semblerait que SBG1 et SGB4 soient physiquement situés dans SBG2…

    Pour ceux que ça concerne, voici un autre extrait de ce mail :

    Si votre VPS est situé dans le datacenter SBG3 (correspondant à la localisation VPS SBG6), celui-ci pourra être remis en service à partir du 22 mars prochain.

    Et ce matin, j'ai reçu un autre mail m'indiquant explicitement que (comme je m'en doutais un peu) mon VPS est irrécupérable…

    Le toolkit Atlas, la bibliothèque légère et facile à utilser pour débuter avec la programmation d'interfaces graphiques… (voir 'site Web personnel").

    • [^] # Re: Quelques mails

      Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

      Mail reçu hier aussi pour mon VPS.

      J'en ai reçu un plus spécifique, qui listait précisément mon VPS et qui m'affirmait qu'il était mort.

      J'en ai également reçu un pour mon dédié. Il était en SBG3, donc juste éteint avec la date du 22 mars pour la remise en route prévisionnelle et un dédommagement de 3x le montant payé en février.

      Pour le VPS détruit, le dédommagement s'élève à 6x le montant payé en février.

    • [^] # Re: Quelques mails

      Posté par  (site Web personnel) . Évalué à 3 (+2/-1).

      Du coup, la manière dont est organisé leur datacenter à Strasbourg à l'air différente de ce que laissait supposer leurs annonces ici :

      Il ont surtout fait une communication merdique dans leur mail très confus.
      Ils ont mélangé les localisation openstack avec les localisations physiques.
      Tu as une info plus précise dans leur FAQ sur les localisations, mais il est aussi un peu merdique car ils nomment openstack-sbgX quand l'interface dit os-sbgX.

      Je ne parle même pas de l'image dans le mail du VPS qui semble être d'une ancienne version (du moins pas celle que j'ai, la localisation pour les tous VPS est "SBG" sans numéro, et il faut regarder la ligne "Region OpenStack" dont ils ne parlent pas dans leur mail).

      Ils ont des gros problèmes de cohérence interne et on voit que le cramage d'un DC n'était pas dans leur propre plan de reprise d'activité. Low cost, mais quand même!

      Donc pour corriger leur mail :

      Si votre VPS est situé dans la Region OpenStack os-sbg1, os-sbg2, os-sbg3 ou os-sbg4 (correspondant à la localisation physique SBG2), celui-ci ne pourra pas être remis en service.
      Si votre VPS est situé dans la Region OpenStack os-sbg5 ou os-sbg6 (correspondant à la localisation physique SBG3), celui-ci pourra être remis en service à partir du 22 mars prochain.

      • [^] # Re: Quelques mails

        Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

        Effectivement, le champs Localisation, contrairement à leur copie d'écran montrée en exemple, contient Strasbourg (SBG) - France, donc SBG sans numéro. En outre, entre ce matin est maintenant, le champs Zone (Cluster) est passé de os-sbg1-abc (cluster-xyz), ce qui m'avait laissé penser que mon VPS était situé dans SGB1, donc potentiellement récupérable, à Region OpenStack: os-sbg4 (cluster-xyz), ce qui explique, si on applique les corrections que tu suggères, le second mail m'annonçant que mon VPS est irrécupérable…

        Le toolkit Atlas, la bibliothèque légère et facile à utilser pour débuter avec la programmation d'interfaces graphiques… (voir 'site Web personnel").

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.