Cloudcache im Überblick

Cloudcache ist eine Funktion, die mithilfe von Profil- und ODFC-Containern Ausfallsicherheit und hohe Verfügbarkeit gewährleistet. Cloudcache verwendet den lokal eingebundenen Container, um regelmäßige Aktualisierungen desRemotespeicheranbieter bereitzustellen. Cloudcache wurde entwickelt, um Benutzer vor kurzfristigen oder intermittierenden lokalen (regionsinternen, nahe gelegenen) Speicherproblemen zu schützen. Je nach Konfiguration kann Cloudcache auch Teil eines BCDR-Plans (Business-Continuity or Disaster-Recovery) sein, wenn Remotespeicheranbieter in verschiedenen Regionen genutzt werden. Cloud-Cache stellt eine Leistungs- und Speicheranforderung an die virtuelle Maschine, denn sie muss zusätzlichen E/A-Vorgänge und den vom lokalen Cache benötigten Speicherplatz bewältigen.

Überlegungen zu Cloudcache:

• Cloud Cache verwendet Speicheranbieter basierend auf der Reihenfolge der Einträge in CCDLocations.
• Speicheranbieter sollten in der Reihenfolge ihrer Nähe und dann der Präferenz aufgelistet werden.
• Nur ein (1) Anbieter wird verwendet, wenn Daten vom Speicheranbieter hydriert werden.
• Die Daten werden in alle Speicheranbieter geschrieben, unabhängig davon, welcher Anbieter während der Hydrierung verwendet wird.
• Die Leistung (Latenz, Auslastung, Engpässe) eines Speicheranbieters wirkt sich auf seinen Synchronisationsstatus mit der lokalen Kopie aus.
• Sind ein (1) oder mehrere Anbieter bei Aktualisierungen aus dem lokalen Cache im Rückstand, könnte dies ein Indikator für einen leistungsschwachen Speicheranbieter sein.
• Die Befehlsergebnisse Ping oder Test-NetConnection sind nicht dasselbe wie transaktionale E/A. Sie sindschlechte Indikatoren dafür, wie ein Speicheranbieter arbeiten wird oder kann.

^{Abbildung 1: Detailliertes Diagramm der Cloudcache-Komponenten}

Cloudcache-Komponenten

Lokaler Cache

Cloud Cache kann einen Benutzer von Konnektivitätsproblemen mit den entfernten Speicheranbietern isolieren, da der für das Benutzerprofil verwendete Container lokal auf der virtuellen Maschine erstellt und gespeichert wird (lokaler Cache). Während einer ersten Anmeldung erstellt FSLogix den Container für den Benutzer in C:\ProgramData\FSLogix\Cache und stellt den Container auf der virtuellen Maschine bereit. Im nächsten Schritt richtet FSLogix alle erforderlichen Umleitungen für das Profil des Benutzers ein. Anschließend erstellt der Benutzerprofildienst das Profil des Benutzers im lokalen Cache. Alle Daten, die in das Profil des Benutzers geschrieben wurden, werden vorübergehend als Cacheobjekte auf Blockebene im selben Verzeichnis gespeichert. Diese Cacheobjekte auf Blockebene werden dann an den lokalen Cache übertragen. Bevor die Cacheobjekte auf Blockebene erstellt werden, werden die Schreibvorgänge im Benutzerprofil im Speicher über eine Proxy-Datei verarbeitet.

Bei einer zweiten^- oder ^n-ten Anmeldung versucht FSLogix, alle früheren lokalen Cache-VHDs, die auf der virtuellen Maschine gespeichert sind, zu finden und bereitzustellen. Die Suche nach einem lokalen Cache ist die Standardkonfigurationseinstellung. Sie ist nicht immer erwünscht, da sie zu Ereignissen mit geringem Speicherplatz führen kann. Schauen Sie auf der Referenzseite für Cloudcache-Einstellungen nach weiteren Einstellungen.

^{Abbildung 2: Cloudcache – lokaler Cache}

Remotespeicheranbieter (hydrieren, leeren, klonen)

Cloudcache verwendet das Benutzerprofil während der Benutzersitzung aus dem lokalen Cache und muss mit einem oder mehreren Remotespeicheranbietern konfiguriert werden, wie in CCDLocations angegeben. Die Remotespeicheranbieter speichern Kopien des lokalen Cache und werden während der aktuellen Sitzung und für nachfolgende Anmeldungen verwendet. Wenn alle Anbieter während der Sitzung des Benutzers nicht funktionsfähig sind, arbeitet der lokale Cache weiter und wächst¹, bis einer oder mehrere Anbieter wieder in einenfunktionsfähigen Zustand zurückkehren.

^{1 Der lokale Cache wächst nur bis zur maximalen Größe des Containers, wie in der Einstellung SizeInMBs} angegeben.

Hydrieren

Wenn der lokale Cache die vom Dateisystem angeforderten Daten nicht enthält, hydriert (liest und kopiert) Cloudcache die Daten von einem der entfernten Speicheranbieter in den lokalen Cache. Dieser Vorgang ist auch Teil des Anmeldeprozesses beim Auffüllen des lokalen Caches für das Benutzerprofil.

