Cloud Management – Teil 1: blkdeviotune/migrate-setmaxdowntime

This entry is part 1 of 2 in the series Cloud Management

Viele von euch haben bestimmt schon einmal von OpenNebula oder OpenStack gehört, beiden Plattformen verwenden standardmäßig libvirtd als Hypervisor, da jedoch die darunter liegende Hardware mit unter stark beansprucht werden wird, vor allem im Cloud Bereich, wo mehrerer KVM Instanzen auf einem Virt Host um CPU/Speicher/IO Resourcen konkurrieren, ist es gelegentlich notwendig die einen oder andere Instanz zu bändigen bzw. in die Schranken zu weisen.

Unsere Cloud läuft derzeit noch mit OpenNebula, wir selbst sind sehr zufrieden mit dem Stack, da sich dieser leicht Verwalten lässt und sich auch gut mit unserem Ceph als Backend verträgt, natürlich verwenden wir in unserem Cloud Stack noch andere Tools, diese sind aber nicht Gegenstand dieses Artikels, mehr dazu in späteren Teilen der Serie.

Libvirtd kann mit CLI Tools wie virsh gesteuert werden, auch besteht die Möglichkeit libvirtd über die entsprechende libvirt C API oder durch seine ScriptLanguage Bindings für ruby/python/perl/javascript/etc… anzusprechen bzw. anzusteuern zu können.

So beispielsweise unterstützt man OpenNebula wenn die Migration einer KVM Instanz von Virt Host A zu Virt Host B aufgrund von Last auf der Instanz selbst partout nicht klappen will…

root@virt1: ~ $ virsh migrate-setmaxdowntime --downtime 1800 one-8366
error: Requested operation is not valid: domain is not being migrated (dieser Fehler kommt nur wenn sich die Instanz nich im Status Migrate befindet, ist hier also nur exemplarisch mit abgebildet)

…oder wenn die Instanz AMOK läuft und somit andere Instanzen zu stark beeinträchtigt…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 400
read_iops_sec  : 0
write_iops_sec : 0

…dann limitieren wir diese einfach ein bisschen…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live 62914560 0 0 200 0 0

…und vergewissern uns nochmal ob unsere neuen IOPs Limits übernommen wurden…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 200
read_iops_sec  : 0
write_iops_sec : 0

…ich denke, damit sollte klar sein worauf wir hier abzielen möchten.

In folgenden Teilen dieser Serie werden wir euch noch mehr Tips & Tricks mit auf den Weg geben, die helfen sollen eure Cloud zu bändigen bzw. aufkommende Probleme anzugehen, also bleibt gespannt. 😉

Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.

Ceph – CRUSH rules über die CLI

Über die CRUSH Map ist es möglich zu beinflussen wie Ceph seine Objekte repliziert und verteilt. Die Standard CRUSH Map verteilt die Daten, sodass jeweils nur eine Kopie per Host abgelegt wird.

Wenn nun ein Ceph Cluster andere Prioritäten voraussieht, bspw. Hosts sich ein Netz, oder ein Rack mit gleicher Stromversorgung teilen, oder im gleichen Rechenzentrum stehen, sprich die Failure Domains anders aufgeteilt sind, ist es möglich diese Abhängigkeiten in der CRUSH Map zu berücksichtigen.

Beispielsweise wollen wir unseren Cluster mit einer Replikation von 3 auf eine 2er Replikation zurücksetzen. Da sich jedoch 2 Hosts einen Rack teilen, wollen wir das auch in unserer CRUSH Map abbilden und das über die CLI:

Ausgangslage:

[root@box12 ~]# ceph osd tree
ID WEIGHT  TYPE NAME                       UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-6 0.33110 datacenter dc03                                                   
-1 0.33110     root datacenter01                                             
-5 0.33110         datacenter datacenter02                                   
-4 0.11037             host box14                                            
 6 0.03679                 osd.6                up  1.00000          1.00000 
 7 0.03679                 osd.7                up  1.00000          1.00000 
 8 0.03679                 osd.8                up  1.00000          1.00000 
