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

[Hugo COLLIGNON]

Hello all

Un "retour d'expérience opérationnel" du SDIS du Bas-Rhin a été publié il y
a quelques jours.
http://pnrs.ensosp.fr/Plateformes/RETEX/Actualites/Partage-d-Experience-du-SDIS-du-Bas-Rhin-Feu-dans-un-data-center-situe-sur-un-port-autonome

Hugo



On Sat, Mar 13, 2021 at 11:41 AM Emmanuel DECAEN 
wrote:

> Le 13/03/2021 à 08:47, Stéphane Rivière a écrit :
> >> Il y a plusieurs années, nous avons subit un emballement thermique sur
> >> un onduleur.
> > Quelle puissance environ ?
>
> Un onduleur de 30 KVA.
>
> >> Lorsque le technicien est arrivé sur site, il a extrait toutes les
> >> batteries, et confirmer le diagnostic : emballement thermique suite à la
> >> défaillance d'une batterie.
> >>
> >> Voici une petite photo de l'état dans lequel se trouvaient les
> batteries:
> > Si t'as un lien, pour "l'édification des masses", on est pour :)
>
> Dans le carton, on voit quelques batteries gonflées et d'autres sans
> dommage apparent:
> http://dl.free.fr/oaWpyYqQr
> http://dl.free.fr/kFoYYCSuf
>
> Cette différence est dû au lieu d'implantation dans l'onduleur.
> Au delà de l'apparence, pour le technicien intervenu sur site, toutes
> les batteries ont souffert et doivent être changées.
>
> --
> *Emmanuel DECAEN*
>
> ---
> 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]

> En version 'du pauvre', il est tout à fait possible de faire tourner un
> cluster Ceph avec ... un seul nœud (un étant un nombre impair) +
> rbd-mirror. Même avec un seul OSD pour avoir la couche CephFS, RBD,
> export NFS, exporter prometheus et tout le reste du stack.

J'ai tellement lu et reçu d'avis sur le nombre de nodes minimal pour
CEPTH (qui varie de 3 à 4) que, bon... pour l'instant... n'ayant pas ce
use-case en tête... Le jour où...

> Tout ça implique 2/3 manips au moment du PRA (changement de sens de
> synchro, passage en primaire, etc ...). Chez nous, on a choisit de
> documenter ça plutôt que de faire de l'automatique mais chacun ces
> préférences et son engagement de service.

+1000 ici, on est 0% automagie 100% doc + 10 doigts humains aussi.


Juste pour rire... Dredi engaged...

La seule automagie qu'on accepterait (mais faut vraiment en avoir
besoin, c'est bien trop coûteux en termes de ressources), c'est la vraie
HA. Cette où tu débranches le serveur, ou mieux, tu l'ouvres et tu
marres... j'ai tout essayé (sous tension bien sûr), virage de câble de
disque, barette ram, jusqu'à virer la CPU :)))

Dans tous les cas, la VM fige imperceptiblement (moins d'une demi
seconde) et le "téléchargement de la dernière Ubuntu sur le Doze XP
continue" (le test habituel, vu que c'était long à télécharger et que ça
testait aussi la connectivité...

La mise en œuvre du lab nous avait coûté des disques en raid 10 (donc 8
disques 2To SATA WD blackcaviar mais des haut de gamme qui valaient un
bras et pesaient comme des SAS et... qui tournent encore aujourd'hui...
pour 7 d'entre eux dans 2 servs en intra...

De la carte mère intel pci à 40€, 3 cartes réseaux par serv (dont 2 eth
pci à 10€ cul à cul boundées, oui c'est sale pour avoir 2Gbps entre) et
1eth 1 Gbpsde chaque vers l'intranet.

C'était sous debian xen drbd et... attends remus pour la glue logique
autour de xen et drbd : https://wiki.xenproject.org/wiki/Remus...

Une vieille manip de en 2010. C'était totalement magique mais tu sentais
que la synchro temps-réel de la ram, de la cpu (et des disques avec
drbd), ça chargeait et il aurait fallu des servs haut de gamme...

Mais le coté 'système immortel' était poilant.

On était très fier de notre coup.

C'était inutilisable :>

Enfin ça pouvait faire tourner quelques windows, quelques sambas pour
faire des NAS, mais la carte mère et la CPU des serveurs étaient trop
faibles et on a pas eu le besoin, vu la conso de ressources...

Je viens de faire un lscpu sur l'un d'eux... du 2c/4t, des... Core(TM)2
Quad CPU Q6600  @ 2.40GHz et la carte mère à 2 balles, de l'intel DG41RQ
 ridicules mais toujours vaillantes. Les disques ont dans les 70K heures
avec un power cycle de 80 (du aux manips HA d'origine qui avaient motivé
leur achat). Comme quoi on a pu quand même en tirer qqchose.

> Mais même avec une des deux solutions ci-dessus, on peut trouver des
> use-cases où un delta de 30s voire de 13ms n'est pas acceptable.

C'est ça. Tout dépends du use-case.

-- 
Be Seeing You
Number Six


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

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

[Stéphane Rivière]

Le 18/03/2021 à 11:16, Mickael MONSIEUR a écrit :
> Si non https://uptime.is/ pour éviter de vous tromper :)

Merci :)

J'aime beaucoup les liens directs

"For convenience, there are special CEO and SEO friendly links for N
nines: three nines, four nines, five nines, six nines etc. "

Donc la téléphonie numérique synchrone des années 90, c'était 5mn/an...

Y'a pas à dire, le progrès fait rage.

-- 
Be Seeing You
Number Six


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

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

[Mickael MONSIEUR]

Si non https://uptime.is/ pour éviter de vous tromper :)

Le jeu. 18 mars 2021 à 10:57, Lucas  a écrit :
>
> On 18/03/21 at 10:41 +0100, Philippe ASTIER via frnog wrote:
> > >> 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire 
> > >> beaucoup.
> > > Tu connais les contraintes de dispo de mon client et ce qu'il a lui-même
> > > vendu à ses clients ?
> >
> > Non. Je sais juste que 99,99%, ça fait classe, il y a beaucoup de
> > chiffres. Je voulais juste faire remarquer que ça fait près de 3,65
> > jours de downtime. Si c’est pour faire de l’argent ça a un coût.
>
> 99.99%, ça fait 3.65 jours par an seulement les années qui durent 100 ans.
> Les années normales, ça fait plutôt 52 minutes.
>
> L.
>
>
> ---
> 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

[Julien Escario]

Le 18/03/2021 à 10:30, Stéphane Rivière a écrit :
>> Un NAS-HA, forcément, c’est sur un site, faut pas rêver. 
> C'est intéressant ce que tu dis. Je le croyais aussi.
>
> Avec la techno qu'on développe en interne (qui n'est que la synthèse des
> possibilités réunies de xen linux lvm drbd avec de la glue logique pour
> résumer), on fait aujourd'hui 'NAS de pauvre' entre GRA et RBX (2ms
> entre, avec des serveurs NVMe qui poutrent et lien stable à 2Gbps).
>
> Bon, c'est pas du CEPH, hein, c'est un truc de pauvre. Mais qui marche.
>
> Voire même en triplette entre GRA RBX SBG (latence max 13ms) et sur SBG
> un serv avec disques mécas 8To raid 10 (pour des trucs moins sensibles à
> la perf mais triplement redondés). Et on triche pas coté vitesse puisque
> l'acquittement vient après l'écriture sur le disque pour privilégier la
> sûreté.

