Auteur Sujet: OVH temporairement bloqué  (Lu 396 fois)

0 Membres et 1 Invité sur ce sujet

DonPanic

  • Messages: 513
  • Boinc'eur Respectable
  • ****
  •   
    • La science à deux mains
OVH temporairement bloqué
« le: 09 novembre 2017 à 12:04 »
Bonjour

Ce matin, reçu dans ma BAL un mail où il y avait ça :
    
Pending Cancellation
FINAL NOTICE FOR DOMAIN
xxxxxxxxx.com    
Notice#: 321134
Date: 11/08/2017

FINAL NOTICE - Your account is pending cancellation

PURCHASE EXPIRATION DATE: 11/16/2017
DOMAIN: xxxxxxxxx.com
EXPIRATION OFFER SEO NOTIFICATION


Et me proposant de racheter mon nom de domaine pour la modique! somme de 86 €.

Immédiatement, je vais sur OVH où j'ai acheté, entre autres, ce nom de domaine
et ovh.com était temporairement inaccessible.

Alors je fais whois, où je vois que mon nom de domaine m'est toujours attribué, et ce jusqu'en Juillet 2018.

Question: se peut-il que ce mail soit couplé à une attaque sur OVH ?
« Modifié: 09 novembre 2017 à 12:09 par DonPanic »


DonPanic

  • Messages: 513
  • Boinc'eur Respectable
  • ****
  •   
    • La science à deux mains
Re : OVH temporairement bloqué
« Réponse #2 le: 09 novembre 2017 à 12:31 »
Merci  Zarck   :jap:

C'est donc une coïncidence, et non le fruit de mon esprit parano  :desole:

toTOW

  • Messages: 3233
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #3 le: 10 novembre 2017 à 00:08 »
Et ton mail et une tentative de phishing :D
FAH-Addict, première source d'information francophone sur le projet Folding@Home.

MortelKni

  • Messages: 42
  • P'tit Nouveau
  • *
  •   
Re : OVH temporairement bloqué
« Réponse #4 le: 10 novembre 2017 à 07:04 »
Tout semble revenu depuis hier après-midi, et les infos sont là :

http://travaux.ovh.net/?do=details&id=28247

Avec le "plus" important :

Citer
Bonjour,
Ce matin à 7h23, nous avons eu une panne majeure sur notre site de Strasbourg (SBG) : une coupure électrique qui a mis dans le noir nos 3 datacentres SBG1, SBG2 et SBG4 durant 3h30. Le pire scénario qui puisse nous arriver.

Le site de SBG est alimenté par une ligne électrique de 20KVA composée de 2 câbles qui délivrent chacun 10MVA. Les 2 câbles fonctionnent ensemble, et sont connectés à la même source et sur le même disjoncteur chez ELD (Strasbourg Électricité Réseaux). Ce matin, l’un des 2 câbles a été endommagé et le disjoncteur a coupé l’alimentation des datacentres.

Le site SBG est prévu pour fonctionner, sans limite de temps, sur les groupes électrogènes. Pour SBG1 et SBG4, nous avons mis en place, un premier système de 2 groupes électrogènes de 2MVA chacun, configurés en N+1 et en 20KV. Pour SBG2, nous avons mis en place 3 groupes en N+1 de 1.4MVA chacun. En cas de coupure de la source externe, les cellules haute tension sont reconfigurées automatiquement par un système de bascule motorisé. En moins de 30 secondes, les datacentres SBG1, SBG2 et SBG4 sont ré-alimentés en 20KV. Pour permettre toutes ces bascules sans couper l’alimentation électrique des serveurs, nous disposons d’onduleurs (UPS) sachant fonctionner sans aucune alimentation durant 8 minutes.

