Auteur Sujet: Comment éteindre un datacenter proprement?  (Lu 20204 fois)

0 Membres et 1 Invité sur ce sujet

Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 673
  • Grenoble (38) @Optrolight
    • Optroastro
Comment éteindre un datacenter proprement?
« Réponse #12 le: 01 novembre 2012 à 14:09:07 »
Simple question de dépendances.

Une application X tournant sur un serveur A peut avoir besoin de la base de données Y tournant sur le serveur B, et du partage de fichiers Z offert par le serveur C.
Un serveur qui a ses disques sur le SAN ne peut démarrer qu'une fois que la baie de disques correspondante et les switches sont opérationnels.

C'est exactement ça !! ;)

Et prévoir dans les fichiers de boot les signaux pour que chaques machines démarre quand c'est son tour est complexe et demande énormèment de temps.
Pour rappel on est sur une architecture d'un labo de recherche. Il y a donc des machines très disparates et il est parfois plus rapide de rebooter à la main les machines que de passer des semaines à tout paramétrer.

seb

  • Pau Broadband Country (64)
  • Abonné SFR fibre FttH
  • *
  • Messages: 515
  • FTTH 1 Gbps sur Pau (64)
Comment éteindre un datacenter proprement?
« Réponse #13 le: 01 novembre 2012 à 15:02:33 »
Franchement, d'après ce que vous me dites, j'ai l'impression que ce genre d'installation est mal conçue, mal paramétrée. Ne peut-on pas paramétrer un OS pour qu'il attende le DNS avant d'aller plus loin? Ou qu'il retente indéfiniment?
Si tu as un contrôle total sur le système, tu pourrais.
Mais tu sembles oublier que les salles informatiques hébergent généralement des systèmes très hétérogènes, avec certaines "network appliances" totalement fermées.

Je doute fort que chez Google, Facebook ou autre, les opérateurs doivent ralumer les serveurs à la main. Ca doit être automatisé un maximum.
Je ne sais pas pour FesseBouc, mais Google conçoit ses propres machines et les équipe de son propre OS.
C'est très différent du cas d'une salle machines conventionnelle.

Pareil, pour le délai de 1 journée pour allumer/éteindre un "système complexe". Est-ce acceptable?
Acceptable ou pas, il est des situations où on n'a pas franchement le choix, hein ...

Si une société perd ses e-mails pendant une journée entière, ou sa base de donnée client pendant 1 journée entière, tout ça à cause d'une défaillance (coupure de courant en aval des onduleurs) qui n'a duré que quelques minutes... vous trouvez ça acceptable? Moi, non! J'ai déjà vécu dans ma boite des coupures d'1 ou 2h, et c'est déjà la fin du monde. Je n'imagine même pas si ça dure 1 journée entière.
La partie "business critical" d'un SI est normalement sécurisée et/ou redondée sur (au moins) un autre site ; tu dois donc pouvoir arrêter une salle machine sans interrompre la production.
Et la disponibilité d'un SI dépend essentiellement des contraintes que l'entreprise se pose à elle même, et surtout ! surtout ! surtout ! des moyens qu'elle accepte de mettre en œuvre pour les tenir.

