> Tech > De la haute disponibilité à  la continuité de l’activité

De la haute disponibilité à  la continuité de l’activité

Tech - Par Carson Soule - Publié le 24 juin 2010
email

Les notions de haute disponibilité, et de poursuite de l’activité sont intimement liées à la reprise après sinistre. Et, trop souvent, nous nous trouvons au coeur même de la catastrophe. Les ouragans Katrina et Rita ont dévasté des centaines de milliers de kilomètres carrés, déplacé des milliers de personnes et perturbé une multitude de sociétés et d’entreprises. Ailleurs dans le monde, d’autres catastrophes naturelles ont anéanti des populations entières. L’enseignement à en tirer n’est pas simplement que la nature a le pouvoir de mettre fin à nos vies et à nos activités, mais aussi l’étendue et la durée de telles tragédies. Trop souvent, nous considérons les sinistres comme des ennuis qui suspendent notre exploitation pendant une courte période. En réalité, nous voyons de grandes zones géographiques frappées pendant plusieurs mois.La nature n’est pas le seul danger que courent les entreprises. Il y a aussi les menaces de terrorisme, comme en témoignent les attaques mortelles dans le monde et près de chez nous. Une sale bombe ou un agent biologique peut rendre une ville inhabitable pendant plusieurs années. Songez aux centaines ou aux milliers d’ordinateurs présents à proximité de la Maison Blanche et du Capitole. Ces centres de gouvernement sont-ils suffisamment protégés contre d’éventuelles campagnes de terreur ?

La figure 1 ne contient qu’une liste partielle des sinistres susceptibles de frapper une société. Si de tels événements se produisent, nous risquons d’être coupés de nos centres informatiques pendant de longues périodes. Et même si nous pouvons récupérer l’information depuis des sites de secours, le personnel pourrait être tellement dispersé que toute reprise de l’exploitation normale serait impossible. Pis encore, nos centres de secours pourraient se trouver près de l’entreprise et, par conséquent, être aussi mal en point que le site principal. Enfin, même si la reprise purement informatique réussit, nos autres actifs et ressources pourraient être tellement affectés que toute poursuite de l’activité serait illusoire.

En tant que professionnels IT, nous devons, avec nos entreprises, élaborer des plans à plusieurs niveaux pour la haute disponibilité, la poursuite de l’exploitation, la reprise après sinistre et la continuité de l’activité. De tels plans doivent viser une protection continue contre des dangers très divers, allant de problèmes techniques internes aux événements externes et aux perturbations globales. Ils doivent répondre aux préoccupations de tous les responsables de l’entreprise, dans tous les services et départements.

De la haute disponibilité à  la continuité de l’activité

La responsabilité de la haute disponibilité incombe généralement au département IT. Elle consiste à s’assurer qu’un serveur ou un réseau est toujours opérationnel et au service des utilisateurs. A ce titre, un plan HD (haute disponibilité) est généralement de la compétences des ingénieurs matériel et logiciel, et de la responsabilité du DSI.

La haute disponibilité d’un serveur ou d’un réseau repose sur la fiabilité des éléments matériels et logiciels qui composent un système. Imaginons le zSeries, dans lequel le « z » signifie « zéro temps d’interruption ». La disponibilité d’un serveur est généralement mesurée en pourcentage de temps de bon fonctionnement. On parle parfois des cinq 9 ou 99,999 pour cent de disponibilité. C’est-à-dire cinq minutes d’interruption par an. La figure 2 montre les traductions pour une disponibilité de 99 à 99,999 pour cent.
La figure 3 montre les causes potentielles et les coûts de l’interruption.

Commençons par aborder la HD un élément à la fois. IBM et d’autres constructeurs ont beaucoup travaillé à la fiabilité de leur matériel. Sur l’iSeries, par exemple, on trouve : RAID, disques miroir, processeurs d’I/O en miroir, bus, lecteurs de disque permutables à chaud, cartes PCI, ventilateurs redondants, alimentations, mémoire à correction d’erreurs, et processeurs de rechange. Redondance et robustesse sont ici les maîtres mots : il s’agit d’éliminer les points de défaillance uniques. Pour les fabricants, cela constituait la « tolérance aux pannes ». Dans son initiative informatique autonome, IBM utilise plutôt le qualificatif « self-healing ». Pour assurer la HD d’un serveur, nous devons aussi examiner ses dépendances et ses connexions avec le monde extérieur. C’est-à-dire l’UPS et les générateurs électriques, les multiples connexions réseau et la sauvegarde sur le réseau étendu (WAN).

Le matériel n’est pas le seul point de défaillance possible. L’OS doit être tout aussi solide mais, malheureusement, le logiciel n’est pas à la hauteur du matériel. Il est plein de composants fragiles et il est rarement autocorrecteur.

Heureusement, la plupart des erreurs de logiciel, si elles peuvent causer des perturbations, mettent rarement le système à genoux. D’ailleurs, en matière d’OS, le service informatique se contente de bien le choisir et de le maintenir avec rigueur. Dans ce domaine, l’essentiel consiste à tester et à appliquer les correctifs système (comme les PTF), à assurer sécurité et protection contre des forces extérieures du genre virus, pirates, et collaborateurs hostiles.

Le dernier aspect de la HD concerne la manière dont l’application s’exécute sur le serveur. La plupart des sites ne mesurent pas la disponibilité des applications sur des serveurs à utilisations mixtes. Habituellement, les applications sont mises hors ligne pour la maintenance, la sauvegarde et même des opérations de routine comme le traitement de fin de période. A l’ère du fonctionnement global, du télétravail et de l’accès au Web 24j/7h, de telles pratiques sont en train de changer. Des techniques du genre Save While Active et Flash Copy sur les SAN tendent à éliminer les créneaux de sauvegarde. L’application à la volée des changements de programmes est désormais pratiquée dans beaucoup d’environnements, y compris les objets *PGM iSeries et les classes Java dans WebSphere. Sur les serveurs dédiés à une seule mission, comme le Web, le courrier électronique et la gestion de base de données, les utilisateurs perçoivent une défaillance applicative comme une défaillance de serveur, en constatant que la fonction requise n’est pas disponible.

La plupart des techniques évoquées jusqu’ici se concentrent sur l’interruption ou les pannes non planifiées. Or, une vraie mesure de la HD doit également inclure le temps d’immobilisation planifié. C’est souvent difficile à réaliser avec un seul système. Les mises à niveau matérielles, les nouvelles versions d’OS ou d’applications et les changements d’infrastructure obligent généralement à mettre un système hors ligne, souvent pour longtemps. Les systèmes redondants sont alors la seule solution.

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par Carson Soule - Publié le 24 juin 2010