Foire Aux Questions sur Hitachi Content Platform

1 269 vues

Publié le

Hitachi Content Platform: le Stockage Objet au Service du Cloud, de l’Archivage, du Partage d’Information et de la Gestion des Contenus.

HCP est la réponse d’Hitachi Data Systems aux préoccupations de partages de fichiers et d’archivage (probant ou non), pour la mise en œuvre d’une infrastructure de stockage objet dédiée à la conservation d’information, l’interopérabilité applicative et de gestion de contenus de tout type.

HCP répond aux besoins de consolidation, de volume important, de simplification de gestion, de facilité étendu de partage et de mise à disposition d’un service avancé de stockage objets en mode Web. HCP est aussi déclinée en offre verticale, afin d’adresser des besoins métiers spécifiques, telle que la solution Hitachi Clinical Repository dédiée aux établissements de santé.

La solution Hitachi Content Platform est un produit tout-en-un matériel et logiciel, dont l’objectif principal est de proposer un espace de stockage partagé en mode Fichier accessible via des protocoles IP et incluant des services avancés de politique de conservation et de protection des contenus.

Le Système Objet du HCP propose des services de stockage très attractifs incluant une évolutivité quasi illimité, une forte résilience, une grande capacité de traitement de données, une prise en charge des métadonnées, une proportion à utiliser du stockage dit low-cost, une haute disponibilité et un accès via les protocoles Web HTTPs (REST, WebDAV, cURL, S3, OpenStack Swift, …). HCP est donc parfaitement adapté aux environnements : Web, réseaux sociaux, d'archivage, de sauvegardes et de fichiers de toute nature et, principalement, au partage de contenus multimédia, tels que les images et les vidéos.

HCP est aussi parfaitement adapté aux volontés d'intégration et de création applicative via les APIs disponibles pour l'échange de données (RESTful API, S3) et l'administration (MAPI). A ce titre, Hitachi propose gratuitement une simple VM Workstation qui permet à un développeur de démarrer un programme de gestion de données à partir de son Framework et langage favoris (.NET, Java, Python, Perl, C#, etc.)

