Upload
hitachi-data-system
View
111
Download
7
Embed Size (px)
DESCRIPTION
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, …). 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.
Citation preview
© Hitachi Data Systems - France 16 septembre 2014. version 1.20
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 C o n t e n u s
Cloud Storage & Objet © Hitachi Data Systems
Partage & Consolidation 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 DIFFERENCE ENTRE UN OBJET ET UN FICHIER ? ............................................................................................ 3 QUELLE EST LA TAILLE LIMITE D’UN FICHIER DANS HCP ? ........................................................................................ 3 DIFFERENCES ENTRE LE STOCKAGE OBJET ET LES AUTRES FORMES DE STOCKAGE ? ................................................ 4 QUELLE DIFFERENCE ENTRE UNE SOLUTION HCP ET UNE SOLUTION HNAS ? ........................................................... 4 QUELLE S SONT LES LIMITES GENERALES ET TECHNIQUES D’UN HCP ? ..................................................................... 6
ARCHIVAGE ET VALEUR PROBATOIRE .......................................................................................................... 7
SAE – INFRASTRUCTURE MATERIELLE CONTRE ENVIRONNEMENT LOGICIEL ? ........................................................... 7 CALCUL D’EMPREINTE ET D’INTEGRITE SUR UN OBJET HCP ? ................................................................................... 8 GARANTIE D’INTEGRITE AU NIVEAU INFRASTRUCTURE DE STOCKAGE ....................................................................... 9 COMMENT CONSERVER UN HORODATAGE ISSU D’UN TIERS DE CONFIANCE ? ............................................................. 9 COMMENT TENIR UN JOURNAL D'EVENEMENTS ? ..................................................................................................... 10 EST-CE QUE HITACHI PROPOSE UN OUTIL DE COLLECTE DE LOGS ? .......................................................................... 10 COMMENT EST DETECTE LA NON SUBSTITUTION DES DONNEES ? ............................................................................. 11 SHREDDING – DESTRUCTION EFFECTIVE DES DONNEES ? ......................................................................................... 11 IDENTIFICATION DE LA SOURCE DE DEPOT ET EMPREINTE ASYMETRIQUE................................................................. 11 REVERSIBILITE ET RECUPERATION DES DONNEES SANS SURCOUT ? ......................................................................... 12 COMMENT RESPECTER DES RECOMMANDATIONS DE LA CNIL ? ............................................................................... 13 CONFORMITE A LA NORME PCI-DSS ....................................................................................................................... 13 COMMENT DEFINIR UNE RETENTION ET UNE DUREE DE VIE SUR UNE DONNEE ? ....................................................... 14 QUELLE METHODE POUR ARCHIVER DES MESSAGES ELECTRONIQUES ? ................................................................... 15 QUELLE GARANTIE D’ETANCHEITE DES DONNEES EN CAS DE MUTUALISATION ? ..................................................... 16 POURQUOI UTILISER HCP POUR LA VALEUR PROBATOIRE ET NON HNAS ? ............................................................. 17 COMMENT EST GERE L’OBSOLESCENCE DES COMPOSANTS D’UN HCP ? .................................................................. 17
PROTECTION ET DISPONIBILITE .................................................................................................................... 19
QUELLE PROTECTION SYNCHRONE ET ASYNCHRONE ? ............................................................................................. 19 REPLICA – COMMENT DUPLIQUER EN INTERNE DES DONNEES ?................................................................................ 19 REPLICATION – COMMENT DUPLIQUER EN EXTERNE DES DONNEES ? ....................................................................... 19 REPLICATION – PLAN DE REPRISE D’ACTIVITE EN MODE BLOC ? .............................................................................. 19 REPLICATION – LES TOPOLOGIES SUPPORTEES ? ...................................................................................................... 20 COMMENT ENCODER DES DONNEES SUR LE SUPPORT DISQUE ? ................................................................................ 21
CLOUD STORAGE ET STOCKAGE OBJETS .................................................................................................... 22
QUELLE INTERACTION AVEC D’AUTRES CLOUD ET ACCES UNIVERSEL ? .................................................................. 22 XAM ET HCP – COMPLEMENTARITE OU OPPOSITION ? ............................................................................................ 22 EST-CE QU’HCP SUPPORTE UN MODE D’ACCES DE TYPE AMAZON S3 ? ................................................................... 23 QUELLES DEFINITIONS DES DROITS D’ACCES AUX OBJETS ? .................................................................................... 23 COMMENT SE PROTEGER DE L’EFFACEMENT ACCIDENTEL DE DONNEES ? ................................................................ 24 SYNCHRONISATION ET PARTAGE DE FICHIERS EN NOMADISME ................................................................................ 24 LIMITES FONCTIONNELLE DE LA SOLUTION HCP ANYWHERE .................................................................................. 26 ACTIONS GLOBALES REALISABLES PAR L’UTILISATEUR AVEC HCP ANYWHERE ..................................................... 26 ACTIONS REALISABLES PAR CLIENT HCP ANYWHERE ............................................................................................ 27 ACTIONS REALISABLES PAR L’ADMINISTRATEUR AVEC HCP ANYWHERE ............................................................... 28
ARCHITECTURE ET DEPLOIEMENT IT .......................................................................................................... 29
QUELLE METHODE DE CHANGEMENT DE SUPPORT PHYSIQUE ? ................................................................................ 29 COMMENT EXTERNALISER DES DONNEES DU HCP VERS DES BANDES ? ................................................................... 29 EST-IL POSSIBLE D’INSTALLER HCP COMME TIERS EXTERNE DU HNAS ................................................................. 30 MAINTENANCE DES SUPPORTS DE STOCKAGE .......................................................................................................... 31 COMMENT GERER UN PARTAGE MIXTE ET DES DROITS CIFS-NFS ? ......................................................................... 31 COMMENT MIGRER DES DONNEES ET DES METADONNEES ? ..................................................................................... 32
Cloud Storage & Objet © Hitachi Data Systems
Archive & Consolidation France
QUELLE TECHNOLOGIE POUR OPTIMISER ET DE REDUIRE LA VOLUMETRIE ? ............................................................ 33 ENVIRONNEMENT DE TESTS OU PRE PRODUCTION : QUELLE SOLUTION ? ................................................................. 33
PERFORMANCES ................................................................................................................................................... 35
QUELLES SONT LES PERFORMANCES D’INGESTION ET DE CONSULTATION ? ............................................................. 35 PERFORMANCE HTTP ET LOAD BALANCING DU HCP ............................................................................................. 35
SOLUTIONS ET EXTENSIONS FONCTIONNELLES ...................................................................................... 37
HITACHI DATA INGESTOR – ACCES CIFS-NFS ET LE MODE ROBO ? ...................................................................... 37 QUELLE CONFIGURATION VMWARE MINIMALE POUR LA VM HDI ? ....................................................................... 38 LA GESTION DES DONNEES ET LES FLUX ENTRE HDI ET HCP SONT-ILS OPTIMISES ? ................................................ 38 COMMENT MESURER LA BANDE PASSANTE NECESSAIRE ENTRE HDI ET HCP ? ....................................................... 38 EXISTE-IL DES ABAQUES DE PERFORMANCES ENTRE HDI ET HCP ? ........................................................................ 39 QUELS SONT LES BENEFICES A UTILISER HDDS AVEC HCP ? .................................................................................. 40 HITACHI CLINICAL REPOSITORY – SUPPORT DICOM, HL7 ET XDS ? ..................................................................... 41
ADMINISTRATION ET SUPERVISION .............................................................................................................. 43
SUPERVISION DU STOCKAGE HCP PAR HI-TRACK ................................................................................................... 43 COMMENT METTRE A JOUR LE SYSTEME INTERNE ? ................................................................................................. 43 ADMINISTRATION DE LA PLATE-FORME ................................................................................................................... 44 LISTE DES PRINCIPAUX PORTS DE COMMUNICATION UTILISES DANS HCP ................................................................ 44 ADMINISTRATION DU STOCKAGE AU SEIN DU HCP .................................................................................................. 44
PROGRAMMATION ET INTEGRATION APPLICATIVE .............................................................................. 45
QUELLE CAPACITE DE DEVELOPPEMENT ET D’INTEGRATION LOGICIELLE ?.............................................................. 45 INTEGRATION ET DEVELOPPEMENT LOGICIEL AVEC LA SOLUTION HCP ................................................................... 45 QUELLE CAPACITE DE DEVELOPPEMENT SUR L’ADMINISTRATION DU HCP ? ........................................................... 46 COMMENT REALISER DES RECHERCHES SUR LES METADONNEES ? ........................................................................... 47 COMMENT RECUPERER DES RAPPORTS EN VUE D’UNE FACTURATION ? .................................................................... 48 QUELLES SONT LES PRINCIPALES REQUETES HTTP SUPPORTEES PAR HCP ? ........................................................... 48
FONCTIONNELS INTEGRES AU STOCKAGE OBJET-CLOUD HITACHI ................................................. 50
INTEGRITE ................................................................................................................................................................ 50 CONFIDENTIALITE .................................................................................................................................................... 50 PERENNITE ............................................................................................................................................................... 50 DISPONIBILITE ......................................................................................................................................................... 51 ACCESSIBILITE ......................................................................................................................................................... 51 REGLEMENTATION ................................................................................................................................................... 52 HISTORIQUE DES VERSIONS DE LA SOLUTION HCP .................................................................................................. 53
Cloud Storage & Objet © Hitachi Data Systems
Archive & Consolidation France
Hitachi Content Platform1 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.
Hitachi Content Platform est aussi la réponse Hitachi 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.
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é.
« 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.
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 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 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, aux
archives, aux sauvegardes et aux fichiers de toute nature et principalement au
partage de contenus multimédia, tels que les images et les vidéos. Par contre,
un Système Objet n’est pas, aujourd’hui, complétement adapté à des
applications nécessitant du stockage transactionnel de niveau bloc, telle que les
bases de données.
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 MD5, SHA, etc. L'empreinte est
enregistrée dans un premier fichier dédié nommé core-metadata.xml et dans
un second fichier nommé hash.txt. Les deux fichiers, non modifiables, sont
présents dans l'arborescence Metadata et accessibles, depuis le réseau IP, via
l’un des protocoles activés (CIFS, NFS, HTTPs, …).
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.
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
Une fois déposé le nom du fichier et son contenu ne peuvent être changés, même
si la date de rétention est nulle ou arrivée au terme de sa conservation. Tout au
long de la conservation du fichier, un processus spécifique (nommé
Scavenging) interne à la plate-forme HCP 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 trois labellisations qui
correspondent à des modèles distincts au niveau matériel. 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.
Evolutivité 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
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
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
aux estimations des Réplicas souhaités. L’interface d’administration du HCP
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 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 et WebDAV 2 To
CIFS 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
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
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
HTTP/HTTPs via REST et ses déclinaisons : WebDAV, S3, …
CIFS, NFS & FTP iSCSI, Fibre Channel, SAS & FCoE
Métadonnée Métadonnées métier et personnalisables
Attributs système de fichiers
Attributs système
Orientation idéale
Fichiers relativement statiques, partage de fichiers et Cloud Storage
Partage de fichiers Données transactionnelles et fréquemment modifiées
Force Evolutivité et accès distribués
Accès simplifié et commodité des partages
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
Réseau de production
IP sans limitation de distance : LAN et WAN, nativement.
IP avec des contraintes de distance : LAN principalement et WAN avec des équipements
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.
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
Fonctionnel HCP HNAS
Déclinaison modèle HCP VM, 300, 500 et 500 XL HNAS série 3000 et 4000
DICOM, HL7 et XDS Oui (option) Non
CIFS SMB Oui, v2 Oui, v2 et v3
NFS Oui, v3 Oui, v3 et v4
FTP Non, mais Oui via HDI Oui
iSCSI Non Oui (option)
Réception email via SMTP Oui Non
HTTP REST/WebDAV/cURL 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 42To (300) à 80Po4 (500XL) 4 (4060)s à 32 Po (4100)
Nombre de fichiers 64 milliards 6 milliards
Accès WAN Oui Non
Anti-Virus Non Oui
Cluster Name Space Oui Oui (option)
Réplication asynchrone Mode fichier/objet (option) Mode bloc et fichier (option)
Réplication synchrone Différé continu (option) Oui (option)
Métadonnées métier Oui Non
Cloisonnement logique Tenant/Namespace (x10000) EVS (x64 niveau annuaire)
Performance Lié au nombre de nœuds Haute performance IOPS
Shredding Oui Non
RADIUS Oui Oui
Journaux Oui Oui
Droits ACLs Non (CIFS/NFS) - Oui (Objet) Oui (CIFS/NFS) – Non (Objet)
Snapshot Non Oui
Réplica fichier Oui (2 à 4) niveau Namespace Non
Versioning Oui Non
Déduplication Oui (SIS) Oui (mode Bloc)
Compression Oui Non
Empreinte HASH Oui Non
Indexation HDDS Oui (contenus et métadonnées) Oui (contenus)
Metadata Query Engine Oui (indexation métadonnées) Non
Spin Down Class Oui (Avec HUS) Non
Miroir Oui via Réplica Oui (option)
File Tiering (mode HSM) Oui (Spin-Down interne et NFS) Oui (option : interne, NFS et HCP)
4 40Po en standard et 80Po après validation Hitachi.
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
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 15,999 To
Nombre de Volumes Logiques par Storage Node en architecture SAIN (HCP 500 et 500XL) 63
Nombre de Serveurs (Storage Node) par HCP 80
Nombre d’Objets (fichier) par Serveur (Storage Node) 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
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.
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° 7 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 Electronique, le positionnement de la
solution Hitachi Content Platform est résolument 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.
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° 8 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 & Audit
(Serda5), d’associations reconnues (FedISA6) 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.
En mode Default Tenant, cette empreinte est enregistrée dans deux fichiers
internes (hash.txt et custom-metadata.xml) et accessibles simultanément
depuis les protocoles CIFS, NFS et HTTPs. 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. Les deux fichiers font 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 ensemble de métadonnées est dupliqué en interne, mais aussi signé pour
assurer leur intégrité. Le troisième calcul concerne l’objet HCP (données et
métadonnées). Seule l’empreinte sur la donnée est accessible. Les autres
5 Livre blanc : Archivage Electronique 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'Economie numérique. 8 Décision-Achats.fr N°142 du premier mars 2011.
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
empreintes sont stockées en internes du HCP et servent lors des contrôles
d’intégrité.
En résumé, un objet HCP est constitué du fichier d’origine, de ses métadonnées
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) 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, alors que le niveau du
MDPL est défini en interne par le HCP.
GARANTIE D’INTEGRITE AU NIVEAU INFRASTRUCTURE DE STOCKAGE
La solution HCP assure et garantie 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) ;
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 11 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
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 Timestamping.
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
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
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.
A titre d’exemple, HCP est validé officiellement avec la solution logicielle Surety12
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).
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é,
le nom de l'utilisateur éventuel lié à l'événement, une courte description de
l'événement (uniquement pour SNMP13) 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. Lors d'une récupération par un téléchargement
depuis l'interface d'administration, le fichier récupéré est encrypté et ne peut
être lu que par le support Hitachi.
EST-CE QUE HITACHI PROPOSE UN OUTIL DE 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, 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.
Il convient donc, 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 du HCP,
pour conserver les historiques de dépôts, suppressions et réplications issus du
HCP.
12 www.surety.com/news/press-releases/surety-joins-the-hitachi-data-systems-isv-partner.aspx 13 Simple Network Management Protocol.
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
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 interne (configuration de base
avec le modèle HCP 300) é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.
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
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
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.
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.
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.
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.
A noter que le produit HCP Data Migrator livré de base avec chaque solution HCP
est un outil graphique, disponible aussi en mode CLI, de transfert automatique
14 Le nouveau nommage est Transfert Layer Security depuis 2001. 15 Certificate Authority. 16 Certificate Signing Request.
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
ou à la demande de données vers et depuis un HCP. Son utilisation peut aussi
contribuer à la restitution simple d’information.
Description du fichier contenant l’ensemble des métadonnées créées par HCP v3.
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 RESPECTER DES RECOMMANDATIONS DE LA CNIL ?
La Cnil17 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.
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é.
17 Commission nationale de l'informatique et des libertés 18 www.pcisecuritystandards.org et fr.pcisecuritystandards.org
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
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.
Quelques exemples de rôles dans la solution HCP v6.
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
(encryption). 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 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
19 Storage Networking Industry Association
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
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 Electronique, 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 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.
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 20 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. Le moteur
20 Simple Mail Transfer Protocol.
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
d’indexation Hitachi Data Discovery Suite peut être utilisé, afin de retrouver les
emails par propriétaire, destinataire ou contenu, même au sein des documents
en attachement.
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 ;
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é
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
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.
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 21 et au respect des réglementations
nationales22 ou internationales.
Le manque de jurisprudence, en France, implique une habitude attentive 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.
21 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). 22 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.
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
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
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.
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° 19 France
PROTECTION ET DISPONIBILITE
QUELLE PROTECTION SYNCHRONE ET ASYNCHRONE ?
L’architecture GRID du HCP est déjà prête pour la future évolution qui consiste à
répartir physiquement les serveurs et les îlots de stockage associé. En effet,
seule une relation IP privé existe entre les serveurs pour l’échange. Leur
répartition au travers d’un réseau LAN en sera donc facilitée. Aujourd’hui 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. Ce service permet des transferts 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.
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 option logicielle dans HCP. Elle peut être
partielle ou totale. Son activation peut aussi être décidée par le gestionnaire
d’un Tenant en fonction de la politique de l’entreprise ou du niveau de service
facturé. 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
d’information. 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 optionnelle de Réplication se réalise au niveau Fichiers et apporte une
traçabilité, une intégrité associée aux métadonnées, un encodage bas niveau
des disques et un recouvrement automatique au niveau fichier en cas
d’altération. 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 – PLAN DE REPRISE D’ACTIVITE 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 baie
Hitachi.
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° 20 France
L’utilisation de TrueCopy peut se faire uniquement avec le modèle HCP 500 qui
s’interface avec un réseau SAN FC vers des baies AMS, HUS et/ou USP. 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.
REPLICATION – LES TOPOLOGIES SUPPORTEES ?
La réplication HCP est une option logicielle (licence). 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. Au sein d’un Namespace, il est permis de ne répliquer
uniquement les répertoires sélectionnés à la racine de l’espace du Namespace.
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
première réplication), mais aussi d’un troisième HCP (destination de la seconde
réplication, en cascade ou chaine par exemple).
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° 21 France
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.
COMMENT ENCODER DES DONNEES SUR LE SUPPORT DISQUE ?
Afin d’augmenter le niveau de sécurité sur les informations, la solution HCP
propose nativement par configuration de mettre en œuvre un mécanisme
automatique et intégré d’encodage (encryption) des données et des
métadonnées mis en dépôt, ainsi que les dictionnaires de l’indexation Plein-
Texte. Les données sont donc enregistrées et encodées sur disques, afin de ne
pas permettre le « détournement de stockage ». Par exemple, un
détournement est représenté par le changement d’un disque dur pour
maintenance ; les informations sur ce disque pourraient être éventuellement
analysées. Un détournement est aussi représenté par la copie cachée (miroir ou
Snapshot) d’un volume disque sur un environnement hébergé. Dans ce cas, le
contrôle strict est même appliqué à une administration externalisée.
Au moment de la mise en œuvre de la solution HCP, il faut positionner le choix
précisant l’encodage sur la totalité de la plate-forme. La clef d’encodage est
alors calculée et affichée. Pour une raison de confidentialité de haut niveau, elle
doit être uniquement notée et conservée par le Responsable Sécurité de
l’entreprise. Aucune autre personne, même Hitachi, ne doit en prendre
connaissance. Il sera nécessaire de saisir la clef affichée pour confirmer la
demande. Il n’y a pas d’autre interaction d’administration ou d’utilisation. A
l’issue de cette opération, il n’y a plus aucun moyen de récupérer la clef.
L’encodage et le décodage sont automatiques et liés à la plate-forme. Il n’y a
pas de processus de modification ou de renouvellement de la clef, sauf à migrer
les données sur une autre plate-forme HCP.
L’algorithme AES 23 256-bits et le fonctionnement d’encodage sont totalement
conformes avec la directive SEC 17a-4. L’encodage et le décodage implique une
charge de traitement supplémentaire pour les serveurs HCP, qu’il faut prendre
en compte. En effet, le traitement d’encodage et de décodage sont effectués
par l’ensemble des serveurs. Avec le même algorithme, l’utilisation de stockage
sur la gamme HDS USP permet de déplacer la fonction d’encodage directement
sur les cartes matérielles de gestion des groupes de disques, en garantissant
un même niveau de flux identique à une configuration sans encodage. La raison
est que des composants spécifiques (Back End Director) sont en charge
nativement du traitement.
23
Advanced Encryption Standard
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 :
c l o u d s t o r a g e e t s t o c k a g e o b j e t
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 22 France
CLOUD STORAGE ET STOCKAGE OBJETS
QUELLE INTERACTION AVEC D’AUTRES CLOUD ET ACCES UNIVERSEL ?
L’interaction avec d’autres solutions du marché et l’accès sans dépendance avec
Hitachi sont du même ordre. Dès l’idée de conception du produit HCP, le
principe d’indépendance et de liberté de dépôt/consultation des informations
était l’essence de design de la solution. Cela se retrouve donc tout
naturellement à tous les niveaux de service. L’accès par un utilisateur ou une
solution tierce ne demande aucune spécificité informatique ou compétence forte.
Aucune API propriétaire Hitachi n’est nécessaire.
Il existe des intégrations verticales au sein des produits Hitachi, telle que la
migration automatisée de données depuis la gamme Hitachi NAS, mais aussi
depuis la gamme Hitachi Data Ingestor (HDI) et HCP Anywhere, ainsi qu’avec
plus d’une centaine d’éditeurs validés et certifiés.
XAM ET HCP – COMPLEMENTARITE OU OPPOSITION ?
Au travers des protocoles CIFS, NFS et http, Hitachi met à disposition un niveau
d’ouverture important, mais aussi de performance. L’ensemble des protocoles
disponibles de base dans la solution HCP sont la garantie d’un accès
indépendant et universel au regard de la technologie actuelle. La mise à
disposition de ces protocoles et leur intégration native évolueront avec
l’adoption par le marché de nouveaux standards. Par exemple XAM24, qui est
d’abord une initiative issue des constructeurs de stockage (SAN, NAS et CAS25),
mais qui pourrait servir de socle d’échange futur. Dans la mesure ou les
enregistrements dans HCP ne sont pas transformés ou propriétarisés, une
interface XAM n’a pas d’utilité au sein de la solution HCP
Hitachi est un membre actif du groupe SNIA en charge de définir les angles de
cette norme, qui souffre surtout d’une faible implication des éditeurs logiciels
plus enclins à travailler sur d’autres normes applicatives, liées au format de la
donnée, et à utiliser, pour l’échange, des protocoles du domaine public et du
Web, qui assurent des services bien plus évolués sans surcoût de
développement ou d’acquisition, sans couche logicielle supplémentaire et avec
de meilleures expériences. Même si une API JAVA pour XAM v1-0 a été
spécifiée en juillet 2008, son utilisation pour le transfert de volume important
pourrait en limiter la portée. Depuis sa ratification, à l’exception de
démonstrateurs, elle est peu utilisée en production. Il s’avère tout de même
que certains constructeurs poussent l’API XAM en remplacement de leur API
propriétaire et, par ce biais, ils obtiennent une légitimité dite d’ouverture. Mais
dans les faits et sans minimiser le travail réalisé, il s’agit toujours de remplacer
une API par une autre.
La stratégie Hitachi sur l’ouverture est de suivre l’Initiative SNIA sur le Cloud
Storage (voir les sites www.snia.org/cloud et www.sniacloud.com) intégrant
une orientation service de type SOA. Le service d’archivage à valeur probante
est pris en compte par cette Initiative. Hitachi Content Platform mets d’ailleurs
en œuvre le concept de Multi-Tenancy défini par la SNIA. La notion d’ouverture
pour les accès de lecture et d’écriture, mais aussi de migration, est alors
réalisée à partir des protocoles mis en avant par la SNIA, c’est-à-dire CIFS, NFS
et HTTP. XAM est considéré, par l’Initiative Cloud Storage, comme une source
Client. Ce Client pourrait être développé par un tiers éditeur pour répondre à un
24 eXtensible Access Method specification. 25 Content Addressable Storage. A noter que la solution HCP n’est pas un CAS. L’accès ne se fait pas par un
adressage du contenu (empreinte). L’empreinte dans HCP sert uniquement à la gestion de l’intégrité de stockage du document et non à la désignation effective du document. L’accès par adressage implique de gérer le risque des collisions d’empreintes, qui est aussi le souci de la déduplication.
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 :
c l o u d s t o r a g e e t s t o c k a g e o b j e t
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 23 France
besoin de dépôt ou d’échange avec un autre socle XAM. A noter, que la SNIA
propose aussi une autre initiative nommé CDMI26. Celle-ci serait plus en accord
avec les choix Hitachi en termes de dépôt, consultation, mise à jour, et
suppression de données.
EST-CE QU’HCP SUPPORTE UN MODE D’ACCES DE TYPE AMAZON S3 ?
A partir de la v5 HCP, les premiers éléments d’intégration liée à l’authentification
de type S3 seront mis en œuvre. A cet effet, HCP intègre une gestion dite
« Object ACLs », avec des notions groupes Publics ou Authentifiés. Ce support
est un clairement une orientation Cloud de l’utilisation de la solution HCP.
Dans une version supérieure à la v5 27 , le support complet d’un échange de
données en lecture-écriture de type Amazon S3 sera pris en charge par la
solution HCP au travers des Tenants-Namespaces. Il sera ainsi possible
d’intégrer aisément HCP à une multitude d’applications compatibles et déjà
disponible sur le marché.
QUELLES DEFINITIONS DES DROITS D’ACCES AUX OBJETS ?
En plus des droits d’accès aux Namespaces, certaines autorisations, aux niveaux
des Namespaces et des fichiers, organisent les fonctions autorisées et les accès
aux informations, par les utilisateurs
Liste des permissions définissant les accès au sein du HCP.
Au sein de la solution HCP, un mode de droits ACL, nommé Object ACL
permettent de spécifier les autorisations dans une orientation Cloud Storage
indépendamment des autorisations traditionnelles. En effet, dans un cadre de
gestion au-delà des systèmes de fichiers Windows et Linux et en accord avec
les nouveaux modes fonctionnels, tel que Amazon S3, la gestion des droits
étendus prend une forme indépendante. La solution HCP intègre donc ces
mécanismes du Cloud.
26 Cloud Data Management InterfaceTM – Technical Proposition v1.0.1 en date du 15 septembre 2011. 27 Contactez votre correspondant HDS pour plus de précision.
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 :
c l o u d s t o r a g e e t s t o c k a g e o b j e t
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 24 France
COMMENT SE PROTEGER DE L’EFFACEMENT ACCIDENTEL DE DONNEES ?
La prévention de l’effacement accidentel peut se gérer aux niveaux utilisateurs et
administrateurs. Un administrateur est un utilisateur avec un rôle particulier,
mais soumis aux mêmes règles d’accès. La prévention est aussi prise en
compte par l’étanchéité fonctionnelle des Tenants, proposée de base par HCP.
La première gestion est liée au mode WORM réglementaire, dans ce cas,
propriétaire ou non de la donnée, simple utilisateur ou super administrateur, la
désignation d’une rétention interdit tout effacement. Il s’agit d’une désignation
forte et irréversible de non suppression de la donnée, tant que le terme de la
rétention n’est pas arrivé.
Mais dans un cadre de stockage fichiers classique, c’est-à-dire sans
réglementation particulière, cette gestion s’organise via différents fonctionnels
au regard de l’architecture cible :
1. Niveau WORM sans niveau réglementaire : en effet une rétention
peut être appliquée à des fichiers et ainsi prévenir la perte accidentelle.
Cette rétention non réglementaire (non Compliant), peut être levée par le
propriétaire. L’effacement requiert donc plusieurs opérations.
2. Niveau Tenant/Namespace : seul le propriétaire du Tenant est autorisé
à réaliser des opérations de déclaration de droits sur les Namespaces
associés. Ce propriétaire du Tenant n’est pas l’administrateur de la plate-
forme. L’administrateur se voit donc interdire l’accès au Tenant ainsi que
toute opération de suppression ou de modification. L’effacement
accidentel par l’administrateur est donc impossible.
3. Niveau Namespace : l’accident d’effacement peut être prévenu, même
pour le propriétaire du Tenant auquel appartient le Namespace et même
pour le propriétaire de la donnée. Il suffit de définir les droits de purge sur
un compte tiers (responsable sécurité, DSI, contrôleur, …) non utilisateur
des données. Ainsi, toute opération d’effacement définitif est proscrit, sauf
par cet utilisateur spécifique, capable de réaliser une purge réelle.
4. Niveau Utilisateur : au regard de ses droits et du rôle assigné,
utilisateur peut être interdit de suppression tout en autorisant la lecture et
l’écriture de nouveaux fichiers. Il peut lui être imposé d’utiliser un compte
spécifique pour supprimer et modifier par écrasement le contenu d’un
fichier.
5. Niveau Objet : pour chaque fichier, HCP permet la désignation de droits
spécifiques nommés Object ACL, afin de limiter l’accès et l’effacement
accidentel par un utilisateur non autorisé.
6. Niveau Système : le fonctionnel Data Protection Level (DPL) est une
méthode physique pour définir une protection contre la perte accidentelle
d’équipement matériel. Il s’agit de spécifier que chaque donnée est
systématiquement doublée (jusqu’à 4 copies). Ainsi, en cas de perte d’une
copie, la plateforme reconstruit automatiquement la copie perdue. Ce
mécanisme sert à prévenir les pertes physiques de disques (panne,
arrachement, casse volontaire, …). Le DPL est un complément à la
protection physique RAID-6 systématiquement mise en place dans une
solution HCP.
Tous ces modes de gestion peuvent être mixés. Ils ne sont pas exclusifs les uns
par rapport aux autres et sont à compléter, par le WORM réglementaire et par
une réplication simple site ou multi sites, afin de parer à toute perte majeure
(inondation, incendie, dégradation volontaire, erreur humaine, …).
SYNCHRONISATION ET PARTAGE DE FICHIERS EN NOMADISME
Afin de répondre à la problématique de partage de fichiers entre différents
équipements, tel un smartphone, le système de fichiers d’un ordinateur
personnel et un navigateur Web, Hitachi propose la solution HCP Anywhere
(HCP AW). Il s’agit d’un environnement logiciel et matériel (cluster de 2
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 :
c l o u d s t o r a g e e t s t o c k a g e o b j e t
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 25 France
serveurs Hitachi) qui s’ajoute à une plate-forme HCP. Cet environnement sert
d’interface et de portail d’accès entre les utilisateurs, les applications clients sur
les équipements des utilisateurs et le stockage HTTPs du HCP.
Depuis le bureau Windows ou MacOS, une icône permet d’accéder au menu principal du
client logiciel HCP-AW. Un menu déroulant contextuel est aussi accessible directement
depuis chaque fichier (clic droit avec Windows).
HCP-AW permet donc à chaque utilisateur d’accéder à ses données personnelles
depuis n’importe quel équipement situé au sein de son entreprise ou en
déplacement. Le principe de base est d’associer un espace disque sur chaque
équipement (ordinateur et smartphone) à un espace de stockage dédié sur un
HCP. Le cluster matériel HCP-AW sert de passerelle pour contrôler les échanges
de données. Sur chaque équipement client, il est nécessaire d’installer une
application pour le dialogue sécurisé avec la passerelle HCP-AW. Dès qu’une
connexion réseau est active, ce dialogue consiste principalement à synchroniser,
en quasi temps réel, les données actives entre l’équipement client et le
stockage centralisé dans un HCP. Les données sont donc automatiquement
protégés et visibles depuis tous les terminaux autorisés.
Cette synchronisation autorise d’autres fonctionnels comme le partage avec des
collaborateurs ou des personnes externes à l’entreprise. Le mode principal de
partage consiste à envoyer par email un lien pointant sur le fichier à partager.
Le destinataire clic alors sur le lien pour télécharger le fichier. Cette méthode
permet de réduire le volume des pièces attachés et de dépasser les limites de
volume imposer par les messageries. Ce lien de partage sur un fichier est de 2
natures :
Interne : seuls les collaborateurs de l’entreprise peuvent télécharger le
fichier.
Public : toutes les personnes internes ou externes à l’entreprise peuvent
télécharger le fichier.
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 :
c l o u d s t o r a g e e t s t o c k a g e o b j e t
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 26 France
Coté critère de partage du lien, l’utilisateur à seulement la possibilité de définir
une durée de vie, en nombre de jours, sur le lien. Mais le plan d’évolution de
HCP-AW prévoit d’ajouter de nouveaux critères.
Un second type de partage concerne le répertoire. Ce partage est autorisé
uniquement en interne de l’entreprise et en désignant spécifiquement d’autres
utilisateurs connu dans l’annuaire.
LIMITES FONCTIONNELLE DE LA SOLUTION HCP ANYWHERE
Limite par Utilisateur Description
#Max. de terminaux. 5 (hors accès au portail Web)
#Max. d’entrée par répertoire 10,000 (fichier et/ou répertoire)
#Max. de fichiers et répertoires. 50,000
#Max. de répertoires partagés. 20
#Max. invitation sur des répertoires partagés. 100
Limite Globale Description
Taille maximale d’un fichier. Configurable entre 1 Go et 2 To, par
défaut la limite est 10 Go.
Longueur max. d’un chemin d’accès (Path). 1,023 caractères.
Longueur max. d’un nom de fichier ou répertoire. 255 caractères.
Pour les application mobile, #Max. du nombre de
fichiers ajoutés à la liste des favoris.
Aucune limite, dépend de l’espace
disponible sur le terminal.
Les autres limitations concernent le nommage des fichiers et répertoires qui ne
peuvent sans nom, ainsi que l’interdiction de certains caractères, tels que la
barre verticale (|), le point-virgule ( ;), les symboles inférieur(<) et supérieur (>),
etc. Ces limites sont d’ailleurs celles des principaux systèmes de fichiers.
Enfin, HCP-AW ne synchronise pas certains fichiers de configuration du système
d’exploitation source, comme « desktop.ini » et « .DS_Store », mais aussi les
liens symboliques et les fichiers de communication (pipe, socket, etc.).
ACTIONS GLOBALES REALISABLES PAR L’UTILISATEUR AVEC HCP ANYWHERE
Action du Profil Utilisateur Complément d’Information Partage de lien sur un fichier en vue de son téléchargement.
Interne (par défaut) ou Public (si autorisé par l’administrateur).
Etendre et supprimer un lien sur un fichier
Partage sur un répertoire En tant qu’initiateur et propriétaire du répertoire partagé, l’utilisateur gère les invitations aux membres à écrire et lire dans ce partage.
Ajout, modification et suppression de fichiers et répertoire dans son espace
Restauration d’un fichier ou d’un répertoire supprimé dans son espace
L’utilisateur sélectionne le fichier à restaurer depuis la liste des versions conservées dans le HCP.
Restauration de l’ancienne version d’un fichier non supprimé.
Idem action précédente.
Accès à la l’activité complète sur le compte et ses données
Via le portail Web HCP-AW, l’utilisateur peut consulter toutes les activités sur les données gérées au sein de HCP-AW : nouveau fichier, mise à jour, suppression, téléchargement, accès au compte, etc.
Consulter et gérer la liste des équipements autorisés sur le compte HCP-AW
L’utilisateur peut consulter les équipements qu’il a autorisés et supprimer leur autorisation.
Installation d’un agent client HCP-AW Via les Store des équipements (Apple, Google, etc.) et en téléchargement depuis le portail HCP-AW.
Configurer la réception d’une notification L’utilisateur peut être averti par email quand, par exemples, un fichier a été téléchargé ou lors d’un échec d’ accès à son compte.
Consultation des seuils et statistiques Affichage du quota, du nombre de fichiers, nombre d’équipements, espace libre, etc.
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 :
c l o u d s t o r a g e e t s t o c k a g e o b j e t
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 27 France
ACTIONS REALISABLES PAR CLIENT HCP ANYWHERE
Pour utiliser HCP-AW, l’utilisateur passe principalement par un agent client ou via
le portail Web. L’accès par le portail Web utilisateur ou par un agent nécessite
une authentification. En fonction de la plate-forme de l’agent, certaines actions
sont possibles et d’autres pas, comme par exemple la restauration de fichiers et
répertoires suite à perte ou suppression accidentelle.
Le tableau28 suivant donne un résumé des actions par type de client et par action.
Action Windows Desktop
Mac OS Desktop
Apple iOS Android Portail Web
Ajout de fichiers ✓ ✓ ✓ ✓ ✓
Lister les fichiers
et répertoires ✓ ✓ ✓ ✓ ✓
Télécharger ✓ ✓ ✓ ✓ ✓
Accès au contenu
en mode Offline ✓ ✓
Via favoris
uniquement
Via favoris
uniquement
Création
répertoires ✓ ✓ ✓ ✓ ✓
Suppression
fichiers et
répertoires
✓ ✓ ✓ ✓ ✓
Restauration
✓
Historique sur un
fichier
Via lien vers
le portail
Via lien vers
le portail ✓
Renommer ✓ ✓
✓
Déplacer fichiers
et répertoires ✓ ✓
✓
Rechercher un
fichier et
répertoire
Via l’outil de
recherche
du poste
Via l’outil de
recherche
du poste
✓ ✓ ✓
Partage de
fichiers
Via lien vers
le portail
Via lien vers
le portail ✓ ✓ ✓
Partage de
répertoires
Via lien vers
le portail
Via lien vers
le portail ✓
Gestion des
partages de
répertoires
✓
Gestion des
partages de
fichiers
✓
Etat de la
synchronisation ✓ ✓
Vue du quota ✓ ✓ ✓ ✓ ✓
Gestion des
terminaux ✓
Vue de l’activité
✓
Notifications par
email ✓
28 Le contenu du tableau évolue au grés des nouvelles versions HCP-AW. Par exemple, le nouveau support de
Windows Phone n’y est pas listé.
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 :
c l o u d s t o r a g e e t s t o c k a g e o b j e t
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 28 France
ACTIONS REALISABLES PAR L’ADMINISTRATEUR AVEC HCP ANYWHERE
Au sein du portail de la solution HCP-AW, il existe principalement 2 catégories de
comptes de niveau administrateur, afin de définir un rôle d’administrateur
(Admin) et un rôle d’auditeur (Audit).
Action du Profil Administrateur Complément d’Information Gestion de l’annuaire. Aujourd’hui uniquement AD. Cette gestion comprend
aussi les groupes AD.
Suivi des équipements matériels. CPU, disque, réseau, etc. Métrique sur la capacité utilisé et optimisé. Métrique sur les opérations : Read, Write, Delete, …. Intégration Syslog, SNMP et email notification.
Suspension et suppression d’utilisateurs.
Gestion des quotas par groupe et utilisateur.
Gestion de la durée max par défaut d’un partage. Définition max. du nombre de jours autorisés.
Autorisation sur la création de liens publics. Interdit ou non l’utilisation de partage public.
Suppression des données (Wipe) sur un terminal. Utile en cas de perte ou de vol.
Gestion de la politique de mot de passe Admin. Nombre de caractères, expiration, etc.
Filtrage des IP en accès à la console.
Gestion de l’accès aux Tenant d’un HCP. Politique de Versioning et Compression. Il y a un Tenant pour les données et un Tenant pour la protection de base de données du portail HCP-AW. Un autre Tenant est éventuellement nécessaire en cas de gestion de clients HDI par HCP-AW.
Audit. Suivi de l’activité globale et par utilisateur.
Gestion de la sécurité. Certificats SSL, autorisation du Ping et SSH, Timeout des navigateurs,….
Intégration avec un Anti-Virus. Symantec et McAfee via protocole ICAP.
Gestion du « Branding ». Personnalisation par un logo d’entreprise.
Gestion de la licence d’utilisation. HCP-AW nécessite une licence d’utilisation basée sur le nombre d’utilisateurs.
Gestion du déploiement de plateformes HDI. Il s’agit d’un fonctionnel spécifique pour aider au déploiement de solutions HDI (disque de bureau) sur les sites distants, via une automatisation des configurations HDI.
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 t e c t u r e e t d é p l o i e m e n t I T
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 29 France
ARCHITECTURE ET DEPLOIEMENT IT
QUELLE METHODE DE CHANGEMENT DE SUPPORT PHYSIQUE ?
La migration de données concerne le déplacement de la donnée archivée d’une
plate-forme HCP vers une autre ou vers une solution différente et,
éventuellement, non Hitachi. La migration de support concerne le changement
physique utilisé pour l’enregistrement et la conservation de la donnée. Dans
HCP, il s’agit du disque dur.
La migration de support peut donc être au niveau du disque (remplacement et
changement de technologie) et au niveau de la baie, qui contrôle les disques.
Ces deux niveaux sont couverts par la solution HCP. En effet, la solution HCP
supporte la mise en œuvre de plusieurs technologies disques et/ou de plusieurs
technologies de baie de stockage, avec des générations différentes.
Habituellement pour des raisons de coût et de capacité, la technologie SATA est
employée pour la conservation, mais il est permis d’utiliser des technologies FC,
SSD et SAS. Il n’y a pas de lien technique impliquant une technologie disque
spécifique. Le même principe de non dépendance existe avec les baies de
stockage. Ainsi, HCP supporte un environnement bâti avec un ou plusieurs
stockages de génération courants et un ou plusieurs stockages de génération
inférieure.
Du fait de cette indépendance aux technologies de stockage, la migration interne
de support est gérée automatiquement. Il est ainsi possible de supprimer une
ancienne génération de stockage et d’en ajouter une nouvelle. Le déplacement
interne est automatisé et gérée directement pas la solution HCP. Ce moyen
répond à la première préoccupation de suivi des technologies dans le temps au
regard d’un archivage sur le long terme ou la vie informatique d’un équipement
est moindre que la vie métier d’une donnée.
COMMENT EXTERNALISER DES DONNEES DU HCP VERS DES BANDES ?
En fonction de la nature du Tenant (Default Tenant ou Multi Tenants), il existe
plusieurs méthodes de transfert, sauvegarde et réplication vers des bandes.
Default Tenant – Sauvegarde.
Via le protocole NDMP v4, il est permis de collecter les données et les
métadonnées, pour enregistrer vers une robotique physique ou virtuelle, les
données stockées sur la plate-forme HCP. Cette opération permet d’obtenir un
exemplaire externalisé, pour une restauration ou non vers un HCP, depuis un
format indépendant puisque les enregistrements envoyés par HCP vers les
bandes sont en GNU Tar. Par choix de configuration, ces enregistrements
peuvent subir un encodage et une compression.
Ce type de sauvegarde est supporté uniquement dans le Default Tenant. Avec les
dernières versions HCP, le Default Tenant n’est pas une priorité fonctionnelle.
Sa disponibilité reste toujours active, mais l’utilisation des Multi Tenants est
fortement recommandée et privilégiée dans les extensions et évolutions
fonctionnelles du HCP (sécurité, protocole, métadonnée, etc.).
Multi Tenants – Sauvegarde.
Pour prendre en compte les Multi Tenants, la mise en œuvre d’une solution de
sauvegarde sachant dialoguer HTTPs, tel que le produit StorFirst Apollo29 de
Seven10 disponible au catalogue Hitachi, est nécessaire. Cette solution
logicielle est sans doute la plus aboutie, puisqu’elle consiste à réaliser des
sauvegardes du contenu d’un ou plusieurs HCP (granularité Namespace)
directement vers une robotique de bandes. Le produit StorFirst est surtout mis
29
www.seventenstorage.com
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 t e c t u r e e t d é p l o i e m e n t I T
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 30 France
en avant pour sa capacité de réplication sur bandes de troisième niveau (DR+1).
La granularité de restauration est au choix par Objet (fichier+ métadonnées),
Namespace ou le système HCP complet. La justification financière d’installer
StorFirst est liée aux environnements HCP supérieurs à 100To de données ou
aux obligations métier (banque, assurance) et d’infrastructure (pas de second
site DR).
Multi Tenants – Migration.
La seconde méthode, de prise en charge des Multi Tenants, consiste à utiliser la
solution HSM ou SntrySTR de QStar 30 (partenaire Hitachi), c’est-à-dire un
fonctionnel logiciel capable d’écrire à la fois les archives sur des médias bandes
(LTO, SDLT, etc.) et sur HCP au travers du protocole HTTP. A noter que les
solutions SntryDICOM et SntryPACS proposent le même fonctionnel de copie
synchrone, locale ou distante entre Hitachi Content Platform et une librairie de
bandes (physiques ou virtuelles), mais avec des services dédiés aux
environnements cliniques (DICOM, HL7, etc.).
EST-IL POSSIBLE D’INSTALLER HCP COMME TIERS EXTERNE DU HNAS
Le principe de fonctionnement de la relation HNAS-HCP est relativement simple.
Il s’agit de définir un ou plusieurs chemins de migration entre un système de
fichiers du HNAS vers un Namespace du HCP. Un Namespace est adressé à
partir d’une URL, par exemple https://compta.2011.archive.hds.net, et d’un
accès Login+Password. Dans l’URL en exemple, archive.hds.net serait le
domaine d’accès à la plate-forme HCP, 2011 serait le nom d’un des Tenants du
HCP et compta serait un des Namespace du Tenant 2011. Une fois le chemin de
migration configuré sur le HNAS, il suffit de créer les politiques de migrations
depuis le HNAS. La configuration sur le HCP consiste à créer un Tenant, un
Namespace et une autorisation d’accès en fonction des choix de classification
des données.
Architecture de délestage entre HNAS et HCP intégrant la protection par réplication.
La solution Hitachi Content Platform est une plate-forme de stockage multi-
protocoles et capable d’accueillir des volumes très importants de données. Son
intégration avec le HNAS en tant que Tiers externe de stockage apporte des
compléments fonctionnels tels que :
L’optimisation du stockage, tels que la compression, la déduplication
fichier (SIS), le Versioning et la mise en WORM de données ciblées.
La sécurisation, par le cloisonnement de données migrées (Tenant), par
exemple pour isoler certaines informations de valeur.
30
www.qstar.com
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 t e c t u r e e t d é p l o i e m e n t I T
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 31 France
La protection, par l’intégration de la réplication automatique vers une
solution HCP distante ou la définition de politique de copies multiples sur
des données de valeur.
La performance multithreading, au travers d’une architecture multi-
contrôleurs internes.
L’administration réduite au minimum de suivi, car HCP propose une prise
en charge automatisée des volumes mis à sa disposition par des capacités
de répartition dynamique des données.
MAINTENANCE DES SUPPORTS DE STOCKAGE
Le premier niveau de maintenance lié au changement des supports concerne
l'organisation physique des disques. Le Groupe RAID-6 assure une double
parité des enregistrements en mode bloc et permet la perte physique jusqu'à 2
disques durs, qui pourront être remplacés. En cas de perte de plus de deux
disques, l'accès aux données peut être assuré par la copie interne (Réplica) sur
un autre Groupe RAID-6 de la plate-forme HCP. La remise en œuvre des
disques assurent un recouvrement automatique des données à partir de la
copie interne. Si deux Groupes RAID-6 sont détruits et concernent les données
sources et leurs copies. La réplication distante permettra d’accéder à la seconde
plate-forme HCP, pour restaurer les données sources.
COMMENT GERER UN PARTAGE MIXTE ET DES DROITS CIFS-NFS ?
L’enregistrement de fichiers via les protocoles CIFS et NFS se réalise, pour le
moment, uniquement dans le Default Tenant (domaine principal de dépôt). Le
système de fichiers des données ou des métadonnées est alors accessible à
travers un unique partage réseau31, quel que soit la volumétrie gérée, car dans
le Default Tenant, il n’y a pas de partitionnement de l’espace alloué. Avec NFS,
la commande Unix/Linux mount permet de créer un lien entre un répertoire
HCP et un répertoire de la plate-forme de destination32.
Vue de l’arborescence de données et ses métadonnées, accessible avec CIFS et NFS.
L’utilisation de CIFS et NFS implique des limitations. Si ce mode d’accès
s’apparente à une solution NAS, la solution HCP n’est pas directement un NAS
et ne peut être utilisée comme telle. Car l’édition directe de fichier n’est pas
permise. La copie, l’ouverture et la suppression d’un fichier est autorisée, mais
la modification directe via un éditeur approprié ne sera pas validée au moment
31 Par exemple en CIFS : \\cifs.hcp.example.com\fcfs_data\images ou \\192.168.211.80\fcfs_data\images 32 Par exemple en NFS : mount -t nfs nfs.hcp-name.domain-name:/fcfs_data/images /home/user1/images
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 t e c t u r e e t d é p l o i e m e n t I T
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 32 France
de l’enregistrement. HCP se comporte comme un WORM, même si aucune
rétention et si tous les droits sont correctement positionnés.
Cette limitation énoncée sur l’accès en mode NAS est contournée par le produit
Hitachi Data Ingestor, qui est une passerelle CIFS & NFS vers le HCP, avec une
complète intégration NAS aux annuaires AD et LDAP de l’entreprise.
Exemples des permissions pour les différents protocoles pris en charge par HCP v3.
En CIFS, il y a deux modes d’accès : anonyme et authentifié. L’authentification
est liée à un environnement Active Directory. Hors configuration avec HDI, la
connaissance du compte directement par HCP est nécessaire pour accéder aux
données.
Si l’utilisation de CIFS et de NFS autorise une liaison avec un annuaire, le
positionnement des droits correspond au standard POSIX, chaque fichier est
associé à un propriétaire (UID), un groupe (GID) et des permissions : lecture,
écriture (ajout, remplacement et suppression) et exécution (utile uniquement
pour les exécutables ou pour traverser un répertoire). La vue des droits est
principalement abordable par les protocoles HTTPs, WebDAV et NFS.
Hors accès via un serveur HDI, les droits étendus (Access Control List) sur NFS et
CIFS ne sont pas pris en charge. La translation des droits POSIX vers CIFS est
principalement réalisée à travers les permissions Read (r--) et Write (-w-). La
permission Execute (--x) est nécessairement associée à une autre permission33.
COMMENT MIGRER DES DONNEES ET DES METADONNEES ?
Les protocoles CIFS, NFS et HTTPs permettent un accès direct aux données et
métadonnées. Une copie de niveau fichier peut donc être réalisée vers une
destination de stockage non HDS.
Une copie vers une autre plate-forme HCP (génération n+x) peut se réaliser aussi
par une copie via le protocole CIFS, NFS et HTTPs (WebDAV, HS3, cURL, etc.).
Pour des raisons de contrôle et de conformité, il sera préférable, soit d'utiliser
les mécanismes internes de réplication en mode fichier+métadonnées, soit
d'utiliser les éventuelles capacités de transfert de l'application Métier (ou
Collecteur). L'utilisation de la réplication par HCP permet une migration
complète des données et des métadonnées sans altérer les périodes de
rétention et met en œuvre un contrôle d'intégrité des données avant le
transfert et à la réception sur le nouvel HCP.
Autre solution, le produit HCP Data Migrator est livré de base avec chaque HCP. Il
est utilisable via une interface graphique et un mode CLI et propose de réaliser
des transferts à la demande ou programmés de fichiers entre un système de
fichiers (Windows, Unix ou Linux) vers une plate-forme HCP et inversement.
33 Par exemple : r-x, –wx ou rwx.
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 t e c t u r e e t d é p l o i e m e n t I T
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 33 France
QUELLE TECHNOLOGIE POUR OPTIMISER ET DE REDUIRE LA VOLUMETRIE ?
Hitachi Content Platform propose deux services d’optimisation de la volumétrie de
stockage. Ces services sont disponibles de base sans surcoût et son débrayable.
Le premier service concerne l’identification des doublons de fichiers, désigné par
le terme Single Instance. C’est-à-dire l’enregistrement de fichiers avec le même
contenu, mais pas nécessairement avec le même nommage. HCP détecte
automatiquement ces contenus identiques et réalise une comparaison binaire
pour s’assurer de leur équivalence, avant de supprimer les redondances et de
conserver respectivement leur désignation ficher, leur emplacement, leur nom
et leurs métadonnées.
Outil de calcul du pourcentage de réduction automatique de la volumétrie HCP.
Le second service concerne la compression automatisée des contenus. Suivant le
type de donnée, cette compression est plus ou moins efficiente. Les taux de
compression les plus importants touchent les contenus ASCII. Pour évaluer les
gains en volume, il suffit de réaliser un échantillonnage à l’aide de l’outil Gzip34.
La solution Hitachi Content Platform propose une compression un peu
supérieure à Gzip. Afin d’évaluer la volumétrie utile nécessaire à chaque projet,
Hitachi utilise un outil, pour calculer les différents ratios d’optimisation en
fonction des types de fichier enregistrés.
ENVIRONNEMENT DE TESTS OU PRE PRODUCTION : QUELLE SOLUTION ?
Dans le cadre d’un environnement de tests et de pré production, Hitachi Data
Systems propose une solution HCP VMware. Il s’agit d’une architecture de 2
images VMware simulant deux serveurs HCP. Cet environnement virtuel permet
de restituer l’ensemble du fonctionnel HCP, afin de faciliter des développements,
des tests avant production et une gestion de conduite du changement. La mise
à disposition et l’installation des VM sont réalisées par une prestation de service
HDS. Elle est associée à un transfert de compétence ou une formation officielle.
La configuration nécessite au préalable l’installation de VMware Server, ESX ou
ESXi. Chaque image VMware nécessite une allocation de 4Go de mémoire, un
stockage de 40Go et deux cartes réseau. Une des cartes simule l’accès IP GbE
privé du HCP et doit être connectée à un Switch IP virtuel (par défaut :
10.1.1.x) dédié, correspondant au réseau privé inclus dans le HCP physique. La
seconde carte réseau correspond à l’accès public de l’entreprise. En fonction de
la configuration, il est permis de connecter la seconde carte à un réseau
physique ou virtuel VMware (par exemple : 192.168.1.x), si la communication
34
www.gzip.org : GNU zip, logiciel libre de compression, disponible sous diverses plates-formes.
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 t e c t u r e e t d é p l o i e m e n t I T
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 34 France
avec le réseau d’entreprise n’est pas nécessaire et que seuls des échanges
internes au serveur VMware sont suffisants.
Schéma générique de déclaration des images HCP dans un serveur VMware.
Pour une meilleure correspondance à un solution HCP de production, les images
VMware HCP peuvent être configurées avec un serveur de temps (NTP), pour la
synchronisation des horloges entre les serveurs HCP et les serveurs applicatifs
de l’entreprise, et un serveur DNS. Ce dernier permet de travailler sur des
déclarations de noms de domaine (Tenant et Namespace) via une délégation
des deux adresses IP du HCP virtuel. Sans serveur DNS, il sera nécessaire de
configurer le fichier Hosts du serveur accédant au HCP, via une association
entre les adresses IP public des VM et les domaines d’accès aux espaces du
HCP. Avec l’utilisation d’un serveur DNS, les déclarations dans le fichier Hosts
sont totalement inutiles.
Exemple du contenu d’un fichier C:\windows\system32\drivers\etc\hosts pour Windows :
chaque adresse IP est associée au Hostname et aux domaines d’accès (Tenant et Namespace) au regard des configurations réalisées dans la partie administration
générale du HCP et l’administration du Tenant cible, comme l’utilisation du protocole CIFS (cifs.vmhcp.domain.local) et/ou HTTPs (Tenant : demo.vmhcp.domain.local et
Namespace : name.demo.vmhcp.domain.local).
Une configuration de base avec VMware Server installée sur un serveur Windows
2003/2008 suffit à une mise en œuvre simple et rapide et peut, par exemple,
faire cohabiter l’application métier et le HCP sur la même plate-forme physique,
afin de minimiser les impacts sur l’organisation de l’entreprise et faciliter un
test unitaire ou un développement.
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 e r f o r m a n c e s
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 35 France
PERFORMANCES
QUELLES SONT LES PERFORMANCES D’INGESTION ET DE CONSULTATION ?
Les performances de dépôt et de consultation, mais aussi de réplication, d’une
solution HCP sont directement liées au nombre et à la taille des fichiers, mais
aussi à la configuration matérielle du HCP. En effet, en dehors de la
considération d’organisation RAID des disques de la baie de stockage (plusieurs
baies sont aussi autorisées), le nombre de serveurs de traitement (nommé
nœud de stockage ou contrôleur) est important pour gérer la volumétrie, mais
aussi pour traiter les demandes en écriture et en lecture, ainsi que les
traitements automatisés internes, comme par exemple, la compression et
l’encodage.
Exemples de performances par taille et nombre de fichiers avec HTTP sur 2 nœuds HCP v3.
La seconde dépendance principale concerne le choix du protocole. En effet, le
mode de fonctionnement LAN des protocoles NFS et surtout CIFS a une
incidence sur le débit des flux, alors que le protocole HTTP apporte un modèle
assurant des dépôts et des consultations supérieurs en nombre de traitements
simultanés. Cette différenciation est liée à l’architecture GRID Cluster de la
solution Hitachi Content Platform.
Le modèle matériel du HCP et sa version ont aussi une implication dans les
performances, celles-ci sont croissantes en fonction de ce choix : HCP 300, HCP
500 et HCP 500 XL. Le modèle 500XL est plus performant que le modèle 500
lui-même plus performant que le modèle 300. Chaque nouvelle version apporte
aussi son lot d’optimisations, à titre d’exemple la v5 (avril 2012) apporte 2 fois
plus de performance au protocole NFS que la v4 dans les mêmes conditions.
PERFORMANCE HTTP ET LOAD BALANCING DU HCP
Afin d’assurer les performances maximales de lecture-écriture, Hitachi
recommande l’utilisation du protocole HTTP. En effet, au contraire des autres
protocoles CIFS et NFS, l’utilisation du protocole HTTP permet de répartir
dynamiquement les accès lecture-écriture, en utilisant tous les serveurs
(Storage Nodes) du HCP, et ainsi maximiser les capacités physiques de
traitement et de parallélisassions des flux.
A partir d’une configuration de délégation d’un sous domaine, depuis le serveur
DNS de l’entreprise, les requêtes HTTP sont automatiquement envoyées à
chaque serveur du HCP, dans un cycle de rotation. Ainsi l’utilisation de 4
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 e r f o r m a n c e s
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 36 France
serveurs HCP par 12 requêtes HTTP, pour l’envoie de 12 fichiers différents,
autorise chaque serveur à traiter 3 fichiers en simultané. Ce mode permet aussi
de passer automatiquement au serveur suivant en cas d’indisponibilité d’un ou
plusieurs serveurs.
Principe du Load Balancing HCP entre les contrôleurs.
La répartition de charge (Load Balancing) est transparente pour les applications
et les utilisateurs accédant aux données du HCP en mode HTTP. Cette
optimisation de charge implique l’utilisation de l’adresse UNC 35 et non de
l’adresse IP (ou Hostname) de chaque serveur. Même si cela est possible et
fonctionne, l’utilisation de l’adresse IP ou du Hostname restreint à adresser
uniquement la plate-forme désignée et non la ferme de plates-formes du HCP
dans sa globalité.
L’URL de stockage est donc un excellent moyen d’accéder à la performance
maximale du HCP, ainsi que la haute-disponibilité.
35 Universal (ou Uniform) Naming Convention.
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 :
s o l u t i o n s e t e x t e n s i o n s f o n c t i o n n e l l e s
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 37 France
SOLUTIONS ET EXTENSIONS FONCTIONNELLES
HITACHI DATA INGESTOR – ACCES CIFS-NFS ET LE MODE ROBO ?
Hitachi Data Ingestor est une solution NAS matérielle et logicielle entièrement
compatible avec les annuaires d’entreprises et intégrant tout le fonctionnel
d’une solution NAS classique. Elle est disponible en mode Cluster, Single et
image VMware.
Son rôle principal est d’être au plus près des applications et des utilisateurs et de
fonctionner comme un espace de stockage temporaire au regard d’une solution
HCP distante (mode ROBO36). C’est-à-dire que toutes les données enregistrées
sur HDI sont automatiquement copiées vers un Tenant/Namespace HCP. Ainsi
les données les plus utilisées sont systématiquement conservées dans le HDI et
en fonction de sa capacité de stockage, le NAS HDI transfert les données vers
le HCP tout en conservant un lien local. Pour l’utilisateur, l’opération est
totalement transparente. Le seul impact concerne le temps d’accès à une
donnée qui a été transférée (migrée). Le rapatriement automatique est géré
par HDI via le protocole HTTPs.
Hitachi Data Ingestor permet d’envisager de larges architectures distribuées et
automatisées, réduisant les coûts de gestion et supprimant les sauvegardes locales.
HDI est donc :
Un serveur NAS en accès CIFS et NFS.
Un accélérateur d’accès aux Tenants HCP, par son espace Cache Disque.
Une solution d’architecture distribuée multi-sites, d’accès à un ou
plusieurs HCP consolidés et sécurisés.
Une solution de sauvegarde, par rapatriement automatique vers un Data
Center de données enregistrées sur des sites locaux.
36 Remote Office Branch Office
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 :
s o l u t i o n s e t e x t e n s i o n s f o n c t i o n n e l l e s
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 38 France
QUELLE CONFIGURATION VMWARE MINIMALE POUR LA VM HDI ?
La VM HDI supporte VMware ESXi et VMware vSphere Client 4.1 et les versions
supérieures. En comparaison avec la solution matérielle Single Node HDI, la VM
HDI a les caractéristiques suivantes :
Tagged-VLAN et Link Aggregation/Alternation ne sont pas configurables.
Ces fonctions sont disponibles dans le modèle matériel.
La performance est dépendante de la charge de la plate-forme VMware
Elément Configuration
Nombre de processeur 2
Taille Mémoire 4 Go
Capacité des disques virtuels - Virtual Disk Disques SATA supportés
OS 26624 Mo
Contrôle de migration 35099 Mo
Données utilisateurs 1057 Mo ou plus37
Contrôleurs SCSI LSI Logic SAS
NIC Nombre 2
Type E1000 or VMXNET3 (exclusivement)
Serial Port Nombre 1
Type Connexion Output of file
Lecteur CD/DVD IDE. Mapping ISO image
Tableau des pré requis pour une installation de la VM HDI avec VMware.
LA GESTION DES DONNEES ET LES FLUX ENTRE HDI ET HCP SONT-ILS OPTIMISES ?
La solution Hitachi Data Ingestor se comporte comme un NAS de partage réseau
de fichiers via les protocoles CIFS, NFS et/ou FTP, mais c’est avant tout une
solution Cache. C’est-à-dire que les données sont physiquement accessibles
depuis le HDI en fonction de la volumétrie associée au HDI, de la capacité de
partage NAS et à la politique de migration automatique.
La migration est réalisée via un ordonnanceur interne à chaque HDI et peut-être
associée à des choix de fichiers et de répertoires. L’optimisation débute donc
par la sélection des données enregistrés dans un partage HDI. Le flux de
transfert vers un Tenant/Namespace est réalisée via le protocole HTTPs REST.
Le contenu des données transmises est compressé (supporté par REST API).
L’utilisation du HTTPs permet une répartition dynamique sur l’ensemble des
contrôleurs du HCP, afin de favoriser un transfert optimisé.
COMMENT MESURER LA BANDE PASSANTE NECESSAIRE ENTRE HDI ET HCP ?
De base, il n’y a pas de bande passante spécifique nécessaire à la
synchronisation de données entre un HDI et un HCP. Cette affirmation n’est pas
une réponse En effet, une bande passante ne se calcule pas seulement sur la
présence d’équipement matériels, mais principalement sur le flux de données
qui doit y transiter sur une période déterminée. En résumer, si la volumétrie est
faible, il ne sert à rien d’avoir une bande passante importante sauf si la période
de synchronisation doit être très courte, et si la volumétrie est forte, mais que
le temps accepté de synchronisation est très important, une bande passante
faible pourrait être acceptable.
La bonne réponse se bâtie sur une liste de contraintes (ou de mesures) qui sont
liées en priorité au nombre d’utilisateurs, à la quantité de données modifiée
entre chaque synchronisation, la taille moyenne des fichiers et la période
37 Le Virtual Disk ne peut pas être étendu ensuite. La capacité nécessaire doit être correctement définie à la
configuration initiale.
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 :
s o l u t i o n s e t e x t e n s i o n s f o n c t i o n n e l l e s
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 39 France
horaire autorisée à la synchronisation. L’exercice peut aussi être inverse. C’est
d’ailleurs souvent le cas. Il y a une bande passante liée à l’équipement réseau
déjà en place et il s’agit de savoir si elle suffira à assurer une synchronisation
adaptée au renouvellement des données à synchroniser et à l’attente de
protection et de sécurisation attendue. Dans ce cas aussi, il faut connaitre le
volume potentiel entre deux synchronisation. Il y a un postulat clair : même si
le flux entre HCP et HDI est optimisé et peut bénéficier d’optimisation par les
équipements matériels du réseau IP en place, il est impossible d’aller plus vite
que la capacité physique du réseau.
En conclusion, la connaissance de la bande passante nécessaire à la
synchronisation des fichiers entre un HDI distant et le HCP centralisé ou la
connaissance du temps nécessaire à assurer une synchronisation dépend de
métriques, des objectifs de service et des matériels cibles et déjà en place :
Métriques :
o Nombre d’utilisateur ;
o Volume jour/utilisateur ;
o Taille moyenne des fichiers ;
o Nature et type des fichiers ;
o Latence du réseau ;
Objectifs :
o Recovery Point Objective – RPO ;
o Recovery Time Objective – RTO ;
Matériels :
o Taille du cache HDI ;
o Nombre de nœuds HDI ;
o Nombre de contrôleurs HCP ;
o Equipement WAN en place ;
EXISTE-IL DES ABAQUES DE PERFORMANCES ENTRE HDI ET HCP ?
Afin d’accompagner les clients dans le dimensionnement de leur architecture
ROBO (Remote Office Branch Office), Hitachi procède à des tests, de
synchronisation en situation, complétés par des retours d’utilisation sur des
sites de production. Les abaques sont bien évidement liés au contexte de
configuration matérielle HCP/HDI, à la qualité du réseau, à la nature des
données synchronisées et à leur taille moyenne.
Exemples sur la synchronisation entre un HCP 500 de 4 contrôleurs et un HDI Single.
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 :
s o l u t i o n s e t e x t e n s i o n s f o n c t i o n n e l l e s
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 40 France
QUELS SONT LES BENEFICES A UTILISER HDDS AVEC HCP ?
Les entreprises doivent absolument être en mesure de classer et de retrouver
leurs informations de manière efficace. Il est crucial que les bonnes personnes
puissent accéder aux bonnes informations, au bon moment, tout en réduisant
les coûts de l'administration des preuves électroniques et en limitant les risques.
La solution Hitachi Data Discovery Suite propose un tel service de recherche
électronique complète, d’un point de vue à la fois technique, probatoire et
réglementaire, avec la solution HCP, mais aussi avec la solution HNAS, les
serveurs Windows et d’autres plates-formes de services de fichiers.
Vues de l’interface de recherche HDDS.
La solution Hitachi Data Discovery Suite est une solution logicielle et matérielle.
Les principaux bénéfices de la mise en œuvre de la solution sont des capacités :
De recherches avancées et rapides sur des plates-formes multiples, dont
Hitachi Content Platform, et des volumes très importants. La notion de
volume à traiter est très importante, avez-vous remarqué le temps
d’attente d’une recherche sur l’ensemble vos données personnelles ? sans
doute plusieurs dizaines de minutes pour obtenir la bonne information
pertinente, ne serait-ce que dans le tri de l’éventuel résultat.
De rapports et de comptes rendus dynamiques sur l’état des informations
au niveau fichier, volume et nature des contenus.
D’intégration dans un environnement informatique, par la prise en charge
de serveurs de fichiers jusqu’au niveau utilisateur.
De migration et d’évaluation de migration de données entre les Tiers de
stockage.
D’audit sur des parties précises des données avec création de rapport en
accord avec les réglementations E-Discovery Américaine, qui n’ont certes
pas d’impact sur les réglementations Françaises, mais précise un niveau
fonctionnel avancé.
D’accès distant en mode graphique via une interface Web traditionnelle,
en mode Windows Gadget, pour le poste client, et en mode CLI pour une
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 :
s o l u t i o n s e t e x t e n s i o n s f o n c t i o n n e l l e s
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 41 France
intégration avec des outils externes et pour industrialiser certains
traitements métier et de gestion.
HITACHI CLINICAL REPOSITORY – SUPPORT DICOM, HL7 ET XDS ?
Pour les établissements de santé, Hitachi Data Systems propose une solution
verticale complète pour l’enregistrement de données médicales issues
d’environnement PACS (système d’archivage et de transmission d’image).
Hitachi Clinical Repository est une réponse au besoin de stockage neutre
principalement dédié au support de données DICOM (imagerie et
communication numériques en médecine), afin d’une part de faciliter le service
de gestion des volumes, mais surtout de proposer un support d’interopérabilité
et d’échange compatible avec tous les systèmes PACS du marché.
HCR supporte tous les types de données et en permet l’exploration neutre.
La solution HCR reçoit les informations DICOM, en extrait l’ensemble des
métadonnées (taille, dimensions, profondeur de couleur, modalité de création
des données, paramétrages des équipements, etc.), pour construire un
document XML. Le couple de l’image DICOM et des métadonnées extraites sont
ensuite enregistrées dans un Tenant du HCP. Grâce aux métadonnées, les
organismes de santé optimisent l'exploitation de leurs données brutes.
La solution Hitachi Clinical Repository se compose du système de stockage Objet
HCP, de l’application d’indexation Hitachi Data Discovery Suite et d’une
intégration logicielle spécifique à la reconnaissance des images DICOM, HL7 et
XDS, mais aussi à d’autres formats (PDF, XML, ZIP, MP3, CSV, MS Office, etc.).
HCR offre une infrastructure intégrée et normalisée, qui accepte tous les types
de données, indexe les métadonnées et assure l'interopérabilité de ces données
enrichies entre les applications externes.
Interface graphique Web de l’environnement clinicien de la solution HCR. Un clic sur une des vignettes pour agrandir l’image ou la visualisation vers un WADO pour l’affichage et
le parcours d’un film plus complet avec reconstruction 3D éventuelle.
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 :
s o l u t i o n s e t e x t e n s i o n s f o n c t i o n n e l l e s
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 42 France
Les données et les métadonnées sont indexées (plein texte) par la solution
Hitachi Data Discovery Suite (HDDS), afin de favoriser l’identification et la
récupération d’information indépendamment du système d’origine, et, ainsi,
favoriser une corrélation de données non cliniques (messagerie, facturation, …)
et cliniques (entrée, comptes rendus opératoires, prescription, etc.).
Avec Hitachi Clinical Repository, Hitachi Data Systems associe des technologies
de stockage et de gestion de l'information reconnues, à une expertise globale
en matière de gestion des données cliniques et de flux de travaux normalisés.
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 d m i n i s t r a t i o n e t s u p e r v i s i o n
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 43 France
ADMINISTRATION ET SUPERVISION
SUPERVISION DU STOCKAGE HCP PAR HI-TRACK
La solution HCP intègre la mise en œuvre d’une supervision distante des
composants internes par Hitachi. Il s’agit essentiellement d’actions proactives
sur la remontée de disfonctionnement liée à des seuils d’alertes. Ainsi, un
disque dur peut être changé avant sa panne réelle. Le logiciel Hi-Track est en
charge de remonter les informations vers Hitachi et l’entreprise pour tout ce qui
concerne les équipements matériels.
Hi-Track est développé et maintenu par Hitachi Data Systems. Il est connecté
directement sur les équipements Hitachi sur le site client. Il fournit, via un
accès Web, des informations sur les produits installés et permet de récupérer
des traces d’activités, d’analyser des erreurs, d’envoyer des alertes et, si
nécessaire, de créer directement un appel support. Hi-Track n’accède pas aux
données, mais uniquement aux informations internes de la plate-forme.
Principe de fonctionnement de l’outil Hi-Track.
Il est possible d’utiliser le mode SSL sur le SVP afin d’utiliser ce mode de
transport sécurisé. Les données sont alors encapsulées dans un tunnel SSL 128
bits qui permettra de sécuriser le transfert des informations. Hitachi Data
Systems a qualifié l’installation de SYMANTEC Corporate Edition pour la
protection antivirus des SVPs (PC d’administration des baies). Ce produit est
interfacé avec le logiciel de télésurveillance Hi-Track de manière à envoyer des
alertes au centre support.
COMMENT METTRE A JOUR LE SYSTEME INTERNE ?
Concernant la mise à jour du système d'exploitation HCP, celui-ci est enregistré
dans un espace disque spécifique. Sa mise à niveau n'implique pas la remise en
cause des données, de leurs métadonnées et des politiques de conservation. La
mise à niveau est réalisée à partir d'une connexion spécifique à la plate-forme
HCP en mode non graphique. Elle consiste à copier le contenu de la nouvelle
version sur un des serveurs HCP et à exécuter immédiatement, ou en différer,
le déploiement automatique de la mise à jour sur les autres serveurs du GRID
HCP.
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 d m i n i s t r a t i o n e t s u p e r v i s i o n
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 44 France
ADMINISTRATION DE LA PLATE-FORME
L’administration de la plate-forme HCP est réalisée via une interface Web en
accès HTTPs. Plusieurs niveaux d’administrateurs sont possibles via des rôles et
la gestion des comptes peut être externalisée via le protocole RADIUS38. Ces
différents niveaux proposent de superviser, contrôler et de configurer la
solution HCP. Une supervision par le protocole SNMP39 est aussi possible. Une
MIB 40 est d’ailleurs accessible en téléchargement depuis l’interface
d’administration.
LISTE DES PRINCIPAUX PORTS DE COMMUNICATION UTILISES DANS HCP
Port Type Direction Flux Fonction
7 UDP Entrant Internet Control Message Protocol (ICMP echo)
22 TCP Entrant Secure Shell Version 2 (SSH2)
25 TCP Entrant Simple Mail Transfer Protocol (SMTP)
53 TCP/UDP Entrant et Sortant Domain Name Service (DNS)
80 TCP Entrant Hypertext Transfer Protocol (HTTP)
88 TCP/UDP Entrant Kerberos (CIFS)
111 TCP/UDP Entrant Portmapper (RPC for NFS)
123 TCP/UDP Entrant et Sortant Network Time Protocol (NTP)
137 TCP/UDP Entrant NETBIOS Name Service (CIFS)
138 TCP/UDP Entrant NETBIOS Datagram Service (CIFS)
139 TCP/UDP Entrant NETBIOS Session Service (CIFS)
161 UDP Entrant Simple Network Management Protocol (SNMP)
162 UDP Sortant Simple Network Management Protocol (SNMP)
443 TCP Entrant Hypertext Transfer Protocol (HTTPS) over Secure Socket Layer (SSL)
445 TCP/UDP Entrant Common Internet File System (CIFS)
514 UDP Sortant System Log (Syslog)
2001 TCP Sortant Hitachi Device Manager (HDvM)
2049 TCP/UDP Entrant Network File System Protocol (NFS)
2050 TCP/UDP Entrant Mount Daemon (NFS)
2051 TCP/UDP Entrant Lock Daemon (NFS)
2052 TCP/UDP Entrant Stat Daemon (NFS)
5747 TCP Entrant HCP Replication
5748 TCP Entrant Secure HCP Replication (avec SSL)
8000 TCP Entrant HCP Administration (HTTPS)
8080 TCP Entrant Hypertext Transfer Protocol (HTTP)
8483 TCP Entrant Hypertext Transfer Protocol (HTTPS) over Secure Socket Layer (SSL)
8888 TCP Entrant HCP Web Search Interface (HTTPS)
10000 TCP Entrant Network Data Management Protocol (NDMP)
15100 TCP Entrant FAST Search Query (HTTP)
16000 TCP Entrant FAST Search Administration (HTTP)
16005 TCP Entrant FAST Search API
16089 TCP Entrant FAST Search User Administration (HTTP)
Configurable TCP Sortant RADIUS (User Authentication)
Dynamique TCP Sortant Active Directory (AD) Authentication
ADMINISTRATION DU STOCKAGE AU SEIN DU HCP
L’administration du stockage dédié et de son réseau SAN FC éventuel ne
nécessitent aucune administration directe. L’environnement HCP prend en
charge l’ensemble de la supervision et aucune manipulation particulière n’est à
réaliser, à l’exception d’un changement de composant, tel un disque dur, pour
une maintenance. Si l’environnement de stockage est partagé avec d’autres
applications, l’administration du stockage (baie AMS, HUS et USP) est alors à
assurer par l’entreprise. Il n’y a par contre aucune manipulation à réaliser sur
les zones de disques attribuées à la solution HCP.
38 Remote Authentication Dial In User Service. 39 Simple Network Management Protocol. 40 Management Information Base.
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 g r a m m a t i o n e t i n t é g r a t i o n a p p l i c a t i v e
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 45 France
PROGRAMMATION ET INTEGRATION APPLICATIVE
QUELLE CAPACITE DE DEVELOPPEMENT ET D’INTEGRATION LOGICIELLE ?
Le support natif du protocole http embarque aussi l’intégration des accès par
WebDAV, REST41 ou cURL42. Ainsi, en plus des protocoles CIFS et NFS pour un
accès direct en mode système de fichiers, il est très aisé d’utiliser les modes
d’accès Web pour dialoguer avec la solution HCP, afin d’assurer l’écriture
(Upload) et la lecture (Download) de tout type de document.
En exemple et pour illustrer la simplification et la facilité de développement sur
HCP, la librairie cURL est disponible dans le domaine public en ligne de
commande sur un très grand nombre de systèmes d’exploitation, mais aussi via
client REST et le langage PHP.
Via HTTP, le mode Web est privilégié, car il autorise des accès non dépendant
d’un réseau local et permet des niveaux de performance en accord avec
l’architecture Cloud réparti du HCP, par le traitement parallèle des flux entrants
et sortants, car tous les serveurs HCP sont disponibles et travaillent ensemble à
la répartition des charges et du stockage des documents. Plus le nombre de
serveurs HCP est important plus le nombre de traitement parallèle est possible,
tout en accédant à un seul espace de stockage consolidé.
INTEGRATION ET DEVELOPPEMENT LOGICIEL AVEC LA SOLUTION HCP
La solution de stockage objets HCP permet une intégration applicative avancée
au travers du protocole HTTPs 43 et de l’API REST 44 . Il est ainsi aisé de
développer un portail d’accès personnalisé pour opérer les principales actions
de lecture, écriture, suppression et autres définition de politique, telle que la
rétention.
Afin de faciliter le développement, il est recommandé d’utiliser la librairie Open
Source cURL 45 . La librairie propose une interface avancée de gestion du
protocole HTTP depuis diverses plates-formes et environnements de
développement.
Via le protocole HTTP et cURL, il est ainsi possible de développer une interface
utilisateur ou applicative à partir de tous les principaux systèmes d’exploitation
Windows, Linux, Unix et même Mainframe, sans compter des environnements
plus exotiques et supportés par la librairie cURL. Le choix du langage de
programmation est lui aussi ouvert et non dépendant du HCP. Le langage C et
Java sont les principaux exemples proposés dans la documentation HCP, mais
cURL propose un mode CLI46 favorisant la création de Scripts, si la création de
programme compilé est une contrainte.
Code Retour Label Description
201 Created Success
403 Forbidden Protocol disabled or Insufficient permissions
409 Conflict Object already exists
413 File Too Large Insufficient capacity
Exemples des codes retours dans le cadre de la requête PUT.
41 REpresentational State Transfer. 42 Client URL Request Library - fr.wikipedia.org/wiki/CURL 43
HTTP/1.1 Protocol Specification (IETF RFC 2068). 44 Plus de détails dans le document « Hitachi Content Platform Developer’s Guide : Building Open Applications on
the Hitachi Content Platform using the HCP REST API ». 45
Site officiel : http://curl.haxx.se/ 46
Si nécessaire, HCP propose aussi un mode CLI.
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 g r a m m a t i o n e t i n t é g r a t i o n a p p l i c a t i v e
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 46 France
Le développement HTTP est possible à la fois sur le Default Tenant et les Tenants
du HCP. Les codes retour pour la vérification des transactions sont ceux du
standard HTTP/1.1.
Explication d’un retour sur une requête PUT avec l’empreinte calculée (hash) par HCP.
Cette empreinte peut servir de contrôle d’intégrité, pour l’application source qui a connaissance de l’algorithme utilisé et paramétrable au niveau d’un Tenant.
L’utilisation des Tenants implique obligatoirement la connaissance de l’URL du
Namespace et une authentification d’accès, c’est-à-dire d’un Login et d’un
Password. Les autorisations d’accès sont définies au niveau d’un Tenant, elles
peuvent être de différents types et éventuellement associées à un annuaire47
d’entreprise.
Explication de l’utilisation de l’URL d’accès à un Namespace d’un Tenant pour envoyer un
fichier en positionnant une politique de gestion dans le cadre de la requête PUT.
QUELLE CAPACITE DE DEVELOPPEMENT SUR L’ADMINISTRATION DU HCP ?
Le protocole HTTP permet par un développement Web de gérer les principales
opérations sur les données. Ce protocole est aussi utilisé pour administrer en
externe les principales actions de gestion par programmation, des Tenants, des
Namespaces et des définitions de politique générale à la solution HCP, comme
la création de comptes d’accès et leurs rôles et permissions. A ce titre, Hitachi
met en œuvre une API dédiée et disponible depuis HCP v4.0.
Nommée HCP Management API, il s’agit d’une interface accessible par HTTP REST
intégrant donc des fonctions d’administration. Il convient de valider l’utilisation
de cette API, depuis l’interface Web du HCP, par un choix de fonctionnement
qui n’est pas autorisé par défaut. Il y a deux niveaux d’autorisation, une pour la
47
A partir de la v5 HCP, le contrôle des accès supporte les annuaires externes, tel qu’Active Directory.
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 g r a m m a t i o n e t i n t é g r a t i o n a p p l i c a t i v e
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 47 France
partie administration globale et une autre pour la partie administration des
Tenants. Chacune peut être activée indépendamment de l’autre ou
simultanément.
En résumé, les principales actions possibles sont :
Création, modification, suppression et récupération d’information sur le
Default Tenant, les Tenants et les Namespaces.
Création, modification, suppression et récupération d’information sur les
classes de rétention.
Création, modification, suppression et récupération d’information sur les
comptes d’accès.
La programmation consiste à manipuler des propriétés au sein de ressources, via
l’utilisation le support de XML et JSON48.
COMMENT REALISER DES RECHERCHES SUR LES METADONNEES ?
La première méthode consiste à utiliser la solution Hitachi Data Discovery Suite
qui propose une interface Web de recherche basée sur l’indexation des
métadonnées, comme des données. HDDS est aussi utilisable via HTTP en
programmation.
La seconde solution est basée sur l’utilisation de Metadata Query API, disponible
de base depuis HCP v4.0, et utilisable à travers l’interface HTTP REST. Cette
API permet de rechercher des objets enregistrés, supprimés ou purgés dans un
HCP, à partir de critères spécifiques. Les données gérées par une politique de
Versioning sont aussi accessibles et ainsi obtenir des informations sur les
données courantes, mais aussi sur les anciennes versions stockées. L’API
permet aussi de tracer les changements effectués dans les Namespace.
Pour utiliser l’API, il est nécessaire de valider l’autorisation de fonctionnement à
travers un compte qui possède le rôle de recherche (Search Role) et les
permissions associées (Search Permission). Seul les Namespace autorisant la
recherche sont accessibles par l’API. Cette permission est sous l’autorité du
Tenant propriétaire du Namespace.
Via la librairie cURL, il est aussi aisé d’accéder aux différentes informations et d’intégrer et
traiter des résultats à partir de scripts et d’une page PHP, dont le retour XML sera associé à un formulaire XSL pour un formatage dynamique et visuel à partir d’un
navigateur Web standard.
En résumé, les principales recherches possibles par Metadata Query API sont une
combinaison basée sur :
Le Namespace ;
48 JavaScript Object Notation.
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 g r a m m a t i o n e t i n t é g r a t i o n a p p l i c a t i v e
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 48 France
La date de modification ;
Le statut des objets (créé, supprimé ou purgé) ;
Le positionnement de l’index ;
Le répertoire.
La programmation consiste à manipuler des critères spécifiques et de traiter les
résultats, via les formats XML ou JSON.
COMMENT RECUPERER DES RAPPORTS EN VUE D’UNE FACTURATION ?
La solution HCP intègre de base une capacité de rapports, afin de réaliser des
procédures automatisée de facturation à l’utilisation (Chargeback). Il s’agit de
fournir des rapports de statistiques, à un intervalle de temps précis ou en
dynamique, sur l’usage de la solution HCP, en termes de nombre de
fichiers/objets, d’espace alloué, de bande passante consommée, etc. Par
exemple, le nombre cumulé de lecture-écriture sur un Namespace.
La récupération de rapports peut être réalisée via HCP Management API et ainsi
intégrer cette capacité dans un programme externe qui se chargera de générer
les facturations adaptées à l’entreprise et au client final. La programmation
consiste à traiter la réception de données au format XML, JSON ou CSV.
QUELLES SONT LES PRINCIPALES REQUETES HTTP SUPPORTEES PAR HCP ?
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 g r a m m a t i o n e t i n t é g r a t i o n a p p l i c a t i v e
Cloud, Archive & Partage © Hitachi Data Systems
Page n° 49 France
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 :
f o n c t i o n n e l s i n t é g r é s a u S t o c k a g e O b j e t H i t a c h i
Résumé Fonctionnel du Stockage Objet © Hitachi Data Systems
Page n° 50 France
FONCTIONNELS INTEGRES AU STOCKAGE OBJET-CLOUD HITACHI
INTEGRITE
Calculs/vérification d’empreinte Calcul d'une empreinte au choix : SHA, RIP, MD5. Vérification continue et à chaque consultation.
Horodatage Lien avec au moins un Serveur NTP. Insertion dans les métadonnées.
Sécurisation interne des données Surveillance de non substitution de la donnée.
Réplica de données (DPL) et de métadonnées (MDPL).
Signature des données et des métadonnées.
Traces des actions Toutes les opérations sont tracées via Syslog. Une MIB SNMP permet aussi la collecte de Logs.
CONFIDENTIALITE
Authentification de l’utilisateur et/ou de
l’application
Authentification des accès via des liens SSL.
Autorisation IP, accès contrôlés via AD/ LDAP.
Séparation d’accès aux données et de
l’administration
Cloisonnement fort entre l'administrateur de la plate-forme et les propriétaires des données.
Segmentation applicative des espaces
de données
Utilisation du concept de Tenant, afin de segmenter les espaces logiques et aussi les accès.
PERENNITE
Evolution de volumes et de puissance Volume jusqu’à 80Po. Dépôt jusqu’à 64 milliards de fichiers.
Puissance jusqu’à 160 unités centrales49.
Mise à jour des versions logicielles Planification automatique de déploiement des évolutions à partir d’une unité centrale.
Intégration de nouvelles technologies Par ajout de nouveaux serveurs ou de capacité volume (baie de stockage et/ou disque).
Cohabitation de technologies anciennes
et récentes dans une même plateforme
Capacité de mixer différentes générations d’unités centrales et de stockage.
Migration des données vers et depuis la
plate-forme
HCP Data Migrator : logiciel compris, en mode CLI et GUI, de transfert/migration de données et
métadonnées depuis, vers et entre HCP.
49
Serveur ou Blade Hitachi.
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 :
f o n c t i o n n e l s i n t é g r é s a u S t o c k a g e O b j e t H i t a c h i
Résumé Fonctionnel du Stockage Objet © Hitachi Data Systems
Page n° 51 France
DISPONIBILITE
Réplication des données Transfert sélectif, asynchrone et multi directionnel via IP des données avec liens SSL.
Migration de données HCP Data Migrator50 : GUI et mode CLI.
Disponibilité de la solution Le SLA est de 99,999%
Redondance des éléments matériels Tous les composants matériels sont redondés ainsi que les chemins d’accès internes et externes.
Régénération des données Fonction automatisée via DPL ou réplication.
Monitoring GUI, MIB SNMP, Syslog, Hitachi HiTrack et HCP Management API.
ACCESSIBILITE
Ecriture NFS, CIFS, FTP, HTTPs (RESTful), WebDAV, cURL, HS351, SMTP, DICOM52, HL7, XDS et XDSi.
Lecture NFS, CIFS, FTP, HTTPs (RESTful), WebDAV, cURL, HS3, NDMP53, DICOM, HL7, XDS et XDSi.
Administration HTTPs, SNMP, RADIUS et HCP Management API.
Indexation et Recherche – interne54 Metadata Query Engine via HTTPs.
Indexation et Recherche – externe55 CIFS, NFS & HTTPs.
50
Disponible de base pour la copie à la demande ou programmée de données et métadonnées, entre un système de fichiers et un Tenant/Namespace HCP. 51 Compatible avec Amazon S3. 52 Uniquement avec la gamme Hitachi Clinical Repository, idem pour HL7 et XDSi. 53 Uniquement pour le Default Tenant. 54
Livré de base dans le HCP, mais uniquement sur les métadonnées. 55 Indexation via Hitachi Data Discovery Suite ou autres solutions du marché.
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 :
f o n c t i o n n e l s i n t é g r é s a u S t o c k a g e O b j e t H i t a c h i
Résumé Fonctionnel du Stockage Objet © Hitachi Data Systems
Page n° 52 France
REGLEMENTATION56
Conformité Française Conforme aux recommandations de la CNIL sur la conservation WORM.
Conforme à la norme NF Z42-013 :200957. WORM logique, HCP est classifié par la norme dans la
catégorie support réinscriptible. Cette classification impose que le système intègre un mécanisme
d’empreinte électronique propre :
Shredding.
Traçabilité-Logs.
Sécurisation.
Empreinte.
Conforme à la norme NF Z42-02058.
Conformité internationale ISO 14641-1 :2012 : version ISO de la NF Z42-013.
ISO 8601 : formalisation pour les dates.
ISO 9660 : Portable Operating System Interface (POSIX).
ISO 14721 : modèle Open Archival Information Systems.
ISO/TR 15801 : Electronic Imaging.
ISO 27001 : contribution à la confidentialité, c’est-à-dire que l’information est accessible
uniquement par ceux dont l’accès est autorisé.
Autres règlementations US DoD 5520-M : Shredding
SEC 17a-4 : validation, intégrité, vérification, qualité, disponibilité et audit
Sarbanes-Oxley, OSHA, HIPAA, FRCP, DISC PD0008, NASD 2210/3210, …
56 Hitachi Content Platform a été évalué en octobre 2006 par les services du cabinet international Kahn Consulting, Inc. Dans le cadre d’un projet national, la solution a aussi
été évaluée en 2009 par les cabinets Alain Bensoussan et Serda Groupe. 57 www.afnor.org 58 Prêt à contribuer à un projet SAE de certification de la chaine pour la conservation de valeur : la certification NF 461nécessite une audition externe à HDS.
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 :
h i s t o r i q u e d e s v e r s i o n s H C P
Résumé Fonctionnel du Stockage Objet © Hitachi Data Systems
Page n° 53 France
HISTORIQUE DES VERSIONS DE LA SOLUTION HCP59
Janvier 2006 : v1.6 Octobre 2006 : v1.8
Première solution construite à partir de serveurs 2U et de stockage WMS100 en attachement Fibre directe sur
chaque contrôleur, soit un serveur par contrôleur.
Système HCA installé sur des disques en RAID-1 internes aux serveurs.
Début de l’architecture SAIN.
Intégration du modèle OAIS.
Utilisation du Linux Fedora Core 4 en Ext3.
Système HCA installé directement sur le stockage de la baie HDS (boot on SAN) : premier alignement en
architecture SAIN et intégration d’un niveau de protection par réplica.
Amélioration de la gestion de protocole et accélération des performances CIFS et du support http en multi accès.
Intégration complète du moteur de recherche et d’indexation du contenu (OEM de FAST).
Amélioration des politiques de rétention et des privilèges de suppression.
Capacité d’audit et d’interrogation sur les objets archives (requête).
Ajout de la fonction de Shredding
Evolutivité étendue à 2 milliards d’objets et plus de 1Po de stockage.
Janvier 2007 : v2.0
Mars 2008 : v2.6
Premier niveau de réplication des objets vers un second HCP, en mode commande et unidirectionnel.
Support de la sauvegarde NDMP
Utilisation du Linux Fedora Core 6 et MPIO pour le Multipathing FC.
Amélioration du support du SAN FC et intégration des outils et des métriques HDS HiCommand.
Qualification de l’ensemble des baies de stockage HDS : WMS, AMS, NSC et USP. Volume en RAID 6.
Qualification de la baie de stockage AMS2x00.
Administration multi niveaux et support Radius.
Modèles HCP 500 et HCP 300 et intégration d’une première architecture RAIN.
Personnalisation métier des métadonnées.
Intégration d’une administration graphique de la réplication bidirectionnelle des objets HCP.
Première brique de migration des objets HCP à partir d’une solution non HDS : prestation de service.
Support de la norme Sec 17a-4 avec l’encodage (AES 256 bits) complet du HCP, index compris.
59 Les informations citées ne prennent pas en compte les supports ISV à l’exception d’intégration bien spécifique et éventuellement disponible au catalogue HDS.
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 :
h i s t o r i q u e d e s v e r s i o n s H C P
Résumé Fonctionnel du Stockage Objet © Hitachi Data Systems
Page n° 54 France
Historique des Versions de la solution HCP – suite
Janvier 2009 : v2.8 Mai 2010 : v3.1
Fonction Single Instance (déduplication) pour diminuer et optimiser l’espace de stockage.
Evolutivité étendue jusqu’à 32 milliards d’objets et 40Po de stockage.
Compression ciblées des données.
Migration automatique à partir de la solution Hitachi HNAS.
Certification officielle SAP NetWeaver via WebDAV.
Module HCP pour Microsoft SharePoint : HDD-MS.
Evolution de la solution d’indexation vers le produit HDDaa.
Solution Hitachi HealthXchange.
Intégration du Cloud Storage et du mode SSP.
Support du Versioning et de la suppression par privilège.
Gestion de Namespaces via HTTPs
Deux modes génériques de classification : Enterprise et Compliant.
Indexation sélective des fichiers.
Amélioration du rôle Compliant
Support du HCP par TSM/SSAM comme destination de stockage WORM.
Ajout de capacité graphique de désignation de Classes de rétention.
Gestion de quota et suivi de consommation.
Nouvelle interface graphique Web.
Nouvelles capacités de Chargeback pour la facturation.
Support de Hitachi Dynamic Provisioning.
Octobre 2010 : v4.0 Avril 2011 : v4.1
Disponibilité de la solution Hitachi Data Ingestor pour les architectures Remote Office Branch Office.
Réplication en architecture multiples : Star & Chain (Cascade).
Contrôle de la réplication par Namespace et lecture automatique d’un objet répliqué en cas d’altération du source.
Data Protection Level dynamique.
Support de la compression au sein du requête HTTPs.
Nouvelle API, via HTTPs, dédiée à l’administration : Management API.
Amélioration du module de Chargeback.
Configuration par défaut d’un HCP 300 en version DPL-1 en cas de réplication.
Nouvelle solution logicielle embarquée : HCP Data Migrator.
Intégration des serveurs Hitachi CR220 et des serveurs Blade 320 Hitachi.
Officialisation de l’externalisation de la solution d’indexation par Hitachi Data Discovery Suite.
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 :
h i s t o r i q u e d e s v e r s i o n s H C P
Résumé Fonctionnel du Stockage Objet © Hitachi Data Systems
Page n° 55 France
Historique des Versions de la solution HCP – suite
Septembre à décembre 2011
Intégration de la réplication sur Librairie de Bandes ou VTL, via la solution StorFirst Apollo.
Nouvelle solution HCP 500 XL : solution dédiée haute capacité et haute performance.
Nouvelle version 3-0 d’Hitachi Data Ingestor :
o Capacité d’accès aux autres volumes HDI (Tenant/Namespace) en mode lecture.
o Facilité pour les utilisateurs de restauration des fichiers supprimés et versions précédentes.
o Fonctionnalité de migration automatique et transparente depuis d’autres NAS et serveurs Windows.
Avril 2012 : v5.0
Augmentation du nombre de Tenant (1°000) et Namespaces(10°000).
Fortes améliorations des interfaces graphiques.
Moniteur graphique de performance et gestion du Failover.
Ajout en interne d’un moteur d’indexation sur les métadonnées uniquement accessible via API HTTPs – ne
remplace pas l’indexation des contenus via HDDS.
Intégration d’une classe de stockage sur disque en mode Spin-down (réduction de la consommation électrique).
Extension des supports CIFS, NFS SMTP et WebDAV aux Namespaces.
Ajout d’une authentification par Object ACLs (Access Control Lists) – orientation Cloud Storage.
Support Active Directory (Utilisateurs et Groupes) au niveau des accès aux Tenants/Namespaces.
Définition d’alertes par Email.
Amélioration du Failover entres HCP.
Nouvelle image VMware HCP pour les PoC : Single Node pour VMware Player et Multi Nodes pour VMware ESXi.
Nouvelle prestation de service HDS pour l’audit et l’analyse de données orientée Fichier – plan d’action avec
engagement ROI et SLA.
Support des baies Hitachi Unified Storage (HUS)
Nouvelle version 3-1 Hitachi Data Ingestor :
o Amélioration des performances.
o Simplification du déploiement de la version VMware en mode HA.
Décembre 2012
Intégration des serveurs Hitachi Compute Rack 210 : plus de performance CPU, plus de mémoire centrale, moins
d’espace (1U) et moins de consommation électrique.
Support des stockages Hitachi Unified Storage Virtual Modular (HUS-VM).
Nouvelle version Hitachi Data Ingestor v3.2 : augmentation des capacités de cache et plus de performance.
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 :
h i s t o r i q u e d e s v e r s i o n s H C P
Résumé Fonctionnel du Stockage Objet © Hitachi Data Systems
Page n° 56 France
Historique des Versions de la solution HCP – suite
Mars 2013 : v6.0
Nouveau serveur CR210H 1U Hitachi pour HCP 500 : ports 10GbE, agrégation de ports, nouvelle CPU, …
Nouveau serveur CR220S 2U Hitachi pour HCP 300 : jusqu’à 12 disques internes.
Support VLAN et Ipv6.
HS3 : intégration du pseudo-langage Amazon S3 via HTTPs.
Capacité d’un tiers de stockage externe vers un lien NFS :
o NAS externe Hitachi ou non Hitachi.
o NAS de déduplication Hitachi ou non Hitachi.
o Prêt pour du Tiers vers de la Bande via des applications partenaires : Qstar, CrossRoad, Active Circle.
Déclinaison d’une offre de production nommée HCP VM, pour VMware en plus des HCP 300, 500 et 500XL.
Extension de gestion des métadonnées : multi métadonnées
Evolutivité étendue jusqu’à 64 milliards de fichiers.
HCP Géo Dispersion : conservation sur des sites distants HCP des métadonnées sans les données.
Diverses améliorations fonctionnelles pour assurer des performances accrues dans les flux de lecture/écriture.
Juin 2013
Première version de la solution HCP AnyWhere, afin d’adresser les équipements nomades (tablette, smartphone,
ordinateur, Web) pour la synchronisation et le partage de fichiers.
Nouvelle version Hitachi Data Ingestor v4 :
o Nouvelle solution matérielle : Cluster DiskLess.
o Augmentation des supports clients, tel que MacOS.
o Encryption locale des données : Data At Rest Encryption (DARE).
o Partage de fichiers RW pour les utilisateurs nomades : Roaming Home Directories (RHD).
o Diverses améliorations : CIFS Access Logs, performance de migration, suppression asynchrone, …
Juillet 2014 : v7.0
Global Name Space : environnement actif/actif multi sites sur un même espace de dépôt.
Nouveaux tiers externes vers : Amazon, Azure et Google.
Nouvelles plates-formes matérielles Hitachi :
o 32Go de mémoire interne
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
Siège Social France, 2-6 Place Charles de Gaulle, 92160 Antony – France : +33 1 46 10 14 00 www.hds.com/fr
Hitachi est une marque déposée d’Hitachi, Ltd. et/ou de ses filiales aux Etats-Unis et dans d’autres pays. Hitachi Data Systems est une marque déposée et une marque de service d’Hitachi, Ltd., aux Etats-Unis et dans d’autres pays.
Toutes les autres marques déposées, marques de service et noms de sociétés sont la propriété légitime de leurs fabricants respectifs.
Avertissement : Le présent document est à caractère informatif uniquement et ne stipule aucune garantie, expresse ou implicite, sur aucun équipement ou service offert par ou devant être offert par Hitachi Data Systems. Il décrit des possibilités conditionnées par un contrat de maintenance conclu avec Hitachi Data Systems, effectif à ce jour, et pouvant dépendre d’une configuration spécifique, et des caractéristiques pouvant ne pas être disponibles à ce jour. Pour plus d’informations concernant les caractéristiques et la disponibilité du produit, contactez votre agence commerciale locale Hitachi Data Systems.
Les produits vendus ou licences octroyées par la société Hitachi Data Systems sont sujets à des conditions générales contenant des garanties limitées.
Pour consulter ces conditions générales avant d'acheter un produit ou demander une licence, rendez-vous à l'adresse http://www.hds.com/corporate/legal/index.html ou contactez votre représentant commercial local par téléphone pour en obtenir un imprimé. En achetant un produit ou une licence de produit, vous acceptez implicitement ces conditions générales.
© Hitachi Data Systems Corporation 2014. Tous droits réservés. [email protected]
Hitachi Cloud Platform © Hitachi Data Systems
Page n° 57 France
À PROPOS D’HITACHI DATA SYSTEMS
Hitachi Data Systems fournit des technologies, services et solutions informatiques
de pointe assurant un ROI et un retour sans précédent sur les ressources
informatiques des clients, qui peuvent mesurer l’impact sur leurs activités.
Considérant que les technologies de l’information doivent être virtualisées,
automatisées, adaptées au Cloud et pérennes, Hitachi Data Systems propose
des solutions qui améliorent l’agilité et réduisent les coûts IT. Comptant plus de
5 800 collaborateurs dans le monde, Hitachi Data Systems est présent dans
plus de 100 pays et régions. Les plus grandes entreprises mondiales, dont plus
de 70% des Fortune 100 et plus de 80% des Fortune Global 100, font confiance
aux produits, services et solutions d’Hitachi Data Systems. Pour Hitachi Data
Systems, les données dirigent le monde et l’information est la nouvelle valeur.
Pour en savoir plus, rendez-vous sur http://www.hds.com/fr
À PROPOS D’HITACHI LTD.
Basé à Tokyo au Japon, Hitachi, Ltd. (TSE : 6501) emploie environ 3260.000
personnes dans le monde et est l’un des leaders mondiaux du marché de
l’électronique. Son chiffre d’affaires consolidé s’est élevé à 9.665 Md de Yens
(117.8 Md de Dollars) au cours de l’exercice 2011 (arrêté au 31 mars 2012).
L’entreprise se concentre plus que jamais sur les activités porteuses
d’innovation pour la société, dont les systèmes d’information et de
télécommunication, les systèmes d’alimentation électrique, les systèmes de
transport, industriels et environnementaux, les systèmes d’aménagement
urbain et social, les équipements de pointe et les périphériques associés. Pour
tout renseignement complémentaire sur Hitachi : http://www.hitachi.fr