-3 0.11037             host box13                                            
 3 0.03679                 osd.3                up  1.00000          1.00000 
 4 0.03679                 osd.4                up  1.00000          1.00000 
 5 0.03679                 osd.5                up  1.00000          1.00000 
-2 0.11037             host box12                                            
 0 0.03679                 osd.0                up  1.00000          1.00000 
 1 0.03679                 osd.1                up  1.00000          1.00000 
 2 0.03679                 osd.2                up  1.00000          1.00000 

Wir erstellen die beiden Racks:

[root@box12 ~]# ceph osd crush add-bucket rack1 rack
added bucket rack1 type rack to crush map
[root@box12 ~]# ceph osd crush add-bucket rack2 rack
added bucket rack2 type rack to crush map

Die Racks wurden erstellt:

[root@box12 ~]# ceph osd tree
ID  WEIGHT  TYPE NAME                       UP/DOWN REWEIGHT PRIMARY-AFFINITY                                                      
 -8       0 rack rack2                                                        
 -7       0 rack rack1                                                        
 -6 0.33110 datacenter dc03                                                   
 -1 0.33110     root datacenter01                                             
 -5 0.33110         datacenter datacenter02                                   
 -4 0.11037             host box14                                            
  6 0.03679                 osd.6                up  1.00000          1.00000 
  7 0.03679                 osd.7                up  1.00000          1.00000 
  8 0.03679                 osd.8                up  1.00000          1.00000 
 -3 0.11037             host box13                                            
  3 0.03679                 osd.3                up  1.00000          1.00000 
  4 0.03679                 osd.4                up  1.00000          1.00000 
  5 0.03679                 osd.5                up  1.00000          1.00000 
 -2 0.11037             host box12                                            
  0 0.03679                 osd.0                up  1.00000          1.00000 
  1 0.03679                 osd.1                up  1.00000          1.00000 
  2 0.03679                 osd.2                up  1.00000          1.00000 

Nun verschieben wir die Hosts 14 & 13 nach Rack1 und 12 nach Rack2:

[root@box12 ~]# ceph osd crush move box14 rack=rack1
moved item id -4 name 'box14' to location {rack=rack1} in crush map
[root@box12 ~]# ceph osd crush move box13 rack=rack1
moved item id -3 name 'box13' to location {rack=rack1} in crush map
[root@box12 ~]# ceph osd crush move box12 rack=rack2
moved item id -2 name 'box12' to location {rack=rack2} in crush map

Und die Racks in das Rechenzentrum(datacenter02):

[root@box12 ~]# ceph osd crush move  rack1 datacenter=datacenter02
moved item id -7 name 'rack1' to location {datacenter=datacenter02} in crush map
[root@box12 ~]# ceph osd crush move  rack2 datacenter=datacenter02
moved item id -8 name 'rack2' to location {datacenter=datacenter02} in crush map

Das ganze sieht dann so aus:

[root@box12 ~]# ceph osd tree
ID  WEIGHT  TYPE NAME                       UP/DOWN REWEIGHT PRIMARY-AFFINITY                                                       
 -6 0.33110 datacenter dc03                                                   
 -1 0.33110     root datacenter01                                             
 -5 0.33110         datacenter datacenter02                                   
 -7 0.22073             rack rack1                                            
 -4 0.11037                 host box14                                        
  6 0.03679                     osd.6            up  1.00000          1.00000 
  7 0.03679                     osd.7            up  1.00000          1.00000 
  8 0.03679                     osd.8            up  1.00000          1.00000 
 -3 0.11037                 host box13                                        
  3 0.03679                     osd.3            up  1.00000          1.00000 
  4 0.03679                     osd.4            up  1.00000          1.00000 
  5 0.03679                     osd.5            up  1.00000          1.00000 
 -8 0.11037             rack rack2                                            
 -2 0.11037                 host box12                                        
  0 0.03679                     osd.0            up  1.00000          1.00000 
  1 0.03679                     osd.1            up  1.00000          1.00000 
  2 0.03679                     osd.2            up  1.00000          1.00000 

