Migration du système de sauvegarde d’une infrastructure locale à un système centralisé IN2P3 101/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

Plan Le système local L’infrastructure centralisée Les étapes de la migration Pour et contre Projets Conclusions 01/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3) 2

Le système local Matériel dédié: – Un serveur Windows 2008 – Logiciel NetWorker (Legato) (depuis plus de 10 ans au Lapp) – Robot (librairie) Overland Neo : 60 slots LTO2 (2 lecteurs) fin de maintenance= 01/2013 Client Networker sur : – Serveurs «Bridge» Windows et Linux pour le backup du NAS (Netapp) (Partages Windows via SMB et montages NFS pour Linux) – Serveurs Linux (têtes GPFS HeadNodes) pour les zones du SAN – Serveurs Windows et Linux pour la sauvegarde des zones locales (data, logs, conf…) Rétention : – Incremental quotidien = 6 mois – Full mensuel = 2 ans – Archivages sur demande = 3 ans PLUS un serveur dédié Microsoft DPM2010 pour la sauvegarde Exchange (backup à chaud sur disque toutes les 30 minutes + backup hebdomadaire des fichiers.edb via Networker) 301/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

Observations Cout élevé de notre solution (cassettes, maintenance hard et soft …) Matériel en fin de vie, pas de budget IN2P3 pour le renouveller De moins en moins de demandes de restauration (utilisation des snapshots sur le NAS) Matériel de stockage de plus en plus fiable  EVOLUTION vers la solution centralisée proposée par le CC-IN2P3 à Lyon 501/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

La nouvelle infrastructure Au CC-IN2P3: – Logiciel IBM TIVOLI Storage Manager (utilisé au CC depuis 1994) – Dans le centre de calcul: 4 librairies SUN SL8500 (partagées avec HPSS) 4 serveurs IBM (10Gbps Eth, 16 Go Ram) pour le backup: Aix 6.1, TSM 6.2 un serveur "library manager" un server pour le monitoring – De la part de l’équipe support : Des outils (wrapper) Aide et documentation – Principe: Backup initié par le client (liste des dossiers à sauver définie sur le serveur TSM) Data écrites sur disque Puis migration sur la bande “primaire” Copie sur la bande “secondaire” Transfert des bandes secondaires dans un local sécurisé (manuellement) 601/06/2016

La nouvelle infrastructure Au LAPP: – Pour les zones NAS et SAN : Installation du client TSM sur des serveurs « bridge » (linux) virtuels Montage NFS des zones NAS Montage GPFS des zones SAN – Pour les données locales des serveurs linux: Utilisation du logiciel « Duplicity » – Pour le serveur Exchange: Microsoft DPM2010 pour backup à chaud sur disque Ajout d’un deuxième serveur avec mécanisme DAG (databases replication) 701/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

Etapes de la migration (1) : le NAS Janvier 2012 : installation du client TSM sur un serveur virtuel, configuration et tests Backup full des zones NAS (ajout de 2 or 3 zones par semaine, en moyenne 5 heures pour 200 GO) : total 3 TO Tuning : augmentation du nombre de cores sur le serveur bridge (machine virtuelle) Avril : incremental quotidien du NAS OK : fichiers scannés, < 100 GO, 5 heures Ancien systeme toujours utilisé en parallèle 801/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

Etapes de la migration (2) : le SAN Ajout d’un autre serveur bridge pour les zones du SAN visibles via GPFS : 2,5 TO full, fichiers, < 50 GO incr par jour, 1 heure Septembre : ajout de la dernière zone SAN (grid_software) : – files, full 700GO – Incremental par jour : < 100 files, <1 GO  plus de 24 heures !!! Tuning : integration avec GPFS : – Installation du client TSM sur une des têtes GPFS – Adaptation du wrapper pour utiliser la commande GPFS "mmbackup"  seulement 35 minutes !!! 901/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

Etapes de la migration (3) : les zones locales Besoin d’une solution pour les zones locales des serveurs linux – Liste des dossiers/fichiers à sauver définie sur le serveur TSM  Trop statique – Client TSM impossible à installer sur chaque serveur : Différents OS / versions Nombre limité de clients au total (CC)  choix de « duplicity » Duplicity = création d’archives incrémentales chiffrées sur une zone distante (via ssh) 1001/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

Avantages Externalisation de fait  sécurité Coût faible : [ 2 serveurs virtuels + bande passante réseau] // [logiciel couteux + serveur dédié + robot + cassettes + maintenance] Plus de serveur à gérer (mises à jours, évolution de versions …) Plus besoin de manipuler les cassettes Choix de la fenêtre de backup et restauration 1201/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

Inconvénients Temps pour une restauration totale possiblement élevé (« node colocation on tapes ») – Solution : refaire un full tous les 6 mois ?  impact sur la volumétrie Moins de flexibilité : paramètres et politiques statiques : – Liste des fichiers/dossiers à sauver définie sur le serveur TSM – Politique de rétention : un an pour les fichiers effacés, 1 à 5 versions pour les fichiers actifs, pas d’archives  Solution : augmentation du nombre de snapshots sur le NAS Accès NFS pour le NAS  Perte des ACLs Windows Nouvelle interface pour les restaurations  documenter les procédures internes, former les membres de l’équipe Besoin d’un autre logiciel pour les zones locales  procédure de restauration plus complexe Pas de solution pour les serveurs Windows Impact sur la charge du réseau (passage au 10 GO) 1301/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

La suite Au lapp : – Utiliser mmbackup pour toutes les zones gpfs – Tester le client TSM pour Windows – Arrêter l’ancien système (une année de rétention atteinte sur les deux systèmes) Au CC : – Remplacer les cassettes LTO4 par des LTO6 (moins de cassettes) – Préparer des pages de statistiques pour les admins des labos – Mettre en place SSL pour sécuriser les transfers (impact sur le CPU?) – 2014 : nouvelle librarie LTP6 (petite) pour le local sécurisé pour automatiser les copies secondaires – Reduire la rétention (choix de différentes politiques basées sur une “classe” de fichiers”)  impact sur les labos – Imposer des plages de sauvegarde – Trouver une solution pour les archives 1401/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3)

Conclusions Du point de vue du CC: – service offert à environ 15 labos, depuis 8 ans pour certains – Support sur la base du “best effort” (pas de SLA) – En 2012 : 15 jours d’arrêt (disponibilité = 98%) – 800 TO pour les labos (idem usage interne du CC) Du point de vue des labos: – Des constraintes – Très bonne solution de type “disaster recovery” – La mutualisation est une bonne chose 01/06/2016 HEPIX Spring 2013 Muriel Gougerot (LAPP) and Remi Ferrand (CC-IN2P3) 15