Migrieren von Datenbankressourcen zu globaler Azure

Dieser Artikel enthält Informationen, mit denen Sie Azure-Datenbankressourcen aus Azure Deutschland in globale Azure migrieren können.

SQL-Datenbank

Um kleinere Azure SQL-Datenbankworkloads zu migrieren, ohne die migrierte Datenbank online zu halten, verwenden Sie die Exportfunktion, um eine BACPAC-Datei zu erstellen. Eine BACPAC-Datei ist eine komprimierte (gepackte) Datei, die Metadaten und Daten aus der SQL Server-Datenbank enthält. Nachdem Sie die BACPAC-Datei erstellt haben, können Sie die Datei in die Zielumgebung kopieren (z. B. mithilfe von AzCopy) und die Importfunktion verwenden, um die Datenbank neu zu erstellen. Beachten Sie die folgenden Aspekte:

• Damit ein Export transaktionskonsensiert ist, stellen Sie sicher, dass eine der folgenden Bedingungen erfüllt ist:
  • Während des Exports tritt keine Schreibaktivität auf.
  • Sie exportieren aus einer transaktional konsistenten Kopie Ihrer SQL-Datenbank.
• Um in Azure Blob Storage zu exportieren, ist die BACPAC-Dateigröße auf 200 GB begrenzt. Exportieren Sie für eine größere BACPAC-Datei in den lokalen Speicher.
• Wenn der Exportvorgang aus der SQL-Datenbank länger als 20 Stunden dauert, wird der Vorgang möglicherweise abgebrochen. In den folgenden Artikeln finden Sie Tipps zur Leistungssteigerung.

Weitere Informationen:

• Erfahren Sie, wie Sie eine Datenbank in eine BACPAC-Datei exportieren.
• Erfahren Sie, wie Sie eine BACPAC-Datei in eine Datenbank importieren.
• Lesen Sie die Dokumentation zur Azure SQL-Datenbank.

Migrieren der SQL-Datenbank mit aktiver Georeplikation

Bei Datenbanken, die für BACPAC-Dateien zu groß sind oder von einer Cloud zu einer anderen migriert werden sollen und mit minimaler Ausfallzeit online bleiben, können Sie die aktive Georeplikation von Azure Deutschland in globale Azure konfigurieren.

Ausführliche Informationen zu aktiven Georeplikationskosten finden Sie im Abschnitt " Aktive Georeplikation in Azure SQL-Datenbankpreisen".For details about active geo-replication costs, see the sectiond active geo-replication in azure SQL Database pricing.

Für die Migration von Datenbanken mit aktiver Georeplikation ist ein logischer Azure SQL-Server in globaler Azure erforderlich. Sie können den Server mithilfe des Portals, Azure PowerShell, Azure CLI usw. erstellen, aber die Konfiguration der aktiven Georeplikation für die Migration von Azure Deutschland zu globaler Azure wird nur mithilfe von Transact-SQL (T-SQL) unterstützt.

Mit der ALTER DATABASE-Anweisung können Sie einen Zielserver in der globalen Azure-Cloud mithilfe seines vollqualifizierten DNS-Servernamens auf der Zielseite angeben.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]

• sourcedb den Datenbanknamen in einem Azure SQL-Server in Azure Deutschland darstellt.
• public-server.database.windows.net stellt den Azure SQL Server-Namen dar, der in globalen Azure vorhanden ist, in dem die Datenbank migriert werden soll. Der Namespace "database.windows.net" ist erforderlich, ersetzen Sie den öffentlichen Server durch den Namen Ihres logischen SQL-Servers in globalen Azure. Der Server in globaler Azure muss einen anderen Namen als der primäre Server in Azure Deutschland haben.

Der Befehl wird auf der Masterdatenbank auf dem Azure Deutschland-Server ausgeführt, auf dem die lokale Datenbank migriert werden soll.

