Transcript
Page 1: Foire Aux Questions sur Hitachi Content Platform

© Hitachi Data Systems - France 16 septembre 2014. version 1.20

[email protected]

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

Page 2: Foire Aux Questions sur Hitachi Content Platform

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

Page 3: Foire Aux Questions sur Hitachi Content Platform

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

Page 4: Foire Aux Questions sur Hitachi Content Platform

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.

Page 5: Foire Aux Questions sur Hitachi Content Platform

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.

Page 6: Foire Aux Questions sur Hitachi Content Platform

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

Page 7: Foire Aux Questions sur Hitachi Content Platform

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

Page 8: Foire Aux Questions sur Hitachi Content Platform

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.

Page 9: Foire Aux Questions sur Hitachi Content Platform

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.

Page 10: Foire Aux Questions sur Hitachi Content Platform

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.

Page 11: Foire Aux Questions sur Hitachi Content Platform

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.

Page 12: Foire Aux Questions sur Hitachi Content Platform

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.

Page 13: Foire Aux Questions sur Hitachi Content Platform

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.

Page 14: Foire Aux Questions sur Hitachi Content Platform

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.

Page 15: Foire Aux Questions sur Hitachi Content Platform

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

Page 16: Foire Aux Questions sur Hitachi Content Platform

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.

Page 17: Foire Aux Questions sur Hitachi Content Platform

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

Page 18: Foire Aux Questions sur Hitachi Content Platform

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

Page 19: Foire Aux Questions sur Hitachi Content Platform

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.

Page 20: Foire Aux Questions sur Hitachi Content Platform

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é

Page 21: Foire Aux Questions sur Hitachi Content Platform

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.

Page 22: Foire Aux Questions sur Hitachi Content Platform

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.

Page 23: Foire Aux Questions sur Hitachi Content Platform

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.

Page 24: Foire Aux Questions sur Hitachi Content Platform

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

Page 25: Foire Aux Questions sur Hitachi Content Platform

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

Page 26: Foire Aux Questions sur Hitachi Content Platform

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.

Page 27: Foire Aux Questions sur Hitachi Content Platform

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.

Page 28: Foire Aux Questions sur Hitachi Content Platform

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

Page 29: Foire Aux Questions sur Hitachi Content Platform

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.

Page 30: Foire Aux Questions sur Hitachi Content Platform

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.

Page 31: Foire Aux Questions sur Hitachi Content Platform

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

Page 32: Foire Aux Questions sur Hitachi Content Platform

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.

Page 33: Foire Aux Questions sur Hitachi Content Platform

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

Page 34: Foire Aux Questions sur Hitachi Content Platform

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

Page 35: Foire Aux Questions sur Hitachi Content Platform

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

Page 36: Foire Aux Questions sur Hitachi Content Platform

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.

Page 37: Foire Aux Questions sur Hitachi Content Platform

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.

Page 38: Foire Aux Questions sur Hitachi Content Platform

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.

Page 39: Foire Aux Questions sur Hitachi Content Platform

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

Page 40: Foire Aux Questions sur Hitachi Content Platform

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.

Page 41: Foire Aux Questions sur Hitachi Content Platform

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

Page 42: Foire Aux Questions sur Hitachi Content Platform

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.

Page 43: Foire Aux Questions sur Hitachi Content Platform

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.

Page 44: Foire Aux Questions sur Hitachi Content Platform

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

Page 45: Foire Aux Questions sur Hitachi Content Platform

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.

Page 46: Foire Aux Questions sur Hitachi Content Platform

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.

Page 47: Foire Aux Questions sur Hitachi Content Platform

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.

Page 48: Foire Aux Questions sur Hitachi Content Platform

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.

Page 49: Foire Aux Questions sur Hitachi Content Platform

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.

Page 50: Foire Aux Questions sur Hitachi Content Platform

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.

Page 51: Foire Aux Questions sur Hitachi Content Platform

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.

Page 52: Foire Aux Questions sur Hitachi Content Platform

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 ?

Page 53: Foire Aux Questions sur Hitachi Content Platform

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

Page 54: Foire Aux Questions sur Hitachi Content Platform

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.

Page 55: Foire Aux Questions sur Hitachi Content Platform

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

Page 56: Foire Aux Questions sur Hitachi Content Platform

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.

Page 57: Foire Aux Questions sur Hitachi Content Platform

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.

Page 58: Foire Aux Questions sur Hitachi Content Platform

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.

Page 59: Foire Aux Questions sur Hitachi Content Platform

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.

Page 60: Foire Aux Questions sur Hitachi Content Platform

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

Page 61: Foire Aux Questions sur Hitachi Content Platform

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