La suppression de SIS dans Exchange 2010 pourrait accroitre les besoins en stockage

A l'occasion du lancement d'Exchange 2010, la dernière mouture de son serveur de messagerie, Microsoft a éliminé la fonction de "Single Instance Storage" qui permettait, lorsqu'une pièce jointe était envoyée à une multitude de destinataires internes, de n'en stocker qu'un exemplaire plutôt que d'en conserver autant de copies que d'e-mails envoyés. En refondant l'architecture de stockage d'Exchange 2010, Microsoft a privilégié l'amélioration des performances en entrées/sorties et a intégré une nouvelle technologie de compression de messages. Cette évolution pourrait toutefois avoir des conséquences sur le dimensionnement des architectures de stockage Exchange et sur la façon dont les entreprises gèrent leurs messageries.

A la place de la technologie Single Instance Storage (SIS), Microsoft met en avant les nouvelles capacités de compression de bases de messages d'Exchange Server 2010, ainsi que de nouveaux outils pour aider à purger les BAL et à conserver la taille des bases à un niveau raisonnable. Mais cette évolution fait grincer des dents certains utilisateurs qui font connaitre leus griefs sur Technet, le site conçu par Microsoft pour les administrateurs de ses technologies.

Microsoft a tenté de minimiser l'impact des évolutions qu'implique l'adoption d'Exchange 2010 sur le Blog Exchange blog cette semaine, tout en admettant que, dans certains cas, la disparition de SIS pourra poser problème. Par exemple, les environnements où l'essentiel des messages sont au format RTF devraient voir leurs besoins de stockage augmenter, car les algorithmes de compression d'Exchange ne traitent pas les messages RTF. En cas d'envois massifs à un grand nombre d'utilisateurs de pièces jointes volumineuses, l'impact stockage pourrait aussi être important. Par exemple, une pièce jointe de 2 Mo envoyée à 1000 utilisateurs consommera désormais 2 Go de stockage et non plus 2 Mo comme auparavant.

Cette évolution devrait donc contraindre les entreprises à mieux informer les utilisateurs sur les meilleures pratiques d'usage de leur messagerie. Par exemple, dans les environnements Microsoft, une alternative à l'envoi de pièces jointes importantes en interne, sera pour les utilisateurs de stocker leur document sur Sharepoint et d'inclure un lien dans le message.

Réduire les coûts de stockage Exchange

SIS est à l'origine apparu avec Exchange 4.0 en 1996 afin d'aider à réduire les coûts de stockage, à une époque le prix du To était prohibitif. Mais, au fil des anées, le prix du stockage s'est effondré et nombre d'infrastructures Exchange on commencé à s'appuyer sur de multiples serveurs, ce qui a limité la porté de SIS qui ne fonctionne que si la messagerie s'appuie sur une base de données unique. De ce fait, SIS est devenu moins important, explique Rob Sanfilippo, un analyste de Directions on Microsoft. "Microsoft a réarchitecturé la base de message d'Exchange afin de réduire les besoins en entrées/sorties et dans ce processus, a supprimé SIS."

Le problème est que les utilisateurs qui déploieront Exchange 2010 comme les versions 2003 ou 2007 devraient voir la taille de leurs bases de messages croître fortement. D'un autre côté, le meilleur support par Exchange 2010 des architectures de disques en attachement direct (DAS)
devrait permettre d'attacher aux serveurs de messagerie du stockage moins coûteux...

De plus, les entreprises doivent se préparer à accroitre la capacité de leur stockage Exchange si elles veulent utiliser la fonction d'archivage de BAL (personal archive mailboxes), inclue dans Exchange 2010. La disparition de SIS ne devrait donc pas être la seule cause de l'inflation du stockage Exchange.

"Si les entreprises font le pas et suivent les préconisations de Microsoft en matière de design des architectures de stockage pour Exchange, elles pourraient, au final, réduire sensiblement le coût de leur stockage," ajoute Sanfilippo. D'autant que, dans le cadre de déploiements à plus de trois serveurs, une utilisation judicieuse de la nouvelle fonction dite Database Availability Groups, qui s'appuie sur des fonctions de clustering et de réplication en continu des bases de messages entre serveurs, permet d'assurer la continuité de service en cas de chute d'un serveur et supprime le besoin d'utiliser des architectures Raid complexes pour protéger les bases de chaque serveur...

par Bridget Bothelo, SearchStorage, avec La rédaction du MagIT