· 7 9 S3 11 S3 13 Amazon S3-API-Support in ECS................................................................. 14 S3-API – Unterstützte und nicht unterstützte

Elastic Cloud Storage (ECS)Version 3.1

Leitfaden für den Datenzugriff302-003-865

01

Copyright © 2013-2017 Dell Inc. oder ihre Tochtergesellschaften. Alle Rechte vorbehalten.

Stand August 2017

Dell ist der Ansicht, dass die Informationen in dieser Veröffentlichung zum Zeitpunkt der Veröffentlichung korrekt sind. Die Informationen können

jederzeit ohne vorherige Ankündigung geändert werden.

DIE INFORMATIONEN IN DIESER VERÖFFENTLICHUNG WERDEN OHNE GEWÄHR ZUR VERFÜGUNG GESTELLT. DELL MACHT KEINE

ZUSICHERUNGEN UND ÜBERNIMMT KEINE HAFTUNG JEDWEDER ART IM HINBLICK AUF DIE IN DIESEM DOKUMENT ENTHALTENEN

INFORMATIONEN UND SCHLIESST INSBESONDERE JEDWEDE IMPLIZITE HAFTUNG FÜR DIE HANDELSÜBLICHKEIT UND DIE EIGNUNG FÜR

EINEN BESTIMMTEN ZWECK AUS. FÜR DIE NUTZUNG, DAS KOPIEREN UND DIE VERTEILUNG DER IN DIESER VERÖFFENTLICHUNG

BESCHRIEBENEN DELL SOFTWARE IST EINE ENTSPRECHENDE SOFTWARELIZENZ ERFORDERLICH.

Dell, EMC und andere Marken sind Marken von Dell Inc. oder ihren Tochtergesellschaften. Alle anderen Marken sind das Eigentum ihrer jeweiligen

Inhaber. Veröffentlicht in Deutschland.

EMC Deutschland GmbHAm Kronberger Hang 2a 65824 Schwalbach/TaunusTel.: +49 6196 4728-0www.DellEMC.com/de-de/index.htm

2 Elastic Cloud Storage (ECS) 3.1 Leitfaden für den Datenzugriff

7

9

S3 11

S3 13Amazon S3-API-Support in ECS................................................................. 14S3-API – Unterstützte und nicht unterstützte Funktionen..........................14

Verhalten, wenn ein Bucket bereits vorhanden ist.......................... 18Bucket-Policy-Unterstützung..................................................................... 18

Erstellen, Zuweisen und Verwalten von Bucket-Policies................ 20Bucket-Policy-Szenarien................................................................21Unterstützte Bucket-Policy-Vorgänge.......................................... 22Bedingungen für unterstützte Bucket-Policy.................................24

S3-Erweiterungen...................................................................................... 25Erweiterungen für den Bytebereich............................................... 26Aufbewahrung............................................................................... 30FS (File System) Enabled...............................................................31

Metadatensuche.........................................................................................32Zuweisen von Metadaten-Indexwerten zu einem Bucket............... 32Verschlüsselung mit Metadatensuche............................................35Zuweisen von Metadaten zu Objekten mithilfe des S3-Protokolls....35Verwenden von Metadaten-Suchabfragen.................................... 36Verwenden der Metadatensuche aus dem ECS-Java-SDK ............42ECS-Systemmetadaten und optionale Attribute............................ 42

S3 und Swift-Interoperabilität.................................................................... 43Erstellen und Managen von geheimen Schlüsseln.......................................45

Erstellen eines Schlüssels für einen Objektbenutzer...................... 46Erstellen eines geheimen S3-Schlüssels: Selfservice..................... 47

Authentifizierung mit dem S3-Service........................................................50Verwenden der s3curl mit ECS....................................................................51Verwenden von SDKs für den Zugriff auf den S3-Service.......................... 52

Verwenden des Java Amazon SDK.................................................52Java SDK-Client für ECS............................................................... 54

OpenStack Swift 57

OpenStack Swift 59OpenStack Swift-Support in ECS.............................................................. 60Von OpenStack Swift unterstützte Vorgänge.............................................60Swift-Erweiterungen.................................................................................. 62Erweiterungen für den Swift-Bytebereich.................................................. 62

Aktualisieren eines Bytebereichs innerhalb eines Objekts.............. 63Überschreiben eines Teils eines Objekts........................................ 64Anhängen von Daten an ein Objekt................................................ 65

Abbildungen

Tabellen

Teil 1

Kapitel 1

Teil 2

Kapitel 2

INHALT

Elastic Cloud Storage (ECS) 3.1 Leitfaden für den Datenzugriff 3

Lesen mehrerer Bytebereiche innerhalb eines Objekts.................. 66Aufbewahrung............................................................................................ 66File System Enabled................................................................................... 67S3 und Swift-Interoperabilität.................................................................... 68OpenStack Swift-Authentifizierung............................................................68

Erstellen von Swift-Benutzern im ECS-Portal............................... 69Authentifizierung mit OpenStack Version 1.0 ................................70Authentifizierung mit OpenStack Version 2.0................................ 72Authentifizierung mithilfe von ECS Keystone V3-Integration.........73

Autorisierung für Container.........................................................................77

EMC Atmos 79

EMC Atmos 81EMC Atmos-API-Unterstützung in ECS..................................................... 82Unterstützte EMC Atmos-REST-API-Aufrufe............................................ 82Nicht unterstützte EMC Atmos-REST-API-Aufrufe................................... 84Support für Untermandanten in EMC Atmos-REST-API-Aufrufen............. 85API-Erweiterungen.....................................................................................85

Anhängen von Daten an ein Objekt................................................ 85ECS-Unterstützung von Aufbewahrung und Ablauf derAufbewahrungsfristen bei Atmos-Objekten................................... 86

CAS 93

CAS 95Einrichten des CAS-Supports in ECS......................................................... 96Cold-Speicher............................................................................................ 96Compliance.................................................................................................97

Plattformverstärkung und Compliance.......................................... 98Compliance und Aufbewahrungs-Policy.........................................98Compliance-Agent....................................................................... 100

CAS-Aufbewahrung in ECS.......................................................................100Erweiterte Aufbewahrung für CAS-Anwendungen: eventbasierteAufbewahrung, gesetzliche Aufbewahrungsfrist und Min-/Max-Kontrolle....102Konfigurieren von Namespace-Aufbewahrungs-Policies........................... 109Erstellen und Einrichten eines Bucket für einen CAS-Benutzer................. 110Einrichten eines CAS-Objektbenutzers...................................................... 111Konfigurieren von Bucket-ACLs für CAS................................................... 112ECS-Management-APIs, die CAS-Benutzer unterstützen......................... 114CAS-SDK-API-Support (Content Addressable Storage)............................115

ECS Management-REST-API 117

ECS Management-REST-API 119Einführung zur ECS-Management-REST-API........................................... 120Authentifizieren Sie sich bei der ECS-Management-REST-API.................120

Authentifizierung ohne Cookies ...................................................120Abmelden..................................................................................... 122ECS Management-REST-API Whoami-Befehl.............................. 123

Teil 3

Kapitel 3

Teil 4

Kapitel 4

Teil 5

Kapitel 5

INHALT


ECS-Management-REST-API – Zusammenfassung..................... 123

HDFS 129

Einführung zu ECS-HDFS 131Einführung zu ECS-HDFS......................................................................... 132Konfigurieren von Hadoop zur Verwendung von ECS HDFS ..................... 133Hadoop-Authentifizierungsmodi................................................................134

Zugriff auf den Bucket als Dateisystem........................................ 134Angepasste Gruppen-ACLs und Standardgruppe für Buckets...... 135Hadoop-Superuser und -Supergroup............................................136Multiprotokollzugriff (Crosshead)................................................ 136Proxybenutzer..............................................................................137Benutzer mit derselben Äquivalenzklasse..................................... 137

Migration von einem einfachen zu einem Kerberos-Hadoop-Cluster......... 137Hadoop-Kerberos-Authentifizierungsmodus.................................138

Interaktion mit dem Dateisystem...............................................................138Unterstützte Hadoop-Anwendungen.........................................................139

Konfiguration eines einfachen Hadoop-Clusters mit ECS HDFS141Integrieren eines einfachen Hadoop-Clusters mit ECS HDFS.................... 142Installation von Hortonworks HDP mithilfe von Ambari............................. 142Erstellen eines Buckets für HDFS über das ECS-Portal.............................144

Festlegen von angepassten Gruppen-ACLs für Buckets............... 147Einrichten von Benutzer ACLs für Buckets...................................149Beispiel für Hadoop und ECS-Bucket-Berechtigungen.................150

Planen der Integration von ECS HDFS und Hadoop.................................. 152Abrufen des ECS HDFS-Installations- und Supportpakets........................ 152Bereitstellen der ECS HDFS-Clientbibliothek............................................ 153Konfigurieren von ECS-Client-Eigenschaften........................................... 154Einrichten von Hive................................................................................... 155Überprüfen des Hadoop-Zugriffs auf ECS................................................ 156Sichern des Buckets..................................................................................157Verlagern des Standard-Dateisystems vom HDFS zu einem ECS-Bucket. 158

Konfiguration eines Kerberized Hadoop-Clusters mit ECS HDFS161

Integrieren eines sicheren Hadoop-Clusters mit ECS HDFS ..................... 162Migration von einem einfachen zu einem Kerberos-Cluster.......................162Zuordnen von Gruppennamen................................................................... 163Konfigurieren von ECS-Nodes mit dem ECS-Serviceprinzipal...................163Aktivieren von Kerberos mit Ambari.......................................................... 167Sichern des ECS-Buckets mithilfe von Metadaten.................................... 168

Laden von Metadatenwerten in ECS mithilfe der Management-REST-API......................................................................................171

Neukonfigurieren von ECS-Client-Eigenschaften......................................172Starten von Hadoop-Services und Überprüfung des Hadoop-Zugriffs aufECS...........................................................................................................173

Troubleshooting 175Einleitung.................................................................................................. 176

Teil 6

Kapitel 6

Kapitel 7

Kapitel 8

Kapitel 9

INHALT


Überprüfen der korrekten Konfiguration von AD/LDAP mit einem sicherenHadoop-Cluster.........................................................................................176Fehlschlagen des Pig-Tests: Kerberos-Prinzipal kann nicht abgerufenwerden...................................................................................................... 177Abgelehnte Berechtigung für AD-Benutzer............................................... 177Berechtigungsfehler.................................................................................. 177Verarbeitung der Anforderung fehlgeschlagen.......................................... 180Aktivieren von clientseitiger Kerberos-Anmeldung und Debugging............ 181Debuggen von Kerberos auf dem KDC....................................................... 181Beseitigen von Uhrabweichungen............................................................. 182Konfigurieren eines oder mehrerer neuer ECS-Nodes mit dem ECS-Serviceprinzipal.........................................................................................182Workaround für Fehler „Yarn-Verzeichnis ist nicht vorhanden“................ 184

Anhang: Hilfe für die Kerberos-Konfiguration 187Hilfe für die Kerberos-Konfiguration..........................................................188

Einrichten des Kerberos-KDC (Key Distribution Center).............. 188Konfigurieren der AD-Benutzerauthentifizierung für Kerberos..... 189

Anhang: Hadoop-core-site.xml-Eigenschaften für ECS HDFS 193Hadoop-core-site.xml-Eigenschaften für ECS HDFS................................ 194

Beispiel für core-site.xml für einfachen Authentifizierungsmodus....197

Anhang: Beispiel für sichere Bucket-Metadaten 199Sichere Bucket-Metadaten...................................................................... 200

Kapitel 10

Kapitel 11

Kapitel 12

INHALT


Aktivieren von Compliance für einen neuen Namespace im ECS-Portal......................99Aufbewahrungsoptionen für CAS-Buckets................................................................ 103EBR-Szenarien..........................................................................................................106Szenarien für gesetzliche Aufbewahrungsfristen...................................................... 108Neue Aufbewahrungs-Policy......................................................................................110Aufbewahrungs-Policies für einen Namespace.......................................................... 110CAS-Einstellungen für Objektbenutzer...................................................................... 112Bearbeiten einer Bucket-ACL.....................................................................................113Managen von Bucket-ACLs........................................................................................113ECS HDFS-Integration in einen Hadoop-Cluster....................................................... 132

12345678910

ABBILDUNGEN


ABBILDUNGEN


Unterstützte S3-APIs..................................................................................................14Zusätzliche Funktionen................................................................................................17Nicht unterstützte S3-APIs......................................................................................... 17Berechtigungen für Objektvorgänge...........................................................................23Berechtigungen für Bucket-Vorgänge........................................................................ 23Berechtigungen für Bucket-Teilressourcen-Vorgänge................................................ 23Unterstützte allgemeine AWS-Bedingungsschlüssel...................................................24Unterstützte S3-spezifische Bedingungsschlüssel für Objektvorgänge...................... 24Unterstützte S3-spezifische Bedingungsschlüssel für Bucket-Vorgänge....................25Von OpenStack Swift unterstützte Aufrufe................................................................ 61Zusätzliche Funktionen...............................................................................................62Von OpenStack Swift nicht unterstützte Aufrufe....................................................... 62Keystone-Authentifizierungsanbieter-Einstellungen................................................... 76Unterstützte Atmos-REST-API-Aufrufe..................................................................... 82Nicht unterstützte Atmos-REST-API-Aufrufe............................................................ 84Atmos-Aufbewahrungsfristen.....................................................................................87Anforderungen für reguläre und Cold-Archive im Vergleich........................................ 96ECS-Management-API-Ressourcen für die Aufbewahrung........................................101CAS-API-Funktionen für EBR (Event-Based Retention, eventbasierte Aufbewahrung)................................................................................................................................. 106CAS-API-Funktionen für gesetzliche Aufbewahrungsfristen..................................... 108Bucket-ACLs............................................................................................................. 113Bucket-ACL-Gruppen................................................................................................ 114ECS Management-REST-API– Zusammenfassung der Methoden.............................124Beispiele für Bucket-Berechtigungen für den Dateisystemzugriff in einem einfachenHadoop-Cluster.........................................................................................................150Beispiele für Bucket-Berechtigungen für den Dateisystemzugriff in einem KerberizedHadoop-Cluster......................................................................................................... 151ECS HDFS-Konfigurationsvoraussetzungen..............................................................152ECS HDFS-Clientbibliothek.......................................................................................153Hadoop-Konfiguration zur Aktivierung des ECS-Zugriffs.......................................... 154Hive-Templeton-Konfiguration..................................................................................155Hadoop-Konfiguration, um Hive-Gleichzeitigkeit und ACID-Transaktionen zuermöglichen.............................................................................................................. 158Hadoop-Konfiguration zur Aktivierung des ECS-Zugriffs.......................................... 172Hadoop core-site.xml-Eigenschaften........................................................................ 194

12345678910111213141516171819

2021222324

25

2627282930

3132

TABELLEN


TABELLEN


TEIL 1

S3

Kapitel 1, "S3"

S3 11

S3


KAPITEL 1

S3

l Amazon S3-API-Support in ECS......................................................................... 14l S3-API – Unterstützte und nicht unterstützte Funktionen................................. 14l Bucket-Policy-Unterstützung............................................................................. 18l S3-Erweiterungen..............................................................................................25l Metadatensuche................................................................................................ 32l S3 und Swift-Interoperabilität............................................................................43l Erstellen und Managen von geheimen Schlüsseln.............................................. 45l Authentifizierung mit dem S3-Service............................................................... 50l Verwenden der s3curl mit ECS........................................................................... 51l Verwenden von SDKs für den Zugriff auf den S3-Service.................................. 52

S3 13

Amazon S3-API-Support in ECSECS bietet Unterstützung für die Application Programming Interface (API) vonAmazon Simple Storage Service (Amazon S3).

Der Amazon S3-Objektservice wird auf den folgenden Ports zur Verfügung gestellt.

Protokoll Ports

HTTP 9020

HTTPS 9021

In den folgenden Themen werden der Support für die S3-API, die von ECSbereitgestellte Erweiterung, die Funktionsweise der Authentifizierung mit dem Serviceund die Verwendung von Software Development Kits (SDKs) für die Entwicklung vonClients für den Zugriff auf den Service beschrieben:

l S3-API – Unterstützte und nicht unterstützte Funktionen auf Seite 14

l S3-Erweiterungen auf Seite 25

l Metadatensuche auf Seite 32

l Erstellen und Managen von geheimen Schlüsseln auf Seite 45

l Authentifizierung mit dem S3-Service auf Seite 50

l Verwenden von SDKs für den Zugriff auf den S3-Service auf Seite 52

Einige Aspekte der Bucket-Adressierung und Authentifizierung sind für ECSspezifisch. Wenn Sie eine vorhandene Anwendung für die Kommunikation mit ECSkonfigurieren oder eine neue Anwendung entwickeln möchten, die die S3-API für dieKommunikation mit ECS verwendet, sollten Sie das folgende Thema konsultieren:ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.

S3-API – Unterstützte und nicht unterstützte FunktionenECS unterstützt einen Teil der Amazon S3 REST-API.

In den folgenden Abschnitten werden die unterstützten und nicht unterstützten APIsbeschrieben:

l Unterstützte S3-APIs auf Seite 14

l Nicht unterstützte S3-APIs auf Seite 17

Unterstützte S3-APIsIn der folgenden Tabelle werden die unterstützten S3-API-Methoden aufgelistet:

Tabelle 1 Unterstützte S3-APIs

Feature Anmerkungen

GET Service ECS unterstützt marker- und max-keys-Parameter, die dasErstellen von Seiten für die Bucket-Liste ermöglichen.

GET /?marker=<bucket>&max-keys=<num>

S3


https://community.emc.com/docs/DOC-56978

Tabelle 1 Unterstützte S3-APIs (Fortsetzung)

Feature Anmerkungen

Beispiel:

GET /?marker=mybucket&max-keys=40

DELETE Bucket

DELETE Bucket cors

DELETE Bucket lifecycle Nur der Ablaufteil wird im Lebenszyklus unterstützt.Richtlinien, die sich auf die Archivierung beziehen (AWSGlacier) werden nicht unterstützt. Der Lebenszyklus wird fürBuckets, die für das Dateisystem aktiviert sind, nichtunterstützt.

DELETE Bucket policy

GET Bucket (List Objects) Buckets, die für das Dateisystem aktiviert sind, unterstützenbeim Auflisten von Objekten im Bucket nur dasTrennzeichen /.

GET Bucket cors

GET Bucket acl

GET Bucket lifecycle Nur der Ablaufteil wird im Lebenszyklus unterstützt.Richtlinien, die sich auf die Archivierung beziehen (AWSGlacier) werden nicht unterstützt. Der Lebenszyklus wird fürBuckets, die für das Dateisystem aktiviert sind, nichtunterstützt.

GET Bucket policy

GET Bucket Object versions

GET Bucket versioning

HEAD Bucket

List Multipart Uploads

PUT Bucket Wenn PUT für einen vorhandenen Bucket durchgeführt wird,

siehe Verhalten, wenn ein Bucket bereits vorhanden ist aufSeite 18.

PUT Bucket cors

PUT Bucket acl

PUT Bucket lifecycle Nur der Ablaufteil wird im Lebenszyklus unterstützt.Richtlinien, die sich auf die Archivierung beziehen (AWSGlacier) werden nicht unterstützt. Der Lebenszyklus wird fürBuckets, die für das Dateisystem aktiviert sind, nichtunterstützt.

PUT Bucket policy Bucket-Policies können nicht für Buckets konfiguriert werden,die für das Dateisystem oder CAS aktiviert sind. Bucket-Policies können nicht für Vorgänge konfiguriert werden, dieECS nicht unterstützt. Weitere Informationen zur

S3

S3-API – Unterstützte und nicht unterstützte Funktionen 15

Tabelle 1 Unterstützte S3-APIs (Fortsetzung)

Feature Anmerkungen

Unterstützung von Bucket-Policies finden Sie unter Bucket-Policy-Unterstützung.

PUT Bucket versioning

DELETE Object

Delete Multiple Objects

GET Object

GET Object ACL

HEAD Object

PUT Object Unterstützt Block-PUT

PUT Object acl

PUT Object - Copy

OPTIONS object

Initiate Multipart Upload

Upload Part

Upload Part - Copy

Completed Multipart Upload ECS gibt ein ETag von 00 für diese Anforderung zurück. Diesunterscheidet sich von der Amazon S3-Antwort.

Abort Multipart Upload

List Parts

Hinweis

l Die Erstellung von Buckets, deren Name weniger als drei Zeichen umfasst, schlägtfehl, wobei der Fehler 400 Bad Request, InvalidBucketName ausgegebenwird.

l Wenn Sie einen Bucket oder ein Objekt ohne Inhalt erstellen, gibt ECS 400invalid content-length value zurück, AWS hingegen 400 BadRequest.

l Ein Objekt zu einem anderen Bucket zu kopieren, der zwar denselbenBenutzermetadaten-Indexschlüssel, aber mit einem anderen Datentyp indiziert,wird nicht unterstützt und führt zu dem Fehler 500 Server Error.

l Wenn Sie bei der Auflistung von Objekten in einem Bucket ein Präfix und einTrennzeichen verwenden, aber eine ungültige Markierung bereitstellen, gibt ECSden Fehler „500 Server Error“ zurück bzw. „400 Bad Request“ für einen Bucket,der für das Dateisystem aktiviert ist. Das unterscheidet sich von AWS, wo „200OK“ zurückgegeben wird, ohne dass Objekte aufgelistet werden.

S3


Tabelle 2 Zusätzliche Funktionen

Feature Anmerkungen

Vorab signierte URLs ECS unterstützt die Verwendung vorab signierter URLs, dieZugriff auf Objekte ohne Anmeldedaten ermöglichen.

Weitere Informationen finden Sie hier.

Block-PUT Mit dem PUT-Vorgang können Objekte in Blöcken

hochgeladen werden. Dadurch kann der Inhalt gesendetwerden, bevor die Gesamtgröße der Nutzdaten bekannt ist.Bei der Blockübertragung wird mit dem Transfer-Encoding-Header (Transfer-Encoding: chunked) angegeben, dass derInhalt in Blöcken übertragen wird.

Nicht unterstützte S3-APIsIn der folgenden Tabelle werden die nicht unterstützten S3-API-Methoden aufgelistet:

Tabelle 3 Nicht unterstützte S3-APIs

Feature Anmerkungen

DELETE Bucket tagging

DELETE Bucket website

GET Bucket location ECS berücksichtigt nur ein einziges virtuelles Rechenzentrum(VDC).

GET Bucket logging

GET Bucket notification Benachrichtigungen sind nur für die reduzierteRedundanzfunktion in S3 definiert. ECS unterstützt derzeitkeine Benachrichtigungen.

GET Bucket tagging

GET Bucket requestPayment ECS nutzt ein eigenes Modell für Zahlungen.

GET Bucket website

PUT Bucket logging

PUT Bucket notification Benachrichtigungen sind nur für die reduzierteRedundanzfunktion in S3 definiert. ECS unterstützt derzeitkeine Benachrichtigungen.

PUT Bucket tagging

PUT Bucket requestPayment ECS nutzt ein eigenes Modell für Zahlungen.

PUT Bucket website

Object APIs

GET Object torrent

POST Object

POST Object restore Dieser Vorgang bezieht sich auf AWS Glacier, das in ECSnicht unterstützt wird.

S3

S3-API – Unterstützte und nicht unterstützte Funktionen 17

http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html

Verhalten, wenn ein Bucket bereits vorhanden ist

Wenn versucht wird, einen Bucket mit einem Namen zu erstellen, der bereitsvorhanden ist, kann sich ECS anders verhalten als AWS.

AWS gibt immer 409 Conflict zurück, wenn ein Benutzer mit der BerechtigungFULL CONTROL für den Bucket oder mit einer anderen Berechtigung versucht, denBucket erneut zu erstellen. Wenn ein ECS-Benutzer mit FULL_CONTROL oderWRITE_ACP für den Bucket versucht, den Bucket erneut zu erstellen, gibt ECS 200OK zurück, und die ACL wird überschrieben, jedoch wird nicht der Eigentümergeändert. Einem ECS-Benutzer mit der Berechtigung READ/WRITE wird 409Conflict zurückgegeben, wenn er versucht, einen Bucket erneut zu erstellen.

Wenn der Bucket-Eigentümer versucht, einen Bucket erneut zu erstellen, gibt ECS200 OK zurück und überschreibt die ACL. AWS verhält sich ebenso.

Wenn ein Benutzer keine Zugriffsrechte für den Bucket hat, wird bei dem Versuch,den Bucket erneut zu erstellen, der Fehler 409 Conflict ausgegeben. AWS verhältsich ebenso.

Bucket-Policy-Unterstützung

ECS unterstützt die Einrichtung von S3-Bucket-Zugriffspolicies. Im Gegensatz zuACLs, die entweder alle Aktionen oder keine erlauben, geben Zugriffspolicies dieMöglichkeit, speziellen Benutzern oder allen Benutzern bedingungsabhängige odergranulare Berechtigungen für spezielle Aktionen einzuräumen. Policy-Bedingungendienen der Zuweisung von Berechtigungen für eine Reihe von Objekten, die dieBedingung erfüllen, und zur automatischen Zuweisung von Berechtigungen zu neuhochgeladenen Objekten.

Die Art und Weise, in der der Ressourcenzugriff bei Verwendung des S3-Protokollsverwaltet wird, ist beschrieben unter http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html, und Sie können diese Beschreibung als Grundlagefür das Verständnis und die Nutzung der S3-Bucket-Policies in ECS verwenden. DieserAbschnitt enthält grundlegende Informationen zur Nutzung von Bucket-Policies undzur Erkennung der Unterschiede bei der Nutzung von Bucket-Policies mit ECS.

Es folgt ein Beispiel für eine ECS-Bucket-Policy.

{ "Version": "2012-10-17", "Id": "S3PolicyIdNew2", "Statement":[ { "Sid":"Granting PutObject permission to user2 ", "Effect":"Allow", "Principal": "user_n2", "Action":["s3:PutObject"], "Resource":["PolicyBuck1/*"], "Condition": { "StringEquals": {"s3:x-amz-server-side-encryption": [ "AES256"]} } } ]}

S3


http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html

http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html

Jede Policy ist ein JavaScript Object Notation (JSON)-Dokument, das eine Version,einen Bezeichner und einen oder mehrere Anweisungen umfasst.

Version

Das Feld „Version“ gibt die Version der Policy-Sprache an und kann entweder2012-10-17 oder 2008-10-17 sein. 2008-10-17 wird automatisch eingefügt,wenn keine Version angegeben wird.

Es wird empfohlen, die Policy-Sprache für eine neue Policy auf die neuesteVersion festzulegen, nämlich auf 2012-10-17.

ID

Das Feld „Id“ ist optional.

Jede Anweisung mit umfasst die folgenden Elemente:

SID

Eine Anweisungs-ID. Diese Zeichenfolge beschreibt die Funktion der Anweisung.

Ressourcen

Der Bucket oder das Objekt, für den/das die Anweisung gilt. Die Ressource kannmit einer Resource- oder NotResource Anweisung verknüpft werden.

Der Ressourcenname ist der Bucket, und der Schlüsselname wird andersangegeben, je nachdem, ob Sie Adressierung im Stil des virtuellen Hosts oder imStil des Pfads verwenden, wie unten gezeigt:

Host Style: http://bucketname.ns1.emc.com/objectnamePath Style: http://ns1.emc.com/bucketname/objectname

In beiden Fällen lautet der Ressourcenname: bucketname/objectname .

Sie können die Platzhalterzeichen * und ? verwenden, wobei das Sternchen (*)für eine beliebige Kombination aus null oder mehr Zeichen und ein Fragezeichen(?) für ein beliebiges einzelnes Zeichen steht. Sie können z. B. alle Objekte ineinem Bucket namens bucketname wie folgt darstellen:

bucketname/*

Aktionen

Die Vorgänge, denen Sie Berechtigungen (zulässig oder unzulässig) zuweisenmöchten. Die unterstützten Vorgänge sind aufgeführt unter Unterstützte Bucket-Policy-Vorgänge auf Seite 22.

Der Vorgang kann mit einer Action- oder NotAction-Anweisung verknüpftwerden.

Wirkung

Kann auf Allow oder Deny festgelegt werden, um zu bestimmen, ob dieangegebenen Aktionen erlaubt oder verweigert werden sollen.

Prinzipal

Der ECS-Objektbenutzer, dem die angegebenen Aktionen erlaubt oder verweigertwerden.

S3

Bucket-Policy-Unterstützung 19

Um allen Benutzern Berechtigungen zu erteilen (als „anonymer Zugriff“bezeichnet), können Sie für den Prinzipal den Platzhalter * angeben, wie untengezeigt:

"Principal":"*"

Hinweis

ECS-Bucket-Policies unterstützen keine Verbundbenutzer und keine AmazonIAM-Benutzer und -Rollen.

Bedingungen

Die Bedingung, unter der die Policy wirksam ist. Mit dem Bedingungsausdruckwird eine in der Policy enthaltene Bedingung mit einer in der Anforderungenthaltenen Bedingung angeglichen.

Die folgenden Bedingungsoperatoren werden nicht unterstützt: Binary, ARN,IfExists, Check Key Exists. Die unterstützten Bedingungsschlüssel sind aufgeführtunter Bedingungen für unterstützte Bucket-Policy auf Seite 24.

Weitere Informationen zu den Elementen, die Sie in einer Policy verwenden können,sind hier in der Amazon S3-Dokumentation aufgeführt.

Erstellen, Zuweisen und Verwalten von Bucket-Policies

Sie können eine Bucket-Policy für einen Bucket über das ECS-Portal erstellen (sieheECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“). Es istauch möglich, eine Policy mithilfe eines anderen Editors zu erstellen und die Policymithilfe der ECS Management-REST-API oder der ECS S3-API mit einem Bucket zuverknüpfen.

Die ECS Management-REST-API bietet die folgenden APIs, mit denen Bucket-Policy-Teilressourcen hinzugefügt, abgerufen und gelöscht werden können:

l PUT /object/bucket/{bucketName}/policyl GET /object/bucket/{bucketName}/policyl DELETE /object/bucket/{bucketName}/policyUm eine Policy über die ECS Management-REST-API festzulegen, müssen Sieentweder die Rolle eines ECS-Systemadministrators oder eines Namespace-Administrators haben.

Die ECS S3-API bietet folgende APIs:

l PUT Bucket Policyl GET Bucket Policyl DELETE Bucket Policy

Hinweis

Um eine Policy über die S3-API festzulegen, müssen Sie der Bucket-Eigentümer sein.

Details zu diesen APIs finden Sie in der ECS-API-Referenz.

S3


http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html


http://doc.isilon.com/ECS/3.1/API/index.html

Bucket-Policy-Szenarien

Im Allgemeinen hat der Bucket-Eigentümer vollständige Kontrolle über einen Bucketund kann anderen Benutzern Berechtigungen erteilen und S3-Bucket-Policies miteinem S3-Client festlegen. In ECS kann ein ECS-System- oder -Namespace-Administrator Bucket-Policies auch mit dem Bucket-Policy-Editor im ECS-Portalfestlegen.

Sie können Bucket-Policies in den folgenden typischen Szenarien verwenden:

l Erteilen von Bucket-Berechtigungen für einen Benutzer auf Seite 21l Erteilen von Bucket-Berechtigungen für alle Benutzer auf Seite 22l Automatisches Zuweisen von Berechtigungen zu erstellten Objekten auf Seite 22

Erteilen von Bucket-Berechtigungen für einen BenutzerWenn einem Benutzer, der nicht der Eigentümer des Buckets ist, Berechtigungen füreinen Bucket gewährt werden sollen, können Sie die Ressource angeben, für die Siedie Berechtigungen ändern möchten, das Prinzipal-Attribut auf den Namen desBenutzers festlegen und eine oder mehrere Aktionen angeben, die Sie zulassenmöchten.

Das folgende Beispiel zeigt eine Policy, die einem Benutzer namens user1 dieBerechtigung zum Aktualisieren und Lesen von Objekten im Bucket mit dem Namenmybucket gewährt.

{ "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "Grant permission to user1", "Effect": "Allow", "Principal": ["user1"], "Action": [ "s3:PutObject","s3:GetObject" ], "Resource":[ "mybucket/*" ] } ]}

Sie können auch auf Bedingungen hinzufügen. Wenn Sie beispielsweise möchten, dassder Benutzer nur in der Lage ist, Schreib- und Lesevorgänge für Objektedurchzuführen, wenn er von einer bestimmten IP-Adresse aus auf den Bucket zugreift,können Sie eine IpAddress-Bedingung wie in der folgenden Policy dargestellthinzufügen.

{ "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "Grant permission ", "Effect": "Allow", "Principal": ["user1"], "Action": [ "s3:PutObject","s3:GetObject" ], "Resource":[ "mybucket/*" ] "Condition": {"IpAddress": {"aws:SourceIp": "<Ip address>"} } ]}

S3

Bucket-Policy-Szenarien 21

Erteilen von Bucket-Berechtigungen für alle BenutzerWenn einem Benutzer, der nicht der Eigentümer des Buckets ist, Berechtigungen füreinen Bucket gewährt werden sollen, können Sie die Ressource angeben, für die Siedie Berechtigungen ändern möchten, das Prinzipal-Attribut auf einen beliebigenBenutzer (*)festlegen und eine oder mehrere Aktionen angeben, die Sie zulassenmöchten.

Das folgende Beispiel zeigt eine Policy, die einem beliebigen Benutzer dieBerechtigung zum Lesen von Objekten im Bucket mit dem Namen mybucketgewährt.

{ "Version": "2012-10-17", "Id": "S3PolicyId2", "Statement": [ { "Sid": "statement2", "Effect": "Allow", "Principal": ["*"], "Action": [ "s3:GetObject" ], "Resource":[ "mybucket/*" ] } ]}

Automatisches Zuweisen von Berechtigungen zu erstellten ObjektenSie können Bucket-Policies verwenden, um automatisch den Zugriff aufaufgenommene Objektdaten zu aktivieren. In der folgenden Beispiel-Bucket-Policykönnen user1 und user2 untergeordnete Ressourcen (d. h. Objekte) in dem Bucketmit dem Namen mybucket erstellen und Objekt-ACLs festlegen. Mit der Möglichkeitzur Einrichtung von ACLs können die Benutzer dann Berechtigungen für andereBenutzer festlegen. Wenn Sie die ACL in demselben Vorgang festlegen, kann eineBedingung festgelegt werden, sodass eine vorgefertigte öffentliche Leseberechtigungfür die ACL angegeben werden muss, wenn das Objekt erstellt wird. Dadurch wirdsichergestellt, dass alle erstellten Objekte von allen Benutzern gelesen werdenkönnen.

{ "Version": "2012-10-17", "Id": "S3PolicyId3", "Statement": [ { "Sid": "statement3", "Effect": "Allow", "Principal": ["user1", "user2"], "Action": [ "s3:PutObject, s3:PutObjectAcl" ], "Resource":[ "mybucket/*" ] "Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}} } ]}

Unterstützte Bucket-Policy-Vorgänge

Die folgenden Tabellen enthalten die unterstützten Berechtigungsschlüsselwörter unddie von ihnen geregelten Vorgänge für Buckets, Objekte und Teilressourcen.

S3


Tabelle 4 Berechtigungen für Objektvorgänge

Berechtigungsschlüsselwort

Unterstützte S3-Vorgänge

s3:GetObject bezieht sich aufdie neueste Version einesBuckets mit Versionskontrolle

GET Object, HEAD Object

s3:GetObjectVersion GET Object, HEAD ObjectDiese Berechtigung unterstützt Anforderungen, in denen eineVersionsnummer angegeben ist

s3:PutObject PUT Object, POST Object, Initiate Multipart Upload, UploadPart, Complete Multipart Upload PUT Object - Copy

s3:GetObjectAcl GET Object ACL

s3:GetObjectVersionAcl GET ACL (für eine bestimmte Version des Objekts)

s3:PutObjectAcl PUT Object ACL

s3:PutObjectVersionAcl PUT Object (für eine bestimmte Version des Objekts)

s3:DeleteObject DELETE Object

s3:DeleteObjectVersion DELETE Object (eine bestimmte Version des Objekts)

s3:ListMultipartUploadParts List Parts

s3:AbortMultipartUpload Abort Multipart Upload

Tabelle 5 Berechtigungen für Bucket-Vorgänge



s3:DeleteBucket DELETE Bucket

s3:ListBucket GET Bucket (List Objects), HEAD Bucket

s3:ListBucketVersions GET Bucket Object versions

s3:GetLifecycleConfiguration GET Bucket lifecycle

s3:PutLifecycleConfiguration PUT Bucket lifecycle

Tabelle 6 Berechtigungen für Bucket-Teilressourcen-Vorgänge



s3:GetBucketAcl GET Bucket acl

s3:PutBucketAcl PUT Bucket acl

s3:GetBucketCORS GET Bucket cors

s3:PutBucketCORS PUT Bucket cors

s3:GetBucketVersioning GET Bucket versioning

s3:PutBucketVersioning PUT Bucket versioning

S3

Unterstützte Bucket-Policy-Vorgänge 23

Tabelle 6 Berechtigungen für Bucket-Teilressourcen-Vorgänge (Fortsetzung)



s3:GetBucketPolicy GET Bucket policy

s3:DeleteBucketPolicy DELETE Bucket policy

s3:PutBucketPolicy PUT Bucket policy

Bedingungen für unterstützte Bucket-PolicyMithilfe des Bedingungselements werden die Bedingungen festgelegt, die bestimmen,wann eine Policy in Kraft ist.

Die folgenden Tabellen enthalten die Bedingungsschlüssel, die von ECS unterstütztwerden und die in Bedingungsausdrücken verwendet werden können.

Tabelle 7 Unterstützte allgemeine AWS-Bedingungsschlüssel

Schlüsselname Beschreibung AnwendbarenOperatoren

aws:CurrentTime Zur Prüfung von Datum/Uhrzeit-Bedingungen Datumsoperator

aws:EpochTime Zur Prüfung von Datum/Uhrzeit-Bedingungenin Epochen- oder UNIX-Zeit (sieheDatumsbedingungsoperatoren).

Datumsoperator

aws:principalType Zur Prüfung des Prinzipaltyps (Benutzer,Konto, Verbundbenutzer usw.) für die aktuelleAnforderung.

Zeichenfolgenoperator

aws:SourceIp Zur Prüfung der IP-Adresse desAnfordernden.


aws:UserAgent Zur Prüfung der Client-Anwendung desAnfordernden.


aws:username Zur Prüfung der Benutzernamens desAnfordernden.


Tabelle 8 Unterstützte S3-spezifische Bedingungsschlüssel für Objektvorgänge

Schlüsselname Beschreibung Geltende Berechtigungen

s3:x-amz-acl Legt die Bedingung fest, dassspezielleZugriffsberechtigungenerforderlich sind, wenn derBenutzer ein Objekt hochlädt.

s3:PutObject,s3:PutObjectAcl,s3:PutObjectVersionAcl

s3:x-amz-grant-permission(für ausdrücklicheBerechtigungen) mit einer derfolgenden Bedingungen: read,write, read-acp, write-acp,full-control

Der Bucket-Eigentümer kannmit diesen SchlüsselnBedingungen hinzufügen,damit bestimmteBerechtigungen erforderlichsind.

s3:PutObject,s3:PutObjectAcl,s3:PutObjectVersionAcl

S3


Tabelle 8 Unterstützte S3-spezifische Bedingungsschlüssel für Objektvorgänge (Fortsetzung)


s3:x-amz-server-side-encryption

Erfordert, dass der Benutzerdiesen Header in derAnforderung angibt.

s3:PutObject,s3:PutObjectAcl

s3:VersionId Beschränkt den Datenzugriffdes Benutzers auf einebestimmte Version desObjekts.

s3:PutObject,s3:PutObjectAcl,s3:DeleteObjectVersion

Tabelle 9 Unterstützte S3-spezifische Bedingungsschlüssel für Bucket-Vorgänge


s3:x-amz-acl Legt die Bedingung fest, dassspezielleZugriffsberechtigungenerforderlich sind, wenn derBenutzer ein Objekt hochlädt.

s3:CreateBucket,s3:PutBucketAcl

s3:x-amz-grant-permission(für ausdrücklicheBerechtigungen) mit einer derfolgenden Bedingungen: read,write, read-acp, write-acp,full-control

Der Bucket-Eigentümer kannmit diesen SchlüsselnBedingungen hinzufügen,damit bestimmteBerechtigungen erforderlichsind.

s3:CreateBucket,s3:PutBucketAcl

s3:prefix Ruft nur die Objektschlüsselmit einem bestimmten Präfixab.

s3:ListBucket,s3:ListBucketVersions

s3:delimiter Erfordert, dass der Benutzerden Trennzeichenparameterin der Anforderung „GetBucket“ (List Objects) angibt.


s3:max-keys Begrenzt die Anzahl derSchlüssel, die ECS alsAntwort auf die Anforderung„Get Bucket“ (List Objects)zurückgibt, indem derBenutzer den Parameter„max-keys“ angeben muss.


S3-ErweiterungenECS unterstützt eine Reihe von Erweiterungen für die S3-API.

Die Erweiterungen und die unterstützenden APIs sind im Folgenden aufgeführt.

l Erweiterungen für den Bytebereich auf Seite 26

l Aufbewahrung auf Seite 30

l FS (File System) Enabled auf Seite 31

S3

S3-Erweiterungen 25

l Metadatensuche auf Seite 32

Erweiterungen für den Bytebereich

Die folgenden Erweiterungen für den Bytebereich sind verfügbar:

l Aktualisieren eines Bytebereichs innerhalb eines Objekts auf Seite 26

l Überschreiben eines Teils eines Objekts auf Seite 27

l Anhängen von Daten an ein Objekt auf Seite 28

l Lesen mehrerer Bytebereiche innerhalb eines Objekts auf Seite 29

Hinweis

Ein Bytebereichsvorgang (Aktualisieren/Anfügen/Überschreiben) bei einem Objektmit Versionsangabe erstellt keine neue Version, sondern aktualisiert die neuesteVersion.Auf alte Versionen eines Objekts angewendete Bytebereichsvorgänge (Aktualisieren/Anfügen/Überschreiben) aktualisieren die neueste Version.

Aktualisieren eines Bytebereichs innerhalb eines ObjektsSie können mit ECS-Erweiterungen für das S3-Protokoll einen Bytebereich innerhalbeines Objekts aktualisieren.

Die Teilaktualisierung eines Objekts kann in vielen Fällen sehr nützlich sein,beispielsweise zur Änderung eines binären Headers am Anfang einer großen Datei. AufAmazon oder anderen S3-kompatiblen Plattformen muss die vollständige Datei erneutgesendet werden.

Das folgende Beispiel veranschaulicht die Aktualisierung eines Bytebereichs. In diesemBeispiel hat object1 den Wert The quick brown fox jumps over the lazydog..

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:04:40 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:9qxKiHt2H7upUDPF86dvGp8VdvI=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:04:40 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:04:28 GMTETag: 6Content-Type: application/jsonContent-Length: 43 The quick brown fox jumps over the lazy dog.

Zur Aktualisierung eines bestimmten Bytebereichs in diesem Objekt muss der Header"Range" in der Objektdatenanforderung den Anfangs- und den End-Offset des zuaktualisierenden Objekts umfassen. Das Format lautet wie folgt: Range:bytes=<startOffset>-<endOffset>.

Im folgenden Beispiel umfasst die PUT-Anforderung den Header "Range" mit demWert bytes=10-14, d. h., dass die Bytes 10, 11, 12, 13 und 14 durch den in der

S3


Anforderung gesendeten Wert ersetzt werden. Hier wird der neue Wert greengesendet.

PUT /bucket1/object1 HTTP/1.1Content-Length: 5Range: bytes=10-14ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:15:16 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:xHJcAYAEQansKLaF+/4PdLBHyaM=Accept-Encoding: gzip, deflate, compress green HTTP/1.1 204 No ContentETag: 10x-amz-id-2: object1x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52aContent-Length: 0Date: Mon, 17 Jun 2013 20:15:16 GMT

Wenn das Objekt erneut gelesen wird, lautet der neue Wert jetzt The quick greenfox jumps over the lazy dog.. Ein bestimmter Bytebereich in diesem Objektwurde aktualisiert; dabei wurde das Wort brown durch das Wort green ersetzt.

GET /bucket1/object1 HTTP/1.1Cookie: JSESSIONID=wdit99359t8rnvipinz4tbtuACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:16:00 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:OGVN4z8NV5vnSAilQTdpv/fcQzU=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:16:00 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:15:16 GMTETag: 10Content-Type: application/jsonContent-Length: 43 The quick green fox jumps over the lazy dog.

Überschreiben eines Teils eines ObjektsSie können mit ECS-Erweiterungen für das S3-Protokoll Teile eines Objektsüberschreiben.

Geben Sie zum Überschreiben eines Objektteils die Daten an, die geschrieben werdensollen, sowie den Anfangs-Offset. Die Daten in der Anforderung werden ab demangegebenen Offset geschrieben. Das Format lautet wie folgt: Range:<startingOffset>-.

Um beispielsweise die Daten brown cat ab Offset 10 zu schreiben, verwenden Siediese PUT-Methode:

PUT /bucket1/object1 HTTP/1.1Content-Length: 9

S3

Erweiterungen für den Bytebereich 27

Range: bytes=10-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:51:41 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:uwPjDAgmazCP5lu77Zvbo+CiT4Q=Accept-Encoding: gzip, deflate, compress brown cat HTTP/1.1 204 No ContentETag: 25x-amz-id-2: object1x-amz-request-id: 65be45c2-0ee8-448a-a5a0-fff82573aa3bContent-Length: 0Date: Mon, 17 Jun 2013 20:51:41 GMT

Wenn das Objekt abgerufen wird, wurde ein Teil der Daten am angegebenen Anfangs-Offset ersetzt (green fox wurde ersetzt durch brown cat) und der Endwertlautet: The quick brown cat jumps over the lazy dog and cat.

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTETag: 25Content-Type: application/jsonContent-Length: 51 The quick brown cat jumps over the lazy dog and cat.

Anhängen von Daten an ein ObjektSie können mit ECS-Erweiterungen für das S3-Protokoll Daten an ein Objektanhängen.

In einigen Fällen müssen Sie Daten an ein Objekt anhängen, können den genauen Byte-Offset aber nicht effizient bestimmen. Für dieses Szenario bietet ECS die Möglichkeit,Daten ohne Angabe eines Offsets an das Objekt anzuhängen (der richtige Offset wirdin der Antwort angegeben). Um beispielsweise einer Protokolldatei Zeilenhinzuzufügen, müssen Sie bei Amazon oder anderen S3-kompatiblen Plattformen dievollständige Protokolldatei erneut senden.

Zum Anhängen von Daten an ein Objekt kann ein "Range"-Header mit demSonderwert bytes=-1- verwendet werden. Auf diese Weise kann das Objekterweitert werden, ohne dass die Größe des vorhandenen Objekts bekannt ist. DasFormat lautet wie folgt: Range: bytes=-1-

S3


Das folgende Beispiel zeigt eine Beispielanforderung zum Anhängen von Daten an einvorhandenes Objekt mit dem "Range"-Wert bytes=-1-. Hier wird der Wert andcat in der Anforderung gesendet.

PUT /bucket1/object1 HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/sqOFL65riEBSWLg6t8hL0DFW4c=Accept-Encoding: gzip, deflate, compress and cat HTTP/1.1 204 No ContentETag: 24x-amz-id-2: object1x-amz-request-id: 087ac237-6ff5-43e3-b587-0c8fe5c08732Content-Length: 0Date: Mon, 17 Jun 2013 20:46:01 GMT

Wenn das Objekt abgerufen wird, wurde and cat angefügt, und Sie können denvollständigen Wert sehen: The quick green fox jumps over the lazy dogand cat.

GET /bucket1/object1 HTTP/1.1ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:56 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:D8FSE8JoLl0MTQcFmd4nG1gMDTg=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:46:56 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:46:01 GMTETag: 24Content-Type: application/jsonContent-Length: 51 The quick green fox jumps over the lazy dog and cat.

Lesen mehrerer Bytebereiche innerhalb eines ObjektsSie können mit ECS-Erweiterungen für das S3-Protokoll mehrere Bytebereicheinnerhalb eines Objekts lesen

Mehrere Teile eines Objekts zu lesen kann in vielen Fällen sehr nützlich sein,beispielsweise um mehrere Teile eines Videos abzurufen. Bei Amazon oder anderenS3-kompatiblen Plattformen ist es erforderlich, für jeden Teil eine gesonderte Anfragezu senden.

S3

Erweiterungen für den Bytebereich 29

Um zwei bestimmte Bytebereiche innerhalb des Objekts object1 zu lesen, tätigenSie die folgende GET-Anforderung für Range: bytes==4-8,41-44. DieLeseantwort gilt dann für die Wörter quick und lazy.

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcRange: bytes==4-8,41-44Content-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 206 Partial ContentDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: multipart/byteranges;boundary=bound04acf7f0ae3cccLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTContent-Length: 230 --bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 4-8/50quick--bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 41-44/50lazy--bound04acf7f0ae3ccc--

Aufbewahrung

Der ECS-S3-Head unterstützt die Aufbewahrung von Objekten, damit diese für einenbestimmten Zeitraum nicht gelöscht oder geändert werden. Dabei handelt es sich umeine ECS-Erweiterung, die in der Standard-S3-API nicht verfügbar ist.

Die Aufbewahrung kann wie folgt festgelegt werden:

Aufbewahrungsfrist für Objekt

Speichert eine Aufbewahrungsfrist mit dem Objekt. Die Aufbewahrungsfrist wirdmithilfe eines Headers x-emc-retention-period für das Objekt festgelegt.

Aufbewahrungs-Policy für Objekt

Für das Objekt kann eine Aufbewahrungs-Policy und für den Namespace die mitder Policy verknüpfte Aufbewahrungsfrist festgelegt werden. Auf diese Weisekann für die Aufbewahrungsfrist für eine Gruppe von Objekten mithilfe einerPolicy derselbe Wert festgelegt werden. Dieser kann durch Ändern der Policy füralle Objekte geändert werden. Die Verwendung einer Policy bietet eine sehr vielhöhere Flexibilität als das Anwenden der Aufbewahrungsfrist auf ein Objekt.Darüber hinaus können mehrere Aufbewahrungs-Policies für einen Namespacefestgelegt werden, sodass für verschiedene Gruppen von Objektenunterschiedliche Aufbewahrungsfristen gelten.Die Aufbewahrungs-Policy, die mit einem Header x-emc-retention-policyauf ein Objekt angewendet wird, und die Aufbewahrungsfrist der Policy müssenvom ECS-Administrator über das ECS-Portal oder mit der ECS-Management-REST-API festgelegt werden.

Aufbewahrungsfrist für Bucket

Mit einer für einen Bucket gespeicherten Aufbewahrungsfrist wird eineAufbewahrung für alle Objekte festgelegt, wobei mit der Aufbewahrungsfrist oder-policy auf Objektlevel eine objektspezifische Einstellung vorgenommen werden

S3


kann, wenn eine längere Aufbewahrung erforderlich ist. Die Aufbewahrungsfristwird mithilfe eines Headers x-emc-retention-period für den Bucketfestgelegt.

Wenn der Versuch unternommen wird, das Objekt zu ändern oder zu löschen, wirdanhand der jeweils längeren Aufbewahrungsfrist für den Bucket oder für das Objektermittelt, ob der Vorgang durchgeführt werden kann. Die Aufbewahrungsfrist für einObjekt wird direkt im Objekt oder mithilfe der Objekt-Aufbewahrungs-Policyfestgelegt.

S3-Buckets können auch über die ECS-Management-REST-API oder über das ECS-Portal erstellt werden. Auch die Aufbewahrungsfrist für einen Bucket kann dortfestgelegt werden.

Lebenszyklus (Ablauf) und Aufbewahrung

ECS unterstützt die S3-Lebenszykluskonfiguration für Buckets mit und ohneaktivierter Versionierung.

Wenn Sie Objekte ändern und löschen müssen, die Objekte jedoch noch über einenbestimmten Zeitraum aufbewahrt werden sollen, können Sie die Versionierung füreinen Bucket aktivieren und mithilfe der Lebenszyklusfunktion bestimmen, wanngelöschte Versionen von Objekten aus ECS entfernt werden.

Versionierung und Lebenszyklus sind S3-Standardfunktionen. Der Lebenszyklusablaufist jedoch eng mit der Aufbewahrung verwandt, einer ECS-Erweiterung. Wenn derLebenszyklus vor Ablauf der Aufbewahrungsfrist abläuft, wird das Objekt erst nachAblauf der Aufbewahrungsfrist gelöscht.

FS (File System) Enabled

Für S3-Buckets kann auch FS aktiviert werden, sodass mit dem S3-Protokollgeschriebene Dateien mithilfe von Dateiprotokollen wie NFS und HDFS gelesenwerden können und umgekehrt.

Aktivieren des FS-ZugriffsSie können den FS-Zugriff beim Erstellen eines Buckets mit dem S3-Protokoll überden Header x-emc-file-system-access-enabled aktivieren. DerDateisystemzugriff kann auch aktiviert werden, wenn Sie einen Bucket über das ECS-Portal erstellen (oder mithilfe der ECS-Management-REST-API).

Einschränkung des FS-SupportEs gelten die folgenden Einschränkungen:

l Wenn für einen Bucket FS aktiviert ist, kann das S3-Lifecycle-Management nichtaktiviert werden.

l Wenn für einen Bucket FS aktiviert ist, kann die Aufbewahrung nicht verwendetwerden.

Crosshead-Support für FS„Crosshead-Support“ bezieht sich auf den Zugriff auf mit einem Protokollgeschriebene Objekte mithilfe eines anderen, von ECS unterstützten Protokolls. Mitdem S3-Head geschriebene Objekte können unter Verwendung der NFS- und HDFS-Dateisystemprotokolle gelesen und geschrieben werden.

Ein wesentlicher Aspekt des Crosshead-Support besteht in der Beziehung der Objekt-und Dateiberechtigungen zwischen Protokollen sowie beim Dateisystemzugriff in der

S3

FS (File System) Enabled 31

Beziehung der Konzepte von Benutzer und Gruppe zwischen Objekt- undDateiprotokollen.

Weitere Informationen zum Crosshead-Support bei Dateisystemen finden Sie im ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.

MetadatensucheDie mit ECS S3 kompatible API bietet eine Erweiterung für die Metadatensuche, mitder Objekte innerhalb eines Buckets basierend auf ihren Metadaten indiziert werdenkönnen und der Metadatenindex abgefragt werden kann, um Objekte und derenzugehörige Daten zu suchen.

Bisher konnten Metadaten kann mithilfe der ECS-S3-API zu Objekten zugeordnet undabgerufen werden, sofern die Identität des betreffenden Objekts bekannt ist. Ohne dieECS-Metadaten-Suchfunktion war es jedoch nicht möglich, ein Objekt basierend aufseine Metadaten zu suchen, ohne alle Objekte in einem Bucket zu durchlaufen.

Bei Metadaten kann es sich um Benutzer-Metadaten oder System-Metadaten handeln.System-Metadaten werden von ECS definiert und automatisch in Objektegeschrieben. Benutzer-Metadaten werden von Clients basierend aufAnwenderanforderungen geschrieben. Sowohl System- als auch Benutzer-Metadatenkönnen indiziert und als Basis für Metadatensuchvorgänge verwendet werden. DieAnzahl der Metadatenwerte, die indiziert werden können, ist auf 30 beschränkt undmuss bei der Erstellung des Bucket definiert werden.

Hinweis

Im Fall von kleinen Objekten (100 KB und weniger) reduziert sich dieDatenaufnahmerate leicht durch die Erhöhung der Anzahl der Indexschlüssel.Performancetestdaten, die zeigen, welche Auswirkungen die Verwendung vonMetadatenindizes für kleinere Objekte hat, finden Sie im Whitepaper zur ECS-Performance.

Beim Abfragen von Objekten basierend auf ihren indizierten Metadaten werden dieObjekte zurückgegeben, die mit der Abfrage und den Werten ihrer indiziertenMetadaten übereinstimmen. Sie können auch festlegen, dass alle System- und/oderBenutzer-Metadaten, die mit den zurückgegebenen Objekten zusammenhängen,zurückgegeben werden. Zusätzlich zu den System-Metadaten können Objekte auchüber Attribute verfügen, die im Rahmen der Metadaten-Suchergebnissezurückgegeben werden können. Die System-Metadatenwerte, die verfügbar sind undindiziert werden können, sowie die optional in Suchergebnissen anzeigbarenMetadatenwerte finden Sie hier.

Die folgenden Themen behandeln die Schritte zur Einrichtung und Verwendung derMetadaten-Suchfunktion:

l Zuweisen von Metadaten-Indexwerten zu einem Bucket auf Seite 32

l Zuweisen von Metadaten zu Objekten mithilfe des S3-Protokolls auf Seite 35

l Verwenden von Metadaten-Suchabfragen auf Seite 36

Zuweisen von Metadaten-Indexwerten zu einem BucketSie können mithilfe des ECS-Portals, der ECS-Management-REST-API oder des S3-Protokolls Metadaten-Indexwerte für einen Bucket festlegen. Die Indexwerte müssenden Namen der Metadaten entsprechen, die sie indexieren, und können aufSystemmetadaten oder Benutzermetadaten basieren.

S3



Eine Liste der verfügbaren Systemmetadaten finden Sie unter ECS-Systemmetadatenund optionale Attribute auf Seite 42.

Indexwerte werden festgelegt, wenn ein Bucket erstellt wird. Sie können dieVerwendung der Indexierung für einen Bucket deaktivieren, aber keine einzelnenIndexwerte ändern oder löschen.

Festlegen von Indexwerten über das Portal

Auf der Seite Manage > Bucket können Buckets erstellt und Indexwerte während desErstellungsprozesses zugewiesen werden. Weitere Informationen finden Sie im ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.

Festlegen von Indexwerten mit der ECS-Management-REST-API

Die Methoden zur Arbeit mit Indizes in der ECS-Management-REST-API sind in derTabelle unten aufgeführt. Zudem finden Sie dort Links zur API-Referenz.

API-Pfad Beschreibung

GET /object/bucket/searchmetadata Listet die Namen aller System-Metadatenschlüssel auf, die für die Zuweisungzu einem neuen Bucket verfügbar sind.

POST /object/bucket Weist die Metadaten-Indexnamen zu, die fürden angegebenen Bucket indiziert werden. DieIndexnamen werden in den Nutzdaten derMethode bereitgestellt.

GET /object/bucket Ruft eine Liste der Buckets ab. Die Bucket-Informationen für jeden Bucket zeigen dieDetails der Metadatensuche an.

GET /object/bucket/{bucketname}/info Ruft die Bucket-Details für den ausgewähltenBucket ab. Die Informationen für den Bucketumfassen die Details der Metadatensuche.

DELETE /object/bucket/{bucketname}/searchmetadata

Beendet die Indexierung über dieMetadatenschlüssel.

Beispiel: Abrufen der Liste der verfügbaren MetadatennamenDas folgende Beispiel ruft die gesamte Liste der Metadatennamen ab, die zurIndexierung zur Verfügung stehen und in Abfragen zurückgegeben werden können.

s3curl.pl --id myuser -- http://{host}:9020/?searchmetadata

Die Ergebnisse der Abfrage lauten wie folgt.

<MetadataSearchList xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <IndexableKeys> <Key> <Name>LastModified</Name> <Datatype>datetime</Datatype> </Key> <Key> <Name>Owner</Name> <Datatype>string</Datatype> </Key>

S3

Zuweisen von Metadaten-Indexwerten zu einem Bucket 33


<Key> <Name>Size</Name> <Datatype>integer</Datatype> </Key> <Key> <Name>CreateTime</Name> <Datatype>datetime</Datatype> </Key> <Key> <Name>ObjectName</Name> <Datatype>string</Datatype> </Key> </IndexableKeys> <OptionalAttributes> <Attribute> <Name>ContentType</Name> <Datatype>string</Datatype> </Attribute> <Attribute> <Name>Expiration</Name> <Datatype>datetime</Datatype> </Attribute> <Attribute> <Name>ContentEncoding</Name> <Datatype>string</Datatype> </Attribute> <Attribute> <Name>Expires</Name> <Datatype>datetime</Datatype> </Attribute> <Attribute> <Name>Retention</Name> <Datatype>integer</Datatype> </Attribute> </OptionalAttributes></MetadataSearchList>

Beispiel: Abrufen der Liste der Schlüssel, die für einen Bucket indiziert wurdenDas folgende Beispiel ruft die Liste der Metadatenschlüssel ab, die derzeit für einenBucket indexiert sind.

s3curl.pl --id myuser -- http://{host}:9020/mybucket/?searchmetadata

Die Ergebnisse für dieses Beispiel lauten wie folgt.

<MetadataSearchList xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <MetadataSearchEnabled>true</MetadataSearchEnabled> <IndexableKeys> <Key> <Name>Size</Name> <Datatype>integer</Datatype> </Key> <Key> <Name>x-amz-meta-DAT</Name> <Datatype>datetime</Datatype> </Key> </IndexableKeys></MetadataSearchList>

Festlegen von Werten mithilfe der S3-API

S3


Die Methoden zur Arbeit mit Indizes in der S3-API sind in der Tabelle untenaufgeführt. Zudem finden Sie dort Links zur API-Referenz.


GET /?searchmetadata Listet die Namen aller verfügbarenSystemmetadaten auf, die zur Indexierung inneuen Buckets verfügbar sind.

PUT /{bucket} -H x-emc-metadata-search:{name[;datatype],...}

Erstellt einen Bucket mit dem Suche-Metadatenschlüssel, der in der Kopfzeileangegeben wurde.

Hinweis

Es muss ein Datentyp mit dem Benutzer-Metadatenschlüssel verknüpft sein. Dies istjedoch für einen System-Metadatenschlüsselnicht erforderlich.

GET /{bucket}/?searchmetadata Ruft die Liste der Metadatenschlüssel ab, diederzeit für einen Bucket indexiert sind.

Beispiel Das Beispiel unten zeigt die Erstellung eines Bucket mit Metadatenindizes für dreiSystem-Metadatenschlüssel und zwei Benutzer-Metadatenschlüssel.

s3curl.pl --id myuser --createbucket -- http://{host}:9020/mybucket -H "x-emc-metadata-search:Size,CreateTime,LastModified,x-amz-meta-STR;String,x-amz-meta-INT;Integer"

Hinweis

Beim Hinzufügen eines neuen Objekts mit „x-amz-meta-“ müssen Werte mitSonderzeichen nicht URL-kodiert werden.

Verschlüsselung mit Metadatensuche

Wenn die Verschlüsselung auf einen Bucket angewendet wird, werden indizierteObjekt-Metadatenschlüssel in unverschlüsselter Form gespeichert, sodass es immermöglich ist, Metadatensuchvorgänge in verschlüsselten Buckets durchzuführen.

Wenn die Verschlüsselung mit vom System bereitgestellten Schlüsseln erfolgt, werdendie von einer Abfrage zurückgegebenen Objekt-Metadaten entschlüsselt und inTextform angezeigt. Ist die Verschlüsselung der Daten jedoch mit einem vom Benutzerbereitgestellten Chiffrierschlüssel erfolgt, werden nicht indizierte Metadaten wiegehabt verschlüsselt von einer Metadaten-Suchabfrage zurückgegeben, da die vomBenutzer stammenden Schlüssel nicht über die Abfrage bereitgestellt werden können.

Zuweisen von Metadaten zu Objekten mithilfe des S3-ProtokollsAnwender können Objekten Benutzermetadaten über den Header „x-amz-meta-“zuweisen. Bei dem zugewiesenen Wert kann es sich um eine beliebigeTextzeichenfolge handeln. Es wird zwischen Groß-/Kleinschreibung unterschieden.

Wenn die Metadaten indiziert sind, damit sie als Grundlage Objektsuchvorgänge(Metadaten-Suchfunktion) verwendet werden können, wird den Daten ein Datentyp

S3

Verschlüsselung mit Metadatensuche 35

zugewiesen. Beim Schreiben von Metadaten in Objekte sollten Clients Daten imrichtigen Format schreiben, dass diese korrekt in Suchvorgängen verwendet werdenkönnen.

Zu diesen Datentypen zählen:

Zeichenfolge

Wenn der Suchindexbegriff als Text markiert ist, wird die Metadaten-Zeichenfolge in allen Suchvergleichen als Zeichenfolge behandelt.

Ganzzahl

Wenn der Suchindexbegriff als Ganzzahl markiert ist, wird die Metadaten-Zeichenfolge in Suchvergleichen in eine Ganzzahl umgewandelt.

Dezimalzahl

Wenn der Suchindexbegriff als Dezimalzahl markiert ist, wird die Metadaten-Zeichenfolge in einen Dezimalwert umgewandelt, wobei das Zeichen „.“ alsDezimaltrennzeichen behandelt wird.

Datum/Uhrzeit

Wenn der Indexbegriff als Datum/Uhrzeit markiert ist, wird die Metadaten-Zeichenfolge als Datum und Uhrzeit mit dem erwarteten Format JJJJ-MM-ttTHH:mm:ssZ behandelt. Wenn die Zeichenfolge als Datum/Uhrzeit behandeltwerden soll, müssen Sie beim Angeben der Metadaten das Format JJJJ-MM-ttTHH:mm:ssZ verwenden.

Beispiel Im Beispiel unten wird die S3-API zum Hochladen eines Objekts und zweier Benutzer-Metadatenwerte für das Objekt verwendet.

s3curl.pl --id myuser --put myfile -- http://{host}:9020/mybucket/file4 -i -H x-amz-meta-STR:String4 -H x-amz-meta-INT:407

Verwenden von Metadaten-SuchabfragenDie Metadaten-Suchfunktion bietet eine umfassende Abfragesprache, um Objekte mitindizierten Metadaten zu suchen.

Die Syntax wird in der folgenden Tabelle gezeigt.

API-Syntax Antworttext

GET /{bucket}/?query={expression}&attributes={fieldname,…}&sorted={selector}&include_older_version={true|false}&max-keys=(num_keys)&marker=(marker value)

<BucketQueryResult xmlns:ns2="http://s3.amazonaws.com/doc/2006-03-01/"> <Name>mybucket</Name> <Marker/> <NextMarker>NO MORE PAGES</NextMarker> <MaxKeys>0</MaxKeys> <ObjectMatches> <object> <objectName>file4</objectName> <objectId>09998027b1b7fbb21f50e13fabb481a237ba2f60f352d437c8da3c7c1c8d7589</objectId> <versionId>0</versionId> <queryMds> <type>SYSMD</type> <mdMap> <entry>

S3


API-Syntax Antworttext

<key>createtime</key> <value>1449081778025</value> </entry> <entry> <key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778025</value> </entry> </mdMap> </queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>407</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>String4</value> </entry> </mdMap> </queryMds> <indexKey/> </object> <object ... </object> </ObjectMatches></BucketQueryResult>

Die Ausdruck-Schlüsselwörter und ihre Bedeutungen sind unten aufgelistet:

expression

Ein Ausdruck mit folgender Form:

[(]{condition1}[%20[and/or]%20{condition2}][)][%20[and/or]%20…]

„condition“ bezeichnet dabei einen Namensfilter für Metadatenschlüssel infolgender Form:

{selector} {operator}{argument},

Beispiel:

LastModified > 2015-09-02T11:22:00Z

selector

Eine durchsuchbarer Schlüsselname, der dem Bucket zugeordnet ist.

operator

Ein Operator. Möglicher Werte: ==,>,<,<=,>=

S3

Verwenden von Metadaten-Suchabfragen 37

Argument

Ein Wert, anhand dessen der selector geprüft wird.

attributes=[fieldname,...]

Gibt beliebige optionale Objektattribute an, die im Bericht enthalten sein sollen.Attributwerte sind im Bericht enthalten, wenn das Attribut im Objekt vorhandenist. Die optionalen Attributwerte umfassen:

l ContentEncoding

l ContentType

l Retention

l Expiration

l Läuft ab

Darüber hinaus ist es möglich, die nicht indizierten Metadaten, die mit den von derSuchanfrage zurückgegebenen Objekten verknüpft sind, zurückzugeben. Das giltfür folgende:

ALL

Listet sowohl System- als auch Benutzer-Metadaten auf, die mit denzurückgegebenen Objekten verknüpft sind.

ALL_SMD

Listet die System-Metadaten auf, die mit den zurückgegebenen Objektenverknüpft sind.

ALL_UMD

Listet die Benutzer-Metadaten auf, die mit den zurückgegebenen Objektenverknüpft sind.

sorted=[selector]

Gibt einen durchsuchbaren Schlüsselnamen an, der dem Bucket zugeordnetwurde. Der Schlüsselname muss ein Schlüssel sein, der im Ausdruck verwendetwird. Wenn &sorted=keyname nicht vorhanden ist, wird die Ausgabe nach demersten Schlüsselnamen sortiert, der im Abfrageausdruck erscheint.

Hinweis

Wenn „or“-Operatoren im Ausdruck verwendet werden, ist die Sortierreihenfolgeunbestimmt.

include-older-versions=[true|false]

Wenn die S3-Versionierung für einen Bucket aktiviert und diese Einstellung auf„true“ festgelegt ist, werden aktuelle und ältere Versionen von Objektenausgegeben, die dem Ausdruck entsprechen. Der Standardwert ist false.

max-keys

Die maximale Anzahl von der Abfrage entsprechenden Objekten, diezurückgegeben werden sollen. Wenn mehr Objekte vorhanden sind als in max-keyfestgelegt, wird eine Markierung zurückgegeben, mit der weitereÜbereinstimmungen abgerufen werden können.

S3


marker

Die Markierung, die von einer vorherigen Abfrage zurückgegeben wurde und denPunkt angibt, ab dem Abfrageübereinstimmungen zurückgegeben werden sollen.

Datum/Uhrzeit-Abfragen

Datum/Uhrzeit-Werte in Benutzermetadaten sind im ISO-8601-Format angegeben(JJJJ-MM-dd'T'HH:mm:ssZ) und werden in diesem Format von ECS übernommen.Metadatenabfragen verwenden ebenfalls dieses Format. ECS speichert jedochDatum/Uhrzeit-Werte für Systemdaten als epoch time, also als Zahl der Millisekundenseit Anfang 1970.

Wenn eine Abfrage Ergebnisse zurückgibt, wird das von ECS verwendete Datum/Uhrzeit-Format ausgegeben. Ein Beispiel für die beiden Formate ist unten dargestellt.

Header-Beispiel für hochgeladene Benutzermetadaten:

-H x-amz-meta-Foo:2015-11-30T12:00:00Z

Ausdruckformat der Benutzer- und Systemabfrage:

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z

Fragment der Abfrageergebnisse – System-Metadaten

<key>createtime</key> <value>1449081777620</value>

Fragment der Abfrageergebnisse – Benutzer-Metadaten

<key>x-amz-meta-Foo</key> <value>2015-11-30T12:00:00Z</value>

Verwenden von „marker“ und „max-keys“ zum Paginieren vonErgebnissen

Mit dem Abfrageparameter „max-keys“ können Sie die maximale Anzahl von Objektenangeben, die von einer Abfrage zurückgegeben werden.

Im folgenden Beispiel wird eine maximale Objektanzahl von 3 angegeben.

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z&max-keys=3

Wenn eine Abfrage mehr Objekten als der über „max-keys“ angegebenen Anzahlentspricht, wird auch eine Markierung zurückgegeben, anhand derer die nächste Seitemit Objekten zurückgegeben werden kann, die der Abfrage entsprechen, aber nichtzurückgegeben wurden.

S3


In der folgenden Abfrage wird eine Markierung angegeben, die aus einer vorherigenAbfrage abgerufen wurde:

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z&max-keys=3&marker=rO0ABXNyAD...

Wenn es sich bei den zurückgegebenen Objekten um die letzte Seite handelt, wird imElement „NextMarker“ des Antworttexts der Text „NO MORE PAGES“zurückgegeben.

<NextMarker>NO MORE PAGES</NextMarker>

Verwenden von Sonderzeichen in Abfragen

Die Verwendung von URL-Codierung ist erforderlich, damit Sonderzeichen korrektvom ECS-REST-Service empfangen werden. Außerdem können Anführungszeichenerforderlich sein, damit ECS beim Analysieren der Abfrage die Symbole nicht falschinterpretiert. Beispiel:

l Beim Abfragen von „x-amz-meta“-Werten müssen Sonderzeichen URL-kodiertwerden. Beispiel: Bei Verwendung von „%“ (ASCII, Hex: 25) oder „/“ (ASCII, Hex:2F) muss die Codierung „%25“ bzw. „%2F“ verwendet werden.

l Beim Abfragen von „x-amz-meta“-Werten mit SQL-reservierten Zeichen müssendie reservierten Zeichen maskiert werden. Dadurch wird sichergestellt, dass dervon ECS verwendete SQL-Parser diese Zeichen nicht als Operatoren interpretiert.Beispiel: 'ab < cd' (hier muss ein Paar von Anführungszeichen an den Serviceübergeben werden, damit der von ECS verwendete SQL-Parser keinen Operatorerkennt). Zu den SQL-reservierten Zeichen gehören Vergleichsoperatoren (=, <, >,+, -, !, ~) und Syntaxtrennzeichen (Komma, Semikolon).Abhängig vom verwendeten Client sind verschiedene Arten vonAnführungszeichen möglich. Beispiel für Unix-Befehlszeilentools wie S3curl.pl:

?query="'ab+cd<ed;ef'"

In diesem Fall wird der Suchwert in einfache Anführungszeichen und die Abfrage indoppelte Anführungszeichen gesetzt.

Beispiel einer Metadatensuche

Das Beispiel unten verwendet die S3-API, um einen Bucket nach einerÜbereinstimmung für eine bestimmte Objektgröße und einen Benutzer-Metadatenwertzu durchsuchen.

Hinweis

Bei einigen REST-Clients müssen Sie unter Umständen Leerzeichen mit URL-Code%20 codieren.

s3curl.pl --id myuser -- "http://{host}:9020.mybucket?query=Size>1000%20and%20x-amz-meta-STR>=String4

S3


Das Ergebnis zeigt drei Objekte, die der Suche entsprechen.

<BucketQueryResult xmlns:ns2="http://s3.amazonaws.com/doc/2006-03-01/"> <Name>mybucket</Name> <Marker/> <NextMarker>NO MORE PAGES</NextMarker> <MaxKeys>0</MaxKeys> <ObjectMatches> <object> <objectName>file4</objectName> <objectId>09998027b1b7fbb21f50e13fabb481a237ba2f60f352d437c8da3c7c1c8d7589</objectId> <versionId>0</versionId> <queryMds> <type>SYSMD</type> <mdMap> <entry> <key>createtime</key> <value>1449081778025</value> </entry> <entry> <key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778025</value> </entry> </mdMap> </queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>407</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>String4</value> </entry> </mdMap> </queryMds> <indexKey/> </object> <object> <objectName>file5</objectName> <objectId>1ad87d86ef558ca0620a26855662da1030f7d9ff1d4bbc7c2ffdfe29943b9150</objectId> <queryMds> <type>SYSMD</type> <mdMap> <entry> <key>createtime</key> <value>1449081778396</value> </entry> <entry> <key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778396</value> </entry> </mdMap>

S3


</queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>507</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>Sring5</value> </entry> </mdMap> </queryMds> <indexKey/> </object> </ObjectMatches></BucketQueryResult>

Verwenden der Metadatensuche aus dem ECS-Java-SDK

Im SDK von Version 3.0 gibt es eine Option zum Ausschließen der Parameter „search“und „searchmetadata“ aus der Signatur, wenn eine Verbindung mit einer ECS-Versionvor ECS 3.0 hergestellt wird. Diese Parameter waren nicht Teil derSignaturberechnung in ECS 2.x, wurden nun aber in die Berechnung aufgenommen,um die Sicherheit zu verbessern.

In der folgenden Kompatibilitätstabelle ist der SDK-Support für die Metadaten-Suchfunktion dargestellt:

ECS-Version

2.x 3.x

SDK 2.x Ja Nein

SDK 3.x Ja Ja

ECS-Systemmetadaten und optionale AttributeSystemmetadaten werden automatisch jedem Objekt im Objektspeicher zugewiesen.Einige Systemmetadaten sind immer ausgefüllt und können als Indexschlüsselverwendet werden, andere Metadaten sind nicht immer vorhanden. Wo sie vorhandensind, können sie jedoch in Metadaten-Suchergebnissen angezeigt werden.

SystemmetadatenDie Systemmetadaten in der nachfolgenden Tabelle können als Schlüssel fürMetadaten-Suchindizes verwendet werden.

Name (Alias) Typ Beschreibung

ObjectName Zeichenfolge

Name des Objekts.

Eigentümer Zeichenfolge

Die Identität des Objekteigentümers

Größe integer Größe des Objekts

CreateTime datetime Der Zeitpunkt, zu dem das Objekt erstellt wurde

S3


Name (Alias) Typ Beschreibung

LastModified datetime Das Datum und die Uhrzeit, zu der das Objektzuletzt geändert wurde.

Hinweis

Eine Änderung wird von ECS S3-Erweiterungen zurAktualisierung des Bytebereichs unterstützt, nichtvon der reinen S3-API.

Optionale MetadatenattributeOptionale System-Metadatenattribute müssen nicht zwingend für ein Objekteingegeben, können aber optional zusammen mit den Suchergebnissen ausgegebenwerden. Die optionalen Systemmetadaten werden in der folgenden Tabelle aufgeführt.

Name (Alias) Typ

ContentType Zeichenfolge

Ablauf datetime

ContentEncoding Zeichenfolge

Expires datetime

Aufbewahrung integer

S3 und Swift-InteroperabilitätS3- und Swift-Protokolle können so zusammenarbeiten, dass S3-Anwendungen aufObjekte in Swift-Buckets und Swift-Anwendungen auf Objekte in S3-Bucketszugreifen können.

Bei der Überlegung, ob es möglich sein soll, mit dem Swift-Head auf Objektezuzugreifen, die mit dem S3-Head erstellt wurden (und umgekehrt), ist zunächst zubedenken, ob Benutzer auf den Bucket zugreifen können (in Swift als „Container“bezeichnet). Einem Bucket ist ein Bucket-Typ zugewiesen (z. B. S3 oder Swift), jenachdem, mit welchem ESC-Head der Bucket erstellt wurde. Wenn Sie sicherstellenmöchten, dass eine Anwendung sowohl auf Swift-Buckets als auch auf S3-Bucketszugreifen kann, müssen Sie dafür sorgen, dass Objektbenutzer die für den jeweiligenBucket-Typ passende Berechtigung haben. Das bedarf genauer Überlegungen, daBerechtigungen für Swift- und S3-Buckets auf unterschiedliche Weise festgelegtwerden.

Hinweis

S3 und Swift-Interoperabilität ist nicht mit der Nutzung von Bucket-Policieskompatibel. Bucket-Policies gelten nur für den Bucket-Zugriff mit dem S3-Head undwerden beim Bucket-Zugriff mit der Swift-API nicht durchgesetzt.

In ECS können demselben Objektbenutzernamen sowohl S3- als auch Swift-Berechtigungen zugewiesen werden. In Bezug auf ECS kann also ein Benutzer namensjohn, der sich als Swift-Benutzer authentifiziert, auf alle S3-Ressourcen zugreifen,für die john eine Zugriffsberechtigung hat.

S3

S3 und Swift-Interoperabilität 43

Der Zugriff auf eine Ressource wird dadurch bestimmt, ob der Benutzer der Bucket-Eigentümer ist oder ob dem Benutzer mithilfe von ACLs die Berechtigung für denBucket zugewiesen wurde. Wenn also ein Bucket beispielsweise von einem S3-Benutzer erstellt wird, ist der betreffende S3-Benutzername der Eigentümer desBuckets, und der Benutzer hat sämtliche Berechtigungen für den Bucket. In ähnlicherWeise hat ein Swift-Benutzer mit demselben Namen ebenfalls sämtlicheBerechtigungen für den Bucket.

Wenn Sie möchten, dass nicht nur der Besitzer, sondern auch andere Benutzer aufeinen Bucket zugreifen können, ist es möglich, mithilfe von ACLs Berechtigungenzuzuweisen. Der Zugriff auf Swift-Container kann mithilfe von Gruppen-ACLs gewährtwerden (in ECS sind dies benutzerdefinierte Gruppen-ACLs). Der Swift-Headüberprüft die Gruppenmitgliedschaft, bevor er die Berechtigungen der Gruppen-ACLüberprüft. Swift-Containern wird die Gruppe admin implizit hinzugefügt, und daherkönnen alle Benutzer, die Mitglied der Gruppe admin (und damit admin-Benutzer)sind, auf die Container eines beliebigen anderen admin-Benutzers zugreifen. Nuradmin-Benutzer haben die Berechtigung, Container zu erstellen, zu löschen undaufzulisten. Die Berechtigungen des admin-Benutzers gelten nur für den Namespace,zu dem der Benutzer gehört. Der Zugriff auf S3-Buckets hängt vonBenutzerberechtigungen (Benutzer-ACLs), nicht von Gruppenberechtigungen ab. Umüber den Zugriff auf einen Bucket zu entscheiden, prüft der S3-Head, ob der BenutzerACL-Berechtigungen für den Bucket hat. Dies ist in der folgenden Abbildungdargestellt.

S3 HEAD SWIFT HEAD

S3 APPLICATION

S3 BUCKET ACCESS SWIFT BUCKET ACCESS

GROUP ACLUSER ACL

SWIFT APPLICATION

ECS OBJECT USER

S3 KEY

SWIFT PASSWORDSWIFT GROUP

Swift user accessto Swift containerS3 user access

to S3 bucket

check Swift group ACLpermissions

Swift user access to S3 bucket

S3 user access to Swift container

check S3user ACL

CROSSHEAD

Da Swift den Zugriff auf Ressourcen anhand von Gruppen gewährt, muss ein S3-Benutzer, der auf einen Swift-Container zugreifen möchte, ebenfalls einer Swift-Gruppe zugewiesen sein, und zwar entweder der Gruppe admin oder einer Gruppe,

S3


der für den betreffenden Container benutzerdefinierte Gruppen-ACLs zugewiesenwurden.

Zusammengefasst heißt das, eine der folgenden Bedingungen muss erfüllt sein, damitder Zugriff auf S3-Buckets möglich ist:

l Der Swift- oder S3-Benutzer muss der Bucket-Eigentümer sein.

l Der Swift- oder S3-Benutzer muss der Benutzer-ACL für den Bucket hinzugefügtworden sein.

Für den Zugriff auf Swift-Container muss eine der folgenden Bedingungen erfüllt sein:

l Der S3- oder Swift-Benutzer muss der Container-Eigentümer sein.

l Der S3-Benutzer muss auch ein Swift-Benutzer und als solcher einer Swift-Gruppe hinzugefügt worden sein. Die Swift-Gruppe muss als benutzerdefinierteGruppe hinzugefügt werden, es sei denn, der Benutzer ist Mitglied der Swift-Gruppe admin, die den benutzerdefinierten Gruppen automatisch hinzugefügtwird.

l Der Swift-Benutzer muss einer Gruppen-ACL für den Container hinzugefügtworden sein, oder der Benutzer muss Mitglied der Swift-Gruppe admin sein, dieden benutzerdefinierten Gruppen automatisch hinzugefügt wird.

Hinweis

Es ist nicht möglich, ein Swift DLO-Objekt über die S3-API zu lesen, da die Anfrage fürden Lesevorgang einem generischen Codepfad folgt und dabei denMetadatenschlüssel X-Object-Manifest übergeht, mit dem das Objekt von seinenursprünglichen Pfaden zurückverfolgt werden könnte.

Hinweis

Bei einem MPU-Upload schlägt der Vorgang list parts fehl, da die Teilressource '?uploadId=<uploadId>' nicht verstanden wird.

Erstellen und Managen von geheimen SchlüsselnBenutzer der ECS-Objektservices benötigen einen geheimen Schlüssel für dieAuthentifizierung bei einem Service.

Geheime Schlüssel können auf die folgenden Weisen erstellt und für Objektbenutzerzur Verfügung gestellt werden:

l Ein Administrator erstellt einen Schlüssel und verteilt ihn an den Objektbenutzer(Erstellen eines Schlüssels für einen Objektbenutzer auf Seite 46).

l Ein Domainbenutzer richtet ein Objektbenutzerkonto ein, und zwar durchErstellung eines neuen geheimen Schlüssels mithilfe der Selfservice-API, die vonder ECS Management-REST-API bereitgestellt wird (Erstellen eines geheimen S3-Schlüssels: Selfservice auf Seite 47).

Es ist möglich, 2 geheime Schlüssel für einen Benutzer zu haben. Beim Wechsel einesgeheimen Schlüssels (manchmal als Rollover bezeichnet) kann eine Ablaufzeit inMinuten für den alten Schlüssel festgelegt werden. Beide Schlüssel werden währenddes Ablaufintervalls für Anforderungen akzeptiert. Daraus ergibt sich eineToleranzperiode, in der eine Anwendung aktualisiert werden kann, sodass sie künftigden neuen Schlüssel verwendet.

S3

Erstellen und Managen von geheimen Schlüsseln 45

Erstellen eines Schlüssels für einen ObjektbenutzerECS-Managementbenutzer können einen geheimen Schlüssel für einenObjektbenutzer erstellen.

l Generieren eines geheimen Schlüssels im ECS Portal auf Seite 46

l Erstellen eines geheimen S3-Schlüssels mit der ECS Management-REST-API aufSeite 46

Weitere Informationen zu ECS-Benutzern finden Sie im ECS-Administrationshandbuchauf der Seite „ECS-Produktdokumentation“.

Generieren eines geheimen Schlüssels im ECS PortalSie können einen geheimen Schlüssel im ECS Portal generieren.

Bevor Sie beginnen

l Dazu müssen Sie ECS-Systemadministrator oder Namespace-Administrator sein.

Wenn Sie Systemadministrator sind, können Sie einen geheimen Schlüssel für einenObjektbenutzer erstellen, der einem beliebigen Namespace angehört. Wenn SieNamespace-Administrator sind, können Sie einen geheimen Schlüssel für einenObjektbenutzer erstellen, der Ihrem Namespace angehört.

Vorgehensweise

1. Wählen Sie im ECS Portal die Seite Manage > Users aus.

2. Wählen Sie in der Tabelle „Object Users“ die Option New Object User aus oderwählen Sie Edit für einen vorhandenen Benutzer aus, dem Sie einen geheimenSchlüssel zuweisen möchten.

3. Wählen Sie für S3 Generate & Add Password aus.

Um einen geheimen Schlüssel für einen Benutzer zu ändern, können Sie einenzweiten geheimen Schlüssel generieren und angeben, wann der erste Schlüsselabläuft.

4. Kopieren Sie den generierten Schlüssel und senden Sie ihn per E-Mail an denObjektbenutzer.

Erstellen eines geheimen S3-Schlüssels mit der ECS Management-REST-APIMit der ECS Management-REST-API kann ein Managementbenutzer einen geheimenSchlüssel für einen S3-Objektbenutzer erstellen.

Die API sieht wie folgt aus:


/object/user-secret-keys/{uid} API, die das Zuweisen von geheimenSchlüsseln zu Objektbenutzern und dasManagen von geheimen Schlüsselnermöglicht.

Ein Namespace-Administrator kann Schlüsselfür Benutzer in seinem Namespace erstellen.Ein Systemadministrator kann Benutzern ineinem beliebigen Namespace Schlüsselzuweisen.

S3




Um einen Schlüssel zu ändern, kann einzweiter Schlüssel zugewiesen werden, undder Zeitpunkt, an dem der erste Schlüsselabläuft, kann festgelegt werden.

Weitere Informationen zum API-Aufruf finden Sie in der ECS-API-Referenz.

Erstellen eines geheimen S3-Schlüssels: SelfserviceSie können mithilfe der ECS Management-REST-API zulassen, dass authentifizierteDomainbenutzer einen geheimen Schlüssel anfordern, der ihnen den Zugriff auf denObjektspeicher ermöglicht.

Sie können die ECS-API-Referenz verwenden, wenn Sie einen benutzerdefiniertenClient zum Durchführen bestimmter ECS-Managementvorgänge erstellen möchten.Für einfache Vorgänge können Domainbenutzer Curl oder einen browserbasiertenHTTP-Client verwenden, um die API zum Erstellen eines geheimen Schlüsselsauszuführen.

Wenn ein Benutzer die object/secret-keys-API ausführt, erstellt ECSautomatisch einen Objektbenutzer und weist einen geheimen Schlüssel zu.


/object/secret-keys API, die es S3-Clientbenutzern ermöglicht,einen neuen geheimen Schlüssel zu erstellen,mit dem sie auf Objekte und Buckets innerhalbihres Namespace zugreifen können.

Dies wird auch als Selfservice-API bezeichnet.

Die Nutzlast für /object/secret-keys kann eine optionale vorhandeneSchlüsselablaufzeit enthalten.

<secret_key_create_param> <existing_key_expiry_time_mins></existing_key_expiry_time_mins> </secret_key_create_param>

Wenn Sie zum ersten Mal einen geheimen Schlüssel erstellen, können Sie denParameter „existing_key_expiry_time_mins“ auslassen. Ein Aufruf würde dann wiefolgt aussehen:

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>

S3

Erstellen eines geheimen S3-Schlüssels: Selfservice 47



Arbeiten mit Selfservice-SchlüsselnDie nachfolgenden Beispiele helfen Ihnen dabei, die ECS-Management-REST-API beimErstellen, Lesen und Verwalten von geheimen Schlüsseln zu verwenden.

Zur Durchführung von Vorgängen mit geheimen Schlüsseln müssen Sie sich zunächstmit der Management-API authentifizieren. In den Beispielen wird das curl-Toolverwendet.

l Anmelden als Domainbenutzer auf Seite 48

l Generieren des ersten Schlüssels auf Seite 48

l Generieren des zweiten Schlüssels auf Seite 49

l Überprüfen von Schlüsseln auf Seite 49

l Löschen aller geheimen Schlüssel auf Seite 49 .

Anmelden als DomainbenutzerSie können sich als Domainbenutzer anmelden und ein Authentifizierungstokenabrufen, das für die Authentifizierung nachfolgender Anforderungen verwendetwerden kann.

curl -ik -u [email protected]:<Password> https://10.241.48.31:4443/loginHTTP/1.1 200 OKDate: Mon, 27 Apr 2015 17:29:38 GMTContent-Type: application/xmlContent-Length: 107Connection: keep-aliveX-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn><user>[email protected]</user></loggedIn>

Generieren des ersten SchlüsselsSie können einen geheimen Schlüssel generieren.

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -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/[email protected]"/> <secret_key>7hXZ9/EHTVvmFuYly/z3gHpihXtEUX/VZxdxDDBd</secret_key> <key_expiry_timestamp/> <key_timestamp>2015-04-27 17:39:13.813</key_timestamp></user_secret_key>

S3


Generieren des zweiten SchlüsselsSie können einen zweiten geheimen Schlüssel generieren und das Ablaufdatum für denersten Schlüssel festlegen.

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -H "Content-Type: application/json" -X POST -d "{\"existing_key_expiry_time_mins\": \"10\"}" 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/[email protected]"/> <secret_key>l3fPCuFCG/bxoOXCPZoYuPwhXrSTwU0f1kFDaRUr</secret_key> <key_expiry_timestamp/> <key_timestamp>2015-04-27 17:40:12.506</key_timestamp></user_secret_key>

Überprüfen von SchlüsselnSie können die Schlüssel überprüfen, die Ihnen zugewiesen wurden. In diesem Fall sindzwei Schlüssel vorhanden, von denen der erste ein Ablaufdatum und eine Ablaufzeithat.

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" https://10.241.48.31:4443/object/secret-keys | xmllint --format -<?xml version="1.0" encoding="UTF-8" standalone="yes"?><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>

Löschen aller geheimen SchlüsselWenn Sie Ihre geheimen Schlüssel löschen müssen, bevor Sie sie erneut generieren,können Sie Folgendes verwenden.

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -H "Content-Type: application/json" -X POST -d "{}" https://10.241.48.31:4443/object/secret-keys/deactivate

S3

Erstellen eines geheimen S3-Schlüssels: Selfservice 49

Authentifizierung mit dem S3-ServiceDer ECS-S3-Service ermöglicht die Authentifizierung mit Signature-Version 2 undSignature-Version 4. Dieses Thema umfasst alle ECS-spezifischen Aspekte desAuthentifizierungsprozesses.

Amazon S3 verwendet eine Autorisierungskopfzeile, die in allen Anforderungenvorhanden sein muss, um den Benutzer zu identifizieren und eine Signatur für dieAnforderung bereitzustellen. Das Format der Autorisierungskopfzeile unterscheidetzwischen der Authentifizierung mit Signature-Version 2 und Signature-Version 4.

Um eine Autorisierungskopfzeile zu erstellen, benötigen Sie eine AWS-Zugriffsschlüssel-ID und einen geheimen Zugriffsschlüssel. In ECS ist die AWS-Zugriffsschlüssel-ID der ECS-UID (User ID, Benutzer-ID) zugeordnet. Eine AWS-Zugriffsschlüssel-ID hat 20 Zeichen (einige S3-Clients wie der S3-Browser prüfendies), aber der ECS-Datenservice hat keine derartige Beschränkung.

Die Authentifizierung mithilfe von Signature-Version 2 und Signature-Version 4 wirdhier eingeführt:

l Authentifizierung mithilfe von Signature-Version 2

l Authentifizierung mithilfe von Signature-Version 4

Es gelten die folgenden Hinweise:

l Im ECS-Objektdatenservice kann die UID (über die ECS-API oder die ECS-Benutzeroberfläche) mit 2 geheimen Schlüsseln konfiguriert werden. Der ECS-Datenservice versucht, den ersten geheimen Schlüssel zu verwenden, und wenndie berechnete Signatur nicht damit übereinstimmt, versucht sie, den zweitengeheimen Schlüssel zu verwenden. Wenn der zweite Schlüssel fehlschlägt, wirddie Anforderung abgelehnt. Wenn Benutzer den geheimen Schlüssel hinzufügenoder ändern, sollte vor Verwendung des neuen geheimen Schlüssels 2 Minutengewartet werden, damit alle Datenservice-Nodes mit dem neuen geheimenSchlüssel aktualisiert werden können, bevor dieser verwendet wird.

l Im ECS-Datenservice wird auch der Namespace in die HMAC-Signaturberechnungeinbezogen.

Authentifizierung mithilfe von Signature-Version 2

Die Autorisierungskopfzeile bei Verwendung von Signature-Version 2 sieht wie folgtaus:

Authorization: AWS <AWSAccessKeyId>:<Signature>

Beispiel:

GET /photos/puppy.jpg?AWSAccessKeyId=user11&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1Host: myco.s3.amazonaws.comDate: Mon, 26 Mar 2007 19:37:58 +0000

Die Authentifizierung mithilfe von Signature-Version 2 wird hier beschrieben:

l http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

S3


http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

Authentifizierung mithilfe von Signature-Version 4

Die Autorisierungskopfzeile bei Verwendung von Signature-Version 4 sieht wie folgtaus:

Authorization: AWS4-HMAC-SHA256 Credential=user11/20130524/us/s3/aws4_request, SignedHeaders=host;range;x-amz-date,Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024

Die Anmeldedatenkomponente besteht aus der Zugriffsschlüssel-ID gefolgt vomUmfang der Anmeldedaten. Der Umfang der Anmeldedaten besteht aus Datum/Region/Servicename/Beendigungszeichenfolge. Bei ECS lautet der Servicenameimmer „s3“ und die Region kann eine beliebige Zeichenfolge sein. Bei Berechnung derSignatur verwendet ECS die vom Client übergebene Regionszeichenfolge.

Die Authentifizierung mithilfe von Signature-Version 4 wird hier beschrieben:

l http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html und

l http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

Ein Beispiel für eine PUT-Bucket-Anforderung über Signature-Version 4 ist imFolgenden aufgeführt:

PUT /bucket_demo HTTP/1.1x-amz-date: 20160726T033659ZAuthorization: AWS4-HMAC-SHA256 Credential=user11/20160726/us/s3/aws4_request,SignedHeaders=host;x-amz-date;x-emc-namespace,Signature=e75a150daa28a2b2f7ca24f6fd0e161cb58648a25121d3108f0af5c9451b09cex-emc-namespace: ns1x-emc-rest-client: TRUEx-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855Content-Length: 0Host: 10.247.195.130:9021Connection: Keep-AliveUser-Agent: Apache-HttpClient/4.2.1 (java 1.5)

Antwort:

HTTP/1.1 200 OKDate: Tue, 26 Jul 2016 03:37:00 GMTServer: ViPR/1.0x-amz-request-id: 0af7c382:156123ab861:4192:896x-amz-id-2: 3e2b2280876d444d6c7215091692fb43b87d6ad95b970f48911d635729a8f7ffLocation: /bucket_demo_2016072603365969263Content-Length: 0

Verwenden der s3curl mit ECSEine geänderte Version der s3curl ist für die Verwendung mit ECS erforderlich.

Bei Verwendung benutzerdefinierter ECS-Header (X-Emc) muss das Signaturelementdes Autorisierungsheaders so eingerichtet werden, dass die benutzerdefinierten

S3

Verwenden der s3curl mit ECS 51

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

Header enthalten sind. Darüber hinaus sind bei der Verbindung mit ECS 3.0 oder höherdie Parameter "search" und "searchmetadata" Teil der Signaturberechnung.

Sie können eine geänderte, ECS-spezifische Version der s3curl, die auf dieHandhabung dieser Bedingungen ausgelegt ist, aus dem EMCECS Git Repositoryabrufen.

Verwenden von SDKs für den Zugriff auf den S3-ServiceFür das Entwickeln von Anwendungen, die mit dem ECS-S3-Service kommunizieren,steht eine Reihe von SDKs zur Verfügung, die Ihre Entwicklungsaktivität unterstützen.

Die ECS-Community stellt Informationen zu den verschiedenen verfügbaren Clientsbereit und gibt Hilfestellung zu deren Verwendung: ECS CommunityEntwicklerressourcen.

In den folgenden Themen wird die Verwendung des Amazon S3 SDK und des ECS JavaSDK beschrieben.

l Verwenden des Java Amazon SDK auf Seite 52

l Java SDK-Client für ECS auf Seite 54

Hinweis

Wenn Sie die ECS-API-Erweiterungen nutzen möchten (siehe S3-Erweiterungen aufSeite 25), finden Sie Unterstützung für diese Erweiterungen im ECS Java SDK. WennSie keine Unterstützung für die ECS-Erweiterungen benötigen bzw. keinevorhandenen Anwendungen haben, die diese verwenden, können Sie das Amazon JavaSDK verwenden.

Hinweis

Die Kompatibilität des ECS-Java-SDK mit der Erweiterung für Metadatensuche wird in Verwenden der Metadatensuche aus dem ECS-Java-SDK auf Seite 42 beschrieben.

Verwenden des Java Amazon SDKSie können auf ECS-Objektspeicher mithilfe des Java-S3 SDK zugreifen.

Standardmäßig ist das AmazonS3Client-Objekt so konfiguriert, dass es direkt mitamazon.com zusammenarbeitet. In diesem Abschnitt wird gezeigt, wie Sie denAmazonS3Client für die Zusammenarbeit mit ECS konfigurieren.

Um eine Instanz des AmazonS3Client-Objekts zu erstellen, müssen Sie dieAnmeldedaten daran weiterleiten. Zu diesem Zweck erstellen Sie ein AWSCredentials-Objekt und leiten den AWS-Zugriffsschlüssel (Ihren ECS-Benutzernamen) und Ihrenfür ECS generierten geheimen Schlüssel daran weiter.

Im folgenden Code-Snippet wird gezeigt, wie dieser Vorgang eingerichtet wird.

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));

Standardmäßig versucht der Amazon-Client, mit Amazon WebServices zukommunizieren. Um dieses Verhalten zu übersteuern und ECS zu kontaktieren,müssen Sie einen spezifischen Endpunkt festlegen.

S3


https://github.com/EMCECS/s3curl

https://community.emc.com/community/products/ecs#developer

https://community.emc.com/community/products/ecs#developer

Sie können den Endpunkt mithilfe der setEndpoint-Methode festlegen. Das Protokoll,das am Endpunkt angegeben wird, bestimmt, ob der Client an den HTTP-Port (9020)oder an den HTTPS-Port (9021) weitergeleitet werden soll.

Hinweis

Wenn Sie den HTTPS-Port verwenden möchten, muss das JDK Ihrer Anwendungeingerichtet werden, um das ECS-Zertifikat erfolgreich zu validieren. Andernfalls gibtder Client SSL-Überprüfungsfehler aus und kann nicht verbunden werden.

Im Code-Snippet unten wird der Client verwendet, um über HTTP auf ECSzuzugreifen:

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));client.setEndpoint("http://ecs1.emc.com:9020");

Wenn Sie die Pfadadressierung verwenden (ecs1.emc.com/mybucket), müssen Sie diesetPathStyleAccess-Option wie unten gezeigt festlegen:

S3ClientOptions options = new S3ClientOptions();options.setPathStyleAccess(true);

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));client.setEndpoint("http://ecs1.emc.com:9020");client.setS3ClientOptions(options);

Der folgende Code zeigt, wie Objekte in einem Bucket aufgelistet werden.

ObjectListing objects = client.listObjects("mybucket");for (S3ObjectSummary summary : objects.getObjectSummaries()) { System.out.println(summary.getKey()+ " "+summary.getOwner());}

Der CreateBucket-Vorgang unterscheidet sich von anderen Vorgängen dadurch, dassdie Festlegung eines Bereichs erwartet wird. Bei S3 würde so das Rechenzentrumangegeben, in dem der Bucket erstellt werden soll. ECS unterstützt jedoch keineBereiche. Wenn also der CreateBucket-Vorgang aufgerufen wird, wird derStandardbereich angegeben. Dadurch wird der AWS-Client davon abgehalten, dieAmazon-Bereichskonfigurationsdatei von Amazon CloudFront herunterzuladen.

client.createBucket("mybucket", "Standard");

Das vollständige Beispiel für die Kommunikation mit dem ECS-S3-Datenservice, dieErstellung eines Buckets und die Bearbeitung eines Objekts wird nachfolgend gezeigt.

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

S3

Verwenden des Java Amazon SDK 53

public static File objectFile = new File("/photos/cat1.jpg");

public static void main(String[] args) throws Exception {

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));

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); listObjects(client);

client.copyObject(bucketName,objectFile.getName(),bucketName, "copy-" + objectFile.getName()); listObjects(client); }

public static void listObjects(AmazonS3Client client) { ObjectListing objects = client.listObjects(bucketName); for (S3ObjectSummary summary : objects.getObjectSummaries()) { System.out.println(summary.getKey()+ " "+summary.getOwner()); } }}

Java SDK-Client für ECSDas ECS Java SDK baut auf dem Amazon S3 Java SDK auf und unterstützt die ECS-API-Erweiterungen.

Ein Beispiel für die Verwendung des ViPR S3-Clients ist nachfolgend dargestellt.

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 = “[email protected]”; String secretKey = “pcQQ20rDI2DHZOIWNkAug3wK4XJP9sQnZqbQJev3”; BasicAWSCredentials creds = new BasicAWSCredentials(accessKey, secretKey); ViPRS3Client client = new ViPRS3Client(endpoint, creds);

}

S3


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) { } }}

S3

Java SDK-Client für ECS 55

S3


TEIL 2

OpenStack Swift

Kapitel 2, "OpenStack Swift"

OpenStack Swift 57

OpenStack Swift


KAPITEL 2

OpenStack Swift

l OpenStack Swift-Support in ECS...................................................................... 60l Von OpenStack Swift unterstützte Vorgänge.................................................... 60l Swift-Erweiterungen..........................................................................................62l Erweiterungen für den Swift-Bytebereich..........................................................62l Aufbewahrung....................................................................................................66l File System Enabled........................................................................................... 67l S3 und Swift-Interoperabilität............................................................................68l OpenStack Swift-Authentifizierung................................................................... 68l Autorisierung für Container................................................................................ 77

OpenStack Swift 59

OpenStack Swift-Support in ECSECS bietet Unterstützung für die OpenStack Swift-API und kann Swift in einerOpenStack-Umgebung ersetzen. In diesem Abschnitt werden die unterstütztenVorgänge beschrieben und die Mechanismen zur Autorisierung und Authentifizierungerläutert.

Der OpenStack Swift-Service wird auf den folgenden Ports zur Verfügung gestellt.

Protokoll Ports

HTTP 9024

HTTPS 9025

ECS unterstützt die OpenStack Swift-API und kann mit Anwendungen, die diese APIunterstützen, verwendet werden. In den folgenden Themen werden die unterstütztenMethoden, die ECS-Erweiterung und der Mechanismus für die Authentifizierungbeschrieben:

l Von OpenStack Swift unterstützte Vorgänge auf Seite 60

l Swift-Erweiterungen auf Seite 62

l OpenStack Swift-Authentifizierung auf Seite 68

l Autorisierung für Container auf Seite 77

Verwendungsbeispiele für die OpenStack Swift-API finden Sie hier:

l Beispiele für die OpenStack-API

In einer OpenStack-Umgebung kann ECS als Ersatz für die OpenStack Swift-Komponente oder parallel zu einer vorhandenen OpenStack Swift-Installationverwendet werden. Zwar kann ECS mit jeder OpenStack-Verteilung verwendetwerden, aber es wurde es mit Mirantis OpenStack 9.1 getestet. Bitte beachten Sie,dass ECS als Swift-Ersatz für Endbenutzer-Objektspeicher und nicht als Glance-Backend getestet wurde.

Wenn Sie OpenStack mit ECS verwenden, müssen Sie ECS so konfigurieren, dass esOpenStack-Benutzer authentifizieren kann. Weitere Informationen zur Konfigurationder Authentifizierung finden Sie unter Authentifizierung mithilfe von ECSKeystone V3-Integration.

Von OpenStack Swift unterstützte VorgängeIm folgenden Abschnitt werden die Anforderungen der OpenStack REST-APIaufgelistet, die von ECS unterstützt werden.

l Unterstützte OpenStack Swift-Aufrufe auf Seite 60

l Nicht unterstützte OpenStack Swift-Aufrufe auf Seite 62

Diese Informationen sind dem Abschnitt „Object Storage API V1“ der OpenStack APIReference-Dokumentation entnommen.

Unterstützte OpenStack Swift-AufrufeDie folgenden Aufrufe der OpenStack Swift-REST-API werden in ECS unterstützt.

OpenStack Swift


http://docs.openstack.org/api/openstack-object-storage/1.0/content/ch_object-storage-dev-troubleshooting.html

http://developer.openstack.org/api-ref-objectstorage-v1.html

http://developer.openstack.org/api-ref-objectstorage-v1.html

Tabelle 10 Von OpenStack Swift unterstützte Aufrufe

Methode Pfad Beschreibung

GET v1/{account} Ruft eine Liste von vorhandenen Speichercontainernnach Namen sortiert ab.

POST v1/{account} Erstellt oder aktualisiert die Kontometadaten, indembenutzerdefinierte Metadatenkopfzeilen der URI aufContainerebene zugeordnet werden. DieseKopfzeilen müssen das Format „X-Account-Meta-*“aufweisen.

GET v1/{account}/{container}

Ruft eine Liste der im Container gespeichertenObjekte ab.

PUT v1/{account}/{container}

Erstellt einen Container.

DELETE v1/{account}/{container}

Löscht einen leeren Container.

POST v1/{account}/{container}

Erstellt oder aktualisiert die beliebigenContainermetadaten, indem benutzerdefinierteMetadatenkopfzeilen der URI auf Containerebenezugeordnet werden. Diese Kopfzeilen müssen dasFormat „X-Container-Meta“ aufweisen *.

HEAD v1/{account}/{container}

Ruft die Containermetadaten ab. Umfasst derzeitnicht die Objektanzahl und verwendeten Byte.Der Benutzer benötigt Administratorrechte.

GET v1/{account}/{container}/{object}

Ruft die Daten des Objekts ab.

Hinweis

Der Abruf eines Bereichs (GET range) ist bei einemSLO (Static Large Object) nicht möglich, wenn dieSegmente vor ECS 3.0 erstellt wurden.

PUT v1/{account}/{container}/{object}

Schreibt oder überschreibt den Inhalt und dieMetadaten eines Objekts.Wird verwendet, um ein vorhandenes Objekt mithilfeder X-Copy-From-Kopfzeile zum Festlegen derQuelle an ein anderes Objekt zu kopieren

Bei einem DLO (Dynamic Large Object) oder SLO(Static Large Object) kann das Objekt ein Manifestsein, wie hier beschrieben.

DELETE v1/{account}/{container}/{object}

Entfernt ein Objekt dauerhaft aus demSpeichersystem. In Kombination mit dem COPY-Befehl können Sie COPY then DELETE verwenden,um ein Objekt effektiv zu verschieben.

HEAD v1/{account}/{container}/{object}

Ruft Objektmetadaten und andere Standard-HTTP-Kopfzeilen ab.

POST v1/{account}/{container}/{object}

Legt beliebige Objektmetadaten fest undüberschreibt sie. Diese Metadaten müssen das

OpenStack Swift

Von OpenStack Swift unterstützte Vorgänge 61

http://docs.openstack.org/developer/swift/api/large_objects.html#static-large-objects

Tabelle 10 Von OpenStack Swift unterstützte Aufrufe (Fortsetzung)


Format „X-Object-Meta“ aufweisen *. Auch „X-Delete-At“ oder „X-Delete-After“ für ablaufendeObjekte kann von diesem Vorgang zugewiesenwerden Andere Kopfzeilen wie „Content-Type“können jedoch durch diesen Vorgang nicht geändertwerden.

Tabelle 11 Zusätzliche Funktionen

Feature Anmerkungen

Temporäre URLs ECS unterstützt die Verwendung temporärer URLs, die esBenutzern ermöglichen, ohne Anmeldedaten Zugriff aufObjekte zu erhalten.

Weitere Informationen finden Sie hier.

Nicht unterstützte OpenStack Swift-AufrufeDie folgenden Aufrufe der OpenStack Swift-REST-API werden in ECS nichtunterstützt.

Tabelle 12 Von OpenStack Swift nicht unterstützte Aufrufe


COPY v1/{account}/{container}/{object}

Der Copy-Vorgang kann durchgeführt werdenmithilfe von „PUT v1/{account}/{container}/{object}“ mit der Kopfzeile „X-Copy-From“.

HEAD v1/{account} Ruft die Kontometadaten ab. Nicht vollständigunterstützt mit der Rückgabe null für diegespeicherten Bytes (X-Account-Bytes-Used).

Swift-ErweiterungenECS unterstützt eine Reihe von Erweiterungen für die Swift-API.

Die Erweiterungen und die unterstützenden APIs sind im Folgenden aufgeführt.

l Erweiterungen für den Swift-Bytebereich auf Seite 62

l Aufbewahrung auf Seite 66

l File System Enabled auf Seite 67

Erweiterungen für den Swift-Bytebereich

Die folgenden Erweiterungen für den Bytebereich sind verfügbar:

l Aktualisieren eines Bytebereichs innerhalb eines Objekts auf Seite 63

l Überschreiben eines Teils eines Objekts auf Seite 64

OpenStack Swift


https://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html

l Anhängen von Daten an ein Objekt auf Seite 65l Lesen mehrerer Bytebereiche innerhalb eines Objekts auf Seite 66

Aktualisieren eines Bytebereichs innerhalb eines ObjektsSie können mit ECS-Erweiterungen für das Swift-Protokoll einen Bytebereichinnerhalb eines Objekts aktualisieren.

Die Teilaktualisierung eines Objekts ist in vielen Fällen sehr nützlich, beispielsweise zurÄnderung eines binären Headers am Anfang einer großen Datei. Auf Swift oderanderen Swift-kompatiblen Plattformen muss die vollständige Datei erneut gesendetwerden.

Das folgende Beispiel veranschaulicht die Aktualisierung eines Bytebereichs. In diesemBeispiel hat object1 den Wert The quick brown fox jumps over the lazydog..

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:04:40 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:9qxKiHt2H7upUDPF86dvGp8VdvI=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:04:40 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:04:28 GMTETag: 6Content-Type: application/jsonContent-Length: 43 The quick brown fox jumps over the lazy dog.

Zur Aktualisierung eines bestimmten Bytebereichs in diesem Objekt muss der Header"Range" in der Objektdatenanforderung den Anfangs- und den End-Offset des zuaktualisierenden Objekts umfassen. Das Format lautet wie folgt: Range:bytes=<startOffset>-<endOffset>.

Im folgenden Beispiel umfasst die PUT-Anforderungsmethode den Header "Range"mit dem Wert bytes=10-14, d. h., dass die Bytes 10, 11, 12, 13 und 14 durch den inder Anforderung gesendeten Wert ersetzt werden. Hier wird der neue Wert greengesendet.

PUT /container1/object1 HTTP/1.1Content-Length: 5Range: bytes=10-14ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:15:16 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:xHJcAYAEQansKLaF+/4PdLBHyaM=Accept-Encoding: gzip, deflate, compress green HTTP/1.1 204 No ContentETag: 10x-amz-id-2: object1

OpenStack Swift

Aktualisieren eines Bytebereichs innerhalb eines Objekts 63

x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52aContent-Length: 0Date: Mon, 17 Jun 2013 20:15:16 GMT

Wenn das Objekt erneut gelesen wird, lautet der neue Wert jetzt The quick greenfox jumps over the lazy dog.. Ein bestimmter Bytebereich in diesem Objektwurde aktualisiert; dabei wurde das Wort brown durch das Wort green ersetzt.

GET /container1/object1 HTTP/1.1Cookie: JSESSIONID=wdit99359t8rnvipinz4tbtuACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:16:00 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:OGVN4z8NV5vnSAilQTdpv/fcQzU=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:16:00 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:15:16 GMTETag: 10Content-Type: application/jsonContent-Length: 43 The quick green fox jumps over the lazy dog.

Überschreiben eines Teils eines ObjektsSie können mit ECS-Erweiterungen für das Swift-Protokoll Teile eines Objektsüberschreiben.

Geben Sie zum Überschreiben eines Objektteils die Daten an, die geschrieben werdensollen, sowie den Anfangs-Offset. Die Daten in der Anforderung werden ab demangegebenen Offset geschrieben. Das Format lautet wie folgt: Range:<startingOffset>-Um beispielsweise die Daten brown cat ab Offset 10 zu schreiben, geben Sie diefolgende PUT-Anfrage aus:

PUT /container1/object1 HTTP/1.1Content-Length: 9Range: bytes=10-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:51:41 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:uwPjDAgmazCP5lu77Zvbo+CiT4Q=Accept-Encoding: gzip, deflate, compress brown cat HTTP/1.1 204 No ContentETag: 25x-amz-id-2: object1x-amz-request-id: 65be45c2-0ee8-448a-a5a0-fff82573aa3bContent-Length: 0Date: Mon, 17 Jun 2013 20:51:41 GMT

OpenStack Swift


Wenn das Objekt abgerufen wird, wurde ein Teil der Daten am angegebenen Anfangs-Offset ersetzt (green fox wurde ersetzt durch brown cat) und der Endwertlautet: The quick brown cat jumps over the lazy dog and cat.

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTETag: 25Content-Type: application/jsonContent-Length: 51 The quick brown cat jumps over the lazy dog and cat.

Anhängen von Daten an ein ObjektSie können mit ECS-Erweiterungen für das Swift-Protokoll Daten an ein Objektanhängen.

In einigen Fällen müssen Sie Daten an ein Objekt anhängen, können den genauen Byte-Offset aber nicht effizient bestimmen. Für dieses Szenario bietet ECS die Möglichkeit,Daten ohne Angabe eines Offsets an das Objekt anzuhängen (der richtige Offset wirdin der Antwort angegeben). Um beispielsweise einer Protokolldatei Zeilenhinzuzufügen, müssen Sie bei Swift oder anderen Swift-kompatiblen Plattformen dievollständige Protokolldatei erneut senden.

Zum Anhängen von Daten an ein Objekt wird ein "Range"-Header mit dem Sonderwertbytes=-1- verwendet. Auf diese Weise wird das Objekt erweitert, ohne dass dieGröße des vorhandenen Objekts bekannt ist. Das Format lautet wie folgt: Range:bytes=-1-Das folgende Beispiel zeigt eine Beispielanforderung zum Anhängen von Daten an einvorhandenes Objekt mit dem "Range"-Wert bytes=-1-. Hier wird der Wert andcat in der Anforderung gesendet.

PUT /container1/object1 HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/sqOFL65riEBSWLg6t8hL0DFW4c=Accept-Encoding: gzip, deflate, compress and cat HTTP/1.1 204 No ContentETag: 24x-amz-id-2: object1x-amz-request-id: 087ac237-6ff5-43e3-b587-0c8fe5c08732Content-Length: 0Date: Mon, 17 Jun 2013 20:46:01 GMT

OpenStack Swift

Anhängen von Daten an ein Objekt 65


GET /container1/object1 HTTP/1.1ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:56 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:D8FSE8JoLl0MTQcFmd4nG1gMDTg=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:46:56 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:46:01 GMTETag: 24Content-Type: application/jsonContent-Length: 51 The quick green fox jumps over the lazy dog and cat.

Lesen mehrerer Bytebereiche innerhalb eines ObjektsSie können mit ECS-Erweiterungen für das Swift-Protokoll mehrere Bytebereicheinnerhalb eines Objekts lesen

Mehrere Teile eines Objekts zu lesen ist in vielen Fällen sehr nützlich, beispielsweiseum mehrere Teile eines Videos abzurufen. Bei Swift oder anderen Swift-kompatiblenPlattformen ist es erforderlich, für jeden Teil eine gesonderte Anfrage zu senden.

Um zwei bestimmte Bytebereiche innerhalb des Objekts object1 zu lesen, tätigenSie die folgende GET-Anforderung für Range: bytes==4-8,41-44. DieLeseantwort gilt dann für die Wörter quick und lazy.

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcRange: bytes==4-8,41-44Content-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 206 Partial ContentDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: multipart/byteranges;boundary=bound04acf7f0ae3cccLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTContent-Length: 230 --bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 4-8/50quick--bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 41-44/50lazy--bound04acf7f0ae3ccc--

Aufbewahrung

OpenStack Swift


Der ECS-Swift-Head unterstützt die Aufbewahrung von Objekten, um deren Löschungoder Änderung über einen bestimmten Zeitraum zu verhindern. Dies ist eine ECS-Erweiterung, die in der Standard-Swift-API nicht verfügbar ist.

Die Aufbewahrung kann wie folgt festgelegt werden:

Aufbewahrungsfrist für Objekt

Speichert eine Aufbewahrungsfrist mit dem Objekt. Die Aufbewahrungsfrist wirdmithilfe eines Headers x-emc-retention-period für das Objekt festgelegt.

Aufbewahrungs-Policy für Objekt

Für das Objekt kann eine Aufbewahrungs-Policy und für den Namespace die mitder Policy verknüpfte Aufbewahrungsfrist festgelegt werden. Auf diese Weisekann für die Aufbewahrungsfrist für eine Gruppe von Objekten mithilfe einerPolicy derselbe Wert festgelegt werden. Dieser kann durch Ändern der Policy füralle Objekte geändert werden. Die Verwendung einer Policy bietet eine sehr vielhöhere Flexibilität als das Anwenden der Aufbewahrungsfrist auf ein Objekt.Darüber hinaus können mehrere Aufbewahrungs-Policies für einen Namespacefestgelegt werden, sodass für verschiedene Gruppen von Objektenunterschiedliche Aufbewahrungsfristen gelten.Die Aufbewahrungs-Policy, die mit einem Header x-emc-retention-policyauf ein Objekt angewendet wird, und die Aufbewahrungsfrist der Policy müssenmit der ECS-Management-REST-API (oder über das ECS-Portal) festgelegtwerden.

Aufbewahrungsfrist für Bucket

Mit einer für einen Bucket gespeicherten Aufbewahrungsfrist wird eineAufbewahrung für alle Objekte festgelegt, wobei mit der Aufbewahrungsfrist oder-policy auf Objektlevel eine objektspezifische Einstellung vorgenommen werdenkann, wenn eine längere Aufbewahrung erforderlich ist. Die Aufbewahrungsfristwird mithilfe eines Headers x-emc-retention-period für den Bucketfestgelegt.

Wenn ein Versuch unternommen wird, das Objekt zu ändern oder zu löschen, wirdanhand der jeweils längeren (direkt für das Objekt oder über die Aufbewahrungs-Policy für das Objekt festgelegten) Aufbewahrungsfrist für den Bucket oder dasObjekt ermittelt, ob der Vorgang durchgeführt werden kann.

File System Enabled

Für Swift-Buckets kann auch FS (File System) aktiviert werden, sodass mit demSwift-Protokoll geschriebene Dateien mithilfe von Dateiprotokollen wie NFS undHDFS gelesen werden können und umgekehrt.

Aktivieren des FS-ZugriffsSie können den Dateisystemzugriff beim Erstellen eines Buckets mit dem Swift-Protokoll über den Header x-emc-file-system-access-enabled aktivieren. DerDateisystemzugriff kann auch aktiviert werden, wenn Sie einen Bucket über das ECS-Portal erstellen (mithilfe der ECS-Management-REST-API).

Einschränkung des FS-SupportEs gelten die folgenden Einschränkungen:

l Wenn für einen Bucket FS aktiviert ist, kann die Aufbewahrung nicht verwendetwerden.

OpenStack Swift

File System Enabled 67

Crosshead-Support für FS„Crosshead-Support“ bezieht sich auf den Zugriff auf mit einem Protokollgeschriebene Objekte mithilfe eines anderen, von ECS unterstützten Protokolls. Mitdem Swift-Head geschriebene Objekte können unter Verwendung der NFS- undHDFS-Dateisystemprotokolle gelesen und geschrieben werden.

Ein wesentlicher Aspekt des Crosshead-Support besteht in der Beziehung derObjekt-/Dateiberechtigungen zwischen Protokollen sowie beim Dateisystemzugriff inder Beziehung der Konzepte von Benutzer und Gruppe zwischen Objekt- undDateiprotokollen.

Weitere Informationen zum Crosshead-Support bei Dateisystemen finden Sie im ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.

S3 und Swift-InteroperabilitätS3- und Swift-Protokolle können so zusammenarbeiten, dass S3-Anwendungen aufObjekte in Swift-Buckets und Swift-Anwendungen auf Objekte in S3-Bucketszugreifen können.

Nähere Informationen zur Interoperabilität von Swift und S3 finden Sie unter S3 undSwift-Interoperabilität.

Hinweis

S3 und Swift-Interoperabilität ist nicht mit der Nutzung von Bucket-Policieskompatibel. Bucket-Policies gelten nur für den Bucket-Zugriff mit dem S3-Head undwerden beim Bucket-Zugriff mit der Swift-API nicht durchgesetzt.

OpenStack Swift-Authentifizierung

ECS bietet Unterstützung für verschiedene Versionen des Protokolls für eineOpenStack Swift-Authentifizierung.

V1

ECS ermöglicht es Objektbenutzern, sich mit dem ECS-Swift-Service zuauthentifizieren und ein Authentifizierungstoken zu erhalten, das beimDurchführen von nachfolgenden API-Aufrufen an den ECS Swift-Serviceverwendet werden kann. Siehe Authentifizierung mit OpenStack Version 1.0 aufSeite 70.

V2

ECS ermöglicht es Objektbenutzern, sich mit dem ECS-Swift-Service zuauthentifizieren, um ein Token mit Bereichsbeschränkung zu erhalten. Hierbeihandelt es sich um ein Token, das einem Mandanten (entspricht einem Projekt)zugeordnet ist. Dieses Token kann bei nachfolgenden API-Aufrufen an den ECSSwift-Service verwendet werden. Siehe Authentifizierung mit OpenStack Version2.0 auf Seite 72

V3

ECS validiert Keystone-V3-Benutzer, die Token vorlegen, die auf ein Keystone-Projekt beschränkt sind. Siehe Authentifizierung mithilfe von ECS Keystone V3-Integration auf Seite 73.

OpenStack Swift



Bei Protokollen der Versionen 1 und 2 erfordert der Zugriff auf den ECS-Objektspeicher mithilfe des OpenStack Swift-Protokolls ein ECS-Objektbenutzerkonto und ein Swift-Passwort.

Für Version 3 werden Benutzer erstellt und Projekten und Rollen zugewiesen.Außerhalb von ECS wird hierfür ein Keystone-V3-Service verwendet. ECS führt dieAuthentifizierung nicht aus, validiert aber das Authentifizierungstoken mit demKeystone-V3-Service.

Das Zuweisen von Swift-Anmeldedaten zu ECS-Objektbenutzern wird unter Erstellenvon Swift-Benutzern im ECS-Portal auf Seite 69 beschrieben.

Erstellen von Swift-Benutzern im ECS-PortalECS-Objektbenutzer können Anmeldedaten für den Zugriff auf den ECS-Objektspeicher mithilfe des OpenStack Swift-Protokolls erhalten.

Bevor Sie beginnenSie müssen ein ECS-Systemadministrator sein.

Weitere Informationen zum Hinzufügen von ECS-Objektbenutzern finden Sie im ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.Vorgehensweise

1. Wählen Sie im ECS-Portal Manage > Users aus.Die Seite User Management wird angezeigt.

2. Auf der Seite User Management wählen Sie entweder New Object User ausoder fügen Sie ein Swift-Passwort zu einem vorhandenen Benutzer hinzu,indem Sie die Aktion Edit für einen in der Benutzertabelle aufgeführtenBenutzer auswählen.Wenn Sie einen neuen Benutzer erstellen, geben Sie einen Namen für denBenutzer ein und wählen Sie den Namespace aus, zu dem der Benutzer gehört.

3. Geben Sie im Swift-Bereich im Feld Groups eine Gruppe ein, zu der derBenutzer gehören soll.Der Swift-Bereich ist in der folgenden Abbildung hervorgehoben.

OpenStack Swift

Erstellen von Swift-Benutzern im ECS-Portal 69


Wenn Sie die Gruppe admin angeben, können Benutzer automatisch alleContainervorgänge durchführen. Wenn Sie eine andere Gruppe angeben, mussdiese Gruppe Berechtigungen für den Container erhalten. WeitereInformationen zur Autorisierung für Container finden Sie unter Autorisierung fürContainer auf Seite 77.

4. Geben Sie ein Passwort für den Swift-Benutzer ein.

5. Wählen Sie Set Password & Groups aus.

Authentifizierung mit OpenStack Version 1.0Sie können sich mit dem ECS OpenStack Swift-Service über V1 desAuthentifizierungsprotokolls authentifizieren.

Vorgehensweise

1. Erwerben Sie eine UID und das zugehörige Passwort für einen ECS-Objektbenutzer.

Sie können diesen Schritt über das ECS-Portal ausführen (siehe Erstellen vonSwift-Benutzern im ECS-Portal auf Seite 69) oder Sie können die folgendeECS-REST-API aufrufen, um ein Passwort zu erzeugen.

Anfrage:

PUT /object/user-password/[email protected] <user_password_create> <password>myPassword</password> <namespace>EMC_NAMESPACE</namespace> </user_password_create>

Antwort:

HTTP 200

2. Rufen Sie die OpenStack-Authentifizierungs-REST-API wie unten gezeigt auf.Verwenden Sie Port 9024 für HTTP bzw. Port 9025 für HTTPS.

Anfrage:

GET /auth/v1.0 X-Auth-User: [email protected] X-Auth-Key: myPassword

Antwort:

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: ECS_e6384f8ffcd849fd95d986a0492ea9a6 Content-Length: 0

OpenStack Swift


Ergebnisse

Wenn die Benutzer-ID und das Passwort von ECS validiert wurden, werden dieSpeicher-URL und das Token in die Antwortkopfzeile zurückgegeben. WeitereAnforderungen werden authentifiziert, indem dieses Token angegeben wird. DieSpeicher-URL stellt den Hostnamen und die Ressourcenadresse bereit. Sie können aufContainer und Objekte zugreifen, indem Sie die folgende X-Storage-URL-Kopfzeilebereitstellen:

X-Storage-Url: https://{hostname}/v1/{account}/{container}/{object}

Das generierte Token läuft 24 Stunden nach der Erstellung ab. Wenn Sie dieAuthentifizierungsanforderung innerhalb des 24-Stundenzeitraums unter Verwendungderselben UID und desselben Passworts wiederholen, gibt OpenStack dasselbe Tokenzurück. Sobald der 24-Stundenablaufzeitraum abgelaufen ist, gibt OpenStack einneues Token zurück.

Im folgenden einfachen Authentifizierungsbeispiel gibt der erste REST-Aufruf ein X-Auth-Token zurück. Im zweiten REST-Aufruf wird dieses X-Auth-Token verwendet,um eine GET-Anforderung für ein Konto auszuführen.

$ curl -i -H "X-Storage-User: [email protected]" -H "X-Storage-Pass: 1fO9X3xyrVhfcokqy3U1UyTY029gha5T+k+vjLqS" http://ecs.yourco.com:9024/auth/v1.0

HTTP/1.1 204 No Content X-Storage-Url: http://ecs.yourco.com:9024/v1/s3 X-Auth-Token: ECS_8cf4a4e943f94711aad1c91a08e98435 Server: Jetty(7.6.4.v20120524)

$ curl -v -X GET -s -H "X-Auth-Token: 8cf4a4e943f94711aad1c91a08e98435" http://ecs.yourco.com:9024/v1/s3

* 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 > < HTTP/1.1 204 No Content < Date: Mon, 16 Sep 2013 19:31:45 GMT < Content-Type: text/plain * Server Jetty(7.6.4.v20120524) is not blacklisted < Server: Jetty(7.6.4.v20120524) <

OpenStack Swift

Authentifizierung mit OpenStack Version 1.0 71

* Connection #0 to host ecs.yourco.com left intact

Authentifizierung mit OpenStack Version 2.0ECS bietet eingeschränkten Support für die Authentifizierung mit OpenStackVersion 2 (Keystone).

Bevor Sie beginnen

ECS bietet eine Implementierung des OpenStack Swift V2-Identitätsservice, der dieVerwendung einer Swift-Anwendung ermöglicht, die V2-Authentifizierung verwendet,um Benutzer zu authentifizieren. Bei den Benutzern muss es sich um ECS-Objektbenutzer handeln, denen OpenStack Swift-Anmeldedaten zugewiesen wurden,die es ihnen ermöglichen, auf den ECS-Objektspeicher mithilfe des Swift-Protokollszuzugreifen.

Nur Token, die auf einen ECS-Namespace (entspricht einem Swift-Projekt)beschränkt sind, können verwendet werden, um Swift-API-Aufrufe vorzunehmen. EinToken ohne Bereichsbeschränkung kann abgerufen und für den Zugriff auf denIdentitätsservice verwendet werden, um die Mandantenidentität abzurufen, bevor Sieein auf einen Mandanten beschränktes Token und einen Serviceendpunkt erhalten.

Das Token mit Bereichseinschränkung und der Serviceendpunkt können zurAuthentifizierung bei ECS, wie im vorigen Abschnitt über die V1-Authentifizierungbeschrieben, verwendet werden.

Die beiden unten aufgeführten Artikel stellen wichtige Hintergrundinformationenbereit..

l OpenStack Keystone-Workflow und Bereichsbeschränkung für Token

l Authentifizieren bei der Admin-API

Vorgehensweise

1. Um ein Token ohne Bereichsbeschränkung von ECS abzurufen, können Sie dieAPI /v2.0/tokens verwenden sowie einen Benutzernamen und dasdazugehörige Passwort für den ECS Swift-Service bereitstellen.

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

Die Antwort gleicht dem folgenden Beispiel. Dem Token ohneBereichsbeschränkung ist eine ID vorangestellt und von ECS erzeugten Tokenist das Präfix ecs_ vorangestellt.

{"access": {"token": {"id":"ecs_d668b72a011c4edf960324ab2e87438b","expires":"1376633127950"l},"user": {"name": "sysadmin", "roles":[ ], "role_links":[ ] },"serviceCatalog":[ ] }} , }

OpenStack Swift


http://bodenr.blogspot.com/2014/03/openstack-keystone-workflow-token.html

http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_authenticate_v2.0_tokens_.html

2. Rufen Sie die Tenant-Informationen ab, die dem Token ohneBereichsbeschränkung zugeordnet sind.

curl -v http://203.0.113.10:9024/v2.0/tenants -H 'X-Auth-Token: d668b72a011c4edf960324ab2e87438b'

Die Antwort gleicht dem folgenden Beispiel.

{"tenants_links":[], "tenants":[{"description":"s3","enabled":true, "name": "s3"}]}

3. Rufen Sie das Token mit Bereichsbeschränkung zusammen mit „storageURL“ab.

curl -v -X POST -H 'ACCEPT: application/json' -H "Content-Type: application/json" -d '{"auth": {"tenantName" : "s3", "token":{"id" : ecs_d668b72a011c4edf960324ab2e87438b"}}}' http://203.0.113.10:9024/v2.0/tokens

Eine Beispielantwort sieht wie folgt aus. Dem Token mit Bereichsbeschränkungist „id“ vorangestellt.

{"access":{"token":{"id":"ecs_baf0709e30ed4b138c5db6767ba76a4e","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. Verwenden Sie das Token mit Bereichsbeschränkung und die Serviceendpunkt-URL für Swift-Authentifizierung. Dieser Schritt ist der gleiche wie in V1 vonOpenStack.

curl -v -H "X-Auth-Token: baf0709e30ed4b138c5db6767ba76a4e" http://203.0.113.10:9024/v1/s3/{container}/{object}

Authentifizierung mithilfe von ECS Keystone V3-IntegrationECS bietet Unterstützung für Keystone V3 durch Validierung der von OpenStackSwift-Benutzern bereitgestellten Authentifizierungstoken. Für Keystone V3 werdenBenutzer außerhalb von ECS mit einem Keystone V3-Service erstellt. ECS führt dieAuthentifizierung nicht aus, validiert aber das Authentifizierungstoken mit demKeystone V3-Service.

OpenStack Swift

Authentifizierung mithilfe von ECS Keystone V3-Integration 73

Hinweis

Ein Projekt in der Keystone-Domain kann als äquivalent zu einem ECS-Mandanten/Namespace betrachtet werden. Ein ECS Namespace entspricht einem Mandanten.

Bei Keystone V3 können Benutzer Rollen zugewiesen werden und die Aktionen, die siedurchführen dürfen, können auf ihrer Rollenmitgliedschaft basieren. Allerdingsbeinhaltet ECS-Unterstützung für Keystone V3 derzeit keine Keystone-Policies,sodass Benutzer der Gruppe (Rolle) admin angehören müssen, damit sieContainervorgänge durchführen können.

Authentifizierungstoken müssen einem Projekt zugeordnet werden; Token ohneBereichsbeschränkung sind bei ECS nicht zulässig. Vorgänge in Bezug auf Token ohneBereichsbeschränkung, wie z. B. das Abrufen einer Liste mit Projekten(gleichbedeutend mit einem Mandanten in ECS) und Services, müssen direkt für denKeystone-Service von Benutzern ausgeführt werden. Die Benutzer müssen dann einToken mit Bereichsbeschränkung vom Keystone-Service erhalten. Dieses Token kannanschließend von ECS validiert werden und, wenn es gültig ist, zur Authentifizierungbei ECS verwendet werden.

Zum Aktivieren der ECS-Validierung muss ein Authentifizierungsanbieter in ECSkonfiguriert worden sein. Wenn ein Token mit Bereichsbeschränkung auf einbestimmtes Projekt von einem Benutzer empfangen wird, kann ECS es dadurch fürden Keystone-V3-Authentifizierungsanbieter validieren. Darüber hinaus muss ein demKeystone-Projekt entsprechender ECS Namespace erstellt werden. WeitereInformationen finden Sie unter Konfigurieren von OpenStack Swift und ECS-Integration auf Seite 74.

AutorisierungsprüfungenECS verwendet die durch die Keystone-Token bereitgestellten Informationen fürAutorisierungsentscheidungen. Folgende Autorisierungsprüfungen finden statt:

1. ECS prüft, ob das Projekt, auf das das Token beschränkt ist, dem Projekt im URIentspricht.

2. Wenn der Vorgang ein objektbezogener Vorgang ist, bewertet ECS die mit demObjekt verknüpften ACLs, um festzustellen, ob der Vorgang zulässig ist.

3. Wenn der Vorgang ein containerbezogener Vorgang ist, bewertet ECS denangeforderten Vorgang. Benutzer mit der Rolle admin können die folgendenContainervorgänge ausführen: auflisten, erstellen, aktualisieren, lesen und löschen.

DomainsIn Keystone V3 gehören alle Benutzer zu einer Domain. Eine Domain kann übermehrere Projekte verfügen. Benutzer haben basierend auf ihrer Rolle Zugriff aufProjekte. Wenn ein Benutzer keiner Domain zugewiesen ist, wird er der Domain default(Standard) zugewiesen.

Mit Swift Keystone V3-Benutzern erstellte Objekte und Container gehören zu<user>@<domain.com>. Wenn der Benutzer keiner Domain zugewiesen wurde, lautetsein Containern und Objekten zugewiesener Benutzername <user>@default.

Konfigurieren von OpenStack Swift und ECS-IntegrationUm sicherzustellen, dass ein OpenStack Swift-Service, der Keystone V3 verwendet,sich bei ECS authentifizieren kann, müssen die Swift- und ECS-Konfigurationenkonsistent sein.

Bevor Sie beginnen

Die folgenden Voraussetzungen sind gültig:

OpenStack Swift


l Stellen Sie sicher, dass Sie Anmeldedaten für das Administratorkonto des Swift-Service haben. Diese Anmeldedaten sind erforderlich, damit sich ECS beimKeystone-Service authentifizieren kann.

l Sie müssen die Identität des Keystone-Projekts haben, zu der die Swift-Benutzergehören, die auf ECS zugreifen sollen.

l Stellen Sie sicher, dass Sie die Anmeldedaten für ein ECS-Systemadministratorkonto haben.

Vorgehensweise

1. Stellen Sie sicher, dass der ECS-Endpunkt dem Swift-Servicekataloghinzugefügt wurde und korrekt formatiert ist.

Sie müssen sicherstellen, dass sich die Endpunkte in der Keystone-Domain„default“ befinden.

2. Melden Sie sich als Systemadministrator beim ECS-Portal an.

3. Erstellen Sie einen Authentifizierungsanbieter, der den Keystone-V3-Serviceendpunkt und die Anmeldedaten eines Administratorkontos angibt, diezur Validierung von Token verwendet werden können.

Siehe Hinzufügen eines Keystone-Authentifizierungsanbieters auf Seite 75.

4. Erstellen Sie einen ECS-Namespace, der über dieselbe ID wie das Keystone-Projekt/-Konto verfügt, dem die Benutzer angehören, die sich authentifizierenmöchten.

Rufen Sie die Keystone-Projekt-ID ab.

a. Wählen Sie im ECS-Portal Manage > Namespace > New Namespace

b. Geben Sie den Namen des Namespace ein.

Das sollte der Name des Swift-Projekts sein.

c. Geben Sie das Konto des Namespace-Administrators als User Admin ein.

Das sollte der Name des Management-Benutzer sein, der zuvor erstelltwurde.

d. Konfigurieren Sie alle weiteren Namespace-Einstellungen, die Sie benötigen.

Weitere Informationen zu Namespace-Einstellungen und zur Erstellung vonBenutzern in ECS finden Sie im ECS-Administrationshandbuch auf der Seite„ECS-Produktdokumentation“.

Ergebnisse

Sobald der Namespace erstellt wurde, können Benutzer, die dem entsprechendenKeystone-Projekt angehören und über ein auf das Projekt beschränktes Tokenverfügen, sich bei ECS authentifizieren (durch Kommunikation zwischen ECS und demKeystone-Authentifizierungsanbieter) und mithilfe der Swift-API auf den ECS-Objektspeicher zugreifen.

Hinzufügen eines Keystone-AuthentifizierungsanbietersSie können OpenStack Swift-Benutzern einen Keystone-Authentifizierungsanbieterhinzufügen.

Bevor Sie beginnen

l Dieser Vorgang erfordert die Rolle „Systemadministrator“ in ECS.

l Sie können nur einen Keystone-Authentifizierungsanbieter hinzufügen.

OpenStack Swift

Authentifizierung mithilfe von ECS Keystone V3-Integration 75



l Rufen Sie die unter Keystone-Authentifizierungsanbieter-Einstellungen auf Seite76 aufgeführten Authentifizierungsanbieterinformationen ab.

Vorgehensweise

1. Wählen Sie im ECS-Portal die Optionen Manage > Authentication.

2. Klicken Sie auf der Seite Authentication Provider Management auf NewAuthentication Provider.

3. Wählen Sie auf der Seite New Authentication Provider im Feld Typ die OptionKeystone V3.

Die entsprechenden Felder werden angezeigt.

4. Geben Sie in die Felder Name, Description, Server URL, KeystoneAdministrator und Admin Password die entsprechenden Werte ein. WeitereInformationen zu diesen Feldern erhalten Sie unter Keystone-Authentifizierungsanbieter-Einstellungen auf Seite 76.

5. Klicken Sie auf Save.

Keystone-Authentifizierungsanbieter-Einstellungen

Sie müssen beim Hinzufügen oder Bearbeiten eines Keystone-Authentifizierungsanbieters Informationen zum Authentifizierungsanbieter angeben.

Tabelle 13 Keystone-Authentifizierungsanbieter-Einstellungen

Feld Beschreibung

Name Der Name des Keystone-Authentifizierungsanbieters. Dieser Name wird zurIdentifizierung des Anbieters in ECS verwendet.

Beschreibung Freitextbeschreibung des Authentifizierungsanbieters.

Typ Keystone V3.

OpenStack Swift


Tabelle 13 Keystone-Authentifizierungsanbieter-Einstellungen (Fortsetzung)

Feld Beschreibung

Server-URL URI des Keystone-Systems, mit dem ECS eine Verbindung herstellt, um Swift-Benutzer zu validieren.

Keystone-Administrator Benutzername für einen Administrator des Keystone-Systems. ECS stellt mitdiesem Benutzernamen eine Verbindung zum Keystone-System her.

Administratorpasswort Passwort des angegebenen Keystone-Administrators.

Autorisierung für ContainerDie OpenStack Swift-Autorisierung gilt nur für Container.

Swift unterstützt derzeit zwei Arten von Autorisierung:

l Verweisautorisierung

l Gruppenautorisierung

ECS unterstützt ausschließlich gruppenbasierte Autorisierung.

Administratorbenutzer können alle Vorgänge innerhalb des Kontos durchführen.Benutzer ohne Administratorrechte können nur Vorgänge für jeden Containerausführen, die auf den Zugriffskontrolllisten für den Lese- bzw. Schreibzugriff von X-Container basieren. Die folgenden Vorgänge können Nicht-Administratorbenutzerngewährt werden:

Administrator weist Lesezugriff auf den Container zuDer Benutzer admin kann einer Gruppe wie folgt Leseberechtigungen zuweisen:

curl -X PUT -v -H 'X-Container-Read: {GROUP LIST}' -H 'X-Auth-Token: {TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}"

Mit diesem Befehl erhält der Benutzer, der der GROUP LIST angehört, Lesezugriff auf„container1“. Dadurch können z. B. der Gruppe Member Leseberechtigungen erteiltwerden:

curl –X PUT -v –H 'X-Container-Read: Member' –H 'X-Auth-Token: {ADMIN_TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}

Nachdem die Leseberechtigung erteilt wurde, können zur Zielgruppe gehörendeBenutzer die folgenden Vorgänge ausführen:

l HEAD container – Ruft Container-Metadaten ab. Nur zulässig, wenn der Benutzerder Gruppe zugewiesen ist, die Tenant-Administratorrechte hat.

l GET container – Listet Objekte in einem Container auf

l GET objects with container – Liest den Inhalt der Objekte im Container

OpenStack Swift

Autorisierung für Container 77

Administrator weist Schreibzugriff auf den Container zuDer Benutzer admin kann einer Gruppe wie folgt Leseberechtigungen zuweisen:

curl -XPUT -v -H 'X-Container-Write: {GROUP LIST}' -H 'X-Auth-Token: {TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}"

Mit diesem Befehl erhalten Benutzer, die der GROUP LIST angehören, Schreibzugriffauf container1. Dadurch können z. B. der Gruppe Member Schreibberechtigungenerteilt werden:

curl –X PUT -v –H 'X-Container-Write: Member' –H 'X-Auth-Token: {ADMIN_TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}

Den Benutzern in der Gruppe GROUP LIST wird Schreibzugriff gewährt. Nachdem dieSchreibberechtigung erteilt wurde, können zur Zielgruppe gehörende Benutzer diefolgenden Vorgänge ausführen:

l POST container – Legt Metadaten fest Beginn mit dem Präfix „X-Container-Meta“.

l PUT objects within container – Schreibt/überschreibt Objekte innerhalb desContainers

Weitere Informationen zur Autorisierung finden Sie unter: Container-Vorgänge.

OpenStack Swift


http://ceph.com/docs/master/radosgw/swift/containerops/

TEIL 3

EMC Atmos

Kapitel 3, "EMC Atmos"

EMC Atmos 79

EMC Atmos


KAPITEL 3

EMC Atmos

l EMC Atmos-API-Unterstützung in ECS............................................................. 82l Unterstützte EMC Atmos-REST-API-Aufrufe....................................................82l Nicht unterstützte EMC Atmos-REST-API-Aufrufe........................................... 84l Support für Untermandanten in EMC Atmos-REST-API-Aufrufen.....................85l API-Erweiterungen.............................................................................................85

EMC Atmos 81

EMC Atmos-API-Unterstützung in ECSECS unterstützt eine Teilmenge der EMC Atmos-API. In diesem Abschnitt sind dieunterstützten Vorgänge und die ECS-Erweiterungen aufgeführt.

Der Atmos Object Service wird auf den folgenden Ports zur Verfügung gestellt.

Protokoll Ports

HTTP 9022

HTTPS 9023

Weitere Informationen zu den unterstützten Vorgängen finden Sie im Atmos-Programmierhandbuch, das über die ECS-Support-Website verfügbar ist.

l Atmos-Programmierhandbuch

Verbindungsformatkompatibilität ist für alle unterstützten Vorgänge vorhanden. Ausdiesem Grund gelten die im Atmos-Programmierhandbuch beschriebenen Vorgänge fürAPI-Vorgänge, die für ECS zur Verfügung gestellt werden.

Das Atmos-Programmierhandbuch enthält auch Informationen zur Authentifizierung mitder Atmos-API und bietet umfassende Beispiele für viele der unterstütztenFunktionen.

Unterstützte EMC Atmos-REST-API-AufrufeECS unterstützt eine Teilmenge der EMC Atmos-API.

Die folgenden Atmos-REST-API-Aufrufe werden unterstützt. Aufrufe sowohl fürObjekt- als auch für Namespace-Schnittstellen werden angezeigt.

Tabelle 14 Unterstützte Atmos-REST-API-Aufrufe


Servicevorgänge

GET /rest/service Informationen zumSystem abrufen

Objektvorgänge

POST /rest/objects/rest/namespace/<path>

Ein Objekt erstellen

(Siehe Hinweise unten)

DELETE /rest/objects/<ObjectID>/rest/namespace/<path>

Objekt löschen

PUT /rest/objects/<ObjectID>/rest/namespace/<path>

Objekt aktualisieren

(Siehe Hinweise unten)

GET /rest/objects/<ObjectID>/rest/namespace/<path>

Objekt (oderVerzeichnisliste) lesen

POST /rest/namespace/<path>?rename Ein Objekt umbenennen

Metadatenvorgänge

EMC Atmos


http://support.emc.com

Tabelle 14 Unterstützte Atmos-REST-API-Aufrufe (Fortsetzung)


GET /rest/objects/<ObjectID>?metadata/user/rest/namespace/<path>?metadata/user

Benutzermetadaten fürein Objekt abrufen

POST /rest/objects/<ObjectID>?metadata/user/rest/namespace/<path>?metadata/user

Benutzermetadatenfestlegen

DELETE /rest/objects/<objectID>?metadata/user/rest/namespace/<path>?metadata/user

Benutzermetadatenlöschen

GET /rest/objects/<ObjectID>?metadata/system/rest/namespace/<path>?metadata/system

Systemmetadaten für einObjekt abrufen

GET /rest/objects/<ObjectID>?acl/rest/namespace/<path>?acl

ACL abrufen

POST /rest/objects/<ObjectID>?acl/rest/namespace/<path>?acl

ACL festlegen

GET /rest/objects/<ObjectID>?metadata/tags/rest/namespace/<path>?metadata/tags

Metadaten-Tags für einObjekt abrufen

GET /rest/objects/<ObjectID>?info/rest/namespace/<path>?info

Objektinformationenabrufen

Head /rest/objects/<ObjectID>/rest/namespace/<path>

Alle Objektmetadatenabrufen

Objektvorgänge

GET /rest/objects Objekte auflisten

GET /rest/objects?listabletags Auflistbare Tags abrufen

Anonymer Zugriff

GET /rest/objects/<ObjectId>?uid=<uid>&expires=<exp>&signature=<sig>/rest/namespace/<path>?uid=<uid>&expires=<exp>&signature=<sig>

Gemeinsam nutzbareURL

Hinweis

l Der x-emc-wschecksum-Header wird in ECS unterstützt.

l Das Hochladen von HTML-Formularen wird nicht unterstützt.

l GET /rest/objects unterstützt mit x-emc-accept keine unterschiedlichenAntworttypen. Beispielweise wird "text/plain" nicht unterstützt

l Das Lesen, Schreiben und Löschen von ACLs funktioniert in ECS genauso wie inAtmos.

l POST /rest/objects unterstützt den Header „x-emc-object-id“, um Legacy-Objekt-IDs (44 Zeichen) zu ermöglichen.

EMC Atmos

Unterstützte EMC Atmos-REST-API-Aufrufe 83

Atmos Listable TagsListable Tags sind spezielle benutzerdefinierte Tags zum Auflisten oder Filtern vonObjekten. Eine Anwendung könnte z. B. einem Anwender ermöglichen, eine Gruppevon Bildern (Objekten) mit einem Tag wie „Vacation2016“ zu kennzeichnen. Späterkann die Anwendung auf die Abfrage „Vacation2016“ reagieren, indem nur die mitdiesem Listable Tag gekennzeichneten Objekte aufgelistet werden.

Bei Verwendung des Atmos-Protokolls mit ECS können Benutzer die Listable Tagsanderer Benutzer weder löschen noch ändern. Unter bestimmten Umständen ist dieseFunktion nativ in Atmos zulässig.

Listable Tags werden in ECS indiziert, um die Performance und Skalierbarkeit desAbrufs gekennzeichneter Objekte zu erhöhen.

In ECS wird das Metadatentag EMC_TAGS zum Persistieren von Listable Tagsverwendet. Dieser Tagname darf in benutzerdefinierten Metadatentags nichtverwendet werden.

Länge der Objekt-IDDie Unterstützung für die Atmos-API in ECS erweitert die Länge der Objekt-ID von 44Zeichen auf 101 Zeichen. Vergessen Sie also beim Verschieben von Anwendungen vonAtmos zu ECS nicht, dass die Objekt-ID-Länge unterschiedlich ist.

Um ein Objekt mit der Legacy-ID-Länge von 44 Zeichen zu erstellen, können Sie denHeader „x-emc-object-id“ verwenden. Dadurch können Objekte zu Atmos migriertwerden.

Nicht unterstützte EMC Atmos-REST-API-Aufrufe

Die folgenden Atmos-REST-API-Aufrufe werden nicht unterstützt.

Tabelle 15 Nicht unterstützte Atmos-REST-API-Aufrufe


Objektversionierung

POST /rest/objects/<objectID>?versions

Objektversion erstellen

DELETE /rest/objects/<objectID>?versions

Objektversion löschen

GET /rest/objects/<objectID>?versions

Objektversionen auflisten

PUT /rest/objects/<objectID>?versions

Objektversionwiederherstellen

Anonymer Zugriff

POST /rest/accesstokens Zugriffstoken erstellen

GET /rest/accesstokens/<token_id>?info

Details zu Zugriffstokenabrufen

DELETE /rest/accesstokens/<token_id>

Zugriffstoken löschen

GET /rest/accesstokens Zugriffstoken auflisten

EMC Atmos


Tabelle 15 Nicht unterstützte Atmos-REST-API-Aufrufe (Fortsetzung)


GET /rest/accesstokens/<token_id>

Inhalt anonym herunterladen

Support für Untermandanten in EMC Atmos-REST-API-Aufrufen

ECS beinhaltet zwei spezielle native REST-API-Aufrufe, mit denen Atmos-Anwendungen der Support für ECS-Subtenants hinzugefügt wird.

Dies sind folgende Aufrufe:

API-Aufruf Beispiel

Subtenant erstellen PUT Http url: /rest/subtenantErforderliche Header: x-emc-uid (zum [email protected]) und x-emc-signature.

Die Subtenant-ID wird in der Kopfzeile"subtenantID" der Antwort festgelegt.

Subtenant löschen DELETE Http url: /rest/subtenants/{subtenantID}Erforderliche Header: x-emc-uid (zum [email protected]) und x-emc-signature.

Hinweis

Subtenant-IDs werden nach der Migration in ECS beibehalten: Der Header lautetx-emc-subtenant-id: {original_subt_id}.

API-ErweiterungenECS unterstützt eine Reihe von Erweiterungen für die Atmos-API.

Die Erweiterungen und die APIs, von denen sie unterstützt werden, sind im Folgendenaufgeführt:

l Anhängen von Daten an ein Objekt auf Seite 85

l ECS-Unterstützung von Aufbewahrung und Ablauf der Aufbewahrungsfristen beiAtmos-Objekten auf Seite 86

Anhängen von Daten an ein ObjektSie können die Erweiterungen ECS des EMC Atmos-Protokolls verwenden, um Datenan ein Objekt anzuhängen.

In einigen Fällen müssen Sie Daten an ein Objekt anhängen, können den genauen Byte-Offset aber nicht effizient bestimmen. Für dieses Szenario stellt ECS die Möglichkeit

EMC Atmos

Support für Untermandanten in EMC Atmos-REST-API-Aufrufen 85

bereit, Daten in Kleinstmengen ohne Angabe eines Offsets an das Objekt anzuhängen(der richtige Offset wird in der Antwort zurückgegeben).

Zum Anhängen von Daten an ein Objekt wird ein "Range"-Header mit dem Sonderwertbytes=-1- verwendet. Auf diese Weise kann das Objekt erweitert werden, ohne dassdie Größe des vorhandenen Objekts bekannt ist. Das Format lautet wie folgt: Range:bytes=-1-Das folgende Beispiel zeigt eine Beispielanforderung zum Anhängen von Daten an einvorhandenes Objekt mit einem "Range"-Wert von bytes=-1-. Hier wird der Wertand cat in der Anforderung gesendet.

PUT /rest/namespace/myObject HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-date: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcx-emc-uid: fa4e31a68d3e4929bec2f964d4cac3de/[email protected]: ZpW9KjRb5+YFdSzZjwufZUqkExc=Content-Type: application/octet-streamAccept-Encoding: gzip, deflate, compress

and cat

HTTP/1.1 200 OKx-emc-mtime: 1431626712933Date: Mon, 17 Jun 2013 20:46:01 GMTx-emc-policy: defaultx-emc-utf8: truex-emc-request-id: 0af9ed8d:14cc314a9bc:112f6:9x-emc-delta: 8x-emc-append-offset: 24Content-Length: 0Server: Jetty(7.6.4.v20120524)

Die Offsetposition, an der Daten angehängt wurden, wird im Header „x-emc-append-offset“ zurückgegeben.


ECS-Unterstützung von Aufbewahrung und Ablauf der Aufbewahrungsfristenbei Atmos-Objekten

ECS unterstützt Aufbewahrungsfristen und Ablauf der Aufbewahrungsfristen beiAtmos-Objekten.

AufbewahrungsfristenAufbewahrungsfristen bestimmen, wie lange ein Objekt von ECS aufbewahrt wird,bevor es bearbeitet oder gelöscht werden kann. Während der Aufbewahrungsfristkann das Objekt nicht bearbeitet oder aus dem System gelöscht werden, sondern erst,wenn die Aufbewahrungsfrist abgelaufen ist.

Beim Erstellen eines Atmos-Objekts in ECS kann die Objektaufbewahrung wie folgtfestgelegt werden:

l Direkt für das Objekt festgelegt

EMC Atmos


l Übernommen von der Aufbewahrungsfrist, die für den ECS-Bucket festgelegtwurde, in dem das Objekt erstellt wird.

Wenn eine Aufbewahrungs-Policy für den ECS-Namespace festgelegt ist, müssen Siedennoch die Aufbewahrungsfrist direkt für das Objekt festlegen. Die Aufbewahrungs-Policy im Namespace wird nicht vom Objekt übernommen.

Tabelle 16 Atmos-Aufbewahrungsfristen

Aufbewahrungfestgelegt für

Verwendet Anmerkungen

Objekt Atmos-API über

l Header-Aufbewahrungsfrist inSekunden:'x-emc-retention-period:60'

l Benutzer-Metadaten(UMD), Enddatum:'x-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2016-10-21:10:00Z'

l Header und UMD:'x-emc-meta:user.maui.retentionEnable =true,user.maui.retentionEnd=2016-10-21T18:14:30Z' -header 'x-emc-retention-period:60'

l Die Aufbewahrung kann für das Objektfestgelegt werden, während das Objekterstellt oder die Objekteinstellungenaktualisiert werden.

l Die Header-Aufbewahrungsfrist wird inSekunden angegeben.

l Die UMD-Aufbewahrung wird durch einEnddatum festgelegt.

l Wenn die Aufbewahrungsfrist über dieKopfzeile und die UMD festgelegtwurde, wird zunächst das UMD-Attribut überprüft, und die dortigeEinstellung hat Vorrang vor derEinstellung im Header.

l Sie können die Aufbewahrungsfristnicht ändern, nachdem sie für dasObjekt festgelegt wurde, sondern erst,wenn sie abgelaufen ist.

l Bei Verwendung des Headers x-emczur Festlegung der Aufbewahrung:

n -1 legt eine unbegrenzteAufbewahrungsfrist fest unddeaktiviert den Ablaufzeitraum, fallseiner festgelegt wurde.

n -2 deaktiviert die für das Objektfestgelegte Aufbewahrungsfrist.

ESC-Namespace ECS-Portal aus der Seite

Neuer Namespace oder

Namespace bearbeiten.

l Wenn Sie eine Aufbewahrungsfrist fürein Objekt festlegen möchten und eineAufbewahrungs-Policy für denNamespace des Objektbenutzersfestgelegt wurde, müssen Sie dennochwie oben beschrieben eineAufbewahrungsfrist direkt für dasObjekt festlegen.

l Wenn eine Aufbewahrungs-Policy fürden ESC-Namespace und/oder eineAufbewahrungsfrist für einen Bucketinnerhalb des Namespace festgelegtwurde und in dem Bucket ein Objekterstellt wird, bewahrt ESC den

ECS REST-APIPOST /object/namespaces/namespace/{namespace}/retention

ECS-Bucket ECS-Portal aus der Seite

Neuer Bucket oder

Bucket bearbeiten.

ECS REST-API

EMC Atmos

ECS-Unterstützung von Aufbewahrung und Ablauf der Aufbewahrungsfristen bei Atmos-Objekten 87

Tabelle 16 Atmos-Aufbewahrungsfristen (Fortsetzung)

Aufbewahrungfestgelegt für

Verwendet Anmerkungen

PUT /object/bucket/{bucketName}/retention

Namespace, den Bucket oder dasObjekt für die längereAufbewahrungsfrist auf, die entwederfür den Namespace oder den Bucketfestgelegt wurde.

l Wenn über den Objekt-Header eineAufbewahrungsfrist für das Objektselbst festgelegt wurde, bewahrt ESCdas Objekt für den längsten Zeitraumauf, der für den Namespace, denBucket oder das Objekt festgelegtwurde.

l Wenn über die Atmos-API einEnddatum für die Aufbewahrungfestgelegt wurde, greift ECS bei derAufbewahrung auf dieses für dasObjekt festgelegte Atmos-API-Enddatum zurück und ignoriert bei derErstellung des Objekts dieAufbewahrungs-Policy des Namespaceund die Aufbewahrungsfristen desBuckets.

l Wenn eine Aufbewahrungs-Policy aufeinen Untermandanten (Bucket)angewendet wird, der Atmos-Objekteenthält, wird die Aufbewahrungs-Policysowohl auf Objekte angewendet, dienach der Festlegung derAufbewahrungs-Policy in demUntermandanten erstellt wurden, alsauch auf Objekte, die vor derFestlegung der Aufbewahrungs-Policyin dem Untermandanten erstelltwurden.

Hinweis

Weitere Details zu Namespace-Aufbewahrungs-Policies und Bucket-Aufbewahrungsfristen finden Sie unter ECS-Administrationshandbuch auf der Seite„ECS-Produktdokumentation“.

Beispiel: Anforderung und Antwort zur Erstellung eines Objekts mit festgelegterAufbewahrung:

POST /rest/namespace/file1 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 16 Feb 2017 19:28:13 GMT

EMC Atmos




x-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2017-06-30T06%3A38%3A44Zx-emc-uid:f082110e13f249649340e172fb7b4956/u1x-emc-utf8:trueContent-Type:plain/textx-emc-signature:2Gz51WT+jQdMjlobDV0mz7obsXM=Content-Length: 774

Response

HTTP/1.1 201 CreatedDate: Thu, 16 Feb 2017 19:28:17 GMTx-emc-policy: defaultx-emc-utf8: truex-emc-request-id: 0af7b3e4:15a4849d95e:37c:0x-emc-delta: 774Location: /rest/objects/0a40bd045f7373d367639f095d1db0d15acadb82d5d2cd108e2142f4be04635c-59bdb9b6-20c0-4f55-bc91-9db728a58854x-emc-mtime: 1487273295379Content-Length: 0Server: ViPR/1.0

Beispiel: Anforderung und Antwort zum Abruf von Objekt-Metadaten:

curl --head -H "x-emc-date:Mon, 30 Jan 2017 16:56:35 GMT" -H "x-emc-uid:7a2593be81374744adbf8e3983e7bd84/u1" -H "x-emc-signature:CQgfoiIQ/DCif7TafcIskWyVpME=" http://10.247.179.228:9022/rest/objects/d1bced53f2ebbcbc51af1d84747bd198d123d3b8585293a5bf0d32bb73c6cf4b-365f4482-c24a-4eca-b24a-070efe29bf63

Response

HTTP/1.1 200 OKDate: Mon, 30 Jan 2017 16:56:35 GMTx-emc-mtime: 1485795387838x-emc-retention-period: 21798212x-emc-meta: user.maui.retentionEnd=2017-10-10T00:00:00Z,user.maui.retentionEnable=true,allow-inline-update=false,atime=2017-01-30T16:45:48Z,ctime=2017-01-30T16:56:27Z,ctype=plain/text,data-range=CAAQgFA=,dek=kq/W1Rg/7qbmaCcLF8pFvqlDJ8+suPTdVddBBZFwZA86muG3P0Pb7w==,dekAlgo=AESKeyWrapRFC5649,etag=0-,fs-mtime-millisec=1485795387838,itime=2017-01-30T16:45:48Z,kekId=s3.7a2593be81374744adbf8e3983e7bd843cdda755061bac6c12c06eb02800a7fee4b11ac2e03f62bb01eee02995068e56,keypoolid=s3.7a2593be81374744adbf8e3983e7bd84,keypoolname=7a2593be81374744adbf8e3983e7bd84,keyversion=0,mtime=2017-01-30T16:56:27Z,namespace=s3,nlink=1,object-name=,objectid=d1bced53f2ebbcbc51af1d84747bd198d123d3b8585293a5bf0d32bb73c6cf4b-365f4482-c24a-4eca-b24a-070efe29bf63,objname=file,parentOid=53ae036bfcfb46f5580b912222f3026835e3ef972c7e3e532ba4a5de30b1946e,parentZone=urn:storageos:VirtualDataCenterData:365f4482-c24a-4eca-b24a-070efe29bf63,policyname=default,retention=CgYIoKOZmlE=,size=0,type=regular,uid=u1,parent=apache,gid=apachex-emc-useracl: u1=FULL_CONTROLx-emc-groupacl: other=READx-emc-policy: defaultx-emc-request-id: 0af7b3e4:159f0185cf7:957:4Content-Type: plain/textContent-Length: 0Server: ViPR/1.0

EMC Atmos


Beispiel: Aktualisierung eines Objekts mit Aufbewahrungswerten

POST /rest/namespace/file2?metadata/user HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 16 Feb 2017 19:37:15 GMTx-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2017-07-30T06%3A38%3A44Zx-emc-uid:f082110e13f249649340e172fb7b4956/u1x-emc-utf8:trueContent-Type:plain/textx-emc-signature:5UPpZcCfO0vtxMTW62fa2/2SmLg=

Response

HTTP/1.1 200 OK

Date: Thu, 16 Feb 2017 19:37:16 GMTx-emc-policy: _intx-emc-utf8: truex-emc-request-id: 0af7b3e4:15a4849d95e:582:0Content-Length: 0Server: ViPR/1.0

AblaufzeitraumWenn für ein Atmos-Objekt das Enddatum eines Aufbewahrungszeitraums festgelegtwurde und der Ablaufzeitraum ebenfalls für das Objekt festgelegt wird, löscht ESC dasObjekt automatisch an dem Datum, das im Ablaufzeitraum angegeben ist. Für denAblaufzeitraum gilt:

l Er kann für Objekte mithilfe der Atmos-API oder des Headers x-emc festgelegtwerden.

l Der Ablaufzeitraum muss nach dem Enddatum der Aufbewahrung liegen.

l Der Ablaufzeitraum ist standardmäßig deaktiviert.

l Bei Verwendung des Headers x-emc zur Festlegung von Aufbewahrung undAblauf deaktiviert der Wert-1 den Ablaufzeitraum.

Beispiel: Festlegen des Ablaufzeitraums mithilfe des Headers x-emc:

POST /rest/namespace/file2 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Tue, 31 Jan 2017 19:38:00 GMTx-emc-expiration-period:300x-emc-uid:a2b85977fd08488b80e646ea875e990b/u1Content-Type:plain/textx-emc-signature:krhYBfKSiM3mFOT6FtRB+2/xZnw=Content-Length: 10240Expect: 100-continue

Beispiel: Anforderung und Antwort bei Verwendung der Atmos-API:

POST /rest/namespace/file2 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 02 Feb 2017 02:47:32 GMTx-emc-

EMC Atmos


meta:user.maui.expirationEnable=true,user.maui.expirationEnd=2017-03-30T20:20:00Zx-emc-uid:239e20dec7a54301a0b02f6090edcace/u1Content-Type:plain/textx-emc-signature:5tGEyK/9qUZCPSnQ9OPOdktN+Zo=Content-Length: 10240Expect: 100-continue

Response

HTTP/1.1 100 ContinueHTTP/1.1 201 CreatedDate: Thu, 02 Feb 2017 02:47:33 GMTx-emc-policy: defaultx-emc-request-id: 0af7b3e4:159fb81ddae:345e:0x-emc-delta: 10240Location: /rest/objects/5c3abaf60e0e207abec96baf0618c0461b7cd716898f8a12ee236aed1ec94bea-c86ee0e9-8709-4897-898e-c3d1895e1d93x-emc-mtime: 1486003652813Content-Length: 0Server ViPR/1.0 is not blacklistedServer: ViPR/1.0

Beispiel: Anforderung und Antwort zur Aktualisierung der Metadaten mit der Atmos-API:

POST /rest/namespace/file?metadata/user HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 02 Feb 2017 02:44:13 GMTx-emc-meta:user.maui.expirationEnable=true,user.maui.expirationEnd=2017-03-30T20:20:00Zx-emc-uid:239e20dec7a54301a0b02f6090edcace/u1Content-Type:plain/textx-emc-signature:9pzcc/Ce4Lq3k52QKdfWLYlZ1Yc=

Response

HTTP/1.1 200 OKDate: Thu, 02 Feb 2017 02:44:14 GMTx-emc-policy: _intx-emc-request-id: 0af7b3e4:159fb81ddae:339e:0Content-Length: 0Server ViPR/1.0 is not blacklistedServer: ViPR/1.0

EMC Atmos


EMC Atmos


TEIL 4

CAS

Kapitel 4, "CAS"

CAS 93

CAS


KAPITEL 4

CAS

l Einrichten des CAS-Supports in ECS.................................................................96l Cold-Speicher....................................................................................................96l Compliance........................................................................................................ 97l CAS-Aufbewahrung in ECS.............................................................................. 100l Erweiterte Aufbewahrung für CAS-Anwendungen: eventbasierte Aufbewahrung,

gesetzliche Aufbewahrungsfrist und Min-/Max-Kontrolle................................ 102l Konfigurieren von Namespace-Aufbewahrungs-Policies...................................109l Erstellen und Einrichten eines Bucket für einen CAS-Benutzer......................... 110l Einrichten eines CAS-Objektbenutzers.............................................................. 111l Konfigurieren von Bucket-ACLs für CAS........................................................... 112l ECS-Management-APIs, die CAS-Benutzer unterstützen................................. 114l CAS-SDK-API-Support (Content Addressable Storage)................................... 115

CAS 95

Einrichten des CAS-Supports in ECSEinführung in den CAS-Support (Content Addressable Storage) in ECS

ECS CAS ermöglicht CAS-SDK-basierten Clientanwendungen das Speichern, Abrufenund Löschen von Fixed-Contentobjekten in ECS-Speicher.

Der zugrunde liegende ECS-Speicher muss bereitgestellt werden, bevor Sie Ihre ECS-Einrichtung konfigurieren können. Das Provisioning ist normalerweise abgeschlossen,wenn ein neues ECS-Rack installiert wird. Dazu gehört das Einrichten einesSpeicherpools, eines VDC und einer Replikationsgruppe. Sie können in ECS dieStandarddokumentation verwenden, wenn Sie diese Objekte erstellen oder bearbeitenmüssen, um CAS zu unterstützen. Siehe ECS-Administrationshandbuch auf der Seite„ECS-Produktdokumentation“.

Für die Speicherpools sollten Sie die Einrichtung eines Cold-Archivs in Betrachtziehen. Siehe Cold-Speicher auf Seite 96.

Legen Sie danach Ihre Namespaces, Benutzer und Buckets mithilfe derStandarddokumentation fest. Siehe ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.

In diesem Kapitel wird beschrieben, wie Sie Ihre Basiskonfiguration ändern, um CAS zuunterstützen.

Cold-SpeicherBeschreibt Cold-Speicherarchive.

Cold-Archive speichern Objekte, die nicht häufig geändert werden und das robusteStandard-EC-Schema nicht benötigen. Das für ein Cold-Archiv verwendete EC-Schema lautet 10 Datenfragmente plus 2 Programmierungsfragmente (10/12). DieEffizienz beträgt 1,2x.

Sie können ein Cold-Archiv (Cold-Speicher) angeben, wenn Sie einen neuenSpeicherpool erstellen. Nach der Erstellung des Speicherpools kann das EC-Schemanicht mehr geändert werden. Dieses Schema kann den Verlust eines einzigen Nodesunterstützen. Es unterstützt auch Verlust von einem von sechs Laufwerken oder zweivon zwölf Laufwerken auf zwei getrennten Nodes.

EC-Anforderungen

Tabelle 17 Anforderungen für reguläre und Cold-Archive im Vergleich

Anwendungsbeispiel

Aktivierung MindestenserforderlicheNodes

MindestenserforderlicheLaufwerke

EmpfohleneLaufwerke

EC-Effizienz EC-Schema

ReguläresArchiv

Standard 4 16* 32 1,33x 12/16

Cold-Archiv VomSystemadministratorkonfiguriert

8 12* 24 1,2x 10/12

CAS






Hinweis

*Da die minimale bereitstellbare Konfiguration für die Appliance der C-Serie aus zweiAppliances mit je 12 Laufwerken besteht, sind 24 Laufwerke das effektive Minimum.

Konfiguration des SpeicherpoolsUm ein Cold-Archiv über das Portal zu erstellen, wählen Sie bei der Erstellung einesneuen Speicherpools Cold Storage aus. Nachdem ein Speicherpool erstellt wurde,kann diese Einstellung nicht mehr geändert werden.

ComplianceBeschreibt die ECS-Funktionen, die behördliche und Branchenstandards für dieSpeicherung von elektronischen Datensätzen unterstützen.

ECS erfüllt die Speicheranforderungen der folgenden Standards gemäß Zertifizierungdurch Cohasset Associates Inc:

l SEC (Securities and Exchange Commission) in Vorschrift 17 CFR, § 240.17a-4(f)

l CFTC (Commodity Futures Trading Commission) in Vorschrift 17 CFR, § 1.31(b)-(c)

Die Compliance ist auf ECS-Appliances mit ECS-Version 2.2.1 und höher zertifiziert.Installationen nur von ECS-Softwareversion 3.0 und höher auf ECS-zertifizierterDrittanbieterhardware sind ebenfalls zertifiziert.

Die Compliance besteht aus drei Komponenten:

CAS

Compliance 97

l Plattformverstärkung: Behebt gängige Sicherheitsschwachstellen.

l Policy-basierte Datensatzaufbewahrung: Begrenzt die Möglichkeit,Aufbewahrungs-Policies für aufbewahrte Datensätze zu ändern.

l Compliancereporting: Das regelmäßige Reporting durch einen System-Agentzeichnet den Compliancestatus des Systems auf.

Plattformverstärkung und ComplianceDie folgenden ECS-Sicherheitsfunktionen unterstützen Compliancestandards.

Sicherheitsfunktionen der ECS-Plattform:

l Benutzer-Root-Zugriffe auf Nodes sind deaktiviert (keine Benutzer-Root-Anmeldungen zulässig).

l ECS-Kunden können über den Administratorbenutzer, der bei Erstinstallationeneingerichtet wird, auf Nodes zugreifen.

l Der Administratorbenutzer führt Befehle für Nodes mithilfe von sudo aus.

l Für sudo-Befehle findet eine vollständige Auditprotokollierung statt.

l ESRS bietet die Möglichkeit, den Remotezugriff auf Nodes vollständigherunterzufahren. Legen Sie im ESRS Policy Manager die Aktion Remote-Terminal starten auf Nie zulassen fest.

l Alle unnötigen Ports (ftpd, sshd) werden geschlossen.

l Der emcsecurity-Benutzer mit der Rolle des Sperradministrators kann Nodes ineinem Cluster sperren. Dies bedeutet, dass der Remotezugriff über das Netzwerkdurch SSH deaktiviert ist. Der Sperradministrator kann anschließend einen Nodeentsperren, um Remote-Wartungsaktivitäten oder andere autorisierte Zugriffe zuermöglichen.

Hinweis

Node-Sperren wirken sich nicht auf autorisierte ECS-Portal- oder ECS-Management-API-Benutzer aus.

Compliance und Aufbewahrungs-PolicyBeschreibt erweiterte Regeln für die Aufbewahrung von Datensätzen in einemcompliancefähigen ECS-System. ECS legt Objektaufbewahrungsfunktionen auf derEbene von Objekten, Buckets und Namespaces auf Aktiviert fest. Compliance stärktdiese Funktionen durch die Beschränkung von Änderungen, die an denAufbewahrungseinstellungen für aufbewahrte Objekte vorgenommen werden können.Zu den Regeln gehören:

l Compliance wird auf der Namespace-Ebene aktiviert. Das bedeutet, dass alleBuckets im Namespace eine Aufbewahrungsfrist aufweisen müssen, die größer alsNull ist. Für CAS können Buckets mit einer Aufbewahrung von null erstellt werden,sofern die Einstellung Enforce Retention Information in Object aktiviert ist.

l Compliance kann nur auf einem Namespace aktiviert werden, während derNamespace erstellt wird. (Compliance kann nicht zu einem vorhandenenNamespace hinzugefügt werden.)

l Nach der Aktivierung ist keine Deaktivierung der Compliance mehr möglich.

l Alle Buckets im Namespace müssen eine Aufbewahrungsfrist aufweisen, diegrößer als Null ist.

CAS


Hinweis

Wenn Sie über eine Anwendung verfügen, die Aufbewahrungsfristen aufObjektebene zuweist, verwenden Sie nicht ECS, um eine Aufbewahrungsfristzuzuweisen, die größer als die Aufbewahrungsfrist der Anwendung ist. DieseAktion führt zu Anwendungsfehlern.

l Ein Bucket mit Daten kann unabhängig von seiner Aufbewahrungswert gelöschtwerden.

l Die Anwendung der Option Infinite für einen Bucket bedeutet, dass Objekte imBucket innerhalb eines compliancefähigen Namespace nicht dauerhaft gelöschtwerden können.

l Die Aufbewahrungsfrist für ein Objekt kann nicht gelöscht oder verkürzt werden.Daher kann die Aufbewahrungsfrist für einen Bucket nicht gelöscht oder verkürztwerden.

l Aufbewahrungsfristen für Objekte und Buckets können verlängert werden.

l Kein Benutzer kann ein aufbewahrtes Objekt löschen. Dies schließt Benutzer mitder CAS-Berechtigung „Privileged Delete“ ein.

Abbildung 1 Aktivieren von Compliance für einen neuen Namespace im ECS-Portal

CAS

Compliance und Aufbewahrungs-Policy 99

Compliance-AgentBeschreibt die Funktion des Compliance-Agents.

Compliancefunktionen sind standardmäßig aktiviert, mit Ausnahme desCompliancemonitorings. Wenn das Monitoring aktiviert ist, veröffentlicht der Agentregelmäßig eine Meldung.

Hinweis

Wenden Sie sich an den Kundensupport, um das Compliancemonitoring zu aktivieren.Monitoringmeldungen können über einen Befehl vom Node abgerufen werden. Siewerden nicht im ECS-Portal angezeigt.

CAS-Aufbewahrung in ECSEin CAS-C-Clip kann eine Aufbewahrungsfrist aufweisen, die den Zeitraum festlegt, indem das Objekt im ECS-Speicher aufbewahrt wird, bevor eine Anwendung es löschenkann.

AufbewahrungsfristenAufbewahrungsfristen werden im C-Clip des Objekts nach CAS-Anwendungzugewiesen.

Wenn beispielsweise ein Finanzdokument nach seinem Erstellungszeitpunkt 3 Jahrelang aufbewahrt werden muss, wird im C-Clip eine Aufbewahrungsfrist von 3 Jahrenfür das Finanzdokument angegeben. Es kann auch eine unbefristete Aufbewahrung fürdas Dokument definiert werden.

Aufbewahrungs-Policies (Aufbewahrungsklassen)

Hinweis

Das Centera-Konzept der „Aufbewahrungsklassen“ entspricht den „Aufbewahrungs-Policies“ in ECS. In dieser Dokumentation wird der Begriff „Aufbewahrungs-Policies“verwendet.

Aufbewahrungs-Policies ermöglichen die Erfassung von Aufbewahrungsfallbeispielenund deren Anwendung auf C-Clips. Unterschiedliche Dokumenttypen könnenbeispielsweise verschiedene Aufbewahrungsfristen haben. Es können folgendeAufbewahrungsfristen festgelegt werden:

l Finanzdokumente: 3 Jahre

l Rechtliche Dokumente: 5 Jahre

l E-Mails: 6 Monate

Wenn eine Aufbewahrungs-Policy auf mehrere C-Clips angewendet wird, ändert sichbei einer Änderung dieser Policy die Aufbewahrungsfrist für alle Objekte, für die diesePolicy gilt.

Aufbewahrungs-Policies werden mit Namespaces in ECS verknüpft und von der CAS-Anwendung als Aufbewahrungsklassen erkannt.

Aufbewahrung auf ECS-Bucket-Level und CASDie Aufbewahrung auf Bucket-Level entspricht nicht der Standardpoolaufbewahrungin Centera. In ECS ist die CAS-Standardaufbewahrung konstant null.

CAS


Verhaltensänderung bei der Standardaufbewahrungsfrist für Objekte, die ohneAufbewahrung auf Objektlevel in Compliance-Namespaces geschrieben wurdenAb ECS 3.0 gilt: Wenn eine Anwendung in einem Compliance-Namespace C-Clips ohneObjektaufbewahrung in einen ECS-CAS-Bucket schreibt und der Bucket einenAufbewahrungswert enthält (z. B. 6 Monate), wird den C-Clips dieStandardaufbewahrungsfrist von unendlich (-1) zugewiesen. Die C-Clips können inkeinem Fall gelöscht werden, da ihre effektive Aufbewahrungsfrist der längsteZeitraum zwischen der Aufbewahrungsfrist auf Bucket-Level und derStandardaufbewahrung auf Objektlevel ist.

Mit dieser Änderung des Verhaltens in ECS 2.2.1 wird ECS mit Centera in Einklanggebracht, wo die Standardpoolaufbewahrung im CE+-Compliancemodus immerunendlich (-1) ist.

In ECS 2.2.1 gilt: Wenn eine Anwendung in einem Compliance-Namespace C-Clipsohne Objektaufbewahrung in einen ECS-CAS-Bucket schreibt und der Bucket einenAufbewahrungswert enthält (z. B. 6 Monate), wird den C-Clips dieAufbewahrungsfrist null (0) zugewiesen. Hier entspricht die effektiveAufbewahrungsfrist für die C-Clips dem Bucket-Aufbewahrungswert (6 Monate). DieC-Clips können in 6 Monaten gelöscht werden.

Nach einem Upgrade von ECS 2.2.1 auf ECS 3.0 oder neuere Versionen schreibenAnwendungen mit dem Verhalten von ECS 2.2.1 C-Clips, die nie gelöscht werdenkönnen.

Halten Sie diese Anwendungen an und konfigurieren Sie sie für die Zuweisung derentsprechenden Aufbewahrung auf Objektlevel, bevor sie mit ECS 3.0 oder neuerenVersionen interagieren.

Im obigen Beispiel muss die Anwendung den C-Clips eine Aufbewahrung aufObjektlevel von 6 Monaten zuweisen.

CAS-VorrangWenn mehrere Aufbewahrungsfristen auf ein CAS-Objekt in ECS angewendet werden,hat die Aufbewahrungsfrist mit dem höheren Wert Vorrang, unabhängig davon, wie dieAufbewahrung angewendet wurde.

Anwenden einer CAS-AufbewahrungSie können Aufbewahrungs-Policies für Namespaces im ECS-Portal oder mit der ECS-Management-API definieren. Siehe Konfigurieren von Namespace-Aufbewahrungs-Policies auf Seite 109.

Ihre externe CAS-Anwendung kann dem C-Clip während dessen Erstellung eine festeAufbewahrungsfrist oder eine Aufbewahrungs-Policy zuweisen.

Bei der Anwendung von Aufbewahrungsfristen über APIs muss die Frist in Sekundenangegeben werden.

Beachten Sie, dass ECS CAS die Aufbewahrung basierend auf der Erstellungszeit desC-Clips und nicht auf der Migrationszeit berechnet.

So erstellen Sie Aufbewahrungs-Policies mit der ECS-Management-API:Sie können Aufbewahrungsfristen und -Policies über die ECS Management-REST-APIerstellen. Im Folgenden finden Sie eine Zusammenfassung.

Tabelle 18 ECS-Management-API-Ressourcen für die Aufbewahrung

Methode Beschreibung

PUT /object/bucket/{bucketName}/retention

Der Aufbewahrungswert für einen Bucketdefiniert eine bindende Aufbewahrungsfrist,

CAS

CAS-Aufbewahrung in ECS 101

Tabelle 18 ECS-Management-API-Ressourcen für die Aufbewahrung (Fortsetzung)

Methode Beschreibung

die auf jedes Objekt im Bucket angewendetwird. Wenn Sie eine Aufbewahrungsfrist von1 Jahr festlegen, kann ein Objekt aus diesemBucket 1 Jahr lang nicht gelöscht werden.

GET /object/bucket/{bucketName}/retention

Gibt die derzeit für einen angegebenenBucket festgelegte Aufbewahrungsfristzurück.

POST /object/namespaces/namespace/{namespace}/retention

Bei Namespaces fungiert dieAufbewahrungseinstellung wie eine Policy,wobei jede Policy ein Paar aus<Name>:<Aufbewahrungsfrist> ist. Für einenNamespace können mehrere Aufbewahrungs-Policies definiert werden. Einem Objektinnerhalb des Namespace kann eine Policynach Name zugewiesen werden. Auf dieseWeise können Sie die Aufbewahrungsfristmehrerer Objekte ändern, denen dieselbePolicy zugewiesen wurde, indem Sie dieentsprechende Policy ändern.

PUT /object/namespaces/namespace/{namespace}/retention/{class}

Aktualisiert die Frist für eine Aufbewahrungs-Policy, die einem Namespace zugewiesen ist.

GET /object/namespaces/namespace/{namespace}/retention

Gibt die für einen Namespace definierteAufbewahrungs-Policy zurück.

Weitere Informationen über die ECS-Management-API finden Sie in der Einführungzur ECS-Management-REST-API auf Seite 120. Die Onlinereferenz befindet sich hier: ECS-API-Referenz.

Erweiterte Aufbewahrung für CAS-Anwendungen:eventbasierte Aufbewahrung, gesetzlicheAufbewahrungsfrist und Min-/Max-Kontrolle

Beschreibung der in der CAS-API verfügbaren erweiterten Aufbewahrungsfunktionen,die von ECS unterstützt werden

Kundenanwendungen verwenden die CAS-API, um Aufbewahrungsstrategienumzusetzen. Wenn CAS-Workloads in ECS migriert werden, ermöglicht die Erkennungder CAS-API-Funktionen durch ECS den Kundenanwendungen die Weiterverwendungder migrierten Daten. In ECS stehen die folgenden ARM-Funktionen (AdvancedRetention Management) ohne separate Lizenz zur Verfügung:

l Eventbasierte Aufbewahrung: die Möglichkeit zum Konfigurieren eines Objektsüber dessen C-Clip zum Anwenden (Auslösen) einer Aufbewahrungsfrist oderAufbewahrungs-Policy, wenn die CAS-Anwendung ein bestimmtes Eventempfängt.

l Gesetzliche Aufbewahrungsfrist: die Möglichkeit, das Löschen eines Objekts zuverhindern, wenn die CAS-Anwendung eine gesetzliche Aufbewahrungsfrist aufdas Objekt über dessen C-Clip angewendet hat. Die CAS-Anwendung kann durch

CAS



Erstellen und Anwenden eindeutiger IDs bis zu 100 gesetzlicheAufbewahrungsfristen auf ein Objekt anwenden.

l Min-/Max-Kontrolle: die Möglichkeit für einen Administrator zum Festlegen vonGrenzwerten für feste oder variable Aufbewahrungsfristen auf Bucket-Level. Fürvariable Aufbewahrungsfristen ist die Unterstützung eventbasierte Aufbewahrungfestgelegt. In ECS können System- oder Namespace-Admins die Werte im ECS-Portal festlegen. Programmierer können die Werte über die ECS-Management-APIfestlegen.

Hinweis

ARM wird für Legacy-CAS-Daten unterstützt, die mit einem beliebigen in ECSmigrierten Namensschema geschrieben wurden.

Min-/Max-Kontrolle für Aufbewahrung auf Bucket-Level in CASSuchen Sie im ECS-Portal nach einem CAS-Bucket und wählen Sie Edit. Alle auf demBildschirm unten angezeigten Steuerelemente sind reine CAS-Funktionen, mitAusnahme des Steuerelements Bucket Retention Period. Bucket Retention Periodist die ECS-Standardfunktion zur Bucket-Aufbewahrung und wird für alle ECS-Bucket-Typen unterstützt.

Abbildung 2 Aufbewahrungsoptionen für CAS-Buckets

Die Aufbewahrungsfunktionen für CAS-Buckets werden in der folgenden Tabelleerläutert.

Feature Beschreibung

EnforceRetention

Wenn dieses Steuerelement aktiviert ist, kann kein CAS-Objekt ohneAufbewahrungsinformationen (Frist oder Policy) erstellt werden. Beim

CAS

Erweiterte Aufbewahrung für CAS-Anwendungen: eventbasierte Aufbewahrung, gesetzliche Aufbewahrungsfrist und Min-/

Max-Kontrolle 103


Information inObject

Versuch, solche Objekte zu speichern, wird ein Fehler zurückgegeben.

Wenn Bucket Retention Period aktiviert ist, ist es auch incompliancefähigen Umgebungen möglich, dieses Steuerelement nicht zukonfigurieren.

Hinweis

Wenn Centera im CE+-Modus in ECS migriert wird, ist EnforceRetention Information in Object standardmäßig für den Bucketaktiviert.

Bucket RetentionPeriod

Wenn eine Bucket-Aufbewahrungsfrist angegeben ist, wird die längereFrist durchgesetzt, sofern Aufbewahrungsfristen sowohl auf Bucket-Levelals auch auf Objektlevel vorhanden sind.

In einer compliancefähigen Umgebung ist Bucket Retention Periodobligatorisch, es sei denn, die Aufbewahrungsinformationen im Objekt

werden durchgesetzt. Wenn Bucket Retention Period jedoch einmalkonfiguriert wurde, kann diese Frist nicht mehr zurückgesetzt werden,selbst wenn die Aufbewahrungsinformationen des Objekts durchgesetztwerden.

Minimum FixedRetention Period

Diese Funktion regelt die in Objekten angegebenen Aufbewahrungsfristen.Wenn die Aufbewahrungsfrist eines Objekts außerhalb der hierangegebenen Grenzen liegt, schlägt ein Schreibversuch für das Objektfehl.Bei Verwendung von Aufbewahrungs-Policies werden die Min-/Max-Einstellungen nicht durchgesetzt.

Wenn Sie unter Minimum Fixed Retention Period die Option Infiniteauswählen, müssen alle Aufbewahrungswerte unbegrenzt sein. Wenn Sie

diese Option unter Maximum Fixed Retention Period auswählen, gibtes keine Obergrenze.

Die Einschränkungen für die minimale/maximale Aufbewahrung werdenauf alle in einen Bucket geschriebene C-Clips angewendet. Wenn ein Clipvon einem SDK-basierten Drittanbietertool migriert wird, muss dieAufbewahrung innerhalb der Grenzen liegen, da andernfalls ein Fehlerausgegeben wird.

Maximum FixedRetention Period

Minimum VariableRetention Period

Diese Funktion regelt die in Objekten angegebenen variablenAufbewahrungsfristen mithilfe von EBR (Event-Based Retention,eventbasierte Aufbewahrung). Bei der EBR wird eineBasisaufbewahrungsfrist festgelegt und die programmierteTriggerfunktion kann die Aufbewahrungsfrist verlängern, wenn der Triggerausgelöst wird. Wenn die neue Aufbewahrungsfrist eines Objektsaußerhalb der hier angegebenen Grenzen liegt, schlägt ein Schreibversuchfür das Objekt als Reaktion auf den Trigger fehl.Bei Verwendung von Aufbewahrungs-Policies werden die Min-/Max-Einstellungen nicht durchgesetzt.

Wenn Sie unter Minimum Variable Retention Period die Option

Infinite auswählen, müssen alle Aufbewahrungswerte unbegrenzt sein.

Wenn Sie diese Option unter Maximum Variable Retention Periodauswählen, gibt es keine Obergrenze.

MaximumVariableRetention Period

CAS



Die Einschränkungen für die minimale/maximale Aufbewahrung werdenauf alle in einen Bucket geschriebene C-Clips angewendet. Wenn ein Clipvon einem SDK-basierten Drittanbietertool migriert wird, muss dieAufbewahrung innerhalb der Grenzen liegen, da andernfalls ein Fehlerausgegeben wird.

Hinweis

Wenn der Systemadministrator oder -programmierer keine Werte für die festen undvariablen Aufbewahrungsfristen festgelegt hat, gibt die get-Funktion der ECS-Management-API keine Werte für die Min-/Max-Einstellungen zurück. DasSteuerelement Enforce Retention Informationen in C-Clip gibt den Standardwertfalse zurück.

Eventbasierte AufbewahrungEBR (Event-Based Retention, eventbasierte Aufbewahrung) ist eine Anweisung, dieangibt, dass ein Datensatz vor einem Event und während einer angegebenen Fristnach dem Event nicht gelöscht werden kann. In CAS ist EBR ein C-Clip mit einerangegebenen Basisaufbewahrungsfrist oder Aufbewahrungs-Policy und einemanwendungsspezifischen Trigger, der eine längere Aufbewahrungsfrist festlegen kann,wenn der Trigger ausgelöst wird. Die Aufbewahrungsfrist beginnt erst, wenn derTrigger ausgelöst wird. Wenn ein C-Clip für EBR markiert ist, kann er vor dem Eventnicht gelöscht werden, es sei denn, ein privilegierter Löschvorgang wird verwendet.

Bei Verwendung von EBR ist der C-Clip-Lebenszyklus wie folgt:

l Erstellen: Die Anwendung erstellt einen neuen C-Clip und markiert ihn für EBR. DieAnwendung kann eine feste Aufbewahrungsfrist angeben, die als minimaleAufbewahrung fungiert. Außerdem muss eine eventbasierte Aufbewahrungsfristoder Policy angegeben werden.

l Event auslösen: Die Anwendung löst das Event aus, das den Ausgangspunkt dereventbasierten Aufbewahrungsfrist oder Aufbewahrungs-Policy markiert. Andiesem Punkt kann die Anwendung eine neue eventbasierte Aufbewahrungsfristzuweisen, sofern diese länger als die beim Erstellen des C-Clips zugewiesene Fristist.

l Löschen: Wenn die Anwendung versucht, den C-Clip zu löschen, müssen diefolgenden Bedingungen erfüllt sein:

n Die Policy-(Namespace-)Aufbewahrungsfrist ist abgelaufen.

n Die Bucket-Aufbewahrungsfrist ist abgelaufen.

n Die feste Aufbewahrungsfrist ist abgelaufen.

n Das Event wurde ausgelöst.

n Sowohl die beim Erstellen festgelegte EBR als auch alle nachfolgendenÄnderungen (Erweiterungen) während des Events sind abgelaufen.

Die folgende Abbildung zeigt die drei möglichen Szenarien für C-Clips mit EBR:

l Für C1 gilt eine feste oder minimale Aufbewahrungsfrist, die bereits vor Auslösungdes Events abgelaufen ist.

l Für C2 gilt eine feste oder minimale Aufbewahrungsfrist, die vor Ablauf der EBRabläuft.

l Für C3 gilt eine feste oder minimale Aufbewahrungsfrist, die nach Ablauf der EBRabläuft.

CAS


Max-Kontrolle 105

Abbildung 3 EBR-Szenarien

Bei nicht vorgabenkonformen Namespaces können feste und variableAufbewahrungsfristen für EBR mit privilegierten Löschbefehlen überschriebenwerden.

Beim Anwenden einer EBR-Aufbewahrung muss diese den Min-/Max-Kontrolleinstellungen für die variable Aufbewahrungsfrist entsprechen.

Tabelle 19 CAS-API-Funktionen für EBR (Event-Based Retention, eventbasierte Aufbewahrung)

Funktion Beschreibung

FPClip_EnableEBRWithClass Diese Funktion legt fest, dass ein C-Clip zumEmpfang eines zukünftigen Events berechtigtist, und ermöglicht die Zuweisung einer EBR-Klasse zum C-Clip während dessen Erstellung.

FPClip_EnableEBRWithPeriod Diese Funktion legt fest, dass ein C-Clip zumEmpfang eines zukünftigen Events berechtigtist, und ermöglicht die Zuweisung einer EBR-Frist zum C-Clip während dessen Erstellung.

FPClip_IsEBREnabled Diese Funktion gibt einen booleschen Wertzurück, der angibt, ob ein C-Clip für EBRaktiviert ist.

FPClip_GetEBRClassName Diese Funktion ruft den Namen der dem C-Clipzugewiesenen EBR-Policy ab.

FPClip_GetEBREventTime Diese Funktion gibt die in einem C-Clipfestgelegte Uhrzeit der Auslösung des EBR-Events für diesen C-Clip zurück.

FPClip_GetEBRPeriod Diese Funktion gibt den Wert (in Sekunden) dereinem C-Clip zugeordneten EBR-Frist zurück.

FPClip_TriggerEBREvent Diese Funktion löst das Event eines C-Clips aus,für den EBR aktiviert wurde.

CAS


Tabelle 19 CAS-API-Funktionen für EBR (Event-Based Retention, eventbasierteAufbewahrung) (Fortsetzung)


FPClip_TriggerEBREventWithClass Diese Funktion löst das Event eines C-Clips aus,für den EBR aktiviert wurde, und weist dem C-Clip eine neue EBR-Policy zu.

FPClip_TriggerEBREventWithPeriod Diese Funktion löst das Event eines C-Clips aus,für den EBR aktiviert wurde, und weist dem C-Clip eine neue EBR-Frist zu.

Gesetzliche AufbewahrungsfristMit einer gesetzlichen Aufbewahrungsfrist können CAS-Anwendungen das Löscheneines C-Clips vorübergehend verhindern. Eine gesetzliche Aufbewahrungsfrist ist fürDaten nützlich, die aufgrund offizieller Ermittlungen, behördlicher Anordnungen oderBefragungen nicht gelöscht werden dürfen, bevor die entsprechenden Ermittlungenabgeschlossen sind. Sobald die Daten nicht mehr aufbewahrt werden müssen, kann diegesetzliche Aufbewahrungsfrist von der Anwendung aufgehoben und das normaleAufbewahrungsverhalten wiederaufgenommen werden. GesetzlicheAufbewahrungsfristen werden von der CAS-Anwendung auf C-Clip-Ebene festgelegtbzw. entfernt.

Hinweis

C-Clips mit gesetzlicher Aufbewahrungsfrist können auch durch privilegierteLöschvorgänge nicht gelöscht werden.

Für einen C-Clip können mehrere gesetzliche Aufbewahrungsfristen gelten. DieAnwendung muss eindeutige IDs für die gesetzlichen Aufbewahrungsfristen erzeugenund die jeweiligen einem C-Clip zugeordneten Fristen nachverfolgen können. DieAnwendung kann diese Informationen nicht von C-Clips abfragen. Es gibt lediglich eineFunktion zur Ermittlung des Status der gesetzlichen Aufbewahrungsfrist eines C-Clips. Wenn für den C-Clip eine oder mehrere gesetzliche Aufbewahrungsfristengelten, gibt diese Funktion „true“ und andernfalls „false“ zurück.

Bei Verwendung der gesetzlichen Aufbewahrungsfrist ist der C-Clip-Lebenszyklus wiefolgt:

l Erstellen: Die Anwendung erstellt einen neuen C-Clip und gibt eine feste und/odereventbasierte Aufbewahrungsfrist an.

l Gesetzliche Aufbewahrungsfrist festlegen: Eine Anwendung legt eine Frist für denC-Clip fest. Diese Anwendung kann sich von der Anwendung unterscheiden, dieden C-Clip geschrieben hat.

l Gesetzliche Aufbewahrungsfrist aufheben: Eine Anwendung hebt die Frist für denC-Clip auf. Diese Anwendung kann sich von der Anwendung unterscheiden, die diegesetzliche Aufbewahrungsfrist festgelegt oder den C-Clip geschrieben hat.

l Delete: Wenn die Anwendung versucht, den C-Clip zu löschen, müssen diefolgenden Bedingungen erfüllt sein:

n Für den C-Clip stehen keine weiteren gesetzlichen Aufbewahrungsfristen aus.

n Die Policy-Aufbewahrungsfrist ist abgelaufen.

n Die Bucket-Standardaufbewahrungsfrist ist abgelaufen. (Die Bucket-Standardaufbewahrungsfrist ist für alle ECS-Objekttypen verfügbar, wird fürCAS jedoch nicht empfohlen.)

CAS


Max-Kontrolle 107

n Die feste Aufbewahrungsfrist ist abgelaufen (reine CAS-Funktion).

n Die Frist für die eventbasierte Aufbewahrung ist abgelaufen (reine CAS-Funktion).

Die folgende Abbildung zeigt die drei möglichen Szenarien für C-Clips mit gesetzlicherAufbewahrungsfrist:

l Für C1 gilt eine feste Aufbewahrungsfrist, die beim Festlegen der gesetzlichenAufbewahrungsfrist bereits abgelaufen ist.

l Für C2 gilt eine feste Aufbewahrungsfrist, die während der gesetzlichenAufbewahrungsfrist abläuft.

l Für C3 gilt eine feste Aufbewahrungsfrist, die nach dem Aufheben dergesetzlichen Aufbewahrungsfrist abläuft.

Abbildung 4 Szenarien für gesetzliche Aufbewahrungsfristen

Einem C-Clip können mehrere gesetzliche Aufbewahrungsfristen zugewiesen werden.Wenn dies der Fall ist, erfordert jede gesetzliche Aufbewahrungsfrist einen separatenAPI-Aufruf mit einer eindeutigen Kennung für die gesetzliche Aufbewahrungsfrist.

Hinweis

Die ID einer gesetzlichen Aufbewahrungsfrist darf maximal 64 Zeichen enthalten. EinC-Clip darf maximal 100 IDs für gesetzliche Aufbewahrungsfristen enthalten. DieseEinschränkungen werden von der CAS-API durchgesetzt.

Tabelle 20 CAS-API-Funktionen für gesetzliche Aufbewahrungsfristen


FPClip_GetRetentionHold Diese Funktion ermittelt den Status dergesetzlichen Aufbewahrungsfrist eines C-Clips und gibt „true“ oder „false“ zurück.

FPClip_SetRetentionHold Diese Funktion legt eine gesetzlicheAufbewahrungsfrist für einen C-Clip festoder hebt sie auf. Bei mehrerengesetzlichen Aufbewahrungsfristen muss

CAS


Tabelle 20 CAS-API-Funktionen für gesetzliche Aufbewahrungsfristen (Fortsetzung)


für jede gesetzliche Aufbewahrungsfristeine eindeutige ID angegeben werden. Beimehreren gesetzlichenAufbewahrungsfristen ist nur ein Aufruf proID möglich.

Konfigurieren von Namespace-Aufbewahrungs-PoliciesCAS-spezifische Konfigurationsanweisungen für Namespace-Aufbewahrungs-Policies

Die Funktion „Retention Policy“ für Namespaces ermöglicht das Definieren undManagen von CAS-Aufbewahrungsklassen für alle im Namespace erstellten C-Clips.

Ein Namespace kann über viele Aufbewahrungs-Policies verfügen. Jede Policydefiniert eine Aufbewahrungsfrist. Durch die Anwendung einer Aufbewahrungs-Policyauf mehrere C-Clips (über die API) wird bei einer Änderung der Aufbewahrungs-Policydie Aufbewahrungsfrist für alle mit der Policy verknüpften Objekte geändert. Bei CASwerden Aufbewahrungsklassen über die Anwendung auf den C-Clip eines Objektsangewendet. Für ein Objekt, das einer Aufbewahrungsfrist unterliegt, sind keineÄnderungsanforderungen zulässig.

Vorgehensweise

1. Wählen Sie im ECSPortal, Manage > Namespace aus.

2. Wählen Sie zum Bearbeiten der Konfiguration eines vorhandenen Namespacedie mit dem Namespace verbundene Aktion Edit aus.

3. Fügen Sie Aufbewahrungs-Policies hinzu und konfigurieren Sie sie.

a. Wählen Sie im Bereich „Retention Policies“ Add aus, um eine neue Policyhinzuzufügen.

b. Geben Sie einen Namen für die Policy ein.

c. Geben Sie eine Frist für die Aufbewahrungs-Policy ein.

Aktivieren Sie das Kontrollkästchen Infinite, wenn Objekte mit dieser Policynie gelöscht werden sollen.

CAS

Konfigurieren von Namespace-Aufbewahrungs-Policies 109

Abbildung 5 Neue Aufbewahrungs-Policy


Abbildung 6 Aufbewahrungs-Policies für einen Namespace

Erstellen und Einrichten eines Bucket für einen CAS-Benutzer

Konfigurieren eines Bucket für den Support eines CAS-Benutzers

In ECS erstellen Managementbenutzer Buckets und werden zu Bucket-Eigentümern.Für CAS müssen Objektbenutzer als Bucket-Eigentümer festgelegt werden. BefolgenSie dieses Verfahren, um einen CAS-Bucket ordnungsgemäß einzurichten und denCAS-Benutzer als Bucket-Eigentümer festzulegen. In diesem Beispiel istnewcasadmin1 ein Managementbenutzer, newcasuser1 ein CAS-Objektbenutzer undnewcasns1 der Namespace. Bei diesem Verfahren wird davon ausgegangen, dass diebeiden Benutzer und Namespaces eingerichtet wurden.

Vorgehensweise

1. Melden Sie sich als newcasadmin1 beim ECS-Portal an.

2. Wählen Sie im ECSPortal Manage > Bucket aus.

3. Wählen Sie New Bucket aus.

CAS


4. Füllen Sie die Felder wie unten dargestellt aus:

Feld Wert

Replication Group Ihre Replikationsgruppe

Set current user as Bucket Owner Prüfen

CAS Aktiviert

5. Wählen Sie Save aus.

6. Wählen Sie Manage > User aus.

7. Vergewissern Sie sich, dass die Registerkarte Object User aktiv ist, suchen Sienach newcasuser1 und wählen Sie Edit aus.

8. Geben Sie unter Default Bucket den Text newcasbucket1 ein und wählen SieSet Bucket aus.

9. Wählen Sie Close aus.

10. Wählen Sie Manage > Bucket aus.

11. Suchen Sie nach newcasbucket1 und wählen Sie Edit Bucket aus.

12. Geben Sie unter Bucket Owner den Text newcasuser1 ein.

13. Wählen Sie Save aus.

Einrichten eines CAS-ObjektbenutzersEinrichten eines Objektbenutzers für die Verwendung von CAS

Bei der Einrichtung eines Objektbenutzers können Sie dem Profil CAS-Funktionenzuweisen, die die Elemente eines CAS-Profils bilden. Die resultierende PEA-Datei kannin CAS-Anwendungen angezeigt werden.

Vorgehensweise

1. Wählen Sie im ECSPortal Manage > Users aus.

2. Wählen Sie zum Bearbeiten der Konfiguration eines vorhandenenObjektbenutzers die mit dem Benutzer verbundene Aktion Edit aus.

CAS

Einrichten eines CAS-Objektbenutzers 111

Abbildung 7 CAS-Einstellungen für Objektbenutzer

3. Geben Sie im CAS-Bereich ein Passwort (Schlüssel) ein oder wählen SieGenerate, um ein Passwort vom Portal erstellen zu lassen.

4. Wählen Sie Set Password aus.

5. Wählen Sie Generate PEA File aus, um die PEA-Datei zu erzeugen, die IhreAnwendung zur Authentifizierung beim CAS-Speicher auf ECS benötigt.

6. Durch die Festlegung eines Standard-Bucket wird für jede Aktion desBenutzers, für die kein Bucket angegeben ist, der angegebene Standard-Bucketverwendet. Geben Sie den Namen des Standard-Bucket ein und wählen Sie SetBucket aus.

7. Wählen Sie Add Attribute aus, um dem Benutzer ein Metadaten-Taghinzuzufügen.

8. Geben Sie einen Namen und einen Wert für das Metadaten-Tag ein.

Weitere Informationen zu Metadaten-Tags finden Sie in der CAS-SDK-Dokumentation.

9. Wählen Sie Save Metadata aus.

Konfigurieren von Bucket-ACLs für CASBearbeiten einer Bucket-ACL zur Beschränkung des Benutzerzugriffs

Einige ECS-Bucket-ACLs sind CAS-Berechtigungen zugeordnet und einige habenkeine Bedeutung für CAS-Daten.

Vorgehensweise

1. Wählen Sie im ECSPortal Manage > Bucket aus.

2. Wählen Sie zum Bearbeiten der ACLs eines vorhandenen Bucket die mit demBucket verbundene Aktion Edit ACL aus.

CAS


Abbildung 8 Bearbeiten einer Bucket-ACL

3. Wählen Sie die mit dem Benutzer verbundene Aktion Edit aus.

Abbildung 9 Managen von Bucket-ACLs

4. Ändern Sie die Berechtigungen.

Tabelle 21 Bucket-ACLs

ECS-ACL ACL-Definition

READ Read, Query und Exist

CAS

Konfigurieren von Bucket-ACLs für CAS 113

Tabelle 21 Bucket-ACLs (Fortsetzung)

ECS-ACL ACL-Definition

WRITE Write und Litigation Hold

FULL_CONTROL Read, Delete, Query, Exist, Clip Copy, Write,Litigation Hold

PRIVILEGED_WRITE Privileged Delete

DELETE Delete

Hinweis

Andere von ECS-ACLs haben keine Bedeutung für CAS.


6. Sie können ACLs auch auf Gruppenlevel bearbeiten. Gruppen sind vordefiniert.Die Mitgliedschaft in der Gruppe wird automatisch basierend aufBenutzerkriterien festgelegt. Wählen Sie Group ACLs aus.

7. Wählen Sie Add aus.

8. Wählen Sie die Gruppe, die Sie bearbeiten möchten, aus der Liste Group Nameaus.

Tabelle 22 Bucket-ACL-Gruppen

Bucket-ACL-Gruppe Beschreibung

public Alle authentifizierten und nichtauthentifizierten Benutzer

all users Alle authentifizierten Benutzer

other Authentifizierte Benutzer ausgenommenBucket-Eigentümer

log delivery Nicht unterstützt

9. Wählen Sie die ACLs aus und klicken Sie auf Save.

ECS-Management-APIs, die CAS-Benutzer unterstützenBeschreibung der ECS-Management-API-Ressourcen, die zum Managen von CAS-Benutzer- und Profileinstellungen verwendet werden können

Beschreibung der ECS-Management-API-Ressourcen:

l GET /object/user-cas/secret/{uid} : ruft den CAS-Schlüssel für denangegebenen Benutzer ab

l GET /object/user-cas/secret/{namespace}/{uid}: ruft den CAS-Schlüssel für den angegebenen Namespace und Benutzer ab

l POST /object/user-cas/secret/{uid}: erstellt oder aktualisiert den CAS-Schlüssel für einen angegebenen Benutzer

l GET /object/user-cas/secret/{namespace}/{uid}/pea: erzeugt einePEA-Datei für den angegebenen Benutzer

CAS


l POST /object/user-cas/secret/{uid}/deactivate: löscht den CAS-Schlüssel für einen angegebenen Benutzer

l GET /object/user-cas/bucket/{namespace}/{uid}: ruft den Standard-Bucket für den angegebenen Namespace und Benutzer ab

l GET /object/user-cas/bucket/{uid}: ruft den Standard-Bucket für einenangegebenen Benutzer ab

l POST /object/user-cas/bucket/{namespace}/{uid}: aktualisiert denStandard-Bucket für den angegebenen Namespace und Benutzer

l GET /object/user-cas/applications/{namespace}: ruft die CAS-registrierten Anwendungen für einen angegebenen Namespace ab

l POST /object/user-cas/metadata/{namespace}/{uid}: aktualisiert dieCAS-registrierten Anwendungen für einen angegebenen Namespace und Benutzer

l GET /object/user-cas/metadata/{namespace}/{uid}: ruft die CAS-Benutzermetadaten für den angegebenen Namespace und Benutzer ab

Weitere Informationen dazu finden Sie unter .

CAS-SDK-API-Support (Content Addressable Storage)Unterstützte VersionenECS unterstützt den CAS-Build 3.1.544 oder höher. Darüber hinaus sollten Sieüberprüfen, dass die Anwendung Ihres ISV ECS unterstützt.

Weitere Informationen zum ECS-CAS-Support finden Sie unter Einrichten des CAS-Supports in ECS auf Seite 96.

CAS-AbfragesupportDie CAS-Abfrage wird ab ECS 2.2 unterstützt.

Hinweis

In ECS geben CAS-Abfragevorgänge Ergebnisse basierend auf der Erstellungszeit desvorhandenen C-Clips und der Löschzeit des gelöschten C-Clips (Reflexion) aus. InEMC Centera geben Abfragevorgänge Ergebnisse basierend auf dem Schreibzeitpunktdes Objekts aus.

Nicht unterstützte APIs in den ECS-Versionen vor ECS 3.0CAS-SDK-API-Aufrufe, die in Versionen von ECS vor ECS 3.0 nicht unterstütztwerden:

l FPClip_EnableEBRWithClass

l FPClip_EnableEBRWithPeriod

l FPClip_SetRetentionHold

l FPClip_TriggerEBREvent

l FPClip_ TriggerEBREventWithClass

l FPClip_ TriggerEBREventWithPeriod

l FPClip_GetEBRClassName

l FPClip_GetEBREventTime

l FPClip_GetEBRPeriod

l FPClip_GetRetentionHold

CAS

CAS-SDK-API-Support (Content Addressable Storage) 115

l FPClip_IsEBREnabled

CAS


TEIL 5

ECS Management-REST-API

Kapitel 5, "ECS Management-REST-API"




KAPITEL 5


l Einführung zur ECS-Management-REST-API...................................................120l Authentifizieren Sie sich bei der ECS-Management-REST-API........................ 120


Einführung zur ECS-Management-REST-APIDieser Abschnitt beschreibt den Zugriff auf und die Authentifizierung bei der ECSManagement-REST-API und bietet eine Übersicht über die API-Pfade. Sie können denObjektspeicher mit der ECS Management-REST-API konfigurieren und verwalten.Wenn der Objektspeicher konfiguriert wurde, können Sie Erstell-, Lese-, Aktualisier-und Löschvorgänge mit den von ECS unterstützten Objekt- und Dateiprotokollendurchführen.

Weitere Informationen zur ECS Management-REST-API finden Sie unter diesenThemen:

l Authentifizieren Sie sich bei der ECS-Management-REST-API. auf Seite 120

l ECS-Management-REST-API – Zusammenfassung auf Seite 123

Die ECS-API-Referenz wird automatisch aus dem Quellcode generiert und stellt eineweitere Referenz für die in der API verfügbaren Methoden dar.

Authentifizieren Sie sich bei der ECS-Management-REST-API.

ECS verwendet ein tokenbasiertes Authentifizierungssystem für REST-API-Aufrufe.Dieser Abschnitt enthält Beispiele für die Authentifizierung mit der ECS-API mit undohne Cookies:

Wenn Sie vom ECS authentifiziert werden, gibt die ECS-API einAuthentifizierungstoken zurück. Sie können dieses Token zur Authentifizierung innachfolgenden Aufrufen verwenden.

l Die ECS-API gibt HTTP-Code 401 zurück, wenn der Client automatischUmleitungen folgt. Sie müssen sich dann anmelden und authentifizieren, um einneues Token zu erhalten.

l Die ECI-API gibt HTTP-Code 302 zurück, wenn der Client nicht automatischUmleitungen folgt. Der Code 302 leitet den Client an die Stelle, wo er erneutauthentifiziert werden kann.

Sie können Authentifizierungstoken wie folgt abrufen und verwenden:

l Speichern des Cookies X-SDS-AUTH-TOKEN aus einer erfolgreichenAuthentifizierungsanforderung und Mitsenden dieses Cookies mit nachfolgendenAnforderungen

l Lesen des HTTP-Headers X-SDS-AUTH-TOKEN HTTP aus einer erfolgreichenAuthentifizierungsanforderung und Kopieren des Headers in nachfolgendeAnforderungen

Die ECS-API ist auf Port 4443 verfügbar. Clients greifen auf ECS zu durch Ausgabeeiner Anmeldeanforderung in der Form:

https://<ECS_IP>:4443/login

Authentifizierung ohne CookiesIn folgendem Beispiel wird gezeigt, wie Sie Authentifizierungstoken verwenden, indemSie den X-SDS-AUTH-TOKEN-HTTP-Header aus einer erfolgreichenAuthentifizierungsanforderung lesen und dann diesen Header in eine nachfolgende




Anforderung kopieren. In diesem Beispiel werden keine Cookies verwendet. DieBeispiele wurden mithilfe des curl Befehlszeilentools geschrieben und zur besserenLesbarkeit formatiert.

Der folgende ECS-API-Aufruf führt ein GET für die Ressource /login aus. Die Option-u bezeichnet den Benutzer des Basisauthentifizierungsheaders. Sie müssen denBenutzer in der Anforderung angeben. Nach erfolgreicher Authentifizierung gibt dieECS-API den HTTP-Code 200 sowie den X-SDS-AUTH-TOKEN-Header mit demcodierten Token zurück.

Die Standardlebensdauer eines ECS-API-Tokens beträgt 8 Stunden, d. h. das Tokenist nach 8 Stunden nicht mehr gültig. Die Standard-Inaktivitätsdauer eines Tokensbeträgt 2 Stunden. Nach einer Inaktivitätsdauer von 2 Stunden läuft das Token ab.Wenn Sie ein abgelaufenes Token verwenden, werden Sie zur URL /loginweitergeleitet. Sie erhalten einen HTTP-Status-Fehlercode 401 bei jedernachfolgenden Nutzung des abgelaufenen Tokens.

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: BAAcQ0xOd3g0MjRCUG4zT3NJdnNuMlAvQTFYblNrPQMAUAQADTEzODU0OTQ4NzYzNTICAAEABQA5dXJu OnN0b3JhZ2VvczpUb2tlbjo2MjIxOTcyZS01NGUyLTRmNWQtYWZjOC1kMGE3ZDJmZDU3MmU6AgAC0A8=<<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn> <user>root</user></loggedIn>* Connection #0 to host 10.247.100.247 left intact* Closing connection #0* SSLv3, TLS alert, Client hello (1):

Sie können die X-SDS-AUTH-TOKEN-Inhalte kopieren und über den Switch -H desCurl-Tools an den nächsten API-Anruf weitergeben, wie im folgenden Beispiel gezeigt.

curl https://10.247.100.247:4443/object/namespaces -k -H "X-SDS-AUTH-TOKEN: BAAcOHZLaGF4MTl3eFhpY0czZ0tWUGhJV2xreUE4PQMAUAQADTEzODU0OTQ4NzYzNTICAAEABQA5dXJu OnN0b3JhZ2VvczpUb2tlbjpkYzc3ODU3Mi04NWRmLTQ2YjMtYjgwZi05YTdlNDFkY2QwZDg6AgAC0A8="

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <namespaces> <namespace> <id>ns1</id> <link rel="self" href="/object/namespaces/namespace/ns1"/> <names>ns1</name>


Authentifizierung ohne Cookies 121

</namespace></namespaces>

Authentifizierung mit CookiesIn diesem Beispiel wird gezeigt, wie Sie Authentifizierungstoken verwenden, indem Siedas Cookie aus einer erfolgreichen Authentifizierungsanforderung speichern und dannan eine nachfolgende Anforderung übergeben.

Im folgenden Beispiel wird der Parameter ?using-cookies=true verwendet, umdarauf hinzuweisen, dass Sie zusätzlich zum normalen HTTP-Header Cookies erhaltenmöchten. Mit diesem Curl-Befehl wird das Authentifizierungstoken im aktuellenVerzeichnis in einer Datei namens cookiefile gespeichert.

curl -L --location-trusted -k https://<ECS_IP>:4443/login?using-cookies=true -u "root:Password" -c cookiefile -v

Der folgende Befehl gibt den Cookie mit dem Authentifizierungstoken über den Switch-b des Curl-Befehls weiter und gibt die Mandanteninformationen des Benutzerszurück.

curl -k https://10.247.100.247:4443/object/namespaces -b cookiefile -v

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <namespaces> <namespace> <id>ns1</id> <link rel="self" href="/object/namespaces/namespace/ns1"/> <names>ns1</name> </namespace></namespaces>

AbmeldenDie Abmelde-API beendet eine Sitzung.

Jeder Benutzer darf maximal 100 gleichzeitige Authentifizierungstoken besitzen. Wirddiese Beschränkung überschritten, verweigert das System jede neue Verbindung füreinen Benutzer, bis es wieder freie Token gibt. Token können frei werden, indem sieganz normal ihr Ablaufdatum erreichen, oder indem der folgende ECS-API-Aufrufausgegeben wird:

GET https://<ECS_IP>:4443/logout

Wenn Sie mehrere Sitzungen gleichzeitig ausführen, erzwingt der folgende API-Aufrufdie Beendigung aller Token, die mit dem aktuellen Benutzer zusammenhängen.

GET https://<ECS_IP>:4443/logout?force=true



Das folgende Beispiel zeigt eine Abmeldeanforderung. Für die Abmeldung übergebenSie das Authentifizierungstoken vom Header oder vom Cookie.

GET https://<ECS_IP>:4443/logout

X-SDS-AUTH-TOKEN:{Auth_Token}

Die Antwort sollte HTTP 200 sein.

ECS Management-REST-API Whoami-BefehlEin ECS-Benutzer kann den eigenen Benutzernamen, die Mandantenzuordnung undseine Rollen über den whoami-API-Aufruf anzeigen.

Anfrage

GET https://<ECS_IP>:4443/user/whoami

Die folgenden Antworten zeigen die whoami-Ausgabe für den Root-Benutzer und füreinen Benutzer, dem die Rolle NAMESPACE_ADMIN für den Namespace ns1zugewiesen wurde.

Antwort

HTTP 200

GET /user/whoami<user> <common_name>root</common_name> <distinguished_name/> <namespace/> <roles> <role>SYSTEM_ADMIN</role> </roles></user>

HTTP 200

GET /user/whoami<user> <common_name>[email protected]</common_name> <distinguished_name/> <namespace>ns1</namespace> <roles> <role>NAMESPACE_ADMIN</role> </roles></user>

ECS-Management-REST-API – ZusammenfassungMit der ECS Management-REST-API kann der ECS-Objektspeicher konfiguriert undverwaltet werden.

In der folgenden Tabelle ist die ECS Management-REST-API zusammengefasst:


ECS Management-REST-API Whoami-Befehl 123

Tabelle 23 ECS Management-REST-API– Zusammenfassung der Methoden

API-Bereich Beschreibung

Konfiguration

Zertifikat /object-certAPI zur Verwaltung von Zertifikaten.

/object-cert/keystoreAPI zur Festlegung und Rotation der von ECS verwendetenZertifikatskette.

Konfigurations-eigenschaften

/config/object/propertiesAPI, die den Benutzerumfang auf GLOBAL oder NAMESPACEfestlegt. Diese Einstellung muss festgelegt werden, bevor der ersteBenutzer erstellt wird. Die Standardeinstellung ist GLOBAL.

GLOBAL bedeutet, dass Benutzer global sind und über Namespaceshinweg gemeinsam verwendet werden können. In diesem Fallbestimmt der mit einem Benutzer verbundene Standard-Namespaceden Namespace für Objektvorgänge und es muss kein Namespace füreinen Vorgang bereitgestellt werden. Im NAMESPACE-Umfang ist einBenutzer mit einem Namespace verknüpft. In diesem Fall istmöglicherweise mehr als ein Benutzer mit demselben Namenvorhanden, jeweils mit einem unterschiedlichen Namespace verknüpft,und für jeden Vorgang muss ein Namespace bereitgestellt werden.

Lizenzierung /licenseAPI, mit der eine Lizenz hingefügt werden kann und Lizenzdetailsabgerufen werden können.

Komponente /feature/API für den Abruf der Details einer Komponente.

Syslog /vdc/syslog/configAPI für das Management der Syslog-Konfiguration und zum Sendenvon Warnmeldungen an den Syslog-Server zu Troubleshooting- undDebuggingzwecken.

SNMP /vdc/snmp/configAPI zur Verwaltung der SNMP-Konfiguration und zum Senden vonWarnmeldungen an den SNMP-Server zu Troubleshooting- undDebuggingzwecken

CAS

CAS-Benutzerprofil /object/user-casAPI für die Zuweisung von geheimen Schlüsseln zu CAS-Benutzernund zur Erstellung der PEA-Datei (Pool Entry Authorization).

Dateisystemzugriff

NFS /object/nfs



Tabelle 23 ECS Management-REST-API– Zusammenfassung der Methoden (Fortsetzung)


API für die Erstellung eines NFS-Exports auf der Grundlage einesECS-Buckets und für den Zugriff auf den Export durch UNIX-Benutzer und -Gruppen.

Messung

Fakturierung /object/billingAPI zur Messung der Objektspeichernutzung auf Mandanten- undBucket-Ebene.

Migration

Transformation /object/transformationAPI für Datentransformationen.

Monitoring

Kapazität /object/capacityAPI zum Abruf der derzeit verwalteten Kapazität.

Dashboard

Warnmeldungen /vdc/alertsAPI zum Abruf von Audit-Warnmeldungen.

Ereignisse /vdc/eventsAPI, mit der die Audit-Ereignisse für einen angegebenen Namespacezurückgegeben werden.

Mehrmandantenfähigkeit

Namespace /object/namespacesAPI zur Erstellung und Verwaltung eines Namespace.

Mit dieser API wird zudem die Aufbewahrungsfrist für den Namespacefestgelegt. Weitere Informationen zu Aufbewahrungsfristen finden Sieim ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.

Geo-Replikation

Replication Group /data/data-service/vpoolsAPI zur Erstellung und Verwaltung von Replikationsgruppen.

Temporary FailedZone

/tempfailedzone/API zum Abruf aller temporär fehlgeschlagen Zonen oder der temporärfehlgeschlagenen Zonen für eine bestimmte Replikationsgruppe.

Provisioning

Basis-URL /object/baseurlAPI zur Erstellung einer Basis-URL, die es vorhandenen Anwendungenermöglicht, mit dem ECS-Objektspeicher zu arbeiten. Weitere


ECS-Management-REST-API – Zusammenfassung 125





Informationen zur Basis-URL finden Sie im ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.

Bucket /object/bucketAPI zur Bereitstellung und Verwaltung von Buckets.

/object/bucket/{bucketName}/lockAPI zum Sperren des Bucket-Zugriffs.

Datenspeicher /vdc/data-storesAPI zur Erstellung von Datenspeichern auf Dateisystemen (/vdc/data-stores/filesystems) oder auf Standardnodes (/vdc/data-stores/commodity).

Node /vdc/nodesAPI zum Abrufen der Nodes, die derzeit für den Cluster konfiguriertsind

Speicherpool /vdc/data-services/varraysAPI zur Erstellung und Verwaltung von Speicherpools.

VirtuellesRechenzentrum

/object/vdcsAPI zum Hinzufügen eines VDC und seiner VDC-Zwischenendpunktesowie zur Angabe des geheimen Schlüssels für die Replikation vonDaten zwischen ECS-Standorten.

VDC Keystore /vdc/keystoreAPI zur Verwaltung von Zertifikaten für ein VDC.

Support

Call Home /vdc/callhome/API zur Verwaltung von ESRS-Konfigurationen und zum Senden vonWarnmeldungen an ConnectEMC.

CLI Package /cliAPI zum Herunterladen des ECS-CLI-Pakets.

Benutzerverwaltung

Authentifizierungsanbieter

/vdc/admin/authprovidersAPI zum Hinzufügen und Verwalten von Authentifizierungsanbietern.

Password Group(Swift)

/object/user-passwordAPI zur Erstellung eines Passworts, das mit der OpenStack Swift-Authentifizierung verwendet wird.

Geheimer Schlüssel /object/user-secret-keysAPI zur Zuweisung von geheimen Schlüsseln zu Objektbenutzern undzur Verwaltung von geheimen Schlüsseln.






Secret Key Self-Service

/object/secret-keysAPI, die es S3-Benutzern ermöglicht, einen neuen geheimen Schlüsselzu erstellen, mit dem sie auf Objekte und Buckets innerhalb ihresNamespace im Objektspeicher zugreifen können

Benutzer (Objekt) /object/usersAPI zur Erstellung und Verwaltung von Objektbenutzern.Objektbenutzer sind immer mit einem Namespace verknüpft. Die APIgibt einen geheimen Schlüssel zurück, der für den S3-Zugriffverwendet werden kann. Ein Objektbenutzer, dem ein geheimer S3-Schlüssel zugewiesen ist, kann diesen über die REST-API ändern.

/object/users/lock.

API zum Sperren des Benutzerzugriffs.

/object/users/{userName}/tags.

API, mit der Tags mit Benutzer-IDs verknüpft werden. Tags liegen inForm von Name-Wert-Paaren vor.

Benutzer(Verwaltung)

/vdc/usersAPI zur Erstellung und Verwaltung von Benutzern.Managementbenutzer können der Rolle des Systemadministratorsoder der Rolle des Namespace-Administrators zugewiesen werden.Mit dieser API können Sie das Passwort des lokalenManagementbenutzers ändern.


ECS-Management-REST-API – Zusammenfassung 127



TEIL 6

HDFS

Kapitel 6, "Einführung zu ECS-HDFS"

Kapitel 7, "Konfiguration eines einfachen Hadoop-Clusters mit ECS HDFS"

Kapitel 8, "Konfiguration eines Kerberized Hadoop-Clusters mit ECS HDFS"

Kapitel 9, "Troubleshooting"

Kapitel 10, "Anhang: Hilfe für die Kerberos-Konfiguration"

Kapitel 11, "Anhang: Hadoop-core-site.xml-Eigenschaften für ECS HDFS"

Kapitel 12, "Anhang: Beispiel für sichere Bucket-Metadaten"

HDFS 129

HDFS


KAPITEL 6

Einführung zu ECS-HDFS

l Einführung zu ECS-HDFS................................................................................. 132l Konfigurieren von Hadoop zur Verwendung von ECS HDFS ............................ 133l Hadoop-Authentifizierungsmodi....................................................................... 134l Migration von einem einfachen zu einem Kerberos-Hadoop-Cluster................. 137l Interaktion mit dem Dateisystem...................................................................... 138l Unterstützte Hadoop-Anwendungen................................................................ 139

Einführung zu ECS-HDFS 131

Einführung zu ECS-HDFSECS HDFS ist ein mit Hadoop kompatibles Dateisystem (HCFS), mit dem Sie Hadoop2.x-Anwendungen in der ECS-Speicherinfrastruktur ausführen können.

Bei Verwendung von ECS HDFS ist die Hadoop-Distribution so konfiguriert, dass sie inECS HDFS statt in dem integrierten Hadoop-Dateisystem ausgeführt wird. Diefolgende Abbildung zeigt, wie ECS HDFS in einen vorhandenen Hadoop-Clusterintegriert wird.

Abbildung 10 ECS HDFS-Integration in einen Hadoop-Cluster

Hadoop Cluster

ResourceManager

Hadoop Client

ECS Client Library

Node Manager

MapReduce Task

Appliance Software

MapReduce Request

Node Manager

MapReduce Task

Node Manager

MapReduce Task

ECS nodes

ECS nodes

ECSnodes

ECS Client Library ECS Client Library

In einer Hadoop-Umgebung, die für die Verwendung von ECS HDFS konfiguriert ist,fungieren die ECS-Nodes jeweils als herkömmliche Hadoop-NameNodes und -DataNodes. Daher können alle ECS-Nodes HDFS-Anforderungen akzeptieren undverarbeiten.

Wenn Sie den Hadoop-Client für die Verwendung von ECS HDFS anstelle desherkömmlichen HDFS konfigurieren, verweist die Konfiguration für die Ausführungaller HDFS-Aktivitäten auf ECS HDFS. Auf den einzelnen ECS HDFS-Client-Nodeswürden herkömmliche Hadoop-Komponenten die ECS Client Library (die ViPRFS JAR-Datei) zur Durchführung der HDFS-Aktivität verwenden.



Für die Integration von ECS HDFS in eine vorhandene Hadoop-Umgebung mussFolgendes vorhanden sein:

l Ein Hadoop-Cluster, der bereits installiert und konfiguriert wurde. Die folgendenDistributionen werden unterstützt:

n Hortonworks HDP 2.5

l Ein Hadoop-Cluster, der installiert und konfiguriert wurde, um ECS HDFS zuunterstützen, und der Folgendes erfordert:

n Einen für das Dateisystem aktivierten Bucket für HDFS-Zugriff.

Hinweis

Nur ein Bucket wird pro Hadoop-Cluster unterstützt, und ECS HDFS muss dasStandarddateisystem sein.

n Die auf dem Cluster bereitgestellte ECS Client Library.

l Für einen Hadoop-Cluster, das mit Kerberos oder Kerberos mit Active Directoryverwendet wird.

n Kerberos-Konfigurationsdateien und Serviceprinzipal-Keytab-Dateien, die fürden ECS-Cluster bereitgestellt werden.

n Im Bucket bereitgestellte sichere Metadaten.

Konfigurieren von Hadoop zur Verwendung von ECS HDFSHadoop speichert Systemkonfigurationsinformationen in verschiedenen Dateien,einschließlich core-site.xml, hdfs-site.xml und hive-site.xml. Die ECS-HDFS-Konfiguration erfordert die Bearbeitung von core-site.xml.

Sie müssen in der Datei core-site.xml mehrere Arten von Eigenschaftenhinzufügen oder bearbeiten, darunter:

l ECS HDFS-Java-Klassen Dieser Eigenschaftensatz definiert die ECS HDFS-Implementierungsklassen, die in der ECS HDFS-Clientbibliothek enthalten sind.

l Dateisystem-Speicherorteigenschaften: Diese Eigenschaften definieren denDateisystem-URI (Schema und Autorität) für die Ausführung von Hadoop-Jobsund die IP-Adressen oder FQDNs der ECS-Daten-Nodes für ein bestimmtes ECS-Dateisystem.

l Eigenschaften für Kerberos-Bereich und Service-Prinzipal: Diese Eigenschaftensind nur in einer Hadoop-Umgebung erforderlich, in der Kerberos vorhanden ist.Diese Eigenschaften ordnen Hadoop- und ECS HDFS-Benutzer zu.

Die Datei core-site.xml befindet sich auf jedem Node im Hadoop-Cluster. Siemüssen jeder Instanz von core-site.xml die gleichen Eigenschaften hinzufügen.

Hinweis

Beim Ändern von Konfigurationsdateien sollten Sie die Managementschnittstelle(Ambari) verwenden, anstatt die Dateien manuell zu bearbeiten. Änderungen, die Siemithilfe der Managementschnittstelle vornehmen, werden im gesamten Clusterbeibehalten.


Konfigurieren von Hadoop zur Verwendung von ECS HDFS 133

Hadoop-AuthentifizierungsmodiHadoop unterstützt zwei unterschiedliche Betriebsmodi zur Ermittlung der Identitäteines Benutzers: einfach und Kerberos.

Einfach

Im einfachen Modus wird die Identität eines Client-Prozesses durch dasHostbetriebssystem bestimmt. Auf Unix-ähnlichen Systemen lautet derBenutzername whoami.

Kerberos

In einer Hadoop-Umgebung mit Kerberos wird die Identität eines Client-Prozessesdurch seine Kerberos-Anmeldedaten bestimmt. Beispielsweise können Sie mitdem Dienstprogramm kinit ein Kerberos Ticket Granting Ticket (TGT) erhaltenund mit klist Ihren aktuellen Prinzipal ermitteln. Beim Zuordnen eines Kerberos-Prinzipals zu einen HDFS-Benutzernamen mit der Hadoop-Eigenschaftauth_to_local werden alle Komponenten bis auf die primäre Komponenteverworfen. Beispielsweise fungiert ein Prinzipal todd/[email protected] als einfacher Benutzername „todd“ in HDFS.

ECS HDFS lässt sich in Hadoop-Cluster integrieren, die einfache oder Kerberos-Authentifizierungsmodi verwenden.

Wenn der Hadoop-Cluster Kerberos verwendet, kann ECS so konfiguriert werden,dass Benutzern mit Kerberos-Prinzipalen in der Form [email protected] Zugriffgewährt wird. Wenn ECS Active Directory (AD) zur Authentifizierung von Benutzernverwendet wird, kann eine unidirektionale Vertrauensstellung zwischen der Kerberos-Umgebung und AD konfiguriert werden, so dass Benutzer sich mithilfe ihrer AD-Anmeldedaten in der Form [email protected] authentifizieren können.

Die Berechtigungen der neu erstellten Dateien und Verzeichnisse werden durch umask(fs.permissions.umask-mode) eingeschränkt. Der empfohlene umask-Wertlautet 022.

Zugriff auf den Bucket als DateisystemDer HDFS-Dateisystemspeicher wird von einem ECS-Bucket bereitgestellt. Wenn Sieeinen Bucket erstellen, müssen Sie ihn in ECS konfigurieren, damit er als Dateisystemverfügbar ist.

ECS (über die ECS-Clientbibliothek) verwendet die Berechtigungen für den Bucketund die Einstellungen innerhalb der Hadoop-Datei core-site.xml, um den Zugriffauf das Root-Dateisystem (den Bucket) zu bestimmen. Sie müssen dafür sorgen, dassSie einen ausreichenden Zugriff konfiguriert haben, damit Hadoop-Benutzer und -Services Dateien und Verzeichnisse in dem Bucket erstellen können.

Generell müssen alle Datei- und Verzeichnisvorgänge von den Bucket-ACLszugelassen werden. Zudem hat jedes einzelne Datei- und Verzeichnisobjekt innerhalbdes Buckets seine eigene Objekt-ACL, und alle Objektvorgänge müssen ebenfalls vonder Objekt-ACL zugelassen werden. Wenn der Objektvorgang nicht der Bucket-ACLentspricht, wird der Vorgang verweigert. Wenn der Objektvorgang nicht der Objekt-ACL entspricht, wird der Vorgang verweigert.

Eine Ausnahme besteht darin, dass der Bucket-Eigentümer, der Hadoop-Superuserund Mitglieder der Hadoop-Supergroup (definiert in hdfs-site.xml) jederzeit alleDateisystemvorgänge durchführen dürfen, unabhängig von den Bucket- und Objekt-ACLs.



Sie können Bucket-ACLs einrichten, indem Sie dem Bucket explizit Benutzer-ACLs fürjeden Benutzer hinzufügen oder indem Sie angepasste Gruppen-ACLs verwenden.Weitere Informationen finden Sie unter Angepasste Gruppen-ACLs undStandardgruppe für Buckets auf Seite 135. Der Bucket-Eigentümer muss ein ECS-Objektbenutzer sein. Andere Benutzer müssen keine ECS-Objektbenutzer, sondernkönnen Unix-Benutzernamen vom Hadoop-Cluster sein.

Eine weitere Ausnahme besteht darin, dass Buckets, die für das Dateisystem aktiviertsind, im Gegensatz zu normalen ECS-Buckets ein spezielles Objekt, das dasStammverzeichnis darstellt, und ein spezielles Objekt für jedes Verzeichnis haben. DasStammverzeichnisobjekt ist in einem neuen Bucket, der für das Dateisystem aktiviertist, noch nicht vorhanden, sondern wird erstellt, wenn der erste Dateisystemvorgangauf dem Bucket durchgeführt wird. Wenn ein solches Stammverzeichnisobjektvorhanden ist, führen manche ECS-HDFS-API-Aufrufe keine ACL-Prüfungen durch.

Um unabhängig von einem API-Aufruf konsistente Berechtigungen zu gewährleisten,sollten Sie sicherstellen, dass die Stammverzeichnisobjekt-ACL die Bucket-ACLdupliziert.

Sobald Benutzer Zugriff auf das Dateisystem haben, werden die Berechtigungen dervon ihnen erstellten Dateien und Verzeichnisse von der Eigenschaft umask in derDatei core-site.xml bestimmt.

Angepasste Gruppen-ACLs und Standardgruppe für BucketsSie können den Zugriff auf den Bucket basierend auf Benutzer-ACLs oder durch dieZuweisung von angepassten Gruppen-ACLs ermöglichen. Angepasste Gruppen sindNamen von Benutzergruppen, wie im Hadoop-Cluster definiert, und ermöglichenHadoop-Benutzern den Zugriff auf den Bucket mit HDFS.

Typische, auf dem Hadoop-Cluster definierte Gruppen sind hdfs (mit Benutzerhdfs), hadoop (umfasst in der Regel alle Servicebenutzer) und users (umfasstandere Nicht-Servicebenutzer, die auf Anwendungen auf dem Hadoop-Clusterzugreifen). Sie können entsprechende Gruppen im ECS-Portal erstellen und ihnenBerechtigungen zuweisen.

Sie können auch eine Standardgruppe für den Bucket zuweisen. Die Standardgruppe istdie Gruppe, die dem Root-Dateisystem (/) zugewiesen wird. Wenn Ihr Bucket-Eigentümer beispielsweise hdfs ist und die Standardgruppe auf hadoop festgelegtist, wird „/“ auf hdfs:hadoop als Benutzer und Gruppe festgelegt. EineStandardgruppe ist auch eine angepasste Gruppe und wird daher in der Liste derangepassten Gruppen-ACLs angezeigt.

Wenn keine Standardgruppe eingerichtet ist, verfügt das Root-Verzeichnis desDateisystems über keine Gruppe, wie im folgenden Beispiel dargestellt.

drwx---rwx+ - hdfs 0 2015-12-09 12:30 /

Bei Einrichtung einer Standardgruppe von hadoop werden Eigentumsrechte undBerechtigungen wie im folgenden Beispiel angezeigt.

drwxrwxrwx+ - hdfs hadoop 0 2015-12-09 12:28 /

Diese Berechtigungen werden nicht für Verzeichnisse übernommen, die im Root-Verzeichnis erstellt werden.


Angepasste Gruppen-ACLs und Standardgruppe für Buckets 135

Wenn keine Standardgruppe zugewiesen ist, kann der Bucket-Eigentümer (derEigentümer des Root-Dateisystems) eine Gruppe zuweisen, indem er das HDFS mitden Befehlen hdfs dfs -chgrp und hdfs dfs -chmod über Hadoop aufruft.

Hadoop-Superuser und -Supergroup

Der Superuser in einer Hadoop-Umgebung ist der Benutzer, der den NameNodestartet, in der Regel hdfs oder [email protected]. Bei einer ECS-HDFS-Konfiguration ist der Superuser der Bucket-Eigentümer. Wenn Sie daher dem Hadoop-Superuser Superuser-Zugriff auf den ECS-Bucket bereitstellen möchten, sollten Siesicherstellen, dass der Bucket sich im Besitz von hdfs, [email protected] [email protected] befindet, sofern Sie Active Directory zur Authentifizierung vonBenutzern in der Hadoop-Umgebung verwenden.

Um sicherzustellen, dass der Hadoop-Client über Superuser-Zugriff verfügt, könnenSie auch mit der Eigenschaft dfs.permissions.superusergroup in der Dateicore-site.xml eine Superuser-Gruppe konfigurieren. Im einfachen Modus erfolgtdie Prüfung, ob ein Benutzer Mitglied der Supergroup ist, auf dem Client, indem derWert der Hadoop-Eigenschaft dfs.permissions.supergroup überprüft wird. InKerberos-Modus erfolgt die Prüfung, ob ein Benutzer Mitglied der Supergroup ist, aufdem ECS-Server.

Im Allgemeinen gilt: Wenn der Bucket-Zugriff über den Hadoop-Superuser oder eineHadoop-Superuser-Gruppe konfiguriert ist, verfügt der Superuser über Vollzugriff(Lesen und Schreiben) auf den Bucket. Benutzer ohne Superuser-Berechtigungenverfügen normalerweise über Lesezugriff. Dies hängt jedoch davon ab, wie der Bucketerstellt wurde. Ein Benutzer muss kein ECS-Objektbenutzer sein, um Zugriff auf denBucket zu erhalten. Der Name muss einem lokalen Unix-, Kerberos- oder AD-Benutzerentsprechen (je nach verwendetem Authentifizierungsmodus).

Eine bewährte Vorgehensweise besteht darin, sicherzustellen, dass der hdfs-Benutzer oder hdfs-Prinzipal entweder der Bucket-Eigentümer (Superuser) oderMitglied einer Superuser-Gruppe ist.

Multiprotokollzugriff (Crosshead)ECS unterstützt die Fähigkeit, Daten mithilfe der S3-Protokolls in einen Bucket zuschreiben und diese Daten als Dateien über HDFS zur Verfügung zu stellen.

Multiprotokollzugriff (auch als Crosshead-Zugriff bezeichnet) bedeutet, dass mit demS3-Protokoll in den Bucket geschriebene Objekte in Hadoop-Jobs verwendet werdenkönnen, beispielsweise in MapReduce. Auf ähnliche Weise können von HDFSgeschriebene Verzeichnisse und Dateien über S3-Clients gelesen und geändertwerden.

Um mithilfe von S3 geschriebene Daten als Dateien aufzurufen, kann der Bucket-Administrator eine Standardgruppe auf dem Bucket festlegen und dieStandardberechtigungen für Dateien und Verzeichnisse für diese Gruppe bestimmen.Diese Standard-Unix-Gruppe wird Objekten zugewiesen, wenn sie über S3 erstelltwerden, sodass sie einen Eigentümer haben sowie über Gruppenzugehörigkeiten und -berechtigungen verfügen, die HDFS-Zugriff über das Hadoop-Cluster ermöglichen.

Mit HDFS erstellte und mithilfe des S3-Protokolls aufgerufene Dateien sind von denStandardberechtigungen nicht betroffen. Diese werden nur auf Objekte angewendet,die mit dem S3-Protokoll erstellt werden.



ProxybenutzerECS HDFS unterstützt die Verwendung des Hadoop-Proxybenutzers.

Ein Proxybenutzer gestattet es einem Hadoop-Benutzer, im Auftrag eines anderenBenutzers Jobs zu senden oder auf HDFS zuzugreifen. Die Proxybenutzer-Funktionlässt sich mit der Funktion effective user in UNIX/Linux vergleichen, bei der einBenutzer bei der Ausführung eines Befehls die Identität eines anderen Benutzersannimmt, wie in den Berechtigungseinstellungen der ausführbaren Datei angegeben.

Konfigurieren Sie Proxybenutzer für einen sicheren Identitätswechsel pro Namespace(oder pro Bucket). Proxybenutzer werden im einfachen und Kerberos-Modusunterstützt. In beiden Modi kann der Administrator Proxy-Identitätswechsel mithilfeder Eigenschaften hadoop.proxyuser.*.* einschränken.

Benutzer mit derselben ÄquivalenzklasseECS konvertiert dreiteilige Prinzipale in zweiteilige Prinzipale.

Ein Kerberos-Prinzipal hat in der Regel die Form primary/instance@realm,obwohl die Instanz nicht erforderlich ist, da der primary@realm-Prinzipal für alleHosts im Bereich gilt. Wenn die Instanz angegeben ist, kann sie verwendet werden, umeinen bestimmten Host zu bezeichnen, wie joe/[email protected] oder joe/[email protected]. Diese beiden Prinzipale gelten für dengleichen primären Benutzer (joe), sind aber nur zur Authentifizierung auf demjeweiligen Host (host1 oder host2) berechtigt.

Diese Art von Benutzerprinzipal wird empfohlen, um eine höhere Sicherheit zuerreichen. Aus der Perspektive von ECS müsste jedes Prinzipal zu ECS hinzugefügtwerden. Dies ist sehr aufwendig. Daher ermöglicht die Äquivalenzbenutzerfunktion dieECS-Autorisierung über einen zweiteiligen Prinzipal (primary@realm), selbst wenndreiteilige Prinzipale genutzt werden.

Migration von einem einfachen zu einem Kerberos-Hadoop-Cluster

ECS bietet Unterstützung für die Migration von einer einfachen Hadoop-Umgebung zueiner Hadoop-Umgebung, die durch Kerberos gesichert ist.

Wenn ECS HDFS in eine Hadoop-Umgebung mit einfacher Sicherheit integriert ist,sind von Hadoop-Benutzern und -Prozessen erstellte Dateien und VerzeichnisseEigentum von nicht sicheren Benutzern. Wenn Sie anschließend das Hadoop-Clusterzur Verwendung von Kerberos-Sicherheit migrieren, sind die in ECS HDFSgeschriebenen Dateien und Verzeichnisse für diese Benutzer nicht mehr zugänglich.

ECS bietet eine integrierte Migrationsfunktion, über die Sie eine Zuordnung zwischenKurznamen und Kerberos-Prinzipalen für ECS bereitstellen können, damit im Besitzvon nicht sicheren Kurznamen befindliche Dateien für den zugeordneten Kerberos-Prinzipal zugänglich sind.

Wenn Sie nur über eine kleine Anzahl von Dateien verfügen, die vonKurznamenbenutzern geschrieben wurden, empfiehlt es sich, diese so zu ändern(mithilfe von chown), dass sie in die Eigentümerschaft des Kerberos-Prinzipalsübergehen. Wenn Sie jedoch über eine große Anzahl von Dateien verfügen, können Siedie Migrationsfunktion verwenden, damit Sie den Eigentümer nicht ändern müssen.


Proxybenutzer 137

Diese Funktion ist für Buckets nicht implementiert. Sie müssen daher die Bucket-ACLsändern, um den Zugriff durch die Kerberos-Prinzipale zu gestatten, wenn Sie auf denZugriff durch Benutzer angewiesen sind. Wenn Sie allerdings dieGruppenmitgliedschaft als primäres Mittel zum Aktivieren des Zugriffs verwenden,müssen Sie die Bucket-ACLs nicht ändern.

ECS ermöglicht die Verwendung der Gruppen, um den Zugriff auf Buckets, Dateienund Verzeichnisse zu vereinfachen. Gruppen verwenden immer einfache UNIX-Namen,sodass der mit einem Bucket, einer Datei oder einem Verzeichnis verknüpfteGruppenname beim Zugriff von einem einfachen oder Kerberized-Cluster identisch ist.Beim Zugriff von einer einfachen Umgebung wird die Gruppenmitgliedschaft über denUNIX-Rechner bestimmt. Beim Zugriff von einem Kerberized-Cluster können Sie dieGruppenmitgliedschaft konfigurieren, indem Sie die Zuordnung zuweisen. Unter Zuordnen von Gruppennamen auf Seite 163 finden Sie Informationen über dieZuordnung von Gruppennamen.

Bei Verwendung von AD-Anmeldedaten wird die Zuordnung zwischen AD-Prinzipalenund UNIX-Prinzipalen durch Entfernen des Domain-Suffix erreicht, d. h. aus demBenutzer [email protected] wird hdfs. Dies ist nicht ganz so flexibel wie dieVerwendung der Kerberos-Prinzipalzuordnung, die auch Zuordnungen etwa [email protected] zu hdfs zulässt.

Bei Verwendung von Gruppen mit AD muss ein Authentifizierungsanbieter in ECSkonfiguriert sein, um die Zugehörigkeit der Gruppe prüfen zu können.

Hadoop-Kerberos-AuthentifizierungsmodusWenn Kerberos und der ECS-AD-Server integriert werden, stellt der Kerberos-Bereicheinen einzigen Benutzer-Namespace bereit, sodass mit kinit authentifizierteHadoop-Benutzer als vertrauenswürdige ECS-Benutzer erkannt werden.

In einem Hadoop-Cluster, der im Kerberos-Modus ausgeführt wird, muss eineunidirektionale bereichsübergreifende Vertrauensstellung vom Kerberos-Bereich zumAD-Bereich für die Authentifizierung Ihrer ECS-Benutzer vorhanden sein.

Mithilfe der folgenden Identitätsübersetzungseigenschaften in der Datei core-site.xml wird für die ordnungsgemäße Benutzerübersetzung (Hadoop zu ECS)gesorgt:

l fs.permissions.umask-mode: Legen Sie als Wert 022 fest.

l fs.viprfs.auth.anonymous_translation: Legen Sie als WertCURRENT_USER fest.

l fs.viprfs.auth.identity_translation: Legen Sie als WertCURRENT_USER_REALM fest, damit der Bereich der Benutzer automatischerkannt wird.

Darüber hinaus müssen Sie folgende Eigenschaften in der Datei core-site.xmlfestlegen, um einen Serviceprinzipal zu definieren:

l viprfs.security.principal: vipr/[email protected], wobeiREALM.COM durch Ihren Kerberos-Bereichsnamen ersetzt wird.

Interaktion mit dem DateisystemWenn Sie direkt mit ECS HDFS interagieren, bemerken Sie möglicherweise diefolgenden Unterschiede zur Interaktion mit dem Standard-HDFS-Dateisystem:



l Anwendungen, die erwarten, dass das Dateisystem eine Instanz vonDistributedFileSystem ist, können nicht ausgeführt werden. Für Anwendungen,deren Hartcodierung die Ausführung mit der integrierten HDFS-Implementierungvorsieht, sind Änderungen erforderlich, um ECS HDFS verwenden zu können.

l ECS HDFS unterstützt keine Prüfsummen der Daten.

l Wenn Sie die Funktion „listCorruptFileBlocks“ verwenden, werden alle Blöcke alsOK gemeldet, da ECS HDFS beschädigte Blöcke nicht kennt.

l Der Replikationsfaktor wird immer als Konstante N gemeldet, wobei N = 1. DieDaten werden durch das ECS-SLA geschützt, nicht durch die Hadoop-Replikation.

Unterstützte Hadoop-AnwendungenECS HDFS unterstützt die meisten Anwendungen in der Hadoop-Umgebung.

Die folgenden Anwendungen in der Hadoop-Umgebung werden unterstützt:

l YARN

l MapRedeuce

l Pig

l Hive

l Spark

l Zookeeper

l Ambari

l Sqoop

l Flume


Unterstützte Hadoop-Anwendungen 139



KAPITEL 7

Konfiguration eines einfachen Hadoop-Clustersmit ECS HDFS

l Integrieren eines einfachen Hadoop-Clusters mit ECS HDFS........................... 142l Installation von Hortonworks HDP mithilfe von Ambari..................................... 142l Erstellen eines Buckets für HDFS über das ECS-Portal.................................... 144l Planen der Integration von ECS HDFS und Hadoop.......................................... 152l Abrufen des ECS HDFS-Installations- und Supportpakets................................ 152l Bereitstellen der ECS HDFS-Clientbibliothek....................................................153l Konfigurieren von ECS-Client-Eigenschaften................................................... 154l Einrichten von Hive.......................................................................................... 155l Überprüfen des Hadoop-Zugriffs auf ECS........................................................ 156l Sichern des Buckets......................................................................................... 157l Verlagern des Standard-Dateisystems vom HDFS zu einem ECS-Bucket......... 158

Konfiguration eines einfachen Hadoop-Clusters mit ECS HDFS 141

Integrieren eines einfachen Hadoop-Clusters mit ECS HDFSSie können eine Hadoop-Distribution konfigurieren, um die ECS-Speicherinfrastrukturmit ECS HDFS zu verwenden.

Um dieses Integrationsverfahren durchzuführen, benötigen Sie folgendeVoraussetzungen:

l Praktische Erfahrungen mit der Hadoop-Distribution und den damit verbundenenTools

l Die Hadoop-Anmeldedaten zum Anmelden bei Hadoop-Nodes, zum Bearbeiten vonHadoop-Systemdateien und zum Starten und Beenden von Hadoop-Services.

Es müssen die folgenden Schritte durchgeführt werden:

1. Installation von Hortonworks HDP mithilfe von Ambari auf Seite 142

2. Erstellen eines Buckets für HDFS über das ECS-Portal auf Seite 144

3. Planen der Integration von ECS HDFS und Hadoop auf Seite 152

4. Abrufen des ECS HDFS-Installations- und Supportpakets auf Seite 152

5. Bereitstellen der ECS HDFS-Clientbibliothek auf Seite 153 (Nicht erforderlich,wenn Sie Ambari Hortonworks für ECS verwendet haben)

6. Konfigurieren von ECS-Client-Eigenschaften auf Seite 154

7. Überprüfen des Hadoop-Zugriffs auf ECS auf Seite 156

8. Verlagern des Standard-Dateisystems vom HDFS zu einem ECS-Bucket auf Seite158

Sobald die Konfiguration abgeschlossen ist, werden Dateien im Standarddateisystemdes Hadoop-Clusters Dateien in ECS-Buckets zugeordnet. So wirdbeispielsweise /foo/bar im Standarddateisystem viprfs://<bucket_name>.<namespace>.<federation_name>/foo/bar zugeordnet.

Installation von Hortonworks HDP mithilfe von AmbariInstallieren Sie den Ambari-Server und nutzen Sie ihn zur Installation von HortonworksHDP.

Dieses Verfahren enthält die grundlegenden Befehle zur Installation und Einrichtungdes Ambari-Servers. Weitere Informationen zur Installation des Ambari-Servers findenSie in der Hortonworks-Dokumentation.

Vorgehensweise

1. Laden Sie das Ambari-Repository herunter.

wget -nv http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.4.2.0/ambari.repo -O /etc/yum.repos.d/ambari.repo

2. Installieren Sie den Ambari-Server.

yum install -y ambari-server

Konfiguration eines einfachen Hadoop-Clusters mit ECS HDFS


https://docs.hortonworks.com/HDPDocuments/Ambari-2.4.2.0/bk_ambari-installation/content/ch_Getting_Ready.html

3. Richten Sie den Ambari-Server ein.

ambari-server setup -s

4. Starten Sie den Ambari-Server.

ambari-server start

5. Navigieren Sie zu http://ambari.example.com:8080/.

6. Wählen Sie auf der Seite Stapel wählen die Hadoop-Version HDP 2.5 undwählen Sie die Version des Betriebssystems aus.

7. Wählen Sie die Hadoop-Services aus, die Sie aktivieren möchten, wie imfolgenden Beispiel gezeigt:


Installation von Hortonworks HDP mithilfe von Ambari 143

8. Schließen Sie den Installationsassistenten ab.

Erstellen eines Buckets für HDFS über das ECS-PortalVerwenden Sie das ECS-Portal, um einen für die Verwendung mit HDFS konfiguriertenBucket zu erstellen.



Bevor Sie beginnen

Stellen sie sicher, dass Ihnen die Rolle eines Namespace- oder Systemadministratorszugewiesen ist. Wenn Sie ein Namespace-Administrator sind, können Sie Buckets inIhrem Namespace erstellen. Wenn Sie Systemadministrator sind, können Sie einenBucket erstellen, der zu einem beliebigen Namespace gehört.

Sie müssen sicherstellen, dass Hadoop-Benutzer und -Services Zugriff auf das HDFS-Dateisystem (den Bucket) haben und Dateien und Verzeichnisse von denentsprechenden Benutzern und Gruppen abgerufen werden können. Dafür gibt esmehrere Vorgehensweisen:

l Setzen Sie als Eigentümer des Buckets den Hadoop-Superuser ein, in der Regelhdfs oder [email protected].

l Aktivieren Sie den Zugriff auf den Bucket über die Gruppenmitgliedschaft:

n Weisen Sie dem Bucket eine Standardgruppe zu. Diese wird automatisch denangepassten Gruppen-ACLs zugewiesen.

n Fügen Sie nach der Erstellung des Buckets angepasste Gruppen-ACLs für alleanderen Gruppen hinzu, die Zugriff benötigen.

l Aktivieren Sie den Zugriff für einzelne Personen, indem Sie dem Bucket Benutzer-ACLs hinzufügen.

l Stellen Sie sicher, dass die Hadoop-Benutzer, die Superuser-Zugriff auf das HDFSbenötigen, Teil der Hadoop-Supergroup sind.

Wenn Objektdaten, die mithilfe von Objektprotokollen in den Bucket geschriebenwurden, über das HDFS zugänglich sein sollen, sollten Sie sicherstellen, dass demBucket eine Standardgruppe zugewiesen zugewiesen wird und die standardmäßigenDatei- und Verzeichnisberechtigungen für die Gruppe festgelegt werden.

Weitere Informationen über Benutzer und Berechtigungen finden Sie unter Zugriff aufden Bucket als Dateisystem auf Seite 134 und Beispiel für Hadoop und ECS-Bucket-Berechtigungen auf Seite 150.

Vorgehensweise

1. Wählen Sie im ECS-Portal Manage > Buckets > New Bucket aus.

2. Geben Sie auf der Seite New Bucket in das Feld Name einen Namen für denBucket ein.

Hinweis

Verwenden Sie keine Unterstriche in Bucket-Namen, da diese nicht von derURI-Java-Klasse unterstützt werden. Beispielsweise funktioniert viprfs://my_bucket.ns.site/ nicht, da es ein ungültiger URI ist und daher vonHadoop nicht verstanden wird.

3. Wählen Sie im Feld Namespace den Namespace aus, dem der Bucketangehören soll.

4. Wählen Sie im Feld Replication Group eine Replikationsgruppe aus oder lassenSie dieses Feld leer, um die Standard-Replikationsgruppe für den Namespace zuverwenden.

5. Geben Sie im Feld Bucket Owner den Benutzernamen des Bucket-Eigentümersein.

Bei einem HDFS-Bucket ist der Eigentümer des Buckets in der Regel hdfs [email protected] für Kerberos-Buckets. Der Hadoop-Benutzer hdfs benötigtSuperuser-Berechtigungen für HDFS. Um dies zu erreichen, machen Sie hdfs


Erstellen eines Buckets für HDFS über das ECS-Portal 145

zum Eigentümer des Buckets. Andere Hadoop-Benutzer benötigenmöglicherweise ebenfalls Superuser-Berechtigungen. Diese werden gewährt,indem Sie Benutzer einer Gruppe zuweisen und diese als Superuser-Gruppefestlegen.

6. CAS sollte nicht aktiviert werden.

Hinweis

Ein Bucket, der für die Verwendung mit dem HDFS vorgesehen ist, kann nichtfür CAS verwendet werden. Das CAS-Steuerelement ist deaktiviert, wenn dasDateisystem aktiviert ist.

7. Aktivieren Sie alle anderen Bucket-Funktionen, die Sie benötigen.

Sie können die folgenden Funktionen für einen HDFS-Bucket aktivieren:

l Quota

l Server-side Encryption

l Metadata Search

l Access During Outage

l Compliance (siehe Hinweis)

l Bucket Retention

Im ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“finden Sie Informationen zu diesen Einstellungen und deren Konfiguration.

Hinweis

Es kann nicht über das HDFS-Protokoll in einen Compliance-fähigen Bucketgeschrieben werden. Mithilfe von Objektprotokollen geschriebene Daten könnenjedoch vom HDFS gelesen werden.

8. Wählen Sie für das Dateisystem die Funktion Enabled aus.

Nach der Aktivierung stehen Felder zum Festlegen einer Standardgruppe fürdas Dateisystem/den Bucket sowie zur Zuweisung von Gruppenberechtigungenfür im Bucket erstellte Dateien und Verzeichnisse zur Verfügung. Diese Felderwerden im folgenden Beispiel gezeigt.




9. Geben Sie im Feld Default Bucket Group einen Namen für die Standard-Bucket-Gruppe ein.

Diese Gruppe entspricht der Gruppe, die mit dem HDFS-Root-Dateisystemverknüpft ist, und gewährt Hadoop-Benutzern, die Mitglieder der Gruppe sind,Zugriff auf das HDFS.

Bei der Standardgruppe könnte es sich um eine Gruppe wie hdfs oder hadoophandeln, der die Services angehören, auf deren Daten Sie auf dem HDFSzugreifen müssen. Sie können aber jede beliebige Gruppe wählen, die für IhreHadoop-Konfiguration sinnvoll ist. Beispielsweise möchte der Administrator,dass alle S3-Dateien in den Bucket hochgeladen werden, der der GruppeS3DataUsers zugewiesen werden soll. Allen S3-Dateien wird dann dieseGruppe zugewiesen. Auf dem Hadoop-Node verfügt der Hadoop-Administratorüber Benutzer, die Mitglieder der Gruppe S3DataUsers sind. S3DataUserskann eine Linux-Gruppe oder eine AD-Gruppe sein. Wenn die Hadoop-Benutzerauf die S3-Daten zugreifen möchten, ist das möglich, da die Dateienhochgeladen und dieser Gruppe zugewiesen wurden.

Sie müssen die Standardgruppe bei der Erstellung des Buckets angeben.Geschieht das nicht, muss die Gruppe später vom Eigentümer des Dateisystemsüber Hadoop zugewiesen werden.

10. Legen Sie in den Feldern Dateizugriffsrechte einer Gruppe undVerzeichniszugriffsrechte einer Gruppe die Standardberechtigungen fürDateien und Verzeichnisse fest, die mit den Objektprotokollen in dem Bucketerstellt wurden.

Mit dieser Einstellung wenden Sie UNIX-Gruppenberechtigungen auf Objektean, die mit Objektprotokollen erstellt wurden. Diese Berechtigungen gelten fürdie HDFS-Gruppe (die Standard-Bucket-Gruppe), wenn das Objekt oder einVerzeichnis über Hadoop aufgelistet wird. Weitere Informationen zum Festlegender Standardgruppe und Berechtigungen für das Dateisystem finden Sie unter Multiprotokollzugriff (Crosshead) auf Seite 136.

a. Wählen Sie im Feld Dateizugriffsrechte einer Gruppe die entsprechendenBerechtigungsschaltflächen aus. Sie legen in der Regel Leseberechtigungen(Read) und Ausführungsberechtigungen (Execute) fest.

b. Wählen Sie im Feld Verzeichniszugriffsrechte einer Gruppe dieentsprechenden Berechtigungsschaltflächen aus. Sie legen in der RegelLeseberechtigungen (Read) und Ausführungsberechtigungen (Execute)fest.

11. Klicken Sie auf Save, um den Bucket zu erstellen.

Festlegen von angepassten Gruppen-ACLs für BucketsSie können eine Gruppen-ACL für einen Bucket im ECS-Portal festlegen, und Siekönnen Bucket-ACLs für eine Gruppe von Benutzern (angepasste Gruppen-ACL) füreinzelne Benutzer oder eine Kombination aus beiden festlegen. Beispielsweise könnenSie einer Gruppe von Benutzern vollständige Bucket-Zugriffsrechte gewähren, aberSie können auch den Bucket-Zugriff für einzelne Benutzer in dieser Gruppebeschränken (oder sogar verweigern).

Bevor Sie beginnen

l Dieser Vorgang erfordert die Systemadministrator- oder Namespace-Administratorrolle in ECS.

l Wenn Sie Systemadministrator sind, können Sie die Gruppen-ACL-Einstellungenfür einen Bucket in einem Namespace bearbeiten.


Festlegen von angepassten Gruppen-ACLs für Buckets 147

l Ein Namespace-Administrator kann die Gruppen-ACL-Einstellungen für einenBucket im Namespace bearbeiten, in dem er der Administrator ist.

Im Bereich „Custom Group ACLs“ können Gruppen definiert und diesenBerechtigungen zugewiesen werden. Das wichtigste Anwendungsbeispiel für dieZuweisung von Gruppen zu einem Bucket ist die Unterstützung des Zugriffs auf denBucket als Dateisystem, z. B. um den Bucket für NFS oder HDFS bereitzustellen.

Mitglieder der UNIX-Gruppe können den Bucket zugreifen, wenn als Dateisystem (mitNFS oder HDFS) darauf zugegriffen wird.

Vorgehensweise

1. Wählen Sie im ECS-Portal Manage > Buckets aus.

2. Suchen Sie auf der Seite Bucket Management den Bucket, den Sie in derTabelle bearbeiten möchten, und wählen Sie dann die Aktion Edit ACL.

3. Um die ACL für eine angepasste Gruppe auszuwählen, klicken Sie auf CustomGroup User ACLs.

4. Klicken Sie auf Add.

Die Seite Edit Custom Group wird wie im folgenden Screenshot dargestelltangezeigt.

5. Geben Sie auf der Seite Edit Custom Group in das Feld Custom Group Nameden Namen für die Gruppe ein.

Bei diesem Namen kann es sich um eine Unix-/Linux-Gruppe oder eine ActiveDirectory-Gruppe handeln.

6. Legen Sie die Berechtigungen für die Gruppe fest.



Sie sollten mindestens Read-, Write-, Execute- und Read ACL-Berechtigungenzuweisen.


Einrichten von Benutzer ACLs für BucketsSie können im ECS-Portal eine Benutzer-ACL für einen Bucket einrichten. ECS weistdem Bucket-Eigentümer automatisch Berechtigungen zu. Sie können anderenHadoop-Benutzern Benutzer-ACLs zuweisen, um den Zugriff auf den Bucket/dasDateisystem zu ermöglichen. Alternativ können die Benutzer Zugriff auf den Bucketerhalten, indem sie einer Gruppe angehören, der angepasste Gruppen-ACLszugewiesen wurden.

Bevor Sie beginnen

l Sie müssen ECS-Namespace-Administrator oder Systemadministrator sein, um dieACL für einen Bucket bearbeiten zu können.

l Wenn Sie Namespace-Administrator sind, können Sie die ACL-Einstellungen fürBuckets bearbeiten, die zu Ihrem Namespace gehören.

l Wenn Sie Systemadministrator sind, können Sie die ACL-Einstellungen für Bucketsbearbeiten, die zu einem beliebigen Namespace gehören.

Vorgehensweise

1. Wählen Sie im ECS-Portal Manage > Buckets aus.

2. Suchen Sie auf der Seite Bucket Management den Bucket, den Sie in derTabelle bearbeiten möchten, und wählen Sie dann die Aktion Edit ACL aus.

3. Achten Sie darauf, dass auf der Seite Bucket ACLs Management dieRegisterkarte User ACLs ausgewählt ist. Das ist die Standardeinstellung.

4. Auf der Registerkarte User ACLs können Sie die Berechtigungen für einenBenutzer bearbeiten, dem bereits Berechtigungen zugewiesen wurden, odereinen Benutzer hinzufügen, dem Sie Berechtigungen zuweisen möchten.

l Um die ACL-Berechtigungen für einen Benutzer festzulegen (oder zuentfernen), der bereits Berechtigungen hat, wählen Sie in der Tabelle ACL inder Spalte „Action“ die Option Edit (oder „Remove“).

l Um einen Benutzer hinzuzufügen, dem Sie Berechtigungen zuweisenmöchten, klicken Sie auf Add und geben Sie den Benutzernamen desBenutzers ein, für den die Berechtigungen gelten sollen. Geben Sie dieBerechtigungen an, die Sie auf den Benutzer anwenden möchten.

Dem Benutzer, den Sie als Bucket-Eigentümer festgelegt haben, sind bereits dieStandardberechtigungen zugewiesen worden.

Im folgenden Beispiel ist der Benutzer hdfs Bucket-Eigentümer und alssolchem ist hdfs die vollständige Kontrolle eingeräumt worden. VollständigeKontrolle bedeutet Lese-, Schreib- und Ausführungsberechtigungen in einerHadoop-/UNIX-Umgebung. Benutzer sally wurden Lese- undAusführungsberechtigungen gewährt, damit der Zugriff auf den Bucket möglichist.


Einrichten von Benutzer ACLs für Buckets 149

Weitere Informationen zu ACL-Berechtigungen finden Sie im ECS-Administrationshandbuch auf der Seite „ECS-Produktdokumentation“.

5. Klicken Sie auf Speichern.

Beispiel für Hadoop und ECS-Bucket-BerechtigungenIn diesem Abschnitt finden Sie Beispiele für die Beziehung zwischen Hadoop-Benutzern und -Gruppen und den Benutzern und Gruppen, denenZugriffsberechtigungen für den Bucket über ECS-Benutzer-ACLs und angepasstenGruppen-ACLs zugewiesen wurden.

Bei der Erstellung eines Buckets weist ECS dem Bucket-Eigentümer und derStandardgruppe automatisch ACLs zu; dabei handelt es sich um dieGruppenzuweisung für den Bucket beim Zugriff über HDFS. Ein Bucket muss immereinen Eigentümer haben, es muss jedoch keine Standardgruppe zugewiesen werden.Anderen Benutzern und Gruppen als dem Bucket-Eigentümer, d. h.benutzerdefinierten Gruppen, können ACLs für den Bucket zugewiesen werden. Aufdiese Weise zugewiesenen ACLs entsprechen den Berechtigungen für Hadoop-Benutzer.

Tabelle 24 Beispiele für Bucket-Berechtigungen für den Dateisystemzugriff in einem einfachenHadoop-Cluster

Hadoop-Benutzer und -Gruppen Bucket-Berechtigungen Bucket-/Dateisystemzugriff

Bucket-Zugriff mithilfe der Gruppen-ACL

Benutzer (Service)

hdfs. mapred, yarn, hive, pig

Benutzer (Anwendungen)

sally, fred

Gruppen

hdfs (hdfs)

hadoop (hdfs, mapred, yarn, hive,pig)

Benutzer (sally, fred)

Eigentümer des Buckets

hdfs

Standardgruppe

BenutzerdefinierteGruppen-ACL

hadoop, users, hive,spark (vollständigeKontrolle)

Benutzer-ACL

hdfs (Eigentümer)

Angepasste Gruppen-ACLs müssen im ECS-Portal für den Bucket festgelegt werden.Weisen Sie den Gruppen hadoop,users,

hive und spark vollständige Kontrolle für

den Bucket/das Root-Dateisystem zu.

In diesem Beispiel wird davon ausgegangen,dass hdfs der Superuser ist, also der

Benutzer, der den NameNode gestartet hat.




Tabelle 24 Beispiele für Bucket-Berechtigungen für den Dateisystemzugriff in einem einfachenHadoop-Cluster (Fortsetzung)

Hadoop-Benutzer und -Gruppen Bucket-Berechtigungen Bucket-/Dateisystemzugriff

Supergroup

hdfs

Bucket erstellt von s3-Benutzer, Crosshead-Zugriff

Benutzer (Service)

hdfs. mapred, yarn, hive, pig


sally, fred

Gruppen

hdfs (hdfs)

hadoop (hdfs, mapred, yarn, hive,pig)

Benutzer (sally, fred)

Supergroup

hdfs


s3user

Standardgruppe

hadoop(Dateiberechtigungeneiner Gruppe: Lesen,Schreiben

(Verzeichnisberechtigungen einer Gruppe: Lesen,Schreiben, Ausführen)


hadoop (Standard)

Benutzer-ACL

s3user (Eigentümer),sally, fred

Wenn Objekte, die von einem S3-Benutzergeschrieben wurden, vom HDFS aus alsDateien zugänglich sein sollen, muss eineStandardgruppe definiert werden (hadoop)

werden, damit Hadoop-Benutzer und -Services aufgrund ihrer GruppenzugehörigkeitBerechtigungen für die Dateien erhalten.

Die Standardgruppe verfügt automatisch überangepasste Gruppen-ACLs für denBucket/das Dateisystem. Das folgendeBeispiel zeigt, dass hadoop als

Standardgruppe festgelegt wurde und dassdie Berechtigungen des Root-Dateisystems777 sind:

drwxrwxrwx+ - s3user hadoop 0 2015-12-09 12:28 /

Benutzern kann der Zugriff entweder durchHinzufügen von Benutzer-ACLs oder durchHinzufügen von angepassten Gruppen-ACLsfür die Gruppe, zu der die Benutzer gehören,gewährt werden.

Tabelle 25 Beispiele für Bucket-Berechtigungen für den Dateisystemzugriff in einem KerberizedHadoop-Cluster

Hadoop-Benutzer Bucket-Berechtigungen Bucket-/Dateisystemzugriff

Benutzer (Service)

[email protected]@REALM.COM,[email protected],[email protected], [email protected]


[email protected],[email protected], [email protected]

Gruppen

hdfs ([email protected])


[email protected]

Standardgruppe

hadoop


hadoop (Standard),users

Benutzer-ACL

[email protected](Eigentümer)

Gruppen-ACLs, die im Portal für den Bucketfestgelegt wurden, bieten die Möglichkeit,den Gruppen hadoop und usersBerechtigungen für den Bucket/das Root-Dateisystem gewähren.

Benutzerinformationen vom Hadoop-Clustermüssen für ECS verfügbar sein, um einensicheren Zugriff auf den Bucketbereitzustellen. Diese Informationen werdenmithilfe von Bucket-Metadaten bereitgestellt.Eine Beispiel-Metadatendatei finden Sie unter Sichere Bucket-Metadaten auf Seite 200.


Beispiel für Hadoop und ECS-Bucket-Berechtigungen 151

Tabelle 25 Beispiele für Bucket-Berechtigungen für den Dateisystemzugriff in einem KerberizedHadoop-Cluster

Hadoop-Benutzer Bucket-Berechtigungen Bucket-/Dateisystemzugriff

hadoop ([email protected],[email protected],[email protected],[email protected],[email protected])

users ([email protected],[email protected])

Supergroup

hdfs

Planen der Integration von ECS HDFS und HadoopAnhand der folgenden Tabelle können Sie prüfen, ob Sie über die nötigenInformationen verfügen, um eine erfolgreiche Integration durchzuführen.

Tabelle 26 ECS HDFS-Konfigurationsvoraussetzungen

Element Aktion

Hadoop-Cluster Prüfen Sie, ob das Cluster installiert und betriebsbereit ist.

Speichern Sie die Admin-Anmeldedaten zur Verwendung im weiterenVerlauf des Verfahrens.

ECS-Cluster:ECS-Nodes

Speichern Sie die IP-Adressen der ECS-Nodes zur Verwendung imweiteren Verlauf des Verfahrens.

ECS-Cluster: Bucket HDFS erfordert, dass ein für HDFS aktivierter Bucket in derReplication Group ECS erstellt wird. Auf den Bucket wird wie auf einDateisystem mit dem Namespace und dem Bucket-Namenzugegriffen.

Notieren Sie den Namen des Buckets.

ECS-Cluster: Tenant-Namespace

Prüfen Sie, ob ein Tenant Namespace konfiguriert ist. Notieren Sieden Namen.

Abrufen des ECS HDFS-Installations- und SupportpaketsDie ECS-HDFS-Clientbibliothek und HDFS-Supporttools werden in der HDFS-Client-ZIP-Datei hdfsclient-<ECS version>-<version>.zip bereitgestellt, die Sievon den ECS-Supportseiten unter support.emc.com herunterladen können.

Die ZIP-Datei enthält die Verzeichnisse /playbooks und /client. Bevor Sie dieDatei entzippen, erstellen Sie ein Verzeichnis für den Inhalt der Zip-Datei(möglicherweise wird es automatisch von Ihrem Unzip-Tool angelegt), und extrahierenSie den Inhalt in dieses Verzeichnis. Nachdem Sie die Dateien extrahiert haben,enthalten die Verzeichnisse Folgendes:



l /playbooks: Enthält Ansible-Playbooks für die Konfiguration einer sicherenHadoop-Umgebung für die Kommunikation mit ECS HDFS.

l /client: Enthält die folgenden Dateien:

n ECS-JAR-Dateien für die Clientbibliothek (ViPPRFS) (viprfs-client-<ECSversion>-hadoop-<Hadoop version>.jar): Zur Konfigurationverschiedener Hadoop-Distributionen

Bereitstellen der ECS HDFS-ClientbibliothekMit dem folgenden Verfahren fügen Sie die JAR-Datei der ECS HDFS-Clientbibliothekin den Klassenpfad der einzelnen Client-Nodes im Hadoop-Cluster ein.

Bevor Sie beginnen

Sie erhalten die ECS HDFS-Clientbibliothek für Ihre Hadoop-Distribution von der ECSSupport-Website, wie unter Abrufen des ECS HDFS-Installations- undSupportpakets auf Seite 152 beschrieben.

Die HDFS-Clientbibliothek verwendet die folgende Benennungskonvention:viprfs-client-<ECS version>-hadoop-<Hadoop version>.jar. Die JAR-Datei zurVerwendung mit dieser Version wird in der Tabelle unten genannt.

Tabelle 27 ECS HDFS-Clientbibliothek

Hadoop-Verteilung

Version ECS HDFS JAR

Hortonworks HDP 2.5 viprfs-client-<ECS-Version>-hadoop-2.7.jar

Hinweis

l Beim Upgrade auf eine neuere Version von ECS müssen Sie die ECS-HDFS-Clientbibliothek für die Version bereitstellen, auf die Sie ein Upgrade durchgeführthaben.

Vorgehensweise

1. Melden Sie sich bei einem Node an, mit dem SSH-Zugriff ohne Passwort aufalle Hadoop-Nodes möglich ist.

2. Führen Sie den Befehl classpath aus, um die Liste der Verzeichnisse imKlassenpfad abzurufen:

# hadoop classpath3. Stellen Sie die Client-JAR-Datei auf allen Hadoop-Nodes bereit, indem Sie die

folgenden Schritte ausführen:

a. Erstellen Sie eine Textdatei namens masters, die eine Liste der IP-Adressenoder FQDNs für alle Hadoop-Master-Nodes enthält, jeweils eine pro Zeile.

b. Erstellen Sie eine Textdatei namens workers, die eine Liste der IP-Adressenoder FQDNs für alle Hadoop-Worker-Nodes enthält, jeweils eine pro Zeile.

c. Erstellen Sie das Verzeichnis /usr/lib/hadoop/lib auf allen Nodes.Verwenden Sie den folgenden Befehl:

# cat masters workers | xargs -i -n 1 ssh root@{} mkdir -p /usr/lib/hadoop/lib


Bereitstellen der ECS HDFS-Clientbibliothek 153

d. Kopieren Sie die ECS-Client-JAR-Datei mit dem folgenden Befehl auf alleNodes:

cat masters workers | xargs -i -n 1 scp viprfs-client-3.1.0.0-hadoop-2.7.jar root@{}:/usr/lib/hadoop/lib/

Konfigurieren von ECS-Client-EigenschaftenSie können mit Ambari die folgenden Konfigurationseigenschaften festlegen, die derECS-Client benötigt.

Weitere Informationen zu den core-site.xml-Parametern finden Sie unter Hadoop-core-site.xml-Eigenschaften für ECS HDFS auf Seite 194.

Tabelle 28 Hadoop-Konfiguration zur Aktivierung des ECS-Zugriffs

Hadoop-Speicherort

Eigenschaft Wert

PrimärerStandort

fs.viprfs.impl com.emc.hadoop.fs.vipr.ViPRFileSystem

fs.AbstractFileSystem.viprfs.impl com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem

fs.viprfs.auth.identity_translation NONE

fs.viprfs.auth.anonymous_translation LOCAL_USER

fs.vipr.installations Kann ein beliebiger Name sein wie etwa federation1,und wird als $FEDERATION bezeichnet.Wenn Sie mehrere unabhängige ECS-Verbändehaben, geben Sie mehrere, durch Kommata getrennteWerte ein.

fs.vipr.installation.$FEDERATION.hosts Durch Kommata getrennte Liste der FQDN oder IP-Adressen eines jeden ECS-Host am lokalen Standort

fs.vipr.installation.$FEDERATION.hosts.resolution dynamic

fs.vipr.installation.$FEDERATION.resolution.dynamic.time_to_live_ms

900000

hdfs-Standort fs.permissions.umask-mode 022

yarn-Standort yarn.application.classpath Hängen Sie Folgendes an:

/usr/lib/hadoop/lib/*

mapred-Standort

mapreduce.application.classpath Hängen Sie Folgendes an:




Tabelle 28 Hadoop-Konfiguration zur Aktivierung des ECS-Zugriffs (Fortsetzung)

Hadoop-Speicherort

Eigenschaft Wert

tez-Standort tez.cluster.additional.classpath.prefix Hängen Sie Folgendes an:


HDFS hadoop-env-Vorlage Hängen Sie Folgendes an:

export HADOOP_CLASSPATH=${HADOOP_CLASSPATH}:/usr/lib/hadoop/lib/*

Spark spark-env-Vorlage Hängen Sie Folgendes an:

export SPARK_DIST_CLASSPATH="${SPARK_DIST_CLASSPATH}:/usr/lib/hadoop/lib/*:/usr/hdp/current/hadoop-client/client/guava.jar"

Einrichten von HiveDie zusätzlichen Schritte in diesem Verfahren sind zur Konfiguration von Hiveerforderlich.

Bevor Sie beginnen

Wenn Sie Hive verwenden, sollten Sie auch sicherstellen, dass das Hive MetastoreWarehouse auf den ViPRFS-Speicherort gerichtet ist. Vorausgesetzt, dass der HiveMetastore-Speicherort mit MySQL ermittelt wird, starten Sie MySQL, navigieren Siezu den Hive-Datenbanken, zeigen Sie den Inhalt der DBS-Tabelle an und richten SieHive wie unten beschrieben ein.

Vorgehensweise

1. Wenn Sie Hive Templeton verwenden, sollten Sie die folgenden Eigenschaftenändern, die bereits definiert sind.

Tabelle 29 Hive-Templeton-Konfiguration

Hadoop-Speicherort Eigenschaft Beispielwert

Erweiterte WebHCat-Website

templeton.hive.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/hive/hive.tar.gz

templeton.pig.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/pig/pig.tar.gz

templeton.sqoop.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/sqoop/sqoop.tar.gz


Einrichten von Hive 155

Tabelle 29 Hive-Templeton-Konfiguration (Fortsetzung)


templeton.streaming.jar viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/mapreduce/hadoop-streaming.jar

2. Starten Sie MySQL.

[root@hdfs-pansy2 lib]# mysql -u hive -pEnter password: Welcome to the MySQL monitor. Commands end with ; or \g.

3. Navigieren Sie zu der Hive-Datenbank.

mysql> use hive;Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -A

4. Zeigen Sie den Inhalt der Datenbank an.

select * from DBS;+------+-------------+-----------------------------------+--------+-------+------+|DB_ID | DESC | DB_LOCATION_URI | NAME | OWNER | OWNER|| | | | | _NAME | _TYPE|+------+-------------+-----------------------------------+--------+-------+------+| 1 | Default Hive| hdfs://hdfs-pansy1.ecs.lab.emc. |default |public |ROLE || | database | com:8020/apps/hive/warehouse | | | || | | | | | || 6 | NULL | viprfs://hdfsbucket.ns.Site1/ |retail |hdfs |USER || | | apps/hive/warehouse/retail_demo.db| _demo | | |+------+-------------+-----------------------------------+--------+-------+------+2 rows in set (0.00 sec)

5. Ändern Sie die Datenbank

mysql> update DBS set DB_LOCATION_URI='viprfs://hdfsbucket3.ns.Site1/apps/hive/warehouse' where DB_ID=1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0

Überprüfen des Hadoop-Zugriffs auf ECSSie müssen den Zugriff auf den ECS-Bucket überprüfen.

Sobald alle Hadoop-Client-Services gestartet wurden, stellen Sie sicher, dass Sie überdie Hadoop-CLI auf den ECS-Bucket zugreifen können. Der URI hat das Formatviprfs://bucket.namespace.federation/.



Für einen Bucket mit URI viprfs://hive-warehouse-1.ns1.federation1/können Sie eine Verzeichnisliste abrufen mit:

[root@mycluster1-master-0 ~]# hdfs dfs -ls viprfs://hive-warehouse-1.ns1.federation1/

Ein neuer Bucket ist leer, und dementsprechend wird nichts zurückgegeben.

Für denselben Bucket erstellen die folgenden Befehle eine leere Datei und rufen danneine Verzeichnisliste ab, in der die Datei angezeigt wird.

[root@mycluster1-master-0 ~]# hdfs dfs -touchz viprfs://hive-warehouse-1.ns1.federation1/hive-warehouse-1[root@mycluster1-master-0 ~]# hdfs dfs -ls viprfs://hive-warehouse-1.ns1.federation1/

Sichern des BucketsZusätzlich zum Konfigurieren einer Bucket-ACL sollte der Stammverzeichniseintragsofort nach Erstellung des Buckets erstellt und gesichert werden.

Bevor Sie beginnen

Dieses Verfahren sollte vom Bucket-Eigentümer durchgeführt werden; in diesemBeispiel ist das hdfs.

Vorgehensweise

1. Legen Sie die Modusbits in der Objekt-ACL des Stammverzeichnisses fest,sodass nur der Bucket-Eigentümer und die Standardgruppe auf den Bucketzugreifen können. Die Gruppe other, die alle ECS HDFS-Clientbenutzerumfasst, ist nicht berechtigt, auf das Stammverzeichnis zuzugreifen, und damitauch nicht berechtigt, auf Dateien in dem Bucket zuzugreifen.

[hdfs@hadoop-0 ~]$fs=viprfs://bucket.ns.fedhadoop fs -chmod 750 $fs/hadoop fs -chown hdfs:hdfs $fs/

2. Bestimmte Gruppen und Benutzer sollten der Objekt-ACL desStammverzeichnisses mithilfe des Befehls setfacl hinzugefügt werden.

Beachten Sie, dass diese Berechtigungen die angepassten Gruppen-ACLs desBuckets duplizieren, um sicherzustellen, dass alle HDFS-APIs dieselbeneffektiven Berechtigungen haben.

hadoop fs -setfacl -m group:hadoop:r-x $fs/hadoop fs -setfacl -m group:users:r-x $fs/hadoop fs -setfacl -m group:hive:r-x $fs/hadoop fs -setfacl -m group:spark:r-x $fs/


Sichern des Buckets 157

3. Überprüfen Sie die Berechtigungen.

hadoop fs -ls -d $fs/drwxr-x---+ - hdfs hdfs 0 2017-08-22 20:44 viprfs://bucket.ns.fed/

hadoop fs -getfacl $fs/# file: viprfs://bucket.ns.fed/# owner: hdfs# group: hdfsuser::rwxgroup::r-xgroup:hadoop:r-xgroup:hive:r-xgroup:spark:r-xgroup:users:r-xmask::r-xother::---

Verlagern des Standard-Dateisystems vom HDFS zu einemECS-Bucket

Obwohl das System jetzt verwendbar ist und scheinbar gut funktioniert, wird eineKonfiguration mit HDFS als Standarddateisystem nicht unterstützt. Daher müssen Siedas Standard-Dateisystem vom HDFS zum ECS-Root-Bucket verlagern. DiesesVerfahren kopiert alle Dateien vom HDFS-Dateisystem zu einem ECS-Bucket und legtanschließend den ECS-Bucket als Standarddateisystem fest.

Vorgehensweise

1. Beenden Sie mit Ambari alle Services, ausgenommen HDFS, YARN undZookeeper.

2. Kopieren Sie alle im DAS HDFS-Dateisystem vorhandenen Dateien auf den ECS-Bucket. Selbst bei einer Neuinstallation von Hadoop gibt es wichtigeVerzeichnisse, die im Standard-Hadoop-Dateisystem vorhanden sein müssen.Kopieren Sie die Dateien mit DistCp.

[hdfs@mycluster1-master-0~]$ hadoop distcp -skipcrccheck -update -pugp -i / viprfs://mycluster1-root.ns1.federation/

3. Konfigurieren Sie mit Ambari folgende Einstellungen:

Tabelle 30 Hadoop-Konfiguration, um Hive-Gleichzeitigkeit und ACID-Transaktionen zuermöglichen


Primärer HDFS Advanced-Standort fs.defaultFS viprfs://<bucket_name>.<namespace>.<federation_name>Beispiel:



Tabelle 30 Hadoop-Konfiguration, um Hive-Gleichzeitigkeit und ACID-Transaktionen zuermöglichen (Fortsetzung)


viprfs://mycluster1-root.ns1.federation1

Spark Advanced Spark-Standardeinstellungen

spark.eventLog.dir viprfs://<bucket_name>.<namespace>.<federation>/<spark-history>Beispiel:

viprfs://mycluster1-root.ns1.federation1/spark-history

Spark Advanced Spark-Standardeinstellungen

spark.history.fs.logDirectory viprfs://<bucket_name>.<namespace>.<federation>/<spark-history>Beispiel:

viprfs://mycluster1-root.ns1.federation1/spark-history

4. Beenden und starten Sie alle Services mit Ambari.

5. Vergewissern Sie sich, dass die richtigen Berechtigungen vorliegen. WennDistCp Fehler verursacht, wurden wichtigen Verzeichnissen möglicherweisenicht die nötigen Berechtigungen zugewiesen. Die folgenden Befehle legen diekorrekten Berechtigungen fest.

[hdfs@mycluster1-master-0~]$hadoop fs -chmod 777 /apps/hive/warehousehadoop fs -chown hive:hdfs /apps/hive/warehousehadoop fs -chmod -R 770 /user/ambari-qahadoop fs -chown -R ambari-qa:hdfs /user/ambari-qa


Verlagern des Standard-Dateisystems vom HDFS zu einem ECS-Bucket 159



KAPITEL 8

Konfiguration eines Kerberized Hadoop-Clusters mit ECS HDFS

l Integrieren eines sicheren Hadoop-Clusters mit ECS HDFS .............................162l Migration von einem einfachen zu einem Kerberos-Cluster.............................. 162l Zuordnen von Gruppennamen...........................................................................163l Konfigurieren von ECS-Nodes mit dem ECS-Serviceprinzipal.......................... 163l Aktivieren von Kerberos mit Ambari.................................................................. 167l Sichern des ECS-Buckets mithilfe von Metadaten........................................... 168l Neukonfigurieren von ECS-Client-Eigenschaften............................................. 172l Starten von Hadoop-Services und Überprüfung des Hadoop-Zugriffs auf ECS

..........................................................................................................................173

Konfiguration eines Kerberized Hadoop-Clusters mit ECS HDFS 161

Integrieren eines sicheren Hadoop-Clusters mit ECS HDFSSie können Ihre vorhandene Hadoop-Distribution, die mit Kerberos gesichert ist, inECS HDFS integrieren.

Sie müssen eine vollständige nicht sichere Installation von Hadoop und ECSdurchführen, bevor Sie optional Kerberos aktivieren.

Bevor Sie die Integrationsschritte durchführen, ist Folgendes erforderlich:

l Überprüfen Sie, ob ein Kerberos Key Distribution Center (KDC) installiert undkonfiguriert ist, um die Authentifizierung des Hadoop-Serviceprinzipals zuhandhaben. Wenn Sie Active Directory für die Authentifizierung von ECS-Benutzern verwenden, müssen Sie eine bereichsübergreifende Vertrauensstellungzwischen dem Kerberos-Bereich und dem ECS-Benutzerbereich einrichten.Informationen zur Einrichtung des Kerberos KDC und zur Konfiguration derVertrauensstellung finden Sie unter Hilfe für die Kerberos-Konfiguration auf Seite188.

l Stellen Sie sicher, dass Sie einen Bucket für das HDFS-Dateisystem erstellt haben(siehe Erstellen eines Buckets für HDFS über das ECS-Portal auf Seite 144).

l Stellen Sie sicher, dass Sie die Richtlinien für die Planung der Integration gelesenhaben (siehe Planen der Integration von ECS HDFS und Hadoop auf Seite 152).

l Stellen Sie sicher, dass Sie das Installations- und Supportpaket heruntergeladenhaben (siehe Abrufen des ECS HDFS-Installations- und Supportpakets auf Seite152).

Führen Sie die folgenden Aufgaben durch, um ECS HDFS in Ihr sicheres Hadoop-Cluster zu integrieren:

1. Migration von einem einfachen zu einem Kerberos-Cluster auf Seite 162

2. Zuordnen von Gruppennamen auf Seite 163

3. Konfigurieren von ECS-Nodes mit dem ECS-Serviceprinzipal auf Seite 163

4. Sichern des ECS-Buckets mithilfe von Metadaten auf Seite 168

5. Neukonfigurieren von ECS-Client-Eigenschaften auf Seite 172

6. Starten von Hadoop-Services und Überprüfung des Hadoop-Zugriffs auf ECS aufSeite 173

Migration von einem einfachen zu einem Kerberos-ClusterECS unterstützt die Migration von einem Hadoop-Cluster mit einfacher Sicherheit zueinem Hadoop-Cluster, das über Kerberos gesichert wird.

Wenn Sie von einer einfachen zu einer sicheren Umgebung migrieren, lesen Sie denAbschnitt Migration von einem einfachen zu einem Kerberos-Hadoop-Cluster auf Seite137.

Im Allgemeinen ermöglicht die Migrationsfunktion von ECS Kerberos-Benutzern einennahtlosen Zugriff auf Dateien und Verzeichnisse. Es gelten jedoch folgende Hinweise:

l Der Ambari-Assistent zur Sicherung eines Hadoop-Clusters meldet im letztenSchritt Fehler, wenn er die Hadoop-Services startet. Hierbei handelt es sich umerwartetes Verhalten. Sobald der ECS-Bucket neu konfiguriert wurde, damit ersicher ist, können Sie die Hadoop-Services starten.



l Damit Benutzer und Prozesse auf den Bucket zugreifen können, müssen sieMitglied der Gruppe sein, die Zugriff auf den Bucket hat. Andernfalls müssen Siedie Bucket-ACLs ändern, damit Kerberos-Benutzer Zugriff haben.

Zuordnen von Gruppennamen

ECS muss Gruppendetails für Hadoop-Serviceprinzipale wie hdfs, hive usw.zuordnen können. Bei Verwendung von Active Directory (AD) könnenGruppeninformationen aus zwei verschiedenen Quellen ermittelt werden: den Bucket-Metadaten oder AD. ECS ermittelt die zu verwendende Quelle aus einerKonfigurationsparametereinstellung in der Konfigurationsdatei /opt/storageos/conf/hdfssvc.conf im Abschnitt [hdfs.fs.request].

Wenn ECS die Gruppeninformationen (sofern verfügbar) aus den Bucket-Metadatenanstelle von AD abrufen soll, definieren Sie den Parameter wie folgt:

[hdfs.fs.request]prefer_secure_metadata_bucket_for_groups = true

Wenn ECS die Gruppeninformationen aus AD anstelle der Bucket-Metadaten abrufensoll, definieren Sie den Parameter wie folgt:

[hdfs.fs.request]prefer_secure_metadata_bucket_for_groups = false

Der Standardwert ist „true“. Wenn dieser Wert nicht definiert ist, ermittelt ECS dieGruppendetails für einen Kerberos-Prinzipal aus den Bucket-Metadaten. Sie müssenjede Änderung für alle ECS-Nodes anwenden und dataheadsvc auf allen Nodes neustarten.

Konfigurieren von ECS-Nodes mit dem ECS-Serviceprinzipal

Der ECS-Serviceprinzipal und die entsprechende keytab-Datei müssen sich auf deneinzelnen ECS-Daten-Nodes befinden. Sie müssen die bereitgestellten Ansible-Playbooks verwenden, um die erforderlichen Schritte zu automatisieren.

Bevor Sie beginnen

Sie benötigen die folgenden Elemente zum Abschluss des Vorgangs:

l Zugriff auf die Ansible-Playbooks. Rufen Sie die Ansible-Playbooks aus dem ECS-HDFS-Softwarepaket ab, wie unter Abrufen des ECS HDFS-Installations- undSupportpakets auf Seite 152 beschrieben.

l Die Liste der ECS-Node-IP-Adressen

l Die IP-Adresse des KDC

l Die DNS-Auflösung, in der Sie dieses Skript ausführen, muss der DNS-Auflösungfür den Hadoop-Host entsprechen, da vipr/_HOST@REALM andernfalls nichtfunktioniert.

ECS stellt wiederverwendbare Ansible-Inhalte mit der Bezeichnung „Rollen“ bereit, dieaus Python-Skripten, YAML-basierten Aufgabenlisten und Vorlagendateien bestehen.


Zuordnen von Gruppennamen 163

l vipr_kerberos_config: konfiguriert einen ECS-Node für Kerberos.

l vipr_jce_config: konfiguriert einen ECS-Daten-Node für eine Verschlüsselungmit unbegrenzter Stärke durch Installation von JCE-Policy-Dateien.

l vipr_kerberos_principal: ruft einen Serviceprinzipal für einen ECS-Nodeab.

Bei diesem Verfahren wird Ansible mit dem Docker-Dienstprogrammcontainerausgeführt, der mit ECS installiert wird.

Vorgehensweise

1. Melden Sie sich bei ECS-Node 1 an und kopieren Sie die Datei hdfsclient-<ECS version>-<version>.zip auf diesen Node.

Beispiel: /home/admin/ansible . Sie können das Paket mit wget direkt vonsupport.emc.com abrufen oder scp verwenden, wenn Sie es auf einen anderenRechner heruntergeladen haben.

2. Entpacken Sie die Datei hdfsclient-<ECS version>-<version>.zip.

Für die Schritte in diesem Verfahren werden die im Verzeichnis viprfs-client-<ECS version>-<version>/playbooks/samples enthaltenenPlaybooks verwendet. Die Schritte sind auch in viprfs-client-<ECSversion>-<version>/playbooks/samples/README.md enthalten.

3. Bearbeiten Sie die Datei inventory.txt im Verzeichnis playbooks/samples, um einen Verweis auf die ECS-Daten-Nodes und den KDC-Server zuerstellen.

Die Standardeinträge sind unten gezeigt.

[data_nodes]192.168.2.[100:200]

[kdc]192.168.2.10

4. Laden Sie das unbegrenzte bzw. unlimited JCE-Policy-Archiv von oracle.comherunter und extrahieren Sie es in ein UnlimitedJCEPolicy-Verzeichnis inviprfs-client-<ECS version>-<version>/playbooks/samples.

Hinweis

Dieser Schritt sollte nur durchgeführt werden, wenn Sie einen starkenVerschlüsselungstyp verwenden.

Kerberos kann für einen starken Verschlüsselungstyp konfiguriert werden, z. B.AES-256. In diesem Fall müssen Sie die JRE innerhalb der ECS-Nodes neukonfigurieren zur Verwendung der Policy.

5. Starten Sie den Dienstprogrammcontainer auf ECS-Node 1 und machen Sie dieAnsible-Playbooks für den Container verfügbar.

a. Laden Sie das Dienstprogrammcontainer-Image.



Beispiel:

sudo docker load -i /opt/emc/caspian/checker/docker/images/utilities.txz

b. Rufen Sie die Identität des Docker-Images ab.

Beispiel:

admin@provo-lilac:~> sudo docker images

Die Ausgabe enthält die Image-Identität:

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZEutilities 1.5.0.0-403.cb6738e 186bd8577a7a 2 weeks ago 738.5 MB

c. Starten Sie das Dienstprogramm-Image und rufen Sie es auf.

Beispiel:

sudo docker run -v /opt/emc/caspian/fabric/agent/services/object/main/log:/opt/storageos/logs -v /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks:/ansible --name=ecs-tools -i -t --privileged --net=host 186bd8577a7a /bin/bash

In diesem Beispiel wird das Verzeichnis /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks, in dem die Ansible-Playbooks extrahiert wurden, dem Verzeichnis /ansible imDienstprogrammcontainer zugeordnet.

6. Wechseln Sie im Container zum Arbeitsverzeichnis.

Beispiel:

cd /ansible

7. Kopieren Sie die Datei krb5.conf vom KDC in das Arbeitsverzeichnis.

8. Installieren Sie die bereitgestellten Ansible-Rollen.

ansible-galaxy install -r requirements.txt -f

9. Bearbeiten Sie generate-vipr-keytabs.yml nach Bedarf und legen Sieden Domainnamen fest.

Beispiel:

[root@nile3-vm22 samples]# cat generate-vipr-keytabs.yml---#### Generates keytabs for ViPR/ECS data nodes.### - hosts: data_nodes serial: 1


Konfigurieren von ECS-Nodes mit dem ECS-Serviceprinzipal 165

roles: - role: vipr_kerberos_principal kdc: "{{ groups.kdc | first }}" principals: - name: vipr/[email protected] keytab: keytabs/[email protected]

In diesem Beispiel wird der Standardwert (vipr/[email protected]) durch(vipr/[email protected]) ersetzt, und die Domain ist MA.EMC.COM.

10. Führen Sie den folgenden Befehl aus.

export ANSIBLE_HOST_KEY_CHECKING=False

11. Führen Sie das Ansible-Playbook aus, um keytab-Dateien zu generieren.

ansible-playbook -v -k -i inventory.txt --user admin –b --become-user=root generate-vipr-keytabs.yml

12. Bearbeiten Sie die Datei setup-vipr-kerberos.yml nach Bedarf.

Die Standarddateiinhalte sind unten gezeigt.

# 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/[email protected] keytab: keytabs/[email protected]

- role: vipr_jce_config jce_policy: name: unlimited src: UnlimitedJCEPolicy/

In diesem Beispiel wird der Standardwert (vipr/[email protected]) durch(vipr/[email protected]) ersetzt, und die Domain ist MA.EMC.COM.

Hinweis

Sie müssen die Rolle vipr_jce_config entfernen, wenn Sie keinen starkenVerschlüsselungstyp verwenden.



13. Führen Sie das Ansible-Playbook aus, um die Daten-Nodes mit dem ECS-Serviceprinzipal zu konfigurieren.

Stellen Sie sicher, dass das Verzeichnis /ansible/samples/keytabvorhanden ist und sich die Datei krb5.conf im Arbeitsverzeichnis /ansible/samples befindet.

ansible-playbook -v -k -i inventory.txt --user admin –b --become-user=root setup-vipr-kerberos.yml

Überprüfen Sie, ob jeweils ein korrekter ECS-Serviceprinzipal pro Daten-Nodeerstellt wurde (vom KDC):

# kadmin.local -q "list_principals" | grep viprvipr/[email protected]/[email protected]

Überprüfen Sie, ob die korrekte keytab-Datei generiert und am Speicherort /data/hdfs/krb5.keytab auf allen ECS-Daten-Nodes gespeichert wurde.Sie können den Befehl strings mit der keytab-Datei verwenden, um denvisuell lesbaren Text zu extrahieren und zu überprüfen, ob er den korrektenPrinzipal enthält. Beispiel:

dataservice-10-247-199-69:~ # strings /data/hdfs/krb5.keytabMA.EMC.COMviprnile3-vm42.centera.lab.emc.com

In diesem Fall ist der Prinzipal vipr/nile3-vm42.centera.lab.emc.com.

Aktivieren von Kerberos mit AmbariSie müssen Kerberos mit Ambari aktivieren.

Dieses Verfahren enthält die grundlegenden Schritte, die zur Aktivierung von Kerberosdurchzuführen sind. Weitere Informationen zum Ambari-Kerberos-Assistenten findenSie hier.

Vorgehensweise

1. Wählen Sie in der Ambari-Schnittstelle Ambari > Admin > Kerberos > Kerberosaktivieren, um den Assistenten zum Aktivieren von Kerberos aufzurufen.

2. Führen Sie im Assistenten die Schritte im Bereich für Kerberized-Cluster durch.Klicken Sie auf das X, um den Kerberos-Assistenten zu beenden.


Aktivieren von Kerberos mit Ambari 167

https://docs.hortonworks.com/HDPDocuments/Ambari-2.2.0.0/bk_Ambari_Security_Guide/content/_running_the_kerberos_wizard.html

Dieser Schritt mit den Kerberized-Clustern kann jetzt übersprungen werden, dadie Hadoop-Services zu diesem Zeitpunkt nicht gestartet werden können.

3. Bestätigen Sie, dass Sie den Assistenten beenden möchten, indem Sie imDialogfeld „Bestätigung“ auf Trotzdem beenden klicken.

Sichern des ECS-Buckets mithilfe von MetadatenUm sicherzustellen, dass der ECS-Bucket mit einem sicheren Hadoop-Clusterzusammenarbeiten kann, muss der Bucket auf Informationen zum Cluster zugreifenkönnen.

In einem sicheren Hadoop-Cluster muss der Kerberos-Prinzipal einem HDFS-Benutzernamen zugeordnet werden. Darüber hinaus muss der Benutzer einer UNIX-Gruppe zugeordnet werden. Innerhalb des Hadoop-Clusters erfasst der NameNodediese Informationen aus den Hadoop-Nodes selbst sowie aus denKonfigurationsdateien (core-site.xml und hdfs.xml).

Damit die ECS-Nodes diese Informationen bestimmen und Clientanforderungen prüfenkönnen, müssen die folgenden Daten den ECS-Nodes zur Verfügung gestellt werden:

l Zuordnung von Kerberos-Benutzern zu UNIX-Benutzern und -gruppen

l Superuser-Gruppe

l Proxybenutzer-Einstellungen

Die Daten werden den ECS-Nodes als eine Reihe von Name-Wert-Paarenbereitgestellt, die als Metadaten gespeichert werden.



Kerberos-BenutzerInformationen zu allen Kerberos-Benutzern (nicht AD-Benutzern), die Hadoop-Zugriffauf einen Bucket benötigen, müssen in ECS hochgeladen werden. Die folgenden Datensind erforderlich:

l Prinzipalname

l Prinzipal-Kurzname (zugeordneter Name)

l Prinzipalgruppen

Wenn 10 Kerberos-Prinzipale auf einem Hadoop-Node vorhanden sind, müssen Sie 30Name-Wert-Paare in der JSON-Eingabedatei erstellen. Alle Namen müssen eindeutigsein, so dass Sie einen eindeutigen Namen für jeden Prinzipalnamen, jeden Prinzipal-Kurznamen und jede Prinzipalgruppe zuweisen müssen. ECS erwartet ein konstantesPräfix und Suffix für die JSON-Eintragsnamen.

Das erforderliche Präfix für jeden Kerberos-Benutzereintrag istinternal.kerberos.user, und die drei möglichen Suffixe sind name, shortnameund groups, wie im folgenden Beispiel gezeigt.

{ "name": "internal.kerberos.user.hdfs.name", "value": "hdfs-cluster999@EXAMPLE_HDFS.EMC.COM"},{ "name": "internal.kerberos.user.hdfs.shortname", "value": "hdfs"},{ "name": "internal.kerberos.user.hdfs.groups", "value": "hadoop,hdfs"},

Der Wert zwischen Präfix und Suffix kann beliebig sein, solange er den Eintrageindeutig identifiziert. Sie können z. B. Folgendes verwenden:

"name": "internal.kerberos.user.1.name","name": "internal.kerberos.user.1.shortname","name": "internal.kerberos.user.1.groups",

Prinzipale können eine Zuordnung zu einem anderen Benutzer enthalten.Beispielsweise ist der Prinzipalbenutzer rm in der Regel über die Einstellungauth_to_local für das Hadoop-Cluster den yarn-Benutzern zugeordnet, wie hiergezeigt.

RULE:[2:$1@$0](rm@EXAMPLE_HDFS.EMC.COM)s/.*/yarn/

Also müssen Sie für alle Prinzipale, die eine Zuordnung zu einem anderen Prinzipalenthalten (z. B. führt der Prinzipal rm eine Zuordnung zum Prinzipal yarn durch), denPrinzipal „mapped“ im Wert „shortname“ verwenden. Der Eintrag für den Prinzipal rmlautet also:

{"name": "internal.kerberos.user.rm.name","value": "rm@EXAMPLE_HDFS.EMC.COM"},{"name": "internal.kerberos.user.yarn.shortname",


Sichern des ECS-Buckets mithilfe von Metadaten 169

"value": "yarn@EXAMPLE_HDFS.EMC.COM"},{"name": "internal.kerberos.user.yarn.groups","value": "hadoop"},

SupergroupSie müssen dem ECS mitteilen, welche Linux-Benutzergruppe auf den Hadoop-NodesSuperuser-Berechtigungen basierend auf ihrer Gruppe erhalten sollen. Zur Festlegungder Supergroup wird nur ein Eintrag in der JSON-Eingabedatei erwartet. Das mussdann wie folgt aussehen:

{ "name": "dfs.permissions.supergroup", "value": "hdfs"}

ProxyeinstellungenFür Proxy-Support müssen Sie alle Proxyeinstellungen angeben, die für jede Hadoop-Anwendung zulässig sind. Anwendung bedeutet in diesem Fall eine der von Hadoopunterstützten Anwendungen, z. B. hive, hbase usw.

Im folgenden Beispiel wird Benutzern, die Mitglied der Gruppe s3users sind (ActiveDirectory- oder Linux-Gruppe) und hive auf einem der Hosts im Hadoop-Clusterausführen können, Proxy-Support für die hive-Anwendung gewährt. So besteht derJSON-Eintrag in diesem Fall aus zwei Name-Wert-Paaren, einem für dieHosteinstellung und einem für die Gruppeneinstellung.

{ "name": "hadoop.proxyuser.hive.hosts", "value": "*"},{ "name": "hadoop.proxyuser.hive.groups", "value": "s3users"}

Die vollständige DateiDie drei Arten von Metadaten müssen in einer einzigen JSON-Datei kombiniertwerden. Das JSON-Dateiformat sieht aus wie im folgenden Beispiel gezeigt.

{ "head_type": "hdfs", "metadata": [ { "name": "METADATANAME_1", "value": "METADATAVALUE_1" }, { "name": "METADATANAME_2", "value": "METADATAVALUE_2" },

:

{ "name": "METADATANAME_N",



"value": "METADATAVALUE_N" } ]}

Hinweis

Das letzte Name-Wert-Paar enthält kein nachgestelltes „,“-Zeichen.

Ein Beispiel für eine JSON-Datei finden Sie unter: Sichere Bucket-Metadaten aufSeite 200.

Sichere und nicht sichere BucketsSobald Metadaten in einen Bucket geladen wurden, wird er als sicherer Bucketbezeichnet, und Sie müssen über Kerberos-Prinzipale verfügen, um darauf zugreifenzu können. Eine Anforderung von einem nicht sicheren Hadoop-Node wird abgelehnt.Wenn keine Metadaten geladen wurden, gilt der Bucket als nicht sicher und eineAnforderung von einem sicheren Hadoop-Node wird abgelehnt.

Die folgende Fehlermeldung wird angezeigt, wenn Sie versuchen, über ein nichtsicheres Cluster auf einen sicheren Bucket zuzugreifen. Eine ähnliche Meldung wirdangezeigt, wenn Sie versuchen, über ein sicheres Cluster auf einen nicht sicherenBucket zuzugreifen.

[hdfs@sandbox ~]$ hadoop fs -ls -R viprfs://hdfsBucket3.s3.site1/ls: ViPRFS internal error (ERROR_FAILED_TO_PROCESS_REQUEST).

Laden von Metadatenwerten in ECS mithilfe der Management-REST-APIDie Metadatenwerte zur Sicherung eines ECS-Buckets für die Verwendung mit einemsicheren Hadoop-Cluster können mit ECS-Management-REST-API-Befehlenbereitgestellt werden.

Bevor Sie beginnen

Hierfür benötigen Sie die Anmeldedaten eines ECS-Systemadministrators.

Wenn der Hadoop-Administrator nicht dem ECS-Systemadministrator entspricht,muss der Hadoop-Administrator mit dem ECS-Systemadministratorzusammenarbeiten, um die sicheren Metadaten in den Bucket zu laden.

Der Hadoop-Administrator kann dem ECS-Systemadministrator die JSON-Metadatendatei zur Verfügung stellen, damit dieser mit dem folgenden Verfahren dieMetadaten laden kann. Wenn die beiden Rollen von demselben Benutzer erfülltwerden, muss dieser Benutzer die JSON-Metadatendatei erstellen und in den ECS-Bucket laden.

Vorgehensweise

1. Erstellen Sie die JSON-Datei mit den Metadaten, wie hier beschrieben: Sicherndes ECS-Buckets mithilfe von Metadaten auf Seite 168.

2. Melden Sie sich mit den Anmeldedaten eines Systemadministrators bei ECS an,um ein Authentifizierungstoken zu erhalten, das bei der Ausführung der ECS-Managementbefehle verwendet werden kann.

Sie können diesen Anmeldebefehl mit Curl ausführen. Im folgenden Beispielmüssen Sie <username>:<password> durch die Anmeldedaten des ECS-


Laden von Metadatenwerten in ECS mithilfe der Management-REST-API 171

Systemadministrators ersetzen und die IP-Adresse oder den Hostnamen einesECS-Nodes angeben.

TOKEN=$(curl -s -k -u <username>:<password> -D - -o /dev/null https://<ECS node IP or hostname>:4443/login | grep X-SDS-AUTH-TOKEN | tr -cd '\40-\176')

3. Führen Sie den ECS-Management-REST-API-Befehl PUT object/bucket/<bucketname>/metadata aus, um die Metadaten bereitzustellen, wie imfolgenden Beispiel gezeigt:

curl -s -k -X PUT -H "$TOKEN" -H "Accept: application/json" -H "Content-Type: application/json" -T <bucketDetails>.json https:/<hostname>:4443/object/bucket/<bucketname>/metadata?namespace=<namespace>

Ersetzt werden muss:

l <username> durch den Benutzernamen eines ECS-Systemadministrators.

l <password> durch das Passwort für den angegebenen Benutzernamen desECS-Systemadministrators.

l <bucketname> durch den Namen des Buckets, den Sie für HDFS-Datenverwenden.

l <hostname> durch die IP-Adresse oder den Hostnamen eines ECS-Nodes.

l <bucketdetails> durch den Dateinamen der JSON-Datei mit den Name-Wert-Paaren.

l <namespace> durch den Namen des Namespace, in dem der Bucket sichbefindet.

Nach der Bereitstellung stehen die Metadaten für alle ECS-Nodes zurVerfügung.

Neukonfigurieren von ECS-Client-EigenschaftenSie können mit Ambari die Konfigurationseigenschaften festlegen, die der ECS-Clientbenötigt.

In der folgenden Tabelle sind die erforderlichen Eigenschaften aufgeführt.

Tabelle 31 Hadoop-Konfiguration zur Aktivierung des ECS-Zugriffs

Hadoop-Speicherort

Eigenschaft Wert

PrimärerStandort

fs.viprfs.auth.identity_translation CURRENT_USER_REALM

fs.viprfs.auth.anonymous_translation CURRENT_USER

viprfs.security.principal Vipr/[email protected], wobei REALM.COMdurch Ihren Kerberos-Bereichsnamen ersetzt wird.

Weitere Informationen zu jedem core_site.xml-Parameter finden Sie unter Hadoop-core-site.xml-Eigenschaften für ECS HDFS auf Seite 194.



Starten von Hadoop-Services und Überprüfung des Hadoop-Zugriffs auf ECS

Starten Sie die Hadoop-Services.

Vorgehensweise

1. Starten Sie die Hadoop-Services mit Ambari.

2. Sobald alle Hadoop-Client-Services gestartet wurden, stellen Sie sicher, dassüber die Hadoop-CLI mit folgendem Befehl auf den ECS-Bucket zugegriffenwerden kann.

hdfs dfs -ls /


Starten von Hadoop-Services und Überprüfung des Hadoop-Zugriffs auf ECS 173



KAPITEL 9

Troubleshooting

l Einleitung..........................................................................................................176l Überprüfen der korrekten Konfiguration von AD/LDAP mit einem sicheren

Hadoop-Cluster................................................................................................ 176l Fehlschlagen des Pig-Tests: Kerberos-Prinzipal kann nicht abgerufen werden

..........................................................................................................................177l Abgelehnte Berechtigung für AD-Benutzer....................................................... 177l Berechtigungsfehler..........................................................................................177l Verarbeitung der Anforderung fehlgeschlagen..................................................180l Aktivieren von clientseitiger Kerberos-Anmeldung und Debugging.................... 181l Debuggen von Kerberos auf dem KDC...............................................................181l Beseitigen von Uhrabweichungen..................................................................... 182l Konfigurieren eines oder mehrerer neuer ECS-Nodes mit dem ECS-

Serviceprinzipal................................................................................................ 182l Workaround für Fehler „Yarn-Verzeichnis ist nicht vorhanden“........................184

Troubleshooting 175

EinleitungIn diesem Abschnitt finden Sie Workarounds für Probleme, die möglicherweise bei derKonfiguration von ECS HDFS auftreten.

Überprüfen der korrekten Konfiguration von AD/LDAP miteinem sicheren Hadoop-Cluster

Überprüfen Sie, ob AD oder LDAP ordnungsgemäß mit dem KDC-Cluster (Kerberos)und dem Hadoop-Cluster konfiguriert ist.

Bei einer korrekten Konfiguration ist es möglich, den kinit-Befehl für einen AD/LDAP-Benutzer anzuwenden. Wenn das Hadoop-Cluster für lokales HDFS konfiguriertist, ist es zudem möglich, das lokale HDFS-Verzeichnis aufzulisten, bevor ECS zumCluster hinzugefügt wird.

WorkaroundWenn Sie sich nicht als AD/LDAP-Benutzer mit KDC auf dem Hadoop-Clusteranmelden können, sollten Sie dieses Problem beheben, bevor Sie mit der ECS Hadoop-Konfiguration fortfahren.

Ein Beispiel für die erfolgreiche Anmeldung ist nachfolgend dargestellt:

[kcluser@lvipri054 root]$ kinit [email protected] for [email protected]:

[kcluser@lvipri054 root]$ klistTicket cache: FILE:/tmp/krb5cc_1025Default principal: [email protected]

Valid starting Expires Service principal04/28/15 06:20:57 04/28/15 16:21:08 krbtgt/[email protected] renew until 05/05/15 06:20:57

Wenn der oben dargestellte Vorgang nicht erfolgreich ist, führen Sie eine Ermittlunganhand der folgenden Checkliste durch:

l Prüfen Sie, ob die Datei /etc/krb5.conf auf dem KDC-Server korrekt ist unddie richtige Syntax aufweist. Bei Bereichen muss in Konfigurationsdateien oder beider Verwendung des Befehls kinit unter Umständen die Groß-/Kleinschreibungbeachtet werden.

l Prüfen Sie, ob die Datei /etc/krb5.conf vom KDC-Server auf alle Hadoop-Nodes kopiert wird.

l Prüfen Sie, ob die unidirektionale Vertrauensstellung zwischen AD/LDAP- undKDC-Server erfolgreich hergestellt wurde.

l Überprüfen Sie, ob der Verschlüsselungstyp auf dem AD/LDAP-Server dem Typauf dem KDC-Server entspricht.

l Prüfen Sie, ob die Dateien /var/kerberos/krb5kdc/kadm5.acl und /var/kerberos/krb5kdc/kdc.conf korrekt sind.

Troubleshooting


l Versuchen Sie, sich als Serviceprinzipal beim KDC-Server anzumelden, um zuüberprüfen, ob der KDC-Server selbst ordnungsgemäß funktioniert.

l Versuchen Sie, sich als derselbe AD/LDAP-Benutzer direkt beim KDC-Serveranzumelden. Wenn dies nicht funktioniert, liegt das Problem wahrscheinlich amKDC-Server selbst.

Fehlschlagen des Pig-Tests: Kerberos-Prinzipal kann nichtabgerufen werden

Der Pig-Test schlägt fehl mit dem Fehler Info:Error: java.io.IOException:Unable to obtain the Kerberos principal, auch nach kinit als AD-Benutzer, oder mit dem Fehler Unable to open iterator for aliasfirstten.

Dieses Problem wird aufgrund der Tatsache verursacht, dass Pig (Version 0.13 oderfrüher) kein Delegationstoken für ViPRFS als sekundären Speicher generiert.

WorkaroundHängen Sie viprfs://bucket.ns.installation/ an dieKonfigurationseinstellung mapreduce.job.hdfs-servers an. Beispiel:

set mapreduce.job.hdfs-servers viprfs://KcdhbuckTM2.s3.site1

Abgelehnte Berechtigung für AD-BenutzerBeim Ausführen einer Anwendung als AD-Benutzer wird der Fehler Permissiondenied ausgegeben.

WorkaroundLegen Sie die Berechtigungen für das Verzeichnis /user wie folgt fest:

hdfs dfs -chmod 1777 /user

BerechtigungsfehlerFehler zu unzureichenden Berechtigungen können für aus verschiedenen Gründenauftreten. Es wird möglicherweise ein Fehler dieser Art ausgegeben, wenn Sie einenhadoop fs-Befehl ausführen, oder ein solcher Fehler kann in einemAnwendungsprotokoll auftreten, wie im Protokoll für mapreduce oder hive.

INSUFFICIENT_PERMISSIONS-Fehler

Im folgenden Beispiel hat der Prinzipal jhs versucht, ein Verzeichnis zu erstellen (/tmp), und den Fehler INSUFFICIENT_PERMISSIONS erhalten. In diesem Fallerlaubten die Berechtigungen des Root-Verzeichnisses nicht, dass dieser Benutzer einVerzeichnis erstellt.

root@lrmk042:/etc/security/keytabs# hadoop fs -mkdir /tmp15/11/08 21:03:09 ERROR vipr.ViPRFileSystemClientBase: Permissions failure for request: User: jhs/lrmk042.lss.emc.com@HOP171_HDFS.EMC.COM (auth:KERBEROS), host:

Troubleshooting

Fehlschlagen des Pig-Tests: Kerberos-Prinzipal kann nicht abgerufen werden 177

hdfsBucket3.s3.site1, namespace: s3, bucket: hdfsBucket315/11/08 21:03:09 ERROR vipr.ViPRFileSystemClientBase: Request message sent: MkDirRequestMessage[kind=MKDIR_REQUEST,namespace=s3,bucket=hdfsBucket3,path=/tmp,hdfsTrustedStatus=HDFS_USER_NOT_TRUSTED,permissions=rwxr-xr-x,createParent=true]mkdir: java.security.AccessControlException: ERROR_INSUFFICIENT_PERMISSIONS

root@lrmk042:/etc/security/keytabs# hadoop fs -ls -d /drwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /root@lrmk042:/etc/security/keytabs#

Wenn die Ursache des Fehlers zu unzureichenden Berechtigungen nicht aus demClient hervorgeht, werfen Sie einen Blick in die Serverprotokolle. Beginnen Sie mitdataheadsvc-error.log, um den Fehler zu suchen. Öffnen Sie einTerminalfenster für jeden ECS-Node und bearbeiten Sie die Datei dataheadsvc-error.log. Suchen Sie den Fehler, der zu dem Zeitpunkt aufgetreten ist, an dem derFehler im Client angezeigt wurde.

Fehler beim Abrufen der Anmeldedaten

Angenommen, es wird ein Fehler wie der folgende im dataheadsvc-error.logangezeigt:

2015-11-08 22:36:21,985 [pool-68-thread-6] ERROR RequestProcessor.java (line 1482) Unable to get group credentials for principal 'jhs@HOP171_HDFS.EMC.COM'. This principal will default to use local user groups. Error message: java.io.IOException: Failed to get group credentials for 'jhs@HOP171_HDFS.EMC.COM', status=ERROR

Hierbei handelt es sich um keinen Fehler. Die Meldung bedeutet, dass der Serverversucht hat, den Prinzipalnamen nachzuschlagen, um festzustellen, obzwischengespeicherte Active Directory-Gruppen (AD-Gruppen) für denPrinzipalbenutzer, der die Anforderung gesendet hat, vorhanden sind. Dieser Fehlerwird bei einem Kerberos-Benutzer zurückgegeben.

In dem Fehler wird der Benutzername genannt, der die Anforderung gesendet hat.Notieren Sie diesen.

Bucket-Zugriffsfehler

Wenn ein Benutzer, der nicht über ACL-Berechtigungen verfügt, Zugriff auf einenBucket anfordert, wird möglicherweise der folgende Fehler im dataheadsvc-error.log angezeigt.

2015-11-08 21:35:26,652 [pool-68-thread-1] ERROR BucketAPIImpl.java (line 220) Getting bucket failed withcom.emc.storageos.objcontrol.object.exception.ObjectAccessException: you don't have GET_KEYPOOL_ACL permission to this keypoolat com.emc.storageos.objcontrol.object.exception.ObjectAccessException.createExceptionForAPI(ObjectAccessException.java:286)at com.emc.storageos.data.object.ipc.protocol.impl.ObjectAccessExceptionParser.parseFrom(ObjectAccessExceptionParser.java:61)

In diesem Fall sollten Sie entweder eine explizite Benutzer-ACL für den Bucket odereine angepasste Gruppen-ACL für eine der Gruppen hinzufügen, der der Benutzerangehört.

Troubleshooting


Objekt-Zugriffsfehler

Eine andere Art von Berechtigungsfehler sind Objekt-Zugriffsfehler. Der Zugriff aufObjekte (Dateien und Verzeichnisse) sollte nicht mit Zugriff auf einen Bucketverwechselt werden. Ein Benutzer kann über alle Steuerungsberechtigungen (Lesen/Schreiben/Löschen) für einen Bucket verfügen, erhält jedoch möglicherweisedennoch einen INSUFFICIENT_PERMISSIONS-Fehler, da er keinen Zugriff auf einoder mehrere Objekte im aufgerufenen Pfad hat. Nachfolgend ist ein Beispiel für einenObjektzugriffsfehler dargestellt.

2015-11-08 22:36:21,995 [pool-68-thread-6] ERROR FileSystemAccessHelper.java (line 1364) nfsProcessOperation failed to process path: mr-history/done2015-11-08 22:36:21,995 [pool-68-thread-6] ERROR ObjectControllerExceptionHelper.java (line 186) Method nfsGetSMD failed due to exceptioncom.emc.storageos.data.object.exception.ObjectControllerException: directory server returns error ERROR_ACCESS_DENIEDat com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessHelper.nfsProcessOperation(FileSystemAccessHelper.java:1368)at com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessHelper.getSystemMetadata(FileSystemAccessHelper.java:466)at com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessLayer.getSystemMetadata(FileSystemAccessLayer.java:532)at com.emc.storageos.data.object.blob.client.BlobAPI.getStat(BlobAPI.java:1294)at com.emc.vipr.engine.real.RealBlobEngine.stat(RealBlobEngine.java:1976)at com.emc.vipr.engine.real.RealBlobEngine.stat(RealBlobEngine.java:802)at com.emc.vipr.hdfs.fs.RequestProcessor.accept(RequestProcessor.java:499)at com.emc.vipr.hdfs.net.ConnectionManager$RequestThread.run(ConnectionManager.java:136)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at java.lang.Thread.run(Thread.java:745)

Besonders zu beachten sind hier die angeforderte Aktion (stat) und der Pfad desObjekts (mr-history/done). Beachten Sie, dass der vorangestellte Schrägstrichnicht angezeigt wird. Der tatsächliche Pfad lautet also /mr-history/done. Sieverfügen jetzt über drei Informationen zur Fehlerbehebung:

l Benutzerprinzipal (jhs@HOP171_HDFS.EMC.COM)l Aktion (stat ist hadoop fs -ls)l Pfad (/mr-history/done)

Es gibt zwei Ansätze für die weiterführende Fehlerbehebung:

l Debugging mit dem blobsvc-Protokoll auf Seite 179l Debugging mit dem Hadoop-Client auf Seite 180

Debugging mit dem blobsvc-ProtokollEine aufgrund von Berechtigungen fehlgeschlagene Anforderung wird in blobsvc miteinem Fehler wie diesem protokolliert:

2015-11-08 22:36:21,994[TaskScheduler-BlobService-COMMUNICATOR-ParallelExecutor-5892]ERROR ObjectAclChecker.java (line 101) not permit, cred jhs@HOP171_HDFS.EMC.COM[hadoop]false1 withaction GET_OBJECT_ACL on object with acl/owner/group user={hdfs@hop171_hdfs.emc.com=[FULL_CONTROL]},groups={hdfs=[READ_ACL, EXECUTE, READ]}, other=[], owner=hdfs@hop171_hdfs.emc.com, group=hdfs

Troubleshooting

Berechtigungsfehler 179

Suchen Sie nach not permit. Dort finden Sie den Benutzer, der die Anforderunggesendet hat (jhs), den Eigentümer des Objekts (hdfs), die Objektgruppe (hdfs)und die Berechtigungen für Eigentümer, Gruppe und andere. Sie erfahren allerdingsnicht, welches Objekt die Berechtigungsprüfung nicht bestanden hat. Melden Sie aufdem Hadoop-Node mit dem hdfs-Prinzipal an. Beginnen Sie mit den Pfad undbewegen Sie sich durch die Struktur nach oben. Dies führt zu einer anderenDebugging-Methode, bei der das Hadoop-Dateisystem aus der Sicht des Clientsbetrachtet wird.

Debugging mit dem Hadoop-ClientWenn einem Berechtigungsfehler empfangen wird, sollten Sie den Benutzerprinzipalkennen, der die Anforderung sendet, und wissen, welche Aktion und welche Elementeangefordert werden. In dem Beispiel erhält der Benutzer jhs einen Fehler bei demVersuch, das Verzeichnis /mr-history/done aufzulisten. Sie können einigeAnalysen durchführen, um die Ursache zu ermitteln. Wenn Sie Zugriff auf dasSuperuser-Konto haben, führen Sie diese Schritte mit diesem Konto durch.

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /mr-history/donedrwxrwxrwt - mapred hadoop 0 2015-11-08 16:58 /mr-history/done

Das folgende Beispiel zeigt, dass der Prinzipal jhs berechtigt ist, dieses Verzeichnisaufzulisten.

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /mr-historydrwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /mr-history

Analog dazu zeigt die folgende Ausgabe, dass für das Verzeichnis keineZugriffsprobleme vorliegen.

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /drwxr-x--- - hdfs hdfs 0 2015-11-08 16:58 /

Das Problem besteht darin, dass das Stammverzeichnis Eigentum von hdfs ist undder Gruppenname hdfs lautet, aber die Einstellung others ist - (0). Der Benutzer,der die Anforderung sendet, ist jhs@REALM. Dieser Benutzer ist Mitglied vonhadoop, aber nicht von hdfs, sodass er über keine ACL-Objektberechtigung zurAuflistung des Verzeichnisses /mr-history/done verfügt. Führen Sie einen chmod-Befehl für das Stammverzeichnis durch, damit dieser Benutzer die Aufgabedurchführen kann.

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -chmod 755 /

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /drwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /

Verarbeitung der Anforderung fehlgeschlagenDer Fehler „Verarbeitung der Anforderung fehlgeschlagen“ kann bei der Auflistungeines Buckets angezeigt werden.

Troubleshooting


Beispielsweise kann bei der Ausführung des Befehls „list bucket“:

# hadoop fs -ls viprfs://hdfsBucket2.s3.site1/

der folgende interne ViPRFS-Fehler ausgegeben werden:

ERROR_FAILED_TO_PROCESS_REQUEST

WorkaroundMögliche Gründe für diesen Fehler sind:

1. Die JAR-Datei des viprfs-Client auf dem Hadoop-Node ist nicht mit der ECS-Software synchronisiert.

2. Sie versuchen, von einem nicht sicheren (Nicht-Kerberos-)Hadoop-Knoten aufeinen sicheren (Kerberos-)Bucket zuzugreifen.

3. Sie versuchen, von einem sicheren (Kerberos-)Hadoop-Knoten auf einen nichtsicheren (Nicht-Kerberos-)Bucket zuzugreifen.

Aktivieren von clientseitiger Kerberos-Anmeldung undDebugging

Zum Troubleshooting von Authentifizierungsproblemen können Sie die detaillierteProtokollierung und das Debugging auf dem aktuell verwendeten Hadoop-Cluster-Node aktivieren.

Aktivieren von clientseitiger detaillierter ProtokollierungSie können die detaillierte Protokollierung wie im folgenden Beispiel gezeigt mithilfeeiner Umgebungsvariablen aktivieren, die nur auf die aktuelle SSH-Sitzungangewendet wird.

export HADOOP_OPTS="-Dsun.security.krb5.debug=true"

Aktivieren von clientseitigem Debugging auf dem Hadoop-NodeZum Troubleshooting von Hadoop-Aktivität zwischen dem Hadoop-Node und demECS können Sie wie folgt die detaillierte Hadoop-Protokollierung aktivieren:

export HADOOP_ROOT_LOGGER="Debug,console"

Debuggen von Kerberos auf dem KDCSie können Kerberos auf dem KDC mit dem Befehl tail auf der KDC-Datei /var/log/krb5kdc.log debuggen, um das Debugging zu erleichtern, wennSie einen HDFS-Vorgang durchführen.

tail -f /var/log/krb5kdc.log

Troubleshooting

Aktivieren von clientseitiger Kerberos-Anmeldung und Debugging 181

Beseitigen von UhrabweichungenDa Kerberos von einer genauen Uhrzeit abhängig ist, muss sichergestellt sein, dass dieUhrzeiten von Client und Server synchronisiert sind.

Wenn zwischen Active Directory (AD) und Daten-Nodes/KDC eine Uhrabweichungvorliegt, müssen Sie den NTP-Server konfigurieren. Gehen Sie dazu wie folgt vor:

1. Verbinden Sie sich mithilfe des Remotedesktops mit dem AD-Server.

2. Führen Sie folgende Befehle aus:

a. w32tm /config /syncfromflags:manual /manualpeerlist:<ntp-server1>,<ntp-server2>

b. net stop w32timec. net start w32time

Konfigurieren eines oder mehrerer neuer ECS-Nodes mitdem ECS-Serviceprinzipal

Wenn Sie einer ECS-Konfiguration einen oder mehrere neue Nodes hinzufügen,müssen der ECS-Serviceprinzipal und die entsprechende Keytab-Datei für die neuenNodes bereitgestellt werden.

Bevor Sie beginnen

l Bei diesem Verfahren wird davon ausgegangen, dass Sie zuvor die hierbeschriebenen Schritte ausgeführt haben und die Ansible-Playbooks installiert undzugänglich sind.

Sie benötigen die folgenden Elemente zum Abschluss des Vorgangs:

l Die Liste der ECS-Node-IP-Adressen

l Die IP-Adresse des KDC.

l Die DNS-Auflösung, in der Sie dieses Skript ausführen, muss der DNS-Auflösungfür den Hadoop-Host entsprechen, da vipr/_HOST@REALM andernfalls nichtfunktioniert.

Vorgehensweise

1. Melden Sie sich bei Node 1 an und prüfen Sie, ob die Tools bereits installiert unddie Playbooks verfügbar sind.

Das zuvor verwendete Beispiel lautete:

/home/admin/ansible/viprfs-client-<ECS version>-<version>/playbooks

2. Bearbeiten Sie die Datei inventory.txt im Verzeichnis playbooks/samples, um die ECS-Nodes hinzuzufügen.

Die Standardeinträge sind im folgenden Auszug dargestellt.

[data_nodes]192.168.2.[100:200]

Troubleshooting


[kdc]192.168.2.10

3. Starten Sie den Dienstprogrammcontainer auf ECS-Node 1 und machen Sie dieAnsible-Playbooks für den Container verfügbar.

a. Laden Sie das Dienstprogrammcontainer-Image.

Beispiel:

sudo docker load -i /opt/emc/caspian/checker/docker/images/utilities.txz

b. Rufen Sie die Identität des Docker-Images ab.

Beispiel:

admin@provo-lilac:~> sudo docker images

Die Ausgabe enthält die Image-Identität:

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZEutilities 1.5.0.0-403.cb6738e 186bd8577a7a 2 weeks ago 738.5 MB

c. Starten Sie das Dienstprogramm-Image und rufen Sie es auf.

Beispiel:

sudo docker run -v /opt/emc/caspian/fabric/agent/services/object/main/log:/opt/storageos/logs -v /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks:/ansible --name=ecs-tools -i -t --privileged --net=host 186bd8577a7a /bin/bash

In diesem Beispiel wird das Verzeichnis /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks, in dem die Ansible-Playbooks extrahiert wurden, dem Verzeichnis /ansible imDienstprogrammcontainer zugeordnet.

4. Wechseln Sie im Container zum Arbeitsverzeichnis.

Beispiel:

cd /ansible

5. Führen Sie das Ansible-Playbook aus, um keytab-Dateien zu generieren.

ansible-playbook -v -k -i inventory.txt generate-vipr-keytabs.yml

6. Führen Sie das Ansible-Playbook aus, um die Daten-Nodes mit dem ECS-Serviceprinzipal zu konfigurieren.

Troubleshooting

Konfigurieren eines oder mehrerer neuer ECS-Nodes mit dem ECS-Serviceprinzipal 183

Stellen Sie sicher, dass das Verzeichnis /ansible/samples/keytabvorhanden ist und sich die Datei krb5.conf im Arbeitsverzeichnis /ansible/samples befindet.

ansible-playbook -v -k -i inventory.txt setup-vipr-kerberos.yml

Überprüfen Sie, ob jeweils ein korrekter ECS-Serviceprinzipal pro Daten-Nodeerstellt wurde (vom KDC):

# kadmin.local -q "list_principals" | grep viprvipr/[email protected]/[email protected]

Überprüfen Sie, ob die korrekte keytab-Datei generiert und am Speicherort /data/hdfs/krb5.keytab auf allen ECS-Daten-Nodes gespeichert wurde.Sie können den Befehl strings mit der keytab-Datei verwenden, um denvisuell lesbaren Text zu extrahieren und zu überprüfen, ob er den korrektenPrinzipal enthält. Beispiel:

dataservice-10-247-199-69:~ # strings /data/hdfs/krb5.keytabMA.EMC.COMviprnile3-vm42.centera.lab.emc.com

In diesem Fall ist der Prinzipal vipr/nile3-vm42.centera.lab.emc.com.

Workaround für Fehler „Yarn-Verzeichnis ist nichtvorhanden“

Wenn Sie ECS als Standarddateisystem mit einem Kerberized HDP-Clusterkonfigurieren, kann ein Fehler wie /ats/done does not exist angezeigt werden.Zudem startet der Resource Manager nicht.

In diesem Verfahren wird ein Workaround für diese Probleme beschrieben.

Vorgehensweise

1. Prüfen Sie, ob Ihre Hadoop-Nodes ECS-Nodes auflösen können.

a. Installieren Sie das nslookup-Tool in den Hadoop-Knoten.

yum install -y bind-utils

b. Prüfen Sie, ob das Tool ECS-Nodes auflösen kann.

nslookup <address of ECS node>

c. Wenn die Auflösung nicht zum korrekten Hostname führt, fügen Sie ECSDNS zu /etc/resolv.conf auf den Hadoop-Nodes hinzu.

Troubleshooting


Sie können überprüfen, ob die DNS-Einträge vorhanden sind, indem Siefolgenden Befehl ausführen:

cat /etc/resolv.conf

d. Jetzt löst der Hadoop-Node die ECS-Nodes auf.

Führen Sie nslookup erneut aus, um sicherzugehen, dass die Auflösungerfolgt.

nslookup <address of ECS node>

2. Überprüfen Sie die Systemzeit im Hadoop-Node, den ECS-Nodes und KDC.

Verwenden Sie:

# date

Wenn die Zeit der Systeme nicht konsolidiert ist, müssen sie mit demselbenNTP-Server synchronisiert werden.

Das wird in Enable NTP beschrieben.

3. Wenn die oben genannten Schritte nicht funktionieren, können Sie versuchen,den Ordner done oder active unter /ats zu erstellen.

# sudo -u hdfs hdfs dfs -mkdir /ats/done

# sudo -u hdfs hdfs dfs -mkdir /ats/active

Prüfen Sie dann, ob die Verzeichnisse vorhanden sind.

$ hdfs dfs -ls /ats

Found 2 items drwxrwxrwt - yarn hadoop 0 2016-07-12 09:00 /ats/active drwx------ - yarn hadoop 0 2016-07-12 09:00 /ats/done

Troubleshooting

Workaround für Fehler „Yarn-Verzeichnis ist nicht vorhanden“ 185

HTTPS://DOCS.HORTONWORKS.COM/HDPDOCUMENTS/AMBARI-2.4.2.0/BK_AMBARI-INSTALLATION/CONTENT/ENABLE_NTP_ON_THE_CLUSTER_AND_ON_THE_BROWSER_HOST.HTML

Troubleshooting


KAPITEL 10

Anhang: Hilfe für die Kerberos-Konfiguration

l Hilfe für die Kerberos-Konfiguration................................................................. 188

Anhang: Hilfe für die Kerberos-Konfiguration 187

Hilfe für die Kerberos-KonfigurationHilfe für das Konfigurieren von Kerberos in dem Hadoop-Cluster.

Einrichten des Kerberos-KDC (Key Distribution Center)Richten Sie das Kerberos-KDC mithilfe der folgenden Schritte ein.

Vorgehensweise

1. Installieren Sie die krb5-Workstation.

Verwenden Sie den folgenden Befehl:

yum install -y krb5-libs krb5-server krb5-workstation

2. Bearbeiten Sie /etc/krb5.conf und ändern Sie den Bereichsnamen und dieErweiterungen.

3. Bearbeiten Sie /var/kerberos/krb5kdc/kdc.conf und ändern Sie denBereichsnamen so, dass er Ihrem eigenen entspricht.

4. Wenn Ihr KDC eine VM ist, erstellen Sie /dev/random neu (andernfalls würdeIhr nächster Schritt der Erstellung der KDC-Datenbank sehr lange dauern).

a. Entfernen mit:

# rm -rf /dev/random

b. Neu erstellen mit:

# mknod /dev/random c 1 9

5. Erstellen Sie die KDC-Datenbank.

# kdb5_util create -s

Hinweis

Wenn Sie einen Fehler mit den anfänglichen Prinzipalen gemacht haben, z. B.„kdb5_util create -s“ falsch ausgeführt haben, müssen Sie u. U. diese Prinzipaleausdrücklich im Verzeichnis /var/kerberos/krb5kdc/ löschen.

6. Ändern Sie kadm5.acl, um Benutzer anzugeben, die über Administratorrechteverfügen.

*/[email protected] *



7. Ändern Sie /var/kerberos/krb5kdc/kdc.conf und nehmen Sie alleVerschlüsselungstypen außer des-cbc-crc:normal heraus. Ändern Sie auchden Bereichsnamen.

8. Vergewissern Sie sich, dass „iptables“ und „selinux“ auf allen Nodes (KDC-Server ebenso wie Hadoop-Nodes) deaktiviert sind.

9. Starten Sie die KDC-Services und erstellen Sie einen lokalen Admin-Prinzipal.

kadmin.local

# service krb5kdc start

# service kadmin start

# /usr/kerberos/sbin/kadmin.local-q "addprinc root/admin"

# kinit root/admin

10. Kopieren Sie die Datei krb5.conf auf alle Hadoop-Nodes.Jedes Mal, wenn Sie eine Änderung an einer der Konfigurationsdateienvornehmen, müssen Sie die unten stehenden Services neu starten und die Dateikrb5.conf in den relevanten Hadoop-Host und die ECS-Nodes kopieren.

11. Starten Sie die Services neu.

service krb5kdc restart

service kadmin restart

12. Unter dem folgenden Link können Sie ein Kerberos-KDC schrittweise einrichten: http://www.centos.org/docs/4/html/rhel-rg-en-4/s1-kerberos-server.html.

Konfigurieren der AD-Benutzerauthentifizierung für KerberosWenn Sie eine Hadoop-Umgebung mit Kerberos-Sicherheit konfiguriert haben, könnenSie sie so konfigurieren, dass sie in der ECS AD-Domain authentifiziert wird.

Vergewissern Sie sich, dass Sie einen AD-Benutzer für Ihren ADREALM haben. DerBenutzer „detscr“ für den ADREALM CAMBRIDGE.ACME.COM wird im folgendenBeispiel verwendet. Erstellen Sie ein einseitiges Vertrauen zwischen dem KDCREALMund dem ADREALM, wie in dem Beispiel gezeigt. Versuchen Sie nicht, diesen Bereichmit „netdom trust“ zu validieren.

Auf Active DirectorySie müssen ein einseitiges bereichsübergreifendes Vertrauen vom KDC-Bereich zumAD-Bereich einrichten. Führen Sie hierfür die folgenden Befehle bei einerBefehlsaufforderung aus:

ksetup /addkdc KDC-REALM <KDC hostname>netdom trust KDC-REALM /Domain:AD-REALM /add /realm /passwordt:<TrustPassword>ksetup /SetEncTypeAttr KDC-REALM <enc_type>

Beispiel:

ksetup /addkdc LSS.EMC.COM lcigb101.lss.emc.comnetdom trust LSS.ACME.COM /Domain:CAMBRIDGE.ACME.COM /add /realm /


Konfigurieren der AD-Benutzerauthentifizierung für Kerberos 189

https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-kerberos-server.html

passwordt:ChangeMeksetup /SetEncTypeAttr LSS.ACME.COM DES-CBC-CRC

Für dieses Beispiel wurde die Verschlüsselung des-cbc-crc verwendet. Dies ist jedocheine schwache Verschlüsselung, die nur zu Demonstrationszwecken gewählt wurde.Das AD, das KDC und die Clients müssen die von Ihnen gewählte Verschlüsselung sieunterstützen.

Auf Ihrem KDC (als Root)Um ein einseitiges Vertrauen einzurichten, müssen Sie einen „krbtgt“-Serviceprinzipalerstellen. Der Name hierfür lautet krbtgt/KDC-REALM@AD-REALM. Geben Sie ihmdas Passwort ChangeMe oder das Passwort, das Sie weiter oben für das Argument /passwordt angegeben haben.

1. Auf KDC (als Root)

# kadminkadmin: addprinc -e "des-cbc-crc:normal" krbtgt/[email protected]

Hinweis

Bei der Bereitstellung sollten Sie die Verschlüsselungstypen auf einen Typ IhrerWahl begrenzen. Wenn dieser Typ funktioniert, können weitereVerschlüsselungstypen hinzugefügt werden.

2. Fügen Sie Ihrer Eigenschaft core-site.xml hadoop.security.auth_to_local diefolgenden Regeln hinzu:

RULE:[1:$1@$0](^.*@CAMBRIDGE\.ACME\.COM$)s/^(.*)@CAMBRIDGE\.ACME\.COM$/$1/gRULE:[2:$1@$0](^.*@CAMBRIDGE\.ACME\.COM$)s/^(.*)@CAMBRIDGE\.ACME\.COM$/$1/g

3. Überprüfen Sie, ob AD oder LDAP auf dem Kerberos (KDC)-Serverordnungsgemäß eingerichtet ist. Benutzer sollten „kinit“ für einen AD-Benutzerausführen und das lokale HDFS-Verzeichnis auflisten können.

Hinweis

Wenn Sie Ihr Hadoop-Cluster und ECS so konfigurieren, dass die Authentifizierungüber AD erfolgt, erstellen Sie lokale Linux-Benutzerkonten auf allen Hadoop-Nodesfür den AD-Benutzer, als der für Sie „kinit“ ausgeführt wird, und stellen Sie zudemsicher, dass für alle Hadoop-Hosts „kinit“ mit diesem AD-Benutzer ausgeführtwird. Wenn Sie beispielsweise „kinit“ als Benutzer userX@ADREALM ausführen,erstellen Sie userX als lokalen Benutzer auf allen Hadoop-Hosts und führen Sie„kinit“ mit „kinit userX@ADREALM“ auf allen Hosts für diesen Benutzer aus.

In dem folgenden Beispiel werden wir als „kinit [email protected]“authentifiziert, erstellen also einen Benutzer namens „detscr“ und führen als dieserBenutzer „kinit“ auf dem Hadoop-Host aus, wie im Folgenden zu sehen:

[root@lviprb159 ~]# su detscr [detscr@lviprb159 root]$ whoami detscr [detscr@lviprb159 root]$ kinit [email protected]



Password for [email protected]: [detscr@lviprb159 root]$ klist Ticket cache: FILE:/tmp/krb5cc_1010 Default principal: [email protected] Valid starting Expires Service principal 12/22/14 14:28:27 03/02/15 01:28:30 krbtgt/[email protected] renew until 09/17/17 15:28:27 [detscr@lviprb159 root]$ hdfs dfs -ls /Found 4 itemsdrwx---rwx - yarn hadoop 0 2014-12-23 14:11 /app-logsdrwx---rwt - hdfs 0 2014-12-23 13:48 /appsdrwx---r-x - mapred 0 2014-12-23 14:11 /mapreddrwx---r-x - hdfs 0 2014-12-23 14:11 /mr-history


Konfigurieren der AD-Benutzerauthentifizierung für Kerberos 191



KAPITEL 11

Anhang: Hadoop-core-site.xml-Eigenschaftenfür ECS HDFS

l Hadoop-core-site.xml-Eigenschaften für ECS HDFS........................................194

Anhang: Hadoop-core-site.xml-Eigenschaften für ECS HDFS 193

Hadoop-core-site.xml-Eigenschaften für ECS HDFSNutzen Sie bei der Konfiguration der Hadoop-Datei core-site.xml die folgendeTabelle als Referenz für die Eigenschaften und ihre zugehörigen Werte.

Tabelle 32 Hadoop core-site.xml-Eigenschaften

Eigenschaft Beschreibung

Eigenschaften zur Dateisystemimplementierung

fs.viprfs.impl<property><name>fs.viprfs.impl</name><value>com.emc.hadoop.fs.vipr.ViPRFileSystem</value></property>

fs.AbstractFileSystem.viprfs.impl <property>

<name>fs.AbstractFileSystem.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem</value> </property>

Eigenschaften, die den Abschnitt für die Autorität des ECS HDFS-Dateisystem-URI definieren

fs.vipr.installations Eine Namensliste im CSV-Format. Die Namen werden über die Eigenschaft „fs.vipr.installation.[federation].hosts“ weiter definiert, sodass sie Gruppen von ECS-Daten-Nodes eindeutigidentifizieren. Die Namen werden als Komponente des Abschnitts für die Autorität des ECS-HDFS-Dateisystem-URI verwendet. Beispiel:

<property> <name>fs.vipr.installations</name> <value><federation>,<site1>,<testsite></value> </property>

fs.vipr.installation.[federation].hosts

Die IP-Adressen der Daten-Nodes des ECS-Clusters oder die Load Balancer für jeden in derEigenschaft „fs.vipr.installations“ aufgeführten Namen. Geben Sie den Wert in Form einer durchKommata getrennten Liste von IP-Adressen oder FQDNs an. Beispiel:

<property> <name>fs.vipr.installation.<federation>.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value> </property>

fs.vipr.installation.[installation_name].resolution

Gibt an, wie die ECS HDFS-Software auf die ECS-Daten-Nodes zugreift. Folgende Werte könnenverwendet werden:

l dynamic: Verwenden Sie diesen Wert, wenn Sie direkt ohne Load Balancer auf ECS-Daten-Nodes zugreifen.

Anhang: Hadoop-core-site.xml-Eigenschaften für ECS HDFS


Tabelle 32 Hadoop core-site.xml-Eigenschaften (Fortsetzung)


l fixed: Verwenden Sie diesen Wert, wenn Sie über einen Load Balancer auf ECS-Daten-Nodeszugreifen.

<property> <name>fs.vipr.installation.<federation>.resolution</name> <value>dynamic</value> </property>

fs.vipr.installation.[installation_name].resolution.dynamic.time_to_live_ms

Wenn die Eigenschaft fs.vipr.installation.[installation_name].resolution auf

dynamic festgelegt wird, gibt diese Eigenschaft an, wie oft ECS für die Liste der aktiven Nodes

abgefragt werden soll. Werte werden in Millisekunden angegeben. Die Standardeinstellung ist 10Minuten.

<property> <name>fs.vipr.installation.<federation>.resolution.dynamic.time_to_live_ms</name> <value>600000</value> </property>

ECS-Dateisystem-URI

fs.defaultFS Eine Hadoop-Standardeigenschaft, die den URI für das Standarddateisystem angibt. Die Einstellungdieser Eigenschaft auf das ECS HDFS-Dateisystem ist optional. Wenn Sie die Eigenschaft nicht aufdas ECS HDFS-Dateisystem festlegen, müssen Sie für jeden Dateisystemvorgang den vollständigenURI angeben. Der URI des ECS HDFS-Dateisystems hat das folgende Format:

viprfs://[bucket_name].[namespace].[federation]

l bucket_name: Der Name des HDFS-fähigen Buckets, der die Daten enthält, die Sie zurAusführung des Hadoop-Jobs verwenden möchten.

l namespace: namespace: Der dem HDFS-fähigen Bucket zugeordnete Tenant-Namespace.

l federation: Der der Gruppe der ECS-Daten-Nodes zugeordnete Name, mit dem Hadoop aufECS-Daten zugreifen kann. Der Wert dieser Eigenschaft muss mit einem der in der Eigenschaftfs.vipr.installations angegebenen Werte übereinstimmen.

Beispiel:

<property> <name>fs.defaultFS</name> <value>viprfs://testbucket.s3.federation1</value> </property>

Eigenschaft umask


Hadoop-core-site.xml-Eigenschaften für ECS HDFS 195



fs.permissions.umask-mode

Diese Hadoop-Standardeigenschaft gibt an, wie ECS HDFS Berechtigungen für Objekte berechnensoll. Berechtigungen werden berechnet, indem umask auf die Eingabeberechtigungen angewendetwird. Der empfohlene Wert für einfache und Kerberos-Konfigurationen lautet: 022. Beispiel:

<property><name>fs.permissions.umask-mode</name><value>022</value></property>

Identitätsübersetzungseigenschaften

fs.viprfs.auth.identity_translation

Diese Eigenschaft gibt an, wie der ECS HDFS-Client festlegt, welchem Kerberos-Bereich einbestimmter Benutzer angehört, falls nicht angegeben. ECS-Daten-Nodes speichern Dateieigentümerals username@REALM, während Hadoop Dateieigentümer nur als Benutzername speichert.

Mögliche Werte:

l NONE: Standard. Benutzer werden keinem Bereich zugeordnet. Verwenden Sie diese Einstellung

mit einem Hadoop-Cluster, das einfache Sicherheit verwendet. Mit dieser Einstellung führt ECSHDFS keine Übersetzung des Bereichs durch.

l CURRENT_USER_REALM: Gültig, falls Kerberos vorhanden ist. Der Bereich des Benutzers wird

automatisch erkannt. Es handelt sich um den Bereich des derzeit angemeldeten Benutzers. ImBeispiel unten ist der Bereich EMC.COM, da sich Sally im Bereich EMC.COM befindet. Der

Dateieigentümer wird geändert in [email protected].

# kinit [email protected]# hdfs dfs -chown john /path/to/file

Bereiche, die in der Befehlszeile bereitgestellt werden, haben Vorrang vor den festgelegtenEigenschaften.

<property> <name>fs.viprfs.auth.identity_translation </name> <value>CURRENT_USER_REALM</value> </property>

Hinweis

FIXED_REALM ist jetzt veraltet.

fs.viprfs.auth.realm Der Bereich, der Benutzern zugewiesen wird, wenn die Eigenschaftfs.viprfs.auth.identity_translation auf FIXED_REALM festgelegt ist.

Dies ist jetzt veraltet.

fs.viprfs.auth.anonymous_translation

Mit dieser Eigenschaft wird bestimmt, wie Benutzer und Gruppen neu erstellten Dateien zugewiesenwerden.





Hinweis

Mit dieser Eigenschaft wurde zuvor festgelegt, wie Dateien ohne Eigentümer zu handhaben sind.Eigentümer dieser Dateien war anonymous. Anonyme Eigentümer von Dateien und Verzeichnissen

gibt es nicht mehr.

Die folgenden Werte können verwendet werden:

l LOCAL_USER: Verwenden Sie diese Einstellung mit einem Hadoop-Cluster, das einfache

Sicherheit verwendet. Weist den Unix-Benutzer und die -Gruppe des Hadoop-Clusters neuerstellten Dateien und Verzeichnissen zu.

l CURRENT_USER: Verwenden Sie diese Einstellung für Hadoop-Cluster, die Kerberos verwenden.

Weist den Kerberos-Prinzipal ([email protected]) als Eigentümer der Datei oder des

Verzeichnisses zu und verwendet die Gruppe, die als Standard für den Bucket zugewiesenwurde.

l NONE: (Veraltet) Gab zuvor an, dass keine Objekte mit anonymem Eigentümer dem aktuellen

Benutzer zugewiesen werden sollen.

<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>CURRENT_USER</value> </property>

Eigenschaften für Kerberos-Bereich und Serviceprinzipal

viprfs.security.principal Diese Eigenschaft gibt den ECS-Serviceprinzipal an. Sie benachrichtigt das KDC über den ECS-Service. Der Wert ist für Ihre Konfiguration spezifisch.Der Prinzipalname kann _HOST enthalten (wird während der Ausführung automatisch durch den

tatsächlichen Daten-Node-FQDN ersetzt).

Beispiel:

<property> <name>viprfs.security.principal</name> <value>vipr/[email protected]</value></property>

Beispiel für core-site.xml für einfachen AuthentifizierungsmodusDie folgende Datei core-site.xml ist ein Beispiel für ECS HDFS-Eigenschaften imeinfachen Authentifizierungsmodus.

Beispiel 1 core-site.xml

<property> <name>fs.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRFileSystem</value>


Beispiel für core-site.xml für einfachen Authentifizierungsmodus 197

Beispiel 1 core-site.xml (Fortsetzung)

</property>

<property> <name>fs.AbstractFileSystem.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem</value></property>

<property> <name>fs.vipr.installations</name> <value>federation1</value></property>

<property> <name>fs.vipr.installation.federation1.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value></property>

<property> <name>fs.vipr.installation.federation1.resolution</name> <value>dynamic</value></property>

<property> <name>fs.vipr.installation.federation1.resolution.dynamic.time_to_live_ms</name> <value>900000</value></property>

<property> <name>fs.defaultFS</name> <value>viprfs://mybucket.mynamespace.federation1/</value></property>

<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>LOCAL_USER</value></property>

<property> <name>fs.viprfs.auth.identity_translation</name> <value>NONE</value></property>



KAPITEL 12

Anhang: Beispiel für sichere Bucket-Metadaten

l Sichere Bucket-Metadaten.............................................................................. 200

Anhang: Beispiel für sichere Bucket-Metadaten 199

Sichere Bucket-MetadatenDas folgende Beispiel zeigt eine Liste der sicheren Name/Wert-Kombinationen fürBucket-Metadaten.

{ "head_type": "hdfs", "metadata": [ { "name": "internal.kerberos.user.ambari-qa.name", "value": "ambari-qa@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.ambari-qa.shortname", "value": "ambari-qa" }, { "name": "internal.kerberos.user.ambari-qa.groups", "value": "hadoop,users" }, { "name": "internal.kerberos.user.cmaurer.name", "value": "cmaurer@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.cmaurer.shortname", "value": "cmaurer" }, { "name": "internal.kerberos.user.cmaurer.groups", "value": "cmaurer,adm,cdrom,sudo,dip,plugdev,users,lpadmin,sambashare" }, { "name": "internal.kerberos.user.dn.name", "value": "dn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.dn.shortname", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.dn.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.hdfs.name", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.hdfs.shortname", "value": "hdfs" }, { "name": "internal.kerberos.user.hdfs.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.hive.name", "value": "hive@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.hive.shortname", "value": "hive"



}, { "name": "internal.kerberos.user.hive.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.jhs.name", "value": "jhs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.jhs.shortname", "value": "mapred" }, { "name": "internal.kerberos.user.jhs.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.nm.name", "value": "nm@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nm.shortname", "value": "yarn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nm.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.nn.name", "value": "nn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nn.shortname", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nn.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.rm.name", "value": "rm@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.rm.shortname", "value": "yarn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.rm.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.spark.name", "value": "spark@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.spark.shortname", "value": "spark" }, { "name": "internal.kerberos.user.spark.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.yarn.name", "value": "yarn@EXAMPLE_HDFS.EMC.COM"


Sichere Bucket-Metadaten 201

}, { "name": "internal.kerberos.user.yarn.shortname", "value": "yarn" }, { "name": "internal.kerberos.user.yarn.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.zookeeper.name", "value": "zookeeper@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.zookeeper.shortname", "value": "ams" }, { "name": "internal.kerberos.user.zookeeper.groups", "value": "hadoop" }, { "name": "hadoop.proxyuser.hcat.groups", "value": "*" }, { "name": "hadoop.proxyuser.hcat.hosts", "value": "*" }, { "name": "hadoop.proxyuser.yarn.users", "value": "*" }, { "name": "hadoop.proxyuser.yarn.hosts", "value": "*" }, { "name": "hadoop.proxyuser.hive.hosts", "value": "10.247.179.42" }, { "name": "hadoop.proxyuser.hive.users", "value": "*" }, { "name": "hadoop.proxyuser.hcat.groups", "value": "*" }, { "name": "hadoop.proxyuser.hcat.hosts", "value": "*" }, { "name": "dfs.permissions.supergroup", "value": "hdfs" } ]}