Publié dans : Internet
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 269
Sur SlideShare
0
Issues des intégrations
0
Intégrations
11
Actions
Partages
0
Téléchargements
29
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Foire Aux Questions sur Hitachi Content Platform

  1. 1. © Hitachi Data Systems - France 14 octobre 2016. version 2.6 Bertrand.LeQuellec@hds.com Foire Aux Questions Hitachi Content Platform L e S t o c k a g e O b j e t a u S e r v i c e d u C l o u d , d e l ’ A r c h i v a g e , d u P a r t a g e d ’ I n f o r m a t i o n e t d e l a G e s t i o n d e s C o n t e n u s Hitachi Cloud Microsoft Azure Google CloudAmazon S3 & compatible
  2. 2. © Hitachi Data Systems Cloud Storage & Objet France Sommaire PRESENTATION ET GENERALITE .....................................................................................................................1 QU’EST-CE QUE LA SOLUTION HCP ?.........................................................................................................................1 QUEL EST LE PROCESSUS D’ECRITURE ET DE CONTROLE DES DONNEES ? ...................................................................1 QUELLES SONT LES DIFFERENCES ENTRE LES MODELES HCP 300, 500 ET XL ?.........................................................2 QUELLE EST L’EVOLUTION PLANIFIEE DES HCP 300 ET 500 ?....................................................................................3 QU’EST-CE QUE LA GAMME HCP G ET S ?.................................................................................................................3 QUELLE DIFFERENCE ENTRE UN OBJET ET UN FICHIER ?............................................................................................4 QUELLE EST LA TAILLE LIMITE D’UN FICHIER DANS HCP ?........................................................................................4 EST-IL POSSIBLE DE MIXER DES NŒUDS HCP 500 AVEC DES NŒUDS HCP-G ? ..........................................................5 EST-IL POSSIBLE D’AJOUTER DES NŒUDS HCP-S A UN HCP 500 ? ............................................................................5 QUELLE EST LA REGLE DE COUPLE ENTRE LES NŒUDS HCP-S ET HCP-G?................................................................ 5 DIFFERENCES ENTRE LE STOCKAGE OBJET ET LES AUTRES FORMES DE STOCKAGE ? ................................................6 QUELLE DIFFERENCE ENTRE UNE SOLUTION HCP ET UNE SOLUTION HNAS ?...........................................................6 QUELLE S SONT LES LIMITES GENERALES ET TECHNIQUES D’UN HCP ? .....................................................................8 QUELS SONT LES POINTS FORTS D’UNE SOLUTION HCP ?...........................................................................................8 ARCHIVAGE ET VALEUR PROBATOIRE..........................................................................................................9 SAE – INFRASTRUCTURE MATERIELLE CONTRE ENVIRONNEMENT LOGICIEL ?...........................................................9 CALCUL D’EMPREINTE ET D’INTEGRITE SUR UN OBJET HCP ? ................................................................................. 10 GARANTIE D’INTEGRITE AU NIVEAU DE L’INFRASTRUCTURE DE STOCKAGE ............................................................ 11 QUELS SONT LES POINTS FORTS D’UNE SOLUTION HCP POUR UN SAE ?.................................................................. 11 COMMENT EST DETECTE LA NON SUBSTITUTION DES DONNEES ?............................................................................. 12 COMMENT CONSERVER UN HORODATAGE ISSU D’UN TIERS DE CONFIANCE ?........................................................... 12 SHREDDING – DESTRUCTION EFFECTIVE DES DONNEES ? ......................................................................................... 13 IDENTIFICATION DE LA SOURCE DE DEPOT ET EMPREINTE ASYMETRIQUE................................................................. 13 EST-CE QUE HITACHI PROPOSE UN OUTIL POUR LA COLLECTE DE LOGS ?................................................................. 14 REVERSIBILITE ET RECUPERATION DES DONNEES SANS SURCOUT ? ......................................................................... 14 COMMENT TENIR UN JOURNAL D'EVENEMENTS ? ..................................................................................................... 15 CONFORMITE A LA NORME PCI-DSS ....................................................................................................................... 16 COMMENT RESPECTER DES RECOMMANDATIONS DE LA CNIL ? ............................................................................... 17 QUELLE METHODE POUR ARCHIVER DES MESSAGES ELECTRONIQUES ? ................................................................... 17 COMMENT DEFINIR UNE RETENTION ET UNE DUREE DE VIE SUR UNE DONNEE ?....................................................... 18 QUELLE GARANTIE D’ETANCHEITE DES DONNEES EN CAS DE MUTUALISATION ?..................................................... 18 POURQUOI UTILISER HCP POUR LA VALEUR PROBATOIRE ET NON HNAS ?............................................................. 19 COMMENT EST GERE L’OBSOLESCENCE DES COMPOSANTS D’UN HCP ? .................................................................. 20 COMMENT S’ASSURER QU’UN FICHIER EST ENREGISTRE ET REPLIQUE ?................................................................... 21 EST-IL POSSIBLE DE MIGRER DES DONNEES DEPUIS EMC CENTERA VERS HCP ?..................................................... 21 EST-IL POSSIBLE DE RECUPERER DES DONNEES DE MANIERE ALEATOIRE ? .............................................................. 24 PROTECTION ET DISPONIBILITE .................................................................................................................... 25 QUELLE PROTECTION SYNCHRONE ET ASYNCHRONE ?............................................................................................. 25 REPLICA – COMMENT DUPLIQUER EN INTERNE DES DONNEES ?................................................................................ 25 REPLICATION – COMMENT DUPLIQUER EN EXTERNE DES DONNEES ?....................................................................... 25 REPLICATION – TRANSFERT EN MODE BLOC ? .......................................................................................................... 25 REPLICATION – LES TOPOLOGIES SUPPORTEES ? ...................................................................................................... 26 SYNCHRONISATION MULTI-SITES – GLOBAL ACCESS TOPOLOGY ?......................................................................... 27 REPLICATION - QUELLE DISTANCE LIMITE ?............................................................................................................. 28 COMMENT ENCODER DES DONNEES SUR LE SUPPORT DISQUE ?................................................................................ 28 REPLICATION - COMMENT EST GERE LE RECOUVREMENT D’UNE DONNEE ? ............................................................. 29 REPLICATION - COMMENT EST GERE LE FAILOVER HCP ?........................................................................................ 29 CLOUD STORAGE ET STOCKAGE OBJETS.................................................................................................... 31 QUELLE INTERACTION AVEC D’AUTRES CLOUD ET ACCES UNIVERSEL ?.................................................................. 31 XAM ET HCP – COMPLEMENTARITE OU OPPOSITION ?............................................................................................ 31 EST-CE QU’HCP SUPPORTE UN MODE D’ACCES DE TYPE AMAZON S3 ?................................................................... 32 QUELLES DEFINITIONS DES DROITS D’ACCES AUX OBJETS ? .................................................................................... 32
  3. 3. © Hitachi Data Systems Cloud Storage & Objet France COMMENT SE PROTEGER DE L’EFFACEMENT ACCIDENTEL DE DONNEES ?................................................................ 33 SYNCHRONISATION ET PARTAGE DE FICHIERS EN NOMADISME ................................................................................ 33 LIMITES FONCTIONNELLE DE LA SOLUTION HCP ANYWHERE.................................................................................. 35 ACTIONS GLOBALES REALISABLES PAR L’UTILISATEUR AVEC HCP ANYWHERE..................................................... 35 ACTIONS REALISABLES PAR LE CLIENT HCP ANYWHERE ....................................................................................... 36 ACTIONS REALISABLES PAR L’ADMINISTRATEUR AVEC HCP ANYWHERE............................................................... 37 ARCHITECTURE ET DEPLOIEMENT IT.......................................................................................................... 38 QUELLE METHODE DE CHANGEMENT DE SUPPORT PHYSIQUE ? ................................................................................ 38 COMMENT EXTERNALISER DES DONNEES DU HCP VERS DES BANDES ?................................................................... 38 EST-IL POSSIBLE D’INSTALLER HCP COMME TIERS EXTERNE DU HNAS ................................................................. 39 MAINTENANCE DES SUPPORTS DE STOCKAGE .......................................................................................................... 40 COMMENT GERER UN PARTAGE MIXTE ET DES DROITS CIFS-NFS ?......................................................................... 40 EST-IL POSSIBLE D’ACCEDER AUX DONNEES EN CIFS-NFS SUR LES NAMESPACES ?............................................... 41 COMMENT MIGRER DES DONNEES ET DES METADONNEES ? ..................................................................................... 41 QUELLE TECHNOLOGIE POUR OPTIMISER ET DE REDUIRE LA VOLUMETRIE ?............................................................ 42 ENVIRONNEMENT DE TESTS OU PRE PRODUCTION : QUELLE SOLUTION ? ................................................................. 43 PERFORMANCES................................................................................................................................................... 45 QUELLES SONT LES PERFORMANCES D’INGESTION ET DE CONSULTATION ? ............................................................. 45 PERFORMANCE HTTP ET LOAD BALANCING DU HCP ............................................................................................. 46 SOLUTIONS ET EXTENSIONS FONCTIONNELLES ...................................................................................... 47 HITACHI DATA INGESTOR – ACCES CIFS-NFS ET LE MODE ROBO ? ...................................................................... 47 QUELLE CONFIGURATION VMWARE MINIMALE POUR LA VM HDI ?....................................................................... 47 LA GESTION DES DONNEES ET LES FLUX ENTRE HDI ET HCP SONT-ILS OPTIMISES ?................................................ 48 COMMENT MESURER LA BANDE PASSANTE NECESSAIRE ENTRE HDI ET HCP ? ....................................................... 48 EXISTE-IL DES ABAQUES DE PERFORMANCES ENTRE HDI ET HCP ? ........................................................................ 49 ADMINISTRATION ET SUPERVISION.............................................................................................................. 50 SUPERVISION DU STOCKAGE HCP PAR HI-TRACK ................................................................................................... 50 COMMENT METTRE A JOUR LE SYSTEME INTERNE ? ................................................................................................. 50 ADMINISTRATION DE LA PLATE-FORME ................................................................................................................... 51 LISTE DES PRINCIPAUX PORTS DE COMMUNICATION UTILISES DANS HCP................................................................ 51 ADMINISTRATION DU STOCKAGE AU SEIN DU HCP .................................................................................................. 51 PROGRAMMATION ET INTEGRATION APPLICATIVE .............................................................................. 52 QUELLE CAPACITE DE DEVELOPPEMENT ET D’INTEGRATION LOGICIELLE ?.............................................................. 52 INTEGRATION ET DEVELOPPEMENT LOGICIEL AVEC LA SOLUTION HCP................................................................... 52 QUELLE CAPACITE DE DEVELOPPEMENT SUR L’ADMINISTRATION DU HCP ?........................................................... 53 COMMENT REALISER DES RECHERCHES SUR LES METADONNEES ?........................................................................... 54 COMMENT RECUPERER DES RAPPORTS EN VUE D’UNE FACTURATION ?.................................................................... 55 QUELLES SONT LES PRINCIPALES REQUETES HTTP SUPPORTEES PAR HCP ?........................................................... 55 EST-CE QU’IL EXISTE UN SDK POUR HCP ?............................................................................................................. 56 FONCTIONNELS INTEGRES AU STOCKAGE OBJET-CLOUD HITACHI................................................. 57 INTEGRITE................................................................................................................................................................ 57 CONFIDENTIALITE.................................................................................................................................................... 57 PERENNITE............................................................................................................................................................... 57 DISPONIBILITE ......................................................................................................................................................... 58 ACCESSIBILITE......................................................................................................................................................... 58 REGLEMENTATION................................................................................................................................................... 59 HISTORIQUE DES VERSIONS DE LA SOLUTION HCP, 2006 A 2008. ........................................................................... 60
  4. 4. © Hitachi Data Systems Cloud Storage & Objet France Hitachi Content Platform1 est la réponse d’Hitachi Data Systems aux préoccupations de partages de fichiers, de stockage objet et d’archivage (réglementaire ou pas), pour la mise en œuvre d’une infrastructure de stockage dédiée à la conservation et l’échange au sein d’un système d’information pour la gestion de contenus. Hitachi Content Platform est aussi la réponse Hitachi aux besoins de consolidation, de volume important, de simplification I et de facilité à la mise à disposition d’un service avancé de stockage objets en mode Web. La solution Hitachi Content Platform est aussi déclinée en offre verticale, afin d’adresser des besoins métiers spécifiques, telle que la solution Hitachi Clinical Repository dédiée aux établissements de santé. « An object is a logical collection of bytes with attributes and security policies. Unlike file or block- based storage, object storage files, images and data blocks are stored as individual objects or as elements of an object, and are associated with a unique identifier. Unique identifications are created via hash algorithms and maintained in an index database. », Gartner, Hype Cycle for Storage Technologies, du 13 Juillet 2015. G00277799. « The new wave of object-based storage [that] has been developed for distributed cloud use is cost- optimized—which is key for clouds—and accessed via HTTP protocols. », Pushan Rinnen, research director at Stamford, Conn.-based Gartner Inc. Storage Magazine, Vol. 11 N°4 June 2012. « The best move HDS ever made was acquiring Archivas, developer of what is now known as the Hitachi Content Platform (HCP). A crossover between content-addressable storage (CAS) and the new generation of cloud storage systems, HCP is an excellent product for next-generation enterprise applications, with an HTTP/REST interface, object-level metadata-driven storage, and solid credentials for reliability. », le 6 avril 2011 par Stephen FOSKETT, sur son Blog « Understanding the accumulation of data » – blog.fosketts.net. 1 Pour les détails de valeurs techniques et de dimensionnement, le lecteur doit se reporter à deux autres documents Hitachi en français : le Quick Réf. et le White Paper HCP. Le premier propose principalement une orientation dimensionnement des déclinaisons produits et des différents supports applicatifs et protocoles. Le White Paper donne un descriptif très exhaustif et détaillé de la solution HCP. Il existe ensuite la large documentation officielle disponible en ligne depuis l’interface Web d’administration et d’utilisation de la solution HCP. COMPATIBLE
  5. 5. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r é s e n t a t i o n e t g é n é r a l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 1 France PRESENTATION ET GENERALITE QU’EST-CE QUE LA SOLUTION HCP ? La solution Hitachi Content Platform est d’abord un produit dit Appliance, c’est-à- dire tout-en-un matériel et logiciel, dont l’objectif principal est de proposer un espace de stockage partagé en mode Fichier. Il est accessible via des protocoles standards IP, incluant des services avancés de politique de conservation, d’analyse et d’autoprotection des contenus. Le partage en mode fichier signifie que l’interaction, avec les autres plates- formes applicatives de l’entreprise, se réalise par l’intermédiaire d’un système classique de fichiers. La solution HCP propose une mise à disposition de volumétrie public, privé et/ou cloisonnée avec ou sans quota. La différenciation, vis-à-vis de la commodité d’un NAS traditionnel, réside dans les services automatisés et intégrés, afin de proposer un nouveau type de stockage dit Objet. Un Objet est constitué du fichier source, de ses métadonnées dites Système (date, taille, type, etc.), de ses métadonnées dites Métier (descriptif du contenu, empreinte-hash, etc.) et de ses politiques de gestion (rétention, réplication, indexation, version, suppression, etc.). Hitachi Content Platform se comporte comme un Service. Il ne s’agit pas de déduire une utilisation brute d’un stockage et d’en bâtir son optimisation, mais de consommer une prestation au regard d’un besoin de production applicative. Le Système Objet du HCP propose des services de stockage très attractifs incluant une évolutivité quasi illimité, une forte résilience, une grande capacité de traitement de données, une prise en charge des métadonnées, une proportion à utiliser du stockage dit low-cost, une haute disponibilité et un accès via les protocoles Web HTTPs (REST, WebDAV, cURL, S3, …). HCP est donc parfaitement adapté aux environnements : Web 2.0, réseaux sociaux, d’archivage, de sauvegarde et fichier, de toute nature et, principalement, au partage de contenus multimédia, tels que les images et les vidéos. QUEL EST LE PROCESSUS D’ECRITURE ET DE CONTROLE DES DONNEES ? Tout d'abord l'écriture des données est réalisée via le réseau IP de l'entreprise par l’un des protocoles activés (CIFS, NFS, HTTPs, SMTP, …). Dès réception complète de la donnée, sa prise en compte par HCP débute par le calcul d’une empreinte avec un des algorithmes du HCP (au choix MD5, SHA, etc.) L'empreinte est enregistrée dans la partie métadonnée dédiée aux informations système (core-metadata.xml). L’accès aux espaces de noms (Tenant/Namespace) HCP est réalisé via des protocoles IP standards (HTTPs, CIFS, NFS, SMTP, …) non propriétaires. Dans une logique WORM et une fois le dépôt effectué, le nom du fichier et son contenu ne peuvent être changés. Tout au long de la conservation du fichier, un processus spécifique (nommé Scavenging) interne à la plate-forme HCP
  6. 6. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r é s e n t a t i o n e t g é n é r a l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 2 France effectue des vérifications sur son intégrité. Une vérification est aussi réalisée lors d'un accès en lecture au fichier. Par exemple, pour la partie accès CIFS, HCP utilise des codes retours associés à ce protocole, comme le NT_STATUS_ACCESS_DENIED. Ce code retour est renvoyé pour refuser les opérations suivantes : renommer un objet 2 ; renommer ou détruire un répertoire qui contient au moins un objet ; écraser un objet ; modifier le contenu d'un objet ; détruire un objet sous rétention ; ajouter un fichier dans la partie métadonnées à l'exception du fichier custom- metadata.xml ; détruire un fichier ou un répertoire Métadonnée et créer un lien. Ces interdictions sont une liste des actions qui permettent de garantir qu’il n’y a aucune possibilité de substitution des données. QUELLES SONT LES DIFFERENCES ENTRE LES MODELES HCP 300, 500 ET XL ? La solution Hitachi Content Platform est disponible sous plusieurs labellisations qui correspondent à des modèles distincts au niveau matériel. Les modèles 300, 500 et 500 XL ne sont plus disponibles depuis Décembre 2015. Ils ont été remplacés par les HCP des gammes G et S. Le modèle HCP 300 est constitué de serveurs de traitements avec des disques internes organisés en RAID-6 ; le modèle HCP 500 est constitué de serveurs ou de serveurs Blade avec un stockage externe sur des baies Hitachi AMS, HUS, VSP et/ou un espace tiers via la virtualisation de stockage ; et le modèle HCP 500 XL est équivalent au modèle HCP 500, mais embarque des disques supplémentaires dans les serveurs, afin d’apporter un gain de traitement dédié au métadonnées. HCP 300 HCP 500 & 500 XL Aperçu général Architecture RAIN. Simple à déployer pour un modèle Appliance avec un stockage embarqué par serveur. Architecture SAIN3 . Offre un maximum de flexibilité de performance et d’évolution matérielle via le stockage Hitachi. Évolutivité Jusqu’à 85To utiles en DPL2 Jusqu’à 140To utiles en DPL1 Jusqu’à 40Po utiles en standard. 80Po après validation Hitachi. Stockage supporté Stockage intégré au sein des serveurs (Node) de l’Appliance Hitachi Content Platform. Hitachi Virtual Storage Platform. Hitachi Universal Storage Platform® V. Hitachi Universal Storage Platform VM. Hitachi Unified Storage. Hitachi Unified Storage VM. Hitachi Adaptable Modular Storage. Hitachi Workgroup Modular Storage. Une seconde caractéristique diffère les modèles. Le HCP 300 est configuré de base avec un Réplica. C’est-à-dire que chaque donnée enregistrée est systématiquement doublée en interne, cela signifie que chaque configuration HCP 300, donnée pour un volume utile, est systématiquement doublée en interne. Une configuration HCP 300, vendue pour 4To utilisables, est livrée avec 8To utiles et ainsi de suite pour les configurations supérieures. Ce choix de base du premier Réplica n’est pas modifiable. Par contre, il est permis de définir des Réplicas supplémentaires dans le cadre de la configuration des espaces de noms (Namespace) au sein de Tenants. Les modèles HCP 500 et 500 XL sont aussi configurables avec des Réplicas, mais de base aucun n’est défini à la livraison. Le choix du nombre de Réplica est donc libre à la configuration. Il convient alors d’adapter la volumétrie disponible aux estimations des Réplicas souhaités. L’interface d’administration du HCP 2 Un objet HCP correspond au fichier source, aux métadonnées systèmes (politique de sécurisation et de conservation), aux métadonnées métiers et aux éventuels Réplicas. 3 SAN-attached Array of Independent Nodes
  7. 7. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r é s e n t a t i o n e t g é n é r a l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 3 France propose un tableau de bord de suivi de l’historique de consommation des espaces de stockage, afin de prévenir les évolutions et les tendances. Cette consommation est automatiquement pondérée par les services de compression et de déduplication. QUELLE EST L’EVOLUTION PLANIFIEE DES HCP 300 ET 500 ? QU’EST-CE QUE LA GAMME HCP G ET S ? En 2015, la solution Hitachi Content Platform a changé vers de nouveaux modèles traduisant une évolution technique et fonctionnelle. Depuis la version 7.2 du système HCP, de nouveaux serveurs physiques ont remplacés ceux des modèles 300 et 5004 . Ces nouveaux serveurs sont nommés HCP-Gxx et HCP-Sxx. Ils proposent d’associer les qualités des gammes 300 et 500 au sein d’une même architecture. C’est-à-dire la possibilité de créer des combinaisons avec du stockage interne et externe (IP et FC), de choisir les ports IP en 1GbE ou 10GbE et d’introduire un niveau de performance supplémentaire avec des processeurs Intel plus puissant, une plus grande capacité mémoire évolutive et des disques Flash en option. Les Nodes S sont dédiés à des besoins de de fortes capacités et les Nodes G assurent la performance fonctionnelle avec le Système d’Information de l’entreprise. Pour le stockage externe, il est soit de nature classique sur des volumétries RAID-6 accessibles via un réseau SAN FC, soit de nature plus moderne, sur des 4 Une configuration HCP 500 peut être complétée avec des Nodes HCP-G et HCP-S.
  8. 8. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r é s e n t a t i o n e t g é n é r a l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 4 France volumétries protégées par une technologie dite Erasure Coding et accessibles uniquement par le réseau IP. A ces deux espaces de stockage, il est possible d’utiliser du stockage interne aux Nodes et aussi du stockage externalisé dans un Cloud Public, tels que Microsoft Azure, Amazon S3 et Google. L’entreprise peut alors définir des politiques de placement de la donnée en fonction de sa criticité, performance et disponibilité. La base d’une configuration HCP est constituée de Nodes G avec du stockage interne. Les Nodes S ainsi que l’utilisation de stockage Cloud Public sont optionnels. La volumétrie maximale de base ne change pas pour atteindre 80Po, mais il est possible de compléter cette volumétrie avec une capacité pouvant aller au-delà des 400Po utiles. Cette extension de volumétrie est gérée par les Nodes HCP-Sxx. QUELLE DIFFERENCE ENTRE UN OBJET ET UN FICHIER ? La notion d’Objet est identique à la notion de fichier, mais avec une information complémentaire nommée Métadonnée Personnalisée ou Métier, à différencier de la métadonnée dite système. La solution Hitachi Content Platform est un système de Stockage Objet et gère donc les fichiers et les métadonnées systèmes et personnalisées associées. Exemple d’une description d’un Objet par rapport à un Fichier. Une métadonnée personnalisée ou métier est constituée d’information textuelle apportant un complément d’information sur le fichier, mais peut contenir aussi des politiques de gestion de ce fichier, comme son mode de conservation et de diffusion ou une empreinte électronique pour, par exemple, désigner une signature d’intégrité du contenu du fichier. QUELLE EST LA TAILLE LIMITE D’UN FICHIER DANS HCP ? La taille limite d’un fichier dans HCP est dépendante du protocole utilisé, c’est à- dire que le protocole impose une taille d’enregistrement et donc de lecture. Protocole Max HTTP (RESTful) – WebDAV, cURL, HS3 et HSwift. 2 To CIFS (SMB) 100 Go NFS – au-delà de cette valeur, les performances sont fortement impactées. 100 Go SMTP, avec attachements. 500 Mo Nombre d’attachement par email en SMTP 50
  9. 9. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r é s e n t a t i o n e t g é n é r a l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 5 France EST-IL POSSIBLE DE MIXER DES NŒUDS HCP 500 AVEC DES NŒUDS HCP-G ? La réponse simple est oui, un HCP 500 ou un HCP 500 XL peut étendre son nombre de nœuds avec des nœuds HCP-G. Il convient tout de même de mettre à jour en mémoire les nœuds du HCP 500. EST-IL POSSIBLE D’AJOUTER DES NŒUDS HCP-S A UN HCP 500 ? La réponse est oui, les nœuds HCP-Sxx implique uniquement d’utiliser au minimum une version 7.x. Les Nœuds HCP-S n’ont aucune relation d’architecture physique avec les nœuds HCP 500 et les nœuds HCP-G. Seule le réseau IP de l’entreprise est utilisé pour gérer la volumétrie entre les deux types d’équipements physiques. QUELLE EST LA REGLE DE COUPLE ENTRE LES NŒUDS HCP-S ET HCP-G? Depuis la version 7, la principale nouveauté des composants physiques HCP est la mise en œuvre d’une architecture à base de HCP-G, dédiés à la performance, qui peuvent être secondés par des nœuds HCP-S, dédiés au stockage capacitif. Le logiciel HCP gère alors le déplacement des données entre les nœuds G et les nœuds S. Cette gestion du déplacement, ou Tiering, est nommé Service Plan, qui est le fonctionnel définissant les politiques de placement des données. Organisation des tiers de stockage entre les nœuds HCP G, S et les Clouds externes. Généralement, l’utilisation d’un Service Plan consiste à déplacer les données en fonction de leur âge et de leur utilisation. Les données les plus anciennes et les moins utilisées sont déplacées vers le stockage capacitif, alors que les plus récentes et les plus utilisées restent sur le stockage performant. Il s’agit d’une règle générique, car il est aussi possible de définir un placement direct vers le capacitif, c’est-à-dire les nœuds S, sans stockage préalable sur les nœuds G. Le Service Plan gère aussi le placement des données en externe du HCP, vers des stockages Cloud (Google, Amazon, Microsoft et compatibles) ou des partages réseau NFS (NAS classique, Scale-out NAS et Disk-to-Tape NAS). HCP peut donc ne pas être le stockage principal des données, mais uniquement leur gestionnaire : métadonnées, indexation, disponibilité, etc.
  10. 10. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r é s e n t a t i o n e t g é n é r a l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 6 France DIFFERENCES ENTRE LE STOCKAGE OBJET ET LES AUTRES FORMES DE STOCKAGE ? Objet Fichier Bloc Unité d’échange Objet : fichier avec des métadonnées métier Fichier Bloc Mise à jour de l’information Création d’un nouvel objet Remplacement de l’existant Remplacement de l’existant Protocoles prioritaires pour les Data HTTP/HTTPs via REST et ses déclinaisons : WebDAV, S3, Swift, … CIFS (SMB) et NFS Fibre Channel et SAS Protocoles possibles pour les Data SMTP, CIFS et NFS FTP et iSCSI iSCSI et FCoE Métadonnée Métadonnées Systèmes : attributs système de fichiers. Métadonnées Métier : information personnalisée Attributs système de fichiers Attributs système Organisation Hiérarchique (File System) et containeur fortement sécurisé (Tenant et plus) Hiérarchique (File System) et espace de partage (Share) Bloc (Disque) et volume de blocs (LUNs). Orientation idéale Fichiers relativement statiques, tel que l’archivage, partage de fichiers, Cloud Storage et Stockage Web Partage de fichiers Données transactionnelles et fréquemment modifiées Force Évolutivité, accès distribués et gestion très souple et agile. Accès simplifié, commodité des partages et gestion simplifiée Haute et très haute performance Limitation Ne convient pas aux fréquences de changement des données transactionnelles Difficulté à s’étendre au- delà du Data Center Difficulté à s’étendre au- delà du Data Center et complexité de gestion. Réseau de production IP uniquement sans limitation de distance : LAN, WAN et WW. IP avec des contraintes de distance : LAN principalement et WAN avec des équipements complémentaires. FC sur des distances mesurées. QUELLE DIFFERENCE ENTRE UNE SOLUTION HCP ET UNE SOLUTION HNAS ? De manière générale, HCP se comporte en grande partie comme une solution de partage de fichiers NAS. Le support des protocoles CIFS et NFS confortent cette position. Le choix peut donc se poser au sein du catalogue Hitachi entre HNAS et HCP. Tout d’abord HNAS est résolument développé pour servir toutes les commodités d’une solution NAS traditionnelle, du support du Snapshot et iSCSI, en passant par les logiciels Anti-Virus, les solutions de virtualisation telle que VMware et jusqu’à la création de partage réseau spécifique. Cette orientation n’est pas la genèse de la solution HCP dont l’orientation matérielle et logicielle a été pensée dans un but de conservation-archivage et de partage Cloud au de-là du réseau LAN de l’entreprise. Le tableau suivant donne un aperçu général des principaux fonctionnels entre les deux solutions, dont la complémentarité existe au travers d’une gestion de Tiers de stockage automatique, via l’option HSM intégrée au HNAS.
  11. 11. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r é s e n t a t i o n e t g é n é r a l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 7 France Fonctionnel HCP HNAS Déclinaison modèle VM, G et S. HNAS série 4000 DICOM, HL7 et XDS Oui (option) Non CIFS SMB Oui, v2 en direct et v2/3 via HDI Oui, v2 et v3 NFS Oui, v3 en direct et v3/4 via HDI Oui, v3 et v4 FTP Oui, via l’option HDI Oui iSCSI Non Oui (option) Réception email via SMTP Oui Non HTTP REST/WebDAV/S3 Oui Non Mode CLI Oui Oui Chargeback Oui Non WORM logique/rétention Fichier File System (option) Annuaire Active Directory Niveau accès Tenant/Namespace HDI niveaux accès et données Niveaux accès et données Taille max. FS 4To à +400Po 4 (4060) à 32 Po (4100) Nombre de fichiers +64 milliards 6 milliards Accès WAN Oui Non (directement) Anti-Virus Non, sauf option HDI et HCPA Oui Cluster Name Space Oui Oui (option) Réplication asynchrone Mode fichier/objet Oui, Mode bloc et fichier (option) Réplication synchrone Différé continu Oui , Mode bloc (option) Métadonnées métier Oui Non Cloisonnement logique Tenant/Namespace (x10 000) EVS (x64 niveau annuaire) Performance Lié au nombre de nœuds Haute performance IOPS Shredding Oui Non RADIUS Oui Oui Journaux et Suivis Syslog, Email, Logs, Chargeback & MIB SNMP. Syslog, FS Audit & MIB SNMP Droits ACLs Non (CIFS/NFS) - Oui (Objet) Oui (CIFS/NFS) – Non (Objet) Snapshot Non Oui Réplica fichier Oui (2 à 4), au niveau Namespace Non Versioning Oui Non Déduplication Oui (SIS) Oui (mode Bloc) Compression Oui Oui Empreinte HASH Oui Non Indexation Métadonnées Oui (Metadata Query Engine) Non Indexation Données Non, solution tierce nécessaire Non, solution tierce nécessaire Miroir Oui via Réplica Oui (option) File Tiering (mode HSM) Oui de base : HCP-S, NFS, Amazon S3, Google & MS Azure Oui, en option : interne, NFS, HCP et Amazon S3.
  12. 12. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r é s e n t a t i o n e t g é n é r a l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 8 France QUELLE S SONT LES LIMITES GENERALES ET TECHNIQUES D’UN HCP ? L’organisation de l’architecture interne d’une solution HCP implique des limites techniques liées aux composants physiques et à l’environnement logiciel de gestion. Ces valeurs évoluent au grés des versions HCP, il peut donc être utile d’en confirmer certaines avant un nouveau projet de stockage objets. Information Limite Taille d’un Volume Logique (mode SAIN) 15,999 To Nombre de Volumes Logiques par Storage Node en architecture SAIN 63 Nombre de Volumes Logiques par Storage Node VM (HCP-VM) 59 Nombre de Volumes Logiques par Storage Node en architecture RAIN (HCP 300) 3 Nombre de Serveurs (Storage Node) par HCP-G 80 Nombre de Serveurs (Storage Node) par HCP-S 80 Nombre d’Objets (fichier) par Node HCP-G 800 000 000 Nombre de répertoire par Serveur (Storage Node) 1 500 000 Nombre d’Objets (fichier) par répertoire 15 000 000 Nombre d’Objets (fichier par système Hitachi Content Platform 64 000 000 000 Nombre de Tenant par HCP 1 000 Nombre de Namespace par HCP 10 000 Nombre de comptes utilisateur décris dans un fichier de correspondance (user mapping) 1 000 Nombre d’éléments XML dans une annotation individuelle 10 000 Nombre de niveau XML dans une annotation individuelle 1000 Nombre d’annotations par objet 10 Ce tableau est un extrait des valeurs les plus générales. Le document en Français « HCP Quick Réf. » est plus complet en détails et caractéristiques internes. QUELS SONT LES POINTS FORTS D’UNE SOLUTION HCP ? Les points forts caractérisant une solution HCP sont les suivants :  Forte évolutivité en performance et volume de stockage ;  Haute disponibilité d’accès en écriture et lecture ;  Redondance locale et distante multi sites sur les données ;  Sécurisation et cloisonnement des accès par Tenant ;  Non adhérence aux contraintes de distance du réseau LAN/WAN ;  Facilité d’intégration applicative, pour la lecture et l’écriture de données ;  Ouverture vers une intégration sans API propriétaire ;  Suivi des charges et aide à la construction de rapport d’utilisation ;  Capacité de protection par l’encodage des données sur disque ;  Fonctionnel d’optimisation par compression et Single Instance ;  Gestion de placement de la donnée par pools internes et externes ;  Appliance tout-en-un réunissant matériel et logiciel embarqué ;  Solution uniquement logicielle via des images VMware ;  Alternative aux serveurs NAS, via l’utilisation du mode Web ;  Versioning local et distant sur les données ;  Automatisation du Failover et Failback via un Global Access (GAT) ;  Intégration avec les architectures Open Source, telle qu’OpenStack via Swift (incluant Keystone et Glance).  …
  13. 13. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 9 France ARCHIVAGE ET VALEUR PROBATOIRE SAE – INFRASTRUCTURE MATERIELLE CONTRE ENVIRONNEMENT LOGICIEL ? La notion d’archivage et plus encore d’archivage électronique est un concept de mieux en mieux accepté par les entreprises. Mettre en place une solution d’archivage permet en effet de répondre à la fois aux exigences des réglementations et aux contraintes informatiques, en gérant de manière intelligente le stockage, l'administration, la recherche et l’exploitation des informations. L’archivage fait partie intégrante du système d’information de l’entreprise. Ainsi de la performance de l’archivage dépend une bonne part de la qualité du système d’information dans son ensemble. La mise en place d’un système d’archivage permet de conserver une copie unique des données et ainsi de réduire de façon drastique le coût des sauvegardes et du stockage, sans oublier une capacité de recherche efficace et fiable. Au regard d’un Système d’Archivage Électronique, le positionnement de la solution Hitachi Content Platform est résolument placé au niveau de l’infrastructure de stockage. Dans le cadre d’un projet d’archivage à valeur probatoire, la confusion existe du fait de l’emploi de terminologie mis en avant à tous les niveaux du processus de vente : pérennité, conservation stricte, rétention, traçabilité, empreinte/signature, sécurité, WORM, etc. Cette utilisation est normale et correspond à un positionnement vertical permettant aux utilisateurs, et leurs entreprises, de situer le domaine d’une proposition produit. Mais le fait d’utiliser tel ou tel autre terme, dans la description d’un produit, ne signifie pas que la valeur de preuve se trouve uniquement dans une interface logicielle ou dans un support matériel. Portail utilisateur (logiciel) Stockage Physique (matériel) Gestion des comptes utilisateurs. Gestion des espaces de stockage. Processus métier de dépôt et consultation. WORM logique avec gestion de la rétention. Empreinte et contrôle continu avec impact. Empreinte et contrôle continu sans impact . Conservation des activités utilisateurs (log). Conservation des activités sur l’infrastructure (log). Conservation des Métadonnées. Conservation des Métadonnées. Contrôle des accès aux Données. Conservation des Données. Métadonnées liées à l’environnement. Stockage des Métadonnées quasi illimité. Indexation unique dans l’application. Indexation multi applications. Cluster actif/passif (pas toujours possible). Géo Cluster actif/actif. Sécurisation des accès à la base applicative. Sécurisation du système de fichiers. Réversibilité dépendante de l’application. Réversibilité indépendante des applications. Software–as–a–Service (SaaS). STorage –as–a–Service (STaaS : Cloud Storage). Copie « synchrone » sur support multiple. Réplication asynchrone et Réplica synchrone sur site Cycle de vie/Déplacement des données avec impact Cycle de vie/Déplacement des données sans impact. Encodage physique des supports. Architecture Remote Office Branch Office (ROBO). Shredding certifié des Données et Métadonnées. Cloisonnement applicatifs (Tenant) et quota. Aperçu des différentiations et des complémentarités entre l’environnement logiciel applicatif de l’utilisateur et l’infrastructure matérielle à associer à la chaine de traitement et de conservation au sein d’un Système d’Archivage dit Electronique.
  14. 14. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 10 France L’ascendant est nécessairement dans la corrélation entre le niveau dit utilisateur (le visuel de « confiance » graphique et sa gestion) et l’infrastructure de réception (le support « non visible » et souvent minimisé) qui donne toute la valeur de réussite à un projet d’archivage. Dans le cadre d’un archivage a valeur probatoire, mais aussi administratif, patrimonial ou culturel, c’est-à-dire nécessitant le respect de normes internationales, telle qu’ISO 14721 résultante du modèle OAIS, ou nationales, telle que la NFZ42-013:2009, le support d’enregistrement des données doit être de type WORM (physique ou logique) associé aux exigences de stabilités, de pérennité, de performance, de diffusion et de migration. La solution Hitachi Content Platform intègre justement un service de support WORM logique. Sa finalité est de répondre aux enjeux réglementaires et normatifs en associant, entre autres, des réponses aux problématiques d’évolutivité de l’infrastructure et de destruction effective de la donnée (Shredding), qui ont un impact sur la qualité finale du service à exécuter. Dans le cadre d’utilisation non probatoire liée uniquement à la fonction de stockage objet et de partage Cloud par HCP, ou bien de réponse singulière par une interface et une organisation métier, la mise en relation indivisible (logiciel et matériel) est moins pertinente et dépend, en priorité, de réponses sur l’amélioration du Service et de la Production. Mais en lisant certains articles d’experts de sociétés de Consulting & Audit5 , d’associations reconnues6 ou d’information ministérielle7 , la conservation sur des serveurs de stockage classique, seraient une « funeste erreur »8 . Il s’agit donc bien de considérer l’élément de support non pas comme un paramètre mineur, mais comme un élément à intégrer dans la réflexion et la chaine complète de vie et de conservation de la donnée. L’environnement logiciel et matériel ne sont ni l’un ni l’autre un gage ou une simplification unique de pérennité, mais des outils dépendants de l’environnement économique, décisionnel et politique. Ils sont adaptés à une période technologique. Il appartient donc à l’entreprise de prendre acte de cette dimension et de s’assurer de la réelle souveraineté de sa donnée. Du fait de sa conception, dès la première version, Hitachi Content Platform se projette entièrement dans cette vision, où les coûts d’utilisation et de migration, c’est-à- dire d’indépendance, sont réellement maitrisés. L’acte d’archivage, au sens large, est alors une aubaine organisationnelle pour les entreprises. CALCUL D’EMPREINTE ET D’INTEGRITE SUR UN OBJET HCP ? Hitachi Content Platform calcule une empreinte pour chaque fichier mis en dépôt. Le choix de l’algorithme d’empreinte (SHA, MD5, etc.) est déterminé par l’entreprise ou l’application métier à la configuration de chaque Tenant. Le hash résultant fait partie de la représentation des métadonnées sur un fichier archivé. L’ensemble fichier et métadonnées représente l’Object HCP. Chaque fichier Métadonnées est dupliqué en interne, mais aussi signé (second calcul de hash) pour assurer son intégrité. Le dernier calcul concerne l’objet HCP, c’est-à-dire le couple Donnée et Métadonnées. Seule l’empreinte sur le fichier principal est accessible. Les autres empreintes sont stockées en interne du HCP et servent lors des contrôles d’intégrité. 5 Livre blanc : Archivage Électronique et Conformité Réglementaire : www.serda.com 6 Fédération de l’ILM, du Stockage et de l’Archivage : www.fedisa.eu 7 Voir rapport rendu par l'Académie scientifique et la déclaration de Nathalie Kosciusko-Morizet. La ministre de l'Économie numérique. 8 Décision-Achats.fr N°142 du premier mars 2011.
  15. 15. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 11 France En résumé, un objet HCP est constitué du fichier d’origine, de métadonnées (système et personnalisé) et d’une copie des métadonnées (MDPL9 ). Il y a une empreinte accessible sur le fichier, une empreinte non accessible sur les métadonnées (SHA-256 par défaut) et une autre empreinte non accessible sur l’objet. Le MDPL diffère du DPL10 , ce dernier est paramétrable en tant que politique de sécurisation et d’administration, alors que le niveau du MDPL est défini en interne et non accessible à l’administration. L’utilisation de l’empreinte HCP a aussi un objectif de contrôle externe. En effet, lors du dépôt d’un fichier, le retour de succès de cette écriture est de renvoyer cette empreinte. Ainsi l’application déposant un fichier à la possibilité de comparer l’empreinte renvoyer du HCP avec celle que l’application aura calculée avant de réaliser l’écriture. Si la comparaison est bonne cela signifie que le fichier enregistré est cohérent avec la source. GARANTIE D’INTEGRITE AU NIVEAU DE L’INFRASTRUCTURE DE STOCKAGE La solution HCP assure et garantit l’intégrité des données par la mise en œuvre des services suivants :  Calcul d’une empreinte (hash) sur chaque information (donnée fichier et métadonnées associées) ;  Gestion logique de l’immuabilité (WORM) de la donnée ;  Détection d’altération par le contrôle dans le temps de l’information ;  Tenu d’un journal d’évènements (Syslog et SNMP) ;  Mécanismes de protection (RAID-6, Réplica & Réplication) ;  Capacité de sécurisation par l’encodage des disques (AES) ;  Séparation entre l’accès Administration et l’accès Donnée (Rôle) ;  Intégration obligatoire avec des serveurs de temps (NTP) ;  Sécurisation et authentification des accès (SSL) ; QUELS SONT LES POINTS FORTS D’UNE SOLUTION HCP POUR UN SAE ? Les points forts caractérisant une solution HCP pour un SAE sont les suivants :  WORM logique natif dans la solution ;  Conservation par rétention unitaire ou classe de rétention ;  Calcul d’empreinte sur chaque donnée ;  Redondance locale et distante multi sites sur les données ;  Sécurisation et cloisonnement des accès par Tenant ;  Facilité d’intégration applicative, pour la lecture et l’écriture de données ;  Ouverture vers une intégration sans API propriétaire ;  Aide à la réversibilité, pour la migration vers d’autres solutions ;  Contrôle automatique de l’intégrité des données ;  Traçabilité des activités de la solution ;  Effacement par Shredding ;  Prise en charge de métadonnées dites métier ;  Conservation de métadonnées dites systèmes, comme la date de dépôt ;  Plan de classement ouvert à travers une arborescence de fichiers ;  Indexation évoluée sur les métadonnées via un moteur interne ;  Capacité à recevoir des emails via SMTP et à les stocker en fichier EML11 ;  … ; 9 Metadata Protection Level : niveau de protection automatisée des métadonnées toujours à 2 copies au minimum. 10 Data Protection Level : détermine la politique de protection à travers un nombre de copies autogérées par HCP. 11 Les fichiers sont au format MIME, contenant l'en-tête de courrier électronique ainsi que le contenu du message. Les pièces jointes sont stockées indépendamment dans un ou plusieurs fichiers dans leur format natif.
  16. 16. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 12 France COMMENT EST DETECTE LA NON SUBSTITUTION DES DONNEES ? Dès son enregistrement la donnée ne peut être modifiée et ne peut être substituée, même par le propriétaire. Toute opération d'ouverture du fichier en mode écriture est strictement interdite, même si le fichier est au-delà de sa période de rétention. Le système de fichiers POSIX de stockage des fichiers est contrôlé directement par HCP. Aucun mécanisme ne permet d'interférer dans la modification ou le remplacement d'un fichier pendant la période de rétention. Après la période de rétention et en fonction des autorisations d'accès, la seule opération autorisée est la suppression définitive du fichier. En cas de suppression après la rétention, puis copie d'un nouveau fichier dans un objectif de substitution, il sera possible de détecter l'opération, car HCP enregistre la date de dépôt, donc la date du fichier de substitution éventuelle. Cette date de dépôt est enregistrée dans un premier fichier nommé core- metadata.xml et dans un second fichier nommé created.txt. Les deux fichiers sont non modifiables, présents dans l'arborescence Metadata et accessibles, depuis le réseau IP, via l’un des protocoles activés (CIFS, NFS, HTTPs, …). En cas de fichier dit non réparable, c'est-à-dire que le fichier source est détecté comme altéré et que sa restauration par sa copie (DPL) interne échoue, une notification d'alerte est enregistrée (SNMP et Syslog). L'interface graphique d'administration propose aussi une vue spécifique sur ces fichiers corrompus. COMMENT CONSERVER UN HORODATAGE ISSU D’UN TIERS DE CONFIANCE ? Hitachi Content Platform propose une capacité d’enregistrement et de sécurisation, dans un format XML, des métadonnées dite Métier. Cela signifie que l’entreprise à la possibilité de stocker des données dans un fichier avec un balisage (DTD) propre à l’entreprise. Ce fichier XML peut être un moyen d’accueillir des informations d’horodatage 12 issus d’une solution tierce accréditée à cette fonction. HCP ne propose pas de soumission directe à un service d’horodatage des données mises en dépôt. Cette opération doit être réalisée avant l’archivage physique dans HCP. Description du fichier contenant la métadonnée désignant la date et l’heure de dépôt. Par contre, HCP enregistre une date et une heure de dépôt de la donnée dans les métadonnées (fichier created.txt et core-meatadata.xml) et s’en sert comme base pour la rétention. Il convient donc que la solution Hitachi Content Platform soit correctement configurée pour lui permettre d’adresser au moins deux serveurs de temps (NTP et tiers horodateur de confiance) synchrone avec l’entreprise, les applications métier et les applications tierces, tel qu’un service 12 Timestamping.
  17. 17. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 13 France officiel d’horodatage permettant d’associer une date et une heure avec un moyen cryptographique, c’est-à-dire basée sur une signature électronique pour réaliser une contremarque de temps. À titre d’exemple, HCP est validé officiellement avec la solution logicielle Surety13 depuis 2007. Il est donc question d’un processus réalisé avant le dépôt et non réalisé au sein du HCP (après le dépôt). SHREDDING – DESTRUCTION EFFECTIVE DES DONNEES ? La destruction d'un fichier ne peut être réalisée qu'au terme de la rétention. L'ordre de suppression n'est pas réalisé par HCP, mais doit être donné par l'application Métier (ou Collecteur). Elle se réalise via l’un des protocoles activés (CIFS, NFS, HTTPs, …), comme pour un fichier standard. L'ordre de suppression provoque dans HCP la suppression du fichier cible, de sa copie interne (Réplica : DPL) et des métadonnées associées. Cette suppression est accompagnée d'une opération dite de Shredding (suppression sécurisée). C'est- à-dire la mise en œuvre d'une opération d’effacement effective des données sur le disque et non uniquement d'une suppression des descripteurs (inodes). Ce mécanisme normé assure que le contenu du fichier ne pourra être lu, par une lecture, même physique, du disque dur. Il y a trois méthodes d’algorithmes :  La principale conforme DoD 5220.22-M en trois passages.  L’écriture aléatoire en trois passages.  L’effacement par réécriture d’une valeur constante avec un passage. Le traitement d'une opération de Shredding fait l'objet d'un enregistrement d'évènement pour être collecté via le protocole Syslog. IDENTIFICATION DE LA SOURCE DE DEPOT ET EMPREINTE ASYMETRIQUE Les règles de dépôt et de consultation impliquent, parfois, la nécessité d’intégrer des méthodes d’identification des sources de dépôt et de consultation. La principale réponse à une telle méthode est la mise en place d’un encodage dit asymétrique avec des capacités de clefs publiques/privés. Le calcul d’empreinte au sein du HCP est symétrique, il s’agit principalement d’une méthode de contrôle interne au sein du HCP et non d’échange. Un contrôle de transfert est possible au travers du choix, par l’entreprise, de l’algorithme utilisé dans HCP. Pour chaque fichier mis en archive, l’application métier à la possibilité d’obtenir cette empreinte et de la confronter avec celle attendue, afin, dans un second temps, de définir de la politique de conservation et de protection. Il y a aussi la possibilité de mettre en place des méthodes informatiques de la gestion de droits utilisateurs (annuaire) et contrôler ainsi les dépositaires. Cette méthode reste à considérer dans le cadre d’un archivage long terme et de la conservation de droit trop fortement liée à une production informatique. L’utilisation directe de l’empreinte asymétrique pour la gestion d’intégrité et d’échange, c’est-à-dire l’identification de la source de dépôt et de consultation, doit être réalisée via des certificats SSL (TLS14 ). L’emploi de certificats est le moyen à privilégier, car il permet de sécuriser le flux, d’identifier un lieu, un équipement de ce lieu et un utilisateur informatique au sein de cet équipement. Ce moyen offre, aussi, la possibilité de définition temporaire d’échange et d’être totalement adapté aux échanges Internet. Au travers des protocoles HTTPs et WebDAV, HCP utilise cette capacité pour les échanges via les services de dépôt/consultation, de recherche, de réplication et d’administration. 13 www.surety.com/news/press-releases/surety-joins-the-hitachi-data-systems-isv-partner.aspx 14 Le nouveau nommage est Transfert Layer Security depuis 2001.
  18. 18. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 14 France HCP intègre son propre CA15 qui génère les demandes de CSR16 . Pour créer un CSR, Il est aussi possible d’utiliser un logiciel tiers comme OpenSSL. Les informations détenues par ce certificat sont : Common Name (CN), Organizational Unit (OU), Organization (O), Location (L), State/Province (ST) et Country (C, désigné par deux lettres normées ISO 3166-1). En résumé, le chiffrement asymétrique est utilisé par HCP, afin d’authentifier et sécuriser les échanges avec les applications et équipements externes. Le chiffrement symétrique est utilisé par HCP pour créer les empreintes et gérer l’intégrité des données au sein du stockage HCP. EST-CE QUE HITACHI PROPOSE UN OUTIL POUR LA COLLECTE DE LOGS ? La collecte de Logs, afin de construire un journal d’évènements du système HCP, doit nécessairement être initiée en externe du HCP, par exemple, via un outil d’écoute sur le protocole Syslog (Syslog Listener). Hitachi ne propose aucun produit spécifique. Le choix est donc laissé à l’intégration applicative. Il existe différents produits pouvant s’acquitter de cette tâche, tels que Splunk (www.splunk.com) et Syslog-ng (www.balabit.com/network-security/syslog- ng/). Ces produits s’accompagnent ou peuvent être complétés par des interfaces Web (par exemple php-syslog) de gestion. Associé à la capacité du protocole Syslog, HCP enregistre par lui-même des logs qui peuvent être automatiquement stockés au sein d’un Tenant de la plate- forme HCP et ainsi assurer une conservation et un contrôle spécifique. Il convient, lors de la phase d’intégration, de mettre en place l’outil adapté pour réaliser les corrélations et réinjecter les journaux dans un espace WORM du HCP, pour conserver, dans un formaliste propre au projet de l’entreprise, les historiques (dépôts, suppressions, réplications, etc.) issus du HCP. En mode CLI, une autre solution est d’utiliser l’outil HCP Log Collector créé sur l’utilisation de l’API HCP de Management (MAPI) :  http://hcplogs.readthedocs.io/en/latest/index.html REVERSIBILITE ET RECUPERATION DES DONNEES SANS SURCOUT ? La conservation de données implique de prendre en compte les moyens et les coûts de changement de la solution d’infrastructure. Avec des échéances de plusieurs années ou dizaines d’années, il apparait avec certitude qu’une infrastructure utilisée pour l’archivage sera amenée à évoluer, mais aussi qu’une entreprise puisse aspirer à changer, pour des raisons de coûts, d’évolutivité ou de pérennité du fournisseur. Le design matériel et logiciel de la solution HCP et les choix d’origine sur l’utilisation de standards sont les éléments de réponse qui permettront à l’entreprise de récupérer les données et les métadonnées sans dépendance financière et technique vis-à-vis d’Hitachi. Concrètement, cette indépendance et cette capacité de réversibilité partielle ou totale se traduisent par :  Aucune transformation en nommage et en contenu des fichiers transmis à la solution HCP.  Une maitrise et une création, par l’entreprise, des chemins et du nommage d’accès à chaque fichier et ses métadonnées.  Une mise à disposition des métadonnées au travers de fichiers ASCII aux formats TEXT et XML.  Une accessibilité complète au travers de standards réseau, tel que CIFS, NFS et HTTPs.  L’utilisation, au sein de HCP, d’une arborescence fichiers normée POSIX. 15 Certificate Authority. 16 Certificate Signing Request.
  19. 19. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 15 France HCP ne propose aucune API propriétaire pour accéder et consulter les données et les métadonnées systèmes et personnalisées (métier). Ainsi, un simple copier/coller via un explorateur réseau suffit à récupérer entièrement les informations. Il conviendra à l’entreprise de mettre en œuvre les opérations de déplacement vers une autre infrastructure en fonction de ses objectifs, avec les contrôles d’intégrité appropriés. La solution HCP propose de base ce contrôle d’intégrité (données et métadonnées) à chaque accès de contenu. HCP Data Migrator est livré avec chaque solution HCP. C’est un outil graphique, disponible aussi en mode CLI, de transfert automatique ou à la demande de données vers et depuis un HCP. Son utilisation peut aussi contribuer à la restitution simple d’information. Extrait du fichier contenant les métadonnées créées par le HCP. SNMP et Syslog contribuent aussi à une intégration avancée et au développement d’application au-dessus de la solution HCP. Le premier au niveau administration de la plate-forme. Le second à la collecte des journaux d’activité et la traçabilité. COMMENT TENIR UN JOURNAL D'EVENEMENTS ? Le journal des évènements du système HCP (System Log Events) comprend des informations liées à l'activité de la plate-forme : arrêt, démarrage, suppression de compte, sauvegarde, mot de passe invalide, service spécifique stoppé, lien réseau, serveur de temps inaccessible, etc. L'accès à ces Logs s'effectue principalement via trois modes : l'interface d'administration avec les droits Monitor; le protocole SNMP et le protocole Syslog. Syslog est le protocole le plus couramment utilisé. Il s'agit d'un service de journaux d'événements d'un système informatique, mais donne aussi son nom au format d'échange. Ce protocole se compose d'une partie Client et d'une partie Serveur. HCP se comporte comme un client en émettant les informations sur le réseau via le port UDP 514. La partie serveur doit collecter les informations, pour centraliser les journaux d'événements. Un événement HCP est composé d'un identifiant unique, le numéro de segment du message (un événement Syslog ne peut excéder 1024 caractères, celui-ci peut donc être découpé en plusieurs segments), l'identifiant de l'événement, la date, la sévérité, l'identification du serveur HCP, le volume (stockage) concerné,
  20. 20. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 16 France le nom de l'utilisateur éventuel lié à l'événement, une courte description de l'événement (uniquement pour SNMP17 ) et le message complet. En plus des événements systèmes envoyés par les protocoles SNMP et Syslog, HCP consigne des Logs internes. Il s'agit d'enregistrements sur l'activité des composants HCP. Ces traces d’activités internes sont uniquement utiles à diagnostiquer un problème interne par le support Hitachi. Elles sont conservées sur une période de 35 jours et sont récupérables pour la réalisation d’un Journal. Via l’outil intégré Metadata Query Engine, il est possible de réaliser des requêtes sur la solution HCP et ainsi compléter le journal par des informations sur la donnée. Les résultats fournis par une requête respectent un format JSON. CONFORMITE A LA NORME PCI-DSS Les exigences à la conformité Payment Card Industry Data Security Standard concernent les offres destinées aux environnements de traitement de l’information liée aux cartes bancaires. Le Security Standards Council 18 regroupe les conseils, les auditeurs certifiés et les membres participants à l’élaboration et la mise en œuvre des recommandations. Le groupe Hitachi est un membre officiel actif de ce comité. Au niveau IT, les équipements réseaux sont les principaux concernés au regard d’une gestion sécurisée des transferts d’informations. Dans son rôle de représentation des industriels du stockage, la SNIA 19 intègre le groupe de travail Storage Security Industry Forum qui aborde ces points de sécurités. Ainsi de nombreux équipements liés aux réseaux de données (SAN FC) et de stockage embarquent du fonctionnel, afin de sécuriser les données et leurs accès. Extrait de la liste des rôles dans la solution HCP. 17 Simple Network Management Protocol. 18 www.pcisecuritystandards.org et fr.pcisecuritystandards.org 19 Storage Networking Industry Association
  21. 21. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 17 France Concernant l’archivage, les obligations d’immuabilité, d’intégrité et de conservation sont très proches des besoins exprimés, dans le cadre d’un SAE nécessitant la valeur probante. La première obligation concerne l’encodage. La fonction d’encodage du HCP est donc appropriée pour ce premier élément de sécurité. La solution HCP propose plusieurs fonctionnels en accord avec PCI-DSS, comme le Shredding (effacement des données), la traçabilité (Syslog et SNMP Secure), la synchronisation avec des serveurs de temps (NTP), la supervision distante des équipements (Secure Remote Support), la gestion des profils d’administration (RBAC), leur mode d’accès et leur déport, éventuel, vers un serveur central RADIUS. COMMENT RESPECTER DES RECOMMANDATIONS DE LA CNIL ? La Cnil20 autorise l’archivage de données à caractère personnel dans le cadre d’un archivage lié à une réglementation à valeur probante et sans dépassement de la durée de conservation. Dans une des recommandations (Délibération n°2005-213 du 11 octobre 2005), les limites de conservation sont clairement énoncées ainsi que les niveaux d’archivage. Il doit être possible de réaliser une purge ou destruction sélective des données. Le niveau granulaire fichier proposé par la solution HCP permet une suppression sélective, si un fichier correspond à une identification à caractère personnel, ce qui permet, aussi, d’assurer une suppression effective (Shredding) applicable au fichier (donnée et métadonnée) et, ainsi, empêcher une utilisation illégale de données à caractère personnel conforme à la Cnil. L’encodage bas niveau des données est aussi un élément fonctionnel offrant, au responsable de la donnée, une garantie de mise en œuvre technique et organisationnelle contre l’utilisation détournée de la donnée. QUELLE METHODE POUR ARCHIVER DES MESSAGES ELECTRONIQUES ? L’archivage des emails peut être réalisé à travers des outils de délestage de messagerie, tel que Hitachi Data Protection Suite et Symantec Enterprise Vault, qui collectent les emails et les pièces jointes et effectuent un enregistrement sur le stockage HCP. Exemple d’une fenêtre de configuration SMTP, vers un Namespace HCP, depuis un serveur Microsoft Exchange. 20 Commission nationale de l'informatique et des libertés
  22. 22. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 18 France Dans le cadre d’un archivage avec une orientation dite de valeur probatoire (Compliant), c’est-à-dire de conservation probante sur un support adapté (WORM logique), il est permis d’envoyer directement les emails via le protocole SMTP 21 qui est nativement supporté par HCP. Ainsi, un administrateur de messagerie peut définir des règles de transfert vers HCP directement à partir de son application de messagerie. Par exemple, Microsoft Exchange 2010 propose tout un service applicatif, au travers de la journalisation des emails et leurs pièces jointes sont envoyés sur HCP, pour y être stockés dans une arborescence fichiers et être classifiés automatiquement par date. COMMENT DEFINIR UNE RETENTION ET UNE DUREE DE VIE SUR UNE DONNEE ? La « durée de vie » d’une donnée est principalement dictée par la politique d’archivage du métier et du cadre réglementaire associé. Cette durée se traduit par une date de rétention connue ou inconnue. C’est-à-dire la conservation sécurisée et la gestion de l’intégrité de la donnée sur toute la période correspondant à la « durée de vie ». A l’issue de cette durée de vie la solution HCP accepte la réalisation d’un traitement informatique sur la donnée, telle que la suppression définitive. La date est dite connue quand elle correspond à une date (normée ISO) de fin de rétention précise calculée en amont du dépôt dans la solution HCP. L’application ou l’utilisateur dépose une donnée et lui associe une date de fin de conservation. La date est dite inconnue quand elle correspond à une période de conservation précise (75 jours, 52 mois, 23 ans, etc.) sans définir explicitement la date de fin de rétention. La donnée est mise en dépôt dans un Namespace HCP, auquel est associé une classe d’archivage qui prend en charge la transformation de la période définie en une date explicite pour chaque donnée archivée (granularité fichier). Cette date est calculée à partir de la date effective de dépôt. Par exemple, pour un espace de dépôt avec une conservation de 3 mois, un fichier archivé aujourd’hui à 21:45:00 sera conservé en mode WORM sur 3 mois jusqu’à 21:45:01. Un second fichier déposé le lendemain à 21:45:00 sera conservé 1 jour de plus que le premier. La date inconnue peut aussi correspondre à une période inconnue. Il s’agit alors de conserver l’information sans limite de temps en attente d’une date précise. Cette date correspond généralement à un évènement externe à la solution HCP, construite au sein du Système d’Archivage Électronique, comme par exemple la conservation des fiches payes d’un employé, un certain nombre d’années après son départ de l’entreprise. L’évènement est le départ de l’entreprise et celui-ci peut intervenir pour différentes raisons : une démission, un licenciement, un départ en retraite, etc. En résumé, la définition d’une durée de vie ou d’une rétention sur une donnée est régie par une date précisée avec le dépôt de la donnée, ou une période exprimée en jours, mois ou années, dans une Classe d’Archivage, en précisant au HCP d’appliquer automatiquement une date de conservation sur la durée de la Classe. A l’issue de la rétention sur la donnée, il est possible de demander la réalisation par HCP d’une suppression définitive (politique nommée Disposition). QUELLE GARANTIE D’ETANCHEITE DES DONNEES EN CAS DE MUTUALISATION ? La mutualisation des données, issues de sources différentes et indépendantes, et leur sécurisation d’accès sont possibles dans une solution HCP. En effet, entre l’administrateur de la plate-forme, le gestionnaire du Tenant et l’utilisateur d’un Namespace, il existe un cloisonnement fort interdisant :  A l’administrateur de la solution d’accéder aux données ;  Au gestionnaire de Tenant d’accéder aux autres Tenants ; 21 Simple Mail Transfer Protocol.
  23. 23. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 19 France  Et à l’utilisateur d’un Namespace d’accéder à d’autres informations que celles autorisées par les droits de son compte. Déclinaisons des cloisonnements au niveau du HCP. Ce cloisonnement favorise la consolidation et évite de dupliquer les zones de stockage par des équipements physiques différents :  Au niveau administrateur, il existe un mécanisme de Rôle, dit Role Base Access, permettant de définir différents niveaux d’administration avec des droits spécifiques à chaque Rôle. Les comptes administrateurs peuvent être issus d’un annuaire externe, tel que RADIUS.  Au niveau gestionnaire d’un Tenant, seul son compte d’accès (Login + mot de passe) est autorisé à définir les droits et les modalités d’accès aux Namespace donc aux données.  Au niveau des utilisateurs, ceux-ci sont déclarés depuis un Tenant et leur droits d’accès déterminent les capacités de lecture, écriture, suppression et recherche sur les données d’un ou plusieurs Namespaces d’un seul Tenant. Un compte utilisateur peut être issu d’un annuaire externe, tel que l’Active Directory.  Le dernier niveau de sécurisation et de paramétrage des accès aux données est lié aux fichiers à travers une notion d’Object ACL. La gestion du cloisonnement au sein du HCP contribue au respect de la norme internationale ISO 27001. Cette norme impose un niveau fort de confidentialité de la donnée et principalement la gestion de l’accès à l’information par les utilisateurs autorisés et non, par exemple, par l’administrateur de la plate- forme. En effet, un système classique gère les accès utilisateurs, mais considère l’administrateur comme un super utilisateur, avec tous les droits d’accès. Avec HCP, cette pratique est interdite. Ce point est essentiel, surtout dans le cas d’hébergement ou de gestion par un tiers sur des données sensibles. POURQUOI UTILISER HCP POUR LA VALEUR PROBATOIRE ET NON HNAS ? Les solutions NAS Hitachi intègrent un fonctionnel WORM logique. C’est-à-dire la capacité de figer un système de fichiers en y associant une rétention. Mais à l’image de ce qui existe sur le marché, ce fonctionnel WORM n’est pas accompagné des services de contrôle de l’intégrité, de traçabilité et de Shredding sur les données, pour ne citer que les principaux services.
  24. 24. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 20 France Dans un cadre d’archivage à valeur probante, il est important de proposer une garantie à tous les niveaux du processus d’archivage. La mise en œuvre d’une rétention est un élément de cette chaîne, mais la traçabilité effective au regard des changements de support physique, de la séparation des accès autorisés entre les propriétaires et les administrateurs, des capacités d’audit, de la prise en charge des métadonnées, de l’assurance de protection par réplication contrôlée et de la suppression effective des données, sont autant de valeurs et de services, embarqués dans le HCP, fortement utiles à la création de la preuve électronique et, par ce biais, fournir la capacité d’être un support candidat aux normes 22 et au respect des réglementations nationales23 ou internationales. Le manque de jurisprudence, en France, implique une pratique de l’attentiste de la part des entreprises et un peu de laxisme général de la part de certains fournisseurs. Mais au regard du temps de conservation de certaines données et des implications de coût déjà vécus dans certains pays, il apparait préférable de mettre en œuvre la meilleure solution au regard des technologies connues du moment. Le NAS est une excellente solution pour le partage de fichiers standards, mais son fonctionnel interne n’a pas été bâti dans un objectif de conservation de valeur probante. D’ailleurs, la durée de vie du matériel est bien plus courte que la durée de rétention des données. Les deux premières questions sont alors : quel sera le processus probant de migration à l’échéance du support et de la maintenance informatique ? Et quels seront les coûts associés à cette migration technique ? Ces questions ont une réponse immédiate avec la solution HCP. COMMENT EST GERE L’OBSOLESCENCE DES COMPOSANTS D’UN HCP ? La genèse du design de la solution HCP est basée sur la prise en compte de la contrainte de durée de vie du matériel informatique, au regard de la durée des données. Le changement des composants informatiques sans remise en cause de l’intégrité des données est une des principales valeurs de la solution HCP. La gestion de l’obsolescence des supports de stockage est la base même d’une gestion réfléchie, pour un archivage sur le long terme. Tout système d’archivage électronique se doit à cette indépendance vis-à-vis de l’infrastructure matérielle, afin de garantir, au mieux de l’état de l’art technologique du moment, la capacité à accéder et lire le contenu des données archivées sur une durée de rétention. Depuis son lancement en 2006, la commercialisation de la solution HCP a vue plus de 3 générations de stockage HDS. C’est-à-dire qu’il y a eu plusieurs fin de commercialisation, puis de support, des composants internes sans remettre en cause la fin de commercialisation et de support de la solution HCP elle-même. Tous les composants du HCP peuvent être changer sans impact sur la conservation des données. Le logiciel embarqué, les serveurs et les stockages évoluent indépendamment et, surtout, sans rupture de la valeur probatoire des données. Il y a 2 types de renouvellement : 1. Renouvellement dit régulier : il s’agit de changer les composants au regard des recommandations du constructeur, avant une fin de support trop définitive. Par exemple, pour le stockage, HCP supporte plusieurs 22 Dans le cadre d’un WORM logique, la révision de mars 2009 de la norme NF Z42-013 nécessite explicitement un stockage avec des capacités intégrant un journal des évènements et un moyen de cryptographique, tel que le hachage (empreinte : document Afnor, page 10, définition 3.15). 23 La Cnil précise que l’acte d’archivage de données personnelles est autorisé, mais ne doit pas excédé le temps nécessaire. La destruction de ces données est alors obligatoire sous peine de sanction pénale. Il est également nécessaire de vérifier qu’aucune copie ou sauvegarde n’est conservée.
  25. 25. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 21 France générations au sein de la plate-forme et prend en charge la migration des données avec garantie de l’intégrité et création des logs. Il convient d’anticiper et de contractualiser les renouvellements tous les 3 à 5 ans. 2. Renouvellement dit non régulier : pour des raisons souvent d’investissement en fond propre ou d’appel d’offre public, il s’agit de reporter au maximum le renouvellement matériel jusqu’à la fin du contrat. S’il s’agit d’un renouvellement de fournisseur, la migration peut se faire via les capacités de réversibilité du HCP. S’il s’agit de continuer avec la solution HCP, la différence de génération peut engager une autre forme de migration, par la réplication. En effet, tous les modèles HCP sont compatibles entre eux avec le même niveau fonctionnel. La réplication est une excellente forme de transfert, car elle permet aussi l’intégrité des données et la mise en œuvre de création de logs, dans le respect d’un cadre réglementaire fort, comme la norme ISO 14721. Le choix du mode de renouvellement est lié aussi au nombre de données (volume et objet). Un renouvellement régulier implique parfois un investissement tout aussi régulier, mais avec un minimum d’impact sur la production informatique, surtout si les volumes de données sont importants. Dans le cas contraire, l’impact financier et IP d’un renouvellement non régulier peut-être envisagé sans contrainte particulière. COMMENT S’ASSURER QU’UN FICHIER EST ENREGISTRE ET REPLIQUE ? Dans le cadre de la création d’un Journal d’Archive, certaines informations sont nécessaires, dont la validation de la protection de la donnée sur un autre support. La réplication est le principal outil de protection vers un site distant. Comme la rétention et l’empreinte, l’indication de réplication réussie est présente dans les propriétés (métadonnées) de l’objet. Un fichier correctement enregistré et protégé dans un HCP est désigné par la réalisation de l’empreinte. En effet, un logiciel déposant un fichier dans HCP reçoit en retour l’empreinte du fichier calculé sur l’algorithme configuré sur le Tenant cible. Ce retour prend en compte la protection locale de la donnée (DPL) et la métadonnée (MDL ou M-DPL). Si ce même logiciel veut s’assurer que la donnée et ses métadonnées sont bien répliquées sur au moins un autre HCP, il suffit de consulter depuis les métadonnées la valeur nommée replicated. L’outil intégré Metadata Query Engine (MQE) est un excellent moyen simple et efficace d’interrogation du HCP. EST-IL POSSIBLE DE MIGRER DES DONNEES DEPUIS EMC CENTERA VERS HCP ? Historiquement, la solution EMC Centera est plus ancienne (sortie en 2003) que la solution HCP (sortie début 2007). Son avènement était une réponse séduisante aux problématiques du stockage WORM physique (DON, UDO, DVD, etc.). Le déploiement du Centera dans des architectures d’archivage électronique correspondait donc à des considérations du moment plus évolutives (capacité du disque dur, déduplication), plus souples (réplication, PRA, gel et dégel) et plus sécurisées de type CAS (Content Addressed Storage), c’est-à-dire que l’accès à une donnée nécessite une clef (CClip) unique et générée par le Centera. Le droit d’accès et la restitution d’une donnée sont donc intimement liés. La perte de ce « droit » provoque l’impossibilité de
  26. 26. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 22 France restituer la donnée. Malgré des évolutions (XAM24 , passerelle CIFS/NFS25 , …), le Centera est principalement utilisé via son API propriétaire (CentraStar/SDK26 ). Cette API reste le principal moyen de lecture et d’écriture. La technologie Centera est toujours utilisée, mais au regard des nouveaux besoins (forte volumétrie, mobilité, performance) et des nouvelles expressions archivistiques (indépendance du support et du logiciel, multi-protocoles non propriétaire de dépôt et de consultation, réversibilité, coût/maintenance, intégration avancée des métadonnées, etc.), le modèle CAS n’est plus adapté. Il convient donc de procéder à une migration. C’est d’ailleurs bien dans ce cas de figure que la technologie EMC Centera montre ses limites. Contrairement à la solution HCP, ce type de technologie n’a pas été pensée comme un support transitoire, mais bien comme une destination finale. Hors, sur plusieurs décennies d’archives et plusieurs centaines de To de données, il apparait que la réalisation effective d’une migration simple et indépendante (de tout fournisseur) est bien éloignée du besoin originel d’une archive sur le long terme. Cela ne signifie pas que la migration est impossible, mais qu’elle est difficile et fortement dépendante de l’architecture logiciel et matérielle mise en place. Il y a donc une dimension financière à prendre en compte et pas nécessairement anticipée. La principale méthode de migration consiste à utiliser l’application logicielle qui a servi au dépôts des archives. Cette application doit alors lire en partie ou l’ensemble des données et les réécrire sur le nouveau support. Cette application doit assurer le contrôle et la journalisation du transfert. En fonction de la volumétrie et surtout du nombre de données, ce transfert est souvent très long. Il est fortement conseillé de migrer avant que la volumétrie devienne un frein au changement de fournisseur et, par ce biais, un surcoût financier. Si l’application est compatible avec l’utilisation du HCP, la migration est alors entièrement assurée par le processus interne du logiciel Métier. La continuité de l’exploitation de la donnée est conservée. Principe d’intégration du connecteur Star Storage pour Documentum ou une autre solution applicative certifiée, qui intègre une capacité de migration depuis un Centera. Il y a, malheureusement, de nombreux cas d’usage ou le temps de migration est trop long (lecture/écriture), pas suffisamment anticipé (maintenance, obsolescence), complexe (applications multiples) ou impossible (obsolescence et performance applicative, incompatibilité). Le besoin Client est alors uniquement exprimé par une demande de migration directe entre support, c’est-à-dire depuis le Centera vers un nouveau support (nouvelle infrastructure) 24 eXtensible Access Method – protocole promu par la SNIA, mais qui n’a pas connu de réel engouement de la part des éditeurs et des constructeurs. Le XAM Developers Group n’a plus aucune activité et depuis Juin 2009, les spécifications sont figées à la v1.0.1 : www.snia.org/forums/xam/technology/specs 25 CUA : Centera Universal Access – c’est le cas le plus favorable de migration vers HCP. 26 Il y a plusieurs versions du CentraStar/SDK. L’étude de faisabilité doit la prendre en compte pour la migration.
  27. 27. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 23 France en espérant une meilleure transparence, une utilisation des protocoles/API de transfert et une répercussion minimale, au profit des applications et surtout des utilisateurs. Dans ce cas, il existe des outils, généralement associés à une prestation de service, pour interfacer à la fois les accès au Centera et au HCP et garantir la pérennité d’exploitation de la donnée. La prestation de service adaptée est nécessaire, car une migration depuis un Centera doit être traitée comme un projet et non comme une procédure simplifiée et automatique. L’expertise et la méthodologie complètent alors la prestation. Ces outils servent les applications au travers d’une interface au CAS, assurant la continuité d’accès à l’ancien support, tout en réalisant le transfert des données vers le stockage objet du HCP. Cette méthode à l’avantage de masquer les contraintes de migration aux applications, mais elles ne réduisent pas les temps de migration. La solution HCP étant plus performante, elle ne sera pas la source de la consommation de ce temps de migration. Il convient aussi de s’assurer que l’outil de migration soit capable d’assurer, à minima, la traçabilité et l’intégrité des données. Dans le cas d’un archivage à valeur probante, la migration masquée aux applications ne supprime pas de bien considérer la continuité de la chaine de conservation réglementaire (confidentialité, politique de rétention, conformité, complétude, etc.). Principe de migration du Centera vers HCP proposée par Interlock à partir d’une Appliance logicielle capable aussi de migrer les données vers HNAS. Il n’y a pas de réponse unique. La solution préconisée correspond nécessairement à un environnement et à son audit préalable. Si pour la solution EMC Documentum, il existe un connecteur certifié (EMC et HDS), tel que celui de Star Storage 27 , pour assurer une migration automatisée et contrôlée du contenu du Centera vers le HCP, le connecteur n’existe pas nécessairement pour tous les environnements logiciels. La société Américaine Interlock 28 propose, en association à du service, un connecteur générique de migration. L’éditeur logiciel Français Cecurity29 , via un développement logiciel spécifique, propose aussi un service similaire basé sur leur solution logicielle de coffre communiquant. La connaissance et l’expérience des deux environnements Centera et HCP permet, aux sociétés, proposées en exemple, de mettre en œuvre des méthodes et des procédures adaptées à chaque besoin, en utilisant les protocoles et API 27 www.star-storage.ro 28 www.interlock-tech.com/services/centera-migration 29 www.cecurity.com
  28. 28. F A Q H i t a c h i C o n t e n t P l a t f o r m : a r c h i v a g e e t v a l e u r p r o b a t o i r e Cloud, Archive & Partage © Hitachi Data Systems Page n° 24 France disponibles, les plus pertinentes à chaque environnement. Quel que soit la société, l’inventaire précis du Centera est une étape obligatoire avant toute migration vers HCP. En résumé, pour la migration du contenu d’un Centera vers HCP, il convient d’anticiper, de réaliser un inventaire exhaustif de l’existant (version produit, typologie, nombre de documents, taille des containers, mode d’adressage, etc.) et d’envisager les points suivants :  Évaluer la capacité de l’application Métier à adresser par des connecteurs certifiés, la source Centera et la nouvelle destination HCP ;  Si le l’application ne peut assurer la migration, vérifier l’existence d’un connecteur pouvant servir cette migration à travers les protocoles disponibles en lecture et écriture ;  Si aucun connecteur n’existe, il faut sans remettre à une société spécialisée qui développera une passerelle via une intégration spécifique à ce transfert, afin de mettre en place un référentiel entre les CClip du Centera et leur représentation dans le système de fichiers du HCP. EST-IL POSSIBLE DE RECUPERER DES DONNEES DE MANIERE ALEATOIRE ? Dans le cadre d’une vérification externe et automatique des contenus du HCP, il est utile de réaliser la vérification par échantillonnage, c’est-à-dire de vérifier qu’entre le logiciel de dépôt et le stockage HCP, il n’existe pas de défaut d’intégrité (perte et corruption). Pour réaliser une telle opération, une méthode consiste à utiliser l’outil intégré au HCP, nommé Metadata Query Engine (MQE), pour lancer une requête sur l’empreinte. Ce type de requête peut être complété par des variables sur des dates. Il est à souligner que la solution HCP propose de base un outil de vérification d’intégrité sur toute la durée de vie des données.
  29. 29. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r o t e c t i o n e t d i s p o n i b i l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 25 France PROTECTION ET DISPONIBILITE QUELLE PROTECTION SYNCHRONE ET ASYNCHRONE ? La protection synchrone, au sein d’un Data Center, est assurée par le service dit Réplica et la protection asynchrone, pour les longues distances, est assurée par le service dit Réplication. Le service de Réplication permet des transferts IP au- delà du réseau LAN. Des clients HDS en production utilisent ce service, pour un transfert entre deux pays ou entre deux Data Center très éloignés. Les services de Réplica et de Réplications peuvent être combinés entre eux et associés à un autre service nommé Global Access Technology (GAT) permettant de bâtir un espace unique au-dessus de plusieurs HCP actifs. Ce regroupement gère automatiquement une distribution, une cohérence et une protection des données, afin de proposer un seul espace de fichiers aux applications et aux utilisateurs, sans recourir à une gestion IT complexe. REPLICA – COMMENT DUPLIQUER EN INTERNE DES DONNEES ? Avec l’utilisation des Réplicas, chaque fichier enregistré est systématiquement dupliqué en interne vers une zone de stockage différente et gérée par un autre serveur. Ainsi le dépôt source et ses copies sont situés sur des groupes RAID physiques différents, dont l'accès est géré par des serveurs (contrôleurs) différents. En cas d'altération du fichier, HCP reconstruit automatiquement le fichier, et les métadonnées, à partir de sa copie et ajoute une information dans les Logs (début, arrêt avant la fin, violation, fin et succès du traitement). La création d’un Réplica est définie par une échelle sur trois niveaux, nommé Data Protection Level (DPL). Un niveau détermine le nombre de copies automatiquement créé par HCP. La copie sert donc à la sécurisation des données, mais aussi à multiplier les points de lectures. En effet, tous les serveurs d’une configuration HCP sont disponibles en lecture et en écriture. La disponibilité d’une information sur différentes zones joue un rôle dans la performance de mise à disposition. REPLICATION – COMMENT DUPLIQUER EN EXTERNE DES DONNEES ? La réplication des données est une fonction logicielle livrée avec chaque HCP. Elle est partielle ou totale. Son activation peut être décidée par le gestionnaire d’un Tenant en fonction de la politique de l’entreprise ou du niveau de service délégué. La réplication est compatible avec la gestion de Réplicas. Ainsi, un document peut avoir plusieurs copies locales et distantes. Le recouvrement automatique est alors géré automatiquement par HCP en cas d’altération des données. L’application ou l’utilisateur ne subit aucune interruption de service, car le recouvrement est totalement transparent tout en conservant la traçabilité de l’opération. La fonction de Réplication se réalise au niveau Fichiers et apporte une traçabilité, une intégrité (contrôle de l’empreinte) incluant les métadonnées. Un fichier répliqué est notifié dans les métadonnées dites systèmes Le second site est alors une « extension » du premier site et permet une double production active dans le cadre d’un Plan de Continuité de Service Actif/Actif. REPLICATION – TRANSFERT EN MODE BLOC ? Effectuer une opération de réplication au niveau bloc, c’est-à-dire en utilisant les fonctions de réplication du stockage HDS, ne permet pas d’utiliser les mécanismes de réplication, d’encodage et de recouvrement automatique du HCP. Cela implique la mise en œuvre du produit Hitachi TrueCopy qui prend en charge la copie de LUNs d’une baie de stockage Hitachi vers une autre.
  30. 30. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r o t e c t i o n e t d i s p o n i b i l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 26 France L’utilisation de TrueCopy peut se faire uniquement avec les modèles HCP 500 et, éventuellement, HCP-G qui peuvent s’interfacer avec un réseau SAN FC vers des baies Hitachi. Dans ce cas, il n’y a pas d’impossibilité technique à utiliser les mécanismes de réplication synchrone ou asynchrone, comme pour des serveurs classiques. La destination nécessitera une configuration équivalente. Ce mode d’installation est à privilégier dans un cadre PRA Actif/Passif, c’est-à- dire sans production effective sur le second HCP. Depuis la version 7 du logiciel HCP et des modèle HCP-G, la réplication de niveau bloc via le SAN est déconseillée. La raison est liée à la minimisation du stockage SAN FC dans les architectes, et surtout, le stockage disque mis en œuvre est désormais interne aux Nœuds HCP-G, virtualisés (VMware) et aux Nœuds capacitifs HCP-S (Erasure Coding). Une réplication au niveau baie n’a plus de sens, car elle ne couvrirait que partiellement la volumétrie. REPLICATION – LES TOPOLOGIES SUPPORTEES ? La réplication HCP n’est plus une option logicielle (licence) de la version 7. Elle est asynchrone et supporte une topologie classique bidirectionnelle, en cascade et en étoile. Mais la réplication HCP se pense d’abord en Tenants et Namespaces qui sont les granularités désignant une source et une destination. Le service de réplication est proposé par l’administration de la plate-forme au Tenant et la réplication est effective sur des Namespaces sélectionnés. C’est donc au niveau du Tenant que la décision est prise d’utiliser ou non la réplication, pour tout ou partie des Namespaces du Tenant. Une réplication consiste à copier des Objets, c’est-à-dire les données et les métadonnées. La source d’une réplication est nommé Primary System et la destination est nommée Replica (différent du réplica associé au service de Data protection Level – DPL). Même pendant la réplication, le Replica est accessible et peut servir des besoins d’accès aux informations. Chaque configuration d’une réplication débute par la création d’un lien sécurisé et authentifié (SSL) entre la source et la destination. Un exemple d’une réplication n-vers-1-vers-1, seul les contenus des Namespace de Tenants désignés sont répliqués entre les HCP : [ABC]-vers-D-vers-E (Tenants 1, 2, 3, 4 et 6) et D-vers-E (Tenant 8). Le Replica sert aussi automatiquement les demandes à partir du Primary System en cas de non disponibilité (perte de la volumétrie), d’altération (empreinte non correspondante) ou de vérification des métadonnées de l’information source. Cette mise à disposition est valable à partir d’un second HCP (destination de la
  31. 31. F A Q H i t a c h i C o n t e n t P l a t f o r m : p r o t e c t i o n e t d i s p o n i b i l i t é Cloud, Archive & Partage © Hitachi Data Systems Page n° 27 France première réplication), mais aussi d’un troisième HCP (destination de la seconde réplication, en cascade ou chaine par exemple). La réplication supporte le service de Versioning. Il est possible de définir une règle différente, de conservation des versions sur des données, entre la source et la destination, par exemple : conserver toutes les versions sur 10 jours dans le Primary System et 30 jours sur le Replica. SYNCHRONISATION MULTI-SITES – GLOBAL ACCESS TOPOLOGY ? La protection HCP se réalise aussi avec un nouveau mode de réplication basée sur une synchronisation multi-sites. Introduite en 2014 ; depuis HCP v7-0, cette technologie, nommée GAT, propose de créer un espace de stockage commun à partir de plusieurs HCP répartis dans un même Data Center ou géographiquement dispersés dans plusieurs Data Center. Cet espace est automatiquement synchronisé entre tous les HCP au niveau du Namespace. Il est donc permis que certains espaces de données soient inscrits dans un Global Access Topology (GAT) et d’autres ne le soient pas. Une architecture GAT contribue à améliorer les besoins de continuité de service inter sites. Un espace géré par le GAT est accessible en mode Lecture/Écriture depuis tous les HCP. Les données de cet espace sont alors accessibles depuis tous les HCP du GAT. Un espace ainsi géré peut aussi être répliqué. Ainsi un Namespace #1 au sein d’un GAT de 3 HCP, peut être répliqué vers Namespace #2 d’un quatrième HCP. La cohérence des données est gérée par la solution HCP au niveau Objet. Les métadonnées dont synchronisées en premier. Le temps de synchronisation dépend du nombre et de la taille des données, du dimensionnement du réseau et de la sécurisation mise en place (encodage). GAT est compatible avec une

×