Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Vincent Bernat]

 ❦ 17 mars 2021 23:04 +01, Barthélémy DELUY:

> Parce que je suis sysadmin, pas expert en datacenter ni en réseau (merci
> les experts de FRnOG de me sortir chaque jour un peu plus de mon
> inculture), donc je me dis bêtement
> "j'ai un serveur à SBG1, un autre à SBG2, et dans toutes les boîtes
> où j'ai fait de la presta les DC sont physiquement éloignés",
> pas
> "en fait SBG1 et SBG2 c'est le même DC il y a juste une cloison
> entre les deux et aucune mesure de protection classique de datacenter, en
> fait dans toutes les autres boîtes on appellerait ça SBG1-1 et SBG1-2 mais
> ça doit pas être assez vendeur".

Pas forcément. Par exemple, Equinix PA2 et PA3 sont accolés.
-- 
I don't know half of you half as well as I should like; and I like less
than half of you half as well as you deserve.
-- J. R. R. Tolkien


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Vincent Finance via frnog]

Je comprends ta réflexion et tq réqction vis-à-vis de cette notion un
peu floue chez OVH.
J'ai pas encore touché au métier de sysadmin (je fais les démarches
pour me former), mais une chose est sûre de mon point de vue : même si
les DC sont physiquements séparés, je préfèrais prendre deux DC situés
dans deux villes différentes, ne serait-ce que pour être sûr que les
deux soient bien éloignés. Le mieux serait de choisir deux opposés
(genre un en Californie et un à New York si boite US) ou deux régions
assez lointaines, mais pas trop pour éviter les fortes latences (genre
SBG et RBX dans le cas OVH).

Le top du top serait deux sociétés différentes, mais en fonction du
budget, c'est déjà mieux d'avoir deux DC différents !

Le mercredi 17 mars 2021 à 23:04 +0100, Barthélémy DELUY a écrit :
> Pour rajouter mes 2 cents :
> 
> J'ai perdu mon serveur de prod et mon serveur de backup primaire dans
> l'incendie. Heureusement que j'ai un backup secondaire chez un autre
> presta
> dans une autre ville...
> 
> Parce que je suis sysadmin, pas expert en datacenter ni en réseau
> (merci
> les experts de FRnOG de me sortir chaque jour un peu plus de mon
> inculture), donc je me dis bêtement
>     "j'ai un serveur à SBG1, un autre à SBG2, et dans toutes les
> boîtes
> où j'ai fait de la presta les DC sont physiquement éloignés",
> pas
>     "en fait SBG1 et SBG2 c'est le même DC il y a juste une
> cloison
> entre les deux et aucune mesure de protection classique de
> datacenter, en
> fait dans toutes les autres boîtes on appellerait ça SBG1-1 et SBG1-2
> mais
> ça doit pas être assez vendeur".
> 
> La seule info qu'on a de disponible quand on est pas dans les secrets
> des
> dieux, c'est cette page :
> https://www.ovh.com/tn/apropos/technologies/datacenters.xml (d'ailleu
> rs,
> fait amusant, cette page est dispo sur la version US et tunisienne,
> mais
> pas sur la version FR, pour la version FR on tombe sur ça
> https://www.ovhcloud.com/fr/about-us/infrastructure-software/ qui n'a
> RIEN
> à voir).
> 
> On a une belle carte, avec le nombre de DC par villes, mais aucune
> info sur
> leur localisation géographique.
> Comment peut-on savoir, en tant que "petit client", où sont situés
> physiquement les machines ?
> Même sur https://www.datacenters.com/providers/ovh on n'a que le code
> postal (et une adresse fausse pour SBG)...
> 
> Cela signifie-t-il qu'en fait OVH n'a qu'un seul "vrai" DC par ville
> ? Et
> que donc les PRA qui se basent sur "si la machine basée à SBG1 tombe
> en
> panne, on peut repartir sur la machine à SBG3 qui en est une
> réplication
> passive parfaite" sont en fait inutiles ?
> Parce que là un paquet de TPE/PME/freelances vont se retrouver mal, à
> devoir refaire et retester des PRA un peu en urgence parce qu'ils ont
> fait
> confiance à la nomenclature OVH...
> 
> Barth
> 
> 
> Le mer. 17 mars 2021 à 20:37, Mickael Monsieur
> 
> a écrit :
> 
> > 
> > 
> > > Le 17 mars 2021 à 18:33, Stéphane Rivière  a
> > > écrit :
> > > 
> > > 
> > > > 
> > > > Si les prix d'OVH défient toute concurrence, il y a bien une
> > > > raison
> > > 
> > > Certainement !
> > > 
> > > Leur ingénierie est meilleure. Et pas seulement sur le
> > > watercooling et
> > > le freecooling. Il y a aussi l'usine de fabrication de serveurs
> > > (15000m²), les achats groupés en direct, la fibre achetée et non
> > > pas
> > > louée, etc.
> > > 
> > > OVH est, comme toutes ces boites, une machine à cash. Mais ce
> > > cash est
> > > employé pour le dev de la boite, pas pour engraisser des
> > > financiers.
> > > 
> > > Alors il y a (peut-être) eu une boulette sur le choix de ne pas
> > > déporter
> > > les onduleurs à l'extérieur des DC ?
> > > 
> > > Alors je prends le pari qu'il va y avoir de la migration
> > > d'onduleurs
> > > dans les mois/années à venir chez OVH...
> > 
> > Heureusement que tu n’as pas parié en 2017 après le black-out
> > électrique
> > et la promesse du démantèlement des dc containers.
> > 
> > > 
> > > Et OVH sera encore meilleur.
> > > 
> > > PS
> > > 
> > > J'ai des servs arrêtés à SBG, dont un très gros. les clients
> > > n'ont rien
> > > vu. Mais j'ai un retex et des améliorations à faire sur ma
> > > gestion
> > > d'IPFO, puis le changement d'IP de zone DNS en plan B... Ça me
> > > fait un
> > > max de dev là, mais ça vaut le coup...
> > > 
> > > Et j'ai aussi de l'empathie pour les users de SBG1/2... Il y a
> > > des
> > > expériences douloureuses qu'on ne souhaite à personne.
> > > 
> > > --
> > > Be Seeing You
> > > Number Six
> > > 
> > > 
> > > ---
> > > Liste de diffusion du FRnOG
> > > http://www.frnog.org/
> > 
> > 
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> > 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Barthélémy DELUY]

Pour rajouter mes 2 cents :

J'ai perdu mon serveur de prod et mon serveur de backup primaire dans
l'incendie. Heureusement que j'ai un backup secondaire chez un autre presta
dans une autre ville...

Parce que je suis sysadmin, pas expert en datacenter ni en réseau (merci
les experts de FRnOG de me sortir chaque jour un peu plus de mon
inculture), donc je me dis bêtement
"j'ai un serveur à SBG1, un autre à SBG2, et dans toutes les boîtes
où j'ai fait de la presta les DC sont physiquement éloignés",
pas
"en fait SBG1 et SBG2 c'est le même DC il y a juste une cloison
entre les deux et aucune mesure de protection classique de datacenter, en
fait dans toutes les autres boîtes on appellerait ça SBG1-1 et SBG1-2 mais
ça doit pas être assez vendeur".

La seule info qu'on a de disponible quand on est pas dans les secrets des
dieux, c'est cette page :
https://www.ovh.com/tn/apropos/technologies/datacenters.xml (d'ailleurs,
fait amusant, cette page est dispo sur la version US et tunisienne, mais
pas sur la version FR, pour la version FR on tombe sur ça
https://www.ovhcloud.com/fr/about-us/infrastructure-software/ qui n'a RIEN
à voir).

On a une belle carte, avec le nombre de DC par villes, mais aucune info sur
leur localisation géographique.
Comment peut-on savoir, en tant que "petit client", où sont situés
physiquement les machines ?
Même sur https://www.datacenters.com/providers/ovh on n'a que le code
postal (et une adresse fausse pour SBG)...

Cela signifie-t-il qu'en fait OVH n'a qu'un seul "vrai" DC par ville ? Et
que donc les PRA qui se basent sur "si la machine basée à SBG1 tombe en
panne, on peut repartir sur la machine à SBG3 qui en est une réplication
passive parfaite" sont en fait inutiles ?
Parce que là un paquet de TPE/PME/freelances vont se retrouver mal, à
devoir refaire et retester des PRA un peu en urgence parce qu'ils ont fait
confiance à la nomenclature OVH...

Barth


Le mer. 17 mars 2021 à 20:37, Mickael Monsieur 
a écrit :

>
>
> > Le 17 mars 2021 à 18:33, Stéphane Rivière  a écrit :
> >
> > 
> >>
> >> Si les prix d'OVH défient toute concurrence, il y a bien une raison
> >
> > Certainement !
> >
> > Leur ingénierie est meilleure. Et pas seulement sur le watercooling et
> > le freecooling. Il y a aussi l'usine de fabrication de serveurs
> > (15000m²), les achats groupés en direct, la fibre achetée et non pas
> > louée, etc.
> >
> > OVH est, comme toutes ces boites, une machine à cash. Mais ce cash est
> > employé pour le dev de la boite, pas pour engraisser des financiers.
> >
> > Alors il y a (peut-être) eu une boulette sur le choix de ne pas déporter
> > les onduleurs à l'extérieur des DC ?
> >
> > Alors je prends le pari qu'il va y avoir de la migration d'onduleurs
> > dans les mois/années à venir chez OVH...
>
> Heureusement que tu n’as pas parié en 2017 après le black-out électrique
> et la promesse du démantèlement des dc containers.
>
> >
> > Et OVH sera encore meilleur.
> >
> > PS
> >
> > J'ai des servs arrêtés à SBG, dont un très gros. les clients n'ont rien
> > vu. Mais j'ai un retex et des améliorations à faire sur ma gestion
> > d'IPFO, puis le changement d'IP de zone DNS en plan B... Ça me fait un
> > max de dev là, mais ça vaut le coup...
> >
> > Et j'ai aussi de l'empathie pour les users de SBG1/2... Il y a des
> > expériences douloureuses qu'on ne souhaite à personne.
> >
> > --
> > Be Seeing You
> > Number Six
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Mickael Monsieur]

> Le 17 mars 2021 à 18:33, Stéphane Rivière  a écrit :
> 
> 
>> 
>> Si les prix d'OVH défient toute concurrence, il y a bien une raison
> 
> Certainement !
> 
> Leur ingénierie est meilleure. Et pas seulement sur le watercooling et
> le freecooling. Il y a aussi l'usine de fabrication de serveurs
> (15000m²), les achats groupés en direct, la fibre achetée et non pas
> louée, etc.
> 
> OVH est, comme toutes ces boites, une machine à cash. Mais ce cash est
> employé pour le dev de la boite, pas pour engraisser des financiers.
> 
> Alors il y a (peut-être) eu une boulette sur le choix de ne pas déporter
> les onduleurs à l'extérieur des DC ?
> 
> Alors je prends le pari qu'il va y avoir de la migration d'onduleurs
> dans les mois/années à venir chez OVH...

Heureusement que tu n’as pas parié en 2017 après le black-out électrique et la 
promesse du démantèlement des dc containers. 

> 
> Et OVH sera encore meilleur.
> 
> PS
> 
> J'ai des servs arrêtés à SBG, dont un très gros. les clients n'ont rien
> vu. Mais j'ai un retex et des améliorations à faire sur ma gestion
> d'IPFO, puis le changement d'IP de zone DNS en plan B... Ça me fait un
> max de dev là, mais ça vaut le coup...
> 
> Et j'ai aussi de l'empathie pour les users de SBG1/2... Il y a des
> expériences douloureuses qu'on ne souhaite à personne.
> 
> -- 
> Be Seeing You
> Number Six
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Re-my bad…