Ce matin, le système de basculement motorisé n’a pas fonctionné. L’ordre de démarrage des groupes n’a pas été donné par l’automate. Il s’agit d’un automate NSM (Normal Secours Motorisé), fournit par l’équipementier des cellules haute-tension 20KV. Nous sommes en contact avec lui, afin de comprendre l’origine de ce dysfonctionnement. C’est toutefois un défaut qui aurait dû être détecté lors des tests périodiques de simulation de défaut sur la source externe. Le dernier test de reprise de SBG sur les groupes date de la fin du mois mai 2017. Durant ce dernier test, nous avons alimenté SBG uniquement à partir des groupes électrogènes durant 8H sans aucun souci et chaque mois nous testons les groupes à vide. Et malgré tout, l’ensemble de ce dispositif n’a pas suffi aujourd’hui pour éviter cette panne.

Vers 10h, nous avons réussi à basculer les cellules manuellement et nous avons recommencé à alimenter le datacentre à partir des groupes électrogènes. Nous avons demandé à ELD de bien vouloir déconnecter le câble défectueux des cellules haute tension et remettre le disjoncteur en marche avec 1 seul des 2 câbles, et donc limité à 10MVA. La manipulation a été effectuée par ELD et le site a été ré-alimenté vers 10h30. Les routeurs de SBG ont été joignables à partir de 10h58.

Depuis, nous travaillons, sur la remise en route des services. Alimenter le site en énergie permet de faire redémarrer les serveurs, mais il reste à remettre en marche les services qui tournent sur les serveurs. C’est pourquoi chaque service revient progressivement depuis 10h58. Notre système de monitoring nous permet de connaitre la liste de serveurs qui ont démarré avec succès et ceux qui ont encore un problème. Nous intervenons sur chacun de ces serveurs pour identifier et résoudre le problème qui l’empêche de redémarrer.

A 7h50, nous avons mis en place une cellule de crise à RBX, où nous avons centralisé les informations et les actions de l’ensemble des équipes. Un camion en partance de RBX a été chargé de pièces de rechange pour SBG. Il est arrivé à destination vers 17h30. Nos équipes locales ont été renforcées par des équipes du datacentre de LIM en Allemagne et de RBX, ils sont tous mobilisés sur place depuis 16H00. Actuellement, plus de 50 techniciens travaillent à SBG pour remettre tous les services en route. Nous préparons les travaux de cette nuit et, si cela était nécessaire, de demain matin.

Prenons du recul. Pour éviter un scénario catastrophe de ce type, durant ces 18 dernières années, OVH a développé des architectures électriques capables de résister à toutes sortes d’incidents électriques. Chaque test, chaque petit défaut, chaque nouvelle idée a enrichi notre expérience, ce qui nous permet de bâtir aujourd’hui des datacentres fiables.

Alors pourquoi cette panne ? Pourquoi SBG n’a pas résisté à une simple coupure électrique d’ELD ? Pourquoi toute l’intelligence que nous avons développée chez OVH, n’a pas permis d’éviter cette panne ?

La réponse rapide : le réseau électrique de SBG a hérité des imperfections de design liées à la faible ambition initialement prévue pour le site.

La réponse longue :
En 2011, nous avons planifié le déploiement de nouveaux datacentres en Europe. Pour tester l’appétence de chaque marché, avec de nouvelles villes et de nouveaux pays, nous avons imaginé une nouvelle technologie de déploiement de datacentres, basée sur les containers maritimes. Grâce à cette technologie, développée en interne, nous avons voulu avoir la souplesse de déployer un datacentre sans les contraintes de temps liées aux permis de construire. A l’origine, nous voulions avoir la possibilité de valider nos hypothèses avant d’investir durablement dans un site.

C’est comme ça que début 2012, nous avons lancé SBG avec un datacentre en containers maritimes : SBG1. Nous avons déployé 8 containers maritimes et SBG1 a été opérationnel en seulement 2 mois. Grâce à ce déploiement ultra rapide, en moins de 6 mois nous avons pu valider que SBG est effectivement un site stratégique pour OVH. Fin 2012, nous avons décidé de construire SBG2 et en 2016, nous avons lancé la construction de SBG3. Ces 2 constructions n’ont pas été faites en containers, mais ont été basées sur notre technologie de « Tour » : la construction de SBG2 a pris 9 mois et SBG3 sera mis en production dans 1 mois. Pour pallier aux problèmes de place début 2013, nous avons construit très rapidement SBG4, l’extension basée encore sur les fameux containers maritimes.