• Die T-SQL-Startkopie-API authentifiziert den angemeldeten Benutzer auf dem öffentlichen Cloudserver, indem er einen Benutzer mit demselben SQL-Anmelde-/Benutzernamen in der Masterdatenbank dieses Servers findet. Dieser Ansatz ist cloudagnostisch; Daher wird die T-SQL-API verwendet, um cloudübergreifende Kopien zu starten. Berechtigungen und weitere Informationen zu diesem Thema finden Sie unter Erstellen und Verwenden der aktiven Georeplikation und ALTER DATABASE (Transact-SQL).

• Mit Ausnahme der anfänglichen T-SQL-Befehlserweiterung, die einen logischen Azure SQL-Server in global azure angibt, ist der rest des aktiven Georeplikationsprozesses identisch mit der vorhandenen Ausführung in der lokalen Cloud. Ausführliche Schritte zum Erstellen einer aktiven Georeplikation finden Sie unter Erstellen und Verwenden der aktiven Georeplikation. Dabei gibt es eine Ausnahme: Die sekundäre Datenbank wird im sekundären logischen Server erstellt, der im globalen Azure eingerichtet ist.

• Sobald die sekundäre Datenbank in globaler Azure vorhanden ist (als Onlinekopie der Azure Deutschland-Datenbank), kann der Kunde ein Datenbankfailover von Azure Deutschland zu global Azure für diese Datenbank mithilfe des BEFEHLS ALTER DATABASE T-SQL initiieren (siehe tabelle unten).

• Nach dem Failover, wenn die sekundäre Datenbank zu einer primären Datenbank in globalem Azure wird, können Sie die aktive Georeplikation beenden und die sekundäre Datenbank jederzeit auf der Seite Azure Deutschland entfernen (siehe Tabelle unten und die im Diagramm dargestellten Schritte).

• Nach dem Failover wird die sekundäre Datenbank in Azure Deutschland bis zum Löschen weiterhin kostenaufwendig.

• Die Verwendung des Befehls ALTER DATABASE ist die einzige Möglichkeit, die aktive Georeplikation einzurichten, um eine Azure Deutschland-Datenbank zu globalen Azure zu migrieren.

• Kein Azure-Portal, Azure Resource Manager, PowerShell oder CLI ist verfügbar, um die aktive Georeplikation für diese Migration zu konfigurieren.

So migrieren Sie eine Datenbank aus Azure Deutschland zu globaler Azure:

1. Wählen Sie die Benutzerdatenbank in Azure Deutschland aus, z. B. azuregermanydb

2. Erstellen Sie einen logischen Server in globaler Azure (der öffentlichen Cloud), z. B. globalazureserver. Der vollqualifizierte Domänenname (Fully Qualified Domain Name, FQDN) ist globalazureserver.database.windows.net.

3. Starten Sie die aktive Georeplikation von Azure Deutschland in globale Azure, indem Sie diesen T-SQL-Befehl auf dem Server in Azure Deutschland ausführen. Beachten Sie, dass der vollqualifizierte DNS-Name für den öffentlichen Server globalazureserver.database.windows.netverwendet wird. Dies ist darauf hinzuweisen, dass sich der Zielserver in globalen Azure und nicht in Azure Deutschland befindet.

   ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];
   

4. Wenn die Replikation bereit ist, die Lese-/Schreib-Workload auf den globalen Azure-Server zu verschieben, initiieren Sie ein geplantes Failover auf globaler Azure, indem Sie diesen T-SQL-Befehl auf dem globalen Azure-Server ausführen.

   ALTER DATABASE [azuregermanydb] FAILOVER;
   

