Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Recover2Cloud : Sungard Availability Services crédibilise le marché DRaaS en France




Parmi la grande variété d’opportunités apportées par le cloud computing aux entreprises de taille moyenne ou intermédiaire, le DRaaS (« Disaster Recovery as a Service ») est un cas d’usage qui s’impose d’évidence.

Qui dit « cloud » dit (a priori) « loin », en tout cas en dehors de la zone de risque de l’entreprise. Par rapport à un secours « classique », le recours à des technologies cloud (associées à la réplication) permet une meilleure optimisation du ratio coût – temps de reprise. Enfin, ce type de service est toujours hébergé dans un data center sécurisé de bon niveau et géré en tout ou partie par des spécialistes, ce qui simplifie la vie d’une DSI avec des moyens limités.

Le marché DRaaS s’est ouvert il y a environ quatre ans aux Etats-Unis mais n’a pas encore véritablement démarré en France. L’introduction en France de Recover2Cloud (R2C) en 2015 par Sungard AS, acteur important en continuité d'activité et notamment dans le marché des services de reprise, est peut-être en train de changer la donne.
 

Recover2Cloud : reprise dans un « cloud communautaire » en France

Recover2Cloud est un service de reprise accélérée des environnements x86 physiques et virtuels, grâce à une réplication des systèmes, des applications et des données dans le cloud.

La réplication et, le cas échéant, la reprise ne se font pas dans un cloud public mais plutôt dans le « cloud communautaire » de R2C, autrement dit, un cloud privé géré par Sungard AS pour la communauté de ces clients. En France, le service est hébergé dans le Data Center Tier 3+ de Sungard AS à Lognes.

Le segment de marché visé par R2C est celui des entreprises de taille moyenne ou intermédiaire qui, comme les grands groupes, ont souvent des besoins en termes de disponibilité des applications de plus en plus élevés mais disposent de ressources limitées.

Recover2Cloud permet aux clients d’atteindre des objectifs de reprise des environnements x86 bien plus exigeants qu’avec un service de secours « traditionnel », dans lequel la reprise s’appuie sur des sauvegardes externalisées et des ressources informatiques physiques mutualisées chez le prestataire, tout en restant à un coût du même ordre.

Bien entendu, il existe depuis plusieurs années d’autres types de solutions de secours rapide, à base de réplication, qui couvrent non seulement les serveurs x86 mais aussi les systèmes dits « legacy ». Cependant, de telles solutions sont coûteuses, plus pertinentes pour les grands groupes que pour les entreprises de taille plus modeste, et nous laissons donc ce type d’approche de côté dans la discussion qui suit.
 

L’architecture du service

L’architecture générale de Recover2Cloud est présentée sur le schéma ci-dessous.

Les serveurs à protéger peuvent être physiques ou virtuels, avec support pour VMware, Hyper-V et Zen. En revanche, lors de la réplication, tous les serveurs sont transformés en « VMs dormants » de type VMware. Les serveurs se trouvent en général dans un data center client mais peuvent aussi être hébergés dans le cloud d’un autre prestataire.

Lors de bascule en test ou reprise, le client dispose de ses systèmes, ses applications et ses données – sous forme de machines virtuelles VMware - dans le cloud communautaire de R2C chez Sungard AS.
 

La réplication

Pour assurer la réplication, les données modifiées sont captées par un agent logiciel sur les serveurs de production du client.

Sungard AS fournit le « serveur de traitement » qui joue le rôle coté client de chef d’orchestre pour la réplication. Les données sont compressées et envoyées de manière sécurisée vers le cloud de reprise où elles sont stockées par un « serveur maitre » dans des fichiers VMDK dormants.

Une copie des données changées est également journalisée par le service CDP (protection de données continue) permettant d’offrir une fenêtre adéquate (généralement d’environ 3 jours) pour récupérer des fichiers corrompus ou supprimés par erreur.

Le service d’accès Internet dédié de Sungard AS est utilisé par défaut pour la réplication.

La cohérence applicative

R2C utilise les mécanismes VSS pour réaliser un point de synchronisation avec Exchange, MS SQL et de toutes les applications Windows. Il s’appuie sur les commandes natives Oracle pour conserver la cohérence des bases de données Oracle.

