Architecture générale

Les architectures TiNa et NBU différant quelque peu dans leur architecture et dénomination, j’ai largement communiqué auprès des différents interlocuteurs du projet afin de présenter les différences de fonctionnement et de veiller à ce que tous utilisent un vocabulaire commun.

Les clients TiNa envoient les données à sauvegarder et les méta-données à un serveur TiNa via IP. Ils seront migrés en clients IP NBU, lesquels envoient les données à sauvegarder à un media serveur NBU (on ajoutera le qualificatif «d’infrastructure» afin de mieux les distinguer des SAN medias serveurs , car ils font partie de l’infrastructure de sauvegarde NBU) et les méta- données à un master serveur NBU via IP.

Les storage nodes Tina envoient les données à sauvegarder à la robotique via le SAN et les méta-données à un serveur TiNa via IP. Ils seront migrés en SAN medias serveurs NBU, lesquels envoient les données à sauvegarder à la robotique via le SAN et les méta-données à un master serveur NBU via IP.

Catalogue

Baie SAN

SAN BACKUP Données sauvegardées via le LAN

Légende

Données sauvegardées via le SAN Méta-données

Storage Node TiNa (ou Filer)

Client TiNa Serveur TiNa

Robotique (physique ou virtuelle)

Florent MATZINGER Page 53 sur 120 28/01/2011

Master Serveur NBU

Media serveur NBU SAN Media serveur NBU

Client NBU Catalogue

Baie SAN

SAN BACKUP Données sauvegardées via le LAN

Légende

Données sauvegardées via le SAN Méta-données

Robotique (physique ou virtuelle)

Illustration 25 : schéma fonctionnel d’une sauvegarde NBU

Tous les serveurs sauvegardés avec l’outil NBU envoient donc leurs méta-données à un master NBU qui héberge le catalogue.

Le but consiste à remplacer les serveurs TiNa par un(des) master(s) et des medias serveurs NBU.

La plate-forme MDSP  étant décomposée en plusieurs DMZ , l’architecture standard de sauvegarde dans les IAS (media serveur dans la ZSV ) ne peut convenir. En effet, les firewalls d’accès aux différentes DMZ et surtout le firewall d’accès à la ZSV constitueraient le goulet d’étranglement de la solution.

J’ai donc proposé en CVAT  une autre architecture, laquelle permet de déporter les medias serveurs dans les DMZ . Comme présenté au chapitre 4.2, le Comité de Validation des Architectures Techniques constitue le passage obligatoire pour toute nouvelle implantation d’architecture afin de s’assurer qu’elle respecte les préconisations groupe et donc sa bonne intégration dans l’architecture déjà présente [1].

Après concertation avec les architectes réseaux, ceux-ci ont exprimé les contraintes suivantes sur les flux :

- pas de communication directement entre les DMZ publique et trusted (passage obligatoire par la DMZ privée pour des questions de sécurité),

- aucun filtrage entre les DMZ trusted et publique RSC , - aucun filtrage entre les environnements PPHOM et INT, - aucun filtrage entre les environnements PPMCE et PPERF,

- préférence pour que les serveurs de la DMZ d’administration communiquent avec la DMZ privée ou publique,

- pas de communication entre les différents environnements ; seule la DMZ d’administration est commune à tous les environnements.

Dans un souci de simplification, on peut considérer, aux sens réseau et sauvegarde (mais non applicatif), que :

- les environnements PPHOM et INT ne forment qu’un seul ensemble, - les DMZ trusted et publique RSC ne forment qu’un seul ensemble. Je considèrerai donc dans la suite du document qu’il y a :

- 4 environnements : PPHOM-INT, PPMCE-PPERF et les 2 PROD,

- 3 DMZ  par environnement : privée, publique et secure- (ou trusted-) publique RSC. J’ai finalement proposé :

- par site : le maintien (sur Aubervilliers) ou le déploiement (sur Vélizy) d’un master afin d’avoir un catalogue unique par site.

- par DMZ : le déploiement d’un media serveur (d’infrastructure) afin que les données sauvegardées ne traversent pas de firewall .

- par environnement : la création d’une VTL pilotée par le media serveur de la DMZ privée.

- pour l’IAS de Vélizy (hors MDSP ) : un media serveur avec sa VTL dédiée. Cette solution permet de limiter les données devant traverser un(des) firewall(s) aux flux :

- de méta-données ,

- de mise à jour de la base EMM et de commande robotique (réservation de lecteurs, demande de montage et de démontage de bande).

Des Demandes d’Ouvertures de Flux (DOF) devront être émises pour les besoins de flux suivants : - tous les serveurs doivent communiquer avec le master ,

- tous les medias serveurs doivent communiquer avec le media serveur de la zone privée qui pilote la VTL ,

- les serveurs de la zone d’administration communiquent avec le media de la DMZ Privée (c’est-à-dire le moins chargé mais proposant du disk staging ), la quantité de données à sauvegarder dans cette DMZ ne justifiant pas d’ajouter de media serveur dédié.

Les flux utilisés sont :

- TCP 1556 (pbx_exchange) entre le serveur hébergeant la base EMM (le master serveur) et les medias serveurs, et entre les medias serveurs des DMZ Publique et Trusted avec le media serveur de la DMZ Privée.

- TCP 13724 (vnetd) entre le master et les clients, entre le media et ses clients, entre les medias serveurs des DMZ Publique et Trusted avec le media serveur de la DMZ Privée.

Florent MATZINGER Page 55 sur 120 28/01/2011

Nous vérifierons dans le chapitre suivant que l’infrastructure proposée supportera la charge. La répartition des clients par media serveur et DXi serait ainsi la suivante :

Site Environnement DMZ desservies serveurMédia

Vélizy PPHOM+INT Public 77 0 mspvq347

Vélizy PPHOM+INT Admin et Private 95 0 mspvq636

Vélizy PPHOM+INT Trusted et Pub RSC 38 0 mspvq760

Vélizy PPMCE+PPERF Public 71 0 mspvr364

Vélizy PPMCE+PPERF Admin et Private 89 0 mspvr636

Vélizy PPMCE+PPERF Trusted et Pub RSC 27 7 mspvr779

Vélizy PROD Public 128 0 mspvp389

Vélizy PROD Admin et Private 141 0 mspvp670

Vélizy PROD Trusted et Pub RSC 29 13 mspvp787

Aubervilliers PROD Public 114 0 mspap389

Aubervilliers PROD Admin et Private 136 0 mspap666

Aubervilliers PROD Trusted et Pub RSC 28 13 mspap785

266 187 0 7 13 278 298 13 Nb de SAN média Nb de clients IP

Tableau VIII : répartition des clients par media serveur