On ne fait pas de la haute disponibilité en "six neuf" (moins de 32 secondes d'indisponibilité par an) avec des bouts de ficelle, mais avec des montagnes de billets ...

miky01

  • Expert. Réseau RESO-LIAin (01)
  • Abonné K-Net
  • *
  • Messages: 3 829
  • Farges (01)
Comment éteindre un datacenter proprement?
« Réponse #14 le: 01 novembre 2012 à 18:04:40 »
as de la haute disponibilité en "six neuf" (moins de 32 secondes d'indisponibilité par an) avec des bouts de ficelle, mais avec des montagnes de billets ...

+1

Avoir 99% de uptime c'est cher, 99.9% tu mutilplie le prix par 50x....

Citation de: leon_m
Pareil, pour le délai de 1 journée pour allumer/éteindre un "système complexe". Est-ce acceptable? Si une société perd ses e-mails pendant une journée entière, ou sa base de donnée client pendant 1 journée entière, tout ça à cause d'une défaillance (coupure de courant en aval des onduleurs) qui n'a duré que quelques minutes... vous trouvez ça acceptable? Moi, non!

Tout dépend des besoins du clients, un client qui peux pas se permettre un redémarage de 1 ou 2 heures fait de la redondance autant pour le storage que les systmes, ou les applics basculent de l'un a l'autre en moins d'une minute, les données sont accessible sur 2 bays de storage qui sont synchrone, tu as des applics sous unix, comme serviceguard, qui font ca tres bien, et si tu veux encore plus fiable, tu réplique sur 2 sites différents.

Quand je dis que ces bays ne s'arrete jamais, tout peux se remplacer online, tout est redondant, et si tu déménage, effectivement la tu l'arrete, mais la c'est pas une heure de redémarage, c'est une semaine, pour certain, le fait de déplacer la bay, t'oblige a tout reformater et restorer les données... et je t'assure que des volumes pareils, c'est une semaine de synchronisation.

Maintenant dans une boite, si 50 secrétaires ont plus d'email pour une journée, c'est pas tres grave en comparaisons d'autres activités, j'avais comme client un opérateur GSM, je peux t'assurer que les serveurs qui gèrent toute la facturation des cartes prepayée, ne sont jamais down, meme en cas d'incendie dans une des salle, car la les pertes se chiffrent en milliers d'€ a la seconde, pareil pour les serveurs dans les grosses banques, la aussi j'avais un client qui avait tout redondant sur 3 sites, dans 3 villes différentes, donc meme avec un site détruit par un tremblement de terre, l'interruption de service ne dépasse pas qques minutes, mais j'ose pas de dire ce que coute ce genre de redondance, les sommes sont astronomiques.

Pour l'infrastructure d'un data center, tout doit etre redondant, les clims, les ups, les alims et le réseau, avec 2 points d'alimentations et 2 acces fibres qui se trouvent a l'oposé du batiment.

Le seul cas de gros datacenter que je connais, ou tout est arreté volontairement pendant une semaime, c'est ceux du CERN, ou tout est arreté pendant la periode Noel, mais le redémarage c'est aussi plusieurs jours de boulot.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
Comment éteindre un datacenter proprement?
« Réponse #15 le: 01 novembre 2012 à 19:16:42 »
Avoir 99% de uptime c'est cher, 99.9% tu mutilplie le prix par 50x....
Je comprends bien le principe, mais je pense que l'ordre de gandeur n'est pas bon. 99%, c'est très mauvais, comme uptime. J'avais un petit serveur hébergé chez moi, et il annonçait en moyenne 99.9% d'uptime (mesure comprenant connexion et alimentation, effectuée toutes les 30 sec), tout ça derrière une connexion ADSL, et sans onduleur. Je n'ose pas imaginer qu'un datacenter propose moins de 99.9%.

Citer
mais j'ose pas de dire ce que coute ce genre de redondance, les sommes sont astronomiques.
Une autre remarque par rapport aux "sommes astronomiques". J'ai bien vu que les systèmes "haute disponibilité" se payent avec des chiffres qui font peur. Les SAN, etc...
Mais j'ai vraiment l'impression qu'on peut faire tout ça à moindre frais, par du logiciel. C'est d'ailleurs ce que semble faire Google et Facebook. Les serveurs de ces 2 géants là sont apparemment alimentés avec 1 seul alim, non redondante, via 1 seul "feed". Visiblement, la perte d'un serveur n'est pas si grave que ça, tout continue à fonctionner de manière nominale.



J'ai d'autres interrogations, je dérive moi même de mon propre sujet.
Je parle de bays de storage comme les EMC, HP, Hitachi, qui peuvent faire jusqu'a 256 Pb (256 000 000 Gb) avec une 100ene de ports FCoE
De même, je ne comprends pas forcèment l'intérêt des énormes systèmes de fichiers sur des SAN. On a ça dans ma grosse boite. Je sais par exemple que le gros filer (serveur de fichier) Netapp a des "partitions" énormes, dont la plus grosse fait un peu moins de 1Po! Or, cette partition ne fait qu'héberger des fichiers CAO dont le plus gros ne doit pas dépasser 1Go! Quel est l'intérêt de laisser ça sur 1 seul système? C'est forcèment plus cher et plus complexe à gérer que si on avait une dizaine/centaine de filers de 10To chacun... Si quelqu'un peut m'expliquer l'intérêt. On m'a toujours appris qu'il fallait "diviser pour mieux regner".
De même, quel est l'intérêt de continuer aujourd'hui à déployer du "fiber chanel" sur de nouveaux équipements, alors que l'Ethernet fait aussi bien en terme de perfo, tout en étant infiniment moins cher?

Leon.

seb

  • Pau Broadband Country (64)
  • Abonné SFR fibre FttH
  • *
  • Messages: 515
  • FTTH 1 Gbps sur Pau (64)
Comment éteindre un datacenter proprement?
« Réponse #16 le: 01 novembre 2012 à 20:25:55 »
Je comprends bien le principe, mais je pense que l'ordre de gandeur n'est pas bon. 99%, c'est très mauvais, comme uptime. J'avais un petit serveur hébergé chez moi, et il annonçait en moyenne 99.9% d'uptime (mesure comprenant connexion et alimentation, effectuée toutes les 30 sec), tout ça derrière une connexion ADSL, et sans onduleur. Je n'ose pas imaginer qu'un datacenter propose moins de 99.9%.
On ne parle pas de l'uptime d'un ordinateur personnel qui fait serveur web, là, mais de celui d'un (bout de) système d'information d'entreprise au complet.
Devoir rebooter un serveur Windows une fois par mois pour appliquer des patches de sécurité, c'est du downtime.
Devoir arrêter une base de données pour mettre à jour son moteur, ou la sauvegarder, c'est du downtime.

Même si l'infrastructure en face était disponible à 100% ...

Une autre remarque par rapport aux "sommes astronomiques". J'ai bien vu que les systèmes "haute disponibilité" se payent avec des chiffres qui font peur. Les SAN, etc...
Mais j'ai vraiment l'impression qu'on peut faire tout ça à moindre frais, par du logiciel. C'est d'ailleurs ce que semble faire Google et Facebook. Les serveurs de ces 2 géants là sont apparemment alimentés avec 1 seul alim, non redondante, via 1 seul "feed". Visiblement, la perte d'un serveur n'est pas si grave que ça, tout continue à fonctionner de manière nominale.
La perte d'un serveur chez Google/Facebook n'a aucune incidence, puisqu'ils utilisent une architecture logicielle massivement distribuée, conçue expressèment pour ça.
Et ça ne coûte pas cher non plus, parce que c'est conçu pour être "jetable".

Une startup peut s'amuser à concevoir son SI de zéro, mais une entreprise classique ne va jurer que par des solutions éprouvées, qui lui donnent l'assurance d'avoir un support technique en cas de problème (et le paiement de lourdes pénalités en cas de non respect des clauses contractuelles).

Je sais par exemple que le gros filer (serveur de fichier) Netapp a des "partitions" énormes, dont la plus grosse fait 1Po! Or, cette partition ne fait qu'héberger des fichiers CAO dont le plus gros ne doit pas dépasser 1Go! Quel est l'intérêt de laisser ça sur 1 seul système? C'est forcèment plus cher et plus complexe à gérer que si on avait une dizaine/centaine de filers de 10To chacun...
Tes partitions sont en fait des volumes RAID, mais passons.

Un gros filer de 1 Po n'est pas forcèment plus cher que 100 petits de 10 To.
Et un seul filer, c'est certainement beaucoup moins lourd à gérer pour les administrateurs stockage, que cent petits.

Un truc qui t'échappe peut être, c'est qu'en stockage, la volumétrie ne fait pas tout.
Le gros des performances est issu de la capacité du système de stockage à enquiller les opérations d'E/S par seconde (IOPS).
Chaque disque dur ne pouvant en prendre qu'un nombre fini à sa charge, tu ne peux augmenter les performances qu'en multipliant les disques.

Bref, ce n'est peut être pas parce qu'ils avaient besoin de 1 Po de volumétrie utile qu'ils ont choisi ce filer dans ta boîte, mais parce qu'ils avaient besoin des IOPS fournis par 200 disques de 500 To.

De même, quel est l'intérêt de continuer aujourd'hui à déployer du "fiber chanel" sur de nouveaux équipements, alors que l'Ethernet fait aussi bien en terme de perfo, tout en étant infiniment moins cher?
Aussi performant et infiniment moins cher ?
Je pense, sans trop de risque de me tromper, que tu te fourres le doigt dans l’œil jusqu'au coude ...

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Comment éteindre un datacenter proprement?
« Réponse #17 le: 01 novembre 2012 à 20:44:36 »
Regardez les pannes sur les HLR, les grosses base de données qui savent où sont localisés tous les mobile d'un opérateur

Bouygues Telecom : panne le 17 novembre 2004
SFR : panne le 6 octobre 2008
Orange : panne le 6 juillet 2012

C'est sécurisé au maximum (tout est triplé sur chaque site et il y a deux sites avec des HLR) mais en cas de panne le chargement de la base de donnée pour repartir sur une sauvegarde prend de nombreuses heures.

Personne n'a trouvé de moyen pour repartir rapidement alors que pendant ce temps c'est tout le réseau de l'opérateur qui est down (remarque, cela permet de la pub au journal de 20h par contre pas sur que la pub soit positive  ;D)

cali

  • Officiel Ukrainian Resilient Data Network
  • Fédération FDN
  • *
  • Messages: 2 401
    • Ukrainian Resilient Data Network
Comment éteindre un datacenter proprement?
« Réponse #18 le: 01 novembre 2012 à 20:47:26 »
Chez nous il arrive d'avoir des coupures de plusieurs heures, alors je peux vous dire que d'un point de vue batteries on est armé... Mais bon, quand je vois les coupures à répétition de la SIEA, et de certains DC, c'est rassurant :p

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Comment éteindre un datacenter proprement?
« Réponse #19 le: 04 novembre 2012 à 12:40:32 »
J'ai déplacé le hors sujet sur la discussion sur le choix entre NAS "fiber chanel" ou NAT 10 Gb/s Ethernet dans le post
switch "fiber chanel" ou Ethernet ?

thenico

  • Expert.
  • Abonné OVH
  • *
  • Messages: 1 009
  • FTTH >500 Mb/s (13)
Comment éteindre un datacenter proprement?
« Réponse #20 le: 04 novembre 2012 à 16:22:55 »
Je gère le SI d'une moyenne entreprise (~100 salariés, 3 sites géographiques dans 2 régions).
Il y a juste une dizaine de serveurs mais éteindre l'infra prends un temps fou.
Et, effectivement, il nous faut une heure avant que le SI marche suffisamment pour permettre à nos employés de travailler:
Le coup de l'Exchange qui démarre avant les DC et qui n'arrivent pas à accrocher l'AD c'est produit tellement de fois qu'on préfère démarrer à la main les serveurs dans un ordre précis.

Alors, je n'ai aucun mal à comprendre qu'un SI plus complexe prenne une journée entière a être remonter.