Lors de la reprise d’un client, ces mécanismes permettent au client (ou à Sungard AS, selon la répartition contractuelle des responsabilités) de repartir du point de cohérence applicative choisi, de façon à ce que tous les serveurs soient repris de manière cohérente en conformité avec VSS et Oracle...

La bascule et le retour

En situation de sinistre, Sungard AS bascule- en fonction de la demande du client - tout ou partie des VM par transformation des VMDKs dormants en VM actives et s’assure qu’elles sont associées aux bons réseaux et à Internet. Des connexions sécurisées sont établies entre les VM activées et les autres serveurs qui se trouvent sur le réseau de production du client

Différents moyens sont possibles pour permettre aux utilisateurs d’accéder à leurs applications dans le cloud R2C : connexions Intenet sécurisées, réseau MPLS, lien dédié, …

A la fin du sinistre, le retour sur le site de production du client se fait essentiellement par réplication en sens inverse. Dans le cas des serveurs VMware, le retour est assez simple : Sungard AS effectue la réplication dans l’autre sens, puis déclenche une bascule vers le site du client. Pour les serveurs de production qui sont physiques ou sur une plate-forme différente de VMware, le retour est un peu plus compliqué. Dans ce cas, le client devra d’abord installer les OS, les service packs et les applications. Ensuite, les disques contenant des volumes non systèmes sont répliqués vers le site client à partir du cloud de reprise.

Les tests

La bascule en test se fait sans interruption des serveurs de production dans un « bac à sable », c'est-à-dire, un environnement virtuel dédié créé pour le test et doté d’un pare-feu virtuel de test spécifique.

Sungard AS déclenche la bascule et les VMDK dormants deviennent actives derrière le pare-feu de test. Après la bascule, le client peut utiliser un client VPN pour se connecter au bac à sable et faire ses propres tests ou, le cas échéant, déléguer ce travail au prestataire.

La qualification en avant vente

En amont de la signature du contrat, Sungard AS mène avec le client un travail collaboratif sérieux sur la conception de la solution (« Customer Design Requirements » ou CDR).

Dans ce contexte, la qualification des applications à protéger est un processus particulièrement important. En effet, la reprise d’un environnement physique et/ou virtuel dans le cloud est sujette à sa capacité d’être exécutée dans le cloud. Il faut également vérifier que tous les middlewares concernés (par exemple, les systèmes de bases de données) peuvent être pris en charge pour réaliser les points de synchronisation pour la cohérence applicative. Enfin, le travail de CDR permet aussi d’évaluer les besoins en termes de RAM, de capacité de stockage, de bande passante pour la réplication et ainsi de suite.

La mise en œuvre du service R2C

Si Sungard AS assure la majeure partie des travaux en tant que MOE, le client doit assumer pleinement son rôle de MOA à chaque étape de la mise en œuvre.

Le calendrier d’un projet de déploiement dépend non seulement des services de secours à déployer mais aussi du périmètre applicatif et de la complexité du système d’information et de son exploitation. Dans un contexte assez simple, la mise en œuvre de R2C peut se faire sur une période d’un à deux mois ou, dans un contexte plus complexe, sur une période de trois à quatre mois. En revanche, la mise en œuvre d’une solution plus globale (secours chaud et froid, R2C en environnement x86 et d’autres services de secours pour les systèmes « legacy »…) peut s’étaler sur un calendrier de six mois.

Les étapes principales d’un projet de déploiement type sont représentées sur ce tableau.

De manière assez classique, la recette de la mise en oeuvre de R2C se déroule en deux étapes : VABF (vérification d’aptitude au bon fonctionnement) et VSR (vérification du service régulier). La mise en production est formalisée par la signature d’un procès-verbal.

Capitaliser sur Recover2Cloud : trois points à ne pas oublier

Recover2Cloud est une solution de grande qualité, mais la valeur qu’elle apporte dans la pratique dépend des applications du système d’information client, d’une bonne utilisation des services managés fournis par le prestataire et, plus largement, de l’ensemble des dispositifs de continuité d’activité de l’entreprise.

L’atteinte des objectifs de reprise dépend des applications du client et de leurs environnements

Disposer d’une vision claire des possibilités offertes par Recover2Cloud, face à la réalité d’un système d’information, est primordial. Ici nous limitons nos commentaires à la problématique des objectifs de reprise pour des environnements hétérogènes.