Im nächsten Schritt lassen wir uns automatisch eine CRUSH Rule erstellen und ausgeben:

[root@box12 ~]# ceph osd crush rule create-simple ceph-blog datacenter01 rack

[root@box12 ~]# ceph osd crush rule ls
[
    "ceph-blog",
    "test03"
]

‘datacenter01 rack’ sagt hier, dass beim datacenter01 begonnen werden soll und alle Kindknoten(leaf) vom Typ rack ausgewählt werden sollen.

Wir lassen uns die CRUSH Rule ausgeben:

[root@box12 ~]# ceph osd crush rule dump ceph-blog
{
    "rule_id": 0,
    "rule_name": "ceph-blog",
    "ruleset": 0,
    "type": 1,
    "min_size": 1,
    "max_size": 10,
    "steps": [
        {
            "op": "take",
            "item": -1,
            "item_name": "datacenter01"
        },
        {
            "op": "chooseleaf_firstn",
            "num": 0,
            "type": "rack"
        },
        {
            "op": "emit"
        }
    ]
}

Sieht gut aus.

Der Pool rbd soll die Rule anwenden:

[root@box12 ~]# ceph osd pool set rbd crush_ruleset 0
set pool 0 crush_ruleset to 0

Funktioniert’s?

[root@box12 ~]# ceph osd map rbd test
osdmap e421 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,0], p4) acting ([4,0,6], p4)

Das test Objekt wird weiterhin über die 3 Hosts verteilt.

Wir setzen die Replikation von 3 auf 2:

[root@box12 ~]# ceph osd pool get rbd size
size: 3
[root@box12 ~]# ceph osd pool set rbd size 2
set pool 0 size to 2

Ceph verteilt die Objekte. Nur Geduld:

[root@box12 ~]# ceph -s
    cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3
     health HEALTH_ERR
            60 pgs are stuck inactive for more than 300 seconds
            60 pgs peering
            60 pgs stuck inactive
            27 pgs stuck unclean
            recovery 3/45 objects degraded (6.667%)
            recovery 3/45 objects misplaced (6.667%)
     monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0}
            election epoch 82, quorum 0,1,2 box12,box13,box14
     osdmap e424: 9 osds: 9 up, 9 in
            flags sortbitwise
      pgmap v150494: 270 pgs, 1 pools, 10942 kB data, 21 objects
            150 GB used, 189 GB / 339 GB avail
            3/45 objects degraded (6.667%)
            3/45 objects misplaced (6.667%)
                 183 active+clean
                  35 peering
                  27 active+remapped
                  25 remapped+peering

Nach ‘ner Weile ist der Cluster wieder im OK Status:

[root@box12 ~]# ceph -s
    cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3
     health HEALTH_OK
     monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0}
            election epoch 82, quorum 0,1,2 box12,box13,box14
     osdmap e424: 9 osds: 9 up, 9 in
            flags sortbitwise
      pgmap v150497: 270 pgs, 1 pools, 10942 kB data, 21 objects
            149 GB used, 189 GB / 339 GB avail
                 270 active+clean

Gucken wir uns nochmal die Verteilung der Objekte an:

[root@box12 ~]# ceph osd map rbd test
osdmap e424 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,0], p4) acting ([4,0], p4)

Sieht besser aus.

Vielleicht nur ein Zufall. Wir stoppen OSD.0 auf box12. Die Daten sollten weiterhin jeweils zwischen beiden Racks repliziert werden:

[root@box12 ~]# systemctl stop ceph-osd@0
[root@box12 ~]# ceph osd tree
ID  WEIGHT  TYPE NAME                       UP/DOWN REWEIGHT PRIMARY-AFFINITY                                                       
 -6 0.33110 datacenter dc03                                                   
 -1 0.33110     root datacenter01                                             
 -5 0.33110         datacenter datacenter02                                   
 -7 0.22073             rack rack1                                            
 -4 0.11037                 host box14                                        
  6 0.03679                     osd.6            up  1.00000          1.00000 
  7 0.03679                     osd.7            up  1.00000          1.00000 
  8 0.03679                     osd.8            up  1.00000          1.00000 
 -3 0.11037                 host box13                                        
  3 0.03679                     osd.3            up  1.00000          1.00000 
  4 0.03679                     osd.4            up  1.00000          1.00000 
  5 0.03679                     osd.5            up  1.00000          1.00000 
 -8 0.11037             rack rack2                                            
 -2 0.11037                 host box12                                        
  0 0.03679                     osd.0          down        0          1.00000 
  1 0.03679                     osd.1            up  1.00000          1.00000 
  2 0.03679                     osd.2            up  1.00000          1.00000 

