DE102013210719B4 - Verfahren und Systeme zum Verwalten von Cache-Speichern - Google Patents

Abstract

Verfahren zum Aktualisieren von Cache-Speichern in einem gemeinsam genutzten Datenspeichersystem, wobei das Verfahren aufweist:- Bereitstellen (S100) eines computergesteuerten Systems (1), das das gemeinsam genutztes Datenspeichersystem (CS) und mehrere lokale Server (LS1, LS2) aufweist, wobei:- das gemeinsam genutzte Datenspeichersystem so eingerichtet ist, dass es mit den lokalen Servern zusammenwirkt;- die lokalen Server Anwendungen (A1, A2) unter Verwendung entsprechender Cache-Speicher (CM1, CM2) bedienen; und- jeder der lokalen Server auf Daten (D) zugreift, die in dem gemeinsam genutzten Datenspeichersystem gespeichert sind,- wobei das Verfahren ferner aufweist,- Bereitstellen (S200H, S200M) von Cachespeicher-Dateninformationen von jedem der lokalen Server (LS1, LS2) an das gemeinsam genutzte Datenspeichersystem, wobei die bereitgestellten Cachespeicher-Dateninformationen aufweisen:- Cachespeicherzugriff-Trefferdaten (H), die Cachespeicherzugriff-Treffer von jedem der lokalen Server darstellen; und- Cachespeicherzugriff-Fehltrefferdaten (M), die Cachespeicherzugriff-Fehltreffer von jedem der lokalen Server darstellen;- in dem gemeinsam genutzten Datenspeichersystem Zusammenführen (S300) wenigstens eines Teils der empfangenen Cachespeicherzugriff-Trefferdaten und Cachespeicherzugriff-Fehltrefferdaten zu zusammengeführten Cachespeicher-Dateninformationen (ACD) und Bereitstellen (S400) der zusammengeführten Cachespeicher-Dateninformationen an einen oder mehrere der lokalen Server; und- in dem einen oder den mehreren lokalen Servern Aktualisieren (S500) von einem bzw. mehreren Cache-Speichern, die verwendet werden, um die eine bzw. die mehreren Anwendungen zu bedienen, auf der Grundlage der bereitgestellten zusammengeführten Cachespeicher-Dateninformationen (ACD),- wobei das Aktualisieren (S500) eines Cache-Speichers (CM1) in Bezug auf Anforderungen an den Cache-Speicher (CM1) von einer entsprechenden Anwendung (A1), die durch einen entsprechenden lokalen Server (LS1) bedient wird, asynchron ausgeführt wird durch eine asynchrone Ausführungseinheit unabhängig vom Austausch von Daten zwischen dem lokalen Cache-Speicher und dem gemeinsam genutzten Datenspeichersystem.

Description