R2C a été conçu pour protéger des serveurs X86 physiques et virtuels. Cependant, beaucoup de clients potentiels dans le segment du marché visé (entreprises de taille moyenne ou intermédiaire) exploite aussi des systèmes « legacy » (AS400, grands systèmes UNIX ou encore Mainframe). En effet, on voit assez souvent des architectures combinant des applications « front office » (généralement plus récentes) en environnement X86 et des applications « back office » sur un système plus ancien.

Si les applications en environnement X86 représentent un sous-ensemble relativement autonome, R2C peut jouer son rôle et assurer une reprise accéléré, toujours en supposant que ce sont les applications dont les utilisateurs ont le plus besoin. Les autres applications pourraient prendre bien plus de temps à reprendre en secours « traditionnel » mais, dans ce cas, ce n’est pas grave.

En revanche, les applications et les environnements pourraient être assez liés, par exemple, si les processus « front office » et leurs applications en environnement x86 s’appuient sur des fonctions ou des bases de données (clients, commandes, référentiels, stocks, …) encore gérées sur un système « legacy ». Dans ce cas, la relance des processus métiers « front office » - souvent assez urgente - est dépendante du temps de reprise globale. Certes, des modes dégradés pourraient être envisagés, mais leur intérêt et leur faisabilité sont à apprécier en fonction des processus et des applications spécifiques.

De manière générale, l’atteinte d’un objectif de reprise accélérée dépend non seulement du service R2C mais aussi de la réalité du système d’information du client.

Le niveau de services managés à demander au prestataire dépend du contexte spécifique de l’organisation

Recover2Cloud est une solution managée mais Sungard AS peut fournir plus ou moins de services autour de la solution en fonction des besoins du client. La répartition des responsabilités – où mettre le curseur du qui fait quoi – est un choix important.

Sungard AS est un grand professionnel de la reprise, avec des ambitions d’aller encore plus loin dans les services managés plus ou moins connexes à son cœur de métier. Une DSI avec des ressources humaines limitées peut légitiment préférer s’appuyer de manière importante sur des experts. Cependant, il ne serait pas prudent de se dégager complètement de cette fonction vitale, quitte à prévoir dans le contrat un certain transfert de compétences.

Il n’y a pas une seule bonne réponse mais la question est incontournable.

Recover2Cloud est un outil au service de la continuité d’activité de l’entreprise

Tous comptes faits, R2C – comme tout DRaaS – n’est qu’un outil parmi d’autres dans la « boite à outils » des procédures de continuité et reprise d’activité d’une entreprise.

La continuité d’activité – comme en témoigne la norme IS0 22301 – va bien au-delà de la reprise informatique, aussi vitale soit-elle. Prenons un exemple très simple. Une organisation qui a mis en place une prestation de DRaaS mais qui n’a rien prévu comme dispositif de gestion de crise va immanquablement souffrir le jour où le sinistre arrivera et où il lui faudra décider que ce qu’elle fait.

R2C est un service qui peut être fort utile à bon nombre de clients. Toutefois, pour pouvoir faire face à un sinistre mettant en péril l’activité d’une organisation, il faut prendre le défi de la continuité dans son ensemble.

Conclusion

Les entreprises françaises sont encore réticentes à s’appuyer sur le cloud public pour les choses essentielles, que ce soit les grandes applications métiers ou un service de reprise informatique suite à sinistre. Le cloud communautaire de R2C - un cloud privé managé par Sungard AS pour la communauté de ses clients - pourrait contourner ces réticences.

Surtout Recover2Cloud a une proposition de valeur forte, notamment pour les entreprises de taille moyenne ou intermédiaire.

Avec ce service, Sungard AS est bien positionné pour crédibiliser la reprise dans le cloud et donc véritablement ouvrir le marché DRaaS en France. Ce faisant, il agit certes à son propre avantage mais aussi au bénéfice d’autres acteurs qui suivront, dans l’émergence d’un marché de reprise dans le cloud dynamique et compétitif, au service des clients.

Donald Callahan
Jeudi 28 Janvier 2016

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Dans la même rubrique :
< >

Mercredi 5 Octobre 2016 - 17:48 Attention : un SMCA n'est pas un PCA !


Duquesne Research Newsletter