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.

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.

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

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

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.