Der Cluster verteilt wieder neu… Nur Geduld:

[root@box12 ~]# ceph osd map rbd test
osdmap e426 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4], p4) acting ([4], p4)

[root@box12 ~]# ceph -s
    cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3
     health HEALTH_WARN
            96 pgs degraded
            31 pgs stuck unclean
            96 pgs undersized
            recovery 10/42 objects degraded (23.810%)
            1/9 in osds are down
     monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0}
            election epoch 82, quorum 0,1,2 box12,box13,box14
     osdmap e426: 9 osds: 8 up, 9 in; 96 remapped pgs
            flags sortbitwise,require_jewel_osds
      pgmap v150626: 270 pgs, 1 pools, 10942 kB data, 21 objects
            149 GB used, 189 GB / 339 GB avail
            10/42 objects degraded (23.810%)
                 174 active+clean
                  96 active+undersized+degraded

Nach einer Weile:

[root@box12 ~]# ceph -s
    cluster e4d48d99-6a00-4697-b0c5-4e9b3123e5a3
     health HEALTH_OK
     monmap e4: 3 mons at {box12=192.168.33.22:6789/0,box13=192.168.33.23:6789/0,box14=192.168.33.24:6789/0}
            election epoch 82, quorum 0,1,2 box12,box13,box14
     osdmap e429: 9 osds: 8 up, 8 in
            flags sortbitwise,require_jewel_osds
      pgmap v150925: 270 pgs, 1 pools, 14071 kB data, 22 objects
            132 GB used, 168 GB / 301 GB avail
                 270 active+clean

Wir testen erneut:

[root@box12 ~]# ceph osd map rbd test
osdmap e429 pool 'rbd' (0) object 'test' -> pg 0.40e8aab5 (0.b5) -> up ([4,1], p4) acting ([4,1], p4)

Das Objekt liegt einmal in Rack1 und einmal in Rack2. Passt!

Noch nicht genug? Ihr habt Interesse noch mehr über Ceph zu erfahren? Dann besucht doch unsere Schulung: Ceph Schulung 😉

Weiterführendes: http://www.crss.ucsc.edu/media/papers/weil-sc06.pdf

Deniz Armagan

Autor: Deniz Armagan

Deniz hat in Worms Kommunikationsinformatik studiert und anschließend noch ein Zusatzstudium in IT-Security in Darmstadt draufgesetzt. Als er das Angebot von NETWAYS bekam, hat er sich schweren Herzens entschlossen, sein Studium abzubrechen und ist nach Nürnberg gezogen. Deniz ist ein sehr bescheidener Mensch, er liebt fahrende Züge und startende PCs - also im Grunde funktionierende Sachen - weswegen er in unserem Support-Team auch super aufgehoben ist.

Monthly Snap December > OSMC, Nicolaus poem, Icinga 2.6, Robocop, Clustershell and Foreman-API, Icinga 2, OSDC, Ceph, Linux, Ansible, OMSA

In the beginning of December Dirk gave us a detailed summary of the first, second and third OSMC days, while Julia gave an account of the evening event at the Indabahn.

On the 6th of December, the St. Nicolaus day, we read Julias version of a Nicolaus poem. A couple of days later Gunnar gave us an insight into Icinga 2.6.

Then Markus Frosch introduced the Robocop, and Marius informed us about Clustershell and Foreman-API.

In parts 1 and 2 Lennart wrote about the organisation of Icinga 2 host- and service objects, whereas Julia informed us about the Early Bird phase and the Call for papers for the Open Source Data Center Conference.