Sur les photos, SBG1 est moins visible parce que plus petit.
Et SBG2, ça ressemble sacrément à des containers, mais c’est vrai qu’on 
remarque que c’est pas la même taille que les vrais qui sont à côté.

> Le 17 mars 2021 à 20:03, Vincent Tondellier via frnog  a 
> écrit :
> 
> Le Wednesday 17 March 2021 19:34:36 Philippe ASTIER via frnog a écrit :
>> Tout le monde savait que SBG2 était constitué de containers en free
>> cooling. 
> 
> 
> Ettt non ! 
> C'est comme le coup de la triple réplication ceph qui se transforme au fur et 
> a mesure en triple backup, c'est faux.
> 
> SBG1, SBG4 oui c'est des containers maritimes.
> SBG2 c'est (ou c'était) une tour avec patio en water/free cooling, mais en 
> dur, pas en containers.
> SBG3 c'est en dur aussi, mais une autre techno que SBG2.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Hugues Voiturier]

Je dirais 4 chassis minimum, je pense même à plus, mais aucune idée du nombre, 
ce n’est pas précisé. 

> On 17 Mar 2021, at 20:28, Philippe ASTIER  
> wrote:
> 
> Ah yes, my bad, suis pas un spécialiste… J’ai lu trop vite.
> 
> Du coup, il y avait seulement 2 châssis alors pour les 44 fibres ? Ou un truc 
> dans le genre ?
> 
> 
> Schéma très risqué quand même, non ?
> 
> 
> 
> 
> 
> 
>> Le 17 mars 2021 à 20:23, Hugues Voiturier > > a écrit :
>> 
>> 44 transpondeurs ? Non, on parle de châssis WDM, interconnectés entre eux. 
>> 
>> Donc une conf corrompue sur un membre du noeud peut tout corrompre.
>> 
>> Pourquoi avoir tout relié ? Parce que ça simplifie beaucoup le re-routage en 
>> cas de fibercut.
>> 
>> Bref, pas de bol :)
>> 
>>> On 17 Mar 2021, at 20:20, Philippe ASTIER >> > wrote:
>>> 
>>> Ouais. Il y a du détail (merci d’ailleurs !)
>>> 
>>> Mais 44 transpondeurs différents qui perdent leur conf en même temps, c’est 
>>> un sacré drôle de bug.
>>> 
>>> Je lis que la « base de configuration copié2 3 fois sur 2 cartes de 
>>> supervision différentes » a « DISPARU «  ? Pouf… baguette magique.
>>> 
>>> Il manque le détail de l’enquête qui a suivi avec le constructeur.
>>> 
>>> 
>>> Tiens, ça fait d’ailleurs penser à ce qu’on fait dans des domaines 
>>> sensibles (aéronautique, nucléaire, etc…) : ne pas mettre tous ses oeufs 
>>> dans le même panier...
>>> 
 Le 17 mars 2021 à 20:10, Hugues Voiturier >>> > a écrit :
 
> Le blackout de 2017 (je crois) me perturbe plus. 
> Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 
> Gb/s qui coûtent je ne sais pas combien. C’est pas normal, corrigez-loi 
> si je me trompe hein…
 
 Ca a été expliqué ici pourtant :
 
 http://travaux.ovh.net/?do=details=28244 
 
>>> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Ah yes, my bad, suis pas un spécialiste… J’ai lu trop vite.

Du coup, il y avait seulement 2 châssis alors pour les 44 fibres ? Ou un truc 
dans le genre ?


Schéma très risqué quand même, non ?






> Le 17 mars 2021 à 20:23, Hugues Voiturier  a écrit 
> :
> 
> 44 transpondeurs ? Non, on parle de châssis WDM, interconnectés entre eux. 
> 
> Donc une conf corrompue sur un membre du noeud peut tout corrompre.
> 
> Pourquoi avoir tout relié ? Parce que ça simplifie beaucoup le re-routage en 
> cas de fibercut.
> 
> Bref, pas de bol :)
> 
>> On 17 Mar 2021, at 20:20, Philippe ASTIER > > wrote:
>> 
>> Ouais. Il y a du détail (merci d’ailleurs !)
>> 
>> Mais 44 transpondeurs différents qui perdent leur conf en même temps, c’est 
>> un sacré drôle de bug.
>> 
>> Je lis que la « base de configuration copié2 3 fois sur 2 cartes de 
>> supervision différentes » a « DISPARU «  ? Pouf… baguette magique.
>> 
>> Il manque le détail de l’enquête qui a suivi avec le constructeur.
>> 
>> 
>> Tiens, ça fait d’ailleurs penser à ce qu’on fait dans des domaines sensibles 
>> (aéronautique, nucléaire, etc…) : ne pas mettre tous ses oeufs dans le même 
>> panier...
>> 
>>> Le 17 mars 2021 à 20:10, Hugues Voiturier >> > a écrit :
>>> 
 Le blackout de 2017 (je crois) me perturbe plus. 
 Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 Gb/s 
 qui coûtent je ne sais pas combien. C’est pas normal, corrigez-loi si je 
 me trompe hein…
>>> 
>>> Ca a été expliqué ici pourtant :
>>> 
>>> http://travaux.ovh.net/?do=details=28244 
>>> 
>> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Hugues Voiturier]

44 transpondeurs ? Non, on parle de châssis WDM, interconnectés entre eux. 

Donc une conf corrompue sur un membre du noeud peut tout corrompre.

Pourquoi avoir tout relié ? Parce que ça simplifie beaucoup le re-routage en 
cas de fibercut.

Bref, pas de bol :)

> On 17 Mar 2021, at 20:20, Philippe ASTIER  
> wrote:
> 
> Ouais. Il y a du détail (merci d’ailleurs !)
> 
> Mais 44 transpondeurs différents qui perdent leur conf en même temps, c’est 
> un sacré drôle de bug.
> 
> Je lis que la « base de configuration copié2 3 fois sur 2 cartes de 
> supervision différentes » a « DISPARU «  ? Pouf… baguette magique.
> 
> Il manque le détail de l’enquête qui a suivi avec le constructeur.
> 
> 
> Tiens, ça fait d’ailleurs penser à ce qu’on fait dans des domaines sensibles 
> (aéronautique, nucléaire, etc…) : ne pas mettre tous ses oeufs dans le même 
> panier...
> 
>> Le 17 mars 2021 à 20:10, Hugues Voiturier > > a écrit :
>> 
>>> Le blackout de 2017 (je crois) me perturbe plus. 
>>> Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 Gb/s 
>>> qui coûtent je ne sais pas combien. C’est pas normal, corrigez-loi si je me 
>>> trompe hein…
>> 
>> Ca a été expliqué ici pourtant :
>> 
>> http://travaux.ovh.net/?do=details=28244 
>> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Ouais. Il y a du détail (merci d’ailleurs !)

Mais 44 transpondeurs différents qui perdent leur conf en même temps, c’est un 
sacré drôle de bug.

Je lis que la « base de configuration copié2 3 fois sur 2 cartes de supervision 
différentes » a « DISPARU «  ? Pouf… baguette magique.

Il manque le détail de l’enquête qui a suivi avec le constructeur.


Tiens, ça fait d’ailleurs penser à ce qu’on fait dans des domaines sensibles 
(aéronautique, nucléaire, etc…) : ne pas mettre tous ses oeufs dans le même 
panier...

> Le 17 mars 2021 à 20:10, Hugues Voiturier  a écrit 
> :
> 
>> Le blackout de 2017 (je crois) me perturbe plus.
>> Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 Gb/s 
>> qui coûtent je ne sais pas combien. C’est pas normal, corrigez-loi si je me 
>> trompe hein…
> 
> Ca a été expliqué ici pourtant :
> 
> http://travaux.ovh.net/?do=details=28244



signature.asc
Description: Message signed with OpenPGP

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Hugues Voiturier]

> Le blackout de 2017 (je crois) me perturbe plus. 
> Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 Gb/s 
> qui coûtent je ne sais pas combien. C’est pas normal, corrigez-loi si je me 
> trompe hein…

Ca a été expliqué ici pourtant :

http://travaux.ovh.net/?do=details=28244



Bug software 

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Vincent Tondellier via frnog]

Le Wednesday 17 March 2021 19:34:36 Philippe ASTIER via frnog a écrit :
> Tout le monde savait que SBG2 était constitué de containers en free
> cooling. 


Ettt non ! 
C'est comme le coup de la triple réplication ceph qui se transforme au fur et 
a mesure en triple backup, c'est faux.

SBG1, SBG4 oui c'est des containers maritimes.
SBG2 c'est (ou c'était) une tour avec patio en water/free cooling, mais en 
dur, pas en containers.
SBG3 c'est en dur aussi, mais une autre techno que SBG2.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

> Je ne doute pas une seconde qu'il soit affecté et à différents niveaux.
> Je ne doute pas qu'ils vont apporter des améliorations aux DC. Tant mieux.
> Ceci dit, quand il y a eu le blackout réseau chez eux y a pas si
> longtemps, ça semblait impossible... On s'est dit, bon, ça c'est fait,
> on le verra plus jamais. Maintenant, ça..

Le blackout de 2017 (je crois) me perturbe plus.
Je n’ai vu aucune explication sur l’arrêt simultané de 40 modules 100 Gb/s qui 
coûtent je ne sais pas combien. C’est pas normal, corrigez-loi si je me trompe 
hein...

> Non, je ne crois pas. OVH est un acteur parmi d'autres sur un marché
> concurrentiel. S'ils n'étaient pas là on irait voir ailleurs.
> Je souhaite sincèrement qu'ils s'améliorent, mais qu'ils s'améliorent de
> façon proactive.

Tu as essayé de voir ailleurs ?

On ne peut pas tout anticiper.
Mais j’en reviens au PRA, qui doit comporter le plan « site détruit ». Tout le 
monde peut t’aider à traiter ce cas, même OVH.

> J'aurais bien aimé qu'ils aillent au devant des problèmes plutôt qu'on
> les subisse tous (eux et nous, les clients).
> C'est bien de tirer des leçons de ses erreurs, mais ce n'est pas suffisant.

Tous les cas ne se prévoient pas.

Quand tu écris ton plan, tu acceptes certains risques parce que ça finit par 
coûter trop cher.

Chez job-3 comme dirait quelqu’un, on avait un DC historique sur la côte Est, 
pas loin de New York. On se demandait où poser le deuxième DC, et on avait un 
site pas loin de Philadelphie. Cool, c’est loin, non ?
Ah ben oui, mais si jamais toute la côté est coupe (et c’est déjà arrivé) ? On 
gère la prod du groupe pour le monde, ça serait dommage de couper les usines en 
Europe… Parce que avoir ton DC qui tourne sur groupe tout seul alors qu’il n’y 
a plus de réseau...

Du coup, on a regardé pour faire plus loin, genre côté ouest. A l’époque, ça 
nous aurait coûté tellement cher en fibre noire (il y avait du volume), sans 
compter les problèmes de réplication, de latence, je t’en passe, que le 
business nous a dit : bon Philadelphie c’est bien. On a compris, au pire, on 
arrêtera toute la prod plusieurs jours s’il le faut.

Et c’était avant le 11 septembre...

Tant que tu ne sais pas combien te coûte tes pertes d’exploitation, tu ne peux 
pas faire de choix éclairé.


signature.asc
Description: Message signed with OpenPGP

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Richard Klein]