Le problème est qu’en déployant SBG1 avec la technologie basée sur les containers maritimes, nous n’avons pas préparé le site au large scale. Nous avons fait 2 erreurs :
1) nous n’avons pas remis le site SBG aux normes internes qui prévoient 2 arrivées électriques indépendantes de 20KV, comme tous nos sites de DCs qui possèdent plusieurs doubles arrivées électriques. Il s’agit d’un investissement important d’environ 2 à 3 millions d’euros par arrivée électrique, mais nous estimons que cela fait partie de notre norme interne.
2) nous avons construit le réseau électrique de SBG2 en le posant sur le réseau électrique de SBG1, au lieu de les rendre indépendant l’un de l’autre, comme dans tous nos datacentres. Chez OVH, chaque numéro de datacentre veut dire que le réseau électrique est indépendant d’un autre datacentre. Partout sauf sur le site de SBG.

La technologie basée sur les containers maritimes n’a été utilisée que pour construire SBG1 et SBG4. En effet, nous avons réalisé que le datacentre en containers n’est pas adapté aux exigences de notre métier. Avec la vitesse de croissance de SBG, la taille minimale d’un site est forcément de plusieurs datacentres, et donc d’une capacité totale de 200.000 serveurs. C’est pourquoi, aujourd’hui, pour déployer un nouveau datacenter, nous n’utilisons plus que 2 types de conceptions largement éprouvées et prévues pour le large scale avec de la fiabilité :
1) la construction de tours de 5 à 6 étages (RBX4, SBG2-3, BHS1-2), pour 40.000 serveurs.
2) l’achat des bâtiments (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) pour 40.000 ou 80.000 serveurs.

Même si l’incident de ce matin a été causé par un automate tiers, nous ne pouvons nous dédouaner de la responsabilité de la panne. A cause du déploiement initial basé sur les containers maritimes, nous avons un historique à rattraper sur SBG pour atteindre le même niveau de normes que sur les autres sites d’OVH.

Cet après-midi, nous avons décidé du plan d’actions suivant :
1) la mise en place de la 2ème arrivée électrique, totalement séparée, de 20MVA ;
2) la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4, ainsi que la séparation du futur SBG3 vis-à-vis de SBG2 et SBG1/SBG4;
3) la migration des clients de SBG1/SBG4 vers SBG3 ;
4) la fermeture de SBG1/SBG4 et la désinstallation des containers maritimes.

Il s’agit d’un plan d’investissement de 4-5 millions d’euros, que nous mettons en route dès demain, et qui, nous l’espérons, nous permettra de restaurer la confiance de nos clients envers SBG et plus largement OVH.

Les équipes sont toujours en train de travailler sur la remise en route des derniers clients impactés. Une fois l’incident clos, nous appliquerons les SLA prévus dans nos contrats.

Nous sommes profondément désolés pour la panne générée et nous vous remercions des encouragements que vous nous témoignez durant cet incident.

Amicalement
Octave

Et pour RBX :

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

Citer
Bonjour,
Ce matin, nous avons eu un incident sur le réseau optique qui interconnecte notre site de Roubaix (RBX) avec 6 des 33 points de présence (POP) de notre réseau : Paris (TH2 et GSW), Francfort (FRA), Amsterdam (AMS), London (LDN), Bruxelles (BRU).

Le site RBX est connecté à travers 6 fibres optiques à ces 6 POP : 2x RBX<>BRU, 2x RBX<>LDN, 2x RBX<>Paris (1x RBX<>TH2 et 1x RBX<>GSW). Ces 6 fibres optiques sont connectées aux systèmes de nœuds optiques qui permettent d’avoir 80 longueurs d’onde de 100Gbps sur chaque fibre optique.