Ah, un peu de tech ! ;-)

Alors, même avec Ceph, y'a pas mal de possibilités avec rbd-mirror qui
fonctionne de manière asynchrone. Avec ça, la latence, tu t'en fous, il
faut juste que le lien puisse engranger le débit de tes écritures. Et ça
marche en 'two-way'.

Je n'ai pas encore testé mais en Octopus, tu peux aussi faire du mode
snapshot, qui revient, peu ou prou avec un ZFS send/receive (si j'ai
bien compris).

En version 'du pauvre', il est tout à fait possible de faire tourner un
cluster Ceph avec ... un seul nœud (un étant un nombre impair) +
rbd-mirror. Même avec un seul OSD pour avoir la couche CephFS, RBD,
export NFS, exporter prometheus et tout le reste du stack.

Tout ça implique 2/3 manips au moment du PRA (changement de sens de
synchro, passage en primaire, etc ...). Chez nous, on a choisit de
documenter ça plutôt que de faire de l'automatique mais chacun ces
préférences et son engagement de service.

Mais même avec une des deux solutions ci-dessus, on peut trouver des
use-cases où un delta de 30s voire de 13ms n'est pas acceptable.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

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

[Stéphane Rivière]

> Et ma petite question sur un point qui semble au coeur des désaccords :
> est-ce qu'un pro, qui est supposé savoir de quoi on parle etc... avait la
> possibilité de savoir que le super HA vendu par ovh était monosite ?

C'est effectivement /la/ question.

> D'après les infos de certains, j'ai l'impression qu'à moins d'aller creuser
> très loin, cette info n'était pas accessible et tout laissait à penser que
> c'était le cas (le fait que les SBG-x soient autant concentrés n'aidant
> pas).

+1, le site est pas facile.

+ la confusion régions open-stack SBG-5 et SBG-6 et serveurs physiques
(plus un SBG-5 physique à venir).

> Perso, je n'aurais probablement pas imaginé devoir aller sur une carto
> vérifier l'éloignement entre 2 DC pour anticiper un incendie. Car quelques
> centaines de mètres suffisent normalement à se protéger assez certainement
> d'une perte totale de données avec un backup minimal.

J'avoue, perso, l'incendie complet + contamination d'un autre DC par la
proximité, j'avais également rien anticipé sur ça.

-- 
Be Seeing You
Number Six


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

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

[Lucas]

On 18/03/21 at 10:41 +0100, Philippe ASTIER via frnog wrote:
> >> 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.
> > Tu connais les contraintes de dispo de mon client et ce qu'il a lui-même
> > vendu à ses clients ?
> 
> Non. Je sais juste que 99,99%, ça fait classe, il y a beaucoup de
> chiffres. Je voulais juste faire remarquer que ça fait près de 3,65
> jours de downtime. Si c’est pour faire de l’argent ça a un coût.

99.99%, ça fait 3.65 jours par an seulement les années qui durent 100 ans.
Les années normales, ça fait plutôt 52 minutes.

L.


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

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

[Stéphane Rivière]

> Hmmm, 13ms de latence pour acquiter une écriture, faut pas écrire
> beaucoup, ou avoir une charge applicative qui le tolère bien, dis donc !
C'est (comme précisé) pour des trucs qu'ont pas besoin de poutrer mais
d'être très résilients (d'où les 3 DC). Disais ça juste pour le coup des
8To RAID10 avec des disques et une CM pas dégueu, ça le fait quand même.

Un bon RAID10 sur 4 bons disques, je trouve que ça ressemble à du SSD,
qui est lui-même très loin du NVMe.

Pour le reste, on préfère effectivement les 2ms *et* du NVMe avec de
bonnes cartes mères :>

-- 
Be Seeing You
Number Six


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

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

[Philippe ASTIER via frnog]

Merci pour le calcul… faut que je dorme… 

Pour moi = HA = haute disponibilité = cluster avec de grosses contraintes.

Le problème c’est que le terme a dérivé, parce que la HA pour un serveur web, 
on peut tricher en multipliant les frontaux.

Au départ, la HA, c’était du cluster sur site avec de la bascule automatique en 
quelques secondes de manière automatique, et c’est pas le même jeu.

> Le 18 mars 2021 à 10:45, Francois Prems  a écrit :
> 
> Bonjour à tous,
> 
> Merci pour ce débat très intéressant et instructif.
> 
> Je veux juste apporter ma minuscule contribution en corrigeant une erreur 
> significative dans le contexte 
> 
> > 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.
> 
> Non,  99,99% = 52 minutes de downtime par an.
> 
> (3.65 jours c'est 99% d'une année, pas 99.99%, qui est presque 1% de plus)
> 
> Et ma petite question sur un point qui semble au coeur des désaccords : 
> est-ce qu'un pro, qui est supposé savoir de quoi on parle etc... avait la 
> possibilité de savoir que le super HA vendu par ovh était monosite ? D'après 
> les infos de certains, j'ai l'impression qu'à moins d'aller creuser très 
> loin, cette info n'était pas accessible et tout laissait à penser que c'était 
> le cas (le fait que les SBG-x soient autant concentrés n'aidant pas).
> Perso, je n'aurais probablement pas imaginé devoir aller sur une carto 
> vérifier l'éloignement entre 2 DC pour anticiper un incendie. Car quelques 
> centaines de mètres suffisent normalement à se protéger assez certainement 
> d'une perte totale de données avec un backup minimal... 
> 
> François 
>  


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

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

[Francois Prems]

Bonjour à tous,

Merci pour ce débat très intéressant et instructif.

Je veux juste apporter ma minuscule contribution en corrigeant une erreur
significative dans le contexte

> 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.

Non,  99,99% = 52 minutes de downtime par an.

(3.65 jours c'est 99% d'une année, pas 99.99%, qui est presque 1% de plus)

Et ma petite question sur un point qui semble au coeur des désaccords :
est-ce qu'un pro, qui est supposé savoir de quoi on parle etc... avait la
possibilité de savoir que le super HA vendu par ovh était monosite ?
D'après les infos de certains, j'ai l'impression qu'à moins d'aller creuser
très loin, cette info n'était pas accessible et tout laissait à penser que
c'était le cas (le fait que les SBG-x soient autant concentrés n'aidant
pas).
Perso, je n'aurais probablement pas imaginé devoir aller sur une carto
vérifier l'éloignement entre 2 DC pour anticiper un incendie. Car quelques
centaines de mètres suffisent normalement à se protéger assez certainement
d'une perte totale de données avec un backup minimal...

