EMC Elastic Cloud Storage (ECS) 2.0 Documentazione ECS

Transcription

EMC Elastic Cloud Storage (ECS)
Versione 2.0
Documentazione ECS
302-001-980
01
Copyright © 2013-2015 EMC Corporation. Tutti i diritti riservati.
Pubblicato Giugno, 2015
EMC ritiene che le informazioni contenute nel presente documento sono esatte alla data di pubblicazione. Le informazioni
sono soggette a modifica senza preavviso.
LE INFORMAZIONI CONTENUTE NEL PRESENTE DOCUMENTO VENGONO FORNITE "COSÌ COME SONO". EMC CORPORATION NON
FORNISCE ALCUNA DICHIARAZIONE O GARANZIA IN RELAZIONE ALLE INFORMAZIONI CONTENUTE NELLA PRESENTE
PUBBLICAZIONE, IN MODO SPECIFICO PER QUANTO ATTIENE ALLE GARANZIE DI COMMERCIABILITÀ O IDONEITÀ PER UNO SCOPO
SPECIFICO.
EMC², EMC, e il logo EMC sono marchi o marchi registrati di EMC Corporation negli Stati Uniti e in altri paesi. Tutti gli altri
marchi citati nel presente documento sono di proprietà dei rispettivi titolari.
Per la versione più aggiornata della documentazione normativa per la vostra linea di prodotti, consultare il Supporto Online
EMC (https://support.emc.com).
EMC Computer Systems Italia S.p.A.
Direzione e Filiale di Milano Via Giovanni Spadolini, 5 - Edificio A 20141 Milano
tel. +39 02 409081 fax +39 02 48204686
http://italy.emc.com
2
SOMMARIO
Parte 1
Novità
11
Capitolo 1
Nuove funzionalità in ECS 2.0
13
Nuove funzionalità........................................................................................ 14
Parte 2
Concetti
17
Capitolo 2
Cos'è ECS?
19
Panoramica...................................................................................................20
Piattaforma ECS............................................................................................ 20
Servizi del portale............................................................................ 20
Servizi di storage .............................................................................21
Servizio di provisioning....................................................................21
Servizio della fabric..........................................................................21
Servizio di infrastruttura...................................................................21
Capitolo 3
Informazioni sulla protezione dei dati
23
Panoramica...................................................................................................24
Servizio di storage.........................................................................................24
Creazioni di object........................................................................................ 24
Letture di object............................................................................................ 27
Codici di cancellazione..................................................................................28
Ripristino in caso di guasti di dischi e nodi....................................................29
Failover e ripristino del sito........................................................................... 30
Parte 3
Installazione e aggiornamento
31
Capitolo 4
Pianificazione di un'installazione
33
Panoramica...................................................................................................34
Preparazione dell'area di installazione..........................................................34
ECS - Checklist dell'idoneità dell'installazione.............................................. 34
Connessione di appliance ECS in un unico sito .............................................34
Requisiti multisito......................................................................................... 36
Parte 4
Configurazione e gestione
37
Capitolo 5
Guida introduttiva al portale ECS
39
Introduzione..................................................................................................40
Login al portale ECS...................................................................................... 40
Modifica password........................................................................................41
Accesso alle aree del portale.........................................................................41
Ordinamento e ricerche nelle tabelle del portale........................................... 44
3
SOMMARIO
Capitolo 6
Configurazione di storage pool, VDC e gruppi di replica
47
Configurazione di storage pool, VDC e gruppi di replica.................................48
Storage pool................................................................................................. 48
Creare storage pool.......................................................................... 49
Data center virtuali (VDC).............................................................................. 49
Creare un VDC per un singolo sito.................................................... 50
Aggiungere un VDC a una federazione.............................................. 51
Eseguire il failover di un sito/eliminare un VDC................................ 51
Gruppi di replica........................................................................................... 52
Creare gruppi di replica.................................................................... 53
Configurazione di ConnectEMC......................................................................53
Capitolo 7
Aggiunta di utenti e assegnazione di ruoli
55
Introduzione..................................................................................................56
Informazioni su utenti e ruoli in ECS.............................................................. 56
Utenti in ECS.................................................................................... 56
Ruoli utente..................................................................................... 58
Utenti locali e di dominio................................................................. 58
Ambito utente: globale o namespace............................................... 59
Attività con gli utenti nel portale ECS............................................................. 60
Aggiungere un nuovo utente di object.............................................. 62
Aggiungere un utente di dominio come utente di object................... 63
Creare un utente di gestione locale o assegnare un utente di dominio
a un ruolo di gestione...................................................................... 64
Creare un amministratore di namespace.......................................... 65
Attività con i provider di autenticazione nel portale ECS................................ 65
Aggiungere un provider di autenticazione........................................ 66
Impostazioni del provider di autenticazione..................................... 67
Considerazioni durante l'aggiunta dei provider di autenticazione.....71
Caratteristiche principali del mapping degli utenti a un namespace.............. 72
Mapping di utenti di dominio a un namespace.................................73
Capitolo 8
Configurazione di un namespace per un tenant
75
Introduzione..................................................................................................76
Informazioni sui tenant................................................................................. 76
Informazioni sulle impostazioni dei namespace............................................ 77
Attività con i namespace nel portale ECS....................................................... 78
Creazione e configurazione di un namespace................................................ 78
Capitolo 9
Acquisizione e caricamento di un file di licenza nel portale ECS
81
Licenze..........................................................................................................82
Acquisizione del file di licenza di EMC ECS.................................................... 82
Capitolo 10
Gestione di un tenant
83
Introduzione..................................................................................................84
Quote............................................................................................................84
Periodi e policy di conservazione.................................................................. 85
Blocco di bucket e utenti............................................................................... 86
Misurazione.................................................................................................. 87
Audit di bucket..............................................................................................89
4
SOMMARIO
Capitolo 11
Failover di un sito ECS
91
Eseguire il failover di un sito/eliminare un VDC............................................. 92
Parte 5
Monitor
93
Capitolo 12
Monitoraggio di risorse: hardware, traffico di rete, larghezza di banda
del disco, integrità di nodi e processi
95
Informazioni sul monitoraggio delle risorse................................................... 96
Utilizzo di pagine di monitoraggio................................................................. 96
Monitoraggio hardware................................................................................. 98
Monitoraggio del traffico di rete.................................................................... 99
Monitoraggio della larghezza di banda del disco.........................................101
Monitoraggio dell'integrità di nodi e processi..............................................102
Capitolo 13
Monitoraggio dello storage: misurazione e capacità
105
Introduzione............................................................................................... 106
Utilizzo di pagine di monitoraggio............................................................... 106
Monitoraggio della capacità........................................................................ 108
Dati di capacità di storage..............................................................108
Monitoraggio dei dati di misurazione.......................................................... 111
Dati di misurazione........................................................................ 111
Capitolo 14
Monitoraggio dei log di servizio
113
Log di servizio............................................................................................. 114
ECS - Posizioni dei log di servizio................................................................ 114
Capitolo 15
Monitoraggio dei servizi: blocchi, codici di cancellazione, replica
geografica e stato di ripristino
115
Informazioni sul monitoraggio dei servizi.................................................... 116
Utilizzo di pagine di monitoraggio............................................................... 116
Monitoraggio di blocchi...............................................................................118
Monitoraggio dei codici di cancellazione.....................................................120
Monitoraggio dello stato di ripristino...........................................................121
Monitoraggio della replica geografica: tassi e blocchi..................................122
Monitoraggio della replica geografica: RPO (Recovery Point Objective)........ 123
Monitoraggio della replica geografica: failover............................................ 124
Monitoraggio della replica geografica: elaborazione di bootstrap................125
Capitolo 16
Monitoraggio degli eventi: portale di audit, API, alert di sistema ed
eventi CLI
127
Informazioni sul monitoraggio degli eventi.................................................. 128
Filtraggio di eventi per data e ordinamento dei risultati per colonna............ 128
Parte 6
Abilitazione dell'accesso ai dati
131
Capitolo 17
Indirizzamento di object storage ECS e utilizzo dell'URL di base
133
Introduzione............................................................................................... 134
5
SOMMARIO
Indirizzamento bucket.................................................................................134
Configurazione DNS....................................................................... 135
URL di base....................................................................................135
Aggiunta di un URL di base..........................................................................137
Esempio di URL di base..................................................................138
Capitolo 18
Creazione e configurazione di bucket
139
Introduzione............................................................................................... 140
Concetti e attributi dei bucket..................................................................... 140
ACL di bucket.............................................................................................. 143
Creare un bucket mediante il portale ECS.................................................... 144
Modifica di un bucket..................................................................................145
Impostazione delle autorizzazioni ACL dei bucket per un utente..................146
Impostazione delle autorizzazioni ACL dei bucket per un gruppo predefinito
................................................................................................................... 147
Creare bucket utilizzando le API basate su object........................................147
Creazione di un bucket attraverso l'utilizzo di API S3 (con s3curl).. 148
Convenzioni di denominazione per bucket e chiavi..................................... 151
Denominazione di bucket e object S3 in ECS..................................151
Denominazione di container e object OpenStack Swift in ECS........ 152
Denominazione di bucket e object Atmos in ECS............................ 152
Denominazione di pool e object CAS in ECS................................... 152
Capitolo 19
Ricezione di una chiave segreta per l'accesso all'object storage
155
Introduzione............................................................................................... 156
Creazione di una chiave per un utente di object.......................................... 156
Generare una chiave segreta dal portale ECS..................................156
Creare una chiave segreta S3 mediante ECS Management REST API
...................................................................................................... 156
Creazione di una chiave segreta S3: SELF-SERVICE...................................... 157
Utilizzo di chiavi self-service.......................................................... 157
Capitolo 20
Configurazione del supporto per applicazioni CAS SDK con il portale
ECS
161
Configurazione del supporto CAS in ECS......................................................162
Conservazione CAS in ECS...........................................................................162
Configurazione di policy di conservazione dei namespace.......................... 164
Configurazione di un bucket per CAS...........................................................165
Configurazione di un utente di object CAS................................................... 166
Configurazione di ACL di bucket per un utente.............................................167
ECS REST API che supportano utenti CAS.....................................................169
Parte 7
Configurazione di ECS HDFS
171
Capitolo 21
Panoramica di HDFS
173
Cos'è HDFS?................................................................................................ 174
Configurazione di Hadoop per l'utilizzo di ECS HDFS ..................... 175
ECS - URI HDFS per l'accesso al file system.....................................175
Hadoop - Modalità di autenticazione..............................................176
Interazione con il file system..........................................................179
Applicazioni di Hadoop non supportate......................................... 179
6
SOMMARIO
Capitolo 22
Configurazione di HDFS in un cluster Hadoop non sicuro
181
Configurazione di ECS HDFS........................................................................ 182
Pianificare l'integrazione di ECS HDFS e Hadoop............................ 182
Ottenimento del pacchetto di installazione e supporto di ECS HDFS
...................................................................................................... 183
Creazione di un bucket per HDFS....................................................183
Implementare il file JAR ECS HDFS.................................................. 184
Utilizzo di un parcel Cloudera per installare Hadoop in un cluster ..185
Modificare il file core-site.xml di Hadoop....................................... 186
Modificare hbase-site.xml HBASE.................................................. 190
Capitolo 23
Configurazione di HDFS in un cluster Hadoop sicuro
193
Configurazione del cluster Hadoop sicuro per l'utilizzo di ECS HDFS ........... 194
Pianificare l'integrazione di ECS HDFS e del cluster Hadoop sicuro.194
...................................................................................................... 195
Creazione di un bucket per HDFS sicuro......................................... 195
Implementazione del file JAR ECS HDFS in un cluster sicuro............196
Utilizzo di un parcel Cloudera per installare Hadoop in un cluster
sicuro.............................................................................................197
Configurare i nodi di ECS con l'entità del servizio ECS.................... 198
Modificare core-site.xml.................................................................201
Indicazioni sulla configurazione di Kerberos.................................. 204
ECS - Riferimento dello strumento di amministrazione................... 207
Capitolo 24
Risoluzione dei problemi di una configurazione ECS HDFS
209
Risoluzione dei problemi.............................................................................210
Verificare la corretta configurazione di AD/LDAP con cluster Hadoop
sicuro.............................................................................................210
Autorizzazione negata per un utente AD......................................... 211
Riavvio di servizi in seguito alla configurazione hbase................... 211
Esito negativo del test Pig: impossibile ottenere l'entità Kerberos.. 211
Abilitare il logging Kerberos lato client........................................... 211
Debug di Kerberos sul server KDC...................................................211
Eliminare il disallineamento dei clock............................................ 212
Capitolo 25
Riferimento delle proprietà del sito core di ECS HDFS
213
Hadoop Proprietà core-site.xml per ECS HDFS............................................. 214
File core-site.xml di esempio per la modalità di autenticazione
semplice........................................................................................ 218
Parte 8
Accesso ai dati ECS
221
Capitolo 26
Supporto ECS Amazon S3 Object Service API
223
API Amazon S3............................................................................................224
Funzionalità supportate e non supportate di API S3....................... 224
Estensioni delle API....................................................................... 227
Autenticazione con il servizio S3.................................................... 231
Utilizzo di SDK per l'accesso al servizio S3..................................... 231
7
SOMMARIO
Capitolo 27
Supporto ECS OpenStack Swift Object Service API
235
OpenStack Swift API....................................................................................236
Operazioni supportate di OpenStack Swift..................................... 236
Estensioni delle API....................................................................... 238
Autenticazione OpenStack versione 1 ........................................... 242
Autenticazione OpenStack versione 2............................................ 243
Autorizzazione su container........................................................... 245
Capitolo 28
Supporto API ECS EMC Atmos Object Service
247
Funzionalità EMC Atmos supportate da API................................................. 248
Chiamate EMC Atmos REST API supportate.................................................. 248
Chiamate EMC Atmos REST API non supportate........................................... 250
Supporto subtenant in chiamate EMC Atmos REST API.................................250
Estensioni delle API.....................................................................................251
Aggiunta di dati a un object........................................................... 251
Parte 9
Utilizzo dell'API REST
253
Capitolo 29
Utilizzo di ECS Management REST API
255
Introduzione............................................................................................... 256
Autenticazione con ECS Management REST API........................................... 256
Autenticazione con AUTH-TOKEN ................................................... 256
Autenticazione con cookie............................................................. 257
Logout........................................................................................... 258
Whoami......................................................................................... 259
ECS Management REST API summary...........................................................259
Parte 10
Manutenzione hardware
263
Capitolo 30
Hardware ECS
265
Componenti hardware dell'appliance ECS................................................... 266
Configurazioni e percorsi di aggiornamento degli appliance ECS................. 269
Cablaggio di alimentazione CA monofase per appliance U-Series ............... 271
Cablaggio di alimentazione CA trifase per appliance U-Series......................273
Switch.........................................................................................................277
Switch privato: Arista 7048............................................................ 278
Switch pubblico: Arista 7150S-24.................................................. 278
Switch pubblico: Arista 7124SX..................................................... 279
Cablaggio di reti.......................................................................................... 279
Nodi............................................................................................................280
Viste anteriori del server................................................................ 281
Vista posteriore del server..............................................................282
Nomi host di rack e nodi..............................................................................284
Unità disco..................................................................................................285
Unità disco integrate................................................................................... 285
Dischi ed enclosure.....................................................................................286
Unità disco in DAE..........................................................................286
LCC................................................................................................ 290
Modulo di controllo della ventola................................................... 291
ICM................................................................................................ 292
Alimentatore DAE........................................................................... 293
8
SOMMARIO
Cablaggio SAS U-Series..................................................................295
Capitolo 31
Sostituzione di un disco di storage ECS in un appliance U-Series
299
Pianificazione della sostituzione delle unità................................................300
Output per il comando cs_hal list disks.......................................................300
Sostituzione di unità................................................................................... 301
Capitolo 32
Sostituzione di un disco di storage ECS in hardware di terze parti
311
Pianificazione della sostituzione delle unità................................................312
Output per il comando cs_hal list disks.......................................................312
Sostituzione di unità................................................................................... 313
Capitolo 33
Aggiunta di un aggiornamento di 60 dischi a un appliance ECS USeries
319
Pianificazione di un aggiornamento di 60 dischi......................................... 320
Comandi cs_hal.......................................................................................... 324
Esecuzione di un aggiornamento di 60 dischi..............................................325
Capitolo 34
Requisiti di rack di terze parti ECS
331
Requisiti di rack di terze parti ECS............................................................... 332
9
SOMMARIO
10
PARTE 1
Novità
Capitolo 1, "Nuove funzionalità in ECS 2.0"
Novità
11
Novità
12
CAPITOLO 1
l
Nuove funzionalità................................................................................................ 14
13
Nuove funzionalità
Vengono descritte le nuove funzionalità e le aggiunte disponibili in ECS 2.0.
Controller
Nelle release precedenti ECS utilizzava il controller ViPR per fornire una serie di servizi,
tra cui autorizzazione, autenticazione, licenze e logging. Queste funzionalità sono ora
incluse in ECS e ViPR non è più richiesto.
Inoltre, non è più necessario installare ECS in una virtual machine, in quanto il primo
nodo in un appliance ECS funge ora da programma di installazione per tutti i nodi.
Portal
ECS era configurato in precedenza dall'interfaccia utente di ViPR. Con ECS 2.0 è
disponibile un nuovo portale che fornisce funzionalità di configurazione, gestione e
monitoraggio per ECS e relativi tenant.
Monitoraggio e diagnostica
ECS fornisce ora funzionalità complete di monitoraggio e diagnostica tramite il portale
ECS ed ECS API. Sono supportate le funzionalità indicate di seguito.
l
l
Misurazione
n
Misurazione dell'utilizzo di namespace e bucket
n
Misurazione temporale di namespace e bucket per capacità, larghezza di banda e
numero di object.
Utilizzo della capacità
n
l
l
l
Monitoraggio dell'utilizzo dello storage pool.
Monitoraggio dell'ambiente fisico
n
Monitoraggio dell'integrità di nodi e dischi
n
Monitoraggio dell'integrità di nodi: utilizzo di CPU, memoria e scheda NIC
n
Monitoraggio dell'integrità dei processi
Efficienza dello storage
n
Monitoraggio delle prestazioni dei job dei codici di cancellazione
n
Monitoraggio dell'utilizzo dei livelli di blocchi
n
Monitoraggio delle operazioni di ripristino
n
Monitoraggio del traffico back-end per operazioni di storage (codici di
cancellazione, riduzione geografica mediante XOR, ripristino)
Monitoraggio della replica geografica
n
Monitoraggio della replica
n
Monitoraggio del failover
n
Monitoraggio del bootstrap
Miglioramenti geografici
Sono stati apportati i seguenti miglioramenti all'utilizzo del meccanismo di replica
geografica di ECS:
14
l
Miglioramento geografico: failover temporaneo dei siti a pagina 15
l
Miglioramento geografico: RPO (Recovery Point Objective) migliorato a pagina 15
l
Miglioramento geografico: Miglioramenti alle prestazioni dell'accesso multisito
tramite geocaching a pagina 15
Miglioramento geografico: failover temporaneo dei siti
ECS 2.0 offre metodi automatici e sofisticati per gestire failback e guasti temporanei dei
siti. Con questa nuova funzionalità le applicazioni accedono ai dati anche in assenza di
connettività tra VDC federati. Sussistono limitazioni in alcune operazioni, ad esempio
nella creazione di nuovi bucket quando i siti sono inattivi. ECS eseguirà automaticamente
la risincronizzazione dei siti e riconcilierà i dati quando tutti i siti saranno nuovamente
operativi e interconnessi.
Miglioramento geografico: RPO (Recovery Point Objective) migliorato
Nelle release precedenti a ECS 2.0, i blocchi di object di ECS avevano dimensione fissa
(128 MB), erano sigillati e venivano replicati in un sito remoto solo una volta riempito il
blocco. Sebbene questa strategia fosse più efficiente, sussisteva l'eventualità che non
venissero replicati molti blocchi con dati di dimensione inferiore a 128 MB in caso di
inattività di un intero sito o un rack. Per risolvere questo problema, in ECS 2.0 il processo
di replica viene ora avviato nel momento in cui un blocco inizia a ricevere dati.
Miglioramento geografico: Miglioramenti alle prestazioni dell'accesso multisito tramite
geocaching
Nelle release precedenti a ECS 2.0, con la federazione di più VDC, qualsiasi tentativo di
lettura di un object doveva essere eseguito nel VDC che possedeva tale object. Di
conseguenza, ogni volta che un utente di un altro sito accedeva ai dati, incorreva in un
costo in termini di larghezza di banda WAN e in prestazioni ridotte a causa della latenza
WAN.
ECS 2.0 risolve questo problema memorizzando nella cache gli object nei siti secondari,
in modo che gli utenti possano accedere in locale ai dati senza un trasferimento WAN.
Misurazione degli object
La misurazione degli object consente il retrieval di statistiche chiave per un tenant e per i
bucket a esso associati. La misurazione dei dati include capacità, numero di object,
object creati, object eliminati e larghezza di banda (in entrata e in uscita) e può essere
sottoposta a retrieval per uno specifico point-in-time o per un intervallo di tempo.
Policy di conservazione
È possibile applicare un periodo di conservazione agli object container (definiti bucket in
Amazon S3, container in OpenStack Swift e subtenant in EMC Atmos) e agli object per
impedire la modifica di dati critici in un determinato periodo di tempo. ECS consente
inoltre di definire policy applicabili a object, in modo che il periodo di conservazione
venga applicato in conformità alla policy definita, anziché a un periodo specifico.
Gestione quote
È possibile impostare limiti di quota in un bucket o un namespace. In questo modo, un
tenant può definire la quantità massima di storage utilizzabile per un namespace e i
tenant possono creare bucket con limiti di quota. È possibile applicare quote rigide e
flessibili, singolarmente o in gruppo, per registrare un evento prima di imporre un limite
rigido.
Blocco di bucket e utenti
È possibile applicare un blocco a livello di bucket e utente mediante ECS Management
REST API, al fine di impedire l'accesso.
Bucket audit
Viene fornito il bucket audit per consentire il logging delle operazioni di creazione,
aggiornamento ed eliminazione di bucket e delle modifiche alle autorizzazioni di accesso
ai bucket.
Nuove funzionalità
15
Riconoscimento a livello di rack
I rack possono essere trattati come domini di errore distinti, consentendo la distribuzione
di blocchi di object store tra questi domini onde evitare che il guasto di un rack determini
il guasto dell'intero sito.
16
PARTE 2
Concetti
Capitolo 2, "Cos'è ECS?"
Capitolo 3, "Informazioni sulla protezione dei dati"
Concetti
17
Concetti
18
CAPITOLO 2
Cos'è ECS?
l
l
Panoramica........................................................................................................... 20
Piattaforma ECS.................................................................................................... 20
Cos'è ECS?
19
Cos'è ECS?
Panoramica
ECS è una piattaforma software-defined cloud storage completa che supporta lo storage,
la manipolazione e l'analisi di dati non strutturati su vasta scala nei prodotti hardware
disponibili in commercio. ECS è progettato nello specifico per supportare applicazioni
mobile, cloud, Big Data e di social networking. Può essere implementato come storage
appliance "chiavi in mano" o come prodotto software installabile in un set di server e
dischi qualificati disponibili in commercio.
L'architettura ECS, di tipo scale-out e geograficamente distribuita, è una piattaforma
cloud che offre:
l
costo inferiore a quello di un public cloud;
l
una combinazione ineguagliabile di efficienza dello storage e accesso ai dati;
l
sviluppo semplificato delle applicazioni grazie all'accesso in lettura e scrittura da
qualsiasi posizione con coerenza assoluta;
l
aumento di availability e prestazioni grazie all'assenza di single point of failure;
l
accessibilità universale per l'eliminazione dei silos di storage e processi inefficienti
di trasferimento dati/ETL.
Piattaforma ECS
La piattaforma ECS include i seguenti livelli e servizi software:
Figura 1 Servizi di piattaforma ECS
Servizi del portale
I servizi del portale includono interfacce per il provisioning, la gestione e il monitoraggio
delle risorse di storage. Di seguito sono indicate le interfacce disponibili.
20
l
GUI: interfaccia grafica basata su browser integrata, denominata portale portale.
l
REST: API RESTful che può essere utilizzata per sviluppare un portale portale
personalizzato.
l
CLI: interfaccia a riga di comando che consente di eseguire le stesse attività
dell'interfaccia basata su browser.
Cos'è ECS?
Servizi di storage
I servizi di storage vengono forniti dallo storage engine non strutturato, che garantisce
l'availability dei dati e la protezione da guasti hardware, danneggiamento dei dati e
situazioni di emergenza nei data center. Consente la gestione dei namespace globali in
data center situati in posizioni geografiche diverse e la replica geografica. Lo storage
engine non strutturato offre i servizi di storage indicati di seguito.
l
Object service: consente l'archiviazione, l'accesso e la manipolazione di dati non
strutturati. L'object service è compatibile con le istanze esistenti di Amazon S3 API,
OpenStack Swift API, EMC CAS API ed EMC Atmos API.
l
HDFS: consente di utilizzare l'infrastruttura di storage del portale come Big Data
repository su cui eseguire applicazioni analitiche Hadoop (in loco).
Servizio di provisioning
Questo servizio gestisce il provisioning delle risorse di storage e dell'accesso utente.
Nello specifico, gestisce gli elementi indicati di seguito.
l
Gestione degli utenti: tiene traccia degli utenti che dispongono dei diritti per
amministrare il sistema, eseguire il provisioning delle risorse di storage e accedere
agli object tramite richieste REST. portale supporta utenti locali e di dominio.
l
Autorizzazione e autenticazione per tutte le richieste di provisioning: interrogano il
dominio di autenticazione per determinare se gli utenti siano autorizzati a eseguire
operazioni di gestione, provisioning e accesso.
l
Gestione delle risorse: consente agli utenti autorizzati di creare storage pool, data
center virtuali e gruppi di replica.
l
Multi-tenant: gestisce il namespace che rappresenta un tenant e i bucket e gli object
associati.
Servizio della fabric
Il servizio della fabric è un cluster manager distribuito responsabile degli elementi
descritti di seguito.
l
Stato del cluster: aggrega i guasti hardware specifici del nodo e segnala l'integrità
complessiva del cluster.
l
Stato dei nodi: monitora lo stato fisico dei nodi e rileva e segnala eventuali errori.
l
Stato dei dischi: monitora l'integrità dei dischi e dei file system. Garantisce
operazioni di lettura/scrittura senza blocchi, rapide e raw nello storage engine ed
espone informazioni sulle singole unità disco e sul relativo stato in modo che lo
storage engine possa inserire dati nelle unità disco secondo gli algoritmi di
protezione dei dati integrati dello storage engine.
l
Gestione del software: fornisce strumenti da riga di comando per l'installazione e
l'esecuzione dei servizi, nonché per l'installazione e l'aggiornamento del fabric
software per i nodi del cluster.
Servizio di infrastruttura
Questo livello fornisce il sistema operativo Linux in esecuzione nei nodi commodity e
implementa interfacce di rete e altri strumenti correlati all'hardware.
Servizi di storage
21
Cos'è ECS?
22
CAPITOLO 3
l
l
l
l
l
l
l
Panoramica........................................................................................................... 24
Servizio di storage.................................................................................................24
Creazioni di object................................................................................................ 24
Letture di object.................................................................................................... 27
Codici di cancellazione..........................................................................................28
Ripristino in caso di guasti di dischi e nodi............................................................29
Failover e ripristino del sito................................................................................... 30
23
Panoramica
Vengono fornite informazioni sul modo in cui ECS protegge i dati non strutturati da guasti
dei nodi, dei dischi e del sito tramite replica e codici di cancellazione.
ECS garantisce la durata, l'affidabilità e l'availability degli object creando e distribuendo
tre copie degli object e dei relativi metadati nel set di nodi nel sito locale. Una volta
scritte correttamente le tre copie, ECS assegna codici di cancellazione alle copie degli
object per ridurre le spese di storage. Gestisce automaticamente gli errori e le operazioni
di ripristino senza richiedere ulteriori dispositivi o backup software.
Servizio di storage
Il livello del servizio di storage gestisce l'availability dei dati e la protezione da
danneggiamento dei dati, guasti hardware e situazioni di emergenza nei data center.
Lo storage engine non strutturato rientra nel livello del servizio di storage. Si tratta di un
servizio condiviso distribuito in esecuzione su ciascun nodo, che gestisce transazioni e
rende persistenti i dati nei nodi. Lo storage engine non strutturato consente la gestione
dei namespace globali in data center situati in posizioni geografiche diverse tramite
replica geografica.
Scrive tutti i dati relativi all'object (ad esempio, i dati dell'utente, i metadati e i dati della
posizione dell'object) in container logici di spazio su disco contiguo noti come blocchi. I
blocchi sono aperti e accettano scritture oppure chiusi e non accettano scritture. Una
volta chiusi i blocchi, lo storage engine eseguirà i codici di cancellazione. Lo storage
engine esegue scritture in blocchi in un modello append-only in modo che i dati esistenti
non vengano mai sovrascritti o modificati. Questa strategia migliora le prestazioni perché
la convalida del blocco e della cache non è richiesta per le operazioni di I/O. Tutti i nodi
possono elaborare le richieste di scrittura per lo stesso object simultaneamente e
scrivere in blocchi diversi.
Lo storage engine tiene traccia della posizione dell'object tramite un indice che registra il
nome dell'object, l'ID del blocco e l'offset. La posizione del blocco viene tracciata
separatamente tramite un indice che registra l'ID del blocco e un set di posizioni dei
dischi. L'indice della posizione del blocco contiene tre puntatori della posizione dei
dischi prima dei codici di cancellazione e più puntatori della posizione dopo i codici di
cancellazione. Lo storage engine esegue tutte le operazioni di storage (ad esempio, i
codici di cancellazione e il ripristino di object) sui blocchi.
Creazioni di object
Creazioni di object: un VDC
Nella figura seguente viene illustrato il modo in cui lo storage engine scrive dati di object
in presenza di un singolo VDC. In questo esempio, nel sito è implementato un singolo
appliance, ma si applicano gli stessi principi in presenza di più appliance. Gli otto nodi si
trovano in un singolo storage pool con un singolo gruppo di replica.
24
Figura 2 Sito singolo: creazioni di object
1. Un'applicazione crea un object in un bucket.
2. Lo storage engine scrive l'object in un blocco. Le posizioni dei dischi corrispondenti a
questo blocco si trovano in tre dischi/nodi diversi, pertanto le scritture si verificano in
tre dischi/nodi diversi in parallelo. Lo storage engine può scrivere l'object in
qualsiasi nodo appartenente al gruppo di replica del bucket. Il VDC in cui è creato
l'object è il proprietario dell'object.
3. Lo storage engine registra le posizioni dei dischi del blocco nell'indice delle posizioni
del blocco e l'ID e l'offset del blocco nell'indice delle posizioni dell'object.
4. Lo storage engine scrive l'indice delle posizioni dell'object in un blocco e le posizioni
dei dischi corrispondenti al blocco in tre dischi/nodi diversi, pertanto le scritture si
verificano in tre dischi/nodi diversi in parallelo. Le posizioni dell'indice vengono
scelte indipendentemente dalle posizioni del blocco di object.
5. Una volta scritte tutte le posizioni, lo storage engine accetta la scrittura
nell'applicazione.
Quando i blocchi di object sono pieni, lo storage engine esegue i codici di cancellazione.
Da questa operazione vengono esclusi i blocchi con indice delle posizioni degli object.
Creazioni di object: VDC federati (2 siti)
In un'implementazione federata di due VDC, lo storage engine scrive blocchi di object nel
VDC locale e anche in quello remoto.
Creazioni di object
25
Figura 3 Due siti: creazioni di object
2. Lo storage engine scrive l'object in un blocco nel sito in cui è acquisito. Le posizioni
dei dischi corrispondenti a questo blocco si trovano in tre dischi/nodi diversi,
pertanto le scritture si verificano in tre dischi/nodi diversi in parallelo. Lo storage
engine può scrivere l'object in qualsiasi nodo appartenente al gruppo di replica del
bucket. Lo storage engine registra le posizioni dei dischi del blocco nell'indice delle
posizioni del blocco e l'ID e l'offset del blocco nell'indice delle posizioni dell'object. Il
sito in cui è originariamente acquisito l'object è il proprietario dell'object.
nell'applicazione.
4. Lo storage engine replica il blocco in tre nodi nel sito federato. Registra le posizioni
del blocco nell'indice delle posizioni dell'object (non illustrato in questo diagramma)
anche in tre nodi diversi nel sito federato.
Quando i blocchi sono pieni, lo storage engine esegue i codici di cancellazione nei
blocchi di object. Da questa operazione vengono esclusi i blocchi con indice delle
posizioni degli object.
Quando in un gruppo di replica si trovano due VDC, entrambi contengono una copia
leggibile dell'object.
26
Tre siti: creazioni di object
Figura 4 Creazioni di object: VDC federati (3 o più siti)
2. Lo storage engine scrive l'object in un blocco nel sito in cui è acquisito. Le posizioni
dei dischi corrispondenti a questo blocco si trovano in tre dischi/nodi diversi,
pertanto le scritture si verificano in tre dischi/nodi diversi in parallelo. Può scrivere
l'object in qualsiasi nodo appartenente al gruppo di replica del bucket. Lo storage
engine registra le posizioni dei dischi del blocco nell'indice delle posizioni del blocco
e l'ID e l'offset del blocco nell'indice delle posizioni dell'object (non illustrato in
questo diagramma). Il VDC in cui viene ricevuta la scrittura è il proprietario dell'object
e contiene una copia leggibile dell'object.
nell'applicazione.
4. Lo storage engine replica i blocchi nei nodi di un altro VDC all'interno del gruppo di
replica. Per migliorare l'efficienza dello storage, lo storage engine esegue
un'operazione XOR sui blocchi con altri blocchi di altri object archiviati nel nodo.
Quando i blocchi sono pieni, lo storage engine esegue i codici di cancellazione nei
blocchi sottoposti all'operazione XOR. Laddove possibile, scrive blocchi XOR
direttamente in formato di codici di cancellazione senza passare attraverso la fase di
replica. Da questa operazione vengono esclusi i blocchi con indice delle posizioni degli
object.
Aggiornamenti di object
Quando un'applicazione aggiorna completamente un object, lo storage engine scrive un
nuovo object (secondo i principi descritti in precedenza). Lo storage engine aggiorna
quindi l'indice della posizione dell'object in modo che punti alla nuova posizione. Poiché
la vecchia posizione non è più referenziata da un indice, l'object originale è disponibile
per la garbage collection.
Letture di object
Letture di object: VDC singolo
In un'implementazione di un singolo sito, quando un client invia una richiesta di lettura,
lo storage engine utilizza l'indice delle posizioni dell'object per trovare i blocchi che
Letture di object
27
archiviano l'object, esegue il retrieval dei blocchi o dei frammenti con codici di
cancellazione, ricostruisce e restituisce l'object al client.
Letture di object: VDC federati (2 siti)
In una federazione a due siti, lo storage engine legge il blocco di object o i frammenti con
codici di cancellazione dai nodi nel VDC a cui è connessa l'applicazione. In una
federazione a due siti esistono blocchi di object in entrambi i siti.
Letture di object: VDC federati (3 o più siti)
Se l'applicazione richiedente è connessa al VDC che possiede l'object, lo storage engine
legge il blocco di object o i frammenti con codici di cancellazione dai nodi nel VDC. Se
l'applicazione richiedente non è connessa al VDC che possiede l'object, lo storage
engine esegue il retrieval del blocco di object o dei frammenti con codici di cancellazione
dal VDC che possiede l'object, li copia nel VDC a cui è connessa l'applicazione e
restituisce l'object all'applicazione. Lo storage engine conserva una copia dell'object
nella cache, nel caso in cui venga effettuata un'altra richiesta per l'object. Se viene
effettuata un'altra richiesta, lo storage engine confronta il timestamp dell'object nella
cache con quello dell'object nel VDC che lo possiede. Se coincidono, restituisce l'object
all'applicazione; se sono diversi, ne esegue il retrieval e lo memorizza nuovamente nella
cache.
Codici di cancellazione
ECS utilizza i codici di cancellazione per offrire una migliore efficienza di storage senza
compromettere la protezione dei dati.
Lo storage engine implementa lo schema dei codici di cancellazione 12/4 Reed Solomon
in cui un object è suddiviso in 12 frammenti di dati e 4 frammenti di codice. I 16
frammenti risultanti sono distribuiti tra i nodi nel sito locale. Lo storage engine è in grado
di ricostruire un object da uno qualsiasi dei 12 frammenti.
Tabella 1 Spese di storage durante l'implementazione di più siti
Numero di siti Spese di storage
1
1,33
2
2,67
3
2,00
4
1,77
5
1,67
6
1,60
7
1,55
8
1.52
ECS richiede almeno quattro nodi che eseguono l'object service in un singolo sito. Tollera
errori in base al numero di nodi.
Tabella 2 Tolleranza agli errori dei nodi in un sito
Nodi totali Tolleranza errori nodi per scritture
4
28
1
Tabella 2 Tolleranza agli errori dei nodi in un sito (continua)
Nodi totali Tolleranza errori nodi per scritture
8 - 24
2
Quando a un object viene assegnato un codice di cancellazione, le porzioni di dati
originali sono presenti sotto forma di singola copia costituita da 16 frammenti distribuiti
all'interno del cluster. Quando a un object è stato assegnato un codice di cancellazione,
ECS può leggere gli object direttamente senza alcuna decodifica o ricostruzione. ECS
utilizza solo i frammenti di codice per la ricostruzione di object quando si verifica un
guasto hardware.
Ripristino in caso di guasti di dischi e nodi
ECS monitora continuamente l'integrità dei nodi, dei dischi e degli object archiviati nel
cluster. Poiché ECS distribuisce le responsabilità relative alla protezione dei dati nel
cluster, è in grado di proteggere di nuovo automaticamente gli object a rischio in caso di
guasto nei nodi o nei dischi.
Stato del disco
ECS segnala l''integrità del disco come Good, Suspect o Bad.
l
Good: è possibile leggere e scrivere sulle partizioni del disco.
l
Suspect: il disco non ha ancora raggiunto un limite di soglia tale da essere
considerato non valido.
l
Bad: è stato raggiunto un determinato limite di soglia di prestazioni hardware ridotte.
Una volta che questo limite di soglia è stato raggiunto, i dati non possono essere letti
o scritti.
ECS scrive solo sui dischi validi. Non scrive sui dischi sospetti o non validi. ECS legge da
dischi validi e sospetti. Quando due blocchi di un object si trovano su dischi sospetti,
ECS scrive i blocchi in altri nodi.
Stato del nodo
ECS segnala l'integrità del nodo come Good, Suspect, Degraded o Bad.
l
Good: il nodo è disponibile e risponde alle richieste di I/O in modo tempestivo. Il
monitoraggio dello stato interno indica che è valido.
l
Suspect: il nodo è disponibile, ma segnala informazioni sullo stato interno, quali un
guasto della ventola (se sono presenti più ventole) e un guasto di un singolo
alimentatore (se vi sono alimentatori ridondanti). Oppure il nodo non è raggiungibile
dagli altri, ma è visibile nelle indagini BMC e il suo stato è sconosciuto.
l
Degraded: il nodo è disponibile, ma segnala dischi non validi o sospetti.
l
Bad: il nodo è raggiungibile, ma il monitoraggio dello stato interno indica uno stato
non valido. Ad esempio, le ventole del nodo sono offline, la temperatura della CPU è
troppo elevata, vi sono troppi errori di memoria e così via. Lo stato non valido può
inoltre essere segnalato quando il nodo è offline e le indagini BMC indicano uno
stato non accettabile.
ECS scrive solo sui nodi validi. Non scrive sui nodi sospetti, danneggiati o non validi. ECS
legge dai nodi validi e sospetti. Quando due blocchi di un object si trovano su nodi
sospetti, ECS scrive due nuovi blocchi in altri nodi. Quando un nodo viene segnalato
come sospetto o non valido, anche tutti i dischi che gestisce sono considerati sospetti o
non validi.
Ripristino in caso di guasti di dischi e nodi
29
Ripristino dei dati
Quando si verifica un guasto di un nodo o di un'unità nel sito, lo storage engine:
1. identifica i blocchi o i frammenti con codici di cancellazione coinvolti dal guasto;
2. scrive copie dei blocchi o dei frammenti con codici di cancellazione coinvolti in nodi
e dischi validi attualmente privi di copie.
Failover e ripristino del sito
ECS fornisce protezione da un guasto del sito dovuto a una situazione di emergenza o un
altro problema che determina l'inattività di un sito o la sua disconnessione da altri in
un'implementazione con federazione geografica.
Guasto temporaneo del sito
Si verifica un guasto temporaneo del sito quando viene interrotta la connettività di rete
tra VDC federati o quando un VDC è temporaneamente inattivo. Quando un VDC è
inattivo, la pagina Replication Group visualizza lo stato Temporarily unavailable
per il VDC irraggiungibile.
Quando vengono configurati bucket con la proprietà Access During Outage impostata su
On, le applicazioni possono leggere object quando sono connesse a qualsiasi sito.
Quando sono connesse applicazioni a un sito diverso dal proprietario del bucket,
l'applicazione deve accedere in modo esplicito al bucket per scrivervi o visualizzarne i
contenuti. Se un'applicazione modifica un object o un bucket mentre è connessa a un
VDC diverso dal proprietario, lo storage engine trasferisce la proprietà al sito in cui è
stata avviata la modifica.
Non è possibile completare le seguenti operazioni in alcun sito della federazione
geografica finché non verrà risolto il guasto temporaneo, indipendentemente
dall'impostazione Access During Outage:
l
Bucket: creazione o ridenominazione di bucket, modifica delle proprietà dei bucket,
elenco dei bucket per un namespace quando il sito proprietario non è raggiungibile
l
Namespace: generazione
l
Utente: generazione
Una volta riconnessi i siti, lo storage engine avvierà un'operazione di risincronizzazione
in background. Utilizzare le opzioni Monitor > Recovery Status del portale per monitorare
l'avanzamento dell'operazione di risincronizzazione.
Failover permanente del sito
Se si verifica una situazione di emergenza nel sito e il VDC non può essere riattivato, è
necessario eliminarlo.
30
PARTE 3
Capitolo 4, "Pianificazione di un'installazione"
31
32
CAPITOLO 4
l
l
l
l
l
Panoramica........................................................................................................... 34
Preparazione dell'area di installazione.................................................................. 34
ECS - Checklist dell'idoneità dell'installazione...................................................... 34
Connessione di appliance ECS in un unico sito .....................................................34
Requisiti multisito................................................................................................. 36
33
Panoramica
Vengono fornite informazioni sui requisiti multisito, relativi all'ambiente fisico e al data
center, nonché sulle topologie delle reti di gestione private.
Preparazione dell'area di installazione
Esaminare il documento Site Preparation Guide per conoscere i requisiti ambientali
associati al cabinet 40U-D utilizzato dall'appliance ECS.
ECS - Checklist dell'idoneità dell'installazione
Esaminare l'elenco dei componenti dell'infrastruttura necessari per garantire l'esito
positivo di un'installazione.
L'implementazione di un appliance ECS comprende i componenti descritti di seguito.
l
Uno o più rack.
n
Il rack deve essere collegato tramite uplink alla rete del cliente per la gestione
remota e del traffico dei dati.
Il rack e tutti i nodi devono essere accesi.
I nodi devono avere indirizzi IP validi assegnati da DHCP o configurati
staticamente.
l
Requisiti dell'infrastruttura: l'ambiente del data center deve includere i seguenti
server raggiungibili da tutti i nodi.
n
Server DHCP (se si assegnano indirizzi IP tramite DHCP)
n
Server DNS (o forwarder)
n
Server NTP
n
Server SMTP
SSH deve essere abilitato su tutti i nodi.
Le porte indicate di seguito sono aperte e utilizzate dal programma di installazione.
l
Registro di sistema Docker: 5000
l
Agente del ciclo di vita: 9240
l
Object:
9020-9025,9040,9091,9094-9098,8088,9898,1095,1096,1098,9100,9101,9111,3
218
l
ZooKeeper: 9277,9278,9279
Vedere Security Guide per l'elenco delle porte che devono essere aperte.
Connessione di appliance ECS in un unico sito
Le reti di gestione degli appliance ECS sono interconnesse tramite Nile Area Network. La
rete NAN viene creata connettendo la porta 51 o 52 a un altro turtle switch di un altro
appliance ECS. Tramite queste connessioni, i nodi di qualsiasi segmento possono
comunicare con qualsiasi altro nodo nella NAN.
34
La topologia più semplice per connettere tra loro gli appliance ECS non richiede switch
aggiuntivi. Tutti i turtle switch possono essere interconnessi tramite topologia lineare o
daisy-chain.
Figura 5 Topologia lineare o daisy-chain
In questa topologia, se si verifica una perdita di connettività, può verificarsi uno scenario
di split-brain.
Figura 6 Split-brain lineare o daisy-chain
Per una rete più affidabile, le estremità della topologia daisy-chain possono essere
interconnesse per creare una rete ad anello. La topologia ad anello è più stabile, dal
momento che uno scenario di split-brain richiederebbe due interruzioni dei collegamenti
dei cavi. Il principale svantaggio relativo a una topologia ad anello è rappresentato dal
fatto che le porte RMM non possono essere connesse alla rete del cliente, a meno che
all'anello non venga aggiunto uno switch esterno di aggregazione o del cliente.
Figura 7 Topologia ad anello
Le topologie daisy-chain o ad anello sono sconsigliate per le installazioni di grandi
dimensioni. In presenza di quattro o più appliance ECS, è consigliabile utilizzare uno
switch di aggregazione. L'aggiunta di uno switch di aggregazione in una topologia a stella
può garantire un livello avanzato di failover riducendo i problemi di split-brain.
Connessione di appliance ECS in un unico sito
35
Figura 8 Topologia a stella
Requisiti multisito
In fase di pianificazione di un'installazione ECS multisito, accertarsi di soddisfare i
requisiti indicati di seguito.
l
Sono richiesti almeno due VDC.
l
Ciascun VDC nella configurazione multisito richiede connettività IP agli altri VDC.
n
Latenza di rete: garantire una latenza massima di 1000 ms tra i siti.
n
Storage libero: se il piano di disaster recovery prevede l'esecuzione per un certo
periodo con un sito definitivamente guasto (anziché il ripristino tempestivo),
ciascun sito avrà bisogno di uno spazio di storage libero sufficiente su tutti i siti
per supportare il ribilanciamento dei dati. La quantità di spazio libero da lasciare
su tutti i siti sarà, in totale:
free space across n sites =1.33*x/(n-1)/(n-2)
dove x indica la quantità totale di dati dell'utente su n siti.
Questa quantità di spazio libero non è necessaria se si aggiunge un nuovo sito
immediatamente dopo il failover e non si continuano a utilizzare (N-1) siti a
tempo indeterminato.
36
PARTE 4
Capitolo 5, "Guida introduttiva al portale ECS"
Capitolo 6, "Configurazione di storage pool, VDC e gruppi di replica"
Capitolo 7, "Aggiunta di utenti e assegnazione di ruoli"
Capitolo 8, "Configurazione di un namespace per un tenant"
Capitolo 9, "Acquisizione e caricamento di un file di licenza nel portale ECS"
Capitolo 10, " Gestione di un tenant"
Capitolo 11, "Failover di un sito ECS"
37
38
CAPITOLO 5
l
l
l
l
l
Introduzione..........................................................................................................40
Login al portale ECS.............................................................................................. 40
Modifica password................................................................................................41
Accesso alle aree del portale.................................................................................41
Ordinamento e ricerche nelle tabelle del portale................................................... 44
39
Introduzione
Il portale ECS consente di configurare, gestire e monitorare ECS.
Il portale fornisce inoltre funzionalità per consentire ai tenant di gestire e monitorare i
propri namespace e creare e configurare bucket al loro interno.
Il portale è principalmente destinato a utenti di gestione, System Administrator e
amministratori di namespace/tenant di ECS. Gli utenti di object storage accedono a ECS
mediante i protocolli di object supportati utilizzando client che supportano tali protocolli.
Ulteriori informazioni su utenti e ruoli di ECS sono disponibili in Aggiunta di utenti e
assegnazione di ruoli a pagina 56.
Il portale utilizza l'istanza pubblica di ECS Management REST API ed è possibile
sviluppare client personalizzati che utilizzino questa API per eseguire operazioni.
Login al portale ECS
È possibile effettuare il login al portale ECS dal browser specificando l'indirizzo IP di
qualsiasi nodo nel cluster.
Prima di cominciare
l
È possibile eseguire il login al portale ECS se si dispone del ruolo di System Admin o
Namespace Admin in ECS.
l
Per l'accesso iniziale viene fornito un account utente "root", assegnato al ruolo di
System Admin.
La sessione scadrà automaticamente dopo 15 minuti di inattività.
Procedura
1. Digitare l'indirizzo IP pubblico del primo nodo nel sistema oppure l'indirizzo del load
balancer configurato come front-end per ECS nel seguente formato: http:/
<node1_public_ip>.
Ad esempio: http://198.51.100.244
Verrà visualizzata la schermata di login.
40
2. Inserire il nome utente e la password.
Se si esegue il login utilizzando le credenziali root iniziali (root/ChangeMe), è
consigliabile modificare la password.
La sessione terminerà chiudendo il browser o eseguendo il logout. Il logout comporta
sempre la chiusura della sessione. Se non è possibile effettuare il login, contattare
l'amministratore.
Modifica password
Una volta eseguito l'accesso al portale ECS, sarà possibile modificare la password.
Prima di cominciare
Gli utenti con ruoli di System Admin e Namespace Admin possono accedere alla pagina
Password.
Eseguendo l'accesso come utente root, questo account non coincide con quello utilizzato
per fornire l'accesso della riga di comando a un nodo. Pertanto, la modifica della
password in questa posizione non si rifletterà sull'account root del nodo.
Procedura
1. Nel portale ECS selezionare Settings > Password
2. Immettere una nuova password nel campo Password, quindi immetterla nuovamente
per conferma.
3. Fare clic su Salva.
Accesso alle aree del portale
Il portale fornisce un menu di navigazione a sinistra e un'area di pagine.
Modifica password
41
Il System Admin può accedere a tutte le pagine, un Namespace Admin può accedere a un
numero limitato di pagine ed eseguire solo operazioni specifiche per i tenant.
Nelle sezioni indicate di seguito viene illustrato l'accesso fornito per utenti di gestione
diversi.
l
System Administrator a pagina 42
l
Namespace Admin a pagina 44
System Administrator
Nella tabella indicata di seguito vengono elencate le voci di menu accessibili e viene
fornito un link ad articoli della documentazione contenenti ulteriori informazioni sul loro
utilizzo.
Area
Menu
Operazioni supportate
Monitor
Metering
Visualizzazione della misurazione di object per
namespace o bucket.
Monitoraggio della capacità di storage pool, nodi e
dischi.
Utilizzo della capacità
Per ulteriori informazioni vedere: Monitoraggio dello
storage: misurazione e capacità a pagina 106.
Events
Visualizzazione di eventi di audit.
Per ulteriori informazioni vedere: Monitoraggio degli
eventi: portale di audit, API, alert di sistema ed eventi
CLI a pagina 128.
Traffic Metrics
Vengono forniti dettagli di monitoraggio come indicato
di seguito.
l
Monitoraggio di larghezza di banda e latenza in
lettura e scrittura.
l
Monitoraggio di storage node e stato del disco per
ciascuno storage pool.
l
Monitoraggio dell'integrità di nodi e processi per
utilizzo di CPU e memoria.
l
Monitoraggio dell'utilizzo della larghezza di banda
del disco.
Hardware Health
Node and Process Health
Larghezza di banda disco
Per ulteriori informazioni vedere: Monitoraggio di
risorse: hardware, traffico di rete, larghezza di banda
del disco, integrità di nodi e processi a pagina 96
Riepilogo dei blocchi
Codici di cancellazione
Recovery Status
Geo Replication
Vengono forniti dettagli di monitoraggio come indicato
di seguito.
l
Monitoraggio dei blocchi e del relativo stato.
l
Monitoraggio dello stato dei codici di
cancellazione.
l
Monitoraggio dello stato di ripristino.
l
Monitoraggio dell'attività di replica geografica.
Per ulteriori informazioni vedere: Monitoraggio dei
servizi: blocchi, codici di cancellazione, replica
geografica e stato di ripristino a pagina 116.
Gestione
42
Storage pool
Sono consentite le operazioni indicate di seguito.
l
Aggiunta di uno storage pool e indicazione dei
nodi che comprende.
Area
Menu
Data center virtuale
l
Replication Group
l
Aggiunta di un VDC e definizione dei dettagli di
connessione.
Configurazione di un gruppo di replica tramite
l'aggiunta di storage pool appartenenti a un VDC.
Per ulteriori informazioni vedere: Configurazione di
storage pool, VDC e gruppi di replica a pagina 48.
Autenticazione
Aggiunta di un provider di autenticazione per gli utenti
di dominio.
Vedere Aggiunta di utenti e assegnazione di ruoli a
pagina 56.
Namespace
l
Creazione di un nuovo namespace.
l
Impostazione di una quota per il namespace.
l
Mapping di utenti di object a un namespace.
Per ulteriori informazioni vedere: Configurazione di un
namespace per un tenant a pagina 76
Utenti
l
Creazione di utenti di object per il namespace.
l
Modifica di utenti di object.
l
Creare chiavi segrete.
Per ulteriori informazioni vedere: Aggiunta di utenti e
assegnazione di ruoli a pagina 56
Bucket
l
Creazione di un bucket.
l
Assegnazione di ACL al proprietario del bucket e
agli utenti di object.
Per ulteriori informazioni vedere: Creazione e
configurazione di bucket a pagina 140
Impostazion URL di base dell'object
i
Impostazione dell'URL di base per determinare quale
parte dell'indirizzo dell'object rappresenta il bucket e
il namespace.
Per ulteriori informazioni vedere: Indirizzamento di
object storage ECS e utilizzo dell'URL di base a pagina
134
Modifica password
Modifica della password personale.
Per ulteriori informazioni vedere: Modifica password a
pagina 41
ConnectEMC
Configurazione dell'invio di eventi a EMC.
Licenze
Visualizzazione dello stato della licenza e caricamento
di una licenza.
Accesso alle aree del portale
43
Area
Menu
Per ulteriori informazioni vedere: Acquisizione e
caricamento di un file di licenza nel portale ECS a
pagina 82
Namespace Admin
Nella tabella indicata di seguito vengono elencate le voci di menu accessibili e viene
fornito un link ad articoli della documentazione contenenti ulteriori informazioni sul loro
utilizzo.
Area
Menu
Monitor
Metering
Visualizzazione della misurazione di object per
namespace o bucket.
Per ulteriori informazioni, consultare Monitoraggio
dello storage: misurazione e capacità a pagina 106
Gestione
Namespace
Modifica del namespace.
Per ulteriori informazioni, consultare Configurazione di
un namespace per un tenant a pagina 76
Utenti
l
Creazione di utenti di object per il namespace.
l
Modifica di utenti di object
l
Creazione di chiavi segrete per utenti di object
Per ulteriori informazioni, consultare Aggiunta di utenti
e assegnazione di ruoli a pagina 56
Bucket
l
Creazione di un bucket.
l
Assegnazione di ACL al proprietario del bucket e
agli utenti di object.
Per ulteriori informazioni, consultare Creazione e
configurazione di bucket a pagina 140
Impostazion Modifica password
i
Modifica della password personale.
Per ulteriori informazioni, consultare Modifica
password a pagina 41
Ordinamento e ricerche nelle tabelle del portale
Quando un set di dati nel portale è di dimensioni elevate, e soprattutto se viene eseguito
su più pagine, è utile poter riordinare una tabella e cercare informazioni al suo interno.
Di seguito è illustrato un esempio di una pagina contenente una tabella.
44
Riordinamento di colonne di tabelle
È possibile riordinare le righe di una tabella in base all'ordinamento di una colonna
selezionata. Una colonna di tabella può essere ordinata facendo clic sull'intestazione.
Le colonne contenenti dati testuali vengono disposte in ordine alfabetico. Se ad esempio
si seleziona il campo Namespace nella tabella Users, la colonna verrà disposta in ordine
alfabetico e regolerà l'ordinamento delle righe. Quando si reimmette la pagina, verrà
applicato l'ordinamento predefinito. In modo analogo, l'aggiornamento della pagina
ripristinerà l'ordinamento predefinito.
Utilizzo della ricerca
La funzionalità di ricerca consente di filtrare le righe delle tabelle in base a stringhe di
testo corrispondenti.
Man mano che si digita testo nella casella di ricerca, vengono visualizzate le righe
contenenti le stringhe corrispondenti alla ricerca. L'ordine di visualizzazione delle righe
corrispondenti ai criteri di ricerca varia a seconda dell'ordinamento applicato alle
colonne delle tabelle (vedere Riordinamento di colonne di tabelle a pagina 45).
Aggiornamento di una pagina
Nelle pagine contenenti i dati delle tabelle è disponibile un controllo di aggiornamento.
Un aggiornamento ripristina l'ordinamento predefinito della tabella.
Ordinamento e ricerche nelle tabelle del portale
45
46
CAPITOLO 6
Configurazione di storage pool, VDC e gruppi di
replica
l
l
l
l
l
Configurazione di storage pool, VDC e gruppi di replica.........................................48
Storage pool..........................................................................................................48
Data center virtuali (VDC)...................................................................................... 49
Gruppi di replica....................................................................................................52
Configurazione di ConnectEMC..............................................................................53
47
Vengono fornite informazioni su come utilizzare il portale per creare, modificare ed
eliminare storage pool, VDC e gruppi di replica per implementazioni singole o federate e
su come configurare ConnectEMC per l'object service.
Per eseguire queste procedure, gli utenti devono essere assegnati al ruolo di System
Admin.
Storage pool
Gli storage pool consentono di organizzare risorse di storage in base ai requisiti del
business. Se ad esempio è necessaria la separazione fisica dei dati, è possibile
partizionare lo storage in più storage pool diversi.
Utilizzare la pagina Storage Pool Management disponibile in Manage > Storage Pools per
creare nuovi storage pool e modificare, eliminare o visualizzare i dettagli degli storage
pool esistenti.
Figura 9 Pagina Storage Pool Management
Tabella 3 Proprietà degli storage pool
Campo
Descrizione
Nome
Nome dello storage pool.
# Nodes
Numero di nodi assegnati allo storage pool.
Stato
Stato corrente dello storage pool e dei nodi. Di seguito sono indicati gli stati di
uno storage pool.
l
Ready: sono installati almeno quattro nodi e tutti hanno uno stato ready
to use.
Nome host
l
Not Ready: un nodo nello storage pool non è in stato ready to use.
l
Partially Ready: sono presenti meno di quattro nodi e tutti hanno uno stato
ready to use.
Nome host completo assegnato al nodo.
Node IP address Indirizzo IP pubblico assegnato al nodo.
48
Rack ID
Nome assegnato al rack contenente i nodi.
Azioni
Le azioni:
Tabella 3 Proprietà degli storage pool (continua)
Campo
Descrizione
l
Edit: utilizzare questa azione per modificare il nome dello storage pool e il
set di nodi inclusi al suo interno.
l
Delete: utilizzare questa azione per eliminare storage pool. Tutti i nodi
nello storage pool devono essere rimossi per poter eliminare uno storage
pool. Non è possibile eliminare lo storage pool di sistema, ovvero il primo
storage pool creato. Se lo storage pool di sistema include nodi vuoti,
questi possono essere eliminati se superiori a quattro.
Creare storage pool
Per assegnare nodi a storage pool, attenersi alla procedura descritta di seguito. Gli
storage pool devono contenere almeno quattro nodi. Il primo storage pool creato è noto
come storage pool di sistema, poiché archivia metadati di sistema. Lo storage pool di
sistema non può essere eliminato.
Procedura
1. Dal portale selezionare Manage > Storage Pools.
2. Fare clic su New Storage Pool.
3. Digitare il nome dello storage pool. Ad esempio: StoragePool1.
4. Selezionare i nodi da aggiungere allo storage pool dall'elenco Available Nodes.
a. Per selezionare individualmente i nodi, fare clic sull'icona + accanto a ciascun
nodo.
b. Per selezionare tutti i nodi disponibili, fare clic sull'icona + in cima all'elenco
Available Nodes.
c. Per restringere l'elenco di nodi disponibili, digitare l'indirizzo IP pubblico o il nome
host del nodo nel campo search.
5. Una volta completata la selezione, fare clic su Save.
6. Una volta che lo storage pool passerà allo stato Ready, attendere 10 minuti prima di
eseguire altre attività di configurazione. In questo modo verrà inizializzata l'ora dello
storage pool.
Se non si attenderà un periodo di tempo sufficiente, verrà restituito il seguente
messaggio di errore: Error 7000 (http: 500): An error occurred in
the API Service. An error occurred in the API service.Cause:
error insertVdcInfo. Virtual Data Center creation failure
may occur when Data Services has not completed
initialization.
Se si riceve questo errore, attendere ulteriormente prima di procedere con altre
configurazioni.
Data center virtuali (VDC)
I VDC sono costrutti logici. Si tratta di risorse di livello superiore che rappresentano
l'insieme dell'infrastruttura ECS da gestire come unità.
Utilizzare la pagina Virtual Data Center Management disponibile in Manage > Virtual Data
Centers per visualizzare i dettagli dei VDC, creare nuovi VDC, modificare ed eliminare VDC
Creare storage pool
49
esistenti, nonché federare più VDC per un'implementazione multisito. Nell'esempio
riportato di seguito viene illustrata la pagina Manage Virtual Data Center per
un'implementazione federata multisito. La configurazione viene eseguita con tre siti. I
VDC sono denominati vdc1, vdc2 e vdc3.
Figura 10 Pagina VDCManagement
Tabella 4 Proprietà di VDC
Campo
Descrizione
Nome
Nome del VDC.
Endpoint
Indirizzi IP pubblici dei nodi negli storage pool che comprendono il VDC.
Stato
Di seguito sono indicati gli stati.
Azioni
l
Online
l
Permanently Failed: il VDC è stato eliminato.
Le azioni:
l
Edit: utilizzare questa azione per modificare il nome del VDC, la chiave di
accesso e gli indirizzi IP pubblici dei nodi negli storage pool del VDC.
l
Delete: utilizzare questa azione per eliminare un VDC. L'operazione di
eliminazione determina il failover permanente del VDC, pertanto non è possibile
riaggiungerlo utilizzando lo stesso nome. Non è possibile eliminare un VDC
facente parte di un gruppo di replica finché non vi verrà rimosso. Non è
possibile eliminare un VDC dopo aver eseguito il login al VDC che si tenta di
eliminare.
Creare un VDC per un singolo sito
In fase di creazione di un VDC per l'implementazione in un singolo sito o durante la
creazione del primo VDC in una federazione multisito, attenersi alla procedura descritta
di seguito.
Prima di cominciare
Uno o più storage pool sono disponibili e in stato Ready.
Procedura
1. Dal portale ECS selezionare Manage > Virtual Data Center.
2. Fare clic su New Virtual Data Center.
3. Digitare un nome. Ad esempio: VDC1.
Il nome non può includere spazi o caratteri di sottolineatura.
4. Fare clic su Get VDC Access Key.
50
La chiave di accesso VDC viene utilizzata come chiave simmetrica per la crittografia
del traffico di replica tra VDC in una federazione multisito.
5. Nella casella di testo Endpoints immettere gli indirizzi IP pubblici di ciascun nodo
negli storage pool del VDC. Fornire tali elementi sotto forma di elenco separato da
virgole.
Aggiungere un VDC a una federazione
Per aggiungere un VDC (ad esempio, VDC2) a un VDC esistente (ad esempio, VDC1) e
creare una federazione, attenersi alla procedura descritta di seguito.
Prima di cominciare
Ottenere le credenziali del portale ECS per l'utente root o per un utente con credenziali di
System Administrator per eseguire il login a entrambi i siti.
Verificare di disporre dell'elenco di indirizzi IP pubblici per i nodi dal sito che si intende
aggiungere (VDC2).
Verificare che nel sito da aggiungere (VDC2) sia caricata una licenza valida e sia presente
almeno uno storage pool in stato Ready.
Procedura
1. Eseguire il login al portale ECS nel sito che si intende aggiungere (VDC2).
Le credenziali predefinite sono root/ChangeMe.
2. Selezionare Manage > Virtual Data Center.
3. Fare clic su Get VDC Access Key.
4. Selezionare la chiave di accesso e copiarla con la combinazione di tasti CTRL+C per
salvarla nel buffer.
5. Eseguire il logout dal portale ECS nel sito che si intende aggiungere (VDC2).
6. Eseguire il login al portale ECS per il primo VDC (VDC1).
7. Selezionare Manage > Virtual Data Center.
8. Fare clic su New Virtual Data Center.
9. Immettere il nome del VDC. Ad esempio: VDC2.
10.Fare clic nel campo Key e incollare (CTRL-V) la chiave copiata dal sito che si intende
aggiungere (VDC2) seguendo i passaggi 3 e 4 in alto.
11.Immettere gli indirizzi IP pubblici del sito da aggiungere. Fornire tali elementi sotto
forma di elenco separato da virgole.
12.Fare clic su Salva.
Eseguire il failover di un sito/eliminare un VDC
Utilizzare questa procedura per eliminare un VDC. L'eliminazione di un VDC avvia il
failover del sito quando il VDC in questione fa parte di una federazione multisito.
Se si verifica una situazione di emergenza, un intero VDC potrebbe non essere più
recuperabile. ECS tratta inizialmente il VDC irrecuperabile come guasto del sito
temporaneo. Se il guasto è permanente, è necessario rimuovere il VDC dalla federazione
per avviare l'elaborazione del failover che ricrea e protegge nuovamente gli object
archiviati nel VDC che presenta il problema. Le attività di ripristino vengono eseguite in
background. Per controllare il processo di ripristino, utilizzare Monitor > Geo Replication >
Failover Procesing.
Aggiungere un VDC a una federazione
51
Procedura
1. Accedere a uno dei VDC operativi nella federazione.
2. Passare a Manage > Replication Group.
3. Fare clic su Edit per il gruppo di replica contenente il VDC da eliminare.
4. Fare clic su Delete nella riga contenente il VDC e lo storage pool da rimuovere.
6. Passare a Manage > VDC. Lo stato del VDC rimosso in modo definitivo cambia in
Permanently failed.
7. Selezionare Delete dall'elenco a discesa nella riga del VDC da rimuovere.
Gruppi di replica
I gruppi di replica sono costrutti logici che definiscono il punto in cui il contenuto dello
storage pool è protetto. I gruppi di replica possono essere locali o globali. I gruppi di
replica locali proteggono gli object all'interno dello stesso VDC da errori nei nodi o nei
dischi. I gruppi di replica globali proteggono gli object da errori nei nodi, nei dischi e nei
siti.
Utilizzare la pagina Manage Replication Groups per visualizzare dettagli dei gruppi di
replica, creare nuovi gruppi e modificare quelli esistenti. Non è possibile eliminare gruppi
di replica in questa versione.
Figura 11 Pagina Manage Replication Groups
Tabella 5 Proprietà dei gruppi di replica
Campo
Descrizione
Nome
Nome del gruppo di replica.
VDC
Numero dei VDC nel gruppo di replica e nomi dei VDC in cui si trovano gli storage
pool.
Storage pool
Nomi degli storage pool e dei VDC associati.
Stato
Di seguito sono indicati gli stati.
Azioni
52
l
Online
l
Temp Unavailable: il traffico di replica in questo VDC ha avuto esito
negativo. Se tutto il traffico di replica nello stesso VDC è in stato Temp
Unavailable, sono consigliabili ulteriori indagini sulla causa dell'errore.
Edit: utilizzare questa azione per modificare il nome del gruppo di replica e il set
di VDC e storage pool al suo interno.
Creare gruppi di replica
Per creare gruppi di replica, attenersi alla procedura descritta di seguito.
Per creare gruppi di replica globali, scegliere storage pool da più VDC.
Procedura
1. Dal portale ECS selezionare Manage > Replication Group .
2. Fare clic su New Replication Group.
3. Digitare un nome. Ad esempio: ReplicationGroup1.
4. Fare clic su Add VDC.
5. Selezionare un data center virtuale e uno storage pool dall'elenco a discesa.
Ripetere questa procedura per aggiungere i VDC e gli storage pool richiesti per la
protezione degli object.
Configurazione di ConnectEMC
Utilizzare questa procedura per configurare l'object service ConnectEMC.
Procedura
1. Nel portale fare clic su Settings > ConnectEMC.
2. Selezionare il tipo di trasporto e scegliere se crittografare le comunicazioni.
3. Se il tipo di trasporto è FTPS, utilizzare la tabella di seguito per ottenere assistenza
nel completamento della configurazione.
Opzione
Descrizione
Crittografia
Scegliere se crittografare i dati del servizio.
Hostname
Specificare corpusfep3.emc.com.
Email Server
Specificare il server SMTP utilizzato nell'ambiente.
Email Addresses L'indirizzo email a cui inviare le notifiche del servizio
ConnectEMC.
4. Se il tipo di trasporto è SMTP, utilizzare la tabella di seguito per ottenere assistenza
nel completamento della configurazione.
Opzione
Descrizione
Crittografia
Scegliere se crittografare i dati del servizio.
Autenticazione
Scegliere un tipo per eseguire l'autenticazione al server SMTP
oppure NONE. Se è richiesta l'autenticazione, è inoltre
necessario fornire il nome utente e la password per
l'autenticazione al server SMTP.
Server SMTP
Immettere il nome host o l'indirizzo IP del server SMTP.
Porta SMTP
Immettere la porta del server SMTP.
Creare gruppi di replica
53
Opzione
Descrizione
Indirizzo mittente L'indirizzo email da visualizzare come indirizzo del mittente per
le notifiche del servizio ConnectEMC.
Email Addresses
L'indirizzo email aggiuntivo a cui inviare le notifiche del servizio
ConnectEMC.
Per consentire l'invio automatico degli alert, il sistema deve disporre di licenza e al
suo interno devono essere configurati ConnectEMC, storage pool, un VDC e gruppi di
replica.
54
CAPITOLO 7
l
l
l
l
l
Introduzione..........................................................................................................56
Informazioni su utenti e ruoli in ECS...................................................................... 56
Attività con gli utenti nel portale ECS..................................................................... 60
Attività con i provider di autenticazione nel portale ECS........................................ 65
Caratteristiche principali del mapping degli utenti a un namespace...................... 72
55
Introduzione
In questo articolo vengono descritti i tipi di utenti supportati in ECS e i ruoli a cui possono
essere assegnati.
Vengono introdotti i concetti principali su utenti e ruoli di ECS:
l
Informazioni su utenti e ruoli in ECS a pagina 56
l
Attività con gli utenti nel portale ECS a pagina 60
Viene quindi descritto come aggiungere utenti di gestione o di object:
l
Aggiungere un nuovo utente di object a pagina 62
l
Aggiungere un utente di dominio come utente di object a pagina 63
l
Creare un utente di gestione locale o assegnare un utente di dominio a un ruolo di
gestione a pagina 64
l
Creare un amministratore di namespace a pagina 65
Viene infine illustrato come configurare un provider di autenticazione ed eseguire il
mapping di utenti di dominio a un namespace:
l
Aggiungere un provider di autenticazione a pagina 66
l
Mapping di utenti di dominio a un namespace a pagina 73
Informazioni su utenti e ruoli in ECS
ECS definisce vari tipi e ruoli di utenti per determinare l'accesso alle funzionalità di
gestione di ECS e all'object store.
I concetti principali relativi a utenti e ruoli sono descritti negli argomenti indicati di
seguito.
l
Utenti in ECS a pagina 56
l
Ruoli utente a pagina 58
l
Utenti locali e di dominio a pagina 58
l
Ambito utente: globale o namespace a pagina 59
Utenti in ECS
ECS richiede due tipi di utenti: utenti di gestione, che possono eseguire
l'amministrazione di ECS, e utenti di object, che accedono all'object store per leggere e
scrivere object e bucket mediante i protocolli di accesso ai dati supportati (S3, EMC
Atmos, OpenStack Swift e CAS).
Gli utenti di gestione possono accedere al portale ECS. Gli utenti di object non possono
accedere al portale ECS, ma possono accedere all'object store mediante i client che
supportano i protocolli di accesso ai dati di ECS.
Utenti di gestione e utenti di object vengono archiviati in tabelle distinte e dispongono di
credenziali diverse. Gli utenti di gestione richiedono un nome utente locale e una
password oppure un link a un account utente di dominio. Gli utenti object richiedono un
nome utente e una chiave segreta. È pertanto possibile creare un utente di gestione e un
utente object con lo stesso nome, ma si tratta di utenti differenti con credenziali diverse.
Inoltre, i nomi degli utenti di gestione e di object possono essere univoci nel sistema ECS
o all'interno di un namespace. Si tratta del cosiddetto ambito utente, descritto in: Ambito
utente: globale o namespace a pagina 59.
56
Nelle seguenti sezioni vengono forniti dettagli dei tipi di utenti supportati:
l
Utenti di gestione a pagina 57
l
Utenti di object a pagina 57
l
Utente root a pagina 57
Utenti di gestione
Gli utenti di gestione possono eseguire la configurazione e l'amministrazione del sistema
ECS e dei tenant configurati in ECS.
Gli utenti di gestione possono essere utenti locali con credenziali archiviate da ECS e
autenticate da ECS a fronte delle credenziali in locale oppure utenti di dominio definiti in
Active Directory (AD) o Lightweight Directory Access Protocol (LDAP) e autenticati a fronte
degli utenti inclusi in tali sistemi. Ulteriori informazioni su utenti di dominio e locali sono
disponibili in Utenti locali e di dominio a pagina 58.
Gli utenti di gestione non vengono replicati tra VDC con federazione geografica.
Utenti di object
Gli utenti di object sono utenti finali dell'object store ECS, a cui accedono tramite object
client mediante i protocolli di object supportati in ECS (S3, EMC Atmos, Openstack Swift
e CAS).
Gli utenti di object sono definiti tramite un nome utente e una chiave segreta utilizzabili
per accedere all'object store. I nomi utente possono essere nomi locali o in stile di
dominio con l'inclusione del simbolo "@".
Un utente di gestione può creare un account utente di object e può assegnare una chiave
segreta a tale account in fase di creazione o in qualsiasi altro momento. Se creata da un
utente di gestione, la chiave segreta degli utenti di object viene distribuita tramite email
o altri supporti.
Per gli utenti di dominio, una chiave segreta può essere ottenuta dall'utente di object
mediante la funzionalità self-service ECS, utilizzando un client che comunica con ECS
REST API (gli utenti di object non hanno accesso al portale ECS). Ulteriori informazioni
sugli utenti di dominio sono disponibili in: Utenti locali e di dominio a pagina 58ed è
possibile fare riferimento a Ricezione di una chiave segreta per l'accesso all'object
storage a pagina 156 per ottenere informazioni sulla creazione di una chiave segreta.
Tuttavia, gli utenti di object utilizzano credenziali ECS e non viene archiviato alcun link a
un account AD, pertanto ECS non verifica che il nome esista in AD o sia mappato al
namespace.
Gli utenti di object sono risorse globali. A un utente di object creato in un VDC possono
quindi essere assegnati privilegi di lettura e scrittura nei bucket e negli object, all'interno
del namespace a cui sono assegnati, da qualsiasi VDC.
Utente root
L'utente root è disponibile in fase di inizializzazione del sistema e viene preassegnato al
ruolo di System Admin.
È consigliabile utilizzare l'utente root solo per l'accesso iniziale al sistema. In questa
fase, la password dell'utente root deve essere modificata nella pagina Settings >
Password ed è consigliabile creare uno o più nuovi account System Admin.
Dal punto di vista dell'audit, è importante sapere quale utente ha apportato la modifica
al sistema, dunque non è opportuno utilizzare l'utente root e ciascun utente con ruolo di
System Admin deve disporre di un account personale.
Utenti in ECS
57
Ruoli utente
ECS definisce ruoli per determinare le operazioni eseguibili da un account utente nel
portale ECS o durante l'accesso a ECS mediante ECS Management REST API. Gli utenti di
gestione possono essere assegnati a ruoli di amministrazione in ECS e possono essere
utenti locali o di dominio.
Se un utente di gestione che è un utente di dominio deve essere assegnato al ruolo di
Namespace Admin, l'utente deve essere mappato al namespace.
Sono definiti i ruoli di gestione descritti di seguito.
l
System Administrator a pagina 58
l
Namespace Admin a pagina 58
System Administrator
Il ruolo di System Admin può configurare ECS e specificare lo storage utilizzato per
l'object store, la procedura di replica dello store, la modalità di configurazione
dell'accesso dei tenant all'object store e quali utenti dispongono di autorizzazioni a un
namespace assegnato.
Il System Admin può inoltre configurare namespace ed eseguirne l'amministrazione
oppure può assegnare un utente appartenente al namespace come Namespace Admin.
Il System Admin ha accesso al portale ECS ed è possibile eseguire le operazioni di
amministrazione del sistema anche da client programmatici mediante ECS Management
REST API.
Poiché gli utenti di gestione non vengono replicati nel sito, è necessario creare un System
Admin in ciascun VDC che ne richieda uno.
Se un utente di gestione che è un utente di dominio deve essere assegnato al ruolo di
Namespace Admin, l'utente deve essere mappato al namespace.
Namespace Admin
Il Namespace Admin è un utente di gestione che può accedere al portale ECS per
configurare le impostazioni dei namespace, tra cui quote e periodi di conservazione, e
può eseguire il mapping degli utenti di dominio al namespace e assegnare utenti locali
come utenti di object per il namespace. Le operazioni di un Namespace Admin possono
inoltre essere eseguite mediante ECS Management REST API.
Un Namespace Admin può essere amministratore di un solo namespace.
Poiché provider di autenticazione e namespace vengono replicati nei siti (sono risorse
globali di ECS), un utente di dominio con ruolo di Namespace Admin può effettuare il
login in qualsiasi sito ed eseguire operazioni di amministrazione dei namespace al suo
interno.
Gli account di gestione locali non vengono replicati nei siti, pertanto un utente locale con
ruolo di Namespace Admin può effettuare il login esclusivamente nel VDC in cui è stato
creato l'account dell'utente di gestione. Se si desidera utilizzare lo stesso nome utente in
un altro VDC, l'utente deve essere creato nel secondo VDC. Poiché si tratta di account
diversi, le modifiche apportate a un account in un VDC, ad esempio la modifica di una
password, non verranno propagate nell'account con lo stesso nome nel secondo VDC.
Utenti locali e di dominio
ECS fornisce supporto per utenti locali e di dominio.
58
Gli utenti locali sono account utente le cui credenziali sono archiviate in ECS. Utenti di
gestione e utenti di object possono essere definiti in locale in ECS. Nel caso degli utenti
di object le credenziali sono risorse globali disponibili in tutti i VDC ECS.
È più semplice scegliere utenti locali per iniziare a utilizzare ECS. L'uso di AD/LDAP
consente tuttavia di sfruttare un database di utenti esistenti e fornisce a un numero
elevato di utenti l'accesso all'object store senza dover creare account per loro.
Gli utenti di dominio sono definiti in un database Active Directory AD/LDAP e ECS deve
comunicare con il server AD o LDAP per autenticare la richiesta di login utente. ECS
utilizza un costrutto definito provider di autenticazione per fornire le credenziali
necessarie per comunicare con il server AD/LDAP e specificare i domini e i gruppi da
rendere disponibili per ECS.
Gli utenti di dominio sono definiti nel formato user@domain.com e ECS tenterà di
autenticare i nomi utente in tale formato mediante i provider di autenticazione
configurati. I nomi utente sprovvisti del simbolo @ verranno autenticati a fronte del
database di utenti locali.
Gli utenti di dominio assegnati a ruoli di gestione possono essere autenticati a fronte
delle relative credenziali AD/LDAP per consentirne l'accesso a ECS e l'esecuzione di
operazioni di amministrazione di ECS. Le operazioni di amministrazione possono essere
eseguite dal portale ECS o mediante ECS Management API.
Gli utenti di dominio possono inoltre essere assegnati come utenti di object. Per evitare
l'overhead amministrativo correlato alla creazione manuale di un numero elevato di
account utente di object in ECS, è disponibile una funzionalità self-service che consente
a ECS di autenticare utenti di dominio, aggiungerli automaticamente come utenti di
object e assegnarvi una chiave segreta.
A tale scopo, è necessario eseguire il mapping di un utente di dominio a un namespace e
ECS fornisce un meccanismo per il mapping di utenti di dominio a un namespace in base
all'appartenenza al dominio e al gruppo e agli attributi associati al relativo account.
Per un utente di object, ECS supporta nomi che includono il simbolo "@", pertanto è
possibile configurare utenti di object con nomi identici al nome di dominio. In questo
modo gli utenti possono accedere all'object store di ECS utilizzando un nome familiare.
Tuttavia, l'autenticazione utilizza una chiave segreta memorizzata in locale, non le
credenziali AD.
Se un utente di object è anche un utente di dominio ed è mappato a un namespace, è
possibile utilizzare ECS REST API per ottenere una nuova chiave segreta per l'accesso
all'object store di ECS mediante S3 API. Tale condizione viene definita funzionalità selfservice.
Ambito utente: globale o namespace
L'ambito degli utenti di object varia a seconda dell'ambito utente impostato.
L'impostazione influisce su tutti gli utenti in tutti i namespace di tutti i VDC federati
L'ambito utente può essere di tipo GLOBAL o NAMESPACE. Nell'ambito globale, i nomi
degli utenti di object sono univoci in tutti i VDC nel sistema ECS. Nell'ambito namespace,
i nomi degli utenti di object sono univoci all'interno di un namespace, pertanto in
namespace diversi possono esistere nomi di account di utenti di object uguali.
L'impostazione predefinita è GLOBAL. Se si intende utilizzare ECS in una configurazione
multi-tenant e si desidera verificare che ai tenant non venga impedito di utilizzare nomi
già esistenti in un altro namespace, è consigliabile modificare la configurazione
predefinita in NAMESPACE.
Ambito utente: globale o namespace
59
Nota
L'impostazione dell'ambito utente deve essere applicata precedentemente alla creazione
del primo utente di object.
Impostazione dell'ambito utente
L'ambito utente può essere impostato mediante l'API PUT /config/object/properties e
passando l'ambito utente nel payload. Di seguito è illustrato un esempio di payload che
imposta user_scope su NAMESPACE.
PUT /config/object/properties/
<property_update>
<properties>
<properties>
<entry>
<key>user_scope</key>
<value>NAMESPACE</value>
</entry>
</properties>
</property_update>
Attività con gli utenti nel portale ECS
Il portale ECS fornisce una pagina Manage > Users per consentire la creazione e
l'assegnazione di utenti locali come utenti di object per un namespace. Permette inoltre
ai System Administrator di creare utenti di gestione locali e assegnarli a ruoli di
amministrazione, nonché assegnare anche utenti di dominio a ruoli di amministrazione.
La pagina Manage > Users include due pagine secondarie:
l
Vista Object Users a pagina 60
l
Vista Management Users a pagina 61
La pagina Management è accessibile solo per gli utenti con ruolo di System Admin (o
utenti root) per ECS.
Vista Object Users
La vista Object Users visualizza una tabella Object Users in cui vengono elencati gli utenti
locali creati, il namespace a cui sono stati assegnati e le azioni eseguibili sull'utente.
Per gli utenti con ruolo di System Admin sono visibili gli utenti di object per tutti i
namespace. Per gli utenti con ruolo di Namespace Admin sono visibili esclusivamente gli
utenti appartenenti al proprio namespace.
Di seguito è illustrata la vista Object Users.
60
La tabella Object Users fornisce l'accesso alle informazioni e alle operazioni descritte di
seguito.
Attributo
Descrizione
Nome
Nome dell'utente.
Namespace
Namespace a cui è assegnato l'utente.
Azioni
Fornisce un menu di selezione per le azioni disponibili. Di seguito sono
indicate le azioni disponibili. Edit e Delete.
Il riquadro Object Users fornisce inoltre l'accesso ai controlli indicati di seguito.
Controllo
Descrizione
New Object User
Il pulsante New Object User consente l'aggiunta di un utente di object.
Vista Management Users
La vista Management Users include una tabella Management Users in cui vengono
elencati gli utenti di gestione creati e le azioni eseguibili sull'utente. Questa pagina è
visibile esclusivamente agli utenti con ruolo di System Admin.
Di seguito è illustrata la vista Management Users.
Attività con gli utenti nel portale ECS
61
La tabella Management Users fornisce l'accesso alle informazioni e alle operazioni
descritte di seguito.
Colonna
Descrizione
Nome
Nome dell'utente.
Azioni
La vista Management Users fornisce inoltre i comandi descritti di seguito.
Controllo
Descrizione
New Management User Il pulsante New Management User consente l'aggiunta di un utente di
gestione a cui può essere assegnato il ruolo di System Admin per ECS.
Aggiungere un nuovo utente di object
È possibile creare nuovi utenti locali e configurarli per l'utilizzo dei protocolli di accesso
agli object supportati. In seguito alla creazione, sarà possibile modificare una
configurazione utente aggiungendo o rimuovendo l'accesso a un protocollo di object
oppure creando una nuova chiave segreta per l'utente.
Prima di cominciare
l
l
l
l
Gli utenti che dispongono del ruolo di System Admin in ECS possono assegnare
utenti per qualsiasi namespace.
Gli utenti che dispongono del ruolo di Namespace Admin possono assegnare utenti
per i namespace di cui sono amministratori.
Per abilitare gli utenti di dominio come utenti di object, fare riferimento a Aggiungere
un utente di dominio come utente di object a pagina 63.
In fase di assegnazione di una password per un utente Swift, l'utente verrà aggiunto
al gruppo Swift Admin.
Nota
Non utilizzare il portale ECS per eseguire questa operazione se si desidera che gli
utenti vengano assegnati a gruppi Swift diversi.
62
È possibile fare riferimento a Attività con gli utenti nel portale ECS a pagina 60 per
informazioni sulla pagina Manage > Users.
Procedura
1. Nel portale ECS selezionare Manage > Users.
Per impostazione predefinita viene visualizzata la pagina Object Users, contenente la
tabella Object Users in cui vengono elencati gli utenti locali creati e il namespace a
cui sono assegnati.
2. Selezionare New Object User.
Verrà visualizzata la pagina New Object User.
3. Immettere il nome dell'utente.
Si tratta del nome per l'utente locale che verrà creato.
È possibile utilizzare nomi in stile di dominio che includono il simbolo "@". Ad
esempio, "some.name@emc.com". Si tratta tuttavia di una convenzione. Per
mantenere i nomi univoci e coerenti con i nomi AD, viene eseguita l'autenticazione
mediante una chiave segreta assegnata al nome utente, non tramite AD o LDAP.
4. Selezionare il namespace a cui verrà assegnato l'utente locale.
Una volta selezionato il namespace, sarà possibile salvare l'utente selezionando Save
e, in un secondo momento, modificarlo e assegnare una chiave segreta per l'accesso
a un protocollo di object. In alternativa, è possibile selezionare Add Passwords e
specificare password o chiavi segrete per l'accesso ai protocolli di object di ECS.
5. Per configurare chiavi segrete per l'utente, selezionare Add Passwords.
6. Per ciascun protocollo di object che si desidera utilizzare per accedere all'object store
di ECS, immettere o generare una chiave da utilizzare per l'accesso a S3, Swift o CAS e
salvarla.
Per salvare la chiave, selezionare Add Password.
7. Specificare una password per ciascuna interfaccia di object che si desidera rendere
accessibile all'utente.
Per S3 e CAS è possibile generare la password.
8. Chiavi segrete e password vengono salvate automaticamente ed è possibile fare clic
sul pulsante Close per tornare alla pagina Users.
Aggiungere un utente di dominio come utente di object
È possibile configurare utenti di dominio in modo che possano accedere a ECS e generare
chiavi segrete per loro. In tal modo, potranno aggiungersi come utenti di object.
Prima di cominciare
Procedura
1. Verificare che sia stato configurato un provider di autenticazione per la connessione
al sistema AD/LDAP appropriato.
L'aggiunta di un provider di autenticazione deve essere eseguita da un System Admin
ed è descritta in Aggiungere un provider di autenticazione a pagina 66.
2. Eseguire il mapping di utenti di dominio al namespace come descritto in Mapping di
utenti di dominio a un namespace a pagina 73.
Questa operazione può essere eseguita dal Namespace Admin.
Aggiungere un utente di dominio come utente di object
63
3. Consentire agli utenti di creare chiavi segrete seguendo le istruzioni in Ricezione di
una chiave segreta per l'accesso all'object storage a pagina 156.
Creare un utente di gestione locale o assegnare un utente di dominio a un ruolo di
gestione
È possibile aggiungere un utente di gestione locale e assegnare lo stesso tipo di utente
oppure un utente di dominio a un ruolo di gestione dal portale ECS. Gli utenti di gestione
sono necessari per eseguire l'amministrazione a livello di sistema (amministrazione di
VDC) e l'amministrazione di namespace. Se un utente non è più necessario per
l'esecuzione di operazioni di amministrazione, è possibile rimuovere l'assegnazione del
ruolo.
Prima di cominciare
l
Per creare un utente di gestione locale o assegnare un ruolo di gestione, è necessario
disporre del ruolo di System Admin.
l
L'utente root di ECS dispone del ruolo di System Admin per impostazione predefinita
e può eseguire l'assegnazione iniziale di un utente al ruolo di System Admin.
l
Per assegnare un utente di dominio a un ruolo di gestione, è in primo luogo
necessario verificare che sia stato aggiunto un provider di autenticazione. Vedere
Aggiungere un provider di autenticazione a pagina 66.
l
Per assegnare un ruolo di Namespace Admin, è necessario creare un utente di
gestione utilizzando l'operazione qui definita ed eseguire l'assegnazione del ruolo
nella pagina Namespace del portale (vedere Configurazione di un namespace per un
tenant a pagina 76). L'utente non potrà eseguire l'accesso finché non disporrà del
ruolo di Namespace Admin (o System Admin).
Procedura
1. Nel portale ECS selezionare Manage > Users.
Per impostazione predefinita viene visualizzata la pagina Object Users; è necessario
passare alla pagina Management Users.
2. Selezionare Management Users.
Viene visualizzata la pagina Management Users, che elenca eventuali utenti a cui sia
stato assegnato il ruolo e include un pulsante New Management User.
3. Selezionare New Management User.
Verrà visualizzata la pagina New Management User, che consente di creare un utente
locale e assegnare il nuovo utente al ruolo di gestione oppure assegnare un utente di
dominio al ruolo di gestione.
4. Selezionare Local User o AD/LDAP User.
Per un utente locale è necessario definire una password; per un utente di dominio, le
credenziali di nome utente e password utilizzate da ECS per autenticare un utente
sono memorizzate in AD/LDAP, pertanto non è necessario definire una password.
5. Immettere il nome dell'utente.
Se è stato selezionato AD/LDAP, l'utente deve essere presente e disponibile
attraverso l'aggiunta di un provider di autenticazione a ECS.
Se si seleziona un utente locale, verrà creato un nuovo utente di gestione locale
64
6. Se si desidera assegnare l'utente al ruolo di System Admin, selezionare Yes nel
selettore System Administrator.
Se si crea un utente di gestione che verrà assegnato al ruolo di Namespace Admin per
un namespace, mantenere l'impostazione No.
Se si seleziona Yes e in un secondo momento si desidera rimuovere i privilegi di
System Administrator dall'utente, sarà possibile modificare le impostazioni utente e
selezionare No.
7. Se non è stato selezionato System Admin poiché si intende assegnare l'utente al
ruolo di Namespace Admin, è necessario selezionare la casella "In order to log in,
non-System Admin users...".
In base alla casella "In order to log in, non-System Admin users...", l'utente non potrà
eseguire l'accesso finché non disporrà del ruolo di Namespace Admin.
8. Selezionare Save.
Creare un amministratore di namespace
È possibile assegnare un utente locale o di dominio come Namespace Admin.
Prima di cominciare
l
Per creare un utente di gestione e assegnare un utente al ruolo di Namespace Admin,
è necessario disporre del ruolo di System Admin.
Procedura
1. Per assegnare un utente di gestione locale al ruolo di Namespace Admin, è necessario
creare un utente di gestione come descritto in Creare un utente di gestione locale o
assegnare un utente di dominio a un ruolo di gestione a pagina 64.
Per assegnare un utente di dominio al ruolo di Namespace Admin, non è necessario
assegnare in modo esplicito l'utente a un ruolo di gestione.
2. Nella pagina Manage > Namespace effettuare le operazioni indicate di seguito.
a. Selezionare l'azione Edit per il namespace.
b. Aggiungere l'utente al campo Namespace Admin. In presenza di più di un
Namespace Admin, i nomi utente devono essere inclusi in un elenco separato da
virgole.
Un utente può essere assegnato come Namespace Admin per un singolo
namespace.
c. Salvare il namespace selezionando Salva.
Ulteriori informazioni sulla configurazione di un namespace sono disponibili in:
Configurazione di un namespace per un tenant a pagina 76.
Attività con i provider di autenticazione nel portale ECS
Il portale ECS fornisce una pagina Manage > Authentication per consentire l'aggiunta di
provider di autenticazione.
La pagina Authentication Provider è accessibile solo per gli utenti con ruolo di System
Admin (o utenti root) per ECS.
Creare un amministratore di namespace
65
La pagina Authentication Provider include la tabella Authentication Provider, in cui viene
elencato il provider di autenticazione creato. Di seguito è riportato un esempio.
La tabella fornisce l'accesso alle informazioni e alle operazioni descritte di seguito.
Attributo
Descrizione
Nome
Nome attribuito al provider di autenticazione.
Tipo
Indica se il provider di autenticazione è un server Active Directory (AD) o
Lightweight Directory Access Protocol (LDAP).
Domini
Domini a cui il provider di autenticazione fornisce l'accesso.
Enabled
Indica se il provider di autenticazione è al momento abilitato (Enabled) o
disabilitato (Disabled).
Azioni
La pagina Authentication Provider fornisce inoltre l'accesso ai controlli indicati di seguito.
Controllo
Descrizione
New Authentication
Provider
Il pulsante New Authentication Provider consente l'aggiunta di un
provider di autenticazione.
Aggiungere un provider di autenticazione
L'autenticazione utente per gli utenti di dominio viene eseguita mediante uno o più
provider di autenticazione aggiunti a ECS. Un provider di autenticazione è un costrutto
che consente a ECS di connettersi a un server AD/LDAP e identifica i domini e i gruppi che
AD/LDAP dovrà rendere disponibile per ECS.
Prima di cominciare
l
Per aggiungere un provider di autenticazione, è necessario disporre del ruolo di
System Admin in ECS. L'utente root dispone del ruolo di System Admin.
l
È necessario disporre dell'accesso alle informazioni del provider di autenticazione
elencate in Impostazioni del provider di autenticazione a pagina 67. Notare in
particolare i requisiti per l'utente Manager DN.
Procedura
1. Nel portale ECS selezionare Manage > Authentication > New Authentication Providers.
2. Immettere i valori per gli attributi. Fare riferimento a Impostazioni del provider di
autenticazione a pagina 67
66
3. Salvare.
4. Per verificare la configurazione, aggiungere un utente dal provider di autenticazione
da Manage > Users > Management Users, quindi provare a effettuare l'accesso come
nuovo utente.
Impostazioni del provider di autenticazione
È necessario fornire alcune informazioni durante l'aggiunta o la modifica di un provider di
autenticazione.
Tabella 6 Impostazioni del provider di autenticazione
Nome campo
Descrizione e requisiti
Nome
Il nome del provider di autenticazione. È possibile disporre di
più provider per domini diversi.
Descrizione
Descrizione con testo libero del provider di autenticazione.
Tipo
Active Directory o LDAP.
Domini
Active Directory e LDAP consentono agli amministratori di
organizzare object di una rete (quali utenti, computer e
dispositivi) in una raccolta gerarchica di contenitori.
I domini costituiscono una raccolta di object definiti a livello
amministrativo che condividono un database di directory
comune, policy di sicurezza e relazioni di trust con altri domini.
In questo modo, ogni dominio è una delimitazione
amministrativa per gli object. Un singolo dominio può
estendersi a più siti fisici o i siti e possono contenere milioni di
object.
Una tipica voce in questo campo del provider di autenticazione
ha il seguente aspetto:
mycompany.com
Se in Active Directory è configurato un suffisso UPN alternativo,
nell'elenco Domains deve essere presente anche l'UPN
alternativo configurato per il dominio. Se, ad esempio, si
aggiunge myco come suffisso UPN alternativo per
mycompany.com, l'elenco Domains conterrà sia myco sia
mycompany.com.
Server URLs
ldap o ldaps (LDAP sicuro) con l'indirizzo IP del controller di
dominio. La porta predefinita per ldap è 389 e quella per ldaps è
636.
Utilizzo: una o più
ldap://<IP controller di dominio>:<porta> (se diversa dalla porta
predefinita)
oppure
ldaps://<IP controller di dominio>:<porta> (se diversa dalla porta
predefinita)
Se il provider di autenticazione supporta una foresta
multidominio, utilizzare l'IP del server del catalogo globale e
67
Tabella 6 Impostazioni del provider di autenticazione (continua)
Nome campo
specificare sempre il numero di porta. Il valore predefinito è
3268 per ldap e 3269 per ldaps.
Utilizzo: ldap(s)://<IP del server del catalogo globale>:<porta>
Manager DN
Indica l'account utente Active Directory Bind che ECS utilizza per
connettersi al server Active Directory o LDAP. Questo account è
utilizzato per effettuare la ricerca in Active Directory quando un
amministratore ECS specifica, ad esempio, un utente per
l'assegnazione dei ruoli.
Requisito:
questo utente deve avere l'opzione Read all inetOrgPerson
information in Active Directory. La classe di object
InetOrgPerson è utilizzata in diversi servizi di directory non
Microsoft, Lightweight Directory Access Protocol (LDAP) e X.500
per rappresentare il personale di un'organizzazione.
Per impostare questo privilegio in Active Directory, aprire Active
Directory Users and Computers, fare clic con il pulsante destro
del mouse sul dominio e selezionare Delegate Control... . Fare
clic su Next, quindi selezionare l'utente utilizzato per
managerdn e fare clic su Next. Le autorizzazioni necessarie
sono visualizzate nella schermata successiva "Read all
inetOrgPerson information."
Esempio:
CN=Manager,CN=Users,DC=mydomaincontroller,DC=com
In questo esempio l'utente di Active Directory Bind è Manager,
nella struttura ad albero Users del dominio
mydomaincontroller.com. In genere managerdn è un utente che
dispone di un numero di privilegi inferiore rispetto a un
amministratore, ma sufficienti per eseguire in Active Directory
query relative agli attributi degli utenti e alle informazioni sul
gruppo.
AVVERTENZA
È necessario aggiornare questo valore in ECS in caso di modifica
delle credenziali managerdn in Active Directory.
Manager Password
La password dell'utente managerdn.
AVVERTENZA
È necessario aggiornare questo valore in ECS in caso di modifica
delle credenziali managerdn in Active Directory.
Provider
68
Selezionare Disabled se si desidera aggiungere il server a ECS
ma non utilizzarlo immediatamente per l'autenticazione.
Indipendentemente dal fatto che questa proprietà sia true, ECS
valida l'univocità del nome e del dominio del provider.
Nome campo
Group Attribute
Indica l'attributo di Active Directory utilizzato per identificare un
gruppo. Utilizzato per effettuare ricerche nella directory per
gruppi.
Esempio: CN
Solo Active Directory. Non si applica ad altri provider di
autenticazione.
Nota
Una volta impostato per un provider, questo valore non può
essere modificato perché i tenant che utilizzano questo provider
potrebbero già disporre di assegnazioni di ruolo e autorizzazioni
configurate utilizzando nomi di gruppo in un formato che usa
l'attributo corrente.
Group Whitelist
Opzionale. Uno o più nomi di gruppo definiti dal provider di
autenticazione. Questa impostazione filtrerà le informazioni di
appartenenza al gruppo che ECS recupera riguardo a un utente.
l
Quando uno o più gruppi sono inclusi in una whitelist,
significa che ECS riconoscerà l'appartenenza di un utente
solo al gruppo o ai gruppi specificati. Sono consentiti più
valori (uno per riga nel portale ECS, separati da virgola in
CLI e API) e caratteri jolly (ad esempio
MyGroup*,TopAdminUsers*).
l
Un valore vuoto (predefinito) significa che ECS riconoscerà
qualsiasi gruppo al quale appartiene un utente. L'asterico
(*) equivale al valore vuoto.
Esempio:
l'utente A appartiene al Gruppo 1 e al Gruppo 2.
Se la whitelist è vuota, ECS sa che
l'utente A è un membro del gruppo 1 e del gruppo 2.
Se la whitelist è "Gruppo 1", ECS
sa che l'utente A è un membro del Gruppo 1, ma non
sa che l'utente A è un membro del Gruppo 2 (o di qualsiasi altro
gruppo).
Prestare attenzione quando si aggiunge un valore di whitelist.
Se, ad esempio, lo user mapping a un tenant è basato
sull'appartenenza a un gruppo, ECS deve riconoscere
l'appartenenza dell'utente al gruppo.
Per limitare l'accesso a un namespace solo agli utenti di un
determinato gruppo o di determinati gruppi, è necessario:
l
Aggiungere tale gruppo o tali gruppi allo user mapping del
namespace (utilizzando il comando CLI viprcli tenant
add-group), in modo che il tenant sia configurato per
accettare solo utenti di tale gruppo o di tali gruppi.
69
Nome campo
l
Aggiungere questo gruppo o questi gruppi alla whitelist, in
modo che ECS sia autorizzato a ricevere le informazioni su
di essi.
Si noti che, per impostazione predefinita, se non vengono
aggiunti gruppi allo user mapping del tenant, vengono accettati
gli utenti di qualsiasi gruppo, indipendentemente dalla
configurazione della whitelist.
Solo Active Directory. Non si applica ad altri provider di
autenticazione.
Search Scope
Un livello (ricerca di utenti a un livello sotto la base di ricerca) o
una sottostruttura ad albero (ricerca dell'intera sottostruttura ad
albero sotto la base di ricerca).
Search Base
Indica il nome distinto di base che ECS utilizza per effettuare la
ricerca di utenti al momento del login e quando vengono
assegnati ruoli o si definiscono ACL.
Esempio: CN=Users,DC=mydomaincontroller,DC=com
In questo esempio viene eseguita la ricerca di tutti gli utenti nel
contenitore Users.
Esempio:
CN=Users,OU=myGroup,DC=mydomaincontroller,DC=com
In questo esempio viene eseguita la ricerca di tutti gli utenti nel
contenitore User dell'unità organizzativa myGroup.
Si noti che la struttura del valore della base di ricerca inizia con
il livello "leaf" e prosegue verso l'alto fino al livello del controller
di dominio, secondo una direzione opposta rispetto a quella
della struttura esaminata nella UI Utenti e computer di Active
Directory.
Search Filter
Indica la stringa utilizzata per selezionare i sottoinsiemi di
utenti. Esempio: userPrincipalName=%u
Nota
ECS non valida questo valore quando si aggiunge il provider di
autenticazione.
Se un suffisso UPN alternativo è configurato in Active Directory,
il valore Search Filter deve essere nel formato
sAMAccountName=%U, dove %U è il nome utente, e non
contenere il nome del dominio.
Questa impostazione non è
disponibile nella UI.
70
Valore che controlla il numero massimo di object restituiti in un
singolo risultato di ricerca. È indipendente dalla dimensione di
ciascun object restituito. Se viene specificato, deve essere
maggiore di 0. Non può essere superiore alla dimensione
massima della pagina configurata nel provider di
autenticazione.
Nome campo
(non applicabile)
Quando si utilizza il protocollo ldaps, SSL convalida il certificato
del provider di autenticazione. Il valore predefinito è false. Se
impostato su true, il protocollo LDAP deve disporre di un
certificato CA valido.
Considerazioni durante l'aggiunta dei provider di autenticazione
Quando si configura ECS per l'utilizzo con Active Directory, è necessario stabilire se
gestire diversi domini in un unico provider di autenticazione o aggiungere provider di
autenticazione distinti per ciascun dominio.
La decisione di aggiungere un unico provider di autenticazione, o più, dipende dal
numero di domini nell'ambiente e dalla posizione nella struttura ad albero da cui l'utente
responsabile può effettuare le ricerche. I provider di autenticazione sono dotati di una
singola search_base da cui vengono condotte le ricerche. Dispongono di un account
manager singolo che deve disporre dell'accesso in lettura al livello di search_base e
precedenti.
Utilizzare un singolo provider di autenticazione per più domini se si gestisce una foresta
di Active Directory e:
l
l'account del responsabile dispone di privilegi di ricerca sufficientemente elevati
nella struttura ad albero da consentire l'accesso a tutte le voci utente;
l
la ricerca verrà condotta nell'intera foresta da una singola base di ricerca e non nei
singoli domini elencati nel provider.
In caso contrario, configurare un provider di autenticazione per ciascun dominio.
Notare che anche se si gestisce una foresta e si dispone dei privilegi corretti, è possibile
non voler gestire tutti i domini con un unico provider di autenticazione. Si utilizzerà
ancora un provider di autenticazione per dominio quando è necessaria granularità e un
maggior controllo su ciascun dominio, specialmente per impostare il punto di partenza
della base di ricerca per la ricerca. Poiché esiste una sola base di ricerca per
configurazione, essa deve includere tutto ciò che viene definito nella configurazione in
modo che la ricerca possa funzionare.
La base di ricerca deve essere sufficientemente elevata nella struttura della directory
della foresta in modo che la ricerca possa trovare correttamente tutti gli utenti nei domini
di destinazione.
l
Se la foresta nella configurazione contiene dieci domini ma i domini di destinazione
sono solo tre, non utilizzare una singola configurazione del provider in quanto la
ricerca si estenderà inutilmente all'intera foresta e questo può influire sulle
prestazioni. In questo caso, utilizzare tre singole configurazioni.
l
Se la foresta nella configurazione contiene dieci domini e si desidera che i domini di
destinazione siano dieci, la scelta ideale è una configurazione globale poiché c'è
meno overhead da installare.
Considerazioni durante l'aggiunta dei provider di autenticazione
71
Caratteristiche principali del mapping degli utenti a un
namespace
È possibile aggiungere utenti di dominio a ECS mediante provider di autenticazione. Per
rendere disponibili gli utenti come utenti namespace, è necessario eseguirne il mapping
al namespace.
Il provider di autenticazione rende disponibili a ECS gli utenti appartenenti ai domini e ai
gruppi in whitelist specificati. Tali utenti possono essere assegnati a ruoli di sistema.
Per associare utenti a un namespace e renderli utenti di object idonei per il namespace, è
necessario associare il dominio di appartenenza dell'utente al namespace e, se
necessario, applicare un filtraggio più granulare in base ai gruppi appartenenti al
dominio e agli attributi assegnati agli utenti di dominio. Un dominio può essere mappato
a un singolo namespace o fornire utenti per più namespace.
Il portale ECS ed ECS Management REST API consentono di specificare mapping quando
viene registrato un nuovo namespace e forniscono supporto per l'aggiornamento dei
mapping per tutti i namespace. La creazione di un namespace è un'operazione che
richiede privilegi di System Admin; le operazioni di modifica di un tenant ed esecuzione
di user mapping possono essere effettuate da un Namespace Admin.
Gli user mapping assegnati a namespace diversi non devono sovrapporsi. Pertanto, se il
namespace Accounts esegue il mapping degli utenti dallo stesso dominio del namespace
HR, deve fornire ulteriori mapping per differenziare i suoi utenti. Nell'esempio riportato di
seguito, il namespace Accounts utilizza il dominio corp.sean.com ma esegue il mapping
di utenti con attributi specifici. In questo caso, si tratta di quelli con il relativo attributo
Department impostato su Accounts in Active Directory.
Figura 12 User mapping a un tenant con gli attributi AD
L'esempio riportato di seguito mostra l'utilizzo di più criteri di mapping. Verrà eseguito il
mapping al namespace di tutti i membri del dominio corp.sean.com appartenenti al
gruppo Storage Admins e con gli attributi Department e Company impostati
rispettivamente su Accounts e su Acme oppure appartenenti al gruppo Storage Admins e
con l'attributo Department impostato su Finance.
72
Figura 13 Utilizzo di più criteri di mapping
Mapping di utenti di dominio a un namespace
Il portaleECS consente di eseguire il mapping degli utenti a un namespace in base al
dominio AD/LDAP, ai gruppi e agli attributi associati agli utenti.
Prima di cominciare
l
Un provider di autenticazione deve essere registrato in ECS e fornire l'accesso al
dominio da cui si desidera eseguire il mapping degli utenti.
l
L'amministratore di AD deve aver configurato i gruppi o gli utenti in AD prima di
eseguire il mapping degli utenti dal portale ECS.
l
Se si utilizza il mapping degli attributi, ogni utente deve disporre del valore di
attributo appropriato impostato in AD.
È consigliabile apprendere i concetti associati allo user mapping, descritti in
Caratteristiche principali del mapping degli utenti a un namespace a pagina 72.
Mapping di utenti di dominio a un namespace
73
Procedura
1. Nel portaleECS selezionare Manage > Namespace.
2. Nella tabella Namespaces fare clic sull'azione Edit del namespace per aprirlo e
modificarlo.
3. Se non è stato già specificato un dominio, fare clic su Add per aggiungere un mapping
e immettere il nome di dominio nel campo Domain.
4. Specificare i gruppi che si intende utilizzare per il mapping degli utenti al namespace.
Il gruppo o i gruppi specificati devono esistere in AD.
5. Se si desidera utilizzare attributi per il mapping degli utenti al namespace, immettere
il nome e uno o più valori per l'attributo. Se non si desidera utilizzare attributi per il
mapping degli utenti al namespace, fare clic sul pulsante di eliminazione per
rimuovere i campi dell'attributo dal mapping corrente.
Ai fini del mapping degli utenti al dominio, il set di valori di attributo per l'utente deve
corrispondere al valore di attributo specificato in ECS.
6. Fare clic su Save per salvare le impostazioni del namespace.
74
CAPITOLO 8
l
l
l
l
l
Introduzione..........................................................................................................76
Informazioni sui tenant......................................................................................... 76
Informazioni sulle impostazioni dei namespace.................................................... 77
Attività con i namespace nel portale ECS............................................................... 78
Creazione e configurazione di un namespace........................................................ 78
75
Introduzione
I namespace forniscono il meccanismo in base al quale più tenant possono accedere
all'object store di ECS e garantiscono che gli object e i bucket scritti dagli utenti di un
tenant siano isolati dagli utenti di altri tenant.
In questo articolo vengono introdotti alcuni concetti relativi ai tenant e alle impostazioni
dei namespace:
l
Informazioni sui tenant a pagina 76
l
Informazioni sulle impostazioni dei namespace a pagina 77
l
Attività con i namespace nel portale ECS a pagina 78
Vengono inoltre descritte le operazioni necessarie per configurare un namespace
mediante il portale ECS:
l
Creazione e configurazione di un namespace a pagina 78
Sebbene per le operazioni di configurazione descritte in questo articolo venga fatto
riferimento al portale ECS, i concetti descritti in Informazioni sui tenant a pagina 76 e
Informazioni sulle impostazioni dei namespace a pagina 77 si applicano
indipendentemente dal fatto che si usi il portale o l'API REST.
Informazioni sui tenant
ECS supporta l'accesso multi-tenant, in cui ciascun tenant è definito da un namespace e
il namespace dispone di un set di utenti configurati che possono archiviare e accedere
agli object all'interno del namespace.
I namespace sono risorse globali in ECS e un System Admin o un Namespace Admin che
accede a ECS in qualsiasi VDC federato può configurarne le impostazioni. Inoltre, gli
utenti di object assegnati a un namespace sono globali e possono accedere all'object
store da qualsiasi VDC federato.
La caratteristica principale di un namespace consiste nel fatto che gli utenti di un
namespace non possono accedere agli object appartenenti a un altro. Inoltre, ECS
consente a un'azienda di configurare namespace e monitorarne e misurarne l'utilizzo e
permette di concedere al tenant diritti di gestione, in modo che possa eseguire
operazioni di configurazione, monitoraggio e misurazione.
È inoltre possibile utilizzare bucket per creare subtenant. Il proprietario dei bucket è
l'amministratore del subtenant e può assegnare utenti al subtenant mediante ACL.
Tuttavia, i subtenant non forniscono lo stesso livello di isolamento dei tenant; a qualsiasi
utente appartenente al tenant potrebbero essere assegnati privilegi su un subtenant. È
pertanto necessario prestare attenzione in fase di assegnazione di utenti.
Sono supportati gli scenari indicati di seguito.
Enterprise con singolo tenant
Tutti gli utenti accedono a bucket e object nello stesso namespace. È possibile
creare subtenant (bucket) per consentire a un subset di utenti di namespace di
accedere allo stesso set di object. Un subtenant può essere un dipartimento
all'interno dell'azienda.
Enterprise multi-tenant
Dipartimenti diversi all'interno di un'organizzazione vengono assegnati a
namespace diversi e a ciascun namespace vengono assegnati utenti di
dipartimento.
76
Cloud service provider con singolo tenant
Viene configurato un singolo namespace e il service provider fornisce l'accesso
all'object store per gli utenti all'interno o all'esterno dell'azienda.
Cloud service provider multi-tenant
Il service provider assegna namespace ad aziende diverse e un amministratore per il
namespace. L'amministratore del namespace per il tenant può quindi aggiungere
utenti e monitorare e misurare l'uso di bucket e object.
Le funzionalità fornite per consentire la gestione dei tenant sono descritte in Gestione di
un tenant a pagina 84.
Ciascun tenant può accedere ai gruppi di replica resi disponibili dal System Admin. A
seconda dei modelli di accesso di un tenant, può richiedere gruppi di replica che
includono siti in specifiche aree geografiche. Se ad esempio un client tenant si trova in
Cina, potrebbe preferire accedere a gruppi di replica che includono VDC situati in Cina.
Informazioni sulle impostazioni dei namespace
Un namespace fornisce un meccanismo in base al quale è possibile isolare object e
bucket in modo che un object in un namespace possa avere lo stesso nome di un object
in un altro. ECS è sempre in grado di distinguere l'object richiesto dal qualificatore del
namespace. Il namespace viene inoltre configurato con attributi che definiscono gli
utenti che possono accedere al namespace e le caratteristiche del namespace. Un
namespace ECS può essere considerato come un tenant.
Gli utenti con privilegi appropriati possono creare bucket, e object al loro interno, nel
namespace.
Il modo in cui i nomi di namespace e bucket vengono utilizzati in fase di indirizzamento
di object in ECS è descritto in Indirizzamento di object storage ECS e utilizzo dell'URL di
base a pagina 134.
Un namespace ECS è caratterizzato dai seguenti attributi:
Gruppo di replica predefinito
Il gruppo di replica in cui un bucket verrà creato se non ne è specificato uno in una
richiesta. Ulteriori informazioni sulla configurazione di gruppi di replica sono
disponibili in Configurazione di storage pool, VDC e gruppi di replica a pagina 48
Amministratori di namespace
Utenti assegnati al ruolo di Namespace Admin per il namespace. Il Namespace
Admin è un utente di gestione di ECS e può essere un utente locale o di dominio.
User mapping
I domini, i gruppi e gli attributi che identificano gli utenti che possono essere
assegnati come utenti di object per un namespace. Il modo in cui gli utenti vengono
aggiunti a ECS e mappati a uno specifico namespace è descritto in Aggiunta di utenti
e assegnazione di ruoli a pagina 56.
Gruppi di replica consentiti (e non consentiti)
ECS Management REST API consente a un client di specificare quali gruppi di replica
possono essere utilizzati dal namespace. Non è disponibile dal portale ECS.
È inoltre possibile specificare policy di conservazione e una quota per il namespace.
Ulteriori informazioni sull'utilizzo di queste funzionalità sono disponibili in Gestione di
un tenant a pagina 84.
Informazioni sulle impostazioni dei namespace
77
Quota
Se abilitata, una dimensione di quota impostata sul namespace può determinare il
logging di un evento (quota flessibile) o il blocco dell'accesso (quota rigida) al
raggiungimento di un limite di storage specificato.
A un namespace possono essere associate varie policy di conservazione, in cui
ciascuna policy definisce un periodo di conservazione. Applicando una policy di
conservazione a un numero di object, una modifica nella policy di conservazione
determinerà un cambiamento nel periodo di conservazione per il set completo di
object a cui è stata applicata la policy. Non è consentita una richiesta di modifica di
object precedente alla scadenza del periodo di conservazione.
Attività con i namespace nel portale ECS
La pagina del portale dei namespace, Manage > Namespace, consente di creare
namespace e fornisce una tabella in cui sono elencati i namespace esistenti, che
possono essere modificati.
Figura 14 Pagina di gestione dei namespace
La tabella dei namespace include i seguenti campi:
Campo
Descrizione
Nome
Nome del namespace.
Quota
Quota, se disponibile, assegnata al namespace.
Replication Group Gruppo di replica predefinito per il namespace.
Notification Quota Limite della quota in cui viene generata una notifica.
Max Quota
Limite della quota in cui verranno bloccate le scritture nel namespace.
Azioni
Azioni eseguibili sul namespace. Sono disponibili le azioni Edit e Delete.
Creazione e configurazione di un namespace
È possibile creare un nuovo namespace o modificare la configurazione di un namespace
esistente nella pagina Manage > Namespace.
78
Prima di cominciare
l
Per eseguire questa operazione, è necessario disporre del ruolo di System Admin in
ECS.
l
Deve esistere un gruppo di replica. Il gruppo di replica fornisce l'accesso agli storage
pool in cui sono archiviati i dati degli object.
l
Per consentire agli utenti di dominio di accedere al namespace, è necessario aver
aggiunto un provider di autenticazione a ECS. Inoltre, se si intende configurare utenti
di object di dominio, è opportuno decidere la procedura in base alla quale eseguire il
mapping degli utenti al namespace. Per ulteriori informazioni sul mapping degli
utenti, è possibile fare riferimento a Aggiunta di utenti e assegnazione di ruoli a
pagina 56.
Accertarsi di aver acquisito dimestichezza con le informazioni generali sui namespace
fornite in Informazioni sulle impostazioni dei namespace a pagina 77.
Procedura
2. Per creare un nuovo namespace, selezionare New Namespace. Per modificare la
configurazione di un namespace esistente, scegliere l'azione Edit associata al
namespace esistente.
3. Specificare il valore appropriato per ciascun campo.
Nella tabella riportata di seguito vengono fornite indicazioni sulle impostazioni per
ciascun campo.
Campo
Descrizione
Nome
Nome del namespace. Il nome deve essere inserito in caratteri minuscoli.
Una volta creato il nome, non sarà possibile modificarlo.
Admin
ID di uno o più utenti che si desidera assegnare al ruolo di Namespace
Admin; separare più utenti con una virgola.
I Namespace Admin possono essere utenti locali o di dominio. Se si desidera
rendere il Namespace Admin un utente di dominio, sarà necessario verificare
di aggiungere un provider di autenticazione a ECS. Fare riferimento a
Aggiunta di utenti e assegnazione di ruoli a pagina 56 per informazioni
dettagliate.
Replication Group
Gruppo di replica predefinito per il namespace.
Quota
Questo controllo consente di abilitare una quota e specificare il
comportamento quando viene raggiunta.
Vedere il passaggio 4 a pagina 80
Policy di
conservazione
Consente di aggiungere e configurare una o più policy di conservazione.
È possibile modificare, disabilitare o eliminare le policy di conservazione
esistenti.
Dominio
Consente di specificare i domini AD/LDAP e di configurare le regole per
includere utenti dal dominio.
Gli utenti appartenenti al dominio possono pertanto utilizzare la funzionalità
self-service di ECS per registrarsi come utenti di object.
Creazione e configurazione di un namespace
79
4. Abilitare e configurare una quota.
a. Impostare il controllo della quota su Enabled se si desidera impostare una quota
per il namespace.
b. Scegliere Notification Only o Block Access
Se si sceglie di bloccare l'accesso al raggiungimento di un limite di storage
specificato, è inoltre possibile specificare una percentuale del limite in cui verrà
inviata una notifica.
5. Aggiungere e configurare policy di conservazione.
a. Nell'area Retention Policies selezionare Add per aggiungere una nuova policy.
b. Immettere un nome per la policy.
c. Specificare il periodo per la policy di conservazione.
È possibile specificare un valore in minuti oppure selezionare la casella di
controllo Infinite per indicare che i bucket a cui è assegnata questa policy di
conservazione non vengano mai eliminati.
6. Specificare un dominio AD/LDAP i cui utenti possano effettuare il login a ECS ed
eseguire attività amministrative per il namespace.
Immettere il nome del dominio e specificare gruppi e attributi per fornire un livello di
controllo più granulare sugli utenti del dominio che potranno accedere a ECS nel
namespace corrente.
Per eseguire mapping più complessi mediante gruppi e attributi, è consigliabile fare
riferimento a Aggiunta di utenti e assegnazione di ruoli a pagina 56
80
CAPITOLO 9
Acquisizione e caricamento di un file di licenza
nel portale ECS
l
l
Licenze..................................................................................................................82
Acquisizione del file di licenza di EMC ECS............................................................ 82
81
Licenze
Le licenze EMC ECS vengono concesse in base alla capacità.
È necessario ottenere almeno una licenza ECS e caricarla nell'appliance.
Nella pagina Settings > License vengono forniti maggiori dettagli.
Acquisizione del file di licenza di EMC ECS
È necessario ottenere il file di licenza (.lic) dal sito web di gestione delle licenze EMC per
caricarlo in ECS.
Prima di cominciare
Per ottenere il file di licenza è necessario disporre del codice LAC (License Authorization
Code), inviato per email da EMC.
Procedura
1. Visitare la pagina support.EMC.com
2. Selezionare Support > Service Center.
3. Selezionare Get and Manage Licenses.
4. Selezionare ECS dall'elenco dei prodotti.
5. Nella pagina della richiesta LAC, immettere il codice LAC e attivarlo.
6. Selezionare le autorizzazioni da attivare e avviare il processo di attivazione.
7. Selezionare Add a Machine e specificare una stringa descrittiva per il raggruppamento
di licenze.
Non è necessario inserire il nome del computer, è sufficiente una stringa per tenere
facilmente traccia delle licenze.
8. Immettere le quantità da attivare per ogni autorizzazione o selezionare Activate All.
Fare clic su Next.
Se si ricevono licenze per una configurazione multisito (geo), è necessario distribuire i
controller in modo appropriato per ottenere i singoli file di licenza per ogni data center
virtuale.
9. In via opzionale, specificare un destinatario per ricevere un'email di riepilogo della
transazione di attivazione.
10.Fare clic su End.
11.Fare clic su Save to File per salvare il file di licenza (.lic) in una cartella del computer.
Il file di licenza è necessario durante la configurazione iniziale di ECS o in un secondo
momento per l'aggiunta di una nuova licenza nel portale ECS (Settings > Licensing).
12.Nel portale ECS selezionare Settings > Licensing.
13.Selezionare Choose File, il file di licenza e quindi Upload.
Verrà aggiornata la visualizzazione della licenza.
82
CAPITOLO 10
l
l
l
l
l
l
Introduzione..........................................................................................................84
Quote....................................................................................................................84
Periodi e policy di conservazione.......................................................................... 85
Blocco di bucket e utenti....................................................................................... 86
Misurazione.......................................................................................................... 87
Audit di bucket......................................................................................................89
83
Introduzione
ECS fornisce una serie di funzionalità per supportare la gestione di un tenant.
Sono supportate le funzionalità indicate di seguito.
Utenti
La capacità di assegnare un Namespace Admin per il namespace e di creare utenti di
object per il namespace è descritta in Aggiunta di utenti e assegnazione di ruoli a
pagina 56.
Quote
La capacità di impostare quote su namespace e bucket è descritta in Quote a pagina
84.
Periodi di conservazione
La capacità di creare policy di conservazione è descritta in Periodi e policy di
conservazione a pagina 85.
La capacità di bloccare bucket e utenti è descritta in Blocco di bucket e utenti a
pagina 86.
Misurazione
La capacità di misurare la scrittura di dati in bucket e namespace è descritta in
Misurazione a pagina 87.
Audit di bucket
La capacità di eseguire l'audit delle operazioni associate ai bucket è descritta in
Audit di bucket a pagina 89.
Quote
È possibile impostare quote rigide e flessibili in un namespace e nei bucket creati al suo
interno.
Le quote flessibili determinano il logging degli eventi, per segnalare il raggiungimento
della quota. Le quote rigide forniscono un limite sulla quantità di object storage
utilizzabile per un bucket o un namespace: una volta raggiunto il limite, l'accesso al
bucket o al namespace verrà bloccato.
Le quote possono essere impostate dal portale ECS oppure mediante l'API e la CLI.
Impostazione di quote dal portale
È possibile impostare quote per un namespace dalla pagina Manage > Namespace, come
descritto in Configurazione di un namespace per un tenant a pagina 76.
Le quote per un bucket vengono impostate dalla pagina Manage > Bucket, come descritto
in Creazione e configurazione di bucket a pagina 140 .
Impostazione di quote mediante API
I seguenti percorsi API consentono di impostare quote:
84
Metodologia
Descrizione
PUT/GET/DELETE /object/namespaces/
namespace/{namespace}/quota
Imposta la quota per un namespace. Il payload
specifica quote rigide e flessibili.
Metodologia
Descrizione
PUT/GET/DELETE /object/bucket/
{bucketName}/quota
Imposta la quota per un bucket. Il payload
specifica quote rigide e flessibili.
Ulteriori informazioni su ECS Management REST API sono disponibili in: Utilizzo di ECS
Management REST API a pagina 256 e il riferimento online è disponibile qui.
Periodi e policy di conservazione
ECS consente di impedire la modifica di dati entro un periodo di conservazione
specificato.
I periodi di conservazione possono essere definiti nei metadati associati a object e
bucket e vengono controllati a ogni richiesta di modifica di un object. I periodi di
conservazione sono supportati in tutte le interfacce di object S3, Swift, Atmos e CAS.
Tuttavia, i dati CAS sono immutabili, pertanto il periodo di conservazione applicato a CAS
si riferisce alla capacità di eliminare object CAS.
Mentre è possibile impostare il periodo di conservazione per un bucket nel portale ECS,
la relativa assegnazione, o policy, a un object deve essere eseguita mediante l'interfaccia
dell'object.
È possibile definire la conservazione in due modi: periodi di conservazione e policy di
conservazione.
I periodi di conservazione vengono assegnati a livello di object o bucket. Quando un
periodo di conservazione viene assegnato a un bucket, ogni volta che si tenta di
modificare un object in un bucket viene controllato il relativo periodo e viene calcolata
un'ora di scadenza.
Un esempio è costituito da un documento finanziario che deve essere conservato per 3
anni dalla data di creazione. È inoltre possibile specificare che l'object venga conservato
a tempo indeterminato.
Le policy di conservazione consentono l'acquisizione di use case di conservazione e
l'applicazione a object. Ad esempio, tipi diversi di documenti possono avere periodi di
conservazione differenti. Potrebbero essere richiesti i seguenti periodi di conservazione:
l
Documenti finanziari - 3 anni
l
Documenti legali - 5 anni
l
Email - 6 mesi
Se una policy di conservazione viene applicata a una serie di object, modificando la
policy può essere modificato il periodo di conservazione di tutti gli object associati.
Come creare policy di conservazione
Per configurare le policy di conservazione disponibili per il namespace dal portale ECS,
fare riferimento a:
Configurazione di un namespace per un tenant a pagina 76
In alternativa, è possibile crearle mediante ECS Management REST API, di cui viene
fornito un riepilogo di seguito.
Periodi e policy di conservazione
85
Metodologia
Descrizione
PUT /object/bucket/{bucketName}/retention
Il valore di conservazione di un bucket
definisce un periodo di conservazione
predefinito applicato a ogni object in un
bucket. Se pertanto si imposta un periodo di
conservazione di 1 anno, non sarà possibile
eliminare un object dal bucket per un anno.
GET /object/bucket/{bucketName}/retention
Restituisce il periodo di conservazione
attualmente impostato per un bucket
specificato.
POST /object/namespaces/namespace/
{namespace}/retention
Per i namespace, l'impostazione della
conservazione opera come una policy, dove
ciascuna policy è costituita da una coppia
<Name>: <Retention period>. È possibile definire
un numero di policy di conservazione per un
namespace e assegnare una policy per nome a
un object nel namespace. In questo modo è
possibile modificare il periodo di conservazione
di un set di object con la stessa policy
assegnata modificando la policy
corrispondente.
PUT /object/namespaces/namespace/
{namespace}/retention/{class}
Aggiorna il periodo di una classe di
conservazione associata a un namespace.
GET /object/namespaces/namespace/
Restituisce le classi di conservazione definite
per un namespace.
Le informazioni su come accedere a ECS Management REST API sono descritte nel
seguente articolo: Utilizzo di ECS Management REST API a pagina 256 e il riferimento
online è disponibile qui.
Come applicare periodi e policy di conservazione
È possibile applicare periodi di conservazione ai bucket nel portale ECS.
Quando si creano object o bucket mediante i protocolli di object service, ad esempio se
si crea un bucket S3 mediante un client che supporta il protocollo S3, è possibile
applicare il periodo di conservazione o la policy di conservazione tramite intestazioni xems.
In fase di creazione di object è possibile applicare le seguenti intestazioni per il periodo
di conservazione e la policy di conservazione:
l
x-emc-retention-period
l
x-emc-retention-policy
In fase di creazione di un bucket è possibile impostare il periodo di conservazione
tramite l'intestazione x-emc-retention-period.
ECS consente di impedire l'accesso a un bucket e l'accesso utenti.
Il supporto per le operazioni di blocco di bucket e utenti è disponibile in ECS
Management REST API. Non è previsto il supporto per il blocco di bucket e utenti nel
portale ECS. Sono supportate le chiamate riportate di seguito.
86
Metodologia
Descrizione
PUT /object/bucket/{bucketName}/lock
Blocca un bucket e non consente scritture al
suo interno.
DELETE /object/bucket/{bucketName}/lock
Sblocca un bucket e consente nuovamente
scritture al suo interno.
PUT /object/users/{userid}/lock
Blocca un utente di object (non AD). Tutte le
successive operazioni API eseguite dall'utente
restituiranno un errore.
DELETE /object/user/{userid}/lock
Sblocca un utente di object (non AD). L'utente
sarà nuovamente in grado di eseguire ulteriori
operazioni API.
Le informazioni su come accedere a ECS Management REST API sono descritte nel
seguente articolo: Utilizzo di ECS Management REST API a pagina 256 e il riferimento
online è disponibile qui.
Misurazione
ECS fornisce supporto per la misurazione dell'utilizzo dell'object storage a livello di
namespace e bucket.
Misurazione mediante il portale
È possibile utilizzare il portale ECS per monitorare l'utilizzo del namespace e dei bucket.
La pagina Monitor > Metering consente la selezione di un namespace o di uno specifico
bucket al suo interno e la visualizzazione dei relativi dati di misurazione.
Tabella 7 Misurazione di bucket e namespace
Attributo
Descrizione
Spazio totale (GB)
Dimensione totale degli object archiviati nel namespace o nel
bucket selezionato.
Conteggio oggetti
Numero di object associati al namespace o al bucket
selezionato al termine dell'ora specificata nel filtro.
Objects Created
Numero di object creati nel namespace o nel bucket selezionato
nel periodo di tempo.
Objects Deleted
Numero di object eliminati dal namespace o dal bucket
selezionato nel periodo di tempo.
Bandwidth Ingress (MB)
Totale di dati di object in entrata (scritture) per il namespace o il
bucket selezionato durante il periodo specificato.
Bandwidth Egress (MB)
Totale di dati di object in uscita (letture) per il namespace o il
Misurazione
87
Nota
I dati di misurazione non sono immediatamente disponibili, in quanto potrebbe essere
necessario molto tempo per raccogliere le statistiche per i dati aggiunti al sistema ed
eliminati da esso.
Per ulteriori informazioni su come accedere a questi dettagli, fare riferimento a
Monitoraggio dello storage: misurazione e capacità a pagina 106.
Misurazione mediante l'API
I seguenti percorsi API consentono di eseguire il retrieval delle informazioni di
misurazione:
Metodologia
Descrizione
GET /object/billing/buckets/{namespace}/
{bucket}/info?sizeunit=<KB|MB|GB>
Ottiene l'utilizzo corrente di un bucket in un
namespace specificato.
GET /object/billing//buckets/{namespace}/
{bucket}/sample?
start_time=<ISO8061_format>&end_time=<ISO8
061_format>&marker=<string_marker>
&sizeunit=<KB|MB|GB>
Campiona l'attività di un bucket per il periodo
di tempo specificato. Per impostazione
predefinita, la risoluzione campione minima di
un bucket è 5 minuti e i campioni verranno
conservati per 30 giorni. Se l'ora di inizio e di
fine non rientrano nei limiti del campione, verrà
restituito un errore. Se l'intervallo di tempo si
estende a più campioni di livello inferiore, i dati
verranno aggregati per il periodo al fine di
produrre un data point.
GET /object/billing/namespace/
Ottiene le informazioni di utilizzo per tutti i
{namespace_name}/info?
bucket in un namespace.
marker=<string_marker>&include_bucket_detail
Nota
=<true|false>&sizeunit=<KB|MB|GB>
Quando sono inclusi i dettagli del bucket, la
dimensione totale sul disco potrebbe essere
diversa rispetto a quella senza dettagli. Ciò è
dovuto all'arrotondamento delle dimensioni del
bucket, che vanno a sommarsi per fornire la
dimensione totale.
GET /object/billing/namespace/
{namespace_name}/sample?
start_time=<ISO8061_format>&end_time=<ISO8
061_format>&marker=<string_marker>
&include_bucket_detail=<true|
false>&sizeunit=<KB|MB|GB>
Ottiene una snapshot per un particolare
campione di tempo per un namespace. Per
impostazione predefinita, bucket e namespace
verranno campionati ogni 5 minuti e i campioni
verranno conservati per 30 giorni. Se l'ora di
inizio e di fine non rientrano nei limiti del
campione, verrà restituito un errore. Se
l'intervallo di tempo si estende a più campioni
di livello inferiore, i dati verranno aggregati per
il periodo al fine di produrre un data point.
88
Audit di bucket
L'API del controller consente di eseguire l'audit dell'utilizzo delle interfacce di object S3,
EMC Atmos e OpenStack Swift.
Viene eseguito il logging delle seguenti operazioni sugli object container (bucket S3,
subtenant EMC Atmos e container OpenStack Swift).
l
Creazione di bucket
l
Delete Bucket
l
Aggiornamento di bucket
l
Impostazione di ACL di bucket
l
Modifica del proprietario di un bucket
l
Impostazione del bucket versioning
l
Impostazione dell'origine del bucket versioning
l
Impostazione dei metadati dei bucket
l
Impostazione dei metadati dei bucket head
l
Impostazione della policy di scadenza di un bucket
l
Eliminazione della policy di scadenza di un bucket
l
Impostazione della configurazione Cors dei bucket
l
Eliminazione della configurazione Cors dei bucket
Generazione di audit log nel portale
È possibile utilizzare la pagina Monitor > Events del portale per rilevare la generazione di
un evento di audit log.
È consigliabile utilizzare l'utente root solo per l'accesso iniziale al sistema. In questa
fase, la password dell'utente root deve essere modificata nella pagina Settings >
Password ed è consigliabile creare uno o più nuovi account System Admin. Dal punto di
vista dell'audit, è importante sapere quale utente ha apportato la modifica al sistema,
dunque non è opportuno utilizzare l'utente root e ciascun utente con ruolo di System
Admin deve disporre di un account personale.
Per ulteriori informazioni sull'utilizzo del log eventi, è possibile fare riferimento a
Monitoraggio degli eventi: portale di audit, API, alert di sistema ed eventi CLI a pagina
128.
API di audit
Il supporto per bucket audit viene fornito dalle seguenti chiamate ECS Management REST
API:
Metodologia
Descrizione
GET /monitoring/events
Recupera gli eventi di audit per un namespace
e un intervallo di tempo specificati.
Audit di bucket
89
90
CAPITOLO 11
l
Eseguire il failover di un sito/eliminare un VDC..................................................... 92
91
Eseguire il failover di un sito/eliminare un VDC
Utilizzare questa procedura per eliminare un VDC. L'eliminazione di un VDC avvia il
failover del sito quando il VDC in questione fa parte di una federazione multisito.
Se si verifica una situazione di emergenza, un intero VDC potrebbe non essere più
recuperabile. ECS tratta inizialmente il VDC irrecuperabile come guasto del sito
temporaneo. Se il guasto è permanente, è necessario rimuovere il VDC dalla federazione
per avviare l'elaborazione del failover che ricrea e protegge nuovamente gli object
archiviati nel VDC che presenta il problema. Le attività di ripristino vengono eseguite in
background. Per controllare il processo di ripristino, utilizzare Monitor > Geo Replication >
Failover Procesing.
Procedura
1. Accedere a uno dei VDC operativi nella federazione.
2. Passare a Manage > Replication Group.
3. Fare clic su Edit per il gruppo di replica contenente il VDC da eliminare.
4. Fare clic su Delete nella riga contenente il VDC e lo storage pool da rimuovere.
6. Passare a Manage > VDC. Lo stato del VDC rimosso in modo definitivo cambia in
Permanently failed.
7. Selezionare Delete dall'elenco a discesa nella riga del VDC da rimuovere.
92
PARTE 5
Monitor
Capitolo 12, "Monitoraggio di risorse: hardware, traffico di rete, larghezza di banda del
disco, integrità di nodi e processi"
Capitolo 13, "Monitoraggio dello storage: misurazione e capacità"
Capitolo 14, "Monitoraggio dei log di servizio"
Capitolo 15, "Monitoraggio dei servizi: blocchi, codici di cancellazione, replica
geografica e stato di ripristino"
Capitolo 16, "Monitoraggio degli eventi: portale di audit, API, alert di sistema ed eventi
CLI"
Monitor
93
Monitor
94
CAPITOLO 12
Monitoraggio di risorse: hardware, traffico di rete,
larghezza di banda del disco, integrità di nodi e
processi
l
l
l
l
l
l
Informazioni sul monitoraggio delle risorse........................................................... 96
Utilizzo di pagine di monitoraggio......................................................................... 96
Monitoraggio hardware......................................................................................... 98
Monitoraggio del traffico di rete.............................................................................99
Monitoraggio della larghezza di banda del disco.................................................101
Monitoraggio dell'integrità di nodi e processi......................................................102
Monitoraggio di risorse: hardware, traffico di rete, larghezza di banda del disco, integrità di nodi e processi
95
Informazioni sul monitoraggio delle risorse
Vengono descritte le funzionalità del portale ECS per il monitoraggio delle risorse.
Il monitoraggio delle risorse include gli elementi indicati di seguito.
l
Integrità dell'hardware a pagina 98
l
Metriche del traffico di rete a pagina 99
l
Larghezza di banda del disco a pagina 101
l
Integrità di nodi e processi a pagina 102
Ciascuna di queste aree di monitoraggio presenta una pagina corrispondente nel menu
Monitor del portale ECS.
Per informazioni su altre funzionalità di monitoraggio del portale ECS, consultare gli
articoli indicati di seguito.
l
Monitoraggio dello storage: misurazione e capacità a pagina 106
l
Monitoraggio dei servizi: blocchi, codici di cancellazione, replica geografica e stato di
ripristino a pagina 116
l
128
Utilizzo di pagine di monitoraggio
Vengono introdotte le tecniche di base per l'utilizzo di pagine di monitoraggio nel portale
ECS.
Le pagine di monitoraggio del portale ECS condividono un set di interazioni comuni. Le
limitazioni sono riportate di seguito.
l
Ricerca: viene visualizzata l'icona di ricerca quando è possibile restringere i risultati
di monitoraggio effettuando la corrispondenza del testo di ricerca con le righe dei
risultati che lo contengono.
Figura 15 Cerca
l
Aggiornamento: l'icona di aggiornamento consente di aggiornare la visualizzazione
del monitoraggio con i dati più recenti.
Figura 16 Aggiorna
l
Filtro: compilare i campi di filtro e l'intervallo di date e selezionare Filter per
visualizzare le righe dei risultati corrispondenti a tutti i campi di filtro. L'intervallo di
date predefinito è sempre compreso tra il giorno precedente e il giorno stesso.
Figura 17 Filtro
96
l
Ordinamento per colonna: selezionare una volta un'intestazione di colonna per
disporre i risultati in base a essa in ordine crescente. Selezionare nuovamente per
cambiare la disposizione in ordine decrescente.
Figura 18 Ordina
l
Visualizzazioni drill-down con percorsi di navigazione: i percorsi di navigazione
consentono di eseguire rapidamente il drill-up dopo aver eseguito il drill-down in
schermate dettagliate. Vedere l'esempio riportato di seguito.
l
Grafici cronologici con passaggi del mouse da sinistra a destra: è possibile ottenere
grafici dettagliati indicanti snapshot di dati ogni ora per gli ultimi cinque giorni che è
possibile esplorare con passaggi del mouse da sinistra a destra. Vedere l'esempio
riportato di seguito.
Figura 19 Navigazione con percorsi
Il testo evidenziato in una riga di tabella indica un link a una visualizzazione dettagliata.
Selezionare il link per eseguire il drill-down al livello di dettaglio successivo. Nelle
visualizzazioni drill-down una stringa di percorso mostra la posizione corrente dell'utente
nella sequenza di visualizzazioni drill-down. Questa stringa di percorso è denominata
traccia degli spostamenti o percorso di navigazione. Selezionare un percorso di
navigazione evidenziato per passare alla visualizzazione associata.
97
Figura 20 Grafico di dati con cursore attivo
Quando si seleziona un pulsante History, al di sotto della tabella vengono visualizzati
tutti i grafici disponibili per la riga corrispondente. Passare il mouse su un grafico da
sinistra a destra per visualizzare una linea verticale che agevola l'individuazione di una
data e un'ora specifiche nel grafico. Una visualizzazione pop-up mostra il valore e il
timestamp per il punto.
Monitoraggio hardware
Viene descritto come utilizzare la pagina Monitor > Hardware Health.
L'integrità dell'hardware è indicata da tre stati:
l
Good: il componente hardware è in normali condizioni operative.
l
Suspect: il componente hardware è in fase di transizione dallo stato Good allo stato
Bad per via di una diminuzione delle metriche hardware, si è verificato un problema
in un componente hardware di livello inferiore oppure l'hardware non è rilevabile dal
sistema per problemi di connettività.
l
Bad: l'hardware necessita di sostituzione.
Nel caso dei dischi, il significato di questi stati è descritto di seguito.
l
Good: il sistema è in grado di leggere dal disco e scrivere al suo interno.
l
Suspect: il sistema non è più in grado di scrivere nel disco, ma può leggere da esso.
Un numero elevato di dischi in stato Suspect può essere determinato da problemi di
connettività in un nodo. Questi dischi eseguiranno nuovamente la transizione allo
stato Good una volta risolti i problemi di connettività.
l
Bad: il sistema non è in grado di leggere dal disco, né di scrivere al suo interno.
Sostituire il disco. Una volta identificato il disco come non valido da parte del
sistema ECS, non potrà essere riutilizzato all'interno di ECS. Per via della protezione
dei dati di ECS, quando un disco presenta problemi, negli altri dischi del sistema
vengono ricreate copie dei dati precedentemente presenti al suo interno. Di
conseguenza un disco non valido rappresenta solo una perdita di capacità per il
sistema e non una perdita di dati. Una volta sostituito, il nuovo disco non avrà dati
ripristinati al suo interno. Diverrà semplicemente capacità raw per il sistema.
Procedura
1. Selezionare Monitor > Hardware Health.
2. Individuare la riga di tabella per lo storage pool di destinazione.
98
3. Facoltativamente, selezionare un nome per lo storage pool per eseguire il drill-down
fino alla visualizzazione dei nodi.
4. Facoltativamente, selezionare l'endpoint di un nodo per eseguire il drill-down fino alla
visualizzazione del disco.
Figura 21 Hardware Health
Nota
Per informazioni sull'utilizzo degli ID disco per identificare i dischi che necessitano di
sostituzione, vedere Sostituzione di un disco di storage ECS in un appliance USeries a pagina 300.
Monitoraggio del traffico di rete
Viene descritta la pagina di monitoraggio del portale ECS per il traffico di rete.
La pagina Monitor > Traffic Metrics fornisce metriche per il traffico di rete a livello di data
center virtuale o singolo nodo. I grafici mostrano i dati relativi agli ultimi sette giorni.
Monitoraggio del traffico di rete
99
Tabella 8 Metriche del traffico di rete
Etichetta di metrica
Descrizione
R Avg. Latenza (ms)
Latenza media delle letture in millisecondi.
W Avg. Latenza (ms)
Latenza media delle scritture in millisecondi.
R Bandwidth
Larghezza di banda delle letture in megabyte al secondo.
W Bandwidth
Larghezza di banda delle scritture in megabyte al secondo.
R Transactions (per/s)
Transazioni di letture al secondo.
W Transactions (per/s)
Transazioni di scritture al secondo.
Recent Transaction Failures per type Per ciascun codice di errore verificatosi nel periodo di
monitoraggio viene visualizzata la percentuale degli errori
totali.
Procedura
1. Selezionare Monitor > Traffic Metrics.
2. Individuare il nome del VDC di destinazione.
3. Facoltativamente, selezionare il nome del VDC per eseguire il drill-down fino alla
visualizzazione dei nodi.
4. Selezionare il pulsante History per il nodo o il VDC di destinazione.
Figura 22 Grafici relativi al traffico di rete di un VDC
100
Monitoraggio della larghezza di banda del disco
Viene descritta la pagina di monitoraggio del portale ECS per la larghezza di banda del
disco.
La pagina Monitor > Disk bandwidth fornisce metriche sull'utilizzo del disco a livello di
data center virtuale o singolo nodo. Per ciascun VDC o nodo è disponibile una riga per la
lettura e un'altra per la scrittura. I grafici mostrano i dati relativi agli ultimi sette giorni.
Tabella 9 Metriche relative alla larghezza di banda del disco
Etichetta di
metrica
Descrizione
Totale
Larghezza di banda totale del disco utilizzata in kilobyte al secondo per
operazioni di lettura o scrittura.
Hardware Recovery
Quantità di larghezza di banda del disco utilizzata per ripristinare i dati in
seguito a un guasto dell'hardware.
Erasure Encoding
Quantità di larghezza di banda del disco utilizzata nelle operazioni relative
ai codici di cancellazione nel sistema.
XOR
Quantità di larghezza di banda del disco del totale utilizzata nelle
operazioni XOR di protezione dei dati del sistema. Le operazioni XOR si
verificano per i sistemi con almeno tre siti (VDC).
Consistency
Checker
Quantità di larghezza di banda del disco utilizzata per individuare
eventuali incoerenze tra i dati protetti e le relative repliche.
Area geografica
Quantità di larghezza di banda del disco utilizzata per il supporto di
operazioni di replica geografica.
User Traffic
Quantità di larghezza di banda utilizzata dagli utenti di object.
Procedura
1. Selezionare Monitor > Disk Bandwidth.
2. Individuare il nome del VDC di destinazione e la riga della tabella di lettura o scrittura
per il VDC.
3. Facoltativamente, selezionare Node Count per eseguire il drill-down fino a una tabella
con le righe per i nodi nel VDC.
4. Selezionare il pulsante History per il VDC o il nodo.
Monitoraggio della larghezza di banda del disco
101
Figura 23 Larghezza di banda disco
Monitoraggio dell'integrità di nodi e processi
Viene descritta la pagina di monitoraggio del portale ECS per l'integrità di nodi e
processi.
La pagina Monitor > Node & Process Health fornisce metriche che consentono di valutare
l'integrità del VDC, del nodo o del processo di un nodo.
Tabella 10 Metriche relative all'integrità di VDC, nodo e processo
102
Livello
Descrizione
Tempo Larghezza di
banda NIC
VDC e nodo
Larghezza di banda media
del controller hardware
dell'interfaccia di rete
utilizzata dal VDC o dal
nodo selezionato.
Tempo CPU Usage (%)
VDC e nodo
Percentuale media del
PCU hardware utilizzato
dal VDC o dal nodo
selezionato.
Tempo Utilizzo di memoria VDC e nodo
Utilizzo medio in
megabyte della memoria
aggregata disponibile nel
VDC o nel nodo.
Relative NIC (%)
Percentuale di larghezza
di banda disponibile del
VDC e nodo
Tabella 10 Metriche relative all'integrità di VDC, nodo e processo (continua)
Livello
Descrizione
controller hardware
dell'interfaccia di rete
utilizzata dal VDC o dal
nodo selezionato.
Relative Memory (%)
VDC e nodo
Percentuale di memoria
utilizzata rispetto alla
memoria disponibile per il
VDC o il nodo selezionato.
CPU (%)
Process
Percentuale di CPU del
nodo utilizzata dal
processo.
Utilizzo di memoria
Process
Memoria in megabyte
utilizzata dal processo.
Relative Memory (%)
Process
Percentuale di memoria
utilizzata rispetto alla
memoria disponibile per il
processo.
Tempo # Thread
Process
Numero medio di thread
utilizzati dal processo.
Last Restart
Process
Ora dell'ultimo riavvio del
processo nel nodo.
Procedura
1. Individuare la riga di tabella per il VDC di destinazione.
2. Facoltativamente, selezionare il nome del VDC per eseguire il drill-down fino a una
tabella con le righe per ciascun nodo nel VDC.
3. Facoltativamente, selezionare un endpoint di un nodo per eseguire il drill-down fino a
una tabella con le righe per ciascun processo in esecuzione nel nodo.
4. Selezionare il pulsante History per il VDC, il nodo o il processo di destinazione.
Monitoraggio dell'integrità di nodi e processi
103
Figura 24 Node & Process Health
104
CAPITOLO 13
Monitoraggio dello storage: misurazione e
capacità
l
l
l
l
Introduzione....................................................................................................... 106
Utilizzo di pagine di monitoraggio....................................................................... 106
Monitoraggio della capacità................................................................................ 108
Monitoraggio dei dati di misurazione.................................................................. 111
105
Introduzione
ECS consente di misurare la creazione e l'eliminazione di object a livello di bucket e di
namespace. ECS consente inoltre il monitoraggio dell'utilizzo della capacità.
Ciascuna di queste funzionalità di monitoraggio presenta un pannello corrispondente nel
menu Monitor del portale ECS e il meccanismo per accedervi, insieme ai dati forniti dal
pannello, è descritto nei seguenti argomenti:
l
Monitoraggio dei dati di misurazione a pagina 111
l
Monitoraggio della capacità a pagina 108
l
Monitoraggio di risorse: hardware, traffico di rete, larghezza di banda del disco,
integrità di nodi e processi a pagina 96
l
l
128
ECS.
l
Figura 25 Cerca
l
Figura 26 Aggiorna
l
Figura 27 Filtro
106
l
Figura 28 Ordina
l
l
107
Monitoraggio della capacità
È possibile monitorare l'utilizzo della capacità di storage pool, nodi e dischi.
Tabelle e visualizzazioni di capacità sono illustrate in Dati di capacità di storage a pagina
108. A ciascuna tabella è associata una visualizzazione cronologica che consente di
notare le variazioni dei dati nel tempo.
L'utilizzo di ECS Management REST API consente il retrieval dei dati a livello di codice
mediante client personalizzati. Il supporto per questa funzionalità e altre che consentono
la gestione di un tenant è disponibile in Gestione di un tenant a pagina 84. ECS
Management REST API Reference viene fornito qui.
Procedura
1. Nel portale ECS selezionare Monitor > Capacity.
2. È possibile eseguire il drill-down nei nodi e nei singoli dischi selezionando il link
appropriato nella tabella.
Indicazioni sulla navigazione nelle tabelle sono disponibili in Utilizzo di pagine di
monitoraggio a pagina 96.
3. Per visualizzare le variazioni della capacità nel tempo, selezionare History per lo
storage pool, il nodo o il disco desiderato.
Dati di capacità di storage
È possibile visualizzare la capacità di storage per storage pool, nodi e dischi nella pagina
Monitor > Capacity Utilization.
Le aree di utilizzo della capacità sono descritte in:
108
l
Capacità storage pool a pagina 109
l
Utilizzo della capacità dei nodi a pagina 109
l
Utilizzo della capacità del disco a pagina 110
Per indicazioni sulla navigazione delle visualizzazioni della capacità, fare riferimento a
Utilizzo di pagine di monitoraggio a pagina 96.
Capacità storage pool
Tabella 11 Utilizzo della capacità: Storage pool
Attributo
Descrizione
Storage pool
Nome dello storage pool.
Nodi
Numero di nodi nello storage pool.
Fare clic sul numero di nodi da aprire: Utilizzo della capacità dei
nodi a pagina 109
Dischi
Numero di dischi nello storage pool.
Usable Capacity
Capacità utilizzabile totale. Totale della capacità già in uso e di
quella ancora allocabile.
Capacità utilizzata
Capacità utilizzata nello storage pool.
Capacità disponibile
Capacità disponibile per l'uso.
Azioni
Viene fornita la seguente azione: History.
History visualizza la cronologia dell'utilizzo della capacità a
livello grafico.
Di seguito è illustrata la visualizzazione cronologica della tabella relativa all'utilizzo della
capacità dello storage pool.
Utilizzo della capacità dei nodi
Tabella 12 Utilizzo della capacità: Node
Attributo
Descrizione
Nodi
Indirizzo IP del nodo.
Dischi
Numero di dischi associati al nodo. Fare clic sul numero di nodi
da aprire: Utilizzo della capacità del disco a pagina 110
Usable Capacity
Capacità utilizzabile totale fornita dai dischi nel nodo. Totale
della capacità già in uso e di quella ancora allocabile.
Capacità utilizzata nel nodo.
Capacità rimanente disponibile nel nodo.
Dati di capacità di storage
109
Tabella 12 Utilizzo della capacità: Node (continua)
Attributo
Descrizione
Node Status
Il segno di spunta indica che lo stato del nodo è Good.
Azioni
Viene fornita la seguente azione: Cronologia
livello grafico.
Di seguito è illustrata la visualizzazione cronologica della tabella relativa all'utilizzo della
capacità del nodo.
Utilizzo della capacità del disco
Tabella 13 Utilizzo della capacità: Disco
Attributo
Descrizione
Dischi
Identificatore del disco.
Usable Capacity
Capacità utilizzabile fornita dal disco.
Capacità utilizzata nel disco.
Capacità rimanente disponibile nel disco.
Stato del disco
Il segno di spunta indica che lo stato del nodo è Good.
Azioni
Viene fornita la seguente azione: Cronologia
livello grafico.
Di seguito è illustrata la visualizzazione cronologica della tabella relativa all'utilizzo del
disco.
110
Monitoraggio dei dati di misurazione
È possibile scegliere il namespace, o il bucket al suo interno, per cui si desidera
visualizzare dati di misurazione ed è possibile selezionare il periodo di tempo per cui
visualizzare i dati.
I dati di misurazione disponibili sono descritti in dettaglio in Dati di misurazione a pagina
111.
L'utilizzo di ECS Management REST API consente il retrieval dei dati a livello di codice
mediante client personalizzati. Il supporto per questa funzionalità e altre che consentono
la gestione di un tenant è disponibile in Gestione di un tenant a pagina 84. ECS
Management REST API Reference viene fornito qui.
Procedura
1. Nel portale ECS selezionare Monitor > Metering.
2. Selezionare il namespace per cui si desidera visualizzare i dati di misurazione.
Gli utenti con ruolo di Namespace Admin potranno selezionare esclusivamente il
proprio namespace.
3. Facoltativamente, immettere il nome del bucket per cui si desidera visualizzare i dati
di object.
Se non si specifica un bucket, i dati di misurazione degli object corrisponderanno ai
totali di tutti i bucket nel namespace.
4. Utilizzare i calendari From e To per scegliere il periodo di tempo per cui visualizzare i
dati.
I dati di misurazione vengono mantenuti per circa 30 giorni.
5. Per visualizzare i dati di misurazione per il namespace e il bucket selezionato, nonché
il periodo di tempo, fare clic su Filter.
Dati di misurazione
I dati di misurazione degli object per un namespace specificato, o un bucket specificato
al suo interno, possono essere ottenuti per un periodo di tempo definito nella pagina
Monitor > Metering del portale ECS.
Monitoraggio dei dati di misurazione
111
Tabella 14 Misurazione di bucket e namespace
Attributo
Descrizione
Spazio totale (GB)
Dimensione totale degli object archiviati nel namespace o nel
bucket selezionato.
Conteggio oggetti
Numero di object associati al namespace o al bucket
selezionato al termine dell'ora specificata nel filtro.
Objects Created
Numero di object creati nel namespace o nel bucket selezionato
nel periodo di tempo.
Objects Deleted
Numero di object eliminati dal namespace o dal bucket
selezionato nel periodo di tempo.
Bandwidth Ingress (MB)
Totale di dati di object in entrata (scritture) per il namespace o il
Bandwidth Egress (MB)
Totale di dati di object in uscita (letture) per il namespace o il
Nota
I dati di misurazione non sono immediatamente disponibili, in quanto potrebbe essere
necessario molto tempo per raccogliere le statistiche per i dati aggiunti al sistema ed
eliminati da esso.
112
CAPITOLO 14
l
l
Log di servizio..................................................................................................... 114
ECS - Posizioni dei log di servizio........................................................................ 114
113
Log di servizio
Vengono descritte la posizione e la funzione dei log di servizio ECS.
Gli amministratori di storage possono accedere ai log di servizio ECS se si dispone
dell'autorizzazione a SSH in un nodo e accedere ai log. L'utilizzo delle pagine Monitoring
del portale ECS è in genere ideale per conoscere lo stato del sistema.
ECS - Posizioni dei log di servizio
Vengono descritti la posizione e il contenuto dei log di servizio ECS.
È possibile accedere ai log di servizio ECS direttamente da una sessione SSH su un nodo.
Passare alla seguente directory: /opt/emc/caspian/fabric/agent/services/
object/main/log per individuare i log degli object service:
114
l
authsvc.log: registra informazioni dal servizio di autenticazione.
l
blobsvc*.log: questi log registrano aspetti del servizio blob.
l
cassvc*.log: questi log registrano aspetti del servizio CAS.
l
coordinatorsvc.log: registra informazioni dal servizio di coordinamento.
l
ecsportalsvc.log: registra informazioni dal servizio del portale ECS.
l
eventsvc*.log: questi log registrano aspetti del servizio eventi. Queste
informazioni sono disponibili nel menu Monitoring del portale ECS.
l
hdfssvc*.log: questi log registrano aspetti del servizio HDFS.
l
objcontrolsvc.log: registra informazioni dall'object service.
l
objheadsvc*.log: questi log registrano aspetti dei vari object head supportati
dall'object service.
l
provisionsvc*.log: questi log registrano aspetti del servizio di provisioning
ECS.
l
resourcesvc*.log: questi log registrano aspetti delle funzioni di suddivisione in
blocchi di ECS.
CAPITOLO 15
Monitoraggio dei servizi: blocchi, codici di
cancellazione, replica geografica e stato di
ripristino
l
l
l
l
l
l
l
l
l
Informazioni sul monitoraggio dei servizi............................................................ 116
Utilizzo di pagine di monitoraggio....................................................................... 116
Monitoraggio di blocchi.......................................................................................118
Monitoraggio dei codici di cancellazione.............................................................120
Monitoraggio dello stato di ripristino...................................................................121
Monitoraggio della replica geografica: tassi e blocchi..........................................122
Monitoraggio della replica geografica: RPO (Recovery Point Objective)................ 123
Monitoraggio della replica geografica: failover.................................................... 124
Monitoraggio della replica geografica: elaborazione di bootstrap........................ 125
Monitoraggio dei servizi: blocchi, codici di cancellazione, replica geografica e stato di ripristino
115
Informazioni sul monitoraggio dei servizi
Vengono descritte le funzionalità del portale ECS per il monitoraggio dei servizi.
Il monitoraggio dei servizi include:
l
Riepilogo dei blocchi a pagina 118
l
Codici di cancellazione a pagina 120
l
Stato di ripristino a pagina 121
l
Replica geografica: tassi e blocchi a pagina 122
l
Replica geografica: RPO (Recovery Point Objective) a pagina 123
l
Replica geografica: elaborazione di failover a pagina 124
l
Replica geografica: elaborazione di bootstrap a pagina 124
Ciascuna di queste aree di monitoraggio presenta una pagina corrispondente nel menu
Monitor del portale ECS. La pagina Geo Replication include quattro sezioni separate.
l
l
l
128
ECS.
l
Figura 31 Cerca
l
Figura 32 Aggiorna
l
116
Figura 33 Filtro
l
Figura 34 Ordina
l
l
117
Monitoraggio di blocchi
Viene descritta la pagina di monitoraggio del portale ECS per i blocchi.
In questa pagina vengono riportate le statistiche per i blocchi sigillati nella zona locale.
Un blocco si definisce sigillato se non può più accettare scritture. È immutabile.
Tabella 15 Tabelle dei blocchi
Tabella
Descrizione
Chunk Count of Each
Type
Mostra il numero e la percentuale di blocchi sigillati per tipi diversi in
base a ciascuno storage pool configurato nella zona locale.
Total Length of Each
Chunk Type
Mostra la dimensione logica totale di blocchi sigillati per tipi diversi in
Avg Sealed Length of
Each Type
Mostra la dimensione logica media di blocchi sigillati per tipi diversi in
Tabella 16 Metriche dei blocchi
Etichetta di
metrica
Descrizione
Storage pool
Questa colonna fornisce l'elenco di storage pool configurati nel VDC locale.
Ciascuna riga fornisce metriche di blocchi per lo storage pool specificato.
Repo User data I blocchi di repository contengono dati dell'utente.
Questa colonna fornisce dati pertinenti per i blocchi di repository nello storage
pool.
118
Tabella 16 Metriche dei blocchi (continua)
Etichetta di
metrica
Descrizione
Level-0 btree
I blocchi B-Tree contengono metadati di sistema sulla disposizione e sulla
posizione dei dati dell'utente. "Level-0" (livello 0) si riferisce al livello inferiore
di dati nel sistema, ad esempio tabelle di object e di ricerca di base.
Questa colonna fornisce dati pertinenti per i blocchi B-Tree di livello 0 nello
storage pool.
Level-0 journal
I blocchi di journal contengono dati di ripristino da errore. "Level-0" (livello 0) si
riferisce al livello inferiore di dati nel sistema, ad esempio tabelle di object e di
ricerca.
Questa colonna fornisce dati pertinenti per i blocchi di journal di livello 0 nello
storage pool.
Level-1 btree
I blocchi B-Tree contengono metadati di sistema sulla disposizione e sulla
posizione dei dati dell'utente. "Level-1" (livello 1) si riferisce a dati più
complessi nel sistema.
Questa colonna fornisce dati pertinenti per i blocchi B-Tree di livello 1 nello
storage pool.
Level-1 journal
I blocchi di journal contengono dati di ripristino da errore. "Level-1" (livello 1) si
riferisce a dati più complessi nel sistema.
Questo campo fornisce dati pertinenti per i blocchi di journal di livello 1 nello
storage pool.
Geo copy
I blocchi geografici contengono repliche di dati da altre zone (VDC).
Questo campo fornisce dati pertinenti per i blocchi di copie geografiche nello
storage pool.
XOR
I blocchi XOR consentono di risparmiare spazio sul disco utilizzando l'algoritmo
XOR per comprimere dati da altri blocchi e sostituire questi ultimi con un blocco
XOR.
Questo campo fornisce dati pertinenti per i blocchi XOR nello storage pool.
Totale
Numero totale di blocchi nello storage pool.
Monitoraggio di blocchi
119
Metriche dei blocchi
Figura 37 Riepilogo dei blocchi
Monitoraggio dei codici di cancellazione
Viene descritto come utilizzare la pagina Monitor > Erasure Coding.
La visualizzazione dei codici di cancellazione monitora il numero totale di dati dell'utente
e di dati con codici di cancellazione in uno storage pool locale. Indica inoltre il numero di
dati in attesa di codici di cancellazione per il tasso corrente e l'ora di completamento
stimata. I grafici mantengono i dati fino a sette giorni.
Tabella 17 Metriche per codici di cancellazione
Colonna
Descrizione
Storage pool
Total User Data
Dimensione logica totale dei blocchi di dati dell'utente nello storage
pool.
Total Erasure Coded Data Dimensione logica totale di tutti i blocchi con codici di cancellazione
nello storage pool.
Rate of Erasure Coding
Tasso in cui vengono elaborati i dati correnti in attesa di codici di
cancellazione.
Est Time to Complete
Ora stimata per il completamento estrapolata dal tasso di codici di
cancellazione corrente.
Procedura
1. Selezionare Monitor > Erasure Coding.
3. Selezionare il pulsante History.
120
Monitoraggio dello stato di ripristino
Viene descritto come utilizzare la pagina Monitor > Recovery Status.
Il ripristino è il processo di ricostruzione dei dati in seguito a una condizione locale
risultante in dati non validi (blocchi). Questa tabella include una riga per ciascuno
storage pool nella zona locale.
Tabella 18 Metriche di ripristino
Colonna
Descrizione
Storage pool
Elenca ciascuno storage pool nella zona locale.
Total Amount Data to be
Recovered
Dimensione logica dei dati ancora da ripristinare.
Recovery Rate
Tasso a cui i dati vengono ripristinati nello storage pool
specificato in byte al secondo.
Time to Completion
Tempo di completamento stimato del ripristino estrapolato dal
tasso di ripristino corrente.
Procedura
1. Selezionare Monitor > Recovery Status.
3. Selezionare il pulsante History.
Monitoraggio dello stato di ripristino
121
Monitoraggio della replica geografica: tassi e blocchi
Vengono descritti i campi delle tabelle disponibili nella pagina Monitor > Geo-Replication
> Rate and Chunks del portale ECS.
Questa pagina fornisce metriche fondamentali sul traffico di rete per una replica e i
blocchi in attesa di replica da parte del VDC o del gruppo di replica.
Tabella 19 Colonne di tassi e blocchi
122
Colonna
Descrizione
Remote Zone
Elenca i VDC remoti con gruppi di replica che includono il VDC locale. I
dati elencati rappresentano l'UUID del VDC.
Replication Group
Questa colonna elenca il gruppo di replica a cui partecipa questa
zona (VDC).
Write Traffic
Tasso corrente di scritture nel VDC o nel gruppo di replica in gigabyte
al secondo.
Read Traffic
Tasso corrente di letture nel VDC o nel gruppo di replica in gigabyte al
secondo.
Repo Chunks Pending
Replication Total Space
Dimensione logica totale di tutti i blocchi di dati dell'utente
(repository) in attesa di replica.
Journal Chunks Pending
Replication Total Space
Dimensione logica totale di tutti i blocchi di metadati di sistema in
attesa di replica.
Chunks Pending XOR
Total Space
Dimensione logica totale di tutti i blocchi in attesa di elaborazione da
parte dell'algoritmo di compressione XOR.
Figura 38 Replica geografica: tassi e blocchi
Monitoraggio della replica geografica: RPO (Recovery Point
Objective)
Vengono descritti i campi delle tabelle disponibili nella pagina Monitor > Geo-Replication
> RPO del portale ECS.
Un Recovery Point Objective (RPO) è una regola di business per il limite di durata di
inattività di un servizio. Con questa visualizzazione è possibile conoscere la durata di un
ripristino per una zona o un gruppo di replica.
Tabella 20 Colonne di RPO
Colonna
Descrizione
Remote Replication
Group\Remote Zone
A livello di VDC, elenca tutti i gruppi di replica remota a cui partecipa la
zona locale. A livello di gruppo di replica, questa colonna elenca le zone
remote nel gruppo di replica. Il dato elencato rappresenta l'identificatore
di sistema per il VDC o il gruppo di replica sotto forma di URN.
Overall RPO
(minutes)
Tempo trascorso nell'ultimo ripristino per la zona o il gruppo di replica.
Figura 39 RPO
Monitoraggio della replica geografica: RPO (Recovery Point Objective)
123
Monitoraggio della replica geografica: failover
Vengono descritte le metriche disponibili nella pagina Monitor > Geo-Replication >
Failover Processing del portale ECS.
La pagina Failover Processing fornisce metriche sul processo di risincronizzazione di un
gruppo di replica una volta ripristinata la connettività tra VDC in seguito all'interruzione
dell'attività.
Tabella 21 Colonne di failover
Campo
Descrizione
Replication
Group
Elenca i gruppi di replica di cui è membro la zona locale. Il dato elencato
rappresenta l'identificatore di sistema per il gruppo di replica sotto forma di
URN.
Failed Zone
Identifica una zona con guasti facente parte del gruppo di replica. In caso di
più zone con guasti, nella tabella saranno presenti più righe per il gruppo di
replica. Il dato mostrato rappresenta l'identificatore di sistema per la zona
sotto forma di URN.
Repo chunks
pending rereplication (# /
Total Space)
Mostra blocchi contenenti dati dell'utente (dati di repository) che necessitano
di essere nuovamente replicati, poiché il sistema non è in grado di verificare
l'esito positivo della replica dei blocchi originali a causa della zona con guasti.
Il campo elenca il numero di blocchi in attesa di nuova replica, nonché la
dimensione logica totale di questi blocchi.
Journal chunks
Total Space)
Mostra blocchi contenenti dati di ripristino da errore che necessitano di essere
nuovamente replicati, poiché il sistema non è in grado di verificare l'esito
positivo della replica dei blocchi originali a causa della zona con guasti. Il
campo elenca il numero di blocchi in attesa di nuova replica, nonché la
Btree chunks
Total Space)
Mostra blocchi contenenti metadati di sistema che necessitano di essere
nuovamente replicati, poiché il sistema non è in grado di verificare l'esito
positivo della replica dei blocchi originali a causa della zona con guasti. Il
campo elenca il numero di blocchi in attesa di nuova replica, nonché la
Repo chunks
pending XOR
decoding (# /
Total Space)
Mostra il numero e la dimensione logica totale dei blocchi in attesa di retrieval
mediante lo schema di compressione XOR.
Failover State
124
l
BLIND_REPLAY_DONE
l
REPLICATION_CHECK_DONE: il processo che verifica che tutti i blocchi di
replica siano in stato accettabile è stato completato.
l
CONSISTENCY_CHECK_DONE: il processo che verifica che tutti i metadati
di sistema siano completamente coerenti con altri dati replicati è stato
completato.
l
ZONE_SYNC_DONE: la sincronizzazione della zona con guasti è stata
completata.
l
ZONE_BOOTSTRAP_DONE: il processo di bootstrap della zona con guasti è
stato completato.
Tabella 21 Colonne di failover (continua)
Campo
Descrizione
ZONE_FAILOVER_DONE: il processo di failover è stato completato.
l
Failover Progress Indicatore in percentuale dello stato generale del processo di failover.
Figura 40 Failover
Monitoraggio della replica geografica: elaborazione di bootstrap
Vengono descritti i campi disponibili nella pagina Monitor > Geo Replication > Bootstrap
Processing del portale ECS.
Per bootstrap si intende il processo di copia dei metadati necessari in un gruppo di
replica che ha aggiunto una zona.
Tabella 22 Colonne di Bootstrap Processing
Colonna
Descrizione
Replication Group
Questa colonna fornisce l'elenco di gruppi di replica a cui partecipa la zona
locale con nuove zone aggiunte. Ciascuna riga fornisce metriche per il
gruppo di replica specificato.
Added Zone
Zona aggiunta al gruppo di replica specificato.
Repo Chunks
Pending
Replication Total
Space
Dimensione logica di tutti i blocchi di dati dell'utente (repository) in attesa
di replica nella zona con guasti.
Journal Chunks
Pending
Replication Total
Space
Dimensione logica di tutti i blocchi di ripristino da errore in attesa di replica
nella zona con guasti.
Btree Chunks
Pending
Replication Total
Space
Dimensione logica di tutti i blocchi di metadati di sistema in attesa di
replica nella zona con guasti.
Bootstrap State
l
Started: il sistema è in procinto di aggiungere la zona al gruppo di
replica.
l
BlindReplayDone
Monitoraggio della replica geografica: elaborazione di bootstrap
125
Tabella 22 Colonne di Bootstrap Processing (continua)
Colonna
Descrizione
l
ReplicationCheckDone: il processo che verifica che tutti i blocchi di
replica siano in stato accettabile è stato completato.
l
ConsistencyCheckDone: il processo che verifica che tutti i metadati di
sistema siano completamente coerenti con altri dati replicati è stato
completato.
l
ZoneSyncDone: la sincronizzazione della zona con guasti è stata
completata.
l
ZoneBootstrapDone: il processo di bootstrap della zona con guasti è
stato completato.
l
Done: l'intero processo di bootstrap è stato completato.
Bootstrap Progress Percentuale di completamento dell'intero processo di bootstrap.
(%)
Figura 41 Elaborazione di bootstrap
126
CAPITOLO 16
Monitoraggio degli eventi: portale di audit, API,
alert di sistema ed eventi CLI
l
l
Informazioni sul monitoraggio degli eventi.......................................................... 128
Filtraggio di eventi per data e ordinamento dei risultati per colonna.................... 128
Monitoraggio degli eventi: portale di audit, API, alert di sistema ed eventi CLI
127
Informazioni sul monitoraggio degli eventi
Vengono descritte le funzioni di monitoraggio degli eventi del portale ECS.
La pagina Events nel menu Monitor visualizza:
l
tutte le attività svolte dagli utenti che utilizzano il portale, ECS REST API o la CLI di
ECS;
l
alert generati dal sistema ECS;
l
alert generati dai servizi ECS.
I dati degli eventi nel portale ECS sono indicati per un massimo di 5 giorni. Per mantenere
i dati per periodi di tempo prolungati, valutare l'utilizzo di ViPR SRM.
Per informazioni su altre pagine di monitoraggio del portale ECS, consultare gli articoli
indicati di seguito.
l
l
l
Filtraggio di eventi per data e ordinamento dei risultati per
colonna
Utilizzare la funzionalità di filtraggio per restringere gli eventi a uno specifico intervallo di
date e ordinare i risultati.
Procedura
1. Immettere una data di inizio nel campo From e una data di fine nel campo To oppure
selezionare le icone del calendario per scegliere le date. La voce predefinita in questi
campi è sempre l'intervallo compreso tra il giorno precedente e il giorno stesso.
2. Selezionare Filter.
3. Selezionare un'intestazione di colonna per disporre i dati per User ID, Description,
Namespace o Timestamp in ordine crescente. Selezionare nuovamente la colonna per
128
Figura 42 Gli eventi vengono visualizzati filtrati per un intervallo di date e disposti per ID utente in
ordine decrescente
Filtraggio di eventi per data e ordinamento dei risultati per colonna
129
130
PARTE 6
Capitolo 17, "Indirizzamento di object storage ECS e utilizzo dell'URL di base "
Capitolo 18, "Creazione e configurazione di bucket "
Capitolo 19, "Ricezione di una chiave segreta per l'accesso all'object storage "
Capitolo 20, "Configurazione del supporto per applicazioni CAS SDK con il portale ECS"
131
132
CAPITOLO 17
Indirizzamento di object storage ECS e utilizzo
dell'URL di base
l
l
l
Introduzione....................................................................................................... 134
Indirizzamento bucket.........................................................................................134
Aggiunta di un URL di base..................................................................................137
133
Introduzione
Le applicazioni scritte per l'utilizzo di Amazon S3 possono essere abilitate per impiegare
l'object storage di ECS impostando il parametro dell'URL di base. L'URL di base viene
impostato in modo predefinito su amazonaws.com. In questo articolo viene descritta la
procedura per impostare l'URL di base e garantire che i requisiti siano instradati su ECS.
Nelle sezioni indicate di seguito vengono descritti lo schema di indirizzamento
supportato da ECS, l'utilizzo del parametro dell'URL di base e il relativo meccanismo di
impostazione.
l
Indirizzamento bucket a pagina 134
l
Aggiunta di un URL di base a pagina 137
Indirizzamento bucket
Il servizio ECS S3 offre vari modi per identificare il bucket, sul quale è necessario
eseguire l'operazione definita in una richiesta.
Quando si utilizza il servizio Amazon S3, tutti i nomi di bucket devono essere unici.
Tuttavia, il servizio ECS S3 supporta l'utilizzo di un namespace, che può essere utilizzato
insieme al nome del bucket, che può avere lo stesso nome in namespace diversi.
Assegnando un namespace a ciascun tenant, un tenant può assegnare nomi di bucket,
senza tenere in considerazione i nomi correntemente utilizzati da altri tenant. Se la
richiesta non specifica alcun namespace, ECS utilizza il namespace predefinito associato
al tenant al quale appartiene l'utente che effettua la richiesta.
Il namespace, che si riferisce alla posizione di un object, può essere specificato
nell'intestazione x-emc-namespace di una richiesta HTTP. ECS Supporta, inoltre,
l'estrazione della posizione dall'intestazione dell'host e consente i seguenti schemi di
indirizzamento compatibili con Amazon S3:
l
Indirizzamento di stile host virtuale a pagina 134
l
Indirizzamento basato su percorso a pagina 134
Indirizzamento di stile host virtuale
Nello schema di indirizzamento di host virtuale, il nome del bucket appare nel nome
host. Ad esempio, è possibile accedere al bucket denominato "mybucket" sull'host
ecs1.yourco.com, utilizzando:
http://mybucket.ecs1.yourco.com
Inoltre, ECS consente di includere un namespace nell'indirizzo. Ad esempio:
<bucketname>.<namespace>.ecs1.yourco.com
Per utilizzare questo stile di indirizzamento, è necessario configurare ECS in modo da
consentirgli di sapere quale parte dell'URL corrisponde al nome del bucket. Questa
operazione viene eseguita configurando l'URL di base. Inoltre è necessario assicurarsi
che il sistema DNS sia in grado di risolvere l'indirizzo. Le sezioni seguenti forniscono
ulteriori informazioni:
l
Configurazione DNS a pagina 135
l
URL di base a pagina 135
Indirizzamento basato su percorso
Nello schema di indirizzamento basato su percorso, il nome del bucket viene aggiunto
alla fine del percorso. Ad esempio:
134
ecs1.yourco.com/mybucket
Utilizzare il seguente formato per includere un namespace:
ecs1.yourco.com/mynamespace/mybucket
Configurazione DNS
Quando si accede allo storage ECS attraverso il servizio S3, è necessario assicurarsi che
l'URL si risolva nell'indirizzo del nodo di dati ECS o nel load balancer del nodo di dati.
Se l'applicazione utilizza l'indirizzamento di stile-percorso, si garantisce che il nome di
base può essere risolto dal DNS. Ad esempio, se l'applicazione inoltra normalmente
richieste nel formato ecs1.yourco.com/bucket, è necessario disporre di una voce DNS
che risolva ecs1.yourco.com nell'indirizzo IP del load balancer utilizzato per l'accesso ai
nodi ECS. Se si utilizza Il servizio Amazon, questo URI presenta il formato: s3-euwest-1.amazonaws.com.
Quando l'applicazione utilizza l'indirizzamento di stile host virtuale, l'URL include il
nome del bucket e può includere un namespace. In queste condizioni, è necessario
assicurarsi di includere una voce DNS, che risolva l'indirizzo di stile host virtuale. È
possibile svolgere questa operazione, utilizzando un carattere jolly nella voce DNS.
Ad esempio, se l'applicazione inoltra normalmente richieste nel formato
bucket.s3.yourco.com, è necessario disporre di due voci DNS.
l
ecs1.yourco.com
l
*.ecs1.yourco.com
Se si utilizza un'applicazione precedentemente connessa al servizio Amazon S3,
utilizzando bucket.s3.amazonaws.com, le voci diventano:
l
s3.amazonaws.com
l
*.s3.amazonaws.com
Tali voci consentono la risoluzione del nome di base, durante l'esecuzione dei comandi
di livello di servizio (ad esempio, elencazione di bucket), e la risoluzione dell'indirizzo
del bucket di stile host virtuale.
Se si sta creando un certificato SSL per questo servizio, è necessario che includa il
carattere jolly nel nome del certificato e la versione senza caratteri jolly come nome
soggetto alternativo.
URL di base
Se si dispone di un'applicazione S3 che utilizza l'indirizzamento di stile host virtuale e si
desidera utilizzarlo per collegarlo a ECS, l'URL di base deve essere impostato in modo da
consentire a ECS di sapere quale parte dell'indirizzo si riferisce al bucket e,
facoltativamente, al namespace. L'URL di base può essere impostato utilizzando il
portale ECS o ECS Management REST API e richiede il ruolo di System Administrator in
ECS.
Nella pagina Base URL Management vengono elencati gli URL di base creati e la relativa
modalità di utilizzo da parte di ECS.
Configurazione DNS
135
Affinché ECS sia in grado di gestire il prefisso della posizione del bucket, l'URL di base
deve essere configurato scegliendo una delle seguenti opzioni.
l
Utilizzare l'URL di base con il namespace
l
Utilizzare l'URL di base senza il namespace
Nell'elaborare una richiesta, ECS:
1. Cerca di estrarre il namespace dall'intestazione x-emc-namespace. Una volta
individuato, saltare i passaggi riportati di seguito ed elaborare la richiesta.
2. Acquisire il nome host dell'URL dall'intestazione dell'host e verificare se l'ultima
parte dell'indirizzo corrisponde agli URL di base configurati.
3. Se viene individuata una corrispondenza dell'URL di base, utilizzare la parte del
prefisso del nome host (la parte lasciata a seguito della rimozione dell'URL di base),
per ottenere la posizione del bucket.
Alcune applicazioni, come Amazon S3 Browser, includono un endpoint statico, come
s3.amazonaws.com, nelle richieste generate. Molte di queste applicazioni non
dispongono di endpoint variabile con cui comunicano. Il browser S3 prova sempre a
inviare le richieste a s3.amazonaws.com. Questo token si trova nell'URI e viene
codificato nella stringa di autenticazione, anche se S3 Browser è stato configurato per
comunicare con ECS.
Mediante l'URL di base è possibile utilizzare un'applicazione come S3 Browser con ViPR
Controller. Impostare l'URL di base su s3.amazonaws.com per consentire il
funzionamento di S3 Browser.
Gli esempi riportati di seguito mostrano il modo in cui ECS gestisce le richieste HTTP in
entrata con strutture differenti.
Esempio 1
Host:
baseball.image.emc.finance.com
BaseURL:
finance.com
Use BaseURL with namespace enabled
Namespace:
Bucket Name:
emc
baseball.image
Esempio 2
Host:
BaseURL:
finance.com
Use BaseURL without namespace enabled
136
Namespace:
Bucket Name:
null (Use other methods to determine namespace)
baseball.image.emc
Esempio 3
Host:
BaseURL:
not configured
Namespace:
Bucket Name:
null (Use other methods to determine namespace.)
null (Use other methods to determine the bucket name.)
ViPR Controller treats this request as a path-style request.
Aggiunta di un URL di base
Questa operazione è necessaria solo se si utilizzano object client che codificano la
posizione di un object, con relativi namespace e bucket, in un URL. In questo caso, è
possibile specificare un URL di base che verrà utilizzato, insieme al namespace, come
percorso verso object contenuti in un tenant.
Prima di cominciare
Per eseguire questa operazione, è necessario disporre del ruolo di System Admin in ECS.
È necessario accertarsi che il dominio specificato in una richiesta, che utilizza un URL per
specificare la posizione di un object, si risolva nella posizione del nodo di dati ECS o di
un load balancer che si trova davanti ai nodi di dati.
Procedura
1. Nel portale ECS selezionare Settings > Object Base URLs.
2. Selezionare New Base URL.
Viene visualizzata la pagina New Base URL.
3. Inserire il nome dell'URL di base. In tal modo, vengono fornite ulteriori informazioni
sull'URL di base, esaminando la relativa tabella.
Aggiunta di un URL di base
137
4. Inserire l'URL di base.
Se gli URL della posizione degli object presentano il seguente formato: https://
mybucket.mynamespace.acme.com (ovvero bucket.namespace.baseurl )
o https://mybucket.acme.com (ovvero bucket.baseurl), l'URL di base
diventa acme.com.
È possibile specificare il formato nel selettore Namespace.
5. Scegliere il formato in cui l'indirizzo dell'object viene codificato nell'URL: con o senza
namespace.
Esempio di URL di base
Come esempio di utilizzo dell'URL di base, un object denominato myphoto.jpg nel bucket
di immagini con URL di base s3.amazonaws.com e tenant namespace "ecsdata"
potrebbe essere indirizzato utilizzando il seguente URL: https://
images.ecsdata.s3.amazonaws.com/myphoto.jpg
Figura 43 Esempio di URL di base
138
CAPITOLO 18
l
l
l
l
l
l
l
l
l
Introduzione....................................................................................................... 140
Concetti e attributi dei bucket............................................................................. 140
ACL di bucket...................................................................................................... 143
Creare un bucket mediante il portale ECS............................................................ 144
Modifica di un bucket..........................................................................................145
Impostazione delle autorizzazioni ACL dei bucket per un utente..........................146
Impostazione delle autorizzazioni ACL dei bucket per un gruppo predefinito.......147
Creare bucket utilizzando le API basate su object................................................147
Convenzioni di denominazione per bucket e chiavi............................................. 151
139
Introduzione
Per archiviare dati di object, sono necessari container. In S3 questi container sono
denominati bucket e questo termine è stato adottato come generico in ECS. In Atmos,
l'equivalente di un bucket è un subtenant e in Swift, l'equivalente di un bucket è un
container; per quanto riguarda CAS, un bucket è un pool CAS.
In ECS, ai bucket viene assegnato un tipo: S3, Swift, Atmos o CAS. Inoltre, i bucket S3,
Atmos o Swift possono essere configurati per il supporto di HDFS e un bucket configurato
per l'accesso HDFS può essere letto e scritto utilizzando il relativo protocollo di object e il
protocollo HDFS.
È possibile creare bucket per ciascun protocollo di object mediante la relativa API, in
genere utilizzando un client che supporti il protocollo appropriato. Ulteriore supporto per
la creazione di bucket S3, HDFS e CAS è disponibile nel portale ECS e in ECS
Management API. La possibilità di creare bucket dal portale agevola la creazione di
bucket per HDFS e CAS e consente di usufruire di alcune delle opzioni di configurazione
di bucket più avanzate fornite da ECS, tra cui quote e periodi di conservazione.
Se si desidera creare bucket mediante i protocolli di object, è possibile utilizzare
intestazioni x-emc speciali per controllare la configurazione dei bucket.
In questo articolo viene descritto come creare e modificare bucket e come impostare ACL
per un bucket mediante il portale ECS. Vengono inoltre illustrate le intestazioni x-emc
aggiuntive che è possibile utilizzare per controllare la configurazione dei bucket quando
si utilizzano i protocolli di object supportati.
Questa situazione è descritta nella sezione 2.1. Inoltre, i bucket S3, Atmos o Swift
possono essere configurati per il supporto di HDFS e un bucket configurato per l'accesso
HDFS può essere letto e scritto utilizzando il relativo protocollo di object e il protocollo
HDFS.
Sono descritti i seguenti use case:
l
Creare un bucket mediante il portale ECS a pagina 144
l
Creare bucket utilizzando le API basate su object a pagina 147
Vengono inoltre descritte la capacità di modificare la configurazione di un bucket e la
procedura per impostare l'ACL per un bucket.
l
Modifica di un bucket a pagina 145
l
Impostazione delle autorizzazioni ACL dei bucket per un utente a pagina 146
Concetti e attributi dei bucket
I bucket sono object container che possono essere utilizzati per controllare l'accesso agli
object e impostare proprietà che definiscono attributi per tutti gli object contenuti, tra cui
periodi di conservazione e quote.
Poiché i namespace sono anche risorse globali, un object può essere indirizzato
utilizzando i relativi bucket e namespace da qualsiasi VDC collegato.
Accesso ai bucket
I bucket sono associati a un gruppo di replica. Se il gruppo di replica si estende a più
VDC, i contenuti del bucket vengono replicati in modo analogo nei VDC. Gli object in un
bucket appartenente a un gruppo di replica che si estende a due VDC, ad esempio VDC1
e VDC2, possono essere accessibili da VDC1 o VDC2. Gli object in un bucket
appartenente a un gruppo di replica associato solo a VDC1 sono accessibili
esclusivamente da VDC1 e non da altri VDC in un sistema ECS federato.
140
L'identità di un bucket e i relativi metadati, tra cui l'ACL associato, sono informazioni di
gestione globale in ECS, ovvero vengono replicate negli storage pool del sistema e sono
visibili da tutti i VDC nella federazione. Tuttavia, il bucket può essere elencato solo da un
VDC facente parte del gruppo di replica a cui appartiene il bucket.
Inoltre, i bucket in ECS appartengono sempre a un namespace.
Proprietà dei bucket
Un bucket appartiene a un namespace e anche gli utenti di object vengono assegnati a
un namespace. Ciascun utente di object può creare bucket solo nel namespace di
appartenenza. Ogni utente di object ECS può tuttavia essere assegnato come proprietario
di un bucket o un object, oppure come beneficiario di un bucket ACL, anche se l'utente
non appartiene allo stesso namespace del bucket o dell'object. In questo modo, bucket e
object possono essere condivisi tra gli utenti in namespace diversi. Ad esempio, in
un'impresa in cui un namespace è un dipartimento, un bucket o un object può essere
condiviso tra utenti in dipartimenti diversi.
Se un utente di object desidera accedere a un bucket in un namespace a cui non
appartiene, il namespace deve essere specificato mediante l'intestazione x-emcnamespace.
Accesso a un bucket durante un'interruzione temporanea dell'attività
ECS fornisce un meccanismo di interruzione temporanea dell'attività che consente il
retrieval degli object anche se la copia primaria dell'object non è disponibile a causa
dell'assenza di availability del sito che la ospita.
Poiché esiste il rischio che i dati dell'object sottoposti a retrieval durante l'interruzione
temporanea dell'attività non siano aggiornati, l'utente deve riconoscere la possibilità di
questa condizione contrassegnando il bucket come disponibile durante un'interruzione
dell'attività.
Attributi dei bucket
Il portale ECS consente la creazione e la gestione dei bucket nella pagina Manage >
Buckets.
La pagina Bucket Management fornisce una tabella che visualizza i bucket relativi a un
namespace selezionato. La tabella mostra gli attributi dei bucket e per ciascuno di essi
fornisce le azioni Edit Bucket, Edit ACL e Delete.
Gli attributi associati a un bucket sono descritti nella tabella riportata di seguito. Per
visualizzare e modificare gli attributi non visibili nella pagina Bucket Management, è
possibile selezionare Edit Bucket.
Concetti e attributi dei bucket
141
Tabella 23 Attributi dei bucket
Attributo
Descrizione
Nome
Nome del bucket. Per indicazioni sulla denominazione dei bucket, è
possibile fare riferimento al seguente argomento: Convenzioni di
denominazione per bucket e chiavi a pagina 151.
creata
Ora di creazione del bucket.
Replication Group
Gruppo di replica in cui verrà creato il bucket.
Namespace
Namespace a cui è associato il bucket.
Owner
Proprietario del bucket.
Notification Quota
Impostazione della quota in cui si riceverà una notifica. Si tratta di una
quota flessibile che può essere impostata autonomamente oppure in
aggiunta a una quota fissa.
La quota non può essere inferiore a 1 GB. La quota associata a un
bucket può essere modificata per tutta la sua durata.
Ulteriori informazioni sulle quote sono disponibili in: Gestione di un
tenant a pagina 84.
Max Quota
Quota fissa che, una volta raggiunta, impedirà l'accesso al bucket. È
possibile impostarne una flessibile che verrà attivata prima del
raggiungimento della quota rigida.
File System Enabled
Indica che ECS consentirà l'utilizzo del bucket come Hadoop Distributed
File System (HDFS).
Questa opzione deve essere impostata in fase di creazione del bucket.
Non potrà essere modificata in un secondo momento.
Non è possibile impostare un bucket File System Enabled per l'accesso
durante un'interruzione dell'attività.
CAS
Indica che il bucket è abilitato per i dati CAS.
Access During Outage
Un flag impostato sul bucket che specifica il comportamento durante
l'accesso ai dati nel bucket in presenza di una zona temporaneamente
non disponibile in una configurazione con federazione geografica.
Se si imposta il flag su ON e si verifica un'interruzione temporanea del
sito, gli object accessibili in questo bucket potrebbero essere stati
aggiornati, ma le modifiche potrebbero non essere state propagate nel
sito da cui si accede all'object. È pertanto lecito aspettarsi che gli object
letti possano non essere aggiornati.
Se il flag è impostato su OFF, i dati nella zona caratterizzata
dall'interruzione temporanea dell'attività non sono disponibili per
l'accesso da altre zone e gli object letti per i dati con copia primaria nel
sito non funzionante non saranno accessibili.
Il flag può essere attivato solo se File System Enabled è disattivato.
Bucket Retention
142
Imposta il periodo di conservazione per un bucket. Informazioni sul
periodo di conservazione sono disponibili in: Gestione di un tenant a
pagina 84.
La scadenza di un periodo di conservazione su un object in un bucket
viene calcolata quando si effettua una richiesta di modifica di un object
e si basa sul valore impostato nel bucket e negli object stessi.
Tabella 23 Attributi dei bucket (continua)
Attributo
Descrizione
Il periodo di conservazione non può essere modificato per l'intera durata
del bucket.
ACL di bucket
I privilegi di cui dispone un utente quando accede a un bucket vengono impostati
mediante ACL.
In fase di creazione di un bucket e di assegnazione di un proprietario, viene creato un
ACL che assegna un set predefinito di autorizzazioni al proprietario del bucket. Per
impostazione predefinita, al proprietario viene assegnato controllo completo.
È possibile modificare le autorizzazioni assegnate al proprietario oppure aggiungere
nuove autorizzazioni per un utente selezionando l'operazione Edit ACL per il bucket.
Nel portale ECS la pagina Bucket ACLs Management fornisce i pannelli User ACLs e Group
ACLs per gestire gli ACL associati a singoli utenti e gruppi predefiniti.
User ACLs
Il pannello User ACLs include gli ACL applicati agli utenti e ne consente l'assegnazione a
un utente mediante l'operazione Add.
Nella tabella seguente vengono fornite le spiegazioni degli ACL.
Tabella 24 ACL di bucket
ACL
Autorizzazione
Read
Consente all'utente di elencare gli object nel bucket.
Read ACL
Consente all'utente di leggere l'ACL del bucket.
Write
Consente all'utente di creare o aggiornare eventuali object nel bucket.
Write ACL
Consente all'utente di scrivere l'ACL per il bucket.
Esecuzione
Imposta l'autorizzazione di esecuzione quando si esegue l'accesso come file
system. L'autorizzazione non ha alcun effetto quando si accede all'object
mediante i protocolli di object di ECS.
Full Control
Conferisce all'utente le autorizzazioni Read, Write, Read ACL e Write ACL.
ACL di bucket
143
Tabella 24 ACL di bucket (continua)
ACL
Autorizzazione
Privileged Write Consente all'utente di eseguire scritture in un bucket o un object quando non
dispone di normale autorizzazione in scrittura. Necessario per i bucket CAS.
Delete
Consente all'utente di eliminare bucket e object. Necessario per i bucket CAS.
Nessuna
L'utente non dispone di privilegi nel bucket.
Nota
Poiché il portale ECS supporta bucket S3, HDFS e CAS, la gamma di autorizzazioni che
può essere impostata non è applicabile a tutti i tipi di bucket.
Group ACLs
È possibile impostare autorizzazioni per un set di gruppi predefiniti. Sono supportati i
seguenti gruppi:
public
Tutti gli utenti, autenticati o meno.
all users
Tutti gli utenti autenticati.
other
Utenti autenticati, ma non il proprietario del bucket.
log delivery
Non supportata.
Le autorizzazioni assegnabili sono elencate in Tabella 24 a pagina 143.
Creare un bucket mediante il portale ECS
Il portale ECS consente di creare bucket e permette di specificarne la configurazione. I
bucket creati nel portale possono essere di tipo S3, S3+HDFS o CAS.
Prima di cominciare
l
Per creare un bucket nel portale ECS, è necessario disporre del ruolo di Namespace
Admin o System Admin.
l
Gli utenti con ruolo di Namespace Admin possono creare bucket nel namespace.
l
Gli utenti con ruolo di System Admin possono creare un bucket appartenente a
qualsiasi namespace.
Procedura
1. Nel portale ECS selezionare Manage > Buckets.
2. Selezionare New Bucket.
3. Selezionare il gruppo di replica a cui è associato il bucket.
4. Selezionare il namespace a cui apparterranno il bucket e i relativi object.
Per gli utenti con ruolo di System Admin, se il sistema ECS dispone di più di un
namespace, selezionare quello a cui apparterrà il bucket.
Gli utenti con ruolo di Namespace Admin potranno selezionare esclusivamente il
proprio namespace.
144
5. Specificare un proprietario per il bucket.
Il proprietario deve essere un utente di object ECS del namespace. Se non si specifica
un utente, l'utente effettivo verrà assegnato come proprietario, ma non potrà
accedere al bucket, a meno che anche il nome utente non venga assegnato come
utente di object.
L'utente specificato disporrà di controllo completo.
6. Per ottenere un bucket di tipo CAS, impostare il controllo CAS su ON.
Per impostazione predefinita, il bucket verrà contrassegnato come di tipo S3.
7. Affinché il bucket supporti l'utilizzo di HDFS, impostare il controllo File System
Enabled su ON.
Ne risulterà un bucket di tipo S3 che supporta HDFS.
8. Se il bucket è di tipo CAS o S3 in cui non è stato impostato File System Enabled, è
possibile impostare Access During outage su ON.
9. Se necessario, specificare una quota per il bucket
Le impostazioni applicabili sono descritte in: Concetti e attributi dei bucket a pagina
140.
10.Se necessario, impostare un periodo di conservazione per il bucket.
Ulteriori informazioni sui periodi di conservazione sono disponibili in: Concetti e
attributi dei bucket a pagina 140.
11.Per creare il bucket, selezionare Save.
Risultati
È possibile assegnare utenti al bucket e impostare autorizzazioni per gli utenti (o gruppi
predefiniti) dal menu Actions della tabella dei bucket.
Modifica di un bucket
È possibile modificare alcune impostazioni del bucket dopo averlo creato e in seguito
alla scrittura di object al suo interno.
Prima di cominciare
l
Per modificare un bucket, è necessario disporre del ruolo di Namespace Admin o
System Admin.
l
Gli utenti con ruolo di Namespace Admin possono modificare l'impostazione per i
bucket appartenenti al proprio namespace.
l
Gli utenti con ruolo di System Admin possono modificare le impostazioni per un
bucket appartenente a qualsiasi namespace.
Procedura
2. Nella tabella Buckets selezionare l'azione Edit per il bucket di cui si desidera
modificare le impostazioni.
3. È possibile modificare i seguenti attributi del bucket:
l
Quota
l
Bucket Owner
Modifica di un bucket
145
l
Access During Outage
Nota
Non disponibile se nel bucket è impostato File System Enabled.
Non è possibile modificare i seguenti attributi del bucket:
l
Replication Group
l
File Access Enabled
l
CAS enabled
Ulteriori informazioni su queste impostazioni sono disponibili in: Concetti e attributi
dei bucket a pagina 140.
Impostazione delle autorizzazioni ACL dei bucket per un utente
Il portale ECS consente di impostare l'ACL di un bucket per un utente o un gruppo
predefinito.
Prima di cominciare
l
Per modificare l'ACL per un bucket, è necessario disporre del ruolo di Namespace
Admin o System Admin.
l
Gli utenti con ruolo di Namespace Admin possono modificare le impostazioni ACL per
i bucket appartenenti al proprio namespace.
l
Gli utenti con ruolo di System Admin possono modificare le impostazioni ACL per un
bucket appartenente a qualsiasi namespace.
Procedura
2. Nella tabella Buckets selezionare l'azione Edit ACL per il bucket di cui si desidera
3. Per impostare le autorizzazioni ALC per un utente, selezionare il pulsante User ACLs.
Per selezionare l'ACL per un gruppo, fare clic su Group ACLs. Per ulteriori informazioni
sull'impostazione di ACL per gruppi, è possibile fare riferimento a Impostazione delle
autorizzazioni ACL dei bucket per un gruppo predefinito a pagina 147.
4. È possibile modificare le autorizzazioni già assegnate a un utente oppure aggiungere
un utente per cui si desidera assegnare autorizzazioni.
l
Per impostare o rimuovere le autorizzazioni ACL già assegnate a un utente,
selezionare Edit o Remove dalla colonna Action nella tabella ACL.
l
Per aggiungere un utente a cui assegnare autorizzazioni, selezionare Add.
All'utente impostato come proprietario del bucket saranno già assegnate
autorizzazioni predefinite.
5. In caso di aggiunta di ACL, immettere il nome dell'utente a cui si applicheranno le
autorizzazioni.
6. Specificare le autorizzazioni che si desidera applicare all'utente.
Ulteriori informazioni sui privilegi ACL sono disponibili in Concetti e attributi dei
bucket a pagina 140.
146
Impostazione delle autorizzazioni ACL dei bucket per un gruppo
predefinito
Il portale ECS consente di impostare l'ACL di un bucket per un utente o un gruppo
predefinito.
Prima di cominciare
l
Per modificare l'ACL di gruppo per un bucket, è necessario disporre del ruolo di
Namespace Admin o System Admin.
l
Gli utenti con ruolo di Namespace Admin possono modificare le impostazioni ACL di
gruppo per i bucket appartenenti al proprio namespace.
l
Gli utenti con ruolo di System Admin possono modificare le impostazioni ACL di
gruppo per un bucket appartenente a qualsiasi namespace.
Procedura
2. Nella tabella Buckets selezionare l'azione Edit ACL per il bucket di cui si desidera
3. Per impostare le autorizzazioni ALC per un gruppo, selezionare il pulsante Group
ACLs.
Per selezionare l'ACL per un utente, fare clic su User ACLs. Per ulteriori informazioni
sull'impostazione di ACL per utenti, è possibile fare riferimento a Impostazione delle
autorizzazioni ACL dei bucket per un utente a pagina 146.
4. Selezionare il gruppo per cui si desidera assegnare privilegi ACL.
Ulteriori informazioni sui privilegi predefiniti sono disponibili in: Concetti e attributi
dei bucket a pagina 140
5. Selezionare i privilegi che si desidera assegnare al gruppo.
Creare bucket utilizzando le API basate su object
Quando si creano bucket utilizzando le API basate su object o strumenti che chiamano le
API basate su object, sono presenti numerose intestazioni che determinano il
comportamento.
Vengono fornite le seguenti intestazioni x-emc:
x-emc-dataservice-vpool
Determina il gruppo di replica che verrà utilizzato per archiviare object associati a
questo bucket. Se non si specifica un gruppo di replica utilizzando l'intestazione xemc-dataservice-vpool, ECS sceglierà il gruppo di replica predefinito
associato al namespace.
x-emc-file-system-access-enabled
Configura il bucket per l'accesso HDFS. L'intestazione non deve essere in conflitto
con l'interfaccia utilizzata. In altre parole, una richiesta di creazione di bucket da
HDFS non può specificare x-emc-file-system-access-enabled=false.
Impostazione delle autorizzazioni ACL dei bucket per un gruppo predefinito
147
x-emc-namespace
Specifica il namespace da utilizzare per questo bucket. Se il namespace non viene
specificato utilizzando la convenzione S3 della richiesta di stile host/percorso, può
essere specificato utilizzando l'intestazione x-emc-namespace. Se il namespace
non viene specificato come questa intestazione, viene utilizzato il namespace
associato all'utente.
x-emc-retention-period
Specifica il periodo di conservazione che verrà applicato agli object in un bucket.
Ogni volta che si effettua una richiesta per modificare un object in un bucket, la
scadenza del periodo di conservazione dell'object viene calcolata in base al periodo
associato al bucket.
x-emc-is-stale-enabled
Flag che indica se il bucket è accessibile durante un'interruzione dell'attività VDC
temporanea in una configurazione federata.
x-emc-project-id
Specifica l'ID progetto da associare al nuovo bucket. Si tratta di una funzionalità
importante per la generazione di report relativi ai dati di misurazione per l'utilizzo
dell'object. Se questa intestazione non è presente, viene utilizzato l'ID progetto
predefinito per il tenant associato.
Viene fornito un esempio di utilizzo dello strumento S3curl per generare un bucket.
l
Creazione di un bucket attraverso l'utilizzo di API S3 (con s3curl) a pagina 148
Creazione di un bucket attraverso l'utilizzo di API S3 (con s3curl)
È possibile utilizzare S3 API per creare un bucket in un gruppo di replica. Poiché ECS
utilizza intestazioni personalizzate (x-emc), la stringa da firmare deve essere progettata
per includere queste intestazioni. In questa procedura, viene utilizzato lo strumento
s3curl. Inoltre, vi sono vari client programmatici da utilizzare, come ad esempio il client
Java S3.
Prima di cominciare
l
In ECS deve essere configurato almeno un gruppo di replica.
l
Perl deve essere installato nella macchina Linux, su cui si intende eseguire s3curl.
l
Sarà necessario installare curl e disporre del modulo s3curl, che agisce come
wrapper attorno a curl.
Per utilizzare s3curl con intestazioni x-emc, devono essere apportate modifiche
secondarie allo script s3curl. Queste modifiche sono descritte nella procedura.
Procedura
1. Ottenere una chiave segreta per l'utente che creerà il bucket.
Fare riferimento all'articolo: Ricezione di una chiave segreta per l'accesso all'object
storage a pagina 156 per ulteriori informazioni.
2. Ottenere l'identità del gruppo di replica in cui si desidera creare il bucket.
Per ottenere l'identità del gruppo di replica, utilizzare ECS REST API:
GET https://<ECS IP Address>:4443/vdc/data-service/vpools
148
La risposta fornisce il nome e l'identità di tutti i virtual pool di data service. Ad
esempio:
<data_service_vpools>
<data_service_vpool>
<creation_time>1403519186936</creation_time>
<id>urn:storageos:ReplicationGroupInfo:8fc8e19b-edf0-4e81bee8-79accc867f64:global</id>
<inactive>false</inactive>
<tags/>
<description>IsilonVPool1</description>
<name>IsilonVPool1</name>
<varrayMappings>
<name>urn:storageos:VirtualDataCenter:1de0bbc2-907c-4edeb133-f5331e03e6fa:vdc1</name>
<value>urn:storageos:VirtualArray:793757ab-ad51-4038b80a-682e124eb25e:vdc1</value>
</varrayMappings>
</data_service_vpool>
</data_service_vpools>
L'ID è urn:storageos:ReplicationGroupInfo:8fc8e19b-edf0-4e81bee8-79accc867f64:global.
3. Configurare s3curl creando un file .s3curl in cui immettere le credenziali utente.
Il file .s3curl deve disporre di autorizzazioni 0600 (rw-/---/---) quando s3curl.pl
viene eseguito.
Nell'esempio riportato di seguito, il profilo "profilo_personale" viene utilizzato per
fare riferimento alle credenziali utente per l'account "utente@yourco.com" e
"radice_profilo" fa riferimento alle credenziali dell'account radice.
%awsSecretAccessKeys = (
my_profile => {
id => 'user@yourco.com',
key => 'sZRCTZyk93IWukHEGQ3evPJEvPUq4ASL8Nre0awN'
},
root_profile => {
id => 'root',
key => 'sZRCTZyk93IWukHEGQ3evPJEvPUq4ASL8Nre0awN'
},
);
4. Aggiungere l'endpoint che si desidera utilizzare s3curl rispetto al file .s3curl.
Questo sarà l'indirizzo del nodo dati o del load balancer che si trova davanti al nodo
dati.
Ad esempio:
push @endpoints , (
'203.0.113.10',
);
'lglw3183.lss.emc.com',
5. Modificare lo script s3curl.pl in modo che includa le intestazioni x-emc in "stringa
da firmare"
Sostituire le seguenti righe:
elsif ($header =~ /^(?'header'[Xx]-(([Aa][Mm][Zz])|([Ee][Mm][Cc]))Creazione di un bucket attraverso l'utilizzo di API S3 (con s3curl)
149
[^:]+): *(?'val'.+)$/) {
my $name = lc $+{header};
my $value = $+{val};
con:
elsif ($header =~ /^([Xx]-(?:(?:[Aa][Mm][Zz])|(?:[Ee][Mm][Cc]))[^:]+): *(.+)$/) {
my $name = lc $1;
my $value = $2;
6. Creare il bucket utilizzando s3curl.pl.
Specificare quanto segue:
l
Profilo dell'utente.
l
Identità del gruppo di replica in cui creare il bucket (<vpool_id>). Tale operazione
deve essere impostata utilizzando l'intestazione x-emc-dataservice-vpool.
l
x-emc-file-system-access-enabled ovvero l'intestazione per
l'abilitazione dell'accesso al file system.
l
Nome del bucket (<BucketName>).
Il comando completamente specificato presenta le seguenti caratteristiche:
./s3curl.pl --debug --id=my_profile --acl public-read-write
--createBucket -- -H 'x-emc-file-system-access-enabled:true'
-H 'x-emc-dataservice-vpool:<vpool_id>' http://<DataNodeIP>:9020/
<BucketName>
Tenere presente che l'argomento -acl public-read-write è opzionale, ma
necessario se si programma l'accesso al bucket in un ambiente anonimo. Ad
esempio, se si intende accedere al bucket come HDFS da un ambiente che non è
protetto attraverso il protocollo Kerberos.
In caso di esito positivo (con --debug attivo) dovrebbe apparire un output simile al
seguente:
s3curl: Found the url: host=203.0.113.10; port=9020; uri=/S3B4;
query=;
s3curl: ordinary endpoint signing case
s3curl: StringToSign='PUT\n\n\nThu, 12 Dec 2013 07:58:39 +0000\nxamz-acl:public-read-write
\nx-emc-file-system-access-enabled:true\nx-emc-dataservice-vpool:
urn:storageos:ReplicationGroupInfo:8fc8e19b-edf0-4e81bee8-79accc867f64:global:\n/S3B4'
s3curl: exec curl -H Date: Thu, 12 Dec 2013 07:58:39 +0000 -H
Authorization: AWS
root:AiTcfMDhsi6iSq2rIbHEZon0WNo= -H x-amz-acl: public-read-write L -H content-type:
--data-binary -X PUT -H x-emc-file-system-access-enabled:true
-H x-emc-dataservice-
150
vpool:urn:storageos:ObjectStore:e0506a04-340b-4e78a694-4c389ce14dc8: http://203.0.113.10:9020/S3B4
È possibile elencare i bucket attraverso l'interfaccia S3, utilizzando:
./s3curl.pl --debug --id=my_profile http://<DataNodeIP>:9020/
Convenzioni di denominazione per bucket e chiavi
I nomi di bucket e object/chiavi devono essere conformi alle specifiche illustrate di
seguito.
l
Denominazione di bucket e object S3 in ECS a pagina 151
l
Denominazione di container e object OpenStack Swift in ECS a pagina 152
l
Denominazione di bucket e object Atmos in ECS a pagina 152
l
Denominazione di pool e object CAS in ECS a pagina 152
Nota
Per utilizzare un bucket per HDFS, è consigliabile evitare caratteri di sottolineatura nel
nome del bucket, in quanto non sono supportati dalla classe Java URI. Ad esempio,
viprfs://my_bucket.ns.site/ non funzionerà in quanto si tratta di un URI non
valido, che pertanto non viene compreso da Hadoop.
Nome dei namespace
Le seguenti regole si applicano alla denominazione dei namespace in ECS:
l
Non possono essere costituiti da una stringa vuota o Null
l
Devono avere una lunghezza compresa tra 1 e 255 caratteri (Unicode)
l
I caratteri validi sono definiti da regex /[a-zA-Z0-9-_]+/. Pertanto:
n
Caratteri alfanumerici
n
Caratteri speciali: trattino (-) e carattere di sottolineatura (_).
Denominazione di bucket e object S3 in ECS
In questo argomento vengono fornite in dettaglio le regole applicabili alla denominazione
di bucket e object in caso di utilizzo di ECS S3 Object API.
Nome dei bucket
Le seguenti regole si applicano alla denominazione dei bucket S3 in ECS:
l
I nomi devono avere una lunghezza compresa tra uno e 255 caratteri. Per S3 i nomi di
bucket devono avere una lunghezza compresa tra 1 e 255 caratteri.
l
I nomi possono includere punti (.), trattini (-), caratteri di sottolineatura (_) e caratteri
alfanumerici ([a-zA-Z0-9]).
l
I nomi possono iniziare con un trattino (-) o un carattere alfanumerico.
l
Il nome deve rispettare le regole indicate di seguito.
n
Non può iniziare con un punto (.)
n
Non può contenere doppi punti (..)
n
Non può terminare con un punto (.)
Convenzioni di denominazione per bucket e chiavi
151
n
I nomi non devono essere in formato di indirizzo IPv4.
È possibile confrontare queste regole con le limitazioni di denominazione indicate nella
specifica S3: http://docs.aws.amazon.com/AmazonS3/latest/dev/
BucketRestrictions.html.
Nome oggetto
Le seguenti regole si applicano alla denominazione degli object S3 in ECS:
l
l
l
Nessuna convalida sui caratteri.
Denominazione di container e object OpenStack Swift in ECS
di bucket e object in caso di utilizzo di ECS OpenStack Swift Object API.
Nome contenitore
Le seguenti regole si applicano alla denominazione dei container Swift:
l
l
l
I caratteri validi sono definiti da regex /[a-zA-Z0-9\\.\\-_]+/
n
Caratteri alfanumerici
n
Caratteri speciali: punto (.), trattino (-) e carattere di sottolineatura (_).
Nome oggetto
Le seguenti regole si applicano alla denominazione degli object Swift:
l
l
l
Denominazione di bucket e object Atmos in ECS
di bucket e object in caso di utilizzo di ECS Atmos Object API.
Subtenant (bucket)
Viene creato dal server, pertanto il client non necessita di conoscere lo schema di
denominazione.
Nome di object
Le seguenti regole si applicano alla denominazione degli object Atmos:
l
l
l
Il nome deve essere espresso in codifica UTF-8 percentuale.
Denominazione di pool e object CAS in ECS
di pool e object CAS ('clip' in terminologia CAS) in caso di utilizzo di CAS API.
152
Denominazione di pool CAS
Le seguenti regole si applicano alla denominazione dei pool CAS in ECS:
l
È consentito una massimo di 255 caratteri
l
Non possono contenere: ' " / & ? * < > <tab> <newline> o <space>
Denominazione di clip
Non esistono chiavi definite dall'utente in CAS API. Quando un'applicazione che utilizza
CAS API crea un clip, lo apre in un pool, crea un nuovo clip e aggiunge tag, attributi, flussi
e così via. Una volta completato, il clip verrà scritto in un device.
Viene restituito un ID clip corrispondente dal motore CAS, a cui si può fare riferimento
mediante <pool name>/<clip id>.
Denominazione di pool e object CAS in ECS
153
154
CAPITOLO 19
Ricezione di una chiave segreta per l'accesso
all'object storage
l
l
l
Introduzione....................................................................................................... 156
Creazione di una chiave per un utente di object.................................................. 156
Creazione di una chiave segreta S3: SELF-SERVICE.............................................. 157
155
Introduzione
Gli utenti degli object service di ECS richiedono una chiave segreta per consentire
l'autenticazione con un servizio.
Le chiavi segrete possono essere create e rese disponibili all'utente di object nei modi
descritti di seguito.
l
L'amministratore crea una chiave e la distribuisce all'utente di object (Creazione di
una chiave per un utente di object a pagina 156).
l
L'utente di object, che è un utente di dominio, crea una nuova chiave mediante l'API
self-service fornita da ECS Management REST API (Creazione di una chiave segreta
S3: SELF-SERVICE a pagina 157).
Creazione di una chiave per un utente di object
Gli utenti di ECS Management possono creare una chiave segreta per un utente di object.
l
Generare una chiave segreta dal portale ECS a pagina 156
l
Creare una chiave segreta S3 mediante ECS Management REST API a pagina 156
Generare una chiave segreta dal portale ECS
È possibile generare una chiave segreta nel portale ECS.
Prima di cominciare
l
È necessario disporre del ruolo di System Admin o Namespace Admin in ECS
Gli utenti con ruolo di System Admin possono creare una chiave segreta per un utente di
object appartenente a qualsiasi namespace. Gli utenti con ruolo di Namespace Admin
possono creare una chiave segreta per un utente di object appartenente ai propri
namespace.
Procedura
1. Nel portale ECS selezionare la pagina Manage > Users.
2. Nella tabella Object Users selezionare Edit per l'utente a cui si desidera assegnare
una chiave segreta.
3. Per S3 selezionare Generate & Add Password.
4. Copiare la chiave generata e inviarla tramite email all'utente di object.
Creare una chiave segreta S3 mediante ECS Management REST API
ECS Management REST API consente a un utente di gestione di creare una chiave segreta
per un utente di object S3.
L'API è indicata di seguito.
156
Percorso API
Descrizione
/object/usersecret-keys/
{uid}
API per consentire l'assegnazione di chiavi segrete a utenti di object e la
relativa gestione.
Percorso API
Descrizione
Gli utenti con ruolo di Namespace Admin possono creare chiavi per gli
utenti nel proprio namespace. Gli utenti con ruolo di System Admin
possono assegnare chiavi agli utenti in qualsiasi namespace.
Ulteriori informazioni sulla chiamata API sono disponibili in ECS Management REST API
reference.
Creazione di una chiave segreta S3: SELF-SERVICE
ECS Management REST API consente agli utenti di dominio autenticati di richiedere una
chiave segreta per l'accesso all'object store.
È possibile utilizzare ECS Management REST API Reference se si desidera creare un client
personalizzato per l'esecuzione di determinate operazioni di gestione ECS. Per
operazioni semplici, gli utenti di dominio possono utilizzare un client HTTP basato su
browser o curl per eseguire l'API e creare una chiave segreta.
Quando un utente esegue l'API object/secret-keys, ECS crea automaticamente un
utente di object e assegna una chiave segreta.
Percorso API
Descrizione
/object/secret- API per consentire agli utenti del client S3 di creare una nuova chiave
segreta che conferisca loro l'accesso a object e bucket nel relativo
keys
namespace.
Viene anche definita API self-service.
Il payload per /object/secret-keys può includere un'ora di scadenza per la chiave
esistente.
<secret_key_create_param>
<existing_key_expiry_time_mins></existing_key_expiry_time_mins>
</secret_key_create_param>
Se si crea una chiave segreta per la prima volta, è possibile omettere il parametro
existing_key_expiry_time_mins e una chiamata risulterebbe come indicato di seguito.
POST object/secret-keys
Request body
<?xml version="1.0" encoding="UTF-8"?>
<secret_key_create_param/>
Response
<user_secret_key>
<secret_key>...</secret_key>
<key_timestamp>...</key_timestamp>
<link rel="..." href="..." />
</user_secret_key>
Utilizzo di chiavi self-service
È possibile eseguire numerose operazioni con chiavi segrete self-service utilizzando ECS
Management REST API Reference.
Creazione di una chiave segreta S3: SELF-SERVICE
157
Negli esempi forniti viene utilizzato lo strumento curl per dimostrare le attività indicate
di seguito.
l
Effettuare il login come utente di dominio a pagina 158
l
Generare la prima chiave a pagina 158
l
Generare la seconda chiave a pagina 159
l
Controllare le chiavi a pagina 159
l
Eliminare tutte le chiavi segrete a pagina 159
Effettuare il login come utente di dominio
È possibile effettuare il login come utente di dominio e ottenere un token di
autenticazione utilizzabile per autenticare le richieste successive.
curl -ik -u user@mydomain.com:<Password> https://10.241.48.31:4443/
login
HTTP/1.1 200 OK
Date: Mon, 27 Apr 2015 17:29:38 GMT
Content-Type: application/xml
Content-Length: 107
Connection: keep-alive
X-SDS-AUTH-TOKEN:
BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC
51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<loggedIn>
<user>tcas@corp.sean.com</user>
</loggedIn>
Controllare i dettagli utente
È possibile controllare i dettagli per un utente. In questo caso, l'utente appartiene al
namespace "ns1" ed è un NAMESPACE_ADMIN.
curl -ks -H "X-SDS-AUTH-TOKEN:
BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQI
ADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtM
TQ1YzRjOTdlNGQ0AgAC0A8="
https://10.241.48.31:4443/user/whoami | xmllint --format <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user>
<common_name>user@mydomain.com</common_name>
<distinguished_name/>
<namespace>ns1</namespace>
<roles>
<role>NAMESPACE_ADMIN</role>
</roles>
</user>
Generare la prima chiave
È possibile generare una chiave segreta.
BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAw
NzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOT
dlNGQ0AgAC0A8="
-H "Content-Type: application/json" -X POST -d "{}"
https://10.241.48.31:4443/object/secret-keys | xmllint --format <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user_secret_key>
<link rel="self" href="/object/user-secret-keys/
tcas@corp.sean.com"/>
<secret_key>7hXZ9/EHTVvmFuYly/z3gHpihXtEUX/VZxdxDDBd</secret_key>
158
<key_expiry_timestamp/>
<key_timestamp>2015-04-27 17:39:13.813</key_timestamp>
</user_secret_key>
Generare la seconda chiave
È possibile generare una seconda chiave segreta e impostare la scadenza per la prima.
BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwN
zQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTd
lNGQ0AgAC0A8="
-H "Content-Type: application/json" -X POST -d
"{\"existing_key_expiry_time_mins\": \"10\"}"
<user_secret_key>
<link rel="self" href="/object/user-secret-keys/
tcas@corp.sean.com"/>
<secret_key>l3fPCuFCG/bxoOXCPZoYuPwhXrSTwU0f1kFDaRUr</secret_key>
<key_expiry_timestamp/>
<key_timestamp>2015-04-27 17:40:12.506</key_timestamp>
</user_secret_key>
Controllare le chiavi
È possibile controllare le chiavi assegnate. In questo caso sono disponibili due chiavi, la
prima delle quali con una data e un'ora di scadenza
dlNGQ0AgAC0A8="
<user_secret_keys>
<secret_key_1>7hXZ9/EHTVvmFuYly/z3gHpihXtEUX/VZxdxDDBd</
secret_key_1>
<secret_key_2>l3fPCuFCG/bxoOXCPZoYuPwhXrSTwU0f1kFDaRUr</
secret_key_2>
<key_expiry_timestamp_1>2015-04-27 17:50:12.369</
key_expiry_timestamp_1>
<key_expiry_timestamp_2/>
<key_timestamp_1>2015-04-27 17:39:13.813</key_timestamp_1>
<key_timestamp_2>2015-04-27 17:40:12.506</key_timestamp_2>
<link rel="self" href="/object/secret-keys"/>
</user_secret_keys>
Eliminare tutte le chiavi segrete
Se è necessario eliminare le chiavi segrete prima di rigenerarle. È possibile utilizzare
quanto indicato di seguito.
dlNGQ0AgAC0A8="
-H "Content-Type: application/json" -X POST -d "{}" https://
10.241.48.31:4443/object/secret-keys/deactivate
Utilizzo di chiavi self-service
159
160
CAPITOLO 20
Configurazione del supporto per applicazioni CAS
SDK con il portale ECS
l
l
l
l
l
l
l
Configurazione del supporto CAS in ECS..............................................................162
Conservazione CAS in ECS...................................................................................162
Configurazione di policy di conservazione dei namespace.................................. 164
Configurazione di un bucket per CAS...................................................................165
Configurazione di un utente di object CAS........................................................... 166
Configurazione di ACL di bucket per un utente.....................................................167
ECS REST API che supportano utenti CAS.............................................................169
Configurazione del supporto per applicazioni CAS SDK con il portale ECS
161
Configurazione del supporto CAS in ECS
Viene introdotto il supporto CAS (content-addressable storage) in ECS.
ECS CAS consente alle applicazioni client basate su CAS SDK di archiviare, recuperare ed
eliminare fixed content object dallo storage ECS.
È necessario eseguire il provisioning dello storage ECS sottostante prima di configurare
un profilo ECS. Il provisioning viene in genere completato all'installazione di un nuovo
rack ECS. Questa condizione include la configurazione di uno storage pool, un VDC e un
gruppo di replica. All'interno di ECS non sono presenti funzionalità specifiche di CAS in
questi object, pertanto è possibile utilizzare la documentazione standard per creare o
modificare questi object per il supporto di CAS. Vedere Configurazione di storage pool,
VDC e gruppi di replica a pagina 48.
Successivamente, configurare namespace, utenti e bucket utilizzando la
documentazione standard:
l
Configurazione di un namespace per un tenant a pagina 76
l
Aggiunta di utenti e assegnazione di ruoli a pagina 56
l
Creazione e configurazione di bucket a pagina 140
In questo documento viene descritto come modificare la configurazione di base per il
supporto di CAS:
l
Conservazione CAS in ECS a pagina 162
l
Configurazione di policy di conservazione dei namespace a pagina 164
l
Configurazione di un bucket per CAS a pagina 165
l
Configurazione di un utente di object CAS a pagina 166
l
Configurazione di ACL di bucket per un utente a pagina 167
l
ECS REST API che supportano utenti CAS a pagina 169
Conservazione CAS in ECS
Un C-Clip CAS può avere un periodo di conservazione che determina per quanto tempo
l'object associato verrà conservato nello storage ECS prima che un'applicazione possa
eliminarlo.
I periodi di conservazione vengono assegnati nel C-Clip per l'object dall'applicazione
CAS.
Se ad esempio un documento finanziario deve essere conservato per tre anni dalla data
di creazione, nel C-Clip associato verrà specificato un periodo di conservazione di tre
anni. È inoltre possibile specificare che il documento venga conservato a tempo
indeterminato.
Policy di conservazione (classi di conservazione)
Le policy di conservazione consentono l'acquisizione di use case di conservazione e
l'applicazione a C-Clip. Ad esempio, tipi diversi di documenti possono avere periodi di
conservazione differenti. Potrebbero essere richiesti i seguenti periodi di conservazione:
162
l
Aspetto finanziario: 3 anni
l
Legale: 5 anni
l
Email: 6 mesi
Se una policy di conservazione viene applicata a una serie di C-Clip, modificando la
policy, verrà modificato il periodo di conservazione di tutti gli object associati.
Le policy di conservazione vengono associate a namespace in ECS e riconosciute
dall'applicazione CAS come classi di conservazione.
Conservazione a livello di bucket non consigliata per CAS
ECS fornisce la conservazione a livello di bucket per tutti gli object service. Poiché la
conservazione a livello di bucket ha priorità rispetto alla conservazione a livello di object
CAS, probabilmente interferirà con l'applicazione CAS esterna.
Precedenza CAS
Se a un object CAS in ECS sono applicati più periodi di conservazione, il periodo con
valore superiore ha precedenza indipendentemente dalla modalità di applicazione della
conservazione.
Modalità di applicazione della conservazione CAS
È possibile definire policy di conservazione (classi di conservazione) in namespace nel
portale ECS o tramite ECS REST API. Vedere Configurazione di policy di conservazione dei
namespace a pagina 164.
L'applicazione CAS esterna può assegnare una classe o un periodo di conservazione
fisso al C-Clip durante la creazione.
In caso di applicazione di periodi di conservazione tramite API, specificare il periodo in
secondi.
ECS CAS tiene conto dell'ora di creazione del C-Clip per tutti i calcoli correlati alla
conservazione e non dell'ora di migrazione.
Modalità di creazione di policy di conservazione con ECS REST API.
È possibile creare periodi e policy di conservazione mediante ECS Management REST API,
di cui viene fornito un riepilogo di seguito.
Tabella 25 ECS REST API - Risorse per la conservazione
Metodologia
Descrizione
PUT /object/bucket/{bucketName}/retention
Il valore di conservazione di un bucket
definisce un periodo di conservazione
predefinito applicato a ogni object in un
bucket. Se pertanto si imposta un periodo di
conservazione di 1 anno, non sarà possibile
eliminare un object dal bucket per un anno.
GET /object/bucket/{bucketName}/retention
Restituisce il periodo di conservazione
attualmente impostato per un bucket
specificato.
POST /object/namespaces/namespace/
Per i namespace, l'impostazione della
conservazione opera come una policy, dove
ciascuna policy è costituita da una coppia
<Name>: <Retention period>. È possibile definire
un numero di policy di conservazione per un
namespace e assegnare una policy per nome a
un object nel namespace. In questo modo è
possibile modificare il periodo di conservazione
di un set di object con la stessa policy
Conservazione CAS in ECS
163
Tabella 25 ECS REST API - Risorse per la conservazione (continua)
Metodologia
Descrizione
assegnata modificando la policy
corrispondente.
PUT /object/namespaces/namespace/
{namespace}/retention/{class}
Aggiorna il periodo di una classe di
conservazione associata a un namespace.
GET /object/namespaces/namespace/
Restituisce le classi di conservazione definite
per un namespace.
Ulteriori informazioni sull'API REST sono disponibili qui: Utilizzo di ECS Management
REST API a pagina 256. Il riferimento online è disponibile qui: ECS Management REST API
Reference.
Configurazione di policy di conservazione dei namespace
Vengono fornite istruzioni di configurazione specifiche di CAS per le policy di
conservazione dei namespace.
La funzionalità Retention Policy per un namespace consente di definire e gestire classi di
conservazione CAS per tutti i C-Clip creati nel namespace.
Un namespace può includere varie policy di conservazione, in cui ciascuna policy
definisce un periodo di conservazione. Attraverso l'applicazione di una policy di
conservazione a una serie di C-Clip (con l'API), modificando la policy, verrà modificato il
periodo di conservazione di tutti gli object associati. Per CAS, le classi di conservazione
vengono applicate al C-Clip di un object dall'applicazione. Se un object rientra in un
periodo di conservazione, non sono consentite richieste di modifica.
Procedura
2. Per modificare la configurazione di un namespace esistente, scegliere l'azione Edit
associata al namespace esistente.
3. Aggiungere e configurare policy di conservazione.
a. Nell'area Retention Policies selezionare Add per aggiungere una nuova policy.
b. Immettere un nome per la policy.
c. Specificare il periodo per la policy di conservazione.
Selezionare la casella di controllo Infinite per accertarsi che gli object con questa
policy non vengano mai eliminati.
164
Figura 44 Nuova policy di conservazione
Figura 45 Policy di conservazione per un namespace
Configurazione di un bucket per CAS
Configurare un bucket per il supporto CAS.
Nota
Le policy di conservazione a livello di bucket non sono consigliate per CAS.
Procedura
1. Nel portaleECS selezionare Manage > Bucket.
2. Per modificare la configurazione di un bucket esistente, scegliere l'azione Edit
associata al bucket esistente.
3. Per abilitare il CAS per il bucket, selezionare il controllo CAS On.
Configurazione di un bucket per CAS
165
Configurazione di un utente di object CAS
Configurare un utente di object per l'utilizzo di CAS.
Quando si configura un utente di object, è possibile assegnare funzionalità CAS che
costituiranno gli elementi di un profilo CAS. Sarà possibile visualizzare il file PEA
risultante per l'utilizzo nelle applicazioni CAS.
Procedura
1. Nel portaleECS selezionare Manage > Users.
2. Per modificare la configurazione di un utente di object esistente, scegliere l'azione
Edit associata all'utente.
Figura 46 Impostazioni CAS per utenti di object
3. Nell'area CAS digitare una password (segreta) o scegliere Generate per generarne una
automaticamente.
4. Scegliere Set Password.
5. Scegliere Generate PEA File per generare il file PEA richiesto dall'applicazione per
l'autenticazione con lo storage CAS in ECS.
6. Impostando un bucket predefinito, ogni azione eseguita dall'utente che non specifica
un bucket utilizzerà il bucket predefinito specificato. Digitare il nome del bucket
predefinito e scegliere Set Bucket.
7. Scegliere Add Attribute per aggiungere un tag di metadati all'utente.
8. Aggiungere il nome e il valore del tag di metadati.
Per ulteriori informazioni sui tag di metadati, consultare la documentazione di CAS
SDK.
9. Scegliere Save Metadata.
166
Configurazione di ACL di bucket per un utente
Modificare l'ACL di un bucket per limitare l'accesso di un utente.
Modificare gli ACL dei bucket per gli utenti CAS. Alcuni ACL di bucket ECS sono associati
ad autorizzazioni CAS, altri non sono significativi per i dati CAS.
Procedura
1. Nel portaleECS selezionare Manage > Bucket.
2. Per modificare gli ACL di un bucket esistente, scegliere l'azione Edit ACL associata al
bucket esistente.
Figura 47 Modifica di ACL di bucket
3. Scegliere l'azione Edit associata all'utente.
Configurazione di ACL di bucket per un utente
167
Figura 48 Gestione di ACL di bucket
4. Modificare le autorizzazioni.
Tabella 26 ACL di bucket
168
Capacità SDK CAS
ECS ACL
Definizione di ACL
Read
lettura
Consente all'utente di
aprire C-Clip nel
bucket.
Write
scrittura
creare C-Clip nel
bucket.
Exist
lettura
aprire C-Clip nel
bucket.
Delete
eliminare
eliminare C-Clip dal
bucket.
Tabella 26 ACL di bucket (continua)
Capacità SDK CAS
ECS ACL
Definizione di ACL
Privileged Delete
scrittura con privilegi
Consente a un utente
di eseguire
l'eliminazione con
privilegi di un C-Clip.
L'eliminazione con
privilegi consente
all'utente di eliminare
un C-Clip nel periodo
di conservazione.
Clip-Enumeration
Al momento non
supportato in ECS
Periodo di conservazione
Al momento non
supportato in ECS
Nota
Solo Centera* supporta
LitHold (conservazione
ai fini legali).
Nota
Altri ACL ECS non sono significativi per CAS.
6. È inoltre possibile modificare gli ACL a livello di gruppo. I gruppi sono predefiniti e
l'appartenenza al gruppo è automatica, in base ai criteri utente. Scegliere Group ACLs.
7. Scegliere Add.
8. Selezionare il gruppo che si desidera modificare dall'elenco Group Name.
Tabella 27 Gruppi di ACL di bucket
Gruppo di ACL di bucket Descrizione
public
Tutti gli utenti, autenticati o meno.
all users
Tutti gli utenti autenticati.
other
Utenti autenticati, ma non il proprietario del bucket.
log delivery
Non supportata.
9. Modificare gli ACL e selezionare Save.
ECS REST API che supportano utenti CAS
Vengono descritte le risorse di ECS REST API utilizzabili per gestire le impostazioni degli
utenti e dei profili CAS.
ECS REST API che supportano utenti CAS
169
ECS Management REST API contiene risorse per la gestione di dati specifici di CAS per un
utente.
Descrizioni di risorse API REST
l
GET /object/user-cas/secret/{uid} : ottiene il segreto CAS per l'utente
specificato.
l
GET /object/user-cas/secret/{namespace}/{uid}: ottiene il segreto
CAS per il namespace e l'utente specificati.
l
POST /object/user-cas/secret/{uid}: crea o aggiorna il segreto CAS per
un utente specificato.
l
GET /object/user-cas/secret/{namespace}/{uid}/pea: genera un file
PEA per l'utente specificato.
l
POST /object/user-cas/secret/{uid}/deactivate: elimina il segreto
CAS per un utente specificato.
l
GET /object/user-cas/bucket/{namespace}/{uid}: ottiene il bucket
predefinito per il namespace e l'utente specificati.
l
GET /object/user-cas/bucket/{uid}: ottiene il bucket predefinito per un
utente specificato.
l
POST /object/user-cas/bucket/{namespace}/{uid}: aggiorna il bucket
predefinito per il namespace e l'utente specificati.
l
GET /object/user-cas/applications/{namespace}: ottiene le
applicazioni registrate in CAS per un namespace specificato.
l
POST /object/user-cas/metadata/{namespace}/{uid}: aggiorna le
applicazioni registrate in CAS per un namespace e un utente specificati.
l
GET /object/user-cas/metadata/{namespace}/{uid}: ottiene i metadati
utente CAS per il namespace e l'utente specificati.
Per ulteriori informazioni, vedere ECS Management REST API Reference.
170
PARTE 7
Capitolo 21, "Panoramica di HDFS"
Capitolo 22, "Configurazione di HDFS in un cluster Hadoop non sicuro"
Capitolo 23, "Configurazione di HDFS in un cluster Hadoop sicuro"
Capitolo 24, "Risoluzione dei problemi di una configurazione ECS HDFS"
Capitolo 25, "Riferimento delle proprietà del sito core di ECS HDFS"
171
172
CAPITOLO 21
Panoramica di HDFS
l
Cos'è HDFS?........................................................................................................ 174
Panoramica di HDFS
173
Panoramica di HDFS
Cos'è HDFS?
ECS HDFS è un file system compatibile con Hadoop (HCFS) che consente di eseguire
applicazioni Hadoop 2.0 sull'infrastruttura di storage ECS.
È possibile configurare la distribuzione Hadoop per l'esecuzione con il file system
Hadoop integrato, ECS HDFS o una combinazione di HDFS, ECS HDFS o altri file system
compatibili con Hadoop disponibili nell'ambiente. Nella figura riportata di seguito viene
illustrato in che modo ECS HDFS si integra con un cluster Hadoop esistente.
Figura 49 ECS Integrazione di HDFS in un cluster Hadoop
Hadoop Cluster
MapReduce Request
Hadoop Client
Job Tracker
Task Tracker
Task Tracker
Task Tracker
MapReduce
Task
MapReduce
Task
MapReduce
Task
ViPRFS JAR
ECS data
nodes
Appliance
ViPRFS JAR
ECS data
nodes
ViPRFS JAR
ECS data
nodes
Commodity
In un ambiente Hadoop configurato per l'utilizzo di ECS HDFS, ciascuno dei nodi di dati
ECS HDFS funziona come un NameNode Hadoop tradizionale. Ciò significa che tutti i nodi
di dati ECS HDFS sono in grado di accettare e gestire richieste HDFS.
Dopo aver configurato il client Hadoop per l'utilizzo di ECS HDFS anziché dell'HDFS
tradizionale, la configurazione punta a ECS HDFS per eseguire tutte le attività dell'HDFS.
Su ciascun nodo del client ECS HDFS, qualsiasi componente Hadoop tradizionale
utilizzerebbe il client ECS HDFS (JAR) per eseguire l'attività HDFS.
Per integrare ECS HDFS con un ambiente Hadoop esistente, è necessario disporre degli
elementi indicati di seguito.
174
Panoramica di HDFS
l
Un cluster Hadoop già installato e configurato. Nella tabella seguente sono elencate
le distribuzioni supportate.
Distribuzioni Hadoop supportate
Pivotal 2.1
Cloudera 5.0, Cloudera 5.1.3
Hortonworks 2.0
l
Hadoop installato e configurato in modo da supportare ECS HDFS, che richiede:
una licenza ECS non strutturata con metodi di accesso Object e HDFS;
n
un gruppo di replica ECS;
n
uno o più bucket che supportano l'accesso a HDFS.
n
Configurazione di Hadoop per l'utilizzo di ECS HDFS
Hadoop archivia le informazioni di configurazione del sistema in un file denominato
core-site.xml. La modifica del file core-site.xml è un'attività richiesta durante
la configurazione di ECS HDFS.
Esistono diversi tipi di proprietà da aggiungere o modificare in core-site.xml, tra cui:
l
l
l
l
ECS - Classi Java HDFS Questo set di proprietà definisce le classi di implementazione
di ECS HDFS contenute nel file JAR del client ECS HDFS. Sono obbligatorie.
Proprietà di posizione del file system: Queste proprietà definiscono l'URI del file
system (schema e autorità) da utilizzare durante l'esecuzione dei processi Hadoop e
gli indirizzi IP dei nodi di dati ECS ViPR per un file system ECS specifico.
Proprietà di conversione dell'identità: Queste proprietà consentono di eseguire il
mapping anonimo degli object posseduti agli utenti, nonché di specificare aree di
autenticazione utente.
Proprietà delle aree di autenticazione e delle entità servizio Kerberos: Queste
proprietà sono richieste in caso di esecuzione in un ambiente Hadoop con Kerberos
installato. Queste proprietà eseguono il mapping degli utenti di Hadoop e ECS HDFS.
core-site.xml si trova su ogni nodo del cluster Hadoop. È necessario aggiungere le
stesse proprietà a ciascuna istanza di core-site.xml.
Nota
Nel caso di distribuzioni Cloudera è consigliabile utilizzare Cloudera Safety Valve, mentre
con Hortonworks è preferibile utilizzare Hortonworks Ambari, per apportare queste
modifiche e renderle persistenti nel cluster.
ECS - URI HDFS per l'accesso al file system
Dopo aver configurato Hadoop per l'utilizzo del file system di ECS, è possibile accedervi
specificando come schema l'URI di ECS HDFS con viprfs:// e come autorità una
combinazione di bucket ECS, tenant namespace e nome dell'installazione definito
dall'utente.
L'URI di ECS HDFS è simile a quanto segue:
viprfs://bucket_name.namespace.installation/path
bucket_name corrisponde a un bucket abilitato per HDFS. Contiene i dati da analizzare
con Hadoop. namespace corrisponde a un tenant namespace, mentre installation_name è
Configurazione di Hadoop per l'utilizzo di ECS HDFS
175
Panoramica di HDFS
il nome assegnato a un determinato set di nodi ECS o al load balancer. ECS HDFS risolve
installation_name in un set di nodi ECS o un load balancer utilizzando la proprietà
fs.vipr.installation.installation_name.hosts, che include gli indirizzi IP dei nodi ECS o del
load balancer.
Se installation_name viene mappato a un set di nodi ECSECS, si può specificare la
frequenza per interrogare ECS in modo da ottenere l'elenco dei nodi attivi impostando
fs.vipr.installation.[installation_name].resolution su dynamic e fs.vipr.installation.
[installation_name].resolution.dynamic.time_to_live_ms per indicare tale frequenza
tramite ECS.
Con un ambiente Hadoop che utilizza sicurezza semplice si può specificare l'URI di ECS
HDFS come file system predefinito in core-site.xml impostandolo come valore della
proprietà fs.defaultFS, anche se non è un requisito. Con un ambiente Hadoop protetto
tramite Kerberos, non è supportata l'impostazione di ECS HDFS come file system
predefinito. L'impostazione di questo valore su ECS HDFS richiede particolare attenzione
in fase di pianificazione generale dell'integrazione di Hadoop in ECS HDFS. Se non si
specifica ECS HDFS come file system predefinito, è necessario utilizzare l'URI completo
con il percorso ogni volta che si accede ai dati ECS. Se le applicazioni esistenti utilizzano
già un file system predefinito diverso, è necessario aggiornarle.
Hadoop - Modalità di autenticazione
ECS HDFS si integra con i cluster Hadoop configurati per l'utilizzo delle modalità di
autenticazione semplice o Kerberos. Per gestire ciascuna modalità, è necessario
impostare diverse proprietà in core-site.xml per assicurarsi che gli utenti e i servizi
possano accedere ai dati necessari.
Hadoop è caratterizzato da applicazioni che accedono ai dati archiviati nei bucket ECS.
Ciò significa che gli utenti Hadoop devono disporre delle autorizzazioni per leggere gli
object che stanno tentando di leggere e delle autorizzazioni per scrivere nei bucket in cui
stanno cercando di scrivere. Hadoop dispone di servizi (quali mapred, hive e hbase) che
devono disporre di autorizzazioni per scrivere i file system.
Tabella 28 Hadoop - Riepilogo delle modalità di autenticazione
Modalità di
autenticazione
Hadoop utente
ECS utente
Autorizzazioni
bucket
Semplice
Gli utenti Unix possono essere utenti
o servizi. Alcuni esempi includono:
anonimo
Controllo
completo di tutti
gli utenti
(obbligatorio)
L'utente scrive i
file come
sally@emc.co
m
Hadoop - I servizi
scrivono i file
system come
mapred@emc.c
om
Assegnare le
autorizzazioni
agli utenti in base
alle necessità.
Kerberos
l
root
l
sally
l
cloudera
l
mapred
Un utente esegue l'autenticazione
tramite kinit, ad esempio:
# kinit sally@emc.com
Gli utenti dei servizi sono definiti
dalla proprietà
viprfs.security.principal in coresite.xml.
176
Panoramica di HDFS
Nella tabella seguente sono indicati gli ACL predefiniti applicati ai file e alle directory
nelle modalità di autenticazione Kerberos e semplice.
Tabella 29 Elenchi ACL predefiniti
Nome
Autenticazione semplice Autenticazione Kerberos
File
666
644
Directory 777
755
Modalità di autenticazione semplice di Hadoop
In un cluster Hadoop eseguito in modalità semplice, quando gli utenti creano file,
directory e object, la stringa riferita al proprietario risulta vuota e vi si fa riferimento come
object anonimo o di proprietà anonima. Ciò potrebbe causare problemi per alcune
applicazioni che eseguono i controlli ACL.
Per risolverli, impostare la proprietà fs.viprfs.auth.anonymous_translation in coresite.xml su CURRENT_USER. Questa impostazione fa in modo che i file con
proprietario anonimo siano mostrati come se fossero di proprietà dell'utente UNIX
corrente. Questo esempio mostra cosa succede quando la proprietà
fs.viprfs.auth.anonymous_translation è impostata su NONE:
# hadoop fs -ls /
14/01/30 11:36:23 INFO vipr.ViPRFileSystem: Initialized ViPRFS (atom
1.0.1.0-811) for viprfs://hdfs.s3.docsite
d------rwx
0 2014-01-30 10:42 /bar
d------rwx
0 2014-01-30 10:34 /fooDir
d------rwx
0 2014-01-30 06:15 /tmp
Se si modifica l'impostazione in CURRENT_USER e l'utente connesso è root, l'utente root
diventa il proprietario:
# hadoop fs -ls /
14/01/30 11:30:37 INFO vipr.ViPRFileSystem: Initialized ViPRFS (atom
1.0.1.0-811) for viprfs://hdfs.s3.docsite
Found 3 items
drwx------ root
0 2014-01-30 10:42 /bar
drwx------ root
0 2014-01-30 10:34 /fooDir
drwx------ root
0 2014-01-30 06:15 /tmp
In modalità anonima, configurare i bucket di ECS per consentire l'accesso a chiunque
affinché i processi di Hadoop possano accedere ai bucket di ECS.
ECS HDFS fornisce la proprietà fs.viprfs.auth.identity_translation come metodo di
mapping degli utenti a un'area di autenticazione quando Kerberos non è installato. Se si
deve eseguire il comando chown per un file, è possibile specificare l'area di
autenticazione da utilizzare. Ad esempio:
hdfs dfs -chown sally@MYREALM.COM /sallys/new/file
Quando si specifica NONE, gli utenti devono digitare l'area di autenticazione a ogni
esecuzione del comando chown per un file. In caso contrario, è possibile specificare
FIXED_REALM per comodità e, quindi, indicare l'effettiva area di autenticazione da
utilizzare nella proprietà fs.viprfs.auth.realm.
<property>
<name>fs.viprfs.auth.identity_translation</name>
Hadoop - Modalità di autenticazione
177
Panoramica di HDFS
<value>FIXED_REALM</value>
</property>
<property>
<name>fs.viprfs.auth.realm</name>
<value>MYREALM.COM</value>
</property>
Si sconsiglia di usare il comando chown in modalità anonima. Quando si esegue il
comando chown per file o directory, la stringa vuota viene compilata con il proprietario
effettivo. Una volta assegnato un proprietario ai file o alle directory, gli utenti anonimi
non potranno più accedervi.
Modalità di autenticazione Kerberos di Hadoop
Quando Kerberos e il server Active Directory di ECS sono integrati, l'area di
autenticazione Kerberos fornisce un unico namespace in modo che gli utenti di Hadoop
autenticati con kinit siano riconosciuti come utenti con credenziali ECS.
In un cluster Hadoop eseguito in modalità Kerberos, è necessario un trust unidirezionale
dall'area di autenticazione Kerberos all'area di autenticazione di Active Directory
utilizzata per autenticare gli utenti di ECS.
Le seguenti proprietà di conversione dell'identità in core-site.xml sono utilizzate per
garantire la corretta conversione degli utenti da Hadoop a ECS:
l
fs.permissions.umask-mode: Impostare il valore su 027.
l
fs.viprfs.auth.anonymous_translation: Impostare il valore su CURRENT_USER.
l
fs.viprfs.auth.identity_translation: Impostare il valore su CURRENT_USER_REALM in
modo che l'area di autenticazione degli utenti sia rilevata automaticamente.
Altrimenti, impostarlo su FIXED_REALM per rendere hardcoded l'area di
autenticazione utente utilizzando la proprietà fs.viprfs.auth.realm.
Inoltre, è necessario impostare le seguenti proprietà in core-site.xml per definire
un'entità di servizio:
l
viprfs.security.principal
PIG e ACL
Poiché PIG esegue i controlli ACL per determinare se un utente dispone delle
autorizzazioni appropriate per un object, è necessario effettuare le seguenti operazioni
quando si esegue PIG a livello superiore di ECS HDFS.
l
l
Opzione 1: Impostare le seguenti proprietà in core-site.xml:
n
fs.<scheme>.auth.identity_translation = CURRENT_USER_REALM (in modalità di
autenticazione Kerberos) o FIXED_REALM (in modalità di autenticazione semplice)
n
fs.<scheme>.auth.anonymous_translation = CURRENT_USER
Opzione 2: Impostare la seguente variabile di ambiente:
n
$VIPR_LOCAL_USER_MODE ="true"
Supporto per SymLink
In un file system HDFS standard, il link simbolico che non specifica l'URI completo di un
file fa riferimento a un percorso nella stessa istanza di HDFS.
Lo stesso vale per ECS HDFS. Quando non si specifica l'URI completo come symlink, ECS
HDFS utilizza il namespace e il bucket correnti come root. Per fornire il symlink di un file
all'esterno del namespace e del bucket correnti, è necessario fornire l'URI completo che
include sia lo schema sia l'autorità.
178
Panoramica di HDFS
Nota
Hadoop 2.2 non supporta i symlink.
Interazione con il file system
Quando si interagisce direttamente con ECS HDFS, è possibile notare le seguenti
differenze rispetto all'interazione con il file system HDFS standard:
l
Le applicazioni che si aspettano che il file system sia un'istanza di
DistributedFileSystem non funzionano. Le applicazioni impostate come hardcoded
per funzionare con l'implementazione HDFS integrata richiedono che le modifiche
utilizzino ECS HDFS.
l
ECS HDFS non supporta i checksum dei dati.
l
Quando si utilizza la funzione listCorruptFileBlocks, tutti i block vengono segnalati
come integri, poiché ECS HDFS non concepisce block danneggiati.
l
Il fattore di replica viene sempre segnalato come costante N, dove N=1. I dati sono
protetti dallo SLA ECS, non dalla replica Hadoop.
Applicazioni di Hadoop non supportate
ECS HDFS non supporta un piccolo subset di applicazioni Hadoop.
l
HttpFS
l
Hue
l
Cloudera Impala
l
Apache Oozie
Le seguenti applicazioni Hadoop non sono supportate con un cluster Hadoop (Kerberos)
sicuro.
l
HBase
l
Hive
Interazione con il file system
179
Panoramica di HDFS
180
CAPITOLO 22
Configurazione di HDFS in un cluster Hadoop non
sicuro
l
Configurazione di ECS HDFS................................................................................ 182
181
In questo articolo viene descritto come configurare la distribuzione Hadoop esistente per
l'utilizzo dei dati nell'infrastruttura di storage ECS con ECS HDFS. Utilizzare questa
procedura dettagliata se la distribuzione Hadoop è configurata per l'utilizzo
dell'autenticazione semplice e non dell'autenticazione Kerberos.
Se la distribuzione Hadoop è configurata per l'autenticazione Kerberos, seguire i
passaggi descritti qui a pagina 194.
Per eseguire questa procedura di integrazione, è necessario disporre:
l
di una conoscenza operativa della distribuzione Hadoop e degli strumenti associati;
l
delle credenziali Hadoop che consentono di accedere ai nodi Hadoop, modificare i
file di sistema Hadoop e avviare e arrestare i servizi Hadoop.
Pianificare l'integrazione di ECS HDFS e Hadoop
Questo elenco può essere utilizzato per verificare di disporre delle informazioni
necessarie per garantire un'integrazione corretta.
Tabella 30 ECS HDFS - Prerequisiti di configurazione
Elemento
Operazione da eseguire
Hadoop cluster
Verificare che il cluster sia installato e in funzione.
Registrare le credenziali dell'amministratore per utilizzarle
successivamente in questa procedura.
ECS - Cluster: nodi ECS Registrare gli indirizzi IP dei nodi ECS per utilizzarli successivamente in
questa procedura.
ECS - Cluster: gruppo
di replica
Verificare che ECS disponga di un gruppo di replica.
HDFS richiede che un bucket abilitato per HDFS venga creato in un
gruppo di replica ECS e che il bucket sia accessibile come filesystem
mediante il nome del namespace e del bucket.
ECS - Cluster:
namespace del tenant
Verificare che sia configurato un namespace del tenant. Registrare il
nome.
Per integrare ECS HDFS con il cluster Hadoop, eseguire le attività indicate di seguito.
1. Come ottenere il pacchetto di installazione e supporto ViPR HDFS a pagina 183
2. Creazione di un bucket per HDFS a pagina 183
3. Implementare il file JAR ViPR HDFS a pagina 184 oppure Utilizzo di un parcel
Cloudera per installare Hadoop in un cluster a pagina 185
4. Modificare core-site.xml. a pagina 186
5. Riavviare i seguenti servizi:
182
l
HDFS
l
MapReduce
l
Pivotal HAWQ (solo se si utilizza questo servizio)
l
YARN (in caso di utilizzo di Hortonworks)
Nota
Se si utilizza Cloudera Manager Safety Valve per modificare le proprietà di coresite.xml, Cloudera Manager riavvierà tutti i servizi per impostazione predefinita.
6. Verificare che i servizi vengano riavviati correttamente.
Nota
Alcuni servizi, ad esempio namenode datanode, non verranno avviati, poiché
default.fs è impostato su ViPRFS ed ECS assume queste attività in una configurazione
non Kerberos
7. Assicurarsi di disporre dell'accesso al file system.
Quando si utilizza HBase, eseguire queste attività aggiuntive:
1. Modificare hbase-site.xml HBASE a pagina 190.
2. Riavviare i servizi HBase.
Il file JAR ECS HDFS e gli strumenti di supporto HDFS vengono forniti in un file ZIP
hdfsclient-1.2.0.0-<version>.zip, che è possibile scaricare dalle pagine di
supporto di ECS all'indirizzo support.EMC.com.
Il file ZIP contiene le directory \tools\bin, \playbooks, \client e \parcels.
Prima di decomprimere il file, creare una directory per conservare i contenuti zip (lo
strumento di decompressione lo può fare automaticamente), quindi estrarre i contenuti
nella directory. Dopo aver estratto i file, le directory conterranno quanto segue:
l
\tools\bin: contiene ViPRAdminTools.sh, che consente la creazione di bucket che
supportano l'accesso HDFS senza bisogno di utilizzare i protocolli di object ECS o il
portale ECS.
l
\playbooks: contiene playbook Ansible per configurare un ambiente Hadoop
sicuro per la comunicazione con ECS HDFS.
l
\client: contiene i file indicati di seguito.
l
n
ECS - File JAR (ViPPRFS) (viprfs-client-<ECS version>-hadoop<hadoop version>.jar): utilizzati per configurare diverse distribuzioni
Hadoop.
n
libvipr-<version>.so: utilizzato per configurare Pivotal HAWQ per l'uso con
ECS HDFS.
\parcels
n
Distribuzioni Cloudera in formato "parcel". I parcel includono il file JAR ViPRFS
appropriato.
Creazione di un bucket per HDFS
Il supporto Hadoop HDFS in ECS utilizza l'object store di ECS. I bucket per l'utilizzo da
parte di HDFS possono essere creati in numerosi modi, ma devono essere contrassegnati
per l'accesso HDFS.
Se si creano bucket per supportare un cluster Hadoop che utilizza la sicurezza semplice
(non Kerberos), è possibile utilizzare il portale ECS oppure le API basate su object, come
descritto nel seguente articolo:
183
l
Per informazioni sull'impostazione di autorizzazioni, fare riferimento a Impostazione di
autorizzazioni di bucket per HDFS a pagina 184.
Nota
Non è necessario utilizzare i trattini bassi nei nomi dei bucket poiché non sono
supportati dalla classe URI Java. Ad esempio, viprfs://my_bucket.ns.site/ non
funzionerà in quanto si tratta di un URI non valido, che pertanto non viene compreso da
Hadoop.
Impostazione di autorizzazioni di bucket per HDFS
Per poter utilizzare un bucket per l'accesso HDFS, è necessario verificare che le
autorizzazioni siano state impostate.
I bucket creati mediante i protocolli di accesso dati di ECS offrono controllo completo per
l'utente che li ha creati. Tuttavia, affinché un bucket possa essere utilizzato per HDFS,
deve essere impostato in modo che tutti gli utenti dispongano di controllo completo.
È possibile impostare autorizzazioni di bucket mediante un client grafico, ad esempio S3
Browser, oppure uno strumento da riga di comando, come s3curl.
Implementare il file JAR ECS HDFS
Utilizzare questa procedura per inserire il file JAR ECS HDFS nel classpath di ciascun nodo
del client nel cluster ECS.
Prima di cominciare
Ottenere il file JAR ECS HDFS per la distribuzione di ECS dal sito del supporto EMC per
ECS, come descritto in Ottenimento del pacchetto di installazione e supporto di ECS
HDFS a pagina 183.
Tabella 31 ECS - File JAR HDFS
- Distribuzione
Hadoop
ECS - File JAR HDFS
Pivotal HD
PHD 2.1: viprfs-client-1.2.0.0-hadoop-2.2.jar
Cloudera
Per le versioni Cloudera precedenti a CDH5 utilizzare: viprfsclient-1.2.0.0-hadoop-2.0.3-alpha.jar
Per le versioni Cloudera CDH5.0.x utilizzare: viprfsclient-1.2.0.0-hadoop-2.2.jar
Per le versioni Cloudera successive a CDH5.1.x utilizzare: viprfsclient-1.2.0.0-hadoop-2.3.jar
Hortonworks
HDP 2.0: viprfs-client-1.2.0.0-hadoop-2.2.jar
Nota
In presenza di una distribuzione Cloudera Hadoop, è possibile utilizzare i parcel Cloudera
forniti per installare una distribuzione Hadoop preconfigurata con il file JAR ViPRFS.
Vedere Utilizzo di un parcel Cloudera per installare Hadoop in un cluster a pagina 185.
184
Procedura
1. Accedere a un nodo del client ECS.
2. Eseguire il comando classpath per ottenere l'elenco delle directory nel classpath:
# hadoop classpath
3. Copiare il file JAR ECS HDFS in una delle cartelle elencate dal comando classpath
dopo la cartella /conf.
Distribuzione ECS
Posizione classpath (consigliata)
Pivotal HD
/usr/lib/gphd/hadoop/lib
Cloudera
/usr/lib/hadoop/lib
Hortonworks
/usr/lib/hadoop/lib
4. Ripetere questa procedura per ogni nodo del client ECS.
Cloudera utilizza parcel come meccanismo per distribuire software nei cluster CDH dalla
console di amministrazione di Cloudera Manager. ECS fornisce parcel Cloudera, definiti
parcel ViPRFS, preconfigurati per l'uso di ECS HDFS.
Prima di cominciare
I parcel Cloudera che includono il client ECS (ViPRFS) vengono forniti nell'installazione e
nel pacchetto di supporto ECS HDFS (vedere Ottenimento del pacchetto di installazione e
supporto di ECS HDFS a pagina 183).
Procedura
1. Creare un parcel repository
Per creare un parcel repository Cloudera, posizionare i file parcel ViPRFS in una
directory pubblicata da un web server. In genere l'hosting è all'interno della rete
personale.
2. Aggiungere il parcel repository ECS dall'interfaccia utente di Cloudera Manager
a. Passare ad Administration > Settings > Parcels.
b. Impostare la frequenza di aggiornamento dei parcel su 1 minuto per accelerare la
discovery.
c. Fare clic su Save Changes
3. Scaricare il parcel
Passare a Hosts > Parcels > Downloadable e scaricare il parcel ViPRFS più recente.
4. Distribuire il parcel nel cluster
È possibile distribuire più versioni di parcel ViPRFS, ma può essere attivata solo una
versione per volta.
Per eliminare un parcel, è necessario disattivarlo, quindi rimuoverlo dagli host. Tutte
le operazioni sopra indicate possono essere eseguite nell'interfaccia utente del
parcel.
5. Attivare il parcel
Un parcel distribuito può essere attivato premendo il pulsante Activate.
185
Cloudera Manager richiederà di riavviare il cluster per consentire l'utilizzo del nuovo
parcel da parte dei processi in esecuzione.
6. Fare clic su Restart per riavviare il cluster
Modificare il file core-site.xml di Hadoop
Utilizzare questa procedura per aggiornare core-site.xml in base alle proprietà
necessarie per integrare ECS HDFS con un cluster Hadoop che usa la modalità di
autenticazione semplice.
Prima di cominciare
È necessario disporre di un set di credenziali utente che consentano di accedere ai nodi
Hadoop e modificare core-site.xml.
La posizione di core-site.xml dipende dalla distribuzione in uso.
Tabella 32 Posizioni di core-site.xml
Distribuzione
Hadoop
Posizione core-site.xml
Nodi da
aggiornare
Pivotal HD
/etc/ghpd/hadoop/conf
ComputeMaster e
client
Cloudera
/etc/hadoop/conf
Tutti i nodi del
client
Hortonworks
/etc/hadoop/conf
Tutti i nodi
core-site.xml risiede su ogni nodo nel cluster Hadoop. È necessario modificare le
stesse proprietà in ogni istanza. È possibile apportare la modifica in un nodo e quindi
utilizzare il comando di copia sicura (scp) per copiare il file negli altri nodi del cluster.
Per ulteriori informazioni su ogni proprietà che è necessario impostare, vedere
Riferimento delle proprietà core_site.xml.
Procedura
1. Accedere a uno dei nodi HDFS in cui è situato core-site.xml.
2. Eseguire una copia di backup di core-site.xml.
cp core-site.xml core-site.backup
3. Utilizzare l'editor di testo preferito per aprire core-site.xml per la modifica.
Nota
Nel caso di distribuzioni Cloudera è consigliabile utilizzare Cloudera Safety Valve,
mentre con Hortonworks è preferibile utilizzare Hortonworks Ambari, per apportare
queste modifiche e renderle persistenti nel cluster.
4. Aggiungere le proprietà e i valori seguenti per definire le classi Java che
implementano il file system ECS HDFS:
<property>
<name>fs.viprfs.impl</name>
<value>com.emc.hadoop.fs.vipr.ViPRFileSystem</value>
</property>
<property>
<name>fs.AbstractFileSystem.viprfs.impl</name>
186
<value>com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem</value>
</property>
5. Aggiungere la proprietà fs.vipr.installations. Nell'esempio seguente il valore è
impostato su Site1.
<property>
<name>fs.vipr.installations</name>
<value>Site1</value>
</property>
6. Aggiungere la proprietà fs.vipr.installation.[installation_name].hosts sotto forma di
elenco separato da virgole dei nodi di dati ECS o degli indirizzi IP del load balancer.
Nell'esempio seguente il nome dell'installazione è impostato su Site1.
Nota
L'utilizzo di un load balancer non apporta alcun valore aggiunto a uno scenario HDFS,
poiché il client dispone della logica necessaria per connettersi direttamente ai nodi.
Per questo motivo, è consigliabile fornire un elenco di nodi di dati in questa proprietà,
non l'indirizzo di un load balancer. È inoltre consigliabile impostare la proprietà
fs.vipr.installation.[installation_name].resolution su "dynamic".
<property>
<name>fs.vipr.installation.Site1.hosts</name>
<value>203.0.113.10,203.0.113.11,203.0.113.12</value>
</property>
7. Aggiungere la proprietà fs.vipr.installation.[nome_installazione].resolution e
impostarla su uno dei valori seguenti:
Opzione Descrizione
dynamic Utilizzare per accedere direttamente ai nodi di dati ECS senza un load
balancer.
fixed
Utilizzare per accedere ai nodi di dati ECS tramite un load balancer.
<property>
<name>fs.vipr.installation.Site1.resolution</name>
<value>dynamic</value>
</property>
a. Se si imposta fs.vipr.installation.[installation_name].resolution su dynamic,
aggiungere la proprietà fs.vipr.installation.
[installation_name].resolution.dynamic.time_to_live_ms per specificare la
frequenza di query di ECS per l'elenco di nodi attivi.
<property>
<name>fs.vipr.installation.Site1.resolution.dynamic.time_to_live
_ms</name>
<value>900000</value>
</property>
8. Individuare la proprietà fs.defaultFS e modificare il valore per specificare l'URI del file
system ECS. .
Questa impostazione è facoltativa ed è possibile specificare l'URL del file system
completo per connettersi a ECS ViPRFS.
187
Utilizzare il formato seguente: viprfs://
<bucket_name.namespace.installation_name, dove
l
bucket_name: è il nome del bucket che contiene i dati che si desidera utilizzare
quando si eseguono job Hadoop. Nella modalità di autenticazione semplice, il
proprietario del bucket deve concedere l'autorizzazione a tutti. Nell'esempio
seguente il nome del bucket è impostato su mybucket.
l
namespace: è il namespace del tenant in cui risiede bucket_name. Nell'esempio
seguente il namespace è impostato su mynamespace.
l
installation_name: è il valore specificato dalla proprietà fs.vipr.installations.
<property>
<name>fs.defaultFS</name>
<value>viprfs://mybucket.mynamespace.Site1/</value>
</property>
9. Individuare fs.permissions.umask-mode e impostare il valore su 022.
In alcune configurazioni questa proprietà potrebbe non esistere. In questo caso
aggiungerla.
<property>
<name>fs.permissions.umask-mode</name>
<value>022</value>
</property>
10.Aggiungere la proprietà fs.viprfs.auth.anonymous_translation e utilizzarla per
specificare se mappare in modo anonimo gli object di proprietà all'utente corrente in
modo che quest'ultimo disponga dell'autorizzazione per modificarla.
Opzione
Descrizione
NONE (predefinita) Non mappa in modo anonimo gli object di proprietà all'utente
corrente.
CURRENT_USER
Mappa in modo anonimo gli object di proprietà all'utente Unix
corrente.
<property>
<name>fs.viprfs.auth.anonymous_translation</name>
<value>CURRENT_USER</value>
</property>
11.Aggiungere la proprietà fs.viprfs.auth.identity_translation. Offre un modo per
assegnare gli utenti a un'area di autenticazione quando Kerberos non è presente.
Opzione
Descrizione
FIXED_REALM
Una volta specificato, ECS HDFS ottiene il nome dell'area di
autenticazione dal valore della proprietà fs.vipr.auth.realm.
NONE (predefinita) ECS HDFS non esegue la conversione dell'area di
autenticazione.
<property>
<value>NONE</value>
</property>
12.Se si imposta la proprietà fs.viprfs.auth.identity_translation su FIXED_REALM,
aggiungere la proprietà fs.viprfs.auth.realm.
188
13.Se si desidera utilizzare il servizio Pivotal HAWQ, aggiungere la proprietà
hawq.vipr.endpoint. Specificare il valore utilizzando il formato seguente:
bucket_name.namespace.installation_name.
Dove:
l
l
l
È necessario eseguire una versione di ECS che supporti Pivotal HAWQ. Per ulteriori
informazioni, consultare Support Matrix.
<property>
<name>hawq.vipr.endpoint</name>
<value>mybucket.mynamespace.Site1</value>
</property>
14.Salvare core-site.xml.
15.Aggiornare core-site.xml per i nodi richiesti nel cluster Hadoop.
16.Se si utilizza una distribuzione Cloudera, usare Cloudera Manager per aggiornare la
valvola di sicurezza di core-site.xml in base allo stesso set di proprietà e valori.
17.Riavviare i servizi Hadoop.
Distribuzione
Hadoop
Comandi
Pivotal HD
ComputeMaster:
# service hadoop-yarn-resourcemanager restart
Nodi di dati:
# service hadoop-hdfs-datanode restart
# service hadoop-yarn-nodemanager restart
NameNode:
# service hadoop-yarn-nodemanager restart
Quando si configura il cluster Pivotal di Hadoop per l'utilizzo di
ECS HDFS come file system predefinito (specificato da
fs.DefaultFS in core-site.xml), non è possibile usare la
funzionalità di avvio/arresto del cluster di icm_client. È altresì
necessario avviare tutti i servizi del cluster (eccetto HDFS)
separatamente. Ad esempio:
icm_client start -s yarn
icm_client start -s zookeeper
e così via.
Cloudera
Utilizzare Cloudera Manager per riavviare i servizi HDFS e
MapReduce
189
Distribuzione
Hadoop
Comandi
Apache
# stop-all.sh
# start-all.sh
18.Testare la configurazione eseguendo il seguente comando per ottenere un elenco di
directory:
# hdfs dfs -ls viprfs://mybucket.mynamespace.Site1/
13/12/13 22:20:37 INFO vipr.ViPRFileSystem: Initialized ViPRFS for
viprfs://mybucket.mynamespace.Site1/
Se è stato impostato fs.defaultFS, è possibile utilizzare:
# hdfs dfs -ls /
Modificare hbase-site.xml HBASE
Quando si utilizza HBASE con ECS HDFS, è necessario impostare hbase.rootdir in
hbase-site.xml sullo stesso valore della proprietà fs.defaultFS in core-site.xml.
hbase-site.xml si trova in una delle seguenti posizioni:
Tabella 33 Posizioni di hbase-site.xml
Distribuzione
Hadoop
Posizione hbase-site.xml
Pivotal HD
/etc/ghpd/hbase/conf/
Cloudera
/etc/hbase/conf/
Hortonworks
/etc/hbase/conf/
Procedura
1. Aprire hbase-site.xml.
2. Impostare la proprietà hbase.rootdir sullo stesso valore di fs.defaultFS aggiungendo /
hbase come suffisso.
3. Salvare le modifiche.
a. In Cloudera aggiungere la proprietà hbase.rootdir alla valvola di sicurezza della
configurazione del servizio HBase per hbase-site.xml.
4. Riavviare i servizi per la distribuzione.
Distribuzione Hadoop Descrizione
Pivotal HD
Eseguire questo comando sul nodo master hbase:
# service hbase-master restart
Eseguire questo comando sul server della regione hbase:
# service hadoop-regionserver restart
190
Distribuzione Hadoop Descrizione
Cloudera
Hortonworks
Utilizzare Cloudera Manager per riavviare il servizio HBase.
# bin/start-hbase.sh
ESEMPIO 1 Voce hbase.rootdir
<property>
<name>hbase.rootdir</name>
<value>viprfs://testbucket.s3.testsite/hbase</value>
</property>
Modificare hbase-site.xml HBASE
191
192
CAPITOLO 23
Configurazione di HDFS in un cluster Hadoop
sicuro
l
Configurazione del cluster Hadoop sicuro per l'utilizzo di ECS HDFS ................... 194
193
Configurazione del cluster Hadoop sicuro per l'utilizzo di ECS
HDFS
In questo articolo viene descritto come configurare la distribuzione Hadoop esistente per
l'utilizzo dei dati nell'infrastruttura di storage ECS con ECS HDFS. Utilizzare questa
procedura dettagliata se il cluster Hadoop è configurato per l'utilizzo dell'autenticazione
Kerberos.
Se il cluster Hadoop è configurato per l'autenticazione semplice, seguire i passaggi
descritti qui a pagina 182.
Questa procedura non è stata qualificata nell'ECS Appliance.
Per eseguire questa procedura di integrazione, è necessario disporre:
l
di una conoscenza operativa del cluster Hadoop e degli strumenti associati;
l
delle credenziali Hadoop che consentono di accedere ai nodi Hadoop, modificare i
file di sistema Hadoop e avviare e arrestare i servizi Hadoop.
Pianificare l'integrazione di ECS HDFS e del cluster Hadoop sicuro
Questo elenco può essere utilizzato per verificare di disporre delle informazioni
necessarie per garantire un'integrazione corretta. È una best practice imparare dapprima
a utilizzare il cluster Hadoop con Kerberos e quindi integrare ECS HDFS.
Tabella 34 ECS HDFS - Prerequisiti di configurazione
Elemento
Operazione da eseguire
Hadoop cluster
Verificare che il cluster sia installato e in funzione.
Registrare le credenziali dell'amministratore per utilizzarle
successivamente in questa procedura.
ECS - Cluster: nodi ECS Registrare gli indirizzi IP dei nodi ECS per utilizzarli successivamente in
questa procedura.
ECS - Cluster: gruppo
di replica
Verificare che ECS disponga di un gruppo di replica.
HDFS richiede che un bucket abilitato per HDFS venga creato in un
gruppo di replica ECS e che il bucket sia accessibile come filesystem
mediante il nome del namespace e del bucket.
ECS - Cluster:
namespace del tenant
Verificare che sia configurato un namespace del tenant. Registrare il
nome.
Verificare inoltre che un Kerberos KDC sia installato e configurato per gestire
l'autenticazione delle entità di servizio Hadoop. Se si utilizza Active Directory per
autenticare utenti ECS, è necessario configurare un trust tra l'area di autenticazione
Kerberos e l'area di autenticazione dell'utente ECS. Le istruzioni su come configurare il
Kerberos KDC e il trust sono disponibili in Indicazioni sulla configurazione di Kerberos a
pagina 204.
Per integrare ECS HDFS con il cluster Hadoop sicuro, eseguire le attività indicate di
seguito.
1. Ottenimento del pacchetto di installazione e supporto di ECS HDFS a pagina 195
2. Creazione di un bucket per HDFS sicuro a pagina 195
194
3. Implementazione del file JAR ECS HDFS in un cluster sicuro a pagina 196 oppure
Utilizzo di un parcel Cloudera per installare Hadoop in un cluster sicuro a pagina 197
4. Configurare i nodi di ECS con l'entità del servizio ECS a pagina 198
5. Modificare core-site.xml. a pagina 201
6. Riavviare i servizi HDFS e MapReduce
7. Verificare che i servizi vengano riavviati correttamente
8. Assicurarsi di disporre dell'accesso al file system
Il file JAR ECS HDFS e gli strumenti di supporto HDFS vengono forniti in un file ZIP
hdfsclient-1.2.0.0-<version>.zip, che è possibile scaricare dalle pagine di
supporto di ECS all'indirizzo support.EMC.com.
Il file ZIP contiene le directory \tools\bin, \playbooks, \client e \parcels.
Prima di decomprimere il file, creare una directory per conservare i contenuti zip (lo
strumento di decompressione lo può fare automaticamente), quindi estrarre i contenuti
nella directory. Dopo aver estratto i file, le directory conterranno quanto segue:
l
\tools\bin: contiene ViPRAdminTools.sh, che consente la creazione di bucket che
supportano l'accesso HDFS senza bisogno di utilizzare i protocolli di object ECS o il
portale ECS.
l
\playbooks: contiene playbook Ansible per configurare un ambiente Hadoop
sicuro per la comunicazione con ECS HDFS.
l
\client: contiene i file indicati di seguito.
l
n
ECS - File JAR (ViPPRFS) (viprfs-client-<ECS version>-hadoop<hadoop version>.jar): utilizzati per configurare diverse distribuzioni
Hadoop.
n
libvipr-<version>.so: utilizzato per configurare Pivotal HAWQ per l'uso con
ECS HDFS.
\parcels
n
Distribuzioni Cloudera in formato "parcel". I parcel includono il file JAR ViPRFS
appropriato.
Creazione di un bucket per HDFS sicuro
Se il cluster Hadoop è protetto tramite Kerberos e si desidera consentire agli utenti
autenticati rispetto a un dominio Kerberos di creare bucket, è possibile creare un bucket
S3 e abilitarlo per l'accesso HDFS oppure utilizzare lo strumento di amministrazione di
ECS.
Lo strumento di amministrazione offre un metodo pratico per creare un bucket senza
dover accedere al portale ECS o utilizzare ECS Management API o S3 Object Service API.
Questi due meccanismi sono descritti qui:
l
l
Creare un bucket per HDFS utilizzando ViPRAdminTool a pagina 196
195
Nota
Non è necessario utilizzare i trattini bassi nei nomi dei bucket poiché non sono
supportati dalla classe URI Java. Ad esempio, viprfs://my_bucket.ns.site/ non
funzionerà in quanto si tratta di un URI non valido, che pertanto non viene compreso da
Hadoop.
Creare un bucket per HDFS utilizzando ViPRAdminTool
Da un cluster Hadoop protetto con Kerberos è possibile utilizzare ViPRAdminTool.sh
per creare un bucket utilizzabile dai protocolli Object e HDFS, senza necessariamente
avere familiarità con ECS REST API oppure Object Data Access API. Lo strumento è un
wrapper basato su una classe Java all'interno del file JAR ECS HDFS, pertanto può essere
eseguito dopo che il cluster Hadoop sarà stato configurato per l'utilizzo di ECS HDFS.
Prima di cominciare
l
Ottenere ViPRAdminTool.sh come descritto in Ottenimento del pacchetto di
installazione e supporto di ECS HDFS a pagina 195
l
Hadoop deve essere installato e nel computer in cui si sta eseguendo lo strumento
deve essere installato il file JAR ECSHDFS; inoltre, il cluster Hadoop deve essere
configurato per l'accesso a ECS HDFS.
l
La protezione Kerberos deve essere configurata. Se la protezione Kerberos non è
configurata, è necessario creare un bucket mediante S3 API o ECS REST API.
Informazioni di riferimento per ViPRAdminTool sono disponibili in ECS - Riferimento dello
strumento di amministrazione a pagina 207.
Procedura
1. Utilizzare lo script ViPRAdminTool.she specificare: Il comando createBucket, il
percorso al nodo e al namespace di ECS, il nome del nuovo bucket e le autorizzazioni
da impostare per il bucket.
Il comando seguente crea un bucket denominato "newbucket" e imposta le
autorizzazioni come 0755 (rwx/r-x/r-x). L'object virtual pool in cui viene creato il
bucket è il pool predefinito e il bucket è assegnato al progetto predefinito.
l
ViPRAdminTool.sh createbucket viprfs://<ECS Node Address>/
myNamespace newbucket 0755
Se si desidera specificare un progetto e un virtual pool, è possibile utilizzare ECS REST
API o la relativa CLI per ottenere questi valori.
Implementazione del file JAR ECS HDFS in un cluster sicuro
Utilizzare questa procedura per inserire il file JAR ECS HDFS nel classpath di ciascun nodo
del client nel cluster ECS.
Prima di cominciare
Ottenere il file JAR ECS HDFS per la distribuzione di ECS dal sito del supporto EMC per
ECS, come descritto in Ottenimento del pacchetto di installazione e supporto di ECS
HDFS a pagina 195.
196
Tabella 35 ECS - File JAR HDFS
- Distribuzione
Hadoop
ECS - File JAR HDFS
Pivotal HD
PHD 2.1: viprfs-client-1.2.0.0-hadoop-2.2.jar
Cloudera
Per le versioni Cloudera precedenti a CDH5 utilizzare: viprfsclient-1.2.0.0-hadoop-2.0.3-alpha.jar
Per le versioni Cloudera CDH5.0.x utilizzare: viprfsclient-1.2.0.0-hadoop-2.2.jar
Per le versioni Cloudera successive a CDH5.1.x utilizzare: viprfsclient-1.2.0.0-hadoop-2.3.jar
Hortonworks
HDP 2.0: viprfs-client-1.2.0.0-hadoop-2.2.jar
Nota
In presenza di una distribuzione Cloudera Hadoop, è possibile utilizzare i Parcel Cloudera
forniti per installare una distribuzione Hadoop preconfigurata con il file JAR ViPRFS.
Vedere Utilizzo di un parcel Cloudera per installare Hadoop in un cluster sicuro a pagina
197.
Procedura
1. Accedere a un nodo del client ECS.
2. Eseguire il comando classpath per ottenere l'elenco delle directory nel classpath:
# hadoop classpath
3. Copiare il file JAR ECS HDFS in una delle cartelle elencate dal comando classpath
dopo la cartella /conf.
Distribuzione ECS
Posizione classpath (consigliata)
Pivotal HD
/usr/lib/gphd/hadoop/lib
Cloudera
/usr/lib/hadoop/lib
Hortonworks
/usr/lib/hadoop/lib
4. Ripetere questa procedura per ogni nodo del client ECS.
Utilizzo di un parcel Cloudera per installare Hadoop in un cluster sicuro
Cloudera utilizza parcel come meccanismo per distribuire software nei cluster CDH dalla
console di amministrazione di Cloudera Manager. ECS fornisce parcel Cloudera, definiti
parcel ViPRFS, preconfigurati per l'uso di ECS HDFS.
Prima di cominciare
I parcel Cloudera che includono il client ECS (ViPRFS) vengono forniti nell'installazione e
nel pacchetto di supporto ECS HDFS (vedere Ottenimento del pacchetto di installazione e
supporto di ECS HDFS a pagina 195).
Procedura
1. Creare un parcel repository
Utilizzo di un parcel Cloudera per installare Hadoop in un cluster sicuro
197
Per creare un parcel repository Cloudera, posizionare i file parcel ViPRFS in una
directory pubblicata da un web server. In genere l'hosting è all'interno della rete
personale.
2. Aggiungere il parcel repository ECS dall'interfaccia utente di Cloudera Manager
a. Passare ad Administration > Settings > Parcels.
b. Impostare la frequenza di aggiornamento dei parcel su 1 minuto per accelerare la
discovery.
c. Fare clic su Save Changes
3. Scaricare il parcel
Passare a Hosts > Parcels > Downloadable e scaricare il parcel ViPRFS più recente.
4. Distribuire il parcel nel cluster
È possibile distribuire più versioni di parcel ViPRFS, ma può essere attivata solo una
versione per volta.
Per eliminare un parcel, è necessario disattivarlo, quindi rimuoverlo dagli host. Tutte
le operazioni sopra indicate possono essere eseguite nell'interfaccia utente del
parcel.
5. Attivare il parcel
Un parcel distribuito può essere attivato premendo il pulsante Activate.
Cloudera Manager richiederà di riavviare il cluster per consentire l'utilizzo del nuovo
parcel da parte dei processi in esecuzione.
6. Fare clic su Restart per riavviare il cluster
Configurare i nodi di ECS con l'entità del servizio ECS
L'entità del servizio ECS e il file della tabella di chiavi corrispondente devono risiedere su
ciascun nodo di dati ECS. Per automatizzare questi passaggi, utilizzare i playbook
Ansible forniti.
Prima di cominciare
Prima di completare questa procedura, è necessario disporre dei seguenti elementi:
l
Accesso ai playbook Ansible. Ottenere i playbook Ansible dal pacchetto software ECS
HDFS come descritto in Ottenimento del pacchetto di installazione e supporto di ViPR
HDFS a pagina 195 e copiarlo nel nodo in cui si intende installare Ansible.
l
Elenco di indirizzi IP dei nodi ECS.
l
Indirizzo IP di KDC.
l
La risoluzione DNS in cui eseguire questo script deve coincidere con quella dell'host
Hadoop, per garantire il funzionamento di vipr/_HOST@REALM.
ECS fornisce contenuti Ansible riutilizzabili denominati 'ruoli', costituiti da script Python,
elenchi di attività basate su YAML e template file.
198
l
vipr_kerberos_config: configura un nodo ECS per Kerberos.
l
vipr_jce_config: configura un nodo di dati ECS per la crittografia con potenza
illimitata installando policy file JCE.
l
vipr_kerberos_principal: acquisisce un'entità di servizio per un nodo ECS.
Procedura
1. Installare Ansible.
yum install epel-release && yum install ansible
2. Decomprimere il file hdfsclient-1.2.0.0-<version>.zip.
Per i passaggi indicati in questa procedura vengono utilizzati i playbook contenuti
nella directory viprfs-client-1.2.0.0-<version>/playbooks/samples. I
passaggi sono inoltre contenuti in viprfs-client-1.2.0.0-<version>/
playbooks/samples/README.md.
3. Installare i ruoli Ansible forniti.
ansible-galaxy install -r requirements.txt -f
4. Copiare i contenuti della directory viprfs-client-1.2.0.0-<version>/
playbooks/samples in una directory di lavoro.
5. Modificare inventory.txt affinché faccia riferimento ai nodi di dati ECS e al server
KDC.
Di seguito vengono visualizzate le voci predefinite.
[data_nodes]
192.168.2.[100:200]
[kdc]
192.168.2.10
6. Scaricare l'archivio di policy JCE "unlimited" da oracle.com ed estrarlo nella directory
UnlimitedJCEPolicy.
È possibile configurare Kerberos per l'uso di un tipo di crittografia avanzata, ad
esempio AES-256. In questo caso, è necessario riconfigurare JRE nei nodi ECS per
l'uso della policy 'unlimited'.
Nota
Questo passaggio deve essere eseguito solo se si utilizza un tipo di crittografia
avanzata.
7. Copiare il file krb5.conf da KDC nella directory di lavoro.
8. Modificare generate-vipr-keytabs.yml in base alle esigenze e impostare il
nome di dominio.
Ad esempio:
[root@nile3-vm22 samples]# cat generate-vipr-keytabs.yml
--###
# Generates keytabs for ViPR/ECS data nodes.
###
- hosts: data_nodes
serial: 1
roles:
- role: vipr_kerberos_principal
Configurare i nodi di ECS con l'entità del servizio ECS
199
kdc: "{{ groups.kdc | first }}"
principals:
- name: vipr/_HOST@MA.EMC.COM
keytab: keytabs/_HOST@MA.EMC.COM.keytab
In questo esempio il valore predefinito (vipr/_HOST@EXAMPLE.COM) è stato
sostituito con (vipr/_HOST@MA.EMC.COM) e il dominio è MA.EMC.COM.
9. Eseguire
export ANSIBLE_HOST_KEY_CHECKING=False
10.Eseguire il playbook Ansible per generare le tabelle di chiavi.
ansible-playbook -v -k -i inventory.txt generate-vipr-keytabs.yml
11.Modificare il file setup-vipr-kerberos.yml in base alle esigenze.
Di seguito vengono visualizzati contenuti del file predefiniti.
# cat setup-vipr-kerberos.yml
--###
# Configures ViPR/ECS for Kerberos authentication.
# - Configures krb5 client
# - Installs keytabs
# - Installs JCE policy
###
- hosts: data_nodes
roles:
- role: vipr_kerberos_config
krb5:
config_file: krb5.conf
service_principal:
name: vipr/_HOST@EXAMPLE.COM
keytab: keytabs/_HOST@EXAMPLE.COM.keytab
- role: vipr_jce_config
jce_policy:
name: unlimited
src: UnlimitedJCEPolicy/
In questo esempio il valore predefinito (vipr/_HOST@EXAMPLE.COM) è stato
sostituito con (vipr/_HOST@MA.EMC.COM) e il dominio è MA.EMC.COM.
Nota
Rimuovere il ruolo "vipr_jce_config" se non si utilizza un tipo di crittografia avanzata.
12.Eseguire il playbook Ansible per configurare i nodi di dati con l'entità del servizio ECS.
Accertarsi che sia disponibile la directory ./viprfs-client-1.2.0.0<version>/playbooks/samples/keytab e che il file krb5.conf si trovi nella
directory viprfs-client-1.2.0.0-<version>/playbooks/samples della
directory di lavoro.
ansible-playbook -v -k -i inventory.txt setup-vipr-kerberos.yml
200
Verificare che dal KDC sia stata creata l'entità del servizio ECS corretta, una per nodo
di dati:
# kadmin.local -q "list_principals" | grep vipr
vipr/nile3-vm42.centera.lab.emc.com@MA.EMC.COM
vipr/nile3-vm43.centera.lab.emc.com@MA.EMC.COM
Verificare che la tabella di chiavi corretta sia stata generata e archiviata nella
posizione: /data/hdfs/krb5.keytab in tutti i nodi di dati ECS. È possibile
utilizzare il comando "strings" nella tabella di chiavi per estrarre il testo leggibile e
verificare che contenga l'entità corretta. Ad esempio:
dataservice-10-247-199-69:~ # strings /data/hdfs/krb5.keytab
MA.EMC.COM
vipr
nile3-vm42.centera.lab.emc.com
In questo caso l'entità è vipr/nile3-vm42.centera.lab.emc.com.
Modificare core-site.xml.
Utilizzare questa procedura per aggiornare core-site.xml in base alle proprietà
necessarie quando si usa ECS HDFS con un cluster ECS che impiega la modalità di
autenticazione Kerberos.
Prima di cominciare
Ottenere le credenziali che consentono di accedere ai nodi ECS e modificare coresite.xml.
Per ulteriori informazioni su ogni proprietà che è necessario impostare, vedere
Riferimento delle proprietà core_site.xml.
core-site.xml risiede su ciascun nodo nel cluster Hadoop ed è necessario modificare
le stesse proprietà in ogni istanza. È possibile apportare la modifica in un nodo e quindi
utilizzare il comando di copia sicura (scp) per copiare il file negli altri nodi del cluster.
Come best practice, eseguire il backup di core-site.xml prima di avviare la
procedura di configurazione.
La posizione di core-site.xml dipende dalla distribuzione in uso.
Tabella 36 Posizione dei file core-site.xml
Distribuzione
ViPR Controller
Posizione core-site.xml
Nodi da
aggiornare
Pivotal HD
/etc/ghpd/hadoop/conf
ComputeMaster e
client
Cloudera
/etc/hadoop/conf
Nodi client
Hortonworks
/etc/hadoop/conf
Tutti i nodi
Procedura
1. Accedere a uno dei nodi HDFS in cui è situato core-site.xml.
2. Eseguire una copia di backup di core-site.xml.
cp core-site.xml core-site.backup
201
3. Utilizzare l'editor di testo preferito per aprire core-site.xml per la modifica.
Nota
Nel caso di distribuzioni Cloudera è consigliabile utilizzare Cloudera Safety Valve,
mentre con Hortonworks è preferibile utilizzare Hortonworks Ambari, per apportare
queste modifiche e renderle persistenti nel cluster.
4. Aggiungere le proprietà e i valori seguenti per definire le classi Java che
implementano il file system ECS HDFS:
<property>
</property>
<property>
</property>
5. Aggiungere la proprietà fs.vipr.installations. Nell'esempio seguente il valore è
impostato su Site1.
<property>
</property>
6. Aggiungere la proprietà fs.vipr.installation.[installation_name].hosts sotto forma di
elenco separato da virgole dei nodi di dati ECS o degli indirizzi IP del load balancer.
Nota
L'utilizzo di un load balancer non apporta alcun valore aggiunto a uno scenario HDFS,
poiché il client dispone della logica necessaria per connettersi direttamente ai nodi.
Per questo motivo, è consigliabile fornire un elenco di nodi di dati in questa proprietà,
non l'indirizzo di un load balancer. È inoltre consigliabile impostare la proprietà
fs.vipr.installation.[installation_name].resolution su "dynamic".
<property>
<value>203.0.113.10,203.0.113.11,203.0.113.12</value>
</property>
7. Aggiungere la proprietà fs.vipr.installation.[nome_installazione].resolution e
impostarla su uno dei valori seguenti:
Opzione Descrizione
dynamic Utilizzare per accedere direttamente ai nodi di dati ECS senza un load
balancer.
fixed
Utilizzare per accedere ai nodi di dati ECS tramite un load balancer.
<property>
202
</property>
a. Se si imposta fs.vipr.installation.[installation_name].resolution su dynamic,
aggiungere la proprietà fs.vipr.installation.
[installation_name].resolution.dynamic.time_to_live_ms per specificare la
frequenza di query di ECS per l'elenco di nodi attivi.
<property>
<name>fs.vipr.installation.Site1.resolution.dynamic.time_to_live
_ms</name>
</property>
8. Individuare la proprietà fs.defaultFS e modificare il valore per specificare l'URI del file
system ECS. .
Questa impostazione è facoltativa ed è possibile specificare l'URL del file system
completo per connettersi a ECS ViPRFS.
Utilizzare il formato seguente: viprfs://
<bucket_name.namespace.installation_name, dove
l
l
l
<property>
</property>
9. Individuare fs.permissions.umask-mode e impostare il valore su 027.
In alcune configurazioni questa proprietà potrebbe non esistere. In questo caso
aggiungerla.
<property>
<value>027</value>
</property>
10.Aggiungere la proprietà fs.viprfs.auth.anonymous_translation e utilizzarla per
specificare se mappare in modo anonimo gli object di proprietà all'utente corrente in
modo che quest'ultimo disponga dell'autorizzazione per modificarla.
Opzione
Descrizione
NONE (predefinita) Non mappa in modo anonimo gli object di proprietà all'utente
corrente.
CURRENT_USER
Mappa in modo anonimo gli object di proprietà all'utente Unix
corrente.
<property>
203
</property>
11.Aggiungere la proprietà fs.viprfs.auth.identity_translation e impostarla su
CURRENT_USER_REALM, che viene mappata all'area di autenticazione dell'utente che
ha eseguito l'accesso tramite kinit.
<property>
<value>CURRENT_USER_REALM</value>
</property>
12.Aggiungere la proprietà viprfs.security.principal. Questa proprietà indica al KDC chi è
l'utente ECS.
Il nome dell'entità può includere "_HOST", che viene automaticamente sostituito con
l'FQDN del nodo di dati effettivo in fase di runtime.
<property>
<name>viprfs.security.principal</name>
<value>vipr/_HOST@example.com</value>
</property>
13.Riavviare i servizi HDFS e MapReduce.
14.Testare la configurazione eseguendo il seguente comando per ottenere un elenco di
directory:
# kinit <service principal>
# hdfs dfs -ls viprfs://mybucket.mynamespace.Site1/
13/12/13 22:20:37 INFO vipr.ViPRFileSystem: Initialized ViPRFS for
viprfs://mybucket.mynamespace.Site1/
Se è stato impostato fs.defaultFS, è possibile utilizzare:
# hdfs dfs -ls /
Indicazioni sulla configurazione di Kerberos
Vengono fornite indicazioni sulla configurazione di Kerberos nel cluster Hadoop.
Configurare il Kerberos KDC
Per configurare il Kerberos KDC, attenersi alla procedura descritta di seguito.
Procedura
1. Installare krb5-workstation.
Utilizzare il comando:
yum install -y krb5-libs krb5-server krb5-workstation
2. Modificare /etc/krb5.conf e cambiare il nome dell'area di autenticazione e le
estensioni.
3. Modificare /var/kerberos/krb5kdc/kdc.conf e cambiare il nome dell'area di
autenticazione in modo che corrisponda a quello personale.
4. Se il KDC è una VM, ricreare /dev/random. In caso contrario, il passaggio
successivo di creazione del database KDC richiederà molto tempo.
204
a. Rimuovere mediante:
# rm -rf /dev/random
b. Ricreare mediante:
# mknod /dev/random c 1 9
5. Creare il database KDC.
# kdb5_util create -s
Nota
In caso di errore con le entità iniziali, ad esempio se si è eseguito "kdb5_util create s" in modo errato, potrebbe essere necessario eliminarle in modo esplicito nella
directory /var/kerberos/krb5kdc/ .
6. Modificare kadm5.acl per specificare utenti con autorizzazioni di amministratore.
*/admin@DET.EMC.COM *
7. Modificare /var/kerberos/krb5kdc/kdc.conf ed eliminare eventuali tipi di
crittografia, ad eccezione di des-cbc-crc:normal. Modificare inoltre il nome
dell'area di autenticazione.
8. Verificare che iptables e selinux siano disattivati in tutti i nodi (server KDC e nodi
Hadoop).
9. Avviare i servizi KDC e creare un'entità admin locale.
kadmin.local
# service krb5kdc start
# service kadmin start
# /usr/kerberos/sbin/kadmin.local-q "addprinc root/admin"
# kinit root/admin
10.Copiare il file krb5.conf in tutti i nodi Hadoop.
Ogni volta che si apporta una modifica a un file di configurazione, riavviare i servizi
indicati di seguito e copiare il file krb5.conf nei nodi ECS e host Hadoop pertinenti.
11.Riavviare i servizi.
service krb5kdc restart
service kadmin restart
12.Per configurare un KDC Kerberos, attenersi alla procedura descritta in http://
www.centos.org/docs/4/html/rhel-rg-en-4/s1-kerberos-server.html.
Indicazioni sulla configurazione di Kerberos
205
Configurare l'autenticazione utente AD per Kerberos
In presenza di un ambiente Hadoop con sicurezza Kerberos, è possibile configurarlo per
l'autenticazione rispetto al dominio AD di ECS.
Verificare di disporre di un utente AD per ADREALM. Nell'esempio di seguito viene
utilizzato l'utente "detscr" per ADREALM CAMBRIDGE.EMC.COM. Creare un trust
unidirezionale tra KDCREALM e ADREALM, come illustrato nell'esempio. Non tentare di
validare questa area di autenticazione utilizzando "netdom trust".
In Active Directory
È necessario configurare un trust unidirezionale dall'area di autenticazione KDS all'area
di autenticazione AD. A tale scopo, eseguire i comandi indicati di seguito al prompt dei
comandi.
ksetup /addkdc KDC-REALM <KDC hostname>
netdom trust KDC-REALM /Domain:AD-REALM /add /realm /
passwordt:<TrustPassword>
ksetup /SetEncTypeAttr KDC-REALM <enc_type>
Ad esempio:
ksetup /addkdc LSS.EMC.COM lcigb101.lss.emc.com
netdom trust LSS.EMC.COM /Domain:CAMBRIDGE.EMC.COM /add /realm /
passwordt:ChangeMe
ksetup /SetEncTypeAttr LSS.EMC.COM DES-CBC-CRC
Per questo esempio è stata utilizzata la crittografia des-cbc-crc. Si tratta tuttavia di una
crittografia debole, scelta esclusivamente a fini dimostrativi. Indipendentemente dal tipo
desiderato, la crittografia deve essere supportata da AD, KDC e client.
Nel KDC (root)
Per configurare un trust unidirezionale, è necessario creare un'entità di servizio "krbtgt".
A tale scopo, il nome è krbtgt/KDC-REALM@AD-REALM. Fornire la password ChangeMe o
quella specificata nell'argomento /passwordt in alto.
1. Nel KDC (root)
# kadmin
kadmin: addprinc -e "des-cbc-crc:normal" krbtgt/
LSS.EMC.COM@CAMBRIDGE.EMC.COM
Nota
In fase di implementazione, è consigliabile limitare i tipi di crittografia a quello
scelto. In caso di esito positivo, sarà possibile aggiungere ulteriori tipi di crittografia
in un secondo momento.
2. Aggiungere le seguenti regole alla proprietà hadoop.security.auth_to_local di coresite.xml:
RULE:[1:$1@$0](^.*@CAMBRIDGE\.EMC\.COM$)s/^(.*)@CAMBRIDGE\.EMC\.COM
$/$1/g
RULE:[2:$1@$0](^.*@CAMBRIDGE\.EMC\.COM$)s/^(.*)@CAMBRIDGE\.EMC\.COM
$/$1/g
3. Verificare che AD o LDAP sia configurato correttamente nel server Kerberos (KDC).
L'utente dovrebbe poter essere autenticato tramite "kinit" a fronte di un utente AD ed
elencare la directory HDFS locale.
206
Nota
In caso di configurazione del cluster Hadoop e di ECS per l'autenticazione tramite AD,
creare account utente Linux locali in tutti i nodi Hadoop per l'utente AD in base al
quale verrà eseguita l'autenticazione tramite "kinit" e accertarsi inoltre che per tutti
gli host Hadoop verrà eseguita la stessa autenticazione con l'utente AD. Se ad
esempio si esegue l'autenticazione tramite "kinit" come userX@ADREALM, creare
userX come utente locale in tutti gli host Hadoop ed eseguire l'autenticazione tramite
"kinit" utilizzando: 'kinit userX@ADREALM' in tutti gli host per l'utente.
Nell'esempio riportato di seguito verrà eseguita l'autenticazione come "kinit
detscr@CAMBRIDGE.EMC.COM", pertanto verrà creato un utente denominato "detscr" che
verrà autenticato tramite "kinit" come tale utente nell'host Hadoop, come riportato di
seguito:
[root@lviprb159 ~]# su detscr
[detscr@lviprb159 root]$ whoami
detscr
[detscr@lviprb159 root]$ kinit detscr@CAMBRIDGE.EMC.COM
Password for detscr@CAMBRIDGE.EMC.COM:
[detscr@lviprb159 root]$ klist
Ticket cache: FILE:/tmp/krb5cc_1010
Default principal: detscr@CAMBRIDGE.EMC.COM
Valid starting
Expires
Service principal
12/22/14 14:28:27 03/02/15 01:28:30 krbtgt/
CAMBRIDGE.EMC.COM@CAMBRIDGE.EMC.COM
renew until 09/17/17 15:28:27
[detscr@lviprb159 root]$ hdfs dfs -ls /
Found 4 items
drwx---rwx
- yarn
hadoop
0 2014-12-23 14:11 /app-logs
drwx---rwt
- hdfs
0 2014-12-23 13:48 /apps
drwx---r-x
- mapred
0 2014-12-23 14:11 /mapred
drwx---r-x
- hdfs
0 2014-12-23 14:11 /mr-history
ECS - Riferimento dello strumento di amministrazione
Lo strumento di amministrazione ECS (ViPRAdminTool.sh) viene fornito per
consentire la creazione di bucket che supportano HDFS da un cluster Hadoop senza
necessità di interagire con il portale ECS o la relativa API. Lo strumento può essere
utilizzato anche per elencare, eliminare e ottenere lo stato dei bucket.
Come ottenere lo strumento
Lo strumento ViPRAdminTool.sh è un wrapper basato su una classe Java all'interno
del file JAR ECS HDFS, pertanto può essere eseguito dopo che il cluster Hadoop sarà stato
configurato per l'utilizzo di ECS HDFS. Può essere ottenuto come descritto in Ottenimento
del pacchetto di installazione e supporto di ECS HDFS a pagina 195.
Utilizzo
l
Per eseguire lo strumento, utilizzare:
ViPRAdminTool.sh <COMMAND> [ARGUMENTS]
l
È possibile eseguire lo strumento senza lo script e chiamando la classe direttamente
utilizzando:
hadoop com/emc/hadoop/fs/vipr/ViPRAdminClient <COMMAND> [ARGUMENTS]
Un comando è sempre obbligatorio ed è indicato da <>; gli argomenti sono opzionali e
sono indicati da [].
ECS - Riferimento dello strumento di amministrazione
207
Nota
È necessario immettere tutti gli argomenti fino all'ultimo argomento che si desidera
specificare.
Comandi
createbucket <uri><name>[permission][vpoolId][projectId]
[objectType]
Crea un bucket.
statbucket <uri><name>
Recupera lo stato per il bucket specificato.
deletebucket <uri><name>
Elimina il bucket specificato.
listbucket <uri>
Elenca tutti i bucket che l'utente corrente è autorizzato a leggere.
Argomenti
name
Nome del bucket da creare/avviare/eliminare.
uri
Un puntatore all'implementazione di ECS, nel formato <scheme>://<DataNode
Address>/<namespace>.
permission
Valido solo per createbucket. Specificare le autorizzazioni POSIX in formato
ottale, come "0755". Valore predefinito: 0777.
vpoolId
Valido solo per createbucket. Identità del gruppo di replica da utilizzare. Se non
viene specificato, viene utilizzato il gruppo di replica predefinito.
objectType
Valido solo per createbucket. Specifica il tipo di objectType consentito per
questo bucket (solo S3).
208
CAPITOLO 24
Risoluzione dei problemi di una configurazione
ECS HDFS
l
Risoluzione dei problemi.....................................................................................210
209
Risoluzione dei problemi
In quest'area vengono fornite soluzioni alternative per i problemi che possono verificarsi
durante la configurazione di ECS HDFS.
Verificare la corretta configurazione di AD/LDAP con cluster Hadoop sicuro
È opportuno verificare la corretta configurazione di AD o LDAP con Kerberos (KDC) e il
cluster Hadoop.
Se la configurazione è corretta, dovrebbe essere possibile eseguire l'autenticazione
tramite "kinit" per un utente AD/LDAP. Se inoltre il cluster Hadoop è configurato per HDFS
in locale, verificare che sia possibile elencare la directory HDFS locale prima dell'aggiunta
di ECS al cluster.
Soluzione alternativa
Se non si riesce a eseguire l'autenticazione come utente AD/LDAP con il KDC nel cluster
Hadoop, è opportuno risolvere questo problema prima di procedere alla configurazione
ECS Hadoop.
Di seguito è illustrato un esempio di login riuscito.
[kcluser@lvipri054 root]$ kinit kcluser@QE.COM
Password for kcluser@QE.COM:
[kcluser@lvipri054 root]$ klist
Ticket cache: FILE:/tmp/krb5cc_1025
Default principal: kcluser@QE.COM
Valid starting
Expires
Service principal
04/28/15 06:20:57 04/28/15 16:21:08 krbtgt/QE.COM@QE.COM
renew until 05/05/15 06:20:57
In caso di esito negativo, è possibile analizzare il problema utilizzando la seguente
checklist:
210
l
Controllare correttezza e sintassi di /etc/krb5.conf nel server KDC. Le aree di
autenticazione possono effettuare distinzione tra maiuscole e minuscole nei file di
configurazione e in caso di utilizzo con il comando kinit.
l
Verificare che il file /etc/krb5.conf dal server KDC venga copiato in tutti i nodi
Hadoop.
l
Verificare che il trust unidirezionale tra AD/LDAP e il server KDC abbia avuto esito
positivo. A tale scopo, fare riferimento alla documentazione appropriata.
l
Verificare che il tipo di crittografia sul server AD/LDAP corrisponda al tipo sul server
KDC.
l
Verificare che i file /var/kerberos/krb5kdc/kadm5.acl e /var/kerberos/
krb5kdc/kdc.conf siano corretti.
l
Provare a eseguire il login come entità di servizio sul server KDC per indicare il
corretto funzionamento del server stesso.
l
Provare a eseguire il login direttamente come lo stesso utente AD/LDAP nel server
KDC. Se l'operazione ha esito negativo, il problema potrebbe essere riconducibile al
server KDC.
Autorizzazione negata per un utente AD
Durante l'esecuzione di un'applicazione come utente AD viene generato un errore di tipo
"Permission denied".
Impostare l'autorizzazione per la directory /user su:
hdfs dfs -chmod 1777 /user
Riavvio di servizi in seguito alla configurazione hbase
Dopo aver modificato la proprietà hbase.rootdir in hbase-site.xml, il servizio hbase non
viene riavviato in modo corretto.
Se si verifica questo errore in Cloudera o Hortonworks, attenersi alla procedura descritta
di seguito per riattivare hbase-master.
1. Connettersi alla CLI di ZooKeeper.
hbase zkcli
2. Rimuovere la directory hbase.
rmr /hbase
3. Riavviare il servizio hbase.
Riavviare tutti i servizi in Cloudera.
Esito negativo del test Pig: impossibile ottenere l'entità Kerberos
Il test Pig ha esito negativo con il seguente errore: "Info:Error: java.io.IOException: Unable
to obtain the Kerberos principal" anche dopo aver eseguito l'autenticazione tramite
kinit come utente AD, oppure con l'errore "Unable to open iterator for alias firstten".
Questo errore si verifica poiché Pig (<0,13) non genera un token di delega per ViPRFS
come storage secondario.
Aggiungere viprfs://bucket.ns.installation/ all'impostazione della
configurazione mapreduce.job.hdfs-servers. Ad esempio:
set mapreduce.job.hdfs-servers viprfs://KcdhbuckTM2.s3.site1
Abilitare il logging Kerberos lato client
Per risolvere problemi di autenticazione, è possibile abilitare il logging dettagliato nel
nodo del cluster Hadoop in uso.
Il logging dettagliato viene abilitato utilizzando una variabile di ambiente che si applica
solo alla sessione SSH corrente.
export HADOOP_OPTS="-Dsun.security.krb5.debug=true"
Debug di Kerberos sul server KDC
Accodare il file /var/log/krb5kdc.log del server KDC durante un'operazione HDFS
per agevolarne il debug.
Autorizzazione negata per un utente AD
211
tail -f /var/log/krb5kdc.log
Eliminare il disallineamento dei clock
È importante verificare che l'ora tra il client e il server sia sincronizzata, poiché Kerberos
si basa sulla precisione oraria.
Se il clock del server AD è disallineato rispetto ai nodi di dati o al server KDC, è
necessario configurare il relativo server NTP. A tale scopo, attenersi alla procedura
descritta di seguito.
1. Utilizzare Desktop remoto per la connessione al server AD.
2. Eseguire i seguenti comandi:
a. w32tm /config /syncfromflags:manual /manualpeerlist:<ntp-server1>,<ntpserver2>
b. net stop w32time
c. net start w32time
212
CAPITOLO 25
Riferimento delle proprietà del sito core di ECS
HDFS
l
Hadoop Proprietà core-site.xml per ECS HDFS..................................................... 214
213
Hadoop Proprietà core-site.xml per ECS HDFS
Quando si configura il file core-site.xml di Hadoop, utilizzare questa tabella come
riferimento per le proprietà e i valori correlati.
Tabella 37 Hadoop Proprietà core-site.xml
Proprietà
Descrizione
Proprietà di implementazione del file system
fs.viprfs.impl
fs.AbstractFileSystem.vi
prfs.impl
<property>
</property>
<property>
</property>
Proprietà che definiscono la sezione di autorità dell'URI del file system ECS HDFS
fs.vipr.installations
Elenco di nomi separato da virgole. I nomi vengono definiti ulteriormente dalla proprietà
fs.vipr.installation.[installation_name].hosts per identificare in modo univoco i set di nodi di dati ECS. I
nomi vengono utilizzati come componente della sezione di autorità dell'URI del file system ECS HDFS.
Ad esempio:
<property>
<value><site1>,<abc>,<testsite></value>
</property>
fs.vipr.installation.
Gli indirizzi IP dei nodi di dati del cluster ECS o i load balancer per ciascun nome elencato nella
[nome_installazione].ho proprietà fs.vipr.installations. Specificare il valore sotto forma di elenco di indirizzi IP separato da
sts
virgole. Ad esempio:
<property>
<name>fs.vipr.installation.<site1>.hosts</name>
<value>203.0.113.10,203.0.113.11,203.0.113.12</value>
</property>
<property>
<name>fs.vipr.installation.<abc>.hosts</name>
<value>198.51.100.0,198.51.100.1,198.51.100.2</value>
</property>
<property>
<name>fs.vipr.installation.<testsite>.hosts</name>
<value>198.51.100.10,198.51.100.11,198.51.100.12</value>
</property>
214
Tabella 37 Hadoop Proprietà core-site.xml (continua)
Proprietà
Descrizione
Specifica il modo in cui il software ECS HDFS sa come accedere ai nodi di dati ECS. I valori sono:
[nome_installazione].res
l
dynamic: Utilizzare questo valore quando si accede direttamente ai nodi di dati ECS senza un load
olution
balancer.
l
fixed: Utilizzare questo valore quando si accede ai nodi di dati ECS tramite un load balancer.
<property>
<name>fs.vipr.installation.testsite.resolution</name>
</property>
Quando la proprietà fs.vipr.installation.[installation_name].resolution è impostata su dynamic, questa
[nome_installazione].res proprietà specifica la frequenza di query di ECS per l'elenco di nodi attivi. I valori sono espressi in
olution.dynamic.time_to millisecondi. Il valore predefinito è 10 minuti.
_live_ms
<property>
<name>fs.vipr.installation.<testsite>.resolution.dynamic.time_to_live_ms</name>
</property>
ECS URI del file system
fs.defaultFS
Una proprietà Hadoop standard che specifica l'URI del file system predefinito. L'impostazione di questa
proprietà sul file system ECS HDFS è facoltativa. Se non la si imposta sul file system ECS HDFS, è
necessario specificare l'URI completo per ciascuna operazione del file system. L'URI del file system ECS
HDFS ha il seguente formato:
viprfs://[bucket_name].[namespace].[installation_name]
l
bucket_name: è il nome del bucket abilitato per HDFS che contiene i dati che si desidera utilizzare
®
quando si eseguono job Hadoop .
l
namespace: è il namespace del tenant associato al bucket abilitato per HDFS.
l
installation_name: è il nome associato al set di nodi di dati ECS che Hadoop può utilizzare per
accedere ai dati ECS. Il valore di questa proprietà deve corrispondere a uno dei valori specificati
nella proprietà fs.vipr.installations.
®
Ad esempio:
<property>
<value>viprfs://testbucket.s3.testsite</value>
</property>
HBase richiede la definizione di un file system predefinito.
Servizio Pivotal HAWQ
hawq.vipr.endpoint
Questa proprietà specifica l'endpoint ECS che il servizio HAWQ utilizza per comunicare con il file system
ECS. La proprietà ha la seguente sintassi:
bucket_name.namespace.installation_name
215
Proprietà
Descrizione
l
bucket_name: è il nome del bucket abilitato per HDFS che contiene i dati che si desidera utilizzare
con il servizio HAWQ.
l
namespace: è il namespace del tenant associato al bucket abilitato per HDFS.
l
installation_name: è il nome associato al set di nodi di dati ECS che Hadoop può utilizzare per
accedere ai dati ECS. Il valore di questa proprietà deve corrispondere a uno dei valori specificati
nella proprietà fs.vipr.installations.
®
Ad esempio:
<property>
<name>hawq.vipr.endpoint</name>
<value>testbucket.s3.testsite</value>
</property>
Proprietà UMASK
fs.permissions.umaskmode
Questa proprietà Hadoop standard specifica il modo in cui ECS HDFS deve calcolare le autorizzazioni
per gli object. Le autorizzazioni vengono elaborate applicando un argomento umask alle autorizzazioni
di input. I valori consigliati sono:
l
Quando Kerberos è presente: 027
l
Quando Kerberos non è presente: 022
Ad esempio:
<property>
<value>027</value>
</property>
Proprietà per la traduzione di identità
fs.viprfs.auth.identity_tr
anslation
Questa proprietà specifica il modo in cui il client ECS HDFS determina a quale area di autenticazione
Kerberos appartiene un dato utente se non è specificata un'area. ECS è caratterizzato da nodi di dati
che archiviano i proprietari di file nel formato username@REALM, mentre Hadoop archivia i proprietari
di file solo con il nome utente.
I valori possibili sono:
l
NONE: predefinito. Gli utenti non sono mappati a un'area di autenticazione.
l
FIXED_REALM: gli utenti sono mappati all'area di autenticazione specificata in fs.viprfs.auth.realm.
l
CURRENT_USER_REALM: valido quando è presente Kerberos. L'area di autenticazione dell'utente
viene rilevata automaticamente ed è l'area di autenticazione dell'utente che ha eseguito l'accesso.
Nell'esempio di seguito, l'area di autenticazione è EMC.COM perché sally è nell'area di
autenticazione EMC.COM. La proprietà del file viene modificata e impostata su john@EMC.COM.
# kinit sally@EMC.COM
# hdfs dfs -chown john /path/to/file
Le aree di autenticazione fornite in corrispondenza della riga di comando hanno la precedenza sulle
impostazioni delle proprietà.
<property>
<name>fs.viprfs.auth.identity_translation
</name>
216
Proprietà
Descrizione
</property>
fs.viprfs.auth.realm
L'area di autenticazione assegnata agli utenti quando la proprietà fs.viprfs.auth.identity_translation è
impostata su FIXED_REALM.
<property>
<value>MY_REALM</value>
</property>
fs.viprfs.auth.anonymou Questa proprietà mappa in modo anonimo gli object di proprietà all'utente corrente in modo che
s_translation
quest'ultimo possa modificarli.
Hadoop prevede che gli object abbiano un proprietario. Tuttavia con ECS HDFS chiunque può aggiornare
gli object di proprietà anonima. I valori possibili sono:
l
CURRENT_USER: consente all'utente di leggere e scrivere object di proprietà anonima. Quando un
object è stat'd, l'utente che "possiede" il blob è l'utente Kerberos corrente.
l
NONE: (predefinito). Non viene eseguito alcun mapping. Gli object la cui proprietà è anonima hanno
un proprietario vuoto. Alcune applicazioni non consentono all'utente corrente di accedere agli
object di proprietà anonima.
<property>
</property>
Proprietà del responsabile del servizio e dell'area di autenticazione Kerberos
viprfs.security.principal
Questa proprietà specifica l'entità del servizio ECS. Questa proprietà fornisce al KDC informazioni sul
servizio ECS. Questo valore è specifico della propria configurazione.
Il nome dell'entità può includere "_HOST", che viene automaticamente sostituito con l'FQDN del nodo di
dati effettivo in fase di runtime.
<property>
<value>vipr/_HOST@<realm></value>
</property>
Ad esempio:
<property>
<value>vipr/_HOST@example.com</value>
</property>
217
Utilizzo di YARN
Quando Kerberos è abilitato con ECS HDFS, Resource Manager (RM) e Node Manager
(NM) di YARN devono essere eseguiti come la stessa entità Kerberos. Ecco un esempio di
impostazione di questo tipo nelle proprietà core-site.xml:
fs.vipr.auth.service.yarn.principal = rm/_HOST@ACME.COM
fs.vipr.auth.service.yarn.keytab = /etc/security/keytab/rm.keytab
yarn.nodemanager.keytab = /etc/security/keytab/rm.keytab
yarn.nodemanager.principal = rm/_HOST@ACME.COM
yarn.resourcemanager.keytab = /etc/security/keytab/rm.keytab
yarn.resourcemanager.principal = rm/_HOST@ACME.COM
File core-site.xml di esempio per la modalità di autenticazione semplice
Questo file core-site.xml è un esempio delle proprietà ECS HDFS per la modalità di
autenticazione semplice.
ESEMPIO 2 core-site.xml
<property>
</property>
<property>
</property>
<property>
</property>
<property>
<value>203.0.113.10,203.0.113.11,203.0.113.12</value>
</property>
<property>
</property>
<property>
<name>fs.vipr.installation.Site1.resolution.dynamic.time_to_live_ms</
name>
</property>
<property>
</property>
<property>
</property>
<property>
218
ESEMPIO 2 core-site.xml (continua)
</property>
<property>
<value>MY.TEST.REALM</value>
</property>
File core-site.xml di esempio per la modalità di autenticazione semplice
219
220
PARTE 8
Accesso ai dati ECS
Capitolo 26, "Supporto ECS Amazon S3 Object Service API"
Capitolo 27, "Supporto ECS OpenStack Swift Object Service API"
Capitolo 28, "Supporto API ECS EMC Atmos Object Service"
Accesso ai dati ECS
221
Accesso ai dati ECS
222
CAPITOLO 26
l
API Amazon S3....................................................................................................224
223
API Amazon S3
In questo articolo viene descritto il supporto di ECS per Amazon S3 API.
Amazon S3 Object Service viene resa disponibile nelle seguenti porte.
Tabella 38 Porte per Amazon S3 Object Service
Protocollo
Porte
HTTP
9020
HTTPS
9021
Nelle sezioni indicate di seguito vengono descritti il supporto per S3 API, l'estensione
fornita da ECS, la modalità di autenticazione con il servizio e la modalità di utilizzo dei kit
SDK per sviluppare i client per l'accesso al servizio:
l
Funzionalità supportate e non supportate di API S3 a pagina 224
l
Estensioni delle API a pagina 227
l
Autenticazione con il servizio S3 a pagina 231
l
Utilizzo di SDK per l'accesso al servizio S3 a pagina 231
Alcuni aspetti dell'indirizzamento dei bucket e dell'autenticazione sono specifici di ECS.
Se si desidera configurare un'applicazione esistente per la comunicazione con ECS o
sviluppare una nuova applicazione che utilizza S3 API per la comunicazione con ECS, fare
riferimento all'articolo seguente:
l
Indirizzamento di object storage ECS e utilizzo dell'URL di base a pagina 134
Funzionalità supportate e non supportate di API S3
ECS supporta un subset di Amazon S3 REST API.
Le seguenti sezioni riportano informazioni dettagliate sulle API supportate e non
supportate:
l
API S3 supportate a pagina 224
l
API S3 non supportate a pagina 226
API S3 supportate
La tabella seguente riporta i metodi API S3 supportati.
Tabella 39 API S3 supportate
Funzionalità
Note
GET service
ECS supporta parametri marker e max-keys per consentire il
paging dell'elenco di bucket.
GET /?marker=<bucket>&max-keys=<num>
Ad esempio:
GET /?marker=mybucket&max-keys=40
DELETE Bucket
224
Tabella 39 API S3 supportate (continua)
Funzionalità
Note
DELETE Bucket cors
DELETE Bucket lifecycle
Solo la parte di scadenza è supportata nel ciclo di vita. Le policy
correlate all'archiviazione (AWS Glacier) non sono supportate.
GET Bucket (List Objects)
GET Bucket cors
GET Bucket acl
GET Bucket lifecycle
GET Bucket Object versions
GET Bucket versioning
HEAD Bucket
List Multipart Uploads
PUT Bucket
PUT Bucket cors
PUT Bucket acl
PUT Bucket lifecycle
PUT Bucket versioning
DELETE Object
Delete Multiple Objects
GET Object
GET Object ACL
HEAD Object
PUT Object
Supporta PUT in blocco
PUT Object acl
PUT Object - Copy
OPTIONS object
Initiate Multipart Upload
Upload Part
Upload Part - Copy
Complete Multipart Upload
ECS restituisce un ETag "00" per questa richiesta. Differisce
dalla risposta di Amazon S3.
Abort Multipart Upload
List parts
Funzionalità supportate e non supportate di API S3
225
Tabella 40 Funzionalità aggiuntive
Funzionalità
Note
URL prefirmati
ECS supporta l'uso di URL prefirmati per consentire agli utenti di
ottenere l'accesso agli object senza credenziali.
Ulteriori informazioni sono disponibili qui.
PUT in blocco
L'operazione PUT può essere utilizzata per caricare object in
blocchi. Il trasferimento in blocco utilizza l'intestazione TransferEncoding (Transfer-Encoding: chunked) per specificare che il
contenuto verrà trasmesso in blocchi. In questo modo sarà
possibile inviare il contenuto prima di conoscere le dimensioni
totali del payload.
API S3 non supportate
La tabella seguente riporta i metodi API S3 non supportati.
Tabella 41 API S3 non supportate
Funzionalità
Note
DELETE Bucket Policy
DELETE Bucket tagging
DELETE Bucket website
GET Bucket policy
GET Bucket location
ECS tiene presente solo un singolo data center virtuale.
GET Bucket logging
GET Bucket notification
La notifica viene definita solo per funzionalità di ridondanza
ridotta in S3. Al momento, ECS non supporta le notifiche.
GET Bucket tagging
GET Bucket requestPayment
ECS possiede un proprio modello di pagamento.
GET Bucket website
PUT Bucket policy
PUT Bucket logging
PUT Bucket notification
La notifica viene definita solo per funzionalità di ridondanza
ridotta in S3. Al momento, ECS non supporta le notifiche.
PUT Bucket tagging
PUT Bucket requestPayment
PUT Bucket website
Object APIs
GET Object torrent
POST Object
226
ECS possiede un proprio modello di pagamento.
Tabella 41 API S3 non supportate (continua)
Funzionalità
Note
POST Object restore
Questa operazione è collegata ad AWS Glacier, che non è
supportato in ECS.
Estensioni delle API
Sono supportate numerose estensioni delle API object.
Le estensioni e le API che le supportano sono elencate nella tabella seguente.
Tabella 42 Estensioni delle API object
Funzionalità
Note
PUT Object (gammaaggiornamento)
Utilizza l'intestazione Range per specificare la gamma di object da
aggiornare.
Aggiornamento di una gamma di byte in un object a pagina 227
PUT Object (gammasovrascrittura)
Utilizza l'intestazione Range per specificare la gamma di object da
sovrascrivere.
Sovrascrittura di una parte di un object a pagina 228
PUT Object (gammaaggiunta)
Utilizza l'intestazione Range per specificare la gamma di object
aggiunta.
Aggiunta di dati a un object a pagina 229
GET Object (gammalettura)
Utilizza l'intestazione Range per specificare la gamma di byte object da
leggere.
Lettura di più gamme di byte in un object a pagina 230
Aggiornamento di una gamma di byte in un object
Di seguito è riportato un esempio di utilizzo delle estensioni API ECS per l'aggiornamento
di una gamma di byte di un object.
Innanzitutto eseguire una richiesta GET per l'object denominato object1 situato in
bucket1 per esaminare l'object. object1 ha il valore The quick brown fox
jumps over the lazy dog.
GET /bucket1/object1 HTTP/1.1
Date: Mon, 17 Jun 2013 20:04:40 -0000
x-emc-namespace: emc
Content-Type: application/octet-stream
Authorization: AWS wuser1:9qxKiHt2H7upUDPF86dvGp8VdvI=
Accept-Encoding: gzip, deflate, compress
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 20:04:40 GMT
227
Last-Modified: Mon, 17 Jun 2013 20:04:28 GMT
ETag: 6
Content-Type: application/json
Content-Length: 43
The quick brown fox jumps over the lazy dog.
A questo punto aggiornare una gamma di byte specifica in questo object. A questo scopo
l'intestazione Range nella richiesta di object data deve includere gli offset iniziale e finale
dell'object che si desidera aggiornare. Il formato è: Range:
bytes=<startOffset>-<endOffset>
Nell'esempio seguente, la richiesta PUT include l'intestazione Range con il valore
bytes=10-14 a indicare che i byte 10, 11, 12, 13 e 14 devono essere sostituiti dal
valore inviato nella richiesta. Qui viene inviato il nuovo valore green.
PUT /bucket1/object1 HTTP/1.1
Content-Length: 5
Range: bytes=10-14
ACCEPT: application/json,application/xml,text/html,application/octetstream
Date: Mon, 17 Jun 2013 20:15:16 -0000
Authorization: AWS wuser1:xHJcAYAEQansKLaF+/4PdLBHyaM=
green
HTTP/1.1 204 No Content
ETag: 10
x-amz-id-2: object1
x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52a
Content-Length: 0
Date: Mon, 17 Jun 2013 20:15:16 GMT
Rileggendo l'object, il nuovo valore è ora The quick green fox jumps over the
lazy dog. (il termine brown è stato sostituito da green). È stata aggiornata una
gamma di byte specifica all'interno di questo object.
Cookie: JSESSIONID=wdit99359t8rnvipinz4tbtu
Date: Mon, 17 Jun 2013 20:16:00 -0000
Authorization: AWS wuser1:OGVN4z8NV5vnSAilQTdpv/fcQzU=
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 20:16:00 GMT
ETag: 10
Content-Length: 43
The quick green fox jumps over the lazy dog.
Sovrascrittura di una parte di un object
Di seguito è riportato un esempio di utilizzo delle estensioni API ECS per la sovrascrittura
di una parte di un object.
228
È possibile sovrascrivere una parte di un object fornendo solo l'offset iniziale nella
richiesta di dati. I dati della richiesta verranno sovrascritti a partire dall'offset fornito. Il
formato è: Range: <startingOffset>Ad esempio, per scrivere i dati brown cat a partire dall'offset 10, emettere la seguente
richiesta PUT:
Content-Length: 9
Range: bytes=10ACCEPT: application/json,application/xml,text/html,application/octetstream
Date: Mon, 17 Jun 2013 20:51:41 -0000
Authorization: AWS wuser1:uwPjDAgmazCP5lu77Zvbo+CiT4Q=
brown cat
ETag: 25
x-amz-id-2: object1
x-amz-request-id: 65be45c2-0ee8-448a-a5a0-fff82573aa3b
Content-Length: 0
Date: Mon, 17 Jun 2013 20:51:41 GMT
Quando si recupera l'object, è possibile visualizzare il valore finale The quick brown
cat jumps over the lazy dog and cat. (green fox è stato sostituito con
brown cat). È stata sovrascritta una parte dei dati in questo object in corrispondenza
dell'offset iniziale fornito.
Date: Mon, 17 Jun 2013 20:51:55 -0000
Authorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 20:51:55 GMT
ETag: 25
Content-Length: 51
The quick brown cat jumps over the lazy dog and cat.
Aggiunta di dati a un object
Di seguito è riportato un esempio di utilizzo delle estensioni API ECS per l'aggiunta di dati
a un object.
Possono esservi casi in cui è necessario eseguire un'aggiunta a un object, ma
determinare l'offset di byte esatto non è efficiente o utile. Per questo scenario ECS
fornisce la capacità di aggiungere automaticamente dati all'object senza specificare un
offset (l'offset corretto viene restituito nella risposta).
Un'intestazione Range con il valore speciale bytes=-1- può essere utilizzata per
aggiungere dati a un object. In questo modo l'object può essere esteso senza conoscere
la dimensione dell'object esistente.
Il formato è: Range: bytes=-1-
229
Una richiesta di esempio che mostra l'aggiunta a un object esistente mediante un valore
per Range di bytes=-1-. Qui il valore and cat viene inviato nella richiesta.
Content-Length: 8
Range: bytes=-1ACCEPT: application/json,application/xml,text/html,application/octetstream
Date: Mon, 17 Jun 2013 20:46:01 -0000
Authorization: AWS wuser1:/sqOFL65riEBSWLg6t8hL0DFW4c=
and cat
ETag: 24
x-amz-id-2: object1
x-amz-request-id: 087ac237-6ff5-43e3-b587-0c8fe5c08732
Content-Length: 0
Date: Mon, 17 Jun 2013 20:46:01 GMT
Quando si recupera di nuovo l'object, è possibile visualizzare il valore completo The
quick green fox jumps over the lazy dog and cat. Si sono aggiunti dati
a questo object.
Date: Mon, 17 Jun 2013 20:46:56 -0000
Authorization: AWS wuser1:D8FSE8JoLl0MTQcFmd4nG1gMDTg=
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 20:46:56 GMT
ETag: 24
Content-Length: 51
The quick green fox jumps over the lazy dog and cat.
Lettura di più gamme di byte in un object
Di seguito è riportato un esempio di utilizzo delle estensioni API ECS per la lettura di più
gamme di byte in un object.
Per leggere due specifiche gamme di byte all'interno dell'object denominato object1, è
necessario emettere la seguente richiesta GET per Range: bytes==4-8,41-44. La
risposta di lettura sarà riferita ai termini quick e lazy.
Nota
Amazon S3 API supporta solo una gamma in caso di utilizzo dell'intestazione HTTP
Range per la lettura; ECS supporta più gamme di byte.
Date: Mon, 17 Jun 2013 20:51:55 -0000
Range: bytes==4-8,41-44
230
HTTP/1.1 206 Partial Content
Date: Mon, 17 Jun 2013 20:51:55 GMT
Content-Type: multipart/byteranges;boundary=bound04acf7f0ae3ccc
Content-Length: 230
--bound04acf7f0ae3ccc
Content-Range: bytes 4-8/50
quick
lazy
--bound04acf7f0ae3ccc--
Autenticazione con il servizio S3
L'autenticazione con le API Amazon S3 è descritta nella documentazione di Amazon S3
riportata di seguito. Questo argomento identifica tutti gli aspetti del processo di
autenticazione specifici di ECS.
L'autenticazione su un sistema ECS attraverso l'utilizzo di Amazon S3 API viene descritta
nelle sezioni riportate di seguito. L'algoritmo completo per l'autenticazione S3 è descritto
nella documentazione di Amazon S3.
Amazon S3 utilizza un'intestazione di autorizzazione che deve essere presente in tutte le
richieste per identificare l'utente e fornire una firma per la richiesta. Quando si chiama
Amazon, l'intestazione deve avere il seguente formato:
Authorization: AWS <AWSAccessKeyId>:<Signature>
In ECS AWSAccessKeyId viene mappato all'ID utente (UID) di ECS. L'ID della chiave di
accesso di AWS è composto da 20 caratteri (alcuni client S3, come S3 Browser,
effettuano questo controllo). Tuttavia, il data service ECS non presenta questo limite.
La firma viene calcolata dagli elementi della richiesta e della chiave segreta dell'utente,
come descritto nella documentazione di Amazon S3:
l
http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
Le seguenti note possono essere applicate:
l
Nell'object data service di ECS l'UID può essere configurato (tramite ECS API o
l'interfaccia utente di ECS) con 2 chiavi segrete. Il data service di ECS cerca di
utilizzare la prima chiave segreta e, se la firma calcolata non corrisponde, tenta di
utilizzare la seconda chiave segreta. Se la seconda chiave ha esito negativo, la
richiesta viene rifiutata. Quando gli utenti aggiungono o modificano la chiave
segreta, devono aspettare 2 minuti per poter aggiornare tutti i nodi del data service
con la nuova chiave segreta, prima di utilizzarla.
l
Inoltre, nel data service di ECS anche il namespace viene incluso nel calcolo della
firma HMAC.
Utilizzo di SDK per l'accesso al servizio S3
Nello sviluppo di applicazioni che comunicano con il servizio S3 di ECS sono disponibili
vari SDK che supportano l'attività di sviluppo.
Autenticazione con il servizio S3
231
EMC Community fornisce informazioni sui vari client disponibili e offre indicazioni sul
loro utilizzo: Risorse sviluppatore EMC ViPR.
Negli argomenti riportati di seguito viene descritto l'utilizzo di Amazon S3 SDK e di EMC
ECS Java SDK.
l
Utilizzo di Java Amazon SDK a pagina 232
l
Client Java SDK per ECS a pagina 233
Nota
Se si desidera utilizzare le estensioni API ECS (vedere ), EMC ECS Java SDK fornisce
supporto per queste estensioni. È possibile utilizzare Amazon Java SDK se non si richiede
supporto per le estensioni ECS o si dispone già di applicazioni che le utilizzano.
Utilizzo di Java Amazon SDK
È possibile accedere all'object storage di ECS utilizzando Java S3 SDK.
Per impostazione predefinita, il client object AmazonS3Client viene codificato in modo da
funzionare direttamente su amazon.com. In questa sezione viene spiegato come
configurare AmazonS3Client per l'utilizzo in ECS.
Per creare un'istanza dell'object AmazonS3Client, è necessario fornire le credenziali. Ciò
è possibile attraverso la creazione di un object AWSCredentials e fornendo la chiave di
accesso di AWS (nome utente ECS) insieme alla chiave segreta generata per ECS.
Il seguente frammento di codice mostra come impostare queste opzioni.
AmazonS3Client client = new AmazonS3Client(new
BasicAWSCredentials(uid, secret));
Per impostazione predefinita, il client Amazon tenta di contattare Amazon WebServices.
Per ignorare questo comportamento e contattare ECS, è necessario impostare un
endpoint specifico,
utilizzando il metodo setEndpoint. Il protocollo specificato nell'endpoint determina se il
client deve essere diretto alla porta HTTP (9020) o alla porta HTTPS (9021).
Nota
Se si intende utilizzare la porta HTTPS, il JDK dell'applicazione deve essere configurato
per validare il certificato ECS correttamente. In caso contrario, il client genera errori di
verifica SSL e non si connette.
Nel frammento riportato di seguito, il client viene utilizzato per accedere a ECS su HTTP:
client.setEndpoint("http://ecs1.emc.com:9020");
Quando si utilizza l'indirizzamento path-style (ecs1.emc.com/mybucket), è necessario
impostare l'opzione setPathStyleAccess, come mostrato di seguito:
S3ClientOptions options = new S3ClientOptions();
options.setPathStyleAccess(true);
client.setEndpoint("http://ecs1.emc.com:9020");
client.setS3ClientOptions(options);
232
Il codice seguente mostra come elencare gli object in un bucket.
ObjectListing objects = client.listObjects("mybucket");
for (S3ObjectSummary summary : objects.getObjectSummaries()) {
System.out.println(summary.getKey()+ "
"+summary.getOwner());
}
L'operazione CreateBucket differisce da altre operazioni, in quanto richiede la specifica
di una regione. S3 consente di indicare il data center in cui il bucket deve essere creato.
Tuttavia, ECS non supporta le regioni. Per questo motivo, durante la chiamata
dell'operazione CreateBucket, viene specificata la regione standard, che interrompe il
download del file di configurazione di Amazon Region da Amazon CloudFront da parte del
client AWS.
client.createBucket("mybucket", "Standard");
Di seguito viene fornito l'esempio completo di comunicazione con il data service S3 di
ECS, creazione di bucket e manipolazione di un object.
public class Test {
public static String uid = "root";
public static String secret =
"KHBkaH0Xd7YKF43ZPFbWMBT9OP0vIcFAMkD/9dwj";
public static String viprDataNode = "http://ecs.yourco.com:9020";
public static String bucketName = "myBucket";
public static File objectFile = new File("/photos/cat1.jpg");
public static void main(String[] args) throws Exception {
S3ClientOptions options = new S3ClientOptions();
options.setPathStyleAccess(true);
AmazonS3Client client = new AmazonS3Client(credentials);
client.setEndpoint(viprDataNode);
client.setS3ClientOptions(options);
client.createBucket(bucketName, "Standard");
listObjects(client);
client.putObject(bucketName, objectFile.getName(),
objectFile);
client.copyObject(bucketName,objectFile.getName(),bucketName,
"copy-" + objectFile.getName());
}
"
}
public static void listObjects(AmazonS3Client client) {
ObjectListing objects = client.listObjects(bucketName);
for (S3ObjectSummary summary : objects.getObjectSummaries()) {
System.out.println(summary.getKey()+
"+summary.getOwner());
}
}
Client Java SDK per ECS
ECS Java SDK si basa su Amazon S3 Java SDK e supporta le estensioni API ECS.
Utilizzo di SDK per l'accesso al servizio S3
233
Di seguito, è mostrato un esempio di utilizzo di ViPRS3client.
package com.emc.ecs.sample;
import com.amazonaws.util.StringInputStream;
import com.emc.vipr.services.s3.ViPRS3Client;
public class BucketCreate {
private ViPRS3Client s3;
public BucketCreate() {
URI endpoint = new URI(“http://ecs.yourco.com:9020”);
String accessKey = “fred@yourco.com”;
String secretKey = “pcQQ20rDI2DHZOIWNkAug3wK4XJP9sQnZqbQJev3”;
BasicAWSCredentials creds = new BasicAWSCredentials(accessKey,
secretKey);
ViPRS3Client client = new ViPRS3Client(endpoint, creds);
}
public static void main(String[] args) throws Exception {
BucketCreate instance = new BucketCreate();
instance.runSample();
}
public void runSample() {
String bucketName="mybucket";
String key1 = "test1.txt";
String content = "Hello World!";
try {
s3.createBucket(bucketName);
s3.putObject(bucketName, key1, new
StringInputStream(content), null);
}
catch (Exception e) {
}
}
234
}
CAPITOLO 27
l
OpenStack Swift API............................................................................................236
235
OpenStack Swift API
ECS include il supporto per OpenStack Swift API. Questo articolo illustra le operazioni
supportate e i meccanismi di autorizzazione e autenticazione.
OpenStack Swift Object Service viene resa disponibile nelle seguenti porte.
Tabella 43 Porte per OpenStack Swift Object Service
Protocollo
Porte
HTTP
9024
HTTPS
9025
Nelle seguenti sezioni vengono descritti i metodi supportati, le estensioni ECS e il
meccanismo di autenticazione:
l
Operazioni supportate di OpenStack Swift a pagina 236
l
Estensioni delle API a pagina 238
l
Autenticazione OpenStack versione 1 a pagina 242
l
Autenticazione OpenStack versione 2 a pagina 243
l
Autorizzazione su container a pagina 245
Gli esempi che illustrano l'utilizzo di OpenStack Swift API sono disponibili qui:
l
Esempi di OpenStack API
Operazioni supportate di OpenStack Swift
Le sezioni seguenti elencano le richieste OpenStack REST API supportate da ECS.
l
Chiamate supportate di OpenStack Swift a pagina 236
l
Chiamate non supportate di OpenStack Swift a pagina 237
Queste informazioni sono tratte dalla sezione V1 sull'API di object storage della
documentazione OpenStack API Reference.
Chiamate supportate di OpenStack Swift
In ECS sono supportate le seguenti chiamate OpenStack Swift REST API.
Tabella 44 Chiamate supportate di OpenStack Swift
236
Metodo
Percorso
Descrizione
GET
v1/{account}
Consente di eseguire il retrieve dell'elenco degli
storage container esistenti ordinati per nome.
GET
v1/{account}/{container}
Consente di eseguire il retrieve dell'elenco degli object
archiviati nel container.
PUT
Consente di creare un container.
DELETE
Consente di eliminare un container vuoto.
POST
Consente di creare o aggiornare i metadati arbitrari del
container associando le intestazioni personalizzate
dei metadati all'URI a livello del container. Tali
Tabella 44 Chiamate supportate di OpenStack Swift (continua)
Metodo
Percorso
Descrizione
intestazioni devono assumere il formato X-ContainerMeta-*.
HEAD
Consente di eseguire il retrieve dei metadati del
container. Attualmente non include il numero di object
e i byte utilizzati.
L'utente richiede privilegi di amministratore.
GET
v1/{account}/{container}/
{object}
Consente di eseguire il retrieve dei dati di object.
PUT
{object}
Consente di scrivere, o sovrascrivere, il contenuto e i
metadati di un object.
Si utilizza per copiare un object esistente in un altro
utilizzando l'intestazione X-Copy-From per designare
l'origine.
DELETE
{object}
Consente di rimuovere un object dal sistema di storage
in modo permanente. Si può utilizzare la
combinazione del comando COPY seguito da DELETE
per rimuovere un object in modo efficace.
HEAD
{object}
Consente di eseguire il retrieve di metadati e altre
intestazioni HTTP standard di un object.
POST
{object}
Consente di impostare e sovrascrivere i metadati
arbitrari dell'object. Tali metadati devono assumere il
formato X-Object-Meta-*. Questa operazione può
anche assegnare il formato X-Delete-At- o X-DeleteAfter per gli object in scadenza. Tuttavia non permette
di modificare altre intestazioni, come Content-Type.
Chiamate non supportate di OpenStack Swift
In ECS non sono supportate le seguenti chiamate OpenStack Swift REST API.
Tabella 45 Chiamate non supportate di OpenStack Swift
Metodo
Percorso
Descrizione
HEAD
v1/{account}
Consente di eseguire il retrieve dei metadati
dell'account, tra cui il numero di container, i byte totali
archiviati in OpenStackObject Storage per l'account o
il tenant.
POST
v1/{account}
Consente di creare o aggiornare i metadati
dell'account associando le intestazioni personalizzate
dei metadati all'URI a livello dell'account. Tali
intestazioni devono assumere il formato X-AccountMeta-*.
COPY
{object}
La copia è supportata utilizzando il metodo PUT v1/
{account}/{container}/{object} con l'intestazione XCopy-From.
Operazioni supportate di OpenStack Swift
237
Funzionalità
Note
Supporto API
PUT Object
(gammaaggiornamento)
Utilizza l'intestazione Range per specificare la gamma di
object da aggiornare.
S3/Atmos/Swift
PUT Object
(gammasovrascrittura)
object da sovrascrivere.
PUT Object
(gammaaggiunta)
object aggiunta.
GET Object
(gamma-lettura)
byte object da leggere.
Aggiornamento di una gamma di byte in un object a
pagina 227
S3/Atmos/Swift
Sovrascrittura di una parte di un object a pagina 228
S3/Atmos/Swift
S3/Atmos/Swift
Lettura di più gamme di byte in un object a pagina
230
Aggiornamento di una gamma di byte in un object
Di seguito è riportato un esempio di utilizzo delle estensioni API ECS per l'aggiornamento
di una gamma di byte di un object.
Innanzitutto eseguire una richiesta GET per l'object denominato object1 situato in
bucket1 per esaminare l'object. object1 ha il valore The quick brown fox
jumps over the lazy dog.
Date: Mon, 17 Jun 2013 20:04:40 -0000
Authorization: AWS wuser1:9qxKiHt2H7upUDPF86dvGp8VdvI=
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 20:04:40 GMT
ETag: 6
Content-Length: 43
The quick brown fox jumps over the lazy dog.
238
A questo punto aggiornare una gamma di byte specifica in questo object. A questo scopo
l'intestazione Range nella richiesta di object data deve includere gli offset iniziale e finale
dell'object che si desidera aggiornare. Il formato è: Range:
bytes=<startOffset>-<endOffset>
Nell'esempio seguente, la richiesta PUT include l'intestazione Range con il valore
bytes=10-14 a indicare che i byte 10, 11, 12, 13 e 14 devono essere sostituiti dal
valore inviato nella richiesta. Qui viene inviato il nuovo valore green.
Content-Length: 5
Range: bytes=10-14
Date: Mon, 17 Jun 2013 20:15:16 -0000
Authorization: AWS wuser1:xHJcAYAEQansKLaF+/4PdLBHyaM=
green
ETag: 10
x-amz-id-2: object1
x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52a
Content-Length: 0
Date: Mon, 17 Jun 2013 20:15:16 GMT
Rileggendo l'object, il nuovo valore è ora The quick green fox jumps over the
lazy dog. (il termine brown è stato sostituito da green). È stata aggiornata una
gamma di byte specifica all'interno di questo object.
Cookie: JSESSIONID=wdit99359t8rnvipinz4tbtu
Date: Mon, 17 Jun 2013 20:16:00 -0000
Authorization: AWS wuser1:OGVN4z8NV5vnSAilQTdpv/fcQzU=
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 20:16:00 GMT
ETag: 10
Content-Length: 43
The quick green fox jumps over the lazy dog.
Sovrascrittura di una parte di un object
Di seguito è riportato un esempio di utilizzo delle estensioni API ECS per la sovrascrittura
di una parte di un object.
È possibile sovrascrivere una parte di un object fornendo solo l'offset iniziale nella
richiesta di dati. I dati della richiesta verranno sovrascritti a partire dall'offset fornito. Il
formato è: Range: <startingOffset>-
239
Ad esempio, per scrivere i dati brown cat a partire dall'offset 10, emettere la seguente
richiesta PUT:
Content-Length: 9
Range: bytes=10ACCEPT: application/json,application/xml,text/html,application/octetstream
Date: Mon, 17 Jun 2013 20:51:41 -0000
Authorization: AWS wuser1:uwPjDAgmazCP5lu77Zvbo+CiT4Q=
brown cat
ETag: 25
x-amz-id-2: object1
x-amz-request-id: 65be45c2-0ee8-448a-a5a0-fff82573aa3b
Content-Length: 0
Date: Mon, 17 Jun 2013 20:51:41 GMT
Quando si recupera l'object, è possibile visualizzare il valore finale The quick brown
cat jumps over the lazy dog and cat. (green fox è stato sostituito con
brown cat). È stata sovrascritta una parte dei dati in questo object in corrispondenza
dell'offset iniziale fornito.
Date: Mon, 17 Jun 2013 20:51:55 -0000
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 20:51:55 GMT
ETag: 25
Content-Length: 51
The quick brown cat jumps over the lazy dog and cat.
a un object.
Il formato è: Range: bytes=-1-
240
Una richiesta di esempio che mostra l'aggiunta a un object esistente mediante un valore
Content-Length: 8
Date: Mon, 17 Jun 2013 20:46:01 -0000
Authorization: AWS wuser1:/sqOFL65riEBSWLg6t8hL0DFW4c=
and cat
ETag: 24
x-amz-id-2: object1
x-amz-request-id: 087ac237-6ff5-43e3-b587-0c8fe5c08732
Content-Length: 0
Date: Mon, 17 Jun 2013 20:46:01 GMT
a questo object.
Date: Mon, 17 Jun 2013 20:46:56 -0000
Authorization: AWS wuser1:D8FSE8JoLl0MTQcFmd4nG1gMDTg=
HTTP/1.1 200 OK
Date: Mon, 17 Jun 2013 20:46:56 GMT
ETag: 24
Content-Length: 51
The quick green fox jumps over the lazy dog and cat.
Lettura di più gamme di byte in un object
Di seguito è riportato un esempio di utilizzo delle estensioni API ECS per la lettura di più
gamme di byte in un object.
Per leggere due specifiche gamme di byte all'interno dell'object denominato object1, è
necessario emettere la seguente richiesta GET per Range: bytes==4-8,41-44. La
risposta di lettura sarà riferita ai termini quick e lazy.
Nota
Amazon S3 API supporta solo una gamma in caso di utilizzo dell'intestazione HTTP
Range per la lettura; ECS supporta più gamme di byte.
Date: Mon, 17 Jun 2013 20:51:55 -0000
Range: bytes==4-8,41-44
241
HTTP/1.1 206 Partial Content
Date: Mon, 17 Jun 2013 20:51:55 GMT
Content-Type: multipart/byteranges;boundary=bound04acf7f0ae3ccc
Content-Length: 230
quick
lazy
--bound04acf7f0ae3ccc--
Autenticazione OpenStack versione 1
Per comunicare con ECS
Procedura
1. Acquisire un UID e una password da ECS. L'UID deve essere un nome LDAP o Active
Directory. Chiamare la seguente ECS REST API per generare una password.
ECS tramite OpenStack Swift API, attenersi alla procedura descritta di seguito.
Richiesta:
PUT /object/user-password/myUser@emc.com
<user_password_create>
<password>myPassword</password>
<namespace>EMC_NAMESPACE</namespace>
</user_password_create>
Risposta:
HTTP 200
2. Chiamare l'API REST di autenticazione OpenStack illustrata di seguito. Utilizzare la
porta 9024 per HTTP o la porta 9025 per HTTPS.
Richiesta:
GET /auth/v1.0
X-Auth-User: myUser@emc.com
X-Auth-Key: myPassword
Risposta:
HTTP/1.1
204 No
Content
Date: Mon, 12 Nov 2010 15:32:21 GMT
Server: Apache
X-Storage-Url: https://{hostname}/v1/account
X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb
Content-Length: 0
242
Risultati
Se l'UID e la password sono convalidati da ECS, l'URL e il token di storage vengono
restituiti nell'intestazione della risposta. Ulteriori richieste vengono autenticate
integrando questo token. L'URL di storage fornisce il nome host e l'indirizzo delle risorse.
È possibile accedere a container e object fornendo la seguente intestazione X-StorageUrl:
X-Storage-Url: https://{hostname}/v1/{account}/{container}/{object}
Il token generato scade 24 ore dopo la creazione. Se si ripete la richiesta di
autenticazione entro 24 ore utilizzando gli stessi UID e password, OpenStack restituirà lo
stesso token. Una volta trascorse 24 ore, OpenStack restituirà un nuovo token.
Nell'esempio seguente di autenticazione semplice, la prima chiamata REST restituisce XAuth-Token. La seconda chiamata REST utilizza X-Auth-Token per eseguire una richiesta
GET su un account.
$ curl -i -H "X-Storage-User: tim_250@sanity.local" -H "X-StoragePass: 1fO9X3xyrVhfcokqy3U1UyTY029gha5T+k+vjLqS"
http://ecs.yourco.com:9024/auth/v1.0
X-Storage-Url: http://ecs.yourco.com:9024/v1/s3
X-Auth-Token: 8cf4a4e943f94711aad1c91a08e98435
Server: Jetty(7.6.4.v20120524)
$ curl -v -X GET -s -H "X-Auth-Token:
8cf4a4e943f94711aad1c91a08e98435"
ecs.yourco.com:9024/v1/s3
http://
* About to connect() to ecs.yourco.com port 9024 (#0)
* Trying 203.0.113.10...
* Adding handle: conn: 0x7f9218808c00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f9218808c00) send_pipe: 1, recv_pipe: 0
* Connected to ecs.yourco.com (203.0.113.10) port 9024 (#0)
>
>
>
>
>
>
<
<
<
*
<
<
GET /v1/s3 HTTP/1.1
User-Agent: curl/7.31.0
Host: ecs.yourco.com:9024
Accept: */*
X-Auth-Token: 8cf4a4e943f94711aad1c91a08e98435
Date: Mon, 16 Sep 2013 19:31:45 GMT
Content-Type: text/plain
Server Jetty(7.6.4.v20120524) is not blacklisted
* Connection #0 to host ecs.yourco.com left intact
ECS include il supporto limitato dell'autenticazione di OpenStack versione 2 (Keystone).
243
Prima di cominciare
OpenStack V2 introduce i token senza ambito. Si possono utilizzare per eseguire una
query relativa alle informazioni del tenant. È possibile utilizzare un token senza ambito
insieme alle informazioni del tenant per eseguire una query relativa a un token con
ambito. È possibile utilizzare un token con ambito e un endpoint di servizio per eseguire
l'autenticazione con ECS come descritto nella sezione precedente che illustra
l'autenticazione V1.
I due articoli elencati sotto contengono informazioni di base importanti.
l
Definizione dell'ambito del token e del workflow di OpenStack Keystone
l
Eseguire l'autenticazione per l'API di amministrazione
Procedura
1. Eseguire il retrieve di un token senza ambito.
curl -v -X POST -H 'ACCEPT: application/json' -H "Content-Type:
application/json" -d '{"auth":
{"passwordCredentials" : {"username" : "swift_user", "password" :
"123"}}}' http://203.0.113.10:9024/v2.0/tokens
Il seguente è un esempio di risposta. Il token senza ambito è preceduto dall'ID.
{"access": {"token":
{"id":"d668b72a011c4edf960324ab2e87438b","expires":"1376633127950"l
},"user":
{"name": "sysadmin", "roles":[ ], "role_links":
[ ] },"serviceCatalog":[ ] }} , }
2. Eseguire il retrieve delle informazioni tenant associate al token senza ambito.
curl -v http://203.0.113.10:9024/v2.0/tenants -H 'X-Auth-Token:
d668b72a011c4edf960324ab2e87438b'
Il seguente è un esempio di risposta.
{"tenants_links":[], "tenants":
[{"description":"s3","enabled":true, "name": "s3"}]}
3. Eseguire il retrieve del token con ambito insieme a storageUrl.
curl -v -X POST -H 'ACCEPT: application/json' -H "Content-Type:
application/json" -d '{"auth": {"tenantName" : "s3",
"token":{"id" :
d668b72a011c4edf960324ab2e87438b"}}}' http://203.0.113.10:9024/
v2.0/tokens
Il seguente è un esempio di risposta. Il token con ambito è preceduto dall'ID.
{"access":{"token":{"id":"baf0709e30ed4b138c5db6767ba76a4e
244
","expires":"1376633255485","tenant":
{"description":"s3","enabled":true,"name":"s3"}},
"user":{"name":"swift_admin","roles":[{"name":"member"},
{"name":"admin"}],"role_links":[]},
"serviceCatalog":[{"type":"object-store",
"name":"Swift","endpoints_links":[],"endpoint":[{"internalURL":
"http://203.0.113.10:9024/v1/s3","publicURL":"http://
203.0.113.10:9024/v1/s3"}]}]}}
4. Utilizzare il token con ambito e l'URL dell'endpoint di servizio per l'autenticazione
swift. Questa fase è la stessa descritta per OpenStack V1.
curl -v -H "X-Auth-Token: baf0709e30ed4b138c5db6767ba76a4e" http://
203.0.113.10:9024/v1/s3/{container}/{object}
Autorizzazione su container
L'autorizzazione di OpenStack Swift è mirata solo ai container.
Swift supporta attualmente due tipi di autorizzazione:
l
Autorizzazione basata sulla referenza
l
Autorizzazione basata sui gruppi
ECS 2.0 supporta solo l'autorizzazione basata sui gruppi.
Gli utenti amministratori possono eseguire qualsiasi operazione nell'account. Gli utenti
non amministratori possono eseguire solo operazioni per container in base agli elenchi
di controllo dell'accesso X-Container-Read e X-Container-Write. Agli utenti non
amministratori si possono assegnare le seguenti operazioni:
L'amministratore assegna l'accesso in lettura al container
curl -XPUT -v -H 'X-Container-Read: {GROUP LIST}'
-H 'X-Auth-Token: {TOKEN}'
http://127.0.0.1:8080/v1/AUTH_bourne/{container1}"
Questo comando consente agli utenti appartenenti al gruppo GROUP LIST di disporre dei
diritti di accesso in lettura a container1.
Una volta concessa l'autorizzazione in lettura, gli utenti appartenenti ai gruppi di
destinazione possono effettuare le seguenti operazioni:
l
HEAD container: consente di eseguire il retrieve dei metadati del container.
Consentito solo se l'utente è assegnato al gruppo che dispone dei privilegi di Tenant
Administrator.
l
GET container: consente di ottenere l'elenco degli object in un container.
l
GET objects with container: consente di leggere i contenuti degli object compresi nel
container.
L'amministratore assegna l'accesso in scrittura al container
curl -XPUT -v -H 'X-Container-Write: {GROUP LIST}'
-H 'X-Auth-Token: {TOKEN}'
http://127.0.0.1:8080/v1/AUTH_bourne/{container1}"
Agli utenti nel gruppo GROUP LIST viene assegnata l'autorizzazione in scrittura. Una volta
concessa l'autorizzazione in scrittura, gli utenti appartenenti ai gruppi di destinazione
possono effettuare le seguenti operazioni:
Autorizzazione su container
245
l
POST container: consente di impostare i metadati. Iniziare con il prefisso "XContainer-Meta".
l
PUT objects within container: consente di scrivere/sovrascrivere gli objects nel
container.
Ulteriori informazioni sull'autorizzazione sono disponibili in: Operazioni dei container
246
CAPITOLO 28
l
l
l
l
l
Funzionalità EMC Atmos supportate da API......................................................... 248
Chiamate EMC Atmos REST API supportate.......................................................... 248
Chiamate EMC Atmos REST API non supportate................................................... 250
Supporto subtenant in chiamate EMC Atmos REST API.........................................250
Estensioni delle API.............................................................................................251
247
Funzionalità EMC Atmos supportate da API
ECS supporta un subset di EMC Atmos API. In questo articolo vengono elencate le
operazioni supportate e le estensioni ECS.
EMC Atmos Object Service viene resa disponibile nelle seguenti porte.
Tabella 47 Porte per EMC Atmos Object Service
Protocol
Ports
HTTP
9022
HTTPS
9023
È possibile trovare ulteriori informazioni sulle operazioni supportate nella Atmos
Programmer’s Guide disponibile sulla EMC Supportzone.
l
Atmos Programmer's Guide
La compatibilità di formato del cavo viene fornita per tutte le operazioni supportate. Di
conseguenza, le operazioni descritte in Atmos Programmer's Guide si applicano alle
operazioni API esposte da ECS.
Atmos Programmer's Guide include inoltre informazioni sull'autenticazione tramite le API
di EMC Atmos e offre esempi completi per molte funzionalità supportate.
Chiamate EMC Atmos REST API supportate
ECS supporta un subset di EMC Atmos API.
Sono supportate le seguenti chiamate API REST di EMC Atmos. Vengono visualizzate le
chiamate dell'object e le interfacce di namespace.
Tabella 48 Chiamate API REST di EMC Atmos supportate
Metodolog Percorso
ia
Descrizione
Operazioni di servizio
GET
/rest/service
Acquisizione informazioni
sul sistema
Operazioni relative all'object
POST
248
/rest/objects
/rest/namespace/<path>
Creazione di object:
DELETE
/rest/objects/<ObjectID>
Eliminazione di object
PUT
Aggiornamento object
Vedere le note riportate di
seguito.
Vedere le note riportate di
seguito.
Tabella 48 Chiamate API REST di EMC Atmos supportate (continua)
Metodolog Percorso
ia
Descrizione
GET
Lettura object (o elenco
directory)
POST
/rest/namespace/<path>?rename
Rinomina object
Operazioni metadati
GET
/rest/objects/<ObjectID>?metadata/user
/rest/namespace/<path>?metadata/user
Acquisizione metadati
utente per object
POST
/rest/objects/<ObjectID>?metadata/user
Impostazione metadati
utente
DELETE
/rest/objects/<objectID>?metadata/user
Eliminazione metadati
utente
GET
/rest/objects/<ObjectID>?metadata/system
/rest/namespace/<path>?metadata/system
Acquisizione metadati
sistema per object
GET
/rest/objects/<ObjectID>?acl
/rest/namespace/<path>?acl
Acquisizione ACL
POST
/rest/objects/<ObjectID>?acl
/rest/namespace/<path>?acl
Impostazione ACL
GET
/rest/objects/<ObjectID>?metadata/tags
/rest/namespace/<path>?metadata/tags
Acquisizione tag metadati
per object
GET
/rest/objects/<ObjectID>?info
/rest/namespace/<path>?info
Acquisizione informazioni
object
Intestazione /rest/objects/<ObjectID>
Acquisizione di tutti i
metadati dell'object
Operazioni spazio-object
GET
/rest/objects
Elenco object
GET
/rest/objects?listabletags
Acquisizione tag
elencabili
Nota
l
L'intestazione x-emc-wschecksum non è supportata.
l
Il caricamento del modulo HTML non è supportato.
l
GET /rest/objects non supporta diversi tipi di risposta con x-emc-accept. Ad
esempio, testo/normale non è supportato.
l
La data di scadenza e il mantenimento degli object non sono supportati.
Chiamate EMC Atmos REST API supportate
249
Chiamate EMC Atmos REST API non supportate
Le seguenti chiamate API REST di EMC Atmos non sono supportate.
Tabella 49 Chiamate API REST di EMC Atmos non supportate
Metodologia Percorso
Descrizione
Versioning object
POST
/rest/objects/<ObjectID>?versions
Creazione di una
versione di object
DELETE
/rest/objects/<objectID>?versions
Eliminazione di una
versione di object
GET
Elenco versioni di object
PUT
Restore versione object
Accesso anonimo
GET
/rest/objects/<ObjectId>?
uid=<uid>&expires=<exp>&signature=<sig>
/rest/namespace/<path>?
uid=<uid>&expires=<exp>&signature=<sig>
URL condivisibile
POST
/rest/accesstokens
Creazione token di
accesso
GET
/rest/accesstokens/<token_id>?info
Accesso a dettagli token
DELETE
/rest/accesstokens/<token_id>
Eliminazione token di
accesso
GET
/rest/accesstokens
Elenco token di accesso
GET
/rest/accesstokens/<token_id>
Download contenuto
anonimo
Nota
La protezione checksum mediante l'intestazione personalizzata x-emc-wschecksum non
è supportata.
Supporto subtenant in chiamate EMC Atmos REST API
ECS include due chiamate API REST native, che prevedono nello specifico l'aggiunta di
supporto subtenant di ECS ad applicazioni Atmos.
Di seguito, sono riportate le chiamate:
250
Telefonata API
Esempio
Creazione
subtenant
INSERIRE url Http: /rest/subtenant
Intestazioni richieste: x-emc-uid (ad esempio, x-emcuid=wuser1@SANITY.LOCAL ) x-emc-signature.
Telefonata API
Esempio
Il subtenantID è impostato nell'intestazione "subtenantID" della risposta.
Eliminazione
subtenant
ELIMINARE url Http: /rest/subtenants/{subtenantID}
Intestazioni richieste: x-emc-uid (ad esempio, x-emcuid=wuser1@SANITY.LOCAL ) x-emc-signature
Funzionalità
Note
PUT Object (gammaaggiunta)
Utilizza l'intestazione Range per specificare la gamma di object
aggiunta.
a un object.
Il formato è: Range: bytes=-1Una richiesta di esempio che mostra l'aggiunta a un object esistente mediante un valore
PUT /rest/namespace/myObject HTTP/1.1
Content-Length: 8
Date: Mon, 17 Jun 2013 20:46:01 -0000
x-emc-date: Mon, 17 Jun 2013 20:46:01 -0000
x-emc-uid: fa4e31a68d3e4929bec2f964d4cac3de/wuser1@sanity.local
x-emc-signature: ZpW9KjRb5+YFdSzZjwufZUqkExc=
and cat
251
HTTP/1.1 200 OK
x-emc-mtime: 1431626712933
Date: Mon, 17 Jun 2013 20:46:01 GMT
x-emc-policy: default
x-emc-utf8: true
x-emc-request-id: 0af9ed8d:14cc314a9bc:112f6:9
x-emc-delta: 8
x-emc-append-offset: 24
Content-Length: 0
La posizione di offset in cui sono stati aggiunti i dati viene restituita nell'intestazione xemc-append-offset.
a questo object.
252
PARTE 9
Capitolo 29, "Utilizzo di ECS Management REST API"
253
254
CAPITOLO 29
l
l
l
Introduzione....................................................................................................... 256
Autenticazione con ECS Management REST API................................................... 256
ECS Management REST API summary...................................................................259
255
Introduzione
In questo articolo viene descritto come accedere a ECS Management REST API ed
eseguire l'autenticazione. Viene inoltre fornito un riepilogo dei percorsi API. ECS
Management REST API consente di configurare e gestire l'object store. Una volta
configurato l'object store, le successive operazioni di creazione, lettura, aggiornamento
ed eliminazione dell'object vengono eseguite utilizzando protocolli di object S3, EMC
Atmos o OpenStack Swift supportati.
È possibile fare riferimento al seguente argomento per conoscere le modalità di accesso
all'API REST e le procedure di autenticazione:
l
Autenticazione con ECS Management REST API a pagina 256
e i percorsi API vengono riepilogati in:
l
ECS Management REST API summary a pagina 259
Inoltre, viene fornito un riferimento alle API in:
l
ECS Management REST API Reference
ECS Management REST API Reference viene generato automaticamente dal codice
sorgente e fornisce un riferimento per i metodi disponibili nell'API.
Autenticazione con ECS Management REST API
ECS utilizza un sistema di autenticazione basata su token per tutte le chiamate API REST.
Sono disponibili esempi per l'autenticazione con ECS REST API, con e senza cookie.
Dopo che l'utente avrà eseguito l'autenticazione a fronte di ECS, verrà restituito un token
da utilizzare per autenticare l'utente nelle chiamate successive.
l
Se il client segue automaticamente reindirizzamenti, viene restituito un codice HTTP
401 a indicare che è necessario effettuare il login e l'autenticazione per ottenere un
nuovo token.
l
Se il client non segue automaticamente reindirizzamenti, viene restituito un codice
HTTP 302. Il codice 302 reindirizza il client nel punto in cui ripetere l'autenticazione.
Per eseguire il retrieval e utilizzare token di autenticazione, è possibile effettuare varie
operazioni.
l
Salvare il cookie X-SDS-AUTH-TOKEN da una richiesta di autenticazione riuscita e
inviarlo nelle richieste successive.
l
Leggere l'intestazione HTTP X-SDS-AUTH-TOKEN da una richiesta di autenticazione
riuscita e copiarla in eventuali richieste successive.
L'API REST è disponibile nella porta :4443 e i client accedono a ECS emettendo una
richiesta di login nel formato:
https://<ECS_IP>:4443/login
Il documento ECS Management REST API Reference fornisce una descrizione e un elenco
completo dei parametri per i metodi dell'API REST utilizzati in questo articolo.
Autenticazione con AUTH-TOKEN
In questo esempio viene illustrato come utilizzare token di autenticazione leggendo
l'intestazione http X-SDS-AUTH-TOKEN da una richiesta di autenticazione riuscita e
256
copiandola in una richiesta successiva. In questi esempi non vengono utilizzati cookie.
Gli esempi qui presenti sono scritti in curl e formattati per agevolare la leggibilità.
Questo comando esegue una richiesta GET nella risorsa /login. L'opzione -u indica
l'utente di un'intestazione di autenticazione di base. Nella richiesta è necessario
includere la designazione dell'utente. In caso di autenticazione riuscita, vengono
restituiti il codice HTTP 200 e l'intestazione X-SDS-AUTH-TOKEN contenente il token
codificato.
curl -L --location-trusted -k https://10.247.100.247:4443/login -u
"root:ChangeMe" -v
> GET /login HTTP/1.1
> Authorization: Basic cm9vdDpDaGFuZ2VNZQ==
> User-Agent: curl/7.24.0 (i386-pc-win32) libcurl/7.24.0 OpenSSL/
0.9.8t zlib/1.2.5
> Host: 10.247.100.247:4443
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 26 Nov 2013 22:18:25 GMT
< Content-Type: application/xml
< Content-Length: 93
< Connection: keep-alive
< X-SDS-AUTH-TOKEN:
BAAcQ0xOd3g0MjRCUG4zT3NJdnNuMlAvQTFYblNrPQMAUAQADTEzODU0OTQ4NzYzNTICAA
EABQA5dXJu
OnN0b3JhZ2VvczpUb2tlbjo2MjIxOTcyZS01NGUyLTRmNWQtYWZjOC1kMGE3ZDJmZDU3Mm
U6AgAC0A8=
<
<loggedIn>
<user>root</user>
</loggedIn>
* Connection #0 to host 10.247.100.247 left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Il token potrà quindi essere passato nuovamente nella chiamata API successiva. È
possibile copiare i contenuti di X-SDS-AUTH-TOKEN e passarli alla richiesta successiva
mediante lo switch -H di curl.
curl https://10.247.100.247:4443/object/namespaces
-k
-H "X-SDS-AUTH-TOKEN:
BAAcOHZLaGF4MTl3eFhpY0czZ0tWUGhJV2xreUE4PQMAUAQADTEzODU0OTQ4NzYzNTICAA
EABQA5dXJu
OnN0b3JhZ2VvczpUb2tlbjpkYzc3ODU3Mi04NWRmLTQ2YjMtYjgwZi05YTdlNDFkY2QwZD
g6AgAC0A8="
<namespaces>
<namespace>
<id>ns1</id>
<link rel="self" href="/object/namespaces/namespace/ns1"/>
<names>ns1</name>
</namespace>
</namespaces>
Autenticazione con cookie
In questo esempio viene illustrato come utilizzare token di autenticazione salvando il
cookie da una richiesta di autenticazione riuscita e quindi passandolo in una richiesta
Autenticazione con cookie
257
successiva. Gli esempi qui presenti sono scritti in curl e formattati per agevolare la
leggibilità.
In questo esempio viene specificato il parametro ?using-cookies=true per indicare che si
desidera ricevere cookie insieme alla normale intestazione HTTP. Questo comando curl
salva il token di autenticazione in un file denominato cookiefile nella directory
corrente.
curl -L --location-trusted -k https://<ECS_IP>:4443/login?usingcookies=true
-u "root:Password"
-c cookiefile
-v
Il comando successivo passa il cookie con il token di autenticazione tramite lo switch -b
e restituisce le informazioni sul tenant dell'utente.
curl -k https://10.247.100.247:4443/object/namespaces -b cookiefile v
<namespaces>
<namespace>
<id>ns1</id>
<link rel="self" href="/object/namespaces/namespace/ns1"/>
<names>ns1</name>
</namespace>
</namespaces>
Logout
L'API di logout termina una sessione.
A un determinato utente è consentito un massimo di 100 token di autenticazione
simultanei. Superato questo limite, il sistema rifiuterà nuove connessioni per questo
utente finché non verranno liberati token. I token possono essere liberati naturalmente,
alla scadenza, oppure in modo esplicito, chiamando l'URI:
https://<ECS_IP>:4443/logout
In caso di più sessioni in esecuzione contemporaneamente, l'URI forza la chiusura di tutti
i token relativi all'utente corrente.
GET https://<ECS_IP>:4443/logout?force=true
Di seguito è riportato un esempio di richiesta di logout.
Request
GET https://<ECS_IP>:4443/logout
X-SDS-AUTH-TOKEN:{Auth_Token}
Passare l'intestazione o il cookie con il token di autenticazione per il logout.
Risposta
HTTP 200
258
Whoami
Un utente ECS può visualizzare il proprio nome utente, l'associazione al tenant e i ruoli
mediante la chiamata API whoami.
Request
GET https://<ECS_IP>:4443/user/whoami
Risposta
HTTP 200
GET /user/whoami
<user>
<common_name>root</common_name>
<namespace/>
<roles>
<role>SYSTEM_ADMIN</role>
</roles>
</user>
HTTP 200
GET /user/whoami
<user>
<common_name>fred@corp.sean.com</common_name>
<namespace>ns1</namespace>
<roles>
<role>NAMESPACE_ADMIN</role>
</roles>
</user>
In questo esempio viene illustrato l'output di whoami per l'utente root e per un utente
assegnato al ruolo NAMESPACE_ADMIN per il namespace "ns1".
ECS Management REST API summary
ECS Management REST API consente di configurare e gestire l'object store ECS.
È inoltre possibile utilizzare altri servizi ECS per supportare l'utilizzo dell'object storage
ECS.
Nella tabella riportata di seguito viene fornito un riepilogo di ECS Management REST API.
Tabella 51 ECS Management REST API- Riepilogo dei metodi
Area API
Descrizione
Provider di
autenticazione
/vdc/admin/authproviders
Fatturazione
/object/billing
API per consentire l'aggiunta e la gestione di provider di autenticazione.
API per consentire la misurazione dell'utilizzo degli object store a livello
di tenant e bucket. Per ulteriori informazioni, vedere Gestione di un
tenant a pagina 84.
URL di base
/object/baseurl
Whoami
259
Tabella 51 ECS Management REST API- Riepilogo dei metodi (continua)
Area API
Descrizione
API per consentire la creazione di un URL di base che permette alle
applicazioni esistenti di utilizzare l'object store ECS. Maggiori
informazioni sull'URL di base sono reperibili in: .
Bucket
/object/bucket
API per il provisioning e la gestione dei bucket.
/object/bucket/{bucketName}/lock
API per consentire il blocco dell'accesso ai bucket. Per ulteriori
informazioni, vedere Gestione di un tenant a pagina 84.
Call Home
/vdc/callhome/
API per consentire la configurazione di ConnectEMC e la creazione di
eventi di alert per ConnectEMC.
Capacità
/object/capacity
API per il retrieval della capacità gestita corrente.
CAS
/object/user-cas
API per consentire l'assegnazione di chiavi segrete agli utenti CAS e la
generazione del file PEA (Pool Entry Authorization).
Certificate
/object-cert
API per la gestione di certificati.
/object-cert/keystore
API per consentire la definizione della catena di certificati utilizzata da
EMC e la rotazione del certificato.
Proprietà di
configurazione
/config/object/properties
API per consentire l'impostazione dell'ambito utente come GLOBAL o
NAMESPACE.
Nell'ambito GLOBAL gli utenti sono globali e possono essere condivisi
tra namespace. In questo caso, il namespace predefinito associato a un
utente determina il namespace per le operazioni sugli object e non è
necessario fornirne uno per un'operazione. Se l'ambito utente è
NAMESPACE, un utente viene associato a un namespace, pertanto
possono coesistere più utenti con lo stesso nome, ciascuno associato a
un namespace diverso. In modalità NAMESPACE è necessario fornire un
namespace per ogni operazione.
Deve essere impostato precedentemente alla creazione del primo
utente. L'impostazione predefinita è GLOBAL.
Data Store
/vdc/data-stores
API per consentire la creazione di datastore su file system (/vdc/
data-stores/filesystems) o nodi commodity (/vdc/datastores/commodity).
260
Area API
Descrizione
Licenze
/license
API per consentire l'aggiunta di una licenza e il retrieval dei relativi
dettagli.
Monitoring
(Dashboard)
/dashboard
Monitoring (Events)
/vdc/events
API per il retrieval delle informazioni di sistema da visualizzare in un
dashboard.
API per il recupero di audit alert.
Namespace
/object/namespaces
API per consentire la creazione e la gestione di un namespace.
Permette inoltre di impostare un periodo di conservazione per il
namespace. Per ulteriori informazioni, vedere Gestione di un tenant a
pagina 84.
Node
/vdc/nodes
API per il retrieval dei nodi attualmente configurati per il cluster.
Password Group
(Swift)
/object/user-password
Replication Group
/data/data-service/vpools
API per consentire la generazione di una password da utilizzare insieme
all'autenticazione OpenStack Swift.
API per consentire la creazione e l'amministrazione di gruppi di replica.
Chiave segreta
/object/user-secret-keys
API per consentire l'assegnazione di chiavi segrete a utenti di object e la
relativa gestione.
Secret Key Self-Service /object/secret-keys
API per consentire agli utenti S3 di creare una nuova chiave segreta che
conferisca loro l'accesso a object e bucket nel relativo namespace
all'interno dell'object store.
Storage pool
/vdc/data-services/varrays
API per consentire la creazione e la gestione di storage pool.
Temporary Failed Zone /tempfailedzone/
API per consentire il retrieval di tutte le zone con guasti temporanei o di
quelle di uno specifico gruppo di replica.
User (Object)
/object/users
API per la creazione e la gestione di utenti di object. Gli utenti di object
sono sempre associati a un namespace. L'API restituisce una chiave
segreta utilizzabile per l'accesso a S3. Un utente di object può
modificare una chiave segreta S3 a lui assegnata tramite l'API REST.
ECS Management REST API summary
261
Area API
Descrizione
/object/users/lock.
Consente il blocco dell'accesso degli utenti.
User (Management)
/vdc/users
API per la creazione e l'amministrazione di utenti di gestione. Gli utenti
di gestione possono essere assegnati al ruolo di System Admin o
Namespace Admin. È possibile modificare la password di un utente di
gestione locale.
Data center virtuale
/object/vdcs
Consente l'aggiunta di un VDC e la definizione della chiave segreta e
degli endpoint associati nei relativi VDC per la replica dei dati tra siti
ECS.
262
PARTE 10
Capitolo 30, "Hardware ECS"
Capitolo 31, "Sostituzione di un disco di storage ECS in un appliance U-Series"
Capitolo 32, "Sostituzione di un disco di storage ECS in hardware di terze parti"
Capitolo 33, "Aggiunta di un aggiornamento di 60 dischi a un appliance ECS U-Series"
Capitolo 34, "Requisiti di rack di terze parti ECS"
263
264
CAPITOLO 30
Hardware ECS
l
l
l
l
l
l
l
l
l
l
l
Componenti hardware dell'appliance ECS........................................................... 266
Configurazioni e percorsi di aggiornamento degli appliance ECS......................... 269
Cablaggio di alimentazione CA monofase per appliance U-Series ....................... 271
Cablaggio di alimentazione CA trifase per appliance U-Series..............................273
Switch.................................................................................................................277
Cablaggio di reti.................................................................................................. 279
Nodi....................................................................................................................280
Nomi host di rack e nodi......................................................................................284
Unità disco..........................................................................................................285
Unità disco integrate........................................................................................... 285
Dischi ed enclosure.............................................................................................286
Hardware ECS
265
Hardware ECS
Componenti hardware dell'appliance ECS
Vengono descritti i componenti hardware dei modelli dell'appliance ECS.
Serie di appliance ECS
L'appliance ECS include due serie.
l
U-Series: storage server non strutturati con DAE separati progettati per ottimizzare la
capacità di storage.
l
C-Series: server di calcolo ad alta densità con dischi integrati progettati per
ottimizzare la capacità di calcolo.
U-Series
L'appliance ECS U-Series include i seguenti componenti hardware.
Tabella 52 ECS Appliance: Componenti hardware U-Series
266
Componente
Descrizione
Rack 40U
Rack EMC Titan D che includono:
l
PDU monofase con quattro cali di potenza (due per lato)
l
PDU delta o WYE trifase facoltativi con due cali di potenza
(uno per lato)
l
Sportelli frontale e posteriore
l
Disposizione in rack fornita dalla produzione EMC
Switch privato
Uno switch da 1 GbE
Switch pubblico
Due switch da 10 GbE
Nodi
Server non strutturato basato su Intel in configurazioni da 4 e 8
nodi
Disk Array Enclosure (DAE)
Cassetti Disk Array Enclosure (DAE) in grado di contenere fino a
60 unità disco da 3,5" e 6 TB
Hardware ECS
Figura 50 Configurazione minima e massima di appliance ECS U-Series
C-Series
L'appliance ECS C-Series include i seguenti componenti hardware.
Tabella 53 ECS Appliance: Componenti hardware C-Series
Componente
Descrizione
Rack 40U
Rack di calcolo EMC Titan D che includono:
l
Quattro cali di tensione orizzontali
l
Due PDU monofase in una configurazione 2U con due cali di
tensione
l
Due PDU WYE o delta trifase facoltative in una
configurazione 2U con due cali di tensione
l
Sportelli frontale e posteriore
l
Disposizione in rack fornita dalla produzione EMC
Componenti hardware dell'appliance ECS
267
Hardware ECS
Tabella 53 ECS Appliance: Componenti hardware C-Series (continua)
Componente
Descrizione
Switch privato
Uno o due switch da 1 GbE Il secondo switch è richiesto per le
configurazioni con più di sei server
Switch pubblico
Due o quattro switch da 10 GbE. Il terzo e il quarto switch sono
richiesti per le configurazioni con più di sei server
Nodi
Server non strutturati basati su Intel in configurazioni da 8 a 48
nodi
Dischi
12 unità disco da 3,5" e 6 TB integrate in ciascun server
Figura 51 Configurazione minima e massima di appliance ECS C-Series
I clienti si collegano all'appliance ECS tramite le porte da 10 GbE e i cavi di
interconnessione personali. Quando sono installati più appliance nello stesso data
center, gli switch privati si possono collegare tramite cablaggi daisy chain oppure home
run allo switch fornito dal cliente.
268
Hardware ECS
Configurazioni e percorsi di aggiornamento degli appliance ECS
Vengono descritti le configurazioni degli appliance ECS disponibili e i percorsi di
aggiornamento tra le configurazioni.
Configurazioni U-Series
L'appliance ECS U-Series è una soluzione di storage densa che impiega hardware
disponibile in commercio.
Tabella 54 Configurazioni U-Series
Numero
modello
Nodi
DAE
Dischi in DAE da 1 Dischi in DAE da 5 Capacità di Switch
a4
a8
storage
U300
4
(configurazi
one minima)
4
15
N/A
360 TB
Uno privato
e due
pubblici
U700
4
4
30
N/A
720 TB
Uno privato
e due
pubblici
U1100
4
4
45
N/A
1080 TB
Uno privato
e due
pubblici
U1500
4
4
60
N/A
1440 TB
Uno privato
e due
pubblici
U1800
8
8
60
15
1800 TB
Uno privato
e due
pubblici
U2100
8
8
60
30
2160 TB
Uno privato
e due
pubblici
U2500
8
8
60
45
2520 TB
Uno privato
e due
pubblici
U3000
(configurazi
one
massima)
8
8
60
60
2880 TB
Uno privato
e due
pubblici
Percorsi di aggiornamento U-Series
Gli aggiornamenti U-Series sono costituiti dai dischi e dall'hardware di infrastruttura
necessari per il passaggio dal numero del modello esistente al successivo numero
superiore. Per eseguire l'aggiornamento per più di un livello di modello, ordinare gli
aggiornamenti per ciascun livello e applicarli in una chiamata di assistenza.
Configurazioni e percorsi di aggiornamento degli appliance ECS
269
Hardware ECS
Tabella 55 Aggiornamenti U-Series
Numero modello
Aggiornamento del disco (dal
successivo modello inferiore)
Aggiornamento hardware
(dal successivo modello
inferiore)
U300 (configurazione
minima)
N/A
N/A
U700
Un kit da 60 dischi
N/A
U1100
Un kit da 60 dischi
N/A
U1500
Un kit da 60 dischi
N/A
U1800
Un kit da 60 dischi
Un server chassis (quattro
nodi) e quattro DAE
U2100
Un kit da 60 dischi
N/A
U2500
Un kit da 60 dischi
N/A
U3000 (configurazione
massima)
Un kit da 60 dischi
N/A
Configurazioni C-Series
L'appliance ECS C-Series è una soluzione di calcolo densa che impiega hardware
disponibile in commercio.
Tabella 56 Configurazioni C-Series
270
Server di calcolo
Phoenix-12
Nodi
Capacità di
storage
Switch
2 (configurazione
minima)
8
144 TB
Uno privato e due
pubblici
3
12
216 TB
Uno privato e due
pubblici
4
16
288 TB
Uno privato e due
pubblici
5
20
360 TB
Uno privato e due
pubblici
6
24
432 TB
Uno privato e due
pubblici
7
28
504 TB
Due privati e
quattro pubblici
8
32
576 TB
Due privati e
quattro pubblici
9
36
648 TB
Due privati e
quattro pubblici
10
40
720 TB
Due privati e
quattro pubblici
Hardware ECS
Tabella 56 Configurazioni C-Series (continua)
Server di calcolo
Phoenix-12
Nodi
Capacità di
storage
Switch
11
44
792 TB
Due privati e
quattro pubblici
12 (configurazione
massima)
48
864 TB
Due privati e
quattro pubblici
Percorsi di aggiornamento C-Series
Gli aggiornamenti C-Series sono costituiti dai dischi e dall'hardware di infrastruttura
necessari per il passaggio dal numero del modello esistente al successivo numero
superiore. Per eseguire l'aggiornamento per più di un livello di modello, ordinare gli
aggiornamenti per ciascun livello e applicarli in una chiamata di assistenza.
Tabella 57 Aggiornamenti C-Series
Numero modello
Aggiornamento del disco Aggiornamento hardware (dal
(dal successivo modello successivo modello inferiore)
inferiore)
2 server di calcolo Phoenix-12
(configurazione minima)
N/A
N/A
12 dischi integrati
Un server chassis (quattro nodi)
12 dischi integrati
12 dischi integrati
12 dischi integrati
12 dischi integrati
Un server chassis (quattro nodi),
uno switch privato e due switch
pubblici
12 dischi integrati
12 dischi integrati
10 server di calcolo Phoenix-12 12 dischi integrati
(configurazione massima)
Cablaggio di alimentazione CA monofase per appliance U-Series
Vengono forniti diagrammi di cablaggio dell'alimentazione monofase per l'appliance ECS
U-Series.
Per ciascuna configurazione, gli switch vengono collegati alla parte anteriore del rack e
instradati alla parte posteriore tramite le guide.
Cablaggio di alimentazione CA monofase per appliance U-Series
271
Hardware ECS
Figura 52 Cablaggio di alimentazione CA monofase per appliance U-Series - Configurazioni da
quattro nodi
272
Hardware ECS
Figura 53 Cablaggio di alimentazione CA monofase per appliance U-Series - Configurazioni da otto
nodi
Cablaggio di alimentazione CA trifase per appliance U-Series
Vengono forniti diagrammi di cablaggio dell'alimentazione CA trifase.
Cablaggio di alimentazione CA delta trifase per appliance U-Series
Nella legenda riportata di seguito, i cavi colorati illustrati nel diagramma vengono
associati ai Part Number EMC e alle lunghezze dei cavi.
273
Hardware ECS
Figura 54 Legenda dei cavi per il diagramma dell'alimentazione CA delta trifase
274
Hardware ECS
Figura 55 Cablaggio dell'alimentazione CA delta trifase - Configurazione da otto nodi
275
Hardware ECS
Cablaggio dell'alimentazione CA WYE trifase
Nella legenda riportata di seguito, i cavi colorati illustrati nel diagramma vengono
associati ai Part Number EMC e alle lunghezze dei cavi.
Figura 56 Legenda dei cavi per il diagramma dell'alimentazione CA WYE trifase
276
Hardware ECS
Figura 57 Cablaggio dell'alimentazione CA WYE trifase - Configurazione da otto nodi
Switch
Gli appliance ECS includono tre switch.
l
Switch privato: uno switch privato da 1 GbE per il traffico di gestione. In un rack CSeries con oltre sei server di calcolo viene aggiunto un secondo switch privato.
l
Switch pubblico: due switch 10 GbE per gestire il traffico di dati. Due modelli Arista
sono idonei all'uso. In un rack C-Series con oltre sei server di calcolo vengono
aggiunti due switch pubblici.
Switch
277
Hardware ECS
Switch privato: Arista 7048
Lo switch privato viene utilizzato per il traffico di gestione. È dotato di 48 porte e input di
alimentatori doppi. Lo switch è configurato in fabbrica.
Figura 58 Configurazione di Arista 7048
1. Porte1-24 - Gestione
2. Porte 25-48 - RMM/IPMI
3. Porte 49-50 - Gestione, connessioni agli switch pubblici da 10 GbE
4. Porta 51 - Connettività NAN Nel primo rack questa porta consente l'uplink alla rete
del cliente se è necessario l'accesso alle porte RMM.
5. Porta 52 - Connettività NAN La porta 52 del primo rack consente la connessione alla
porta 51 del rack successivo e così via per tutti i rack nel sito ECS.
Nota
La connettività NAN (Nile Area Network) collega tutti gli appliance ECS in un sito.
Switch pubblico: Arista 7150S-24
Lo switch 7150S-24 è uno switch a 24 porte. Lo switch è dotato di 24 porte SFP+,
alimentatori doppi hot swap e moduli di ventole ridondanti, sostituibili sul campo.
Figura 59 Arista 7150S-24
1. Porte 1-8: uplink alla rete del cliente
2. Porte 9-12: connessione ai nodi come porte dati
278
Hardware ECS
3. Porte 13-20: connessione ai nodi come porte dati
4. Porte 21-22: interconnessione per interfacce MLAG tra switch pubblici
5. Porte 23-24: interconnessione per interfacce MLAG tra switch pubblici
6. 1 interfaccia di rete per la gestione degli switch
7. Console seriale: la porta della console viene utilizzata per gestire lo switch tramite
una connessione seriale e la porta di gestione Ethernet è collegata allo switch di
gestione da 1 GbE
Switch pubblico: Arista 7124SX
Lo switch Arista 7124SX è dotato di 24 porte SFP+, alimentatori doppi hot swap e moduli
di ventole ridondanti, sostituibili sul campo.
Figura 60 Arista 7124SX
1. Porte 1-8 - Porte dati per l'uplink alla rete del cliente. Queste porte forniscono la
connessione all'infrastruttura 10GbE dell'utente.
2. Porte 9-20 - Connesse ai nodi come porte dati
3. Porte 21-22 - Interconnessione HA per interfacce MLAG tra switch pubblici
4. Porte 23-24 - Interconnessione HA per interfacce MLAG tra switch pubblici
5. 1 interfaccia di rete per la gestione degli switch
6. Console seriale
Cablaggio di reti
Presenta i diagrammi di cablaggio delle reti per gli switch pubblici e privati in un
appliance ECS.
I diagrammi di cablaggio delle reti si applicano agli appliance ECS U-Series e C-Series.
Per effettuare una distinzione tra i tre switch nella documentazione, ogni switch presenta
un nome alternativo:
l
Hare: switch pubblico da 10 GbE situato in cima al rack.
l
Rabbit: secondo switch pubblico da 10 GbE situato al di sotto dell'hare switch.
l
Turtle: switch privato da 1 GbE situato al di sotto del rabbit switch.
Switch pubblico: Arista 7124SX
279
Hardware ECS
Figura 61 Cablaggio di switch pubblici per quattro nodi
Figura 62 Cablaggio di switch privati per quattro nodi
Nodi
ECS Appliance include due tipi di nodi:
l
U-Series Phoenix-16 for Object and HDFS (giugno 2014)
l
C-Series Phoenix-12 for Object and HDFS (dicembre 2014)
I nodi U-Series devono disporre delle funzionalità standard indicate di seguito.
280
Hardware ECS
l
Server a quattro nodi (2U) con due CPU per nodo
l
CPU Ivy Bridge a quattro core da 2,4 GHz
l
Quattro canali con memoria DDR3 nativa (1333)
l
Uno o due dischi di sistema per nodo
l
Indicatori LED per ogni nodo
l
Alimentatori doppi hot swap dello chassis
l
Due interfacce SAS per nodo
I nodi C-Series devono disporre delle funzionalità standard indicate di seguito.
l
Server a quattro nodi (2U) con due CPU per nodo
l
CPU Ivy Bridge a quattro core da 2,4 GHz
l
Quattro canali con memoria DDR3 nativa (1333)
l
Un disco di sistema per nodo
l
Indicatori LED per ogni nodo
l
Alimentatori doppi hot swap dello chassis; supporto per alimentatori N + 1
l
Una interfaccia SAS per nodo
l
12 dischi rigidi SAS hot swap da 3,5” per server (tre per ogni nodo)
Viste anteriori del server
Figura 63 Vista anteriore dello chassis U-Series
Figura 64 Vista anteriore dello chassis C-Series
Gli indicatori LED si trovano sui lati sinistro e destro dei pannelli anteriori del server.
Viste anteriori del server
281
Hardware ECS
Figura 65 LED (lato sinistro)
Tabella 58 LED del server
LED
Utilizzo
Descrizione
A
Tasto di accensione del
sistema con LED
B
Pulsante LED dell'ID del
sistema
Identifica il server tra i diversi server
disponibili. Spento per impostazione
predefinita e blu quando è attivato dal pulsante
o dal software.
C
LED dello stato del sistema
Mostra lo stato complessivo del sistema (verde,
verde lampeggiante, ambra lampeggiante,
ambra, spento).
D
LED di attività/link di rete
Vista posteriore del server
I server chassis Phoenix-16 (U-Series) e Phoenix-12 (C-Series) forniscono entrambi doppi
alimentatori hot swap e quattro nodi. Lo chassis condivide un alimentatore ridondante
comune che abilita l'alimentazione HA in ciascun chassis condiviso in tutti i nodi. I nodi
vengono montati su vassoi sostituibili a caldo che si adattano nei quattro slot dei nodi
corrispondenti, accessibili dalla parte posteriore del server.
282
Hardware ECS
Figura 66 Vista posteriore dei server chassis Phoenix-12 e Phoenix-16
1. Nodo 1
2. Nodo 2
3. Nodo 3
4. Nodo 4
Figura 67 Porte posteriori sui nodi Phoenix-12 e Phoenix-16
1. 1 GbE: collegata a una delle porte dati dello switch da 1 GbE.
2. RMM: porta dedicata per il monitoraggio dell'hardware (per nodo).
3. SAS per DAE (solo su Phoenix-16)
4. 10 GbE (primaria): la porta dati destra da 10 GbE di ciascun nodo è collegata a una
delle porte dati primarie dello switch da 10 GbE.
5. 10 GbE (secondaria): la porta dati sinistra da 10 GbE di ciascun nodo è collegata a
una delle porte dati secondarie dello switch da 10 GbE.
Vista posteriore del server
283
Hardware ECS
Nomi host di rack e nodi
Vengono elencati i nomi host predefiniti di rack e nodi per un appliance ECS.
Nomi di colori e ID di rack predefiniti vengono assegnati in ordine di installazione come
illustrato di seguito.
Tabella 59 ID di rack da 1 a 50
ID rack
Colore rack
ID rack
Colore rack
ID rack
Colore rack
1
rosso
18
carminio
35
seta di mais
2
verde
19
castano
ramato
36
ocra
3
blu
20
bronzo
37
lavanda
4
giallo
21
albicocca
38
rossastro
5
magenta
22
gelsomino
39
avorio
6
ciano
23
verde
militare
40
corniola
7
azzurro
24
rame
41
grigio talpa
8
viola
25
amaranto
42
blu scuro
9
rosa chiaro
26
menta
43
blu indaco
10
arancione
27
cobalto
44
veronica
11
chartreuse
28
felce
45
giallo limone
12
rosa
29
terra di Siena 46
sabbia
13
marrone
30
mantide
47
ruggine
14
bianco
31
jeans
48
mattone
15
grigio
32
acqua
marina
49
avocado
16
beige
33
neonato
50
chewing gum
17
grigio chiaro
34
melanzana
Ai nodi vengono assegnati nomi host in base all'ordine nel server chassis e nel rack
stesso. Nella tabella indicata di seguito vengono elencati i nomi host predefiniti.
Tabella 60 Nomi host predefiniti
284
Nod Host name
e
Node
Host name
Node
Host name
1
provo
17
memphis
33
tampa
2
sandy
18
seattle
34
toledo
3
orem
19
denver
35
aurora
4
ogden
20
portland
36
stockton
Hardware ECS
Tabella 60 Nomi host predefiniti (continua)
Nod Host name
e
Node
Host name
Node
Host name
5
layton
21
tucson
37
buffalo
6
logan
22
atlanta
38
newark
7
Lehi
23
fresno
39
glendale
8
murray
24
mesa
40
lincoln
9
boston
25
omaha
41
norfolk
10
chicago
26
oakland
42
chandler
11
houston
27
miami
43
madison
12
phoenix
28
tulsa
44
orlando
13
dallas
29
honolulu
45
garland
14
detroit
30
wichita
46
akron
15
columbus
31
raleigh
47
reno
16
austin
32
anaheim
48
laredo
I nodi posizionati nello stesso slot in rack diversi in un sito avranno lo stesso nome host.
Ad esempio, il nodo 4 sarà sempre denominato ogden, supponendo che si usino i nomi
di nodi predefiniti.
Gli output di sistema identificheranno nodi in base a una combinazione univoca di nome
host del nodo e nome del rack. Ad esempio, il nodo 4 nel rack 4 e il nodo 4 nel rack 5
verranno identificati come segue:
ogden-green
ogden-blue
Unità disco
Vengono descritte le unità disco utilizzate in appliance ECS.
Le appliance ECS utilizzano le seguenti unità disco per lo storage:
Tabella 61 Unità disco di storage
Service
Dim.
rpm
Tipo
Oggetto
6 TB
7200
SATA
Tutti i dischi in un DAE o integrati in un server chassis sono conformi alle seguenti regole:
l
Tutte le unità disco devono avere le stesse dimensioni
l
Tutte le unità disco devono avere la stessa velocità
Unità disco integrate
Vengono descritti i dischi di storage integrati nel server chassis.
Unità disco
285
Hardware ECS
Nei server con dischi integrati i dischi sono accessibili dal lato anteriore dello chassis. I
dischi vengono assegnati in parti uguali ai quattro nodi dello chassis.
Nota
La prima unità disco assegnata a ciascun nodo è chiamata unità disco zero (HDD0).
Queste unità di storage conterranno alcuni dati di sistema. Per questo motivo, l'unità
disco zero non può essere sostituita senza prima contattare EMC Customer Support.
Figura 68 Dischi integrati con mapping di nodi
Dischi ed enclosure
La linea U-Series fornisce Disk Array Enclosure (DAE). Il DAE è un cassetto che scorre
all'interno e all'esterno del rack compatto 40U. Le unità disco, la scheda LCC e i moduli di
raffreddamento per il DAE sono situati all'interno del DAE. Il DAE è caratterizzato dalle
funzionalità indicate di seguito.
l
15, 30, 45 o 60 unità disco da 3,5" in un unico cassetto 4U. Revisione dalla parte
anteriore.
l
Una scheda LCC (Link Control Card). Revisione dalla parte anteriore.
l
Un modulo ICM (Inter Connect Module). Revisione dalla parte posteriore.
l
Tre ventole o moduli di raffreddamento; ridondanza n+1. Revisione dalla parte
anteriore.
l
Due alimentatori, ridondanza n+1. Revisione dalla parte posteriore.
I server C-Series includono dischi integrati: 12 unità disco da 3,5" accessibili dalla parte
anteriore del server.
Unità disco in DAE
Le unità disco sono racchiuse in enclosure stile cartuccia. Ogni cartuccia ha un gancio
che consente di rimuovere e installare facilmente l'unità disco.
All'interno di ciascun DAE sono presenti etichette stampate fisicamente sui lati sinistro e
anteriore che descrivono le righe (o i banchi) e le colonne (o gli slot) in cui vengono
installate le unità disco nel DAE.
I banchi sono etichettati da A a E, mentre gli slot sono etichettati da 0 a 11. Quando si
descrive il layout delle unità disco all'interno del DAE, il formato dell'interfaccia per il DAE
è denominato E_D, dove E indica l'enclosure e D il disco. Ad esempio, un formato di
interfaccia 1_B11 deve essere interpretato nel modo seguente: enclosure 1, nella riga
(banco) B, nel numero di slot 11.
Le enclosure sono numerate da 1 a 8 partendo dalla parte inferiore del rack. I
collegamenti dei cavi posteriori sono contrassegnati da colori specifici.
La disposizione dei dischi in un DAE deve riflettere i layout prescritti illustrati nelle figure
di seguito.
286
Hardware ECS
Guardando il DAE dalla parte antero-superiore, la figura riportata di seguito illustra il
layout delle unità disco del DAE.
Figura 69 Layout di dischi U-Series per configurazioni a 15 dischi
Unità disco in DAE
287
Hardware ECS
288
Hardware ECS
Unità disco in DAE
289
Hardware ECS
LCC
Ogni DAE include una scheda LCC sostituibile a caldo la cui funzione principale è quella
di fungere da espansore SAS e fornire servizi di enclosure. Ogni LCC monitora in modo
indipendente lo stato ambientale dell'intero enclosure e comunica lo stato al sistema. La
scheda LCC dispone di un LED per la segnalazione di guasti e un LED di alimentazione.
Tabella 62 LED dello stato della scheda LCC del DAE
LED
Colore Stato
Alimentazione
Verde
Acceso Alimentazione attivata
—
Spento Alimentazione disattivata
Interruzione di alimentazione Ambra
—
290
Descrizione
Acceso Guasto
Spento Nessun guasto o alimentazione disattivata
Hardware ECS
Figura 73 LCC con LED
Modulo di controllo della ventola
Ogni DAE include tre moduli di controllo della ventola (moduli di raffreddamento) situati
nella parte anteriore del DAE. Il modulo di controllo della ventola aumenta la capacità di
raffreddamento di ogni DAE. Si inserisce direttamente nel battiscopa del DAE a partire
dall'alto del Disk Array Enclosure. Nel modulo di controllo della ventola, i sensori
misurano le temperature ambiente esterne per garantire un raffreddamento uniforme del
DAE.
Tabella 63 LED di guasto della ventola del modulo di controllo della ventola
LED
Colore
Stato
Descrizione
Guasto ventola ambra - Acceso Guasto riscontrato. Una o più ventole sono guaste.
Spento Nessun guasto riscontrato. Le ventole funzionano
normalmente.
Figura 74 Modulo di controllo della ventola con LED
Modulo di controllo della ventola
291
Hardware ECS
ICM
Il modulo ICM è l'elemento di gestione di interconnessione principale. È un modulo plugin che include un connettore USB, una scheda di gestione RJ-12, un indicatore ID del bus,
un indicatore ID dell'enclosure, due connettori SAS di input e due connettori SAS di
output con i LED corrispondenti che indicano il link e l'attività di ciascun connettore SAS
per l'input e l'output dei dispositivi.
Tabella 64 LED di stato del bus ICM
LED
Colore Stato
Interruzione di alimentazione Verde
Alimentazione attivata
Descrizione
Acceso Alimentazione attivata
—
Spento Alimentazione disattivata
Ambra
Acceso Guasto
—
Spento Nessun guasto o alimentazione disattivata
ICM supporta le seguenti porte I/O nella parte posteriore:
l
quattro porte SAS PCI Gen 2 da 6 Gb/s;
l
un connettore di gestione (RJ-12) per SPS (solo diagnostica di assistenza sul campo);
l
un connettore USB;
l
porte SAS x8 da 6 Gb/s.
Supporta quattro porte SAS x8 da 6Gb/s (due input e due output, una utilizzata) sulla
parte posteriore del modulo ICM. Questa porta fornisce un'interfaccia per le unità SAS e
NL-SAS nel DAE.
Tabella 65 LED porta ICM da 6 Gb/s
292
LED
Colore
Stato
Descrizione
Link/Attività
Blu
Acceso
Indica una connessione 4x o 8x con tutte le
linee funzionanti a 6 Gb/s.
Verde
Acceso
Indica che è stata stabilita una larghezza della
porta ampia diversa da 4x o 8x oppure che una
o più linee non funzionano a piena velocità o
non sono connesse.
—
Spento
Non connesso.
Hardware ECS
Figura 75 LED ICM
1. LED di errore alimentazione (ambra)
2. LED alimentazione (verde)
3. LED di attività link (blu/verde)
Alimentatore DAE
L'alimentatore può essere sostituito a caldo. Ha una vite con testa zigrinata incorporata
per la massima semplicità di installazione e rimozione. Ciascun alimentatore include una
ventola per il raffreddamento. L'alimentatore è un convertitore offline, auto-ranging, con
rifasamento, a più uscite e dotato di un proprio cavo. Ciascun alimentatore supporta un
DAE completamente configurato e condivide le correnti di carico con l'altro alimentatore.
L'alimentatore DAE fornisce quattro power zone indipendenti. Ciascun alimentatore
sostituibile a caldo è in grado di fornire 1300 W a 12 V nella configurazione a elevata
disponibilità di condivisione del carico. Il controllo e lo stato vengono implementati
nell'interfaccia I2C.
Alimentatore DAE
293
Hardware ECS
Tabella 66 LED del modulo di raffreddamento/alimentazione CA del DAE
LED
Colore
Stato
Descrizione
Alimentazione Verde
CA attivata
(alimentazion
e 12 V): un
LED per
—
ciascun cavo
di
alimentazione
.
Acceso
OK. Alimentazione CA o SPS applicata. Tutte le
tensioni in uscita rientrano nei rispettivi
intervalli di funzionamento, a esclusione del
guasto della ventola.
Spento
L'alimentazione 12 V non rientra nell'intervallo
di funzionamento, è in arresto o è stato
riscontrato un guasto nell'unità.
Interruzione di Ambra
alimentazione
Acceso
Sotto il controllo del modulo ICM. Acceso se le
ventole o gli output non rientrano nell'intervallo
di funzionamento specificato mentre l'unità
non è nella modalità a basso consumo
energetico.
Spento
Tutti gli output rientrano nell'intervallo
specificato o sono in arresto o è stato
riscontrato un guasto nell'unità.
—
294
Hardware ECS
Figura 76 Alimentatore DAE
Cablaggio SAS U-Series
Fornisce diagrammi di cablaggio per i cavi SAV che connettono nodi a DAE.
Nota
I diagrammi hardware numerano i nodi partendo da zero. In tutte le altre discussioni
dell'architettura e del software ECS, i nodi vengono numerati partendo da uno.
295
Hardware ECS
Figura 77 Cablaggio SAS per configurazioni a quattro nodi
296
Hardware ECS
Figura 78 Cablaggio SAS per configurazioni a otto nodi
297
Hardware ECS
298
CAPITOLO 31
Sostituzione di un disco di storage ECS in un
appliance U-Series
l
l
l
Pianificazione della sostituzione delle unità........................................................300
Output per il comando cs_hal list disks...............................................................300
Sostituzione di unità........................................................................................... 301
299
Pianificazione della sostituzione delle unità
Viene descritta una strategia efficiente per la pulizia periodica di un ECS Appliance per
sostituire le unità di storage di tipo FAILED e SUSPECT.
Nota
Per sostituire le unità principali (non di storage) del nodo, contattare EMC Customer
Support.
In questo documento viene effettuata la distinzione tra i termini "unità" e "disco".
Un'unità è uno spindle fisico. Un disco è un'entità logica (ovvero, una partizione in
un'unità).
Quando il sistema etichetta un'unità come FAILED, la logica di protezione dei dati ricrea i
dati di quell'unità su altre unità nel sistema. L'unità FAILED non viene più coinvolta nel
sistema in alcun modo. La sostituzione di un'unità non comporta il ripristino dei dati
nell'unità sostitutiva. Di conseguenza un'unità FAILED rappresenta solo una perdita di
capacità raw per il sistema. Questa caratteristica della protezione dei dati integrata
riduce la necessità di interventi di assistenza immediati quando un'unità si guasta.
È necessario sostituire anche le unità SUSPECT, che sono sospette a causa di errori fisici
e non per problemi di connettività. Quando un'unità è etichettata come SUSPECT, il
sistema non scrive più nuovi dati sull'unità, ma il sistema continua a leggerli. L'unità
SUSPECT con errori fisici sarà etichettata come FAILED quando gli errori fisici superano un
determinato limite di soglia. Finché l'unità rimane di tipo SUSPECT, non partecipa
completamente al sistema di storage. È pertanto consigliabile impostare manualmente
su Bad un disco nell'unità corrispondente utilizzando lo strumento da riga di comando
cs_hwmgr fornito. Questo passaggio dà al sistema l'opportunità di completare le
interazioni di rete in sospeso con l'unità. I dati sull'unità verranno ricostruiti altrove nel
sistema utilizzando copie dei dati di altre unità. Di conseguenza è possibile avviare il
processo di sostituzione non appena il sistema indica che il disco nell'unità FAILED
corrispondente è stato impostato su Bad.
Nota
L'UI ViPR elenca un nodo come DEGRADED quando dispone di dischi di storage con stato
Suspect o Bad.
Un modo efficiente per gestire le unità FAILED prevede la sostituzione periodica. Il
periodo di sostituzione dovrebbe essere calcolato utilizzando la percentuale di errore
media delle unità indicata dal produttore in modo che non vi sia il rischio che un numero
critico di unità si guasti entro la data pianificata per l'intervento di assistenza successivo.
Questo processo è denominato "pulizia". La pulizia comporta:
l
ordine di un numero sufficiente di unità per coprire la percentuale di errore media
prevista entro la data dell'intervento di assistenza successivo;
l
identificazione delle unità FAILED;
l
identificazione di unità SUSPECT che sono sospette a causa di errori fisici e
impostazione manuale dei dischi corrispondenti su Bad;
l
sostituzione delle unità FAILED.
Output per il comando cs_hal list disks
Descrive i tipi di righe di output del comando cs_hal list disks.
300
Nell'output cs_hal list disks abbreviato di seguito osservare i diversi tipi di righe:
l
Le prime tre righe rappresentano la struttura RAID di due unità interne del nodo.
l
La riga successiva mostra un'unità di storage GOOD. I nomi dei dispositivi, i numeri di
slot e i numeri di serie possono essere utilizzati nei comandi cs_hal a condizione
che siano univoci. Il nome dell'enclosure può inoltre essere utilizzato nei comandi
cs_hal.
l
La riga successiva mostra un'unità di storage FAILED. Partition Name indica che il
disco nell'unità corrispondente è assegnato all'object service, il disco è formattato e
lo stato del disco è Bad.
l
La riga successiva mostra un'unità di storage SUSPECT. Il disco nell'unità SUSPECT
corrispondente presenta uno stato Suspect.
l
L'ultima riga indica uno slot vuoto o un'unità che non può essere rilevata.
l
Lo stato di integrità definitivo di un'unità è indicato nella colonna SMART Status.
Nota
Ignorare le informazioni sullo stato nella colonna Partition Name. Queste
informazioni non sono necessarie ai fini della presente procedura. Se si è interessati
allo stato della partizione per altri motivi, il comando cs_hwmgr disk --listby-service Object presenterà le informazioni più aggiornate e accurate sullo
stato della partizione nella colonna Health.
l
La colonna DiskSet è riservata per l'utilizzo futuro.
[root@layton-cyan ~]# cs_hal list disks
Disks(s):
SCSI Device Block Device Enclosure
Partition Name
Number
SMART Status
DiskSet
----------- ------------ ----------- ----------------------------------------------------- -------------- -----------n/a
/dev/md0
RAID vol
n/a
supported
n/a
/dev/sg4
/dev/sdb
internal
KLH6DHXJ
GOOD
/dev/sg5
/dev/sdc
internal
KLH6DM1J
GOOD
/dev/sg8
/dev/sdf
/dev/sg0
Object:Formatted:Good
WCAW32601327
GOOD
/dev/sg9
/dev/sdg
/dev/sg0
Object:Formatted:Bad
WCAW32568324
FAILED: self-test fail; read element;
/dev/sg10
/dev/sdh
/dev/sg0
Object:Formatted:Suspect
WCAW32547329
SUSPECT: Reallocated_Sector_Count(5)=11
...
unavailable
/dev/sg0
Slot Serial
---n/a
not
0
1
A08
A09
A10
E05
internal: 2
external: 30
total disks: 32
Sostituzione di unità
Sostituire le unità di storage FAILED e SUSPECT usando i comandi sul nodo.
Nota
Non attivare la modalità di manutenzione per il nodo per sostituire le unità.
301
Procedura
1. Per accedere al rack (cabinet) ECS utilizzando la rete privata (192.168.219.xxx) da un
laptop, attenersi alla procedura descritta di seguito.
a. Dal retro del rack individuare le porte della rete dello switch privato da 1 GbE
aprendo la porta posteriore.
b. Nello switch (turtle) Arista da 1 GbE collegare un cavo di rete dal laptop alla porta
24 sullo switch.
Figura 79 Individuare la porta 24 sullo switch privato da 1 GbE
c. Impostare l'interfaccia di rete sul laptop sull'indirizzo statico 192.168.219.99 e
sulla subnet mask 255.255.255.0, senza richiedere alcun gateway.
d. Verificare il funzionamento della rete temporanea tra il laptop e la rete di gestione
privata del rack mediante il comando ping.
C:\>ping 192.168.219.1
Pinging 192.168.219.1 with 32 bytes of data:
Reply from 192.168.219.1: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.219.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Nota
Se 192.168.219.1 non risponde, provare 192.168.218.2. In caso di ulteriore
assenza di risposta, verificare l'IP del laptop o la subnet mask, la connessione di
rete e la connessione della porta switch.
e. Dal laptop, accedere con SSH nel nodo 1 (provo) tramite 192.168.219.1,
utilizzando le credenziali di root login (con la password predefinita o modificata
dal cliente).
302
2. Utilizzare il comando cs_hal list disks e osservare lo stato di integrità di
ciascuna unità nella colonna SMART Status:
# cs_hal list disks
Disks(s):
Partition Name
Number
SMART Status
DiskSet
----------- ------------ ----------- ----------------------------------------------------- -------------- -----------n/a
/dev/md0
RAID vol
n/a
supported
n/a
/dev/sg4
/dev/sdb
internal
KLH6DHXJ
GOOD
/dev/sg5
/dev/sdc
internal
KLH6DM1J
GOOD
/dev/sg8
/dev/sdf
/dev/sg0
WCAW32601327
GOOD
/dev/sg9
/dev/sdg
/dev/sg0
WCAW32568324
GOOD
/dev/sg10
/dev/sdh
/dev/sg0
WCAW32547329
GOOD
/dev/sg11
/dev/sdi
/dev/sg0
WCAW32543442
GOOD
/dev/sg12
/dev/sdj
/dev/sg0
WCAW32499200
GOOD
/dev/sg13
/dev/sdk
/dev/sg0
WCAW32540070
GOOD
/dev/sg14
/dev/sdl
/dev/sg0
WCAW32493928
GOOD
/dev/sg15
/dev/sdm
/dev/sg0
WCAW32612977
GOOD
/dev/sg16
/dev/sdn
/dev/sg0
WCAW32599710
/dev/sg17
/dev/sdo
/dev/sg0
WCAW32566491
GOOD
/dev/sg18
/dev/sdp
/dev/sg0
WCAW32528145
GOOD
/dev/sg19
/dev/sdq
/dev/sg0
WCAW32509214
GOOD
/dev/sg20
/dev/sdr
/dev/sg0
WCAW32499242
GOOD
/dev/sg21
/dev/sds
/dev/sg0
WCAW32613242
GOOD
/dev/sg22
/dev/sdt
/dev/sg0
WCAW32503593
GOOD
/dev/sg23
/dev/sdu
/dev/sg0
WCAW32607576
GOOD
/dev/sg24
/dev/sdv
/dev/sg0
WCAW32507898
GOOD
/dev/sg25
/dev/sdw
/dev/sg0
WCAW32613032
GOOD
/dev/sg26
/dev/sdx
/dev/sg0
WCAW32613016
GOOD
/dev/sg27
/dev/sdy
/dev/sg0
WCAW32543718
GOOD
/dev/sg28
/dev/sdz
/dev/sg0
WCAW32599747
GOOD
/dev/sg29
/dev/sdaa
/dev/sg0
WCAW32612688
GOOD
/dev/sg30
/dev/sdab
/dev/sg0
WCAW32567229
GOOD
/dev/sg31
/dev/sdac
/dev/sg0
WCAW32609899
GOOD
/dev/sg32
/dev/sdad
/dev/sg0
WCAW32546152
GOOD
/dev/sg33
/dev/sdae
/dev/sg0
WCAW32613312
GOOD
/dev/sg34
/dev/sdaf
/dev/sg0
Slot Serial
---n/a
not
0
1
A08
A09
A10
B08
B07
B06
A11
B10
B11
C11
D11
C10
D10
C09
D09
E11
E10
E09
C08
D08
C07
E06
E08
D06
C06
D07
E07
303
WCAW32507641
GOOD
/dev/sg3
/dev/sda
WCAW32547444
GOOD
/dev/sg6
/dev/sdd
WCAW32525128
GOOD
/dev/sg7
/dev/sde
WCAW32496935
GOOD
…
…
unavailable
unavailable
unavailable
unavailable
/dev/sg0
A06
/dev/sg0
A07
/dev/sg0
B09
/dev/sg0
/dev/sg0
/dev/sg0
/dev/sg0
E02
E03
E04
E05
internal: 2
external: 30
total disks: 32
Qui il report mostra le 2 unità interne del nodo, 30 unità di storage (una delle quali
con stato di integrità SUSPECT) e 30 slot vuoti etichettati come non disponibili.
Nota
Se l'output del comando precedente indica che il nome di partizione di un'unità è
"Object:Formatted:Bad" oppure "Object:Formatted:Suspect" e il relativo stato SMART
è "GOOD", non procedere oltre. Questa condizione è il risultato di un bug nel gestore
hardware che genera un'eccezione in fase di determinazione dell'integrità di un'unità.
Contattare l'assistenza clienti ECS e attendere che venga fornita una procedura di
risoluzione al problema. In caso contrario, procedere al passaggio successivo.
Nota
Se si dispone di un ID del disco dal portale ECS, utilizzare il seguente comando con
grep per ottenere il numero di serie del disco nella sesta colonna. In questo
esempio, il numero di serie è AR31021EG62L9C:
# cs_hwmgr disk --list-by-service Object | grep
a1d7c15f-9995-4205-99b9-2267794d0154
a1d7c15f-9995-4205-99b9-2267794d0154
...
AR31021EG62L9C
...
Utilizzare ora il comando cs_hwmgr drives --list con grep e il numero di
serie per ottenere l'ID dello slot nella sesta (ultima) colonna. In questo esempio, l'ID
dello slot è A06:
# cs_hwmgr drives --list | grep AR31021EG62L9C
ATA
HGST HUS726060AL AR31021EG62L9C
6001
Good
A06
Sono ora disponibili le informazioni necessarie per utilizzare questa procedura.
3. Annotare il numero di serie dell'unità FAILED o SUSPECT.
4. Se l'unità di destinazione è SUSPECT, procedere nel modo indicato di seguito.
Determinare se lo stato dell'unità è SUSPECT per via di problemi nell'hardware:
304
l
Continuare la procedura di sostituzione dell'unità se la colonna SMART Status
nell'output del comando cs-hal mostra dati di tipo "reallocated_sector_count".
Questi dati indicano problemi nell'hardware.
l
Arrestare la procedura di sostituzione dell'unità se non si visualizzano dati di tipo
"reallocated_sector_count". Lo stato di un'unità può essere SUSPECT per via di
problemi non correlati all'hardware ma, ad esempio, alla connettività.
a. Utilizzare il comando cs_hwmgr --list per ottenere i valori VendorId e
ProductID per il disco, disponibili nelle prime due colonne.
# cs_hwmgr drive --list | grep -i WCAW32599710
ATA
HUS726060ALA640
WCAW32599710
6001
Suspect
B11
Nota
Se il comando cs_hwgmr drive --list | grep <disk SN#> non restituisce alcun output
per un'unità "Suspect", l'unità non è monitorata dal gestore hardware. Contattare
l'assistenza clienti ECS per richiedere supporto. Consultare l'articolo 197235 della
knowledgebase.
b. Impostare lo stato di integrità dell'unità su "Bad" con il comando cs_hwmgr
drive --set-health-bad utilizzando i valori <VendorID>, <ProductID> e <Disk
SN#>.
# cs_hwmgr drive --set-health-bad ATA HUS726060ALA640
WCAW32547329
Setting drive health of ATA:HUS726060ALA640:WCAW32547329 to
bad...Suceeded
c. Utilizzare il comando cs_hwmgr drive --remove per rimuovere l'unità di
destinazione (o più nello specifico il disco associato all'unità) dalla
configurazione. Si tenga presente che questo comando non comporta la rimozione
dell'unità dall'output del comando cs_hwmgr drive --list.
# cs_hwmgr drive --remove ATA HUS726060ALA640 WCAW32599710
Removing drive ATA:HUS726060ALA640:WCAW32547329...Suceeded
Nota
Se il comando cs_hwmgr drive --remove ha esito negativo, provare con il comando
cs_hwmgr drive --force-remove utilizzando i valori <VendorID>,
<ProductID> e <Disk SN#>.
5. Se l'unità di destinazione è BAD, procedere nel modo indicato di seguito.
l
Se il numero di serie dell'unità non è indicato nell'output del comando cs_hwmgr
drive --list, ignorare questo passaggio.
l
Se lo stato dell'unità segnalato con il comando cs_hwmgr drive --list è
"Bad", procedere con il passaggio secondario di seguito.
a. Utilizzare il comando cs_hwmgr drive --remove per rimuovere l'unità di
Nota
305
6. Utilizzare il comando cs_hal led e il numero di serie per accendere il LED per
l'unità (per individuare l'unità corretta nel cassetto).
# cs_hal led WCAW32599710 blink
7. Individuare il DAE con l'unità FAILED.
8. Rimuovere (in senso antiorario) le viti a colletto dai fori di montaggio sui lati destro e
sinistro dell'enclosure in modo che possa essere accessibile. Afferrare le maniglie di
fissaggio dell'enclosure dai bordi zigrinati ed estrarle per liberare l'enclosure dalle
guide interne; estrarre quindi lentamente l'enclosure dal cabinet finché non si blocca
nella posizione di assistenza.
Figura 80 Rilascio dell'enclosure con viti a colletto ed estrazione dal cabinet
Nota
Se non si riesce a estrarre facilmente i dispositivi di bloccaggio, esercitare una lieve
pressione sul cassetto e riprovare.
9. Individuare l'unità da sostituire cercando un LED di errore color ambra (fisso)
illuminato. Verificare che l'ID dello slot fornito corrisponda all'unità con il LED di
errore illuminato. I disco sono disposti in cinque file da dodici assemblaggi di unità
ognuna. La prima fila (anteriore) è formata da A, seguita da B, C, D ed E; gli
assemblaggi di unità sono numerati da 0 a 11, da sinistra a destra, in ogni fila.
306
Figura 81 Layout dell'unità DAE
CL4749
10.Collegare un braccialetto ESD al polso e all'enclosure.
11.Rimuovere l'unità dal DAE premendo la linguetta di rilascio arancione. Sollevare il
supporto, rimuovere l'unità e posizionarla su una superficie antistatica.
307
Figura 82 Rimozione del modulo di un'unità DAE
2
3
CL4665
12.Installare la nuova unità nello stesso slot nel DAE.
13.Allineare l'unità alle guide nello slot, quindi inserire la nuova unità nel DAE.
14.Con il supporto del modulo dell'unità completamente aperto, inserire delicatamente il
modulo nello slot.
15.Il supporto del modulo dell'unità inizierà a ruotare verso il basso.
16.Spingere la maniglia verso il basso per bloccare il fermo. Dopo aver chiuso il supporto
di fissaggio, premere con decisione il bordo del modulo per verificare che l'unità sia
correttamente inserita. Il LED di funzionamento del modulo dell'unità lampeggia per
indicare l'avvio della sequenza di rotazione.
308
Figura 83 Installazione del modulo di un'unità DAE
1
2
3
CL4666
17.Inserire i due supporti autobloccanti arancioni per fissare l'enclosure onde evitare che
possa scivolare fuori dal cabinet. Allineare le due viti a colletto su ciascun lato con i
fori di montaggio sul cabinet. Introdurre le viti a colletto nei fori di montaggio e
serrarle con le dita.
309
Figura 84 Inserimento del DAE nel cabinet
18.Una volta chiuso l'enclosure, verificare che la velocità delle ventole torni ai normali
livelli operativi.
19.Utilizzare il comando cs_hal list disks per confermare che il sistema riconosce
la nuova unità. La nuova unità ha lo stesso ID di slot dell'unità sostituita. Annotare il
nuovo numero di serie. Il sistema integra automaticamente il nuovo disco in uso dai
servizi appropriati.
20.Utilizzare il comando cs_hal led e il nuovo numero di serie per spegnere il LED per
l'unità.
# cs_hal led <serial_number_of_new_drive> off
Risultati
Il nodo e il sistema rilevano automaticamente l'unità e la inizializzano per l'utilizzo.
310
CAPITOLO 32
Sostituzione di un disco di storage ECS in
hardware di terze parti
l
l
l
Pianificazione della sostituzione delle unità........................................................312
Output per il comando cs_hal list disks...............................................................312
Sostituzione di unità........................................................................................... 313
311
Pianificazione della sostituzione delle unità
Viene descritta una strategia efficiente per la pulizia periodica di un ECS Appliance per
sostituire le unità di storage di tipo FAILED e SUSPECT.
Nota
Per sostituire le unità principali (non di storage) del nodo, contattare EMC Customer
Support.
In questo documento viene effettuata la distinzione tra i termini "unità" e "disco".
Un'unità è uno spindle fisico. Un disco è un'entità logica (ovvero, una partizione in
un'unità).
Quando il sistema etichetta un'unità come FAILED, la logica di protezione dei dati ricrea i
dati di quell'unità su altre unità nel sistema. L'unità FAILED non viene più coinvolta nel
sistema in alcun modo. La sostituzione di un'unità non comporta il ripristino dei dati
nell'unità sostitutiva. Di conseguenza un'unità FAILED rappresenta solo una perdita di
capacità raw per il sistema. Questa caratteristica della protezione dei dati integrata
riduce la necessità di interventi di assistenza immediati quando un'unità si guasta.
È necessario sostituire anche le unità SUSPECT, che sono sospette a causa di errori fisici
e non per problemi di connettività. Quando un'unità è etichettata come SUSPECT, il
sistema non scrive più nuovi dati sull'unità, ma il sistema continua a leggerli. L'unità
SUSPECT con errori fisici sarà etichettata come FAILED quando gli errori fisici superano un
determinato limite di soglia. Finché l'unità rimane di tipo SUSPECT, non partecipa
completamente al sistema di storage. È pertanto consigliabile impostare manualmente
su Bad un disco nell'unità corrispondente utilizzando lo strumento da riga di comando
cs_hwmgr fornito. Questo passaggio dà al sistema l'opportunità di completare le
interazioni di rete in sospeso con l'unità. I dati sull'unità verranno ricostruiti altrove nel
sistema utilizzando copie dei dati di altre unità. Di conseguenza è possibile avviare il
processo di sostituzione non appena il sistema indica che il disco nell'unità FAILED
corrispondente è stato impostato su Bad.
Nota
L'UI ViPR elenca un nodo come DEGRADED quando dispone di dischi di storage con stato
Suspect o Bad.
Un modo efficiente per gestire le unità FAILED prevede la sostituzione periodica. Il
periodo di sostituzione dovrebbe essere calcolato utilizzando la percentuale di errore
media delle unità indicata dal produttore in modo che non vi sia il rischio che un numero
critico di unità si guasti entro la data pianificata per l'intervento di assistenza successivo.
Questo processo è denominato "pulizia". La pulizia comporta:
l
ordine di un numero sufficiente di unità per coprire la percentuale di errore media
prevista entro la data dell'intervento di assistenza successivo;
l
identificazione delle unità FAILED;
l
identificazione di unità SUSPECT che sono sospette a causa di errori fisici e
impostazione manuale dei dischi corrispondenti su Bad;
l
sostituzione delle unità FAILED.
Output per il comando cs_hal list disks
Descrive i tipi di righe di output del comando cs_hal list disks.
312
l
l
La riga successiva mostra un'unità di storage GOOD. I nomi dei dispositivi, i numeri di
slot e i numeri di serie possono essere utilizzati nei comandi cs_hal a condizione
che siano univoci. Il nome dell'enclosure può inoltre essere utilizzato nei comandi
cs_hal.
l
l
La riga successiva mostra un'unità di storage SUSPECT. Il disco nell'unità SUSPECT
corrispondente presenta uno stato Suspect.
l
l
Lo stato di integrità definitivo di un'unità è indicato nella colonna SMART Status.
Nota
Ignorare le informazioni sullo stato nella colonna Partition Name. Queste
informazioni non sono necessarie ai fini della presente procedura. Se si è interessati
allo stato della partizione per altri motivi, il comando cs_hwmgr disk --listby-service Object presenterà le informazioni più aggiornate e accurate sullo
stato della partizione nella colonna Health.
l
Disks(s):
Partition Name
Number
SMART Status
DiskSet
----------- ------------ ----------- ----------------------------------------------------- -------------- -----------n/a
/dev/md0
RAID vol
n/a
supported
n/a
/dev/sg4
/dev/sdb
internal
KLH6DHXJ
GOOD
/dev/sg5
/dev/sdc
internal
KLH6DM1J
GOOD
/dev/sg8
/dev/sdf
/dev/sg0
WCAW32601327
GOOD
/dev/sg9
/dev/sdg
/dev/sg0
WCAW32568324
/dev/sg10
/dev/sdh
/dev/sg0
WCAW32547329
...
unavailable
/dev/sg0
Slot Serial
---n/a
not
0
1
A08
A09
A10
E05
internal: 2
external: 30
total disks: 32
Sostituire le unità di storage FAILED e SUSPECT usando i comandi sul nodo.
Nota
Non attivare la modalità di manutenzione per il nodo per sostituire le unità.
313
Procedura
1. Per accedere al rack (cabinet) ECS utilizzando la rete privata (192.168.219.xxx) da un
laptop, attenersi alla procedura descritta di seguito.
a. Individuare le porte della rete dello switch privato da 1 GbE.
b. Nello switch (turtle) da 1 GbE collegare un cavo di rete dal laptop alla porta 24
sullo switch.
C:\>ping 192.168.219.1
Nota
e. Dal laptop, accedere con SSH nel nodo 1 (provo) tramite 192.168.219.1,
utilizzando le credenziali di root login (con la password predefinita o modificata
dal cliente).
2. Utilizzare il comando cs_hal list disks e osservare lo stato di integrità di
ciascuna unità nella colonna SMART Status:
# cs_hal list disks
Disks(s):
Partition Name
Number
SMART Status
DiskSet
----------- ------------ ----------- ----------------------------------------------------- -------------- -----------n/a
/dev/md0
RAID vol
n/a
supported
n/a
/dev/sg4
/dev/sdb
internal
KLH6DHXJ
GOOD
/dev/sg5
/dev/sdc
internal
KLH6DM1J
GOOD
/dev/sg8
/dev/sdf
/dev/sg0
WCAW32601327
GOOD
/dev/sg9
/dev/sdg
/dev/sg0
WCAW32568324
GOOD
/dev/sg10
/dev/sdh
/dev/sg0
WCAW32547329
GOOD
/dev/sg11
/dev/sdi
/dev/sg0
WCAW32543442
GOOD
/dev/sg12
/dev/sdj
/dev/sg0
WCAW32499200
GOOD
/dev/sg13
/dev/sdk
/dev/sg0
WCAW32540070
GOOD
314
Slot Serial
---n/a
0
1
A08
A09
A10
B08
B07
B06
not
/dev/sg14
/dev/sdl
/dev/sg0
WCAW32493928
GOOD
/dev/sg15
/dev/sdm
/dev/sg0
WCAW32612977
GOOD
/dev/sg16
/dev/sdn
/dev/sg0
WCAW32599710
/dev/sg17
/dev/sdo
/dev/sg0
WCAW32566491
GOOD
/dev/sg18
/dev/sdp
/dev/sg0
WCAW32528145
GOOD
/dev/sg19
/dev/sdq
/dev/sg0
WCAW32509214
GOOD
/dev/sg20
/dev/sdr
/dev/sg0
WCAW32499242
GOOD
/dev/sg21
/dev/sds
/dev/sg0
WCAW32613242
GOOD
/dev/sg22
/dev/sdt
/dev/sg0
WCAW32503593
GOOD
/dev/sg23
/dev/sdu
/dev/sg0
WCAW32607576
GOOD
/dev/sg24
/dev/sdv
/dev/sg0
WCAW32507898
GOOD
/dev/sg25
/dev/sdw
/dev/sg0
WCAW32613032
GOOD
/dev/sg26
/dev/sdx
/dev/sg0
WCAW32613016
GOOD
/dev/sg27
/dev/sdy
/dev/sg0
WCAW32543718
GOOD
/dev/sg28
/dev/sdz
/dev/sg0
WCAW32599747
GOOD
/dev/sg29
/dev/sdaa
/dev/sg0
WCAW32612688
GOOD
/dev/sg30
/dev/sdab
/dev/sg0
WCAW32567229
GOOD
/dev/sg31
/dev/sdac
/dev/sg0
WCAW32609899
GOOD
/dev/sg32
/dev/sdad
/dev/sg0
WCAW32546152
GOOD
/dev/sg33
/dev/sdae
/dev/sg0
WCAW32613312
GOOD
/dev/sg34
/dev/sdaf
/dev/sg0
WCAW32507641
GOOD
/dev/sg3
/dev/sda
/dev/sg0
WCAW32547444
GOOD
/dev/sg6
/dev/sdd
/dev/sg0
WCAW32525128
GOOD
/dev/sg7
/dev/sde
/dev/sg0
WCAW32496935
GOOD
…
…
unavailable
/dev/sg0
unavailable
/dev/sg0
unavailable
/dev/sg0
unavailable
/dev/sg0
A11
B10
B11
C11
D11
C10
D10
C09
D09
E11
E10
E09
C08
D08
C07
E06
E08
D06
C06
D07
E07
A06
A07
B09
E02
E03
E04
E05
internal: 2
external: 30
total disks: 32
Qui il report mostra le 2 unità interne del nodo, 30 unità di storage (una delle quali
con stato di integrità SUSPECT) e 30 slot vuoti etichettati come non disponibili.
315
Nota
Se l'output del comando precedente indica che il nome di partizione di un'unità è
"Object:Formatted:Bad" oppure "Object:Formatted:Suspect" e il relativo stato SMART
è "GOOD", non procedere oltre. Questa condizione è il risultato di un bug nel gestore
hardware che genera un'eccezione in fase di determinazione dell'integrità di un'unità.
Contattare l'assistenza clienti ECS e attendere che venga fornita una procedura di
risoluzione al problema. In caso contrario, procedere al passaggio successivo.
Nota
Se si dispone di un ID del disco dal portale ECS, utilizzare il seguente comando con
grep per ottenere il numero di serie del disco nella sesta colonna. In questo
esempio, il numero di serie è AR31021EG62L9C:
# cs_hwmgr disk --list-by-service Object | grep
a1d7c15f-9995-4205-99b9-2267794d0154
a1d7c15f-9995-4205-99b9-2267794d0154
...
AR31021EG62L9C
...
Utilizzare ora il comando cs_hwmgr drives --list con grep e il numero di
serie per ottenere l'ID dello slot nella sesta (ultima) colonna. In questo esempio, l'ID
dello slot è A06:
# cs_hwmgr drives --list | grep AR31021EG62L9C
ATA
HGST HUS726060AL AR31021EG62L9C
6001
Good
A06
Sono ora disponibili le informazioni necessarie per utilizzare questa procedura.
3. Annotare il numero di serie dell'unità FAILED o SUSPECT.
4. Se l'unità di destinazione è SUSPECT, procedere nel modo indicato di seguito.
Determinare se lo stato dell'unità è SUSPECT per via di problemi nell'hardware:
l
Continuare la procedura di sostituzione dell'unità se la colonna SMART Status
nell'output del comando cs-hal mostra dati di tipo "reallocated_sector_count".
Questi dati indicano problemi nell'hardware.
l
Arrestare la procedura di sostituzione dell'unità se non si visualizzano dati di tipo
"reallocated_sector_count". Lo stato di un'unità può essere SUSPECT per via di
problemi non correlati all'hardware ma, ad esempio, alla connettività.
a. Utilizzare il comando cs_hwmgr --list per ottenere i valori VendorId e
ProductID per il disco, disponibili nelle prime due colonne.
# cs_hwmgr drive --list | grep -i WCAW32599710
ATA
HUS726060ALA640
WCAW32599710
6001
Suspect
B11
Nota
Se il comando cs_hwgmr drive --list | grep <disk SN#> non restituisce alcun output
per un'unità "Suspect", l'unità non è monitorata dal gestore hardware. Contattare
l'assistenza clienti ECS per richiedere supporto. Consultare l'articolo 197235 della
knowledgebase.
316
b. Impostare lo stato di integrità dell'unità su "Bad" con il comando cs_hwmgr
drive --set-health-bad utilizzando i valori <VendorID>, <ProductID> e <Disk
SN#>.
# cs_hwmgr drive --set-health-bad ATA HUS726060ALA640
WCAW32547329
Setting drive health of ATA:HUS726060ALA640:WCAW32547329 to
bad...Suceeded
c. Utilizzare il comando cs_hwmgr drive --remove per rimuovere l'unità di
Nota
5. Se l'unità di destinazione è BAD, procedere nel modo indicato di seguito.
l
Se il numero di serie dell'unità non è indicato nell'output del comando cs_hwmgr
drive --list, ignorare questo passaggio.
l
Se lo stato dell'unità segnalato con il comando cs_hwmgr drive --list è
"Bad", procedere con il passaggio secondario di seguito.
a. Utilizzare il comando cs_hwmgr drive --remove per rimuovere l'unità di
Nota
6. Utilizzare il comando cs_hal led e il numero di serie per accendere il LED per
l'unità (per individuare l'unità corretta nel cassetto).
# cs_hal led WCAW32599710 blink
7. Individuare il disco e sostituirlo nello stesso slot attenendosi alle istruzioni fornite dal
produttore dell'hardware.
8. Utilizzare il comando cs_hal list disks per confermare che il sistema riconosce
la nuova unità. La nuova unità ha lo stesso ID di slot dell'unità sostituita. Annotare il
317
nuovo numero di serie. Il sistema integra automaticamente il nuovo disco in uso dai
servizi appropriati.
9. Utilizzare il comando cs_hal led e il nuovo numero di serie per spegnere il LED per
l'unità.
# cs_hal led <serial_number_of_new_drive> off
Risultati
Il nodo e il sistema rilevano automaticamente l'unità e la inizializzano per l'utilizzo.
318
CAPITOLO 33
Aggiunta di un aggiornamento di 60 dischi a un
appliance ECS U-Series
l
l
l
Pianificazione di un aggiornamento di 60 dischi................................................. 320
Comandi cs_hal.................................................................................................. 324
Esecuzione di un aggiornamento di 60 dischi......................................................325
Aggiunta di un aggiornamento di 60 dischi a un appliance ECS U-Series
319
Pianificazione di un aggiornamento di 60 dischi
Considerazioni sulla pianificazione di un aggiornamento di 60 dischi per un appliance
ECS U-Series
Un aggiornamento di 60 dischi aggiunge 15 dischi a ciascuna delle quattro coppie di
DAE/nodi.
Per determinare i rack che verranno aggiornati, fare riferimento al modulo dell'ordine di
vendita e individuare il numero PSNT. Nei rack di destinazione questo numero è indicato
sull'etichetta ben visibile applicata sul retro del prodotto. Prima di iniziare, determinare
se i nodi target eseguono software ECS 1.2 (o versioni successive) o una versione
precedente di ECS. La procedura varia a seconda della versione del software
Prima di avviare la procedura di aggiornamento, accertarsi di rispettare le regole indicate
di seguito.
l
Un DAE deve avere 15, 30, 45 o 60 dischi.
l
Le unità disco devono essere installate tenendo presente le configurazioni illustrate
nelle figure di seguito.
l
Gli ultimi quattro DAE devono contenere lo stesso numero di unità disco.
l
Gli ultimi quattro DAE devono avere 60 dischi per poter aggiornare il rack con altre
quattro coppie di DAE/nodi.
l
I primi quattro DAE devono contenere lo stesso numero di unità disco.
l
Tutte le unità disco in un DAE devono avere le stesse dimensioni e la stessa velocità.
l
Se un DAE presenta unità disco danneggiate (non valide), la procedura di
aggiornamento può proseguire senza dover sostituire tali unità.
Nella prima figura è illustrata la configurazione minima dell'appliance ECS U-Series.
320
l
Gli slot delle unità disco da A0 ad A11 sono sempre popolati.
l
Gli slot delle unità disco da B0 ad B2 sono sempre popolati.
Figura 85 Configurazione a 15 dischi
Determinare per quali slot di unità rimuovere la protezione e installare l'unità disco in
base alle figure illustrate di seguito.
Per eseguire l'aggiornamento da 15 a 30 dischi per DAE:
l
Popolare gli slot delle unità disco da B3 a B11.
l
Popolare gli slot delle unità disco da C0 a C5.
321
Per eseguire l'aggiornamento da 30 a 45 dischi:
322
l
Popolare gli slot delle unità disco da C6 a C11.
l
Popolare gli slot delle unità disco da D0 a D8.
Per eseguire l'aggiornamento da 45 a 60 dischi:
l
Popolare gli slot delle unità disco da D9 a D11.
l
Popolare gli slot delle unità disco da E0 a E11.
323
Comandi cs_hal
Vengono introdotti i comandi cs_hal utilizzati in questa procedura.
Comando cs_hal list disks
l
l
La riga successiva mostra l'unità di storage GOOD nella colonna SMART Status. I
nomi dei dispositivi, i numeri di slot e i numeri di serie possono essere utilizzati nei
comandi cs_hal a condizione che siano univoci. Il nome dell'enclosure (DAE) può
inoltre essere utilizzato nei comandi cs_hal.
l
Nota
Utilizzare il valore nella colonna SMART Status in fase di determinazione dello stato
corrente dell'unità disco.
l
l
l
La riga successiva mostra un'unità di storage SUSPECT.
Disks(s):
324
Partition Name
Number
SMART Status
DiskSet
----------- ------------ ----------- ----------------------------------------------------- -------------- -----------n/a
/dev/md0
RAID vol
n/a
supported
n/a
/dev/sg4
/dev/sdb
internal
KLH6DHXJ
GOOD
/dev/sg5
/dev/sdc
internal
KLH6DM1J
GOOD
/dev/sg8
/dev/sdf
/dev/sg0
WCAW32601327
GOOD
/dev/sg9
/dev/sdg
/dev/sg0
WCAW32568324
/dev/sg10
/dev/sdh
/dev/sg0
WCAW32547329
...
unavailable
/dev/sg0
Slot Serial
---n/a
not
0
1
A08
A09
A10
E05
internal: 2
external: 30
total disks: 32
cs_hal list daes
Utilizzare questo comando per individuare l'ID del DAE associato al nodo.
# cs_hal list daes
Enclosure(s):
SCSI Device Ext Disks
----------- --------/dev/sg2
15
total: 1
cs_hal list node
Utilizzare questo comando per individuare il nome del nodo in uso. In questo modo è
possibile definire il DAE associato al nodo facendo riferimento a un diagramma.
# cs_hal list node
Node(s):
Name
HBAs Enclosures Int Disks Ext Disks
---------- ---- ---------- --------- --------provo-sage 2
1
1
16
Esecuzione di un aggiornamento di 60 dischi
Aggiungere 15 dischi a 4 DAE (Disk Array Enclosure) per completare un aggiornamento di
60 dischi.
Prima di cominciare
Installare unità disco in una coppia nodo/DAE alla volta.
Procedura
1. Per accedere al rack ECS utilizzando la rete privata (192.168.219.xxx) da un laptop,
attenersi alla procedura descritta di seguito.
a. Dal retro del rack individuare le porte della rete dello switch privato da 1 GbE
aprendo la porta posteriore.
325
b. Nello switch (turtle) Arista da 1 GbE collegare un cavo di rete dal laptop alla porta
24 sullo switch.
Figura 89 Individuare la porta 24 sullo switch privato da 1 GbE
C:\>ping 192.168.219.1
Nota
e. Avviare una sessione SSH con il primo nodo.
2. Utilizzare il comando cs_hal list disks:
# cs_hal list disks
Nota
Gli slot delle unità disco elencati come occupati nell'output devono soddisfare le
aspettative dalla fase di pianificazione.
326
3. Individuare il DAE corretto:
a. Utilizzare il comando cs_hal list node per verificare il nome del nodo.
# cs_hal list node
Node(s):
Name
HBAs Enclosures Int Disks Ext Disks
---------- ---- ---------- --------- --------provo-sage 2
1
1
16
b. Utilizzare il seguente diagramma di cablaggio per identificare fisicamente il DAE
corretto:
Figura 90 Cablaggio di appliance ECS U-Series
4. Aprire il DAE identificato con il diagramma di cablaggio.
5. Rimuovere la protezione e popolare le unità disco in slot come illustrato nel
diagramma di layout dei dischi appropriato.
327
6. Chiudere il DAE e attendere 2 minuti.
7. Utilizzare il comando cs_hal list disks per verificare che il nodo abbia
riconosciuto il numero corretto di unità disco.
# cs_hal list disks | grep -i external
external: <number of disks>
Dove <number of disks> equivale a 30, 45 o 60.
8. Se il risultato è imprevisto, utilizzare il comando cs_hal list disks per
determinare le unità disco che il nodo non è in grado di riconoscere. Utilizzare il
diagramma di layout dei dischi appropriato per il confronto.
# cs_hal list disks
9. Se un'unità disco non viene riconosciuta nell'output, attenersi alla procedura
descritta di seguito.
a. Aprire il DAE e verificare che allo slot sia stata aggiunta un'unità disco
b. Se è presente un'unità disco, riposizionarla o aggiungerne una nuova allo slot.
c. Eseguire di nuovo il comando cs_hal list disks.
d. Se l'unità disco continua a non essere riconosciuta nell'output oppure l'output
viene elencato come FAILED, ordinare un'unità disco sostitutiva.
10.Ripetere i passaggi da 1 a 9 per le tre coppie di nodi/DAE rimanenti.
11.Attendere 10 minuti dopo il completamento dell'aggiornamento nel nodo finale.
Eseguire quindi il comando cs_hwmgr per verificare che tutte le unità siano visibili
per il sistema.
# viprexec "cs_hwmgr ListDrives | grep -i count"
Output from host : ???.???.???.1
Persistent drive count: <number of disks>
Dove:
l
Il numero finale dell'indirizzo IP visualizzato (.1 e così via) indica il numero di nodi
nel rack.
l
<number of disks> equivale a 30, 45 o 60.
Nota
Il comando viprexec esegue il comando tra virgolette in ciascun nodo del rack ECS
corrente. È opportuno prestare attenzione prima di utilizzare questo comando con
altri a livello di nodo.
328
12.Se l'output non corrisponde al numero di unità previste, attendere altri 10 minuti e
ripetere il comando viprexec. Se il numero di unità non è comunque corretto,
accedere tramite SSH nell'host con il numero di unità errato e ripetere il passaggio 11.
Risultati
Il nodo e il sistema ECS rilevano automaticamente le unità disco e le inizializzano per
l'utilizzo. Per confermare che i dischi vengano riconosciuti come validi dall'object service,
utilizzare il comando cs_hwmgr disk --list-by-service.
329
330
CAPITOLO 34
l
Requisiti di rack di terze parti ECS....................................................................... 332
331
I clienti che desiderano assemblare un appliance ECS utilizzando i propri rack devono
verificare che soddisfino i requisiti descritti di seguito.
In Technical information and requirements vengono fornite ulteriori informazioni.
Tabella 67 Requisiti di rack di terze parti
Categoria
requisito
Descrizione
Cabinet
Profondità rack minima: 112 cm.
Larghezza cabinet consigliata: 61 cm per garantire spazio per l'instradamento
dei cavi ai lati del cabinet.
Sufficiente spazio contiguo ovunque nel rack per installare i componenti
nell'ordine relativo richiesto.
Se utilizzata, una porta anteriore deve mantenere minimo 3 cm di spazio libero
dai pannelli. Deve essere perforata con almeno il 50% di apertura dell'aria
equamente distribuita. Non deve ostruire il passaggio al personale di
assistenza e deve consentire la visualizzazione dei LED attraverso di essa.
Se utilizzata, la porta posteriore deve essere perforata con almeno il 50% di
apertura dell'aria equamente distribuita.
È consigliabile utilizzare pannelli di chiusura per prevenire il ricircolo dell'aria
all'interno del cabinet.
Per garantire un'area operativa accettabile e un flusso d'aria appropriato, è
consigliabile mantenere 107 cm di spazio libero nell'area anteriore e 91 cm
nell'area posteriore del cabinet.
Guide NEMA
Larghezza di 48 cm con incrementi 1U.
Profondità compresa tra 61 e 86 cm.
Le guide NEMA con fori rotondi devono essere in grado di utilizzare viti di
dimensione M5 utilizzate con guide EMC.
Le guide NEMA con fori quadrati possono utilizzare viti speciali EMC,
036-709-013 o clip di vendor di rack di terze parti che accettino guide con fori
rotondi. Contattare EMC Sales in fase di ordinazione di componenti ECS per
accertarsi di ricevere il kit di guide corretto per la configurazione rack in uso.
Alimentazione
Requisiti dell'alimentazione CA: 200-240 V CA +/- 10% 50-60 Hz.
Il rack del cliente deve disporre di power zone ridondanti, una su ciascun lato
del rack con multiprese PDU separate. Ogni power zone ridondante deve
disporre della capacità per il massimo carico di alimentazione. NOTA: EMC non
è responsabile di eventuali guasti, problemi o interruzioni dell'attività dovuti
al malfunzionamento delle PDU fornite dal cliente.
Cablaggio
I cavi del prodotto devono essere instradati in modo che riflettano l'offerta
EMC standard di fabbrica. A tale scopo è inoltre consigliabile chiudere i cavi
con una fascetta ai lati per evitare che pendano e interferiscano con il
funzionamento delle FRU (Field Replaceable Unit).
I cavi ottici devono mantenere un raggio di piegatura di 3,8 cm.
332
Tabella 67 Requisiti di rack di terze parti (continua)
Categoria
requisito
Descrizione
I cavi di componenti di terze parti nel rack non devono interferire con
componenti logici EMC bloccando il flusso dell'aria dalla parte anteriore a
quella posteriore o impedendo il funzionamento delle singole FRU.
Disk Array
Tutti i DAE devono essere installati in ordine sequenziale dal basso verso
Enclosures (DAE) l'altro, onde evitare il rischio che si capovolgano.
Nota
Peso
l
ATTENZIONE
l
L’apertura di più DAE alla volta causa pericolo di ribaltamento.
l
Solo un DAE alla volta può essere aperto. I rack EMC rappresentano una
soluzione integrata per prevenire l’apertura di più DAE alla volta. I rack
dei clienti non supportano questa funzionalità.
Il rack del cliente deve essere in grado di supportare il peso delle
apparecchiature EMC.
333
334

EMC Elastic Cloud Storage (ECS) 2.0 Documentazione ECS

Transcription

Similar documents

elevatori a tazze bucket elevators

+ NAC - Igienisti on line

ljiki - ＪＵＫＩ

Beverage Processing guidelines (file pdf)

Studio ed analisi di sistemi di accumulo termico in

Corporate Brochure - API Applicazioni Plastiche Industriali

Filing and Storage Systems

Storage

L`arte dello sbroglio dei Circuiti Stampati