Martin wrote about S3 and Swift with the Ceph object, and Alexander about Black Magic for GNU/Linux-Nerds.

At the end of the month Julia reminded us of the Ansible training, and Tim reported on OMSA issues, solutions and xkcd.

Lukas Stegmeier

Autor: Lukas Stegmeier

Lukas hat im September 2016 seine Ausbildung zum Veranstaltungskaufmann bei NETWAYS gestartet. Er freut sich auf eine spannende Ausbildung und ist schon ganz gespannt auf unsere Firmenfeste. Zuhause hebt er den Geräuschpegel durch regelmäßiges Schlagzeugspielen enorm an und sportlich verausgabt sich Lukas seit 12 Jahren intensiv beim Fußball.

S3 und Swift mit dem Ceph Object Gateway (radosgw)

 Object Gateway ist eine Objektspeicher-Schnittstelle, welche Anwendungen eine RESTful HTTP Schnittstelle zum Ceph Object Store zur Verfügung stellt.

Es werden 2 Schnittstellen unterstützt:

  • S3-Kompatibilität: Stellt eine Objektspeicherfunktionalität mit einer Schnittstelle bereit, die zum größtenteils mit der Amazon S3 RESTful API kompatibel ist.
  • Swift-Kompatibilität: Stellt die Objektspeicherfunktionalität mit einer Schnittstelle bereit, die zum größtenteils der OpenStack Swift API kompatibel ist.

Das Ceph Object Storage verwendet den RadosGW Daemon für die Interaktion mit dem Ceph Storage-Cluster. Als Backend kann hierfür das gleiche Ceph Storage Cluster verwendet werden wie für das Ceph Filesystem oder das Ceph Block Device.

Seit dem Ceph Release Jewel ist es nun auch möglich in einer MultiSite Konfiguration in die Nicht-Master-Zonen zu schreiben. Die Synchronisation der einzelnen Zonen funktioniert Out-of-the-box. Auf zusätzliche Agenten wird seit dem Jewel Release verzichtet.

Eine ausführliche Dokumentation für die Einrichtung eines MultiSite RADOSGateway findet man natürlich in der offiziellen Dokumentation oder auch bei uns in der Ceph Schulung.

Martin Schuster

Autor: Martin Schuster

Martin gehört zu den Urgesteinen bei NETWAYS und leitet zusammen mit Sebastian das Managed Services Team. Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren.

Rückblick Ceph Schulung 15.-16. November 2016

 

Schulung_Logo_PM

Wir bei Netways setzen bekanntermaßen sehr gerne und mit großen Eifer OpenSource-Lösungen auch in unserer Infrastruktur ein. Hierbei greifen Puppet, Foreman und OpenNebula auf ein gemeinsames Rückgrat zu, unseren Storage, der aktuell auf zwei Standorte und insgesamt 18 Server verteilt ist.

Dieser wird mittlerweile seit mehreren Jahren über Ceph zur Verfügung gestellt.training_sidebar_ceph_de_200x155

Ceph wurde 2007 von Sage Weil im Rahmen einer Doktorarbeit entwickelt und stellt ein Konzept für einen Object Store dar, der verteilt, hochverfügbar und auch eine konfigurierbare Anzahl an Replica skalierend vorhalten kann.

Seit dem ersten Stable Release 2012 hat sich das Ceph Projekt steil nach oben entwickelt , was 2014 zur Übernahme durch Red Hat führte. Trotz des hausinternen Konkurrenz durch GlusterFS steht die Entwicklung bei Ceph nicht still, sondern hat sich im Gegenteil beschleunigt.

Seit Version 0.6 Mitte 2012 ist Ceph innerhalb von 4 Jahren bei der vierten LTS Version „Hammer“ angekommen und wird in unterschiedlichen Clustergrößen bei den unterschiedlichsten Organisationen eingesetzt. Während unser Produktivcluster ca. 300 TB verwaltet, setzte das CERN bereits 2013 einen Testcluster von 3 Petabyte (sic!) ein.