Heureusement pour les vibrations de tremblement de terre il y a des SSD
contrairement aux têtes de HDD qui s'écrasent sur les plateaux en cas d'une
forte secousse.
Autre question que je vous pose ...Déléguer son hébergement et ses serveurs
dans le cloud c'est une  dépendance total auprès d'un prestataire .
Aujourd'hui c'est un onduleur , cela peux aussi êtres un serveur qui lache,
un risque sismique ou une attaque . Dans 99% des cas vous n'aurez pas de
problème et le 1% c'est le cas OVH.
Il y a une trop forte dépendance au service du cloud parce que c'est pas
chère et c'est plus simple de ne pas maintenir vos  propres serveurs et
d'avoir de la redondance .
Nous avons tous vécu ce Big one ,mise en oeuvre du PRA...beaucoup de sueur
et d'énervement.
Il y aura d'autre Big one , comment va réagir mon réveil connecté, comment
mon mobile 5G arrivera à se connecter , comment la Smart City de ma ville
survivra?
Bref c'était mieux avant ! Facile à dire mais l'expérience nous permet
d'apprendre de nos erreurs !

Bonne soirée a tous

Richard


Le mer. 17 mars 2021 à 18:40, Nicolas Parpandet  a écrit :

>
> > comment sont aménagés les DC où ils se trouvent, quels sont les
> > dispositifs anti-feu/inondation/radiations/etc.
>
> Surtout qu'ici c'est une zone sismique, datacenter en carton au bord du
> rhin, ya pas que le feu comme danger ;)
>
> A+
>
> Nicolas
>
> >
> > --
> > Cordialement,
> > Artur
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

> Je suis globalement d'accord avec ton message.

Ouf… de toute façon, je n’espérais pas détroner le frôleur en chef de l’autre 
côté de l’Atlantique :) J’ai renoncé.

> 
> Le 17/03/2021 à 17:57, Philippe ASTIER via frnog a écrit :
>> Je pense qu’OVH a une responsabilité sur l’absence de transparence sur le 
>> service exactement fourni, au moins pour une partie de ses services.
> 
> Ils ont également une responsabilité dans la façon dont ils ont conçu
> leurs propres DC et la sécurité qu'ils ont mis dedans/autour pour
> assurer les services qu'on leur achète.
> Ce n'est quand-même pas au client lambda d'expliquer au professionnel de
> l’hébergement comment il doit concevoir son DC.
> Et d'un autre côté flamber son DC n'a jamais été un standard dans la
> profession. Ça reste des exceptions.

Le problème c’est qu’on présente les Datacenters comme des bunkers 
indestructibles où tous les scenarios du monde sont prévus. 
Ben non. Il y a des tiers-1, 2, 3… avec des contraintes et des sécurités 
différentes, chez tous les opérateurs.

Tout le monde savait que SBG2 était constitué de containers en free cooling. 

Bref, assurer un service, oui. Contre quel niveau de risque, c’est là le flou.


> Pas de problème. Le mien "haut de gamme" payé au prix fort est peut-être
> juste à côté du tien. :)))
> As-t-on réellement l'assurance que quand on paye plus cher, les
> prestations suivent ? Pas sûr.
> Je laisse passer le nuage des fumées et je vais voir si OVH est capable
> d'apporter des précisions sur son organisation interne à un client
> "comme un autre" : où sont réellement les serveurs (surtout les PCI),
> comment sont aménagés les DC où ils se trouvent, quels sont les
> dispositifs anti-feu/inondation/radiations/etc.

Ben tu peux payer plus cher parce que tu as un plus gros serveur sans pour 
autant avoir des backups hors sites, c’est pas choquant en soi.

C’est pas une question de prix, c’est surtout de pouvoir poser la question de 
savoir ce qui est mis en pratique, et d’en accepter (ou pas) le risque.


J’ai mis une semaine à confirmer que mon VPS était sur SBG6 (enfin SBG3, vu que 
SBG6 est en openstack… bref), parce qu’il n’était juste plus listé sur la 
console du tout (en dehors de son IP).
C’est inadmissible. C’est pas une question de prix, j’ai le droit d’exiger de 
savoir où il est. Et si on ne me répond pas…. Ben j’ai le droit de partir, 
c’est la loi du marché.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

[Gregory CAUCHIE]

> Le 17 mars 2021 à 18:14, Radu-Adrian Feurdean 
>  a écrit :
> 
> On Wed, Mar 17, 2021, at 16:07, Gregory CAUCHIE wrote:
>> 
>> Si tu n’as pas d’échange avec eux, ça ne sert à rien de les éviter. 
> 
> NON
> 1 - parce-que c'est une mauvaise pratique. L'internet fonctionne a base de 
> standards respecte par tous les participants, et RFC1918 en fait partie.
> 2 - parce-que "never say never". Tu ne sais jamais de quoi le futur sera fait.

En sortant ainsi la phrase ainsi du contexte, la réaction se comprend.

> Donc encore ine fois, ne *JAMAIS* faire ca sur une nouvelle installation. Sur 
> de l'existant, fait se mettre dans un coin de la tete qu'il faudra normaliser 
> un jour ou autre (sachant que d'habitude plus le temps passe, plus c'est 
> difficile de changer).

on est tous d’accord, ça a été dit et redit, et je me joins à tout cela, je ne 
reviendrais pas encore une fois dessus.

> Et surtout, ne *JAMAIS* dire a quelqu'un (surtout novice ou non technique) 
> que c'est une pratique acceptable. Ca ne l'est *PAS* .

Je ne suis pas le meilleur en sémantique, donc entre recommandable, acceptable, 
etc je n’ai pas d’avis. En revanche, en pur technique, pour les gens qui ont 
déjà déployé de l’IP publique en LAN, la problématique n’est pas sujette à 
débat. Soit tu as des adresses en interne que tu souhaites joindre en externe, 
et là bah le routage IP à plat t’empêche de joindre l’extérieur ; soit tu as 
des en interne des adresses IP publiques que tu n’as pas besoin de joindre en 
externe, et là pas de problème… enfin bien évidemment tant que l’utilisation de 
l’adressage publique comme de tes besoins ne change pas, ce qui n’est 
clairement pas garanti. Ce n’est en tout cas pas une histoire de pays ni de km.


> Le 17 mars 2021 à 18:28, Erwan David  a écrit :
> 
> Et si RFC 1918 ne suffit pas, ne pas oublier que RFC 6598 définis un /10
> d'IP privées (100.64.0.0/10)

La référence qui me semble plus pertinente, et qui inclus les deux RFC 
ci-dessus, est le RFC6890 "Special-Purpose IP Address Registries"   qui est 
plus complète sur ce qui est utilisable, où et comment, en source comme en 
destination, sur réseau publique, privé ou uniquement dans de la documentation.

--
Grégory

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Artur]

Le 17/03/2021 à 18:13, Stéphane Rivière a écrit :
>
> Je crois sincèrement qu'Octave est profondément touché par ce qui est
> arrivé. Avec son caractère, je crois qu'il prendra les mesures
> appropriées. Comme probalement sortir les onduleurs des DC pour les
> traiter comme les GE.

Je ne doute pas une seconde qu'il soit affecté et à différents niveaux.
Je ne doute pas qu'ils vont apporter des améliorations aux DC. Tant mieux.
Ceci dit, quand il y a eu le blackout réseau chez eux y a pas si
longtemps, ça semblait impossible... On s'est dit, bon, ça c'est fait,
on le verra plus jamais. Maintenant, ça...

>> hébergeurs ont des responsabilités envers leurs clients qu'ils doivent
>> assumer, je ne parle même pas de respect qu'on leur doit puisque ce sont
>> eux qui font vivre lesdits hébergeurs.
> Ou inversement.
Non, je ne crois pas. OVH est un acteur parmi d'autres sur un marché
concurrentiel. S'ils n'étaient pas là on irait voir ailleurs.
Je souhaite sincèrement qu'ils s'améliorent, mais qu'ils s'améliorent de
façon proactive.
J'aurais bien aimé qu'ils aillent au devant des problèmes plutôt qu'on
les subisse tous (eux et nous, les clients).
C'est bien de tirer des leçons de ses erreurs, mais ce n'est pas suffisant.

-- 
Cordialement,
Artur


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Nicolas Parpandet]

> comment sont aménagés les DC où ils se trouvent, quels sont les
> dispositifs anti-feu/inondation/radiations/etc.

Surtout qu'ici c'est une zone sismique, datacenter en carton au bord du rhin, 
ya pas que le feu comme danger ;)

A+

Nicolas

> 
> --
> Cordialement,
> Artur
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] stockage batterie

[Stéphane Rivière]

> sur une étagère ou dans une armoire anti feu ?

Tant qu'elle est débranchée, pas de risque...

Si feu dans le local, ça cramera avec le reste. Tout ce qui est lithium
est susceptible à plein de trucs... gros chaud, enfoncement mécanique,
ça peut déclencher une réaction chimique "intéressante"...

-- 
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Artur]

Je suis globalement d'accord avec ton message.

Le 17/03/2021 à 17:57, Philippe ASTIER via frnog a écrit :
> Je pense qu’OVH a une responsabilité sur l’absence de transparence sur le 
> service exactement fourni, au moins pour une partie de ses services.

Ils ont également une responsabilité dans la façon dont ils ont conçu
leurs propres DC et la sécurité qu'ils ont mis dedans/autour pour
assurer les services qu'on leur achète.
Ce n'est quand-même pas au client lambda d'expliquer au professionnel de
l’hébergement comment il doit concevoir son DC.
Et d'un autre côté flamber son DC n'a jamais été un standard dans la
profession. Ça reste des exceptions.

> Maintenant, je veux aussi pouvoir acheter un serveur nu, sans backup, dans 
> une case en carton pâte si c’est facturé le bon prix.

Pas de problème. Le mien "haut de gamme" payé au prix fort est peut-être
juste à côté du tien. :)))
As-t-on réellement l'assurance que quand on paye plus cher, les
prestations suivent ? Pas sûr.
Je laisse passer le nuage des fumées et je vais voir si OVH est capable
d'apporter des précisions sur son organisation interne à un client
"comme un autre" : où sont réellement les serveurs (surtout les PCI),
comment sont aménagés les DC où ils se trouvent, quels sont les
dispositifs anti-feu/inondation/radiations/etc.

-- 
Cordialement,
Artur


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Stéphane Rivière]

> Si les prix d'OVH défient toute concurrence, il y a bien une raison

Certainement !

Leur ingénierie est meilleure. Et pas seulement sur le watercooling et
le freecooling. Il y a aussi l'usine de fabrication de serveurs
(15000m²), les achats groupés en direct, la fibre achetée et non pas
louée, etc.

OVH est, comme toutes ces boites, une machine à cash. Mais ce cash est
employé pour le dev de la boite, pas pour engraisser des financiers.

Alors il y a (peut-être) eu une boulette sur le choix de ne pas déporter
les onduleurs à l'extérieur des DC ?

Alors je prends le pari qu'il va y avoir de la migration d'onduleurs
dans les mois/années à venir chez OVH...

Et OVH sera encore meilleur.

PS

J'ai des servs arrêtés à SBG, dont un très gros. les clients n'ont rien
vu. Mais j'ai un retex et des améliorations à faire sur ma gestion
d'IPFO, puis le changement d'IP de zone DNS en plan B... Ça me fait un
max de dev là, mais ça vaut le coup...

Et j'ai aussi de l'empathie pour les users de SBG1/2... Il y a des
expériences douloureuses qu'on ne souhaite à personne.

-- 
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

[Erwan David]

