Exadata@Azure mit OpenTofu

In einem meiner Projekte des Jahres 2025 erstellten wir die Infrastruktur einer größeren Anwendungsumgebung in Azure mit OpenTofu. Das allein ist schon spannend genug, denn bis vor kurzem betreute ich hauptsächlich Projekte in der Oracle Cloud Infrastructure (OCI). Richtig interessant wurde es aber mit dem Oracle Database@Azure-Teil, denn hier treffen gleich zwei Cloud-Welten in einer noch nicht ganz so verbreiteten Art aufeinander.

Gleich zu Beginn gab es ein paar Stolpersteine. Einer davon: die Bereitstellung eines Exadata-Clusters in einem Azure Virtual Network mit IPv4/IPv6 Dual Stack. Laut Dokumentation wird das zunächst nicht empfohlen. Da aber nur ein einziges virtuelles Netzwerk vorgesehen war, haben wir es trotzdem ausprobiert.

Obwohl für das delegierte Subnetz, das von OCI genutzt wird, kein IPv6-Präfix konfiguriert war, lief ich in einen Bug beim Erstellen der Network Security Group in der OCI. Der IPv6-Präfix des VNets wurde schlicht nicht ignoriert und im Ergebnis schlug der Deployment-Prozess fehlt, da die OCI-Seite ausschließlich IPv4 unterstützt und keine IPv6-CIDRs in einer NSG erlaubt sind.

Da das Projekt auch für Oracle nicht ganz unwichtig war, wurde erfreulich schnell Abhilfe geschaffen und nach etwa zwei Wochen war das Problem behoben.

Der erste Cluster wurde klassisch per Click Ops über das Azure-Portal erstellt. Danach wollten wir das Ganze natürlich sauber im Code abbilden, um alles reproduzierbar und dokumentiert zentral ablegen zu können. Also schreiben wir die entsprechenden Code-Zeilen laut azurerm-Dokumentation für Oracle Cloud VM Cluster mit den aus unserer Sicht relevanten Parametern. Heraus kam folgende Konfiguration, bei der wir uns initial auf die Pflichtfelder und ein paar bewusste Abweichungen von den Defaults beschränkt haben:

resource "azurerm_oracle_cloud_vm_cluster" "exacl-fz3" {
 name                            = "exacl-fz3"
 display_name                    = "exacl-fz3"
 location                        = azurerm_resource_group.rg-exadata.location
 resource_group_name             = azurerm_resource_group.rg-exadata.name
 cloud_exadata_infrastructure_id = azurerm_oracle_exadata_infrastructure.exa-platform-zone3.id
 db_servers                      = [data.azurerm_oracle_db_servers.exacl-zone3.db_servers[0].ocid, data.azurerm_oracle_db_servers.exacl-zone3.db_servers[1].ocid]
 hostname                        = "exa-fz3"
 virtual_network_id              = azurerm_virtual_network.vnet-exadata.id
 subnet_id                       = azurerm_subnet.subnet-oracle-exadata.id
 cpu_core_count                  = 4
 license_model                   = "BringYourOwnLicense"
 gi_version                      = "23.0.0.0"
 ssh_public_keys                 = ["ssh-rsa xxx"]
 data_storage_percentage         = "80"
 time_zone                       = "Europe/Berlin"
 db_node_storage_size_in_gbs     = 1000
 sparse_diskgroup_enabled        = false
 data_storage_size_in_tbs        = 192
 local_backup_enabled            = false
}

Bei der Ausführung des OpenTofu-Codes startete die Azure-API brav den dortigen Erstellungsprozess und versuchte anschließend, die Workload an OCI zu übergeben. Nach etwa einer Minute war dann aber Schluss mit folgendem Fehler:

400: DbServerList is not empty, DataStorageOption params can't be null.

Die Meldung kam ziemlich sicher von der OCI-Seite, denn in Azure wird der Job korrekt angelegt, bricht dort aber später ab. Der Hinweis auf “DataStorageOption params can't be null” klingt zunächst nach einem fehlenden Storage-Parameter, was aber nicht wirklich Sinn ergibt, da im Code alle Storage-relevanten Werte gesetzt sind.

Also nutzten wir den kurzen Draht zu Oracle und ein gemeinsamer Blick auf unseren Code bestätigte, dass wir laut Doku alles richtig gemacht haben. Als nächstes haben wir natürlich einen Service Request eröffnet und tiefer gegraben. Und wie so oft war die Lösung am Ende erstaunlich simpel. Der eigentliche Knackpunkt war, dass der Parameter “memory_size_in_gbs” nicht gesetzt war.

Dieser Parameter definiert den verfügbaren Hauptspeicher der Cluster-VMs. Beim Anlegen über das Azure-Portal wird dafür automatisch ein Default-Wert gesetzt. Der azurerm-Provider hingegen verlangt diesen Parameter nicht explizit – setzt aber eben auch keinen Default und wird dann mit einer eher unglücklich formulierten Fehlermeldung kombiniert. Kurz gesagt: Fehlt “memory_size_in_gbs”, kann der Cluster nicht erstellt werden, auch wenn alles andere korrekt aussieht.

Mit dem folgenden Zusatz lief das Deployment dann problemlos:

resource "azurerm_oracle_cloud_vm_cluster" "exacl-fz3" {
 …
 time_zone                       = "Europe/Berlin"
 db_node_storage_size_in_gbs     = 1000
 memory_size_in_gbs              = 600
 sparse_diskgroup_enabled        = false
 data_storage_size_in_tbs        = 192
 …
}

Falls Sie also beim Aufbau eines Exadata@Azure-Clusters per Code über genau diesen Fehler stolpern, wissen Sie nun woran es liegt.

Sie interessieren sich für die Grundlagen der OCI? Dann empfehle ich Ihnen diesen Kurs im Robotron Schulungszentrum: https://www.robotron.de/schulungszentrum/kurse/kurssuche/kursdetails/praxisworkshop-oracle-cloud-infrastructure-oci

Der Praxisworkshop bietet Ihnen einen technischen Einstieg in die Oracle Cloud Infrastructure (OCI) und lässt Sie von unserer umfangreichen Praxiserfahrung durch hilfreiche Tipps und erprobte Best Practices profitieren.