François

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

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

[Dominique Rousseau]

Le Thu, Mar 18, 2021 at 10:30:16AM +0100, Stéphane Rivière [s...@genesix.org] a 
écrit:
[...]
> 
> Voire même en triplette entre GRA RBX SBG (latence max 13ms) et sur SBG
> un serv avec disques mécas 8To raid 10 (pour des trucs moins sensibles à
> la perf mais triplement redondés). Et on triche pas coté vitesse puisque
> l'acquittement vient après l'écriture sur le disque pour privilégier la
> sûreté.

Hmmm, 13ms de latence pour acquiter une écriture, faut pas écrire
beaucoup, ou avoir une charge applicative qui le tolère bien, dis donc !


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

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

[Philippe ASTIER via frnog]

> Tu te confrontes à tes propres contradictions : c'est aux prestas de
> prévoir les backups hors-site mais quand OVH te dit qu'il s'en occupe,
> tout d'un coup ça devient 'compliqué' ? Avec un réseau en propre ?

La responsabilité d’un professionnel, c’est de savoir comment est fait ce qu’il 
délègue à autrui.

Est-ce que tu as un contrat d’OVH qui te dit que les backups de ta solution 
étaient hors site ? Si oui, tu les traines au tribunal. Sinon… ben ya eu un 
trou dans la raquette, ou alors fallait pas signer. (Je me rends compte que tu 
dis après que tu étais en train de sortir, donc ce n’est pas forcément ta 
responsabilité initiale).

> Au risque de te vexer à nouveau (sans que ce soit le but), c'est ma
> définition de fan-boy, mais on peut ergoter longtemps juste sur ce point.

Je ne vais pas me vexer du tout. 

> Mon client n'attendait pas de la haute dispo sur une catastrophe
> pareille mais un backup restaurable, même à J+7, il aurait trouvé ça
> plutôt normal. TL;DR : le backup est spécifié dans le service NAS-HA.
> Après, ce que c'est exactement, on en sait pas et c'est justement là
> qu'on a fauté pour notre part.

« Le backup est spécifié ». J’ai pas lu les termes, ça dit quoi ? 
Ah pardon, tu as écrit que tu ne savais pas. Ben sans vouloir te vexer, fallait 
pas signer du tout. Mais moi je me contredis...

> On essaie toutefois de rester humbles et compatissants parce qu'un jour,
> ça va nous arriver.

L’humilité est importante dans nos métiers. On commet tous des erreurs par 
omissions ou excès de confiance, surtout que tout le monde pense que tout 
s’offre instantanément à 10 euros, et que tout est indestructible. C’est nier 
la réalité.

>> 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.
> Tu connais les contraintes de dispo de mon client et ce qu'il a lui-même
> vendu à ses clients ?

Non. Je sais juste que 99,99%, ça fait classe, il y a beaucoup de chiffres. Je 
voulais juste faire remarquer que ça fait près de 3,65 jours de downtime. Si 
c’est pour faire de l’argent ça a un coût.

>> Tu es allé chez OVH pour le côté low-cost, difficile de s’en offusquer 
>> après. 
> Je n'ai pas dû être clair, désolé : j'étais en train de SORTIR un
> client, ce ne sont pas des choix que j'ai fait mais que je dois assumer
> quand même, c'est la vie ;-)


Ouais, c’est le pas de bol.
« Shit happens » 

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

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

[Stéphane Rivière]

> Un NAS-HA, forcément, c’est sur un site, faut pas rêver. 

C'est intéressant ce que tu dis. Je le croyais aussi.

Avec la techno qu'on développe en interne (qui n'est que la synthèse des
possibilités réunies de xen linux lvm drbd avec de la glue logique pour
résumer), on fait aujourd'hui 'NAS de pauvre' entre GRA et RBX (2ms
entre, avec des serveurs NVMe qui poutrent et lien stable à 2Gbps).

Bon, c'est pas du CEPH, hein, c'est un truc de pauvre. Mais qui marche.

Voire même en triplette entre GRA RBX SBG (latence max 13ms) et sur SBG
un serv avec disques mécas 8To raid 10 (pour des trucs moins sensibles à
la perf mais triplement redondés). Et on triche pas coté vitesse puisque
l'acquittement vient après l'écriture sur le disque pour privilégier la
sûreté.

> Bref. Un bâtiment, ça se détruit, la preuve. 
> Donc ton NAS-HA il était destructible. Tout le monde l’oublie, certes, mais 
> il fallait le documenter et comprendre si c’était un souci ou pas.

Faut avouer que la perte de serveur c'était prévu... mais si on mettait
nos œufs dans plusieurs DC, c'est qu'on pensait plus à nos amis les
tractopelles qu'au 'grand incendie'...

> 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.

+1000

Qui a dit ici qu'il avait évolué dans le monde à 5 chiffres (99.999),
celui des télécoms ? Sauf que les télécoms (au sens PABX temporels,
techno synchrone purement téléphonique) n'existent plus et que
maintenant c'est de la VOIP purement asynchrone (comme tout transmission
IP).

> Tu es allé chez OVH pour le côté low-cost, difficile de s’en offusquer après. 
> Le terme de fan-boy est assez insultant. 

Bah... Comme dit un pote anglais "lassetomb" - pour laisse tomber :)

-- 
Be Seeing You
Number Six


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

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