Le 17/03/2021 à 18:14, Radu-Adrian Feurdean a écrit :
>
> On Wed, Mar 17, 2021, at 16:07, Gregory CAUCHIE wrote:
>> Si tu n’as pas d’échange avec eux, ça ne sert à rien de les éviter. 
> NON
> 1 - parce-que c'est une mauvaise pratique. L'internet fonctionne a base de 
> standards respecte par tous les participants, et RFC1918 en fait partie.
> 2 - parce-que "never say never". Tu ne sais jamais de quoi le futur sera fait.
>
> Donc encore ine fois, ne *JAMAIS* faire ca sur une nouvelle installation. Sur 
> de l'existant, fait se mettre dans un coin de la tete qu'il faudra normaliser 
> un jour ou autre (sachant que d'habitude plus le temps passe, plus c'est 
> difficile de changer).
> Et surtout, ne *JAMAIS* dire a quelqu'un (surtout novice ou non technique) 
> que c'est une pratique acceptable. Ca ne l'est *PAS* .
>
Et si RFC 1918 ne suffit pas, ne pas oublier que RFC 6598 définis un /10
d'IP privées (100.64.0.0/10)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Daniel Caillibaud]

Le 17/03/21 à 17:20, Thomas Pedoussaut  a écrit :
> Le 17/03/2021 à 13:13, Richard DEMONGEOT a écrit :
> > Le snapshot est (selon moi) viable pour des VM avec peu d'écritures 
> > (genre PHP, ) mais pas pour les serveurs de bases de données par 
> > exemple. Ou alors, il faut - dans l'arbo - faire un dump SQL propre 
> > qui lui est snapshot-safe.  
> 
> En MySQL on peut faire un "FLUSH TABLE WITH READ LOCK" pour figer une 
> image disque "safe" afin de faire un snapshot (lvs, zfs, ceph...) puis 
> liberer le lock.

Oui, je fais ça depuis des années (avec du snapshot lvm) et ça marche bien, 
mais j'ai quand
même eu une fois un pb avec des journaux innoDb corrompus, donc pas sûr que ce 
soit
complètement fiable.

À l'époque j'ai pas creusé car le snapshot de la veille me suffisait et que 
j'avais vraiment pas
le temps ce jour là (ok, mauvaise excuse j'aurais dû creuser).

> Les ENT de plusieurs académies francaises sont backupées comme cela, 
> avec une vitesse de reprise sur incident sans commune mesure avec une 
> remontée de backup classique.

Y'a des ENT qui tournent avec mysql ? ;-)

Pas sûr que ce soit un bon exemple, y'a au moins un ENT qui a été HS de longues 
heures après
l'incendie ;-)

Mais quand on en est à remonter les backups, c'est que c'est vraiment une 
grosse cata et qu'on
est pas à qq heures près, pour une reprise sur incident plus courant la 
réplication est quand
même bcp plus efficace.

C'est pas pour la durée de reprise que je fais du backup raw, c'est pour la 
durée du dump et
la conso disque que ça génère (j'en fais quand même, à partir des backup raw 
dans une VM qui
fait que ça, mais moins souvent que les snapshots disque).

-- 
Daniel

Un conducteur dangereux, c'est celui qui vous dépasse
malgré tous vos efforts pour l'en empêcher.
Woody Allen


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Stéphane Rivière]

Le 17/03/2021 à 16:14, David Ponzone a écrit :
> +1
> Mais une presta beaucoup plus chère est-elle vraiment mieux du point de vue 
> de la sécurisation implicite ?

En tout cas, pour avoir tâté (via des audits) à de l'AWS ou de l'Azure,
ils ont aussi leur problèmes... Même leur support est bon, voire très
bon. Azure a planté toutes les DB d'un très grand groupe FR pendant plus
de 6 heures il y a 2/3 ans (je sais plus exactement). Personne n'a rien
dit, c'était du Microsoft :)

Tout dépend de ce qu'on est prêt à payer pour son incompétence.

Prendre du bon dédié chez OVH et faire ce qu'il faut dessus, c'est un
métier. Par contre, ça coûte vraiment moins cher pour un résultat juste
nickel. Mais c'est un métier. Ça rejoint la comparaison de Laurent.

-- 
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

[Radu-Adrian Feurdean]

On Wed, Mar 17, 2021, at 16:07, Gregory CAUCHIE wrote:
> 
> Si tu n’as pas d’échange avec eux, ça ne sert à rien de les éviter. 

NON
1 - parce-que c'est une mauvaise pratique. L'internet fonctionne a base de 
standards respecte par tous les participants, et RFC1918 en fait partie.
2 - parce-que "never say never". Tu ne sais jamais de quoi le futur sera fait.

Donc encore ine fois, ne *JAMAIS* faire ca sur une nouvelle installation. Sur 
de l'existant, fait se mettre dans un coin de la tete qu'il faudra normaliser 
un jour ou autre (sachant que d'habitude plus le temps passe, plus c'est 
difficile de changer).
Et surtout, ne *JAMAIS* dire a quelqu'un (surtout novice ou non technique) que 
c'est une pratique acceptable. Ca ne l'est *PAS* .


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Stéphane Rivière]

> D'ailleurs je ne dois pas avoir tout à fait tort car Oles a bien précisé
> dans ses vidéos qu'ils ont fait des choix discutables et qu'ils doivent
> améliorer des choses pour que ce genre de catastrophes (oui, de mon
> point de vue, ce n'est pas un incident) n'arrive plus ou en tout cas pas
> dans ces dimensions.

Je crois sincèrement qu'Octave est profondément touché par ce qui est
arrivé. Avec son caractère, je crois qu'il prendra les mesures
appropriées. Comme probalement sortir les onduleurs des DC pour les
traiter comme les GE.

> hébergeurs ont des responsabilités envers leurs clients qu'ils doivent
> assumer, je ne parle même pas de respect qu'on leur doit puisque ce sont
> eux qui font vivre lesdits hébergeurs.

Ou inversement.

OVH nous a permis de nous développer. Sans eux, on ramerait plus.

Leur super réseau offert et leurs super dédiés (bons hardwares) pas
chers et leurs IP données et tous les services autour, les NDD pas cher,
les API, le réseau privé qui poutre à 2 Gbps pour pas cher, et
l'internet avec un bon peering à 1 Gbps et 2 Gbps burst...

Alors là un incendie qui détruit le DC, hein... force majeure. y'a des
CGV, on prend un beau jouet, petit ou gros, on peut le casser, pas le
casser, bien ou mal s'en servir, etc. Comme confondre snapshot et
sauvegarde, c'est confondre drive partagé et sauvegarde, être dev et se
croire sysadmin parce qu'on sait installer un LEMP, etc.

J'espère qu'OVH ne se prendra pas du juridique en pleine poire, dans
cette époque de "zounours" et de "maman m'a dit que j'y ai droit".

J'aurais comme un sentiment d'injustice.

-- 
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Arnaud FEIX]

Bonjour,

Moi j’ai l’impression qu’il existe quand même, le RGS, la PSSIE et d’autres 
textes qu’il est bon de connaître et dont il faut demander l’application, 
maintenant il n’y a pas forcément de DSI et RSSI dans toutes les mairies et 
donc oui ces textes ne sont pas forcément appliqués.
De plus il faut aussi savoir qu’une mairie n’est pas un service de l’état, mais 
une collectivité locale.



Envoyé de mon iPhone

> Le 17 mars 2021 à 15:36, Artur  a écrit :
> 
> Le 17/03/2021 à 15:21, Emmanuel Jacquet a écrit :
>>> Le mer. 17 mars 2021 à 14:49, David Ponzone  a
>>> écrit :
>>> 
>>> Par contre, quand c’est des collectivités locales, donc de l’argent
>>> public, c’est un peu plus ennuyeux que l’Etat ne fournisse pas un cahier
>>> des charges de base que doit respecter le prestataire
>> Alors comme on dit aujourd'hui "LOL". En tout cas je n'ai rien vu passer
>> précisément sur ce sujet.
> J'ai lu le contraire dans la presse très récemment en rapport avec cet
> incendie.
> 
> Il semblerait d'après l'article que le cahier de charge de l'Etat
> imposait un backup géographique des services hébergés pour garantir une
> reprise d'activité.
> 
> -- 
> Cordialement,
> Artur
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[David Ponzone]

Je suis d’accord.

J’ai d’ailleurs fait un mail à Equinix pour leur expliquer que j’avais besoin 
de mettre le feu à PA2/PA3 pour valider mon PRA.

Blague à part, certains PRA (en réseau) ne sont pas testables.
Quand ton PRA dépend de fournisseurs et que tu ne sais pas par qui/où ils 
passent, ça devient très délicat.
Si tu demandes, tu as au moins 3 cas:
-certains ne te diront rien (Orange/SFR/…)
-certains sont transparents mais si demain ça change, tu seras pas informé
-certains sont transparents et tu peux à peu près espérer être prévenu en cas 
de changement mais j’y mettrais pas mon PRA à couper

Donc en fait, ton PRA dépend du PRA de tes fournisseurs et de leur transparence.
Ca devient compliqué.

> Le 17 mars 2021 à 18:01, Philippe ASTIER via frnog  a écrit :
> 
> :)
> 
> J’ai oublié un point : un PRA pas testé, c’est comme s’il n’était pas écrit.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

:)

J’ai oublié un point : un PRA pas testé, c’est comme s’il n’était pas écrit.
Un backup qu’on n’a pas essayé de restaurer, c’est comme si on n’en avait pas.

Alors quand on espère qu’avec une case à cocher on est couvert, ben… faut 
changer de métier.

> Le 17 mars 2021 à 17:56, Stéphane Rivière  a écrit :
> 
> 
>> C’est pas un avis à 2 cents en fait. Ca vaut beaucoup plus cher que ça. :)
>> D’autant que j’ai du me mettre à dos la moitié de la liste...
> 
> Mais FRnOG vaut mieux que ça :)))
> 
> Et merci pour ce message.
> 
> -- 
> Be Seeing You
> Number Six
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

Bon, d’abord, je vois que j’ai encore des lecteurs :)

Je pense qu’OVH a une responsabilité sur l’absence de transparence sur le 
service exactement fourni, au moins pour une partie de ses services.

Par exemple, quand on parle d’un triple backup des VPS, je pense qu’il vient 
naturellement à l’esprit de tout le monde que ce n’est pas sur le même site. 

Et on attend tous qu’OVH comprenne ce qui s’est passé, nous l’explique (aussi 
pour nos autres hébergeurs !), et prenne le mesures qu’il faut.

Moi je m’attends surtout à pouvoir savoir où est physiquement chacun des 
services que je paie, ce qui clairement n’était pas le cas.
Si Octave réagit bien, il va rajouter l’option backup hors site avec le coup 
associé d’ailleurs.


Maintenant, je veux aussi pouvoir acheter un serveur nu, sans backup, dans une 
case en carton pâte si c’est facturé le bon prix.

Le problème c’est la facilité du Clickodrome qui fait qu’un trois click et une 
CB on achète un service sans avoir lu le contrat et comprendre ce qu’on a 
acheté. Du coup, monter un service est trop facile. Vous imaginiez vraiment 
qu’à 10€/mois, vous aviez un serveur, de l’électricité, des backups, une 
connexion internet et aussi un bouton « PRA » peut-être ? Faut un peu garder 
les pieds sur terre. J’ai un VPS qui a eu chaud et qui redémarre semaine 
prochaine, mais je savais que je m’exposais à le perde...

Je pense qu’on va passer à la mode legal US : te faire 3 popups pour certifier 
que tu as bien lu le contrat (que bien entendu tu n’auras pas plus lu). Au 
moins, tu auras menti trois fois, et ça sera vraiment ta faute.


