Datenbankverwaltung mit Nutanix
Ordnung schaffen
Veröffentlicht in Ausgabe 09/2022 - SCHWERPUNKT
Möglicherweise haben Sie schon einmal etwas von Era, einem Werkzeug des Softwareherstellers Nutanix gehört. Das Datenbank-Tool Era wurde kürzlich von Nutanix in NDB (Nutanix-Datenbank-Service) umbenannt. NDB ist eine Software-Suite bestehend aus einer virtuellen Aplliance samt Agenten, mit der Sie Datenbanken von unterschiedlichen Herstellern und Mengen verwalten und pflegen können. Entwickelt wurde die Suite in den Programmiersprachen Java und Python. NDB ist eine Datenbank-as-a-Service (DBaaS) zur Verwaltung von On-Premises-Clouddatenbanken.
Die Idee dahinter ist, die Administration von Datenbanken drastisch zu vereinfachen. Es ist schon recht selten, wenn eine Organisation lediglich die Datenbanken eines einzigen Datenbankherstellers einsetzt. Meistens sind die Umgebungen nicht so homogen, wie es zu wünschen wäre, und es sind jede Menge verschiedener Datenbanken für die unterschiedlichen Applikationen im Unternehmen im Einsatz. Das liegt nicht selten daran, dass Applikationen eine eigene DB mitbringen oder zumindest entsprechende Vorgaben machen. Das wiederum bedeutet, dass zahlreiche unterschiedliche Datenbank-Engines im Bestand sind, die alle mehr oder weniger gepflegt werden wollen und nach Best Practices auf dem neuesten Stand gehalten werden müssen. Ganz entscheidende Stichworte sind hier sicherlich das Lifecycle- und Security-Management von Datenbanken. Und was dann auch noch hinzukommt ist, dass die Datenbanken auf einem der vielen Betriebssysteme, die es heute gibt, laufen müssen.
Manch IT-Verantwortlicher hat sich im Laufe der Zeit eine umfangreiche Sammlung von Skripten zugelegt, um hier das eine oder andere zu automatisieren, zu vereinfachen und damit am Ende Zeit einzusparen. Aber auch Skripte müssen gepflegt werden und das ist dann auch ein nicht zu unterschätzender Arbeitsaufwand. Aber es gibt noch viele weitere Herausforderungen und komplexe Fragestellungen, die im Umfeld von Datenbanken zu lösen sind, denn je nach Größe und Hersteller spielt die Anzahl und die Größe von Volumes für die Datenbank eine entscheidende Rolle.
Möglicherweise haben Sie schon einmal etwas von Era, einem Werkzeug des Softwareherstellers Nutanix gehört. Das Datenbank-Tool Era wurde kürzlich von Nutanix in NDB (Nutanix-Datenbank-Service) umbenannt. NDB ist eine Software-Suite bestehend aus einer virtuellen Aplliance samt Agenten, mit der Sie Datenbanken von unterschiedlichen Herstellern und Mengen verwalten und pflegen können. Entwickelt wurde die Suite in den Programmiersprachen Java und Python. NDB ist eine Datenbank-as-a-Service (DBaaS) zur Verwaltung von On-Premises-Clouddatenbanken.
Die Idee dahinter ist, die Administration von Datenbanken drastisch zu vereinfachen. Es ist schon recht selten, wenn eine Organisation lediglich die Datenbanken eines einzigen Datenbankherstellers einsetzt. Meistens sind die Umgebungen nicht so homogen, wie es zu wünschen wäre, und es sind jede Menge verschiedener Datenbanken für die unterschiedlichen Applikationen im Unternehmen im Einsatz. Das liegt nicht selten daran, dass Applikationen eine eigene DB mitbringen oder zumindest entsprechende Vorgaben machen. Das wiederum bedeutet, dass zahlreiche unterschiedliche Datenbank-Engines im Bestand sind, die alle mehr oder weniger gepflegt werden wollen und nach Best Practices auf dem neuesten Stand gehalten werden müssen. Ganz entscheidende Stichworte sind hier sicherlich das Lifecycle- und Security-Management von Datenbanken. Und was dann auch noch hinzukommt ist, dass die Datenbanken auf einem der vielen Betriebssysteme, die es heute gibt, laufen müssen.
Manch IT-Verantwortlicher hat sich im Laufe der Zeit eine umfangreiche Sammlung von Skripten zugelegt, um hier das eine oder andere zu automatisieren, zu vereinfachen und damit am Ende Zeit einzusparen. Aber auch Skripte müssen gepflegt werden und das ist dann auch ein nicht zu unterschätzender Arbeitsaufwand. Aber es gibt noch viele weitere Herausforderungen und komplexe Fragestellungen, die im Umfeld von Datenbanken zu lösen sind, denn je nach Größe und Hersteller spielt die Anzahl und die Größe von Volumes für die Datenbank eine entscheidende Rolle.
Auch die Kapazitäts- und Performanceanforderung, die eine Datenbank mitbringt, müssen Sie im Blick behalten. Arbeiten Sie etwa mit Datawarehouse und Multi-TByte-Datenbanken, haben Sie sofort das Thema High-Performance-Database auf dem Tisch. Aber natürlich freuen sich alle User über kurze Antwortzeiten bei den Abfragen, nicht nur die Kollegen aus der High-Performance-Database-Ecke – gerade auch dann, wenn viele Datenbankkopien zu erstellen sind oder wenn mal eben die Anforderung lautet, den Entwicklern im Unternehmen eine DB mit realen Produktionsdaten zur Verfügung zu stellen, geht es immer um Performace.
Vorteile und Performance von Nutanix-HCI
NDB bedient sich gerade dann, wenn es um Performance geht, der Mechanismen der Nutanix-HCI (hyperkonvergente Infrastruktur), auf der die Appliance läuft. Durch die in der Architektur der Plattform verankerte, garantierte Data-Locality-Funktion und den Redirect on Write (RoW), der vom Software-defined Storage unter anderem auch bei der Erstellung von Snapshots verwendet wird, kann NDB mit enormer Performance glänzen. Das Konzept der Data Locality in der Nutanix-HCI sorgt dafür, dass Ihre Work-loads mit geringster, fast vernachlässigbarer Leselatenz arbeiten. Die Tatsache, dass ausschließlich die lokalen Disks eines Nodes zum Einsatz kommen, sorgt in den einzelnen Nodes eines Clusters für eine maximale Leistung, die natürlich direkt an den Workloads, in denen die Datenbanken betrieben werden, ankommt.
Es gibt eine ganze Reihe unterschiedlicher Verfahren, wie Snapshots – also Point-in-Time-Kopien – möglichst optimal erstellt werden können. Das effizienteste Verfahren im Storage-Umfeld ist wohl das Redirect-on-Write-Verfahren. RoW liefert eine optimale Performance und eignet sich zudem ideal für das langfristige Speichern von Snapshots. Hinzukommt, dass RoW obendrein auch noch Workload-zentrisch arbeitet, was bedeutet, dass ein Snapshot auch nur von einem einzelnen Workload erstellt wird und nicht wie so oft von einem ganzen Volume. Wenn Sie genau verstehen möchten, wie die Data Locality in der Nutanix-HCI funktioniert, empfehlen wir einen Blick in den Artikel "Direkt an der Quelle" aus IT-Administrator 06/2021 zu werfen [1].
Schnelleinstieg in NDB
Nachdem wir die Hintergründe darüber beleuchtet haben, warum NDB beim Kopieren beziehungsweise Klonen und beim Erstellen von Datenbank-Snapshots so performant arbeitet und problemlos mit großen und vielen unterschiedlichen Datenbanken zurechtkommt, schauen wir uns NDB etwas genauer an. Was sofort bei der UI auffällt, ist, dass das Konzept von Bedienung und Look-and-Feel bei NDB genauso konsequent umgesetzt wurde wie bei anderen Applikationen des Herstellers. Wenn Sie eine App bedienen können, kommen Sie quasi auch mit allen anderen zurecht.
Aber fangen wir ganz von vorn an. NDB ist sowohl für den Hypervisor von Nutanix (AHV) als auch den Hypervisor von VMware (ESXi) verfügbar. Weiterhin können Sie zum jetzigen Zeitpunkt NDB für die Verwaltung Ihrer Oracle-, Microsoft-SQL-Server-, PostgreSQL-, MongoDB-, MySQL-, MariaDB- und SAP-HANA-Datenbanken nutzen. Dazu kommt, dass NDB auch das Clustern von Datenbanken bezüglich der Aktiv-Aktiv-Cluster-Datenbanktechnologie von Oracle, den Real Application Clusters (RAC), Availability Groups (AG) für Microsoft SQL Server und Postgres HA (Patroni) für PostgreSQL über Nutanix-Cluster-Grenzen hinweg unterstützt.
Beim Windows Server Failovercluster (WSFC) handelt es sich übrigens um eine Gruppe unabhängiger Windows-Server, die gemeinsam die Verfügbarkeit von Anwendungen und Diensten erhöhen. Microsofts SQL-Server verwendet die WSFC-Dienste zur Realisierung von Always-On-Availability-Groups (AG) und SQL-Server-Failover-Cluster-Instanzen.
Es ist derweil auch kein Geheimnis, dass sich die unterschiedlichen Datenbanken in der Regel auch auf den unterschiedlichsten Betriebssystemen respektive Betriebssystem-Versionen installieren lassen. Das bedeutet, dass selbst wenn wir nur die aktuellen Betriebssysteme betrachten, es eine unglaubliche Menge an diesbezüglichen Kombinationen gibt. Deshalb schon einmal ein erster Tipp an dieser Stelle: Werfen Sie auf jeden Fall einen Blick auf die Compatibility- und Feature-Support-Matrix, die Sie in den NDB Release Notes finden. NDB unterstützt zwar heute schon sehr viele DB-OS-Kombinationen, aber eben nicht alle.
NDB kann auch Cluster-übergreifend (Multi-Cluster) zur Verwaltung Ihrer Datenbank-Workloads genutzt werden. Wenn Sie mehrere unterschiedliche Cluster von Nutanix im Einsatz haben, können Sie NDB auf dem einen Cluster ausrollen und dann auch die Datenbanken, die sich auf anderen Nutanix-Clustern befinden, ausrollen, einbinden oder bearbeiten. Cluster von Nutanix lassen sich mit unterschiedlichen Hypervisoren erstellen. Das bedeutet, dass Sie einen Cluster mit AHV und weitere Cluster dann beispielsweise mit ESXi oder Hyper-V aufbauen können. Auch die Hardware darf von Cluster zu Cluster mit Serversystemen von unterschiedlichen Hardwareherstellern ausgestattet werden. Administrieren lassen sich dann alle Cluster zusammen mit Prism Central, dem zentralen Verwaltungstool für Nutanix-Cluster.
Gehen wir nun einmal davon aus, dass NDB bereits in einem lokalen Nutanix-Cluster ausgerollt wurde. Ob NDB nun als qcow2-Image-Datei in einem Nutanix-AOS-Cluster unter AHV betrieben wird oder als OVA-Datei in einem Nutanix-AOS-Cluster unter ESXi und mittels vCenter-Server auf die Plattform gebracht wurde, ist für die nachfolgende Betrachtung eher unerheblich. Im Zuge des initialen Deployments wurde entweder eine IP-Adresse mitgegeben oder ein im Netz vorhandener DHCP-Server genutzt. In beiden Fällen erreichen Sie nun die HTML5-UI von NDB durch Eingabe der URL "https://<IP-Adresse oder FQDN der NDB-Appliance>" im Browser.
Bei der Erstanmeldung vergeben Sie Ihr bevorzugtes Passwort und melden sich an. Geführt von einem Wizard müssen Sie nun einige Felder ausfüllen, um NDB unter anderem mit der Plattform zu verbinden. Diese Registrierung umfasst etwa die IP-Adresse und die Anmeldedaten des Clusters, auf dem sich NDB befindet. Weiter können Sie in diesem Dialog auch Storage-Container angeben, die für ein Deployment von Datenbanken zum Einsatz kommen sollen.
Die Adressen von DNS-, NTP- und SMTP-Servern werden selbstverständlich ebenfalls abgefragt. Die Frage bezüglich des Netzwerkprofils sollten Sie an dieser Stelle allerdings mit "Create Profile Later" beantworten. Nachdem Sie auf "Get Started" geklickt haben, beginnt das finale Setup der NDB-Appliance – was je nachdem, was Sie an Leistung und Bandbreite zur Verfügung haben, auch schon einmal bis zu 15 Minuten dauern kann.
Einer der Gründe dafür liegt darin, dass jetzt auch diverse Datenbank-Engine-Image-Profiles einschließlich einem aktuellen Linux-OS wie PostgreSQL nebst PostgreSQL High Availibility, MariaDB, MySQL und MongoDB, die Sie später für Ihre Greenfield-Deployments von Datenbanken nutzen können, geladen werden. Natürlich müssen Sie diese Image-Profiles nicht verwenden, sondern können eigene, neu erstellte oder bereits bestehende Workloads mit Betriebssystem und Datenbank mittels NDB nutzen. Hierbei kann es sich auch um einen bereits seit langer Zeit in Produktion befindlichen "Brownfield"-Datenbank-Workload handeln, den Sie nun nicht mehr manuell verwalten möchten. Dies gilt gerade für Microsoft-SQL-Server-, Oracle- oder SAP-HANA-Datenbank-Workloads, da diese nicht bei der Installation von NDB als Datenbank-Engine-Image-Profiles als Vorlagen zur Verfügung stehen.
NDB-Dashboard in reinem HTML5
Nach der Anmeldung über die URL der NDB-Appliance landen Sie immer auf dem NDB-Dashboard. In der aktuellen Version 2.4.1 beziehungsweise zum Zeitpunkt der Erstellung dieses Artikels war in der UI noch an einigen Stellen der alte Name "Era" zu sehen. Dies sollte Sie nicht verwirren. In der Software ist unter dem Punkt "Getting Startet" ein Wizard integriert, der Sie an Ihr Ziel führen kann. Der ganze Prozess ist so intuitiv gestaltet und mit erklärenden Texten versehen, dass Sie eigentlich sofort mit Ihrer Arbeit beginnen können.
Der Wizard führt Sie Schritt für Schritt durch die vorhandene Menüstruktur der Software. Aber selbstverständlich müssen Sie den Wizard nicht nutzen. Sie können Ihre Arbeiten in NDB auch ohne diesen durchführen und direkt die benötigten Funktionen in der Menüstruktur von NDB aufrufen. Für einen Schnelleinstieg und um möglichst einfach den Umgang mit der Suite zu erlernen, ist der Wizard jedoch ideal geeignet.
Profile in NDB
Die Idee von NDB basiert prinzipiell darauf, die Tätigkeiten rund um Datenbanken, wie das Erstellen, das Kopieren, das Klonen und das Patchen und Updaten, auf der Basis von Profilen durchzuführen. Vor allem, wenn es auch um große Mengen an zu verwaltenden Datenbanken geht, ist das profilbasierte Arbeiten eigentlich unverzichtbar. Um Profile zu nutzen, ist ein Datenbank-Workload als Vorlage notwendig. Entweder verwenden Sie eines der mitgelieferten Datenbank-Engine-Image-Profile oder erstellen Sie einfach eine neue VM, versehen diese mit einem Betriebssystem und installieren und konfigurieren Ihre Wunschdatenbank. Alternativ dazu können Sie auch einen bereits bestehenden Datenbank-Workload verwenden.
Dabei stellt Ihnen die Appliance ein Framework basierend auf fünf unterschiedlichen Profilen zur Verfügung. Hierbei handelt es sich um Software-, Compute-, Network-, Database-Parameters- und Windows-Domain-Profile. Aber werfen wir zuerst einen genaueren Blick auf die einzelnen Profilvarianten, wobei Sie in diesem Zusammenhang sehen werden, wie einfach es ist, Profile selbst zu erstellen.
Jetzt ist es natürlich so, dass die unterschiedlichen Profile eine direkte Abhängigkeit zu den einzelnen Datenbanken aufweisen. Sie können für alle durch NDB unterstützten Datenbanken ein Softwareprofil erstellen. NDB bringt wie schon gesagt bereits Softwareprofile von Haus aus für PostgreSQL, MariaDB, MySQL und MongoDB mit, aber für Oracle, MS-SQL und SAP HANA müssen Sie erst einmal ein Profil anlegen. Das soll andererseits nicht bedeuten, dass Sie die vorhandenen Default-Profile zwingend nutzen müssen. Auch diese lassen sich ganz nach Ihren eigenen Bedürfnissen erstellen.
Es gibt zwei grundsätzliche Wege, um ein Softwareprofil anzufertigen. Der eine besteht darin, einen existierenden vollständigen Datenbank-Workload dazu zu nutzen, Pate zu stehen. Der andere Weg ist, einen Workload zu verwenden, der nur ein Betriebssystem enthält. Bei dieser Variante wird dann im Zuge der Profilerstellung eine Datenbank-ISO-Datei nebst Patch-File mitgegeben. Schauen wir uns einmal an, wie das Ganze in der ersten Variante abläuft. Bevor Sie ein eigenes Softwareprofil erstellen, registrieren Sie zunächst einen vorhandenen oder neu erstellten Datenbankserver-Workload. Im Zuge der Registrierung des Workloads versieht NDB diesen dann mit einem Agenten.
Zur Verdeutlichung hier ein Beispiel zu MS-SQL: Nachdem Sie einen Workload erstellt haben, der einen Windows-Server samt SQL-Server enthält, schauen Sie sich im Anschluss an die Kopplung die Verzeichnisstruktur an. Dort werden Sie ein neues Verzeichnis namens "C:\NTNX" finden. Daneben können Sie sich auch im Task-Manager die Dienste anzeigen lassen und Sie werden dort dann einen Service namens "Era Worker" vorfinden. Dieses Beispiel gilt vom Schema her nun stellvertretend für alle weiteren Datenbankankopplungen an NDB.
Selbstverständlich steht auch der umgekehrte Weg offen, und zwar die Deregistrierung einer Datenbank, wenn Sie diese nicht mehr über NDB verwalten möchten. Im Zuge der Abkopplung stellt NDB den Urzustand der Datenbankmaschine wieder her, sodass keine Fragmente des Agenten mehr im Workload vorhanden sind.
Mit einem Compute-Profil können Sie die Rahmenbedingungen im Hinblick auf die Anzahl der vCPUs, der vCores und des Arbeitsspeichers (RAM) für den zu erstellenden Datenbankserver-Workload vorgeben. Nach der Installation von NDB stehen zwei Out-of-the-Box-Profile zur Auswahl. Eigene Profile sind auch hier schnell erstellt.
Als Nächstes folgt das Netzwerkprofil. Dieses gibt das VLAN an, in dem sich der neue Datenbankserver-Workload befinden soll. Das vierte Profil, das benötigt wird, ist das Datenbank-Parameterprofil. Hier werden nun alle Vorgaben definiert, die die Datenbank im Workload betreffen. Wie beim Softwareprofil auch muss dieses auf die zu verwendende Datenbank abgestimmt werden. Dies merken Sie schon an den Vorlagen, die NDB hier von sich aus mitbringt.
NDB bringt bereits von Haus aus acht Profile für die aktuell unterstützten Datenbanken mit. Und auch hier gilt: Wenn Sie die verfügbaren Beispielprofile nicht verwenden möchten, können Sie entweder die Beispielprofile ändern oder Ihre eigenen erstellen. Standardmäßig hat NDB kein Windows-Domänenprofil an Bord. Zum Anlegen werden Informationen wie der Name der Domäne (FQDN) und der Benutzer sowie das Kennwort verlangt. Auch enthält dieses Profil Angaben zum Startkonto des SQL-Dienstes, die Pfade der Organisationseinheit (OU) et cetera. Aber wenn Sie alle für das Profil benötigten Informationen zur Hand haben, ist das Erstellen eines Windows-Domänenprofils auch keine große Sache.
Datenbankprofile in NDB |
|
Profilname |
Funktion |
DEFAULT_ORACLE_PARAMS |
Standard-Oracle-Datenbank-Parameterprofil |
DEFAULT_POSTGRES_PARAMS |
Standard-Datenbank-Parameterprofil für PostgreSQL-Datenbanken |
DEFAULT_SQLSERVER_INSTANCE_PARAMS |
Standard-SQL-Server-Datenbank-Parameterprofil für SQL-Server-Instanzen |
DEFAULT_SQLSERVER_DATABASE_PARAMS |
Standard-SQL-Server-Datenbank-Parameterprofil für SQL-Server-Datenbanken |
DEFAULT_MARIADB_PARAMS |
Standard-MariaDB-Datenbank-Parameterprofil |
DEFAULT_MYSQL_PARAMS |
Standard-MySQL-Datenbank-Parameterprofil |
DEFAULT_SAPHANA_PARAMS |
Standard-SAP-HANA-Datenbank-Parameterprofil |
DEFAULT_MONGODB_PARAMS |
Standard-MongoDB-Datenbank-Parameterprofil |
Datenbanken sichern und wiederherstellen
Eines der Kernfunktionsmodule in NDB ist die Time-Machine. Mit der Time-Machine können Sie unterschiedliche Vorgänge wie das Erstellen von Datenbank-Snapshots, -Transaktionsprotokollen oder -Klonen zeitlich verwalten und automatisieren. So lassen sich jederzeit beliebige Kopien der Daten aus Ihren Quelldatenbanken erzeugen, die Sie zu bestimmten Zeitpunkten durch Time-Machine haben erstellen lassen. Auch sind Datenbankwiederherstellungen auf der Basis von durch Time-Machine erstellten Snapshots und Wiederherstellungspunkten kein Thema. Hierbei wird dann die aktuelle Datenbank durch Daten eines Snapshots, der zu einem bestimmten Zeitpunkt erstellt wurde, ersetzt.
Sollte der Wiederherstellungsvorgang warum auch immer fehlschlagen, bleibt die Datenbank in dem Zustand, in dem sie sich vor dem Wiederherstellungsversuch befand. Die Administration und Planung sämtlicher Vorgänge finden über den integrierten Prozess-Scheduler innerhalb der NDB-UI statt. Dieser sieht wie ein normaler Kalender aus, in dem Sie anhand von Symbolen sehen, was an welchem Tag zu welcher Uhrzeit an Vorgängen durchgeführt wurde. Dabei können Sie dann auf einer Zeitlinie auch beispielsweise sofort erkennen, ob es sich bei einem Snapshot um ein automatisiert oder manuell erstelltes Datenbankabbild handelt. In der Time-Machine können Sie alles zur Anzeige bringen, was mit den von NDB verwalteten Datenbanken jemals durchgeführt wurde.
Das Einspielen eines oder mehrerer Datenbank-Fixes, etwa bei kumulierten Updates, erfolgt ebenfalls auf Basis der Profile. Möchten Sie beispielsweise, dass Ihre Datenbank-Updates zeitlich gesteuert ablaufen, ergänzen Sie einfach Ihre bereits erstellten Profile um diesen Task. So halten Sie mit dem automatisierten Einspielen von Service Packs Ihre alleinstehenden sowie geclusterten Datenbanken dann immer auf dem aktuellen Stand. Nach der Profilergänzung beziehungsweise -erstellung wird das Ganze noch veröffentlicht und kann danach zum vorgegebenen Zeitpunkt nach Belieben auf alle assoziierten Datenbanken angewendet werden. Überwachen lässt sich der Vorgang im integrierten Taskmanager von NDB.
Hinter den SLAs, also den Service Level Agreements, verbergen sich die Datenaufbewahrungs-Policies, in denen hinterlegt wurde, wie lange NDB Snapshots, die das Time-Machine-Modul erzeugt, aufbewahren soll. Ein Blick in die Tabelle "SLAs mit Aufbewahrungszeiträumen" zeigt die bereits in NDB enthaltenen Richtlinien. Selbstverständlich können Sie auch eigene Richtlinien erstellen und diese entsprechend einsetzen. Die selbsterstellten SLAs lassen sich nachträglich jederzeit editieren oder auch wieder löschen. Im Zuge der Registrierung einer Datenbank in NDB können Sie die SLAs, die Sie nutzen möchten, angeben.
SLAs mit Aufbewahrungszeiträumen |
|||||
SLAs |
Aufbewahrungszeiträume |
||||
kontinuierlich |
täglich |
wöchentlich |
monatlich |
Quartalsweise |
|
DEFAULT_OOB_GOLD_SLA |
30 Tage |
90 Tage |
16 Wochen |
12 Monate |
75 Quartale |
DEFAULT_OOB_SILVER_SLA |
14 Tage |
60 Tage |
12 Wochen |
12 Monate |
|
DEFAULT_OOB_BRONZE_SLA |
7 Tage |
30 Tage |
8 Wochen |
6 Monate |
|
DEFAULT_OOB_BRASS_SLA |
7 Tage |
||||
NONE |
|||||
Rollenbasiertes Konzept in NDB
Neben der Möglichkeit, lokale User anzulegen und mit entsprechenden Rollen auszustatten, ist es natürlich auch möglich, durch Kopplung mit dem Active Directory die AD-User mit den gewünschten Rollen zu versehen. Das gilt auch für Gruppen von Usern. Wie der Name schon sagt, gibt es bezüglich der Super-User-Rolle keine Beschränkungen im Hinblick auf die Möglichkeiten innerhalb von NDB. Berechtigungen wie etwa das Hinzufügen externer AD-Gruppen, die Vergabe von Rollen an die unterschiedlichen User oder ein Upgrade von NDB zu starten sind allerdings ausschließlich dieser Rolle vorbehalten.
Der Infrastructure-Admin hingegen darf nicht mehr alles und unterscheidet sich zum Beispiel dadurch von den anderen Rollen, dass er Infrastruktur-Ressourcen wie IP-Adress-Pools oder komplette HCI-Cluster-Ressourcen hinzufügen darf. Wogegen der Database-Infrastructure-Admin sich vom Database-Admin dadurch unterscheidet, dass er beispielsweise den Benutzern unter anderem das Erstellen von Profilen in NDB erlauben kann. Durch dieses umfangreiche und granulare Berechtigungskonzept ist NDB natürlich auch gut für die Nutzung im Umfeld von IT-Teamstrukturen in großen Enterprise-Umgebungen geeignet.
NDB via CLI und der API fernsteuern
In NDB können Sie Quellcode in einer von Ihnen bevorzugten Sprache (cURL, Python, Golang, JavaScript oder PowerShell) generieren. Sie nutzen dann einfach den von NDB generierten Code via Copy and Paste dazu, um aus anderen Applikationen wie UserDataScripts, ShellScripts, Terraform, OpenShift et cetera heraus NDB so anzusteuern, dass NDB die gewünschten Datenbankoperationen (etwa Erstellen und Registrieren von DBs, Cloning oder Snapshots) ferngesteuert durchführt. Stellen Sie sich einmal den Anwendungsfall vor, dass Sie aus Ihren Docker-Containern heraus mithilfe von ferngesteuertem NDB Ihre Datenbankoperationen ablaufen lassen. Es ist auch wirklich extrem einfach und intuitiv sich den gewünschten Source-Code von NDB erzeugen zu lassen.
Und so gehts: In jedem Fenster, in dem ein administrativer Vorgang abgeschlossen wird, lässt sich über den Button mit der Aufschrift "API Equivalent" der Quellcode dieses administrativen Vorgangs generieren, den Sie dann via Copy und Paste direkt für Ihre Automatisierungsvorhaben verwenden können. Möchten Sie beispielsweise einen neuen Datenbank-Serverworkload in NDB registrieren, gehen Sie einfach in das entsprechende Server-Datenbank-Registrierungsmenü, starten den Vorgang und geben alle Parameter, die vom System für die Registrierung verlangt werden, in die sich öffnenden Formulare nacheinander ein. Anschließend können Sie sich den Quellcode geben lassen und den Vorgang abbrechen oder zusätzlich noch den Vorgang starten und den entsprechenden Datenbank-Workload registrieren.
Fazit
Mit NDB steht den im Unternehmen zuständigen Datenbankadministratoren ein rollenbasiertes Tool zur automatisierten Verwaltung, Provisionierung und Wartung von Datenbanken zur Verfügung. Ein großer Vorteil für Admins liegt mit Sicherheit darin, dass sie all ihre datenbankbezogenen Tätigkeiten zentralisiert in einem einzigen Tool durchführen können. Mit der auf Policies basierenden Automatisierung lassen sich unterschiedliche Datenbanken provisionieren. Auch das Klonen oder Erstellen von zeitlich geplanten Snapshots für das Backup der Datenbanken mittels NDB nimmt Admins einiges an Arbeit ab.
Das Gleiche gilt für die automatisierte Durchführung von notwendigen Updates und das Einspielen von Patches. Und selbst im Umfeld von Hochverfügbarkeit für Datenbanken kann NDB für Entlastung und Ablaufoptimierung im Tagesgeschäft sorgen. Für Entwickler ist sicherlich die Einfachheit der Bereitstellung von Quellcode für unterschiedliche Programmierumgebungen eine interessante Option und erleichtert die Nutzung von NDB aus Fremdapplikationen oder selbst entwickelter Software heraus.
(dr)
Link
[1] Artikel: Nutanix HCI aus IT-Administrator 06/2021 https://www.it-administrator.de/magazin/heftarchiv/artikel/352219.html/