Schlagwort: SDN

Ich wollte in meiner Azure-Local-Demo-Umgebung die erste Network Security Group (NSG) bereitstellen. Mehrere Deployments sind jedoch fehlgeschlagen, obwohl die eigentliche NSG-Definition auf den ersten Blick unauffällig aussah.

Die entscheidende Fehlermeldung war dabei diese hier:

{
  "status": "Failed",
  "error": {
    "code": "NotImplemented",
    "message": "The moc-operator network security group service returned an error while reconciling: AddOrUpdateNetworkSecurityGroup not implemented for non-NC provider: Not Implemented"
  }
}

Zusätzlich tauchte auf ARM-Ebene noch der übliche Folgefehler auf:

{
  "code": "DeploymentFailed",
  "message": "At least one resource deployment operation failed.",
  "details": [
    {
      "code": "ResourceDeploymentFailure",
      "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."
    }
  ]
}

Worum es dabei eigentlich ging

Der Fehler lag am Ende nicht an einer falschen NSG-Regel oder an einem fehlerhaften ARM-/Bicep-Deployment. Das eigentliche Problem war, dass die Azure-Local-Umgebung noch nicht mit einem aktiven Network Controller (NC) bzw. der dazugehörigen SDN-Integration ausgestattet war.

Der Hinweis steckt bereits in der Fehlermeldung: not implemented for non-NC provider. Das Backend hat also signalisiert, dass es die NSG-Operation nicht ausführen kann, solange kein NC-basierter Provider zur Verfügung steht.

Erste Prüfung auf dem Host

Als Erstes habe ich auf einem Azure-Local-Knoten geprüft, ob die Plattform grundsätzlich passt und ob es bereits Hinweise auf einen vorhandenen Network Controller gibt:

systeminfo.exe | findstr /B /C:"OS Name" /C:"OS Version"

Get-ClusterGroup | Where-Object Name -match 'Network Controller|NC'

Get-ClusterResource | Where-Object Name -match 'Network Controller|NC'

Das Ergebnis war aufschlussreich:

• Der Host lief bereits auf Build 26100.
• Es gab jedoch keine vorhandene Network-Controller-Clustergruppe.
• Auch bei den Cluster-Ressourcen war kein aktiver NC zu sehen.

Damit war die Richtung klar: Die Umgebung war für NSGs noch nicht vollständig vorbereitet.

Der eigentliche Fix

Auf dem System war das passende ECE-Feature-Cmdlet bereits vorhanden:

Get-Command Add-EceFeature -ErrorAction SilentlyContinue

Also lag die Lösung darin, den Network Controller nachträglich zu aktivieren.

Mein erster Versuch sah so aus:

Add-EceFeature -Name NC -SDNPrefix AzLocal01 -AcknowledgeMaintenanceWindow

Das schlug allerdings direkt mit einem Validierungsfehler fehl:

The SDNPrefix 'azlocal01' is invalid. The SDNPrefix must be 8 characters or less.

Der SDNPrefix darf in diesem Fall also maximal 8 Zeichen lang sein.

Mit einem kürzeren Präfix funktionierte es dann:

Add-EceFeature -Name NC -SDNPrefix AZLOC01 -AcknowledgeMaintenanceWindow

Validierung nach der Aktivierung

Nach erfolgreicher Ausführung konnte ich prüfen, ob der Network Controller nun tatsächlich als Cluster-Ressource vorhanden und online ist:

Get-ClusterResource | Where-Object Name -match 'Network Controller|NC' |
    Select-Object Name, State, OwnerGroup, ResourceType |
    Format-Table -AutoSize

Das Ergebnis zeigte anschließend den aktiven NC:

Name        State   OwnerGroup  ResourceType
----        -----   ----------  ------------
azloc01-NC  Online  ApiService  Network Name

Ab diesem Zeitpunkt ließ sich das ursprüngliche NSG-Deployment erfolgreich durchführen.

Kurz zusammengefasst

• Die NSG-Bereitstellung schlug mit not implemented for non-NC provider fehl.
• Ursache war eine fehlende bzw. noch nicht aktivierte NC-/SDN-Integration in Azure Local.
• Der Fix bestand darin, den Network Controller per Add-EceFeature nachträglich zu aktivieren.
• Dabei ist zu beachten, dass der verwendete SDNPrefix maximal 8 Zeichen lang sein darf.
• Nach erfolgreicher NC-Aktivierung funktionierte auch die Bereitstellung der NSG.

Fazit

Wenn sich in Azure Local eine Network Security Group nicht erstellen lässt und dabei ein Fehler in Richtung non-NC provider auftaucht, lohnt es sich, nicht zuerst an den NSG-Regeln selbst zu zweifeln. In meinem Fall lag das Problem eine Ebene tiefer: Die Umgebung hatte schlicht noch keinen aktiven Network Controller.

Die eigentliche NSG war also nicht das Problem – die Plattformvoraussetzung dafür fehlte noch.

Schreibe einen Kommentar...