> Le 17 mars 2021 à 15:31, Artur  a écrit :
> 
> Salut,
> 
> Le 17/03/2021 à 14:41, Alexandre Archambault a écrit :
>> 
>> Si cet incident peut participer de la prise de conscience qu'il
>> appartient au professionnel d'organiser, le cas échéant en sachant
>> s'entourer de conseil extérieurs - il a tout à fait le droit de ne pas
>> tout maitriser - sa stratégie de sauvegarde, qui commence, en premier
>> lieu, par lire ce qu'il peut signer.
> 
> C'est un paragraphe qui s'adresse à OVH ? ;)
> 
> Je suis d'accord sur le fait que le client qui achète des prestations à
> OVH peut être un pro et savoir ce qu'il achète bien que rien n'a été
> fait pour informer le client sur l'organisation interne des services d'OVH.
> Mais quand je m'adresse à un pro comme OVH (enfin... c'est ce qu'ils
> disent partout), je ne m'attends pas à acheter un service à Mme Michu
> qui a mis un serveur dans une boite en carton avec les bandes de
> sauvegardes posées dessus.
> 
> Si le client peut avoir une part de la responsabilité dans la survie de
> ses données / de son activité dans une situation comme celle-ci, je ne
> dédouane pas du tout OVH de sa part de responsabilité à elle.
> D'ailleurs je ne dois pas avoir tout à fait tort car Oles a bien précisé
> dans ses vidéos qu'ils ont fait des choix discutables et qu'ils doivent
> améliorer des choses pour que ce genre de catastrophes (oui, de mon
> point de vue, ce n'est pas un incident) n'arrive plus ou en tout cas pas
> dans ces dimensions.
> 
> Pour ceux qui se demanderaient, je suis client d'OVH depuis bien
> longtemps à titre personnel et pro. J'ai plusieurs machines au SBG3 qui
> attendent gentiment qu'on veuille bien les rallumer et nos clients n'ont
> aucunement été impactés par le sinistre à SBG.
> Et ma situation ne change rien à mon avis sur cet affaire que j'ai
> brièvement exprimé ci-dessus.
> Sur le plan humain, je compatis, etc. Sur le plan pro, je pardonne rien.
> Et de mon point de vue, comme tout professionnel qui se respecte, les
> hébergeurs ont des responsabilités envers leurs clients qu'ils doivent
> assumer, je ne parle même pas de respect qu'on leur doit puisque ce sont
> eux qui font vivre lesdits hébergeurs.
> 
> -- 
> Cordialement,
> Artur
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Stéphane Rivière]

> C’est pas un avis à 2 cents en fait. Ca vaut beaucoup plus cher que ça. :)
> D’autant que j’ai du me mettre à dos la moitié de la liste...

Mais FRnOG vaut mieux que ça :)))

Et merci pour ce message.

-- 
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Richard DEMONGEOT]

Le 2021-03-17 17:20, Thomas Pedoussaut a écrit :

Le 17/03/2021 à 13:13, Richard DEMONGEOT a écrit :
Le snapshot est (selon moi) viable pour des VM avec peu d'écritures 
(genre PHP, ) mais pas pour les serveurs de bases de données par 
exemple. Ou alors, il faut - dans l'arbo - faire un dump SQL propre 
qui lui est snapshot-safe.



En MySQL on peut faire un "FLUSH TABLE WITH READ LOCK" pour figer une
image disque "safe" afin de faire un snapshot (lvs, zfs, ceph...) puis
liberer le lock.


Oui, c'est une solution aussi :). C'est proche de ce que j'utilise :p. 
Un détail près, je le fait sur un slave dédié au backup, et donc je me 
permet de couper le démon complètement.



Les ENT de plusieurs académies francaises sont backupées comme cela,
avec une vitesse de reprise sur incident sans commune mesure avec une
remontée de backup classique.



L'avantage du démon arrêté, y compris avec le "innodb-fast-shutdown = 0" 
c'est que je n'ai plus les redo logs à rejouer lorsque je restaure le 
backup.

Revers de la médaille:
- tu ne peut pas restaurer une table. (donc mysqldump, reste intéressant 
pour ça);
- Si tu as une corruption binaire (déjà vu :/) , tu la traine dans les 
backups.



Cordialement,


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Thomas Pedoussaut]

Le 17/03/2021 à 13:13, Richard DEMONGEOT a écrit :
Le snapshot est (selon moi) viable pour des VM avec peu d'écritures 
(genre PHP, ) mais pas pour les serveurs de bases de données par 
exemple. Ou alors, il faut - dans l'arbo - faire un dump SQL propre 
qui lui est snapshot-safe.



En MySQL on peut faire un "FLUSH TABLE WITH READ LOCK" pour figer une 
image disque "safe" afin de faire un snapshot (lvs, zfs, ceph...) puis 
liberer le lock.


Les ENT de plusieurs académies francaises sont backupées comme cela, 
avec une vitesse de reprise sur incident sans commune mesure avec une 
remontée de backup classique.



--

Thomas


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Segment Routing

[Gregory CAUCHIE]

Bonjour,

> Le 15 mars 2021 à 15:20, Olivier Eche  a écrit :
> 
> De plus la bascule du monde LDP vers SR se fait plutôt bien en utilisant
> des mapping server.

pourquoi un mapping-server et pas « juste » un changement de preference 
protocole / distance administrative pour ta migration ?
Tu avais des routeurs non SR-capable ? un use-case particulier ?

--
Greg

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

[Gregory CAUCHIE]

> Le 17 mars 2021 à 16:45, David Ponzone  a écrit :
> 
> Faut éviter de prendre des exemples rapides et premier degré ces temps-ci, 
> car ils sont pris comme tel.
> Ma faute.
> 
> C’est très culotté de penser que le client n’aura jamais d’échange avec une 
> IP Google ou AWS.

Idem pour moi (je me rends compte maintenant), l’objectif de mon côté était 
d’insister sur « avec qui tu as besoin de communiquer ».
Et effectivement, une entité qui ne communiquerait pas avec Google Search et 
YouTube ça semble rare. Pour AWS et GCP, à voir en revanche, les parts de 
marchés sont plus réparties, donc possible.

> Par contre un /16 au Vietnam, y a moins de risque.

Moins de risques oui, mais pas de garantie. C’est cette nuance que je voulais 
apporter.

--
Greg

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Daniel via frnog]

Bonjour

Le 17/03/2021 à 16:19, Stephane EVEILLARD a écrit :

[...]

pour un défaut de procédures existantes (Murphy l'a dit, si tu ne testes jamais 
tes groupes électrogènes, ils ne démarreront pas le jour ou tu en auras besoin)

Si les prix d'OVH défient toute concurrence, il y a bien une raison
Faire démarrer un groupe électrogène toutes les semaines et faire des tests de 
bascule plusieurs fois par an, ça a un cout
[...]
Et bien toujours à SBG mais un autre DC d'un autre FAI, celui ci a eu il 
n'y a pas très longtemps un souci électrique et le système de secours 
était en panne. Les tarifs de ce prestataire ne sont de loin pas aussi 
accessibles que ceux d'OVH. Et pourtant ...


--
Daniel


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

[David Ponzone]

Faut éviter de prendre des exemples rapides et premier degré ces temps-ci, car 
ils sont pris comme tel.
Ma faute.

C’est très culotté de penser que le client n’aura jamais d’échange avec une IP 
Google ou AWS.
Par contre un /16 au Vietnam, y a moins de risque.

Si le client a un /16 avec 2000 PC actifs, la renum est un boulot de titan, 
donc il faut faire peser dans la balance le risque s’il n’y a pas renum et le 
prévenir.

> Le 17 mars 2021 à 16:07, Gregory CAUCHIE  a écrit :
> 
> Bonjour,
> 
>> Le 16 mars 2021 à 11:48, David Ponzone  a écrit :
>> 
>> Aucune autre conséquence.
>> Tu peux utiliser du publique comme si c’était du privé, faut juste éviter de 
>> taper dans des IP de Google ou AWS.
> 
> Si tu n’as pas d’échange avec eux, ça ne sert à rien de les éviter. Tout 
> comme le nombre de km n’a de la même manière rien à voir dans l’histoire. La 
> question de base qui doit être posée est : as-tu en interne une IP publique 
> que tu dois pouvoir joindre en externe ? certes le NAT gère le cas du plan de 
> transfert, mais ça ne règle pas le routage interne au LAN !
> 
> Si tu as en interne une adresse publique d’un site web concernant « un truc 
> qui semble pas important et qui est hébergé à l’autre bout de la terre » mais 
> que tu as besoin d'accéder à cette page, bah ton routeur avant le NAT va te 
> router en interne plutôt qu’à la destination à l’autre bout de la terre.
> 
> De la même manière, si tu as en interne des IP publiques d’une grande banque 
> française à côté de chez toi mais que tu n’as jamais à échanger avec elle, 
> alors pas de problème de routage dans ton LAN, tu iras bien vers ta Gateway 
> etc.
> 
> À noter pour info (vu dans une entreprise du CAC40), l’utilisation de proxy 
> Internet au niveau du NAT. Cela « tunnelise » le traffic jusqu’au boîtier 
> NAT, les routeurs « LANs » n’ont pour rôle que de joindre le proxy et les 
> utilisateurs, sans connaissance de l’extérieur. Cela demande de se creuser un 
> peu sur l’archi réseau, rien d’insurmontable, mais niveau exploitation et 
> évolutivité, c’est une autre paire de manche.
> 
> --
> Greg


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [MISC] OVH : SBG-2 en feu

[Stephane EVEILLARD]

Bonjour

Pour avoir personnellement travaillé avec nombre d'entreprises qui veulent la 
Ferrai au prix de la 2 CV je comprends et je partage
Pour avoir été DSI d'une structure certes modeste, mais hébergeur en propre, 
oui le backup, le PRA et toutes les mesures qui permettent
A l'équipe IT de bien dormir ont un prix.
Et non on n'est pas informaticien parce qu'on a déballé la tablette de Tata 
Jeanine et qu'on l'a connectée à la LiveBox

Pour en revenir à OVH ET SBG2, n'oublions pas que ce complexe avait connu en 
2017 de graves problèmes électriques

https://www.numerama.com/business/304644-bfm-business-cozy-cloud-une-importante-panne-chez-ovh-affecte-plusieurs-sites.html

pour un défaut de procédures existantes (Murphy l'a dit, si tu ne testes jamais 
tes groupes électrogènes, ils ne démarreront pas le jour ou tu en auras besoin)

Si les prix d'OVH défient toute concurrence, il y a bien une raison
Faire démarrer un groupe électrogène toutes les semaines et faire des tests de 
bascule plusieurs fois par an, ça a un cout

Pour reprendre l'exemple du Gaz, oui si ca pète c'est d'abord la faute de 
l'installateur, mais si le Gaz est plein de saloperies, on partage les torts 


Cordialement / Best Regards 
  
Stéphane EVEILLARD 





-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Laurent 
GUINCHARD
Envoyé : mercredi 17 mars 2021 16:06
À : frnog-m...@frnog.org
Objet : [FRnOG] [MISC] OVH : SBG-2 en feu

Hello,