Pour chaque 100G connectés aux routeurs, nous utilisons 2 chemins optiques qui sont géographiquement distincts. En cas de coupure de fibre optique, le fameux « coup de pelleteuse », le système se reconfigure en 50ms et tous les liens restent UP. Pour connecter RBX aux POP, nous avons 4.4Tbps de capacité, 44x100G : 12x 100G vers Paris, 8x100G vers London, 2x100G vers Bruxelles, 8x100G vers Amsterdam, 10x100G vers Frankfurt, 2x100G vers DC GRA et 2x100G vers DC SBG.

A 8h01, d’un coup, l’ensemble des liens 100G, les 44x 100G, ont été perdus. Étant donné le système de redondance que nous avons mis en place, l’origine du problème ne pouvait pas être la coupure physique de 6 fibres optiques simultanément. Nous n’avons pas pu faire les diagnostiques sur les châssis à distance car les interfaces de management étaient figées. Nous avons été obligés d’intervenir directement dans les salles de routage, pour faire les manipulations sur les châssis : déconnecter les câbles entre les châssis puis faire redémarrer le système et enfin seulement faire les diagnostiques avec l’équipementier. Les tentatives de redémarrage du système ont pris beaucoup de temps, car chaque châssis a besoin de 10 à 12 minutes pour démarrer. C’est la principale raison de la durée de l’incident.

Le diagnostique : Toutes les cartes transpondeurs que nous utilisons, ncs2k-400g-lk9, ncs2k-200g-cklc, sont passées en état « standby ». L’une des origines possible d’un tel état est la perte de configuration. Nous avons donc récupéré le backup et remis en place la configuration, ce qui a permis au système de reconfigurer toutes les cartes transpondeurs. Les 100G dans les routeurs sont revenus naturellement et la connexion de RBX vers les 6 POP a été rétablie à 10h34.

Il s’agit clairement d’un bug software sur les équipements optiques. La base de données avec la configuration est enregistrée 3 fois et copiée sur 2 cartes de supervision. Malgré toutes ces sécurités, la base a disparu. Nous allons travailler avec l’équipementier pour trouver l’origine du problème et les aider à fixer le bug. Nous ne remettons pas en cause la confiance avec l’équipementier, même si ce type de bug est particulièrement critique. L’uptime est une question de design qui prend en compte tous les cas de figure, y compris quand plus rien ne marche. Le mode parano chez Ovh doit être poussé encore plus loin dans l’ensemble de nos designs.

Les bugs ça peut exister, les incidents qui impactent nos clients non. Il y a forcement une erreur chez Ovh puisque malgré tous les investissements dans le réseau, dans les fibres, dans les technologies, nous venons d’avoir 2 heures de downtime sur l’ensemble de nos infrastructures à Roubaix.

L’une des solutions est de créer 2 systèmes de nœuds optiques au lieu d’un seul. 2 systèmes, cela veut dire 2 bases de données et donc en cas de perte de la configuration, un seul système est en panne. Si 50% des liens passent par l’un des systèmes, aujourd’hui, nous aurions perdu 50% de la capacité mais pas 100% de liens. C’est l’un des projets que nous avons commencé il y a 1 mois, les châssis ont été commandés et nous allons les recevoir dans les prochains jours. Nous pourrons commencer les travaux de configuration et migration sous 2 semaines. Vu l’incident d’aujourd’hui, ce projet devient prioritaire, pour l’ensemble de nos infrastructures, tous les DCs, tous les POPs.

Dans le métier de fournisseur des infrastructures Cloud, seul ceux qui sont paranos durent. La qualité de service est une conséquence de 2 éléments. Tous les incidents anticipés « by design ». Et les incidents où nous avons appris de nos erreurs. Cet incident là nous amène à mettre la barre encore plus haut pour s’approcher du risque zéro.

Nous sommes sincèrement désolés pour les 2H33 minutes de downtime sur le site RBX. Dans les prochains jours, les clients impactés vont recevoir un email pour déclencher l’application des engagements SLA.

