DE112020000629T5

DE112020000629T5 - Vereinheitlichte und automatisierte installation, einsatz, konfiguration und verwaltung von softwaredefinierten speicheranlagen

Info

Publication number: DE112020000629T5
Application number: DE112020000629.8T
Authority: DE
Inventors: William J. Elliot IV
Original assignee: EMC IP Holding Co LLC
Current assignee: EMC Corp
Priority date: 2019-01-31
Filing date: 2020-01-20
Publication date: 2021-11-11
Also published as: US10708135B1; CN113678100A; WO2020159734A1

Abstract

Auf eine Verbrauchsanforderung, umfassend einen Stapelparameter und einen Ressourceneigenschaftsparameter, wird zugegriffen. Der Stapelparameter spezifiziert mindestens einen Typ von angeforderter Speicheranlage. Der Ressourceneigenschaftsparameter spezifiziert mindestens eine von der Speicheranlage benötigte Funktionsfähigkeit. Basierend auf dem Stapelparameter wird ein Satz von einer oder mehreren ersten Speicheranlagen bestimmt, die in der Lage sind, die Verbrauchsanforderung zu erfüllen. Für jede erste Speicheranlage im Satz, der nicht eingesetzt wird, wird ein erster Arbeitsablauf generiert, der erste Arbeitsablauf ist konfiguriert, um die jeweilige erste Speicheranlage im Satz einzusetzen, der nicht eingesetzt wird. Für jede zweite Speicheranlage im Satz, der den Ressourceneigenschaftsparameter nicht aufweist, wird ein zweiter Arbeitsablauf generiert, der konfiguriert ist, um diese Ressourceneigenschaft in der jeweiligen zweiten Speicheranlage zu implementieren. Der Satz von Speicheranlagen ist konfiguriert, um die Verbrauchsanforderung zu erfüllen, indem der erste und zweite Arbeitsablauf ablaufen.

Description

GEBIET
Diese Anmeldung bezieht sich mindestens im Allgemeinen auf Geräte, Systeme und Verfahren zur Datenspeicherung und Datenverarbeitung in Computersystemen, einschließlich Systemen zum Verwalten von Daten und Ressourcen in einer virtualisierten Umgebung. Genauer gesagt bezieht sich diese Anmeldung mindestens auf Wege, um die Konfiguration, den Einsatz und die Installation von softwaredefiniertem Datenspeicher zu verbessern.
HINTERGRUND
Wenn der Wert und die Verwendung von Information weiter zunehmen, suchen Einzelpersonen und Unternehmen nach zusätzlichen Wegen, um Information zu verarbeiten und zu speichern. Eine Möglichkeit, die Benutzern zur Verfügung steht, sind Informationshandhabungssysteme. Ein Informationshandhabungssystem verarbeitet, kompiliert, speichert und/oder kommuniziert Information oder Daten für geschäftliche, persönliche oder andere Zwecke, wodurch es Benutzern ermöglicht wird, den Wert der Information zu nutzen. Da Technologie- und Informationshandhabungsbedürfnisse und -anforderungen zwischen verschiedenen Benutzern oder Anwendungen variieren, können Informationshandhabungssysteme auch variieren, was mit Information gehandhabt wird, wie die Information gehandhabt wird, wie viel Information verarbeitet, gespeichert oder kommuniziert wird und wie schnell und effizient die Information verarbeitet, gespeichert oder kommuniziert werden kann. Durch die Variationen in Informationshandhabungssystemen können Informationshandhabungssysteme allgemein oder für einen spezifischen Benutzer oder eine spezifische Verwendung konfiguriert werden, wie beispielsweise Finanztransaktionsverarbeitung, Flugbuchungen, Unternehmensdatenspeicherung oder globale Kommunikation. Darüber hinaus können Informationshandhabungssysteme eine Vielzahl von Hardware- und Softwarekomponenten beinhalten, die konfiguriert sein können, um Information zu verarbeiten, zu speichern und zu kommunizieren, und ein oder mehrere Computersysteme, Datenspeichersysteme und Netzwerksysteme beinhalten können.
In Datenspeichersystemen speichern Benutzer verschiedener Speichertechnologien enorme Datenmengen auf verschiedenen Speichergeräten. Aus einer Speicheranordnung von Speichergeräten kann ein Benutzer eine beliebige Kombination der Speichergeräte auswählen, um eine virtuelle Speicherressource oder logische Einheit zu erzeugen. Computersysteme verbessern sich ständig in Bezug auf Geschwindigkeit, Zuverlässigkeit und Verarbeitungsfähigkeit. Wie in der Technik bekannt ist, beinhalten Computersysteme, die große Datenmengen verarbeiten und speichern, typischerweise einen oder mehrere Prozessoren in Kommunikation mit einem gemeinsam genutzten Datenspeichersystem, in dem die Daten gespeichert werden. Das Datenspeichersystem kann eine oder mehrere Speichergeräte beinhalten, die normalerweise ziemlich robuster Natur und nützlich für die Speicherung sind, die verschiedene zeitliche Anforderungen, z. B. Plattenlaufwerke, überspannt. Der eine oder die mehreren Prozessoren führen ihre jeweiligen Arbeitsschritte unter Verwendung des Speichersystems durch. Massenspeichersysteme (MSS) beinhalten typischerweise eine Anordnung aus einer Mehrzahl von Platten mit integrierter intelligenter- und Kommunikationselektronik und Software, um die Daten auf den Platten verfügbar zu machen.
Darüber hinaus befassen sich Unternehmen mit mehr Daten als je zuvor, und die herkömmliche Infrastruktur bietet nicht mehr die Zuverlässigkeit, Leistung und Effizienz, die Unternehmensarbeitslasten (z. B. Unternehmensinformationshandhabungssysteme) erfordern. Diese Realität fordert die Informationstechnologie-Manager (IT) auf, einfachere und rationellere und kosteneffektivere Ansätze zu verfolgen, wie beispielsweise die softwaredefinierte Infrastruktur (SDI). SDI ermöglicht es Unternehmen, die Leistung und Effizienz von IT als ein Dienst zu genießen, indem Hardware und Software getrennt und auf eine umfangreiche Automatisierung und Orchestrierung fokussiert werden. Dies ermöglicht es IT, das Geschäft mit skalierbaren, agilen Ressourcen für Cloud- und webbasierte Dienste und native Cloud-Arbeitslasten zu versorgen.
Außerdem verwenden Informationsverarbeitungssysteme zunehmend rekonfigurierbare virtuelle Ressourcen, um sich ändernde Benutzerbedürfnisse auf effiziente, flexible und kosteneffektive Weise zu erfüllen. Beispielsweise wurden Cloud-Computing- und Speichersysteme, die unter Verwendung virtueller Ressourcen implementiert werden, weithin übernommen. Andere virtuelle Ressourcen, die nun in Informationsverarbeitungssystemen weit verbreitet sind, enthalten Linux-Container. Solche Container können verwendet werden, um mindestens einen Teil der Virtualisierungsinfrastruktur eines gegebenen Informationsverarbeitungssystems bereitzustellen.
ZUSAMMENFASSUNG
Diese Zusammenfassung wird bereitgestellt, um eine Auswahl von Konzepten in einer vereinfachten Form vorzustellen, um ein grundlegendes Verständnis einer oder mehrerer Ausführungsformen bereitzustellen, die nachstehend in der ausführlichen Beschreibung weiter beschrieben werden. Diese Zusammenfassung soll weder Schlüsselmerkmale oder wesentliche Merkmale des beanspruchten Gegenstands identifizieren, noch soll sie verwendet werden, um den Umfang des beanspruchten Gegenstands zu beschränken.
In bestimmten Ausführungsformen wird ein computer-implementiertes Verfahren zum Einsetzen von Speicheranlagen bereitgestellt. Auf eine Verbrauchsanforderung zum Verbrauchen von Speicheranlagen wird zugegriffen, die Verbrauchsanforderung umfassend einen Stapelparameter und einen Ressourceneigenschaftsparameter, wobei der Stapelparameter mindestens einen Typ von angeforderter Speicheranlage spezifiziert und der Ressourceneigenschaftsparameter mindestens eine von der Speicheranlage benötigte Funktionsfähigkeit spezifiziert. Basierend auf dem Stapelparameter wird ein Satz von einer oder mehreren ersten Speicheranlagen bestimmt, die in der Lage sind, die Verbrauchsanforderung zu erfüllen. Für jede erste Speicheranlage im Satz, der nicht eingesetzt wird, wird ein erster Arbeitsablauf generiert, der erste Arbeitsablauf ist konfiguriert, um die jeweilige erste Speicheranlage im Satz einzusetzen, der nicht eingesetzt wird. Für jede zweite Speicheranlage im Satz, der den Ressourceneigenschaftsparameter nicht aufweist, wird ein zweiter Arbeitsablauf generiert, der zweite Arbeitsablauf ist konfiguriert, um diese Ressourceneigenschaft in der jeweiligen zweiten Speicheranlage zu implementieren. Der Satz von Speicheranlagen ist konfiguriert, um die Verbrauchsanforderung zu erfüllen, wobei das Konfigurieren das Ablaufen des ersten und zweiten Arbeitsablaufs umfasst.
In bestimmten Ausführungsformen des computer-implementierten Verfahrens umfasst das computer-implementierte Verfahren ferner das Bestimmen, dass eine dritte Speicheranlagenressource erzeugt werden kann, um die Verbrauchsanforderung zu erfüllen; und das Generieren eines dritten Arbeitsablaufs, der konfiguriert ist, um die dritte Speicheranlagenressource zu erzeugen und einzusetzen. In bestimmten Ausführungsformen wird die dritte Speicheranlagenressource innerhalb mindestens einer der ersten und zweiten Speicheranlagen gebildet.
In bestimmten Ausführungsformen des computer-implementierten Verfahrens dient die Verbrauchsanforderung zum Bereitstellen einer Dateifreigabe, und das computer-implementierte Verfahren umfasst ferner das Kontaktieren eines oder mehrerer LINUX-Hosts, um eine Hostinformation zu ermitteln und zu speichern, das Registrieren des einen oder der mehreren LINUX-Hosts, das Anfordern eines Einsatzes eines vorbestimmten Typs von Speicheranlagen als jeweilige Dienste, und das Erzeugen einer entsprechenden Dateifreigabe.
In weiteren Ausführungsformen des computer-implementierten Verfahrens umfasst die Verbrauchsanforderung eine Abfrage, die Abfrageparameter enthält, die sich auf eine Suche eines Inventars der Speicheranlagen beziehen, und das computer-implementierte Verfahren umfasst ferner das Vordefinieren eines Satzes von Vorlagen, die auf die Speicheranlagen anwendbar sind, wobei jede jeweilige Vorlage eine Konfiguration der jeweiligen Speicheranlage und Voraussetzungen zum Einsetzen der Speicheranlage umfasst, und das Generieren eines Regelsatzes, der konfiguriert ist, um auf einem Inventar von Speicheranlagen ausgeführt zu werden, wobei der Regelsatz konfiguriert ist, um basierend auf einer oder mehreren Regeln im Regelsatz zu bestimmen, ob eine Vorlage für eine gegebene Speicheranlage realisierbar ist.
In bestimmten Ausführungsformen des computer-implementierten Verfahrens wird eine Liste von Einsatzvorlagen empfangen, die auf die Speicheranlagen anwendbar sind, wobei die Liste im Hinblick auf den Regelsatz generiert wird, wobei die Liste von Einsatzvorlagen mindestens eines von umfasst: Ein Grund, warum ein zweiter Teil der Liste von Einsatzvorlagen nicht eingesetzt werden kann; und Gründe warum ein zweiter Teil der Liste von Einsatzvorlagen nicht eingesetzt werden kann.
In bestimmten Ausführungsformen des computer-implementierten Verfahrens umfassen die Speicheranlagen softwaredefinierte Speicheranlagen. In bestimmten Ausführungsformen wird mindestens ein Teil des computer-implementierten Verfahrens in einer cloudnativen Umgebung ausgeführt.
In einem anderen Aspekt wird ein System bereitgestellt, wobei das System einen Prozessor und einen nichtflüchtigen Speicher in betriebsfähiger Kommunikation mit dem Prozessor und Speichern von Computerprogrammcode umfasst, der, wenn er auf dem Prozessor ausgeführt wird, den Prozessor veranlasst, einen Prozess auszuführen, der betriebsfähig ist, um bestimmte Arbeitsschritte durchzuführen. Ein Arbeitsschritt umfasst Zugreifen auf eine Verbrauchsanforderung zum Verbrauchen von Speicheranlagen, die Verbrauchsanforderung umfassend einen Stapelparameter und einen Ressourceneigenschaftsparameter, wobei der Stapelparameter mindestens einen Typ von angeforderter Speicheranlage spezifiziert und der Ressourceneigenschaftsparameter mindestens eine von der Speicheranlage benötigte Funktionsfähigkeit spezifiziert. Ein Arbeitsschritt umfasst Bestimmen, basierend auf dem Stapelparameter, eines Satzes von einer oder mehreren ersten Speicheranlagen, die in der Lage sind, die Verbrauchsanforderung zu erfüllen. Ein Arbeitsschritt umfasst für jede erste Speicheranlage im Satz, der nicht eingesetzt wird, Generieren eines ersten Arbeitsablaufs, der konfiguriert ist, um die jeweilige erste Speicheranlage im Satz einzusetzen, der nicht eingesetzt wird. Ein Arbeitsschritt umfasst für jede zweite Speicheranlage im Satz, der den Ressourceneigenschaftsparameter nicht aufweist, Generieren eines zweiten Arbeitsablaufs, der konfiguriert ist, um diese Ressourceneigenschaft in der jeweiligen zweiten Speicheranlage zu implementieren. Ein Arbeitsschritt umfasst Konfigurieren des Satzes von Speicheranlagen, um die Verbrauchsanforderung zu erfüllen, wobei das Konfigurieren das Ablaufen des ersten und zweiten Arbeitsablaufs umfasst.
In einer weiteren Ausführungsform des Systems umfassen die durchgeführten Arbeitsschritte ferner das Bestimmen, dass eine dritte Speicheranlagenressource erzeugt werden kann, um die Verbrauchsanforderung zu erfüllen, und das Generieren eines dritten Arbeitsablaufs, der konfiguriert ist, um die dritte Speicheranlagenressource zu erzeugen und einzusetzen. In bestimmten Ausführungsformen wird die dritte Speicheranlagenressource innerhalb mindestens einer der ersten und zweiten Speicheranlagen gebildet. In bestimmten Ausführungsformen umfasst die Verbrauchsanforderung eine Abfrage, die Abfrageparameter enthält, die sich auf eine Suche eines Inventars der Speicheranlagen beziehen, und das computer-implementierte Verfahren umfasst ferner Computerprogrammcode, der, wenn er auf dem Prozessor ausgeführt wird, den Prozessor veranlasst, die folgenden Aktionen durchzuführen: Vordefinieren eines Satzes von Vorlagen, die auf die Speicheranlagen anwendbar sind, wobei jede jeweilige Vorlage eine Konfiguration der jeweiligen Speicheranlage und Voraussetzungen zum Einsetzen der Speicheranlage umfasst, und Generieren eines Regelsatzes, der konfiguriert ist, um auf einem Inventar von Speicheranlagen ausgeführt zu werden, wobei der Regelsatz konfiguriert ist, um basierend auf einer oder mehreren Regeln im Regelsatz zu bestimmen, ob eine Vorlage für eine gegebene Speicheranlage realisierbar ist.
In bestimmten Ausführungsformen des Systems enthalten die Arbeitsschritte das Empfangen einer Liste von Einsatzvorlagen, die auf die Speicheranlagen anwendbar sind, wobei die Liste im Hinblick auf den Regelsatz generiert wird, wobei die Liste von Einsatzvorlagen mindestens eines von umfasst: Gründe, warum ein erster Teil der Liste von Einsatzvorlagen eingesetzt werden kann; und Gründe, warum ein zweiter Teil der Liste von Einsatzvorlagen nicht eingesetzt werden kann.
In bestimmten Ausführungsformen des Systems umfassen die Speicheranlagen softwaredefinierte Speicheranlagen. In bestimmten Ausführungsformen des Systems wird mindestens ein Teil des Computerprogrammcodes in einer cloudnativen Umgebung ausgeführt.
In einem weiteren Aspekt wird ein Computerprogrammprodukt bereitgestellt, wobei das Computerprogrammprodukt ein nichtflüchtiges computerlesbares Speichermedium enthält, auf dem Computerprogrammcode codiert ist, der, wenn er auf einem Prozessor eines Computers ausgeführt wird, den Computer veranlasst, ein Speichersystem zu betreiben. In bestimmten Ausführungsformen umfasst das Computerprogrammprodukt Computerprogrammcode zum Zugreifen auf eine Verbrauchsanforderung zum Verbrauchen von Speicheranlagen, die Verbrauchsanforderung umfassend einen Stapelparameter und einen Ressourceneigenschaftsparameter, wobei der Stapelparameter mindestens einen Typ von angeforderter Speicheranlage spezifiziert und der Ressourceneigenschaftsparameter mindestens eine von der Speicheranlage benötigte Funktionsfähigkeit spezifiziert. In bestimmten Ausführungsformen umfasst das Computerprogrammprodukt Computerprogrammcode zum Bestimmen, basierend auf dem Stapelparameter, eines Satzes von einer oder mehreren ersten Speicheranlagen, die in der Lage sind, die Verbrauchsanforderung zu erfüllen.
In bestimmten Ausführungsformen umfasst das Computerprogrammprodukt Computerprogrammcode zum Generieren, für jede erste Speicheranlage im Satz, der nicht eingesetzt wird, eines ersten Arbeitsablaufs, der konfiguriert ist, um die jeweilige erste Speicheranlage im Satz einzusetzen, der nicht eingesetzt wird. In bestimmten Ausführungsformen umfasst das Computerprogrammprodukt Computerprogrammcode zum Generieren, für jede zweite Speicheranlage im Satz, der den Ressourceneigenschaftsparameter nicht aufweist, eines zweiten Arbeitsablaufs, der konfiguriert ist, um diese Ressourceneigenschaft in der jeweiligen zweiten Speicheranlage zu implementieren. In bestimmten Ausführungsformen umfasst das Computerprogrammprodukt Computerprogrammcode zum Konfigurieren des Satzes von Speicheranlagen, um die Verbrauchsanforderung zu erfüllen, wobei das Konfigurieren das Ablaufen des ersten und zweiten Arbeitsablaufs umfasst.
In weiteren Ausführungsformen umfasst das Computerprogrammprodukt Computerprogrammcode zum Bestimmen, dass eine dritte Speicheranlagenressource erzeugt werden kann, um die Verbrauchsanforderung zu erfüllen, und Computerprogrammcode zum Generieren eines dritten Arbeitsablaufs, der konfiguriert ist, um die dritte Speicheranlagenressource zu erzeugen und einzusetzen.
In zusätzlichen Ausführungsformen umfasst die Verbrauchsanforderung eine Abfrage, die Abfrageparameter enthält, die sich auf eine Suche eines Inventars der Speicheranlagen beziehen, und das Computerprogrammprodukt umfasst ferner Computerprogrammcode zum Vordefinieren eines Satzes von Vorlagen, die auf die Speicheranlagen anwendbar sind, wobei jede jeweilige Vorlage eine Konfiguration der jeweiligen Speicheranlage und Voraussetzungen zum Einsetzen der Speicheranlage umfasst, und Computerprogrammcode zum Generieren eines Regelsatzes, der konfiguriert ist, um auf einem Inventar von Speicheranlagen ausgeführt zu werden, wobei der Regelsatz konfiguriert ist, um basierend auf einer oder mehreren Regeln im Regelsatz zu bestimmen, ob eine Vorlage für eine gegebene Speicheranlage realisierbar ist.
In bestimmten Ausführungsformen umfasst das Computerprogrammprodukt Computerprogrammcode zum Empfangen einer Liste von Einsatzvorlagen, die auf die Speicheranlagen anwendbar sind, wobei die Liste im Hinblick auf den Regelsatz generiert wird, wobei die Liste von Einsatzvorlagen mindestens eines von umfasst: ein Grund, warum ein erster Teil der Liste von Einsatzvorlagen eingesetzt werden kann; und Gründe, warum ein zweiter Teil der Liste von Einsatzvorlagen nicht eingesetzt werden kann. In bestimmten Ausführungsformen umfassen die Speicheranlagen softwaredefinierte Speicheranlagen. Details, die sich auf diese und andere Ausführungsformen beziehen, werden hierin ausführlicher beschrieben.
Figurenliste
Objekte, Aspekte, Merkmale und Vorteile von hierin offenbarten Ausführungsformen werden aus der folgenden ausführlichen Beschreibung, den beigefügten Ansprüchen und den beigefügten Zeichnungen, in denen gleiche Bezugszeichen ähnliche oder identische Elemente bezeichnen, deutlicher ersichtlich. Bezugszeichen, die in der Beschreibung in Verbindung mit einer Figur eingeführt werden, können in einer oder mehreren nachfolgenden Figuren ohne zusätzliche Beschreibung in der Beschreibung wiederholt werden, um einen Kontext für andere Merkmale bereitzustellen. Aus Gründen der Klarheit kann nicht jedes Element in jeder Figur bezeichnet sein. Es versteht sich, dass die Zeichnungen nicht unbedingt maßstabsgetreu sind, sondern stattdessen auf die Veranschaulichung von Ausführungsformen, Prinzipien und Konzepten gelegt werden. Die Zeichnungen sollen den Umfang der hiermit enthaltenen Ansprüche nicht beschränken.

1 ist ein veranschaulichendes Funktionsdiagramm einer Verwaltungs- und Betriebsebene (M&O), die auf hoher Ebene eine beispielhafte softwaredefinierte Speicherplattform gemäß mindestens einer veranschaulichenden Ausführungsform der Offenbarung einkapselt;
2 ist ein veranschaulichendes Diagramm, das zeigt, wie mehrere Datendienste zusammen auf Servern in einem beispielhaften System, einschließlich Anwendungen, die Kunden ausführen, gemäß einer veranschaulichenden Ausführungsform der Offenbarung existieren;
3 ist ein vereinfachtes Diagramm einer Architektur, die eine softwaredefinierte Speichersuite gemäß einer veranschaulichenden Ausführungsform der Offenbarung implementiert.
4 ist ein detaillierteres Diagramm der in 3 gezeigten Architektur gemäß einer veranschaulichenden Ausführungsform;
5 ist ein Diagramm, das Steuerungsdienste für die Architektur zeigt, die im detaillierten Diagramm von 4 gemäß einer veranschaulichenden Ausführungsform der Offenbarung gezeigt ist;
6 ist eine veranschaulichende Benutzerschnittstelle, die konfiguriert ist, um mit den verschiedenen hierin beschriebenen Architekturen gemäß mindestens einer offenbarten Ausführungsform zu arbeiten;
7 ist ein erstes veranschaulichendes Diagramm, das Komponenten innerhalb der Stapeleinsatzorchestrierungssteuerung von 5 gemäß einer Ausführungsform zeigt;
8 ist ein zweites veranschaulichendes Diagramm, das zusätzliche Komponenten zeigt, die innerhalb der Stapeleinsatzorchestrierungssteuerung von 5 gemäß mindestens einer Ausführungsform verwendet werden;
9 ist ein erstes vereinfachtes Flussdiagramm eines beispielhaften Verfahrens zum Speicherdiensteinsatz, das mit den Systemen der 3-8 gemäß einer Ausführungsform verwendbar ist;
10 ist ein zweites vereinfachtes Flussdiagramm eines beispielhaften Verfahrens zum Dienstspeichereinsatz, das mit den Systemen der 3-8 gemäß einer Ausführungsform verwendbar ist;
11 ist ein Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 3-8 stattfinden, die während des Speicherdiensteinsatzes stattfindet, die Aktionen zeigt, die auftreten, wenn ein Kunde nach einer NAS-Freigabe (Network Attached Storage) fragt, bis zu dem Punkt, an dem der Arbeitsablauf zusammengesetzt und an den Arbeitsablaufausführungsdienst der 3-8 gemäß mindestens einer Ausführungsform weitergegeben wird;
12 ist ein veranschaulichendes Diagramm, das automatisierte vertikale Funktionen zeigt, die in einer Architektur stattfinden, die auf den Architekturen der 3-8 gemäß mindestens einer Ausführungsform basiert;
13 ist ein vereinfachtes Flussdiagramm, das ein Verfahren zum Registrieren und Einsetzen von Hosts und Speicher für die Architekturen der 3-12 gemäß mindestens einer Ausführungsform zeigt;
14 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während der Registrierung eines Hosts und dem Einsatz eines softwaredefinierten Shared-Block-Speichers (basierend auf Direct Attached Storage), wie etwa VxFlex OS und softwaredefiniertem Network Attached Storage (SDNAS), gemäß mindestens einer Ausführungsform aktiv sind;
15 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während der Registrierung eines Hosts aktiv sind, gemäß mindestens einer Ausführungsform;
16 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während des Einsatzes von Scale 10 als Dienst aktiv sind, gemäß mindestens einer Ausführungsform;
17 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während des Einsatzes von SDNAS als Dienst aktiv sind, gemäß mindestens einer Ausführungsform;
18 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während der Erzeugung einer NFS (Network File Share) aktiv sind, gemäß mindestens einer Ausführungsform;
19 ist ein veranschaulichendes Diagramm, das die Komponenten zeigt, die während der Registrierung eines Hosts aktiv sind und Einsatzvorlagen anfordern, gemäß mindestens einer Ausführungsform;
20 ist ein veranschaulichendes vereinfachtes Flussdiagramm, das Aktionen zeigt, die während der Registrierung eines Hosts stattfinden und Einsatzvorlagen anfordern, in der Architektur von mindestens 3-8, gemäß mindestens einer Ausführungsform;
21 ist ein veranschaulichendes vereinfachtes Flussdiagramm, das ein Verfahren zum Antworten auf eine Anforderung zum Bereitstellen von Speicher zeigt, das das Angeben, welche Konfigurationen im Inventar verfügbar sind, und die Fähigkeit dieses Inventars für die Architektur der mindestens 3-8 gemäß mindestens einer Ausführungsform beinhaltet;
22 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die verwendet werden, um ein Verfahren zum Anfordern von Vorlagen für das Verfahren der 21 gemäß mindestens einer Ausführungsform zu implementieren;
23 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die verwendet werden, um ein Verfahren zum Erhalten installierter Speicherdienste für das Verfahren der 21 gemäß mindestens einer Ausführungsform zu implementieren;
24 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die verwendet werden, um ein Verfahren zum Erhalten von Echtzeitdaten installierter Speicherdienste für das Verfahren der 21 gemäß mindestens einer Ausführungsform zu implementieren;
25 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die verwendet werden, um ein Verfahren zum Einsetzen eines Speicherstapels für das Verfahren der 21 gemäß mindestens einer Ausführungsform zu implementieren;
26 ist ein vereinfachtes Flussdiagramm eines beispielhaften Verfahrens zum Identifizieren eines Pools von Hardware, der von SDS-Plattformen verbraucht werden kann, und zum elastischen Erweitern/Kontrahieren bestehender Speicherstapel für mindestens die Architektur der 2-19 gemäß mindestens einer Ausführungsform;
27 ist ein vereinfachtes Flussdiagramm eines Verfahrens zum Parsen einer Verbrauchsanforderung für Benutzerinformationen für das Flussdiagramm der 28 gemäß mindestens einer Ausführungsform;
28 ist ein vereinfachtes Flussdiagramm eines Verfahrens zum Parsen einer Verbrauchsanforderung für Speichertypinformationen gemäß mindestens einer Ausführungsform; und
29 ist ein vereinfachtes Blockdiagramm einer Vorrichtung, die verwendet werden kann, um mindestens einen Teil der Systeme und des Verfahrens der 1-28 gemäß mindestens einigen Ausführungsformen zu implementieren.