> Donc, j'en ai marre qu'on charge OVH parce que certains « pros » ne se sont 
> juste jamais préoccupé de la base de leur métier : savoir où sont leurs 
> données, comment elle sont protégées, et comment faire en cas de sinistre. 
>
>Je suis très curieux de voir les sociétés qui ont utilisé OVH en « clickodrome 
>à pas cher » se défendre que leurs clients finaux vont leur demander où sont 
>passées leurs données. 
>
>
>Après, je suis pas naïf, qu'OVH pousse le marketing à nous faire croire que « 
>tout va bien madame la marquise », ça se discute. Mais si l'infra d'OVH (ou de 
>qui que ce soit d'autre) sert à faire de l'argent, il faut le faire 
>sérieusement, en se posant les questions AVANT que le sinistre se produise, et 
>pas en pleurant après que.. Ah mais ils ne m'ont pas dit ? Ca passe pour du 
>grand public, pas pour du professionnel.
>
>
>C'est pas un avis à 2 cents en fait. Ca vaut beaucoup plus cher que ça. :) 
>D'autant que j'ai du me mettre à dos la moitié de la liste...

+1 à 1000 %
On peut évidemment discuter des problèmes de fond : est ce que le DC 
était bien conçut ou pas ? est ce que les procédures anti-incendie ont été 
suivie ? y'a-t-il eut une fausse manip qui a déclenché le feu ? ... tout ça.

Mais sur le reste, c'est-à-dire le service client qui est délivré :

1 - Le service est généralement proportionnel au prix dans ce domaine. 
Si ça ne vaut vraiment pas cher, généralement c'est que ça ne vaut pas plus.
Donc on en a juste pour son argent ... pas plus.

2 - Dans une infra IT, les protections (sécu, backup, PRA) doivent être 
budgétés en fonction du risque et de l'impact de perdre ces choses.
On ne peut pas budgéter l'achat d'une 2CV et s'offusquer qu'elle 
n'aille pas aussi vite qu'une Ferrari après coup.
Si le business de mon entreprise ne tient que part le SI installé 
quelque part, alors je dois mettre les ressources et moyens nécessaire pour 
faire en sorte que même en cas de catastrophe ma boite puisse continuer de 
fonctionner.

3 - Ces sujets doivent être dans les mains de professionnels du 
secteur. Ne pas vouloir faire appel à des professionnels délibérément condamne 
par avance tout reproche à venir.
Si je veux une modif de la desserte en gaz à la maison, je ne le fais 
pas moi-même, j'appelle un spécialiste parce que je n'en suis pas un.
Si je le fais quand même et que çà me pète à la tronche, c'est ma 
responsabilité qui est engagé, pas celle du fournisseur de GAZ.

Cordialement.

Laurent GUINCHARD

---
Liste de diffusion du FRnOG
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=04%7C01%7C%7Cbdbd5518a97a45a6a67508d8e9568f5c%7C84df9e7fe9f640afb435%7C1%7C0%7C637515905259555171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0%2FvcMoSlQ0xukD%2FJIYzsLIrWO%2BBN37MvuZQ2pOVuns8%3Dreserved=0


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[David Ponzone]

+1
Mais une presta beaucoup plus chère est-elle vraiment mieux du point de vue de 
la sécurisation implicite ?
C’est quoi le niveau d’engagement d’Azure avec leur VM de base si le DC brûle ?

La seule différence, c’est probablement la taille des clients, dont le sérieux 
du prestataire entre les 2 qui va pas jouer à ne pas avoir de sauvegarde 
off-site.

> Le 17 mars 2021 à 16:05, Laurent GUINCHARD  a 
> écrit :
> +1 à 1000 %
>   On peut évidemment discuter des problèmes de fond : est ce que le DC 
> était bien conçut ou pas ? est ce que les procédures anti-incendie ont été 
> suivie ? y'a-t-il eut une fausse manip qui a déclenché le feu ? ... tout ça.
> 
>   Mais sur le reste, c’est-à-dire le service client qui est délivré :
> 
>   1 - Le service est généralement proportionnel au prix dans ce domaine. 
> Si ça ne vaut vraiment pas cher, généralement c'est que ça ne vaut pas plus.
>   Donc on en a juste pour son argent ... pas plus.
> 
>   2 - Dans une infra IT, les protections (sécu, backup, PRA) doivent être 
> budgétés en fonction du risque et de l'impact de perdre ces choses.
>   On ne peut pas budgéter l'achat d'une 2CV et s'offusquer qu'elle 
> n'aille pas aussi vite qu'une Ferrari après coup.
>   Si le business de mon entreprise ne tient que part le SI installé 
> quelque part, alors je dois mettre les ressources et moyens nécessaire pour 
> faire en sorte que même en cas de catastrophe ma boite puisse continuer de 
> fonctionner.
> 
>   3 - Ces sujets doivent être dans les mains de professionnels du 
> secteur. Ne pas vouloir faire appel à des professionnels délibérément 
> condamne par avance tout reproche à venir.
>   Si je veux une modif de la desserte en gaz à la maison, je ne le fais 
> pas moi-même, j'appelle un spécialiste parce que je n'en suis pas un.
>   Si je le fais quand même et que çà me pète à la tronche, c'est ma 
> responsabilité qui est engagé, pas celle du fournisseur de GAZ.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Subnet ip publique sur LAN

[Gregory CAUCHIE]

Bonjour,

> Le 16 mars 2021 à 11:48, David Ponzone  a écrit :
> 
> Aucune autre conséquence.
> Tu peux utiliser du publique comme si c’était du privé, faut juste éviter de 
> taper dans des IP de Google ou AWS.

Si tu n’as pas d’échange avec eux, ça ne sert à rien de les éviter. Tout comme 
le nombre de km n’a de la même manière rien à voir dans l’histoire. La question 
de base qui doit être posée est : as-tu en interne une IP publique que tu dois 
pouvoir joindre en externe ? certes le NAT gère le cas du plan de transfert, 
mais ça ne règle pas le routage interne au LAN !

Si tu as en interne une adresse publique d’un site web concernant « un truc qui 
semble pas important et qui est hébergé à l’autre bout de la terre » mais que 
tu as besoin d'accéder à cette page, bah ton routeur avant le NAT va te router 
en interne plutôt qu’à la destination à l’autre bout de la terre.

De la même manière, si tu as en interne des IP publiques d’une grande banque 
française à côté de chez toi mais que tu n’as jamais à échanger avec elle, 
alors pas de problème de routage dans ton LAN, tu iras bien vers ta Gateway etc.

À noter pour info (vu dans une entreprise du CAC40), l’utilisation de proxy 
Internet au niveau du NAT. Cela « tunnelise » le traffic jusqu’au boîtier NAT, 
les routeurs « LANs » n’ont pour rôle que de joindre le proxy et les 
utilisateurs, sans connaissance de l’extérieur. Cela demande de se creuser un 
peu sur l’archi réseau, rien d’insurmontable, mais niveau exploitation et 
évolutivité, c’est une autre paire de manche.

--
Greg

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] OVH : SBG-2 en feu

[Laurent GUINCHARD]

Hello,

> Donc, j’en ai marre qu’on charge OVH parce que certains « pros » ne se sont 
> juste jamais préoccupé de la base de leur métier : savoir où sont leurs 
> données, comment elle sont protégées, et comment faire en cas de sinistre. 
>
>Je suis très curieux de voir les sociétés qui ont utilisé OVH en « clickodrome 
>à pas cher » se défendre que leurs clients finaux vont leur demander où sont 
>passées leurs données. 
>
>
>Après, je suis pas naïf, qu’OVH pousse le marketing à nous faire croire que « 
>tout va bien madame la marquise », ça se discute. Mais si l’infra d’OVH (ou de 
>qui que ce soit d’autre) sert à faire de l’argent, il faut le faire 
>sérieusement, en se posant les questions AVANT que le sinistre se produise, et 
>pas en pleurant après que…. Ah mais ils ne m’ont pas dit ? Ca passe pour du 
>grand public, pas pour du professionnel.
>
>
>C’est pas un avis à 2 cents en fait. Ca vaut beaucoup plus cher que ça. :) 
>D’autant que j’ai du me mettre à dos la moitié de la liste...

+1 à 1000 %
On peut évidemment discuter des problèmes de fond : est ce que le DC 
était bien conçut ou pas ? est ce que les procédures anti-incendie ont été 
suivie ? y'a-t-il eut une fausse manip qui a déclenché le feu ? ... tout ça.

Mais sur le reste, c’est-à-dire le service client qui est délivré :

1 - Le service est généralement proportionnel au prix dans ce domaine. 
Si ça ne vaut vraiment pas cher, généralement c'est que ça ne vaut pas plus.
Donc on en a juste pour son argent ... pas plus.

2 - Dans une infra IT, les protections (sécu, backup, PRA) doivent être 
budgétés en fonction du risque et de l'impact de perdre ces choses.
On ne peut pas budgéter l'achat d'une 2CV et s'offusquer qu'elle 
n'aille pas aussi vite qu'une Ferrari après coup.
Si le business de mon entreprise ne tient que part le SI installé 
quelque part, alors je dois mettre les ressources et moyens nécessaire pour 
faire en sorte que même en cas de catastrophe ma boite puisse continuer de 
fonctionner.

3 - Ces sujets doivent être dans les mains de professionnels du 
secteur. Ne pas vouloir faire appel à des professionnels délibérément condamne 
par avance tout reproche à venir.
Si je veux une modif de la desserte en gaz à la maison, je ne le fais 
pas moi-même, j'appelle un spécialiste parce que je n'en suis pas un.
Si je le fais quand même et que çà me pète à la tronche, c'est ma 
responsabilité qui est engagé, pas celle du fournisseur de GAZ.

Cordialement.

Laurent GUINCHARD

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Artur]

Le 17/03/2021 à 15:42, David Ponzone a écrit :
> Mais là tu parles de l’Etat en tant que client, comme data.gouv.fr 
> .
Oui, c'est exact.
> Moi je parle des milliers de sites pour les mairies et autres, dont l’Etat se 
> décharge (ce qui est normal ou pas, c’est un autre débat) mais sans un 
> minimum d’accompagnement/recommendations.
> Je suis peut-être un utopiste mais ça semble un peu délirant.
> La Mairie de base, qui n’a pas de service informatique en propre, va bosser 
> avec le frère du gendre de l’éleveur qui a vendu son caniche au Maire, parce 
> qu’il s’y connait, et ça finit chez OVH sans backup. Et le mec qui a fait le 
> site a disparu.