[Philippe ASTIER via frnog]

+1000 au moins
Merci Stéphane, c’était exactement le but de mon premier message…

Le bashing ne fait rien avancer, et ne permet pas de retex.

L’offre d’OVH permet d’accéder rapidement à des services qu’on a du mal à 
trouver aussi simplement ailleurs.

Après, personne ne vous empêche de changer de crèmerie non plus.

> Le 18 mars 2021 à 10:16, Stéphane Rivière  a écrit :
> 
> Non messieurs, d'abord on ne s'étripe pas, on discute et je ressens le
> bashing OVH comme injuste par rapport à ce qu'offre OVH pour le prix.
> 
> Donc je prends le temps de basher les basheurs, dans le respect
> toutefois (chacun est libre de ses opinions, y compris de critiquer les
> critiqueurs, n'est-il pas ? ;)
> 
> Je ne suis pas un fan boy, ni ne réduit l'incendie d'un onduleur à un
> problème marketing. Facile de fermer le débat par des adjectifs ou
> d'accuser le marketing de tous les maux.
> 
> La critique est facile et il n'y a pas de honte à choisir la bourse si
> c'est leur choix, ni de changer leur nom si ça leur chante, ni de faire
> de la gratte et un album pour se faire plaisir... C'est leur droit
> d'entreprise et d'humains libres et le marché tranchera.
> 
> Je suis un tech qui a conscience de la difficulté de faire son métier de
> sysadmin et de l'extraordinaire complexité technique d'une entreprise
> comme OVH. La technique est faillible.
> 
> Je suppose qu'on fera un jour un procès à la nature parce qu'au bout, il
> y a la mort. Comme des enfants font déjà des procès à leurs parents
> parce qu'ils n'ont jamais demandé à naître.
> 
> Vous confondez le 'système parfait' qui n'existe pas avec un process
> d'évolution technique où les DC d'OVH tendent, à chaque génération, vers
> le meilleur, selon une approche d'action, réaction (retex), correction.
> 
> Musk fait pareil avec ses fusées. C'est l'approche à privilégier pour
> innover rapidement.
> 
> Vous confondez un accident industriel, qui aura un retex, avec le
> résultat d'une conception malveillante, comme le 737max.
> 
> Pour le reste Carpe Diem.
> 
> -- 
> 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

[Julien Escario]

Le 18/03/2021 à 10:01, Philippe ASTIER a écrit :
> La haute-disponibilité entre sites, c’est hors de prix et contraignant, parce 
> que la bande passante et la latence sont durs à gérer, même avec les débits 
> d’aujourd’hui.
> Un NAS-HA, forcément, c’est sur un site, faut pas rêver. 
>
> Bref. Un bâtiment, ça se détruit, la preuve. 
> Donc ton NAS-HA il était destructible. Tout le monde l’oublie, certes, mais 
> il fallait le documenter et comprendre si c’était un souci ou pas.

Tu te confrontes à tes propres contradictions : c'est aux prestas de
prévoir les backups hors-site mais quand OVH te dit qu'il s'en occupe,
tout d'un coup ça devient 'compliqué' ? Avec un réseau en propre ?

Au risque de te vexer à nouveau (sans que ce soit le but), c'est ma
définition de fan-boy, mais on peut ergoter longtemps juste sur ce point.

Mon client n'attendait pas de la haute dispo sur une catastrophe
pareille mais un backup restaurable, même à J+7, il aurait trouvé ça
plutôt normal. TL;DR : le backup est spécifié dans le service NAS-HA.
Après, ce que c'est exactement, on en sait pas et c'est justement là
qu'on a fauté pour notre part.

On essaie toutefois de rester humbles et compatissants parce qu'un jour,
ça va nous arriver.

>> 99,99% d'uptime garanti, pour du site vitrine, ça semblait bien coller,
>> on s'est laissés avoir, on a pas creusé davantage et on a commencé à
>> migrer à marche forcée les trucs qui étaient vraiment en danger.
> 99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.
Tu connais les contraintes de dispo de mon client et ce qu'il a lui-même
vendu à ses clients ?
>> Avec tout le respect que j'ai pour Octave et ce qu'il a accompli ces 20
>> dernières années, quand on démarre une boite dans un esprit low-cost, il
>> est très difficile d'en sortir (cf le peering Free, par exemple), n'en
>> déplaise aux fan-boys.
> Tu es allé chez OVH pour le côté low-cost, difficile de s’en offusquer après. 
Je n'ai pas dû être clair, désolé : j'étais en train de SORTIR un
client, ce ne sont pas des choix que j'ai fait mais que je dois assumer
quand même, c'est la vie ;-)

Julien




OpenPGP_signature
Description: OpenPGP digital signature

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

[David Ponzone]

C’est peut-être parce que je viens du réseau, et que j’ai commencé en 95, à une 
époque où les SLA non respectés coûtaient des fortunes à France 
Telecom/Worldcom/MCI/TD/Siris/autres, mais un SLA n’a de valeur que si ie 
fournisseur s’engage contractuellement à payer des pénalités.

En hosting, c’est probablement une notion historiquement moins regardée car les 
incidents restent rares.

Pour moi, un SLA en hosting, ça doit coûter X mois d’abonnement pour une 
coupure de plus de 4h, et pour une coupure de 24H, on doit arriver à 2/3 ans 
d’abonnement, parce que ça doit jamais arriver.
Mais ce SLA n’a de sens que si le fournisseur craint de le payer à un grand 
nombre de clients (comme France Telecom sur les Transfix il y a 20 ans) et/ou 
que le prix de ce service est élevé voir très élevé.
Si dans le DC, y a 100 000 clients sans SLA, et 5 qui se paient le super 
service avec SLA, j’ai peur que ça soit pas une grosse pression.
Donc j’aurais tendance à me méfier du SLA d’un fournisseur qui construit 99% de 
son CA sur des offres sans SLA.

> Le 18 mars 2021 à 09:44, Julien Escario  a écrit :
> 
> 
> Exemple : j'ai un client qui était en cours de migration sur une infra
> qu'on lui a monté chez nous : pas de bol, ce qui tournait bien, n'avait
> pas de soucis de perf ou de problème immédiat de redondance était à
> SBG2. des machines physiques avec une grosse partie du stockage en
> NAS-HA. Pourquoi on est passés à côté ? Parce que le service NAS-HA, il
> est vendu sur la page comme quasi-indestructible avec des SLA de malade
> en dispo, du backup, etc ...
> 


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

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

[Stéphane Rivière]

Non messieurs, d'abord on ne s'étripe pas, on discute et je ressens le
bashing OVH comme injuste par rapport à ce qu'offre OVH pour le prix.

Donc je prends le temps de basher les basheurs, dans le respect
toutefois (chacun est libre de ses opinions, y compris de critiquer les
critiqueurs, n'est-il pas ? ;)

Je ne suis pas un fan boy, ni ne réduit l'incendie d'un onduleur à un
problème marketing. Facile de fermer le débat par des adjectifs ou
d'accuser le marketing de tous les maux.

La critique est facile et il n'y a pas de honte à choisir la bourse si
c'est leur choix, ni de changer leur nom si ça leur chante, ni de faire
de la gratte et un album pour se faire plaisir... C'est leur droit
d'entreprise et d'humains libres et le marché tranchera.

Je suis un tech qui a conscience de la difficulté de faire son métier de
sysadmin et de l'extraordinaire complexité technique d'une entreprise
comme OVH. La technique est faillible.

Je suppose qu'on fera un jour un procès à la nature parce qu'au bout, il
y a la mort. Comme des enfants font déjà des procès à leurs parents
parce qu'ils n'ont jamais demandé à naître.

Vous confondez le 'système parfait' qui n'existe pas avec un process
d'évolution technique où les DC d'OVH tendent, à chaque génération, vers
le meilleur, selon une approche d'action, réaction (retex), correction.

Musk fait pareil avec ses fusées. C'est l'approche à privilégier pour
innover rapidement.

Vous confondez un accident industriel, qui aura un retex, avec le
résultat d'une conception malveillante, comme le 737max.

Pour le reste Carpe Diem.

-- 
Be Seeing You
Number Six


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

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

[Philippe ASTIER via frnog]

> Honnêtement, je pense qu'il faut que vous sortiez des facteurs
> techniques et que l'on accepte collectivement que c'est le marketing qui
> est la cause principale d'une perte de données.

Euh on a écrit ça. 
Le marketing fait oublier à certains la réalité technique.
Ca n’empêche que les professionnels qui achètent doivent comprendre ce qu’ils 
achètent, en profondeur.

> Exemple : j'ai un client qui était en cours de migration sur une infra
> qu'on lui a monté chez nous : pas de bol, ce qui tournait bien, n'avait
> pas de soucis de perf ou de problème immédiat de redondance était à
> SBG2. des machines physiques avec une grosse partie du stockage en
> NAS-HA. Pourquoi on est passés à côté ? Parce que le service NAS-HA, il
> est vendu sur la page comme quasi-indestructible avec des SLA de malade
> en dispo, du backup, etc ...

La haute-disponibilité entre sites, c’est hors de prix et contraignant, parce 
que la bande passante et la latence sont durs à gérer, même avec les débits 
d’aujourd’hui.
Un NAS-HA, forcément, c’est sur un site, faut pas rêver. 

Bref. Un bâtiment, ça se détruit, la preuve. 
Donc ton NAS-HA il était destructible. Tout le monde l’oublie, certes, mais il 
fallait le documenter et comprendre si c’était un souci ou pas.

> 99,99% d'uptime garanti, pour du site vitrine, ça semblait bien coller,
> on s'est laissés avoir, on a pas creusé davantage et on a commencé à
> migrer à marche forcée les trucs qui étaient vraiment en danger.

99,99% = 3,65 jours de downtime par an, ça commence déjà à faire beaucoup.

> Avec tout le respect que j'ai pour Octave et ce qu'il a accompli ces 20
> dernières années, quand on démarre une boite dans un esprit low-cost, il
> est très difficile d'en sortir (cf le peering Free, par exemple), n'en
> déplaise aux fan-boys.

Tu es allé chez OVH pour le côté low-cost, difficile de s’en offusquer après. 
Le teme de fan-boy est assez insultant. J’ai des services chez OVH, chez 
d’autres, en fonction des contraintes et du coût.

OVH a un price-point intéressant, avec des risques, qu’on n’est pas forcé 
d’accepter.

> La chose positive dans tout ça, c'est que depuis, nos clients nous
> 'challengent' sur leurs PRA/PCA et on découvre plein de trucs qui ne
> vont pas ici et là. C'est très instructif.

Ah ben ça c’st cool. :)

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

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

[Remi Desgrange]

C'est très intéressant ce que tu dis.

J'ai l'impression que les AWS, GCP, Azure et consort ont fait beaucoup de
marketing autour de "nos VM sont éphémères, tu n'a pas de KVM, si elle
crash tu en remontes une nouvelle, l'immutable caytropbien, etc..." (et
accessoirement, utilisez nos services managés, car on est meilleur que vous
pour ça, et ça ramène plus de pognon).