5. Die aktive Georeplikationsverknüpfung kann vor oder nach dem Failovervorgang beendet werden. Führen Sie den folgenden T-SQL-Befehl nach dem geplanten Failover aus, um die Georeplikationsverknüpfung zu entfernen, wobei die Datenbank in Microsoft Azure die Lese-/Schreibkopie ist. Sie sollte auf dem logischen Server der aktuellen geo primary-Datenbank (d. h. auf dem globalen Azure-Server) ausgeführt werden. Dadurch wird der Migrationsprozess abgeschlossen.

   ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];
   

   Der folgende T-SQL-Befehl, der vor dem geplanten Failover ausgeführt wird, beendet auch den Migrationsprozess, aber in dieser Situation bleibt die Datenbank in Azure Deutschland die Lese-/Schreibzugriffskopie. Dieser T-SQL-Befehl sollte auch auf dem logischen Server der aktuellen geo-primären Datenbank ausgeführt werden, in diesem Fall auf dem Azure Deutschland-Server.

   ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];
   

Diese Schritte zum Migrieren von Azure SQL-Datenbanken aus Azure Deutschland zu globaler Azure können auch mithilfe der aktiven Georeplikation befolgt werden.

Weitere Informationen finden Sie in den folgenden Tabellen: T-SQL-Befehle zum Verwalten von Failover. Die folgenden Befehle werden für die cloudübergreifende aktive Georeplikation zwischen Azure Deutschland und globaler Azure unterstützt:

Aktive Georeplikationsüberwachungssystemansichten

Migrieren von langfristigen Aufbewahrungssicherungen für SQL-Datenbank

Durch die Migration einer Datenbank mit Georeplikation oder BACPAC-Datei werden keine langfristigen Aufbewahrungssicherungen kopiert, über die die Datenbank möglicherweise in Azure Deutschland verfügt. Um vorhandene langfristige Aufbewahrungssicherungen in die globale Azure-Zielregion zu migrieren, können Sie den Vorgang KOPIEREN für Langzeitaufbewahrungssicherungen verwenden.

Voraussetzungen

1. Die Zieldatenbank, in die Sie die LTR-Sicherungen kopieren, muss im globalen Azure vorhanden sein, bevor Sie mit dem Kopieren der Sicherungen beginnen. Es wird empfohlen, zuerst die Quelldatenbank mithilfe der aktiven Georeplikation zu migrieren und dann die LTR-Sicherungskopie zu initiieren. Dadurch wird sichergestellt, dass die Datenbanksicherungen in die richtige Zieldatenbank kopiert werden. Dieser Schritt ist nicht erforderlich, wenn Sie LTR-Sicherungen einer gelöschten Datenbank kopieren. Beim Kopieren der LTR-Sicherungen einer entfernten Datenbank wird in der Zielregion eine Dummy-DatabaseID erstellt.
2. Installieren Sie dieses PowerShell Az-Modul
3. Bevor Sie beginnen, stellen Sie sicher, dass erforderliche Azure RBAC-Rollen entweder im Abonnement - oder Ressourcengruppenbereich gewährt werden. Hinweis: Um auf LTR-Sicherungen zuzugreifen, die zu einem verworfenen Server gehören, muss die Berechtigung im Abonnementbereich dieses Servers erteilt werden. .

Einschränkungen

• Failover-Gruppen werden nicht unterstützt. Dies bedeutet, dass Kunden, die Azure Deutschland-Datenbanken migrieren, verbindungszeichenfolgen selbst während des Failovers verwalten müssen.
• Keine Unterstützung für Azure-Portal, Azure Resource Manager-APIs, PowerShell oder CLI. Dies bedeutet, dass jede Azure Deutschland-Migration die aktive Einrichtung der Georeplikation und das Failover über T-SQL verwalten muss.
• Kunden können nicht mehrere Geo-Secondaries in globalen Azure für Datenbanken in Azure Deutschland erstellen.
• Die Erstellung einer geosekundären Instanz muss von der Region Azure Germany aus initiiert werden.
• Kunden können Datenbanken aus Azure Deutschland nur zu globalen Azure migrieren. Derzeit wird keine andere cloudübergreifende Migration unterstützt.
• Azure AD-Benutzer in Azure Deutschland-Benutzerdatenbanken werden migriert, sind aber nicht im neuen Azure AD-Mandanten verfügbar, in dem sich die migrierte Datenbank befindet. Um diese Benutzer zu aktivieren, müssen sie manuell gelöscht und neu erstellt werden, indem sie die aktuellen Azure AD-Benutzer verwenden, die im neuen Azure AD-Mandanten verfügbar sind, in dem sich die neu migrierte Datenbank befindet.