Qui faut-il blâmer ? Je suppose que le Maire qui souhaite obtenir un
soutien de la part de (mettre ici un service de l'Etat/un pro) pour
savoir comment gérer ses services techniques (pas uniquement
l'informatique) le trouvera (plus ou moins) facilement.
Mais si il préfère faire du clientélisme primaire, autant l'aider avec
un vote à faire un autre métier lors des prochaines élections. Non ?

J'ai des témoignages d'un ami pro qui s'arrache parfois les cheveux en
essayant de faire son métier auprès de certaines collectivités parce que
les personnes nommées/recrutées pour s'occuper des services techniques
ne sont clairement pas compétentes.

>> Le 17 mars 2021 à 15:34, Artur  a écrit :
>>
>> Le 17/03/2021 à 15:21, Emmanuel Jacquet a écrit :
>>> Le mer. 17 mars 2021 à 14:49, David Ponzone  a
>>> écrit :
>>>
 Par contre, quand c’est des collectivités locales, donc de l’argent
 public, c’est un peu plus ennuyeux que l’Etat ne fournisse pas un cahier
 des charges de base que doit respecter le prestataire
>>> Alors comme on dit aujourd'hui "LOL". En tout cas je n'ai rien vu passer
>>> précisément sur ce sujet.
>> J'ai lu le contraire dans la presse très récemment en rapport avec cet
>> incendie.
>>
>> Il semblerait d'après l'article que le cahier de charge de l'Etat
>> imposait un backup géographique des services hébergés pour garantir une
>> reprise d'activité.

-- 
Cordialement,
Artur


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Vincent Tondellier via frnog]

On mercredi 17 mars 2021 14:42:07 CET, Daniel Caillibaud wrote:

Le 17/03/21 à 13:12, Philippe ASTIER via frnog  a écrit :
Donc, je ne reste pas d’accord, OVH ne fait pas de « merde en 
boite », et permet d’avoir le
niveau de sauvegarde qu’on l’on veut en fonction des risques 
dont ont veut se protéger, au

prix que l’on accepte de payer.


Apparemment le pb c'est surtout pour ceux qui avaient pris 
l'option backup automatique fait par
ovh avec triple réplication, qui payaient pour ça leur vps le 
double, et qui ont perdu
toutes leurs données quand même (je retrouve plus la page de 
description qui parlait de triple réplication sans dire où).


Triple réplication ca veut juste dire : le disque est sur un cluster ceph, 
donc répliqué 3 fois (ce qui ne veut pas dire sur 3 disques / machines, 
mais bien plus vu le fonctionnement de ceph).

Les snapshots pareil, c'est des snapshots ceph, donc sur le même cluster.

Les seuls backups contractuels perdus que j'ai vu sont les backups veeam du 
private cloud, mais je ne crois pas qu'ils soient vendus "triple 
réplication".


Sinon +1 également sur les 2 cents.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[David Ponzone]

Mais là tu parles de l’Etat en tant que client, comme data.gouv.fr 
.

Moi je parle des milliers de sites pour les mairies et autres, dont l’Etat se 
décharge (ce qui est normal ou pas, c’est un autre débat) mais sans un minimum 
d’accompagnement/recommendations.
Je suis peut-être un utopiste mais ça semble un peu délirant.
La Mairie de base, qui n’a pas de service informatique en propre, va bosser 
avec le frère du gendre de l’éleveur qui a vendu son caniche au Maire, parce 
qu’il s’y connait, et ça finit chez OVH sans backup. Et le mec qui a fait le 
site a disparu.

> Le 17 mars 2021 à 15:34, Artur  a écrit :
> 
> Le 17/03/2021 à 15:21, Emmanuel Jacquet a écrit :
>> Le mer. 17 mars 2021 à 14:49, David Ponzone  a
>> écrit :
>> 
>>> Par contre, quand c’est des collectivités locales, donc de l’argent
>>> public, c’est un peu plus ennuyeux que l’Etat ne fournisse pas un cahier
>>> des charges de base que doit respecter le prestataire
>> Alors comme on dit aujourd'hui "LOL". En tout cas je n'ai rien vu passer
>> précisément sur ce sujet.
> J'ai lu le contraire dans la presse très récemment en rapport avec cet
> incendie.
> 
> Il semblerait d'après l'article que le cahier de charge de l'Etat
> imposait un backup géographique des services hébergés pour garantir une
> reprise d'activité.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Artur]

Le 17/03/2021 à 15:21, Emmanuel Jacquet a écrit :
> Le mer. 17 mars 2021 à 14:49, David Ponzone  a
> écrit :
>
>> Par contre, quand c’est des collectivités locales, donc de l’argent
>> public, c’est un peu plus ennuyeux que l’Etat ne fournisse pas un cahier
>> des charges de base que doit respecter le prestataire
> Alors comme on dit aujourd'hui "LOL". En tout cas je n'ai rien vu passer
> précisément sur ce sujet.
J'ai lu le contraire dans la presse très récemment en rapport avec cet
incendie.

Il semblerait d'après l'article que le cahier de charge de l'Etat
imposait un backup géographique des services hébergés pour garantir une
reprise d'activité.

-- 
Cordialement,
Artur


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Artur]

Salut,

Le 17/03/2021 à 14:41, Alexandre Archambault a écrit :
>
> Si cet incident peut participer de la prise de conscience qu'il
> appartient au professionnel d'organiser, le cas échéant en sachant
> s'entourer de conseil extérieurs - il a tout à fait le droit de ne pas
> tout maitriser - sa stratégie de sauvegarde, qui commence, en premier
> lieu, par lire ce qu'il peut signer.

C'est un paragraphe qui s'adresse à OVH ? ;)

Je suis d'accord sur le fait que le client qui achète des prestations à
OVH peut être un pro et savoir ce qu'il achète bien que rien n'a été
fait pour informer le client sur l'organisation interne des services d'OVH.
Mais quand je m'adresse à un pro comme OVH (enfin... c'est ce qu'ils
disent partout), je ne m'attends pas à acheter un service à Mme Michu
qui a mis un serveur dans une boite en carton avec les bandes de
sauvegardes posées dessus.

Si le client peut avoir une part de la responsabilité dans la survie de
ses données / de son activité dans une situation comme celle-ci, je ne
dédouane pas du tout OVH de sa part de responsabilité à elle.
D'ailleurs je ne dois pas avoir tout à fait tort car Oles a bien précisé
dans ses vidéos qu'ils ont fait des choix discutables et qu'ils doivent
améliorer des choses pour que ce genre de catastrophes (oui, de mon
point de vue, ce n'est pas un incident) n'arrive plus ou en tout cas pas
dans ces dimensions.

Pour ceux qui se demanderaient, je suis client d'OVH depuis bien
longtemps à titre personnel et pro. J'ai plusieurs machines au SBG3 qui
attendent gentiment qu'on veuille bien les rallumer et nos clients n'ont
aucunement été impactés par le sinistre à SBG.
Et ma situation ne change rien à mon avis sur cet affaire que j'ai
brièvement exprimé ci-dessus.
Sur le plan humain, je compatis, etc. Sur le plan pro, je pardonne rien.
Et de mon point de vue, comme tout professionnel qui se respecte, les
hébergeurs ont des responsabilités envers leurs clients qu'ils doivent
assumer, je ne parle même pas de respect qu'on leur doit puisque ce sont
eux qui font vivre lesdits hébergeurs.

-- 
Cordialement,
Artur


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Emmanuel Jacquet]

Le mer. 17 mars 2021 à 14:49, David Ponzone  a
écrit :

> Par contre, quand c’est des collectivités locales, donc de l’argent
> public, c’est un peu plus ennuyeux que l’Etat ne fournisse pas un cahier
> des charges de base que doit respecter le prestataire



Alors comme on dit aujourd'hui "LOL". En tout cas je n'ai rien vu passer
précisément sur ce sujet.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [MISC] stockage batterie

[Jerome Lien]

Bonjour à tous,

une question de curiosité, qui n'a aucun rapport avec l'actualité ;-)
comment stockez vous les batteries en stock ? batterie d'ordinateur
portable, de périphérique mobile, scanner, dect, d'onduleur ...

sur une étagère ou dans une armoire anti feu ?

merci à tous, Jérôme

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[David Ponzone]

+1 à tout ce qui a été dit avant.

Personnellement, je me fous un peu des choix de la TPE de 3 personnes qui veut 
dépenser max 10€/mois pour son site web, et qui de toute façon ne ressent pas 
d’impact notable sur son CA si le site est down pendant 1 semaine.
Par contre, quand c’est des collectivités locales, donc de l’argent public, 
c’est un peu plus ennuyeux que l’Etat ne fournisse pas un cahier des charges de 
base que doit respecter le prestataire. On sait tous que ce genre de projet 
tombe largement sous le seuil de l’AOP, mais c’est pas une raison pour faire 
n’importe quoi.

> Le 17 mars 2021 à 14:41, Alexandre Archambault  a écrit :
> 
> #NousSommesLegion.
> 
> Si cet incident peut participer de la prise de conscience qu'il
> appartient au professionnel d'organiser, le cas échéant en sachant
> s'entourer de conseil extérieurs - il a tout à fait le droit de ne pas
> tout maitriser - sa stratégie de sauvegarde, qui commence, en premier
> lieu, par lire ce qu'il peut signer.
> 
> Le "c'est pas mon problème, c'est celui de mon prestataire, le client
> est roi", vous oubliez tout de suite. Ca marche peut être ici, mais
> devant un vrai juge, c'est inopérant quand c'est entre professionnels.
> 
> Voilà une bonne idée d'intervention pour
> FrnOG-quand-ça-sera-possible-de-nouveau "Maitre, vous allez encore
> râler, on a signé un truc sans vous en parler"
> 
> En attendant, quelques pistes ici =>
> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Daniel Caillibaud]

Le 17/03/21 à 13:12, Philippe ASTIER via frnog  a écrit :
> Donc, je ne reste pas d’accord, OVH ne fait pas de « merde en boite », et 
> permet d’avoir le
> niveau de sauvegarde qu’on l’on veut en fonction des risques dont ont veut se 
> protéger, au
> prix que l’on accepte de payer.

Apparemment le pb c'est surtout pour ceux qui avaient pris l'option backup 
automatique fait par
ovh avec triple réplication, qui payaient pour ça leur vps le double, et qui 
ont perdu
toutes leurs données quand même (je retrouve plus la page de description qui 
parlait de triple
réplication sans dire où).

Ensuite, ceux qui râlent parce qu'ovh ne faisaient pas le backup de leur dédié, 
no comment… 
Ça va p'tet faire un peu de ménage dans la profession ;-)

-- 
Daniel

Un pigeon, c'est plus con qu'un dauphin, d'accord... mais ça vole. 
Michel Audiard


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Alexandre Archambault]

Le 17/03/2021 à 14:06, Laurent Barme a écrit :
>> D’autant que j’ai du me mettre à dos la moitié de la liste...
>>
>>
> Je fais partie de l'autre moitié -)

#NousSommesLegion.

Si cet incident peut participer de la prise de conscience qu'il
appartient au professionnel d'organiser, le cas échéant en sachant
s'entourer de conseil extérieurs - il a tout à fait le droit de ne pas
tout maitriser - sa stratégie de sauvegarde, qui commence, en premier
lieu, par lire ce qu'il peut signer.

Le "c'est pas mon problème, c'est celui de mon prestataire, le client
est roi", vous oubliez tout de suite. Ca marche peut être ici, mais
devant un vrai juge, c'est inopérant quand c'est entre professionnels.

Voilà une bonne idée d'intervention pour
FrnOG-quand-ça-sera-possible-de-nouveau "Maitre, vous allez encore
râler, on a signé un truc sans vous en parler"

En attendant, quelques pistes ici =>



-- 
Alec,


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [MISC] OVH : SBG-2 en feu

[Oliver varenne]

Un bon backup, c'est un backup en double (au moins) et à deux endroits 
différents.



Cordialement,
 


Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 




> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Vincent Duvernet
> Envoyé : mercredi 17 mars 2021 12:42
> À : frnog@frnog.org
> Objet : RE: [FRnOG] [MISC] OVH : SBG-2 en feu
> 
> Glop, glop,
> 
> Au final, comme beaucoup d'autres sur la liste, nous allons devoir
> repenser certains aspects techniques.
> 
> Parce que prendre l'option payante pour les snapshots journaliers, en
> fait, bah c'est juste de la merde en boite puisque c'est stocké à côté pour
> pouvoir faire un restore en cas de panne mineure.
> Et ceux qui ont eu la chance d'avoir un backup FTP vers RBX, il semblerait
> que ce soit juste "de la chance".
> Et quand en plus, lors des migrations (forcées) vers leur nouvelle
> plateforme, on peut être basculé d'un bâtiment à l'autre sans aucun
> contrôle dessus, lorsqu'on y réfléchit, ça ne donne pas trop envie de
> mettre tous ses œufs chez OVH.
> 
> A partir de là, je conçois que ce soit la douche froide pour de nombreuses
> personnes et qui vont quitter OVH (déjà que leur support technique pour
> VPS est mauvais hors temps de crise, ce n'est pas le moment de le
> réévaluer aujourd'hui...). Cependant, on peut aussi se dire que la foudre
> ne tombera pas 2x fois au même endroit (bon sauf si le mec qui est
> intervenu (bizarrement) quelques heures avant l'incendie de ces mêmes
> onduleurs, intervient  à nouveau pour faire (peut-être) la même
> boulette)...
> 
> Je me souviens d'une formation chez APC en 2004 qui indiquait que les
> gros crashs en DC étaient dus 4/5 à un problème entre la chaise et le
> clavier... (les anciens se souviendront aussi de la Tour Redbus (tiens
> c'était aussi en mars je viens de voir. Décidément)).
> Et sinon, l'incendie en 2018 au Japon pour AWS, on en a beaucoup moins
> parlé. (moins de transparence chez les GAFAM ?)
> 
> Et pour finir, les données Office/Microsoft365, de base c'est pas non plus
> sauvegardé contre l'incendie. #JeDisCaJeDisRien...
> 
> Vincent Duvernet
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Olivier Lange]

Le mer. 17 mars 2021 09 h 07, Laurent Barme

> > D’autant que j’ai du me mettre à dos la moitié de la liste...
> >
> >
> Je fais partie de l'autre moitié -)
>

Pareil ;). Un peu marre de ceux qui repoussent leurs erreurs sur OVH au
lieu d'assumer. Ils sont pas tout rose ni parfait, mais il faut rester dans
la limite du raisonnable!

De mon côté, je n'ai presque plus besoin d'avoir D'infra, mais le peu que
j'si, j'ai fait le choix de partir sur des vm pci a 3€, que je considère
comme jetable et réparti dans les différents DC, avec le postulat que non,
ça ne peut pas Peter, ça va péter, et comment je fais en sorte que ce soit
transparent?

Olivier

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Christophe BARRY]