Je n’ai pas l'impression qu'OVH ait marketé le truc comme ça.

On Thu, Mar 18, 2021 at 9:45 AM Julien Escario 
wrote:

> Bonjour,
>
> Je vous lis depuis quelques jours en train de vous étriper sur la place
> du curseur de responsabilité d'OVH.
>
> Honnêtement, je pense qu'il faut que vous sortiez des facteurs
> techniques et que l'on accepte collectivement que c'est le marketing qui
> est la cause principale d'une perte de données.
>
> Exemple : j'ai un client qui était en cours de migration sur une infra
> qu'on lui a monté chez nous : pas de bol, ce qui tournait bien, n'avait
> pas de soucis de perf ou de problème immédiat de redondance était à
> SBG2. des machines physiques avec une grosse partie du stockage en
> NAS-HA. Pourquoi on est passés à côté ? Parce que le service NAS-HA, il
> est vendu sur la page comme quasi-indestructible avec des SLA de malade
> en dispo, du backup, etc ...
>
> 99,99% d'uptime garanti, pour du site vitrine, ça semblait bien coller,
> on s'est laissés avoir, on a pas creusé davantage et on a commencé à
> migrer à marche forcée les trucs qui étaient vraiment en danger.
>
> Si on avait pu parler à un tech OVH d'un level suffisant, il nous aurait
> probablement expliqué où était le risque (et il est probable qu'on
> l'aurait mis de côté vu ce qu'il y avait par ailleurs) mais voilà, c'est
> du low-cost et le tech, on y a pas accès parce que le marketing a
> verrouillé la communication sur ces questions.
>
> Avec tout le respect que j'ai pour Octave et ce qu'il a accompli ces 20
> dernières années, quand on démarre une boite dans un esprit low-cost, il
> est très difficile d'en sortir (cf le peering Free, par exemple), n'en
> déplaise aux fan-boys.
>
> La chose positive dans tout ça, c'est que depuis, nos clients nous
> 'challengent' sur leurs PRA/PCA et on découvre plein de trucs qui ne
> vont pas ici et là. C'est très instructif.
>
> Julien
>
> Le 18/03/2021 à 09:05, Stéphane Rivière a écrit :
> >> 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.
> > OVH a doublé comme prévu son alim sur SBG, plusieurs M€ d'investissement
> > et les conteneurs, ça se déménage en claquant des doigts ? Les permis de
> > construire, le pognon, les thunes quoi, facile, j'achète, j'achète :)))
> >
> > OVH est en train de finaliser SBG5 (physique), certainement pour migrer
> > SBG1 et SBG4 et ensuite "faire de la place" pour un SBG6 (physique).
> >
> > Bon, ça ne va pas assez vite pour toi... Monsieur pressé :)
> >
> --
> *Julien Escario*
> Technicien Informatique
>
> julien.esca...@altinea.fr
> Tel direct : 03 74 39 10 21
> Support : 09 70 75 44 25
>
> Logo Altinea
> *Conseils & Infrastructures
> Informatiques*
>
> Accueil : 03 74 39 10 20
> 9 Rue du faubourg 39570 Nogna
> *www.altinea.fr *
>
>
>