Leerung

Die Leerung erfolgt in der Regel auf drei Arten.

1. Bei einem asynchronen Vorgang (lazy) leert Cloudcache die Änderungen von allen Speicheranbietern gleichzeitig, da jeder Anbieter in seinem eigenen Thread geleert wird. FSLogix drosselt diesen Vorgang nicht und nutzt so viel Durchsatz wie das System zulässt.
2. Wenn während der Abmeldung ein oder mehrere Anbieter nicht alle Aktualisierungen enthalten, wird die Abmeldung des Benutzers so lange verzögert², bis alle Anbieter in der gleichen Sequenz sind.
3. Wenn während der Sitzung eines Benutzers die Verbindung zu einem Speicheranbieter gestört ist, stellt FSLogix alle Änderungen in eine Warteschlange und überträgt sie an die Anbieter, sobald diese wieder in einem funktionsfähigen Zustand sind.

^{2 Die Abmeldung eines Benutzers wird je nach Konfiguration von Cloudcache mit dem HealthyProvidersRequiredForUnregister Wert} verzögert.

Klon

Ein vollständiger VHD(x)-Klon wird ausgeführt, wenn Cloudcache bei der Anmeldung feststellt, dass sich ein Speicheranbieter nicht in der gleichen Reihenfolge befindet. Während dieses Vorgangs werden alle ausstehenden Schreibvorgänge im lokalen Cache gespeichert, bis sich alle Speicheranbieter in derselben Reihenfolgen sind. Nach Abschluss beginnt der Flush-Vorgang mit dem Senden neuer Daten an die Speicheranbieter.

Indizierung (zeitgesteuerter Schreibcache)

Cloudcaches verwenden die Indizierung im lokalen Cache. Zeitlich begrenzte Schreibcaches sind Dateien, die Schreibvorgänge darstellen, die noch nicht in den lokalen Cache übertragen wurden. Diese Dateien werden mit einer numerischen Erweiterung notiert. Sobald der Index in den lokalen Cache übertragen wurde, wird er in ein Cacheobjekt umgewandelt.

Indexdateien müssen immer dann berücksichtigt werden, wenn eine virtuelle Maschine unerwartet heruntergefahren oder neu gestartet wird. Diese Dateien stellen Daten dar, die noch nicht in den lokalen Cache übertragen wurden, was zu Datenverlusten oder schlimmstenfalls zu einem beschädigten Container führen kann. In nicht-persistenten Umgebungen oder Umgebungen mit mehreren Sitzungen stellt der Benutzer in der Regel keine Verbindung mehr zu derselben virtuellen Maschine her, sobald sich diese von dem unerwarteten Ereignis erholt hat. In diesen Fällen können die Daten, die nicht ordnungsgemäß an die Speicheranbieter übertragen wurden, verloren gehen und zu einem Problem mit dem Profilcontainer des Benutzers führen.

Proxydatei

Cloud Cache verwendet das Konzept einer Proxy-Datei, die als Profile_%username%.vhd dargestellt wird, obwohl es sich nicht um eine echte VHD-Datei handelt. Die Proxydatei dient als Mittel zum Sammeln und Verarbeiten aller E/A-Schreibvorgänge, die für den lokalen Cache bestimmt sind. Die E/A-Schreibvorgänge werden im Arbeitsspeicher gepuffert und über die Proxydatei nachverfolgt, bevor sie als Cacheobjekte auf Blockebene in das Cacheverzeichnis geschrieben werden. Während die Proxydatei dieselbe Größe wie die lokale Cachedatei hat, ist die tatsächliche Größe auf dem Datenträger null, da keine Daten in diese Datei geschrieben werden.

^{Abbildung 3: Cloudcache-Proxydatei}

Zusätzliche Dateien

Cloudcache verwendet zwei (2) zusätzliche Dateien, um die Kontrolle und die Reihenfolge des lokalen Cache zu gewährleisten.

Sperrdatei

Die Sperrdatei ist, wie der Name schon sagt, eine Datei, mit der festgestellt wird, welche virtuelle Maschine eine E/A-Sperre für den Container hat. Cloudcache bestimmt anhand dieser Informationen die Eigentümerschaft des Containers für einen bestimmten Anbieter. Der Mechanismus der Sperrdatei ist wichtig, wenn Cloudcache mit dem Profiltyp „3“ (mehrere oder gleichzeitige Sitzungen) verwendet wird.

Metadatei

Die Metadatei ist eine Mehrzweckdatei, in der wir den Zustand des Containers verfolgen. Innerhalb der Metadatei verwendet Cloudcache ein Sequenznummerierungssystem, um festzustellen, welcher Anbieter über die neuesten Daten verfügt.

Speicheranbieter

FSLogix ist kein Speicheranbieter, sondern verlässt sich auf die zugrunde liegende Architektur des/der Speicheranbieter(s). Weitere Informationen zu den von FSLogix unterstützten Speicheranbietern finden Sie unter Containerspeicheroptionen.

Nächste Schritte