Bien, on repose les hypothèses alors :
1 - tu as un site principal (actif dirons nous) et un site secondaire (passif dirons, passif dans le sens où les transactions se font sur le site principal et que sur celui ci)
2 - tu souhaites avoir une "réplication" (ce n'est en fait pas du tout le bon terme, je parlerais moi d'avoir une "image délocalisée") du site "actif" vers le site "passif" sachant que :
a) le site "actif" héberge les applications SAP et EXCHANGE
b) les données totales (sur le site "actif") de SAP sont de 2,8 To
c) les données totales (sur le site "actif") de EXCHANGE sont de 1,6 To (je suppose, puisque tu ne mets pas d'unité de valeur dans ton post)
d) le lien entre le site "actif" et le site "passif" est une fibre optique supportant un débit de 1 Giga bits/seconde
e) seules les données de modifications doivent transiter du site "actif" vers le site "passif" (données de modification = creation / suppression / update)
f) on n'a AUCUNE INFORMATION sur la volumétrie instantantée de ces modifications ni leur frequence...
Ceci est je pense le résumé de tout ce qui a été dit jusqu'ici.
Indépendamment de simples "mesures" qui consisteraient à dire quelque chose comme : << mes enregistrements font 100 octets de taille et il y a en moyenne 60 enregistrements modifies par heure >> et tenter par une règle de trois de dire quelque chose comme : << il faut tant d'octets transmis par seconde >>, on est je pense, a cote de la plaque....
En effet, SAP et EXCHANGE sont des applicatifs extremement sophistiqués et penser ne serait-ce qu'une seconde que le simple fait de transporter de la donnée brute d'un site vers un autre suffit a assurer un "backup" est un leurre.
Sur le site "actif" par exemple, il faut mettre en oeuvre des fonctions d'export de données avant de les transmettre et souvent, ces fonctions d'export de données se font base fermée !!! (que ce soit ici de l'Oracle ou autre base).
Et sur le site "passif" il faut un SAP d'accueil, qui importe de la donnée reçue pour l'intégrer dans les procédures de mises a jour de la base, procédures qui ne sont pas si triviales.
Qui plus est, financierement parlant, cela signifie avoir ACHETE 2 licences SAP et 2 licences EXCHANGE (sans parler des licences Oracle ou autre base de données...).
Je ne recommande que deux choses, avant toute tentative d'évaluation de la taille du "tuyau" (la fibre en l'occurence) :
1 - contacter un Ingénieur SAP et lui demander comment et avec quelles options du produit il mettrait en place une telle réplication , au sens VRAI du terme
2 - contacter un Ingénieur MICROSOFT et lui demander comment et avec quelles options du produit il mettrait en place une telle réplication , au sens VRAI du terme
Pour ma part, s'il s'agit de probleme de sécurité, de plan de secours, de plan de reprise d'activité, de plan de continuité de service, peu importe le terme utilisé, je n'ai JAMAIS vu d'entreprise payer 2 FOIS pour cela...
Les éléments de secours ont plutot ete axés sur la redondance des serveurs, sur la délocalisation a "faible" distance de Baies de disques mais alors, on se contrefichait royalement de savoir ce qu'il y avait sur les disques, on agissait "mécaniquement" un peu comme du mirroring mais a distance...
Par contre, JAMAIS le site "passif" n'était en mesure d'exécuter simultanément l'application (du fait du cout des licences applicatives); le site "passif" se contentait d'avoir une copie conforme des données des disques du site "actif".
Je pense qu'au final, c'est ça que tu cherches...
Dans ce cas, c'est toute une technologie a mettre en oeuvre et qui ne se résume SURTOUT PAS à calculer combien d'octets transitent sur une fibre optique...