-- 
Cordialement, Rémi Desgrange

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

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

[Mickael Monsieur]

> Le 18 mars 2021 à 09:05, Stéphane Rivière  a écrit :
> 
> 
>> 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. 
> OVH a doublé comme prévu son alim sur SBG, plusieurs M€ d'investissement
> et les conteneurs, ça se déménage en claquant des doigts ? Les permis de
> construire, le pognon, les thunes quoi, facile, j'achète, j'achète :)))
> 
> OVH est en train de finaliser SBG5 (physique), certainement pour migrer
> SBG1 et SBG4 et ensuite "faire de la place" pour un SBG6 (physique).
> 
> Bon, ça ne va pas assez vite pour toi... Monsieur pressé :)

Ce qui est magnifique avec les fans boys c’est que ça ose tout... la preuve en 
est ... 

Presque 5 ans... tu te rends compte de l’énormité que tu dit ? C’est une 
éternité en gestion de projets dans ce secteur, surtout quand c’est censé être 
critique. La sécurisation de l’exploitation existante doit toujours passer 
AVANT l’expansion... 

Entre temps, ils ont eu le temps d’ouvrir des NOUVEAUX DC, de changer un nom de 
marque fort pour un nom de marque que personne utilise, de monter un dossier 
boursier... (la liste est sûrement plus longue, mais je me moque totalement de 
leur Life, on les a quittés en 2007 après 7 ans pour notre plus grand 
soulagement...) 

Ce qui est certain c’est que leur model eco c’est de toujours plus grossir pour 
payer les banques et les fonds, cette dynamique vient d’être stoppée net au 
plus mauvais moment pour eux, car je pense qu’ils vont se retrouver en mauvaise 
posture si ils n’ont pas d’argent frais cette année. Ils comptaient sur l’intro 
en bourse pour cela, c’est mort.

> 
> -- 
> Stéphane Rivière
> Ile d'Oléron - France


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

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

[Stéphane Cottin via frnog]

On 18 Mar 2021, at 9:29, Dominique Rousseau wrote:

Le Wed, Mar 17, 2021 at 11:41:33AM +, Vincent Duvernet 
[vincent.duver...@nolme.com] a écrit:

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.


Des snapshots, ça n'a *jamais* été un mode sauvegarde sur lequel
s'appuyer pour un PRA.


+1000




--
Dominique Rousseau
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - 
http://www.neuronnexion.coop



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

[Julien Escario]

Bonjour,

Je vous lis depuis quelques jours en train de vous étriper sur la place
du curseur de responsabilité d'OVH.

Honnêtement, je pense qu'il faut que vous sortiez des facteurs
techniques et que l'on accepte collectivement que c'est le marketing qui
est la cause principale d'une perte de données.

Exemple : j'ai un client qui était en cours de migration sur une infra
qu'on lui a monté chez nous : pas de bol, ce qui tournait bien, n'avait
pas de soucis de perf ou de problème immédiat de redondance était à
SBG2. des machines physiques avec une grosse partie du stockage en
NAS-HA. Pourquoi on est passés à côté ? Parce que le service NAS-HA, il
est vendu sur la page comme quasi-indestructible avec des SLA de malade
en dispo, du backup, etc ...

99,99% d'uptime garanti, pour du site vitrine, ça semblait bien coller,
on s'est laissés avoir, on a pas creusé davantage et on a commencé à
migrer à marche forcée les trucs qui étaient vraiment en danger.

Si on avait pu parler à un tech OVH d'un level suffisant, il nous aurait
probablement expliqué où était le risque (et il est probable qu'on
l'aurait mis de côté vu ce qu'il y avait par ailleurs) mais voilà, c'est
du low-cost et le tech, on y a pas accès parce que le marketing a
verrouillé la communication sur ces questions.

Avec tout le respect que j'ai pour Octave et ce qu'il a accompli ces 20
dernières années, quand on démarre une boite dans un esprit low-cost, il
est très difficile d'en sortir (cf le peering Free, par exemple), n'en
déplaise aux fan-boys.

La chose positive dans tout ça, c'est que depuis, nos clients nous
'challengent' sur leurs PRA/PCA et on découvre plein de trucs qui ne
vont pas ici et là. C'est très instructif.

Julien

Le 18/03/2021 à 09:05, Stéphane Rivière a écrit :
>> 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. 
> OVH a doublé comme prévu son alim sur SBG, plusieurs M€ d'investissement
> et les conteneurs, ça se déménage en claquant des doigts ? Les permis de
> construire, le pognon, les thunes quoi, facile, j'achète, j'achète :)))
>
> OVH est en train de finaliser SBG5 (physique), certainement pour migrer
> SBG1 et SBG4 et ensuite "faire de la place" pour un SBG6 (physique).
>
> Bon, ça ne va pas assez vite pour toi... Monsieur pressé :)
>
-- 
*Julien Escario*
Technicien Informatique

julien.esca...@altinea.fr
Tel direct : 03 74 39 10 21
Support : 09 70 75 44 25