• GEBIET DER ERFINDUNG
• Die Erfindung bezieht sich allgemein auf das Gebiet von computergesteuerten Verfahren und Systemen zum Verwalten von Cache-Speichern und insbesondere in einer Speicherbereichsnetz- (SAN-) Umgebung.
• HINTERGRUND DER ERFINDUNG
• Ein Speicherbereichsnetz (SAN) ist ein spezielles Netzwerk, das einen Zugriff auf konsolidierte Datenspeicher auf Blockebene bereitstellt. Derartige Netzwerke werden hauptsächlich verwendet, um Speichereinheiten (z.B. Platten-Arrays oder Bandbibliotheken) für Server zugänglich zu machen, so dass diese Einheiten scheinbar lokal mit dem Betriebssystem verbunden sind. Ein SAN weist üblicherweise ein eigenes Netzwerk aus Speichereinheiten auf, auf die im Allgemeinen über das Lokalbereichsnetz durch andere Einheiten nicht zugegriffen werden kann. Ein SAN stellt keine Dateiabstraktions-Operationen, sondern lediglich Operationen auf Blockebene bereit. Dateisysteme, die auf SANs aufgebaut sind, stellen jedoch einen Zugang auf Dateiebene bereit (siehe z.B. Wikipedia-Mitwirkender, „Storage area network“,
• Allgemeiner ausgedrückt, es gibt mehrere bekannte Umgebungen, bei denen mehrere lokale Anwendungsserver (d.h. unter Verwendung entsprechender Cache-Speicher zum Bedienen entsprechender Anwendungen) so eingerichtet sind, dass sie mit einem gemeinsam genutzten Datenspeichersystem zusammenwirken, so dass sie auf Daten zugreifen können, die in dem gemeinsam genutzten Speicherpool gespeichert sind. Wie derartige Systeme den Cache-Speicher verwalten, wird üblicherweise folgendermaßen umgesetzt:
• - Fehltreffer des lokalen Cache-Speichers werden durch die lokalen Server an das gemeinsam genutzte Datenspeichersystem gemeldet;
• - Letzteres liefert in Reaktion darauf die fehlenden Daten; und
• - des Weiteren konsolidiert und verwendet es die empfangenen Cachespeicher-Fehltrefferdaten für Zwecke des Zwischenspeicherns/der Schichtung (caching/tiering), d.h. Zwecke des Anordnens von Daten.
• Das erfolgt z.B. in einer SAN-Umgebung. Offensichtlich spielt das gemeinsam genutzte Datenspeichersystem eine zentrale Rolle; es wird deswegen gelegentlich als ein „zentrales System“ bezeichnet.
• In einer typischen SAN-Umgebung sind mehrere Anwendungsserver über eine Standard-Zugangsschnittstelle auf Blockebene mit dem gemeinsam genutzten Datenspeichersystem verbunden (auf Daten wird üblicherweise in Blöcken mit fester Größe von z.B. 512 bis 528 Byte zugegriffen). Der gemeinsam genutzte Speicherpool wird durch einen SAN-Speicherserver wie etwa der IBM DS8000 verwaltet. Der SAN-Speicherserver verwendet häufig große Cache-Speicher, um den Systemdurchsatz zu verbessern und die Zugriffslatenzzeit zu verringern, während gleichzeitig jeder Anwendungsserver ebenfalls Cache-Speicher verwenden kann, um die Anwendungsagilität in Bezug auf E/A-Leistungsfähigkeit zu vergrößern und um die Inanspruchnahme der Bandbreite des SAN-Servers zu verringern. Es ist verständlich, dass die Cache-Speicher in den Anwendungsservern (im Folgenden auch als „lokale Cache-Speicher“ bezeichnet) und der Cache-Speicher in dem SAN-Speicherserver unabhängig betrieben werden: es gibt keine Koordinierung zwischen ihnen. Die gleiche Schlussfolgerung gilt im Allgemeinen für allgemeinere Systemarchitekturen, die oben erwähnt wurden, d.h., bei denen lokale Anwendungsserver mit einem gemeinsam genutzten Datenspeichersystem zusammenwirken, um auf Daten zuzugreifen, die in dem gemeinsam genutzten Speicherpool gespeichert sind.
• Die US 8 171 114 B1 offenbart ein Verfahren zum Zwischenspeichern durch Speichern von Daten in einem ersten Cache, der für ein erstes geographisches Gebiet spezifisch ist und auf den nur eine erste Anwendung in dem ersten geographischen Gebiet zugreifen kann; Speichern von Daten in einem zweiten Cache, der für ein zweites geographisches Gebiet spezifisch ist und auf den eine Vielzahl von Anwendungen in dem zweiten geographischen Gebiet zugreifen können, einschließlich der ersten Anwendung und einer zweiten Anwendung, wobei das zweite geographische Gebiet größer ist als das erste geographische Gebiet und zumindest einen Teil davon umfasst; als Reaktion auf einen Miss für Daten im ersten Cache, Kontaktieren des zweiten Caches und Suchen nach den Daten im zweiten Cache; und als Reaktion auf einen Treffer für die Daten im zweiten Cache, Senden der Daten an eine erste Anwendung, wobei die Daten von einer zweiten Anwendung in dem zweiten Cache platziert wurden.
• KURZDARSTELLUNG DER ERFINDUNG
• Gemäß einem ersten Aspekt (d.h. einem globalem Aspekt) wird die vorliegende Erfindung als ein Verfahren zum Aktualisieren von Cache-Speichern in einem gemeinsam genutzten Datenspeichersystem ausgeführt, wobei das Verfahren aufweist:
• Bereitstellen eines computergesteuerten Systems, das das gemeinsam genutzte Datenspeichersystem und mehrere lokale Server aufweist, wobei:
  • das gemeinsam genutzte Datenspeichersystem so eingerichtet ist, dass es mit den lokalen Servern zusammenwirkt;
  • die lokalen Server unter Verwendung entsprechender Cache-Speicher Anwendungen bedienen; und
  • jeder der lokalen Server auf Daten zugreift, die in dem gemeinsam genutzten Datenspeichersystem gespeichert sind,
wobei das Verfahren ferner aufweist:
• Bereitstellen von Cachespeicher-Dateninformationen von jedem der lokalen Server an das gemeinsam genutzte Datenspeichersystem, wobei die bereitgestellten Cachespeicher-Dateninformationen aufweisen:
  • Cachespeicherzugriff-Trefferdaten, die Cachespeicherzugriff-Treffer von jedem der lokalen Server darstellen; und
  • Cachespeicherzugriff-Fehltrefferdaten, die Cachespeicherzugriff-Fehltreffer von jedem der lokalen Server darstellen;
  • in dem gemeinsam genutzten Datenspeichersystem Zusammenführen von wenigstens einem Teil der empfangenen Cachespeicherzugriff-Trefferdaten und Cachespeicherzugriff-Fehltrefferdaten zu zusammengeführten Cachespeicher-Dateninformationen und Bereitstellen der zusammengeführten Cachespeicher-Dateninformationen an einen oder mehrere der lokalen Server; und
  • in dem einen oder den mehreren lokalen Servern Aktualisieren eines bzw. mehrerer Cache-Speicher, die zum Bedienen einer bzw. mehrerer Anwendungen verwendet werden, auf der Grundlage der bereitgestellten zusammengeführten Cachespeicher-Dateninformationen,
  • wobei das Aktualisieren eines Cache-Speichers in Bezug auf Anforderungen an den Cache-Speicher von einer entsprechenden Anwendung, die durch einen entsprechenden lokalen Server bedient wird, asynchron ausgeführt wird durch eine asynchrone Ausführungseinheit unabhängig vom Austausch von Daten zwischen dem lokalen Cache-Speicher und dem gemeinsam genutzten Datenspeichersystem.
• Das Zusammenführen weist ferner vorzugsweise das Sortieren der Cachespeicherzugriff-Trefferdaten und der Cachespeicherzugriff-Fehltrefferdaten gemäß dem Vorkommen der Cachespeicherzugriff-Trefferdaten und der Cachespeicherzugriff-Fehltrefferdaten auf, so dass die Struktur der erhaltenen Cachespeicher-Dateninformationen das Sortieren widerspiegelt.
• Erfindungsgemäß wird das Aktualisieren eines Cache-Speichers in Bezug auf Anforderungen an den Cache-Speicher von einer entsprechenden Anwendung, die durch einen entsprechenden lokalen Server bedient wird, asynchron ausgeführt.
• Vorzugsweise weist das Aktualisieren eines Cache-Speichers das Auswählen von Teilmengen von Daten in den zusammengeführten Cachespeicher-Dateninformationen und das Belegen des Cache-Speichers gemäß den ausgewählten Teilmengen von Daten auf.
• In bevorzugten Ausführungsformen weist das Aktualisieren eine Cache-Speichers auf: Auswählen wenigstens von zwei unterschiedlichen Teilmengen von Daten in den zusammengeführten Cachespeicher-Dateninformationen; Anweisen, den Cache-Speicher ohne Verzögerung mit Daten zu belegen, die einer der unterschiedlichen Teilmengen von Daten entsprechen; und Anweisen, Daten, die der anderen der unterschiedlichen Teilmengen von Daten entsprechen, in einer Kontrollliste abzulegen, wobei das Verfahren ferner die folgenden Schritte aufweist: Überwachen von Daten in der Kontrollliste, um Daten zu ermitteln, mit denen der Cache-Speicher belegt werden soll; und Belegen des Cache-Speichers mit den Daten, die dementsprechend ermittelt wurden.
• In Ausführungsformen weist das Verfahren ferner auf: Anweisen, zusätzliche Daten, die den lokalen Cachespeicherzugriff-Fehltrefferdaten entsprechen, in der Kontrollliste abzulegen, wobei die lokalen Cachespeicherzugriff-Fehltrefferdaten Cachespeicherzugriff-Fehltreffer darstellen, die durch den lokalen Server unabhängig von den zusammengeführten Cachespeicher-Dateninformationen gesammelt werden, so dass sowohl die lokalen Cachespeicherzugriff-Fehltrefferdaten als auch die Daten, die der zweiten Teilmenge der beiden unterschiedlichen Teilmengen von Daten entsprechen, überwacht werden können, um zu ermitteln, mit welchen Daten der Cache-Speicher belegt werden soll.
• Die Kontrollliste weist vorzugsweise eine umlaufende Liste von zwischengespeicherten Objekten auf, und das Überwachen von Daten in der Kontrollliste weist das Entfernen eines ältesten zwischengespeicherten Objekts, das während einer vorgegebenen Zeitperiode nicht für einen Zugriff angefordert wurde, aus der umlaufenden Liste auf.
• In Ausführungsformen weist das Verfahren ferner das Filtern von Daten auf, die sich bereits in dem Cache-Speicher befinden, bevor ein Cache-Speicher mit derartigen Daten belegt wird.
• Die zusammengeführten Cachespeicher-Dateninformationen können zum Beispiel bei einer Feinteiligkeit (granularity) zusammengeführt werden, die größer als eine Feinteiligkeit ist, die bei einem nachfolgenden Aktualisieren des Cache-Speichers verwendet wird.
• Gemäß weiteren Aspekten wird die Erfindung als ein computergesteuertes System ausgeführt, das eine oder mehrere der oben erwähnten Komponenten aufweist (d.h. wenigstens ein gemeinsam genutztes Datenspeichersystem und/oder einen (lokalen) Server), wobei das System so eingerichtet ist, dass es in einem Verfahren nach einer der obigen Ausführungsformen jeden der Schritte ausführt, die durch die eine oder die mehreren Komponenten ausgeführt werden.
• Gemäß einem nochmals weiteren Aspekt kann die Erfindung schließlich als ein Computerprogrammprodukt zum Verwalten von Cache-Speichern ausgeführt werden, wobei das Computerprogrammprodukt ein nichtflüchtiges computerlesbares Speichermedium mit darauf verkörpertem computerlesbaren Programmcode aufweist, wobei der computerlesbare Programmcode so eingerichtet ist, dass er jeden der Schritte eines Verfahrens nach einer der obigen Ausführungsformen umsetzt.
• Verfahren, Systeme und deren Komponenten, die die vorliegende Erfindung verkörpern, werden im Folgenden mittels nicht einschränkender Beispiele und unter Bezugnahme auf die beigefügten Zeichnungen beschrieben.
• Die der Erfindung zugrunde liegenden Aufgaben werden jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind Gegenstand der abhängigen Patentansprüche.
• Figurenliste
• 1 stellt schematisch ein computergesteuertes System dar, das so ausgelegt ist, dass es Verfahren gemäß Ausführungsformen der Erfindung umsetzt;
• 2 ist ein Ablaufplan, der in Übersichtsform Schritte darstellt, die in Ausführungsformen beteiligt sind;
• 3 ist eine Darstellung, die Komponenten und Schritte zeigt, die in einer Belegungslogik und einem Belegungsmechanismus eines lokalen Cache-Speichers gemäß Ausführungsformen beteiligt sind; und
• 4 ist eine Darstellung, die sich auf bestimmte Aspekte einer Belegungslogik eines lokalen Cache-Speichers wie in 3 gemäß Ausführungsformen konzentriert.
• AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
• Die folgende Beschreibung ist folgendermaßen aufgebaut. Zuerst werden allgemeine Ausführungsformen und höhere Varianten beschrieben (Abschnitt 1). Der nächste Abschnitt widmet sich spezielleren Ausführungsformen und Einzelheiten der technischen Umsetzung (Abschnitt 2).
• Allgemeine Ausführungsformen und höhere Varianten
• In diesem Abschnitt werden allgemeine Aspekte der Erfindung beschrieben, die Verfahren zum Verwalten von Cache-Speichern betreffen. Da die vorliegende Erfindung Wechselwirkungen zwischen Clients LS1, LS2 und einem zentralen Server CS, d.h. in einer Client-Server-Architektur siehe 1, betrifft, können unterschiedliche Beschreibungen der Erfindung in Abhängigkeit von dem angenommenen Standpunkt gegeben werden. Deswegen werden im Folgenden zuerst allgemeine Aspekte der Erfindung beschrieben, die in einem globalen System ausgeführt wird, das sowohl die Clients als auch den Server CS aufweist. Anschließend werden Aspekte derselben Erfindung bei Betrachtung aus der Sicht eines Client oder des Servers CS erläutert. Diese Aspekte unterscheiden sich natürlich lediglich in dem angenommenen Standpunkt (d.h. global oder aus Sicht einer der Komponenten von 1 betrachtet) und bezeichnen ein und dieselbe Erfindung.
• In den 1 bis 2 wird zunächst das Verfahren allgemein in einem computergesteuerten System 1 betrieben, das aus globaler Sicht sowohl den Server als auch die Clients aufweist und zwar ein gemeinsam genutztes Datenspeichersystem CS und mehrere lokale Server LS1, LS2. Somit enthält formal ausgedrückt ein erster Schritt S100 des Verfahrens dementsprechend das Bereitstellen eines computergesteuerten Systems 1 wie in 1 dargestellt. In diesem System 1 ist das gemeinsam genutzte Datenspeichersystem CS so eingerichtet, dass es mit mehreren lokalen Servern, d.h. in einer minimalen Konfiguration wenigstens zwei lokalen Servern LS1, LS2, zusammenwirkt. Diese bedienen Anwendungen A1, A2 unter Verwendung von entsprechenden Cache-Speichern CM1, CM2. Jeder der lokalen Server kann auf Daten D zugreifen, die in dem gemeinsam genutzten Datenspeichersystem gespeichert sind. Die Daten D werden üblicherweise angefordert für einen Zugriff durch einen lokalen Server auf Anforderung der Anwendung, die von ihm bedient wird, wie in SAN-Umgebungen, bei denen die vorliegende Erfindung üblicherweise angewendet wird. Das gemeinsam genutzte Datenspeichersystem CS soll außerdem im Folgenden aus offensichtlichen Gründen als ein „zentrales System“ bezeichnet werden. Dieses System CS wird üblicherweise durch einen SAN-Speicherserver verwaltet. Somit sind sowohl das lokale als auch das zentrale System üblicherweise „Server“. Das zentrale System CS wirkt als Datenserver für die lokalen Server LS1, LS2, während die lokalen Server LSn unter Verwendung von entsprechenden Cache-Speichern CMn entsprechenden Anwendungen An dienen. Zur Vermeidung von Mehrdeutigkeiten wird das zentrale System CS trotzdem als „System“ bezeichnet, während die lokalen Server als „Server“ bezeichnet werden. Es wird angemerkt, dass das computergesteuerte System in einer minimalen Konfiguration wenigstens das zentrale System CS, zwei lokale Server LS1, LS2 aufweist, die einer oder mehreren Anwendungen dienen, und zwei (oder mehrere) entsprechende Cache-Speicher verwendet. Es sollte einem Fachmann tatsächlich klar sein, dass ein lokaler Server mehr als einer Anwendung dienen kann, und zwar unter Verwendung von mehr als einem Cache-Speicher.
• Anschließend enthält ein zweiter Schritt das Bereitstellen von Cachespeicher-Dateninformationen von jedem der lokalen Server LS1, LS2 für das zentrale System CS. Die Cachespeicher-Dateninformationen enthalten üblicherweise Cachespeicher-Datenstatistiken. Wie in Verfahren nach dem Stand der Technik betreffen derartige Statistiken Cachespeicherzugriff-Fehltreffer M, d.h. Daten, die Cachespeicherzugriff-Fehltreffer von jedem der lokalen Server darstellen. Ein „Cachespeicherzugriff-Fehltreffer“ ist an sich bekannt: er bezeichnet eine Datenzugriffsanforderung, die von dem Cache-Speicher CMn nicht bedient wurde, da einige oder alle der entsprechenden Daten zum Zeitpunkt der Anforderung nicht zwischengespeichert waren.
• Im Unterschied zu Verfahren nach dem Stand der Technik enthalten die Cachespeicher-Dateninformationen, die in der vorliegenden Erfindung an das zentrale System weitergeleitet werden, ferner Cachespeicherzugriff-Trefferdaten H, d.h. die Cachespeicherzugriff-Treffer von jedem der lokalen Server darstellen. Ein „Cachespeicherzugriff-Treffer“ ist ebenfalls an sich bekannt, er entspricht vorgegebenen Daten, die in einem Cache-Speicher zwischengespeichert sind, der durch eine oder mehrere Anwendungen verwendet wird und die in Reaktion auf eine Datenzugriffsanforderung von diesem Cache-Speicher bedient werden. Der spezielle Fall von teilweisen Treffern wird später erläutert. Cachespeicherzugriff-Treffer und Fehltreffer werden üblicherweise zu verschiedenen Zeitpunkten gesendet, da Cachespeicherzugriff-Fehltreffer im Gegensatz zu Cachespeicherzugriff-Treffern eine sofortige Reaktion benötigen, eine Sache, die ebenfalls später entwickelt wird. Somit ist es verständlich, dass die Cachespeicherzugriff-Trefferdaten vorzugsweise unabhängig von den Cachespeicherzugriff-Fehltrefferdaten bereitgestellt werden wie durch die Schritte S200H und S200M in 2 dargestellt.
• Das zentrale System CS führt als Nächstes im Schritt S300 wenigstens einen Teil der empfangenen Cachespeicherzugriff-Trefferdaten H und Cachespeicherzugriff-Fehltrefferdaten zu zusammengeführten Cachespeicher-Dateninformationen ACD zusammen. Die zusammengeführten Cachespeicher-Dateninformationen können die tatsächlichen Daten, mit denen später die lokalen Cache-Speicher belegt werden sollen, oder einfacher Datenkennungen zusammenführen. Nachdem sie zusammengeführt wurden, können die Cachespeicher-Dateninformationen ACD dann im Schritt 400 an einen oder mehrere lokale Server bereitgestellt werden. Die lokalen Cachespeicherzugriff-Fehltreffer M, Cachespeicherzugriff-Treffer H und Daten D, auf die zugegriffen wird, sollten sich natürlich von LS1 zu LS2 möglicherweise unterscheiden.
• Ein lokaler Server aktualisiert dann den von ihm verwalteten Cache-Speicher (Schritt S500) auf der Grundlage der empfangenen Cachespeicher-Dateninformationen ACD z.B. möglichst bald nach dem Empfangen der zusammengeführten Daten von dem zentralen System.
• Demzufolge kann die Leistungsfähigkeit eines lokalen Cachespeichers bei Vorhandensein von „globaleren“ Kenntnissen verbessert werden, die in den ACD erworben wurden, d.h. Kenntnisse über Cachespeicherzugriff-Fehltreffer und Treffer, die in mehreren Anwendungen vorkommen (einschließlich Anwendungen, die von einer bestimmten lokalen Anwendung, die mit den ACD bereitgestellt werden sollen, verschieden sind). Deswegen wird ein vorgegebener lokaler Cachespeicher auf der Grundlage von Daten aktualisiert, die wahrscheinlich für diesen vorgegebenen lokalen Cachespeicher relevant sind, wenn es an anderer Stelle erwiesen wurde, dass sie relevant sind. Diese globalen Daten sind alle in stärkerem Maße relevant, wenn zwischen Cachespeicher-Daten, die an einer Stelle relevant sind, und Cachespeicher-Daten, die an anderer Stelle relevant sind, eine bestimmte Korrelation besteht. Das ist nämlich der Fall, wenn dieselbe Anwendung auf mehreren Clients läuft und mit denselben Daten von den mehreren Clients in Berührung kommt. Das ist außerdem der Fall, wenn eine Anwendung von einem Server zu irgendeinem anderen wandert (z.B. zur Ausfallsicherung). Im Gegensatz dazu „sehen“ in den Systemen nach dem Stand der Technik die lokalen Cachespeicher nicht die konsolidierte Arbeitslast von allen Anwendungsservern, und deswegen können Entscheidungen einer lokalen Zwischenspeicherung nicht optimal sein oder zumindest nicht aus zentraler Sicht.
• Es wird angemerkt, falls durch den Aufbau der Schritte S200 bis S500 die zusammengeführten Daten ACD globale Kenntnisse der Cachespeicher-Dateninformationen enthalten, verhindert dies jedoch nicht, dass die zusammengeführten Daten ACD, die für einen lokalen Server bereitgestellt werden, zugeschnitten sind, d.h. speziell für diesen Server erstellt wurden. Im Einzelnen können ACD-Daten, die an einen lokalen Server (z.B. LS1) bereitgestellt werden, Cachespeicher-Dateninformationen enthalten, die sowohl vom LS1 als auch vom LS2 erfasst wurden, während trotzdem die Betonung auf Daten liegt, die hauptsächlich für LS1 konsolidiert wurden. Dies sollte später entwickelt werden.
• Die Erfindung wird vorteilhaft in einer SAN-Umgebung umgesetzt, wobei das zentrale System CS vorzugsweise einen großen Cachespeicher und/oder Schichtungs-Mechanismen (tiering mechanisms) nutzt. Außerdem werden vorzugsweise schnellere Speichereinheiten für das Speichern im Cachespeicher z.B. flashgestützte SSDs in dem zentralen System CS und/oder in den lokalen Servern LS1, LS2 verwendet.
• Das bisher Beschriebene betrifft bei Betrachtung von einem globalen Standpunkt allgemeine Aspekte eines Verfahrens. Nunmehr kann dasselbe Verfahren in Schritte zerlegt werden, die in einer der anderen von den beteiligten Komponenten LS1, LS2, CS ausgeführt werden.
• Das Verfahren weist z.B. vom Standpunkt eines lokalen Servers LS1 die folgenden Schritte auf: Ein lokaler Server sollte
• - die Cachespeicher-Dateninformationen dem zentralen System CS zur Verfügung stellen, wobei die Cachespeicher-Dateninformationen in Abhängigkeit von der globalen Systemkonfiguration z.B. gesendet oder abgerufen werden können;
• - dann von den zentralen System CS zusammengeführte Cachespeicher-Dateninformationen ACD empfangen, die wie oben beschrieben erhalten werden; und
• - anschließend seinen Cache-Speicher auf der Grundlage der empfangenen ACD aktualisieren.
• Das Verfahren weist in ähnlicher Weise vom Standpunkt des zentralen Systems CS auf:
• - Empfangen (oder Abrufen) von Cachespeicherzugriff-Trefferdaten H und Cachespeicherzugriff-Fehltrefferdaten M von jedem der lokalen Server LS1, LS2 in einer beliebigen Reihenfolge (Schritt S210H, S210M);
• - Zusammenführen wenigstens eines Teils der empfangenen Cachespeicherzugriff-Trefferdaten und Cachespeicherzugriff-Fehltrefferdaten zu zusammengeführten Cachespeicher-Dateninformationen ACD, Schritt 300; und
• - Bereitstellen der ACD der Reihe nach an einen oder mehrere der lokalen Server LS1, LS2, Schritt S400, für eine nachfolgende Aktualisierung der Cache-Speicher CM1, CM2.
• Die Leistungsfähigkeit der obigen Verfahren kann verbessert werden, wenn die Struktur der an die lokalen Server bereitgestellten ACD Angaben in Bezug auf die Relevanz der Daten enthält. Zu diesem Zweck und unter Bezugnahme auf 4 kann der ACD-Zusammenführungsschritt (d.h. der Schritt 300 in 2) in Ausführungsformen Datensortieroperationen aufweisen. Genauer können die Cachespeicherzugriff-Trefferdaten und die Cachespeicherzugriff-Fehltrefferdaten nach dem Auftreten der Cachespeicherzugriff-Trefferdaten und der Cachespeicherzugriff-Fehltrefferdaten sortiert werden. Dieses Auftreten kann z.B. anhand von lokalen Aufzeichnungen oder vorzugsweise aus früheren Konsolidierungsarbeiten in dem zentralen Server CS berechnet werden. Deswegen kann die Struktur der zusammengeführten Cachespeicher-Dateninformationen ACD dieses Sortieren möglicherweise implizit wiedergeben. In 4 werden die Daten z.B. in der aufsteigenden Reihenfolge ihres Vorkommens sortiert, d.h. die neuesten Daten (gepunktete rechtwinklige Abschnitte in den ACD-Daten von 4) befinden sich an einem Ende der ACD-Datenstruktur, die für die lokalen Server bereitgestellt wird.
• Es wird angemerkt, dass „Vorkommen“ umfassend verstanden werden sollte; es kann z.B. die Häufigkeit des Vorkommens dieser Daten widerspiegeln. Es widerspiegelt allgemeiner die Neigung, in einer oder mehreren Zeitperioden vorzukommen; es kann einfach der zeitliche Verlauf dieser Daten sein. In diesem Zusammenhang wird angemerkt, dass der Fortgang z.B. unterschiedliche Zeitintervalle berücksichtigen muss und die Cachespeicherzugriff-Daten H, M mit entsprechenden Zeitintervallen korrelieren muss, um relevante Zeitperioden zu vergleichen, d.h. Zeitperioden, die vergleichbar sind, und um das vergleichbare Vorkommen für die Cachespeicherzugriff-Daten H, M abzuleiten, bevor sie in der ACD-Struktur von 4 zusammengeführt werden. Man spricht gelegentlich von einer Cachespeicherzugriff-Daten-„Konsolidierung“, wenn dieser Prozess lediglich für Cachespeicherzugriff-Fehltreffer ausgeführt wird. In vorliegenden Ausführungsformen der Erfindung rührt die Ursprünglichkeit dieses optionalen Schritts von der Tatsache her, dass sowohl Cachespeicherzugriff-Fehltreffer als auch Cachespeicherzugriff-Treffer konsolidiert werden, wobei Cachespeicherzugriff-Fehltreffer und Treffer mehrere Cachespeicher/Anwendungen/Server betreffen.
• Während die Cachespeicherzugriff-Fehltreffer außerdem üblicherweise sofort an den zentralen Server gemeldet werden, trifft das für Cachespeicherzugriff-Treffer nicht zu; sie können z.B. lokal gesammelt und periodisch gemeldet werden, wenn eine Einstellung an der Häufigkeit von Cachespeicherzugriff-Fehltreffern erforderlich ist. In Varianten könnten Cachespeicherzugriff-Treffer im Verlauf einer Operation (nicht bevorzugt) oder wenn ein quantitativer Schwellenwert für Cache-Treffer in einem lokalen Server erreicht wurde, gemeldet werden.
• Nun können viele vorteilhafte Ausgestaltungsoptionen vorgesehen werden. Der Austausch von statistischen Angaben zwischen den lokalen Servern und dem zentralen System CS kann z.B. inband oder außerband ausgeführt werden. Außerdem können beim Konsolidieren von Cachespeicherzugriff-Daten Cachespeicherzugriff-Daten für Anwendungsanforderungen, die wenige Datenbits betreffen, vorzugsweise gemeinsam gruppiert werden, um Daten nachfolgend in SSDs abzulegen; die Cachespeicherzugriff-Daten für Anforderungen, die viele Bits betreffen, können ebenfalls gruppiert werden: Daten für größere Anforderungen werden besser in HDDs abgelegt.
• In Abhängigkeit von den betrachteten Zeitintervallen reicht die Häufigkeit des Vorkommens der Cachespeicher-Dateninformationen von einer nahezu momentanen Häufigkeit (Augenblickshäufigkeit) bis zu einer gleichwertigen mittleren Häufigkeit für eine effektive Zeitperiode usw. Jedenfalls ergibt sich aus Simulationen, die durch die Erfinder der vorliegenden Erfindung gemacht wurden, dass das Sortieren der ACD und eine dementsprechende Strukturierung der ACD eine Verbesserung der langfristigen Relevanz von Cachespeicherzugriff-Daten ermöglicht, d.h. die lokalen Cachespeicher CM1, CM2 können nachfolgend zu Cachespeicher-Daten aktualisiert werden, bei denen eine größere Wahrscheinlichkeit besteht, über längere Zeitperioden durch die entsprechende Anwendung A1, A2 angefordert zu werden.
• Die Aktualisierungen des Cache-Speichers werden im Allgemeinen durch den Schritt S500 in 2 bezeichnet. In den 3 und 4 werden die Aktualisierungen des Cache-Speichers in mehrere Teilschritte zerlegt und zwar S11, S11a, S11b, S121, S122, S23, S450 und S550 bis S580, wobei die Teilschritte vorzugsweise durch einen lokalen Server oder dessen Komponenten umgesetzt werden. Diese Komponenten sind in eine Belegungslogik 10 und einen Belegungsmechanismus 24 unterteilt. Erstere enthält Komponenten 11, 12, 12a, 21, 22, 23. Der Belegungsmechanismus 24 schließt eine Daten-Verlagerungseinrichtung (Daten-Mover) 24 ein, die mit einem Cachespeicher zusammenwirkt, z.B. einem Direct-Attach-Storage- (DAS-) Cache-Speicher 26, und ein Cachespeicher-Verzeichnis 25. Ein Cache-Speicher CM1, CM2, der in 1 dargestellt ist, weist mindestens einen Speicher 26 (z.B. einen DAS-Cache-Speicher) auf wie in 3 dargestellt, der ebenfalls als „CM“ bezeichnet ist.
• In den 3 und 4: die Aktualisierungen des Cache-Speichers werden vorzugsweise asynchron ausgeführt. Im Einzelnen werden Aktualisierungen an einem vorhandenen Cache-Speicher CM1 asynchron in Bezug auf Benutzeranforderungen an den Cache-Speicher CM1 von der entsprechenden Anwendung A1 ausgeführt, d.h. durch den entsprechenden lokalen Server LS1 bedient. Der Cachespeicher-Belegungsmechanismus kann z.B. durch eine asynchrone Ausführungseinheit wie die in 3 dargestellte gesteuert werden, z.B. ein spezieller Software-Thread. Das bedeutet, dass eigentliche Cachespeicher-Belegungsschritte außerhalb des kritischen Datenwegs betrieben werden können, d.h. außerhalb des Wegs, der Schritte enthält, die erforderlich sind, um Daten entweder von dem lokalen Cache-Speicher oder von dem zentralen System zu den Anwendungen zu liefern. Somit wird der normale Betrieb der lokalen Cache-Speicher durch den Aktualisierungsmechanismus nicht nachteilig beeinflusst.
• Genauer gesagt, Aktualisierungen des Cache-Speichers schließen üblicherweise die Auswahl von Daten-Teilmengen ein, d.h. Teilmengen der Daten in den ACD, die an einen lokalen Server bereitgestellt werden, werden ausgewählt, und der entsprechende Cache-Speicher wird anschließend gemäß den ausgewählten Teilmengen belegt, die insbesondere durch die Schritte S11, S11b, S121 in den 3 bis 4 erfasst werden. Zum Beispiel können Teilmengen von Daten in den empfangenen ACD ausgewählt werden, z.B. Daten-Teilmengen, die am häufigsten vorkommen (oder kurz gesagt „aktuelle Daten“), um den Cache-Speicher mit ihnen direkt zu belegen (siehe Schritt S11, 3 oder 4). Was die restlichen Daten-Teilmengen betrifft, so können sie z.B. verworfen werden, fallen gelassen werden oder trotzdem überwacht werden. Im Einzelnen können einige der Daten-Teilmengen in einer Kontrollliste 12 für eine nachfolgende Überwachung abgelegt werden, wie im Folgenden erläutert wird.
• Diese Auswahl von Daten-Teilmengen kann als ein Schritt des Filterns betrachtet werden. Für die Auswahl von Daten-Teilmengen wird vorteilhaft die ACD-Struktur verwendet, die implizit mitteilen kann, welche Daten aktuell sind und für welche Daten das nicht zutrifft. In Varianten können einige Cachespeicher-Daten explizit als „unbedingt notwendig (must-have)“ markiert werden. In ähnlicher Weise könnten einige Daten in den ACD als „nicht unbedingt notwendig (must-not-have)“ markiert werden. Somit kann eine Logik der lokalen Belegung vorgehen, um die Daten-Teilmengen gemäß ihrer impliziten oder expliziten Bewertungen auszuwählen. Der lokale Server kann z.B. möglicherweise die „must-haves“ nicht (oder zumindest nicht sofort) filtern; er kann stattdessen die restlichen Daten filtern oder könnte sogar sicherstellen, dass „must-not-haves“ nicht zwischengespeichert werden. Viele weitere dazwischen liegende Strategien können entworfen werden, wie es einem Fachmann klar ist.
• Da die Daten, die in den ACD identifiziert sind, Daten entsprechen können, die sich bereits im Cache-Speicher befinden, werden mehrere Stufen von zusätzlichen Filtern vorteilhaft umgesetzt:
• - Zunächst kann man bereits im Cache-Speicher befindliche Daten aus den ACD ausfiltern, sobald sie in einem lokalen Server empfangen werden. Beim Empfangen der ACD, z.B. einer geordneten Liste des Datenbereichs, der jeweils einem 1-MB-Segment wie in 4 entspricht, wird eine Logik 10 des lokalen Cache-Speichers zuerst Datenfragmente (oder Datenfragment-Kennungen) aus jenen Fragmenten ausfiltern, die sich bereits im Cache-Speicher befinden, wie in den 3 und 4, Schritt S11b dargestellt.
• - Allgemeiner gesagt, man kann Daten, die sich bereits im Cache-Speicher befinden, an mehreren Punkten filtern, z.B. am Filter 11 und/oder an der Datenverlagerungseinrichtung 24 usw.
• Tatsächlich muss sichergestellt werden (wenn der Wunsch besteht, jene Daten, die sich bereits im Cache-Speicher befinden, auszufiltern), dass diese Daten gefiltert werden, bevor der Cache-Speicher mit ihnen belegt wird.
• Gegenwärtig können verschiedene gleichlaufende Wege für die Belegung eines Cache-Speichers vorgesehen werden. Es können z. B. zwei oder mehrere unterschiedliche Teilmengen von Daten in eintreffenden ACD identifiziert werden.
• Wie in den 3 bis 4 dargestellt kann die Belegungslogik 10 anweisen, den Cache-Speicher CM1 ohne Verzögerung mit Daten zu belegen (Schritt S11), die einer der identifizierten unterschiedlichen Daten-Teilmengen entsprechen, während sie anweist (Schritt S11a), Daten, die einer anderen der identifizierten unterschiedlichen Daten-Teilmengen entsprechen, in einer Kontrollliste 12 abzulegen. In der Kontrollliste 12 abgelegte Daten können anschließend überwacht werden (Schritt S120), um zu ermitteln, mit welchen Daten der Cache-Speicher zu belegen ist S121. „Ohne Verzögerung“ bedeutet sofort oder ohne weitere Aufforderung z.B. mit der minimalen vertretbaren Zeit, die durch Logik und Schaltungen zugelassen wird. Das könnte z.B. durch eine maximale Geschwindigkeit gesteuert werden, mit der Belegungen ausgeführt werden können. Mit anderen Worten, der Cache-Speicher kann mit den „aktuellsten“ Daten sofort belegt werden, wobei die restlichen Daten zur „Beobachtung“ in der Kontrollliste abgelegt werden und der Cache-Speicher später bei Bedarf mit ihnen belegt wird.
• Tatsächlich können mehrere Daten-Teilmengen in ankommenden ACD identifiziert werden. Wie in 4 dargestellt können z.B. drei Typen von Teilmengen von Daten identifiziert werden: (i) ein erster Typ (schraffierte Segmente), der sofort identifiziert wird, da er Daten entspricht, die bereits zwischengespeichert sind und die demzufolge verworfen werden, Schritt S11b; (ii) ein zweiter Typ (gepunktete Segmente), der aktuellen Daten entspricht, mit denen der Cache sofort belegt werden sollte (Schritt S11) und (iii) ein dritter Typ (weiße Segmente), der weniger aktuellen Daten entspricht, die in der Kontrollliste 12 abgelegt werden sollen. Es ist verständlich, dass die oben genannten Teilmengen (ii) und (iii) am wirkungsvollsten verarbeitet und verwaltet werden, wenn die Daten-Teilmengen (i) der ACD zuerst gefiltert werden, um Daten zu entfernen, die sich bereits im Cache-Speicher befinden.
• Wie ferner in der Cachespeicher-Aktualisierungslogik 10 und dem Belegungsmechanismus 24 bis 25 der 3 bis 4 dargestellt, können zusätzliche Daten in der Kontrollliste 12 abgelegt werden, Schritt S200Ma. Diese Daten können z.B. Fehltreffer-Daten eines lokalen Cache-Speichers entsprechen, z.B. lokalen Lese-Fehltreffern oder LRM, d.h. Daten, die eine Darstellung von Cachespeicherzugriff-Fehltreffern sind, die durch einen lokalen Server und unabhängig von den empfangenen ACD gesammelt werden. Demzufolge können sowohl die Fehltrefferdaten eines lokalen Cache-Speichers LRM und eine Daten-Teilmenge der ACD in der Kontrollliste abgelegt und überwacht werden (Schritt S120), um zu ermitteln, mit welchen Daten der Cache-Speicher später belegt werden soll, Schritt S121. Das ermöglicht, genauer und schneller auf Änderungen der Arbeitslast in den lokalen Servern zu reagieren. In dieser Hinsicht kann ein lokaler Server an in stärkerem Maße feinstrukturierten Fragmenten anstelle von Datenbereichen betrieben werden (z.B. 1 MB anstelle von 1 GB, wie in 4 dargestellt). Wenn nun ein einzelnes Fragment in einem vollständigen Datenbereich „aktuell“ erscheint, kann die Aktualität des Bereichs, zu dem das Fragment gehört, und der in dem zentralen System CS beobachtet wird, nicht groß genug sein, damit es in den ACD als aktuell markiert (oder sogar zusammengeführt) wird. Dieses „aktuelle“ Fragment kann jedoch trotzdem für eine Vor-Ort-Überwachung der Kontrollliste angefügt werden, wodurch ermöglicht wird, dass der Cache-Speicher nachfolgend mit ihm belegt wird. Weitere Gründe, warum das zentrale System nicht genügend Cachespeicherzugriff-Fehltreffer „sieht“, bestehen darin, dass auf die speziellen Daten lediglich durch einen lokalen Server zugegriffen wird oder sie in der Vergangenheit nicht betrachtet wurden, somit hatten die historischen Daten keine ausreichende Gewichtung. Außerdem dauert es üblicherweise eine bestimmte Zeit, bis die ACD durch das zentrale System an die lokalen Server bereitgestellt werden. Deswegen kann ein unabhängiges Einfügen der LRM in die Kontrollliste 12 für eine nachfolgende Überwachung dabei helfen, die Reaktionsfähigkeit und/oder die Empfindlichkeit zu verbessern.
• Hinsichtlich der Überwachung der Daten in der Kontrollliste kann dies insbesondere unter Verwendung einer umlaufenden Liste 12a von zwischengespeicherten Objekten ausgeführt werden. Im Einzelnen enthält ein wirkungsvoller Algorithmus das Entfernen eines ältesten zwischengespeicherten Objekts aus der umlaufenden Liste 12a, vorausgesetzt, dass dieses älteste zwischengespeicherte Objekt während einer vorgegebenen Zeitspanne, z.B. einem letzten Taktumlauf, nicht angefordert wurde. Das kann z.B. unter Verwendung einer modifizierten Version umgesetzt werden. In dem vorliegenden Kontext kann dieser Algorithmus so umgesetzt werden, dass er eine umlaufende Liste von zwischengespeicherten Objekten im Speicher führt, wobei ein Iterator (der „Taktzeiger“) auf die älteste Zeile in der Liste zeigt. Für jede Seite hält der Algorithmus ein Referenzbit vor, das im gesetzten Zustand angibt, dass während des letzten Taktumlaufs auf die Seite zugegriffen wurde. Wenn ein Cachespeicherzugriff-Fehltreffer auftritt und in dem Cache-Speicher kein freier Platz vorhanden ist (d.h. der Cache-Speicher ist voll), wird das Referenzbit an der Zeigerposition untersucht. Wenn dieses Bit null (d.h. „nicht gesetzt“) ist, wird das zwischengespeicherte Objekt, auf welches der „Zeiger“ zeigt, fallen gelassen, und der Rahmen der leeren Seite kann somit einer ankommenden Seite zugewiesen werden. Andererseits wird das Referenzbit gelöscht und der Taktzeiger wird inkrementiert, so dass er in der umlaufenden Liste auf die nächste Seite zeigt. Der Vorgang wird wiederholt, bis eine „Opfer“-Seite gefunden wird. In Varianten könnten andere Seitenersetzungs-Algorithmen (First In, First Out (FIFO), Second-Chance usw.) verwendet werden. Die oben genannte Lösung (Algorithmus mit modifiziertem Takt) ist jedoch eine wirkungsvolle Version des FIFO (z.B. wirkungsvoller als Second-Chance), da zwischengespeicherte Objekte in der Liste nicht ständig verschoben werden müssen.
• Bisher wurden Ausführungsformen der Erfindung hauptsächlich in Bezug auf Verfahrensschritte beschrieben. Die Erfindung kann jedoch gemäß ihrer weiteren Aspekte als ein computergesteuertes System umgesetzt werden, das eine oder mehrere Komponenten enthält, die oben erwähnt wurden (d.h. wenigstens ein gemeinsam genutztes Datenspeichersystem (oder kurz gesagt ein „zentrales System“) und/oder einen lokalen Server). Allgemein ausgedrückt kann ein derartiges computergesteuertes System in geeigneter Weise eingerichtet sein, um die Verfahrensschritte, die den Komponenten zugewiesen sind, auszuführen.
• Dieses computergesteuerte System kann z.B. auf ein gemeinsam genutztes Datenspeichersystem CS beschränkt sein. Das Letztere kann insbesondere aufweisen:
• - eine (nicht gezeigte) Empfangseinheit, die so eingerichtet ist, dass sie Cachespeicherzugriff-Trefferdaten und Cachespeicherzugriff-Fehltrefferdaten von jedem der lokalen Server LS1 LS2 (möglicherweise unabhängig) empfängt;
• - eine (nicht gezeigte) Zusammenführungslogik, die so eingerichtet ist, dass sie wenigstens einen Teil der empfangenen Cachespeicherzugriff-Trefferdaten und Cachespeicherzugriff-Fehltrefferdaten zu den ACD zusammenführt; und
• - eine (nicht gezeigte) Schnittstelle, die so eingerichtet ist, dass sie ermöglicht, dass die ACD zu (jedem der) lokalen Servern LS1, LS2 gesendet werden. Wie oben erwähnt, kann die Zusammenführung in Abhängigkeit von dem Zielserver kundenspezifisch erfolgen.
• Dieses computergesteuerte System kann nun in ähnlicher Weise auf einen lokalen Server beschränkt sein. Der Letztere kann insbesondere eine (nicht gezeigte) Schnittstelle, um Cachespeicherzugriff-Daten dem zentralen System CS verfügbar zu machen, und eine Empfängereinheit zum Empfangen von zusammengeführten Cachespeicherzugriff-Daten ACD aufweisen. Es kann ferner eine Cachespeicher-Belegungslogik 10 und Cachespeicher-Belegungswerkzeuge 24 aufweisen, wie in den 3 bis 4 veranschaulicht ist.
• Das computergesteuerte System kann natürlich wie oben beschrieben sowohl ein gemeinsam genutztes Datenspeichersystem CS und einen oder mehrere lokale Server LS1, LS2 aufweisen.
• Die Erfindung kann schließlich außerdem als ein Computerprogrammprodukt ausgeführt werden, das ein computerlesbares Speichermedium aufweist, das darin verkörperten computerlesbaren Programmcode aufweist, wobei der Programmcode so eingerichtet ist, dass er jeden der Schritte des oben beschriebenen Verfahrens umsetzt. Einzelheiten des Programmcodes und seine algorithmischen Aspekte sind im nächsten Abschnitt angegeben.
• Die obigen Ausführungsformen wurden unter Bezugnahme auf die beigefügten Zeichnungen kurz und knapp beschrieben und können mehrere Varianten enthalten, die unter Bezugnahme auf alle Aspekte der Erfindung beschrieben wurden. In Ausführungsformen können verschiedene Kombinationen der oben genannten Merkmale vorgesehen sein.
• Demzufolge kann ein computergesteuertes System 1 gemäß Ausführungsformen der Erfindung insbesondere aufweisen:
• - einen lokalen Server LS1, der eine schnelle Einheit als Cache-Speicher verwendet, z.B. eine Flash-SSD;
• - einen gemeinsam genutzten Datenspeicher-Server CS, der eine Backend-Speichereinrichtung darstellt, die mehrere Speichermedien verwendet;
• - ein Schichtungs-Modul T in dem Speicherserver zum Identifizieren von aktuellen Daten und zum Speichern aktueller Daten auf einem schnellen Speichermedium.
• Zu einem weiteren Beispiel gehört ein computergesteuertes System 1, das insbesondere aufweist: einen oder mehrere lokale Server LS1, LS2 und ein zentrales geschichtetes (tiered) Speichersystem CS, wobei das zentrale System:
• - grobstrukturierte globale statistische Angaben (auf der Grundlage der beobachteten konsolidierten Arbeitslast und zusammengeführter lokaler statistischer Angaben von lokalen Servern) vorhält,
• - Daten in Speichermedien ablegt, die unterschiedliche Leistungscharakteristiken aufweisen, die sich auf diese grobstrukturierten globalen statistischen Angaben gründen, und
• - grobstrukturierte statistische Cachespeicher-Angaben ACD an einzelne lokale Server auf der Grundlage der globalen statistischen Angaben bereitstellt, und wobei jeder der lokalen Server:
• - feinstrukturierte lokale statistische Angaben vorhält (auf der Grundlage von lokal beobachteten Arbeitslasten); und
• - den lokalen Cache-Speicher gemäß der feinstrukturierten lokalen und der grobstrukturierten globalen statistischen Angaben belegt.
• Detaillierte Beispiele von bevorzugten Ausführungsformen werden im nächsten Abschnitt erläutert.
• Spezifische Ausführungsformen und Einzelheiten der technische Umsetzung
• Bei den speziellen Ausführungsformen, die im Folgenden beschrieben werden, wird ein Mechanismus zum Koordinieren von lokalen Cachespeicher-Servern und des zentralen Cache-Speichers in einer SAN-Umgebung vorgeschlagen. Das Ziel besteht darin, die Leistungsfähigkeit von Cachespeichern durch gezielte Nutzung des Verknüpfens von kurz- und langfristigen statistischen Angaben zu verbessern. Die lokalen Cache-Speicher melden statistische Angaben der Cachespeicherzugriff-Treffer (z.B. zu einer geeigneten Struktur zusammengeführt, z.B. auf Bereichsebene zur Verwendung durch das zentrale System) periodisch an das zentrale System, und das zentrale System konsolidiert die Trefferstatistik des lokalen Cache-Speichers zusammen mit seinen eigenen Arbeitslast-Statistiken (in Bezug auf Cachespeicherzugriff-Fehltreffer der lokalen Server und außerdem auf Verlaufsdaten, die Cachespeicherzugriff-Treffer und Fehltreffer von lokalen Servern entsprechen) und stellt die konsolidierten statistischen Angaben für alle lokalen Server zur Verfügung. Die konsolidierten statistischen Angaben, die an lokale Server zurückgegeben werden, können deswegen auf einen speziellen Server zugeschnitten sein. Jeder lokale Server verwendet dann die konsolidierten statistischen Angaben, um die Leistungsfähigkeit des lokalen Servers zu verbessern. Der lokale Server erreicht dies durch gezielte Nutzung der Fähigkeit zum Verknüpfen von zwingend erforderlichen Cachespeicher-Belegungen aus zentralen statistischen Angaben mit einer selektiven Cachespeicher-Belegung auf der Grundlage von lokalen und zentralen statistischen Angaben.
• Die Gesamtarchitektur ist in 1 gezeigt und wurde bereits im vorhergehenden Abschnitt erläutert. Die Doppelpfeile zwischen lokalen Servern LS1, LS2 und dem zentralen System CS stellen den Austausch von statistischen Angaben dar, der periodisch oder sporadisch erfolgen kann.
• Das zentrale System kann zum Beispiel jeden Cachespeicher-Mechanismus CC verwenden, der bei SAN-Speicherservern bekannt ist. Es kann außerdem einen Schichtungs- (T-) Mechanismus oder sogar eine Kombination CC/T aus Cachespeicher- und Schichtungs-Mechanismen verwenden. Trotzdem wird ein automatisierter Schichtungs-Mechanismus vorteilhaft verwendet (z.B. der IBM EasyTier-Mechanismus), um aktuelle (hot) Daten einer schnelleren Speichereinheit (z.B. SSD, Flash) zuzuweisen und nichtaktuelle (cold) Daten HDDs oder einer schnellen HDD-Schicht (tier) bzw. einer langsamen HDD-Schicht zuzuweisen. Das zentrale System kann Daten in dem Backend-Speicher in Schichten anordnen, damit die Daten für die Arbeitslast besser optimiert werden. Der eigentliche Cache-Speicher weist keine Schicht auf, und Schichtung (tiering) bezeichnet die Neuanordnung von Daten in dem Backend-Speicher. Wie bekannt bezeichnet ein Backend-Speicher das tatsächliche dauerhafte Speichermedium, z.B. HDDs, bei denen die eigentlichen Daten dauerhaft gespeichert werden.
• Im Folgenden bezeichnet die Terminologie „zentraler Cache-Speicher“ den Cache-Speicher des zentralen Systems, d.h. das gemeinsam genutzte Datenspeichersystem CS. Durch Erweiterung kann sie Operationen, die den zentralen Cache-Speicher steuern, und somit das eigentliche zentrale System bezeichnen.
• Da alle Fehltreffer des lokalen Cache-Speichers von Arbeitslasten schließlich zu dem SAN-Server gelangen, um die entsprechenden Daten zu erfassen, besteht für die lokalen Server keine Notwendigkeit, statistische Angaben über Cachespeicherzugriff-Fehltreffer zu melden (über die Anforderungen von Cachespeicherzugriff-Fehltreffern hinaus, die „normalerweise“ an den zentralen Server adressiert sind). In Systemen nach dem Stand der Technik jedoch werden in dem zentralen Server die lokalen Cachespeicherzugriff-Treffer, die von den lokalen Cache-Speichern bedient werden, nicht bemerkt. Deswegen sind in vorliegenden Ausführungsformen die lokalen Server nun für das Sammeln von statistischen Angaben über Cachespeicherzugriff-Treffer zuständig und melden diese an das zentrale System.
• Zur Erinnerung, da das zentrale System alle Cachespeicherzugriff-Fehltreffer jedes lokalen Cache-Speichers bemerkt, kann das zentrale System die Cachespeicherzugriff-Fehltreffer und die gemeldeten statistischen Angaben zu Cachespeicherzugriff-Treffern für jeden lokalen Cache-Speicher verknüpfen. Ein ähnlicher Konsolidierungsmechanismus wie jener, der für Daten/Datenkennungen, die Cachespeicherzugriff-Fehltreffern entsprechen, und Daten/Datenkennungen, die Cachespeicherzugriff-Treffern entsprechen, verwendet wurde, kann verwendet werden. Das zentrale System stellt dann diese statistischen Angaben für jeden lokalen Server bereit. Das kann entweder durch den lokalen oder den zentralen Cache-Speicher ausgelöst werden:
• - Bei einem Pull-Modell lösen lokale Server einen Datenaustausch mit dem zentralen System aus, entweder zum Senden der statistischen Angaben zu Cachespeicherzugriff-Treffern oder zum Fragen nach den konsolidierten statistischen Angaben des zentralen Cache-Speichers.
• - Bei einem Push-Modell sendet das zentrale System periodisch die konsolidierten statistischen Angaben zu den lokalen Servern.
• Der Austausch von statistischen Angaben zwischen den lokalen Servern und dem zentralen System kann „inband“ oder „außerband“ ausgeführt werden. Inband bedeutet, dass der Austausch von statistischen Angaben in den Datenweg eingebettet ist, über den der Anwendungsserver Daten liest oder speichert, z.B. Fibre Channel oder SCCI. Außerband bedeutet, dass beim Austausch von statistischen Angaben ein unabhängiger Datenübertragungskanal zwischen den Anwendungsservern und dem SAN-Speicherserver verwendet wird.
• Häufig sind lokale Cache-Speicher so ausgelegt, dass sie die örtliche und zeitliche Lage von Arbeitslasten ausnutzen. Bei dem zentralen System, das statistische Abgaben konsolidiert, die von allen lokalen Cache-Speichern gewonnen werden, und sie für alle lokalen Cache-Speicher zur Verfügung stellt, kann die Leistungsfähigkeit von lokalen Cache-Speichern stark verbessert werden, da diese statistischen Angaben eine zentrale sowie langfristige Ansicht darstellen, in welchem Umfang Daten es wert sind, zwischengespeichert zu werden (d.h. der „aktuelle“ Bereich). Eine Möglichkeit zum Verbessern der Leistungsfähigkeit von lokalen Cache-Speichern besteht darin, diesen Bereich aktueller Daten, der durch die statistischen Angaben des CS angegeben ist, bedingungslos dem lokalen Cache-Speicher anzufügen. Es wird angemerkt, dass lokale Cache-Speicher statistische Angaben zu Cachespeicherzugriff-Treffern mit anderer Häufigkeit melden können als die Häufigkeit, mit der die konsolidierten statistischen Angaben von dem zentralen Cache-Speicher empfangen werden.
• Im Folgenden werden Ausgestaltungen lokaler Cache-Speicher offenbart, die die zentralen statistischen Angaben verwenden, um die Leistungsfähigkeit von Zwischenspeicherungen zu verbessern.
• Bei bevorzugten Ausführungsformen der Ausgestaltung von lokalen Cache-Speichern meldet der lokale Cache-Speicher statistische Angaben zu Cachespeicherzugriff-Treffern z.B. die Anzahl der Treffer pro Datenbereich, an das zentrale System und empfängt periodisch konsolidierte statistische Angaben für einen Datenbereich von 1 GB, z.B. alle 15 Minuten. Für den lokalen Cache-Speicher können z.B. SATA- oder SAS-Flash-SSDs oder PCI-e-Flash-Cards als Speichermedium verwendet werden, auf dem sich die zwischengespeicherten Daten befinden werden. Unter der Annahme, dass der lokale Flash-Cache die zwischengespeicherten Daten in 1-MB-Fragmenten organisiert, beträgt die Größe von zwischengespeicherten Entitäten 1 MB.
• Üblicherweise bezeichnen Datenbereiche (z.B. 1 GB Daten) eine Anzahl von aufeinanderfolgenden Fragmenten (mit fester Größe). Ein Fragment bezeichnet einen Abschnitt fester Größe eines Datenbereichs und ein Vielfaches eines Blocks mit fester Größe. Die Blockgröße ist in dem System ab initio festgelegt. Jeder der Abschnitte wird üblicherweise a priori ermittelt und ist deshalb nicht dynamisch. Bereiche und Fragmente können die Daten sein, mit denen die lokalen Cache-Speicher (bei Bedarf) als Nächstes belegt werden sollen. Vorzugsweise werden Kennungen des Datenbereichs/Fragments, wie im vorhergehenden Abschnitt erwähnt, anstelle der zu verteilenden Daten verwendet. Kennungen werden zum Beispiel vorzugsweise auf der Ebene der Belegungslogik 10 des lokalen Cache-Speichers, 3 verwendet. In jedem Fall bezeichnet der Bereich/das Fragment eindeutig die Daten, die verteilt werden sollen. Zwischen Bereich/Fragment von Daten und Kennungen von Bereich/Fragment von Daten wird demzufolge im Folgenden nicht unterschieden, da sie dieselben Daten bezeichnen.
• Es wird angemerkt, dass nach dem Stand der Technik ein Bereich gelegentlich als ein durchgehender Speicherbereich in einem Computer-Dateisystem definiert ist, der für eine Datei reserviert ist. Im vorliegenden Fall sind „Bereiche“ nicht notwendigerweise für Dateien reserviert, entsprechen jedoch trotzdem einem durchgehenden Bereich des Speicherraums (jedoch nicht in einem Computer-Dateisystem, sondern in einem Speichersystem).
• Im Fall eines lokalen Festwert-Cachespeichers, d.h. ein Cache-Speicher, der lediglich nichtmodifizierte Daten zwischenspeichert, wenn eine Benutzer-Leseanforderung empfangen wird, wird der lokale Cache-Speicher zuerst abgefragt. Wenn es sich um einen Cachespeicherzugriff-Treffer handelt, können Daten von dem lokalen Flash-Cachespeicher gelesen werden und zurück zur Anwendung gesendet werden. Andernfalls (Cachespeicherzugriff-Fehltreffer) wird die Anforderung zu dem SAN-Speicherserver weitergeleitet. Beim Empfangen der angeforderten Daten von dem SAN-Speicherserver, werden die Daten zurück zu der anfordernden Anwendung gesendet und können in Abhängigkeit von ihrer Datengröße und ihrer Aktualität in dem lokalen Flash-Cachespeicher abgelegt werden. Bei einer Benutzer-Schreibanforderung wird die alte Kopie der Daten gegebenenfalls in dem lokalen Cache-Speicher ungültig gemacht, und die Daten werden in den SAN-Speicherserver geschrieben. Es ist klar, dass dies für eine vorgegebene Leseanforderung geschehen kann, es können jedoch nur einige der angeforderten Daten in dem Cache-Speicher gefunden werden, das heißt, ein Teil der Anforderung kann ein Cachespeicherzugriff-Treffer und ein Teil von ihr ein Cachespeicherzugriff-Fehltreffer sein. Dieser Fall kann als ein „teilweiser“ Treffer bezeichnet werden. In einem derartigen Fall kann der lokale Cache-Speicher entscheiden, die Trefferdaten von dem Cache-Speicher und die fehlenden Daten von dem SAN bereitzustellen oder alle Daten von dem SAN bereitzustellen, wobei eine derartige Entscheidung durch eine Strategie gesteuert würde, die als eine Strategie teilweiser Treffer bezeichnet wird. In jedem Fall gelten die oben erwähnten Grundgedanken für die Bereitstellung von Treffern und Fehltreffern für teilweise Treffer bzw. teilweise Fehltreffer, da ein teilweiser Treffer als ein Fehltreffer oder als komplementäre Fehltreffer und Treffer verarbeitet werden kann.
• Wie im vorhergehenden Abschnitt erwähnt werden die meisten Cachespeicher-Belegungsoperationen vorzugsweise durch eine asynchrone Ausführungseinheit 10 (z.B. einen speziellen Software-Thread) gesteuert. Das bedeutet, dass die eigentlichen Cachespeicher-Belegungsoperationen außerhalb des kritischen Datenwegs betrieben werden. 3 zeigt die Gesamtprozedur der asynchronen Logikbelegung, zu der verschiedene Komponenten der Verwaltung des lokalen Cache-Speichers gehören, und zwar die Cachespeicher-Belegungslogik 10 (wobei die letztere Filter 11, Kontrollliste 12, Warteschlangen 21, 22 und Scheduler 23 enthält), Daten-Verlagerungseinrichtung 24, Direct-Attach-Storage- (DAS-) Flash-Cachespeicher 26 und Cachespeicher-Verzeichnis 25.
• Die aktuelle Liste ACD, die im Schritt S400 empfangen wurde, und die lokalen Lese-Fehltreffer LRM, die im Schritt S200Ma empfangen wurden, werden zu dem Filter 11 bzw. der Kontrollliste 12 gesendet. Auf der Grundlage der aktuellen Liste ACD und der lokalen Lese-Fehltreffer LRM, die empfangen wurden, erzeugt die Belegungslogik 10 eine Folge von Cachespeicher-Belegungsanforderungen (Schritte S11, S121). Die Cachespeicher-Belegungsanforderungen werden zu zwei Warteschlangen 21, 22 gesendet, die durch die Daten-Verlagerungseinrichtung 24 verarbeitet werden, wie im vorhergehenden Abschnitt erläutert. Die Warteschlangen werden außerdem vorzugsweise bei einer niedrigeren Priorität und/oder bei einer begrenzten Bandbreite im Vergleich zu normalen Benutzer-Lese/Schreibanforderungen verarbeitet. Die beiden Warteschlangen können von einem Scheduler 23 mit strenger Priorität bedient werden. In Varianten könnte jedoch stattdessen lediglich eine Warteschlange verwendet werden. Das Vorhandensein zweier Warteschlangen bringt jedoch zukünftig mehr Daten, die wahrscheinlich einen Treffer darstellen, schneller in den Cache-Speicher und macht es einfacher, Anforderungen mit hoher Priorität zu verwalten, da die Anforderungen mit hoher Priorität in einer Warteschlange und Anforderungen mit niedrigerer Priorität in der anderen Warteschlange abgelegt werden können. Anschließend liest die Daten-Verlagerungseinrichtung 24 die Daten, die für eine Cachespeicher-Belegung von dem SAN-Speicherserver CS vorgehalten werden (Schritt S450) und speichert sie im Direct-Attach-Storage- (DAS-) Cache-Speicher 26 (Schritt S550); das Cachespeicher-Verzeichnis 25 wird dementsprechend aktualisiert, Schritt 560. Das Cachespeicher-Verzeichnis 25 kann ansonsten immer dann aktualisiert werden, wenn der lokale Server LS einen lokalen Lesetreffer bestätigt, Schritt S200Ha. Wie früher erläutert kann das Filter 11 weiterhin diejenigen Daten ausfiltern, die sich bereits im Cache-Speicher befinden, Schritt S11b, siehe außerdem 4. Während angewiesen wird, dass der Cache-Speicher mit den aktuellsten Datenfragmenten direkt belegt wird (S11), werden die weniger aktuellen Datenfragmente zu der Kontrollliste 12 gesendet, Schritt S11a.
• Somit wird der SAN-Speicherserver CS bei mehreren Gelegenheiten benötigt: ein erstes Mal (Schritt S400), um die zusammengeführten Cachespeicher-Dateninformationen ACD, d.h. die globalen statistischen Angaben, bereitzustellen, und ein zweites Mal (S450) zum Abfragen der eigentlichen Daten, die jenen Daten entsprechen, die bei Bedarf für eine Cachespeicher-Belegung vorgehalten werden. In der Ausführungsform von 3 fällt die Belegungslogik 10 Entscheidungen auf der Grundlage von Datenkennungen anstelle der eigentlichen Daten, wodurch in diesem Fall der Schritt S450 erforderlich ist. Dadurch kann die Menge von ACD-Daten, die zu lokalen Servern weitergeleitet werden, deutlich verringert werden, da nicht alle Daten, die in den ACD-Daten identifiziert sind, lokal zwischengespeichert werden. In Varianten könnten natürlich eigentliche Daten zusammen mit den ACD gesendet werden, wobei in diesem Fall der Schritt S450 nicht mehr erforderlich wäre. Das System CS wird schließlich außerdem benötigt, um auf „gewöhnliche“ Cachespeicherzugriff-Fehltreffer-Anforderungen von lokalen Servern zu reagieren; wobei dieser Punkt in den Zeichnungen nicht explizit gezeigt ist, die entsprechenden Operationen sind jedoch den Schritten S450, S550 und S560 in 3 ähnlich.
• 4 zeigt eine genaue Prozedur für einen lokalen Server, der zentrale statistische Abgaben ACD verwendet, d.h. die aktuelle Bereichsliste ACD, die durch den SAN-Speicherserver CS gesendet wurde, um Cachespeicher-Belegungsentscheidungen zu treffen. Wie in 4 dargestellt, erzeugt der SAN-Speicherserver CS eine geordnete Liste von Bereichen ACD, d.h., in der Datenbereiche gemäß ihrer Aktualität sortiert sind. Diese wird vorzugsweise durch Verknüpfen statistischer Angaben zu gegenwärtigen und früheren Cachespeicherzugriff-Treffern sowie Cachespeicherzugriff-Fehltreffern erreicht. Jeder der Bereiche in den ACD stellt eine Liste von aufeinanderfolgenden Fragmentkennungen dar, mit denen möglicherweise später eine Belegung erfolgen kann. Wie erwähnt filtert der lokale Cache-Speicher beim Empfangen der geordneten Liste aktueller Bereiche ACD zuerst Fragmentkennungen von jenen Fragmenten aus, die sich bereits in dem Cache-Speicher befinden, d.h. bereits im Cache-Speicher vorhanden sind, oder während der Belegung, Schritt S11b. Die übrigen Fragmentkennungen (d.h. Kennungen von nicht vorhandenen Fragmenten) enthalten wahrscheinlich einige wenige „sehr aktuelle“ Fragmentkennungen (gepunktete rechtwinklige Segmente): diese werden direkt zur Belegungswarteschlange 21 gesendet (Schritt S11). Die Warteschlangen 21, 22 von 3 sind wie gesagt vorzugsweise für einen Scheduler 23 mit strenger Priorität reserviert. Die Ausführungseinheit 10 der Belegungslogik verwendet diese Belegungsanforderungen und führt sie asynchron aus.
• Es gibt mehrere mögliche Mechanismen zum Ermitteln der Anzahl von Fragmenten, die „sehr aktuell“ sind; wobei die Menge von sehr aktuellen Fragmenten vorzugsweise variabel ist. Sie müsste eingestellt werden, wenn z.B. die Daten in der Hinweisliste ACD vollständig infolge eines vorhergesagten oder durch eine Anwendung ausgelösten Ereignisses vorhanden sind, wobei in diesem Fall die Fragmente ungeachtet von Maßzahl oder Arbeitslast belegt werden müssten. Es wird angemerkt, dass sich eine derartige Fragmentkennung bereits in der Belegungskontrollliste befinden könnte. In diesem Fall ist es nützlich, sie aus der Kontrollliste zu entfernen. Die verbleibenden weniger aktuellen Fragmentkennungen werden in die Belegungskontrollliste 12 eingefügt, die vorzugsweise durch eine modifizierte Version des Takt-Algorithmus betrieben wird, um Fragmente herauszufinden, die für eine Belegung infrage kommen, d.h. es gemäß bestimmten Regeln wert sind.
• Außerdem und wie bereits früher erwähnt können andere Streams (S200Ma) von Fragmentkennungen der Belegungskontrollliste 12 angefügt werden, z.B. jede Fragmentkennung LRM, bei der kürzlich ein Lese-Fehltreffer aufgetreten ist.
• Genauer gesagt, ein Referenz-Pseudo-Trefferzählwert C kann für jede Fragmentkennung in der Kontrollliste 12 geführt werden. Die Belegungskontrollliste 12 kann folgendermaßen verwaltet werden: beim Eintreffen einer Fragmentkennung an der Belegungskontrollliste wird zuerst geprüft, ob sich die Fragmentkennung bereits in der Belegungskontrollliste befindet. Das erfolgt unabhängig davon, ob die Fragmentkennung von der geordneten Liste von aktuellen Bereichen oder von einem Lese-Fehltreffer oder einer anderen Quelle stammt. Daher wird,
• - falls die Fragmentkennung ein Lese-Fehltreffer ist und einen Pseudo-Treffer in der Kontrollliste zur Folge hat, ihr Pseudo-Trefferzählwert C um 1 erhöht. Des Weiteren wird,
• - falls der Pseudo-Trefferzählwert C größer als ein Schwellenwert T ist (oder gleich diesem ist), die Fragmentkennung aus der Kontrollliste entfernt und in einer Belegungswarteschlange abgelegt (Schritt S121).
• Wenn es sich nun bei der Fragmentkennung um einen Teil der Hinweis-ACD des zentralen Systems handelt, der in der Kontrollliste vorhanden ist, muss in diesem Fall nichts Besonderes getan werden. Es ist vorgesehen, dass der Pseudo-Trefferzähler für ACD-Hinweise nicht erhöht wird, d.h., ein Pseudo-Treffer tritt lediglich für lokale Lese-Fehltreffer LRM auf, so dass nichtaktuelle Fragmente in den ACD im Vergleich zu lokalen Lese-Fehltreffern LRM keine Extratreffer erhalten.
• Wenn sich die Fragmentkennung noch nicht in der Kontrollliste befindet, wird eine Ersetzungsprozedur begonnen, indem der Zeiger des Takts 12a durch einen umlaufenden Puffer bewegt wird und die folgenden Schritte in einer Schleife ausgeführt werden:
• - Wenn das gezeigte Element frei ist, wird die Position von der ankommenden Fragmentkennung eingenommen, und ihr Trefferzählwert wird auf null initialisiert. Die Prozedur hält dann an.
• - Wenn das gezeigte Element einen niedrigen Treffer-Zählwert aufweist (z.B. ein bestimmter Wert nahe null oder ein Bruchteil von 7) verglichen mit dem mittleren Treffer-Zählwert bei dem nichtresidenten Takt, wird es entfernt und seine Position wird von einem ankommenden Fragment eingenommen, wobei sein Treffer-Zählwert auf null initialisiert wird. Die Prozedur hält dann an.
• - Andernfalls wird der Referenz-Zählwert der gezeigten Fragmentkennung zurückgesetzt oder durch einen Zerlegungsfaktor (wie z.B. 2 oder 3) geteilt, und anschließend bewegt sich der Taktzeiger zum nächsten Element.
• Die Schleife kann im Allgemeinen ausgeführt werden, bis die neue Fragmentkennung einen Platz in der Kontrollliste gefunden hat. Sie kann alternativ nach einer bestimmten Anzahl von Taktzeiger-Bewegungen angehalten werden, um die ausgeführten Verarbeitungszyklen zu begrenzen. Im letzteren Fall muss im letzten Umlauf entschieden werden, welche Fragmentkennung (die neue Fragmentkennung oder eine an der gegenwärtigen Position des Taktzeigers) behalten wird und welche verworfen wird. Die Entscheidung kann eine Funktion der gegenwärtigen Werte C und T sein.
• Der Schwellenwert T kann als ein konfigurierbarer Wert z.B. 3 eingestellt werden. Dieser Wert kann durch gezieltes Probieren (Trial-and-Error) neu definiert werden. Da dieser Wert die Cachespeicher-Leistungsfähigkeit beeinflusst, wird vorzugsweise ein Verfahren verwendet, um einen adaptiven Schwellenwert wie folgt einzustellen.
• - Unter der Voraussetzung, dass residente Fragmente durch einen weiteren Takt 24a auf der Grundlage ihres Referenz-Zählwerts verwaltet werden, kann das Verfahren des adaptiven Schwellenwerts den (veränderlichen) Mittelwert des Referenz-Zählwerts der zuletzt verworfenen Fragmente, z.B. Ce, das im Schritt S570 verworfen wurde, verfolgen.
• - Anschließend wird die Geschwindigkeit der Taktverschiebung für beide Takte gemessen (d.h. der Takt für residente Daten 24a und der Takt 12a für nichtresidente Daten, d.h. in der Kontrollliste).
• Zum Beispiel: während einer vorgegebenen Zeitperiode macht der residente Takt 24a Nr Umläufe, während der nichtresidente Takt 12a Nn Umläufe macht. Der Schwellenwert T wird dann auf Ce Nr/Nn gesetzt.
• Es wird daran erinnert, dass T per definitionem der Schwellenwert des Referenz-Zählwerts zum Füllen von nichtresidenten Fragmenten in den lokalen Cache-Speicher ist. Durch Einstellen T = Ce Nr/Nn wird erwartet, dass die Fragmente, die in den lokalen Cache-Speicher 26 eintreten, nützlicher sind als die verworfenen Fragmente.
• In einem extremen Fall könnte es (wenigstens theoretisch) vorkommen, dass es für eine Zeitperiode keine Belegungsanforderungen gibt, wobei T dann auf null gesetzt wird, da Nr = 0. Das ist nicht erwünscht, da eine Belegung mit nichtaktuellen Fragmenten erfolgen darf. Um diesen extremen Fall zu vermeiden, erzwingt die Belegungslogik eine minimale Belegungsgeschwindigkeit, und zwar wird die Belegungslogik für eine gegebene Zeitperiode wenigstens Tf Fragment-Belegungsanforderungen ausgeben, wobei Tf eine im Voraus definierte kleine Zahl ist.
• Um eine Belegung mit einem nichtresidenten Fragment auszuführen, muss ein residentes Fragment aus dem lokalen Cache-Speicher entfernt werden, wenn der Cache-Speicher voll ist. Das residente Fragment, das entfernt werden soll, wird durch einen Entfernungsalgorithmus ausgewählt. In einer bevorzugten Ausführungsform wird der Takt-Algorithmus verwendet, bei dem für jedes residente Fragment ein Referenz-Zählwert verwendet wird, um Cachespeicherzugriff-Treffer aufzuzeichnen. Jene Fragmente mit wenigen Treffern werden entfernt, wenn der Taktzeiger auf sie zeigt. Der SAN-Speicherserver oder die Anwendung kann jedoch festlegen, dass bestimmte Fragmente durch den Entfernungsalgorithmus nicht für eine Entfernung berücksichtigt werden (z.B. Fragmente, die durch den SAN-Speicherserver als „sehr aktuell“, d.h. „must-have“ („müssen vorhanden sein“) identifiziert werden). Diese „sehr aktuellen“ Fragmente bleiben solange in dem lokalen Cache-Speicher wie durch den SAN-Speicherserver bestimmt. Das kann erreicht werden durch das Verwenden eines einzelnen Bit für jedes residente Fragment, das angibt, ob das Fragment festgelegt ist (d.h., es kann nicht aus dem Cache-Speicher entfernt werden). Zu Vollständigkeit verwendet der residente Takt 24a denselben Algorithmus wie der nichtresidente Takt 12a, um Referenz-Zählwerte für Fragmente zurückzusetzen oder zu dämpfen, die aufgegeben werden, da die Referenz-Zählwerte zu niedrig sind.
• Es können viele weitere Varianten als die oben explizit angesprochenen vorgesehen werden. Der zentrale Server kann z.B. einen Schichtungs-Mechanismus selbständig, d.h. ohne einen Cachespeicher-Mechanismus umsetzen. Als weiteres Beispiel kann jeder der lokalen Server LS1, LS2 grobstrukturierte lokale statistische Angaben assemblieren, um sie dem zentralen System CS in einem für das zentrale System besser geeigneten Format bereitzustellen.
• Bezugszeichenliste

1

Computergesteuertes System

10

Belegungslogik des lokalen Cache-Speichers

11

Filter

12

Kontrollliste

12a

Nichtresidenter (Kontrolllisten-) Takt

21

Erste Warteschlange der Belegungslogik des lokalen Cache-Speichers

22

Zweite Warteschlange der Belegungslogik des lokalen Cache-Speichers

23

Scheduler der Belegungslogik des lokalen Cache-Speichers

24

Datenverlagerungseinrichtung des lokalen Cache-Speichers

24a

Residenter Takt

25

Verzeichnis des lokalen Cache-Speichers

26

Lokaler DAS-Cache-Speicher

A1

Anwendung 1

A2

Anwendung 2

ACD

Zusammengeführte Cachespeicher-Dateninformationen

BES

Backend-Speicher des gemeinsam genutzten Datenspeichersystems

CC

Cache-Speicher des gemeinsam genutzten Datenspeichersystems

CM1

Cache- (DAS-) Speicher 1

CM2

Cache- (DAS-) Speicher 2

CM

Cache- (DAS-) Speicher

CS

Gemeinsam genutztes Datenspeichersystem (Zentrales System, SAN-Speicherserver)

D

Daten, die in dem gemeinsam genutzten Datenspeichersystem gespeichert sind

H

Cachespeicherzugriff-Trefferdaten

H, M

Cachespeicher-Dateninformationen

LRM

Fehltrefferdaten des lokalen Cache-Speichers

LS1

Lokaler Server 1

LS2

Lokaler Server 2

M

Cachespeicherzugriff-Fehltrefferdaten

T

Schichtungs-Mechanismus des gemeinsam genutzten Datenspeichersystems

Claims (12)

1. Verfahren zum Aktualisieren von Cache-Speichern in einem gemeinsam genutzten Datenspeichersystem, wobei das Verfahren aufweist: - Bereitstellen (S100) eines computergesteuerten Systems (1), das das gemeinsam genutztes Datenspeichersystem (CS) und mehrere lokale Server (LS1, LS2) aufweist, wobei: - das gemeinsam genutzte Datenspeichersystem so eingerichtet ist, dass es mit den lokalen Servern zusammenwirkt; - die lokalen Server Anwendungen (A1, A2) unter Verwendung entsprechender Cache-Speicher (CM1, CM2) bedienen; und - jeder der lokalen Server auf Daten (D) zugreift, die in dem gemeinsam genutzten Datenspeichersystem gespeichert sind, - wobei das Verfahren ferner aufweist, - Bereitstellen (S200H, S200M) von Cachespeicher-Dateninformationen von jedem der lokalen Server (LS1, LS2) an das gemeinsam genutzte Datenspeichersystem, wobei die bereitgestellten Cachespeicher-Dateninformationen aufweisen: - Cachespeicherzugriff-Trefferdaten (H), die Cachespeicherzugriff-Treffer von jedem der lokalen Server darstellen; und - Cachespeicherzugriff-Fehltrefferdaten (M), die Cachespeicherzugriff-Fehltreffer von jedem der lokalen Server darstellen; - in dem gemeinsam genutzten Datenspeichersystem Zusammenführen (S300) wenigstens eines Teils der empfangenen Cachespeicherzugriff-Trefferdaten und Cachespeicherzugriff-Fehltrefferdaten zu zusammengeführten Cachespeicher-Dateninformationen (ACD) und Bereitstellen (S400) der zusammengeführten Cachespeicher-Dateninformationen an einen oder mehrere der lokalen Server; und - in dem einen oder den mehreren lokalen Servern Aktualisieren (S500) von einem bzw. mehreren Cache-Speichern, die verwendet werden, um die eine bzw. die mehreren Anwendungen zu bedienen, auf der Grundlage der bereitgestellten zusammengeführten Cachespeicher-Dateninformationen (ACD), - wobei das Aktualisieren (S500) eines Cache-Speichers (CM1) in Bezug auf Anforderungen an den Cache-Speicher (CM1) von einer entsprechenden Anwendung (A1), die durch einen entsprechenden lokalen Server (LS1) bedient wird, asynchron ausgeführt wird durch eine asynchrone Ausführungseinheit unabhängig vom Austausch von Daten zwischen dem lokalen Cache-Speicher und dem gemeinsam genutzten Datenspeichersystem.
2. Verfahren nach Anspruch 1, wobei das Zusammenführen (S300) ferner aufweist das Sortieren der Cachespeicherzugriff-Trefferdaten und der Cachespeicherzugriff-Fehltrefferdaten gemäß dem Vorkommen der Cachespeicherzugriff-Trefferdaten und der Cachespeicherzugriff-Fehltrefferdaten, so dass eine erhaltene Struktur der zusammengeführten Cachespeicher-Dateninformationen das Sortieren widerspiegelt.
3. Verfahren nach einem der Ansprüche 1 bis 2, wobei das Aktualisieren (S500) eines Cache-Speichers (CM1) das Auswählen von Teilmengen von Daten in den zusammengeführten Cachespeicher-Dateninformationen (ACD) und das Belegen (S11, S121) des Cache-Speichers (CM1) gemäß den ausgewählten Teilmengen von Daten aufweist.
4. Verfahren nach Anspruch 3, wobei das Aktualisieren (S500) eines Cache-Speichers (CM1) aufweist: Auswählen von wenigstens zwei unterschiedlichen Teilmengen von Daten in den zusammengeführten Cachespeicher-Dateninformationen (ACD); Anweisen (S11), den Cache-Speicher (CM1) unverzüglich mit Daten zu belegen, die einer der unterschiedlichen Teilmengen von Daten entsprechen; und Anweisen (S11a), Daten, die einer anderen der unterschiedlichen Teilmengen von Daten entsprechen, in einer Kontrollliste (12) abzulegen, wobei das Verfahren die Schritte aufweist: Überwachen (S120) von Daten in der Kontrollliste, um Daten zu ermitteln, mit denen der Cache-Speicher (CM1) belegt werden soll (S121); und Belegen (S121) des Cache-Speichers (CM1) mit den dementsprechend ermittelten Daten.
5. Verfahren nach Anspruch 4, wobei das Verfahren ferner aufweist: Anweisen (S200Ma), zusätzliche Daten, die Fehltrefferdaten (LRM) des lokalen Cache-Speichers entsprechen, in der Kontrollliste (12) abzulegen, wobei die Fehltrefferdaten des lokalen Cache-Speichers Cachespeicherzugriff-Fehltreffer darstellen, die durch einen lokalen Server unabhängig von den zusammengeführten Cachespeicher-Dateninformationen gesammelt werden, so dass sowohl die Fehltrefferdaten des lokalen Cache-Speichers als auch die Daten, die der zweiten der beiden unterschiedlichen Teilmengen von Daten entsprechen, überwacht werden können (S120), um zu ermitteln, mit welchen Daten der Cache-Speicher (CM1) zu belegen ist (S121).
6. Verfahren nach Anspruch 4 oder 5, wobei die Kontrollliste eine umlaufende Liste (12a) von zwischengespeicherten Objekten aufweist und das Überwachen (S120) von Daten in der Kontrollliste das Entfernen eines ältesten zwischengespeicherten Objekts, für das während einer vorgegebenen Zeitperiode kein Zugriff gefordert wurde, aus der umlaufenden Liste (12a) aufweist.
7. Verfahren nach einem der Ansprüche 4 bis 6, wobei das Verfahren ferner das Filtern (S11b) von Daten aufweist, die sich bereits im Cache-Speicher befinden, bevor ein Cache-Speicher mit diesen Daten belegt wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, wobei zusammengeführte Cachespeicher-Dateninformationen bei einer Feinteiligkeit zusammengeführt werden, die größer ist als eine Feinteiligkeit, die bei jedem nachfolgendem Aktualisieren des Cache-Speichers verwendet wird.
9. Gemeinsam genutztes Datenspeichersystem (CS), das so eingerichtet ist, dass es jeden der Schritte ausführt, die durch das gemeinsam genutzte Datenspeichersystem (CS) in einem beliebigen der Verfahren nach den Ansprüchen 1 bis 8 ausgeführt werden.
10. Server (LS1, LS2), der so eingerichtet ist, dass er jeden der Schritte ausführt, die durch einen einzelnen lokalen Server in einem beliebigen der Verfahren nach den Ansprüchen 1 bis 8 ausgeführt werden.
11. Computergesteuertes System (1), das das gemeinsam genutzte Datenspeichersystem (CS) nach Anspruch 9 und mehrere lokale Server (LS1, LS2) jeweils nach Anspruch 10 aufweist.
12. Computerprogrammprodukt zum Verwalten von Cache-Speichern, wobei das Computerprogrammprodukt ein nichtflüchtiges computerlesbares Speichermedium mit computerlesbarem Programmcode aufweist, der darin verkörpert ist, wobei der computerlesbare Programmcode so eingerichtet ist, dass er jeden der Schritte des Verfahrens nach einem der Ansprüche 1 bis 11 umsetzt.

Images