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.

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.

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 ... ), 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.

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.

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