Kopieren langfristiger Aufbewahrungssicherungen mithilfe von PowerShell

Es wurde ein neuer PowerShell-Befehl "Copy-AzSqlDatabaseLongTermRetentionBackup " eingeführt, mit dem die langfristigen Aufbewahrungssicherungen aus Azure Deutschland in globale Azure-Regionen kopiert werden können.

1. Kopieren der LTR-Sicherung mithilfe des Sicherungsnamens Das folgende Beispiel zeigt, wie Sie mithilfe des Sicherungsnamens eine LTR-Sicherung aus Azure Deutschland in die globale Azure-Region kopieren können.

# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN 

2. Kopieren der LTR-Sicherung mithilfe der Sicherungsressourcen-ID Das folgende Beispiel zeigt, wie Sie LTR-Sicherung aus Azure Deutschland mithilfe einer Sicherungsressourcen-ID in eine globale Azure-Region kopieren können. Dieses Beispiel kann auch verwendet werden, um Sicherungen einer gelöschten Datenbank zu kopieren.

$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Einschränkungen

• Point-in-Time Restore (PITR)-Sicherungen werden nur für die primäre Datenbank übernommen, das ist beabsichtigt. Bei der Migration von Datenbanken aus Azure Deutschland mit Geo-DR werden PITR-Sicherungen nach dem Failover mit dem neuen Primären beginnen. Die vorhandenen PITR-Sicherungen (auf dem vorherigen primären Server in Azure Deutschland) werden jedoch nicht migriert. Wenn Sie PITR-Sicherungen benötigen, um Point-in-Time-Wiederherstellungsszenarien zu unterstützen, müssen Sie die Datenbank aus PITR-Sicherungen in Azure Deutschland wiederherstellen und dann die wiederhergestellte Datenbank in globale Azure migrieren.
• Langfristige Aufbewahrungsrichtlinien werden nicht mit der Datenbank migriert. Wenn Sie über eine langfristige Aufbewahrungsrichtlinie (LTR) in Ihrer Datenbank in Azure Deutschland verfügen, müssen Sie die LTR-Richtlinie nach der Migration manuell kopieren und neu erstellen.

Anfordern des Zugriffs

Um eine Datenbank aus Azure Deutschland mithilfe der Georeplikation zu globalen Azure zu migrieren, muss Ihr Abonnement in Azure Deutschland aktiviert sein, um die cloudübergreifende Migration erfolgreich zu konfigurieren.

Um Ihr Azure Deutschland-Abonnement zu aktivieren, müssen Sie den folgenden Link verwenden, um eine Migrationssupportanfrage zu erstellen:

1. Navigieren Sie zu der folgenden Unterstützungsanforderung für Migration.

2. Geben Sie auf der Registerkarte "Grundlagen" Geo-DR Migration als Zusammenfassung ein, und wählen Sie dann "Weiter" aus: Lösungen

   

3. Überprüfen Sie die empfohlenen Schritte, und wählen Sie dann "Weiter: Details" aus.

   

4. Geben Sie auf der Detailseite Folgendes an:

   1. Geben Sie im Feld "Beschreibung" die globale Azure-Abonnement-ID ein, zu der migriert werden soll. Wenn Sie Datenbanken zu mehreren Abonnements migrieren möchten, fügen Sie eine Liste der globalen Azure-IDs hinzu, zu der Sie Datenbanken migrieren möchten.
   2. Geben Sie Kontaktinformationen an: Name, Firmenname, E-Mail oder Telefonnummer.
   3. Füllen Sie das Formular aus, und wählen Sie dann "Weiter" aus: Überprüfen + Erstellen.

   

5. Überprüfen Sie die Supportanfrage, und wählen Sie dann "Erstellen" aus.

