Irgendwie war es notwendig, Rosplatform (R-Virtualization und R-Storage) in das Hardwarespeichersystem ( 3PAR ) zu integrieren, was in verschiedenen Szenarien sehr nützlich sein kann.
Synergiekonfiguration
Zuvor wurde diese Art der Integration an Blades (Blade CH121 v5) eines Huawei Center Blade mit Dorado 5000 v3-Speichersystem getestet, wobei sich SDS (softwaredefinierter Speicher) des P-Speichers der Rosplatforma auf dem Speichersystem aufgrund des gesamten Flashs recht gut zeigte, jedoch mit Synergy , falls verfügbar JBOD-Festplatten aus dem D3940-Modul, alles ist viel interessanter und flexibler.
3 Server Blades (Synergy 480 Gen10 (871940-B21)):
- Jeder verfügt über zwei Intel® Xeon® Platinum 8270-CPUs.
- Vernetzen Sie zwei Ports mit 20 Gbit / s.
- RAM 256 GB.
- In den Blades befinden sich keine Festplatten.
- Im Synergy 2HDD-Festplattenmodul 900 GB in RAID1 für jedes Betriebssystem / Hypervisor und 3SSD HPE VK0960GFDKK 960 GB für die Metadaten + Cache-Rolle (jeweils für einen Server) sowie 9HDD EG0900JFCKB für 900 GB.
Das Betriebssystem wurde über einen Kanal über einen RAID-Controller von einem Synergy-Festplattenmodul geladen.
Lokales Sicherheitsdatenblatt, das über einen JBOD-Kanal vom Synergy-Festplattenmodul bereitgestellt wird.
3PAR-Konfiguration
Synergy ist mit 3PAR (FC16 Gbit / s) verbunden:
Eine LUN (eins zu viele) RAID6 von SSD mit 200 GB Kapazität. 9 LUN RAID6 von der Festplatte mit einer Kapazität von jeweils 150 GB (drei LUNs pro Blade).
Zahl: 1 Prüfstandsdiagramm.
Beschreibung der Szenarien
Wir haben verschiedene Optionen für die Integration mit 3PAR getestet, die auch gleichzeitig in einer gemischten Konfiguration verwendet werden können.
Szenario mit SDS-Bereitstellung von Rosplatform auf separaten LUNs von jeweils 150 GB von 3PAR:
Abb. 2 Szenario mit SDS-Bereitstellung von Rosplatform auf separaten LUNs
mit Speichersystemen für jeden der drei Knoten wurde FC mit 3 LUNs von 150 GB vorgestellt.
Auf Speichersystemen wurden sie in RAID6 von Festplatten konfiguriert. In Abb. 2 zeigt schematisch 10 GB und Switch, aber die Implementierung erfolgte auf der Ebene des Synergy-Switch mit 20 GB-Ports, wobei eine Schnittstelle für die Verwaltung und Virtualisierung und die andere für den SDS-Speicher vorgesehen ist.
Dieses Szenario wurde getestet, um sicherzustellen, dass die folgenden Optionen funktionieren:
- SDS Rosplatform funktioniert auf 3PAR.
- Stärkung des SDS von Rosplatforma über 3PAR durch Hinzufügen eines lokalen SSD-Cache.
- Durch Erstellen einer kleinen SDS-Rosplatform zum Speichern von VM-Konfigurationsdateien, in der die VMs selbst auf LUN 3PAR erstellt werden.
- Testen von SDS Rosplatforma auf 3PAR und Definition eines etwas langsameren Strichs als eines Strichs lokaler Festplatten.
2) Ein Szenario mit dem Erstellen einer VM auf einer LUN aus 3PAR:
Abb. 3 Szenario mit der Erstellung einer VM auf einer LUN aus 3PAR.
LUN 200 GB RAID6 von SSD für VM wurde mit Speicher vorgestellt. Die LUN-Konfiguration ist eins zu viele.
Dieses Szenario wurde getestet, um die Funktionen zu überprüfen:
- Von 3PAR direkt an VM LUN anschließen.
- Verwenden der angeschlossenen VM-LUN als primäre Festplatte ohne Verwendung von qcow2.
- Verwenden mehrerer VMs mit derselben 200-GB-LUN zur späteren Installation des Gastcluster-Dateisystems.
- Migration einer VM mit einer 200-GB-LUN von 3PAR und einem Knotenabsturz beim Neustart dieser VM auf den verbleibenden Knoten.
- Verwenden von SDS von 3PAR als Speicher für VM-Konfigurationsdateien und des Gastbetriebssystems mit direkter Bereitstellung auf LUNs von 3PAR.
- Verwenden von SDS auf den lokalen Festplatten des Synergy-Moduls als Speicher für VM-Konfigurationsdateien und des Gastbetriebssystems mit Bereitstellung auf LUN 200 GB von 3PAR direkt.
Beschreibung der Einstellungen
Für alle Szenarien auf jedem Knoten wurden vor der üblichen Bereitstellung des Clusters dieselben Einstellungen vorgenommen, die unmittelbar nach der Installation von drei Knoten aus den Rosplatform-Images vorgenommen wurden. Kurze Anweisungen zum Installieren und Konfigurieren des Clusters selbst finden Sie im vorherigen Artikel .
1. Aktivieren des Multipath-Dienstes zum automatischen Laden:
#chkconfig multipathd on2. Aktivieren des Ladens von Modulen:
#modprobe dm-multipath
#modprobe dm-round-robin3. Kopieren der Konfigurationsvorlage in den Ordner für die Arbeitskonfiguration:
#cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/4.Überprüfen Sie das Einschlussmuster unter den folgenden Parametern:
defaults {
user_friendly_names yes
find_multipaths yes
}5. Hinzufügen eines Alias für eine freigegebene Festplatte für eine VM:
multipaths {
multipath {
# wwid 3600508b4000156d700012000000b0000
# alias yellow
# path_grouping_policy multibus
# path_selector "round-robin 0"
# failback manual
# rr_weight priorities
# no_path_retry 5
# }
multipath {
wwid 360002ac0000000000000000f000049f4
alias test3par
}
}
6.Überprüfen Sie den Start des Dienstes:
#systemctl start multipathd7. Überprüfen des Dienstes und Anzeigen von Geräten mit mpath:
#multipath –ll8. Obligatorischer Neustart:
#reboot9. Überprüfen des Dienstes und Anzeigen von Geräten mit mpath:
#multipath –llAls nächstes wurden die Standardclustereinstellungen durchgeführt.
Zahl: 4 Web-Benutzeroberfläche, bevor Sie den Mehrwegedienst aktivieren.
Zahl: 5 Nach dem Aktivieren des Mehrwegedienstes wurden dm-Geräte angezeigt.
Screenshot nach dem Erstellen des Rosplatforma-Clusters, in dem 200 GB LUN für VMs speziell eine nicht zugewiesene Rolle haben:
Abb. 6 Screenshot nach dem Erstellen des Rosplatforma-Clusters.
Der Screenshot zeigt zwei Tier0 und Tier1, wobei Tier0 das lokale Sicherheitsdatenblatt und Tier1 das Sicherheitsdatenblatt über 3PAR ist:
Abb. 7 Lokales Sicherheitsdatenblatt und mehr als 3PAR.
Als Nächstes wurde eine VM ohne lokale Festplatte mit einer 200-GB-LUN von 3PAR erstellt:
#prlctl set testVM --device-add hdd --device /dev/mapper/ test3parDie VM wurde mit den folgenden Parametern erstellt:
- Typ - CentOS Linux
- vCPU - 4
- RAM - 8
- Gastbetriebssystem - Centos 7 (1908)
Migrationstests
Migrationstests wurden mit oder ohne installierte Gasttools durchgeführt.
In allen Fällen wurde die VM erfolgreich migriert, ohne anzuhalten.
Zahl: 8 Ergebnis und Zeitpunkt der VM-Migration.
Test1 - eine normale VM mit denselben Parametern nur mit einem lokalen Festplatten-Image QCOW2 64 GB und Live-Migration einer Test10-VM mit einer 200 GB LUN von 3PAR.
Die Migrationszeit ist kürzer, da während des Vorgangs kein Schritt zum Umschalten auf eine Kopie des VM-Disk-Images auf einem anderen Knoten erfolgt. Nur die Konfigurationsdatei wird mit einem Link zur LUN 200 GB kopiert, der von jedem Knoten des Clusters aus sichtbar ist.
Zahl: 9 Ping-Ergebnisse.
Während der Live-Migration wurde mit einer 200-GB-LUN von 3PAR ein Ping an die VM gesendet.
Der Verlust von nur einem Paket wurde aufgezeichnet. Genau das Gleiche passiert mit einer regulären VM auf SDS, aber die VM bleibt über das Netzwerk verfügbar und funktioniert weiterhin.
Not-Aus-Tests
Wenn der Server ausgeschaltet wurde, auf dem sich eine VM mit einer 200-GB-LUN von 3PAR befand, und nachdem der HA-Dienst den fehlenden Knoten erkannt hatte, wurde die zu testende VM erfolgreich auf einem anderen Knoten neu gestartet, der gemäß dem Standard-DRS-Algorithmus Round Robin ausgewählt wurde, und funktionierte weiter. Während des Pings gingen 7 Pakete verloren. Beim Umschalten wurde nur die VM-Konfigurationsdatei gestartet, und auf das Gastbetriebssystem war immer über den angehängten Pfad zur LUN zugegriffen.
Wir haben auch das Erstellen einer Sicherung getestet, bei der die VM-Konfigurationsdatei erfolgreich gesichert wurde und beim Wiederherstellen von dieser VM-Kopie erfolgreich gestartet wurde.
Tests des sequentiellen Schreibens auf VM mit 200 GB LUN von 3PAR, die die Leistung dieser LUN von 3PAR zeigten, wobei Rosplatforma keine Zwischenschicht war, und der Test zeigt den Betrieb des Gastbetriebssystems und der 3PAR-Speichersysteme.
Verwendete fio-Parameter in VM mit 200 GB LUN von 3PAR:
[seqwrite]
rw=write
size=4g
numjobs=4
bs=1m
ioengine=libaio
iodepth=32
time_based
#runtime=60
direct=1
filename_format=__testfile'$jobnum'
thread
directory=/sdb/
Tests mit einem Cluster-Dateisystem im Gastbetriebssystem
Zahl: 10 Clustered-Dateisystem im Gastbetriebssystem.
Ein Szenario mit einer 200-GB-LUN, die mit zwei VMs verbunden ist, wurde erfolgreich getestet, auf dem das GFS2-Cluster-Dateisystem mithilfe des Gastbetriebssystems in der VM installiert wird. Während des Tests wurde eine der VMs oder der Host ausgeschaltet. Danach arbeitete die andere VM weiter mit dieser LUN und schrieb / las Dateien von dort. Unten sehen Sie einen Screenshot mit den GFS2-Einstellungen in der VM. Die Ausgaben der Schrittmacherbefehle werden ebenfalls angezeigt:
Weitere Sicherheitsdatenblätter der Rosplatforma oben auf der LUN:
Abb. 11 Konfigurieren mit SDS Rosplatform, das auf einer 3PAR-LUN bereitgestellt wird.
Das gleiche Szenario wurde erfolgreich mit einer 200-GB-LUN getestet, die mit zwei VMs verbunden war, auf denen mithilfe des Gastbetriebssystems ein Cluster-Dateisystem in der VM installiert war. Als Datenspeicherort wurde jedoch der auf der LUN von 3PAR erstellte Datenspeicher von SDS Rosplatforma verwendet. Während des Tests wurde eine der VMs oder der Host ausgeschaltet. Danach arbeitete die andere VM weiter mit dieser LUN und schrieb / las Dateien von dort.
Zahl: 12 Testen Sie mit dem Hinzufügen einer SSD die Rolle des Cache aus dem Synergy-Festplattenmodul.
Das gleiche Szenario wurde erfolgreich mit einer 200-GB-LUN getestet, die mit zwei VMs verbunden war, auf denen ein Cluster-Dateisystem unter Verwendung des Gastbetriebssystems in der VM installiert war. Der auf der LUN von 3PAR erstellte Datenspeicher von SDS Rosplatforma wurde jedoch als VM-Speicherort verwendet. Außerdem wurde die Leistung dieses Datenspeichers durch Hinzufügen einer SSD als Cache aus dem Synergy-Festplattenmodul verbessert. Während des Tests wurde eine der VMs oder der Host ausgeschaltet. Danach arbeitete die andere VM weiter mit dieser LUN und schrieb / las Dateien von dort.
Cluster-Dateisystemtests auf Rosplatform-Knoten
Zahl: 13 Der Test mit VM-Konfigurationsdateien auf SDS Rosplatforma von 3PAR LUN 200 GB wurde vorgestellt.
Es wurde ein Szenario mit gemeinsam genutztem Speicher von 3PAR für VM-Disk-Images auf einem Cluster-Dateisystem getestet, das auf den Rosplatforma-Knoten installiert war, und die Konfigurationsdateien dieser VMs befanden sich auf dem Sicherheitsdatenblatt der Rosplatforma. Während des Tests wurde einer der Hosts deaktiviert. Danach mussten die VMs aufgrund der Arbeit von zwei anderen Hosts gemäß Replik 3 auf dem SDS-Cluster für VM-Konfigurationsdateien und 3 Protokollen des Cluster-Dateisystems für VM-Disk-Images mit ihren Festplattenabbildern weiterarbeiten.
Zahl: 14 SDS wird von 3PAR auf LUN gebracht.
Es wurde ein Szenario mit gemeinsam genutztem Speicher von 3PAR für VM-Disk-Images auf einem Cluster-Dateisystem getestet, das auf den Rosplatforma-Knoten installiert war, und die Konfigurationsdateien dieser VMs befanden sich auf dem Sicherheitsdatenblatt von Rosplatforma, wo SDS von 3PAR auf die LUN angehoben wurde. Während des Tests wurde einer der Hosts deaktiviert. Danach mussten die VMs aufgrund der Arbeit von zwei anderen Hosts gemäß Replik 3 auf dem SDS-Cluster für VM-Konfigurationsdateien und 3 Protokollen des Cluster-Dateisystems für VM-Disk-Images mit ihren Festplattenabbildern weiterarbeiten.
Zahl: 15 SDS Tier0 auf LUNs von 3PAR, SDS Tier1 auf Festplatten vom Synergy-Modul.
Es wurde ein Szenario mit gemeinsam genutztem Speicher von 3PAR für VM-Disk-Images auf einem Cluster-Dateisystem getestet, das auf den Rosplatforma-Knoten installiert war, und die Konfigurationsdateien dieser VMs befanden sich auf SDS Rosplatforma, wo SDS Tier0 auf der LUN von 3PAR und die zweite SDS-Schicht 1 auf Disketten des Moduls ausgelöst wurde Synergie. Während des Tests wurde einer der Hosts deaktiviert. Danach mussten die VMs aufgrund der Arbeit von zwei anderen Hosts gemäß Replik 3 auf dem SDS-Cluster für VM-Konfigurationsdateien und 3 Protokollen des Cluster-Dateisystems für VM-Disk-Images mit ihren Disk-Images arbeiten. Es gab jedoch Probleme mit der Arbeit von kvm-qemu mit GFS2. Nach einer langen Untersuchung schlug der Sperrmanager von GFS2 fehl und die Rosplatforma konnte die VM aus diesem Grund nicht auf einem anderen Host des Clusters starten. Die Frage bleibt offen. Gleiches gilt für die Optionen in Abbildung 13 und 14.Ein mögliches Problem bei diesem Szenario liegt in den Besonderheiten von kvm-qemu, das mit qcow2 und dem Rohbild arbeitet, wobei Schreibvorgänge synchron ausgeführt werden und der Sperrmanager von GFS2 für solche Vorgänge beschränkt ist.
Fazit
Die Optionen von SDS zu LUN von 3PAR und LUN-Präsentation von 3PAR funktionieren recht gut und können für die Arbeit in der Infrastruktur verwendet werden, haben aber natürlich einige Nachteile.
Im Fall von Sicherheitsdatenblättern auf den Monden ist die Leistung beispielsweise immer geringfügig niedriger als bei Sicherheitsdatenblättern auf lokalen Festplatten. Dies kann durch lokale SSDs mit der Rolle des Caches verbessert werden, reguläre Sicherheitsdatenblätter sind jedoch immer überwiegend schneller. Optional kann SDS on Storage in einem separaten Schießstand konfiguriert werden. Ein weiteres nicht unwichtiges Minus ist die Fehlertoleranz. Auf SDS ist jeder Knoten ein Controller, bei dem mindestens ein Cluster mit drei Knoten beginnt. Bei Speichersystemen gibt es immer zwei Controller pro Rack. Für SDS ist dies ein einzelner Fehlerpunkt. Trotz dieser Nachteile treten solche Szenarien während eines schrittweisen Übergangs vom externen Speicher zum SDS oder bei der Entsorgung eines vorhandenen Speichersystems auf. Darüber hinaus gibt es Funktionen des Speichersystems selbst, wie Deduplizierung, Kompression, die aufgrund der Besonderheiten des architektonischen AnsatzRosplatforma ist in SDS nicht vorhanden, 3PAR jedoch. Dank der oben beschriebenen Szenarien können sie auf Speicherebene verwendet werden.
Relevant sind auch Szenarien mit LUN-Präsentation für VMs für Gastsysteme mit eigenem Clustersystem. Bei der Präsentation von LUNs für jede VM separat treten Nachteile wie die mangelnde Automatisierung während des Lebenszyklus einer großen Anzahl von VMs auf, die möglicherweise auf das Cluster-Dateisystem auf den Rosplatform-Knoten zurückzuführen sind. In diesem Fall ist jedoch GFS2 mit kvm-qemu fehlgeschlagen Wenn Sie es für andere Dateien verwenden, funktioniert alles auch bei Notfalltests auf der Rosplatform. Sobald jedoch VM-Images dort abgelegt werden, schlägt der GFS2-Sperrmanager bei Notfalltests fehl. Vielleicht wird dieses Problem gelöst.
Die obigen Szenarien für die Verwendung von Multipath können zum Verknüpfen von Bandbibliotheken hilfreich sein. Rosplatform hat eine integrierte Backup - System (SRK) , die Kopien auf dem P-Storage - Cluster - Ordner oder einen lokalen Ordner schreiben kann, kann aber nicht die Arbeit mit Bandgeräten , bis Sie ein Skript selbst oder für diese Zwecke schreiben können Sie externe SRK, wie verwenden rubackup , die Neben der Arbeit mit Band hilft es, Kopien von VMs mit angeschlossenen LUNs zu erstellen, was bei der Integration in Speichersysteme wichtig ist.