Amicalement
Octave

Dans le genre pas de bol ...
« Modifié: 10 novembre 2017 à 07:10 par MortelKni »

Fixe : i7 6700k, GTX 970, 16GB ram, W10
Port. : Dell Latitude E5540 2015, Debian 9 x64

modesti

  • CàA
  • Messages: 14195
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #5 le: 10 novembre 2017 à 08:12 »
Merci pour les infos, MortelKni :jap:
C'était la journée de Murphy hier

Viendez chez nous, cause qu'on est les meilleur(e)s :D


In memoriam Jip

Matt11

  • Messages: 551
  • Boinc'eur Respectable
  • ****
  •   
Re : OVH temporairement bloqué
« Réponse #6 le: 10 novembre 2017 à 11:11 »
C'est rare qu'une entreprise assume ses fautes à ce point et soit aussi transparente. Chapeau pour la communication.

Ubuntu Mate 16.04  Intel core i7 6700K 4x4.0GHz 16Gb Nvidia Geforce GTX 1070

PhilTheNet

  • Messages: 1742
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #7 le: 10 novembre 2017 à 13:38 »
Maintenant j'attends la ristourne....  :gniak:


Le petit dernier :

JeromeC

  • CàA
  • Messages: 19975
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #8 le: 10 novembre 2017 à 16:25 »
Vive les SLA :D
Parce que c'était lui, parce que c'était moi.

[AF] fansyl

  • Messages: 1457
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #9 le: 10 novembre 2017 à 18:29 »
Beaucoup d'entreprises devraient s'inspirer de la communication, de la transparence et de la prise de décision !
C'est tellement inhabituel alors que cela devrait être la norme !
 :hello:
Je crunche dans le silence et c'est ma joie !
i7-3770K/16Go/GTX970 (sous WC) - i7-3770T/16Go/HD4000 - Q9550/4Go/GT1030 - Ryzen 5 1400/8Go/GTX1050


MortelKni

  • Messages: 42
  • P'tit Nouveau
  • *
  •   
Re : OVH temporairement bloqué
« Réponse #10 le: 10 novembre 2017 à 18:40 »
Faut dire qu'ils avaient pas trop intérêt à se planter, a la dernière panne ils ont pas vraiment bien communiqués.

Mais visiblement le mea culpa d'Octave a été pris en compte cette fous-ci, ça fait plaisir !

EDIT : Màj récente détaillée des problèmes de Roubaix

Citer
Incident optique sur Roubaix du 09/11/2017

Résumé de l'incident :
• 8h00 : Toutes les liens 100G au DC de Roubaix sont down.
• 8h15 : Impossible de se connecter au nœud
• 8h40 : Nous redémarrons électriquement le châssis maitre.
• 9h00 : Toujours impossible de récupérer la main sur le nœud
• 9h15 : Nous décâblons tout le management du nœud
• 9h30 : Nous réussissons à récupérer la main sur Roubaix
• 9h40 : On voit tous les châssis mais aucune alarme sur le châssis et la configuration des circuits a disparu
• 10h00 : On injecte le dernier backup de la database sur le nœud
• 10h15 : Les circuits commencent à remonter
• 10h30 : La plupart des circuits sont up, il en reste 8 down
• 11h00 : Certains transpondeurs ne sont pas vu par le système, et un ampli est HS, on lance le RMA de l'ampli
• 11h30 : On reset tous les transpondeurs non reconnu, tous les circuits sont up
• 14h15 : On effectue le remplacement de l'ampli
• 14h30 : Tous les circuits sont up, les protections fonctionnelles et les dernières alarmes fixées.



Explication :
D’après les logs récoltés sur tous les châssis du nœud de Roubaix (20), il apparait que nous avons eu 3 phénomènes en cascade sur le noeud de Roubaix :