AUSFÜHRLICHE BESCHREIBUNG
Mindestens einige veranschaulichende Ausführungsformen werden hierin unter Bezugnahme auf beispielhafte Informationsverarbeitungssysteme und zugehörige Computer, Server, Speichergeräte und andere Verarbeitungsgeräte beschrieben. Es versteht sich jedoch, dass hierin beschriebene Ausführungsformen nicht auf die Verwendung mit den gezeigten besonderen veranschaulichenden System- und Gerätkonfigurationen beschränkt sind. Darüber hinaus können Ausführungsformen ohne Einschränkung Vorrichtungen, Systeme, Verfahren und Computerprogrammprodukte beinhalten, die prozessorlesbare Speichermedien umfassen.
Es wird erwartet, dass mindestens einige der hierin beschriebenen Ausführungsformen in verschiedenen Arten von Speichersystemen, nicht nur softwaredefinierten Speichersystemen, funktionsfähig sind. In einigen Ausführungsformen kann die vorliegende Offenbarung die Offenlegung logischer Speicherressourcen ermöglichen und es IT-Abteilungen und Cloud-Service-Anbietern von Unternehmen ermöglichen, heterogene Speicherumgebungen durch eine einfache, robuste Representational State Transfer (REST) API und eine Befehlszeilenschnittstelle (CLI) zu verwalten.
Bevor Ausführungsformen der Konzepte, Strukturen und Techniken beschrieben werden, die hierin geschützt werden sollen, werden einige Begriffe erläutert und auf einige relevante Hintergrundpatente Bezug genommen. Die folgende Beschreibung beinhaltet mehrere Begriffe, für die die Definitionen im Allgemeinen in der Technik bekannt sind. Die folgenden Glossardefinitionen werden jedoch bereitgestellt, um die nachfolgende Beschreibung zu verdeutlichen, und können beim Verständnis der Beschreibung und der Ansprüche hilfreich sein.
Wie hierin verwendet, soll der Begriff „Speichersystem“ weithin so ausgelegt werden, dass er beispielsweise private oder öffentliche Cloud-Computing-Systeme zum Speichern von Daten sowie Systeme zum Speichern von Daten, die virtuelle Infrastruktur umfassen, und solche, die keine virtuelle Infrastruktur umfassen, umfasst. Wie hierin verwendet, beziehen sich die Begriffe „Client“, „Host“ und „Benutzer“ austauschbar auf jede Person, jedes System oder jede andere Entität, die ein Speichersystem zum Lesen/Schreiben von Daten verwendet. In einigen Ausführungsformen kann sich der Begriff „Speichergerät“ auch auf eine Speicheranordnung beziehen, die mehrere Speichergeräte beinhaltet. In bestimmten Ausführungsformen kann sich ein Speichermedium auf ein oder mehrere Speichermedien beziehen, wie beispielsweise eine Festplatte, eine Kombination von Festplatten, Flash-Speicher, Kombinationen von Flash-Speicher, Kombinationen von Festplatten, Flash und anderen Speichergeräten und andere Arten und Kombinationen von computerlesbaren Speichermedien, einschließlich solcher, die noch nicht konzipiert wurden. Ein Speichermedium kann sich auch sowohl auf physische als auch logische Speichermedien beziehen und kann mehrere Ebenen von virtuellen bis physischen Abbildungen beinhalten und kann ein Bild oder ein Diskettenbild sein oder beinhalten. Ein Speichermedium kann computerlesbar sein und kann hierin auch als computerlesbares Speichermedium bezeichnet werden.
In bestimmten Ausführungsformen kann der Begriff „Informationsverarbeitungssystem“ verwendet werden, um beispielsweise Verarbeitungssysteme, die Cloud-Computing- und Speichersysteme umfassen, sowie andere Arten von Verarbeitungssystemen, die verschiedene Kombinationen von physischen und virtuellen Verarbeitungsressourcen umfassen, zu umfassen. Ein Informationsverarbeitungssystem kann daher beispielsweise mindestens ein Rechenzentrum oder eine andere Art von Cloudbasiertem System umfassen, das eine oder mehrere Clouds beinhaltet, die Mandanten hosten, die auf Cloud-Ressourcen zugreifen. Cloud-Computing soll sich auf alle Varianten von Cloud-Computing beziehen, einschließlich, aber nicht beschränkt auf öffentliches, privates und hybrides Cloud-Computing. Darüber hinaus können sich Informationshandhabungsressourcen weithin auf jedes Komponentensystem, jedes Gerät oder jede Vorrichtung eines Informationshandhabungssystems beziehen, einschließlich, ohne Einschränkung, Prozessoren, Busse, Speicher, Eingabe-Ausgabe-Geräte und/oder Schnittstellen, Speicherressourcen, Netzwerkschnittstellen, Motherboards, elektromechanische Geräte (z. B. Lüfter), Anzeigen und Stromversorgungen.
In bestimmten Ausführungsformen kann der Begriff „computerlesbare Medien“ jede beliebige Instrumentalität oder Aggregation von Instrumentalitäten beinhalten, die Daten und/oder Anweisungen für einen Zeitraum behalten können. Computerlesbare Medien können ohne Einschränkung Speichermedien beinhalten, wie beispielsweise eine Direktzugriffsspeichervorrichtung (z. B. ein Festplattenlaufwerk oder eine Diskette), eine Speichervorrichtung mit sequenziellem Zugriff (z. B. ein Bandlaufwerk), eine Compact Disk, CD-ROM, DVD, Direktzugriffsspeicher („RAM“), Nur-Lese-Speicher („ROM“), elektrisch löschbarer programmierbarer Nur-Lese-Speicher („EEPROM“) und/oder Flash-Speicher; sowie Kommunikationsmedien, wie beispielsweise Drähte, optische Fasern, Mikrowellen, Funkwellen und andere elektromagnetische und/oder optische Träger; und/oder jede beliebige Kombination der vorgenannten.
In bestimmten Ausführungsformen kann der Begriff „I/O-Anforderung“ oder einfach „I/O“ verwendet werden, um sich auf eine Eingabe- oder Ausgabeanforderung zu beziehen, wie beispielsweise eine Datenlese- oder Datenschreibanforderung, die von einem Host, einem Benutzer oder jeder anderen Entität stammen kann, die in betriebsfähiger Kommunikation mit einem Computersystem steht.
In bestimmten Ausführungsformen kann sich der Begriff „Speichergerät“ auf jedes nichtflüchtige Speichergerät (NVM) beziehen, einschließlich Festplattenlaufwerke (HDDs), Festkörperlaufwerke (SSDs), Flash-Geräte (z. B. NAND-Flash-Geräte) und ähnliche Geräte, auf die lokal und/oder entfernt zugegriffen werden kann (z. B. über ein Speicherverbundenes Netzwerk (SAN) (hierin auch als Speicheranordnungsnetzwerk (SAN) bezeichnet).
In bestimmten Ausführungsformen kann sich eine Speicheranordnung (manchmal als Plattenanordnung bezeichnet) auf ein Datenspeichersystem beziehen, das für blockbasierte, dateibasierte oder Objektspeicherung verwendet wird, wobei Speicheranordnungen beispielsweise dedizierte Speicherhardware beinhalten können, die rotierende Festplattenlaufwerke (HDDs), Festkörperlaufwerke und/oder All-Flash-Laufwerke enthält (z. B. das XtremIO All-Flash-Laufwerk, das von DELL/EMC von Hopkinton MA erhältlich ist). In bestimmten Ausführungsformen kann eine Datenspeicherentität eines oder mehrere von einem Dateisystem, Objektspeicher, einem virtualisierten Gerät, einer logischen Einheit, einer logischen Einheitsnummer, einem logischen Volumen, einem logischen Gerät, einem physischen Gerät und/oder einem Speichermedium sein.
In bestimmten Ausführungsformen kann eine logische Einheit (LU) eine logische Entität sein, die von einem Speichersystem zum Zugreifen auf Daten aus dem Speichersystem bereitgestellt wird, und wie hierin verwendet, wird eine logische Einheit austauschbar mit einem logischen Volumen verwendet. In vielen Ausführungsformen hierin kann eine LU oder LUN (logische Einheitsnummer) austauschbar füreinander verwendet werden. In bestimmten Ausführungsformen kann eine LUN eine logische Einheitsnummer zum Identifizieren einer logischen Einheit sein; kann sich auch auf eine oder mehrere virtuelle Disketten oder virtuelle LUNs beziehen, die einer oder mehreren virtuellen Maschinen entsprechen können. LUNs können in kleinere logische Bereiche unterteilt werden, um die Last zwischen Systemmodulen auszugleichen, wobei jeder solche kleine logische Bereich als Sub-LUN bezeichnet wird.
In bestimmten Ausführungsformen kann eine physische Speichereinheit eine physische Entität sein, wie beispielsweise eine Platte oder eine Anordnung von Platten, zum Speichern von Daten an Speicherorten, auf die durch Adresse zugegriffen werden kann, wobei die physische Speichereinheit austauschbar mit dem physischen Volumen verwendet wird. In bestimmten Ausführungsformen kann eine Datenspeicherentität eines oder mehrere von einem Dateisystem, Objektspeicher, einem virtualisierten Gerät, einer logischen Einheit, einer logischen Einheitsnummer, einem logischen Volumen, einem logischen Gerät, einem physischen Gerät und/oder einem Speichermedium sein.
In bestimmten Ausführungsformen kann sich eine Speichersteuerung auf ein beliebiges System, eine Vorrichtung oder ein Gerät beziehen, das betriebsfähig ist, um die Kommunikation von Daten zwischen einem Prozessor und Speicherressourcen einer Speicheranordnung zu verwalten. In bestimmten Ausführungsformen kann eine Speichersteuerung Funktionalität bereitstellen, einschließlich, ohne Einschränkung, Plattenaggregation und redundante Anordnung unabhängiger Platten (RAID), I/O-Routing und Fehlererkennung und -wiederherstellung. Eine Speichersteuerung kann auch Merkmale aufweisen, die geteilten Speicher und hohe Verfügbarkeit unterstützen. In einigen Ausführungsformen kann eine Speichersteuerung eine PowerEdge-RAID-Steuerung (PERC) umfassen, die von Dell EMC Inc. hergestellt wird. Speichersteuerungen können sich innerhalb eines Gehäuses oder einer anderen Einfassung als der eines Informationshandhabungssystems befinden, das sie steuern, wie beispielsweise eine Speichereinfassung, die eine oder mehrere physische Speicherressourcen einer gegebenen Speicheranordnung umfasst.
In bestimmten Ausführungsformen beinhaltet die Datenreplikation Prozesse, durch die Speicherdaten (z. B. Daten, die auf einer Datenspeichereinheit gespeichert sind) in ein entferntes oder lokales System dupliziert werden, um dabei zu helfen, eine verbesserte Redundanzebene bereitzustellen, falls ein Haupt- oder primäres Speichersicherungssystem ausfällt. In bestimmten Ausführungsformen kann ein Bild eine Kopie einer logischen Speichereinheit zu einem bestimmten Zeitpunkt sein. In bestimmten Ausführungsformen kann ein Klon eine Kopie oder ein Klon des Bilds oder der Bilder und/oder des Laufwerks oder der Laufwerke eines ersten Orts an einem zweiten Ort sein. In einigen Ausführungsformen kann ein Klon aus einem Satz von Objekten bestehen.
In bestimmten Ausführungsformen kann ein Datendienst ein Dienst zum Empfangen, Verarbeiten, Speichern und Schützen von Daten sein. In bestimmten Ausführungsformen stellen Datendienste die Datenverwaltungsfähigkeiten des Systems auf hoher Ebene bereit.
In bestimmten Ausführungsformen bezieht sich ein einzelner Mandant auf eine einzelne Instanz der Software und unterstützende Infrastruktur dient einem einzelnen Kunden. Mit einem einzelnen Abo hat jeder Kunde seine eigene unabhängige Datenbank und Instanz der Software. In bestimmten Ausführungsformen bezieht sich ein Mehrmandant auf eine Bedingung, unter der eine einzelne Instanz von Software und ihre unterstützende Infrastruktur mehreren Kunden dient. Jeder Kunde teilt die Softwareanwendung und teilt auch eine einzelne Datenbank. Die Daten jedes Mandanten sind isoliert und bleiben für andere Mandanten unsichtbar. In bestimmten Ausführungsformen stellt ein Mandant eine Organisation dar, die innerhalb eines Datenspeichersystems arbeitet. Mandanten können auch in einem System zum Zwecke der Sicherheitsisolierung erzeugt werden.
In bestimmten Ausführungsformen bezieht sich ein Speicherstapel auf einen software-definierten Speicher-(SDS)-Stapel, wobei SDS eine Speicherarchitektur ist, die eine Schicht von Software verwendet, um die physische Datenspeicherkapazität auf Industriestandardservern bereitzustellen, zu orchestrieren und zu verwalten. In bestimmten Ausführungsformen können SDS-Produkte hyperkonvergente Systeme sein, die als ein einzelnes Produkt entwickelt und unterstützt werden, das Server wie Dell EMC PowerEdge-Server nutzt, aber dies ist nicht einschränkend. SDI/SDS können die Automatisierung der Infrastrukturkonfiguration ermöglichen, was es ermöglichen kann, dass Lösungen schneller eingesetzt und schneller auf Echtzeitanwendungsanforderungen ausgerichtet werden.
In bestimmten Ausführungsformen sind physische Platten Platten, die für den Datendienstverbrauch verfügbar sind. Physische Platten können lokal an andere Geräte (z. B. einen Speicherstapel) angeschlossen werden, aber dies ist nicht für alle Arten von physischen Platten erforderlich, wie es von einem Fachmann auf dem Gebiet erkannt wird.
In bestimmten Ausführungsformen ist Cloud-Computing durch fünf Merkmale oder Qualitäten gekennzeichnet: (1) On-Demand-Self-Service; (2) breiter Netzwerkzugriff; (3) Ressourcen-Pooling; schnelle Elastizität oder Erweiterung; und (5) gemessener Dienst. In bestimmten Ausführungsformen enthält eine Cloud-Computing-Architektur Front-End- und Back-End-Komponenten. Cloud-Computing-Plattformen, die als Clients oder Cloud-Clients bezeichnet werden, können Server, Thick- oder Thin-Clients, Zero-(Ultra-Thin-)Clients, Tablets und mobile Geräte enthalten. Diese Client-Plattformen interagieren mit dem Cloud-Datenspeicher über eine Anwendung (Middleware), über einen Webbrowser oder durch eine virtuelle Sitzung. Beispielsweise ist das Front-End in einer Cloud-Architektur die sichtbare Schnittstelle, auf die Computerbenutzer oder Clients über ihre webfähigen Client-Geräte treffen. Eine Back-End-Plattform für die Cloud-Computing-Architektur kann physische Einzel-Mandant-Server (auch als „Bare-Metal“-Server bezeichnet), Datenspeichereinrichtungen, virtuelle Maschinen, einen Sicherheitsmechanismus und Dienste enthalten, die alle in Übereinstimmung mit einem Bereitstellungsmodell aufgebaut sind und alle gemeinsam für die Bereitstellung eines Dienstes verantwortlich sind.
Bei bestimmten Ausführungsformen ist Software as a Service (SaaS) eine Art von Cloud-Computing, das ein Software-Verteilungsmodell bereitstellt, in dem ein Drittanbieter Anwendungen hostet und sie über ein Netzwerk wie das Internet für Kunden verfügbar macht. Andere Arten von Cloud-Computing können Infrastruktur als Dienst (IaaS) und Plattform als Dienst (PaaS) enthalten.
Bei bestimmten Ausführungsformen ist ein natives Cloud-Ökosystem ein Cloud-System, das mit dem Container als die modulare Rechenabstraktion hocheingesetzt, elastisch und zusammensetzbar ist.
Kubernetes ist eine Open-Source-Container-Verwaltungsplattform, die eine tragbare, erweiterbare Open-Source-Plattform zum Verwalten von containerisierten Arbeitslasten und Diensten bereitstellt, die sowohl deklarative Konfiguration als auch Automatisierung ermöglicht. Kubernetes kann mindestens als Containerplattform, Mikrodienstplattform und tragbare Cloud-Plattform betrachtet werden. Kubernetes kann typischerweise Container wie Docker-Container laufen lassen. Zu diesem Zeitpunkt ist Kubernetes ein Open-Source-Projekt, das von der Cloud Native Computing Foundation (CNCF) aus San Francisco, Kalifornien, verwaltet wird.
Pivotal Cloud Foundry ist eine cloudagnostische Paas-Lösung und stellt eine Open-Source-Multi-Cloud-Anwendungsplattform als Dienst bereit. Zu diesem Zeitpunkt wird Pivotal Cloud Foundry von der Cloud Foundry Foundation aus San Francisco, Kalifornien, verwaltet.
In bestimmten Ausführungsformen sind Stapeldatendienste ein Satz von Datendiensten, die den Speicher verbrauchen. In bestimmten Ausführungsformen können einige Datendienste derzeit nicht mit anderen auf derselben Rechenvorrichtung koexistieren.
In bestimmten Ausführungsformen sind Stapelclientdienste ein Satz von Diensten, die Speicherfacetten für Anwendungen oder andere softwaredefinierte Speicherstapel dienen.
In bestimmten Ausführungsformen sind öffentliche Cloud-Dienste ein Satz von öffentlichen Angeboten, die verwendet werden, um kalte Daten auszulagern oder zusätzliche Archivierungskapazität bereitzustellen.
In bestimmten Ausführungsformen stellt eine softwaredefinierte Infrastruktur (SDI) Brain eine vereinheitlichte Verwaltung von softwaredefinierten Speicherkernkomponenten bereit.
In bestimmten Ausführungsformen beschreibt eine Orchestrierung eine automatisierte Anordnung, Koordination und Verwaltung von komplexen Computersystemen und Diensten. Eine Orchestrierung kann ein „Zusammenfügen“ von Software- und Hardwarekomponenten miteinander involvieren, um einen definierten Dienst bereitzustellen, oder ein Verbinden und Automatisieren von Arbeitsabläufen, wenn anwendbar, um einen definierten Dienst bereitzustellen. Im Bereich des Cloud-Computing kann eine Orchestrierung einen Arbeitsablauf enthalten und ist konfiguriert, um eine gerichtete Aktion in Richtung eines Ziels oder einer Zielsetzung bereitzustellen. Beispielsweise wird in bestimmten Ausführungsformen hierin eine Orchestrierung ausgeführt, um eine Zielsetzung zu erfüllen, wie z. B. das „Einsetzen spezifischer SDS-Dienste für einen spezifischen Server oder eine Reihe von Servern“, wobei das Erreichen dieser Orchestrierung durch Ausführen mehrerer Arbeitsabläufe (z. B. Aufgabensequenzen oder Sätze von Anweisungen) erfolgt, die jeweils bestimmte automatisierte Prozesse oder Arbeitsabläufe ausführen, um den Gesamteinsatz spezifischer SDS-Dienstziele zu erreichen (z. B. Arbeitsabläufe wie z. B. einen Arbeitsablauf oder eine Liste von Aufgaben zum Einsetzen eines Speicherstapels, eines Arbeitsablaufs oder einer Liste von Aufgaben zum Registrieren eines Hosts, eines Arbeitsablaufs oder einer Liste von Aufgaben zum Bereitstellen eines Stapelclients als Dienst usw.). Im Gegensatz dazu wird in bestimmten Ausführungsformen ein Arbeitsablauf im Allgemeinen als ein Prozess innerhalb einer einzelnen Domäne für Automatisierungszwecke verarbeitet und abgeschlossen.
Während anbieterspezifische Terminologie hierin verwendet werden kann, um das Verständnis zu erleichtern, versteht es sich, dass die Konzepte, Techniken und Strukturen, die hierin geschützt werden sollen, nicht auf die Verwendung mit spezifischen kommerziellen Produkten beschränkt sind. Darüber hinaus werden, um Klarheit in der Offenbarung sicherzustellen, wohlbekannte Verfahren, Prozeduren, Schaltungen, Komponenten und Produkte hierin nicht im Detail beschrieben.
Die Ausdrücke „wie“, „zum Beispiel“, „z.B.“, „beispielhaft“ und Varianten davon werden hier verwendet, um nicht-beschränkende Ausführungsformen zu beschreiben, und werden hier verwendet, um „als Beispiel, Ausprägung oder Illustration“ zu bedeuten. Alle hierin beschriebenen Ausführungsformen sind nicht unbedingt als bevorzugt oder vorteilhaft gegenüber anderen Ausführungsformen auszulegen und/oder um die Einbeziehung von Merkmalen in andere Ausführungsformen auszuschließen. Darüber hinaus wird das Wort „optional“ hierin verwendet, um zu bedeuten, dass ein Merkmal oder Prozess usw. in einigen Ausführungsformen bereitgestellt und in anderen Ausführungsformen nicht bereitgestellt wird. Jede Ausführungsform kann eine Vielzahl von „optionalen“ Merkmalen enthalten, sofern diese nicht im Widerspruch zueinander stehen.
Darüber hinaus versteht es sich in den folgenden Implementierungen, dass, obwohl viele spezifische Ausführungsformen bestimmte Marken und Namen von Produkten verwenden (z. B. Dell EMC-Produkte, Ansible, Microsoft und Amazon Cloud Services usw.), keine der hierin beschriebenen Ausführungsformen auf die Verwendung von Produkten von einem Anbieter beschränkt sein soll. Zumindest einige Ausführungsformen sollen vollständig hardwareunabhängig sein. In bestimmten Ausführungsformen können jedoch zusätzliche Merkmale (z. B. mehr Dinge, die automatisch bereitgestellt werden können, mehr Aktionen usw.) verfügbar sein, wenn bestimmte Anbieterprodukte verwendet werden, bei denen spezielle Kenntnisse darüber vorhanden sind, wie Vorteile und Eigenschaften des Produkts des Anbieters zu nutzen sind. Wenn beispielsweise in einer Ausführungsform Dell EMC PowerEdge-Server in Kombination mit Datendiensten und Clientdiensten auch von Dell EMC verwendet werden, kann eine SLO-basierte Bereitstellung (Dell EMC-Marke der Bereitstellung durch oder basierend auf Dienstebene) im Vergleich zu anderen Arten der Bereitstellung bereitgestellt werden. Ein Fachmann auf dem Gebiet erkennt verschiedene Vorteile, die basierend auf der Kenntnis bestimmter Hardwareeigenschaften erzielt werden können, gegenüber der Bereitstellung basierend auf „Waren“-Hardware, bei der spezielle Vorteile, Merkmale und Eigenschaften nicht bekannt sein können. Zusätzlich versteht es sich, dass die hierin beschriebenen Ausführungsformen innerhalb eines beliebigen Kundenökosystems funktionieren sollen, nicht nur der dargestellten Dell EMC-Ökosysteme.
Die IT-Abteilungen haben zunehmende Anforderungen, Speicheranforderungen zu berücksichtigen, die neue Anforderungen erfüllen, die mit herkömmlichen, speziell entwickelten Geräten nicht leicht erfüllt werden können. Die Entstehung von Edge- und Near-Edge-Arbeitslasten zusammen mit strengen IT-Budgets führt zu der Notwendigkeit flexibler softwaredefinierter Speicherlösungen. Diese Lösungen ermöglichen es dem Kunden, seine eigene Hardwareinfrastruktur basierend auf ihren Anforderungen unter Verwendung von Servern vom niedrigsten Bieter zu erstellen.
Trotz dieser und anderer bedeutender Fortschritte verbleiben wesentliche Hindernisse in bestimmten Informationsverarbeitungskontexten. Zum Beispiel kann es übermäßig schwierig sein, Datenanalysefunktionalität unter der aktuellen Praxis zu implementieren. Es kann auch schwierig sein, softwaredefinierte Speicheranlagen von mehreren Anbietern oder mehreren verschiedenen Arten von softwaredefiniertem Speicher (SDS) zu installieren, zu konfigurieren und einzusetzen. Somit sind Unternehmen, die Datenspeichersysteme, Informationsverarbeitungssysteme und dergleichen verkaufen, sehr damit befasst, Kunden mit einer effizienten Datenspeicherlösung zu versorgen, die Kosten minimiert, während sie Kundendatenspeicherbedürfnisse erfüllt. Es wäre für solche Unternehmen vorteilhaft, eine Möglichkeit zu haben, die Komplexität der Implementierung von Datenspeicher zu reduzieren.
Eine Barriere für die Datenspeicheroptimierung ist die Schwierigkeit, den verwendeten Speicher (z. B. verschiedene softwaredefinierte Speicherstapel) zusammen zu integrieren, insbesondere so, dass die integrierten Systeme automatisch zusammenarbeiten. Kunden fordern oft, dass SDS eine vereinheitlichte oder standardisierte Schnittstelle aufweist. Ein Grund, warum dieses Ziel zu erreichen schwierig ist, ist weil es oft einen Mangel an standardisierten Benutzerschnittstellen mit den verschiedenen Stapeln gibt. Zum Beispiel hat manchmal jeder softwaredefinierte Speicherstapel seinen eigenen Einsatzprozess und Installationsfußabdruck. Dies führt zu einer unsachgemäßen und inkonsistenten Ressourcennutzung. Darüber hinaus hat jeder softwaredefinierte Speicherstapel oft seine eigene Verwaltungsschnittstelle, obwohl viele SDS-Stapel Ressourcen auf ähnliche Weise verwalten können. Ferner kann jeder softwaredefinierte Speicherstapel seine Verbrauchsressourcen auf seine eigene Weise freilegen. Einige Stapel sind möglicherweise nicht Industriestandard oder mit anderen Stapeln konsistent. Infolgedessen können vorhandene softwaredefinierte Speicherstapel benutzerdefinierte Benutzer- und/oder Komponentenschnittstellen erfordern, was arbeits- und zeitintensiv ist - und somit kostspielig sein kann. Darüber hinaus bedeutet dies, dass ein gegebenes System nicht flexibel genug ist, um sich an sich ändernde Kundenbedürfnisse und neue oder aktualisierte Hardware-/Geschäftsanforderungen anzupassen und darauf zu reagieren.
Ein anderes Problem ist die Vielfalt von Speichertypen. Ein IT-Administrator möchte in der Lage sein, Anforderungen vieler verschiedener Speichertypen zu erfüllen: unter anderem Block, Dateifreigaben, Objekt und Streams. Jeder Speichertyp ist in seinem Protokoll, seinen Zugriffsmustern und seinen Leistungs- und Nutzungseigenschaften einzigartig. Somit erfordert jeder Speichertyp bestimmte Ressourcen und Konfiguration, um zu booten. Diese Vielfalt erzwingt schwere Installationsverpflichtungen und erhöht die Gesamtkosten für den Kunden.
Außerdem besteht ein Bedarf, dass ein IT-Administrator in der Lage sein muss, einen minimalen Hardwaresatz zu verwenden, um maximale Fähigkeiten bereitzustellen. Da verschiedene Speichertypen exklusiven Zugriff auf Hardwareressourcen benötigen, ist das effektive Ausgleichen der Ressourcen, um die Kapazität über alle Speichertypen mit minimalen Ressourcen zu maximieren, eine echte Herausforderung. Auch die kombinierte Nutzung ist ein Faktor. Einzelne Computerserver können mehr Hardware enthalten, als für einen einzelnen Speichertyp benötigt wird. Daher ermöglicht das Kombinieren von Speichertypen auf einem einzelnen Computerserver dem IT-Administrator weitere Flexibilität. Dies erfordert die Segregation von Rechenressourcen über einen Proxy, der die Reservierungsstrategien/- richtlinien der Speichertypen versteht.
Kunden verwenden Speicherstapel und andere Speicherressourcen auf eine gerätebasierte Weise, wobei die gekaufte Hardware oft in der Fabrik vorkonfiguriert ist, um sicherzustellen, dass Kunden nach der Lieferung schnell wieder einsatzbereit sind. In typischen Situationen kauft ein Kunde seine eigene Hardware, die er in Datenracks/- stapeln in seinem Datenzentrum unterbringt und verwendet eine Steuerebene oder andere Software, um anzufordern, dass die gekauften Systeme mit softwaredefiniertem Speicher eingesetzt werden, sodass Anwendungen entweder auf diesen Servern oder benachbart zu diesen Servern auf anderen Computern laufen können. Ein Problem bei dieser Anordnung ist, dass jedes einzelne Speichergerät seine eigene Art des Installierens und Speicherns mit verschiedenen Assistenten oder Skripten aufweist, um dem Benutzer zu helfen, aber die Schnittstellen, die alle unterschiedlich sind, können für Kunden schwierig und unbequem sein, insbesondere wenn die Installations-, Konfigurations- und Einsatzerfahrungen für jedes neue Gerät in einem System unterschiedlich sind.
Ein anderes Problem, das die Konfiguration und den Einsatz von Speichersystemen beeinflussen kann, ist die übrig gebliebene und/oder ungenutzte Kapazität. In vielen Systemen wird jeder Speicherstapel (beispielsweise Produkte von Dell EMC von Hopkinton, Massachusetts, wie EMC ECS, VxFlex OS, SDNAS, Nautilus und Produkte wie Dell EMC's Cloud Tiering Appliance und/oder Cloud Array sowie Produkte, die konfiguriert sind, um eine Fähigkeit zum Verschieben von Datenmobilität in Anordnungen bereitzustellen, anstatt sie in einem separaten Server oder Gerät zu haben) manuell installiert (unter Verwendung eines Installationsskripts/-assistenten oder Formular) und unter Verwendung einer Befehlszeilenschnittstelle (CLI) oder Benutzerschnittstelle (UI) für jedes jeweilige Produkt unter Verwendung vorgeschriebener Arbeitsblätter konfiguriert. Diese Praxis kann dazu führen, dass Speicher- und/oder Rechnerkapazitäten ungenutzt bleiben.
Eine Lösung, die in der Branche ausprobiert wurde, um die Einfachheit der Installation und Konfiguration von Hardware zu verbessern, ist das CEPH-Speicherprodukt von Red Hat Software aus Raleigh, North Carolina. CEPH stellt eine einzelne definierte Open-Stack-SDS-Plattform bereit, die für einige kleinere Installationen hilfreich sein kann. Kunden suchen jedoch immer noch eine Lösung auf Unternehmensebene, die mindestens die Merkmale von CEPH sowie zusätzliche Merkmale und Vorteile bereitstellt.
In bestimmten hierin beschriebenen Ausführungsformen wird die Erfahrung der Installation, Konfiguration und des Einsatzes neuer hardware- und softwaredefinierter Speicher sowohl für ein Rechenzentrum als auch für die Cloud verbessert und vereinheitlicht. In bestimmten Ausführungsformen wird eine Konfiguration bereitgestellt, die eine Softwaresuite beinhaltet, die eine einheitliche Speicherverwaltung über alle softwaredefinierten Speicheranlagen hinweg bereitstellen kann, verstehen kann, was zum Einsatz und zur Verkabelung erforderlich ist, um eine Speicheranforderung zu bedienen, und softwaredefinierte Speicherstapel als Ergebnis von prädiktiver Analyse, Richtlinie und Verwendung auf Anforderung des IT-Administrators hoch- oder herunterfahren kann.
Bei einer bestimmten Ausführungsform können Kunden auch die Betriebskosten senken, wenn Kunden auf eine einzelne Verwaltungszone um die SDS zugreifen können, die verfügbar ist, um ein einfach zu implementierendes und zu verwaltendes Angebot zu haben, das in ein modernes cloudnatives Ökosystem (z. B. Pivotal Cloud Foundry - Pivotal Container Service auf Basis von Kubernetes (PCF-PKS)) gleitet, wodurch der Bedarf an teuren Hardware-Geräten oder virtuellen „Ressourcensuch“-Anwendungen („vApps“) vermieden wird. PCV-PKS ist ein System, das den Einsatz und den Verbrauch von Containerdiensten mit „Produktionsgrad“-Kubernetes ermöglicht. Kubernetes stellt, wie zuvor angemerkt, ein Open-Source-Container-Orchestrierungssystem zum Automatisieren des Einsatzes, der Skalierung und Verwaltung von containerisierten Anwendungen über Cluster von Hosts hinweg bereit.
Bestimmte hierin beschriebene Ausführungsformen sind in der Lage, diesen Bedarf zumindest teilweise zu erfüllen. Bei bestimmten hierin beschriebenen Ausführungsformen wird ein Mechanismus identifiziert, durch den mehrere Speichertypen (Block, Datei, Objekt und Stream) durch eine einzelne Verwaltungs- und Orchestrierungsebene installiert, konfiguriert, verbraucht und verwaltet werden können, die die Anforderungen jedes Speichertyps versteht und Richtlinien auf Hardwareinventar anwendet, um softwaredefinierten Speicher auf Unternehmensebene auf Warenanlagen auszurollen.
In bestimmten Ausführungsformen wird eine Anordnung bereitgestellt, die konfiguriert ist zum:

• Übergeben eines Mechanismus an einen IT-Administrator, um die Server zu identifizieren, die sie für softwaredefinierten Speicherverbrauch verwenden möchten;
• Ermöglichen, dass ein IT-Administrator aus einer Vielzahl von Speichertypen und sogar Profilen innerhalb jedes Speichers einsetzen kann;
• Automatisieren der Installation der softwaredefinierten Speicherstapelkomponenten, wie beispielsweise Speicherserversoftware (Servertreiber), Datenpfadsoftware (Clienttreiber) und Verwaltungssoftware für jeden Speichertyp;
• Automatisierten der Konfiguration der softwaredefinierten Speicherstapelkomponenten, um die Berührungspunkte zu reduzieren, die vom IT-Administrator erforderlich sind.
• Aussetzen von Verbrauchsschnittstellen (APIs, SDKs oder Industriestandard-Enabler-Plug-Ins) für den IT-Administrator oder andere geeignete Entitäten, um den Verbrauch des Speichers zu beschleunigen;
• Überwachen des Speichers auf Warnungen und andere umsetzbare Informationen;
• Automatisieren der Verwaltung von Speicherstapeln, um Expansions-, Kontraktions- oder Wartungsvorgänge zu ermöglichen;

In mindestens einigen Ausführungsformen stellen die hierin beschriebenen Anordnungen mindestens diese vorteilhaften Merkmale bereit:

• Einen vereinheitlichten Mechanismus/eine vereinheitlichte Plattform für softwaredefinierte Speicheranlagen.
• Automatisierte/unbeaufsichtigte Installation und Einsatz von Speicherstapeln basierend auf einer Richtlinie im Vergleich zu verfügbarem Inventar.
• Ein hyperkonvergentes Speicherstapel-Ökosystem (mehrere Stapel auf einem einzelnen Server).

Es wird erwartet, dass die hierin beschriebenen Ausführungsformen mit mindestens den folgenden Technologien verwendbar sind:

• Dell EMC Elastic Cloud Storage (ECS); Dell EMC VXFLEX OS; Software Defined Network Attached Storage (SDNAS); Dell EMC NAUTILUS (eine proprietäre softwaredefinierte Lösung zum Speichern und Analysieren hoher Volumina von Streaming-Internet-of-Things- (IoT-) Daten in Echtzeit); Glider und Speicherstapel, die spezifischen Speichermerkmalen, Protokollen oder „Speichertypen“ (Block, Datei, Objekt, Stream) entsprechen.
• Ansible: Ein Allzweck-IT-Orchestrierungstool, das leicht eingebettet werden kann, um die Orchestrierung der Installation, Konfiguration und Verwaltung der obigen Speicherstapel zu ermöglichen; Ansible ist eine Open-Source-Automatisierungsplattform, die in der Lage ist, bei der Konfigurationsverwaltung, Anwendungseinsatz, Aufgabenautomatisierung zu helfen. Und IT-Orchestrierung (z. B. wenn es erforderlich ist, Aufgaben nacheinander auszuführen und eine Kette von Ereignissen zu erzeugen, die auf mehreren verschiedenen Servern oder Geräten stattfinden müssen).
• Installationsdienstprogramme, wie beispielsweise Dell EMC Installationsdienstprogramme.

Es gibt bekannte Wege, verschiedene Arten von Speicherstapeln zu installieren und zu konfigurieren (einschließlich, aber nicht beschränkt auf den vorgenannten Dell EMC Elastic Cloud Storage (ECS); Dell EMC VXFLEX OS, SDNAS und Dell EMC NAUTILUS). Beispielsweise wird in einigen Fällen jeder Speicherstapel manuell installiert (unter Verwendung eines Installationsskripts/-assistenten oder einem Formular) und unter Verwendung einer Befehlszeilenschnittstelle (CLI) oder Benutzerschnittstelle (UI) für jedes jeweilige Produkt konfiguriert. Die Erfahrung jedes Produkts ist anders und weit davon entfernt, vereinheitlicht zu sein. Die unterschiedliche Erfahrung bedeutet auch, dass Benutzer nicht in der Lage sind, zu versuchen, einen Server manuell zwischen Speicherstapeln zu „teilen“.
In bestimmten Ausführungsformen, wie hierin beschrieben, werden diese Probleme zumindest teilweise über ein einziges Verfahren zum Automatisieren der Installation, Konfiguration und des Einsatzes aller Arten von Speicherstapeln über eine vereinheitlichte Schnittstelle angesprochen. Bestimmte Ausführungsformen hierin sind in der Lage, die Fähigkeit für Software auf konsolidierte Weise zu beschreiben und zu schützen, um in der Lage zu sein, viele verschiedene Arten von softwaredefinierten Speicher-(SDS)-Anlagen zu steuern, zu verwalten, einzusetzen, zu lösen und zu konfigurieren. Bestimmte hierin beschriebene Ausführungsformen sind konfiguriert, um DELL EMC softwaredefinierte Speicher-(SDS)-Anlagen zu steuern, zu verwalten, einzusetzen und zu konfigurieren, einschließlich, aber nicht beschränkt auf DELL EMC SCALE 10, DELL EMC VCX OS, Speicher, der über Container Storage Interface (CSI) verbunden ist, eine Kubernetes-basierte dynamische Open-Source-Container-Speicherbereitstellungsumgebung, an die Entwickler persistente Volumenansprüche für eine bestimmte Dienstklasse ausgeben können, wobei diese dann Kubernetes präsentiert werden), gerätebasierten CSI-Speicher wie Dell EMC PowerMax und Unity, softwaredefinierten ECS oder Objektspeichern, ECS flex, DELL EMC ISILON FLEX und ISILON SOFTWARE DEFINED (wobei DELL EMC ISILON eine Art von netzwerkgebundenen Scale-Out-Speichersystemen ist, die für anspruchsvolle Unternehmensdateiarbeitslasten konzipiert sind) und praktisch jede Art von Datensystem oder Informationssystem in Bezug auf Datenschutz, einschließlich, aber nicht beschränkt auf Produkte wie DELL EMC DATA DOMAIN VIRTUAL EDITION. Die Bezugnahme hierin auf spezifische Produkte von DELL EMC soll beispielhaft und nicht einschränkend sein. Der Fachmann auf dem Gebiet erkennt die Anwendbarkeit der hierin beschriebenen Ausführungsformen auf Speicheranlagen usw. von vielen verschiedenen Lieferanten.
Ferner haben bestimmte hierin beschriebene Ausführungsformen Anwendbarkeit in einer Vielzahl von Verwendungskategorien, einschließlich, aber nicht beschränkt auf, Serverfabrikinstallation, Serververwaltungsinstallation, Serververwaltung, Diensteinsatzverwaltung, „Pflege- und Bereitstellung“-Dienst und Dienstnutzung.
Bei der Serverfabrikinstallation können in einer beispielhaften Ausführungsform Server von einem Anbieter, wie beispielsweise DELL EMC PowerEdge-Server, mit einem Basisbetriebssystem (OS) und erforderlicher Software vorinstalliert sein, um die Teilnahme am softwaredefinierten Speichersuiten-(SDSS)-Ökosystem zu beschleunigen. Mit einer Serververwaltungsinstallation ermöglichen die hierin beschriebenen Ausführungsformen den Einsatz eines SDSS-Ökosystems in einer cloudnativen Infrastruktur eines Kunden. Mit einer Serververwaltungsverwendung sind bestimmte hierin beschriebene Ausführungsformen in der Lage, eine vollständige Verwaltungsfähigkeit bereitzustellen, einschließlich der schnellen Identifizierung von Servern zur Verwendung durch die Suite (SDSS), Hinzufügen eines Servers oder einer Reihe von Servern zur Verwendung durch die SDSS, Entfernen, Ersetzen oder Aufrüsten von Servern, nicht störend, zur Verwendung durch die SDSS und Überwachen der Gesundheit des Servers. Zusätzlich versteht es sich, dass in dieser Offenbarung die Begriffe softwaredefiniertes Speichersystem (SDSS), softwaredefinierte Schnittstelle (SDI) Brain und VIKI alle austauschbar verwendet werden.
Für die Diensteinsatzverwaltung setzen bestimmte hierin beschriebene Ausführungsformen bestimmte softwaredefinierte Speicherdienste auf einem bestimmten Server oder einer Reihe von Servern ein, konfigurieren die anfänglichen Eigenschaften oder Einschränkungen, die jeder Dienst verbrauchen darf, und/oder entfernen oder verschieben softwaredefinierte Dienste von einem Server. Für den „Pflege- und Bereitstellung“-Dienst überwachen bestimmte hierin beschriebene Ausführungsformen die Gesundheit und Kapazität von softwaredefinierten Diensten auf einem Server oder einer Gruppe von Servern, informieren Benutzer oder andere Instanzen über Ausfälle oder potenzielle Ausfälle der Dienste unter Verwendung der vorhandenen Berichts- und Überwachungssysteme des Benutzers, prognostizieren Dienstengpässe und stellen (halb-)automatisierte Wiederherstellung oder Erweiterung erforderlicher Datendienste bereit, um innerhalb von SLAs zu bleiben. Für die Dienstnutzung erstellen, erweitern und entfernen bestimmte hierin beschriebene Ausführungsformen Volumes, Shares, Buckets, Streams oder Schutz unter Verwendung von Industriestandardspezifikationen.
In bestimmten Ausführungsformen werden Konfigurationen bereitgestellt, die vorteilhafterweise eines oder mehrere der folgenden Merkmale bereitstellen:

• Mehrere Dienste auf einer gemeinsam genutzten Infrastruktur einsetzen
• Dienste für viele Mandanten bereitstellen.
• Elastisch skalierte Plattform und Dienste
• Kapazität zwischen Diensten flexibel verschieben
• Betriebskonsistenz über Dienste hinweg bereitstellen
• Sichtbarkeit für Betreiber und Kontobenutzer bereitstellen

1 ist ein veranschaulichendes Funktionsdiagramm 100 einer Verwaltungs- und Orchestrierungsebene (M&O) 102 (hierin auch als eine Schicht bezeichnet), die auf hoher Ebene eine beispielhafte softwaredefinierte Speicherplattform gemäß mindestens einer veranschaulichenden Ausführungsform der Offenbarung einkapselt. 1 stellt eine Verwaltungsebene 102 dar, die im vorhandenen cloudnativen Ökosystem des Kunden läuft, das die verschiedenen Speicherstapel 106 -120 (weiter unten erörtert) installiert, konfiguriert und verwaltet. Im beispielhaften Diagramm 100 von 1 wird das M&O (das in bestimmten Ausführungsformen auch als eine Steuerung oder ein „Gehirn“ für das System bezeichnet wird) als Teil eines Cloud-Computing-Ökosystems gezeigt (z.B. indem es Teil von Kubernetes oder PCF ist, wie in 1 gezeigt). Die M&O-Ebene 102 steht in betriebsfähiger Kommunikation mit einer Vielzahl von potenziellen softwaredefinierten Speicherstapeln, die in Verbindung mit dem Cloud-Computing-Ökosystem verwendet werden können. Im Beispiel von 1 umfassen diese Speicherstapel einen softwaredefinierten (SD-) Block 106, einen softwaredefinierten Network-Attached-Storage- (SDNAS-) Block 108, ein Cloud-Gateway 110, eine Benutzer-App 112, eine DELL EMC DATA DOMAIN virtuelle Edition 114, einen DELL EMC Elastic Cloud Storage (ECS) 116, DELL EMC NAUTILUS 118 und DELL EMC ISILON 120.
In 1 stehen der SD-Block 106, das SDNAS 108, das Cloud-Gateway 110, die Benutzer-App 112 und das DDve 114 alle in betriebsfähiger Kommunikation mit dem DELL EMC VxFlex OS 104. Es ist zu beachten, dass das „OS“ in „VxFlex OS“ Teil des Produktnamens dieses beispielhaften Produkts ist, das früher als Dell EMC ScaleIO bekannt war; das „OS“ steht nicht für „Betriebssystem“). Das VxFlex OS 104 stellt einen breit skalierten, leistungsstarken und grundlegenden Speicher bereit. VxFlex OS ist ein softwaredefiniertes Speicherprodukt, das ein serverbasiertes Speicherbereichsnetzwerk (SAN) aus lokalem Anwendungsserverspeicher unter Verwendung vorhandener Kundenhardware- oder EMC-Server erstellt. VxFlex OS wandelt in bestimmten Aspekten direkt angeschlossenen Speicher in geteilten Blockspeicher um. VxFlex OS konvergiert in bestimmten Ausführungsformen Rechenressourcen und Warenspeicher in eine Einzelschichtarchitektur. VxFlex OS kann nur als Speicher oder als konvergierte Infrastruktur eingesetzt werden, die Speicher-, Rechen- und Netzwerkressourcen in einem einzigen Block kombiniert. Kapazität und Leistung aller verfügbaren Ressourcen werden aggregiert und jedem teilnehmenden VxFlex OS-Server und -Anwendung zur Verfügung gestellt. Speicherebenen können mit Medientypen und Laufwerkstypen erstellt werden, die den idealen Leistungs- oder Kapazitätseigenschaften entsprechen, um den Anwendungsanforderungen am besten zu entsprechen.
Der SD-Block 106 stellt erweiterte Blockdatendienste, Datenreduktion, Momentaufnahmen, Replikation, Abstufung, D@RE (Dell EMC Unity Data at Rest Encryption (D@RE) und Multi-Mandantenfähigkeit bereit. Der SDNAS-Block 108 stellt einen Mehrmandanten-NAS bereit. Das Cloud-Gateway 110 ist eine Verbindung zu externen Cloud-Diensten 109 wie Amazon Web Services, Microsoft Azure und Web Stream (diese sind veranschaulichend und nicht einschränkend). Die Benutzer-App 112 stellt mehrere Benutzeranwendungen dar, die in dieser Anordnung verwendbar sind, einschließlich, aber nicht beschränkt auf NoSQL DBs, Grafik-DBs, Stream-Prozessoren, Map Reduce, Elastic Search und Traditional Apps. Das DDve 114 stellt, wie oben erwähnt, eine Verbindung zum Unternehmensdatenschutz bereit und kann auch mit den Cloud-Diensten 109 verwendet werden. Amazon Cloud Services. In bestimmten Ausführungsformen wird das ECS SD 116 mit Objekten verwendet, Nautilus 118 wird zur Speicherung von Streams verwendet und Isilion 120 wird mit großskalierten NAS verwendet. In bestimmten Ausführungsformen ist ein softwaredefinierter (SD) NAS, ein Typ von Hochleistungs-NAS, ein anderer verwendbarer Datendienst.
In mindestens einer Ausführungsform kann das System 100 von 1 unter Verwendung eines DELL EMC POWEREDGE Blade-Servers und von Diensten implementiert werden, die containerisierte Software entweder eines M&O 102 des softwaredefinierten Speicherstapels (SDSSo (d. h. der Speicherstapel von 1) oder Speicherstapel-Datenpfaddienste einschließen können. Es versteht sich jedoch, dass die Ausführungsformen hierin nicht auf PowerEdge-Server für einen beliebigen Aspekt beschränkt sind, einschließlich, aber nicht beschränkt auf, das M&O 102 oder den Speicherstapeleinsatz selbst; vorteilhafterweise ist das M&O 102 in bestimmten Ausführungsformen hardwareunabhängig.
2 ist ein veranschaulichendes Diagramm 200, das zeigt, wie mehrere Datendienste (z. B. eine Anwendung 112, das VxFlex OS 104, der SD-Block 106, das SDNAS 108, das DDve 114, das Cloud-Gateway 116, das ECS, Nautilus, Isilion) zusammen auf Servern 202 koexistieren, in einem beispielhaften System, einschließlich Anwendungen, die Kunden ausführen, gemäß einer veranschaulichenden Ausführungsform. Zum Beispiel enthält der ganz rechte Server, das obere Rack sieben Datendienste, einschließlich vier Anwendungen 112 (durch den Buchstaben „A“ gekennzeichnet), ein VxFlex OS 104 (durch den Buchstaben „S“ gekennzeichnet), einen SD-Block 106 (durch den Buchstaben „C“ gekennzeichnet) und ein SDNAS 108 (durch den Buchstaben „N“ gekennzeichnet). Der Fachmann auf dem Gebiet erkennt, dass die anderen Racks in den Servern unter Verwendung der Buchstabencodes in der Figur ähnlich interpretiert werden können. Vorteilhafterweise stellt die M&O-Steuerebene 102, wie hierin weiter beschrieben, eine vereinheitlichte Verwaltungsschnittstelle zum Konfigurieren, Einsetzen, Bereitstellen, Verwalten usw. über alle diese speicherdefinierten Anlagen hinweg bereit. Die M&O-Ebene handhabt Verwaltung, Orchestrierung, Einsatz, Konfiguration und Registrierung.
3 ist ein vereinfachtes Diagramm einer Architektur 300, die eine softwaredefinierte Speichersuite gemäß einer veranschaulichenden Ausführungsform implementiert. 4 ist ein detaillierteres Diagramm 400 der in 3 gezeigten Architektur gemäß einer veranschaulichenden Ausführungsform. 3 und 4 stellen dieselbe Architektur, jedoch in unterschiedlichen Detailebenen dar. 4 stellt auch im Detail in den Abschnittsstapel-Datendiensten 324 (weiter unten beschrieben) eine Vielzahl verschiedener Arten von Stapeln dar, z. B. DELL EMC Nautilus, SDNAS, DELL EMC VxFlex OS (hierin auch als SIO bezeichnet) usw., sowie Cloud-Datendienste, und wie der Fachmann auf dem Gebiet erkennen wird, könnte es auch andere Arten von Speicherstapeln von verschiedenen Anbietern geben. Wie der Fachmann auf dem Gebiet erkennen wird, kann jeder Stapeltyp (einschließlich der Cloud-Datenschnittstellen) seine eigene proprietäre Verwaltungsschnittstelle und Verwaltungssoftware aufweisen, die „unterhalb“ dieser proprietären Verwaltungsschnittstelle ausgeführt wird. Für Benutzer (die nicht nur IT-Personal, sondern auch nicht-menschliche Entitäten wie Steuerungen, Prozessoren, Rechensysteme, Anwendungen enthalten), die diese Stapelressourcen steuern, verwalten, einsetzen, bereitstellen, konfigurieren usw. wollen, kann dies kompliziert, zeitaufwändig und kostspielig sein. Jedes Produkt kann seine eigenen einzigartigen Anforderungen haben, um diese Aufgaben mit seinen eigenen Assistenten oder Skripten zu erfüllen, was die Belastung für Benutzer/Clients erhöht, die verschiedene Installations- und Konfigurationstechniken für jedes System lernen und verwenden müssen. Eine Möglichkeit, zumindest einige der hierin beschriebenen Ausführungsformen, hilft, dieses Problem zu lösen, besteht darin, Möglichkeiten bereitzustellen, um die Erfahrung des Steuerns, Verwaltens, Einsetzens, Bereitstellens und Konfigurierens von Speicheranlagen (insbesondere softwaredefinierten Speicheranlagen) wie den Stapeldatendiensten zu vereinheitlichen und zu automatisieren. Gemäß mindestens einigen Ausführungsformen, die hierin weiter beschrieben werden, werden Systeme, Verfahren und Geräte bereitgestellt, um eine Architektur mit einer Steuerebene bereitzustellen, die konfiguriert ist, um die Erfahrung für den Benutzer zu vereinheitlichen. Dies wird hierin weiter beschrieben.
Unter Bezugnahme auf 3 und 4 beinhalten die Architekturen 300 von 3 und 400 von 4 jeweils eine softwaredefinierte Speicherverwaltungs- und Orchestrierungsebene (M&O) 102 (hierin auch als eine Schicht 102 bezeichnet), wie oben erwähnt, die mit einem Oberflächenbereich 302 und einer Mehrzahl von Speicherstapeln 306 interagiert. Es ist auch zu beachten, dass die M&O-Steuerebene 102 von Fig. 300 explizit zeigt, dass das Element „Stapelverwaltungsdienste 302“ (weiter unten erörtert) außerhalb der M&O-Steuerebene 102 liegt; diese Konfiguration ist ebenfalls auch in 4 anwendbar, jedoch macht dies die in 4 gezeigte Detailebene nicht so einfach zu sehen.
In der beispielhaften Architektur von 3 und 4 beinhalten die Speicherstapel 306 unter Berücksichtigung dieser Architekturen, die von unten nach oben beginnen, Stapel-Client-Dienste 332, Stapeldatendienste 334, eine Vielzahl von physischen Platten 336a -336c, Unterstützung 338 und einen oder mehrere öffentliche Cloud-Dienste 340. Im Allgemeinen werden die Speicherstapel 306 in bestimmten Ausführungsformen unter Verwendung vorhandener softwaredefinierter Speicherstapel implementiert. Die physischen Platten 336 beinhalten einen Satz von (normalerweise lokal angeschlossenen) physischen Platten, die für den Datendienstverbrauch verfügbar sind.
Die Stapeldatendienste 334 stellen einen Satz von Datendiensten zum Verbrauchen des Speichers bereit. Wie der Fachmann auf dem Gebiet erkennt, können einige Datendienste derzeit nicht mit anderen auf derselben Rechenvorrichtung koexistieren, und in bestimmten Ausführungsformen müssen diese Datendienste nicht auf derselben Rechenvorrichtung koexistieren. Die Stapelclientdienste 322 stellen einen Satz von Diensten bereit, die Speicherfacetten für Anwendungen oder andere softwaredefinierte Speicherstapel dienen (Schichtungen/Abhängigkeiten voneinander sind in den 3 oder 4 nicht gezeigt).
In bestimmten Ausführungsformen beinhalten diese öffentlichen Cloud-Dienste 340, sind aber nicht beschränkt auf einen Satz von öffentlichen Angeboten, die verwendet werden, um kalte Daten auszulagern oder zusätzliche Archivierungskapazität bereitzustellen; in bestimmten Ausführungsformen ist es möglich, eine gesamte Arbeitslast von Daten in die öffentlichen Cloud-Dienste 340 oder ein anderes Rechenzentrum zu verschieben. Wie in 4 gezeigt, können diese in einer beispielhaften Ausführungsform öffentliche Cloud-Dienste 340 beinhalten (einschließlich, aber nicht beschränkt auf Amazon Web Services (AWS), Virtustream und Microsoft Azure, die als öffentliche Cloud-Dienste 340 verwendet werden können). Die Unterstützung 338 kann jede Art von Unterstützung beinhalten, die für die M&O-Ebene 102 verwendbar ist. In bestimmten Ausführungsformen ist die Unterstützung 228 DELL EMC-Unterstützung, wie beispielsweise Secure Remote Services (SRS)-Call-Home unterstützung für M&O. In bestimmten Ausführungsformen pflegen Dienste wie SRS ein Inventar an Kundenanlagen; somit kann in bestimmten Ausführungsformen diese Dell Unterstützung 338 auch genutzt werden, um den Inventardienst 402 in der M&O-Ebene 102 zu füllen, indem sie dabei helfen, zu überprüfen, welche Speicherstapel „gesund“ oder zumindest frei von Problemen sind, die die gewünschte Leistung beeinträchtigen. Dies kann für Benutzer bequemer sein, da es die Notwendigkeit entfernen kann, manuell Eingabeinformationen bereitzustellen.
Die Stapelverwaltungsdienste 330 sind Dienste, die Verwaltung (Steuerpfad) der bereits vorhandenen Speicherstapel durchführen. Vorteilhafterweise können die Stapelverwaltungsdienste 330 auf den cloudnativen Cluster angehoben werden, wenn dies nicht bereits ermöglicht ist. In bestimmten Ausführungsformen sind die Stapelverwaltungsdienste 330 so konfiguriert, dass sie „steckbar“ sind, was bedeutet, dass ihre erweiterten Funktionen und sich ändernde Funktionalität durch das Plug-In gesteuert werden können und automatisch in der M&O-Ebene ohne zusätzliche Anpassung durch die vereinheitlichten Dienste widergespiegelt werden können. Wie in 4 gezeigt, beinhalten die Stapelverwaltungsdienste 330 eine Vielzahl von Verwaltungsdiensten (z. B. die mit „ECS-Mgmt.“, „SD-Block-Mgmt.“, „DDve-Mgmt.“ usw.), die den bestimmten Stapeldatendiensten 334 entsprechen/übereinstimmen.
Die M&O-Ebene 102 wird hierin auch als die softwaredefinierte Schnittstelle (SDI) „Gehirn“ bezeichnet und stellt in bestimmten Ausführungsformen eine vereinheitlichte Verwaltung von softwaredefinierten Speicherkernkomponenten bereit. Wie in 4 gezeigt, beinhaltet die M&O-Ebene 102 in bestimmten Ausführungsformen ein cloudnatives Ökosystem 323, wie Kubernetes/Pivotal Cloud Foundry, die eine außergewöhnliche Scale-out-Konfiguration, Verwaltungsfähigkeit bereitstellen. In bestimmten Ausführungsformen wird davon ausgegangen, dass ein Benutzer/Kunde, der die Architektur von 3 und/oder 4 verwendet, bereits ein cloudnatives Ökosystem in seiner privaten Cloud hat.. In bestimmten Ausführungsformen sind die Serververwaltungsdienste 322 ein Satz von Open-Source-Tools, die verwendet werden, um Installation, Einsatz und Konfiguration der softwaredefinierten Speicherstapel 306 durchzuführen.
Der vereinheitlichte softwaredefinierte Verwaltungsdienst 304 ist ein Satz von Diensten, die die Server und Dienste unter Verwaltung verstehen und es dem Benutzer ermöglichen, eine beliebige Richtlinie um Einsätze zu erzeugen und zu speichern. Die vereinheitlichten softwaredefinierten Verwaltungsdienste 304 speichern und wenden auch Konfigurationsvorlagen auf Speicherstapel an, um Konfigurationen angesichts der eingesetzten Hardware am besten zu praktizieren.
Die Überwachungs- und Berichts- (M&R) Komponente 321 ist ein externes M&R-Angebot, das in die vereinheitlichten softwaredefinierten Verwaltungsdienste integriert ist, um eine Dashboard-Benachrichtigung über Server- oder Dienstfehler bereitzustellen, sowie um es der Plattform zu ermöglichen, eine elastische Expansion bestimmter Stapel in Abhängigkeit von der Richtlinie und Warnungen von M&R durchzuführen (dies wird hierin weiter erörtert). In bestimmten Ausführungsformen ist ein Produkt, das konfiguriert ist, um es einem Benutzer zu ermöglichen, eine gegebene Speicherumgebung aus einer beliebigen Perspektive zu überwachen, zu analysieren und zu beheben, wie beispielsweise DELL EMC CLOUDIQ, in bestimmten Ausführungsformen verwendbar, um diesen Aspekt der Ausführungsform zu implementieren.
Die Verwaltungs-REST- (Representational State Transfer) Endpunkte 316 werden durch REST-Endpunkte freigelegt. In bestimmten Ausführungsformen erfordern die Verwaltungs-REST-Endpunkte 316 die Einhaltung der Industriestandardspezifikation. In bestimmten Ausführungsformen stellt die Oberflächenbereichsschicht 302 ausschließlich die gewünschten Berührungspunkte bereit.
Die Oberflächenbereichsebene oder -schicht 302 beinhaltet Enabler 308, Software-Entwickler-Kits (SDKs) 310, Playbooks 312 und Benutzerschnittstellen 314. Der Oberflächenbereich 302 stellt dar, wie die SDI-Brain-323-Fähigkeiten dem Verbraucher ausgesetzt sind.. Es versteht sich, dass in dieser Offenbarung die Begriffe softwaredefiniertes Speichersystem (SDSS), softwaredefinierte Schnittstelle (SDI) Brain und VIKI alle austauschbar verwendet werden. In bestimmten Ausführungsformen ist es vorteilhaft, wenn der Oberflächenbereich 302 „vorverpackte“ Industriestandard-SDKs und Enabler beinhaltet.
Die Benutzerschnittstellen (UI) 314 können in verschiedenen Ausführungsformen auf verschiedene Weise implementiert werden. In einer Ausführungsform ist die UI 314 eine native UI, die direkt durch die SDI-Brain-Verwaltungs-REST-Endpunkte 316 kommuniziert (in diesem Fall würde ein Portaldienst zu den vereinheitlichten softwaredefinierten Verwaltungsdiensten 304 des SDI-Brains hinzugefügt). In einer Ausführungsform ist die UI 3114 eine webbasierte grafische Schnittstelle, auf die Cloud-Administratoren und Benutzer zugreifen können, um Rechen-, Speicher- und Netzwerkdienste zu verwalten, wie die OpenStack Horizonbasierte UI (die in bestimmten Ausführungsformen mit der Existenz eines OpenStack-Kern-Plug-Ins plus eines Horizon-Plug-Ins an anderer Stelle im System 400 fortfahren).
Die Verwaltungs-REST-Endpunkte 316 von 3 und 4 beinhalten in bestimmten Ausführungsformen einen Satz von Plattform-REST-Endpunkten, die weiter unten in Verbindung mit 5, 7 und 8 erörtert werden. 5 ist ein Diagramm 500, das Steuerungsdienste für die Architektur zeigt, die im detaillierten Diagramm von 4 gemäß einer veranschaulichenden Ausführungsform der Offenbarung gezeigt ist.
5 beinhaltet Plattform-REST-Endpunkte 502, native Dienste 504, einen Stapeleinsatzanforderungsabbilder 605, eine Stapelkoordinatororchestrierungskomponente 508, eine Rechensteuerung 509, Open-Source-Dienste 510, DELL EMC-Dienste 512 (die nicht der Unterstützung 328 von 3 und 4 gleichen), ein API-Gateway 514, einen Lastverteiler 516, einen Plattformkonfigurationsverwaltungsdienst 518, einen Aufgabendienst 520, eine Arbeitsablaufausführungssteuerung 522, eine Ansible-Bibliothek 524, eine Verbrauchssteuerung 526, einen Verbrauchsanforderungsabbilder 528, eine Platzierungsanalyse 530 und eine Stapelbereitstellungsorchestrierungssteuerung 532. Diese werden nachstehend weiter beschrieben.
VIKI-Plattformdienste laufen in 5 in einer vorhandenen cloudnativen Umgebung eines Kunden wie der Kubernetes-Cloud-Umgebung 323. Es versteht sich, dass in dieser Offenbarung die Begriffe softwaredefiniertes Speichersystem (SDSS), softwaredefinierte Schnittstelle (SDI) Brain und VIKI alle austauschbar verwendet werden. VIKI wird für viele Knoten für hohe Verfügbarkeit eingesetzt und Dienstorchestrierung wird durch Helm-Diagramme erreicht, die verwendet werden können, um das Verpacken und Einsetzen gemeinsamer Anwendungen auf Kubernetes zu vereinfachen. Anforderungen an die Plattform werden von mehreren Diensten bedient, die unabhängig ablaufen. Das API-Gateway 514 multiplext den eingehenden Uniform Resource Locator (URL) an den Dienst, der diese Anforderung in der Plattform bedienen kann. In bestimmten Ausführungsformen können mehrere desselben Diensts innerhalb des cloudnativen Ökosystems 323 vorhanden sein. Ein Lastausgleicher 516 wie NGINX verteilt die Anforderungslast über die Anforderungslasten hinweg (relativ) gleichmäßig.
Die nativen Dienste 504 sind in bestimmten Ausführungsformen alle Dienste, die von der VIKI-Plattform implementiert werden, mit Ausnahme von AWX.
Die Rechensteuerung 509 legt REST-Schnittstellen frei, die Server zum Inventar hinzufügen. Dieses Inventar wird verwendet, um softwaredefinierte Speicherstapel einzusetzen und zu installieren.
Die Stapeleinsatzorchestrierungssteuerung 532 legt REST-Schnittstellen frei, die Speicherstapel auf Servern einsetzen, sowie die Stapel basierend auf Benutzereingaben oder Best-Practice-Vorlagen, die im Richtlinienmanager gespeichert sind, konfigurieren und booten. Die Verbrauchssteuerung 526 legt REST-Schnittstellen frei, die es dem Verbraucher ermöglichen, Speicher für jeden jeweiligen Speicherstapeltyp zu verbrauchen. In der einfachsten Form ist es ein Durchlauf durch den zugrunde liegenden Stapel. In komplizierten Abläufen treibt sie dynamisch eine elastische Expansion oder einen elastischen Einsatz von Speicherstapeln an, um die Anforderung zu erfüllen.
Open-Source-Dienste 510 werden genutzt, um die Infrastrukturentwicklungskosten zu reduzieren. Sie werden von vielen Diensten in den nativen Diensten 504 verwendet. Dell EMC-Dienste 512 sind Dienste, die verwendet werden, um das funktionsübergreifende Verhalten zu erleichtern, wie beispielsweise M&R und Unterstützung/Call-Home. Die Plattformkonfigurationsverwaltungsdienste 518, hierin auch als Basisdienste in VIKI bezeichnet, sind unabhängig von oder gemeinsam von den Steuerungen, z. B. Rechensteuerung 509, Stapeleinsatzorchestrierungssteuerung 532 und Verbrauchssteuerung 526 in 5.
In bestimmten Ausführungsformen sind die Steuerungsdienste in 5 VIKI-Steuerungsdienste. Die Plattform-REST-Endpunkte 502 am oberen Rand von 5 beinhalten alles, was mit einer Anforderung zum Installieren, Konfigurieren oder Registrieren einer SDS-Anlage oder eines anderen Speichers zu tun hat, bis hin zu Verbrauchsanforderungen - alles, was das Verwaltungssystem zu bieten hat. Und dann können unter den Plattform-REST-Endpunkten 502 in 5 andere Endpunkte innerhalb des Blocks der nativen Dienste 504 in Einsatz-REST-Endpunkte und auch Verbrauchs-REST-Endpunkte aufgeteilt werden. In bestimmten Ausführungsformen kommen Verbrauchsanforderungen durch die nativen Dienste 504 herein, wie Einsatzanforderungen, und dann werden sie an den Verbrauchsanforderungsmanager 528 weitergeleitet.
6 ist eine veranschaulichende Benutzerschnittstelle 600, die konfiguriert ist, um mit der Architektur der 3-8 und gemäß mindestens einer offenbarten Ausführungsform zu arbeiten. Diese Benutzerschnittstelle (UI) 600 ist in bestimmten Ausführungsformen als Browsererweiterung implementiert, aber das ist nicht einschränkend. Das Admin-Feld 602 in der beispielhaften UI 600 ermöglicht es der UI 600, als zentrale Verwaltungsschnittstelle für die softwaredefinierte Speicherinfrastruktur (SDSI) der 3-8 zu fungieren. Über die Schaltfläche „Objekt“ 604 auf der UI 600 stellt die UI 600 einem Benutzer eine Möglichkeit bereit, um ein Roll-up von aktiven softwaredefinierten Datendiensten in logischen Gruppierungen zu fordern. Über die Schaltfläche „Dienst hinzufügen“ 606 in der UI 600 ist ein Benutzer in der Lage, beispielsweise „Dienst hinzufügen“ auszuwählen, und die UI 600 versteht, wie Speicherstapel einzusetzen und zu konfigurieren sind (dies wird hierin ausführlicher erörtert). Über die Schaltfläche „Cloud-Gateway“ 608 ermöglicht die UI 600 einem Benutzer, prädiktive Analysen und Ereignisse von M&R zu nutzen, um Dienste zu neuen Knoten elastisch zu erweitern (dies wird hierin ausführlicher erörtert). Über die Schaltfläche „Virtueller Strom“ 610 vereinfacht die UI 600 den Einsatz und die Konfiguration für einen Benutzer, da das System Speicherstapelabhängigkeiten versteht und wie den Einsatz und die Konfiguration orchestriert werden kann.
7 ist ein erstes veranschaulichendes Diagramm 700, das Komponenten innerhalb der Stapeleinsatzorchestrierungssteuerung 532 von 5 gemäß einer Ausführungsform zeigt. In bestimmten Ausführungsformen besteht das Gesamtziel der Box 714, die in gestrichelter Linie dargestellt ist (und die von anderen ähnlichen Boxen daneben), darin, typspezifische Logistik- und Geschäftslogik auf eine steckbare Architektur herunterzusetzen, so dass die obersten Schichten einfach und unabhängig von den Bedürfnissen der einzelnen Technologien sein können. Diese Box 714, die in gestrichelten Linien dargestellt ist, stellt in bestimmten Ausführungsformen eine beliebige der in 5 gezeigten Blocksteuerung, Feuersteuerung, Objektsteuerung, Projektions- und Streamsteuerung dar. Das Gesamtziel der Boxen 705, 708 innerhalb der Box 714 (zusammen mit beliebigen anderen Boxen, die innerhalb der gestrichelten Box 714 daran angrenzen würden) besteht darin, technologiespezifische Konfigurationsparameter und Geschäftslogik in eine steckbare Architektur zu setzen.
Unter weiterer Bezugnahme auf 7 sind die Komponenten in diesem Teil der Architektur von oben nach unten wie folgt konfiguriert:
Northbound-Anforderungen zum Einsetzen von Speicherdiensten eines bestimmten Typs treten in die Stapeleinsatzanforderungsabbildungsschicht 506 ein. Die Verantwortung dieses Diensts besteht darin, Argumente zu validieren, an den Stapelkoordinatororchestrierungsdienst zu versenden und eine Aufgaben-ID und eine andere relevante Information zurückzugeben.
Der Stapelkoordinatororchestrierungsdienst 508 empfängt Anforderungen zum Versenden von Speicherdiensten vom Anforderungsabbildungsdienst 506. Der Stapelkoordinatororchestrierungsdienst 508 kann mehrere abhängige Einsatzanforderungen in derselben Anforderung empfangen (wie SDNAS auf VxFlex OS). Der Stapelkoordinatororchestrierungsdienst 508 ist für das Laden des jeweiligen Stapeltyps und das Aufrufen der erforderlichen Schnittstellen verantwortlich, um die angeforderten Ergebnisse zu erzielen. Er unterstützt die Vorschau und Ausführung für die jeweiligen Arbeitsschritte.
Die erste Plug-In-Fähigkeit 702 wird durch Dienste in der Box 714 erzielt, die in der gestrichelten Linie dargestellt ist, die nachstehend einen REST-Schnittstellenvertrag implementiert und sich selbst gegen die Dienstregistrierung als einen Anbieter der Stapelkoordinatororchestrierung registriert.
Die <TYPE> Steuerung (Block, Datei, Objekt, Stream, Schutz) 704 implementiert einen grundlegenden Satz von REST-Schnittstellen und registriert den Dienst gegen eine Registrierung mit einem bestimmten Typ. In dieser beispielhaften Ausführungsform ist nur eine Hauptsteuerung jedes <TYPE> zulässig und die Typen sind festgelegt.
Gemäß der zweiten Plug-In-Fähigkeit 706 weist jeder Haupttyp eine Reihe von REST-Eintrittspunkten auf, die implementiert werden sollen. Zum Einsatz ist die Blockauswahlanalyse der Einsatzeintrittspunkt, der den richtigen Dienst bestimmt, der eingesetzt werden soll, wenn die Einsatzanforderung gegeben ist.
Die Stapelimplementierung (Block/VxFlex OS, Datei/SDNAS usw.) 708 registriert sich selbst gegen eine Dienstregistrierung und implementiert die Kenntnisse über: welche Ressourcen benötigt werden, um diese Anforderung zu bedienen (Erzeugen eines neuen Pools, Einsetzen eines neuen Stapels usw.); wie die Arbeitsschritte zu beschreiben sind, die für eine Vorschauanforderung durchgeführt werden müssen; und wie die Einsatz- oder Verwaltungsarbeitsschritte unter Verwendung des Bedrock-Diensts zu starten sind, der bestimmt, wie Ansible-Playbooks zu konfigurieren und auszuführen sind, um Automatisierung für IT-Verwaltungsaufgaben bereitzustellen.
Der Southbound-Treiber 710 für jeden Stapel ist verantwortlich für das Sprechen mit den eingesetzten Speicherstapelverwaltungsschnittstellen (VxFlex OS Management oder „MDM“), um eine Information darüber abzuleiten, wie eine Anforderung zu erfüllen ist. Southbound-Treiber 710 versendet in bestimmten Ausführungsformen auch Bedrock, um grundlegende Information über Hosts sowie ein Dienstprogramm zu erhalten, und Stapelimplementierung kann diese Informationen verwenden.
8 ist ein zweites veranschaulichendes Diagramm 800, das zusätzliche Komponenten zeigt, die innerhalb der Stapeleinsatzorchestrierungssteuerung 532 von 4 gemäß mindestens einer Ausführungsform verwendet werden. Die Stapeleinsatzorchestrierungssteuerung 532 ermöglicht das Installieren von Stapeln, das Ändern von Stapeln, das Abrufen von Information über Stapel, das Erzeugen neuer Ressourcen innerhalb von Stapeln (z. B. in bestimmten Ausführungsformen, einen neuen Pool) und das Zurückgeben von Aufgabenobjekten für lang laufende Arbeitsschritte.
9 ist ein erstes vereinfachtes Flussdiagramm 900 eines beispielhaften Verfahrens zum Speicherdiensteinsatz, das mit den Systemen der 3-8 gemäß einer Ausführungsform verwendbar ist, und 10 ist ein zweites vereinfachtes Flussdiagramm eines beispielhaften Verfahrens zum Dienstspeichereinsatz, das mit den Systemen der 3-8 gemäß einer Ausführungsform verwendbar ist. 9 stellt ein Verfahren dar, das dem von 10 ähnlich ist, jedoch auf einer vereinfachten und höheren Ebene, während 10 weitere Details für jeden Haupttyp der durchgeführten Analyse bereitstellt. Die Verfahren der 9 und 10 sind in bestimmten Ausführungsformen für verschiedene Anwendungen verwendbar, wie z. B. das Einsetzen bestimmter softwaredefinierter Speicherdienste auf einem bestimmten Server oder einer Reihe von Servern. Zum Beispiel können in bestimmten Ausführungsformen Kunden ihre softwaredefinierten Speicherstapel einsetzen wollen, bevor Verbrauchsanforderungen eintreffen. In Übereinstimmung mit bestimmten Ausführungsformen hierin haben die hierin beschriebenen Systeme, Verfahren und Geräte (einschließlich, aber nicht beschränkt auf die Architektur der 3-8) die Fähigkeit: (a) die Stapel und Ressourcen zu verstehen, die potenziell zur Verwendung verfügbar sind, wenn eine Client-/Kundenanforderung eintrifft; und (b) diese Anforderung durch Einsetzen eines Stapels zu bedienen oder einfach eine Ressource innerhalb dieses Stapels auszuschneiden, um die Besonderheiten der Speicheranforderung zu erfüllen.
In 9 werden nach dem Empfang einer Anforderung (Block 910) drei Arten von Analysen abgeschlossen: eine Abbildungsanalyse (Block 910), eine Stapelanalyse (Block 920) und eine Ressourcenanalyse (Block 930), basierend auf den Ergebnissen dieser Analyse, wobei die Orchestrierung, die abläuft (Block 940), in der Lage sein wird, das einzusetzen und miteinander zu koppeln, was zum Bedienen der empfangenen Speicheranforderung erforderlich ist. In bestimmten Ausführungsformen wird die empfangene Anforderung einen Stapelparameter und einen Ressourceneigenschaftsparameter beinhalten, wobei der Stapelparameter mindestens einen Typ von Speicheranlage spezifiziert und der Ressourceneigenschaftsparameter mindestens eine von der Speicheranlage benötigte Funktionsfähigkeit spezifiziert.
Als ein Beispiel wird ein Beispiel betrachtet, in dem eine Kunden-/Client-Anforderung für eine NAS-Freigabe empfangen wird (Block 905 - 9, Block 1050, 10). In bestimmten Ausführungsformen wird eine Anforderung für einen Typ von Speicherfreigabe als Verbrauchsanforderung bezeichnet (Block 1050 von 10). Gemäß 10 wird die Kunden-/Client-Anforderung analysiert (wie hierin weiter beschrieben), um zu bestimmen, was angefordert wird. In diesem Beispiel wird davon ausgegangen, dass die empfangene Verbrauchsanforderung angibt, dass die NAS-Freigabe (z. B. Stapelparameter) auf extrem schnellem Speicher (erster Ressourceneigenschaftsparameter) mit Inline-Deduplizierungsfähigkeit (zweiter Ressourceneigenschaftsparameter) erfolgen muss.
Zunächst wird unter Bezugnahme auf 9 und 10 eine Abbildungs-/Platzierungsanalyse (Block 910, 9, Block 1052, 10) ausgeführt, um die Anforderung zu analysieren, um die Typen von Stapeln zu bestimmen, die zum Bedienen der Anforderung erforderlich sind (Block 1052, 10). Die hierin beschriebenen Systeme, Verfahren und Geräte sind auch in der Lage, (als Reaktion auf die empfangene Anforderung) über die Analyse der Blöcke 910-940 (und der Blöcke 1050 -1066) zu bestimmen, ob die Ressourcen verfügbar und eingesetzt sind. In diesem hypothetischen Beispiel wird davon ausgegangen, dass als Reaktion auf die Anforderung für eine NAS-Freigabe auf sehr schnellem Speicher mit Inline-Deduplizierungsfähigkeit (Block 1052) die Liste, die bei Block 1054 empfangen wird, angibt, dass die empfangene Anforderung nur durch eine Kombination von SDNAS-, SD-Block- und VxFlex OS-Speicherstapeln bedient werden kann.
Eine Stapelanalyse (Block 920) beinhaltet in bestimmten Ausführungsformen ein Prüfen des Status von Speicherstapeln, die die Speicheranforderung erfüllen können (oder die benötigt/erforderlich sind, um die Speicheranforderung zu erfüllen), um basierend auf dem Status (Block 1054) zu bestimmen, ob die Stapel, die verwendet werden sollen, um die Speicheranforderung zu erfüllen, eingesetzt sind (Block 1056). Der aktuelle Speicher wird analysiert und der Status des Speichers wird empfangen (Block 1054). Im aktuellen Bericht gibt der Status an, dass innerhalb des verfügbaren Speichers die SIO (hierin auch als DELL EMC VxFlex OS bezeichnet) und SDNAS-Produkte eingesetzt sind. Im Verfahren von 10 wäre, wenn diese beiden die einzigen benötigten Stapel wären, die Antwort an diesem Punkt bei Block 1056 „ja“.
In diesem Beispiel ist die SIO jedoch nicht der einzige benötigte Stapel, so dass die Analyse für jeden erforderlichen Stapel fortgesetzt wird. Beispielsweise kann die Stapelanalyse bestimmen, dass für die aktuelle Suite, die die Kunden-/Client-Anforderung empfängt, SIO eingesetzt hat, aber es gibt nur einen Pool auf dem Festplattenlaufwerk (HDD), kein Festkörperlaufwerk (SSD) und softwaredefinierter (SD) Block wird überhaupt nicht eingesetzt. In diesem hypothetischen Fall wird gelernt, dass der SD-Block, der zum Bedienen der Anforderung benötigt wird, nicht eingesetzt wird (Antwort bei Block 1056 ist „NEIN“).
In dieser Situation wird ein Arbeitsablauf (z. B. ein Satz von Aufgaben oder ein Skript) zu einer Liste von Arbeitsabläufen hinzugefügt, die zum Zeitpunkt der Orchestrierung ablaufen sollen (wenn der Speicher oder die Freigabe für Kunden/Clients verfügbar gemacht wird). Beispielsweise fügen Sie für jeden nicht eingesetzten Stapel einen oder mehrere Arbeitsabläufe zur Orchestrierung hinzu, um nicht eingesetzte Stapel nach Bedarf einzusetzen. Somit führen die Verfahren 900 und 1000 nach Abschluss der Stapelanalyse (Block 920) dann eine Ressourcenanalyse durch (Block 930, 1060 -1064), wobei die Ressourcenanalyse jedes Stapels (ob eingesetzt oder nicht) Ressourceneigenschaften aufweist, die für die angeforderte Leistungsstufe des Kunden benötigt werden und benötigte Merkmale aufweist (Block 1060). Basierend darauf kann die SDS-Suite/Architektur in der Lage sein, auf die Suche nach der automatischen Bereitstellung von Ressourcen zu reagieren.
Unter Bezugnahme auf das Verfahren 900 von 9 und das Verfahren 1000 von 10 findet eine Abbildungsanalyse (Block 910) statt. In bestimmten Ausführungsformen bestimmt beispielsweise eine SDS-Suite/Architektur im Abbildungsanalyseblock, dass die empfangene Anforderungsanforderung (Block 905) nur von einem SDNAS, SD-Block, SIO-Kombination bedient werden kann (Block 910).
Als Teil der Stapelanalyse (Block 920) bestimmt die SDS-Suite/Architektur, ob die erforderlichen Ressourcen bereits eingesetzt sind. In bestimmten Ausführungsformen beinhaltet die Stapelanalyse das Bewerten des offenen Erfinders (z. B. von Speicherressourcen) gegen eine Best-Practice-Vorlage. In diesem Beispiel bestimmt die SDS-Suite/Architektur, dass SIO bereits eingesetzt ist, SDNAS bereits eingesetzt ist, aber der softwaredefinierte (SD) Block nicht eingesetzt ist. In bestimmten Ausführungsformen implementiert der SD-Block einen Satz von zusätzlichen Fähigkeiten, die VxFlex OS für Blockspeicher nutzen können. Beispielsweise bestimmt in dem hypothetischen Fall, da SD-Block nicht eingesetzt ist, als letzter Teil der Stapelanalyse die SDS-Suite/Architektur, dass sie ein Skript oder einen Arbeitsablauf zur Orchestrierung hinzufügen sollte, um sie einzusetzen, wie z. B. „Ansible-Skript zum Einsetzen von SD-Block gegen eine Best-Practice ausführen“ (was beispielhaft, aber nicht einschränkend ist).
Unter erneuter Bezugnahme auf 9, 10 wird nach Abschluss der Stapelanalyse eine Ressourcenanalyse (Block 930) ausgeführt, um zu bestimmen, ob jeder Stapel (ob eingesetzt oder nicht) Ressourceneigenschaften aufweist, die für Leistungsstufen und benötigte Merkmale benötigt werden (Block 1060). Im Ressourcenanalyseblock (Block 930) werden Prüfungen durchgeführt, um zu bestimmen, ob die verfügbaren und eingesetzten Stapel andere Anforderungen der Anforderung erfüllen. Weitere Details über diese Arten von Prüfungen werden hierin weiter beschrieben. Fehlt eine Ressource an benötigten Merkmalen oder Eigenschaften (d. h. Antwort bei Block 1062 ist „JA“), wird ein Arbeitsablauf/Skript zur Orchestrierung hinzugefügt, um die benötigten Merkmale oder Eigenschaften zu generieren.
Beispielsweise wird in dem hypothetischen Fall, wenn die SIO-Ressource keinen Pool aufweist, der hohe Leistung erfüllt (was in der Anforderung spezifiziert wurde), ein Arbeitsablauf/Skript hinzugefügt, das „SSD-basierten SIO-Pool erstellen“ hinzufügt (wobei in der Technik bekannt ist, dass SSD-Geräteab zu diesem Zeitpunkt im Allgemeinen leistungsfähigere Geräte als HDD-Geräte sind). In einem weiteren Beispiel, das sich auf den hypothetischen Fall bezieht, wird, wenn die SD-Block-Ressource eine entsprechende Abbildung benötigt, um ein Inline-Deduplizierungsmerkmal bereitzustellen, ein Arbeitsablauf/ein Skript, der/das „Inline-Dedupvolumenabbildung im SD-Block erzeugen“ angibt, zur Orchestrierung hinzugefügt. Ein weiteres Beispiel für den Fall, dass die Ressourcenanalyse ergibt, dass SDNAS weitere Ressourcen (Freigabe) erzeugen muss, die dem Profil entsprechen, wird im Takt 1064 ein Workflow/Skript mit der Konfiguration „SDNAS-Dateifreigabe erzeugen“ zur Orchestrierung hinzugefügt.
Wenn Ressourcen an benötigten Merkmalen und Eigenschaften nicht mehr fehlen (d. h. Antwort bei 1062 ist „NEIN“), läuft die Orchestrierung an (Block 940, Block 1066), wobei die Orchestrierung alle Skripte ausführt, die zur Orchestrierung hinzugefügt wurden.
Die 11 ist ein Diagramm 1100 und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 3-8 stattfinden, die während des Speicherdiensteinsatzes stattfindet, die Aktionen zeigt, die auftreten, wenn ein Kunde nach einer NAS-Freigabe (Network Attached Storage) fragt, bis zu dem Punkt, an dem der Arbeitsablauf zusammengesetzt und an den Arbeitsablaufausführungsdienst der 3-8 gemäß mindestens einer Ausführungsform weitergegeben wird. Die Abfolge von Aktionen von 11 ist als die Aktionen gezeigt, die mit (1) bis (9) auf der rechten Seite der Zeichnung nummeriert sind, wobei entsprechende nummerierte Beschriftungen in der Architektur auf der linken Seite der Zeichnung gezeigt sind, die zeigen, welche Elemente der Architektur bei der Implementierung der Abfolge helfen.
Die Architektur von 11 ist im Wesentlichen dieselbe wie die von 4, zeigt jedoch einige der Elemente darin ausführlicher. Die ausführlichen Bezugszeichen von 4 sind in 11 nicht enthalten, um die Klarheit zu verbessern, aber es wird erwartet, dass gleiche Elemente gleiche Nummern haben. Diese Abfolge wird implementiert, um einen hypothetischen Fall zu erfüllen, der mit dem oben für die Flussdiagramme von 9 und 10 erörterten identisch ist, wobei die in 9 und 10 gezeigten Verfahren weiterhin anwendbar sind. 11 zeigt noch ausführlicher, wie die Komponenten der Architektur von z. B. 3 und 4 in der Lage sind, die Verfahren von 9 und 10 zu implementieren.
Unter Bezugnahme auf 9, 10, 11 ist der hypothetische Fall derselbe wie oben erörtert: Ein Kunde fragt nach einer NAS-Freigabe auf super („über“) schnellem Speicher mit Inline-Deduplizierungsfähigkeit. Die aktuelle SDS-Suite von Speicher im System, das die Anforderung empfängt, hat SIO eingesetzt, aber es gibt nur einen Pool auf HDD (langsamer Speicher), nicht SSD (schneller Speicher) und SD-Block wird überhaupt nicht eingesetzt. Beginnend mit Schritt 1 in der Sequenz kommt bei Schritt (1) eine Anforderung für eine NAS-Freigabe an der Architektur an, in diesem Beispiel über die Verwaltungs-REST-Endpunkte 316 (3, 4). Bei Schritt (2) findet eine Platzierungsanalyse (hier auch als Abbildungsanalyse bekannt, z. B. wie in Block 910 von 9 und Block 1052 von 10 gezeigt) statt. Wie 11 zeigt, führt der Anforderungsabbildungsdienst 318 in dieser Ausführungsform die Platzierungs-/Abbildungsanalyse (2), die Stapelanalyse (3), (4) und (5) und die Ressourcenanalyse (6), (7) und (8) durch, von denen jede im Wesentlichen ähnlich wie die oben in Verbindung mit 9 und 10 beschriebene Weise fortschreitet. 11 zeigt auch, dass die Stapeltreiber 414 (4) dabei helfen, die mit den Schritten (3), (4) und (5) der Stapelanalyse und den Schritten (6), (7) und (8) der Ressourcenanalyse verknüpften Information an die zugehörigen Stapelverwaltungsdienste 330 (z. B. SDNAS-Verwaltung und SIO-Verwaltung) zu kommunizieren. Der Arbeitsablaufausführungsdienst 410 führt dann die Orchestrierung bei (9) aus.
12 ist ein veranschaulichendes Diagramm 1200, das automatisierte vertikale Funktionen zeigt, die in einer Architektur stattfinden, die auf den Architekturen der 3-8 gemäß mindestens einer Ausführungsform basiert. Insbesondere ist die in 12 gezeigte Architektur eine „abgespeckte“ Architektur im Vergleich zu der Architektur 400 von 4, um die stattfindenden Aktionen besser zu zeigen. In dieser beispielhaften Ausführungsform der Architektur implementiert die Architektur 1200 eine Verwaltungsplattform, die die Installation, den Einsatz und die Konfiguration einer bestimmten vereinfachten Teilmenge von Speicher automatisiert (z. B. in dieser beispielhaften Ausführungsform SDNAS auf dem VxFlex OS für den einfachen Verbrauch von Dateifreigaben unter Verwendung eines Industriestandard-Front-End, Ansible Tower). Wie in 12 gezeigt, beinhaltet die Architektur 1200 von unten nach oben eine softwaredefinierte Speicherverwaltungs- und Orchestrierungsebene (M&O)/-schicht 102 (hierin auch als eine Schicht 102 bezeichnet), wie oben erwähnt, die mit einem Oberflächenbereich 302 und einem oder mehreren Speicherstapeln 306 interagiert. Wie in 4 befinden sich die Stapelverwaltungsdienste 302 in bestimmten Ausführungsformen außerhalb der M&O-Steuerebene 102.
Unter Berücksichtigung der Architektur von 12, die von unten nach oben beginnt, beinhalten die Speicherstapel 306 eine Vielzahl von physischen Platten 336d -336c, Stapeldatendienste 334 und Stapelclient-Dienste 332. Im Allgemeinen werden die Speicherstapel 306 in bestimmten Ausführungsformen unter Verwendung bestehender softwaredefinierter Speicherstapel implementiert, wie z. B. dem abgebildeten SIO-Datendienst 1248 (dieser Datendienst ist jedoch veranschaulichend und nicht einschränkend). Die physischen Platten 336 beinhalten einen Satz von physischen Platten, die für den Datendienstverbrauch verfügbar sind.
Die Stapeldatendienste 334 stellen einen Satz von Datendiensten zum Verbrauchen des Speichers bereit. Die Stapelclientdienste 322 stellen einen Satz von Diensten bereit, die Speicherfacetten für Anwendungen oder anderen softwaredefinierten Speicherstapeln dienen (Schichtungen/Abhängigkeiten voneinander sind in 12 nicht veranschaulicht).
Die Stapelverwaltungsdienste 330 sind Dienste, die Verwaltung (Steuerpfad) der bereits vorhandenen Speicherstapel durchführen. Vorteilhafterweise können die Stapelverwaltungsdienste 330 auf den cloudnativen Cluster angehoben werden, wenn dies nicht bereits ermöglicht ist. In bestimmten Ausführungsformen sind die Stapelverwaltungsdienste 330 so konfiguriert, dass sie „steckbar“ sind, was bedeutet, dass ihre erweiterten Funktionen und sich ändernde Funktionalität durch das Plug-In gesteuert werden können und automatisch in der M&O-Ebene ohne zusätzliche Anpassung durch die vereinheitlichten Dienste widergespiegelt werden können. Wie in 12 gezeigt, beinhalten die Stapelverwaltungsdienste 330 nur beispielhaft SIO-Verwaltungsdienste und SDNAS-Verwaltungsdienste. Wie zu erkennen ist, beinhaltet die Stapelverwaltungsdienstschicht 330 im Allgemeinen Verwaltungsdienste für die Client-Dienste und Datendienste, die sich tatsächlich in der Stapelclientdienstschicht 332 bzw. den Stapeldatendiensten 324 befinden.
Die M&O-Ebene 102 wird hierin auch als die softwaredefinierte Schnittstelle (SDI) „Gehirn“ bezeichnet und stellt in bestimmten Ausführungsformen eine vereinheitlichte Verwaltung von softwaredefinierten Speicherkernkomponenten bereit. Wie in 12 gezeigt, beinhaltet die M&O-Ebene 102 in bestimmten Ausführungsformen ein cloudnatives Ökosystem 323, wie Kubernetes/Pivotal Cloud Foundry. In bestimmten Ausführungsformen wird davon ausgegangen, dass ein Benutzer/Kunde, der die Architektur von 12 verwendet, bereits ein cloudnatives Ökosystem in seiner privaten Cloud haben kann. In bestimmten Ausführungsformen kann die Architektur 1200, wenn der Benutzer oder Kunde kein cloudnatives Ökosystem in seiner privaten Cloud hat, ein cloudnatives Ökosystem bereitstellen.
Die Serververwaltungsdienste 322 sind ein Satz von Open-Source-Tools, die verwendet werden, um Installation, Einsatz und Konfiguration der softwaredefinierten Speicherstapel 306 durchzuführen. In der beispielhaften Ausführungsform von 12 ist die veranschaulichende Serververwaltungsquelle, die verwendet wird, Ansible, aber das ist nicht einschränkend.
Der vereinheitlichte softwaredefinierte Verwaltungsdienst 304 ist ein Satz von Diensten, der die Server und Dienste unter Verwaltung verstehen und es dem Benutzer ermöglicht, eine beliebige Richtlinie um Einsätze zu erzeugen und zu speichern. Die vereinheitlichten softwaredefinierten Verwaltungsdienste 304 speichern und wenden auch Konfigurationsvorlagen auf Speicherstapel an, um Konfigurationen angesichts der eingesetzten Hardware am besten zu praktizieren.
Die Verwaltungs-REST- (Representational State Transfer) Endpunkte 316 werden durch REST-Endpunkte freigelegt. In bestimmten Ausführungsformen erfordern die Verwaltungs-REST-Endpunkte 316 die Einhaltung der Industriestandardspezifikation. In bestimmten Ausführungsformen stellt die Oberflächenbereichsschicht 302 ausschließlich die gewünschten Berührungspunkte bereit.
Die Oberflächenbereichsebene oder -schicht 302 beinhaltet eine grundlegende oder „rudimentäre“ Benutzerschnittstelle (UI) 1202, wie die Wiederverwendung vorhandener UI-Anlagen. Vorteilhafterweise nutzt die Implementierung in bestimmten Ausführungsformen die vorhandenen IT-Ökosysteme eines Kunden, wie Ansible Tower, VMware vRO und/oder andere Orchestrierungs- und Verwaltungssoftware, so dass zumindest einige der hierin beschriebenen Ausführungsformen leicht in das/die vorhandene(n) Ökosystem(e) „eingesteckt“ werden können. Die Oberflächenbereichsschicht 302 beinhaltet auch eine grundlegende organisierte Einheit oder einen Satz von Skripten, die/der die Arbeit für eine automatisierte Serverkonfiguration, wie ein Ansible Playbook 1204, für den Verbrauch der Plattform definiert. Der Oberflächenbereich 302 stellt dar, wie die SDI-Brain-323-Fähigkeiten dem Verbraucher ausgesetzt sind.. Es versteht sich, dass in dieser Offenbarung die Begriffe softwaredefiniertes Speichersystem (SDSS), softwaredefinierte Schnittstelle (SDI) Brain und VIKI alle austauschbar verwendet werden.
Die 13 ist ein vereinfachtes Flussdiagramm 1300, das ein Verfahren zum Registrieren und Einsetzen von Hosts und Speicher für die Architektur der 3-12 gemäß mindestens einer Ausführungsform zeigt. Die 14 ist ein veranschaulichendes Diagramm 1400 und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während der Registrierung eines Hosts und dem Einsatz eines softwaredefinierten Freigabe-Block-Speichers (basierend auf Direct Attached Storage), wie etwa VxFlex OS und softwaredefiniertem Network Attached Storage (SDNAS), gemäß mindestens einer Ausführungsform aktiv sind. Obwohl das Flussdiagramm der 13 und das entsprechende Diagramm und die entsprechende Abfolge der 14 hierin insbesondere unter Bezugnahme auf die vereinfachte Architektur der 12 beschrieben sind, versteht es sich, dass derartige Beschreibungen gleichermaßen auch auf die Architekturen der 3-4 anwendbar sind.
Unter Bezugnahme auf die 12-14 veranschaulicht das Gesamtverfahren in einer Ausführungsform einen Prozess für einen Kunden/Client, um eine Dateifreigabe schneller und einfacher bereitzustellen, als dies derzeit der Fall ist. Wenn der Kunde in der Lage ist, die Architektur zu verwenden, um einen Host schnell und automatisch im System zu registrieren und einen Stapeldatendienst (z. B. SIO) und einen Stapelclientdienst (z. B. SDNAS) einzusetzen, wird die Dateifreigabe schnell bereitgestellt. In Block 1310 der 13 beginnt ein Kunde/Client den Prozess, um die Dateifreigabe schnell bereitzustellen. In Schritt (1) der verwandten Sequenz der 14 kommt die Anforderung zum Registrieren von Hosts über die Verwaltungs-REST-Endpunkte 316 herein, und die Anforderung wird an die Rechensteuerung weitergeleitet (siehe 14). LINUX-Hosts werden zur Verwendung durch VIKI registriert (Blöcke 1320-1322 der 13). Dieser Registrierungsprozess beinhaltet, dass die Rechensteuerung (14) die LINUX-Hosts kontaktiert, grundlegende Informationen über die LINUX-Hosts entdeckt und gelernte Inventarinformation speichert (Schritt (2) der Sequenz der 14). Die 15 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während der Registrierung eines LINUX-Hosts aktiv sind, gemäß mindestens einer Ausführungsform.
Die 16 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge 1500 von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während des Einsatzes von Scale 10 als Dienst aktiv sind, gemäß mindestens einer Ausführungsform. Unter kurzer Bezugnahme auf die beispielhafte Sequenz der 15 teilen sich in Schritt (1) der Sequenz als Teil der Registrierung die REST-Endpunkte 416 der Verwaltung LINUX-Hostinformation. In Schritt (2) kontaktiert die Rechensteuerung die Bedrock-Steuerung mit Passwortinformation. In Schritt (3) verwendet die Bedrock-Steuerung das vorhandene Playbook von Caspian, um ssh-Schlüssel zur Erleichterung der späteren Ansible-Skriptwiedergabe zu übertragen. In Schritt (4) „verbirgt“ die Bedrock-Steuerung die asynchrone Natur des ansible Skripts und gibt den Status 202 an die Rechensteuerung zurück. In Schritt (5) überträgt die Rechensteuerung auch ssh-Schlüssel, so dass sie auf Inventar-/Entdeckungsinformation zugreifen kann. In Schritt (6) führt die Rechensteuerung das Ansible-Einbaumodul aus, um Entdeckungsinformation zu erhalten. In Schritt (7) speichert die Rechensteuerung Hostinformation in Form einer Ansible-verbrauchbaren Datei oder eines Artefakts, auf die/das die Bedrock-Steuerung oder Ansible selbst bei einer Gruppierung/einem Tag während der Einsatzanforderung verweisen kann. In Schritt (8) wird die Verwaltungs-REST-Endpunkte-416 -Antwort an die Entität zurückgegeben, die das Registrieren der LINUX-Hosts angefordert hat.
Unter weiterer Bezugnahme auf 13 und 14 identifiziert der Anforderungsabbildungsdienst 318 als Reaktion auf die Anforderung, VxFlex OS als Dienst einzusetzen (Block 1330-1332), das/die geeignete(n) auszuführende(n) Playbook(s) (z. B. durch Kommunizieren mit den Ansible-Playbooks, wie in 14 gezeigt). Als weiterer Teil der Anforderung führt das Workbook aus, das einem Benutzer eine Rückmeldung bereitstellt (Schritt (5) in der Sequenz der 14). Der Arbeitsablaufausführungsdienst 410 führt den Arbeitsablauf aus und installiert die Komponenten des VxFlex OS (Schritt (6) der Sequenz der 14), wobei in dieser Ausführungsform VxFlex OS mit Standardwerten eingesetzt wird. Diese Anforderung kann über mehrere Quellen eingehen, z. B. durch eine REST-API 316, die Benutzerschnittstelle 1202 oder das Ansible-Playbook 1204. Dieser Registrierungsprozess wird auch in Verbindung mit der Sequenz der 16 weiter detailliert, die nachstehend kurz erörtert wird.
Die 16 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge 1600 von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während des Einsatzes von Scale 10 als Dienst aktiv sind, gemäß mindestens einer Ausführungsform. Unter kurzer Bezugnahme auf die Sequenz der 16 wird zum Einsetzen des Stapeldatendiensts 324 (in diesem Fall VxFlex OS) in Schritt (1) eine VxFlex OS-Einstellungs-POST-Anforderung an den REST-Endpunkten 416 der Verwaltung empfangen und assoziiert: Gruppen-/Host-Tags werden durch die Bedrock-Steuerung des Anforderungsabbildungsdiensts 318 abgeholt. In Schritt (2) der Sequenz ruft die Bedrock-Steuerung Gruppierungen/Hosts aus REST-Anforderungsnutzdaten aus der „Ansible-Datei“ ab (alternativ kann dies in bestimmten Ausführungsformen nicht erforderlich sein, wenn die zugrunde liegende Ansible-Ausführung sie abrufen kann). In Schritt (3) gibt die Bedrock-Steuerung eine „Aufgaben-ID“ an den Aufrufer zurück (d. h. welche Entität auch immer den Einsatz von VxFlex OS als Dienst anfordert) für nachfolgende Statusaktualisierungen bei dem Einsatz. In Schritt (4) führt die Bedrock-Steuerung das Ansible-Skript aus, um VxFlex OS-Komponenten auf jeweiligen Knoten einzusetzen. (MDM-Verwaltung, SDC-Anwendungsverbinder und SDS-Speicherserver). In Schritt (5) setzt das Ansible-Skript Komponenten ein. In Schritt (6) erzeugt das Ansible-Skript einen Basisspeicherpool im VxFlex OS (z. B. in den Stapelverwaltungsdiensten 330).
In Schritt (7) fragt die Bedrock-Steuerung die Ansible-Ausgabe ab und „speichert“ eine wichtige Terminalzustandsinformation für jeden Host/Knoten und jede Komponente, die eingesetzt wird, zusammen mit einem einfachen Statusfeld. In bestimmten Ausführungsformen besteht, da die Terminalzustandsinformation gespeichert wird, keine Notwendigkeit, den Gesamtstatus bereitzustellen. In bestimmten Ausführungsformen ist es notwendig, die eindeutige Kennung des VxFlex OS-Speicherpools zu kennen, so dass er verwendet werden kann, wenn eine NFS-Dateifreigabe durch SDNAS erzeugt wird (wie hierin weiter erörtert). In Schritt (8) ruft eine GET-Anforderung von der Northbound-API mit „Aufgaben-ID“ aus Schritt (6) oben eine zwischengespeicherte Statusinformation ab, bis alle Nachrichten, die mit der Aufgaben-ID verknüpft sind, in einem Terminalzustand sind.
Unter erneuter Bezugnahme auf die 12-14, im Flussdiagramm der 13 und der Sequenz der 14, ist es nun bei den Blöcken 1340-1342 der 13 und Schritt (8) der 14, wobei SDNAS als ein Dienst eingesetzt werden soll. Der Ablauf zum Einsetzen von SDNAS als ein Dienst in 17 ist im Wesentlichen ähnlich dem Prozessablauf, der oben in Verbindung mit dem Einsatz von VxFlex OS als ein Dienst beschrieben wurde.
17 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während des Einsatzes von SDNAS als ein Dienst aktiv sind, gemäß mindestens einer Ausführungsform. In Schritt (1) der Sequenz der 17 wird eine VxFlex OS-Einsatz-POST-Anforderung an den Verwaltungs-REST-Endpunkten 416 empfangen und die Gruppen-/Host-Tags werden durch die Bedrock-Steuerung des Anforderungsabbildungsdiensts 318 abgeholt. In Schritt (2) der Sequenz ruft die Bedrock-Steuerung Gruppierungen/Hosts aus REST-Anforderungsnutzdaten aus „Ansible-Datei“ ab (in einer Ausführungsform kann dies nicht erforderlich sein, wenn die zugrunde liegende Ansible-Ausführung sie abrufen kann). In Schritt (3) gibt die Bedrock-Steuerung eine „Aufgaben-ID“ an den Aufrufer (Entität, die die Bereitstellung von SDNAS als ein Dienst angefordert hat) für nachfolgende Statusaktualisierungen bei dem Einsatz zurück. In Schritt (4) führt die Bedrock-Steuerung das Ansible-Skript aus, um SDNAS-Clusterverwaltungs- und NASlib-Komponenten (Network Attached Storage Libraries) auf jeweiligen Knoten einzusetzen. In Schritt (5) setzt ein Ansible-Skript Komponenten ein. In Schritt (6) fragt die Bedrock-Steuerung die Ansible-Ausgabe ab und „speichert“ eine wichtige Terminalzustandsinformation für jeden Host/Knoten und jede Komponente, die eingesetzt wird, zusammen mit einem einfachen Statusfeld. In bestimmten Ausführungsformen bedeutet dies keine Notwendigkeit für den Gesamtstatus. In Schritt (7) ruft eine GET-Anforderung von der Northbound-API mit „Aufgaben-ID“ aus Schritt 6 oben eine zwischengespeicherte Statusinformation ab, bis alle Nachrichten, die mit der Aufgaben-ID verknüpft sind, in einem Terminalzustand sind.
Unter erneuter Bezugnahme auf die 13 und 14 ist es nun bei den Blöcken 1350 der 13 und den Schritten (9)-(10) der Sequenz der 14, wobei die Dateifreigabe bereit ist, eingesetzt zu werden. Die obigen Arbeitsabläufe haben den detaillierten Status zurückgegeben und die Pool-Kapazität bereitgestellt (Schritt (9) der 14), und an diesem Punkt kann eine Dateifreigabe, wie beispielsweise eine NFS-Dateifreigabe (NFS = Networked File System), an die Stapelverwaltungsdienste 330 gesendet werden (d. h. in dieser beispielhaften Ausführungsform, d.h. der Eintrittspunkt für diese Anforderung). Gemäß 13, Block 1350, wird die Sequenz der 18 dann ausgeführt, um die Dateifreigabe über den SDNAS-Verwaltungseintrittspunkt bereitzustellen.
Die 18 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge von Aktionen, die in der Architektur der 12 und dem vereinfachten Flussdiagramm der 13 stattfinden, die die Komponenten zeigen, die während der Erzeugung einer NFS (Network File Share) aktiv sind, gemäß mindestens einer Ausführungsform. Unter kurzer Bezugnahme auf 18 wird in Schritt (1) eine neue NFS-Freigabe unter Verwendung von POST auf der SDNAS-Verwaltungs-API (veranschaulicht als oberer Screenshot 1802 in 18) vorgenommen. In Schritt (2) wird die NFS-Freigabe auf dem Client angezeigt (veranschaulicht als unterer Screenshot 1804 in 18).
In einer anderen Ausführungsform können unter Verwendung der in den 3-8 gezeigten vollständigen Architektur zusätzliche Merkmale implementiert werden. In bestimmten Ausführungsformen können die beschriebenen Systeme, Verfahren und Vorrichtungen zusätzlich zu den oben beschriebenen Funktionen, die in den Ausführungsformen der 3-18 implementiert sind, eine besser angepasste automatisierte Einrichtung für Benutzer bereitstellen, wobei mehr Vorlagen angepasst sind, um die Installation, Steuerung, Verwaltung, Einsatz, Konfiguration usw. von Speicheranlagen, wie softwaredefinierten Speicheranlagen, an bestimmte Benutzeranforderungen anzupassen, basierend auf den Eigenschaften und Merkmalen der Speicheranlagen.
In bestimmten Ausführungsformen sind die beschriebenen Systeme, Verfahren und Vorrichtungen beispielsweise in der Lage, eine Liste von softwaredefinierten Speicherstapelkonfigurationen (SDS-Stapelkonfigurationen) zurückzugeben, die dem Benutzer angesichts des Inventars des Benutzers und der Fähigkeit dieses Inventars zur Verfügung stehen. In bestimmten Ausführungsformen baut die Fähigkeit, eine Liste von verfügbaren SDS-Stapelkonfigurationen zurückzugeben, angesichts des Inventars und der Fähigkeit des Benutzers, eine Basis auf, um in der Lage zu sein, eine softwaredefinierte Speicherstapelinstallierbarkeit basierend auf mehreren anderen Faktoren zu beschreiben, einschließlich, aber nicht beschränkt auf, Serverfähigkeit (Speicher, Festplatte, CPU, Netzwerk), Lizenzierung, bestehende Stapelinstallationen, Mandanten-Einschränkungen und Netzwerktopologie und -konfiguration.
Die 19 ist ein veranschaulichendes Diagramm 1900, das die Komponenten zeigt, die während der Registrierung eines Hosts aktiv sind und Einsatzvorlagen anfordern, gemäß mindestens einer Ausführungsform, wobei die anwendbare Architektur die von 3-5 ist, wie oben erörtert. 20 ist ein veranschaulichendes vereinfachtes Flussdiagramm, das die Aktionen während der Registrierung eines Hosts und der Anforderung von Einsatzvorlagen in der Architektur von mindestens 3-8 zeigt. Insbesondere ist die in 19 gezeigte Architektur eine „abgespeckte“ Architektur im Vergleich zu der Architektur 500 von 5, um die stattfindenden Aktionen besser zu zeigen.
Unter Bezugnahme auf 19 veranschaulicht 19 die M&O-Schicht und die Oberflächenbereichsschicht 302 und beinhaltet Plattform-REST-Endpunkte 502, native Dienste 504, eine Rechensteuerung 509, ein API-Gateway 514, einen Einsatzvorlagenverwaltungsdienst (DTMS) 1906, eine Vielzahl von Vorlagen 1914a - 1914e innerhalb des Einsatzvorlagenverwaltungsdiensts, Open-Source-Dienste 1906, einen Richtlinienmanager 1908, einen Vorlagen-CRUD-Dienst 1910, eine Vorlagendefinitionsdatei 1912 und eine Stapeleinsatzorchestrierungssteuerung 532. Diese werden nachstehend weiter beschrieben oder sind identisch mit der Art und Weise, wie sie zuvor in Verbindung mit 4-5 oder an anderer Stelle hierin beschrieben wurden.
Anforderungen an die Plattform-REST-Endpunkte 502 werden von mehreren Diensten bedient, die unabhängig ablaufen. Das API-Gateway 514 multiplext den eingehenden Uniform Resource Locator (URL) an den Dienst, der diese Anforderung in der Plattform bedienen kann. In bestimmten Ausführungsformen können mehrere desselben Diensts innerhalb des cloudnativen Ökosystems 323 vorhanden sein. Die Benutzerschnittstelle (UI) 1902 kommuniziert Anforderungen an das API-Gateway 415. In bestimmten Ausführungsformen wird die UI 1902 als rudimentäre UI unter Verwendung des Vaadin-Frameworks implementiert, wobei das Vaadin-Framework ein Java-UI-Framework und eine Bibliothek ist, die die Entwicklung von Webanwendungen vereinfacht, wobei Code für das Framework in Java geschrieben und auf der Java Virtual Machine (JVM) des Servers ausgeführt wird, während die UI als Hypertext Markup Version 5 (HTML5) in einem Browser gerendert wird. Das Vaadin-Framework ist ein Open-Source-Produkt, das von Vaadin in Turku, Finnland, erhältlich ist. In bestimmten Ausführungsformen wird die UI 1902 über die Ansible Tower/AWX-Integration implementiert, wobei Ansible Tower eine webbasierte Schnittstelle zum Verwalten von Ansible ist, die eine UI zum Verwalten schneller Einsätze und Überwachungskonfigurationen bereitstellt.
Die nativen Dienste 504 sind in bestimmten Ausführungsformen ähnlich den nativen Diensten 504, wie oben in Verbindung mit 5 beschrieben, und beinhalten alle Dienste, die von der VIKI-Plattform implementiert werden, mit Ausnahme von Ansible AWX/Tower. Die Rechensteuerung 509 legt REST-Schnittstellen frei, die Server zum Inventar hinzufügen. Dieses Inventar wird verwendet, um softwaredefinierte Speicherstapel einzusetzen und zu installieren.
Die Stapeleinsatzorchestrierungssteuerung 532 hat Funktionen ähnlich denen der in 5 und legt REST-Schnittstellen frei, die Speicherstapel auf Servern einsetzen, sowie die Stapel basierend auf Benutzereingaben oder Best-Practice-Vorlagen, die im Richtlinienmanager 1908 und/oder der Vorlagendefinitionsdatei 1912 gespeichert sind, konfigurieren und booten.
In bestimmten Ausführungsformen sind die Steuerungsdienste in 19 VIKI-Steuerungsdienste. Die Plattform-REST-Endpunkte 502 am oberen Rand von 19 beinhalten alles, was mit einer Anforderung zum Installieren, Konfigurieren oder Registrieren einer SDS-Anlage oder eines anderen Speichers zu tun hat, bis hin zu Verbrauchsanforderungen - alles, was das Verwaltungssystem zu bieten hat, wie zuvor erwähnt. Die nativen Dienste 504 sind in bestimmten Ausführungsformen alle Dienste, die von der VIKI-Plattform implementiert werden, mit Ausnahme von AWX, wie zuvor angemerkt.
Die Vorlagendefinitionsdatei 1912 ist eine Datei, die Konfigurationen von Speicherstapeln und Voraussetzungen beschreibt, die für die Speicherstapelkonfiguration benötigt werden, die eingesetzt werden soll. In dem Vorlagenerzeugungs-/-lese-/-aktualisierungs-/-lösch-(CRUD)-Dienst 1910 werden Vorlagendefinitionen und eine Infentarinformation verfolgt und dem DTMS 1906 bereitgestellt, wenn angefordert, überprüft, ob sich die Vorlagendefinitionen ändern, und Vorlagendefinitionsdateien im Speicher gespeichert. Das DTMS 1906 sammelt Daten-, Vorlagen- und eine Inventarinformation und stellt sie dem Richtlinienmanager 1908 bereit, empfängt einen Satz von Ergebnissen vom Richtlinienmanager 1908, filtert die Ergebnisse basierend auf Abfrageparametern und stellt eine Antwort für einen Anrufer/Benutzer bereit.
Mit Bezug auf 19 und das Flussdiagramm 2000 von 20 kann in der Architektur 1900 der 19 ein Kunde/Benutzer LINUX-Hosts zur Verwendung durch VIKI registrieren/identifizieren (Block 2010), Einsatzvorlagen anfordern, die der Kunde/Benutzer ausführen kann (Block 2020), eine detaillierte Liste von Vorlagen erhalten, die eingesetzt werden können (Block 2030), und Gründe erhalten, warum er keine anderen einsetzen kann (Block 2040). Dies wird hierin weiter erläutert.
Die 21 ist ein veranschaulichendes vereinfachtes Flussdiagramm, das ein Verfahren zum Antworten auf eine Anforderung zum Bereitstellen von Speicher zeigt, das das Angeben, welche Konfigurationen im Inventar verfügbar sind, und die Fähigkeit dieses Inventars für die Architektur der mindestens 3-8 und 19 gemäß mindestens einer Ausführungsform beinhaltet. 21 beinhaltet auf einer hohen Ebene die in den 19-25 gezeigten Gesamtaktionen, wobei in bestimmten Blöcken Details zu den Aktionen in einer oder mehreren der 19-25 weiter beschrieben werden. Unter Bezugnahme auf die 19 und 21 beginnt das Verfahren mit vordefinierten Vorlagen und Regeln, die auf die softwaredefinierten Speicheranlagen angewendet werden sollen (Block 2110). Die Vordefinition beinhaltet die Erzeugung einer Vorlagendefinitionsdatei 1912, die die Konfigurationen von Speicherstapeln und die Voraussetzungen zum Einsetzen der Konfiguration beschreibt (Block 2112), sowie die Erzeugung eines Regelsatzes 1909 für den Richtlinienmanager 1908 (Block 2114). Der Regelsatz 1909 kann gegen eine Inventar- und Konfigurationsinformation ausgeführt werden, um zu bestimmen, ob die Vorlage erreichbar ist.
Der Vorlagen-CRUD-Dienst 1910 wird gestartet (Block 2120), der beinhaltet, dass der Vorlagen-CRUD-Dienst 1910 die Vorlagendefinitionsdatei 1912 lädt und sie im Speicher vorhält (Block 2122). Die Vorlagendefinitionsdatei beschreibt die Speicherstapelkonfiguration und Voraussetzungen zum Einsetzen der Konfiguration (Block 2122). Als Teil davon überprüft der Vorlagen-CRUD-Dienst 1910, ob sich die Definition (Vorlagendefinitionsdatei 1912) geändert hat, wenn ein GET aufgerufen wird, und eine bestimmte Zeit verstrichen ist (optional) (Block 2124). Eine Anforderung für Vorlagen wird gestellt (Block 2130). In bestimmten Ausführungsformen beinhaltet dies ein Durchführen von Aktionen, die in der Abfolge in 22 aufgelistet sind, die ein veranschaulichendes Diagramm 2200 und eine beispielhafte Abfolge von Aktionen ist, die verwendet werden, um ein Verfahren zum Anfordern von Vorlagen für das Verfahren der 21 gemäß mindestens einer Ausführungsform zu implementieren. In 22 entsprechen die Zahlen im Diagramm der Komponente in der Architektur, die beim Durchführen des entsprechenden nummerierten Schritts hilft.
Unter kurzer Bezugnahme auf die 19 und 22 sendet ein Benutzer in der aufgelisteten Abfolge in Schritt (1) eine Anforderung, um zu sehen, welche möglichen Speicherstapel für den Einsatzvorlagenverwaltungsdienst (DTMS) 1906 eingesetzt werden können. Die Benutzeranforderung kann Abfrageparameter bereitstellen, um die Abfrage einzuschränken. In Schritt (2) fordert der DTMS 1906 die Vorlagendefinitionen vom Vorlagen-CRUD-Dienst 1910 an. In Schritt (3) fordert der DTMS 1906 die Inventarinformation vom Inventar-CRUD-Dienst 2202 an (22). In Schritt (4) sammelt der DTMS 1906 die Daten und Vorlagen und sendet sie an den Richtlinienmanager 1908. In Schritt (5) wendet der Richtlinienmanagerdienst die Eingabe- und Regelsätze an, um einen Ergebnissatz zu erzielen, der an den DTMS 1906 zurückgegeben wird. In Schritt (6) filtert der DTMS 1906 Ergebnisse basierend auf Abfrageparametern, die in Schritt (1) gesendet werden. In Schritt (7) formuliert der DTMS 1906 einen Antwortkörper mit einem OK-Statuscode an den Anrufer. In Schritt (8) zeigt die Benutzererfahrung (UX-Erfahrung) oder Benutzerschnittstelle die Vorlagen basierend auf der Abfrage. Diese Vorlagen werden in Block 2130 von 21 zurückgegeben.
Unter erneuter Bezugnahme auf die 19 und 21 wird in Block 2140 eine Liste installierter Speicherdienste erhalten (Block 2140), und 23 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge 2300 von Aktionen, die verwendet werden, um ein Verfahren zum Erhalten installierter Speicherdienste für das Verfahren der 21 gemäß mindestens einer Ausführungsform zu implementieren. Unter kurzer Bezugnahme auf 23 und auf die darin gezeigte Abfolge wird in Schritt (1) eine Anforderung über die Plattform-REST-Endpunkte 502 gesendet, um eine Liste vorhandener Speicherstapel zu erhalten, die in der VIKI-Plattform installiert sind (GET/vi/Speicherdienst). Für jeden Speicherstapel sendet der Speichereinsatzdienst in Schritt (2) eine Anforderung an die Rechensteuerung, eine Liste von Knoten zu erhalten, auf denen der Speicherstapel mit dieser universellen eindeutigen Kennung (UUID) installiert ist (GET/vi/Rechen/Speicherdienst/{uuid}). In Schritt (3) gibt die Rechensteuerung an die REST-Endpunkte die Liste von Knoten zurück, auf denen eine Komponente des Speicherstapels installiert ist. In Schritt (4) kompiliert der SDS die Antwort und sendet die Antwort zurück an den Kunden. 23 enthält ein Beispiel für Nutzdaten 2302, die in Schritt (4) an den Kunden zurückgegeben werden können. Die beispielhaften Nutzdaten (die nur der Veranschaulichung dienen) enthalten eine Liste von Speicherdiensten, einschließlich UUD, Typ (z. B. Block, Datei usw.), Stapelname (z. B. VxFlex OS, SDNAS) und eine Liste von Knoten, auf denen der Stapel installiert ist.
Unter erneuter Bezugnahme auf die 19 und 21 erhält das Verfahren nach dem Erhalten der Liste installierter Speicherdienste (Block 2140) Echtzeitdaten installierter Speicherdienste (Block 2140), und 24 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge 2400 von Aktionen, die verwendet werden, um ein Verfahren zum Erhalten von Echtzeitdaten installierter Speicherdienste für das Verfahren der 21 gemäß mindestens einer Ausführungsform zu implementieren. Unter kurzer Bezugnahme auf 24 wird in Schritt (1) eine Anforderung an den Speichereinsatzdienst 2402 gesendet, um Details über vorhandene Speicherstapel zu erhalten, die im Inventar installiert sind (GET/vi/Speicherdienst/{uuid}/Details). In Schritt (2) führt der Speichereinsatzdienst 2402 einen REST-Aufruf an den Stapelkoordinator-(SC)-Dienst 2404 durch (GET/vi/Speicherdienst/{uuid}/Details). In Schritt (3) führt der SC-Dienst 2404 einen REST-Aufruf (GET/v1/Dienstregistrierung/{type}) an die Dienstregistrierung 2408 durch, damit der Typ der Steuerung zugreifen kann (z. B. Block, Datei). In Schritt (4) führt der SC-Dienst 2408 einen REST-Aufruf an die registrierte Steuerung 2406 durch (GET/vi/Speicherdienst/<type>/{uuid}/Details). In Schritt (5) führt die Steuerung 2406 einen REST-Aufruf (GET/vi/Dienstregistrierung/{type}/{stack}) an die Dienstregistrierung 2408 durch, damit die Stapelimplementierung zugreifen kann (z. B. VxFlex OS usw.). In Schritt (6) führt die Steuerung einen REST-Aufruf an die Stapelimplementierungssteuerung 532 durch (GET/vi/Speicherdienst/<type>/<stack>/{uuid}/Details). In Schritt (7) ruft ein Southbound-Treiber die Stapelverwaltungsschnittstelle auf, um spezifische Details zu erhalten. In Schritt (8) kompiliert der Speichereinsatzdienst 2402 die Stapeldetails und gibt eine Antwort an den Benutzer zurück.
Unter erneuter Bezugnahme auf die 19 und 21 kann der Speicherstapel eingesetzt werden, sobald die Architektur die Vorlage, installierte Speicherdienstdetails und die in Echtzeit installierten Speicherdienstdetails aufweist (Block 2160). Die 25 ist ein veranschaulichendes Diagramm und eine beispielhafte Abfolge 2500 von Aktionen, die verwendet werden, um ein Verfahren zum Einsetzen eines Speicherstapels für das Verfahren der 21 gemäß mindestens einer Ausführungsform zu implementieren. Unter kurzer Bezugnahme auf 25 wird in Schritt (1) eine Anforderung an den Speichereinsatzdienst gesendet, um einen Speicherstapel einzusetzen (POST/v1/Speicherdienst/Änderungsanforderung). In Schritt (2) sendet der Speichereinsatzdienst eine Anforderung an den Aufgabendienst, um eine neue Aufgabe zu erzeugen (POST/v1/Aufgaben). In Schritt (3) führt der Speichereinsatzdienst einen REST-Aufruf an den Stapelkoordinatororchestrierungsdienst (SCO) durch
(POST/v1/Speicherdienst/Änderungsanforderung). In Schritt (4) wird eine Aufgabe an den Benutzer zurückgegeben, so dass der Benutzer die Einsatzausführung überwachen kann. In Schritt (5) führt der SCO einen REST-Aufruf
(GET/v1/Dienstregistrierung/{type}) an die Dienstregistrierung durch, damit der Typ der Steuerung zugreifen kann (z. B. Block, Datei). In Schritt (6) führt der SCO einen REST-Aufruf an die korrekte Steuerung durch
(POST/v1/ Speicherdienst/<type>/Einsatz). In Schritt (7) führt die Steuerung einen REST-Aufruf (GET/v1/Dienstregistrierung/{type}/{stack}) an die Dienstregistrierung durch, damit die Stapelimplementierung zugreifen kann (z. B. VxFlex OS, SDNAS usw.).
In Schritt (8) führt die Steuerung einen REST-Aufruf an die Stapelimplementierungssteuerung durch, die Southbound-Treiber aufruft, um den Speicherstapel einzusetzen (POST/v1/Speicherdienst/<type>/<stack>/Einsatz). In Schritt (9) analysiert die Stapelsteuerung Ressourcen und orchestriert die durchzuführenden Arbeitsschritte. In Schritt (10) fordert eine Orchestrierungsanordnung eine Einsatzsteuerung von der Dienstregistrierung an. In Schritt (11) führt die Orchestrierungsanordnung einen REST-Aufruf an die Einsatzsteuerung durch. In Schritt (12) ruft die Einsatzsteuerung Bedrock auf und fragt die Aufgabe ab. In Schritt (13) wird, wenn die Aufgabe abgeschlossen ist, eine Nachricht auf den Bus gesetzt. In Schritt (14) abonniert die Orchestrierungsanordnung eine Nachricht vom Bus über die gerade ausgeführte Aufgabe. In Schritt (15) abonniert der SCO den Nachrichtenbus und verbraucht den Aufgabenstatus. In Schritt (16) markiert der SCO die Aufgabe mit dem geeigneten Status (abgeschlossen oder fehlgeschlagen). Dies beendet auch das Verfahren von 21.
Wie die obigen Ausführungsformen zeigen, kann eine einzelne, vereinheitlichte Verwaltungs- und Orchestrierungsschicht (M&O)-Schicht oder -Ebene mit Architekturen wie oben beschrieben konfiguriert werden, um Speicheranlagen von mehreren verschiedenen Anbietern automatisch zu installieren, zu konfigurieren, einzusetzen und zu verbrauchen, und kann verstehen, was zum Einsatz und zur Verkabelung erforderlich ist, um eine Speicheranforderung zu bedienen, und softwaredefinierte Speicherstapel als Ergebnis von prädiktiver Analyse, Richtlinie und Verwendung auf Anforderung des IT-Administrators hoch- oder herunterzufahren.
Die IT-Abteilungen verwenden softwaredefinierte Speicherplattformen, um die über Kapital und Betriebskosten zu reduzieren, die mit dem Einsetzen und Warten der Hardware verbunden sind, die mit speziell entwickelten Geräten (Speicheranordnungen) verbunden sind. Dies wird zunächst durch Standardisieren auf und Kaufen eines Satzes von Warenrechenservern, Zusammenstellen dieser mit einfacher Vernetzung und Installieren von softwaredefinierten Speicherstapeln erreicht, die Block-, Datei-, Objekt- oder Stream-Speicher über IP-basierte Protokolle bereitstellen.
Es können jedoch Herausforderungen auftreten, wenn versucht wird, die Nutzungen der Infrastruktur über viele Speichertypen hinweg zu maximieren. Eine versuchte Lösung bestand darin, bestimmte Server im Rack auf bestimmte Rollen zu beschränken. Zum Beispiel stellen die Server 1 -4 Blockspeicher, die Server 5 -8 Objektspeicher und so weiter bereit. Diese arbeitsblattbasierten Konfigurationspraktiken können zu verlorener Kapazität führen, und verlorene Kapazität auf einem Speichertyp bedeutet potenzielle Kapazitätsverhungerung für einen anderen Speichertyp im Verlauf.
Mindestens einige der vorgenannten Ausführungsformen demonstrierten und beschrieben eine vereinheitlichte Konfigurationsverwaltung, einschließlich des Einsatzes, der Installation, der Konfiguration und des Verbrauchs von softwaredefinierten Speicheranlagen. Mindestens einige dieser Ausführungsformen stellen eine Möglichkeit bereit, diese Rollen präskriptiv und manuell zu identifizieren und Richtlinien auf einen Inventar von Hardware anzuwenden, um softwaredefinierte Speicherstapel für zukünftigen Verbrauch automatisch zu installieren.
In weiteren Aspekten dieser Ausführungsformen werden zusätzliche Ausführungsformen bereitgestellt, die das Entfernen der präskriptiven, manuellen Einsatzschritte vollständig ermöglichen. Mindestens einige Ausführungsformen stellen einen Mechanismus bereit, bei dem Richtlinien und prädiktive Analysen auf Verbrauchsanforderungen vom Benutzer angewendet werden (Anforderungen zum Erzeugen von Volumes, Buckets, Dateifreigaben usw.) und auf den verfügbaren Hardwareinventar angewendet werden, um die Speichersoftware dynamisch zu installieren und zu konfigurieren. Dies ermöglicht es dem Kunden, mit nichts anderem als Hardwareinventar zu beginnen und dem Kunden Verbrauchsfähigkeit bereitzustellen, wobei die Verwaltungssoftware Speicherstapel bootet und Konfigurationsänderungen vornimmt, wenn Anforderungen in das System kommen. In bestimmten Ausführungsformen kann dies einen verbrauchsbasierten elastischen Einsatz und Neukonfiguration des softwaredefinierten Speichers bereitstellen.
Mindestens einige Ausführungsformen stellen einen automatisierten Mechanismus bereit, um Speicherstapel elastisch einzusetzen, die für die Anforderungen zum Verbrauchen von Speicher geeignet sind. Mindestens einige Ausführungsformen stellen eine Möglichkeit bereit, Speicherstapel verantwortungsvoll zu kontrahieren (Größe zu reduzieren) oder zu deinstallieren, wenn sie nicht mehr verwendet werden. Mindestens einige Ausführungsformen erweitern bestehende Speicherstapel zu zusätzlichen Knoten oder Laufwerken, um die Kapazität prädiktiv zu erhöhen. Mindestens einige Ausführungsformen stellen dem IT-Administrator Steuerungen bereit, um Operationen basierend auf Operationstypen zu steuern. (Installieren versus Erweitern versus Kontrahieren). Mindestens einige Ausführungsformen ermöglichen das Automatisieren der Installation, des Einsatzes und der Konfiguration usw. von Speicherstapeln, wie zuvor hierin beschrieben. Mindestens einige Ausführungsformen erweitern und/oder kontrahieren die Speicherverwendungsrichtlinie, prädiktive Analyse (vergangene Verwendung, die zukünftige Ergebnisse vorhersagt) elastisch. Mindestens einige Ausführungsformen führen die Installation/den Einsatz als Teil von Verbrauchsanforderungen durch.
In bestimmten Ausführungsformen wird eine Konfiguration bereitgestellt, wobei ein IT-Administrator einen Pool oder Inventar von Hardware (z. B. Server) identifiziert, die von softwaredefinierten Speicherplattformen verbraucht werden können. In einigen Ausführungsformen können die Server nur ein bloßes, unterstütztes Betriebssystem auf sich haben. Im Gegensatz zu einem manuell konfigurierten Rack von Servern, in dem ein vorgeschriebener Satz von Speichertypen auf einem festen Satz von Knoten installiert ist, die vom Benutzer definiert werden, bevor der Endbenutzer eine Anforderung zum Verbrauchen des Speichers stellt (ein Volume, eine Freigabe oder einen Bucket erzeugen), beginnt diese Konfiguration in bestimmten Ausführungsformen stattdessen, ohne dass Speicherstapel installiert sind, bevor Verbrauchsanforderungen zulässig sind.
Unter kurzer Bezugnahme auf die 3 und 4 beinhalten mindestens einige Ausführungsformen eine Komponente, die als der elastische Konfigurationsdienst 328 bezeichnet wird, innerhalb der M&O-Verwaltungsschicht/- ebene, die arbeitet, um mindestens die Funktionen zu implementieren, die mit den 26-28 verbunden sind, die nachstehend weiter beschrieben werden.
Es wird eine Situation betrachtet, in der ein Kunde/Client in einem computerbasierten oder informationsverarbeitenden Ökosystem, wie beispielsweise einem Cloud-Ökosystem, in einer Client-Server-Konfiguration vorhanden ist, aber der Kunde/Client keinen einzelnen Speicherstapel (noch) irgendwo im Ökosystem eingesetzt hat. Der Kunde hat jedoch Zugriff auf eine Architektur wie die oben beschriebene M&O-Ebene/-Schicht. Der Kunde/Client führt eine Anwendung wie eine ORACLE-Datenbank auf dem Server aus, und diese Anwendung benötigt hypothetisch 10 GB Speicher.
Mit den hierin beschriebenen Ausführungsformen ist der Kunde/Client in der Lage, ein 10-GB-Volumen für diesen Server anzufordern (im Gegensatz zu anderen hierin beschriebenen Anwendungsfällen), und in bestimmten Ausführungsformen sollte die hierin bereitgestellte Architektur in der Lage sein, basierend auf der Anforderung für die 10 GB Speicher genau zu erkennen, welche Art von Speicher benötigt wird, welche Ressourcen diese Funktion implementieren können, und auch die Fähigkeit haben, den Speicherstapel auszulassen und tatsächlich zu installieren, einzusetzen und zu konfigurieren, um in der Lage zu sein, diese Anforderung für die 10 GB zu erfüllen, und dann schließlich die Verwaltungssoftware dieses Speicherstapels aufzurufen, um das Volumen tatsächlich zu erzeugen. Somit ist es möglich, mit „nichts“ zu beginnen (kein Zugriff auf irgendwelche Datenspeicher), und so kann von nichts begonnen werden und dann tatsächlich ein Speicherstapel automatisch eingesetzt werden und bereit sein. Dies bietet auch einen wichtigen Vorteil für Kunden/Clients, da sie möglicherweise nicht für den zusätzlichen Speicher (die zusätzlichen 10 GB Datenspeicher) bezahlen müssen, bis der Kunde/Client ihn tatsächlich verwendet, und dieser Vorteil hat auch Anwendbarkeit in Cloud-Speicherkonfigurationen.
In mindestens einigen Ausführungsformen ermöglicht dieser Mechanismus dem IT-Administrator, einen Pool oder Inventar von Hardware (Server) zu identifizieren, die von softwaredefinierten Speicherplattformen verbraucht werden können. Die Server können nur ein bloßes, unterstütztes Betriebssystem auf sich haben. Im Gegensatz zu einem manuell konfigurierten Rack von Servern, in dem ein vorgeschriebener Satz von Speichertypen auf einem festen Satz von Knoten installiert ist, die vom Benutzer definiert werden, bevor der Endbenutzer eine Anforderung zum Verbrauchen des Speichers stellt (ein Volume, eine Freigabe oder einen Bucket erzeugen), beginnt dieser Mechanismus stattdessen, ohne dass Speicherstapel installiert sind, bevor Verbrauchsanforderungen zulässig sind, und stellt sie dann automatisch als Reaktion auf bestimmte Anweisungen bereit. Somit kann dies vorteilhafterweise das Durchführen einer Art von „Just-in-Time“-Installation und - Einsatz von Speicheranlagen ermöglichen, was kosten- und ressourceneffizienter ist, da Speicheranlagen nicht installiert oder eingesetzt werden, bis sie tatsächlich für den Verbrauch benötigt werden, wodurch Clients und Kunden Geld sparen, indem sie Speicheranlagen nicht installieren und einsetzen müssen, bis sie benötigt werden.
26 ist ein vereinfachtes Flussdiagramm eines beispielhaften Verfahrens 2600 zum Identifizieren eines Pools von Hardware, der von SDS-Plattformen verbraucht werden kann, und zum elastischen Erweitern/Kontrahieren bestehender Speicherstapel für mindestens die Architektur der 2-19 gemäß mindestens einer Ausführungsform. Dieses Flussdiagramm 2600 wird in Verbindung mit einem veranschaulichenden Beispiel erörtert, bei dem die Verwaltungsplattform (z. B. die SDS-M&O 102 von mindestens den 3-19, wie hierin beschrieben) installiert ist, aber dieses Beispiel nicht einschränkend ist und bereitgestellt wird, um einfach besser zu verstehen, wie die Prozessschritte funktionieren. In bestimmten Ausführungsformen ist die M&O in einem cloudnativen Orchestrierungsökosystem installiert, wie Kubernetes, Pivotal Cloud Foundry oder Pivotal Container Service (PKS). In bestimmten Ausführungsformen identifiziert ein IT-Administrator, bevor das Verfahren der 26 beginnt, ein Rack von Servern zur Verwendung durch die M&O 102-Verwaltungsplattform. In bestimmten Ausführungsformen können potenziell verwendbare Server automatisch identifiziert (und eingerichtet, eingesetzt, konfiguriert usw.) werden, gemäß den Architekturen und Verfahren, einschließlich der vereinheitlichten Schnittstelle für die Konfigurationsverwaltung, die hierin in Verbindung mit den 3-26 beschrieben ist.
In mindestens einer Ausführungsform wird das Verfahren der 26 in einer Konfiguration implementiert, in der die M&O-Verwaltungsplattform 102 einen festes Inventar enthält, um mit eingehende Anforderungen und unterstützten Speichertopologien übereinzustimmen. Obwohl die Verwendung eines festen Inventars nicht einschränkend ist, verbessert das Vorhandensein eines festen Inventars die Effizienz der Analyse von Anlagen, um ihre Fähigkeit zu beurteilen, Kundenbedürfnisse zu erfüllen. In einem Beispiel kann das feste Inventar, das gegen eingehende Speicheranforderungen und unterstützte Speichertopologien angepasst wird, die folgenden beispielhaften Eigenschaften beinhalten, aber dies ist natürlich nicht einschränkend:

• Die Speichertypen: Block, Datei, Objekt, Stream
• Speichertechnologien: VxFlex OS, PowerMax, Unity, ECS Flex, Isilon SD, Nautilus, AWS S3, SDNAS (und ihre jeweiligen Speichertypen, die sie unterstützen)
• Speicherprotokolle: iSCSI, FC, SDC (VxFlex OS), NAS

Unter Bezugnahme auf 26 wird in Block 2605 eine Anforderung von einem Benutzer für ein Blockvolumen einer vorbestimmten Größe „X“ an einen vorbestimmten Host „Y“ unter Verwendung einer vordefinierten Schnittstelle (z. B. einer Benutzerschnittstelle (UI) 314 wie oben beschrieben) empfangen (z. B. am Verwaltungs-REST-Endpunkt 316). In diesem Beispiel werden die folgenden Parameter angenommen:

• Benutzer: Anwendungsspezifische integrierte Schaltung
• Anforderungstyp: Bereitstellung von Speicher
• Speicher:
• Typ: Block
• Protokoll: iSCSI
• Größe: 10 GB
• Hosts: dbhosti.localhost, dbhost2.localhost

In Block 2010 wird die Verbrauchsanforderung für eine Information geparst, die betrifft: Spezifischer Mandant/Host; Benutzer; Anforderungstyp; Speichertyp; Speicherprotokoll. Somit interpretiert die Verwaltungsplattform 102 die empfangene Verbrauchsanforderung als einen bestimmten Typ, um einen bestimmten Mandanten und Host zu bedienen. Der elastische Einsatzdienst 328 (3 und 4) ist für das Abgleichen der Verbrauchsanforderung mit einer vorhandenen Speichertechnologieinstallation/-einsatz oder das Erweitern der Kapazität eines vorhandenen Einsatzes oder das Installieren eines neuen Speichertechnologieeinsatzes verantwortlich, um die Anforderung zu bedienen. Die folgenden Anforderungsfelder beeinflussen in bestimmten Ausführungsformen den elastischen Einsatzdienst 328: Benutzer, Anforderungstyp, Speichertyp und Speicherprotokoll. Als Teil dieses Parsens werden in bestimmten Ausführungsformen die Prozesse der 27-29 durchgeführt (Block 2611), und es werden Bestimmungen vorgenommen, um welchen Anforderungstyp es sich handelt (Block 2612) und ob die Speichertechnologie das erforderliche Speicherprotokoll bereitstellen kann (Block 2613). Dies wird nachstehend weiter erläutert.
Unter kurzer Bezugnahme auf 27 ist 27 ein vereinfachtes Flussdiagramm 2700 eines Verfahrens zum Parsen einer Verbrauchsanforderung für eine Benutzerinformation für das Flussdiagramm der 28 gemäß mindestens einer Ausführungsform. In Block 2710 wird das Benutzerfeld auf Datentrennung basierend auf Benutzer/Mandanten, Dienstebene, Richtlinie überprüft. Abhängig von der Richtlinie und Dienstebene, für die der Kunde bezahlt, muss der elastische Einsatzdienst 328 sicherstellen, dass die Daten dieses Benutzers von den Daten anderer Benutzer getrennt werden. („Mandant“ kann hier für den Benutzer ausgetauscht werden, da ganze Organisationen/Unternehmen wünschen können, dass ihre Daten von den Daten anderer Unternehmen getrennt werden). So wird in Block 2720 geprüft, ob die Benutzerdaten des Kunden von anderen Benutzerdaten zu trennen sind. Wenn die Antwort bei Block 2720 „NEIN“ ist (d. h. Kundenbenutzerdaten müssen nicht getrennt werden), wird bei Block 2722 geprüft, ob der Benutzer bereits einen oder mehrere Speicherstapel hat, der bereits mit anderen Kunden koexistiert. Wenn die Antwort bei Block 2722 „JA“ ist, kann der elastische Einsatzdienst 328 den vorhandenen Speicherstapel als Kandidaten für die Blockvolumenanforderung von Block 2605 betrachten (16). Eine Instanz, wenn die Antwort bei Block 2722 „JA“ sein könnte, ist eine Situation, in der der Benutzer oder Mandant für eine kostengünstigere Richtlinie bezahlen kann, bei der sein Speicherstapel mit anderen Kunden koexistiert. In diesem Fall kann, wenn dieser Speicherstapel bereits existiert, er zur Verwendung mit dieser Anforderung betrachtet werden.
Wenn die Antwort bei Block 2722 „NEIN“ ist (was bedeutet, dass die Daten nicht getrennt werden müssen, aber der Benutzer nicht bereits einen Speicherstapel eingesetzt hat), muss der elastische Einsatzdienst 328 neuen Speicher installieren/einsetzen (z. B. unter Verwendung der hierin bereits beschriebenen Verfahren in Verbindung mit 3-25 usw.).
Unter erneuter Bezugnahme auf Block 2720 muss, wenn die Antwort bei Block 2720 „JA“ ist (Kundendaten müssen getrennt werden), der elastische Einsatzdienst 328 dann, abhängig von der Richtlinie und Dienstebene, für die der Kunde bezahlt, sicherstellen, dass die Daten dieses Benutzers von den Daten anderer Benutzer getrennt werden. (In bestimmten Ausführungsformen kann „Mandant“ hier für den Benutzer ausgetauscht werden, da ganze Organisationen/Unternehmen wünschen können, dass ihre Daten von den Daten anderer Unternehmen getrennt werden). Wenn also bei Block 2720 ein „JA“ ist, wird geprüft, ob der Benutzer bereits einen Speicherstapel vom gleichen Typ (z. B. dem Typ „Block“) in demselben (Speicher-Netzwerk eingesetzt hat (Block 2730). Wenn die Antwort bei Block 2730 „JA“ ist, kann der elastische Einsatzdienst 328 dann den vorhandenen Speicherstapel als Kandidaten für die Anforderung von Block 2605 von 26 betrachten (z. B. für eine Blockvolumenanforderung für ein 10-GB-Volumen) (Block 2724).
Wenn die Antwort bei Block 2730 „NEIN“ ist, lernt der elastische Einsatzdienst 328, wenn der Benutzer keinen Speicherstapel vom gleichen Typ eingesetzt hat, dass er einen neuen Speicherstapel installieren/bereitstellen muss (Block 2740), z. B. unter Verwendung der vorgenannten Verfahren und Architekturen von 3-25. Das Verfahren kehrt dann zu Block 2612 von 26 zurück (Block 2750).
Unter erneuter Bezugnahme auf 26 wird bei Block 2612 der Anforderungstyp geprüft, um zu sehen, ob es eines von Folgendem ist: Bereitstellen, Erweitern, Entfernen/Löschen, Verbinden oder Entfernen von Konnektivität (Block 2612). Zum Beispiel könnte die Anforderung eine Anforderung zum Erzeugen (Bereitstellen) von Speicher für einen Host/Cluster, Erweitern von bestehendem Speicher oder Entfernen/Löschen von Speicher sein. Sie könnte auch verwendet werden, um bestehenden Speicher mit zusätzlichen Hosts/Clustern zu verbinden oder um Konnektivität des Speichers mit oder vom Host zu entfernen.
In Block 2613 wird eine Prüfung durchgeführt, um zu bestimmen, ob eine beliebige verfügbare Speichertechnologie das erforderliche Speicherprotokoll bereitstellen kann (das erforderliche Protokoll, das in der Anforderung benannt ist). Das Speicherprotokoll (z. B. eines von FC, iSCSI, SDC [VxFlex OS], NAS) treibt eine Richtlinie innerhalb der Verwaltungsplattform an, da jede Speichertechnologie nur bestimmte Protokolle bereitstellen kann. Wenn zum Beispiel die Anforderung in Block 2605 „iSCSI“ als das Protokoll spezifiziert und die Liste der verfügbaren Speichertechnologien war: nur SDNAS und Isilon, dann würde Block 2613 wählen, Isilon einzusetzen, da Dell EMC SDNAS kein iSCSI-Protokoll bereitstellen kann. Die Verarbeitung fließt dann von Block 2613 zu Block 2615. Es ist auch anzumerken, dass in 26 die Reihenfolge der Prüfungsfelder beim Parsen der Verbrauchsanforderung in Block 2610 veranschaulichend und nicht einschränkend ist; Felder können in beliebiger Reihenfolge geprüft werden.
Unter Bezugnahme auf die Blöcke 2615 und 2620 wird das aktuelle SDS analysiert, um zu bestimmen, ob ein beliebiger Speicher des angeforderten Typs existiert. Die Verwaltungsplattform 328 verwendet dieses Feld, um zu bestimmen, ob ein Speicherstapel eingesetzt ist, der dem angeforderten Typ entspricht. Die Verwaltungsplattform weist einen Inventar unterstützter Speichertypen und Technologien auf, die diese Typen bedienen können. Als ein veranschaulichendes (aber nicht einschränkendes) Beispiel beinhaltet die Inventarliste in einer Ausführungsform:

• Block: VxFlex OS (Standard), PowerMax, Unity
• Datei: Dell EMC SDNAS [softwaredefinierter NAS] (Standard), Isilon SD
• Objekt: Dell EMC ECS (Standard), AWS S3
• Stream: Dell EMC Nautilus

Der elastische Einsatzdienst 328 ist konfiguriert, um zu wissen, welche Speichertechnologie über zwei Mechanismen verwendet werden soll: Wenn keine nicht standardmäßigen Speicherstapel eingesetzt sind, dann wird die standardmäßige Speicherstapeltechnologie verwendet, aber wenn keine nicht standardmäßige Speicherstapeltechnologie in den Anforderungsnutzdaten identifiziert wird, dann wird die standardmäßige Speicherstapeltechnologie verwendet. Andernfalls verwendet die Richtlinie die angegebene/nicht standardmäßige Speichertechnologie für Anforderungen. Somit springt in Block 2615 der 26 das Verfahren kurz zu 28 (Block 2616), die ein vereinfachtes Flussdiagramm 2800 eines Verfahrens zum Parsen einer Verbrauchsanforderung für eine Speichertypinformation gemäß mindestens einer Ausführungsform ist.
Unter kurzer Bezugnahme auf 28 beginnt die Verarbeitung in 28 von Block 2616 der 26 bei Block 2810. Die Speichertypen werden analysiert (Block 2820), um zu bestimmen, ob ein eingesetzter Speicherstapel existiert, der dem angeforderten Typ entspricht (z. B. einem von Blocktyp, Dateityp, Objekttyp und Streamtyp). Um zu bestimmen, welche Speichertechnologie verwendet werden soll, prüft der elastische Einsatzdienst 328, ob keine nicht standardmäßigen Speicherstapel eingesetzt sind (Block 2830). Wenn die Antwort „NEIN“ ist, dann wird die standardmäßige Speicherstapeltechnologie verwendet (Block 232). Falls die Antwort bei Block 2830 „JA“ ist, werden nicht standardmäßige Speicherstapel (bereits) eingesetzt, dann wird geprüft, ob die Anforderungsnutzdaten einen nicht standardmäßigen Speicherstapel identifiziert haben, der verwendet werden soll (Block 2840). Falls die Antwort bei Block 2840 „NEIN“ ist, bedeutet dies, dass die Anforderungsnutzdaten eine bestimmte Speichertechnologie nicht anzugeben scheinen, so dass es zulässig ist, die standardmäßige Speicherstapeltechnologie für das System zu verwenden (Block 2832).
Falls bei Block 2840 die Antwort „JA“ ist, dass die Anforderungsnutzdaten eine nicht standardmäßige Speichertechnologie darin enthalten, dann sollten die Anforderungen konfiguriert werden, die angegebene nicht standardmäßige Speichertechnologie zu verwenden (Block 2850). Die Verarbeitung kehrt dann bei Block 2860 zurück zu Block 2616 von 26.
Unter erneuter Bezugnahme auf 26 werden bei Block 2616 Ergebnisse zurückgegeben, die angeben, ob Speicher des angeforderten Typs existiert (Blöcke 2615 und 2620). Wenn also bei Block 2620 Speicher des angeforderten Typs existiert (Antwort bei Block 2620 ist JA), dann wird der Speicherstapel rekonfiguriert, um die Anforderung zu erfüllen (Block 2637), und optional kann eine Benachrichtigung gesendet werden, dass der neue Stapel eingesetzt wurde (Block 2639). Abhängig von den IT-Administratoreinstellungen kann der Einsatz automatisch stattfinden. In bestimmten Ausführungsformen kann ein optionaler Vorschau-/Pausenschritt (zwischen den Blöcken 2620 und 2637) stattfinden, wobei eine Entität wie ein Endbenutzer oder ein IT-Manager vor dem Einsatz eine endgültige Genehmigung geben kann.
Unter erneuter Bezugnahme auf Block 2620 wird, wenn Speicher des angeforderten Typs nicht existiert (Antwort bei Block 2620 ist „NEIN“), dann wird in bestimmten Ausführungsformen der hierin beschriebene elastische Einsatzdienst 328 konfiguriert, um die aktuelle Landschaft der softwaredefinierten Speicheranlagen zu analysieren und hat bestimmt, dass kein Speicher des angeforderten Typs existiert. Um bei dem Einsatz, der Konfiguration und Bereitstellung von Speicher eines geeigneten oder geeigneten Typs in einigen Ausführungsformen zu helfen, identifiziert der elastische Einsatzdienst in Block 2625 eine geeignete Vorlage (Satz von Bereitstellungsattributen) des Typblocks, die auf den Inventar anzuwenden ist, wobei berücksichtigt wird:

• Die angeforderte Größe (einige Größen können von einigen Hosts im Inventar nicht erfüllt werden)
• Der angeforderte Host (Hosts mit vorherigen Anforderungen bevorzugen im Allgemeinen eine nachfolgende Speicherung aus derselben Quelle)
• Vergangene Leistung (Bewertung) solcher Anforderungen und der abonnierte Einsatz (Analyse, die die zukünftige Leistung von Arbeitsschritten vorhersagt)
• Leistung/Ressourcen des Inventars (andere Speicherstapel können in Verwendung sein, und es kann wünschenswert sein, die Installation neuer Stapel auf ihnen zu vermeiden, abhängig von der Richtlinie und den Bedingungen)
• Kompatibilität von Speicherstapeln (einige Speicherstapel koexistieren neben anderen Speicherstapeln, einige jedoch nicht), um zu bestimmen, ob Multi-Stack auf einem einzelnen Server zulässig ist.

In Block 2630 empfängt der elastische Einsatzdienst 328 die Dienstanalyseergebnisse gemäß den Einstellungen. Die Analyse des elastischen Einsatzdiensts führt zu verschiedenen unterstützten Möglichkeiten (abhängig von den IT-Administratoreinstellungen). Wenn die Anforderung automatisch erfüllt werden kann (Antwort ist „JA“ bei Block 2635, dann wird der Speicherstapel eingesetzt (z. B. wenn Speicher verfügbar ist, aber noch nicht eingesetzt ist) oder rekonfiguriert (z. B. Speicher wird eingesetzt, aber seine Zuordnung muss sich in irgendeiner Weise ändern, um die Anforderung zu erfüllen), um die Anforderung zu erfüllen, ohne Administratoreingriff (Block 2637). Wenn die Einstellungen es erfordern, kann optional eine Benachrichtigung gesendet werden (z. B. an einen Benutzer, IT-Administrator oder eine andere Entität zum Empfangen von Benachrichtigungen), um zu warnen, dass ein neuer Stapel eingesetzt wurde (Block 2639).
Wenn die Anforderung nicht automatisch erfüllt werden kann (d. h. Antwort bei Block 2635 ist „NEIN“), dann kann es sein, dass die Konfiguration so ist, dass einige manuelle Aktionen, wie Genehmigung oder Überprüfung der Änderung oder eine geführte Ausführung, stattfinden müssen, bevor die Anforderung ausgeführt wird. In Block 2640 wird geprüft, ob die Anforderung mit Benutzereingaben, wie Überprüfung oder geführte Ausführung, erfüllt werden kann. Wenn die Antwort bei Block 2640 JA ist, dann ist der elastische Einsatzdienst 328 konfiguriert, um ein „Menü“ von Optionen für den IT-Administrator bereitzustellen, um die Ausführung zu führen, wodurch eine bessere präskriptive Automatisierung für zukünftige Anforderungen bereitgestellt wird.
Zum Beispiel kann der elastische Einsatzdienst 328 eine empfohlene Vorlage bereitstellen, um die empfangenen Anforderungen zu erfüllen (Block 2642), und der neue Speicherstapel wird gemäß einer geführten Benutzerauswahl eingesetzt oder rekonfiguriert (Block 2644).
Ein anderes Ergebnis bei Block 2640 ist eine „NEIN“-Antwort, da die Anforderung nicht mit Benutzereingaben erfüllt werden kann, sodass es keine möglichen Wege gibt, um die Anforderung zu erfüllen, was zu einem Fehlschlag der Anforderung führt (Block 2645). Ein Fehlschlag kann aus verschiedenen Gründen auftreten, einschließlich, aber nicht beschränkt auf, kein Inventar, nicht genug Inventar oder die Ressourcen des Inventars sind bereits anderen Speichertypen oder Stapeln zugeordnet.
Die obige Beschreibung für die 26-28 in Verbindung mit den 3, 4 demonstriert den elastischen Einsatzdienst 328 in bestimmten Ausführungsformen, akzeptiert Verbrauchsanforderungen, um Speicher zu erstellen, zu löschen, zu erweitern und bestimmt den besten Ablauf der bereitzustellenden Aktion. Bei bestimmten Ausführungsformen trägt ein Vorteil von mindestens einigen Ausführungsformen der hierin beschriebenen Architektur und Verfahren dazu bei, minimale Einsätze zu etablieren, da der vorlagenbasierte Einsatz, Installation und Konfiguration von Speicherstapeln potenzielle zukünftige Verwendung berücksichtigt, um den gesamten zeitaufwändigen Prozess der Installation von Speicherstapeln zu reduzieren. Zusätzlich ist ein weiterer Vorteil von mindestens einigen hierin beschriebenen Ausführungsformen die Fähigkeit, die Kapazität zu maximieren, da mindestens einige Ausführungsformen des elastischen Einsatzdiensts 328 dazu beitragen, verlorene Kapazität zu verhindern, indem nur ein Teil des Festplattenspeichers des Servers, wo möglich, zugeordnet wird. Ferner ist ein weiterer Vorteil von mindestens einigen hierin beschriebenen Ausführungsformen dazu beitragend, die Rechenleistung zu maximieren, da der elastische Einsatz Speicherstapel auf einem einzelnen Server kombiniert, um die Rechenressourcen zu maximieren. Außerdem ist noch ein weiterer Vorteil von mindestens einigen hierin beschriebenen Ausführungsformen die Möglichkeit, Ressourcen neu zuzuweisen, da mindestens einige Ausführungsformen des hierin beschriebenen elastischen Einsatzes Speicherstapel von einem Knoten zum anderen bewegen können, um die Dienstebenenziele zu erfüllen.
Das Testen an mindestens einigen hierin beschriebenen Ausführungsformen beinhaltete eine Fallstudie, bei der Block- und Dateispeicherstapelkomponenten auf denselben Knoten erfolgreich installiert (und eingesetzt und konfiguriert...) wurden (wobei einzigartige lokale Speichervolumen für jeden Stapel zugewiesen wurden).
In den vorstehend beschriebenen Flussdiagrammen und Sequenzdiagrammen stellen bestimmte Elemente (z. B. rechteckige Elemente, rautenförmige Elemente und Anweisungen, denen eine Zahl in einem Kreis vorausgeht), hierin als „Verarbeitungsblöcke“ bezeichnet, Computersoftwareanweisungen oder Gruppen von Anweisungen dar. Alternativ können die Verarbeitungsblöcke Schritte darstellen, die von funktionell äquivalenten Schaltungen wie einer digitalen Signalprozessor- (DSP) Schaltung oder einer anwendungsspezifischen integrierten Schaltung (ASIC) durchgeführt werden. Die Flussdiagramme und Sequenzdiagramme stellen nicht die Syntax einer bestimmten Programmiersprache dar, sondern veranschaulichen vielmehr die funktionale Information, die der Fachmann auf dem Gebiet benötigt, um Schaltungen herzustellen oder Computersoftware zu erzeugen, um die erforderliche Verarbeitung der bestimmten Vorrichtung durchzuführen. Es ist zu beachten, dass viele Routineprogrammelemente, wie die Initialisierung von Schleifen und Variablen und die Verwendung von temporären Variablen, aus Gründen der Klarheit weggelassen werden können. Die beschriebene bestimmte Sequenz von Blöcken ist nur veranschaulichend und kann variiert werden, ohne vom Geist der Konzepte, Strukturen und Techniken abzuweichen, die hierin geschützt werden sollen. Sofern nicht anders angegeben, sind die nachstehend beschriebenen Blöcke ungeordnet, was bedeutet, dass, wenn möglich, die durch die Blöcke dargestellten Funktionen in jeder geeigneten oder wünschenswerten Reihenfolge ausgeführt werden können.
Ferner können die hierin beschriebenen Prozesse und Arbeitsschritte durch einen Computer durchgeführt werden, der speziell für den gewünschten Zweck konfiguriert ist, oder durch einen Universalcomputer, der speziell für den gewünschten Zweck durch ein anderes Computerprogramm konfiguriert ist, das in einem computerlesbaren Speichermedium oder im Speicher gespeichert ist.
Die 29 ist ein vereinfachtes Blockdiagramm einer Vorrichtung, die verwendet werden kann, um mindestens einen Teil der Systeme, Architekturen, Sequenzdiagramme und des Verfahrens der 1-28 gemäß mindestens einigen Ausführungsformen zu implementieren.
Wie in 29 gezeigt, kann der Computer 2900 einen Prozessor 2902, einen flüchtigen Speicher 2904 (z. B. RAM), einen nichtflüchtigen Speicher 2906 (z. B. ein oder mehrere Festplattenlaufwerke (HDDs), ein oder mehrere Festkörperlaufwerke (SSDs), wie beispielsweise ein Flash-Laufwerk, ein oder mehrere Hybride magnetische und Festkörperlaufwerke und/oder ein oder mehrere virtuelle Speichervolumen, wie beispielsweise einen Cloud-Speicher, oder eine Kombination von physischen Speichervolumen und virtuellen Speichervolumen), eine grafische Benutzerschnittstelle (GUI) 2910 (z. B. einen Touchscreen, eine Anzeige und so weiter) und ein Eingabe- und/oder Ausgabegerät (I/O) 2908 (z. B. eine Maus, eine Tastatur usw.) beinhalten. Der nichtflüchtige Speicher 2904 speichert z. B. Journaldaten 2904a, Metadaten 2904b und vorab zugeordnete Speicherbereiche 2904c. Der nichtflüchtige Speicher 2906 kann in einigen Ausführungsformen ein Betriebssystem 2914 und Computeranweisungen 2912 und Daten 2916 beinhalten. In bestimmten Ausführungsformen sind die Computeranweisungen 2912 konfiguriert, um mehrere Teilsysteme bereitzustellen, einschließlich eines Routing-Teilsystems 2912A, eines Steuerteilsystems 2912b, eines Datenteilsystems 2912C und eines Schreibcachespeichers 2912d. In bestimmten Ausführungsformen werden die Computeranweisungen 2912 durch den Prozessor/die CPU 2902 aus dem flüchtigen Speicher 2904 ausgeführt, um mindestens einen Teil der in 2-8 gezeigten Prozesse durchzuführen. Programmcode kann auch auf Daten angewendet werden, die unter Verwendung eines Eingabegeräts oder GUI 2910 eingegeben oder von dem I/O-Gerät 2908 empfangen werden.
Die Systeme, Architekturen, Sequenzen, Flussdiagramme und Prozesse der 1-28 sind nicht auf die Verwendung mit der Hardware und Software beschränkt, die hierin beschrieben und veranschaulicht sind, und können in jeder Rechen- oder Verarbeitungsumgebung und mit jeder Art von Maschine oder Satz von Maschinen, die ein Computerprogramm ausführen können, anwendbar sein. Die hierin beschriebenen Prozesse können in Hardware, Software oder einer Kombination der beiden implementiert werden. Die Logik zum Ausführen des Verfahrens kann als Teil des in 29 beschriebenen Systems verkörpert sein, das zum Ausführen eines Verfahrens nützlich ist, das unter Bezugnahme auf Ausführungsformen beschrieben ist, die beispielsweise in 1-28 gezeigt sind. Die hierin beschriebenen Prozesse und Systeme sind nicht auf die beschriebenen spezifischen Ausführungsformen beschränkt, noch sind sie speziell auf die gezeigte spezifische Verarbeitungsreihenfolge beschränkt. Vielmehr kann jeder der Blöcke der Prozesse neu geordnet, kombiniert oder entfernt werden, parallel oder seriell durchgeführt werden, wie es erforderlich ist, um die hierin dargelegten Ergebnisse zu erzielen.
Der Prozessor 2902 kann durch einen oder mehrere programmierbare Prozessoren implementiert werden, die ein oder mehrere Computerprogramme ausführen, um die Funktionen des Systems durchzuführen. Wie hierin verwendet, beschreibt der Begriff „Prozessor“ eine elektronische Schaltung, die eine Funktion, einen Arbeitsablauf oder eine Sequenz von Arbeitsabläufen durchführt. Die Funktion, der Arbeitsablauf oder die Sequenz von Arbeitsabläufen kann in die elektronische Schaltung hartcodiert oder durch Anweisungen, die in einer Speichervorrichtung gehalten werden, weichcodiert sein. Ein „Prozessor“ kann die Funktion, den Arbeitsablauf oder Sequenz von Arbeitsabläufen unter Verwendung von digitalen Werten oder unter Verwendung von analogen Signalen durchführen. In einigen Ausführungsformen kann der „Prozessor“ in einer oder mehreren anwendungsspezifischen integrierten Schaltungen (ASICs) verkörpert sein. In einigen Ausführungsformen kann der „Prozessor“ in einem oder mehreren Mikroprozessoren mit zugehörigem Programmspeicher verkörpert sein. In einigen Ausführungsformen kann der „Prozessor“ in einer oder mehreren diskreten elektronischen Schaltungen verkörpert sein. Der „Prozessor“ kann ein analoges, digitales oder gemischtes Signal sein. In einigen Ausführungsformen kann der „Prozessor“ ein oder mehrere physische Prozessoren oder ein oder mehrere „virtuelle“ (z. B. entfernt angeordnete oder „Cloud“) Prozessoren sein.
Verschiedene Funktionen von Schaltungselementen können auch als Verarbeitungsblöcke in einem Softwareprogramm implementiert werden. Eine solche Software kann beispielsweise in einem oder mehreren digitalen Signalprozessoren, Mikrocontrollern oder Universalcomputern eingesetzt werden. Beschriebene Ausführungsformen können in Hardware, einer Kombination von Hardware und Software, in Software oder in Software implementiert werden, die von einem oder mehreren physischen oder virtuellen Prozessoren ausgeführt wird.
Einige Ausführungsformen können in Form von Verfahren und Vorrichtungen zum Praktizieren dieser Verfahren implementiert werden. Beschriebene Ausführungsformen können auch in Form von Programmcode implementiert werden, der beispielsweise in einem Speichermedium gespeichert, in eine Maschine geladen und/oder von einer Maschine ausgeführt oder über ein Übertragungsmedium oder einen Träger übertragen wird, wie beispielsweise über elektrische Verdrahtung oder Verkabelung, durch Faseroptik oder über elektromagnetische Strahlung. Ein nichtflüchtiges maschinenlesbares Medium kann physische Medien beinhalten, ist aber nicht beschränkt auf physische Medien, wie beispielsweise magnetische Aufzeichnungsmedien einschließlich Festplatten, Disketten und Magnetbandmedien, optische Aufzeichnungsmedien einschließlich Compact Discs (CDs) und Digital Versatile Discs (DVDs), Festkörperspeicher wie Flash-Speicher, hybrid-magnetischer und Festkörperspeicher, nichtflüchtiger Speicher, flüchtiger Speicher und so weiter, beinhaltet aber nicht ein flüchtiges Signal per se. Wenn die Maschine in einem nichtflüchtigen maschinenlesbaren Medium verkörpert ist und der Programmcode in eine Maschine geladen und von dieser ausgeführt wird, wie beispielsweise einen Computer, wird die Maschine zu einer Vorrichtung zum Praktizieren des Verfahrens.
Wenn sie auf einer oder mehreren Verarbeitungsgeräten implementiert sind, kombinieren sich die Programmcodesegmente mit dem Prozessor, um ein einzigartiges Gerät bereitzustellen, das analog zu spezifischen Logikschaltungen arbeitet. Solche Verarbeitungsgeräte können beispielsweise einen Universalmikroprozessor, einen digitalen Signalprozessor (DSP), einen Computer mit reduziertem Befehlssatz (RISC), einen Computer mit komplexem Befehlssatz (CISC), eine anwendungsspezifische integrierte Schaltung (ASIC), eine feldprogrammierbare Gatteranordnung (FPGA), eine programmierbare Logikanordnung (PLA), einen Mikrocontroller, eine eingebettete Steuerung, einen Mehrkernprozessor und/oder andere beinhalten, einschließlich Kombinationen von einem oder mehreren der vorstehenden. Beschriebene Ausführungsformen können auch in Form eines Bitstroms oder einer anderen Sequenz von Signalwerten implementiert werden, die elektrisch oder optisch durch ein Medium übertragen werden, gespeicherte Magnetfeldvariationen in einem magnetischen Aufzeichnungsmedium usw., die unter Verwendung eines Verfahrens und/oder einer Vorrichtung, wie in den Ansprüchen angegeben, erzeugt werden.
Wenn beispielsweise der Programmcode in eine Maschine geladen und von dieser ausgeführt wird, wie beispielsweise den Computer von 29, wird die Maschine zu einer Vorrichtung zum Praktizieren der Erfindung. Wenn er auf einem oder mehreren Universalprozessoren implementiert ist, kombiniert sich der Programmcode mit einem solchen Prozessor, um eine einzigartige Vorrichtung bereitzustellen, die analog zu spezifischen Logikschaltungen arbeitet. Als solche kann eine digitale Universalmaschine in eine digitale Spezialmaschine umgewandelt werden. 29 zeigt Programmlogik 2924, verkörpert auf einem computerlesbaren Medium 2920, wie gezeigt, und wobei die Logik in computerausführbarem Code codiert ist, der zum Ausführen des Reservierungsdienstprozesses dieser Erfindung und dadurch zum Bilden eines Computerprogrammprodukts 2922 konfiguriert ist. Die Logik kann dieselbe Logik auf dem auf dem Prozessor geladenen Speicher sein. Die Programmlogik kann auch in Softwaremodulen, als Module oder als Hardwaremodule verkörpert sein. Ein Prozessor kann ein virtueller Prozessor oder ein physischer Prozessor sein. Logik kann über mehrere Prozessoren oder virtuelle Prozessoren verteilt sein, um die Logik auszuführen.
In einigen Ausführungsformen kann ein Speichermedium ein physisches oder logisches Gerät sein. In einigen Ausführungsformen kann ein Speichermedium aus physischen oder logischen Geräten bestehen. In einigen Ausführungsformen kann ein Speichermedium über mehrere physische und/oder logische Geräte abgebildet sein. In einigen Ausführungsformen kann ein Speichermedium in einer virtualisierten Umgebung vorhanden sein. In einigen Ausführungsformen kann ein Prozessor eine virtuelle oder physische Ausführungsform sein. In einigen Ausführungsformen kann eine Logik über einen oder mehrere physische oder virtuelle Prozessoren ausgeführt werden.
Zum Zwecke der Veranschaulichung der vorliegenden Ausführungsform werden die offenbarten Ausführungsformen als in einer bestimmten Konfiguration und unter Verwendung spezieller logischer Anordnungen verkörpert beschrieben, aber der Fachmann auf dem Gebiet erkennt, dass das Gerät nicht auf die bestimmte Konfiguration beschränkt ist, sondern nur durch die in dieser Beschreibung enthaltenen Ansprüche. Darüber hinaus wird erwartet, dass während der Laufzeit eines Patents, das aus dieser Anmeldung stammt, viele relevante Technologien entwickelt werden und die Umfänge der entsprechenden Begriffe alle diese neuen Technologien a priori beinhalten sollen.
Die Begriffe „umfasst“, „umfassend“, „beinhaltet“, „beinhaltend“, „aufweisend“ und ihre Entsprechungen bedeuten zumindest „beinhaltend, aber nicht beschränkt auf“. Wie hierin verwendet, beinhaltet die Singularform „ein“, „eine“ und „der/die/das“ Mehrzahlbezüge, sofern der Kontext nicht eindeutig etwas anderes vorschreibt. Verschiedene Elemente, die im Kontext einer einzelnen Ausführungsform beschrieben werden, können auch separat oder in einer beliebigen geeigneten Unterkombination bereitgestellt werden. Es versteht sich ferner, dass verschiedene Änderungen in den Details, Materialien und Anordnungen der Teile, die hierin beschrieben und veranschaulicht wurden, durch den Fachmann vorgenommen werden können, ohne vom Umfang der folgenden Ansprüche abzuweichen.

Claims

Computer implementiertes Verfahren zum Einsetzen von Speicheranlagen, das Verfahren umfassend: Zugreifen auf eine Verbrauchsanforderung zum Verbrauchen von Speicheranlagen, die Verbrauchsanforderung umfassend einen Stapelparameter und einen Ressourceneigenschaftsparameter, wobei der Stapelparameter mindestens einen Typ von angeforderter Speicheranlage spezifiziert und der Ressourceneigenschaftsparameter mindestens eine von der Speicheranlage benötigte Funktionsfähigkeit spezifiziert; Bestimmen, basierend auf dem Stapelparameter, eines Satzes von einer oder mehreren ersten Speicheranlagen, die in der Lage sind, die Verbrauchsanforderung zu erfüllen; für jede erste Speicheranlage im Satz, der nicht eingesetzt wird, Generieren eines ersten Arbeitsablaufs, der konfiguriert ist, um die jeweilige erste Speicheranlage im Satz einzusetzen, der nicht eingesetzt wird; für jede zweite Speicheranlage im Satz, der den Ressourceneigenschaftsparameter nicht aufweist, Generieren eines zweiten Arbeitsablaufs, der konfiguriert ist, um diese Ressourceneigenschaft in der jeweiligen zweiten Speicheranlage zu implementieren; und Konfigurieren des Satzes von Speicheranlagen, um die Verbrauchsanforderung zu erfüllen, wobei das Konfigurieren das Ablaufen des ersten und zweiten Arbeitsablaufs umfasst.
Computer implementiertes Verfahren nach Anspruch 1, ferner umfassend: Bestimmen, dass eine dritte Speicheranlagenressource erzeugt werden kann, um die Verbrauchsanforderung zu erfüllen; und Generieren eines dritten Arbeitsablaufs, der konfiguriert ist, um die dritte Speicheranlagenressource zu erzeugen und einzusetzen.
Computer implementiertes Verfahren nach Anspruch 2, wobei die dritte Speicheranlagenressource innerhalb mindestens einer der ersten und zweiten Speicheranlagen gebildet wird.
Computer implementiertes Verfahren nach Anspruch 1, wobei die Verbrauchsanforderung zum Bereitstellen einer Dateifreigabe dient, und wobei das computer implementierte Verfahren ferner umfasst: Kontaktieren eines oder mehrerer LINUX-Hosts, um eine Hostinformation zu ermitteln und zu speichern; Registrieren des einen oder der mehreren LINUX-Hosts; Anfordern eines Einsatzes eines vorbestimmten Typs von Speicheranlagen als jeweilige Dienste; und Erzeugen einer entsprechenden Dateifreigabe.
Computer implementiertes Verfahren nach Anspruch 1, wobei die Verbrauchsanforderung eine Abfrage umfasst, die Abfrageparameter enthält, die sich auf eine Suche eines Inventars der Speicheranlagen beziehen, und wobei das computer implementierte Verfahren ferner umfasst: Vordefinieren eines Satzes von Vorlagen, die auf die Speicheranlagen anwendbar sind, wobei jede jeweilige Vorlage eine Konfiguration der jeweiligen Speicheranlage und Voraussetzungen zum Einsetzen der Speicheranlage umfasst; und Generieren eines Regelsatzes, der konfiguriert ist, um auf einem Inventar von Speicheranlagen ausgeführt zu werden, wobei der Regelsatz konfiguriert ist, um basierend auf einer oder mehreren Regeln im Regelsatz zu bestimmen, ob eine Vorlage für eine gegebene Speicheranlage realisierbar ist.
Computer implementiertes Verfahren nach Anspruch 5, ferner umfassend ein Empfangen einer Liste von Einsatzvorlagen, die auf die Speicheranlagen anwendbar sind, wobei die Liste im Hinblick auf den Regelsatz generiert wird, wobei die Liste von Einsatzvorlagen mindestens eines von umfasst: ein Grund, warum ein erster Teil der Liste von Einsatzvorlagen eingesetzt werden kann; und Gründe, warum ein zweiter Teil der Liste von Einsatzvorlagen nicht eingesetzt werden kann.
Computer implementiertes Verfahren nach Anspruch 1, wobei die Speicheranlagen softwaredefinierte Speicheranlagen umfassen.
Computer implementiertes Verfahren nach Anspruch 1, wobei mindestens ein Teil des computer implementierten Verfahrens in einer cloudnativen Umgebung ausgeführt wird.
System, umfassend: einen Prozessor; und einen nichtflüchtigen Speicher in betriebsfähiger Kommunikation mit dem Prozessor und Speichern von Computerprogrammcode, der, wenn er auf dem Prozessor ausgeführt wird, den Prozessor veranlasst, einen Prozess auszuführen, der betriebsfähig ist, um die folgenden Arbeitsschritte durchzuführen: Zugreifen auf eine Verbrauchsanforderung zum Verbrauchen von Speicheranlagen, die Verbrauchsanforderung umfassend einen Stapelparameter und einen Ressourceneigenschaftsparameter, wobei der Stapelparameter mindestens einen Typ von angeforderter Speicheranlage spezifiziert und der Ressourceneigenschaftsparameter mindestens eine von der Speicheranlage benötigte Funktionsfähigkeit spezifiziert; Bestimmen, basierend auf dem Stapelparameter, eines Satzes von einer oder mehreren ersten Speicheranlagen, die in der Lage sind, die Verbrauchsanforderung zu erfüllen; für jede erste Speicheranlage im Satz, der nicht eingesetzt wird, Generieren eines ersten Arbeitsablaufs, der konfiguriert ist, um die jeweilige erste Speicheranlage im Satz einzusetzen, der nicht eingesetzt wird; für jede zweite Speicheranlage im Satz, der den Ressourceneigenschaftsparameter nicht aufweist, Generieren eines zweiten Arbeitsablaufs, der konfiguriert ist, um diese Ressourceneigenschaft in der jeweiligen zweiten Speicheranlage zu implementieren; und Konfigurieren des Satzes von Speicheranlagen, um die Verbrauchsanforderung zu erfüllen, wobei das Konfigurieren das Ablaufen des ersten und zweiten Arbeitsablaufs umfasst.
System nach Anspruch 9, ferner umfassend Computerprogrammcode, der, wenn er auf dem Prozessor ausgeführt wird, den Prozessor veranlasst, die folgenden Arbeitsschritte durchzuführen: Bestimmen, dass eine dritte Speicheranlagenressource erzeugt werden kann, um die Verbrauchsanforderung zu erfüllen; und Generieren eines dritten Arbeitsablaufs, der konfiguriert ist, um die dritte Speicheranlagenressource zu erzeugen und einzusetzen.
Computer implementiertes Verfahren nach Anspruch 10, wobei die dritte Speicheranlagenressource innerhalb mindestens einer der ersten und zweiten Speicheranlagen gebildet wird.
System nach Anspruch 9, wobei die Verbrauchsanforderung eine Abfrage umfasst, die Abfrageparameter enthält, die sich auf eine Suche eines Inventars der Speicheranlagen beziehen, und wobei das computer implementierte Verfahren ferner Computerprogrammcode umfasst, der, wenn er auf dem Prozessor ausgeführt wird, den Prozessor veranlasst, die folgenden Aktionen durchzuführen: Vordefinieren eines Satzes von Vorlagen, die auf die Speicheranlagen anwendbar sind, wobei jede jeweilige Vorlage eine Konfiguration der jeweiligen Speicheranlage und Voraussetzungen zum Einsetzen der Speicheranlage umfasst; und Generieren eines Regelsatzes, der konfiguriert ist, um auf einem Inventar von Speicheranlagen ausgeführt zu werden, wobei der Regelsatz konfiguriert ist, um basierend auf einer oder mehreren Regeln im Regelsatz zu bestimmen, ob eine Vorlage für eine gegebene Speicheranlage realisierbar ist.
System nach Anspruch 9, ferner umfassend Computerprogrammcode, der, wenn er auf dem Prozessor ausgeführt wird, den Prozessor veranlasst, die folgenden Arbeitsschritte durchzuführen: Empfangen einer Liste von Einsatzvorlagen, die auf die Speicheranlagen anwendbar sind, wobei die Liste im Hinblick auf den Regelsatz generiert wird, wobei die Liste von Einsatzvorlagen mindestens eines von umfasst: Gründe, warum ein erster Teil der Liste von Einsatzvorlagen eingesetzt werden kann; und Gründe, warum ein zweiter Teil der Liste von Einsatzvorlagen nicht eingesetzt werden kann.
System nach Anspruch 9, wobei die Speicheranlagen softwaredefinierte Speicheranlagen umfassen.
System nach Anspruch 9, wobei mindestens ein Teil des Computerprogrammcodes in einer cloudnativen Umgebung ausgeführt wird.
Computerprogrammprodukt, enthaltend ein nichtflüchtiges computerlesbares Speichermedium, auf dem Computerprogrammcode codiert ist, der, wenn er auf einem Prozessor eines Computers ausgeführt wird, den Computer veranlasst, ein Speichersystem zu betreiben, das Computerprogrammprodukt umfassend: Computerprogrammcode zum Zugreifen auf eine Verbrauchsanforderung zum Verbrauchen von Speicheranlagen, die Verbrauchsanforderung umfassend einen Stapelparameter und einen Ressourceneigenschaftsparameter, wobei der Stapelparameter mindestens einen Typ von angeforderter Speicheranlage spezifiziert und der Ressourceneigenschaftsparameter mindestens eine von der Speicheranlage benötigte Funktionsfähigkeit spezifiziert; Computerprogrammcode zum Bestimmen, basierend auf dem Stapelparameter, eines Satzes von einer oder mehreren ersten Speicheranlagen, die in der Lage sind, die Verbrauchsanforderung zu erfüllen; Computerprogrammcode zum Generieren, für jede erste Speicheranlage im Satz, der nicht eingesetzt wird, eines ersten Arbeitsablaufs, der konfiguriert ist, um die jeweilige erste Speicheranlage im Satz einzusetzen, der nicht eingesetzt wird; Computerprogrammcode zum Generieren, für jede zweite Speicheranlage im Satz, der den Ressourceneigenschaftsparameter nicht aufweist, eines zweiten Arbeitsablaufs, der konfiguriert ist, um diese Ressourceneigenschaft in der jeweiligen zweiten Speicheranlage zu implementieren; und Computerprogrammcode zum Konfigurieren des Satzes von Speicheranlagen, um die Verbrauchsanforderung zu erfüllen, wobei das Konfigurieren das Ablaufen des ersten und zweiten Arbeitsablaufs umfasst.
Computerprogrammprodukt nach Anspruch 16, ferner umfassend: Computerprogrammcode zum Bestimmen, dass eine dritte Speicheranlagenressource erzeugt werden kann, um die Verbrauchsanforderung zu erfüllen; und Computerprogrammcode zum Generieren eines dritten Arbeitsablaufs, der konfiguriert ist, um die dritte Speicheranlagenressource zu erzeugen und einzusetzen.
Computerprogrammprodukt nach Anspruch 16, wobei die Verbrauchsanforderung eine Abfrage umfasst, die Abfrageparameter enthält, die sich auf eine Suche eines Inventars der Speicheranlagen beziehen, und ferner umfassend: Computerprogrammcode zum Vordefinieren eines Satzes von Vorlagen, die auf die Speicheranlagen anwendbar sind, wobei jede jeweilige Vorlage eine Konfiguration der jeweiligen Speicheranlage und Voraussetzungen zum Einsetzen der Speicheranlage umfasst; und Computerprogrammcode zum Generieren eines Regelsatzes, der konfiguriert ist, um auf einem Inventar von Speicheranlagen ausgeführt zu werden, wobei der Regelsatz konfiguriert ist, um basierend auf einer oder mehreren Regeln im Regelsatz zu bestimmen, ob eine Vorlage für eine gegebene Speicheranlage realisierbar ist.
Computerprogrammprodukt nach Anspruch 16, ferner umfassend Computerprogrammcode zum Empfangen einer Liste von Einsatzvorlagen, die auf die Speicheranlagen anwendbar sind, wobei die Liste im Hinblick auf den Regelsatz generiert wird, wobei die Liste von Einsatzvorlagen mindestens eines von umfasst: ein Grund, warum ein erster Teil der Liste von Einsatzvorlagen eingesetzt werden kann; und Gründe, warum ein zweiter Teil der Liste von Einsatzvorlagen nicht eingesetzt werden kann.
Computerprogrammprodukt nach Anspruch 16, wobei die Speicheranlagen softwaredefinierte Speicheranlagen umfassen.