Merci Philippe
+1

Christophe Barry

> Le 17 mars 2021 à 14:09, Laurent Barme <5...@barme.fr> a écrit :
> 
> 
> Le 17/03/2021 à 13:12, Philippe ASTIER via frnog a écrit :
>>> Parce que prendre l'option payante pour les snapshots journaliers, en fait, 
>>> bah c'est juste de la merde en boite puisque c'est stocké à côté pour 
>>> pouvoir faire un restore en cas de panne mineure.
>>> Et ceux qui ont eu la chance d'avoir un backup FTP vers RBX, il semblerait 
>>> que ce soit juste "de la chance".
>>> Et quand en plus, lors des migrations (forcées) vers leur nouvelle 
>>> plateforme, on peut être basculé d'un bâtiment à l'autre sans aucun 
>>> contrôle dessus, lorsqu'on y réfléchit, ça ne donne pas trop envie de 
>>> mettre tous ses œufs chez OVH.
> …
>> 
>> Donc, j’en ai marre qu’on charge OVH parce que certains « pros » ne se sont 
>> juste jamais préoccupé de la base de leur métier : savoir où sont leurs 
>> données, comment elle sont protégées, et comment faire en cas de sinistre.
> +1
> …
>> D’autant que j’ai du me mettre à dos la moitié de la liste...
>> 
>> 
> Je fais partie de l'autre moitié -)
> 
> Laurent Barme
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Laurent Barme]

Le 17/03/2021 à 13:12, Philippe ASTIER via frnog a écrit :

Parce que prendre l'option payante pour les snapshots journaliers, en fait, bah 
c'est juste de la merde en boite puisque c'est stocké à côté pour pouvoir faire 
un restore en cas de panne mineure.
Et ceux qui ont eu la chance d'avoir un backup FTP vers RBX, il semblerait que ce soit 
juste "de la chance".
Et quand en plus, lors des migrations (forcées) vers leur nouvelle plateforme, 
on peut être basculé d'un bâtiment à l'autre sans aucun contrôle dessus, 
lorsqu'on y réfléchit, ça ne donne pas trop envie de mettre tous ses œufs chez 
OVH.

…


Donc, j’en ai marre qu’on charge OVH parce que certains « pros » ne se sont 
juste jamais préoccupé de la base de leur métier : savoir où sont leurs 
données, comment elle sont protégées, et comment faire en cas de sinistre.

+1
…

D’autant que j’ai du me mettre à dos la moitié de la liste...



Je fais partie de l'autre moitié -)

Laurent Barme



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Richard DEMONGEOT]

Le 2021-03-17 12:41, Vincent Duvernet a écrit :

Glop, glop,



Bonjour à tous,


Au final, comme beaucoup d'autres sur la liste, nous allons devoir
repenser certains aspects techniques.

Parce que prendre l'option payante pour les snapshots journaliers, en
fait, bah c'est juste de la merde en boite puisque c'est stocké à côté
pour pouvoir faire un restore en cas de panne mineure.


Le snapshot, c'est une photo du disque. Techniquement, c'est possible de 
les exporter sur un autre site (zfs send | zfs recieve); mais par défaut 
ce n'est pas le cas.
En plus, snapshot, tu prends une photo avec des fichiers ouverts, voir 
même potentiellement en cours d'écriture. Donc tu risque des corruptions 
de données, comme quand tu éteint ton serveur violemment.


Le snapshot est (selon moi) viable pour des VM avec peu d'écritures 
(genre PHP, ) mais pas pour les serveurs de bases de données par 
exemple. Ou alors, il faut - dans l'arbo - faire un dump SQL propre qui 
lui est snapshot-safe.



Et ceux qui ont eu la chance d'avoir un backup FTP vers RBX, il
semblerait que ce soit juste "de la chance".


En l’occurrence, oui. Mais à RBX (de ce que j'ai vu), ils mettent les 
serveurs de backups dans un autre DC que la machine. Est-ce que, comme 
pour SBG, plusieurs DC sont en campus? J'ai pas creusé.



Et quand en plus, lors des migrations (forcées) vers leur nouvelle
plateforme, on peut être basculé d'un bâtiment à l'autre sans aucun
contrôle dessus, lorsqu'on y réfléchit, ça ne donne pas trop envie de
mettre tous ses œufs chez OVH.


De ce que j'ai vu, on peut être basculé au sein de la même région, mais 
pas en inter région.
Donc tu peut tout à fait gérer ton backup en prenant les serveurs de 
backups dans d'autres régions.



A partir de là, je conçois que ce soit la douche froide pour de
nombreuses personnes et qui vont quitter OVH


Et est-ce que les autres font mieux? Douche froide, oui. Moins bien que 
la concurrence? je ne peut pas dire.



Et pour finir, les données Office/Microsoft365, de base c'est pas non
plus sauvegardé contre l'incendie. #JeDisCaJeDisRien...


Ohhh wait, le jour ou ça arrive chez Microsoft, on reparle de la douche 
froide ? :)



--
Richard


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Philippe ASTIER via frnog]

> Parce que prendre l'option payante pour les snapshots journaliers, en fait, 
> bah c'est juste de la merde en boite puisque c'est stocké à côté pour pouvoir 
> faire un restore en cas de panne mineure.
> Et ceux qui ont eu la chance d'avoir un backup FTP vers RBX, il semblerait 
> que ce soit juste "de la chance".
> Et quand en plus, lors des migrations (forcées) vers leur nouvelle 
> plateforme, on peut être basculé d'un bâtiment à l'autre sans aucun contrôle 
> dessus, lorsqu'on y réfléchit, ça ne donne pas trop envie de mettre tous ses 
> œufs chez OVH.

Je voudrais apporter mes 2 cents de bémol.

Un snapshot, c’est permet de se protéger des problèmes plus « logiques »  sur 
la machine, donc ce n’est absolument pas choquant pour moi que ce soit à côté, 
au contraire, le but est d’aller vite en supposant que le hardware n’a rien. 
Techniquement, un snapshot hors site, c’est pas très logique du tout.

Une sauvegarde, c’est déjà pas la même stratégie, et on peut aussi d’en avoir 
sur site, mais en ayant conscience qu’on n’a pas de protection en cas de 
sinistre physique. Ou même simplement d’indisponibilité du site.

Personne ne vous empêche d’avoir un snapshot sur site, un premier niveau de 
sauvegarde sur site et un deuxième sur un autre DC. C’est même probablement la 
meilleure chose à faire, OVH ou pas. Et de nombreux clients d’OVH, qui avaient 
adopté cette stratégie sont repartis en quelques heures.


C’est la base de notre métier et de l’écriture d’un PRA. Savoir quels sont les 
risques, combien ils coûtent, et comment les mitiger ou s’en protéger.

Donc, je ne reste pas d’accord, OVH ne fait pas de « merde en boite », et 
permet d’avoir le niveau de sauvegarde qu’on l’on veut en fonction des risques 
dont ont veut se protéger, au prix que l’on accepte de payer. OVH a toute les 
technos disponibles pour mettre en oeuvre un PRA complexe. C’est même peut-être 
beaucoup plus transparent que chez Azure ou AWS.


Donc, j’en ai marre qu’on charge OVH parce que certains « pros » ne se sont 
juste jamais préoccupé de la base de leur métier : savoir où sont leurs 
données, comment elle sont protégées, et comment faire en cas de sinistre. 

Je suis très curieux de voir les sociétés qui ont utilisé OVH en « clickodrome 
à pas cher » se défendre que leurs clients finaux vont leur demander où sont 
passées leurs données. 


Après, je suis pas naïf, qu’OVH pousse le marketing à nous faire croire que « 
tout va bien madame la marquise », ça se discute. Mais si l’infra d’OVH (ou de 
qui que ce soit d’autre) sert à faire de l’argent, il faut le faire 
sérieusement, en se posant les questions AVANT que le sinistre se produise, et 
pas en pleurant après que…. Ah mais ils ne m’ont pas dit ? Ca passe pour du 
grand public, pas pour du professionnel.


C’est pas un avis à 2 cents en fait. Ca vaut beaucoup plus cher que ça. :)
D’autant que j’ai du me mettre à dos la moitié de la liste...


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Thomas Quinot]

Le 17/03/2021 à 12:41, Vincent Duvernet a écrit :

Et sinon, l'incendie en 2018 au Japon pour AWS, on en a beaucoup moins parlé. 
(moins de transparence chez les GAFAM ?)
Apparemment l'immeuble était encore en chantier quand il a brûlé, pas en 
prod.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [MISC] OVH : SBG-2 en feu

[Vincent Duvernet]

Glop, glop,

Au final, comme beaucoup d'autres sur la liste, nous allons devoir repenser 
certains aspects techniques.

Parce que prendre l'option payante pour les snapshots journaliers, en fait, bah 
c'est juste de la merde en boite puisque c'est stocké à côté pour pouvoir faire 
un restore en cas de panne mineure.
Et ceux qui ont eu la chance d'avoir un backup FTP vers RBX, il semblerait que 
ce soit juste "de la chance".
Et quand en plus, lors des migrations (forcées) vers leur nouvelle plateforme, 
on peut être basculé d'un bâtiment à l'autre sans aucun contrôle dessus, 
lorsqu'on y réfléchit, ça ne donne pas trop envie de mettre tous ses œufs chez 
OVH.

A partir de là, je conçois que ce soit la douche froide pour de nombreuses 
personnes et qui vont quitter OVH (déjà que leur support technique pour VPS est 
mauvais hors temps de crise, ce n'est pas le moment de le réévaluer 
aujourd'hui...). Cependant, on peut aussi se dire que la foudre ne tombera pas 
2x fois au même endroit (bon sauf si le mec qui est intervenu (bizarrement) 
quelques heures avant l'incendie de ces mêmes onduleurs, intervient  à nouveau 
pour faire (peut-être) la même boulette)...

Je me souviens d'une formation chez APC en 2004 qui indiquait que les gros 
crashs en DC étaient dus 4/5 à un problème entre la chaise et le clavier... 
(les anciens se souviendront aussi de la Tour Redbus (tiens c'était aussi en 
mars je viens de voir. Décidément)).
Et sinon, l'incendie en 2018 au Japon pour AWS, on en a beaucoup moins parlé. 
(moins de transparence chez les GAFAM ?)

Et pour finir, les données Office/Microsoft365, de base c'est pas non plus 
sauvegardé contre l'incendie. #JeDisCaJeDisRien...

Vincent Duvernet

---
Liste de diffusion du FRnOG
http://www.frnog.org/