1. Surcharge du CPU du Node Controller (châssis maitre)
Chaque nœud optique a un châssis maitre qui permet d'échanger les informations entre les nœuds et permet d'échanger avec ses châssis slaves. Sur ce châssis maitre est sauvegardé la database sur 2 cartes controllers et le LCD.
A partir de 7h50, on remarque que Roubaix commence à avoir des problèmes de communication avec les nœuds directement connectés à lui et montrer une surcharge CPU du châssis maitre. Aujourd'hui, nous n'avons pas encore la cause de cette surcharge du CPU. Malgré le down de SBG plus tôt, nous examinons toutes les pistes. Les équipes du constructeur investiguent encore sur cette cause. Nous avons un call samedi 11 novembre pour en savoir plus.

2. Switchover en cascade
Suite à la surcharge du CPU du node, le châssis maitre a effectué un switchover des cartes controller. Après le premier switchover des controllers et la surcharge du CPU, nous sommes tombé sur un bug soft connu de Cisco. Ce bug arrive sur les gros nœuds et a pour conséquence de faire un switchover des controllers toutes les 30 secondes. En temps normal ce switch over se stabilise seul. Ce bug est fixé en release 10.8 qui sera disponible à partir du 31/11

3. Perte de la database
A 8h00, suite aux switchover en cascade, nous sommes tombé sur un autre bug soft qui est une désynchro du timing entre les 2 cartes controllers du chassis maitre. Ce bug a provoquer l'envoi d'une commande disant aux cartes controller de mettre la database à 0. Les cartes controllers du châssis maitre ont donc envoyées cette nouvelle information aux châssis slaves ce qui a fait perdre tous les liens 100G de Roubaix. Ce bug est fixé en release 10.7 qui est actuellement disponible.



Plan d'action :
Voici le plan d'action que l'on va mettre en place avec les conseils du constructeur:

• Il y a 2 semaines, nous avons lancé le remplacer les cartes controllers de Roubaix et Gravelines par des TNCS (au lieu de TNCE) qui ont le double de puissance CPU et le double de RAM. Nous avons reçu les 2 premières hier pour Roubaix et nous allons faire le swap rapidement, après avoir eu la procédure du constructeur.(Semaine du 13 Novembre). Nous allons pousser le remplacement des Controllers sur les noeuds de Strasbourg et Frankfort aussi.
• Nous faisons l'upgrade software de tous les nœuds pour aller en 10.8
• Aujourd'hui nous somme en version 10.5.2.6, nous devons passer par une version intermédiaire 10.5.2.7 pour pouvoir aller en 10.7 ou 10.8 ensuite
• Nous effectuons un split des gros nœuds (POP/DC) pour avoir au moins 2 nodes controllers par POP/DC

En résumé :
• Step 1 : Remplacement des TNCE sur RBX/GRA (ETA possible: lundi 13/11 soir pour RBX, mardi 14/11 soir pour GRA)
• Step 2 : Upgrade Software en 10.8 (ETA possible: 4 semaines)
• Step 3 : Split des gros noeuds (ETA: à étudier. Il faut décider la stratégie, établir le protocole précis puis faire la roadmap)



