La Fibre
Datacenter et équipements réseaux => Datacenter => 
Énergie => Discussion démarrée par: Leon le 01 novembre 2012 à 08:43:41
-
Bonjour à tous,
Voilà, je lance un pavé dans la mare. C'est la tempête Sandy aux US qui m'a rappelé le sujet.
Les datacenters sont conçus pour être alimentés en permanence. Seulement, on voit bien qu'il y a des situations extrèmes où il est préférable d'arrêter une salle ou un datacenter entier. Que ça soit pour réaliser une maintenance sur la chaine d'alimentation d'équipements (serveurs) sans double d'alimentation, ou dans le cas de la tempête Sandy parce que la situation dans le datacenter est trop critique (alimentation principale HS + générateurs de secours les pieds dans l'eau).
J'ai l'impression que ce genre de situation, de procédure d'arrêt propre n'est pas vraiment prévue, et pas automatisée. Quand on sait, par exemple, que toutes les sources d'alimentation sont HS (générateurs compris), et qu'il ne reste que 5 min d'autonomie sur les batteries, il me semble préférable d'arrêter proprement les serveurs, de forcer l'arrêt d'écriture sur les disque dur, plutôt que de subir la coupure avec des dégat parfois très longs et complexes à réparer (récupérer un gros RAID corrompu).
Les petits onduleurs destinés aux particuliers disposent très souvent d'un port série et/ou USB qui permet d'informer le PC/Serveur que la batterie est trop déchargée et que ça va bientôt couper.
Etonnamment, je ne vois rien d'équivalent dans les datacenters / chez les hébergeurs. Mais c'est peut-être une méconnaissance du sujet de ma part.
Pour ceux qui travaillent en datacenter, vous en savez plus? Comment ces situations sont-elles gérées?
Pareil, quand on sait que la situation d'alimentation n'est pas stable, et peut être coupée à tout moment, il ne faudrait garder allumé que les équipements les plus critiques (=indispensables) et les moins sensibles aux coupures électriques. Je pense aux switch/routeurs notamment, qui sont moins sensibles que les serveurs.
Bien évidemment, il me semble évident que tout cela doit être automatisé, surtout dans les datacenters "carrier neutral" hébergeant une foulle d'acteurs très différents. Le temps de réaction nécessaire pour réagir se compte en minutes.
Leon.
-
En fait un arret propre en 5 minutes, c'est absolument impossible, un shutdown d'une DB Oracle ou autre c'est au minimum 15 minutes.
Un gros système de storage, comme p.ex les Hitachi, pour flusher le cache, c'est 45 minutes...
Dans les config high availability, ce qui est fait c'est 2 alims séparés, 2 UPS, 2 groupes diesel, voir plus.
Et apres tu as les config "metro cluster" ou tout est répliqué a double sur 2 sites, donc si un site tombe, en une ou 2 minutes tout est pris en charge par le site qui reste vivant.
Sur cerain sites, les clients prévoient un shutdown piloté de tous les équipements, c'est assez lourd à mettre en oeuvre vu la tres grande diversité de matos employé, mais sur un gros datacenter, tu peux pas le faire en moins de 60 minutes, et c'est toujours un choix humain de prendre cette décision, tu peux pas faire confiance a un server de décider de t'arreter 300 systèmes, storage, réseau.
En cas de situation tres critique, incendie, inondations, etc, c'est le "bouton rouge" qui coupe tout, ensuite c'est la remise en état et les procédures de recovery.
-
Merci pour ta réponse.
En fait un arret propre en 5 minutes, c'est absolument impossible, un shutdown d'une DB Oracle ou autre c'est au minimum 15 minutes.
Un gros système de storage, comme p.ex les Hitachi, pour flusher le cache, c'est 45 minutes...
Qu'est-ce qui explique des temps aussi énormes? Pour les 45min, est-ce qu'il faut comprendre que c'est le temps nécessaire pour que toutes les écritures en cache (=RAM) se terminent vers les disque? Ca me parait absolument énorme. Mettre en cache 45 min d'écriture, ça doit nécessiter une quantité de RAM astronomique. Quel est l'intérêt? Je peux comprendre pour quelques secondes de cache, mais 45min...
Sur cerain sites, les clients prévoient un shutdown piloté de tous les équipements, c'est assez lourd à mettre en oeuvre vu la tres grande diversité de matos employé, mais sur un gros datacenter, tu peux pas le faire en moins de 60 minutes, et c'est toujours un choix humain de prendre cette décision, tu peux pas faire confiance a un server de décider de t'arreter 300 systèmes, storage, réseau.
Est-ce que ce genre de procédure est appliqué y compris dans des "datacenter tiers"? Dans ce cas, est-ce qu'on fait confiance à la remontée d'alerte (par e-mail, ou SMS) qui passe par une chaine "humaine"? Vu les compte-rendu d'incident que l'on peut voir sur les grosses défaillances de grands datacenters, on voit qu'en général, cette chaine d'information fonctionne assez mal, et que les clients sont parfois informés après la coupure, alors qu'ils auraient pu l'être avant.
Chez OVH apparemment, il arrive que les opérateurs prennent la main sur les serveurs pour forcer le shutdown, en vue d'une maintenance sur l'alimentation. Tout ça ne fonctionne bien évidemment que si le client-admin laisse la main à OVH sur ses serveurs (c'est le cas par défaut, mais c'est facile de bloquer l'accès). Je pense que ce genre de procédure est automatisé. Je vois mal un technicien se logger 300 fois de suite sur 300 machines différentes!
tu peux pas faire confiance a un server de décider de t'arreter 300 systèmes, storage, réseau.
J'avoue que j'ai toujours du mal à comprendre pourquoi on ne pourrait pas automatiser tout ça. Un automate bien programmé ne prend en général que des bonnes décisions. C'est vrai dans beaucoup de secteurs critiques: nucléaire, ferroviaire, etc... Les erreurs sur des dispositifs "sécuritaires" sont souvent (pas toujours mais souvent) dues à des réactions inappropriées d'humains.
Leon.
-
Je peux te donner un exemple sur une petite salle serveur. Ayant eu des problèmes d'électricité assez souvent ces dernières années, l'arrêt complet s'est donc fait assez souvent.
L'ingénieur système et réseau qui gère cela à mon boulot m'a expliqué un peu la chose.
Etat des lieux:
Environ une dizaine de machine serveur dell.
Un NAS centralisé se partageant entre différent serveur.
Des stations de calcul ( 4 ou 5).
Routeur et baie de brassage pour le réseau.
Chaque machine possède deux alimentations séparées (une sur chaque phase du réseau le tout ondulé).
Toutes machine en production on a 10 minutes de tenue sur l'onduleur.
Aujourd'hui la procédure est bien rodé et on arrête les machine en 8 9 minutes. Les machines possèdes toutes une liaison d'alerte à distance.
Il n'y a pas plusieurs clients sur notre machine puisque c'est un labo de recherche. l'ingénieur système envoit juste un mail et coupe quand il veut.
le plus long est en faite le redémarrage puisque il faut redémarrer dans l'ordre les différentes machines. Cela prend 40 minutes au total.
Par contre sur un centre avec des clients de partout en effet cela est plus problématique surtout en urgence. Quoique en urgence les contrats doivent prévoir qu'il ne peut y avoir d'alerte à priori.
-
le plus long est en faite le redémarrage puisque il faut redémarrer dans l'ordre les différentes machines. Cela prend 40 minutes au total.
Pourquoi y a-t-il un ordre pour redémarrer les serveurs? Normalement, on remet le courant, et ça se remet en route tout seul, non?
Par contre sur un centre avec des clients de partout en effet cela est plus problématique surtout en urgence. Quoique en urgence les contrats doivent prévoir qu'il ne peut y avoir d'alerte à priori.
Pourquoi "qu'il ne peut pas y avoir d'alerte"? Je peux comprendre que dans certaines situations, il peut ne pas y avoir d'alerte. Mais quand l'arrêt est prévisible? Quand il manque 1 groupe électrogène par exemple. Pourquoi se passer de l'alerte dans ce cas là? Encore une fois, une coupure brutale est souvent synonyme de perte de données, donc c'est à éviter à tout prix.
Leon.
-
Pour les 45min, est-ce qu'il faut comprendre que c'est le temps nécessaire pour que toutes les écritures en cache (=RAM) se terminent vers les disque?
Je ne suis encore jamais tombé sur une baie SAN/NAS qui mettrait 45 minutes à s'arrêter, mais 20-30 minutes, j'ai déjà vu, c'est assez courant sur de grosses configs.
Il y a le vidage des caches disques, l'interruption (propre) des opérations de maintenance des disques et volumes qui pouvaient être en cours, l'arrêt du système lui-même.
Ceci dit, ces systèmes possèdent généralement leurs propres batteries et sont autonomes pour gérer leur arrêt en cas de coupure totale électrique.
J'ai vécu (en live, j'étais d'astreinte), le blackout électrique de deux salles machines d'un assureur en quatre lettres, et c'était très instructif. ;)
ErDF essayait de sécuriser l'adduction électrique du site, mais n'a réussi qu'à tout couper, un samedi à 9H30 ...
Les onduleurs étaient censés tenir 15 minutes, mais comme l'assureur sortait tout juste d'une phase de migration complète de son SI, presque tous les équipements avaient été doublés, et de nouveaux environnements étaient - en plus - venus se greffer dans les salles, sans que les onduleurs soient retaillés en conséquence.
Les groupes électrogènes ne démarraient alors pas automatiquement, et les gens de la sécurité n'ont pas eu le temps de les mettre en route avant que les onduleurs lâchent (au bout de 3 ou 4 minutes).
Il nous a fallu tout le week-end pour faire repartir l'essentiel (qui permettait aux agences de travailler le lundi, elles ont bien dû faire sans informatique le samedi après-midi), et pas loin de la semaine qui a suivi pour tout le reste.
Il y a eu relativement peu de casse (quelques barrettes de RAM, quelques DD, un CPU par ci par là, comme à chaque fois que j'ai arrêté - proprement cette fois-ci - une salle machine), mais finalement bien peu de systèmes qui n'ont pas voulu (ou pu) repartir.
Nos difficultés ont surtout été liées au fait que des machines essentielles (serveurs DNS, par exemple) étaient mal repérées, que beaucoup de docs n'avaient pas été tirées en éditions papier (la procédure de redémarrage de la salle machines est sur le réseau ... ;D), ou qu'elles étaient obsolètes, et - surtout - que les dernières configurations actives de pas mal d'équipements (switches LAN/SAN, gros serveurs IBM) n'avaient pas été correctement écrites dans les mémoires non volatiles des équipements.
-
Pourquoi y a-t-il un ordre pour redémarrer les serveurs? Normalement, on remet le courant, et ça se remet en route tout seul, non?
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.
-
Mais ça ne se fait pas tout seul? Un serveur qui ne voit pas son SAN/NAS n'attends pas de le voir? L'opérateur doit-il faire des manipulations dans un ordre particulier?
Leon.
-
Je te prend un exemple : si tu démarre une machine de prod alors que le réseau n'est pas up ou même que le serveur DNS n'est pas up cela peux mettre en échec certains services. Il faudra relancer a la main les services qui posent problème. Si seulement 2 services posent problème par serveur, vu le nombre de serveurs c'est ingérable.
J'ai l'expérience d'un datacenter avec des systèmes complexes occupant une centaines de baies. L'extinction prend une journée entière (L'extinction se fait dans un ordre précis), sachant que 2 semaines avant l'extinction il y a un inventaire pour être sur d'avoir les procédure pour éteindre tous les systèmes.
La re-mise en service prend également une bonne journée avec de nombreuses personnes qui ne font que ça. Il y a des étapes et avant de passer a l'étape suivante et de rallumer xx équipements, il faut s'assurer que les services précédents sont bien up.
que les dernières configurations actives de pas mal d'équipements (switches LAN/SAN, gros serveurs IBM) n'avaient pas été correctement écrites dans les mémoires non volatiles des équipements.
Je connais ça pour les serveurs.
Perso, sur les serveurs que je gère, j'écris tout dans les fichiers de conf et je ré-démarre (je ne suis pas sur des services essentiels, mais des serveurs de tests)
J'ai déjà vu plusieurs fois une société qui exploite des serveurs faire des conf IP sans les écrire. Le reboot suivant c'est la galère surtout quand le reboot est plus d'un an après. Je demande maintenant systématiquement un reboot dans les instructions que j’écris après la configuration et avant les tests.
-
Mais ça ne se fait pas tout seul?
Tu peux avoir des serveurs qui vont tenter de démarrer sur plusieurs sources, et finir par rebooter s'ils n'y arrivent pas, et ceux là vont sans doute finir par décoller tout seuls quand ils auront trouvé ce qu'il leur faut pour démarrer.
Mais à côté de ça, tu en as beaucoup plus qui vont s'arrêter dès la première tentative, et attendre que quelqu'un leur dise quoi faire.
Et là, je ne te parle que de l'aspect démarrage de l'OS.
D'un point de vue applicatif, il est excessivement rare qu'une application accepte de démarrer s'il lui manque une ressource essentielle.
Une base de données à qui il manque un disque refusera de démarrer, purement et simplement.
Une application à qui il manque sa base de données refusera de démarrer, purement et simplement.
-
Je ne suis encore jamais tombé sur une baie SAN/NAS qui mettrait 45 minutes à s'arrêter, mais 20-30 minutes, j'ai déjà vu, c'est assez courant sur de grosses configs.
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, ces systemes sont prévus pour ne JAMAIS etre arreté, au pire tu peux faire un shutdown qui peux meme dépasser une heures pour les plus grosses config, et en cas de coupure électrique d'urgence, c'est le service de maintnance du constructeur qui intervient pour le redémarer, et la ca peux prendre plusieurs heures, si il y a pas de failures hardware suite a la coupure électrique.
-
Je me permet de continuer à faire des commentaires sur un monde que je ne connais pas. Je raconte surement des conneries, alors merci de me corriger/ de m'expliquer.
Je te prend un exemple : si tu démarre une machine de prod alors que le réseau n'est pas up ou même que le serveur DNS n'est pas up cela peux mettre en échec certains services. Il faudra relancer a la main les services qui posent problème. Si seulement 2 services posent problème par serveur, vu le nombre de serveurs c'est ingérable.
Mais à côté de ça, tu en as beaucoup plus qui vont s'arrêter dès la première tentative, et attendre que quelqu'un leur dise quoi faire.
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? Toutes ces opération "manuelles" que vous me citez me semblent soit être automatisables, soit liés à des problèmes de mauvaise configuration d'équipement (basculement vers une config par défaut inappropriée).
Un service (DNS, SAN) temporairement indisponible, ça doit être une situation prévue, je pense. Si l'indisponibilité de l'un fait planter l'autre, c'est qu'il y a un problème de conception/paramétrage, non?
Je doute fort que chez Google, Facebook ou autre, les opérateurs doivent ralumer les serveurs à la main. Ca doit être automatisé un maximum.
La re-mise en service prend également une bonne journée avec de nombreuses personnes qui ne font que ça. Il y a des étapes et avant de passer a l'étape suivante et de rallumer xx équipements, il faut s'assurer que les services précédents sont bien up.
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! 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.
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, ces systemes sont prévus pour ne JAMAIS etre arreté,
Comment est-ce possible de concevoir un système qui est prévu pour ne pas être arrêté? L'arrêt, même si c'est exceptionnel, doit être une opération prévue, à mon avis. C'est une situation qui peut être rencontrée pour plusieurs raisons: défaillance, déménagement, etc...
Je ne comprends pas comment on peut garantir une "GTR" avec les services que vous me décrivez tous les 3! S'il faut faire déplacer des gens, suivre des procédures manuelles sans fin, comment peut-on garantir des "GTR" de 4h sur des services informatiques?
Leon.
-
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.
-
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 ...
-
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....
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.
-
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%.
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.
-
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 ...
-
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)
-
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
-
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 ? (https://lafibre.info/datacenter/switch-fiber-chanel-ou-ethernet/)
-
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.