Logo Altinea
*Conseils & Infrastructures
Informatiques*

Accueil : 03 74 39 10 20
9 Rue du faubourg 39570 Nogna
*www.altinea.fr *




OpenPGP_signature
Description: OpenPGP digital signature

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

[Dominique Rousseau]

Le Wed, Mar 17, 2021 at 11:41:33AM +, Vincent Duvernet 
[vincent.duver...@nolme.com] a écrit:
> 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.

Des snapshots, ça n'a *jamais* été un mode sauvegarde sur lequel
s'appuyer pour un PRA.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

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

[Laurent Barme]

Le 17/03/2021 à 23:18, Vincent Finance via frnog a écrit :
…

  Le mieux serait de choisir deux opposés
… ou deux régions
assez lointaines, mais pas trop pour éviter les fortes latences (genre
SBG et RBX dans le cas OVH).


C'est une solution qu'OVH avait mise en avant au Summit de 2014 ;-)


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

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

[Stéphane Rivière]

> "en fait SBG1 et SBG2 c'est le même DC il y a juste une cloison

SBG1 c'est deux rangées de conteneurs (bien visibles sur une vue sat)
sur deux étages (je crois), le tout est totalement séparé (plusieurs
mètres) de SBG2, conçu sur une autre techno.

Le sens des vents, la disposition et la violence de l'incendie de SBG2
> confiance à la nomenclature OVH...

La règle de base : éparpiller ses bécanes entre GRA <2ms> RBX <9ms> SBG,
ce qui fait d'ailleurs 13ms entre GRA et SBG.(pings via le réseau privé
OVH, pas internet...)

Après, certains disent qu'un ultime backup chez un autre hébergeur
serait souhaitable contre le vol de NIC, le "sahbhotââge" interne...

C'est probablement un bon conseil.

Tout *conseil paranoïaque* sur les sauvegardes et le métier de syadmin
ou d'hébergeur est un *bon conseil*.

-- 
Be Seeing You
Number Six


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

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

[Michel 'ic' Luczak]

io,

> On 17 Mar 2021, at 23:44, Vincent Bernat  wrote:
> 
> Pas forcément. Par exemple, Equinix PA2 et PA3 sont accolés.

certes, mais c’est plus ou moins explicite dès le site plaquette 
https://www.equinix.com/locations/europe-colocation/france-colocation/paris-data-centers/
 donc pas de surprise…

++ ic



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

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

[Stéphane Rivière]

> 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. 
OVH a doublé comme prévu son alim sur SBG, plusieurs M€ d'investissement
et les conteneurs, ça se déménage en claquant des doigts ? Les permis de
construire, le pognon, les thunes quoi, facile, j'achète, j'achète :)))

OVH est en train de finaliser SBG5 (physique), certainement pour migrer
SBG1 et SBG4 et ensuite "faire de la place" pour un SBG6 (physique).

Bon, ça ne va pas assez vite pour toi... Monsieur pressé :)

-- 
Stéphane Rivière
Ile d'Oléron - France


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

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

[Fabrice TERRANCLE]

Bonjour,

De manière générale, il est quand même plus prudent de gérer le backup dans un 
autre datacenter certes, mais aussi et surtout chez un autre hébergeur.

En effet, on peut tout à fait imaginer le bug d'un robot interne chez OVH, un 
bug massif du système de réinstallation automatique... Dans ce dernier cas, 
ceux qui auront fait le double chez OVH pourrait s'en mordre les doigts.

Ok, c'est peut-être improbable, mais un incendie ça l'est tout autant.

Avant l'incident de SBG2, les clients n'entendaient pas ces arguments, OVH 
était le meilleur, point barre. Cet incendie permet de dire que tout peut 
arriver, quelque soit la confiance que l'on peut avoir.

Cordialement,
Fabrice TERRANCLE
Administrateur système
Tel. Mobile : 0658885108

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Vincent 
Bernat
Envoyé : mercredi 17 mars 2021 23:45
À : Barthélémy DELUY 
Cc : Mickael Monsieur ; FRnOG ML 
Objet : Re: [FRnOG] [MISC] OVH : SBG-2 en feu

 ❦ 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/


smime.p7s
Description: S/MIME cryptographic signature

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] [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] 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] [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] [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] [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] [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] [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/

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/

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

[Stéphane Rivière]

> Un onduleur de 30 KVA.

Oui, ça commence à faire quelques batteries.

> http://dl.free.fr/oaWpyYqQr
> http://dl.free.fr/kFoYYCSuf

Merci.

> Au delà de l'apparence, pour le technicien intervenu sur site, toutes
> les batteries ont souffert et doivent être changées.

+1000

Ces onduleurs souvent... c'est comme les mauvais AV ou Doze en config
d'origine, un process se lance dans /temp, c'est 'normal', il triture et
renomme en masse les fichiers en .crypto et c'est toujours 'normal'.


Un emballement thermique dans un coffre de batterie est (normalement -
restons dans le 'normal' :) détectable,.

À minima, par le suivi de la diff temp ext et coffret et la dT de la
temp coffret, c'est quand même zarb que les sécus ne soient pas plus
pointues sur un truc aussi chaud. On peut aussi déduire des choses des
variations de paramètres chargeur et onduleur.

Ces coffres devraient être toujours ventilés et de plus  par de l'air à
la température contrôlée (15-20 degrés). On peut doubler la vie de ses
batteries par rapport à une ambiance à 30°.

On en installait dans le sahara, elles arrivaient à tenir 18 mois :>

J'ai l'impression qu'ils préfèrent les faire "étanches" pour contenir
les 'débordements'.

Surtout que ces batteries à électrolyte gélifiée, on peut pas les
contrôler visuellement (la base) et elle sont aussi plus sensibles à
l'emballement thermique que les plomb stationnaires (qui elles dégagent
de l'H mais sont visuellement contrôlables - chacune a ses problèmes).

Il existe des batteries gel plus évoluées (techno AGM de mémoire) avec
sonde de temp incorporée, j'en ai une dans les 130 Ah sur ma caisse.
Durée de la batterie : 10 ans.

Je dois pas avoir tous les éléments...

Je vais en parler à mon pote d'ECUS à l'occase - eux ils doivent être
bien au point :)

-- 
Be Seeing You
Number Six


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

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

[Clement Cavadore]

Hello,