Stratégie possible pour le split :
Il est possible de splitter complètement le réseau en 2 réseaux indépendants et étanches au niveau du management (avec toujours la possible de re-splitter les nodes à l'intérieur même de chaque réseau). Avec une répartition "smart" des lignes optiques entre 2 réseaux "red" et "blue", chaque DC peut joindre chaque POP en direct par chacun des 2 réseaux distincts.


cf http://travaux.ovh.net/?do=details&id=28244
« Modifié: 10 novembre 2017 à 21:03 par MortelKni »

Fixe : i7 6700k, GTX 970, 16GB ram, W10
Port. : Dell Latitude E5540 2015, Debian 9 x64

GuL

  • Messages: 1145
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : Re : OVH temporairement bloqué
« Réponse #11 le: 12 novembre 2017 à 15:07 »
Beaucoup d'entreprises devraient s'inspirer de la communication, de la transparence et de la prise de décision !
C'est tellement inhabituel alors que cela devrait être la norme !
 :hello:
:plusun:

nabz

  • Animateur fanatique
  • Messages: 4571
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #12 le: 12 novembre 2017 à 15:29 »
Perte des 2 sources électriques externes, non démarrage des sources de secours, bah ça commence comme Fukushima mais ça se termine mieux !
Contrôle de BOINC : SAM - BoincTasks 1.73 - TThrottle 7.52 - TeamViewer 12.0
Calculs : Boinc 7.8.2 SF - VirtualBox 5.1.28 - Pilote Ati 17.3 - Pilote nVidia 385.28
OS et utilitaires : Win 10 x86/64 - Core Temp 1.10 - CCleaner 5.34 - DriverSweeper 3.1

PhilTheNet

  • Messages: 1742
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #13 le: 14 novembre 2017 à 12:32 »
3 serveurs en carafe durant toute une matinée (et pas 2h comme annoncé par OVH) et des coupures aléatoires jusqu'au lendemain :

Mes compensations

Vous n'avez droit à aucune compensation.


Ca donne envie...


 :D


Le petit dernier :

DonPanic

  • Messages: 513
  • Boinc'eur Respectable
  • ****
  •   
    • La science à deux mains
Re : Re : OVH temporairement bloqué
« Réponse #14 le: 14 novembre 2017 à 14:17 »
3 serveurs en carafe durant toute une matinée (et pas 2h comme annoncé par OVH) et des coupures aléatoires jusqu'au lendemain :

Mes compensations

Vous n'avez droit à aucune compensation.


Ca donne envie...

Je n'ai que des noms de domaine chez OVH, j'ai PHPNET comme hébergeur, en cas de pépins, ils refilent des points fidélité avec petites réducs sur les achats.

JeromeC

  • CàA
  • Messages: 19975
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #15 le: 14 novembre 2017 à 14:27 »
3 serveurs en carafe durant toute une matinée (et pas 2h comme annoncé par OVH) et des coupures aléatoires jusqu'au lendemain :

Mes compensations

Vous n'avez droit à aucune compensation.


Ca donne envie...


 :D
T'avais qu'à prendre un contrat plus cher avec des SLA plus gros :D
Parce que c'était lui, parce que c'était moi.

Matt11

  • Messages: 551
  • Boinc'eur Respectable
  • ****
  •   
Re : OVH temporairement bloqué
« Réponse #16 le: 14 novembre 2017 à 19:23 »
J'ai reçu 12% du prix de ma location mensuelle sur un serveur Kimsufi (bon pour moi ça fait 0.66€  :hyperbon: )

Ubuntu Mate 16.04  Intel core i7 6700K 4x4.0GHz 16Gb Nvidia Geforce GTX 1070

Sébastien

  • Gentil admin
  • Messages: 1915
  • Boinc'eur devant l'éternel
  • *******
  •   
Re : OVH temporairement bloqué
« Réponse #17 le: 14 novembre 2017 à 19:38 »
J'ai aussi reçu 12% du prix de la location mensuelle pour 2 heures d'indisponibilité.

JeromeC

  • CàA
  • Messages: 19975
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #18 le: 15 novembre 2017 à 00:05 »
C'est plutôt "bien payé" au final, même si la coupure a plutôt duré 1 voire 1/2 journée pour que tout revienne à la normale, ça fait bien plus que 1/30.
Parce que c'était lui, parce que c'était moi.

Sébastien

  • Gentil admin
  • Messages: 1915
  • Boinc'eur devant l'éternel
  • *******
  •   

PhilTheNet

  • Messages: 1742
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #20 le: 16 novembre 2017 à 07:51 »
Ben moi c'est 0% x3 serveurs => 2 serveurs résiliés

 :D


Le petit dernier :

toTOW

  • Messages: 3233
  • Boinc'eur devant l'éternel
  • *****
  •   
Re : OVH temporairement bloqué
« Réponse #21 le: 19 novembre 2017 à 03:01 »
Au final, j'ai eu 4 jours de location offerts sur mon KS ... :)
FAH-Addict, première source d'information francophone sur le projet Folding@Home.