Sobald die Anforderung verarbeitet wurde, werden Sie kontaktiert.

Azure Cosmos DB (ein Microsoft-Datenbankdienst)

Sie können das Azure Cosmos DB-Datenmigrationstool verwenden, um Daten zu Azure Cosmos DB zu migrieren. Das Azure Cosmos DB Data Migration Tool ist eine Open-Source-Lösung, die Daten aus verschiedenen Quellen in Azure Cosmos DB importiert, darunter: JSON-Dateien, MongoDB, SQL Server, CSV-Dateien, Azure Table Storage, AmazonDb, HBase und Azure Cosmos-Container.

Das Azure Cosmos DB Data Migration Tool ist als grafisches Schnittstellentool oder als Befehlszeilentool verfügbar. Der Quellcode ist im GitHub-Repository des Azure Cosmos DB-Datenmigrationstools verfügbar. Eine kompilierte Version des Tools ist im Microsoft Download Center verfügbar.

Um Azure Cosmos DB-Ressourcen zu migrieren, empfehlen wir, die folgenden Schritte auszuführen:

1. Überprüfen Sie die Betriebszeit-Anforderungen der Anwendung und die Kontokonfigurationen, um den besten Maßnahmenplan zu ermitteln.
2. Klonen Sie die Kontokonfigurationen von Azure Deutschland in die neue Region, indem Sie das Datenmigrationstool ausführen.
3. Wenn die Verwendung eines Wartungsfensters möglich ist, kopieren Sie Daten aus der Quelle in das Ziel, indem Sie das Datenmigrationstool ausführen.
4. Wenn die Verwendung eines Wartungsfensters keine Option ist, kopieren Sie Daten aus der Quelle in das Ziel, indem Sie das Tool ausführen, und führen Sie dann die folgenden Schritte aus:
   1. Verwenden Sie einen konfigurationsgesteuerten Ansatz, um Änderungen an den Lese-/Schreiboperationen in einer Anwendung vorzunehmen.
   2. Führen Sie eine erstmalige Synchronisierung aus.
   3. Richten Sie eine inkrementelle Synchronisierung ein und holen Sie den Änderungsfeed ein.
   4. Richten Sie die Verweise auf das neue Konto und validieren Sie die Anwendung.
   5. Beenden Sie Schreibvorgänge in das alte Konto, überprüfen Sie, ob der Änderungsfeed erfasst wird, und leiten Sie dann die Schreibvorgänge auf das neue Konto um.
   6. Beenden Sie das Tool, und löschen Sie das alte Konto.
5. Führen Sie das Tool aus, um zu überprüfen, ob Daten in alten und neuen Konten konsistent sind.

Weitere Informationen:

• Informationen zum Verwenden des Datenmigrationstools finden Sie im Lernprogramm: Verwenden des Datenmigrationstools zum Migrieren Ihrer Daten zu Azure Cosmos DB.
• Informationen zu Cosmos DB finden Sie unter "Willkommen bei Azure Cosmos DB".

Azure Cache für Redis

Sie haben einige Optionen, wenn Sie einen Azure-Cache für Redis-Instanz von Azure Deutschland zu globaler Azure migrieren möchten. Die von Ihnen ausgewählte Option hängt von Ihren Anforderungen ab.

Option 1: Annehmen von Datenverlust, Erstellen einer neuen Instanz

Dieser Ansatz ist am sinnvollsten, wenn beide der folgenden Bedingungen zutreffen:

• Sie verwenden Azure Cache für Redis als vorübergehenden Datencache.
• Ihre Anwendung füllt die Cachedaten automatisch in der neuen Region auf.

So migrieren Sie mit Datenverlust und erstellen eine neue Instanz:

1. Erstellen Sie einen neuen Azure-Cache für Redis-Instanz in der neuen Zielregion.
2. Aktualisieren Sie Ihre Anwendung so, dass sie die neue Instanz in der neuen Region verwendet.
3. Löschen Sie den alten Azure-Cache für Redis-Instanz in der Quellregion.

