Foire Aux Questions sur Hitachi Content Platform

© 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

© 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

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

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

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
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

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

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.

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

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.

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.

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.

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).
 …

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
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.

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.

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.

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.

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.

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.

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é,

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

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

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.

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.

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.

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

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.

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

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.

p r o t e c t i o n e t d i s p o n i b i l i t é
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.

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

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

Foire Aux Questions sur Hitachi Content Platform

Foire Aux Questions sur Hitachi Content Platform

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Foire Aux Questions sur Hitachi Content Platform

Similaire à Foire Aux Questions sur Hitachi Content Platform (20)

Plus de Bertrand LE QUELLEC

Plus de Bertrand LE QUELLEC (8)

Foire Aux Questions sur Hitachi Content Platform