Über die Jahre der Administration und des Einsatzes eines Clusters eignet man sich selbstverständlich ein gewisses Maß an Wissen an. Neben Veranstaltungsbesuchen und Vorträgen von externen Referenten, versuchen wir seit diesem Jahr, Ceph auch mit Schulungen von unserer Seite aus bekannter zu machen.

In der zweiten Iteration fand diese letzte Woche im 2tägigen Rahmen statt.

Neben der Wissensvermittlung stand auch die Netways-berühmtberüchtigte Nahrungsmittelüberversorgung mit Frühstück, Kaffeepause I, Mittagessen, Kaffeepause II und Abendessen für die Teilnehmer auf dem Programm.

Als Einstieg wählte Trainer Achim Ledermüller einen Überblick auf verschiedene Storage Arten um in der Folge Ceph genauer vorzustellen. Praktische Anwendung kam natürlich nicht zu kurz.

Die Teilnehmer installierten ihren eigenen Ceph-Cluster auf den bereitgestellten Schulungsnotebooks und konnten nach kurzer Zeit gegenseitig die ersten Dateien in rados-pools ablegen und aufrufen.

Als nächster Punkt wurde der Algorithmus hinter Ceph, „CRUSH“ und die zur Clusterverwaltung eingesetzte crushmap erklärt und an praktischen Beispielen veranschaulicht. Wie verändert sich der Cluster, wenn ein OSD ausfällt oder nach langer Zeit wieder in den Cluster zurück kehrt?

Nach einer kurzen Feedbackrunde ging es zu dem oben erwähnten Abendessen in das gewohnt gute Gasthaus Pegnitztal wo auch nicht-Ceph-Themen diskutiert wurden.

An Tag 2 hatten die Teilnehmer die Möglichkeit, eigene VMs mit QEMU/KVM auf dem Storage zu deployen, und die Auswirkungen auf den Cluster live zu beobachten.

Der restliche Tag stand im Zeichen der praktischen Anwendung.

Wie sieht es mit der Kompatibilität zur S3 API aus (gut!), welche Hardware ist Best Practice (commodity), wo kann ich an Performanceschrauben drehen (Netzwerk, storage und caching)? Wie kann ich den Cluster überwachen (ceph-plugins) und was ist im Fehlerfall zu tun?

Die nächsten Schulungstermine finden sich hier, wir würden uns freuen, unser Wissen weiterhin mit anderen zu teilen.

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Neue Juwelen in Ceph

Schulung_Stammlogo_webDer letzte Ceph Major Release Jewel hat nicht nur viele Bugs behoben sondern auch neue Features eingeführt bzw. für die Produktion freigegeben.

Ein neues Feature ist der sogenannte rbd-mirror, welcher zur asynchronen Replikationen von RBDs (vergleichbar mir iSCSI) verwendet wird. Ein neuer Daemon kümmert sich selbständig um die ständige Replikation der der RBDs zwischen zwei Clustern. Dadurch wird der Betrieb eines unabhängigen Clusters für Disaster Recovery Zwecke sehr viel einfacher und effektiver.

Mit Jewel wurde auch das neue Storage Backend Bluestore eingeführt. Dies ist der erste Schritt um sich von XFS zu trennen und vor allem von den doppelten Schreibprozessen, welche durch das Journal des Dateisystems verursacht werden. Bluestore soll bereits in der nächsten Version für produktive Cluster geeignet sein.

Lang erwartet, wurde auch CephFS für die Produktion freigeben. Das POSIX kompatible, shared Dateisystem kann gleichzeitig von mehreren Clients eingebunden und verwendet werden. Allerdings gibt es noch kleinere Einschränkungen die aber natürlich mit den nächsten Versionen angegangen werden.

Wer jetzt mehr Lust auf Ceph bekommen hat ist herzlich zu unserer Ceph Schulung im November eingeladen. Neben den beständigen Neuerungen in Ceph werden dort natürlich die grundlegenden Komponenten und Konzepte im Detail erklärt.

Achim Ledermueller

Autor: Achim Ledermueller

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.