Option 2: Kopieren von Daten aus der Quellinstanz in die Zielinstanz

Ein Mitglied des Teams "Azure Cache for Redis" schrieb ein Open-Source-Tool, mit dem Daten aus einem Azure-Cache für Redis-Instanzen in eine andere kopiert werden, ohne dass Import- oder Exportfunktionen erforderlich sind. Informationen zum Tool finden Sie in Schritt 4 in den folgenden Schritten.

So kopieren Sie Daten aus der Quellinstanz in die Zielinstanz:

1. Erstellen Sie einen virtuellen Computer in der Quellregion. Wenn Ihr Dataset im Azure-Cache für Redis groß ist, stellen Sie sicher, dass Sie eine relativ leistungsfähige VM-Größe auswählen, um die Kopierzeit zu minimieren.
2. Erstellen Sie einen neuen Azure-Cache für Redis-Instanz in der Zielregion.
3. Löschen von Daten aus der Zielinstanz . (Stellen Sie sicher, dass Sie nicht aus der Quellinstanz flushen. Das Flushen ist erforderlich, weil das Kopiertool vorhandene Schlüssel am Zielspeicherort nicht überschreibt.)
4. Verwenden Sie das folgende Tool, um Daten aus der Azure-Quellcache für Redis-Instanz automatisch in die Azure Cache für Redis-Zielinstanz zu kopieren: Toolquelle und Tooldownload.

Option 3: Aus der Quellinstanz exportieren, in die Zielinstanz importieren

Dieser Ansatz nutzt Features, die nur auf der Premium-Stufe verfügbar sind.

So exportieren Sie aus der Quellinstanz und importieren Sie in die Zielinstanz:

1. Erstellen Sie einen neuen Azure-Cache der Premium-Ebene für Redis-Instanz in der Zielregion. Verwenden Sie dieselbe Größe wie der Azure-Quellcache für Redis-Instanz.

2. Exportieren Sie Daten aus dem Quellcache , oder verwenden Sie das PowerShell-CmdletExport-AzRedisCache.

   Hinweis

   Das Export-Azure Storage-Konto muss sich in derselben Region wie die Cacheinstanz befinden.

3. Kopieren Sie die exportierten Blobs in ein Speicherkonto in der Zielregion (z. B. mithilfe von AzCopy).

4. Importieren Sie Daten in den Zielcache , oder verwenden Sie das powerShell-CmdletImport-AzRedisCAche.

5. Konfigurieren Sie Ihre Anwendung neu, um den Azure-Zielcache für Redis-Instanz zu verwenden.

Option 4: Schreiben von Daten in zwei Azure Cache für Redis-Instanzen, lesen aus einer Instanz

Für diesen Ansatz müssen Sie Ihre Anwendung ändern. Die Anwendung muss Daten in mehr als eine Cacheinstanz schreiben, während sie aus einer der Cacheinstanzen liest. Dieser Ansatz ist sinnvoll, wenn die in Azure Cache für Redis gespeicherten Daten die folgenden Kriterien erfüllen:

• Die Daten werden regelmäßig aktualisiert.
• Alle Daten werden in den Azure-Zielcache für Redis-Instanz geschrieben.
• Sie haben genügend Zeit, damit alle Daten aktualisiert werden können.

Weitere Informationen:

• Sehen Sie sich die Übersicht über den Azure-Cache für Redis an.

PostgreSQL und MySQL

Weitere Informationen finden Sie in den Artikeln im Abschnitt "Sichern und Migrieren von Daten" von PostgreSQL und MySQL.

Nächste Schritte

Erfahren Sie mehr über Tools, Techniken und Empfehlungen für die Migration von Ressourcen in den folgenden Dienstkategorien:

• Berechnen
• Vernetzung
• Lagerung
• Web
• Analytik
• Iot
• Integration
• Identität
• Sicherheit
• Verwaltungstools
• Medien