Le samedi 13 mars 2021 à 11:40 +0100, Emmanuel DECAEN a écrit :
> Dans le carton, on voit quelques batteries gonflées et d'autres sans 
> dommage apparent:
> http://dl.free.fr/oaWpyYqQr
> http://dl.free.fr/kFoYYCSuf
> 
> Cette différence est dû au lieu d'implantation dans l'onduleur.
> Au delà de l'apparence, pour le technicien intervenu sur site,
> toutes les batteries ont souffert et doivent être changées.

J'y ai aussi eu droit, dans une autre vie, sur un onduleur de 15 ou
20kVA de mémoire. Les batteries avaient gonflé de la même manière, et
on avait dû tout changer. 

Et en plus, l'onduleur en question était sur un floor, ça aurait pu
être gravissime si ca n'avait pas été détecté avant... Surtout que le
système d'extinction incendie était inopérant (percuteurs posés à côté
des bouteilles) ! 

-- 
Clément Cavadore


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

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

[Emmanuel DECAEN]

Le 13/03/2021 à 08:47, Stéphane Rivière a écrit :

Il y a plusieurs années, nous avons subit un emballement thermique sur
un onduleur.

Quelle puissance environ ?


Un onduleur de 30 KVA.


Lorsque le technicien est arrivé sur site, il a extrait toutes les
batteries, et confirmer le diagnostic : emballement thermique suite à la
défaillance d'une batterie.

Voici une petite photo de l'état dans lequel se trouvaient les batteries:

Si t'as un lien, pour "l'édification des masses", on est pour :)


Dans le carton, on voit quelques batteries gonflées et d'autres sans 
dommage apparent:

http://dl.free.fr/oaWpyYqQr
http://dl.free.fr/kFoYYCSuf

Cette différence est dû au lieu d'implantation dans l'onduleur.
Au delà de l'apparence, pour le technicien intervenu sur site, toutes 
les batteries ont souffert et doivent être changées.


--
*Emmanuel DECAEN*

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

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

[Stéphane Rivière]

> Il y a plusieurs années, nous avons subit un emballement thermique sur
> un onduleur.

Quelle puissance environ ?

> Lorsque le technicien est arrivé sur site, il a extrait toutes les
> batteries, et confirmer le diagnostic : emballement thermique suite à la
> défaillance d'une batterie.
> 
> Voici une petite photo de l'état dans lequel se trouvaient les batteries:

Si t'as un lien, pour "l'édification des masses", on est pour :)

> Ce que nous avons retenu:
>  -> ne pas attendre un quelconque SNMP trap ou mail d'alerte de l'onduleur
>  -> mettre une marge très basse dans la supervision des batteries, du
> genre pour 21°C en moyenne, considérer l'alerte à partir de 24°C

+1000

Les anciennes batteries stationnaires (à électrolyte liquide) dégazaient
de l'hydrogène à remplir des dirigeables. Un vrai problème pour la
ventilation du local batterie.

Les batteries à électrolyte gélifiées "semblent" plus inoffensives.
Dans tous les cas, ce sont des bombes. J'ai (hélas) des d'anecdotes.

Et coté manipulation, le courant continu à 120V (même moins) est bien
plus mortel que du 440V alternatif. Changer des batteries sur certains
'petits' onduleurs dès 6/10 KVA peut être très dangereux sans formation.

Un truc "éducatif" (à ne surtout pas faire) pour s'en donner une idée,
sacrifier une batterie en fin de vie et une grosse clé plate : mettre la
batterie loin de tout, poser la clé plate sur les bornes, se barrer
(très loin). Voir la clé rougir puis la batterie exploser (plus ou moins
gracieusement en fonction de son état).

Ou sinon regarder ça, à 3 mn pour les pressés...

https://www.youtube.com/watch?v=DpQeDcEpEn0

Notez comment les câbles bougent tout seuls sous l'effet de la charge.
Vu ça sur du 20KV en fond de tranchée !!! Ça fait très bizarre...

J'en profite pour donner un truc : quand on raccorde les deux batteries
de deux bagnoles, on branche /toujours/ le (+) d'abord ! Et seulement
ensuite le (-). Et après, on débranche d'abord le (-). Des deux cotés.

-- 
Be Seeing You
Number Six


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

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

[Emmanuel DECAEN]

Bonsoir,

Le 12/03/2021 à 09:55, Clement Cavadore a écrit :

Le vendredi 12 mars 2021 à 09:45 +0100, Stéphane Rivière a écrit :

Finalement, les GE (feu, explosion), les onduleurs (feu), les salles
batteries (explosion) devraient être traités comme des dépôts de
munitions, et placés dans des îlots à l'extérieur des DC...

So true (je me suis fait la même réflexion, car les départ d'incendie
côté onduleurs, c'est pas rare).



Il y a plusieurs années, nous avons subit un emballement thermique sur 
un onduleur.


La supervision (Nagios à l'époque) a commencé par détecter un 
augmentation de quelques degrés sur les batteries de l'onduleur.

Pensant que la climatisation avait un problème, nous sommes allés voir...
Mais rien, rien du tout:
 -> la climatisation fonctionnait très bien
 -> absolument aucun signe anormal côté onduleur, pas d'alerte sur l'écran
 -> aucun signe extérieur : aucune odeur, aucune fumée

Inquiets de cette situation, l'astreinte a appelé le constructeur, et 
là, par téléphone, le technicien a tout de suite identifié le risque !
Ce dernier a fait couper immédiatement l'alimentation des batteries et 
fait passer en bypass.
Lorsque le technicien est arrivé sur site, il a extrait toutes les 
batteries, et confirmer le diagnostic : emballement thermique suite à la 
défaillance d'une batterie.


Voici une petite photo de l'état dans lequel se trouvaient les batteries:


Ce que nous avons retenu:
 -> ne pas attendre un quelconque SNMP trap ou mail d'alerte de l'onduleur
 -> mettre une marge très basse dans la supervision des batteries, du 
genre pour 21°C en moyenne, considérer l'alerte à partir de 24°C


Bon Week-End.

--
*Emmanuel DECAEN*


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

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

[Philippe Bourcier]

Bonsoir,

>> Ok donc des étages et des salles séparées ? 1 par étage ou plusieurs par 
>> étages ?
>> La question reste la même: onduleur par salle ou global en bas ?
> 
> Classiquement, tout est au niveau 0, vu le poids et pour la maintenance.

Merci de passer ce thread en MISC.


Cordialement,
--
Philippe Bourcier
web : http://sysctl.org
blog : https://www.linkedin.com/today/author/philippebourcier


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